Contents

• Summary
• EAS-CAP Profile Recommendation: Bibliographic Information
• Excerpts from the EAS-CAP Profile Recommendation
• From the ECIG Announcement
• About the FCC Emergency Alert System (EAS)
• ECIG Member Companies and Organizations
• About the EAS-CAP Industry Group (ECIG)
• About the Common Alerting Protocol (CAP)
• Principal References

Members of the EAS-CAP Industry Group (ECIG) have announced the release of initial draft text for EAS-CAP Industry Group EAS-CAP Profile Recommendation EAS-CAP-0.1 with an invititation for public comment. The Common Alerting Protocol (CAP) specification was approved as an OASIS Standard in October 2005 and as an ITU-T Recommendation X.1303 in 2007-09.

CAP is a "simple but general format for exchanging all-hazard emergency alerts and public warnings over all kinds of networks. It allows a consistent warning message to be disseminated simultaneously over many different warning systems, thus increasing warning effectiveness while simplifying the warning task. CAP also facilitates the detection of emerging patterns in local warnings of various kinds, such as might indicate an undetected hazard or hostile act."

The CAP standard has now been implemented by dozens of companies, agencies and organizations. On July 30, 2008, the U.S. Department of Homeland Security's Federal Emergency Management Agency (FEMA) announced its intention to adopt an alerting protocol in line with CAP Version 1.1 as the standard for the Integrated Public Alert and Warnings System (IPAWS), during the first quarter of calendar year 2009. IPAWS is a network of alert systems through which FEMA is upgrading the existing Emergency Alert System (EAS).

The EAS-CAP Industry Group was formed as a broad coalition of equipment, software and service providers in response to a July 2007 decision by the Federal Communications Commission (FCC) to maintain EAS and have all U.S. EAS participants adopt an ability to receive messages using the Common Alerting Protocol (CAP) within 180 days after FEMA formally adopts CAP version 1.1 as a standard for EAS.

Members of EAS-CAP Industry Group believe "the integration of this EAS-CAP profile into existing and planned systems will lay a foundation for migration to an upcoming FEMA CAP profile. Prior to the formation of the EAS-CAP Industry Group, numerous progressive companies were already involved in CAP messaging for EAS. However, each vendor used its own method for transporting the EAS parameters within a CAP message, raising the potential challenge of various EAS equipment and systems not being able to communicate with each other. The advent of this EAS-CAP profile will provide the basis for interoperability both among next generation EAS equipment and services, as well as between the EAS community and other communications channels."

ECIG is providing the profile "as a recommendation to U.S. governmental agencies and industry associations on the use of CAP for EAS purposes, including the FCC, FEMA, National Weather Service, and other organizations. Group members intend to rapidly implement the EAS-CAP profile within their own systems and equipment. The profile will be an important step towards improving interoperability across agencies, jurisdictions, systems, and vendors, helping to ensure that the public benefits from improved capabilities to communicate weather, civil, AMBER, and other alerts via broadcast media."

The draft Profile is based upon the CAP standard and FCC EAS Rules. "Public warnings intended for transmission over the Emergency Alert System (EAS) can be encoded in Common Alerting Protocol (CAP) messages in various ways. The EAS-CAP Profile represents a consensus among EAS equipment manufacturers and warning practitioners regarding a single recommended pattern for compatible encoding."

According to the published ECIG FAQ document, "The Industry Group is currently developing Test Vectors for all vendors to use in testing their devices on an individual basis, but no live device-to-device testing is planned at this time. We feel that each vendor using the individual tests within the Test Vector suite to be certain that their device reacts properly to each test will result in adequate compatibility testing... The purpose of the group is solely to develop technical standards to promote interoperability among EAS vendors in the context of the CAP 1.1 Standard. Issues of price, availability, and other marketing and sales questions are outside the scope of the group..."

EAS-CAP Profile Recommendation: Bibliographic Information

EAS-CAP Industry Group EAS-CAP Profile Recommendation EAS-CAP-0.1. Produced by members of the EAS-CAP Industry Group. September 25, 2008. 27 pages. Copyright © 2008 EAS-CAP Industry Group. Includes: Appendix A: "Membership of the EAS-CAP Industry Group"; Appendix B: "CAP-V1.1 to EAS Validation Criteria"; "CAP to EAS Validation Table." Send comment to: comment@eas-cap.org. See the EAS-CAP Profile reference document for instructions on providing feedback. Extent: 586952 bytes (MD5 Checksum: 87a14fb01959493482f8322855e22c46). [cache]

Abstract: "Public warnings intended for transmission over the Emergency Alert System (EAS) can be encoded in Common Alerting Protocol (CAP) messages in various ways. A consensus among EAS equipment manufacturers and warning practitioners regarding a single recommended pattern for compatible encoding — the EAS-CAP Profile — is documented along with related recommendations.

Excerpts from the EAS-CAP Profile Recommendation

The following excerpts are adapted from the EAS-CAP Profile Recommendation EAS-CAP-0.1

From Section II, (EAS-CAP Industry Group Participants and Activities): "In May, 2008 an ad-hoc Industry Group of EAS equipment manufacturers and other interested parties convened for the purpose of facilitating the incorporation of the Common Alerting Protocol version 1.1 into the national Emergency Alert System (EAS) by devising a workable EAS-CAP Profile and associated technical and procedural recommendations. The Industry Group conducted an initial telephone conference call and thereafter utilized an online forum for the discussion of issues and the drafting of this document.

From Section IV, (Definitions): An EAS-CAP Profile Decoder is "a device or software application that performs one or more of the following tasks: (1) Using the EAS-CAP Profile, converts a CAP alert into the CFR 47 Part 11 Emergency Alert System (EAS) format, commonly referred to as the ZCZC string; (2) Using the EAS-CAP Profile, converts a CAP alert into a text string intended for display as video, or input into a Text to Speech converter, or as input for any other text display; and used in conjunction with an EAS alert.

From Section VI, (Discussion of items omitted or included in the Profile):

• A. Included: for rendering of both text-to-speech and video display of EAS alerts from CAP messages, a method to announce and display [...] useful and specific information derived from the CAP message elements that can be used as part of the EAS alert broadcast [rather than generic information derived from the EAS Header Code]
• B. Included: both a proprietary and non-proprietary audio format for use with attached audio files. While the non-proprietary WAV PCM audio files are free of any licensing fees, they will be significantly larger in file size than the proprietary, licensed-format MP3 files. This gives the individual CAP network architects the option to choose between low cost or low file size.
• C. Not included: methods to originate and render CAP alerts using additional languages for EAS alert use; await forthcoming decisions by the FCC
• D. Not included: recommended default values for the CAP Urgency, Severity, and Certainty element values corresponding to each EAS Event Code; leave this to system vendors and clients
• E. Not included: definition of requirement for text-to-speech technology in an EAS-CAP Profile Decoder

From Section VII, (EAS-CAP Profile) Best practices which must be observed when encoding CAP messages intended for EAS broadcast... [see the Profile document for details]

From Section VIII, (CAP Message Processing for EAS)

A. One of the main purposes of this Profile is to ensure that CAP messages are rendered in EAS such that duplicate messages can be detected once the message is forwarded in the EAS domain. This means that for a given CAP message, all vendors must emit the exact same CFR 47 Part 11 "ZCZC" string. All characters, starting with the ZCZC header and ending with the hyphen before the LLLLLLLL field, must be identical.

B. Further, the Profile defines the content of the text string used as input to a Text-To-Speech element, or to a video character generator element. While there may be some local user and vendor customization, the intent here is that the generated audio and video is as similar as possible between EAS vendors. This intentional consistency among vendors allows CAP origination software to offer its users a reliable "preview" of what an EAS alert will look and sound like on air, regardless of which vendors equipment is used at the receiving end.

From Section IX, EAS Relay Network Security: While the EAS-CAP Industry Group does not propose to specify relay network or networks for EAS, it does make the following recommendations regarding EAS network security... Section 3.3.2.1 of the OASIS CAP 1.1 Specification includes the W3C recommendation for Digital Signatures and specifies an "enveloped" digital signature as the preferred mechanism for ensuring CAP message authenticity and integrity. The Industry Group recommends the implementation of this technique. This recommendation is not meant to preclude the use of additional methods for encryption and authentication within EAS Relay Networks...

From Appendix B CAP-V1.1 to EAS Validation Criteria: Incoming CAP-V1.1 messages SHALL be subjected to a validation step prior to acceptance for translation to an FCC Part 11 EAS alert. The purpose of this step is to determine whether or not to continue the translation based upon basic syntax and semantic requirements. It is recommended that the EAS-CAP Profile Decoder log any useful information about message validation. This step does not address message authentication. The source will be trusted based upon other authentication steps taken in a different layer of the communication.

Validation Philosophy: In this document we discuss the rules for validation of EAS-CAP Profile messages. There are also assumed rules for basic CAP validation. As of this writing, the "conformance rules" are not part of the CAP 1.1 Specification. There may be conformance rules that are being generated as part of future type acceptance of CAP 1.1 devices. This EAS-CAP Industry Group has wrestled with the issue of strict adherence to the CAP schema versus the potential rejection of a valid alert due to a trivial formatting error. We do not further address the issue of CAP conformance here, other than to say that if there are rules for CAP conformance that affect certification of EAS-CAP devices, then validation based on those rules will be performed first.

Error Signaling Philosophy: We realize that EAS-CAP is a part of the larger CAP community, and that messages that are in error for EAS renderers are not necessarily errors to the CAP community. Therefore, we have taken the following approach: if a message has an error that would be an error to any CAP receiver, we signal an error. If the message is in error only to an EAS-CAP Profile Decoder, we signal acceptance of the message, but do not act on it. Our intent is that the CAP community is not subjected to what they would consider to be erroneous Error messages.

Validation Overview: The CAP-to-EAS message validation procedure described below details the minimum requirements to enforce basic message verification. Specifically, the purpose of this validation step is to: (1) reject improperly formatted, improperly constructed, or damaged CAP messages. (2) ignore messages that do not contain sufficient information for the generation of a unique EAS message. (3) ignore CAP messages that are not intended for EAS translation. Once a CAP message passes the validation step, it may be subjected to an additional set of filters that will decide if a particular alert is to be placed on the air by a particular user...

CAP Required Elements: In the EAS-CAP Profile, we do not require that all CAP-required elements be present. We assume that a processing element in the chain before the EAS-CAP Profile Decoder has verified the format of the alert, and that the authentication scheme has delivered an intact message to the EAS-CAP Profile Decoder.

EAS-CAP Required Elements: "In order to translate a CAP message into an EAS message, another set of optional CAP elements are required. These elements have been defined in the EAS-CAP Profile in order to guarantee consistent translation into an EAS message. These elements of the CAP message are not necessarily required as elements in CAP, but are required by EAS. Some elements are required for proper translation into an EAS message, and thus are included in a specific minimum set of EAS-CAP required elements. Other elements may be considered of lesser importance. Some of these elements will have defined default values..."

From the ECIG Announcement

September 25, 2008.

The EAS-CAP Industry Group (ECIG) — a broad coalition of equipment, software, and service providers to the Emergency Alert System — today announced that its members have released a draft profile for the effective use and translation of the open, non-proprietary Common Alerting Protocol (CAP)* for the next generation of broadcast EAS.

The profile will be an important step towards improving interoperability across agencies, jurisdictions, systems, and vendors, helping to ensure that the public benefits from improved capabilities to communicate weather, civil, AMBER, and other alerts via broadcast media.

The Industry Group will provide this profile as a recommendation to U.S. governmental agencies and industry associations on the use of CAP for EAS purposes, including the FCC, FEMA, National Weather Service, and other organizations. Group members intend to rapidly implement the EAS-CAP profile within their own systems and equipment.

The EAS-CAP profile provides developers and manufacturers guidelines as to which elements in a CAP message are required for an EAS message, identifies how a mandatory alert from a state/territorial Governor would be identified, describes basic authentication and security features, recommends accepted formats for audio messages, and other features.

The output of the Group's work is publicly accessible on its website www.eas-cap.org, and the Group will offer a mechanism for public comment on that site. The Group plans to continue its work to solicit feedback and provide recommendations to EAS stakeholders.

Background

The EAS-CAP Industry Group was established in response to the July 2007 decision by the U.S. Federal Communications Commission (FCC) to maintain EAS and have all U.S. EAS participants adopt an ability to receive messages using the Common Alerting Protocol (CAP) within 180 days after the Federal Emergency Management Agency (FEMA) formally adopts CAP version 1.1 as a standard for EAS.** FEMA's announcement on CAP adoption is expected in the first quarter of 2009.

The Common Alerting Protocol (CAP) is a simple but general format for exchanging all-hazard emergency alerts and public warnings over all kinds of networks. CAP allows a consistent warning message to be disseminated simultaneously over many different warning systems, such as computers, wireless communications, alarms, and television radio and cable via broadcast EAS.

Industry Group Support

Group members [see details] supporting the EAS-CAP Profile include:

• Digital Alert Systems, LLC
• Hormann America, Inc.
• iBiquity Digital Corporation
• Monroe Electronics, Inc.
• MyStateUSA
• Sage Alerting Systems, Inc.
• SpectraRep, LLC
• TFT, Inc.
• Trilithic, Inc.
• Warning Systems, Inc.

Additional Information

For more information about the EAS-CAP Industry Group and its EAS-CAP Profile, visit http://www.eas-cap.org.

For more information about the EAS, visit the FCC's Public Safety & Homeland Security Bureau http://www.fcc.gov/pshs/eas/.

For more information about the FCC's Report and Order on CAP, visit http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-07-109A1.pdf.

About the EAS-CAP Industry Group

The EAS-CAP Industry Group (ECIG) is an informal coalition of Emergency Alert System equipment, software and service providers. Using the best available information, the EAS-CAP Industry Group has collaborated to develop a voluntary profile for the interoperability of advanced Emergency Alert System (EAS) capabilities in the United States using the Common Alerting Protocol (CAP). Specifically, the Industry Group collaborated to coordinate interoperable data standards among Emergency Alert System equipment, software and service providers. Further, the Industry Group will seek to provide recommendations to U.S. governmental agencies and industry associations on the use of CAP for EAS purposes.

The EAS-CAP Industry Group's intention is to offer an interoperable EAS-CAP data profile that is a freely available resource for EAS participants, equipment, software and service providers, to the benefit of public alert and warning capabilities throughout the United States. It is the intention of the Industry Group that any work product of the group be free of copyright and intellectual property constraints.

* The Common Alerting Protocol v1.1 was developed by the Organization for the Advancement of Structured Information Standards (OASIS), a non-profit, international consortium that develops standards.

** Review of the Emergency Alert System, Second Report and Order and Further Notice of Proposed Rulemaking, 22 FCC Rcd. 13275 (2007), EB Docket No. 04-296 (Second EAS Report and Order).

About the FCC Emergency Alert System (EAS)

The Emergency Alert System (EAS) is a U.S. national public warning system that requires broadcasters, cable television systems, wireless cable systems, satellite digital audio radio service (SDARS) providers and, direct broadcast satellite (DBS) service providers to provide the communications capability to the President to address the American public during a National emergency. The system also may be used by state and local authorities to deliver important emergency information such as AMBER alerts and weather information targeted to a specific area.

The FCC, in conjunction with Federal Emergency Management Agency (FEMA) and the National Oceanic and Atmospheric Administration's National Weather Service (NWS), implement EAS at the federal level. The President has sole responsibility for determining when the EAS will be activated at the national level, and has delegated this authority to the director of FEMA. FEMA is responsible for implementation of the national-level activation of EAS, tests, and exercises. The NWS develops emergency weather information to alert the public of imminent dangerous weather conditions.

The FCC's role includes prescribing rules that establish technical standards for EAS, procedures for EAS participants to follow in the event EAS is activated, and EAS testing protocols. Additionally, the FCC ensures that EAS state and local plans developed by industry conform to the FCC EAS rules and regulations.

[As of 2008-09], the FCC continued to implement its EAS responsibilities in an on-going rulemaking proceeding. In its July 12, 2007 Second Report and Order and Further Notice of Proposed Rulemaking issued in EB Docket 04-296, the FCC addressed various aspects of the current EAS and also explored necessary steps to advance the so-called 'Next Generation EAS.'

The Commission stated that a reliable "wide-reaching public alert and warning system is critical to public safety" and that the EAS network should permit "officials at the national, state and local levels to reach affected citizens in the most effective and efficient manner possible." Among actions taken by the Second Report and Order, the Commission ordered that all EAS Participants must be able to receive messages formatted pursuant to the Common Alert Protocol (CAP 1.1) within 180 days of the adoption of said protocol by FEMA. The Commission also allowed mandatory use of the EAS by a state governor following introduction of CAP, providing that the delivery and transmission of such messages is described in a state EAS plan that is reviewed by the FCC...

Title 47: Telecommunication, Part 11: Emergency Alert System (EAS)

This part [Part 11] contains rules and regulations providing for an Emergency Alert System (EAS). The EAS provides the President with the capability to provide immediate communications and information to the general public at the National, State and Local Area levels during periods of national emergency. The rules in this part describe the required technical standards and operational procedures of the EAS for analog AM, FM, and TV broadcast stations, digital broadcast stations, analog cable systems, digital cable systems, wireline video systems, wireless cable systems, Direct Broadcast Satellite (DBS) services, Satellite Digital Audio Radio Service (SDARS), and other participating entities. The EAS may be used to provide the heads of State and local government, or their designated representatives, with a means of emergency communication with the public in their State or Local Area...

[11.11] "(a) The EAS is composed of analog radio broadcast stations including AM, FM, and Low-power FM (LPFM) stations; digital audio broadcasting (DAB) stations, including digital AM, FM, and Low-power FM stations; analog television broadcast stations including Class A television (CA) and Low-power TV (LPTV) stations; digital television (DTV) broadcast stations, including digital CA and digital LPTV stations; analog cable systems; digital cable systems which are defined for purposes of this part only as the portion of a cable system that delivers channels in digital format to subscribers at the input of a Unidirectional Digital Cable Product or other navigation device; wireline video systems; wireless cable systems which may consist of Broadband Radio Service (BRS), or Educational Broadband Service (EBS) stations; DBS services, as defined in 47 CFR 25.701(a) (including certain Ku-band Fixed-Satellite Service Direct to Home providers); SDARS, as defined in 47 CFR 25.201; participating broadcast networks, cable networks and program suppliers; and other entities and industries operating on an organized basis during emergencies at the National, State and local levels. These entities are referred to collectively as EAS Participants in this part, and are subject to this part, except as otherwise provided herein. At a minimum EAS Participants must use a common EAS protocol, as defined in '11.31, to send and receive emergency alerts..."

[See also the e-CFR (Electronic Code of Federal Regulations) Definitions for: (1) CAP: Common Alerting Protocol. The Common Alerting Protocol (CAP) refers to Organization for the Advancement of Structured Information Standards (OASIS) Standard CAP V1.1, October 2005, or any subsequent version of CAP adopted by OASIS and implemented by the CMAS; (2) Alert Message: An Alert Message is a message that is intended to provide the recipient information regarding an emergency, and that meets the requirements for transmission by a Participating Commercial Mobile Service Provider; (3) Commercial Mobile Alert System (CMAS) - refers to the voluntary emergency alerting system whereby Commercial Mobile Service Providers may elect to transmit Alert Messages to the public; (4) Commercial Mobile Service Provider (or CMS Provider) is an FCC licensee providing commercial mobile service ... that is provided for profit and makes interconnected service available to the public or to such classes of eligible users as to be effectively available to a substantial portion of the public, as specified by regulation by the Commission..."]

Next Generation EAS Summit: The Federal Communications Commission's Public Safety and Homeland Security Bureau hosted a Summit on "Next Generation EAS", addressing the U.S. Emergency Alert System (EAS): The Making of a Robust, Next Generation Emergency Information Highway [or: Promoting an Effective Emergency Alert System on the Road to a Next Generation EAS], on Monday, May 19, 2008. See the Summary of EAS Summit and Public Notice April 21, 2008 [cache]. Summary excerpt:

"[...] The second panel focused on next generation technologies and explored what policies and protocols should be implemented to ensure compatibility between Federal implementation of the Common Alert Protocol (CAP) architecture and state government operations. Panel Two was hosted by PSHSB Chief Engineer Bill Lane. Panelists included Ms. Malena Barzilai, Senior Counsel for the Association of Public Broadcasters; Mr. Art Botterell, developer of the Common Alerting Protocol (CAP) and Manager of the Contra Costa County, California, Community Warning System; Mr. Lance Craver, Program Director of FEMA's Integrated Public Alert and Warning System (IPAWS); Mr. Clay Freinwald, from Entercom, Inc. and Chair of the EAS Committee of the Society of Broadcast Engineers; Mr. Craig Hodan, National Oceanic and Atmospheric Administration; and Ms. Suzanne Goucher, President and CEO of the Maine Association of Broadcasters...

Panelists expressed that industry and broadcasters were anxious to begin the implementation of CAP and were awaiting release and designation of the appropriate CAP protocols by the Department of Homeland Security, Federal Emergency Management Agency. In addition to re-emphasizing the need for CAP training and Federal funding for the next generation EAS, panelists urged the Federal government to assume a leadership role in defining the system architecture, establishing the CAP guidelines, and allowing industry to development the system implementation. A number of other peripheral issues were also discussed including administration of the system, authentication and verification issues for state and local emergency injects into the system, targeting of specific messages, testing programs, and equipment certification..."

ECIG Member Companies and Organizations

The EAS-CAP Industry Group core founding members include voting participants, non-voting participants, and (by invitation) observer stakeholders from selected Federal, state and local departments/agencies, as well as a number of industrial trade groups. Non-voting participants in the include the Technical Advisor (Art Botterell, of Contra Costa County California Sheriff's Office) and Facilitator (Gary E. Timm, Broadcast Chair, Wisconsin EAS Committee [SECC], and Member of Society of Broadcast Engineers [SBE] EAS Committee). Individuals contributing to the initial draft Profile are listed in Appendix A ('Membership of the EAS-CAP Industry Group') of the EAS-CAP Industry Group EAS-CAP Profile Recommendation EAS-CAP-0.1.

Individuals contributing to EAS-CAP-0.1 include: Digital Alert Systems, LLC (Bruce Robertson, Tom Wood); Hormann America, Inc. (Efraim Petel, Tomer Petel); iBiquity Digital Corporation (Marek Milbar); Monroe Electronics, Inc. (Jim Heminway, Jon Rue); MyStateUSA (Claudia Bittner, Matt Farlow); Sage Alerting Systems, Inc. (Harold Price, Jerry LeBow); SpectraRep, LLC (Adam Cranson, Ed Czarnecki, Jim Mattix, Rick Ducey, Rodney Herrmann); TFT, Inc. (Darryl Parker), Trilithic, Inc. (Allen Studer, Art Leisey, Mike Maginty); Warning Systems Inc. (Elysa Jones, Jeff Kyser, Tom Fahy).

ECIG Voting Participants

• Digital Alert Systems. "The founders of Digital Alert Systems have been involved in EAS/EBS since 1990. Digital Alert Systems, LLC was formed October 2003 following a discussion of how present IP based technologies could improve the cost and operation of the legacy FCC part 11 EAS encoder/decoders, and provide more effective emergency communications in the future. Three EAS considerations became obvious in 2003. First, the requirement for EAS was expanding in scope, not shrinking; second, there was an industry wide need for technological improvement; and third, computer technology was available to build a better IP compatible Encoder/Decoder platform meeting legacy EAS requirements while being compatible with developing IP infrastructure like CAP, IPAWS, HazCollect, and DEAS. Investigation demonstrated that new generation hardware and software programming could produce a greatly improved, cost-effective product for the Emergency Alert System. The DASDEC EAS Encoder/Decoder was the result..."

• Hormann America. "Hormann America builds integrated public alert and warning systems based upon the international standard Common Alerting Protocol. Our customers include the States of California, New York, and Hawaii, the award-winning Community Warning System in Contra Costa County, and other installations around the world.. The AlertNET CAP Server is the heart of most Hormann America installations. Its primary task is hosting message creation tools, serving as a message repository, and handling message processing and distribution. The server can also be used to provide a single user interface that ties together multiple warning systems, such as sirens, email, and outbound telephone..."

• iBiquity Digital Corporation "iBiquity Digital Corporation is the developer of the HD Radio system. This technology allows AM and FM stations to broadcast digital signals in tandem with their analog signals, providing broadcasters with a platform to offer crystal-clear, CD-quality sound and scrolling text and graphics; as well as multiple channels of programming on the same FM frequency (multicasting) and advanced services such as traffic updates; content — all subscription free... We are actively engaged with broadcasters; receiver, component and broadcast equipment manufacturers; automotive manufacturers; and retailers in the United States and around the world to ensure swift and successful adoption of HD Radio technology... iBiquity Digital has 130 employees spread across three offices in Columbia, Maryland (corporate headquarters), Basking Ridge, New Jersey, and Pontiac, Michigan.

• Monroe Electronics. Monroe Electronics currently "offers a complete line of electrostatic measuring instruments including electrostatic voltmeters, electrostatic fieldmeters, coulomb meters and resistivity meters through a world wide group of distributors and representatives. In recent years we've developed an EAS system that has been widely accepted in the CATV market. We continue to apply our techniques in the Broadcast Radio and Television markets as well as security and process control markets... Monroe's One-Net is a fully configurable EAS Encoder/Decoder. The One-Net will interface with most existing analog EAS systems and can be enabled to meet the new digital EAS requirements. Optional internal MPEG2 Encoder with streaming EAS message for Simulcast interface with Decoder/Upconverter. In addition to a full range of inputs and outputs, the One-Net can hold up to 3 internal AM/FM/NOAA radios. An almost unlimited number of EAS events can be stored in the memory with all the needed details, including the audio."

• MyStateUSA. "MyStateUSA is a unique system oriented to providing secure, mass information sharing that gets information into the right hands securely and quickly. AlertSense from MyStateUSA is an interoperable alerting and communication system that provides a secure and immediate solution for emergency messaging and public outreach. Interoperability is how software communicates with other software without any special effort on either side. AlertSense does this by using standard compliant formats such as CAP and Web Services. The Common Alerting Protocol (CAP) is an open, standards interchange format that can send or collect data in regards to all types of emergency warnings. CAP standards allows reports on a local, regional and national level to receive and deliver information on a wide range of information-management and warning dissemination systems. The AlertSense system adheres to the CAP standards. AlertSense offers interoperable technology that can disseminate information to multiple recipients in a variety of formats: internal and external alerts, warning systems, phones, email, text messages, faxes, sirens, Emergency Alert Systems (EAS) and more. All while simultaneously posting information for authorized parties to public websites or secure public safety systems...

• Sage Alerting Systems. "Sage Alerting Systems, Inc., 'Developers of the new CAP Compliant Digital ENDEC' "will continue its legacy of innovation and excellence in the Emergency Alert System development and implementation. The original Sage ENDEC led the way in ease of use, reliability and functionality and meaningful features that allow broadcasters, cable operators and public safety agencies to get alerts out to the public in a rapid and predictable manner. Our mission is to bring our years of experience to the new CAP compliant FCC EAS requirements through the Sage Digital ENDEC... Sage Alerting Systems has provided Emergency Alert System (EAS) devices to Radio stations, other broadcast outlets, and emergency organizations since 1996. The classic Sage ENDEC is eclipsed by its new plug compatible "Digital ENDEC", adding AES/EBU audio, a LAN interface, and support for the new Common Alerting Protocol..."

• SpectraRep. "SpectraRep is a leading provider of solutions for the broadcast delivery of data over satellite, digital television and the Internet. SpectraRep is working with broadcasters around the country to deploy wireless datacast broadband services and applications for all-hazards emergency notification, emergency management, first responder and training applications. In addition to its work in public safety and homeland security, SpectraRep provides a range of services for distance education, digital signage and content delivery. SpectraRep announced its support of a draft profile for the effective use and translation of the open, non-proprietary Common Alerting Protocol (CAP) for the next generation of broadcast EAS, newly-released by the EAS-CAP Working Group. SpectraRep AlertManager is a patent-pending all-hazards emergency notification capability based on the latest version of the Common Alerting Protocol (CAP). The system is built as a network centric capability for government agencies, and provides secure multipath transmission via satellite, DTV data broadcast, and Internet networks. For broadcast EAS at television stations and cable head-ends, the system allows officials to generate text-crawls and audio broadcasts of messages in real-time to warn the general public. The system also provides a foundation for interoperability with other alerting systems, enabling authorities to deliver complete, consistent and coordinated warning messages to the public..."

• TFT. "TFT is an employee owned, privately held corporation with manufacturing, engineering, and administrative offices located at 1953 Concourse Drive, San Jose, California. TFT manufactures monitoring, STL (studio-transmitter-link), and EAS (Emergency Alert System) products for professional broadcast, emergency management, industrial and consumer applications. In Silicon Valley, we have access not only to a myriad of products and advanced service but also to a wealth of technology. The EAS 2008 CAP-to-EAS Converter continuously monitors a CAP ('Common Alerting Protocol') source to seek new emergency messages and generates an EAS protocol output for connection to existing FCC Type Certified EAS Encoder/Decoders. The unit actively polls a CAP server every few seconds for new emergency messages. Additionally the unit can receive a CAP message using Simple Object Access Protocol (SOAP). The Model 2008 provides the FCC mandated link between CAP and EAS. When connected to a TFT EAS 911, the unit will monitor message activity, report status, and can even email staff accordingly. It connects to CAP Servers, including National Weather Service (NWS), Department of Homeland Security (DHS), National Oceanic and Atmospheric Administration (NOAA), Federal Emergency Management Agency (FEMA), United States Geological Survey (USGS) and others...

• Trilithic. Trilithic provides EAS Solutions for the Broadcast, Cable television, Radio, and IPTV Industries. Trilithic has a long history of supporting EAS and the evolution of standards and technology. Not only do we expect to provide a solution for CAP protocol and other new capabilities to improve the delivery of emergency alerts, we expect to deliver a solution to our customer that is based on maximizing their investment in our current product in their inventory. Trilithic traditionally has been able to update and modify current hardware, firmware, and software to provide the best solution to meet the operational expectations of our customers. We understand your need to keep your EAS investment low and will continue to design with that goal in mind. New customers to Trilithic can expect a technology based solution that evolves with the standards and a company that supports its customers and embraces their business requirements... Trilithic is active with the FCC, FEMA, and other organizations involved in the evolution of EAS. Arthur Leisey, SCTE EAS Sub Committee Chairman is involved with most of our efforts and is available to further discuss each customer's specific requirements... Trilithic, Inc. is committed to the design of environmentally safe products. As such, it is a goal of Trilithic to reduce the amount of hazardous substances and waste introduced into the environment..."

• Warning Systems, Inc. "WSI manufactures VHF and UHF Tone Alert Radios that can be selected geographically, individually, or by common interest groups, and activated by the Common Alerting Protocol (CAP). Utilizing the technology of XML, WSI provides the Common Alerting Protocol (CAP) message format to the activation of all types of dissemination systems. These include not just our basic Tone Alert Radios (TARs), which are already geographically aware warning devices, but most all tone encoded RF devices as well. This means that virtually all DTMF, 2-tone or single-tone systems can be activated with a CAP message using the state-of-the-art WSI activation systems. In many cases, this system will provide current technology to activate legacy systems... The WSI system can transmit both your emergency broadcasts and other programming sources, such as NOAA weather broadcasts. With the push of a button, the customer's receiver can be used to hear the NOAA simulcast. However, any emergency transmission will override the NOAA broadcast... Interoperability and promoting standards for emergency communications is very important to WSI. Consequently the company is active in several important emergency management and technical associations. We are also proud to have been recognized for contributions to emergency management, interoperability, and community service. WSI regularly participates in joint technology demonstrations utilizing CAP to enable interoperable alert and warning solutions... WSI was chosen to participate in the first pilot phase of FEMA's Integrated Public Alert and Warning System (IPAWS) for CAP based EAS activation, and is under contract to Sandia National Labs to provide EAS and RF activation for phase two of the Web Alert and Relay Network (WARN) pilot portion of IPAWS...

About the EAS-CAP Industry Group (ECIG)

The EAS-CAP Industry Group (ECIG) is a coalition of Emergency Alert System equipment, software and service providers. The EAS-CAP Industry Group is working to develop a voluntary profile for the interoperability of advanced Emergency Alert System (EAS) capabilities in the United States using the Common Alerting Protocol (CAP).

The ECIG has been established in response to:

• A perceived need among EAS industry participants for interoperability among advanced Emergency Alert System (EAS) capabilities in the United States, equipment and services that will map Common Alerting Protocol (CAP) emergency messages into the legacy EAS protocol.

• A decision by the Federal Communications Commission (FCC) to maintain EAS and have all U.S. EAS participants adopt an ability to receive messages using the Common Alerting Protocol (CAP) within 180 days after the Federal Emergency Management Agency (FEMA) formally adopts CAP 1.1 as a standard for EAS.

• The need to establish a community and stakeholder process for CAP for the needs of EAS industry participants, including vendors, service providers and broadcasters, cablecasters, wireless cable systems, and satellite program providers.

ECIG Mission Statement:

Using the best available information, the EAS-CAP Industry Group will collaborate to seek agreement on a voluntary profile for the interoperability of advanced emergency alert system (EAS) capabilities in the United States using the Common Alerting Protocol (CAP). Specifically, the Industry Group is collaborating to coordinate interoperability data standards among Emergency Alert System equipment, software and service providers. Further, the Industry Group may provide recommendations to U.S. governmental agencies and industry associations on the use of CAP for EAS purposes.

The EAS-CAP Industry Group's intention is to offer an interoperable EAS CAP data profile that is a freely available resource for EAS participants, equipment, software and service providers, to the benefit of public alert and warning capabilities throughout the United States. It is the intention of the Industry Group that any work product of the group be free of copyright and intellectual property constraints.

In June 2008, "the EAS-CAP Industry Group held its first meeting by teleconference, establishing the overall objectives of the group. ECIG members agreed on the mission of defining an interoperability profile within CAP 1.1 that allows an EAS device to be able to receive a CAP alert from anywhere, and render it into a consistent EAS message. Members at this founding meeting included Digital Alert Systems, Hormann America, Monroe Electronics, MyStateUSA, Sage Alerting Systems, SpectraRep, TFT, and Trilithic."

About the Common Alerting Protocol (CAP)

Common Alerting Protocol Version 1.1. OASIS Standard. Edited by Elysa Jones (Warning Systems, Inc) and Art Botterell. Produced by members of the OASIS Emergency Management Technical Committee. Reference identifier: 'CAP-V1.1'. October 2005. 35 pages. Note that the OASIS Emergency TC is developing several related specifications, including: CAP (Common Alerting Protocol); EDXL-DE (Emergency Data Exchange Language Distribution Element); EDXL-RM (Emergency Data Exchange Language Resource Messaging); HAVE (Emergency Data Exchange Language Hospital AVailability Exchange - HAVE).

"The Common Alerting Protocol (CAP) is a simple but general format for exchanging all-hazard emergency alerts and public warnings over all kinds of networks. CAP allows a consistent warning message to be disseminated simultaneously over many different warning systems, thus increasing warning effectiveness while simplifying the warning task. CAP also facilitates the detection of emerging patterns in local warnings of various kinds, such as might indicate an undetected hazard or hostile act. And CAP provides a template for effective warning messages based on best practices identified in academic research and real-world experience.

The Common Alerting Protocol (CAP) provides an open, non-proprietary digital message format for all types of alerts and notifications. It does not address any particular application or telecommunications method. The CAP format is compatible with emerging techniques, such as Web services, as well as existing formats including the Specific Area Message Encoding (SAME) used for the United States' National Oceanic and Atmospheric Administration (NOAA) Weather Radio and the Emergency Alert System (EAS), while offering enhanced capabilities that include:

• Flexible geographic targeting using latitude/longitude shapes and other geospatial representations in three dimensions
• Multilingual and multi-audience messaging
• Phased and delayed effective times and expirations
• Enhanced message update and cancellation features
• Template support for framing complete and effective warning messages
• Compatible with digital encryption and signature capability
• Facility for digital images and audio

Key benefits of CAP will include reduction of costs and operational complexity by eliminating the need for multiple custom software interfaces to the many warning sources and dissemination systems involved in all-hazard warning. The CAP message format can be converted to and from the 'native' formats of all kinds of sensor and alerting technologies, forming a basis for a technology-independent national and international 'warning internet'...

Applications of the CAP Alert Message: The primary use of the CAP Alert Message is to provide a single input to activate all kinds of alerting and public warning systems. This reduces the workload associated with using multiple warning systems while enhancing technical reliability and target-audience effectiveness. It also helps ensure consistency in the information transmitted over multiple delivery systems, another key to warning effectiveness.

A secondary application of CAP is to normalize warnings from various sources so they can be aggregated and compared in tabular or graphic form as an aid to situational awareness and pattern detection. Although primarily designed as an interoperability standard for use among warning systems and other emergency information systems, the CAP Alert Message can be delivered directly to alert recipients over various networks, including data broadcasts. Location-aware receiving devices could use the information in a CAP Alert Message to determine, based on their current location, whether that particular message was relevant to their users. The CAP Alert Message can also be used by sensor systems as a format for reporting significant events to collection and analysis systems and centers...

History: The National Science and Technology Council report on Effective Disaster Warnings released in November, 2000 recommended that 'a standard method should be developed to collect and relay instantaneously and automatically all types of hazard warnings and reports locally, regionally and nationally for input into a wide variety of dissemination systems'. An international working group of more than 130 emergency managers and information technology and telecommunications experts convened in 2001 and adopted the specific recommendations of the NSTC report as a point of departure for the design of a Common Alerting Protocol (CAP). Their draft went through several revisions and was tested in demonstrations and field trials in Virginia (supported by the ComCARE Alliance) and in California (in cooperation with the California Office of Emergency Services) during 2002 and 2003.

In 2002 the CAP initiative was endorsed by the national non-profit Partnership for Public Warning, which sponsored its contribution in 2003 to the OASIS standards process. In 2004, CAP version 1.0 was adopted as an OASIS Standard..."

Principal References

• Announcement:
  • Announcement September 26, 2008: "Emergency Alert System Manufacturers and Service Providers Develop Profile for Using Common Alerting Protocol in Broadcast EAS. Industry Leaders Collaborate on Utilizing Open Standard to Facilitate Interoperability of Advanced Emergency Alert System Capabilities in the U.S." [source PDF, bis]
  • SpectraRep Supports Draft of Next Generation of Broadcast EAS-CAP Profile. Announcement September 25, 2008.
• EAS-CAP Industry Group (ECIG):
  • EAS-CAP Industry Group (ECIG) web site. "Promoting standards for the next generation of EAS."
  • ECIG Mission
  • ECIG Members and Participants
  • EAS-CAP Industry Group Profile. Specification reference page with instructions for feedback.
  • ECIG Frequently Asked Questions (FAQ) document
  • ECIG Press Releases
  • Industry Resources for the U.S. Emergency Alert System
• Common Alerting Protocol (CAP):
  • Common Alerting Protocol Version 1.1. OASIS Standard.
  • ITU-T X.1303: Common Alerting Protocol (CAP 1.1). From International Telecommunication Union. Telecommunication Standardization Sector of ITU. Series X: Data Networks, Open System Communications and Security. Telecommunication Security. Recommendation X.1303 (09/07). Approved in 2007-09.
  • OASIS Emergency Management TC: CAP, EDXL-DE, EDXL-RM, HAVE
  • OASIS Emergency Management Technical Committee
  • Summary: The OASIS Emergency Management TC supports development and adoption of several standards relating to public safety and emergency management, including (1) alerting, warning, and informing responders and the public (2) incident reporting and tracking; (3) resource identification, tasking and tracking.
    • CAP (Common Alerting Protocol)
    • EDXL-DE (Emergency Data Exchange Language Distribution Element)
    • EDXL-RM (Emergency Data Exchange Language Resource Messaging)
    • HAVE (Emergency Data Exchange Language Hospital AVailability Exchange - HAVE)
  • Recent Emergency Management TC deliverables
  • OASIS/ITU-T Common Alerting Protocol (CAP) Receives Support from FEMA and WMO
  • Members Approve Common Alerting Protocol (CAP) v1.1 as OASIS Standard
  • "CAP 1.0 Fact Sheet." Date: 3/1/2004. From the OASIS TC. "The Common Alerting Protocol (CAP) is the OASIS Emergency Management Technical Committee's first standard for homeland security and civil emergency management. CAP is a simple, flexible data interchange format for collecting and distributing 'all-hazard' safety notifications and emergency warnings over information networks and public alerting systems..."
  • Emergency Management Technical Committee. News story 2003-01-10.
  • Announcement and Call for Participation: OASIS Emergency Management TC
• CAP Information from Incident.com:
  • Who Is Using CAP?
  • The CAP Cookbook
  • Creating CAP Applications. Summarizes some of the key choices and trade-offs facing the designer or integrator of a CAP-based application.
  • CAP EAS/NWR Profile. Reference document from The CAP Cookbook. "A key characteristic of the Common Alerting Protocol (CAP) is that it can be used to include and extend existing warning technologies as part of a larger integrated public alert and warning system.
• U.S. Federal Communications Commission (FCC), Emergency Alert System (EAS):
  • FCC EAS home page
  • FCC EAS Rules from The Electronic Code of Federal Regulations (e-CFR). CFR 47, Part 11 = Emergency Alert System (EAS).
  • Next Generation EAS Planning. See the 'Progress Reports'.
  • Emergency Alert System (EAS). Information from the U.S. Dept of Commerce, National Oceanic and Atmospheric Administration (NOAA), National Weather Service.
  • U.S. Integrated Public Alert and Warning System (IPAWS)
• CAP and FEMA:
  • "FEMA Announces Intention to Adopt Common Alerting Protocol 1.1." Announcement July 30, 2008. See also the news story "OASIS/ITU-T Common Alerting Protocol (CAP) Receives Support from FEMA and WMO".
  • SBE Offers Plan to Help FEMA Move on CAP." May 23, 2008. "Frustrated by the lack of progress by FEMA, the Society of Broadcast Engineers offered a preliminary strategy to help move CAP (Common Alerting Protocol) from FEMA's offices to broadcast stations and emergency operations centers."
  • "Will the EAS House Be Put in Order? Questions Persist About Funding and Timing of a Next-Generation System." By Randy J. Stine. From (July 02, 2008).
  • Society of Broadcast Engineers (SBE) Strategy for Impementing CAP EAS. May 2008. Referenced from the SBE web site document "SBE and EAS Issues." [cache/archive: PDF and canonical .doc]
  • FCC 07-109 Review of the Emergency Alert System. EB Docket No. 04-296. Second Report and Order and Further Notice of Proposed Rulemaking. Released: July 12, 2007. See "Common Alerting Protocol (CAP) for EAS," pages 20ff. [source PDF]
• Updates, Commentary:
  • EAS Manufacturers, Service Providers Develop CAP 'Profile' From Radio World Newsbytes.
  • Elysa Jones (Warning Systems, OASIS EMTC Chair) wrote to the OASIS Emergency Management TC List: "It is my understanding that FEMA will request the OASIS-EMTC to review and take through the standards process this EAS-CAP profile. We have the Subcommittee formed to do this and expect there to be a request coming to us soon to accept this as a work product and begin our effort."