V4 and V6 Interface of NENA i2 Architecture

Table Of Contents

Cisco BTS 10200 Softswitch Support for V6 and V4 Interfaces of NENA i2 Architecture Feature, Release 6.0.3

Contents

Overview

Functional Elements

Call Server

VoIP Positioning Center

Emergency Services Gateway

Routing Proxy

Data Objects

Emergency Services Routing Number

Emergency Services Query Key

Interface Definitions

V4 Interface

V6 Interface

Feature Operation

Basic Routing of Emergency Calls

BTS 10200 Softswitch as an ESGW

BTS 10200 Softswitch as a Call Server

BTS 10200 Softswitch as both Call Server and ESGW

Feature Constraints

Feature Provisioning

Billing Enhancements

Install and Upgrade Considerations

Additional References

Related Documents

Standards

Cisco BTS 10200 Softswitch Support for V6 and V4 Interfaces of NENA i2 Architecture Feature, Release 6.0.3

---

Last Updated: August 10, 2011

The Cisco BTS 10200 Softswitch supports the V6 and V4 interfaces as defined by the National Emergency Number Association's (NENA) Interim VoIP Architecture for Enhanced 911 Services (i2). These interfaces enable the BTS 10200 to route emergency calls originating from a subscriber endpoint in a VoIP network to the appropriate Public Safety Answering Point (PSAP).

The NENA standard for the i2 architecture recommends the support for interconnection between the VoIP network and the emergency services network to help route emergency calls between callers and PSAPs.

The service providers in the VoIP domain are required to be compliant with the NENA standard for the following reasons:

•For delivery of 911 calls to the proper PSAP.

•For providing a callback number or contact information to the PSAP.

•For providing the location of the caller to the PSAP.

•For providing direct IP connectivity to the PSAP.

Note This feature is based on the NENA Interim VoIP Architecture for Enhanced 9-1-1 Services (i2), NENA 08-001, Issue 1 December 6, 2005. For more information on the NENA architecture, see the website: www.nena.org.

For more information on PSAP and emergency services provided by the BTS 10200, see the Emergency Services (911) section in the Cisco BTS 10200 Softswitch Network and Subscriber Descriptions Guide.

Contents

•Overview

•Feature Operation

•Feature Constraints

•Feature Provisioning

•Billing Enhancements

•Install and Upgrade Considerations

•Additional References

Overview

This section covers the following topics:

•Functional Elements

•Data Objects

•Interface Definitions

Note The BTS 10200 performs the functions of a call server, or an Emergency Services Gateway (ESGW), or both.

Functional Elements

This section describes the functional elements in a NENA architecture.

Figure 1 illustrates the network elements and the signaling interfaces in the NENA architecture, and also shows how an emergency call is routed between the VoIP and the emergency service networks.

Figure 1 Network Elements and Signaling Interfaces in a NENA Architecture

Call Server

A call server is an entity in a private or public IP network that provides services to endpoints in an emergency caller's home domain. It interworks with Session Initiation Protocol (SIP) servers and other elements in an IP network that is used to support emergency services call routing.

The call server may use a SIP or VoIP signaling protocol within its own serving domain. When a VoIP endpoint initiates an emergency call in the IP domain, the location and callback information are sent to the call server through the interface between the endpoint and the call server.

VoIP Positioning Center

A VoIP Positioning Center (VPC) is an element that provides routing information to support the routing of VoIP emergency calls.

The VPC passes the Emergency Services Routing Number (ESRN), Emergency Services Query Key (ESQK), and the Last Routing Option (LRO) objects to the call server or the routing proxy in response to a request for routing information associated with the emergency call.

Emergency Services Gateway

An ESGW is an essential element in a NENA i2 solution that is needed to route emergency calls originating from VoIP endpoints. It is a signaling and media interworking point between the IP domain and the E-911 Selective Routers (SR). It uses Multi-Frequency (MF) or Signaling System 7 (SS7) signaling to route emergency calls towards the SR.

As an ESGW, the BTS 10200 uses the ESRN received from the proxy server to select an appropriate trunk group to route the call. Subsequently, if the trunk group is available, it proceeds to signal emergency call origination toward the corresponding SR. The BTS 10200 sends the ESRN (as the called number) and ESQK (as the Automatic Number Identification (ANI)) to the SR.

Routing Proxy

A routing proxy is an intermediary entity in a network that places requests on behalf of other clients. It interprets a request message and may rewrite specific parts of it before forwarding it. (Refer to IETF RFC 3261[5] for more information on the functions of a routing proxy.)

The routing proxy supports the SIP specification. The routing proxy interfaces the VPC using the V2 interface. The VPC provides the ESRN and ESQK, and the LRO, in a response defined by V2. The routing proxy then sends an invite with the ESRN and ESQK to the ESGW over the V4 interface.

Data Objects

The 911 data objects used in a NENA architecture are explained in the following sections:

Emergency Services Routing Number

The ESRN is used by the call server or the routing proxy to route an emergency call to the correct ESGW. The ESGW uses the ESRN to select the desired path to the appropriate SR for the call.

When an endpoint initiates an emergency call, the call server routes the invite to the routing proxy server. The routing proxy queries the VPC to obtain the ESRN and ESQK over the V2 interface. The VPC uses the location information to determine an ESRN for routing, and allocates an ESQK for the call.

The ESRN may be a ten-digit North American Numbering Plan (NANP) number.

Emergency Services Query Key

An ESQK is delivered to the E-911 SR as the calling number or ANI for the call to the PSAP. The ESQK is used by the SR as the key to the selective routing data associated with the call.

The ESRN and ESQK are returned over the V2 interface by the VPC in response to the query for routing information for the emergency call.

Interface Definitions

For the BTS 10200 to function as a call server or an ESGW, or both, the following interfaces are used while routing the emergency call between callers in the VoIP domain to an appropriate PSAP.

V4 Interface

A V4 interface is used to forward emergency calls to the ESGW. The routing proxy uses the ESRN returned from the VPC to forward calls to the appropriate ESGW and inserts ESRN and ESQK into the signaling message.

As an ESGW, BTS 10200 receives the emergency call routing information from the routing proxy on the V4 (SIP) interface. The BTS 10200 extracts the ESRN and ESQK information from the invite received from the routing proxy to setup a call towards the SRs. The ESGW can interface with SRs on Channel Associated Signaling (CAS), ISDN User Part (ISUP), or SIP interfaces.

Re-using the existing methods of routing, the BTS 10200 routes the inbound call received on the V4 interface towards the SR, by using the ESRN and ESQK.

V6 Interface

A V6 interface is defined as a SIP interface to a routing proxy. This interface is used by the call server to route the emergency call invites to the routing proxy.

Currently, BTS 10200 acts as a call server directly supporting V6 interface as mentioned in NENA i2 specification. For emergency calls to be routed on V6 interface, the DESTINATION table must contain a CALL_TYPE field with the value EMG in BTS 10200. Additionally, the ROUTE defined for the call should be associated with the SIP trunk group serving the V6 interface towards the routing server or the VPC.

Note If the EMG call type is not set, the BTS 10200 treats the call as a normal call, and does not assign a priority to it.

Note For more information on these interfaces, see the Interim VoIP Architecture For Enhanced 9-1-1 Services, NENA 08-001 document. This document is available at the website: www.nena.org.

Feature Operation

This section covers the following topics:

•Basic Routing of Emergency Calls

•BTS 10200 Softswitch as an ESGW

•BTS 10200 Softswitch as a Call Server

•BTS 10200 Softswitch as both Call Server and ESGW

Basic Routing of Emergency Calls

The following steps describe the basic call routing of VoIP emergency calls using the BTS 10200. A SIP endpoint is taken as an example.

---

Step 1 A SIP endpoint initiates an emergency call by sending the call initiation request and the callback information to the call server. The callback information identifies the number that can be dialed to reach the caller.

The SIP endpoint sends an invite message that includes the domain name in the Req-URI, and a tel-URI in the FROM header to indicate the callback information to be used.

Step 2 The call server receives the call initiation request. The invite of the call is routed on the V6 interface to an external routing server or VPC. The invite contains the following:

•The FROM header of the invite with the callback number or ANI of the caller.

•The TO and Req-URI have 911 digits (emergency number).

Step 3 The routing proxy forwards the request to the VPC over the V2 interface. The VPC receives the routing request containing an identifier of the emergency caller that can be mapped to an E.164 number (example, a tel-URI).

Step 4 The VPC receives the invite and derives ESRN and ESQK applicable for the call, and returns the invite back to the routing proxy. The routing proxy sends a new invite containing the ESRN and ESQK to the BTS 10200 Softswitch acting as ESGW on the V4 interface.

Step 5 The incoming invite to BTS 10200 Softswitch on the V4 interface has ESRN, ESQK in the following headers:

•Req-URI header has the ESRN.

•P-Asserted-ID header has the ESQK.

Note The BTS 10200 treats the call as an emergency call if ESRN received in the Req-URI of invite on V4 is part of EMERGENCY-NUMBER-LIST table.

Step 6 The BTS 10200 Softswitch uses the ESRN and determines the appropriate PSAP towards which the emergency call is to be routed. The BTS 10200 uses the existing routing method (dial-plan or carrier-based routing) to route the call based on the ESRN received.

---

BTS 10200 Softswitch as an ESGW

As an ESGW, the BTS 10200 uses the V4 interface to receive the ESRN and ESQK from the routing proxy. The ESGW uses the ESRN to select an outgoing trunk group to the appropriate SR by using the outgoing (SS7 or MF) signaling protocol. It includes the ESRN as the called number and the ESQK as the ANI to route the call towards the SR.

BTS 10200 Softswitch as a Call Server

As a call server, the BTS 10200 receives the call initiation request and sends a routing request to the routing proxy over the V6 interface. The VPC receives the routing request from the routing proxy having the necessary information to identify the emergency caller, such as callback information, and location of the caller.

BTS 10200 Softswitch as both Call Server and ESGW

When the BTS 10200 acts as a call server and ESGW, the routing proxy receives an invite from the V6 interface and sends out the invite on V4 interface after replacing the Req-URI with the ESRN and inserting the P-Asserted ID header having the ESQK.

The routing proxy is assumed to operate in the following manner:

•It does not modify the To-Header, Call-ID and Body fields of the incoming invite received from the NENA V6 interface before sending it out on V4 interface.

•It adds a new tag to the FROM header in the outbound invite on V4 interface.

The emergency call is treated as a SIP hair-pinned call based upon the value of Tag parameter in the FROM header.

Feature Constraints

This section lists the constraints of the feature:

•For emergency calls to be routed out on the V6 interface, the corresponding DESTINATION table CALL_TYPE field needs to have EMG value. Additionally, the corresponding route of the call should be associated with the SIP trunk group serving the V6 interface towards the routing server/VPC.

•For enabling incoming calls on the V4 interface SIP trunk, the value of the USE_PAI_HDR_FOR_ANI in SOFTSW-TG-PROFILE table must be Y.

•During routing failures (due to unavailability of resources, administrative or operational OOS situations) on a trunk group, the existing BTS 10200 Softswitch's alternate routing method is applicable, such as route advance, overflow DN.

•The feature does not support location information handling.

•The feature is based on the assumption that the security as specified by NENA i2 standard is realized by IPSec tunnel terminating on external nodes.

Feature Provisioning

This section explains how to provision the feature.

Note The commands shown in this section are only examples; you need to enter values that are appropriate for your network and service requirements. The CLI syntax allows you to use commands in uppercase or lowercase. It also allows you to enter hyphens (-) or underscores (_) interchangeably. (Exceptions, if any, are noted in the procedures.) For a complete list of tokens for each CLI table, as well as the allowed values, default values, and detailed descriptions for each token, see the Cisco BTS 10200 Softswitch CLI Database at this website: http://www.cisco.com/en/US/docs/voice_ip_comm/bts/6.0.3/BTS603_Mainpage.html

To provision the V6 and V4 interfaces in BTS 10200, do the following:

Command	Description
add softsw_tg_profile id=tg_profile-1; nena_i2_v4_v6_supp=Y; protocol_type=SIP; use_pai_hdr_for_ani=y;	The NENA_i2_V4_V6_SUPP token in the softswitch trunk group profile table specifies whether the softswitch trunk group will be used as NENA V4 or V6 interface.

Note When the NENA_i2_V4_V6_SUPP token is of the value Y, the USE_PAI_HDR_FOR_ANI token should also be set to Y.

Table 1 lists the new tokens added for the feature:

Table 1 New CLI Tokens

New Token Name	Table Name	Description	Default Value	Possible Values
NENA_i2_V4_V6_SUPP	SOFTSW_TG_PROFILE	Specifies whether the softswitch trunk group will be used as NENA V4 or V6 interface.	N	Y/N
USE_UNASSERTED_ANI_IN_FROM_HDR	SOFTSW_TG_PROFILE	Specifies whether the unasserted calling party number and display name is used in the FROM header of the outgoing SIP invite.	N	Y/N

Table 2 lists the new value defined for NEXT_ACTION token in the ROUTE table. The new value is called OVERFLOW_NENA_V4_WITH_UNASSERTED_ANI.

Table 2 NEXT_ACTION Token Details

New Token Name	Table Name	Description	Default Value	Possible Values
NEXT_ACTION	ROUTE	Specifies the action to perform after all trunk groups within a route are exhausted. Permitted values are: •NONE (Default)—No next action. Plays standard no route to destination announcement. •ALT-ROUTE—Uses alternate route. •ANNC—Uses an announcement ID. •OVERFLOW-DN—Reroutes the call using the overflow DN. •OVERFLOW-NENA-V4-WITH-UNASSERTED-ANI—Reroutes the call based on dialed emergency number and calling subscriber's number for NENA V4 call.	NONE	•NONE •ANNC •ALT_ROUTE •OVERFLOW-DN •OVERFLOW-NENA-V4-WITH-UNASSERTED-ANI

Billing Enhancements

The CDR fields listed below are populated in the billing record for incoming calls on V4 Interface.

Table 3 lists the new CDR fields.

Table 3 New CDR Fields

CDR Field Name	Field Type	Field Size	Description
NENA_V6_CALLING_PARTY	String	64	This field is populated from the FROM header in the V4 invite.
NENA_V6_CALLED_PARTY	String	64	This field is populated from the TO header in the V4 invite.
NENA_V4_ESQK	String	64	This field is populated from the P-Asserted-ID parameter in the V4 invite.
NENA_V4_ESRN	String	64	This field is populated from the Req-URI in the V4 invite.

The BTS 10200 treats the call segments on V6 and V4 interfaces independently and generates a CDR for each call segment. The CDR generated for the first call segment (routed on the V6 interface by the call server) is the standard CDR generated by the BTS 10200.

A CDR is generated for the second call segment (routed on the V4 interface by the routing proxy), corresponding to the V4 interface has details to correlate the original 911 caller, ESRN, and ESQK.

When the BTS 10200 acts as an ESGW, the new CDR fields appear in the billing record. When acting as a call server, these fields do not appear in the billing record.

Install and Upgrade Considerations

•The NENA_i2_V4_V6_SUPP token in the SOFTSW-TG-PROFILE table should be set to N during an upgrade process.

•The size increase of EMERGENCY_NUMBER_LIST table should be between 50 and 250 during an upgrade.

Additional References

Related Documents

Related Topic	Document Title
Summary of features and usage guidelines for this release	Cisco BTS 10200 Softswitch Release Notes
Reference listing of all CLI tables and tokens	Cisco BTS 10200 Softswitch CLI Database
Emergency Services Information	Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions Guide

Standards

Standard	Title
NENA i2 Standard	NENA Interim VoIP Architecture for Enhanced 9-1-1 Services (i2)

Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2011 Cisco Systems, Inc. All rights reserved.