WO2014204378A1

WO2014204378A1 - Alert message feedback handling

Info

Publication number: WO2014204378A1
Application number: PCT/SE2014/050579
Authority: WO
Inventors: Fredrik ERLANDSON; Lars Kari
Original assignee: Mobile Arts Ab
Priority date: 2013-06-20
Filing date: 2014-05-13
Publication date: 2014-12-24

Abstract

The present disclosure relates to provide network status and/or user status information for enhanced alert message management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network, the providing input information for enhanced alert message handling managing traffic in a communication network during an emergency situation.

Description

ALERT MESSAGE FEEDBACK HANDLING

TECHNICAL FIELD

This disclosure relates to methods, network nodes, a system, and computer programs for providing input information enabling handling of network status information and/or user status information in conjunction with alert message sending management and alert message related emergency management.

BACKGROUND

Today's globalized world and modern society is more vulnerable than ever and the population is exposed to an ever increasing number of major threats and hazards.

For example, the increased travelling around the planet for business and leisure makes travellers more exposed to environmental disasters, conflicts, epidemics or other diseases. More transportation through, and industries located within or close to, dense populated areas also increases the risk of serious consequences in case of e.g. traffic accidents or industrial hazardous leaks or pollutions.

The unpredictable and extreme weather conditions and climate changes also make environmental disasters more common with extreme consequences for people, infrastructure and health care.

Also, actions of war and terrorism are global and can affect a great number of people all over the world.

In all the examples above, knowledge of people's current location and a possibility to urgently alert people at risk on the current situation and what appropriate measures to take are top priorities to prevent people from ending up in unfortunate situations or even being injured or killed. This applies not only for citizens in their home country, but for citizens staying abroad as well.

In order not to worry people unduly and create unnecessary anxiety or mass hysteria, it is also of highest priority to only alert people who is actually at risk, i.e. alert only not those close to or within the affected area at the time of an incident.

Several attempts have been made in the past to inform and warn citizens of war related scenarios, emergencies, etc.

Sirens and similar aural solutions have been used since long to locally warn citizens of e.g. war scenarios, like bombs and missile attacks, etc. Aural solutions have later on often been complemented with public broadcasting systems, i.e. radio and television, in order to also provide information about the situation.

One of several problems with sirens and similar aural solutions alone is that the citizens don't get any direct information about the incident or where it is at. It can also be hard to determine if the incident is ongoing or has already occurred. The public broadcasting systems also suffer from various drawbacks. For example, the broadcasting of alert information does rarely reach only the local area in which the event has occurred, but often a whole nation why it may worry citizens unduly. A prerequisite for accessing the information is also that people are close to turned on radio and/or television.

Due to the enormous increase of mobile telephony in most parts of the world during the last couple of decades and due to that mobile phones or user equipments have become nearly everyone's possession, the idea of using the mobile equipment for receiving alert notifications has been considered highly advantageous.

Since the majority of mobile telephony standards used around the world provide message and data services as well as speech services, notifications can easily be supplied to the mobile subscribers in text format as well as in other formats, like image or video formats.

One attempt to use mobile equipment for receiving alert notifications is subscription- based alert services, in which the mobile subscriber gets alerts within his fields of interest.

A major drawback with subscription-based alert services is that subscribers must provide information about themselves and their interests in advance to receive any alerts and that the subscriber often has to pay a periodic subscription fee. In practice, subscribers seldom want to voluntarily use their own time and energy on providing personal information to get notifications of any kind. Furthermore, subscribers often fear that their personal information may be misused, sold or passed on to third parties without their approval. Most importantly, in able for an emergency alert service to be effective, it is required that the vast majority of all subscribers subscribes to the same service, for which reason subscription-based alert services in practice never is an alternative for effective emergency alerting.

Another attempt to use mobile networks to warn citizens is Cell Broadcasting with Short Message Service (SMS) which is a Global Systems for Mobile communication (GSM) standard that provides a network operator or service supplier the possibility to broadcast a message to

GSM subscribers within a certain radio cell or group of cells. A SMS Cell Broadcast message is broadcasted cyclically by a Base Transceiver Stations (BTSs) in defined radio cells at a specified frequency and duration. One of the major disadvantages with Cell Broadcasting is that all mobile subscribers must initially and manually configure their mobile equipment in order to be able to receive such messages. This configuration often also includes settings of different subjects that the subscriber is interested in receiving messages in, besides alert messages.

As in the case with subscription-based alert services, it is necessary that all subscribers are aware of Cell Broadcasting services and have actively done all the required reconfigurations and subject settings in able for emergency alert services to operate. In fact, the knowledge of Cell Broadcasting is generally poor and, and even if it were not, both the effort and knowledge how to reconfigure and the risk of letting personal settings being misused makes Cell

Broadcasting a deficient alternative for emergency alert services.

Furthermore, since Cell Broadcasting systems are quite expensive and most certainly will be used for other purposes, such as commercial advertising during non-emergency periods, it is not unlikely that subscribers will become tired of this technique and choose to turn off the Cell Broadcasting feature on their mobile equipment.

Another disadvantage with Cell Broadcasting is that the location accuracy is limited to cell accuracy. Moreover, Cell Broadcasting services send the same alert message content and setting to all subscribers within a cell or set of cells.

Yet another disadvantage with Cell Broadcasting is that it severely decreases the signalling capacity of the mobile network due to repeated transmissions.

Apart from the above, there have also been proposed other attempts to handle alert message distribution in mobile networks as described in the following prior art:

WO 2009/070029 Al describes a location based alert system for sending alert messages to users of mobile phones. Probes located between a Home Location Register (HLR) and Visiting Location Register (VLR) and corresponding Mobile Switching Centres (MSCs) are utilised to monitor the traffic related to location updates. Probed data contains International Mobile

Subscriber Identity (IMSI) or Mobile Subscriber Integrated Services Digital Network Number, Cell ID, Location Area Code (LAC) ID, date and time. Sending of alert messages comprises: assessing received information and determine the relevant mobile phones with corresponding MSISDN number to send alert messages to and sending the alert messages to relevant mobile phones located in the specific geographical area. The assessing of received information may comprise a randomizing of cell ids in order to reduce queued traffic load on the same cell before a paging procedure on relevant MSISDNs for receiving serving cells for each relevant MSISDN and a check whether the returned cell ids are within the range of the cells covering a relevant geographic area. The alert message sending may also comprise measuring the time elapsed from sending the message to receiving a confirmation and, if the time elapsed is above a certain limit; reduce the load of the current cell by sending the next message through another cell.

WO 2009/104970 Al reveals a traveller's alert system for producing updated status of subscribers who are staying in a specific geographical area abroad A database is continuously updated with location information and MSISDN numbers of subscribers who are staying abroad with the aid of a probe that identifies queries from foreign operators in the mobile network to the HLR, i.e. probing is done between the national Gateway (G-)MSC and HLR. Location data relates to whole countries or specific regions in one or more countries. Data updated in the database are visited country, region, MSISDN, date and time for last update for each person associated with the MSISDN. Status for persons staying abroad may be presented on a graphical user interface connected to clients.

WO 2008/079092 Al describes a method and apparatus for mobile subscriber alert notification in which 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 quality of passive location data, generated in a network element due to any of the events:

sending an SMS, making a call, location area update or periodic location update and stored in a 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. The method for mobile subscriber alert notification comprises sending a request to network nodes serving cells belonging to the alert area to modify the configuration of subscriber location data updating in the network nodes. The modified configuration comprises a periodic location update parameter.

WO 2006/028381 Al presents a method and system for optimized control of traffic load on switches in a communication network for maximum exploitation of the capacity of the switches when alerting the population when an undesirable event occurs in a specific geographical area by means of messages transmitted via the switches. The method comprises a step for establishing information on whom is located within a geographical area, a step for assigning load status on switches by test transmitting simultaneous calls, the number of calls being increased or reduced as a result of the revealed load on the switch and based on a set of rules, a step for clarifying and implementing broadcasting, a step for monitoring the load on the switches and a step for changing the number of message exchanges as a result of revealed load status on the switch(es). As for alerting subscribers staying abroad, WO 2009/104970 Al reveals a traveller's alert system for producing updated status of subscribers who are staying in a specific geographical area abroad by means of a probe that identifies queries from foreign operators in the mobile network to the HLR, i.e. probing between a foreign MSC and the home network HLR. As radio network data for foreign countries seldom is available and the foreign MSCs may serve large unknown geographical regions (probing between an on-net HLR and an off-net MSC provides subscriber info (MSISDN/IMSI/LMSI) and node info (MSC/ SGSN), but not cell info), the only certain location information provided by this method is in which country the subscriber is located.

WO 2008/079092 Al describes a method and apparatus for mobile subscriber alert notification, in 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 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.

Shortcomings of the prior art comprise that subscriber information, especially subscriber location information, is limited and/or rapidly becomes outdated, which severely limits available alert message handling possibilities.

There is hence a need to overcome the drawbacks of prior art configurations.

SUMMARY

It is an object of example embodiments of the invention to address at least some of the issues outlined above. This object and others are achieved by the methods, the nodes, a system and the computer program according to the appended independent claims, and by the embodiments according to the appended dependent claims.

According to one aspect, the invention provides a method for providing network status and/or user status information for enhanced alert message sending management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network, the method being performed in an alert messaging node of an alert messaging system. The method comprises receiving feedback information to the sending of alert messages to said user devices, and determining network status and/or user status information, based on the feedback information. In addition, the method comprises providing the determined network status and/or user status information, enabling said enhanced alert message sending management and alert message related emergency management.

According to a second aspect, the invention provides a method for providing network status and/or user status information for enhanced alert message sending management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network. This method is performed in a middleware node of an alert messaging system, and comprises receiving network status information and/or user status information of user devices to which alert messages were sent, and obtaining location information of a user device of the user devices to which alert messages were sent. In addition, the method comprises providing the location information of a user device of the user devices; and the obtained network status information and/or user status information, enabling enhanced alert message sending management and alert message related emergency management.

According to a third aspect, the invention provides a method for providing network status and/or user status information for enhanced alert message sending management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network. The method is performed in an alert messaging system, and comprises receiving feedback information to the sending of alert messages to said user devices, and obtaining location information of a user device of the user devices to which alert messages were sent. The method also comprises determining network status and/or user status information, based on the feedback information. In addition, the method comprises providing the location information of a user device of the user devices, the obtained network status information and/or user status information, enabling enhanced alert message sending management and alert message related emergency management.

According to a fourth aspect, the invention provides an alert messaging node being configured to provide network status and/or user status information for enhanced alert message management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network. The alert messaging node comprises a processor; and a memory storing computer program comprising computer program code. When said program code is run in the processor, it causes the alert messaging node to receive feedback information to the sending of alert messages to said user devices, and determine the network status and/or user status information, based on the feedback information. In addition, it causes the alert messaging node to provide the determined network status and/or user status information, enabling enhanced alert message sending management and alert message related emergency management.

According to a fifth aspect, the invention provides a middleware node being configured to provide network status and/or user status information for enhanced alert message management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network. The middleware node comprises a processor; and a memory storing computer program comprising computer program code which, when run in the processor, causes the middleware node to receive network status and/or user status information of user devices to which alert messages were sent; and to obtain location information of a user device of the user devices to which alert messages were sent. In addition, it causes the middleware node to provide the location information of a user device of the user devices; the obtained network status information and/or user status information, enabling enhanced alert message sending management and alert message related emergency management.

According to a sixth aspect, the invention provides a computer program comprising computer program code. When this computer program code is run in a processor of an alert messaging node, it causes the alert messaging node, which is configured to provide network status and/or user status information for enhanced alert message management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network, to receive feedback information to the sending of alert messages to said user devices. It also causes the alert messaging node to determine the network status and/or user status information, based on the feedback information. In addition, it causes the alert messaging node to provide the determined network status and/or user status information, enabling enhanced alert message sending management and alert message related emergency management.

According to a seventh aspect, the invention provides a computer program comprising computer program code. When this computer program code is run in a processor of a middleware node, it causes the middleware node, which is configured to provide network status and/or user status information for enhanced alert message management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network, to receive network status and/or user status information of user devices to which alert messages were sent. Also, it causes the middleware node to obtain location information of a user device of the user devices to which alert messages were sent; and to provide the location information of a user device of the user devices, the obtained network status information and/or user status information, enabling enhanced alert message sending management and alert message related emergency management.

It is an advantage of the invention that it enables enhanced alert message sending management and alert message related emergency management. This enables, for instance, - defining media statements (e.g. for radio, press and television);

assigning and scaling technical personnel to accurate equipment and/or problem areas;

giving authorities an indication of the magnitude of the incident and help the authorities to scale and optimize emergency and evacuation operations accordingly (according to e.g. number and nationality of subscribers);

helping the police force, the fire brigade or a rescue group to overview the situation and the need and size of operation within an affected area;

helping the network operators to overview the mobile network functionality and scale technical support and provide input for repair teams;

- defining new or changing or refining old priorities for Alert message sending

Services, subscriber and/or cells; and

defining new or changing or refining old subscriber settings in terms of Age Of Location (AOL), Quality Of Location (QOL), location accuracy, etc. Further objects and features, as well as advantages of the present disclosure will become apparent from consideration of the various embodiments of the present disclosure described in the following description and the appended claims when considered in connection with the accompanied drawings. BRIEF DESCRIPTION OF DRAWINGS

The present invention will now be described in more detail, and with reference to the accompanying drawings, in which:

Figures 1 to 3 present flow-charts of methods according to embodiments of the present disclosure;

Figures 4 to 6 schematically illustrate an alert messaging node, a middleware node, and an alert messaging system, respectively; and

Figures 7 to 9 illustrates examples of some embodiments of the present disclosure. ABBREVIATIONS

AMN Alert Messaging Node

ATI Any Time Interrogation

ATM Any Time Modification

ATSI Any Time Subscription Information

BSC Base Station Controller

BTS Base Transceiver Station

CAMEL Customized Applications for Mobile Network Enhanced Logic

CDR Charging Data Record

CdGT Called GT

CgGT Calling GT

CGI Cell Global Identity

DMAOL Default MAOL

DR Delivery Receipt

E-CGI Enhanced CGI

GMLC Gateway Mobile Location Center

GPRS General Packet Radio Service

GPS Global Positioning System

GSM Global System for Mobile Communications

GT Global Title

HLR Home Location Register

HPLMN Home Public Land Mobile Network

HSS Home Subscriber Server

IMS IP Multimedia Subsystem

IMSI International Mobile Subscriber Identity

IP Internet Protocol

ISD Insert Subscriber Data

ISDN Integrated Services Digital Network

LA Location Area

LAI Location Area Identity

LCS LoCation Service

LMSI Local Mobile Station Identity

LU Location Update

MAOL Max Age of Location MAP Mobile Application Protocol

MMS Multimedia Messaging Service

MO Mobile Originating

MS Mobile Station

MSC Mobile Switching Center

MSISDN Mobile Subscriber ISDN Number

MT Mobile Terminating

MWN Middleware Node

OMA Open Mobile Alliance

PSI Provide Subscriber Information

RDS Reference Data Server

RNC Radio Network Controller

SAF Store and Forward

SAI Service Area Identity

SGSN Serving GPRS Support Node

SLIA Standard Location Immediate Answer

SLIR Standard Location Immediate Request

SMS Short Message Service

SMSC SMS Center

SOAP Simple Object Access Protocol

SUPL Secure User Plane Location

SPJ-LCS Send Routing Information for Location Service

SPJ-SM Send Routing Information for Short Message

UE User Equipment

UMTS Universal Mobile Telecommunications System

USSD Unstructured Supplementary Services Data

VLR Visiting Location Register

DETAILED DESCRIPTION

Herein are disclosed methods, network nodes, a system, and computer programs for providing input information enabling handling of network status information and/or user status information in conjunction with alert message sending management and alert message related emergency management. It should further be mentioned that user device and user equipment (UE) are synonymous herein. Also, user and subscriber are used interchangeably, and hence user and subscriber are herein interchangeable with one another.

It is interest that concerned authorities receive knowledge about the status and health of the subscribers and the mobile network close to or within for example an emergency area.

Prior art does not disclose any effective ways to use (Alert) message delivery receipts and responses (in conjunction with emergency/Alert message sending) as a way of disclosing and presenting subscriber and/or network status (and statistics) within specific geographic areas, such as Alert zones, LACs or cells. Neither does prior art disclose the use of message delivery receipt and response information as input for refined emergency (emergency/Alert) message sending in regard to (emergency/Alert) message content definitions (texts, languages and types), pre-defined message response definitions and emergency area, Alert and Roaming zones definitions depending on message sending service and subscriber priorities and types as well as subscriber (and network) location.

Furthermore, prior art does not disclose the use of message delivery receipt and response information for refined management and alert message related emergency management such as scaling of emergency and/or technical personnel.

Prior art does neither present how to add (neither last-known or real-time) location and node info to the (Alert) message delivery receipts and responses or provide solutions on how to properly handle Alert message responses with attached location and node info from off-net (international) subscribers for use as subscriber and network status and statistics presentation, message sending refining and emergency organization and scaling.

Figure 1 presents a flow-chart of a method for providing network status and/or user status information for enhanced alert message sending management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network. The method is performed in an alert messaging node of an alert messaging system, and comprises receiving 102 feedback information to the sending of alert messages to said user devices, determining 104 network status and/or user status information, based on the feedback information; and providing 106 the determined network status and/or user status information, enabling said enhanced alert message sending management and alert message related emergency management. The alert message sending may comprise attempting to send alert messages, and wherein receiving (102) feedback information comprises receiving intermediate delivery receipts having information of each attempted alert message sending to the user devices.

Receiving (102) feedback information may comprise receiving final delivery receipts having information about successful delivery of alert messages to the user device.

Receiving (102) feedback information may comprise receiving an alert message response from user devices to which an alert message was sent.

The method performed in an alert messaging node may comprise obtaining a last-known location of user devices from passive location methods and caching said last known location in a location cache of the alert messaging node.

The method performed in an alert messaging node may comprise providing the last- known location of user devices.

The method performed in an alert messaging node may further comprise obtaining a real time location of a user device of the user devices from active location methods via an internal proxy and Global Mobile Location Center, GMLC, functionality or via external proxies, GMLCs and Mobile Location Centers, MCSs.

The method performed in an alert messaging node may comprise obtaining a real time location of a user device of the user devices, based on requesting said real time location from a middleware node connected to the alert messaging node.

The method performed in an alert messaging node may comprise providing the real time location of a user device of the user devices.

The method performed in an alert messaging node may further comprise providing into sent alert messages a destination address, DA, with originating/source address from alert messages previously received, and an originating address, OA, with destination address from the previously received alert message.

The method performed in an alert messaging node may further comprise handling incoming SRI-SM in a virtual home location register in the alert messaging node global SMSC functionality, being configured to serve the originating address.

The method performed in an alert messaging node may comprise providing a send routing information for short message, SRI-SM, response including a special IMSI/LMSI for the originating address, and the virtual MSC/SGSN in the alert messaging node global SMSC functionality as MSC/SGSN address.

The method performed in an alert messaging node may comprise handling and routing incoming MT-FSM in the virtual MSC/SGSN towards the MWN. Figure 2 presents a flow-chart of a method for providing network status and/or user status information for enhanced alert message sending management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network. The method is performed in a middleware node of an alert messaging system, and comprises receiving 202 network status information and/or user status information of user devices to which alert messages were sent, and obtaining 204 location information of a user device of the user devices to which alert messages were sent. In addition, the method comprises providing 206 the location information of a user device of the user devices; and the obtained network status information and/or user status information, enabling enhanced alert message sending management and alert message related emergency management.

Obtaining (204) location information of a user device, within the method performed in a middleware node, may comprise retrieving information about the location of a user device by using passive user device location methods, optionally in combination with active user device location methods.

Obtaining (204) location information of a user device, within the method performed in a middleware node, may comprise obtaining, or receiving from an alert messaging node, information about a last known location of said user device.

The method performed in a middleware node may comprise storing the last known location in a user database of the middleware node.

Retrieving information about the location of a user device by using passive user device location methods, within the method performed in a middleware node, may comprise using non- intrusive probing on communication network interfaces or location information derived from Event Managers or Charging Data Records, CDRs.

Obtaining (204) location information of a user device, within the method performed in a middleware node, may comprise obtaining real-time location information of a user device.

Obtaining (204) real time location information of a user device, within the method performed in a middleware node, may comprise deriving the real time location from active location methods via internal proxy and GMLC functionality in the middleware node.

Retrieving information about the location of a user device by using active user device location methods, within the method performed in a middleware node, may comprise using active user device location methods comprising using Provide Subscriber Information, PSI, for International Mobile Subscriber Identity, IMSI, Land Mobile Subscriber Identity, LMSI, towards Mobile Switching Centre, MSC, or Serving General Packet Radio Service Support Node, SGSN, alternatively Customized Applications for Mobile network Enhanced Logic, CAMEL, Any Time Interrogation, ATI, for Mobile Station International, Integrated Service Digital Network Number, MSISDN, towards Home Location Register, HLR, the retrieval of MSISDN and/or serving MSC/SGSN address for the user device comprises using Send Routing Information for Location Services, SRI-LCS, for user device International Mobile Subscriber Identity/Land Mobile Subscriber Identity, IMSI/LMSI, towards HLR and the retrieval of IMSI/LMSI and/or serving MSC/SGSN address for the user device comprises using Send Routing Information for Short Message, SRI-SM, for user device MSISDN towards HLR in the communication network.

The method, within the method performed in a middleware node, may comprising determining alert message managing input information for a specific geographical area based on at least one of: a proportion between successful final delivery receipts, DRs, and total number of alert messages sent to said specific geographical area; a proportion between unsuccessful final DRs and total number of alert messages sent to said specific geographical area; and a proportion between intermediate DRs and total number of alert messages sent to said specific geographical area.

The method performed in a middleware node, may comprise determining alert message managing input information for a specific geographical area based a proportion between message responses requiring assistance or help, and message responses requiring neither assistance nor help.

Figure 3 presents a flow-chart of a method for providing network status and/or user status information for enhanced alert message sending management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network. The method is performed in an alert messaging system, and comprises receiving 302 feedback information to the sending of alert messages to said user devices, and obtaining 304 location information of a user device of the user devices to which alert messages were sent. The method also comprises determining 306 network status and/or user status information, based on the feedback information. In addition, the method comprises providing 308 the location information of a user device of the user devices, the obtained network status information and/or user status information, enabling enhanced alert message sending management and alert message related emergency management. Figure 4 schematically illustrates an alert messaging node (AMN). The AMN 400, 602 is configured to provide network status and/or user status information for enhanced alert message management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network. The alert messaging node comprises a processor 402; and a memory 404 storing computer program comprising computer program code. When said program code is run in the processor, it causes the alert messaging node to receive 102 feedback information to the sending of alert messages to said user devices, and determine 104 the network status and/or user status information, based on the feedback information. In addition, it causes the alert messaging node to provide 106 the determined network status and/or user status information, enabling enhanced alert message sending management and alert message related emergency management.

Figure 5 schematically illustrates a middleware node (MWN). The MWN is configured to provide network status and/or user status information for enhanced alert message management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network. The middleware node comprises a processor 502; and a memory 504 storing computer program comprising computer program code which, when run in the processor, causes the middleware node to receive 202 network status and/or user status information of user devices to which alert messages were sent; and to obtain 204 location information of a user device of the user devices to which alert messages were sent. In addition, it causes the middleware node to provide 206 the location information of a user device of the user devices; the obtained network status information and/or user status information, enabling enhanced alert message sending management and alert message related emergency management.

Figure 6 schematically illustrates an alert messaging system configured to provide network status and/or user status information for enhanced alert message management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network. The alert messaging system comprises an alert messaging node 602, as described above, and a middleware node 604, as described above.

Embodiments of the present disclosure comprises a computer program comprising computer program code which, when run in a processor 402 of an alert messaging node 400, causes the alert messaging node being configured to provide network status and/or user status information for enhanced alert message management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network, to receive 102 feedback information to the sending of alert messages to said user devices, and to determine 104 the network status and/or user status information , based on the feedback information. It also causes the alert messaging node to provide 106 the determined network status and/or user status information, enabling enhanced alert message sending management and alert message related emergency management.

Embodiments of the present disclosure also comprises a computer program comprising computer program code which, when run in a processor 502 of a middleware node 500, causes the middleware node being configured to provide network status and/or user status information for enhanced alert message management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a

communication network, to receive 202 network status and/or user status information of user devices to which alert messages were sent. Also, it causes the middleware node to obtain 204 location information of a user device of the user devices to which alert messages were sent; and to provide 206 the location information of a user device of the user devices, the obtained network status information and/or user status information, enabling enhanced alert message sending management and alert message related emergency management.

Some embodiments of the present disclosure generally focus on a method, system and computer program for enhanced handling and use of on-net and off-net message delivery receipts and responses for identification and presentation of subscriber and network status and statistics, for defining or refining (Alert) message content and response, emergency area, Alert and Roaming zone propagation and for emergency organizing and scaling in dependence on message sending service and subscriber priorities and types as well as subscriber (and network) location.

Present embodiments relate generally to methods, network nodes, a system and computer program for enhanced (handling and) (mass) sending of (location-based) Alert messages to notify (specific groups of) subscribers within defined Emergency areas/Area Of Interests of undesirable events, such as threats or emergency situations, in circuit and packet switched mobile networks (without overloading the mobile/Core and Radio Access network, and doing so independently of any subscriber preferences).

Some embodiments focus on a method, a system and/or computer program for the enhanced, last known as well as real-time, handling and use of on-net and off-net message delivery receipts and responses for revealing the status, health and location of subscribers and the status of the mobile network for use as message sending input and for identification and presentation of subscriber and network statistics for the calculating and management/ organization of e.g. emergency scaling, evacuation organization, ambulance and hospital use, technical support services, etc.

To reveal the status and location of message responses from on-net and off-net subscribers, the system make use of internal proxy and GMLC functionality for the inclusion of last known or real-time (current) location in Alert message delivery receipts and responses for on-net subscribers and internal Global SMSC plus proxy and GMLC functionality for the inclusion of last known or real-time (current) location in Alert message responses for off-net subscribers, respectively. The system may as an embodiment of the disclosure alternatively make use of an external legacy GMLC.

Passively obtained user device subscriber data may be complemented with active location methods including at least one of: provide subscriber information (PSI), ATI, send routing information for location services (SRI-LCS) or send routing information for short message (SPJ-SM).

Location methods for positioning of UEs comprise the following:

passive location methods, such as passive probe location, event manager location or charging data record (CDR) location,

active basic location methods, such as 3generation partnership program (GPP) customized application for mobile network enhanced logic (CAMEL) provide subscriber identity (PSI) or ATI, and

active enhanced location methods, such as 3GPP location service (LCS) enhanced cell global identity (E-CGI), open mobile alliance (OMA) secure user plane location (SUPL) assisted global positioning system (A-GPS) (gateway mobile location center (GMLC)) or mobile station (MS)-based or MS-assisted) 3 GPP LCS A-GPS

(GMLC/serving mobile location center (SMLC)).

Collection of service-related data may temporarily be put on hold while the system is not in service or while the system is handling other kind of non location-based services, such as bulk message sending. The collection of service-related data must first be activated and time be spent on collecting and processing the data before any location-dependent message sending may occur.

As UE subscriber data is collected via passive location methods, it may have to be complemented with active location methods in case of missing, obsolete or too old data. This also applies when the UE location quality or accuracy is insufficient compared to defined settings. In case of older location or cell data than a defined (default) max age of location

((D)MAOL) or in case UE subscriber MSISDN or MSC/SGSN address is missing or obsolete, the middleware node may update (and store) these by:

sending a CAMEL PSI towards the MSC/SGSN to get (updated) cell information (CGI/SAI) in case of missing or obsolete cell info,

sending a CAMEL ATI towards the HLR to get (updated) cell information (CGI /SAI) in case of missing or obsolete cell information (this method increases load on the HLR, why the PSI method may be preferred),

sending a SRI-SM for MSISDN towards the HLR in case of missing or obsolete IMSI and/or MSC/SGSN address (obtained node information may hereby be used as destination node address when sending the message and the IMSI may be used as subscriber address when sending the message), or

sending a SRI-LCS for IMSI towards the HLR in case of missing or obsolete MSISDN and/or MSC/SGSN address (obtained node information may hereby be used as destination node address when sending the message and the MSISDN may be used as subscriber index key).

In order to only send messages to subscribers within the actual defined emergency area(s), a demand for effective alert message sending is to determine cell-based geographical alert zones based on CGI, within GSM, and SAI within UMTS and/or geographic coordinates from alert area definition information and radio network data for the communication network.

To ensure that all subscribers, also those who may enter into an emergency area during alert message sending, will receive an alert message, a challenge for effective alert message sending is to determine an alert zone-related roaming zone from alert zone definition information comprising cells or geographic areas surrounding the alert zone or Location Areas, having LAIs including cells of the alert zone and then send messages to not only the alert zone, but also to the roaming zone dependent on settings. Another challenge is that the roaming zone should be able to be defined statically, with a size that is set from message sending start, as well as dynamically, with a size that varies, for instance decreases, over time based on e.g. remaining message sending validity period, progressed sending time, on internal system settings, subscriber priority or on subscriber-specific settings.

To increase the alert message sending throughput while avoiding core and radio access network overloads and congestions, one demand for effective alert message sending is to handle message sending so that the message output and radio traffic load lies within an acceptable output and radio traffic load interval and so that the radio traffic load is uniformly distributed among all (instances of) cells wherein a UE to be alerted is located.

To further increase the throughput of alert messages while avoiding core and radio access network overloads and congestions, other challenges for effective alert message sending are to use separated sending processes for messages needing and not needing initial paging and to send messages as packet switched data instead of circuit switched data if possible.

To fully utilize different network's performance and subscriber UE's presentation functionality, there are demands for effective alert message handling to send alert messages as circuit switched SMS messages or unstructured supplementary services data (USSD) messages as well as packet switched multimedia messaging service (MMS) or SMS over general packet radio service (GPRS).

To enable efficient defining, refining and supervision of alert geographical areas as well as enabling efficient defining and refining of alert message sending services, one demand for effective alert message sending preparation is to render presentation data, e.g. status and statistical data for subscribers of a particular type or all subscribers and their whereabouts, for presenting alert service-specific data. The alert service-specific data may comprise data that has been defined for a specific alert message sending service, e.g. service-specific alert zone/AOI, service data, message content and type, alert/roaming zones, and/or service related subscriber data, cell data and traffic data obtained from (continuous) data collection through passive location methods, alternatively in combination with data collection through active location methods, from radio network and from traffic data. Both the service-specific and service-related data may, for presentation use, be related to geographic area.

To ensure correct location information for subscribers staying abroad, one demand for effective subscriber UE location and alert message sending is to utilize obtained node information from passive probing between the on-net HLR and the off-net MSC/SGSN for deriving subscriber UE location, together with information from global cell databases where obtained foreign cell information can be translated into geographic coordinates.

For alert messaging systems there are also demands for withholding subscriber privacy data towards third party and to enable use of the system while not conducting alert message sending for other duties, such as location-based services for e.g. advertising, territorial monitoring and triggering services and non location-based services for e.g. bulk message sending. Basic status and statistics of subscribers, obtained from continuous collection of subscriber and location data through passive location methods, alternatively in combination with collection through active location methods, can be used as initial message sending input, for basic identification and presentation of subscriber and network status and statistics and for basic emergency organizing and scaling purposes. For example, the basic status and statistics can reveal how many and what subscribers are staying within a certain area in total, how many and what subscribers of a certain type, for example nationality, are staying within a certain area or how many and what subscribers within a certain area has received or responded to an (Alert) message.

Active location methods could be used as a complement to passive location methods for example when an UE location (obtained through passive location) proves to be within or close to an area considered being extra vulnerable or important.

The basic status and statistics can give a good (enough) estimate on how the emergency situation affects subscribers and network within a certain area and can give a good (enough) input for (Alert) message sending definitions as well as a good (enough) input for appropriate authorities to e.g. organize and scale rescue or technical operations.

According to some embodiments of the disclosure, the status of the mobile network per cell/LAC can be obtained from the proportion of successful and /or unsuccessful final delivery receipts compared with the number of totally sent messages or intermediate receipts to the cell/LAC.

According to other embodiments of the disclosure, the proportion of received message responses compared with the total number of sent messages to a cell/LAC provides an indication on how severe the situation is within that area.

According to yet other embodiments of the disclosure, the proportion of received message responses requesting assistance or help compared with the total number of received message responses or successful delivery receipts for a cell/LAC provides an indication on the help resources needed and (Alert) message service and subscriber priority settings.

Basic status and statistics are either not based on any subscriber locations at all or based on subscriber locations not collected in real-time, for example, when being collected via continuous passive location methods with sometimes old location updates or otherwise giving old or inaccurate information. For this reason, the status and statistics obtained might not be fully reliable. For example, the subscriber might have roamed outside of the Alert zone or the Alert zone cells and/or LAC(s) might be incorrect or not affected, etc. Detailed subscriber status and statistics obtained from the message delivery receipts and/or message responses with attached real-time (current) location and node information (i.e. the addition of cell_id/SAI_id/LAC and MSC/SGSN information) on the other hand can provide fully reliable information on the emergency situation, e.g. fully reliable information on subscriber (UE) location (or fully reliable information on status plus (UE) location regarding message responses with attached real-time location), affected areas or zones and mobile network status.

The present disclosure enables providing vital information in emergency situations from:

1. basic status and statistics obtained from either discrepancies between results from Intermediate, Final Delivery Receipts and sent messages (without any attached location and/or node data attached to the delivery receipt information sent to and processed and presented by a managing node and client nodes) or from (Alert) message delivery receipt and/or response information with attached last-known location obtained from (continuous) collection of subscriber (UE) location and node information via passive location methods, alternatively in combination with collection via active location methods, in conjunction with alert message preparation and sending;

2. detailed status and statistics obtained from (Alert) message delivery receipt and response information with attached real-time location from on-net subscribers; and/or

3. detailed status and statistics obtained from (Alert) message delivery receipt and response information with attached real-time location from off-net subscribers

Embodiments of the disclosure handle two kinds of delivery receipts per subscriber:

Intermediate Delivery Receipts received for each alert message sending attempt; and

- Final Delivery Receipts (successful/not successful message delivery) received at successful alert message delivery to the user device or when further alert message sending attempts have finally stopped.

To simplify the responding to alert messages; pre-defined message answers can sent along the alert message, for example formulated as: "I'm within affected area, but OK", "I'm within affected area and need immediate help", "I'm not within the affected area and OK", etc.

This could provide a valuable and vital input on how to address the current situation in the area, given that the location of the subscriber is accurate.

Basic status and statistics obtained from Intermediate and Final delivery receipts or from message delivery receipts and responses with attached location obtained from continuous collection of network and subscriber data via passive location methods (alternatively in combination with collection through active location methods) for example in conjunction with Alert message preparation and sending, can give an approximate information on subscribers and the mobile network in the emergency area. Detailed status and statistics derived from Alert message delivery receipts and responses with attached real-time (current) location, however, can in addition to provide a fully reliable information thereof also give (first-hand) real-time reports from well-defined geographic locations either inside, close-by or outside the emergency area (in case of utilizing Alert message response information with attached real-time location).

Basic and detailed status information and statistics can provide information on e.g.: - where the actual center of the emergency area is

whether the defined Alert and Roaming are accurate or needs changing or refining

the total number of subscribers within a (defined) emergency area/AOI/Alert zone/Roaming zone/cell/LAC (based upon geographic area)

- the total numbers of subscribers with a certain Mobile Country Code, i.e. nationality (subscribers per MCC (IMSI)) within a emergency area/AOI/Alert zone/Roaming zone/cell/LAC (based upon area and destination or originating info)

the total number of subscribers with a certain Network Operator (subscribers per MNC (MSISDN)) within a emergency area/AOI/Alert zone/Roaming zone/cell/LAC (based upon area and destination or originating info)

number of subscribers with a specific type of subscription (post and pre-paid) number of subscribers (plus their identity and last-known or real-time location) needing (immediate) assistance or help

health status of subscribers within different areas or zones

- mobile network functionality, e.g. if radio equipment (BTSs/NodeBs) or possibly core equipment (BSCs/RNCs) is out of order due to situation

the proportion between successful final delivery receipts compared with the number of totally sent messages (i.e. the proportion of intermediate versus final delivery reports)

- the proportion between received message responses compared with the total number of successful final delivery receipts

the proportion between received message responses requesting assistance or help compared with the total number of received message responses or successful delivery receipts the proportion between message responses with an attached location not matching the area, cell or LA that the Alert message was sent to

whether the Age Of Location (AOL), Quality Of Location (QOL) and location accuracy subscriber settings are considered accurate or if the need to be upgraded

The basic and detailed status and statistics can be used as input for a variety of changes and improvements, for example be used for identification and presentation network data and subscriber data including location, as input for defining or refining Alert message sending (initially and during message sending) or as input for emergency organizing and scaling purposes (initially or during message sending).

For example, the derived information can provide vital input for Alert message definitions and changes in regards to message content (texts, languages and types), pre-defined message responses, etc. depending on location and priority. It may also become necessary to change Alert and Roaming zones definitions and propagations in regards to obtained status and statistics information. The information also helps fine-tuning the scaling and organization of e.g. rescue and technical personnel.

Upgraded definitions for the Alert message sending and/or emergency areas and zones can either be provided manually, by a system operator through a user interface in the Client and/or Managing nodes, or be handled automatically by the Client and/or Managing node system in accordance with a number of pre-defined rules.

The basic and detailed status and statistics can, with different degrees of accuracy, be utilized for e.g. be utilized for:

defining new or changing or refining old emergency areas' geographic propagation or cells and/or LACs included in the Alert and Roaming zones,

changing or refining Alert message and pre-defined answer content (e.g. text content, language or type) for certain or all subscribers so that accurate information is provided and so that subscribers from different nationalities may get the Alert message text (and predefined answers) in their own language and language coding),

(graphically or by other means) presenting number of subscribers of a certain type within a particular area or all areas,

- (graphically or by other means) presenting number of subscribers of a certain type within a particular area or all areas that an Alert message has been sent to, that has received an Alert message, that has responded an Alert message, etc.,

message sending blocking strategy input,

traffic barring strategy input, defining media statements (e.g. for radio, press and television),

assigning and scaling technical personnel to accurate equipment and/or problem areas,

giving authorities an indication of the magnitude of the incident and help the authorities to scale and optimize emergency and evacuation operations accordingly (according to e.g. number and nationality of subscribers),

helping the police force, the fire brigade or a rescue group to overview the situation and the need and size of operation within an affected area,

helping the network operators to overview the mobile network functionality and scale technical support and provide input for repair teams,

defining new or changing or refining old priorities for Alert message sending Services, subscriber and/or cells,

defining new or changing or refining old subscriber settings in terms of Age Of Location (AOL), Quality Of Location (QOL), location accuracy, etc.

Figure 7 schematically presents an overall system for alert message sending. The system comprises a middleware node (MWN) and an alert messaging node (AMN). An over-all system may also comprise client nodes and a managing node.

The system is connected to a communication network comprising a home location register (HLR), a MSC/SGSN, a BSC (PCU) /RNC and a BTS/NodeB. A user device or mobile station (MS) communicates with the BTS/NodeB.

The HLR in GSM or home subscriber server (HSS) for IP multimedia subsystems (IMS), hereinafter referred to as HLR, is a central database to which mobile subscribers (i.e.

subscriptions), identified via e.g. MSISDN, are permanently assigned for the purpose of storing vital details about the subscriber/subscription, the UE in use, the service(s) required, the user's identification encryption code, and serving network node information. Node information stored in the HLR enables charging and routing of messages towards the MSC or SGSN to which the UE is currently attached.

The MSC, for circuit switched messages, and the SGSN, for packet switched messages, basically handles the switching and routing of messages and often incorporates a VLR that is not shown, which is a database similar to the HLR storing information on the location of subscribers currently visiting the location area having a LAI served by the VLR.

In the mobile network shown in the Figure 7, the VLR and the MSC or SGSN are collocated in the same physical node and hereinafter referred to as MSC/SGSN. The BSC for circuit switched messages, packet control unit (PCU) for packet switched messages, often collocated with BSC or RNC, in UMTS networks, is basically used to control groups of BTSs, in GSM, or NodeBs, in UMTS, and provide the mobility management for subscribers and the connection to the MSC/SGSN.

BTSs and NodeBs are basically transceivers distributed at fixed locations for communication with the UEs over radio links.

The mobile radio network is divided into LA, which represents the area in which a UE can move freely without updating the location to the VLR. Each LA is assigned a unique LAI.

The mobile network is also divided into smaller areas or cells; each served by a

BTS/NodeB and assigned with a unique identity known as CGI in GSM, or SAI in UMTS.

In most emergency situations, it is important to provide fast and accurate information to all individuals within an area exposed to the emergency, whether they are individuals living or working within or close to the emergency area, individuals temporarily visiting the area or any rescue team sent out for handling the emergency.

It is also important to provide a fast and accurate status on subscribers and statistics on how many and who are currently within or close to an emergency area, domestic or foreign, to give authorities an indication of the magnitude of the emergency and help the authorities to e.g. scale evacuation and medical operations in accordance with the number and nationality of the individuals or inform relevant parties, such as hospitals, fire brigades, police forces, press, relatives, etc. of the situation in the area.

The same applies to network technical status too; fast and accurate information regarding the network status in an alert area could provide vital input when e.g. assigning technical support personnel to the area. Fast and accurate status information is also vital when defining what and how information should be sent to the individuals concerned.

Basic handling of alert message delivery receipts (DR) and response according to some illustrative examples related to embodiments of the present invention is described in accordance with Figure 7, for which protocols that are being used are:

Client nodes - Managing node: proprietary interface

Managing node - Middleware node: proprietary interface

Middleware node- Alert Messaging node: standard interface with some proprietary expansions (e.g. SMPP++, MLP++ and protocols over SOAP)

Denotation [1] of figure 1: The last known location of mobile subscribers' UE together with node data is continually or per event collected passively (e.g. via non-intrusive probes on different interfaces or entities in the core and radio access network that extracts information on subscriber, node and cell from traffic passing through or via Charging Data Records (CDRs) fetched from e.g. MSC/SGSNs, Media Devices (MDs) or Billing Systems (BSs)) and stored in the Middleware Subscriber DataBase (SDB). As an (alternative or) complement to passively collected location, the location of mobile subscribers' UE together with node data can on occasion be collected via active location methods (via internal Proxy and GMLC (and SMLC) functionality in the Alert Messaging or Middleware node or initiated by the Middleware node and/or the Alert Messaging node towards and external GMLC (not shown), such as 3GGPP CAMEL PSI/ATI, 3 GPP LCS E-CGI (CGI+TA/CGI+TA+NMR CGI+TA+RTT), OMA SUPL A-GPS or 3GPP LCS A-GPS.

The Middleware SDB preferably uses MSISDN as index if provided, otherwise IMSI. The Middleware Cell DataBase (CDB) stores specific or all cell information for the radio network (per operator), which is continually or event-based updated from radio network planning data and tools. The collection of location and node data can be put on hold when there is no (emergency) services at hand (i.e. no Alert messages to send) and the system is either not in use or used for other purposes, such as e.g. a location-independent Bulk SMSC.

Denotation [2]: At the start of Alert message sending, i.e. during the Initialization Phase, Zone Data Definitions (ZDD) together with any new Message Sending Strategies (message blocking strategies) and/or Barring Strategies are downloaded from the Middleware node to the Alert Messaging node. Any Message Sending Strategy and/or Barring Strategy in current use are uploaded from the Alert Messaging node to the Middleware node to be used when rolling back to initial strategies after that Alert message sending has ended.

The Zone Data Definitions (ZDD) in use during the Initialization Phase are mainly predefined or provisional, e.g. covering especially vulnerable or hazardous zones or zones where incidents have occurred previously.

The Message Sending Strategy (message blocking strategy), preferably sent between the Middleware node and the Alert Messaging node over SOAP, defines the message sending strategy to use for the Alert Messaging node while sending Alert messages (i.e. whether to allow sending of all Alert messages (and block any other message sending), Alert messages from only a certain Service Id, Type or priority, not allow any message sending at all (e.g. during re-configurations) or allow all kind of message sending (e.g. Alert, bulk and advertising message sending). The Barring Strategy defines whether or not to bar, i.e. prohibit, (and later unbar) certain types of non-prioritized subscriber activities (for example calls) in the mobile network during Alert message sending.

Denotation [3]: The Client node or Managing node sends a request for Alert message sending to all subscribers' UE within a particular area (Emergency area) (defined e.g. as a point, circle or polygon coordinates) and with a content (text, type, language and coding) to the Middleware node. The request is specified with a Service Id and Service Type. Messages content could be defined differently dependent on e.g. obtained UE Mobile Country Codes (MCC), Mobile Network Code (MNC), etc.

Denotation [4] : Basic status and statistics of subscribers, obtained from continuous collection of subscriber and location data through passive location methods, alternatively in combination with collection through active location methods, are sent to the Managing node and Client nodes for processing and presentation.

Denotation [5]: The Middleware node starts with investigating if there is already stored a pre-defined Alert zone which corresponds to the emergency area. In one embodiment, if no corresponding pre-defined Alert zone exists, the Middleware creates a new Alert zone including cells that covers the area (i.e. translates the emergency area into cells from data stored in the CDB).

In one example, the Middleware node also defines a Roaming zone surrounding the Alert zone based upon (pre-)defined criterions, such as a default Max Age Of Location (AOL), a default Roaming zone radius, etc., subscriber-specific criterions (Max AOF, QOL, etc. for e.g. emergency personnel), or data from the Managing or Client nodes together with cell data stored in the CDB.

In one example, the Middleware node does not create any Alert zone, but bases Alert message sending directly upon the geographic coordinates for UEs which has proven to be within the emergency area, i.e. the SMPP submit message forwarded to the Alert Messaging node initiating Alert message sending is based upon geographic coordinates alone.

Denotation [6] : The Middleware node then identifies all subscriber UEs that shall receive an Alert message based upon subscriber data stored in the Middleware SDB, Alert and Roaming zone cell or LAC data and/or geographic coordinates.

Denotation [7] : The Middleware node forwards any Alert and Roaming zone identities, if defined, towards the Alert Messaging node as an updated Zone Data Definitions (ZDD) file together with any updated Message Sending and Barring Strategies and sends an Alert message sending initiating message to all subscriber UEs within the Alert and Roaming zones or with geographic coordinates that corresponds to the emergency area towards the Alert Messaging node.

In one example of embodiments of the present disclosure, the Alert message sending initiating message is sent from the Middleware node to the Alert Messaging node as an SMPP submit message.

In another example of embodiments of the present disclosure, the initiating message is sent as an SMPP submit multi message. This embodiment includes handling and exports of Distribution Lists (DL), defining all destination addresses, for example over http towards the Alert Messaging node.

According to one example of embodiments of the present disclosure, the initiating message contains information on destination subscriber UE information, e.g.

MSISDN/IMSI/LMSI, message content and type, subscriber priority, etc., node information (MSC/SGSN), cell information (CGI/SAI), geographic coordinates, Quality of Location (QOL) and Max Age Of Location (AOL).

In one example of embodiments of the present disclosure, the cell id is forwarded in the cell info if the subscriber UE's last known location is within the Alert zone, but not forward in case the subscriber UE's last known location is within the Roaming zone, but outside of the Alert zone. In the same embodiment, this forces an active UE location, for example a PSI location, which updates the current cell id for the UE.

According to one example of embodiments of the present disclosure, the Alert message sending initiating message also contains Alert message sending Service Id and Type.

Denotation [8] : When the SMPP submit or submit multi initiating messages are received by the Alert Messaging node, a Store And Forward (SAF) module, which basically handles the storing, sending and resending of messages per destination address, first queues all incoming messages per MSISDN if obtained, otherwise per IMSI/LMSI. SAF also includes a cache, where all last known locations (cell ids, LACs and/or geographic coordinates) are cached.

The SAF handling of messages, i.e. the sending, resending and forwarding of messages, depends on Service Id, Type and priority, subscriber priority, which Message Sending and Barring Strategies has been defined and on whether the messages should be forwarded and handled and queued by the Cell Load Balancer or forwarded and handled by conventional message sending means, the latter for example when normal or bulk sending activities.

Denotation [9] : Based on Service Id, Type and priority, subscriber priority and which Message Sending and Barring Strategies has been defined, queued messages in the SAF may then be outputted and forwarded towards the Cell Load Balancer (CLB), which distributes the messages into queues indexed per cell, LAC and paging type. The identity of the cells and/or LACs that are indexed in the CLB queues derived from ZDD information received. The CLB then divides messages into separate queues per cells, LACs, priorities and paging type, and then initiates sending of Alert messages on one sending process per cell and/or LAC parallel in time for all cells and/or LACs concerned.

Denotation [10]: The sending of Send Routing Information for Short Message (SRI-SM) for MSISDN sent towards the HLR to get IMSI and MSC/SGSN address is excluded due to already obtained in denotation [1].

Denotation [11]: The actual Alert message is then sent in form of a Mobile Terminated Forward Short Message (MT-FSM) towards the Mobile Switching Centre (MSC) (if circuit switched network) or Serving GPRS Support Node SGSN (if packet switched network) with IMSI as Destination Address (DA) for all UEs that shall receive the message.

Denotations [12 - 14]: Messages are forwarded towards the Base Station Controller (BSC) (if circuit switched network) or Packet Control Unit (PCU) (if packet switched network - often collocated with B SC) or Radio Network Controller (RNC) (if UMTS) [12], then towards the Base Transceiver Station (BTS) / Node B (UMTS) [13] and the UE [14].

Delivery Status result (RSMDS) may be excluded due to saving network capacity.

Denotations [15 - 21]: According to examples of embodiments of the present disclosure, the Alert Messaging node processes and stores: received Alert message responses, denotation [16], from the MSC/SGSN in case the subscriber manually responses to the Alert message denotation [15]; Final Delivery Receipts [17] when the message has been duly received by the subscriber or the message sending attempts are finally stopped; and Intermediate Delivery Receipts when a message sending has been attempted [18].

Information on message responses and delivery receipts per subscriber (MSISDN/IMSI) could, according to embodiments of the present disclosure, be stored in SAF and/or be forwarded via e.g. SMPP towards the Managing and/or Client nodes via the Middleware node, if basic status and statistics are so requested by the Managing and/or Client nodes.

If the SAF Cache has knowledge of the UE's last known location (cell ids, LACs and/or geographic coordinates), one embodiment of the present disclosure attaches this, see denotation [20], to the message response and delivery receipt information forwarded to the Managing and/or Client nodes via the Middleware node. If the SAF Cache does not have knowledge of the UE's last known location, another embodiment of the present disclosure attaches the UE's last known location stored in the Middleware node SDB, denotation [21], to the message response and delivery receipt information forwarded to the Managing and/or Client nodes. In one example of embodiments of the present disclosure, when the Managing or Client nodes receives the message response or delivery receipt information, it uses recipient

(subscriber) message id and a prefix in the destination to derive which Alert Service the response or delivery receipt refers to. The Alert Service can then use recipient message id and the suffix in the destination to derive which submit message it refers to or alternatively use the source address, source MSISDN and/or source IMSI to derive which MSISDN and/or IMSI it refers to.

In one example of embodiments of the present invention, the response and/or delivery receipt including subscriber (MSISD/IMSI), node (MSC/SGSN info) and last known cell information (cell_id/SAI_id/LAC) are used to monitor and present the progress of Alert message sending, refine message sending and organize technical and rescue resources for the areas and zones concerned. Note however that since this method only utilizes last known location, which can be outdated, the attached location information might not be fully reliable. In the following, on-net detailed status and statistics derived from message responses and delivery receipts with attached real-time location, will be discussed to some extent.

If one knew exactly where the subscriber UE was at the time information on Alert message delivery receipts and/or message response was received, it could provide vital input for handling the emergency situation.

According to embodiments of the present disclosure, this is solved by attaching the current real-time location and node info (i.e. the cell_id/SAI_id/LAC and MSC/SGSN info) of the UE to delivery receipt and/or message response information that can be processed and presented to e.g. emergency personnel at the Managing or Client nodes.

Such intermediate delivery receipt information with attached real-time location and node info could provide current information on where the UE is located and serving node at the time when the Alert message sending was being attempted by the Alert Messaging node.

Such final delivery receipt information with attached real-time location and node info could provide current information on where the UE is located and serving node at the time when the Alert message been duly received by the subscriber, i.e. when the Alert Messaging node receives a successful delivery response from the MSC/SGSN, alternatively when the message sending attempts has been finally stopped. A message response, either pre-defined or manually entered by the subscriber, with attached real-time location and node info could provide current information on where the UE is located and serving node at the time when the response was done.

All the above information provides vital and reliable information on the emergency situation, needed for planning and organizing technical and rescue resources as well as for refining and fine-tuning Alert message sending. The refining of Alert message sending in regards to emergency area, alert zone, roaming zone and message content.

For instance, if the location results from received delivery receipts and/or message responses proves to be outside of the affected area, either the Alert zone(s) definitions or the cell definitions, i.e. radio network data, need to be updated or refined.

The message responses, pre-defined or manually entered by the message receiver, in themselves can also give vital information on the situation. For instance, if several subscribers within a specific cell or area indicate in their responses that the incident does not seem to have affected the area they are currently located in, the priority for all those subscribers, cell(s) and/or alert area(s) or zone(s) might be set lower, alternatively that no more Alert messages will be sent to these.

According to some embodiments of the present disclosure it is possible for Managing and/or Client node emergency personnel or operators to pre-define one or several Service- specific Alert message service answers previous to sending. The subscriber that receives an Alert message then has the possibility to either use this pre-defined answer when answering the message or manually enter an answer by himself. As the emergency situation might be stressful and/or the subscriber may be injured, it should be easier to just choose between the pre-defined answers than to enter one manually.

Examples on pre-defined answers that gives the emergency personnel vital information are e.g.: 1) "I'm not within an emergency area and I'm OK", 2) "I'm within an emergency area, but OK", 3) "I'm within an emergency area and need help, but not urgently" and 4) "I'm within an emergency area and need immediate help!".

In order to keep subscriber privacy under control for a Network Operator, subscriber identities, including the subscriber identities for subscribers responding to Alert messages, are normally kept anonymously (made unidentifiable) towards third party Alert Applications. When passing subscriber information outside of the network operator's control, the MSISDN and/or IMSI/LMSI are therefore normally encrypted. However, when receiving either pre-defined answers or personal answers to Alert messages stating that the subscriber needs help, one embodiment of the present disclosure passes Alert message subscribers' information unencrypted to the third party, so that it is possible to identify subscribers requesting help and make direct contact.

One preference order is:

1) Internal Proxy and GMLC functionality in the Alert Messaging node,

2) Proxy in the Alert Messaging node and GMLC functionality in the Middleware node,

3) Proxy in the Alert Messaging node and external GMLC

The on-net handling of Alert message delivery receipts (DR) and responses, i.e. the (service-specific) proxying and information feedback to the Managing and Client nodes, with addition of subscriber info (MSISDN/IMSI/LMSI), real-time location info (CGI/SAI/LAC) and node info (MSC/SGSN) of the present disclosure is described in accordance with Figure 8.

The described process covers Alert messages in the form of SMS in GSM and UMTS mobile networks, but since the handling of other type of messages, such as USSD and MMS messages, and messages in other mobile network standards principally are the same; the description also applies for these.

Denotation [0]:The subscriber decides to send a response to the previously received Alert message. Depending on UE and/or network operator preferences, the response message is either using a provided Reply Path (RP=Y) or not (RP=N). When the Reply Path is used (see below), the message response is sent with the Alert Messaging node as serving SMSC address. When no Reply Path is used, the message response is sent with the Originating SMSC (O-SMSC) that normally serves the MS as serving SMSC address. The message response includes:

1) Destination Address (DA), with the originating/source address (prefix & suffix) from the previously received Alert message.

2) Originating Address (OA), with the destination address (MSISDN) from the previously received Alert message.

3) Reply Path (RP), with content (yes, no) according to UE and/or network operator preferences.

4) Service Centre Address (SCA), with Alert Messaging node address (when using Reply Path (=Y)) or O-SMSC address (when not using Reply Path (=N)) Reply Path are normally not used, i.e. any message response to the Alert message is then sent via the Originating SMSC (O-SMSC) that normally serves the UE (and not via the Alert Messaging node)

Denotation [1]: Also depending on UE and/or network operator preferences, the response message is sent via either the MSC(/VLR) (normally) or SGSN (unusual).

If the UE decides to use a circuit switched bearer, the MS sends the response message to the MSC/VLR via BTS/Node B and BSC(SCU)/RNC.

If the UE decides to use a packet bearer, the UE sends the response message to the SGSN via BTS/Node B and BSC(SCU)/RNC.

Denotation [2] : If Service Centre Address (SCA) indicates the O-SMSC, the MSC/SGSN forwards the message response to the O-SMSC [2a] and if SCA indicates the Alert Messaging node, the MSC/SGSN forwards the message response to the Alert Messaging node [2b].

Denotation [3]: If so configured (i.e. SCA = Alert Messaging node and the Alert Messaging node receives the message response), the Alert Messaging node sends an SRI-SM to the HLR that serves the Originating Address, i.e. the MSISDN.

A successful SRI-SM response includes IMSI for the MSISDN. If the SRI-SM response is unsuccessful or if the IMSI returned is not part of the Alert Messaging node served IMSI number series but a Reply Path is stored for the MSISDN in the Alert Messaging node, the execution still continues since the received message response includes Reply Path. However, if no such Reply Path is stored for the MSISDN in the Alert Messaging node, the message response is rejected and the execution ends.

It is noted that the Reply Path for the MSISDN is created in the Alert Messaging node if the original Alert message (for which the message response is returned) sent to the MSISDN included Reply Path=Yes. The Alert Messaging node keeps such a Reply Path for the MSISDN during an operator-defined period or until the message response with Reply Path=Y is received from the MSISDN.

Denotation [4]: The O-SMSC [4a] or Alert Messaging node [4b] then sends an SMPP deliver_sm/data_sm to the client in the Alert Messaging node Proxy given by the prefix in the message response included Destination Address, including:

- Destination, with the message response included Destination Address (prefix & suffix), i.e. the Source (prefix & suffix) from submit_sm/data_sm for the Alert message

Source, with the message response included Originating Address (MSISDN), i.e. the Destination (MSISDN) from submit_sm/data_sm for the Alert message, or the MSISDN retrieved from HLR by the Alert Messaging node for the Destination (IMSI) from

submit_sm/data_sm for the Alert message

Servicejype

Protocoled

Datacoding

Priority_flag, as configured in the O-SMSC or Alert Messaging node, defining if the Alert message is a priority message.

Optionally: Source_bearer_type, indicating e.g. SMS

Denotation [5]: If Alert Messaging node Proxy analysis of the Destination Address (prefix & suffix) in the SMPP deliver_sm/data_sm from the O-SMSC [4a] or Alert Messaging node [4b] indicates that the MSISDN location is to be retrieved, the Proxy sends a location request (MLP SLIR) command to the internal GMLC functionality [5a], to the GMLC functionality in the Middleware node [5b] or to the external GMLC [5c] (either directly or via the Middleware node).

Denotation [6]: When the GMLC (functionality) receives the location request (MLP SLIR), it sends an CAMEL Send Routing Information for Short Message (SRI-SM) to the HLR that serves the MSISDN [6a, 6b or 6c] . A successful SRI-SM response then includes IMSI (and LMSI, if applicable) and Msc id and/or Sgsn id (including LAC) for the MSISDN. If the SRI- SM response is unsuccessful, the GMLC (functionality) returns a location response (MLP SLIA) to the Alert Messaging node Proxy indicating unsuccessful request and the execution ends in GMLC (functionality). If both Msc_id and Sgsn_id for the MSISDN are known, the selection whether to send a CAMEL Provide Subscriber Information (PSI) towards the MCS or the SGSN is defined by a GMLC (functionality) internal analysis.

Denotation [7]: If IMSI and an Msc id was received in SRI SM Response and PSI is allowed for the Msc id, a PSI is sent for the IMSI (and LMSI, if known and allowed for the MSC/VLR) to the MSC given by the Msc_id [7a, 7b or 7c]. A successful PSI Response includes CGI or SAI (and LAC)) and Age of location.

If IMSI and a Sgsn id was received in SRI SM Response and PSI is allowed for the Sgsn_id, a PSI is sent for the IMSI to the SGSN given by the Sgsn_id [7a, 7b or 7c]. A successful PSI Response then includes CGI or SAI (and LAC) and Age of location. Denotation [8]: The GMLC (functionality) then sends a location response (MLP SLIA) [8a, 8b or 8c] to the Alert Messaging node Proxy including e.g.:

Msid = MSISDN

Msidjype = "MSISDN"

- Result

Time, with Age Of Location, if known, otherwise time of request Optionally: IMSI, if know, for the MSISDN

Optionally: LMSI, if know, for the MSISDN

Optionally: Msc_id, if know, for the MSISDN

- Optionally: CGI if know, for the MSISDN

Optionally: Sgsn_id, if know, for the MSISDN

Optionally: SAI, if know, for the MSISDN

Denotation [9] : The current real-time node and location info from the location response is stored in the Alert Messaging node Cache [9a] as well as in the Middleware node SDB [9b] (in the next denotation).

Denotation [10]: The Alert Messaging node Proxy then sends an SMPP

deliver_sm/data_sm via the Middleware node towards the Managing node given by the prefix in the message response included Destination Address, which may include:

- Destination, the same Destination as received from the O-SMSC or Alert

Messaging node, i.e. with the message response included Destination Address (prefix & suffix), i.e. the Source (prefix & suffix) from submit_sm/data_sm for the Alert message

Source, the same Source as received from the O-SMSC or Alert Messaging node, i.e. with the message response included Originating Address (MSISDN), i.e. the Destination (MSISDN) from submit_sm/data_sm for the Alert message, or the MSISDN retrieved from HLR by the Alert Messaging node for the Destination (IMSI) from submit sm for the Alert message

Priority_flag, the same Priority_flag as received from the O-SMSC or Alert Messaging node, i.e. defining if the Alert message is a priority message

- Optionally: Source lMSI, defining the IMSI for the MSISDN and taken from the location response (SLIA) provided IMSI, included if provided and allowed to be included for the SMPP client Optionally: Source LMSI, defining the LMSI for the MSISDN and taken from the location response (SLIA) provided LMSI, included if provided and allowed to be included for the SMPP client

Optionally: Source msc id, i.e. source msc addr, source msc addr npi, source_msc_addr_ton, defining the Msc_id for the MSISDN and taken from the location response (SLIA) provided Msc id, included if provided and allowed to be included for the SMPP client

Optionally: Source_sgsn_id, i.e. source_sgsn_addr, source_sgsn_addr_npi, source_sgsn_addr_ton, defining the Sgsn_id for the MSISDN, and taken from the location response (SLIA) provided Sgsn id, included if provided and allowed to be included for the SMPP client

Optionally: Source_cell_global_id, i.e. source_cgi_mcc, source_cgi_mnc, source_cgi_lac, source_cgi_ci, defining the Cell Global Identity for the MSISDN and taken from the location response (SLIA) provided CGI (mutually exclusive with SAI), included if provided and allowed to be included for the SMPP client

Optionally: Source_service_area_id, i.e. source_sai_mcc, source_sai_mnc, source_sai_lac, source_sai_sac, defining the Service Area Identity for the MSISDN and taken from the location response (SLIA) provided SAI (mutually exclusive with CGI), included if provided and allowed to be included for the SMPP client

Optionally: Source loc age, defining the Age Of Location of CGI/SAI for the MSISDN and taken from the location response (SLIA) provided Age Of Location, included if provided (i.e. when the location response (SLIA) Time is Age Of Location, not the time of request) and allowed to be included for the SMPP client

Denotation [11]: When receiving the deliver_sm/data_sm, the Managing node can e.g. use the prefix in the Destination to derive which Client node the message response refers to.

Denotation [12]: The SMPP deliver_sm/data_sm is then sent towards the accurate Client node, where the Client node can use e.g. the suffix in the Destination to derive which Alert message Service this message response refers to. The responding MSISDN is given by the Source. The Client node can also use the Source_IMSI to derive which IMSI this message response is from.

According to some embodiments of the present disclosure, the current real-time node and location info from an active location, e.g. by sending an SRI-SM to the HLR that serves the MSISDN [6a, 6b or 6c] followed by sending a PSI for the IMSI (and LMSI, if known and allowed for the MSC/VLR) to the MSC given by the Msc_id [7a, 7b or 7c] in accordance with step 5 - 9 above, is attached to the intermediate and final delivery receipt information that are sent to the Managing and/or Client nodes.

Denotation [13]: Some embodiments of the present disclosure initiates active location, either default for all Alert message delivery receipts (not preferred due to the increased traffic in the network) or for certain message delivery receipts (e.g. when so requested for certain message delivery receipts by the Alert messaging service defined in the Managing or Client nodes and by Destination Address (prefix & suffix) analyses in the Alert Messaging node Proxy), and attaches the retrieved current real-time node and location info stored in the Alert Messaging node Cache [9a] to the Alert message delivery receipt information sent to the Managing node via the Middleware node [13].

As some embodiments of the present disclosure stores message responses and delivery receipts in the Alert Messaging node SAF and requested location results (or last known location if an active location has not been requested) in the SAF Cache, the matching of real-time location and message responses and/or delivery receipts can be done during Alert message sending as well as after sending has been finished.

In some embodiments, where the last known locations are not stored in the SAF Cache, the location information could be obtained from the Middleware node SDB.

Denotation [14]: When receiving the Alert message delivery receipt information, the Managing node can use e.g. the recipient message id and the prefix in the Destination to derive which Client node and Alert Service the delivery receipt refers to.

Denotation [15]: The Alert message delivery receipt information is then sent towards the accurate Client node, where the Client node can use e.g. the prefix in the Destination to derive which Alert Service this message delivery receipt refers to.

The Alert Service can then use recipient message id and the suffix in the destination to derive which submit message this delivery receipt refers to. The Alert Service can also use the source address, source MSISDN and/or source IMSI to derive which MSISDN and/or IMSI this delivery receipt refers to.

The delivery receipt includes subscriber, node and real-time (or last known, if an active location has not been requested) cell and LAC information which could be used e.g. to monitor the progress of Alert message deliveries and to e.g. alert technical and emergency personnel to plan for emergency actions. Off-net detailed status and statistics derived from message responses and delivery receipts with attached real-time location, will now be discussed.

When handling Alert message responses from off-net subscribers (from foreign or visiting subscribers), the 'Global SMSC functionality in Alert Messaging node, i.e. the incorporated virtual HLR and MSC/SGSN functionality, handles the incoming SRI-SM and MT-FSM from the off-net O-SMSC and the onward routing.

One preference order is:

1) Internal Proxy and GMLC functionality + Global SMSC functionality in the Alert Messaging node

2) Internal Proxy + Global SMSC functionality in the Alert Messaging node and

GMLC functionality in the Middleware node

3) Internal Proxy + Global SMSC functionality in the Alert Messaging node and external GMLC

The real-time off-net handling of Alert message responses (proxying and feedback) with addition of subscriber info (MSISDN/IMSI/LMSI), cell info (CGI/SAI/LAC) and node info (MSC/SGSN) of the present disclosure is described in accordance with Figure 9.

The described process covers Alert messages in the form of SMS in GSM and UMTS mobile networks as in previous figures, but since the handling of other type of messages, such as USSD and MMS messages, and messages in other mobile network standards principally are the same; the description also applies for these.

For real-time off-net Alert message responses:

Denotation [0] : The off-net subscriber decides to send a response to the previously received Alert message.

As Reply Path cannot be used, the message response includes:

Denotation [1]: Depending on UE and/or network operator preferences, the response message is sent via either the MSC(/VLR) (normally) or SGSN (unusual).

If the UE decides to use a circuit switched bearer, the MS sends the response message to the MSC/VLR via BTS/Node B and BSC(SCU)/RNC. If the UE decides to use a packet bearer, the UE sends the response message to the SGSN via BTS/Node B and BSC(SCU)/RNC.

Denotation [2] : Due to that Reply Path cannot be used for off-net subscribers, all message responses are sent via the off-net O-SMSC that normally serves the UE, i.e. the

MSC(VLR)/SGSN forwards the responses to the off-net O-SMSC SCA indicated in the response.

Denotation [3]: In order to obtain IMSI and MSC/SGSN address, the off-net O-SMSC sends an SRI-SM towards the virtual HLR in the Alert Messaging node Global SMSC functionality that has been configured serving the Originating Address (MSISDN). A successful SRI-SM response includes a special IMSI/LMSI for the MSISDN and the virtual MSC/SGSN in the Alert Messaging node Global SMSC functionality as MSC/SGSN address.

Denotation [4]: The off-net O-SMSC then sends the MT-FSM to the virtual MSC/SGSN that has been obtained in the SRI-SM response.

Denotation [4,5]: In some embodiments of the present disclosure, the Global SMSC then sends an SMPP deliver_sm/data_sm to the client in the Alert Messaging node Proxy given by the prefix in the message response included Destination Address, and including e.g.:

Destination, with the message response included Destination Address (prefix & suffix), i.e. the Source (prefix & suffix) from submit_sm/data_sm for the Alert message

submit_sm/data_sm for the Alert message

Servicejype

Protocoled

- Datacoding

Priority_flag, as configured in the O-SMSC or Alert Messaging node, defining if the message is a priority message.

Optionally: Source_bearer_type, indicating message type Denotation [5 - 14]: Fully corresponds to the steps described under Alert Messaging node on-net message responses and delivery receipt with attached real-time location of Figure 8.

Thus, to reveal the status and location of message responses from on-net and off-net subscribers, internal proxy and GMLC functionality can be utilized for the inclusion of last known or real-time (current) location in Alert message delivery receipts and responses for on- net subscribers and internal Global SMSC plus proxy and GMLC functionality for the inclusion of last known or real-time (current) location in Alert message responses for off-net subscribers, respectively.

One skilled in the art will also appreciate that the present disclosure is not limited to the embodiments or the combined embodiments disclosed in the enclosed drawings and the foregoing description, which are presented for purposes of illustration only, but it can be implemented in a number of different ways, as defined by the following claims.

It should be appreciated by those skilled in the art that the conception and specific embodiment disclosed might be readily utilised as a basis for modifying or designing other structures for carrying out the same purposes of the present disclosure. For instance, nodes may be combined or co-located but are preferably separated due to that nodes handle different interfaces and protocols.

It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the disclosure as set forth in the appended claims

It must be emphasized that this disclosure may be varied in many ways.

The elements of an embodiment of this disclosure may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a plurality of units or as part of other functional units. As such, this disclosure may be implemented in a plurality of units, or may be physically and functionally distributed between different units and processors.

It is made clear that presented embodiments may well be combined forming new embodiments not explicitly described herein. Explicit embodiments of methods in one or more nodes as presented herein may thus be combined with embodiments of the corresponding nodes, producing embodiments of nodes comprising features and/or functions of said embodiments of methods of the present disclosure.

Advantages of embodiments of the present invention comprise that it enables enhanced alert message sending management and alert message related emergency

management. This enables, for instance,

defining media statements (e.g. for radio, press and television); assigning and scaling technical personnel to accurate equipment and/or problem areas; giving authorities an indication of the magnitude of the incident and help the authorities to scale and optimize emergency and evacuation operations accordingly (according to e.g. number and nationality of subscribers);

defining new or changing or refining old priorities for Alert message sending Services, subscriber and/or cells; and

- defining new or changing or refining old subscriber settings in terms of Age Of

Location (AOL), Quality Of Location (QOL), location accuracy, etc.

In the claims, the term "comprises/comprising" does not exclude the presence of other elements or steps. Additionally, although individual features may be included in separate claims, these may be combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. In addition, singular references do not exclude a plurality. The terms "a", "an", "first", "second" etc. do not preclude a plurality. Reference signs in the claims are provided merely as a clarifying example and shall not be construed as limiting the scope of the claims in any way.

Although this disclosure has been described above with reference to specific

embodiments, it is not intended to be limited to the specific form set forth herein. Rather, this disclosure is limited only by the accompanying claims and, other embodiments than the specific above are equally possible within the scope of these appended claims.

Claims

A method for providing network status and/or user status information for enhanced alert message sending management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network, the method being performed in an alert messaging node (400, 602) of an alert messaging system, the method comprising:

receiving (102) feedback information to the sending of alert messages to said user devices,

determining (104) network status and/or user status information, based on the feedback information; and

providing (106) the determined network status and/or user status information, enabling said enhanced alert message sending management and alert message related emergency management.

The method according to claim 1, where alert message sending comprises attempting to send alert messages, and wherein receiving (102) feedback information comprises receiving intermediate delivery receipts having information of each attempted alert message sending to the user devices.

The method according to claim 1, wherein receiving (102) feedback information comprises receiving final delivery receipts having information about successful delivery of alert messages to the user device.

The method according to any of claims 1 to 3, wherein receiving (102) feedback information comprises receiving an alert message response from user devices to which an alert message was sent.

The method according to any of claims 1 to 4, further comprising obtaining a last-known location of user devices from passive location methods and caching said last known location in a location cache of the alert messaging node.

The method according to claim 5, further comprising providing the last-known location of user devices.

7. The method according to any of claims 1 to 6, further obtaining a real time location of a user device of the user devices from active location methods via an internal proxy and Global Mobile Location Center, GMLC, functionality or via external proxies, GMLCs and Mobile Location Centers, MCSs.

8. The method according to any of claims 1 to 6, further comprising obtaining a real time location of a user device of the user devices, based on requesting said real time location from a middleware node connected to the alert messaging node. 9. The method according to claim 7 or 8, further comprising providing the real time location of a user device of the user devices.

10. The method according to any of claims 1-9, further comprising providing into sent alert messages a destination address, DA, with originating/source address from alert messages previously received, and an originating address, OA, with destination address from the previously received alert message.

11. The method according to claim 10, further comprising handling incoming SRI-SM in a virtual home location register in the alert messaging node global SMSC functionality, being configured to serve the originating address.

12. The method according to claim 10 or 11, further comprising providing a send routing information for short message, SRI-SM, response including a special IMSI/LMSI for the originating address, and the virtual MSC/SGSN in the alert messaging node global SMSC functionality as MSC/SGSN address.

13. The method according to any of claims 10 to 12, further comprising handling and routing incoming MT-FSM in the virtual MSC/SGSN towards the MWN. 14. A method for providing network status and/or user status information for enhanced alert message sending management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network, the method being performed in a middleware node (500, 604) of an alert messaging system, the method comprising: receiving (202) network status information and/or user status information of user devices to which alert messages were sent;

obtaining (204) location information of a user device of the user devices to which alert messages were sent; and

- providing (206) the location information of a user device of the user devices; and the obtained network status information and/or user status information, enabling enhanced alert message sending management and alert message related emergency management. 15. The method according to claim 14, wherein obtaining (204) location information of a user device comprises retrieving information about the location of a user device by using passive user device location methods, optionally in combination with active user device location methods. 16. The method according to claim 14 or 15, wherein obtaining (204) location information of a user device comprises obtaining, or receiving from an alert messaging node, information about a last known location of said user device.

17. The method according to claim 16, further comprising storing the last known location in a user database of the middleware node.

18. The method according to claim 15, wherein retrieving information about the location of a user device by using passive user device location methods comprises using non-intrusive probing on communication network interfaces or location information derived from Event Managers or Charging Data Records, CDRs.

19. The method according to claim 14 or 15, wherein obtaining (204) location information of a user device comprises obtaining real-time location information of a user device. 20. The method according to any of claim 14, 15 or 19, wherein obtaining (204) real time location information of a user device comprises deriving the real time location from active location methods via internal proxy and GMLC functionality in the middleware node.

21. The method according to any of claim 14, 15 or 19, wherein retrieving information about the location of a user device by using active user device location methods, comprises using active user device location methods comprising using Provide Subscriber

Information, PSI, for International Mobile Subscriber Identity, IMSI, Land Mobile Subscriber Identity, LMSI, towards Mobile Switching Centre, MSC, or Serving General

Packet Radio Service Support Node, SGSN, alternatively Customized Applications for Mobile network Enhanced Logic, CAMEL, Any Time Interrogation, ATI, for Mobile Station International, Integrated Service Digital Network Number, MSISDN, towards Home Location Register, HLR, the retrieval of MSISDN and/or serving MSC/SGSN address for the user device comprises using Send Routing Information for Location

Services, SRI-LCS, for user device International Mobile Subscriber Identity/Land Mobile Subscriber Identity, IMSI/LMSI, towards HLR and the retrieval of IMSI/LMSI and/or serving MSC/SGSN address for the user device comprises using Send Routing

Information for Short Message, SRI-SM, for user device MSISDN towards HLR in the communication network.

22. The method according to any of claims 14 to 21, further comprising determining alert message managing input information for a specific geographical area based on at least one of: a proportion between successful final delivery receipts, DRs, and total number of alert messages sent to said specific geographical area; a proportion between unsuccessful final DRs and total number of alert messages sent to said specific geographical area; and a proportion between intermediate DRs and total number of alert messages sent to said specific geographical area. 23. The method according to any of claims 14 to 22, further comprising determining alert message managing input information for a specific geographical area based a proportion between message responses requiring assistance or help, and message responses requiring neither assistance nor help. 24. A method for providing network status and/or user status information for enhanced alert message sending management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network, the method being performed in an alert messaging system (600), the method comprising: receiving (302) feedback information to the sending of alert messages to said user devices,

obtaining (304) location information of a user device of the user devices to which alert messages were sent;

determining (306) network status and/or user status information, based on the feedback information; and

providing (308) the location information of a user device of the user devices, the obtained network status information and/or user status information, enabling enhanced alert message sending management and alert message related emergency management.

The method according to claim 24, wherein alert message sending comprises performing sending attempts of alert messages, and wherein receiving (302) feedback information comprises receiving intermediate delivery receipts having information about each performed sending attempt of alert messages.

26. The method according to claim 24, wherein receiving (302) feedback information

comprises receiving final delivery receipts having information about successful delivery of alert messages to the user device.

27. The method according to any of claims 24 to 26, wherein obtaining location information of a user device comprises obtaining information about a last known location of a user device.

The method according to any of claims 24 to 27, wherein obtaining location information of a user device comprises obtaining real-time location information of a user device.

The method according to any of claims 24 to 28, further comprising determining alert message managing input information for a specific geographical area based on at least one of: a proportion between successful final delivery receipts, DRs, and total number of alert messages sent to said specific geographical area; a proportion between unsuccessful final DRs and total number of alert messages sent to said specific geographical area; and a proportion between intermediate DRs and total number of alert messages sent to said specific geographical area.

30. system The method according to any of claims 24 to 29, further comprising determining alert message managing input information for a specific geographical area based a proportion between message responses requiring assistance or help, and message responses requiring neither assistance nor help.

31. An alert messaging node (400, 602) configured to provide network status and/or user status information for enhanced alert message management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network, the alert messaging node comprising: a processor (402); and

a memory (404) storing computer program comprising computer program code which, when run in the processor, causes the alert messaging node to:

receive (102) feedback information to the sending of alert messages to said user devices,

determine (104) the network status and/or user status information , based on the feedback information; and

provide (106) the determined network status and/or user status information, enabling enhanced alert message sending management and alert message related emergency management.

32. An alert messaging node according claim 31, wherein the computer program code causes the alert messaging node to comprise internal proxy and global mobile location center, GMLC, functionality for on-net subscribers.

33. An alert messaging node according claim 31 or 32, wherein the computer program code causes the alert messaging node to comprise internal global short message center plus proxy and global mobile location center functionality for off-net subscribers. 34. An alert messaging node according to any of claims 31 to 33, wherein the global short message service center, SMSC, functionality comprises home location register and MSC/SGSN functionality to attach location information and node information to alert message feedback, being message responses only, routed via off-net originating-SMSCs. A middleware node (500, 604) configured to provide network status and/or user status information for enhanced alert message management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network, the middleware node comprising:

a processor (502); and

a memory (504) storing computer program comprising computer program code which, when run in the processor, causes the middleware node to:

receive (202) network status and/or user status information of user devices to which alert messages were sent;

obtain (204) location information of a user device of the user devices to which alert messages were sent; and

provide (206) the location information of a user device of the user devices; the obtained network status information and/or user status information, enabling enhanced alert message sending management and alert message related emergency management.

An alert messaging system (600) configured to provide network status and/or user status information for enhanced alert message management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network, the alert messaging system comprising; an alert messaging node (400, 602) according any of claims 31 to 34; and a middleware node (500, 604) according to claim 35.

A computer program comprising computer program code which, when run in a processor (402) of an alert messaging node (400), causes the alert messaging node being configured to provide network status and/or user status information for enhanced alert message management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network, to: receive (102) feedback information to the sending of alert messages to said user devices,

determine (104) the network status and/or user status information, based on the feedback information; and provide (106) the determined network status and/or user status information, enabling enhanced alert message sending management and alert message related emergency management.

A computer program comprising computer program code which, when run in a processor (502) of a middleware node (500), causes the middleware node being configured to provide network status and/or user status information for enhanced alert message management and alert message related emergency management, for which alert messages are sent to user devices in a specific geographical area of a communication network, to: receive (202) network status and/or user status information of user devices to which alert messages were sent;

provide (206) the location information of a user device of the user devices, the obtained network status information and/or user status information, enabling enhanced alert message sending management and alert message related emergency management.