SBE EAS Advisory Group Publishes EAS Security Notes

Prepared by the SBE EAS Advisory Group

Intrusions into computerized equipment have been around since the internet became a reality years ago. It is no surprise to broadcast engineers that these invasions have made their way into radio and television stations.

Most recently, EAS devices have been a major target. To comply with FCC rules, these devices must have internet access to receive information from FEMA via IPAWS.

Security for EAS and other station devices should be a high priority for station engineers. As a result, the SBE EAS Advisory group has put together a basic security guidelines summary to aid stations in assuring that all equipment is protected from these outside intrusions.

Summary

Every week, broadcasters like you are having their station equipment and computers hacked or tampered with by outsiders or malware infections that affect station computers and networks. If it hasn’t happened to you yet, the odds are unfortunately high that it eventually will happen.

These types of intrusions are more than an inconvenience. It can cost you to repair the systems that were compromised. It can cost you revenue for lost airtime. It can cost you credibility in your audience and community. Moreover, it eventually will cost all of us if the government feels it necessary to step in with additional regulations and requirements on broadcasters.

At the same time, it’s challenging for many broadcasters to keep up with the wide range of potential cyberattacks. Many broadcasters don’t know they have become vulnerable to attackers until it’s too late.
To help broadcasters address this growing concern, we have compiled some tips and best practices on how to keep your operation from falling prey to cybercrime. The bottom line:
• Know your Systems. Know what is connected to the network and the internet: at the office, studio, transmitter site, and remotes. If it’s connected, it is at risk.
• Defend your Network. Anything that is connected to your network or the internet must be behind a firewall.
• Protect your Equipment. Change default passwords. Change default usernames. Regularly check for and install any software upgrades or patches for equipment.
• Use Common Sense with Email and the Internet. Be cautious about opening email attachments or downloading from websites you don’t completely trust. Harmful malware can enter your station, and do significant damage to your business.
What is the problem?

Recent events had plainly shown that broadcasters are a low-hanging fruit for internet mischief-makers and cybercriminals. All too frequently, this involves key station equipment and computers left vulnerable to the internet, not changing default passwords, or even not having passwords at all.

The results have included the entire programming stream disrupted by IP streamers redirected to offensive, political and/or obscene content, the issuance of false or simulated EAS messages, the creation of fake messages and alerts via RDS encoders, the wholesale disruption of station operations when computers are locked via malware and viruses, and more. These are issues that have already happened, repeatedly.

In many cases, the threats boil down to simple vulnerabilities that could have been easily addressed beforehand.
• Stations with unconfigured firewalls – or even no firewalls.
• Station equipment left exposed and unprotected to the open internet.
• Station equipment left with default or easily guessable passwords – or even no passwords.
• Email attachments open, which introduced malware across the station network.

Presenting the potential for reaching a wide audience with inappropriate or political content, broadcasters present an irresistible opportunity for internet bad guys. Some broadcasters have opined that cybersecurity is too expensive or difficult. However, as we outline below, broadcasters can take preventative steps that are often a minimal expense – or no expense at all.

The technical solutions:

• Know Your Systems. Know what systems are connected to your network and to the internet, and know which systems should not be. If it is connected to the network, it’s going to need to be protected. This applies to looking at your systems throughout your operation. This includes the business office, studios, transmitter sites, remote control points, and other remote sites.
• Firewalls to Defend Your Network. The one security item every company needs is a firewall, a security appliance that attaches to your network and acts as the protective shield between the outside world and your wired and/or wireless network. A firewall continuously inspects traffic and matches it against a set of predesigned rules. If the traffic qualifies as safe, it’s allowed onto your network. If the traffic is questionable, the firewall blocks it and stops an attack before it enters your network. Just about anything in your broadcast facility should be behind a firewall if it is on your network, or going to be connected to the internet. Properly configure your firewall, make sure any software or firmware is up to date, and don’t leave ports open.
• Equipment Passwords and Account Management. Equipment in your station may come with a default password. You are urged to change default passwords on any equipment in your operation. If there are accounts or usernames on equipment that are default, or unused, you should also change or delete these. And remember, just because a system has a password, does not mean that it may be fully protected from access by other means. Equipment needs to be behind a firewall.
• Updates and Patches. The manufacturers of equipment in your station may contact you periodically regarding software patches and updates. Make it a practice of applying those software updates in a timely manner. Also, make it a practice of checking with your various manufacturers from time to time to see if they have released software updates of which you may not have been. These updates and patches may include not only feature improvements and bug fixes; they may also contain critical security patches.
• Secure Networks. Other measures to consider is a virtual private network (VPN). A VPN securely and inexpensively uses the public internet, instead of privately owned or leased lines, to provide remote sites and individuals with secure access to your organization’s network. Consider, for example, a VPN link as part of the STL, if that relies on an IP stream from the studio to transmitter.
• Safe Web Browsing and E-Mail Habits. Very bad things can enter the station via email or suspect web sites. If your station’s employees send e-mails and browse the internet (and of course, virtually all do!), you may also want to consider a software security solutions that include e-mail security, Web gateway security, and URL filtering.
The social solutions

• Security fundamentally involves a social aspect. Internally, you may need to reorient your employees and colleagues around safe email and web browsing habits. You may want to orient these employees to be wary of scam and phishing emails, and to beware of potentially dangerous attachments to emails from unknown or suspicious senders. You may need to reinforce safe web browsing habits, such as being careful not to download content from unknown or suspect websites.
• Broadcasters are a community. Externally, you may find opportunities to share information about what you are doing to improve security, what threats you see, and how you are addressing them.
When to call in an IT security consultant

There are going to be things you might not be able to do alone as a broadcaster. For FCC issues, you get outside legal advice. For annual and quarterly financials, you have an accountant. The same goes for security expertise. When you need to conduct a risk assessment, or get assistance in setting up network and IT security solutions, it may be money well spent it if you don’t have the expertise to do it yourself.

Don’t be part of the problem. Be part of the solution.

The Society of Broadcast Engineers Forms EAS Advisory Group

The Society of Broadcast Engineers has actively worked as a source of information for the Emergency Alert System since it was launched. As the system has developed and evolved to include new technologies and alerting partners, so has the SBE adapted to be the most effective and thorough resource for broadcasters to use to implement their EAS efforts.

As part of this evolution, SBE President Jerry Massey, CPBE, 8-VSB, AMD, DRB, CBNT, authorized the formation of the SBE EAS Advisory Group. The purpose of the group is to stay abreast of developments regarding EAS that will affect SBE members, including changes in federal regulations, policy and technology, and communicate pertinent developments to appropriate SBE national leadership and staff.

The group’s member’s are:
Larry Wilkins, CPBE, AMD, CBNT (group chair)
George Molnar
James Hoge
Ed Czarnecki (Monroe Electronics/Digital Alert Systems)
Harold Price (Sage Alerting Systems)

The group members were chosen to yield insight from the two SBE national committees that are involved with EAS issues, SBE members who are heavily involved with EAS, and SBE sustaining members that manufacture EAS equipment. The group reports to Wayne Pecena, CPBE, 8-VSB, AMD, DRB, CBNE, the chair of the SBE Education Committee, and Joe Snelson, CPBE, 8-VSB, the chair of the SBE Government Relations Committee.

On the announcement of the group’s formation, SBE President Jerry Massey said, “The SBE has worked with the various EAS partners, from stations to manufacturers to legislators, to be the trusted source of EAS information. The SBE EAS Advisory Group continues the effort that was begun by previous SBE committees.”

Larry Wilkins, the group chair, added, “Going forward, one focus of the group will be to field reports concerning origination or distribution problems from broadcast stations and state emergency communications committees (SECC). Using the expertise of the committee members along with information from our contacts with the FCC and FEMA, a recommended solution can be issued to the industry.”

Initial Findings of the 2016 EAS Nationwide Test

EAS logoAt the end of December, the FCC released an initial overview of the nationwide EAS test results and highlighted several opportunities for strengthening the EAS. The Federal Emergency Management Agency (FEMA), in coordination with the Federal Communications Commission (Commission) and the National Weather Service (NWS), conducted a nationwide test of the Emergency Alert System (EAS) at 2:20 p.m. EDT on Sept. 28, 2016. The nationwide test was designed to assess the reliability and effectiveness of the EAS, with a particular emphasis on testing FEMA’s Integrated Public Alert and Warning System (IPAWS), the integrated gateway through which common alerting protocol-based (CAP-based) EAS alerts are disseminated to EAS Participants.

The test also provided the Commission an opportunity to evaluate improvements made to the EAS since the 2011 nationwide EAS test and to improve its ability to monitor the performance of EAS Participants during nationwide EAS tests. At the direction of the Commission, the Public Safety and Homeland Security Bureau launched the EAS Test Reporting System (ETRS), an electronic filing system and related database, on June 27, 2016. Using ETRS for the first time, EAS Participants nationwide registered accounts and submitted identifying information regarding their participation in the EAS. In the hours following the nationwide test, EAS Participants submitted “day of test” results that indicated whether they successfully received and retransmitted the test alert. EAS Participants submitted detailed analyses in the weeks following the test that specified how they received the alert and identified any complications they experienced during the test.

The FCC reports that the Nationwide EAS Test was successful. Initial test data indicates that the vast majority of EAS participants successfully received and retransmitted the National Periodic Test (NPT) code that was used for the test. The improvements made to the EAS using the lessons learned from the 2011 nationwide EAS test and the implementation of the ETRS appear to have significantly improved test performance over what was observed during the 2011 test.

From the data submitted by EAS participants to the ETRS, several steps have been identified where the Commission could strengthen the EAS. These improvements address problems with poor audio quality, inability to deliver the Spanish alert because of receive timing between the over-the-air test and the IPAWS CAP alert, better access to alerts for people with disabilities, shortcomings in some state EAS plans, improperly configured station equipment, and potential improvements in cybersecurity of the EAS.

Read the FCC’s public notice:
https://apps.fcc.gov/edocs_public/attachmatch/DA-16-1452A1.docx
https://apps.fcc.gov/edocs_public/attachmatch/DA-16-1452A1.pdf

Be Prepared for the 2016 National EAS Test

EAS logoWith the pending national EAS test, and the FCC’s unveiling of the EAS Test Reporting System, the SBE has prepared this summary of dates and actions of which all stations should be aware.

Aug. 26, 2016
Stations must complete Form One in the ETRS

Sep 28, 2016, 2:20 p.m. ET
EAS test
If circumstances prevent a test on Sep 28, the secondary test date is Oct 5, 2016.

Sep 28, 2016
By 11:59 p.m. ET, stations must complete the day-of-test report on Form Two in the ETRS

Nov 14, 2016
Deadline to submit post-test data on Form Three in the ETRS

FCC Adds Three EAS Event Weather Codes

The FCC has released a report and order to add three new weather event codes for the Emergency Alert System. The codes are Extreme Wind Warning (EWW), Storm Surge Watch (SSA) and Storm Surge Warning (SSW).

Read the complete report and order at the FCC website.

From the R&O, the FCC will “require EAS equipment manufacturers to integrate these codes into equipment yet to be manufactured or sold, and make necessary software upgrades available to EAS participants no later than six months from the effective date of the rule amendments adopted in this order.”

While the new codes will not need to be added to EAS devices until 2017, the SBE has gathered information on adding the codes.

Gorman-Redlich Users
Gorman-Redlich will deliver new units with the codes as per the deadline. For existing units, contact the compoany. A new EPROM is likely required.

Monroe Electronics/Digital Alert System Users
DASDEC and R189 One-Net software version 3.0 already support these three event codes. If you have v3.0, no further action is needed, aside from selecting the codes from the drop-down menu if you want to use them.

Sage Alerting System Users
Sage plans to include the codes in the upcoming 89.30 release. To add the events now, use the “New Events” tab in the ENDECSetD settings program to define the new event code, then include the codes a filter as needed.

Trilithic Users
EASyCap B4020 software will be updated for the event codes. Users subscribed to the Trilithic Newsgroup will be notified when the update is ready. Starting Jan. 1, 2017, a radio-specific EAS product will be available. There are no plans to update the EASyCast platform. That product platform has reached the end of its service, so unless a large number of users request an update, one will not be released.

FCC Launches EAS Test Reporting System

The FCC EAS Test Reporting System (ETRS) is up and running. The system is for EAS participants to file identifying information, day of test data, and post-test data related to a nationwide test. The ETRS provides several new features that ease the data-entry burden on EAS participants, encourage timely filings, and minimize input errors. The ETRS also offers new data fields that are responsive to stakeholder comments.

Access the ETRS

The FCC will use this system for the September National EAS Test and future EAS regional and national tests. There are multiple steps involved in the reporting process. The first step is to complete Form One, which must be done Aug. 26, 2016. To complete the form, participants must register on the ETRS site using the station’s FRN number and a password. Once registered, the FCC will send ETRS account credentials and a link to the ETRS login page.

Adrienne Abbott, SBE member and Nevada EAS chair, compiled some details about the system. Every station will need to complete a Form One. Station groups have the option of designating a coordinator to handle the filings. The coordinator will have the ability to batch file the forms. The form requires call letters as they appear on the license, the facility number for each station and the name of the station’s legal owner. As information is entered, some information will automatically populate the form from the FCC’s CDBS. It is advised to verify the CDBS information is correct.

The transmitter coordinates will not self-populate and must be entered directly. Use decimal form and NAD 83. Licenses are issued with NAD 27, so those numbers cannot be used. The FCC provides a conversion tool, and some consulting engineers offer the station info. If a tower is registered, the coordinates on the registration are in NAD 83. A Google map should appear if the coordinates are close. Check the map for your exact tower location. It should be within one second of the location on your license. If not, correct the location on the license.

The form will ask for the station’s monitoring assignments, but there is no need to include the NWS NOAA Weather Radio frequency. Enter the broadcast stations. The form will also ask for the brand of EAS equipment being used and the firmware/software version. Check the manufacturer’s website to make sure you have the latest update before you enter that information.

After the test, complete Form Two with the initial results of how the test was received and rebroadcast. The FCC wants that information as soon as possible after the test. Form Three allows more time to add any details or other information about the test.

In the FCC announcement about the ETRS, there is mention of a new EAS Handbook. Read the complete FCC public notice.

FEMA Plans New England Regional IPAWS Test, Holds Informative Webinars To Prep

FEMA, working with state broadcast associations in Connecticut, Maine, Massachusetts, New Hampshire, Rhode Island, and Vermont is planning to conduct a New England regional IPAWS test in September. This test will be a follow-up to the tests conducted in West Virginia last September, which resulted in 90% of participating stations successfully carrying the National Periodic Test EAS code and second test involving participants in Ohio, Kentucky, Michigan and Tennessee, conducted on March 18, 2015, which met with similar success. FEMA is conducting a series of regional tests in preparation for a future nationwide IPAWS test. The goal of these preliminary tests is to evaluate how messages are distributed and propagated throughout the system, and identify areas for improvement.

The next regional test, which will involve participants in Connecticut, Maine, Massachusetts, New Hampshire, Rhode Island, and Vermont, will be conducted on Sept. 16, 2015, at 2:20 p.m. Eastern Time. Local radio and television stations are not required to participate in the test; however, broad participation by stations will be very helpful in evaluating how the test messages propagate throughout the region.

In preparation for the test, FEMA is hosting technical webinars on Aug. 19 at 2 p.m. Eastern and Sept. 3 at 10 a.m. Eastern. The webinars will outline how the Sept. 16 test will be conducted, and will also provide information regarding EAS device configuration in preparation for the test. The technical webinars will discuss the technical side of IPAWS and conclude with step-by-step instructions for configuring various EAS devices. The two tech webinars will be essentially identical. The webinars will be recorded and available for later viewing as well.

The webinars are open to all but will specifically address the New England test. FEMA will conduct additional webinars in support of future tests in other areas of the country.

Links

Topic: NE ISSRT Technical Webinar I
Date and Time: August 19, 2015 2:00 p.m., Eastern Daylight Time (New York, GMT-04:00)

Event address for attendees:

http://tinyurl.com/nufuecl

Audio conference information
650-479-3207
Access code: 662 686 997

Topic: NE ISSRT Technical Webinar II
Date and Time: Thursday, September 3, 2015 10:00 am, Eastern Daylight Time (New York, GMT-04:00)

Event address for attendees:

http://tinyurl.com/nlrpfmc

Audio conference information
650-479-3207
Access code: 662 930 173

FCC Issues NPRM To Propose New EAS Event Codes

In a notice of proposed rulemaking adopted July 8, 2015, the Federal Communications Commission proposes to revise the FCC Emergency Alert System (EAS) rules, as set forth in a letter and subsequent comments filed by the National Weather Service (NWS) of the National Oceanic and Atmospheric Administration (NOAA). Specifically, the NWS requests that the Commission add three new EAS event codes, covering extreme wind and storm surges, as well as revise the territorial boundaries of the geographic location codes for two offshore marine areas listed in the EAS rules as location codes 75 and 77. The FCC agreed with the NWS that targeted, specific warnings “will help the public and emergency officials better respond to local threat(s).”
The codes specifically requested by the NWS:

Extreme Wind Warning (EWW)
To provide advance notice of the onset of extreme sustained surface winds (greater than or equal to 115 miles per hour) associated with a major land-falling hurricane (category 3 or higher). The NWS explains that using the Tornado Warning (TOR) event code caused confusion when used to warn of Hurricane Charley’s high winds in 2004. The NWS started using the EWW code during the 2007 hurricane season.

Storm Surge Watch (SSA) and Storm Surge Warning (SSW)
The NWS says the Storm Surge Watch/Warning will be issued when there is a significant risk of life-threatening inundation from rising water moving inland from the ocean. In the event of a storm surge, a watch (SSA) would be issued 48 hours in advance of the event taking place and a warning (SSW) would be issued 36 hours in advance of the event, and will help to mitigate damage from storm surge, the leading cause of death in tropical cyclones. The NWS currently does not issue explicit storm surge warnings, although the National Hurricane Center (NHC) has advocated for a storm surge watch and storm surge warning for a number of years. The NWS explains that the current hurricane watch/warning does not provide clear or sufficient information to allow citizens to determine if they are threatened by wind or storm surge or both.

The FCC seeks comments on adding these codes.

The NWS also requests that the Commission revise the areas defined in the geographic location codes identified in section 11.31(f) of the EAS rules as location codes 75 and 77, which cover offshore marine areas. These location codes, and their defined areas, like all the offshore (marine areas) location codes contained in the EAS Protocol, were originally adopted in 2002. Currently, the marine area defined for location code 75 covers “Western North Atlantic Ocean, and along U.S. East Coast, south of Currituck Beach Light, N.C., following the coastline into Gulf of Mexico to Bonita Beach, FL, including the Caribbean,” while location code 77 covers “Gulf of Mexico, and along the U.S. Gulf Coast from the Mexican border to Bonita Beach, FL.” The NWS indicates that it has changed the end point it uses for generating weather alerts for both of these areas from Bonita Beach, FL, to Ocean Reef, FL, and, accordingly, requests that the area covered by location code 75 be changed to “Western North Atlantic Ocean, and along U.S. East Coast, south of Currituck Beach Light, NC, following the coastline to Ocean Reef, FL, including the Caribbean,” and that the area covered by location code 77 be changed to “Gulf of Mexico, and along the U.S. Gulf Coast from the Mexican border to Ocean Reef, FL.”

The FCC also proposes revising footnote 1 of section 11.31 to delete the reference to a past deadline and to clarify that the numbers assigned to the offshore marine areas listed in the table of geographic areas in section 11.31(f), while consistent with the format of the state and territory location codes derived from the ANSI standard, are not a product of that standard, but rather were assigned by the NWS.

PS Docket No. 15-94

Read more SBE news and headlines

Audible Crawls Implementation and FCC Comment Deadlines Set

On May 28, 2015, the Federal Communications Commission released the Second Accessible Emergency Information Order, which adopted additional rules under the authority of Sections 202 and 203 of the Twenty-First Century Communications and Video Accessibility Act of 2010 (CVAA) to make emergency information in video programming accessible to individuals who are blind or visually impaired. First, the Second Accessible Emergency Information Order requires multichannel video programming distributors (MVPD) to pass through a secondary audio stream containing audible emergency information when they permit consumers to access linear programming on second-screen devices, such as tablets, smartphones, laptops, and similar devices. Second, the Second Accessible Emergency Information Order requires manufacturers of apparatus that receive or play back video programming to provide a mechanism that is simple and easy to use for activating the secondary audio stream to access audible emergency information. The Commission stated that the Second Accessible Emergency Information Order would become effective 30 days after publication in the Federal Register. The Federal Register published a summary of the Second Accessible Emergency Information Order on July 10, 2015. Accordingly, the rules adopted in the Second Accessible Emergency Information Order will take effect on August 10, 2015.

In the Second Further Notice of Proposed Rulemaking adopted with the order, the Commission seeks comment on additional issues related to making emergency information audibly accessible to individuals who are blind or visually impaired, including: how to prioritize aural emergency information on the secondary audio stream; whether to continue to require school closing information to be included aurally on the secondary audio stream; and whether to require MVPDs to ensure that the devices and applications they provide to subscribers include a simple and easy to use activation mechanism for accessing audible emergency information on the secondary audio stream. The Commission set deadlines for filing comments and reply comments at 30 and 60 days, respectively, after publication of the Second Further Notice in the Federal Register. The Federal Register published a summary of the Second Further Notice on July 10, 2015. Accordingly, comments must be submitted no later than Aug. 10, 2015, and reply comments must be submitted no later than Sept. 8, 2015.

Read the FCC Public Notice

MB Docket No. 12-107

FCC Delays Requirement for Aural Representation of Visual Emergency Information on Secondary Audio Stream

By Chris Imlay, SBE General Counsel

On May 26, 2015, FCC issued a memorandum opinion and order addressing two petitions for waiver of Section 79.2(b)(2)(ii) of the FCC’s rules, which requires among other things that emergency information provided visually during non-newscast video programming be made audibly accessible to individuals who are blind or visually impaired through the use of the secondary audio stream. Broadcasters refer to this requirement as the “Audible Crawl Rule.”

The FCC granted a waiver of the rule for hybrid cable systems if they provide free equipment to analog customers who are blind or visually impaired to enable access to the digital secondary audio stream. The FCC also waived the compliance deadline for analog-only cable systems until June 12, 2018.

For broadcasters, the FCC granted only a six-month waiver of the compliance deadline. However, the FCC agreed to waive the requirement to aurally describe visual but non-textual emergency information, such as maps or other graphic displays for a period of 18 months. Broadcasters are, however, permitted to exclude school closings information from the Audible Crawl Rule. These three waiver provisions were granted at the behest of the National Association of Broadcasters in a March 27, 2015 petition for temporary partial exemption and limited waiver. The NAB Petition was strongly supported by SBE.

The six-month waiver (until Nov, 30, 2015) of the compliance deadline for video programming distributors of all sorts to comply with the Audible Crawl Rule by providing aurally on the secondary audio stream emergency information presented visually in non-newscast programming, was granted as a matter of necessity. The FCC was convinced that the technical means necessary for broadcasters to aurally transcribe emergency information text crawls on the secondary audio stream were not available from manufacturers in time for broadcasters to obtain and implement them by May 26, 2015, which had been the deadline. The FCC said it was persuaded by the NAB and the other broadcast industry comments that a six-month extension of the compliance deadline was needed for broadcasters to purchase, install, and test equipment and systems that will effectively communicate emergency information to their viewers who are blind or visually impaired.

About this, the SBE had noted that a 2013 report and order and further notice of proposed rulemaking in Docket 12-107 established rules for Text-to-Speech (TTS). These rules state that the three-beep alerting tones will be transmitted on both the main and secondary audio programming (SAP) channels. Currently, devices used to produce alerts and emergency crawls only provide alerting beeps on one set of audio channels. Also, the current rules state that the alerting tones are required on both audio channels. However, the actual text-to-speech would be required only on the SAP channel. The TTS audio cannot be mixed or ducted over program audio. Rather, it must completely override it. This override requires a complex series of switching audio paths. The problem is compounded by the fact that most modern stations use embedded audio in their Serial Digital Interface (SDI) video paths. In that circumstance, audio would have to be disembedded; switched to its proper path; and then re-embedded into the video signal for its output to the transmitter. Some stations may choose to run separate AES audio paths. However, this does not lessen the need to perform complex switching of audio, given the language of the current rules.

Few stations, however have one device that performs all its emergency crawl and alerting needs. A station may have one device that performs EAS tests and warnings; another that handles weather information; and a third that handles news bulletins. Vendors for these products have not to date created devices or sub-systems to perform the TTS required by the Commission. At the present time, no industry or other standard, voluntary or mandatory has been established to determine how each vendor will perform and execute the TTS functions. Stations therefore need time to test and evaluate the specifications of each vendor’s product to engineer a switching solution for each particular station configuration. Vendors are only just now making products available for testing or purchase.

With respect to the FCC’s 18-month waiver of the requirement to aurally describe visual but non-textual emergency information (e.g., maps or other graphic displays), in part for the reasons stated above, the FCC agreed with the NAB, SBE and others that radar maps and similar moving graphics do not contain text files that can be converted to speech and, therefore, an automated TTS system cannot be used to aurally describe them at the present time. Technical solutions to this can be developed within the Disability Advisory Committee. This is timely because visual but nontextual emergency information is generally duplicative of emergency information contained in an accompanying on-screen crawl, which can be aurally transcribed on the secondary audio stream.

About this, the SBE said in comments that there is currently no mechanism to perform this function. Compliance with the requirement by the former deadline would have required stations to input written descriptions of the map or graphics into the crawl information for the TTS to convert to audio. Most systems automatically produce crawl information either from the National Weather Service (NWS) or from the creator of an EAS alert. To insert the written descriptions, stations would have to manually modify crawl alerts and emergency text information. Currently, that would require manually retyping alerts and emergency messages. The additional time was needed to modify systems to perform those functions and to create new work flows so the requirement can be implemented. Stations in smaller markets that do not yet require video description service (VDS) will have to build these systems in their plants to allow the TTS service to be used. Such an added requirement could not have been accomplished by the former May 26, 2015 deadline under the circumstances.

Finally, the requirement to include school closings information aurally on the secondary audio stream was waived pending reconsideration of the requirement in Docket 12-107 pursuant to a further notice of proposed rule making released earlier in May. Broadcasters argued that an alternative solution is needed because audible crawls of school closings would continue for long periods of time and preclude other programming. The SBE said that this is because all TTS announcements must be repeated twice as they are crawled across the screen. Furthermore, school closing crawls in particular have two inherent characteristics that make implementing this problematic as a practical matter: 1) they are very long; and 2) they are often changed and updated in real time. According to the rules now in place, every change or update to school closing information would have to be announced twice. While this can be performed by the system, it makes the SAP channel otherwise unusable as a source of audio programming for viewers using it as a second language channel or for sight-impaired people to use it as a video description service (VDS) channel. The TTS announcements could possibly last for periods of 30 or 45 minutes, or even an hour at a time.

The short waiver periods granted by the FCC show that the Commission is committed to implementing these rules as soon as possible. The FCC waited until the very last second to grant the Audio Crawl Rule waivers, but the relief from the waivers is important because there was in fact no way to comply with the requirements as a technical matter. It remains to be seen if the situation improves markedly in the next six months.