NG911 SRD final v0.5.0 signed.pdf

Systems Requirements Document (SRD)

Global Public Safety Communications (GPSC)

Public Safety Answering Point (PSAP), Public Safety IP Network (PSInet) &

Next Generation Core Services (NGCS)

Submitted by: Jon Marcy (NetMaker Communications LLC) Lead Engineer DoD Office of Global Public Safety

Communications Modernization

Approved and Released by: John Holloway Director DoD Office of Global Public

Safety Communications Modernization

Version 0.5.0

PSAP, PSINET & NGCS SYSTEMS REQUIREMENTS DOCUMENT

Page ii of 84

DOCUMENT REVISION HISTORY

Project Name: Public Safety IP Network (PSInet)

Document Status (Draft):

Change

Request#

Document

Version

Approval

Dates Modified By Section, Page(s) & Text Revised

NA 0.1.0 NA F Black Initial Draft

NA 0.2.0 NA L Curling All – Complete re-map outline to match

Numbering Scheme. Add NS# to sections.

NA 0.3.0 NA L Curling All – Reformat to SRD format.

NA 0.4.0 NA L Curling All – Reformat to SRD format.

NA 0.4.2 NA L Curling All – Incorporate JITC feedback

NA 0.4.3 NA M. Fowler All – Edit, proof and format version 0.4.2

NA 0.4.4 NA L Curling All – Incorporate round 2 JITC feedback add

PSAP

NA 0.4.5 NA J. Marcy Added Section 4.7.4 Computer Aided Dispatch

NA 0.4.6 NA L. Curling All- Incorporate field comments

NA 0.4.7 NA L. Curling All- Requirement Numbering

NA 0.4.8 NA L. Curling All- incorporate PSAP/ECC change & Final

Review

NA 0.5.0 NA L. Curling FINAL

PSAP, PSINET & NGCS SYSTEMS REQUIREMENTS DOCUMENT

Page iii of 84

TABLE OF CONTENTS

Table of Contents

1 SCOPE

1.1 SYSTEM IDENTIFICATION

1.2 SYSTEM OVERVIEW

1.2.1 Location Information Service (LIS) / Geographic Information System (GIS)

1.2.2 Boundary Cloud Access Point (BCAP) / Voice Cloud Access Point (VCAP)

1.2.3 NGCS

1.2.4 MPG

1.2.4 Mission Partner Voice Enclave

1.2.6 PSAP/ECC

2 APPLICABLE DOCUMENTS

2.1 GENERAL

2.2 COMPANION DOCUMENT

3 COMMON PROTOCOL REQUIREMENTS

3.1 SYSTEM INTERNAL INTERFACE REQUIREMENTS

3.1.1 HTTP Enabled Location Delivery (HELD)

3.1.2 Location-to Service Translation (LoST)

3.1.4 IPV6

3.1.5 SIP 14

3.2 SYSTEM AVAILABILITY

4 FUNCTIONAL ELEMENT REQUIREMENTS

4.1 CSPR

4.1.1 CSPR Interface Support Requirements

4.2 PSPR

4.2.1 Summary

4.2.2 Standards

4.2.3 Set of requirements

4.3 LOCATION INFORMATION SERVER (LIS)

4.3.1 Summary

4.3.2 Set of requirements

4.4 SI/GIS

4.4.1 GIS Datastore Summary

4.4.2 Set of requirements

4.4.3 SI Summary

4.4.4 Set of requirements

4.5 PSAP/ECC

4.5.1 SIP Call interface

4.5.2 Test Calls

4.5.3 Call Diversion

4.5.4 Bridge Interface

4.5.5 Computer Aided Dispatch (CAD) / Unified CAD (UCAD)

4.5.6 Logging Service

4.5.7 Time Interface

4.5.8 GIS 27

4.6 SBC

4.6.1 SBC Requirements

4.7 SC/SS

4.7.1 SC Requirements

5 APPENDIX A - ACRONYM GLOSSARY

PSINET & NGCS SYSTEMS REQUIREMENTS DOCUMENT

Page ii of 84

6 APPENDIX B - SUPPORTED STANDARDS

7 APPENDIX C – CALL FLOW DIAGRAMS

8 APPENDIX D – FUNCTIONAL REQUIREMENTS DOCUMENT (FRD) FOR PUBLIC SAFETY

COMMUNICATIONS, VOLUME 1

Appendix D1 – Architecture Appendix D2 – Call Flow Appendix D3 – Service Creation Appendix D4 – Basic Services Data Associated with a Call Appendix D5 – Event Notification Appendix D6 – Security Appendix D7 – Service Management Appendix D8 – Roles and Responsibilities Appendix D9 – Profile Minimal-Profile Definition Appendix D10 – Call Handling/CAD Event Creation Appendix D11 – Dispatch Support Appendix D12 – Resource Management Appendix D13 – Call Incident/Event Management Appendix D14 – Supplemental Resource Request Tracking Appendix D15 – Incident Disposition Appendix D16 – Business Function/CAD Administration Appendix D17 – System Functions Appendix D18 – Reporting and Monitoring Appendix D19 – Interfaces Appendix D20 – Common Operational Picture (COP) Appendix D21 – GIS/CAD Mapping Integration Appendix D22 – 911 Telephony Integration and Data Standards Appendix D23 – References Appendix D24 – Acronyms and Definitions

Table of Figures

FIGURE 1. - DOD PSC OV-1 FIELDING 2023-2026

FIGURE 2. - DOD PSC OV-1 FIELDING 2027

FIGURE 3. - SIP LOCATION CAPABLE END INSTRUMENT

FIGURE 4. - LEGACY ANALOG/DIGITAL/SIP EI LOCATION INSERTED BY LSC . 40

FIGURE 5. - LOCATION INSERTED BY SBC IN RSC ARCHITECTURE

NG9-1-1 SYSTEMS REQUIREMENTS DOCUMENT

1 SCOPE

This document serves as the technical foundation and provides extensive external technical references for the Joint Interoperability Test Command (JITC) to build test plans and certify systems for the DoD Unified Capabilities Approved Products List (APL) in accordance with the

DODI 8100.04. This document is to be publicly releasable.

This document contains the text-based detailed requirements for the delivery of the Next

Generation Core Services (NGCS) elements as well as the Public Safety IP Network (PSInet) for

Global Public Safety Communications (GPSC). The final system architecture utilizes the standardized structure and design of the National Emergency Numbering Association (NENA) i3 framework to allow interoperability between the Department of Defense (DoD) PSInet and commercial emergency services IP networks (ESInet). Refer to the NextGen 9-1-1 Functional

Requirements Document (FRD) for additional framework guidance.

This document is intended to be updated regularly to enable the DoD to keep pace with industry standards, requirements, and Information and Communications Technology (ICT) and Cyber-

Supply Chain Risk Management (C-SCRM) best practices. Updates shall ensure continual interoperability and backwards compatibility with evolving NENA i3 standards. Maintaining full interoperability is required to guarantee call delivery to commercial Public Safety Answering

Points (PSAP)/Emergency Communications Centers (ECC) via the Mission Partner Gateways

(MPG).

The scope of this Systems Requirements Document (SRD) is to detail the requirements, specifications, systems, and interface requirements for all NGCS functional elements supporting the DoD PSInet for the GPSC i3-based ESInet. It details the specifications and behavior for all software products and services, hardware, and networks operating within the PSInet.

Additionally, detailed messaging definition for the PSInet is described as well as the interconnection between PSAP/ECCs and the PSInet, in addition to State/Municipal ESInet-to-

PSInet interconnections. Figures 1 and 2: DOD GPSC OV-1 provide an operational overview of the NG9-1-1 ecosystem out to 2027.

Figure 1. - DoD PSC OV-1 Fielding 2023-2026

Figure 2. - DoD PSC OV-1 Fielding 2027

1.1 System Identification

The Next Generation 9-1-1 system is comprised of the following subsystems:

1. Public Safety IP Network and associated NexGen core services.

2. Public Safety Answering Point and associated call handling and Computer Aided

Dispatch systems.

3. Location Information Services and associated Geospatial Information Systems.

1.2 System Overview

The scope of this system comprises the PSInet, NGCS, and PSAP/ECC interconnections. This system is composed of a series of interconnected subsystems. These subsystems often have overlapping technologies that are required for interoperability.

The PSInet shall consist of a virtual IP network—shared with the unclassified voice network— established on the DISA-managed global unclassified Multi-Protocol Label Switching (MPLS) network. Based on the establishment of an MPLS Virtual Routing and Forwarding (VRF) instance on the unclassified network, the PSInet shall consist of shared, geographically positioned policy-engine servers and the associated Session Border Controller (SBC) cybersecurity solutions of the Enterprise Voice Services (EVS) initiative. This configuration shall support the internal routing of Session Initiation Protocol (SIP)-based 9-1-1 calls to DoD

PSAP/ECC facilities as well as the ingress and egress of SIP-based 9-1-1 calls between the unclassified Voice over IP (VoIP) soft-switch backbone, MPG, and the PSInet.

1.2.1 Location Information Service (LIS) / Geographic Information System (GIS)

The establishment of LIS capabilities paired with accurate GIS data in the NENA i3 recommended format is a key factor of NG9-1-1. The DOD IP network shall be configured to provide locations of endpoints (i.e., calling devices). An LIS can provide Location-by-Reference or Location-by-Value. If employing Location-by-Value, the value can be in either geo

(latitude/longitude) or civic (street address) forms. LIS capabilities shall be established as part of the DOD VoIP framework and managed by the Components responsible for installation VoIP deployments and sustainment. IP voice capabilities shall include the ability to query an LIS and insert the received location information into the SIP header of a 9-1-1 call before the call is routed out of the originating voice enclave. Additional architectural and technical details are found in the Next Generation 9-1-1 Technical Architecture Document (NG9-1-1 TAD).

1.2.2 Boundary Cloud Access Point (BCAP) / Voice Cloud Access Point (VCAP)

In support of any FedRAMP-approved hosted software employed to deliver PSInet, NGCS, and

PSAP/ECC capabilities, the software shall obtain Impact Level 5 (IL5) Provisional Authority

(PA) to operate, as well as a valid Authorization to Operate (ATO) to connect to the DISA unclassified BCAP and/or VCAP. All SIP-based network traffic (i.e., signaling and media) shall traverse the VCAP, while all other TCP/IP-related network traffic shall traverse the BCAP. The

BCAP is currently planned to retire in 2026 with the architecture transitioning to Software

Defined Wide Area Networking (SD-WAN).

1.2.3 NGCS

The NGCS and PSInet make up the core call-routing subsystem responsible for ensuring calls routed to the correct PSAP/ECC. Unlike the commercial ESInets, the DISA shall establish a global PSInet to support all DoD users.

In the system core, the critical functional elements are: the SBC, Core Session Policy Router

(CSPR), Public Safety Policy Router (PSPR). The PSPR, as a product, shall incorporation the following NENA i3 functions: Emergency Call Routing Function (ECRF), and Location

Validation Function (LVF).

1.2.4 MPG

The MPG is the security boundary responsible for interconnecting the DoD PSInet to commercial ESInets. The MPG consists of the following functional elements: Firewalls, Intrusion Detection/Prevention Systems and SBCs. The interface between the MPG and ESInets will need individually designed to ensure proper call handling for both wireline and wireless calls. This is due to the fact every state has a potentially unique ESInet configuration. Wireless emergency services call which originates from a location serviced by a DoD PSAP/ECC will be routed from the commercial wireless carrier to the closest state ESInet. The caller’s location will be identified by a dynamic location reference in the call header. The servicing PSAP/ECC will de-reference the location reference by querying the location server in the carrier network to provide a dispatchable location.

1.2.4 Mission Partner Voice Enclave

In the mission-partner voice enclave, the critical functional elements to support NG9-1-1 are the end instrument (EI), Session Controller (SC), Location Information Services (LIS), and Session

Border Controller (SBC).

1.2.6 PSAP/ECC

The PSAP/ECC as defined in this document shall be an NG9-1-1 or legacy E9-1-1 emergency services answer-and-dispatch center located on a DoD facility in compliance with U.S. Federal laws.

Within the United States, 9-1-1 calls may be routed to a DoD Emergency Response Center (DoD

PSAP/ECC) or to a civil PSAP. The emergency-services network that handles DoD and PSTN

911 calls may be TDM-based or IP-based.

Outside of the United States, 9-1-1 calls may be routed to a DoD PSAP/ECC (if one exists at the

DoD location). If no DoD PSAP/ECC exists, 9-1-1 calls shall transit the PSInet and exit via the

MPG for delivery to the civil PSAP/ECC serving the caller location based on local policy.

2 APPLICABLE DOCUMENTS

2.1 General

Documents listed in this section are specified in sections 3, 4, or 5 of this SRD. This section does not include documents cited in other sections of this specification or recommended for additional information or as examples. While every effort has been made to ensure the completeness of this list, readers are cautioned that they should meet all specified requirements of documents cited in sections 3, 4, or 5 of this specification, whether they are listed in this section. The documents with links relevant at the time of publication are included in Appendix B.

2.2 Companion document

The SRD is meant to be used in conjunction with the Next Generation 9-1-1 (NG9-1-1) FRD serving as the Public Safety framework.

3 COMMON PROTOCOL REQUIREMENTS

3.1 System Internal Interface Requirements

3.1.1 HTTP Enabled Location Delivery (HELD)

PSI-000180 [Required: GIS, LIS, SBC, PSPR] The product shall support HELD is defined in

RFC 5985 and RFC 7840. HELD provides a non-SIP location delivery.

PSI-000190 [Required: GIS, LIS, SBC, PSPR] When responding to HELD, the product shall support Presence Information Data Format - Location Object (PIDF-LO) as described in IETF

RFC 4119 and updated by IETF RFC 5139 and IETF RFC 5491.

PSI-000200 [Required: GIS, LIS, SBC, PSPR] All geodetic data shall use WORLD

GEODETIC SYSTEM 1984 (WGS84) as the datum.

PSI-000210 [Required: GIS, LIS, SBC, PSPR] The representation of the location object within the Presence Information Data Format document shall utilize the <tuple> element as defined in

IETF RFC 4119.

PSI-000220 [Required: GIS, LIS, SBC, PSPR] A <geopriv> element shall describe a discrete location. Where a discrete location can be uniquely described in more than one way, each location description shall reside in a separate <tuple> element with only one <geopriv> element per <tuple>.

PSI-000230 [Required: GIS, LIS, SBC, PSPR] Providing more than one location element in a single <location-info> element should only be used to represent a compound location referring to the same place. For example, a geodetic location describing a point, and a civic location indicating the floor in a building at that point.

PSI-000240 [Required: GIS, LIS, SBC, PSPR] Elements evaluating a PIDF-LO shall respect the order of <geopriv> elements in the presence document received.

3.1.1.1 PIDF-LO

PIDF-LO is a core element for location data in an emergency services call containing the geographical location information describes a physical position in the world.

PSI-000250 [Required: GIS, LIS, SBC, PSPR] The product shall support the base function of

PIDF-LO as covered in RFC 4119 updated by RFC 5139. The GEOPRIV PIDF-LO is covered in

RFC 4119 updated by RFC 5491.

PSI-000270 [Required: GIS, LIS, SBC, PSPR] The product shall support the baseline PIDF usage of the GEOPRIV element in RFC 5139 Sec2.1.

PSI-000280 [Required: GIS, LIS, SBC, PSPR] The product shall support the location-info as defined in RFC 5139 sec 2.1.1.

PSI-000290 [Required: GIS, LIS, SBC, PSPR] The product may support the method as defined in RFC 5139 sec 2.1.3.

PSI-000300 [Required: GIS, LIS, SBC, PSPR] The product may support the provided-by as defined in RFC 5139 sec 2.1.4.

PSI-000310 [Conditional: GIS, LIS, SBC, PSPR] Where civic address data is used the function shall support the xml schema in RFC 5139 sec 4.

The following is an example of a Civic Address XML schema:

<?xml version="1.0"?>

<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:xml="http://www.w3.org/XML/1998/namespace" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>

<xs:simpleType name="iso3166a2">

<xs:restriction base="xs:token">

<xs:pattern value="[A-Z]{2}"/>

</xs:restriction>

</xs:simpleType>

<xs:complexType name="caType">

<xs:simpleContent>

<xs:extension base="xs:token">

<xs:attribute ref="xml:lang" use="optional"/>

</xs:extension>

</xs:simpleContent>

</xs:complexType>

<xs:element name="civicAddress" type="ca:civicAddress"/>

<xs:complexType name="civicAddress">

<xs:sequence>

<xs:element name="country" type="ca:iso3166a2" minOccurs="0"/>

<xs:element name="A1" type="ca:caType" minOccurs="0"/>

<xs:element name="A2" type="ca:caType" minOccurs="0"/>

<xs:element name="A3" type="ca:caType" minOccurs="0"/>

<xs:element name="A4" type="ca:caType" minOccurs="0"/>

<xs:element name="A5" type="ca:caType" minOccurs="0"/>

<xs:element name="A6" type="ca:caType" minOccurs="0"/>

<xs:element name="PRM" type="ca:caType" minOccurs="0"/>

<xs:element name="PRD" type="ca:caType" minOccurs="0"/>

<xs:element name="RD" type="ca:caType" minOccurs="0"/>

<xs:element name="STS" type="ca:caType" minOccurs="0"/>

<xs:element name="POD" type="ca:caType" minOccurs="0"/>

<xs:element name="POM" type="ca:caType" minOccurs="0"/>

<xs:element name="RDSEC" type="ca:caType" minOccurs="0"/>

<xs:element name="RDBR" type="ca:caType" minOccurs="0"/>

<xs:element name="RDSUBBR" type="ca:caType" minOccurs="0"/>

<xs:element name="HNO" type="ca:caType" minOccurs="0"/>

<xs:element name="HNS" type="ca:caType" minOccurs="0"/>

<xs:element name="LMK" type="ca:caType" minOccurs="0"/>

<xs:element name="LOC" type="ca:caType" minOccurs="0"/>

<xs:element name="FLR" type="ca:caType" minOccurs="0"/>

<xs:element name="NAM" type="ca:caType" minOccurs="0"/>

<xs:element name="PC" type="ca:caType" minOccurs="0"/>

<xs:element name="BLD" type="ca:caType" minOccurs="0"/>

<xs:element name="UNIT" type="ca:caType" minOccurs="0"/>

<xs:element name="ROOM" type="ca:caType" minOccurs="0"/>

<xs:element name="SEAT" type="ca:caType" minOccurs="0"/>

<xs:element name="PLC" type="xs:token" minOccurs="0"/>

<xs:element name="PCN" type="ca:caType" minOccurs="0"/>

<xs:element name="POBOX" type="ca:caType" minOccurs="0"/>

<xs:element name="ADDCODE" type="ca:caType" minOccurs="0"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:anyAttribute namespace="##any" processContents="lax"/>

</xs:complexType>

</xs:schema>

PSI-000320 [Required: GIS, LIS, SBC, PSPR] All functions shall prioritize geospatial

(GeoShape) data as defined in RFC 5491 sec 5.

PSI-000330 [Required: GIS, LIS, SBC, PSPR] The product shall support both 2D and 3D geospatial formats.

The following is a sample XML schema for a 2D location point:

<presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gml="http://www.opengis.net/gml" entity="pres:point2d@example.com">

<dm:device id="point2d">

<gp:geopriv>

<gp:location-info>

<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">

<gml:pos>-34.407 150.883</gml:pos>

</gml:Point>

</gp:location-info>

<gp:usage-rules/>

<gp:method>Wiremap</gp:method>

</gp:geopriv>

<dm:deviceID>mac:1234567890ab</dm:deviceID>

<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp>

</dm:device>

</presence>

3.1.2 Location-to Service Translation (LoST)

LoST – Location-to-Service Translation – LoST (RFC5222) is a protocol designed specifically to request and convey location information to and from a LoST server. In NG9-1-1 it is used for location-based call routing.

PSI-000340 [Required: CSPR, PSPR] All SIP-based emergency calls pass location information either by value (PIDF-LO) or by reference (Location URI) plus a Service URN to an Emergency

Services Routing Proxy (ESRP) to support routing of emergency calls.

PSI-000350 [Required: CSPR, PSPR] The CSPR shall process a LoST query to the PSPR when receiving an emergency call via a SIP INVITE.

PSI-000360 [Required: CSPR, PSPR] The CSPR shall pass the Service URN and location information via the LoST interface (as defined in IETF RFC 5222) to PSPR, which determines the next hop in routing a call to the requested service.

PSI-000370 [Conditional: CSPR, PSPR] If an element using LoST receives location by reference, it shall de-reference the URI to obtain the value prior to querying the LoST server.

The LoST server does not accept location by reference.

PSI-000380 [Required: CSPR, PSPR] The PSPR shall the map the call's location information and requested Service URN to a "PSAP URI" by querying its data and then returning the URI provided. Using the returned URI and other information (time-of-day, PSAP/ECC state, etc.), the

CSPR policy shall determine the appropriate routing URI. The LoST protocol (RFC 5222) allows civic location information to be returned in an XML format. The system shall support the

XML schema in the RFC including the following service calls:

<findService> and <findServiceResponse>

<getServiceBoundary> and <getServiceBoundaryResponse>

<listServices> and <listServicesResponse>

<listServicesByLocation> and <listServicesByLocationResponse> findService Request

PSI-000390 [Required: CSPR, PSPR] The product shall support “civic” and “geodetic-2d” profiles are baseline profiles defined in IETF RFC 5222, and emergency calls are expected to use only these profiles.

PSI-000400 [Optional: CSPR, PSPR] Conformant LoST servers may, but are not required to support any location profiles beyond these baseline profiles.

PSI-000410 [Required: CSPR, PSPR] The LoST interface shall allow a geo-location to be expressed as a point or one of several defined “shapes,” such as circle, ellipse, arc band, or polygon.

PSI-000420 [Required: CSPR, PSPR] PSPR shall understands and handles all shapes in PSI-

000410. The “service” element shall identify the service requested by the client.

PSI-000430 [Required: CSPR, PSPR] Valid service names shall be urn:service:sos or one of its sub-services for PSPR queries used by entities or devices for emergency calls.

PSI-000440 [Optional: CSPR, PSPR] PSPR implementations may support additional service names used internal to the PSInet dependent on the provisioning of service boundary layers in a geographical information system.

findService Response

PSI-000450 [Conditional: PSPR] A PSPR server may operate in recursive mode or iterative mode if the server being queried is not authoritative for the location supplied.

PSI-000460 [Required: PSPR] When recursion is used the PSPR shall initiate a query on behalf of the requestor that propagates through other PSPRs to an authoritative PSPR that returns the

PSAP URI back through the intervening PSPRs to the requesting PSPR.

PSI-000470 [Required: PSPR] The use of iteration by the PSPR shall return a domain name of the next PSPR to contact.

PSI-000480 [Conditional:] The PSPR may operate in a recursive mode or an iterative mode, depending on local provisioning and the value of the 'recursive' attribute of the <findService> request. All PSPR implementations shall support both recursive and iterative modes.

PSI-000490 [Required: PSPR] When the PSPR successfully processes a LoST <findService> message, it shall return a LoST <findServiceResponse> message containing a <mapping> element that includes the “next hop” CSPR or PSAP URI in the <uri> element. If the PSPR cannot successfully process a LoST <findService> message, it shall return a LoST <errors> message indicating the nature of the error or a LoST <redirect> message indicating the PSPR that can process the <findService> message.

PSI-000500 [Required: PSPR] The <uri> returned shall specify either the next hop URI of the

PSAP/ECC or the CSPR that is appropriate for the location sent in the query message. This shall be a globally routable URI with a scheme of sip for urn:service:sos. Some other service URNs may return values with HTTP/HTTPS schemes. LoST servers shall return SIPS and HTTPS

URIs in addition to the SIP and HTTP (where appropriate) URIs.

PSI-000510 [Required: CSPR, PSPR] The expires attribute in the <mapping> element provides an PSPR with a way to control load, balancing it against the time required to completely implement a routing change when circumstances require. By increasing the expiration time, fewer queries to the server may be received if upstream LoST servers or clients implement caching. The product shall support a variable expires.

PSI-000520 [Required: CSPR, PSPR] The LoST response contains <via> elements in the

<path> element that name the LoST servers visited to obtain the answer. Vias shall be returned to be compliant with IETF RFC 5222 and are essential for use in error resolution.

PSI-000530 [Required: CSPR, PSPR] The product shall support <displayName> element of the

<mapping> response as a text string to indicate the serving agency(ies) for the location provided in the query. This information could be useful to PSAP/ECCs that query an PSPR.

PSI-000540 [Required: CSPR, PSPR] The product shall support the <service> element in the query which identifies the service for which this mapping is valid.

PSI-000560 [Required: CSPR, PSPR] The product shall support the <serviceNumber> element in the <mapping> response which contains the emergency services number appropriate for the location provided in the query. This allows a foreign end device to recognize a dialed emergency number.

PSI-000570 [Required: CSPR, PSPR] The PSPR shall support be configured to allow a requesting entity to obtain the boundary of the service area handled by the requested service, returned in the <serviceBoundary> element of <mapping>. This is most useful for mobile devices that use geodetic coordinates since they can track their location. When they leave the service area, they can send another <findService> request to determine the proper service area for their new location and avoid re-querying the PSPR provided they are within the returned boundary.

PSI-000580 [Required: CSPR, PSPR] The service boundary in a <mapping> shall support be returned by value and by reference. If the server returns a service boundary reference, the client shall then obtain the actual service boundary with a <getServiceBoundary> request.

Latitude/Longitude/Altitude

PSI-000590 [Required: GIS, LIS, SBC, PSPR] The LoST query shall support latitude and longitude to ensure geolocation accuracy. GML and geoshape elements require a srsName attribute to specify a URN that defines their interpretation. The system shall support latitude/longitude/altitude as the srsName attribute formatted as <gml:pos> with the latitude and longitude in decimal degrees.

3.1.4 IPV6

IP6-000011 [Required: All Products] - All products shall support both Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6) stacks as described in RFC 8200. IPv6 shall also be implemented IAW USGv6 Capability Summary Strings (CSS) for each device type listed.

IP6-000050 [Required: All Products] - The system shall provide the same (or equivalent) functionality in IPv6 operation as it provides in IPv4 operation consistent with the requirements for the APL category.

IP6-000070 [Required: All Products] - The product shall support the transmission of IPv6 packets over Ethernet networks using the frame format defined in RFC 6085 and RFC 8064.

IP6-000100 [Conditional: All Products] - If Path MTU Discovery is used and a Packet Too Big message is received requesting a next-hop MTU that is less than the IPv6 minimum link MTU, then the product shall ignore the request for the smaller MTU and shall include a fragment header in the packet.

NOTE: Unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path.

IP6-000150 [Required: All Products] - The product shall support the IPv6 Addressing

Architecture as described in RFC 4291 and as updated by RFC 5952, RFC 6052, RFC 7136, RFC 7346, RFC 7371, and RFC 8064.

NOTE 1: According to DoD IPv6 Standard Profiles for IPv6-capable Products-Supplemental

Guidance version 6.0, the use of IPv4-mapped addresses on the-wire is discouraged due to security risks raised by inherent ambiguities.

IP6-000160 [Required: All Products] - The product shall support the IPv6 Scoped Address

Architecture as described in RFC 4007 and updated by RFC 7346.

IP6-000180 [Conditional: All Products] - If Dynamic Host Configuration Protocol (DHCP) is supported within an IPv6 environment, then it shall be implemented in accordance with the

DHCP for IPv6 (DHCPv6) as described in RFC 8415 and updated by RFC 4361, RFC 5494, RFC 6221, RFC 6422, RFC 6644, RFC 7083, RFC 7227, RFC 7283, RFC 7550.

IP6-000200 [Conditional: All Products] - If the product is a DHCPv6 client, then the product shall discard any messages that contain options that are not allowed to appear in the received message type (e.g., an Identity Association option in an Information-Request message).

IP6-000220 [Conditional: All Products] - If the product is a DHCPv6 client and the first retransmission timeout has elapsed since the client sent the Solicit message and the client has received an Advertise message(s), but the Advertise message(s) does not have a preference value of 255, then the client shall continue with a client-initiated message exchange by sending a

Request message.

IP6-000230 [Conditional: All Products] - If the product is a DHCPv6 client and the DHCPv6 solicitation message exchange fails, then it shall restart the reconfiguration process after receiving user input, system restart, attachment to a new link, a system configurable timer, or a user defined external event occurs.

NOTE: The intent is to ensure that the DHCP client continues to restart the configuration process periodically until it succeeds.

IP6-000240 [Conditional: All Products] - If the product is a DHCPv6 client and it sends an

Information-Request message, then it shall include a Client Identifier option to allow it to be authenticated to the DHCPv6 server.

IP6-000250 [Conditional: EI, NA/SS] - If the product is a DHCPv6 client, then it shall perform duplicate address detection upon receipt of an address from the DHCPv6 server before transmitting packets using that address for itself.

IP6-000260 [Conditional: All Products] - If the product is a DHCPv6 client, then it shall log all reconfigure events.

NOTE: Some systems may not be able to log all this information (e.g., the system may not have access to this information).

IP6-000270 [Conditional: All Products] - If the product supports DHCPv6 and uses authentication, then it shall discard unauthenticated DHCPv6 messages from DOD Information

Network (DODIN) Products and log the event.

NOTE: Some systems may not be able to log all this information (e.g., the system may not have access to this information).

IP6-000280 [Required: All Products] - The product shall support Neighbor Discovery for IPv6 as described in RFC 4861 and updated by RFC 5942, RFC 6980, RFC 7048, RFC 7527, RFC

7559, RFC 8028, RFC 8319, RFC 8425 as appropriate to their role as an IPv6 End Node or IPv6

Intermediate Node. Informational RFC 4943 provides additional background on implementation of Neighbor Discovery (ND). Note: ND implies that nodes MUST support Multicast Listener

Discovery.

IP6-000430 [Required: All Products] - If the product supports IPv6 SLAAC, then the product shall have a configurable parameter that allows the function to be enabled and disabled.

Specifically, the product shall have a configurable parameter that allows the managed address configuration flag and the other stateful configuration flag to always be set and not perform stateless auto configuration.

IP6-000450 [Required: All Products] - While nodes are not required to auto configure their addresses using SLAAC, all IPv6 Nodes shall support link-local address configuration and

Duplicate Address Detection (DAD) as specified in RFC 4862 as updated by RFC 7527. In accordance with RFC 4862 as updated by RFC 7527, DAD shall be implemented and shall be on by default.

IP6-000460 [Required: All Products] - A node shall allow for auto configuration-related variable to be configured by system management for each multicast-capable interface to include

DupAddrDetectTransmits where a value of zero indicates that DAD is not performed on tentative addresses as specified in RFC 4862 as updated by RFC 7527.

NOTE: Network Infrastructure Security Technical Implementation Guide (STIG) states the following: The use of Duplicate Address Detection opens the possibility of denial-of-service attacks. Any node can respond to Neighbor Solicitations for a tentative address, causing the other node to reject the address as a duplicate. This attack is like other attacks involving the spoofing of Neighbor Discovery messages. Further, RFC 4862 as updated by RFC 7527 states the following: By default, all addresses should be tested for uniqueness prior to their assignment to an interface for safety. The test should individually be performed on all addresses obtained manually, via stateless address auto configuration, or via DHCPv6. To accommodate sites that believe the overhead of performing Duplicate Address Detection outweighs its benefits, the use of Duplicate Address Detection can be disabled through the administrative setting of a per-interface configuration flag. The products may include an administrative setting to disable DAD.

IP6-000470 [Required: All Products] - The product shall support manual assignment of IPv6 addresses.

IP6-000520 [Required: All Products] - The product shall support the Internet Control Message

Protocol (ICMP) for IPv6 as described in RFC 4443 and updated by RFC 4884.

IP6-000550 [Conditional: All Products] - If the product has the capability to send an Echo

Reply message in response to an Echo Request message sent to an IPv6 multicast or anycast address, the product shall support the disabling of this capability.

NOTE: The number of responses may be traffic conditioned to limit the effect of a denial-of-service attack.

IP6-000740 [Conditional: All Products] - If an ICMP outbound packet message is allowed, then the product shall be capable of rate limiting the transmission of ICMP responses.

IP6-000890 [Conditional: All Products ] - If IPv6-compatible nodes are managed via Simple

Network Management Protocol (SNMP) using IPv6, then the product shall comply with the

Management Information Base (MIB) for IPv6 textual conventions and general group as defined in RFC 4293 which obsoletes RFC 2011, RFC 2465, and RFC 2466.

IP6-000900 [Conditional: All Products ] - If the product performs routing functions and if

IPv6-capable nodes are managed via SNMP management using IPv6, then the product shall support the SNMPv3 management framework as described in RFC 3411 which obsoletes RFC

2571, and is updated by RFC 5343, RFC 5590.

IP6-000910 [Conditional: All Products ] - If the product performs routing functions and if

IPv6-capable nodes are managed via SNMP management using IPv6, then the product shall support SNMPv3 message processing and dispatching as described in RFC 3412 which obsoletes

RFC 2572, and is updated by RFC 5590.

IP6-000920 [Conditional: All Products ] - If the product performs routing functions and if

IPv6-capable nodes are managed via SNMP management using IPv6, then the product shall support the SNMPv3 applications as described in RFC 3413 part of STD 62 which obsoletes

RFC 2573.

IP6-000930 [Conditional: All Products ] - If IPv6-compatible nodes are managed via SNMP using IPv6, then the product shall support the IP MIBs as defined in RFC 4293 which obsoletes

RFC 2011, RFC 2465, and RFC 2466.

IP6-000940 [Conditional: All Products ] - If IPv6-compatible nodes are managed via SNMP using IPv6, then the product shall support the Transmission Control Protocol (TCP) MIBs as defined in RFC 4022.

IP6-000950 [Conditional: All Products ] - If IPv6-compatible nodes are managed via SNMP using IPv6, then the product shall support the User Datagram Protocol (UDP) MIBs as defined in

RFC 4113.

IP6-000970 [Conditional: All Products ] - If the product performs routing functions and is managed by SNMP using IPv6, then the product shall support the IP Forwarding MIB as defined in RFC 4292.

IP6-001000 [Conditional: All Products] - If the product uses the Domain Name Service (DNS) resolver for IPv6 based queries, then the product shall conform to RFC 3596 a.k.a. STD 88 for

DNS queries.

IP6-001040 [Required: All Products] - The product shall forward packets using the same IP version as the version in the received packet.

NOTE: If the packet was received as an IPv6 packet, then the appliance shall forward it as an

IPv6 packet. If the packet was received as an IPv4 packet, then the appliance shall forward the packet as an IPv4 packet. This requirement is primarily associated with the signaling packets to ensure that translation does not occur.

IP6-001120 [Required: SBC] - The product shall be able to provide topology hiding [e.g., Network Address Translation (NAT)] - for IPv6 packets as described in Cybersecurity Section.

NOTE: Deployments requiring the network topology hiding that IPv4 NAT provided as a side-effect should consider RFC 4864 – Local Network Protection (LNP) for IPv6.

AUX-003880 [Required: All Products] - The system or network device shall be able to set

DSCPs on both signaling packets and media streams for both IPv4 and IPv6 as specified in the

Traffic Conditioning Specification Section.

CYB-061000 [Required: All Products] - The product shall support the capability to verify that the identity claimed in an X.509v3 certificate Subject Common Name, used to establish an authenticated and secure channel, correctly maps to the identity claimed in signaling messages transmitted within the same secure channel.

NOTE1: At this time the identity claimed in an X.509v3 certificate Subject Common Name may be a FQDN, IPv4, or IPv6 address.

NOTE2: The Subject Common Name is expected to map to the identity claimed in signaling messages, but this mapping does not mean that the Subject Common Name and the identity in the signaling messages are identical or related. For example, the identity claimed in a signaling message may be 1234567890@uc.mil, and this might be compared to a CAC Subject Common

Name of Doe. John. A. 2378324324 to verify that the certificate presented in the CAC maps to the claimed phone number for authorization purposes.

CYB-061010 [All Products ] - The product shall support the capability to examine the identity claimed by the X.509v3 Subject Common Name field and compare it to the identity claimed within signaling messages regardless of whether the claimed identity contains an FQDN, IPv4 address, or IPv6 address.

3.1.5 SIP

SIP-000010 [Required: All Products] All SIP devices must support SIP in accordance with

RFC 3261 and offer-answer in accordance with RFC 3264.

SIP-000020 [Required: All Products] SIP devices must implement TCP.

SIP-000030 [Required: All Products] All SIP devices must support TLS which includes DOD

Public Key Information (PKI) and Federal Information Processing Standards (FIPS) 140-2 or

140-3 validated modules.

SIP-000040 [Required: All Products] All SIP devices must support

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and

TLS_RSA_WITH_AES_128_CBC_SHA.

SIP-000050 [Required: All Products] All SIP devices shall support TLS (dual path method) to provide confidentiality for the SIP messages as described in RFC 3261.

SIP-000060 [Required: All Products] All SIP devices shall support Online Certification Status

Protocol (OCSP).

SIP-000070 [Required: All Products] The system must support voice samples received from

SIP end instruments using the real-time transport protocol (RTP) as described in RFC 3550 and https://www.rfc-editor.org/rfc/rfc3264 https://www.rfc-editor.org/rfc/rfc3261 https://www.rfc-editor.org/rfc/rfc3550

MUST support SRTP RFC 3711 using SDP security descriptions RFC 4568 for the necessary key exchange.

SIP-000080 [Required: All Products] The system must support MUST use the confidentiality mechanisms in SRTP and SRTCP and support Symmetric RTP/SRTP to ensure media confidentiality as described in [RFC 3711].

SIP-000090 [Required: All Products] The SRTP media port range must be configurable between 2048 and 65535 with the default between: 16384 to 32764.

SIP-000100 [Required: All Products] The system must support PRACK, 100rel option tag in accordance with RFC 3262.

SIP-000110 [Required: All Products] The system MUST support the following CODECs:

G.711 μ-Law, G.711 a-Law, Dual Tone Multi-Frequency (DTMF) via RFC 4733, G.729 or

G.729A, T.38, RFC 4040 64 Kbps Clearmode, V.150.1 Modem Relay (Media Gateways

/vIPers), NoAudio (SCIP-215, For Secure Communications Interoperability Protocol (SCIP) secure only phones).

SIP-000120 [Required: All Products] The system must support Session Controllers sending changes to negotiated media capabilities via SIP. SIP re-INVITE MUST support [RFC 3261], Section 14 of the SIPconnect 2.0 Technical Recommendation “Modifying an Existing Session.”

SIP UPDATE MUST be used for this purpose when both endpoints advertise support for [RFC

3311].

The following SIP requirements from UCR 2013, Change 2 are required:

SIP-009581 [Required: All Products] SIP signaling appliances MUST support generating and receiving the SUBSCRIBE method for event notification (RFC 3265).

SIP-009591 [Required: All Products] SIP signaling appliances MUST support the NOTIFY method for event notification defined in RFC 3265. This specification uses the NOTIFY request in the call transfer supplementary service.

3.1.5.1 Emergency Services

SIP-000130 [Required: SC, SBC, CSPR] The system MUST be able to recognize emergency calls (i.e., 9-1-1) and route that call to the CSPR. It MUST populate the Request-URI using a dial string Uniform Resource Identifier (URI), in accordance with NENA-STA-010.3d-2021 that contains the national emergency services number.

SIP-000140 [Required: All Products] The system MUST recognize the identity of the caller in the “P-Asserted-Identity” header field, in accordance with the rules of RFC 3325 and RFC 5876, and in the “From” header field URI with a URI that the Session Controller wishes to be used for caller identification.

SIP-000150 [Required: All Products] The system MUST NOT withhold the “P-Asserted-

Identity” header field for privacy reasons and MUST NOT anonymize the “From” header field.

All products shall pass the INVITE with identity of the caller in the “P-Asserted-Identity” header field, in accordance with the rules of RFC 3325 and RFC 5876, and in the “From” header field

URI with a URI that the SC wishes to be used for caller identification.

https://www.rfc-editor.org/rfc/rfc3711 https://www.rfc-editor.org/rfc/rfc4568 https://www.rfc-editor.org/rfc/rfc3711 https://www.rfc-editor.org/rfc/rfc3262 https://www.rfc-editor.org/rfc/rfc4733 https://www.rfc-editor.org/rfc/rfc3261 https://www.rfc-editor.org/rfc/rfc3311 https://www.rfc-editor.org/rfc/rfc3311 https://www.rfc-editor.org/rfc/rfc3265 https://www.rfc-editor.org/rfc/rfc3265 https://www.rfc-editor.org/rfc/rfc3325 https://www.rfc-editor.org/rfc/rfc5876

SIP-010160 [Required: All Products] The SC shall not withhold the “P-Asserted-Identity” header field for privacy reasons and shall not anonymize the “From” header field. Products in the call path shall not anonymize the “From” header field.

SIP-010165 [Required: CSPR] The CSPR shall be able to recognize emergency calls based on the presence of the agreed emergency services number in the Request-URI.

SIP-000170 [Required: All Products] If an originating session is an emergency session, then

SIP session limits do not apply. The CSPR shall NOT apply SIP session limits to emergency calls originated by a Session Controller. The Session Controller and the SBC shall NOT apply

SIP session limits to emergency services calls.

SIP-000180 [Required: All Products] Information relating to the location of a SC user or EI shall be provided depending on local regulatory requirements. The SC or EI when providing location SHALL support do so using the SIP Geolocation Header field as specified in RFC 6442, location MAY be provided by value or by reference.

3.2 System Availability

SCM-001861 [Ref UCR: SCM-001860] [Required: CSPR, SBC, SC]

Call survivability: connect first time and call remains active until either the call originator or terminating end disconnects.

a) No Loss of Active Sessions. In the event of component failure in an appliance subsystem(s), all active sessions shall not be disrupted (namely, the loss of established session connections requiring user redialing to reestablish), and the media path through the network shall be restored within 5 seconds. In addition, when the state information is lost for non-disrupted active sessions, the Secure Real-time Transport Protocol (SRTP) media streams will clear when both the called and calling parties hang up their End

Instrument (EIs).

b) Software Upgrades and Patches. Software upgrades and patches shall be able to be implemented without incurring any subsystem downtime.

c) System must support a minimum Mean Opinion Score (MOS) score of 4.0 or better for

SIP calls.

4 FUNCTIONAL ELEMENT REQUIREMENTS

4.1 CSPR

The CSPR is the DoD product category for the NENA i3 ESRP functional element. The functionality of the ESRP comprises the NENA i3 Policy Routing Function (PRF).

Typically, an emergency services call is received via an SBC to the CSPR, the CSPR shall query the PSPR and refer the call to the servicing PSAP/ECC. It is possible the CSPR may tandem the call to an intermediary CSPR before delivering to the destination PSAP/ECC. The destination of the call on the output of the CSPR is conceptually a queue, represented by a URI. In most cases, the queue is maintained on a downstream CSPR, and is most often empty. However, when the network gets busy it is possible for another PSAP/ECC to receive calls from the queue. The queue is most often First-In First-Out, but in some cases, there can be out-of-order selections from the queue.

Policy-based routing is a networking technique that allows administrators to create and enforce specific rules for routing traffic within a network. This can be useful in a variety of situations, such as prioritizing certain types of traffic, directing traffic to specific devices or networks, or implementing security measures.

Policy-based routing provides the ability to customize routing decisions based on a variety of factors, such as the source and destination of traffic, the type of traffic being transmitted, and the status of network devices. This facilitates call routing decisions based on real time call progression data based on, but not limited to Secure Telephone Identity Revisited (STIR) /Signature-based Handling Information Using toKENs (SHAKEN) attestation level, network call abuse patterns, and/or PSInet call load metrics.

The CSPR processes administrative calls using the policy routing function inherent in the CSPR to leverage policy-based routing. Emergency services calls trigger the CSPR to query the PSPR for location validation and route determination the CSPR uses this additional location information to make the final policy-based routing decision.

4.1.1 CSPR Interface Support Requirements

The CSPR requirements are located the DISA Soft Switch Backbone SRD.

4.2 PSPR

4.2.1 Summary

Emergency calls shall be routed to the appropriate PSAP/ECC based on the location of the caller.

In addition, PSAP/ECCs may utilize the same routing functionality to determine how to route emergency calls to the correct responder. The NG9-1-1 functional element responsible for providing routing information to the various querying entities is the PSPR. A PSPR provided by

DISA and accessible from the PSInet shall permit querying by an IP client/endpoint, an IP routing proxy belonging to, a CSPR in a next generation Public Safety network, or by some combination of these. DISA shall provide a PSPR to replicate Forest Guide (FG) functionality as part of the MPG as required.

The DOD shall consolidate the NENA i3 defined functional elements ECRF, LVF, and FG into the PSPR product category due to the overlap of functionality. The ECRF and LVF functions have the same interfaces and contain the same data. They may be combined into a single implementation. However, it should be noted that the ECRF is a real-time element in the signaling path of an emergency call.

4.2.2 Standards

PSP-000010 [Required: PSPR] PSPR shall comply with NENA-STA-010.3b-2021 Sec 4.3

PSPR shall comply with NENA-STA-010.3b-2021 Sec 4.13

PSP-000020 [Required: PSPR] The system shall comply with NENA‑STA‑005.1.2‑2022.

4.2.3 Set of requirements

PSP-000030 [Required: PSPR] A PSPR accessible inside the PSInet shall permit querying from any Emergency Service entity inside the PSInet.

PSP-000040 [Required: PSPR] The PSPR shall route SIP calls based off an FQDN and the SIP

URI therefore all elements identified by hostnames SHALL have corresponding Domain Name

Service (DNS) records as specified in STD13 (RFC 1034) in the DOD DNS.

PSP-000050 [Required: All Products] All elements connected to the PSInet shall support a local DNS resolver to translate hostnames they receive to IP addresses.

PSP-000060 [Conditional: PSPR] When a caching DNS resolver in the PSInet cannot refresh an expired cached resource record in response to a query because the authoritative DNS server is not available, it should reuse the stale cached resource record as though the cached resource record’s TTL is 1 second, as described in Section 4 of RFC 8767.

PSP-000070 [Required: PSPR] DNSSEC (RFC 4035) SHALL be deployed in authoritative

DNS servers, especially those resolving names found in external PSPRs.

PSP-000080 [Required: PSPR] A domain that has SIP elements within the domain SHALL have an SRV record RFC 2782 for a SIP service for the domain, and any of its subdomains that may appear in a URI.

PSP-000090 [Required: CSPR, PSPR] Placing a LoST query always requires resolution of an

Application-Unique String (AUS), which is in the form of an FQDN via U-NAPTR (RFC 4848), and U-NAPTR resolution may also be required to obtain the URI for a LIS (per RFC 5986)

Route Query

PSP-000100 [Required: PSPR] When an PSPR receives a LoST query (as defined in IETF RFC

5222), it determines whether the query was received from an authenticated entity (e.g., an CSPR) and the type of service requested (i.e., emergency services).

PSP-000110 [Required: PSPR] Authentication shall apply to all entities that initiate queries to the PSPR within the PSInet. TLS is used by all PSPRs within the PSInet, and credentials issued to the querying entity that are traceable to a DOD Certificate Authority (CA) shall be accepted.

PSP-000120 [Required: PSPR] Devices and carriers outside the PSInet may not…