Location Validation Function Clause Samples

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...