Upload
jose-maria-carazo-cepedano
View
5.179
Download
4
Embed Size (px)
DESCRIPTION
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.
Citation preview
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
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!