Technical Report on a Nationwide Number Portability Study ATIS- 1000071 TECHNICAL REPORT As a leading technology and solutions development organization, the Alliance for Telecorrrrijnications Industry Solutions (ATIS) brings together the top global CT conpanies to advance the industry’s rest pressing business priorities. ATIS’ nearly 200 menter conpanies are currently working to address the All IP transition, netw ork functions virtualization, big data analytics, cloud services, device solutions, emergency services, fvM, cyber security, netw ork evolution, quality of service, billing support, operations, and niich more. These priorities follow a fast-track development lit ecycle — from design and innovation a t’is through standards, specifications, requirements, business use cases, softw are to olkits, open source solutions, and interoperability testing. ATIS is accredited by the American National Standards Institute (ANSI). The organization is the North American Organizational Partner for the 3rd Generation Partnership Roject (3GPF, a founding Partner of the oneM2M global initiative, a member of and major U.S. contrIbutorto the International Telecomnsjnication Union (ITU), as well as a menter of the Inter-American Telecomrrtjnication Comrrission (CITEL). For more information, visitwww.rrtis.orq. Notice of Disclaimer & Limitation of Liability The inforn,atron provided inthisdocumentisdirected solelyto professionalswho have the appropnate degree of expenenceto understand and interpret its contentsi n accordance withgenerally accepted engineenng orother professional standardsand applicable regulations No recommen dation as to productsorvendorsismade or should be implied. NO REPRESENTATION OR WARRANTY IS MADE THAT THE INFORMATION IS TECHNICALLY ACCURATE OR SUFFICIENT OR CONFORMS TO ANY STATUTE, GOVERNMENTAL RULE OR REGULATION, AND FURTHER, NO REPRESENTATION OR WARRA NTY IS MADE OFMERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR AGAINST INFRINGEMENT OF INTELLECTU AL PROPERTY RIGHTS. ATIS SHALL NOT BE LIABLE, BEYOND THE AMOUNT OFANY SUM RECEIVED IN PAYMENT BYATIS FOR THIS DOCUMENT, A ND IN NO EVENT SHALL ATIS BE LIABLE FOR LOST PROFITS OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES. ATIS EXPRESSLY ADVISES THAT ANY AND ALL USE OF OR RELIANCE UPON THE INFORMATION PROVIDED IN THIS DOCUMENT IS AT THE RI SK OF THE USER. NOTE - The useis attention iscalled to the posability that compliancewith thissiandard may require use ofan invention covered by patent rights By publication of thisstandard, no position staten with respect to whetheruse of an invention covered by patentnightswill be required, an d if any such use is required no position is talwn regarding the validity of this claim or any patent rights in connection therewith. Please refer to [http://www.atisorgllegallpatentinfo.asp] to determine if any statement hasbeen filed by a patent holdenindicating a willingness to grant a license eitherwithout compensation oron reasonable and non-discnminatorytermsand conditionsto applicantsdeanng to obtain a license. ATIS-1000071, Technical Report on a Nationwide Number Portability Study Is an ATIS Standard deloped by the Packet Technologies and Systems Committee (PTSC). Published by Alliance for Telecommunications Industry Solutions 1200 G Street, NW, Suite 500 Washington, DC 20005 Copynght© 2016 by Alliance for Telecommunications Industry Solutions All nghts reserved. No part of thispublication may be reproduced in any form in an electronic retrieve1 system or otherwise, without the pn or wntten penirisson of the publisher. For information contact ATIS at 202.628.6360 ATIS is online at < htlp l/vrww.atis org ATIS Technical Report on Technical Report on a Nationwide Number Portability Study Alliance for Telecommunications Industry Solutions Approved June 20, 2016 Abstract This Technical Report outlines the characterisbcs of the current U.S. local number portability implementation based on use of the Location Routing Number (LRN) method and explores different approaches for implementing Nationwide Number Portability (NNP) and their impacts. ATIS-1 000071 Foreword The Alliance for Telecommunication Industry Solutions (ATIS) serves the public through improved understanding between providers, customers, and manufacturers. The Packet Technologies and Systems Committee (PTSC) develops and recommends standards and technical reports related to services, architectures, and signaling, in addition to related subjects under consideration in other North American and international standards bodies. PTSC coordinates and develops standards and technical reports relevant to telecommunications networks in the U.S., reviews and prepares contributions on such matters for submission to U.S. ITU-T and U.S. ITU-R Study Groups or other standards organizations, and reviews for acceptability or per contra the positions of other countries in related standards development and takes or recommends appropriate actions. The mandatory requirements are designated by the word shall and recommendations by the word should. Where both a mandatory requirement and a recommendation are specified for the same criterion, the recommendation represents a goal currently identifiable as having distinct compatibility or performance advantages. The word may denotes an optional capability that could augment the standard. The standard is fully functional without the incorporation of this optional capability. Suggestions for improvement of this document are welcome. They should be sent to the Alliance for Telecommunications Industry Solutions, PTSC, 1200 G Street NW, Suite 500, Washington, DC 20005. At the time of consensus on this document, PTSC, which was responsible for its development, had the following leadership: M. Dolly, PTSC Chair (AT&T) V. Shaikh, PTSC Vice-Chair (Applied Communications Sciences) P. Pfautz, Technical Editor (AT&T) ATIS-1 000071 Table of Contents Scope, Purpose, & Application .1 1.1 Introduction 1 1.2 Background 1 1.3 Assumptions 1 2 References 1 3 Definitions, Acronyms, & Abbreviations 2 3.1 Definitions 2 3.2 Acronyms & Abbreviations 3 4 Current Number Portability Infrastructure 7 4.1 Common Channel Signaling Network 7 4.2 Relationship Between NPAC, LSMS, & NPDB 8 4.3 Number Portability Routing in a Common Channel Signaling Network 8 4.3.1 IPNetworks ii 5 Commercial Agreement NNP Solution 11 6 National LRN Implementation of NNP 12 6.1 Routing Impacts 13 6.2 Non-Routing Impacts 13 6.3 Transition to IP 14 7 Location Portability per GR-2982-CORE 15 7.1 Assumptions of GR-2982-CORE PORC Solution 15 7.2 Call Processing 16 7.2.1 PORC-Capable Originating Switch 16 7.2.2 PORC-Capable Intermediate Switch 17 7.2.3 PORC-Capable Donor/Surrogate Donor Switch 17 7.2.4 PORC-Capable Recipient Switch 18 7.3 Impacts to Circuit Switched Networks 19 7.4 Impacts to IP Networks/IP Network Considerations 20 8 Non-Geographic Location Routing Number (NGLRN) 21 8.1 Policy Considerations 22 8.1.1 InterLA TA Call Processing 22 8.1.2 N-i Query Requirement 23 8.1.3 Routing to NGLRN/NGTNs 23 8.1.4 Providing NNP Service to Customers 23 8.1.5 NGGWPoIicies 23 8.1.6 TheNGAreaCode 23 8.2 Administration of NG Resources 24 8.2 1 Porting Geographic TNs 24 8.2.2 Allocating Numbering Resources 24 8.3 NG Call Processing 25 8.3.1 InterLATA Call Processing 25 8.3.2 TDM to Geographic TN with NGLRN 25 8.3.3 TDMtoNGTN 25 8.3.4 IPtoNGTN&NGLRN 25 8.3.5 NG Originated Calls to 9-1-i 26 8.3.6 NGGWs & NGGW Providers 26 III ATIS-1 000071 9 Internet Interconnection . 26 10 Impacts on Regulatory Related Services 27 10.1 Emergency Services 27 10.1.1 Enhanced 9-1-1 (E9-1-1) 27 10.1.2 Next Generation 9-1-1 (NG9-1-1) 31 10.2 National Security/Emergency Preparedness (NS/EP) 36 10.2.1 GETS&WPS 36 10.2.2 NGN GETS 37 10.2.3 Number Portability Considerations 37 11 Analysis 39 11.1 Feasibility of NNP Maintaining Current Paradigms 39 11.1. 1 Feasibility in Circuit Switched Networks 39 11.1.2 Feasibility in IP Networks 39 11.2 Feasibility of NNP Post IP Transition 39 11.3 National Number Assignment 40 12 Summary of Proposals & Impacts 40 12.1 Commercial Agreements 40 12.1. 1 Oveiview of Commercial Agreement Approach 40 12.1.2 ImpactAnalysis 40 12.2 National LRN 41 12.2.1 Oveiview 41 12.2.2 Impacts 41 12.3 NNP Solution Based on GR-2982-CORE 43 12.3.1 Oveiview of NNP Solution Based on GR-2982-CORE 43 12.3.2 Impact Analysis 43 12.4 NGLRN 46 12.4.1 NGLRN Solution Description 46 12.4.2 Impacts 46 12.5 Internet Interconnection 48 12.5.1 Overview 48 12.5.2 Summary of Impacts 48 Appendix A: National Telephone Cooperative Association (NTCA) Call Scenarios 50 Table of Figures Figure 4.1 — Illustrating a Common Channel Signaling (SS7) Network 7 Figure 4.2 — Example Service Provider connecting to an NPAC 8 Figure 4.3 — Originating Switch NP Processing Direct to Recipient Switch 9 Figure 4.4— IXC Routed call; NP Query at IXC Switch 10 Figure 5.1 — Call Flow to a Ported Number 12 iv ATIS TECHNICAL REPORT ATIS-1 000071 ATIS Technical Report on — Nationwide Number Portability Study I Scope, Purpose, & Application 1.1 Introduction This Technical Report outlines the characteristics of the current U.S. local number portability implementation based on use of the Location Routing Number (LRN) method and explores different approaches for implementing Nationwide Number Portability (NNP) and their impacts. 1.2 Background The Federal Communications Commission (FCC) has asked the industry1 and the North American Numbering Council (NANC)2 to determine what changes to existing infrastructure and procedures would be required to permit users to port an E.164 geographic telephone number beyond current limits (essentially the rate center to which the NPA-NXX of the number is assigned) to any area of the nation. The FCC also asked “how long the need for LRNs will continue to exist once Voice over Internet Protocol (V0IP) interconnection is fully implemented, including an analysis of the role of LRNs for carriers that implement both Time-Division Multiplexing (TDM) and VoIP-based interconnection during the VoIP interconnection transition.” The NANC delegated analysis to several of its working groups. Certain groups, the Local Number Portability Administration (LNPA) Working Group and the Future of Numbering (FON) Working Group, have in turn indicated that changes to the technical solution for number portability would most appropriately come from the Alliance for Telecommunications Industry Solutions (ATIS) Packet Technologies & Systems Committee (PTSC). This document presents the PTSC’s analysis. 13 Assumptions NNP is defined as allowing portability outside the rate center including from one state to another. The FoN WG made the following assumptions: 1) Assume that when the consumer engages in NNP they physically move and their interconnection point is established in their new geography. 2) Assume that the consumer is now under the new district (porting to a different rate center or Local Access and Transport Area [LATA] within the same state) or new state laws/regulations. 3) Assume that NNP should be implemented up to and including crossing state lines (e.g. porting a number assigned in CA to NY). 2 References ATIS-1000002, Technical Requirements for Number Portability Switching Systems.3 ATIS-1000003, Technical Requirements for Number Portability — Database and Global Title Translation.4 1 Letter from FCC Chair to President of CTIA, July 27, 2015. 2 Letter from Chief of FCC Wireline Competition Bureau to NANC Chair, November 16, 2015. This document is available from the Alliance for Telecommunications Industry Solutions (ATIS) at: < https://www.atis.org/docstore/product.aspxi =21228>. This document is available from ATIS at: . ATIS-1 000071 ATIS-1 000047, Sijnaling System 7 (SS7) and Internet Protocol (IP) Transport Networks Signaling lnteiworking and Compatibility.’ ATIS-1000051, TCAP Gateway Functionality.6 ATIS-1000063, IPNNI Profile.7 ATI s-i 000660.1 998(R20 13), Signaling System Number 7 — Call Completion to a Portable Number — Integrated Text.8 GR-2982-CORE, Local Number Portability (LNP) Capability Specification: Location Portability, Issue 1, December 1997.0 GR-2936-CORE, Local Number Portability (LNP) Capability Specification: Seivice Provider Portability, Issue 3, November 1997.8 GR-394-CORE, LSSGR: Switching System Generic Requirements for Interexchange Carrier Interconnection (IC!) Using the Integrated Services Digital Network User Part (ISDNUP), Issue 7, December 2003. 8 AT Is-i 000679.2015, Inteiworking between Session Initiation Protocol (SIP) and ISDN User Part, April 2015.10 IETF RFC 4679, DSL Forum Vendor-Specific RADIUS Attributes, September 2006.11 IETF RFC 4694, Number Portability Parameters for the “tel” URI, October 2006.11 NENA 05-001, NENA Standard for the Implementation of the Wireless Emergency Service Protocol E2 Interface, December 2003.12 J-STD-034, Wireless Enhanced Emergency Services, December 1997.13 J-STD-036-C, Enhanced Wireless 9-1-1 Phase II, October 2013.14 OMA-TS-MLP-V3_2-20051 124-C, Mobile Location Protocol 3.2, November 2005.15 3 Definitions, Acronyms, & Abbreviations For a list of common communications terms and definitions, please visit the ATIS Telecom Glossary, which is located at < http://www.atis.org/glossary>. 3.1 Definitions GUBB (Geographic Unit Building Block): The smallest geographic unit within an area of location portability that is meaningful for rating purposes by any carrier. This document is available from ATIS at: . This document is available from ATIS at: . ‘ This document is available from ATIS at: . This document is available from ATIS at: . This document is available from Telcordia at: . 10 This document is available from ATIS at: . This document is available from the Internet Engineering Task Force (IETF) at: . 12 This document is available from the National Emergency Number Association (NENA) at . 13 This document is available from ATIS at: < https://wwwatis.org/docstore/product.aspxid=1 1435>. 14 This document is available from ATIS at 15 This document is available from the Open Mobile Alliance (OMA) at: . 2 ATIS-1 000071 3.2 Acronyms & Abbreviations ALl Automatic Location Identification AMA Automatic Message Accounting ANI Automatic Number Identification AOA Angle of Arrival API Applications Programming Interface ATIS Alliance for Telecommunications Industry Solutions CAF Connect America Fund CAMA Centralized Automatic Message Accounting CdPN Called Party Number CLEC Competitive Local Exchange Carrier CMAS Commercial Mobile Alert System CNAM Calling Name CO Central Office CPC Calling Party Category CPE Customer Premise Equipment DN Directory Number DNS Domain Name Server DSCP Differentiated Services Code Points E-MF Enhanced MF E9-1-1 Enhanced 9-1-1 EMS Emergency Medical Services ENUM E.164 Number Mapping ESCO Emergency Service Central Office ESGW Emergency Services Gateway ESN Emergency Service Number ESRD Emergency Services Routing Digits ESRK Emergency Services Routing Key ESQK Emergency Services Query Key ESS Electronic Switching System ESZ Emergency Service Zone ETS Emergency Telecommunications Service 3 ATIS-1 000071 FCC Federal Communications Commission FCI Forward Call Indicator FoN WG Future of Numbering Working Group GAP Generic Address Parameter GDP Generic Digits Parameter GETS Government Emergency Telecommunication Service GMLC Gateway Mobile Location Center GPS Global Positioning System GUBB Geographic Unit Building Block HPC High Probability of Call Completion lAM Initial Address Message CA Independent Computing Architecture IETF Internet Engineering Task Force ILEC Incumbent Local Exchange Carriers IMS IP Multimedia Subsystem IP Internet Protocol IPX Internetwork Packet Exchange ISDN Integrated Services Digital Network ISUP ISDN User Part ISVM Inter-Switch Voice Messaging IXC lnterexchange Carrier JIP Jurisdiction Information Parameter LATA Local Access and Transport Area LERG Local Exchange Routing Guide LIDB Line Information Database LNP Local Number Portability LNPA WG Local Number Portability Administration Working Group LPG Legacy PSAP Gateway LRN Location Routing Number LSMS Local Service Management System LSP Label-Switched Paths LSPP Local Service Provider Portability LSRG Legacy Selective Router Gateway 4 ATIS-1 000071 MF Multi-Frequency MLP Mobile Location Protocol MPC Mobile Positioning Center MPLS Multi-protocol Label Switching MSC Mobile Switching Centers MTA Message Transfer Agent MTP Message Transfer Part NANC North American Numbering Council NANP North American Numbering Plan NANPA North American Numbering Plan Administration NAS NANP Administration System NCAS Non-Call Associated Signaling NE Network Element NENA National Emergency Number Association NG Non-Geographic NGGW Non-Geographic Gateway NGLRN Non-Geographic Location Routing Number NGN Next Generation Network NGTN Non-Geographic Telephone Number NOWG Numbering Oversight Working Group NNA Nationwide Number Assignment NNP Nationwide Number Portability NP Number Portability NP GTT Number Portability Global Title Translation NPA Numbering Plan Area NPAC Number Portability Administration Center NPD Numbering Plan Digit NPDB Number Portability Database NS/EP National Security/Emergency Preparedness NTCA National Telephone Cooperative Association OMA Open Mobile Alliance PA National Number Pool Administration PAM PSAP-to-ALI Message 5 ATIS-1 000071 pANI pseudo ANI PAS Pooling Administration System PIDF-LO Presence Information Data Format Location Object P01 Point of Interconnection PORC Portability Outside the Rate Center PSN Public Switched Network PSTN Public Switched Telephone Network PTSC Packet Technologies & Systems Committee RBOC Regional Bell Operating Company RLEC Rural Local Exchange Carrier RPH Resource-Priority Header SAP Service Activation Parameter SIP Session Initiation Protocol SLA Service Level Agreement SMS Short Message Service SOA Service Order Administration SP Service Provider SPID Service Profile Identifier SR Selective Router SRDB Selective Routing Database SS7 Signaling System Number 7 SSP Service Switching Point STP Signaling Transfer Point TCAP Transaction Capabilities Application Part TDM Time-Division Multiplexing TDOA Time Difference of Arrival TN Telephone Number TWI Toll Warning Indicator URI Uniform Resource Identifier V0IP Voice over Internet Protocol VPC VoIP Positioning Center WC Wireless Carrier WCM Wireline Compatibility Mode 6 ATIS-1 000071 WPS Wireless Priority Service WSP Wireless Service Provider 4 Current Number Portability Infrastructure 4.1 Common Channel Signaling Network A telecommunication network served by common channel signaling is composed of a number of switching and processing nodes interconnected by transmission links. The nodes in the telecommunication network that are provided with common channel signaling are, in the context of signaling, referred to as signaling points. Signaling Links Signaling links are basic components in a signaling network that interconnect signaling points. The signaling links encompass the level 2 functions that provide for message error control (detection and subsequent correction). In addition, signaling links are responsible for maintaining the correct message sequence. Signaling links connect signaling points at which signaling network functions such as message routing are provided at level 3, and at which the user functions may be provided (if the signaling point is also an originating or destination point). A Signaling Transfer Point (STP) is a signaling point that transfers messages from one signaling link to another at level 3. The STP function may be combined with some other (e.g., switching) function. The signaling links, STPs, and signaling (originating or destination) points may be combined in many different ways to form a “signaling network.” Current TDM-based networks use Signaling System 7 as a protocol and are referred to as a Signaling System Number 7 (SS7) network. Figure 4.1 — Common Channel Signaling (SS7) Network Supporting Number Portability While some service providers (SPs) have network architectures similar to that shown in Figure 4.1, no assumptions are made about the deployed architecture of the Number Portability Database (NPDB) application platforms that provide the NPDB application or the method by which the NPDB application platforms are connected to the SS7 network. NPDB application platforms may be deployed in simplex, mated (duplex). N+1, or any other configuration. and can be connected to the SS7 network using simplex or mated (duplex) STP5. Each service provider has selected a network architecture based on their own requirements for reliability, survivability. and performance under failure conditions. This also may be a system they have deployed within their own network or obtained as a service provided by another Number Portability (NP) service provider. 7 ATIS-1 000071 4.2 Relationship Between NPAC, LSMS, & NPDB Information about ported numbers will be made available to platforms supporting the NPDB application from the Number Portability Administration Center (NPAC). The Number Portability Global Title Translation (NP GTT) function will also receive information about ported Directory Number (DN) from the NPAC. The NPDB and NP GTT are supported by a Local Service Management System (LSMS) function that provides the interface to the NPAC. The LSMS function supports a vendor’s NPDB application, a vendor’s NP GTT function, and possibly other internal processes of the service provider. As such, the requirements for the LSMS are to be determined by the vendor and the service provider. This LSMS function may be part of the NPDB application and NP GTT function, or may reside elsewhere. A single LSMS may support multiple NPDB applications or NP GTT functions or both. A service provider may also use more than one LSMS to serve a given NPDB application or NP GTT function, in order to provide greater reliability. Specific configurations between LSMS systems, NPDB applications, and NP GTT are up to each individual service provider and their vendors. Figure 4.2 shows one way in which a service provider may connect to an NPAC. Figure 4.2 — Example Service Provider connecting to an NPAC All service providers have deployed or have access to an NP application that includes relationships between the NPAC, and LSMS, an NPDB, and an NP GTT functionality. These functional entities are the basis of an LRN based Number Portability (NP) application. 4.3 Number Portability Routing in a Common Channel Signaling Network NP gives the end user the ability to move from one switch to another and keep their original DN. There are three types of NP: Service Portability, Service Provider Portability, and Location Portability. • Seivico Portability — Allows an end user to retain the same DN when changing services. • Service Provider Portability—Allows an end user to retain the same DN when changing service providers. • Location Portability — Allows an end user to retain the same DN when changing physical locations. In this case, the subscriber may or may not change service providers. Only service provider portability and location portability within a rate center are supported at this time, except for the “permanent roamer” mobile example described in section 5. When an NPA-NXX is defined as portable, the NPDB service logic returns an LRN of the recipient switch for each DN that has been ported. When the switch receives the LRN, the LRN will be used to route the call to its correct destination. In the Initial Address Message (IAM). the Called Party Number parameter will be populated with the LRN and a Generic Address Parameter (GAP) will be populated with the actual dialed digits (plus derived NPA 8 ATIS-1 000071 when necessary). The Forward Call Indicator (FCI) parameter in the Integrated Services Digital Network User Part (ISUP) Initial Address Message (lAM) will be used to indicate whether an NP query has been performed. This is used to prevent more than one NP query from being launched on a call. The switch does not distinguish the type of call (intra-LATA local, intra-LATA TOLL, or inter-LATA) based on whether the dialed DN is portable or ported. The type of call is determined based on the analysis of the dialed DN and not the LRN. Queries for non-ported DNs will cause the NPDB to return the actual dialed DN and not the LRN. In this case, the dialed DN will be translated in the NP Routing Tables. Switches that do not have the NP capability will route the call toward the donor switch or a tandem switch that has the NP capability, and the NP capable switch will launch the query to determine routing. Service providers are required to have the ability to specify the LRN that identifies the switch. The switch must support provisioning of a minimum of two 10-digit LRNs per LATA. Each LRN provisioned can come from any NPA-NXX assigned to that switch in the Local Exchange Routing Guide (LERG). The service provider is required to be able to provision routing translations for scenarios where either the dialed DN or the LRN is returned from the NPDB. The routing for the NPA-NXX will be the same regardless of whether the NPDB returns the LRN or the DN. The call will route to the donor switch when the DN is returned, and the call will route to the recipient switch based on the LRN when the LRN is returned. In either case, this is LERG-based routing The service provider is required to be able to provision translations for routing when the NPDB is unavailable. The switch treats this situation as though an analyzeRoute with Dialed Number was returned from the NPDB. These translations would normally route towards the donor switch. The following two call examples illustrate basic call processing when an NP application is in use and show the basic relationships between network nodes in an SS7 network. Figure 4.3 below is a high level example of NP processing of a local call. Figure 4.4 illustrates NP call processing involving an lnterexchange Carrier (IXC). Many other call examples exist. The intent is not to illustrate all possible call examples, but these call examples give a basic understanding as to how a call is processed in an NP network environment. SubscriberA Dials 713-2222 NPDB Figure 4.3 — Originating Switch NP Processing Direct to Recipient Switch Subscriber B 708-713-2222 PortedDN (1) (8) Originating Recipient Switch Switch (2) (5) (7) 9 ATIS-1 000071 The following illustrative call flows assume the calls are handled by the Local Exchange Carrier (LEO). Since no XC is involved in the call, intraLATA SS7 signaling is used. These call flows are provided for illustration purposes to aid in understanding the NP processes and are not meant to be all-inclusive. No network boundaries should be assumed or implied unless specifically stated. This is a common case where a subscriber number is ported to a different switch and the subscriber can be connected via a direct connection. The “Signal Ported Number” trunk group option, as described in ATIS 1000002, is not specified for this scenario. The following steps are illustrated in Figure 4.3: 1. Subscriber A (708-224-1111) dials Subscriber B (708-71 3-2222). 2. The Originating Switch performs digit analysis on the dialed digits to determine how to route the call. The switch determines that B is in a portable NPA-NXX (708-713) and the DN does not reside on the switch. 3. The switch sends a Ti .667 (analyzedlnformation) or pre-IN (IN/i) (Providelnstructions:Start) query based on the dialed digits to the NPDB. 4. The NPDB sends a T1.667 (analyzeRoute) or pre-IN (in/i) (ConnectControl:Connect) response containing the LRN (3i2-979-xxxx) of the Recipient Switch. 5. The Originating Switch receives the NPDB response and analyzes the data. The LRN is translated in the NP Routing Tables and an SUP route out of the switch is determined. The LRN is populated in the Called Party Number (CdPN) parameter and the dialed digits are populated in the GAP parameter of the ISUP lAM message. The FCI Ported Number Translation Indicator is set to indicate a query has been done (set to “translated number”). 6. The call is routed to the Recipient Switch based on the LRN. 7. The Recipient Switch receives and processes the contents of the lAM message. The switch determines that an LRN is received and that it is the switch’s LRN. Since the LRN identifies this switch, the switch uses the contents of the GAP rather than the Called Party Number parameter to identify the subscriber. 8. The Recipient Switch completes the call to the subscriber. IXC-Routed Call; NP Query at IXC Switch For this case, the Originating Switch determines that the call is to be routed to an IXC, and does not perform the NP query. The NP query is performed at the IXC Switch, and the call is routed onward to the Recipient Switch. In this example, the XC has direct trunks to both the Originating and Recipient Switches. The following steps are illustrated in Figure 4.4: SubscriberA Dials 1-708-713-2222 Subscriber B 708-713-2222 (1) (10) Originating Switch IXC Switch (4) (7)(2) Recipient Switch (9) Figure 4.4 — IXC Routed call; NP Query at IXC Switch 10 ATIS-1 000071 1 Subscriber A (305-224-1111) dials Subscriber B (1-708-713-2222). 2. The Originating Switch performs digit analysis on the dialed digits to determine how to route the call. The switch determines that routing to the called DN (Subscriber B) requires routing to an IXC and does not perform the NP query. 3. The Originating Switch signals, using SS7 signaling, the dialed number to the XC Switch using existing procedures. 4. The IXC Switch performs digit analysis on the incoming digits to determine how to route the call. The switch determines that the called DN (Subscriber B) is in a portable NPA-NXX (708-71 3) and verifies that conditions have been met such that a query should be sent. 5. The IXC Switch sends a query based on the dialed digits to the NPDB. 6. The NPDB sends a response containing the LRN (708-979-xxxx) of the Recipient Switch. 7. The IXC Switch receives the NPDB response and analyzes the data. The LRN is translated in the NP Routing Tables and an SUP route out of the switch is determined. 8. The IXC Switch signals, using SS7 signaling, the LRN in the AM CdPN to the Recipient Switch. The lAM includes a “Ported Number” GAP containing the dialed digits and the FCI Ported Number Translation indicator is set to “translated number.” 9. The Recipient Switch performs digit analysis on the incoming digits to determine how to route the call and determines that the DN is on the switch. 10. The Recipient Switch completes the call to the terminating subscriber. A number of services in use today rely upon SS7 signaling. These include Line Information Database (LIDB) (alternate billing services), CLASS, Calling Name (CNAM), and Inter-Switch Voice Messaging (ISVM). Prior to NP, the SS7 network used six-digit GTT procedures (analysis of NPA-NXX) to route messages for these services to the target system. Once a given NPA-NXX is supported in multiple target systems, a GTT function based on ten-digit analysis is needed to correctly identify the target system. For those services that do not need to operate between networks, six-digit GTT procedures may continue to be adequate. The support of these services between networks is dependent upon bilateral business agreements. Ten-digit GTT may be needed within a network if intra-service provider porting takes place. NP is transparent to the end user. NP is a network capability which allows the DN of an end user to be moved from one switch to another within the rate center. There may be some feature limitations when the end user changes their service to a different service provider. Some features previously used by the customer may not be supported by the new service provider’s network. Also, some features may no longer work because they require an intra-switch or intra-network relationship with other users that no longer exists once the customer changes to the new service provider. 4.3.1 IP Networks IP networks currently support number portability through a variety of arrangements. These may include performing LNP queries of a Transaction Capabilities Application Part (TCAP) NPDB through interworking from Internet Protocol (IP) protocols as discussed in ATIS-1000047 and ATIS-1000051 or mapping NP information from the LSMS into a Domain Name Server (DNS) namespace to support an E.164 Number Mapping (ENUM) query as in RFC 4679. In call set up NP information elements are mapped into Session Initiation Protocol (SIP) messages as described in ATIS-1000679 and RFC 4694. 5 Commercial Agreement NNP Solution Wireless carriers with a nationwide footprint may allow customers to move outside the LATA associated with their number by treating them as permanent roamers. Likewise, they can port in the numbers of customers that have moved outside their original LATA by porting the numbers to their Point of Interconnection (P01) in the original LATA. Since the P01 in either case remains in the original LATA end user billing, interconnection and settlements are not changed 11 ATIS-1 000071 It has been suggested16 that an interim solution to nationwide portability could be achieved by using the facilities of third parties to provide a P01 in the donor LATA and to deliver traffic from that P01 to the network of the recipient provider in a distant LATA. The call flow to a ported number is shown in the figure below: tTP 1 LATA 2 Third ar-ty NCtwork — j14. ilL “4P %13 Figure 5.1 — Call Flow to a Ported Number Note that issues relating to the LRN used to port the number to the third party P01 may need to be examined by the ATIS Industry Numbering Committee (INC) and LNPA Working Group, and the Numbering Oversight Working Group (NOWG): • In order for the recipient carrier to appear as a wireless carrier in industry databases, must the LRN be assigned to the recipient carrier rather than the third party provider? • If so, will this require assignment of an LRN to each wireless carrier in each LATA from which they wish to port in numbers, and what impacts would be expected to the North American Numbering Plan (NANP)? 6 National LRN Implementation of NNP The approach described in this clause allows LRNs to be used outside of the current LATA boundaries thereby allowing TNs to be “ported” nationally. This solution assumes that service providers will be permitted to have LRNs in multiple regional NPACs to identify current customer’s service market. To affect this approach, processes are involved in the call set up, including signaling, and responsibilities exist as to which service provider will perform dips to obtain the LRN to address how the dialed Telephone Number (TN) is then processed to properly terminate the call. Such processes and responsibilities are additional areas of consideration that need to be assessed relative to NNP impacts. However, this solution takes a straightforward approach leveraging 16 Level 3 presentation atCCA/CTIA meeting of August 31, 2015. 12 ATIS-1 000071 today’s infrastructure since it utilizes existing call routing functionality, without the costs’ of additional administrative overhead. This approach for NNP using national LRNs acknowledges that there are both routing and non-routing impacts as well. This clause identifies but does not address specific mitigation approaches to non-routing impacts. It may be noted that the industry has some experience with the effects of removing the edit preventing inter-LATA porting as a result of measures taken in response to hurricane Katrina and subsequent storms.17 6.1 Routing Impacts This proposal minimizes the changes required to the processes surrounding the routing of ported TNs by utilizing the existing routing infrastructure. Another benefit of this approach is that it allows carriers with a nationwide footprint to associate customers who have physically moved outside the rate center or LATA associated with their NPA-NXX to an LRN in the rate center or LATA in which they now reside. This proposal allows “permanent roamer’ calls to be routed appropriately based on the nationwide use of LRNs while assisting the service providers in determining the correct interstate/jurisdictional nature of the call based on the location of the LRN assigned. Although there are some aspects of LRN routing that need to be considered when taking LRN routing outside the current constraints placed on LRNs by rate centers and LATAs, existing LRN routing principles can effectively support the routing aspects of NNP. Some aspects that have to be addressed include but are not limited to: • Current NPAC system processes require the LRN and TN NPA-NXX components to be associated to the same LATA. • Some assessment of network equipment (e.g., switches) ability to handle substantially more NPAs (due to potential ported TNs from a much wider base of NPAs than the equipment may handle today) needs to be performed. • The impact to the N-i lookup requirement. Service providers would need to conduct an assessment to determine the network impacts of either performing all queries at the point of origination, or maintaining the N-i call completion scenario with the understanding that those TNs porting outside the LATA require additional routing. 6.2 Non-Routing Impacts From a routing perspective, the existing LNP/LRN process can support NNP and by doing so, network impacts and efforts can be minimized. One of the major benefits of this approach is that it requires minimal changes to the administration or assignment of numbering resources. Some non-routing issues exist relative to this proposal These include, but are not limited to: • NNP will impact many industry processes including call detail record processing, subscriber billing, caller ID issues (e.g., systems that default Caller Name as viewed by the called party to a rate center or state [exacerbating a consumer issue that exists with wireless calls today]). • Tariffs, toll-free (Short Message Service [SMS]) processing, Enhanced 9-i-i (E9-i-i). as well as many other processes have some aspects that may key on the relationship of a TN to a rate center and/or a LATA. • The porting-in service provider may not have a presence in the ported-out area. In general, appropriate business agreements may need to exist between the port-in and port-out service providers. These situations are addressed within the current LNP LATA environment; however, NNP extends these situations nationally. 17 These impacts are discussed in an LNPA Working Group report, available at. < https://www.npac.com/media/npac/f;les/publicllnpa-wg-documents/final report on out of lata porting - pooling for disaster relief after hurricane katrina >. 13 ATIS-1 000071 • Dialing plan consistency (e.g., national 1+ dialing) may be needed. For example, variations exist across the country with respect to the way calls can/should be dialed, i.e., 1+10 digits, 10 digits, and/or 7 digits. Dialing plans are often related to the routing rules associated with the dialed number. For example, local calls originating and terminating within the same NPA, especially if only one NPA today serves the area, are usually dialed on a seven digit basis. NNP impacts on the varying dialing plans needs to be assessed. • Numbering resources are state-managed. Porting TNs out-of-state raises questions of regulatory and service provider responsibilities, liabilities, and numbering resource management. • State regulatory oversight aligns with NPA boundaries (all NPAs have geographical boundaries that lie within a given state) and all rate center boundaries lie within a given state. Rare isolated cases may exist between states having a common border to address various dialing and servicing issues for small areas. NNP would, in many cases, be moving a TN’s relationship to geography outside the state of the base NPA, resulting in potential issues with existing state regulations, policies, etc. • Consumer issues include but are not limited to: o Consumers with geographic-based rate plans keyed on rate center or LATA considerations need to be clearly aware of how a call they place aligns with their rate plan. o Call completion issues may arise when routing to TN5 that have moved from a specific rate center/LATA geography to anywhere within the national footprint. o Toll/call blocking software that blocks calls based on the local/toll relationship the calling number has to the called number based on NPA-NXX, would need to determine local/toll at a TN level or rely on some indication that a call is toll/not toll, etc. o Caller ID/Name impacts need to be assessed. o Consumer billing confusion. This is especially true if local/toll plans are involved, and having calls to the same NPA-NXX that are sometimes local and sometimes toll. • Other issues: o SMS 800 — The impacts on SMS 800 need to be assessed since there could be restrictions on toll-free calling based on calling party location (e.g., a toll-free service could be set up to work on an intraLATA basis only) which could impact consumers [e.g., if a customer ports a New York City TN to Los Angeles, and a toll-free number is set to only work in LATA 132 (New York City area), it is not clear whether a call from the New York City TN (which is now assigned to Los Angeles [LATA 730]) to the toll-free number will be allowed]. o Local Systems — The impacts to local systems, both Service Order Administration (SQA) and LSMS would need to be assessed. Dependencies, assumptions, or design and implementation decisions likely exist regarding the relationships between NPA5, NXXs, LRNs, and geographic areas of service and/or single NPAC regions. Present system implementations may be based on the current porting rules regarding porting only within a single LATA and/or NPAC region, and the fact that an LRN only can be associated with a single NPAC region, as well as that a ported TN record can only exist in one NPAC region. o Service Providers’ Number Management Systems — A need to assess whether “edits” would need to be updated to allow for TNs to be assigned to switches that are outside of the area. 6.3 Transition to IP This solution can evolve into an all-IF environment. Although there is no industry consensus on how to route calls in an IP enviroment, many of the P routing scenarios proposed do not change any of the existing industry regulations, processes, or assumptions. Therefore, there are many who hold the belief that the implementation of lP would not change the administration of how numbers are assigned from the NPA-NXX level downward, nor how routing data, NPAC, pooling, and block data, are currently provisioned and distributed. The major impact of IF networks centers around defining the essential data elements required for routing in an P environment, how that data would be exhanged between providers, and how the network would use those data elements to complete calls end to end. 14 ATIS-1 000071 Consequently, this proposed routing solution would be pertinent in an all-IP environment unless or until the industry agrees that routing in an all-IP environment would be fundamentally different than how it occurs today and defines the requirements and specifications for implementation of the new approach. 7 Location Portability per GR-2982-CORE GR-2982-CORE describes one solution for porting beyond rate center boundaries. Portability Outside the Rate Center (PORC), as described in GR-2982-CORE, is based on the concept of a Geographic Unit Building Block (GUBB). GR-2982-CORE defines a GUBB as “the smallest geographic unit within an area of location portability that is meaningful for rating purposes by any carrier.” The GUBB is an identifier that represents the geographic location of the end user in an area within which customers may port their TNs. Each GUBB is a separate, distinct area with specific non-overlapping borders. The territory covered by an area of location portability must be fully defined by one or more GUBBs. Every location within the area of portability corresponds to one and only one geographic block. Every TN in an area of location portability can be associated with one and only one GUBB, based on the TN’s geographic location in the area of location portability. At the time that GR-2982-CORE was written, consensus was being sought on defining a GUBB for each existing Toll Rate Center. GR-2982-CORE also raised the possible necessity of defining a GUBB for each Local Rate District that exists within a large metropolitan area’s Toll Rate Center to support jurisdictions where distance- sensitive local measured service offerings are tariffed. GR-2982-CORE suggested that a GUBB could be represented by any one of the NPA-NXXs currently assigned within an existing Rate Center. GR-2982-CORE assumes a billing policy in which the end user calling a PORC TN would incur the transport charges for the call. To support this policy, GUBBs would be used to determine the charges (if any) applicable to the call, rather than TNs. Since charges based on GUBBs could be different from charges based on TNs, GR 2982-CORE suggested that a warning tone or announcement might have to be provided to customers to alert them of this difference. 7.1 Assumptions of GR-2982-CORE PORC Solution The PORC solution described in GR-2982-CORE is based on the following assumptions: • An LNP-capable switch conforms to the requirements set forth in GR-2936-CORE (which describes the requirements for Local Service Provider Portability {LSPP]). • An LNP-capable switch is able to perform an LNP query and is able to swap the Generic Address Parameter/Called Party Number (GAP/CdPN) information (i.e., populate the LRN received in the response from the LNP database in the Called Party Number parameter, and populate the dialed number in the GAP). In a PORC environment, it is assumed that both the recipient and donor switches are LNP (i.e., LSPP)-capable. • A PORC-capable switch is an LNP-capable switch that supports the PORC requirements defined in GR 2982-CORE. • In a PORC environment, the donor switch is not required to be PORC-capable. If the donor switch is not PORC-capable, it is assumed that a surrogate donor switch exists that is PORC-capable. • In a PORC environment, the recipient switch is required to be PORC-capable. • GUBBs are used as the vehicle for identifying the geographic location of the end user. In a PORC environment, it is expected that PORC-participating networks will use GUBBs to provide the geographic location of the end user. No assumptions are made with respect to non-PORC-participating networks. • The GUBB is a six-digit number that should use an NPA-NXX format, and at cutover should use existing rate centers and a representative NPA-NXX that is assigned and working in each rate center. • The GUBB identifies the geographic area to which the end user ports. • The GUBB supports the classification of the call as local Extended Area of Service, TolI-lntraLATA or Toll InterLATA based on the calling and called party’s respective GUBBs. • The GUBB will be assigned as a line attribute only if the line is ported outside the rate center. • The LRN is used for routing and the GUBB is used for carrier selection and rating purposes. 15 ATIS-1 000071 • No new requirements will be placed on non-PORC participating networks and their Network Elements (N Es). However, PORC works best when all carriers/switches in the area of portability are PORC capable. • Calling parties served by non-PORC participating networks will not experience any difference in how a call to a PORC number is rated (i.e., the call will be rated based on the dialed Directory Number [DN] rather than on the GUBB). • Carrier selection for toll calls will be made by the billed party. • The FCI M Bit will be set for all LSPP and PORC query/response interactions at a Service Switching Point (SSP). The M Bit, when set, indicates an LSPP LNP query has been performed. Since the PORC query encompasses LSPP translations and responses, it is appropriate to set the M Bit following a PORC query/response. • The FCI 0 Bit will be set when a PORC query/response is completed (see Clause 7.2 for further details). • A PORC-capable switch will always send a PORC query with a PORC trigger criteria type. • Location Portability within a state and its subsets and rate center change within a state and its subsets will be supported. This is a reflection of the jurisdiction of state public utility commissions and their potential LNP decisions. Exceptions to this may be made for cross-boundary situations. • If a recipient switch serves more than one rate center, and if a call to a PORC DN is routed to that switch without a P0RC translation having been completed (i.e., without the 0 Bit having been set), then a PORC query is needed to obtain the appropriate carrier and charge number information for the call leg between rate centers served by that switch. With regulatory relief, this situation may be alleviated and the PORC query avoided. 7.2 Call Processing When a call is placed to a PORC DN, the PORC-capable switch launches a query to the LNP database (referred to in ATIS-1000002 as a Number Portability Database {NPDB]). A PORC-capable switch must be able to distinguish NPA-NXXs that have been designated as portable, launch a P0RC query to the LNP database requesting information necessary to rate and route a call to such a number, and, if the number was actually ported, process the call using the information provided by the database. 7.2.1 PORC-Capable Originating Switch In an environment where all switches are PORC-capable, an LNP trigger would be encountered at the originating switch for a call to a number within the area of portability. Specifically, the originating switch will encounter the Local_Number_Portability PORC trigger when the dialed digits received match 3 to 10 contiguous digits of an NPA-NXX-XXXX (NPA mandatory), which has been designated as portable. As with portability within the rate center, if the dialed number received is served by the switch, then the LNP PORC trigger will be bypassed. As in the case of portability within the rate center, when an LNP PORC trigger is detected, the SSP formulates and sends an Info_Analyzed Message (referred to in ATIS-1000002 as the analyzedlnformation message) to the LNP database. In order for the LNP database to recognize that the LNP query has been sent from a PORC capable switch, the query’s Trigger Criteria Type parameter will be set to localNumberPortabilityP0RC. The Info_Analyzed message will also include the CalledPartylD parameter containing the 10 digits of the dialed number, as well as the CallingPartylD parameter, ChargeNumber parameter, and the Jurisdictionlnformation parameter18, if available. The message sent in response to a PORC query will include a CalIedPartylD parameter that contains the 10-digit LRN (if the dialed number was ported) or the 10-digit dialed number (if not ported). If the called number has been ported outside the rate center, the response to the PORC query (i.e., the Analyze_Route message) will also carry information about the geographic location of the called number. This six-digit GUBB is defined based on pre-LNP rate centers (if a number has not been ported, then its NPA-NXX corresponds to the six-digit GUBB, i.e., every 18 An originating SSP will populate the first six digits of its LRN in the Jurisdictionlnformation parameter of the Info_Analyzed message. If the LNP query is performed by a subsequent SSP in the call path, the SSP will use the content of the JIP received via SUP signaling (if available) to populate the Jursidictionlnformation parameter in the Info-Analyzed message. 16 ATIS-1 000071 NPA-NXX has a default GUBB). The GUBB of a number ported outside the rate center is carried in the TerminatingGUBB value of the GenericDigits parameter of the Analyze_Route message sent in response to a PORC LNP query. The GUBB will be used by the switch to determine the type of call and therefore the carrier that will transport the call. Carrier type is determined by the switch based on routing tables that reflect the geographic relationship of the calling and called party’s serving switches, the geographic relationship of the calling and called party stations, and the Class of Service of the calling party. When the Analyze_Route message is received, the switch will determine the type of call and perform carrier selection based on these switch-based routing tables. The GUBB information will also be used to rate the call. Upon receiving the response to the PORC query, the SSP will use the content of the CalledPartylD parameter to determine the outgoing route for the call. If, in response to a PORC query, the Analyze_Route message contains a TerminatingGUBB value in the GenericDigits parameter, indicating that a PORC query has been performed and the dialed number has been ported outside the rate center, the SSP will perform digit analysis on the GUBB in the post-query dialing plan and determine a “Type of Call” (i.e , intra-network/intra-rate center, inter-network/intra-rate center, inter-rate center/intra-LATA, inter-rate center/inter-LATA). “Rating” (i.e., the switch call processing used to perform charge determination resulting in an Automatic Message Accounting [AMA] record that reflects a correct Structure Code, Call Code, etc.) and “Screening” (i.e., the switch call processing used to perform prefix-based blocking, toll restriction, class of service restriction, etc., as a function of analyzed digits) will be based on the GUBB. If the “Type of Call” is inter-rate center/inter-LATA, or inter-rate center/intra-LATA with the calling party’s designated carrier an entity other than the Local Service Provider, carrier selection will also be done based on the GUBB. After applying the processing described above, the PORC-capable SSP routes the call toward the Recipient Switch. If the SSP determines that the outgoing route is via an SS7 facility, the SSP will generate an lAM that includes the LRN of the Recipient Switch (as the Called Party Number), the PORC DN (as the GAP), the six-digit TerminatingGUBB value in the GenericDigits parameter, and an indicator (0 Bit in the FCI) that a PORC query has been performed. The M Bit (Ported Number Translated Indicator) in the FCI will also be set, indicating that number translation has been performed. In addition, the AM includes the Originating GUBB, if the Calling Party is also ported outside the rate center. (In an LNP environment, the lAM includes the Jurisdiction Information Parameter [JIP], which identifies the originating switch.) If the response to the PORC query does not contain a TerminatingGUBB value in the GenericDigits parameter, indicating that a PORC query has been performed but the dialed number has not been ported or was ported within the rate center, then the response message from the LNP database will be processed the same as an LNP response without location portability, except that if the outgoing facility is SS7, the lAM will include an indicator (0 Bit in the FCI) that a PORC query was performed, in addition to the M Bit indicating number translation. (Note that if digit analysis of the LRN selects an outgoing route that is ME, the SSP will signal the dialed number and not the LRN, as with LSPP.) GR-2982-CORE leaves the support for a suitable Toll Warning Indicator for calls to PORC DNs up to the discretion of the service provider. Specifically, GR-2982-CORE discusses an office-wide option at the switch that performs the LNP PORC query that controls the application of a Toll Warning Indicator (TWI) tone or announcement toward the calling party for calls to PORC DN5 that result in a “toll” call based on digit analysis of the GUBB. GR-2982-CORE allows the switch that performs the LNP PORC query a carrier-specific option to provide TWI tone or announcement on behalf of another carrier or to signal a TWI to the carrier via the ISUP Service Activation Parameter (SAP). 7.2.2 PORC-Capable Intermediate Switch For a call to a number outside the area of portability, the LNP PORC trigger may be encountered at the N-i carrier switch (i.e.. the interexchange carrier’s switch, which is an intermediate switch in the call path) since that carrier is responsible for creating the billing record for the calling party. In this case, the LNP PORC trigger may be encountered when the dialed number is in a portable NPA-NXX unless the incoming ISUP lAM FCI M Bit and the FCI 0 Bit have both been set. 7.2.3 PORC-Capable DonorlSurrogate Donor Switch The donor switch of a ported DN is defined as the switch for which the NPA-NXX of the DN is ‘native”. In PORC scenarios where a switch serves multiple rate centers, a switch may be both the donor and recipient switch for a 17 ATIS-1 000071 location-ported DN. In cases where the originating switch is not PORC-capable (or where the results of a PORC query have been lost due to MF signaling), the donor switch or its “surrogate” will be responsible for performing the PORC query. In cases where no LNP query is performed (i.e., at the originating or N-i carrier switch), the call will route “normally” to a donor switch based on the dialed NPA-NXX or the carrier access code. If the donor switch does not support PORC but does support LSPP (a fundamental LNP assumption), an LSPP query will route the call to a PORC-capable “surrogate’ switch via an LRN. A “surrogate” is a switch that has been pre designated as having responsibility for performing the PORC query on behalf of a non PORC-capable donor switch. Thus a surrogate donor switch is a PORC-capable switch with an LRN whose default GUBB is the same as the default (pre-PORC ported) GUBB of the dialed number. The donor/surrogate switch will launch an LNP PORC query if: 1. The call did not originate on the switch. 2. The NPA-NXX in the CdPN is native to the switch. 3. The 0 Bit in the FCI of the received ISUP lAM is not set. 4. The received DN is portable (i.e., in a portable NPA-NXX). In addition to the above four conditions, the donor/surrogate switch will launch an LNP PORC query if the DN is served by the switch and the line has a GUBB associated with it. If a switch receives a call to a DN served by the switch and the DN has no GUBB associated with it, the switch will complete the call, whether or not the lAM M Bit and 0 Bit are set. If the number is ported outside the rate center, the LNP database will have to process a query from a donor (or surrogate) switch differently than a query from an originating or interexchange carrier switch. It is assumed that the calling party will pay for the call to (the rate center of) the donor switch, but the cost of the last leg of the call will be borne by another party or network(s). Therefore, new AMA information will be needed for that last leg (in a manner similar to remote call forwarding). Since carrier selection is done according to the preference of the billed party, carrier information will also be needed. This “last-resort” charging and carrier information for each location- ported number is assumed to be stored in the LNP database. To alert the LNP database that the SSP needs donor switch information in response to a PORC donor switch query, the LNP P0RC query will include a TriggerCriteriaType of localNumberPortabilityPoRCdonor. The response message will include the appropriate charging and carrier information to allow the switch to continue call processing. If the DN has been ported outside the rate center, the PORC response will include the LRN in the CalledPartylD, a RedirectingGUBB in a GenericDigitsParameter, a TerminatingGUBB in a GenericDigitsParameter, and ChargeNumber and Carrier parameters. The LRN may be either a home LRN (if the switch serves more than one rate center) or a foreign LRN. If the call is to be routed outside the switch, the lAM will include the RedirectingGUBB as well as the TerminatingGUBB (in separate Generic Digits Parameters). The donor/surrogate will discard any JIP received in the incoming lAM and generate and populate a new JIP in the outgoing lAM that contains the NPA-NXX associated with the donor/surrogate switch. In addition, the donor/surrogate switch will discard any Charge Number parameter received in the incoming lAM and generate and populate a new Charge Number parameter in the outgoing lAM using the content of the ChargeNumber parameter in the database response. If a TNS parameter is included (based on GR-394-CORE), it will be populated using the content of the Carrier parameter returned by the LNP database. The PORC-translated called number indicator, bit 0, of the FCI parameter will be set to “1,” “number PORC translated”. If the called number is ported within the rate center (i.e., the content of the CalledPartylD parameter is different from the dialed number, but there is no terminating GUBB), the outgoing lAM will be populated as for an LNP call, with the exception that the PORC translated called number indicator, bit 0, of the FCI parameter will be coded to ‘i ,“ “number PORC translated”. If the donor/surrogate switch does not receive an LRN (i.e., dialed number not ported) as a result of the LNP PORC query, the donor/surrogate switch will include an indication that a PORC number translation has been made to prevent subsequent PORC queries. 7.2.4 PORC-Capable Recipient Switch The PORC recipient switch is the switch that serves a PORC (location ported) number. To support rating and carrier selection of outgoing calls from a PORC number, as well as to support processing of intraswitch calls to a PORC DN, the recipient switch must associate a PORC DN it serves with a six-digit GUBB value of the form 18 ATIS-1 000071 ‘NPA-NXX’ that reflects the rate center of that DN. This GUBB value will be used to populate the Originating GUBB in the ISUP lAM Generic Digits Parameter (GDP) for call originations from the PORC DN, when appropriate, and will also be used as the Terminating GUBB for calls to the PORC DN when that DN is served by the switch. The switch must also associate a ten digit LRN of the form ‘NPA-NXX-XXXX’ with the PORC DN. The first six digits of the LRN associated with a PORC DN served by a switch may also be used for populating the JIP for that DN during call origination. For inter-switch calls to the Recipient Switch, the incoming lAM will include the LRN of the Recipient Switch (as the Called Party Number), the PORC DN (as the GAP), the FCI (with both the “M” and “0” bits set to indicate that a PORC query has been performed), and the Terminating GUBB (in the Generic Digits Parameter). The Recipient Switch is expected to complete the call to the PORC DN according to the call completion procedures for LNP. 73 Impacts to Circuit Switched Networks The PORC solution described in GR-2982-CORE will impact the functions, data, and signaling provided by SSPs and the LNP database that support LSPP. These impacts are summarized below. • Switches within the area of portability A PORC-capable originating switch will use essentially the same criteria as it would for LSPP to determine whether to initiate an LNP query, subject to modified escape criteria (e.g., 0+ calls and calls destined for non-LSP carriers may result in an LNP query being launched). For PORC, the criteria may be different because the appropriate carrier (or operator services system) cannot be determined prior to a query being sent to an LNP database for calls to DNs that have ported outside of the rate center. There are slight differences in the information provided in a PORC LNP query as compared to an LSPP LNP query. When a PORC-capable originating switch sends a query to the LNP database, the query will include a TriggerCriteriaType of localNum berPortabilityPORC rather than locaIN umberPortability. The most significant impact on a PORC-capable originating switch is the Post-PORC-Query call processing that is performed on the GUBB to support carrier selection and AMA generation. If the outgoing route associated with a call to a PORC DN involves an ISUP trunk, the AM generated by the PORC-capable originating switch will contain additional information that would not be present in an lAM associated with a call to a DN that has ported under LSPP. Specifically, the lAM generated by the PORC-capable originating switch associated with a call to a PORC DN will include the terminating GUBB in a Generic Digits Parameter, and a value of”i” in BitO of the FCI indicating “number PORC translated”. If the called number is ported within the rate center, then no terminating GUBB will be included in the response from the LNP database or in the outgoing AM. The outgoing lAM associated with a call to a number that is ported within the rate center will still include a value of “1” in Bit 0 of the FCI indicating “number PORC translated”. PORC-capable originating switches may also support functionality to provide a “toll warning” indication. This functionality is not something that would be present in an LSPP-capable originating switch. In terms of the content of the PORC LNP query/response, the outgoing lAM generated, and the capability to provide a “toll warning” indication, the impacts on a PORC-capable intermediate (i.e., interexchange carrier “N-i” switch) are comparable to those associated with a PORC-capable originating switch. One difference in the processing at a PORC-capable N-i switch is the criteria used to determine whether a query should be sent to the LNP database. If the FCI M Bit and the FCI 0 Bit have both been set in an incoming SUP IAM. a PORC-capable intermediate switch will not launch an LNP query. A PORC-capable N-i switch is expected to use the terminating GUBB information provided in the response from an LNP database to support AMA generation associated with the call. A PORC-capable recipient switch must be able to process incoming and outgoing calls to/from a PORC DN. To support rating and carrier selection of outgoing calls from a PORC number, as well as intraswitch calls to a PORC DN, a PORC-capable recipient switch must associate an LRN and a GUBB with the PORC DN. As described in Clause 7.2.4, the GUBB assigned to the DN will be used to populate the Originating GUBB in the ISUP GDP of IAMs associated with outgoing calls from a PORC DN, and will be i9 ATIS-1 000071 used as the Terminating GUBB for calls to the PORC DN when that DN is served by the switch. This functionality goes beyond what would be expected of a recipient switch in an LSPP environment. Donor switches that are PORC-capable will be expected to initiate a PORC query to an LNP database if no previous LNP query has been performed (i.e., neither the M Bit nor the 0 Bit in the FCI of a received AM is set), or in scenarios where the 0 Bit is not set, the dialed number belongs to a portable NPA-NXX, and the DN is either not served by the donor switch or has a GUBB associated with it (i.e., it is a PORC DN). The impacts on the PORC-capable donor switch associated with generating an LNP query and using the information in the response to rate and route the call to the recipient switch are comparable to those described above for PORC-capable originating switches. (Note that if the DN is served by the switch but is not a PORC DN, and the call is received with the 0 Bit not set, the donor switch will complete the call to the DN as it normally would.) The notion of a “surrogate” donor switch has impacts on donor switch processing that go beyond what is expected of a donor switch operating in an LSPP environment. If the donor switch is not PORC-capable, and the incoming call is received with neither the M Bit nor the 0 Bit set, the donor switch will launch an LSPP query. The response from the LNP database will contain the LRN of the surrogate (PORC-capable) donor switch. In this scenario, the surrogate donor switch will be responsible for launching the PORC LNP query. There are additional impacts on the post-query processing performed by a donor/surrogate switch due to the need to bill the calling party for the call leg from the donor or surrogate donor to the recipient switch. If the PORC donor/surrogate switch receives a response to a PORC LNP query that contains a foreign LRN and no Terminating GUBB (because the number has been ported within the rate center), then LSPP processing will be implied with the addition of the 0 Bit in the FCI of any outgoing AM set to number PORC translated”. If the number has been ported outside the rate center, the response from the LNP database to a PORC query initiated by a donor/surrogate switch is expected to contain the LRN, the Charge Number, the Terminating GUBB, the Redirecting GUBB, and the Carrier. The donor/surrogate switch will route the call forward based on the LRN and Carrier information received in the LNP response. Based on provisioning, the donor/surrogate switch will be responsible for generating AMA for the call leg to the recipient switch and appending it to the normal AMA record generated by the donor switch. • LNP Database The PORC solution described in GR-2982-CORE impacts the data that must be stored in the LNP database as well as the processing and signaling supported by the LNP database. The LNP database must store a GUBB and LRN for each PORC DN and must support the ability to process (including acceptance of new Trigger Criteria Types) and respond to PORC queries. In addition, to support PORC queries from donor switches, the LNP database will have to be capable of storing and returning Carrier information to support the routing of the call to the recipient switch, and a Charge Number and Redirecting GUBB to facilitate proper billing for that call leg. 7.4 Impacts to IP Networks/IP Network Considerations IETF RFC 4694 and ATIS-1000679.2015 describe mechanisms for signaling LSPP-related information, such as the dialed number, LRN, JIP, and FCI M Bit, forward by including parameters associated with tel Uniform Resource Identifiers (URIs) passed in the SIP P-Asserted-Identity and Request-URI headers. To support a GR 2982-CORE-based PORC solution in an IP environment, additional extensions to SIP will be needed to allow information such as the Terminating GUBB, Redirecting GUBB, and FCI 0 Bit information to be signaled between network nodes in support of call setup involving PORC customers. RFC 4694 and ATIS-1000679.2015 define a mechanism for carrying the JIP/Originating GUBB information by associating an “rn’ parameter with the tel URI in the P-Asserted-Identity header that contains information associated with the Calling Party. RFC 4964 and ATIS-1000679.2015 also describe the inclusion of an “rn’ parameter in the Request-URI header that contains the dialed number. The “rn’ parameter within the Request URI header is used to carry the LRN associated with a ported number. RFC 4964 and ATIS-1000679 also define the “npdi” parameter that is also carried in the Request-URI header to indicate that a (LSPP) number portability query has been performed. One way to support GR-2982-CORE-based PORC call setup in an IP environment would be to define new parameters that could be carried in the Request-URI to signal the Terminating GUBB as well as indicate that a PORC LNP query has been performed (i.e., the equivalent of the FCI 0 Bit). Additional 20 ATIS-1 000071 study would be needed to identify an appropriate SIP mechanism for communicating the Redirecting GUBB, since it is not associated with the calling or the called party. Neither RFC 4694 nor ATIS-1000679 addresses the specifics of the signaling to/from an LNP database. If it is assumed that existing TCAP-based mechanisms will continue to be used to support NP queries/responses in an IP environment, then the impacts of supporting a GR-2982-based PORC solution will be the same as those described in Clause 7.3 for a circuit-switched environment. However, if it is assumed that evolution to an IP environment will require a new NP query/response architecture and/or protocol, then further study will be required to examine viable alternatives for supporting this functionality. 8 Non-Geographic Location Routing Number (NGLRN) The NGLRN solution does not distinguish between wireless and wireline TNs. The solution works the same for both. NNP is generally thought to mean the ability to port a TN to a different geographic area. More specifically, it is thought to be the ability for the geographic area associated with the ported TN to be different than the geographic area associated with the LRN used for number portability. In practice this is believed to mean the ability for the ported TN and LRN to be in different LATAs, because porting geographically within the same LATA is technically and operationally feasible today. The solution described in this clause uses a non-geographic (NG) area code for LRNs. While this will require some new capabilities, it avoids many significant issues that have been built into the communications networks by geographic number assignment, geographic-based call processing, and interLATA call processing. The key elements of the solution are: • A new NG area code and administration processes for LRNs (NGLRN). • A network of gateways to host the NGLRNs for call termination (Non-Geographic Gateway [NGGW]). • The ability for ALL service providers to route calls to NGLRNs. In addition to these key elements the solution proposes the following: • Service providers will need to route calls to an IP network to complete calls to NGLRNs and Non- Geographic Telephone Numbers (NGTNs). o This could be the service provider’s own IP network or one they have an agreement with for this purpose. o Even SS7 switches will be able to route to an IF network based on the NG area code. • The NG area code can also be used for TN assignment to consumers (NGTN), i.e., service providers can assign TNs from the NG area code to consumers. o NNP customers, who use either NGTNs or NNP TNs, must have either wireless or VoIP service. o Calls to NGTNs should be excluded from interLATA requirements. • There needs to be administrative processes that handle the allocation and addressing for NGLRN5 and NGTN5, as well as the porting of NGTNs. o For conservation reasons, NGLRNs and NGTNs should be assigned and routed on a 10-digit basis, i.e., not six-digits. • NGLRNs and NGTNs should be serviced by IP networks. o NGGWs should be P network elements providing IP interconnection. o Calls terminating on NGGWs should be transported over IF networks. • There should be an industry-led certification process for NGGW providers. o NGGW providers should be required to offer interconnection. o Service providers can be NGGW providers. o NGGW providers should not be required to offer NGLRN service to other service providers, i.e they could provide it only for their own NGTN5 and NGLRNs. • Providing Non-Geographic (NG) capabilities to customers should be voluntary to service providers. i.e., service providers are not required to provide their customers’ NG capabilities. 21 ATIS-1 000071 The solution would work as follows: • Activating the NGLRN: o Service provider obtains an NGLRN through an administrative process. o Service information associated with the NGLRN, e.g., the NGGW address associated with the NGLRN, is published to the industry. o The NGGW provider activates service to the NGLRN. • Assigning an NGTN to a customer: o Service provider obtains an NGTN through an administrative process. o Service provider associates an NGLRN (or other service information) with the NGTN, o The NGTN:NGLRN association is published to the industry. o Assign the TN to the customer. • Porting a geographic TN: o The NGLRN is associated with the ported TN in the porting process. There are many issues that would need to be evaluated and decided by the industry to implement this solution. These issues can be divided into the following broad categories: • Policy considerations. • The NG area code. • Administration of NG resources. • NG call processing. • NGGWs and NGGW providers. 8.1 Policy Considerations Many policies in U.S. communications are based on the association of a TN to a specific geographic area. The very nature of NNP breaks the association of the TN to a specific geographic area. This clause will identify policy issues that should be addressed related to NNP. 8.1.1 InterLATA Call Processing Some carriers have a regulatory requirement to offer their customers the ability to choose an interexchange carrier (IXC) to transport their calls between LATAs. In these cases carriers identify whether a call is interLATA by the dialed central office (CC) code. If the CO code is in a different LATA than where the call originated, the carrier will hand off the call to the customer’s chosen IXC. In an NNP environment it is possible that the carrier will not be able to correctly determine whether the call is in a different LATA. The CO code could be in a different LATA but the TN could have been ported into the LATA where the call originates. In the NGLRN solution the carrier will not be able to identify whether the call is destined for another LATA because the NGLRN will not be associated with any specific LATA. To resolve this it is likely that policies would need to be changed for calls to NNP TNs. The requirement for interLATA call processing could be rescinded for calls to NNP TNs. In this scenario, calls to NGLRN5 would not be subject to interLATA call processing. Carriers could choose to handle this call as they preferred. They could route it directly to their NG transport provider or directly to the NGGW. Conversely they could choose to hand it off to the customer’s IXC for call processing as they do today. Another alternative is to rescind all interLATA call processing requirements. The environment that introduced interLATA call processing is very different than todays environment. Wireless carriers that no longer have interLATA requirements account for a significant amount of traffic. Incumbent Local Exchange Carriers (ILECs) are no longer restricted from providing IXC service. The dominant IXCs of the late-90s/early-OOs have been acquired by local carriers. Perhaps NNP could be a catalyst for rescinding all interLATA requirements. 22 ATIS-1 000071 8.1.2 N-I Query Requirement LNP came about at a time when there were many competing IXCs and ILECs were restricted from providing IXC service. Neither of those things is true today. However, in this environment the IXCs wanted to ensure that they were involved in this important aspect of call processing. The industry agreed to an N-i query architecture. In this solution, the second to last carrier in the call would perform the LNP query. The FCC integrated this solution into LNP regulatory requirements. In practice what this means is that carriers that are subject to interLATA call processing requirements must suppress the LNP query for interLATA calls and hand the call off to the IXC unqueried. The XC will perform the query and route the call to the correct network. This also ensures that calls are queried early in call processing and not sent to the network that was assigned the CO code only to find that the number has ported to a different network. In an NNP environment, a call could look like it is interLATA but actually be intraLATA. In this case it could be more efficient for the originating carrier to know this, but they may not be able to do this with the N-i requirement. One way of relieving this issue is to rescind the N-i requirement. There is not a need to require an originating query, just not to require an N-i query. A carrier could choose to query all calls on their originating network and route calls to the NNP numbers accordingly, or they could choose to handle calls as they do today, i.e., if a call looks like it is interLATA, hand it off to the IXC and let the XC query the call. It would be important to ensure the call is queried before it gets to the network that is assigned the CO code. Today since it is a requirement for the N-i network to query the call, there is no charge to the originating carrier for the IXC to perform the query. If N-i were rescinded, it is possible that the IXC could want to charge the originating carrier for the query. If this were an issue, the N-i arrangement could be grandfathered, After all, the IXC would not be doing any more work than it is today. 8.1.3 Routing to NGLRNINGTNs The one main requirement for all carriers is that they have the ability to route calls to NGLRN/NGTNs. To do this, carriers will either access routing information related to NGLRN/NGTNs and route to NGGWs, or they can route calls with an NG area code to a carrier that can route calls to NGGWs. The latter means that carriers may need to enter into an agreement with an NG transport provider to complete calls to NGLRN/NGTNs. Policies would have to be established to ensure this requirement is met. 8.1.4 Providing NNP Service to Customers In the NGLRN solution there is no need to require carriers to provide NNP service to their customers. Only carriers that choose to provide NNP service would need to implement processes and infrastructure to support NNP. The only NNP requirement on a carrier is that it can route calls to NGLRN/NGTNs. 8.1.5 NGGW Policies Because NGGWs are critical to NNP call processing, there should be an industry-led certification process for NGGWs. For example, it may be a requirement for NGGWs to offer interconnection to any certified carrier. There may be certain uptime commitments. There is no need to require carriers to provide NGGW service. This should be something that carriers choose to do. A carrier that does provide an NGGW should not be required to offer NNP services to any other carrier’s customers. That is, they can deploy an NGGW for their own customers only. As has already been noted, a carrier that deploys an NGGW may be required to offer interconnection to other carriers to terminate calls to their customers. 8.1.6 The NG Area Code There are various process and policy issues the industry will need to consider when selecting the NG area code; including: 23 ATIS-1 000071 • Should the area code be an easily recognizable code, e.g. have repeating or sequential digits? • To account for growth, should area codes be reserved that have similar characteristics to act as an identifier for consumers, e.g., have common digits, similar to the way 8YY indicates toll-free? • How should other NANP countries be addressed? If needed, some smaller countries may be able to use a central office code in their existing area code, rather than a new NPA, for the same purpose. 8.2 Administration of NG Resources The new NG area code(s) will be a new numbering resource that will be served solely by lP networks. As such, the industry can implement administrative processes that are more advanced than processes today that need to account for legacy Public Switched Telephone Networks (PSTN5). For example, administrative processes that are handled today by different parties can be combined, such as allocation and porting. Or administrative processes that are handled today by a single authoritative registry can be handled by multiple distributed registries, all managing the same information. Alternatively, these administrative processes could be integrated with existing processes such as the North American Numbering Plan Administration (NANPA), the National Number Pool Administration (PA), the Local Exchange Routing Guide (LERG), and the Local Number Portability Administration (LNPA). 8.2.1 Porting Geographic TNs The most straightforward administrative process will be porting geographic numbers to NGLRNs, i.e., NNP. The LNPA operates seven distinct regional Number Portability Administration Centers (NPACs). These are systems that provide Application Programming Interfaces (APIs) to service providers for the purpose of enacting ports and receiving routing information about ports. The seven NPACs are divided by area codes. That is, each area code is served by one, and only one, NPAC. Not all service providers connect to all NPACs. It seems logical when porting a geographic TN to an NGLRN that the ported TN area code-to-NPAC association should remain in place. For example, if a 212 TN is being ported to an NGLRN it should be ported in the Northeast regional NPAC. This would provide the least disruption to the existing processes. It would also mean that if service providers wanted to be sure to be able to route to all NGLRNs, they would need to connect to all NPAC regions. 8.2.2 Allocating Numbering Resources This clause describes issues involved in allocating NGLRNs and NGTNs. 8.2.2.1 NGLRNs Depending upon the industry’s chosen solution, one or more entities would manage the allocation of NGLRNs to service providers, i.e., they would administer the NG area code. To conserve NGLRNs in this solution they should be assigned on a 10-digit basis. The service provider would submit administrative and service data related to providing service for the NGLRN. Examples of data that could be collected includes: • Administrative: o Service provide name. o Service provider contact. 0 NGGW provider name. o NGGW contact. • Service: o NGLRN. o NGGW address. 24 ATIS-1 000071 Other service providers would likely need access to the service data to complete calls. Service data should be available almost immediately, so service could be enabled quickly. Service providers, regulators, and law enforcement may need access to administrative data in the event of service issues. Some data may be relevant to the general public. The industry would need to decide the specifics of the data and who has access to it. 8.2.2.2 NGTNs Allocating NGTNs would be similar to allocating NGLRNs, NGLRNs could be allocated to service providers for assignment to consumers on a 10-digit, just-in-time basis. That is, an API between the service provider and the administrator could enable an immediate assignment as service is being established for the customer. Similar administrative and service data would need to be submitted and possibly shared. 8.2.2.3 Porting NGTNs Porting an NGTN could be done in at least two different ways. It could be done as it is today, where the NG area code is associated with an existing NPAC region or a new one, and porting the NGTN is a matter of changing the NGLRN. Alternatively, it could be done by changing the NGTN-to-service-provider association in the administrative systems that allocate the NGTNs to service providers. 8.3 NG Call Processing This clause discusses solutions and issues related to call processing for both NGTNs and NGLRNs. 8.3.1 InterLATA Call Processing Calls to NGTNs should be excluded from interLATA call processing requirements It would be too difficult to determine whether the call was interLATA both during and after the call. 8.3.2 TOM to Geographic TN with NGLRN Originating TDM networks will process the call as they do today in one of two ways; 1) they do the LNP dip immediately, or 2) they determine that they need to hand the call off to another service provider without doing an LNP dip. In the latter case, call processing for this service provider is no different than it is today. In the former case, the service provider will receive the NGLRN when it does the LNP dip. They will have translations set up to route calls to the NG area code to an P network for completion. Since the NG area code will be dedicated to NG service, it will be easy for the TDM network to identify and route NG traffic. The IP transport network could be the service provider’s own network or a network that they have an agreement with for transport of NG traffic. Once on the IP transport network, the call will route to the NGGW based on the service data associated with the NGLRN, e.g., NGGW address. If the service provider hands off the call to another network for the LNP dip, that network will handle the call as described in the two paragraphs above. 8.3.3 TOM to NGTN A call from an originating TDM network to an NGTN can also be handled two ways; 1) the originating network can do the dip and send the call to the P network for completion, or 2) the originating network can send the call to the lP network based on the NGTN. In the latter case the P network does the LNP dip and completes the call based on the NGLRN. 8.3.4 IP to NGTN & NGLRN All NGTNs have an associated NGLRN. The IP network will perform an LNP dip to obtain the NGLRN then route based on the NGLRN to the terminating NGGW. It is possible that the network would translate the NGLRN to 25 ATIS-1 000071 another resource such as a URI or Service Profile Identifier (SPID); that is something that the industry can evaluate. 8.3.5 NG Originated Calls to 9.4-1 Calls to 9-1-1 have had to account for the possibility that the calling TN does not indicate the actual location of the caller. This has had to be addressed for both wireless callers and VoIP callers. Both of these solutions rely on a pseudo-automatic number identifier, or pANI.19 Calls to 9-1-1 from NNP TNs and NGTNs will use one of these two solutions depending on whether it is wireless or V0IP. 8.3.6 NGGWs & NGGW Providers NGGWs can be thought of as an IP version of the existing TDM LATA tandems. NGGWs host the NGLRNs. Terminating service providers connect to the NGGW and provide them their NGLRN. When they acquire the NGLRN, they provide the NGGW info to the administrator and this is shared with other service providers. Calls to the NGLRN are routed to the NGGW and the NGGW routes the call to the service provider. Service providers can establish their own NGGW; they do not need to rely on another provider. NGGW providers need to offer interconnection for all to ensure call completion for NG services. NGGW providers would need to be certified by the industry. Details of the certification process would need to be decided by the industry. 9 Internet Interconnection The crux of what makes Local Number Portability “local” and nationwide number portability difficult is the requirement that local interconnection take place within the LATA containing the rate center with which the number is associated. The Internet Interconnection solution considers the implementation of NNP in an environment in which this requirement for interconnection is replaced with a default requirement to provide a P01 on the Internet. Under the terms of the 2011 Connect America Fund (CAF) Report and Order, carriers are free to negotiate alternate forms of interconnection and corresponding compensation. National carriers have already negotiated agreements that involve the exchange of traffic in IF at a small number of POls, often carrier hotels, rather than on a per-LATA or more molecular basis. NNP between service providers with such agreements need not present call routing or settlements issues. For NNP to be generally deployed, however, the problem of interconnection between more localized carriers in different states and LATAs must be addressed. While carriers are free to negotiate bilateral interconnection they are not compelled to so, so some kind of default interconnection paradigm is required. Today that paradigm is per-LATA TDM interconnection, direct or indirect. This is not an efficient approach as voice communication evolves into what is essentially an application on broadband networks. It is therefore proposed that, where service providers cannot agree on the terms of interconnection, the default is for each to provide a P01 on the Internet, essentially a set of Session Border Controller addresses where traffic can be delivered. Because all service providers must have Internet Connectivity (essential if they are to morph into the broadband providers envisioned in the National Broadband Plan), whether through peering or transit, this does not represent a large imposition. Once IP interconnection is achieved, whether through bilateral agreements or default, the implementation of NNP will be greatly simplified. The Internet Interconnection approach does not require a recipient carrier to provide a physical P01 in the donor LATA nor require an originating local service provider to bear the normal toll costs of delivering a call ported to a foreign LATA to the recipient carrier. 19 A pANI is a non-dialable TN that is used as the calling TN for mobile and VoIP 9-1-1 calls to provide proper routing and delivery of customer information to the PSAP. See . 26 ATIS-1 000071 Under Internet Interconnection, all service providers must be able to resolve telephone numbers to IP addresses for interconnection. This may be accomplished in a number of ways, whether directly by a secure query infrastructure that replaces the functions of the NPAC and LERG or indirectly via existing numbering aggregation constructions such as central office codes and LRNs. Originating service providers will resolve the dialed NANP number for all calls to an interconnection address whether based on bilateral agreements for interconnection (which may still predominate) or the default Internet P01 and route the call to its destination regardless of the location of the called number. 10 Impacts on Regulatory Related Services This clause considers impacts on regulatory services such as Emergency Services [i.e., Enhanced 9-1-1 (E9-1-1) and Next Generation 9-1-1 (NG9-1-1)] and National Security/Emergency Preparedness (e.g., WPS, GETS, and NGN-PS). 10.1 Emergency Services This clause describes the impacts of Nationwide Number Portability on Enhanced 9-1-1 (E9-1-1) and Next Generation 9-1-1 (NG9-1-1) and considers transitional architectures involving the interconnection of Next Generation Emergency Services Networks with legacy originating networks and legacy Public Safety Answering Points (PSAPs). 10.1.1 Enhanced 9-1-1 (E9-l-l) Enhanced 9-1-1 (E9-1-1) Service is a public safety feature that allows emergency calls to be routed to a designated Emergency Service bureau when the three-digit telephone number “9-1-1” is dialed. The Emergency Service bureau is a centralized agency or facility that a municipality operates to receive and respond to requests for emergency services such as police, fire, and Emergency Medical Services (EMS). Attendants at the Emergency Service bureau may be personnel from the police or fire department, or any agency designated to receive emergency calls. In general, the centralized answering point for emergency calls is referred to as a PSAP. Existing E9-1-1 Service architectures, and any evolution to the service architecture brought about by changes in technology and the regulatory environment, must support critical functionality to facilitate the delivery of emergency services to those in need. Selective Routers (SRs) are a critical element of legacy Emergency Services Networks that support E9-1-1 Service. SRs (also known as E9-1-1 Tandems) are specially-equipped central offices that provide the tandem switching of 9-1-1 calls. Selective routing is the process by which 9-1-1 calls are routed to the appropriate PSAP (or other designated destination) based on the caller’s location. For emergency calls that originate in legacy wireline networks, the caller’s location is represented by their 10-digit telephone number or Automatic Number Identification (ANI). For emergency calls that originate in legacy wireless networks, selective routing is done based on a 10-digit key that represents the caller’s location. In addition to providing selective routing functionality, SRs control the delivery of the voice call to the PSAP, as well as emergency call transfer and certain maintenance functions for each PSAP. Today, SRs typically receive emergency calls over dedicated Multi-Frequency (MF) or SS7 trunk groups from wireline end offices and Mobile Switching Centers (MSC5). They use information received in incoming signaling to identify the PSAP that serves the area in which the call originated. SR5 deliver the emergency call to the PSAP, typically over traditional Centralized Automatic Message Accounting (CAMA)-like or Enhanced MF interfaces, with a key piece of information that allows the PSAP to query an Automatic Location Identification (ALl) database for the caller’s location information. Having retrieved the location information, the PSAP can facilitate the dispatch of emergency personnel to the incident location. At a high level, the primary capabilities of E9-1-1 Service consist of the following: • Emergency calls are detected based on the dialed digits “9-1-1”. 27 ATIS-1 000071 • Emergency calls are selectively routed via an SR/E9-1-1 Tandem switch to an appropriate serving PSAP, based on the caller’s location (or approximate location). Note that in some failure cases, default or alternate routing may apply. • A callback number is delivered to the PSAP with the call (although there are some exceptions for certain wireless implementations and non-initialized handsets). • The PSAP uses information received in call setup signaling to query the ALl database to obtain location information for the caller. • The PSAP call-taker may transfer the call to another agency for further handling (e.g., for dispatch). As described above, a unique feature of E9-1-1 is selective routing. Selective Routing allows 9-1-1 calls to be routed to the appropriate PSAP based on the calling number/AN I, or other location information that may be provided with the call. To support selective routing, an SRIE9-1-1 tandem will interact with a Selective Routing Database (SRDB). The SR provides the calling number/ANI or location key to the SRDB, and the SRDB returns an Emergency Service Number (ESN). An ESN is a three- to five-digit number representing a unique combination of emergency service agencies (law enforcement, fire, and EMS) designated to serve a specific range of addresses within a particular geographical area referred to as an Emergency Service Zone (ESZ). The SR uses the ESN to select the path to the destination PSAP for the emergency call. The ESN may also play a role in selecting the transfer-to PSAP if the primary PSAP requests selective transfer of the emergency call. The introduction of the ANI feature was critical to supporting E9-1-1 because it allowed delivery of the 9-1-1 caller’s telephone number to the PSAP with the call. Using this information, the PSAP could identify the caller and, if necessary, call back the caller. A CAMA-like Multi-Frequency (MF) signaling scheme was initially used to support ANI delivery to the PSAP. This signaling scheme, referred to as Traditional MF, is still in use in certain areas today, and supports the delivery of a seven-digit number, along with a single Numbering Plan Digit (N PD) that can be used to derive the NPA. A Feature Group D-like signaling scheme, referred to as Enhanced MF (E MF), is more commonly used between SRs and PSAPs, and supports the delivery of either one or two 10-digit numbers to the PSAP with the call, along with an ANI II value that tells the PSAP Customer Premise Equipment (CPE) whether to display the information using a steady or flashing display. The delivery of the wireline 9-1-1 caller’s telephone number allows PSAP5 to access the location information associated with the telephone number by querying the ALl database. In the case of wireline emergency callers, the ALl database contains static telephone number-to-street address mappings. The carrier that serves the PSAP typically operates the ALl databases. Enhanced wireless emergency services (i.e., wireless E9-1-1), requiring wireless carriers to provide the location of the wireless 9-1-1 callers to PSAPs, are mandated by the U.S. Federal Communications Commission (FCC). For the initial stage, Phase I, the FCC required Wireless Service Providers (WSP5) to upgrade their networks to support delivery of a callback number and an identifier of the cell site or base station location where the 9-1-1 call originated to the PSAP. Phase I of the FCC’s mandate was required to be implemented by April 1998. Phase II requires delivery of E9-1-1 service that includes the latitude and longitude of the 9-1-1 call within specific accuracy and reliability parameters, depending on the location technology that the carriers have chosen. For network-based technologies, location must be accurate to within 100 meters for 67 percent of calls, and 300 meters for 90 percent of calls. For handset-based technologies, location must be accurate to within 50 meters for 67 percent of calls, and 150 meters for 90 percent of calls. While the original order called for handset-based geographic location to be provided to the PSAPs by October 1, 2001, the FCC has since introduced a phased-in implementation schedule for handset- and network-based location that extends until January 2019. The industry standard for E9-1-1 Phase I, J-STD-034, uses the term Emergency Services Routing Digits (ESRD) for the cell site identifier that is associated with an emergency call. With E9-1-1 Phase I. the SR uses the ESRD to selectively route the wireless 9-1-1 call to the appropriate PSAP. Specifically, the SR queries the SRDB using the ESRD. As in the wireline architecture described above, the SR receives an ESN in the response from the SRDB and associates the ESN with the destination P SAP. To fulfill Phase II requirements for the delivery of latitude and longitude associated with the 9-1-1 call, wireless carriers have had to deploy location determination technology in their networks. The location technology may be handset-based (e.g., Global Positioning System [GPS]) or network-based (e.g., Time Difference of Arrival [TDOA], Angle of Arrival [AOA], etc.). Technically, if SS7 ISDN User Part (ISUP) signaling is supported between the MSC and the SR/E9-1-1 tandem, Phase II location information could be delivered in the ISUP Initial Address Message (lAM), provided the wireless network is able to determine the location coordinates prior to call setup. 28 ATIS-1 000071 However, due to limitations in today’s location determination technology that result in delays in obtaining Phase II location, existing Phase II implementations only support the delivery of Phase I information or a location key in the call setup signaling. Phase II location information is delivered over a separate data link between the wireless network and the emergency services network. The E2 protocol defined in J-STD-036-C and NENA-05-001 is typically used over the data link between the wireless network and emergency services network to requestldeliver initial caller location information to the PSAP via the ALl system, and to provide updated location information when requested. There are also some implementations that use the Mobile Location Protocol (MLP) between the ALl system and the Mobile Positioning Center (MPC)/Gateway Mobile Location Center (GMLC) in the wireless network to obtain the location associated with an emergency call. The method in which Phase II location is delivered by the wireless network to the emergency services network via a separate data link is referred to as the Non-Call Associated Signaling (NCAS) approach in J-STD-036. There are two variants of this approach: one that is just referred to as NCAS, and the other that is referred to as Wireline Compatibility Mode (WCM). Of the two variants, the WCM approach is more widely deployed. With the WCM approach, all the FCC-mandated Phase I and Phase II location information and the callback number is sent over a separate data link to the ALl database. The MSC may support either an ME or an SS7 interface over which a single 10-digit number is delivered to the SR, and the SR supports an interface where only a single 7/1 0-digit number is delivered to the PSAP. The one piece of information sent by the MSC to the SR is referred to as the Emergency Services Routing Key (ESRK). The ESRK represents an ESZ in the jurisdiction of a PSAP, and also uniquely identifies the 9-1-1 call. The ESRK also uniquely identifies an MPC/GMLC in the wireless network. The MSC stores a set of ESRKs in its database and assigns them to wireless 9-1-1 calls. Upon completion of the 9-1-1 calls, the ESRKs are released to be assigned to other 9-1-1 calls. The PSAP receives only the ESRK from the SR and uses it to query the ALl database to receive the callback number, cell site identifier (ESRD), and the latitude and longitude information for the mobile caller. With the wireless NCAS approach, the MSC sends a callback number and the cell site identifier (ESRD) to the SR using either MF or SS7 signaling. Call setup using the wireless NCAS approach is identical to the call setup in the E9-1-1 Phase I scenario documented in J-STD-034. The SR uses the ESRD to interact with the SRDB. and the SRDB returns an ESN that causes the SR to route the 9-1-1 call to the appropriate PSAP. The interface between the SR and the PSAP will typically be an Enhanced MF (E-MF) interface that supports the delivery of both the callback number and the ESRD to the PSAP, although hybrid arrangements (involving the real-time update of the ALl data via the SR) may be used if the PSAP supports either a Traditional MF interface or the delivery of a single 10-digit number via an F-ME interface. Existing VolP implementations use the wireless E9-1-1 techniques described above as a basis for delivering emergency originations from VoIP callers to legacy PSAPs that are served by SRs. To support emergency calling, VolP customers self-provision their location with the V0IP provider. This location information is made available to a system referred to as a V0IP Positioning Center (VPC). When a 9-1-1 call is initiated, the VPC allocates an Emergency Services Query Key (ESQK) to the call (in a manner similar to the way that an MPC/GMLC allocates an ESRK to a wireless emergency call). The ESQK identifies a call instance at a VPC, and is associated with a particular SR/ESN combination. The ESQK is delivered to the SR (with or without a callback number) via an Emergency Services Gateway (ESGW) over an ME or SS7 interface. The SR then queries the SRDB using the ESQK to determine the route (i.e., trunk group) to the target PSAP. The SR delivers the ESQK to the PSAP via MF signaling (possibly with a callback number, depending on the capabilities of the PSAP interface). The PSAP uses the ESQK to query the ALl system, and the ALl system steers the query back to the VPC (in the same manner as it would steer a query to an MPC/GMLC for a wireless emergency call). The VPC responds with the provisioned location information and a callback number. The ALl system then passes the location and callback information to the PSAP. 10.1.1.1 Number Portability Considerations To support Local Number Portability, a number of changes were made in the processes that are used to provision data into the SRDB and ALl systems. These processes ensured that any authorized company could send end user telephone number records to the appropriate Database Management System provider for any valid NPA NXX that had access to 9-1-1, and that the appropriate donor and recipient service providers (and their contact information) could be identified and the associated records correctly migrated between the providers’ systems. With the adoption of these process changes and the provisioning of data into the appropriate SRDB and ALl systems, emergency calls from ported customers could be routed properly to the appropriate PSAPs and location information associated with the emergency calls could be returned via the ALl system to the PSAP. 29 ATIS-1 000071 An issue was identified with respect to the ability for the PSAP to call back ported users that had undergone service provider portability (e.g., porting from a wireline phone to a wireless phone [or vice versa], or between wireless phones). If, for example, a customer wanted to port their service from wireline to wireless, there would be a period during which both the wireless and wireline phones could dial 9-1-1, but callback would only be possible to one of the phones, depending upon the stage of the porting process. For example, if the 9-1-1 call is dialed from the wireless phone before the appropriate porting databases are updated, the callback will go to the wireline phone. If the 9-1-1 call is dialed from the wireline phone after the appropriate porting databases are updated but before termination of wireline service, the callback will go to the wireless phone. The same issue could occur if porting were between different wireless service providers, although the interval during which both wireless phones can dial 9-1-1 and callback is possible to only one of the phones (depending upon the stage of the porting process) is expected to be much smaller. This callback issue was handled via a public and PSAP education program spearheaded by the National Emergency Number Association (NENA). The most significant issue with respect to Number Portability (both LNP and NNP) is the ability to deliver emergency calls originated by ported users to PSAPs that support traditional (i.e., NPD ÷ 7-digit “CAMA-like”) ME interfaces from their serving SRs. Today, there are PSAPs that use CPE that is only capable of supporting an interface to the SR that delivers a Numbering Plan Digit (NPD) and a seven-digit Calling Station Number/ANI. An NPD is a single-digit representation of an originating station’s NPA code. The NPD is used in E9-1-1 service to unambiguously identify to the PSAP which of up to four NPA5 serves the originating station. Translations at the SR contain a default mapping of NPAs to the NPD digits 0, 1, 2, or 3 for use on NPD + seven-digit ME PSAP interfaces. In cases where the Calling Station Number/ANI is available, but the call either cannot be properly routed by the SR, or the call requires special attention by the PSAP attendant, the Calling Station Number/ANI displayed may optionally be flashed to alert the answering PSAP attendant. For each ESN known to the SR, translations at the SR contain an indication that denotes whether a ‘flashing display” should be used when calls meeting certain criteria and associated with that ESN are delivered to a PSAP. To trigger a flashing display at a PSAP that supports an NPD + seven-digit interface, the SR will send an NPD value of 4, 5, 6, or 7, each providing the “flashing display’ equivalent to the corresponding NPD value of 0, 1,2, or 3. If the SR serves wireline calling stations in four or fewer NPAs, each NPA will be mapped to one of the NPD digits (0, 1, 2, 3). However, in general, a serving SR will support more than four NPAs. Therefore, the E9-1-1 Network Provider must have a mechanism in the SR for choosing which four of those NPAs are to be applied to each PSAP that uses the NPD + seven-digit interface. Mappings of NPAs to NPD values will typically be done on a per-PSAP trunk group basis, using the NPA code associated with the Calling Station Number/ANI. Where the per-trunk-group mapping of NPA codes to NPD digits is not populated for a particular PSAP trunk group that uses NPD ÷ seven-digit MF signaling, the NPD digit will be derived from the SR’s default mapping using the NPA code associated with the Calling Station Number/ANI. Where neither the per-trunk-group mapping nor the default mapping of NPA codes produces a valid NPD digit, the Calling Station Number/ANI will be considered invalid, and the call will be treated as if the Calling Station Number/ANI were unavailable (i.e., a fictitious ANI is sent of the form 0-91 1-OTTT, where the TTT indicates the Emergency Service Central Office [ESCO] number associated with the originating office). For wireless originations where the signaling delivered to the SR includes a callback number and an ESRD, and the emergency call is destined for a PSAP that supports an NPD + seven-digit MF interface, the SR will determine, based on per-PSAP provisioning, whether the Calling Station Number/ANI or the cell site and sector number represented by the ESRD will be delivered to the PSAP. Once this determination is made, the MF signaling outpulsed to the PSAP will be the same as described above. With Nationwide Number Portability, the number of NPAs that may potentially be associated with emergency callers that reside in a particular PSAP’s serving area will be significantly larger than today. For PSAPs that support Traditional ME interfaces, this will result in a larger number of emergency calls for which they will not be able to accurately identify the NPA associated with the callback number, negatively impacting the ability of such PSAPs to call back emergency callers should it become necessary to do so. One way of addressing this limitation is to upgrade the interface between the SR and the PSAP to support Enhanced ME signaling, which allows for the delivery of 10-digit callback numbers to the PSAP. Alternatively, all emergency originations from NNP ported users could be treated as VolP or wireless originations, with an NPA-appropriate pseudo ANI signaled with the call; however this would require changes to the service supported by existing wireline callers. As described below. limitations associated with Traditional ME interfaces do not apply to NC PSAPs. 30 ATIS-1 000071 10.1.2 Next Generation 9-1-1 (NG9-1-1) The goal of Next Generation 9-1-1 (NG9-1-1) is to provide at least E9-1-1-equivalent functionality in support of emergency call originations from fixed, nomadic, and mobile IP users, and to build on those capabilities to improve performance and extend feature functionality (e.g., to support delivery of text-based emergency services requests to PSAPs). There are a number of alternative NG9-1-1 Service architectures under discussion in various industry groups. NENA has defined a long term solution for emergency calling, referred to as the i3 Solution, whose end state assumes end-to-end Internet Protocol (IP) signaling from an lP-enabled endpoint to an IP enabled PSAP, with callback and caller location information provided to the PSAP with the call. Similarly, a joint work group in ATIS is defining the architecture, protocol, and procedures to support the processing of emergency calls by an lP Multimedia Subsystem (IMS)-based Next Generation Emergency Services Network. Regardless of the Functional Elements and interfaces that make up these architectures, NG9-1-1 Service architectures must, at a minimum, support the E9-1-1 capabilities identified in Clause 10.1.1. A fundamental capability required of any Next Generation Emergency Services network is the ability to selectively route an emergency call to the appropriate PSAP based on the location from which the call was originated. This implies that information identifying the location of the caller must be available at any routing element in the call path. Emergency call setup in an NG9-1-1 environment is expected to be SIP-based. The SIP signaling associated with an emergency session request is expected to include location information, either “by value” (i.e., as a Presence Information Data Format Location Object [PIDF-LO]) in the body of the SIP message or “by reference” (where a location reference is included in the SIP signaling and can be de-referenced to obtain the location value/PIDF-LO). The routing element is expected to use a location value to query a call routing function to obtain routing information for the call. The location information used as input to the call routing function can either be in the form of a civic/street address or geo-coordinates. The output of the call routing function is expected to be in the form of a Uniform Resource Identifier (U RI). If location-based routing cannot be performed because sufficient information is not received with the call to allow the location-based process to be successful (e.g., location information is not received with the call, or a route cannot be determined for the location value associated with the call), the Next Generation Emergency Services Network must be able to route the call using a default location or default next hop URI (as appropriate for the abnormal condition encountered). Alternate/Overflow routing allows the Next Generation Emergency Services Network to temporarily redirect emergency calls to/toward a pre-designated alternate PSAP/destination (e.g., a call center) when the primary PSAP or next hop element is not available to take calls (e.g., due to network/PSAP conditions or other policy). When the Next Generation Emergency Services Network delivers an emergency call to a Next Generation PSAP, it is expected to generate SIP signaling that includes location information (by-value or by-reference), callback information, and Additional Data (by-value and/or by-reference). The location information that the Next Generation Emergency Service Network signals to a Next Generation PSAP will be the same as the location information that it received in incoming SIP signaling. For example, if a routing element within the Next Generation Emergency Services Network receives location-by-reference in a SIP INVITE message associated with an incoming emergency call, and it de-references that location reference to obtain a location-by-value with which to query a location-based routing functional element, it will still send the location-by-reference forward in outgoing SIP signaling to/toward the Next Generation PSAP. Likewise, routing elements in the Next Generation Emergency Services Network may receive additional data associated with a call by reference and/or by value in an incoming SIP INVITE message associated with an emergency call. The routing element is expected to pass the additional data to/toward the Next Generation PSAP in the same form as it was received. Today, PSAPs receive non-location information, such as class of service information, associated with an emergency call in the response from the ALl system. PSAPs that receive emergency calls from the Next Generation Emergency Services Network must, at a minimum, have the same type of non-location information available to them as is available in ALl responses today. 10.1.2.1 Number Portability Considerations The issues identified in Clause 10.1.1.1 related to supporting Number Portability in a legacy E9-1-1 environment do not apply in an end-state NG9-1-1 environment, where there is end-to-end lP connectivity. As described in Clause 101.2, the routing of emergency calls in an NG9-1-1 environment is based on location that is in the form of a street address or geo-coordinates, rather than a 10-digit NANP number as is the case in E9-1-1. In an NG9- 1-1 environment, location information associated with an emergency caller is delivered to a Next Generation 31 ATI s-I 000071 PSAP with the call, If that location information is in the form of a location reference, the Next Generation PSAP will need to initiate a de-reference operation to obtain the location value (in the form of a street address or geo coordinate location). While this functionality is similar to the ALl requests initiated by a legacy PSAP in an E9-1-1 environment, the location reference in an NG9-1-1 environment will be in the form of a URI that need not contain digits as the location key. The most significant issues that Number Portability created for E9-1-1 had to do with the delivery of ANI/callback number to a legacy PSAP that supported a CAMA-like interface from an SR, due to the restriction on the number of NPAs that could be represented by an NPD. In an NG9-1-1 environment, the callback information delivered to an NG PSAP may contain information that consists of, or is easily converted to, a 10-digit NANP number, or it may be in the form of a URI that does not contain any digits at all. Next Generation PSAPs are expected to be capable of accepting callback information, typically communicated in a SIP P-Asserted-Identity header, that meets the SIP requirements for information populated in that header. 10.1.2.2 Transitional Architectures in Support of Emergency Calling Although NG9-1-1 is defined to utilize an end-to-end IP architecture, there will continue to be legacy wireline and wireless (circuit switched) originating networks deployed after emergency service networks and a significant number of PSAP5 have evolved to support NG9-1-1 architectures. Since any PSAP5 served by NG Emergency Services Networks will need to be able to receive emergency calls that originate on these legacy networks, gateway functionality will be a required part of a near-term NG9-1-1 Service Architecture. This gateway functionality must include signaling interworking to convert the incoming MF or SS7 signaling generated by a legacy origination network to the lP-based (i.e., SIP) signaling supported by an Next Generation Emergency Services Network. In addition, since routing within the Next Generation Emergency Services Network will be based on location, a gateway element that interconnects with an Next Generation Emergency Services Network must support the ability to use the information provided by a wireline switch or MSC in call setup signaling (e.g., calling number/ANI, ESRK, cell site/sector represented by an ESRD) to retrieve location information that can be used as input to routing determination. Based on the routing location provided, the routing determination function will identify which Emergency Services Network should handle the call. Routing location will also be used to support routing within the Next Generation Emergency Services Network. Gateway functionality will also be needed to enable interactions between Next Generation Emergency Services Network elements (and the PSAPs they serve) and legacy systems, such as MPCs/GMLCs, to support the retrieval of dispatch location. In addition to gateway functionality on the ingress side of a Next Generation Emergency Services Network, there will be a need to support gateway functionality on the egress side of the Next Generation Emergency Services Network. That is due to the fact that, while an increasing number of PSAPs will evolve to support NG functionality over time, Next Generation Emergency Services Networks must be able to deliver emergency calls to interconnected legacy PSAPs. Thus the near-term NG9-1-1 Service Architecture must include a functional element that will provide signaling interworking and other functionality necessary for emergency calls routed via the Next Generation Emergency Services Network to be delivered to and handled by legacy PSAPs without requiring changes to legacy PSAP CPE. Calls routed via a Next Generation Emergency Services Network and delivered to a legacy PSAP must undergo signaling interworking to convert the incoming IP-based (i.e., SIP) signaling supported by the Next Generation Emergency Services Network to the Traditional MF or E-MF signaling supported by the legacy PSAP. Functionality must also be applied by the Next Generation Emergency Services Network to emergency call originations to allow the legacy PSAP to experience call delivery, ALl data retrieval, and feature activation the same way as they do today. 10.1 .2.2.1 Support for Interconnection of Next Generation Emergency Services Networks and Legacy Originating Networks To support emergency calls that originate in legacy networks, the NENA i3 Solution and ATIS MS-based NG9-1- 1 Service Architecture include the Legacy Network Gateway (LNG) functional element. The LNG logically resides between the originating network and the NG Emergency Services Network and allows PSAPs served by the Next Generation Emergency Services Network to receive emergency calls from legacy originating networks. The LNG provides the protocol interworking functionality from the SS7 or MF signaling that it receives from a legacy originating network to the SIP signaling used in the Next Generation Emergency Services Network. In addition, the LNG is responsible for routing emergency calls to the appropriate element in the appropriate Next Generation Emergency Services Network. To support this routing function. the LNG applies NG9-1-1-specific interworking 32 ATIS-1 000071 functionality to legacy emergency calls that allows the information provided in the call setup signaling by the wireline switch or MSC (e.g., calling number/ANI, ESRK, cell site/sector represented by an ESRD) to be used as input to the retrieval of routing location (in the form of a street address or geo-coordinate location) from an associated location server/database. The LNG uses this location information to query a call routing function to obtain routing information in the form of a URI. The LNG must then forward the emergency call/session request to a routing element in the Next Generation Emergency Services Network, using the URI provided by the call routing function. The LNG will include callback and location information in the outgoing signaling. The location server/database associated with an LNG must support mappings from a specific calling number/ANI or pseudo ANI (pANI) (e.g., ESRK, ESRD) value to a location that will result in the emergency call being routed to the target PSAP associated with the calling number/ANI/pANI. In an NNP environment, it is critical that the correct location mappings are provisioned into the location server/database associated with the LNG. Mechanisms comparable to those used to populate legacy ALl systems in an E9-1-1 environment will need to be implemented to ensure that the appropriate donor and recipient service providers (and their contact information) can be identified and that the associated data (i.e., calling number/ANI/pANI-to-routing location mappings) are correctly provisioned into the LNG’s location server/database. This is of particular concern in the case of legacy wireline originations where the calling number is the key to the routing and dispatch location for an emergency call. In addition to identifying the location to be used or emergency call routing, the LNG is also responsible for providing dispatch location to PSAPs for emergency calls that originate in legacy networks. The mechanisms used by an LNG to access dispatch location are comparable to those used by an ALl system to provide dispatch location to a PSAP in an E9-1-1 environment (i.e., by accessing provisioned data and steering queries to MPC/GMLCs in wireless originating networks, as appropriate). The ability for an LNG to provide dispatch location to a PSAP in an NNP environment will depend on provisioning mechanisms to reflect an up-to-date view of the relationship between the location key (e.g., calling number/ANI or pANI) and the associated location information in records provisioned into the location server/database. Once again, the most direct impacts are on legacy wireline originations, where the calling number provides the key to the dispatch location for an emergency call 10.1.2.2.2 Support for Interconnection of Next Generation Emergency Services Networks and Legacy PSAPs In addition to supporting the delivery of emergency calls to Next Generation PSAPs, Next Generation Emergency Services Networks are required to support the delivery of emergency calls to legacy PSAPs. To support the delivery of emergency calls that are routed via Next Generation Emergency Services to a legacy PSAP, NG9-1-1 Service Architectures include a Legacy PSAP Gateway (LPG) that serves as the signaling and media interconnection point between the Next Generation Emergency Services Network and the legacy PSAP. The LPG is expected to provide special processing of the information received in incoming (SIP-based) call setup signaling to facilitate call delivery to legacy PSAPs, to assist legacy PSAPs in obtaining the callback and location information necessary to handle the call and support the dispatch of emergency personnel, and to support feature functionality currently available to legacy PSAPs, such as call transfer. The SIP signaling delivered to an LPG by a Next Generation Emergency Services Network will contain the same information as the SIP signaling that is delivered to an Next Generation PSAP, including location information (by-reference or by-value) and callback information. The LPG will be responsible for interworking the SIP signaling to the Traditional MF or E-MF signaling that is appropriate for the interface over which the call will be delivered to the legacy PSAP. Traditional MF and E-MF interfaces to legacy PSAPs assume that callback information signaled to a PSAP will be in the form of a 711 0-digit NANP number. It is possible that the callback information delivered to an LPG with an emergency call (e.g., associated with a V0IP origination) will not be in the form of (or easily converted to) a 10-digit NANP number. Location information received by the LPG will be provided to the legacy PSAP outside of the call setup process via a legacy ALl interface The LPG will look to the legacy PSAP like an ALl system and the legacy PSAP will query the LPG using the same interface as it would use to query an ALl database. Like an ALl system, when an LPG is queried with an ALl query key (i.e., callback number and/or pANI), the LPG will respond with the location and other non-location information, as appropriate for the query protocol used by the legacy PSAP. If the SIP signaling associated with an emergency call routed via the Next Generation Emergency Services Network contains a location by value, the LPG will include that location information in the ALl response. formatted appropriately for the receiving PSAP. If the SIP signaling delivered by the Next Generation Emergency Services Network to the LPG includes a location-by-reference, the LPG must first dereference the location-by-reference to obtain the location information to return to the PSAP in response to an ALl query. 33 ATISi 000071 If a PSAP is expecting to receive callback information delivered with the call in call setup signaling, and the callback information received by the LPG is not in the form of (or easily converted to) a 10-digit NANP number with an NPA that is appropriate for the target PSAP (ie., consisting of one of four NPAs supported by a legacy PSAP that supports a Traditional MF interlace), the LPG will perform a mapping from the callback information to a locally significant digit string that can be delivered to the legacy PSAP via Traditional MF or E-MF signaling (as appropriate for the PSAP). The locally significant digit string delivered to the PSAP will be of the form “NPD/NPA 51 1-XXXX”. If the PSAP expects to receive location information delivered with the emergency call, the LPG will generate a 10- digit key (pANI) and associate it with the location and other call information that was provided in the incoming INVITE message from the Next Generation Emergency Services Network. This key will be passed to the PSAP via the Traditional MF or E-MF interface (as appropriate for the PSAP) and will be used by the PSAP in the ALl query that it generates. If the PSAP expects to receive both callback and location information with the emergency call (i.e., via an E-MF interlace) and a pANI of the form NPD/NPA-511-XXXX is sent in the MF sequence corresponding to the callback number, the same digit string can be generated by the LPG and delivered to the legacy PSAP as a pANI that represents the location information received by the LPG in incoming signaling. Note that, like emergency calls from non-initialized mobile devices, legacy PSAPs will not be able to initiate a callback call if the callback information associated with the emergency call is not in the form of a dialable NANP number. The mechanisms used by LPGs to deliver emergency calls to legacy PSAPs when the callback information is not in the form of a 10-digit NANP number (or where the callback information is in the form of a NANP number but the NPA is not one that is supported by a target Traditional MF PSAP) can also be used to support the delivery of emergency calls from NNP customers to legacy PSAP5 that utilize a Traditional MF interlace. 10.1.2.2.3 Support for Interconnection of Next Generation Emergency Services Networks & Legacy Selective Routers During the transition period while the Emergency Services infrastructure migrates toward lP, and PSAPs evolve to support i3 functionality, wireline and wireless callers and PSAPs that are served by legacy Selective Routers (SR5), will need to be supported. A Legacy Selective Router Gateway (LSRG) will provide the needed functionality to facilitate emergency call handling in transitional architectures where legacy SRs and ALls are still present. The LSRG is a signaling and media connection point between a legacy SR and a Next Generation Emergency Services Network. The LSRG allows emergency originations routed via a legacy SR to terminate on an NG PSAP, as well as allowing calls routed via a Next Generation Emergency Services Network to terminate to a legacy PSAP that is connected to a legacy SR. The LSRG also facilitates transfers of calls between PSAPs that are served by legacy SRs and PSAPs that are served by Next Generation Emergency Services Networks, regardless of the type of network from which the call originated. Unlike an LNG, which only resides on the ingress side of the Next Generation Emergency Services Network, or the LPG, which only resides on the egress side of the Next Generation Emergency Services Network, an LSRG may reside on either the ingress or the egress side of a Next Generation Emergency Services Network. The ingress LSRG facilitates the delivery of calls from a legacy E9-1-1 Network to a Next Generation Emergency Services Network. The egress LSRG facilitates the delivery of calls from a Next Generation Emergency Services Network to a legacy E9-1-1 Network. Ingress LSRG Calls originating in legacy end offices or MSCs and routed via a legacy SR must undergo signaling interworking to convert the incoming SS7 signaling used by the SR to the SIP-based signaling supported by the Next Generation Emergency Services Network. An LSRG on the ingress side of the Next Generation Emergency Services Network supports an SS7 interface on the SR side, and a SIP interlace toward the Next Generation Emergency Services Network. The LSRG must support functionality to interwork interworking between the SS7 signaling that it receives from the SR to the SIP signaling used in the Next Generation Emergency Services Network. The LSRG is also responsible for routing emergency calls that originate in a network that is connected to the SR to the appropriate (routing) element in the Next Generation Emergency Services Network. To support this routing, the LSRG must apply service-specific interworking functionality to legacy emergency calls to allow the information provided by the wireline switch or MSC (e.g., calling number/ANI, ESRK, cell site/sector represented 34 ATIS-1 000071 by an ESRD) in the call setup signaling, and passed to the LSRG through the SR to be used as input to the retrieval of routing and dispatch location. The LSRG obtains dispatch location information by querying a legacy ALl database using the key” (i.e., calling number/ANI, ESRK, ESRD) provided in call setup signaling. The LSRG obtains routing location either from the ALl database (e.g. for wireline originations) or by mapping the received ESRKIESRD to a location that will result in the call being routed to the target PSAP. The LSRG uses the routing location to query a call routing function to obtain routing information in the form of a URI. The LSRG must then forward the emergency call/session request to the appropriate element in the NG Emergency Services Network, based on the URI provided by the routing function. The LSRG includes callback and location information in the outgoing SIP signaling sent to the Next Generation Emergency Services Network. To operate successfully in an NNP environment, the static mappings of calling number/ANI/ESRK/ESRD-to routing location and the ALl data accessed by the LSRG to support the acquisition of dispatch location must be provisioned with the correct location mappings/records. The mechanisms described in Clause 10.1.1.1 for populating legacy ALl systems operating in an NNP environment in the context of E9-1-1 will also apply to ALl systems accessed by an ingress LSRG. Mechanisms comparable to those used by an LNG to ensure the accuracy of calling number/ANI/pANl-to-routing location mappings will be applicable to mappings stored in an ingress LSRG. Egress LSRG An emergency call that is routed via a Next Generation Emergency Services Network and is destined for a legacy PSAP that is connected to an SR must traverse an LSRG on the egress side of the Next Generation Emergency Services Network. Upon receiving an emergency session request from a Next Generation Emergency Services Network, the LSRG will analyze the signaled information and apply NG9-1-1-specific processing to identify the outgoing trunk group over which the call will be delivered to the interconnected legacy SR, and to ensure that the information delivered to the legacy SR is in an acceptable format. The LSRG will select the outgoing route to the SR based on the destination PSAP number/address provided in the incoming SIP signaling from the NG Emergency Services Network. The LSRG maintains a mapping between the PSAP URI delivered to it in incoming SIP signaling and the Directory Number (DN) of the corresponding PSAP on the SR. The LSRG delivers the emergency call to the SR over an SS7-supported tandem-to-tandem trunk group. SS7 interfaces to legacy SRs assume that the PSAP DN and the callback information and/or location keys (i.e., pANls) signaled to the legacy SR will be in the form of a 10-digit NANP number. It is possible that some emergency originations (e.g., from V0IP callers) will contain callback information that is not in the form of (or easily converted to) a 10-digit NANP number. If callback information is to be delivered to the SR (i.e., in the SS7 Calling Party Number parameter) and it is not in the form of (or easily converted to) a 10-digit NANP number, the LSRG will perform a mapping from the non NANP callback information to a pseudo callback number that falls within the range of NPA-511-8950 through NPA-51 1-8999 (if the NPA is one of 281, 405: 806, 870, and 903) or in the range NPA-21 1-9950 through NPA 211-9999 (for any other NPA in the United States), as appropriate for the destination PSAP. The LSRG will also need to be able to pass a key to the location information associated with the emergency call to the SR, either by itself (i.e., populated in the SS7 Calling Party Number parameter) or in addition to the callback information (where the callback information will be populated in the SS7 Calling Party Number parameter and the location key will be populated in the SS7 Generic Digits Parameter). An egress LSRG must therefore also generate a 10-digit pANI to associate with the location information received in incoming signaling from the Next Generation Emergency Services Network. If the location information received in incoming signaling from the Next Generation Emergency Services Network contains a location-by-value, the LSRG will associate a pANI that falls within the range of NPA-51 1-8950 through NPA-51 1-8999 (if the NPA is one of 281, 405, 806, 870, and 903) or in the range NPA-21 1-9950 through NPA-21 1-9999 (for any other N PA), as appropriate for the destination PSAP. (Note that the same pANI can be used to represent both the callback and location information.) If the location information received from the Next Generation Emergency Services Network contains a location- by-reference, the LSRG will first check to see whether the location reference URI contains a value that is easily converted to a 10-digit NANP number (i.e., is of the form ‘+lNPANXXXXXX”). If the value of the location reference URI is of the form “+1 NPANXXXXXX”, the LSRG will use the NPA-NXX-XXXX portion of the location reference URI as the pANl that is the key to the location associated with the emergency call. If the content of the location reference URI is not of the form “+1 NPANXXXXXX”, the LSRG will use the mechanism described above for location-by-value to associate a pANl with the location information. If the SR receives both a callback number (or pseudo callback number) and a pANI (associated with the location information): it will use per-PSAP provisioning to determine what will be signaled forward to the PSAP. The PSAP 35 ATIS-1 000071 will use the information received in incoming signaling to query an ALl system to obtain the dispatch location for the call. The ALl will steer the location query back to the LSRG, in the same way as it would steer a location query to an MPC/GMLC in a wireless originating network. To support location delivery to legacy PSAP5 that are served by legacy SRs, the LSRG must support an E2+ interface — as defined in NENA 05-001 — or an MLP interface — as defined in OMA-TS-MLP-V3_2-20051124-C — as appropriate for the interconnected ALl system. The LSRG may also need to support a PSAP-to-ALI Message (PAM) interface, if it interconnects with ALl databases that use PAM to obtain location for legacy wireless emergency calls today (support for a PAM interface will be based on agreements between the LSRG provider and the ALl database provider). The location key used in the E2+/MLP/PAM query will be the pANI (possibly in combination with the callback number/pseudo callback number) created by the LSRG for the emergency call. If the location information received from the Next Generation Emergency Services Network is in the form of a location-by-value, the LSRG will be responsible for returning that location information, as well as the callback number and other non-location information, in the response to the ALl system. If the location information is in the form of a civic location/street address, the LSRG must ensure that location returned in the ALl response is in a format that is acceptable to the ALl system/PSAP. If the location information received by the Next Generation Emergency Services Network is in the form of a location- by-reference, the LSRG will first have to dereference the location reference to obtain the location value to be returned in the response to the ALl system. Once again, if the location value is in the form of a civic location/street address, the LSRG will have to ensure that location returned in the ALl response is in an acceptable format. The ability to generate a pseudo callback number and/or pANI to support the delivery of an emergency call that has traversed a Next Generation Emergency Services Network and is destined for a legacy PSAP that is interconnected to an SR can also be used to support emergency calling in an NNP environment. In particular, the use of pseudo callback numbers/pANIs addresses the issue of trying to deliver a callback number to a PSAP that is interconnected via a Traditional MF when the NPA associated with that callback number is not one of the four that is supported by that PSAP. By substituting an NPA-appropriate pseudo callback number/pANI, the call can be successfully delivered to the PSAP using the existing signaling interlace. The actual callback number associated with the NNP customer can then be delivered to the PSAP via the ALl system, after the ALl receives it in the response from the LSRG. 10.2 National Security/Emergency Preparedness (NS/EP) Emergency Telecommunications Service (ETS) is a national service, providing priority telecommunications to the ETS-authorized user in times of disaster and emergency [ITU-T E.107j. National Security/Emergency Preparedness Next Generation Network Government Emergency Telecommunication Service (NS/EP GETS), Legacy Government Emergency Telecommunication Service (GETS), and Wireless Priority Service (WPS) are all facets of the U.S.A. instantiation of the international standard for Emergency Telecommunications Service (ETS). 10.2.1 GETS &WPS GETS is one facet of the U.S.A. instantiation of ETS using public telecommunications networks, offered by the government to authorized users for NS/EP purposes. GETS is a circuit-switched form of ETS for voice (and voiceband data) using PIN authorization in which a user can invoke the service by dialing a GETS Access Number or GETS Number Translation from most phones served by the Public Switched Network (PSN). GETS provides priority treatment across originating, transit, and terminating networks. WPS is a circuit-switched form of ETS for voice (and voiceband data) using subscription-based authentication in which a user can invoke the service by dialing a feature code from a WPS-subscribed mobile phone served by a public wireless network. WPS provides priority treatment across originating and terminating public wireless networks, including priority radio resource assignment upon call origination and termination. In the PSTN, NS/EP voice calls (e.g., GETS and WPS) are supported using the SS7 High Probability of Call Completion (HPC) network capability and priority signaling procedures as specified in ATIS-1000631 and ATIS 1000006. In general, NS/EP calls are provided priority treatment in the PSTN/SS7 network by: • Including the special ETS indicator (i.e., Calling Party Category (CPC) NS/EP indicator and possibility Precedence parameter priority level) in the ISUP Initial Address Message (lAM). • Marking the AM with a Message Transfer Part (MTP) message priority level of 1 to increase the probability of successful transfer during network congestion. • Setting the lAM timer (T7) to the maximum value. 36 ATIS-1 000071 Marking any outgoing TCAP message associated with the NS/EP call with an MTP message priority level of 2 to increase the probability of successful transfer during network congestion. 10.2.2 NGN GETS NS/EP Next Generation Network (NGN) GETS (NS/EP NGN-GETS) is the evolution of Legacy GETS and WPS to achieve service continuity in the packet-switched NGN and leverage the NGN to offer new features and priority multimedia services (voice, video, and data). In IP-based NGN, NGN GETS sessions are supported using priority signaling control and P transport procedures and capabilities. In general, NGN GETS sessions are provided priority treatment by: • Use of the SIP Resource-Priority Header (RPH) with the ets (and possibly wps) namespace to indicate a request for priority network resources and priority treatment. • Use of IP transport priority mechanisms to increase the probability of successful transport of NS/EP signaling and bearer traffic (e.g. use of specific Differentiated Services (DiffServ) Code Points (DSCP) and per-hop behaviors, and the use of specific Multi-protocol Label Switching (MPLS) Label- Switched Paths (LSPs). 10.2.3 Number Portability Considerations 10.2.3.1 General NSIEP Considerations The main NS/EP consideration for NNP is that any number portability database query/response (e.g. to Number Portability or Routing Databases) associated with an NS/EP call/session has to be provided priority treatment. NS/EP requirements for PSTN/SS7 are provided in ATIS-1000006. ATIS-1000006 specifies that any outgoing TCAP query message associated with an NS/EP call is required to be marked with an MTP priority level of 2. Similarly, the TCAP responses should be marked with MTP priority level of 2. Specifically, Clause 510 of ATIS 1000006 specifies the following: “SS7 end nodes supporting TCAP applications (e.g., the LNP database or a switch supporting certain supplementary services) should use MTP message priority 2 when responding to a TCAP query related to an ETS call. Specifically, the applications that are not ETS-specific (e.g., LNP or switched-based supplementary services) may not have any explicit protocol information indicating that a particular TCAP query message is associated with an ETS call. The only information that might be available is the MTP message priority level in the received messages to determine the value to be used for the TCAP response messages.” As discussed in Clause 7.1 .4 for IP Networks, neither RFC 4694 nor ATIS-1 000679 addresses the specifics of the signaling to/from an LNP database. If it is assumed that existing TCAP-based mechanisms will continue to be used to support NP queries/responses in an IP environment, then the TCAP queries/responses associated with NS/EP sessions have to be provided priority treatment. However, if it is assumed that evolution to an P environment will require a new NP query/response architecture and/or protocol, then any such alternatives under consideration would have to support necessary priority mechanisms to support NS/EP. In summary, NNP solution(s) should take into consideration: • Priority treatment for the network transport of number portability queries/responses associated with NS/EP calls/sessions. • Priority handling of the queries/responses associated with NS/EP calls/sessions at the databases (e.g., Number Portability or Routing Databases). NOTE: Whether mobile stations with WPS/NGN GETS subscriptions are allowed, nationwide porting may be subjected to NS/EP Service Level Agreement (SLA) rules and, if it is determined to be applicable, further analysis of impacts would be needed. 10.2.3.2 NSIEP Considerations for Commercial Agreements NNP Solution This clause discusses NS/EP considerations for the commercial agreements NNP solution described in Clause 5. 37 ATIS-1 000071 Clause 5 discusses a commercial agreements NNP solution that involves using the facilities of third parties to provide a P01 in the donor LATA and to deliver traffic from that P01 to the network of the recipient provider in a distant LATA. It is important that the evaluation of such a solution takes into consideration NS/EP impacts. In the context of NSIEP, the general considerations related to priority treatment of the number portability query/responses discussed in Clause 10.2.3.1 apply. NS/EP implications needs further study. Specifically, there will be a need to make sure that the third party arrangement described for the commercial option has the necessary capabilities to provide priority treatment and handling of NS/EP calls/sessions (i.e., if the third party is not a GETS Service Provider). 10.2.3.3 NSIEP Considerations for National LRN Implementation of NNP This clause discusses NS/EP considerations for the national LRN implementation solution described in Clause 6. Clause 6 discusses a solution involving a national LRN implementation. This solution allows LRNs to be used outside of the current LATA boundaries thereby allowing TNs to be “ported’ nationally. In the context of NS/EP, the general considerations related to priority treatment of the number portability query/responses discussed in Clause 10.2.3.1 apply. NS/EP implications needs further study. 10.2.3.4 NSIEP Considerations for NNP Solution: Location Portability per GR-2982- CORE This clause discusses NS/EP considerations for the location portability per GR-2982-CORE solution described in Clause 7. Clause 7 discusses a solution involving PORC based on the concept of a GUBB. In this solution, the LRN is used for routing and the GUBB is used for carrier selection. In the context of NS/EP, the general considerations related to priority treatment of the number portability query/responses discussed in Clause 10.2.3.1 apply. NS/EP implications need further study. Specifically, further analysis is needed to determine the implications of carrier selection based on the GUBB. 10.2.3.5 NSIEP Considerations for NNP Solution: Non-Geographic Location Routing Number (NGLRN) This clause discusses NS/EP considerations for the Non-Geographic Location Routing Number (NGLRN) solution described in Clause 8. Clause 8 discusses a solution that involves the following key elements: • A new non-geographic area code and administration processes for LRNs (NGLRN). • A network of gateways to host the NGLRNs for call termination (NGGW). • The ability for all service providers to route calls to NGLRNs. Clause 8 also specifies that the service providers will need to route calls to an IP network to complete calls to NGLRNs and NGTNs. This could be the service provider’s own IP network or one they have an agreement with to use for this purpose. In the context of NS/EP, the general considerations related to priority treatment of the number portability query/responses discussed in Clause 10.2.3.1 apply. NS/EP implications needs further study. Specifically. there will be need to ensure that the network of NGGWs (lP network) is capable of recognizing and providing priority to NS/EP calls/sessions including any query/response to NPDBs. Also, there will be a need to make sure that any third party arrangement as described for the NGLRN option has the necessary capabilities to provide priority treatment and handling of NS/EP calls/sessions (i.e.. if the third party is not a GETS Service Provider). 38 ATIS-1 000071 10.2.3.6 NSIEP Considerations for Internet Interconnection Clause 9 discusses NNP in an Internet Interconnection environment Specifically, Clause 9 indicates that: The Internet Interconnection considers the implementation of NNP in an environment in which this requirement for interconnection is replaced with a default requirement to provide a P01 on the Internet.” In the context of NS/EP, the general considerations related to priority treatment of the number portability query/responses discussed in Clause 10.2.3.1 apply. NS/EP implications needs further study. Specifically, given that NGN-GETS is based on the assumption that NS/EP communications will be supported over carrier managed IP-based NGNs, it means that the concept of replacing the requirement for interconnection with a default requirement to provide P01 on the Internet will need specific arrangements to address priority treatment, QoS, and security of NS/EP calls/sessions. 11 Analysis 11.1 Feasibility of NNP Maintaining Current Paradigms 11.1.1 Feasibility in Circuit Switched Networks Based on the discussion in Clause 7 of the GR-2982-CORE Portability Outside the Rate Center solution for NNP, it is theoretically possible to implement NNP without changing the existing interconnection, billing, and settlement paradigms. However: • It is strongly recommended that the N-i query model be abandoned in favor of the originating service provider always querying calls to NPA-NXX5 where an NNP port has occurred. • Areas can be excluded from portability only if porting both in and out is excluded. Thus, a small wireless carrier cannot take advantage of NNP to serve customers porting into its area unless the wireline CLECs in the area also implement NNP. • Since implementation of NNP along the lines of GR-2982-CORE would require SS7 protocol, switch data model, and call processing development, it is unlikely that a GR-2982-based NNP implementation is feasible due to the number of manufacture discontinued platforms on which such development is not available (or sensible). 11.1.2 Feasibility in lP Networks IP-based networks may be more amenable to the developments required to implement NNP so long as development is currently available for the platform in question. Given the requirement that all networks in an NNP area be converted, true NNP, preserving existing interconnection, billing, and settlements paradigms, is not viewed as feasible, even in an all-IP environment. Changes to existing paradigms could facilitate NNP in an P environment. 11.2 Feasibility of NNP Post IP Transition While IP networks could implement NNP through something like the GR-2982-CORE model, it is worth asking if this is a sensible approach particularly in light of the FCC’s question about the need for continued user of LRNs after the transition to VoIP interconnection. As long as service providers continue to use code-based routing (as even P-based service providers generally do today) LRN5 will be necessary. In an all lP environment, however, routing need not be Central Office code-based and the most logical approach is to translate destination telephone numbers to some P construct; for example, a domain name or URI. LRNs, with the associated impacts on numbering resource utilization, would no longer be required. Although such an approach is frequently employed internally in IMS platforms and an intercarrier implementation has been discussed, no consensus has been reached [ATIS/SIP Forum lP NNI Task Force Report]. 39 ATIS-1 000071 11.3 National Number Assignment While the focus of this document is for NNP, consideration of NNP without a consideration of Nationwide Number Assignment (NNA) creates impacts and confusion for consumers and national and state processes and systems. To rescind the interLATA requirement for NNP would again create an issue if the interLATA requirements remain for numbers directly assigned. This again speaks to the need to concurrently implement NNA when NNP is implemented. The assignment of TNs nationally, through NNA, can be the impetus for rescinding all interLATA and rate center requirements. However, this would cause changes for the existing NANP Administration System (NAS) system (much the same as NNP will cause for the Pooling Administration System [PAS] system), and providers’ number assignment systems and processes. Implementing NNA would provide similar treatment for numbers in their initial assignment as well as when they become ported. 12 Summary of Proposals & Impacts 12.1 Commercial Agreements 12.1.1 Overview of Commercial Agreement Approach Service providers wishing to port in a number that is located outside of a LATA in which they have an interconnection point contract with another provider with facilities in that donor LATA to provide a P01 to which calls to the ported number can be routed. The party providing the P01 arranges to route calls to ported numbers to the recipient network per terms of a commercial agreement. In this way the P01 for a number that has effectively moved to a distant LATA can remain in the original LATA just as in the case of a provider with a national footprint that treats customers who move as permanent roamers. 12.1.2 Impact Analysis 12.1.2.1 SS7 Signaling The commercial agreement approach in which a third party provides an interconnection point in the donor LATA and delivers calls to the recipient service provider that has ported a number into a foreign LATA requires no changes to existing SS7 signaling. 12.1.2.2 Call Processing The commercial agreement approach requires no changes to call processing. 12.1.2.3 Network Routing The party providing the donor LATA P01 must arrange to route ported-out-of-LATA calls terminating to that P01 to the recipient carrier. This can be accomplished with existing routing capabilities. 12.1.2.4 NPAC No known changes to the NPAC are required. Investigation may be required to determine whether if the P01 provider is a wireline carrier and the recipient carrier is wireless whether any negative impacts will result. 12.1.2.5 Numbering Administration There should be no impacts on number administration unless it is determined that six-digit unique LRNs are required and these need to be assigned on a per-recipient service provider basis. If this were the case, then each recipient service provider would need an LRN (and thus a central office code) in each LATA from which it seeks to port numbers. 40 ATIS-1 000071 12.1.2.6 AccountinglBilling The need for any accounting or billing changes would depend on the details of the commercial agreement between the out-of-LATA P01 provider and the recipient carrier. With terminating intercarrier compensation defaulting to Bill & Keep, impacts on terminating compensation should be minimized. 12.1.2.7 PSTNIIP Interworking There should be no impacts on PSTN/lP interworking. 12.1.2.8 Regulatory Related Services (Emergency and NSIEP) For ported wireless numbers calls, emergency calls should be handled as they would be for roamers. Impacts on numbers ported to wireline service require further study. Further analysis is needed to determine NS/EP impacts. 12.1.2.9 Policy No particular policy impacts are expected for the commercial agreement approach. 12.1.2.10 Interconnection Agreements Interconnection must be estabhshed between the part providing the P01 in the donor LATA and other providers delivering traffic to that LATA. Whether actual interconnection agreements are between the distant recipient service provider or the service provider supplying the donor LATA P01 is to be determined. 12.2National LRN 12.2.1 Overview This approach proposes a routing solution to enable NNP using Location Routing Numbers (LRN5). This approach allows LRNs to be used outside of the current LATA boundaries thereby allowing TNs to be “ported” nationally. 12.2.2 Impacts 12.2.2.1 SS7 Signaling There is no change required in SS7 signaling. 12.2.2.2 Call Processing & Network Routing There is no requirement to change the call processing and network routing. However, service providers would need to conduct an assessment to determine the network impacts of either performing all queries at the point of origination or maintaining the N-i call completion scenario with the understanding that those TNs porting outside the LATA require additional routing. In addition, some assessment of network equipment (e.g., switches) ability to handle substantially more NPAs (due to potential ported TNs from a much wider base of NPAs than the equipment may handle today) needs to be performed. Calls to ported numbers may appear to be local, but querying the LNP database will return an out-of-LATA LRN. Regional Bell Operating Company (RBOC) switch generics may be coded to block this type of call or to hand them off to an Inter-exchange carrier (IXC). 41 ATIS-1 000071 12.2.2.3 NPAC Current NPAC system processes require the LRN and TN NPA-NXX components to be associated to the same LATA. Changes to support this proposal would require existing edits to be modified. Also, currently local systems connect to the regional NPAC SMS database based on numbers being broadcast to the region where the NPA NXX is allocated. Local systems would need to connect to all regions that numbers may port from to receive the network routing information in support of the NPDB used for call routing. The impacts to local systems, both SOA and LSMS, would need to be assessed. Dependencies, assumptions, or design and implementation decisions likely exist regarding the relationships between NPAs, NXXs, LRNs, and geographic areas of service and/or single NPAC regions. Present system implementations may be based on the current porting rules regarding porting only within a single LATA and/or NPAC region, and that an LRN only can be associated with a single NPAC region, as well as that a ported TN record can only exist in one NPAC region. 12.2.2.4 Numbering Administration There should be no impacts on national number administration. However, numbering resources are state managed. Porting TNs out-of-state raises questions of regulatory and service provider responsibilities, liabilities, and numbering resource management. State regulatory oversight aligns with NPA boundaries (all NPAs have geographical boundaries that lie within a given state) and all rate center boundaries lie within a given state. Rare isolated cases may exist between states having a common border to address various dialing and servicing issues for small areas. 12.2.2.5 AccountinglBilling From a consumer point of view there could be some confusion if local/toll plans are involved, as there would be calls to the same NPA-NXX that are sometimes local and sometimes toll. 12.2.2.6 PSTN/1P Interworking There should he no impacts on PSTN/lP interworking. Although there is no industry consensus on how to route calls in an IP environment, many of the IP routing scenarios proposed do not change any of the existing industry regulations, processes, or assumptions. Therefore, there are many who hold the belief that the implementation of IP would not change the administration of how numbers are assigned from the NPA-NXX level downward, nor how routing data, NPAC, pooling, and block data are currently provisioned and distributed. Consequently, this proposed routing solution would be pertinent in an all-IP environment unless or until the industry agrees that the provisioning and routing would be fundamentally different than how it occurs today and defines the requirements and specifications for its implementation. 12.2.2.7 Regulatory Related Services (Emergency and NSIEP) For ported wireless numbers calls, emergency calls should be handled as they would be for roamers. Impacts on numbers ported to wireline service require further study. Further analysis is needed to determine NS/EP impacts. 12.2.2.8 Policy Dialing plan consistency (e.g., national 1+10-digit dialing) may be needed. For example, variations exist across the country with how calls can/should be dialed, i.e., 1+10 digits, 10 digits, and/or 7 digits. These are often related to intelligence in the dialed number relative to routing. For example, local calls originating and terminating 42 ATIS-1 000071 within the same NPA, if only one NPA today serves the area, are usually dialed on a seven-digit basis. Areas where NPA overlays have occurred are dialed as 1+10 digits or only 10 digits depending on the dial plan approved by the state. NNP impacts on the varying dialing plans need to be assessed. I23NNP Solution Based on GR-2982-CORE 12.3.1 Overview of NNP Solution Based on GR-2982-CORE GR-2982-CORE describes one solution for NNP that is based on the concept of a GUBB. A GUBB is an identifier that represents the geographic location of the end user in an area within which customers may port their TNs. Each GUBB is a separate, distinct area with specific non-overlapping borders. The territory covered by an area of location portability must be fully defined by one or more GUBBs. Every location within the area of portability corresponds to one and only one geographic block. Every TN in an area of location portability can be associated with one and only one GUBB, based on the TN’s geographic location in the area of location portability. GR-2982- CORE assumes that a GUBB is a six-digit number formatted as an NPA-NXX. The GR-2982-CORE solution assumes that at cutover, current rate centers will continue to exist, and a representative NPA-NXX will be assigned and working in each rate center. The GR-2982-CORE-based NNP solution (referred to as PORC) assumes that routing continues to be done using existing LNP LRN-based mechanisms, but that the GUBB is used for carrier selection and rating purposes. GR 2982-CORE assumes a billing policy in which the end user calling a TN that has ported outside of the rate center will incur the transport charges for the call. Since charges based on GUBBs could be different from charges based on TNs, GR-2982-CORE suggests the use of a warning tone or announcement to alert the calling customer to this difference. While the GR-2982-CORE-based solution strongly recommends that PORC routing queries be performed at the originating switch, it does not require that this be the case. In cases where no routing query is performed, the call will route “normally” to a donor switch based on the dialed NPA-NXX or the carrier access code. The donor switch will then be expected to perform the PORC routing query. Alternatively, a PORC routing query may be performed at a “surrogate” switch. In this scenario, the call is routed to the surrogate switch using an LRN provided by an LSPP/LNP query that took place at the originating switch, an intermediate switch, or the actual donor switch. A recipient switch is required to be capable of supporting a PORC routing query and processing the associated response. GR-2982-CORE requires modifications to the TCAP signaling used to query the NNP routing database (referred to in GR-2892-CORE as the LNP SCP) consisting of a different Trigger Criteria Type value in the database query and, if the called number has undergone NNP, the inclusion of a terminating GUBB in the database response. Modifications to the SS7 ISUP signaling used between switches are also required to include the delivery of GUBB information and an indication that a PORC query has been performed. In addition to the call processing impacts at the switch that performs the PORC query (i.e., to generate and process the TCAP messages exchanged with the LNP SCP), call processing at subsequent switches will also be impacted by the presence of the additional information in incoming SUP signaling. The mechanisms described in GR-2982-CORE were defined in a timeframe that pre-dated considerations related to the IP transition. While extensions to SIP have been defined to support LNP, support for a GR-2982-CORE- based PORC solution in an IP environment would require additional extensions to SIP to allow information such as the Terminating GUBB, Redirecting GUBB, and an indication that a PORC query has been performed to be signaled between IP network elements in support of call setup involving PORC customers. If it is assumed that existing TCAP-based mechanisms will continue to be used to support NP queries/responses in an P environment, then the impacts of supporting a GR-2982-CORE-based PORC solution will be the same as in a circuit-switched environment. However, if it is assumed that evolution to an IP environment will require a new NP query/response architecture and/or protocol, then further study will be required to examine viable alternatives for supporting this functionality. 12.3.2 Impact Analysis The following text provides an analysis of impacts of the GR-2982-CORE solution with respect to the following attributes. 43 ATIS-1 000071 12.3.2.1 SS7 Signaling The GR-2982-CORE-based PORC solution requires changes to the SS7 TCAP signaling used in querying an NP database. Specifically, it requires the use of a new value in the Trigger Criteria Type parameter of the NP query, and the inclusion of Terminating GUBB information in the NP response. The PORC solution also has SS7 ISUP signaling impacts in that it requires the assignment of a new value to the 0 Bit in the in FCI parameter, as well as new values in the Type of Digits field within the SS7 Generic Digits Parameter associated with GUBB information. 12.3.2.2 Call Processing At the switch that performs the PORC query, the escape criteria that might inhibit an LNP trigger from being detected (e.g., criteria like 0+ dialed calls or calls destined for a toll carrier other than the carrier of the originating switch) may be different than for an LSPP query. If a number has been ported outside the rate center, the appropriate carrier or the operator services system cannot be determined prior to a query being sent to the NP database. A switch that performs a PORC query must also populate the correct Trigger Criteria Type in the NP query and use the GUBB information (if present) in the response to support the carrier selection and rating applied to the call. The switch that performs the PORC query must also populate the outgoing SS7 ISUP signaling correctly, with the appropriate setting of the 0 Bit in the FCI and GUBB information populated in the Generic Digits Parameter (if received in the response from the NP database). Switches that are subsequent to the one that performs the PORC query in the call path must be capable of processing the information in the FCI 0 Bit and Generic Digits parameter (if present) to determine whether a PORC query should be performed and to determine the rating for the call. Routing at subsequent switches will be based on the LRN, as is the case for LNP today. 12.3.2.3 Network Routing As with LSPP/LNP today, network routing in a PORC environment will be based either on the dialed digits/Called Party Number (if the dialed number is not ported) or on the LRN (if one is provided by the NP database because the dialed number is ported). In the context of the GR-2982-CORE-based NNP solution, carrier selection will be based on the GUBB. The GUBB will be used by the switch to determine the type of call (i.e., intra-network/intra-rate center, inter network/intra-rate center, inter-rate center/intra-LATA, inter-rate center/inter-LATA). If the type of call is inter-rate center/inter-LATA, or inter-rate center/intra-LATA with the calling party’s designated carrier an entity other than the Local Service Provider, determination of the transport carrier will be based on switch-based routing tables that reflect the geographic relationship of the calling and called party’s serving switches, the geographic relationship of the calling and called party stations, and the Class of Service of the calling party. 12.3.2.4 NPAC Support of the GR-2982-CORE-based solution for NNP will require that GUBBs, like LRNs, be administered over a wide geographic area, since all carriers will need to be able to locate their customers geographically for all other carriers. Like LRNs, it is expected that the administration of GUBBs would be performed by a neutral third party. As such, the NPAC could expand its role in NP-related data administration to include administration of GUBBs. This would require new functionality at the NPAC. 12.3.2.5 Numbering Administration The six-digit GUBB approach utilized by the GR-2982-CORE-based NNP solution does not require changes to existing rate centers or number administration principles. Existing rate centers provide the geographic basis for the GUBBs that are fundamental to the PORC solution. Every DN in an area of location portability will be associated with one and only one GUBB, based on the DN’s geographic location in the GUBB “template” or map’ associated with the area of location portability. 44 ATIS-1 000071 12.3.2.6 AccountinglBilling In a GR-2982-CORE-based NNP implementation, real-time rating (i.e., the switch call processing used to perform charge determination resulting in an AMA record that reflects a correct Structure Code, Call Code, etc.) will be based on the GUBB. Using the established rate centers as the basis for GUBB definition permits established billing and rating systems to continue to use the existing vertical and horizontal coordinates to define the common point from which to calculate mileage for toll distance rating. The use of GUBBs as the basis for real-time rating will require modifications to switch processing. 12.3.2.7 PSTNIIP Interworking Due to the timeframe in which GR-2982-CORE was written, the GR assumes a circuit-switched environment and does not address P-based networks or interworking between TDM and IP-based networks in support of NNP. IETF RFC 4694 and ATIS-1000679.2015 describe mechanisms for supporting LNP by signaling LSPP-related information, such as the dialed number, LRN, JIP, and the FCI M Bit, forward by including parameters associated with tel URIs passed in the SIP P-Asserted-Identity and Request-URI headers. Extensions to SIP would be needed to support the transport of the additional information (i.e., Terminating GUBB, Redirecting GUBB, and FCI 0 Bit information) used by the GR-2982-CORE-based NNP solution. New SS7-SIP interworking would also need to be defined to support transitional architectures consisting of a mix of TDM and IP-based network elements. The use of a protocol other than TCAP to support NP queries in an IP environment requires further study. 12.3.2.8 Regulatory Related Services (Emergency and NSIEP) Because 9-1-1 calls do not utilize NP-based routing mechanisms, potential issues related to the delivery of emergency calls originated by location-ported users and routed via legacy Selective Routers to legacy PSAPs that support Traditional MF interfaces are independent of any NNP solution. As described in Clause 10.1.2, transitional and long-term architectures that utilize a Next Generation Emergency Services Network already provide mechanisms that could be used to support the delivery of emergency calls to legacy and NG PSAPs from location-ported callers. For scenarios where the legacy E9-1-1 infrastructure is in place, with delivery of emergency calls over Traditional MF interfaces to legacy PSAPs, solutions such as upgrading the PSAP to support an Enhanced MF interface may be needed to address limitations in the number of NPAs that can be delivered over a single Traditional MF trunk group. However, as stated above, this is independent of the NNP solution that is deployed. With respect to NS/EP, priority treatment of TCAP-based PORC queries would need to be maintained in a GR 2982-CORE-based NNP implementation. Further analysis is needed to determine if there are any implications associated with carrier selection based on GUBBs. 12.3.2.9 Policy The NNP solution described in GR-2982-CORE assumes that existing policies with respect to rate centers and rules related to interLATA call routing are in effect. GR-2982-CORE supports a billing policy in which end users who call PORC DNs are billed for the call according to the billing policies established by the carrier responsible for transporting the call (e.g., the LEC for “local calls”, the intraLATA toll provider or LEC for “lntraLATA toll calls”, or the IXC for “InterLATA toll calls”). Calls that are initially routed to the Donor (or its surrogate) and then redirected to the Recipient Switch may need to support other billing policies. The billing policy supported by GR-2982-CORE also assumes that PORC customers will not incur unusual charges for receiving calls. 12.3.2.10 Interconnection Agreements Interconnection agreements associated with a GR-2982-CORE-based NNP solution will need to address support for NNP between networks, and specifically support for the transport of additional signaling elements (e.g., Terminating GUBB, Redirecting GUBB, and FCI 0 Bit information) between networks. Interconnection 45 ATIS-1 000071 Agreements will also have to address policies related to billing/settlements between interconnected carriers, and the use of GUBBs to drive call rating and carrier selection. 124 NGLRN 12.4.1 NGLRN Solution Description The NGLRN solution proposes a new numbering resource (non-geographic area code) to be used for routing numbers (NGLRN) for NNP TNs. Geographic TNs are ported to an NGLRN. The area code of the NGLRN can be used as an indicator to networks that the call may be treated differently. For example it may be an indicator that the call can be billed or routed differently. The NGLRNs would be hosted on a network of IF switches (NGGWs) for call routing and termination. Connectivity to the NGGWs is only offered over IF. NGGW providers would volunteer to offer this function and likely be vetted by an industry body. The NGLRN solution requires that all carriers have the ability to route to NGLRNs. Carriers may choose to have agreements with transport providers who can route to NGLRNs rather than do it themselves. Otherwise the solution does not require carriers to 1) offer NNP service to their customers, 2) connect directly to NGGWs, nor 3) interface with administrative systems or processes required to enable the solution. 12.4.2 Impacts 12.4.2.1 TDMISS7 Network The NGLRN solution does not require any changes or modifications to TDM/SS7 infrastructure. One of the key issues with regard to implementing any new industry-wide service or function is the impact it may have on TDM/SS7 networks. Given the migration to IP, TDM/SS7 infrastructure is becoming very difficult to maintain, i.e., there is very little expertise and manufacturers are no longer producing it or updating it. Therefore any solution proposed for NNP cannot require any changes to TDM/SS7 infrastructure. The NGLRN solution does not require any changes to TDM/SS7 networks. The only requirement on these networks is the ability to route calls based on an area code, which has always been a basic requirement of all communications networks. Carriers have a choice of either implementing connectivity to the IF network that supports NGLRNs or contracting with a transport provider that does interface to that network. Carriers with TDM/SS7 networks may choose to contract with a transport provider to handle calls to NGLRNs. This would be a simple matter of routing to the transport provider based on the area code of the NGLRN. 12.4.2.2 Call Processing/Network Routing The NGLRN solution does not require originating queries on all calls nor changes to interLATA call processing. Some carriers have a requirement to offer their customers a choice of IXC. These carriers also have a requirement to suppress the LNP query on the originating network and pass calls off to the IXC so that the IXC may perform the query. This is referred to as the N-i query requirement. These carriers also offer their customers’ IXC service. For those calls the carrier can choose to query the call on the originating network because they are both the originating carrier and the N-i carrier. The number of calls that have an N-i query requirement has been steadily decreasing. Carriers that do not have an N-i query requirement can query the call on their originating network. Alternatively they can choose to contract with a transport provider to handle both transport and LNP queries. In the NGLRN solution carriers can handle calls the way they do today. That is, f they have an N-i requirement they can hand calls off to the IXC, if they perform originating queries on all calls they can continue to do that, and if they contract with a transport provider to perform LNP queries they can do that too. The only requirement is that there is an arrangement with a carrier that can handle calls to NGLRNs. As noted in Clause 8.1.1, it may be more efficient, but not necessary, for the FCC to rescind the N-i query requirement as well as the interLATA call processing requirement for calls to NNP TNs. 46 ATIS-1 000071 12.4.2.3 NPAC There are no software modifications required to the NPAC for the NGLRN solution. NGLRNs will have to be added to the NPAC as valid LRNs, as is done today for geographic LRNs. The main difference is that the same NGLRN will be able to be duplicated across multiple NPAC regions. Operationally this is not done today. 12.4.2.4 Number Administration The NGLRNs will need to be administered by some entity. This could be done by either of the existing administrators, NANPA or the PA, or the industry could choose to select a new administrator. NGLRNs will have to be allocated to NGGW providers. Service provider and routing information will need to be associated with the NGLRN. This data needs to be available to carriers. 12.4.2.5 AccountinglBilling Accounting/billing changes to the end user are up to each carrier. This applies to all proposed NNP solutions. Carriers that bill on a minutes basis will not need to change billing. Carriers that bill based on distance may choose to bill differently because an NNP customer’s location may not indicate the true distance that the call has traveled. However there are no rules that would restrict them from continuing to bill as they do today. The NGLRN solution does not propose a method of providing the customers geographic location to originating networks. Carriers that choose to bill calls to NNP TNs differently may choose to bill those calls on a minutes basis. 12.4.2.6 PSTNIIP Interworking The NGLRN solution provides the ability to interwork the TDM/SS7 PSTN with the lP PSTN and the ability to transition customers and the network from TDM/SS7 to IP. The NGLRN solution creates an all-IP network of PSTN switches (i.e., the NGGWs) that interface with the TDM/SS7 PSTN via the NGLRN. Calls can flow easily from the TDM/SS7 PSTN to the lP PSTN by routing to the area code of the NGLRN. TDM/SS7 switches would route calls based on the NGLRN area code to a transport network (the carrier’s own or a trading partner’s) that can complete calls to NGLRNs. Carriers can move customers from the TDM/SS7 PSTN to the lP PSTN by porting TNs to NGLRNs. 12.4.2.7 Regulatory Related Services There is no new functionality required for the NGLRN solution to enable regulatory related services. Calls to 9-1-1 initiated by NNP TN5 would use the pANl solutions deployed for wireless and VoIP service. Further analysis is needed to determine NS/EP impacts. 12.4.2.8 Policy The only policy change specific to the NGLRN solution is requiring carriers to have the ability to route to NGLRNs. Carriers may choose to have agreements with transport providers who can route to NGLRNs rather than do it themselves. Otherwise the solution does not require carriers to 1) offer NNP service to their customers, 2) connect directly to NGGWs, nor 3) interface with administrative systems or processes necessary to enable the solution. 47 ATIS-1 000071 Implementing NNP will require the FCC to issue an order lifting the LNP policy that restricts porting to within the same rate center. Carriers are not supposed to port a TN from one rate center to another. To deploy NNP, regardless of the technical solution, the FCC will have to issue an order that rescinds that restriction. NNP further breaks down the association of TNs to geography. In light of NNP, the industry should consider changing policies regarding N-I query processing and interLATA call processing for NNP TNs. For more on policy considerations, see Clause 8.1. 12.5 Internet Interconnection 12.5.1 Overview Where service providers cannot agree on the terms of interconnection, the default is for each to provide a P01 on the Internet, essentially a set of Session Border Controller addresses where traffic can be delivered. Under Internet interconnection all service providers must be able to resolve telephone numbers to IF addresses for interconnection. This may be accomplished in a number of ways, whether directly by a secure query infrastructure that replaces the functions of the NPAC and LERG or indirectly via existing numbering aggregation constructions such as central office codes and LRNs. Originating service providers will resolve the dialed NANP number for all calls to an interconnection address whether based on bilateral agreements for interconnection (which may still predominate) or the default Internet P01 and route the call to its destination regardless of the location of the called number. 12.5.2 Summary of Impacts 12.5.2.1 SS7 Signaling No new SS7 capabilities are required. Existing interworking between SS7 ISUP and SIP will suffice. 12.5.2.2 Call Processing All service providers must be able to resolve telephone numbers to P addresses for interconnection. This may be accomplished in a number of ways, whether directly by a secure query infrastructure that replaces the functions of the NPAC and LERG or indirectly via existing numbering aggregation constructions such as central office codes and LRNs. 12.5.2.3 Network Routing Whether the recipient SF should be required to effectively establish a PCI in the origin service area by obtaining numbering resources (even a 1O-d LRN) so the issue of an interconnection agreement will be worked requires further study. Alternatively, SPs could connect through intermediaries where an Independent Computing Architecture (ICA) did not exist. How this intermediary role may be kept minimal, e.g., signaling broker as opposed to full Internetwork Packet Exchange (IPX) transport provider, requires further study. The answer may lie in arrangements to certify SPs and allow them to access any Internet P01 on that basis through some security infrastructure. 12.5.2.4 NPAC The NPAC can be used for TN to P resolution as considered in the ATIS/SIF Forum lP NNI Task Force routing Report, ATIS-1000063. Alternatively, it can be replaced by a secure, possibly distributed, registry infrastructure that directly resolves dialed numbers to interconnection addresses on a portability corrected basis. 12.5.2.5 Numbering Administration Number administration need not change, but could evolve to more easily support non-geographic assignment if that were judged desirable since in-LATA P01 establishment would not be required. 48 ATIS-1 000071 12.5.2.6 AccountinglBilling With terminating compensation defaulting to bill & keep and end user billing moving to all distance or unlimited offers, there will be no unexpected toll charge issues and no jurisdictional routing problems. Transport arrangements and cost recovery follow the Internet model providing competitive market discipline and eliminating opportunities for arbitrage. 12.5.2.7 PSTNIIP Interworking The Internet Interconnection model assumes the PSTN has become all-IP, at least with respect to interconnection. 12.5.2.8 Regulatory Related Services (Emergency & NSIEP) Priority arrangements or even separate dedicated interconnection can be provided for Emergency and NS/EP services. Further analysis is needed to determine NSIEP impacts. 12.5.2.9 Policy Internet Interconnection requires a redefinition of interconnection obligations. 49 ATIS-1 000071 Appendix A: National Telephone Cooperative Association (NTCA) Call Scenarios On March 16, 2016, the National Telephone Cooperative Association (NTCA) sent a letter to the NANC Chair with respect to its position on nationwide number portability. The letter included a number of call scenarios that the NTCA suggested be considered in evaluating proposals for NNP. This Appendix looks at each of the scenarios under the solutions (other than Commercial Agreements) presented in the NNP report.2° Analysis of the scenario is presented in italics. BASELINE FACT PATTERN FOR CALL FLOW SCENARIOS For purposes of the Call Flow Scenarios that follow, assume in each case: • Wireless Carrier 1 is a regional wireless carrier based in Dallas, TX (Dallas Message Transfer Agent [MTA]). • Wireless Carrier 2 is a regional wireless carrier based in Minneapolis, MN (Minneapolis MTA). • Rural Local Exchange Carrier (RLEC) is a wireline carrier based in rural TX (Dallas MTA). • Assumptions made for the purposes of this fact pattern: o Wireless Carrier 2 and RLEC do not have direct interconnections in place. o Wireless Carrier 2 does not have any operations/physical network presence in the Dallas MTA. SCENARIO Al — Wireline to Wireless Call (Rural Texas Calling Minneapolis Number Ported to Dallas, Physically Located in Dallas) • Wireless Carrier 2 customer in Minnesota moves to Dallas and requests to have the “Minneapolis” telephone number ported from Wireless Carrier 2 that provides regional service in Minneapolis to Wireless Carrier 1 that provides regional service in Dallas. • RLEC customer (rural TX, Dallas MTA) calls Wireless Carrier 1 customer with a Minneapolis telephone number while the latter is physically in Dallas. This Scenario represents an intraMTA call to ported-in foreign number. Under the NLRN (Nationwide LRN) approach, Wireless Carrier (WC)1 sets up a port/n NPAC (appropriate NPAC Region[sJ may need to be discussed) that maps the TN to an LRN that senies the Dallas LA TA (LRN presumably starting with an NPA-NXX assigned to WCI in the Dallas LA TA). The LRN could conceivably be the same LRN that WC1 has established for standard intra-LA TA ports in Dallas. The carrier could choose another LRN for out- of-area port-ins if they want (e.g., same NPA-NXX base, but different last four digits). If/how such a call gets treated by RLEC as local or toll is an open question. Under the GR-2982 approach, it is recommended the RLEC perform an NNP query on the call even though the number would appear to be a toll call. Based on the information returned in the query response, the RLEC would route the call as intraMTA (either intra- or inter-LA TA depending on the terminating GUBB) and bill accordingly, If the query were not performed by the RLEC, the RLEC would route the call to the caller’s toll provider. The toll provider would be expected to perform the PORC LNP query, but if it did not, the donor (or surrogate donor) switch would perform the PORC query. 20 Letter from Michael R. Romano and Brian J. Ford to Betty Ann Kane, March 16, 2016. Also filed with the FCC in: WC Docket No. 13-97: Numbering Policies for Modern Communications WC Docket No. 07-149: Telcordia Technologies, Inc. Petition to Reform Amendment 57 and to Order a Competitive Bidding Process for Number Portability Administration WC Docket No. 09-1 09: Petition of Telcordia Technologies, Inc. to Reform or Strike Amendment 70, to Institute Competitive Bidding for Number Portability Administration, and to End the NAPM LLC’s Interim Role in Number Portability Administration Con tract Management CC Docket No. 95-116: Telephone Number Portability GN Docket No. I 3-5: Technology Transitions 50 ATIS-1 000071 Under the NGLRN approach, if the RLEC chose not query the call, the RLEC would route the call to the caller’s designated toll provider. The toll provider would query the call and route to the toll provider’s transport provider (perhaps itself) to complete the call to NGNP gateway serving the ported number gateway. End user billing and settlements are to be determined. In the absence of other arrangements, originating switched access and toll billing would be expected. If the RLEC chose to query the call, the NG LRN in the query response would be used route the call (based on the presence of the NO NPA) to the RLEC’s chosen transport provider. That transport provider would complete the call to the NGNP gateway sewing Wireless Carrier I. Billing and settlements are to be determined. Under the Internet Interconnection approach, the RLEC would query the call and resolve the called number to the Internet P01 for Wireless Carrier 2. SCENARIO A2 — Wireline to Wireless Call (Rural Texas Calling Minneapolis Number Ported to Dallas, Physically Traveling Elsewhere) • Same as Al — Wireless Carrier 2 customer in Minnesota moves to Dallas and requests to have the “Minneapolis” telephone number ported from Wireless Carrier 2 that provides regional service in Minneapolis to Wireless Carrier 1 that provides regional service in Dallas. • RLEC customer (rural TX, Dallas MTA) calls Wireless Carrier 1 customer with a Minneapolis telephone number and while the latter is traveling somewhere other than Dallas. Local call to ported-in number while roaming — no additional impact, call delivered to home MSC. Absent changes in current procedures, the call will be delivered to the home MSC of the roaming customer and delivery from thence to the roamer will be the responsibility of the recipient wireless carrier. See SCERNARIO Al. SCENARIO 81 — Wireline to Wireless Call (Rural Texas Calling Dallas Number Ported to Minneapolis, Physically Located in Minneapolis) • Wireless Carrier 1 customer in Dallas moves to Minneapolis and requests to have the “Dallas” telephone number ported from Wireless Carrier 1 that provides regional service in Dallas to Wireless Carrier 2 that provides regional service in Minneapolis. • RLEC customer (rural Texas, Dallas MTA) calls Wireless Carrier 2 customer with a Dallas telephone number while the latter is physically in Minneapolis. This scenario represents a toll call to local number ported to a foreign MTA. Under the NLRN approach, RLEC would need to query NPAC to ‘pick up’ the Minneapolis LRN and then process the call accordingly as any call to Minneapolis. If/how such a call gets treated by RLEC as local or toll is an open question. WC2 sets up a port in NPAC (appropriate NPAC Region[s] may need to be discussed) that maps the TN to an LRN that serves the Minneapolis LA TA (LRN presumably starting with an NPA-NXX assigned to WC2 in the Minneapolis LA TA). The LRN could conceivably be the same LRN that WC2 has established for standard intra-LATA ports in Minneapolis. The carrier could choose another LRN for out-of-area port-ins if they want (e.g., same NPA-NXX base, but different last four digits). Under the GR-2982 solution, the RLEC would query the call and based on the terminating GUBB in the response recognize the call as toll and route, bill, and settle accordingly. Under the NGLRN approach, the RLEC would query because the called number is intraMTA (assuming it is IntraLATA: if interLATA the call would be routed to the caller’s toll provider). Based on the NO LRN being returned, the RLEC would route the call (based on the NO NPA) to its selected transport provider. The transport provider would in turn complete the call to NGNP gateway sewing the ported number gateway. End user billing and settlements are to be determined. Under the Internet Interconnection approach, the RLEC would query the call and resolve the called number to the Internet P01 for Wireless Carrier 2. 51 ATIS-1 000071 SCENARIO B2 — Wireline to Wireless Call (Rural Texas Calling Dallas Number Ported to Minneapolis, Physically Traveling Back to Dallas) • Same as Bi — Wireless Carrier 1 customer in Dallas moves to Minneapolis and requests to have the “Dallas’ telephone number ported from Wireless Carrier 1 that provides regional service in Dallas to Wireless Carrier 2 that provides regional service in Minneapolis. • RLEC customer (rural Texas, Dallas MTA) calls Wireless Carrier 2 customer with a Dallas telephone number and while the latter is traveling back to Dallas. To/I call to local number ported out — roaming back. Ca/I will be delivered to the Wireless Carrier 2 home MSC as in SCENARIO Bi for extension to the roaming subscriber. SCENARIO Cl — Wireless to Wireline Call (Minneapolis Number Ported to Dallas, Physically Located in Dallas, Calling Rural Texas) • Same as Al — Wireless Carrier 2 customer in Minnesota moves to Dallas and requests to have the “Minneapolis” telephone number ported from Wireless Carrier 2 that provides regional service in Minneapolis to Wireless Carrier 1 that provides regional service in Dallas. • Wireless Carrier 1 customer with a Minneapolis telephone number while physically in Dallas calls RLLC customer (rural Texas, Dallas MTA). This scenario represents an intraMTA call from a ported in wireless number. As with a roamer-originated call today the call is treated as intraMTA. The GR-2982 solution might provide some information about the home location of the caller. Under the NLRN approach, this would be routed like any call today. It is an intraMTA call that is done today; in this case the NPA is not the original location. SCENARIO C2 — Wireless to Wireline Call (Minneapolis Number Ported to Dallas, Physically Traveling Elsewhere, Calling Rural Texas) • Same as Al — Wireless Carrier 2 customer in Minnesota moves to Dallas and requests to have the “Minneapolis” telephone number ported from Wireless Carrier 2 that provides regional service in Minneapolis to Wireless Carrier 1 that provides regional service in Dallas. • Wireless Carrier 1 customer with a Minneapolis telephone number and while traveling somewhere other than Dallas calls RLEC customer (rural Texas, Dallas MTA). Normal roaming call flow. The GR-2982 solution might provide some information about the home location of the cal/er. SCENARIO Dl — Wireless to Wireline Call (Dallas Number Ported to Minneapolis, Physically Located in Minneapolis, Calling Rural Texas) • Same as Bi — Wireless Carrier 1 customer in Dallas moves to Minneapolis and requests to have the “Dallas” telephone number ported from Wireless Carrier 1 that provides regional service in Dallas to Wireless Carrier 2 that provides regional service in Minneapolis. • Wireless Carrier 2 customer with a Dallas telephone number while physically in Minneapolis calls RLEC customer (rural Texas). Toll call back to original LA TA from number ported out. There are no special impacts of this call except that the GR-2982 approach may provide some information about the home location of the caller. There are no special impacts of this call that may be delivered to the Internet P01 of the RLEC under the Internet Interconnection solution. 52 ATIS-1 000071 SCENARIO D2 — Wireless to Wireline Call (Dallas Number Ported to Minneapolis, Physically Traveling Back to Dallas, Calling Rural Texas) • Same as Bi — Wireless Carrier 1 customer in Dallas moves to Minneapolis and requests to have the “Dallas” telephone number ported from Wireless Carrier 1 that provides regional service in Dallas to Wireless Carrier 2 that provides regional service in Minneapolis. • Wireless Carrier 2 customer with a Dallas telephone number and while traveling back to Dallas calls RLEC customer (rural Texas, Dallas MTA). Local call while roaming. The GR-2982 solution might provide some information about the home location of the caller. 53