POSITION INFORMATION FOR VOIP EMERGENCY CALLS
Originating from a Wireless Metropolitan Access Network
J. Barcel´o, B. Bellalta, C. Maci´an, M. Oliver and A. Sfairopoulou
Technology Department, Universitat Pompeu Fabra, Passeig de Circumval.laci´o 8, Barcelona, Spain
Keywords:
Location, WiFi, VoIP, Emergency Calls.
Abstract:
This article describes a mechanism to provide location information about users of a wireless metropolitan
access network to trusted and authorized third parties. A case of particular interest is that of providing emer-
gency centers with the location of the VoIP caller. The location information is obtained from the wireless
access points using SNMP polling, and stored in a location server. The outbound SIP proxy server requests
the user’s location and includes it in the SIP invite message when the callee is an emergency center.
1 INTRODUCTION
VoIP communications appear as a new channel to
reach emergency call centers. However, they usually
fail to provide the position of the caller.
The provision of the position to the emergency
center consists of two steps; first, obtaining the po-
sition of the user, and second, transmitting this infor-
mation to the emergency center.
The proposed solution focuses on a scenario in
which the caller is connected to a Wireless Metropol-
itan Access Network. This is a level-2 network, or
a Internet Attachment Provider (IAP) in the terminol-
ogy of the Internet draft that addresses emergency SIP
calls (Schulzrinne and Marshall, 2006). The other
supposition is that the emergency call is actually an
end-to-end IP call. In other words, that it terminates
in a IP-capable emergency center.
The second section of the article references some
related work. The third section addresses the problem
of collecting caller’s position in a Wireless Metropol-
itan Access Network based on IEEE 802.11 technol-
ogy. In the fourth section the distribution of such in-
formation to third party web applications is explored.
Section 5 is devoted to the inclusion of caller loca-
tion information in emergency calls. The last section
concludes this preliminary work.
2 RELATED WORK
In our approach the location of the user is approxi-
mated by the position of the access point to which
the wireless terminal is associated. There are dif-
ferent alternatives to find that association detailed
in(Clementi, 2005).
The accuracy might be increased by compiling ra-
dio measures from the user’s device and comparing
them with a radiomap that reflects the propagation
characteristics of the environment (Bahl and Padman-
abhan, 2000).
For practical purposes, a network-assisted ap-
proach is much more desirable. In this case the infor-
mation is obtained from network devices rather than
networked devices. This would allow to find the po-
sition of any kind of terminal, no matter whether it is
a laptop, a PDA or a telephone.
Once the user is located, the position information
has to be attached to the call, and the call has to be
routed to the corresponding emergencycenter. (Rosen
et al., 2006) covers these aspects in a general way.
The recommendations for position information
management are described in (Cuellar et al., 2004).
(Peterson, 2005) defines the position object, called
Presence Information Data Format - Location (PIDF-
LO).
(Polk and Rosen, 2006) proposes a mechanism to
convey position information in a SIP message. It in-
393
Barceló J., Bellalta B., Macián C., Oliver M. and Sfairopoulou A. (2007).
POSITION INFORMATION FOR VOIP EMERGENCY CALLS - Originating from a Wireless Metropolitan Access Network.
In Proceedings of the Third International Conference on Web Information Systems and Technologies - Internet Technology, pages 393-396
DOI: 10.5220/0001277203930396
Copyright
c
 SciTePress

volves the inclusion of a new SIP header, the Geolo-
cation header, either with the PIDF-LO in the body
or as a location-by-reference URI. Since in our pro-
posal the terminal is not aware of its own position,
and body parts may not be inserted by a proxy server,
the only applicable solution is specifying a location-
by-reference URI.
Current work at the IETF mainly supports the idea
that the user terminals obtain their own position at
boot time (e.g. using DHCP) and then include this
information in the SIP message that initiates the call.
This approach has two main shortcomings. The first
is that the UAs that are available nowadays do not in-
clude emergency call and location functionality. The
second is the assumption that the terminal has not
moved since boot time (or last DHCP renewal). For
this reason, this article suggests a network-oriented
approach, that will work with existing SIP phones.
3 OBTAINING THE POSITION
INFORMATION
Every wireless access point maintains a table that con-
tains the associated terminals’ addresses. This infor-
mation can be collected to roughly determine the po-
sition of a user, since the coverage area of an access
point is limited, specially indoors (typically less than
100m).
This kind of position information is called cell
tower/sector. This is one of the types of location in-
formation supported by the IETF and is intended for
mobile networks (sectorial) towers. The others are
civic and geospatial (WGS84 coordinates). The tower
(in our case the access point) position is expressed as
a point, and might include an irregularly shaped poly-
gon of geospatial coordinates reflecting the coverage
footprint.
The entity that collects and re-distributes location
information is called location server. A database is
created in the location server, containing a table with
the IP address of each access point, together with the
position of the access point (coordinates), the size of
the cell, and type of access point (i.e. the manufac-
turer, model and firmware version). Based on this ta-
ble, an SNMP poll is conducted periodically to obtain
the association tables from the Management Informa-
tion Base (MIB). These tables contain the MAC ad-
dresses and IP addresses of the wireless terminals as-
sociated to the polled access point.
After polling all the access points the location
server can store in a database the association between
terminal address (MAC and IP) and access point ad-
dress (IP). And knowing this association, the position
of the terminal can be inferred.
The time granularity depends on the frequency of
the polls. The design decision in our implementa-
tion is to perform polls every 30 seconds. More polls
would offer more accuracy, but also generate more
network traffic. A solution to increase time accuracy
that does not have such an impact in network traf-
fic consists on combining SNMP polls with SNMP
traps. Some access points can be configured to issue
an SNMP trap (a message to the network management
service) after IEEE802.11 events (association or de-
association of terminals) occur. A solution based only
on traps is undesirable, because the traps (UDP pack-
ets) can be lost on their way to the location server,
specially on wireless links.
4 MAKING THE LOCATION
INFORMATION AVAILABLE
TO TRUSTED THIRD PARTIES
Previous work in this area (Hong et al., 2003) already
recognized the importance of mechanisms to distrib-
ute the position information only after user consent.
Our proposal differs from the previous ones in that it
is completely web-based. The user does not need to
install any special software in her wireless terminal to
manage the position information.
In our testbed, the access network is owned and
managed by an entity called the Neutral Operator.
This entity would be in charge of running the loca-
tion server. If this location information has to lead to
a plethora of new and original services, it should be
available to third parties. Being position information
tightly related to privacy, only trusted parties should
be provided with such information, and always after
user consent. We propose that the location server of-
fers this data via a Web Service interface in the pub-
lic Internet. Any organization interested in providing
position-aware content should apply to the Neutral
Operator. If the organization is considered trusted,
the Neutral Operator will provide it with credentials
that allow identification in subsequent transactions.
The reason to choose Web Services is to make the
position information available to the broadest vari-
ety of position-aware applications. Mobile operators
have already chosen this mechanism to provide cell-
related position information to their commercial part-
ners. Making the position provision for WiFi network
operators similar to the one offered by mobile oper-
ator would simplify the implementation of position-
aware applications that act as consumers from both
sources. The implementation uses Axis’ native JWS
WEBIST 2007 - International Conference on Web Information Systems and Technologies
394

(Java Web Services) files.
A well defined process has been established to
guarantee that the position information is offered only
after user authorization. It consists in a number of
steps that are illustrated in figure 1.
During the authorization process, a user that is
browsing a location aware website is redirected to an
interface of the location server that is connected to
the same access (level 2) network as the user. Then
the user is going to be back-redirected to the position-
aware website.
Every time that the position-aware application
contacts the location service, it has to provide a user
name and a password for authentication purposes.
This detail has been obviated in the explanation that
follows for the sake of simplicity.
Another aspect that should be highlighted from
figure 1 is that the location server needs two physi-
cal interfaces. The first interface is connected to the
access network where the user resides. Usually, the
wireless terminals use private addressing, and there-
fore the first interface of the location server probably
has a private address. In any case it needs an address
in the same subnet as the user’s terminal.
The second interface connects the location server
to the Internet. This interface is used to communi-
cate with third party position-aware applications and
is configured with a public Internet address.
This is a step-by step explanation:
1. The user browses to a position-aware website.
2. This site wants to obtain the position of the user,
in order to provide that user with position tailored
content. The position-aware website needs to con-
tact the location server to ask for that informa-
tion, but explicit authorization from the user is
needed. To obtain that permission, the position-
aware website contacts the location server and
sends a user identifier (user
id). This user id must
be unique in the position-aware-website. The
back-redirect URL (which is going to be used
again in step 7) is also sent.
3. As an answer the location server sends an url
pointing to an interface of the location server that
is situated in the access network.
4. The position-aware website redirects the user to
the url indicated in the previous step, delivering
the application name and the user id as parame-
ters attached at the URL.
5. At this point, the location server receives the
HTTP request from the user. It captures the user
MAC address and associates it to the position-
aware website and user id in the database.
represents web−service interaction
represents web−browser interaction
LOCATION
AWARE
WEBSITE
ACCESS
NETWORK
INTERFACE
INTERNET
INTERFACE
USER
SERVER
1
2
3
4
5
6
9
8
7
10
LOCATION
Figure 1: Steps to authorize the provision of position infor-
mation to trusted third parties.
The MAC value is the key value that allows to
search for a user in the position database, since it
is the value that appears in the access points asso-
ciation tables.
6. The location server presents a form to the user
asking if she or he wants to be located by the
position-aware website for a given period of time
(e.g one hour).
7. The user agrees.
8. The user is back-redirected to the location-aware
website, using the url mentioned in step 2.
9. Now the position-aware website can request posi-
tion information.
10. And deliver the position-tailored content to the
user.
The Web Services transactions contain sensitive
information such as credentials and the position of
the user and therefore they should be appropriately
secured (TC, 2006).
The described protocol offers position informa-
tion to trusted third parties without revealing any fur-
ther information about the user. Usually, the position-
aware website does not even know the IP address
of the wireless terminal, since the terminal is prob-
ably assigned a private address that is converted using
NAT/PAT. However, a user might decide to provide
its identity (by any means, out of the scope of this
work) and its position to the same position-aware ap-
plication. In this case, this pair of items have severe
POSITION INFORMATION FOR VOIP EMERGENCY CALLS - Originating from a Wireless Metropolitan Access
Network
395

privacy implications and should be protected conse-
quently.
5 PROVIDING EMERGENCY
CENTERS WITH LOCATION
INFORMATION
When adding position information to calls, it makes
sense to use SIP mechanisms instead of Web Ser-
vices. Thus the Geolocation header is used as pro-
posed in (Polk and Rosen, 2006) containing location-
by-reference. This header is introduced by the SIP
proxy server. That means that both the SIP proxy and
the emergency center will need to contact the loca-
tion server to obtain the position of the terminal. The
dialogs with the location server will benefit from the
Web Services interface described in section 4 but will
skip the user authorization web-based mechanism.
INVITE sip:[e-mail] SIP/2.0
Via: SIP/2.0/UDP sipproxy.voipow.com
;branch=z9hG4bK77ef4c2312983.1
Via: SIP/2.0/UDP pc33.voipow.com
;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: 112 <sip:[e-mail]>
From: Victor <sip:[e-mail]>
;tag=1928301774
Call-ID: [e-mail]
CSeq: 314159 INVITE
Contact: <sip:[e-mail]>
Resource-Priority: wps.0
Geolocation: sips:[e-mail]
Supported: geolocation
Content-Type: application/sdp
Content-Length: 142
In the proposed example, Victor is in trouble and
calls to the emergency center. Victor is a client
of the voipow VoIP over Wireless service provider
and therefore the SIP phone sends the requests to its
outbound proxy called sipproxy.voipow.com
1
. The
proxy realizes that the destination of the call corre-
sponds to an emergency center and contact the loca-
tion server to obtain the position of the user.
The SIP proxy knows both the IP and the MAC
address of the terminal initiating and emergency call
and it is considered a trusted third party by the loca-
tion server and therefore is allowed to obtain the po-
sition of the user. In this special case, the SIP proxy
does not need explicit authorization from the user to
get the position information.
1
It has to be noted that this proxy needs direct connec-
tion to the wireless metropolitan access network, and there-
fore the solution outlined in this paper is not general, but
restricted to this scenario
The position information is included in the form
of a header called Geolocation. This header has to be
de-referenced by the emergency center to obtain the
user position in the form of PIDF-LO object.
In addition to the position header, the highest
Resource-Priority header is included in the request,
in accordance to (Schulzrinne and Polk, 2006)
6 CONCLUSION
This article presents ongoing work for collecting in-
formation about the position of the users of a Wire-
less Metropolitan Access Network and storing it in a
location server. After user authorization, this location
information can be offered to trusted third parties that
provide location tailored content.
A VoIP service provider operating in that network,
can incorporate intelligence in the outbound proxy to
interact with the location server. Then the location
information can be conveyed in SIP invite messages
in emergency calls. The location information is used
to route the call and is presented to the emergency
center operator.
REFERENCES
Bahl, P. and Padmanabhan, V. N. (2000). Radar: an in-
building rf-based user location and tracking system.
In IEEE INFOCOM, volume 2, pages 775–784.
Clementi, L. (2005). Infrastrutture di supporto per il
progetto di servizi dipendenti dalla locazione. M. eng.
thesis, Universit`a degli Studi di Bologna, Italy.
Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and Polk,
J. (2004). Geopriv Requirements. RFC 3693 (Infor-
mational).
Hong, J. I., Boriello, G., Landay, J. A., McDonald, D. A.,
Schilit, B. N., and Tygar, J. (2003). Privacy and se-
curity in the location-enhanced world wide web. In
UBICOMP.
Peterson, J. (2005). A Presence-based GEOPRIV Location
Object Format. RFC 4119 (Proposed Standard).
Polk, J. and Rosen, B. (2006). Session initiation protocol
location conveyance. Internet draft.
Rosen, B., Schulzrinne, H., Polk, J., and Newton, A. (2006).
Framework for emergency calling in internet multime-
dia. Internet draft.
Schulzrinne, H. and Marshall, R. (2006). Requirements for
emergency context resolution with internet technolo-
gies. Internet draft.
Schulzrinne, H. and Polk, J. (2006). Communications
Resource Priority for the Session Initiation Protocol
(SIP). RFC 4412 (Proposed Standard).
TC, O. W. S. S. (2006). Web services security v1.1.
WEBIST 2007 - International Conference on Web Information Systems and Technologies
396