2024-05912. 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 [e-mail] 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 [e-mail], or George Donato, Associate Division Chief, Cybersecurity and Communications Reliability Division, Public Safety and Homeland Security Bureau at [e-mail] 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 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 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 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 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 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 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.