Search

Telecom Decision CRTC 2019-353

PDF version

Ottawa, 22 October 2019

Public record: 8621-C12-01/08

CISC Emergency Services Working Group – Consensus report on matters related to compatibility, reliability, resiliency, and security for next-generation 9-1-1

The Commission approves the recommendations made in a report by the CRTC Interconnection Steering Committee’s (CISC) Emergency Services Working Group (ESWG) related to compatibility, reliability, resiliency, and security for next-generation 9-1-1 (NG9-1-1) [the Report]. The Commission directs NG9-1-1 network providers and other telecommunications service providers to implement the measures identified in the Report that apply to them by 30 June 2020. The Commission also encourages public safety answering points (PSAPs) to adopt the applicable best practices identified in the Report by 30 June 2020. The implementation of these measures in the transition towards NG9-1-1 will respond to the public safety needs of Canadians.

Background

  1. Canadians currently have access to either Basic 9-1-1 (B9-1-1) or Enhanced 9-1-1 (E9-1-1) service through traditional wireline, wireless, and voice over Internet Protocol (VoIP) telephone services wherever a 9-1-1 call centre, also known as a public safety answering point (PSAP), has been established.Footnote 1
  2. When a person dials 9-1-1 in Canada today, the call travels from the network from which it was placed (the originating network)Footnote 2 to the local specialized 9-1-1 network. The 9-1-1 network then routes the call and the associated caller information (if available) to the PSAP that serves the area from which the 9-1-1 call was placed. The PSAP then dispatches emergency responders such as fire, police, and ambulance, as required. 
  3. The Commission’s role in the 9-1-1 context is to exercise regulatory oversight of the access provided by telecommunications service providers (TSPs) to 9-1-1 services to enable communications between Canadians and PSAPs wherever one has been established by the provincial, territorial, and/or municipal governments.
  4. In Telecom Regulatory Policy 2014-342, the Commission indicated that Canadians should have access to new, enhanced, and innovative 9-1-1 services with Internet Protocol (IP)-based capabilities, otherwise referred to as next-generation 9-1-1 (NG9-1-1) services.
  5. In Telecom Regulatory Policy 2017-182, the Commission established a framework for NG9-1-1 (the NG9-1-1 framework). Once NG9-1-1 is fully implemented in Canada, emergency assistance requestsFootnote 3 will flow from originating networks to NG9-1-1 networks as defined in the National Emergency Numbering Association (NENA) i3 architecture standard.Footnote 4 In order for an emergency assistance request to (i) properly, reliably, and securely transit between the requestor and the PSAP communicator,Footnote 5 and (ii) be intelligible to both parties, certain measures must be set in advance. These measures are required for compatibility between the originating networks, the NG9-1-1 networks, and the PSAP’s networks.
  6. The NG9-1-1 framework includes the following key determinations:
    • that Bell Canada and TELUS Communications Inc. start conducting NG9-1-1 implementation trials by end of February 2019;
    • that NG9-1-1 network providers and other TSPs support NG9-1-1 Voice serviceFootnote 6 by 30 June 2020;
    • that NG9-1-1 network providers and other TSPs support NG9-1-1 Text Messaging serviceFootnote 7 by 31 December 2020;
    • that current 9-1-1 networks be decommissioned by 30 June 2023;
    • that NG9-1-1 networks be interconnected to form a national network of networks; and
    • that NG9-1-1 network providers take all reasonable measures to ensure that their NG9-1-1 networks are reliable and resilient to the maximum extent feasible.Footnote 8 
  7. For E9-1-1 service, any caller information associated with a 9-1-1 call, including information required to route the call to the appropriate PSAP, is stored in the Automatic Location Identification / Automatic Number Identification (ALI/ANI) databases. For NG9-1-1 service, these databases will be replaced by the Location Information Server (LIS) and the Additional Data Repository (ADR) functionalities. In Telecom Regulatory Policy 2019-66, the Commission set out roles and responsibilities with respect to the LIS and ADR functionalities. 
  8. Finally, in Telecom Decision 2018-217, the Commission imposed certain network compatibility, reliability, resiliency, and security requirements on NG9-1-1 network providers and TSPs.

The Report

  1. On 12 August 2019, the Commission received for approval from the CRTC Interconnection Steering Committee (CISC) Emergency Services Working Group (ESWG) the following consensus report (the Report):Footnote 9
    • NG9-1-1 Reliability, Resiliency, and Security Best Practices & Standards, 17 July 2019 (ESRE088)
  2. The Report can be found under the “Reports” section of the ESWG page, which is available under the CISC section of the Commission’s website at www.crtc.gc.ca.
  3. The Report represents another significant milestone in the transition towards NG9-1-1 in Canada. The Report contains a number of recommendations related to compatibility between originating networks, NG9-1-1 networks, and PSAP networks, as well as reliability, resiliency, and security measures for the NG9-1-1 networks and the networks with which they interconnect. These recommendations, built on the engineering principles set out in Telecom Regulatory Policy 2016-165, include proposed obligations for NG9-1-1 network providers and originating network providers, and best practices and conditions for PSAPs. The Report also includes six matters for future consideration that will be presented to the Commission in a follow-up report by 31 October 2019.
  4. Specifically, the ESWG recommended, among other things, that the Commission
    • require the NG9-1-1 network providers to include certain compatibility, reliability, resiliency, and security measures in their NG9-1-1 service agreementsFootnote 10 with 9-1-1 authoritiesFootnote 11 as conditions that i3-compliant PSAPs must meet to be connected to the NG9-1-1 network;
    • mandate TSPs and encourage PSAPs to implement an end-to-end encryption strategy;
    • mandate NG9-1-1 network providers to make available their Next-Generation Core Services Authoritative Domain Name Service and Network Time Protocol Service (NTP), as defined in the NENA i3 architecture standard, to interconnected i3-compliant PSAPs within their incumbent local exchange carrier (ILEC) territory;
    • mandate the NG9-1-1 network providers to provide a PSAP Credentialing Agency (PCA) service to authenticate PSAPs on the NG9-1-1 network, as defined in the i3 architecture standard, until a nationwide agency is established; and
    • approve the list of CODECsFootnote 12 to be supported by PSAPs and a process under which CISC would be tasked with managing changes to this list.
  5. The ESWG recommended that the Commission (i) require that NG9-1-1 network providers and TSPs implement the measures that apply to them, and (ii) encourage PSAPs to adopt the best practices that apply to them, by 30 June 2020.
  6. The Report details the timing dependencies between the activities on the critical path to the implementation of NG9-1-1 Voice service by 30 June 2020. The ESWG submitted that key timing dependencies must be met, including the issuance of the Commission’s determinations related to the Report, in order for NG9-1-1 network providers to be in a position to finalize the production interconnection specificationsFootnote 13 and make them available to the interconnecting parties (PSAPs and originating network providers, respectively). Given the winter holidays, the ESWG members representing the interconnecting parties agreed to a deadline of 6 January 2020 for the NG9-1-1 network providers to finalize the production interconnection specifications.
  7. In Telecom Decision 2018-217, the Commission noted WSPs’ concern regarding their readiness to launch NG9-1-1 Voice service, which is dependent on their vendors’ development cycle. The Report notes that the launch timelines could be jeopardized should unforeseen issues arise that would have a material impact on the production interconnection specifications. The Report also notes that since NG9-1-1 network providers and TSPs have Commission-mandated deadlines, should they be unable to meet their deadlines, it is incumbent upon them to request an extension from the Commission directly, not through the ESWG.
  8. Finally, in Telecom Decision 2018-217, the Commission encouraged PSAPs to support, at a minimum, a specific list of CODECs. In the Report, the ESWG recommended that the Commission approve the addition of Opus to, and the deletion of Enhanced Variable Rate Codec and video CODECs from, that list.

Commission’s analysis and determinations

  1. The Commission considers that the Report represents a key milestone on the path to meeting the strategic objectives of NG9-1-1, namely an increase in the safety of Canadians, by giving them the best access to emergency services through world-class telecommunications networks. The Commission further considers that (i) there was appropriate stakeholder representation in developing the Report, and (ii) the Report is within the defined scope of the multiple tasks it includes (i.e. emergency services task identification forms 0081, 0082, 0083, and 0090).    
  2. The ESWG’s recommendations are appropriate, reasonable, and consistent with (i) the broader strategic objectives set out in Telecom Regulatory Policies 2017-182 and 2019-66; (ii) the engineering principles set out in Telecom Regulatory Policy 2016-165; and (iii) the strategic objective that NG9-1-1 is to be based on the i3 architecture standard, allowing for deviations where necessary in the Canadian environment.
  3. As indicated above, in order for an emergency assistance request to (i) properly, reliably, and securely transit between the requestor and the PSAP communicator; and (ii) be intelligible to both parties, common strategies, network requirements, parameters, and protocols must be set in advance so that the networks are compatible. Some of these are defined in the NENA i3 architecture standard, the NG9-1-1 network providers’ interconnection specifications, Commission determinations, and in the NG9-1-1 service agreements between NG9-1-1 network providers and 9-1-1 authorities. 
  4. The Commission considers it appropriate to impose conditions that parties must meet to interconnect to the NG9-1-1 networks in order to ensure compatibility between originating networks, NG9-1-1 networks, and PSAP networks, as well as reliability, resiliency, and security measures for the NG9-1-1 and interconnecting networks. For E9-1-1, (i) the Commission imposed similar requirements on interconnecting originating network providers; and (ii) since the Commission does not directly regulate PSAPs, it imposed conditions in the standard template 9-1-1 service agreements between the 9-1-1 network providers and 9-1-1 authorities.
  5. The Commission considers that the ESWG’s recommended approach is consistent with the approach used for E9-1-1 and ensures that TSPs and NG9-1-1 network providers can meet their fundamental obligation to provide their customers with access to emergency services. The various measures proposed in the Report will collectively ensure (i) that emergency communications are received by the appropriate primary PSAP and subsequently transferred to and received by the secondary PSAP;Footnote 14 (ii) efficient routing and traffic management; (iii) the integrity of the NG9-1-1 networks and the networks interconnected with the NG9-1-1 networks; (iv) compatibility between the originating, NG9-1-1, and PSAP networks; and (v) the intelligibility of communications between the emergency assistance requestor and the PSAP communicator.
  6. While most of the measures outlined in the Report will have financial implications for PSAPs, the level of which was not included in the Report, the risks associated with the failure to meet these measures are not in the best interest of Canadians. Moreover, the PSAP representatives in the ESWG agreed to them. Given the importance of these measures, the Commission considers that the ESWG’s recommended approach is appropriate and in the best interest of all interconnected stakeholders and Canadians.
  7. The Commission has set out in the Appendix to this decision the requirements and best practices stemming from the Report, as discussed below.
  8. The Commission approves the ESWG’s recommendations related to mandatory conditions for i3-compliant PSAPs to interconnect to NG9-1-1 networks through NG9-1-1 service agreements (items 10 to 16 in the Appendix to this decision). The Commission therefore directs NG9-1-1 network providers, as a condition of service pursuant to section 24 of the Telecommunications Act, by 30 June 2020, to (i) include in their NG9-1-1 service agreements with 9-1-1 authorities the requirements reflected in items 10 through 16 set out in the Appendix to this decision, and (ii) take reasonable measures to ensure that only i3-compliant PSAPs that are compliant with these conditions are connected to the NG9-1-1 networks.
  9. With respect to the interconnection specifications, the Commission considers that the recommended timelines are appropriate since they provide interconnecting parties with six months’ notice, consistent with current practice. The Commission therefore directs NG9-1-1 network providers to make available to interconnecting parties and file for the Commission’s information the interconnection specifications (item 21 in the Appendix), by 6 January 2020 for the provision of NG9-1-1 Voice service, and by 30 June 2020 for the provision of NG9-1-1 Text Messaging service.
  10. The Commission approves the changes to the list of CODECs described in paragraph 16 above, such that the current complete list of mandatory audio CODECs is as follows: G.711 (A-law and μ-law), Adaptive Multi-Rate Audio (AMR), AMR-(wideband) WB, Opus (narrowband and wideband), with optional but recommended support for Enhanced Voice Services (EVS), G.722, and G.729.
  11. Finally, regarding the ESWG’s recommended authentication mechanism (PCA service), since (i) this mechanism is necessary for the launch of NG9-1-1 Voice service, (ii) a national entity in Canada has not stepped forward, and (iii) the NG9-1-1 network providers have indicated that they do not expect the costs to have a material impact on NG9-1-1 rates, the Commission considers the NG9-1-1 network providers’ proposal to provide a PCA service to be reasonable.
  12. The Commission agrees with the remainder of the ESWG’s recommendations. Accordingly, the Commission approves these recommendations and
    • directs NG9-1-1 network providers and other TSPs, as a condition of service pursuant to sections 24 and 24.1 of the Telecommunications Act, to implement the requirements that apply to them (items 1 to 6, 17 to 20, and 22 to 23 in the Appendix) by 30 June 2020;
    • encourages PSAPs to adopt the best practices that apply to them (items 7 to 9 in the Appendix) by 30 June 2020; and
    • requests that CISC create and manage the process for future changes to the mandatory list of CODECs, whereby CISC would present recommendations for the Commission’s consideration regarding changes to the mandatory list of audio CODECs to be supported by i3-compliant PSAPs, by 30 June 2020.

Policy Direction

  1. On 17 June 2019, the Governor General in Council registered the Order Issuing a Direction to the CRTC on Implementing the Canadian Telecommunications Policy Objectives to Promote Competition, Affordability, Consumer Interests and Innovation, SOR/2019-227 (the 2019 Policy Direction), which complements the previous Policy Direction issued in 2006.Footnote 15 Under the 2019 Policy Direction, the Commission must consider and specify how its determinations promote competition, affordability, consumer interests, or innovation, as applicable.
  2. The Report addresses technical matters relating to the compatibility, reliability, resiliency, and security of NG9-1-1 networks and the networks with which they interconnect. The Commission considers that by directing the NG9-1-1 network providers and TSPs to implement the various measures in support of NG9-1-1 implementation that apply to them as outlined in the Report, it is ensuring the proper functioning of these critical networks and thereby promoting consumer interests. As well, by approving the recommendations in the Report, the Commission is promoting innovation in the transition towards NG9-1-1 networks and services that are responsive to the public safety needs of Canadians.

Secretary General

Related documents

Appendix to Telecom Decision CRTC 2019-353

Requirements and best practices stemming from the Report

Requirements for next-generation 9-1-1 (NG9-1-1) network providers and telecommunications service providers (TSPs)

  1. TSPs and NG9-1-1 network providers must support a set maximumtransmission unit (MTU) value of 1,500 bytes for their network domain.
  2. TSPs must use registered autonomous system (AS)Footnote 16 numbers, when available; if not available, TSPs must bilaterally discuss the use of private AS numbers with the NG9-1-1 network provider(s) as part of interconnection logistics.
  3. When TSPs supply In-Call Dual Tone Multi-Frequency (DTMF) tones in-band, they must use an uncompressed CODEC such as G.711 when presented to the ESInet [Emergency Services Internet Protocol network] / NGCS [Next-Generation Core Services] in order to avoidissues that arise with lost or duplicated tones.
  4. NG9-1-1 network providers must provision each PSAP site they serve with two physically diverse Internet Protocol-virtual private network (IP-VPN) facilities to meet the reliability, resiliency, redundancy, and diversity requirements for NG9-1-1 where dual entries to the public safety answering point (PSAP) building exist or are possible.
  5. Where a 9-1-1 authority has designated one or more provincial or territorial default i3-compliant PSAP(s), the NG9-1-1 network provider must include this arrangement in its NG9-1-1 service agreement with the applicable 9-1-1 authority.
  6. TSPs must implement the following end-to-end encryption strategy:
    1. Transport Layer Security (TLS) over the Transmission Control Protocol (TCP) must be used for all protocol operations that support TLS.
    2. Fallback to unencrypted TCP and, as a last resort to unencrypted User Datagram Protocol (UDP), must be allowed for Session Initiation Protocol (SIP), and fallback to TCP must be allowed for HTTP [Hypertext Transfer Protocol], on an exceptional basis, to prevent an emergency assistance request from not being processed.
    3. To complement the Commission’s requirements regarding encryption set out in Telecom Decision 2018-217, the default cryptographic protocol must be TLS 1.2 using the Advanced Encryption Standard (AES)-256 bits encryption algorithm, or stronger.
    4. When item C above cannot be met by one party at the time of onboarding, a mutually agreeable interim solution must be negotiated by the trusted interconnecting parties (i.e. TSPs and PSAPs), as follows:
      1. When TLS 1.2 cannot be supported by one party, TLS 1.1 only must be used on an interim basis. TLS 1.0 must not be used.
      2. When the strongest cypher suite supported by the NG9-1-1 network provider that meets or exceeds the AES-256 bits encryption algorithm cannot be supported, the next most secure cyphers may be considered on an interim basis, ensuring that the strongest cypher that can be supported by both parties is selected.
      3. When encryption cannot be supported by one party, either on one or all of its peering network elements, non-encrypted communication can be used for a contractually defined grace period (as detailed in item v below).
      4. The period of deviation from the encryption method detailed in items i and ii above must be captured as part of the NG9-1-1 service agreement and followed up by the applicable interconnected parties.
      5. The interim solution grace period of up to nine months will be negotiated as part of an NG9-1-1 service agreement. The interconnected party must be compliant with the industry-adopted encryption solution before the grace period expires; otherwise, the NG9-1-1 network provider will coordinate a solution.
    5. For future changes to the TLS and encryption standards, TSPs, NG9-1-1 network providers, or PSAPs must submit a contribution to the ESWG. The ESWG will then evaluate and present recommendations to the Commission for consideration.

Best practices for PSAPs

  1. The Commission encourages PSAPs to follow the Engineering Best Practices presented by the NG9-1-1 network providers (see ESCO0577, ESCO0580, and ESCO0569) when considering interconnection to the ESInet and building their own internal infrastructure.
  2. The Commission encourages PSAPs to implement the encryption strategy, as described in item 6 above.
  3. The Commission encourages PSAPs to, as the preferred approach, support the reception and processing of in-call DTMF both in-band and out-of-band (as defined in the Internet Engineering Task Force’s Request for Comments [RFC] 4733), as natively provided by the TSPs. Should an i3-compliant PSAP support only one method (either in-band or out-of-band), it will be incumbent on this PSAP to interwork between the method presented and the method supported.

Mandatory conditions for i3-compliant PSAPs to interconnect to the NG9-1-1 networks through NG9-1-1 service agreements

  1. NG9-1-1 network providers must include, as part of their NG9-1-1 service agreement with applicable 9-1-1 authorities, the requirement for an i3-compliant PSAP to deploy Dual Stack as the preferred method for simultaneous use of IP version 4 and IP version 6 address space or to individually perform Network Address Translation - Protocol Translation (NAT-PT) for their network domain, as defined in the NG9-1-1 network provider’s User-to-Network Interface (UNI) interconnection specifications.
  2. NG9-1-1 network providers must include, as part of their NG9-1-1 service agreement with applicable 9-1-1 authorities, the requirement for an i3-compliant PSAP to support a set MTU value of 1,500 bytes for their network domain.
  3. NG9-1-1 network providers must include, as part of their NG9-1-1 service agreement with applicable 9-1-1 authorities, the requirement for an i3-compliant PSAP to use the Border Gateway Protocol (BGP) for dynamic routing between peering networks, using registered AS numbers when available.
  4. NG9-1-1 network providers must include, as part of their NG9-1-1 service agreement with applicable 9-1-1 authorities, the requirement that i3-compliant PSAPs use an i3-compliant Border Control Function (BCF), as defined in the NG9-1-1 network provider’s UNI interconnection specifications, and deploy BCFs in a manner that prevents single points of failure.
  5. NG9-1-1 network providers must include, as part of their NG9-1-1 service agreement with applicable 9-1-1 authorities, the requirement that i3-compliant PSAPs use the quality of service (QoS) strategy defined in the NG9-1-1 network provider’s UNI interconnection specifications.
  6. NG9-1-1 network providers must include, as part of their NG9-1-1 service agreement with applicable 9-1-1 authorities, the requirement that i3-compliant PSAPs implement the mandatory list of audio CODECs, which is (i) provided by the NG9-1-1 network providers as part of the production onboarding process, and (ii) updated through the proposed change management process managed by the CRTC Interconnection Steering Committee (CISC).
  7. NG9-1-1 network providers must include, as part of their NG9-1-1 service agreement with applicable 9-1-1 authorities, the requirement that i3-compliant PSAPs use the top-level PSAP Credentialing Agency (PCA) service provided by the NG9-1-1 network provider, as defined in the UNI interconnection specifications.

Network features to be provided by NG9-1-1 network providers to PSAPs

  1. NG9-1-1 network providers must make available their Next-Generation Core Services (NGCS) Authoritative Domain Name Service (DNS), as defined in National Emergency Numbering Association (NENA) i3, to interconnected i3-compliant PSAPs within their incumbent local exchange carrier (ILEC) territory.
  2. NG9-1-1 network providers must provision a Network Time Protocol Service (NTP), as defined in the NENA i3 architecture standard, for interconnected i3-compliant PSAPs within their ILEC territory.
  3. NG9-1-1 service providers must provision a top-level PCA service, as defined in NENA i3, until a nationwide PCA is established in the future, if one is established.
  4. NG9-1-1 network providers must provide private AS numbers to PSAPs that do not have registered AS numbers.

Deadline for the NG9-1-1 network providers to make the interconnection specifications available

  1. NG9-1-1 network providers are to file with the Commission and make available
    1. the production Network-to-Network Interface (NNI) interconnection specifications to interconnecting TSPs and to all other NG9-1-1 network providers in Canada; and
    2. the production UNI interconnection specifications to interconnecting PSAPs.

    These production interconnection specifications are to be made available

    1. by 6 January 2020 for the provision of NG9-1-1 Voice service (which is to be supported by 30 June 2020); and
    2. by 30 June 2020 for the provision of NG9-1-1 Text Messaging service (which is to be supported by 31 December 2020).

Provision of Location Information Server (LIS) and Additional Data Repository (ADR)

  1. NG9-1-1 network providers and TSPs must provision the hosted LIS and hosted Basic Call-ADR functionalities by leveraging the existing Enhanced 9-1-1 (E9-1-1) telephone number record provisioning feed in the following manner:
    1. NG9-1-1 network providers must populate with real or pseudo-civic addresses their respective Emergency Call Routing Function for the purpose of NG9-1-1 call routing.
    2. NG9-1-1 network providers must populate the hosted Basic Call-ADR with data that meets the E9-1-1 equivalency.
    3. TSPs opting to use the hosted functionalities must maintain the existing E9-1-1 provisioning process for their customer name and address records.
  2. TSPs that opt to self-provision their Basic Call-ADR must do so by reference, as opposed to by value, and format their Basic Call-ADR as defined by the NG9-1-1 network providers (e.g. in the NNI interconnection specifications).
Date modified: