Zusammenfassung

  • Der AT&T-Fernverkehrsausfall vom 15. Januar 1990 war nach dem vorliegenden Quellenpaket kein Beleg für Sabotage, Virusbefall oder einen gleichzeitigen Ausfall aller 4ESS-Systeme. Die technische Zäsur lag in einer gemeinsamen Softwareänderung an der CCS7-Signalisierungsumgebung: Ein normaler Erholungsvorgang nach einem kleinen New Yorker Hardwareereignis konnte durch eng aufeinanderfolgende Initial Address Messages eine Direct-Link-Node-Zustandsaktualisierung beschädigen und benachbarte Vermittlungen in denselben instabilen Ablauf treiben.
  • Die Rechenschaftsfrage betrifft nicht nur Fehlerfreiheit von Code. Sie betrifft die Kontrolle über laufenden Netzcode, Statuskarten, Duplikatprozessoren, Backup-Signalisierungswege, Rollout-Reichweite, Rücknahmefähigkeit und unabhängige Nachprüfung. Der Vorfall zeigt, dass Telekom-Kontinuität dort entschieden wird, wo ein Betreiber Zustandsübergänge im Signalisierungsnetz messen, begrenzen und zurückdrehen kann.

Der Vorfall begann nach AT&Ts technischer Darstellung am 15. Januar 1990 gegen 14:30 Uhr Eastern Standard Time mit einem 4ESS-Fernvermittlungssystem in New York. Dieses System erlebte ein geringfügiges Hardwareproblem an einer Schnittstelle, die in der öffentlichen Rekonstruktion als Auslöser der Erholungskette erscheint. Wichtig ist die Trennung: Dieses Ereignis war der Startimpuls, nicht die nationale Ursache. Die betroffene 4ESS-Vermittlung tat zunächst, was eine große Telefonvermittlung im Fehlerfall tun sollte.

Sie unterbrach die Annahme neuer Verbindungsaufbauversuche für ungefähr vier bis sechs Sekunden, führte eine normale Wiederherstellung aus und signalisierte verbundenen 4ESS-Systemen, vorübergehend keine neuen Anrufe an sie zu senden.

Dieser kurze lokale Erholungsvorgang wäre in einem hinreichend entkoppelten Signalisierungsnetz kein landesweiter Ausfall gewesen. Die technische Bedeutung liegt darin, was beim Wiederanschluss geschah. Als die New Yorker Vermittlung wieder Anrufverarbeitung aufnahm, sandte sie Initial Address Messages, kurz IAMs, an benachbarte Vermittlungen. IAMs sind keine Schadpakete im heutigen Sinn, sondern reguläre Signalisierungsnachrichten zum Aufbau eines Anrufs.

Nach AT&Ts eigener Darstellung nutzte ein Direct Link Node, also ein DLN-Prozessor in einer empfangenden Vermittlung, diese Nachrichten, um seine Statuskarte zu aktualisieren und zu erkennen, dass New York wieder verfügbar war. Während dieser Statusaktualisierung bestand für mehrere Sekunden ein empfindliches Zeitfenster. Wenn zwei IAMs innerhalb eines Hundertstels einer Sekunde eintrafen, konnte die Datenstruktur des Prozessors beschädigt werden, woraufhin der Prozessor neu initialisierte.

Die Details dieser IAM- und DLN-Zeitbedingung sind AT&T zuzuschreiben. Das Quellenpaket enthält keine freigegebene Quellcodeablage, keinen vollständigen Diff, keine Compileranalyse und keine bestätigte Datenstrukturbeschreibung. Spätere softwaretechnische Erzählungen sprechen von einer falsch platzierten Anweisung im Programmablauf. Solche Darstellungen sind nützlich als sekundäre Narrative, aber nicht als primärer Codebeweis. Deshalb darf die Analyse nicht behaupten, der öffentliche Befund sei eine gesicherte Ein-Zeilen-Codeursache.

Der gesicherte Kern ist enger: AT&T beschrieb ein zeitabhängiges Verhalten beim Aktualisieren der DLN-Statuskarte, ausgelöst durch zwei gültige IAMs in extrem kurzem Abstand, während eine Vermittlung einen Nachbarn als wieder betriebsbereit registrierte.

Gerade diese Enge macht den Befund technisch schärfer. Der 1990er Vorfall ist kein Fall, in dem die Steuerungsebene von außen mit ungewöhnlichen oder offenkundig schädlichen Nachrichten überflutet wurde. Nach dem vorliegenden Paket reichen reguläre Signalisierungsnachrichten, ein normaler Wiederanlauf und ein gemeinsamer Programmzustand aus, um die Kontrolllogik zu treffen. Die richtige Frage lautet deshalb nicht, ob ein Betreiber jede denkbare Störung vorhersagen kann.

Sie lautet, ob er die Zustandsübergänge seiner eigenen Wiederherstellungslogik so prüft, dass gültige Nachrichten in plausiblen zeitlichen Abständen nicht aus Erholung Ausbreitung machen. Ein Test, der nur stabile Verbindungsaufbauten oder einzelne Fehlerpfade betrachtet, würde genau den gefährlichen Moment übersehen: den kurzen Übergang zwischen „Nachbar ist nicht verfügbar“ und „Nachbar ist wieder verfügbar“, während weiterhin echte Anrufsignale eintreffen.

Die zweite wichtige Grenze betrifft Redundanz. Die betroffene Vermittlung hatte einen duplizierten Gegenprozessor. Nach AT&Ts Darstellung übernahm dieser Mate-Prozessor den Verkehr, nachdem der erste DLN-Prozessor neu initialisieren musste. Das klingt zunächst nach Resilienz. Im konkreten Zustand war es aber keine unabhängige Schutzgrenze, weil beide Prozessoren demselben Code und derselben zeitkritischen Bedingung ausgesetzt waren. Traf auf den zweiten Prozessor erneut ein eng gepaartes IAM-Muster während der entsprechenden Statusaktualisierung, konnte auch er neu initialisieren.

In diesem Moment wurde die Vermittlung zeitweise vom CCS7-Signalisierungsnetz isoliert. Die Sprach- oder Trägerpfade allein genügten nicht, wenn die gemeinsame Signalisierungsschicht den Verbindungsaufbau und die Zustandskoordination nicht stabil tragen konnte.

Diese Art korrelierter Redundanz ist besonders tückisch, weil sie im Normalbetrieb wie Kapazität oder Schutz aussieht. Zwei Prozessoren können Last verteilen, schnelle Übernahme ermöglichen und einzelne Hardwarefehler abfangen. Sie bilden aber keinen zweiten Kontrollbereich, wenn sie denselben Zustandsautomaten, dieselbe Version, dieselben Annahmen über Nachrichtenabstände und dieselben Kartenaktualisierungen nutzen. Die operative Unabhängigkeit entsteht nicht durch die Zahl der Prozessoren, sondern durch die Trennung der Fehlerursachen.

Wenn beide DLN-Prozessoren denselben Übergang ausführen, ist der Ausfall des ersten Prozessors nicht nur ein Ereignis, auf das der zweite reagiert. Er ist auch ein Hinweis darauf, dass der zweite in wenigen Sekunden denselben Pfad betreten kann. Genau deshalb muss Redundanz in Signalisierungssystemen als Fehlerbereich modelliert werden, nicht als statische Stückzahl.

CCS7 war dabei nicht eine Randkomponente. ITU-T-Empfehlungen zu Signalling System No. 7 beschreiben die Architektur einer gemeinsamen Signalisierung mit Message Transfer Part, Netzdiensten, Leistungsanforderungen, Überwachung und Messung. Diese Dokumente belegen im Quellenpaket keine rückwirkende Normverletzung durch AT&T. Sie erklären aber, warum Status-, Routing-, Erholungs- und Verbindungsaufbaunachrichten eine operative Steuerungsschicht bilden.

In einem Fernverkehrsnetz kann die Nutzbarkeit der Dienstebene daran hängen, ob diese Steuerungsschicht korrekt weiß, welcher Nachbar verfügbar ist, welche Signalisierungsverbindung belastbar ist und welcher Softwarezustand gerade Signale verarbeitet.

Die Kaskade entstand, weil Erholung und Ausbreitung denselben Kanal benutzten. Eine Vermittlung, deren Signalisierungsprozessoren ausfielen, meldete einen nicht verfügbaren Zustand. Nach der Neuinitialisierung nahm sie die Signalisierung wieder auf. Nachbarvermittlungen mussten diesen Rückkehrzustand verarbeiten. Genau dort lag das empfindliche Zeitfenster. Unter fortlaufender Anruf- und Signalisierungslast konnten mehrere Vermittlungen in zufälliger Reihenfolge dieselbe Bedingung erleben. Der Mechanismus war also kein einfacher Dominoausfall durch einen defekten Schalter.

Er war ein Feedback zwischen gültigen Kontrollnachrichten, gemeinsamer Softwarelogik und automatischen Erholungszuständen.

Für die Analyse von Zustandsübergängen ist dieser Punkt zentral. Ein stabiler Knoten sendet Anrufsignale, ein nicht verfügbarer Knoten sendet keine normalen neuen Verbindungsaufbaupfade, und ein zurückkehrender Knoten erzeugt eine dritte Lage: Er ist gerade wieder in die Signalisierungsbeziehung eingetreten, während seine Nachbarn ihre Sicht auf ihn korrigieren. Dieser Übergang ist kurz, aber nicht nebensächlich. Wenn während genau dieses Fensters mehrere IAMs fast gleichzeitig eintreffen, muss die Software entweder serialisieren, puffern, verwerfen, konsistent wiederholen oder kontrolliert abbrechen.

Sie darf die Statuskarte nicht in einen Zustand bringen, der den Signalisierungsprozessor neu startet und dadurch den nächsten Rückkehrzyklus vorbereitet. Ein realistischer Test müsste daher nicht nur fragen, ob ein einzelnes IAM korrekt verarbeitet wird, sondern was passiert, wenn gültige IAMs in enger Folge während einer Kartenänderung eintreffen, wenn der erste Prozessor gerade gefallen ist und wenn der zweite denselben Nachbarzustand übernimmt.

Spätere akademische Arbeiten ordnen den Vorfall als Beispiel für eine Kontrollschichtinstabilität ein, bei der reguläre Protokollnachrichten eine latente Implementierungsschwäche auslösen können. Auch das darf nicht überdehnt werden. Die Quellen stützen hier keinen Angriff und keinen absichtlich präparierten Schadinhalt. Der Erkenntniswert liegt gerade darin, dass ein Netz auch ohne böswillige Eingriffe instabil werden kann, wenn gültige Nachrichten in einem ungetesteten Zustandsübergang eine wiederholbare Schwäche aktivieren.

Für Rechenschaft bedeutet das: Die Frage ist nicht nur, ob ein Paket formal gültig war, sondern ob der Betreiber den Übergangszustand, die Wiederholbarkeit und die Flottenreichweite der eigenen Erholungslogik beherrschte.

Die breite Veränderungsgrenze war die Softwareeinführung von Mitte Dezember 1989. AT&T sagte, der Fehler sei mit einem Update in die 4ESS-Flotte gelangt, das den Zugriff auf ein Backup-Signalisierungsnetz beschleunigen sollte. Ein zeitgenössischer Telephony-Bericht, wiedergegeben in den vorliegenden RISKS-Archivquellen, spricht davon, dass der neue Code in Front-End-Prozessoren aller 114 4ESS-Systeme geladen worden sei. Daraus folgt ein Befund über gemeinsame Exposition, nicht über simultanes Versagen. Das Quellenpaket belegt nicht, dass alle 114 Systeme gleichzeitig ausfielen.

Es belegt auch nicht, dass alle Kunden oder Regionen dieselbe Ausfalltiefe erlebten. Belastbar ist die Aussage, dass eine gemeinsame Softwarebedingung breit genug ausgerollt war, um aus einem lokalen Erholungsereignis eine nationale Signalisierungsstörung werden zu lassen.

Gerade dieser Punkt macht den Vorfall bis heute instruktiv. Ein Update, das den Weg zu Backup-Signalisierung schneller machen sollte, wurde zur gemeinsamen Schwäche der Backup- und Erholungslogik. Der Kontrollfehler lag nicht darin, überhaupt Automatisierung oder Ersatzpfade zu besitzen. Er lag darin, dass die gleiche Änderung eine große Flotte mit derselben Zustandsbedingung verband. Backup-Pfade und duplizierte Prozessoren waren nur dann wirkliche Schutzschichten, wenn sie einen unabhängigen Fehlerbereich bildeten.

Im Januar 1990 war die Unabhängigkeit an der entscheidenden Stelle begrenzt: identischer Code, vergleichbarer Zustandsübergang, dieselben eintreffenden Signalisierungsnachrichten, dieselbe Notwendigkeit, Nachbarzustände schnell zu aktualisieren.

Ein Backup-Signalisierungsweg ist deshalb nicht schon unabhängig, weil er topologisch anders benannt oder in normalen Architekturzeichnungen getrennt dargestellt wird. Unabhängig ist er erst, wenn der Zugang zu ihm, die Steuerentscheidung über seine Nutzung, die Lastregelung, die Fehlererkennung und die Rücknahme nicht vom selben verletzlichen laufenden Code abhängen. Wenn die Softwareänderung, die den Zugriff auf den Backup-Weg beschleunigen soll, zugleich die gemeinsame empfindliche Bedingung einführt, dann sitzt der Ersatzpfad im selben Kontrollbereich wie der Primärpfad.

Er kann im Störungsfall sogar Teil der Last- und Erholungsdynamik werden, weil mehr Signalisierungsverkehr oder schnellerer Zugriff auf Ersatzwege die Prozessoren in genau den Moment bringt, in dem sie Status aktualisieren. Der Begriff Backup beschreibt dann eine Absicht, aber noch keine bewiesene Fehlertrennung.

AT&T berichtete, die Änderung sei in Laborumgebungen streng getestet worden und die exakte Kombination von Ereignissen sei nicht vorhergesehen worden. Auch hier muss die Analyse präzise bleiben. Eine solche Aussage entlastet die Ereignisrekonstruktion nicht von der Kontrollfrage. Sie verschiebt sie auf Testinhalt und Testtreue: Wurden Rückkehr-in-den-Dienst-Übergänge unter dichter IAM-Folge geprüft? Wurde das Zusammenspiel zweier DLN-Prozessoren als gekoppeltes Erholungssystem getestet? Wurde das Verhalten unter fortlaufender CCS7-Last untersucht, bei der Nachbarn gleichzeitig Anrufe aufbauen und Statuskarten aktualisieren?

Gab es eine gestufte Exposition mit Stoppkriterien, bevor die Änderung eine breite 4ESS-Flotte erreichte? Ohne solche Nachweise bleibt ein Testlabel weniger aussagekräftig als die beobachtete Laufzeitrealität.

Produktionsnahe Tests hätten besonders vier Eigenschaften abdecken müssen. Erstens die zeitliche Nähe gültiger IAMs während einer laufenden Statuskartenänderung, einschließlich wiederholter Paare und kurzer Bursts. Zweitens die Übernahme vom ersten DLN-Prozessor auf den Mate-Prozessor unter derselben eintreffenden Signalisierungslast. Drittens die Reaktion der Nachbarvermittlungen, wenn ein Knoten erst nicht verfügbar ist, dann kurz später wieder verfügbar erscheint und danach erneut isoliert wird.

Viertens die Flottenwirkung einer gemeinsamen Version, also die Frage, ob mehrere Vermittlungen mit identischem Code dieselbe Sequenz nicht nur einzeln, sondern als Netzverhalten reproduzieren. Der Testgegenstand ist damit kein einzelner Funktionsaufruf und kein einzelner Schalter. Der Testgegenstand ist ein Zustandsübergang im Netz.

Die Diagnose während des Vorfalls verlief nicht als sofortige, saubere Identifikation einer einzelnen Ursache. AT&T-Ingenieure versuchten zunächst Standardverfahren, erkannten dann, dass diese nicht ausreichten, werteten Fehlermeldungsmuster und Vermittlungsverhalten aus und zogen technische Unterstützung sowie Bell-Labs-Teams hinzu. Diese Abfolge ist wichtig, weil sie die Differenz zwischen Störungsbeseitigung und Rechenschaft zeigt. Ein Betreiber kann während eines laufenden Ausfalls improvisieren und zugleich später eine härtere Kontrollbilanz benötigen: Welche Signale waren sichtbar? Welche Zustände wurden zeitnah erkannt?

Welche Version lief auf welcher Vermittlung? Welche Handlung durfte Signalisierungsverkehr reduzieren, ohne die Diagnose zu zerstören? Welche Instanz konnte zur vorherigen Programmversion zurückkehren?

Die Stabilisierung erfolgte nach AT&Ts Darstellung durch eine temporäre Reduktion des Signalisierungsverkehrs auf Backup-Links. Das senkte die Nachrichtenlast für betroffene Prozessoren und half, die instabile Wiederholung zu brechen. Die letzte Verbindung wurde um 23:30 Uhr Eastern Standard Time freigemacht. Diese Maßnahme gehört zur Mitigation, nicht zur Ursache. Sie sagt nicht, dass Backup-Links die nationale Störung verursacht hätten. Sie zeigt vielmehr, dass die Betreiberseite den Signalisierungsdruck reduzieren musste, damit die Vermittlungen nicht immer wieder in denselben empfindlichen Erholungszustand gerieten.

Signalisierungsisolation ist in einem solchen Fall eine anspruchsvolle Kontrolle. Sie darf nicht nur bedeuten, dass ein Betreiber Nachrichten grob abschaltet und danach hofft, dass sich die Lage beruhigt. Sie muss in der Lage sein, Verdachtsverkehr zu dämpfen, Prozessorzustände zu beobachten, Rückkehrmeldungen zu unterscheiden und die Wiederfreigabe schrittweise zu messen. Wenn ein Backup-Link gedrosselt wird, muss klar bleiben, ob dadurch ein Trigger entfernt, eine Propagationsschleife gebrochen oder nur die Symptome überdeckt werden.

Isolation ohne Messung kann die Diagnose verschleiern; Messung ohne Isolationsmöglichkeit kann die Kaskade weiterlaufen lassen. Die operative Kunst liegt darin, beides zusammenzuführen: Nachrichtenlast begrenzen und zugleich genug Zustandssicht behalten, um den nächsten Schritt zu verantworten.

Am Dienstag nach dem Vorfall entfernte AT&T die fehlerhafte Änderung, kehrte vorübergehend zum vorherigen Programm zurück, reproduzierte das Problem im Labor, korrigierte die Schwäche und testete die Änderung, bevor Backup-Verbindungen wiederhergestellt wurden. Diese Abfolge ist der belastbare Rücknahmepfad im Quellenpaket.

Sie ist für Rechenschaft mindestens so wichtig wie die technische Einzelbedingung, weil sie zeigt, welche Kontrollen nach der Diagnose tatsächlich wirksam waren: Last reduzieren, gemeinsame Exposition zurücknehmen, Fehler unter kontrollierten Bedingungen reproduzieren, Korrektur prüfen und erst danach die zuvor gedämpften Signalisierungswege wieder freigeben.

Eine geübte Rücknahme setzt mehr voraus als die Existenz einer älteren Programmversion. Die Organisation muss wissen, welche Vermittlung welche Fassung ausführt, welche Systeme bereits auf die neue Logik angewiesen sind, welche Konfigurationsänderungen zusammen mit dem Programm ausgeliefert wurden und welche Seiteneffekte eine Rückkehr auslösen kann. Sie braucht außerdem Stoppbedingungen, die früher greifen als ein nationaler Ausfall: ungewöhnliche DLN-Neuinitialisierungen, wiederholte Rückkehrmeldungen, abweichende Linklast, ansteigende blockierte Verbindungsversuche oder zufällig wirkende regionale Muster nach einer gemeinsamen Änderung.

Ein Versions- und Zustandsinventar ist dabei keine Bürokratie. Es ist das Instrument, mit dem ein Betreiber erkennt, ob er ein lokales Ereignis oder eine Flottenexposition bearbeitet.

Der Kundeneffekt muss ebenfalls sauber getrennt werden. Zeitgenössische Berichte und AT&T-Angaben sprachen davon, dass während wesentlicher Teile der Störung ungefähr die Hälfte der versuchten Fernverbindungen scheiterte. UPI berichtete gesondert über eine Schätzung von 50 Millionen blockierten Anrufen und Auswirkungen auf 800-Nummern sowie Computerleitungen. Spätere Darstellungen nennen höhere Blockierungszahlen. Diese Angaben dürfen nicht zu einer einzigen präzisen Zahl verschmolzen werden.

Das Quellenpaket enthält keine unabhängig geprüfte Gesamtrechnung, keinen verifizierten Dollarverlust, keine vollständige Liste betroffener Kundengruppen und keine genaue Bilanz für Notfall-, Finanzmarkt- oder Datendienste. Die richtige Formulierung bleibt daher quellengebunden: etwa die Hälfte der Verbindungsversuche nach zeitgenössischer Beschreibung in relevanten Phasen, die 50-Millionen-Schätzung nach UPI, spätere höhere Narrative als spätere Narrative.

Diese Vorsicht ist keine Abschwächung. Sie ist Teil der Netzverantwortung. Ein nationaler Fernverkehrsausfall ist schwerwiegend genug, ohne dass ungesicherte Zahlen oder juristische Schlussfolgerungen hinzugefügt werden. Wer technische Rechenschaft ernst nimmt, trennt Messung, Schätzung und Erzählung. Die Hälfte der Anrufversuche ist eine andere Aussage als 50 Millionen blockierte Anrufe. Beide sind wiederum etwas anderes als ein finanzieller Schaden, den das vorliegende Paket nicht belegt. Ebenso ist ein Softwaredefekt etwas anderes als eine Normverletzung, Haftung oder individuelles Fehlverhalten.

Die Quellen tragen eine Kontrollanalyse, keine Anklageschrift.

Auch die Messgrenzen im Incident selbst müssen getrennt bleiben. Der Trigger ist das kleine New Yorker Hardwareproblem. Die latente Ursache der Kaskade ist die zeitabhängige Softwarebedingung in der DLN-Statusaktualisierung, soweit AT&T sie öffentlich beschrieb. Die Propagation ist das Wiederauftreten derselben Bedingung in Nachbarvermittlungen unter CCS7-Last. Die Recovery ist die betriebliche Stabilisierung durch Lastreduktion, Rücknahme, Laborreproduktion und Korrektur. Der Kundenimpact ist eine eigene Ebene mit unvollständigen, teils unterschiedlich berichteten Schätzungen.

Wenn ein Bericht diese Ebenen zusammenzieht, wirkt der Vorfall entweder simpler oder dramatischer, als die Evidenz trägt. Für einen Netzbetreiber ist aber gerade die Trennung wertvoll, weil jede Ebene andere Kontrollen verlangt.

Die zentrale Chronologie lässt sich deshalb in fünf getrennten Ebenen darstellen. Erstens der lokale Trigger: ein kleines Hardwareproblem in einer New Yorker 4ESS-Vermittlung. Zweitens der normale Erholungsablauf: vier bis sechs Sekunden Unterbrechung neuer Anrufannahme und Benachrichtigung benachbarter 4ESS-Systeme. Drittens die latente Softwarebedingung: eine Mitte Dezember eingeführte Änderung, die während einer DLN-Statuskartenaktualisierung auf zwei IAMs innerhalb eines Hundertstels einer Sekunde empfindlich reagieren konnte.

Viertens die Propagation: duplizierte Prozessoren und Nachbarvermittlungen verarbeiteten denselben Rückkehrzustand unter CCS7-Last und konnten sich wiederholt isolieren. Fünftens die Mitigation: AT&T reduzierte Backup-Signalisierungslast, rollte zurück, reproduzierte und korrigierte. Wenn diese Ebenen vermischt werden, verschwindet die eigentliche Lehre.

Diese Lehre lautet: Laufender Code ist die operative Wahrheit eines Netzes. Diagramme über Redundanz, Begriffe wie Backup oder allgemeine Aussagen über robuste Vermittlungsarchitektur genügen nicht, wenn die aktive Version, der Zustandsautomat und die Signalisierungsnachrichten im Fehlerfall gemeinsam dieselbe Schwäche ausführen. Die genaue, aktuelle Abbildung von Softwareversion, Prozessorzustand, Signalisierungsstatus, Nachbarverfügbarkeit und Freigabeentscheidung ist ein Kontrollinstrument.

Ohne sie weiß ein Betreiber nicht schnell genug, ob er einen lokalen Defekt, eine gemeinsame Flottenänderung, eine Lastbedingung, einen isolierbaren Link oder eine wiederholbare Erholungsreaktion sieht.

Betriebsnahe Zustandsübergangstests wären die erste präventive Schicht. Nicht nur der stabile Normalbetrieb muss getestet werden, sondern der Moment, in dem ein Nachbar nach kurzer Nichterreichbarkeit zurückkehrt. Die Tests müssen eng gepaarte IAMs, Wiederholungen, Bursts und Nachrichtensequenzen unter realistischer Signalisierungslast enthalten. Sie müssen den duplizierten DLN-Pfad als gekoppeltes System behandeln, nicht als zwei unabhängig bewertete Einzelprozessoren. Sie müssen nachweisen, dass eine Statuskarte während einer Aktualisierung konsistent bleibt oder kontrolliert scheitert.

Und sie müssen die Reaktion benachbarter Vermittlungen erfassen, weil in diesem Vorfall die Nachbarschaftsreaktion der Ausbreitungsweg war.

Solche Tests sollten außerdem Stop-and-resume-Zyklen enthalten, nicht nur Durchsatzläufe. Der kritische Moment war kein maximaler Dauerverkehr, sondern eine Rückkehr in den Dienst unter laufenden gültigen Nachrichten. Deshalb müsste ein Prüfszenario die Vermittlung wiederholt kurz aus der Signalisierungsbeziehung nehmen, Rückkehrmeldungen erzeugen, IAM-Paare in engen Abständen zuführen und beobachten, ob der Status konsistent bleibt. Der Test müsste auch zeigen, ob der Mate-Prozessor wirklich eine unabhängige Erholung bietet oder nur denselben Fehler mit kurzer Verzögerung übernimmt.

Erst wenn der Test diese Wechselwirkung zwischen Wiederanlauf, Nachbarstatus, IAM-Timing und Prozessorpaar sichtbar macht, nähert er sich der Laufzeitrealität des Vorfalls.

Die zweite Schicht ist gestufte Exposition. Eine gemeinsame 4ESS-Änderung, die den Zugriff auf Backup-Signalisierung beschleunigt, berührt eine nationale Steuerungsschicht. Eine solche Änderung sollte nicht nur funktional bestehen, sondern in einer begrenzten Flottenexposition messbare Stoppkriterien haben. Dazu gehören Fehlerhäufigkeit bei DLN-Neuinitialisierung, unerwartete Statuskartenänderungen, Häufung von Rückkehrmeldungen, Linklast auf Backup-Signalisierungswegen und Abweichungen im Verbindungsaufbau. Der Punkt ist nicht, aus heutiger Sicht eine konkrete damalige Rolloutregel zu behaupten.

Der Punkt ist, dass ohne dokumentierte Stufung und Versionsinventar die gemeinsame Schwäche erst sichtbar wird, wenn sie bereits breit läuft.

Ein gestufter Rollout hätte außerdem eine klare Versions- und Zustandskarte gebraucht. Welche 4ESS-Systeme führen die neue Version aus? Welche behalten die vorherige Fassung? Welche Systeme haben Backup-Signalisierungszugang unter der neuen Logik aktiviert? Welche Fehlerzähler ändern sich nach der Einführung? Welche Schwelle stoppt die weitere Ausbringung, und wer darf sie stoppen? Ohne diese Fragen wird ein großflächiger Softwarestand selbst zum blinden Fleck. Die Organisation sieht dann zwar einzelne Alarme, aber nicht sofort, dass dieselbe Änderung als gemeinsame Ursache über viele Vermittlungen hinweg plausibel ist.

Ein Inventar ist damit nicht nur für Abrechnung oder Wartung wichtig, sondern für die Fähigkeit, eine Kaskade früh als gemeinsame Exposition zu erkennen.

Die dritte Schicht ist Signalisierungsisolation. AT&Ts Stabilisierung durch das temporäre Senken der Backup-Link-Signalisierungslast zeigt, dass ein Betreiber in der Lage sein muss, Kontrollnachrichtenströme zu dämpfen oder zu isolieren, ohne das gesamte Lagebild zu verlieren. Ein gutes Kontrollsystem trennt dabei Ursache, Ausbreitung und Erholung. Es muss sagen können: Dieser Link ist gedämpft, dieser Prozessor initialisiert neu, diese Vermittlung ist aus CCS7-Sicht nicht verfügbar, diese Version verarbeitet den Rückkehrzustand, dieser Nachbar sendet gültige IAMs mit ungewöhnlich enger zeitlicher Nähe.

Nur dann ist Isolation ein gezielter Eingriff und nicht bloß eine grobe Abschaltung.

Die vierte Schicht ist Rücknahmefähigkeit. AT&T kehrte zum vorherigen Programm zurück. Das ist eine harte betriebliche Fähigkeit, keine Nebensache. Eine Rücknahme ist nur dann wirksam, wenn die vorherige Version verfügbar, mit der aktuellen Konfiguration kompatibel, auf der Flotte auffindbar und unter Krisenbedingungen freigabefähig ist. Für eine nationale Vermittlungsflotte bedeutet das: Versionsinventar, Signatur der laufenden Software, klare Autorisierung, geübtes Zurücksetzen, Beobachtung nach Rücknahme und eine Abgrenzung, ob Backup-Signalisierungswege sofort oder schrittweise wieder voll belastet werden dürfen.

Die fünfte Schicht ist unabhängige Nachprüfung. Das vorliegende Quellenpaket enthält AT&T-Angaben, zeitgenössische Presse, ein Telephony-Narrativ, ITU-Architekturkontext, NTIA- und GAO-Kontext sowie spätere wissenschaftliche Einordnungen. Es enthält aber nicht die vollständigen internen Logs. Eine belastbare Nachprüfung müsste die Zeitlinie pro Vermittlung, die Nachrichtenfolge, die Versionsstände, den Ursprung des Hardwaretriggers, die DLN-Zustände, die Entscheidungen zur Linklastreduktion, die Rücknahmezeiten und die Laborreproduktion trennen.

Unabhängigkeit bedeutet hier nicht Misstrauen als Haltung, sondern Nachvollziehbarkeit als Kontrolle: Ein Netz, auf das Öffentlichkeit, Unternehmen und kritische Dienste angewiesen sind, braucht überprüfbare Betriebswahrheit.

Solche unabhängige Evidenz müsste mehrere Zusagen prüfbar machen. Wenn ein Betreiber sagt, die Störung sei stabilisiert worden, sollten Linklast, Neuinitialisierungsrate und Verbindungsaufbauversuche vor und nach der Maßnahme getrennt sichtbar sein. Wenn er sagt, eine Softwareänderung sei entfernt worden, sollten Versionseinträge pro Vermittlung und Zeitstempel der Rücknahme vorliegen. Wenn er sagt, der Fehler sei im Labor reproduziert und korrigiert worden, sollten Testfall, Eingangssequenz, beobachteter Fehler und bestandener Gegenversuch unterscheidbar sein.

Wenn er sagt, der Kundenimpact habe eine bestimmte Größenordnung gehabt, sollten Messmethode, Zeitraum, Diensttyp und Schätzunsicherheit getrennt bleiben. Diese Evidenz würde nicht automatisch Schuld beweisen. Sie würde aber verhindern, dass Rechenschaft allein aus Erinnerung, Presseformeln oder zusammengezogenen Zahlen besteht.

Der Vorfall widerlegt auch einfache Redundanzsprache. Zwei Prozessoren sind nicht zwei Fehlerbereiche, wenn beide dieselbe verletzliche Logik zur selben Zeit in demselben Statusübergang ausführen. Ein Backup-Netz ist nicht unabhängig, wenn die Änderung, die es schneller erreichbar machen soll, die gemeinsame Schwäche trägt. Viele Vermittlungen sind keine robuste Vielfalt, wenn sie nahezu gleichartig versioniert und zeitgleich auf denselben Kontrollzustand empfindlich sind. Echte Resilienz entsteht erst, wenn Redundanz mit Unterschiedlichkeit, Isolation, beobachtbarer Zustandsführung und Rücknahme verbunden wird.

Für die öffentliche Kommunikation ergibt sich eine weitere Kontrollpflicht. Eine transparente Darstellung muss sagen, was als Auslöser bekannt ist, was als latenter Softwaredefekt beschrieben wurde, wie gültige Signalisierungsnachrichten die Schwäche berührten, welche Kaskadenlogik AT&T angab, welche Maßnahmen stabilisierten und welche Messgrenzen verbleiben. Sie darf aus einem kleinen Hardwareereignis keinen nationalen Hardwareausfall machen. Sie darf aus einer Softwarebedingung keinen Angriff machen. Sie darf aus Sekundärerzählungen keine freigelegte Quellcodewahrheit machen.

Und sie darf aus unterschiedlichen Impact-Schätzungen keine exakte, unprüfbare Schadenszahl formen.

Die Architekturquellen helfen, diese Kommunikation einzuordnen. Signalling System No. 7 trennt und verbindet Nutz- und Steuerungsebenen so, dass ein Fehler in Status-, Transfer- oder Verwaltungsfunktionen den Aufbau normaler Verbindungen massiv treffen kann. Die ITU-T-Empfehlungen liefern dafür Terminologie und Systemkontext. NTIA- und GAO-Quellen ordnen Telekommunikationsinfrastruktur, Zuverlässigkeit und öffentliche Abhängigkeit ein. Keine dieser Quellen beweist rückwirkend, dass AT&T gegen eine bestimmte Regel verstoßen habe.

Sie machen aber klar, warum die Steuerungsschicht eines Fernverkehrsnetzes als kritische Betriebsebene behandelt werden muss und warum deren Veränderung nicht wie eine isolierte Komfortfunktion bewertet werden darf.

Der 15. Januar 1990 bleibt deshalb ein Fall über Netzbetreiberkontrolle. Der damalige Betreiber war das historische American Telephone & Telegraph Company/AT&T-Fernverkehrsnetz; die heutige AT&T Inc. dient hier nur als Verzeichniszuordnung für die Entität. Die Verantwortungsebene im Ereignis liegt bei der Organisation, die damals 4ESS-Software, CCS7-Verhalten, Vermittlungsflotte, Backup-Signalisierung, Störungssteuerung und Rücknahmepfad kontrollierte. Das bedeutet nicht individuelle Schuld. Es bedeutet, dass der Ort der Kontrolle auch der Ort der nachträglichen Fragen ist: Wer wusste welche Version? Wer sah welchen Zustand?

Wer konnte welche Signalisierung isolieren? Wer autorisierte die Rücknahme? Welche Tests hätten den konkreten Übergang sichtbar gemacht?