DE602005000383T2

DE602005000383T2 - Fehlererkennung und -diagnose

Info

Publication number: DE602005000383T2
Application number: DE602005000383T
Authority: DE
Inventors: Lidong c/o Microsoft Corporation Zhou; Lili c/o Microsoft Corporation Qiu; Paramvir c/o Microsoft Corpoation Bahl; Ananth Rajagopala c/o Microsoft Corp Rao
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2004-01-30
Filing date: 2005-01-31
Publication date: 2007-04-26
Anticipated expiration: 2025-02-01
Also published as: ES2279479T3; CN1665205A; EP1560366A1; KR20060042903A; DE602005000383D1; CN1665205B; JP4786908B2; US20050169185A1; US7583587B2; ATE350832T1; JP2005223906A; EP1560366B1; DK1560366T3; KR101098744B1

Description

GEBIET DER TECHNIK
Die folgende Erfindung betrifft im Allgemeinen verdrahtete und drahtlose Netzwerke, und im Besonderen betrifft die Erfindung ein System zur Fehlersuche und -beseitigung zur Erfassung und Diagnose von Fehlern.
HINTERGRUND DER TECHNIK
Obgleich die Netzwerkverwaltung eine Schlüsselkomponente für eine erfolgreiche Anwendung eines drahtlosen Multi-Hop-Netzwerkes ist, wurde ihr sowohl seitens der Industrie als auch der Forschungsgemeinde nur in begrenztem Maße Beachtung geschenkt. Die Fehlersuche und -beseitigung in einem Netzwerk stellt einen Aspekt der Netzwerkverwaltung dar, der für das Aufrechterhalten der „Gesundheit" des Netzwerkes und für das Sicherstellen seines reibungslosen und fortlaufenden Betriebes verantwortlich ist. Die Fehlersuche und -beseitigung in einem Netzwerk wird, egal ob das Netzwerk verdrahtet oder drahtlos ist, durch Interaktionen erschwert, die zwischen den verschiedenen Einheiten, zwischen verschiedenen Fehlern und so weiter, auftreten.
Die Fehlersuche und -beseitigung in einem drahtlosen Multi-Hop-Netzwerk wird darüber hinaus noch durch eine Reihe verschiedener zusätzlicher Faktoren erschwert. So sind beispielsweise typische drahtlose Multi-Hop-Netzwerke im Allgemeinen anfällig für Verbindungsfehler, die durch Schwankungen der Signalausbreitung verursacht werden. Die Schwankungen der Signalausbreitung können durch eine Reihe verschiedener von Faktoren verursacht werden, so wie beispielsweise schwankende Umgebungsbedingungen. Diese Schwankungen führen zu einer Netzwerk-Topologie, die dynamisch und unvorhersagbar ist. Die Knotenmobilität verschärft diese Faktoren, da sich Knoten an ganz unterschiedlichen Positionen befinden können, während sie mit dem Netzwerk verbunden sind, wodurch der dynamische und unvorhersagbare Charakter des Netzwerkes noch verstärkt wird. Zusätzlich dazu, ist die Kapazität von drahtlosen Multi-Hop-Netzwerken im Allgemeinen aufgrund des Mangels an Ressourcen (beispielsweise Bandbreite, Batterieleistung, und so weiter) begrenzt, wodurch die Menge an Steuerungsaufwand für den Verwaltungsverkehr, die das Netzwerk tolerieren kann, beschränkt wird. Darüber hinaus kann ein drahtloses Netzwerk empfindlich gegenüber Linkattacken von böswilligen Parteien sein. So können die Angreifer beispielsweise fehlerhafte Informationen einspeisen, um die Bemühungen der Netzwerkverwaltung zu unterbrechen oder diese zu stören.
Herkömmliche heuristische und theoretische Verfahren, die herkömmlicherweise zum Durchführen der Fehlersuche und -beseitigung angewendet wurden, erfassen typischerweise nicht das Verhalten des Netzwerkes, so wie dies in einer „realen" Umgebung implementiert ist. So kann das Netzwerkverhalten beispielsweise durch Interaktionen zwischen den einzelnen Knoten beeinflusst werden, ebenso wie durch externes Rauschen, das in der Nähe der Knoten auftritt. Herkömmliche heuristische oder theoretische Verfahren gehen die Interaktionen zwischen den verschiedenen Komponenten des Netzwerkes mit seiner angrenzenden Umgebung nicht auf adäquate Weise an und erfassen dementsprechend das Verhalten eines solchen Netzwerkes nicht.
Dementsprechend besteht ein Bedarf an einem System für die Fehlersuche und -beseitigung in einem Netzwerk, das eine verbesserte Erfassung und Diagnose von Fehlern bereitstellt.
ZUSAMMENFASSUNG
Im Folgenden wird ein System zur Fehlersuche und -beseitigung beschrieben. Das System kann eine Simulation eines realen Netzwerkes zum Erfassen und Diagnostizieren von Fehlern in dem Betrieb des realen Netzwerkes verwenden. So kann eine Netzwerk-Simulation beispielsweise durch Daten gesteuert sein, die den Betrieb des realen Netzwerkes beschreiben. In der Praxis können unverarbeitete Daten, die für die Verwendung beim Steuern der Netzwerk-Simulation erfasst werden, aus unterschiedlichen Gründen Fehler enthalten, so wie beispielsweise aufgrund von Hardware-, Software und/oder Netzwerkfehlern. Um sicherzustellen, dass die zum Steuern der Netzwerk-Simulation verwendeten Daten konsistent sind, können die unverarbeiteten Daten gesäubert werden. So kann beispielsweise jeder Knoten in einem Netzwerk Daten für die Verwendung beim Steuern der Netzwerk-Simulation bereitstellen. Die durch einen bestimmten Kno ten bereitgestellten Daten können nicht nur den Betrieb dieses bestimmten Knotens sondern auch den Betrieb eines oder mehrerer benachbarter Knoten beschreiben. Aus diesem Grund können die von den Knoten in dem Netzwerk gewonnen Daten redundant sein. Anschließend werden die redundanten Daten miteinander verglichen, um irgendwelche Inkonsistenzen zu identifizieren, die anschließend auf verschiedenerlei Weise, wie beispielsweise durch Datenmittelung, Entfernung von inkonsistenten Daten und so weiter beseitigt werden.
Anschließend kann die Netzwerk-Simulation auf Basis dieser Daten die Netzwerkleistung schätzen. Die geschätzte Netzwerkleistung wird mit der beobachteten Netzwerkleistung der Leistung des realen Netzwerkes vergleichen, um zu erfassen, ob das reale Netzwerk die Leistung wie erwartet aufweist. Wenn dies nicht der Fall ist, wird ein Fehler in dem Betrieb des realen Netzwerkes erfasst. Mit anderen Worten bedeutet dies, dass eine Differenz zwischen der geschätzten Netzwerkleistung, wie diese durch die Netzwerk-Simulation angezeigt wird, und der beobachteten Netzwerkleistung, wie diese durch das reale Netzwerk angezeigt wird, zum Erfassen des Auftretens von Fehlern in dem realen Netzwerk verwendet werden kann. Die Netzwerk-Simulation kann anschließend für die Fehlerdiagnose durch selektives Einspeisen von einem oder mehreren Fehlern in die Netzwerk-Simulation so lange verwendet werden, bis sich die Netzwerkleistung der Netzwerk-Simulation der Netzwerkleistung des realen Netzwerkes nähert.
Wenn der eine oder die mehreren Fehler des Fehlersatzes, der in der angenäherten Netzwerkleistung resultiert, identifiziert sind, können eine oder mehreren Modifizierungen identifiziert und zum Korrigieren der Fehler implementiert werden. So kann die Netzwerk-Simulation beispielsweise anschließend dafür verwendet werden, eine Was-Wenn-Analyse so durchzuführen, dass die Modifizierungen in dem simulierten Netzwerk vorgenommen werden, um zu testen, ob durch die Modifizierungen die Fehler korrigiert werden und/oder in einer anderen Form die Netzwerkleistung verbessert wird. Auf diese Weise kann die Netzwerk-Simulation eine quantitative Rückmeldung zu der Auswirkung einer Reihe von Modifizierungen auf die Netzwerkleistung bereitstellen, die in dem Netzwerk durchgeführt werden, so wie beispielsweise Modifizierungen, die zum Korrigieren der Fehler und/oder zum Verbessern der Netzwerkleistung vorgenommen werden.
Das Dokument US-A-5 922 051 offenbart ein Computernetzwerk mit einer Vielzahl von Knoten, die mit ihm assoziiert sind, ein Datenverkehrsverwaltungssystem zum Verwalten des Datenverkehrs zwischen der Vielzahl von Knoten, das 1) eine Abfrageschaltung, die Informationen über den Verkehr zwischen den Knoten von der Vielzahl von Knoten abruft; und 2) eine Prozesslogik umfasst, die zuerst ausgewählte Informationen zum Knotenverkehr, welche mit einem ersten ausgewählten der Vielzahl von Knoten assoziiert sind, mit einem Schwellenwert vergleicht, um einen Trend in den zuerst ausgewählten Informationen zum Knotenverkehr in Bezug auf den ersten Schwellenwert zu erfassen.
Aus dem Dokument US 2003/0093709 A1 ist ein System zum Unterstützen der Fehlersuche und -beseitigung in einem Netzwerk bekannt, das Folgendes umfasst: eine Speichereinrichtung zum periodischen Speichern von Einstellungs-/Konfigurationsdaten und Leistungsdaten der Geräte, die das Netzwerk bilden, auf Basis eines Schemas aus Geräte-IDs, Schnittstellen-IDs und einer jeweiligen CONFIG-Versionszahl, eine Überwachungseinrichtung zum Überwachen der Leistungsdaten der Geräte durch Vergleichen der Leistungsdaten mit jeweiligen Schwellenwerten; eine Identifiziereinrichtung zum Identifizieren des fehlerhaften Gerätes auf Basis des Schemas, wenn die Leistungsdaten von wenigstens einem Gerät nicht innerhalb eines bestimmten Schwellenwertes liegen, wobei die Speichereinrichtung darüber hinaus das identifizierte Ergebnis für die Fehlersuche und -beseitigung des Netzwerkes speichert. Auf diese Weise kann das System einen Änderungsfaktor der Betriebsbedingung des Netzwerksystems schätzen und entsprechend Korrekturen vornehmen.
Es ist die Aufgabe der vorliegenden Erfindung, ein verbessertes Verfahren und System bereitzustellen, das ein System zur Fehlersuche und -beseitigung zum Erfassen und Diagnostizieren von Fehlern in dem Netzwerk umfasst.
Diese Aufgabe wird durch den Gegenstand der unabhängigen Ansprüche 1, 11 und 22 erfüllt.
Im Folgenden werden bevorzugte Ausführungsbeispiele ausführlicher im Zusammenhang mit den beigefügten Zeichnungen beschrieben.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist eine Darstellung einer Umgebung in einer exemplarischen Implementierung, die ein Netzwerk mit einer Vielzahl von Knoten darstellt.
2 ist eine Darstellung einer exemplarischen Implementierung, die ein in 1 dargestelltes Analyse-Modul auf ausführlichere Weise zeigt.
3 ist eine Darstellung eines Netzwerkes mit einer Sieben-mal-Drei-Topologie.
4 ist eine Darstellung einer exemplarischen Implementierung, die ein System zeigt, das einen Simulator und eine in 2 dargestellte Netzwerk-Simulation umfasst.
5 ist ein Ablaufplan, der eine Vorgehensweise in einer exemplarischen Implementierung darstellt, in der die Fehler, die demselben Typ entsprechen, einer Anfangsdiagnose unterzogen werden.
6 ist eine Darstellung eines Entscheidungsbaumes in einer exemplarischen Implementierung, die dazu verwendet werden kann, um auf Basis einer Differenz zwischen der geschätzten und der beobachteten Leistung, einen Fehlertyp zu bestimmen.
7 ist ein Ablaufplan, der eine Vorgehensweise in einer exemplarischen Implementierung darstellt, bei der Fehler unterschiedlicher Typen unter Verwendung eines iterativen Diagnostikalgorithmus diagnostiziert werden.
8 ist eine Darstellung eines Netzwerkes in einer exemplarischen Implementierung, in der die Vielzahl von in 1 dargestellten Knoten Agenten-Module umfassen, die so ausgeführt werden können, dass sie Überwachung benachbarter Knoten durchführen.
9 ist ein Ablaufdiagramm, das eine Vorgehensweise in einer exemplarischen Implementierung darstellt, in der Mitteilungen, die benachbarte Knoten beschreiben, verglichen werden, um sich fehlerhaft verhaltende Knoten zu lokalisieren.
10 ist ein Ablaufplan, der eine Vorgehensweise in einer exemplarischen Implementierung darstellt, bei der eine Was-Wenn-Analyse auf Basis einer tracegesteuerten Online-Simulation durchgeführt wird.
11 ist ein Ablaufdiagramm, das eine Vorgehensweise in einer exemplarischen Implementierung darstellt, bei der Modifizierungen in einem Netzwerk auf Basis einer Diagnose eines schadhaften Flusses hergeleitet werden.
12 ist eine Darstellung eines Netzwerkes, das eine Vielzahl von Abläufen enthält, von denen einer ein schadhafter Fluss ist.
13 ist eine Darstellung einer exemplarischen Implementierung, die eine durch einen Manager-Knoten bereitgestellte grafische Benutzerschnittstelle (GUI) zeigt, die es einem Systemverwalter ermöglicht, ein Netzwerk zu visualisieren und Verwaltungsanforderungen an das Netzwerk auszugeben.
In der gesamten Offenbarung und den Figuren werden die gleichen Nummern für die Bezeichnung von ähnlichen Komponenten und Leistungsmerkmalen verwendet.
AUSFÜHRLICHE BESCHREIBUNG
Überblick
Im Folgenden wird ein System zur Fehlersuche und -beseitigung für die Verwendung in verdrahteten und/oder drahtlosen Netzwerken zum Aufrechterhalten eines effizienten und zuverlässigen Netzwerkbetriebes beschrieben. Das hierein beschriebene System kann eine tracegesteuerte Online-Netzwerk-Simulation umfassen, um Fehler zu erfassen und eine Analyse der Hauptursachen der Fehler durchzuführen. Die Netzwerk-Simulation ist in dem Sinne „Online", dass sie Netzwerkleistungsdaten von einem „realen" Netzwerk gewinnen kann.
Das System kann zum Diagnostizieren einer großen Bandbreite von Leistungsproblemen (das heißt, Fehlern), so wie beispielsweise Fehlern, die durch Packet-Dropping, Verbindungsüberlastung, fehlerhaftem Verhalten der Medium Access Control (MAC), ex ternem Rauschen und so weiter, verursacht werden, angewendet werden. Das System kann auch zum Bewerten von alternativen Netzwerkkonfigurationen zum Verbessern der Netzwerkleistung verwendet werden. Obgleich die folgende Diskussion ein System in einem exemplarischen drahtlosen Netzwerk beschreibt, kann das System auch in verdrahteten Netzwerken verwendet werden.
Exemplarische Umgebung
Wie vorangehend beschrieben, hat das Thema der Netzwerkverwaltung sowohl seitens der Industrie als auch der Forschungsgemeinde nur begrenzt Beachtung erfahren. Die Implementierung von Netzwerkverwaltung kann das ständige Überwachen der Funktionsweise des Netzwerkes, das Erfassen von Informationen über Knoten und Verbindungen in dem Netzwerk, das Entfernen von Inkonsistenzen und Rauschen aus den mitgeteilten Daten, die Analyse der Daten und das Durchführen der geeigneten Maßnahmen zum Verbessern der Netzwerkverlässlichkeit und der Netzwerkleistung umfassen.
Die Fehlersuche und -beseitigung in einem Netzwerk stellt einen Aspekt der Netzwerkverwaltung dar, der für das Aufrechterhalten der „Gesundheit" des Netzwerkes und für das Sicherstellen seines reibungslosen und fortlaufenden Betriebes verantwortlich ist. Die Fehlersuche und -beseitigung in einem Netzwerk, egal ob dieses verdrahtet oder drahtlos ist, kann durch verschiedene Interaktionen, so wie beispielsweise Interaktionen, die zwischen den verschiedenen Netzwerkeinheiten, Interaktionen zwischen Fehlern und so weiter auftreten, verkompliziert werden. Die Fehlersuche und -beseitigung in einem drahtlosen Multi-Hop-Netzwerk wird durch eine Reihe zusätzlicher Faktoren noch weiter erschwert. So sind typische Multi-Hop-Netzwerke im Allgemeinen empfindlich gegenüber von Verbindungsfehlern, die durch Schwankungen der Signalausbreitung verursacht werden, die in einer Netzwerk-Topologie resultieren, die dynamisch und unvorhersagbar ist. Darüber hinaus ist die Kapazität von drahtlosen Multi-Hop-Netzwerken im Allgemeinen durch den Mangel an Ressourcen (beispielsweise Bandbreite, Batterieleistung, und so weiter) begrenzt, wodurch die Menge an Steuerungsaufwand für den Verwaltungsverkehr, die das Netzwerk tolerieren kann, beschränkt wird.
Im Folgenden wird ein System beschrieben, das diese Komplikationen zu überwinden versucht. Das System kann eine tracegesteuerte Online-Simulation zum Erfassen von Fehlern und zum Durchführen der Analyse der Hauptursachen verwenden. Die Simulation kann dazu verwendet werden, um Ereignisse, die in dem Netzwerk stattgefunden haben und die in einem Fehler resultierten, zu reproduzieren und dementsprechend diese Fehler zu identifizieren und zu beseitigen.
1 ist eine Darstellung einer Umgebung in einer exemplarischen Implementierung, die ein Netzwerk 100 mit einer Vielzahl von Knoten 102(1), 102(2), 102(3), ..., 102(n), ..., 102(N) zeigt. Die Vielzahl der Knoten 102(1) bis 102(N) aus 1 implementiert ein exemplarisches System, das eine Simulation des Netzwerkes 100 für die Erfassung und Diagnose von Fehlern sowie für die Was-Wenn-Analyse verwendet. Dieses Netzwerk besitzt verschiedene vorteilhafte Eigenschaften. Erstens, ist das Netzwerk flexibel. Da eine Simulation in hohem Maße an Kundenanforderungen anpassbar ist und auf eine große Klasse von Netzwerken in verschiedenen Umgebungen angewendet werden kann, kann die Fehlerdiagnose, die auf dem Simulator installiert wird, so konfiguriert sein, dass sie diese Flexibilität übernimmt. Zweitens, können durch eine Simulation eine Reihe verschiedener komplizierter Interaktionen erfasst werden. So können beispielsweise Interaktionen innerhalb des Netzwerkes, zwischen dem Netzwerk und der Umgebung, ebenso wie zwischen unterschiedlichen Fehlern, die während des Betriebes des Netzwerkes auftreten, erfasst werden. Aus diesem Grund gewährleistet das System durch die Verwendung der Simulation eine systematische Diagnose einer großen Bandbreite von Fehlern einschließlich Kombinationen davon. Drittens, ist das System in der Hinsicht erweiterbar, dass die Fähigkeit des Erfassens neuer Fehler in das System integriert werden kann, indem die Fehler in der Simulation unabhängig von den anderen Fehlern in dem System modelliert werden. Die Interaktionen zwischen den neuen Fehlern und bereits existierenden Fehlern, die in dem System modelliert werden, wird implizit durch das Ausführen der Simulation erfasst. Viertens, erleichtert das Reproduzieren des Netzwerkes innerhalb eines Simulators die Was-Wenn-Analyse, die eine quantitative Rückmeldung zu der Auswirkung der in dem Netzwerk vorgenommenen Modifizierungen auf die Netzwerkleistung, bereitstellt. So können beispielsweise Korrekturvorgänge zum Korrigieren eines Fehlers in dem Betrieb des Netzwerkes vorgenommen werden, es kann eine Modifizierung zum Erhöhen der Leistung des Netzwerkes vorgenommen werden, und so weiter.
Das System kann einen oder mehrere einer Reihe verschiedener Simulatoren zum Simulieren des Netzwerkes 100, so wie beispielsweise QUALNET (QUALNET ist eine Marke von Scalable Network Technologies, Inc. of Los Angeles, Kalifornien), OPNET MODELER (OPNET MODELER ist eine Marke von OPNET Technologies, Inc. of Washington D.C.) und so weiter verwenden. Die Traces, die den Simulatoren bereitgestellt werden, werden von dem Netzwerk, das diagnostiziert wird, das heißt, von einem „realen" Netzwerk, gewonnen. Durch das Verwenden von Traces von dem realen Netzwerk besteht nicht mehr die Abhängigkeit des Systems von generischen Theoriemodellen, die die Nuancen der Hardware, der Software und der Umgebung des bestimmten betreffenden Netzwerkes eventuell nicht erfassen können, wodurch die Genauigkeit des Systems verbessert wird.
Darüber hinaus kann das System auch ein Fehlerdiagnose-Schema zum Durchführen der Analyse der Hauptursache anwenden. So kann das Schema beispielsweise Daten zur geschätzten Netzwerkleistung, die durch den tracegesteuerten Online-Simulator ausgegeben werden, als die Bezugslinie für die erwartete Leistung des realen Netzwerkes verwenden. Anschließend wird eine Abweichung von der erwarteten Leistung zum Anzeigen eines möglichen Fehlers verwendet. Darüber hinaus kann das Schema selektiv einen Satz von in Frage kommenden Fehlern in einen Simulator einspeisen, um die Analyse der Hauptursachen durch Reduzieren der Fehlerdiagnose auf ein Problem des Suchens eines Fehlersatzes durchzuführen. Eine Hauptursache kann dementsprechend auf Basis der Fehler identifiziert werden, die, wenn sie eingespeist werden, eine Simulation dazu veranlassen, sich der beobachteten Leistung des realen Netzwerkes zu nähern. Dementsprechend kann das System einen Suchalgorithmus zum Erfassen und Diagnostizieren von Fehlern wie beispielsweise Packet-Dropping, Verbindungsüberlastung, externem Rauschen, fehlerhaftem Verhalten der Medium Access Control (MAC), und so weiter verwenden. Diese Fehler können eine relativ lang andauernde Auswirkung auf die Leistung haben, und sind schwieriger zu erfassen als Fail-Stop-Fehler, wie zum Beispiel die, die auftreten, wenn ein Knoten sich selbst aufgrund eines Strom- oder Batterieausfalls abschaltet.
Auf diese Weise kann das System eine Simulation als ein analytisches Tool zur Fehlersuche und -beseitigung und zum Testen von alternativen und möglicherweise leistungsverbessernden Konfigurationen in einem Netzwerk verwenden. In den folgenden Ab schnitten werden Netzwerktraces identifiziert, die, wenn sie einem Simulator bereitgestellt werden, eine Netzwerk-Simulation gewährleisten, die eine genaue Abbildung des tatsächlichen Netzwerkverhaltens erzeugt. Es wird des Weiteren ein Verfahren beschrieben, das fehlerhafte Daten aus dem Trace reduziert oder aus ihm entfernt, eine nähere Diskussion dazu wird in Bezug auf die 8 und 9 gegeben. Demzufolge werden dem Simulator Daten einer hohen Qualität bereitgestellt. Darüber hinaus wird ein Suchalgorithmus beschrieben, der zum Diagnostizieren mehrerer Fehler in dem Netzwerk auf effektive Weise eingesetzt wird, eine nähere Diskussion dazu wird in Bezug auf 7 gegeben. Darüber hinaus kann der Simulator auch zum Durchführen der Was-Wenn-Analyse und zum Quantifizieren der Vorteile möglicher Maßnahmen für die Leistung des aktuellen Netzwerkes verwendet werden, eine nähere Diskussion dazu wird in Bezug auf die 10 bis 13 gegeben.
Das System zur Fehlersuche und -beseitigung kann ein einer großen Bandbreite von Netzwerkkonfigurationen verwendet werden. Ein solches Beispiel ist durch das Netzwerk 100 in 1 illustriert, das als ein drahtloses Maschen-Netzwerk dargestellt ist. Ein Maschen-Netzwerk kann eine Reihe verschiedener Anordnungen aufweisen, so wie beispielsweise eine Topologie ganzer Maschen oder eine Topologie partieller Maschen. In einer Topologie ganzer Maschen ist jeder Knoten direkt mit jedem anderen Knoten in dem Netzwerk verbunden. In einer Topologie partieller Maschen ist jeder Knoten mit wenigstens einem anderen Knoten aber nicht notwendigerweise mit jedem anderen Knoten in dem Netzwerk verbunden.
So kann ein Maschen-Netzwerk beispielsweise als eine Befähigungstechnologie dazu dienen, dass Nachbarn gemeinsam ein drahtloses Maschen-Netzwerk einer sich selbst verwaltenden Community bilden. Jeder Nachbar kann einen oder mehrere der Vielzahl von Knoten 102(1) bis 102(N) des Netzwerkes 100 bereitstellen. Mit einem solchen Netzwerk können Nachbarn beispielsweise ein Internet-Gateway 104 auf kosteneffektive Weise gemeinsam nutzen.
In einem Beispiel eines Maschen-Netzwerkes, das in einer Nachbarschaft verwendet wird, sind Router (Leitwegsucher), die verwendet werden, um die Vielzahl von Knoten 102(1) bis 102(N) kommunikativ zu verbinden, in einem Haushalt installiert und in Steckdosen eingesteckt. Dementsprechend hat ein jeder Router in diesem Beispiel eine eingeschränkte Mobilität. Die relative Stabilität eines solchen Netzwerks macht die Fehlersuche und -beseitigung für das Netzwerk jedoch noch wichtiger, da Fehler eine lang andauernde Auswirkung auf die Netzwerkleistung ausüben können. Hierbei sollte beachtet werden, dass der Fehler der Routermobilität in diesem Beispiel nichts von der Dynamik in der Netzwerk-Topologie wegnimmt, da drahtlose Verbindungen aufgrund von Änderungen in der Umgebung zugreifbar oder nicht zugreifbar sein können. In einem weiteren Beispiel können die Knoten eines Maschen-Netzwerkes mobil sein, so beispielsweise durch die Verwendung von mobilen Rechengeräten, die die Fähigkeit zur drahtlosen Kommunikation besitzen, so wie beispielsweise Personal Digital Assistants (PDAs), Tablett-Personalcomputer (PCs), Laptopcomputer und so weiter.
Darüber hinaus ist das Wachstum eines Community-Maschen-Netzwerkes organisch, da die Benutzer Ausrüstung kaufen und diese dann installieren, um sich dem Maschen-Netzwerk anzuschließen. Herkömmlichen Maschen-Netzwerken fehlte es an einer zentralisierten Einheit, die für die Systemverwaltung verantwortlich ist. Dennoch können die Fähigkeiten zur Selbstverwaltung und zur Selbstheilung, die durch das hierin beschriebene System gewährleistet werden, so bereitgestellt werden, dass ein jeder Knoten 102(1) bis 102(N) Fähigkeiten zur Fehlersuche und -beseitigung implementiert. In der dargestellten Implementierung wird ein einziger Knoten bereitgestellt, der Verwaltungsfähigkeiten besitzt.
In dem in 1 dargestellten Netzwerk 100 hat jeder der Knoten einen Prozessor, einen Speicher und ein Netzwerkverbindungsgerät, von dem ein Beispiel durch den Knoten 102(n) dargestellt ist, der einen Prozessor 106(n), einen Speicher 108(n) und ein Netzwerkverbindungsgerät 110(n) enthält. Die Prozessoren (beispielsweise die Prozessoren 106(n), 106(N)) sind nicht auf die Materialien, aus denen sie gebildet sind, oder die Verarbeitungsmechanismen beschränkt, die in ihnen durchgeführt werden. So können die Prozessoren beispielsweise aus Halbleitern und/oder Transistoren (beispielsweise elektronische integrierte Schaltungen (ICs)) gebildet sein. In solch einem Kontext können durch Prozessoren ausführbare Befehle elektronisch ausführbare Befehle sein. Alternativ dazu können die Mechanismen der oder für die Prozessoren und demzufolge die Mechanismen eines oder für einen Knoten Quantenberechnung, optische Berechnung, mechanische Berechnung (beispielsweise unter Verwendung von Nanotechnolo gie) und so weiter umfassen, wobei die Mechanismen nicht auf diese Genannten beschränkt sind.
Der Speicher (beispielsweise Speicher 108(n), 108(N)) enthält ein Computerspeichermedium in der Form eines flüchtigen und/oder nicht-flüchtigen Speichers, wie beispielsweise einen Nur-Lesespeicher (ROM), einen Schreib-/Lesespeicher (RAM), und so weiter. Der Speicher kann des Weiteren auch entnehmbare/nicht-entnehmbare, flüchtige/nicht-flüchtige Computerspeichermedien umfassen. Der Speicher gewährleistet das Speichern von computerlesbaren Anweisungen, Datenstrukturen, Softwarekomponenten und/oder anderen Daten für Knoten.
Die Netzwerkverbindungsgeräte (beispielsweise die Netzwerkverbindungsgeräte 110(n), 110(N)) können eine Reihe verschiedener Konfigurationen für das kommunikative Verbinden der Knoten mit dem Netzwerk 100 umfassen. Wenn der Knoten beispielsweise in einer Umgebung eines lokalen Netzes (LAN) verwendet wird, ist der Knoten 102(n) kommunikativ mit dem LAN über eine Netzwerkschnittstelle oder einen Adapter verbunden, die verdrahtet oder drahtlos sein können. Wenn der Knoten in einer Umgebung eines Großraumnetzwerkes (WAN) verwendet wird, kann das Netzwerkverbindungsgerät als ein Modem oder als eine andere Einrichtung zum Herstellen von Verbindungen, so wie beispielsweise eine verdrahtete Verbindung über eine digitale Subskribenden-Leitung (DSL), eine drahtlose durch einen Satelliten bereitgestellte Verbindung und so weiter konfiguriert sein. In 1 werden logische Verbindungen durch die Verwendung von Pfeilen dargestellt. Obgleich es sich bei dem in 1 dargestellten Netzwerk 100 um ein drahtloses Maschen-Netzwerk handelt, können eine Reihe verschiedener anderer Netzwerke, so wie beispielsweise das Internet, Intranets und so weiter verwendet werden.
Die Knoten 102(n), 102(N) illustrieren eine exemplarische Verwaltungs-Architektur, die aus Software-Modulen besteht. Im Allgemeinen können jegliche der hierin beschriebenen Funktionen unter Verwendung von Software, Firmware (beispielsweise eine eingebaute Logikschaltung), manueller Verarbeitung oder einer Kombination aus diesen Implementierungen ausgeführt werden. Die Begriffe „Modul", „Funktionalität" und „Logik", so wie diese hierin verwendet werden, repräsentieren im Allgemeinen Software, Firmware oder eine Kombination aus Software und Firmware. In dem Fall einer Software- Implementierung repräsentieren Modul, Funktionalität oder Logik einen Programmcode, der spezifische Aufgaben ausführt, wenn er auf einem Prozessor, so wie beispielsweise auf einem oder mehreren zentralen Recheneinheiten (CPUs) ausgeführt ist. Der Programmcode kann in einem oder mehreren computerlesbaren Speichervorrichtungen gespeichert sein. Die Leistungsmerkmale des im Folgenden beschriebenen Systems sind plattformunabhängig, was bedeutet, dass die Verfahren zur Fehlersuche und -beseitigung auf einer Vielzahl von kommerziell erhältlichen Rechenplattformen, die eine Reihe von Prozessoren haben, implementiert werden können.
Ein Agenten-Modul 112(n) wird für die Ausführung auf einem jeden Knoten 102(n) des Netzwerkes 100 bereitgestellt. Das Agenten-Modul 112(n) ist so dargestellt, dass es auf dem Prozessor 106(n) ausgeführt und in dem Speicher 108(n) speicherbar ist. Das Agenten-Modul 112(n) umfasst ein Datenertassungs-Modul 114(n) (im Folgenden als „Erfassungs-Modul" bezeichnet), das, wenn es ausgeführt ist, Daten von verschiedenen Protokollschichten und/oder von dem Netzwerkverbindungsgerät 110(n) erfassen kann. In dem in 1 dargestellten Netzwerk 100 teilt das Agenten-Modul 112(n) anschließend diese Daten dem Knoten 102(N) mit, der Verwaltungsfunktionen besitzt und der im Folgenden als Manager-Knoten bezeichnet wird. Der Manager-Knoten 102(N) führt eine Analyse der Daten (beispielsweise durch Implementierung einer Simulation, die die Daten als Eingabe akzeptiert) durch und unternimmt geeignete Maßnahmen zur Fehlersuche und -beseitigung im Netzwerk. Die Verwaltung des Netzwerkes kann zentralisiert werden, indem der Manager auf einem einzigen Knoten platziert wird, so wie dies in dem in 1 dargestellten Netzwerk der Fall ist, oder die Verwaltung kann aufgeteilt so angeordnet sein, dass eine Vielzahl der Knoten eines Netzwerkes jeweils Verwaltungsfunktionen enthält.
Die Agenten-Module 112(n), 112(N), wenn diese auf den jeweiligen Prozessoren 106(n), 106(N) ausgeführt sind, erfassen und kommunizieren Daten, die ihre (lokale) Darstellung zu dem Verhalten des Netzwerkes beschreiben, zu dem Manager-Knoten 102(N). Beispiele der gesendeten Daten können beispielsweise Verkehrsstatistiken, Signalstärke der empfangenen Pakete auf verschiedenen Verbindungen, Zählungen von erneuten Übertragungen auf einer jeden Verbindung und so weiter umfassen.
Der Manager-Knoten 102(N) enthält ein Manager-Modul 116(N), das in dem Speicher 108(N) gespeichert und auf dem Prozessor 106(N) ausgeführt werden kann, zum Verarbeiten der Daten von den Agenten 112(n), 112(N) für die Fehlersuche und -beseitigung in dem Netzwerk 100. Das Manager-Modul 116(N) enthält beispielsweise einen Netzwerk-Simulator 118(N) (im Folgenden als „Simulator" bezeichnet), der auf dem Prozessor 106(N) ausgeführt und in dem Speicher 108(N) gespeichert werden kann, zum Simulieren des Netzwerkes 100.
Die durch den Manager-Knoten 102(N) von den verschiedenen Agenten-Modulen 112(n), 112(N) empfangenen Daten können zu einer inkonsistenten Darstellung des Netzwerkes 100 führen. Solche Inkonsistenzen können das Ergebnis von Änderungen in der Topologie und in der Umgebung, Messfehlern, sich fehlerhaft verhaltenden Knoten, und so weiter sein. Aus diesem Grund enthält der Manager-Knoten 102(N) ein Datensäuberungs-Modul 120(N) (im Folgenden als „Säuberungs-Modul" bezeichnet), das auf dem Prozessor 106(N) ausgeführt werden kann, um solche Inkonsistenzen aufzuheben. Die gesäuberten Daten, die von dem Säuberungs-Modul 120(N) ausgegeben werden, werden anschließend für das Verarbeiten durch ein Hauptursachen-Analyse-Modul 122(N) (im Folgenden als „Analyse-Modul" bezeichnet) bereitgestellt, eine weitere Diskussion dazu wird in Bezug auf die folgende Figur angeführt. Obgleich der Manager-Knoten 102(N) so dargestellt ist, dass er das Agenten-Modul 112(N) und das Manager-Modul 116(N) enthält, ist der Manager-Knoten 102(N) in einer anderen Implementierung ein dedizierter Manager-Knoten in der Hinsicht, dass er das Agenten-Modul 112(N) nicht enthält. Darüber hinaus kann, wie dies voranstehend bereits beschrieben wurde, die Funktionalität des Manager-Moduls 116(N) durch mehr als einen Knoten in dem Netzwerk 100 gewährleistet sein.
2 ist eine Darstellung einer exemplarischen Implementierung 200, die das in 1 dargestellte Analyse-Modul 122(N) auf ausführlichere Weise darstellt. Wenn die in den Daten vorhandenen Inkonsistenzen durch das in 1 dargestellte Säuberungs-Modul 120(N) behoben sind, werden die gesäuberten Daten für weitere Untersuchungen in das Analyse-Modul 122(N) eingespeist.
Das Analyse-Modul 122(N) verwendet eine tracegesteuerte Online-Simulation zum Feststellen von Hauptursachen von Unstimmigkeiten anhand der erwarteten Netzwerk leistung, so wie dies durch die simulierte Netzwerkleistung angezeigt wird. In der folgenden Diskussion werden die „erwartete Netzwerkleistung" und die „simulierte Netzwerkleistung" untereinander austauschbar verwendet, um die Netzwerkleistung anzuzeigen, so wie diese durch eine Netzwerk-Simulation bereitgestellt wird. Das Analyse-Modul 122(N) kann zum Steuern der Online-Simulation und zum Festlegen der erwarteten Leistung mit den gegebenen Netzwerkkonfigurationen und Verkehrsmustern gesäuberte Daten 202 verwenden, die von einer Trace-Einrichtung gewonnen wurden, Beispiele solcher Daten sind in 2 als Empfangssignalstärke (RSS) der Verbindung 204, Verbindungsposition 206 und Routing-Aktualisierung 208 dargestellt.
Das Analyse-Modul 122(N) ist so dargestellt, dass es eine Netzwerk-Simulation 210 enthält, die durch das Ausführen des Simulators 118(N) bereitgestellt wird. Die Netzwerk-Simulation 210 kann durch das Ausführen von einem oder mehreren Software-Modulen bereitgestellt werden, die Simulationen von Eigenschaften eines Netzwerkes durchführen, von denen Beispiele in 2 durch ein Interterenzeinspeisungs-Modul 212, ein Verkehrssimulator-Modul 214 und ein Topologieänderungs-Modul 216 dargestellt sind. Das Interferenzeinspeisungs-Modul 212 kann ausgeführt werden, um Quellen von externem Rauschen durch das Einspeisen des Effektes von externem Rauschen in die Netzwerk-Simulation 210 zu simulieren. Das Verkehrssimulator-Modul 214 kann ausgeführt werden, um sicherzustellen, dass sich der Verkehr der Netzwerk-Simulation 210 dem Verkehr des realen Netzwerkes nähert. Das Topologieänderungs-Modul 216 kann ausgeführt werden, um Änderungen in der Topologie zu simulieren, so beispielsweise durch Hinzufügen und/oder Entfernen von Knoten in der Netzwerk-Simulation 210.
Das Analyse-Modul 122(N) erfasst Fehler in dem in 1 dargestellten Netzwerk 100 durch Vergleichen der erwarteten Leistung, wie diese durch die Netzwerk-Simulation 210 angezeigt wird, mit der beobachteten Leistung. Wenn Unstimmigkeiten beobachtet werden, stellt das Analyse-Modul 122(N) die Hauptursache für die Unstimmigkeit durch Suchen nach einem oder mehreren Fehlern fest, die in einem Fehlerverzeichnis 218 gespeichert sind, und die in der besten Übereinstimmung zwischen der simulierten und der beobachteten Netzwerkleistung resultieren.
Das Analyse-Modul 122(N) kann beispielsweise beobachtete Daten 220 von einem oder mehreren der in 1 dargestellten Agenten-Module 112(n) empfangen, die eine Verlustrate, eine Durchflussleistung und Rauschen 220 beschreiben, die in 2 als „Verlustrate, Durchflussleistung und Rauschen 220" dargestellt sind. Die Netzwerk-Simulation 210 berechnet erwartete Daten 222, die eine erwartete Verlustrate, eine erwartete Durchflussleistung und ein erwartetes Rauschen beschreiben, und die in 2 als „erwartete Verlustrate, Durchflussleistung und Rauschen 222" dargestellt sind. Die beobachteten Daten 220 werden über eine Verzögerungsschaltung 224 so zu einer Vergleichseinrichtung 226 kommuniziert, dass die Vergleichseinrichtung 226 die beobachteten und die erwarteten Daten 220, 222 gleichzeitig empfängt. Anschließend stellt die Vergleichseinrichtung 226 fest, ob die beobachteten Daten 220 die erwarteten Daten 222 überschreiten. Wenn dies der Fall ist, gibt die Vergleichseinrichtung 226 eine Fehlerbenachrichtigung 228 für die Kommunikation zu dem Systemverwalter aus und überträgt den Fehler zu dem Fehlerverzeichnis 218, um eine Hauptursache für den Fehler zu bestimmen.
Nachdem die Hauptursache für den Fehler durch Auswahl von einem oder mehreren Fehlern aus dem Fehlerverzeichnis 218 identifiziert worden ist, kann das Analyse-Modul 122(N) eine oder mehrere alternative Maßnahmen zum Beheben des Fehlers simulieren. Die alternativen Maßnahmen können mit dem aktuellen Verkehrsmuster und der Netzwerk-Topologie, so wie diese jeweils durch das Verkehrssimulator-Modul 214 und durch das Topologieänderungs-Modul 216 bereitgestellt werden, simuliert werden. Auf Basis der Simulationen kann das Analyse-Modul 122(N) eine oder mehrere geeignete Maßnahmen zum Beheben der Fehler und zum Verbessern der Gesamtleistung des Netzwerkes vorschlagen, wovon ein Beispiel als Verbindungsknoten-Fehler 230 in 2 dargestellt ist. So kann beispielsweise der Systemverwalter benachrichtigt werden, wenn der Verdacht besteht, dass die Software oder die Hardware fehlerhaft ist, die Topologie kann durch Anpassung der Übertragungsleistung geändert werden, wenn eine schlechte Verbindungsfähigkeit erfasst wird, die Router können Ratebegrenzungen durchführen, um eine Verbindungsüberlastung zu mildern, und so weiter.
Das Verwenden der Netzwerk-Simulation 210 für die Online-Diagnose bietet eine Reihe verschiedener Vorteile gegenüber den herkömmlichen heuristischen oder theoretischen Diagnoseverfahren. So kann die Netzwerk-Simulation 210 gegenüber den herkömmli chen heuristischen oder theoretischen Verfahren beispielsweise einen größeren Einblick in das Verhalten des Netzwerkes gewährleisten. Ein betriebsfähiges drahtloses Netzwerk ist beispielsweise eine komplexes System mit eng miteinander in Beziehung stehenden Komponenten, wie beispielsweise Verkehrsflüssen, Netzwerkprotokollen, Signalverarbeitungsalgorithmen, Hardware, Hochfrequenz-(HF)Ausbreitung und so weiter. Darüber hinaus können Interaktionen zwischen allen diesen Komponenten des Netzwerkes auftreten. Interaktionen zwischen Fehlern können auf effektive Weise diagnostiziert und über die Auswahl von einem oder mehreren Fehlern aus dem Fehlerverzeichnis 218 angegangen werden, die in einer Netzwerk-Simulation 210 resultieren, die dem tatsächlichen Verhalten des „realen" Netzwerkes entspricht.
Des Weiteren kann das Netzwerkverhalten durch Interaktionen zwischen den einzelnen Knoten, ebenso wie durch externe Rauschquellen, die sich in der Nähe der Knoten befinden, beeinflusst werden. Die herkömmlichen heuristischen oder theoretischen Verfahren erfassen das Verhalten solcher Netzwerke nicht und gehen Interaktionen zwischen den verschiedenen Komponenten des Netzwerkes nicht auf geeignete Weise an.
Als ein Beispiel sei ein Netzwerk 300 mit einer Sieben-mal-Drei-Topolgie, das in 3 dargestellt ist, betrachtet. In dem Netzwerk 300 sind fünf Flüsse dargestellt und als F₁ 302, F₂ 304, F₃ 306, F₄ 308 und F₅ 310 bezeichnet. In dem illustrierten Beispiel hat jeder der Abläufe 302 bis 310 eine ähnliche Menge an Verkehr zu kommunizieren. So kann beispielsweise jeder der Flüsse 302 bis 310 im Wesentlichen ähnliche Mengen an Daten von den jeweiligen Anwendungen empfangen.
Darüber hinaus können sich in diesem Beispiel einander angrenzende Knoten gegenseitig „hören", und der Interferenzbereich beträgt das Zweifache der Größe des Kommunikationsbereiches. So interferiert beispielsweise der Verkehr zwischen dem Knoten A 312 und dem Knoten O 314 beispielsweise mit dem Verkehr zwischen den Knoten C 318 und Q 318. Auf ähnliche Weise interferiert der Verkehr zwischen den Knoten G 320 und U 322 mit dem Verkehr zwischen den Knoten E 324 und S 326. Der Verkehr zwischen den Knoten G 320 und U 322 und der Verkehr zwischen den Knoten A 312 und O 314 interferieren jedoch nicht mit dem Verkehr zwischen den Knoten D 328 und R 330.
Die folgende Tabelle beschreibt ein Beispiel der Durchflussleistung der Flüsse 302 bis 310, wenn jeder Fluss Verkehr einer konstanten Bitrate (CBR) von elf Mbps sendet.
Wie in der obenstehende Tabelle dargestellt ist, empfängt der Fluss F₃ 306 eine höhere Durchflussleistung als die Flüsse F₂ 304 und F₄ 308. Mit anderen Worten bedeutet dies, dass Fluss F₃ 306 einen größeren Anteil der Bandbreite verbraucht als die anderen Flüsse des Netzwerkes 300.
Herkömmlicherweise konnte das Anwenden von heuristischen Verfahren zu einer Schlussfolgerung führen, dass der Fluss F₃ 306 einen übermäßig größeren Anteil der Bandbreite empfängt. Durch die Verwendung einer tracegesteuerten Online-Simulation kann der Manager-Knoten 102(N) jedoch zu dem Schluss kommen, dass es sich dabei um ein normales Verhalten handelt. So kann die Netzwerk-Simulation beispielsweise auch die Verbindungsqualität berücksichtigen und dementsprechend feststellen, dass die Flusse F₁ 302 und F₅ 310 mit den Flüssen F₂ 304 und F₄ 308 interferieren. Aus diesem Grund wird Fluss F₃ 306 aufgrund des Fehlens von Interferenz von den Flüssen F₁ 302 und F₅ 310 im Gegensatz zu den Flüssen F₂ 304 und F₄ 308 mit zusätzlicher Bandbreite versorgt. Auf diese Weise kann die Simulation feststellen, dass, selbst wenn sämtliche Flüsse dieselbe Senderate der Anwendungsebene haben, die beobachtete Durchflussleistung erwartet wird. Eine einfache Heuristik kann jedoch zu dem fälschlichen Schluss kommen, dass sich die Knoten D 328 und R 330 fehlerhaft verhalten.
Die Netzwerk-Simulation wird durch das Analyse-Modul 122(N) zum Verwalten des Netzwerkes durch das Wissen, was in Anbetracht der aktuellen Verkehrsflüsse und Verbindungsqualitäten von dem Netzwerk „zu erwarten ist", verwendet. Mit anderen Worten bedeutet dies, dass das Analyse-Modul 122(N) auf Basis von Schätzungen, die durch die Netzwerk-Simulation bereitgestellt werden, das kommentieren kann, was normales Verhalten darstellt. In dem vorangegangenen Beispiel wird dies, obgleich F₃ 306 einen größeren Anteil der Bandbreite des Netzwerkes 300 verwendet als die anderen Flüsse in dem Netzwerk 300, durch das Manager-Modul nicht als Fehler angezeigt, da dieses Verhalten erwartet wird. Wenn das beobachtete Verhalten von dem erwarteten Verhal ten abweicht, kann das Manager-Modul die Fehlersuche-Algorithmen einbeziehen, die das in 2 dargestellte Fehlerverzeichnis 218 verwenden, um die Hauptursache der Abweichung festzustellen.
Darüber hinaus sind, obgleich möglicherweise herkömmliche signaturbasierende oder regelnbasierte Ansätze der Fehlerdiagnose auf einen bestimmten Typ von Netzwerk mit einer spezifischen Umgebung und Konfiguration angewendet werden können, einfache Signaturen oder Regeln nicht ausreichend, um die intrinsische Komplexität in allgemeinen Einstellungen für die Fehlerdiagnose zu erfassen. Im Gegensatz dazu ist ein Simulator in höchstem Maße an Kundenanforderungen anpassbar und kann mit geeigneten Parametereinstellungen auf eine breite Klasse von Netzwerken angewendet werden, die für die Verwendung in verschiedenen Umgebungen konfiguriert sind. Die Fehlerdiagnose, die auf einem solchen Simulator installiert ist vererbt diese Allgemeingültigkeit.
Noch ein weiterer Vorteil des simulationsbasierten Ansatzes ist die Fähigkeit zum Durchführen der Was-Wenn-Analyse. Dies bedeutet, dass durch Ändern der Einstellungen oder durch Durchführen bestimmter Maßnahmen in dem Simulator ein Simulator die Leistung für ein imaginäres Szenario vorhersagen kann. Auf Basis dieser Daten kann ein Manager-Modul die Agenten-Module (beispielsweise Agenten-Modul 112(N) aus 1) anweisen, eine geeignete Maßnahme zum Optimieren der Leistung durchzuführen. Wie vorangehend beschrieben wurde, ist eine solche Was-Wenn-Analyse deshalb wertvoll, da es sich als schwierig erweisen kann, die Folgen eines Korrekturvorganges aufgrund einer Interaktion von mehreren Faktoren in einem Netzwerk vorherzusehen.
So kann beispielsweise die Sendeleistung erhöht werden, um die Verbindungsqualität zu verbessern, diese Erhöhung kann jedoch auch eine zusätzliche Interferenz erzeugen, die andere Knoten in dem Netzwerk nachteilig beeinflusst.
Erfassung und Diagnose von Fehlern
Im Folgenden wird ein simulationsbasierter Ansatz der Diagnose beschrieben, der das Erstellen einer Umgebung innerhalb eines Simulators (beispielsweise die Netzwerk-Simulation 210) bereitstellt, die sich der Funktionalität eines realen Netzwerkes nähert. Die erstellte Umgebung (das heißt, die Netzwerk-Simulation) kann anschließend zum Feststellen des erwarteten Verhaltens des realen Netzwerkes ebenso wie zum Feststellen, wann Unstimmigkeiten in dem realen Netzwerk auftreten, verwendet werden. Um eine Hauptursache dieser Unstimmigkeiten herauszufinden, ist der Manager-Knoten ausgeführt, um einen Suchraum abzusuchen, um festzustellen, welcher Fehler oder Fehlersatz die Netzwerkleistung reproduzieren können, die sich der Netzwerkleistung nähert, welche in dem realen Netzwerk beobachtet wird. Das simulierte Netzwerk kann eine Reihe verschiedener Netzwerkaspekte, so wie beispielsweise die Netzwerk-Topologie, Routingverhalten, Verkehrsmuster, die in dem realen Netzwerk beobachtet wurden, und so weiter, reproduzieren.
Im Folgenden wird ein Diagnosealgorithmus beschrieben, der zum Suchen von Hauptursachen für Fehler ausgeführt werden kann und der eine tracegesteuerte Online-Simulation als einen Baustein verwendet. So kann der Diagnosealgorithmus beispielsweise zuerst mit einem gegebenen Fehlersatz die Leistung des Netzwerkes schätzen. Anschließend durchsucht der Diagnosealgorithmus auf Basis der Differenzen zwischen der geschätzten und der beobachteten Leistung einen Suchraum, um jegliche beobachtete Unstimmigkeiten zu reproduzieren. In einer Implementierung kann der Diagnosealgorithmus mehrere Fehler desselben Typs (beispielsweise Netzwerk-Topologie) diagnostizieren, und er kann auch das Vorhandensein von mehreren Typen von Fehlern (beispielsweise Rauschen und Topologie) diagnostizieren.
Fehler können selbst dann diagnostiziert werden, wenn die Tracedaten, die zum Steuern der Simulation verwendet werden, Fehler enthalten. So können beispielsweise Daten, die durch das in 1 dargestellte Agenten-Modul 112(n) bereitgestellt werden, Fehler aufgrund einer Reihe verschiedener Ursachen wie beispielsweise Messfehlern, falschen Informationen, Software-/Hardwarefehlern in der Ausführung des Knotens 102(n), Netzwerkkommunikationsfehlern, und so weiter, enthalten. Das Säuberungs-Modul 120(N) wird durch den Manager-Knoten 102(N) ausgeführt, um die fehlerhaften Daten so in dem Trace zu reduzieren oder aus diesem zu entfernen, das zum Steuern der simulationsbasierten Fehlerdiagnose Tracedaten einer entsprechenden Qualität verwendet werden. Eine weiterführende Diskussion zur Ausführung des Säuberungs-Moduls 120(N) ist in Bezug auf die 8 bis 9 angeführt.
Tracegesteuerte Simulation
4 ist eine Darstellung einer exemplarischen Implementierung, die ein System 400 zeigt, das einen Simulator 118(N) und die in 2 dargestellte Netzwerk-Simulation 210 enthält. Tracedaten, die durch den Betrieb eines realen Netzwerkes gewonnen werden, befähigen den Simulator 118(N) zum genauen Darstellen des Netzwerkbetriebes des realen Netzwerkes und zum Prüfen der Auswirkungen eines gegebenen Fehlersatzes auf das reale Netzwerk. Für die Eingabe in einen Simulator können eine Reihe verschiedener Tracedaten erfasst werden, Beispiele davon werden auf die folgende Art und Weise beschrieben:
Netzwerk-Topologie 402
Netzwerk-Topologie-Daten 402 beschreiben die Topologie des Netzwerkes, so wie beispielsweise, welche Knoten aktuelle Mitglieder des Netzwerkes sind, sowie die entsprechenden Verbindungen zwischen den Knoten. So kann ein jeder Knoten in dem Netzwerk beispielsweise konfiguriert sein, um den Status (beispielsweise verbunden oder nicht verbunden) von benachbarten Knoten und Knoten mitzuteilen, auf die in einer oder mehreren Routing-Tabellen des Knotens verwiesen wird. Auf diese Weise kann dem Manager-Knoten 102(N) aus 1 die Zugehörigkeit von Knoten zu dem Netzwerk mitgeteilt werden. In einer Implementierung werden jeweils nur die Änderungen bei Nachbarn oder Routen mitgeteilt. Diese Daten können zum Steuern einer Routen-Simulation verwendet werden, die auf ausführlichere Weise in Bezug auf einen in 4 dargestellten Routen-Simulator beschrieben wird.
Verkehrsstatistik 404
Verkehrsstatistik-Daten 404 können zum Beschreiben von Mengen von Daten, die durch das Netzwerk kommuniziert und der bestimmten Knoten, die diese Daten kommunizieren, verwendet werden. Die Verkehrsstatistiken 404 können als Eingabe in das Simulator-Modul 214 aus 2 so verwendet werden, dass die Netzwerk-Simulation 210 einen Verkehrsfluss hat, der sich dem des realen Netzwerkes nähert. Jeder Knoten des Netzwerkes kann einen oder mehrere Zähler enthalten, die das Verkehrsvolumen, das von seinen Nachbarn gesendet und von ihnen empfangen wird, beschreiben. Diese Da ten werden verwendet, um eine Routenverkehrs-Simulation zu steuern, die durch das Verkehrssimulations-Modul 214 bereitgestellt wird, das ebenfalls auf ausführlichere Weise In Bezug auf 4 beschrieben wird.
Physikalisches Medium 406
Daten zum physikalischen Medium 406 können die Auswirkungen des physikalischen Mediums, das zum Implementieren des Netzwerkes verwendet wird, auf die Netzwerkleistung beschreiben. So kann beispielsweise in einem drahtlosen Netzwerk jeder Knoten sein Rauschpegel und die Signalstärke der drahtlosen Verbindungen von seinen benachbarten Knoten mitteilen. In einer Implementierung werden Abweichungen der Signalstärke periodisch durch Zeitmittelung, Standardabweichung oder andere statistische Zusammenstellungen erfasst.
Netzwerkbetrieb 408
Netzwerkbetriebsdaten 408 beschreiben den Netzwerkbetrieb 408 des realen Netzwerkes. Wie vorangehend beschrieben, wird der beobachtete Netzwerkbetrieb mit dem von der Netzwerk-Simulation ausgegebenen geschätzten Netzwerkbetrieb verglichen, um Unstimmigkeiten in dem Netzwerkbetrieb zu erfassen. Zum Netzwerkbetrieb können sowohl der Verbindungsbetrieb als auch der Ende-zu-Ende-Betrieb gehören, von denen beide durch eine Reihe verschiedener Metriken so wie beispielsweise Paketverlustrate, Verzögerung und Durchflussleistung gemessen werden können. Die folgenden Beschreibung legt das Hauptaugenmerk auf den Verbindungsebenenbetrieb. Die Datenerfassung kann zwei Schritte umfassen: (1) das Erfassen von unverarbeiteten Leistungsdaten an einem lokalen Knoten und (2) das Verteilen der erfassten Daten zu den Erfassungsstellen für die Analyse. Für die Lokaldaten-Erfassung kann eine Reihe verschiedener Tools verwendet werden, so wie beispielsweise native Routing-Protokolle und „Paketschnüffler".
In einer Implementierung ist, obgleich die Verteilung von Daten zu dem Manager-Modul einen Netzwerk-Steuerungsaufwand verursacht, der Steuerungsaufwand für das Netzwerk gering und hat wenig Auswirkung auf den Datenverkehr in dem Netzwerk. Darüber hinaus kann der Steuerungsaufwand für das Netzwerk durch Verwendung von Kom pression, Datenkodierung, Multicast (Gruppenruf), adaptiven Änderungen eines Zeitmaßes und/oder des räumlichen Bereiches der Verteilung und so weiter reduziert werden. So wird beispielsweise ein minimaler Datensatz während des normalen Betriebes des Netzwerkes erfasst und ausgetauscht. Sobald die Notwendigkeit nach zusätzlichen Daten besteht (beispielsweise, wenn die Informationen, die erfasst werden, eine Unstimmigkeit anzeigen), kann das Manager-Modul zusätzliche Informationen anfordern und die Frequenz der Datenerfassung für das Subset der Knoten, die ein verstärktes Überwachen benötigen, erhöhen.
Simulationsmethodik
Die Netzwerkeigenschaften, die durch den Simulator modelliert werden, können in eine Reihe verschiedener Kategorien, so wie beispielsweise Verkehrslast, Routing (Leitwegsuche), drahtloses Signal, Fehler und so weiter klassifiziert werden. Die folgenden Abschnitte beschreiben Simulationsbeispiele einer jeden dieser Kategorien als einzelne Module, die dazu verwendet werden, den Simulator zu veranlassen, die entsprechenden Netzwerkeigenschaften zu simulieren.
Verkehrslast-Simulator 410
Eine durch einen Simulator erzeugte Netzwerk-Simulation kann so konfiguriert sein, dass sie ein Verkehrsmuster bereitstellt, das sich dem Verkehrsmuster des realen Netzwerkes nähert. Ein Beispiel eines Ansatzes für die Verkehrslast-Simulation beinhaltet Ende-zu-Ende-Anwendunganforderungen. Ein Netzwerk mit N Knoten kann jedoch möglicherweise N² Anforderungen enthalten. Darüber hinaus kann es sich in Anbetracht der Heterogenität von Anwendungsanforderungen und der Verwendung von unterschiedlichen Transportprotokollen, so wie beispielsweise einem Übertragungssteuerungsprotokoll (TCP), einem Benutzer-Datengramm-Protokoll (UDP), einem Rapid Transport Protocol (RTP) und so weiter als schwierig erweisen, Ende-zu-Ende-Anwendungsanforderungen zu erhalten.
In einer Implementierung ist ein Verkehrslast-Simulator-Modul 410 ein Abschnitt des in 2 dargestellten Verkehrssimulator-Moduls 214 und stellt eine verbindungsbasierte Verkehrssimulation bereit, die für die Skalierbarkeit und zum Umgehen der Notwendigkeit verwendet wird, dass Ende-zu-Ende-Anwendunganforderungen erhalten werden müssen. Die verbindungsbasierende Verkehrssimulation kann, wenn sie implementiert ist, eine Anwendungsebenen-Senderate in jeder Verbindung anpassen, um die Zählungen des beobachteten Verbindungsebenen-Verkehrs des realen Netzwerkes anzupassen. Auf diese Weise werden die höheren Schichten (beispielsweise eine Transportschicht, eine Anwendungsschicht und so weiter) abstrahiert, wodurch sich die Simulation auf die Paketgröße und die Verkehrsrate konzentrieren kann.
Das Anpassen der Senderate pro jeweiliger Verbindung in einem Simulator kann durchaus an Bedeutung erlangen, wenn die Senderate in einer Verbindung nicht direkt gesteuert werden kann, so wie beispielsweise, wenn lediglich die Anwendungsebenen-Senderate angepasst werden kann und das Protokoll der Medium Access Control (MAC) adressiert werden muss. Wenn beispielsweise eine Anwendungs-Senderate einer Verbindung bei einem Mbps eingestellt wird, kann die tatsächliche Senderate (auf Sendung) aufgrund des Backoffs an der MAC-Schicht geringer oder aufgrund der MAC-Ebenen-Übertragung höher sein. Das Thema wird durch Interferenz weiter verkompliziert, die Interdependenz zwischen den Senderaten in verschiedenen Verbindungen verursacht.
Ein iteratives Sucherverfahren kann zum Überwinden dieser Probleme durch Bestimmen der Senderate in einer jeden Verbindung verwendet werden. Es kann eine Reihe verschiedener iterativer Suchverfahren angewendet werden, so wie (i) multiplikativer Anstieg und multiplikativer Abfall, und (ii) additiver Anstieg und additiver Abfall. Wie dies in der folgenden Vorgehensweise dargestellt ist, die unter Verwendung eines Pseudocodes illustriert wird, versucht jede Verbindung einzeln die Differenz zwischen der aktuellen Senderate in dem Simulator und der tatsächlichen Senderate in dem realen Netzwerk zu reduzieren.
Auf diese Weise illustriert der oben stehende Pseudocode ein Beispiel der Suche nach der Anwendungsebenen-Senderate unter Verwendung von entweder multiplikativem Anstieg/multiplikativem Abfall oder additivem Anstieg/additivem Abfall. In der oben stehenden exemplarischen Vorgehensweise wird ein Parameter α eingeführt, wobei α ≤ 1 ist (beispielsweise, ist α = 0,5), um Schwingung zu dämpfen. Der Prozess wird so lange wiederholt, bis sich entweder die Rate der Zielrate nähert (als targetMacSent bezeichnet), oder bis eine maximale Anzahl von Wiederholungen erreicht ist.
Routen-Simulator 412
Routing (Leitwegsuche) spielt eine wichtige Bedeutung in der Netzwerkleistung, insbesondere in einem Multi-Hop-Netzwerk. Ein Ansatz der Routen-Simulation beinhaltet die Simulation eines Routing-Protokolls, das in dem realen Netzwerk innerhalb des Simulators verwendet wird. Um dasselbe Routingverhalten wie in einem realen Netzwerk zu reproduzieren, werden detaillierte Traces zum Erstellen des Routings gewonnen.
Die tatsächlichen Routen, die Pakete durchlaufen, können als eine Eingabe in das Routen-Simulator-Modul 412 verwendet werden. Wenn Routen keinen häufigen Schwankungen unterliegen, können Routenänderungen verfolgt werden, anstatt die Routen auf einer paketweisen Basis in dem Manager zu erfassen. Zu diesem Zweck kann das Routen-Simulator-Modul 412 beispielsweise tracegesteuert sein. So kann das Routen-Simulator-Modul beispielsweise innerhalb des Simulators 118(N) implementiert sein, so wie zum Beispiel ein QUALNET-Simulator (QUALNET ist eine Marke von Scalable Network Technologies, Inc. of Los Angeles, Kalifornien). Das Routen-Simulations-Modul 412 akzeptiert Routing-Aktualisierungen und die entsprechenden Zeitstempel als Eingaben und stellt anschließend sicher, dass die Pakete in der Netzwerk-Simulation dieselben Routen wie in dem realen Netzwerk durchlaufen.
Signalstärken-Simulator 414
Die Signalstärke hat sowohl eine Auswirkung auf die Leistung des verdrahteten als auch des drahtlosen Netzwerkes. Aufgrund von Abweichungen in verschiedenen Netzwerkverbindungsgeräten (beispielsweise drahtlosen Karten) und Umgebungen, kann es sich als schwierig erweisen, ein allgemeines Ausbreitungsmodell herzuleiten, das sämtliche dieser Faktoren erfasst. Um dieses Problem anzugehen, kann der Signalstärken-Simulator 414 von der realen Messung der Signalstärke in dem realen Netzwerk gesteuert sein, die von den Netzwerkverbindungsgeräten selbst gewonnen wird.
Fehlereinspeisung 416
Das System kann ein Fehlereinspeisungs-Modul 416 enthalten, das ausgeführt werden kann, um verschiedene Typen von Fehlern in den Simulator einzuspeisen, wie beispielsweise Packet-Dropping an Hosts, externe Rauschquellen, fehlerhaftes Verhalten der Medium Access Control MAC und so weiter. Auf diese Weise kann das Analyse-Modul die Auswirkung von Fehlern auf das Netzwerk untersuchen. Packet-Dropping an Hosts tritt beispielsweise dann auf, wenn ein sich fehlerhaft verhaltender Knoten einen Teil des Verkehrs von einem oder mehreren benachbarten Knoten, zum Beispiel aufgrund von Hardware-/Softwarefehlern, Überlauf im Zwischenspeicher, böswilligem Verwerfen und so weiter verwirft. Die Fähigkeit, solches End-Host-Packet-Dropping zu erfassen ist deshalb nützlich, da es den Manager ermöglicht, zwischen den Verlusten, die durch End-Hosts verursacht werden und den Verlusten, die durch das Netzwerk verursacht werden, zu unterscheiden.
Das System unterstützt durch die Ausführung des Fehlereinspeisungs-Moduls 416 darüber hinaus auch die Fähigkeit des Einspeisens von externen Rauschequellen in das Netzwerk. Dementsprechend kann das System eine Simulation bereitstellen, die die Auswirkung von Rauschquellen, die außerhalb des Netzwerkes liegen (das heißt, die nicht durch einen Knoten bereitgestellt werden), aber dennoch das Netzwerk beeinträchtigen, repliziert.
Fehlerhaftes Verhalten der Medium Access Control MAC tritt dann auf, wenn ein fehlerhafter Knoten den MAC-Regeln nicht folgt und einen nicht berechtigten Anteil der Ka nalbandbreite erhält. So kann in IEEE 802.11 ein fehlerhafter Knoten beispielsweise ein kleineres Konfliktfenster (CW „contention window") wählen, um aggressiv Verkehr zu senden.
Verbindungsüberlastung kann ebenfalls durch das System simuliert werden, indem dem simulierten Netzwerk eine hohe Datenübertragungslast zugeführt wird. Anders als bei anderen Typen von Fehlern wird die Verbindungsüberlastung implizit durch die Verkehrsstatistiken erfasst, die von jedem Knoten gewonnen werden. Dementsprechend kann die tracegesteuerte Simulation direkt die Auswirkung der Verbindungsüberlastung auf das reale Netzwerk einschätzen. Eine weiterführende Diskussion der Fehlerdiagnose kann dem folgenden Abschnitt entnommen werden.
Fehlerdiagnose
Die Hauptursachen von Störungen und Leistungsproblemen können durch die Ausführung des in 2 dargestellten Analyse-Moduls 122(N) diagnostiziert werden. Durch Anwenden von Fehlern auf eine Netzwerk-Simulation kann die Diagnose von Netzwerk-Unstimmigkeiten auf das Suchen eines Fehlersatzes reduziert werden, der, wenn er in das simulierte Netzwerk eingespeist wird, in einer durch das simulierte Netzwerk geschätzten Leistung resultiert, die sich der beobachteten Leistung des realen Netzwerkes nähert. Eher formell, wird unter den gegebenen Netzwerkeinstellungen NS, der Fehlersatz (FaultSet) so gesucht, dass: SimPerf(NS; FaultSet) = RealPerfwobei die Netzwerkleistung ein funktionaler Wert ist, der unter Verwendung einer Reihe verschiedener Metriken quantifiziert werden kann.
Der Suchraum für einen Fehler kann mehrere Suchdimensionen aufgrund der verschiedenen Kombination von Fehlern, die gefunden werden können, enthalten. In einer Implementierung wird das Analyse-Modul 122(N) für die effiziente Suche aufgrund einer Einsicht optimiert, dass verschiedene Typen von Fehlern oftmals einige wenige bestimmte Metriken der Netzwerkleistung ändern. So beeinträchtigt im Allgemeinen das Packet-Dropping an Hosts die Verbindungsverlustrate, jedoch keine anderen Metriken der Netzwerkleistung. Aus diesem Grund können die Metriken der Netzwerkleistung zum Diagnostizieren der Netzwerkleistung verwendet werden, indem die Differenzen zwischen der beobachteten und geschätzten Netzwerkleistung, die durch die Metriken angezeigt werden, zur Kenntnis genommen werden.
In einer Implementierung ist es nicht notwendig, ein prognostisches Modell für den Zweck der Fehlerdiagnose bereitzustellen. Hier ist es vielmehr ausreichend, das zu simulieren, was in dem Netzwerk nach der Tatsache stattgefunden hat. So können beispielsweise Agenten-Module dem Manager-Modul periodisch Informationen über die Verbindungsbedingungen und die Verkehrsmuster mitteilen. Diese Informationen werden verarbeitet und anschließend in den Simulator eingespeist, um eine Netzwerk-Simulation zu erzeugen, die anschließend zum Feststellen einer wahrscheinlichen Hauptursache des Fehlers verwendet werden kann.
Anfangsdiagnose
5 ist ein Ablaufplan, der eine Vorgehensweise 500 in einer exemplarischen Implementierung darstellt, in der Fehler desselben Typs einer Anfangsdiagnose unterzogen werden. Im Sinne einer verständlichen Darstellung beinhaltet die folgende Diskussion drei exemplarischen Fehlertypen: (1) Packet-Dropping an Hosts; (2) externes Rauschen; und (3) fehlerhaftes MAC-Verhalten. Es sollte jedoch offensichtlich sein, dass eine große Bandbreite von anderen Fehlern und Fehlerkombinationen auf eine ähnliche Weise angegangen werden können. Die folgende Diskussion umfasst Vorgehensweisen, die unter Verwendung der beschriebenen Systeme und Geräte implementiert werden können. Aspekte einer jeden der Vorgehensweisen können in Hardware, Firmware oder Software oder in einer Kombination daraus implementiert werden. Die Vorgehensweisen werden als ein Satz von Blöcken dargestellt, die Operationen, die durch ein oder mehrere Geräte durchgeführt werden, spezifizieren, und sind nicht notwendigerweise auf die Reihenfolgen beschränkt, die für das Durchführen der Operationen durch die jeweiligen Blöcke dargestellt sind.
Wie vorangehend beschrieben wurde, kann eine tracegesteuerte Simulation, wenn aktuelle Netzwerkeinstellungen eines realen Netzwerkes in sie eingespeist werden, dafür verwendet werden, eine geschätzte Netzwerkleistung des Netzwerkes zu erstellen. Auf Basis der Differenz zwischen der geschätzten Netzwerkleistung und der beobachteten Netzwerkleistung können die Typen von Fehlern unter Verwendung eines Entscheidungsbaumes festgestellt werden, wovon ein Beispiel in 6 dargestellt ist.
Aufgrund einer Reihe verschiedener Faktoren ist die geschätzte Netzwerkleistung selbst bei Nicht-Vorhandensein von Fehlern wahrscheinlich nicht mit der beobachteten Netzwerkleistung identisch. Aus diesem Grund können Unstimmigkeiten in der Netzwerkleistung unter Verwendung eines Schwellenwertes festgestellt werden. So kann eine Unstimmigkeit beispielsweise auf der Basis festgestellt werden, ob eine Differenz zwischen den Werten der geschätzten und der beobachteten (das heißt, der realen) Netzwerkleistung einen entsprechenden Schwellenwert übersteigt. Der Schwellenwert kann auf verschiedenerlei Weise berechnet werden, so beispielsweise durch Beobachten der historischen Differenz zwischen der simulierten und der tatsächlichen Netzwerkleistung.
Ein Fehlerklassifikationsschema, von dem ein Beispiel in 6 dargestellt ist, ist konfiguriert, um den Typ von Fehler zu bestimmen, der die Unstimmigkeit verursacht hat, in dem zur Kenntnis genommen wird, dass unterschiedliche Fehler jeweils unterschiedliche Verhalten demonstrieren. Während sich die Verhalten, die durch einen jeden der Fehler demonstriert werden, noch überlappen können (beispielsweise führen sowohl die Rauschquellen als auch das Packet-Dropping an den Hosts zu einem Anstieg der Verlustraten, das Verringern des Konfliktfensters führt zu einem Anstieg der Menge von Verkehr und erhöht demzufolge das Interferenzrauschen, und so weiter), können die Fehler zunächst durch Überprüfen des jeweiligen differenzierenden Verhaltens kategorisiert werden. So erhöht beispielsweise eine externe Rauschquelle die Rauschpegel, die die benachbarten Knoten erfahren, jedoch erhöht sie nicht die Senderaten irgendeines Knotens. Aus diesem Grund kann die externe Rauschquelle von dem fehlerhaften Verhalten der MAC und dem Packet-Dropping an Hosts unterschieden werden.
Im Folgenden wird erneut Bezug auf 5 genommen. Die folgende Diskussion enthält eingeklammerte Angaben mit kursivem Text, die alternierende Bezeichnungen, so wie diese in dem exemplarischen Pseudocode verwendet werden, angeben, der in der Diskussion der entsprechenden Figuren enthalten ist. In Block 502 wählt das Analyse-Modul einen oder mehrere Fehler von einer Vielzahl von Fehlern wie beispielsweise von dem Fehlerverzeichnis 218 aus 2 aus. Bei einer ersten Iteration der Vorgehens weise 500 wird keiner der Vielzahl von Fehlern ausgewählt, um eine erwartete Leistung des Netzwerkes unter normalen Betriebsbedingungen, das heißt, ohne Fehler herzuleiten. In einer anderen Implementierung wird die Vorgehensweise 500 aus 5 verwendet, um eine Anfangsdiagnose durchzuführen, und hierbei handelt es sich nicht um eine iterative Vorgehensweise, das heißt, es ist eine Vorgehensweise „in einem Durchlauf". In solch einer Implementierung kann der Block 502 aus der Vorgehensweise 500 weggelassen werden, und der Fehlersatz wird als ein leerer Satz {} bereitgestellt.
In Block 504 werden der Fehlersatz (FS) und die Netzwerkeinstellungen (NS) als eine Eingabe der Netzwerk-Simulation bereitgestellt. Es können eine Reihe verschiedener Netzwerkeinstellungen bereitgestellt werden, wie beispielsweise Signalstärke, Verkehrsstatistiken, Routing-Tabellen und so weiter.
In Block 506 wird die erwartete Leistung (SimPerf) durch Ausführen der Netzwerk-Simulation mit den bereitgestellten Eingaben vorhergesagt. Im Entscheidungsblock 506 wird eine Feststellung dahingehend getroffen, ob die Differenz (Diff) zwischen der erwarteten Leistung (SimPerf) und der realen Leistung (RealPerf) größer als ein Schwellenwert ist. Wenn die Differenz größer als der Schwellenwert ist (Block 506), wird der Fehlertyp (FT) bestimmt (Block 510). Eine weiterführende Diskussion der Bestimmung eines Fehlertyps ist in Bezug auf 6 angeführt.
Nachdem der Fehlertyp bestimmt ist, werden die Fehler durch Suchen eines Satzes an Knoten und Verbindungen, die Differenzen zwischen der beobachteten und der erwarteten Netzwerkleistung aufweisen, welche einen Schwellenwert für diesen bestimmten Fehlertyp überschreiten (Block 514), lokalisiert (Block 512). Der Fehlertyp bestimmt, welche Netzwerkleistungs-Metrik zum Quantifizieren der Differenz in der Leistung verwendet wird. So kann beispielsweise Packet-Dropping durch Suchen von Verbindungen mit einer signifikanten Differenz zwischen den erwarteten und den beobachteten Verlustraten identifiziert werden.
In Block 516 wird der Fehlerbetrag des Fehlers bestimmt. So kann eine Funktion (als „g( )" bezeichnet) beispielsweise zum Abbilden der Auswirkung eines Fehlers in einem entsprechenden Fehlerbetrag verwendet werden. So ist beispielsweise in einem Szenario des Packet-Dropping an einem End-Host die Funktion g() eine Identitätsfunktion, da die Differenz in der Verlustrate einer Verbindung direkt in einer Änderung der Rate des Packet-Dropping in einer Verbindung abgebildet werden kann (Fehlerbetrag des Fehlers). In einem Fehlerszenario des externen Rauschens ist die Funktion g() eine Ausbreitungsfunktion eines Rauschsignals. Die Blöcke 510 bis 516 können für jeden Knoten oder Verbindung wiederholt werden. Der Fehler mit einem entsprechenden Fehlerbetrag kann anschließend in Block 516 zu dem Fehlersatz hinzuaddiert werden.
Im Folgenden wird ein exemplarischer Pseudocode illustriert, der ausgeführt werden kann, um eine Vorgehensweise ähnlich der in 5 dargestellten Vorgehensweise 500 zu implementieren, und er wird wie folgt ausgedrückt:
Der Pseudocode beschreibt einen Diagnostikalgorithmus, der zum Erfassen, ob ein Fehler aufgetreten ist, verwendet werden kann. Die folgende Vorgehensweise ist ein Beispiel eines Algorithmus, der zum Feststellen des Typs des erfassten Fehlers verwendet werden kann.
6 ist ein Ablaufdiagramm, das eine Vorgehensweise 600 in einer exemplarischen Implementierung darstellt, in der ein Entscheidungsbaum zum Feststellen eines Typs von Fehler verwendet wird. Die in 6 dargestellte Vorgehensweise 600 kann dem in 5 dargestellten Block 510 entsprechen oder nicht. In dem Entscheidungsblock 602 wird eine Feststellung dahingehend getroffen, ob der absolute Wert einer simulierten Menge von gesendeten Paketen (SimSent) minus einer realen Menge von gesendeten Paketen (RealSent) größer als ein Schwellenwert ist, was als ThreshSentDiff bezeichnet wird. Wenn dies der Fall ist, wird ein Fehler gesendet, der anzeigt, dass das Konfliktfenster (CW) auf zu niedrig eingestellt ist (Block 604).
Wenn der Schwellenwert von Block 602 nicht überschritten wird, wird anschließend im Entscheidungsblock 606 eine Feststellung dahingehend getroffen, ob eine Unstimmigkeit (das heißt, wenn eine Rauschen-Schwellenwert-Differenz ThreshNoiseDiff überschritten wurde) zwischen dem realen Rauschen (RealNoise), welches in dem realen Netzwerk angezeigt wird und dem erwarteten Rauschen (SimNoise) des simulierten Netzwerkes vorliegt. Wenn dies der Fall ist, wird ein Rauschen-Fehler festgestellt (Block 608).
Wenn der Rauschen-Schwellenwert nicht überschritten wurde (Block 606), wird anschließend im Entscheidungsblock 610 eine Feststellung dahingehend getroffen, ob der simulierte Paketverlust (SimLoss), das heißt, der erwartete Paketverlust, von dem realen Paketverlust (RealLoss) um mehr als eine Verlust-Schwellenwert-Differenz (Thresh-LossDiff) abweicht. Wenn dies der Fall ist, wurde ein Packet-Dropping-Fehler festgestellt (Block 612). Anderenfalls arbeitet der Knoten normal (Block 614). Hierbei sollte offensichtlich sein, dass eine große Bandbreite verschiedener anderer Fehlertypen ebenfalls auf eine ähnliche Weise festgestellt werden kann.
7 ist ein Ablaufplan, der eine Vorgehensweise 700 in einer exemplarischen Implementierung darstellt, in der Fehler, die unterschiedlichen Typs sind, unter Verwendung eines iterativen Diagnostikalgorithmus diagnostiziert werden. Im Allgemeinen können in einem Netzwerk mehrere Typen von interagierenden Fehlern festgestellt werden. Selbst wenn die Fehler desselben Typs sind, können immer noch Interaktionen festgestellt werden, wodurch ein Diagnostikalgorithmus mit einem Durchlauf nicht mehr ausreichend ist. Aus diesem Grund kann ein iterativer Diagnostikalgorithmus, so wie dieser in 7 dargestellt ist, implementiert werden, um die Hauptursachen zu finden. Der Algorithmus umfasst zwei Stufen: (i) eine Anfangsdiagnose-Stufe, die der in 5 dargestellten Vorgehensweise 500 ähnlich ist, und (ii) iterative Verfeinerungen.
Während der Stufe der Anfangsdiagnose wird ein Diagnostikalgorithmus mit einem Durchlauf angewendet, um einen Anfangs-Fehlersatz herzuleiten. Während der zweiten Stufe wird der Fehlersatz iterativ durch (i) Anpassen des Fehlerbetrages der Fehler, die bereits in den Fehlersatz eingefügt worden sind, und (ii) gegebenenfalls Hinzuaddieren des neuen Fehlers zu dem Satz, verfeinert. Die Vorgehensweise 700 kann so lange wiederholt werden, bis die Änderung in dem Fehlersatz verschwindend gering ist, so wie dies der Fall ist, wenn die Fehlertypen und die Positionen sich nicht ändern, sich die Fehlerbeträge der Fehler um minimale Mengen ändern, und so weiter.
Ein iterativer Ansatz kann auch für das Suchen nach den Fehlerbeträgen der Fehler verwendet werden. Auf einer hohen Ebene ist dieser Ansatz ähnlich der verbindungsbasierten Simulation, die in Bezug auf 5 beschrieben ist, bei der die Differenz zwischen den Zielwerten und den aktuellen Werten als eine Rückmeldung zum progressiven Annähern an das Ziel verwendet wurde.
In Block 702 wird beispielsweise die erwartete Netzwerkleistung mit dem vorhandenen Fehlersatz für jede Wiederholung geschätzt. So kann die erwartete Netzwerkleistung beispielsweise durch die Simulation des Netzwerkes unter Verwendung der von dem realen Netzwerk gewonnenen Netzwerkeinstellungen geschätzt werden. Die Netzwerkeinstellungen werden durch die Ausführung von Agenten-Modulen auf jedem Knoten bereitgestellt. Die Netzwerkeinstellungen, die durch jeden Knoten bereitgestellt werden, können die lokale Netzwerkleistung des Knotens ebenso wie die Netzwerkleistung der benachbarten Knoten beschreiben.
In Block 704 wird die Differenz zwischen der geschätzten Netzwerkleistung (unter dem vorhandenen Fehlersatz) und der realen Netzwerkleistung berechnet. Die Differenz kann beispielsweise durch einen Manager-Knoten durch die Ausführung eines Manager-Moduls berechnet werden. Das Manager-Modul vergleicht, wenn es ausgeführt ist, die geschätzte (das heißt, die erwartete) Netzwerkleistung, die von einem simulierten Netzwerk gewonnen wird, mit der realen (das heißt, der beobachteten) Netzwerkleistung, wie diese durch zusätzliche Netzwerkeinstellungen, die von einer Vielzahl von Agenten gewonnen werden, angezeigt wird.
Die in 7 dargestellte Vorgehensweise 700 stellt zuerst eine Anfangs-Diagnose in einer Art und Weise an, die der in Bezug auf 5 beschriebenen Vorgehensweise 500 ähnlich ist. Im Entscheidungsblock 706 wird beispielsweise eine Feststellung dahingehend getroffen, ob die berechnete Differenz größer als ein entsprechender Schwellenwert ist. Wenn dies nicht der Fall ist, wird der Fehlersatz mitgeteilt (Block 708). Da in diesem Beispiel die berechnete Differenz nicht größer als der Schwellenwert ist, zeigt dies dem Analyse-Modul an, dass das Netzwerk normal arbeitet. Wenn die berechnete Differenz größer als der entsprechende Schwellenwert ist (Block 706), wird jedoch der Fehlertyp festgestellt (Block 710). Der Fehlertyp kann auf verschiedenerlei Weise festgestellt werden, wovon ein Beispiel in Bezug auf 6 beschrieben worden ist.
In Block 712 wird die Differenz in eine Änderung in den Fehlerbeträgen des Fehlers umgewandelt, und die Fehlerbeträge werden in Übereinstimmung mit der berechneten Änderung angepasst (Block 714). So kann die Funktion g(), wie voranstehend in Bezug auf 5 beschrieben, zum Berechnen eines Fehlerbetrages für jeden der Fehler auf Basis der jeweiligen Differenzen zwischen der erwarteten und der realen Netzwerkleistung verwendet werden. Auf diese Weise können die Fehler miteinander verglichen werden, um festzustellen, welcher Fehler eine Auswirkung auf die Netzwerkleistung hat, die der beobachteten Unstimmigkeit entspricht. In einer Implementierung wird der größte Fehlerbetrag zuerst verwendet, um die Unstimmigkeit zu erklären und dadurch einen bestimmten Fehler zu identifizieren, der die Unstimmigkeit verursacht hat. In einer anderen Implementierung werden die Fehlerbeträge verglichen, um einen Fehler zu lokalisieren, der zu einer Differenz führt, die sich der berechneten Differenz nähert. So kann beispielsweise jeder einer Vielzahl von Fehlern jeweilige Differenzen zwischen der erwarteten und der realen Netzwerkleistung haben. Es können einer oder mehrere der Fehler durch Anpassen der jeweiligen Differenzen an die berechnete Differenz bei der Netzwerkleistung ausgewählt werden. In Block 716 werden Fehler entfernt, die Fehlerbeträge haben, die geringer als ein entsprechender Schwellenwert sind, wodurch der Fehlersatz optimiert wird.
In dem Entscheidungsblock 718 wird eine Feststellung dahingehend getroffen, ob die erwartete Leistung des Netzwerkes unter Verwendung des aktuellen Fehlersatzes mit der realen Netzwerkleistung übereinstimmt. So kann das Analyse-Modul beispielsweise heuristische Daten speichern, die eine oder mehrere Wiederholungen des Fehlersatzes und der resultierenden Leistungswerte in der Netzwerk-Simulation beschreiben. Die Differenz zwischen den Zielwerten (das heißt, den Leistungswerten des realen Netzwerkes) und den aktuellen Werten (das heißt, den Leistungswerten des simulierten Netzwerkes) wird durch das Analyse-Modul als eine Rückmeldung zum progressiven „Bewegen" der Netzwerk-Simulation verwendet, damit sich diese dem realen Netzwerk nähert.
Wenn die erwartete Leistung nicht mit der Leistung des realen Netzwerkes übereinstimmt (Block 718), wird ein neuer in Frage kommender Fehler zu dem Fehlersatz hinzugefügt. Zusätzlich zu dem Suchen nach den korrekten Fehlerbeträgen der Fehler kann beispielsweise die Zugehörigkeit zu dem Fehlersatz durch Auswählen neuer in Frage kommender Fehler, die die Differenz zwischen der erwarteten Netzwerkleistung und der Leistung des realen Netzwerkes am besten erklären, iterativ verfeinert werden (Block 720). Diese neuen Fehler werden zu dem Fehlersatz (Block 722) hinzugefügt. Anschließend wird der Fehlersatz, einschließlich des neuen in Frage kommenden Fehlers als eine Eingabe in eine Netzwerk-Simulation zum Schätzen der erwarteten Netzwerkleistung mit dem vorhandenen Fehlersatz (Block 702) verwendet. In einer Implementierung wird ein Fehler während jeder Iteration der Vorgehensweise 700 hinzuaddiert, die die größte Unstimmigkeit erklären kann, wodurch falsche Positivwerte gesteuert werden. Die Vorgehensweise 700 kann anschließend so lange wiederholt werden, bis sich die erwartete Leistung des simulierten Netzwerkes der realen Leistung des realen Netzwerkes nähert. Auf diese Weise kann das simulierte Netzwerk durch das Einfügen von Fehlern so bewegt werden, dass es eine genaue Darstellung von Fehlern, die zu der beobachteten Netzwerkleistung in dem realen Netzwerk führen, gewährleistet.
Im Folgenden wird ein exemplarischer Pseudocode dargestellt, der ausgeführt werden kann, um die in 7 dargestellte Vorgehensweise 700 bereitzustellen.
Auf diese Weise beschreibt der Pseudocode einen exemplarischen Diagnostikalgorithmus, der konfiguriert ist, um Fehler mehrerer Typen zu diagnostizieren.
Entfernen von Fehlern in Tracedaten
In den vorangehenden Abschnitten wurde die Fehlerdiagnose beschrieben, bei der Tracedaten zum Steuern einer Online-Simulation verwendet werden. In der Praxis können Tracedaten, die durch Agenten-Module erfasst werden, wenn diese auf den jeweiligen Knoten ausgeführt sind, aus mehreren Gründen, so wie beispielsweise aufgrund von Hardware-, Software- und/oder Netzwerkfehlern, Fehler enthalten, wie dies voranstehend bereits erwähnt wurde. Dementsprechend kann das in 1 dargestellte Säuberungs-Modul 120(N) ausgeführt sein, um die „rohen" Tracedaten, die von einer Vielzahl von Agenten empfangen wurden, zu säubern, um für die Fehlerdiagnose gesäuberte Tracedaten als eine Eingabe in den Simulator 118(N) bereitzustellen.
8 ist eine Darstellung eines Netzwerkes 800 in einer exemplarischen Implementierung, in der die Vielzahl von Knoten 102(1) bis 102(N) aus 1 Agenten-Module enthalten, die ausgeführt werden können, um ein Überwachen der benachbarten Knoten durchzuführen. Die Agentenmodule, die auf einem jeden der Knoten in dem Netzwerk ausgeführt werden, führen ein Überwachen der benachbarten Knoten durch, wobei es sich um ein Verfahren handelt, bei dem eine Vielzahl von Knoten 102(1) bis 102(N) die Leistung und die Verkehrsstatistiken nicht nur für ihre eigenen eingehenden/abgehenden Verbindungen sondern auch für andere Verbindungen innerhalb ihres Kommunikationsbereiches mitteilt. Das Überwachen der benachbarten Knoten kann auf verschiedenerlei Weise durchgeführt werden. So kann beispielsweise ein Agenten-Modul auf einem ersten Knoten ausgeführt sein, um einen zweiten Knoten in dem Netz werk zu untersuchen, um von dem zweiten Knoten Daten der Netzwerkleistung zu gewinnen. In einem weiteren Beispiel empfängt der erste Knoten eine Kommunikation von dem zweiten Knoten, wie beispielsweise eine Rundsendung, die Daten der Netzwerkleistung enthält. In einem weiteren Beispiel überwacht der erste Knoten Daten, die durch den zweiten Knoten für die Kommunikation durch das Netzwerk zum Überwachen der Netzwerkleistung gesendet werden. Der erste Knoten kann beispielsweise in einem „gemeinsamen" (unterschiedslosen) Modus arbeiten, der es einem Netzwerkverbindungsgerät des Knotens ermöglicht, jedes Datenpaket, das in seiner Vollständigkeit an diesem bestimmten Knoten ankommt, abzufangen und zu lesen.
Aufgrund von Überwachen von benachbarten Knoten werden wahrscheinlich mehrere Mitteilungen von verschiedenen Quellen (das heißt, Knoten) für jede Verbindung eingereicht. So kann beispielsweise der Knoten 102(3) eine Mitteilung 802(2) von dem Knoten 102(2) erhalten, die die Netzwerkleistung von dem Knoten 102(2) ebenso wie die Netzwerkleistung der Knoten 102(1), 102(n) beschreibt. Die Klammerangaben, die mit den Referenznummern der Mitteilungen in 8 verwendet werden, werden ausgewählt, um die Übereinstimmung der Mitteilung mit ihrem jeweiligen Knoten, beispielsweise Knoten 102(2) und Mitteilung 802(2) anzuzeigen.
Der Knoten 102(3) enthält die Daten der Netzwerkleistung von der Mitteilung 802(2) (die unsichtbar in 8 dargestellt ist) in der Mitteilung 802(3), die für die Kommunikation zu dem Manager-Knoten 102(N) erstellt wird. Die Mitteilung 802(3) kann auch Daten der Netzwerkleistung enthalten, die durch den Knoten 102(3) durch Überwachen der Knoten 102(2), 102(1) gewonnen werden. In einer Implementierung wird die Mitteilung 802(3) durch die Ausführung eines Agenten-Moduls zum Entfernen von redundanten Informationen optimiert. So kann beispielsweise das Agenten-Modul des Knotens 102(3) Informationen entfernen, die konsistent sind und in den jeweiligen Mitteilungen 802(2), 802(3) durch die Knoten 102(2), 102(3) wiederholt werden, und Daten, die die Inkonsistenzen in den Daten beschreiben, beibehalten. Auf die gleiche Weise kann der Knoten 102(n) das Erfassungs-Modul 114(n) zum Gewinnen der Daten der Netzwerkleistung von den Knoten 102(2), 102(3) ausführen. Die Daten der Netzwerkleistung werden als eine Mitteilung 802(n) für die Kommunikation zu dem Manager-Knoten 102(N) konfiguriert.
Die redundanten Mitteilungen können durch den Manager-Knoten 102(N) zum Erfassen von einer oder mehreren Inkonsistenzen in der Netzwerkleistung verwendet werden. So können beispielsweise die Mitteilungen 802(2), 802(3) durch die Ausführung des Säuberungs-Moduls 120(N) durch den Manager-Knoten 102(N) miteinander verglichen werden, um Inkonsistenzen in den hierin beschriebenen Daten der Netzwerkleistung zu suchen. Die Inkonsistenzen können auf verschiedenerlei Weise gesucht werden, ein Beispiel davon ist in der folgenden Figur beschrieben.
9 ist ein Ablaufdiagramm, das eine Vorgehensweise 900 in einer exemplarischen Implementierung darstellt, bei der Mitteilungen, die benachbarte Knoten beschreiben, miteinander verglichen werden, um einen sich fehlerhaft verhaltenden Knoten in einem Netzwerk zu lokalisieren. In dieser Implementierung identifiziert die Vorgehensweise 900 die sich fehlerhaft verhaltenden Knoten als den minimalen Satz von Knoten, die die Unstimmigkeit in den Mitteilungen erklären können.
In der in Bezug auf 9 beschriebenen Vorgehensweise 900 kann ein Sendeknoten i eine Anzahl von Paketen, die gesendet wird und eine Anzahl von MAC-Ebenen-Bestätigungen, die für eine gerichtete Verbindung I empfangen wird, als (sent_i(l), ack_i(l)) mitteilen. Ein Empfangsknoten j teilt die Anzahl von Paketen, die auf der Verbindung empfangen werden, als recv_j(l) mit. Darüber hinaus teilt der unmittelbare Nachbar k des Sende- oder des Empfangsknotens auch die Anzahl der Pakete und MAC-Ebenenen-Bestätigungen, die auf der Verbindung gesendet oder empfangen werden als (sent_k(l), recv_k(l), ack_k(l)) mit. Eine Inkonsistenz in den Mitteilungen wird so wie in einem der folgenden Fälle definiert.
In dem Entscheidungsblock 902 wird eine Feststellung dahingehend getroffen, ob eine Anzahl von Paketen, die auf einer Verbindung empfangen wird, so wie dies durch ihr Ziel mitgeteilt wird, signifikant höher ist (so wie dies durch einen Schwellenwert beschrieben ist) als die Anzahl von Paketen, die auf derselben Verbindung gesendet wird, so wie dies durch seine Quelle mitgeteilt wird. Das heißt, für die Verbindung l von Knoten i zu Knoten j und einen gegebenen Schwellenwert t, wird die folgende Feststellung unternommen: recvj(l) – senti(l) > t
Der Schwellenwert t wird verwendet, da die Kommunikation der Mitteilungen durch die Berichte durch die jeweiligen Knoten typischerweise nicht synchronisiert wird. Wenn die Anzahl der empfangenen Pakete signifikant höher ist als die Anzahl der gesendeten Pakete, wird eine Inkonsistenz in den Mitteilungen festgestellt, die auf ausführlichere Weise in Bezug auf Block 912 beschrieben wird. Wenn die Anzahl der durch die jeweiligen Knoten gesendeten und empfangen Pakete übereinstimmt, fährt die Vorgehensweise 900 mit Block 904 fort.
In dem Entscheidungsblock 904 wird eine Feststellung dahingehend getroffen, ob eine Anzahl von über eine Verbindung gesendeten MAC-Ebenen-Bestätigungen, wie durch ihre Quelle mitgeteilt wird, einer Anzahl von Paketen entspricht, die auf dieser Verbindung empfangen wurden, wie dies durch ihr Ziel mitgeteilt wird. Mit anderen Worten bedeutet dies, dass für die Verbindung l von dem Knoten i zu dem Knoten j und unter einem gegebenen Schwellenwert t die folgende Beziehung festgestellt wird: |ackj(l) – recvj(l)| > t
Wenn dementsprechend die Anzahl der Bestätigungen nicht mit der Anzahl der empfangenen Pakete übereinstimmt (das heißt, annähernd ist) (Block 904), wird eine Inkonsistenz in den Mitteilungen bemerkt. Wenn die Anzahl der Bestätigungen mit der Anzahl der empfangenen Pakete übereinstimmt (Block 904), fährt die Vorgehensweise 900 mit Block 906 fort.
In dem Entscheidungsblock 906 wird eine Feststellung dahingehend getroffen, ob eine Anzahl von auf einer Verbindung empfangenen Pakete, so wie dies durch einen Nachbar ihres Zieles mitgeteilt wird, signifikant höher ist als die Anzahl der auf derselben Verbindung gesendeten Pakete, so wie dies durch ihre Quelle mitgeteilt wird. Das heißt, für die Verbindung l von dem Knoten i zu dem Knoten j, in der der Nachbar des Knotens j der Knoten k ist, und unter einem gegebenen Schwellenwert, wird die folgende Beziehung festgestellt: recvk(l) sentj(l) > t
Wenn dementsprechend die Anzahl der empfangenen Pakete mit der Anzahl der gesendeten Pakete übereinstimmt (das heißt, annähernd gleich ist) (Block 906), wird eine Inkonsistenz in den Mitteilungen festgestellt. Anderenfalls fährt die Vorgehensweise 900 mit Block 908 fort.
In dem Entscheidungsblock 908 wird eine Feststellung dahingehend getroffen, ob eine Anzahl von auf einer Verbindung gesendeten Paketen, so wie diese durch einen Nachbar ihrer Quelle mitgeteilt wird, signifikant höher ist als eine Anzahl von auf derselben Verbindung gesendeten Paketen, so wie diese durch ihre Quelle mitgeteilt wird. Mit anderen Worten bedeutet dies, dass für die Verbindung l von dem Knoten i zu dem Knoten j, wobei K der Nachbar von i ist, und unter einem gegebenen Schwellenwert, die folgende Beziehung festgestellt wird: sentk(l) – senti(l) > t
Wie dies in der obenstehenden Gleichung dargestellt ist, wird, wenn die Anzahl der gesendeten Pakete der Anzahl der gesendeten Pakete (Block 908), so wie dies jeweils durch die Quelle und die benachbarten Knoten angezeigt wird, annähernd gleich ist, eine Inkonsistenz in den Mitteilungen festgestellt. Anderenfalls sind die Mitteilungen konsistent (Block 910).
In dem Entscheidungsblock 912 wird eine Feststellung dahingehend getroffen, ob ein Paar von Knoten bereits in dem Inkonsistenzgraph enthalten ist. Wenn dies nicht der Fall ist, werden die Knoten zu einem Inkonsistenzgraph hinzugefügt (Block 914). Wenn das inkonsistente Paar von Knoten bereits in dem Inkonsistenzgraph enthalten ist (Block 912) oder zu dem Inkonsistenzgraph hinzugefügt wurde (Block 914), wird eine Kante zwischen den Knoten in dem Inkonsistenzgraph hinzugefügt (Block 916).
Nachdem jedes der inkonsistenten Paare identifiziert worden ist, wird an dem Block 918 ein kleinster Satz (das heißt, mit der kleinsten Anzahl) von Knoten in dem Inkonsistenzgraph gefunden, der die beobachteten Inkonsistenzen erklären kann. So kann beispielsweise eine Annahme angestellt werden, dass die meisten Knoten in dem Netzwerk zuverlässige Mitteilungen senden. Dementsprechend wird der kleinste Satz von Knoten, der die beobachteten Inkonsistenzen erklären kann, gesucht. Dies kann bei spielsweise dadurch erreicht werden, dass der kleinste Satz von Scheitelpunkten gefunden wird, der den Inkonsistenzgraph bedeckt, wobei die identifizierten Scheitelpunkte die sich fehlerhaft verhaltenen Knoten repräsentieren.
Der kleinste Satz von Scheitelpunkten kann durch die Anwendung eines Vertex Cover[Knotenabdeckung]Problems, von dem bekannt ist, dass es NP-schwer ist, gesucht werden. Es wird ein Greedy-[gieriger]Algorithmus angewendet, der iterativ den Knoten mit den meisten Kanten und den einfallenden Kanten aus einem aktuellen Inkonsistenzgraph so lange heraussucht und entfernt, bis keine Kanten mehr übrig sind.
Zum weiteren Verbessern der Genauigkeit der Inkonsistenz-Erfassung kann eine Historie an Mitteilungen verwendet werden. So kann beispielsweise an dem Block 920 eine neue Mitteilung hinzugefügt werden, um den Inkonsistenzgraph ohne Entfernen der vorhergehenden Informationen zu aktualisieren. Inkonsistente Paare von Knoten in der neuen Mitteilung können anschließend unter Verwendung der Blöcke 912 bis 918 der Vorgehensweise 900 verarbeitet werden. So kann beispielsweise derselbe gierige Algorithmus des Blockes 918 erneut angewendet werden, um sich fehlerhaft verhaltende Knoten zu identifizieren.
Was-Wenn-Analyse
In den vorhergehenden Abschnitten wurden Fehler selektiv in eine Netzwerk-Simulation eingespeist, um zu identifizieren, welche Fehler, wenn es welche gibt, eine Differenz zwischen der erwarteten und der beobachteten Netzwerkleistung verursacht haben. Die Netzwerk-Simulation kann darüber hinaus auch zum Durchführen einer „Was-Wenn"-Analyse zum Verbessern des Betriebes des Netzwerkes verwendet werden. Die Was-Wenn-Analyse ermöglicht es dem Manager-Modul, wenn dies ausgeführt ist, die Auswirkung von möglichen Netzwerk- und Knotenkonfigurationen auf die Netzwerkleistung zu bestimmen. Das Ergebnis der Was-Wenn-Analyse ist ein Satz von Maßnahmen, der es dem Manager-Modul ermöglicht, das Netzwerk auf effiziente Weise zu betreiben, so wie beispielsweise dadurch, dass das Agenten-Modul auf ausgewählten Knoten in dem Netzwerk veranlasst wird, den jeweiligen Knoten entsprechend zu konfigurieren.
So kann die Was-Wenn-Analyse beispielsweise durch die Verwendung einer tracegesteuerten Online-Simulation, wie vorangehend beschrieben, durchgeführt werden. In der folgenden Diskussion werden exemplarische Traces identifiziert, die so erfasst werden können, dass sie den Simulator (beispielsweise den Simulator 118(N) aus 2) steuern können. So kann der Simulator beispielsweise zum Bereitstellen einer Netzwerk-Simulation eines realen Netzwerkes verwendet werden. Die Netzwerk-Simulation kann erneut konfiguriert sein, um verschiedene Knoten- und Netzwerkkonfigurationen zu testen, und um zu bestimmen, welche Konfigurationen die beste Netzwerkleistung insgesamt für die vorhandenen Verkehrsbedingungen liefert. Das Manager-Modul kann anschließend einen Satz von Maßnahmen für die Implementierung durch bestimmte Knoten in dem Netzwerk auf Basis der Konfiguration bestimmen.
Herkömmliche Verfahren, die für die Was-Wenn-Analyse angewendet wurden, verwendeten vereinfachte Netzwerkmodelle und leiteten die erwartete Leistung analytisch her. Die tracegesteuerte Online-Simulation weist jedoch Vorteile gegenüber der theoretischen Analyse dahingehend auf, dass die Verwendung eines Simulators einen verbesserten Einblick in das Verhalten des Netzwerkes ermöglicht, als es mit einem heuristischen oder theoretischen Verfahren selbst möglich ist. So ist beispielsweise ein betriebsfähiges drahtloses Netzwerk ein komplexes System mit eng miteinander in Beziehung stehenden Komponenten, wie beispielsweise Verkehrsflüssen, Netzwerkprotokollen, Signalverarbeitungsalgorithmen, Hardware, Hochfrequenz- (HF) Ausbreitung und, was den größten Ausschlag gibt, mit der Interaktion zwischen jedem dieser Komponenten. Darüber hinaus kann das Netzwerkverhalten durch die Interaktion zwischen den Knoten innerhalb ihrer jeweiligen Bereiche und durch in der Nähe befindliche Rauschquellen beeinflusst werden. Weder das heuristische noch das theoretische Verfahren erfassen das Verhalten solcher Netzwerke und die Interaktionen zwischen den verschiedenen Komponenten.
10 ist ein Ablaufplan, der eine Vorgehensweise 1000 in einer exemplarischen Implementierung darstellt, in der eine Was-Wenn-Analyse auf Basis einer tracegesteuerten Online-Simulation durchgeführt wird. Die Vorgehensweise 1000 reproduziert auf einer hohen Ebene zunächst ein reales Netzwerk unter Verwendung einer Netzwerk-Simulation. Anschließend werden die Folgen von Modifizierungen in dem Netzwerk, wenn diese in dem realen Netzwerk durchgeführt werden, durch Anwenden jener Ände rungen in der Netzwerk-Simulation zum Quantifizieren der Auswirkungen der Netzwerkleistung bestimmt.
In Block 1002 werden eine oder mehrere einer Vielzahl von Modifizierungen durch die Ausführung des Manager-Moduls ausgewählt. Modifizierungen können auf verschiedenerlei Weise ausgewählt werden. So können durch das Manager-Modul beispielsweise Modifizierungen als ein Fehler erachtet werden, der eine Erhöhung statt eine Verringerung der Netzwerkleistung hervorruft. Die Modifizierungen in solch einem Fall können in dem in 2 dargestellten Fehlerverzeichnis 218 gespeichert werden und auf Basis des Typs geordnet werden. In Block 1004 stellt das Analyse-Modul die Netzwerkeinstellungen eines realen Netzwerkes und einen Satz von Modifizierungen bereit, der die ausgewählten Modifizierungen in einer Netzwerk-Simulation als eine Eingabe enthält.
In Block 1006 wird die erwartete Leistung des Netzwerkes auf Basis der Eingaben vorhergesagt. So kann der Simulator beispielsweise eine Netzwerk-Simulation auf Basis der Netzwerkeinstellungen des realen Netzwerkes und des Modifizierungssatzes erzeugen. Die Netzwerk-Simulation kann anschließend, so wie dies voranstehend beschrieben wurde, dafür verwendet werden, um die Folgen der Modifizierungen in dem realen Netzwerk zu bestimmen.
In dem Entscheidungsblock 1008 wird eine Feststellung dahingehend getroffen, ob die Differenz zwischen der erwarteten Leistung des Netzwerkes der Netzwerk-Simulation und der realen Leistung des realen Netzwerkes größer als ein Schwellenwert ist. So kann die Netzwerk-Simulation beispielsweise eine Ausgabe der Werte der simulierten Netzwerkleistung bereitstellen, die mit den von den in 1 dargestellten Agenten-Modulen 122(n) gewonnenen Werten der realen Netzwerkleistung verglichen werden. Wenn die Differenz zwischen der erwarteten und der realen Netzwerkleistung geringer als der Schwellenwert ist (Block 1008), kann eine neue Modifizierung ausgewählt werden (Block 1002), und die Auswirkung der Modifizierung, wie voranstehend beschrieben, festgestellt werden.
Das Analyse-Modul leitet, wenn dies ausgeführt ist, eine oder mehrere durch die Agenten-Module des Netzwerkes durchzuführenden Maßnahmen zum Implementieren der Modifizierung (Block 1008) her. So kann das Analyse-Modul beispielsweise ein Ver zeichnis mit Maßnahmen, die auf den entsprechenden Modifizierungen abgebildet werden, enthalten. Anschließend kann das Analyse-Modul auf Basis der Modifizierungen die entsprechenden Maßnahmen herleiten.
In Block 1010 stellt das Analyse-Modul eine Kommunikation, die die eine oder mehrere Maßnahmen beschreibt, für die Kommunikation mit den entsprechenden Agenten-Modulen her. Die entsprechenden Agenten-Module können anschließend die jeweiligen Knoten des Netzwerkes dazu veranlassen, die hierin beschriebenen Maßnahmen durchzuführen. Auf diese Weise können die Manager- und Agenten-Module verwendet werden, um eine Was-Wenn-Analyse auf Basis einer tracegesteuerten Online-Simulation auf eine der Fehlererfassung ähnliche Weise durchzuführen. Die Was-Wenn-Analyse kann zum Korrigieren von Fehlern und zum Verbessern der Netzwerkleistung verwendet werden.
In einer weiteren exemplarischen Implementierung wird die Simulation dafür verwendet, eine in dem Netzwerk vorzunehmende Modifizierung zum Verbessern der Netzwerkleistung zu bestimmen, so wie beispielsweise durch Anwenden eines iterativen Ansatzes zum Durchführen der Was-Wenn-Analyse. Dieser Ansatz ist ähnlich der Simulation, die in Bezug auf die 5 und 7 beschrieben wurde. Dementsprechend könnte ein Verfeinern durch Iteration verwendet werden, wenn mehrere Modifizierungsmaßnahmen erforderlich sind.
11 ist ein Ablaufdiagramm, das eine Vorgehensweise 1100 in einer exemplarischen Implementierung darstellt, in der Modifizierungen in einem Netzwerk auf Basis einer Diagnose eines schadhaften Flusses hergeleitet werden. In Block 1102 wird ein Manager-Modul (beispielsweise ein Manager-Modul 116(N) aus den 1 und 2) ausgeführt, um festzustellen, dass ein oder mehrere Flüsse in dem Netzwerk geringere Durchsatzleistungswerte als ihre entsprechenden Ziel-Durchsatzleistungswerte aufweisen. In Block 1104 stellt das Manager-Modul fest, welcher, wenn es irgendeiner in dem Netzwerk ist, ein „schadhafter Fluss" ist. Ein schadhafter Fluss ist ein Typ von Fehler, dessen Vorhandensein eine ernstzunehmende Verschlechterung der Durchsatzleistung des Netzwerkes verursacht, und der sich von den voranstehenden Fehlern dahingehend unterscheidet, dass der schadhafte Fluss selbst nicht fehlerhaft ist, jedoch nicht gut mit anderen konkurrierenden Flüssen interagiert.
In Block 1106 werden beispielsweise Netzwerkeinstellungen erfasst, die Ziel-Ende-zu-Ende-Anforderungen und das sich in Verwendung befindende Routing-Protokoll beschreiben. Hierbei sollte beachtet werden, dass sich diese Netzwerkeinstellungen von den Traces, die für die Fehlersuche und -beseitigung verwendet werden, unterscheiden, da die Vorgehensweise 1100 untersucht, wie das Netzwerk (beispielsweise Verbindungslasten und Routing) auf die Änderungen in der Netzwerkkonfiguration reagieren wird.
In Block 1108 wird die Auswirkung auf die gesamte Durchflussleistung des Netzwerkes auf Basis des Entfernens eines jeden Flusses aus der Netzwerk-Simulation überprüft, wobei pro Mal jeweils einer entfernt wird. In einer Implementierung wird ein schadhafter Fluss als der eine Fluss identifiziert, dessen Entfernung die signifikanteste Gesamtverbesserung der Netzwerkleistung ergibt. So ist beispielsweise in 12 ein Netzwerk 1200 dargestellt, das eine Vielzahl von Flüssen 1202 bis 1216 enthält. Fluss acht 1216 (in 12 als F₈ dargestellt) kreuzt jeden der anderen Flüsse 1202 bis 1214 in dem dargestellten Netzwerk. Dementsprechend kann das Entfernen von Fluss acht 1208 in dem größten Anstieg der Durchflussleistung resultieren, ganz anders als beim Entfernen irgendeines der anderen Flüsse 1202 bis 1214. Mit anderen Worten bedeutet dies, dass das Vorhandensein von Fluss acht 1216 die größte Menge an Schaden an der Leistung des Netzwerkes 1200 verursacht. Auf diese Weise kann eine Modifizierung (beispielsweise das Entfernen oder Reduzieren des Einflusses von Fluss acht 1216 auf andere Flüsse des Systems) in dem Netzwerk 1200 bestimmt werden, welche in dem größten Anstieg der Netzwerkleistung resultiert.
In Block 1110 werden eine oder mehrere Maßnahmen auf Basis der Modifizierung hergeleitet, die zum Verbessern der Netzwerkleistung verwendet wird. Zu den exemplarischen Maßnahmen können die Ratebegrenzung, ein Rerouting (Ersatzwegschaltung) und eine Topologiesteuerung von Fluss acht 1216 gehören. Die Netzwerk-Simulation befähigt das Manager-Modul den Nutzen dieser Maßnahmen genau zu bewerten. So zeigt die folgende Tabelle eine erwartete Durchflussleistung für exemplarische Korrekturvorgänge.
Wie dies in der Tabelle dargestellt ist, führt ein Anstieg der Übertragungsleistung auf 25 dBm von den vier betrachteten exemplarischen Vorgängen (und dem einen Nicht-Vorgang) zu der höchsten Durchflussleistung, da dadurch die Anzahl von Hops, die zum Erreichen eines Zieles benötigt werden, reduziert wird. Auf Basis dieser Ergebnisse stellt das Manager-Modul eine Kommunikation her, die einen oder mehrere der Agenten auf den jeweiligen Knoten dazu veranlasst, die Leistung zu erhöhen, um das Problem mit der Netzwerkleistung zu mildern.
Exemplarische System-Implementierung
Ein Beispiel des beschriebenen Systems wurde auf einer WINDOWS XP-Plattform (WINDOWS XP ist eine Marke der Microsoft Corp., Redmond WA) implementiert. Komponenten der exemplarischen Implementierung, Designprinzipien und ihre Leistungsmerkmale werden in diesem Abschnitt beschrieben.
Das exemplarische System enthält in diesem Beispiel zwei separate Komponenten: Agenten-Module und Manager-Module. Wie vorangehend in Bezug auf 1 beschrieben wurde, wird das Agenten-Modul auf einem jeden Knoten des Netzwerkes zum Mitteilen lokaler Daten entweder periodisch oder auf Abfrage ausgeführt. Ein Manager-Modul erfasst die relevanten Daten von den Agenten-Modulen und wird zum Analysieren der Daten, so wie beispielsweise durch die Ausführung eines enthaltenen Analyse-Moduls, so wie in Bezug auf 2 beschrieben, ausgeführt.
Das exemplarische System setzt auf Einfachheit und Erweiterbarkeit beruhende Designprinzipien um. So können beispielsweise die für das Überwachen und Verwalten gesammelten und verbreiteten Daten in Leistungszähler eingebracht werden, die von WINDOWS unterstützt sind (WINDOWS ist eine Marke der Microsoft Corp., Redmond WA). Leistungszäher können als durch Kategorien (Name, Wert) gruppierte Paare bereitgestellt sein.
Darüber hinaus ist das beschriebene system erweiterbar. Das Hinzufügen zu den Daten, die überwacht werden, beinhaltet die Erstellung einer neuen Kategorie von Leistungszählern und das Schreiben eines Moduls, das die Werte des Leistungszählers aktualisiert, wenn sich die Informationen ändern. Leistungsdaten in Bezug auf das Übertragungssteuerungsprotokoll (TCP), das Benutzer-Datengramm-Protokoll (UDP), das Internet-Protokoll (IP) und die WRAPI können mit wenig zusätzlichem Aufwand in das System integriert werden.
Die Werte in diesen Leistungszählern können nur lesbar oder beschreibbar sein. Beschreibbare Zähler bieten beispielsweise eine Möglichkeit für einen nicht-autorisierten Manager-Knoten, die Werte des Verhaltens eines Knoten zu ändern und zu beeinflussen, um Probleme zu beheben oder dezentral Experimente zu initiieren, so wie beispielsweise durch die Kommunikation eines Manager-Moduls mit einem Agenten-Modul, die auf verschiedenen jeweiligen Knoten ausgeführt sind.
Jeder Manager-Knoten kann darüber hinaus mit einer Grafikbenutzerschnittstelle (GUI) 1300 ausgestattet sein, von dem ein Beispiel in 13 dargestellt ist, um mit den Verwaltern des Netzwerkes zu kommunizieren. Durch die GUI kann ein Verwalter das Netzwerk visualisieren ebenso wie Verwaltungsanforderungen durch das Manager-Modul erstellen. Die GUI 1300 zeigt eine Topologie für eine exemplarische Netzwerk-Testumgebung an. In diesem Beispiel stellt die GUI 1300 ein Manager-Fenster mit Agenten, die über einer Testumgebung von 23 Knoten angeordnet sind, dar. Das Manager-Modul kann die Topologie auf Basis der relativen Koordinaten der Knoten anzeigen, die entweder direkt gewonnen oder hergeleitet werden. Die GUI 1300 kann es dem Verwalter darüber hinaus auch ermöglichen, einen bestimmten Teil des Netzwerkes für mehr ausführliche Informationen zu vergrößern und auf einen Link zu klicken, um eine Anzeige von Daten der Netzwerkleistung über eine bestimmte Verbindung in einem Tabellenformat zu veranlassen.

Claims

Verfahren zur Erfassung und Diagnose von Fehlern in einem Netzwerk, das umfasst: Erfassen einer Unstimmigkeit im Betrieb eines Netzwerks durch: Zuführen von Daten, die das Netzwerk beschreiben, als Netzwerk-Simulation (210), so dass die Netzwerk-Simulation eine Schätzung der Netzwerkleistung (504) bereitstellt; und Feststellen, ob sich die Schätzung der Netzwerkleistung von der beobachteten Netzwerkleistung des Netzwerks (508) unterscheidet; und Diagnostizieren einer Hauptursache der Unstimmigkeit durch Einspeisen eines oder mehrerer einer Vielzahl von den Fehlern in die Netzwerk-Simulation, bis sich die Schätzung der Netzwerkleistung der beobachteten Netzwerkleistung (510, 512, 514, 516) nähert.
Verfahren nach Anspruch 1, wobei das Feststellen einschließt, dass ermittelt wird, ob sich die Schätzung der Netzwerkleistung um mehr als ein entsprechender Schwellenwert von der beobachteten Netzwerkleistung des Netzwerks unterscheidet.
Verfahren nach Anspruch 1, wobei das Diagnostizieren einschließt: Umwandeln des Unterschiedes zwischen der geschätzten und der beobachteten Netzwerkleistung in einen Fehlerbetrag; und Feststellen, ob der Fehlerbetrag der Netzwerksimulation sich so bewegt, dass er sich der beobachteten Netzwerkleistung des Netzwerks nähert.
Verfahren nach Anspruch 1, wobei das Diagnostizieren einschließt: Umwandeln der Differenz zwischen der geschätzten und der beobachteten Netzwerkleistung in einem Fehlerbetrag; Feststellen, ob der Fehlerbetrag geringer ist als ein entsprechender Schwellenwert; und wenn der Fehlerbetrag geringer ist als der entsprechende Schwellenwert, Entfernen eines entsprechenden Fehlers aus einem Fehlersatz, der als eine Eingabe in die Netzwerk-Simulation verwendet wird.
Verfahren nach Anspruch 1, wobei das Diagnostizieren einschließt: Stellen einer Anfangsdiagnose, um einen Anfangs-Fehlersatz zu erzeugen; und Iteratives Verfeinern des Anfangs-Fehlersatzes, um zu einem aktuellen Fehlersatz zu gelangen, der, wenn er als eine Eingabe durch die Netzwerk-Simulation verwendet wird, bewirkt, dass sich die Schätzung der Netzwerkleistung, die durch die Netzwerk-Simulation bereitgestellt wird, der beobachteten Netzwerkleistung nähert.
Verfahren nach Anspruch 1, wobei das Netzwerk ein drahtloses Multi-Hop-Netzwerk ist.
Verfahren nach Anspruch 1, wobei das Netzwerk ein verdrahtetes Netzwerk ist.
Verfahren nach Anspruch 1, wobei die Daten eine Route beschreiben, die durch eine Reihe von Hops gebildet wird, die ein Datenpaket durch das Netzwerk zwischen einem Ursprungsknoten und einem Zielknoten des Netzwerkes durchläuft.
Verfahren nach Anspruch 1, wobei die Daten Trace-Daten enthalten, die aus der Gruppe ausgewählt werden, die besteht aus: Netzwerk-Topologie einschließlich Routing; Verkehrsstatistik; physikalisches Medium; und Netzwerkleistung.
Ein oder mehrere computerlesbare/s Medium/Medien, das/die durch Computer ausführbare Befehle umfasst/umfassen, die, wenn sie durch einen Computer ausgeführt werden, den Computer anweisen, das Verfahren nach Anspruch 1 durchzuführen.
System zur Erfassung und Diagnose von Fehlern in einem Netzwerk, das eine Vielzahl von Knoten (102) umfasst, die kommunikativ miteinander gekoppelt sind, um das Netzwerk zu bilden, wobei: ein oder mehrere der Knoten ein Agenten-Modul (112(N)) enthalten, das auf ihnen ausgeführt werden kann, um: Netzwerkeinstellungen zu erfassen; und eine Kommunikation herzustellen, die die Netzwerkeinstellung zur Kommunikation über das Netzwerk einschließt; und wobei der wenigstens eine Knoten ein Manager-Modul (116(N)) enthält, das darauf ausgeführt werden kann, um: die Kommunikation zu empfangen; eine Simulation des Netzwerks auf Basis der aus der Kommunikation gewonnenen Netzwerkeinstellungen zu erzeugen, so dass sie die Netzwerk-Simulation eine Schätzung der Netzwerkleistung bereitstellt; und einen Fehler (510, 512, 514, 516) in der Netzwerkfunktion zu erfassen, indem eine Schätzung der Netzwerkleistung mit einer Beobachtung der Netzwerkleistung des Netzwerks (508) verglichen wird.
System nach Anspruch 11, wobei wenigstens zwei der Knoten ein entsprechendes Manager-Modul enthalten.
System nach Anspruch 11, wobei jeder der Knoten ein entsprechendes Agenten-Modul enthält.
System nach Anspruch 11, wobei das Manager-Modul des Weiteren so ausgeführt werden kann, dass es einen Korrekturvorgang auf Basis des erfassten Fehlers herleitet; und das Agent-Modul veranlasst, den Korrekturvorgang durchzuführen.
System nach Anspruch 11, wobei der Fehler im Netzwerkbetrieb erfasst wird, indem festgestellt wird, ob eine Differenz zwischen der Schätzung und der Beobachtung größer ist als ein entsprechender Schwellenwert.
System nach Anspruch 11, wobei das Manager-Modul des Weiteren ausgeführt werden kann, um den Fehler zu diagnostizieren, indem ein oder mehrere einer Vielzahl der Fehler in der Netzwerk-Simulation eingespeist werden, bis sich die Schätzung der Beobachtung nähert.
System nach Anspruch 11, wobei das Manager-Modul des Weiteren ausgeführt werden kann, um den Fehler zu diagnostizieren, indem es eine Differenz zwischen der Schätzung und der Beobachtung in einen Fehlerbetrag umwandelt; und feststellt, ob der Fehlerbetrag, die durch die Netzwerk-Simulation bereitgestellte Schätzung so bewegt, dass sie sich der Beobachtung nähert.
System nach Anspruch 11, wobei das Manager-Modul des Weiteren so ausgeführt werden kann, dass es den Fehler diagnostiziert, indem es: eine Differenz zwischen der Schätzung und der Beobachtung in einen Fehlerbetrag umwandelt; und feststellt, ob der Fehlerbetrag geringer ist als ein entsprechender Schwellenwert; und wenn der Fehlerbetrag geringer ist als der entsprechende Schwellenwert, einen entsprechenden Fehler aus einem Fehlersatz entfernt, der als eine Eingabe durch die erzeugte Simulation zum Produzieren der Schätzung verwendet wird.
System nach Anspruch 11, wobei das Manager-Modul des Weiteren ausgeführt werden kann, um den Fehler zu diagnostizieren, in dem es: eine Anfangsdiagnose stellt, um einen Anfangs-Fehlersatz zu erzeugen; einen Anfangs-Fehlersatz iterativ verfeinert, um zu einem aktuellen Fehlersatz zu gelangen, der, wenn er als eine Eingabe durch die Netzwerk-Simulation verwendet wird, bewirkt, dass sich die Schätzung der Beobachtung nähert.
System nach Anspruch 11, wobei das Netzwerk ein Maschen-Netzwerk ist.
System nach Anspruch 11, wobei die Netzwerkeinstellungen eine Route beschreiben, die durch eine Reihe von Hops gebildet wird, die ein Datenpaket durch das Netzwerk zwischen einem Ursprungsknoten und einem Zielknoten des Netzwerkes durchläuft.
Knoten (102) in einem Netzwerk mit einer Einrichtung zur Erfassung und Diagnose von den Fehlern in dem Netzwerk, wobei der Knoten umfasst: eine Einrichtung zum Verwalten von Betrieb (102(N)) eines Netzwerks mit einer Vielzahl von Einrichtungen zum Leiten von Datenpakten, wobei: jede Leiteinrichtung kommunikativ mit einer anderen der Leiteinrichtung gekoppelt ist; und die Verwaltungseinrichtung des Weiteren eine Einrichtung enthält, die: Netzwerkeinstellungen, die von dem Netzwerk gewonnen werden, einer Einrichtung zum Simulieren des Netzwerks (210) bereitstellt; einen Ausgang von der Simuliereinrichtung empfängt, der Netzwerkleistung des Netzwerks schätzt; und einen Fehler (510, 512, 514, 516) durch Vergleichen des Ausgangs mit einer Beobachtung der Netzwerkleistung des Netzwerks (508) erfasst.
Knoten nach Anspruch 22, wobei die Verwaltungseinrichtung des Weiteren eine Einrichtung zum Diagnostizieren des Fehlers enthält.
Knoten nach Anspruch 22, wobei das Netzwerk ein Maschen-Netzwerk ist.
Knoten nach Anspruch 22, wobei die Verwaltungseinrichtung des Weiteren eine Einrichtung zum Herleiten eines Korrekturvorgangs auf Basis des erfassten Fehlers enthält.