ARCHIVED - Telecom Decision CRTC 2006-60

This page has been archived on the Web

Information identified as archived on the Web is for reference, research or recordkeeping purposes. Archived Decisions, Notices and Orders (DNOs) remain in effect except to the extent they are amended or reversed by the Commission, a court, or the government. The text of archived information has not been altered or updated after the date of archiving. Changes to DNOs are published as “dashes” to the original DNO number. Web pages that are archived on the Web are not subject to the Government of Canada Web Standards. As per the Communications Policy of the Government of Canada, you can request alternate formats by contacting us.

 

Telecom Decision CRTC 2006-60

  Ottawa, 21 September 2006
 

CRTC Interconnection Steering Committee - Consensus report on E9-1-1 services provided to nomadic and fixed/non-native VoIP subscribers

  Reference: 8621-C12-01/00, 8663-C12-200402892 and 8663-B2-200316101
  In this Decision, the Commission approves the recommendations in the CRTC Interconnection Steering Committee Emergency Services Working Group (ESWG) Consensus Report ESRE042, ESWG 12-month Consensus Report on Nomadic VoIP Technical and Operating Impediments to 9-1-1/E9-1-1 Service Delivery in Canada, and requests the ESWG to file, within six months of the date of this Decision, a functional architecture for the implementation of VoIP E9-1-1 service in Canada.
 

Background

1.

In Emergency service obligations for local VoIP service providers, Telecom Decision CRTC 2005-21, 4 April 2005 (Decision 2005-21), the Commission directed Canadian carriers supporting nomadic local voice over Internet Protocol (VoIP) services or fixed/non-native local VoIP services to implement an interim solution that would provide a level of 9-1-1 service functionally comparable to Basic 9-1-1 service in areas where 9-1-1/Enhanced 9-1-1 (E9-1-1) service was available from the incumbent local exchange carrier (ILEC). The solution was to be implemented within 90 days from the date of the Decision.

2.

In light of the public safety issues related to the limitations on 9-1-1/E9-1-1 service provided with local VoIP services, in Decision 2005-21 the Commission requested the CRTC Interconnection Steering Committee (CISC) Emergency Services Working Group (ESWG) to submit a report identifying the technical and operational issues that impeded 9-1-1/E9-1-1 service delivery when local VoIP service was offered on a fixed/non-native basis. This report was due within six months from the date of the Decision. The Commission indicated that the report should identify all viable solutions and recommend the preferred solution(s), with supporting rationale, and a proposed time frame for implementation.

3.

The Commission also requested that the ESWG submit a similar report with respect to 9-1-1/E9-1-1 service provided to nomadic local VoIP subscribers within one year from the date of the Decision.

4.

On 3 November 2005, the Commission received ESWG Consensus Report ESRE041, Identification of Issues for Provision of 9-1-1/E9-1-1 Service to Fixed/Non-Native VoIP Customers, dated 27 October 2005.

5.

In CRTC Interconnection Steering Committee - Consensus item: Consensus report on 9-1-1/E9-1-1 services provided to fixed/non-native VoIP subscribers, Telecom Decision CRTC 2005-73, 20 December 2005 (Decision 2005-73),the Commission approved the ESWG recommendation in ESRE041 that the Commission consider the proposals to be put forward in the ESWG report on nomadic 9-1-1/E9-1-1 services before making a final determination on the solution(s) to be implemented by VoIP service providers in order to improve the provision of 9-1-1/E9-1-1 services.
 

The Report

6.

On 31 May 2006, the Commission received ESWG Consensus Report ESRE042, ESWG 12-month Consensus Report on Nomadic VoIP Technical and Operating Impediments to 9-1-1/E9-1-1 Service Delivery in Canada, dated 24 May 2006 (the Report). The Report is available through the Commission's CISC ESWG website at the following address: http://www.crtc.gc.ca/public/cisc/es/ESRE0042.doc.

7.

The Report identifies the many technical and operational issues that impede E9-1-1 service delivery to nomadic and fixed/non-native customers in a VoIP environment. The Report then identifies and analyzes all viable solutions and recommends the deployment of a Canadian version of the i2 solution developed by the National Emergency Number Association (NENA).1

8.

However, in the Report the ESWG noted the need for the implementation of a Canadian i2 solution to accommodate the differences between the Canadian and American environments. These differences include the regulatory environment; the difference in size and complexity of the public switched telephone network; the 9-1-1 systems framework, including public safety answering point equipment and interfaces; and the funding model.

9.

As the first step in the deployment, the ESWG proposed to file a functional architecture for the implementation of VoIP E9-1-1 service in Canada for Commission approval within six months of the Commission's approval of the Report.

10.

The ESWG submitted that this architecture would be consistent with the NENA i2 standard, modified as necessary for implementation in Canada, and would include a timeline for implementation of the key deliverable elements.

11.

The ESWG noted that its report on the architecture would include a specification of the roles and responsibilities of all emergency services industry participants, particularly those who will supply the new operating elements. The ESWG recommended that following the Commission's approval of the proposed architecture, the industry be granted a minimum of 12 months to implement the Canadian i2 solution.

12.

The ESWG noted that during the 12-month deliberations leading to the Report, its members had not agreed on the process of how to develop a cost recovery mechanism. The ESWG indicated that some members had suggested that cost recovery be a part of the proposed architecture plan, while others were of the view that CISC was not the forum for such discussion and that the development of a cost recovery mechanism would not influence the proposed technical solution.

13.

The ESWG requested that in its disposition of the Report, the Commission provide guidance or direction on whether the ESWG should include cost recovery in the development of the architecture plan and, if so, to what level of detail. The ESWG also requested that if the Commission did not provide such direction, it provide an indication as to where and how this issue would be addressed.

14.

In addition, the ESWG requested that the Commission continue the practice of supporting the advancement in emergency services by providing deadlines for the accomplishment of specific tasks through decisions and direct the commencement of this deployment as quickly as practical.
 

Commission's analysis and determinations

15.

The Commission notes that in Decision 2005-73 it deferred making a final determination on the type of 9-1-1 solution(s) to be used for 9-1-1/E9-1-1 services to fixed/non-native VoIP customers until all possible solutions had been explored and evaluated. This decision was based on the prospect that the nomadic solution could address the technical and operational issues that impeded E9-1-1 service delivery to both nomadic and fixed/non-native customers, and that this could eliminate the need for expensive modifications to the existing "legacy" platforms that would only address the less common fixed/non-native case.

16.

The Commission notes that the Report has identified and analyzed the many technical and operational issues that impede E9-1-1 service delivery to both nomadic and fixed/non-native customers in a VoIP environment. The Commission notes that the ESWG, after this wide-ranging investigation, reached a consensus that the solution recommended in the Report is the only viable solution.

17.

Based on its review of the Report, the Commission approves the ESWG's recommendations and requests the ESWG to file, within six months of the date of this Decision, a functional architecture for the implementation of VoIP E9-1-1 service in Canada. The Commission considers that this architecture should be consistent with the NENA i2 standard, modified as necessary for implementation in Canada, and that it should include a timeline for implementation of the key deliverable elements.

18.

The Commission also considers that the ESWG's report on the architecture should specify the roles and responsibilities of all emergency services industry participants, particularly those who will supply the new operating elements.

19.

The Commission considers that it would be premature at this time to direct the development of a cost recovery mechanism. The Commission also considers that it will only be appropriate to examine this issue after it has received and reviewed the ESWG report on the functional architecture for the implementation of a Canadian i2 solution.

20.

More importantly, the Commission considers that both the Commission and the industry must first understand the specific roles and responsibilities of all emergency services industry participants, particularly those supplying the new operating elements, before any examination of a cost recovery mechanism.

21.

Finally, the Commission notes that, if necessary, it will provide guidance to the industry on how and when the issue of cost recovery will be dealt with as part of any implementation directives upon the disposition of the ESWG's architecture report.
  Secretary General
  This document is available in alternative format upon request, and may also be examined in PDF format or in HTML at the following Internet site: www.crtc.gc.ca
  ___________

Footnote:

1  NENA is a joint industry and public safety body that promotes research and planning for the 9‑1‑1 service in North America and plays a key role in gaining agreement on the development of IP and VoIP solutions for 9‑1‑1 service. The NENA i2 architecture was designed to enable VoIP telecommunications service providers to deliver full E9‑1‑1 service through the existing E9‑1‑1 infrastructure.

Date Modified: 2006-09-21

Date modified: