Insight On Rules #88

February 1995

FCC Releases EAS Rules

by Harold Hallikainen

San Luis Obispo, CA On December 9, 1994, the FCC released a Report and Order that replaces the existing Emergency Broadcasting System with a new Emergency Alert System. They also issued a Further Notice of Proposed Rulemaking regarding EAS for cable systems, MDS (wireless cable), Digital Audio Radio and other services. In this article, we'll take a close look at the new rules regarding broadcast stations. This article is based on a review of the Report and Order and discussion with FCC staff and others. The full text of the report and order is available on internet at http://fcc.gov. It's also available by fax at +1 805 541 0201. You may also want to check the FCC's fax server at +1 202 418 2830.

Implementation Timetable

No changes are REQUIRED until 1 July 1995. However, by 1 July 1995, all existing EBS decoders in stations MUST be modified to respond to the existing two tone (853 and 960 Hz) attention signal in a minimum of 3 and a maximum of 4 seconds. The existing decoders are required to respond in 8 to 16 seconds. Decoders can be modified anytime before 1 July 1995.

Starting 1 July 1995, two tone encoders MAY be modified to transmit the attention signal for 8 to 25 seconds. The shortened tone was suggested by NAB in their EBS petition. The 8 second minimum with a decode time maximum of four seconds insures broadcast stations will continue to properly receive the EBS tones.

Starting 1 July 1995, stations MAY start using the new EAS codes in addi tion to the shortened EBS tone.

Starting 1 July 1996, stations MUST use the new EAS codes along with the shortened EBS tone.

Starting 1 July 1997, stations no longer need to maintain the existing two tone decoders. All station alerting is done by the new EAS codes. Stations MUST continue to broadcast the two tone "attention signal" during monthly tests and during emergencies. Paragraph 95 of the Report and Order indicates that retention of the tone or not making it excessively short was due to comments from a couple organizations representing disabled persons. It was thought that the tones would catch someone's attention better than a short audio frequency shift keyed (AFSK) chirp. In addition, though not mentioned in the Report and Order, there are several thousand consumer receivers in operation around the country that detect the dual tone attention signal. Continued use of the two tone attention signal allows these receivers to continue to operate.

The EAS Protocol

Currently, the two tone attention signal provides a very limited form of message addressing. Receivers are muted unless an emergency message is sent. The EAS expands the addressability of the system. The EAS protocol uses an audio frequency shift keyed asynchronous data signal with one start bit (always space), 8 data bits, no parity bit, and one stop bit (always mark). The data is transmitted at 520.83 bits per second with a mark frequency of 2083.3 Hz and a space frequency of 1562.5 Hz. The rules do not specify tolerances on these frequencies. The asynchronous "8 none 1" is also not clearly specified in the rules. The tones must modulate the transmitter at least 80% (peak), according to 11.51(f). Many stations are not meeting the existing modulation requirements due to how their audio processing equipment handles the tones. This will, once again, be something to watch for.


PREAMBLE] ZCZC-ORG-EEE-PSSCCC+TTTT-JJJHHMM-LLLLLLLL-
(one second pause)
[PREAMBLE] ZCZC-ORG-EEE-PSSCCC+TTTT-JJJHHMM-LLLLLLLL-
(one second pause)
[PREAMBLE] ZCZC-ORG-EEE-PSSCCC+TTTT-JJJHHMM-LLLLLLLL-
(one or more second pause)
(two tone attention signal for 8 to 25 seconds)
(emergency audio programming)
[PREAMBLE] NNNN
(one second pause)
[PREAMBLE] NNNN
(one second pause)
[PREAMBLE] NNNN
(one or more second pause)

Figure 1 - The EAS Protocol


As shown in figure 1, each data packet starts with a preamble (16 bytes of hex AB). It is followed by a string of ascii characters (with the most significant bit a zero or space). The "ZCZC" is sent as a 4 character ascii sequence. It is a "start of message" flag.

ORG is a three character identifier indicating who originated the activation of the EAS. Only five ORG codes are assigned. These are EAN (Emergency Action Notification network of program networks and suppliers for a national alert), PEP (Primary Entry Point, key broadcast stations which can provide national emergency information if EAN fails), WXR (National Weather Service), CIV (civil authorities, such as EAS activations by state or county governments), and EAS (Emergency Alert System activations by broadcast or cable systems).

EEE is a three character "event code" that identifies the type of emergency. These are listed in figure 2.


EAN       National Emergency Action Notification
EAT       National Emergency Action Termination
NIC       National Information Center
NPT       National Periodic Test
RMT       Required Monthly Test
RWT       Required Weekly Test
TOA       Tornado Watch
TOR       Tornado Warning
SVA       Severe Thunderstorm Watch
SVR       Severe Thunderstorm Warning
SVS       Severe Weather Statement
SPS       Special Weather Statement
FFA       Flash Flood Watch
FFW       Flash Flood Warning
FFS       Flash Flood Statement
FLA       Flood Watch
FLW       Flood Warning
FLS       Flood Statement
WSA       Winter Storm Watch
WSW       Winter Storm Warning
BZW       Blizzard Warning
HWA       High Wind Watch
HWW       High wind Warning
HUA       Hurricane Watch
HUW       Hurricane Warning
HLS       Hurricane Statement
TSA       Tsunami Watch
TSW       Tsunami Warning
EVI       Evacuate Immediate
CEM       Civil Emergency Message
DMO       Practice/Demo Warning
ADR       Administrative Message

Figure 2 - EAS Event Codes

PSSCCC defines the location of the emergency. Each state is assigned a number (SS). Each county is assigned a number (CCC). If the CCC is 000, the emergency covers the whole state. P is 0 if the emergency covers the whole county. P can be a number 1 through 9 to cover nine portions of a county (generally scanning west to east, north to south).

TTTT defines the valid duration of the emergency in HHMM format with 15 minute resolution below one hour, then 30 minute resolution.

JJJHHMM defines the time the message was originally released. JJJ is a three digit number representing the day of year (1 January is 001). HHMM is the time in UTC (the old GMT). The use of UTC was selected since emergency messages may cross time zones.

LLLLLLLL is the identity of the station CURRENTLY transmitting the code. When packets are relayed, this is the ONLY field that is changed.

NNNN is an End Of Message indicator. It can mute consumer receivers or return stations to normal programming automatically.

The rules do not specify the contents of the one second pause. It COULD be one second of silence, one second of normal program audio or one second of 2083.3 Hz. Paragraph 110 of the R&O refers to "unobtrusive tests" of the system where only the EAS data is sent. They estimate the tests would take about six seconds and be unintelligible to listeners. If an average alerting packet runs 58 bytes (including preamble) and each byte is 10 bits (including start and stop bits), it would take a little over a second to transmit. The End Of Message packets are considerably shorter, running 20 bytes with the preamble. These each take about 400 milliseconds. It SEEMS that the "unobtrusive test" would be less obtrusive if program audio were allowed in the pause periods. The data bursts would then sound something like the data bursts we currently hear on some networks for station equipment control.

Decoders must receive two identical headers (of the three transmitted) to be considered valid. This is the system error checking.

Typical Weekly Test

Stations will be required to initiate weekly tests of the system (see 11.61(a)(2)). Prior to 1 July 1996, tests include the existing attention signal and EBS test script. These tests (as existing tests) are to be conducted weekly on random days and times between 8:30 a.m. and sunset. Starting 1 July 1996 stations (except class D NCE and LPTV) stations are to run the "unobtrusive" tests consisting of the EAS header transmitted three times followed by the EAS EOM transmitted three times. Stations are required to log EAS test transmissions and receptions. No audio message is required. Only the AFSK datastream is broadcast. These tests are NOT relayed to other stations.

Typical Monthly Test

Monthly tests in odd numbered months will be run between 8:30 a.m. and sunset. Tests in even numbered months will be run between sunset and 8:30 a.m. These tests include the EAS header, the two tone attention signal, a test script and the EAS EOM. Broadcast stations do not ORIGINATE this test, but instead relay tests that are received from other sources. The test is originated by "local or state primary sources" (such as a county or state emergency operations center). Stations in the originating local area or originating state are REQUIRED to retransmit the test within 15 minutes or reception. Since the new system will use a web topology instead of the existing tree structure, there will be many loops making it possible for the station to receive a message several times, each arriving over a different route. The decoder ignores subsequent identical messages preventing continuous transmissions.

Emergency Operation

Stations preprogram their EAS decoder as to what areas and which event codes they wish to respond to. All stations MUST respond to EAN (national emergency) messages. On receiving a valid EAS header, the decoder displays the identifying data and notifies the operator if the header matches one of the stored emergency types. The decoder records up to two minutes of emergency programming followed by the EAS EOM. The operator may then relay the message using the received EAS header information and the recorded emergency audio. If necessary, the emergency programming may be translated to another language for that station's audience.

It seems that local EAS plans should be set up to either include separate distribution webs for each language spoken in an area (and broadcast), or a single web could be used with the emergency operations center giving the emergency instructions in several languages sequentially (like the announcements in airports).

Automation

The new system has many features making automation possible. It still has a few requirements disallowing automation (such as the required check of the Authenticator Word List in 11.54(a)(2)), but I expect further refinement of the system to make automation feasible. This, combined with the proposed reduction in operator requirements (discussed last month) would allow unattended operation of broadcast stations.

I see the EAS as a web of nodes, all interconnected by several communications paths. National, state and local emergency agencies have several entry points to the web. A county emergency operations center might have an EAS encoder driving phone lines or a county radio system driving the EAS decoders at several stations in the area. When an emergency occurs, the emergency official could push a button on a map of the county identifying which area(s) require notification. She/he would then push a button marked "Evacuate Immediate" (or other event code) and wait for the "green light". The green light would be lit after the three EAS headers and the two tone attention signal are sent. The official would then give the emergency instructions and push the EOM button. This audio (AFSK datastream, attention signal and voice announcement) would be sent to several stations in the area. Stations that have programmed their EAS systems for this area and event type would immediately broadcast the EAS codes (regenerating them, substituting their own call letters) followed by the attention signal, the emergency audio and the EAS EOM. Since it takes time to fully decode the EAS datastream and regenerate it, it's necessary to buffer the audio. The new EAS systems will include a two minute (minimum) audio storage. Other stations monitoring this station will similarly receive the EAS datastream and rebroadcast it. The "immediate" retransmission is required only for national (EAN) messages. State and local messages may be delayed up to 15 minutes (see 11.51(k)(2)). It appears that EAS systems COULD be designed to interface with program automation systems to run the emergency message during the next break, avoiding program interruption. This, however, seems to add unnecessary complexity. If the use of EAS is indeed reserved for true emergencies, it appears immediate retransmission is appropriate.

New Hardware

Although the Report and Order recognizes the possibility of manufacturing separate encoders and decoders, I suspect most units will be integrated. This vastly simplifies the interface requirements when the system must automatically relay an emergency message. So, here's what I see as the new EBS box.

A "integrated" EAS unit would be required to have at least two audio inputs. These would monitor other EAS sources, such as other broadcast stations, state and local emergency communications circuits, weather service radios, etc. A state EAS plan provides the monitoring assignments for each station. The topology is designed to provide several paths from an originating point to all participants so a failure at any one point does not disrupt the system.

I'd suggest a "program loop through" similar to many existing EBS systems. The loop through should be designed to consider the varieties of program transmission methods. At a minimum, I'd suggest a way of handling balanced stereo audio and composite stereo. On receiving appropriate EAS codes, the system would drop whatever audio is being passed through and substitute its audio (the EAS tones, attention signal, time delayed emergency program, EAS EOM), then return to normal audio.

The system will have a display and keyboard that are used to program the system and display information pulled from received EAS headers.

The systems will also have a serial data port to relay EAS data to and receive EAS data from non-audio circuits (digital data circuits, RBDS encoder/decoder, etc.). It appears (based on 11.32(a)(2), 11.32(a)(3), and 11.32(a)(1)) that the EAS systems do a speed conversion from 83 bps used over audio channels to 1200 bps for digital circuits.

Vast Improvement

The new system appears to be a vast improvement over the existing EBS. This is the third EBS system I've worked with, starting with the old 1 KHz tone and carrier drops (which typically tripped breakers on our old transmitter). The addressability, web network structure and features that allow for automation look very good. There are still a few things to be worked out, and some room for additional features. I'd like to see the EAS protocol expanded a bit to allow a plain text packet between the header and EOM packets. The packet could also include a language identification code. An emergency operations center could then generate a text message along with a voice emergency announcement. This text message could be relayed to RBDS receivers, electronic billboards, television stations, and CATV systems where a voice announcement may not be appropriate.

Once again, I invite you to read the Report and Order yourself. It's available via internet or fax, as described above.


Harold Hallikainen is president of Hallikainen and Friends, a manufacturer of transmitter control and telemetry systems. He also teaches electronics at Cuesta College, San Luis Obispo and is doing lots of contra dancing. He can be reached at 805 541 0200, fax 805 541 0201. He can also be reached on internet at harold@hallikainen.com.