SKELETON - ETSI · Web viewSTF 473 . Task 1.4 . Working Document v1.0. MAMES Message Definition...

Task 1.4

STF 473

Task 1.4 Working Document v1.0

MAMES Message Definition

[Authors: STF 473]

<

ETSI

TECHNICAL SPECIFICATION

Reference<Workitem>

Keywords<keywords>

ETSI

650 Route des LuciolesF-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 CAssociation à but non lucratif enregistrée à laSous-Préfecture de Grasse (06) N° 7803/88

Important notice

Individual copies of the present document can be downloaded from:http://www.etsi.org

The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat.

Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at

http://portal.etsi.org/tb/status/status.asp

If you find errors in the present document, please send your comment to one of the following services:http://portal.etsi.org/chaircor/ETSI_support.asp

Copyright Notification

No part may be reproduced except as authorized by written permission.The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute yyyy.All rights reserved.

DECTTM, PLUGTESTSTM, UMTSTM and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.3GPPTM and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and

of the 3GPP Organizational Partners.GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.

Task 1.42

http://portal.etsi.org/chaircor/ETSI_support.asp

http://portal.etsi.org/tb/status/status.asp

http://www.etsi.org/

Logos on the front pageIf a logo is to be included, it should appear on the right hand side of the front page.

Copyrights on page 2This paragraph should be used for deliverables processed before WG/TB approval and used in meetings. It will replace the 1st paragraph within the copyright section.

Reproduction is only permitted for the purpose of standardization work undertaken within ETSI.The copyright and the foregoing restriction extend to reproduction in all media.

If an additonal copyright is necessary, it shall appear on page 2 after the ETSI copyright notification

The additional EBU copyright applies for EBU and DVB documents.

© European Broadcasting Union yyyy.

The additional CENELEC copyright applies for ETSI/CENELEC documents.

© Comité Européen de Normalisation Electrotechnique yyyy.

The additional CEN copyright applies for CEN documents.

© Comité Européen de Normalisation yyyy.

The additional WIMAX copyright applies for WIMAX documents.

© WIMAX Forum yyyy.

ETSI

Task 1.43

ContentsIf you need to update the table of content you would need to first unlock it.To unlock the Table of Contents: select the Table of Contents, click simultaneously: Ctrl + Shift + F11.Then lock it: reselect the Table of Contents and then click simultaneously: Ctrl + F11.

Logos on the front page...............................................................................................................................3

Copyrights on page 2..................................................................................................................................3

If an additonal copyright is necessary, it shall appear on page 2 after the ETSI copyright notification.. .3

Intellectual Property Rights.........................................................................................................................6

Foreword.....................................................................................................................................................6

Introduction.................................................................................................................................................6

1 Scope.................................................................................................................................................6

2 References.........................................................................................................................................72.1 Normative references..................................................................................................................................72.2 Informative references................................................................................................................................7

3 Definitions, symbols and abbreviations............................................................................................83.1 Definitions...................................................................................................................................................83.2 Symbols.......................................................................................................................................................83.3 Abbreviations..............................................................................................................................................8

4 Workflow and General Assumptions for MAMES Frame Definition..............................................94.1 Workflow for the MAMES Frame Definition............................................................................................94.2 Proposed Alert Message Frame Structures...............................................................................................104.2.1 Previous Work on MAMES Frame Format Definition.......................................................................104.2.2 A4A Protocol Definition.....................................................................................................................114.2.3 Analysis of Existing Solution..............................................................................................................124.3 General Assumptions/Considerations for MAMES Frame Fields Definition..........................................124.4 Analysis of CAP Elements Relevant for MAMES Frame Fields Definition............................................14

5 MAMES Messages Classification..................................................................................................15

6 MAMES ALERT Message.............................................................................................................176.1 MAMES ALERT Frame Structure Definition..........................................................................................176.1.1 MAMES ALERT Message Elements Overview.................................................................................186.2 MAMES ALERT Header Fields Definition.............................................................................................196.2.1 Mandatory Header (MH).....................................................................................................................206.2.1.1 MAMES Protocol Version.............................................................................................................216.2.1.2 MAMES Message Type................................................................................................................216.2.1.3 MAMES Message ID....................................................................................................................226.2.1.4 MAMES Alert Provider ID...........................................................................................................226.2.1.5 Notification Area..........................................................................................................................236.2.1.6 MAMES Priority...........................................................................................................................246.2.1.7 ACK Request Flag.........................................................................................................................256.2.1.8 Alert Issuer ID..............................................................................................................................256.2.1.9 MAMES Event Category..............................................................................................................266.2.1.10 Next Header Type..........................................................................................................................276.2.2 Extension Headers (EHs)...................................................................................................................276.2.3 Alert Message Headers (AMHs).........................................................................................................276.2.3.1 Alert Message Type......................................................................................................................286.2.3.2 Language ID.................................................................................................................................286.2.3.3 Alert Message Length...................................................................................................................296.2.3.4 More AMHs Flag..........................................................................................................................296.3 MAMES Payload Definition.....................................................................................................................30

7 MAMES Ultra-short ALERT Message...........................................................................................32

ETSI

Task 1.44

7.1 Rationale and preliminary notes on use cases...........................................................................................327.2 MAMES Ultra-short ALERT: Structure and Header Definition..............................................................33

8 MAMES UPDATE Message..........................................................................................................358.1 Rationale and preliminary notes on use cases...........................................................................................358.2 General Assumptions/Considerations for MAMES UPDATE Definition................................................358.3 MAMES UPDATE: Structure and Header Definition..............................................................................378.3.1 MAMES Reference.............................................................................................................................39

9 MAMES CANCEL Message..........................................................................................................419.1 Rationale and preliminary notes on use cases...........................................................................................419.2 MAMES CANCEL: Structure and Header Definition..............................................................................41

10 MAMES ACK Message..................................................................................................................4410.1 Rationale and preliminary notes on use cases...........................................................................................4410.2 MAMES ACK: Structure and Header Definition.....................................................................................4410.2.1 MAMES Receiver Location................................................................................................................4610.2.2 MAMES Receiver ID..........................................................................................................................47

11 Traceability Matrix: Requirements - MAMES Frame....................................................................48

Annex A: Detailed Definition of MAMES Header Fields....................................................................50

A.1 <Notification Area>: Radius index.................................................................................................50

A.2 <MAMES Priority>: Map on CAP <urgency>...............................................................................51

A.3 < MAMES Event Category>: Map on CAP <category>................................................................51

A.4 <Language ID>: Map on ISO 639-1 Codes....................................................................................53

A.5 <MAMES User Location>..............................................................................................................57

Annex B (informative): Geographical Grid Systems Analysis.................................................................58

ETSI

Task 1.45

<PAGE BREAK>

Intellectual Property Rights<PAGE BREAK>

Foreword

Introduction<PAGE BREAK>

1 ScopeThe present document provides the definition of the overall MAMES Frame structure and the mandatory MAMES elements. Starting from the identified MAMES functional requirements, different types of MAMES Messages have been defined. For each of them, the structure, the Header and the Payload (if any) are specified in detail.

This report has been written in close coordination with the Task 1.5 report, which specifies the optional elements of the MAMES Header (Extension Headers).

ETSI

Task 1.46

2 References

2.1 Normative references

2.2 Informative references[i.1] Deering, S., and Hinden, R., “Internet Protocol, Version 6 (IPv6) Specification,” RFC 2460

[online], URL: http://tools.ietf.org/html/rfc2460

[i.2] Eddy, W., and Davies, E., “Using Self-Delimiting Numeric Values in Protocols,” RFC 6256 [online], URL: http://www.rfc-editor.org/rfc/rfc6256.txt

[i.3] L. Franck, R. Suffritti, “Multiple Alert Message Encapsulation over Satellite,” 1st International Conference on Wireless Communication, Vehicular Technology, Information Theory and Aerospace & Electronic Systems Technology, 2009, Wireless VITAE 2009, May 2009.

[i.4] De Cola, Tomaso and Mulero Chaves, Javier and Parraga Niebla, Cristina and Garrammone, Giuliano (2012) , A Novel Protocol to Transmit Alert Messages during Crises over GNSS. Ka-band and ICSSC Conference 2012, 24-27 Sept. 2012, Ottawa, Canada.

[i.5] Alert4all - D3.6 Communication system for dissemination of alert messages: architecture and design document, URL: http://www.alert4all.eu/images/deliverables_public/A4A_D3.6.DLR.v1.0.F.pdf

[i.6] Common Alert Protocol (CAP) Version 1.2, OASIS Standard, 1 July 2010 (authoritative version: http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.doc).

[i.7] N. Freed Innosoft, N. Borenstein,”Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types”, RFC 2046 [online], URL: http://tools.ietf.org/html/rfc2046

[i.8] http://www.loc.gov/standards/iso639-2/php/code_list.php

[i.9] http://epp.eurostat.ec.europa.eu/portal/page/portal/nuts_nomenclature/principles_characteristics

[i.10] http://epp.eurostat.ec.europa.eu/portal/page/portal/nuts_nomenclature/local_administrative_units

[i.11] http://tools.ietf.org/html/rfc6713

[i.12] http://www.iana.org/assignments/media-types/media-types.xhtml

ETSI

Task 1.47

http://www.iana.org/assignments/media-types/media-types.xhtml

http://tools.ietf.org/html/rfc6713%20

http://epp.eurostat.ec.europa.eu/portal/page/portal/nuts_nomenclature/local_administrative_units

http://epp.eurostat.ec.europa.eu/portal/page/portal/nuts_nomenclature/principles_characteristics

http://www.loc.gov/standards/iso639-2/php/code_list.php

http://tools.ietf.org/html/rfc2046

http://www.alert4all.eu/images/deliverables_public/A4A_D3.6.DLR.v1.0.F.pdf

http://www.rfc-editor.org/rfc/rfc6256.txt

3 Definitions, symbols and abbreviations

3.1 Definitions

3.2 Symbols

3.3 AbbreviationsAM Alert Message AMH Alert Message HeaderCBRNE Chemical, Biological, Radiological, Nuclear or high-yield Explosive threat or attackEH Extension HeaderMH Mandatory HeaderSDVN Self Delimiting Numeric ValuesP Payload

ETSI

Task 1.48

4 Workflow and General Assumptions for MAMES Frame Definition

This section aims at giving an overview of the procedure which leads to the definition of the MAMES Frame structure and the identification of the MAMES Header Fields. In particular the workflow followed for the MAMES Frame definition is reported, together with a detailed description of some of the main considered inputs (e.g. proposed alert message structures, general assumptions, etc).

4.1 Workflow for the MAMES Frame Definition Figure 1 depicts the workflow that has been followed for the MAMES Frame definition and the identification of the MAMES Header fields. In detail:

some of the main inputs considered for the definition of the MAMES Message are highlighted. These are:

- MAMES Functional Requirements (Task 1.3 MAMES Requirements Document);

- Proposed Alert Message Frame Structure (Previous work on MAMES Frame format definition [i.3] and A4A Protocol [i.4] [i.5]);

- CAP (elements of <alert> and <info> segments) [i.6];

- General Assumptions and Considerations for MAMES Frame Elements and mandatory fields definition;

- Specific Assumptions and Considerations for the optional MAMES Headers definition;

the main outputs are shown: MAMES Frame structure and MAMES Frame elements definition;

the input-output relations are reported;

an indication of the document reporting the inputs analysis and the outputs definition is provided.

Figure 1: Workflow for MAMES Frame Definition

ETSI

Task 1.49

4.2 Proposed Alert Message Frame Structures A brief description of the previous work on MAMES Frame format definition [i.3] and of the A4A Protocol [i.4] [i.5] is provided to better introduce the choices that will be taken for the MAMES Frame definition.

4.2.1 Previous Work on MAMES Frame Format Definition According to [i.3], the MAMES Frame format relies on a mandatory header and on two further MAMES components:

Transport Enhancers, which optionally provide mechanisms to support the implementation of reliability, segmentation and re-assembly, congestion control functions, overcoming the limitation of underlying communication protocol stack (indications for improving the alert message transport).

Message Enhancers, which optionally provide additional data to improve the rendering of the alert message on devices with heterogeneous capabilities.

Details of Message and Transport Enhancers are provided in Task 1.5 document.

Taking into account the concepts of Transport and Message Enhancers, the MAMES frame format is composed of four fields:

A header specifying the frame length. The first bit of the length field is used to indicate the size unit (bytes or 512 bit word). This yields a maximum size of about 2MByte. A message enhancer may be used to implement padding.

A sequence of zero or more transport enhancers.

A sequence of zero or more message enhancers.

The alert message.

Transport and Message Enhancers are similar to extension headers from IPv6 and they include a type identifier and a pointer to the next block. Implementations are expected to discard enhancers of unsupported types. The overhead of the MAMES frame (excluding the enhancers) compared to the alert message is 2 bytes. Figure 2 depicts the MAMES Frame format (b means bit, B means Byte and fields lengths starting with X are variable).

Figure 2: MAMES Frame Format [i.3]

ETSI

Task 1.410

4.2.2 A4A Protocol Definition

The A4A protocol has been devised to enable efficient transport of alert messages over narrowband channels, such as GNSS systems (e.g., SBAS, GPS, Galileo) that can jeopardize the timely delivery of messages because of the very limited data rate they can offer to upper protocol layers and the reduced amount of data each GNSS frame can carry.

In more detail, the A4A protocol re-encodes CAP messages in order to preserve the content of the original message generated by the involved authorities. The ASN.1 specification of CAP is taken as reference to perform an efficient re-processing of the alert message and specification of A4A protocol message format. Finally, additionally to native CAP capabilities, optional functions have been also introduced to meet some alerting application requirements which are not accounted in the CAP specification, such as: message fragmentation, priority management, security mechanisms (source authentication, encryption, and message integrity), resilience against link errors (erasure coding and retransmission strategies).

The A4A protocol data unit (PDU) is structured so as to collect the mandatory fields of Alert and Info sections of the corresponding CAP message in a single protocol block (A4A_PrimaryHeader), whereas the actual text message is encoded in a dedicated block (A4A_SecondaryHeader). This approach allows a receiver to process only the first block in the case it does not implement capabilities to process and display (or play) the pure text message. Extensions follow as separate and independent blocks (A4A_ExtensionsHeader). In more detail, the overall A4A PDU structure is sketched in Figure 3:

Figure 3: A4A Protocol Data Unit [i.4]

To achieve a flexible and efficient protocol design, A4A protocol adopts the principle of Next Header (NH) to generate as many extensions as needed, preventing some limitations in the support of new options. The general Next Header principle is reported in Figure 4. The Header Type (HT) indicates which header is being implemented. Further to this, the SDNV [i.2] encoding is also used to encode the variable-length fields of the CAP specification, which would require a TLV (Time-Length-Value) approach thus imposing some additional overhead that could make the transmission over GNSS quite challenging.

Finally, in order to make the description of the geographic area lighter in terms of number of bits to be transmitted, the geocode field is specified according to NUTS (Nomenclature of territorial units for statistics: levels 1, 2, and 3) [i.9] and LAU (Local Administrative Units: levels 1 and 2, formerly NUTS 4 and 5) [i.10] and encoded as SDNV values. In addition to a more concise representation of the reference area, this approach also allows representing areas in terms of administrative boundaries, which can be of certain benefit to efficiently coordinate rescue or support operations when a crisis situation affects different administrative zones.

Figure 4: A4A Next Header Principle [i.4]

ETSI

Task 1.411

4.2.3 Analysis of Existing SolutionThe following table summarizes the benefits and the limitations of the solutions described in the previous subsections. This analysis helps to clarify the MAMES Frame structure definition, which aims at overcoming the main drawbacks of the existing proposed solution for the delivery of Alert Messages.

Table 1: Benefits and Limitations of Existing Solutions

Solution Benefits Limitations

MAMES

(Previous work [i.3])

Preliminary work on MAMES (useful input)

Encapsulation Protocol for Alert Messages

Flexibility (Next Header principle)

Transport and Message Enhancers concept

MAMES Frame Format definition does not include the possibility of encapsulating a concatenation of multiple Alert Messages.

Only some examples of Message and Transport Enhancers fields are provided and some of them need clarifications (e.g. required data rate, required delay, etc).

A4A Protocol

[i.4]

Flexibility (Next Header principle)

It can encapsulate CAP

Efficient CAP encoding mechanism (SDNV encoding of CAP fields) that reduces CAP message size and enables the transmission of it over narrowband communication channels (as GNSS systems), including the implementation of function extension.

.

A4A protocol is not an encapsulation protocol for different alert messages.

It does not support protocols different from CAP.

4.3 General Assumptions/Considerations for MAMES Frame Fields Definition In this section general assumptions/considerations that have been taken into account for the definition of the different MAMES Frame elements (and in particular for the identification of the MAMES Header fields) are reported.

Table 2 lists some of the main assumptions/considerations introducing potential solutions, recommendations and corresponding open issues (if any). Their numbering is only for reference purpose (useful for the following sections), it does not denote a priority order. However some of the reported assumptions derive from others (this is highlighted in the table).

This list will be updated in case some other assumptions will be required; on the other hand specific assumptions/considerations related to the identification and definition of Extension Headers fields are reported in Task 1.5 Document.

Table 2: General Assumptions/Considerations for MAMES Frame Definition

No.# Assumption/Consideration Proposed Solution/Recommendation/Open Issue

g-0The MAMES Message should encapsulate a single or multiple Alert Messages (e.g. to address the different rendering capabilities of Alerting Devices).

The MAMES Frame Structure and MAMES Header elements should be defined with the aim to allow the transmission of a single or multiple Alert Messages.

E.g: In the latter case the Alert Messages can be characterized by different kind of media types (text, audio, image, etc.) and different languages.

g-1 The information contained in the mandatory MAMES Header element should refer to the whole MAMES Message, which may encapsulate different types of Alert

The mandatory elements of the MAMES Header should be defined considering the essential information required for the

ETSI

Task 1.412

Messages.

Only essential information should be included in the mandatory MAMES Header element, whose fields/indicators/parameters are required for protocol organisation, for encapsulation purposes, and for MAMES Message filtering at the MAMES receiver side.

transmission of the MAMES Frame.

g-2

The additional/optional information for MAMES Message encapsulation, decapsulation and rendering should be contained in the optional MAMES Header Elements. These should be classified as elements which refer to the whole MAMES Message and elements which refer to specific Alert Messages (encapsulated in the payload).

Some optional MAMES header elements that refer to the whole MAMES Message should be defined. It is proposed to name these elements Extension Headers of the MAMES Message.

Optional MAMES header elements that refer to a specific Alert Message (contained in the payload) should be defined. It is proposed to name these elements Alert Message Headers.

For each Alert Message contained in the MAMES payload the corresponding Alert Message Header is required.(see also assumption # g-0).

g-3

Since the mandatory and some of the optional MAMES Header Elements should refer to the whole MAMES Message, the identification of their fields requires that all the encapsulated Alert Messages (in the MAMES payload) have common features (e.g. in terms of scope).

Any given MAMES Message should pertain to only one specific event (incident); the zero or more Alert Messages encapsulated in the MAMES Payload should relate to different aspects of that event.

Any given MAMES Message should pertain to only one notification area.

All the encapsulated Alert Messages are assumed to be sent at the same time by an Alert issuer.

(derived from assumptions: # g-2, # g-3)

It is proposed to assume:

“One MAMES Message => One Event => One Notification Area => One event category => One Alert Issuer => One time alert issued”.

This seems to be the most natural assumption to avoid a too complicated MAMES Message (too many possible combinations should be considered).

Furthermore, after having composed a MAMES Message, the MAMES Alert Provider should submit the completed Message as soon as possible, with all the alert information it has at the moment; it should not wait for potential additional information from another Alert Issuers, relating to another event, another notification area, etc.

However, although all encapsulated Alert Messages (MAMES Payload) should refer to the same incident, they could:

carry different information; be characterized by different kind of media (text,

audio, image, etc.); be characterized by different languages.

g-4

The MAMES Alert Provider must have a good understanding of the incident, and decide whether or not to include optional headers and how to set values.

A distinction between the Alert Issuer and the MAMES Alert Provider reflecting the Protocol Layer Architecture entities (defined in Task 1.3 Protocol Architecture Document) is required.

The MAMES Alert Provider thus effectively plays the role of a “secondary Alert Issuer”.

Additionally, it would be desirable to have a kind of automatic, “pure” encapsulation mode (where no decisions are required on the part of the MAMES Alert Provider). E.g., if a CAP message arrives, there are two “automatic” possibilities: (1) set MAMES mandatory,and optional headers algorithmically (possibly by snooping CAP) + encapsulate + submit; or (2) build the mandatory MAMES Header (by snooping CAP) + submit without payload (useful for low-bandwidth Satcom systems).

g-5 Different types of MAMES Message should be defined based on the message purpose (e.g. message function, target audience) and satellite network transmission constraints (e.g. MAMES Transmission over GNSS

It is proposed to define different kind of MAMES Message ( see section 5).

Among them, the Ultra-short MAMES Message, which is characterized by an empty payload, is defined to allow the

ETSI

Task 1.413

Systems).transmission of MAMES Message over narrowband satellite channels. This message represents the shortest MAMES message.

g-6 Two or more CAP Alert Messages can be encapsulated in the MAMES Payload only if they are one the translation of the others (different languages).

Any given MAMES Frame shall not contain different CAP Alert Messages that are written in the same language. Different MAMES Frame shall be used in that case.

4.4 Analysis of CAP Elements Relevant for MAMES Frame Fields Definition

The analysis of all the elements of the CAP <alert> and <info> segments, including discussion/recommendation for the applicability of analogous or corresponding indicators as potential MAMES parameters, is reported in the Annex A1 of the Task 1.5 Document.

As depicted in Figure 1, the aim of this analysis is to identify key parameters for MAMES, and not to provide a “mapping” between CAP and MAMES.

1 In order to better identify the CAP parameters, which are relevant for the definition of the Mandatory MAMES elements (main objective of Task 1.4), these are marked by a grey shaded row (CAP elements table).

ETSI

Task 1.414

5 MAMES Messages ClassificationThis section aims at introducing the different types of MAMES Messages that have been defined. These are:

MAMES ALERT

Ultra-short MAMES ALERT (Us-ALERT)

MAMES UPDATE

MAMES CANCEL

MAMES ACK

In order to identify the type of MAMES Message an indicator shall be defined and it is named “MAMES Message Type”.

Moreover, while the MAMES ALERT represents the “ordinary” MAMES Message, Ultra-short MAMES ALERT, MAMES UPDATE, MAMES CANCEL and MAMES ACK, are also referred to as “special types” of MAMES Message.

Among the MAMES “special types” of MAMES Message, it is worth highlighting that the Ultra-short MAMES ALERT type is characterized by an empty payload, while the other ones may or may not include a payload. Empty payload means that only the MAMES Header is transmitted. Further details are provided in the following sections, where for each type of MAMES Message the frame structure is defined together with preliminary notes on use cases.

In figure 5 an overview of the MAMES Message Types is depicted.

Figure 5: MAMES Message Classification

ETSI

Task 1.415

The proposed MAMES structure aims at not mixing elements of the header and of the payload, therefore, as better described in the following, it consists of a MAMES Header (which may include different groups of headers) and a payload (single or multiple alert messages). The rendering devices would normally just need one Alert Message, so they could jump directly to the interested message once the whole MAMES header is processed.

ETSI

Task 1.416

6 MAMES ALERT Message

6.1 MAMES ALERT Frame Structure DefinitionStarting from the MAMES functional requirements and taking into account the inputs from the previously described protocol specifications, one of the main features considered in the MAMES Frame structure definition is the flexibility of the protocol. In detail, flexibility: (i) to future extensions (e.g. new Alert Message Protocols); (ii) to meet the heterogeneity of the Alerting Devices capabilities; (iii) to the integration of the already existing communication networks; (iv) to different kind of data channels capacity aiming at efficiently transmitting alert messages even in narrowband channels or in critical conditions characterized by scarce availability of network resources.

The MAMES Frame definition is inspired by the Next Header concept of the IPv6 protocol [i.1].

As depicted in Figure 3, MAMES Frame is composed of:

a set of MAMES Headers, which comprise:

Mandatory Header (MH)

Extension Headers (EHs)

Alert Message Headers (AMHs)

a MAMES Payload, comprising a concatenation of Alert Messages (it can be a single or multiple Alert Messages)

While in Figure 6 MAMES Message structure and notation is reported, an overview of the different MAMES Elements is provided in the following subsection, where the concepts of “Mandatory” and “Optional” are explained and the main features of each element are highlighted.

ETSI

Task 1.417

Figure 6: MAMES Frame Structure and Notation

As better described in the following subsection:

the Mandatory Header and the Extension Headers refer to the entire MAMES Message.

each Alert Message Header is associated to an Alert Message contained in the MAMES payload. In particular: Alert Message Header #1 refers to Alert Message #1, Alert Message Header #2 refers to Alert Message #2 and so on.

6.1.1 MAMES ALERT Message Elements Overview In the description of the different elements of MAMES Frame, the following qualifications are used:

Mandatory: Mandatory MAMES element.

Optional: Optional MAMES element.

Table 3 lists and briefly describes the elements of the MAMES Frame.

Table 3: MAMES Frame Elements

MAMES Element Element Optionality Brief Description Notes

ETSI

Task 1.418

MA

MES

HEA

DER

Mandatory Header (MH)

MANDATORY

MH shall be present in every MAMES Message

It is of fixed length.

It contains several mandatory header fields pertaining to the entire MAMES Message

The last header field of the Mandatory Header shall specify the type of the next header (“Next Header Type”). This can obviously be one of the following headers:

- The 1st Extension Header; or

- The 1st Alert Message Header; or

- “No more headers” (a special code shall be used for the Next Header Type to indicate that no more headers follow)

The corresponding fields are detailed in this document.

Extension Headers

(EHs)OPTIONAL

It contains several optional headers pertaining to the entire MAMES Message.

Those optional headers that are of variable length contain a field indicating the length of the header, the “Header Length” field.

Each one of these optional headers shall end with a “Next Header Type” field, specifying the type of the next header (e.g. EH or AMH or “no more headers”). A special code shall be used to indicate when no more headers follow, i.e., no Alert Message is attached.

The corresponding fields are detailed in Task 1.5 document.

Alert Message Headers

(AMHs)

OPTIONAL

Alert-Message specific headers (one for each Alert Message contained in the MAMES Payload).

Each Alert Message Header is mandatory if a corresponding alert message is contained in the MAMES Payload

It contains only mandatory fields

The AMHs fields are:

- Alert Message Type, specifying the Alert Protocol/data type of the AM.

- Language ID, indicating the language of the pertaining Alert Message;

- Alert Message Length, denoting the length of the pertaining Alert Message (in Bytes);

- ”More AMHs Flag”, denoting that more AMH(s) follow (flag value 1) or no more AMH(s) follow (flag value 0)

The mandatory fields are detailed in this document

MA

MES

Alert Messages

(AMs)OPTIONAL 1. Alert Messages (N times) – collectively called

“Payload”

The MAMES Payload is detailed in this document.

6.2 MAMES ALERT Header Fields DefinitionIn this section the fields of each MAMES Header Element (MH, EHs, AMH ) are defined.

The following table reports a list of all allowed MAMES header types, which need to be associated to an unique code value. The defined codes will be used for the Next Header Type field of the MAMES Headers to indicate the type of the header that follows.

ETSI

Task 1.419

In detail the “Next Header Type” specifies the type of the next header. In case “no more headers” follow a special code is used: “0000”.

Table 4: Definition of the codes for the MAMES Next Header Types

Header Group Code MAMES Header Type Brief Description

EH

0001 Extension Header A It denotes the appropriate handling and the intended distribution of the MAMES message..

0010 Extension Header B It denotes the incident ID and the time when the alert was (first) issued by the Alert Issuer.

0011 Response Type Header It denotes the recommended type of action

0100 Validity Header It denotes the start and end time validity of the MAMES Message

0101 Administrative Areas Header It denotes the Administrative Area to be alerted.

0111 Authentication/Integrity Header It is used for Authentication/Integrity.

1000 Encryption Header It is used for Encryption..

AMH 1001 Alert Message HeaderIt denotes the presence of at least one AM in the MAMES Payload and it provides information related to that AM

6.2.1 Mandatory Header (MH)The Mandatory Header is mandatory and of fixed length.

The Mandatory Header of the MAMES Frame shall be processed by every MAMES Agent.

Table 5 reports a list of the proposed Mandatory Header fields (including length) giving an overview of the parameters of the Mandatory Header element of the MAMES Message. Details on each field are reported in the following subsections.

Table 5: Mandatory Header Fields List

Field # Length (bits)1 Field Brief Description

1 4 MAMES Protocol Version Version of the MAMES protocol used for Alert Messages encapsulation.

2 3 MAMES Message Type It indicates the type of the MAMES Message (ALERT, UPDATE, CANCEL, ACK)

3 10 MAMES Message ID Identifier of the MAMES Frame

4 10 MAMES Alert Provider ID Identifier of the sender of the MAMES Message

5 41 Notification Area It indicates the geographical area where the MAMES Message needs to be delivered.

6 3 MAMES Priority Priority of the MAMES Frame with respect to other MAMES Frames

7 1 ACK Request Flag It indicates if a MAMES ACK Frame is requested by the MAMES Alert Provider.

8 12 Alert Issuer ID Identifier of the (original) source of the Alert Message, i.e., the emergency authority.

9 4 MAMES Event Category Identifier of the event (incident) category.

1 The length represents the minimum number of bits required by the corresponding Header field. Header byte –alignment will be part of the Task 2.1 activity.

ETSI

Task 1.420

10 4 Next Header Type It identifies the type of the Header immediately following the MAMES Mandatory Header.

6.2.1.1 MAMES Protocol Version

Table 6: “MAMES Protocol Version” Mandatory Header Field

Proposed Header Field Name MAMES Protocol Version

Belongs to Header Group Mandatory Header

Reference. -

Requirement -

Description/ Rationale Version of the MAMES protocol used for Alert Messages encapsulation.

Field Optionality MANDATORY

Length (bits) 4

Code Values 0001 - First Version of the MAMES Protocol

0010 – Second Version of the MAMES Protocol

….

Conclusion/ Recommendation/ Notes

The MAMES Protocol Version is the first field of the MH and shall be used to specify the version of the MAMES Protocol used for the Alert Messages encapsulation.

6.2.1.2 MAMES Message Type

Table 7: “MAMES Message Type” Mandatory Header Field

Proposed Header Field Name MAMES Message Type


Reference. CAP < msgType>

Requirement REQ-gen-fctl-14 - REQ-gen-fctl-17

Description/ Rationale

It refers to the type of the MAMES Message, not the type of the encapsulated Alert Message (although the type may be inherited). Five different types of MAMES Messages are defined: ALERT, Ultra-short ALERT, ACK, UPDATE, CANCEL.

Only in the “ALERT” and “UPDATE” MAMES Message type cases the payload may consist of multiple concatenated Alert Messages.


Length (bits) 3

Code Values Five codes are used to identify the different MAMES Message types. These are:100: MAMES ALERT001 MAMES UPDATE

ETSI

Task 1.421

010 CANCEL

011 MAMES ACK

000 Ultra-short MAMES ALERT

NOTE: All other values are reserved.


The MAMES Message Type shall be used to specify the type of MAMES Message.

The acknowledgement/cancel/update at Alert Protocol level will be encapsulated in a MAMES Frame with “MAMES Message Type” equals to 011/010/001, respectively.

6.2.1.3 MAMES Message ID

Table 8: “MAMES Message ID” Mandatory Header Field

Proposed Header Field Name MAMES Message ID


Reference. CAP < identifier>

Requirement REQ-gen-fctl-16


The unique identifier of this particular MAMES Frame.

The MAMES Message ID is set by the MAMES Alert Provider, and thus has only local significance to this MAMES Alert Provider. The value pair (MAMES Message ID, MAMES Alert Provider ID) has global significance and univocally identifies a MAMES Message.


Length (bits) 10

Code Values The MAMES Alert Provider is responsible for the numbering of MAMES Messages. Consecutive binary coded numbers are used.

0000000001 – First MAMES Message sent by the MAMES Alert Provider A

0000000010 – Second MAMES Message sent by the MAMES Alert Provider A.

........


The MAMES Message ID shall be used as an identifier of a MAMES Message originated by a MAMES Alert Provider. It is required for MAMES UPDATE, CANCEL and Ultra-Short MAMES ALERT. On the contrary it is not part of the MH of a MAMES ACK Frame, which is originated by the MAMES Receiver.

6.2.1.4 MAMES Alert Provider ID

Table 9: “MAMES Alert Provider ID” Mandatory Header Field

Proposed Header Field Name MAMES Alert Provider ID


Reference. CAP < sender>


Description/ Rationale Identifier of the sender of the MAMES Message (MAMES Alert Provider).The MAMES Alert Provider ID identifies the MAMES Alert Provider, which is responsible for encapsulating the Alert Messages received by different Alert Issuers.

ETSI

Task 1.422

An identifier will be assigned to every MAMES Alert Provider and a map will be taken updated.

The combination of the MAMES Alert Provider and the MAMES Message ID will univocally identify a MAMES Message.


Length (bits) 10

Code Values Each MAMES Alert Provider is identified by a binary coded number:

0000000001 - MAMES Alert Provider A

0000000010 - MAMES Alert Provider B

......


The MAMES Alert Provider ID shall be used in all types of MAMES Messages.

The MAMES Alert Provider ID is the MAMES equivalent of the CAP <sender> field and shall be a MANDATORY field of the MAMES MH.

6.2.1.5 Notification Area

Table 10: “Notification Area” Mandatory Header Field

Proposed Header Field Name Notification Area


Reference. WGS84 (World Geodetic System 1984), CAP <geocode>, <areaDesc> (CAP area segment)

Requirement REQ-user-fctl-002


Geographic code identifying the affected area of the alert messages contained in the payload.

Many different systems for the Notification Area coding have been analysed, focusing on geographical codes and avoiding administrative unit subdivisions codes. These are: WGS84, Universal Transverse Mercator (UTM), World Geographic Reference System (WGRS), Global Area Reference System (GARS)., Military Grid Reference System (MGRS) and Maidenhead Locator. The analysis is reported in Annex B.

However the identification of the Notification Area specifying a point on a map (geographical Coordinates) and a radius seems to be a good trade-off between geo location information and required number of bits.

Moreover although a circle is not always the best solution for select the area to be notified (squared and polygonal areas are preferred), it is worth noticing that the information carried by the Notification Area Field can be seen as a “coarse” representation of the real area to be alerted. A “fine” representation is left to the encapsulated Alert Message and the receiver is responsible for the rendering of the Alert Message based on its coordinates.

Additionally, an “Administrative Areas” EH has been defined (see the Task 1.5 Report) which allows the MAMES Alert Provider to specify administrative/political regions where the MAMES Frame shall be received and processed. A MAMES Receiver shall process a MAMES Frame only if both the “Notification Area” and the “Administrative Areas” criteria are met.

The proposed Notification Area code is a purely geographical code which consists of:

a point (latitude and longitude)

a radius (index, see Annex A.1)


Length (bits) 45

Code Values The code value identifying the Notification Area is implemented as a bit array consisting of the sub-code fields listed in the following.

Sub-code field Range Bit-size

ETSI

Task 1.423

Latitude N/S 0-1 1

Latitude Degrees 0-89 7

Latitude Minutes 0-59 6

Latitude Seconds 0-59 6

Longitude N/S 0-1 1

Longitude Degrees 0-179 8

Longitude Minutes 0-59 6

Longitude Seconds 0-59 6

Radius Index2 0-16 4


The MAMES Notification Area, denoting the geographical area to be alerted, shall be part of the MH, while an EH is defined for the identification of the administrative units to be alerted within the notification area (see Task 1.5 document).

The notification area of the different Alert Messages contained in the MAMES payload shall belong to the same area (see assumption # g-3).An area shall be defined and the identification code shall be part of the Mandatory Header of the MAMES Frame.

This allow the transmission of the MAMES message over a large area and in the same time the rendering of the MAMES message only by the alerting receiving devices of the affected area.

The proposed code allows a compact representation of the Notification Area field.

6.2.1.6 MAMES Priority

Table 11: “MAMES Priority” Mandatory Header Field

Proposed Header Field Name MAMES Priority


Reference CAP < urgency>



Priority of the MAMES Frame with respect to other MAMES Frames

Among the CAP elements, which can be related to the priority that need to associate to an Alert Message (<urgency>, <severity> and <certainty>), the <urgency> field is chosen to be used as an indicator of the MAMES Priority.

However, although MAMES priority value can be inherited from the priority of the encapsulated alert messages, it is “priority ” at MAMES level.

The priority field is only read at the receiver and it will be used to prioritize the visualization of the Alert Messages; it may be also read at intermediate nodes, if the intermediate nodes are snooping the MAMES Frame, and it can be used to prioritize the transmission when different MAMES Frames are competing to be transmitted. In any case there should be an automatic translation from the value of the urgency CAP field (if CAP is transported), or through some other mechanisms, if CAP is not transported.


Length (bits) 3

Code Values Five MAMES Priority levels are defined. Since the MAMES priority is inherited from the urgency of the encapsulated alert message, a map between the CAP <urgency> values and MAMES Priority code values is reported in Annex A.2.

2 The radius indexes are detailed in the Annex A.1.

ETSI

Task 1.424

<MAMES Priority> Description

001 Very High - The MAMES Message should be sent immediately

010 High – The MAMES Message should be sent soon.

011 Medium - The MAMES Message should be sent in the near future.

100 Low – The MAMES Message should be sent, although the responsive action of the encapsulated alert messages is no longer required.

000 Unspecified - The priority is not known (the urgency of the encapsulated Alert Messages is unspecified).



This field denotes the priority at MAMES level, which should be specified by the MAMES Alerter-Side Agent and taken into account for satellite system resource assignment (optionally) by the MAMES Alert Provider and by the Intermediary System (with MAMES Protocol Termination). Moreover it should be enacted by the MAMES User-Side Agent for rendering purposes.

All the Alert Messages contained in the MAMES Payload shall have the same MAMES Priority.

3-bit field length should be considered (longer than currently necessary) to accommodate later features/updates

6.2.1.7 ACK Request Flag

Table 12: “ACK Request Flag” Mandatory Header Field

Proposed Header Field Name ACK Request Flag


Reference. -



This header field, implemented as a 1-bit flag, is used by the MAMES Alerter Side Agent to request, from the MAMES Receiver, an acknowledgement indicating successful reception of the MAMES Frame. The MAMES Receiver shall reply with an ACK Frame (see section 10), if a return link is available.


Length (bits) 1

Code Values 0 – The MAMES Alert Provider does NOT request for MAMES ACK

1 – The MAMES Alert Provider DOES request for MAMES ACK

Conclusion/ Recommendation/ Notes The ACK Request Flag shall be used to request a MAMES ACK Frame (mandatory).

6.2.1.8 Alert Issuer ID

Table 13: “Alert Issuer ID” Mandatory Header Field

Proposed Header Field Name Alert Issuer ID


Reference CAP <source>

Requirement REQ-alerter-fctl-004

Description/ Rationale Identifier of the emergency authority that issued the Alert Message.

ETSI

Task 1.425

An identifier will be assigned to every Alert Issuer.

In detail a pre-defined mapping table “Alert Issuer name Alert Issuer ID” shall be used by the MAMES Alert Provider when setting the Alert Issuer ID in a given MAMES Frame.


Length (bits) 12

Code Values Each MAMES Alert Issuer is identified by a binary coded number:

000000000000 - MAMES Alert Issuer Unspecified

000000000001 - MAMES Alert Issuer A

000000000010 - MAMES Alert Issuer B

......


The Alert Issuer ID shall be used to identify the issuer of the Alert Message (emergency authority).

If the Alert Issuer is not specified, a special code is used: “000000000000”

6.2.1.9 MAMES Event Category

Table 14: “Category” Mandatory Header Field

Proposed Header Field Name MAMES Event Category


Reference CAP <category>



Identifier of the event (incident) category.To identify the event category associated to MAMES Message, the CAP <category> field is chosen to be used as an indicator of the MAMES Event Category.


Length (bits) 4

Code Values The <MAMES Event Category> values include all the CAP <category> values and a value denoting “unspecified event catagory”. A map between the CAP <category> values and <MAMES Event Category> code values is reported in Annex A.3.

<MAMES Event Category> Description

0001 Geophysical (inc. landslide)

0010 Meteorological (inc. flood)

0011 General emergency and public safety

0100 Law enforcement, military, homeland and local/private security

0101 Rescue and recovery

0111 Fire suppression and rescue

1000 Medical and public health

1001 Pollution and other environmental

1010 Public and private transportation

1011 Utility, telecommunication, other non-transport infrastructure

1100 Chemical, Biological, Radiological, Nuclear or High-Yield

Explosive threat or attack

ETSI

Task 1.426

1101 Other events

0000 The event is not specified.



The MAMES Event Categry shall be used to identify the category of the event, if unspecified the 0000 code shall be used.

A MAMES Message shall refer to one event, therefore all the encapsulated Alert Messages (contained in the Payload) refer to the same event (see assumption # g-3).

The code value “0000”, which means “Unspecified” is used if CAP is not included in the Payload and the event category is not specified by the encapsulated Alert Messages.

6.2.1.10 Next Header Type

Since the “Next Header Type” is a MAMES Header Field that is used as an identifier of the type of the next header of the considered MAMES Message, in the following a general definition of this field is provided. It is valid for all the defined MAMES group of headers. A reference to the last column of Table 4 is given in the “Code Values” row of the Table 15 in order to identify the code values allowed for each specific MAMES group of headers

Table 15: “Next Header Type” Field for (MH, EHs and AMHs)

Proposed Header Field Name Next Header Type


Reference IPv6 Next Header Concept [i.1]

Requirement REQ-gen-fctl-009; REQ-gen-fctl-010, REQ-alerter-fctl-004

Description/ RationaleIt specifies the type of the next header.

In particular it identifies the type of the Header immediately following the current header. It can be an EH, an AMH, or otherwise denote that “no more headers” follows.


Length (bits) 4

Code Values See Table 4 (last column) for the identification of the allowed ID values.

The ID associated to the “no more headers” case is “0000”.


The Next Header Type field shall be used as a pointer to the next header. A special code shall be used for the Next Header Type to indicate “no more headers”. This special code is allowed in MH and EHs

6.2.2 Extension Headers (EHs)The Extension Headers refer to the entire MAMES Message, therefore each EH is represented by common features that are valid for all Alert Messages contained in the MAMES Payload.

For details see Task 1.5 Document.

6.2.3 Alert Message Headers (AMHs)Differently from MH and EHs, Alert Message Headers (#1- #N) refer only to their correspondent Alert Messages. As an example AMH #1 refers to Alert Message #1 and therefore contains additional information only for Alert Message #1.

In the following the proposed fields of the AMHs are listed and described. All the defined fields are mandatory.

Table 16: Alert Message Header Fields List

Field Length Field Brief Description

ETSI

Task 1.427

# (bits)

1 11 Alert Message Type It specifies the Alert Protocol type or the type of data of the Alert Message (contained in the Payload) this specific AMH refers to.

2 8 Language ID It specifies the language of the corresponding Alert Message.

3 27 Alert Message LengthLength of the pertaining Alert Message (in Bytes)

4 1 More AMHs Flag It denotes if the an AMH follows/does not follow the specific AMH.

6.2.3.1 Alert Message Type

Table 17: “Alert Message Type” Alert Message Header Field

Proposed Header Field Name Alert Message Type

Belongs to Header Group Alert Message Header

Reference CAP <mimeType>, <uri> and <digest> (CAP resource segment),

Requirement REQ-gen-fctl-001; REQ-gen-fctl-002; REQ-gen-fctl-003; REQ-gen-fctl-004; REQ-gen-fctl-005;


It specifies the type of data or Alert Protocol of the AM the AMH refers to.

To indicate the type of media (text, audio, …) contained in the MAMES payload, MIME type/subtypes are used. The MIME type/subtypes are kept consistent with the standard, therefore a map between the MIME type/subtypes and the Alert Message Type will be provided and updated.

Currently, taking into account all the MIME type/subtypes (≈1480) and the Alert protocol listed in table 19 (supported MAMES Alert Message Types,) 11 bits are needed to encode this field of the AMH.


Length (bits) 11

Code Values Table 19 provides a map between the Alert Message Types (decimal value) and the Alert Protocol/data types of the AM.



The Alert Message Type shall be used to identify the supported type of the Alert Message (contained in the payload), the AMH refers to.

6.2.3.2 Language ID

Table 18: “Language ID” Alert Message Header Field

Proposed Header Field Name Language ID


Reference ISO 639 -1 [i.8]


Description/ Rationale It specifies the language used in the corresponding Alert Message.

ETSI

Task 1.428

To specify the Language ID, among different possible options (e.g.: RFC 3066, and RFC5646), the ISO 639 -2 is taken as a reference.


Length (bits) 8

Code Values A map of the ISO 639-1 codes and the MAMES <Language ID> is reported in Annex A.4.


Conclusion/ Recommendation/ Notes The Languege ID shall be used to identify the language of the Alert Message the AMH refers to.

6.2.3.3 Alert Message Length

Table 19: “Alert Message Length” Alert Message Header Field

Proposed Header Field Name Alert Message Length


Reference CAP <size> element of the resource segment


Description/ Rationale It denotes the length of the pertaining AM (in Bytes)


Length (bits) 28

Code Values The code values are represented by the number of Bytes (binary encoded) of the length of the Alert Message, the AMH refers to. 28 bits allow a maximum Alert Message size of ~268MB.


The Alert Message Length shall be used to specify the length of the AM the AMH refers to.

It is assumed that the maximum Alert Message size is about ~268MB.

6.2.3.4 More AMHs Flag

Table 20: “Alert Message Length” Alert Message Header Field

Proposed Header Field Name More AMHs Flag


Reference -

Requirement REQ-gen-fctl-006; REQ-gen-fctl-007

Description/ RationaleIt denotes if an AMH follows/does not follow the specific AMH.

This field is used to indicate that an AMH follows the considered AMH. Therefore at least another message is contained in the payload.


Length (bits) 1

Code Values 0 – No more AMHs follow

1 – At least one AMH follows


The “More AMHs Flag” shall be used as an indicator of the encapsulation of multiple AMs within the MAMES Payload (mandatory).

ETSI

Task 1.429

6.3 MAMES Payload DefinitionWith the exception of Ultra-short MAMES ALERT Message, the MAMES Payload may contain one or more Alert Messages, which can be represented by:

- Alert Messages formatted according to MAMES known Alert Protocols.

- Alert Messages formatted according to MAMES unknown Alert Protocols.

- Plain text or EMC (audio, images, videos,...).

Based on the defined MAMES Frame Structure the type of the Alert Message contained in the payload is specified by the “Alert Message Type” field of the AMH of the considered Alert Message.

Table 21 reports a list of the MAMES supported Alert Protocol/type of data. In particular the first column provides the Alert Message Types (decimal values) to be used in the corresponding AMH field.

Table 21: List of supported MAMES Alert Message Types

Alert Message Type

[decimal value]

MAMES Alert Message Type

(Alert Protocol name / type of data)Comment

1 CAP

It includes:

all CAP defined versions

CAP-XML, CAP-JSON, CAP-ASN.1 encoded CAP versions

all the defined CAP message types (Alert, Update, Ack, Cancel, Error).

Since CAP can also transport audio, video, text and URI when the MAMES Alert Message Type is CAP, it means that the Alert Message may include different type of data.

2 POCSAGIt includes both message coding formats defined for the information content part of messages: numeric messages and alphanumeric messages.

3 A4A protocol A4A protocol efficiently re-encodes CAP messages taking as a reference ASN.1 specification of CAP and introducing additional optional functions with respect to native CAP capabilities.

range of values mapped on the Internet Media Type/subtype

(4 ≤ type ≤1482)

Internet Media Type/subtype list audio, video, text, URI are included in this list [i.12].

2027≤ type ≤2047 Reserved for experimental usage These values are reserved for experimental usage

0 Bulk (undefined)It is used in case no information regarding the AM type is given.

The MAMES Receiver tries to process the AM according to its capabilities.

NOTE: All other values are reserved for future extensions.

Some considerations taking into account in the definition of supported MAMES Alert Message Types follow:

Only one type of MAMES Alert Message types is considered for CAP and it includes all the defined versions, coding schemes and CAP messages types.

ETSI

Task 1.430

It is assumed that: a CAP-capable Alerting Device is able to understand/interpret all CAP versions/coding schemes or to discard the Alert Message (AM) based on the information achieved by reading/processing the Alert Message first lines (e.g. not recognized-> discard the AM, recognized-> interpret and render the AM). This is all done at Alert Protocol level (not at MAMES level). In detail: the MAMES User Side Agent processes all the MAMES Headers, including the Alert Message Header (AMH), decapsulates the MAMES Message and passes the AM contained in the Payload to the Alert Protocol layer. It is responsibility of the Alert Protocol layer to understand if the AM can or cannot be interpreted and rendered by the upper layers.

The MAMES User Side Agent processes all the MAMES Headers, including the Alert Message Header (AMH), decapsulates the MAMES Message and forwards the AM(s) contained in the Payload to the Alert Protocol layer. It is responsibility of the Alert Protocol layer to interpret or discard the received AM(s) based on the capabilities of the Alerting Device. E.g.: a CAP-Capable Alerting Device may be able to understand/interpret all CAP versions/coding schemes, in this case every AM (CAP formatted) is interpreted and forwarded to the upper layer for rendering purposes; on the contrary if a CAP-Capable Alerting Device is not able to interpret all CAP versions/coding schemes and by reading/ processing the AM first lines it recognized that (as an example) it does not support the CAP version of the AM, it discards the received AM. It is worth mentioning that a Mediation Function can be used to fix this problem: its purpose is to translate one Alert Protocol (e.g. CAPv1.2) into another one (e.g. CAPv1.1).

Compression schemes as gzip [i.11] is included in the Internet Media Types list [i.12].

The payloads will be carried with MSB first.

ETSI

Task 1.431

7 MAMES Ultra-short ALERT Message

7.1 Rationale and preliminary notes on use cases The ultra-short MAMES Message is defined with the aim to achieve one of the MAMES objectives: alert message transport over narrowband satellite systems (MAMES over GNSS). Since the ultra-short MAMES Message consists of only the MAMES Header, the MAMES Header design is carried out taken into account the need of avoiding fragmentation, which could affect the delivery delay of some Alert Messages.

In detail, in case the transmission of Ultra-short MAMES ALERT Message is required (e.g. for lack of network resources), the MAMES Alerter Side Agent would be allowed to discard the MAMES Extension Headers, the Alert Message Headers and the MAMES Payload and only transmit the MAMES Mandatory Header, which contains some essential alert parameters extracted from the discarded MAMES payload.

Truncating/modifying the original Alert is a critical issue, to be coordinated between Alert Issuer and MAMES Alert Provider, but MAMES is just providing the technical tool. The alternative (in the MAMES domain) would be to discard the entire Alert Message, and not send anything over the narrowband channel.

Therefore the MAMES Ultra-short ALERT can be seen as an extreme solution (used in exceptional cases). Very few information (among them: notification area, event category, priority, alert issuer) are carried. It can be seen as a flag that makes people: eg. switch on the TV to get more information regarding the event; or that makes a siren emit a particular sound based on the event category.

It is worth highlighting that the Ultra-Short ALERT Frame should not contain any Extension Headers. The rationale follows: (i) it has to be as short as possible, and (ii) it should normally be submitted as fast as possible. If Extension Headers are needed (e.g. for security issues), the MAMES ALERT type without a payload is used.

An additional use case of the MAMES Ultra-short ALERT can be represented by the “out-of-band signaling”. The MAMES Ultra-short ALERT is transmitted to a parallel low bit-rate channel if there is not enough capacity to send the real MAMES ALERT message.

The possibility to make explicit backward/forward reference to a “longer” MAMES Message (MAME ALERT) from an Ultra-short one has been analysed.

Two examples of “backward/forward reference” cases are briefly described in Table 22, highlighting the main constraints. While Table 23 reports a detail analysis on the advantages and disadvantages of the adoption of a reference indicator in the Ultra-short MAMES ALERT. This analysis has been carried out focusing on the “out of band” case and highlights that a reference in the Ultra-Short ALERT, besides an increase of the MAMES protocol complexity from the implementation point of view, is not so beneficial in terms of efficiency of the alert itself (it may confuse the alerted users).

Table 22: BACKWARD/ FORWARD reference Cases

CASE BACKWARD reference FORWARD reference

Description

The MAMES Alert Provider has already sent a MAMES ALERT, but a temporary lack of network resources does not allow the transmission of this MAMES ALERT Message. To cope with the limited network resources the MAMES Alert Provider generates the corresponding Ultra-Short MAMES Message and keeps on delivering the alert in the same channel or in a low bitrate parallel channel.

The MAMES Alert Provider is not able to send MAMES ALERT Messages due to a temporary lack of network resources. Therefore it generates an Ultra-Short MAMES Message to deliver the alert in the channel or in a low bitrate parallel channel. As the network resources become again available the MAMES Alert Provider decides to transmit the long version of the alert corresponding to the ultra-short ones (MAMES ALERT Message).

Constraints Definition of an additional header field for backward reference

Definition of an additional header field for forward reference.

The MAMES Alert Provider shall reserve the next Message ID for the MAMES ALERT Message (long version).

ETSI

Task 1.432

Table 23: Tradeoff for a Reference Indicator (out-of-band) within the MAMES Ultra-Short ALERT

Advantages Drawbacks/Problems Balance -/0/+ (negative/neutral/positive)

With the Reference in the Ultra-Short ALERT, the MAMES Receiver would know that there is (or will be) another, full MAMES ALERT Frame on a higher-capacity channel.

What should the MAMES Receiver do with this information?

The best course of action for the MAMES Receiver will depend a lot on the actual situation (criticality, capabilities of the Alerting Device, expected delay of the full information, etc.). An algorithm needs to be developed that covers all possible situations optimally.

0

The Alert User will either (i) be alerted immediately anyway, or (ii) be alerted immediately and told that “more is on the way”, or (iii) delay the pre-alert until the full information arrives.

Ad (i) – no change for basic Alerting Devices, e.g. a siren.

Ad (ii) – is a potential benefit (but: When and where will the full information arrive?).

Ad (iii) – not recommended

Overall, there are hardly any real benefits for the Alert User.

Some Alert Users may get confused about the “pre-alert” and don’t know where to wait or how to access the delayed “full information.”

Alert Users will normally just turn on the radio (or other media) – in effect obviating the need for the reference to a future ALERT.

0

The Ultra-Short ALERT is designed exactly for those cases where no higher-capacity channel available at all (e.g., SatNav-only situations)!

There is no need to send an Ultra-Short ALERT when a full ALERT is possible!

-

The Reference in the Ultra-Short ALERT would be the “MAMES Reference” parameter (= MAMES Message ID of another MAMES Frame).

This complicates the implementation, since a “link” between different ALERT type frames at difference times is created. E.g., the MAMES Message ID of the future MAMES Frame must be defined/reserved in advance.

Does an UPDATE or CANCEL of one MAMES Frame imply that the “linked” frame will/must also be updated/cancelled?

-

Even without this explicit “pointer” to another MAMES Frame, reception of an Ultra-Short ALERT can (and should) be interpreted as an “implicit pointer/indication” that the Alert User should try to access other media, e.g. turn on the radio. The Alerting Device should in any case display/announce a correcponding instruction to the Alert Users.

This is in effect an implicit out-of-band information “for free”.

-

Therefore the Ultra-Short MAMES Message does not consider backward/forward reference. It is just an extreme solution and the MAMES Alert Provider will decide (based on the available network resources) if the creation and issue of an ultra-short ALERT is needed.

ETSI

Task 1.433

7.2 MAMES Ultra-short ALERT: Structure and Header DefinitionThe structure of an Ultra-short MAMES ALERT Message consists of only a Header, the Ultra-short ALERT Mandatory Header (Us-ALERT MH), whose fields are listed and briefly described in Table 24.

Table 24: Fields List of the Ultra-short MAMES ALERT Mandatory Header (Us-ALERT MH)

Field #

Length (bits) Field Brief Description

1 4 MAMES Protocol Version (see Section 6.2.1.1 )

2 3 MAMES Message Type It indicates the type of the MAMES Message: Ultra-short MAMES ALERT (see Section 6.2.1.2)

3 10 MAMES Message ID (see Section 6.2.1.3)

4 10 MAMES Alert Provider ID (see Section 6.2.1.4 )

5 45 Notification Area (see Section 6.2.1.5 )6 3 MAMES Priority (see Section 6.2.1.6)

7 12 Alert Issuer ID (see Section 6.2.1.8 )

8 4 MAMES Event Category (see Section 6.2.1.9)

Figure 7 depict an example of Ultra-short MAMES ALERT.

MAMES Protocol VersionMAMES Message TypeMAMES Message ID

MAMES Alert Provider IDNotification AreaMAMES PriorityAlert Issuer ID

MAMES Event Category

Us-

ALER

T M

H

Figure 7: Ultra-short MAMES ALERT Message

ETSI

Task 1.434

8 MAMES UPDATE Message

8.1 Rationale and preliminary notes on use cases MAMES UPDATE is not a new alert message, but just an update of a previously transmitted MAMES Message. Differently from the other special message types, it may include a payload. A MAMES UPDATE overwrites the Headers/Payload of the original MAMES ALERT Frame, and leaves Headers/Payload that are not included unchanged.

In detail, a MAMES UPDATE Message shall be used in case an update of a previous sent MAMES Message is needed within the validity time1 of the MAMES Message.

In the following an overview of a MAMES UPDATE Message usage is provided, while a detailed list of assumptions/considerations taken into account for the definition of this message is reported in Table 25.

A MAMES UPDATE could be:

1. an update of the MAMES priority field;

2. an update of one or more EHs of the MAMES Message;

3. an update of the information carried by the encapsulated Alert Messages (whether they are not formatted to any Alert Protocols or they are formatted according to an Alert Protocol that does include the use of the “update” message type);

4. an update of a combination of the previous options.

In the third case, taking into account the assumptions reported in table 25, the information update may be handled in two different ways, depending on the entity of the update:

Issue of a MAMES UPDATE not including a payload. This option is recommended in case the information reported in the MAMES UPDATE MH and EHs field are enough for the required update.

Issue of a MAMES UPDATE including a payload.

Moreover an update of an Ultra short MAMES Message shall be represented by a MAMES UPDATE, including only the MAMES UPDATE MH.

It is worth highlighting that a MAMES UPDATE shall be characterized by the same “Notification Area” Header field reported in the MAMES Message it refers to. This assumption implies that, in case of an update of the Notification Area, the MAMES Alert Provider shall:

issue a MAMES CANCEL message referring to the MAMES Message to be updated; this makes the MAMES User-Side Agent to discard the MAMES Message the MAMES CANCEL refers to and notify the MAMES message invalidation to the users;

issue a new MAMES message with a new Notification Area field code value.

8.2 General Assumptions/Considerations for MAMES UPDATE DefinitionThe assumptions/considerations taken into account for the definition of the MAMES UPDATE message are listed in Table 25.

Table 25: Assumptions/Considerations for MAMES UPDATE Definition

No.# Assumption/Consideration Proposed Solution/Recommendation

1 The time validity of a MAMES Message is specified by the “Alert Validity” EH, if present. Otherwise it is assumed that after 1 day the message expires. Therefore if neither a MAMES CANCEL or UPDATE is sent, the Alerting Device or Alert Intermediary System discards the MAMES Message and notifies the users the MAMES message expiration. These are preliminary considerations that might be changed as use cases are identified (TS/TR).

ETSI

Task 1.435

u-0A MAMES UPDATE is an update at MAMES level.

A MAMES UPDATE is an update at MAMES level and it shall be used in the following cases:

an update of the priority (“MAMES Priority” field of the MH) of a MAMES Message is required;

an update of an EH (e.g.: MAMES Validity Start/End) of an earlier MAMES Message is required;

an update of at least an Alert Message (encapsulated in a previously sent MAMES Message).

NOTE 1: Alert Protocol level updates (e.g. CAP Update message type) are sent encapsulated in MAMES UPDATE Messages. Therefore MAMES UPDATE also refers to the encapsulated message (if any).

u-1

A MAMES UPDATE is not a new alert message, but just an update of a valid (not expired) previously transmitted MAMES Message. It supersedes the previously transmitted MAMES Message.

Starting from this concept:

“One MAMES Message => One Event => One Notification Area => One event category => One Alert Issuer => One time alert issued” (from: assumption #g-3 in Table 2)

a MAMES UPDATE of a previously sent MAMES Message (“ALERT” type) shall be sent if the Notification Area does not need to be changed. Otherwise a new MAMES Message (“ALERT” type) shall be transmitted.

u-2

Multiple consecutive MAMES UPDATE messages of the same MAMES Message can be transmitted (if needed).

Each MAMES UPDATE supersedes a previously transmitted MAMES UPDATE of the same MAMES Message.

In order to identify a MAMES UPDATE, the following information shall be included in the mandatory fields of the MAMES UPDATE Header:

the MAMES Message ID

the MAMES Alert Provider ID;

the ID of the MAMES Message the MAMES UPDATE refers to (it is called “ MAMES Reference” and it is a mandatory field of the MAMES UPDATE Header).

The combination of these fields allows the MAMES User-Side agent to properly process the received MAMES UPDATE messages and act accordingly.

NOTE: The MAMES Message ID is also an indication of the latest MAMES UPDATE transmitted.

u-3A MAMES UPDATE may include a field denoting the type of action recommended.

An optional field, called “MAMES Response Type”, which denotes the type of action recommended (see <response type > CAP element) is defined (Task 1.5 document).

This field shall be used in case an update of the information carried by the AM is needed and the MAMES UPDATE is characterized by an empty payload.

See also assumption # u-4

u-4 A MAMES UPDATE may or may not include a payload.

A MAMES UPDATE should NOT include a payload in the following cases:

an update of the priority (“MAMES Priority” field of the MH) of a MAMES Message is required;

an update of an EH (e.g.: MAMES Validity Start/End) of an earlier MAMES Message is required;

If an update of the content of an Alert Message is required the MAMES UPDATE may or may not include a payload:

If it does NOT include a payload the “MAMES Response Type” shall be included to provide the MAMES UPDATE information.

If it includes a payload and, consequently, the AMHs, (one for each encapsulated Alert Messages), each Alert Message shall be an updated version of the one transmitted in the previous sent MAMES Message the MAMES UPDATE refers to.

ETSI

Task 1.436

NOTE 1: If an update of a MAMES Message that contains multiple Alert Messages, some formatted according to Alert Protocols that include the use of the “update” message type and some that do not, is needed, the MAMES UPDATE Payload will be represented by: the “update” type of the Alert Messages (for those messages that are formatted according to Alert Protocols that include the use of the “update” message type ) and by updated Alert Messages (for those messages that do not support the “update” message type)

8.3 MAMES UPDATE: Structure and Header DefinitionA MAMES UPDATE consists of:

a Header, which includes:

UPDATE Mandatory Header (UPDATE MH), which contains all the mandatory fields of the Header;

EHs, which (if present) are represented by some of the EHs defined in Task 1.5 document.

Alert Message Headers (AMHs), which refer to the Alert Messages contained in the payload (see section 6.2.3 for further details)

a Payload, which comprises the updated versions of the Alert Messages contained in the MAMES Message the MAMES UPDATE refers to (see the assumption # u-4 of table 25).

The mandatory header fields of a MAMES UPDATE are listed and briefly described in Table 26 .

While details of those mandatory fields that have not been already described are reported in the following subsections, the EHs are detailed in the Task 1.5 document.

Table 26: List of the MAMES UPDATE Mandatory Header (UPDATE MH)

Field #


1 4 MAMES Protocol Version (see Section 6.2.1.1).

2 3 MAMES Message Type It indicates the type of the MAMES Message: MAMES UPDATE. (see Section 6.2.1.2)

3 10 MAMES Message ID (see Section 6.2.1.3).

4 10 MAMES Alert Provider ID (see Section 6.2.1.4).

5 45 Notification Area (see Section 6.2.1.5).

6 3 MAMES Priority

(see Section 6.2.1.6).

The code value of this field may or may not be updated with respect to the corresponding one of the MAMES Message the update refers to.

7 10 MAMES Reference

It specifies the “MAMES Message ID” of a previous transmitted MAMES Message, which needs to be referenced.

In this case it identifies the MAMES message, the MAMES UPDATE refers to.

8 1 ACK Request Flag (see Section 6.2.1.7).

9 12 Alert Issuer ID (see Section 6.2.1.8).

10 4 MAMES Event Category (see Section 6.2.1.9).

11 4 Next Header Type (see Section 6.2.1.10).

It identifies one of the EH allowed for a MAMES UPDATE

ETSI

Task 1.437

message or AMH type or that “no more headers” follow.

ETSI

Task 1.438

A MAMES UPDATE Message example is depicted in Figure 8. The darker colored UPDATE MH fields are the ones whose values are the same of the values indicating in the MAMES Frame to be updated.


MAMES Alert Provider IDNotification AreaMAMES Priority

MAMES ReferenceACK Request Flag

Alert Issuer IDMAMES Event Category

Next Header Type

Updated Extension Headers

Alert Message Headers (for updated Alert Messages)

Corresponding updated Alert Messages

UPD

ATE

MH

EHs

AMHs

P

Figure 8: MAMES UPDATE Message

8.3.1 MAMES ReferenceTable 27: “MAMES Reference” UPDATE/CANCEL/ACK Mandatory Header Field

Proposed Header Field Name MAMES Reference

Belongs to Header Group UPDATE/CANCEL/ACK Mandatory Header

Reference CAP < reference>


Description/ Rationale It specifies the “MAMES Message ID” of an earlier MAMES Message, which needs to be referenced.

This field is mandatory for MAMES ACK, CANCEL, UPDATE messages. In detail it indicates the “MAMES Message ID” of the MAMES message,

a MAMES ACK shall acknowledge;

ETSI

Task 1.439

a MAMES UPDATE shall update.

a MAMES CANCEL shall “mark as invalid”


Length (bits) 10

Code Values (see MAMES Message ID definition – section 6.2.1.3)

Conclusion/ Recommendation/ Notes The MAMES Reference shall be used in the MAMES UPDATE/CANCEL/ACK Frame (mandatory).

ETSI

Task 1.440

9 MAMES CANCEL Message

9.1 Rationale and preliminary notes on use cases A MAMES CANCEL Message declares a previous MAMES Message as obsolete: this does not necessarily mean that the incident described in the previous MAMES Message will not occur. MAMES CANCEL Messages may be used, e.g., to withdraw a previous MAMES Message that has been transmitted erroneously or to the wrong notification area.

MAMES CANCEL is useful to handle the expiration of an alert message within MAMES validity time 1, whether the encapsulated Alert Messages (of the MAMES ALERT) are formatted according to Alert Protocols that do or do not support the “cancel” messages types.

Two different cases can be considered:

1. the MAMES ALERT Message does NOT include the “Validity Header” (EH);

2. the MAMES ALERT Message includes the “Validity Header” (EH).

While in the former case a MAMES CANCEL Message shall be sent by the MAMES Alert Provider to withdraw a previous MAMES Message, in the latter case the MAMES validity check is allowed on the MAMES user side (MAMES User Side Agent) for rendering purposes in case of Direct Alert or for relaying purposes in case of In-direct Alert.

Processing the “Validity Header”, the MAMES User Side Agent knows if the MAMES Message has expired or not and act accordingly. In detail, the actual time (t), the “MAMES Validity Start” (t s) and “MAMES Validity End”(te) parameters (included in the “Validity Header”), are used:

if ts ≤ t ≤ te the MAMES User-Side Agent decapsulates the MAMES Message and sends the Alert Message to the upper protocol layers entities for rendering purposes (Direct-Alert case) or process the Alert Message according to the technology of the Alert Intermediary System (In-direct Alert case).

if t < ts or t > te :

the MAMES User-Side Agent of the Alerting Device discards the MAMES Message and notifies the user that the MAMES Message validity has expired (Direct Alert)

the MAMES User-Side Agent of the Alert Intermediary System discards the MAMES Message and notifies the users that the MAMES Message validity has expired (Indirect Alert)

Therefore in the latter case is up to the MAMES Alert Provider to transmit or not a MAMES CANCEL message.

It is worth noticing that if an Alert Protocol level cancel message type needs to be transmitted, it will be encapsulated in a MAMES CANCEL Message. Therefore the MAMES CANCEL Message may include a Payload containing the Alert Protocol level cancel nessages.

9.2 MAMES CANCEL: Structure and Header DefinitionA MAMES CANCEL consists of:


CANCEL Mandatory Header (CANCEL MH), which contains all the mandatory fields of the Header;


Alert Message Headers (AMHs), which refer to the Alert Messages contained in the payload (see section 6.2.3 for further details)

1 see footnote 7.

ETSI

Task 1.441

a Payload, which (if present) comprises the Alert Protocol cancel messages type of the Alert Messages contained in the MAMES ALERT Message the MAMES CANCEL refers to.

The mandatory header fields of a MAMES CANCEL are listed and briefly described in Table 28.

Table 28: Fields List of the MAMES CANCEL Mandatory Header (CANCEL MH)

Field #



2 3 MAMES Message Type It indicates the type of the MAMES Message: MAMES CANCEL (see Section 6.2.1.2).

3 10 MAMES Message ID (see Section 6.2.1.3).

4 10 MAMES Alert Provider ID(see Section 6.2.1.4).

It represents the destination of the MAMES ACK.

5 45 Notification Area (see Section 6.2.1.5).

6 3 MAMES Priority(see Section 6.2.1.6).

The priority value shall be inherited by the MAMES Message to be cancelled (or mark as “not valid”).

7 10 MAMES Reference(see Section 8.3.1).

It identifies the MAMES message, the MAMES CANCEL refers to.

8 1 ACK Request Flag (see Section 6.2.1.7).

9 4 Next Header Type(see Section 6.2.1.10).

It identifies one of the EH allowed for a MAMES CAMCEL message or AMH type or that “no more headers” follow.

Figure 9 depicts an example of MAMES CANCEL. The darker colored CANCEL MH fields are the ones whose values are the same of the values indicating in the MAMES Frame to be cancelled.

ETSI

Task 1.442


MAMES Alert Provider IDNotification AreaMAMES Priority

MAMES ReferenceACK Request FlagNext Header Type

Extension Headers as required

Alert Message Header(s) for Cancellation Message(s)

Corresponding Cancellation Message(s)

P

CAN

CEL

MH

EHs

AMHs

Figure 9: MAMES CANCEL Message

ETSI

Task 1.443

10 MAMES ACK Message

10.1 Rationale and preliminary notes on use cases The MAMES ACK message is defined with the aim to provide (as an optional feature) acknowledgement at MAMES level and enabling the encapsulation of Alert Protocol level acknowledgements.

The MAMES ACK message is sent by the User-Side Agent back to the Alerter-Side Agent in case the Alerter-Side Agent asks for acknowledgement. This requires:

the definition of an EH that the Alerter-Side Agent uses to ask for acknowledgement; this EH (“MAMES ACK Request”) shall be set in the transmitted MAMES Message in case acknowledgement is required (see Task 1.5);

the definition of the MAMES ACK Message that acknowledges a previously received MAMES Message (ALERT or UPDATE, or CANCEL message);

A MAMES Message that includes the “MAMES ACK Request” EH properly set shall be acknowledged. In particular, in case of a bidirectional satellite network, a MAMES ACK can be sent by the MAMES User Side Agent back to the MAMES Alert Provider.

Since MAMES ACK Messages can be also be used to encapsulate Alert Protocol level acknowledgements, the frame structure of a MAMES ACK may include a Payload. In detail:

the MAMES ACK is characterized by an empty payload (and consequently absence of AMHs) if it is a “pure” MAMES ACK;

the MAMES ACK includes a payload (and consequently the pertaining AMHs) if it is a MAMES ACK that encapsulates Alert Protocol level acknowledgements;

It is worth highlighting that:

A MAMES Message (ALERT/UPDATE/CANCEL) can be acknowledged once.

If the receiver sends a MAMES ACK, when and how is an implementation issue.

the MAMES Alert Provider may receive MAMES ACKs that it did not request. If this happens, it knows that the ACK was requested/caused at Alert Protocol level. This is also testified by the presence of a payload in the MAMES ACK that signals that the Alert Issuer wants an acknowledgement (which is encapsulated the payload).

10.2 MAMES ACK: Structure and Header DefinitionThis subsection aims at defining the structure of a MAMES ACK. A MAMES ACK consists of:


ACK Mandatory Header (ACK MH), which contains all the mandatory fields of the Header;


Alert Message Headers (AMHs), which refer to the Alert Messages contained in the payload, if any.

a Payload, which comprises the Alert Protocol acknowledgement messages type (if any) of the Alert Messages contained in the MAMES ALERT Message the MAMES ACK refers to.

The mandatory header fields of a MAMES ACK are listed and briefly described in Table 29.

While details of those mandatory fields that have not been already described are reported in the following subsections, the optional fields are detailed in the Task 1.5 document, where for each EH a list of the MAMES Message types that may include that particular EH is provided.

ETSI

Task 1.444

Table 29: Fields List of the MAMES ACK Mandatory Header (ACK MH)

Field #



2

3

MAMES Message Type (see Section 6.2.1.2)

It indicates the type of the MAMES Message: MAMES ACK.

3 10 MAMES Reference (see Section 8.3.1).

It identifies the MAMES message, the MAMES ACK refers to.

4 10 MAMES Alert Provider ID (see Section 6.2.1.4).

5 41 MAMES User Location It indicates the geographical position of the sender of the MAMES ACK.

6 3 MAMES Priority(see Section 6.2.1.6).

The priority value may be inherited by the MAMES Message to be acknowledged.

7 10 Alert Issuer ID

(see Section 6.2.1.8).

In case of Alert Protocol level acknowledgemnets encapsulation it makes the MAMES Alert Provider knows where to send the acknowledgement message to.

8 13 MAMES Receiver ID Identifier of the sender of the MAMES ACK.

9 8 Next Header Type (see Section 6.2.1.10).

It identifies one of the EH allowed for a MAMES ACK message or AMH type or that “no more headers” follow.

It is worth highlighting that the MAMES ACK MH does not include the “MAMES Message ID”. In fact the “MAMES Message ID” uniquely identifies the MAMES Frame transmitted by a MAMES Alert Provider. Since the MAMES ACK is transmitted by the MAMES Receiver, the MAMES Message ID is omitted.

Figure 10 depicts an example of MAMES ACK.. The darker colored ACK MH fields are the ones whose values are the same of the values reported in the MAMES Frame to be acknowledged.

ETSI

Task 1.445

MAMES Protocol VersionMAMES Message Type

MAMES ReferenceMAMES Alert Provider IDMAMES Receiver Location

MAMES PriorityAlert Issuer ID

MAMES Receiver IDNext Header Type

Authentic./Integrity Header

Encryption Header

Alert Message Header(s) for Acknowledgement

Message(s)

Corresponding Acknowledgement

Message(s)

ACK

MH

EHs

AMHs

P

Figure 10: MAMES ACK Message

10.2.1 MAMES Receiver Location Table 30: “MAMES Receiver Location” ACK Mandatory Header Field

Proposed Header Name MAMES Receiver Location

Belongs to Header Group ACK Mandatory Header

Reference WGS84 (World Geodetic System 1984)

Description/Rationale

The MAMES Receiver Location Field is used by the MAMES Receiver to indicate, inside a MAMES ACK Frame, its geographical position.

This enables the MAMES Alert Provider to identify the location where the alert has been successfully received.


Length (bits) 41

ETSI

Task 1.446

Code Values All latitude/longitude values as follows:

0°0’0” < Latitude < +/-89°59’59”

0°0’0” < Longitude < +/-179°59’59”

This covers the entire surface of the earth with an accuracy of 1 sec. (lat./long.), i.e., a few tens of meters.

For details see Annex A.5

A code value for “unspecified” location is defined. It is obtained by setting to “1” all the 41 bits of the MAMES Receiver Location Field (decimal value =2199023255551).

Conclusion/ Recommendation

The MAMES Receiver Location shall be used in the MAMES ACK Frame (mandatory).

Although a code value for “unspecified” is defined, in “normal operation” it is recommended to specify the MAMES Receiver Location.

10.2.2 MAMES Receiver ID

Table 31 “MAMES Receiver ID” ACK Mandatory Header Field

Proposed Header Field Name MAMES Receiver ID

Belongs to Header Group ACK Mandatory Header

Reference. -

Requirement REQ-user-fctl-008


Identifier of the sender of the MAMES ACK.

It identifies the entity hosting the MAMES User-Side Agent (Alert Intermediary System or Alerting Device) that sends the MAMES ACK.

Since not all MAMES Receivers may have a MAME Receiver ID assigned, a code value for “unspecified” is defined. Assigning & managing MAMES Receiver IDs is an administrative task of the MAMES Alert Provider.


Length (bits) 13

Code Values 0000000000000 - Unspecified

0000000000001 - MAMES User 1

0000000000010 - MAMES User 2

......


The MAMES Receiver ID shall be used in the MAMES ACK Frame (mandatory).

Although a code value for “unspecified” is defined, in “normal operation” it is recommended to specify the MAMES Receiver ID.

ETSI

Task 1.447

11 Traceability Matrix: Requirements - MAMES FrameIn this section a traceability matrix, which maps the defined MAMES functional requirements with the defined MAMES Frame fields will be provided.

It is worth highlighting that those requirements that are not mapped on a specific MAMES Header Field are some of the Alerter-side and User-Side Agent functional requirements whose objectives are more implementation oriented.

Table 32: Traceability Matrix: Requirements - MAMES Frame

Requirement MAMES Field/Group of MAMES Headers

REQ-gen-fctl-001 Alert Message Type





REQ-gen-fctl-006 Next Header Type

REQ-gen-fctl-007 Next Header Type

REQ-gen-fctl-008 MAMES Priority

REQ-gen-fctl-009 Next Header Type , EHs

REQ-gen-fctl-010 Next Header Type , EHs

REQ-gen-fctl-011MAMES Alert Provider ID

Authentication/Integrity EH

REQ-gen-fctl-012 Authentication/Integrity EH

REQ-gen-fctl-013 Encryption EH, Alert Scope Header

REQ-gen-fctl-014 MAMES Message Type


REQ-gen-fctl-016 MAMES Reference, MAMES Message Type


REQ-alerter-fctl-001 -



REQ-alerter-fctl-004 AMH, MAMES Message Type


REQ-alerter-fctl-006 Authentication/Integrity EH, Encryption EH,


REQ-alerter-fctl-008 ACK Request Flag


REQ-user-fctl-001 -

REQ-user-fctl-002 Notification Area, Administrative Area EH

REQ-user-fctl-003 -

REQ-user-fctl-004 -

REQ-user-fctl-005 -

ETSI

Task 1.448

REQ-user-fctl-006 -

REQ-user-fctl-007 MAMES Message Type, MAMES Receiver ID, MAMES Receiver Location

REQ-user-fctl-008 -

ETSI

Task 1.449

Annex A:Detailed Definition of MAMES Header FieldsThis Annex aims at providing details on some of the defined code values used for in the MAMES Mandatory Header fields.

A.1 <Notification Area>: Radius indexThe following figure reports the code value of the 16 indexes used for the <Notification Area> radius definition.

radiusindex=code value log(radius [km]) radius [km] rounded km-values meaning:

0 radius unspecified1 0 1,00 1 radius up to . km2 0,25 1,78 2 radius up to . km3 0,5 3,16 3 radius up to . km4 0,75 5,62 6 radius up to . km5 1 10,00 10 radius up to . km6 1,25 17,78 20 radius up to . km7 1,5 31,62 30 radius up to . km8 1,75 56,23 60 radius up to . km9 2 100,00 100 radius up to . km10 2,25 177,83 200 radius up to . km11 2,5 316,23 300 radius up to . km12 2,75 562,34 600 radius up to . km13 3 1000,00 1000 radius up to . km14 3,25 1778,28 2000 radius up to . km15 2000 radius greater than . Km

Note: a circle of radius 2000 km covers: Portugal-Finland; Scotland-Turkey(center of circle: Vienna)

Figure 11: Radius Index Definition

ETSI

Task 1.450

A.2 <MAMES Priority>: Map on CAP <urgency>The following table reports a map between the CAP <urgency> element of the CAP <info> segment and the <MAMES Priority> code values.

Table 33: <MAMES Priority> - CAP <urgency> Map

<MAMES Priority> MAMES Priority Levels CAP <urgency> CAP Values Description

1111 Very High Immediate Responsive action SHOULD be taken immediately

0001 High Expected Responsive action SHOULD be taken soon (within next hour)

0010 Medium Future Responsive action SHOULD be taken in the near future

0011 Low Past Responsive action is no longer required

0000 Unknown Unknown Urgency unknown

A.3 < MAMES Event Category>: Map on CAP <category>

The following table reports a map between the CAP <category> element of the CAP <info> segment and the < MAMES Event Category> code values.

Table 34: < MAMES Event Category > - CAP < category > Map

<MAMES Event Category> CAP <category> Description

0001 Geo Geophysical (inc. landslide)

0010 Met Meteorological (inc. flood)

0011 Safety General emergency and public safety

0100 Security Law enforcement, military, homeland and local/private security

0101 Rescue Rescue and recovery

0111 Fire Fire suppression and rescue

1000 Health Medical and public health

1001 Env Pollution and other environmental

1010 Transport Public and private transportation

1011 Infra Utility, telecommunication, other non-transport infrastructure

1100 CBRNEChemical, Biological, Radiological, Nuclear or High-Yield

Explosive threat or attack

1101 Other Other events

00001 - -

1 This code is used for “unspecified” event category. It is not mapped with a CAP <caytegory> element. It is an additional category defined for MAMES to cope with the encapsulation of those messages (no CAP) that do not include information regarding the event category.

ETSI

Task 1.451

A.4 <Language ID>: Map on ISO 639-1 CodesThe following figure reports a map between the ISO 639-1 code values and the MAMES code values (in decimal). The <Language ID> field length is 8 bits.

Table 35: < MAMES Language ID > - ISO 639-1 Codes Map

MAMES Language ID allowed values (decimal)

ISO 639-1 Code English name of Language

1 aa Afar2 ab Abkhazian3 af Afrikaans4 ak Akan5 sq Albanian6 am Amharic7 ar Arabic8 an Aragonese9 hy Armenian10 as Assamese11 av Avaric12 ae Avestan13 ay Aymara14 az Azerbaijani15 ba Bashkir16 bm Bambara17 eu Basque18 be Belarusian19 bn Bengali20 bh Bihari languages21 bi Bislama22 bo Tibetan23 bs Bosnian24 br Breton25 bg Bulgarian26 my Burmese27 ca Catalan; Valencian28 cs Czech29 ch Chamorro30 ce Chechen31 zh Chinese

32 cu Church Slavic; Old Slavonic; Church Slavonic; Old Bulgarian; Old Church Slavonic

33 cv Chuvash34 kw Cornish35 co Corsican36 cr Cree37 cy Welsh38 cs Czech39 da Danish40 de German41 dv Divehi; Dhivehi; Maldivian42 nl Dutch; Flemish43 dz Dzongkha44 el Greek, Modern (1453-)45 en English46 eo Esperanto47 et Estonian48 eu Basque

ETSI

Task 1.452

49 ee Ewe50 fo Faroese51 fa Persian52 fj Fijian53 fi Finnish54 fr French55 fr French56 fy Western Frisian57 ff Fulah58 ka Georgian59 de German60 gd Gaelic; Scottish Gaelic61 ga Irish62 gl Galician63 gv Manx64 el Greek, Modern (1453-)65 gn Guarani66 gu Gujarati67 ht Haitian; Haitian Creole68 ha Hausa69 he Hebrew70 hz Herero71 hi Hindi72 ho Hiri Motu73 hr Croatian74 hu Hungarian75 hy Armenian76 ig Igbo77 is Icelandic78 io Ido79 ii Sichuan Yi; Nuosu80 iu Inuktitut81 ie Interlingue; Occidental

82 ia Interlingua (International Auxiliary Language Association)83 id Indonesian84 ik Inupiaq85 is Icelandic86 it Italian87 jv Javanese88 ja Japanese

89 kl Kalaallisut; Greenlandic90 kn Kannada91 ks Kashmiri92 ka Georgian93 kr Kanuri94 kk Kazakh95 km Central Khmer96 ki Kikuyu; Gikuyu97 rw Kinyarwanda98 ky Kirghiz; Kyrgyz99 kv Komi

100 kg Kongo101 ko Korean

102 kj Kuanyama; Kwanyama103 ku Kurdish104 lo Lao105 la Latin106 lv Latvian

ETSI

Task 1.453

107 li Limburgan; Limburger; Limburgish108 ln Lingala109 lt Lithuanian110 lb Luxembourgish; Letzeburgesch111 lu Luba-Katanga112 lg Ganda113 mk Macedonian114 mh Marshallese115 ml Malayalam116 mi Maori117 mr Marathi118 ms Malay119 mk Macedonian120 mg Malagasy121 mt Maltese122 mn Mongolian123 mi Maori124 ms Malay125 my Burmese126 na Nauru127 nv Navajo; Navaho128 nr Ndebele, South; South Ndebele

129 nd Ndebele, North; North Ndebele130 ng Ndonga131 ne Nepali132 nl Dutch; Flemish

133 nn Norwegian Nynorsk; Nynorsk, Norwegian

134 nb Bokmål, Norwegian; Norwegian Bokmål

135 no Norwegian

136 ny Chichewa; Chewa; Nyanja

137 oc Occitan (post 1500)138 oj Ojibwa139 or Oriya140 om Oromo141 os Ossetian; Ossetic142 pa Panjabi; Punjabi143 fa Persian144 pi Pali145 pl Polish146 pt Portuguese147 ps Pushto; Pashto148 qu Quechua149 rm Romansh150 ro Romanian; Moldavian; Moldovan151 rn Rundi152 ru Russian153 sg Sango154 sa Sanskrit155 si Sinhala; Sinhalese156 sk Slovak157 sk Slovak158 sl Slovenian159 se Northern Sami160 sm Samoan161 sn Shona162 sd Sindhi163 so Somali

ETSI

Task 1.454

164 st Sotho, Southern165 es Spanish; Castilian166 sq Albanian167 sc Sardinian168 sr Serbian169 ss Swati170 su Sundanese171 sw Swahili172 sv Swedish173 ty Tahitian174 ta Tamil175 tt Tatar176 te Telugu177 tg Tajik178 tl Tagalog179 th Thai180 bo Tibetan181 ti Tigrinya182 to Tonga (Tonga Islands)183 tn Tswana184 ts Tsonga185 tk Turkmen186 tr Turkish187 tw Twi188 ug Uighur; Uyghur189 uk Ukrainian190 ur Urdu191 uz Uzbek192 ve Venda193 vi Vietnamese194 vo Volapük195 cy Welsh196 wa Walloon197 wo Wolof198 xh Xhosa199 yi Yiddish200 yo Yoruba201 za Zhuang; Chuang202 zh Chinese203 zu Zulu

ETSI

Task 1.455

A.5 <MAMES User Location>The following table reports code value details and an example of the <MAMES User Location> Header field.

Figure 12: <MAMES User Location> Header field Details

ETSI

Task 1.456

Annex B (informative):Geographical Grid Systems AnalysisThis Annex aims at providing details on the analysis that has been carried out for the <Notification Area> MH field definition. In particular different geographical grid systems have been analysed and finally the World Geodetic System (WGS84) has been selected for the definition of the <Notification Area>. As reported in section, this seems to be a good trade-off between geo location information and required number of bits. Table 36 gives an overview of the different grid systems, highlighting their main features, accuracy and required number of bits.

ETSI

Task 1.457

Table 36: Geographical Grid Systems Analysis

GRID SYSTEMS

World Geodetic System (WGS84)Reference http://wiki.gis.com/wiki/index.php/WGS84Main Features Standard for use in cartography, geodesy, and navigation. Used also in CAP.Accuracy up to 1''Number of bits (for accuracy up to 1', 4'', max=1'') #bits (1'≈1.8Km) #bits (4''≈100m) #bits (max=1''≈30m)Code Latitude N/S: 0-1 1 1 1 Latitude Degrees: 0-89 7 7 7 Latitude Minutes: 0-59 6 6 6 Latitude 4 Seconds: 0-15 4 Latitude Seconds: 0-59 6 Longitude N/S: 0-1 1 1 1 Longitude Degrees: 0-179 8 8 8 Longitude Minutes: 0-59 6 6 6 Longitude 4 Seconds: 0-15 4 Longitude 1 Seconds: 0-59 6

Total # of bits 29 37 41

Universal Transverse Mercator (UTM)Reference http://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_systemMain Features 2-dimensional Cartesian coordinate system to give locations on the surface of the Earth; Limited to 84°N and 80°S lat.; Beyond UPS are

used;longitude 174 to 180 EastAccuracy up to 1mNumber of bits (for accuracy up to 1km, 100m, max=1m) #bits (1Km) #bits (100m) #bits (max=1m)Code 60 long. zones 6 6 6 N and S 1 1 1 600000 m (long.) 10 13 20

ETSI

Task 1.458

http://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system

http://wiki.gis.com/wiki/index.php/WGS84

10000000 m (lat.) 14 17 24Total # of bits 31 37 51

World Geographic Reference System (WGRS)

Reference http://en.wikipedia.org/wiki/GeorefMain Features

Based on lat/long, standard, but simplier and more concise notation; Run in one direction: east from 180° meridian, north from South Pole; Code: 4letter+4numbers; used for air navigation particularly in military or inter-service applications, but it is rarely seen today.

Accuracy up to 0,01'Number of bits (for accuracy up to 1', 0.1', max=0.01') #bits (1'≈1.8Km) #bits (0.1'≈180m) #bits (max=0.01'≈1,8m)Code 24 (lat) x 12 (long) = 288 zones (15°x15°) 9 9 9 15 (lat) x 15 (long) = 225 zones (1°x1°) 8 8 8 60x60= 360 (1'X1') 9 9 9 10x10=100 (0.1'X0.1') 7 100x100=10000 (0.01'X0.01') 14


Global Area Reference System (GARS)Reference http://en.wikipedia.org/wiki/Global_Area_Reference_SystemMain Features Area centric standardized geospatial reference system developed by NGA (National Geospatial Intelligence Agency) for use across US

Department of defenceAccuracy up to 5'Number of bits (for accuracy up to max=5') #bits (-) #bits (-) #bits (max=5'≈ 9 km)Code 360 (lat) x 720 (long) = 259200 zones (30'x30') 18 4 subdivision of each 30'x30' zone(15'x15') 2 9 subdivision of each 15'x15' zone(5'x5') 4


Military Grid Reference System (MGRS)Reference http://en.wikipedia.org/wiki/Military_grid_reference_systemMain Features Point Centric geocoordinate standard used by NATO militaries for locating points on the earth; derived from UTS and UTM

ETSI

Task 1.459

http://en.wikipedia.org/wiki/Military_grid_reference_system

http://en.wikipedia.org/wiki/Global_Area_Reference_System

http://en.wikipedia.org/wiki/Georef

Accuracy up to 1 m squareNumber of bits (for accuracy up to 1km, 100m, max=1m) #bits (1Km) #bits (100m) #bits (max=1m)Code 20(lat) x 60 (long) = 120 (8°x 6°) (in most cases) 7 7 7 48 zones (1°x1°) 6 6 6 10x10 =100 (10 km) 100x100=10000 (1 km) 14 1000x1000=1000000 (100 m) 20 10000x10000=100000000 (10 m) 100000x100000=10000000000 (1 m) 34


MAIDENHEAD LOCATORReference https://en.wikipedia.org/wiki/Maidenhead_Locator_SystemMain Features It is a geographic co-ordinate system used by amateur radio operators.Accuracy up to (2,5'x 5') common definitionNumber of bits (for accuracy up to max=2.5'x5') #bits (-) #bits (-) #bits (max= 2.5'x5'≈4.5x9Km)Code 18(lat) x 18 (long) = 324 (10°x 20°) 9 10(lat) x 10 (long) = 100 (1°x 2°) 7 24(lat) x 24 (long) = 576 (2,5'x 5') 10


Universal Polar Stereographic (UPS)Reference http://en.wikipedia.org/wiki/Universal_polar_stereographic_coordinate_systemMain Features

It is used in conjunction with the UTM coordinate system. It covers the Earth's polar regions (the areas north of 84°N and south of 80°S, which are not covered by the UTM grids) and an additional 30 minutes of latitude extending into UTM grid to provide some overlap between the two systems.

ETSI

Task 1.460

http://en.wikipedia.org/wiki/Universal_polar_stereographic_coordinate_system

https://en.wikipedia.org/wiki/Maidenhead_Locator_System

SKELETON - ETSI · Web viewSTF 473 . Task 1.4 . Working Document v1.0. MAMES Message Definition...

Documents

Transcript of SKELETON - ETSI · Web viewSTF 473 . Task 1.4 . Working Document v1.0. MAMES Message Definition...