[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