Note: Descriptions are shown in the official language in which they were submitted.
CA 02548943 2006-05-08
T2006-059797-CA
METHOD, SYSTEM AND APPARATUS FOR RETRIEVING LOCATION
INFORMATION ON BEHALF OF A LOCATION-UNAWARE DEVICE IN A
PACKET-SWITCHED ENVIRONMENT
FIELD OF THE INVENTION
The present invention relates generally to communications over packet-switched
networks and, in particular, to a method, system and apparatus for retrieving
location
information on behalf of a location-unaware device in a packet-switched
environment.
BACKGROUND OF THE INVENTION
One of the underpinnings of emergency services is the ability to determine the
physical location from which an emergency call has been originated. For
example,
when an emergency call is made in the public switched telephone network (PSTN)
using a plain old telephony service (POTS) phone, the emergency call sent
through
the PSTN specifies the directory number of the POTS phone. Due to the way in
which the PSTN is configured, the directory number of each POTS phone
corresponds
to a fixed physical location (e.g., service address), and this relationship is
maintained
in an ALI database made available to Public Safety Answering Point (PSAP)
operators. Thus, upon handling an emergency call specifying a given directory
number, a PSAP operator who queries the ALI database using the given directory
number will learn the address from which the emergency call was placed and,
consequently, to which an emergency crew needs to be dispatched.
As voice-over-internet-protocol (VoIP) becomes the predominant technology used
in
the telecommunications industry, customers using VoIP endpoints (hereinafter
"VoIP
customers") will expect enhanced emergency services to be delivered when
emergency calls are originated from such devices over a broadband network. In
other
words, customers will expect an emergency address to be made available to an
operator who receives the emergency call at the appropriate PSAP, when they
make a
VoIP call or engage in a communication session via a packet-switched network
using
1
CA 02548943 2006-05-08
T2006-059797-CA
other means (such as Instant Messaging and the like). However, some broadband
service providers' networks are not natively compatible with the existing
emergency
infrastructure described above. In order to allow the delivery of emergency
services
to VoIP customers in a broadband network, the National Emergency Numbering
Association (NENA) has proposed various architectures that can interface with
the
existing emergency infrastructure, thereby allowing existing PSAPs to handle
emergency calls placed by VoIP customers.
Compounding the need to address the aforementioned issue of incompatibility
with
the existing emergency infrastructure is the need to address the issue of
determining
the physical location of the VoIP device from which an emergency call is
originated.
Specifically, because telephone numbers assigned to VoIP devices are not
necessarily
associated with a fixed address or location, the availability of the directory
number of
the VoIP device is not sufficient to allow the physical location of the VoIP
device to
be determined. In order to resolve this issue in the emergency services
context,
NENA has proposed a so-called "i2" architecture, which provides a network
element
known as a location information server (LIS) that serves as a repository for
location
information. The LIS is configured with a mapping between, on the one hand,
location information elements or so-called "emergency addresses" (in the form
of
civic addresses, geo-spatial location attributes or an appropriate location
tag) and, on
the other, logical representations of the respective physical locations with
which the
emergency addresses are associated.
According to the i2 standard, VoIP devices are supposed to receive information
on
their own physical locations from the LIS, so that this information is
conveyed to a
network node (such as a soft switch) responsible for handling an emergency
call
originated from the VoIP device.
However, one significant omission from NENA's proposed i2 architecture is any
description of interfaces and required protocols to enable the VoIP device to
retrieve
the emergency address from the LIS. In fact, document NENA 08-001, Issue 1,
December 6, 2005, entitled "Interim VoIP Architecture for Enhanced 9-1-1
Services
(i2)", hereby incorporated by reference herein, plainly states that "How the
IP
2
CA 02548943 2006-05-08
T2006-059797-CA
network actually determines the location and the protocol between the LIS and
IP
device is outside the scope of this document". Moreover, there is no
indication in the
industry how a location-unaware device is to locate and contact the LIS.
Actually, the
equipment presently available in the industry (such as the VoIP devices, soft
switches,
etc.) does not have the ability to retrieve such emergency address information
from
the LIS.
Thus, there remains a need for a solution to the problem of enabling a
location-
unaware device to retrieve their location information from the LIS.
SUMMARY OF THE INVENTION
According to a first broad aspect of the present invention there is provided a
method
for retrieving an emergency address on behalf of an endpoint in a packet-
switched
environment. The method comprises receiving an indication of a public network
address associated with the endpoint; determining a location information
database
address associated with a location information database responsible for
storing
emergency addresses for endpoints associated with a range of public network
addresses, the range of public network addresses including the public network
address
of the endpoint; transmitting to the location information database using the
location
information database address an emergency address request; the emergency
address
request comprising the public network address of the endpoint. The method
further
comprises responsive to the transmitting, receiving the emergency address from
the
location information database.
According to a second broad aspect of the present invention there is provided
a
system for retrieving an emergency address on behalf of an endpoint in a
packet-
switched environment. The system comprises a computing apparatus
conununicatively coupled to a call server responsible for handling an
emergency call
from the endpoint. The computing apparatus is operable to: receive an
indication of a
public network address associated with the endpoint from the call server;
determine a
location information database address associated with a location information
database
responsible for storing emergency addresses for endpoints associated with a
range of
3
CA 02548943 2006-05-08
T2006-059797-CA
public network addresses, the range of public network addresses including the
public
network address of the endpoint; transmit to the location information database
using
the location information database address an emergency address request; the
emergency address request comprising the public network address of the
endpoint;
receive the emergency address from the location information database.
According to a third broad aspect of the present invention there is provided a
computing apparatus for retrieving an emergency address on behalf of an
endpoint in
a packet-switched environment. The computing apparatus comprises means for
receiving an indication of a public network address associated with the
endpoint;
means for determining a location information database address associated with
a
location information database responsible for storing emergency addresses for
endpoints associated with a range of public network addresses, the range of
public
network addresses including the public network address of the endpoint; means
for
transmitting to the location information database using the location
information
database address an emergency address request; the emergency address request
comprising the public network address of the endpoint; means for receiving the
emergency address from the location information database.
According to a fourth broad aspect of the present invention there is provided
a call
server for handling voice-over-packet-switched-network calls on behalf of an
endpoint. The call server is operable to receive an emergency call originated
from the
endpoint; determine a public network address associated with the endpoint;
transmit
the public network address to a computing apparatus, the public network
address of
the endpoint for enabling the computing apparatus to determine a location
information
database address based on the public network address of the endpoint;
determine the
emergency address based on the location information database address and the
public
network address of the endpoint. The call server is further operable to
receive the
emergency address from the computing apparatus; handle the emergency call
based
on the emergency address.
4
CA 02548943 2006-05-08
T2006-059797-CA
According to a fifth broad aspect of the present invention there is provided a
method
for retrieving an emergency address on behalf of an endpoint in a packet-
switched
environment. The method comprises receiving an indication of a public network
address associated with the endpoint; determining a location information
database
address associated with a location information database responsible for
storing
emergency addresses for endpoints associated with a range of public network
addresses, the range of public network addresses including the public network
address
of the endpoint; transmitting to the location information database using the
location
information database address an emergency address request; the emergency
address
request comprising the public network address of the endpoint; the
transmitting being
instrumental in causing the location information database to determine the
emergency
address based on the public network address and to release the emergency
address.
According to another broad aspect of the present invention there is provided a
system
for retrieving an emergency address on behalf of an endpoint in a packet-
switched
environment. The system comprises a computing apparatus communicatively
coupled
to a call server responsible for handling an emergency call from the endpoint;
the
computing apparatus operable to receive an indication of a public network
address
associated with the endpoint from the call server; determine a location
information
database address associated with a location information database responsible
for
storing emergency addresses for endpoints associated with a range of public
network
addresses, the range of public network addresses including the public network
address
of the endpoint; transmit to the location information database using the
location
information database address an emergency address request; the emergency
address
request comprising the public network address of the endpoint; the emergency
address
request being instrumental in causing the location information database to
determine
the emergency address based on the public network address and to release the
emergency address.
According to yet another broad aspect of the present invention there is
provided a
method for retrieving location information on behalf of an endpoint in a
packet-
switched environment. The method comprises receiving an indication of a public
network address associated with the endpoint; determining a location
information
5
CA 02548943 2006-05-08
T2006-059797-CA
database address associated with a location information database responsible
for
storing location information for endpoints associated with a range of public
network
addresses, the range of public network addresses including the public network
address
of the endpoint; transmitting to the location information database using the
location
information database address a location information request; the location
information
request comprising the public network address of the endpoint; the
transmitting being
instrumental in causing the location information database to determine the
location
information based on the public network address and to release the location
information.
According to another broad aspect of the present invention there is provided
an
apparatus for retrieving location information on behalf of an endpoint in a
packet-
switched environment. The apparatus comprises means for receiving an
indication of
a public network address associated with the endpoint; means for determining a
location information database address associated with a location information
database
responsible for storing location information for endpoints associated with a
range of
public network addresses, the range of public network addresses including the
public
network address of the endpoint; means for transmitting to the location
information
database at the location information database address a location information
request;
the location information request comprising the public network address of the
endpoint; the transmitting being instrumental in causing the location
information
database to determine the location information based on the public network
address
and to release the location information.
These and other aspects and features of the present invention will now become
apparent to those of ordinary skill in the art upon review of the following
description
of specific embodiments of the invention in conjunction with the accompanying
drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
In the drawings:
6
CA 02548943 2006-05-08
T2006-059797-CA
Fig. 1 is a diagrammatic representation of an infrastructure for the delivery
of VoIP
telephony services to a VoIP endpoint, in accordance with an example non-
limiting
embodiment of the present invention;
Fig. 2 is a diagrammatic representation of an address directory of the
infrastructure of
Fig. 1;
Fig 3 depicts a block diagram of a method for retrieving an emergency address
on
behalf of a location-unaware device according to one non-limiting embodiment
of the
present invention;
Fig. 4 is a diagrammatic representation of an infrastructure for the delivery
of VoIP
telephony services to a VoIP endpoint, in accordance with another non-limiting
embodiment of the present invention;
Fig. 5 depicts a block diagram of a method for retrieving an emergency address
on
behalf of a location-unaware device according to another non-limiting
embodiment of
the present invention.
It is to be expressly understood that the description and drawings are only
for the
purpose of illustration of certain embodiments of the invention and are an aid
for
understanding. They are not intended to be a definition of the limits of the
invention.
DETAILED DESCRIPTION OF EMBODIMENTS
Fig. 1 shows various components of an infrastructure for delivering VoIP
telephony
services, including provisioning of emergency services, to a VoIP device, in
accordance with an example non-limiting embodiment of the present invention.
The
non-limiting example of the infrastructure comprises an access device 102
connected
to a port 106A of an access multiplexer 106 via a physical communication link
108.
In an example non-limiting embodiment, the access device 102 may comprise a
broadband modem 110 connected to a router 112 over a home network 114. The
7
CA 02548943 2006-05-08
T2006-059797-CA
router 112 may in turn be connected over the home network 114 to a VoIP phone
116
or, alternatively, to a POTS phone 118 via an analog terminal adapter (ATA)
120.
The ATA 120 and the VoIP phone 116 are just two non-limiting embodiments of a
so-
called "VoIP endpoint". Another non-limiting example of the VoIP endpoint can
be
embodied as a computer implementing an IP telephony software.
In another non-limiting embodiment, the functionality of the router 112 and
the
broadband modem 110 can be embodied in a single device. In an alternative non-
limiting embodiment of the present invention, the router 112 can be omitted
from the
infrastructure of Fig. 1. In yet further non-limiting embodiments of the
present
invention, the functionality of the ATA 120 can be incorporated into the
broadband
modem 110. In another non-limiting embodiment of the present invention, the
functionality of the ATA 120 can be incorporated into the router 112.
Alternatively, in
yet other non-limiting embodiments of the present invention, the functionality
of the
router 112, the broadband modem 110 and the ATA 120 (or the VoIP phone 116)
can
be incorporated into a single device.
In an example non-limiting embodiment, the physical communication link 108 can
be
a copper twisted pair, over which higher-layer protocols allow for the
exchange of
packets. In an alternative non-limiting embodiment, the physical communication
link
108 may comprise an Ethernet link, a fiber optic link (e.g., Fiber-to-the-
Home, Fiber-
to-the-Curb, etc.), a wireless link (e.g., EV-DO, WiMax, WiFi, CDMA, TDMA,
GSM, and the like), a cable, etc., or a combination thereof. In some non-
limiting
embodiments, the home network 114 can comprise an Ethernet network. In other
non-
limiting embodiments, the home network 114 can comprise a wireless network
(ex. an
802.11 based network, an 802.12 based network and the like) or any other
suitable
type of home network.
The access multiplexer 106, which in an example non-limiting embodiment can
comprise a digital subscriber line access multiplexer (DSLAM), can be
connected to a
network access server (NAS) 126, which may also be referred to by some in the
industry as a broadband remote access server (BRAS), a remote access server
(RAS)
or a broadband access server (BAS). The NAS 126 provides access to a core
packet-
8
CA 02548943 2006-05-08
T2006-059797-CA
switched data network 132, such as the Internet, over which VoIP calls can be
established. In an example non-limiting embodiment, communication between the
access multiplexer 106 and the NAS 126 may take place over a dedicated logical
link
(not depicted) between the access multiplexer 106 and the NAS 126. The
dedicated
logical link can be defined via an access data network 132. In an example non-
limiting embodiment, the dedicated logical link can be implemented as an
asynchronous transfer mode (ATM) permanent virtual circuit (PVC). In another
example non-limiting embodiment, the dedicated logical link can be implemented
as a
virtual local area network (VLAN). Still other implementations of the
dedicated
logical link are within the scope of the present invention.
The purpose of the access multiplexer 106 is to multiplex several physical
links (such
as the link 108) from several access devices (such as access device 102) for
communication over the access data network 132 and vice versa.
Also provided in Fig. 1 is a network element 140A, which in some embodiments
of
the present invention can be provided at an edge of the core packet-switched
data
network 132. The network element 140A is referred to the industry as a "call
server",
a "packet switch" or a "soft switch" and comprises circuitry, software andlor
control
logic for providing various communication services to VoIP endpoints (such as,
for
example, the aforementioned ATA 120 or VoIP phone 116). Examples of such
communication services include (i) connecting incoming calls to the VoIP
endpoint
(such as the ATA 120 or the VoIP phone 116); and (ii) handling outgoing calls
originated from the VoIP endpoint (such as the ATA 120 or the VoIP phone 116).
Other examples of communication services that can be performed by the network
element 140A can include but are not limited to call waiting, call forwarding,
voicemail recording, storage and retrieval, and so on.
In addition, the network element 140A can comprise suitable circuitry,
software
and/or control logic for exchanging calls with entities outside the core
packet-
switched data network 132. This is particularly convenient, when a call placed
by a
VoIP customer (i.e. a user of the VoIP phone 116) to a telephone number that
is
reachable only via the Public Switched Telephone Network (PSTN), which has
been
9
CA 02548943 2006-05-08
T2006-059797-CA
omitted from Fig. 1 for the sake of simplicity. A non-limiting example of the
network
element 140A can be embodied in a MCS 5200 Soft Switch manufactured by Nortel
Networks Ltd. of 8200 Dixie Road, Brampton, Ontario L6T 5P6, Canada.
Given the components of the infrastructure of Fig. 1 described above, it is
possible to
deliver VoIP telephony services to the user of the VoIP phone 116 or the POTS
phone
118 equipped with the ATA 120. The VoIP telephony service can be delivered by
a
service provider which manages the aforementioned access multiplexer 106, the
access data network 132, the network access server 126 and the network element
140A. Alternatively, the VoIP telephony service can be delivered by an
alternative
service provider in which case the VoIP telephony service "runs over" the
infrastructure of Fig. 1. This arrangement for delivering the VoIP telephony
service is
generally referred to as "over-the-top VoIP".
In order to facilitate provisioning of emergency services, the infrastructure
of Fig. 1
further comprises an emergency services entity 160. The emergency services
entity
160 can comprise several components, such as one or more Public Safety
Answering
Points (PSAPs), one or more 911 selective routers, one or more emergency
services
gateways, an Automatic Line Identification (ALI) database and the like. These
components are well known to those of skill in the art and, as such, have been
omitted
from Fig. 1.
In some embodiments of the present invention, the emergency services entity
160 can
be connected to the network element 140A via the PSTN (not depicted). In these
non-
limiting embodiments, the emergency services entity 160 can further comprise
one or
more media gateways (not depicted), the main purpose of which is to mediate
digital
communication to analog communication and vice versa.
Also provided in the infrastructure of Fig. 1 is a location information
database 150A.
In some non-limiting embodiments, the location information database 150A can
be
connected directly to the network element 140A. In other non-limiting
embodiments
of the present invention, the location information database 150A can be
integrated
with the network element 140A. Yet in further non-limiting embodiments, the
CA 02548943 2006-05-08
T2006-059797-CA
network element 140A can access the location information database 150A via the
core
packet-switched data network 132. In yet other non-limiting embodiments, the
location information database 150A may be distributed amongst a plurality of
functional elements and/or physical locations. It should be further
appreciated that the
location information database 150A can be managed, maintained and/or updated
by a
service provider that may be the same service provider as, or a different
service
provider from, the service provider that is responsible for providing the
access device
102 with access to the core packet-switched data network 132.
In an example non-limiting embodiment, the location information database 150A
can
be implemented as a location information server (LIS) described in the
document
NENA 08-001, Issue 1, December 6, 2005, entitled "Interim VoIP Architecture
for
Enhanced 9-1-1 Services (i2)", hereby incorporated by reference herein. To
this end,
the location information database 150A may comprise a plurality of records,
each
record mapping an emergency address to a logical identifier. In an example non-
limiting embodiment, the emergency address can be expressed as a civic address
or a
set of geo-spatial coordinates (e.g., latitude/longitude) indicative of a
physical location
of the VoIP telephone 116 or the ATA 120. In various example non-limiting
embodiments, the logical identifier may be an IP address in compliance with,
e.g.,
IPv4 or IPv6, or a proprietary address, label or tag. For the purposes of the
specific
non-limiting example presented herein below, it is assumed that the logical
identifier,
or in other words, a "public network address" of the VoIP endpoint comprises
an IP
address. It is further assumed that the location information database 150A has
been
populated with the emergency address associated with a location of the VoIP
phone
116.
In some non-limiting embodiments of the present invention, the infrastructure
of Fig.
1 can further comprise a network element 140B communicatively coupled to the
core
packet-switched data network 132. The network element 140B can be managed by a
service provider different from the service provider which manages the network
element 140A. The network element 140B can be operable to deliver VoIP
telephony
services to subscribers (not depicted) of the service provider which manages
the
network element 140B. These subscribers can use VoIP endpoints that can be
11
CA 02548943 2006-05-08
T2006-059797-CA
substantially similar to the VoIP phone 116 or the ATA 120. The service
provider
which manages the network element 140B can also provide so-called "roaming
services" to the subscribers of the service provider which manages the network
element 140A.
The network element 140B can be coupled to a location information database
150B,
which can be substantially similar to the location information database 150A.
To that
end, the location information database 150B maintains mappings associated with
the
subscribers of the service provider which manages the network element 140B.
The
network element 140B can also be coupled to the emergency services entity 160
for
the purposes of provisioning emergency services to its subscribers. In an
alternative
non-limiting embodiment of the present invention, the network element 140B can
be
coupled to a separate emergency services entity (not depicted).
Communicatively coupled to the core packet-switched data network 132 is a
location
retrieving server 145. The function of the location retrieving server 145 will
be
described in greater detail herein below. For now, suffice it to say, that the
location
retrieving server 145 is operable to retrieve location information from the
location
information database 150A or location information database 150B on behalf of a
location-unaware device, such the ATA 120, the VoIP phone 116 or the network
elements 140A, 140B. In some non-limiting embodiments of the present
invention,
the location retrieving server 145 can comprise a Ubiquity Application Server,
which
can be provided by Ubiquity of 515 Legget Drive, Suite 400, Ottawa, Ontario,
Canada. It should be noted that in alternative non-limiting embodiments of the
present
invention, any suitable type of an application server or a suitable computing
apparatus
can be used.
The location retrieving server 145 can be reached via the core packet-switched
data
network 132 at a network address, such as but not limited to an IP address. In
some
non-limiting embodiments, the IP address assigned to the location retrieving
server
145 can be a static IP address. The network element 140A and the network
element
140B are made aware of this static IP address for the purposes of reaching the
location
retrieving server 145 via the core packet-switched data network 132. In an
alternative
12
CA 02548943 2006-05-08
T2006-059797-CA
non-limiting embodiment, the IP address assigned to the location retrieving
server 145
can be a dynamic IP address. In these non-limiting embodiments, the network
element
140A and the network element 140B can be dynamically updated with the dynamic
IP
address of the location retrieval server 145, as is known to those of skill in
the art. In
an alternative non-limiting embodiment of the present invention, the location
retrieval
server 145 can be assigned a Unique Resource Identifier (URI), such as, for
example,
an URL. The network element 140A and the network element 140B can be made
aware of this URL of the location retrieval server 145. The URL enables the
network
element 140A and network element 140B to contact the location retrieval server
145
via the core packet-switched data network 132 by performing a DNS look-up, as
is
known to those of skill in the art.
Communicatively coupled to the location retrieving server 145 is an address
directory
147. Generally speaking, the purpose of the address directory 147 is to
maintain a
mapping between an IP address range assigned to a particular service provider
and a
network address of the location information database maintained by or for the
particular service provider. In an alternative non-limiting embodiment of the
present
invention, the address directory 147 can be integrated with the location
retrieving
server 145. In another alternative non-limiting embodiment of the present
invention,
the address directory 147 can be reachable by the location retrieving server
145 via
the core packet-switched data network 132. In yet further embodiments, the
address
directory 147 can be distributed amongst a plurality of functional elements
and/or
physical locations. The address directory 147 will now be described in greater
detail
with reference to Fig. 2, which depicts a specific non-limiting embodiment of
such an
address directory 147.
The address directory 147 can maintain a number of records, such as example
records
202, 204 and 206. Each of the records 202, 204 and 206 can map a service
provider
210 to a corresponding address range 212 and a corresponding location
information
database address 214. It should be noted that in some non-limiting embodiments
of
the present invention, the service provider 210 can be omitted from the
records 202,
204 and 206 maintained in the address directory 147.
13
CA 02548943 2006-05-08
T2006-059797-CA
The record 202 can be maintained for the service provider 210 "A", which can,
for
example, be the service provider which manages the aforementioned network
element
140A. The address range 212 for the service provider 210 "A" contains
"151.200Ø0/16" which is indicative of the range of IP addresses allotted to
the
service provider 210 "A" - from IP address 151.200Ø1 to 151.200.255.255. As
will
be appreciated by those of skill in the art, the service provider 210 "A" can
use these
allotted IP addresses, commonly referred to as a pool of available IP
addresses, to
assign an IP address to its subscribers, for example to the VoIP phone 116,
the ATA
120, the access device 102 and other devices served by the service provider
210"A".
The service provider 210 "A" can also "sublet" a portion of these allotted IP
addresses
to another service provider.
The location information database address 214 for the service provider 210 "A"
indicates a network address where a location information database (such as the
location information database 150A maintained by or for the service provider
210 "A"
can be reached). In the particular example depicted in record 202, the address
maintained in the location information database address 214 comprises an URL
"https://lis.a-isp.net".
The record 204 can be maintained for the service provider 210 "B", which can,
for
example, be the service provider which manages the aforementioned network
element
140B. The address range 212 for the service provider 210 "B" contains
"163.27Ø0/16" which is indicative of the range of IP addresses allotted to
the service
provider 210 "B" - from IP address 163.27Ø1 to 163.27.255.255. The location
information database address 214 for the service provider 210 "B" indicates a
network
address where a location information database (such as the location
information
database 150B maintained by or for the service provider 210 "B" can be
reached). In
the particular example depicted in record 204, the address maintained in the
location
information database address 214 comprises an URL "https://lisl.b-corp.com".
In substantially the same manner, the record 206 can be maintained for the
service
provider 210 "C", which can, for example, be the service provider which
manages a
network element (not depicted) substantially similar to the network elements
140A,
14
CA 02548943 2006-05-08
T2006-059797-CA
140B. The address range 212 for the service provider 210 "C" contains
"201Ø0.0/24'
which is indicative of the range of IP addresses allotted to the service
provider 210
"C" - from IP address 201Ø0.1 to 201.255.255.255. The location information
database address 214 for the service provider 210 "C" indicates a network
address
where a location information database (such as the location information
database
substantially similar to the location information databases 150A, 150B
maintained by
or for the service provider 210 "C" can be reached.) In the particular example
depicted in record 206 the address maintained in the location information
database
address 214 comprises an IP address "201Ø0.1".
Approaches to populating records 202, 204 and 206 are not particularly
limited. In
some embodiments of the present invention, the records 202, 204 and 206 can be
populated for service providers on the basis of a subscription. For example
the service
provider associated with the record 204 may subscribe to an emergency
retrieval
service contemplated in accordance with non-limiting embodiments of the
present
invention. During the subscription process, the service provider may provide
the
necessary information to populate the record 204. In another non-limiting
embodiment of the present invention, the entity which manages the address
directory
147 (for example, the service provider which manages the location retrieval
server
145) may populate records 202, 204 and 206 on the basis of publicly available
information about the IP ranges assigned to various service providers. An
example of
such publicly available information can be found at:
http://www.iana.org/assignments/ipv4-address-space. Those of skill in the art
will
appreciate that yet other approaches to populating records 202, 204 and 206
are
possible.
It should be explicitly stated that the above-presented description has used
the IP
address for the purposes of illustration and not as a limitation of the
embodiments of
the present invention. It should be noted that any other network address
suitable for
the purposes of communication via the core packet-switched data network 132
can be
used. A non-limiting example of such network address can comprise a SIP
address, a
MAC address, a proprietary network address, a device identifier and the like
CA 02548943 2006-05-08
T2006-059797-CA
Of course, it will be apparent to those skilled in the art that numerous
modifications
and variations of the infrastructure of Fig. 1 are possible. For example, in
an
alternative non-limiting embodiment, the access multiplexer 106 can be
omitted. This
is especially true in the case where the access device 102 implements a
wireless
access point. In an example non-limiting embodiment of this scenario, the
connection
between the wireless access point and the NAS 126 can be provided by a
dedicated
point-to-point link. In another non-limiting scenario where the broadband
modem 110
implements a cable modem, the access multiplexer 106 can also be omitted. Yet
in
another non-limiting embodiment, the NAS 126 can be omitted from the
infrastructure of Fig. 1.
Given the infrastructure of Fig. 1 and the address directory 147 as more
particularly
described in Fig. 2, it is possible to perform a method for retrieving an
emergency
address on behalf of a location-unaware device (such as the VoIP phone 116)
according to a non-limiting embodiment of the present invention. With
reference to
Fig. 3 the method for retrieving an emergency address on behalf of a location-
unaware device is now described in greater detail.
Step 310: receive an indication of a public network address
The method begins at step 310, where the location retrieving server 145
receives the indication of the public network address from a network element
responsible for handling an emergency call from a VoIP endpoint. In a
particular non-limiting example being used below, it is assumed that the user
of the VoIP phone 116 has originated the emergency call and that the network
element 140A is responsible for handling the emergency call.
In some embodiments of the present invention, the association between the
VoIP phone 116 and the network element 140A is "hard-coded" into the VoIP
phone 116. More specifically, a network address (such as but not limited to a
static IP address) of the network element 140A can be programmed, hard-
coded or otherwise made known to the VoIP phone 116. Therefore, all calls
originated from and destined to the VoIP phone 116 will be handled by the
network element 140A (or another network element, which acts as a fall-back
16
CA 02548943 2006-05-08
T2006-059797-CA
network element for the network element 140A, in case the network element
140A is down, congested or otherwise unavailable).
In an alternative non-limiting embodiment, the IP address assigned to the
network element 140A can be a dynamic IP address. In these non-limiting
embodiments, the VoIP phone 116 can be dynamically updated with the
dynamic IP address of the network element 140A, as is known to those of skill
in the art. In an alternative non-limiting embodiment of the present
invention,
the network element 140A can be assigned a Unique Resource Identifier
(URI), such as, for example, an URL. The VoIP phone 116 can be made aware
of this URL of the network element 140A. The URL enables the VoIP phone
116 to contact the network element 140A via the core packet-switched data
network 132 by performing a DNS look-up, as is known to those of kill in the
art.
In a specific non-limiting embodiment of the present invention, the location
retrieving server 145 receives a signaling message, such as a SIP invite
message, from the network element 140A in response to the network element
140A detecting the emergency call from the VoIP phone 116. In some
embodiments of the present invention, the network element 140A can act as a
SIP proxy or, in other words, the network element 140A can "forward" a SIP
invite message received from the VoIP phone 116 to the location retrieving
server 145. In these non-limiting embodiments, the location retrieving server
145 can extract the indication of the public network address associated with
the VoIP phone 116, which can be, but is not limited to, a public IP address,
by examining a "via" header of the SIP invite message received from the
network element 140A.
In an alternative non-limiting embodiment, the network element 140A can
handle the emergency call in a "back-to-back" manner. In other words, upon
receiving the emergency call from the VoIP phone 116, the network element
140A can generate a new SIP invite message to establish a VoIP call with the
location retrieving server 145. In these embodiments, the network element
17
CA 02548943 2006-05-08
T2006-059797-CA
140A firstly examines the SIP invite message received from the VoIP phone
116 to retrieve the indication of the public IP address associated with the
VoIP
phone 116. Secondly, when generating the SIP message destined to the
location retrieving server 145, the network element 140A inserts the
indication
of the public IP address into the SIP invite message. In a particular non-
limiting embodiment, the network element 140A can insert the indication of
the public IP address in the SIP invite message into the "via" header.
In some non-limiting embodiments of the present invention, which are
particularly applicable when the VoIP phone 116 is assigned a private IP
address for the purposes of communication on the home network 114, the
network element 140A can extract and transmit to the location retrieving
server 145 the indication of the public IP address associated with the router
112 or the broadband modem 110.
Irrespective of how the network element 140A generates the SIP invite
message, the location retrieving server 145 becomes aware of the public
network address of the VoIP phone 116 which is in process of establishing the
emergency call via the network element 140A.
It should be noted that in other non-limiting embodiments, any other suitable
network address of the VoIP phone 116, which is compatible with the location
information database 150A, or in other words any network address of the VoIP
phone 116 suitable for performing a lookup into the location information
database 150A, can be used. A non-limiting example of such network address
of the VoIP phone 116 can comprise a SIP address, a MAC address, a
proprietary identifier and the like. Therefore, it should be explicitly
understood
that the term "public network address" includes any suitable network address
of the VoIP phone 116.
For the purposes of a non-limiting example to be presented below, assume that
the location retrieving server 145 has received the IP address
151.200.56.101" associated with the VoIP phone 116.
18
CA 02548943 2006-05-08
T2006-059797-CA
Step 320: determine a location information database address
Next, the location retrieving server 145 determines a network address of the
location information database responsible for storing location information for
the VoIP phone 116.
In a particular non-limiting embodiment, the location retrieving server 145
accesses the address directory 147 to retrieve a record associated with the
service provider managing the network element 140A. Specifically, the
location retrieving server 145 determines which address range 212 contains
the public IP address of the VoIP phone 116 obtained at step 310.
In the specific non-limiting example being presented here, the location
retrieving server 145 attempts to locate a record that contains an address
range
212 which includes the IP address "151.200.56.101". The location retrieving
server 145 determines that record 202 associated with the service provider 210
"A" contains the address range 212, which includes the IP address
"151.200.56.101". The location retrieving server 145 then extracts the content
of the location information database address 214, which in this example
contains the URL "https://lis.a-isp.net".
Accordingly, the location retrieving server 145 has determined the network
address associated with the location information database 150A which
maintains the emergency address for the VoIP phone 116.
Step 325: transmit an emergency address request to the location information
database
150A
Next, the location retrieving server 145 transmits an emergency address
request to the location information database 150A at the network address
determined at step 320 (i.e. https://lis.a-isp.net). As will be appreciated by
those skilled in the art, a DNS query may be performed in some embodiments
of the present invention in order to determine an IP address corresponding to
the URL obtained in step 320. In some non-limiting embodiments of the
19
CA 02548943 2006-05-08
T2006-059797-CA
present invention, the location retrieving server 145 can transmit the
emergency address request using an HTTP enabled location delivery (HELD)
with OBO extensions protocol, available from http://www.ietf.org/internet-
drafts/draft-winterbottom-http-location-delivery-02.txt. In an alternative non-
limiting embodiment of the present invention, the emergency address request
can be transmitted using a SIMPLE protocol (SIP IM with Presence
Leveraging Extensions), available from http://www.ietf.org/internet-
drafts/draft-ietf-simple-presence-data-model-07.txt. It should be noted that
in
some embodiments of the present invention, a proprietary protocol can be
used. One skilled in the art will appreciate that other suitable protocols can
also be used.
Irrespective of which protocol is used for transmitting the emergency address
request, the emergency address request contains the public network address of
the VoIP phone 116 obtained at step 310.
Step 330: receive the emergency address from the location information database
150A
Upon receipt of the emergency address request, the location information
database 150A performs a look up based on the public network address of the
VoIP phone 116 received as part of the emergency address request.
In an event that the location information database 150A fails to locate a
record
associated with the public network address received as part of the emergency
address request, the location information database 150A can execute an
exception handling routine, such as but not limited to transmitting an error
message to the location retrieving server 145 indicative of the fact that the
emergency address for the VoIP phone 116 is not available. If, on the other
hand, the location information database 150A successfully locates a record
associated with the public network address received as part of the emergency
address request, the location information database 150A transmits the
associated emergency address back to the location retrieving server 145. In
some non-limiting embodiments of the present invention, the location
information database 150A can transmit the emergency address by-value
CA 02548943 2006-05-08
T2006-059797-CA
(referred to as "The Presence Information Data Format Location Object" or
simply PIDF-LO). In alternative non-limiting embodiments, the location
information database 150A can transmit the emergency address by reference
(referred to as Universal Resource Identifier or simply "URI").
In this manner, the location retrieving server 145 becomes aware of the
emergency address associated with the VoIP phone 116.
It should be noted that in some non-limiting embodiments of the present
invention, the location information database 150A can transniit the emergency
address to another entity, such as but not limited to the network element
140A.
Step 340: release the emergenoy address
Next, the location retrieving server 145 releases the emergency address.
Several non-limiting embodiments for how the location retrieving server 145
releases the emergency address are contemplated:
Releasing the emergency address to the network element 140A
In a first non-limiting embodiment of the present invention, the location
retrieving server 145 releases the emergency address to the network element
140A. Specifically, the location retrieving server 145 can generate a SIP
invite
message directed to the network element 140A and insert an indication of the
emergency address into one or more fields of the SIP invite message.
In a particular non-limiting embodiment, the location retrieving server 145
can
insert the indication of the emergency address into the SIP invite message
using a SIP Location conveyance protocol available from
http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-02.txt.
Upon receipt of the SIP invite message, the network element 140A becomes
aware of the emergency address associated with the VoIP phone 116 and can
handle the emergency call from the VoIP phone 116 accordingly, as
prescribed by the aforementioned NENA i2 standard, for example. These steps
21
CA 02548943 2006-05-08
T2006-059797-CA
are known to those skilled in the art and, therefore, only a non-limiting
example is provided herein below for purposes of illustration only.
For example, the network element 140A can transmit a query containing the
emergency address to a VoIP positioning center (VPC), which is not depicted
on Fig.l for the sake of simplicity, in order to retrieve emergency call
routing
instructions from the VPC.
Based on the emergency address, the VPC can query an Emergency Routing
Data Base (ERDB, not shown) for routing information relating to the
emergency call. In an example, the routing information may be in the form of
an emergency services query key (ESQK) and an emergency services routing
number (ESRN), which are returned to the network element 140A. In
addition, the ESQK is pushed to an ALI database (not depicted) in the
emergency services entity 160. It should be noted that in some non-limiting
embodiments, the ESQK may have been provisioned in the ALI prior to the
emergency call being placed. Meanwhile, the VPC stores the ESQK and the
aforementioned emergency address along with the callback number of the
VoIP phone 116.
Upon receipt of the ESQK and the ESRN from the VPC, network element
140A routes the emergency call based on the ESRN as the routing path
identifier and uses the ESQK as the calling number going to an Emergency
Services Gateway (not depicted) in the emergency services entity 160. The
emergency call with the ESQK is then routed to a PSAP via an appropriate
PSTN selective router (not shown). At the PSAP, an operator queries the ALI
database with the ESQK. In turn, the ALI database queries the VPC with the
ESQK to obtain the location object that had been stored by the VPC in
association with that ESQK. In this way, the PSAP operator learns the
physical location of the VoIP phone 116 from which the emergency call was
originated. In an alternative non-limiting embodiment, rather than having the
operator querying the ALI, the Emergency Services Gateway can send a
22
CA 02548943 2006-05-08
T2006-059797-CA
message containing the ESQK to the ALI, which in turn will send the
emergency address to the PSAP.
Acting asa proxy to the network element 140A
In a second non-limiting embodiment of the present invention, the location
retrieving server 145 can act as a SIP proxy to the network element 140A for
the purposes of handling the emergency call from the VoIP phone 116.
Specifically, the location retrieving server 145 can transmit a query
containing
the emergency address to the aforementioned VoIP positioning center (VPC)
in order to retrieve emergency call routing instructions from the VPC.
Equipped with the routing instructions provided by the VPC, the location
retrieving server 145 can dispose of the emergency call in accordance with the
routing instructions, as described immediately above.
Acting as a redirect server for the network element 140A
In a third non-limiting embodiment of the present invention, the location
retrieving server 145 can act as a redirect server for the network element
140A
for the purposes of handling the emergency call from the VoIP phone 116.
Specifically, the location retrieving server 145 can transmit a query
containing
the emergency address to the aforementioned VoIP positioning center (VPC)
in order to retrieve emergency call routing instructions from the VPC.
Equipped with the routing instructions provided by the VPC, the location
retrieving server 145 can transmit the routing instructions back to the
network
element 140A to enable the network element 140A to handle the emergency
call in accordance with the routing instructions. In a specific non-limiting
example, the location retrieving server 145 can send a SIP redirect message to
the network element 140A, the SIP redirect message containing the ESQK and
the ESRN.
Releasing the emer eg_ncy address to the VoIP phone 116
In some non-limiting embodiments and as an enhancement, the location
retrieving server 145 can also forward a copy of the indication of the
emergency address to the VoIP phone 116 for storage thereon. In some non-
23
CA 02548943 2006-05-08
T2006-059797-CA
limiting embodiments of the present invention, the VoIP phone 116 can store
the emergency address and forward the emergency address to the network
element 140A, for example, during establishment of a future emergency call.
Given steps 310 - 340 described above, the location retrieving server 145 has
conveniently obtained the emergency address associated with the VoIP phone 116
from the location information server 150A on behalf of the VoIP phone 116 and
the
network element 140A.
Now consider a scenario, whereby the user of the VoIP phone 116 has moved the
VoIP phone 116. For example, the user of the VoIP phone 116 may have connected
the VoIP phone 116 in a hotel room in another city. Today, high speed access
(wired
or wireless) is commonly available in most hotels and is offered to hotel
guests either
at an additional charge or as included in the hotel room price. When accessing
the
core packet-switched data network 132 from the hotel room, the VoIP phone 116
may
be accessing the core packet-switched data network 132 via an access data
network
which is different from the access data network 132. For example, the VoIP
phone
116 may be accessing the core packet-switched data network 132 via an access
data
network associated with a service provider "B" which manages the network
element
140B and maintains the location information database 150B.
In this non-limiting scenario, when the VoIP phone 116 is connected to the
core
packet-switched data network 132, an emergency address associated with its
location
will be provisioned in the location information database 150B. The VoIP phone
116
will also be assigned an IP address from a range of IP addresses of the
service
provider "B". However, when an emergency call (or any other call) is
originated from
the VoIP phone 116 in this scenario, it will be routed via a "native network
element",
such as the network element 140A. In this scenario, by executing the method
described above, the location retrieving server 145 is able to retrieve the
emergency
address from the location information database 150B on behalf of the VoIP
phone 116
to enable emergency call handling, even though the VoIP phone 116, which is
location-unaware, accesses the core packet-switched data network 132 via a
different
access data network and even though the emergency address is stored in the
location
24
CA 02548943 2006-05-08
T2006-059797-CA
information database 150B managed by a different service provider from the
service
provider managing the network element 140A.
An alternative non-limiting embodiment of the infrastructure of Fig. 1 is
depicted in
Fig. 4. The infrastructure depicted in Fig. 4 is substantially similar to the
infrastructure of Fig. 1, but for the specific differences described below.
The infrastructure of Fig. 4 comprises network elements associated with a
single
service provider, such as the network element 140A-1 and the location
information
database 150A-1. Naturally, the infrastructure of Fig. 4 can comprise a
plurality of
other network elements managed by the single service provider, such as a
geographically dispersed or "redundant" network element (not depicted). In
this non-
limiting embodiment, the need for the address directory 147 can be eliminated.
Of
course, the address directory 147 can be maintained, for example, where the
service
provider maintains more than one location information database 150A-1. In that
case,
the address directory 147 can map a sub-set of IP addresses to the network
address of
the respective location information database.
Given the infrastructure of Fig. 4, the location retrieving server 145 can
execute a
method for retrieving an emergency address on behalf of a location-unaware
device
according to another non-limiting embodiment of the present invention. With
reference to Fig. 5 the method for retrieving an emergency address on behalf
of a
location-unaware device is now described in greater detail.
Step 510: receive an indication of a public network address
The method begins at step 510, where the location retrieving server 145
receives the indication of the public network address from the network
element 140A-1 in response to the network element 140A-1 detecting an
emergency call originating from the VoIP phone 116.
Step 510 can be implemented in substantially the same manner as described
above in respect to step 310.
CA 02548943 2006-05-08
T2006-059797-CA
Step 515: transmit an emerizency address rec~uest to the location information
database
150A-1
At this step, the location retrieving server 145 transmits the emergency
address
request to the location information database 150A-1. In these non-limiting
embodiments, a network address associated with the location information
database 150A-1 can be known to the location retrieving server 145.
How the location retrieving server 145 transmits the emergency address
request can be executed in substantially the same manner as described above
in reference to step 325.
Step 520: receive the emergency address from the location information database
150A-1
Next, the location retrieving server 145 receives the emergency address
associated with the VoIP phone 116 from the location information database
150A-1.
How the location retrieving server 145 receives the emergency address from
the location information database 150A-1 can be implemented in substantially
the same manner as described above in association with step 330.
Step 530: release the emergency address
Next, the location retrieving server 145 releases the emergency address.
Several non-limiting embodiments for how the location retrieving server 145
releases the emergency address are contemplated and these embodiments can
be substantially similar to the embodiments contemplated for the step 340
described above.
Effectively, in this non-limiting alternative embodiment of the method for
retrieving
the emergency address on behalf of a location-unaware device, the location
retrieving
server 145 can retrieve an emergency address on behalf of a location-unaware
device
(ex. the VoIP phone 116) used by subscribers to VoIP telephony service of a
single
26
CA 02548943 2006-05-08
T2006-059797-CA
service provider, i.e. the service provider, which in these embodiments,
manages the
network element 140-1 and maintains the location information database 150A-1.
In an alternative embodiment of the present invention, when the location
information
database 150A receives an emergency address request from the location
retrieving
server 145, the location information database 150A performs a look up and
retrieves
the emergency address associated with a network address contained in the
emergency
address request. The location information database 150A can then transmit the
emergency address directly to the network element 140A. In an alternative non-
limiting embodiment of the present invention, the location information
database 150A
can also transmit the emergency address to the VoIP 116.
In some non-limiting embodiments of the present invention, the functionality
of the
location retrieving server 145 can be integrated with the functionality of the
network
element 140A (or the network element 140B) into a single device.
Even though the foregoing description has been presented using an example of
retrieving an emergency address on behalf of a location-unaware device in a
packet-
switched environment, one skilled in the art will appreciate that teachings of
the
embodiments of this invention can be applied for retrieving other types of
location
information on behalf of location-unaware devices, such as service addresses
and the
like. Generally speaking, the teachings of the embodiments of the present
invention
can be applied for retrieving location information for the purposes of
delivering SIP-
based services (such as voice calls over packet-switched networks, instant
messaging
and the like) or location information for the purposes of services delivered
to
endpoints in a packet-switched network in general.
Those skilled in the art will appreciate that certain functionality of the NAS
126, the
location information databases 150A, 150B, the location retrieving server 145
and/or
other elements of the infrastructure described herein may be implemented as
pre-
programmed hardware or firmware elements (e.g., application specific
integrated
circuits (ASICs), electrically erasable programmable read-only memories
(EEPROMs), etc.), or other related components. In other embodiments, certain
27
CA 02548943 2006-05-08
T2006-059797-CA
portions of the NAS 126, the location information databases 150A, 150B, the
location
retrieving server 145 and/or other elements may be implemented as an
arithmetic and
logic unit (ALU) having access to a code memory (not shown) which stores
program
instructions for the operation of the ALU. The program instructions could be
stored
on a medium which is fixed, tangible and readable directly by the NAS 126, the
location information databases 150A, 150B, the location retrieving server 145
and/or
other elements, (e.g., removable diskette, CD-ROM, ROM, fixed disk, USB
drive), or
the program instructions could be stored remotely but transmittable to the NAS
126,
the location information databases 150A, 150B, the location retrieving server
145
and/or other elements via a modem or other interface device.
While specific embodiments of the present invention have been described and
illustrated, it will be apparent to those skilled in the art that numerous
modifications
and variations can be made without departing from the scope of the invention
as
defined in the appended claims.
28
