Abstract:
A Location Server receives requests for subscribers that are within an Alert Area to enable notifications/alerts to be sent to the subscribers from an Alert Application. The Location Server extracts the location information by performing a search in a Database for subscribers that are located in the Alert Area. The quality of the locations in the database is dependent of the frequency with which a Core Network sends passive location data to the Location Server at network events when the Mobile Station is in contact with the network. The Location Server reconfigures the Core Network and Radio Access Network to send the information when it is needed. An advantage of the invention is that it is possible to provide services that require knowing which subscribers are currently located in a specific area in a flexible way without over loading the mobile network.

Description:
FIELD OF INVENTION 
       [0001]    The present invention relates to subscriber notifications and more particularly to a method and apparatus for mobile subscriber alert notifications. 
       BACKGROUND 
       [0002]    There exists various occasions when there is a need to alert and/or notify individuals. In some situations it is also preferred to be able to notify only individuals being present in a specified geographical area. The alert can be a warning for a bush fire, traffic guidance, advertisement etc. but can also be useful for geo-fencing and territorial monitoring. 
         [0003]    Mobile communication systems and the mobile terminals is one example of a system that can be used for such notifications. 
         [0004]    In the Global Systems for Mobile communication (GSM) standard, there is a service defined called Short Message Service (SMS) Cell Broadcast, which provides an information supplier with the possibility of broadcasting a message to the GSM users within a certain geographical region, see GSM Technical Specification (TS) 03.02. The geographical region in which a SMS Cell Broadcast message is broadcast is defined on a per message basis and can include one or more cells, or even an entire Public Land Mobile Network (PLMN). An SMS Cell Broadcast message is broadcast cyclically by the Base Transceiver Stations (BTSs) in the defined geographical region at a frequency and duration specified by the information supplier. 
         [0005]    Cell broadcast can be used to inform all subscribers connected to a cell of a specific mobile operator via Short Message Service SMS about something important in the particular location. 
         [0006]    A drawbacks with the cell broadcast solution is that accuracy is limited to cell accuracy. Further, the same information is broadcasted to all subscribers. It is also a drawback that a mobile network does not know who are in the particular location, for example temporary out of coverage, so it is not possible to follow up if the subscriber got the notification. Cell broadcast also has several limitations in terms of functionality. 
         [0007]    The applicants patent application WO 98/08350 describes a method and system for selectively broadcasting a message to mobile stations traveling within a particular geographic area within a serving mobile switching center (MSC) coverage area. The message is transmitted using for example short message service (SMS) messages to each of the mobile stations determined to be located within the specified geographic area. The determination of to which mobile stations to send the message is done by querying a visiting location register (VLR). 
         [0008]    A drawback with WO 98/08350 is that the accuracy, e.g. the age, of the information accessible in the VLR is not sufficient. 
         [0009]    WO 00/54524 describes a service by which suppliers of general information can supply general information to the mobile radio network users in a certain geographical area, without the users having to set their mobile stations in the mode for receiving such information. 
         [0010]    The service comprises registering a general information message in a general information message register in the mobile radio network including registering an identification of served area. When receiving a location update message from the mobile station the identification of served area is comparing with the information of the location of said mobile station included in the location update message. It is determined whether the general information message should be sent to the mobile station based on the result of the comparison and the general information message is sent to the mobile station if it is determined that the general information message should be sent. 
         [0011]    A problem with the invention according to WO 00/54524 is that it is the mobile station that initiates the sending of information. Thus, although the subscriber location in the mobile network is known by the location update information the method is not suitable for alert notifications where it is important to be able to distribute the information urgently to a plurality of mobile stations since awaiting the mobiles updating their location is not acceptable. 
       SUMMARY OF INVENTION 
       [0012]    Earlier technology suffers from presenting solutions for efficiently finding which mobile stations are located in a specific geographical area such that alert notifications can be adequately communicated to a plurality of subscribers within the area. The present invention relates to the problem of providing an improved apparatus and method for mobile subscriber alert notification whereas the above mentioned drawbacks are avoided. 
         [0013]    This problem is solved by a method and apparatus for mobile subscriber alert notification. A location server receives a request for subscribers within an alert area from an alert application and receives subscriber locations from at least one network node. The location server stores received subscriber locations in a location database and checks received and/or stored subscriber location data for subscribers located within the alert area. If so the location server informs the alert application about such subscribers. 
         [0014]    An advantage of the invention is that it is possible to provide services that require knowing which subscribers are currently located in a specific area in a flexible way without over loading the mobile network. 
         [0015]    The purpose with the invention is to provide a method and apparatus for efficiently finding which mobile stations are located in a specific geographical area for mobile subscriber alert notification. 
         [0016]    Preferred embodiments of the invention will now be described in more detail with reference to the enclosed drawings. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0017]      FIG. 1  is a block diagram showing an architecture overview of a spatial trigger system according to the prior art. 
           [0018]      FIG. 2  is a block diagram showing an architecture overview of an alert system according to the invention. 
           [0019]      FIG. 3  is a block diagram showing a Location Server according to the invention. 
           [0020]      FIG. 4   a  is a block diagram showing a Location Server, and signals between other network elements of the alert system. 
           [0021]      FIG. 4   b  is a flow chart showing the method of the Location Server in  FIG. 4   a.    
           [0022]      FIG. 5   a  is a block diagram showing an embodiment of the Location Server in  FIG. 4  in more detail. 
           [0023]      FIG. 5   b  is a flow chart showing the method of the Location Server if  FIG. 5   a.    
           [0024]      FIG. 6  is a signal diagram showing another embodiment of a Location Server according to the invention. 
           [0025]      FIG. 7   a  is a block diagram showing an embodiment of the Location Server in  FIG. 4  in more detail. 
           [0026]      FIG. 7   b  is a flow chart showing the method of the Location Server if  FIG. 7   a  in more detail. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0027]      FIG. 1  is a block diagram showing an architecture overview of a spatial trigger system according to the prior art. 
         [0028]    The services that spatial triggers enable are services that are dependent on how a subscriber moves. A couple of examples are:
       Inform a service when a subscriber enters an area   Inform a service when a subscriber leaves an area   Inform a service when two subscribers are getting close to each other.       
 
         [0032]    Location based/trigger applications  110  request a Location Server  120  (Location Server LS terminology according to OMA and Gateway Mobile Location Centre GMLC is the term used by 3GPP) to get informed when a specific subscriber enters/leaves an area or getting close to another specific subscriber. 
         [0033]    The OMA standardized Mobile Location Protocol MLP is used as application interface  115  between the trigger applications  110  and the Location Server  120 . 
         [0034]    The Location Server is responsible for updating a Location Database DB  130 , which can be stand alone or co-located with the LS, with subscriber locations received from other nodes in the mobile network. The Location Server is also responsible for checking the different criterion and inform the trigger application when a criteria is fulfilled. The quality of the locations in the DB  130  is dependent of the update frequency of the subscriber locations. 
         [0035]    A Core Network CN  140  sends passive data to the Location Server when the Mobile Station MS  160  is in contact with the mobile net  100  via cells  170  managed by the Radio Access Network RAN  170 . Examples of this are network events such as when subscriber sending SMS, making a call, location area update and periodic location update. The passive data include MS identity and location information. 
         [0036]      FIG. 2  is a block diagram showing an architecture overview of an alert system according to the invention. 
         [0037]    An alert application  210  request the Location Server  120  for subscribers that are within an area  220  by using MLP. Notification/alert is sent to the subscribers by the application. Since the alert application and location server/location database may use different representation of the geographical area it is not required that the area requested from the alert application and the area identified by the location server/location database is strictly identical. The application notifies the subscriber according to the customers need via either SMS  212 , MMS  214 , Voice  216  or by other methods. 
         [0038]    The Location Server is responsible for an initial searching in the DB for all subscribers that are located in the alert area  220 . It is also responsible for updating the DB with subscriber locations received from other nodes in the mobile network. The quality of the locations in the DB is dependent of the update frequency. The Location Server is also responsible for the optimized signaling flow described below. 
         [0039]    The CN  140  sends passive data to the Location Server when the MS is in contact with the mobile net  100 . Examples of this are network events such as subscriber sending SMS, making a call, location area update and periodic location update. The passive data include MS id and location information. 
         [0040]    The solution to the problem is to reconfigure the CN and RAN to just send the information when it is needed, and also extract the location information as quickly as possible for the mobile network. 
         [0041]      FIG. 3  is a block diagram showing a Location Server  120  according to the invention having a processor  360  and a memory  370  having instructions accessible from the memory and processable by said processor. 
         [0042]    The Location server contains several functional blocks with different responsibilities. 
         [0043]    An Application Handler  310  is responsible for all communication with the Alert Application  210 . It performs syntax control, decoding, authentication and authorization. 
         [0044]    A Location Server LS Core  320  is the message mediator, and correlates all signaling toward a Core Network CN  140  and RAN  150 . 
         [0045]    The DB  130  is the location data storage for all subscribers as well as a specification of the served geographical area such as geographical information about cell structure. 
         [0046]    A CN configurator  330  communicates with CN to switch on/off the passive data flow. 
         [0047]    An Event Handler  340  receives passive data events from the core network  140  and the radio access network  150 . The most important event is the Periodic Location Update PLU event that is a periodic registration event that occurs regularly according to a setting in the RAN. The PLU time can vary between several hours and part of an hour. Examples of other events are: Voice calls, SMS, Normal Location updates, IMSI/GPRS attach/detach, IMSI attach/detach and SS. 
         [0048]    A RAN configurator  350  communicates with the RAN to reconfigure the PLU timer. LS  320  starts with requesting the PLU timer from the RAN  150  to make it possible to revert to the original value when the supervision period has passed. The LS sets a new very low PLU value, which is used until all locations have been reported to the LS (typically less than 10 minutes). The LS send a new request to RAN that sets the PLU timer to the original value. 
         [0049]      FIG. 4   a  is a block diagram showing the Location Server, and signals between other network elements of the alert system. 
         [0050]    The passive data flow is put on hold until there is an area to supervise. When the Alert Application  210  wants find all subscribers in a specific area, then the passive data flow is enabled and the Location Server starts to collect subscriber locations. 
         [0051]    In message  401  the LS receives request from the alert Application, including the alert area. 
         [0052]    In message  402  LS determines which cell(s) that belongs to the alert area. 
         [0053]    In message  403  LS send a start request to the CN that serves the particular cells. The start request can, as an option, specify only cells within the alert area  220  to be monitored. 
         [0054]    In message  404   a  the start request will make the CN to start sending passive data for the subscribers to the Location Server. 
         [0055]    In message  404   b  the subscriber locations are stored in the database. 
         [0056]    In message  404   c  the subscribers that are within the alert area are sent to the alert application, including subscriber id, location and quality of provided data (age). It may also include information on when accurate data may be provided. 
         [0057]    In messages  405   a,b  the LS fetch periodic location update (PLU) time from RAN for the particular cell(s). The PLU time is in order of hours. 
         [0058]    In message  406  the LS configure a new, low, PLU time in the selected cells via the RAN. The value is in order of minutes. 
         [0059]    In message  407   a  the LS receive passive data for all subscribers located in the selected cells within a couple of minutes. 
         [0060]    In message  407   b  the subscriber locations are stored in the database. 
         [0061]    In message  407   c  the subscribers that are within the alert area are sent to the alert application, including subscriber id, location and time. This is done until all subscribers have been located. 
         [0062]    In message  408  the LS configure the original FLU value in the selected cells. 
         [0063]    In message  409  the LS send a stop request to the CN to stop sending passive data. 
         [0064]    The passive data in message  404   a  and message  407   a  is primarily generated by the PLU event received from RAN. During the time the cells are supervised there might also occur other events (for example; SMS is sent, IMSI attach, call is made, IMSI detach . . . ). The existences of these events are dependent on the implementation, but the benefits of having them are small. 
         [0065]      FIG. 4   b  is a flow chart showing the method of the Location Server in  FIG. 4   a.    
         [0066]    The method starts in step  450 . 
         [0067]    In step  451  the LS receives request from the alert Application, including the alert area. 
         [0068]    In step  452  LS determines which cell(s) that belongs to the alert area. 
         [0069]    In step  453  LS send a start request to the CN that serves the particular cells. The start request can, as an option, specify only cells within the alert area  220  to be monitored. 
         [0070]    The start request  453  will make the CN to start sending passive data for the subscribers to the Location Server which are received in step  454 . 
         [0071]    In step  455  the subscriber locations are stored in the database. 
         [0072]    In step  456  the subscribers that are within the alert area are sent to the alert application, including subscriber id, location and quality of provided data (age). It may also include information on when accurate data may be provided. 
         [0073]    In step  457  the LS fetch periodic location update (PLU) time from RAN for the particular cell(s). The PLU time is in order of hours. 
         [0074]    In step  458  the LS configure a new, low, PLU time in the selected cells via the RAN. The value is in order of minutes. 
         [0075]    In step  459  the LS receive passive data for all subscribers located in the selected cells within a couple of minutes. 
         [0076]    In step  460  the subscriber locations are stored in the database. 
         [0077]    In step  461  the subscribers that are within the alert area are sent to the alert application, including subscriber id, location and time. This is done until all subscribers have been located. 
         [0078]    In step  462  the LS configure the original PLU value in the selected cells. 
         [0079]    In step  463  the LS send a stop request to the CN to stop sending passive data. 
         [0080]    The passive data in step  454  and step  459  is primarily generated by the PLU event received from RAN. During the time the cells are supervised there might also occur other events (for example; SMS is sent, IMSI attach, call is made, IMSI detach . . . ). The existences of these events are dependent on the implementation, but the benefits of having them are small. 
         [0081]    The method ends in step  464 . 
         [0082]      FIG. 5   a  is a block diagram showing an embodiment of the Location Server  120  of  FIG. 4  in more detail. 
         [0083]    The passive data flow is put on hold until there is an area to supervise. When the Alert Application  210  wants to find all subscribers in a specific area, then the passive data flow is enabled and the Location Server starts to collect subscriber locations. 
         [0084]    In message  501  the Application Handler  310  receives a request from Alert Application, including alert area. The Application Handler decodes the message, authenticate and check authorization of the Alert Application to verify that the request is allowed. The request is handed over to LS Core  320  if the request is valid and authorized. 
         [0085]    In messages  502  the LS Core determines which cell(s) that belongs to the alert area, by searching the Location DB  130 . 
         [0086]    In message  503  the LS Core informs CN Configurator  330  to send a start request to the CN  360  that serves the particular cells. 
         [0087]    The start request will make the CN to start sending passive data for the subscribers to the Location Server which are received in messages  504   a . The Event Handler  340  in the LS is responsible for receiving the network events/passive location data from the CN. The Event handler forwards the data to LS Core. 
         [0088]    In message  504   b  the LS Core forward the location data to the database and translate the location data to a location estimate (latitude/longitude). 
         [0089]    In message  504   c  the subscriber (i.e. identifier and subscriber data) that are within the alert area are sent by LS Core to the Application Handler, which forwards the data to the Alert Application. The data includes subscriber id, location estimate and quality of provided data (age). It may also include information on when accurate data may be provided. 
         [0090]    In message  505  the LS Core requests RAN Configurator  350  to fetch periodic location update (PLU) time from RAN for the particular cell(s). The PLU time is normally in order of hours. 
         [0091]    In message  506  the LS Core requests RAN Configurator to configure a new, lower, PLU time in the selected cells via the RAN. The value is normally in the order of minutes. 
         [0092]    Within a couple of minutes (due to the new PLU time) passive data for all subscribers within the defined cells have been sent to the Event Handler. In message  507   a , after having received the passive data, the Event Handler forwards the event data to LS Core. 
         [0093]    In message  507   b  the LS Core forwards the location data to the Location DB and translates the location data to a location estimate (latitude/longitude). 
         [0094]    In message  507   c  the subscribers data that are within the alert area are sent by LS Core to the Application Handler  310 , which forwards the data to the Alert Application. The data includes subscriber id, location estimate and quality of provided data (age). It may also include information on when accurate data may be provided. 
         [0095]    In message  508  the LS Core requests RAN Configurator to reconfigure the PLU value to the original value in the selected cells. 
         [0096]    In message  509  the LS Core request CN Configurator to send a stop request to the CN. The stop request makes the CN stop sending passive data. 
         [0097]    The passive data in message  504   a  and in message  507   a  is primarily generated by the PLU event received from RAN. During the time the cells are supervised there might also occur other events (for example; SMS is sent, IMSI attach, call is made, IMSI detach . . . ). The existences of these events are dependent on the implementation, but the benefits of having them are small. 
         [0098]      FIG. 5   b  is a flow chart showing the method of the Location Server in  FIG. 5   a.    
         [0099]    The method starts in step  550 . 
         [0100]    In step  551  the Application Handler  310  receives a request from Alert Application, including alert area. The Application Handler decodes the message, authenticate and check authorization of the Alert Application to verify that the request is allowed. The request is handed over to LS Core  320  if the request is valid and authorized. 
         [0101]    In step  552  the LS Core determines which cell(s) that belongs to the alert area, by searching the Location DB  130 . 
         [0102]    In step  553  the LS Core informs CN Configurator  330  to send a start request to the CN  360  that serves the particular cells. 
         [0103]    In step  554  the LS receives passive data for the subscribers from the CN. The Event Handler  340  in the LS is responsible for receiving the network events/passive location data from the CN. The Event handler forwards the data to LS Core. 
         [0104]    In step  555  the LS Core forward the location data to the database and translate the location data to a location estimate (latitude/longitude). 
         [0105]    In step  556  the subscriber (i.e. identifier and subscriber data) that are within the alert area are sent by LS Core to the Application Handler, which forwards the data to the Alert Application. The data includes subscriber id, location estimate and quality of provided data (age). It may also include information on when accurate data may be provided. 
         [0106]    In step  557  the LS Core requests RAN Configurator  350  to fetch periodic location update (PLU) time from RAN for the particular cell(s). The PLU time is normally in order of hours. 
         [0107]    In step  558  the LS Core requests RAN Configurator to configure a new, lower, PLU time in the selected cells via the RAN. The value is normally in the order of minutes. 
         [0108]    Within a couple of minutes (due to the new PLU time) passive data for all subscribers within the defined cells have been received by the Event Handler. In step  559 , after having received the passive data, the Event Handler forwards the event data to LS Core. 
         [0109]    In step  560  the LS Core forwards the location data to the Location DB and translates the location data to a location estimate (latitude/longitude). 
         [0110]    In step  561  the subscribers data that are within the alert area are sent by LS Core to the Application Handler  310 , which forwards the data to the Alert Application. The data includes subscriber id, location estimate and quality of provided data (age). It may also include information on when accurate data may be provided. 
         [0111]    In step  562  the LS Core requests RAN Configurator to reconfigure the PLU value to the original value in the selected cells. 
         [0112]    In step  563  the LS Core request CN Configurator to send a stop request to the CN. The stop request makes the CN stop sending passive data. 
         [0113]    The method ends in step  564 . 
         [0114]      FIG. 6  is a signal diagram showing another embodiment of a Location Server according to the invention. 
         [0115]    Subscribers that subscribe to ST services will have updated positions stored in the location database DB every time there is radio communication between the terminal and the PLMN (such as SMS sending, making call, attach to network, LA update . . . ). This means that ST enabled subscribers will have high quality on the positioning data, and the consequence is that those subscribers load the network more than other users. The load is however quite low as long as only a part of the subscriber base is using ST. 
         [0116]    An alternative to get all passive data events for the subscribers is to select only one or a few of the events. One event suitable for this is the Periodic Location Update event. This event comes regularly, for example once every hour. That would mean that the average age of location would be 30 minutes. The shorter interval that is used, the more is the CN, LS and transmission network loaded. This alternative (with a reasonable high PLU time) is however very good to combine with the optimized solution, since this alternative provides an updated location database which facilitates a fast response to the application. 
         [0117]    In this embodiment the passive data flow active for ST enabled subscribers includes all event types. All non-ST enabled subscribers will only get network events for the PLU passive data event. When the Alert Application wants to find all subscribers in a specific area, then the passive data flow is increased for all subscribers in the relevant cells, by decreasing the PLU time. 
         [0118]    In messages  690  passive data for all subscribers are continuously sent to the Location Server from the CN. The LS store the data in the database. The subscriber location data is normally updated with an interval of 1-8 hour. 
         [0119]    In message  601  the LS receive a request from alert Application, including alert area. 
         [0120]    In messages  602  the LS performs a search in the database to find which subscribers that have a location that overlaps with the alert area. 
         [0121]    In message  603  a response including MSISDN, location and age of the location is sent to the alert application. 
         [0122]    In messages  603 * the LS starts at this point to forward subscriber locations for the subscribers within the alert area to the alert application. 
         [0123]    In messages  604  the LS determines which cell(s) that belongs to the requested area 
         [0124]    In messages  605  the LS fetch current periodic location update (PLU) time from RAN for the particular cell(s). The PLU time is in order of hours. 
         [0125]    In message  606  the LS configure a new, low, PLU time in the selected cells via the RAN. The value is in order of minutes. 
         [0126]    In message  607   a  the LS receive passive data for all subscribers located in the selected cells within a couple of minutes. 
         [0127]    In message  607   b  the subscriber locations are stored in the database. 
         [0128]    In message  607   c  the subscribers that are within the alert area are sent to the alert application, including subscriber id, location and time. This is done until all subscribers have been located. 
         [0129]    In message  608  the LS configure the original PLU value in the selected cells 
         [0130]      FIG. 7   a  is a block diagram showing an embodiment of the Location Server in  FIG. 4  in more detail. 
         [0131]    In this embodiment the passive data flow active for ST enabled subscribers includes all event types. All non-ST enabled subscribers will only get network events for the PLU passive data event. When the Alert Application wants to find all subscribers in a specific area, then the passive data flow is increased for all subscribers in the relevant cells, by decreasing the PLU time. 
         [0132]    In messages  790  passive data for all subscribers are continuously sent to the Event Handler in the LS from CN. The Event Handler forwards the data to the Location DB via LS Core. 
         [0133]    In message  701  the Application Handler receives request from Alert Application, including alert area. The Application Handler decodes the message, authenticates and checks authorization of the Alert Application to verify that the request is allowed. The request is handed over to LS Core if the request is valid and authorized. 
         [0134]    In message  702  the LS Core requests the database for all subscribers currently with a location estimate that is within or overlapping with the alert area. The response is forwarded to the Application Handler. 
         [0135]    In message  703  the Application Handler responds to the Alert Application with a response including MSISDN, location and age of the location for all subscribers matching the alert area. 
         [0136]    In message  703 * the LS Core will at this point start to check all incoming passive data, to see if the subscriber location is within the alert area. The subscribers and their respective locations that are within the alert area are forwarded to the Application Handler that in turn forwards the data to the Alert Application. 
         [0137]    In message  704  the LS Core determines by interrogating the Location DB which cell(s) that belongs to the requested area 
         [0138]    In message  705  the LS Core requests RAN Configurator to fetch periodic location update (PLU) time from RAN for the particular cell(s). The PLU time is in order of hours. 
         [0139]    In message  706  the LS Core requests RAN Configurator to configure a new, low, PLU time in the selected cells via the RAN. The value is in order of minutes. 
         [0140]    Within a couple of minutes (due to changed PLU time) passive data for all subscribers within the defined cells have been sent to the Event Handler. After having received the passive data the Event Handler forwards the data to LS Core in message  707   a.    
         [0141]    In message  707   b  the LS Core forward the location data to the Location DB and translates the location data to a location estimate (latitude/longitude). 
         [0142]    In message  707   c  the subscribers that are within the alert area are sent by LS Core to the Application Handler, which forwards the data to the Alert Application. The data includes subscriber id, location estimate and quality of provided data (age). 
         [0143]    In message  708  the LS Core requests RAN Configurator to reconfigure the PLU value to the original value in the selected cells. 
         [0144]      FIG. 7   b  is a flow chart showing the method of the Location Server if  FIG. 7   a  in more detail. 
         [0145]    The method starts in step  750 . 
         [0146]    In steps  751  passive data for all subscribers are continuously sent to the Event Handler in the LS from CN. 
         [0147]    The Event Handler forwards the data to the Location DB via LS Core. 
         [0148]    In step  752  the Application Handler receives request from Alert Application, including alert area. The Application Handler decodes the message, authenticates and checks authorization of the Alert Application to verify that the request is allowed. The request is handed over to LS Core if the request is valid and authorized. 
         [0149]    In step  753  the LS Core requests the database for all subscribers currently with a location estimate that is within or overlapping with the alert area. The response is forwarded to the Application Handler. 
         [0150]    In step  754  the Application Handler responds to the Alert Application with a response including MSISDN, location and age of the location for all subscribers matching the alert area. 
         [0151]    In step  755  the LS Core will at this point start to check all incoming passive data, to see if the subscriber location is within the alert area. The subscribers and their respective locations that are within the alert area are forwarded to the Application Handler that in turn forwards the data to the Alert Application. 
         [0152]    In step  756  the LS Core determines by interrogating the Location DB which cell(s) that belongs to the requested area. 
         [0153]    In step  757  the LS Core requests RAN Configurator to fetch periodic location update (PLU) time from RAN for the particular cell(s). The PLU time is in order of hours. 
         [0154]    In step  758  the LS Core requests RAN Configurator to configure a new, low, PLU time in the selected cells via the RAN. The value is in order of minutes. 
         [0155]    Within a couple of minutes (due to changed PLU time) passive data for all subscribers within the defined cells have been sent to the Event Handler. After having received the passive data the Event Handler forwards the data to LS Core in step  759 . 
         [0156]    In step  760  the LS Core forward the location data to the Location DB and translates the location data to a location estimate (latitude/longitude). 
         [0157]    In step  761  the subscribers that are within the alert area are sent by LS Core to the Application Handler, which forwards the data to the Alert Application. The data includes subscriber id, location estimate and quality of provided data (age). 
         [0158]    In step  762  the LS Core requests RAN Configurator to reconfigure the PLU value to the original value in the selected cells. 
         [0159]    The method ends in step  763 . 
         [0160]    An advantage of the invention is that it is possible to locate subscribers within a particular area quickly and with low load on the Core Network CN (E.G. MSC, SGSN, Etc.), Location Server and the transmission network. 
         [0161]    The system is using on spatial triggers, with all advantages that ST have in terms of quality of service, with updated subscriber locations and improve the age of location by modifying configuration settings in the RAN at runtime. 
         [0162]    The problem with high network load is solved by in runtime switching off the CN functionality when it is not needed. Another important improvement is that the high update rate is only used in the needed cells and not in the complete network. 
         [0163]    Most operators want to have fresh positions in the location database and with the invention the average age of location is significantly decreased. 
         [0164]    The steady stream of location data from the CN when using spatial triggers means also that the load in the CN will be high (i.e. the capacity drops). With the invention the load in CN is reduced to a slight Central Processing Unit CPU increase during a couple of minutes. 
         [0165]    Another advantage is that the amount of Gateway Mobile Location Center GMLC hardware needed to be able to handle the constant high traffic load from the CN during continuous spatial triggering is avoided.