In this document it's described the main entities involved and its respective roles in this type of systems, main requirements and topics. It's included the Emergency system from the point of view of the Mobile Operators, the description of each module, its characteristics and processes (GIS, Location and Notification modules). Also, the document describes the interface with the external Agencies, web services and call flows. It's also discussed the SMS-C and CBS (Cell broadcast) mechanisms, administration tools and reporting mgmt.

2. Contents
Main entities and roles
MNO’s Emergency Infrastructure:
General Schema
Emergency Manager module
Emergency API - Agency Interface
General Call flow
GIS Manager module
Location Mgmt module
Notification Mgr module
Reporting
Administration
National infrastructure
Comments & Conclusions

3. Main Entities and Roles
National Government:
• Being a solution for the country population, the Emergency
Detection
Government must impose general rules and policies Systems
to other regional/local authorities, Agencies and
Automatic/ Manual systems capable of
Mobile Operators acting as coordinators in the generating alerts in special situations
(bushfires, earthquakes, tsunamis, hurri
Emergency project. canes, volcanic
• Establish the Emergency & Alert Detection eruptions, terrorism, etc)
Systems
Agencies
Agencies:
• There are organisms like 112 or 911. Receive the alerts and establish the
emergency situation within other
• Adopt Government’s guidelines organisms such as Police, Fire
Brigade, Health Care organizations, …)
• Receive events and info from Detection Systems
• Determine emergency situations initiating the Mobile
Operators
process with the Mobile Operator’s systems.
Mobile Operators (MNOs): Receive the emergency area from
the Agencies and proceed to
• Adopt Government’s guideline identify the affected population
• Establish the adequate dialog with the Agencies notifying them with the adequate
message
• Execute the emergency process for detecting their
subscribers that are involved in the alert and notify
them through available channels .

4. MNO’s Emergency infrastructure – General Schema
The proposed emergency middleware is composed by 5 main modules:
Emergency Mgr: Front-end with the Agencies and coordinator of the
Agency emergency processes.
Agency 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 the
subscribers who are affected by the emergency. In
Emergency Mgr general, it will use the list of cells but other
systems/capacities
available mechanisms can be used to obtain the
Other MNO’s
GIS Mgr most current user’s positions. This module will
Admin Tools
work with the SMS-C system as notification
channel.
Location Mgmt Notification Mgr: Launch the emergency
message to the involved users. These tasks can be
Notification Mgr performed using several channels and approaches.
SMS-C CBS
It will be discussed the SMS-C systems and the Cell
Broadcast system (CBS).
Admin Tools: Allowing the administration of main DBs and establish the
most appropriate values for internal parameters.
Network The middleware will have a connection with different MNO’s systems and
repositories (O&M, Subscribers DB, Network Info DB, Terminal Capabilities
DB, etc).

5. MNO’s Emergency infrastructure – Emergency Mgr Module
The core module of the system acts as Front-End with the
external Agencies or other Third parties systems.
Agency
Emergency
Agency Web Tool The dialogue with these Agencies could be through a well-
defined Web services or through an Emergency Web Tool
Agency interface that can support specific features to manage the emergency
process (p.e. Establish the emergency area, show the
emergency’s progress). This tool can be used also by the
Emergency API
MNO’s team.
Emergency Log/Stat Provides a complete set of API services including not only
DB DB the Emergency functions but also additional public services
supported by other modules (GIS, Location and Notification
Mgr).
GIS Mgr Location Mgmt Based on the requests received, the Emergency Mgr
establishes the adequate call flow within the other modules.
Notification Mgr
All the emergency information is saved in the Emergency DB
(Starting parameters, List of cells, List of users and their
status, timestamps, etc). This information will be useful for
statistics purposes and it must be kept in long-term storage
for several years.

6. MNO’s Emergency infrastructure – Emergency API (I)
Set of Web services under XML proprietary structures. Agency
ExecCommandAResp
ExecCommandACK
ExecCommandReq
ConfigCommands
EmergencyReport
This interface must include security mechanisms such as:
SystemStatus
Authentication: Through unique ID or
Login/Password keys per Agency/MNO and per
Requestor User.
Authorization: Several profiles for each requestor
(Read-Only, Write, Update).
Secure Communications: VPN connection, IP Emergency Mgr Module
filtering,…
This module must check all the parameters for each
request, for instance: The functional design and specifications of
these Web services should be analyzed by all
Emergency Area: Any geometric figure but usually the entities involved (Government, Agencies
it’s specified as a polygon (GML format). This area and Mobile Operators) to meet present and
must not exceed over the country limits. In future needs on the basis of existing systems
addition, the maximum number of vertices could be and its capacity of additional developments.
checked.
Emergency Message Length: Maximum number of
characters depending on the notification channel.
Expiration time/Emergency Duration

7. MNO’s Emergency infrastructure – Emergency API (II)
We can classified the Web services in 4 main blocks: Agency
ExecCommandAResp
ExecCommandACK
ExecCommandReq
Execution Commands: Initiated by the Agencies.
ConfigCommands
EmergencyReport
SystemStatus
Usually needs more than 1 minute of processing so the
MNO’s system will respond with an ACK and then will
push the full answer towards the Agency’s URL.
Reporting commands: Once the emergency is
started, the MNO’s system will inform periodically
(predefined schedule) to the Agency about the Emergency Mgr Module
progress of each process. The Agency can also ask for
this information at any moment (Query command).
Under the Execution block it’s defined
Status commands: The MNO’s system will inform functions for
periodically (predefined schedule) about the status of Create, Update, Start, Stop, Resume and
the system including availability (1:N sites), DB’s Cancel the emergency.
status, network status, etc.
Based on these set of API services, the
Configuration commands: It can contain list of MNO’s system will change its internal
White/Black lists of MSISDNs, Agency data (i.e. Access status, for instance: Idle, Initiated, In
keys, list of users), reporting times, etc. Progress, Stopped, Cancelled, Finished.
This internal status will be communicated
to the Agency through the Status
Commands.

8. MNO’s Emergency infrastructure – Emergency API (III)
Message From/To Content Description
CreateEmergencyReq Agency → Operator ID_Emergency, ID_Agency, Create a new emergency in the
Emergency_Area, MNO’s system.
Expiration/Duration, Message
CreateEmergencyResp Agency ← Operator ID_Emergency, The Real/Effective area will be
Real_Emergency_Area calculated based on the coverage
EstimatedUsers, EstimatedTime area of all the involved cells.
UpdateEmergencyReq Agency → Operator ID_Emergency, Recalculate the real area and
Updated_Emergency_Area, affected users
[Updated_Expiration_time]
StartEmergency Agency → Operator ID_Emergency Start the emergency process
based on the existing
preprocessed data
StatusEmergency Agency ← Operator ID_Emergency, TotalCells, Periodic report to inform about
TotalUsers/Status,TimeElapsed,… emergency progress
Stop/Resume/Cancel Agency → Operator ID_Emergency Stop, re-start or abort the
Emergency emergency. 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, …)

9. MNO’s Emergency infrastructure – General Call flow (I)
Agency Emergency Mgr GIS Mgr Location Mgmt
Start Emergency MNO’s network
changes
ACK (Status) Internal checks Every change in the MNO’s
Set Status Update Spatial DB Network Info DB (i.e. new
cells, drops) will launch the
Get Cells in Area (Emergency Area) Update process reflecting these
changes in the internal Spatial DB
Reporting (Status, Progress Data)
Buffered Area (opt)
Matching Process
Set Cell priority (opt)
This set of processes will be repeated
when there is any change on the
List of cells (CGI_Id, [priority]) Emergency Area and when occurs any
changes in the MNO’s network
Save/Update Cell data
Reporting (Status, Progress Data)
Get Users in Area (List of Cells, [priority])
Reporting (Status, Progress Data) Get users located in area
List of Users (List of MSISDN per CGI Id)
Filters: M2M Devices / Black lists
List of Users (List of MSISDN per CGI Id)
Save/Update Users data
Reporting (Status, Progress Data)
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

10. MNO’s Emergency infrastructure – General Call flow (II)
Agency Emergency Mgr Notification Mgr
SMS-C CBS
Save/Update Users data
The notification process can be
Send SMS (List of Users, message, [Priority]) started in parallel from the users
obtained in each cell
Reporting (Status, Progress Data)
•Reset new users ( Status=Pending)
•Launch msgs to the SMS-C systems (load
balance, geo-distribution, round robin, …)
Reporting ()
•Change user’s status (notifications from SMS-C
Reporting (Status, Progress Data)
system)
• Retries policies
•Reorder internal queues
Reporting (Nº of users per status)
Save/Update Users data
Reporting (Finished, Resume Data)
Save/Update Cells data
Send SMS (List of Cells, message, [Priority])
Reporting (Status, Progress Data)
Broadcast message to all users
within the list of cells
Reporting (End status)
Reporting (Finished, Resume Data)
Under the CBS approach is not needed to obtain the position of the users involved in every cell

11. MNO’s Emergency infrastructure – GIS Mgr Module (I)
Emergency Mgr The GIS Mgr module must be integrated with the MNO
Network Info DB (BTS DB) where the current deployment
Emergency_Area Cell_list of cell data (macro, micro, femtos,...) is reflected for each
network topology (2G, 3G, LTE).
Spatial API Each record cell must have of a unique ID (CGI_Id), the site
coordinates and the associated coverage area. The format
and content of these data is usually proprietary and it may
Spatial Matching Process depend on the radio planning tools used.
DB
This dynamic information should be transferred and
Update Process synchronized through periodic or on-demand Update
process so all changes that the MNO’s team make must be
MNO transferred to the internal Spatial DB of this module.
Network Info O&M Network
DB Network team This DB will be optimized giving a high performance for the
Planning required emergency process.
Changes
This module also provides a set of API spatial services
(GetCGIData, ShowCGICoverage, …). The most important
During an emergency it will be very important to
function is the intelligent selection of the cells that are
consider new Temporary cells as well the
network drops (cell falls) so the GIS process found within the emergency area (Matching Process).
should be repeated several times in order to get
these changes in real time.

12. MNO’s Emergency infrastructure – GIS Mgr Module (II)
Matching Process: Intelligent overlap process
between Emergency Area and Cells coverage area.
As it’s shown in the schema, this process could take
into account several parameters to decide whether
a cell should be considered or not:
Maximum distance between Cell site and the
emergency area (closest intersection point).
Percentage of overlap area
Percentage of Non-overlap area
Based on these parameters, the matching process could be totally adapted and configured based on
the 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 the
overlap process taking this value into account in the subsequent emergency processes (i.e. get the
users 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

13. 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 emergency
area will be the result of the union of all the coverage areas of every cell that have been considered by
the process.
It is important to note that, in the context of an emergency, it is preferable to operate by excess but more
cells will involve to more potential users increasing the time during the notification process trying to reach
to all the affected population. The hole system must maintain the adequate balance between
performance and processing time so the adaptation of the cell selection process is extremely important.

14. MNO’s Emergency infrastructure – Location Mgmt (I)
Emergency Mgr This module must obtain the identity (i.e.MSISDN) of
every user that is located in the emergency area.
For this purpose, it could be connected with different
Cell_list List of Users in Area location systems under one or more technologies (CGI,E-
CGI, GPS/A-GPS, etc). These MNO’s systems could be:
Location API Cache/ Location Systems: Obtain the current user’s position in
Positions
DB real time under Control or User Plane architectures
Multi Location Plug-ins operating in Active mode per each request.
Presence Servers: Usually needs the subscription of
the target users (reporting their CGI/LAC changes) or the
Data registration of any geographical area &Cell (reporting the
Location Presence
Collector
Servers Servers users that entry/leave in/from this area). Based on the
Systems
required subscription we could consider these systems in
a Pseudo-Active mode
Location Data Collector Systems: Get the position of the users
Procedures CDR
MNO Analysis based on asynchronous events that occur in the network
(Pseudo Real time) so they are classified as Passive
Network
IP SS7
systems. These systems don’t need pre-subscription and
Probes Events they are capable to get the last known position of every
customer of the MNO.

15. MNO’s Emergency infrastructure – Location Mgmt (II)
In general, for the emergency purposes, the Passive systems will
be used reaching all potential users and without affecting the
Location Mgmt Module performance of the operator's network.
To collect the information, these Passive Systems are based on
several mechanisms like:
Synch. API Asynch. Push SQL Network events from MSC/VLR
(attach/detach, calls/messages, etc)
Historic/log
DB
IP or SS7 probes
CDR Analysis: Each event is periodically transferred from
Passive Data Collector System (PDCS) the network (p.e. MSC) to the Billing/Intermediation MNO’s
systems. Each billable event contains the timestamp and the
associated CellID.
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 Location
Module. 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 desired
information for each Cell Id.
Under PDCS, the user’s position will not be obtained in real time
(delay between 15 min and 2 hours).

16. MNO’s Emergency infrastructure – Location Mgmt (III)
Cell_list List of Users (MSISDNs)
in Area
Location Mgmt module MSISDN
Initial_CGIId
Cache/Positions Initial-Timestamp
Cache Mgr Updated_CGIId
DB Updated –TimeStamp
Status
Synch. Plug-in Asynch. Plug-in SQL Plug-in
Select (MSISDN, Timestamp, Event) from Historic_DB
Resp (List Users Notify msg (MSISDN,Cell Id, Event)
Request (1:N Cells) Where Cell_ID in (list of cells) ORDER BY Timestamp
Per Cell Id)
Synch. API Asynch. Push SQL
Event
Collector
Historic/log
DB
Passive Data Collector System (PDCS)
Location CDR
Procedures Analysis
IP SS7
Probes Events

17. MNO’s Emergency infrastructure – Notification Mgr (I)
The objective of this module is to notify the emergency
Emergency Mgr message to all involved users in the shortest time.
List of Users in Area + Start/Stop/
Emergency message Status_results Resume/Cancel In general, the messaging system will be the SMS-C or
Req/Resp
SMPP-GW system. The Operator can provide one or
more of these systems based on geographical areas
Messaging API distribution or by load balance distribution.
Emergency Internal
Mechanisms of notification will be required from the
DB Queues SMS-C systems to this module determining the status
of each message
(Pending, Sent, Accepted, Delivered, Rejected, Expired,
Media GWs Plug-ins Deleted, etc).
The module will have internal queues where to store
SMS-C IVR the data associated with each user including its
SMS-C E-Mail state, nº of retries and associated timestamps.
The Notification Mgr shall take into account the
This module must provide an API interface to overhead of each SMS-C system connected so it must
start, stop or resume the notification process.
distribute properly the messages to avoid saturation of
the network that will increase with the emergency
situation.
Other channels like email, TV or radio can be used.

18. MNO’s Emergency infrastructure – Notification Mgr (II)
Most often used for marketing campaigns, another alternative
Emergency Mgr for mass notification of messages is called CBS (Cell Broadcast
Cell List + Start/Stop/ System).
Emergency_message Resume/Cancel
Commands
It allows messages to be communicated to multiple mobile
Notification Mgr clients that are located in a certain target area of the MNO’s
network.
CBS The CBS provides unique features for the treatment of
emergencies (greater efficiency, geo-scalable, geo-specific).
However, the lack of delivered confirmations in the process
MSC BSC/RNC
and the need to properly configuration of the mobile
terminals (opening CBCH channels) have prevented its
installation for these purposes. Other possible misconceptions
could be the support for all types of networks
(CDMA, UMTS, LTE, WiMax,…), handset battery drain or costs
for service activation.
The use of a CBS would require obtaining the
cells involved in the emergency area (GIS There are many companies & organisms who prefer the CBS
Mgr process) without requiring the process compared to the usual SMS-C systems so they are promoting
of identification of the involved users an international regulation for the adoption of this technology
(Location Mgmt process). in the management of massive emergencies to the
population.

19. 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

20. MNO’s Emergency infrastructure – Reporting
As it has been described in the Call flow slides, it is extremely
Agency Emergency Mgr important that the MNO’s system periodically notifies the Agency
about the status and progress of the emergency processes.
Reporting msg
GIS Mgr Process
The Agency can ask the status of the emergency at any moment
through a Query request (Web Service). The Web Tool can also
Reporting msg displays graphically the advance of each internal process.
Location Mgr Process
Reporting msg
These reporting messages will be established at certain points in
Notification Mgr
Process the workflow (breakpoints) such as:
Start of cell selection process
Query Status req End of cell selection process and total number of cells
Reporting msg Start of Users selection process
Periodic reports with the total amount of users involved
End of Users selection process and total number of users
Start of Notification process
Periodic reports with figures such as:
The Emergency Mgr must take into account the o Nº of Pending messages – Not sent to the SMS-C
predefined duration of the emergency
(Expiration time value) so these reporting
system
messages will include the estimated time to o Nº of messages sent but not confirmed
complete each individual process. oNº of delivered messages
oNº of messages in other status
(Rejected, Expired, Error, …)

21. MNO’s Emergency infrastructure – Administration
This module provides the management of several master DB
Admin Tools that affect the internal operation of the system:
1. Users DB: Maintain the profile of all users (Agency and
MNO users) who can access the system through Web
Special tools and/or Web Services. It contains unique access
Users Agencies System
DB DB
Devices
DB
keys, contact data and privilege level. In addition, these
DB users can be grouped.
2. Agencies DB: Each Agency must be reflected with
attributes such as:
3. Special Devices DB: Identity of M2M o Agency Id – Login/password access keys
devices and MSISDN Black list. These o Contact data
devices should not notified by o List of allowed IP address
emergency purposes. o Notify URLs
4. System DB: Management of external connections with MNO’s systems (i.e. Location
Sources, Media Gateways):
o Connection data: URL, host, port
o Access keys
o Maximum allowed throughput
And the value of internal parameters such as:
oReporting: Predefined breakpoints and periodic time for automatic reporting msgs
oBuffered area: Multiplier factor over the original emergency area
oMaximum processing time per internal process

22. National Infrastructure – Emergency Middleware
Agency A Agency B Agency C
Standard Agency Interface Proprietary Agency Interface Statistics
Historical Reports
Standard MNO Interface Proprietary MNO Interface
Web Tools
Operator X Operator Y Operator Z
Public Warning Public Warning Public Warning
Emergency System Emergency System Emergency System
Objective: Intermediation between Agencies (national, regional) and all the mobile operators in the
country. 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 of
earthquakes, pollution levels, levels of pollen, risk of fire, etc)

23. 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. Additional
processes are required to import and process these data for emergency purposes
establishing a theoretical cell’s coverage based on radio electric parameters, BTS
density and other approaches.
In general, it should be necessary to improve the precision and exactitude of every
individual cell’s coverage area (without interferences).
Also it would be very useful the integration with MNO network systems that
automatically detect falls and failures at cell/BTS level communicating in real time
these events to the Emergency system.
Femto cells should be considered (Indoor environment) with a different Cell_Id
value per register.

24. 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 improve
the initial stage in the notification process.
Include fixed telephone lines -> Matching process between emergency area and
yellow pages information (addresses).
The spatial matching process should be different depending on the notification
channel 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 different
networks.
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. These
systems should optimize this point to ensure real time and full coverage of the
population.
Include transparently the foreign customers attached to the Visited network.

25. 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 factory
preset.
 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 predefined
confirmation message
Include fixed telephone lines: Interface with IVR systems.
Include foreign users
Include other alert mechanisms for blind people (speech app, audible alarms) and
hearing disease (vibration or flash-light alarms)

26. 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 and
policies between governmental entities and Mobile operators (Country level) as well must
involve other international organisms.
From the Mobile Operator point of view, the final Emergency system - or the individual
components needed - will not only serve for the treatment of emergencies but it will be
used for other purposes such as:
LBS infrastructure
Massive marketing campaigns
Advertisement (LBA)
From the described processes, some of the components and necessary systems can be
already available in many operators (Geo-fencing features) so, basically, it will be required
the Emergency Mgr module for controlling the workflow between the existing
components and supports the Agency interface.

27. Comments & Conclusions (V)
The Agency interface – Web services and I/O parameters - should be standardized and
specified 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 a
compromise between performance, quality and efficiency in all the processes involved:
Generalization of theoretical coverage areas of each cell
Determine 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 the
emergency area, total number of cells affected and total number of users involved.

28. Comments & Conclusions (VI)
• Full penetration Governments • Common Guidelines and procedures
• User manual configuration • Individual & General negotiations
Agencies Local/National • Compensations
• Battery Usage
• Types of alerts (text, voice, sound, Forces • Civil & Corporate & Social
vibration) Responsibilities
• Foreign Visitors & Multilingual support •Geographical limits per jurisdiction
• Blind & Hearing disabled people • Privacy issues
• Alert to fixed phones • Risks analysis
• Verified confirmation of each message • Costs (infrastructure, implementation,
installation and maintenance)
Entities • Education of the population
&
Requirements
Technology & Handset
Providers Manufacturers
Needs
Standardization Mobile
Organisms Operators
ETSI, 3GPP, GSMA, Core Network
EMTEL, CMAS, … Suppliers
• 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

29. Any questions?
I’m happy to help you!