CA2540276C - Method for populating a location information database used in the delivery of emergency and other location-based services in a voip environment - Google Patents
Method for populating a location information database used in the delivery of emergency and other location-based services in a voip environment Download PDFInfo
- Publication number
- CA2540276C CA2540276C CA2540276A CA2540276A CA2540276C CA 2540276 C CA2540276 C CA 2540276C CA 2540276 A CA2540276 A CA 2540276A CA 2540276 A CA2540276 A CA 2540276A CA 2540276 C CA2540276 C CA 2540276C
- Authority
- CA
- Canada
- Prior art keywords
- host device
- logical
- method defined
- information database
- location
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 50
- 238000012384 transportation and delivery Methods 0.000 title description 5
- 230000004044 response Effects 0.000 claims abstract description 12
- 238000013507 mapping Methods 0.000 claims description 29
- 238000013475 authorization Methods 0.000 claims description 28
- RYGMFSIKBFXOCR-UHFFFAOYSA-N Copper Chemical compound [Cu] RYGMFSIKBFXOCR-UHFFFAOYSA-N 0.000 claims description 3
- 229910052802 copper Inorganic materials 0.000 claims description 3
- 239000010949 copper Substances 0.000 claims description 3
- 239000000835 fiber Substances 0.000 claims description 2
- 238000009877 rendering Methods 0.000 claims 1
- 238000004891 communication Methods 0.000 description 11
- 230000000977 initiatory effect Effects 0.000 description 8
- 108010007100 Pulmonary Surfactant-Associated Protein A Proteins 0.000 description 6
- 102100027773 Pulmonary surfactant-associated protein A2 Human genes 0.000 description 6
- OYYYPYWQLRODNN-UHFFFAOYSA-N [hydroxy(3-methylbut-3-enoxy)phosphoryl]methylphosphonic acid Chemical compound CC(=C)CCOP(O)(=O)CP(O)(O)=O OYYYPYWQLRODNN-UHFFFAOYSA-N 0.000 description 3
- 230000004913 activation Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 230000015654 memory Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 101100459773 Caenorhabditis elegans nas-11 gene Proteins 0.000 description 1
- 101100459775 Caenorhabditis elegans nas-13 gene Proteins 0.000 description 1
- 101100347998 Caenorhabditis elegans nas-21 gene Proteins 0.000 description 1
- 206010047289 Ventricular extrasystoles Diseases 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000013329 compounding Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 238000009424 underpinning Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
- H04L65/401—Support for services or applications wherein the services involve a main real-time session and one or more additional parallel real-time or time sensitive sessions, e.g. white board sharing or spawning of a subconference
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/52—Network services specially adapted for the location of the user terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2101/00—Indexing scheme associated with group H04L61/00
- H04L2101/60—Types of network addresses
- H04L2101/618—Details of network addresses
- H04L2101/64—Asynchronous transfer mode [ATM] addresses
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
A method of 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 device and a network access server. The method comprises receiving from the host device over the logical connection a request for network access; assigning a logical identifier to the host device in response to the receiving; determining a physical location associated 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 information database.
Description
86503-131 and -132
2 USED IN THE DELIVERY OF EMERGENCY AND OTHER LOCATION-
3 BASED SERVICES IN A VOIP ENVIRONMENT
4 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.
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.
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 86503-131 and -132 1 existing emergency infrastructure, thereby allowing existing PSAPs to handle emergency 2 calls placed by VoIP customers.
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.
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.
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 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 86503-131 and -132 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.
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.
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.
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 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.
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.
23 In the drawings:
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.
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.
34 Fig. 4 shows origination and flow of an emergency call.
86503-131 and -132 2 Fig. 5 shows origination and flow of a customer service call.
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.
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.
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
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.
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 86503-131 and -132 1 existing emergency infrastructure, thereby allowing existing PSAPs to handle emergency 2 calls placed by VoIP customers.
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.
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.
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 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 86503-131 and -132 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.
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.
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.
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 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.
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.
23 In the drawings:
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.
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.
34 Fig. 4 shows origination and flow of an emergency call.
86503-131 and -132 2 Fig. 5 shows origination and flow of a customer service call.
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.
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.
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 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).
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
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.
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.
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
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.
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.
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 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.
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.
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:
19 - The host device 102 establishes physical layer connectivity with the access multiplexer 106 over the physical communication link 108.
22 - This is followed by the establishment of Ethernet connectivity between the host device 102 23 and the access multiplexer 106.
- 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).
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 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.
- The host device begins entry into PPPoE communication by broadcasting an 6 "initiation" packet over the dedicated logical link 130.
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).
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 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:
Alternative 1 (where the pool 127 of logical identifiers is maintained by the authorization entity 142): the authorization entity 142 obtains a logical identifier 210 from the pool 127 of logical identifiers that is maintained by the 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.
- 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 completing the establishment of a PPPoE session between the endpoints of the 18 logical connection 202.
- Additional hand-shaking may be performed between the host device 102 and the in order to establish a Point-to-Point Protocol (PPP) session between the 22 endpoints of the logical connection 202.
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.
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.
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.
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.
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.
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.
86503-131 and -132 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.
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.
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.
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 86503-131 and -132 1 objects indicative of respective physical locations associated with those logical identifiers.
3 Emergency Services 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)".
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.
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.
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 86503-131 and -132 1 with the location information database 136 either before or during origination of the 2 emergency call.
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.
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.
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.
32 Upon receipt of the ESQK and the ESRN from the VPC 404, the call server 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 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.
8 Non-Emergency Location-Based Services 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.
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.
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.
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 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.
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.
17 Assuming that the location of the host device 102 has been obtained, the 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.).
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.).
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.
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 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.
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.
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.
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.
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
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.
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.
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 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.
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.
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:
19 - The host device 102 establishes physical layer connectivity with the access multiplexer 106 over the physical communication link 108.
22 - This is followed by the establishment of Ethernet connectivity between the host device 102 23 and the access multiplexer 106.
- 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).
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 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.
- The host device begins entry into PPPoE communication by broadcasting an 6 "initiation" packet over the dedicated logical link 130.
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).
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 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:
Alternative 1 (where the pool 127 of logical identifiers is maintained by the authorization entity 142): the authorization entity 142 obtains a logical identifier 210 from the pool 127 of logical identifiers that is maintained by the 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.
- 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 completing the establishment of a PPPoE session between the endpoints of the 18 logical connection 202.
- Additional hand-shaking may be performed between the host device 102 and the in order to establish a Point-to-Point Protocol (PPP) session between the 22 endpoints of the logical connection 202.
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.
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.
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.
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.
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.
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.
86503-131 and -132 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.
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.
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.
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 86503-131 and -132 1 objects indicative of respective physical locations associated with those logical identifiers.
3 Emergency Services 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)".
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.
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.
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 86503-131 and -132 1 with the location information database 136 either before or during origination of the 2 emergency call.
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.
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.
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.
32 Upon receipt of the ESQK and the ESRN from the VPC 404, the call server 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 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.
8 Non-Emergency Location-Based Services 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.
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.
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.
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 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.
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.
17 Assuming that the location of the host device 102 has been obtained, the 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.).
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.).
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.
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 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.
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.
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.
Claims (39)
1. A method of 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 device and a network access server, comprising:
- receiving from said host device over said logical connection a request for network access;
- assigning a logical identifier to said host device in response to said receiving;
- determining a physical location associated with said endpoint of said logical connection;
- creating an association between said logical identifier and said physical location;
- storing said association in the location information database; and - sending said logical identifier to said host device subsequent to said determining.
- receiving from said host device over said logical connection a request for network access;
- assigning a logical identifier to said host device in response to said receiving;
- determining a physical location associated with said endpoint of said logical connection;
- creating an association between said logical identifier and said physical location;
- storing said association in the location information database; and - sending said logical identifier to said host device subsequent to said determining.
2. The method defined in claim 1, further comprising:
- transmitting said logical identifier and said physical location to a computing apparatus.
- transmitting said logical identifier and said physical location to a computing apparatus.
3. The method defined in claim 2, said computing apparatus performing said creating and said storing.
4. The method defined in claim 3, said computing apparatus being implemented as a location information database.
5. The method defined in any one of claims 1 to 4, wherein said receiving is performed by the network access server.
6. The method defined in any one of claims 1 to 5, wherein said logical identifier comprises an IP address.
7. The method defined in claim any one of claims 1 to 6, wherein said logical connection traverses (i) a first physical portion between said host device and a port of an access multiplexer; and (ii) a second physical portion between said access multiplexer and said network access server.
8. The method defined in claim 7, wherein a dedicated logical link for supporting said logical connection is established over said second portion.
9. The method defined in claim 8, wherein said dedicated logical link comprises an ATM
PVC.
PVC.
10. The method defined in claim 9, wherein said logical connection is implemented using PPPoE.
11. The method defined in claim 8, wherein said dedicated logical link comprises a virtual local area network (VLAN).
12. The method defined in claim 8, wherein said first portion comprises at least one of a copper pair, a fiber optic cable, a coax cable and a wireless link.
13. The method defined in any one of claims 1 to 12, wherein said network access server is operative to provide access to a core packet-switched network.
14. The method defined in any one of claims 1 to 13, wherein said host device comprises a router and a broadband modem.
15. The method defined in claim 14, wherein said router provides a connection to at least one IP-enabled telephony system.
16. The method defined in claim 15, wherein said at least one IP-enabled telephony system comprises at least one of (a) an IP-phone; (b) an analog terminal adapter connected to a POTS phone; and (c) a computer implementing an IP telephony software application.
17. The method defined in any one of claims 1 to 13, wherein said host device comprises a wireless access point.
18. The method defined in claim 8, further comprising:
-consulting a mapping of dedicated logical links to logical identifiers on the basis of the logical identifier assigned to said host device, thereby to obtain an identity of the dedicated logical link supporting said logical connection of which said host device is an endpoint.
-consulting a mapping of dedicated logical links to logical identifiers on the basis of the logical identifier assigned to said host device, thereby to obtain an identity of the dedicated logical link supporting said logical connection of which said host device is an endpoint.
19. The method defined in claim 18, further comprising:
-querying an operation support system with said identity of the dedicated logical link supporting said logical connection of which said host device is an endpoint, the operation support system maintaining a mapping of physical locations to respective dedicated logical links, thereby to obtain said physical location associated with said endpoint of said logical connection.
-querying an operation support system with said identity of the dedicated logical link supporting said logical connection of which said host device is an endpoint, the operation support system maintaining a mapping of physical locations to respective dedicated logical links, thereby to obtain said physical location associated with said endpoint of said logical connection.
20. The method defined in claim 19, wherein said creating is implemented by said operation support system.
21. The method defined in any one of claims 1 to 20, wherein said physical location comprises a civic address.
22. The method defined in any one of claims 1 to 20, wherein said physical location comprises geo-spatial coordinates.
23. The method defined in any one of claims 1 to 22, wherein said assigning comprises said network access server selecting said logical identifier from a set of pre-allocated logical identifiers.
24. The method defined in claim any one of claims 1 to 23, wherein said request for network access comprises credentials.
25. The method defined in claim 24, further comprising attempting to authorize said host device based on said credentials.
26. The method defined in claim 25, wherein said assigning is performed only in response to successful authorization of said host device.
27. The method defined in claim 26, wherein said assigning comprises causing said authorization entity to select said logical identifier from a set of pre-allocated logical identifiers.
28. The method defined in claim 27, wherein said assigning is performed by the network access server.
29. The method defined in claim 28, wherein said attempting to authorize is performed by an AAA server.
30. The method defined in claim 29, wherein said assigning is performed by the AAA server.
31. A method, comprising:
- for each of a plurality of host devices, populating a location information database in accordance with the method of claim 1;
- receiving from a particular host device a call specifying a particular logical identifier;
- consulting the location information database to determine a physical location associated with the particular logical identifier.
- for each of a plurality of host devices, populating a location information database in accordance with the method of claim 1;
- receiving from a particular host device a call specifying a particular logical identifier;
- consulting the location information database to determine a physical location associated with the particular logical identifier.
32. The method defined in claim 31, wherein said call is an emergency call.
33. The method defined in claim 31 or claim 32, further comprising:
- routing the call to an emergency operator; and - rendering available to the emergency operator said physical location associated with the particular logical identifier.
- routing the call to an emergency operator; and - rendering available to the emergency operator said physical location associated with the particular logical identifier.
34. A method, comprising:
- for each of a plurality of host devices, populating a location information database in accordance with the method of any one of claims 1 to 33;
- receiving from a particular host device a particular logical identifier;
- consulting the location information database to determine a physical location associated with the particular logical identifier;
- sending to the particular host device the physical location associated with the particular logical identifier;
- when placing a call, the host device specifying the physical location associated with the particular logical identifier.
- for each of a plurality of host devices, populating a location information database in accordance with the method of any one of claims 1 to 33;
- receiving from a particular host device a particular logical identifier;
- consulting the location information database to determine a physical location associated with the particular logical identifier;
- sending to the particular host device the physical location associated with the particular logical identifier;
- when placing a call, the host device specifying the physical location associated with the particular logical identifier.
35. A method of 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 device and a network access server, comprising:
- receiving from said host device over said logical connection a request for network access;
- assigning a logical identifier to said host device in response to said receiving;
- providing said logical identifier to a computing apparatus capable of:
(i) determining a physical location associated with said endpoint of said logical connection;
(ii) creating an association between said logical identifier and said physical location; (iii) storing said association; and (iv) sending said logical identifier to said host device subsequent to said determining.
- receiving from said host device over said logical connection a request for network access;
- assigning a logical identifier to said host device in response to said receiving;
- providing said logical identifier to a computing apparatus capable of:
(i) determining a physical location associated with said endpoint of said logical connection;
(ii) creating an association between said logical identifier and said physical location; (iii) storing said association; and (iv) sending said logical identifier to said host device subsequent to said determining.
36. The method defined in claim 35, wherein said computing apparatus is a location information database.
37. A method of populating a location information database for use in providing a location-based service, comprising:
- receiving a logical identifier assigned to a host device in response to receiving a request for network access from said host device over a logical connection having a first endpoint that is the host device and a second endpoint that is a network access server;
- determining a physical location associated with said endpoint of said logical connection;
- creating an association between said logical identifier and said physical location;
- storing said association in the location information database; and - sending said logical identifier to said host device subsequent to said determining.
- receiving a logical identifier assigned to a host device in response to receiving a request for network access from said host device over a logical connection having a first endpoint that is the host device and a second endpoint that is a network access server;
- determining a physical location associated with said endpoint of said logical connection;
- creating an association between said logical identifier and said physical location;
- storing said association in the location information database; and - sending said logical identifier to said host device subsequent to said determining.
38. Apparatus for 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 device and a network access server, comprising:
- first means for receiving from said host device over said logical connection a request for network access;
- second means for assigning a logical identifier to said host device in response to said receiving;
- third means for determining a physical location associated with said endpoint of said logical connection;
- fourth means for creating an association between said logical identifier and said physical location;
- fifth means for storing said association in the location information database; and - sixth means for sending said logical identifier to said host device subsequent to said determining.
- first means for receiving from said host device over said logical connection a request for network access;
- second means for assigning a logical identifier to said host device in response to said receiving;
- third means for determining a physical location associated with said endpoint of said logical connection;
- fourth means for creating an association between said logical identifier and said physical location;
- fifth means for storing said association in the location information database; and - sixth means for sending said logical identifier to said host device subsequent to said determining.
39. The apparatus defined in claim 38, wherein:
- the first means is implemented by a network access server;
- the second means is implemented by either the network access server or an authorization entity;
- the third means is implemented by an operation support system;
- the fourth means is implemented by either the operation support system or the location information database;
- the fifth means is implemented by the location information database.
- the first means is implemented by a network access server;
- the second means is implemented by either the network access server or an authorization entity;
- the third means is implemented by an operation support system;
- the fourth means is implemented by either the operation support system or the location information database;
- the fifth means is implemented by the location information database.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2540276A CA2540276C (en) | 2006-03-20 | 2006-03-20 | Method for populating a location information database used in the delivery of emergency and other location-based services in a voip environment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2540276A CA2540276C (en) | 2006-03-20 | 2006-03-20 | Method for populating a location information database used in the delivery of emergency and other location-based services in a voip environment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2540276A1 CA2540276A1 (en) | 2007-09-20 |
| CA2540276C true CA2540276C (en) | 2015-06-02 |
Family
ID=38520892
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2540276A Active CA2540276C (en) | 2006-03-20 | 2006-03-20 | Method for populating a location information database used in the delivery of emergency and other location-based services in a voip environment |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2540276C (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10033641B2 (en) | 2014-11-06 | 2018-07-24 | Juniper Networks, Inc. | Deterministic and optimized bit index explicit replication (BIER) forwarding |
| US10153967B2 (en) | 2014-11-06 | 2018-12-11 | Juniper Networks, Inc. | Deterministic and optimized bit index explicit replication (BIER) forwarding |
| EP3432513B1 (en) * | 2015-06-29 | 2020-12-02 | Juniper Networks, Inc. | Deterministic and optimized bit index explicit replication (bier) forwarding |
-
2006
- 2006-03-20 CA CA2540276A patent/CA2540276C/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CA2540276A1 (en) | 2007-09-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8768951B2 (en) | Method for populating a location information database used in the delivery of emergency and other location-based services in a VoIP environment | |
| US8280989B2 (en) | Method, system and apparatus for provisioning a communication client | |
| US7602886B1 (en) | Method and system for using a network-provided location for voice-over-packet emergency services calls | |
| US9294436B2 (en) | Method, system and apparatus for verifying validity of location information in a packet-based network | |
| US9020105B2 (en) | Systems and methods for third party emergency call termination | |
| JP5987122B2 (en) | Network address translated device identification for device specific traffic flow steering | |
| US20070127452A1 (en) | Voice over Internet protocol (VoIP) mobility detection | |
| US20070201622A1 (en) | Method and apparatus for providing E911 services for nomadic users | |
| US20100166167A1 (en) | Method and Apparatus for Managing Subscriber Profile Information | |
| US20150156320A1 (en) | Systems and methods for locating endpoints in a communication network | |
| US9667802B2 (en) | Methods of assigning, recording and using a location routing number | |
| CA2540276C (en) | Method for populating a location information database used in the delivery of emergency and other location-based services in a voip environment | |
| US9072074B1 (en) | Method and apparatus for determining the location of a terminal adaptor | |
| US20140341210A1 (en) | Delivering correct number information in a private sip netework | |
| US7706253B1 (en) | Gateway to route communications during a fault | |
| WO2018052932A1 (en) | Next generation emergency call routing over diverse networks | |
| US10084923B2 (en) | Method and system for dynamic trunk group based call routing | |
| KR101836655B1 (en) | Method and system for processing in bound call of the messenger subscriber | |
| JP2009027710A (en) | Reduction of wireless communication costs in enterprise | |
| US7881289B1 (en) | Method and apparatus for porting telephone numbers of endpoint devices | |
| CA2548943A1 (en) | Method, system and apparatus for retrieving location information on behalf of a location-unaware device in a packet-switched environment | |
| US20070263801A1 (en) | Method for Addressing a Device in Behalf of Establishing a Communication Path Between a Telephony Network and a Data Network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request |