Objective and Source

Preliminary analysis of file size constraints for Common Alerting Protocol (CAP) public alert messages in Canada

Objective and Source

In January 2012 Public Safety Canada (PS) requested the Centre for Security Science (CSS) research file size limits defined for “public” alerts using the Common Alerting Protocol (CAP) standard [[1]] and, if limits were deemed to be necessary for technical reasons, to recommend specific limits. This Technical Advisory Note (TAN) provides a summary of study findings addressing this question and also offers related recommendations on best practices for CAP file attachments.

Emergency Management Systems and Interoperability is a mission area of CSS. CSS provides scientific and technical support to public safety stakeholders at all levels of government in Canada. CSS operates under a Memorandum of Understanding between Public Safety Canada and Defence R&D Canada within the Department of National Defence, Government of Canada.

Background, Study Method and Participants

On December 30 2011 the Pelmorex National Alert Aggregation and Dissemination System (NAADS) Governance Council relaxed a one megabyte (MB) CAP file size limitation that was regarded as too restrictive for some stakeholders. The Council also encouraged a more formal study of the matter be conducted with the aim of identifying and reviewing CAP file size constraints imposed in other CAP systems around the world.

The study concerned public alerting specifically, addressing only the dissemination of alert information after a decision is made to warn the public. Such public dissemination involves a complex mix of systems, business processes and technologies, with alerts ultimately reaching the public through last mile distributors (LMDs). The study focused on how dissemination is affected by the size of the alert information, and some low bandwidth and latency issues that require attention. Related constraint and best practice issues were included for future study and consideration.

As noted above, PS requested CSS conduct the study. Fortunately, CSS had a number of the world’s leading CAP experts under contract at the time, including Elysa Jones, chair of the OASIS Emergency Management Technical Committee that oversees CAP. She was named the project lead, and received support from experts and stakeholders (identified below), including Eliot Christian, recently retired of the World Meteorological Organization (WMO), where he hosted worldwide CAP Implementation Workshops.

The study team was charged to collect information from stakeholders on the alerting implications of file size limits. Based on this information, and on their expert judgement and knowledge of business processes and technology (including hardware, software, and reformatting capacities), inferences would be drawn and recommendations were to be provided. These were to consider the impact of various file size limits on alert originators and alert receivers/distributors, and on the quality and type of alerting content.

An Interview Form including background information on the issue of CAP file size constraints was developed and emailed to over 100 experts and stakeholders (copy of that form is an Attachment here). Most of the 37 respondents were then interviewed via telephone. A summary of the compiled responses was used as the basis for this TAN.

The following organizations responded to the Interview Form: Alberta Emergency Management Agency, Anguilla Department of Disaster Management, CAPAN, CSS Multi-Agency Situational Awareness System (MASAS), Cellcast UK Limited, ComLabs, Earth Networks, Emergency Management British Columbia, Environment Canada, EUMETSAT, German Weather Service, Google, Intelligence for Environment & Security, International Telecommunication Union, MITRE, My State USA, Nordic Geospatial, the OASIS Emergency Management Technical Committee, Pelmorex Media Incorporated, Sage Alerting Systems, Saskatchewan Emergency Management Organization, Swan Island Networks, TFT Incorporated, UK MetOffice, US Geological Survey, US Integrated Public Alert and Warning System, US National Weather Service, Washington State, Videotron, and the World Meteorological Organization. Three independent experts also responded to the Interview Form.

General Observations

The Role of CAP - Increasingly, public alert information is being represented in CAP, which standardizes the format of alert information. Use of the CAP format simplifies automated routing and enables other processing of alert information. For instance, a CAP alert typically includes coded information about: the type of an event; the urgency, severity, and certainty; the affected area; and the onset time and duration. These coded values are useful for automated decisions on whether and where to distribute the alert. However, CAP is not yet a commonly supported format among consumer devices such as phones, radios, and television sets. Accordingly, a last mile distributor receiving alert information in CAP format would typically convert it for presentation to the public. For example, a television station's CAP equipment may be setup to insert "crawl text" that is seen by its viewers; a radio station would need to convert text to audio (if not already included as attachment) so as to broadcast audio to get the message out to its listeners; a cellular phone service may choose to send a short text message to its users; other distributors turn the alert information into pager messages, e-mail notes, or Fax messages; and still others may process the alert information to trigger sirens.

Interactive and Non-Interactive Media - A fundamental distinction between two types of media is necessary when considering file size constraints in the distribution of public alert messages. With "interactive media", message recipients are able to access referenced information sources external to the message. With "non-interactive media", message recipients have very limited or no ability to access referenced information sources that are external to the message. Traditional radio, television, and Fax transmissions are typical of non-interactive media, while e-mail and Internet transmissions are typical of interactive media.

Audio for Non-interactive Media - The provision of audio alert messages over non-interactive media entails particular challenges for distributors because audio is vastly larger than its corresponding text. An EAS audio alert message cannot be longer than two minutes, and this long-standing constraint is built into the existing hardware as well as relevant standards. This audio alert message must be of a quality to assure intelligibility. Even with compression, such audio files can be megabytes in size, which is likely the largest files a typical alert distributor needs to handle. Accordingly, audio files ought to be transmitted only to those distributors who must have them. Also, when alerts are in multiple languages the audio files should be packaged so that distributors get only those audio files they actually need to broadcast.

Several Factors Determine Size - In addition to the packaging of multiple languages in a single alert message, the message file size can be affected by other factors. For instance, geographic coordinates can add to the size. Also, packaging multiple warning areas into a single message would multiply the alert message size. This is a key file size constraint for complex multi-area weather alerts for example.

Effects of Size Vary by Distributor - Last mile distributors can have very different characteristics with regard to the telecommunications resources available and the variety of communications paths (depending on infrastructure) that are likely to reach the local populace. Remote areas are typically underserved in these respects, as are areas that may be economically challenged.

Other Types of Constraints - Although this TAN focuses on the size of alert messages, other types of constraints come into play as well. For instance, there may be policy constraints on linking to particular external sites or "streaming" resources. There may be practical constraints that no unusual formats are used and that the processing time of any single alert be seconds or less. Some systems may have constraints as to the versions of standards supported, and may also constrain certain alert message elements (e.g., number of polygons, polygon points, geographic codes, "info blocks", linked resources). Another practical constraint may be that certain distributors are not equipped or staffed to deal with unusual methods of distributing messages.

EAS Crawl Text Constraint - SCTE 18, the Emergency Alert Messaging standard [[2]], is published by the Society of Cable Telecommunications Engineers (SCTE). This standard, and SCTE DVS-168 for TCIP/IP implementations, defines how cable TV systems signal emergencies to digital receiving devices such as digital Set-top Boxes, digital TV receivers and digital video recorders. In accord with SCTE 18, the Emergency Alert System (EAS) "crawl text" for public alert messages should not exceed 1800 characters (~2 KB). Within this limit must be accounted any delay of the message display and having the message in multiple languages.

Cellular Mobile Alerting Constraint - A Cellular Mobile Alert Message (a term used in the U.S. EAS context) is limited to 90 characters due to current, second generation technology constraints. However, third and fourth generation mobile multicast technology will be able to send multi-media (including video) and will leverage IPv6 capabilities so this restriction may change in the future.

File Size Findings and Recommendations

The following table summarizes various size constraints reported by study respondents.

a. File Size Effects

a. 1. Finding - Size Impacts Delivery - Strict restrictions on file size could impede the objective to properly inform, given that many service providers would reject outright any public alert message that is oversize. Some involved in alert delivery are concerned that larger file sizes for public alert messages could impact the prompt delivery of alerts. Aspecific assertion is that they could not provide efficient or effective service if alerts were to contain text in excess of 1800 characters (~2KB) or audio in excess of two minutes.

a. 2. Finding - File Size and WMO GTS - Some connections within the widely-used WMO Global Telecommunication System (GTS) operate at only 16 Kbps, which implies that about 200 KB could be sent in two minutes. However, GTS regulations impose a limit of 15 KB. GTS regulations are legal requirements as part of the WMO Technical Regulations, a treaty-level international agreement among the 183 Member nations of the WMO. This means that only warnings up to 15 KB can be exchanged between the WMO GTS and Canadian alerting systems.

a. 3. Finding - File Size and H.323 - ITU-T Recommendation H.323, Packet-based Multimedia Communications Systems, is a multimedia conferencing protocol for voice, video, and data conferencing over packet-switched networks ("multimedia over IP"). With H.323, users can work side by side on a document using voice, video, text, and application sharing technologies. CAP messages up to about 63K can be carried inside of an H.323 message. However, actually deployed H.323 routing elements such as Gatekeepers may further limit the size of messages.

a. 4. Finding - File Size and SIP - Session Initiation Protocol (SIP), defined by IETF RFC 3261, can be used for voice, video, instant messaging, gaming, etc. SIP is an application-layer control protocol for creating, modifying and terminating sessions with one or more participants within a telecommunications network. SIP requests can carry CAP content, but only if it is smaller than 256 KB.

a. 5. Finding - File Size and XMPP - There is practically no limit to the size of CAP messages in eXtensible Markup Language (XML) accessible to instant messaging users via the Extensible Messaging and Presence Protocol (XMPP). XMPP is an open technology for real-time applications including instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalized routing of XML data.

a. 6. Finding - Upload Constraints - The bandwidth available for uploading of alert messages intended for public distribution can impose a file size constraint, given that the sending process cannot be prolonged. For instance, to upload a CAP alert via a common satellite uplink in two minutes implies that the message not exceed 100 KB.

a. 7. Finding - Downstream Constraints - Small messages (perhaps up to a few KB) are often necessary in systems that disseminate alerts to many thousands of users. In a typical design, clients poll alerting servers for alerts and deliver a small header message giving just the essential information, with subsequent download of the full message available when called upon. This aligns with cellular Short Message Service, iPhone, Blackberry, and other distribution networks emphasizing small message sizes.

a. 8. Finding - File Size and Polygon Points - The number of polygon points in an alert message can greatly impact the file size constraint. The US Commercial Mobile Alert System (CMAS) imposes a limitation of 100 polygon points. It is well understood that this is an issue in Canada and efforts are underway to reduce CAP Canadian Profile (CAP-CP) location reference polygon sizes. It is also understood that a single polygon for a CAP alert info block representing an area of multiple polygons could also be used to reduce the file size.

a. 9. Recommendation - Warn Originator of Oversize Message - The originator of an alert should be advised if the intended distribution has a constraint on the message size, especially so that a life-critical message would not be blocked or truncated for exceeding the size constraint. This warning could be part of a form fill-in or similar process that accepts alert messages from an originator.

b. Multiple Languages

b. 1. Finding - Multiple Language Constraints - Having alert messages in multiple languages is a legal requirement in some places. This further constrains the alerting methods and file size. For instance, some current EAS technology only looks at the first "info block" of a CAP message, although a second info block might have English/French alternate language text.