1. Field of the Invention
This invention relates generally to telecommunication. More particularly, it relates to location based services for the provision of E-9-1-1 emergency services using Voice Over Internet Protocol (VoIP) protocols and architectures.
2. Background of the Related Art
911 is a phone number widely recognized in North America as an emergency phone number that is used to contact emergency dispatch personnel. Enhanced 911 (E911) is defined by the transmission of callback number and location information. E911 may be implemented for landline, cellular and/or VoIP.
A Public Service Answering Point (PSAP) is a dispatch office that receives 9-1-1 calls from the public. A PSAP may be a local, fire or police department, an ambulance service or a regional office covering all services. A 9-1-1 (“911”) service becomes E-9-1-1 (“E911”) when automatic number identification and automatic location information related to the call is provided to the 911 operator.
Voice-Over-Internet Protocol (VoIP) is a technology that emulates a traditional phone call, but instead of using a circuit based system such as the telephone network, it utilizes packetized data transmission techniques most notably implemented in the Internet. 911 calls made using VoIP technology must reach the correct PSAP, but there currently is no uniform interface to the various PSAPs for call delivery because the technology for connecting calls varies. For instance, some PSAPs are Internet Protocol (IP) capable. Some PSAPs are accessed via ordinary Public Switched Telephone Network (PSTN) telephone lines. Some PSAPs are accessed through selective routing such as direct trunks. There is no uniformity among the thousands of different PSAPs.
Moreover, some Public Safety Access Points (PSAPs) are not enhanced, and thus do not receive the callback or location information at all from any phone; landline, cellular or VoIP.
The existing E911 infrastructure is built upon copper wire line voice technology and is not fully compatible with VoIP. Given VoIP technology, there are at least three VoIP scenarios that require E911 service:
In the current state of technology, VoIP 911 call-routing relies on a VoIP Positioning Center (VPC) to receive VoIP 911 calls, determine the location of the VoIP caller (through prior location provisioning, or passing location with call signaling), determine the correct PSAP for that location and determine how that PSAP can receive VoIP calls (e.g. over PSTN, over Selective Router, or over VoIP). Additionally, the VPC is responsible for interaction with the PSAP's ALI, handling the various ALI protocols. (ALI is a database that relates a specific telephone number to an address. This database accepts a PSAP query with a telephone number and responds with an address. In the case of an Emergency Services Query Key (ESQK), the ALI database steers the query to the appropriate VPC and steers the response back to the PSAP. An ESQK is a digit string that uniquely identifies an ongoing emergency services call and is used to correlate the emergency services call with the associated data messages. It may also identify an emergency services zone and may be used to route the call through the network. Similar to an Emergency Services Routing Key (ESRK) in wireless E9-1-1 networks.) A VoIP Positioning Center is acting as a “Swiss Army Knife” of VoIP Emergency Service.
Moreover, there is complexity in public access to Public Safety Answering Points due to lack of a Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) for all PSAPs. (SIP is the IP-based protocol defined in IETF RFCs 3261 and 2543. SIP is one of two dominant protocols used by the VoIP industry. URI is the addressing technology for identifying resources on the Internet or a private intranet. URIs were originally defined as two types: Uniform Resource Locators (URLs) which are addresses with network location, and Uniform Resource Names (URNs) which are persistent names that are address independent. Today, a URI is defined by its purpose rather than the URL vs. URN classification.) Some PSAPs are accessed only by conventional telephone line, others only by direct telephone trunk lines. Not all PSAPs are accessible via the Internet.
In particular, as shown in
In particular, as shown in
A respective location information server (LIS) 108 services each of the VPCs 106. The LIS 108 is responsible for storing and providing access to the subscriber location information needed for E9-1-1 call processing (as defined by the NENA VoIP Location Working Group).
A conventional VoIP Positioning Center (VPC) 106 is a system that attempts to determine the appropriate or correct PSAP 114 that a VoIP emergency E911 call should be routed to based on the VoIP subscriber's position. The conventional VPC 106 also returns associated routing instructions to the VoIP network. The conventional VPC 106 additionally provides the caller's location and the callback number to the relevant PSAP through the automatic location identifier (ALI) (The ALI is a database that accepts a PSAP query, and using that relates a specific telephone number to a street address. In the case of an Emergency Services Query Key (ESQK), the ALI database steers the query to the appropriate VPC and steers the response back to the PSAP. An ALI is typically owned by a LEC or a PSAP.)
Further as shown in
In a first scenario, the VPC 106 passes the 9-1-1 call to the PSAP 114a using an INVITE telephone number message, via a media gateway 110 that translates between the IP protocol of the INVITE message and a telephone line interface, and interfaces with the public switched telephone network (PSTN) 112.
In a second scenario, the VPC 106 passes the 9-1-1 call to the PSAP 114b using an INVITE S/R message, via an ESGW 120 and selective router 122. In this scenario, the selective router 122 is connected to the relevant PSAP 114b via direct trunks.
In a third scenario, the VPC 106 passes the 9-1-1 call to the PSAP 114c using an INVITE PSAP message, via IP, to the PSAP 114c.
In the second and third scenario, the ALI 126 must be inter-connected with each VPC 106 (a,b,c). Furthermore, each VPC is burdened with supporting all the various ALI protocols: ve2, e2, PAM, legacy NENA, etc.
Thus, each VoIP service provider requires its own VPC 106 comprising multiple elements (route determination module 404, call delivery module 406, and provisioning list 408). Conventional VPCs used by any given VoIP service provider are required to handle many aspects of routing an emergency VoIP E911 call to the relevant PSAP and providing ALI information to the PSAP, creating an expensive and highly complex architecture all in one place. The complexity is compounded by the fact that many (if not most) PSAPs are not capable of being accessed by an emergency VoIP E911 call via Internet Protocol (IP). Moreover, each VoIP service provider, of which there are many, must implement their own VPC, causing wasteful inefficiencies in the system architecture as appreciated by the present inventors. This makes the conventional VPC difficult to manage since it accomplishes not only route determination using the route determination module 404, but also delivery of calls using a call delivery module 406, and additionally serves to maintain a provisioning list 408 (i.e., interface type) for accessing each PSAP. This in turn causes great complexity in public access to PSAPs, depending upon various entities in the VoIP world to know the capabilities of each particular PSAP throughout the region, state, or even country.
There is a need for an architecture and methodology that both simplifies the complexity of a voice positioning center (VPC), and which also increases system efficiencies.
In accordance with the principles of the present invention, a voice over Internet Protocol (VoIP) emergency call is delivered to a public safety access point (PSAP) by determining a route of a VoIP emergency call. An INVITE message including a location object relating to a caller of said VoIP emergency call is passed over a connection utilizing Session Initiation Protocol (SIP). Upon receipt of the passed INVITE message, a provisioning is looked up of the PSAP for accessing the PSAP with the VoIP emergency call. The INVITE message is delivered to the PSAP using an appropriate interface designated by the looked up access technology provisioned.
In accordance with the principles of the invention, a new VoIP element called a “PSAP Proxy” is introduced. The PSAP Proxy's role in VoIP E-9-1-1 is to represent the PSAP as a VoIP entity to the VoIP Service Provider. For the PSAP the PSAP Proxy represents ALI delivery over IP to the IP capable PSAP and a common protocol platform for access to traditional ALI databases.
From the VoIP networks' perspective, the PSAP Proxy makes it appear as if each PSAP is VoIP enabled. The PSAP Proxy takes over the burden from the VPC of delivering the call to the PSAP via whatever technology is required to route calls to the PSAP (e.g. PSTN, dedicated trunks, VoIP).
From the VPC ALI networks' perspective, the PSAP Proxy makes it appear as if each PSAP is ve2 enabled (ve2 is the current NENA VoIP standard ALI interface). The PSAP Proxy takes over the burden from the VPC of delivering ALI information to the PSAP via whatever technology or protocol the PSAP's ALI requires.
The present invention implements VoIP functions of call delivery and content delivery (e.g, ALI) in a separate network entity referred to herein as a “PSAP Proxy”. A PSAP Proxy is a unit that handles delivery of a VoIP call to a correct PSAP. A PSAP Proxy also provides VoIP call ALI information to the PSAP. The PSAP Proxy is separately IP addressable by multiple different VPCs, potentially from multiple VoIP service providers, providing greater network simplicity and efficiency than is provided by conventional network architectures.
When a Voice Over Internet Protocol (VoIP) caller dials 9-1-1, the VoIP Service Provider's Soft Switch sends the VoIP call to a VPC for addition of a Location Object (LO). Then, based on the position of the caller determined by the location object, the VPC selects the correct PSAP Proxy and passes the E911 emergency call, with location object, over an Internet Protocol connection to the correct PSAP Proxy. The PSAP proxy, accepting an IP input from the VPC, handles delivery of the emergency VoIP call to the PSAP using the best available technology to interconnect with the PSAP. In this way, the PSAP Proxy in accordance with the present invention makes all PSAPs appear IP capable to the VoIP service providers, and provides a SIP URI for all PSAPs. The PSAP Proxy communicates with any other components or entities required to process the call (e.g., Selective Router, PSTN, PSAP). When the PSAP requests ALI information from the PSAP Proxy the PSAP Proxy will handle protocol conversions between the existing ALI protocols (ve2, e2, e2+, PAM, legacy NENA, etc.) to NENA ve2 or NENA e2 used to communicate with a VPC.
The PSAP Proxy technique as disclosed and taught herein provides VoIP service providers and VoIP positioning centers with the ability to deliver calls and automatic location identifier (ALI) information to PSAPs with the PSAP Proxy.
Moreover, a PSAP proxy in accordance with the principles of the present invention allows local exchange carriers (LECs) and Competitive Local Exchange Carriers (CLECs) the ability to collect inbound calls for routing via their public switched telephone network (PSTN) and emergency service network to the PSAPs.
In particular, as shown in
Importantly, in accordance with the present invention, the conventional VoIP positioning center (VPC) is divided into a smaller, more efficient, less complex VPC 106a, 106b, 106c (collectively referred to herein as 106) capable only of route determination 508 (represented as 508a, 508b, 508c).
Also importantly, the invention implements the call delivery module 502 and provisioning list 504 remote from the VPC 106 in what is referred to herein as a “PSAP Proxy”. The VPCs 106 communicate with the PSAP Proxy 100 via an IP interface connected to a plurality of VPC modules. In this way, call delivery and PSAP provisioning lookup functions can be consolidated into a common location for use by a plurality of VoIP service providers.
The PSAP Proxy can be located within a VoIP service providers network, or because it is remote from the route determination module 508 of the VPC 106, the PSAP Proxy can be implemented as a commercial service provided by a third party to multiple VoIP service providers.
The VoIP positioning center (VPC) 106 selects the correct PSAP Proxy, based on a simple lookup of location object information with its designated PSAP. The VPC 106 then transmits the VoIP E911 call, with location object (LO) added, to the correct PSAP Proxy. Only one PSAP Proxy 100 is shown in
The PSAP Proxy 100 makes all PSAPs 114 appear IP capable to VoIP service providers (VSPs), and provides a Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) for all PSAPs 114.
The PSAP Proxy 100 communicates with any other components or entities required to process the call (e.g., ESGW, Selective Router, PSTN, PSAP).
In particular, as shown in
As shown in
Further as shown in
In a first scenario, the PSAP Proxy 100 passes the 9-1-1 call with location object added to the PSAP 114a using an INVITE telephone number message, via a media gateway 110 that translates between the IP protocol of the INVITE message and a telephone line interface, and interfaces with the public switched telephone network (PSTN) 112. In such case, the PSAP Proxy 100 serves as a web service automatic location identifier (ALI).
In a second scenario, the PSAP proxy 100 passes the 9-1-1 call with location object added to the PSAP 114b using an INVITE S/R message, via a ESGW 120 and selective router 122. In this scenario, the selective router 122 is connected to the relevant PSAP 114b via direct trunks.
In a third scenario, the PSAP proxy 100 passes the 9-1-1 call with location object added to the PSAP 114c using an INVITE PSAP [LO] message, via IP, to the PSAP proxy 114c. In such case, a web service for additional content delivery may be included such that the PSAP 114c may access the web service. Also, ALI data may be passed over the connection i3 between the PSAP proxy 100 and the PSAP 114c.
In all cases shown in
The PSAP proxy 100 then converts the INVITE message to the appropriate technology and protocol and sends to the PSAP along with the pertinent information (including, in some cases, the location object for IP-enabled PSAPs).
Currently there are three types of call access to a PSAP by an incoming emergency E911 VoIP call. Each PSAP 114 may have more than one type of call access: i1 type, i2 type, and/or i3 type.
i1 type call access for a PSAP is a common PSTN telephone line interface. i2 type call access for a PSAP relates to the use of a selective router/direct telephone trunk line. i3 type call access for a PSAP relates to a VoIP enabled PSAP.
Entry 401 gives an example associating a given PSAP, this one identified with a SIP/URI such as 911@kirkland.wa.gov, with a call access type of i1 (PSTN). Of course, PSAPs can be identified in other unique ways, such as by an assigned number as exemplified in entry 403. Moreover, as exemplified in entry 402, the PSAP might be provisioned with an i2 type of call access (i.e., selective router/direct trunk). Exemplified in entries 403-404 are PSAPs that are provisioned with i3 type call access, which are Internet Protocol (IP) interfaces that are VoIP enabled.
Most preferably, the interface between the VPC 106 and the PSAP Proxy 100 is an Internet Protocol (IP) connection such as the Internet. However, any open API may be implemented.
The PSAP Proxy communicates with any other components or entities required to process the call (e.g., ALI, Selective Router, PSTN, PSAP, VPC).
Advantages of the present invention include that it can be used to simplify the introduction or adoption of future technologies system-wide or on a PSAP by PSAP basis, by incorporating additional logic/capability in the PSAP Proxy rather than requiring changes by individual PSAPs, local exchange carriers (LECs), or VoIP service providers (VSPs). (The LEC is the wireline carrier for local calls.) The present invention moves call delivery outside the VoIP positioning center (VPC), simplifying the VPC and increasing flexibility of the system.
While the invention has been described with reference to the exemplary embodiments thereof, those skilled in the art will be able to make various modifications to the described embodiments of the invention without departing from the true spirit and scope of the invention.
An early and favorable action of the merits is earnestly solicited.
Number | Date | Country | |
---|---|---|---|
60728326 | Oct 2005 | US |