Main entities and roles MNO’s Emergency Infrastructure:

General SchemaEmergency Manager moduleEmergency API - Agency InterfaceGeneral Call flowGIS Manager moduleLocation Mgmt moduleNotification Mgr module ReportingAdministration

National infrastructureComments & Conclusions

Contents

Main Entities and Roles

National Government:• Being a solution for the country population, theGovernment must impose general rules and policiesto other regional/local authorities, Agencies andMobile Operators acting as coordinators in theEmergency project.• Establish the Emergency & Alert DetectionSystems

Agencies:• There are organisms like 112 or 911.• Adopt Government’s guidelines• Receive events and info from Detection Systems• Determine emergency situations initiating theprocess with the Mobile Operator’s systems.

Mobile Operators (MNOs):• Adopt Government’s guideline• Establish the adequate dialog with the Agencies• Execute the emergency process for detecting theirsubscribers that are involved in the alert and notifythem through available channels .

Automatic/ Manual systems capable of generating alerts in special situations

(bushfires, earthquakes, tsunamis, hurricanes, volcanic

eruptions, terrorism, etc)

Receive the alerts and establish the emergency situation within other

organisms such as Police, Fire Brigade, Health Care organizations, …)

Emergency Detection Systems

Agencies

Receive the emergency area from the Agencies and proceed to

identify the affected population notifying them with the adequate

message

Mobile Operators

Network

Agency

MNO’s Emergency infrastructure – General Schema

Emergency Mgr

Oth

er M

NO

’s system

s/capacities

Location Mgmt

Agency

GIS Mgr Ad

min

Too

ls

The proposed emergency middleware is composed by 5 main modules:Emergency Mgr: Front-end with the Agencies and coordinator of the

emergency processes.GIS Mgr: Translate or convert the original emergency area into

Network parameters, in general, a list of cells that match with this area.

Location Mgmt: Detect and identify thesubscribers who are affected by the emergency. Ingeneral, it will use the list of cells but otheravailable mechanisms can be used to obtain themost current user’s positions. This module willwork with the SMS-C system as notificationchannel.

Notification Mgr: Launch the emergencymessage to the involved users. These tasks can beperformed using several channels and approaches.It will be discussed the SMS-C systems and the CellBroadcast system (CBS).

Admin Tools: Allowing the administration of main DBs and establish themost appropriate values for internal parameters.

The middleware will have a connection with different MNO’s systems andrepositories (O&M, Subscribers DB, Network Info DB, Terminal CapabilitiesDB, etc).

Notification MgrSMS-C CBS

Agency

MNO’s Emergency infrastructure – Emergency Mgr Module

Emergency API

Location Mgmt

Agency

GIS Mgr

Notification Mgr

EmergencyDB

Log/StatDB

Emergency Web Tool

The core module of the system acts as Front-End with theexternal Agencies or other Third parties systems.

The dialogue with these Agencies could be through a well-defined Web services or through an Emergency Web Toolthat can support specific features to manage the emergencyprocess (p.e. Establish the emergency area, show theemergency’s progress). This tool can be used also by theMNO’s team.

Provides a complete set of API services including not onlythe Emergency functions but also additional public servicessupported by other modules (GIS, Location and NotificationMgr).

Based on the requests received, the Emergency Mgrestablishes the adequate call flow within the other modules.

All the emergency information is saved in the Emergency DB(Starting parameters, List of cells, List of users and theirstatus, timestamps, etc). This information will be useful forstatistics purposes and it must be kept in long-term storagefor several years.

Agency interface

MNO’s Emergency infrastructure – Emergency API (I)

Set of Web services under XML proprietary structures.

This interface must include security mechanisms such as:

Authentication: Through unique ID orLogin/Password keys per Agency/MNO and perRequestor User.

Authorization: Several profiles for each requestor(Read-Only, Write, Update).

Secure Communications: VPN connection, IPfiltering,…

Agency

Emergency Mgr Module

Exe

cCo

mm

and

Req

Exe

cCo

mm

and

AC

K

Exe

cCo

mm

and

AR

esp

Eme

rge

ncy

Re

po

rt

Syst

em

Stat

us

Co

nfi

gCo

mm

and

s

This module must check all the parameters for eachrequest, for instance:

Emergency Area: Any geometric figure but usuallyit’s specified as a polygon (GML format). This areamust not exceed over the country limits. Inaddition, the maximum number of vertices could bechecked.

Emergency Message Length: Maximum number ofcharacters depending on the notification channel.

Expiration time/Emergency Duration

The functional design and specifications of these Web services should be analyzed by all the entities involved (Government, Agencies and Mobile Operators) to meet present and future needs on the basis of existing systems and its capacity of additional developments.

MNO’s Emergency infrastructure – Emergency API (II)

We can classified the Web services in 4 main blocks:

Execution Commands: Initiated by the Agencies.Usually needs more than 1 minute of processing so theMNO’s system will respond with an ACK and then willpush the full answer towards the Agency’s URL.

Reporting commands: Once the emergency isstarted, the MNO’s system will inform periodically(predefined schedule) to the Agency about theprogress of each process. The Agency can also ask forthis information at any moment (Query command).

Status commands: The MNO’s system will informperiodically (predefined schedule) about the status ofthe system including availability (1:N sites), DB’sstatus, network status, etc.

Configuration commands: It can contain list ofWhite/Black lists of MSISDNs, Agency data (i.e. Accesskeys, list of users), reporting times, etc.

Agency

Emergency Mgr Module

Under the Execution block it’s definedfunctions forCreate, Update, Start, Stop, Resume andCancel the emergency.

Based on these set of API services, theMNO’s system will change its internalstatus, for instance: Idle, Initiated, InProgress, Stopped, Cancelled, Finished.This internal status will be communicatedto the Agency through the StatusCommands.

Exe

cCo

mm

and

Req

Exe

cCo

mm

and

AC

K

Exe

cCo

mm

and

AR

esp

Eme

rge

ncy

Re

po

rt

Syst

em

Stat

us

Co

nfi

gCo

mm

and

s

MNO’s Emergency infrastructure – Emergency API (III)

Message From/To Content Description

CreateEmergencyReq Agency → Operator ID_Emergency, ID_Agency, Emergency_Area, Expiration/Duration, Message

Create a new emergency in theMNO’s system.

CreateEmergencyResp Agency ← Operator ID_Emergency, Real_Emergency_Area EstimatedUsers, EstimatedTime

The Real/Effective area will becalculated based on the coveragearea of all the involved cells.

UpdateEmergencyReq Agency → Operator ID_Emergency, Updated_Emergency_Area, [Updated_Expiration_time]

Recalculate the real area andaffected users

StartEmergency Agency → Operator ID_Emergency Start the emergency processbased on the existingpreprocessed data

StatusEmergency Agency ← Operator ID_Emergency, TotalCells, TotalUsers/Status,TimeElapsed,…

Periodic report to inform aboutemergency progress

Stop/Resume/Cancel Emergency

Agency → Operator ID_Emergency Stop, re-start or abort theemergency. Change internal state.

StatusSystem Agency ← Operator Id_MNO, Status_System Periodic report to inform about the status of the emergency system (comms, DB, network status, …)

MNO’s Emergency infrastructure – General Call flow (I)

Emergency Mgr Location MgmtGIS Mgr

Internal checksSet Status

Buffered Area (opt)Matching Process

Set Cell priority (opt)

Update Spatial DB

Save/Update Cell data

Get users located in areaFilters: M2M Devices / Black lists

Save/Update Users data

MNO’s network changes

Agency

Start Emergency

ACK (Status)

Get Cells in Area (Emergency Area)

List of cells (CGI_Id, [priority])

Get Users in Area (List of Cells, [priority])

List of Users (List of MSISDN per CGI Id)

Every change in the MNO’s Network Info DB (i.e. new cells, drops) will launch the

Update process reflecting these changes in the internal Spatial DB

Reporting (Status, Progress Data)

Reporting (Status, Progress Data)

Reporting (Status, Progress Data)List of Users (List of MSISDN per CGI Id)

Reporting (Status, Progress Data)

This set of processes will be repeated when there is any change on the

Emergency Area and when occurs any changes in the MNO’s network

This set of processes will be repeated when there is any change in the list of cells and

periodically to detect new users that enter the area and/or users who leave the zone

MNO’s Emergency infrastructure – General Call flow (II)

Emergency Mgr Notification MgrSMS-C CBS

Agency

Save/Update Users data

Send SMS (List of Users, message, [Priority])

Reporting (Nº of users per status)

Save/Update Users data

Save/Update Cells data

Send SMS (List of Cells, message, [Priority])

Broadcast message to all users within the list of cells

Reporting (End status)

Reporting (Status, Progress Data)

Reporting (Status, Progress Data)Reporting ()

Reporting (Finished, Resume Data)

Reporting (Finished, Resume Data)

Reporting (Status, Progress Data)

The notification process can be started in parallel from the users

obtained in each cell

Under the CBS approach is not needed to obtain the position of the users involved in every cell

•Reset new users ( Status=Pending)•Launch msgs to the SMS-C systems (load balance, geo-distribution, round robin, …)•Change user’s status (notifications from SMS-C system)• Retries policies•Reorder internal queues

MNO’s Emergency infrastructure – GIS Mgr Module (I)

Spatial API

SpatialDB

The GIS Mgr module must be integrated with the MNONetwork Info DB (BTS DB) where the current deploymentof cell data (macro, micro, femtos,...) is reflected for eachnetwork topology (2G, 3G, LTE).

Each record cell must have of a unique ID (CGI_Id), the sitecoordinates and the associated coverage area. The formatand content of these data is usually proprietary and it maydepend on the radio planning tools used.

This dynamic information should be transferred andsynchronized through periodic or on-demand Updateprocess so all changes that the MNO’s team make must betransferred to the internal Spatial DB of this module.This DB will be optimized giving a high performance for therequired emergency process.

This module also provides a set of API spatial services(GetCGIData, ShowCGICoverage, …). The most importantfunction is the intelligent selection of the cells that arefound within the emergency area (Matching Process).

Emergency Mgr

MNO Network Info

DB

Matching Process

Emergency_Area Cell_list

O&M NetworkteamNetwork

PlanningChanges

Update Process

During an emergency it will be very important to consider new Temporary cells as well the

network drops (cell falls) so the GIS process should be repeated several times in order to get

these changes in real time.

MNO’s Emergency infrastructure – GIS Mgr Module (II)

Matching Process: Intelligent overlap processbetween Emergency Area and Cells coverage area.

As it’s shown in the schema, this process could takeinto account several parameters to decide whethera cell should be considered or not:

Maximum distance between Cell site and theemergency area (closest intersection point).

Percentage of overlap areaPercentage of Non-overlap area

Based on these parameters, the matching process could be totally adapted and configured based onthe specific characteristics of the MNO’s network (Cell density and distribution, Coverage areas, etc).

In addition, it could be possible to assign an initial priority for each cell based on the result of theoverlap process taking this value into account in the subsequent emergency processes (i.e. get theusers attached in each cell based on this priority and/or establish the order of message notification).

Other approach is to increase the original emergency area from the Agency applying a buffered area (multiplier value). This new emergency area would be processed by the GIS Mgr module

MNO’s Emergency infrastructure – GIS Mgr Module (III)

As it’s shown in the above figure, based on the result of the Matching process, the effective emergencyarea will be the result of the union of all the coverage areas of every cell that have been considered bythe process.

It is important to note that, in the context of an emergency, it is preferable to operate by excess but morecells will involve to more potential users increasing the time during the notification process trying to reachto all the affected population. The hole system must maintain the adequate balance betweenperformance and processing time so the adaptation of the cell selection process is extremely important.

MNO’s Emergency infrastructure – Location Mgmt (I)

Location API Cache/Positions

DB

This module must obtain the identity (i.e.MSISDN) ofevery user that is located in the emergency area.For this purpose, it could be connected with differentlocation systems under one or more technologies (CGI,E-CGI, GPS/A-GPS, etc). These MNO’s systems could be:

Location Systems: Obtain the current user’s position inreal time under Control or User Plane architecturesoperating in Active mode per each request.

Presence Servers: Usually needs the subscription ofthe target users (reporting their CGI/LAC changes) or theregistration of any geographical area &Cell (reporting theusers that entry/leave in/from this area). Based on therequired subscription we could consider these systems ina Pseudo-Active mode

Data Collector Systems: Get the position of the usersbased on asynchronous events that occur in the network(Pseudo Real time) so they are classified as Passivesystems. These systems don’t need pre-subscription andthey are capable to get the last known position of everycustomer of the MNO.

Emergency Mgr

List of Users in Area Cell_list

Location Servers

Multi Location Plug-ins

PresenceServers

Data CollectorSystems

SS7 Events

IP Probes

MNO Network

LocationProcedures

CDRAnalysis

MNO’s Emergency infrastructure – Location Mgmt (II)

In general, for the emergency purposes, the Passive systems willbe used reaching all potential users and without affecting theperformance of the operator's network.

To collect the information, these Passive Systems are based onseveral mechanisms like:

Network events from MSC/VLR(attach/detach, calls/messages, etc)

IP or SS7 probesCDR Analysis: Each event is periodically transferred from

the network (p.e. MSC) to the Billing/Intermediation MNO’ssystems. Each billable event contains the timestamp and theassociated CellID.

Location Mgmt Module

Historic/logDB

Synch. API

Passive Data Collector System (PDCS)

Asynch. Push SQL

The interface with these Passive Data Collector Systems (PDCS) could be:

1. Request/Response (Synch.): The PDCS provides an API service allowing to receive the list of cells(1:N cells per request) and answer with the list of users that have been detected in each one of them.The Location module will have into account the overhead and load of the PDCS.

2. Asynchronous Push: The PDCS notifies all detected changes (MSISDN+Cell_Id values) to the LocationModule. This information is saved in its Cache DB performing locally the search process.

3. SQL statement: The Location module accesses directly to the PDCS DB extracting the desiredinformation for each Cell Id.

Under PDCS, the user’s position will not be obtained in real time (delay between 15 min and 2 hours).

MNO’s Emergency infrastructure – Location Mgmt (III)

Cache/PositionsDB

List of Users (MSISDNs)in Area

Request (1:N Cells)

SS7 Events

IP Probes

LocationProcedures

CDRAnalysis

Historic/logDB

Synch. API

Passive Data Collector System (PDCS)

Asynch. Push SQL

Cell_list

Resp (List UsersPer Cell Id)

Notify msg (MSISDN,Cell Id, Event)

MSISDNInitial_CGIIdInitial-TimestampUpdated_CGIIdUpdated –TimeStampStatus

Select (MSISDN, Timestamp, Event) from Historic_DBWhere Cell_ID in (list of cells) ORDER BY Timestamp

EventCollector

Location Mgmt module

Synch. Plug-in Asynch. Plug-in SQL Plug-in

Cache Mgr

MNO’s Emergency infrastructure – Notification Mgr (I)

Messaging API

EmergencyDB

The objective of this module is to notify the emergencymessage to all involved users in the shortest time.

In general, the messaging system will be the SMS-C orSMPP-GW system. The Operator can provide one ormore of these systems based on geographical areasdistribution or by load balance distribution.

Mechanisms of notification will be required from theSMS-C systems to this module determining the statusof each message(Pending, Sent, Accepted, Delivered, Rejected, Expired,Deleted, etc).

The module will have internal queues where to storethe data associated with each user including itsstate, nº of retries and associated timestamps.

The Notification Mgr shall take into account theoverhead of each SMS-C system connected so it mustdistribute properly the messages to avoid saturation ofthe network that will increase with the emergencysituation.

Other channels like email, TV or radio can be used.

Emergency Mgr

List of Users in Area +Emergency message Status_results

SMS-C

Media GWs Plug-ins

E-Mail

IVR

Internal Queues

SMS-C

Start/Stop/Resume/Cancel

Req/Resp

This module must provide an API interface to start, stop or resume the notification process.

Notification Mgr

MNO’s Emergency infrastructure – Notification Mgr (II)

CBS

Most often used for marketing campaigns, another alternativefor mass notification of messages is called CBS (Cell BroadcastSystem).

It allows messages to be communicated to multiple mobileclients that are located in a certain target area of the MNO’snetwork.

The CBS provides unique features for the treatment ofemergencies (greater efficiency, geo-scalable, geo-specific).However, the lack of delivered confirmations in the processand the need to properly configuration of the mobileterminals (opening CBCH channels) have prevented itsinstallation for these purposes. Other possible misconceptionscould be the support for all types of networks(CDMA, UMTS, LTE, WiMax,…), handset battery drain or costsfor service activation.

There are many companies & organisms who prefer the CBScompared to the usual SMS-C systems so they are promotingan international regulation for the adoption of this technologyin the management of massive emergencies to thepopulation.

Emergency Mgr

Cell List +Emergency_message

Start/Stop/Resume/Cancel

Commands

MSC BSC/RNC

The use of a CBS would require obtaining the cells involved in the emergency area (GIS

Mgr process) without requiring the process of identification of the involved users

(Location Mgmt process).

MNO’s Emergency infrastructure – Notification Mgr (III)

Characteristic SMS-C System Cell Broadcast System

Messages sent Point to point Point to area

User identity Yes. MSISDN is required Not required

Location Based No. The msg is received independent of user’s location Yes.

Bidirectional Direct. Users receive and answer to the sender Not directly. Only if the msg includes phone numbers or URLs.

Dedicated Channels No. It uses signaling radio channels Yes. Different channels with Multilanguage support

Foreign Users Depend on their home network (msg outing) Msgs are delivered to all users in a given cell

Message Size 140-160 characters. Maximum 5 msgs concatenated 93 characters. Maximum of 15 concatenated pages

Display Message Controlled by the user Msgs can be automatic pushed to the screen or launch a beep (Subscribed handsets)

Handset Compatibility Full compatibility With most handsets but it requires manual configuration (different between handsets)

Retries The SMS-C can be configured for retrying Yes. Broadcast msgs can be repeated

Reach 100% users Yes. All handsets support SMS messages No. High penetration

Timing Limited by network capacity. Possible congestions Not limited but delays occur in areas with poor coverage

Delivered confirmation Yes No. It’s not possible individual confirmation

MNO’s Emergency infrastructure – Reporting

As it has been described in the Call flow slides, it is extremelyimportant that the MNO’s system periodically notifies the Agencyabout the status and progress of the emergency processes.

The Agency can ask the status of the emergency at any momentthrough a Query request (Web Service). The Web Tool can alsodisplays graphically the advance of each internal process.

These reporting messages will be established at certain points inthe workflow (breakpoints) such as:

Start of cell selection processEnd of cell selection process and total number of cellsStart of Users selection processPeriodic reports with the total amount of users involvedEnd of Users selection process and total number of usersStart of Notification processPeriodic reports with figures such as:

o Nº of Pending messages – Not sent to the SMS-Csystemo Nº of messages sent but not confirmedoNº of delivered messagesoNº of messages in other status(Rejected, Expired, Error, …)

Emergency Mgr

GIS Mgr Process

Agency

Reporting msg

Location Mgr ProcessReporting msg

Notification Mgr Process

Reporting msg

Query Status req

Reporting msg

The Emergency Mgr must take into account the predefined duration of the emergency

(Expiration time value) so these reporting messages will include the estimated time to

complete each individual process.

MNO’s Emergency infrastructure – Administration

Admin Tools

UsersDB

AgenciesDB

Special Devices

DB

SystemDB

This module provides the management of several master DBthat affect the internal operation of the system:

1. Users DB: Maintain the profile of all users (Agency andMNO users) who can access the system through Webtools and/or Web Services. It contains unique accesskeys, contact data and privilege level. In addition, theseusers can be grouped.

2. Agencies DB: Each Agency must be reflected withattributes such as:o Agency Id – Login/password access keyso Contact datao List of allowed IP addresso Notify URLs

4. System DB: Management of external connections with MNO’s systems (i.e. LocationSources, Media Gateways):o Connection data: URL, host, porto Access keyso Maximum allowed throughput

And the value of internal parameters such as:oReporting: Predefined breakpoints and periodic time for automatic reporting msgsoBuffered area: Multiplier factor over the original emergency areaoMaximum processing time per internal process

3. Special Devices DB: Identity of M2Mdevices and MSISDN Black list. Thesedevices should not notified byemergency purposes.

National Infrastructure – Emergency Middleware

Objective: Intermediation between Agencies (national, regional) and all the mobile operators in thecountry. Other Third party entities could be integrated.

Each agency may be assigned to different geographical areas.Adapt the protocols and interfaces between these entities (std or proprietary) under a single common

platform independently of the internal solution that every Operator has chosen.Provide global and general functions such as:

• Statistical management• Reporting – Historical DB (long term storage)• Web tools: Emergency mgmt, control and visualization with specific spatial layers (estimation ofearthquakes, pollution levels, levels of pollen, risk of fire, etc)

Agency A Agency B Agency C

Operator X

Public WarningEmergency System

Operator Y

Public WarningEmergency System

Operator Z

Public WarningEmergency System

Standard Agency Interface Proprietary Agency Interface

Standard MNO Interface Proprietary MNO Interface

Statistics

Historical Reports

Web Tools

Comments & Conclusions (I) – Critical Points

Architecture:High availability usually with geographic redundancy (both for processes and DBs).No single point of failure. Functional and Stress tests are critical.Heartbeat mechanisms for verifying availability by detecting failures in any

component and in the communications between Agencies and MNOs.Time synchronization.

GIS Manager module:The format and content of the MNO’s Network Information DB is proprietary and

usually it doesn’t have a well defined coverage area for each cell. Additionalprocesses are required to import and process these data for emergency purposesestablishing a theoretical cell’s coverage based on radio electric parameters, BTSdensity and other approaches.

In general, it should be necessary to improve the precision and exactitude of everyindividual cell’s coverage area (without interferences).

Also it would be very useful the integration with MNO network systems thatautomatically detect falls and failures at cell/BTS level communicating in real timethese events to the Emergency system.

Femto cells should be considered (Indoor environment) with a different Cell_Idvalue per register.

Comments & Conclusions (II) – Critical Points

GIS Manager module:Disaster Prevention: Having previously calculated the associated cells lists in

geographical areas where disasters occur at certain times of the year could improvethe initial stage in the notification process.

Include fixed telephone lines -> Matching process between emergency area andyellow pages information (addresses).

The spatial matching process should be different depending on the notificationchannel used (SMS-C or CBS) or even different depending on the type of network(2G, 3G, 4G) where there will be coverage overlapping between cells of differentnetworks.

Location Management:The common Passive systems get sometimes the user's position with a significant

delay that can affect the quality and effectiveness of the emergency system. Thesesystems should optimize this point to ensure real time and full coverage of thepopulation.

Include transparently the foreign customers attached to the Visited network.

Comments & Conclusions (III) – Critical Points

Notification Manager module:Critical process that must be done in the shortest possible time being dependent

on the network congestion during the emergency period.Main discussion about CBS system pros&cons: Support for all type of networks (2G, 3G, 4G) Homogeneity to set up and activate CBS feature in mobile terminals or factorypreset. New smart phones with CBS function built-in. Full support for Android and IOS devices Support native Cell broadcast features and characteristics Support delivered confirmation (Gov’s requirement):

Adding URL in the CB message Through U-SIM app Through handset programming that sends an ACK or a predefinedconfirmation message

Include fixed telephone lines: Interface with IVR systems.Include foreign usersInclude other alert mechanisms for blind people (speech app, audible alarms) and

hearing disease (vibration or flash-light alarms)

Comments & Conclusions (IV)

The Public Warning Emergency System is highly demanded by many administrations.

It requires a complicated process that must establish common regulatory rules andpolicies between governmental entities and Mobile operators (Country level) as well mustinvolve other international organisms.

From the Mobile Operator point of view, the final Emergency system - or the individualcomponents needed - will not only serve for the treatment of emergencies but it will beused for other purposes such as:

LBS infrastructureMassive marketing campaignsAdvertisement (LBA)

From the described processes, some of the components and necessary systems can bealready available in many operators (Geo-fencing features) so, basically, it will be requiredthe Emergency Mgr module for controlling the workflow between the existingcomponents and supports the Agency interface.

Comments & Conclusions (V)

The Agency interface – Web services and I/O parameters - should be standardized andspecified as a global reference for any Public Emergency System (from existing CAP interface).

The objective is to save human lives being preferable to operate by excess but reaching acompromise between performance, quality and efficiency in all the processes involved:

Generalization of theoretical coverage areas of each cellDetermine multiple sub-emergency areas with different priorities based on the type

of disaster.Intelligent cell selection process based on the emergency area (both for SMS-C and

CBS channels)User’s location from multiple available sources /systems (only for SMS-C channel)Notification process with the most adequate distribution mechanisms and taking into

account cell’s priority

Response times may be estimated depending on the type of disaster, size of theemergency area, total number of cells affected and total number of users involved.

Comments & Conclusions (VI)

Entities

&

Requirements

&

Needs

Governments

Mobile Operators

Standardization

Organisms

ETSI, 3GPP, GSMA, EMTEL, CMAS, …

TechnologyProviders

Agencies

Core Network Suppliers

HandsetManufacturers

Local/National Forces

• Common Guidelines and procedures• Individual & General negotiations• Compensations • Civil & Corporate & Social Responsibilities•Geographical limits per jurisdiction

• Privacy issues• Risks analysis• Costs (infrastructure, implementation,

installation and maintenance)• Education of the population

• Full penetration

• User manual configuration• Battery Usage• Types of alerts (text, voice, sound, vibration)• Foreign Visitors & Multilingual support • Blind & Hearing disabled people• Alert to fixed phones• Verified confirmation of each message

• CAP (Common Alerting Protocol)

• Cell broadcast & SMS-C approaches• Location solutions: Passive & Active• Support all 2G/3G/4G phones

• Supported band of frequencies• Support core network evolution• Handset updates required• Network capacity• No single point of failure

Any questions?

I’m happy to help you!