Method, system and apparatus for verifying validity of location information in a packet-switched network

According to embodiments of the present invention, there are provided a method, system and apparatus for determining validity of location information in a packet-switched network. A method for determining if location information associated with an endpoint in a packet-switched network is valid, the location information having been stored in a memory, comprises obtaining an access device identifier associated with an access device responsible for handling a communication session between the endpoint and the packet-switched network. The access device identifier is then compared with a last known access device identifier associated with the endpoint to enable determining if the location information is valid.

FIELD OF THE INVENTION

This invention relates to the field of telecommunications in general and, more specifically, to a method, system and apparatus for verifying validity of location information in a packet-based network.

BACKGROUND OF THE INVENTION

With the advent of the Internet, society has witnessed the expansion of a global packet-switched network into an ever increasing number of homes and businesses. This has enabled an ever-increasing number of users to communicate with each other, primarily utilizing electronic communications such as e-mail and instant messaging. Meanwhile, advances have been made in delivering voice communication over packet-switched networks, driven primarily by the cost advantage of placing long-distance calls over the packet-switched networks, but also by the ability to deliver advanced service features to the customers. This cost advantage can be enjoyed by both a service provider delivering the voice communication over packet-switched network service (in a form of lower operating cost), as well as a customer who subscribes to the services of such a service provider (in a form of lower service subscription fees). Technology dealing with the delivery of real-time voice communication over the packet-switched network is generally referred to as voice-over-packet, voice-over-IP or VoIP.

As far as a communication endpoint in a VoIP system is concerned, several implementations have been envisioned in the industry. Some service providers have offered its customers the use of a VoIP phone that is connected directly to the packet-switched network. Even though these VoIP phones can offer a number of advanced communication features, deployment of VoIP phones obviously leads to an increased cost associated with purchase of a new VoIP phone. Other service providers have offered its customers the use of a so-called “soft phone” or, in other words, a computing apparatus equipped with software to originate and receive calls via the packet-switched network. Yet others have offered their customers the possibility to re-use their existing Plain Old Telephone System (POTS) phones by equipping them with an Analogue Telephone Adaptor (ATA) which essentially mediates communication between the packet-switched network and the POTS phone by translating digital communication into analogue communication and vice versa.

As is well appreciated in the art, the delivery technology for VoIP is fundamentally different from the delivery technology for the traditional PSTN-based calls. As a result of these differences, one area where service providers of VoIP services have encountered challenges is in the area of provisioning of emergency services. Several solutions have been proposed, including a system where a user of the VoIP endpoint is expected to register the address associated with the VoIP endpoint (a so-called “emergency address”) which is stored in a memory and is retrieved when the user places an emergency call using the VoIP endpoint. The retrieved emergency address is used for two purposes: (i) to determine a Public Safety Answering Point (PSAP) that is responsible for handling calls from a particular geographic area associated with the emergency address; and (ii) transmit the emergency address to the PSAP to enable delivery of so-called “enhanced 9-1-1” services.

This solution has definite merit; however it still suffers a disadvantage associated with the fact that, due to the very nature of VoIP systems, the user can plug his or her VoIP endpoint (i.e., the VoIP phone, the ATA or the soft phone) anywhere where a high speed connection is available and place the emergency call. If the user has indeed moved his or her VoIP endpoint without updating the emergency address stored in the aforementioned memory with the new emergency address, the prior art system has no means of determining that the emergency address stored in the aforementioned memory is no longer the correct address associated with the location of the VoIP endpoint. Quite on the contrary, the aforementioned system will retrieve the stored address, determine the PSAP to route the emergency call to based on the retrieved emergency address and transmit the emergency address to the PSAP. It is clear that in this scenario, the call will most probably be routed to a wrong PSAP and the wrong emergency address information will be transmitted to the wrong PSAP. If the user of the VoIP endpoint is unable to speak (for example due to a medical condition the user is experiencing), an emergency response team will be dispatched to the wrong location, potentially resulting in a lethal outcome of the emergency situation experienced by the user.

Clearly, there is a need in the art for an improved system for verifying validity of the stored emergency address or other types of location information.

SUMMARY OF THE INVENTION

According to a first broad aspect of the present invention, there is provided a method for determining if an emergency address associated with an endpoint in a packet-switched network is valid, the emergency address having been stored in a memory. The method comprises obtaining an access device identifier associated with an access device responsible for handling a communication session between the endpoint and the packet-switched network; comparing the access device identifier with a last known access device identifier associated with the endpoint; based on the comparing, determining if the emergency address is valid.

According to a second broad aspect of the present invention, there is provided a method for enabling determining if location information associated with an endpoint in a packet-switched network is valid, the method executable at the endpoint. The method comprises determining an access device identifier associated with an access device which is to be utilized by the endpoint to establish a communication session over the packet-switched network; storing the access device identifier in a memory; releasing the access device identifier to a network entity; the releasing for enabling the network entity to compare the access device identifier with a last known access device identifier associated with the endpoint in an attempt to validate that the location information is valid.

According to a third broad aspect of the present invention, there is provided a method for enabling determining if location information associated with an endpoint in a packet-switched network is valid. The method comprises receiving from the endpoint at least an endpoint identifier and an access device identifier; determining if a record associated with the endpoint identifier exists; if the determining renders a negative outcome, creating the record associated with the endpoint, the record for storing at least the endpoint identifier and the access device identifier; wherein the record associated with the endpoint is for enabling determining if location information associated with the endpoint is valid.

According to a fourth broad aspect of the present invention, there is provided a method for determining if location information associated with an endpoint in a packet-switched network is valid, the location information having been stored in a memory. The method comprises obtaining an access device identifier associated with an access device responsible for handling a communication session between the endpoint and the packet-switched network; comparing the access device identifier with a last known access device identifier associated with the endpoint; based on the comparing, determining if the service address is valid.

According to a fifth broad aspect of the present invention, there is provided an apparatus for determining if an emergency address associated with an endpoint in a packet-switched network is valid, the emergency address having been stored in a memory. The apparatus comprises means for obtaining an access device identifier associated with an access device responsible for handling a communication session between the endpoint and the packet-switched network; means for comparing the access device identifier with a last known access device identifier associated with the endpoint; means for determining if the emergency address is valid, the means for determining being responsive to the means for comparing.

According to another broad aspect of the present invention, there is provided an apparatus for enabling determining if associated location information is valid, the apparatus connectable to an access device, the access device for enabling the apparatus to establish a communication session via a packet-switched network. The apparatus comprises means for determining an access device identifier associated with the access device; means for storing the access device identifier in a memory; means for releasing the access device identifier to a network entity; the releasing for enabling the network entity to compare the access device identifier with a last known access device identifier associated with the endpoint in an attempt to validate if the location information is valid.

According to another broad aspect of the present invention, there is provided a system for determining if an emergency address associated with an endpoint in a packet-switched network is valid, the emergency address having been stored in a memory. The system comprising: a network entity; an access device for enabling the endpoint to establish a communication session with the network entity. The network entity is operable to obtain an access device identifier associated with the access device; compare the access device identifier with a last known access device identifier associated with the endpoint; determine if the emergency address is valid.

According to yet another broad aspect of the present invention, there is provided a system for determining if an emergency address associated with an endpoint in a packet-switched network is valid, the emergency address having been stored in a memory. The system comprises a network entity that is operable to obtain an access device identifier associated with an access device responsible for handling a communication session between the endpoint and the packet-switched network; compare the access device identifier with a last known access device identifier associated with the endpoint; determine if the emergency address is valid.

These and other aspects and features of the present invention will now become apparent to those skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying drawings.

It is to be expressly understood that the description and drawings are only for the purpose of illustration of certain embodiments of the invention and are an aid for understanding. They are not intended to be a definition of the limits of the invention.

DETAILED DESCRIPTION OF THE EMBODIMENTS

FIG. 1Ashows various components of an infrastructure for verifying validity of an emergency address in a packet-switched network in accordance with a non-limiting embodiment of the present invention. The infrastructure comprises an access device102which is connected to an access multiplexer106via a physical connection link108. In a non-limiting example, the access device102can comprise a modem110connected to a router112over a home network114. The modem110can comprise any suitable broadband modem, such as, but not limited to, a cable modem, an xDSL modem and the like. The router112can be embodied in any suitable wired or wireless router. In another non-limiting embodiment, the functionality of the router112and the modem110can be embodied in a single device. In some non-limiting embodiments, the home network114can comprise an Ethernet network. In other non-limiting embodiments, the home network114can comprise a wireless network (ex. an 802.11 based network, an 802.12 based network and the like) or any other suitable type of home network.

The router112may in turn be connected over the home network114to a VoIP phone116or, alternatively, to a POTS phone118via an analog terminal adapter (ATA)120. The ATA120and the VoIP phone116are just two non-limiting embodiments of a so-called “VoIP endpoint”. Another non-limiting example of the VoIP endpoint can be embodied as a computer implementing an IP telephony software application (so-called soft client software).

In an example non-limiting embodiment, the physical communication link108can be a copper twisted pair, over which higher-layer protocols allow for the exchange of packets. In an alternative non-limiting embodiment, the physical communication link108may comprise an Ethernet link, a fiber optic link (e.g., Fiber-to-the-Home, Fiber-to-the-Curb, etc.), a wireless link (e.g., EV-DO, WiMax, WiFi, CDMA, TDMA, GSM, and the like), a cable, etc., or a combination thereof. In some non-limiting embodiments, the home network114can comprise an Ethernet network. In other non-limiting embodiments, the home network114can comprise a wireless network (ex. an 802.11 based network, an 802.12 based network, an 802.16 based network and the like) or any other suitable type of home network.

In another non-limiting embodiment, the functionality of the router112and the modem110can be embodied in a single device. In an alternative non-limiting embodiment of the present invention, the router112can be omitted from the infrastructure ofFIG. 1. In yet further non-limiting embodiments of the present invention, the functionality of the ATA120can be incorporated into the modem110. In another non-limiting embodiment of the present invention, the functionality of the ATA120can be incorporated into the router112. Alternatively, in yet other non-limiting embodiments of the present invention, the functionality of the router112, the modem110and the ATA120(or the VoIP phone116) can be incorporated into a single device.

The access multiplexer106, which in a non-limiting embodiment can be a digital subscriber line access multiplexer (DSLAM), is connected to a network access server (NAS)126via an access data network124. In a non-limiting embodiment, the access multiplexer106can comprise a Stinger® FS+ DSL Access Concentrator from Lucent Technologies, 600 Mountain Avenue, Murray Hill, N.J., USA. In these embodiments, the access multiplexer106can be located in a central office (not depicted) of a service provider. Alternatively, the access multiplexer106can be located at an outside location, in which case, the access multiplexer106can be embodied in what is referred to in the industry as an OPI-DSLAM or an outside plant interface DSLAM. In this scenario, the DSLAM120can comprise a Stinger® Compact Remote from Lucent Technologies. Yet in other embodiments of the present invention, the access multiplexer106can be distributed, with some components being situated in the central office and some components being situated at the outside location. It should be noted that in other non-limiting embodiments of the present invention, other types of access multiplexer106can be used. For example, in the above-mentioned cable scenario a so-called “unmanned hub” can be utilized.

The NAS126is sometimes also referred to by some in the industry as a broadband remote access server (BRAS), a remote access server (RAS) or a broadband access server (BAS). The NAS126provides access to a core packet-switched data network132, such as the Internet, over which VoIP calls can be established. In alternative embodiments of the invention, the core packet-switched data network132can be implemented in any suitable data network adapted for supporting VoIP calls, such as, but not limited to, a private data network, a public data network (ex. the Internet) and the like. The type of the access data network124is immaterial for the purposes of the embodiments of the present invention. Generally speaking, the access data network124can support one or more logical links (not depicted) between the access multiplexer106and the NAS126(such as asynchronous transfer mode permanent virtual circuit (PVC), a virtual local area network (VLAN) and the like). The purpose of the access multiplexer106is to multiplex several physical links (such as the link108) from several access devices (such as access device102) for communication over the access data network124and vice versa.

The access multiplexer106can comprise a number of ports, such as a port106A depicted inFIG. 1A. In some embodiments of the present invention, the port106A is dedicated to the physical connection link108. In these embodiments, each port of the access multiplexer106(such as the port106A) can be associated with a dedicated logical link, for example the aforementioned PVC or VLAN, which in turn can be uniquely associated with the physical connection link108.

In some non-limiting embodiments of the present invention, the router112can implement a DHCP server functionality. In other words, the router112can receive an IP address request from a device connected thereto (such as the ATA120and/or the VoIP phone116) and, responsive to such an IP address request, to assign an IP address. In these embodiments, the router112can also perform network address translation functionality. Put another way, the IP address assigned by the router112to the devices connected thereto can be a private IP address used for addressing devices connected to the home network114(such as the ATA120and/or the VoIP phone116) and the router112can perform a network address functionality by translating one or more private IP addresses into a global IP address used by the router112for communication with entities outside of the home network114via the core packet-switched network132and vice versa.

In alternative non-limiting embodiments of the present invention, the DHCP functionality can be performed by the network access server126. A non-limiting example of such a non-limiting embodiment is depicted inFIG. 1B, where a DHCP server180can be integrated with (depicted in a broken line192) or can be accessed by the network access server126(depicted generally by a connection190). In these embodiments, the router112can obtain an IP address by transmitting an IP address request to the DHCP server180. How the router112transmits the IP address request is not particularly limiting and can include, but is not limited to, broadcasting a DHCP request, establishing a PPPoE session, establishing a PPP session, transmitting an IP address request via a logical connection (such as a VLAN, a PVC, etc.) and the like. It should be noted that in some non-limiting embodiments of the present invention, the network access server126can access the DHCP server180via a network, such as, but not limited to, the access data network124or the core packet-switched data network132.

Returning toFIG. 1Aand according to a specific non-limiting embodiment depicted therein, whereby the home network114is implemented as an Ethernet network and whereby the router112can implement a DHCP server functionality, the VoIP endpoint (such as the ATA120) can maintain a mapping, which is commonly referred to by those of skill in the art as “Address Resolution Protocol” or simply as an “ARP” mapping. Specifically, the ARP mapping denotes a relationship between a destination IP Address and a destination MAC address for each potential destination device coupled to the home network114. For example, for the purposes of communication between the ATA120and the router112, the ATA120can maintain an ARP mapping that correlates the IP address of the router112(such as, but not limited to, the private IP address assigned to the router112for the purposes of communication over the home network114) and the MAC address of a port of the router112which the ATA120is connected to. Naturally, other entities connected to the home network114(such as the VoIP phone116, the router112, etc.) can also maintain similar ARP mappings.

A non-limiting example of an ARP mapping that can be maintained by the ATA120is depicted in Table 1 below.

As shown in Table 1, the ARP mapping correlates a 1stdestination identifier and a 2nddestination identifier of a potential destination device. An example of the 1stdestination identifier is a MAC address and an example of the 2ndnetwork identifier is an IP address, but this not need to be construed as a limitation of the present invention. In fact, any suitable type of the 1stand 2ndidentifiers (or just a single identifier) can be used. Returning to the two examples presented in Table 1, the ATA120can maintain two ARP mappings—one for the router112(ex. MAC address 00-08-74-4C-7F-1D and the corresponding IP address 125.213.22.165) and one for the VoIP phone118(ex. a proprietary identifier 1256-IX1 and the corresponding proprietary identifier 25896655).

Also provided inFIG. 1Ais a network element140, which in some embodiments of the present invention can be provided at an edge of the core packet-switched data network132. The network element140is referred to in the industry as a “packet switch” or a “soft switch” and comprises circuitry, software and/or control logic for providing various communication services to VoIP endpoints (such as, for example, the ATA120, the VoIP phone116or the aforementioned computer implementing an IP telephony software application). Examples of such communication services include (i) connecting incoming calls to the VoIP endpoint (such as the ATA120, the VoIP phone116or the aforementioned computer implementing an IP telephony software application); and (ii) handling outgoing calls originated from the VoIP endpoint (such as the ATA120, the VoIP phone116or the aforementioned computer implementing an IP telephony software application). Other examples of communication services that can be performed by the network element140can include but are not limited to call waiting, call forwarding, and so on.

In addition, the network element140can comprise suitable circuitry, software and/or control logic for exchanging calls with entities outside the core packet-switched data network132. This is particularly convenient, when a call placed by a VoIP customer (i.e. a user of the VoIP phone116) to a telephone number that is reachable only via the Public Switched Telephone Network (PSTN), which has been omitted fromFIG. 1Afor the sake of simplicity. A non-limiting example of the network element140can be embodied in a MCS 5200 Soft Switch manufactured by Nortel Networks Ltd. of 8200 Dixie Road, Brampton, Ontario L6T 5P6, Canada.

Given the components of the infrastructure ofFIG. 1Adescribed above, it is possible to deliver VoIP telephony services to the user of the VoIP phone116or the POTS phone118equipped with the ATA120. The VoIP telephony service can be delivered by a service provider who manages the aforementioned access multiplexer106, the access data network124, the NAS126and the network element140. Alternatively, the VoIP telephony service can be delivered by an alternative service provider in which case the VoIP telephony service “runs over” the infrastructure ofFIG. 1. This arrangement for delivering the VoIP telephony service is generally referred to as “over-the-top VoIP”.

In order to facilitate provisioning of emergency services, the infrastructure ofFIG. 1Afurther comprises an emergency services entity160. The emergency services entity160can comprise several components, such as one or more Public Safety Answering Points (PSAPs), one or more 911 selective routers, an Automatic Line Identification (ALI) database and the like. These components are well known to those of skill in the art and, as such, have been omitted fromFIG. 1A. In some embodiments of the present invention, the emergency services entity160can be connected to the network element140via the PSTN (not depicted). In these embodiments, the emergency services entity160further comprises one or more media gateways (not depicted), the main purpose of which is to mediate digital communication to analog communication and vice versa.

Communicatively coupled to the core packet-switched data network132is a provisioning server145. The function of the provisioning server145will be discussed in greater detail herein below. For now, suffice it to say, that the provisioning server145is operable to register the VoIP endpoints (i.e. the ATA120, the VoIP phone116or the aforementioned computer implementing an IP telephony software application) as they are connected to the access data network124. More specifically, the provisioning server145is operable to validate the VoIP endpoint, download the required software applications to the VoIP endpoint, perform service activation and the like.

The provisioning server145can be reached via the core packet-switched data network132at a network address, such as, but not limited to, an IP address. In some non-limiting embodiments, the IP address assigned to the provisioning server145is a static IP address. An indication of the static IP address can be hard coded into the ATA120and/or the VoIP phone116. In other words, the ATA120and/or the VoIP phone116is aware of the network address at which the provisioning server145can be reached over the core packet-switched data network132.

In an alternative non-limiting embodiment, the network address assigned to the provisioning server145can be a dynamic IP address. In these non-limiting embodiments, the ATA120and/or the VoIP phone116can be dynamically updated with the dynamic IP address of the provisioning server145, as is known to those of skill in the art. In an alternative non-limiting embodiment of the present invention, the provisioning server145can be assigned a Unique Resource Identifier (URI), such as, for example, an URL. The ATA120and/or the VoIP phone116can be made aware of this URL of the provisioning server145. The URL enables the ATA120and/or the VoIP phone116to contact the provisioning server145via the core packet-switched data network132by performing a DNS look-up, as is known to those of skill in the art.

The provisioning server145can implement one or more protocols for communicating with the VoIP endpoint (such as the ATA120and/or the VoIP phone116and/or the aforementioned computer implementing an IP telephony software application). In some non-limiting embodiments of the present invention, the provisioning server145can implement an XML over HTTPS protocol. In alternative non-limiting embodiments of the present invention, a Session Initiation Protocol or, simply, a SIP protocol can be used. In yet other embodiments, which are particularly true where the VoIP endpoint is embodied in a computing apparatus operable to execute a soft client application, Simple Object Access Protocol (SOAP) can be used. In yet further embodiments of the present invention, an Extensible Mark-up Language (XML) Configuration Access Protocol (XCAP), available from http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-11.txt, can be used. It should be noted that in alternative non-limiting embodiments, any other suitable protocol can be used.

In some embodiments of the present invention, the network element140and the provisioning server145can implement a Simple Object Access Protocol (SOAP) protocol. As such, the network element140and the provisioning server145can exchange messages using SOAP protocol via the core packet-switched data network132. Any other suitable communication protocol can be used for the purposes of communication between the network element140and the provisioning server145.

Communicatively coupled to the provisioning server145is an emergency address repository150. Generally speaking, the purpose of the emergency address repository150is to maintain a mapping between a network identifier of the VoIP endpoint and a network identifier associated with an access device (such as, but not limited to, the access device102or a portion thereof, the access multiplexer106, etc.). The emergency address repository150will now be described in greater detail with reference toFIG. 2, which depicts a specific non-limiting embodiment of such an emergency address repository150.

The emergency address repository150can maintain a number of records, such as an example record202. For the purposes of the specific non-limiting example discussed herein below, assume that the record202is associated with the user of the ATA120. The record202can comprise several fields, such as a user identifier220and a unique access device identifier224. The purpose of the user identifier220is to identify a particular user or a VoIP endpoint associated with the particular user whom the record202is associated with. A user identifier220can be embodied in a network identifier of the VoIP endpoint (such as a directory number, a SIP address, a MAC address and the like), a customer account number or any other suitable identifier.

The method for determining and populating the unique access device identifier224will be described in greater detail herein below. For the time being, suffice it to say that the purpose of the unique access device identifier224is to uniquely identify an access device employed by the VoIP endpoint (such as the POTS phone118equipped with the ATA120, the VoIP phone116or the aforementioned computer implementing an IP telephony software application) to establish a communication session via the network element140and the core packet-switched data network132. The term “access device”, as used herein below, can encompass the access device102in its entirety, the router112or the modem110. It is also envisioned that the term “access device” can encompass the access multiplexer106or even the NAS126.

In some non-limiting embodiments of the present invention, the emergency address repository150can also comprise an emergency address222. The emergency address222comprises an indication of the physical location of the VoIP endpoint, such as a civic address, a set of geo-coordinates and the like. In a first non-limiting embodiment, data maintained in the emergency address222can be provided by the user of the VoIP endpoint. Method for populating such data is described in the U.S. patent application assigned to the applicant entitled “PROVISIONING OF EMERGENCY SERVICES IN A VOICE-OVER-PACKET ENVIRONMENT”, bearing an application Ser. No. 10/986,395 filed on Nov. 12, 2004, the content of which is incorporated herein by reference in its entirety. In a second non-limiting embodiment, the emergency address222can be populated by an auto-discovery procedure, the method of implementing which is described in the U.S. patent application assigned to the applicant entitled “METHOD FOR POPULATING A LOCATION INFORMATION DATABASE USED IN THE DELIVERY OF EMERGENCY AND OTHER LOCATION-BASED SERVICES IN A VOIP ENVIRONMENT”, bearing an application Ser. No. 11/378,413, filed on Mar. 30, 2006, the content of which is incorporated herein by reference in its entirety. It should be explicitly noted that the alternative method for populating the emergency address222are within the scope of the embodiments of this invention.

It should be noted that an indication of the emergency address can be maintained elsewhere in the infrastructure ofFIG. 1A. For example, in some non-limiting embodiments of the present invention, the indication of the emergency address can be maintained by the network element140in an internal database (not depicted). In another non-limiting embodiment of the present invention, the indication of the emergency address can be maintained in a database (not depicted) accessible by the network element140via the core packet-switched data network132. In yet further non-limiting embodiments, the indication of the emergency address can be maintained by the VoIP endpoint. Yet in further non-limiting embodiments, the indication of the emergency address can be maintained in a Location Information Database (not depicted), as promulgated in a document byNENA08-001, Issue1, Dec. 6, 2005, entitled “Interim VoIP Architecture for Enhanced9-1-1Services(i2)”. Other alternatives for maintaining the indication of the emergency address are, of course, possible and are within the scope of embodiments of the present invention.

Naturally, the emergency address repository150can maintain a number of other records, collectively depicted at204. These records204can be associated with other subscribers to the VoIP telephony service.

It should be noted that in some non-limiting embodiments of the present invention, the functionality of the provisioning server145and the network element140can be integrated into a single device, as depicted inFIG. 1C. In a non-limiting embodiment depicted inFIG. 1C, the functionality of the provisioning server145and the network element140is embodied in a combined apparatus190. The combined apparatus190can access the emergency address repository150via the core packet-switched data network132. In an alternative non-limiting embodiment of the invention, the emergency address repository150can be connected directly to the combined apparatus190via a direct link (depicted as192). In another non-limiting embodiment of the present invention, the emergency address repository150can be integrated into the functionality of the combined apparatus190.

Of course, it will be apparent to those skilled in the art that numerous modifications and variations of the infrastructure ofFIGS. 1A,1B and1C are possible. For example, in an alternative non-limiting embodiment, the access multiplexer106can be omitted. This is especially true in the case where the access device102implements a wireless access point. In an example non-limiting embodiment of this scenario, the connection between the wireless access point and the NAS126can be provided by a dedicated point-to-point link. In another non-limiting scenario where the modem110implements a cable modem, the access multiplexer106can also be omitted. Yet in another non-limiting embodiment, the NAS126can be omitted from the infrastructure ofFIG. 1.

Given the infrastructure ofFIG. 1A,1B or1C, it is possible to perform a method for determining validity of the emergency address according to an embodiment of the present invention. With reference toFIGS. 3A and 3Ba method for enabling determination of validity of the emergency address is now described.

Step310: VoIP Endpoint Obtains an Indication of an Access Device Identifier

The method begins at step310at which an indication of an access device identifier is obtained. In a non-limiting embodiment of the present invention, step310can be executed when the VoIP endpoint is powered on. In alternative embodiments, step310can be executed upon occurrence of a particular event, such as the user of the ATA120attempting to place a call, the user of the ATA120attempting to place an emergency call, the ATA120broadcasting an IP address request and the like. For the purposes of the illustrative non-limiting example presented herein below, it is assumed that the VoIP endpoint comprises the ATA120.Several non-limiting alternative embodiments of how the ATA120can obtain the indication of the access device identifier are possible:

Scenario -1—FIG. 1AWhen the ATA120is powered on (for example when the user of the ATA120plugs in the ATA120for the first time), the ATA120attempts to obtain an IP address. In a non-limiting example of the architecture depicted inFIG. 1A, the ATA120can broadcast an IP address request to the router112via the home network114. For example, the ATA120can broadcast an Ethernet frame containing the IP address request.It will be recalled that in some non-limiting embodiments of the present invention, the router112can perform a DHCP server functionality. In these non-limiting embodiments, responsive to the receipt of the IP address request, the router112assigns an IP address in a manner known to those of skill in the art and generates an Ethernet frame containing the IP address assigned to the ATA120. The router112then transmits the Ethernet frame to the ATA120.When the ATA120receives the Ethernet frame, the ATA120can examine a header of the Ethernet frame in order to determine (i) an IP address associated with a source of the Ethernet frame (i.e. the router112); and (ii) a MAC address associated with the source of the Ethernet frame (i.e. a port of the router112to which the ATA120is connected to). Equipped with this information, the ATA120populates the aforementioned ARP mapping.Effectively, the ATA120has obtained the indication of the access device identifier associated with the access device (i.e. the router112).

Scenario 2—FIGS.1A/1B/1C—an Alternative ImplementationIn an alternative non-limiting scenario, which is particularly applicable in embodiments whereby the ATA120is assigned a static IP address, the ATA120can obtain the indication of the access device identifier in the following manner. When powered on, the ATA120can send a ping to the provisioning server145(or any other suitable network entity coupled to the core packet-switched network132) via the router112and via the core packet-switched network132. Responsive to receipt of the ping, the provisioning server145can send an IP packet containing a ping response to the ATA120. When the router112receives the IP packet containing the ping response destined for the ATA120, it encapsulates the received IP packet in a format suitable for transmission over the home network114. In specific non-limiting examples of the infrastructures of FIGS.1A/1B/1C, the router112can encapsulate the received IP packet into an Ethernet frame and transmit the Ethernet frame to the ATA120. When the ATA120receives the Ethernet frame, it becomes aware of the IP address and the MAC address associated with the router112in substantially the same way as described above in reference to Scenario 1. The ATA112then populates the aforementioned ARP mapping.Effectively, the ATA120has obtained the indication of the access device identifier associated with the access device (i.e. the router112).

Persons skilled in the art will appreciate that the above-described scenarios are intended to serve as examples and are not intended to be limiting in any way. Other variations for the ATA120to obtain the indication of the access device identifier are possible and are within the scope of the embodiments of this invention.

Step320: Provisioning Server145Receives the Indication of the Access Device Identifier

At step320, the provisioning server145receives the indication of the access device identifier from the ATA120. Specifically, the ATA120establishes a communication session with the provisioning server145via the core packet-switched data network132and transmits the indication of the access device identifier thereto. The ATA120also transmits an indication of an identifier associated with the ATA120, such as, but not limited to, a telephone number, a SIP address, a MAC address and the like. The indication of the identifier associated with the ATA120is hereinafter referred to as a “VoIP endpoint identifier”.Generally speaking, the ATA120creates a delivery component that contains the indication of the access device identifier and the VoIP endpoint identifier, the delivery component being compatible with the protocols associated with the communication session established between the ATA120and the provisioning server145. More specifically, it will be recalled that in some non-limiting embodiments, the ATA120and the provisioning server145can implement the XML over HTTPS protocol. In these specific non-limiting embodiments, the ATA120can transmit the indication of the access device identifier and the VoIP endpoint identifier to the provisioning server145using one or more optional fields of the XML schema. In a non-limiting example, the indication of the access device identifier and the indication of the VoIP endpoint identifier can be captured in the optional field of the XML schema as follows:
<AccessDeviceIdentifier><01-08-22-5L-8T-6M>
<EndpointIdentifier><00-08-74-4C-7F-1D>Those skilled in the art will appreciate that other protocols for transmitting the indication of the access device identifier and the VoIP endpoint identifier can be used for the purposes of the embodiments of the present invention.

Alternative ImplementationsThis alternative non-limiting embodiment of how the provisioning server145can become aware of the access device identifier is particularly applicable in embodiments whereby the provisioning server145has access to the access data network124and, more particularly, to the logical links (ex. PVC or VLAN) defined therethrough. In this non-limiting scenario, the provisioning server145can obtain the indication of the access device identifier not from the ATA120, but rather from the access device itself, which in this scenario can comprise the access multiplexer106. More specifically, the provisioning server145can request from the access multiplexer105an indication of a VLAN or the PVC assigned to a physical connection link (such as the aforementioned physical connection link108) associated with the ATA120or, in other words, an identifier of a logical link associated with the port106A which serves the ATA120.In these alternative non-limiting embodiments, the step310described above can be omitted. It should be noted that in these alternative non-limiting embodiments, execution of step320can be triggered, for example, by the ATA120being plugged in for the first time. One skilled in the art will appreciate that any other suitable trigger described above can also be used to trigger the execution of step320.In an alternative non-limiting embodiment of the present invention, the router112can transmit the indication of the access device identifier to the provisioning server145. In these non-limiting embodiments, the access device identifier can be embodied in one of: an identifier of the router112, an identifier of the modem110and the like. Yet in another non-limiting embodiment of the present invention, the NAS126can transmit the indication of the access device identifier to the provisioning server145. For example, when generating and transmitting the IP address to the ATA120, the NAS126can transmit an indication of the access device identifier (which in this scenario can be, but is not limited to, an identifier of the port106A or the access multiplexer106) to the provisioning server145.
Step330: Provisioning Server145Stores the Indication of the Access Device IdentifierNext, the provisioning server145stores the indication of the access device identifier. In some non-limiting embodiments of the present invention, execution of step330can be triggered by a so-called previous record discovery routine. To that extent, the provisioning server145attempts to locate a record associated with the user of the ATA120. Specifically, the provisioning server145retrieves the VoIP endpoint identifier associated with the ATA120(such as, but not limited to, a telephone number, a SIP address, a MAC address and the like) received in step320and attempts to locate a record which contains a user identifier220that matches the VoIP endpoint identifier associated with the ATA120.If the provisioning server145fails to locate the record, the provisioning server145realizes that no record associated with the ATA120has been provisioned and, thus, the provisioning server145deduces that the ATA120is powered on for the first time.Having determined that no record associated with the ATA120exists, the provisioning server145generates the aforementioned record202. Firstly, the provisioning server145populates the user identifier220. In a specific non-limiting example, the provisioning server145retrieves the VoIP endpoint identifier (such as, but not limited to, a telephone number, a SIP address, a MAC address and the like associated with the ATA120) and generates the user identifier220based on the retrieved VoIP endpoint identifier. Next, the provisioning server145retrieves the indication of the access device identifier and populates the unique access device identifier224.Effectively, the provisioning server145generated a record that correlates the user identifier (ex. the network identifier of the ATA120) with the access device identifier (ex. a MAC address of the port of the router112).

Given steps310to330, which can be jointly described as provisioning steps, the provisioning server145has generated knowledge of a unique access device identifier associated with an access point used by the user of the ATA120at a particular location. Put another way, the provisioning server145has obtained a unique access device identifier associated with the particular location or what is to be referred to herein below as a “last known access device identifier”. Given the knowledge of the last known access identifier, it is possible to validate whether the emergency address is valid.

Step350: Provisioning Server145Receives an Indication of an Access Device Identifier

At this step, the indication of the access device identifier is received at the provisioning server145. In some non-limiting embodiments of the present invention, step350can be performed upon occurrence of a triggering event. In some non-limiting embodiments of the present invention, the triggering event can be manifested in the ATA120broadcasting an IP address request. For example, the ATA120can broadcast the IP address request after being powered on after a power loss or pursuant to an ATA120re-set procedure that requires to power off and then to power on the ATA120. Alternatively, the ATA120can broadcast the IP address request after the user has unplugged the ATA120and plugged it in again into the same or a different power outlet (which can be at the same or at a different location). Alternatively, the ATA120can broadcast the IP address request when being plugged into a new access device, for example being plugged into another modem, such as a modem in a hotel room or the like.In an alternative embodiment of the present invention, the triggering event can be manifested in the ATA120being powered on. This is particularly true in embodiments, when the ATA120is assigned a static IP address. As will be appreciated by those of skill in the art, in these non-limiting embodiments, the ATA120does not transmit an IP address request. Therefore, step350can be executed upon the VoIP endpoint being powered on.In another non-limiting embodiment of the present invention, which are particularly true where the VoIP endpoint is embodied in a computing apparatus running a soft client application, the triggering event can comprise the user logging in to the soft client application.In yet another non-limiting embodiment of the present invention, the triggering event can comprise an occurrence of a particular time. In other words, step350can be executed on a periodic basis, such as, but not limited to, every hour, every day, monthly or at any other suitable time interval.In yet further non-limiting embodiments of the present invention, the triggering event can further be manifested in the user of the ATA120indicating his or her desire to initiate an outgoing call, for example, by dialing a destination directory number. In some embodiments of the present invention, the method is only responsive to a particular type of the outgoing call, such as, but not limited to, an emergency call. In other non-limiting embodiments, the method is responsive to any types of the requests for establishment of a communication session. In yet further non-limiting embodiments of the present invention, the triggering event can comprise a first outgoing call of the day and the like.Irrespective of how execution of step350is triggered, in some non-limiting embodiments of the present invention, the ATA120can transmit the indication of the access device identifier to the provisioning server145. Specifically, the ATA120can transmit the indication of the access device identifier stored in the ARP mapping and the VoIP endpoint identifier in substantially the same way as described above in reference to step310.In alternative non-limiting embodiments of the present invention, the provisioning server145can request the access device (which in this non-limiting scenario can be embodied in the aforementioned access multiplexer106) to transmit the indication of the access device identifier (which in this non-limiting scenario can be embodied in a MAC address of the aforementioned port106a; a logical link identifier associated with the logical link defined for the physical connection108or even an identifier of the physical connection108itself, if one is available).Yet in an alternative embodiment of the present invention, the provisioning server145can receive the indication of the access device identifier from the NAS126. Specifically, the NAS126can transmit the indication of the access device identifier to the provisioning server145when assigning an IP address to the router112(or if no router112is present, to the ATA120or the VoIP phone116). In these non-limiting embodiments, the access device identifier can comprise an identifier of the port106A or the access multiplexer106, an identifier of the router114, an identifier of the modem110or the access device102.
Step360: Compare the Received Access Device Identifier with the Last Known Access Device IdentifierNext, the received access device identifier is compared with the last known access device identifier stored in the emergency address repository150in a record associated with the user of the ATA120. To that extent, the provisioning server145attempts to locate a record associated with the user of the ATA120.Specifically, the provisioning server145retrieves the VoIP endpoint identifier associated with the ATA120(such as, but not limited to, a telephone number, a SIP address, a MAC address and the like) received in step350and attempts to locate a record which contains a user identifier220that matches the VoIP endpoint identifier associated with the ATA120. If the provisioning server145fails to locate the record, the provisioning server145can execute an exception handling routine, such as, but not limited to, determining that the emergency address is not available or is not valid, generating a default emergency call treatment trigger (such as basic 911 emergency call treatment trigger) and the like. The purpose of the basic 911 emergency call treatment trigger will be explained in greater detail herein below.For the purposes of the non-limiting example being described herein below, it will be assumed that the provisioning server145has successfully located the record associated with the ATA120(i.e. the aforementioned record202). Once the provisioning server145is successful in locating the record (in the non-limiting example discussed herein, record202), the provisioning server145retrieves the unique access device identifier224, which contains the indication of the last known access device identifier.The provisioning server145then compares the access device identifier received in step350with the last known access device identifier maintained in the unique access device identifier224. If the two values match (i.e. the “Yes” branch of step360), the provisioning server145determines that the ATA120accesses the core packet-switched data network132through the same access device as the access device associated with the last known access device identifier. In other words, the provisioning server145determines that the user of the ATA120has not moved and, thus, determines that the emergency address (for example, the emergency address222) is valid360A.If, on the other hand, the two values do not match (i.e. the “No” branch of step360), the provisioning server145determines that the ATA120accesses the core packet-switched data network132through an access device different from the access device associated with the last known access device identifier. In other words, the provisioning server145determines that the user of the ATA120has moved and, thus, determines that the emergency address is not valid360B.
Step370: Determine Emergency Call TreatmentEquipped with the determination whether the emergency address is valid360A or the emergency address is not valid360B, the provisioning server145determines emergency call treatment at step370.

Emergency Address is Valid360AIf it has been determined that the emergency address is valid360A, the provisioning server145can create a so-called “enhanced 911 call treatment trigger”. The enhanced 911 call treatment trigger is indicative of the fact that the emergency address associated with the last known location (for example, the aforementioned emergency address222or an emergency address maintained at a different entity) is valid and, therefore, the emergency address can be used for determining emergency call routing and/or for forwarding to the PSAP to enable the PSAP to dispatch an emergency response unit to the emergency address. The enhanced 911 call treatment trigger can be then transmitted to the VoIP endpoint or to the network element140.In an alternative non-limiting embodiment of the present invention, the record202may contain a routing key to be used for routing the emergency call. In these non-limiting embodiments of the present invention, if it is determined that the emergency address is valid360A, the routing key maintained in the record202can be retrieved and the emergency call can be handled in accordance with the routing key. Methods for using such a routing key are described in the U.S. patent application assigned to the applicant entitled “EMERGENCY CALL HANDLING IN A VOICE-OVER-PACKET ENVIRONMENT”, bearing an application Ser. No. 10/986,365 filed on Nov. 12, 2004, the content of which is incorporated herein by reference in its entirety.

Emergency Address is not Valid360BIf it has been determined that the emergency address is not valid360B, the provisioning server145can create a so-called “basic 911 call treatment trigger”. The basic 911 call treatment trigger is indicative of the fact that the emergency address associated with the last known location (for example, the aforementioned emergency address222or an emergency address maintained in a different entity) is not valid and, therefore, the emergency address should not be used for determining emergency call routing and/or for forwarding to the PSAP. Put another way, any emergency call originated by the user of the ATA120should be subjected to the basic 911 call treatment, such as forwarding to a central answering point and the like. The basic 911 call treatment trigger can be then transmitted to the ATA120or to the network element140.In some non-limiting embodiments of the present invention, the provisioning server145can trigger an update routine. The update routine is to enable updating the information maintained in the emergency address222. In case that the emergency address222is updated by the user of the ATA120, the provisioning server145can convey a reminder to the user of the ATA120, for example by calling the user of the ATA120, sending an e-mail reminder, sending an SMS reminder, sending a reminder by mail and the like. In some non-limiting embodiments of the present invention, the user of the ATA120can log into a web portal (not depicted) and, once properly authenticated, can indicate that he or she has moved. The user can be authenticated by providing an account number, a SIP address, a MAC address of the VoIP endpoint or any other suitable identifier. The web portal can then trigger a record update routine and, particularly, the web portal can transmit a message to the provisioning server145to trigger the provisioning server to delete a record associated with the ATA120(i.e. the aforementioned record202). The user can then perform a powering cycle, i.e. power off and power on the ATA120. By performing the power cycle, the user triggers execution of the aforementioned steps310-330which results in an updated record associated with the ATA120with updated access device identifier being stored emergency address repository510. It should be noted that any other triggering event described above can be used to trigger the creation of the updated record associated with the ATA120.In case that the emergency address222is updated by an auto-discover routine, the provisioning server145can trigger such an auto-discovery routine.

Given steps350to370, which can be jointly described as verification steps, the provisioning server145has verified validity of the emergency address associated with the VoIP endpoint and determined the emergency call treatment based on whether the emergency address is valid or not.

In an alternative non-limiting embodiment of the above-described method, as depicted inFIG. 3C, verifying steps350C-370C can be executed by the network element140. Execution of these steps by the network element140is substantially similar to the execution of steps350-370by the provisioning server145, as described above. Specific non-limiting differences are discussed below.

Step350CStep350C can be triggered and performed in substantially the same way as described above in relation to step350. For example, the triggering event in these non-limiting embodiments can be manifested in the user of the ATA120indicating his or her desire to initiate an outgoing call, for example, by dialing a destination directory number. In some embodiments of the present invention, the method is only responsive to a particular type of the outgoing call, such as, but not limited to, an emergency call. In other non-limiting embodiments, the method is responsive to any types of the requests for establishment of a communication session. It should be noted that various alternatives for the triggering event contemplated above in respect to step350are also applicable to implementation of step350C.

Step360CIn order to execute this step, the network element140can contact the aforementioned emergency address repository150(whether directly, as is the case in the infrastructure depicted inFIG. 1Cor via the provisioning server145using SOAP or any other suitable protocol, as is the case in the infrastructures depicted inFIGS. 1A and 1B) to locate and retrieve the content of the record202.It will be recalled that in some non-limiting embodiments of the present invention, the functionality of the network element140, the provisioning server145and the emergency address database150can be integrated into a single device (i.e. the aforementioned combined apparatus190). In these non-limiting embodiments, the network element140can execute a database look-up into the local emergency address repository150.

Step370COnce the network element140determines whether the enhanced 911 call treatment trigger or the basic 911 call treatment trigger should apply, the network element140can either:(i) immediately act on the trigger (especially in scenario, whereby the verifying steps are triggered by the user of the ATA120placing an emergency call);(ii) store the appropriate trigger in a database (not depicted);(iii) transmit the appropriate trigger to the ATA120;(iv) transmit the appropriate trigger to the provisioning server145.

Yet in other non-limiting embodiments, the execution of steps350-370or350C-370C can be split between various entities of the infrastructure ofFIGS. 1,1A and1B. For example, step350C can be implemented by the network element140, while steps360C-370C can be performed by the provisioning server145.

Even though the above description has primarily been based on examples of verifying validity of an emergency address for the purposes of delivering emergency response services, it should be noted that the teachings presented herein can be equally used for verifying validity of a service address for the purposes of delivering other types of location-based services, such as non-emergency location based services.

Consider now a customer services call being originated from the user of the ATA120. When the customer services call is received at the network element140, the network element can execute the above-described verification steps in order to determine if the service address associated with the user of the ATA120is valid or, in other words, determine if the user of the ATA120has moved his or her ATA120.

If the network element140determines that the service address is valid or, in other words, that the user of the ATA has not moved, the network element140can trigger execution of one or more of the following actions:a) determine special offers (such as, but not limited to, discounts, promotions, etc.) currently available in the geographic area associated with the stored service address;b) automatically determine language preferences (e.g., French for calls originated from locations in the province of Quebec, Spanish for calls originated from locations in a certain neighbourhood or country, etc.);c) perform a network test, if other users in the same geographic area have experienced or reported issues with network connectivity.

If the network element140determines that the service address is no longer valid or, in other words, that the user of the ATA120has moved, the network element140can transmit an indication of the user of the ATA120having moved to a customer services representative, who can take one or more of the following actions:a) solicit from the user of the ATA120the new service address and update the service address;b) update the user of the ATA120on the special offers available in the new geographic area associated with the updated service address;c) perform network tests on the connection or review other settings or potential problems specific to the new geographical area.

Even though the foregoing description has used an example of a VoIP endpoint for illustration purposes, it should be understood that it was not intended to be limiting in any sense. Generally speaking, the teachings of the embodiments of the present invention can be applied for verifying validity of location information for the purposes of delivering SIP-based services (such as voice calls over packet-switched networks, instant messaging and the like) or location information for the purposes of services delivered to endpoints in a packet-switched network in general.

Those skilled in the art will appreciate that certain functionality of the NAS126, emergency address repository150and/or other elements of the infrastructure described herein may be implemented as pre-programmed hardware or firmware elements (e.g., application specific integrated circuits (ASICs), electrically erasable programmable read-only memories (EEPROMs), etc.), or other related components. In other embodiments, certain portions of the NAS126, emergency address repository150and/or other elements may be implemented as an arithmetic and logic unit (ALU) having access to a code memory (not shown) which stores program instructions for the operation of the ALU. The program instructions could be stored on a medium which is fixed, tangible and readable directly by the NAS126, emergency address repository150and/or other elements, (e.g., removable diskette, CD-ROM, ROM, fixed disk, USB drive), or the program instructions could be stored remotely but transmittable to the NAS126, the emergency address repository150and/or other elements via a modem or other interface device.

Persons skilled in the art will appreciate that there are yet more alternative implementations and modifications possible for implementing the present invention, and that the above implementations and examples are only illustrations of one or more embodiments of the present invention. The scope of the invention, therefore, is only to be limited by the claims appended hereto.