DE69920886T2 - Kapazitätszuweisungssystem unter verwendung von halbautonomen netzwerkkomponenten zur durchführung und steuerung eines übertragungsprogramms - Google Patents

Kapazitätszuweisungssystem unter verwendung von halbautonomen netzwerkkomponenten zur durchführung und steuerung eines übertragungsprogramms Download PDF

Info

Publication number
DE69920886T2
DE69920886T2 DE69920886T DE69920886T DE69920886T2 DE 69920886 T2 DE69920886 T2 DE 69920886T2 DE 69920886 T DE69920886 T DE 69920886T DE 69920886 T DE69920886 T DE 69920886T DE 69920886 T2 DE69920886 T2 DE 69920886T2
Authority
DE
Germany
Prior art keywords
network
schedule
implementation
transmission
component
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69920886T
Other languages
English (en)
Other versions
DE69920886D1 (de
Inventor
R. Jeffrey JACOBSON
Ronald Nau
Scott Swanson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
INNOVATIVE COMM TECHNOLOGIES I
Innovative Communications Technologies Inc
Original Assignee
INNOVATIVE COMM TECHNOLOGIES I
Innovative Communications Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by INNOVATIVE COMM TECHNOLOGIES I, Innovative Communications Technologies Inc filed Critical INNOVATIVE COMM TECHNOLOGIES I
Application granted granted Critical
Publication of DE69920886D1 publication Critical patent/DE69920886D1/de
Publication of DE69920886T2 publication Critical patent/DE69920886T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W16/00Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/18Network planning tools
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0896Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14Network analysis or design
    • H04L41/142Network analysis or design using statistical or mathematical methods
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876Network utilisation, e.g. volume of load or congestion level
    • H04L43/0894Packet rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Human Computer Interaction (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

  • Gebiet der Erfindung
  • Diese Erfindung bezieht sich auf Kommunikationsverfahren und -vorrichtungen, welche eine Netzwerkverwaltung, Bandbreiten- und Pfadsteuerung in einem heterogenen Netzwerk, welches aus Einrichtungen und Übertragungswegen vielfältiger Anbieter zusammengesetzt sein kann. Im Speziellen betrifft das Kommunikationssystem semiautonome Implementierungskomponenten innerhalb einer Verwaltungshierarchie, um Elemente vielfältiger Anbieter global zu verwalten, während lokale Netzwerkanforderungen erfüllt werden.
  • Hintergrund der Erfindung
  • Seit vielen Jahren versuchen Telekommunikationsdienste, eine Bandbreitenbelegung zwischen Netzwerkelementen zu optimieren oder zu minimieren. Seit dem modernen Kommunikationszeitalter, hervorgerufen durch die Theorien von Shannon, sind sich Telekommunikationsingenieure in hohem Maße der Notwendigkeit bewusst, optimale oder zumindest gute Lösungen für Bandbreiten-Zuordnungsprobleme in Punkt-zu-Punkt- und Punkt-zu-Mehrpunkt-Netzwerken zur Verfügung zu stellen.
  • In drahtlosen Kommunikationssystemen können Lösungen für Bandbreiten-Zuordnungsprobleme in der Art und Weise gesehen werden, in der Daten moduliert werden, um endliche Ressourcen "aufzuteilen". Beispielsweise sieht ein Zeitvielfachzugriff ("TDMA") eine Einrichtung für mehrere Stationen vor, um auf Zeitschlitze auf Satellitenträgern zuzugreifen und auf diese Weise Bandbreitenressourcen "aufzuteilen". Ein Codemultiplex-Vielfachzugriff ("CDMA") sieht eine Einrichtung vor, um Codemultiplextechniken (Zeit- und Frequenzmodulation) für Mehrpunktzugriff in einem vorbestimmten Frequenzbandbereich zu verwenden und auf diese Weise Bandbreitenbereich "aufzuteilen". In ähnlicher Weise stellt ein Frequenzvielfachzugriff ("FDMA") eine Einrichtung zum Aufteilen und Teilen einer endlichen Bandbreitenressource bereit.
  • Weiter ausgearbeitete Schemata, um die Bandbreite in Übereinstimmung mit einem vorbestimmten Zeitplan und Modulationsplan zuzuordnen, können in dem US-Patent Nr. 5,592,470 von Rudrapatna et al., ("Rudrapatna"), ausgegeben am 7. Januar 1997 (das "Rudrapatna-Patent"), eingesehen werden. Das Rudrapatna-Patent betrifft ein terrestrisches Mikroanschlussnetzwerk, welches Bandbreite an terrestrische Mikroanschlussempfänger zuweist, basierend auf einem vorbestimmten Zeitplan und Modulationsplan. Der vorbestimmte Zeitplan und der Plan können nachfolgend durch dynamische Anforderungen an die Mikroanschlüsse geändert werden. Das Netzwerk kann dann die dynamischen Anforderungen erfüllen, indem Kanäle zwischen Modulations- und Polarisationsschemata in vorbestimmter Anzahl verschoben werden.
  • In drahtlosen Netzwerken benötigen gewisse Kommunikationsverbindungen mehr Bandbreiten- und Leistungsressourcen als andere. Dies ist notwendig, um einen festgelegten Informationsdurchsatz aufrechtzuerhalten, um geeignete Servicestufen bereitzustellen, oder aufgrund verschiedener Standortkonfigurationen (z.B. verschiedenen Antennengrößen). Jedes Mal, wenn eine Änderung von Netzwerkressourcen-Zuordnungen notwendig ist, um wechselnde Verkehrsanforderungen zu erfüllen, kann ein neuer Übertragungsplan implementiert werden oder nicht. Dies kann das Programmieren, das Übermitteln und das Empfangen von Kommunikationseinrichtungen, z.B. Verstärkern, Modulatoren und Demodulatoren, notwendig machen, um die neuen Ressourcenzuweisungen zu unterstützen. Diese und andere Probleme der Bandbreitenzuordnung in einem Mehrfachanbieternetzwerk werden durch die vorliegende Erfindung behandelt.
  • Die kanadische Patentanmeldung CA-A-2216672 offenbart ein mobiles Satellitensystem, welches ein Netzwerkingenieur/Systemtechnik-(NE/SE-)System aufweist. Das NE/SE führt das Verfahren zum Erzeugen von Frequenzplänen für das Satellitensystem aus. Das NE/SE weist ein Netzwerkoperationszentrum (NOC) an, benötigte Konfigurationsänderungen auszuführen.
  • Zusammenfassung der Erfindung
  • Gemäß einem ersten Gesichtspunkt der vorliegenden Erfindung wird ein System zum Steuern eines Netzwerks von Kommunikationsvorrichtungen 44, 46, 48, 50, 51, 56, 57, 58 vorgesehen, wobei jede Vorrichtung, welche in dem Netzwerk gemäß einem Sendeplan kommuniziert, welcher durch eine Verwaltungskomponente MC des Systems spezifiziert wird, wobei das System umfasst: eine Verwaltungskomponente, welche den Sendeplan für alle Kommunikationsvorrichtungen in dem Netzwerk steuert; und eine oder mehrere Implementierungskomponenten IC, welche eine oder mehrere Kommunikationsvorrichtungen in dem Netzwerk gemäß Anweisungen von der Verwaltungskomponente steuert, wobei jede Implementierungskomponente aufweist: eine Empfangseinrichtung zum Empfangen von mindestens einem Sendeplan von der Verwaltungskomponente; und eine Ausgabeeinrichtung zum Ausgeben eines Befehls an eine Kommunikationsvorrichtung, welche durch die Implementierungskomponente gesteuert wird, um den Sendeplan anstatt des Sendeplans, welcher im Moment durch die Kommunikationsvorrichtung verwendet wird, zu implementieren, wobei das System dadurch gekennzeichnet ist, dass: der Sendeplan eine zeitplangemäße Implementierungszeit zum Ändern des Sendeplans für eine oder mehrere Vorrichtungen in dem Netzwerk aufweist; jede Implementierungskomponente des Weiteren eine Decodierungseinrichtung zum Decodieren der zeitgemäßen Implementierungszeit für den Sendeplan aus dem Sendeplan, welcher durch die Empfangseinrichtung empfangen wird, aufweist; und die Implementierungskomponente den Sendeplan zu der festgelegten Implementierungszeit implementiert.
  • Gemäß einem zweiten Gesichtspunkt der vorliegenden Erfindung wird ein Verfahren zum Steuern eines Netzwerks von Kommunikationsvorrichtungen bereitgestellt, wobei jede Vorrichtung in dem Netzwerk gemäß einem Sendeplan kommuniziert, welcher durch eine Verwaltungskomponente des Systems festgelegt wird, wobei das Verfahren die Schritte aufweist: Empfangen von mindestens einem Sendeplan von der Verwaltungskomponente, welcher basierend auf einer Leistungsauswertung eines bestehenden Sendeplans festgelegt wird; und Ausgeben eines Befehls an eine Kommunikationsvorrichtung, welche durch eine Implementationskomponente gesteuert wird, um den Sendeplan anstelle eines Sendeplans zu implementieren, welcher durch diese Kommunikationsvorrichtung momentan verwendet wird, dadurch gekennzeichnet, dass: das Verfahren des Weiteren aufweist: Decodieren einer zeitgemäßen Implementierungszeit für den Sendeplan aus dem empfangenen Sendeplan, wobei die zeitgemäße Implementierungszeit zum Ändern des Transmissionsplans für eine oder mehrere Vorrichtungen in dem Netzwerk vorgesehen ist; und Implementieren des Sendeplans zu der festgelegten Implementierungszeit.
  • Die Verfahren und Vorrichtungen, welche hierin offenbart sind, können verfügbare Übertragungsressourcen in Punkt-zu-Punkt-, Mehrpunkt und Rundfunk-drahtlosen Netzwerken zuordnen und neu zuordnen. Dies kann auf der Basis von Informationskapazitäts- und Verbindungsanforderungen zwischen Sendern und Empfängern von Kommunikationsverbindungen zu der Zeit der Zuweisung oder Neuzuweisung erreicht werden. Das System kann ebenso einen Netzwerkadministrator mit neuartigen Werkzeugen und automatisierten Verfahren zum Festlegen und Implementieren von Netzwerksendeplänen und zum Ändern von Zuweisungsentscheidungen, wenn die Verkehrsanforderungen sich ändern, bereitstellen.
  • Das System kann Werkzeuge bereitstellen, um effizient Senderessourcen zuzuweisen. Diese Werkzeuge helfen Kommunikationsverbindungen zu implementieren, welche drahtlose Netzwerke ausbilden. Eine optimale Ressource für eine "Gute-Anpassung"-Zuweisung wird erreicht, wenn Netzwerkbenutzer gerade genug Informationssendekapazität haben, um ihre Aufgaben auszuführen. Ein Weg, um optimale oder gute Senderessourcen-Zuweisungen in einem drahtlosen Netzwerk zu erreichen, ist, Benutzungsmuster von Netzwerkbenutzern zu analysieren und eine Kapazität gemäß einem zeitlich wechselnden Zeitplan zuzuweisen.
  • Durch Analysieren von Netzwerkbenutzungsmustern kann eine Verwaltungskomponente einen Sendeplan-Zeitplan bestimmen, welcher die Satellitenbandbreite, welche dem Netzwerk zur Verfügung steht, basierend auf Ereignisnutzungsmustern (historical usage patterns) effizient zuweisen. Die Verwaltungskomponente kann automatisch einen Sendeplan-Zeitplan zeitgemäß festlegen und implementieren. Wenn die Netzwerkbenutzeranforderungen sich ändern, kann die Verwaltungskomponente den zeitplangemäßen Sendeplan aktualisieren oder anpassen, um die neuen Anforderungen zu erfüllen.
  • Das System kann die Implementierung der Sendepläne durch Neuprogrammieren des Systems automatisieren, wenn vorbestimmte Parameter erreicht werden. Z.B. kann die Verwaltungskomponente einen Sendeplan aus einer Ereignisauswertung von Bandbreitenanforderungen zwischen Stationen bestimmen. Dieser Sendeplan kann automatisch in dem Netzwerk eingesetzt werden. Die Verwaltungskomponente kann dann Netzwerkzuweisungsanforderungen überwachen und analysieren, um einen neuen Sendeplan zu bestimmen. Der neue Sendeplan kann dann automatisch in dem Netzwerk eingesetzt werden, wenn vorbestimmte Parameter erreicht werden, etwa wenn eine mittlere Änderung in der Bandbreite, z.B. die Bandbreite in Benutzung/Bandbreite nach dem Sendeplan, einen vorbestimmten Wert übersteigt oder falls eine vorbestimmte Zeitdauer verstrichen ist (transpired). Die Sendepläne können als generische Netzwerkbefehle weitergeleitet werden und in entsprechende Einrichtungsparameter und zugehörige Steuerbefehle übersetzt werden, wie es zum Rekonfigurieren von Netzwerkeinrichtungselementen benötigt wird. Somit kann das System Einrichtungskonfigurationen erstellen und an Netzwerkelemente verteilen, zum Neuprogrammieren einer synchronisierten Ausführung zu vorbestimmten Zeiten.
  • Des Weiteren steuert und legt das System die Bandbreite zwischen den Netzwerkelementen zeitplangemäß fest, um andere Netzwerkfaktoren, wie ökonomische Beschränkungen, zu beachten. In einem drahtlosen Kommunikationsnetzwerk sollte jeder Kommunikationsträger gerade genug Bandbreite und Leistung aufweisen, die notwendig ist, um den Bedarf seiner korrespondierenden Benutzer zu erfüllen. Obwohl die optimale Ressourcenzuweisung das oberste Ziel ist, kann eine suboptimale Zuweisung toleriert werden, wenn ökonomische Bedingungen die Senderessourcen möglicherweise auf endliche Mengen beschränken. Beispielsweise kann eine dynamische Bandbreitenanforderung an einer Netzwerkstation eine Erhöhung einer Bandbreitenzuweisung von der Station benötigen, beispielsweise wenn die Warteschlangenlänge einen vorbestimmten Wert an dem Stationsschalter (Switch) erreicht. Die Station kann zusätzliche verfügbare Kapazität auf einer verfügbaren Kommunikationsverbindung aufweisen, jedoch übersteigt die Kapazitätszunahme der Verbindung bei weitem die benötige Bandbreite, um die Länge der Kommunikationswarteschlange zu reduzieren. Des Weiteren können die finanziellen Kosten für die Kapazitätszunahme die Kosten des Wartens auf eine Netzwerkbenutzung übersteigen, um die Länge der Warteschlange zu verringern. Das System würde in diesem Fall dem Netzwerk erlauben, die Benutzerdaten aufzustauen und einen Fluss zu steuern, bevor das System zusätzliche Kapazität zuweisen würde. Das System stellt Verfahren zum Nutzen endlicher Senderessourcen bereit, indem eine erneute Zuweisung von Leistung und Bandbreite so weit ermöglicht wird, wie es nötig ist, um wechselnde Kommunikationsanforderungen in Satellitennetzwerken zu erfüllen. Jedoch sind die Fähigkeiten des Systems auf alle drahtlosen Netzwerke anwendbar, welche als eine Sammlung von Sendern, Senderessourcen und Empfängern modelliert werden können.
  • Das System stellt ein Mittel zum Verwalten einer heterogenen Netzwerkeinrichtung oder einer Netzwerkeinrichtung von vielfältigen Anbietern über heterogene Senderessourcen oder Senderessourcen von vielfältigen Anbietern mit vielfältigen Übertragungswegen zur Verfügung. Solch ein Weg kann über programmierbare C-, Ku- oder Ka-Band-Satellitennetzwerke verlaufen. Andere Pfade können über diskrete Träger auf einem vorprogrammierten Netzwerk, wie dem Inmarsat, dem Globalstar oder Iridium-Satellitensystemen verfügbar sein. Noch weitere Pfade können über dritte beteiligte Medien oder Breitbandnetzwerke, wie dem vorgesehenen Teledesic-Satellitennetzwerk, verfügbar sein. Ein weiterer Pfad kann über ein programmierbares oder verwaltetes Netzwerk, wie dem globalen Satellitensystem Intelsat, verfügbar sein. Damit stellt das System eine Einrichtung zum Festlegen und Verwalten der Kapazität zwischen Netzwerkelementen bereit, wobei das Netzwerk eine Kombination aus einem diskreten Bandbreiten-Zuweisungsnetzwerk, welches durch ein externes System verwaltet wird, einem halbprogrammierbaren Medium oder Breitbandnetzwerk, in dem eine sich ändernde Menge von Bandbreite von einer extern verwalteten Ressource zugewiesen werden kann, und einem voll programmierbaren Netzwerk, wo die Ressource durch eine Netzwerkverwaltungskomponente verwaltet wird, sein kann. Damit stellt das Verwaltungssystem ein nahezu transparentes Mittel bereit, mit welchem ein Betreiber, Nutzer oder Netzwerkelement Anforderungen an das Netzwerk richten kann und das Verwaltungssystem diese Anforderung basierend auf einem Minimalkostenalgorithmus, einer Qualität von Servicepa rametern und vorbestimmten oder zeitlich wechselnden Sendeplänen erfüllen kann.
  • Das beschriebene Verwaltungssystem kann Sendeelemente (Sender und Empfänger) in einem drahtlosen Netzwerk konfigurieren, um eine festgelegte Zuweisung der Senderessourcen gemäß wechselnden, zeitplangemäßen oder Ad-hoc-Kapazitätsanforderungen zu implementieren. Das System hält einen Zeitplan von Sendeplanimplementierungen aufrecht und kann automatisch jede Implementierung zu einer zeitplangemäßen Zeit ausführen.
  • Das semi-autonome Netzwerkverwaltungssystem besteht im Wesentlichen aus zwei semi-autonomen Komponenten. Die erste Komponente ist die Implementierungskomponente (IC), welche an einem Standort ausführt, welcher Netzwerksendeelemente aufweist, und die zweite ist eine Verwaltungskomponente (MC), welche an einem Netzwerkverwaltungsstandort ausführt. Diese Komponenten können über ein Benutzerdatagramm-Internet-Protokoll-Botschaftsformat verbunden sein.
  • Im Zentrum des Systems ist die IC. Die IC kann ein autonomes Anwendungsprogramm sein, welches ein oder mehrere Netzwerkelemente steuert. Ein Netzwerkelement kann eine Station oder eine Kommunikationsvorrichtung sein, welche physikalisch durch eine IC gesteuert wird. Deshalb ist es üblicherweise das Netzwerkelement ein stationärer oder mobiler Kommunikationsknoten an einem einzelnen physikalischen Ort. Die IC kann jedoch ein Netzwerkelement fernsteuern.
  • In einer Ausführungsform der vorliegenden Erfindung kann die IC-Anwendung in einer geeigneten Verarbeitungsumgebung, wie einem PC, welcher UNIX oder ein anderes geeignetes Betriebssystem, wie Windows oder DOS ausführt, ausgeführt werden kann. Die IC kann ebenfalls auf einem integrierten oder eingebetteten Prozessor, wie einem PC, auf einer Kartenumgebung mit ei nem anwendungsspezifischen oder Echtzeit-Betriebssystem, welches darauf ausgeführt wird, ausgeführt werden.
  • Die IC ist semi-autonom, beispielsweise kann sie Zuweisungsbefehle von einer Netzwerkkomponente in ausführbare Befehle für ihre zugehörigen Netzwerkelemente übersetzen, ohne direkten, permanenten Kontakt mit der Netzwerkverwaltungskomponente aufzuweisen. Die IC kann vorprogrammierte Parameter, Sendepläne oder Sammelbefehle für eine automatischen Ausführung speichern. Die IC kann einen Netzwerk-Programmiersprachenbefehlssatz oder einen generischen Zuweisungsbefehl auf eine Anbieter-spezifische Befehlsabfolge abbilden. Die IC kann die Verwaltungskomponente kontaktieren, um die Erlaubnis zu empfangen auf Netzwerkbandbreite zuzugreifen, um die Nichtverfügbarkeit von Netzwerkelementen zu berichten oder um verschiedene Zuweisungsparameter anzufordern, falls oder wenn lokale Anforderungen die IC-vorprogrammierten Zuweisungen übersteigen. Damit kann die IC eine unabhängige Steuerung über Netzwerkelemente zur Verfügung stellen, während sie einen Verwaltungsplan einhält oder ausführt.
  • In dem offenbarten semi-autonomen Netzwerkverwaltungsschema können Sendezeitpläne im Voraus zu der Implementierung der zeitplangemäßen Sendepläne geladen werden. Dann kann zu einer vorbestimmten Zeit das Netzwerk zu dem neuen Sendeplan wechseln, um die optimale oder zumindest gute Lösung zu implementieren, bevor kompliziertere dynamische Bandbreiten-Zuweisungsalgorithmen implementiert werden müssten.
  • Zusätzlich zu automatisch implementierenden, zeitplangemäßen Sendeplänen, welche durch die Verwaltungskomponente erzeugt werden, kann das System ebenso Netzwerkbenutzungsuntersuchungen durchführen. Eine automatisierte Netzwerk-Benutzungsuntersuchung kann erfordern, dass die Verwaltungskomponente Zugang zu Verkehrsdaten, welche für das Netzwerk gesammelt wurden, hat. Die Daten können automatisch oder per Hand durch die Verwaltungskomponente gesammelt werden, oder die Implementierungskomponente wirkt mit den Elementen in dem Netzwerk zusammen, um die Benutzungsdaten zu sammeln. Die Verwaltungskomponente kann statistische Verfahren verwenden, um die gesammelten Netzwerkbenutzungsdaten zu untersuchen, um optimierte Sendepläne für eine effiziente Nutzung der verfügbaren Ressourcen gemäß einem Sendeplan vorzuschlagen oder zu implementieren.
  • Die effiziente Benutzung eines Bandbreitenspektrums kann auf verschiedenen Ebenen in dem System erreicht werden. Auf einer ersten Ebene kann die Bandbreite zeitplangemäß in Übereinstimmung mit einer Ereignisuntersuchung der Anforderungen an das Netzwerk festgelegt werden. Beispielsweise kann bestimmt werden, dass der Verkehr am Montagmorgen hauptsächlich auswärtig ist (d.h. von einer zentralen Erdstation zu einer Mobilstation). An Freitagen geht der Hauptteil des Verkehrs jedoch in die entgegengesetzte Richtung (d.h. von Mobilstationen zurück zu der zentralen Erdstation). In diesem Beispiel kann ein asymmetrischer Kanal für den Montagsverkehr geöffnet werden, um einen auswärtigen Datenweg mit einer höheren Geschwindigkeit und einen Rückweg mit einer langsameren Geschwindigkeit bereitzustellen. Dann kann die entgegengesetzte Zuweisung für den Freitagsverkehr eingerichtet werden (z.B. ein Hochgeschwindigkeitskanal von einer Mobilstation an die zentrale Station und ein Niedriggeschwindigkeits-Bestätigungskanal von der zentralen Station zurück zu der Mobilstation). Dies kann eine optimale oder zumindest kosteneffiziente Lösung für die Kapazitätsanforderungen zu einer bestimmten Zeit bereitstellen.
  • Auf einer zweiten Ebene kann das System Kapazität basierend auf einer Dienstklasse von Service-Parametern zuordnen, welche z.B. durch ein Paketformat vom Asynchronen-Übertragungs ("ATM"-)Typ verfügbar sind. Beispielsweise kann eine Dienstklasse Datenpakete mit geringer Priorität für eine besondere Anwendung identifizieren. In diesem Fall mag ein teurer Satellitenträger nicht notwendig sein, und eine ökonomischere Senderessource kann durch das Netzwerk in Betrieb genommen werden, um die benötigten Datenpakete weiterzuleiten. Damit kann das vorliegende Netzwerk eine Dienstklasse von Service-Bandbreiten-Zuweisungsverfahren mit Minimalkosten-Führungsentscheidungen (Routing Decisions) basierend auf vorbestimmten Parametern, welche in der IC programmiert sind, mischen.
  • Die semi-autonome Weise von Netzwerkverwaltungskomponenten kann ein Datagrammprotokoll zur Interprozesskommunikation benutzen. Genauer gesagt, die Netzwerkkomponenten können durch Verwendung des Benutzerdatagrammprotokolls ("UDP") über ein Internetprotokoll ("IP") kommunizieren. Die Kommunikation zwischen der Verwaltungskomponente und der IC kann eine zyklisch abfragende (Pollen-) oder eine unterbrechende (Interrupt-) Methodik verwenden.
  • In einem zyklisch abfragenden Modus kontaktiert die Verwaltungskomponente jede der ICs, um UDP/IP-Botschaften weiterzuleiten oder um eine Übertragungssteuerungsprotokoll/Internetprotokoll-("TCP/IP"-)Information von der bestimmten IC zu empfangen. In einem unterbrechend betriebenen Modus kann der IC versuchen, mit der Verwaltungskomponente zu kommunizieren. Der unterbrechende Modus kann verwendet werden, um eine Verbindung mit der MC einzurichten, wenn die IC die Synchronisation mit dem Netzwerk verliert, oder um einen Alarm oder andere lokale Gegebenheiten weiterzuleiten, welche sich an der IC ereignen, welche durch die Verwaltungskomponenten nicht erfasst werden können. In dem unterbrechend betriebenen Modus kann die IC einen vorher zugewiesenen Sicherungskanal oder eine vorbestimmte Bandbreitenzuweisung aufweisen, um mit der Verwaltungskomponente zu kommunizieren. Die Verwaltungskomponente kann programmiert sein, um Alarmgegebenheiten oder Kommunikationsversuche von den ICs zu erfassen, wenn vorbestimmte Parameter-Schwellwerte erreicht werden.
  • Zusätzlich wird ein Signalsteuerungsmechanismus zwischen der Verwaltungskomponente und den ICs offenbart. Der Signalsteuerungsmechanismus ist in Betrieb, um sicherzustellen, dass jeder der ICs die zugehörige(n) Botschaft(en) empfängt und dass der Sendeplan gemäß dem vorbestimmten Zeitplan implementiert wird.
  • Der Signalsteuerungsmechanismus zwischen einer Verwaltungskomponente und Implementierungskomponenten kann durch Austauschen der folgenden UDP/IP-Botschaften kommunizieren.
    • • Sendesteuerbefehl
    • • Abbruchbefehl
    • • Bestätigung eines Sendesteuer- oder Abbruchbefehls
    • • Prüfanfrage
    • • Prüfrückmeldung
  • Ein Sendesteuerbefehl ("TCO") legt neue Sendeparameter für einen Sender oder Empfänger fest. Der TCO legt die Implementierungszeit fest. Die Implementierungszeit ist die Zeit, zu welcher Elemente beginnen sollen, die Sendeparameter, welche in dem Befehl festgelegt sind, zu benutzen. TCOs werden durch das System erstellt, um einen neuen Sendeplan zu implementieren. Das System sendet die TCOs an die ICs der Sender und Empfänger, welche Parameter ändern müssen, um den neuen Sendeplan zu implementieren. TCOs können auf einer Festplatte oder einer anderen nichtflüchtigen Speichereinrichtung gespeichert sein, so dass sie bei IC-Neustarts und bei Stromausfällen der Ics erhalten bleiben.
  • Es ist möglich, dass eine IC nicht in Betrieb sein kann oder nicht in der Lage sein kann, mit den verwalteten Vorrichtungen zu dem Ausführungszeitpunkt einer TCO zu kommunizieren. Wenn dies eintritt, kann die IC den momentanen Sendeplan implementieren oder kann einen Standardzustand implementieren, wenn die IC eine Kommunikation mit der verwalteten Vorrichtung wieder einrichtet.
  • Die IC kann eine Bestätigung einer TCO senden, wenn eine TCO von dem System empfangen wird. Falls einer der benötigten Parameterwechsel nicht implementiert werden kann, weil die verwaltete Vorrichtung oder die Konfigurationsdateien dies nicht unterstützen, benachrichtigt die IC die Verwaltungskomponente davon in der Bestätigung.
  • Die IC kann ebenso prüfen, ob die Parameterwerte für die verwaltete Netzwerkvorrichtung gültig sind. Die Parameterbereiche sind in den Vorrichtungsteuerungs-Konfigurationsdateien in der IC festgelegt, wie nachfolgend weiter behandelt wird.
  • Eine Bestätigungsbotschaft kann zum Berichten der erfolgreichen Implementation eines Sendesteuerbefehls nicht notwendig sein. Da die Mehrheit der Satellitennetzwerke einzelne Verbindungen zu jedem entfernten Standort implementieren, kann die IP-Verbindung zu dem System verloren sein, wenn eine IC nicht in der Lage ist einen TCO zu implementieren. Die Systemverwaltungskomponente kann das Problem aus einem Mangel von Prüfrückmeldungen erfassen. Falls das System nicht eine Prüfrückmeldung von einer IC empfängt, kann das System den Standortstatus aktualisieren und den Verwaltungskomponentenalarm auslösen.
  • Ein Abbruchbefehl kann die IC anweisen einen anhängigen TCO für die spezifizierten Sender oder Empfänger abzubrechen. Das System kann Abbruchbefehle senden, wenn eine anhängige Implementation durch den Administrator abgebrochen wird. Die IC kann eine Bestätigung senden, wenn sie einen Abbruchbefehl empfängt. Die IC kann eine Bestätigung senden, wenn sie einen TCO oder einen Abbruchbefehl von der Verwaltungskomponente empfängt.
  • Eine Prüfanfrage kann durch die Verwaltungskomponente periodisch an eine IC gesendet werden. Die Verwaltungskomponente kann eine Prüfungsanfrage senden, um den Status eines Transmitters oder eines Empfängers zu prüfen. Eine Prüfanfrage kann an jeden Sender und Empfänger gesendet werden, der durch eine IC verwaltet wird.
  • Eine Prüfantwort kann durch eine IC gesendet werden, wenn eine Prüfanfrage von der Verwaltungskomponente empfangen wird. Eine Prüfantwort kann die momentanen Parameterwerte des Senders oder Empfängers, welcher in der Prüfanfrage festgelegt ist, aufweisen.
  • Eine Prüfantwort kann im Aufbau ähnlich einem TCO sein. Sie kann die Hardware-Identifikation für einen Sender oder Empfänger und eine Liste von Modellparametern und ihren momentanen Werten aufweisen, wie von der physikalischen Hardware gemeldet.
  • Der Empfangsfrequenz-Modellparameter kann ein spezieller Fall sein: Die Frequenz, welche durch den Demodulator zurückgegeben wird, stimmt möglicherweise nicht mit der befohlenen Sendefrequenz überein. Quellen für Frequenzfehler während eines drahtlosen Trägersendeprozesses können zu einem Versatz zwischen den erwarteten und der tatsächlichen empfangenen Frequenz führen. Viele Demodulatoren sind entworfen worden, um diese Frequenzverschiebung durch Suchen des gesendeten Trägers in einer Umgebung um die befohlene Sendefrequenz anzupassen. Jedoch kann das System auch diesen Empfangsfreqenz-Offset berücksichtigen, indem bestimmt wird, ob die physikalische Hardware die gleichen Parameter wie in dem zuletzt implementierten TCO benutzt.
  • Die Verwaltungskomponente kann periodisch die momentanen Parameter von allen Sendern und Empfängern abfragen. Diese Netzwerkprüffunktion kann die folgenden Funktionen ausführen:
    • • Beibehalten des Kommunikationsstatus zwischen der Verwaltungskomponente und den Sendern und Empfängern in dem Netzwerk.
    • • Erfassen von Parameterwechseln der verwalteten Vorrichtung.
  • Wenn ein Unterschied zwischen den festgelegten Sendeparametern für einen Sender oder Empfänger und der verwalteten Vorrichtung erfasst wird, kann die Verwaltungskomponente einen Bandbreiten-Administrator benachrichtigen. Die Verwaltungskomponenten-Betreiberschnittstelle kann einen hörbaren wie auch einen visuellen Alarm verwenden, um die Wahrscheinlichkeit zu erhöhen, dass ein Bandbreiten-Administrator die Änderung wahrnimmt und handelt, um ihn zu beheben.
  • 21 zeigt eine Einrichtungssteuerungs-IC 150. Die IC 150 kann eine Konfigurationsdatenbank 152 aufweisen, welche eine Konfigurationsabbildung für Endbenutzer-Empfangs- und Sendervorrichtungen speichert, welche z.B. mit seriellen Vorrichtungen 164, 166, 172, 174 und parallelen Vorrichtungen 188, 190 über Schnittstellen verbunden ist. Die Empfänger/Sendervorrichtung kann von verschiedenen Anbietern sein, und deshalb bildet die Konfigurationsdatenbank 152 Befehle von der Verwaltungskomponente 156 auf eine bestimmte Vorrichtung ab. Dieses Merkmal der IC ermöglicht das Verwenden einer generischen Netzwerksteuersprache, welche ab Kommandos an die IC 150 gesendet werden (nachfolgend weiter behandelt).
  • Das System ist aufgebaut, um alle Sendevorrichtungen zu verwalten, unabhängig von dem Hersteller. Um dies zu erreichen, befasst sich die Verwaltungskomponente mit Modellsatelliten, Sendern und Empfängern, wie in 6 dargestellt.
  • Die Sender- und Empfängermodelle weisen Parameter auf, welche notwendig sind, um eine drahtlose Verbindung zu implementieren. Nur Parameter, welche sich auf die Einrichtung von drahtlosen Verbindungen beziehen, müssen in die Sender- und Empfängermodelle aufgenommen werden.
  • Die Verwaltungskomponente benötigt keine Information über physikalische Vorrichtungselemente, welche verwendet werden, um die Kommunikationsverbindung in dem verwalteten Netzwerk zu implementieren. Deshalb muss die MC die Modellparameter nicht direkt auf Kommandos für die physikalische Hardware der Sender und Empfänger an diesem Standort abbilden. Die IC kann Information über die physikalische Hardware an ihrem Standort aufweisen und kann die Modellparameter auf die zugehörigen Befehle und Antworten abbilden.
  • Die IC kann Information über die physikalische Hardware aus Konfigurationsdateien lesen. Diese Dateien können die Information festlegen, welche durch die IC benötigt wird, um die verwaltete Vorrichtung an einem Standort zu überwachen und zu steuern. Die IC-Konfigurationsdateien können die Information enthalten, welche notwendig ist, um Parameterwechsel für die Modellsender und -empfänger in Befehle für die physikalische Hardware umzuwandeln.
  • Kurzbeschreibung der Zeichnungen
  • 1 ist ein bildhaftes Schema eines Satellitennetzwerks mit sternförmiger Topologie, welche einen geteilten ausgehenden Simplex-Kanal und einen privaten eingehenden Simplex-Kanal zeigt.
  • 2 ist eine schematische Darstellung einer Gittertopologie für ein Satellitennetzwerk, welche geteilte abgehende Simplex-Kanäle zeigt.
  • 3 ist ein Blockdiagramm eines Sendevorrichtungsmodells, welches Modulatoren, Aufwärtskonverter und die Verlust- und Verstärkungselemente in dem Schaltkreis, die Anlagenantenne und die entsprechenden Empfangsschaltkreise, welche Verstärkungs- und Verlustelemente aufweisen, den Empfangsumsetzer und den Demodulator zeigt.
  • 4 stellt Softwarekomponenten für das semi-autonome Netzwerkverwaltungssystem der vorliegenden Erfindung dar.
  • 5 ist ein Blockdiagramm, welches die Softwarekomponenten detailliert darstellt. An der Steueranlage befindet sich eine Verwaltungs-(Steuer-)Komponente, eine Anzeigensteuerungseinrichtung und eine Ereignisaufzeichnungskomponente. An dem abgesetzten Standort befindet sich die IC, die Verwaltungssteuerkomponente und eine Anzeigensteuerungseinrichtung und eine Ereignisaufzeichnungskomponente. Die Verwaltungssende- und -empfangsvorrichtung ist des Weiteren als durch die IC-Vorrichtungssteuerung gesteuert dargestellt.
  • 6 ist ein Blockdiagramm, welches die Elemente eines Sendemodells darstellt, welche durch die semi-autonome IC der vorliegenden Erfindung gesteuert werden.
  • 7 zeigt des Weiteren ein funktionales Schema der IC-Systeme.
  • 8 ist ein Blockdiagramm, welches die Software-Verarbeitungsarchitektur der semi-autonomen Netzwerkverwaltungskomponente darstellt.
  • 9 ist ein Blockdiagramm des Informationsflusses in den semi-autonomen Komponenten der vorliegenden Erfindung.
  • 10 ist eine graphische Darstellung der Sendeplanzuweisung des verfügbaren Spektrums.
  • 11 ist eine graphische Darstellung des Sendeplans eines Sendeplan-Zeitplans.
  • 12 ist eine graphische Darstellung eines Sendeplan-Zeitplans, welcher während eines bestimmten Tages implementiert wird.
  • 13 ist ein Flussdiagramm, welches ein Verfahren zum Aufstellen und Ausführen eines Sendeplans darstellt.
  • 14 ist ein Flussdiagramm, welches ein Verfahren zum Ausführen einer Bandbreiten-Zuweisungsanfrage darstellt.
  • 15 ist eine graphische Darstellung eines UDP-Datagrammformats, welches in den Verwaltungskomponenten verwendet wird.
  • 16 ist ein funktionales Schema der Anfrage/Befehlsflussrichtung der vorliegenden Erfindung.
  • 17 ist ein Flussdiagramm, welches ein Verfahren zum Einstufen, Anwenden und Implementieren von Sendeplänen innerhalb des Netzwerks darstellt.
  • 18 ist eine graphische Darstellung, wie die Methodik der vorliegenden Erfindung Sendemedien als Ressourcen betrachtet.
  • 19 ist eine graphische Darstellung der Methodik der vorliegenden Erfindung, welche Sendemedienressourcen zuordnet.
  • 20 ist eine graphische Darstellung einer Zeitsteuerungs-Sendeplanimplementierung.
  • 21 ist eine graphische Darstellung des Befehlsverarbeitungsflusses in der Implementierungskomponente.
  • 22 ist eine graphische Darstellung des Verarbeitungsflusses für eine Netzwerkprüfverarbeitung.
  • 23 ist eine graphische Darstellung des automatischen Befehlsflusses bezüglich der Zeitsteuerung.
  • Detaillierte Beschreibung einer bevorzugten Ausführungsform
  • Das System ist aus zwei Softwarekomponenten zusammengesetzt, der Verwaltungskomponente ("MC") und der Implementierungskomponente ("IC"), welche zusammenarbeiten, um die Sendeelemente in einem drahtlosen Netzwerk zu überwachen und zu steuern.
  • Die MC weist eine Benutzerschnittstelle zum Konfigurieren, Überwachen und Steuern der Kapazitätszuordnungsaktivität in einem drahtlosen Netzwerk auf. Dies kann eine Win32-Anwendung sein, welche auf einer Windows-NT-Workstation läuft, welche an einem Netzwerkbetriebszentrum angeordnet ist (NOC). Konfigurieren, Überwachen und Steuern der Kapazitätszuweisung kann mit der Verwaltungskomponente erreicht werden. Die MC kommuniziert mit der anderen Softwarekomponente, wobei die IC die Internet-Protokoll-(IP-)Familie der Netzwerkprotokolle verwendet, wie in 4 und 5 dargestellt.
  • Die IC ist eine Anwendung, welche mit den physikalischen Hardware-Elementen kommunizieren kann, welche die Kommunikationsverbindung in einem drahtlosen Netzwerk implementieren. Die IC kann eine Win32-Anwendung sein, welche auf einem Rechner läuft, welcher an jeder Anlage des Netzwerks vorgesehen ist. Die IC kann einen Satz von Konfigurationsdateien lesen, welche die Netzwerkvorrichtung beschreiben, welche überwacht und gesteuert werden sollen. Diese Konfigurationsdateien können Textdateien sein und können mit einem Texteditor-Programm erstellt und geändert werden. Im Allgemeinen sind die Konfigurationsdateien wiederverwendbar, d.h., dass dieselben Konfigurationsdateien an vielen Anlagen verwendet werden können, falls dieselbe Netzwerkvorrichtung an beiden Anlagen verwendet wird.
  • Wie zuvor behandelt, kommunizieren die MCs und die ICs durch Austauschen von IP-Botschaften. 5 ist eine Darstellung einer Anschlussmöglichkeit zwischen der Verwaltungskomponente und der IC in einem drahtlosen Netzwerk. Die IP-Verbindungen können in einem Satellitennetzwerk, durch das Internet oder durch ein privates Netzwerk implementiert sein. Ein zweiter physikalischer Übertragungsweg zwischen der MC und den ICs kann verwendet werden, um eine IP-Kommunikation einzurichten. Typischerweise kommunizieren ICs nicht mit anderen ICs; jedoch können Kommunikationsverbindungen zwischen Komponenten für eine weitergeführte Kommunikation mit dem MC eingerichtet werden.
  • Das Verwaltungssystem ist um mehrere Elemente angeordnet. Diese sind:
    • • Senderessourcen
    • • Anlage
    • • Sender
    • • Empfänger
    • • Sendeelement
    • • Sendeplan
    • • Implementierung
    • • Zeitplan
    • • Ausführungszeit
  • Eine Senderessource kann ein Teil einer drahtlosen Kapazität (Leistung und Bandbreite) sein, welche durch die Sender in einem Netzwerk benutzt wird. Eine Anlage kann eine Sammlung von Sendern und Empfängern sein, welche durch eine einzige IC gesteuert wird. Normalerweise steuert eine IC alle Sender und Empfänger einer Netzwerkanlage. Jedoch können die Sender und Empfänger in einer Netzwerkanlage durch mehr als eine IC gesteuert werden. Z.B. kann dies der Fall bei einer Netzwerkknotenanlage in einem Satellitennetzwerk mit einer sternförmigen Konfiguration sein.
  • Ein Sender ist ein Vorrichtungselement, welches ein Informationssignal moduliert, derart, dass es Zugang zu einem drahtlosen Medium haben kann. Ein Empfänger ist ein Vorrichtungselement, welches ein Signal demoduliert, welches von einem drahtlosen Medium empfangen wurde, um die Information aus dem übertragenen Signal zurückzugewinnen. Ein Sendeelement kann ein Sender oder Empfänger in einer Netzwerkkonfiguration sein. Obwohl Sender und Empfänger verschieden sein können und verschiedene Funktionen ausführen können, kann die Verwaltungskomponente manche Operationen ausführen, für welche Sender und Empfänger beide in der gleichen Weise behandelt werden. Beispielsweise kann die MC den Status von allen Sendern und Empfängern in einem Netzwerk prüfen. Die Verwaltungskomponente kann möglicherweise nicht zwischen Sendern und Empfängern unterscheiden, wenn sie diese Prüfoperation ausführt.
  • Eine drahtlose Verbindung kann erzeugt werden, wenn ein Informationssignal durch einen Sender moduliert und dann durch ei nen oder mehrere Empfänger demoduliert wird. Ein drahtloses Kommunikationsnetzwerk ist eine Ansammlung von Kommunikationsverbindungen, welche eine Informationsübermittelung zwischen den Anlagen in dem Netzwerk ermöglichen. Jede Verbindung benötigt einen Teil der Senderessourcen, welche für das drahtlose Netzwerk verfügbar sind. Die Zuordnung von verfügbaren Senderessourcen unter den Sendern in einem Netzwerk ist ein Sendeplan. Diese Sendepläne können die Informationskapazität und die Verbindungsanforderungen zwischen den Sendern und Empfängern in einem Netzwerk festlegen.
  • Nur Sender müssen möglicherweise in einem Sendeplan festgelegt werden. Sender erzeugen die Signale, welche die Senderessourcen verwenden. Die Zahl der Sender, welche ein drahtloses Signal demodulieren, beeinflusst nicht die Menge der Senderessourcen (Bandbreite und Leistung), welche verwendet werden, um die Verbindung zu implementieren.
  • Implementieren kann das Verfahren zum Konfigurieren der Sender und Empfänger in einem drahtlosen Netzwerk sein, um die Senderessourcen wie in einem Sendeplan festgelegt zuzuordnen. Die Verwaltungskomponente kann einen Sendeplan implementieren, indem sie Befehle an die ICs sendet, welche die Sender in dem Sendeplan steuern und die Empfänger sendet, welche den Sendern zuhören. Diese Befehle legen die Sendeparameter für die Sender und Empfänger fest und wann sie implementiert werden sollen. Die IC sendet die vorrichtungsspezifischen Befehle, welche die Sendeparameter zu der festgelegten Zeit implementieren. Der Implementierungszeitplan kann eine Liste von allen Sendeplan-Implementierungen sein, welche automatisch in der Zukunft ausgeführt werden können. Der Zeitplan kann durch die MC-Anwendung eingehalten werden. Ein Benutzer kann Implementierungen zu dem Zeitplan hinzufügen, Implementierungen von dem Zeitplan entfernen und existierende Implementierungen zu anderen Zeiten hin verschieben. Eine Ausführungszeit besteht aus einem Sendeplan und der Zeit, zu welcher die Sendung implementiert werden wird. Die Zeit kann ein wiederkehrender Zeitpunkt sein, z.B. 12:00 UTC jeden Tag oder 06:00 UTC jeden Montag. Der Implementierungszeitplan kann aus Ausführungszeiten gebildet werden.
  • Die Informationsarchitektur des Systems betrifft hauptsächlich die Struktur der Datenbank, welche durch die Verwaltungskomponente unterhalten wird, und kann die Struktur der Botschaften festlegen, welche zwischen der Verwaltungskomponente und den IC ausgetauscht werden.
  • Die Informationen, welche durch die Verwaltungskomponente (Netzwerkkonfigurationen, Senderessourcen-Konfigurationen, Zeitpläne, etc.) beibehalten werden, können in einer relationalen Datenbank gespeichert werden.
  • Die Verwaltungskomponente kann Information über die drahtlosen Netzwerke benötigen, welche sie verwaltet. Ein Netzwerk kann als zusammengesetzt aus Anlagen, Sendern und Empfängern betrachtet werden. Information über diese Objekte, z.B. Anlagen, Sender und Empfänger, und die Beziehungen zwischen ihnen können eine Netzwerkkonfiguration bilden. Ein Netzwerk kann eine Ansammlung von Anlagen sein, welche durch Senderessourcen verbunden sind. Die nachfolgend beschriebenen Informationen können für jedes Netzwerk festgelegt werden, welches durch das System verwaltet wird:
    • • Name
    • • Senderessourcen, welche für die Verwendung durch das Netzwerk verfügbar sind.
  • Das System kann die folgenden Informationen für jedes Netzwerk beibehalten:
    • • Netzwerk-ID
    • • Status
    • • Anlagen in dem Netzwerk
  • Eine Anlage kann ein physikalischer Ort einer Antenne in einem drahtlosen Netzwerk sein. Zusätzlich zu einer Antenne kann eine Anlage mindestens einen Sender oder Empfänger aufweisen.
  • Das System kann es erfordern, dass die folgenden Informationen für jede Anlage bereitgestellt werden:
    • • Name
    • • NMS-IP-Adresse
    • • Ort (Straßenadresse, geographische Koordinaten, etc.)
    • • Anschlussinformation (Telefonnummern, Betreibernamen, Radiofrequenzen, etc.)
    • • Antennenparameter (Größe, Verstärkung, etc.).
  • Das System kann die folgenden Informationen für jede Anlage aufrechterhalten:
    • • Anlagen-ID
    • • Status
    • • Netzwerk, zu welchem die Anlage zugehörig ist
    • • Sender in der Anlage
    • • Empfänger in der Anlage
    • • Zeit der letzten Übertragung der Verwaltungskomponente an die Anlage
    • • Zeit der letzten Antwort der IC von der Anlage.
  • In dem System kann ein Sender die notwendige Vorrichtung aufweisen, um einen digitalen Datenstrom in einen Träger zum Senden über eine drahtlose Ressource zu verwandeln. Das System kann erfordern, dass jeder Sender eindeutig bezeichnet wird.
  • Das System kann die folgenden Informationen für jeden Sender aufrechterhalten:
    • • Sender-ID
    • • Status (UP, DOWN, FIXED, UNKNOWN)
    • • Anlage, wo der Sender angeordnet ist
    • • Empfänger, welcher den/die Senderträger empfangen soll.
  • Das System kann den Status der Sender in einem drahtlosen Netzwerk nachverfolgen. Mögliche Statuswerte für die nachverfolgten Komponenten können sein:
  • UP
    Der Sender erzeugt im Moment einen Träger und wird durch die Verwaltungskomponente gesteuert.
    DOWN
    Der Sender erzeugt keinen Träger, aber wird durch die Verwaltungskomponente gesteuert.
    FIXED
    Der Sender erzeugt einen Träger, und die Verwaltungskomponente kennt die Charakteristik des Trägers, aber der Sender wird nicht von der Verwaltungskomponente gesteuert.
    UNKNOWN
    Die Verwaltungskomponente weiß nicht, ob der Sender einen Träger erzeugt.
  • In dem System kann ein Empfänger die notwendige Vorrichtung aufweisen, um einen Träger, welcher über eine drahtlose Ressource gesendet wird, zu empfangen und den digitalen Datenstrom wiederzugewinnen. Die folgenden Informationen können für jeden Empfänger festgelegt sein:
    • • Name
    • • Sender des Trägers, welchen der Empfänger empfangen sollte.
  • Das System kann die folgenden Informationen für jeden Empfänger aufrechterhalten:
    • • Empfänger-ID
    • • Status
    • • Anlage, wo der Empfänger angeordnet ist.
  • Ein Pool kann eine Ansammlung von Senderessourcen sein, welche für die Verwendung durch die verwalteten Netzwerke verfügbar sind. Jede Senderessource ist ein Teil einer Sendekapazität (Leistung und Bandbreite). Die folgenden Informationen können für jeden Pool benötigt werden:
    • • Name
    • • Senderessourcen in dem Pool.
  • Das System kann die folgenden Informationen über jeden Pool aufrechterhalten:
    • • Pool-ID
    • • Netzwerke, welche den Pool verwenden.
  • Eine Senderessource kann ein Teil einer Sendekapazität sein (Leistung und Bandbreite). Das System kann die folgenden Informationen für jede Senderessource benötigen:
    • • Beschreibung (Transponder, Anbieter, etc.)
    • • Startfrequenz
    • • Endfrequenz
    • • Translation-Offset
    • • Leistungszuordnung
    • • Kostentabelle.
  • Das System kann die folgenden Informationen über jede Senderessource aufrechterhalten:
    • • Senderessourcen-IC
    • • Pool, zu welchem die Senderessource zugehörig ist.
  • Ein Sendeplan ist eine Zuordnung von Senderessourcen zu einem oder mehreren Trägern in einem drahtlosen Netzwerk. Das System legt die folgenden Informationen für einen Sendeplan fest:
    • • Ausführungszeit
    • • Dauer
    • • Bemerkungen.
  • Das System kann die folgenden Informationen für einen Sendeplan aufrechterhalten:
    • • TP-ID
    • • Zustand (NICHT ZEITGESTEUERT, ZEITGESTEUERT, BEVORSTEHEND, BEREIT, STARTEND, AKTIV, ABGESCHLOSSEN oder ABGEBROCHEN)
    • • BARs erfüllt durch das TP.
  • Das System kann Anlagen mit vielfältigen Sendern und Empfängern verwalten. Dafür verwaltet das System ein Benennungsschema zum Identifizieren eines spezifischen Senders oder Empfängers in einer Anlage.
  • 9 kann den Fluss der Hardware-Identifikationsinformation von den IC-Konfigurationsdateien zu der Verwaltungskomponente darstellen. Die Identifikationsinformation kann aus den Konfigurationsdateien entstehen, welche für eine Anlage in einem Netzwerk erzeugt wurden. Die Konfigurationsdateien für eine Anlage können durch die IC gelesen werden.
  • 9 zeigt den Informationsfluss in dem System. Jeder Sender und Empfänger in einer Anlage kann durch eine Vorrichtungsklasse gekennzeichnet sein. Jedem Mitglied einer Klasse ist eine Objektnummer zugeordnet. Zusammen identifizieren die Vorrichtungsklasse und das Objekt einen einzigartigen Sender oder Empfänger in einer Anlage. Ein Bandbreitenadministrator 902 kann die Hardware-Identifikation bereitstellen, wenn er die Sender und Empfänger einer Anlage für eine Bandbreitenverwaltung konfiguriert. Der Fluss an Information, welcher in 9 dargestellt ist, vereinfacht eine Netzwerkkonfigurationsunterhaltung und reduziert das Risiko von Problemen aufgrund einer inkonsistenten Konfigurationsinformation in dem Netzwerk. Die Kreise mit einem Querstrich 914, 916 stellen dar, dass weder der Bandbreitenadministrator 902 noch die Verwaltungskomponente 906 Zugang zu den Konfigurationsdateien 910 benötigen.
  • Die Systemsoftware-Komponenten können Informationen durch Senden und Empfangen von Botschaften austauschen, welche ein Netzwerk oder externe Verbindungen nutzen. Das Verwaltungsverfahren kann mit allen IC-Verfahren kommunizieren. Jede IC kommuniziert nur mit der Verwaltungskomponente.
  • Das Benutzerdatagramm-Protokoll (UDP) der Internet-Protokoll-(IP-)Familie kann verwendet werden, um die Zwischenprozessbotschaften zu transportieren. Das System kann die Kombination der IP-Adresse und dem UDP-Port verwenden, um die ICs in dem Netzwerk zu identifizieren. Eine Anlagen-Identifikationsinformation wird möglicherweise in den Botschaften nicht benötigt, falls die IP-Adressen und -Ports schon in den IP- und UDP-Vorspännen (Headers) verfügbar sind.
  • Die Verwaltung und die ICs können kommunizieren, wobei mehrere Botschaftstypen verwendet werden. Obwohl jeder Botschaftstyp verschiedene Informationen aufweist und einen unterschiedli chen Zweck erfüllt, teilen die Botschaftstypen ein paar gemeinsame Eigenschaften, wie in 15 dargestellt.
    • • Eine Botschaft wird als einzelnes UDP-Datagramm gesendet.
    • • Nur ASCII-Zeichen sind in der Botschaft zugelassen.
    • • Eine Botschaft ist eine Folge von Informationsfeldern.
    • • Felder sind mit einem ASCII-Zeilenvorschub (LF, Linefeed) abgeschlossen.
    • • Eine Botschaft wird mit einem leeren Feld abgeschlossen (einzelnes LF).
    • • Die ersten drei Felder sind für jede Botschaft gleich (Botschaftstyp, Laufzahl und Hardware-Identifikation).
  • Obwohl Systembotschaften nur ASCII-Zeichen aufweisen, können die Botschaften vor dem Versenden mittels UDP komprimiert werden. Botschaften können nach dem Empfang wieder dekomprimiert werden. Felder #4 bis #N 1514, 1518 in 15 sind Informationsfelder 1524. Die Felder vor den Informationsfeldern in einer BMF-Botschaft sind Vorspann- bzw. Header-Felder 1528.
  • Vorspannfelder können in Systembotschaften 1528 vorliegen. Typischerweise sind die Reihenfolge und das Format der Vorspannfelder gleich unabhängig von einem Botschaftstyp. Das Format eines Vorspannfeldes ist einfach: eine Zeichenfolge abgeschlossen durch ein ASCII-Vorschub-(LF-)Zeichen 1504, 1508, 1510. Die Zeichenfolge kann ein druckbares ASCII-Zeichen außer dem LF aufweisen. Die Verwaltungskomponente und die ICs können durch Verwendung der folgenden Botschaftstypen kommunizieren:
    • • Sendesteuerbefehl (TCO)
    • • Abbruchbefehl (ABRT)
    • • Bestätigung (ACK)
    • • Prüfanfrage (AREQ)
    • • Prüfantwort (ARSP)
  • Der mnemonische Code in Klammern hinter jedem Botschaftstyp ist die Bezeichnung, welche in dem ersten Feld 1502 einer Systembotschaft 1526 verwendet wird. Nach dem Botschaftstypfeld ist das nächste Feld in einer Systembotschaft eine Laufzahl 1506. Die Verwaltungskomponente unterhält für jedes Teil der verwalteten Vorrichtung (z.B. Empfänger oder Sender) in einem Netzwerk eine Laufzahl. Die IC kann die Laufzahl von einer Anfragebotschaft in einer Antwortbotschaft verwenden.
  • Laufzahlen können verwendet werden, um Antworten (ACK oder ARSP) Anfragen (TCO, ABRT oder AREQ) zuzuordnen. Die Verwendung von Laufzahlen 1506 verhindert eine Verwechslung, wenn viele Antworten empfangen werden, weil viele Anfragen aufgrund von Botschaftszustellungsverzögerungen oder zeitweilig nicht verfügbarer Komponenten gesendet wurden.
  • 18 stellt einen Sendeplan zum Zuweisen von Sendemedienressourcen über Sender in einem Netzwerk dar. 18 zeigt, dass ein Sendemedium in diskrete Segmente 10 aufgeteilt werden kann. Ein Netzwerkverwaltungsplan kann die diskreten Segmente 10 der Bandbreite als diskrete Sendemedienquellen 12 betrachten. Ein Sendeplan 16 kann verwendet werden, um einen Netzwerksender 18 über eine Verbindung 14 auf eine vorbestimmte Sendemedienressource 12 abzubilden. Beispielsweise können Sendenetzwerksender 20, im Besonderen Sender 18, mittels eines Sendeplans 16 über eine Verbindung 14 auf zwei diskrete Segmente 10 abgebildet werden. Die Netzwerk-Medienressource kann eine sternförmige Topologie, wie in 1 dargestellt, aufweisen oder eine netzförmige Topologie aufweisen, wie in 2 dargestellt.
  • Netzwerk-Sendemedienressourcen können auch in getrennten Netzwerken sein. Beispielweise kann eine erste Netzwerksenderessource eine Kapazität von dem INMARSAT-Satellitennetzwerk auf weisen oder durch private Netzwerke in einem C-, KU-, KA- oder L-Band bereitgestellt werden. Die Netzwerksenderessourcen können des Weiteren durch erdnahe Satelliten, Satelliten mit mittlerer Erdumlaufbahn oder geostationäre Satelliten erhöht werden. Erdnahe Satelliten können durch das Iridiumsystem gebildet werden, welches von Iridium Inc. verwendet wird. Geostationäre Satelliten können ebenso zusätzliche Senderessourcen bereitstellen, wie beispielsweise die Inmarsat- oder Intelsat-Satellitendienste.
  • Die Verwaltungskomponente oder die ICs müssen nicht einer direkter Steuerung der Bandbreitenzuordnung unterliegen, um Sendemedienressourcen zu verwenden. Beispielsweise kann eine Bandbreitenzuweisung auf dem Iridium-Satellitensystem unabhängig von der Verwaltungskomponente und den ICs betrieben werden. Jedoch können die Bandbreiten-Zuordnungsverfahren von z.B. dem Iridium-Netzwerk verwendet werden, um den sich ergebenden Übertragungsweg wie eine Sendemedienressource zu behandeln, welche unter Kontrolle der Verwaltungskomponente ist. Tatsächlich können vielfältige Träger von dritten Systemen in diskreten vorbestimmten Einheiten zugewiesen werden, wie z.B. diskrete Segmente 10, welche in 18 dargestellt sind, für die Verwendung als Medienressource durch die vorliegende Erfindung.
  • 19 ist eine graphische Darstellung der Netzwerkelemente, ICs, einer Verwaltungskomponente und eines Sendeplans. Eine zentrale Steuerungseinrichtung der vorliegenden Erfindung kann durch eine Verwaltungskomponente ("MC") 30 gebildet werden. Die MC 30 kommuniziert mit einer Vielzahl von ICs ("ICs") 32, 34, 38, 40 durch Verbindungen 31. Jede IC bildet eine einzigartige Anlage, welche der Netzwerkverwaltungssteuerung durch die MC unterliegt. Jeder IC kann eine Netzwerkvorrichtung 42 zur Steuerung unterliegen. Beispielsweise unterliegt einer IC 40 ein Sender zur Steuerung, und einer BIC 38 unterliegen Emp fänger 46, 48, 50, 51 und Sender 56, 57 zur Steuerung. Jedoch unterliegen einer IC 36 ein Empfänger 54 und ein Sender 52 zur Steuerung. Die vorliegende Erfindung implementiert einen Sendeplan 43 durch Abbilden von Netzwerkvorrichtungen 42 auf Sendemedienressourcen 46. Beispielsweise wurden einem Sender 44 Sendemedienressourcen 45 zum Empfangen durch einen Empfänger 48 zugewiesen, wie durch aufsteigende Verbindungs- und absteigende Verbindungsabbildungen in dem Sendeplan 43 angedeutet. Dies kann eine kombinierte Sendemedienressource darstellen, deren Gesamtkapazität die gesamte diskrete, der Sendemedienressource 45 zugeordnete Menge ist. Beispielsweise kann eine dynamische Bandbreitenanforderung für eine Verbindung mit einer vorbestimmten Dienstklasse in zwei einzelne Träger aufgespalten werden. Die diskreten Träger können durch zwei diskrete Medienressourcen, welche der Sendemedienressource 45 zugeordnet sind, repräsentiert werden, um einen notwendigen Gesamtdurchfluss bereitzustellen, um die vorbestimmte Kapazität anzupassen, um die Dienstklasse zu unterstützen. Die überschüssige Kapazität kann genutzt werden, um die wiedergewonnene Zeit bereitzustellen, um die Pakete am Empfänger 48 zusammenzusetzen. Diese Methodik ist zum Beispiel nützlich, wenn z.B. eine Dienstklasse von einem bestimmten Endbenutzer die Netzwerkkapazität überschreitet, um die Anforderung an einen einzelnen Kanal oder eine angrenzende Medienressource zu erfüllen. Beispielsweise benötigt die Dienstklasse eine Verbindung, welche die Bitratenkapazität des Modulators an einem bestimmten Sender übersteigt, aber zwei Modulatoren würden reichlich Bandbreite für die Dienstklasse bereitstellen. In diesem Beispiel könnte die IC oder die Verwaltungskomponente einen Paketdatenstrom von der Endnutzervorrichtung auf zwei verschiedene Modulatoren aufteilen. In diesem Beispiel könnten mehrfache Sendemedienressourcen zugeordnet werden, um die Gesamtanforderung der Dienstklasse zu erfüllen.
  • Ein weiteres repräsentatives Beispiel für einen hier verwendeten Sendeplan ist eine Übermittlung von einer IC 38 über einen Sender 56, welcher eine Sendemedienressource 57 zugeordnet ist. Die Sendemedienressourcen 57 können zum Empfangen von sowohl einer IC 34 und einem Empfänger 58 als auch einer IC 32 und einem Empfänger 60 verwendet werden. Dies ist ein Beispiel für eine Punkt-zu-Mehrpunkt-Übertragung. Der Punkt wird durch einen Aufwärtssender 56 repräsentiert, und die Mehrpunkte werden durch die Empfänger 58 und 60 repräsentiert. Eine repräsentative Anwendung eines solchen Plans ist z.B. eine Übertragungsbotschaft von einem Sender 56 an zwei simultane Anlagen, welche durch die ICs 32 und 34 repräsentiert werden.
  • Ein weiteres repräsentatives Beispiel für einen hier verwendeten Sendeplan ist ein Sender 57, welcher eine Zuordnung von Sendemedienressourcen 61 für den Empfang durch den Empfänger 54 aufweist. Die IC 36 weist einen Sender 52 und Sendemedienressourcen 53 auf, welche zum Empfang durch den Empfänger 50 der IC 38 zugeordnet sind. Dieser Sendeplan kann eine asymmetrische Transmission repräsentieren, d.h. der nach außen gehende Kanal der IC 38, dargestellt am Transmitter 57, sind mehr Medienressourcen zugeordnet, was eine größere Bandbreiten- oder größere Datenrate zum Empfang durch eine IC 36 durch einen Empfänger 54 andeutet als der ausgehende Kanal von der IC 36 durch den Sender 52 über Sendemedienressourcen 53 zum Empfang durch den Empfänger 50 zu der IC 38. Andere repräsentative Permutationen der hier verwendeten Sendepläne werden durch den Abbildungssendeplan 43 in 19 dargestellt.
  • 20 stellt einen zeitlichen Ablauf dar, wie ein repräsentativer Sendeplan durch die Verwaltungskomponente implementiert werden kann. Die Sendeplanimplementation beginnt mit einer Verwaltungskomponente 100, welche einen vorbestimmten Befehl 102 an das Netzwerk zu einer vorbestimmten Befehlszeit 110 zu senden hat. Der (die) Befehl(e) 102 werden an eine IC 104 gesendet, welche die Senderessourcenzuordnung zu der Implementierungszeit ändern muss. Dieser Befehl wird in der IC 104 gespeichert, und die Zeit, um den Befehl zu implementieren, wird durch die IC 104 decodiert. Die IC 104 sendet eine Befehlsbestätigung 118 an die Verwaltungskomponente 100 zurück. Zu diesem Zeitpunkt wird der Befehl 102 geladen und wartet auf das Verteilen an der MC 100 zu der vorbestimmten Befehlszeit 110. Das Kommando 102 wird nochmals gesendet 122, falls die Empfangsbestätigung des Kommandos 118 nicht innerhalb einer vorbestimmten Zeit empfangen wurde.
  • Es versteht sich, dass die MC 100 eine Liste von jeder IC 104 in dem Netzwerk aufweist, welche geändert werden muss. Diese Liste kann die TCP/IP-Adresse jeder IC 104 aufweisen, so dass die MC 110 eine UDP/IP-Botschaft mit einem darin codierten Befehl 102 senden kann. Eine Bestätigungsendfrist 134 ist enthalten, welche Sekunden vor der Implementierungszeit des neuen Sendeplans sein kann. Die Bestätigungsendfrist 134 kann der letzte Zeitpunkt sein, zu welcher eine MC 106 eine Implementierung abbrechen kann, falls nicht jede IC 104 die Befehle bestätigt.
  • Offenbar kann die IC 104 eine koordinierte Implementierung verwenden, um sicherzustellen, dass keine IC 104 mittellos ist, wenn der Sendeplan implementiert ist. Während der Abbruchssequenz, welche auftritt, falls die IC 104 den Befehl 102 in dem Schritt 118 nicht bestätigt hat, sendet die MC 106 eine Abbruchsbotschaft 126 an eine IC 108, an welche der Befehl 102 gesendet wurde. Die IC 108 kann eine Abbruchsbestätigung 128 senden. Der Abbruchbefehl 126 wird nochmals in dem Schritt 130 gesendet, falls er nicht bestätigt wird. Die Implementierungszeit 136 definiert eine Zeit, zu welcher der Sendeplan durch die IC 104 ausgeführt wird. Es ist offensichtlich, dass zu diesem Zeitpunkt alle notwendigen ICs 104 einen Bestätigungsbefehl 118 aufweisen und in einer synchronisierten Weise regressiv bis zu der vorbestimmten Implementierungszeit 136 zählen. Offensichtlich kann der Bestätigungsbefehl eine Zeitangabe aufweisen, zu welcher eine IC 104 einen Befehl 102 empfängt, um zu überprüfen, dass die Implementierungszeit 136 zwischen allen ICs 104 synchronisiert ist. Wenn alle Befehle bestätigt wurden und das Netzwerk bereit ist den Plan zu der Implementierungszeit 136 zu implementieren, implementieren die ICs 104 den (die) Befehl(e), welche von der MC 100 zu der Implementierungszeit 136 empfangen wurden.
  • Zu diesem Zeitpunkt kann ein neuer Sendeplan, wie in 19 dargestellt, durch das Netzwerk implementiert werden. Der Kommunikationsweg zwischen einer MC 30 und ICs 32, 34, 36, 38, 40 ist unabhängig von den Sendemedienressourcen. Wie in 19 dargestellt, erfolgt ein Sendeweg 31 allgemeinerweise über ein TCP/IP-Netzwerk (z.B. das Internet), wie in der heutigen Verwendung allgemein bekannt. Jedoch ist es in dem Umfang der vorliegenden Erfindung, einen Überwachungs- oder Aufrechterhaltungskanal festzulegen, welcher ein Punkt-zu-Mehrpunkt-Übertragungsschema von der MC 30 zu und von den ICs 32, 34, 36, 38, 40 sein kann, wobei eine der ICs zusammen mit der MC 30 angeordnet sicherstellt, dass eine Netzwerkverbindung zwischen den ICs 32, 34, 36, 38, 40 und einem der MC zugeordneten Sender vorhanden ist, wie einem Sender 44. In einem solchen Fall kann jede IC 32, 34, 36, 38, 40, welche bereit ist, den neuen Sendeplan zu implementieren, einen Empfänger aufweisen, welcher vorgesehen ist, den Sender 44 zu überwachen und das Abbruchsignal 126 zu empfangen, falls nicht jede IC 32, 34, 36, 38, 40 bestätigt. Dies stellt einen selbstschützenden oder Überwachungskanal-Sicherungsplan zum Abbrechen der Implementierung eines neuen Sendeplans sicher, falls eine oder mehrere ICs 32, 34, 36, 38, 40 die Verbindung mit der Verwaltungskomponente verlieren.
  • Befehle können in eine IC 150 aus einer Mehrzahl an Quellen eingebracht werden, wobei eine davon direkt von der MC sein kann. Ein Knoten 158 kann ein UNIX-Dämon oder ein Windows NTTM-Dienst sein, welcher eine TCP/IP-Adresse überwacht. Somit können Befehle von einer MC 156 in eine IC 150 durch einen Port 204 eingebracht werden. Nach dem Einbringen in die IC 150 können Netzwerkbefehle in dem Schritt 158 in Übereinstimmung mit einer Konfigurationsdatenbankinformation abgebildet werden, um spezifische Befehle 178 an die Netzwerkeinrichtung auszugeben. Diese Befehle können in eine Befehlsschlange 168, 180, 184 gesetzt werden, welche dann durch einen Zeitplanerprozess 162, 170 und 186 ausgerichtet wird. Beispielsweise können zeitplangemäße Befehlsimplementierungsprozesse 162, 170, 186 Ausgabebefehle an die zugehörigen Empfänger, Sender oder Netzwerkvorrichtungen durch einen seriellen Port 164, 166, 172, 174 oder einen parallelen Port 188, 190 ausgeben. Befehlsschlangen 168, 180, 184 können periodisch abgetastete (polled), unterbrechend (interrupt) angetriebene Schlangen sein. Das bedeutet, der zeitplangemäße Implementierungsprozess 164 kann periodisch die Schlangen 168, 180, 184 abfragen, um zu bestimmen, ob ein Befehl vorliegt, und falls dem so ist, den Befehl an eine geeignete Netzwerk-Schnittstellenvorrichtung (d.h. einen seriellen Vorrichtungstreiber 164, 166) weiterleiten, oder der Befehlsschlüssel kann eine Zeitspanne sein.
  • Die Befehlsschleife kann alternativ unterbrechend antreibend sein. Das bedeutet, wenn z.B. ein Befehl in eine Schlange 168, 180, 184 eingebracht wird, dass eine Befehlsschlange 168 eine Unterbrechung (interrupt) an den Befehlsimplementierungsprozess senden kann, damit der Befehlsimplementierungsprozess den Befehl bedient und ihn dann an die geeignete Netzwerkvorrichtung an dem geeigneten seriellen Port weiterleitet. Offensichtlich kann dieser Prozess ebenso für Implementierungsprozesse 170, 186 verwendet werden.
  • Befehlsimplementierungsprozesse 168, 170, 186 können mit der Netzwerkzeit 202 synchronisiert sein, um Befehle zu der geeigneten Zeit auszuführen. Das bedeutet, eine Implementierung der Sendepläne kann mit der Netzwerkzeit 202 synchronisiert werden, um sicherzustellen, dass sich alle Netzwerkvorrichtungen selbst simultan oder nahezu simultan rekonfigurieren. Die Implementierungsprozesse 168, 170, 186 können ebenso Daten von der Konfigurationsdatenbank 152 aufweisen, um den Implementierungsprozess 168, 170, 186 für bestimmte Endbenutzer-Netzwerkvorrichtungen zu konfigurieren. Dies stellt eine Flexibilität in dem Implementierungsprozess 168, 170, 186 bereit. Das bedeutet, die Implementierung kann als ein modulares Softwareprogramm geschrieben werden, welches durch Konfigurationsdatenbankdaten 160 verändert werden kann, wenn der Implementierungsprozess 168, 170, 186 ausgeführt wird. Weiter kann bei diesem Konzept die MC 156 die Konfigurationsdatenbank 152 über eine Verknüpfung 204 adressieren, um die Konfigurationsdatenbank 152 zu ändern, um die Endbenutzereinrichtungen neu festzulegen. Dies ermöglicht der MC 156, die Endbenutzereinrichtungen ferngesteuert von dem Benutzerort an der IC-Anlage zu verwalten. Die IC 150 kann durch ein Modul 158 über eine Verknüpfung 182 kommunizieren, um Bestätigungen 200 an die MC 156 zurückzusenden. Bestätigungsbefehle 118 sind in 20 dargestellt, und Befehlsbestätigungen können ebenfalls verwendet werden. Die 2128 stellen einen Schritt dar, welcher verwendet werden kann, um den Empfang von Befehlen zu bestätigen oder um den Empfang eines Abbruchbefehls zu bestätigen.
  • Es ist offensichtlich, dass es mindestens zwei Arten gibt, die MC-Befehle abzubilden, oder mindestens zwei Arten gibt, auf welche die MC-Befehle auf Endbenutzervorrichtungen oder auf einen bestimmten Port auf einer IC abzubilden. Zuerst wird eine TCP/IP-Adresse für die befehlende IC 204 bereitgestellt, und dann ist innerhalb des UDP-Befehls eine Unteradresse, wel che bei 158 decodiert werden kann und an eine bestimmte Endbenutzervorrichtung adressiert ist.
  • 22 zeigt ein graphisches Blockdiagramm eines Prüfsteuerprozesses, durch welchen Daten von Netzwerkeinrichtungen gesammelt werden können. Dieser und der nachfolgende ähnlich aufgezeigte Prozess stellen keine Ausführungsformen der vorliegenden Erfindung dar, sondern repräsentieren Hintergrundinformationen, welche nützlich sind, um die Erfindung zu verstehen. Eine Implementierungskomponente 150 kann eine Konfigurationsdatenbank 152 aufweisen, welche die Konfigurationen der IC in Bezug auf die Endbenutzer-Netzwerkeinrichtung steuert. Eine Prüfanfrage 252 kann durch die MC über einen Port 254 empfangen werden. Der Port 254 kann ein Benutzerdatenpaket über ein TCP/IP-Netzwerk an eine bestimmte vorbestimmte Adresse bei 256 sein. Bei 256 kann ein selbsttätiger Anforderungsbefehl decodiert werden, um einen Einrichtungsnamen auf eine der Hardware-Identifikationen von denen abzubilden, welche in der Konfigurationsdatenbank 152 abgespeichert sind. Der Prozess bei 256 kann ebenso verwendet werden, um Einrichtungseigenschaften auf Datensteuerungen 290 abzubilden. Diese Parameter können an den Neuformatierungs-Befehlsprozess bei 280 weitergeleitet werden, welcher verwendet wird, um für die MC eine formatierte Prüfantwort 282 bereitzustellen.
  • In einer Ausführungsform, welche den Stand der Technik darstellt, kann die MC einen asynchronen Datensammlungsprozess 262, 264, 266 für die Netzwerkeinrichtung an einem entsprechenden Datenport 268, 270, 272, 274, 276, 278 für die Netzwerkeinrichtung einrichten. Der asynchrone Datensammelprozess 262, 264, 266 kann unterbrechend oder periodisch abfragend betrieben werden.
  • In dem unterbrechend (interrupt) betriebenen Beispiel des asynchronen Datensammelprozesses 262, 264, 266 kann die Endbe nutzervorrichtung einen unaufgeforderten Befehl über die entsprechende Vorrichtung (z.B. Vorrichtung 268) an den asynchronen Datensammelprozess 262, 264, 266 senden. Die Unterbrechung (Interrupt) ruft dann das Programm auf, um die Datengegebenheit (oder möglicherweise einen Alarm) der Netzwerkeinrichtung zu bedienen. Der asynchrone Datensammelprozess 262, 264, 266 führt dann die Daten zu einem Datensteuerspeicherblock 258, wo der Alarm oder die Datengegebenheit in der IC gespeichert werden kann. Offensichtlich kann der Datensteuerspeicherblock 258 eine Festplatte oder eine andere verfügbare Permanentspeichereinrichtung in der BIC sein. In einem Beispiel des Standes der Technik ist die Datensteuerspeichereinrichtung ein nicht flüchtiges Datenspeichermedium, und der asynchrone Datensammelprozess ist ein modulares Programm, da es durch Daten der Konfigurationsdatenbank 260 für die bestimmte Netzwerkvorrichtung geändert wird. Dies ermöglicht eine flexible Programmierungsmethodik für den asynchronen Datensammelprozess, welcher in der vorliegenden Erfindung verwendet wird.
  • In dem zyklisch abfragenden Beispiel des asynchronen Datensammelprozesses 262, 264, 266 kann der asynchrone Datensammelprozess 262 z.B. die Endbenutzer-Netzwerkvorrichtung periodisch abfragen, welche z.B. mit dem Port 268 verbunden ist, um Daten oder Alarmgegebenheiten von der Endbenutzervorrichtung zu empfangen. Die zyklische Abfragerate kann ein Parameter von der Konfigurationsdatenbank sein und über eine Verknüpfung 260 empfangen werden.
  • Zusammengefasst kann eine Prüfanfrage über einen Port 254 empfangen und bei 256 decodiert werden, um Daten des Datensteuerspeicherprogramms 292 auszugeben. Die Datenausgabe von dem Datensteuerspeicher kann bei 280 mit Parametern formatiert werden, welche von der Prüfanfrage übergeben werden 290. Diese kann eine selbsttätige Antwort 294 zurück an die BMC 282 in geeignetem und vorbestimmtem Format vorsehen.
  • 23 zeigt eine logische Flussdarstellung einer Netzwerkprüfung von einer MC 302. In 23 kann die MC 302 eine selbsttätige Zeit für ein Netzwerkelement, einen Sender oder einen Empfänger 300 erzeugen. Zu der geeigneten Zeit kann die MC 302 eine Prüfanfrage 306 senden. Offensichtlich ist die Prüfanfrage 306 an das Netzwerkelement und die bestimmte IC gerichtet, welche dieses Element 308 steuert. Die IC kann dann das Netzwerkelement abfragen und eine Prüfantwort 312 an ein MC 310 senden. Die Prüfantwort 312 ist in zeitlicher Synchronisation 316 nach der Prüfanfrage 306 dargestellt.
  • Initialisierungs- oder Konfigurationsdateien können verwendet werden, um die Erfindung zu implementieren. Beispielsweise kann eine "command.ini"-Datei verwendet werden, um Benutzerschnittstellen-Befehlsdefinitionen für alle unterstützten Netzwerk-Verwaltungssystemeinrichtungen bereitzustellen. Die "command.ini"-Datei spezifiziert die Menüs zugehörig zu jeder Steuerung, welche auf einem Benutzerdisplay verwendet wird.
  • Eine "monitor.ini"-Datei kann verwendet werden, um durch eine Implementierungskomponente ausgeführte, automatische Überwachungsfunktionen zu spezifizieren. Die "monitor.ini"-Datei kann als Netzwerkverwaltungssystem-Datenverbindungsschnittstelle-Definitionsdatei wirken.
  • Die "equipct1.ini"-Datei kann als Netzwerkverwaltungssystem-Steuerungsinitialisierungsdatei verwendet werden. Das bedeutet, die "equipct1.ini"-Datei spezifiziert einige globale Parameter für die Implementierungskomponentenanwendung. Sie kann ebenso die Lage der anderen Konfigurationsdateien angeben, falls solche Dateien nicht an einer vorbestimmten oder Standardstelle gespeichert sind.
  • Eine "event.ini"-Datei kann Beschreibungen von Netzwerk-Verwaltungssystemereignissen vorsehen. Beispielsweise kann die "event.ini"-Datei textbasierte Antworten (auf Benutzerbefehle), welche auf einem Benutzerinterface dargestellt werden, und die asynchronen Botschaften, welche zu entweder einem Ereignisprotokollvorrichtung oder einer anderen Vorrichtung gesendet werden, definieren.
  • Eine "port.ini"-Datei kann als Netzwerkverwaltungssystemexterne Verbindungsdefinitionsdatei verwendet werden. Die "port.ini"-Datei kann bestimmte serielle und parallele Ports spezifizieren, welche durch die Implementierungskomponente verwendet werden.
  • Die "serial.ini"-Datei kann als Netzwerkverwaltungssystemserielle Kommandobeschreibungsdatei verwendet werden. Diese Datei kann Befehls- und Antwortzeichenfolgen spezifizieren, welche verwendet werden, um mit einer Verwaltungseinrichtung über eine serielle Schnittstelle zu kommunizieren.
  • Die "panel.ini"-Datei kann eine Gesamtspezifikation für eine Anzeigensteuerungsdarstellung sein. Diese Datei verbindet die Bedienelemente mit spezifischen Ein-/Ausgabeports und beschreibt die gesamte graphische Benutzerschnittstelle für eine Einrichtungssteuerungsanlage.
  • Die "template.ini"-Datei kann als das Netzwerkverwaltungssystem-Anzeigenschablonen-Beschreibungsdatei verwendet werden. Diese Datei spezifiziert die graphische Qualität der in der Anzeigensteuerungsdarstellung verwendeten Bedienelemente. Die graphische Qualität kann die Position des graphischen Bedienelements auf der Anzeige, den Typ des Anzeigeobjekts, den Namen von einer benötigten Bitmap-Graphikdatei und eine Referenz auf ein zu dem Bedienelement zugehörigen Menü aufweisen.
  • Die Hardware-Identifikationsfeld 1510 kann Information aufweisen, welche einen bestimmten Sender oder Empfänger an einer Anlage spezifiziert. Das Hardware-Identifikationsfeld kann das Format aufweisen:
    HWID=<Class>:<Name>
    wobei
    <Class> der Hardwaretyp ist, und
    <Name> der Name ist, welcher zu einem bestimmten Teil der Hardware in der IC-Konfiguration zugeordnet ist. Der Hardwaretyp kann einer aus den folgenden Klassen sein:
    • • Sender (TX)
    • • Empfänger (RX)
    • • Aufwärtswandler (UC)
    • • Abwärtswandler (DC)
  • Der <Class>-Anteil des Hardware-Identifikationsfeldes kann eines der in Klammern dargestellten mnemonischen Zeichen sein. Informationsfelder 1524 und Kopffelder (Header) 1528 können einige Gemeinsamkeiten aufweisen. Jeder Feldtyp wird mit einem ASCII-Zeilenvorschubzeichen (LF) 1512, 1522 abgeschlossen. Der hauptsächliche Unterschied zwischen Kopffeldern 1528 und Informationsfeldern 1524 ist, dass dieselben Kopffelder in allen Systembotschaften gefunden werden, während verschiedene Botschaften verschiedene Informationsfelder aufweisen können.
  • Aufgrund der Größe der Informationsfelder 1524 ist das Format eines Informationsfeldes komplexer als das Format eines Kopffeldes. Informationsfelder können mit dem Format übereinstimmen:
    <mnemonic>=<value>
    wobei
    <mnemonic> ein mnemonisches Zeichen, welches den Feldtyp darstellt, und
    <value> eine Zeichenfolgendarstellung des Wertefeldes ist.
  • Sowohl das mnemonische Zeichen als auch der Wert des Informationsfeldes können aus druckbaren ASCII-Zeichen bestehen. Jedoch wird das ASCII-Zeichen "=" verwendet, um die mnemonischen Zeichen und die Werteanteile des Informationsfeldes zu trennen. Daher kann ein "=" weder in den mnemonischen Zeichen noch in den Wertezeichenfolgen vorhanden sein.
  • Ein Sendesteuerbefehl (TCO) wird von der Verwaltungskomponente an ein IC gesendet, um Parameteränderungen für einen Sender oder Empfänger, welcher durch die IC gesteuert wird, anzufordern. Eine TCO hat die folgenden Informationsfelder:
    • • Ausführungszeit
    • • Modellparameter
  • Das Ausführungszeitfeld legt die Zeit fest, an welcher der TCO implementiert werden muss. Der TCO für jede Seite einer Kommunikationsverbindung (Sender und Empfänger) kann dieselbe Ausführungszeit aufweisen, um die Zeit zu minimieren, für welche der Träger während des Wechselns nicht in Betrieb ist. Ausführungszeiten können in UTC angegeben sein. Das Ausführungszeitfeld kann das Format aufweisen:
    ET=<YYYY><MM><DD><hh><mm>
    wobei
    <YYYY> eine vierstellige Jahreszahl (0000 bis 9999) ist,
    <MM> eine zweistellige Monatszahl (Januar ist "01", etc.) ist,
    <DD> der zweistellige Monatstag (01 bis 31) ist,
    <hh> die zweistellige Stunde des Tages (00 bis 23) ist, und
    <mm> die zweistellige Minute der Stunde (00 bis 59) ist.
  • Alle Felder des TCO nach der Ausführungszeit sind Modellparameter. Diese Felder sind Parameterwerte für den Sender oder Empfänger, welche durch das Hardware-Identifikationsfeld des TCO festgelegt werden. Modellparameter können als Parameter/Wertepaar spezifiziert werden. Das Format eines Modellparameter in einer BMF-Botschaft ist:
    <mnemonic>=<value>
    wobei
    <mnemonic> das mnemonisches Zeichen für ein Modellparameter und
    <value> eine Zeichenfolgendarstellung für einen Parameterwert ist.
  • Ein Abbruchbefehl (ABRT) kann an ein IC gesendet werden, um beliebige anhängige TCO für die spezifizierte Hardware abzubrechen. Ein ABRT benötigt keine Informationsfelder.
  • Eine Bestätigung (ACK) informiert die Verwaltungskomponente, dass die IC den TCO oder den ABRT empfangen hat. Die ACK ist die Antwortbotschaft für einen TCO oder einen ABRT. Wenn eine IC den TCO oder den ABRT empfängt, muss es die Bestätigung an die Verwaltungskomponente senden. Falls die IC irgendein Problem mit dem TCO erfasst (konfigurierte Hardware unterstützt einen Modellparameter nicht, ungültige Hardware-ID, etc.), dann wird die ACK die Probleme beschreiben. Eine ACK für den ABRT benötigt diese Problembeschreibung nicht. Die AKC kann die folgenden Informationsfelder aufweisen:
    • • Ausführungszeit (identisch wie in TCO)
    • • Modellparameter (nur falls eine Fehlergegebenheit vorhanden ist)
  • Eine ACK kann dieselben Informationsfelder wie der TCO aufweisen, welcher bestätigt wird. Jedoch sind die Modellparameterfelder nur vorhanden, falls die IC den Modellparameter nicht erfüllen kann. Beispielsweise, falls der TCO eine ungültige Empfängerbitrate aufweist, aber eine gültige Empfängerfrequenz, dann würde die ACK ein Informationsfeld für den RXR-Modellparameter, aber nicht für den RXF-Modellparameter aufweisen.
  • Eine Prüfanfrage (AREQ) wird periodisch durch die MC an jeden Sender und Empfänger in einem Satellitennetzwerk gesendet. Jede AREQ wird an die BMF-IC gesendet, welche für die Verwaltung des spezifischen Senders oder Empfängers verantwortlich ist. Die AREQ benötigt keine Informationsfelder.
  • Die Prüfantwort (ARSP) wird als Antwort auf eine AREQ von der MC an eine IC gesendet. Die ARSP ist die Antwortbotschaft für die AREQ. Die ARSP hat die folgenden Informationsfelder:
    • • Ausführungszeit (Zeit, zu welcher ARSP erzeugt wurde)
    • • Modellparameter (momentane Einstellungen)
  • Das Format der ARSP kann nahezu identisch zu dem Format einer TCO sein: Die Botschaft weist ein Informationsfeld für alle die Modellparameter auf, welche zugehörig zu dem spezifischen Teil der Hardware sind. Jedoch können die Werte der Modellparameter die tatsächlichen Einstellungen der Hardware sein und nicht die gewünschten Einstellungen.
  • Ein Zweck der ARSP ist, den Zustand der Hardware in dem Netzwerk zu bestimmen. Ein zweiter Zweck ist, nach manuell eingeführten Änderungen der Konfiguration der Netzwerk-Hardware zu suchen. Beispielsweise kann ein Bediener an einer auswärtigen Anlage manuell die Empfängerfrequenz durch Verwenden der manu ellen Bedienelemente der Einrichtung verändern. Die Verwaltungskomponente fragt periodisch den momentanen Zustand aller verwalteten Einrichtungen ab, um Parametermodifikationen, welche nicht durch die Verwaltung ausgelöst wurden, zu erfassen. Die Ausführungszeit für eine Prüfantwort ist die Zeit, zu welcher die ARSP erzeugt wurde.
  • Eine ARSP kann die Modellparameter für den durch die Hardware-Identifikation spezifizierten Einrichtungstyp aufweisen. Wenn der Wert für den Modellparameter nicht verfügbar ist, kann der Wert des Teilfeldes "UNKNOWN" sein. Beispielsweise, falls der Verschlüsselungszustand eines Senders nicht durch eine IC bestimmt werden kann, erscheint das Feld "SCR=UNKNOWN" in der Prüfantwort.
  • Die IC (IC) kann ihre Konfigurationsdateien beim Starten auslesen und im Speicher vorliegende Datenbanktabellen und Daten-"Objekte" erstellen, um einen schnellen Zugriff auf die in diesen Dateien gespeicherten Konfigurationsinformationen zu vereinfachen. In den Daten, welche aus den Konfigurationsdateien ausgelesen werden, sind die Aufzeichnungen, welche eine Einrichtung beschreiben, welche die Management-Konsole-(MC-) Anwendung versuchen wird durch ihre Befehle an die Einrichtungssteuerung zu steuern. Die MC kann mit der Einrichtungssteuerung mit einer Botschaft kommunizieren, welche ein Format aufweist ähnlich zu:
    Eugip=EquipmentClass:EquipmentUnitName
    Attribute1=Value1
    Attribute2=Value2
    wobei "EquipmentClass" und "EquipmentName" Zeichenfolgenwerte sind, welche in den IC-Konfigurationsdateien zum Identifizieren eines Teils einer modellierten Einrichtung erscheinen. Die Werte von "Attribute" und "Value" werden ebenfalls als Zei chenfolgen dargestellt, und somit erfolgt der gesamte Dialog zwischen der MC und der IC durch textbasierte Botschaften.
  • Die IC-Konfigurationsdateien identifizieren ein oder mehrere Teile der modellierten Einrichtung und einen Satz an Attributen, welche die modellierte Einrichtung unterstützen kann. Beispielsweise kann der folgende Abschnitt der "equipctl.ini"-Datei ein Einrichtungselement beschreiben, welches als "TRANSMITTER:Outbound" bekannt ist. Die modellierten Attribute werden durch den "EquipModemAttrs"-Eintrag identifiziert und listen die Werte TXF TXR MODT MODR ENCT ENCR DENC SCR PWR CXR als zulässige Attribute für die als "TRANSMITTER:Outbound" bekannte Einheit auf.
  • [Outbound]
    Figure 00470001
  • Dieser Konfigurationseintrag kann ebenso mit anderen Konfigurationseinträgen assoziiert werden, welche es ermöglichen, die Einrichtungssteuerung zu setzen (ändern) und die Attributwerte eines momentanen Teils einer seriell angebundenen Einrichtung zu erhalten (wiederzuerlangen). Die Einträge in der Liste von "EquipAttrSetCmds" beziehen sich auf die Einträge in der "serial.ini"-Datei, welche den momentanen zu sendenden Befehl beschreibt. Die Einträge in den "EquipAttrSetCmdPorts" und "EquipAttrSetCmdAddrs" beschreiben, mit welchem seriellen Port die angebundene Einrichtung verbunden ist und die Adresse der angebundenen Einrichtung (in dem Fall, dass vielfältige Teile der Einrichtung über denselben seriellen Port angebunden sind). In gleicher Weise beziehen sich die "EquipAttrMon-Conns"-Einträge auf die Konfigurationseinträge in der "monitor.ini"-Datei, welche den Mechanismus beschreibt, durch welchen das Attribut von der angebundenen Einrichtung wiedergewonnen wird, und die "EquipAttrMonConnPorts" und "EquipAttrMonConnAddrs" beschreiben die seriellen Ports und Adressen, welche für die Datenwiedergewinnung verwendet werden.
  • Da der IC die Semantik der Datenwerte nicht bekannt ist, welche das "Setzen" oder "Holen" und das Abbilden zwischen der Einrichtung und den Einrichtungsattributen sind, von welchen die MC annimmt, dass sie sie steuert, sind vollständig in den Einrichtungssteuerkonfigurationsdateien und nicht in der Einrichtungssteuersoftware festgelegt.
  • Die MC und die IC kommunizieren über ein Textformat, welches allgemein zuvor beschrieben wurde. Jede Kommunikation wird durch die MC begonnen. Drei Anfragepakete sind momentan festgelegt: 1) eine Anfrage zum Ändern der Attribute eines bestimmten Teils der Einrichtung zu einer bestimmten Zeit in der Zukunft, 2) eine Anfrage, um die Anfrage zum Ändern der Attribute eines bestimmten Teils einer Einrichtung abzubrechen, und 3) eine Anfrage, um die momentanen Werte der Attribute eines bestimmten Teils der Einrichtung zurückzusenden. Jede Anfrage wird normalerweise mit einer komplementären Botschaft beantwortet. In manchen Fällen jedoch wird vorsätzlich keine Antwortbotschaft generiert, um eine negative Antwort zu übermitteln.
  • Die Anfrage, um die Attribute eines bestimmten Teils der Einrichtung zu ändern, ist als Sendeänderungsbefehl (TCO) bekannt. Das Format einer TCO ist wie folgt: MessageSequenceNumber
    Figure 00490001
  • Wenn die IC ein TCO empfängt, bestätigt sie die Anfrage. Die Anfragebestätigung beinhaltet ein Bestätigen, dass die angeforderte Änderungszeit noch nicht verstrichen ist und dass die IC-Konfiguration die angeforderten Änderungen unterstützt. Die IC kann sich auf ihre im Speicher vorliegende Datenbank der Konfigurationsdaten beziehen, um die Anfrage zu bestätigen. Erstens kann die IC versichern, dass die angeforderte Einrichtung in der Konfiguration identifiziert ist. Sie kann dann versichern, indem die in der Anfrage genannten Attribute durch die Konfiguration zu den Befehlen zurückverfolgt werden, welche ausgegeben werden müssen, um sicherzustellen, dass eine ausreichende Konfigurationsinformation vorliegt, um die benötigen Befehle zu bilden. Abschließend kann sie überprüfen, um zu sehen, ob die Einrichtung im Moment auf Befehle reagiert.
  • Falls ein Fehler erfasst wird, beispielsweise dass die Anfrage nicht durch die Konfiguration unterstützt werden kann, kann eine Antwort an die MC zurückgesendet werden, welche die ver letzenden Anfragedaten identifiziert. Beispielsweise, falls eine Anfrage eine Einrichtungsidentifikation enthält, welche nicht exakt dem Eintrag in die "equipctl.ini"-Datei entspricht oder falls ein Attributname nicht exakt einem der legitimen Attribute, welche in der "equipctl.ini"-Datei genannt sind, entspricht, würde eine Antwort gesendet, welche angibt, warum die TCO ungültig war, und implizit angeben, dass die Anfrage nicht implementiert würde. Falls ein legitimes Attribut genannt wird, aber die Einrichtungssteuerung erkennt, dass entweder kein serieller Befehl referenziert wird oder dass der referenzierte serielle Befehl nicht konfiguriert ist, kann die IC ebenso eine ähnliche Antwort senden, welche angibt, warum die Anfrage nicht implementiert werden kann. Eine Bestätigung der Parameterwerte kann mit einer ähnlichen Technik erreicht werden.
  • Falls andererseits die Anfrage richtig ist, aber die Einrichtung im Moment nicht auf serielle Befehle reagiert, wird vorsätzlich keine Antwort erzeugt, was andeuten kann, dass kein Problem in der Anfrage erfasst wurde, aber da keine Bestätigung gesandt wurde, wird die Anfrage nicht zu der spezifischen Zeit implementiert. Andererseits wird eine Bestätigung an die MC zurückgesendet, welche angibt, dass, falls nicht anders befohlen, die IC die angeforderte Konfigurationsänderung zu der geforderten Zeit ausführen wird. Die Anforderung, die Änderung der Attribute eines bestimmten Teils einer Einrichtung zu löschen, ist als Abbruchsbotschaft (ABRT) bekannt. Das Format einer ABRT ist wie folgt: ABRT
    Figure 00500001
  • Die IC kann einen ausstehenden Befehl entfernen, welcher gesetzt ist, um an eine bestimmte Einrichtung ausgegeben zu wer den, falls ein beliebiger Befehl in einer Warteschlange ist, und kann eine Bestätigung an die MC senden, welche angibt, dass sie dies getan hat. Falls zu der Empfangszeit kein Befehl aussteht, kann die IC mit einer Botschaft antworten, welche angibt, dass ein Befehl gefunden wurde. Die Anfrage, die momentanen Werte der Attribute eines bestimmten Teils einer Einrichtung wiederzuerlangen, ist als Prüfbotschaft (AUDIT) bekannt. Das Format einer AUDIT ist wie folgt: AUDIT
    Figure 00510001
  • Die MC kann die momentanen Werte der Einrichtungsattribute anfragen, indem eine AUDIT-Botschaft an die IC gesendet wird. Die Botschaft kann spezifische Attributnamen beinhalten oder in Abwesenheit jeglicher Attributnamen alle der Einrichtung zugehörigen Attribute zurücksenden. Sollte die Einrichtung oder identifizierte Attribute nicht in der IC-Konfiguration definiert sein, wird die IC eine Botschaft ähnlich einer negativen Bestätigung auf eine TCO senden, welche angibt, welches bestimmte Feld der Anfragebotschaft als fehlerhaft erkannt wurde. Falls die AUDIT-Anfragebotschaft als durch die momentane IC-Konfiguration unterstützt erkannt wird, kann die IC die Konfigurationseinträge, welche durch das "equipctl.ini"-Datei identifiziert werden, um die momentanen Werte wiederzuerlangen, und eine Antwortbotschaft ähnlich der TCO-Botschaft bilden und diese an die MC senden. Das Antwortbotschaftsformat ist wie folgt: AUDIT
    Figure 00510002
    Figure 00520001
  • 13 stellt ein Flussdiagramm einer Sendeplanausführung dar. Zu Beginn kann das System eine nicht zeitplangemäße Übertragung 1302 aufweisen. Dem Sendeplan kann eine Ausführungszeit 1304 zugewiesen sein. Der Sendeplan kann an das Netzwerk weitergeleitet werden, um den Plan in einen schwebenden Zustand zu setzen. Nachdem alle der TCOs, welche zum Implementieren des Sendeplans benötigt werden, den Befehl bestätigt haben, ist der Sendeplan bereit zur Ausführung 1308. Zu der Sendeplan-Ausführungszeit 1310 beginnt der Plan die Startsequenz. Nachdem die MC bestätigt, dass alle TCOs bestätigt wurden, z.B. so dass die MC nicht einen Abbruchbefehl ausgibt, wird der Sendeplan aktiv 1312.
  • Das System beginnt einen normalen Betrieb mit dem neuen Sendeplan, und das System beginnt, wieder Daten über die Verbindungsbenutzung 1316 zu sammeln. Spezielle Sendepläne, die nicht wiederkehren, werden nicht neu zeitplangemäß eingeordnet 1318.
  • 14 stellt eine Bandbreiten-Zuordnungsanfrage dar. Die Steuerschleife kann in der MC ausgeführt werden. Das System kann eine Anforderung für eine Bandbreite 1402 von dem Bandbreitenadministrator oder einer IC empfangen. Die Anfrage kann ein nicht zeitplangemäßes Netzwerk-Event 1404 sein. Die Anfrage nach einer Bandbreite wird decodiert und zeitplangemäß für eine Ausführung eingeteilt 1406. Der Ausführungszeitplan kann für eine sofortige Ausführung oder für einen zeitplangemäßen Einsatz sein. Die geeignete TCO kann von der MC an die geeignete IC gesendet werden, um den Sendeplan weiterzuleiten und den Sendeplan in einen Bereitszustand 1408 zu setzen. Der Sendeplan wartet dann auf seine Ausführungszeit. Wenn die Sende plan-Ausführungszeit eintritt 1410, bestätigt die MC, dass die TCOs durch die IC bestätigt wurden. Falls die TCOs bestätigt wurden, wird der Plan zu der vorbestimmten Zeit aktiv 1412. Das System hat auf diese Weise die Bandbreitenanforderung erfüllt 1414.
  • Die IC kann eine Steuerschleife implementieren, welche ähnlich zu der zuvor dargestellten und beschriebenen ist. Die IC kann bestätigen, dass ein Kanal innerhalb des vorliegenden Sendeplans verfügbar ist 1406 und den neuen Sendeplan sofort ausführen 1408, 1410 und 1412. Die IC kann dann die MC 1402 von dem nicht zeitplangemäßen Sendeplan 1404 benachrichtigen. Die MC kann dann, wie zuvor beschrieben, fortfahren, um den neuen Plan weiterzuleiten und anzuwenden.
  • 5 stellt die Zwischenprozesskommunikation zwischen dem MC 502 und den ICs 506 und 542 dar. MC-Befehle werden über die UDP/IP-Verbindung 504 von der Steuerkomponente 503 zu der Einrichtungssteuerkomponente 514 gesendet. Die Einrichtungssteuerung 519 bildet dann die generischen Netzwerkbefehle von der MC auf spezifische Befehle (wie zuvor beschrieben) zum Ausgeben 512 an die verwaltete Einrichtung 510 ab. Die Einrichtungssteuerung 514 verliert den Befehls-Event 524. Die IC kann ebenso den Befehls-Event auf einer lokalen Anzeige 530 angeben.
  • Das System kann eine Alarm- oder andere Netzwerkbotschaften über die TCP/IP-Verbindung 516 empfangen, welche die Netzwerkverwaltungsanzeige 518 beeinflussen können. Die Einrichtungssteuerung 514 kann sich mit der Anzeigensteuerung 518 verbinden, wenn die Einrichtungssteuerung 514 eine Alarmgegebenheit von der Netzwerkeinrichtung 510, 520 über Befehlsverbindungen 512, 522 empfängt. Die Event-Aufzeichnungseinrichtung 534 kann Netzwerkprüfungen und Netzwerk-Events von der IC-506-Einrichtungssteuerung 514 über die UDP/IP-Verbindung 532 empfangen.
  • Wie zuvor beschrieben, kann jeder der Kommunikationsprozesse in 5 unterbrechend oder zyklisch abfragend betrieben werden.
  • Die IC kann ebenso das Befehls-Event auf der lokalen Anzeige 530 ausgeben.
  • Das System kann Alarm- oder andere Netzwerkbotschaften über die TCP/IP-Verbindung 516 empfangen, welche die Netzwerkverwaltungsanzeige 518 beeinflussen. Die Einrichtungssteuerung 514 kann mit der Anzeigensteuerung 518 verbunden sein, wenn die Einrichtungssteuerung 514 eine Alarmgegebenheit von der Netzwerkeinrichtung 510, 520 über Befehlsverbindungen 512, 522 empfängt. Die Event-Aufzeichnungseinrichtung 534 kann Netzwerkprüfungen und Netzwerk-Events von der IC-506-Einrichtungssteuerung 514 über eine UDP/IP-Verbindung 532 empfangen. Wie zuvor beschrieben, kann jeder der Kommunikationsprozesse in 5 unterbrechend oder zyklisch abfragend betrieben werden.
  • Andere Ausführungsformen und Verwendungen der Erfindung werden einem Fachmann bei Betrachtung der Beschreibung und der Ausführung der hierin beschriebenen Erfindung offensichtlich. Die Beschreibung und die Beispiele sollen nur als beispielhaft angesehen werden. Der Umfang der Erfindung wird nur durch die hier beigefügten Ansprüche begrenzt.

Claims (19)

  1. System zum Steuern eines Netzwerks von Kommunikationsvorrichtungen (44, 46, 48, 50, 51, 56, 57, 58), wobei jede Vorrichtung in dem Netzwerk gemäß einem Sendeplan kommuniziert, welcher eine Zuordnung von Senderessourcen zwischen den Vorrichtungen festlegt und welcher durch eine Verwaltungskomponente (MC) des Systems festgelegt ist, wobei das System aufweist: eine Verwaltungskomponente, die den Sendeplan für alle Kommunikationsvorrichtungen in dem Netzwerk steuert; und eine oder mehrere Implementierungskomponenten (IC), die eine oder mehrere Kommunikationsvorrichtungen in dem Netzwerk gemäß den Anweisungen von der Verwaltungskomponente steuern, wobei jede Implementierungskomponente aufweist: eine Empfangseinrichtung zum Empfangen von mindestens einem Sendeplan von der Verwaltungskomponente; und eine Ausgabeeinrichtung zum Ausgeben eines Befehls an eine Kommunikationsvorrichtung, welche durch die Implementierungskomponente gesteuert wird, um den Sendeplan zu implementieren, anstatt eines Sendeplans, welcher im Moment durch die Kommunikationsvorrichtung benutzt wird, wobei das System dadurch gekennzeichnet ist, dass: der Übertragungsplan eine zeitplanmäßige Implementierungszeit zum Ändern des Sendeplans für eine oder mehrere Vorrichtungen in dem Netzwerk aufweist; jede Implementierungskomponente des Weiteren eine Decodierungseinrichtung zum Decodieren der zeitplanmäßigen Implementierungszeit für den Sendeplan aus dem Sendeplan, welcher durch die Empfangseinrichtung empfangen wird, aufweist; und die Implementierungskomponente den Sendeplan zu der spezifizierten Implementierungszeit implementiert.
  2. System nach Anspruch 1, wobei die Kommunikationsvorrichtungen Sender aufweisen und wobei die Verwaltungskomponente vorbestimmte Sendemedien-Ressourcen auf die Sender abbildet.
  3. System nach Anspruch 2, wobei der Sendeplan mindestens eine spezifische festgelegte Sendemedien-Ressourcenabbildung ändert und wobei die Ausgabeeinrichtung der Implementierungskomponente das Befehl zum Implementieren des Sendeplans an mindestens einen Sender und an mindestens einen Empfänger, welcher durch die Änderung der Abbildung von der mindestens einen spezifischen festgelegten Sendemedienressource beeinflusst ist, sendet.
  4. System nach einem der vorhergehenden Ansprüche, welches einen Wartungskanal aufweist, der eine Kommunikation zwischen der Verwaltungskomponente und der einen oder mehreren Implementierungskomponenten für eine Kommunikation des Sendeplans zwischen der Verwaltungskomponente und den Implementierungskomponenten ermöglicht.
  5. System nach einem der vorhergehenden Ansprüche, wobei das Netzwerk der Kommunikationsvorrichtungen ein Satellitengestütztes Kommunikationsnetzwerk aufweist und wobei die Kommunikationsvorrichtungen Netzwerkvorrichtungen zum Senden und Empfangen von Nachrichten via Satellit aufweisen.
  6. System nach einem der vorhergehenden Ansprüche, wobei die Verwaltungskomponente aufweist: eine Bestimmungseinrichtung zum Bestimmen der Kommunikationsvorrichtungen in dem Netzwerk, welche durch einen zu implementierenden Sendeplan beeinflusst sind; und eine Sendeplan-Botschafterzeugungseinrichtung zum Erzeugen einer Botschaft, welche einen Sendeplan aufweist, welcher an die Implementierungskomponente zu senden ist, welche die durch den Sendeplan beeinflussten Kommunikationsvorrichtungen steuert.
  7. System nach Anspruch 6, wobei die Verwaltungskomponente des Weiteren aufweist: eine Plansendeeinrichtung zum Senden des Sendeplans an alle Implementierungskomponenten, welche die durch den Übertragungsplan beeinflussten Kommunikationsvorrichtungen steuern.
  8. System nach Anspruch 6 oder 7, wobei die Verwaltungskomponente des Weiteren eine Quittungsfrist-Überwachungseinrichtung zum Bilden einer Quittungsfrist aufweist, durch welche alle Implementierungskomponenten, welche die durch den Transmissionsplan beeinflussten Kommunikationsvorrichtungen steuern, veranlasst werden eine Quittung zu senden, und wobei Quittungen zum Überwachen von all diesen Implementierungskomponenten.
  9. System nach Anspruch 8, wobei die Verwaltungskomponente des Weiteren ein Abbruchbotschaftsvorrichtung zum Senden einer Abbruchsbotschaft an alle Implementierungskomponenten beinhaltet, welche die durch den Sendeplan beeinfluss ten Kommunikationsvorrichtungen steuert, falls eine Quittung nicht von all den Implementierungskomponenten erhalten wird, welche die Kommunikationsvorrichtungen steuert, welche durch einen Sendeplan vor der Quittungsfrist beeinflusst sind.
  10. System nach Anspruch 8 oder 9, wobei die Sendeplanbotschaft eine Zahlenfolge für eine spezifische Kommunikationsvorrichtung aufweist und wobei die Zahlenfolge benutzt wird, um zu bestimmen, ob eine Quittung von allen Implementierungskomponenten, an die der Sendeplan gesandt wurde, empfangen ist.
  11. System nach einem der vorhergehenden Ansprüche, in welchem das Netzwerk eine Kombination aus einem oder mehreren des Folgenden aufweist: ein diskretes Bandbreiten-Zuordnungsnetzwerk, welches durch ein externes System verwaltet wird, ein halb-programmierbares mittleres Netzwerk, wobei eine variierende Anzahl an Bandbreiten von einer extern verwalteten Ressource zugeordnet werden kann, und ein voll programmierbares Netzwerk, wobei die Ressourcen durch eine Netzwerkverwaltungskomponente verwaltet werden.
  12. System nach einem der vorhergehenden Ansprüche, wobei das Netzwerk der Kommunikationsvorrichtungen ein TCP/EP-Netzwerk aufweist und wobei die Kommunikationsnetzwerkvorrichtungen eine Netzwerkvorrichtung aufweisen, welche ausgebildet ist, das TCP/IP-Protokoll nutzende Nachrichten zu senden und zu empfangen.
  13. Verfahren zum Steuern eines Netzwerkes von Kommunikationsvorrichtungen, wobei jede Vorrichtung in dem Netzwerk gemäß einem Sendeplan kommuniziert, welcher die Zuordnung von Senderessourcen zwischen den Vorrichtungen festlegt, und welcher durch eine Verwaltungskomponente des Systems spezifiziert ist, wobei das Verfahren die Schritte aufweist: Empfangen von mindestens einem Sendeplan von der Verwaltungskomponente, welche basierend auf einer Leistungsauswertung eines bestehenden Sendeplans bestimmt wird; und Ausgeben eines Befehls an eine Kommunikationsvorrichtung, welche durch eine Implementierungskomponente gesteuert ist, um den Sendeplan anstatt eines Sendeplans, welcher im Moment durch diese Kommunikationsvorrichtung verwendet wird, zu implementieren, dadurch gekennzeichnet ist, dass: das Verfahren des Weiteren aufweist: Decodieren einer zeitplanmäßigen Implementierungszeit für den Sendeplan aus dem empfangenen Sendeplan, wobei die zeitplanmäßige Implementierung Zeit zum Ändern des Sendeplans für eine oder mehrere Vorrichtungen in dem Netzwerk aufweist; und Implementieren des Sendeplans zu der spezifizierten Implementierungszeit.
  14. Verfahren nach Anspruch 13, wobei der Sendeplan zumindest eine spezifizierte vorbestimmte Übertragungsmedien-Ressourcenabbildung ändert und wobei eine Ausgabeeinrichtung der Implementierungskomponente ein Befehl zum Implementieren des Sendeplans an mindestens einen Sender und mindestens ein Empfänger sendet, welcher auf die mindestens eine spezifische vorbestimmte Sendemedienressource, welche durch den Sendeplan geändert ist, abgebildet wird.
  15. Verfahren nach den Ansprüchen 13 oder 14, welches des Weiteren die Schritte aufweist: Bestimmen der Kommunikationsvorrichtungen in dem Netzwerk, welche durch einen zu implementierenden Sendeplan beeinflusst sind; Erzeugen einer Botschaft, welche einen Sendeplan enthält, welcher an die Implementierungskomponente zu senden ist, welche die durch den Sendeplan beeinflussten Kommunikationsvorrichtungen steuert; und Senden des Sendeplans an die Implementierungskomponenten, welche die durch den Sendeplan beeinflussten Kommunikationsvorrichtungen steuern.
  16. Verfahren nach Anspruch 15, welches des Weiteren die Schritte aufweist: Ausbilden einer Quittungsfrist, durch welche alle Implementierungskomponenten, welche die durch den Sendeplan beeinflussten Kommunikationsvorrichtungen steuern, veranlasst werden, eine Quittung zu senden; und Überwachen der Bestätigungen von all diesen Implementierungskomponenten.
  17. Verfahren nach Anspruch 16, welches des Weiteren den Schritt aufweist: Senden einer Abbruchsbotschaft an alle Implementierungskomponenten, welche die durch einen Sendeplan beeinflussten Kommunikationsvorrichtungen steuern, falls nicht von allen Implementierungskomponenten, welche durch einen Sendeplan vor der Bestätigungsfrist beeinflusst werden, eine Quittung erhalten wird.
  18. Verfahren nach den Ansprüchen 16 oder 17, wobei die Sendeplanbotschaft eine Zahlenfolge für eine spezifische Kommunikationsvorrichtung aufweist und wobei die Zahlenfolge benutzt wird, um zu bestimmen, ob eine Quittung von all den Implementierungskomponenten erhalten ist, welche die Kommunikationsvorrichtungen steuern, an welche der Sendeplan gesandt wurde.
  19. Verfahren nach einem der Ansprüche 13 bis 18, welches des Weiteren aufweist: Ausführen einer Ereignisanalyse der Netzwerkbenutzung des Netzwerks über eine vorbestimmte Zeitspanne; Bestimmen einer wahrscheinlichen zukünftigen Netzwerkanforderung aus der Ereignisanalyse; und Bilden eines Sendeplans, derart, dass im Wesentlichen die wahrscheinliche zukünftige Netzwerknachfrage befriedigt wird.
DE69920886T 1998-01-23 1999-01-22 Kapazitätszuweisungssystem unter verwendung von halbautonomen netzwerkkomponenten zur durchführung und steuerung eines übertragungsprogramms Expired - Lifetime DE69920886T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US7233998P 1998-01-23 1998-01-23
US72339P 1998-01-23
PCT/US1999/001317 WO1999038274A1 (en) 1998-01-23 1999-01-22 Capacity allocation system using semi-autonomous network elements to implement and control a transmission schedule

Publications (2)

Publication Number Publication Date
DE69920886D1 DE69920886D1 (de) 2004-11-11
DE69920886T2 true DE69920886T2 (de) 2006-03-02

Family

ID=22106972

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69920886T Expired - Lifetime DE69920886T2 (de) 1998-01-23 1999-01-22 Kapazitätszuweisungssystem unter verwendung von halbautonomen netzwerkkomponenten zur durchführung und steuerung eines übertragungsprogramms

Country Status (6)

Country Link
EP (1) EP1062741B1 (de)
AT (1) ATE279048T1 (de)
AU (1) AU2560799A (de)
CA (1) CA2319345C (de)
DE (1) DE69920886T2 (de)
WO (1) WO1999038274A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001043349A2 (de) * 1999-12-09 2001-06-14 Siemens Aktiengesellschaft Dynamische auswahl eines mediumzugriffsverfahrens in kommunikationsnetzen
US7379469B2 (en) 2001-01-12 2008-05-27 Broadcom Corporation System and method for scheduling burst profile changes based on minislot count
US7092715B2 (en) 2001-08-22 2006-08-15 Nokia Corporation Method and apparatus for node adding decision support in a wireless network
US9166886B1 (en) 2013-06-19 2015-10-20 Google Inc. Systems and methods for determining physical network topology

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0456249B1 (de) * 1990-05-10 1998-12-09 Hewlett-Packard Company System zum Integrieren von Anwenderprogrammen in eine heterogene Netzwerkumgebung
US5533023A (en) * 1994-12-16 1996-07-02 Stanford Telecommunications, Inc. Practical means for dynamic allocation of individual demodulators to a multiplicity of received RF signals
US5592470A (en) * 1994-12-21 1997-01-07 At&T Broadband wireless system and network architecture providing broadband/narrowband service with optimal static and dynamic bandwidth/channel allocation
US5689568A (en) * 1995-06-29 1997-11-18 Hughes Electronics Medium access control for a mobile satellite system
US5713075A (en) * 1995-11-30 1998-01-27 Amsc Subsidiary Corporation Network engineering/systems engineering system for mobile satellite communication system
SE508573C2 (sv) * 1995-12-08 1998-10-19 Ericsson Telefon Ab L M Generisk informationsmodell för konfigurering, styrning och hantering av hjälpresurser i ett telekommunikationsnät
US5838907A (en) * 1996-02-20 1998-11-17 Compaq Computer Corporation Configuration manager for network devices and an associated method for providing configuration information thereto
US5724509A (en) * 1996-04-22 1998-03-03 Motorola, Inc. Method and apparatus for synchronizing implementation of configuration information in a communication system

Also Published As

Publication number Publication date
ATE279048T1 (de) 2004-10-15
EP1062741B1 (de) 2004-10-06
CA2319345C (en) 2009-09-08
WO1999038274A1 (en) 1999-07-29
EP1062741A1 (de) 2000-12-27
WO1999038274A9 (en) 1999-10-14
AU2560799A (en) 1999-08-09
DE69920886D1 (de) 2004-11-11
EP1062741A4 (de) 2001-10-04
CA2319345A1 (en) 1999-07-29

Similar Documents

Publication Publication Date Title
US6381250B1 (en) Capacity allocation system using semi-autonomous network elements to implement and control a transmission schedule
DE69834260T2 (de) Verfahren und anordnung zur wiederholer verwaltung
DE19752614C2 (de) Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz
DE60003905T2 (de) System und verfahren zur dynamischen zuteilung der zeit und bandbreite
DE60319058T2 (de) Funkressourcenverwaltung basierend auf Interferenz zwischen mehreren Funkbetreibern
DE10066463B4 (de) Verfahren zur Kommunikation mit verzögerter Bestätigung und Alarmverwaltung
DE69129439T2 (de) Zugriffskoordination von einer Mehrzahl von Basisstationen zu einem schnurlosen Medium
DE60225741T2 (de) Netzwerkverwaltungssystem
DE10062303C2 (de) Verfahren zum Betrieb eines Ad Hoc-Netzwerkes zur drahtlosen Datenübertragung von synchronen und asynchronen Nachrichten
DE60218275T2 (de) Verfahren und Vorrichtung zur Leitweglenkung von Informationen in Satellitenkommunikationsnetzen
DE69224805T2 (de) Lokales Netzwerksystem
DE3638675A1 (de) Rechnergestuetztes schulungssystem und verfahren zur wirtschaftlichen rechnergestuetzten schulung
DE69926477T2 (de) Verfahren und Vorrichtung zur dynamischen Steuerung der Bereitstellung von differenzierter Diensten
EP0996257A2 (de) Netzwerk mit Brücken-Terminal zur Übertragung von Daten zwischen mehreren Sub-Netzwerken
DE69927356T2 (de) Querverbindungskonfigurierungsverfahren in einem funksystem und funksystem
DE60127499T2 (de) Routenaktualisierungsverfahren für ein Mikromobilitätsnetzwerk
DE60311208T2 (de) Unterstützung von mehrfachen logischen Kanälen in einer physikalischen Schnittstelle
DE69935271T2 (de) Verfahren, Gerät, und Steuergerät zur drahtlosen Kommunikation
DE19848342A1 (de) Lokales Netzwerk mit einem Brücken-Terminal zur Übertragung von Daten zwischen mehreren Sub-Netzwerken und zur Schleifendetektion
DE69920886T2 (de) Kapazitätszuweisungssystem unter verwendung von halbautonomen netzwerkkomponenten zur durchführung und steuerung eines übertragungsprogramms
EP0993714A2 (de) Verfahren und system zur steuerung der nutzung von satelliten-übertragungskapazität in terrestrischen netzen
EP1062767A1 (de) Computernetz mit daten- oder kommunikationsendsystemen
EP0996259A2 (de) Automatische Konfigurierung eines Brücken-Terminals zur Uebertragung von Daten zwischen mehreren Sub-Netzwerken in einem lokalen Netzwerk
EP3107219B1 (de) System und verfahren zur redundanten anbindung an ein backbone-netzwerk sowie ein in diesem system einsetzbarer uplink-knoten
WO2004100458A1 (de) Verfahren, system, verwaltungseinheit und endgerät zum erfassen, darstellen und verändern von parametern und parameterwerten, z. b. bandbreite oder kosten, mindestens eines teilstücks einer verbindung zwischen einem server und einem endgerät

Legal Events

Date Code Title Description
8364 No opposition during term of opposition