This is the text only HTML accessible version of the PDF document selected.

View Original PDF
Go Back or Close

NENA The 9- 1 -1 Association 1700 Diagonal Road I Suite 500 I Alexandria, VA 22314 Ms. Marlene H. Dortch, Secretary Federal Communications Commission 445 12th Street SW Washington, D.C. 20554 January 29th, 2016 In re 911 Governance and Accountability; Improving 911 Reliability; PS Docket Nos. 14-193 & 13-75. Dear Ms. Dortch: Consistent with commitments made during prior ex parte presentations in March and October of 2015, I have the pleasure to submit, on behalf the stakeholders listed below, the attached consensus plan to ensure reliable and resilient 9-1-1 service as consumer and public safety networks transition to Next Generation 9-1-1 technology and systems. This plan was developed by the stakeholders listed below through a course of intensive discussions span-ning many months, and we believe it reflects a viable path forward as the Commission seeks to address the thorny issues surrounding 9-1-1 governance and reliability. Should you have any questions, please contact me as below. Respectfully submitted, J Telford E. For ; "Trey" Director of Government Affairs COMMISSION ON STATE EMERGENCY NATIONAL ASSOCIATION OF STATE 9-1-1 COMMUNICATIONS ADMINISTRATORS (NASNA) Patrick Tyler, General Counsel Evelyn Bailey, Executive Director 333 Guadalupe Street, Ste. 2-212 380 Blake Hill Road Austin, TX 78701-3942 East Calais, VT 05650 512.305.6915 844.381.3635 NATIONAL EMERGENCY NUMBER ASSOCIATION (NENA) Brian Fontes, CEO 1700 Diagonal Road, Ste. 500 Alexandria, VA 22314 202.618.6369 TEXAS 9-1-1 ALLIANCE Richard Muscat, Director of Regulatory Affairs 2600 Airport Freeway Fort Worth, TX 76111 210.408.3911 INDUSTRY COUNCIL FOR EMERGENCY RESPONSE TECHNOLOGY (iCERT) George S. Rice, Jr., Executive Director P.O. Box 46523 Washington, D.C. 20015 240.398.3065 UNITED STATES TELECOM ASSOCIATION Anthony V. Jones, Director, Critical Infrastructure and Compliance 607 14th Street NW, Ste. 400 Washington, D.C. 20005 202.326.730 National Emergency Number Association I 202-466-4911 I FAX 202-618-6370 viAvvv.nena.crg

Recommendations To Promote Reliable and Resilient 9-I-I Services as the Transition to Next Generation 9-1-I Technologies and Systems Occurs1 Executive Summary The ways in which consumers communicate is changing rapidly. As a result, the technologies that sup-port 9-I-I systems and the underlying governance models, business models and commercial relation-ships that form the basis of the 9-1-1 ecosystem are also transitioning.2 These changing roles and respon-sibilities require a careful review to ensure that best practices and regulations designed for legacy 9-I-I systems are updated so that NG9-I-r systems are highly reliable and resilient. The need for such a review was explicitly identified in the Federal Communication Commission's (FCC's) 9-1-I Governance Notice of Proposed Rulemaking (Governance NPRM).3 This paper is designed to review and address the issues raised in the Governance NPRM.4 We begin with a discussion of Next Generation 9-I-I (NG9-I-I) terms and concepts, recognizing the importance of clarity to an ecosystem that has more participants and greater role fragmentation than ever before. Ultimately, the terms and concepts will need a long-term repository as well as a Focused campaign of education. The need for clarity is even more evident given the changing roles and respon-sibilities of those entities responsible for supporting 9-I-I services, and clarifying these changing roles is critical to understanding how to best ensure high reliability and resiliency as we transition from legacy E9-I-I systems and move toward the more flexible and complicated NG9-1-I solutions. We also discuss the importance, during this transition, of updating existing and establishing new best practices with the goal of improving 9-I-I system performance and, when service impairments occur, to restore service rapidly. Such restoration is made more difficult by a lack of coordination within the 9-I-I ecosystem, and thus collaboration will be key to the future sticcess of such restoration efforts. In addition, we discuss how standards will play a critical role in all stages of this effort by providing common understanding of concepts; describing systems that support the changing roles of the various players in the 9-I-I ecosystem; and establishing uniform methods of interaction, interoperability and 1 This paper was developed jointly by the National Emergency Number Association (NENA), the National Association of State 9-1-1 Administrators (NASNA), the Industry Council for Emergency Response Technologies (iCERT), the Association for Telecommunications Industry Solutions (ATIS), the United States Telecom Association (USTelecorn), Texas Commission on State Emergency Communications (CSEC), and the Texas 9-1-.1 I The 2014 National y I i Progress Report provides valuable data on the status of 9-1-i and progress towards Next Generation 9-1-r (NG9-i-I) implementation from more than 39 states. The National 9-1-I Program (9-.1-I,gov) was created by Congress to provide Federal leadership and coordination in promoting optimal services. 3 In The Matters of 9-I-I Governance and Accountability and Improving 9-1-1 Reliability, Policy Statement and Notice of Pro-posed Rulemaking, P.S. Docket 14-193 and P.S. Docket t3-75 respectively, adopted November 21, 1014, Released November 21, 2,014. Other federal agencies and programs have also addressed many of the same issues including the appropriate roles and
jurisdiction of federal, state and local governments. See, for example, A National Plan for Migrating to IP-Enabled 9-I-I Systems, The National E9-1-1. Implementation Coordination Office, September 2009 (which identifies at page 5-it the need to "Clarify jurisdictional frameworks and responsibilities and identify the coordination required at each level of government to make IF-enabled 9-1-I possible" and at page 1-5 expresses the need to identify "Governance and Policy Clarify jurisdictional frameworks and responsibilities and identify the coordination required at each level of government to make IP-enabled 9-1-I possible.") See also, Next Generation 9-I-I (NG9-I-r) System Initiative Transition Plan, Intelligent Transportation Systems, U.S. Department of Transportation; and National Emergency Communications Plan, 1014 U.S, Department of Homeland Security. As acknowledged most expressly herein with regard to the development of future work initiatives, this paper is not intended to be the final stopping point on addressing these issues. Rather continuing and ongoing work and effort is needed and expected for years to come. As more is learned by interested NG9-1-1. stakeholders on these issues and as new issues arise, appropriate revisions to aspects of this paper, standards and future work initiatives should accordingly be expected to evolve and be updated.

collaboration that will be critical for effective system monitoring and rapid system restoration in times of impairment. Finally, we frame other areas of further effort that go beyond the scope of this paper: the need to track and disseminate NG9-14 deployment information, the requirement for business continuity plans, the importance of strong cybersecurity and credentialing measures, and the opportunity for improved services through strong data analytics. This paper represents the belief that the 9-I-I ecosystem vendors, public safety trade and practi-tioner associations, public safety authorities and agencies, and federal, state & local governments can play a collaborative role that can bring about these changes to our 9-I-I ecosystem in a seamless and successful manner. We encourage the FCC to consider possible alternatives to additional federal regu-lation, to consider the benefits of best practices and standards, and to work with public safety and industry to develop and implement improved best practices and standards that will promote 9-I-I reli-ability and resiliency. Contents I. Introduction 3 II. Clarification of and Education Regarding NG9-1-I Terms and Concepts 4 III. Development of Best Practices to Improve 9-I-I Performance Including Resolution of 9-I-I Outages and Service Impairments II Monitoring II Resolving Service Impairments and Clearinghouse Information 12 9-I-I Authority and PSAP Communication: 12 IV. Improvement of Standards to Facilitate NG9-I-I Implementation 13 V. Framework for Future Work Initiatives 14 Tracking and Dissemination of Data Related to Specific NG9-I-I Deployments Nationwide 14 Business Continuity Plans Cybersecurity 15 Credentialing 15 Data Analytics 15 VI. Conclusion 15 Figures Figure r - Enhanced 9-I-I (E9-I-I) Network Architecture Figure 2 - Modified NENA i3 Architectural Foundation for Reliability & Resilience 5 7

I. Introduction Like communications networks generally, the nation's emergency communications systems are under-going a critical transition from legacy 9-i-1 systems that utilize Time Division Multiplexing (TOM)- based technologies to Next Generation 9-1-i (NG9-1-I) systems employing Internet Protocol (IP).-based technologies.5 NG9-I-I will provide a modern technology platform that will enable more effective com-munications between the public and public safety agencies and amongst various first responders. It has the potential to vastly enhance 9-1-1 services by improving benefit/cost/value relationships, offering more flexible and accurate call routing, improving survivability and resiliency, increasing accessibility through various modes of communications, and providing Public Safety Answering Points (PSAPs) with more information about emergencies, including text, video, and supplemental data. Ultimately, legacy 9-I-i systems will be replaced entirely by NG9-i-I systems, but this transition will take time to occur across the country and likely will be implemented in phases, dependent in part on local jurisdic-tions' capabilities and resources. It is critically important that the reliability of 9-I-I systems and services be ensured during this transitional period and beyond. Lessons learned during previous transitions for wireless, VoIP and text messaging can help achieve this goal.6 Today's 9-I-I systems are a mixture of and early transitional NG9-I-I core services, often requiring PSAPs to interact with services operating on both legacy systems and IP networks.? As a result, differences in the areas of resiliency, reliability, troubleshooting capabilities, best practice resolution processes, and implementations of standards may be based on differing technologies, designs, and func-tionalities, or stakeholder responsibilities. Additionally, the migration from the legacy infrastructure and processing methods to NG9-I-I creates significant complexity beyond "just" implementing NG9-I-i. The organizations collaborating on this paper understand the critical importance of maintaining effective and reliable 9-1-1 services, even as the transition to NG9-1-I occurs; and they encourage the Commission to consider the benefits of best practices in achieving that goal. Best practices can poten-tially be more effective than regulations because they can be adjusted more easily to accommodate evolving technology and other factors. Best practices can also benefit government entities performing or contracting for similar 9-I-i functions that may not be subject to regulation. Such a collaborative approach will enable public safety and industry stakeholders to incorporate innovative service solutions into the NG9-I-r system more broadly and effectively than regulations. This paper organizes the major issues, objectives, and recommendations in the following manner: i.Clarification of and Education Regarding NG9-1.-I Terms and Concepts 2. Examination of Changing Roles and Responsibilities of Entities Supporting 9-I-I Services 3. Development of Best Practices to Improve 9-I-I Performance Including Resolution of 9-I-I Out-ages and Service Impairments 4. Improvement of Standards to Facilitate NG9-I-i Implementation 5. Framework for Future Work Initiatives 5 See NENA Baseline Next Generation Description (February 21, 2011) which states, '13 is on a path to an end state i3 ar-chitecture (and' Baseline NG9-I-r must include functions of today's E9-14 system." Available at httr1fwww.ncna.orging9-1-1-projectibaseline. 6 See History o p i And What it Means For the Future Of Emergency Communications, Industry Council for Emergency Response
Technologies and the 9-I-I Education Foundation, found at http://www.theinduqrycouncil.orgipublicationsiin-e)Jc.frn, ' Full NG9-I-I does not exist yet, as dependencies on carrier or other Originating Service Provider (OSP) capabilities are still to be implemented, such as IP-to-IP interface for voice from the carrier environment, expansion of IP interface for multimedia, and MMES to support non-voice media. 'While Internet-based OSPs could provide some of these services, no such OSP has implemented those capabilities to date. 3

II. Clarification of and Education Regarding NG9-1-1 Terms and Concepts Changes in technologies and markets are reconfiguring the 9-I-I systems. The expanding group of par-ticipants and stakeholders, including those that regulate the industry, must achieve new levels of coop-eration and coordination in order to be effective. An efficient transition to NG9-1-I requires achieving the greatest consensus possible regarding the boundaries of a NG9-1-I system and which elements of the system are most critical to its reliability.' It will involve the effective development and implemen-tation of best practices For NG9-I-1 and requires all affected stakeholders to have a common under-standing of the NG9-1-I architecture, its various components, the manner in which NG9-1-I services are provided and supported, and a set of common nomenclature. Especially during times of system impairments, consistent and understood definitions and conventions will be important for clear and effective communication as well as proper collaboration and timely resolution of issues. This section provides a description of NG9-I-I terms and concepts, identifies areas where further clarification of such terms and concepts may be needed, and makes recommendations for promoting uniformity of terminology and education of affected stakeholders. Emergency 9-I-I services in the United States are predominantly provided via Enhanced 9-I-1 (E9-I-I) systems that use TDM-based technology to deliver voice 9-I-I calls to PSAPs, and include information that allows PSAPs to receive or retrieve the location and call-back information of the caller. The "9-I-I Authority" is the governmental entity responsible under applicable law for overseeing or managing delivery of all 9-I-1 calls originating within a defined jurisdiction normally a state, county or municipality. As such, it is responsible for those parts of the 9-I-I communications ecosystem that support emergency calling within the jurisdiction, including systems for one or more PSAPs, and for interoperability with other 94-1 systems outside the jurisdiction. Today, public access to 9-I-I services is provided over a variety of wireless and wireline communications networks by Originating Service Providers (OSPs), which include mandated local exchange carriers (LECs), wireless service providers, cable companies, over-the-top VoIP providers, and other non-mandated providers of communications services. These OSPs are defined to be the entities that maintain customer relationships that provide ingress into the 9-1-I system, allowing their customers to access this system by using the digits "9-I-I" to initiate an emergency call for help. Typically, such originations occur using methods to convey voice calls, but all forms of multimedia are covered by this definition (text being the most notable and recent form of alternative communication). For the context of this paper, we will use the term "9-I-I call" to 8 For example, summarized at page 9 of 2013 NENA technical paper ("ArEArA Potential Points of Demarcation to NG.9-1-1 Networks Information Document''), industry technologists have identified potential points of logical and physical ingress de-marcation to the NG9-i-i system on the ingress edge of an ESInet, e.g., the Legaq Network Gateway (LNG) in a hybrid environment or the Session Border Controller (SBC) in an end-to-end IP environment. The NENA paper expressly states that
these technical findings are not meant to serve as, or be determinative of, regulatory demarcations, yet the technologists' NG9-1-1 demarcation is not the same as the current ingress demarcation point determined by the FCC, i.e., the selective router. See, e.g., 4-1-1 Requirements for IP-Enabled Services, Final Rule, Fed. Reg. Vol. 7o, No. 124, p. 37273 (June 29, 2005) which establishes the definition of the Wireline E9-1-I Network and pinpoints the selective router as the point where the 9-I-I network begins. The FCC has recognized that the dedicated wireline 9-1-I network is separate and distinct from originating service provider networks (part of the public switched telephone network or "PSTN") and has defined the E9-1-1 Network as a dedicated wireline network that., (I) is interconnected with but largely separate from the public switched telephone network; (2) includes a selective router; and (3) is utilized to route emergency calls and related information to PSAPs, designated statewide default answering points, appropriate local emergency authorities or other emergency answering points. (See, 47 CFR 9,3.) Also, as parr of its Universal Service Report and Order, the FCC recognizes the distinction between "access to emergency services" and the E9-1-1 network. (See Federal Communications Commission, In the Matter of Federal-State Joint Board on Universal Service, CC Docket No. 96-45, Report and Order, Adopted: May 7, 1997 Released: May 8, 1997 pp. 42.) And as part of its wireless and Vo[P 9-I-I mandates, the 9-1-I selective router has served as the presumptive ingress demarcation point between the 9-1-1 network and the originating service provider network. (See Letterfrom Thomas J. Sugrue, Chief Wireless Telecommunications Bureau, to Marlys R. Davis, E9-1-4 Program Manager, Department of Information and Ad-ministrative Services, King County, Washington, May 7, 2000, 4

indicate voice, text or multimedia communication capabilities and will use the term "9-I-I originator" or simply "originator" to refer to the individual who is initiating the 9-1-1 call. OSPs deliver 9-1-1 calls and associated location information to a 9-1-I System Service Provider (SSP), which is responsible for routing the call to the specific PSAP identified to serve the 9-1-1 call based upon the originator's location and, in some cases, call media type.' SSPs are under contract with the PSAP to provide a variety of services, often including routing, transport, database management, customer premise equipment (CPE), maintenance, and system monitoring. The FCC has regulations applicable to certain SSPs,' typically those which are also Local Exchange Carriers (LECs) or Incumbent LECs (ILECs) provision-ing 9-I-I routing and 9-I-I database services, defined as "Covered 9-I-I Service Providers" (CSP). In the context of this paper, an "SSP" will be used interchangeably to refer to CSPs or their non-mandated counterparts. E9-1-1 Components Originating Calls ILICs.:CLE Cs. F5Ps. Cm Irrlo WSPs. Em ergencr 9 erTice ProTifiers SSFResponsibiliry 3dti Ca.b. titre S elective Rau tar VillrelroeloP 1SLIncrlaer Record*. or VolDICellular Shell Record*. SR DB ALI Other ES Providers DBMS Figure r - Enhanced 9-1-I (E9-I-I) Network Architecture NISAG Primary PSAPs Secondary PSAPs Voice - - Data In legacy 9-1-1 systems (as depicted in Figure I above), the 9-I-I call initiates in an OSP (shown as wireline/ILEC End Offices, wireless, and VolP Service Providers) and is terminated on a Selective Router (SR), and the location information is stored in an Automatic Location Information (ALI) da-tabase. Both the SR and the ALI database are provided by the SSP. For E9-1-I services today, the SSP is often an incumbent LEC (ILEC). Note that, in this situation, the ILEC has distinctly different respon-sibilities associated with being both the OSP and SSP Once the SSP delivers the 9-I-I calls and associ-ated data, including location information, to the PSAP, the PSAP is responsible for answering the calls, displaying the location information, allowing the PSAP call taker to request an updated location posi-tion of the 9-1-1 originator, and relaying or transferring sessions as appropriate for emergency dispatch-ing. Note that the Mobile Switching Center (MSC), Position Determination Entity (PDE) and the 9 For example, a particular PSAP may be designated to handle all text-to-9-I-I messages for a group of PSAPs that otherwise would take voice calls independently, HI See 47 C.F.R. 4.9(h). 5

Mobile Positioning Center (MPG) in Figure I are shown for completeness and serve as an example of what a wireless OSP would typically provide to support 9-I-I calls. A PSAP can be defined as "local," "regional," "state," "private," "tribal" or "federal." Each definition conveys the geographic or statutory coverage area serviced by the PSAP, where local" typically refers to county, city or other municipal jurisdictions. The PSAP "call taker" has the primary responsibility of interacting with the 9-1-I originator, triaging the type of emergency and then initiating the dispatch of emergency assistance. The "dispatcher" is responsible for interacting with the appropriate emergency responders; and, in certain jurisdictions, the "call taker" and the "dispatcher" are the same person. "First responders" are those personnel who are initially dispatched to the scene of an emergency, and the three general categories of emergency responders are "police," "fire," and "medical," the latter providing Emergency Medical Services (EMS). PSAPs are often defined in hierarchical terms as well, where a "primary PSAP" defines the system that initially takes the 9-I-I call for a particular jurisdiction and a "secondary PSAP" is a separate entity to which a primary PSAP transfers a 9-I-I call and which is then responsible for further triage of a 9-I-I call such that it can be conveyed to the appropriate dispatch system. Secondary PSAPs often have functionally different responsibilities associated with the police, fire, or medical personnel which they manage. As systems transition towards it becomes harder to identify the basic operational respon-sibilities of 9-I-I SSPs (e.g., routing the 9-I-I call, providing mechanisms to control abnormal routing needs, maintaining and housing GIS and other 9-I-I data, managing location validation processes, net-work connectivity, network and data system monitoring and troubleshooting), and those of the PSAP CPE. The elements are complex, new, continually evolving and assembled in many different ways based on circumstances, specific needs and constraints. For purposes of these basic core type functions in this document, the generic term of 9-I-I SSPs should still be used for identifying specific operational re-sponsibilities, and the recommended best practices associated with each such operational responsibility. There is a compelling need to identify and specify appropriate new 9-I-I SSP best practices for NG9-I-t and transitionally; and this is one of the major focuses of this document. In order to facilitate the transition to a nationwide standard for IP-ba.sed 9-1-I commu-nications (the "i3" architecture) has been developed by NENA with the involvement and contribution of a broad range of-communication providers, public safety agencies, and industry vendors. The intent of this NG9-1-I core services standard is for all E9-1-I capabilities, both for voice and location data, and other new NG9-I-I capabilities, to operate on Emergency Service IP networks (ESInets). These NG9-I-I systems, including associated servers, software, and databases serving PSAPs and other Public-Safety-related entities, support all major originating call types: wireline, wireless, and VolP as well as future forms of public requests for assistance, such as pictures and video. State and Local government entities responsible for dispatching emergency response to
9-1-1 calls are adapting their transitional 9-I-I archi-tectures to the NENA i3 model to ultimately increase effectiveness, to provide better operational capa-bilities, to support IP-based multimedia content from callers and incident-related support resources, and to incorporate NG9-1-I services as they become commercially available. Using the modified' i3 architecture (Figure 2) as the foundation for their efforts, these entities will need to address 9-I-I relia-bility and resilience issues previously identified by public safety and industry in their joint submission to the FCC in August, 2015.12 " The original NENA i3 architecture depicts an all-IP network configuration. However, this document addresses the transition to NG9-I-t and thus must describe situations in which portions of the legacy network may still exist. Thus, the modified NENA i3 architecture depicts the potential existence of the legacy SR and ALI database and thus introduces a new platform, the Legacy Selective Router Gateway which serves as the interface between the SRJALI and the ESInet. 12 Letter ex parse to FCC dated g11112015, NENA, NASNA, iCERT, A TIS, USIA, CSEC, Texas 9-14 Alliance Re: .9-1-1 Gov-ernance and Accountability, PS Docket No. 14-193; Improving 9-I-I Reliability, PS Docket No. 53-75. 6

Clients SIPA 32 tireeh Access Networks 1.194 Il I 1 I _II Public Access IP Networks Origination Networks C3P Cat Puhlie.11N* SRI-LAW SEiV10E DNS G lobal Internet Private Networks Or IMS 191111k17.11Jgtnating I B"dCantrr ECP147Private0 Interfaces Servicas Web Emergency Services IP Network (ESInet) Domains '57,,7g1 ` Le9"ve=rer-lop ( Legacy PSAP Gateway 11;ftiotiedia 8er-Oces WirefesslIP client9 L RSTN diem ININ,AssICS dierit3 WS) ILTS Localiarp VaPdaii Web frrierface----.1 Legacy Circuit-Switched - Networks 1 (ECRF) Emerge !ay Cat) 8 Rutile iLVP)LocartutVatfdarion Databases LegacyyP itTiT r'sr gencY - I " Nete. Gate cy k Leg cy Sete ive Pew F Gate ay 1115.1., rnalfrip jrD7Corttra, Suppieinerttat Services Databases Tehrtinabog ESRP I Legacy9-1-1i rastruabre &festive Router 1 Ad PSAP PSAP Figure a - Modified NENA i3 Architectural Foundation For Reliability & Resilience While NG9-1-I offers clear benefits, its architectural framework is more complex than E9-I-1, con-tinues to evolve, and is assembled in different ways based on circumstances, specific needs and con-straints. Moreover, the terms and concepts used to characterize NG9-I-I services and the entities en-gaged in the provision of NG9-I-I services are likely to change over time with new entities emerging to provide services to PSAPs and PSAPs taking greater control over the communications infrastructures that support emergency services. In analyzing Figure 2, the NG9-1-I architecture is broken into four areas: Clients, Access Networks, Origination Networks, and ESInet Domains. Next Generation Core Services (NGCS) are provided on top of the ESInet Domains and consist of a set of Gateways and Border Control Functions (BCFs), controlling the interfaces into and out of the ESInet, and a variety of Call Routing, Validation and Supplemental services. Three Gateways control voice calls through the network: the Legacy Network Gateway (LNG) takes TDM-based voice 9-I-I calls and converts them to IP for call ingress into the ESInet Domain; the Legacy PSAP Gateway (LPG) converts an IP-based 9-1-1 call to TDM which allows the call to terminate at legacy PSAPs, and the Legacy Selective Router Gateway (LSRG) converts legacy 9-I-I calls that terminate on a SR and converts them to IP for call ingress into the ESInet Domain. Two Border Controllers provide security and control of data calls through the network: The Originating Border Controllers interface between Originating Networks and the ESInet Domain, and Terminating Border Controllers interface between primary ESInets Domains and secondary ESInet Domains (sim-ilar to primary and secondary PSAPs, described earlier). The call routing portion of the NGCS include an Emergency Call & Routing Function (ECRF) which determines the routing of a NG9-I-I call based upon call origination information usually location, but potentially call origination type (wireline, wireless or VoIP) or media type (voice, text, picture or video). The Originating Emergency Service Routing Proxy (ESRP) performs the actual routing function, based upon guidance from the ECRF and the Terminating ESRP determines the final destination of the call, again relying upon instructions from the ECRF. 7

The differences between legacy E9-I-I and emerging NG9-I-i systems and services can create mis-understanding and confusion, especially as efforts are made to address the appropriate roles and respon-sibilities of each participant in the process. The SSP will continue to play a prominent role in the operation of NG9-I-i systems and the provision of NG9-I-i services, linking OSPs and PSAPs. How-ever, the entity fulfilling that role may be different than the one that fulfilled that role previously. In addition, the functions characterized as SSP-provided functions (e.g., routing, transport, database man-agement, CPE, system monitoring) may be performed by different entities under contract with the 9-I-I Authority or PSAP, or even by the 9-1-1 Authority or PSAP itself. State, regional, and local government entities operate independently of one another, and often purchase NG9-i-i system components from multiple vendors. Given the critical importance of 9-i-i services and the increased complexity of a multi-vendor environment, special effort and focus must be applied to the areas of reliability, resiliency, troubleshooting capabilities, and resolution processes. All affected stakeholders, including 9-1-1 Authorities, PSAPs, SSPs, and OSPs, ESInet providers, and other NG9-I-i vendors, will need to work together to address these critical issues, and a common understand-ing of NG9-I-I terminology and concepts is important to achieving that goal. MEr The FCC should hold a public workshop to review and seek input on NG9-I-i terminology and its application to future NG9-I-r implementation and development of best practices. 2Q 2016 Industry and public safety will work jointly to extend the NENA Master 3Q 2016 Glossary that establishes consensus on appropriate NG9-I-I terms and con-cepts in order to ensure such consensus can be incorporated into future NG9-I-I standards and best practices. Industry and public safety will work jointly to develop education and out- 3Q dim 4Q 20t6 reach initiatives that will promote a consistent and uniform understanding of NG9-1-t terms and concepts, and work to execute such initiatives in con-junction with NENA, NASNA, and other stakeholder organizations. III. Examination of Changing Roles and Responsibilities of Entities Supporting 9-1-1 Services The telecommunications industry has experienced fundamental change over the past two decades. Driven by consumer expectations of communications capabilities, these changes have encompassed a convergence of telecommunications and information services and have resulted in a variety of new service providers, products and services, and technologies. All these changes are having a direct impact on 9-1-I emergency services, as consumers expect to communicate with PSAPs in the same way they communicate with others (e.g., voice, text, video). As this new NG9-1-I environment emerges, the roles and responsibilities of OSPs, 9-1-1 SSPs, 9-1-i authorities, and PSAPs will evolve and change. Under-standing how they will change and ensuring that public policies, best practices, and regulations align with those changes will be important to the success of NG9-1-1 implementation. As already noted, there are several key entities in existing and future 9-I-I solutions. OSPs must deliver their subscribers' 9-1-I calls and data to the designated 9-1-1 Authority's system". In the legacy environment, the 9-1-i Authority typically procures
9-1-1 solutions from a single SSP which aggregates OSP voice and data. Under the FCC's rules, SSPs are classified as CSPs and subject to certain regula-tions designed to, among things, ensure reliable 9-I-I services. In transitional and future environments, the 9-1-i Authority may procure 9-I-i solutions from an array of one or more vendors. Additionally, 9-1-I Authorities are beginning to develop cooperative relationships to effectively move toward NG9-1-I, for example, by using hosted IP-capable 9-I-I CPE, sharing data centers, data systems, and ESlnets. '3 47 C.F.R. 64.3001 8

The flexibility and complexity of the ESInet-based architecture and NG9-i-i solutions requires all par-ticipants to assemble multiple components into a single, highly reliable solution. The legacy telecom-munications model in which the ILEC is almost always the SSP is no longer assured. The operating and business environment that resulted in the legacy ILEC almost universally being the sole or primary SSP in a given area no longer exists as variations of NENA i3 solutions have emerged. New technology, based on IP elements and architectures, has created a new blueprint for delivering 9-I-I services as defined by the NENA i3 NG9-1-I framework. The legacy telephone switch that pro-vided 9-1-i call routing for 40 years is being replaced by distributed IP-based architectures that offer far more advanced features and capabilities. The existing paradigm of local 9-I-I solutions can now be replaced with solutions based on IP technology that serve larger geographic areas, offer economies of scale and provide additional interoperability Features for 9-I-I services. These NG9-I-I solutions are, by necessity, provided by entities that create solution elements and integrate technology from specialized providers of IP solution elements (e.g., IP transport or broadband networks, IP gateways, IP routers, IP bridges, and security devices). The NG9-1.4 infrastructure offers more complex functions than the legacy switch being replaced. As a result, the future NG9-1-I capabilities are far advanced and the pos-sibilities for emergence of a more advanced emergency response system are significant. The NENA i3 architecture follows an evolutionary model. IP network capabilities are deployed based on public safety needs and readiness to implement NG9-1-t services. The ESlnets and NGCS solutions deployed today are often used for certain 9-1-I functions, such as replacement of legacy selec-tive routing with IP selective routing. As such, all external interfaces, or technological demarcation points, are well defined, limited in scope and well controlled. This approach will continue to evolve as NG9-I-I systems are implemented and the NENA i3 vision is realized. New non-traditional OSPs will establish connectivity with ESInets across the United States, and individual ESInets will establish con-nections with one another. Over time, the NG9-I-I architecture will become more complex to design, manage, secure and further evolve. Based on advanced technology that continues to evolve, NG9-I-I will become ever more complex as more capabilities are provided and more entities participate in providing Features. Going forward, SSPs and the PSAPs they serve will be required to operate in an environment where IP technology and products will continue to change rapidly. As a result, solutions will need to be con-stantly reevaluated and updated. The complexity of the new NG9-I-I infrastructure and the accelerating high rate of change drive the need for public safety personnel with high-tech specialization. Just as security threats on the Internet must be constantly addressed, technology and security concerns of NG9-I-I need to be constantly managed and updated. As a result, vendors must develop and maintain leading technology solutions and management capabilities. Expanding capabilities in emergency service management and response will drive feature innovation; one example is the
need to interface NG9-I-I networks with the nationwide public safety LTE network being developed by FirstNet in order to en-sure automated information exchange. Managing the implementation of NG9-I-I systems is challeng-ing enough, but SSPs must also manage the operational transition from legacy 9-I-1 systems to these future NG9-I-I systems. They must meet all these requirements with highly available solutions in a constantly changing operating environment. The legacy SSP has typically been the ILEC, but this may not be the case in the future. Some ILECs may exit the 9-I-I services business and new SSPs are expected to emerge. The changing envi-ronment promises an increase in competition and commensurate increases in innovation and 9-I-I services functionality. However, artificial constructs based on the legacy single-provider system would inhibit new entrants to the 9-1-i market and delay ILECs from reasonably and judiciously exiting the market. Such artificial barriers are not conducive to a competitive market and should only be considered on a case by case basis. For the first time, many 9-1-1 Authorities are being given choices for where and 9

how to receive their 9-1-1 services, and in an ever increasing number of cases, state, regional, or local government consortiums are choosing to perform some of these functions themselves. Over the past decade, the significant consumer transition to wireless and IP technologies has spawned an increase in the different types of service offerings by current providers and entirely new types of OSPs whose customers may originate a 9-1-I request for assistance. Wireless and VoIP products are available, and new IP products are on the horizon with the advent of new consumer social media and other application-based communication products. The NG9-I-I vision challenges OSPs to interface with 9-1-1 systems in new ways, including the validation of their subscribers' location information using NG9-I-I systems as opposed to the current Master Street and Address Guide (MSAG) process, and offering caller location information with call setup signaling rather than after call answer at the PSAP. For regional and nationwide OSPs, these requirements may be duplicated across the number of NG9-I-I systems each OSP will encounter across its service footprint. These changes require OSPs to modify their internal processes and systems, and these changes are just beginning for most OSPs. The NG9-I-I model requires the OSP to modify the methods by which they validate subscriber location data and deliver location data to the SSPs. On the positive side, the NG9-I-I paradigm can offer OSPs the opportunity to connect to fewer interface points as compared with legacy selective routers, via redundant call delivery paths. OSPs have a responsibility to design and deploy a highly reliable solution for delivering 9-I-I calls to the various SSPs across their service area footprint. OSPs must monitor their networks and facilities to ensure they are in good working order and availability has not been compromised. OSPs must have working relationships with each SSP for reporting, troubleshooting and managing service disruptions that occur in their networks or for reporting impacts they can observe occurring in the SSP's domain. These relationships manifest themselves in communications between Network Operations Centers (NOCs). SSPs have the responsibility to design and deploy highly reliable solutions for accepting and pro-cessing 9-I-I calls, as well as delivering 9-1-1 calls to PSAPs, while recognizing and reasonably accounting for challenges and limitations. They must manage the availability of their ESInets and the various NG9-I-I system and service functions. They must have working relationships with all OSPs capable of delivering 9-I-I calls, the PSAPs served, the 9-1-I Authorities and all service providers that interface to the ESInet. The SSP has responsibility for the performance, evolution and management of the NG9-I-I system including the call routing solution. While SSPs have clear responsibilities for ensuring that 9-I-I functions are performed effectively, the state, regional, and local 9-I-I Authorities and PSAPs can en-hance this process by specifically addressing these issues and responsibilities thoroughly in their various procurement and contracting documents, as well as in their own self-provisioning 9-I-I Functions that may involve these issues and responsibilities. The transition to IP technology requires fundamentally more complex
cybersecurity capabilities than were required in the legacy operating environment. The flexibility of IP technology and the wider variety of NG9-I-1 roles and responsibilities introduces new attack vulnerabilities and service compro-mise possibilities. NG9-I-I requires all entities - OSPs, SSPs and PSAPs - to manage their own security domain and diligently implement security mechanisms, which cover both systems and operational pro-cedures. In addition, cooperation among entities will aid in security violation detection and mitigation. Various security and networking appliances will need to be introduced to the various domains. Security Functions include BCFs, such as session border controllers, firewalls, intrusion detection, and identity verification solutions. Each security domain will need to stay abreast of current cybersecurity practices and control user access based on roles of user, operations or maintenance. .10

Reconunen4Miiir Target Timeframe Industry and public safety will work jointly to develop an updated i3 Archi- 4Q 2016 tecture diagram that identifies new and emerging participants in the 9-I-I ecosystem and their changing roles and responsibilities. The FCC should hold a public workshop to review and seek input on the 2Q 2016 changing roles and responsibilities of entities supporting 9-I-I services and the appropriate best practices that would promote reliable 9-1-I services in this changing NG9-I-I environment, and should incorporate the results of this review in the FCC's future work plan for Communications Security, Re-liability and Interoperability Council (CSRIC) and Task Force for Optimal PSAP Architecture (TFOPA). I. Development of Best Practices to Improve 9-1-1 Performance Including Resolution of 9-1-1 Outages and Service Impairments Al! of the above noted changes have had impacts on the ability to monitor service impairments and to implement system resolution procedures to recover from service impairments as they happen. Pub-lic/private partnerships between service providers and 9-I-I Authorities must address non-coordinated fragmentation of the 9-I-I ecosystem in order to promote prompt resolution to service impairments. This section addresses this challenge, and focuses on three major areas of function: (.Monitoring 2. Resolving Service Impairments and Clearinghouse Information 3. PSAP Communication Monitoring Every OSP and SSP provider has the responsibility for using appropriately designed systems and for monitoring its own systems and services to detect and respond to 9-I-I service-related impairments and participate in appropriate situational awareness.' Similarly, for their owned or controlled systems, every PSAP and/or 9-I-I Authority has the responsibility of monitoring its own systems and services to detect and respond to 9-I-I service impairments and participate in appropriate situational awareness. Recent outages have highlighted the complexity of monitoring and responding to impairments within indi-vidual networks. These same outages, however, have identified situations in which other providers in the ecosystem observed impacts to their 9-I-I delivery systems and had information that could be useful to the ultimate resolution of the impairment. Based upon work already done to describe the i3 archi-tecture and experience in connection with recent outages, we recommend that the existing i3 docu-ments be enhanced to describe monitoring options that can be implemented in each system (OSP and SSP) that would identify possible 9-I-I service impairments and follow industry Best Practices. Con-sideration should also be given to how the FCC's CSRIC and TFOPA initiatives could assist this effort. Furthermore, as part of best practices, all 2-1-1 stakeholders (including but not limited to, all OSPs and SSPs) should implement a secure distributed information sharing fabric that would facilitate the sharing of observed network threats or impairment issues and improve the ability for individual system provid-ers to notify appropriate parties at the onset of an impairment or compromise.' s 14 Monitoring and logging among multiple providers across the NG9-1-I service process imply a Design step, in that much of what needs to be monitored and logged must he designed into the providers' systems. This requires that requirements and approach be considered upfront, as well as in
ongoing revisions to the applicable systems to support this. Optimally, some pan of these should be part of technical standards, 15 By way of example, during the April 2014 Outage, some VoIP OSPs noted 9-I-I delivery problems. They observed that VoIP 9-I-I calls being steered to Washington State were not receiving All queries from those jurisdictions. This information may have been useful to the CSP networks experiencing the service impairment, allowing a more clear picture of the situation and facilitating a faster network recovery and resolution. II

Resolving Service Impairments and Clearinghouse Information As with monitoring, every OSP and SSP provider has the responsibility of troubleshooting 9-I-I service-related impairments, and similarly for their owned or controlled systems, every PSAP and/or 9-I-I Au-thority has the responsibility of troubleshooting 9-1-I service-related impairments. Because of the con-nected nature of these 9-1-1 systems, a service impairment in one system is likely to create a service impairment or be observable in another part of the ecosystem. Today, OSPs file FCC outage reports via the Network Outage Reporting System (NOM). This information, following FCC rules designed based on competitive and confidentiality justifications, is not always immediately available and is not readily shared with other network providers; and NORS is not only 9-I-I-focused. More importantly, the individual 9-I-I troubleshooting efforts are not coordinated, nor are resources generally combined to provide a more complete picture of the impairment. This lack of coordination may slow resolution time because key information may be missing and the engineering staffs of the network providers in-volved have limitations on what experiences, knowledge, or troubleshooting techniques can be shared. While each network provider may have a process for addressing issues within its own network (whether provided directly by the provider or by a vendor to the provider), resources from other networks may not be available for a variety of reasons. We recommend that a voluntary, industry-led 9-1-1 trouble-shooting coordination method be established such that affected stakeholders can coordinate across pro-vider networks in order to have the free exchange of necessary information to more rapidly resolve service impairments through the effective communication of observed 9-1-I system impacts and the interaction of experts from each system provider. This effort would include the creation of a coordina-tion system, creating documents or model agreements that explain how 9-I-r stakeholders would use the system, and a how such a system would be funded. We recommend that this begin near-term as a simple mechanism for information sharing, possibly by providing conference bridges for identified points of contact to engage. Future work would explore best practices and more effective and automated information sharing techniques. This troubleshooting coordination method is not intended to replace currently applicable FCC and PUC oversight, nor to relieve the providers from their legal or contractual responsibility for ensuring the reliability of 9-i-I systems. During 9-1-I service impairments, system capabilities are always restored at some point in time, with partial or full recovery and resolution. However, resolution of the impairment is not always effec-tively communicated to each stakeholder. Just as an information-sharing technique was recommended earlier For system troubleshooting, so too should system impairment resolution be shared, as appropri-ate, both through periodic updates and final resolution (preferably with a root-cause analysis that allows all parties to learn from impairment). We recommend that the stakeholders who created this document build upon the information sharing and collaboration techniques constructed For sharing monitoring information and for troubleshooting, and extend these techniques to incorporate methods to share impairment resolution. Timely conveyance of system impairment resolution also allows providers who
have invoked alternate architectures to return to normal operating procedures. 9-1-I Authority and PSAP Communication: PSAPs are the bridge between 9-I-I callers and emergency services response. It is vitally important that PSAPs are effective during the emergency response process. Effective communication to the 9-I-t Authority and/or PSAP community impacted or possibly impacted by service impairment is critical; however, the nature, frequency and sheer volume of communication can cause ineffectiveness and a waste of resources. In order to be most effective in all situations, 9-1-1 Authorities and PSAPs need an understanding of the solution status relative to OSP 9-I-I call delivery and SSP capabilities. However, PSAPs have many responsibilities and are typically resource-constrained; therefore, communication to a PSAP needs to be efficient, timely and, most important, meaningful to the PSAP. Too much commu-nication, that is not actionable by the 9-I-I Authority or PSAP, can be just as bad, or worse, than too 12

little communication. It should be made clear to all industry stakeholders which types of communica-tions should go to the 9-1-1 Authority (or their agent) instead of the PSAP and which types of commu-nications should be sent to neither. Recommended Actions: MAE Industry and public safety will work jointly to identify and produce recom-mendations for effective levels of PSAP communications and policies that will promote increased effectiveness, including defining those events for which PSAPs and/or 9-I-I Authorities need timely and effective communi-cations from SSPs and others in the NG9-I-1 ecosystem Industry and public safety will work jointly to develop best practices for a 9-I-I resolution coordination process and support capability at geographic levels that are effective and facilitate service delivery Industry and public safety will work jointly to consider the need for collab-oration on past resolution cases to support education and best practices up-dates, while also protecting truly Legitimate trade secret and competitive in-formation and promoting the importance of candor associated with the in-formation Industry and public safety will work jointly to examine the roles of opera-tions centers (e.g., NOCs), the ability of such operations centers to incorpo-rate new resolution coordination processes developed through best practices, and the potential for such functionality to be promoted within each part of the 9-I-I ecosystem through the development of model contracts between entities involved in the provision of 9-1-1 services Target Timeframe: 4Q 2016 3Q 2016 through 2.Q 2017 3Q thru 4Q 2017 4Q2016 V. Improvement of Standards to Facilitate NG9-1-1 Implementation Technical and operational standards, guidelines, and recommendation are necessary to facilitate a timely and effective implementation of NG9-1-t systems and services that is flexible and enables stake-holders to address new technology challenges in a timely and effective manner. Clear objectives for developing such standards and guidelines, target completion dates, priorities, and commitments asso-ciated with their implementation form the basis of a national project plan to target timely and effective implementation of reliable NG9-1-1 systems and services. We recommend using existing standards fora and processes (e.g., NENA, APCO, ATIS) as the appropriate repositories for the extension, consolidation and reference to existing and future work that addresses the NG9-1-1 systems and services. The system and service operational standards and guidelines, as well as PSAP operational standards and guidelines, assume that, to a large degree, the experiences of early adopters will be leveraged to develop information that can guide those that follow, so that "re-invention" across the country and the "re-learning" of avoidable pitfalls is minimized. However, key aspects of the NG9-l-I architecture, such as the incorporation of location information with calls coming from the OSP, have still not been im-plemented and evaluated by early adopters for a number of reasons, including resource limitations and the complexity of nationwide OSPs interacting with regional NG9-l-I systems' NG9-1-I related standards that already exist are shown at and (National 9-I-I Office), at URLs: http://www.nena.org4age=Standards and http://911.govistandardsFornextgen.hrml. 16 9-I-I location for routing and location information delivery is evolutionary and is a function of at least two
simultaneous tracks, i.e., the future will see a merging of location accuracy technology via mandates For ClvIRS providers along with the location "object" found in the i3 specification which will originate in OSP systems. This blending of technology will add to the demands on OSPs for resources and will raise questions of cost recovery. 13

Standards in progress and yet to be developed include areas of interfaces, NG9-I-I system opera-dons, monitoring and troubleshooting, PSAP operations, 9-1-1 apps, and those for other users beyond PSAPs. As previously noted, experiences of early adopters and parallels from E9-I-1 should be applied to make maximum use of applicable knowledge. The Alliance for Telecommunications Industry Solutions (ATIS) is addressing Emergency Proce-dures in legacy and emerging systems'', and we recommend that such standards be incorporated, di-rectly or by reference, into future NENA i3 standards work. Additional standards need to be developed for Monitoring and Cybersecurity; and we recommend that these standards be organized to address all involved systems, services, and stakeholders, including underlying IP networks used for transport and PSAPs. Because of the connectivity between the i3 systems and services and public internet systems and services, Cybersecurity should specifically address these Public Interfaces. Monitoring standards may not exist. Further discovery is necessary and new efforts might need to be started to provide best prac-tices and/or standards in this area. Numerous Cybersecurity Standards exist, and specific areas address-ing public safety are currently being discussed in FCC's CSRIC V and its TFOPA. Incorporating these standards, directly or by reference, should be in extensions of the i3 Architecture description. Industry and public safety will work jointly, in conjunction with the National 3Q thru 4Q 2o16 9-I-I Office, to develop a baseline/minimum set of NG9-1-t capabilities and system design characteristics for which standards are necessary or beneficial, and identify how the current NG9-I-I standards should be changed accord-ingly Industry and public safety will work with appropriate standards organiza-tions to incorporate changes to the NG9-I-I standards to reflect these base-line requirements Industry and public safety will work jointly to develop recommended pro-cesses that PSAPs and/or 9-1-I Authorities could use to confirm that 9-I-I services meet appropriate NG9-I-I standards 2Q thru 4Q 2017 3Q thru 4Q 2017 VI. Framework for Future Work Initiatives In addition to the specific work initiatives already identified in this document, we believe that consid-eration should be given to future work efforts in the following areas. Tracking and Dissemination of Data Related to Specific NG9-I-I Deployments Nationwide To date, various resources, such as the Commission PSAP spreadsheet, ILEC and new competitor wholesale websites, NENA status documents, and other state, regional, and local plans and resources have detailed how 9-1-I was being done in most areas based on the legacy 9-1-I system and how to reach appropriate 9-I-I contact people when needed. But these resources are falling more and more out of date as legacy systems transition to while at the same time the need for these resources con-tinues or may be increasing. Business Continuity Plans When network or 9-I-I system impairments occur, timely resolution is critical. Every PSAP, Au-thority and 9-I-I System Service Provider should have and regularly update a comprehensive business '7 ATIS -07000i5; "ATIS Standard for Implementation of 3GPP Common IMS Emergency Procedures for IMS Origination and ESInet/Legacy Selective Router Termination", August 20/3. This document describes the North American emergency call
handling procedures in an IMS-based origination network (including steps taken by the originating device and network ele-ments) and routing of such calls to a terminating ES1ner or to a legacy Selective Router. This document also describes the interface between the IMS originating network and the ES1neti and between the IMS originating network and a legacy Selec-tive Router. 14

continuity plan that can be implemented quickly in order to ensure resiliency of the overall 9-I-I system. Such a plan should be developed and updated in collaboration with other stakeholders and should include alternate routing scenarios, backup plans, and disaster recovery processes, and the development of best practices in this area would provide valuable guidance to PSAPs. Given the importance of emer-gency response from a national perspective, consideration should be given to whether and how NG9-1.4 system business continuity plans at the state and local levels could potentially integrate into and work with the nation's Continuity of Operations Plan (COOP) as may be appropriate:8 Cybersecurity As 9-I-I systems transition to IP-based technologies, the need for strong cybersecurity practices becomes even more critical. Cybersecurity should be included as a foundational component of any 9-I-I resili-ency plan; and provisions designed to assess and mitigate cybersecurity risks should be a major focus of any future development effort, Close coordination with entities developing cybersecurity standards is important, and existing standards (e.g., NENAs Security For Next Generation 9-1-1 Standard) should be reviewed and evaluated for future development work. Credentialing Effective security requires effective authentication processes for PSAPs, their service providers and agents, and various public safety agencies interacting with the NG9-I-I system. Consideration should be given to developing best practices for credentialing, to include the types of systems and data that should be credentialed, process for establishing authentication for various agen tsiagencies, and a deter-mination of the entity having credentialing authority. Data Antdytics The transition to NG9-l-I systems introduces a plethora of new data and creates the opportunity to use a variety of data collection and analysis systems to promote increased awareness about 9-I-I system performance. Consideration should be given to establishing a focused industry working group on data analytics that would be tasked with developing best practices for use of data analytics by PSAPs and other interested entities that are part of the NG9-t-r system and who feel they would benefit from access to analytics filtered data. VII. Conclusion The recommendations presented in this document were developed through a broadly supported con-sensus-based approach by industry and the public safety community, and largely focus on the develop-ment of best practices. These best practices should be developed through a combination of industry-based standards bodies, such as ATIS' Emergency Services Interconnection Forum (ESIF) and Network Reliability Steering Committee (NRSC), and FCC-led advisory committees, such as CSRIC and the TFOPA. We highly recommend that, in lieu of regulations, the Commission work with these various entities to ensure that their future work plans include the continued development of best practices and standards that will promote 9-I-I reliability and resiliency. '3 COOP is a United States Federal government initiative that is required by U.S. Presidential directive and managed by the Federal Emergency Management Agency. Its goal is to ensure that federal agencies are able to continue performance of essen-tial functions under a broad range of circumstances, and FEVIA works closely with state and local government entities and the private sector
in achieving this goal. Cf, Continuity Guidance Circular r (CGC r), Continuity Guidance for Non-Federal Governments (States, Territories, Tribes, and Local Government Jurisdictions) (July 2013) (available at littp:Hviremagoviniedia-library-dataii3866o9o588o3-bo84a7z5o6632.49ahrd6da4b647ze691/CGC-I-Signed-july-2013.pdf).