ARCHIVE - Common Look and Feel Guidance Version 1.2 - National Public Alerting System

Federal / Provincial / Territorial Public Alerting Working Group of Senior Officials Responsible for Emergency Management

PDF (783 KB)

2. Introduction

This document presents the current collection of specifications, policy decisions and recommended practices related to the Common Look and Feel (CLF) of public alerts associated with the National Public Alerting System (NPAS) initiative; for Alerting Authorities, Last Mile Distributors (LMD), and developers of applications that support the distribution of Canadian public alerts to the CLF objectives.

This document is versioned and will be updated as lessons are learned and advancements are made. Readers are encouraged to ensure they are working with the most current version of NPAS CLF Guidance available at http://www.npas.ca.

This document was initially produced with the support of the Centre for Security Science (CSS) Canadian Safety and Security Program (CSSP) at the request of the Federal/Provincial/Territorial (FPT) Senior Officials Responsible for Emergency Management (SOREM) Public Alerting Working Group (PAWG), and in consultation with the public-private CLF Working Group.

Responsibility for this document now resides with SOREM and the document is maintained by the CLF Working Group.

3. Purpose

The purpose of this document is to provide Last Mile Distributors (LMDs) and alerting authorities with the guidance they require to support the CLF of public alerts associated with the NPAS initiative.

4. Scope

The CLF guidance provided applies to all media unless specifically noted. Guidance for media not yet supported, such as a wireless public alerting system envisioned for Canada, is not included in this version, but can be expected to be included in future versions. 

5. Common Look and Feel

Common Look and Feel is an objective that aims to make public alerts more readily recognized by the Canadian public.

Ideally, every member of the public would receive the same alert content, the same alert signal, the same presentation format, etc., and while that may not be achievable due to the variety of distribution mediums, there are practices the NPAS community can follow to reduce the differences between broadcasters and distribution mediums.

CLF is not limited to visual and audible presentation. It also relates to alert repetition, expiry practices, the sequence of audience alert messages presented and other factors.

6. Terminology

Active Alert or Active Alert Message: An alert message which has not expired or been updated or cancelled.

Alberta Emergency Alert (AEA): The province of Alberta's alerting system.

Alerting Authority: An authority, recognized by a government authority, having a responsibility for issuing public alerts.

Alerting Attention Signal: An audible signal used to capture attention in advance of the presentation of an audience alert message.

Alert Message: The complete CAP message, which may include multiple audience alert messages. See CAP documentation for further clarification. http://docs.oasis-open.org/emergency/cap/.

Audience Alert Message: A complete message within a CAP alert message, that may be distinct from another audience alert message because of the language, alert area, severity, etc., and which is identifiable within the CAP message as a separate <info> element. It may or may not include audio and/or other resources.

Broadcasting Distribution Undertaking (BDU): An undertaking that distributes the signals of broadcasters.

Broadcast Delay: The time between the CAP alert message being available to a last mile distributor and the audience alert message(s) being presented to the public.

Broadcast Immediate Events List: A collection of event types and associated CAP urgency, severity and certainty conditions, that have been identified by the Senior Officials Responsible for Emergency Management as having an imminent or unexpected threat to life, that alerting officials wish to be distributed and presented to the public as soon as possible, even if it means disrupting the programming of last mile distributors.
The current version of this list is available at http://www.npas.ca

Broadcast Immediate Alert (BI): An audience alert message that aligns with the Broadcast Immediate Events List. BI should not be confused with Broadcast Intrusive - a similar term used by Environment and Climate Change Canada, who should be consulted on its current definition.

Broadcast Immediate Parameter (BIP): The parameter which indicates whether an alert meets the BI criteria.

Broadcast Text Parameter (BTP): The alert message text intended for use by LMDs for visual display and generating Text To Speech audio when an audio file is not available.

Canadian Profile of the Common Alerting Protocol (CAP-CP): A set of rules and references specific to the use of CAP in Canada. See http://www.cap-cp.ca

Common Alerting Protocol (CAP): The international message protocol adopted for use in NPAS. It is an international standard managed by OASIS, the Organization for the Advancement of Structured Information Standards. See http://docs.oasis-open.org/emergency/cap/

CAP Layer: A specification developed by one or more members of the alerting community that relates to the extension of CAP, in accordance with CAP, for including additional content within a CAP alert message. e.g. the parameters defined in the SOREM Public Alerting Layer.

CAP Profile: A specification developed by one or more members of the alerting community that includes additional constraints and rules for CAP users, all of which must be within the bounds of the CAP standard. e.g. Canadian Profile of the Common Alerting Protocol (CAP-CP).

Common Look and Feel (CLF): The objective of presenting clearly recognizable authoritative audience alert messages to the Canadian public through the diversity of communications media and distributors supporting the NPAS initiative.

CLF Working Group: Coalition of last mile distributors, vendors, equipment manufacturers and government representatives. The CLF Working Group reports to the PAWG.

Last Mile Distributor (LMD): A party that presents audience alert messages to the public through one or more media. E.g. Radio, television, search engine provider, SMS text message service, etc.

Layer: See CAP Layer.

National Alert Aggregation & Dissemination (NAAD) System: The CAP alert message aggregation system recognized as the national aggregator for NPAS. Owned and operated by Pelmorex Communications Inc. See https://alerts.pelmorex.com 

National Public Alerting System (NPAS): The Canadian Federal/Provincial/Territorial government led public alerting initiative. See http://www.npas.ca

Over-the-Air (OTA): Refers to radio and television broadcast directly to the end user, and not through a BDU.

PAWG: Public Alerting Working Group reporting to SOREM. PAWG members include Federal/Provincial and Territorial representatives.

Present: To format and display text, video, and/or audio, interrupting or mixing with the program feed as required.

Profile: See CAP Profile.

Senior Officials Responsible for Emergency Management (SOREM): A forum of Federal/Provincial/Territorial (F/P/T) officials responsible for coordinating a strategy for emergency management in Canada, and for providing guidance and advice on how to enhance emergency management in Canada. SOREM includes representatives from provincial and territorial emergency management organizations and Public Safety Canada.

SOREM Public Alerting Layer: A CAP layer developed by SOREM for the Canadian public alerting community.

7. Specifications

NPAS participants should work within the requirements of the following specifications. LMDs are not expected to accept or present alert messages which are not in compliance with these specifications.

7.1. Common Alerting Protocol (CAP)

The Common Alerting Protocol (CAP) is the message protocol adopted for use in NPAS. It is an international standard managed by OASIS, the Organization for the Advancement of Structured Information Standards. CAP is an international standard that can be found in use in many countries of the world.

Current and past versions of CAP can be found at http://docs.oasis-open.org/emergency/cap/

7.2. Canadian Profile of the Common Alerting Protocol (CAP-CP)

The Canadian Profile of the Common Alerting Protocol (CAP) was developed to address alerting issues specific to Canada. As an example, CAP-CP requires the inclusion of a Canadian <eventCode>, whereas CAP does not.

Current and past versions of CAP-CP can be found at http://www.cap-cp.ca

7.3. SOREM Public Alerting Layer

The SOREM Public Alerting Layer establishes parameters that are referred to by the CLF. The current version of the specification can be found in Appendix B.

7.4. Other Documents

NPAS participants that connect with the NAAD System should refer to the NAAD System resources available at https://alerts.pelmorex.com.  Participants may also subscribe to receive email notifications of technical updates and bulletins. For example, the Test Message Policy is available at this location.

If the alerting authority includes the actual location of the subject event in the CAP alert message, they should do so to the specifications defined by the CAPAN CAP Event Location Layer. http://www.canops.org/?page=CAPAN

8. Guidance

The guidance below applies to all alert messages distributed within the NPAS initiative, and not just those that are BI. Where guidance is specific to BI or a medium, it is noted. To the extent possible, guidance is not repeated. e.g. Official language considerations are not repeated for television and radio; only exceptions are noted.

8.1. CAP Message Elements

• 8.1.1. LMDs should use the content found in a suitable <parameter> in the CAP message in their presentation of the alert to the public.
  • 8.1.1.1. See Appendix C for parameters that are suitable for presentation of the alert to the public.
• 8.1.2. In the absence of a suitable <parameter>, LMDs should use the text assembled from an algorithm of fields and connecting words that is suitable for their presentation of the alert to the public.
  • 8.1.2.1. See Appendix C for algorithms that are suitable for presentation of the alert to the public.

8.2. Official Language Considerations

• 8.2.1. Alerting authorities are to issue audience alert messages in at least one of Canada's two official languages, English and/or French, in accordance with their government's legislation.
• 8.2.2. Whenever possible and practical, alerting authorities should include audience alert messages in both official languages, in both text and audio versions.
• 8.2.3. English and French audience alert messages for the same alert message are to be packaged within separate English and French <info> elements of a CAP alert message.
• 8.2.4. Preferably, the English and French text and audio audience alert messages from alerting authorities will be similarly complete. i.e. Both will include the same event reference, location references, instructions, etc. It is understood this may not be possible and practical for all alerting authorities.
• 8.2.5. LMDs are not expected to translate audience alert messages.
• 8.2.6. When a CAP alert message includes two or more languages, the LMD should present the audience alert message in the language(s) best suited to the community they serve in accordance with any applicable regulatory or legislative requirements, e.g. bilingual community.
• 8.2.7. When presenting audience alert messages in more than one language, the first language transmitted should be the principal language of the distribution medium.
• 8.2.8. If an audience alert message is present for only one of the two official languages, it should be used.

8.3. Alert Text, Audio, and Video

• 8.3.1. It is understood that the length and or the duration of an audience alert message may be truncated by LMDs to the technical constraints of LMD media. Alerting authorities are therefore encouraged to place the most important information at the beginning of the message to ensure that the most critical information is presented should their text, audio or video exceed the presentation constraints of an LMD.
  • 8.3.1.1. See Appendix A for medium constraints.
• 8.3.2. It is understood that some LMD applications may be programmed to interpret space, carriage return, new line, etc. in the CAP free form text elements as a single space. Recognizing the number of media that a single audience alert message may be distributed through; all alert originating parties, including re-originators, should note that trying to influence the presentation in one type of medium, or one LMD's medium, may negatively impact the presentation of the alert audience message in another.

8.4. Alerting Attention Signal

• 8.4.1. Wherever possible, the Canadian Alerting Attention Signal should be used to introduce audience alert messages that are identified as BI and distributed audibly.
• 8.4.2. In the event that LMD equipment cannot insert the Canadian Alerting Attention Signal, the use of an alternative alert signal or tone available to the LMD should be used.
• 8.4.3. Specifications
  • 8.4.3.1. The Canadian Alerting Attention Signal is comprised of two alternating complex tones. Tone 1 is formed by the combination of three frequencies, 932.33 Hz, 1046.5 Hz and 3135.96 Hz, modulated at 7271.96 Hz. Tone 2 is formed by the combination of three frequencies 440Hz, 659.26 Hz and 3135.96 Hz, modulated at 1099.26 Hz.
  • 8.4.3.2. The mp3 audio file of the Canadian Alerting Attention Signal can be obtained from http://www.npas.ca. 
  • 8.4.3.3. The duration of the Canadian Alerting Attention Signal is 8 seconds.
    
• 8.4.4. The relative volume of the Canadian Alerting Attention Signal should be normalized to the station's output.
• 8.4.5. LMD program audio should be off when the Canadian Alerting Attention Signal is played.
• 8.4.6. The Canadian Alerting Attention Signal should be placed before the audience alert message audio.
• 8.4.7. When presenting audience alert messages in more than one language, the Alerting Attention Signal should only precede the first language transmitted.
• 8.4.8. Use of the Canadian Alerting Attention Signal between multiple audience alert messages from the same alert is not required.
• 8.4.9. If the audience alert message is repeated, the Canadian Alerting Attention Signal should not precede the repeated audience alert message.
• 8.4.10. The interval between the Canadian Alerting Attention Signal and the audience alert message should be less than one second.
• 8.4.11. The Canadian Alerting Attention Signal is only to be used for the purpose of bringing attention to alerts issued through the NPAS, for testing, and for public education. Use of the Canadian Alerting Attention Signal is strictly prohibited for any other purpose.

8.5. Repeat Distribution of Audience Alert Messages

• 8.5.1. LMDs are expected to distribute or present a BI audience alert message a minimum of one time.
• 8.5.2. LMDs may at their own discretion distribute or present any active audience alert message to the public more than once but should not use the Canadian Alerting Attention Signal after the first time.

8.6. Alert Message Expires and Cancellation

• 8.6.1. Alerting authorities are responsible for ensuring their alert messages are expired or cancelled.
• 8.6.2. The active alert message may be ended by issuing an alert with <msgType> value of “Cancel”, or expired using <msgType> value of “Update” with an <expires> value set to the current or near current time, and the appropriate reference to the alert the cancel or update refers to.
• 8.6.3. The inclusion of an “AllClear” <responseType> is encouraged when the alert is being ended.
• 8.6.4. CAP allows for alert messages to be cancelled without an expiration time being provided. This may be done by an alerting authority in the hope that the cancel audience alert message is presented in some mediums. E.g. on a website. When cancelling an alert message, alerting authorities should provide an <expires> time. LMDs who receive a cancel message without an <expires> time, or a later <expires> time, should automatically consider the alert message to be expired.

8.7. Multiple BI Alert Audience Messages for the same Distribution Channel

• 8.7.1. LMDs should present multiple BI audience alert messages in the order they are received. BI audience alert messages should be presented before those that are not BI.

8.8. Broadcast Immediately and Effective Time

• 8.8.1. Alerting authorities should ensure that audience alert messages with a BI value of “yes” have an <effective> time equal to <sent>.

8.9. Multiple <info> Elements

• 8.9.1. If more than one <info> element of the same language is included in a CAP alert message, the most critical <info> elements should be placed first in the order of the CAP alert message.
• 8.9.2. It is understood that some LMDs may only be able to present the first <info> element of a CAP alert message that satisfies the criteria the LMD is programmed for. e.g. Combination of location, BI status, etc.
• 8.9.3. All LMDs are encouraged towards presenting alert messages with multiple <info> elements of the same language. The multiple <info> elements should be presented with the most critical ones first (as indicated by having a BI value of “yes”).

8.10. Updates

• 8.10.1. The LMD should present the updated alert message only, when an LMD receives an update to an alert message that they have not yet presented.
• 8.10.2. If the LMD receives an update to an alert message while playing that alert message, it should play the original message to completion then provide the update.

8.11. Broadcast Immediate and Minor Updates

• 8.11.1. If an LMD receives an update alert message with an <info> element having a BI value of “yes” that also includes a CAP-CP Minor Change <parameter>, the LMD is not expected to interrupt programming for the minor change update if the referenced alert was already presented.

8.12. Polygons

• 8.12.1. Alert authorities should, if possible, use the fewest number of polygons required to describe the area of the alert.
• 8.12.2. Alert authorities should, if possible, use polygons which do not exceed 150 vertices.
• 8.12.3. Any generalization of polygons associated with CAP-CP location references should include all areas of the single location, and may therefore also include areas outside of it. Further, overage should be kept to a minimum. For clarity, alerting a slightly larger area is preferred to alerting an area less than that which the alert has been issued for.
  

8.13. Speed of Delivery

• 8.13.1. Once an alert message has been published, every party involved in the distribution of that alert should work towards advancing and presenting the audience alert message to the public as quickly as possible.
• 8.13.2. LMDs should present BI audience alert messages immediately.
• 8.13.3. If an LMD with a visual and audible presentation (e.g. television) has the alert file in hand and cannot download an associated audio file within one minute, it should precede with the visual presentation, preferably with consideration to the guidance found in the section titled Audio Content Considerations 8.14. The Canadian Alerting Attention Signal should still be played.
• 8.13.4. Any audience alert message held in an LMD queue to follow a prior audience alert message should be presented following the presentation of the one before it.
• 8.13.5. When a new BI alert message is received, the current audience alert message should be allowed to finish playing, and then play the Canadian Alerting Attention Signal prior to playing the new BI audience alert message.

8.14. Audio Content Considerations

• 8.14.1. Alerting authorities should aim for audio content of less than 60 seconds in duration per language.
• 8.14.2. Audio content that is to be distributed over TV and radio should not exceed 120 seconds in duration per language.
• 8.14.3. Audio content should be made available to LMDs as a monophonic MP3 file, using a coding rate of 64 kbit/s data.
  • 8.14.3.1. Other audio formats may also be supported, depending on the LMD.
  • 8.14.3.2. The content of the audio message must not differ between the formats.
• 8.14.4. Audio file size should not exceed known system requirements as referenced in Appendix A.
• 8.14.5. Alerting authorities should not include the Canadian Alerting Attention Signal in the audio file associated with an audience alert message, as it is to be presented by LMDs before presenting the audio content provided to them.
• 8.14.6. In the absence of a suitable audio file, LMDs with audio capabilities are encouraged to read the text of the audience alert message or use LMD Text To Speech (TTS) to audibly present the text of the audience alert message.

8.15. Medium Specific Considerations

• 8.15.1. Television
  • 8.15.1.1. Program interruption may be limited to BI alert messages.
  • 8.15.1.2. Automated broadcast interruption need not be used if a person can immediately present the text of an audience alert message verbally and visually mindful of the other guidance found in this document. The Canadian Alerting Attention Signal should be played just prior to presenting the text.
  • 8.15.1.3. In the absence of a means to deliver an audible message, the Canadian Alerting Attention Signal should be played just prior to presenting the alert visually.
  • 8.15.1.4. Full Screen
    • 8.15.1.4.1. General
      • 8.15.1.4.1.1. The audience alert message need only be presented until it is acknowledged, removed or the channel changed by the viewer.
      • 8.15.1.4.1.2. The text should be limited to 120 words or approximately 720 characters, per page.
    • 8.15.1.4.2. Single Page
      • 8.15.1.4.2.1. The background colour should be solid red.
      • 8.15.1.4.2.2. The text should be white.
      • 8.15.1.4.2.3. The font should be arial, or similarly clean font, and of a size consistent with content normally presented for reading.
      • 8.15.1.4.2.4. The text should be centered.
      • 8.15.1.4.2.5. The entire text should be visible using televisions formatted to 4:3 aspect ratio.
      • 8.15.1.4.2.6. A banner should be used that reads “EMERGENCY ALERT“ in English and “ALERTE D'URGENCE“ in French.
      • 8.15.1.4.2.7. If a second language is to follow, an indicator should be presented at the bottom of the page. E.g. “Un message français suivra.”; “An English message follows.”
      • 8.15.1.4.2.8. The page should be presented or available for no less than 15 seconds and no more than 60 seconds.
    • 8.15.1.4.3. Multiple Page
      • 8.15.1.4.3.1. See “Single Page” for formatting of the pages of an audience alert message.
      • 8.15.1.4.3.2. An indication of the number of pages that are being used to present text should be presented below the banner at all times. e.g. Page x of y pages.
        
  • 8.15.1.5. Crawler Insertion
    • 8.15.1.5.1. The background colour should be solid red.
    • 8.15.1.5.2. The text should be white.
    • 8.15.1.5.3. The font should be arial, or similarly clean font, and of a size consistent with content normally presented for reading.
    • 8.15.1.5.4. Over-the-air broadcasters should center the crawler block mid-screen to avoid conflict with BDU crawlers that should be located at the bottom or top of the screen.
      • 8.15.1.5.4.1. Over-the-air recommended placement is 55% of picture height down from the top, and the bottom of the crawler 70% down from the top.
    • 8.15.1.5.5. The text should crawl from the right to the left.
    • 8.15.1.5.6. The text should crawl at a rate that does not exceed 400 characters per minute.
    • 8.15.1.5.7. The crawl may take longer than two minutes.
      • 8.15.1.5.7.1. The crawl may continue beyond the duration of the audio message.
    • 8.15.1.5.8. Closed captioning of the program should not interfere with the presentation of the crawler.
  • 8.15.1.6. Audio Considerations
    • 8.15.1.6.1. Program audio should be replaced with the alert audio for the duration of the Canadian Alerting Attention Signal and alert. Program audio may be restored as soon as the audio message has completed.
    • 8.15.1.6.2. Preferably, the alert audio will replace any described video service that may be running at the same time on SAP (NTSC) or VI (ATSC) channels.
    • 8.15.1.6.3. The LMD should synchronize the start of the audio content with the start of the visual content.
• 8.15.2. Radio
  • 8.15.2.1. Program interruption may be limited to BI alert messages.
  • 8.15.2.2. Automated broadcast interruption need not be used if a person can immediately present the text of an audience alert message verbally, mindful of the other guidance found in this document. The Canadian Alerting Attention Signal should be played just prior to presenting the text.

9. Future Considerations

Stakeholders are encouraged to review the material produced by the Centre for Security Science (CSS) Public Safety and Security Program (CSSP) at the request of the Federal Provincial Territorial (FPT) Senior Officials Responsible for Emergency Management (SOREM) Public Alerting Working Group, and in consultation with the public-private Common Look and Feel Working Group. Doing so may support a more comprehensive understanding of current constraints and opportunities. Please note this technical document contains technical recommendations only, whereas the CLF document is the official guidance document. This material is available at http://www.npas.ca

10. Credits and Recognition

• Participating Provincial and Territorial Government Agencies
• Canadian Association of Broadcasters Technical Coordinating Committee
• Canadian Radio-television Telecommunications Commission
• CAP EAS Industry Group
• CAP-CP Working Group
• Centre for Security Science
• Common Look and Feel Working Group
• Pelmorex Communications Inc.
• NetAlerts
• Environment Canada
• Allport Group

APPENDIX A – CLF Defined Constraints

1. Medium Constraints

• 1.1. Audience Alert Messages Intended for Presentation on Television or Radio
  • 1.1.1. Up to 900 characters per language (maximum 1800 characters)
  • 1.1.2. Up to 120 seconds audio per language (maximum 240 seconds)
• 1.2. NAAD System
  • 1.2.1. CAP file size of 5 MB prior to any conversion
• 1.3. Wireless Emergency Alerting (To be developed)

2. Industry Constraints

• 2.1. Television
  • 2.1.1. Full Screen
    • 2.1.1.1. 720 characters per full screen of text
    • 2.1.1.2. 60 seconds per page
    • 2.1.1.3. 1 to 2 screens of text per message
  • 2.1.2. Crawler Insertion
    • 2.1.2.1. 400 characters per minute

3. Audience Alert Messages That Exceed Limits

• 3.1. Alerting authorities are advised that messages that exceed these limits may be automatically truncated.
• 3.2. LMDs are encouraged to carry messages longer than the constraints and deliver them if possible.
• 3.3. Messages should not be rejected for minor constraint violations.

APPENDIX B – SOREM Public Alerting Layer

The SOREM Public Alerting Layer establishes a number of CAP <parameter>s which are used to support the public alerting community in Canada. In a separate document, SOREM maintains the “Broadcast Immediate Events List”, which works in conjunction with this layer. The current version of this list is available at http://www.npas.ca

1. Broadcast Immediate Parameter

The Broadcast Immediate Parameter (BIP) provides an indicator that the content of an alert message is intended for immediate broadcast by LMDs.

• 1.1. A CAP <parameter> shall be used to indicate when the criteria for a BI alert, as defined by the “Broadcast Immediate Events List”, have been met.
• 1.2. This <parameter> will be described as the Broadcast Immediate Parameter or BIP.
• 1.3. A BIP is an optional CAP element and is not required for non-BI alerts.  This includes alerts that don't meet the BI criteria and those do meet the BI criteria (Event, Urgency, Severity, Certainty) but are not intended for broadcast distribution.
• 1.4. For alerts that do meet the BI criteria, a BIP is required in order to properly indicate whether the alert is intended for immediate broadcast.
• 1.5. The <valueName> of the BIP <parameter> is “layer:SOREM:1.0:Broadcast_Immediately”. This <valueName> shall conform to the CAP-CP <valueName> Scheme. (i.e., naming conventions, versioning, case-insensitivity, etc.).
• 1.6. The BIP <parameter> <value> shall be either “yes” to indicate the alert is intended for immediate broadcast or “no” to indicate it is not. The <value> is case-insensitive and shall contain no other characters or whitespace.
• 1.7. A single BIP element is allowed in an <info> element.
• 1.8. When an alert contains multiple <info> elements, each <info> element should have a single respective BIP to indicate whether the <info> element meets the BI criteria. An alert therefore may have <info> elements that are BI and non-BI.
• 1.9. Multiple languages are supported via multiple <info> elements, each with a single respective BIP. Where the content of <info> elements differs only by language, i.e. translated free form text, the BIP <value> of those <info> elements should be the same.
• 1.10. The audience alert message for a BI alert shall be derived from <info> elements that have a BIP <value> of “yes”.

2. Broadcast Text Parameter

If the Broadcast Text Parameter (BTP) is available it can be used as the sole source of the audience alert message text for on-screen display and for audible presentation on television or radio, as described in Appendix C.

• 2.1. A CAP <parameter> shall be used to hold text which provides a suitably complete summary of an alert's content sufficient for public broadcast.
• 2.2. This <parameter> will be described as the Broadcast Text Parameter or BTP.
• 2.3. A BTP is an optional CAP element and is not required for BI alerts. Any alert may include a BTP.
• 2.4. The <valueName> of the BTP <parameter> is “layer:SOREM:1.0:Broadcast_Text”. This <valueName> shall conform to the CAP-CP <valueName> Scheme. (i.e., naming conventions, versioning, case-insensitivity, etc.).
• 2.5. The BTP <parameter> <value> shall contain the BTP element content. The maximum length of the BTP element content shall be in accordance with CLF guidance (Appendix A).
• 2.6. A single BTP element is allowed in an <info> element.
• 2.7. Multiple languages are supported via multiple <info> elements, each with a single respective BTP.
• 2.8. BTP element content shall only be in the language of the respective <info> element; mixing content from multiple languages is not permitted, except for place names.
• 2.9. The BTP element content should not substantially differ between languages, except for the required translation.
• 2.10. The BTP element content should be consistent with the content of existing elements of the CAP alert. This content cannot differ substantially so as to prevent confusion and contradiction.
• 2.11. BTP element content should contain, at a minimum, the event, location, issuing authority and instruction information following CLF guidance.

APPENDIX C – LMD Presentation Content

In presenting the content of an alert to the public, the LMD should use the preferred methods of Audio Content and Text Content as described below. In the event that such content is not available or the LMD does not support this content, the Assembled Content method should be used.

1. Audio Content

2. Text Content

3. Assembled Content

The following algorithms can be used to assemble content suitable for presentation of the alert to the public.

APPENDIX D – Alert Processing Guidance for Last Mile Distributors

1. Broadcast Immediate Alerts

• 1.1 The Broadcast Immediate Parameter, as defined in the SOREM Public Alerting Layer [ref.: Appendix C] shall be used to indicate when an alert is BI.
• 1.2. LMDs are not required to validate a BI alert against the “Broadcast Immediate Events List” as long as a valid BI indicator is included in the alert message.
• 1.3. LMDs should inspect all incoming CAP messages, regardless of whether they are indicated as BI or not. This is because CAP messages which are issued to update or replace active BI alerts may not be indicated as BI, since these new messages may not meet the BI criteria.  As such, if LMDs were to only take action for BI alerts, they may continue to distribute an alert to the public after it has been cancelled by the alerting authority. Furthermore, multiple BI alerts may be issued for a single emergency event, as the geographic area affected by the emergency may change or expand with time. In such a case, the existing BI alert may be updated and a CAP message issued with additional geographic areas added. These updates contain no new information for the public in the geographic areas that have been previously alerted; hence a given updated BI alert may not be pertinent for a particular LMD (e.g. if the new geographic areas are outside the LMD's area of interest), underlining the importance that LMDs inspect all incoming CAP messages, regardless of their frequency or BI status.

2. Audience Alert Message

• 2.1. CAP Parameter
  • 2.1.1 If a suitable <parameter> is available in the CAP message, and supported by the LMD, the <value> element of this <parameter> should be used for the Audience Alert Message [ref.: 8.1.1.]. The composition steps in Appendix D – 2.2 for the Audience Alert Message are therefore not required.
  • 2.1.2. The SOREM Broadcast Text Parameter and the Alberta Emergency Alert Broadcast Text Parameter currently provide acceptable parameters [ref.: 8.1.1.1.; Appendix C].
  • 2.1.3. Other than formatting changes, such as truncation due to any limits the LMD may have on message length [ref.: 8.3.1.], no other processing of the <parameter> content is necessary prior to presentation.
• 2.2. Algorithm Composition Steps for LMDs
  • 2.2.1. <info> elements should be evaluated in the order in which they appear in the CAP message [ref.: 8.9.1.]. The first <info> element which matches the appropriate criteria for use as defined by the LMD, such as language, importance, and location should be used for the composition steps [ref.: 8.9.2.]. Originating systems should place <info> elements with important information first with this guidance in mind [ref.: 8.9.1.].
  • 2.2.2. The section delimiter is specifically defined as a space, a dash, and a space. ex. “ - “.
  • 2.2.3. If the <info> element is a French language <info> element ex. “fr-CA” the Audience Alert Message shall begin with the phrase “Alerte” followed by a section delimiter. For all other languages including English, the Audience Alert Message shall begin with the phrase “Alert“ followed by a section delimiter.
  • 2.2.4. If the <info> element contains a <senderName> element, the Audience Alert Message will continue with the content from the <senderName> element followed by a section delimiter. If there is no <senderName> element, nothing will be added to the Audience Alert Message in this step.
  • 2.2.5. If the <info> element is a French language <info> element, the phrase “Alerte” shall be added, followed by a space, followed by the content from the <event> element. For all other languages including English, the content from <event> will be added, followed by a space, followed by the phrase “Alert”. Regardless of the language, a section delimiter is appended to complete this step.
  • 2.2.6. The <areaDesc> elements from each of the <area> elements will be concatenated, using a comma and a space between each, in the order in which they appear. After the final description, instead of the comma and space, a section delimiter shall be added. This string of area descriptions will be added to the Audience Alert Message.
  • 2.2.7. If the <info> element contains an <instruction> element, this element's content shall be added.
  • 2.2.8. French Composition Example: Alerte - <senderName> - Alerte <event> - <areaDesc> - <instruction>
  • 2.2.9. English Composition Example: Alert - <senderName> - <event> Alert - <areaDesc> - <instruction>
  • 2.2.10. The Audience Alert Message is now complete and any formatting changes can take place in preparation for presentation.
• 2.3. Formatting
  • 2.3.1. Whenever truncation takes place, such a deletion MUST be indicated by the use of an ellipsis using asterisks (***).
  • 2.3.2. Whitespace shall be normalized. Whitespace includes the space, new line, carriage return, and tab characters. Leading and trailing whitespace shall be removed. Where there are adjoining whitespace characters, they shall be collapsed into a single space character [ref.: 8.3.2.].

3. Audience Alert Audio

• 3.1. CAP Resource
  • 3.1.1. <info> elements should be evaluated in the order in which they appear in the CAP message [ref.: 8.9.1.]. The first <info> element which matches the appropriate criteria for use as defined by the LMD, such as language, importance, and location should be used to determine if a CAP resource is available [ref.: 8.9.2.].
  • 3.1.2. <resource> elements should be evaluated in the order in which they appear in the <info> element. The first <resource> element which matches the appropriate criteria as defined by the LMD should be used.
  • 3.1.3. A <resource> element with the <resourceDesc> element having a value of “Broadcast Audio” shall indicate that the <resource> element contains Audience Alert Audio. This value is not case sensitive, must have no further text or white space added, and shall be used for all languages. For public presentation by the LMD of the <resourceDesc> in languages other than English, such as on a website, the LMD system can optionally perform its own translation of this value.
  • 3.1.4. If Audience Alert Audio is contained in the <resource> element, the <mimeType> element shall be evaluated by the LMD. At a minimum, LMDs must support receiving audio of type “audio/mpeg” in the MP3 format as described in the CLF [ref.: 8.14.3.].
  • 3.1.5. Additional audio types may be present in the <info> element, to support additional formats such as uncompressed or streaming audio, in additional <resource> elements that an LMD may optionally elect to use instead of MP3 [ref.: 8.14.3.1.]. A <resource> element with MP3 audio shall be present as a default if additional audio types are also present. Only one audio type should be used by the LMD as the Audience Alert Audio for presentation.
  • 3.1.6. If a suitable <resource> element is found and the LMD is capable of downloading, the audio file shall be downloaded by the LMD using the value from the <uri> element. If this file cannot be downloaded within one minute, the LMD may elect to use the TTS method of generating the Audience Alert Audio. If the LMD is not capable of downloading, the TTS method should be used immediately. LMDs may optionally attempt to retry a failed audio file download however any retry attempts should not unduly delay the presentation of the alert to the public [ref.: 8.13.3.]. LMDs should not attempt to use <uri> values from other <resource> elements.
  • 3.1.7. LMDs must support downloading audio files using the <uri> element. Support of the <derefURI> by LMDs is optional. If a <resource> element contains both <uri> and <derefURI> elements, the <uri> element should be considered the primary value. If the <uri> value fails to download, or the LMD has no ability to download the <uri>, the <derefURI> should be used as the secondary value.
• 3.2. Text to Speech (TTS)
  • 3.2.1. If the “CAP Resource” method cannot provide suitable Audience Alert Audio, this TTS method should be used. If TTS is not available then the manual method referenced in 8.14.6 should be followed.
  • 3.2.2. The Audience Alert Message shall be generated using the defined method. This text content shall be used by the LMD's TTS engine to generate the Audience Alert Audio.
  • 3.2.3. It is recommended that the LMD support a lexicon of place names, however this is optional.
  • 3.2.4. All applicable CLF guidance on Audience Alert Audio, such as length, shall also be followed when TTS generation is used.
  • 3.2.5. LMDs can optionally modify the text content used by the TTS engine in order to improve the conversion process. This could include expanding any acronyms, adding additional breaks or pauses, etc. This modified content should only be used by the TTS engine and should not be used for visual presentation.

Date modified:

2018-03-29