The Emergency Alert System; Correction, 19789-19795 [2024-05912]

Agencies

• FEDERAL COMMUNICATIONS COMMISSION

[Federal Register Volume 89, Number 55 (Wednesday, March 20, 2024)]
[Proposed Rules]
[Pages 19789-19795]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2024-05912]


=======================================================================
-----------------------------------------------------------------------

FEDERAL COMMUNICATIONS COMMISSION

47 CFR Part 11

[PS Docket No. 15-94; FR ID 209369]


The Emergency Alert System; Correction

AGENCY: Federal Communications Commission.

ACTION: Proposed rule; correction.

-----------------------------------------------------------------------

SUMMARY: This document corrects the Synopsis and Initial Regulatory 
Flexibility Analysis to the proposed rule published in the Federal 
Register of March 7, 2024, regarding the Emergency Alert System. This 
correction clarifies the issues upon which the Commission seeks comment 
and condenses the Initial Regulatory Flexibility Analysis.

DATES: Comments on the NPRM are due on or before April 8, 2024, and 
reply comments are due on or before May 6, 2024.

ADDRESSES: You may submit comments, identified by PS Docket No. 15-94, 
by any of the following methods:
     Electronic Filers: Comments may be filed electronically 
using the internet by accessing the ECFS: https://apps.fcc.gov/ecfs/.
     Paper Filers: Parties who choose to file by paper must 
file an original and one copy of each filing.
    Filings can be sent by commercial overnight courier, or by first-
class or overnight U.S. Postal Service mail. All filings must be 
addressed to the Commission's Secretary, Office of the Secretary, 
Federal Communications Commission.
     Commercial overnight mail (other than U.S. Postal Service 
Express Mail and Priority Mail) must be sent to 9050 Junction Drive, 
Annapolis Junction, MD 20701.
     U.S. Postal Service first-class, Express, and Priority 
mail must be addressed to 45 L Street NE, Washington, DC 20554.
     Effective March 19, 2020, and until further notice, the 
Commission no longer accepts any hand or messenger delivered filings. 
This is a temporary measure taken to help protect the health and safety 
of individuals, and to mitigate the transmission of COVID-19. See FCC 
Announces Closure of FCC Headquarters Open Window and Change in Hand-
Delivery Policy, Public Notice, DA 20-304 (March 19, 2020), https://www.fcc.gov/document/fcc-closes-headquarters-open-window-and-changes-hand-delivery-policy.
    People with Disabilities: To request materials in accessible 
formats for people with disabilities (Braille, large print, electronic 
files, audio format), send an email to [email protected] or call the 
Consumer & Governmental Affairs Bureau at 202-418-0530 (voice) or 202-
418-0432 (TTY).

FOR FURTHER INFORMATION CONTACT: For further information concerning the 
information contained in this document, send an email to David Munson, 
Attorney Advisor, Cybersecurity and Communications Reliability 
Division, Public Safety and Homeland Security Bureau at 202-418-2921 or 
[email protected], or George Donato, Associate Division Chief, 
Cybersecurity and Communications Reliability Division, Public Safety 
and Homeland Security Bureau at [email protected] or call 202-418-
0729.

SUPPLEMENTARY INFORMATION:

Correction

    In the Federal Register of March 7, 2024, 89 FR 16504, on pages 
16504-16509, the Synopsis and Initial Regulatory Flexibility Analysis 
should be replaced with the corrected Synopsis and Initial Regulatory 
Flexibility Analysis sections below.

Synopsis

    In furtherance of the Commission's continued emphasis on improving 
the accessibility of alerts, we seek comment on additional measures to 
promote multilingual EAS. As the Commission observed in 2016, when it 
required reporting of multilingual activities as updates to State EAS 
Plans, ``[t]o the extent that the reports suggest that [those who do 
not have a proficiency in English] are not receiving critical emergency 
information, the Commission . . . can assess, if appropriate, what 
further steps should be taken.'' In light of the minimal issuance of 
EAS messages in languages other than English, we believe it is now 
appropriate to take further steps to promote multilingual alerting.
    Accordingly, as detailed below, we seek comment on the efficacy and 
feasibility of distributing multilingual EAS messages in the form of 
brief, pre-scripted (or ``template'') alerts in Arabic, Chinese, 
French, German, Haitian Creole, Hindi, Italian, Korean, Portuguese, 
Russian, Spanish, Tagalog, and Vietnamese, as well as in English. The 
template scripts (in all languages) would be stored in EAS devices, and 
the translated audio for each template would be provided as audio files 
or links to streaming audio. EAS Participants would be required to 
transmit template alerts using the template audio and script in the 
template language that correspond to the EAS Participants' primary 
language (i.e., the language of their programming content); where the 
EAS Participant offers multiple channels, it would transmit on such 
channels the template audio and script in the template language that 
corresponds to the language of such channels.
    Current CAP-Based Multilingual Approach. As an initial matter, we 
observe that the ECIG Implementation Guide provides a process through 
which alert originators can specify distribution of their alerts in 
multiple languages, and EAS Participants can elect to distribute--or 
not distribute--the alert in those languages. Under those procedures, 
the alert originator specifies in its CAP alert instructions the 
language in which it desires the alert to be transmitted to the public, 
and the EAS device then will process and transmit the alert in those 
languages if (i) the language is the EAS Participant's ``primary'' or 
``secondary'' language that the EAS Participant has programmed its EAS 
device to process and transmit, and (ii) an audio file containing the 
translated audio or URL link to streaming translated audio is supplied 
by the alert originator, or TTS in that language has been configured in 
the EAS device. If the device is programmed to relay the primary 
language and secondary languages, the alert can be relayed in multiple 
languages as a single alert, provided the combined audio does not 
exceed 2 minutes and the combined visual crawl characters do not exceed 
1,800 characters (including the required header code information). In 
those instances where the message cannot meet the 2-minute and/or 1,800 
character limit, only the ``primary'' language is transmitted to the 
public as a self-contained alert--the ``secondary'' languages are 
transmitted after the original alert's End-of-Message codes (which 
terminates the alert) have run (i.e., after the alert is over, at which 
point, the additional languages are essentially being aired as regular 
programming (i.e., no EAS header

[[Page 19790]]

codes; no Attention signal; and no EOM codes--just a visual crawl and 
audio)). In either case, if translated audio for each language is not 
supplied or linked by the alert originator, TTS would be used, if TTS 
capable of verbalizing the language selected is configured in the EAS 
device. These procedures allow alert originators to effectively request 
transmission of alerts in non-English languages, but leave the decision 
as to which, if any, non-English language in which the alert will be 
transmitted to the EAS Participant (which it effects through programing 
its EAS device).
    Multilingual template alert processing. We propose to implement and 
require transmission of multilingual template EAS alerts in Arabic, 
Chinese, French, German, Haitian Creole, Hindi, Italian, Korean, 
Portuguese, Russian, Spanish, Tagalog, and Vietnamese, as well as in 
English. We propose that alert originators would initiate the template 
alert in legacy or CAP like any other EAS alert, using the applicable 
template event code. We propose that a new template-specific event code 
would be added to the EAS protocol for each template alert type 
(earthquake, wildfire, etc.). For example, if a template alert for 
earthquakes was added, there would be two earthquake event codes in the 
EAS Protocol: the existing earthquake event code that would be 
processed under existing rules, and the template earthquake event code, 
which would be processed under the specific template processing model 
described herein. The EAS device would use that event code to render 
that template (earthquake, wildfire, etc.) using the stored template 
text (for the visual crawl) and stored or linked audio in the languages 
that correspond to the language of the EAS Participant's programming 
content.
    We propose to require EAS Participants to transmit alerts in the 
language of the program content they transmit in instances where the 
alert originator elects to issue an alert using a template event code 
and the EAS Participant's programming content is in one of the 13 
proposed non-English template languages; the EAS Participant would 
transmit the alert using the English language template script and 
stored or linked audio, if the EAS Participant's programming content is 
in English or in a non-English language that is not one of the proposed 
non-English template languages. For music-oriented radio stations, the 
station's primary language would be the language its announcements and 
spoken communications. We are not proposing to mandate carriage of 
state and local alerts, we are proposing only that if the EAS 
Participant relays state and local alerts, it must relay template 
alerts as proposed herein. EAS Participants must of course relay alerts 
categorized as national alerts, thus, if a template were developed for 
the NPT or RMT, EAS Participants would be required to process those 
using the multilingual template processing requirements. This 
requirement would apply to each channel of programming provided by the 
EAS Participant. Accordingly, EAS Participants that provide multiple 
channels of programming would be required to ensure that for template 
alerts received, they transmit that alert on each channel they offer 
using the template audio and script language that corresponds to the 
programming content delivered over such channel. For example, a cable 
service that offers channels with English and Spanish language 
programming, would transmit the template alert on the Spanish language 
channels using the Spanish language audio and script associated with 
that template event code, and would transmit the template alert on 
English language channels using the English language audio and script 
associated with that template event code.
    Because multilingual alerts are likely to apply only to discrete 
geographic areas, and satellite providers transmit over nationwide 
footprints, we propose that DBS and SDARS providers would not be 
subject to these requirements, except that if a template is developed 
for the nationwide National Periodic Test (NPT) alert, DBS and SDARS 
providers would be required to overlay the NPT template English 
language audio and scroll on all channels.
    We seek comment on the foregoing construct generally, and more 
specifically with respect to the various alerting elements involved 
below. We observe that while EAS Participants would be required to 
transmit the template alert on a given channel using the template audio 
and script language that corresponds to the programming content of that 
channel, they may also include template audio and script in languages 
that do not correspond to the programming content. Thus, for example, a 
station that broadcasts Spanish-language programming would be required 
to transmit the template alert using the Spanish-language audio and 
script associated with that template event code, but could, if it 
elected to, also transmit the English audio and script for that 
template alert code (as discussed below, the Spanish and English audio 
and scripts could be combined into a single alert). In all events, the 
alert originator need not identify the specific languages in which they 
desire to have the template issued, because the template would be 
transmitted to the public by EAS Participants in the template language 
that matches their programming (and possibly other language, if the EAS 
Participant so elected).
    Should EAS Participants be allowed to transmit template alerts on 
channels in languages that do not correspond to the programming content 
offered on that channel? Or, to reduce the potential programming 
interruption, should we require EAS Participants to transmit templates 
only in the language that corresponds to their programming content 
(e.g., the Spanish language template would be transmitted on channels 
carrying Spanish language programs)? Should English be the default 
language in cases where the program content is in a non-English 
language that is not one of the proposed 13 non-English template 
languages? In cases where the EAS Participant's programming content is 
in one of the proposed 13 non-English template languages, should EAS 
Participants be required to transmit the template alert using both the 
non-English language and English audio and script for that template 
event code (i.e., as a combined alert), assuming the combined version 
meets the 2-minute and 1,800 character thresholds described above (or 
if the combined alert does not meet the 2-minute and 1,800 character 
thresholds, transmitting the non-English template audio and script as a 
single alert, and transmitting the English audio and script directly 
after the non-English version of the alert is completed)? NCTA suggests 
that Multichannel Video Programming Distributor (MVPD) architecture, as 
it presently exists, does not support the multilingual alerting 
approach outlined here. We seek comment on the particular 
considerations and steps associated with implementing template-based 
multilingual alerting for EAS in MVPD systems.
    We also seek comment on whether additional languages to the 13 non-
English languages specified above could and should be supported through 
this construct. Are there technical impediments to multichannel video 
programming providers, including DBS and SDARS providers, overlaying 
differing audio and script messages on different channels? Could these 
providers instead combine template audio and scripts in different 
languages into a single alert with template audio and script in 
different languages (but not exceeding the 2-minute limit for audio 
messages or the 1,800 character

[[Page 19791]]

limits for the scroll) that could be transmitted like any other alert? 
Seeing as the audio associated with a template alert received in legacy 
format would be discarded by the EAS device (which would use the stored 
or linked template audio appropriate to the EAS Participant's 
programming content), is the 2-minute limit on alert audio relevant to 
how each EAS Participant processes a template alert? Would it be 
necessary to increase the existing 2-minute for template alerts to 
accommodate transmission of template alerts that combine multiple 
languages? Could the 1,800 character limit also be increased for such 
purpose?
    Should alert originators be able to request transmitting the 
template alert in one or more of the proposed 13 non-English template 
languages and/or English similar to how this capability is facilitated 
in the ECIG Implementation Guide multilingual procedures? For example, 
alert originators could initiate the template alert in CAP like any 
other EAS alert, using the applicable template event code. In the CAP 
instructions, the alert originator could identify the template 
language(s) in which it would like the alert to be transmitted. The EAS 
device would use that event code to render that template (earthquake, 
wildfire, etc.) using the stored template text and stored or linked 
audio in the languages (i) requested by the alert originator that (ii) 
correspond to the ``primary'' and ``secondary'' languages it is 
programmed to process. Under this construct, EAS Participants would be 
required to program into their EAS device the language of their 
programming content as their ``primary'' language and then could elect 
to program other template languages in which they are willing to 
transmit the template alert as ``secondary'' languages--meaning they 
would only be required to transmit the template in their primary 
programming language, but could voluntarily include other template 
languages. EAS Participants that provide multiple channels of 
programming would need to be able to program their EAS devices so that 
channels carrying non-English language programming were assigned as 
``primary'' languages the template language that matches their 
programming content. The CAP-based template alert would be converted 
into an EAS protocol-compliant alert for transmission to the public 
just like any other CAP EAS alert, using the appropriate template event 
code. Because the EAS Protocol lacks any mechanism to specify or 
request a template language (including English), the EAS device 
receiving a template alert in legacy format would broadcast the alert 
using the script and audio that corresponds to whichever language is 
programmed as its ``primary'' language. Thus, for example, if a 
template alert were received in legacy form with Spanish language, the 
EAS device receiving that alert would process that alert like any EAS 
alert: first it would check IPAWS for a CAP version of that alert per 
the CAP prioritization requirement; then, if no CAP version was 
available, it would broadcast that alert anew using (i) the template 
script and audio that correspond to the template event code in the 
received legacy-formatted alert (the audio of the received legacy-based 
template alert would be discarded), (ii) in the EAS device's 
``primary'' language. We seek comment on this approach.
    Visual crawl. With respect to the visual message generated for EAS 
alerts, we observe that the EAS already uses a pre-scripted visual 
message for National Periodic Test (NPT) alerts received in legacy EAS 
format, and this approach suggests that multilingual templates with 
pre-scripted visual messages are feasible. For example, the NPT script 
states: ``This is a nationwide test of the Emergency Alert System, 
issued by the Federal Emergency Management Agency, covering the United 
States from [time] until [time]. This is only a test. No action is 
required by the public.'' The ``from [time] until [time]'' portion of 
the text is derived from the alert's release date/time and valid time 
period header codes. It appears viable to use a similar approach with 
pre-scripted text messages in non-English languages that would 
correspond to template event codes. First, as discussed further below, 
because providing audio translations (in pre-recorded audio files or 
links to streaming audio) that include location and time parameters is 
impractical, and reliable TTS for all template languages may not be 
available, one approach for the visual scroll would be to make template 
scripts that are static and provide only general information (e.g., ``A 
wildfire alert has been issued for your area. Please contact local 
authorities or check local news sources for more information.''). In 
this case, the entirety of the script message could be scrolled 
(subject to any character generation limitations) and matching 
translated audio could be provided.
    We seek comment on the feasibility and efficacy of this approach. 
Could generalized text lacking location and applicable time frames 
effectively warn the public of an impending emergency? Would 
transmitting such generalized alerts actually cause confusion to the 
public, particularly given the large geographic service areas 
associated with full-power broadcast stations? For example, the service 
areas and resolvable signal of full-power broadcast stations can span 
multiple states, thus, an alert that indicates that ``a wildfire alert 
has been issued for your area'' that was issued for a single county in 
Virginia might be received in upper New York State, with audiences 
throughout wondering whether the wildfire is a danger to their 
immediate areas. Would including a URL address (e.g., 
www.moreinfo.com), if feasible, where template alert audiences could 
obtain additional and more specific information make the generalized 
script approach more effective and reduce any potential for confusion? 
Alternatively, could the location and applicable time periods be 
conveyed in English? For example, could the visual messages for non-
English language template alerts contain expressions of time using 
digit numbers (typically with a.m. or p.m. included) and locations in 
English, both of which the EAS device can provide?
    We seek comment on which approach(s) could be feasibly and 
practically implemented in EAS devices. We observe, for example, that 
having variable information in the script could significantly impact 
the audio. As explained below, generating matching audio for fixed 
scripts involves only installing prerecorded audio files or links to 
streaming audio for each such script on the EAS device. Generating 
audio for scripts with variable information would effectively require 
use of TTS to capture each variation, but it is unclear whether cost-
effective non-English language TTS reliable and accurate enough for 
emergency warning purposes is available at this time. The number of 
characters in a script also impact how it can be processed using the 
two-minute/1,800 character limits for audio and text. We seek comment 
on the interplay of these factors including the relative costs involved 
in implementing fixed scripts versus variable scripts. We also observe 
that visual scrolls in EAS Participant systems are typically generated 
by processing systems downstream from the EAS device. Are the character 
generators used in existing downstream processing systems of 
broadcasters and cable systems capable of generating the character and 
punctuation sets for all 13 of the proposed template languages? If not, 
what modifications to downstream processing systems would be required 
to reliably scroll all 13 languages, and what costs would be implicated 
in such modifications? Assuming that all

[[Page 19792]]

template scripts were stored on the EAS device, would initiating and 
posting template alerts present any technical issues for IPAWS?
    American Sign Language (ASL). Approximately more than half a 
million people use ASL to communicate as their native language. We seek 
comment on the feasibility of developing and implementing ASL files for 
template alerts. Could video files of qualified ASL signers signing the 
template script for each template event type be developed and stored in 
the EAS device? Would ASL be processed like any other non-English 
language? How would the ASL be displayed? Would the potential variation 
in specific details of the alert (like applicable times, and location 
information), if included in the template version, present impediments 
to conveying the alert in ASL? If scripts were fixed, such that there 
would only be as many as there were template event types (earthquake, 
wildfire, etc.), how much memory capacity would be required (on 
average) to store, for example, 16 template ASL video files? Is 
sufficient spare memory capacity available in EAS device models in 
deployment today to accommodate such ASL file storage, or could these 
be stored in an external hard drive or thumb drive connected to the EAS 
device? In cases where the alerts are no longer static, are there ways 
to insert fillable video-based information using artificial 
intelligence driven technologies? Would the ASL be identical for non-
English language script (i.e., no variation based on the template 
language script and audio with which it is being transmitted)?
    Template Audio. We propose that audio matching the template script 
would be prerecorded for each template, in all proposed 13 non-English 
languages as well as English; EAS Participants could download and store 
the prerecorded audio files for the language(s) of their programming 
content, and any other languages they wish to include in their template 
alerts, in their EAS device. What memory requirements would apply to 
storing prerecorded audio files for each template? For example, 
assuming the audio length did not exceed 30 seconds and there were 16 
template audio files for each of the 13 proposed template languages, in 
addition to the English language version (for a total of 224 audio 
files), how much memory would be required to store such files? Is spare 
memory capacity sufficient to accommodate such storage available in EAS 
device models in deployment today, or could such files be stored on an 
external hard drive or thumb drive connected to the EAS device? Could a 
given template script be conveyed in a single audio version for each of 
the proposed 13 non-English languages? For example, there is no single 
``Chinese'' language, but rather a multitude of dialects, such as 
Mandarin and Cantonese. What mechanism would be practical and efficient 
for the Commission to employ in identifying specific dialects in which 
to prerecord the audio messages? Which of the proposed 13 non-English 
languages might require development of dialect-specific audio? 
Prerecorded audio also could be made available via a URL link provided 
in a CAP-formatted alert. Because such a URL reference cannot be 
conveyed in a legacy-formatted alert, the relevant template alert audio 
would have to be stored on all EAS devices, or the URL addresses would 
need to be determined and relayed to EAS devices as software updates. 
We seek comment on the relative merits of using linked audio versus 
stored audio.
    We propose to use static, pre-recorded audio messages for use in 
connection with template-based alerts. While TTS functionality 
developed for each template alert and language could be used in theory, 
and is one of the mechanisms for generating audio in the ECIG 
Implementation Guide's multilingual alerting procedures, we have 
concerns regarding the reliability of TTS for the template languages we 
propose to use for pre-scripted translations. We seek comment on 
whether TTS is available or could be developed in the 13 non-English 
template languages that would be sufficiently reliable and accurate to 
use in generating the audio portion of a multilingual template alert 
from its fixed script. Would inclusion of specific identifying alert 
elements--such as time periods, affected area names, and originating 
source of the alert--have any appreciable impact on the feasibility and 
reliability of using TTS to generate template audio for any of the 13 
template non-English languages and the English language version? Would 
integrating the presumably limited TTS functionality required to 
verbalize the template scripts require anything more than software 
changes to the installed base of EAS devices? Would using existing TTS 
solutions or TTS developed specifically to verbalize the information in 
the template scripts be less costly to implement in EAS devices than 
storing audio files in the EAS device or providing links to streaming 
audio (assuming a source(s) for the streaming audio is operated 
independently from EAS Participants)? Could the installed base of EAS 
device models in use today be updated for either approach? Is streaming 
template audio from an external source an efficient and more cost-
effective alternative to storing audio files on the EAS device? Would 
transport latencies create significant delays in completing these 
streaming sessions?
    Simulcasting. Simulcasting configurations typically involve a 
single program stream that is transmitted from one source with remote 
(repeater) stations rebroadcasting 100% of that program stream. In 
these configurations, the EAS alert is overlaid onto the program stream 
at the originating source facilities--the remote (repeater) stations do 
not have EAS devices at their locations. Because the geographic areas 
in which the remote (repeater) stations are located often are not the 
same as the geographic area of the originating source of the program 
stream (wherein EAS is overlaid onto the program stream)--meaning EAS 
alerts issued for the originating source's county may not apply to the 
county in which the remote (repeater) station is located--the 
originating source typically only relays national alerts, and statewide 
alerts (if the originating source and remote (repeater) stations are 
all located in the same state). Given that multilingual alerting is 
highly location-specific, would it be useful to limit use of 
multilingual templates in these configurations to those issued 
nationally or on a statewide basis (where all counties are affected), 
assuming any template would ever be issued on such a basis?
    Changes to Standards and Equipment. We seek comment on whether 
changes would be required to any IPAWS instructions or the ECIG 
Implementation Guide to facilitate the template alert processing 
approach described above. We also seek comment on what changes would be 
required to EAS devices and downstream or upstream processing systems 
to implement the template alert approach described above. What would be 
the costs of any such changes?
    Integrating Consumer Choice Into Multilingual Template Alerting. As 
indicated above, EAS Participant transmissions typically are not 
processable by the end user devices that receive them. Thus, the 
template alert processing approach relies on alert originators and EAS 
Participants, who presumably both know the public segments they serve, 
to choose the template language version that is appropriate to their 
audiences. We seek comment on whether and how template alerting in EAS 
could be augmented, in

[[Page 19793]]

transmission or presentation over EAS Participant platforms, to provide 
end users with an ability to choose which template version language 
they experience individually. Could template alerts be transmitted on 
secondary channels and processed in accordance with end user 
preferences by compatible end user devices? Could cable systems 
transmit the template version(s) of an alert on force tuned channels 
and provide subscribers the choice of which version they would be 
force-tuned to in the set-top-box Graphic User Interface menus?
    In the WEA Accessibility Order, we directed the Public Safety and 
Homeland Security Bureau (Bureau) to propose and seek comment on a set 
of emergency alert messages for support via multilingual templates. As 
part of this process, the Commission directed the Bureau to seek 
comment on which messages are most commonly used by alerting 
authorities, as well as those which may be most time-sensitive and thus 
critical for immediate comprehension. We seek comment on whether we 
should follow this approach for identifying which messages should be 
made available as EAS template alerts, and whether the Bureau should 
establish a process for ongoing updates to such templates as 
appropriate. We also seek comment on whether the WEA templates should 
be used, in whole or in part, in EAS, if feasible.
    Benefits. As a general matter, improving access to alert 
information by people whose primary language is not English provides 
significant public safety benefits and is in the public interest. Our 
general findings concerning the benefits of improving accessibility to 
WEA alerts in different languages in the WEA Accessibility Order, which 
focused on template alert issuance to commercial mobile service end 
users, seems relevant in this regard. In that item, the Commission 
found significant benefits arising from enhancing language support 
through a template-based approach. The enhanced language support makes 
alerts comprehensible for some language communities for the first time, 
which helps to keep these vulnerable communities safer during 
disasters, and incentivizes emergency managers to become authorized by 
FEMA to distribute CAP-formatted alerts using IPAWS.
    These general benefits are not specific to CMS architecture, and it 
seems reasonable to expect similar benefits in the EAS context. While 
the multilingual benefits of template alerting in EAS may to some 
extent hinge upon EAS Participants agreeing to transmit template alert 
languages other than their programmed primary language, the template 
processing approach described above--where the alert content and 
processing options are fully transparent to the EAS Participant and 
installed in their EAS devices for automated processing--should make it 
easier for EAS Participants to confidently do so. To the extent that 
the template alert processing approach described above increases 
participation by EAS Participants and emergency managers in getting 
multilingual template alerts out to the communities that might 
otherwise not have any understandable warning of an impending emergency 
situation, there will be an incremental increase in lives saved, 
injuries prevented, and reductions in the cost of deploying first 
responders. Such result is expected because the template alerts 
proposed above would, for those alerts suitable to be relayed in pre-
scripted template form, be prepared by the Commission, thus, removing 
the burden of translation from alert originators.
    The expected benefits from the template alert processing approach 
described above include prevention of property damages, injuries, and 
loss of life. These benefits are expected to affect over 26 million 
people in the United States who report that they do not speak English 
very well or at all. A significant percentage of this group of 
individuals would benefit from accessing alerts in their primary 
language. Those who communicate in non-English languages are at risk of 
not understanding alert information that could otherwise prevent 
property damage, injuries, and deaths. Reduced confusion and increased 
trust in EAS through the enhanced language support also increase the 
likelihood that the public will follow alert instructions in the 
future.
    While it is difficult to quantify the precise dollar value of 
improvements to the public's safety, life, and health, making EAS 
alerts more accessible to people that might not otherwise understand 
their warning information or have alternate sources of such information 
in their primary language, would likely yield significant benefits to 
preservation of life and property in the event of such emergencies. 
There is great value in improved public safety for reducing the risk of 
avoidable deaths and injuries by better informing the public of pending 
emergencies. We seek comment on our assessment of the benefits and the 
potential for measuring those benefits.
    Costs. Without knowing precisely what changes would be required in 
EAS devices and potentially involved in interconnected transmission 
processing systems, it is difficult to estimate the total costs of 
implementing template alert processing in EAS. We observe, however, 
that the Commission has implemented changes to EAS involving software 
changes to EAS devices, which seem relevant to estimating the costs of 
implementing multilingual templates. Most recently, in the 
Comprehensible Alerts Order, which adopted EAS header code changes as 
well as visual crawl script for the NPT code, the Commission estimated 
costs in line with the costs for EAS header code changes adopted in the 
2016 Weather Alerts Order and the 2017 Blue Alerts Order. The 
Commission concluded in the Weather Alerts Order and the Comprehensible 
Alerts Order that the only costs to EAS Participants for installing the 
new event codes and EAS software, respectively, were the labor cost of 
downloading the software patches onto their devices and associated 
clerical work (the record indicated that the patches themselves would 
be provided free of charge). The Blue Alerts Order followed the same 
approach but also included relevant associated testing.
    Assuming that template alert processing can be implemented via a 
regular software update patch that EAS Participants install in the 
normal course of business, we would expect the costs of software 
installation, labor, and testing to install the patch likely would be 
similar to the industry-wide estimate for mandatory software updates in 
the Comprehensible Alerts Order. The Commission estimates that software 
labor industry-wide would not exceed 5 hours of labor multiplied by 
25,519 estimated broadcasters and cable head-ends, plus 1 SDARS 
provider and 2 DBS providers, for a total of 127,610 hours of software-
related labor, a figure which is likely an over-estimate. Using an 
average hourly wage of $60.07 for software and web developers, 
programmers, and testers, and factoring in a 45% markup of hourly wage 
for benefits, and a 5.5% inflation adjustment between 2022 and 2023, we 
estimate an hourly wage of $91.89. Using these estimates of 5 hours 
labor time at a cost of $91.89 per hour would result in a total labor 
cost to each EAS Participant for installing a software patch that 
configures the template mechanism in the EAS device of approximately 
$460, and an aggregate labor cost of approximately $12 million. We seek 
comment on whether this estimate is too high or too low, and we ask 
commenters to provide data

[[Page 19794]]

supporting either our cost estimate or a different estimate.
    We seek comment on the extent to which the changes required to 
implement the template alert processing approach described above could 
be implemented in a routine software update patch. Would a patch 
specific to the template mechanism (and not folded into a routine 
software update patch) be required, and at what cost to EAS 
Participants? How long would it take to develop, test and release such 
a patch? If existing EAS device models required adding memory capacity 
to enable in-device template audio file storage, could adding such 
memory be done in the field, and at what cost to EAS Participants? If 
TTS were used to generate the template audio from the script, would 
inclusion of the necessary TTS functionality require additional memory 
and at what cost? Are there any existing EAS device models in use in 
which implementing the template alert processing approach described 
above could not be effected using a software patch and instead would 
have to be replaced? What costs would be associated with such 
replacements? If changes would be required to transmission systems 
upstream or downstream from the EAS device, how long would those take 
to develop and implement, and at what cost to EAS Participants? Would 
changes be required to commercially available alert originating systems 
and software (e.g., Everbridge)? Are there more efficient and less 
burdensome alternatives that might achieve the same results?
    Based on the foregoing, assuming the template alert processing 
approach described above can be implemented via a routine software 
update patch, and other costs (including memory requirements or changes 
to upstream/downstream transmission) are relatively low, we would 
estimate that the total costs would be approximately $12 million. If 
accurate, that would in our view be far outweighed by the overall 
benefits to public safety and the public interest described above. We 
recognize, however, that there potentially could be costs associated 
with adding memory capacity, firmware and/or other modifications to EAS 
devices, and changes potentially could be required to downstream 
transmission processing systems. It is also conceivable that there are 
some older EAS devices in use today that could not be updated or 
modified to enable template alert processing and transmission. We seek 
comment on all of these factors. We observe that the record in this 
proceeding will clarify these issues, and we will revise our cost 
assessments accordingly. We seek comment on our estimates and any 
implementation costs we have not expressly contemplated above. If 
commenters disagree with our assessments, we seek alternative estimates 
with supporting data and information.
    ECIG Implementation Guide. In the event that the template alert 
processing approach described above would necessitate revisions within 
or an amendment to the ECIG Implementation Guide to facilitate such 
processing, and how long would it take to effect any such changes?
    EAS Devices. Assuming multilingual template alert text and audio 
can be integrated in EAS devices, and processing instructions can be 
implemented in such devices via software updates alone, how long would 
manufacturers require to develop, test and release such updates (and at 
what cost to EAS Participants)? If storage of template visual script 
and audio files in installed EAS device models were to require addition 
of memory capacity via firmware update or some other mechanism, how 
long would it take EAS Participants to acquire and install such memory 
capacity (and at what cost)? How much time likely would be required to 
implement a stored (audio and visual script) template alert mechanism?
    EAS Participant Transmission Systems. Would implementing the 
template alert processing approach present any unique challenges or 
require modifications with respect to EAS Participant transmission 
processing systems upstream or downstream from the EAS device that 
would impact the time required for implementation? For example, in the 
Comprehensive Alerts Order, the Commission provided cable operators 
with additional time relative to all other EAS Participant categories 
to comply with the required change to the text associated with the EAN 
event code due to software-related complexities associated with 
implementing such text in cable system processing equipment downstream 
from the EAS device.
    Providing Accountability Through Transparency Act. Consistent with 
the Providing Accountability Through Transparency Act, Public Law 118-
9, a summary of this document will be available on https://www.fcc.gov/proposed-rulemakings.

Initial Regulatory Flexibility Analysis

    In the NPRM, the Commission seeks comment on the efficacy and 
feasibility of implementing a process for distributing template-based 
EAS messages in the 13 most commonly spoken non-English languages 
(according to U.S. Census data)--Arabic, Chinese, French, German, 
Haitian Creole, Hindi, Italian, Korean, Portuguese, Russian, Spanish, 
Tagalog, and Vietnamese--as well as in English. The Commission proposes 
an approach for processing multilingual template EAS alerts that is 
fairly consistent with existing procedures for processing EAS alerts, 
and requests comment on specific relevant alerting elements, such as 
template-specific event codes, template script-based visual messages, 
and template audio. The Commission also proposes that EAS Participants 
would be required to transmit the template alerts in the non-English or 
English template language corresponds to the programming content of 
their channel(s); EAS Participants that provide multiple channels of 
programming (other than satellite-based EAS Participants that transmit 
on a nationwide basis) would transmit the template visual and audio 
messages on each channel in the language that corresponds to the 
programming content carried on such channel.
    The proposed action is authorized pursuant to: sections 1, 2, 4(i), 
4(n), 303, 335, 624(g), 706 and 713 of the Communications Act of 1934, 
as amended, 47 U.S.C. 151, 152, 154(i), 154(n), 303, 335, 544(g), 606, 
and 613.
    There are small entities among the current EAS Participants, which 
include 17,521 radio broadcasters and 8,133 other participants, 
including television broadcasters, cable operators, satellite 
operators, and other businesses in the industry segments that could be 
impacted by the changes proposed in the NPRM, as follows: Small 
Businesses, Small Organizations, and Small Governmental Jurisdictions; 
Radio Stations; FM Translator Stations and Low Power FM Stations; 
Television Broadcasting; Cable System Operators (Telecom Act Standard); 
Cable Companies and Systems (Rate Regulation); Satellite 
Telecommunications; All Other Telecommunications; Broadband Radio 
Service and Educational Broadband Service; Direct Broadcast Satellite 
(``DBS'') Service; Radio and Television Broadcasting and Wireless 
Communications Equipment Manufacturing.
    The proposed changes would impose new or modified reporting, 
recordkeeping or other compliance obligations on certain small, as well 
as other, entities required to distribute EAS alerts to the public 
(i.e., ``EAS Participants''), and entities that manufacture EAS 
equipment. The changes likely would require development and 
installation in existing

[[Page 19795]]

EAS equipment Text-to-Speech (TTS) functionalities, audio files, video 
files, text files and additional memory capacity, displaying EAS 
messages in a secondary language when requested by an alert originator, 
using predefined and installed text, audio and video files, that likely 
would require EAS equipment manufacturers to develop software updates 
to implement such changes in deployed EAS equipment and EAS equipment 
in production. EAS Participants would have to acquire, and install such 
software updates in their EAS devices.
    There are no federal Rules that May Duplicate, Overlap, or Conflict 
with the Proposed Rules. The Commission requests comment on 
alternatives.

Federal Communications Commission.
Katura Jackson,
Federal Register Liaison Officer, Office of the Secretary.
[FR Doc. 2024-05912 Filed 3-19-24; 8:45 am]
BILLING CODE 6712-01-P