Note: Descriptions are shown in the official language in which they were submitted.
CA 02540276 2006-03-20
86503-131 and -132
1 METHOD FOR POPULATING A LOCATION INFORMATION DATABASE
2 USED IN THE DELIVERY OF EMERGENCY AND OTHER LOCATION-
3 BASED SERVICES IN A VOIP ENVIRONMENT
4
6 FIELD OF THE INVENTION
7
8 The present invention relates generally to VoIP communications and, in
particular, to
9 a method for populating a location information database used in the
delivery of
location-based services, such as emergency services, to users of VoIP devices.
11
12 BACKGROUND OF THE INVENTION
13
14 One of the underpinnings of location-based services such as emergency
services is the
ability to determine the physical location from which a call has been made.
For
16 example, when an emergency call is made in the public switched telephone
network
17 (PSTN) using a plain old telephony service (POTS) phone, the emergency
call sent
18 through the PSTN specifies the directory number of the POTS phone. Due
to the way
19 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
21 maintained in an ALI database made available to PSAP operators. Thus,
upon
22 handling an emergency call specifying a given directory number, a PSAP
operator
23 who queries the ALT database using the given directory number will learn
the address
24 from which the emergency call was placed and, consequently, to which an
emergency
crew needs to be dispatched.
26
27 As voice-over-internet-protocol (VoIP) becomes the predominant
technology used in
28 the telecommunications industry, customers using VoIP devices
(hereinafter "VoIP
29 customers") will expect emergency services to be delivered when
emergency calls are
originated from such devices over a broadband network. However, some broadband
31 service providers' networks are not natively compatible with the
existing emergency
32 infrastructure described above. In order to allow the delivery of
emergency services
33 to VoIP customers in a broadband network, the National Emergency
Numbering
34 Association (NENA) has proposed various architectures that can interface
with the
1
CA 02540276 2012-02-21
86503-131 and -132
1 existing emergency infrastructure, thereby allowing existing PSAPs to
handle emergency
2 calls placed by VoIP customers.
3
4 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
6 location of the VoIP device from which an emergency call is originated.
Specifically,
7 because telephone numbers assigned to VoIP devices are not necessarily
associated with a
8 fixed address or location, the availability of the directory number of
the VoIP device is not
9 sufficient to allow the physical location of the VoIP device to be
determined. This problem
also prevents service providers from offering other location-based services to
their VoIP
11 customers.
12
13 In order to resolve the above issue in the emergency services context,
NENA has proposed a
14 so-called "i2" architecture, which provides a network element known as a
location
information server (US) that serves as a repository for location information.
The US is
16 configured with a mapping between, on the one hand, location information
elements (in the
17 form of civic addresses or geo-spatial location attributes) and, on the
other, logical
18 representations of the respective physical locations with which the
location information
19 elements are associated.
21 Using the LIS, VoIP devices will be able to receive information on their
own physical
22 locations so that this information is conveyed during an emergency call.
Alternatively, a
23 VoIP device may be assigned a unique key that is used as an index to the
US, which key is
24 conveyed during an emergency call and can be used to consult the US for
the purposes of
obtaining the physical location of the VoIP device.
26
27 However, one significant omission from NENA's proposed i2 architecture
is any description
28 of how to populate the US with accurate information. In fact, document
NENA 08-001,
29 Issue 1, December 6, 2005, entitled "Interim VoIP Architecture for
Enhanced 9-1-1 Services
(i2)" plainly states that "How the IP network actually determines the location
and the
31 protocol between the US and IP device is outside the scope of this
document". Thus, there
2
CA 02540276 2012-02-21
86503-131 and -132
1 remains a need for a solution to the problem of determining a VoIP
device's location, in
2 order to enable the LIS to be populated.
2a
CA 02540276 2006-03-20
86503-131 and -132
1
2 SUMMARY OF THE INVENTION
3
4 The present invention provides a solution to the problem of determining a
VoIP
device's location, in order to allow VoIP customers to benefit from emergency
6 services and other location-based services.
7
8 A first broad aspect of the present invention seeks to provide a method
of populating a
9 location information database for use in providing a location-based
service to a host
device that is an endpoint of a logical connection between the host device and
a
11 network access server. The method comprises receiving from the host
device over the
12 logical connection a request for network access; assigning a logical
identifier to the
13 host device in response to the receiving; determining a physical
location associated
14 with the endpoint of the logical connection; creating an association
between the
logical identifier and the physical location; and storing the association in
the location
16 information database.
17
18 A second broad aspect of the present invention seeks to provide a method of
19 populating a location information database for use in providing a
location-based
service to a host device that is an endpoint of a logical connection between
the host
21 device and a network access server. The method comprises receiving from
the host
22 device over the logical connection a request for network access;
assigning a logical
23 identifier to the host device in response to the receiving; and
providing the logical
24 identifier to a computing apparatus capable of: (i) determining a
physical location
associated with the endpoint of the logical connection; (ii) creating an
association
26 between the logical identifier and the physical location; and (iii)
storing the
27 association.
28
29 A third broad aspect of the present invention seeks to provide a method
of populating
a location information database for use in providing a location-based service.
The
31 method comprises receiving a logical identifier assigned to a host
device in response
32 to receiving a request for network access from the host device over a
logical
33 connection having a first endpoint that is the host device and a second
endpoint that is
3
CA 02540276 2006-03-20
86503-131 and -132
1 a network access server; determining a physical location associated with
the endpoint
2 of the logical connection; creating an association between the logical
identifier and
3 the physical location; and storing the association in the location
information database.
4
A fourth broad aspect of the present invention seeks to provide a system for
6 populating a location information database for use in providing a
location-based
7 service to a host device that is an endpoint of a logical connection
between the host
8 device and a network access server. The system comprises first means for
receiving
9 from the host device over the logical connection a request for network
access; second
means for assigning a logical identifier to the host device in response to the
receiving;
11 third means for determining a physical location associated with the
endpoint of the
12 logical connection; fourth means for creating an association between the
logical
13 identifier and the physical location; and fifth means for storing the
association in the
14 location information database.
16 These and other aspects and features of the present invention will now
become
17 apparent to those of ordinary skill in the art upon review of the
following description
18 of specific embodiments of the invention in conjunction with the
accompanying
19 drawings.
21 BRIEF DESCRIPTION OF THE DRAWINGS
22
23 In the drawings:
24
Fig. 1 is a diagrammatic representation of an infrastructure for the delivery
of
26 location-based services to a host device in a VoIP environment, in
accordance with an
27 example non-limiting embodiment of the present invention.
28
29 Fig. 2 shows an event flow upon activation of the host device.
31 Fig. 3 shows creation of an association between a physical location of
the host device
32 and a logical identifier assigned to the host device.
33
34 Fig. 4 shows origination and flow of an emergency call.
4
CA 02540276 2006-03-20
86503-131 and -132
1
2 Fig. 5 shows origination and flow of a customer service call.
3
4 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
6 understanding. They are not intended to be a definition of the limits of
the invention.
7
8 DETAILED DESCRIPTION OF EMBODIMENTS
9
Fig. 1 shows various components of an infrastructure for delivering location-
based
11 services, including emergency services, to a VoIP device, in accordance
with an
12 example non-limiting embodiment of the present invention. The
infrastructure
13 comprises a VoIP device (hereinafter "host device" 102) connected to a
port 104 of an
14 access multiplexer 106 via a physical communication link 108. In an
example non-
limiting embodiment, the host device 102 may comprise a broadband modem 110
16 connected to a router 112 over a home network 114. The router 112 may in
turn be
17 connected over the home network 114 to a VoIP phone 116 or,
alternatively, to a
18 POTS phone 118 via an analog terminal adapter (ATA) 120. In an example
non-
19 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
21 alternative embodiment, the physical communication link 108 might not a
copper pair,
22 but instead may comprise an Ethernet link, a fiber optic link (e.g.,
FTTH, FTTC), a
23 fixed wireless link, a coax cable, etc., or a combination thereof.
24
The infrastructure of Fig. 1 further comprises an operation support system
(OSS) 122.
26 The OSS 122 generally represents a collection of systems that perform
management,
27 inventory, engineering, planning, and repair functions for the broadband
service
28 provider. In this light, one of the functions of the OSS 122 may include
management
29 of network elements, assets and equipment. Thus, the OSS 122 maintains a
mapping
124 between, on the one hand, the ports of various access multiplexers under
control
31 of the broadband service provider and, on the other, location objects
indicative of the
32 respective physical locations of the host devices connected to those
ports. In the
33 specific case under consideration here, the mapping 124 maintained by
the OSS 122
34 relates port 104 of the access multiplexer 106 to a location object
indicative of the
5
CA 02540276 2006-03-20
86503-131 and -132
1 physical location of the host device 102. The location object may be
expressed as a
2 civic address or a set of geo-spatial coordinates (e.g.,
latitude/longitude).
3
4 The access multiplexer 106, which in an example non-limiting embodiment
can be a
digital subscriber line access multiplexer (DSLAM), is connected to a network
access
6 server (NAS) 126, which may also be referred to by some in the industry as a
7 broadband remote access server (BRAS), a remote access server (RAS) or a
8 broadband access server (BAS). The NAS 126 provides access to a core packet-
9 switched data network 128, such as the Internet, over which VoIP calls
can be
established. In an example non-limiting embodiment, communication between the
11 access multiplexer 106 and the NAS 126 may take place over a dedicated
logical link
12 130 between the access multiplexer 106 and the NAS 126. The dedicated
logical link
13 130 traverses an intervening access data network 132. In an example non-
limiting
14 embodiment, the dedicated logical link 130 can be implemented as an
asynchronous
transfer mode (ATM) permanent virtual circuit (PVC). In another example non-
16 limiting embodiment, the dedicated logical link 130 can be implemented
as a virtual
17 local area network (VLAN). Still other implementations of the dedicated
logical link
18 130 are within the scope of the present invention.
19
The functionality of the access multiplexer 106 is to allow data arriving from
the NAS
21 126 along given ATM PVCs or VLANs to be sent over corresponding physical
22 communication links via corresponding one of its ports, and vice versa.
Thus, one can
23 say that the access multiplexer implements a mapping 134 between, on the
one hand,
24 dedicated logical links and, on the other, ports of the access
multiplexer 106. In the
specific case under consideration here, the mapping 134 implemented by the
access
26 multiplexer 106 relates the dedicated logical link 130 to port 104 of
the access
27 multiplexer 106. In two example non-limiting embodiments, the mapping
134 can be
28 maintained by either the access multiplexer 106 or the OSS 122.
29
The infrastructure of Fig. 1 further comprises an authorization entity 142
connected to
31 the NAS 126. The nature of the connection between the NAS 126 and the
32 authorization entity 142 is immaterial. In an example non-limiting
embodiment, the
33 authorization entity 142 can be a server (e.g., an AAA server)
responsive to queries
34 from the NAS 126. In such an embodiment, the authorization entity 142
and the NAS
6
CA 02540276 2012-02-21
86503-131 and -132
1 126 may communicate using the so-called "Remote Authentication Dial In
User Service"
2 (RADIUS) protocol, a description of which is available at
www.ietf.org/rfc/rfc2865.txt. In
3 another example non-limiting embodiment, the authorization entity 142 can
be a functional
4 element integrated with the NAS 126.
6 Also provided in the infrastructure of Fig. 1 is a location information
database 136, which
7 can be implemented as a computing apparatus. In some embodiments, the
location
8 information database 136 can be connected to the NAS 126 by a link 12,
while in other
9 embodiments, the location information database 136 can be connected to
the authorization
entity 142 by a link 14. The nature of the connection between the location
information
11 database 136 and either the NAS 126 or the authorization entity 142 is
immaterial. In other
12 embodiments, the location information database 136 may be integrated
with either the OSS
13 122, the NAS 126 or the authorization entity 142. In yet other
embodiments, the location
14 information database 136 may be distributed amongst a plurality of
functional elements
and/or physical locations. It should be further appreciated that the location
information
16 database 136 can be managed, maintained and/or updated by an entity that
may be the same
17 entity as, or a different entity from, the entity that is responsible
for providing the host device
18 102 with access to the core packet-switched data network 128.
19
In an example non-limiting embodiment, the location information database 136
can be
21 implemented as a location information server (LIS) described in the
document NENA 08-
22 001, Issue 1, December 6, 2005, entitled "Interim VoIP Architecture for
Enhanced 9-1-1
23 Services (i2)". To this end, the location information database 136 may
comprise a plurality
24 of records 140, each record 140 mapping a location object to a logical
identifier. In an
example non-limiting embodiment, the location object can be expressed as a
civic address or
26 a set of geo-spatial coordinates (e.g., latitude/longitude) indicative
of a physical location. In
27 various example non-limiting embodiments, the logical identifier may be
an IP address in
28 compliance with, e.g., IPv4 or IPv6, or a proprietary address, label or
tag.
29
In an example non-limiting embodiment, the NAS 126 may be operative to
maintain a pool
31 127 of pre-allocated logical identifiers that can be used by various
host devices, including the
7
CA 02540276 2012-02-21
86503-131 and -132
1 host device 102. In an example non-limiting embodiment, the pool 127 of
logical identifiers
2 may be built up as a cooperative effort between the NAS 126 and the OSS
122, while in
3 other embodiments, it is not necessary for the OSS 122 to be involved in
creating the pool
4 127 of logical identifiers. In still other embodiments, the pool 127 of
logical identifiers may
be maintained by the authorization entity 142, and can be made accessible to
the
6 authorization entity 142 without needing to pass through the NAS 126.
7
8 Of course, it will be apparent to those skilled in the art that numerous
modifications and
9 variations of the infrastructure of Fig. 1 are possible. For example, in
an alternative
embodiment, the access multiplexer 106 can be omitted. This is especially true
in the case
11 where the host device 102 implements a wireless access point. In an
example non-limiting
12 embodiment of this scenario, the connection between the wireless access
point and the NAS
13 126 can be provided by a dedicated point-to-point link.
14
Reference is now made to Fig. 2, which illustrates an event flow upon
activation of the host
16 device 102, which may occur as the modem 110 in the host device 102 is
powered up.
17 Thereafter:
18
19 - The host device 102 establishes physical layer connectivity with the
access multiplexer 106
over the physical communication link 108.
21
22 - This is followed by the establishment of Ethernet connectivity between
the host device 102
23 and the access multiplexer 106.
24
- The host device 102 verifies its ability to communicate using Point-to-Point
Protocol over
26 Ethernet (PPPoE). For a more detailed explanation of PPPoE, the reader
is referred to
27 Internet Request For Comments (RFC) 2516, available from the Internet
Engineering Task
28 Force (http://www.ietforg).
8
CA 02540276 2012-02-21
86503-131 and -132
1 - Next, assuming that the host device 102 has the ability to communicate
using PPPoE, the
2 host device 102 verifies whether it should make a so-called "access
request" automatically
3 or in response to user input (which can be obtained via a
8a
CA 02540276 2006-03-20
86503-131 and -132
1 software application). For the purposes of this example, let it be
assumed that
2 conditions have been met such that the host device 102 should make an
access
3 request.
4
- The host device begins entry into PPPoE communication by broadcasting an
6 "initiation" packet over the dedicated logical link 130.
7
8 - The NAS 126 responds to receipt of the initiation packet by sending
an "offer"
9 packet to the host device 102. Thus, at this stage, it can be said that a
logical
connection 202 has been defined between a first endpoint (the host device 102)
11 and a second endpoint (the NAS 126).
12
13 - Following receipt of the offer packet, the host device 102 sends an
access request
14 208 to the NAS 126 with the ultimate goal of accessing the core packet-
switched
data network 128 (e.g., for the purpose of making and receiving VoIP calls).
In an
16 example non-limiting embodiment, the access request 208 may comprise
17 credentials 216 that can be hard coded or programmably installed on the
host
18 device 102. Alternatively, the credentials 216 may be entered by a user
of the host
19 device 102.
21 - Upon receipt of the access request 208 containing the credentials 216
along the
22 dedicated logical link 130, the NAS 126 executes an authorization
procedure as
23 follows. The NAS 126 communicates the credentials 216 to the
authorization
24 entity 142, e.g., in the form of a RADIUS Access-Request message 218. In
response to receipt of the credentials 216 from the NAS 126, the authorization
26 entity 142 determines whether the credentials 216 allow access to the
core packet-
27 switched data network 128. In a non-limiting example embodiment, this
can be
28 determined by consulting a database (not shown). If the credentials 216
allow
29 access to the core packet-switched data network 128, the authorization
entity 142
returns an acceptance message (e.g., a RADIUS Access-Accept message). On the
31 other hand, if the credentials 216 do not allow access to the core
packet-switched
32 data network 128, the authorization entity 142 returns a refusal message
(e.g., a
33 RADIUS Access-Reject message). Assume that the credentials 216 allow
access
9
CA 02540276 2006-03-20
86503-131 and -132
1 to the
core packet-switched data network 128, resulting in issuance of an
2 acceptance message 214. Two alternatives are possible:
3
4 -
Alternative 1 (where the pool 127 of logical identifiers is maintained by the
authorization entity 142): the authorization entity 142 obtains a logical
6
identifier 210 from the pool 127 of logical identifiers that is maintained by
the
7
authorization entity 142. The logical identifier is sent to the NAS 126, which
8 assigns the logical identifier 210 to the dedicated logical link 130.
9
- Alternative 2 (where the pool 127 of logical identifiers maintained by the
NAS
11 126):
responsive to receipt of the acceptance message from the authorization
12 entity
142, the NAS 126 obtains a logical identifier 210 from the pool 127 of
13 logical
identifiers that is maintained by the NAS 126. The logical identifier
14 210 so obtained is assigned by the NAS 126 to the dedicated logical
link 130.
16 - The
NAS 126 sends a "confirmation" packet back to the host device 102, thus
17
completing the establishment of a PPPoE session between the endpoints of the
18 logical connection 202.
19
- Additional hand-shaking may be performed between the host device 102 and the
21 NAS 126
in order to establish a Point-to-Point Protocol (PPP) session between the
22 endpoints of the logical connection 202.
23
24 -
Following this, further hand-shaking may be undertaken between the host device
102 and the NAS 126 in order to establish an Internet Protocol Control
Protocol
26 (IPCP) session between the endpoints of the logical connection 202.
27
28 -
During the IPCP session, the NAS 126 releases the logical identifier 210
towards
29 the
host device 102 that issued the access request 208, in order to allow the host
device 102 to identify itself using the logical identifier in future
communications
31 over
the dedicated logical link 130. For the purposes of the present example, let
it
32 be
assumed that the logical identifier 210 assigned to the dedicated logical link
33 130 is an IP address, e.g., "208.106.88.104" or any other conceivable IP
address.
34
CA 02540276 2006-03-20
86503-131 and -132
1 It is recalled from the above that once the logical identifier 210 has
been obtained
2 from the pool 127 of logical identifiers (either by the NAS 126 or by the
authorization
3 entity 142), the NAS 126 assigns the logical identifier 210 to the
dedicated logical
4 link 130.
6 In a first implementation, namely where the location information database
136 is
7 connected to the NAS 126 by the link 12, the fact that the NAS assigns
the logical
8 identifier 210 to the dedicated logical link 130 allows the NAS 126 to
construct and
9 maintain a mapping 212 between, on the one hand, various dedicated
logical links
(such as the dedicated logical link 130 and others) and, on the other, logical
identifiers
11 corresponding to those dedicated logical links.
12
13 In a second implementation, namely where the location information
database 136 is
14 connected to the authorization entity 142 by the link 14, the logical
identifier 210 and
the identity of the dedicated logical link 130 to which it is assigned are
sent back by
16 the NAS 126 to the authorization entity 142, and it is the authorization
entity 142 that
17 maintains the aforementioned mapping 212 between dedicated logical links
and
18 logical identifiers corresponding to those dedicated logical links.
19
Of course, those skilled in the art will be able to think of other ways of
causing the
21 host device 102 to send the access request 208 over the logical
connection 202
22 between the host device 102 and the NAS 126, as well as other ways of
assigning a
23 logical identifier to the dedicated logical link 130, and such other
ways should be
24 considered as being within the scope of the present invention. It should
further be
mentioned that the establishment of the aforementioned PPPoE, PPP and/or IPCP
26 sessions is not a requirement of the present invention. This is
particularly the case
27 where the dedicated logical link 130 is a VLAN.
28
29 In view of the preceding description, and in particular given the
previously described
mappings 124, 134 maintained in the OSS 122 and/or the access multiplexer 106
and
31 the mapping 212 maintained in the NAS 126 or the authorization entity
142, the
32 following describes how one can create an association between logical
identifiers
33 (such as IP addresses) and respective location objects each indicative
of a physical
34 location.
11
CA 02540276 2006-03-20
86503-131 and -132
1
2 Specifically, with reference to Fig. 3, by combining the mapping 124 with
the
3 mapping 134, the OSS 122 can create an intermediate mapping (denoted 302)
4 between, on the one hand, dedicated logical links and, on the other hand,
location
objects indicative of respective physical locations of host devices having
logical
6 connections with the NAS 126 which traverse those dedicated logical
links. In the
7 specific example being considered here, the intermediate mapping 302 would
8 associate the dedicated logical link 130 to the physical location of the
host device 102.
9 In an example non-limiting embodiment, the OSS 122 transmits the
intermediate
mapping 302 to the location information database 136.
11
12 Next, the location information database 136 can be operative to combine the
13 intermediate mapping 302 (received from the OSS 122) with the previously
described
14 mapping 212 (received from the NAS 126 or the authorization entity 142),
thus
creating a final mapping 304 between, on the one hand, logical identifiers
(such as IP
16 addresses) and, on the other, location objects indicative of the
respective physical
17 locations of host devices having logical connections with the NAS 126
which traverse
18 respective dedicated logical links to which those logical identifiers
have been
19 assigned. In the specific example being considered here, the final
mapping 304 would
specify that IP address 208.106.88.104 corresponds to the physical location of
the host
21 device 102. This is precisely the type of association that is useful to
have stored in the
22 location information database 136.
23
24 In an alternative embodiment, the OSS 122 can forward the mapping 124 and
the
mapping 134 to the location information database 136. In this alternative
26 embodiment, the location information database 136 can be responsible for
creating the
27 intermediate mapping 302. In yet further embodiments, the OSS 122 can
forward the
28 mapping 124 and the mapping 134 to an intermediate computing apparatus
that can be
29 responsible for creating the intermediate mapping 302 and for forwarding
the
intermediate mapping 302 to the location information database 136.
31
32 From the above, it should be apparent that the location information
database 136 can
33 be
populated with logical identifiers (such as IP addresses) and corresponding
location
12
CA 02540276 2012-02-21
86503-131 and -132
1 objects indicative of respective physical locations associated with those
logical identifiers.
2
3 Emergency Services
4
One non-limiting example of the usefulness of the information stored in the
records 140 of
6 the location information database 136 is in the context of emergency
services. In what
7 follows, only a cursory overview of an emergency call flow will be
provided, as a person
8 skilled in the art will recognize that additional information can be
obtained from document
9 NENA 08-001, Issue 1, December 6, 2005, entitled "Interim VoIP
Architecture for Enhanced
9-1-1 Services (i2)".
11
12 With reference to Fig. 4, there is provided a call server 402, a VoIP
positioning center (VPC)
13 404 and an emergency services provider network 406. The call server 402
is reachable via
14 the core packet-switched data network 128. In an example non-limiting
embodiment, the call
server 402 is embodied as a MCS 5200 Soft Switch manufactured by Nortel
Networks Ltd.
16 of 8200 Dixie Road, Brampton, Ontario L6T 5P6, Canada. Generally
speaking, the call
17 server 402 provides communication services and features for (i)
connecting incoming calls to
18 the host device 102 and (ii) handling outgoing calls originated from the
host device 102. In
19 the case of an emergency call received at the call server 402, the call
server 402 is operable
to obtain call-related information and to route the emergency call together
with the call-
21 related information towards an emergency services gateway (ESGW) 408 in
the emergency
22 services provider network 406 via an interface 410.
23
24 Consider now an emergency call being originated from the host device
102. The emergency
call comprises a call initiation portion 412 and ancillary information 414.
26
27 In a first implementation, the ancillary information 414 comprises a
location object indicative
28 of the physical location of the host device 102. It should be
appreciated that in such an
29 implementation, the location object comprised in the ancillary
information 414 may be
obtained by the host device 102 by virtue of direct interaction
13
CA 02540276 2006-03-20
86503-131 and -132
1 with the location information database 136 either before or during
origination of the
2 emergency call.
3
4 In a second implementation, the ancillary information 414 comprises a
logical
identifier (such as an IP address or proprietary identifier) associated with
the host
6 device 102. It is recalled that the logical identifier in question can be
received from
7 the NAS 126 as a consequence of the host device 102 having been
authorized to
8 access the core packet-switched data network 128. When the emergency call is
9 received at the call server 402, the call server 402 obtains call-related
information by
querying the VPC 404 on the basis of the ancillary information 414.
11
12 Specifically, the VPC 404 is a network element that conveys routing
information to
13 support the routing of VoIP emergency calls. The VPC 404 receives the
ancillary
14 information 414 from the call server 402 over an interface 416. If the
ancillary
information 414 is a logical identifier (i.e., in the second implementation
mentioned
16 above), the VPC 404 is operable to obtain the corresponding location
object from the
17 location information database 136. Accordingly, in this second
implementation, an
18 interface 418 is provided between the VPC 146 and the location
information database
19 136. The interface 418 is not required when the ancillary information
414 already
comprises the location object.
21
22 Based on the location object (either contained in the ancillary
information 414 or
23 obtained from the location information database 136), the VPC 404
queries an
24 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
26 emergency services query key (ESQK) and an emergency services routing
number
27 (ESRN), which are returned to the call server 402. In addition, the ESQK
is pushed to
28 an ALI database 420 in the emergency services provider network 406.
Meanwhile,
29 the VPC 404 stores the ESQK and the aforementioned location object along
with the
callback number of the host device 102.
31
32 Upon receipt of the ESQK and the ESRN from the VPC 404, the call server
402
33 routes the emergency call based on the ESRN as the routing path
identifier and uses
34 the ESQK as the calling number going to the ESGW 408. The emergency call
with
14
CA 02540276 2006-03-20
86503-131 and -132
1 the ESQK is then routed to a PSAP via an appropriate PSTN selective
router (not
2 shown). At the PSAP, an operator queries the ALI database 420 with the
ESQK. In
3 turn, the ALI database 420 queries the VPC 404 with the ESQK to obtain
the location
4 object that had been stored by the VPC 404 in association with that ESQK.
In this
way, the PSAP operator learns the physical location of the host device 102
from
6 which the emergency call was originated.
7
8 Non-Emergency Location-Based Services
9
Another non-limiting example of the usefulness of the information stored in
the
11 records 140 of the location information database 136 is in the context
of location-
12 based services other than emergency services. With reference to Fig. 5,
let a specific
13 non-limiting example location-based service be "customer service", which
is provided
14 by a customer service entity 502. The customer service entity 502
comprises a call
control portion 512 (for receiving the customer service call), a database 514
and a
16 location-based services entity (LBSE) 516.
17
18 Also provided in the infrastructure of Fig. 5 is a call server 530,
which is reachable
19 via the core packet-switched data network 128. The call server 530 provides
communication services and features for (i) connecting incoming calls to the
host
21 device 102 and (ii) handling outgoing calls originated from the host
device 102.
22
23 Consider now a customer services call being originated from the host
device 102. The
24 customer service call comprises a call initiation portion 518
(including, for example, a
directory number where the customer service entity 502 can be reached, as well
as a
26 call origination number at which the phone 116 or 118 can be reached)
and ancillary
27 information 520. The call initiation portion 518 causes the customer
service call
28 (including the ancillary information 520) to be routed to the customer
service entity
29 502. The ancillary information 520 is processed by the call control
portion 512 and
forwarded to the LBSE 516.
31
32 In a first implementation, the ancillary information 520 comprises a
location object
33 indicative of the physical location of the host device 102. It should be
appreciated
34 that in such an implementation, the location object comprised in the
ancillary
CA 02540276 2006-03-20
86503-131 and -132
1 information 520 may be obtained by the host device 102 by virtue of
direct interaction
2 with the location information database 136 either before or during
origination of the
3 customer service call.
4
In a second implementation, the ancillary information 520 comprises a logical
6 identifier (such as an IP address or proprietary identifier) associated
with the host
7 device 102. It is recalled that the logical identifier in question can be
received from
8 the NAS 126 as a consequence of the host device 102 having been
authorized to
9 access the core packet-switched data network 128. The LBSE 516 communicates
with the location information database 136 over a link 504, which can be
physical or
11 logical. Specifically, the LBSE 516 queries the location information
database 136
12 with the logical identifier in order to obtain the corresponding
location object stored in
13 the location information database 136. Due to the manner in which the
location
14 information database 136 is populated, the location object obtained by
the LBSE 516
will represent the location of the host device 102.
16
17 Assuming that the location of the host device 102 has been obtained, the
LBSE 516
18 can then automatically determine language preferences (e.g., French for
calls
19 originated from locations in the province of Quebec, Spanish for calls
originated from
locations in a certain neighborhood or country, etc.).
21
22 Alternatively or in addition, in a non-limiting example, the LBSE 516
can access a
23 user profile stored in a database 514 (based on, e.g., the
aforementioned call
24 origination number in the call initiation portion 518) and if the
address has changed,
verify with the user if the address in the user profile should be updated (for
billing
26 purposes, etc.).
27
28 Alternatively or in addition, in a non-limiting example, the LBSE 516
can access a
29 user profile stored in the database 514 (based on, e.g., the
aforementioned call
origination number in the call initiation portion 518) and retrieve current
promotions
31 applicable to the user's geographical location.
32
33 Alternatively or in addition, in a non-limiting example, the LBSE 516
can access a
34 user profile stored in the database 514 (based on, e.g., the
aforementioned call
16
CA 02540276 2006-03-20
86503-131 and -132
1 origination number in the call initiation portion 518) and retrieve data
representative
2 of services available in the user's geographical area to enable a
customer services
3 representative to more precisely target his or her up-sell pitch.
4
Those skilled in the art will appreciate that certain functionality of the NAS
126, the
6 location information database 136 and/or other elements of the
infrastructure
7 described herein may be implemented as pre-programmed hardware or firmware
8 elements (e.g., application specific integrated circuits (ASICs),
electrically erasable
9 programmable read-only memories (EEPROMs), etc.), or other related
components.
In other embodiments, certain portions of the NAS 126, the location
information
11 database 136 and/or other elements may be implemented as an arithmetic
and logic
12 unit (ALU) having access to a code memory (not shown) which stores program
13 instructions for the operation of the ALU. The program instructions
could be stored
14 on a medium which is fixed, tangible and readable directly by the NAS 126,
the
location information database 136 and/or other elements, (e.g., removable
diskette,
16 CD-ROM, ROM, fixed disk, USB drive), or the program instructions could
be stored
17 remotely but transmittable to the NAS 126, the location information
database 136
18 and/or other elements via a modem or other interface device.
19
While specific embodiments of the present invention have been described and
21 illustrated, it will be apparent to those skilled in the art that
numerous modifications
22 and variations can be made without departing from the scope of the
invention as
23 defined in the appended claims.
17
