Chapter 13 - Emergency Calls on the Internet pptx

When users want to make an emergency call, they simply dial the local emergency number e.g., 112, 911, and the call is connected to the closest emergency center, which will dispatch the

Trang 1

Chapter 13

Emergency Calls on the Internet

13.1 Introduction

This chapter is devoted to the complex topic of based emergency calls What makes IP-based emergency calls a complex issue? First of all, an emergency call needs to be routed

to the closest Public Safety Answering Point (PSAP) This requires the call to be routed to the PSAP based on the caller’s location, which in turns requires the caller’s location to be determined roughly Furthermore, it also requires a mechanism to translate the location into the real URI of the PSAP All of these issues make IP-based emergency calls complex in comparison with regular IP-based calls using SIP

There are three different types of emergency communications, of which this chapter covers just the first

Citizen-to-authority communications This type of communication refers to users dialling

an emergency number, such as 112 in Europe or 911 in the USA Usually these are

referred to as emergency calls.

Authority-to-citizen communications This typically refers to national emergency centers

broadcasting alerting information related to emergency situations For example, in the case of a rough weather condition, such as a hurricane or a tsunami, an alert can be issued to the population providing instructions for their safety In some cases, this type of emergency communication may require warning messages or instructions to be launched to all citizens or a group of them who are located in a determined geographical area, e.g., where a disaster has taken place

Authority-to-authority communications This refers to the type of communication that

takes place between two authorities during an emergency situation This might be the communication that takes place between a national emergency coordination center and the police, fire brigade, or hospitals Typically, this type of communication has higher priority than the rest of the calls, and it might pre-empt existing calls

When users want to make an emergency call, they simply dial the local emergency number (e.g., 112, 911), and the call is connected to the closest emergency center, which will dispatch the requested emergency service (e.g., an ambulance) This process is simple from the user’s point of view, because the user just needs to dial the local emergency number However, the process can be split into the following building blocks

´ıa- M ar t´ın

The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third Edition

Gonzalo Camarillo and Miguel A Garc

Trang 2

First, the terminal needs to determine its location, or if this is not possible, some network entity must do it This is required for two reasons On one hand, the emergency call needs

to be routed to the closest PSAP A PSAP is a local emergency coordination center which

is able to dispatch the appropriate emergency service (fire brigade, ambulance, police, etc.)

to the requested location A PSAP has a geographical area of responsibility The size of this area varies from country to country In some cases, a PSAP covers a small geographical area, such as a county or a city, whereas in other cases it covers a larger area, such as a state

or a whole country In any case, the idea is to connect the user with the closest PSAP and

to dispatch the requested emergency personnel to the user’s location On the other hand, the location information is required at the PSAP to dispatch the emergency personnel to the user’s location Usually, the user indicates the geographical location to the PSAP agent, but if a location determination mechanism is available, then it might be more accurate or help in dispatching the emergency personnel Location determination is further described in Section 13.2

Second, the terminal needs to understand that the user is making an emergency call and needs to include such information in the signaling, so that exceptional procedures for emergency calls are followed It is not necessary that the local emergency number is present

in the signaling, but an indication that “this is an emergency call” The same is also true for GSM emergency calls, where there is an indication of the emergency call, but not the dialed number Sometimes, there are different numbers for each of the emergency services, so, it might happen that the signaling contains an indication of the specific service that the user requested (e.g., police, or ambulance) The identification of emergency calls is analyzed in greater detail in Section 13.3

Third, there is a need to find the URI of the PSAP that is able to answer the call, which

is the PSAP responsible for the current user’s location As a consequence the emergency calls are routed based on the caller’s location rather than on the callee’s number Either the terminal itself or a proxies in the network can determine the URI of the closest PSAP to the current location, but in any case, this determination requires a database to be queried with the user’s location as input in order to obtain the routing address of the closest PSAP Section 13.4 further analyzes the procedures to determine the closest PSAP

Last, the emergency call is issued If location information is available to the terminal, then the location is attached to the INVITE request that establishes the session If not, a proxy need to determine the terminal’s location to obtain the routing information to the PSAP The INVITE request is routed to the closest PSAP where an agent answers The agent at the PSAP can dispatch the requested service to the user’s location Issuing an emergency call is further described in Section 13.5

The remaining sections of the chapter analyze the protocols and procedures that are available for each of these building blocks in a greater level of detail

13.2 Location Acquisition

Location determination and acquisition is an important component of emergency calls The terminal’s location is required for routing the call to the PSAP that handles the emergency services in the area where the user is located In addition, the PSAP can use that location information to dispatch the emergency service to that location This section describes different mechanisms for location determination and then for transporting such location to the terminal

Trang 3

13.2 LOCATION ACQUISITION 313

Location can be expressed in either geodetic or civic format All location determination protocols support both formats of location information Geodetic location information can be expressed as a point, as a polygon, or as a shape of various formats

Nearly all location determination protocols are able to convey it as a value or as a reference A value contains the actual geodetic or civic location information A reference

is merely a pointer, such as an HTTP URI, to a server that stores the actual location The receiver of the reference can invoke the URI to obtain the actual location, if required There are several mechanisms to determine the location of the user Some mechanisms require the terminal to obtain the location, others require the network to locate it Some mechanism are designed for fixed and wireless environments, others for the cellular space In general, location determination can be classified into four different groups of mechanisms: (i) the user enters its location information;

(ii) the access network provides access to a “wire database” with location information; (iii) terminal-measured location information;

(iv) network-measured location information

The following sections analyze the different location determination mechanisms

13.2.1 Manual Configuration

The simplest mechanism for providing location information consists of manually configuring the terminal with either the geodetic or the civic location information When an emergency call takes place, the terminal can send the pre-configured location information along with the INVITE request

For obvious reasons, manual configuration is only applicable to fixed terminals The location supplied is accurate as it is the configured information However, it is prone to errors Assume that we have a user whose fixed terminal is manually configured with location information Assume that the user relocates to a different district or city The terminal should

be reconfigured with the new location information If the user forgets to reconfigure it, emergency calls might be routed to the wrong PSAP Therefore, we can think of manual configuration as the last resort for location determination

13.2.2 Location Acquired from DHCP

We described DHCP in Section 5.1, where we indicated that IMS terminals can use DHCP to request configuration parameters, such as its IP address or the address of an outbound proxy (e.g., a P-CSCF in IMS) Another application of DHCP allows a terminal to request its civic

or geospatial location information from a DHCP server Essentially, the terminal includes in

a DHCP request the list of parameters it is interested in receiving So, the DHCP request includes, among other parameters, the DHCP option for Civic Addresses Configuration Information (specified in RFC4776 [297]) or the DHCP option for Coordinate-based Location Configuration Information (specified in RFC 3825 [254]) The former requests location information as a civic address, i.e., street, number, postal code, city, country, etc The latter requests the location information as a combination of latitude, longitude, and altitude In any case, both DHCP options are applicable to either DHCP for IPv4 (RFC 2131 [123]) and DHCP for IPv6 (RFC 3315 [124])

Trang 4

This mechanism puts the burden of determining the location configuration on to a DHCP server So, for either of these options to work correctly, the DHCP server has to gain access

to the location information of the terminal that requests it In fixed environments, such

as enterprises or consumer ADSL connections, this is done in a database that matches the termination of a physical line with its civic or geospatial address The DHCP server has access to such a database, sometimes it is even built into the server When a new fixed lined

is deployed (e.g., an Ethernet switch port, the location of a WLAN access point, or an ADSL line), the civic or geospatial location information where the line terminates is added to entry

of the line in the database Then, when the DHCP server receives a DHCP request indicating either of the two options, the DHCP server queries the database with the line identifier, and obtains the requested location, which is sent in the DHCP response along with the rest of requested information (e.g., IP address, DNS server, SIP outbound proxy server)

The DHCP mechanism, although it could be applicable to both fixed and mobile networks, is typically used in stationary environments, for example, fixed networks This also includes fixed WLAN access points

13.2.3 Location Acquired from Layer 2 Protocols

There are a number of proprietary Layer 2 protocols that allow elements connected to

a network to discover each other and discover how they are connected The industry knows the burden of dealing with proprietary protocols, so in year 2005, the Link Layer Discovery Protocol (LLDP), specified in IEEE 802.1AB [170], emerged as the standard in 802-type LANs for the discovery of connected elements LLDP is used for learning the physical topology information for network management purposes and for advertising the functionalities provided by each network element For example, LLDP messages provide information about chassis and port identification, system name, system capabilities, system description, etc

In 2006, the Telecommunications Industry Association (TIA) extended LLDP when it created Link Layer Discovery Protocol–Media Endpoint Discovery (LLDP-MED), specified

in ANSI/TIA-1057 [74] LLDP-MED simplifies the deployment of VoIP terminals in 802 LANs LLDP-MED adds new messages to provide information about power over Ethernet, network policy configuration (e.g., the virtual LAN identification), media endpoint location information, and inventory management For the purpose of emergency calls, our interest lies

on the media endpoint location information that LLDP-MED is able to supply

LLDP-MED is able to provide the location information of a terminal in three different formats Two of these formats are defined by the IETF for use with the DHCP protocol; the third one is specified by the National Emergency Number Association (NENA) The three location information data formats that LLDP-MED supports are:

• coordinate-based location configuration information, as specified in RFC 3825 [254];

• civic address location configuration information, as specified in RFC 4776 [297];

• emergency Location Identification Number, specified by NENA TID 07-503 [218] Owing to the nature of 802 LANs, this mechanism is applicable to stationary systems, for example, Ethernet LANs or networks terminated in managed WLAN access points

Trang 5

13.2.4 Location Acquired from Application Layer Protocols

There are a number of protocols that are at the application level (layer 7) and are able to deliver the location of a device The assumption is that a server is able to determine the location of the device This might be the case when the server contains the database that maps either Ethernet ports or WLAN access points to the location of those ports and access points; or it might be the case when the server is able to determine the location of a mobile device through triangulation of the cells

One of the protocols for retrieving location information at the application layer is HTTP Enabled Location Delivery (HELD) HELD assumes a server located in the access network that has access to the terminal location information The server implements an HTTP server and the extensions specified by HELD in the Internet-Draft “HTTP Enabled Location Delivery (HELD)” [83]

HELD allows a terminal to retrieve its actual location information This is known as location-by-value, and provides the terminal with the literal location information HELD also allows a terminal to retrieve a pointer to its location information This is known as location-by-reference and provides the terminal with one or more URIs that contain the actual terminal location

HELD assumes that the client is configured with the URI of the HELD server that is able

to determine the client’s location HELD defines three messages to support the retrieval of location These messages are, in fact, XML documents that are conveyed in HTTP requests

or responses The three HELD messages are known as Location Request, Location Response, and error messages.

Figure 13.1: HELD operation with HTTP POST

The general operation of HELD is described with the aid of Figure 13.1 A client configured with the URI of the HELD server sends an HTTP POST request (1) This request indicates, among other information, the XML document types that the client understands HELD documents are identified with the content type “application/held+xml”, which is inserted into the Accept header field The POST request also contains a Location Request XML document, which is identified as a HELD document in the Content-Type header field The Location Request document can be as simple as the example of Figure 13.2, which merely indicates that the client is interested in receiving both the civic and geodetic location information The server retrieves the client’s location information, for example, by examining

Trang 6

the Ethernet port the request was received from Then, it composes a Location Response XML document and attaches it to the 200 (OK) response (2) Figure 13.3 shows an example

of a Location Response message The example includes the location in both geodetic and civic location format In fact, the Location Response message embeds a Presence Location Object, which we describe later in Section 19.12 when we analyze presence information documents in more detail

<?xml version="1.0" encoding="UTF-8"?>

geodetic

civic

</locationType>

</locationRequest>

Figure 13.2: HELD Location Request XML message

A second mechanism to obtain the location is also presented in Figure 13.4 A second client wants to retrieve its location information This second client sends an HTTP GET request (1) to its configured HELD server Unlike the POST request (1) of Figure 13.1, this GET request (1) does not contain a body, so the semantics are merely “please send me my current location information” Like the POST request (1) of Figure 13.1, this GET request (1) contains an Accept header field indicated the support for the HELD document format Then the HELD server replies with a 200 (OK) response (2) Since the client did not have an opportunity to express its preference about the location format and other parameters, it is totally up to the HELD server to decide which format or formats to include in the HELD document

13.2.5 Location Acquired from a GPS

GPS is the most sophisticated location acquisition mechanism With the mass market advent

of GPS systems, the price of GPS chips is decreasing, with the result that high-end mobile devices now contain a built-in GPS receiver In addition, stand-alone GPS receivers can interface with mobile devices, so that the mobile device can read the current position from the GPS receiver

The accuracy of a GPS receiver is of the order of tens of meters with 95% of confidence, which is more than enough for the purpose of emergency calls This makes GPS the preferred mechanism for location information However, there are some drawbacks A GPS receiver requires a clear sky for receiving at least three GPS satellites in order to calculate the position This precludes the usage of GPS receivers in buildings, such as offices, blocks of apartments, and any other kind of indoor facilities It is also known that GPS has trouble in urban areas, especially where there are high buildings

13.2.6 Wireless Triangulation

Wireless networks are also able to provide a wireless triangulation mechanism for supplying the terminal’s location Triangulation is a process by which the location of a terminal is determined by measuring the radial distance, direction, strength, angle of arrival, or time of arrival of the received signal from three different points

Trang 7

<presence xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"

xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"

entity="pres:someone@example.com">

<gp:geopriv>

<gp:location-info>

<gs:Circle

xmlns:gs="http://www.opengis.net/pidflo/1.0"

xmlns:gml="http://www.opengis.net/gml"

srsName="urn:ogc:def:crs:EPSG::4326">

<gml:pos>60.102937 22.320921</gml:pos>

<gs:radius uom="urn:ogc:def:uom:EPSG::9001">30

</gs:radius>

</gs:Circle>

<ca:civicAddress

xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xml:lang="FI">

<ca:country>FI</ca:country>

<ca:A3>Helsinki</ca:A3>

<ca:A6>Mannerheimintie</ca:A6>

<ca:HNO>14</ca:HNO>

<ca:NAM>Example Corporation</ca:NAM>

<ca:PC>00100</ca:PC>

</ca:civicAddress>

</gp:location-info>

<gp:usage-rules>

<gp:retransmission-allowed>false</gp:retransmission-allowed>

<gp:retention-expiry>

2007-05-25T12:35:02+10:00

</gp:retention-expiry>

</gp:usage-rules>

</gp:geopriv>

</status>

</tuple>

</presence>

</locationResponse>

Figure 13.3: Location Response XML message

Trang 8

Figure 13.4: HELD operation with HTTP GET

13.3 Identifying Emergency Calls

An emergency call is typically triggered when the user dials a well-known number for emergency calls (e.g., 112, 911) In circuit-switched GSM emergency calls, the signaling associated with an emergency call does not actually contain the dialed number, but, instead,

it turns a bit to indicate that “this is an emergency call” This triggers the special procedures for routing the call based on location rather than the dialed number

In the Internet there is also a need for indicating that the user is making an emergency call For example, SIP proxies may need to apply special procedures to emergency calls, such

as routing based on the location rather than on the dialed number Proxies may be able to give high priority to emergency calls and bypass internal queues that, otherwise, may delay the completion of the call

In the Internet, when a user makes an emergency call (e.g., by dialling 112, 911, or other local emergency number), the SIP User Agent uses a well-known SOS Uniform Resource Name (URN) to identify the call as an emergency call This URN is specified

in RFC 5031 [299] The generic SOS URN is

urn:service:sos

The SIP User Agent inserts this SOS URN in the Request-URI of a SIP INVITE request.

In many countries, there are specific numbers that route calls to the police, ambu-lance, fire brigade, etc RFC 5031 [299] provides other more specific URNs, including: urn:service:sos.fire to reach a fire service; urn:service:sos.police to reach a police or law enforcement force; or urn:service:sos.physician to reach a physician referral service

The availability of SOS URNs allows terminal manufacturers to deploy universal devices that implement a “red button” for emergencies, independently of the country where the device

is operating

In most cases phones do not implement a red button to trigger an emergency call Typically phones are configured with the local emergency number (either in the local configuration or available in the Universal Integrated Circuit Card (UICC)), so that when the user dials 112 or other similar emergency number, the phone creates an INVITE request

whose Request-URI is effectively a SOS URN.

Trang 9

13.4 LOCATING THE CLOSEST PSAP 319

13.4 Locating the Closest PSAP

When a terminal is about to place an emergency call, it needs to learn the real SIP URI or TEL URL of the closest PSAP to the user’s location If the terminal is unable to find the SIP URI or TEL URL of its closest PSAP, a SIP proxy can assist it, in which case, the search of the SIP URI or TEL URL of the closest PSAP is delegated to the proxy In any case, either the terminal or the proxy need to find out the PSAP URI The IETF has developed extensions

to HTTP to solve this piece of the puzzle These extensions are specified in the Internet-Draft

“LoST: A Location-to-Service Translation Protocol” [163]

LoST allows a client to request the URI that corresponds to a given location and a given service In the case of emergency calls, the service is clearly emergency calls, and the URI is the PSAP URI However, LoST can be used in any other context where a location and service pair needs to be translated into a URI

The basic operation in LoST takes a location (either in geodetic or civic location information) and a service as input, and generates a URI as an output This is the URI of the service in such location, so for the emergency call service this is the URI of the PSAP that serves that location Furthermore, LoST is also able to convey the geographical boundary that is under the URI responsibility Thus, a terminal can correlate its position with the PSAP boundary, and if the terminal moves outside that PSAP boundary, the terminal can do a new query to find the local PSAP for the new location

Figure 13.5: LoST operation

Like HELD, LoST reuses HTTP requests and responses to convey XML documents that operate as queries and responses Actually, LoST uses POST requests and its responses (typically 200 (OK)) to transport the LoST queries and responses The general operation

of LoST is depicted in Figure 13.5 LoST queries and responses are, in fact, XML documents that are identified with the MIME type application/lost+xml LoST defines the following pairs of queries and responses

• <findService> and <findServiceResponse> These are the main request and response in LoST A client sends a <findService> request containing the service of its interest along with its civic or geodetic location and receives a

<findServiceResponse> message that contains the URLs that map to such location and service Applied to emergency calls, a client sends to its LoST server a

Trang 10

<findService> request containing its location and receives the URL of the closest PSAP

• <getServiceBoundary> and <getServiceBoundaryResponse> Any URL that has been mapped to a service has a boundary where the URL is applicable For example, in emergency calls, a PSAP (which is identified by its URL) might have responsibility over a large city LoST can convey the boundary where the PSAP URI

is valid However, a LoST server might not always send the boundary of a service in

a response, but, instead, it can send a reference to it The <getServiceBoundary> request allows a client to de-reference a service boundary, thus allowing the client to determine the boundary of URL associated to a service

• <listServices> and <listServicesResponse> We have indicated that LoST is

a generic protocol that can be used not only in the context of emergency services, but also with any other service where a location should be mapped to a URL (e.g., a pizza delivery service) Clients send a <listServices> request to a LoST server to find out the services that the server understands

• <listServicesByLocation> and <listServicesByLocationResponse> This request and response pair is used to find out the available services in a given location

<findService

xmlns="urn:ietf:params:xml:ns:lost1"

xmlns:p2="http://www.opengis.net/gml"

serviceBoundary="value"

recursive="true">

<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">

<p2:pos>43.6 -79.3</p2:pos>

</p2:Point>

</location>

<service>urn:service:sos.police</service>

</findService>

Figure 13.6: A <findService> query in LoST

Let us take a look at an example of the core LoST query and response A client generates an HTTP GET request towards its LoST server The HTTP request includes a

<findService> XML document, such as that shown in Figure 13.6 The location element contains the geodetic coordinates of interest, and the service element contains the service

of interest, in this case, the police emergency services

Then, the LoST server generates a <findServiceResponse> XML document, such as that included in Figure 13.7, and attaches it to a 200 (OK) response The response contains the civic address corresponding to the geodetic coordinates included in the request, in addition to the SIP URI or TEL URL of the police emergency service and the boundary where such URI

is applicable, which corresponds to a city

Định dạng
Số trang	17
Dung lượng	508,4 KB