SKELETON - ETSI · Web viewIn case of any existing or perceived difference in contents between such...

ETSI TS 1xx xxx V<m.t.e> (<yyyy-mm>)

< DTS/SES-00310MAMES;

[Part <n>: Part element of title;[Sub-part <m>: Sub-part element of title]]>

[<GSM/UMTS spec>]

[Part element for endorsement]

The TS (ETSI Technical Specification) is the preferred deliverable when the document contains normative provisions and short time to "market", validation and maintenance are essential.

A TS may later be converted to an ES or an EN, or be used to publish the contents of a draft ES being sent for vote or a draft EN being sent for Public Enquiry or vote.

The guidance text (green) shall be removed when no longer needed.

<

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

The present document can be downloaded from:http://www.etsi.org

The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any

existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (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 or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI.

The content of the PDF version shall not be modified without the written authorization of ETSI.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.

ETSI TS 1xx xxx V<m.t.e> (<yyyy-mm>)2[Part element for endorsement] or [Release #]

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 below the title on the right hand side of the cover page

Copyrights on page 2This paragraph should be used for deliverables processed before WG/TB approval and used in meetings.

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 additional 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


Contents (style TT)

If 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.To update the Table of Contents: F9.To lock it: select the Table of Contents and then click simultaneously: Ctrl + F11.

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

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

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

Intellectual Property Rights (style H1)........................................................................................................7

Foreword (style H1).....................................................................................................................................7Multi-part documents...................................................................................................................................................7

Modal verbs terminology (style H1)...........................................................................................................7

Executive summary (style H1)....................................................................................................................8

Introduction (style H1)................................................................................................................................8

1 Scope (style H1)................................................................................................................................8

2 References (style H1)........................................................................................................................92.1 Normative references (style H2).................................................................................................................92.2 Informative references (style H2)................................................................................................................9

3 Definitions, symbols and abbreviations (style H1).........................................................................103.1 Definitions (style H2)................................................................................................................................103.2 Symbols (style H2)....................................................................................................................................103.3 Abbreviations (style H2)...........................................................................................................................10

4 MAMES Objectives and Operation................................................................................................124.1 MAMES Objectives..................................................................................................................................124.2 Overview of MAMES Operation..............................................................................................................124.2.2 MAMES Operative Modes: Direct and Indirect MAMES Alerting...................................................124.2.3 The MAMES Agents...........................................................................................................................144.3.1.1 MAMES Alerter-Side Agent.........................................................................................................154.3.1.2 MAMES User-Side Agent.............................................................................................................15

5 MAMES Architecture.....................................................................................................................165.1 Functional Architecture.............................................................................................................................165.1.1 MAMES Functional Blocks Main Features........................................................................................185.1.1.1 MAMES Signalling Processing Block..........................................................................................185.1.1.2 MAMES Message Framing Block.................................................................................................195.1.1.3 MAMES Message De-Framing Block...........................................................................................205.1.1.4 MAMES Scheduling & Forwarding Block...................................................................................215.2 Protocol Architecture................................................................................................................................215.2.1 MAMES Direct Alerting.....................................................................................................................225.2.1.1 Protocol Architecture CASE A1....................................................................................................225.2.1.2 Protocol Architecture CASE A2....................................................................................................235.2.2 Indirect MAMES Alerting..................................................................................................................245.2.2.1 Protocol Architecture CASE B1....................................................................................................245.2.2.2 Protocol Architecture CASE B2....................................................................................................25

6 MAMES Messages.........................................................................................................................276.1 MAMES Message Types..........................................................................................................................286.1.1 MAMES ALERT.................................................................................................................................296.1.2 MAMES Ultra-Short ALERT.............................................................................................................296.1.3 MAMES UPDATE..............................................................................................................................296.1.4 MAMES CANCEL.............................................................................................................................30

ETSI


6.1.5 MAMES ACK.....................................................................................................................................306.2 MAMES Message Headers.......................................................................................................................316.2.1 MAMES Mandatory Headers..............................................................................................................316.2.1.1 The ALERT Mandatory Header....................................................................................................316.2.1.2 The Ultra-Short ALERT Mandatory Header.................................................................................316.2.1.3 The UPDATE Mandatory Header.................................................................................................326.2.1.4 The CANCEL Mandatory Header.................................................................................................326.2.1.5 The ACK Mandatory Header.........................................................................................................336.2.2 MAMES Extension Headers...............................................................................................................336.2.2.1 Extension Header A.......................................................................................................................336.2.2.2 Extension Header B.......................................................................................................................346.2.2.3 Response Type Header..................................................................................................................346.2.2.4 Validity Header..............................................................................................................................346.2.2.5 Administrative Areas Header.........................................................................................................346.2.2.6 Authentication/Integrity Header....................................................................................................356.2.2.7 Encryption Header.........................................................................................................................356.2.3 The Alert Message Header..................................................................................................................366.3 MAMES Header Fields ............................................................................................................................366.3.1 Fields of Mandatory Headers..............................................................................................................366.3.1.1 MAMES Protocol Version.............................................................................................................366.3.1.2 MAMES Message Type.................................................................................................................376.3.1.3 MAMES Message ID.....................................................................................................................376.3.1.4 MAMES Alert Provider ID............................................................................................................376.3.1.5 Notification Area...........................................................................................................................386.3.1.6 MAMES Priority............................................................................................................................386.3.1.7 ACK Request Flag.........................................................................................................................396.3.1.8 Alert Issuer ID...............................................................................................................................396.3.1.9 MAMES Event Category...............................................................................................................406.3.1.10 Next Header Type..........................................................................................................................406.3.1.11 MAMES Reference........................................................................................................................416.3.1.12 MAMES Receiver Location..........................................................................................................416.3.1.13 MAMES Receiver ID....................................................................................................................426.3.2 Fields of Extension Header A..............................................................................................................426.3.2.1 MAMES Status..............................................................................................................................426.3.2.2 MAMES Alert Scope.....................................................................................................................436.3.3 Fields of Extension Header B..............................................................................................................436.3.3.1 MAMES Incident ID.....................................................................................................................436.3.3.2 Alert Issued....................................................................................................................................436.3.4 Fields of the Response Type Header...................................................................................................446.3.4.1 MAMES Response Type...............................................................................................................446.3.5 Fields of the Validity Header..............................................................................................................446.3.5.1 MAMES Validity Start..................................................................................................................446.3.5.2 MAMES Validity End...................................................................................................................456.3.6 Fields of the Administrative Areas Header.........................................................................................456.3.6.1 Administrative Areas Header Version...........................................................................................456.3.6.2 Administrative Areas Coding........................................................................................................456.3.6.3 Number of Areas............................................................................................................................466.3.6.4 Area IDs.........................................................................................................................................466.3.7 Fields of the Authentication/Integrity Header.....................................................................................466.3.7.1 Authentication/Integrity Header Version.......................................................................................466.3.7.2 Authentication/Integrity Flag.........................................................................................................476.3.7.3 Authentication/Integrity Algorithm ID..........................................................................................476.3.7.4 MAC Value Length.......................................................................................................................476.3.7.5 MAC Value....................................................................................................................................486.3.8 Fields of the Encryption Header..........................................................................................................486.3.8.1 Encryption Header Version...........................................................................................................486.3.8.2 Encryption Algorithm ID...............................................................................................................486.3.8.3 Initialisation Vector Length...........................................................................................................496.3.8.4 Initialisation Vector.......................................................................................................................496.3.8.5 Block Size......................................................................................................................................496.3.8.6 Number of Padding Bytes..............................................................................................................50

ETSI


6.3.7 Fields of the Alert Message Header....................................................................................................506.3.7.1 Alert Message ID...........................................................................................................................506.3.7.2 Alert Message Type.......................................................................................................................506.3.7.3 Language ID..................................................................................................................................516.3.7.4 Alert Message Length....................................................................................................................516.3.7.5 More AMHs Flag...........................................................................................................................52

7 Behaviour of MAMES Agents........................................................................................................537.1 MAMES Alerter-Side Agent.....................................................................................................................547.1.1 Communication with an Alert Issuer...................................................................................................547.1.2 Communication with a MAMES User-Side Agent.............................................................................547.2 MAMES User-Side Agent........................................................................................................................547.2.1 Communication with a MAMES Alerter-Side Agent.........................................................................547.2.2 Communication with an Alerting Device............................................................................................54

x xxx...................................................................................................................................................55x.x xxx.............................................................................................................................................................55

Proforma copyright release text block......................................................................................................56Annexes 56

Annex A (normative): MAMES Requirements (style H8)...................................................................56

Annex B (normative): MAMES Frame Field Details (style H8).........................................................56

B.1 Mandatory Header Fields Details (style H1)...................................................................................56B.1.1 Notification Area (style H2)......................................................................................................................56B.1.2 <MAMES Priority>: CAP <urgency> Mapping (style H2)......................................................................58

B.2 Mandatory Header Fields Details (style H1)...................................................................................58B.2.1 <Language ID>: ISO 639-1 Codes Mapping (style H2)...........................................................................58

Annex <C> (normative or informative): ATS in TTCN-2 (style H8).................................................62

<C.1> The TTCN-2 Machine Processable form (TTCN.MP) (style H1).................................................62

Annex <D> (normative or informative): ATS in TTCN-3 (style H8).................................................62

<D.1>............................................................................TTCN-3 files and other related modules (style H1).........................................................................................................................................................62

<D.2>.............................................................................HTML documentation of TTCN-3 files (style H1).........................................................................................................................................................62

Annex <E> (informative): Bibliography (style H8)..............................................................................63

Annex <F> (informative): Change History (style H8)..........................................................................63

History (style H1)......................................................................................................................................64A few examples:..........................................................................................................................................................64

ETSI


<PAGE BREAK>

Intellectual Property Rights (style H1)

This clause is always the first unnumbered clause.

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http://ipr.etsi.org).

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.

Foreword (style H1)

This unnumbered clause is mandatory and shall appear just after the IPR clause.

Replace all <parameters> with the appropriate text.

This Technical Specification (TS) has been produced by ETSI Technical Committee {ETSI Technical Committee|ETSI Project|<other>} <long techbody> (<short techbody>).

Multi-part documentsThe following block is required in the case of multi-part deliverables:

the <common element of the title> is the same for all parts;

the <part element of the title> differs from part to part; and if appropriate;

the <sub-part element of the title> differs from sub-part to sub-part.

The paragraph identifying the current part (and sub-part, if appropriate) shall be set in bold.

See an example in the Foreword of EN 300 392-3-5 standard regrouping the different cases we may have of multi-part deliverables containing different deliverable types (e.g. TSs and ENs), parts and sub-parts and a less complex one with TS 101 376-3-22.

For more details see clause 2.5 of the ETSI Drafting Rules (EDRs).

The best solution for maintaining the structure of series is to have a detailed list of all parts and subparts mentioned in one of the parts (usually it is part 1).

If you choose this solution, the following text has to be mentioned in all of the other parts and sub-parts:

The present document is part <i> of a multi-part deliverable. Full details of the entire series can be found in part [x] [Bookmark reference].

See an example in the Foreword of the EN 302 217-2-1.

Modal verbs terminology (style H1)

This unnumbered clause is a mandatory informative element and shall appear just after the "Foreword".

In the present document "shall", "shall not", "should", "should not", "may", "may not", "need", "need not", "will", "will not", "can" and "cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).

"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI


http://portal.etsi.org/Help/editHelp!/Howtostart/ETSIDraftingRules.aspx

http://www.etsi.org/deliver/etsi_en/302200_302299/3022170201/01.03.01_60/en_3022170201v010301p.pdf


http://www.etsi.org/deliver/etsi_ts/101300_101399/1013760322/03.02.01_60/ts_1013760322v030201p.pdf

http://www.etsi.org/deliver/etsi_en/300300_300399/3003920305/01.04.01_60/en_3003920305v010401p.pdf

Executive summary (style H1)

This unnumbered clause, if present, appears after the "Modal verbs terminology" and before the "Introduction". It is an optional informative element and shall not contain requirements.

The "Executive summary" is used, if required, to summarize the ETSI deliverable. It contains enough information for the readers to become acquainted with the full document without reading it. It is usually one page or shorter.

Introduction (style H1)

This unnumbered clause, if present, appears just before the "Scope". It is an optional informative element and shall not contain requirements.

<PAGE BREAK>

CLAUSE NUMBERING STARTS HEREAFTER.

Automatic numbering may be used in ETSI deliverables but it is highly recommended to use sequence numbering.Check http://portal.etsi.org/edithelp/Files/other/EDRs_navigator.chm clauses 2.12.1.1 and 6.9.2 for help.

1 Scope (style H1)

This clause numbered 1 shall start on a new page. More details can be found in clause 2.9 of the EDRs.

The Scope shall not contain requirements. Forms of expression such as the following should be used:

The present document …

From ToR:

In a global alert network, satellite links provide robust communication channels with broadcast capabilities. Alert messages can be issued from/distributed to many technologies including and not restricted to: SMS and cell broadcast, audio message, facsimile, POCSAG (pagers), slow scan TV, telex, etc. By using a standard and generic encapsulation format, one is therefore able to guarantee interoperability. This work item aims at defining a flexible encapsulation scheme for these alert messages still making provision for adding new message formats, and defining mechanisms in order to fulfil the associated requirements (e.g. as identified in EMTEL TS (TS 102 182)).

green marks require discussion

yellow marks indicate other interesting text, or incomplete parts

light blue marks indicate areas that require coordination with TR/Josef

red text = notes about the content of the section

EXAMPLE: The present document provides the necessary adaptions to the endorsed document.

<PAGE BREAK>

ETSI



http://portal.etsi.org/edithelp/Files/other/EDRs_navigator.chm

2 References (style H1)

This clause numbered 2 appears just after the "Scope". It is a required element.

The following text block applies. More details can be found in clause 2.10 of the EDRs.

References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references,only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.

Referenced documents which are not found to be publicly available in the expected location might be found at http://docbox.etsi.org/Reference.

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity.

2.1 Normative references (style H2)

Clause 2.1 shall only contain normative (essential) references, which are cited in the document itself. These references have to be publicly available and in English.

The following referenced documents are necessary for the application of the present document.

Use the EX style, enclose the number in square brackets and separate it from the title with a tab (you may use sequence fields for automatically numbering references, see clause A.4: "Sequence numbering") (see example).

EXAMPLE:

[X] [tab] <Standard Organization acronym> <document number>: "<Title>".

[1] Franck, L.; Suffritti, R., "Multiple Alert Message Encapsulation over Satellite," Wireless Communication, Vehicular Technology, Information Theory and Aerospace & Electronic Systems Technology, 2009. Wireless VITAE 2009. 1st International Conference on , vol., no., pp.540,543, 17-20 May 2009; doi: 10.1109/WIRELESSVITAE.2009.5172503.

2.2 Informative references (style H2)

Clause 2.2 shall only contain informative references, which are cited in the document itself.

The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area.

Use the EX style, add the letter "i" (for informative) before the number (which shall be in square brackets) and separate this from the title with a tab (you may use sequence fields for automatically numbering references, see clause A.4: "Sequence numbering") (see example).

EXAMPLE:

[i.1] [tab] <Standard Organization acronym> <document number> <V#>: "<Title>".

[i.2] [tab] <Standard Organization acronym> <document number>: "<Title>".

3 Definitions, symbols and abbreviations (style H1)

Delete from the above heading the word(s) which is/are not applicable, (see clause 2.11 of EDRs).

Definitions and abbreviations extracted from ETSI deliverables can be useful when drafting documents and can be consulted via the Terms and Definitions Interactive Database (TEDDI) (http://webapp.etsi.org/Teddi/).

ETSI


http://webapp.etsi.org/Teddi/


http://docbox.etsi.org/Reference


3.1 Definitions (style H2)

Clause numbering depends on applicability.

A definition shall not take the form of, or contain, a requirement.

The form of a definition shall be such that it can replace the term in context. Additional information shall be given only in the form of examples or notes (see below).

The terms and definitions shall be presented in alphabetical order.

The following text block applies. More details can be found in clause 2.11.1 of the EDRs.

For the purposes of the present document, the [following] terms and definitions [given in ... and the following] apply:

I suggest to keep the definitions in the TR for the time being (to avoid inconsistent definitions). New ones can be added here however.

Definition format Use the Normal style.

The term shall be in bold, and shall start with a lower case letter (unless it is always rendered with a leading capital) followed by a colon, one space, and the definition starting with a lower case letter and no ending full-stop.

<defined term>: <definition>

EXAMPLE: text used to clarify abstract rules by applying them literally

NOTE: This may contain additional information.

3.2 Symbols (style H2)

Symbols should be ordered alphabetically. Clause numbering depends on applicability.


For the purposes of the present document, the [following] symbols [given in ... and the following] apply:

Symbol format Use the EW style and separate this from the definition with a tab. Use the EX style for the last term.

<1st symbol> [tab]<1st Explanation> (style EW)<2nd symbol> [tab]<2nd Explanation> (style EW)<3rd symbol> [tab]<3rd Explanation> (style EX)

3.3 Abbreviations (style H2)

Abbreviations should be ordered alphabetically. Clause numbering depends on applicability.


For the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:

Abbreviation format Use the EW style and separate this from the definition with a tab. Use the EX style for the last term.

<1st ACRONYM> [tab]<Explanation> (style EW)

AM Alert MessageAMH Alert Message Header

ETSI





EH Extension HeaderMH Mandatory HeaderP Payload

<PAGE BREAK>

ETSI


4 MAMES Objectives and Operation

4.1 MAMES ObjectivesMAMES main objectives are:

the definition of a multiple Alert Message encapsulation protocol for Alert Messages transport over satellite links;

the provision of a flexible and extensible encapsulation scheme;

the encapsulation of a single or a concatenation of Alert Messages (e.g. POCSAG, CAP, unstructured text, image, etc);

the definition of additional (optional) functions for service extension and adaption towards specific crisis situations;

the integration of the defined protocol with the main telecommunication satellite architectures (Galileo Public Regulated Service and Commercial Service data part; DVB-Suite; any IP-based satellite access, etc).

4.2 Overview of MAMES Operation An overview of MAMES basic operation is provided. The MAMES network entities (MAMES Alert Provider and MAMES Alert Receiver) are introduced together with the two MAMES operative modes and the MAMES Agents are presented with the aim to characterize the entities responsible for the execution of the protocol.

4.2.2 MAMES Operative Modes: Direct and Indirect MAMES Alerting For the purpose of the present specification, the focus is on the MAMES entities responsible for initiating and terminating the MAMES Protocol. These are:

the MAMES Alert Provider;

the MAMES Alert Receiver.

Table x.x reports a description of the MAMES network entities.

ETSI


Table x.x: MAMES Network Entities

MAMES Entity MAMES Network Side

Description

MAMES Alert Provider Alerter side

MAMES Network entity that generates MAMES Messages (forward) and receives MAMES ACK Messages (if a return link is available):

upon reception of an Alert Protocol Message from an Alert Issuer, it is responsible for encapsulating that message in a MAMES Message (forward) and transmitting it via its associated SatCom/SatNav Provider.

upon reception of a MAMES ACK Message originated by a MAMES Alert Receiver, it is responsible for receiving and handling the acknowledgement.

MAMES Alert Receiver User side

MAMES Network entity that terminates MAMES Protocol and generates MAMES ACKs:

upon reception of a MAMES Message originated by a MAMES Alert Provider, it is responsible for receiving and decapsulating it.

upon a request of transmitting a MAMES ACK (if a return link is available), it is responsible for generating and transmitting it back to the MAMES Alert Provider.

Figure x.x illustrates the basic MAMES alerting operation, showing the main involved entities and messages exchanged. In detail the two MAMES operative modes depicted in Figure x.x. are:

Direct MAMES Alerting. The MAMES Alert Receiver is inside the satellite user segment and directly receives the MAMES Messages.

Indirect MAMES Alerting. The MAMES Alert Receiver is outside the satellite user segment and therefore an intermediary network entity is in charge of forwarding MAMES Messages to the MAMES Alert Receiver.

Figure x.x: Overview of MAMES Operation

ETSI


In the Indirect MAMES Alerting the Alert Intermediary System is introduced. Although it is not a MAMES entity, for completeness, it is worth clarifying its role within the MAMES Network.

An Alert Intermediary System is defined as a telecommunication network or a node that forwards alert-related messages. As detailed in the MAMES Protocol Architecture, an Alert Intermediary System can be represented by:

a simple network relay node, which relays the received MAMES Message/Alert Message through a specific communication link and technology and re-transmits it over a different link and based on a different communication technology;

a telecommunication network, used for transporting MAMES Message/Alert Message.

The MAMES Indirect Alerting operative mode may include one or more Alert Intermediary System between the MAMES Alert Provider and the MAMES Alert Receiver.

4.2.3 The MAMES Agents A MAMES Agent is a software module that executes the MAMES Protocol. Two types of MAMES Agents are defined:

the MAMES Alerter-Side Agent;

the MAMES User-Side Agent.

As depicted in Figure x.x, the former serves the MAMES Alert Provider and the latter the MAMES Alert Receiver.

Figure x.x: MAMES Alerter-Side and User-Side Agents

The figure illustrates the role of the MAMES Alerter-Side and User-Side Agents, highlighting their interfaces to other entities. In particular, the MAMES Alerter-Side and User-Side Controller are introduced. They play the role of supervisory entities for the MAMES Agents. The Controllers’ function is to configure, control and monitor the Agents, and to receive information from the Agents. The Controller may be represented by: a software module operated under direct human supervision and control (MAMES Agent configuration and operation control in coordination with the Alert Issuer) or an autonomous software algorithm performing these tasks.

ETSI


From the MAMES Protocol point of view, only the MAMES Alerter-Side and User-Side Agents perform protocol actions, leaving the MAMES Alerter-Side and User-Side Controllers outside the scope of the present specification. In the above figure, only the MAMES Agents (red margin) and the communications between them (red arrows) are within the scope of MAMES.

4.3.1.1 MAMES Alerter-Side Agent

The MAMES Alerter-Side Agent is the MAMES Agent serving the MAMES Alert Provider. It is a software module responsible for the creation of the MAMES Message. Its main function is to receive the Alert Message as a Service Data Unit (SDU) and produce the MAMES Message as Protocol Data Unit (PDU), enabling the correct transmission of MAMES Message from the MAMES Alert Provider to the MAMES Alert Receiver in case of Direct MAMES Alerting, or to an Alert Intermediary System in case of Indirect MAMES Alerting.

If a return link is available and if this operating mode is enabled, the MAMES Alerter-Side Agent allows also the reception of MAMES ACK(s) originated by the MAMES Alert Receiver and the proper handling of them and of the corresponding Alert Message acknowledgements (if any).

4.3.1.2 MAMES User-Side Agent

The MAMES User-Side Agent is the MAMES Agent serving the MAMES Alert Receiver. It is a software module responsible for the termination of the MAMES Protocol. Its main function is to receive the MAMES Message and decapsulate it. The MAMES User-Side Agent output towards the higher layers is the Alert Message(s) carried by the MAMES message (MAMES Message Payload).

If a return link is available and if this operating mode is enabled, the MAMES User-Side Agent is also responsible for the reception of Alert Message acknowledgments originated by the Alerting Device and/or generation of MAMES ACK(s) and subsequent transmission of them back to the MAMES Alert Provider..

<PAGE BREAK>

ETSI


5 MAMES Architecture This clause defines the MAMES Functional and Protocol Architectures, focusing on the main MAMES functional entities and on the MAMES positioning in a protocol-stack architecture, respectively.

5.1 Functional Architecture A high level description of the MAMES Functional blocks and their interconnections is reported in Table 5.1.

Table 5.1: MAMES Functional Entities Description

MAMES Functional Block Description Interfacing Functional Blocks

MAMES Signalling Processing

It receives and dispatches the MAMES configuration and control messages (MAMES signaling messages) by activating the right functional MAMES block.

MAMES Controller

MAMES Message Framing

MAMES Message De-Framing

MAMES Scheduling & Forwarding


It generates a MAMES Frame, according to the request received from the MAMES Signalling Processing entity. It creates the MAMES Header and encapsulates Alert Message(s) (if any) in the MAMES Frame.



MAMES Message De-framing

It processes the received MAMES Frame. It parses the MAMES Header and decapsulates the Alert Message(s) contained in the Payload (if any).




It schedules the MAMES Frames and/or forwards them towards the MAMES network entity the MAMES Message is destined to.



MAMES Message De-Framing

Figure 5.1 and Figure 5.2 depict the MAMES Functional Blocks within the MAMES entities for the alerter and user side of the MAMES Network, respectively.

ETSI


Figure 5.1: MAMES Functional Entities (Alerter-Side of the MAMES Network)

ETSI


Figure 5.2: MAMES Functional Entities (User-Side of the MAMES Network)

5.1.1 MAMES Functional Blocks Main FeaturesIn the following a description of the main MAMES functional blocks is reported, differentiating between Alerter and User side of the MAMES Network . It is worth clarifying that for each functional entity a general overview of the main features is provided; a detailed design of the different elements is implementation dependent and is out of scope of this specification. Moreover communications/behavior among the MAMES Agents will be reported in section 7.

5.1.1.1 MAMES Signalling Processing Block

ETSI


Table x.x: MAMES Signalling Processing Block Description

MAMES Functional

Block

MAMES Network

SideDescription

Input Output

MA

MES

Sig

nalli

ng P

roce

ssin

g

Ale

rter-

Side

It forwards the control and configuration messages from the MAMES Alerter-Side Controller to the right MAMES Alerter-Side Agent functional blocks and the notification messages of a performed action from a MAMES Alerter-Side Agent functional block to the MAMES Alerter-Side Controller.

MAMES Signalling:

Control messages

Configuration messages

Notification messages

MAMES Signalling:

Control messages

Configuration messages


Use

r-Si

de

It forwards the control and configuration messages from the MAMES User-Side Controller to the right MAMES User-Side Agent functional blocks and the notification messages of a performed action from a MAMES User-Side Agent functional block to the MAMES User-Side Controller.

5.1.1.2 MAMES Message Framing Block

Table x.x: MAMES Message Framing Block Description

MAMES Functional

Block

MAMES Network

SideDescription

Input Output

MA

MES

Mes

sage

Fra

min

g

Ale

rter-

Side

Upon reception of a MAMES framing request and one or more Alert Message(s), it generates a MAMES Message, which includes a Payload, encapsulating the received Alert Message(s) into a MAMES Frame.

While upon the reception of only a MAMES framing request, it generates a MAMES Message, which does not include a Payload. It generates the MAMES Header of the MAMES Message, following the received indications (signalling).

As the MAMES Frame is generated, it forwards it to the MAMES Scheduling and Forwarding Block and notifies the MAMES Alerter-Side Agent Signalling Processing Block of the preformed actions.

MAMES Signalling messages

Alert Message(s)

MAMES Message


ETSI


MAMES Functional

Block

MAMES Network

SideDescription

Input Output

Use

r-Si

de

Upon reception of a MAMES frame that request for acknowledgement, it generates a MAMES ACK Frame (no Payload) according to the indication received from the MAMES Signalling Processing block.

While upon the reception of an Alert Protocol level acknowledgement to be sent back to the MAMES Alert Issuer, it generates a MAMES ACK Frame encapsulating the received Alert Message in the MAMES ACK Payload.

As the MAMES ACK is generated, it forwards it to the MAMES Scheduling and Forwarding Block and notifies the MAMES User-Side Agent Signalling Processing Block of the preformed actions.


Acknowledgement Alert Message(s)

MAMES ACK Message


5.1.1.3 MAMES Message De-Framing Block

Table x.x: MAMES Message De-Framing Block Description

MAMES Functional

Block

MAMES Network

SideDescription

Input Output

MA

MES

Mes

sage

De-

Fram

ing

Ale

rter-

Side

Following the indications received from the MAMES Signalling Processing Block of the Alerter-Side Agent, upon reception of a MAMES ACK, it parses the MAMES Header and decapsulates the MAMES ACK obtaining the transmitted Alert Message acknowledgements (if any) to be forwarded towards the Alert Issuer.

After these operations it notifies the MAMES Signalling Processing Block of the performed actions.


MAMES ACK Message

Acknowledgement Alert Message(s)


Use

r-Si

de

Following the indications received from the MAMES Signalling Processing Block of the User-Side Agent, upon reception of a MAMES Frame, it parses the MAMES Header, and decapsulates the MAMES Message obtaining the transmitted Alert Message(s) (if any) to be forwarded towards the Alerting Device.



MAMES Message (ALERT, Ultra-short ALERT, CANCEL, UPDATE)

Alert Message(s)


ETSI


Sara Jayousi, 16/12/14,

to be decided

5.1.1.4 MAMES Scheduling & Forwarding Block

Table x.x: MAMES Scheduling & Forwarding Block Description

MAMES Functional

Block

MAMES Network

SideDescription

Input Output

MA

MES

Sch

edul

ing

& F

orw

ardi

ng

Ale

rter-

Side

Following the indications received from the MAMES Signalling Processing Block of the Alerter-Side Agent (including MAMES Message priority management indications), upon reception of a MAMES Frame from the MAMES Framing Block, it schedules the received frame and forwards it in the appropriate forwarding queue for transmission.


MAMES Message


MAMES Message


Use

r-Si

de

Following the indications received from the MAMES Signalling Processing Block of the User-Side Agent (including MAMES Message priority management indications), upon reception of a MAMES ACK from the MAMES Framing Block, it schedules the received frame and forwards it in the appropriate forwarding queue for transmission.


MAMES ACK


MAMES ACK


5.2 Protocol Architecture In terms of the OSI layer model, it is assumed that MAMES operates above the highest layer provided by the (satellite) dissemination network. MAMES can work in different operative conditions:

End-to-end, implemented below the application layer.

Hop-by-hop, depending on the protocol stack implemented in the intermediate nodes (Alert Intermediary Systems).

In detail, MAMES shall be implemented as a shim layer in the protocol stack in order to:

offer the encapsulation service towards the above protocol layer generating Alert messages;

interface to the underlying layer for MAMES Message(s) properly transport through the network.

A high level design of the MAMES protocol architecture is provided. Focusing on the MAMES Alert Receiver, four cases are identified and for each of them the protocol-stack architecture is provided. As highlighted in Table X two main features of the MAMES Receiver are considered, to derive the four cases. These are:

the MAMES Receiver is INSIDE/OUTSIDE the satellite user segment (Direct/Indirect MAMES Alerting);

the capability of interpreting the Alert Protocol used by the Alert Issuer (Alert Protocol terminates INSIDE/OUTSIDE MAMES Receiver).

ETSI


Table x.x: MAMES Cases based on MAMES Receiver capabilities

Direct MAMES Alerting Indirect MAMES Alerting

Alert Protocol terminates INSIDE MAMES Receiver

CASE A1 CASE B1

Alert Protocol terminates OUTSIDE MAMES Receiver CASE A2 CASE B2

For simplicity, the protocol architecture analysis is carried out assuming that:

the payload of the MAMES Message contains a single Alert Message;

the Alert Protocol used by the Alert Issuer is supposed to be the same Alert Protocol transported by MAMES;

the Alerting device is capable of interpreting the Alert protocol used by the Alert Issuer.

The extension to the case of multiple Alert Messages inside one MAMES Message and to the case of multiple Alert Protocols are straightforward, and in any case not fundamental for the protocol architecture definition.

5.2.1 MAMES Direct Alerting

5.2.1.1 Protocol Architecture CASE A1

In Case A1 the MAMES Receiver is inside the satellite user segment and is represented by an Alerting Device that is capable of receiving MAMES Message and interpreting its content formatted according to the Alert Protocol of the Alert Issuer. Case A1 main features are:

Direct MAMES Alerting;

MAMES User-Side Agent is embedded in the Alerting Device,

The Alert Protocol terminates inside the MAMES Receiver.

Figure x depicts the Case A1 protocol stack architecture.

In detail, an Alert Message (formatted according to an Alert Protocol) is sent by the Alert Issuer to the MAMES Alert Provider which is in charge of encapsulating the received Alert Message (through the MAMES Alerter-Side Agent), and distributing the generated MAMES Message over a satellite communication/navigation network. The MAMES Message is directly received by the MAMES Receiver (Alerting Device), which decapsulates the MAMES Message (thanks to the embedded MAMES User-Side Agent) and interprets its content (since the Alert Message is formatted according to an Alert Protocol that is “understood” by the Alerting Device).

ETSI


Figure x.x: Direct MAMES Alerting - Case A1: Protocol Layer Architecture High Level Design

5.2.1.2 Protocol Architecture CASE A2

In Case A2 the MAMES Receiver is inside the satellite user segment, but it is not capable of interpreting the Alert Message formatted according to the Alert Protocol of the Alert Issuer. Case A2 main features are:

Direct MAMES Alerting;

MAMES User-Side Agent is not embedded in the Alerting Device;

The Alert Protocol terminates outside the MAMES Receiver;

One or more Alert Intermediary Systems are between the MAMES Receiver and the Alerting Device.

Figure x depicts the Case A2 protocol stack architecture.

As an example in the Figure x only one Alert Intermediary System is reported and it is represented by the Local Distribution Network and the Alert Protocol terminates inside the Alerting Device; however different Alert Intermediary Systems can be traversed by the Alert Message before the Alert Protocol is terminated and the Alert Protocol may also terminate inside one of them.

In detail, the MAMES Message is directly received by the MAMES Receiver which decapsulates the MAMES Message and forwards the Alert Message over a different communication link. The Alert Message is then received by the Alerting Device which interprets the Alert Message.

ETSI


Figure x.x: Direct MAMES Alerting - Case A2: Protocol Layer Architecture High Level Design

5.2.2 Indirect MAMES Alerting

5.2.2.1 Protocol Architecture CASE B1

In Case B1 the MAMES Receiver is outside the satellite user segment and is represented by an Alerting Device that is capable of receiving MAMES Message and interpreting its content formatted according to the Alert Protocol of the Alert Issuer. Case B1 main features are:

Indirect MAMES Alerting;

MAMES User-Side Agent is embedded in the Alerting Device;

The MAMES message traverses one or more Alert Intermediary Systems;

The Alert Protocol terminates inside the MAMES Receiver.

Figure x depicts the Case B1 protocol stack architecture.

In detail, describing the example illustrated in Figure x.x, the MAMES Message transmitted by the MAMES Alert Provider over a satellite communication/navigation network is received by an Alert Intermediary System, which forwards it to the MAMES Receiver (Alerting Device). The MAMES Receiver decapsulates the MAMES Message and interprets its content.

ETSI


Figure x.x: Indirect MAMES Alerting - Case B1: Protocol Layer Architecture High Level Design

5.2.2.2 Protocol Architecture CASE B2

In Case B2 the MAMES Receiver is outside the satellite user segment and it is not capable of interpreting the Alert Message formatted according to the Alert Protocol of the Alert Issuer. Case B2 main features are:

Inirect MAMES Alerting;

MAMES User-Side Agent is not embedded in the Alerting Device;

The MAMES message traverses one or more Alert Intermediary Systems;

The Alert Protocol terminates outside the MAMES Receiver;

The Alert Message traverses one or more Alert Intermediary Systems;

Figure x depicts the Case B2 protocol stack architecture.

In detail, describing the example reported in Figure x.x, the MAMES Message is received by an Alert Intermediary System which forwards it to the MAMES Receiver. The MAMES Receiver decapsulates the MAMES Message and forwards the Alert Message over a local distribution network, which represents the Alert Intermediary System between the MAMES Alert Receiver and the Alerting Device. The Alert Message is then received by the Alerting Device which is capable of interpreting it.

ETSI


Figure x.x: Indirect MAMES Alerting - Case B2: Protocol Layer Architecture High Level Design

ETSI


6 MAMES Messages This clause provides the definition of the MAMES Messages: message types, headers and fields definitions are reported.

The structure of a MAMES Frame and the adopted notation is reported in Figure 6.1.

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 (zero, single or multiple Alert Messages).

Figure 6.1: MAMES Frame Structure and Notation

The MAMES Frame Structure and MAMES Headers are defined with the aim to allow the transmission of multiple Alert Messages encapsulated in a single MAMES Message. However the following constraints shall be considered:

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

The encapsulated Alert Message(s) shall be characterized by: different Alert Protocol/media types (text, audio, image, etc.) and/or different languages and/or specific information related to different aspects of that event.

ETSI



to be updated according to the decision on the payload (AMH fields)

JR, 16/12/14,

I’m not sure if this fig should be in a TS (rather informal style).

6.1 MAMES Message TypesDifferent types of MAMES Message are defined based on the message purpose (e.g. message function) and satellite network transmission constraints (e.g. MAMES Transmission over GNSS Systems).

Five types of MAMES Messages are defined. These are:

MAMES ALERT

MAMES Ultra-short ALERT (Us-ALERT)

MAMES UPDATE

MAMES CANCEL

MAMES ACK

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

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 MAMES Ultra-short 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 scope and the basic functions are described.

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

Figure 6.4: MAMES Message Classification

ETSI



If a CAP Error Message Type needs to be transmitted, which MAMES Frame should be used? JR: we should use MAMES ALERT for all the CAP “forward” messages, since the MAMES Receiver passes on these messages anyway, and does not act on them. MAMES doesn’t care what kind of CAP message is inside the payload… MAMES CANCEL is meant for Alert Protocols that do not themselves have a cancel message. TO BE UPDATED According to the selected solution regarding Payload/no Payload (To be discussed)

6.1.1 MAMES ALERT MAMES ALERT Message enables the encapsulation of a single or multiple Alert Messages that need to be delivered for alert purposes.

A MAMES ALERT:

represents the “ordinary” MAMES Message;

may or may not include a payload: in “normal conditions”, it includes at least one AM in the payload.

A MAMES ALERT consists of:

a Header, which includes:

ALERT Mandatory Header (ALERT MH);

EHs;

AMHs;

a Payload, which comprises a single or multiple Alert Messages.

6.1.2 MAMES Ultra-Short ALERT The MAMES Ultra-short Message is the shortest MAMES Message defined with the aim to to allow the transmission of MAMES Message over narrowband satellite channels.(e.g.:MAMES over GNSS).

A MAMES Ultra-short ALERT:

is an extreme solution used in exceptional cases (e.g.: network resources limited contexts, out-of-band signaling, etc.);

carries very few information;

does not include backward/forward reference to a “longer” MAMES Message (MAMES ALERT).

An MAMES Ultra-short ALERT Message consists of only a Header, the Ultra-short ALERT Mandatory Header (Us-ALERT MH).

6.1.3 MAMES UPDATE MAMES UPDATE Message is an update at MAMES level. It is an update of a valid previously transmitted MAMES Message (MAMES ALERT or MAMES Ultra-short ALERT or MAMES UPDATE).

A MAMES UPDATE:

overwrites the Headers/Payload of the MAMES Frame it refers to, and leaves Headers/Payload that are not included unchanged.

enables the encapsulation of Alert Protocol level updates.

may or may not include a payload.

A MAMES UPDATE consists of:


UPDATE Mandatory Header (UPDATE MH);

ETSI


EHs;

AMHs;

a Payload, which comprises the updated versions of the Alert Messages contained in the MAMES Message the MAMES UPDATE refers to.

6.1.4 MAMES CANCEL A MAMES CANCEL Message is a cancellation at MAMES level. It declares a valid previously transmitted MAMES Message (MAMES ALERT, MAMES Ultra-short ALERT, MAMES UPDATE) as obsolete.

MAMES CANCEL:

handles the expiration of a valid MAMES Message or the erroneous transmission of a MAMES Message;

enables the encapsulation of Alert Protocol level cancellation messages (only in this case the MAMES CANCEL includes a payload).

A MAMES CANCEL consists of:


CANCEL Mandatory Header (CANCEL MH);

EH(s);

AMH(s).

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

6.1.5 MAMES ACK The MAMES ACK message provides acknowledgement at MAMES level of a previously received MAMES Message (ALERT or UPDATE, or CANCEL messages).

MAMES ACK:

notifies the success of reception of a MAMES Message;

is transmitted from the MAMES Receiver to the MAMES Provider in case they are connected through a bidirectional satellite network and the MAMES Alert Provider asks for acknowledgement or an Alert Protocol level acknowledgement needs to be transmitted;

enables the encapsulation of Alert Protocol level acknowledgements (only in this case the MAMES ACK includes a payload).

A MAMES ACK consists of:


ACK Mandatory Header (ACK MH);

EHs;

AMH(s);

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

ETSI


6.2 MAMES Message Headers In the following subsections the different MAMES Headers type are defined. These are:

the MAMES Mandatory Headers of the defined MAMES Message types;

the MAMES Extension Headers;

the Alert Message Header.

6.2.1 MAMES Mandatory Headers The main general features that characterize the MAMES Mandatory Headers of all the defined MAMES Message types follow. A Mandatory Header:

is mandatory;

is of fixed length;

pertains to the entire MAMES Message;

shall be processed by every MAMES Agent.

6.2.1.1 The ALERT Mandatory Header

Table 6.10: ALERT Mandatory Header

MAMES Header Type ALERT Mandatory Header

Definition Mandatory Header of the MAMES ALERT Frame.

Header Fields MAMES Protocol Version

MAMES Message Type

MAMES Message ID

MAMES Alert Provider ID

Notification Area

MAMES Priority

ACK Request Flag

Alert Issuer ID

MAMES Event Category

Next Header Type

ETSI


6.2.1.2 The Ultra-Short ALERT Mandatory Header

Table 6.11: Ultra-short ALERT Mandatory Header

MAMES Header Type Ultra-short ALERT Mandatory Header

Definition Mandatory Header of the MAMES Ultra-short ALERT Frame. It represents the entire MAMES Ultra-short ALERT Frame.


MAMES Message Type

MAMES Message ID


Notification Area

MAMES Priority

Alert Issuer ID


6.2.1.3 The UPDATE Mandatory Header

Table 6.12: UPDATE Mandatory Header

MAMES Header Type UPDATE Mandatory Header

Definition Mandatory Header of the MAMES UPDATE Frame.


MAMES Message Type

MAMES Message ID


Notification Area

MAMES Priority

MAMES Reference

ACK Request Flag

Alert Issuer ID


Next Header Type

6.2.1.4 The CANCEL Mandatory Header

Table 6.13: CANCEL Mandatory Header

MAMES Header Type CANCEL Mandatory Header

Definition Mandatory Header of the MAMES CANCEL Frame.


MAMES Message Type

MAMES Message ID

ETSI



Alert Issuer ID is not included in the CANCEL MH. Please consider the following case: MAMES CANCEL is used to encapsulate a CAP Cancel Message and ACK is requested. Considerations: The Alert Issuer ID needs to be included in the MAMES ACK to allow the MAMES Alert Provider to forward the ACK to the Alert Issuer. We assumed that the Alert Issuer ID of a MAMES ACK is the same of the one of the MAMES Message to be acknowledged. But the MAMES CANCEL does not have this field….. JR: we should transport all CAP “forward” messages inside a MAMES ALERT… that was our original assumpltion… and it still works I believe. MAMES doesn’t need to know what kind of CAP message it carries in the payload. MAMES CANCEL (and UPDATE) is meant for Alert Protocols that do not themselves have a cancel (an update) message.

MAMES Header Type CANCEL Mandatory Header


Notification Area

MAMES Priority

MAMES Reference

ACK Request Flag

Next Header Type

6.2.1.5 The ACK Mandatory Header

Table 6.14: ACK Mandatory Header

MAMES Header Type ACK Mandatory Header

Definition Mandatory Header of the MAMES ACK Frame.


MAMES Message Type

MAMES Reference


MAMES User Location

MAMES Priority

Alert Issuer ID

MAMES Receiver ID

Next Header Type

6.2.2 MAMES Extension Headers The main general features that characterize all the defined MAMES Extension Headers follow. An EH:

aims at enhancing the MAMES Frame by adding new features (e.g. integrity, encryption, etc.);

is an optional header of the MAMES Message;

pertains to the entire MAMES Message;

may contain fixed or variable length fields; for each variable length field, a field indicating its length is present.

contains only mandatory fields.

shall contain a “Next Header Type” field, specifying the type of the next header.

6.2.2.1 Extension Header A

Table 6.16: Extension Header A

MAMES Extension Header Extension Header A

Definition It denotes the appropriate handling and the intended distribution of the MAMES message.

ETSI


MAMES Extension Header Extension Header A

Header Fields MAMES Status

MAMES Alert Scope

Next Header TypeAllowed in MAMES

Message TypesALERT; UPDATE; CANCEL

6.2.2.2 Extension Header B

Table 6.17: Extension Header B

MAMES Extension Header Extension Header B

Definition It denotes the incident ID and the time when the alert was (first) issued by the Alert Issuer.

Header Fields MAMES Incident ID

Alert Issued



6.2.2.3 Response Type Header

Table 6.18: Response Type Header

MAMES Extension Header Response Type Header

Definition It denotes the recommended type of action.

Header Fields MAMES Response Type


Message TypesALERT; UPDATE

6.2.2.4 Validity Header

Table 6.19: Validity Header

MAMES Extension Header Validity Header

Definition It denotes the start and end time validity of the MAMES Message.

Header Fields MAMES Validity Start

MAMES Validity End



ETSI


6.2.2.5 Administrative Areas Header

Table 6.20: Administrative Areas Header

MAMES Extension Header Administrative Areas Header

Definition It denotes the Administrative Area to be alerted.

Header Fields Administrative Areas Header Version

Administrative Areas Coding

Number of Areas

Area IDs



6.2.2.6 Authentication/Integrity Header

Table 6.21: Authentication/Integrity Header

MAMES Extension Header Authentication/Integrity Header

Definition It is used for Authentication/Integrity.

Header Fields Authentication/Integrity Header Version

Authentication/Integrity Flag

Authentication/Integrity Algorithm ID

MAC Value Length

MAC Value


Message TypesALERT; UPDATE; CANCEL; ACK

6.2.2.7 Encryption Header

Table 6.22: Encryption Header

MAMES Extension Header Encryption Header

Definition It is used for Encryption.

Header Fields Encryption Header Version

Encryption Algorithm ID

Initialisation Vector Length

Initialisation Vector

ETSI


MAMES Extension Header Encryption Header

Block Size

Number of Padding Bytes


Message TypesALERT; UPDATE; CANCEL; ACK

6.2.3 The Alert Message Header

Table 6.23: Alert Message Header

MAMES Header Type Alert Message Header

Definition Alert Message specific header. It denotes the presence of at least one AM in the MAMES Payload and, pertaining only to the corresponding AM, it provides information related to that AM.

Header Fields Alert Message ID

Alert Message Type

Language ID

Alert Message Length

More AMHs Flag

Allowed in MAMES Message Types

ALERT; UPDATE; CANCEL; ACK

6.3 MAMES Header Fields In the following all the MAMES Header fields are defined in detail, grouping them according to the MAMES Header type (MHs, EHs, AMH) they belong to.

6.3.1 Fields of Mandatory Headers

6.3.1.1 MAMES Protocol Version

Table 6.24: MAMES Protocol Version Field

Field Name MAMES Protocol Version

Definition Version of the MAMES protocol used for Alert Message(s) encapsulation.

Code values Field Length [bits]

Value Range [decimal] Description

4 1 ≤ version ≤ 16 Version number of the MAMES Protocol.

ETSI



1) Byte-alignment: Waiting for feedback

6.3.1.2 MAMES Message Type

Table 6.25: MAMES Message Type Field

Field Name MAMES Message Type

Definition Type of the MAMES Message.

Code values Five codes are used to identify the different MAMES Message types.

Field Length [bits]

Value Range [binary] Description

4

0100 MAMES ALERT

0001 MAMES UPDATE

0010 MAMES CANCEL0011 MAMES ACK0000 Ultra-short MAMES ALERT

(all other) (Not defined)

6.3.1.3 MAMES Message ID

Table 6.26: MAMES Message ID Field

Field Name MAMES Message ID

Definition Unique identifier of a MAMES Frame originated by a MAMES Alert Provider.

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

Field Length [bits]


12

000000000001 First MAMES Message sent by the MAMES Alert Provider A

000000000010 Second MAMES Message sent by the MAMES Alert Provider A.

… …

111111111111 Last MAMES Message sent by the MAMES Alert Provider A, before restarting from 000000000001 MAMES Message ID.

6.3.1.4 MAMES Alert Provider ID

Table 6.27: MAMES Alert Provider ID Field

Field Name MAMES Alert Provider ID

Definition Identifier of the sender of the MAMES Message (MAMES Alert Provider).

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

ETSI


Field Length [bits]


12

000000000001 MAMES Alert Provider A000000000010 MAMES Alert Provider B

… …

6.3.1.5 Notification Area

TBD – I would not include a reference to the geo grid system analysis.

Table 6.28: Notification Area Field

Field Name Notification Area

Definition Geographic area where the MAMES Message needs to be delivered. It consists of: consists of: a point (latitude and longitude) and a radius (index, see Annex B.1.1).

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. An example is provided in Annex B.1.1.

Field Length [bits] Sub-code bit size

Value Range

[decimal] Description

48

1 0-1 Latitude North/South (+/-) (1/0)

7 0-89 Latitude Degrees

6 0-59 Latitude Minutes

6 0-59 Latitude Seconds

1 0-1 Longitude East/West (+/-) (1/0)

8 0-179 Longitude Degrees

6 0-59 Longitude Minutes

6 0-59 Longitude Seconds

4 0-16 Radius Index1 (up to 2000 km & >2000 km)

3 (all other) (Not defined)

6.3.1.6 MAMES Priority

Table 6.29: MAMES Priority Field

Field Name MAMES Priority

Definition Priority of the MAMES Frame with respect to other MAMES Frames

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 B.1.2.

Field Length [bits]


4 1111 Very High - The MAMES Message should be sent immediately

1 The radius indexes are detailed in the Annex B.1.1.

ETSI


0001 High – The MAMES Message should be sent soon.

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

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

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


6.3.1.7 ACK Request Flag

Table 6.30: ACK Request Flag Field

Field Name ACK Request Flag

Definition 1-bit flag indicating if a MAMES ACK Frame is requested by the MAMES Alert Provider.



1

0 The MAMES Alert Provider does NOT request for MAMES ACK

1 The MAMES Alert Provider DOES request for MAMES ACK

6.3.1.8 Alert Issuer ID

Table 6.31: Alert Issuer ID Field

Field Name Alert Issuer ID

Definition Identifier of the (original) source of the Alert Message, i.e., the emergency authority.

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

Field Length [bits] Value Range [binary] Description

16

0000000000000000 MAMES Alert Issuer Unspecified

0000000000000001 MAMES Alert Issuer A

0000000000000010MAMES Alert Issuer B

… …

ETSI


6.3.1.9 MAMES Event Category

Table 6.32: MAMES Event Category Field

Field Name MAMES Event Category

Definition Identifier of the event (incident) category.

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

Field Length [bits]


4

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

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

Explosive threat or attack

1101 Other events

0000 The event is NOT specified.


6.3.1.10 Next Header Type

Table 6.33: Next Header Type Field

Field Name Next Header Type

Definition Identifier of the type of the next header (header that immediately follows the current header).



4 0001 Extension Header A

0010 Extension Header B

0011 Response Type Header

0100 Validity Header

0101 Administrative Areas Header

0111 Authentication/Integrity Header

1000 Encryption Header

ETSI


1001 Alert Message Header

0000 No more headers follow.


6.3.1.11 MAMES Reference

Table 6.34.: MAMES Reference Field

Field Name MAMES Reference

Definition “MAMES Message ID” of an earlier MAMES Message, which needs to be referenced.

Code values See also “MAMES Message ID” code values definition - Section 6.3.1.3)

Field Length [bits]


12

000000000001 Reference to the first MAMES Message sent by the MAMES Alert Provider A

000000000010 Reference to the second MAMES Message sent by the MAMES Alert Provider A.

…

6.3.1.12 MAMES Receiver Location

Table 6.35: MAMES Receiver Location Field

Field Name MAMES Receiver Location

Definition Geographical position of the sender (MAMES Receiver) of the MAMES ACK.

Code values The code value identifying the MAMES Receiver Location is implemented as a bit array consisting of the sub-code fields listed in the following.

The code values cover the entire surface of the earth with an accuracy of 1 sec. (lat./long.), i.e., a few tens of meters.

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

Field Length [bits] Sub-code bit size Value Range

[decimal] Description

48 1 0-1 Latitude North/South (+/-) (1/0)

7 0-89 Latitude Degrees

6 0-59 Latitude Minutes

6 0-59 Latitude Seconds

1 0-1 Longitude East/West (+/-) (1/0)

8 0-179 Longitude Degrees

6 0-59 Longitude Minutes

6 0-59 Longitude Seconds

7 (all other) (Not defined) – Altitude could be useful (aircraft)??

ETSI


- 281474976710655 Code used for “unspecified” location

6.3.1.13 MAMES Receiver ID

Table 6.36: MAMES Receiver ID Field

Field Name MAMES Receiver ID

Definition Identifier of the sender of the MAMES ACK.

Code values The defined “MAMES Receiver ID” code values have local significance (each MAMES Alert Provider has its own ones).


16

0000000000000000 Unspecified

0000000000000001 MAMES User 1

0000000000000010 MAMES User 2…

6.3.2 Fields of Extension Header A

6.3.2.1 MAMES Status

Table 6.37: MAMES Status Field

Field Name MAMES Status

Definition Status of the MAMES Message, denoting the appropriate handling of the MAMES Message (Actual – Exercise – System – Test).

Code values Four MAMES Status cases are defined.

Field Length [bits]


3

000 Actual (default): The MAMES Frame refers to an actual event.

001 Exercise: The MAMES Frame refers to an exercise, rather than an actual emergency.

010 System: The MAMES Frame is sent for system-internal purposes, rather than referring to an actual emergency.

011 Test: The MAMES Frame is sent for test purposes.(all other) (Not defined)

ETSI



A clarification is needed. Annex A (T.1.5 pag.24) reports: If not present, a status corresponding to “actual” should be the default value (therefore this parameter does not need to be mandatory in MAMES). According to this sentence the” 000=Actual” code value could be omitted. The introduction of the default value comes from the “EHs grouping” operation, doesn’t it? Scope: include the case that a MAMES Status does not need to be set, but the MAMES Alert Scope does. JR: to be discussed

6.3.2.2 MAMES Alert Scope

Table 6.38: MAMES Alert Scope Field

Field Name MAMES Alert Scope

Definition Intended distribution of the MAMES message (restricted, unrestricted).

Code values Two MAMES Alert Scope code values are defined.

Field Length [bits]


000 Public (default): The MAMES Frame is addressed to the general public, for unrestricted access.

001Restricted: The MAMES Frame is addressed to restricted audiences (e.g. emergency personnel or other authorities), rather than the general public.


6.3.3 Fields of Extension Header B

6.3.3.1 MAMES Incident ID

Table 6.39: MAMES Incident ID Field

Field Name MAMES Incident ID

Definition Identifier of the incident. It is assigned by the MAMES Alert Provider for the purposes of identification and/or later reference.

Code values The defined “MAMES Incident ID” code values have local significance (each MAMES Alert Provider has its own ones).

Field Length [bits]


81 ≤ ID ≤ 255 Value assigned by the MAMES Alert Provider to identify the

particular incident.0 Unspecified

6.3.3.2 Alert Issued

Table 6.40: Alert Issued Field

Field Name Alert Issued

Definition Time instant when the respective Alert was issued by the Alert Issuer.

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

All date/time values between 1 Jan. 2000 0h 0’ 0” and 31 Dec. 2063 23h 59’ 59” . UTC/GMT???

Field Length [bits]

Sub-code bit size Value Range [decimal]

Description

ETSI



see previous comment

32

6 0-63 year since 2000

4 1-12 month of the year

5 1-31 day of the month

5 0-23 hour of the day

6 0-59 minute

6 0-59 second

- 0 Unspecified

6.3.4 Fields of the Response Type Header

6.3.4.1 MAMES Response Type

Table 6.41: MAMES Response Type Field

Field Name

Definition Type of action recommended for the target audience: Shelter – Evacuate – Prepare – Execute – Avoid – Monitor – Assess – AllClear – None)

Code values Nine MAMES Response Type code values are defined.

Field Length [bits]


4

0001 Shelter: Take shelter (details may be in the MAMES Payload).

0010 Evacuate: Evacuate the area (details may be in the MAMES Payload).

0011 Prepare: Make preparations (details may be in the MAMES Payload).

0100 Execute: Execute a pre-planned activity (details may be in the MAMES Payload).

0101 Avoid: Avoid the subject event (details may be in the MAMES Payload).

0110 Monitor: Attend to information sources (details may be in the MAMES Payload).

0111 Assess: Evaluate the information contained in the MAMES Payload.

0111AllClear: The subject event no longer poses a threat or concern and any follow-on action may be described in the MAMES Payload.

0000 None: No action recommended.(all other) (Not defined)

6.3.5 Fields of the Validity Header

6.3.5.1 MAMES Validity Start

Table 6.42: MAMES Validity Start Field

Field Name MAMES Validity Start

Definition Time instant when the MAMES Frame shall become valid.

ETSI


Code values For details see table

Field Length [bits] Value Range Description

32

All date/time values between 1 Jan. 2000 0h 0’ 0” and 31 Dec. 2063 23h 59’ 59”

Code value (bit array) indicating the time instant when the MAMES Frame shall become valid.

0 (decimal) Unspecified

6.3.5.2 MAMES Validity End

Table 6.43: MAMES Validity End Field

Field Name MAMES Validity End

Definition Time instant when the MAMES Frame shall become invalid.

Code values For details see table


32

All date/time values between 1 Jan. 2000 0h 0’ 0” and 31 Dec. 2063 23h 59’ 59”

Code value (bit array) indicating the time instant when the MAMES Frame shall become invalid.

0 (decimal) Unspecified

6.3.6 Fields of the Administrative Areas Header

6.3.6.1 Administrative Areas Header Version

Table 6.44: Administrative Areas Header Version Field

Field Name Administrative Areas Header Version

Definition Version of the Administrative Areas Header.



4 1 ≤ version ≤ 16 Version number of the Administrative Areas Header

6.3.6.2 Administrative Areas Coding

Table 6.45: Administrative Areas Coding Field

Field Name Administrative Areas Coding

Definition Identifier of the administrative areas coding scheme.

Code values Three Administrative Areas Coding schemes are supported by MAMES and corresponding code values are defined.

Field Length [bits]


ETSI


4

0000 NUTS [r4]

0001 NUTS and LAU [r5]

0010ISO 3166 [r6]


6.3.6.3 Number of Areas

Table 6.46: Number of Areas Field

Field Name Number of Areas

Definition Number of administrative area IDs contained in the field “Area IDs.” The Area IDs are coded according to the scheme specified in the “Administrative Areas Coding” field.

Code values

Field Length [bits]


6 1≤ number ≤ 64 The allowed maximum number of Area IDs is tentatively set to 2^6 (=64).

6.3.6.4 Area IDs

Table 6.47: Area IDs Field

Field Name Area IDs

Definition Administrative area codes.

Code values


The field length is determined by the length of one area code, as derived

from the “Administrative Areas Coding” field, multiplied by the “Number of Areas” parameter.

Any value of the specified length

This field contains the administrative area codes, strung together without separator.

6.3.7 Fields of the Authentication/Integrity Header

6.3.7.1 Authentication/Integrity Header Version

Table 6.48: Authentication/Integrity Header Version Field

Field Name Authentication/Integrity Header Version

Definition Version of the Authentication/Integrity Header.

ETSI




4 1 ≤version ≤16 Version number of the Authentication/Integrity Header.

6.3.7.2 Authentication/Integrity Flag

Table 6.49: Authentication/Integrity Flag Field

Field Name Authentication/Integrity Flag

Definition Flag denoting if an Authentication or an Integrity mechanism is applied to the MAMES Message.



10 A MAMES Authentication mechanism is being applied.

1 A MAMES Integrity mechanism is being applied.

6.3.7.3 Authentication/Integrity Algorithm ID

Table 6.50: Authentication/Integrity Algorithm ID Field

Field Name Authentication/Integrity Algorithm ID

Definition Identifier of the employed authentication/integrity algorithm.

Code values Three Authentication/Integrity Algorithms are supported by MAMES and corresponding code values are defined.

Field Length [bits]


6

000000 HMAC-SHA1

000001 HMAC-SHA256

000010AES-CMAC


6.3.7.4 MAC Value Length

Table 6.51: MAC Value Length Field

Field Name MAC Value Length

Definition

Code values

Field Length [bits]


ETSI


5 1 ≤ length ≤ 32 The length of the MAC Value is specified in terms of an integer, non-zero number of Bytes.

6.3.7.5 MAC Value

Table 6.52: MAC Value Field

Field Name MAC Value

Definition

Code values


As specified by the “MAC Value Length”

parameter


The output value resulting from the computations according to the Authentication/Integrity algorithm employed.

6.3.8 Fields of the Encryption Header

6.3.8.1 Encryption Header Version

Table 6.53: Encryption Header Version Field

Field Name Encryption Header Version

Definition Version of the Encryption Header.



4 1 ≤ version ≤ 16 Version number of the Encryption Header.

6.3.8.2 Encryption Algorithm ID

Table 6.54: Encryption Algorithm ID Field

Field Name Encryption Algorithm ID

Definition Identifier of the employed encryption algorithm.

Code values Two Encryption algorithms are supported by MAMES and corresponding code values are defined.

Field Length [bits]


6 000000 AES-CBC

ETSI


000001 AES-CTR

(all other)(Not defined)

6.3.8.3 Initialisation Vector Length

Table 6.55: Initialisation Vector Length Field

Field Name Initialisation Vector Length

Definition Length of the Initialisation Vector of the employed encryption algorithm.

Code values

Field Length [bits]


5 1 ≤ length ≤ 32 The length of the Initialisation Vector is specified in terms of an integer, non-zero number of Bytes.

6.3.8.4 Initialisation Vector

Table 6.56: Initialisation Vector Field

Field Name Initialisation Vector

Definition Initialisation Vector defined by the employed encryption algorithm.

Code values


As specified by the “Initialisation Vector Length” parameter


The Initialisation Vector as defined by the encryption algorithm employed.

6.3.8.5 Block Size

Table 6.57: Block Size Field

Field Name Block Size

Definition

Code values

Field Length [bits]


5 1 ≤ length ≤ 32 The Block Size is specified in terms of an integer, non-zero number of Bytes.

ETSI


6.3.8.6 Number of Padding Bytes

Table 6.58: Number of Padding Bytes Field

Field Name Number of Padding Bytes

Definition Number of Padding Bytes.



5 1 ≤ length ≤ 32 The Number of Padding Bytes is specified in terms of an integer, non-zero number of Bytes.

6.3.7 Fields of the Alert Message Header

6.3.7.1 Alert Message ID

Table 6.59: Alert Message ID Field

Field Name Alert Message ID

Definition Unique identifier of an Alert Message encapsulated by a MAMES Alert Provider.

Code values The MAMES Alert Provider is responsible for the numbering of the encapsulated Alert Messages. Consecutive numbers are used.


4

0001 First Aelrt Message sent by the MAMES Alert Provider A

0010 Second Alert Message sent by the MAMES Alert Provider A.

… …

6.3.7.2 Alert Message Type

Table 6.59: Alert Message Type Field

Field Name Alert Message Type

Definition Alert Protocol type or the type of data of the Alert Message (contained in the Payload) this specific AMH refers to.

Code values The defined code values identify the supported type of Alert Message/type of data of the first release of the MAMES Protocol.

Field Length [bits] Value Range [decimal] Description

ETSI


11

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

2 POCSAG. It includes: numeric messages and alphanumeric messages.

3 A4A protocol

range of values mapped on the Internet Media

Type/subtype

(4 ≤ type ≤1482)

Internet Media Type/subtype list (see ANNEX. X)

0 It is used in case no information regarding the AM type is given.


6.3.7.3 Language ID

Table 6.60: Language ID Field

Field Name Language ID

Definition Identifier of the language of the corresponding Alert Message.

Code values The considered languages are the ones listed by the ISO 639-1.

Field Length [bits]


81≤ ID ≤203 203 ISO 639-1 code values. A map of the ISO 639-1 codes

and the MAMES <Language ID> is reported in Annex B2.1.(all other) (Not defined).

6.3.7.4 Alert Message Length

Table 6.61: Alert Message Length Field

Field Name Alert Message Length

Definition Length of the pertaining Alert Message (in Bytes)

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.

Field Length [bits]


28

1 AM length = 1 Byte

2 AM length = 2 Bytes

… …

268435455 Maximum AM length ~268 Byte

ETSI


6.3.7.5 More AMHs Flag

Table 6.62: More AMHs Flag Field

Field Name More AMHs Flag

Definition Flag denoting if an AMH follows/does not follow the specific AMH.



10 No more AMHs follow.

1 At least one AMH follows.

ETSI


7 Behaviour of MAMES Agents Start from T1.3 MAMES Requ. (on Alerter & User-Side Agents), clause 6.

Also consider the clause on “Roles and Responsibilities of Actors” in the TR… “… upon reception of …”

<Text>.

***** PLEASE DO NOT CONSIDER THE FOLLOWING TEXT (these are preliminary notes that may be useful for this section)******

Notes from Alert Messages Types:

UPDATE:

NOTE 1: A MAMES UPDATE of a previously sent MAMES Message shall be sent if the Notification Area does not need to be changed. Otherwise the MAMES Alert Provider shall: 1) issue a MAMES CANCEL message referring to the MAMES Message to be updated; 2) issue a new MAMES Message (“ALERT” type) with the modified Notification Area.

NOTE 2: 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). 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).

NOTE 3: An update of a MAMES Ultra-short ALERT shall be represented by a MAMES UPDATE, including only the UPDATE MH.

ACK:

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

NOTE 2: If the MAMES Receiver sends a MAMES ACK, when and how is an implementation issue.

NOTE 3: 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).

Ultra-short ALERT:

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 MAMES Ultra-short 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.

ETSI


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: e.g. 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.

Notes from Headers fields:

see v02

The MAMES Extension Headers shall be seen as an (optional) tool for the MAMES Alert Provider that allows for a concise and standardised structuring of pre-existing alert information. Any alert-related information that the MAMES Alert Provider adds in the form of an Extension Header must be consistent with both content and intent of the original alert information as issued by the Alert Issuer. This may require communication between the MAMES Alert Provider and the Alert Issuer when building a MAMES Frame.

7.1 MAMES Alerter-Side Agent <Text>.

7.1.1 Communication with an Alert Issuer <Text>.

7.1.2 Communication with a MAMES User-Side Agent <Text>.

7.2 MAMES User-Side Agent <Text>.

7.2.1 Communication with a MAMES Alerter-Side Agent <Text>.

7.2.2 Communication with an Alerting Device<Text>.

ETSI


<PAGE BREAK>

x xxxFrom clause 4 the technical content of the deliverable shall be inserted. Each clause shall have a title which shall be placed after its number separated by a tab.

A clause can have numbered subdivisions, e.g. 5.1, 5.2, 5.1.1, 5.1.2, etc. This process of subdivisions may be continued as far as the sixth heading level (e.g. 6.5.4.3.2.1).

For numbering issues, see clause 2.12.1 of the EDRs.

Use the Heading style appropriate to its level (see clause 6.1, table 8 of the EDRs).

Separate the number of the heading and the text of the heading with a tab.

Treat clause titles as normal text (i.e. no additional capitalization), but no full stop.

<Text>.

<Text>.

x.x xxx<Text>.

IF YOUR DOCUMENT CONTAINS FIGURES, TABLES AND/OR MATHEMATICAL FORMULAE, THIS IS THE WAY THEY SHALL BE PREPARED:

- Figures shall be prepared in accordance to clauses 7.5.2 and/or 7.1 of the EDRs. The figure number and title shall be below the figure. An explicit figure title is optional. See clause 5.1.5 if you need to include notes to figures.

Use TF style for the figure number and title.

Use FL style on the paragraph which contains the figure itself.

If applicable, the figure number is followed by a colon, a space and the table title.

Maximum width for figures is 17 cm and maximum height is 22 cm.

Should you wish to number figures automatically, "Sequence numbering and bookmarking" (see clause 6.9.2 of the EDRs) is highly recommended.

- Tables shall be prepared in accordance to clause 5.2 of the EDRs. If you have tables in your document, the table number and title shall be above the table itself. An explicit table title is optional.

Use TH style for the table number and title.

If applicable, the table number is followed by a colon, a space and the table title.

Should you wish to number tables automatically, "Sequence numbering and bookmarking" (see clause 6.9.2 of the EDRs) is highly recommended.

- Mathematical formulae shall be prepared in accordance to clause 5.3 of the EDRs.

Numbers given to the clauses, tables, figures and mathematical formulae of an annex shall be preceded by the letter designating that annex followed by a full-stop (e.g. figure B.1, table C.4). The numbering shall start afresh with each annex. A single annex shall be designated "Annex A".

NOTE: For an easy application of the ETSI styles download "the ETSI styles toolbar" from editHelp! website.

ETSI


http://portal.etsi.org/Help/editHelp!/Standardsdevelopment/Drafting/Stylestoolbar.aspx








THE FOLLOWING TEXT IS TO BE USED WHEN APPROPRIATE:

Proforma copyright release text blockThis text box shall immediately follow after the heading of an element (i.e. clause or annex) containing a proforma or template which is intended to be copied by the user. Such an element shall always start on a new page.

Notwithstanding the provisions of the copyright clause related to the text of the present document, ETSI grants that users of the present document may freely reproduce the <proformatype> proforma in this {clause|annex} so that it can be used for its intended purposes and may further publish the completed <proformatype>.

<PAGE BREAK>

AnnexesEach annex shall start on a new page (insert a page break between annexes A and B, annexes B and C, etc.).

Numbers given to the clauses, tables, figures and mathematical formulae of an annex shall be preceded by the letter designating that annex followed by a full-stop. The numbering shall start afresh with each annex. A single annex shall be designated "Annex A".

Clauses in annex A shall be designated "A.1", "A.2", "A.3", etc. (further details in clause 2.12.1 of the EDRs).

Use the Heading 8 style. Insert a line break ("shift" + "enter") between the colon and the title.

For all annex clause headings use the appropriate Heading styles, starting from Heading 1, e.g. for clause A.1 use Heading 1, for clause A.1.1 use Heading 2. (See clause 6.1, table 8 of the EDRs).

Annex A (normative):MAMES Requirements (style H8)

Contains the updated clause 6 of T1.3 “MAMES Requirements”

<Text>.

<PAGE BREAK>

Annex B (normative):MAMES Frame Field Details (style H8)

This Annex contains details of some of the MAMES Frame Fields.

B.1 Mandatory Header Fields Details (style H1)

B.1.1 Notification Area (style H2)

<Text>.

ETSI




Table B.1: Notification Area MH Field: Radius

Radius index=code value log(radius[km]) radius[km] rounded km-values Meaning

0 radius unspecified

1 0 1,00 1 radius up to . km

2 0,25 1,78 2 radius up to . km

3 0,5 3,16 3 radius up to . km

4 0,75 5,62 6 radius up to . km

5 1 10,00 10 radius up to . km

6 1,25 17,78 20 radius up to . km

7 1,5 31,62 30 radius up to . km

8 1,75 56,23 60 radius up to . km

9 2 100,00 100 radius up to . km

10 2,25 177,83 200 radius up to . km

11 2,5 316,23 300 radius up to . km

12 2,75 562,34 600 radius up to . km

13 3 1000,00 1000 radius up to . km

14 3,25 1778,28 2000 radius up to . km

15 2000 radius greater than . Km

Table B.2: Notification Area MH Field: Example

Example of Area to be alerted Alcazar de Sevilla (37°23'02"N 5°59'28"W) + radius (20 km)

Notification Area Code 101001010101110000100000001011110110111000110000

Details

Geo-coordinates example [decimal] example [binary]

Latitude North/South (+/-) (1/0) 1 1

Latitude Degrees 37 0100101

Latitude Minutes 23 010111

Latitude Seconds 2 000010

Longitude East/West (+/-) (1/0) 0 0

Longitude Degrees 5 00000101

Longitude Minutes 59 111011

Longitude Seconds 28 011100

ETSI


Example of Area to be alerted Alcazar de Sevilla (37°23'02"N 5°59'28"W) + radius (20 km)

Radius Index1 (up to 2000 km & >2000 km) 6 0110

B.1.2 <MAMES Priority>: CAP <urgency> Mapping (style H2)

The following table reports a mapping between the CAP <urgency> element of the CAP <info> segment and the <MAMES Priority> code values.

Table B.1.2.1: <MAMES Priority> - CAP <urgency> Mapping

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

1111 Very High Immediate Responsive action SHOULD be taken immediately

0001 High ExpectedResponsive 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

B.2 Mandatory Header Fields Details (style H1)

<Text>.

B.2.1 <Language ID>: ISO 639-1 Codes Mapping (style H2)

The following table reports a mapping between the ISO 639-1 code values and the MAMES code values (in decimal). The <Language ID> field length is 8 bits.

Table B.2: < 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 Armenian

10 as Assamese11 av Avaric12 ae Avestan13 ay Aymara14 az Azerbaijani15 ba Bashkir16 bm Bambara17 eu Basque

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

ETSI



18 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 Basque49 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; Nuosu

ETSI



80 iu Inuktitut81 ie Interlingue; Occidental

82 ia Interlingua (International Auxiliary Language Association)

83 id Indonesian84 ik Inupiaq85 is Icelandic86 it Italian87 jv Javanese88 ja Japanese89 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 Komi100 kg Kongo101 ko Korean102 kj Kuanyama; Kwanyama103 ku Kurdish104 lo Lao105 la Latin106 lv Latvian107 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 Ndebele129 nd Ndebele, North; North Ndebele130 ng Ndonga131 ne Nepali132 nl Dutch; Flemish133 nn Norwegian Nynorsk; Nynorsk, Norwegian134 nb Bokmål, Norwegian; Norwegian Bokmål135 no Norwegian136 ny Chichewa; Chewa; Nyanja137 oc Occitan (post 1500)138 oj Ojibwa139 or Oriya140 om Oromo141 os Ossetian; Ossetic

ETSI



142 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 Somali164 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


<PAGE BREAK>

Abstract Test Suite (ATS) text blockThis text should be used for ATSs using either TTCN-2 or TTCN-3. In case:

TTCN-2 is used: attach the TTCN.MP;

TTCN-3 is used: attach the TTCN-3 files and other related modules, as well as the HTML documentation of the TTCN-3 files.

Annex <C> (normative or informative):ATS in TTCN-2 (style H8)

This text shall only be used for ATSs using TTCN version 2 (TTCN-2):

This ATS has been produced using the Tree and Tabular Combined Notation version 2 (TTCN-2) according to ISO/IEC 9646-3 [<bookmark reference>].

<C.1> The TTCN-2 Machine Processable form (TTCN.MP) (style H1)

The TTCN.MP representation corresponding to this ATS is contained in an ASCII file (<any_name>.MP contained in archive <Shortfilename>.ZIP) which accompanies the present document.

<PAGE BREAK>

Annex <D> (normative or informative):ATS in TTCN-3 (style H8)

This text shall only be used for ATSs using TTCN version 3 (TTCN-3):

This ATS has been produced using the Testing and Test Control Notation (TTCN) according to ES 201 873-1 [<bookmark reference>].

Indicated here which parts of the ES 201 873 series and its versions (editions) have been used; also indicate any extensions which have been used.

<D.1> TTCN-3 files and other related modules (style H1)

The TTCN-3 and other related modules are contained in archive <Shortfilename>.zip which accompanies the present document.

<D.2> HTML documentation of TTCN-3 files (style H1)

The HTML documentation of the TTCN-3 and other related modules are contained in archive <Shortfilename>.zip which accompanies the present document.

ETSI


<PAGE BREAK>

Annex <E> (informative):Bibliography (style H8)

This optional informative clause shall start on a new page and be the last annex of an ETSI deliverable or the last but one if followed by the "Change history/Change request history" annex, if any. The Bibliography shall not contain requirements.

The Bibliography identifies additional reading material not mentioned within the document. Those publications might or might not be publicly available (no check is made by the ETSI Secretariat).

The Bibliography shall include list of standards, books, articles, or other sources on a particular subject which are not referenced in the document.

The Bibliography shall not include references mentioned in the deliverable.

Use Heading 8 style for the "Bibliography" annex, see clause 2.13 for examples.

For the listed material use the Normal style or bulleted lists (e.g. B1+), do not use numbered references.

<Publication>: "<Title>".

OR

<Publication>: "<Title>".

<PAGE BREAK>

Annex <F> (informative):Change History (style H8)

The informative clause shall start on a new page and be the last annex before the "History" clause. It is an optional, informative element and shall not contain requirements.

If it is desired to keep a detailed record of the changes implemented in a new version it is recommended that this is done by inserting a "Change history/Change request" annex, see clause 2.15.

It shall be presented as a table. Apply the normal style format for tables (see clause 5.2.2 of the EDRs).

Date Version Information about changes

October 2011 1.1.1 First publication of the TS after approval by TC SPAN at SPAN#19(30 September - 2 October 2011; Prague)

February 2012 1.2.1

Implemented Change Requests:SPAN(12)20_019 Error message information clarificationsSPAN(12)20_033 Revised error message informationSPAN(12)20_046 update of figure 3 clause 9.2These CRs were approved by TC SPAN#20 (3 - 5 February 2012; Sophia)

Version 1.2.1 prepared by the Rapporteur

July 2013 1.3.1

Implemented Changes:

Correction needed because the previously approved version did not contain the last version of the ASN.1 and XML attachments.

Version 1.3.1 prepared by the Rapporteur

ETSI



<PAGE BREAK>

History (style H1)

This unnumbered clause shall start on a new page and be the last clause of an ETSI deliverable. It is a required informative element and shall not contain requirements.

The "History" identifies the major milestones in the life of an ETSI deliverable through the means of a table. The history box shall be provided by the ETSI Secretariat (all additional information will be removed at the publication stage).

Document history

<Version> <Date> <Milestone>

A few examples:

Document history

V0.0.5 April 2008 Pre-Processing done before TB approvale-mail: mailto:[email protected]

V1.1.1 July 2010 Publication

V2.0.0 March 2013 Clean-up done by editHelp!e-mail: mailto:[email protected]

Latest changes made on 2014-05-20

ETSI


mailto:[email protected]

mailto:[email protected]

SKELETON - ETSI · Web viewIn case of any existing or perceived difference in contents between such...

Documents

Transcript of SKELETON - ETSI · Web viewIn case of any existing or perceived difference in contents between such...