Abstract:
An efficient and easily user-modified fixing of the conditions, under which the positional data of the user may be transmitted ( 8   b ) to a poller ( 11 ) is made possible by means of a method for polling the concordance of a user of a mobile radio terminal ( 13  in a mobile radio network, to the transmission ( 8   b ) of the positional data thereof to a poller ( 11 ), whereby in the case of a poll ( 1 ) by a poller ( 11 ) for the position ( 5 ) of the mobile radio, terminal ( 13 ), the poll data is supplemented according to a preset specification ( 20  or  21  or  22  or  23 ) for said poller ( 11 ), before a transmission ( 2   c ) of the polled data from the poll ( 1 ) to an exchange ( 14 ) in the mobile radio network ( 14, 16 , ( 12 ), on the basis of which ( 20  to  23 ) it may at least be determined ( 14 ) whether a concordance on the part of the mobile radio terminal ( 13 ) for the transmission ( 8   b ) of the mobile radio terminal position to the poller ( 11 ) will be obtained. At least when the specification ( 20  to  23 ) determines that the concordance will be obtained ( 22, 23 ), a request ( 3 ) for explanation of the concordance is sent from the exchange ( 14 ) to the mobile radio terminal ( 13 ). For a transmission ( 8   b ) of the position of the terminal ( 13 ) to the poller ( 11 ), whether said position should be sent ( 8   b ) to said poller ( 11 ) is checked at least by means of given stored conditions ( 16, 18 )

Description:
CLAIM FOR PRIORITY  
       [0001]     This application claims priority to International Application No. PCT/DE01/04458 which was published in the German language on Jun. 12, 2003, and filed in the German language on Nov. 27, 2001, the contents of which are hereby incorporated by reference. 
     
    
     TECHNICAL FIELD OF THE INVENTION  
       [0002]     The invention relates to positional data recording, and in particular, to a method and system for polling the concordance of a mobile radio terminal user for the transmission of positional data to a poller.  
       BACKGROUND OF THE INVENTION  
       [0003]     Document WO 98/52379 describes the determination of the geographical location of a mobile station in a mobile communications network. The intention is to protect the integrity of a mobile station user and to prevent the location of a mobile station becoming known against the will of the user. For this purpose an authorization check is performed in conjunction with an inquiry to determine the geographical location of a mobile station. The geographical location is only determined if authorization is present for the mobile station to be determined. Said authorization check includes verification of whether a mobile station user has given consent for the location of his mobile station to be determined. The authorization check also includes that only certain third parties are informed of the geographical location of a mobile station.  
         [0004]     Document WO 99/63780 describes a method in a telecommunications system for administering location services by using black and gray location application lists and a position gateway. When a location application subscribes to a location service, the service provider assigns to the location application a unique location application identifier number (LAIN) which is included in every position inquiry. The black list is used to bar services to location applications included in the list, while maintaining the location application profile of the location application in a position gateway. Location applications included in the gray list have access to a service, but the latter is monitored by a network unit.  
         [0005]     It is known from 3GPP-TS 23.271 to use positional data of a mobile radio terminal user of a cellular mobile radio network for location-based services such as information about the nearest service station, etc. (“location services”=LCS). However, in some circumstances a mobile radio terminal user would wish to prevent every third party being able to obtain his current position from the mobile radio network. The mobile radio terminal user consequently requires a function which defines for every potential poller of his position from the mobile radio network whether notification of the positional data of the mobile radio terminal user to said poller is generally permitted, generally barred, or may be permitted following verification from the mobile radio terminal user. This function is referred to as the LCS user privacy function.  
         [0006]     The LCS user privacy defined by 3GPP (3GPP standards TS 23.271 and TS 29.002) requires a relatively large amount of memory in the home location register (HLR) of the mobile radio network and in the exchange (MSC-SGSN), and creates a high load when copying conditions relating to the transmission of positional data of a user to a poller from the HLR to the exchange currently being used by the user (visited MSC/SGSN).  
         [0007]     According to 3GPP standards TS  23 . 271  and TS  29 . 002 , the LCS user privacy is stored for every subscriber in a home location register (HLR) in a plurality of privacy classes and is downloaded from the HLR to the MSC or SGSN visited by the user, whereupon an LCS user privacy function checks whether, in the case of an inquiry about the position of the mobile radio terminal (mobile terminating location request MT-LR) from a GMLC, positional data is to be transmitted to the poller. LCS privacy classes are provided for value added services, namely the call session-related class and the call session-unrelated class. In 3GPP the user can specify for each of these two classes up to 40 LCS client IDs, and for each client ID (identities of potential pollers seeking the position of the user) can define specifications relating to how the MSCs/SGSNs visited by the user are to perform the LCS user privacy check. For example it is possible to specify that the user only receives an LCS notification (that is to say a notification that someone is inquiring about his position) or that the user receives an LCS verification (that is to say a query to obtain consent from the user before transmitting his position to a poller), as well as other possibilities. If an LCS client ID is not stored in a list specified by the user, a default behavior as stipulated by the user is executed.  
       SUMMARY OF THE INVENTION  
       [0008]     The present invention enables a user of a mobile radio network to make specifications relating to inquiries about his position as simply and efficiently as possible. In one embodiment according to the invention, on the arrival of an inquiry from a poller at a positional data request gateway (GMLC), prior to forwarding the inquiry to the exchange (MSC, SGSN) of the mobile radio network currently being visited by the mobile radio terminal, the polling data is supplemented by a specification which indicates at least whether consent of the mobile radio terminal user is obtained for forwarding the mobile radio terminal position to said poller, the equipping of the positional data request gateway GMLC of the mobile radio network with a file that can be modified by the user is enabled, which file indicates for any inquiries whether consent is obtained before positional data is transmitted, and optionally at what time and/or for which positions transmission of positional data to the poller is permitted by the user. An increased load as a result of downloading such specifications from the home location register into an exchange MSC/SGSN can consequently be substantially reduced because it is only necessary for virtual identities in the form of a limited number of specifications to be notified to an MSC by the HLR, whether the user is consulted before transmission of his positional data, and what should happen if he does not respond to this. According to one aspect according to the invention, the specifications in the positional data request gateway (POSITIONAL DATA REQUEST GATEWAY) relating to whether a user is consulted before transmission of his positional data and what should be done if he does not respond, or if he is to be notified, or whether positional data information can be passed to the poller without notification and verification, can be changed by the user simply by means of mobile radio (voice or SMS, etc.) or WAP or Internet etc., and can be linked to additional conditions (attributes, such as time-dependent or location-dependent ones), which was not possible with hitherto customary storing in the HLR. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0009]     Further features and advantages of the invention emerge from the description of exemplary embodiments below with reference to the drawings, in which:  
         [0010]      FIG. 1  shows a positional data poll according to 3GPP R4.  
         [0011]      FIG. 2  shows a variation of the positional data poll according to the invention. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0012]     In  FIG. 1 , an inquiry  1  is sent from a positional data application (LCS application)  11  to a positional data request gateway (GMLC)  12 , which in step  2  forwards the positional data inquiry to an exchange (SGSN/MSC etc.)  14  currently visited by the user of the mobile radio terminal (MS)  13 . The exchange SGSN/MSC  14  has (e.g. regularly) stored in a step  0  specifications downloaded from an HLR about mobile radio terminal users which stipulate whether it is necessary to check back with the mobile radio terminal  13  before transmitting the position of the mobile radio terminal to the poller  11 . If such a verification is prescribed, in step  3  the exchange  14  interrogates the mobile radio terminal  13  as to whether the user of the mobile radio terminal  13  wishes to notify the current mobile radio terminal position to the poller  11  for the current inquiry of the poller. In reply to this, either a response  4  can be sent from the mobile radio terminal to the exchange  14 , or in some circumstances no response is sent if, for example, the mobile radio terminal is not being used, is switched off or is located in a radio blackspot. If transmission of the position of the mobile radio terminal to the poller  11  is permitted, or if alternatively it is permitted after consent  4  has been sought and consent has been given, or if alternatively it is specified that the position should be transmitted if a refusal of consent is not received, the position can be transmitted from the exchange  14  to the poller  11 . In step  5  the exchange  14  queries in a RAN of a 3G network or a BSS of a 2G network etc. the position of the mobile radio terminal  13  (for example on the basis of the cell identity of the mobile radio cell currently being used by the mobile radio terminal  13 ), and in return in step  6  receives the current mobile radio terminal position. If the position is to be transmitted to the poller  11 , the transmission station  14  transmits the data representing the position to the positional data request gateway GMLC  12  in step  7 ; in step  8  said gateway forwards the data without further conditions to the poller  11  (if appropriate also indicating the age of the positional data, insofar as the age was determined by the positional data identification station RAN/BSS  15 ).  
         [0013]      FIG. 2  shows a recording of the position according to the invention and forwarding to the poller in accordance with the conditions stipulated by the mobile radio terminal user:  
         [0014]     It is possible to use here a mobile radio network according to the 3GPP R 4 standard without infringing the standard, so that upward compatibility is possible to a large extent.  
         [0015]     As also in the solution illustrated in  FIG. 1 , on request or regularly in step  0  for a multiplicity of mobile radio terminal users, a set of specifications is transmitted from a home location register of the mobile radio network HLR  16  to (on request) the exchange SGSN/MSC  14  currently used by the mobile radio terminal user or (in the case of regular transmission) to the exchanges, which specifications however in this case indicate which instructions relating to queries to obtain consent are to be executed in the mobile station  13  by the exchange  14  for which of the (here virtual) poller identity data notified to the exchange  14  in inquiries relating to the position. According to the invention, this is a limited number of specifications (for a limited number of virtual identities), in the present example shown in  FIG. 4  it is 4 specifications for 4 (virtual) identities. Since the specifications  20 ,  21 ,  22 ,  23  can be the same for a multiplicity of users of mobile radio terminals, because they do not include decisions of the users about specific pollers, but general instructions for 4 different cases, the network load between HLR  16  and exchange MSC/SGSN  14  can be substantially reduced. Moreover, the number of specifications here is very low in comparison with the possible number of up to 80 specifications (for up to 80 different pollers) per mobile station according to the 3GPP standard, which further substantially reduces the network load traffic between HLR and exchange  14 .  
         [0016]     In the present example 5 different cases are provided, with storage being required in the exchange  14  only for 4 different cases: This is possible because, prior to forwarding inquiries of a poller  11  to the exchange  14 , the positional data request gateway GMLC  12  substitutes in the polling data of the inquiry, at the position at which the identify of the poller  11  is usually present, a virtual identity  20 ,  21 ,  22  or  23  in accordance with tables  18  stored in the positional data request gateway GMLC  12  or available to the latter, in which tables it is specified for each user of a mobile station  13  (or for its MSISDN, IMSI, etc.) how to respond to each poller  11 . As a result, instead of the identity of the poller  11 , a virtual identity  20  to  23  arrives at the exchange  14 , for which identity instructions were or will be loaded from the home location register HLR  16  into the exchange  14 , and in accordance with the instructions in the standard way either an inquiry is sent to the mobile station  13  to obtain consent to transmit its position to the poller  11  or not, and a default specification is provided for the case where no response is obtained.  
         [0017]     The identity of the poller is transmitted in the positional data request gateway GMLC  12  by one of the 5 following (virtual) identities (which now only represent the instructions and no longer the identity of the poller  11 ) to the exchange  14 :  
         [0018]     Client ID  1 : (virtual identity  1 ) notify positional data without notifying the mobile station  13  (which means that in the event of an inquiry the position of the mobile station  13  will be transmitted to the poller  11  without notifying the mobile station  13 );  
         [0019]     Client ID  2  (virtual identity  2 ): notify (which means that in the event of an inquiry from the poller  11 , the latter will be transmitted the position of the mobile station  13 , but the mobile station  13  will be informed of this);  
         [0020]     Client ID  3  (virtual identity  3 ): in accordance with an instruction that the mobile station  13  is to be asked whether the position of the mobile station  13  is to be transmitted to the poller  11 , whereby the position is transmitted to the poller  11  if the mobile station either responds positively or does not respond at all (because it is switched off, etc.).  
         [0021]     Client ID  4  (virtual identity  4 ): instruction to the exchange  14  to the effect that, prior to transmitting to the poller  11  the position of the mobile station  13 , the latter is asked for consent, and the position of the mobile station  13  is only transmitted if a response  4  comes from the mobile station  13  and if that response is positive.  
         [0022]     For the fifth possibility, namely that positional data recording for the mobile station  13  is never permitted for the poller  11 , nothing need be stored in the home location register  16  and in the exchange  14  because in this case the positional data request gateway GMLC  12  can notify the rejection of positional data recording to the poller  11  without verification from the exchange  14 .  
         [0023]     During the notification of the mobile station  13  and during the request for consent to transmit the positional data in the mobile station  13  in step  3 , the latter is notified, for example (as standard), the name of the poller  11 , so that the user of the mobile station  13  knows who is sending the inquiry.  
         [0024]     The allocation of the specifications  20  to  23  (=virtual identities which reference only instructions) is thus known to the HLR  16  (which notifies it to the exchange  14  visited by the mobile station  13 ), and to the positional data request gateway GMLC  12 . If a positional data request gateway GMLC  12  receives an inquiry  1  of a poller  11 , prior to forwarding  2   c , virtual identity data  20  or  21  or  22  or  23  is substituted for the received identity data (client ID) of the poller  11  on the basis of an allocation table (mapping table)  17  containing the mappings of identity data to the virtual identities  20  to  23  specified by the user of the mobile station  13 . If necessary, the table can be supplemented by extended attributes, such as temporal or geographical restrictions or dependencies on expanded specifications about or from the poller  11 .  
         [0025]     The above method according to the invention can be implemented easily and efficiently without conflicting with the 3GPP standard.  
         [0026]     Alternatively, the following method can be used: The specifications  20  to  23  (virtual identities client ID  1  to  4 ) are also stored as above in the HLR  16  and in a positional data request gateway GMLC  12 .  
         [0027]     Before this alternative method (=method II) is applied, it is checked by the positional data request gateway GMLC  12  whether the exchange MSC/SGSN  14  is able to used method II. This can be the case in particular if the exchange MSC/SGSN  14  is located in the same network as the positional data request gateway GMLC  12  or in a network comparable with the positional data request gateway GMLC  12  or is stored in a special list. If this is the case, in step  2 c in  FIG. 2  the identity (LCS client ID) of the poller  11  co-transmitted from the poller  11  in the inquiry in step  1  is transmitted from the positional data request gateway GMLC  12  with the position inquiry to the exchange SGSN/MSC  14  in an “extension container” (extension container according to 3GPP standard TS 29.002) or in an extension container in the “LCS client external ID” or in the “LCS client dialed by MS” etc. The exchange SGSN/MSC  14  executes the checks as described above, but before transmitting the notification or inquiry to obtain consent to the mobile station it checks whether the positional data request gateway GMLC  12  supports method II. If method II is supported by the positional data request gateway GMLC  12 , prior to the inquiry  3  in the mobile station  13  with respect to consent or notification, the exchange SGSN/MSC  14  substitutes the actual LCS client ID of the poller  11  transmitted in the extension container for the specification  20 / 21 / 22 / 23  (virtual identity) in the polling data. Where the actual LCS client ID of the poller  11  is to be found can be provided or notified in individual cases.  
         [0028]     The procedure according to the invention of the first method above can thus be as follows:  
         [0029]     In step  0  a list of instructions  20  to  23  for particular inquiries is transmitted on request or regularly from the home location register HLR  16  to the exchange SGSN/MSC  14  for each mobile station  13 , wherein in the instructions  20  to  23  the poller identities client ID 1  to client ID 4  are only virtual identities for referencing the associated instructions.  
         [0030]     Step 1: Transmission of an LCS service request from an LCS client (inquiries of  11 ) to a positional data request gateway GMLC  12  and the transmission of required and optional data (client ID, IMSI/MSISDN, QoS) for this purpose.  
         [0031]     Step 2a: The positional data request gateway GMLC  12  checks which specification  20  to  23  is to be transmitted in step 2c instead of the identity of the poller  11  in the inquiry  1  (client ID) for the poller (client ID) specified in the inquiry  1  and for the mobile radio subscriber identity module of the mobile station  13  (IMSI/MSISDN) defined in the inquiry  1  to the exchange MSC/SGSN  14 . Prior to the inquiry  2 C it can be checked here at what times or, after the response  7 , in what region the user of the mobile station  13  has permitted for a specific user (with IMSI/MSISDN etc. according to the inquiry  1 ) and for a special poller  11  (according to the client ID in the inquiry  1 ) polling of the positional data with or without verification  3 , and if appropriate the method with steps 2c to 7 is continued only in the positive case, and otherwise a rejection of the position inquiry is transmitted in step 8.  
         [0032]     Step 2b: The identity (client ID) of the poller  11  transmitted in inquiry  1  is stored together with a transaction identity (MAP reference) allocated to the inquiry 2c in an allocation table (mapping table  17 ) in order to be able to allocate a response  7  containing the same transaction identity as the forwarding 2c to the poller  11  again.  
         [0033]     Step 2c: An inquiry with a specification  20  or  21  or  22  or  23  is transmitted from the positional data request gateway GMLC  12  to an exchange  14  currently being visited by the mobile station  3  (according to the HLR specification etc.). Steps 3 to 7 follow as described for  FIG. 1 , wherein, however, the exchange SGSN/MSC  14  from the HLR 16  for the mobile station  13  specified (IMSI/MSISDN etc.) in the inquiry  1  the specifications  20  to  23  which are the same for a multiplicity of mobile stations with associated instructions (transmit positional data without notification, transmit positional data with notification to the mobile station, ask mobile station for permission before transmitting positional data and transmit if the response is positive or no response is received, ask mobile station before transmitting positional data and transmit if a positive response is received).  
         [0034]     Step 8a: In contrast to the above method, after receiving a response  7  (comprising positional data and possibly the age of the recording and transaction identity), the positional data request gateway GMLC  12  substitutes the identity of the poller  11  for the received transaction identity on the basis of the allocation table  17  and possibly also asks for any geographical specifications of the user  13  in the specifications list  18 , and in step 8b transmits the positional data (where this was permitted) or a rejection of positional data recording to the poller  11 .  
         [0035]     The geographical specifications requested, before transmission of the positional data to the poller  11 , by the positional data request gateway GMLC  12  from an LCS privacy database  18  for the location determined (by the RAN/BSS  15 ) comprise, for example, that in the case of visits by the user of the mobile station  13  in particular groups of cell identities etc. (which the user has previously defined in some form or other) should not be performed. In addition, it can be additionally checked here whether the position should be notified to the poller  11  at the current time, wherein the position is transmitted to the poller, for example, for positional data determined during a predetermined period of time.