4.1 Location Information Server (LIS) & PIDF-LO

4.1 Location Information Server (LIS) & PIDF-LO

Quick Answer: The Location Information Server (LIS) is an authoritative access-network entity governed by RFC 5687 and NENA-STA-010 that determines a calling device's physical location and delivers it using protocols such as HTTP-Enabled Location Delivery (HELD, RFC 5985). Caller location is standardized as a Presence Information Data Format - Location Object (PIDF-LO, RFC 4119), which conveys either 2D/3D geodetic coordinates (RFC 5491 using GML 3.1.1 referenced to WGS 84) or structured civic addresses (RFC 5139 CAtypes). NENA i3 allows location to arrive either by value (LbyV, the PIDF-LO carried inside the SIP INVITE) or by reference (LbyR, a URI that authorized elements dereference from the LIS), so ESRPs, ECRF clients, and PSAPs must be prepared to handle both.

---

The Architectural Role of the Location Information Server (LIS)

In legacy Enhanced 9-1-1 (E9-1-1) architectures, caller location was decoupled from call signaling. Location was represented as a static billing record stored in a centralized tabular database (Automatic Location Identification, or ALI). After an emergency call arrived over dedicated analog CAMA trunks at a Public Safety Answering Point (PSAP), the call-handling console initiated an out-of-band serial dip over a modem or point-to-point data circuit to retrieve the tabular ALI record. This legacy model introduced multiple seconds of delay, failed completely for nomadic VoIP or wireless callers moving across jurisdictions, and could not convey real-time coordinates.

Next Generation 9-1-1 (NG911) executes an architectural paradigm inversion: location must be acquired prior to or at the exact instant of call origination to drive real-time spatial routing across the Emergency Services IP Network (ESInet).

Under IETF RFC 5687 and NENA-STA-010 (NENA i3 Standard for Next Generation 9-1-1), the Location Information Server (LIS) is the authoritative functional entity operating within the access network (such as a wireline broadband provider, cellular wireless carrier, enterprise IP-PBX, or university Wi-Fi network) responsible for storing, discovering, and serving caller location. The LIS binds a physical geographic location to a device identifier:

• Wireline Broadband / FTTH: Binds subscriber location to an optical network terminal (ONT) identifier, DSLAM port, or static IP lease.
• Enterprise Local Area Networks: Binds location to an Ethernet switch chassis, line card, and physical switch port using Link Layer Discovery Protocol - Media Endpoint Discovery (LLDP-MED, ANSI/TIA-1057).
• Campus Wi-Fi Networks: Binds location to a Wireless LAN Controller (WLC), Access Point (AP) radio MAC address, and Basic Service Set Identifier (BSSID).
• Cellular Wireless Networks: Binds location to a serving cellular base station (eNodeB/gNodeB), sector ID, Timing Advance (TA), Round Trip Time (RTT), or Assisted-GNSS (A-GNSS) device measurements.

+-----------------------+          HELD Request (RFC 5985)          +-----------------------+
|   IP User Endpoint    | ----------------------------------------> |    Access Network     |
| (VoIP Phone / Mobile) |                                           |  Location Information |
|                       | <---------------------------------------- |      Server (LIS)     |
+-----------------------+        HELD Response (PIDF-LO XML)        +-----------------------+
           |                                                                    |
           | SIP INVITE [contains embedded PIDF-LO (LbyV)]                      | (Location URI)
           v                                                                    v
+-------------------------------------------------------------------------------------------+
|                    EMERGENCY SERVICES IP NETWORK (ESInet) / NGCS CORE                     |
|    +-----------------------+                  +-----------------------------------+       |
|    |  Border Control (BCF) | ---------------> | Emergency Service Routing (ESRP)  |       |
|    +-----------------------+                  +-----------------------------------+       |
+-------------------------------------------------------------------------------------------+

Location Configuration Protocols (LCP)

The protocol an endpoint utilizes to discover and request its own location from a LIS is designated a Location Configuration Protocol (LCP). Standardized LCP implementations include:

1. HTTP-Enabled Location Delivery (HELD - RFC 5985): The primary Layer 7 application protocol across modern IP networks, utilizing XML payloads transported securely over TLS (HTTPS).
2. Dynamic Host Configuration Protocol (DHCP) Options: Used during initial IP address assignment:
   • RFC 3825 (Option 123): Coordinate-based geodetic location (latitude, longitude, altitude).
   • RFC 4776 (Option 99): Structured civic address configuration.
3. LLDP-MED (ANSI/TIA-1057): Operates at Layer 2 (Data Link Layer) between Ethernet switches and VoIP endpoints to push physical wall-jack, room, and floor metadata directly into the phone upon link establishment.

---

The HELD Protocol (RFC 5985) in Detail

HTTP-Enabled Location Delivery (HELD), standardized in IETF RFC 5985, is an XML-based, request-response protocol operating over Transport Layer Security (TLS). When an IP endpoint boots or detects that an emergency session is initiated, it issues a HELD <locationRequest> to its local LIS.

HELD Request Capabilities & Parameters:

• responseTime Attribute: RFC 5985 lets the client give either a time in milliseconds or a purpose: responseTime="emergencyRouting" asks for a location quickly enough to route the call, while responseTime="emergencyDispatch" signals that the location will be used to dispatch responders, so the LIS should return the most accurate fix it can within a dispatch-acceptable time.
• locationType Filtering: The client specifies the requested format: geodetic (<locationType>geodetic</locationType>), civic (<locationType>civic</locationType>), or both.
• Requested Location Types (exact): The <locationType> element lists the forms the client wants (any, geodetic, civic, or locationURI). With exact="true", the LIS must return exactly those types or an error; with exact="false" (the default), it may return other available types.
• Location by Value vs. Reference: The client specifies whether it requests the actual PIDF-LO XML document directly or a dereferencing URI (<locationType>locationURI</locationType>).

<!-- Example HELD Location Request -->
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="emergencyRouting">
  <locationType exact="true">geodetic</locationType>
</locationRequest>

Upon receiving the request, the LIS authenticates the endpoint, maps its Layer 2 or Layer 3 network identifier to its internal spatial database, and returns a <locationResponse> encapsulating an RFC 4119 PIDF-LO XML document.

---

Location by Value (LbyV) vs. Location by Reference (LbyR)

In SIP signaling, emergency caller location can be conveyed to downstream Next Generation Core Services (NGCS) and Public Safety Answering Points (PSAPs) via two distinct architectural methods:

LOCATION BY VALUE (LbyV) - DETERMINISTIC & IMMEDIATE:
[ Originating Endpoint / LNG ] ============= SIP INVITE (with PIDF-LO inside) ============> [ ESRP / PSAP ]
                                              (Location available at T = 0 ms)

LOCATION BY REFERENCE (LbyR) - DEREFERENCE STEP:
[ Originating Endpoint ] ───────────────── SIP INVITE (Geolocation: URI) ─────────────────► [ ESRP / PSAP ]
                                                                                                   │
                                   [ Concurrent HTTPS GET Over TLS ] ◄─────────────────────────────┘
                                   [ Requires LIS availability & authorization ] ──────────────────► [ Location retrieved on demand ]

Exam Trap & Operational Reality: Do not assume either method is banned. NENA i3 elements must handle both Location by Value (LbyV) and Location by Reference (LbyR). By-value location avoids a dereference step at call setup; by-reference location lets a PSAP pull updated location for a moving caller. Because dereferencing depends on the LIS being reachable and the requester being authorized, ESRP policy and default routing must cover the case where location cannot be retrieved in time.

---

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

Standardized by the IETF GEOPRIV working group in RFC 4119, the Presence Information Data Format - Location Object (PIDF-LO) provides a secure, XML-based data container for encapsulating location across IP networks. A PIDF-LO object adheres to a strict hierarchical schema:

<presence> (Root element defining presence entity)
   │
   └── <tuple> (Observation unit with unique timestamp and status)
          │
          └── <status>
                 │
                 └── <geopriv> (Geographic privacy container)
                        ├── <location-info> (Geodetic or Civic spatial payload)
                        └── <usage-rules> (Retention & retransmission policies)

Mandatory PIDF-LO XML Elements:

1. <presence>: Root element declaring XML namespaces and the entity identifier (e.g., entity="pres:caller@carrier.com").
2. <tuple>: Encapsulates the location observation along with a <timestamp> indicating when the positioning measurement was recorded.
3. <geopriv>: The mandatory security and privacy container:
   • <retransmission-allowed>: Tells recipients whether they may share the location further (RFC 4119 defaults to no); emergency call handling relies on public safety rules that let location follow the call to transfer and dispatch partners.
   • <retention-expiry>: Specifies the exact UTC date and time after which the receiving system must purge the location data from volatile and non-volatile storage caches, protecting citizen privacy.
4. <location-info>: Contains the actual geographic payload, formatted either as an RFC 5491 geodetic shape (<gml:Point>, <gml:Polygon>, etc.) or an RFC 5139 structured civic address (<civicAddress>).

---

Geodetic Location Encoding: RFC 5491 & GML 3.1.1

Geodetic coordinates within a PIDF-LO are formatted according to IETF RFC 5491, which defines an application profile of Geography Markup Language (GML) 3.1.1. All coordinates must reference the World Geodetic System 1984 (WGS 84) coordinate reference system (EPSG:4326 for 2D coordinates; EPSG:4979 for 3D coordinates including altitude).

Standard 2D and 3D Geodetic Geometries:

• Point (2D / 3D): A single coordinate pair (pos="lat long") or triplet (pos="lat long alt"). In emergency routing, raw points must be accompanied by explicit uncertainty values.
• Polygon: A closed linear ring of coordinate pairs defining a bounded geographic polygon.
• Circle: A 2D point accompanied by a radius in meters, defining a circular area of uncertainty.
• Ellipse: Defined by a center point, semi-major axis, semi-minor axis, and orientation angle in degrees.
• ArcBand: A curved wedge representing a directional cellular sector defined by inner radius, outer radius, start angle, and end angle.
• Sphere / Ellipsoid (3D): 3D volume representations incorporating vertical uncertainty.
• Prism (3D): A 2D polygonal base extruded vertically between a minimum and maximum altitude, used to model multi-story buildings, indoor shopping malls, or campus facilities.

<!-- Example RFC 5491 3D Point with Uncertainty -->
<gml:Point xmlns:gml="http://www.opengis.net/gml" srsName="urn:ogc:def:crs:EPSG::4979">
  <gml:pos>38.897675 -77.036530 45.2</gml:pos>
</gml:Point>

---

3D Vertical Location (Z-Axis) & FCC Indoor Accuracy Mandates

With over 80% of emergency calls originating from wireless mobile devices, locating callers vertically within multi-story high-rise structures represents a critical operational challenge. Under the FCC's indoor location accuracy rules (the z-axis metric adopted in the Fifth Report and Order in PS Docket 07-114), wireless carriers must deliver z-axis location within ±3 meters relative to the handset for 80% of wireless 9-1-1 calls from z-axis-capable devices.

Engineering Representation of Vertical Z-Axis:

1. Height Above Ellipsoid (HAE): In geodetic PIDF-LO objects, altitude is measured strictly in meters above the WGS 84 reference ellipsoid, NOT Mean Sea Level (MSL) and NOT height above ground level (AGL). Converting HAE into an actionable architectural floor number requires local GIS systems to utilize high-resolution digital elevation models (DEM) and geoid undulation grids (e.g., GEOID18).
2. Vertical Uncertainty (Z-Uncertainty): A raw altitude value without uncertainty is operationally invalid for dispatch. RFC 5491 shapes such as the Ellipsoid carry a vertical uncertainty axis, and RFC 7459 defines a confidence element (for example, 95%) so the recipient knows how likely it is that the caller lies inside the reported volume.
3. 3D GML Prisms: In advanced indoor location systems, enterprise LIS servers map Wi-Fi access points and Bluetooth Low Energy (BLE) beacons directly to a GML Prism, defining the exact 3D spatial boundary of an interior suite or floor.

---

Civic Address Encoding: RFC 5139 & CAtypes Taxonomy

When emergency location originates from fixed wireline endpoints, enterprise Multi-Line Telephone Systems (MLTS), or geocoded address databases, location is formatted as a structured civic address under IETF RFC 5139 (which supersedes the older RFC 4119 civic specification).

RFC 5139 establishes standardized Civic Address Types (CAtypes) to prevent the data parsing ambiguities that plagued legacy text systems:

<!-- Example RFC 5139 Civic Address Payload -->
<civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
  <country>US</country>
  <A1>VA</A1>
  <A2>Fairfax</A2>
  <A3>Fairfax</A3>
  <PRD>North</PRD>
  <A6>Main</A6>
  <STS>Street</STS>
  <HNO>10400</HNO>
  <FLR>3</FLR>
  <ROOM>Suite 350</ROOM>
  <PC>22030</PC>
</civicAddress>

---

Address Normalization & Public Safety Operational Traps

Translating human-readable civic addresses into standardized RFC 5139 XML requires strict parsing rules to avoid catastrophic routing errors:

1. Municipal Jurisdiction (A3) vs. Postal Community Name (PCN)

A widespread point of failure in public safety dispatch is conflating the USPS postal delivery community with the actual incorporated municipality. The USPS assigns mailing names based on the post office delivering physical mail, which frequently crosses municipal and county borders. For NG911 routing, A3 must reflect the authoritative civil jurisdiction, not the postal community name. Misrepresenting A3 causes the Emergency Call Routing Function (ECRF) to query the incorrect jurisdictional boundary polygon.

2. House Number Suffix (HNS) Separation

House numbers containing fractional, alphabetic, or descriptive qualifiers (e.g., 742 1/2 Elm Street or 1200-B Highway 10) must be parsed into distinct HNO (742) and HNS (1/2) elements. Concatenating suffixes directly into the HNO field causes automated geocoding engines to fail matching against authoritative GIS Site/Structure Address Points.

3. Directional Prefix vs. Suffix Disambiguation

In urban centers with thoroughfares utilizing both pre- and post-directionals (e.g., North 1st Street East), failing to isolate North into PRD and East into POD results in multi-match errors or default routing during emergency call processing.