Abstract:
A cellular telecommunications network for facilitating communication connections for terminals having token identification modules, the network including: a location register for receiving requests to access the network and, if the requests are associated with a token identification module, redirecting the requests; a token register which receives redirected requests, generates connection identification data and transmits the connection identification data to the location register to identify the terminal to the location register; a network gateway component for establishing a communication between the network and the terminal in accordance with the connection identification data; and a network monitoring component for performing service management, such as a session authentication check. A network implementing the invention is capable of providing data communication sessions to terminals having identification modules that are not associated with MSISDN numbers. Embodiments described are directed to laptops and M2M terminals with embedded token identification modules.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a continuation of U.S. application Ser. No. 13/351,788, filed Jan. 17, 2012, which is a continuation of U.S. application Ser. No. 13/117,979, filed May 27, 2011, which is a continuation of U.S. application Ser. No. 12/935,798, filed Sep. 30, 2010, which is a 371 application of PCT/GB2009/50321, filed Apr. 2, 2009, all of said applications incorporated herein by reference. 
     
    
     FIELD OF THE INVENTION 
       [0002]    The present invention relates to a telecommunications network. In particular, the invention relates to a cellular network that allows terminals having identification modules to establish a data communication without that identification module being associated with a subscriber. 
       BACKGROUND OF THE INVENTION 
       [0003]    In conventional cellular telecommunications networks, the activation of a subscriber identification module (SIM) requires that certain preconditions are met. Of particular interest here, the SIM must be associated with a unique telephone number (MSISDN). This familiar telephone number is generally used by a calling party wishing to make a voice (or video) call to the mobile terminal into which the SIM has been inserted. Invariably, the telephone number is selected (either automatically or in some instances by the user themselves) from a range of available MSISDN numbers owned by the provisioning operating company and the selected number is assigned to the SIM when the SIM is addressed for the first time by the operating company network: generally this means that the telephone number must be assigned before a user first activates the SIM under a prepay or contract arrangement. 
         [0004]    The network operator bears a cost associated with provisioning a SIM with a valid MSISDN, both for the reservation of the MSISDN (regulators such as the ITU assign ranges of MSISDN numbers to operating companies) and for the retail staff time and overheads in registering the selected number for use. 
         [0005]    Where that SIM appears no longer (or never to have been) used for a predetermined period, the network operators typically note this fact and initiate a “quarantine” process for returning the telephone number to the set of available numbers. Of course, this quarantining process has an associated cost: so too does reassigning that MSISDN number as ultimately will happen when it is confirmed unused after the quarantine period expires. 
         [0006]    As the reader will readily appreciate, the provisioning of SIMs that are infrequently or never used represents a distinct inconvenience to the network operator. This inconvenience is significant even when considering the conventional provision of mobile telephones and data card/modems with SIMs. There is however a current trend to embed or otherwise SIM-enable a far wider range of computing and other electronic goods. For example, PC laptops, ultra-mobile PCs (UMPC), personal digital assistants (PDA), satellite positioning devices, set top boxes (STB), wireless access points (APs) and even onboard vehicle computers may, and lately often are, fitted with modules that accept SIMs to enable communication over cellular telecommunication networks. Clearly, this trend implies a concomitant increase in the number of unused or infrequently used SIMs and a consequently greater level of disruption to the network operator who wishes to enable such devices. 
         [0007]    A further problem arises in relation to the production and management of SIM cards for telematics terminals (e.g. in-car computers), where it is desirable that the terminals may be exported to a variety of geographical locations each with their own telecommunication network. 
         [0008]    As described in prior patents GB2378097, GB2378094 and GB2378095, the problem may be addressed by ensuring that all relevant operator keys and specific parameters are pre-stored on the SIM, at the time of manufacture. Consequently, a suitably prepared SIM can be re-registered from one home network to another home network as necessary. The SIM is sent instructions regarding which authentication keys it is to use in which territory and a corresponding new SIM identifier number, IMSI. 
         [0009]    As a result, where cars are exported, SIMs can be configured for the country of manufacture and later reconfigured for the final country. The method can also apply to other devices and can be indefinitely re-configured. Hence a terminal can be used in another network (not as a roaming subscriber) for a significant time without a new SIM card being issued. Clearly the non- or infrequent use of such “prefitted” SIMs would only amplify the problems outlined above, since this solution requires the provisioning of a plurality of available MSISDNs, one for each territory envisaged at manufacture. 
       SUMMARY OF THE INVENTION 
       [0010]    It is therefore an object of the invention to obviate or at least mitigate the aforementioned problems. 
         [0011]    In accordance with one aspect of the present invention, there is provided a cellular telecommunications network for facilitating communication connections for terminals having token identification modules, the network including: 
         [0012]    a location register for receiving requests to access the network and, if the requests are associated with a token identification module, redirecting the requests; 
         [0013]    a token register which receives redirected requests, generates connection identification data and transmits the connection identification data to the location register to identify the terminal to the location register; 
         [0014]    a network gateway component for establishing a communication between the network and the terminal in accordance with the connection identification data; 
         [0015]    a network gateway component for establishing a communication between the network and the terminal in accordance with the token connection identification data; and 
         [0016]    a network monitoring component for performing service management. 
         [0017]    The communication connections are preferably data-only communication connections. 
         [0018]    Each request to access the network from a terminal having token identification module preferably includes an IMSI number identifying the token identification module uniquely. 
         [0019]    The network may further include: a server which is adapted to serve user dialog webpages to terminals in accordance with token connection identification data, each webpage presenting the user with at least one user action option; and an internetwork gateway which governs access from the cellular network to an internetwork; wherein the session authentication check performed by the network monitoring component includes determining whether the token connection identification data is associated with a valid session; wherein the network gateway component directs the terminal to a user dialog webpage served by the web server when the network monitoring component determines that there is no valid associated session, and wherein the terminal is given access to the internetwork in dependence upon user action option input from the terminal. 
         [0020]    Alternatively the network further includes an internetwork gateway which governs access from the cellular network to an M2M server via an internetwork; the session authentication check performed by the network monitoring component includes determining whether the token connection identification data is associated with a valid M2M session; and the network monitoring component directs the terminal to the M2M server when the network monitoring component determines that the token connection identification data is associated with a valid M2M session. 
         [0021]    The internetwork may be the Internet or an intranet. 
         [0022]    The location register may be distributed having an aggregator point for aggregating signalling functionality and a network entity for carrying out further location register functionality, said aggregator point and said network entity being in communication with one another. Examples of further location register functionality include the temporary storage of IMSI numbers. 
         [0023]    Examples of service management performed by the network monitoring component include: session management; session authentication checking; and/or the application of network operator policy (such as fair usage). 
         [0024]    In accordance with another aspect of the present invention, there is provided a method for facilitating communication connections between terminals having token identification modules and a cellular telecommunications network, the cellular network including a location register, a token register, a network gateway component, a network monitoring component, a server and an internetwork gateway; the method including: 
         [0025]    at the location register, receiving a request to access the network from a terminal, determining whether the request is associated with a token identification module and redirecting the request to the token register; 
         [0026]    at the token register, receiving the redirected request, generating token connection identification data and transmitting the connection identification data to the location register thereby identifying the terminal to the location register; 
         [0027]    establishing a communication between the network and the terminal in accordance with the token connection identification data; and 
         [0028]    performing a session authentication check. 
         [0029]    The session authentication check step may include determining whether the token connection identification data is associated with a valid session and the method may further include: serving a user dialog webpage to the terminal in accordance with the token connection identification data, the webpage presenting the user with at least one user action option; directing the terminal to the user dialog webpage when the network monitoring component determines that there is no valid associated session; and permitting access from the cellular network to the internetwork in dependence upon user action option input from the terminal. 
         [0030]    Alternatively, the method may further include: directing the terminal to the M2M server when the network monitoring component determines that the token connection identification data is associated with a valid M2M session, where the internetwork gateway governs access from the cellular network to an M2M server via an internetwork and the session authentication check step includes determining whether the token connection identification data is associated with a valid M2M session. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWING FIGURES 
         [0031]    For a better understanding of the present invention, reference will now be made, by way of example only, to the accompanying drawings in which:— 
           [0032]      FIG. 1  illustrates key elements of a cellular telecommunications network, and its operation; 
           [0033]      FIG. 2A  illustrates key elements of a cellular telecommunications network in accordance with the invention, the network having both a home location register and a token register; 
           [0034]      FIG. 2B  illustrates key elements of an alternative cellular telecommunications network in accordance with the invention, the network having no home location register and relying upon a visitor location register instead; 
           [0035]      FIG. 2C  illustrates key elements of a further alternative cellular telecommunications network in accordance with the invention, the network relying upon location register functionality in a network gateway component instead of home location register; 
           [0036]      FIG. 2D  illustrates key elements of yet further alternative cellular telecommunications networks in accordance with the invention, in which an SS7 aggregation point is used to facilitate the architectures of  FIGS. 2  A,  2 B and  2 C; 
           [0037]      FIG. 3  illustrates the flow of events in providing data sessions to a PC laptop with an embedded identification module in accordance with the invention; and 
           [0038]      FIG. 4  illustrates the flow of events in providing data sessions to a device for use in a machine to machine environment in accordance with the invention. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0039]    A telecommunications network  100  includes a plurality of base stations (BS)  3 ,  4 ,  5 ,  7 ,  8 , and  9  and a core network  12 . 
         [0040]    Each base station (BS) corresponds to a respective cell of the telecommunications network and receives calls from and transmits calls to a mobile terminal in that cell by wireless radio communication in one or both of the circuit switched or packet switched domains. Such a subscriber&#39;s mobile terminal is shown at  1 . The mobile terminal may be a handheld mobile telephone, a personal digital assistant (PDA) or a laptop computer equipped with a datacard. 
         [0041]    Each base station comprises a base transceiver station (BTS) and a base station controller (BSC). A BSC may control more than one BTS. The BTSs and BSCs comprise the radio access network. 
         [0042]    Conventionally, the base stations are arranged in groups and each group of base stations is controlled by one mobile switching centre (MSC), such as MSC  2  for base stations  3 ,  4  and  5 . As shown in  FIG. 1 , the network has another MSC  6 , which is controlling a further three base stations  7 ,  8  and  9 . In practice, the network will incorporate many more MSCs and base stations than shown in  FIG. 1 . 
         [0043]    Each subscriber to the network is provided with at least one smart card or subscriber identity module (SIM) card (strictly speaking a UICC) which, when associated with the user&#39;s mobile terminal identifies the subscriber to the network. The terminal typically has an identifier of its own (the “International Mobile Equipment Identity”, IMEI), which can be obtained in certain networks, however this terminal ID is not essential in identifying the subscriber to the network. The SIM card is preprogrammed with a unique identification number, the “International Mobile Subscriber Identity” (IMSI) which can be accessed on the card but which is not generally known to (or used directly by) the subscriber. Printed on the outside of each SIM, there is a further unique identification number, the ICCID/SIM Serial number (SSN), which is unrelated to the IMSI number. The subscriber is issued with a further, publicly known, number, that is, the subscriber&#39;s telephone number, by means of which calls to the subscriber are initiated by callers. This number is the Mobile Subscriber ISDN Number (MSISDN). 
         [0044]    The core network includes a home location register (HLR)  10  which, for each subscriber to the network, stores the IMSI and the corresponding MSISDN together with other subscriber data, such as the current or last known location of the subscriber&#39;s mobile terminal. A second register, the visitor location register (VLR)  14 , is used to store the IMSI and the corresponding MSISDN for subscribers that are active in the network temporarily. Throughout the present description, the term “location register” should be understood to relate to a network entity performing the functionality of a HLR, a VLR and/or a network gateway component, such as a serving GPRS support node (SGSN). 
         [0045]    When the subscriber wishes to activate their mobile terminal in the network (so that it may make or receive calls subsequently), the subscriber places their SIM card in a card reader associated with the mobile terminal (terminal  1  in this example). 
         [0046]    When the mobile terminal  1  is switched on, it searches for a mobile network to which to connect. Once the mobile terminal identifies the desired network, it sends a message to the network (via the base station  3  associated with the particular cell of that network in which the terminal  1  is located) to indicate that it has entered into “idle state”. This message includes the IMSI (read from the card). In a conventional network, the base station  3  then transmits the IMSI to the MSC  2  with which the BS  3  is registered. 
         [0047]    The MSC  2  passes the IMSI to the VLR  14 , which in turn checks its database to determine whether there is an existing record of the particular subscriber. 
         [0048]    If no record is found, the VLR  14  indicates this to the MSC  2  and the MSC  2  accesses the appropriate location in the HLR  10  present in the network core  12 . The MSC  2  then extracts the corresponding subscriber MSISDN and other subscriber data from the appropriate storage location, and stores it temporarily in a location in the VLR  14 . Then an acknowledge message is sent to the mobile terminal. In this way, therefore the newly active subscriber is effectively registered with a particular MSC (MSC  2 ), and the subscriber&#39;s information is temporarily stored in the VLR (VLR  14 ) associated with that MSC. 
         [0049]    When the HLR  10  is interrogated by the MSC  2  in the manner described above, the HLR  10  additionally performs an authentication procedure for the mobile terminal  1 . The HLR  10  transmits authentication data to the MSC  2  in “challenge” and “response” forms. Using this data, MSC  2  passes a “challenge” to the mobile terminal  1  through base station  3 . Upon receipt of this data, the mobile terminal  1  passes this data to its SIM and produces a “response”. This response is generated using an encryption algorithm on the SIM and a unique key, Ki, on the SIM. The response is transmitted back to the MSC  2  which checks it against information that it has obtained for that subscriber from the HLR  10  in order to complete the authentication process. If the response from the mobile terminal  1  is as expected, the mobile terminal  1  is deemed authenticated. At this point the MSC  2  requests subscription data from the HLR  10 . The HLR  10  then passes the subscription data to the VLR  14 . 
         [0050]    The authentication process will be repeated at regular intervals while the mobile terminal  1  remains activated and can also be repeated each time the mobile terminal makes or receives a call, if required (this process is known as “paging”). 
         [0051]    Each of the MSCs of the network (MSC  2  and MSC  6 ) has a respective VLR ( 14  and  11 ) associated with it and operates in the same way as already described when a subscriber activates a mobile terminal in one of the cells corresponding to one of the base stations controlled by that MSC. 
         [0052]    When the subscriber using mobile terminal  1  wishes to make a voice call, having already inserted the SIM card into the reader associated with this mobile terminal and the SIM has been authenticated in the manner described, a call may be made by entering the telephone number (MSISDN) of the called party in the usual way. This information is received by the base station  3  and is then routed to the called party via the MSC  2 . By means of the information held in the VLR  14 , MSC  6  can associate the call with a particular subscriber and thus record information for charging purposes. 
         [0053]    The MSCs  2  and  6  support communications in the circuit switched domain—typically voice calls. Corresponding SGSNs  16  and  18  are provided to support communications in the packet switched domain—such as GPRS data transmissions. The SGSNs  16  and  18  function in an analogous way to the MSCs  2  and  6 . The SGSNs  16 ,  18  are equipped with an equivalent to the VLR for the packet switched domain. 
         [0054]      FIGS. 2A ,  2 B,  2 C and  2 D show a number of alternative cellular network arrangements suitable for allowing data communication between a mobile terminal and the network in accordance with the invention. Where components are substantially identical to components shown in  FIG. 1 , the same reference numerals are adopted in  FIGS. 2A ,  2 B,  2 C and  2 D. 
         [0055]    In the invention, identification modules are treated as unique tokens that have not yet been associated with a particular subscriber: they are consequently referred to a token identification modules, or TIMs. Typically, a TIM card has the same form factor as a SIM card and is interchangeable therewith. Just like SIM cards, TIMs are preprogrammed with at least one unique identification number, the “International Mobile Subscriber Identity” (IMSI) which is accessible on the card. The TIM is however not associated with a publicly known number (i.e. a MSISDN). In this sense, the TIM is considered to be an “unprovisioned” SIM. 
         [0056]    As TIMs have no MSISDN associated with them, they can be used in environments where it is uncertain when any given TIM will be used or indeed whether that TIM will be used at all. This is commercially important in typical cellular networks where there is a cost associated with provisioning a SIM with a valid MSISDN and a further cost associated with quarantining and ultimately reassigning that MSISDN number when it is unused for a predetermined period (typically of the order of six to nine months). 
         [0057]    To handle the initial requests for a connection to the network, the network of  FIG. 2  A includes both a home location register (HLR)  10  (identical to that in the  FIG. 1  network) and a global HLR (G-HLR)  210 . 
         [0058]    In an alternative implementation, illustrated in  FIG. 2B , the base stations  3 , 4 , 5 , 7 , 8  and  9 ; MSCs  2 ,  6 ; VLRs  11 ,  14 ; and SGSNs of  FIG. 1  are linked to a global HLR (G-HLR)  210 , however no HLR  10  is required. 
         [0059]    When the user of the mobile terminal  1 ′ wishes to activate their mobile terminal in the network (so that it may open a data connection subsequently), the user places a TIM card in a card reader associated with the mobile terminal (terminal  1 ′ in  FIGS. 2A ,  2 B,  2 C and  2 D). The mobile terminal  1 ′ then connects to the radio network (step  201 ). 
         [0060]    As for  FIG. 1 , connection to the radio network in  FIG. 2  A amounts to a request from the TIM to access the appropriate location in the HLR  10  for the transmitted IMSI number from the appropriate storage location. The HLR  10  determines that the IMSI number provided by the TIM belongs to another register. The request for connection is then forwarded to the G-HLR  210  (step  202 ). The G-HLR  210  then extracts the IMSI number from this request and, assuming the IMSI number is in a range maintained by the G-HLR  210 , transmits a token signal to the HLR  10  (step  203 ) that the IMSI has been recognised by the G-HLR  210  (this token signal may simply be a confirmation signal (OK′) but it may include further profile information). 
         [0061]    Connection to the radio network in  FIG. 2B , by contrast, amounts to a request to access the appropriate home location in the VLR  14  for the transmitted IMSI number from the appropriate storage location. The VLR  14  determines, by IMSI number analysis, that the TIM belongs to another register. The request for connection is then forwarded to the G-HLR  210  (step  202 B). The G-HLR  210  then extracts the IMSI number from this request and, assuming the IMSI number is in a range maintained by the G-HLR  210 , transmits a token signal to the VLR  14  (step  203 B) that the IMSI has been recognised by the G-HLR  210  (this token signal may simply be a confirmation signal (OK′) but it may include further profile information). 
         [0062]    Likewise, connection to the radio network in  FIG. 2C , amounts to a request to access the appropriate home location in the SGSN for the transmitted IMSI number from the appropriate storage location. The SGSN determines, by IMSI number analysis, that the TIM belongs to another register. The request for connection is then forwarded to the G-HLR  210  (step  202 C). The G-HLR  210  then extracts the IMSI number from this request and, assuming the IMSI number is in a range maintained by the G-HLR  210 , transmits a token signal to the SGSN (step  203 C) that the IMSI has been recognised by the G-HLR  210  (this token signal may simply be a confirmation signal (OK′) but it may include further profile information). 
         [0063]      FIG. 2D  illustrates a different mechanism for handling such requests for connection to the radio network in which an SS7 aggregator point  290  (such as an SS7 Signalling Connection Control Part (SCCP) Relay or Signalling Transfer Point (STP)) is used to aggregate the SS7 functionality. In particular, the SS7 aggregator point may perform IMSI analysis (e.g. Global Title Translation (GTT) capabilities for the IMSI address type), eliminating the need to continually manage the routing tables within MSCs (Mobile Switching Centre) and/or the SGSN  220 . 
         [0064]    The HLR  10 , upon receipt of the token signal, stores the IMSI temporarily in a location in the visitor location register (VLR)  14 . In the  FIG. 2B  alternative, the VLR  14  stores the IMSI temporarily in a VLR location register store. In this way, therefore the user of the terminal  1 ′ is effectively registered with a particular MSC (MSC  2 ), and any profile information associated with the TIM is temporarily stored in the VLR (VLR  14 ) associated with that MSC. 
         [0065]    In the  FIG. 2C  alternative, the SGSN stores the IMSI temporarily in an SGSN location register store. The user of the terminal  1 ′ is then effectively registered with a particular SGSN (bypassing the VLR altogether), and any profile information associated with the TIM is temporarily stored in the SGSN location register store. 
         [0066]    Once the above steps have been completed, an authentication procedure is then performed for the mobile terminal  1 ′. For  FIGS. 2A and 2B , the G-HLR  210  transmits authentication data to the MSC  2  in “challenge” and “response” forms. Using this data, MSC  2  passes a “challenge” to the mobile terminal  1 ′ through base station  3 . Upon receipt of this data, the mobile terminal  1 ′ passes this data to its TIM and produces a “response”. This response is generated using an encryption algorithm on the TIM and a unique key, Ki′, on the TIM. The response is transmitted back to the MSC  2  which checks it against information that it has obtained for that token from the G-HLR  210  in order to complete the authentication process. If the response from the mobile terminal  1 ′ is as expected, the mobile terminal  1 ′ is deemed authenticated. 
         [0067]    For  FIG. 2C  too, the G-HLR  210  transmits authentication data to the SGSN  220  in “challenge” and “response” forms. Here, the SGSN  220  uses this data to pass a “challenge” to the mobile terminal  1 ′ through base station  3 . Upon receipt of this data, the mobile terminal  1 ′ passes this data to its TIM and produces a “response”. This response is generated using an encryption algorithm on the TIM and a unique key, Ki′, on the TIM. The response is transmitted back to the SGSN  220  which checks it against information that it has obtained for that token from the G-HLR  210  in order to complete the authentication process. If the response from the mobile terminal  1 ′ is as expected, the mobile terminal  1 ′ is deemed authenticated. 
         [0068]    As the reader will readily appreciate, the use of an SS7 aggregator point  290  to aggregate SS7 functionality (as illustrated in  FIG. 2D ) can be combined with the mechanisms for performing authentication described above whether the authentication is performed via MSC  2  or SGSN  220 . 
         [0069]    The authentication process will be repeated at regular intervals while the mobile terminal  1 ′ remains activated and can also be repeated each time the mobile terminal makes or receives a call, if required. 
         [0070]    When the user of mobile terminal  1 ′ wishes to establish a data connection, having already inserted the TIM card into the reader associated with this mobile terminal and the validity of the TIM has been confirmed by the G-HLR  210  in the manner described, the request for a data connection is passed to a network gateway component  220  (i.e. SGSN  16 ) and a gateway session is established. 
         [0071]    The network gateway component  220  receives from the G-HLR  210  a key corresponding to the IMSI. This key is used, in turn, to query a network monitoring component  230  (e.g. NGME, or GGSN) which determines whether the key data is associated with an existing, valid session (typically a native RADIUS and/or DIAMETER session). The signalling between the network gateway component  220  and the network monitoring component  230  is preferably zero-rated so that the user is not billed for the establishment of the session. 
         [0072]    If a valid session already does exist for this key data, the data connection is established (step  209 ). The mobile terminal  1 ′ has access to a requested internetwork  246 —typically the Internet or a corporate intranet. 
         [0073]    If however no valid session can be found that corresponds to the key, the mobile terminal  1 ′ may instead be redirected to a webpage generated by a web server  240 . The webpage presented is tailored to the mobile terminal  1 ′ in accordance with key data and offers the user at least one user action option. 
         [0074]    The network monitoring component  230  then acts as an internetwork gateway: denying or allowing access from the cellular network  100  to the requested internetwork  246  in dependence upon the information input by the user in relation to the selected user action option. In a typical scenario, the webpage offers the option of a time-limited session for a predetermined price. The selection of that option leads the user to a user dialog requesting user billing information, including for example: name, address, credit/debit card details, voucher/coupon information, existing phone no. to which to bill/SMS etc. 
         [0075]    Session control is provided by a session control server (preferably a native DIAMETER server). The session control server issues regular reports on the sessions it manages (so-called “event tickets”). In a native DIAMETER-based session, the network monitoring component  230  can use the DIAMETER event tickets for each valid session to monitor the session usage of each user. This may in turn be presented to the user through an application on the mobile terminal  1 ′, so that the user may see, for instance, that usage has exceeded a prearranged threshold value. Alternatively, session usage may in turn be presented to the user through a pop-up on a web application (e.g. browser) on the mobile terminal  1 ′. 
         [0076]    Since the reporting comes directly from the DIAMETER server rather than from a client-based (and inaccurate) counter application, the user is immediately presented with up-to-date session usage reporting. As the reader will appreciate this means that the user can avoid the phenomenon of “bill-shock” (when the tariff for a particular session is received (after some delay) and the user realises that the bill is a great deal higher than they understood it would be). 
         [0077]    There are many more benefits from using a client application on the terminal to present the usage information. For example the user could be provided with a facility to record itemised logs of their usage or to request a specific quality of service level (for which a different charge could be levied and that charge in turn be monitored by the user). The operator of a cellular network could also have more latitude in services: offering, for instance, dynamic, congestion-based, charging where the cost per unit of data can be varied in accordance with the degree of data usage on the network at that instant (which the user could in turn monitor through his/her client application). 
         [0078]    Clearly, the network monitoring component  230  can also use the DIAMETER event tickets for each valid session to monitor the session usage of groups of users (as might be required in providing services to a business or “enterprise”). This arrangement facilitates so-called “mediated billing” so that an enterprise can aggregate the bills for groups of enterprise users. Mediated billing may be effected by presenting information about monitored sessions to an administrator or agent for the enterprise through an enterprise monitoring and central billing application. 
         [0079]    The operation of the invention may be further understood by considering two more specific embodiments. The first embodiment, illustrated in  FIG. 3 , relates to the processing of a request for a data session from a laptop computer with an embedded TIM. The second embodiment, illustrated in  FIG. 4  concerns the processing of a request for a machine to machine data session from a machine to machine client with an embedded TIM. 
         [0080]    In  FIG. 3 , the network includes a SCP  302  and a global HLR (G-HLR)  310 . The mobile terminal  301  in this case is a laptop computer with an embedded TIM. The SCP  302  may subsume the functionality of the HLR  10  in the  FIG. 1  network (ensuring that connection to the radio network follows the mechanism set out in more detail in  FIG. 2A ). Alternatively the SCP  302  may subsume the functionality of a VLR  14  (facilitating the mechanism of  FIG. 2B ) and/or the functionality of an SGSN  220  (facilitating the mechanism of  FIG. 2C ). Clearly, the SCP  302  may also incorporate an SS7 aggregator  290  (such as an SCCP Relay) to aggregate the SS7 functionalities that would otherwise be required of the HLR  10 , VLR  14  and/or the SGSN  220 —thereby facilitating any one of the mechanisms represented in  FIG. 2D . 
         [0081]    When the user wishes to activate his laptop in the cellular network (so that it may open a data connection subsequently), the user “starts” a data connect application executing on the operating system of the laptop. The laptop  301  then connects to the radio network (step  351 ). 
         [0082]    As for  FIG. 1 , connection to the radio network in  FIG. 3  amounts to a request to access the appropriate location in the SCP  302  for the transmitted IMSI number from the appropriate storage location: no MSISDN has been associated with the IMSI number provided by the TIM. The SCP  302  determines that the IMSI number provided by the TIM belongs to another register. The request for connection is then redirected to the G-HLR  310  (step  352 ). The G-HLR  310  then extracts the IMSI number from this request and, assuming the IMSI number is in a range maintained by the G-HLR  310 , transmits a token signal to the SCP  302  (step  354 ) that the IMSI has been recognised by the G-HLR  310  (this token signal may simply be a confirmation signal (OK′) but it may include further profile information). 
         [0083]    The SCP  302 , upon receipt of the token signal, stores the IMSI temporarily (for instance in a VLR location register store or an SGSN location register store). In this way, therefore the user of the laptop  301  is effectively registered with a particular MSC or SGSN, and any profile information associated with the TIM is temporarily stored in the VLR  14  associated with that MSC  2  or SGSN  220 . 
         [0084]    The request for a data connection is passed by the SCP  302  to a network gateway component  320  (i.e. SGSN  16 ). The network gateway component  320  receives from the G-HLR  310  a key corresponding to the IMSI (step  356 ). Taking the key, together with the forwarded request for a data connection, network gateway component  320  establishes a gateway session. This key is used, in turn, to query a network monitoring component  330  (e.g. NGME, or GGSN) which determines whether the key data is associated with an existing, valid session (typically a native DIAMETER session). The signalling (step  358 ) between the network gateway component  320  and the network monitoring component  330  is preferably zero-rated so that the user is not billed for the establishment of the session. 
         [0085]    If a valid session already does exist for this key data, the data connection is established (step  362 ). The laptop  301  has access to a requested internetwork  346 -typically the Internet or a corporate intranet. 
         [0086]    If however no valid session can be found that corresponds to the key, the laptop  301  may instead be redirected to a webpage generated by a web server  340  (step  364 ). The webpage presented is tailored to the laptop  301  in accordance with key data and offers the user at least one user action option. 
         [0087]    In this case, the web server offers a “landing page” with access to a payment portal—allowing the user to purchase either a time/data limited session package or to initiate an application for a contract payment relationship with the network operator. 
         [0088]    The user is prompted to provide personal details including their credit card details to facilitate the establishment of a data session for a predetermined price (step  366 ). 
         [0089]    The user data is sent to an application server  350 . This server in turn processes the credit card details of the user for authentication at a credit card server  360 . Assuming the credit card details are authenticated, the credit card server  360  signals that fact (step  372 ) back to the application server  350 . 
         [0090]    The application server  350 , now that it has authenticated credit card details for the user signals to a DIAMETER server  370  that a DIAMETER session should be initiated for this user (step  374 ). The DIAMETER SERVER in turn signals to the network monitoring component  330  that a session should be opened (step  376 ). 
         [0091]    The network monitoring component  330  then redirects the user to the internet (step  378 ) and simultaneously changes the billing status of the user from zero rated to a data rate. 
         [0092]    As the DIAMETER server  370  provides “tickets” showing session usage, this information is pushed to a notification server  380  (step  382 ). The notification server may either send prearranged updates as to the percentage (or absolute) usage or may respond to user (or client application) queries as to current usage status. In a preferred implementation, the notification server creates an RSS feed for each session, thereby allowing the user&#39;s laptop to monitor status using a conventional HTTP port (port  80 ) and avoiding any need for a customisation to the user&#39;s firewall software. 
         [0093]    At the end of a prearranged session, the DIAMETER server  370  instructs the network monitoring component  330  to place the session on hold (and zero-rates the session). It also pushes a usage alert to the user via the notification server  380 . 
         [0094]    If the session ended because credit had expired the user need only repeat the process of requesting a further session from the landing page. 
         [0095]    In a preferred implementation, the webpage presented to the laptop  301  offers the user a further action option of requesting that the current session-based relationship mediated by the TIM should be converted to a contract-based relationship (i.e. a so-called postpay contract). To meet this request, the network operator may simply order up and send a conventional “provisioned” SIM card to the user so that the user may physically swap the TIM out of (and the new SIM card into) the laptop&#39;s card reader. Thereafter, access to data sessions would go through the conventional event flow outlined in relation to  FIG. 1 . 
         [0096]    As the reader will appreciate, there are alternative mechanisms for facilitating a swap from the TIM-enabled sessions to conventional contract data session access. The IMSI held by the TIM could, for instance, be provisioned on a given network operator&#39;s network (i.e. an MSISDN number may be associated with the IMSI). Indeed a plurality of MSISDN numbers could be provisioned to the TIM as might be necessary to effect the prior art “prefitted” SIM scenario mentioned above. 
         [0097]    In this case, the web server offers a “landing page” with access to a payment portal—allowing the user to purchase either a time/data limited session package or to initiate an application for a contract payment relationship with the network operator. 
         [0098]    The second embodiment, illustrated in  FIG. 4 , relates to a machine to machine implementation of the invention. The illustrated network includes a SCP  402  and a global HLR (G-HLR)  410 . The terminal  401  in this case is a machine to machine (M2M) client (note that this terminal is not strictly “mobile” in many, cases—the terminal being installed at a single geographic location from which it is not typically moved) with an embedded TIM. 
         [0099]    The SCP  402  may subsume the functionality of the HLR  10  in the  FIG. 1  network (ensuring that connection to the radio network follows the mechanism set out in more detail in  FIG. 2A ). Alternatively the SCP  402  may subsume the functionality of a VLR  14  (facilitating the mechanism of  FIG. 2B ) and/or the functionality of an SGSN  220  (facilitating the mechanism of  FIG. 2C ). Clearly, the SCP  402  may also incorporate an SS7 aggregator  290  (such as an SCCP Relay) to aggregate the SS7 functionalities that would otherwise be required of the HLR  10 , VLR  14  and/or the SGSN  220 —thereby facilitating any one of the mechanisms represented in  FIG. 2D . 
         [0100]    When the M2M client  401  requires to be activated in the cellular network (so that it may open a data connection subsequently), the client “starts” a data connect application executing on its operating system, typically in response to a trigger event. The M2M client  401  then connects to the radio network (step  450 ). 
         [0101]    As for  FIG. 1 , connection to the radio network in  FIG. 4  amounts to a request to access the appropriate location in the SCP  402  for the transmitted IMSI number and to extract the corresponding subscriber MSISDN from the appropriate storage location. Since no MSISDN has been associated with the IMSI number provided by the TIM, the SCP  402  determines that the IMSI number provided by the TIM belongs to another register. The request for connection is then redirected to the G-HLR  410  (step  452 ). The G-HLR  410  then extracts the IMSI number from this request and, assuming the IMSI number is in a range maintained by the G-HLR  410 , transmits a token signal to the SCP  402  (step  454 ) that the IMSI has been recognised by the G-HLR  410  (this token signal may simply be a confirmation signal (OK′) but it may include further profile information). 
         [0102]    The SCP  402 , upon receipt of the token signal, stores the IMSI temporarily in a location in the visitor location register (VLR) (not shown). In this way, therefore the M2M client  401  is effectively registered with a particular MSC (not shown), and any profile information associated with the TIM is temporarily stored in the VLR associated with that MSC. 
         [0103]    The request for a data connection is passed by the SCP  402  to a network gateway component  420  (i.e. SGSN  16 ). The network gateway component  420  receives from the G-HLR  410  a key corresponding to the IMSI (step  456 ). Taking the key, together with the forwarded request for a data connection, network gateway component  320  establishes a gateway session. This key is used, in turn, to query a network monitoring component  430  (e.g. NGME or GGSN) which determines whether the key data is associated with an existing, valid session (typically a native DIAMETER session). The signalling (step  458 ) between the network gateway component  420  and the network monitoring component  430  is preferably zero-rated so that the client device  401  is not billed for the establishment of the session. 
         [0104]    Assuming that no valid session corresponding to that key exists, the network monitoring component  430  interfaces with a DIAMETER server  440  to authenticate a new M2M data session (step  462 ) for the M2M client  401 . 
         [0105]    The DIAMETER server  440  in turn signals to the network monitoring component  430  that a session should be opened (step  464 ). 
         [0106]    The network monitoring component  430  then redirects the user to a requested M2M server  450  via a fixed-line network such as the internet  470  (step  466 ) and simultaneously changes the billing status of the M2M client session from zero rated to a data rate. 
         [0107]    At the end of a prearranged session, the DIAMETER server  440  instructs the network monitoring component  430  to place the session on hold (and zero-rates the session). 
         [0108]    The DIAMETER server  440  also pushes a usage alert (using DIAMETER tickets, step  468 ) to a billing mediation engine  480 , which generates a billing event corresponding to the reported session usage. 
         [0109]    As described in further detail in co-pending UK patent application GB 0815200.1, the M2M client sends and receives short text messages (SMS) to a dedicated M2M SMS platform  495 . These SMS messages are transported in a conventional manner through an SMS Gateway  490  and then across an internet connection  470  to the M2M SMS platform  495 . 
         [0110]    The SMS gateway  490  also passes data relating to the transferred SMS messages to the mediation engine  480  to allow billing for this messaging. 
         [0111]    While terminals are often referred to as “mobile” in the preceding discussion the term “mobile” should not be construed to require that a terminal always be mobile, merely that it has the capability of being in communication with a wireless telecommunications network which allows mobility. For instance, a PC terminal or an M2M client that is never moved from a particular geographic location may in this sense still be considered mobile as it could be moved to a different location yet still access the same network. Where the term “mobile terminal” is used in the present discussion it is to be read as including the possibility of a terminal that is “semi-permanent” or even “fixed” where the context does not contradict such an interpretation.