La Federal Communications Commission a terminé d’enquêter sur T-Mobile pour une panne de réseau que le président Ajit Pai a qualifiée d ‘ »inacceptable ». Mais au lieu de punir l’opérateur mobile, la FCC émet simplement un avis public pour «rappeler» aux compagnies de téléphone les «meilleures pratiques acceptées par l’industrie» qui auraient pu empêcher la panne de T-Mobile.

Après la panne de 12 heures dans tout le pays le 15 juin, les services de SMS et d’appels ont interrompu les appels, y compris les appels d’urgence 911, Pai a écrit que «la panne du réseau T-Mobile est inacceptable» et que «la FCC lance une enquête. Nous exigeons des réponses – tout comme les consommateurs américains».

Pai a l’habitude de parler dur avec les transporteurs et de ne pas donner suite à des punitions qui pourraient avoir un effet dissuasif plus important que les avertissements sévèrement formulés. Cela semble être ce qui s’est encore produit hier lorsque le FCC a annoncé les résultats de son enquête sur T-Mobile. Pai a déclaré que « la panne de T-Mobile était un échec » parce que le transporteur n’avait pas suivi les meilleures pratiques qui auraient pu l’empêcher ou la minimiser, mais il n’a annoncé aucune sanction. L’affaire semble être close sur la base de l’annonce d’hier, mais nous avons contacté le bureau du président Pai aujourd’hui pour demander si une sanction de T-Mobile est imminente. Nous mettrons à jour cet article si nous obtenons une réponse.

FCC détaille les erreurs de T-Mobile

le rapport d’enquête du personnel a identifié plusieurs erreurs commises par T-Mobile lors de la panne, qui a commencé lorsque T-Mobile installait de nouveaux routeurs dans le sud-est des États-Unis. Lorsqu’une liaison de transport par fibre dans la région a échoué, le réseau de T-Mobile aurait dû transférer le trafic sur une liaison différente. Mais le transporteur « avait mal configuré le poids des liens vers l’un de ses routeurs », ce qui « empêchait le trafic de circuler vers le nouveau routeur actif comme prévu ». T-Mobile n’avait mis en œuvre aucun processus de sécurité pour éviter la mauvaise configuration ou pour alerter les ingénieurs réseau du problème.

Le marché d’Atlanta «s’est isolé» du reste du réseau, entraînant la perte de connectivité de tous les utilisateurs LTE de la région. Une erreur logicielle a aggravé les choses en empêchant les appareils mobiles de la région d’Atlanta de se réenregistrer auprès du sous-système multimédia IP via Wi-Fi. Au lieu d’acheminer les tentatives d’enregistrement de l’appareil vers un nœud différent, «le système d’enregistrement a acheminé à plusieurs reprises les tentatives de réenregistrement pour chaque appareil mobile vers le dernier nœud conservé dans ses enregistrements, qui n’était pas disponible en raison de l’isolement du marché».

L’erreur logicielle existait dans le réseau de T-Mobile depuis des mois. « Cette erreur logicielle n’a probablement pas causé de problèmes avant que cette panne ne se produise, car la panne était le premier isolement notable du marché depuis que T-Mobile a intégré ce logiciel dans son réseau », a déclaré la FCC. Des tests réguliers « auraient pu découvrir la faille logicielle et la mauvaise configuration du routage avant qu’ils n’aient un impact sur les appels en direct », a également déclaré la FCC.

Après le début des troubles du 15 juin, les ingénieurs de T-Mobile « ont fini par exacerber [the outage’s] impact parce qu’ils ont mal diagnostiqué le problème. »Le rapport de la FCC poursuit:

T-Mobile croyait que la liaison de transport par fibre optique qui avait échoué plus tôt dans la journée continuait de provoquer la panne en cours. En se fondant sur cette croyance, T-Mobile a arrêté manuellement le lien pour tenter d’en transférer le trafic. Cependant, en raison des poids Open Shortest Path First toujours mal configurés, ces étapes ont recréé les conditions initiales de la panne. Les clients LTE du marché d’Atlanta ont de nouveau été déconnectés du réseau LTE et forcés d’établir des appels via Wi-Fi, et leurs tentatives d’enregistrement ont de nouveau échoué et ont créé une tempête d’enregistrement qui a ajouté une congestion supplémentaire au sous-système multimédia IP de T-Mobile.

Les ingénieurs de T-Mobile ont presque immédiatement reconnu qu’ils avaient mal diagnostiqué le problème. Cependant, ils n’ont pas été en mesure de résoudre le problème en restaurant le lien car les outils de gestion de réseau nécessaires pour le faire à distance s’appuyaient sur les mêmes chemins qu’ils venaient de désactiver. Lorsque les ingénieurs de T-Mobile ont pu accéder à l’équipement sur place et corriger leur erreur en rétablissant la liaison une heure plus tard, les clients du marché d’Atlanta ont à nouveau pu tenter de s’inscrire à VoLTE. [Voice over LTE]. Cependant, cela a à nouveau créé une congestion supplémentaire car les ingénieurs de T-Mobile n’avaient pas encore résolu l’erreur logicielle qui empêchait les enregistrements de se terminer.

La panne s’étend à l’échelle nationale

Le rapport de la FCC a expliqué comment la panne s’est propagée du marché d’Atlanta à l’échelle nationale. Le trafic externe destiné au système d’Atlanta a été redirigé vers d’autres régions, ce qui « a créé suffisamment de congestion dans ces systèmes d’enregistrement pour que le réseau T-Mobile envoie les tentatives d’enregistrement à d’autres nœuds. L’erreur logicielle a de nouveau acheminé les tentatives de réenregistrement vers le dernier. nœud enregistré, qui connaissait probablement déjà une forte congestion.  » Peu de temps après, «les enregistrements de sous-système multimédia IP, VoLTE et voix sur Wi-Fi ont commencé à échouer dans tout le pays».

La grande majorité des clients de T-Mobile n’ont pas pu se connecter aux réseaux Voice over LTE ou Voice over Wi-Fi, et ont donc «retombé sur les réseaux à commutation de circuits 3G et 2G de T-Mobile pour passer et recevoir des appels pendant que l’appareil continuait son tentatives d’enregistrement sur le réseau VoLTE.  » Cela a entraîné une congestion 3G et 2G, entraînant l’échec de nombreux appels téléphoniques. Les nœuds du réseau ont continué à détenir des ressources pour ces sessions d’appel après la fin des appels, surchargeant les ressources informatiques des nœuds et provoquant encore plus d’échecs d’appels.