Recherche

Décision de télécom CRTC 2018-108

Version PDF

Ottawa, le 29 mars 2018

Dossier public : 8621-C12-01/08

Comité directeur du CRTC sur l’interconnexion – Rapports de consensus sur un calendrier et une méthodologie proposés relatifs aux messages d’alerte d’essai du service d’alertes sans fil au public

Contexte

  1. Dans la politique réglementaire de télécom 2017-91, le Conseil a ordonné aux fournisseurs de services sans fil (FSSF) de mettre en œuvre une capacité d’alertes sans fil au public sur leurs réseaux, excluant les réseaux antérieurs à la technologie d’évolution à long terme (LTE), d’ici le 6 avril 2018. Le Conseil a aussi demandé au Comité directeur du CRTC sur l’interconnexion (CDCI) de résoudre un certain nombre de questions en suspens relatives au service d’alertes sans fil au public (SASFP) avant la distribution obligatoire de messages d’alerte en cas d’urgence, y compris l’établissement d’un calendrier et d’une méthodologie relatifs aux messages d’alerte d’essai du SASFP.

Rapport

  1. Le Conseil a reçu les deux rapports de consensus suivants du Groupe de travail Réseau (GTR) du CDCI sur un calendrier et une méthodologie proposés relatifs aux messages d’alerte d’essai du SASFP :
    • Wireless Public Alerting (WPA) – Testing Schedule (NTRE059, 3 octobre 2017)
    • Wireless Public Alerting (WPA) – Test Message Handling (NTRE060, 31 octobre 2017)
  2. On peut consulter ces rapports de consensus sur le site Web du Conseil à l’adresse www.crtc.gc.ca, dans la section « Rapports » de la page du GTR, qui se trouve sous la rubrique du CDCI.
  3. Le GTR a fait les trois recommandations suivantes liées au calendrier et à la méthodologie concernant les messages d’alerte d’essai du SASFP :
    • Le calendrier relatif aux messages d’alerte d’essai du SASFP devrait comporter cinq essais par année, comme le recommande le groupe de travail sur les alertes au public des cadres supérieurs responsables de la gestion des urgences (CSRGU) en ce qui concerne la diffusion de messages d’alerte en cas d’urgence. Seul le message d’alerte d’essai diffusé au cours de la Semaine de la sécurité civile en mai de chaque année serait visible aux utilisateurs finals. Les quatre autres messages d’alerte d’essai seraient transmis au moyen du canal d’essai du SASFP et seraient invisibles aux utilisateurs finals.
    • Pelmorex Weather Networks (Television) Inc. (Pelmorex)Note de bas de page 1, à titre d’exploitant actuel du Système d’agrégation et de dissémination national d’alertes (système ADNA), devrait mettre en œuvre la solution de gestion des messages d’alerte d’essai invisibles décrite dans le rapport NTRE060 au plus tard à la mi-décembre 2017. Si Pelmorex met en œuvre cette solution, il ne serait pas nécessaire de modifier la norme ATISNote de bas de page 2 0700021Note de bas de page 3.
    • Le GTR devrait continuer de mettre à jour les spécifications de l’interface d’entrepriseNote de bas de page 4 du SASFP et déployer la version 2.0 de l’interface d’entreprise.
  4. Pelmorex a indiqué qu’il y a un risque que de nombreux messages d’alerte d’essai visibles soient diffusés pendant la Semaine de la sécurité civile en raison d’une erreur humaine en aval, de la diffusion des messages d’alerte par différentes organisations de gestion des urgences (OGU) ou de la rediffusion intentionnelle d’un message d’alerte par les OGUNote de bas de page 5.

Résultats de l’analyse du Conseil

  1. Le Conseil estime qu’il est approprié que le calendrier relatif aux messages d’alerte d’essai du SASFP corresponde au calendrier d’essai des messages d’alerte radiodiffusés des CSRGU qui prévoit cinq essais par année, car cela permettrait i) de tester efficacement le SASFP afin de confirmer qu’il est prêt à être mis en opération, et ii) de tester efficacement le système de radiodiffusion et le système d’alertes sans fil au public simultanément en tenant compte de la façon dont les alertes au public seront diffusées.
  2. Le Conseil estime également qu’il est approprié que la solution de gestion des messages d’alerte d’essai invisibles soit mise en œuvre par l’exploitant actuel du système ADNA, Pelmorex. Pelmorex devrait également mettre en application les procédures et les mesures de protection nécessaires pour atténuer le risque que des messages d’alerte d’essai visibles soient émis par inadvertance en raison d’une erreur humaine et faire en sorte que de nombreux messages d’alerte d’essai ne soient pas émis par différentes OGU, ce qui créerait de la confusion quant aux essais. Pour ce faire, Pelmorex devrait notamment assurer une formation et une coordination appropriées en ce qui concerne la diffusion des messages d’alerte d’essai et respecter le calendrier relatif aux messages d’alerte d’essai.
  3. Les spécifications techniques du SASFP doivent être mises à jour au fil du temps afin d’intégrer les améliorations apportées à sa fonctionnalité ou d’intégrer de nouvelles fonctions avantageuses. Le GTR a déployé la version 2.0 de l’interface d’entreprise du SASFP, qui est maintenant accessible aux FSSF. Le Conseil estime qu’il serait avantageux pour les intervenants du SASFP et le SASFP dans son ensemble que le GTR continue de mettre à jour les spécifications de l’interface d’entreprise du SASFP.
  4. Par conséquent, le Conseil :
    • approuve le calendrier proposé relatif aux messages d’alerte d’essai qui prévoit cinq essais par année, conformément au calendrier d’essai des CSRGU pour la diffusion d’alertes en cas d’urgence. Un seul de ces essais sera visible aux utilisateurs finals; il se déroulera chaque année pendant la Semaine de la sécurité civile. Les quatre autres essais seront invisibles aux utilisateurs finals;
    • approuve la recommandation selon laquelle le GTR devrait mettre à jour les spécifications de l’interface d’entreprise du SASFP de temps à autre, selon les besoins;
    • s’attend à ce que l’exploitant du système ADNA :
      • mette en œuvre, si ce n’est pas déjà fait, une solution de gestion des messages d’alerte d’essai invisibles au plus tard le 6 avril 2018;
      • mette en application les procédures et les mesures de protection nécessaires pour atténuer le risque que des messages d’alerte d’essai visibles soient émis par inadvertance en raison d’une erreur humaine et faire en sorte que de nombreux messages d’alerte d’essai ne soient pas émis par différentes OGU et que les messages d’alerte d’essai ne soient pas rediffusés intentionnellement par les OGU;
      • travaille avec les OGU pour offrir aux émetteurs d’alerte et à d’autres acteurs pertinents en matière d’alertes de la formation sur la réalisation des essais de diffusion de messages d’alerte et le respect du calendrier relatif aux messages d’alerte d’essai.
  5. Compte tenu de ce qui précède et de la décision 2018-85, le Conseil confirme que les FSSF doivent diffuser des messages d’alerte en cas d’urgence au public à compter du 6 avril 2018, ce qui correspond également à la date limite pour la mise en œuvre de la capacité d’alertes sans fil au public imposée dans la politique réglementaire de télécom 2017-91. Le Conseil impose donc les obligations suivantes aux FSSF, conformément aux articles 24 et 24.1 de la Loi sur les télécommunications :

    À compter du 6 avril 2018, tous les FSSF sont tenus, comme condition de fourniture des services, de diffuser immédiatement les messages d’alerte d’urgence émis par l’exploitant du système ADNA en vue d’une diffusion immédiate. Les messages d’alerte en cas d’urgence doivent être transmis sur les réseaux utilisés par les FSSF, excluant les réseaux antérieurs à la technologie LTE, afin que tous les appareils sans fil mobiles compatibles avec le SASFP connectés aux tours de téléphonie cellulaire qui prennent en charge le réseau et qui desservent la totalité ou une partie de la zone définie par l’OGU ayant émis le message d’alerte reçoivent le message d’alerte en cas d’urgence (comme il est décrit dans la politique réglementaire de télécom 2017-91).

Mécanisme de refus

Recommandation du GTR

  1. Le GTR a recommandé que les FSSF soient autorisés à « refuser » de transmettre les messages d’alerte d’essai dans les circonstances décrites dans le rapport NTRE059 (comme une urgence touchant le fonctionnement du réseau de télécommunication) et dans d’autres circonstances extraordinaires (comme la perte de redondance d’une plateforme ou une panne de transmission), dans les cas où un message d’alerte d’essai du SASFP ferait augmenter le trafic sur les réseaux de téléphonie et exacerberait l’urgence touchant le fonctionnement. Le GTR a indiqué que le mécanisme de refus devrait inclure la méthode (p. ex. par téléphone ou par courriel) par laquelle le FSSF demanderait à l’émetteur du message d’alerte d’essai (c.-à-d. l’exploitant du système ADNA ou l’OGU) de ne pas lui transmettre le message d’alerte d’essai, et que ce mécanisme devrait être intégré aux procédures d’essai du SASFP.

Résultats de l’analyse du Conseil

  1. Le Conseil estime qu’une urgence touchant le fonctionnement du réseau de télécommunication, la perte de redondance d’une plateforme et une panne de transmission sont des circonstances rares et qu’elles sont très peu susceptibles de se produire pendant des essais d’alerte périodiques. Il est toutefois possible que ces circonstances se produisent, et il est important que le Conseil indique ce que doivent faire les FSSF dans ces circonstances.
  2. Des essais d’alerte invisibles sont menés afin d’assurer le bon fonctionnement du système d’alerte, et des essais d’alerte visibles sont menés pour faire connaître le SASFP aux Canadiens. Si les FSSF refusent de diffuser un message d’alerte d’essai visible, un grand nombre d’utilisateurs finals pourraient ne pas recevoir l’alerte, ce qui créerait de la confusion au sein de la population canadienne et des intervenants du SASFP, puisque la date et l’heure prévues de la diffusion du message d’alerte d’essai visible auront été communiquées pendant la campagne de sensibilisation et d’éducation du public sur le SASFP et les essais auront été effectués par tous les autres FSSF et les intervenants du SASFP selon le calendrier préétabli relatif aux messages d’alerte d’essai.
  3. Afin de dissiper la confusion découlant du refus d’un FSSF de participer à la diffusion d’un message d’essai visible prévu, ce FSSF doit aviser rapidement ses utilisateurs finals touchés i) de la situation qui l’a empêché de participer à l’essai et ii) du moment auquel les utilisateurs finals seront de nouveau en mesure de recevoir un message d’alerte d’essai si une OGU émettait un tel message. De plus, le Conseil estime qu’il est raisonnable qu’un FSSF qui sait qu’il ne sera pas en mesure de participer à l’un des essais prévus, dans une région en particulier ou dans sa zone de couverture, en informe le Conseil et l’exploitant du système ADNA.
  4. En outre, le FSSF doit soumettre un rapport d’incident au Conseil dans un délai de sept jours après avoir pris conscience qu’il ne sera pas en mesure de participer aux essais ou dans un délai de sept jours après les essais d’alerte visibles ou invisibles prévus, selon la première des éventualités. Le rapport d’incident devrait comprendre i) une explication de la raison pour laquelle le FSSF n’est pas ou n’a pas été en mesure de diffuser le message d’alerte d’essai, ii) le message envoyé à ses utilisateurs finals touchés, iii) les régions touchées, et iv) le nombre estimé d’utilisateurs finals touchés. De plus, le FSSF devrait mener des essais internes afin de s’assurer qu’il a la capacité opérationnelle nécessaire pour diffuser les alertes d’urgence après une urgence touchant le fonctionnement du réseau.
  5. Compte tenu de ce qui précède, le Conseil approuve la recommandation du GTR selon laquelle un FSSF doit être en mesure de « refuser » de diffuser un message d’alerte d’essai dans les circonstances décrites dans le rapport NTRE059, aux conditions suivantes :
    • Le Conseil ordonne aux FSSF concernés d’aviser leurs utilisateurs finals touchés i) de l’urgence touchant le fonctionnement du réseau ou de toute autre situation extraordinaire qui l’a empêché de diffuser le message d’alerte d’essai visible, et ii) du moment auquel les utilisateurs finals seront de nouveau en mesure de recevoir un message d’alerte d’essai si une OGU émettait un tel message.
    • Le Conseil ordonne aux FSSF concernés d’informer immédiatement le Conseil et l’exploitant du système ADNA dès qu’il sait qu’il ne sera pas en mesure de participer à l’un des essais d’alerte visibles ou invisibles prévus dans une région en particulier ou dans sa zone de couverture. De plus, le FSSF doit soumettre un rapport d’incident au Conseil dans un délai de sept jours après avoir pris conscience qu’il ne sera pas en mesure de participer aux essais ou dans un délai de sept jours après les essais prévus, selon la première des éventualités. Le rapport d’incident doit comprendre i) une explication de la raison pour laquelle le FSSF n’est pas ou n’a pas été en mesure de diffuser le message d’alerte d’essai, ii) le message envoyé à ses utilisateurs finals touchés si l’essai auquel le FSSF ne participe pas ou ne participera pas est un essai visible, iii) les régions touchées, et iv) le nombre estimé d’utilisateurs finals touchés.
    • Le Conseil ordonne aux FSSF concernés, dès que l’urgence touchant le fonctionnement du réseau ou toute autre situation extraordinaire aura été réglée, de mener des essais internes afin de confirmer qu’ils ont la capacité opérationnelle nécessaire pour diffuser les messages d’alerte d’essai et de fournir rapidement une confirmation à cet égard au Conseil, à l’exploitant du système ADNA et aux autres intervenants du SASFP.

Secrétaire général

Documents connexes

Date de modification :