1. email: luca.ronga@cnit.it
Satellite Assisted Delivery of Alerts: A Standardization Activity within ETSI
M. Berioli*, T. De Cola*, L. S. Ronga**, S. Jayousi**, J. Rammer,° L. Franck°°
*DLR - Institute of Communications and Navigation German Aerospace Centre (Germany)
**CNIT- National Inter-University Consortium for Telecommunications (Italy)
° Dr. Rammer RM e.U. (Austria)
°° Télécom Bretagne, Microwave Department (France)
7 th Advanced Satellite Multimedia Systems Conference, Livorno - Italy, September 8-9, 2014

2. Outline
Rationale
Current Alerting Technologies and Enabling SatCom/SatNav systems
MAMES Context and Encapsulation Protocol Design
Standardisation activity in ETSI and SatAlert Experiment
Conclusions

3. Rationale In case of natural or manmade disasters:
Prevention, support and relief are key elements of emergency management operations.
Reliable and timely distribution/delivery of alert messages is the main requirement for current and future alerting networks.
Heterogeneous alerting procedures and practices partially relying on outdated technologies.
Increasing availability of new information channels.
Current status
Timely and reliably distribution of alert messages.
Integration of different systems (multi-country/emergency situations).
Efficient transport of different alert messages formats (including narrowband channels).
Technical Challenges
ETSI Specialist Task Force 473 (SES/SatEC) Standardization Activity
MAMES - Multiple Alert Message Encapsulation over Satellite
Definition of a multiple alert message encapsulation protocol for transporting alert messages over satellite links, aiming at a fast distribution of alert to the population.
Main objective

4. Current Alerting Technologies
meet specific governmental mandates (e.g., EU, USA);
provide assistance in specific emergency situations (e.g., Tsunami).
Alerting systems are usually tailored to:
Large variety of emergencies and different continents 
Different requirements  Different systems/technologies
Traditional media
sirens, public loud-speakers, public displays, audible/ visual signals
Broadcast transmissions
paging, radio broadcast, TV broadcast
Personal interactive devices
terrestrial networks, land mobile networks, satellite-based mobile networks, Internet/ Web/ social Media
…but a single alert message format, CAP (Common Alerting Protocol) widely used:
Standardised in OASIS (CAP version 2) and ITU-T (X.1303).
Usually implemented as XML-based messages.
Transport of pure-text and enriched messages (audio, video, pictures).

5. The role of SatCom/SatNav Systems
Broadcast capabilities and large coverage area.
Resilience to infrastructure disruption.
Broadcast-Bidirectional fixed/mobile services (SatCom).
Positioning and location-based services (SatNav).
Satellite technology plays a key role in alerting communications
Data channels and new services exploitation (e.g. Galileo).
Alert message distribution over a large/specific area (location-based service).
Addressed to users equipped with a simple Galileo or SBAS (Satellite-Based Augmentation Systems)compliant receiver.
Big potential for SatNav in alerting application
Very limited rate: bit/s.
Tiny messages: bit.
Message fragmentation possible solution but source of further performance degradation in terms of delivery delay.
… but important limitations need to be considered

6. MAMES Concept MAMES shall:
Provide light, flexible and efficient alert message encapsulation.
Offer additional (optional) functions for service extension and adaptions towards specific crisis situations.
MAMES shall be implemented as a shim layer in the protocol stack, so as to:
Offer the encapsulations service towards the above protocol layer generating the alert message.
Interface to the underlying layer in order for MAMES packets to be properly transported by the network.
MAMES can work in different operative conditions:
End-to-end, implemented below the application layer.
Hop-by-hop, depending on the protocol stack implemented in the intermediate nodes.

7. Example of MAMES-Enabled Architecture

8. MAMES Positioning
MAMES is an encapsulation protocol for multiple alert messages transport over satellite links (e.g. :alert messages formatted according to different alert protocols, plain text, audio, images, videos, etc.)
MAMES frame structure includes the possibility of encapsulating a concatenation of multiple alert messages.
MAMES Extension Headers aims at improving the transport and rendering of the alert messages.
CAP is an alert message format; it is not an encapsulation protocol for transporting alert messages.
A4A protocol is an efficient CAP encoding mechanism that reduces CAP message size. It is not an encapsulation protocol for different alert messages. It does not support protocols different from CAP.

9. MAMES Encapsulation Protocol Design
MAMES main service is to provide encapsulation service
Further to this, additional services are envisaged:
Reliability, in terms of packet-layer coding, message repetition, or retransmission.
Security, in terms of authentication and encryption.
Message fragmentation.
Priority and QoS management (e.g., desired rate an delay).
Encapsulation of different formats’ alert messages.
Concatenation of multiple messages.
Support of multi-technology receiver.
Support of MAMES-level acknowledgements.
Support of ultra-short MAMES Messages (no encapsulated payload).

10. MAMES Message Structure
MH: essential data fields pertaining to the entire MAMES Message, e.g.: <Message ID>, <Alert Provider ID>, <Notification Area>, <Priority>.
Mandatory Header
Conditional Header
CH: coditional data fields pertaining to the entire MAMES Message (only if CAP is not in the payload) , e.g.: <Alert Issuer ID>, <Event Category>, etc.
Extension Headers (optional)
EHs: optional information pertaining to the entire MAMES Message, e.g.: <Alert Status>, <Alert Scope>, <Incident ID>, <Minimum Delay>, <Authentication/Integrity>, <Encryption>, <Fragmentation>, etc.
AMHs: information required to interpret the encapsulated Alert Messages, e.g.: <Language ID>, <Accessibility Indicator>, <Alert Message Length>; the 1st Alert Message Header pertains to the 1st Alert Message, etc.
Alert Message Headers
Alert Messages
(Payload)
Payload: original alert information as created by the Alert Issuer (emergency authority); can be a CAP message, text, images, audio, etc.

11. Examples of MAMES MessagesMH
MAMES Protocol Version
MAMES Message ID
MAMES Message Type
MAMES Alert Provider ID
Notification Area
MAMES Priority
Next Header Type
Example of MAMES Message:
Ultra-short MAMES Message
MAMES Protocol Version
MAMES Message ID
MAMES Message Type
MAMES Alert Provider ID
Notification Area
MAMES Priority
Next Header Type
Alert Issuer ID
MAMES Event Category MH
CMH
Payload: CAP and text
No CH
Some EHs
Next Header Type Concept
EHs
Status Header
Alert Scope Header
Authentication/Integrity Header
…..
Next Header Type
Specifies the type
of Alert Message #1
AMHs
Language ID
Accessibility Indicator
Alert Message Length
Next Header Type
Only Mandatory and Conditional Headers
No Payload
Size: 12 Bytes
Alert Messages
Payload
Alert Message #1
CAP message
Alert Message #2
Text message
"no more headers” code

12. Status of Standardisation in ETSI
STF 473 on going activities:
MAMES Specification: definition of the different types of MAMES message Frames.
Definition of the Mandatory and Extension Header Fields.
1° Phase
Current Status
(start of the 2° Phase)
2° Phase

13. Conclusions
Future alerting system will require cross-support and make use of different technologies
Delivery of alert messages for different emergency situations and different devices call for a smart alert message encapsulation protocol
MAMES is the result of the ongoing standardisation activity (STF 473) within ETSI SES SatEC
The final specification is expected to be taken as reference for future alert system to ease integration and improve alert management efficiency