PD BECS_Request For Information_Army ESINet_11FEB2026_Final.pdf

Distribution Statement A. Approved for Public Release: Distribution is Unlimited.

Page | 1

Request For Information (RFI) for

U.S. Army Closed Emergency Service IP Network (ESINet)

The Army Contracting Command - Aberdeen Proving Ground (ACC-APG), on behalf of the Capability Program Executive Command, Control and Communications-Network

(CPE C3N), Project Manager Integrated Enterprise Network (PM IEN), Product Director

Base Emergency Communications Systems (PD BECS), is issuing this Request for

Information (RFI) to conduct market research and assess industry capabilities and is seeking information on the estimated cost associated with establishing a closed Army

Emergency Service IP (Internet Protocol) Network (ESINet) with Next Generation Core

Services (NGCS) that will be integrated with the existing Army Voice Modernization

(VMOD) 2.0 infrastructure.

A closed Emergency Service IP Network (ESInet) is a secure, private, managed IP-based network dedicated to 9-1-1 emergency communications. It acts as the, high-reliability infrastructure for Next Generation 9-1-1 (NG9-1-1) systems, enabling Public

Safety Answering Points (PSAPs) to receive and share multimedia data like, video, text, and voice, while providing enhanced location accuracy and improved resilience. In essence, a closed ESInet replaces legacy, voice-only, copper-wire telephone systems with a robust digital foundation for modern, data-rich, emergency response.

1. Purpose

The purpose of this RFI is to conduct market research in accordance with FAR Part 10 to obtain industry input that will inform the Government’s understanding of available technical approaches and deployment considerations.

For planning and market research purposes only, respondents may, at their discretion, provide notional, non-binding cost range information or high-level cost drivers

Page | 2 associated with implementing a closed Army Emergency Service IP Network (ESINet) with Next Generation Core Services (NGCS) operating within the Army Voice

Modernization (VMOD) environment. Any cost information provided should be budgetary in nature, reflect order-of-magnitude considerations at a conceptual level, and be intended solely to inform the Government’s understanding of potential cost drivers, scalability considerations, and implementation tradeoffs. The Government is not requesting detailed pricing, cost proposals, or binding Rough Order of Magnitude

(ROM) estimates, and any cost information submitted will not be used for evaluation or comparison purposes.

The information received in response to this RFI will be used solely for planning and market research purposes and to assist the Government in refining a potential enterprise-level strategy for Army-owned and Army-operated Public Safety Answering

Points (PSAPs) under the PD BECS portfolio. Responses will support the Government’s assessment of technical feasibility, integration considerations, scalability, and cost drivers associated with potential ESINet and NGCS deployment models.

PD BECS is seeking information on all aspects of an upgrade to the existing Army Voice

Modernization (VMOD) infrastructure to include the engineering, installation, spare parts, training, and deliverable documentation requirements for the inclusion of policy engine and security stack technologies required to establish an Army ESINet within the

Army VMOD network. Future upgraded Army PSAPs shall interconnect with the Army

ESINet to receive and transfer Session Initiation Protocol (SIP) based 9-1-1 calls.

The supporting Internet Protocol (IP) telecommunications systems that are proposed to deliver the ESINet/NGCS capabilities will meet National Emergency Number

Association (NENA) i3 standards, as well as relevant Department of War (DoW) and/or

Army Risk Management Framework (RMF) requirements.

Respondents are requested to provide descriptive, experience-based information regarding the types of hardware, software, and supporting components that may typically be required to implement a closed Army ESINet with NGCS, based on the respondent’s understanding of applicable standards and enterprise architectures.

Responses should be provided in a white paper–style narrative format and submitted as a separate Microsoft Word document limited to five (5) pages. Optional tables, diagrams, or figures may be embedded within the Word document where helpful to convey architectural concepts, integration approaches, or notional component groupings. Responses should focus on technical considerations, assumptions, and lessons learned, rather than product-specific proposals or prescriptive designs.

Any site-specific or system background information provided in this RFI is furnished for informational purposes only and does not define or constrain future requirements.

Page | 3

This RFI does not constitute a solicitation, does not commit the Government to issue a solicitation or award a contract, and does not obligate the Government to pay for any costs incurred by respondents in the preparation or submission of information.

Participation in this RFI is strictly voluntary.

For planning purposes only, the Government anticipates that an initial Army ESINet capability could be fielded in the late FY27 to early FY28 timeframe; however, this timeframe is subject to change based on requirements refinement, funding availability, and acquisition strategy decisions.

2. Disclaimer

The information provided in this RFI is subject to change and is not binding on the

Government. The Government has not made a commitment to procure any of the items discussed, and release of this RFI should not be construed as such a commitment or as authorization to incur cost for which reimbursement would be required or sought.

3. Next Generation 9-1-1 (NG-911) Architectural Considerations

For market research and planning purposes, the Government is evaluating potential architectural approaches to support the initial fielding of an Army ESINet capable of enabling NG-911 services across Army-owned and Army-operated PSAPs.

From a notional planning perspective, the Government anticipates that the initial Army

ESINet capability would emphasize three primary functional objectives. These objectives include enabling support for SIP and Voice over Internet Protocol (VoIP) technologies for 9-1-1 call handling; facilitating the connection of NG-911 capable Army

PSAPs to an Army ESINet; and supporting the convergence of SIP based 9-1-1 traffic onto a unified IP transport stream capable of carrying data, voice, and video traffic as real-time services mature within the Army enterprise environment.

As the Army continues its transition toward enterprise Real Time Services (RTS) and

Unified Capabilities (UC), NG-911 capabilities are expected to evolve in parallel. The

Government anticipates that future PSAP modernization efforts would be designed to align with broader Army initiatives aimed at the progressive elimination of legacy Time

Division Multiplexing (TDM) telephony systems and the transition to IP based services.

Accordingly, respondents are requested to consider how proposed NG-911 approaches could accommodate such evolution over time.

In addition, any NG-911 capabilities contemplated under this RFI would be expected to align with applicable requirements and guidance outlined in the Defense Information

Systems Agency (DISA) NG-911 System Requirements Document (SRD), which is provided as an appendix for informational purposes. Compliance with relevant

Page | 4

Department of Defense and Army policies, including RMF considerations, is also a key planning consideration.

Consistent with current Department of War Chief Information Officer (DoW CIO) policy, unclassified IP and SIP trunking is anticipated to be supported between session control elements. Legacy telephony environments may require upgrades to support Local

Session Controller (LSC) and Regional Session Controller (RSC) constructs as described in applicable Unified Capabilities Requirements (UCR) documentation. A key architectural consideration for the Government is the ability to modernize PSAP capabilities within defined geographic regions in a manner that supports readiness for connection to an Army ESINet.

For market research purposes, respondents may consider and describe how existing

SIP enabled technologies within Army enterprise voice and transport environments, including capabilities associated with the Army VMOD environment, could potentially interoperate with or support a closed Army ESINet construct. Any such discussion is requested for informational purposes only and should not be construed as a

Government endorsement of a specific architecture, technology, vendor, or integration approach.

To provide additional context for the Government’s market research, respondents may also, at their discretion, include a brief summary of relevant prior experience associated with SIP-enabled enterprise voice, NG-911, ESINet, or similar mission-critical communications environments. If provided, this information should be limited to no more than one (1) page and may be presented in table format.

Such information may include, for example, contract or task order identifiers, customer type (e.g., Federal, State, or Local Government), a high-level description of scope, and the general timeframe of performance. This information is requested solely to inform the

Government’s understanding of industry experience and will not be evaluated, scored, or used to determine vendor eligibility for any future procurement.

3.1 NG-911 Architectural Considerations and Summary

From a notional planning perspective, a private Army ESINet with NGCS would interoperate with existing Army enterprise voice and transport capabilities, including the

Army VMOD environment, to support VoIP and SIP based 9-1-1 call handling across

Army-owned and Army-operated PSAPs, as well as interoperability with State and local

PSAPs as applicable.

3.1.1 Engineering and Documentation Considerations for ESINet/NGCS

Respondents are requested to describe engineering and documentation approaches typically associated with implementing an ESINet/NGCS capability within an Army

Page | 5 enterprise environment. Responses should address the following areas, using brief descriptive narratives sufficient to explain typical approaches, considerations, and practices, rather than simple statements of capability or experience.

Respondents are requested to describe engineering and documentation approaches typically associated with implementing an ESINet/NGCS capability within an Army enterprise environment. Responses should address the following areas, using concise descriptive narratives that explain how such activities are typically performed, key considerations, and lessons learned, rather than simple statements that the activity has been performed.

a. Approaches for conducting installation surveys, site assessments, and technical briefings to support system design and integration planning.

b. Considerations for engineering software and hardware components necessary to augment existing Army enterprise voice and transport infrastructure, including interoperability with the Army Voice Modernization (VMOD) environment.

c. Types of technical documentation typically developed to support system implementation and sustainment, such as “as-built” or “as-installed” drawings and configuration documentation.

3.1.2 NGCS Software and Integration Considerations

Respondents are requested to describe approaches, considerations, and assumptions typically associated with deploying and integrating NGCS software capabilities within an

Army enterprise environment that interoperates with existing Army voice and transport infrastructure, including the VMOD 2.0 environment. Areas of interest include integration with policy engines, session control elements, and security architectures necessary to support secure peering with external NGCS and ESINet service providers.

For planning and market research purposes, respondents may, at their discretion, address how proposed approaches would interface with Government-provided NG-911

Geographical Information System (GIS) data feeds to support geographical location validation and call routing functions.

If respondents elect to address this topic, responses may include descriptive information related to the following areas, provided for informational purposes only:

a. Considerations for enabling Emergency Call Routing Function (ECRF) capabilities within an enterprise voice and transport environment.

b. Approaches for supporting Emergency Services Routing Proxy (ESRP) functionality through policy engine or equivalent technologies.

Page | 6

c. Security architecture considerations, including the use of stateful firewalls, session border controllers, or equivalent technologies, to support Mission Partner

Gateway (MPG) peering with commercial NGCS and ESINET service providers.

d. Installation, integration, and validation considerations associated with RSC environments, including notional locations such as Fort Belvoir and Fort Carson.

e. Integration of routing policy engines to support inbound SIP based 9-1-1 call routing and PSAP specific routing plans within the Army enterprise voice network.

f. Testing, validation, and transition activities typically associated with introducing

NGCS capabilities into an operational environment.

g. Development of configuration and system documentation typically required to support Government operations, sustainment, and oversight.

h. Warranty and technical support considerations commonly associated with newly deployed NGCS and ESINet technologies.

Information provided in response to this section is entirely optional, will not be evaluated or scored, and will not be used to assess vendor capability or eligibility for any future acquisition. Any discussion is requested solely to inform the Government’s understanding of potential architectural approaches and integration considerations.

3.1.3 Training Considerations

The Government is seeking information regarding training approaches typically associated with NG-911 system deployments. Respondents are requested to describe training options for Government voice network operators and NG-911 system administrators, including training scope, delivery methods, and notional pricing considerations. Any training information provided will be used for planning and market research purposes only.

4. Generic Switch Functional Considerations

Respondents may, at their discretion, provide information related to functional considerations associated with generic switching and session control capabilities that may be relevant to NG-911, ESINet, and enterprise voice interoperability within the

Department of Defense Information Network (DoDIN) environment.

The Government seeks information on how applicable DoW policies, requirements documents, and security guidance may inform technical approaches, interoperability considerations, and system design assumptions. The following documents are provided as reference material to support a common understanding of the operational and security context and are not intended to define finalized requirements.

Page | 7

4.1 Reference Documents

The following documents are referenced for informational purposes to support discussion of DoDIN interoperability, enterprise voice integration, and security considerations:

a. DoW Voice Networks UCR, 2013, Change 2.

b. VoIP Security Technical Implementation Guides (STIGs) and associated security checklists, latest approved editions.

c. Department of Defense Instruction (DoDI) 8010.01, Department of Defense

Information Network (DoDIN) Transport, 2018.

4.2 Army Interoperability Considerations

The DISA NG-911 SRD, provided as an appendix to this RFI, is included as a reference to inform industry understanding of interoperability considerations relevant to potential

ESINet and NGCS implementations within the DoDIN.

For market research and planning purposes, respondents may, at their discretion, reference how interoperability concepts, interfaces, and functional expectations described in the Defense Information Systems Agency (DISA) NG-911 System

Requirements Document (SRD) could inform architectural approaches, integration strategies, or system design assumptions for Army emergency communications environments. The SRD is provided for informational context only and is not intended to define finalized Government requirements, prescribe a specific solution, or serve as a basis for evaluation of vendor capabilities.

4.3 Information Assurance Authorization Considerations

Respondents are advised that telecommunications and information systems operating on Army IP networks are subject to applicable DoW and Army information assurance and cybersecurity policies, including requirements related to authorization under the

RMF prior to operational use.

For planning and market research purposes, respondents may, at their discretion, describe how proposed ESINet and NGCS approaches typically address authorization considerations, security controls, and lifecycle cybersecurity activities necessary to support an Authorization to Operate (ATO) within Army network environments.

Any information provided in response to this section is optional, informational only, and will not be evaluated, scored, or used to assess vendor capability or eligibility for any future acquisition. Information provided does not constitute finalized Government requirements and is intended solely to inform Government planning and requirements refinement.

Page | 8

4.4 System Hardware and Software Features

4.4.1 Army NG-911 System Description

From a notional planning perspective, NG-911 capabilities that may interconnect with an

Army ESINet with NGCS are expected to include SIP enabled Call Handling Systems

(CHS), Location Information Service (LIS) capabilities, NG-911 GIS data sources, and enterprise VoIP telephony infrastructure operating within the Army environment, including systems associated with the Army VMOD 2.0 architecture.

Architectural considerations include the ability of an ESINet/NGCS construct to interoperate with existing Army enterprise telecommunications systems to support end-to-end NG-911 call processing. References to ECRF capabilities and external NG-911

CHS functionality are provided for contextual understanding of the Army’s current operational environment and are not intended to represent a comprehensive or exhaustive set of NGCS services.

For planning and market research purposes, respondents may, at their discretion, describe how a broader set of Next Generation Core Services (NGCS) functional capabilities could inform architectural approaches, assumptions, and integration strategies. Respondents may also, where applicable, describe opportunities to host

NGCS software components within data center or enterprise hosting environments.

Any discussion of proposed software or system features is requested for informational purposes only to support market research and planning activities and should consider alignment with applicable NGCS functional concepts and National Emergency Number

Association (NENA) i3 standards. Information provided will not be evaluated, scored, or used to assess vendor capability or eligibility for any future acquisition.

4.4.1.1 Army ESINet/NGCS Framework

The diagram below is provided for planning and illustrative purposes only to convey a notional framework describing how an Army ESINet with NGCS could be structured to interoperate with existing Army enterprise voice, transport, and security environments.

This notional framework is intended to support industry understanding of potential architectural concepts, functional relationships, and interface points associated with an

Army ESINet/NGCS capability. It is not intended to represent a finalized design, required architecture, or preferred solution, nor does it establish system requirements or implementation direction.

Respondents may, at their discretion, use the below framework as contextual reference when describing alternative architectural approaches, integration strategies, assumptions, dependencies, and scalability considerations. The Government recognizes that viable ESINet/NGCS implementations may differ in structure, Page | 9 component placement, hosting models, or interface mechanisms based on technical approach and operational considerations.

Figure 1: Notional Army ESINet/NGCS Framework

4.4.1.2 ECRF Considerations

The Government is seeking industry input regarding ECRF capabilities that may be relevant to an Army ESINet and NGCS implementation. Respondents may, at their discretion, provide information considering functional, interoperability, and standards-based considerations typically associated with ECRF services within NG-911 architectures.

4.4.1.2.1 Standards Alignment

The following NENA standards are provided as reference material to inform industry understanding of commonly recognized ECRF functional and interoperability expectations within NG-911 environments. These references are provided for informational purposes only and are not intended to define finalized Government requirements or mandate compliance at this stage.

• NENA-STA-010.3b-2021, Section 4.3 (ECRF functional considerations)

• NENA-STA-010.3b-2021, Section 4.13 (ECRF interface and operational considerations)

• NENA-STA-005.1.2-2022 (NG-911 core services reference architecture)

Respondents may reference these or other applicable standards when describing architectural approaches, assumptions, and integration strategies relevant to ECRF functionality in an Army enterprise context.

4.4.1.2.1.1 ECRF Functional and Technical Considerations

For planning and market research purposes, the Government is seeking information regarding functional and technical considerations associated with Emergency Call

Page | 10

Routing Function (ECRF) services operating within an Army ESINet environment.

Respondents may, at their discretion, describe how ECRF capabilities are typically implemented to support accessibility, routing, and name resolution across emergency services entities within a secure enterprise network.

If respondents elect to address this topic, responses may include descriptive information related to the following considerations, provided for informational purposes only:

• Approaches for enabling ECRF query accessibility by emergency services entities operating within an Army ESINet environment.

• Use of SIP call routing mechanisms that rely on Fully Qualified Domain Names

(FQDNs) and SIP Uniform Resource Identifiers (URIs), including associated

Domain Name System (DNS) considerations consistent with STD 13 (Request for Comment (RFC) 1034) and Department of War DNS environments.

• Support for local DNS resolution capabilities by ESINet-connected elements to translate hostnames into IP addresses.

• DNS caching and resiliency behaviors, including approaches for handling expired cached resource records in scenarios where authoritative DNS servers are temporarily unavailable, consistent with concepts described in RFC 8767.

• Use of Domain Name System Security Extensions (DNSSEC), as described in

RFC 4035, particularly for authoritative DNS services resolving names associated with external ECRF interactions.

• Use of Service (SRV) records, as defined in RFC 2782, to support SIP services within domains containing SIP elements, including subdomains that may appear within SIP URIs.

• Location-to-Service Translation (LoST) query considerations, including resolution of Application-Unique Strings (AUS) represented as FQDNs using Uniform-Name

Authority Pointer (U-NAPTR) mechanisms (RFC 4848), and potential U-NAPTR resolution to obtain LIS URIs consistent with RFC 5986.

Information provided in response to this section is entirely optional, will not be evaluated, scored, or used to assess vendor capability or eligibility, and is requested solely to inform the Government’s understanding of potential ECRF implementation approaches and integration considerations.

Respondents may reference these or other applicable standards when describing architectural approaches, assumptions, dependencies, and integration strategies relevant to ECRF functionality within an Army enterprise context. References to specific standards are provided for informational purposes only and are not intended to define finalized Government requirements.

4.4.2 Route Query Considerations

Page | 11

The Government is seeking information regarding how ECRF services may process

LoST queries, as defined in Internet Engineering Task Force (IETF) RFC 5222, within an Army ESINet environment. Respondents may, at their discretion, describe approaches for authentication, query handling, routing determination, and response logic associated with emergency services routing.

Areas of interest include, but are not limited to, the following considerations:

• Approaches for determining whether a LoST query is received from an authenticated entity operating within the Army ESINet, such as a Call State

Processing Function or equivalent capability, and for identifying the type of service requested (e.g., emergency services).

• Authentication and transport security mechanisms commonly employed for entities initiating queries to an ECRF, including the use of Transport Layer

Security (TLS) and credentialing models that may leverage Department of War or other trusted certificate authorities within secure enterprise environments.

• Methods for handling queries originating from entities external to the Army

ESINet that may not possess Department of War credentials, including use of assumed or common public identities and differentiation of routing behavior based on the requested service. Such considerations may be applicable to

Mission Partner Gateway (MPG) interconnections with external ESINets.

• ECRF routing determination logic used to identify appropriate URIs to be returned in LoST responses, which may include SIP points of interconnection to the Army ESINet, URIs associated with PSAPs or Emergency Communications

Centers (ECCs), or URIs associated with other emergency services entities.

• Use of service boundary data within the ECRF, including one or more service boundary polygons with associated attributes that map specific service Uniform

Resource Names (URNs) to routing outcomes when a queried location falls within a defined boundary.

• Handling of routing responses when a queried location intersects multiple service boundaries associated with the same service URN, including policies for selecting a URI based on criteria such as geographic overlap, area precedence, or tie-breaking rules.

• Considerations for returning single versus multiple URIs in response to internal versus external queries, and for addressing potential conflicts in returned data through local policy at the querying entity.

• Use of querier identity, service URNs, or other contextual information to support accurate routing decisions for queries originating from within the Army ESINet environment.

Page | 12

References to specific standards, behaviors, or mechanisms are provided for informational context only and are not intended to define finalized Government requirements. Respondents may describe alternative or equivalent approaches that address similar routing, security, and interoperability objectives.

4.4.3 Service Boundary Considerations

The Government is seeking information regarding approaches used to represent, manage, and apply service boundary data within an ECRF operating in an NG-911 and

ESINet environment.

Areas of interest include, but are not limited to, the following considerations:

• Methods for representing location information using geodetic coordinates that correspond to defined geographic shapes, including the use of polygon sets to represent service boundaries. Such representations may include multiple polygons to account for non-contiguous service areas or service areas containing internal exclusions or “holes.”

• Approaches for associating service boundary polygon sets with emergency service URNs and corresponding URIs used for routing purposes. Attributes commonly associated with service boundary polygons may include identification of the applicable service URN and the URI to be returned when a queried location falls within the defined boundary.

• ECRF logic used to process LoST queries by identifying the service boundary polygon that corresponds to the requested service URN and contains the queried location, and by returning the associated URI. Considerations may include how overlapping boundaries are handled when the queried location is represented as a shape rather than a point, including use of selection algorithms such as greatest area of overlap or other precedence rules.

• Data stewardship and governance models for maintaining authoritative service boundary information, including approaches where emergency service authorities maintain source data for their respective jurisdictions and where such data may be aggregated at regional, Military Department, or enterprise levels.

• Operational models in which ECRF instances may be replicated across originating networks, including considerations for operation and maintenance of distributed ECRF instances while preserving the integrity, accuracy, and authoritative nature of the underlying service boundary data.

• Policy considerations that influence the granularity of routing data returned by the

ECRF, such as returning URIs associated with call state processing functions versus PSAPs, and how such policies may vary based on the identity of the query originator and or the requested service URN.

Page | 13

References to specific behaviors, data ownership models, or routing policies are provided for informational context only and are not intended to define finalized

Government requirements. Respondents may describe alternative or equivalent approaches that address similar functional, governance, and interoperability objectives.

4.4.4 Location Validation Considerations

The Government is seeking information regarding approaches for performing location validation functions within an ECRF operating in an NG-911 and ESINet environment.

Areas of interest include, but are not limited to, the following considerations:

• Methods by which an ECRF may validate civic location information against authoritative GIS data sources to determine whether a provided address can be uniquely identified within the database and is suitable for accurate emergency call routing and responder dispatch.

• Criteria commonly used to assess whether a civic address is sufficiently complete, specific, and reliable to support routing decisions and emergency response activities.

• Approaches that allow PSAPs or ECCs to submit location validation queries independent of inbound call signaling, such as for pre-validation, testing, or data quality purposes.

• Use of LoST mechanisms, including those described in IETF RFC 5222, to support location validation and routing determinations within NG-911 architectures.

References to specific validation behaviors, interfaces, or standards are provided for informational context only and are not intended to define finalized Government requirements. Respondents may describe alternative or equivalent approaches that address similar location validation, accuracy, and interoperability objectives.

4.4.5 NG-911 Call Handling Environment (CHE) Considerations

For planning and market research purposes, the Government is seeking industry input regarding Call Handling Environment (CHE) capabilities typically associated with NG-

911 operations and how such capabilities may be supported by, or integrated with, an

ESINet and NGCS architecture.

Respondents may, at their discretion, describe architectural approaches, functional considerations, and policy-driven mechanisms used to support call treatment, routing, overflow, failover, and media handling between Public Safety Answering Points

(PSAPs), Emergency Communications Centers (ECCs), and an ESINet.

Page | 14

If respondents elect to address this topic, responses may include descriptive information related to the following considerations, provided for informational purposes only:

• Call treatment and routing logic

• Capacity management, overflow, and alternate call treatment

• Media handling and situational awareness

• Resilience, failover, and continuity of operations

• Event notification and inter-PSAP coordination

Information provided in response to this section is entirely optional, will not be evaluated or scored, and will not be used to assess vendor capability or eligibility for any future acquisition. This information is requested solely to inform Government planning and market research activities and does not constitute finalized Government requirements.

Areas of interest include, but are not limited to, the following considerations:

4.4.5.1 Call Treatment and Routing Logic

• Approaches for routing emergency calls from initiating entities through the

ESINet to appropriate destinations based on call treatment logic, policy rules, and available location information, including civic, geographic, geodetic, or reference-based location data.

• Methods for determining call treatment based on factors such as call type, location, policy rules, and operational context, including handling of fragmented, incomplete, or malformed call records.

• Mechanisms for managing error conditions, such as missing or corrupted callback information or unavailable location data, through predefined policy-based treatments.

• Techniques for providing acknowledgements or status indications to originating devices based on identified call treatment, including messaging to confirm receipt of emergency communications (e.g., text acknowledgements).

4.4.5.2 Capacity Management, Overflow, and Alternate Call Treatment

• Approaches for managing call volume and capacity limits at PSAPs, including the ability to define thresholds for simultaneous emergency calls and to apply alternate call treatment when those thresholds are reached.

• Methods for implementing alternate call treatments, such as flexible queuing, network busy signals, recorded messages, interactive voice response, rollover to alternate PSAPs, or combinations of these approaches.

• Design considerations for ensuring sufficient bandwidth and transport capacity to support peak call volumes across supported media types, including voice, video, text, and associated multimedia.

Page | 15

• Techniques for overflowing emergency calls to designated alternate PSAPs or multiple PSAPs based on predetermined criteria, including considerations of receiving PSAP capacity and total call load.

• Approaches for identifying and managing potentially redundant emergency calls associated with the same incident within a dynamically defined geographic area, such as high-visibility or mass-notification events.

4.4.5.3 Media Handling and Situational Awareness

• Support for alternate call treatment and routing across multiple media types or combinations of media, including voice, video, text, emergency event notifications, and sensor or alarm-based inputs.

• Capabilities for PSAPs to accept additional media from callers, such as images or other data, to support situational awareness and response decision-making.

• Visual or operational indicators that inform PSAP personnel when calls are overflowing, as well as indicators at receiving PSAPs or alternate locations identifying the source of overflow traffic.

4.4.5.4 Resilience, Failover, and Security Considerations

• Approaches for supporting multiple predefined failover scenarios to maintain continuity of operations during system, network, or facility outages.

• Considerations for supporting backup PSAP operations, including scenarios where backup PSAPs may operate on the same or different ESINets.

• Mechanisms for supporting emergency call routing from any authorized entity capable of initiating an emergency call within the NG-911 ecosystem.

• Security considerations related to detecting and handling potentially malicious content, including approaches for isolating or “quarantining” calls and associated data while preserving the ability for call-takers to communicate with callers to assess whether a legitimate emergency exists.

4.4.5.5 Event Notification Integration

• Support for receiving emergency event notifications from authorized systems within the NG-911 environment.

• Use of standard interfaces to support the generation and ingestion of event notifications from authorized entities and systems operating within or connected to the NG-911 ecosystem.

The considerations described above are provided for informational and planning purposes only and are not intended to define finalized Government requirements or prescribe a specific implementation approach. Respondents may describe alternative or

Page | 16 equivalent methods that address similar operational, resilience, and interoperability objectives.

4.4.6 Call Authentication Considerations

The Government is seeking information regarding approaches for authenticating emergency calls as they enter an NG-911 call handling environment supported by an

ESINet and NGCS architecture. Call authentication is intended to ensure that originating providers or other authorized entities are permitted to proceed with call treatment and processing within the system.

Areas of interest include, but are not limited to, the following considerations:

• Methods for generating call detail records (CDRs) upon call entry into the system and for associating authentication-related information with those records.

• Approaches for recording certificate-based authentication outcomes, including successful and failed authentication events, within call detail records or associated logging mechanisms.

• Use of Secure Telephony Identity Revisited (STIR) and Secure Handling of

Asserted information using toKENs (SHAKEN) methodologies to authenticate originating providers or other responsible parties and to establish trust in call origination.

• Certificate management and authentication models that leverage strong cryptographic mechanisms, such as X.509 certificates, public key infrastructure, and certificate revocation processes, consistent with applicable RFCs and recognized best practices.

• Techniques for handling calls that cannot be authenticated, including policies governing call refusal, error handling, or notification mechanisms provided to originating entities or end users when authentication is unsuccessful.

• Methods for generating notifications or indicators when calls are successfully authenticated to support operational awareness, auditing, or downstream call processing decisions.

References to specific standards, cryptographic algorithms, or regulatory frameworks are provided for informational context only and are not intended to define finalized

Government requirements or prescribe a specific implementation. Respondents may describe alternative or equivalent approaches that address similar call authentication, trust, and security objectives within an NG-911 environment.

4.4.7 Communications Path Considerations

Page | 17

The Government is seeking information regarding approaches used to establish and manage communications paths between VoIP end instruments and PSAPs within an

NG-911 call handling environment supported by an ESINet and NGCS architecture.

Areas of interest include, but are not limited to, the following considerations:

• Methods for establishing, maintaining, and reestablishing a communications path between a PSAP and a VoIP communications device, including scenarios where a call is disconnected or abandoned prior to being answered by a call-taker.

• Approaches for enabling call-back capabilities from a PSAP to a communications device, including use of CDR data or other associated call metadata to identify available call-back methods.

• Techniques for presenting supported call-back communication options to call-takers when a call-back is initiated, and for recording the outcomes of call-back attempts for operational awareness and auditing purposes.

• Support for providing ring-back or other media to callers, where applicable, as part of call-back or reconnection workflows.

• Media handling considerations specific to emergency communications, including approaches where Voice Activity Detection (VAD) may be disabled or adjusted to support call quality and continuity.

• Mechanisms for maintaining connectivity with a caller’s device following premature disconnection, when supported by the originating network and consistent with system policy.

4.4.7.1 Additional Data Considerations:

The Government is also seeking information regarding approaches for acquiring, managing, and presenting additional data associated with emergency calls to support call processing and situational awareness.

Areas of interest include, but are not limited to, the following considerations:

• Policy-based mechanisms for determining which additional data queries are authorized and which data sources may be accessed during call processing.

• Methods for recording query parameters and query results associated with additional data retrieval within call detail records or related logging systems.

• Approaches for automatically executing certain data queries based on predefined policy rules and for indicating to call-takers when additional data is available.

• User interface considerations for accessing additional data in a streamlined manner, such as through a limited number of user actions, to support timely decision-making during emergency call handling.

Page | 18

• Techniques for acquiring and presenting additional data to call-takers, subject to applicable security controls and local policy rules, and for enabling authorized personnel to access and search such data.

• Support for integration with internal and external data sources, including information derived from SIP signaling, SIP headers, call detail records, building or floor plan data, medical or responder-relevant data, and other authorized sources.

• Capabilities for performing drill-down queries to obtain more detailed information related to an emergency call, and for selectively downloading data from external sources to support rapid retrieval under agreed-upon conditions.

• Approaches for associating additional data elements with specific calls, callers, locations, or emergency incidents, including the ability to distinguish between data related to a building or campus and data related to individual tenants or occupants.

• Methods for acquiring and presenting additional data based on the address of record of the caller or the location associated with the emergency.

The considerations described above are provided for informational and planning purposes only and are not intended to define finalized Government requirements or prescribe a specific implementation. Respondents may describe alternative or equivalent approaches that address similar communications, data integration, and operational support objectives within an NG-911 environment.

4.4.8 Location Validation Considerations

The Government is seeking information regarding approaches for receiving, validating, and managing caller location information within an NG-911 call handling environment supported by an ESINet and NGCS architecture.

Areas of interest include, but are not limited to, the following considerations:

• Methods for recognizing and processing caller location information formatted in accordance with NENA-approved standard formats and protocols, such as

Presence Information Data Format - Location Object (PIDF-LO).

• Techniques for identifying and handling unrecognizable or unsupported location data types received during call processing.

• Approaches for performing validation of civic address information to support accurate routing and emergency response.

• Mechanisms for detecting and managing garbled, incomplete, or malformed location data.

• Validation checks applied to location fields to ensure logical data ranges and logical content consistency.

Page | 19

• Use of default or fallback routing strategies in scenarios where location determination or validation cannot be completed successfully.

• Capabilities for receiving, filtering, and processing updates to location information as new or corrected data becomes available during the lifecycle of an emergency call.

• Handling of scenarios in which multiple locations may be associated with a single call, including interpretation rules, prioritization logic, and treatment by relevant functional elements within the NG-911 architecture.

• Support for location and address validation requests initiated by entities capable of routing emergency calls, consistent with system policy and security considerations.

The considerations described above are provided for informational and planning purposes only and are not intended to define finalized Government requirements or prescribe a specific implementation. Respondents may describe alternative or equivalent approaches that address similar location validation, data integrity, and routing support objectives within an NG-911 environment.

5.0 Supplementary Industry Input

5.1 Regional Distributed Architecture Considerations

The Government is seeking industry input regarding distributed and regional architectural approaches that may support NG-911 and ESINet operations within an

Army enterprise environment. Respondents may, at their discretion, provide descriptive, experience-based, and notional responses to the questions below. Responses should focus on architectural considerations, tradeoffs, and lessons learned rather than commitments or guarantees.

1. Assuming PSAPs are upgraded to support NG-911-compliant, SIP-based CHS, what architectural approaches could support the establishment of a regional construct using a centralized platform with remotely operated dispatch centers as a means of reducing the overall PSAP footprint? Please describe notional architectures that illustrate this approach.

2. Are there additional network elements, services, or supporting components typically required to enable SIP connectivity in an NG-911 environment that may not already be accounted for within a baseline NG-911 or ESINet design?

3. In scenarios where a centralized PSAP capability is geographically distributed to support continuity of operations, what practical considerations influence the physical separation distance between PSAP locations?

Page | 20

4. What latency considerations or tolerances are typically associated with split or geographically distributed PSAP operations in NG-911 environments?

5. Based on prior implementations or industry experience, what Recovery Time

Objective (RTO) and Recovery Point Objective (RPO) ranges are commonly achievable for failover between geographically distributed PSAPs, recognizing that actual values may vary based on architecture and implementation?

6. What architectural approaches are commonly used to support failover between

NGCS functional elements in a distributed environment?

7. In the event a primary PSAP is unavailable or unable to accept calls, what methods or workflows are typically employed to support failover to an alternate

PSAP within an NG-911 or ESINet construct?

8. What approaches could support interoperability between distributed Land Mobile

Radio (LMR) networks and a distributed ESINet architecture, and what considerations should be taken into account when integrating these environments?

9. In a distributed regional or CONUS-wide architecture, how is critical operational data (for example, caller location, incident status, responder tracking, or related situational data) typically synchronized between centralized platforms and remote dispatch centers to maintain data accuracy and operational awareness?

10. For integrated or hybrid cloud environments, what hosting and deployment models (for example, Government cloud, private cloud, or on-premises solutions) are commonly used to support NG-911 and ESINet capabilities while addressing

Department of War security, data sovereignty, and operational requirements?

5.2 Army ESINet/NGCS - Enterprise Operational Architecture Decomposition

Considerations

For planning and market research purposes, the Government is seeking industry input regarding how NG-911 and ESINet/NGCS capabilities may operate as part of a broader

Army enterprise communications environment, including interoperability with existing

Army VMOD capabilities.

Respondents may, at their discretion, describe enterprise-level operational activities, functional decompositions, and architectural elements that may be relevant to supporting ESINet and NGCS operations at scale. Responses should focus on notional operational constructs, functional groupings, and enabling technologies, rather than prescriptive solutions.

Page | 21

Information provided in response to this section is entirely optional, will not be evaluated or scored, and will not be used to assess vendor capability or eligibility for any future acquisition. This information is requested solely to inform Government planning and market research activities and does not constitute finalized Government requirements.

Responses should focus on notional operational constructs, functional groupings, and enabling technologies rather than prescriptive solutions.

1. From an enterprise operational perspective, are there additional operational activities, functions, or architectural elements that may warrant consideration to support ESINet and NGCS capabilities within the Army environment beyond those described in this RFI?

2. What technologies, platforms, or architectural approaches are commonly used to support ESINet and NGCS operational activities at regional, national, or international scale, and what tradeoffs or considerations should be taken into account when deploying such capabilities across a geographically distributed

Army enterprise?

5.3 Army ESINet/NGCS – Mission Partner Gateway (MPG) Considerations

The Government is seeking industry input regarding architectural, operational, and governance considerations associated with establishing MPG interconnections between an Army ESINet and commercial ESINet and…