idnits 2.17.1 draft-foster-e164-gstn-npusa-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 6, 2003) is 7654 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mark Foster 2 Internet Draft Tom McGarry 3 Document: James Yu 4 NeuStar, Inc. 5 Category: Informational May 6, 2003 7 Telephone Number Portability Administration in the U.S. 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [RFC]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright Notice 30 Copyright (C) The Internet Society (2003). All rights reserved. 32 Abstract 34 This document provides a historical as well as practical overview of 35 the implementation of Number Portability Administration for 36 telephone numbers in the United States (U.S.). There are various 37 regulatory constraints that establish relevant parameters for NP 38 implementation, most of which are not network technology specific. 39 This document describes the NP business model and the architecture 40 for NP administration in the North America. It also briefly 41 discusses the functions performed by the NP administrator and the 42 cost recovery mechanism. 44 Telephone Number Portability in the GSTN: An Overview May 6, 2003 46 1. Introduction 48 This document provides a historical as well as practical overview of 49 the implementation of Number Portability (NP) Administration for 50 telephone numbers in the United States (U.S.). This document 51 describes the NP business model and the architecture for NP 52 administration in the North America. It also briefly discusses the 53 functions performed by the NP administrator and the cost recovery 54 mechanism. 56 The North American telecommunications industry began to seriously 57 investigate methods of providing local number portability (LNP) in 58 late 1994. On July 13, 1995, the Federal Communications Commission 59 (FCC) in the U.S. issued a Notice of Proposed Rulemaking (NPRM) FCC 60 Docket Number 95-116 that opened discussion on NP and sought 61 comments on a wide variety of policy and technical issues related to 62 NP. 64 In 1995 and 1996 several state regulatory bodies, notably the 65 Illinois Commerce Commission (ICC), began the process of officially 66 selecting the architecture to be used for NP in their respective 67 states. After considerable discussion and deliberation, the 68 "Location Routing Number (LRN)" scheme was selected by Illinois, and 69 other states. The switching and signaling requirements for number 70 portability developed in the Illinois LNP workshop under the 71 auspices of the ICC became the basis of the de facto North American 72 industry standards [ICC]. The activities on number portability in 73 the North America also interacted with activities in many other 74 parts of world. 76 There are various regulatory constraints that establish relevant 77 parameters for NP implementation, most of which are not network 78 technology specific. This document describes the NP business model 79 and the architecture for NP administration in the North America. It 80 also briefly discusses the functions performed by the NP 81 administrator and the cost recovery mechanism. 83 2. Abbreviations and Acronyms 85 ACQ All Call Query 86 AIN Advanced Intelligent Network 87 CRTC Canadian Radio and Television Commission 88 FCC Federal Communications Commission 89 ICC Illinois Commerce Commission 90 IETF Internet Engineering Task Force 91 LEC Local Exchange Carrier 92 LLC Limited Liability Corporation 93 LNP Local Number Portability 94 LRN Location Routing Number 95 LSMS Local Service Management System 96 NANC North American Numbering Council 97 NP Number Portability 99 Telephone Number Portability in the GSTN: An Overview May 6, 2003 101 NPAC Number Portability Administration Center 102 NPDB Number Portability Database 103 NPRM Notice of Proposed Rulemaking 104 OSS Operation Support System 105 PUC Public Utility Commission 106 QoR Query on Release 107 RBOC Regional Bell Operating Company 108 SMS Service Management System 109 SOA Service Order Administration 110 SS7 Signaling System Number 7 111 STP Signaling Transfer Point 112 TN Telephone Number 113 U.S. United States 115 3. Performance/Legal/Regulatory Requirements 117 After substantial industry discussion and debate, and extensive 118 comments filed with the FCC, the FCC and the U.S. telecommunications 119 industry set the following minimum performance criteria for LNP: 121 1. Support existing network services, features and capabilities. 122 2. Efficiently use numbering resources. 123 3. Not require end users to change their telecommunication numbers. 124 4. Not require telecommunications carrier to rely on databases, 125 other network facilities, or services provided by other 126 telecommunications carriers in order to route calls to proper 127 termination point. 128 5. Not result in unreasonable degradation in service quality or 129 network reliability when implemented. 130 6. Not result in unreasonable degradation of service quality or 131 network reliability when customers switch carriers. 132 7. Not result in a carrier having a proprietary interest. 133 8. Be able to accommodate location and service portability in the 134 future. 135 9. Have no significant adverse impact outside areas where number 136 portability is deployed. 138 In July 1996, the FCC issued the First Report and Order on LNP under 139 95-116, calling for the deployment of LNP across the U.S. starting 140 in 1997. The FCC did not mandate any specific implementation of LNP 141 in the U.S., but it did call upon the industry to develop and 142 endorse a national standard that would ensure interoperability with 143 all industry segments, including wireless. While providing overall 144 guidelines and requirements for LNP, it did explicitly state that 145 the LRN method met these requirements, whereas alternate proposals 146 (such as Query on Release or QoR) did not. 148 A core requirement was that a carrier who is serving ported numbers 149 need not be reliant on any other carrier (especially the donor 150 network) for completing calls, whether for call transport/routing or 151 for signaling. That's not to say that a carrier couldn't 152 voluntarily opt to use another carrier or the donor network for 154 Telephone Number Portability in the GSTN: An Overview May 6, 2003 156 queries or call routing. But the key is voluntarily. This 157 requirement was imposed on all NP implementations in the U.S. for 158 common carrier telephony services regardless of the network 159 technology employed. 161 Similar requirements were adopted by the Canadian Radio and 162 Television Commission (CRTC), the equivalent of the FCC in Canada, 163 and in a number of regulatory and industry bodies in other countries 164 (e.g., Belgium, Denmark, Spain, and Switzerland) which resulted in 165 the use of centralized Number Portability Databases (NPDBs) to 166 support number portability. 168 In the U.S. and Canada, the All Call Query (ACQ) scheme was adopted 169 because it does not rely on the donor network for call routing (see 170 requirements numbers 4 and 7) and it can accommodate location and 171 service portability in the future. 173 In the U.S. and Canada, there is also the "N-1" guideline that 174 recommends that the network next to the destination network perform 175 the NPDB query if the NPDB query has not been done or the routing 176 information is not available (e.g., due to signaling interworking). 177 This is to prevent the call from being re-routed at the donor 178 network. In the U.S., the wireline carriers are required to support 179 NP in certain service areas in phases. The wireless carriers' 180 support of NP has been postponed until November 2002. 182 4. NP Administration Process in the North America 184 4.1 Business Model 186 Figure 1 shows the NP business model that was adopted in the U.S. 187 and Canada. The U.S. is divided into seven regions coinciding with 188 the boundaries of the original seven Regional Bell Operating Company 189 (RBOC) regions. This was done to facilitate the formation of 190 separate contracting and administrative areas (formed as limited 191 liability companies) for LNP in the U.S. intentionally coinciding 192 with the original RBOC boundaries, thus enabling each RBOC to 193 participate singly in each of these areas. 195 A contractor was selected in open competitive procurements conducted 196 by the industry to be the NPAC provider for each of the seven NPAC 197 regions (Midwest, Northeast, Mid-Atlantic, Southwest, Southeast, 198 Western, and West Coast) in the U.S. The same thing happened in 199 Canada as well. Each Limited Liability Corp. (LLC) in the seven 200 U.S. regions and Canadian Consortium maintain largely identical 201 contracts with the selected contractor(s) covering each region. 203 The FCC and North American Numbering Council (NANC) oversee the 204 technical and operational standards and cost recovery rulemakings. 205 The state Public Utility Commissions (PUCs) also influenced the 206 development of technical and operational standards. 208 Telephone Number Portability in the GSTN: An Overview May 6, 2003 210 Each LLC signed a master contract with the selected NPAC that set the 211 prices and terms and provided the form of User Agreement for the 212 selected NPAC to sign with each individual NPAC user. NPAC users are 213 any bona fide entity that either ports numbers or subscribes to 214 updates to the NPDB provided by the NPAC. 216 Before becoming a NPAC user, a Customer must first sign and return a 217 Non-Disclosure Agreement before any other documentation can be sent. 218 Therefore after the NPAC receives a signed Non-Disclosure Agreement 219 the Customer can now receive the Master Agreement, User Agreement, 220 and Interconnect Plan. The Master Agreement is the top-level 221 overall contract. 223 +--------+ +----------+ 224 | FCC |------------>| State | 225 | NANC |<---+ +--->| PUCs | 226 +--------+ | | +----------+ 227 | | 228 v v (Master 229 +--------------+ Agreement) +----------+ 230 | Regional LLC |<----------->| NPAC | 231 | Contract | | | 232 | Administrator| +----------+ 233 +--------------+ ^ 234 ^ | 235 | | 236 v | 237 +----------+ | 238 | NPAC |<------------------+ 239 | Users | (One User Agreement per User) 240 +----------+ 242 Figure 1. NP Administration Business Model in the U.S. 244 The User Agreements come under the Master Agreements and must be 245 signed by the individual Customers who wish to use NPAC services. 246 If a Customer plans on operating in more than one region, the 247 Customer must sign a separate User Agreement for each of the regions 248 where operations will take place. 250 The Interconnect Plan is another NPAC document that the Customer 251 must sign and return. This document provides an overview of the 252 customer interconnection to the NPAC. 254 The new customer process is shown below. 256 - Customer contacts Chicago NPAC (Help Desk) to request information. 257 - Introduction Package (Application, Non-Disclosure Agreement) sent 258 to customer. 260 Telephone Number Portability in the GSTN: An Overview May 6, 2003 262 - Customer signs and returns Non-disclosure Agreement. 263 - Master Agreement, User Agreement and Interconnect Plan sent to 264 Customer. 265 - Customer signs and returns User Agreement. 266 - Customer signs and returns Interconnect Plan. 267 - Customer data entered. 269 4.2 NPAC Architecture 271 Figure 2 shows the architecture for number portability 272 administration in the U.S. and Canada. 274 (Carrier Facilities) : (NPAC Facilities) 275 : 276 +---------+ : 277 | SOA | : 278 | |-------------------+ 279 +---------+ : | 280 : | 281 : +----------+ 282 : | NPAC/SMS | 283 : | | 284 : +----------+ 285 : | 286 +---------+ +---------+ : | 287 | NPDB |---------| LSMS |-------------------+ 288 | | | | : 289 +---------+ +---------+ : 290 : 292 Figure 2. NPAC Architecture. 294 The interface between the Service Order Administration (SOA) and the 295 NPAC/SMS (Service Management System) is for provisioning ported end- 296 user data including the support of the creation, cancellation, 297 retrieval and update of subscription, service provider, and network 298 information. The local exchange carriers operate the SOAs. 300 The interface between the Local Service Management System (LSMS) and 301 the NPAC/SMS is mainly used for downloading ported number 302 information from the NPAC/SMS to the LSMS. The LSMS then updates 303 the NPDB. A local exchange carrier may operate the LSMS if it 304 decides to deploy an NPDB itself. A service bureau can also operate 305 the LSMS to provision several Local Exchange Carriers' (LECs') NPDBs 306 or operate the LSMS and the NPDB for the operators (e.g., LECs or 307 long distance carriers) to query. The interface between the LSMS 308 and the NPDB is up to the entities that operate them. 310 The functional requirement specification developed under the 311 auspices of the NANC defines the external functionality of the NPAC 313 Telephone Number Portability in the GSTN: An Overview May 6, 2003 315 SMS [FRS]. The interfaces between the NPAC/SMS and the SOA or LSMS 316 use standards-based communications and security technologies and are 317 made public [IIS]. Please note that only the information about the 318 ported numbers is stored at the NPAC databases and the NPDBs at 319 present. 321 4.3 NPAC SMS Functions 323 This section provides a list of the NPAC SMS functions. Please see 324 [FRS] for details. 326 - Provisioning Service: For the new service provider to notify the 327 NPAC SMS of a provision request for a ported number and to send an 328 activation notice to activate the update from the NPAC SMS to the 329 LSMS. 331 - Disconnect Service: For handling disconnection of the telephony 332 service for a ported number. 334 - Repair Service: For resolving problems detected either by a Service 335 Provider or by a customer contacting a Service Provider. 337 - Conflict Resolution: For resolving a conflict when there is 338 disagreement between the old and new Service Providers as to who 339 will be providing service for the telephone number (TN). Please 340 note that the processes for obtaining authorization from the 341 customer to port a number are defined by the Service Providers. 342 The NPAC is not involved in obtaining or verifying customer 343 approval to port a telephone number. 345 - Disaster Recovery and Backup: For having a backup facility and the 346 disaster recovery procedures in place for planned and unplanned 347 downtime at the primary facility. 349 - Order Cancellation: For the new Service Provider to cancel a 350 previously submitted but not activated provision request. 352 - Audit Request: For troubleshooting customer problems and also as a 353 maintenance process to ensure data integrity across the entire NP 354 network. 356 - Report Request: For supporting report generation for pre-defined 357 and ad-hoc reports. 359 - Data Management: For managing network, Service Provider, and 360 customer subscription data. The network data defines the 361 configuration of the NP service and network and includes such data 362 as: participating Service Providers, NPA-NXXs that are portable, 363 and LRNs associated with each Service Provider. The Service 364 Provider data indicates who the NP Service Providers are and 365 includes location, contact name, security, routing, and network 367 Telephone Number Portability in the GSTN: An Overview May 6, 2003 369 interface information. The subscription data indicates how local 370 number portability should operate to meet subscribers' needs. 372 - NPA-NXX Split Processing: For the administration of the 373 information for NPA split (the current NPA, the new NPA, and the 374 affected NXXs) plus the beginning and end date of the permissive 375 dialing period. 377 - Business Support: For supporting service providers that have 378 different needs for business hours and days available for porting. 380 - Notification Recovery: For allowing a Service Provider to capture, 381 via a recovery process, all notifications that were missed during 382 a downtime period for the Service Provider. 384 4.4 Cost Recovery 386 In the FCC's Third Report and Order, adopted May 5, 1998, released 387 May 12, 1998 and published in the Federal Registry July 29, 1998 the 388 Commission implemented section 251(e)(2) with regards to the costs 389 of providing long-term number portability. Section 251(e)(2) of the 390 Communications Act of 1934 (1934 Act), as amended requires that "the 391 cost of establishing telecommunications numbering administration 392 arrangements and number portability shall be borne by all 393 telecommunications carriers on a competitively neutral basis as 394 determined by the Commission." 396 The costs can be categorized below. 398 - Share costs incurred by industry as a whole for the NPACs: 400 * Non-recurring costs, e.g., administrator costs to implement 401 database hardware and software. 402 * Recurring costs, e.g., administrator costs to administer the 403 databases. 404 * Costs incurred by administrators to upload and download data to 405 and from databases. Shared costs of each regional database 406 distributed among telecommunications carriers with revenue 407 derived from providing telecommunications service in the area 408 served by the database, in proportion to carrier's share of 409 revenue for the region. Carriers without such revenue assessed 410 $100 per year. 412 - Carrier-specific costs incurred by each carrier that directly 413 relates to providing NP, e.g., querying calls, porting telephone 414 numbers between carriers. 416 * Dedicated costs, e.g., number portability software, NPDBs and 417 Signaling Transfer Point (STPs) reserved exclusively for NP. 418 * Joint costs, e.g., software generics, switch hardware, Operation 419 Support System (OSS), Signaling System Number 7 (SS7) or Advanced 420 Intelligent Network (AIN) upgrade, incremental to providing NP. 422 Telephone Number Portability in the GSTN: An Overview May 6, 2003 424 Carriers may include incremental overhead incurred specifically 425 in providing NP. 427 Incumbent LECs may recover costs directly related to providing NP 428 through federally tariffed charges that can be query-service 429 charges, prearranged and default, and monthly end-user charges. For 430 example, the end-users in the metropolitan D.C. area pay 23 cents 431 per month for NP surcharge. Carriers, other than incumbent LECs, may 432 recover costs in any manner consistent with state and federal laws 433 and regulations. 435 5. Security Considerations 437 Communication over the SOA and LSAM interfaces must be secure and 438 the NPAC must authenticate the communicating entity when 439 establishing a session over the SOA or LSMS interface. Otherwise, 440 porting event can be initiated without the knowledge of the involved 441 LECs or the LRN associated with a ported TN can be changed that 442 would cause the calls to that TN to be routed to the wrong switch. 444 6. IANA Considerations 446 This document introduces no new values for IANA registration. 448 7. Normative References 450 [FRS] NANC, "Functional Requirements Specification - NPAC SMS, 451 Release 3.2.0a," October 3, 2002. 453 [ICC] ICC, "Generic Switching & Signaling Requirements for Number 454 Portability, Issue 1.05," August 1, 1997. 456 [IIS] NeuStar (formerly Lockheed Martin IMS Corporation), prepared 457 for the North American Numbering Council (NANC),"NPAC SMS 458 interoperable Interface Specification, 3.2.0a," October 3, 459 2002. 461 [RFC] Scott Bradner, RFC2026, "The Internet Standards Process -- 462 Revision 3," October 1996. 464 8. Authors� Addresses 466 Mark D. Foster 467 NeuStar, Inc. 468 46000 Center Oak Plaza 469 Sterling, VA 20166 470 United States 472 Phone: +1-571-434-5410 474 Telephone Number Portability in the GSTN: An Overview May 6, 2003 476 Fax: +1-571-434-5401 477 EMail: mark.foster@neustar.biz 479 Tom McGarry 480 NeuStar, Inc. 481 46000 Center Oak Plaza 482 Sterling, VA 20166 483 United States 485 Phone: +1-571-434-5570 486 Fax: +1-571-434-5401 487 EMail: tom.mcgarry@neustar.biz 489 James Yu 490 NeuStar, Inc. 491 46000 Center Oak Plaza 492 Sterling, VA 20166 493 United States 495 Phone: +1-571-434-5572 496 Fax: +1-571-434-5401 497 EMail: james.yu@neustar.biz 499 Full Copyright Statement 501 "Copyright (C) The Internet Society (2003). All Rights Reserved. 503 This document and translations of it may be copied and furnished to 504 others, and derivative works that comment on or otherwise explain it 505 or assist in its implementation may be prepared, copied, published 506 and distributed, in whole or in part, without restriction of any 507 kind, provided that the above copyright notice and this paragraph 508 are included on all such copies and derivative works. However, this 509 document itself may not be modified in any way, such as by removing 510 the copyright notice or references to the Internet Society or other 511 Internet organizations, except as needed for the purpose of 512 developing Internet standards in which case the procedures for 513 copyrights defined in the Internet Standards process must be 514 followed, or as required to translate it into languages other than 515 English. 517 The limited permissions granted above are perpetual and will not be 518 revoked by the Internet Society or its successors or assigns. 520 This document and the information contained herein is provided on an 521 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 522 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 524 Telephone Number Portability in the GSTN: An Overview May 6, 2003 526 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 527 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 528 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 530 Acknowledgement 532 Funding for the RFC Editor function is currently provided by the 533 Internet Society.