In the fixed network you could get away with ignoring the difference between a number and a place. A line terminated in a known building, the switch knew which PSAP served that building, and the mapping was static enough to be maintained by hand. Mobile access broke the first assumption, and VoIP broke the second. A subscriber’s phone number now tells you approximately nothing about where they are standing.
Next-generation emergency architectures answer this with two separate queries, each with its own protocol. HELD asks a Location Information Server where the caller is. LoST asks an Emergency Call Routing Function who serves that location. Both are IETF protocols, both are HTTP with XML payloads, and both appear in NENA i3 and in the European NG112 work (ETSI TS 103 479) as the interfaces to the ECRF and the LIS.
This article covers what the two protocols actually do, where they sit in an IMS network, and which parts of them tend to break in practice.
Two Questions, Two Protocols
| Question | Protocol | Answering element | Specification |
|---|---|---|---|
| Where is the caller? | HELD | LIS | RFC 5985, RFC 6155 |
| Who serves that place? | LoST | ECRF | RFC 5222 |
| Give me a fresher position | HTTP dereference | LIS | RFC 6753 |
The split is deliberate. The party who knows where a subscriber is and the party who knows which authority covers a given polygon are rarely the same organisation. An access network operator can answer the first question and has no business answering the second. A public authority maintains the boundaries and has no access to your subscriber data. Keeping the two queries separate lets each side own its own data.
HELD: Asking the LIS Where the Caller Is
A HELD locationRequest is an HTTP POST with content type application/held+xml. The body identifies the device and states what kind of location you want back:
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
xmlns:id="urn:ietf:params:xml:ns:geopriv:held:id"
responseTime="emergencyRouting">
<id:device><id:uri>tel:+4366012340001</id:uri></id:device>
<locationType exact="false">geodetic civic locationURI</locationType>
</locationRequest>Three details in that request matter more than they look.
The device element carries the identity you are asking about, which RFC 6155 added to the base protocol. This is what allows a third party, such as your IMS core, to ask on the subscriber’s behalf rather than the device asking for itself.
locationType lists what you want: a civic address, a geodetic position, a location URI, or any combination. The exact attribute decides what happens when the LIS cannot supply everything you asked for. With exact="false" it returns what it has. With exact="true" it returns an error instead.
responseTime exists precisely because this query sits inside call setup. Setting it to emergencyRouting tells the LIS to return something usable immediately, even if a more precise fix would be available a few seconds later. emergencyDispatch is the opposite request: take the time you need, accuracy matters more.
The response is a PIDF-LO document (RFC 4119) wrapped in a locationResponse. The location itself is either a civic address, a geometry, or both. Geometries follow RFC 5491, which is where shapes like Point, Circle, Ellipse and ArcBand are defined, along with the rules for how uncertainty is expressed.
By Value and by Reference
A HELD response can also contain a locationUriSet: an HTTPS URL that resolves to the caller’s current position. This is the part that people implementing only the routing path tend to skip, and it matters for the call taker rather than for you.
A snapshot is not a position
A position conveyed by value is a snapshot of where the caller was at the moment of the query. A caller in a moving vehicle has left it by the time the PSAP answers. A location URI can be dereferenced again later, per RFC 6753, and returns the position as it is now. If your network only attaches a by-value PIDF-LO, the PSAP is stuck with your snapshot. Pass the location URI along as well when the LIS offers one, and set its lifetime long enough to outlive the call.
LoST: Asking the ECRF Who Serves That Place
A LoST findService is an HTTP POST with content type application/lost+xml. It carries a location and a service URN (RFC 5031), and it asks which URI serves that combination:
<findService xmlns="urn:ietf:params:xml:ns:lost1" recursive="true">
<location id="loc1" profile="geodetic-2d">
<gml:Point xmlns:gml="http://www.opengis.net/gml">
<gml:pos>48.190739 16.373121</gml:pos>
</gml:Point>
</location>
<service>urn:service:sos.ambulance</service>
</findService>The profile attribute names the location profile. RFC 5222 defines geodetic-2d and civic. Note the “2d”: altitude has no place in a findService, even though the PIDF-LO you received from the LIS may well carry it. Reducing a three-dimensional shape to its two-dimensional equivalent before querying is your job, not the ECRF’s.
The response contains a mapping with the destination URI, usually a SIP URI, plus a display name, the local emergency number, and an expires timestamp. It also contains a path element listing every server that contributed, which is what lets you detect loops.
recursive controls who does the work when the answer lives on another server. With recursive="true" the ECRF resolves the chain itself and returns the final mapping. With recursive="false" it may return a redirect element naming the next server, and following that chain, with a hop count, is on you.
Where This Sits in an IMS Network
The UE performs an emergency registration and sends an INVITE to an SOS service URN. The P-CSCF recognises it as an emergency session and forwards it to an E-CSCF rather than to the S-CSCF chain. From there, 3GPP TS 23.167 puts location retrieval and route determination behind the Location Retrieval Function. Whether your LRF speaks HELD and LoST to external elements or resolves everything from an internal database is an implementation decision, not a standards requirement, and both exist in the field.
Location travels in SIP in the Geolocation header (RFC 6442), either as a cid: URI pointing at a PIDF-LO body part in the multipart body, or as an HTTPS URI that the receiver dereferences. The Geolocation-Routing header states whether intermediaries may route on that location. If you are inserting location that you retrieved yourself, you are the one setting these.
What Breaks in Practice
None of the following is exotic. Every one of these is something we have seen, and every one of them passes a naive interop test and fails a real one.
Application errors arrive with HTTP 200
Both protocols carry their failures in the response body. A HELD error element and a LoST errors element are perfectly normal XML documents delivered over a successful HTTP transaction. Code that checks the status code and then parses optimistically will treat a failed lookup as a successful one.
Namespace prefixes are not stable
One LIS emits gs:Circle, another a differently prefixed equivalent, a third nests things in a slightly different order. Parse by namespace URI and local name. Anything that matches on literal prefixes works until you meet your second vendor.
Geometry must be reduced before the findService
You will receive Circles, Ellipses and sometimes altitude. A geodetic-2d query takes two-dimensional shapes. Doing the reduction yourself, rather than forwarding whatever the LIS returned, is the difference between a routable query and a locationProfileUnrecognized.
The lookups sit inside your call setup budget
Two sequential HTTP round trips to external parties sit between the INVITE and the PSAP. Set hard timeouts, keep them short, and make the query asynchronous if your platform allows it.
Cache mappings, carefully
The expires attribute on a mapping exists to be used, and a service boundary lets you answer repeat queries locally rather than hitting the ECRF for every call in the same district. Just be sure your cache key is the boundary and not an arbitrary rounding of coordinates.
Interop is annual, your releases are not
The real LIS and ECRF belong to other people, and events like the ETSI NG112 plugtests happen once a year. If that is the only place your error handling gets exercised, it is being exercised too late.
The One Rule That Overrides Everything
A failed lookup must not fail the call
If the LIS times out, if the ECRF returns notFound, if the response does not parse – the call still has to reach a PSAP. Configure a location-independent default route per service and take it whenever the location path does not produce an answer in time. A call routed to a slightly wrong PSAP is an inconvenience. A call that fails is the thing this entire architecture exists to prevent.
Testing It Before It Matters
None of the above is difficult to implement. All of it is difficult to verify, because exercising it means having a LIS and an ECRF to talk to – and the real ones belong to other people.
That gap is why we wrote a mock LIS and ECRF: three endpoints – HELD locationRequest, location dereference and LoST findService – backed by a configurable set of devices, sectors and default PSAPs. It is not a location service, it has no geocoding and no authorisation model worth the name, and every position in it is one that somebody typed in. What it does give you is a target that returns the awkward cases on demand, including every failure mode listed above, so that your error handling is tested before it matters. It slots into the same continuous verification approach we use for everything else: if a code path only runs during a real emergency, it has effectively never run.
What This Does Not Cover
LoST and HELD answer two questions. A complete i3 or NG112 deployment asks several more: additional data associated with a call (RFC 7852), location validation before a call rather than during one, event logging, discrepancy reporting against the authority that maintains the boundaries. Treat the two protocols described here as the routing path, not as the whole architecture.
The routing path, though, is the one that has to work on the first attempt, every time, for a caller who will not get a second chance to dial.
Emergency routing is a first-class call path, not an appendix
In our platform the P-CSCF detects the SOS URN, the E-CSCF owns the emergency session, and the location path – HELD to the LIS, LoST to the ECRF, dereference for the call taker – is implemented, timed out, and backed by default routes that carry the call when the lookups do not. And because it ships with a mock LIS and ECRF, all of it can be exercised in your lab on day one, not at next year’s plugtest.
References: RFC 5985 (HELD), RFC 6155 (HELD device identity), RFC 6753 (location dereference), RFC 5222 (LoST), RFC 5031 (service URNs), RFC 4119 (PIDF-LO), RFC 5491 (PIDF-LO geodetic shapes), RFC 6442 (SIP Geolocation), RFC 7852 (additional data), 3GPP TS 23.167 (IMS emergency sessions), ETSI TS 103 479 (NG112 core architecture), NENA i3.