GB2410863A - Context-based selection of telecommunications services - Google Patents

Abstract

A method of selecting services for use by a subscriber having a terminal connected to a mobile network via a communications serving node. The mobile network comprises a data store storing service parameters specifying services provided by the mobile network and supplementary services transmitted by the mobile network. The service parameters are indexed according to context data, such as the location of the subscriber, the location of the serving node, time of day, type of network, "home", "work" or "play" activities of the subscriber. Data is received identifying a context associated with the subscriber and, in response to the received data, service parameters are selected from the data store based on the identified context. The selected service parameters are transmitted to the communications serving node to provide the subscriber with the relevant service.

Description

24 1 0863 Method and System for Selection of Telecommunications Services

Field of the Invention

The present invention relates to a method and a system for the selection of telecommunications services, and is particularly, but not exclusively, suited to the selection of services for a subscriber in a mobile network. Embodiments of the invention are particularly well suited for use in selecting services for roaming subscribers, but could be applied to the retrieval of data in dependence on other aspects of the context of the subscriber.

Background of the Invention

One of the major features of all classes of GSM networks (cellular, PCS, and satellite) is the ability to support roaming users. Through the control signaling network, Mobile Switching Centers (MSCs) interact to locate and connect to users throughout the network, and data are stored in the MSC databases to assist in the role of determining how and whether connections are to be made to roaming users. These data include networkspecific basic services and supplementary services, as defined in the GSM standard GSM 09.02 version 4.19.1. In addition to the network-specific basic services and supplementary services, network subscribers increasingly have access to various supplementary services transmitted by the network. In the following description, the former (basic services and the supplementary services specific for the network) will be referred to as the network-specific services, and the latter (supplementary services transmitted by the network) will be referred to as the supplementary services. These supplementary services include, for example: services offered via an Intelligent Network (IN) (such as a Personal Number, in which the IN routes calls made to a personal number in accordance with previously specified instructions); services delivered in text mode via short messages; and notices, advertisements, personal reminders and information via the Internet through via Smart Messaging and WAP.

Currently network operators exercise a binary approach in relation to provision of sensitive services such as GPRS in networks other than the home network. Essentially, operators either allow full access to the services to which the subscriber has subscribed in the home network, or no access to certain sensitive services when the subscriber is roaming outside of the home network.

Whilst this can be extremely inconvenient for users who roam on a regular basis, it is understandable, given the difficulties associated with classifying third party networks and the technical difficulties associated with implementing varying degrees of access to network- specific services and supplementary services (NSSS) on a per subscriber basis.

US 6,108,540 discloses a system wherein each subscriber has a plurality of profiles stored in respect thereof, each of which specifies particular network specific and supplementary services appropriate for different times of the day or different geographic areas. In order to change profile, the subscriber sends data to the Home Location Register (HER) associated therewith, identifying which, of the plurality of profiles, is required. This arrangement has several problems, a first being that it requires the user to have some knowledge of the way in which his networkspecific services and supplementary services are organized; a second that it requires the user to manually specify which of the profiles is required; and a third that changes have to be made on a per subscriber basis, which is resource intensive.

US 6,603,969 discloses another system in which each subscriber has a plurality of profiles stored in respect thereof, but in this patent each profile specifies particular network-specific and supplementary services appropriate for different activities of the user (work, leisure, holiday). A current profile is changed in response to data received from the subscriber's terminal, the data having been input manually by the subscriber, or in response to conditions satisfying certain specified criteria (e.g. change of cell or geographical location).

Changes to profiles are in any case made on a per subscriber basis, which as mentioned above is resource intensive.

It is an object of the invention to provide an improved means of selecting service parameters in dependence on the context of the subscriber.

Summary of the Invention

In accordance with one aspect of the present invention, there is provided a method of selecting services for use by a subscriber in a mobile network, the subscriber having a terminal capable of connecting to the mobile network via a communications serving node, wherein the mobile network comprises a data store arranged to store service parameters specifying services provided by the mobile network and supplementary services transmitted by the mobile network, said service parameters being indexed in accordance with context data, the method including: l O receiving data identifying a context associated with the subscriber; in response to receipt of said identified context, selecting service data from the store of service parameters, based on said context; and transmitting the selected service data to the communications serving node.

In embodiments of the invention, service parameters are effectively selected for the subscriber in real time, based on the current content of the stored data. This means that any changes to the services are automatically included at the time of selection of the services for transmission to the user. This is a stark contrast to the arrangements described in US 6,108,540 and US 6,603,969, which instead store a plurality of pre-specified profiles for each subscriber, each comprising parameters that define services to be delivered to individual subscribers.

Preferably context data includes network location of the subscriber, extrinsic parameters such as time of day, and intrinsic parameters such as "home", "work", 'play" etc. Conveniently the network location of the subscriber can be identified from the identity of the communications serving node, which can be switches, GPRS serving nodes, Base Station Controllers, etc According to a second aspect of the invention there is provided a method of indexing a set of context-based network service parameters for use in providing a subscriber with network services, the method comprising: storing a set of parameters corresponding to a network service; assigning an identifier to the set of stored parameters; and associating said identifier with a context associated with said subscriber.

Indexing service parameter data in this manner means that the actual service parameters only need to be stored once, while the identifier, which links context to service, may be stored several times. This has significant implications in terms of updating data, since such an identifier is one-step removed from the sometimes vast amounts of service parameters. In the event that the service parameters change, since there is only one entry in the database corresponding thereto, the change only has to be effected once. By comparison, in the known prior art arrangements, each time a service parameter is changed, each profile in which the service parameter is listed requires changing.

Conveniently the method can also include associating the identifier with a type of subscriber.

According to a further aspect of the present invention there is provided a communications system equipped with storage and processing means arranged to effect the methods described herein.

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 block diagram of a mobile station arranged to operate in accordance with embodiments of the invention; Figure 2 is a schematic diagram showing components of a public land mobile network in which embodiments of the invention are arranged to operate; Figure 3 is a schematic representation of data contained in, and data processing components of, a home location register in accordance with an embodiment of the invention; Figure 4 is a schematic representation of further data contained in, or accessible by, the home location register shown in Figure 3; Figure 5 is a schematic representation of a data structure accessible via the further data shown in Figure 4; Figure 6 is a flow diagram showing steps carried out by the home location register shown in Figure 3; Figure 7 is a schematic diagram showing a configuration in which calls are processed according to an embodiment of the invention; Figure 8 is a flow diagram showing steps carried out by the home location register shown in Figure 3 according to a second embodiment; Figure 9 is a schematic representation of yet further data contained in, or accessible by, the home location register shown in Figure 3; Figure 10 is a schematic representation of still further data contained in, or accessible by, the home location register shown in Figure 3; Figure 11 is a schematic representation of a data structure accessible via the yet further data shown in Figure 10; and Figure 12 is a schematic representation of service parameter data accessible via the data structure shown in Figure 11.

Detailed Description of the Invention

Referring to Figure 1, a GSM-compliant mobile station MS 2 suitable for use in conjunction with embodiments of the present invention is a handset which comprises a transmit/receive aerial 16, a radio frequency transceiver 18, a GPRS module 19 which includes a packetiser/depacketiser and buffer store, a speech coder/decoder 20 connected to a loudspeaker 22 and a microphone 24, a processor circuit 26 and its associated memory 28, an LCD display 30, and a manual input port (keypad) 32. The mobile station is connected to a removable subscriber identity module (SIM) not shown, via electrical contacts.

Figure 2 shows an example of a Public Land Mobile Network (PLMN) 1, such as a GSM or UMTS network, within which embodiments of the invention operate. In Figure 2, the blocks indicate components of the PLMN network, which comprises a cellular network (only one cell 100 being shown in the Figure). The cell 100 has a limited coverage and is served by the PLMN I via a Base Transceiver Station (BTS) 101 and a Base Station Controller (BSC) 103, which form a Base Station System (BSS) 105. The BSC 103 is connected to a Mobile Switching Center (MSC) 107 which is an exchange and is arranged to perform all switching functions for mobile stations MS 2 located in a geographical area designated as the MSC area. The radio network subsystem (or BSS) may additionally, or alternatively, be connected to a WAP Serving GPRS support node (SGSN) 109, which provides various control functions such as tracking the mobile station's location for the purposes of packet data transfer, and performing security functions and access control. The SGSN may be connected to further nodes such as a gateway GPRS support node (GGSN) 111.

As shown in Figure 2, the MSC 107 is connected to an Intelligent Network IN 117 for providing the subscriber with access to intelligent network services (in the following an intelligent network means both an intelligent network and other service platforms similar to the intelligent network). The MSC is also connected to a Short Message Service Centre SMSC 119 via a Short Message Service Gateway SMSGW of the PLMN 1.

In operation, the MSC 107 and SGSN 109 take into account the impact of the allocation of radio resources and the mobile nature of the subscribers, and perform procedures required for location registration and hand-over of served mobile stations MS. For clarity purposes, the overview of Figure 2 hereinafter describes the configuration of, and actions performed by, the MSC 107 only, but these actions should be understood also to apply to the SGSN 109. In particular, the SGSN 109 has a cache (not shown) that is arranged to receive and store data in relation to the MS 2 that is used in subsequent processing of data sent thereto and therefrom.

The MSC 107 is connected to a Home Location Register (HLR) 115, which is a database arranged to manage data relating to mobile subscribers such as MS 2. The PLMN 1 may include one or several HLRs 115, depending on the number of mobile subscribers, the capacity of the equipment and the organization of the PLMN network 1. The HLR 115 is arranged to store data identifying the location of mobile subscribers managed by each HLR 115 (e. g. in order to be able to route calls thereto); identification numbers attached to each mobile subscription (e.g. International Mobile Subscriber identity (IMSI); International Mobile Subscriber ISDN Number (MSISDN)); communication service subscription information, service restrictions (e.g. roaming limitations); general subscriber attributes and preferences; and supplementary service information including parameters associated with these services.

Additionally, the MSC 107is connected to a Visitor Location Register (VLR) 113, which is arranged, as in known configurations, to receive data from mobile subscribers MS in this MSC 107 area and pass this information onto the HLR 115. For example, when an MS 2 is in the location area of the VLR 113, the VLR 113 starts an allocation updating procedure, whereby the MSC 107 transfers the identity of the location area in which the MS 2 is situated to the VLR 113. Having received this identity, the VLR 113 sends the location identity to the HLR 115, which transmits authentication data to the VLR 113, enabling the VLR 113 to authenticate, or otherwise, the attempt to register with the PLMN 1 (by MS 2). In the event that the MS 2 is successfully authenticated, the VLR 113 indicates this to the HLR 115, whereupon data identifying network-specific and supplementary service parameters corresponding to the MS 2 are downloaded to the VLR 113. In addition, the VLR 113 may allocate a Temporary Mobile Subscriber Identity (TMSI) to the MS 2, which is used by the VLR 113 for identification and addressing of the MS 2. Thus the VLR 113 stores identification numbers corresponding to this registered mobile subscriber MS 2, a temporary mobile station identity (TMSI), a location area where a corresponding MS is registered, together with network specific and supplementary service parameters received from the HLR 115.

In terms of communication between the various components of the PLMN 1, the MSC 107, HLR 115 and VLR 113 may send and receive data via a variety of signaling protocols, including but not limited to, Signaling System Number 113 (SS#7) Mobile Application Part (MAP), while signaling between the MSC 107 and the BSS 103 may use the Base Station System Application Part (BSSAP) of SS#7. Within the BSS 105 (i.e. between the BTS 101 and BSC 103) signaling is preferably mobile-specific, which means that the SS#7 protocols are not used for signaling transport.

As described above, embodiments of the invention are concerned with selection of network-specific and supplementary service parameters for use by the HLR 115. More specifically, in one aspect of the invention embodiments are concerned with tailoring selection of these service parameters in accordance with the context of a subscriber, such as the type of mobile network in which the or each subscriber is located (identified from, e.g. the network identity of the MS 2); in another aspect of the invention, embodiments are concerned with achieving efficient and scalable selection of the network-specific and supplementary service parameters, and this is achieved by a novel means of storing and arranging data in the HLR 115, to be described in more detail below.

Turning firstly to Figure 3, the HLR 115 includes a database HLR (DB) 201, which, in accordance with known methods, stores information about mobile users that have subscribed to some or all of the network-specific and supplementary services described above. The database HLR (DB) 201 stores records in respect of each subscriber (only one 210 is shown in the figure, which corresponds to MS 2), including at least a subscriber identifier field (IMSI) 211; an equipment number field (IMEI) 213; and a subscriber number (MSISDN) 215, along with details, in the form of a network identifier 217, of the MSC 107 with which the MS 2 is associated. The HLR(DB) 201 also stores details of the network-specific and supplementary services to which the subscriber MS 2 has access (e.g. to certain IN facilities 221, such as VPN, short number dialing, conditional call forwarding in respect of certain incoming or outgoing calls; to certain GPRS facilities 223 such as MMS, WAP, Intranet and Internet; Operator Determined Barring (ODB) facilities 225 in which calls made at certain times of day can be controlled by the operator; and others), along with details of the customer type (e.g. tariff 1, tariff 2 etc.) 231. The HLR 115 also includes, or has access to, NSSSP selecting software component 200, which is arranged to select data on the basis of, at least in part, the type of network with which the MS2 is associated, as will be described in more detail below.

In embodiments of a first aspect of the invention, selection of the NSSSP is additionally dependent on the network in which the MS 2 is registered, in terms of levels of protection in relation to fraud and privacy. This aspect of the invention has particular application in relation to GPRS services, where interception of data packets, within network PLMN, is possible and, more importantly, is outside of the control and protection of the network operator with whom the mobile subscribers have subscribed (the "home" network) when the subscriber is roaming. In addition, embodiments of the invention are dependent on the type of communication in which the MS 2 is involved (e.g. location update or incoming call/data transfer), since the number of services to which a subscriber requires access, and thus the amount of data that are required to be transmitted to the VLR 113, is different in the two scenarios.

Referring still to Figure 3, the HER (DB) 201 additionally stores a mapping 241 between subscriber network locations (in the form of source and destination addresses 251, 253 relating to incoming requests received from or in respect of subscribers) and types of services 255 accessible by a subscriber. In a first embodiment, identification of an appropriate service type 255 effectively invokes selection of one of a plurality of sets of data (301, shown in Figure 4), hereinafter referred to templates, each one corresponding to a previously defined type of service (herein referred to as roaming_x or home_y, where x and y respectively indicate particular versions of the roaming and home sets of data).

The categorization of service type 255, as a function of source and destination network locations (251, 253), is dependent on the policy of the HLR network operator.

At least some of the Figures referred to herein are closely related, in that outputs of parts shown in one Figure provide inputs to parts shown in other Figures. More specifically, Figure 3 shows a data structure 241 that links to a template 301 shown in Figures 4, 9 and 10; template 301 includes one or more identifiers 311 that provide input to a service parameter data structure 341 shown in Figures 5 and 11; and, for Figure 11 at least, items within the service parameter data structure 341 link to actual service parameters shown in table 1001 (shown in Figure 12).

Figure 4 shows parts of a template 301 for one such service type ("roaming_3"). The template 301 comprises a plurality of static data fields 303a 303d, which specify service data for all subscribers in this type of network, i.e. data that are independent of subscriber type 231. The template 301 also includes at least one dynamic data field 305, which contains an identifier 311 linking the template 301 to a data structure shown in Figure 5 (table 341). The data structure 341 contains data relating to a plurality of network-specifc and supplementary services IN1, IN2, INS (in this example all of the services are Intelligent Network services), each having a plurality of values that are dependent on the subscriber type 231. The NSSSP software component 200 is arranged to identify service parameters corresponding to each of the services TNT, IN2, INS, on the basis of subscriber type 231, via the identifier 311 in the

dynamic data field 305 ofthe template table 301.

Embodiments of the invention will now be described in the context of several scenarios. In a first scenario it is assumed that the subscriber is roaming in France and switches on his mobile 'phone MS 2, thereby commencing a location update procedure via the MSC 107. Referring to Figure 6, and assuming that the MS 2 is successfully authenticated by the VLR 113 and SGSN 109 (in accordance with conventional methods), at step 501, the NSSSP software component 200 accesses the network type mapping 241 shown in Figure 3 using a destination address, to which NSSSP data are to be sent, and a source address, from which the request for NSSSP data originates.

In this example, the destination address is the network address of the MS 2 (network identifier 217 corresponding to the MSC 107); since the subscriber is in France, this means that the identifier 217 starts with the number 3*. For location updates, the source address is the network address of the HER 115, which, in this implementation, has a default identifier *. Referring back to Figure 3, a combination of destination address of 3* and source address of * means that the NSSSP software component 200 selects "roaming_3" service type, and, at step 503, accesses the template 301 (Figure 4) corresponding to the service type identified at step 501. At step 505 the NSSSP software component reads all of the static network-specific and supplementary service parameter data corresponding thereto (data 303a 303d).

At step 507a, the NSSSP software component 200 searches, in the template 301, for the presence of dynamic fields, which may, for example, be identifiable by means of a flag and/or a process step that automatically invokes data structures (tables) associated with these fields. In this illustrative example, there is only one such dynamic field (field 305 "IN Context Set Version", which corresponds to the provision of GSM Intelligent Network (IN) services), and this field is linked to table 341. Having identified one or more such fields, any data therein - here identifier 311, which has a value of I - are retrieved (step 507b).

Next, at step 509 the NSSSP software component 200 invokes table 341; since selection of actual parameters is dependent on the type of subscriber, at step 511, the NSSSP software component 200 retrieves the subscriber type 231, and then queries (step 513) the table 341 using the service identifier and the subscriber type 213 retrieved at steps 507b and 511 respectively to extract the appropriate service parameters (step 513, described in more detail below). It will be appreciated by the skilled person that data identifying the subscriber type 231 can be retrieved at any time prior to this point.

Data corresponding to IN context set services for identifier 311 having a value of I are then retrieved (step 513). Assuming the subscriber type retrieved at step 511 to be "A", and referring to Figure 5, a value of 25 corresponding to service INI is retrieved. This value essentially indexes a specific type of service data and trigger key for intelligent network service INI.

The NSSSP software component 200 then transmits parameters corresponding to this trigger key, together with the static parameters retrieved at step 505, in a known manner (via the MAP protocol) to the VLR 113. The skilled person would appreciate that the data retrieved at steps 505 and 513 could be sent independently of one another, instead of being collated and sent together, as indicated at step 515.

It should be appreciated that embodiments of the invention provide a flexible way of relating the same service parameter to different customer types referring again to Figure 5, it can be seen that a value of 25 for service IN1 corresponds to identifier 1 for customer type A and to identifier 4 for customer type C. As will be appreciated from the foregoing, identifier type is directly coupled to network type, so that subscriber types A and C will actually have access to the same instance of INI services (those corresponding to a value of 25) only when they are in different types of networks.

It is to be noted that, in comparison to known methods (such as are described in US 6,108,540 and US 6,603,969, discussed above), an HER configured in accordance with the invention does not store a plurality of pre specified profiles for each subscriber, each comprising parameters that define services to be delivered to individual subscribers. Instead, parameters are effectively selected for the subscriber in real time, based on the current content of the mapping 241, template 301 and tables 341, which means that any changes to the resources 241, 301, 341 (i.e. changes to service types, customer types, and network types) are automatically included at the time of selection of NSSSP.

Embodiments are preferably arranged such that data relating to a given service parameter are only stored once, and are indexed by one or more data structures (or tables - here tables 231, 301, 341, among others). The link between subscriber and service parameters is thus efficiently provided by an index to the service parameters, which means that a change to a service parameter only has to be made to the entry corresponding to that service parameter, whilst changes to subscriber tariff and access to services for a subscriber can be made via the link to these service parameters. In the example given above, intelligent network service INI can have a range of parameters, each dependent on, for example the type of subscriber and where the subscriber is, among other things. The selection of a particular IN1 parameter is driven by a link maintained in table 341; if the services available to subscriber type A in a network location for which the identifier is 1 were to change, then only the value 25 in mapping 241 - essentially the index to service parameters of IN1 - needs to be changed.

Since such changes (to service types, customer types, and network types) are only made to these resources 241, 301, 341, rather than to data associated with each and every subscriber, the overheads associated with maintaining NSSSP for delivery to individual subscribers are far lower with embodiments of the invention. Furthermore, since service parameters are selected in real time, rather than being stored in profiles as described in US 6,108, 540 and US 6,603,969, the amount of storage required by embodiments of the invention is considerably less than that required in the known systems.

Embodiments of the invention are thus an improvement, in terms of efficiency, storage and scalability, over known methods.

It should also be noted that this method of indexing and selecting network-specific and supplementary service parameters represents a second aspect of the invention, since it can be used to select parameters on the basis of context data other than network type. Such context data could, for example, include extrinsic parameters such as time of day and on intrinsic parameters such as whether the subscriber is deemed to be "at home" or "at work". The scope of the invention is envisaged to apply to other such context data.

In addition to being used in the selection of NSSSP for location update, an embodiment of the invention can also be used by the HLR 115 in handling mobile-terminating calls (or in co-ordinating transmission of data messages), where the subscriber receives a call (or data messages) from a third party, and the HLR 115 is involved in routing the call to the subscriber MS 2. Such a scenario will now be described with reference to Figures 7, 8 and 9, for the case where the subscriber is assumed to be roaming in France and receives a call. It should be noted that, in Figures7, 8 and 9, those parts that are identical to those that have already been described are given the same reference numerals and are not described in any further detail.

Referring to Figure 8, a request for the network location of the MS 2 is sent by the Gateway MSC GMSC 601 (via the MAP protocol, at step 701) to the HLR 115. In addition to sending the requisite location information to the GMSC 601 at step 703 (in accordance with known methods), the HLR 115 invokes the NSSSP software component in order to identify and download, to the VLR 113, those NSSSP that are required to receive the call. Accordingly, at step 501 the NSSSP software 200 accesses the network type mapping 241 using the network address of the MS 2 (MSC identifier 217, which starts with 3*) as destination address, and the network address of the Gateway MSC 601, which has an identifier corresponding to the home network (which in this example is 447170) as source address. Accordingly and referring back to Figure 3, the NSSSP software component 200 selects "roaming_4" service type at step 501 and, at step 503 accesses the template 301 corresponding to the "roaming_4" service type identified at step 501 (shown in Figure 9), reading (step 505) all of the static network-specific and supplementary service parameter data corresponding thereto (data 303a 303d).

The NSSSP software component 200 also retrieves identifier(s) 311 corresponding to the dynamic field(s) that is/are relevant to the type of call or data service being set up. In the example of a Mobile Terminating call, the relevant services include those corresponding to Intelligent Network services, so that "IN Context Set Vsn" 305 dynamic field is of interest (step 507b); in this example, the identifier 311 corresponding to dynamic field 305 takes a value of "4". Next, at step 509, the NSSSP software component 200 invokes table 341, and queries (step 513) the IN Context Set table 341 using both the service identifier and the subscriber type 213 to extract the appropriate service parameters. Assuming the subscriber to be of type "A", and referring back to Figure 5, data corresponding to service INS are retrieved (which for identifier 4 takes a value of 64 and translates to a particular set of mobile terminating CAMEL data; not shown). At step 515 these data, together with the static data retrieved at step 505, are transmitted to the VLR 113.

It will be appreciated that parameters corresponding to service IN1 will already have been sent to the VLR 113, since the MS2 will have carried out a location update procedure at the time of camping on the cell served by MSC 107. It can therefore be seen that the parameters sent in response to location update messages are a subset of those parameters required to receive a Mobile Terminating call, and that NSSSP parameter data are only transmitted to the VLR 113 as and when they are required. This advantageously reduces both the bandwidth usage associated with transmitting NSSSP data and the amount of storage capacity required on the MSC 107.

A further example will now be described, in which MS 2 is assumed to be capable of sending and receiving GPRS data. As described above, the SGSN 109 is referred to as a serving GPRS support node, in that such a node is arranged to serve mobile stations MS 2 in its routing area. On logon to the GPRS service of a mobile station, the SGSN 109 establishes a mobility management context containing information pertaining to mobility and security for the mobile station MS 2. The SGSN 109 also establishes a routing context, referred to in GPRS as a "PDP context", with the GGSN 111 to be used by the mobile station MS 2 to access a packet data network such as the public Internet, an intranet connection or a leased line.

Thus, with the additional functionality of the SGSN 109 and the GGSN 111 in the PLMN, and the GPRS module 19 in the mobile stations MS 2, the mobile networks and users are GPRS enabled, whereby the mobile users may transmit and receive packet mode data. For example, the mobile user may use the mobile station MS 2 in order to access Web pages, using terminal equipment attached to the mobile station MS 2, on the public Internet, via the gateway functionality provided by the GGSN 111 and the packet mode transfer functionality provided in the remainder of the network including the SGSN 109, the BSCs 103, the BTSs 101 and a GPRS radio interface.

The GPRS radio interface is described in GSM 03.64 Version 5.1.0, entitled "Digital Cellular Communications System (Phase 2+)"; General Packet Radio Service (GPRS); Overall Description of the GPRS Radio Interface; Stage 2, published by European Telecommunications Standard Institute, the contents of which are incorporated herein by reference.

The GPRS architecture and transmission mechanism, mobility management functionality, network management functionality, radio resource functionality, packet routing and transfer functionality, transmission and information storage using GPRS are described in GSM 03.60 Version 5.2.0, entitled "Digital Cellular Telecommunications System (Phase 2+)"; General Packet Radio Service (GPRS); Service Description; Stage 2, published by the European Telecommunications Standard Institute, the contents of which are incorporated herein by reference.

Mobile station MS 2 is arranged to store a plurality of PDP contexts, each of which corresponds to a particular GPRS service and can be activated by the MS 2 once it has attached to the GPRS network. As is known in the art, at the time of performing a GPRS attach procedure, the MS 2 attempts to copy information to the SGSN 109 for the purposes of sending and receiving GPRS data. The ability, or otherwise, of the MS 2 to activate a selected context is dependent on the data sent from the HLR 115 to the SGSN 109, and this embodiment of the invention is concerned with controlling these data on the basis of the type of network in which the MS 2 is located.

In this example it is assumed that the MS 2 instigates a logon procedure with the SGSN 109, so as to attach thereto. The GPRS logon signaling procedure is described in GSM 03.60 V.5.2.0, part 6.5 entitled "Attach Function", which part is incorporated herein specifically by reference. This part also refers to part 9.2.2 entitled "Activation Procedures" of the same document, which describes the PDP context activation procedure at logon, which part is also incorporated herein specifically by reference.

Having executed GPRS attach, the mobile station is in a "ready state", in which packet transfer may occur via the GPRS radio interface between the mobile station MS 2 and the PLMN, and mobility management contexts are established in the mobile station and the SGSN 109. The mobile station then attempts to activate a selected PDP context, by transmitting an 'Activate PDP Context' request to the SGSN 109.

Upon receipt of such an activation request, the SGSN 109 queries the HLR 115, in which GPRS subscription information is held for the subscriber, in order to check that the mobile station MS 2 is allowed to activate the PDP context contained in the request; in particular the SGSN 109 requests data identifying the Access Point Nodes (GGSN 111 (if any)) to which the mobile station MS 2 can send and receive packet data. Having received the request, the HLR 115 additionally invokes the NSSSP software component 200 in order to determine which parameters should be sent to the SGSN 109. In this example, the destination address is the network address of the MS 2 (MSC identifier 217), which is again assumed to start with the number 3*, and, since the call is a GPRS activation request, the source address is the network address of the HLR 115, which has a default identifier *. Referring back to Figure 3, the NSSSP software component 200 selects "roaming_3" service type at step 501, then accesses the template 301 corresponding to "roaming_3" service type and reads (steps 503, 505) all of the static network-specific and supplementary service parameter data in the template. This template 301 is shown in Figure 10, and, with the exception of an additional row that corresponds to PDP Context data, is identical to that shown in Figures 4 and 9.

The NSSSP software component 200 retrieves identifier(s) 311 corresponding to the dynamic field(s) that is/are relevant to the type of call or data service being set up. In the example of a GPRS activation request, the relevant services include those corresponding to GPRS services, so that the identifier(s) corresponding to the "PDP Context Set Vsn" 307 dynamic field is/are of interest (step 507b); in this example, the identifier 311 corresponding to dynamic field 307 takes a value of "1". The NSSSP software component 200 then queries a PDP Context Set data structure 341 using both the service identifier and the subscriber type 213 to extract the appropriate service parameters. Assuming the subscriber to be a type A subscriber, and referring to Figure 11, values 3, 36 and 37 are extracted from table 341, each of which index various GPRS PDP Context parameters, a selection of which are shown in Figure 12 (SMS parameters, together with an accepted list of protocol types, billing characteristics, specified Quality of Service, Access Point Nodes) . These data, together with the static data retrieved at step 505, are then transmitted to the SGSN 109, so that, when the MS 2 requests activation of a selected PDP context, the SGSN 109 can process the request in accordance with the NSSSP parameters sent from the HER 115.

Referring back to Figure 11 briefly, it can be seen that when identifier 311 takes value 1 and the subscriber is of type D, the subscriber will have access to two sets of WAP service parameters: those identified by value 5 and those identified by value 1. Turning to Figure 12, this means that customer type D can send and receive data via two different WAP GGSN nodes, one of which (SPWAP) is also accessible to customer types B and C, and one of which (CORPlWAP) is only accessible to customer type D. Thus identifiers 1, 2, 3 essentially represent a set of core PDP Context parameters, which can be supplemented by additional Access Point Nodes, Quality of Service etc. in accordance with customer type.

The examples described above are relatively simple, in terms of variety in template type and the like. Whilst this is convenient, from the point of view of describing the invention, the skilled person will appreciate that there could be a wider range of destination types (and thus number of templates), and indeed that any particular destination address could be split according to regions, each being associated with a different template. For example, destination address 1* could comprise 1631*; 1630*; 1350*; 1949* etc. (each of which, in this example, is a state within North America), each of which having a template associated therewith, so that services available to subscribers could vary in accordance with location within a country and/or region.

Instead of having one template per network type or network location, networks could be categorized by type - e.g. "trusted", "trusted for MMS", "trusted for WAP" etc. - and a template associated with each type. Such an arrangement could involve use of a yet further look-up table, accessed prior to accessing mapping 241, and essentially replacing "destination address" with a type of network. This further look-up table would therefore link actual destination address to type of network and output the network type for use in selecting an appropriate template as described above.

In the above examples, identifier 341 is used to refer to tables corresponding to different types of NSSSP (Intelligent Network Services, GPRS services); in practice the different types of NSSSP can be stored in one or a plurality of data structures, and the NSSSP software component 200 arranged to retrieve data corresponding to the type of communication (location update, incoming call, data transfer etc.) for which service parameters are to be selected.

Whilst, in the above examples, the destination address 251 is identified from the MSC 107 with which the MS 2 is associated, the destination address 251 could alternatively be identified from a VLR address received in the SCCP layer for MAP operations sent from a Gateway MSC (GMSC). Alternatively, the subscriber data to be used for MAP operations sent from the HER system could be based on the VLR address stored in the subscriber's HER record.

The NSSSP software component 200 described above could comprise one or several computer programs, preferably written in the C programming language and arranged to run as part of the standard HLR software involved selection and transmission of network-specific and supplementary service parameters.

Whilst in the embodiments described above both the network location and subscriber type are utilised when selecting NSSSP for transmission to the VLR 113 or SGSN 109, it will be appreciated that the invention lies in filtering services in accordance with where the subscriber is roaming, and that further filtering in accordance with subscriber type is a preferred, rather than essential, feature.

As described above, embodiments of the invention can be applied in respect of context data other than network location. In particular, services such as call forwarding could be indexed in accordance with, and a set of services could be selected for transmission to the user as, a function of the time of day.

In addition to downloading the selected services to the VLR 113, the HLR I 15 could additionally download temporal data specifying periods during which the selected services (i.e. call forwarding conditions apply); in the event that the specified period is deemed to have elapsed and the mobile station MS 2 is still communicating with the VLR 113, the VLR 113 could send a further request to the HLR 115 for a new set of services, these being relevant to the new context of the subscriber - i.e. at the new time. Such an arrangement would be particularly useful for time periods when the subscriber is deemed to be at home as opposed to at work, when he may have different call forwarding options specified. The skilled person will appreciate that this applies to other network services (i.e. those other than call forwarding).

The above embodiments are to be understood as illustrative examples of the invention. Further embodiments of the invention are envisaged. For example, embodiments could be used in selection of data from databases other than those relating to mobile networks, since the principle of retrieving a set of data, in respect of real-time conditions, is generally applicable to many data retrieval problems. 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.

Claims (33)

1. Claims 1. A method of selecting services for use by a subscriber in a

   mobile network, the subscriber having a terminal capable of connecting to the mobile network via a communications serving node, wherein the mobile network comprises a data store arranged to store service parameters specifying services provided by the mobile network and supplementary services transmitted by the mobile network, said service parameters being indexed in accordance with context data, the method including: receiving data identifying a context associated with the subscriber; in response to receipt of said identified context, selecting service data from the store of service parameters, based on said context; and transmitting the selected service data to the communications serving node.
2. 2. A method according to claim 1, in which the context includes the location of the subscriber.
3. 3. A method according to claim I or claim 2, in which the context includes the network location of the subscriber.
4. 4. A method according to claim 3, in which the network location of the subscriber comprises the network location of a communications serving node with which the subscriber is associated.
5. 5. A method according to claim 3, in which the network location of the subscriber comprises the network location of the communications serving node with which the terminal is connected.
6. 6. A method according to any one of the preceding claims, in which the context includes parameters that are extrinsic to the subscriber.
7. 7. A method according to claim 6, in which said extrinsic parameters include time of day.
8. 8. A method according to any one of the preceding claims, in which the context includes intrinsic parameters associated with the subscriber.
9. 9. A method according to any one of the preceding claims, in which the store of service parameters includes control data for use in controlling voice services.
10. 10. A method according to claim 9, in which the control data includes triggers associated with one or more intelligent network services.
11. 11. A method according to any one of the preceding claims, in which the store of service parameters includes control data for use in controlling in packet-based services.
12. 12. A method according to any one of the preceding claims, in which the stored data is indexed in accordance with subscriber type and said selecting step additionally includes selecting data on the basis of the type of said subscriber.
13. 13. A method of selecting services for use by a subscriber in a mobile network, the subscriber having a terminal capable of connecting to the mobile network via a communications serving node, wherein the mobile network comprises a data store arranged to store service parameters specifying services provided by the mobile network and supplementary services transmitted by the mobile network, said service parameters being indexed in accordance with network location, the method including: receiving data identifying a network location of a communications serving node with which the subscriber is associated; in response to receipt of said identified network location, selecting service data from the store of service parameters, based on said network location; and transmitting the selected service data to the communications serving node.
14. 14. A method according to claim 13, in which the stored data is indexed in accordance with subscriber type and said selecting step additionally includes selecting data on the basis of the type of said subscriber.
15. 15. A method of indexing a set of context-based network service parameters for use in providing a subscriber with network services, the method comprlsmg: storing a set of parameters corresponding to a network service; assigning an identifier to the set of stored parameters; and associating said identifier with a context associated with said subscriber.
16. 16. A method according to claim 15, in which the context includes type of network.
17. 17. A method according to claim 16, in which the method includes associating network location with type of network.
18. 18. A method according to claim 15 or claim 16, in which the context includes network location.
19. 19. A method according to any one of claim 15 to claim 18, in which said context includes extrinsic parameters.
20. 20. A method according to claim 19, in which said extrinsic parameters include time of day.
21. 21. A method according to any one of claim 15 to claim 20, including associating said identifier with one or more customer types.
22. 22. A method of indexing a set of location based network service parameters for use in providing a subscriber with network services, the method comprising: storing a set of parameters corresponding to a network service; assigning an identifier to the set of stored parameters; associating said identifier with network locations.
23. 23. A method according to claim 22, including associating said identifier with one or more customer types.
24. 24. A method according to any one of claim 22 or claim 23, in which the network location is network location of said subscriber.
25. 25. A method according to any one of claim 15 to claim 24, in which said network service includes services provided by the mobile network.
26. 26. A method according to any one of claim 15 to claim 25, in which said network service includes supplementary services transmitted by the mobile network.
27. 27. A method according to claim 25, in which said supplementary services include intelligent network services.
28. 28. A method according to any one of claim 15 to claim 27, in which said network services include GPRS services.
29. 29. A method of selecting services for use by a subscriber in a mobile network, the subscriber having a terminal capable of connecting to the mobile network via a communications serving node, method including: receiving data identifying a context of the subscriber; receiving data identifying type of subscriber; selecting one or more sets of data, from a plurality of selectable sets of data, based on the received context data, at least one set of data being invariant with subscriber type and at least one set of data varying in accordance with subscriber type; and transmitting the or each selected set to the communications serving node; in which, for the or each set of data that varies in accordance with subscriber type, said selecting step additionally includes selecting on the basis of said received subscriber data.
30. 30. A method according to claim 29, in which the context of the subscriber includes the type of mobile network in which the subscriber requests services.
31. 31. A method according to claim 29 or claim 30, in which the context of the subscriber includes the location of the mobile network in which the subscriber requests services.
32. 32. A method according claim 31, including identifying the location of said mobile network on the basis of the network location of the communications serving node.
33. 33. A method of providing services to a subscriber in a mobile network, the subscriber having a terminal capable of connecting to the mobile network via a communications serving node, wherein the mobile network comprises a data store arranged to store service parameters specifying services provided by the mobile network and supplementary services transmitted by the mobile network, the method including: receiving data identifying a context associated with the subscriber; transmitting a request for service data from the store of service parameters, based on said context; receiving service data and data indicating conditions under which said service data are relevant; monitoring context data associated with the subscriber in accordance with the received conditions; and transmitting a further request for service data in the event that said conditions are met.