Common use of Location Validation Function Clause in Contracts

Location Validation Function. The Location Validation Function (LVF) provided will be physically separate from the Emergency Call Routing Function (ECRF). The LVF and ECRF are populated from the same GIS (Geographic Information System) sources and no unique GIS data requirements exist for either function. Location to Service Translation (LoST) servers, specifically dedicated for LVF functions, will be implemented independently of the ECRF for authorized carrier access to the validation functions. This architecture ensures that potentially high-volume validation functions never interfere with the ECRF functions of emergency call routing and determination of first responders for a given location. As with the ECRF, the LVF will utilize the Customer’s GIS data provisioned via the SIF and will determine whether or not the civic address provided in the LoST request is valid. The LVF responds per the NENA i3 standard (NENA 08-003) and the specified Internet Engineering Task Force (IETF) standards (RFC5222). To complement the LoST protocol interface into the LVF, a map-based graphical user interface (GUI) will be available to authorized users. This interface, accessible via a secure web interface, is designed to facilitate the finding of LVF-valid civic addresses for CSPs otherwise unable to validate a location via the LVF using the LoST protocol interface. The LVF is deployed in a fully-redundant, highly available (99.9%) environment to ensure immediate responses to the LVF LoST queries. It is critical to note: the solution component services, which are utilized during live 9-1-1 call processing and which could include an "LVF LoST Query" during call time will be designed for 99.999% availability. Our LVF component (LVF with Locology, which is the provisioning interface) is designed to meet/exceed 99.9% availability. This is in concert with the direction from NENA i3 standard and the ongoing working group. The attached NENA document discusses the differentiation in Section 3.4 on Page 23 and provides guidelines for availability. Generally Five 9s for runtime systems and network components and two to three 9s to other functional elements. Clients must access the LVF via secure protocols; Secure Sockets Layer (SSL) versions 2 and 3 and Transport Layer Security (TLS) versions 1, 1.1, and 1.2 are all supported. Mutual authentication will also be employed, so it is expected that both the client and LVF will be configured with valid digital certificates issued by their designated PSAP Credentialing Agency (PCA). At the time of West’s response, a PCA does not exist. Without a PCA, credentials will be issued by a trusted credentialing entity. The LVF is in a secure network using an Intelligent DNS infrastructure to provide a high level of performance, availability and security. Behind the Intelligent DNS infrastructure, additional state-of-the- art network elements provide high security against even the most aggressive malicious network attacks. All fixed location (wireline) telephone number (TN) records must be validated against the Customer’s GIS data prior to being loaded into the Location Information Server (LIS) and Automatic Location Identification (ALI) systems. The database management system used to process and validate Service Order Input (SOI) from communications service providers (CSPs) maintains a copy of the validated record and the data used for SOI validation is sourced from the Customer’s GIS data. Anytime the underlying GIS data is updated, the database management system searches for any TN records that may be impacted by the change. For those affected, it then immediately revalidates the record and either updates the LIS and ALI or flags it as an error for the Data Integrity Unit (DIU) analyst, who will work with the carrier and/or the Customer’s designated coordinator(s) to resolve. During the transitional phase toward a full i3 model, this process bypasses the need for periodic (e.g., every 30 days) LIS record revalidations and ensures the LIS/ALI records are kept as current as possible. For authorized CSPs who have chosen to provide their own LIS, the LVF is also available to validate their subscriber’s location information prior to provisioning, as well as for periodic revalidation as needed. Please note that this LoST server instance will always be separate from the ESInet ECRF instance involved in 9-1-1 call routing. Depending on the capabilities of the PSAP CPE to utilize locally available GIS data (i.e. data provisioned for the ALI mapping display), when a 9-1-1 call involves a reporting party that is not located at the site of the emergency, the LVF LoST server and complimentary map-based GUI will be available to the call taker to determine the valid address provided by the caller.

Location Validation Function. The Location Validation Function (LVF) provided will be physically separate from the Emergency Call Routing Function (ECRF). The LVF and ECRF are populated from the same GIS (Geographic Information System) sources and no unique GIS data requirements exist for either function. Location to Service Translation (LoST) servers, specifically dedicated for LVF functions, will be implemented independently of the ECRF for authorized carrier access to the validation functions. This architecture ensures that potentially high-volume validation functions never interfere with the ECRF functions of emergency call routing and determination of first responders for a given location. As with the ECRF, the LVF will utilize the Customer’s GIS data provisioned via the SIF and will determine whether or not the civic address provided in the LoST request is valid. The LVF responds per the NENA i3 standard (NENA 08-003) and the specified Internet Engineering Task Force (IETF) standards (RFC5222). To complement the LoST protocol interface into the LVF, a map-based graphical user interface (GUI) will be available to authorized users. This interface, accessible via a secure web interface, is designed to facilitate the finding of LVF-valid civic addresses for CSPs otherwise unable to validate a location via the LVF using the LoST protocol interface. The LVF is deployed in a fully-redundant, highly available (99.9%) environment to ensure immediate responses to the LVF LoST queries. It is critical to note: the solution component services, which are utilized during live 9-1-1 call processing and which could include an "LVF LoST Query" during call time will be designed for 99.999% availability. Our LVF component (LVF with Locology, which is the provisioning interface) is designed to meet/exceed 99.9% availability. This is in concert with the direction from NENA i3 standard and the ongoing working group. The attached NENA document discusses the differentiation in Section 3.4 on Page 23 and provides guidelines for availability. Generally Five 9s for runtime systems and network components and two to three 9s to other functional elements. Clients must access the LVF via secure protocols; Secure Sockets Layer (SSL) versions 2 and 3 and Transport Layer Security (TLS) versions 1, 1.1, and 1.2 are all supported. Mutual authentication will also be employed, so it is expected that both the client and LVF will be configured with valid digital certificates issued by their designated PSAP Credentialing Agency (PCA). At the time of WestXxxx’s response, a PCA does not exist. Without a PCA, credentials will be issued by a trusted credentialing entity. The LVF is in a secure network using an Intelligent DNS infrastructure to provide a high level of performance, availability and security. Behind the Intelligent DNS infrastructure, additional state-of-the- art network elements provide high security against even the most aggressive malicious network attacks. All fixed location (wireline) telephone number (TN) records must be validated against the Customer’s GIS data prior to being loaded into the Location Information Server (LIS) and Automatic Location Identification (ALI) systems. The database management system used to process and validate Service Order Input (SOI) from communications service providers (CSPs) maintains a copy of the validated record and the data used for SOI validation is sourced from the Customer’s GIS data. Anytime the underlying GIS data is updated, the database management system searches for any TN records that may be impacted by the change. For those affected, it then immediately revalidates the record and either updates the LIS and ALI or flags it as an error for the Data Integrity Unit (DIU) analyst, who will work with the carrier and/or the Customer’s designated coordinator(s) to resolve. During the transitional phase toward a full i3 model, this process bypasses the need for periodic (e.g., every 30 days) LIS record revalidations and ensures the LIS/ALI records are kept as current as possible. For authorized CSPs who have chosen to provide their own LIS, the LVF is also available to validate their subscriber’s location information prior to provisioning, as well as for periodic revalidation as needed. Please note that this LoST server instance will always be separate from the ESInet ECRF instance involved in 9-1-1 call routing. Depending on the capabilities of the PSAP CPE to utilize locally available GIS data (i.e. data provisioned for the ALI mapping display), when a 9-1-1 call involves a reporting party that is not located at the site of the emergency, the LVF LoST server and complimentary map-based GUI will be available to the call taker to determine the valid address provided by the caller.