WO2014018387A2

WO2014018387A2 - Sip initiated legacy call to an ng911 esinet

Info

Publication number: WO2014018387A2
Application number: PCT/US2013/051237
Authority: WO
Inventors: Donald Leroy MITCHELL; Roger S. Marshall; Andrew Singer; Firdaus Aryana
Original assignee: Telecommunication Systems, Inc.
Priority date: 2012-07-23
Filing date: 2013-07-19
Publication date: 2014-01-30
Also published as: WO2014018387A3; EP2875630A2

Abstract

An i3 proxy module is provided within a 911 service provider network (e.g., at the VoIP positioning center) to respond to a VoIP i2 SIP INVITE destined for a PSAP having i3 architecture. The i3 proxy module responds to the VoIP i2 SIP INVITE by generating a VoIP i3 SIP INVITE with PIDF-LO and routing the same to the i3 emergency services routing proxy (ESRP) within the i3 network. Thus, an i3 SIP INVITE with PIDF-LO is sent from an i3 proxy module associated with an i2-based VoIP positioning center (VPC). Thus, legacy originating service provider (OSP) carrier networks are now enabled to route an emergency call to a PSAP having an i3 ESInet architecture.

Description

SIP INITIATED LEGACY CALL TO AN NG911 ESINET

This application claims priority from U.S. Prov. No. 61/674,614, filed July 23, 2012, entitled "SIP INITIATED LEGACY CALL TO AN NG91 1 ESINET", the entirety of which is explicitly incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to wireless telecommunications, and more particularly to public safety.

2. Background of the Related Art

Voice Over Internet Protocol (VoIP) is becoming the predominant technology used in the telecommunications industry. As VoIP becomes more widely adopted, E9-1 -1 calls will increasingly originate from VoIP users. Some VoIP telecommunications service provider networks, however, are not natively compatible with the existing E9-1-1 infrastructure.

The National Emergency Number Association ("NENA") has developed an interim standard for what is known as "i2 architecture" to support the interconnection of VoIP domains with the existing Emergency Services Network infrastructure in support of the migration toward end-to-end emergency calling over the VoIP networks between callers and Public Safety Answering Points (PSAPs). This standard is described in detail in NENA 08-001 , Issue 1 December 6, 2005, which is explicitly incorporated herein by reference.

One goal of the i2 architecture is to make no changes that will affect the PSAP by minimizing changes in the existing emergency services provider infrastructure. The call setup signaling in the IP domain in i2 architecture uses Session Initiation Protocol (SIP).

i2 architecture supports the receipt of both civic location information as well as geodetic location information as input to emergency call routing decisions. This enables the i2 architecture to route emergency calls regardless of the format of the location provided by the source. It is expected that the location provided by the originating network and chosen for routing purposes by the VoIP positioning center (VPC) is the location that is provided to the PSAP. The location provided to the PSAP is in the same form (civic or geo) that was received.

Location information may, in general, be presented by the VoIP end point by one of two methods: civic location information, or geodetic location information. Civic location is required for non-wireless fixed and nomadic types of service. Geodetic location information optionally may be sent as supplemental information in addition to the civic location.

Civic location presented to the PSAP is expected to be MSAG validated. A valid emergency services authority (VESA) registry is used to provide certification of entities that are authorized to query for and view location information for any given emergency call instance it is requested to process.

Fig. 2 shows a conventional SIP call in a conventional i2 network. In particular, as shown in step 1 of Fig. 2, a VoIP device initiates an emergency call within a given originating service provider's carrier network 210.

In response to the incoming IP call, the relevant call server 212 within the carrier network 210 then generates a VoIP i2 SIP INVITE (v6).

The VoIP i2 SIP INVITE (v6) is routed to a VoIP positioning center (VPC) 222 in a 911 service provider's network 220.

In step 2, a response (i.e., a VoIP i2 SIP INVITE (v4)) is passed from the VoIP positioning center (VPC) 222 back to the call server 212 in the carrier network 210. The response VoIP i2 SIP INVITE (v4) uses the emergency services gateway route identifier (ESGWRI) to select the appropriate emergency services gateway (ESGW) 252. (The ESGWRI is used by the call server 212 to route an emergency call to the correct emergency services gateway (ESGW) 252. The ESGWRI is used by the ESGW 252 to select the desired path to the appropriate selective router 162 for the emergency call.

In step 3, the call server 212 sends a VoIP i2 SIP INVITE (4) to the appropriate Emergency Services Gateway (ESGW) 252. In step 4, real-time transport protocol (RTP) voice from the emergency-calling device is connected to the appropriate public safety answering point (PSAP) via the Emergency Services Gateway (ESGW) 252.

In step 5, the Emergency Services Gateway (ESGW) 252 passes time-division multiplex (TDM) (or other appropriate format) voice, to the appropriate selective router 162 in a Local Exchange Carrier ("LEC") Network 160 servicing a relevant PSAP.

More recently, NENA has developed an all-Internet Protocol solution called "i3 architecture", (or Next Generation NG9-1-1) solution. In i3 architecture, all calls entering the emergency services IP network ("ESInet") are SIP based. Gateways, if needed, are outside of, or on the edge of, the ESInet. IP services that are not native SIP based, have protocol interworking to SIP prior to being presented to the ESInet. All calls entering the ESInet normally have location information in the signaling with the call, though the location may be coarse, e.g., cell site/sector.

The i3 architecture defines a legacy network gateway (LNG) to interface between a carrier's legacy network, and the ESInet. This is intended to give carriers time to implement the hardware and facilities necessary to upgrade to an i3 architecture. The i3 architecture also defines a legacy PSAP Gateway (LPG) to interface at the egress end of an ESInet, between the ESInet and a legacy PSAP via CAMA trunking interconnections. The i3 architecture also defines a Legacy Selective Router Gateway (LSRG) at the egress end of an ESInet, between the ESInet and a legacy Selective Router element. Both of these gateways are in order to support the origination of an emergency call through the ESInet to a legacy PSAP, as well as the transfer of an emergency call between an i3 PSAP and a legacy PSAP. These paths represent transitional approaches to support older PSAP equipment.

Conventional solutions presume that carrier networks will upgrade to an all-IP i3 architecture before PSAPs. The present inventors have appreciated that there is no upgrade path, or solution, to route emergency calls between an older i2 architecture carrier network and a newer, i3 Emergency Services IP Network (ESInet) architecture PSAP. Thus, the inventors herein have appreciated that there is a problem when an originating service provider network with an older i2 architecture seeks to route an emergency call to an upgraded PSAP converted to an i3 ESInet.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the present invention will become apparent to those skilled in the art from the following description with reference to the drawings, in which:

Fig. 1 shows a SIP initiated legacy emergency call routed to a Next

Generation 9-1 -1 ("NG91 1 ") Emergency Services IP Network ("ESInet"), in accordance with the principles of the present invention.

Fig. 2 shows a conventional SIP call in a conventional i2 network. DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The present inventors have realized that originating service providers (OSPs) using the NENA i2 standard for routing emergency calls to a PSAP, may need to deliver the emergency calls in a different manner from the VoIP Positioning Center (VPC) if/when the PSAP converts to an i3 ESInet. To this end, the present invention provides the creation of an i3 proxy module 100 within a 91 1 service provider network (e.g., at the VoIP positioning center 122) to respond to a VoIP i2 SIP INVITE destined for a PSAP having i3 architecture.

In accordance with the principles of the invention, the i3 proxy module 100 responds to the VoIP i2 SIP INVITE by generating a VoIP i3 3261 SIP INVITE with PIDF-LO and routing the same to the i3 emergency services routing proxy (ESRP) 134 within the i3 network 130. Thus, in accordance with the invention, an i3 SIP INVITE with PIDF-LO is sent from an i3 proxy module 100 associated with an i2-based VoIP positioning center (VPC) 122. Thus, legacy originating service provider (OSP) carrier networks are now enabled to route an emergency call to a PSAP having an i3 ESInet architecture. Fig. 1 shows a SIP initiated legacy emergency call routed to a Next Generation 9-1-1 ("NG911") Emergency Services IP Network ("ESInet"), in accordance with the principles of the present invention.

In particular, as shown in Fig. 1 , an originating service provider (OSP) carrier network 110 includes a call server 112. A 911 service provider network 120 still including older i2 architecture includes a VoIP positioning center 122, and an associated i3 proxy module 100. The i3 proxy module 100 detects receipt of an incoming VoIP i2 SIP INVITE from an emergency call intended to be routed to a public safety answering point (PSAP) within an upgraded emergency services IP network (ESInet) 130 operating with an i3-compatible architecture. The i3-architecture ESInet 130 includes an i3 media anchor module 132 (e.g., RTP voice, text, video, etc.), and an i3 Emergency Services Routing Proxy ("ESRP") 134.

In operation, in step 1 , an incoming emergency call which requires routing is serviced by the call server 112 in the originating service provider's carrier network 110. In response, the call server 112 generates a VoIP i2 SIP INVITE (v6) message destined for the VoIP positioning center (VPC) 122 in the legacy i2 architecture-based 911 service provider network 120.

In step 2, the i3 Proxy module 100 associated with the VoIP positioning center (VPC) 122 receives the incoming VoIP i2 SIP INVITE, and determines that the destination of the emergency call is serviced by an i3 based (or i3-compatible) Emergency Services Network (ESInet) 130.

In step 3, the i3 proxy module 100 associated with the VoIP positioning center (VPC) 122 creates a VoIP i3 3261 SIP INVITE with a presence information data format with location object (PIDF-LO) to "forward" the emergency call to the intended PSAP via the appropriate Emergency Services IP Network ("ESInet"). The VoIP i3 3261 SIP INVITE includes location elements in a Presence Information Data Format with Location Object (PIDF-LO), as well as any other necessary elements, as indicated in the NENA 08-003v1 NENA i3 Specification. In this inventive way the older, i2 architecture 911 service provider network 120 appears to be an upgraded i3 architecture to the receiving i3 ESInet 130, though in actuality it is primarily an i2 architecture with an inventive i3 proxy module 100 added.

In step 4, the emergency call including, e.g., RTP voice or other media (e.g., text, video, etc.) is facilitated between the VoIP device initiating the emergency call, via the call server 112 at the originating service provider carrier network 110, and the i3 media anchor module 132 at the assigned i3 ESInet 130.

The present invention enables a carrier merely to replace their emergency services gateway (ESGW) connectivity when the carrier is requested to connect to an i3 ESInet.

The invention manages location delivery by (a) Value - PIDF-LO or

(b) Reference, as requested by the jurisdiction. The invention can pass all voice.

Preferably LVF validation is performed for addresses in the relevant location information server ("LIS") when an originating service provider carrier network

110 is required to connect to an i3 network 130. Preferably state run LIS updates are managed (e.g., for Reverse 9-1-1), and continues to provide call information database (CIDB) functionality. Value-added services may be provided via an extended integrated database ("XIDB").

The invention relates to emergency services, and any method which provides mobile subscriber information based upon credentials and variables.

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.

Claims

CLAIMS What is claimed is:

1. A method to proxy i3 architecture within a non-i3 architecture network, comprising:

receiving a non-i3 architecture session Internet protocol (SIP)

INVITE message;

generating an i3 SIP INVITE message with PIDF-LO or Reference

Identifier; and

routing said generated i3 SIP INVITE message with PIDF-LO or Reference Identifier to an appropriate Emergency Services IP Network (ESInet).

2. The method to proxy i3 architecture within a non-i3 architecture network according to claim 1 , wherein:

said non-i3 architecture is \2 architecture.

3. The method to proxy i3 architecture within a non-i3 architecture network according to claim 1 , further comprising:

routing said generated i3 SIP INVITE message to an i3 emergency services routing proxy (ESRP) within said ESInet.

4. The method to proxy i3 architecture within a non-i3 architecture network according to claim 1 , wherein:

said SIP INVITE message is associated with an incoming emergency call.

5. The method to proxy i3 architecture within a non-i3 architecture network according to claim 1 , wherein:

said SIP INVITE message is an i3-architecture sourced SIP INVITE message.

6. The method to proxy i3 architecture within a non-i3 architecture network according to claim 1 , wherein:

said SIP INVITE message is a Voice over Internet Protocol (VoIP) i3 SIP INVITE message.

7. The method to proxy i3 architecture within a non-i3 architecture network according to claim 1 , wherein:

said i3 SIP INVITE message with PIDF-LO is sent from an i3 proxy module associated with an i2-based VoIP positioning center (VPC).

8. Apparatus to proxy i3 architecture within a non-i3 architecture network, comprising:

means for receiving a non-i3 architecture session Internet protocol (SIP) INVITE message;

means for generating an i3 SIP INVITE message with PIDF-LO; and

means for routing said generated i3 SIP INVITE message with PIDF-LO or Reference Identifier to an appropriate Emergency Services IP Network (ESInet).

9. The apparatus to proxy i3 architecture within a non-i3 architecture network according to claim 8, wherein:

said non-i3 architecture is i2 architecture.

10. The apparatus to proxy i3 architecture within a non-i3 architecture network according to claim 8, further comprising:

means for routing said generated i3 SIP INVITE message to an i3 emergency services routing proxy (ESRP) within said ESInet.

11. The apparatus to proxy i3 architecture within a non-i3 architecture network according to claim 8, wherein:

said SIP INVITE message is associated with an incoming emergency call.

12. The apparatus to proxy i3 architecture within a non-i3 architecture network according to claim 8, wherein:

said SIP INVITE message is an i3-architecture sourced SIP INVITE message.

13. The apparatus to proxy i3 architecture within a non-i3 architecture network according to claim 8, wherein:

14. The apparatus to proxy i3 architecture within a non-i3 architecture network according to claim 8, wherein:

said i3 SIP INVITE message with PIDF-LO or Reference Identifier is sent from an i3 proxy module associated with an ι^'2-based VoIP positioning center (VPC).