DE69634505T2 - Lokales Netz zum Übertragen von Daten unter Verwendung von isochronen und asynchronen Kanälen - Google Patents

Lokales Netz zum Übertragen von Daten unter Verwendung von isochronen und asynchronen Kanälen Download PDF

Info

Publication number
DE69634505T2
DE69634505T2 DE69634505T DE69634505T DE69634505T2 DE 69634505 T2 DE69634505 T2 DE 69634505T2 DE 69634505 T DE69634505 T DE 69634505T DE 69634505 T DE69634505 T DE 69634505T DE 69634505 T2 DE69634505 T2 DE 69634505T2
Authority
DE
Germany
Prior art keywords
isochronous
multicast
node
data
transmitter
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
DE69634505T
Other languages
English (en)
Other versions
DE69634505D1 (de
Inventor
Junichi Hamamatsu-shi Fujimori
Tatsutoshi Hamamatsu-shi Abe
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.)
Yamaha Corp
Original Assignee
Yamaha Corp
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 Yamaha Corp filed Critical Yamaha Corp
Publication of DE69634505D1 publication Critical patent/DE69634505D1/de
Application granted granted Critical
Publication of DE69634505T2 publication Critical patent/DE69634505T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40058—Isochronous transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40065—Bandwidth and channel allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40117—Interconnection of audio or video/imaging devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H04L2012/6432—Topology
    • H04L2012/6435—Bus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H04L2012/6443—Network Node Interface, e.g. Routing, Path finding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H04L2012/6445—Admission control
    • H04L2012/6448—Medium Access Control [MAC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/64—Hybrid switching systems
    • H04L12/6418—Hybrid transport
    • H04L2012/6445—Admission control
    • H04L2012/6456—Channel and bandwidth allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols

Description

  • Hintergrund der Erfindung
  • Die vorliegende Erfindung bezieht sich auf ein Netzwerksystem, in dem eine Vielzahl von Knoten über in einem Bus geschaffene logische Pfade miteinander verbunden sind, sowie auf ein Datenübertragungsverfahren, das vorzugsweise in einem Netzwerksystem zur Übertragung von MIDI-Daten (Musical Instrument Digital Interface) und Audiodaten eingesetzt werden kann.
  • In einem neueren AV (audiovisuellen) System, können viele Geräte miteinander verbunden werden, um ein Netzwerk zu bilden. Die Verbindungsmedien, wie zum Beispiel Koaxialkabel, abgeschirmte Kabel und Kabel mit parallelen Aderpaaren werden zum Verbinden elektronischer Geräte miteinander verwendet. Die Situation ist dieselbe wie bei der Verbindung von MIDI-Geräten. Um ein Netzwerk in MIDI-Systemen aufzustellen, werden elektronische Musikinstrumente durch die Koaxialkabel, abgeschirmten Kabel und so weiter miteinander verbunden. Wie oben beschrieben, werden bei den derzeitigen MIDI-Systemen (oder MIDI einsetzenden elektronischen Musikumgebungen) die Verbindungen zwischen den Geräten aus einer Netzwerkstruktur aufgebaut, die durch die physischen Verbindungsmedien hergestellt wird, so dass es mühsam ist, dieselbe Netzwerkkonfiguration in einem anderen Ort wiederherzustellen.
  • Außerdem sind bei einem solchen Netzwerk die Verbindungskabel tendenziell so viele Leitungen vorhanden, dass die Kabel einen großen Platz einnehmen und die Arbeit der Wiederverkabelung nach einem Abschluss der Kabel mühsam ist. Es wird daher eine Netzwerkarchitektur vorgeschlagen, bei der eine Vielzahl von Geräten über ein einziges Kabel miteinander verbunden sind, über das unter den Geräten Daten ausgetauscht werden. Die Protokollschichtstruktur in einer solchen Netzwerkarchitektur ist in 35 gezeigt. Die Protokollschichtstruktur besteht aus einer physikalischen Schicht 102, einer Verbindungsschicht 103, einer Transaktionsschicht 104 und einem seriellen Busmanager 101. Die physikalische Schicht 102 definiert eine die Knoten verbindende physikalische Schnittstelle, führt eine Umwandlung zwischen einem elektrischen Signal und logischen Symbolen durch, die von der Verbindungsschicht 103 verarbeitet werden können. Das elektrische Signal wird über verschiedene serielle Busmedien übertragen. In der Architektur kann die einzige physikalische Schicht 102 Daten durch eine bestimmte Buskonkurrenzbereinigung übertragen. In anderen Worten übertragen die Knoten nie Daten gleichzeitig. Die Verbindungsschicht 103 übernimmt eine Adressierung von Knoten zu Knoten, eine Datenprüfung und eine Datenrahmung, um hierdurch einen unidirektionalen Übertragungsdienst für die Transaktionsschicht 104 bereitzustellen. Die Datenübertragung wird durch ein ACK-Signal von einem die Daten empfangenden Knoten bestätigt. Die Verbindungsschicht 103 stellt auch eine später zu beschreibende isochrone Übertragung bereit. Die Transaktionsschicht 104 stellt einen Zwischen-Knoten-Transaktionsdienst (Anforderungs-Antwort-Protokoll) bereit, der zum Beispiel von IEEE 1212 CSR (Control and Status Register) empfohlen wird. Die Transaktionsschicht 104 stellt jedoch keinen Dienst für isochrone Daten bereit. Der serielle Busmanager 101 ist eine Entität, welche das CSR verwaltet, das die Leistungsmerkmale eines jeden Knoten repräsentiert. Der serielle Busmanager 101 führt eine zentrale Verwaltung isochroner Kanäle und Frequenzbänder der Daten im lokalen Bus durch.
  • Bei der isochronen Übertragung wird normalerweise ein Buszyklus von 125 psec verwendet, so dass ein Knoten mit einem isochronen Kanal innerhalb eines Zyklus ein Datenpaket durch ein Band übertragen kann, das dem Knoten zugeteilt wurde. Außerdem wird bei der isochronen Übertragung ein Paket nicht an einen einzigen Knoten adressiert, sondern wird ein Paket, das mit einer isochronen Kanalnummer etikettiert ist, an alle Knoten gleichzeitig rundgesendet. Bei jedem die isochrone Übertragung unterstützenden Knoten wird jeder Empfang des isochronen Pakets jeweils der Verbindungsschicht 103 mitgeteilt. Die Verbindungsschicht 103 bestimmt je nach der dem Paket zugeordneten Kanalnummer, ob das übertragene Paket akzeptiert werden sollte oder nicht. Eine solche Netzwerkarchitektur wird zum Beispiel in IEEE P1394 "High Performance Serial Bus Standard" ("Norm für einen seriellen Hochleistungsbus") vorgeschlagen. Der serielle Hochleistungsbus der P1394 ist im Detail in Teener, M "A Bus on a Diet – The Serial Bus Alternative" ("Ein Bus auf Diät – Die Alternative für den seriellen Bus"), Proceedings of the Computer Society International Conference (COMP-CON) Spring, Los Alamitos (1992), S. 316–321 (ISBN 0-8186-2655-0) beschrieben. Bei der Netzwerkarchitektur müssen die mehreren Knoten in der physikalischen Ebene lediglich mit einem einzigen Kabel verbunden werden. Bei der isochronen Übertragung erhält ein Senderknoten eine Kanalnummer und ein Band als Ressourcen zur Datenübertragung im Voraus, während ein Empfängerknoten eine Kanalnummer angibt, um Daten von einem entsprechenden Senderknoten zu empfangen. Auf diese Weise kann das von einem Senderport des Sendeknotens rundgesendete isochrone Paket von einem eindeutigen Empfangsport des Empfangsknotens empfangen werden. Wie oben beschrieben, bestimmt die Verbindungsschicht 103, ob das jeweilige gesendete isochrone Paket akzeptiert werden sollte oder nicht. Das akzeptierte Paket wird an eine obere Schicht der Protokollschichtstruktur weitergereicht. Bei einer solchen Netzwerkarchitektur, bei der ein bestimmtes Übertragungsband bei der isochronen Übertragung sichergestellt werden muss, kann es dazu kommen, dass die Übertragung diskreter Daten, wie zum Beispiel einer MIDI-Nachricht, nicht wirkungsvoll ist, weil das erhaltene Band nicht voll genutzt wird, so dass es schwierig ist, den Netzwerknutzungswirkungsgrad zu maximieren.
  • Zusammenfassung der Erfindung
  • Es ist eine Aufgabe der vorliegenden Erfindung, eine Netzwerkarchitektur und ein Datenübertragungsverfahren vorzusehen, bei dem der maximale Netzwerknutzungswirkungsgrad auch in einem Fall realisiert werden kann, in dem die diskreten Daten übertragen werden.
  • Eine weitere Aufgabe der vorliegenden Erfindung ist es, eine Netzwerkarchitektur bereitzustellen, bei der ein Rücksetzen oder Umkonfigurieren des Netzwerks automatisch auch dann vorgenommen werden kann, wenn ein Knoten neu installiert oder entfernt wird, während das Netzwerk in Betrieb ist.
  • Erfindungsgemäß umfasst ein Netzwerksystem eine Vielzahl von Knoten, welche zum Austausch von Informationen und zur Datenübertragung miteinander kommunizieren können. Ein Bus verbindet die Knoten und konfiguriert die logischen Pfade, um einen Knoten mit einem anderen Knoten logisch zu verbinden, um die Datenübertragung sicherzustellen. Dabei besitzt jeder Knoten mindestens einen Anschluss, der dazu ausgelegt ist, für den Zugriff auf den Bus zugewiesen zu werden, und Mittel zur Klassifizierung der Anschlüsse in vier Arten: einen isochronen Sender, einen isochronen Empfänger, einen Multicast-Sender und einen Multicast-Empfänger. Jeder Knoten verknüpft eine isochrone Kanalnummer und ein Datenübertragungsband mit dem isochronen Sender, wenn dieser dafür zugewiesen ist, die Daten, die durch die daran gebundene Kanalnummer gekennzeichnet sind, isochron durch das angebundene Datenübertragungsband an den Bus zu übertragen. Jeder Knoten verknüpft eine isochrone Kanalnummer mit dem isochronen Empfänger, wenn dieser dafür zugewiesen ist, dass der isochrone Empfänger ausschließlich Daten empfangen kann, die von einem anderen isochronen Sender gesendet wurden, welcher einem anderen Knoten zugewiesen ist, falls die gesendeten Daten durch dieselbe isochrone Kanalnummer gekennzeichnet sind, wie die, die mit dem isochronen Empfänger verknüpft ist. Jeder Knoten verknüpft eine Multicast-Kanalnummer mit dem Multicast-Sender, wenn dieser dafür zugewiesen ist, asynchrone Daten, die durch die damit verknüpfte Multicast-Kanalnummer gekennzeichnet sind, an den Bus zu senden. Jeder Knoten verknüpft eine Multicast-Kanalnummer mit dem Multicast-Empfänger, wenn dieser dafür zugewiesen ist, dass der Multicast-Empfänger ausschließlich Daten empfangen kann, die von einem anderen Multicast-Sender gesendet wurden, welcher einem anderen Knoten zugewiesen ist, falls die gesendeten Daten durch dieselbe Multicast-Kanalnummer gekennzeichnet sind, wie die, die mit dem Multicast-Empfänger verknüpft ist.
  • In einer spezifischen Ausführungsform wird ein Datenübertragungsknoten betrieben, der entweder den isochronen Sender oder den Multicast-Sender hat, der dazu ausgelegt ist, zu arbeiten, wenn die logischen Pfade zurückgesetzt sind, um Senderinformation zu übertragen, welche Ressourcen repräsentiert, einschließlich einer isochronen Kanalnummer, eines Datenübertragungsbands und einer Multicast-Kanalnummer, die auf Zurücksetzen der logischen Pfade hin neu mit dem isochronen Sender bzw. dem Multicast-Sender verknüpft werden können, während ein Empfängerknoten, der entweder den isochronen Empfänger oder den Multicast-Empfänger hat, dazu ausgelegt ist, zu arbeiten, wenn die übertragene Senderinformation empfangen wird, um die Ressourcen einschließlich einer isochronen Kanalnummer und einer Multicast-Kanalnummer mit dem isochronen Empfänger und dem Multicast-Empfänger neu zu verknüpfen und dadurch die logischen Pfade wiederherzustellen. Außerdem speichert der Empfängerknoten Pfadinformationen, welche die logischen Pfade repräsentieren und verknüpft die Ressourcen entsprechend der übertragenen Senderinformation und der gespeicherten Pfadinformation neu, um die Übereinstimmung zwischen den Ressourcen des Empfängerknotens und den Ressourcen des Senderknotens hinsichtlich der isochronen Kanalnummer und der Multicastkanalnummer sicherzustellen.
  • In einer anderen spezifischen Ausführungsform hat jeder Knoten eine Kommunikationsarchitektur die aus Protokollebenen einschließlich einer Transportebene, beinhaltend einen isochronen Manager zum Erfassen von isochronen Ressourcen und zum Verknüpfen der erfassten isochronen Ressourcen entweder mit dem zugewiesenen isochronen Sender oder mit dem isochronen Empfänger, einen Multicast-Manager zum Erfassen von Multicast-Ressourcen entweder an den zugewiesenen Multicast-Sender oder den Multicast-Empfänger, sowie einen Pfad-Informationsmanager, der mit dem isochronen Manager und dem Multicast-Manager zusammenwirkt, um eine obere Protokollebene mit einem Service bereitzustellen, um die logischen Pfade zu setzen und um die gesetzten logischen Pfade zu verwalten.
  • In einer weiteren spezifischen Ausführungsform ist einem Übertragungsknoten der isochrone Sender und der Multicast-Sender zugewiesen, wobei der Übertragungsknoten wiederholt Übertragungszyklen ausführt, die eine isochrone Übertragung von Daten über den isochronen Sender und ein asynchrones Senden von Daten über den Multicast-Sender beinhaltet; und so dass der Übertragungsknoten entsprechend der Eigenschaft der Daten und der Verfügbarkeit des isochronen Senders und des Multicast-Senders die Daten in jedem Übertragungszyklus an den isochronen Sender oder an den Multicast-Sender verteilt. Zum Beispiel verarbeitet der Übertragungsknoten eine Mischung kontinuierlicher Musikdaten und diskreter Musikdaten und verteilt die kontinuierlichen Musikdaten an den isochronen Sender, während er die diskreten Musikdaten an den Multicast-Sender verteilt.
  • Wie oben dargelegt, können erfindungsgemäß virtuelle logische Pfade im Netzwerksystem unabhängig von der physikalischen Verbindungstopologie konfiguriert werden. Wenn zwei Knoten oder Geräte an das Netzwerksystem angeschlossen sind, kann zwischen den zwei Geräten unabhängig vom physikalischen Standort der Geräte eingerichtet werden, und können Daten über den logischen Pfad ausgetauscht werden. Daher können die Daten über den virtuellen logischen Pfad ausgetauscht werden, der nicht von der Netzwerktopologie abhängt, so dass bei der Verbindungsabfolge der Geräte niemals Fehler auftauchen und die Daten zuverlässig übertragen werden können. Die logische Verbindung kann ganz einfach modifiziert werden, ohne dass dabei die physische Verbindung der Geräte verändert zu werden braucht, da der virtuelle Pfad logisch unter den Geräten konfiguriert ist. Die Information über den virtuellen Pfad, welche die logische Pfadkonfiguration repräsentiert, ist in jedem an das Netzwerk angeschlossenen Gerät gespeichert. Daher kann die gesamte Pfadinformation des ganzen Netzwerksystems in einem Speichermedium gespeichert werden, und dieselbe Netzwerksystemkonfiguration kann einfach und sofort wiederhergestellt werden, indem die gesicherte Pfadinformation vom Speichermedium geladen wird. Außerdem ermöglicht es die vorliegende Erfindung, nicht nur eine isochrone Übertragung zu verwenden, bei der das Band der Übertragung sichergestellt ist, sondern auch eine Multicast-Übertragung, bei der die Daten nach Bedarf an Bestimmte der vielen Knoten übertragen werden kann. Daher können die Daten effizient übertragen werden, unabhängig davon, wie die diskreten Daten erzeugt werden. Außerdem können die Musikdaten, wie zum Beispiel die MIDI-Daten und die Audiodaten, die eine Echtzeitübertragung erfordern, wirkungsvoll übertragen werden.
  • Kurzbeschreibung der Zeichnungen
  • 1 ist ein schematisches Blockdiagramm, das eine Datenkommunikation in einem mLAN gemäß der vorliegenden Erfindung zeigt.
  • 2 ist ein schematisches Blockdiagramm, das eine Protokollschichtstruktur in dem erfindungsgemäßen mLAN zeigt.
  • 3 ist ein schematisches Blockdiagramm, das eine Multicast-Übertragung im mLAN zeigt.
  • 4 ist ein tabellarisches Diagramm, das ein Format einer Pfadinformationstabelle zeigt.
  • 5 ist ein tabellarisches Diagramm, das ein Format einer Knoteninformationstabelle zeigt.
  • 6 ist ein tabellarisches Diagramm, das ein Format einer Multicast-Informationstabelle zeigt.
  • 7 ist ein tabellarisches Diagramm, das ein Format einer isochronen Informationstabelle zeigt.
  • 8 ist eine Tabelle, die ein Format eines Portinformationseintrags zeigt.
  • 9 ist ein tabellarisches Diagramm, das ein Format eines Sprecher-Informations-Berichtspakets zeigt.
  • 10 ist ein Fließdiagramm, das Akquisitions- und Verknüpfungsvorgänge isochroner Ressourcen durch einen isochronen Manager zeigt.
  • 11 ist ein Fließdiagramm, das den isochronen Ressourcenverknüpfungsvorgang zeigt.
  • 12(a) und 12(b) sind Fließdiagramme, die isochrone Dateneintrags- und isochrone Übertragungsvorgänge durch den isochronen Manager zeigen.
  • 13(a) und 13(b) sind Fließdiagramme, die isochrone Datenempfangs- und Sprecherduplikations-Erfassungsvorgänge durch den isochronen Manager zeigen.
  • 14 ist ein Fließdiagramm, das einen Sprecher-Informations-Aktualisierungsvorgang durch den isochronen Manager zeigt.
  • 15 ist ein Fließdiagramm, das einen Bus-Rücksetz-Abwicklungsvorgang durch den isochronen Manager zeigt.
  • 16 ist ein Fließdiagramm, das einen Bus-Rücksetz-Abschluss-Mitteilungs-Empfangsvorgang durch den isochronen Manager zeigt.
  • 17 ist ein Fließdiagramm, das Akquisitions- und Verknüpfungsvorgänge von Multicast-Ressourcen durch einen Multicast-Manager zeigt.
  • 18 ist ein Fließdiagramm, das den Verknüpfungsvorgang der Multicastressourcen durch den Multicast-Manager zeigt.
  • 19 ist ein Fließdiagramm, das einen Multicast-Übertragungsvorgang durch den Multicast-Manager zeigt.
  • 20 ist ein Fließdiagramm, das einen Multicast-Empfangsvorgang durch den Multicast-Manager zeigt.
  • 21 ist ein Fließdiagramm, das einen Sprecher-Informations-Aktualisierungsvorgang durch den Multicast-Manager zeigt.
  • 22 ist ein Fließdiagramm, das einen Bus-Rücksetz-Abwicklungsvorgang durch den Multicast-Manager zeigt.
  • 23 ist ein Fließdiagramm, das einen Bus-Rücksetz-Abschluss-Mitteilungs-Empfangsvorgang durch den Multicast-Manager zeigt.
  • 24 ist ein Fließdiagramm, das einen Pfadkonfigurationsvorgang durch einen PIM zeigt.
  • 25 ist ein Fließdiagramm, das eine Datenübertragung an einen Pfad durch den PIM zeigt.
  • 26 ist ein Fließdiagramm, das einen Pfad-Lösevorgang durch den PIM zeigt.
  • 27 ist ein Fließdiagramm, das einen Bus-Rücksetz-Abwicklungsvorgang durch den PIM zeigt.
  • 28 ist Fließdiagramm, das einen Vorgang zur Mitteilung eines erfolglosen Ereignisses durch den PIM zeigt.
  • 29 ist ein Fließdiagramm, das einen Sprecher-Informations-Aktualisierungsvorgang durch den PIM zeigt.
  • 30 ist ein Fließdiagramm, das einen Port-Informations-Nachfragevorgang durch einen NIM zeigt.
  • 31 ist ein Fließdiagramm, das einen Abwicklungsvorgang eines Sprecher-Informations-Berichtspakets durch den NIM zeigt.
  • 32 ist ein Fließdiagramm, das einen Bus-Rücksetz-Abwicklungsvorgang durch den NIM zeigt.
  • 33 ist ein Fließdiagramm, das einen Bus-Rücksetz-Abschluss-Abwicklungsvorgang durch den NIM zeigt.
  • 34 ist ein Beispiel einer Datenübertragungs-Zyklusstruktur im mLAN gemäß der vorliegenden Erfindung.
  • 35 ist ein schematisches Blockdiagramm, das eine Protokollschichtstruktur in einem herkömmlichen Netzwerksystem zeigt.
  • 36 ist ein schematisches Blockdiagramm, das eine weitere Ausführungsform des erfindungsgemäßen mLAN zeigt.
  • Detaillierte Beschreibung der Erfindung
  • Es folgt eine Beschreibung eines Netzwerksystems in der Form eines mLAN (Musical Local Area Network/Lokales Musiknetz) gemäß der vorliegenden Erfindung in der folgenden Gliederung:
    • 1. Überblick über ein mLAN
    • 1.1 Überblick über die Datenkommunikation
    • 1.2 mLAN-Protokollschichtstruktur
    • 1.3 mLAN-Transportschicht
    • 1.4 Adressierung bei der Datenübertragung
    • 1.4.1 Pfad
    • 1.4.2 PIM (Pfadinformationsmanager)
    • 2. mLAN-Transportschichtspezifikation
    • 2.1 Dienste bei der mLAN-Transportschicht
    • 2.1.1 Port
    • 2.2 Struktur einer mLAN-Transportschicht
    • 2.3 Isochroner Übertragungsdienst
    • 2.3.1 Isochroner Manager
    • 2.3.2 Akquirieren und Verknüpfen isochroner Ressourcen
    • 2.3.3 Verknüpfen isochroner Ressourcen
    • 2.3.4 isochrone Datenübertragung
    • 2.3.5 Isochroner Datenempfang
    • 2.3.6 Erfassung einer Sprecherduplikation
    • 2.3.7 Kommunikation mit unterer Schicht
    • 2.3.8 Kommunikation mit PIM
    • 2.3.9 Bus-Rücksetzabwicklung
    • 2.3.10 Sprecherinformationsmodifikation
    • 2.3.11 Kommunikation mit NIM
    • 2.4 Multicast-Übertragungsdienst
    • 2.4.1 Multicast-Manager
    • 2.4.2 Akquirieren und Verknüpfen von Multicast-Ressourcen
    • 2.4.3 Sprecherinformationsaktualisierung
    • 2.4.4 Multicast-Datenübertragung
    • 2.4.5 Verknüpfen von Multicast-Ressourcen
    • 2.4.6 Multicast-Datenempfang
    • 2.4.7 Kommunikation mit unterer Schicht
    • 2.4.8 Kommunikation mit PIM
    • 2.4.9 Kommunikation mit NIM
    • 2.4.10 Bus-Rücksetzabwicklung
    • 2.5 PIM (Pfadinformationsmanager)
    • 2.5.1 Pfadeinstellung
    • 2.5.2 Datenübertragung an den Pfad
    • 2.5.3 Lösen des Pfads
    • 2.5.4 Busrücksetzung, Sprecher-Informationsabwicklung und Mitteilung über erfolgloses Ereignis
    • 2.5.5 Kommunikation mit NIM
    • 2.6 NIM (Knoteninformationsmanagement)
    • 2.6.1 Portinformationsanfrage
    • 2.6.2 Sprecherinformations-Berichts-Paketabwicklung
    • 2.6.3 Kommunikation mit unterer Schicht
    • 2.6.4 Bus-Rücksetzabwicklung
    • 2.7 mLAN-Transportschichtfähigkeiten
    • 2.7.1 Pfadinformationstabelle
    • 2.7.2 Knoteninformationstabelle
    • 2.7.3 Multicast-Informationstabelle
    • 2.7.4 Isochrone Informationstabelle
    • 2.7.5 Portinformationseintrag
    • 2.7.6 Senderinformations-Berichtspaket
    • 2.8 mLAN-Zyklusstruktur
    • 2.9 Die Verwendung von Multicast-Sendung und isochroner Sendung
    • 2.10 Plug-and-Play
  • 1. Überblick über ein mLAN
  • 1.1 Überblick über die Datenkommunikation
  • 1 zeigt den Betrieb einer Datenkommunikation im mLAN. Wie in 1 gezeigt, sind die Knoten #1 und #2, die Knoten #2 und #3 bzw. die Knoten #3 und #4 über physische Kabel miteinander verbunden. Ein Sprecherport und ein Hörerport sind als eine logische Entität in einem jeden Knoten definiert. Diese Ports sind die obersten Zugangspunkte, über die direkt von einer Host-Anwendung in jedem Knoten zugegriffen werden kann. Im Netzwerksystem der vorliegenden Erfindung werden zwischen einem Paar Ports virtuelle Datenpfade (logische Pfade) eingerichtet, so dass die Daten über die virtuellen Pfade übertragen werden können.
  • In dem Fall, dass die virtuellen Pfade, wie in 1 gezeigt, ausgebildet sind, kann der Knoten #1 über den virtuellen Pfad zwischen dem Sprecherport 1-T1 des Knotens #1 und dem Hörerport 4-R2 des Knotens #4 an den Knoten #4 Daten übertragen. Der Knoten #3 kann über die virtuellen Pfade, die zwischen dem Sprecherport 3-T1 des Knotens #3 und demjenigen des Hörerports 1-R1 des Knotens #1, des Hörerports 2-R1 des Knotens #2 und des Hörerports 4-R1 des Knotens #4 Daten an die Knoten #1, #2 bzw. #4 übertragen.
  • Beim mLAN ist die isochrone Übertragung als eines der Übertragungsverfahren spezifiziert, durch welche eine Echtzeit-Datenübertragung durch das Akquirieren eines notwendigen Bands im Voraus zum Steuern einer Signallaufzeit bewerkstelligt werden kann. Die isochrone Übertragung besetzt das Band jedoch ständig, so dass die isochrone Übertragung zur Übertragung diskreter Daten, wie zum Beispiel von MIDI-Nachrichten nicht wirkungsvoll funktioniert. Deshalb wird zusätzlich zur isochronen Übertragung beim mLAN eine asynchrone Multicast-Übertragung eingeführt, durch welche Daten von einem Knoten an eine Vielzahl anderer Knoten übertragen werden können. Die Daten können von einem Knoten an die anderen Knoten sowohl durch die isochrone Übertragung als auch durch die Multicast-Übertragung gesendet werden. Außerdem wird auch das Konzept eines "Kanals" für die asynchrone Paketübertragung im mLAN eingeführt.
  • Die eingeführte asynchrone Multicast-Übertragung ist eine Art "Hörer-Initiative", bei der ein Hörer (Empfänger) ein von einem Sprecher (Sender) rundgesendetes Paket selektiv empfängt. Bei diesem Verfahren kann ein einziges Band wirkungsvoll genutzt werden, da ein gemeinsames Paket gut zu übertragen ist, wenn dieselbe Nachricht an eine Vielzahl von Bestimmungsorten zu senden ist. Außerdem ist bei diesem Verfahren die Paketauswahl unter der Steuerung des Hörers, so dass die Arbeitslast des Sprechers sich niemals ändert, auch wenn die Anzahl der empfangenden Knoten erhöht wird. So kann durch Abwälzen eines großen Teils der Datenübertragungssteuerung an die Hörer die Arbeitsbelastung des Sprechers verringert und die Echtzeitleistung der Datenübertragung verbessert werden.
  • 1.2 mLAN-Protokollschichtstruktur
  • 2 zeigt ein Beispiel der mLAN-Protokollschichtstruktur. 2 veranschaulicht die Protokollschichtstruktur des erfindungsgemäßen mLAN gemäß dem OSI-Referenzmodell (Open System Interconnection). Die Protokollschichtstruktur kann in eine Unterschicht-Infrastruktur und eine Oberschicht-Infrastruktur aufgeteilt werden. Die Unterschicht-Infrastruktur entspricht der ersten bis vierten Schicht des OSI-Referenzmodells, während die Oberschicht-Infrastruktur der fünften bis siebten Schicht des OSI-Referenzmodells entspricht. Mittel zum Austauschen von Nachrichten zwischen Anwendungen sind in der Unterschicht-Infrastruktur spezifiziert, während der Inhalt der Nachricht in der Oberschicht-Infrastruktur spezifiziert ist. Die Unterschicht-Infrastruktur richtet logische Pfade ein und bietet einen durchgehenden (end-to-end) Übertragungsdienst für die oberen Schichten. Die Oberschicht-Infrastruktur definiert eine Semantik der Nachrichten und spezifiziert Anwendungsdienste zur Nutzung der Nachrichten.
  • Die Oberschicht besteht aus mLAN-Protokollen 11, welche der Präsentationsschicht (sechste OSI-Schicht) 26 entspricht, sowie einer mLAN-Anwendung 12, welche der Anwendungsschicht (siebte OSI-Schicht) 27 entspricht. Die in der Sitzungsschicht (fünfte OSI-Schicht) 25 implementierten Funktionen werden durch die unteren Schichten durchgeführt, welche die mLAN-Transportschicht 10 enthalten, so dass die mLAN-Oberschicht-Infrastruktur keine der Sitzungsschicht 25 entsprechende Schicht aufweist. Die Gruppe der mLAN-Protokolle 11 spezifiziert verschiedene zusätzliche Steuermechanismen zur Ermöglichung einer wirkungsvollen Übertragung von Musikinformation und sieht verschiedene Datenformate und Kommunikationsprotokolle vor. Die Protokolle enthalten ein MIDI-Übertragungsprotokoll, ein digitales Audio-Übertragungsprotokoll und so weiter. Die mLAN-Anwendung 12 nutzt ein Datenaustauschverfahren, das durch die mLAN-Protokolle 11 definiert ist.
  • Die Unterschicht-Infrastruktur besteht aus einer mLAN-Transportschicht 10, die der Transportschicht (vierte OSI-Schicht) 24 entspricht, einer Transaktionsschicht 3, die der Netzwerkschicht (dritte OSI-Schicht) 23 entspricht, einer Verbindungsschicht 2, die der Datenverbindungsschicht (zweite OSI-Schicht) 22 entspricht, einer physikalischen Schicht 1, die der physikalischen Schicht (ersten OSI-Schicht) 21 entspricht und einer Knotensteuerung 4.
  • Bei der mLAN-Transportschicht 10 ist eine Unteradresse, die als "Port" bezeichnet wird, definiert, um eine Datenkommunikation von Port zu Port zu erzielen und um die Differenz der Spezifikation in der Unterschicht zu absorbieren. Die mLAN-Transportschicht 10 sieht auch eine gemeinsame Dienstschnittstelle für die mLAN-Oberschicht vor, die von der Spezifikation der unteren Schicht unabhängig ist. Wenn es daher untere Schichten gibt, die auf unterschiedlichen Standards aufbauen, ist die mLAN-Transportschicht 10 für jede untere Schicht vorgesehen. Bei der mLAN-Transportschicht 10 sind ein PIM (Path Information Manager/Pfadinformationsmanager) 8, eine isochroner Manager 7, ein Multicast-Manager 6, ein Transaktionsmanager 5 und ein NIM (Node Information Manager/Knoteninformationsmanager) 9 definiert.
  • In der physikalischen Schicht 1 ist eine eine Vielzahl von Knoten verbindende physikalische Schnittstelle spezifiziert, und die physikalische Schicht 1 führt eine Umwandlung zwischen einem elektrischen Signal und logischen Symbolen durch, die von der Verbindungsschicht 2 verarbeitet werden können. Bei dem mLAN wird normalerweise ein Kabel für die physikalische Verbindung verwendet.
  • Die Verbindungsschicht 2 dient einer Adressierung von Knoten zu Knoten, Datenüberprüfung oder -untersuchung und einer Datenrahmung, um so einen unidirektionalen Datenübertragungsdienst für die Transaktionsschicht 3 vorzusehen. Die Datenübertragung wird durch ein ACK-Signal vom Datenempfänger bestätigt. Die Verbindungsschicht 2 sieht auch eine noch zu beschreibende isochrone Übertragung vor.
  • Die Transaktionsschicht 3 sieht einen Zwischen-Knoten-Transaktionsdienst (Anforderungs-Antwort-Protokoll) vor, das zum Beispiel durch IEEE 1212 CSR (Control and Status Register/Steuerungs- und Statusregister)-Architektur empfohlen wird. Die Knotensteuerung (die dem seriellen Busmanager entspricht) 4 ist eine Entität, welche das CSR verwaltet, das die Leistungsmerkmale eines jeden Knotens repräsentiert.
  • 1.3 mLAN-Transportschicht
  • Bei der mLAN-Transportschicht 10 wird die mit "Port" bezeichnete Unteradresse so definiert, dass sie eine Datenkommunikation von Port zu Port ermöglicht. Die mLAN-Transportschicht 10 unterstützt nicht nur die isochrone Übertragung und die asynchrone Paketübertragung, sondern auch die Multicast-Übertragung, die ein Datenübertragungsprotokoll zum Senden von Daten von einem Port an eine Vielzahl anderer Ports ist.
  • 1.4 Adressierung bei der Datenübertragung
  • Bei der Zwischen-Port-Datenübertragung durch die Multicast-Übertragung und die isochrone Übertragung sollte ein Kanal vor der tatsächlichen Übertragung mit einem Port verknüpft sein. Der Senderknoten sollte im Voraus eine Kanalnummer als eine Ressource zum Übertragen von Daten erhalten, während der Empfängerknoten eine Kanalnummer spezifiziert, um Daten von einem Sprecherport des Senderknotens zu empfangen. Die Kanalnummer ist eine der Ressourcen, die den Sende- und Empfangsports bei der Datenübertragung dynamisch zugewiesen wird. Es kann dabei für den Port vor und nach einem Rücksetzen des Busses, wodurch die Pfade initialisiert werden, eine andere Kanalnummer zugewiesen werden. Der Empfangsknoten spezifiziert den entsprechenden Senderknoten mittels einer Knoten-ID. Jedem Knoten wird bei dem Rücksetzen des Busses automatisch eine eindeutige Knoten-ID zugewiesen. Der Benutzer braucht die Knoten-ID im Gegensatz zur SCSI (Small Computer System Interface)-ID-Zuweisung nicht zuzuweisen. Die Eindeutigkeit der Knoten-ID im lokalen Bus wird durch die dynamische Zuweisung durch die physikalische Schicht garantiert. Daher werden die Knoten-ID und die zur Adressierung verwendete Kanalnummer nach einem Rücksetzen des Busses erneut zugewiesen. Die Knoten-ID und die Kanalnummer können vor und nach der erneuten Zuweisung anders sein. Daher kann es sein, dass eine Datenübertragung aufgrund einer Veränderung der Adressabbildung nicht wieder aufgenommen wird, wenn in der Mitte einer isochronen/Multicast-Übertragung ein Rücksetzen des Busses geschieht. Unter der Berücksichtung einer solchen Situation wird Routeninformation, die als "Pfad" bezeichnet wird, in der mLAN-Transportschicht 10 gespeichert, um die Datenübertragungsroute wiederherzustellen, so dass die Datenübertragung auch dann wieder aufgenommen werden kann, wenn nach einem Rücksetzen des Busses die Knoten-ID und die Kanalnummer geändert wurden. Der Benutzer kümmert sich nicht um die Rücksetzung des Busses.
  • 1.4.1 Pfad
  • Der im Port gesetzte Pfad, der die isochrone/Multicast-Übertragung durchführt, ist nicht verbindungsorientiert, sondern stellt eine Art Routeninformation zum Übertragen von Daten an eine Vielzahl von Empfangsport dar. In diesem Fall werden die Daten in einer verbindungslosen Art und Weise übertragen. Die Pfadinformation wird im Bestimmungsknoten der Route gespeichert, und der Pfad wird von der mLAN-Transportschicht 10 wiederhergestellt, nachdem der Bus durch ein Rücksetzen des Busses oder ein Einschaltungsrücksetzen gemäß der gespeicherten Pfadinformation initialisiert wird. Die kontigurierten Pfade werden vom PIM (Path Information Manager/Pfadinformationsmanager) 8 verwaltet.
  • Bei der isochronen/Multicast-Übertragung wird ein Paket von einem Sprecherport eines Quellknotens an Hörerports einer Vielzahl von Bestimmungsknoten übertragen. Es wäre schwierig, Daten in Echtzeit zu übertragen, wenn der Queilknoten das Routing lösen würde, was an der Zunahme der Rechenleistung des Quellknotens liegt. Wenn zum Beispiel der Quellknoten eine Liste von Bestimmungsorten hat und ein aufgelisteter Bestimmungsknoten im Netzwerk nicht gefunden wird, muss der Quellknoten das Routing auflösen. Außerdem kann es sein, dass es einfache Quellknoten, wie zum Beispiel eine Maus und eine Tastatur gibt, die nicht genug Speicherplatz zum Ablegen von Pfadinformation für eine Anzahl von Bestimmungsknoten haben. Deswegen wird die Pfadinformation erfindungsgemäß in den Bestimmungsknoten gespeichert.
  • Wie oben beschrieben, wird die Pfadinformation bei den Empfangsknoten gespeichert, um das Routing zu rekonstruieren, nachdem die Knoten-ID und die Kanalnummer durch das Rücksetzen des Busses geändert wurde. Deswegen sollte die Pfadinformation ein Typ von Information sein, die durch das Rücksetzen des Busses niemals beeinflusst wird. Die Pfadinformation kann Folgendes beinhalten:
    Sprecherport-ID
    Eindeutige Sprecher-Knoten-ID
    Hörer-Port-ID,
    wie in der Tabelle von 4 gezeigt.
  • Die Port-ID wird von Anwendungen bestimmt, und die eindeutige Knoten-ID ist in einer Vorrichtung des Knotens bei der Auslieferung des Geräteprodukts hart codiert. Die eindeutige Knoten-ID wird durch das Rücksetzen des Busses niemals geändert. Beim Rücksetzen des Busses aktualisiert die mLAN-Transportschicht 10 interne Pfadinformation je nach den Veränderungen in der Kanalnummer und der Knoten-ID, um die Routing-Ressource unabhängig von dem Rücksetzen des Busses für die Oberschicht-Anwendungen vorzusehen. Daher können die Anwendungen unabhängig vom Rücksetzen des Busses die Datenübertragung wieder aufnehmen.
  • 1.4.2 PIM (Pfadinformationsmanager)
  • Der PIM (Pfadinformationsmanager) 8, der in der mLAN-Transportschicht 10 definiert ist, ist ein Modul, das jeden der zwischen einem Paar von Ports definierten Pfade verwaltet. Der PIM 8 handhabt die Zuweisung und die Auflösung des Pfads und unterhält die Pfadinformation. Der PIM 8 hat auch eine Funktion zum Wiederherstellen der logischen Pfade gemäß der im Knoten gespeicherten Pfadinformation, was automatisch nach einem Businitialisierungsvorgang geschieht, der durch das Hinzufügen oder Entfernen einer Knotenvorrichtung oder durch ein Einschaltungsrücksetzen verursacht wurde. Der PIM 8 liefert einen Dienst zum Setzen der logischen Pfade zwischen den Ports, die eine isochrone oder Multicast-Übertragung für die Oberschichtanwendungen durchführen. Die Pfadinformation wird im PIM 8 als eine Pfadinformationstabelle, die in 4 gezeigt ist, gespeichert. Das Hinzufügen oder Entfernen einer physikalischen Knotenvorrichtung veranlasst ein Rücksetzen des Busses. Beim Rücksetzen des Busses wird die Knoten-ID dynamisch zugewiesen, so dass die Knoten-ID vor und nach dem Rücksetzen des Busses anders sein kann. Natürlich wirkt sich diese Veränderung der Knoten-ID auf die Knotenadressierung aus. Die Daten könnten also nicht ohne eine Umkonfiguration korrekt übertragen werden. Daher aktualisiert nach einer solchen Buskonfigurationsänderung der PIM 8 die Pfadinformationstabelle, um die korrekte Datenübertragung sicherzustellen. Daher brauchen die Oberschichtanwendungen sich nicht um die Veränderung in der Buskonfiguration zu kümmern. Vorzugsweise bleibt die im PIM 8 gespeicherte Pfadinformation erhalten, während der Strom abgeschaltet ist, weshalb die korrekten Pfade nach einem Einschaltungsrücksetzen wiederhergestellt werden können.
  • 2. mLAN-Transportschichtspezifikation
  • 2.1 Dienste in der mLAN-Transportschicht
  • Die mLAN-Transportschicht 10 sieht drei Arten von Übertragungsdiensten für die obere Schicht vor. Die drei Schichten enthalten die Multicast-Übertragung, eine isochrone Übertragung und eine Transaktion, die wie unten beschrieben gekennzeichnet ist.
  • A. Multicast-Übertragung
  • Die Multicast-Übertragung ist eine asynchrone Datenpaketübertragung, bei der ein Datenpaket von einem Sprecherport an eine Vielzahl von Hörerports übertragen wird. Die Multicast-Übertragung wird von der mLAN-Transportschicht 10 spezifiziert. Bei der Multicast-Übertragung werden Pakete an Zielorte rundgesendet, und es wird niemals eine Bestätigung (ACK) zurückgeschickt. Daher kann der Senderknoten nicht erkennen, ob die Datenübertragung erfolgreich war oder nicht, aber es können die Frequenzbänder des Busses mit einem hohen Wirkungsgrad genutzt werden.
  • B. Isochrone Übertragung
  • Die isochrone Übertragung ist in der Verbindungsschicht 2 spezifiziert. Jeder Knoten sichert ein Band, bevor dieser mit der Datenübertragung beginnt, um einen bestimmten Signalverzögerungsbereich zu sichern, so dass die Gesamtlast des gesamten Netzwerkes vollständig gesteuert wird. Dieses Übertragungsverfahren ist für Situationen geeignet, bei denen ein konstantes Datenvolumen periodisch abgefragt wird oder bei denen eine Datenankunftszeit genau gesteuert werden muss.
  • C. Transaktion
  • Die Transaktion ist ein in der Transaktionsschicht 3 spezifiziertes bidirektionales gleichberechtigtes (peer-to-peer) Übertragungsverfahren. Die Übertragung wird in verbindungsloser Weise durchgeführt, es ist jedoch eine Bestätigungs(ACK)/Neuversuchs-Funktion implementiert, um eine zuverlässige Datenübertragung zu garantieren.
  • 2.1.1 Port
  • Der Port ist ein Dienstzugangspunkt in der mLAN-Transportschicht 10 und wird im Folgenden erläutert. Die obere Schicht kann auf den durch die mLAN-Transportschicht 10 bereitgestellten Dienst über den Port zugreifen. Die oben beschriebenen Übertragungsdienste sind nur zwischen den Ports verfügbar, die eine bestimmte Eigenschaft haben. In anderen Worten kann ein Paket nicht an einen Port ausgeliefert werden, der für den entsprechenden Dienst ungeeignet ist. Die Eigenschaft des Ports wird durch die mit ihm verknüpfte Ressource definiert. Die Ressourcen, die als die Porteigenschaft verknüpft werden können, können wie unten aufgeführt, kategorisiert werden.
  • A. Transaktionsport
  • Eine Portabwicklungstransaktion. Der Transaktionsport führt sowohl das Senden als auch das Empfangen von Daten durch. Eine Adresse im Knoten ist als die Ressource verknüpft.
  • B. Isochroner Sprecher
  • Ein die isochrone Datenübertragung abwickelnder Port. Eine isochrone Kanalnummer und eine isochrone Bandbreite sind als die Ressourcen verknüpft.
  • C. Isochroner Hörer
  • Ein den isochronen Datenempfang abwickelnder Port. Eine isochrone Kanalnummer ist als die Ressourcen verknüpft. Der Hörer kann ein Paket empfangen, das mit derselben Kanalnummer wie diejenige, die mit dem Hörer verknüpft ist, etikettiert ist.
  • D. Multicast-Sprecher
  • Ein die Multicast-Datenübertragung abwickelnder Port. Eine Multicast-Kanalnummer ist als die Ressourcen verknüpft.
  • E. Multicast-Hörer
  • Ein den Multicast-Datenempfang abwickelnder Port. Eine Multicast-Kanalnummer ist als die Ressourcen verknüpft. Der Hörer kann ein Paket empfangen, das durch dieselbe Kanalnummer wie diejenige, die mit dem Hörer verknüpft ist, etikettiert ist.
  • Die Transaktion in der mLAN-Transportschicht 10 kann durch die Ebene der Transaktionsschicht 3 als eine Transaktion zur mit dem Port verknüpften Adresse erkannt werden. Bei diesem Verfahren ist es unmöglich, auf einen Adressort (zum Beispiel einen Eintrag im Konfigurations-ROM) zuzugreifen, der nicht mit einem Port verknüpft ist. Um auf eine solche Ressource zuzugreifen, ist erfindungsgemäß der NIM (Knoteninformationsmanager) 9 vorgesehen. Durch das Ausgeben einer Anfrage an den NIM 9 eines bestimmten Knotens können andere Knoten Knoteninformation (die eindeutige Knoten-ID, Anzahl von Ports im Knoten, Eigenschaften des Ports) eines bestimmten Knotens abrufen.
  • 2.2 Struktur der mLAN-Transportschicht
  • Wie oben beschrieben, besteht die mLAN-Transportschicht 10 aus fünf unten angegebenen Modulen.
  • A. Isochroner Manager 7
  • Der isochrone Manager 7 akquiriert oder erhält Ressourcen (die isochrone Kanalnummer und Bandbreite) zum Durchführen einer isochronen Übertragung und verknüpft die Ressourcen mit dem isochronen Sprecher. Der Manager 7 unterhält auch die erhaltenen isochronen Ressourcen und ihre Verknüpfungsinformation.
  • B. Multicast-Manager 6
  • Der Multicast-Manager 6 erhält eine Kanalnummer zum Durchführen einer Multicast-Übertragung und verknüpft diese mit dem Multicast-Sprecher. Der Manager 6 unterhält auch die erhaltenen Multicast-Ressourcen und ihre Verknüpfungsinformation.
  • C. Transaktionsmanager 5
  • Der Transaktionsmanager 5 verwaltet die Ressourcenverknüpfung mit dem Transaktionsport.
  • D. PIM (Pfadinformationsmanager) 8
  • Der PIM 8 konfiguriert die logischen Pfade zwischen den isochronen und den Multicast-Ports und erhält die konfigurierten logischen Pfade.
  • E. NIM (Knoteninformationsmanager) 9
  • Der NIM 9 fungiert als ein Host-Modul für den Knoten-Controller 4. Der NIM 9 führt eine Konfiguration oder erneute Konfiguration für andere Module gemäß der Änderung des Busstatus durch, die vom Knotencontroller 4 mitgeteilt wird.
  • 2.3 Isochroner Übertragungsdienst
  • Der isochrone Übertragungsdienst wird im Folgenden erläutert. Die die isochrone Datenübertragung abwickelnden Sender- und Empfängerports werden "isochroner Sprecher" bzw. "isochroner Hörer" genannt. Bei der isochronen Datenkommunikation ist ein Buszyklus von zum Beispiel 125 μs spezifiziert, und ein schon über einen isochronen Kanal verfügender Knoten kann in der Menge der erhaltenen Bandbreite Daten übertragen. In dem Fall, wo die isochrone Übertragung einen neu geschaffenen Port als einen isochronen Sprecher nutzt, sollte die Kanalnummer und die Bandbreite mit dem neuen Port verknüpft sein. Bei der isochronen Übertragung wird ein Paket nicht an einen einzelnen Port adressiert, sondern wird an alle Knoten mit einer isochronen Kanalnummer rundgesendet. Der die isochrone Kommunikation unterstützende Knoten teilt alle isochronen Paketankünfte an die Verbindungsschicht 2 mit. Die Verbindungsschicht 2 bestimmt je nach der am ankommenden Paket angebrachten Kanalnummer, ob das Paket angenommen werden sollte oder nicht.
  • 2.3.1 Isochroner Manager
  • Der isochrone Manager 7 ist ein Modul, das in der mLAN-Transportschicht 10 vorgesehen ist und die isochronen Ressourcen im jeweiligen Knoten verwaltet. Der isochrone Manager 7 akquiriert die isochronen Ressourcen (die isochrone Kanalnummer und die Bandbreite) nach Anforderung von den Host-Anwendungen und verknüpft sie mit dem isochronen Sprecher. Nach der Ressourcenverknüpfung bereitet sich der isochrone Sprecher auf die Übertragung eines isochronen Pakets vor. Für den isochronen Hörer wird eine isochrone Kanalnummer verknüpft. Ein mit einer Kanalnummer verknüpfter isochroner Hörer kann ein derselben Kanalnummer zugeordnetes isochrones Paket empfangen. Der isochrone Manager unterhält die durch die oben beschriebenen Vorgang akquirierten Ressourcen. Wenn der Bus durch eine Rücksetzung des Busses initialisiert wird, werden alle für einen isochronen Port akquirierten Ressourcen erneut verknüpft.
  • 2.3.2 Akquirieren und Verknüpfen isochroner Ressourcen
  • Es folgt eine Erläuterung des Erhaltens und Verknüpfens der isochronen Ressourcen anhand von 10. Wenn der isochrone Manager 7 eine Isochron-Manager-Verknüpfungs-Ressourcen-Anforderung empfängt, wird die isochrone Ressource erhalten und, wie oben beschrieben, mit dem isochronen Sprecher verknüpft. In Schritt S10 fordert der isochrone Manager den Busmanager auf, eine isochrone Kanalnummer und eine Bandbreite zuzuweisen. Diese Anforderung wird durch eine exklusive Peer-to-Peer-Transaktion mit dem CSR des Busmanagers durchgeführt. Dann wird das Ergebnis der isochronen Ressourcenakquisition in Schritt S20 getestet. Wenn die Ressourcen erfolgreich erhalten wurden, verknüpft der isochrone Manager 7 die erhaltenen Ressourcen in Schritt S30 mit dem isochronen Sprecher. Der tatsächliche Verknüpfungsvorgang wird jedoch bei der Sprecherinformationsaktualisierung durchgeführt, so dass der Verknüpfungsvorgang in 10 durch einen gestrichelten Block dargestellt ist. Dann wird in Schritt S40 ein Sprecherinformationsberichtspaket, das die erhaltenen Ressourcen wie in 9 formatiert enthält, rundgesendet, um die Erstellung eines isochronen Sprechers mitzuteilen. Dann wird in Schritt S50 das Ergebnis der Ressourcenverknüpfung an den PIM 8 berichtet. In diesem Fall wird der Erfolg der Ressourcenverknüpfung berichtet.
  • Wie in 9 gezeigt, besteht das Sprecherinformations-Berichtspaket aus einer Paket-ID, die anzeigt, dass das entsprechende Paket das Sprecherinformations-Berichtspaket ist, gefolgt einer Sprecherport-ID, einer Sprecherknoten-ID, einer eindeutigen Knoten-ID des Sprechers und einer Sprecherressourceninformation.
  • Wenn die isochronen Ressourcen in Schritt S20 nicht erhalten wurden, wird in Schritt S50 dem PIM 8 das Fehlschlagen mitgeteilt. Nach dem oben gezeigten Vorgang kann der geschaffene isochrone Sprecher isochrone Pakete senden.
  • 2.3.3 Die Verknüpfung isochroner Ressourcen (Hörer)
  • Um isochrone Daten zu empfangen, sollte der isochrone Manager 7 isochrone Ressourcen mit einem isochronen Hörer verknüpfen. Der Verknüpfungsvorgang für isochrone Ressourcen ist in 11 gezeigt. Wenn der isochrone Manager 7 eine Anforderung einer isochronen Ressourcenverknüpfung von der oberen Schicht empfängt, werden die isochronen Ressourcen beschafft und wie unten beschrieben mit dem isochronen Hörer verknüpft. In Schritt S60 verknüpft der isochrone Manager 7 auf der Hörerseite die isochrone Kanalnummer eines entsprechenden Sprechers mit einem als ein isochroner Hörer spezifizierten Port. Auf der Hörerseite muss keine Kanalnummer oder Bandbreit erneut beschafft werden. Eine empfangene Kanalnummer wird einfach mit dem Hörerport verknüpft. Jedoch sollte die mit dem Hörerport verknüpfte Kanalnummer diejenige Nummer sein, die schon vom Sprecherport beschafft wurde. In Schritt S70 wird die Information über den neuerdings verknüpften Hörerport in einer isochronen Informationstabelle des isochronen Managers 7 geschrieben. Die isochrone Informationstabelle ist in 7 veranschaulicht. Wie in 7 gezeigt, enthält eine Tabelle eine Port-ID, einen Port-Typ und isochrone Ressourcen des Sprecher- und des Hörerports. In Schritt S80 wird die in der isochronen Informationstabelle des isochronen Managers 7 enthaltene Liste der empfangenden Kanalnummern zur Verbindungsschicht 2 weitergereicht. Die Verbindungsschicht 2 empfängt alle isochronen Pakete, teilt dem isochronen Manager 7 jedoch nur diejenigen empfangenen Pakete mit, deren Kanalnummern in der Liste der empfangenden Kanalnummern aufgenommen ist. Dann wird in Schritt S90 das Ergebnis der Ressourcenverknüpfung an den PIM 8 berichtet. Die Ressourcenverknüpfung schlägt unter normalen Bedingungen jedoch niemals fehl, und der Erfolg der Ressourcenverknüpfung wird in den meisten Fällen dem PIM 8 berichtet. Wie oben gezeigt, wird die isochrone Ressourceverknüpfung für den Hörerport durchgeführt.
  • 2.3.4 Isochrone Datenübertragung
  • Nach der isochronen Ressourcenverknüpfung für den isochronen Sprecher und Hörer sind die isochronen Pakete zur Übertragung bereit. Beim Übertragungsvorgang werden zuerst Daten angenommen und dann übertragen. Die Annahme isochroner Daten oder deren Eintrag ist in 12(a) veranschaulicht, während die isochrone Datenübertragung in 12(b) gezeigt ist. Wenn der isochrone Manager 7 eine Anforderung zum Übertragen von Daten durch den isochronen Sprecher von dem PIM 8 empfängt, beginnt der Vorgang zum Eintrag isochroner Daten. In Schritt S100 durchsucht der isochrone Manager 7 sein isochrone Informationstabelle, die in 7 gezeigt ist, um die isochrone Kanalnummer zu erhalten, die mit dem spezifizierten isochronen Sprecher verknüpft ist. Dann werden in Schritt S110 die zu übertragenden Daten und die herausgesuchte isochrone Kanalnummer vorrübergehend gespeichert. Diese Pufferung wird durchgeführt, um einen bestimmten Buszyklus abzuwarten, da die isochrone Übertragung tatsächlich mit der Mitteilung eines isochronen Zyklus beginnt. Wenn die isochronen Übertragungsdaten akzeptiert sind und der isochrone Zyklus durch die Verbindungsschicht 2 mitgeteilt wird, wird die isochrone Datenübertragung eingeleitet. Zuerst gibt in Schritt S120 der isochrone Manager 7 eine isochrone Übertragungsanforderung an die Verbindungsschicht 2 aus, wobei er die isochrone Kanalnummer verwendet. Bei diesem Schritt werden auch die Übertragungsdaten an die Verbindungsschicht 2 weitergegeben, und die isochronen Übertragungsdaten werden durch die Verbindungsschicht 2 und die physikalische Schicht 1 an alle Knoten rundgesendet.
  • 2.3.5 Isochroner Datenempfang
  • 13(a) ist ein Fließdiagramm, das einen isochronen Datenempfangsvorgang veranschaulicht, durch den das übertragene Paket empfangen wird. Wenn der isochrone Manager 7 durch die Verbindungsschicht 2 vom Datenempfang informiert wird, startet der Empfangsvorgang. In Schritt S130 durchsucht der isochrone Manager 7 seine eigene isochrone Informationstabelle, die in 7 gezeigt ist, um durch die am Paket angebrachte isochrone Kanalnummer die Zielhörerportnummer zu finden. Dann teilt in Schritt S140 der isochrone Manager 7 dem gefundenen Port den Datenempfang mit und überträgt die empfangenen Daten an diesen Port.
  • 2.3.6 Sprecherduplikationserfassung
  • Übrigens ist nur eine isochrone Kanalnummer mit nur einem isochronen Sprecher verknüpft. Mit anderen Worten überträgt nur ein isochroner Sprecher Pakete unter der Verwendung einer bestimmten isochronen Kanalnummer. Wenn daher der isochrone Manager 7 erkennt, dass mehrere isochrone Sprecher Pakete mit derselben isochronen Kanalnummer senden, stellt der isochrone Manager 7 seine Mitteilung des Datenempfangs an die obere Schicht auf der Ebene der Verbindungsschicht 2 ein und teilt der oberen Schicht die Information mit, dass eine Kanalnummerduplikation besteht. Der Detektionsvorgang der Kanalnummerduplikation ist in 13(b) veranschaulicht. Wenn die Kanalnummer des Sprechers dupliziert ist, teilt die Verbindungsschicht 2 dies dem isochronen Manager 7 mit, der dann die Duplikation dem PIM 8 mitteilt. Die Mitteilung des isochronen Datenempfangs an den PIM 8 wird auf der Ebene der Verbindungssicht 2 unterbrochen.
  • 2.3.7 Kommunikation mit unterer Schicht
  • Beim isochronen Übertragungsdienst kommuniziert der isochrone Manager 7 in der mLAN-Transportschicht 10 mit der Verbindungsschicht 2 unter der Verbindung der unten beschriebenen Dienstelemente. Die mLAN-Transportschicht 10 fordert die Verbindungsschicht 2 auf, ein isochrones Paket unter der Verwendung eines Dienstelements "isochrone Verbindungsanforderung" zu übertragen. Ein Dienstelement "isochrone Verbindungsanzeige" wird durch die Verbindungsschicht 2 an den isochronen Manager 7 ausgegeben, um die Ankunft des isochronen Pakets anzukündigen. Ein Dienstelement "Verbindungszyklus-Startanzeige" wird von der Verbindungsschicht 2 an den isochronen Manager 7 ausgegeben, um den Start des isochronen Zyklus anzuzeigen. Nach Empfang des Dienstelements überträgt der isochrone Manager 7 die Daten unter der Verwendung des Dienstelements "isochrone Verbindungsanforderung". Mit einem Dienstelement "isochrone Verbindungssteuerungsanforderung" gibt der isochrone Manager 7 alle mit dem isochronen Hörern verknüpften Kanalnummern innerhalb des Knotens an die Verbindungsschicht 2 als ein Dienstelement "Kanalempfangsliste" aus. Nach Empfang eines Pakets, dessen Kanalnummer in dem Dienstelement "Kanalempfangsliste" aufgeführt ist, gibt die Verbindungsschicht 2 das Dienstelement "isochrone Verbindungsanzeige" an den isochronen Manager 7 aus.
  • 2.3.8 Kommunikation mit PIM
  • Der isochrone Manager 7 kommuniziert mit dem PIM 8 wie unten beschrieben. Ein Dienstelement "Isochron-Manager-Datenanforderung" wird vom PIM 8 an den isochronen Manager 7 ausgegeben, und der isochrone Manager 7 überträgt durch die Anforderung spezifizierte Daten. Ein Dienstelement "Isochron- Manager-Datenanzeige" wird vom isochronen Manager 7 an den PIM 8 ausgegeben, um dem PIM 8 die Ankunft des isochronen Pakets mitzuteilen. Ein Dienstelement "Isochron-Manager-Ressourcenverknüpfungsanforderung" wird vom PIM 8 an den isochronen Manager 7 ausgegeben, und der isochrone Manager 7 verknüpft Ressourcen mit dem durch das Dienstelement spezifizierten Port. Ein Dienstelement "Isochron-Manager-Ressourcenverknüpfungsbestätigung" wird vom isochronen Manager 7 an den PIM 8 ausgegeben, um in Reaktion auf das Dienstelement "Isochron-Manager-Ressourcenverknüpfungsanforderung" das Ergebnis der Verknüpfung anzuzeigen. Die Dienstelemente "Isochron-Manager-Ressourcenauflösungsanforderung" und "Isochron-Manager-Ressourcenauflösungsbestätigung" werden vom isochronen Manager 7 und dem PIM 8 ausgetauscht, um die schon beschafften Ressourcen wieder aufzulösen.
  • 2.3.9 Busrücksetzabwicklung
  • Wenn dem Bus ein Knoten hinzugefügt wird, wird das Rücksetzen des Busses ausgeführt, um alle logischen Pfade zurückzusetzen, und dann werden die Pfade erneut dadurch konfiguriert, dass den Knoten neue Knoten-IDs zugewiesen werden. In diesem Fall wird nach dem Bus-Rücksetz-Abwicklungsvorgang ein Bus-Rücksetz-Abschluss-Mitteilungsvorgang durchgeführt. Der Bus-Rücksetz-Abwicklungsvorgang ist in 15 veranschaulicht. Wenn eine Rücksetzung des Busses geschieht, gibt der NIM 9 eine Rücksetzanforderung (Isochron-Manager-Steuerungsanforderung (RÜCKSETZEN)) an den isochronen Manager 7 aus, der dann den Bus-Rücksetz-Abwicklungsvorgang einleitet. Nach dem Empfangen der Anforderung weist der isochrone Manager 7 die Isochron-Übertragungsanforderung vom PIM 8 in Schritt S190 ab, wodurch der Bus-Rücksetz-Abwicklungsvorgang durchgeführt wird.
  • Nachdem das Rücksetzen des Busses abgeschlossen ist, gibt der NIM 9 eine Isochron-Manager-Steuerungs-Rücksetzung (INITIALISIEREN) an den isochronen Manager 7 aus. Nach dem Empfangen der Anforderung führt der isochrone Manager 7 den Bus-Rücksetz-Abschluss-Mitteilungsvorgang durch. Der Bus-Rücksetz-Abschluss-Mitteilungsvorgang ist in 16 veranschaulicht. Zunächst ruft in Schritt S200 der isochrone Manager 7 einen Sprechereintrag von der isochronen Informationstabelle ab, die in 7 gezeigt ist, und fordert in Schritt S210 den Busmanager dazu auf, die isochrone Kanalnummer und die Bandbreite zuzuweisen. Diese Aufforderung erfolgt durch eine exklusive Peer-to-Peer-Transaktion mit dem CSR des Busmanagers. Dann wird in Schritt S220 überprüft, ob die isochrone Ressource erfolgreich beschafft wurde oder nicht. Wenn die Ressource erfolgreich beschafft wurde, verknüpft der isochrone Manager 7 die Ressource mit dem isochronen Sprecher. Der tatsächliche Verknüpfungsvorgang wird jedoch in der Sprecherinformationsaktualisierung durchgeführt, so dass der Verknüpfungsvorgang in 16 als ein gestrichelter Block gezeigt ist. In Schritt S240 wird ein Sprecherinformations-Berichtspaket, das die erhaltenen Ressourcen enthält und wie in 9 gezeigt formatiert ist, rundgesendet, um die Schaffung eines isochronen Sprechers mitzuteilen. Dann wird in Schritt S250 das Ergebnis der Ressourcenverknüpfung an den PIM 8 berichtet. In diesem Fall wird der Erfolg der Ressourcenverknüpfung berichtet. Wenn andererseits in Schritt S220 die isochrone Ressource nicht beschafft werden konnte, wird in Schritt S250 dem PIM 8 das Fehlschlagen berichtet. Nach dem Schritt S250 wird überprüft, ob ein Sprechereintrag verbleibt, der noch nicht mit isochronen Ressourcen verknüpft worden ist. Wenn es einen solchen Sprechereintrag gibt, werden die Schritte S200 bis S250 noch einmal durchgeführt, um mit allen Sprechereinträgen isochrone Ressourcen zu verknüpfen. Nachdem alle Sprecherports mit entsprechenden Ressourcen verknüpft sind, wird der Vorgang abgeschlossen. Auf diese Weise ist der isochrone Manager 7 zum Annehmen von Anforderungen von anderen Schichten bereit.
  • 2.3.10 Sprecherinformationsaktualisierung
  • Wenn dem isochronen Manager 7 mitgeteilt wird, dass der NIM 9 ein Sprecherinformations-Berichtspaket mittels der Isochron-Manager-Steuerungsanforderung (Sprecherinfo empfangen) empfangen hat, wird ein Sprecherinformations-Aktualisierungsvorgang durchgeführt. Der Sprecherinformations-Aktualisierungsvorgang ist in 14 veranschaulicht. Zuerst gewinnt der isochrone Manager 7 die Sprecherport-ID und Sprecherressourceninformation von dem Sprecherinformations-Berichtspaket, das das in 9 gezeigte Format hat, und legt gemäß der gewonnen Information einen neuen Sprechereintrag an, um die isochrone Informationstabelle, die in 7 gezeigt ist, zu aktualisieren. Dann wird in Schritt S170 das Sprecherinformations-Berichtspaket an den PIM 8 geleitet, um dem PIM mitzuteilen, dass die Pfadinformation geändert wurde. In Reaktion auf die Mitteilung aktualisiert der PIM 8 die Pfadinformationstabelle, wie noch zu beschreiben ist. In Schritt S180 wird dem NIM 9 die Aktualisierung der isochronen Informationstabelle mitgeteilt. Auf diese Weise wird der Sprecherinformations-Aktualisierungsvorgang nach dem Empfangen des Sprecherinformations-Berichtspakets durchgeführt, das rundgesendet wird, wenn in einem Knoten ein Sprecherport angelegt wird. Die Sprecherinformation wird nicht nur abhängig vom Sprecherinformations-Berichtspaket, das von dem eigenen Knoten rundgesendet wird, aktualisiert, sondern auch abhängig vom Sprecherinformations-Berichtspaket, das von den anderen Knoten rundgesendet wird.
  • 2.3.11 Kommunikation mit NIM
  • Für den isochronen Manager 7 gibt der NIM ein Dienstelement "Isochron-Manager-Steueranforderung" aus, das die unten aufgelisteten Parameter enthält.
    RÜCKSETZEN (RESET): Setzt den Status des isochronen Managers 7 zurück. INITIALISIEREN (INITIALIZE): Initialisiert den Status des isochronen Managers 7.
    SPRECHER-INFO EMPFANGEN: Teilt mit, dass der NIM 9 ein Sprecherinformations-Berichtspaket empfangen hat.
  • Ein Dienstelement "Isochron-Manager-Steuerbestätigung" wird vom isochronen Manager 7 an den NIM 9 ausgegeben, um die Ergebnisse der von der "Isochron-Manager-Steueranforderung" ausgegebenen Steueranforderung zurückzugeben. Der Status des isochronen Managers 7 wird durch ein Dienstelement "Isochron-Manager-Ereignisanzeige" berichtet, das vom isochronen Manager 7 an den NIM 9 ausgegeben wird.
  • 2.4 Multicast-Übertragungsdienst
  • Es folgt eine Beschreibung des Multicast-Übertragungsdienstes. Die Multicast-Datenübertragung ist eine asynchrone und verbindungslose Datenkommunikation, die von einem sendenden Port an eine Vielzahl empfangender Ports durchgeführt wird. Bei der Multicast-Datenübertragung wird der sendende Port als ein "Multicast-Sprecher" und der empfangende Port als ein "Multicast-Hörer" bezeichnet. Die Multicast-Datenübertragung ist in der mLAN-Transportschicht 10 definiert. Der Anwendungsbenutzer sollte ein Multicast-Kanalnummer mit einem Sprecherport verknüpfen, bevor er eine Sendung über den Port beginnt. Dies bedeutet, dass der Sprecherport ein Recht erhält, Daten über den Kanal zu senden. Nur der Multicast-Sprecher kann tatsächlich ein Multicast-Paket unter der Verwendung eines bestimmten Multicast-Kanals senden, vorausgesetzt, der Multicast-Sprecher ist mit der Kanalnummer verknüpft. Das vom Sprecher ausgesendete Paket wird nicht an einen einzigen oder einzelnen Multicast-Hörer adressiert, sondern das Paket wird von der in der Transaktionsschicht 3 definierten Rundsendeeinrichtung an alle Knoten rundgesendet.
  • Wenn ein Multicast-Paket an einem Knoten eintrifft, teilt die Transaktionsschicht 3 dieses Knotens dem Multicast-Manager 6 die Ankunft mit. Am empfangenen Paket ist eine Multicast-Kanalnummer angebracht, die dem entsprechenden Multicast-Sprecher zugewiesen wurde, so dass der Multicast-Manager 6 des Zielknotens durch Überprüfung der angebrachten Kanalnummer bestimmt, ob das Paket angenommen werden sollte oder nicht. Der Multicast-Sprecher kann daher nicht erkennen, welche der Multicast-Hörer tatsächlich mithören.
  • Die mit dem Multicast-Sprecher verknüpfte Multicast-Kanalnummer wird durch den Verknüpfungsvorgang des Multicast-Managers 6 in der mLAN-Transportschicht 10 beschafft. Die mit dem Multicast-Hörer verknüpfte Multicast-Kanalnummer wird von denjenigen ausgewählt, die schon mit den Multicast-Sprechern verknüpft sind.
  • Der Mechanismus der Multicast-Übertragung ist in 3 veranschaulicht. In 3 fungieren die Ports #1 und #3 eines Knotens #1 als ein Multicast-Sprecher. Diese Ports sind mit der Multicast-Kanalnummer #2 bzw. #4 verknüpft. Wenn eine Hostanwendung eine Übertragungsanforderung für den Port #1 des Knotens #1 ausgibt, werden die Daten unter der Verwendung des Kanals #2 an alle Knoten im lokalen Bus rundgesendet. Jeder Knoten empfängt das durch die Rundsendeeinrichtung übertragene Paket. Nach dem Empfang wird das empfangene Paket von der unteren Schicht zur mLAN-Transportschicht 10 weitergeleitet, die das Paket entgegennimmt. In den Knoten #2 und #3 fungiert einer der Ports #2 oder #3 als ein Multicast-Hörer. Die mLAN-Transportschicht 10 im jeweiligen Knoten leitet die Daten des über den Multicast-Kanal #2 übertragenen Pakets an seinen eigenen Multicast-Hörerport weiter. Auf diese Weise wird die Multicast-Übertragung durchgeführt. In ähnlicher Weise wird das an den Port #3 des Knotens #1 gelieferte Paket über den Kanal #4 an den jeweiligen Knoten übertragen. Das Paket wird vom Port #3 (der mit der Multicast-Kanalnummer #4 verknüpft ist) des Knotens #2 empfangen. Auf der anderen Seite ist im Knoten #3 der Multicast-Kanal #4 nicht mit einem Knoten verknüpft, so dass die mLAN-Transportschicht 10 des Knotens #3 das über den Kanal empfangene Paket verwirft.
  • 2.4.1 Multicast-Manager
  • Der Multicast-Manager 6 ist ein Modul, das die Aufgabe hat, eine Multicast-Kanalnummer für einen Port zu erhalten, um die Multicast-Übertragung durchzuführen, und um diese mit dem Port zu verknüpfen. Der Multicast-Manager 6 erhält eine Multicast-Kanalnummer durch Ausgeben eines Sprecherinformations-Berichtspakets. Außerdem empfängt der Manager 6 alle von anderen Knoten innerhalb des lokalen Busses ausgegebenen Sprecherinformations-Berichtspakete zur Schaffung einer Multicast-Informationstabelle, die Korrespondenzen zwischen den Multicast-Kanalnummern und den Multicast-Sprecherports enthält, wie in 6 gezeigt. Nach Empfang des Sprecherinformations-Berichtspakets bestimmt der Multicast-Manager 6 eines jeden Knotens die Multicast-Kanalnummer des Sprechers je nach der Reihenfolge des Empfangs, während die Multicast-Informationstabelle (die in 6 gezeigt ist) organisiert wird. Wenn der Multicast-Manager 6 ein Sprecherinformations-Berichtspaket, das von seinem eigenen Knoten gesendet wurde, empfängt, bestimmt der Multicast-Manager 6 die Multicast-Kanalnummer seines eigenen Knotens. Von einem Multicast-Hörer wird auf die Multicast-Informationstabelle zugegriffen, um nach einer Multicast-Kanalnummer zu suchen, die mit einem entsprechenden Multicast-Sprecher verknüpft ist. Der Multicast-Manager 6 liefert die Verknüpfungsinformation nach einer Anforderung von der Hostanwendung. Der Multicast-Manager 6 ist in jedem Knoten vorgesehen, der einen Multicast-Port (Multicast-Sprecher/Multicast-Hörer) hat, um die Multicast-Datenübertragung durchzuführen.
  • 2.4.2 Erhalten und Verknüpfen von Multicast-Ressourcen
  • Der Vorgang zum Erhalten und Verknüpfen von Multicast-Ressourcen ist unten anhand von 17 erläutert. Der Multicast-Manager 6 führt den Vorgang zum Erhalten und Verknüpfen von Multicast-Ressourcen für einen Port zum Schaffen eines Multicast-Sprechers durch. Der Vorgang wird begonnen, wenn der Multicast-Manager 6 eine "Multicast-Manager-Ressourcenverknüpfungsanfrage" vom PIM 8 der oberen Schicht erhält. In Schritt S600 führt der Multicast-Manager 6 eine Rundsendung eines Sprecherinformations-Berichtspakets für alle Knoten durch. Das Sprecherinformations-Berichtspaket ist wie in 9 gezeigt formatiert und enthält eine erhaltene Multicast-Kanalnummer, die der eindeutigen Knoten-ID und der Port-ID zugeordnet ist. Wenn in Schritt S610 erkannt wird, dass erfolgreich eine Multicast-Kanalnummer erhalten wurde, wird die erhaltene Ressource (Multicast-Kanalnummer) in Schritt S620 mit einem spezifizierten Multicast-Sprecher verknüpft. Dann wird dem PIM das Ergebnis der Ressourcenverknüpfung mitgeteilt. In diesem Fall wird dem PIM 8 mitgeteilt, dass die Verknüpfung erfolgreich war. Wenn auf der anderen Seite erkannt wird, dass die Multicast-Kanalnummerzuteilung fehlgeschlagen ist, geht der Vorgang von Schritt S610 weiter zu Schritt S630, und die entsprechende Mitteilung wird an den PIM 8 geleitet, welche den Vorgang beendet. Der Vorgang der Schritte S610 und S620 ist in gestrichelten Blöcken gezeigt, weil der tatsächliche Ressourcenverknüpfungsvorgang durch Rundsenden eines Sprecherinformations-Berichtspaket im unten beschriebenen Sprecherinformations-Aktualisierungsvorgang geschieht.
  • 2.4.3 Sprecherinformationsaktualisierung
  • Der NIM 9 im jeweiligen Knoten empfängt das rundgesendete Sprecherinformations-Berichtspaket, durch welches der Sprecherinformations-Aktualisierungsvorgang gesteuert wird. Der Sprecherinformations-Aktualisierungsvorgang wird im Folgenden anhand 21 erläutert. Der Vorgang wird eingeleitet, wenn der NIM 9 dem Multicast-Manager 6 den Empfang des Sprecherinformations-Berichtspakets mitteilt. Im Schritt S750 wird zum Zuweisen einer Multicast-Kanalnummer zu jedem Knoten in der Ankunftsreihenfolge des Sprecherinformations-Berichtspakets ein im Multicast-Manager 6 in jedem Knoten vorgesehener Paketzähler um "1" inkrementiert. Der Multicast-Manager 6, dessen Paketzähler bei einem Rücksetzen des Busses auf "0" zurückgesetzt wird, zählt empfangene Sprecherinformations-Berichtspakete nach dem Rücksetzen des Busses. In Schritt S760 aktualisiert der Multicast-Manager 6 die Multicast-Informationstabelle (6), welche die Korrespondenz zwischen der eindeutigen Knoten-ID, der Port-ID und der Multicast-Kanalnummer gemäß dem empfangenen Sprecherinformations-Berichtspakets enthält. Die Port-ID wird von dem Sprecherinformations-Berichtspaket gewonnen, und der Wert des Paketzählers wird als die Ressourceninformation verwendet, um einen Sprechereintrag anzulegen. Dann sendet in Schritt S770 der Multicast-Manager 6 das Sprecherinformations-Berichtspaket zur Mitteilung der Aktualisierung der Pfadinformation an den PIM 8. In Schritt S780 wird dem NIM 9 das Ergebnis der Aktualisierung mitgeteilt, was den Vorgang beendet. Der Multicast-Manager 6, der das Sprecherinformations-Berichtspaket rundgesendet hat, verwendet den Zählerwert zum Zeitpunkt des Empfangs des eigenen Pakets als die Multicast-Kanalnummer, die mit einem Multicast-Sprecher des eigenen Knotens zu verknüpfen ist. Die maximale Anzahl von Multicast-Kanälen im lokalen Bus ist auf 256 (0–255) gesetzt. Wenn der Paket-Zählerwert den Maximalwert überschreitet, berichtet der Multicast-Manager 6 dies an die obere Schicht.
  • 2.4.4 Multicast-Datenübertragung
  • Es folgt eine Beschreibung des Multicast-Datenübertragungsvorgangs anhand von 19. Die Multicast-Datenübertragung wird eingeleitet, wenn der Multicast-Manager 6 von dem PIM 8 der oberen Schicht zu übertragende Daten empfängt. In Schritt S670 durchsucht der Multicast-Manager 6, der die zu übertragenden Daten empfangen hat, die in 6 gezeigte Multicast-Informationstabelle, um die mit dem zu verwendenden Multicast-Sprecher verknüpfte Multicast-Kanalnummer zu erhalten. Dann gibt er in Schritt S680 eine Multicast-Übertragungsanforderung aus, während er die zu übertragenden Daten an die Transaktionsschicht 3 sendet. Auf diese Weise werden die Daten im Multicast-Verfahren gesendet. Bei diesem Verfahren werden die Daten tatsächlich rundgesendet, so dass niemals eine Bestätigung (ACK) zurückkommt.
  • 2.4.5 Verknüpfung von Multicast-Ressourcen (Hörer)
  • Damit ein Multicast-Hörer ein Multicast-Paket empfangen kann, sollte dieselbe Multicast-Kanalnummer, die im Multicast-Paket enthalten ist, im Voraus mit dem empfangenden Hörer verknüpft sein. Die Verknüpfung der Multicast-Ressourcen ist in 18 veranschaulicht. Der Verknüpfungsvorgang wird nach dem Empfang einer "Multicast-Manager-Ressourcenverknüpfungsanforderung" vom PIM 8 eingeleitet. Zuerst wird in Schritt S640 die Multicast-Informationstabelle durchsucht und der spezifizierte Port wird mit der Multicast-Kanalnummer verknüpft, durch die die Daten identifiziert sind. In Schritt S650 werden die Port-ID, der Port-Typ und die Multicast-Ressource (Multicast-Kanalnummer) als ein neuer Eintrag in die Multicast-Informationstabelle eingetragen. In Schritt S660 wird dem PIM 8 das Ergebnis des Verknüpfungsvorgangs mitgeteilt. Die Hörer-Ressourcenverknüpfung schlägt niemals fehl, weil es nur eine Verknüpfungsanforderung zum Verknüpfen der Ressource mit dem Kanal gibt, der schon einem entsprechenden Sprecher zugeordnet ist. Daher wird in diesem Fall dem PIM 8 die erfolgreiche Verknüpfung mitgeteilt, wodurch der Vorgang beendet wird. Nachdem die Multicast-Ressource mit dem Multicast-Hörer verknüpft wurde, können die Multicast-Daten korrekt empfangen werden.
  • 2.4.6 Multicast-Datenempfang
  • Es folgt eine Erläuterung des Multicast-Datenempfangsvorgangs anhand von 20. Der Vorgang wird durch die Mitteilung des Datenempfangs von der Transaktionsschicht 3 begonnen. Zuerst wird in Schritt S700 gegebenenfalls die Sprecherduplikation erfasst. Die Multicast-Kanalnummer, die am Multicast-Paket angebracht ist, ist diejenige, die mit dem Multicast-Sprecher verknüpft ist, der das Paket ausgesendet hat. Dabei darf nur ein Multicast-Sprecher mit einer eindeutigen Multicast-Kanalnummer verknüpft sein. Das heißt also, dass jeder Multicast-Sprecher Pakete unter der Verwendung einer bestimmten Multicast-Kanalnummer versendet. Wenn daher der Multicast-Manager 6 erkennt, dass zwei oder mehr Multicast-Sprecher Pakete gleichzeitig mit derselben Multicast-Kanalnummer aussenden, springt der Vorgang zu Schritt S730 vorwärts, bei dem die Mitteilung des Dateneingangs an den PIM 8 eingestellt wird, und die Duplikation wird mit dem Senden der Kanalduplikations-Nummerinformation an den PIM 8 berichtet. Wenn auf der anderen Seite in Schritt S700 keine Sprecher-Duplikation festgestellt wird, durchsucht der Multicast-Manager 6 die Multicast-Informationstabelle, um den teilnehmenden Hörer-Port zu identifizieren. Wenn dann in Schritt S720 das empfangene Paket die Kanalnummer hat, die mit der Kanalnummer zusammenfällt, die mit dem Multicast-Hörer im Knoten verknüpft ist, wird diesem Hörer der Paketempfang mitgeteilt. Der Multicast-Manager 6 empfängt alle Multicast-Pakete nach der Mitteilung des Dateneingangs von der Transaktionsschicht 3. Der Paketeingang wird dem Multicast-Hörerport im Knoten jedoch erst dann mitgeteilt, wenn die Multicast-Kanalnummer mit derjenigen zusammenfällt, die mit dem Hörer verknüpft ist. Auf diese Weise kann der mitgeteilte Hörer das Multicast-Datenpaket exklusiv empfangen. Wenn es jedoch zwei oder mehr Bestimmungshörer gibt, dupliziert der Multicast-Manager die Daten, um die Daten auch an diese Hörer zu liefern. Für den Fall, dass die angebrachte Multicast-Kanalnummer mit keinem Hörer im Knoten verknüpft ist, wird das Paket verworfen. Wie oben beschrieben, wird der Multicast-Datenempfangsvorgang korrekt durchgeführt.
  • 2.4.7 Kommunikation mit unterer Schicht
  • Wie oben beschrieben, kommuniziert der Multicast-Manager 6 in der mLAN-Transportschicht 10 mit der Transaktionsschicht 3, um die Multicast-Übertragung durchzuführen. Die mLAN-Transportschicht 10 verwendet unten angeführte Dienstelemente, die in der Transaktionsschicht 3 definiert sind.
  • Transaktionsdatenanforderung: Der Multicast-Manager 6 gibt dieses Dienstelement an die Transaktionsschicht 3 aus, um die Multicast-Übertragung einzuleiten. Die Multicast-Übertragung wird unter der Verwendung des Rundsendeleistungsmerkmals in der Transaktionsschicht 3 durchgeführt, so dass eine Eigenschaft RUNDSENDESCHREIBEN als ein Transaktionstyp spezifiziert wird.
  • Transaktionsdatenanzeige: Mit diesem Dienstelement wird dem Multicast-Manager 6 der Dateneingang von der Transaktionsschicht 3 mitgeteilt.
  • 2.4.8 Kommunikation mit PIM
  • Der Multicast-Manager 6 kommuniziert auch mit dem PIM 8. Die unten angeführten Dienstelemente werden für die Kommunikation zwischen dem Multicast-Manager 6 und dem PIM 8 in der oberen Schicht definiert.
  • Multicast-Manager-Datenanforderung: Der PIM 8 gibt dieses Dienstelement an den Multicast-Manager 6 aus. Der Multicast-Manager 6 überträgt die durch das Dienstelement spezifizierten Daten.
  • Multicast-Manager-Datenanzeige: Der Multicast-Manager 6 gibt dieses Dienstelement an den PIM 8 aus, um ihm mitzuteilen, dass der Manager 6 ein Multicast-Paket empfangen hat.
  • Multicast-Manager-Ressourcenverknüpfungsanforderung: Der PIM 8 gibt dieses Dienstelement an den Multicast-Manager 6 aus. Der Multicast-Manager 6 verknüpft Ressourcen mit dem durch das Dienstelement angegebenen Port. Durch dieses Dienstelement gibt der PIM 8 die Port-ID und die Multicast-Kanalnummer weiter, die erforderlich ist, wenn der Typ des durch die Port-ID spezifizierten Ports MULTICASTHÖRER ist.
  • Multicast-Manager-Ressourcenverknüpfungsbestätigung: Der Multicast-Manager 6 gibt dieses Dienstelement an den PIM 8 aus, um die Ergebnisse des Vorgangs zurückzugeben, der in Reaktion auf die Multicast-Manager-Ressourcenverknüpfungsanforderung durchgeführt wurde.
  • 2.4.9 Kommunikation mit NIM
  • Der Multicast-Manager 6 kommuniziert auch mit dem NIM 9, um die Multicast-Datenübertragung durchzuführen. Die unten angeführten Dienstelemente sind zur Durchführung für die Kommunikation zwischen dem Multicast-Manager 6 und dem NIM 9 in der oberen Schicht definiert. Der NIM 9 verwendet diese Dienstelemente zum Rücksetzen bzw. Initialisieren des Status des Multicast-Managers 6.
  • Multicast-Manager-Steueranforderung: Der NIM 9 gibt dieses Dienstelement an den Multicast-Manager 6 aus. Durch dieses Dienstelement werden die unten angegebenen Parameter weitergegeben:
    RÜCKSETZEN (RESET): Setzt den Status des Multicast-Managers 6 zurück.
    INITIALISIEREN: Initialisiert den Status des Multicast-Managers 6.
    SPRECHERINFORMATION EMPFANGEN: Teil mit, dass der NIM 9 das Sprecherinformations-Berichtspaket empfangen hat.
  • Multicast-Manager-Steuerbestätigung: Der Multicast-Manager 6 gibt dieses Dienstelement an den NIM 9 aus, um die Ergebnisse des Vorgangs zurückzugeben, der in Reaktion auf die Multicast-Manager-Steueranforderung durchgeführt wurde.
  • Multicast-Manager-Ereignisanzeige: Der Multicast-Manager 6 gibt dieses Dienstelement an den NIM 9 aus, um den internen Status des Multicast-Managers 6 zu berichten.
  • 2.4.10 Busrücksetzabwicklung
  • Es folgt eine Beschreibung der Durchführung der Rücksetzung des Busses. Wenn in den Bus ein neuer Knoten eingeführt wird, wird der Bus rückgesetzt, um alle Pfade rückzusetzen, und dann werden die Pfade dadurch rekonstruiert, dass den entsprechenden Knoten neue Knoten-IDs zugewiesen werden. In diesem Fall wird der Bus-Rücksetz-Abschluss-Mitteilungsvorgang nach dem Bus-Rücksetz-Abwicklungsvorgang durchgeführt. Der Bus-Rücksetz-Abwicklungsvorgang ist in 22 veranschaulicht. Wenn eine Busrücksetzung geschieht, gibt der NIM 9 eine Rücksetzanforderung (Multicast-Manager-Steueranforderung (RÜCKSETZEN)) an den Multicast-Manager 6 aus, der dann den Bus-Rücksetz-Abwicklungsvorgang einleitet. Nach Empfang der Anforderung setzt der Multicast-Manager 6 in Schritt S800 einen Paketzähler auf "0" zurück. Außerdem löscht der Multicast-Manager 6 die in der Multicast-Informationstabelle gespeicherte Multicast-Kanalnummer und weist die Multicast-Übertragungsanforderungen vom PIM 8 in Schritt S810 zurück, wodurch der Bus-Rücksetz-Abwicklungsvorgang beendet wird.
  • Nachdem die Busrücksetzung abgeschlossen ist, gibt der NIM 9 eine Multicast-Manager-Steuerungsanforderung (INITIALISIEREN) an den Multicast-Manager 6 aus. Nach Empfang der Anforderung führt der Multicast-Manager 6 den Bus-Rücksetz-Abschluss-Mitteilungsvorgang durch. Der Bus-Rücksetz-Abschluss-Mitteilungsvorgang ist in 23 veranschaulicht. Wenn der Multicast-Manager 6 in seiner eigenen Multicast-Informationstabelle eine Port-ID speichert und eine dieser Port-ID entsprechende Multicast-Kanalnummer gelöscht wird, dann bedeutet dies, dass die mit dem Port verknüpfte Multicast-Kanalnummer durch die Busrücksetzung gelöscht wird. Daher gewinnt in Schritt S820 der Multicast-Manager 6 einen Sprechereintrag, dessen Ressource in der Multicast-Informationstabelle gelöscht ist. Dann sendet in Schritt S830 der Manager 6 ein Sprecherinformations-Berichtspaket rund, das die Ressource (die Multicast-Kanalnummer) enthält. In Schritt S840 wird geprüft, ob die Ressource neu erhalten wurde. Wenn die Ressource erhalten wurde, geht der Vorgang weiter zu Schritt S850, wo die Ressource (die erhaltene Multicast-Nummer) mit dem Sprechereintrag verknüpft wird. Dann wird in Schritt S860 dem PIM 8 das Ergebnis der Ressourcenverknüpfung mitgeteilt. In diesem Fall wird dem PIM 8 die erfolgreiche Ressourcenverknüpfung mitgeteilt. Wenn auf der anderen Seite in Schritt S840 erkannt wird, dass die Ressourcenzuweisung fehlgeschlagen ist, wird dem PIM 8 der Fehlschlag mitgeteilt. Die Schritte S840 und S850 aus dem gleichen Grund wie im vorhergehenden Abschnitt 2.4.5 (Verknüpfung von Multicast-Ressourcen) in gestrichelten Blöcken angezeigt. Dann wird in Schritt S870 geprüft, ob es einen verbleibenden Sprechereintrag gibt, der mit keiner Multicast-Ressource verknüpft ist. Wenn es einen solchen Eintrag gibt, wird der Multicast-Ressourcen-Verknüpfungsvorgang dadurch erneut ausgeführt, dass zu Schritt S820 zurückgekehrt wird, um die Ressource mit allen Sprechern zu verknüpfen. Wenn die Multicast-Sprecher mit den Multicast-Ressourcen verknüpft sind, wird der Vorgang beendet.
  • 2.5 PIM (Pfadinformationsmanager)
  • Der PIM (Pfadinformationsmanager) 8 in der mLAN-Transportschicht 10 wird im Folgenden beschrieben. Der PIM 8 ist in der mLAN-Transportschicht 10 vorgesehen, und der PIM 8 setzt oder konfiguriert einen logischen Pfad zwischen einem Sprecherport und einem Hörerport. Der PIM 8 speichert die Pfadinformation, die für den schon konfigurierten Pfad repräsentativ ist, und der PIM 8 konfiguriert nach der durch eine Busrücksetzung verursachten Initialisierung den Pfad um. Der PIM 8 unterhält jedoch die Pfadinformation nur für die Ports zur Abwicklung der beiden Übertragungsmodi, welche die isochrone Übertragung und die Multicast-Übertragung sind, unter den drei Übertragungsmodi, die in der mLAN-Transportschicht 10 definiert sind.
  • Der PIM 8 liefert die unten angegebenen Dienste für die oberen Schichten.
    • A. Pfadkonfiguration/Auflösung: Konfiguriert einen Pfad zwischen Ports, welche die isochrone Übertragung und die Multicast-Übertragung handhaben. Konfigurierte Pfade können auch aufgelöst werden.
    • B. Pfadinformationsspeicher: Speichert die Pfadinformation, welche durch die Dienste des PIM 8 konfiguriert wurden. Der PIM 8 speichert die Pfadinformation auch dann, wenn der Strom abgeschaltet ist, und die logischen Pfade werden gemäß der gespeicherten Pfadinformation neu konfiguriert.
    • C. Neue Konfiguration eines Pfads nach dem Einschalten: Nach der Initialisierung des Busses, die durch ein Einschalten verursacht wurde, konfiguriert der PIM 8 die Pfade automatisch neu und stellt den anfänglichen Status der Pfadkonfiguration wieder her.
    • D. Pfadinformationsaustausch: Nach Anforderung durch Host-Anwendungen fragt der PIM 8 unter der Verwendung eines Pfadinformations-Verwaltungsprotokolls bei anderen Knoten nach der Pfadinformation. Die anderen Knoten enthalten zum Beispiel ein Diskettenlaufwerk.
  • Der PIM 8 liefert auch einen Dienst zum Setzen und Rücksetzen eines Pfads zwischen einem Hörerport an seinem lokalen Knoten und einem Sprecherport an einem entfernten Knoten. Der PIM 8 kann jedoch keinen Pfad zwischen einem Sprecher- und einem Hörerport konfigurieren, wenn sie beide in einem entfernten Knoten sind. Dieses Leistungsmerkmal wird durch den Busmanager als eine Hostanwendung vorgesehen.
  • 2.5.1 Pfadsetzung
  • Der Pfadkonfigurationsvorgang des PIM 8 ist in 24 veranschaulicht. Der Vorgang wird eingeleitet, wenn der PIM 8 eine Anforderung "PIM-Pfad-Setzanforderung" von der Hostanwendung empfängt. Nach Empfang der Anforderung erhält der PIM 8 in Schritt S300 die Eigenschaft eines relevanten Sprecherports. Dann setzt in Schritt S310 der PIM 8 dieselbe Eigenschaft für den relevanten Hörerport als die Eigenschaft des Sprechers, die zuvor in Schritt S300 erhalten wurde. In Schritt S320 fordert der PIM 8 das Modul der unteren Schicht (den isochronen Manager 7, wenn der Porttyp isochron ist, oder den Multicast-Manager 6, wenn der Porttyp Multicast ist), um die Ressourcen zu verknüpfen. Die Ressource wird an diesem Punkt nur mit dem Hörer verknüpft, da der Sprecher schon mit der Ressource verknüpft ist. Wenn der Pfad erfolgreich gesetzt wurde, wird in Schritt S330 die Pfadinformationstabelle aktualisiert. Bei dieser Aktualisierung wird ein Verbindungsflag von "getrennt" in "verbunden" geändert. In Schritt S340 wird das Ergebnis der Pfadkonfiguration an die Hostanwendung in Reaktion auf eine Anforderung von dieser berichtet. In diesem Fall wird der Erfolg der Pfadkonfiguration mitgeteilt. Die oben beschriebene Pfadkonfiguration schlägt niemals fehl, weil die tatsächliche Pfadkonfiguration durch Kopieren der schon erhaltenen Ressourcen des Sprechers auf den Hörer erfolgt. Auf diese Weise wird die Pfadkonfiguration beendet.
  • 2.5.2 Datenübertragung zum Pfad
  • Eine Datenübertragung auf den Pfad ist im Folgenden anhand von 25 beschrieben. Der Übertragungsvorgang wird eingeleitet, wenn der PIM 8 von der oberen Schicht zu übertragende Daten empfängt. In Schritt S360 wird der Typ des Ports zum Senden von Daten durch Bezugnahme auf die Portinformationseinträge identifiziert, die vom NIM 9 unterhalten werden, und wie in 8 gezeigt formatiert sind. In Schritt S370 wird geprüft, ob der Porttyp Sprecher ist oder nicht. Wenn der Porttyp Sprecher ist, wird in Schritt S380 geprüft, ob der Porttyp Multicast ist oder nicht. Wenn der Port sich als ein Multicast-Port herausstellt, überträgt der PIM 8 die Daten an den Multicast-Manager 6. Der Multicast-Manager 6 führt den Multicast-Übertragungsvorgang wie oben beschrieben aus. Wenn es sich herausstellt, dass es sich um einen isochronen Port handelt, geht der Vorgang von Schritt S380 zu Schritt S400 weiter, bei dem die Daten an den isochronen Manager 7 gesendet werden. Der isochrone Manager 7 führt den isochronen Übertragungsvorgang aus, der in 12 gezeigt ist, wodurch der Übertragungsvorgang beendet wird. Wenn in Schritt S370 entdeckt wird, dass der Port kein Sprecher ist, wird der Vorgang beendet.
  • 2.5.3 Pfadauflösung
  • Der Pfadauflösungsvorgang ist in 26 gezeigt. Die bestehende Pfadinformation ist in der durch den PIM 8 am Hörerknoten unterhaltenen Pfadinformationstabelle gespeichert. Der PIM 8 führt den tatsächlichen Pfadauflösungsvorgang durch. Der Pfad wird ohne Bestätigung durch den Sprecher aufgelöst. Wenn der PIM eine Anforderung "PIM-Pfadauflösungsanforderung" von der oberen Schicht empfängt, wird der Pfadauflösungsvorgang eingeleitet. In Schritt S410 prüft der PIM 8, dass der von der Anforderung angegebene Pfad für den entsprechenden Hörerport gesetzt ist, indem die in 4 gezeigte Pfadinformationstabelle durchsucht wird. In Schritt S420 wird geprüft, ob der Pfad in einem verbundenen Zustand gehalten wird oder nicht. Wenn der Pfad verbunden ist, wird die mit dem Hörerport verknüpfte Ressource aufgelöst und in Schritt S430 der entsprechende Eintrag aus der Pfadinformationstabelle gelöscht. Dann wird in Schritt S440 eine Antwort auf die Anforderung an die obere Schicht zurückgegeben. In diesem Fall wird eine erfolgreiche Auflösung berichtet. Wenn in Schritt S420 der Pfad nicht im verbundenen Zustand ist, wird in Schritt S440 eine entsprechende Antwort an die obere Schicht zurückgegeben.
  • 2.5.4 Busrücksetzung, Sprecherinformationsabwicklung und Mitteilung über erfolgloses Ereignis
  • Die mLAN-Transportschicht 10 weist einen Kanal zur Verwendung der asynchronen Multicast-Übertragung dynamisch zu, so dass der Sprecher nach einer Rücksetzung des Busses eine neue Multicast-Kanalnummer erhalten muss. Auf diese Weise kann sich die Multicast-Kanalnummer, die mit einem Sprecher verknüpft ist, vor und nach der Rücksetzung des Busses unterscheiden. Demnach kann der Hörer keine Daten empfangen, ohne dass er dieselbe Kanalnummer wie der Sprecher nach der Rücksetzung des Busses setzt. Daher führt der PIM 8 zuerst einen Bus-Rücksetz-Abwicklungsvorgang und dann einen Sprecherinformations-Aktualisierungsvorgang durch. Der Bus-Rücksetz-Abwicklungsvorgang ist unten anhand von 27 beschrieben. Der Bus-Rücksetz-Abwicklungsvorgang wird eingeleitet, wenn der NIM 9 eine Anforderung "PIM-Steueranforderung (RÜCKSETZEN)" nach dem Rücksetzen des Busses an den PIM 8 ausgibt. Nach Empfang der Anforderung setzt der PIM 8 in Schritt S450 alle Verbindungsflags der Einträge in der Pfadinformationstabelle auf "getrennt". In diesem Zustand wird die Pfadinformationstabelle gehalten, jedoch wird die Datenübertragung gemäß der Pfadinformation abgeschaltet. Nach Abschluss der Busrücksetzung verknüpfen alle Knoten erneut Ressourcen mit isochronen und Multicast-Sprechern in ihren Knoten. Wenn die erneute Verknüpfung der Ressourcen erfolgreich ist, wird die aktualisierte Information über die Sprecher in der Form des Sprecherinformations-Berichtspaket, das wie in 9 gezeigt formatiert ist, rundgesendet.
  • Die Ankunft des Sprecherinformations-Berichtspakets wird von dem Multicast-Manager 6 oder dem isochronen Manager 7 an den PIM 8 (über IM-Ereignis-Anzeige() oder MM-Ereignis-Anzeige()) mitgeteilt, so dass der Sprecherinformations-Aktualisierungsvorgang eingeleitet wird. Der Sprecherinformations-Aktualisierungsvorgang ist in 29 gezeigt. In Schritt S460 sucht der PIM 8 in jedem Knoten die eindeutige Knoten-ID in der Art Pfadinformationstabelle, um den Eintrag des Sprechers herauszufinden, der für das empfangene Sprecherinformations-Berichtspaket relevant ist. Dann wird in Schritt S470 die Eigenschaft dieses Sprechers identifiziert. Außerdem wird in Schritt S480 die Eigenschaft des Hörers identifiziert, der mit dem Sprecher verbunden ist. In Schritt S490 wird geprüft, ob der Sprecher und der Hörer miteinander verbunden werden können. Wenn der Sprecher und der Hörer miteinander verbunden werden können, wird in Schritt S500 geprüft, ob der Porttyp Multicast ist oder nicht. Wenn der Porttyp Multicast ist, fordert der PIM 8 den Multicast-Manager 6 auf, Multicast-Ressourcen zu verknüpfen. Ansonsten, wenn der Porttyp isochron ist, fordert der PIM 8 den isochronen Manager 7 auf, isochrone Ressourcen zu verknüpfen. Nach Empfang der Anforderung verknüpfen diese Unterschichtmodule Ressourcen mit den relevanten Hörern und geben die Ergebnisse an den PIM 8 zurück. Bei der Prüfung der zurückgegebenen Ergebnisse erkennt der PIM 8 in Schritt S530, ob die Ressourcenverknüpfung erfolgreich ist oder nicht. Wenn die Ressource erfolgreich verknüpft ist, wird in Schritt S540 der Verbindungsflag in der Pfadinformationstabelle auf "verbunden" gesetzt. Wenn andererseits der relevante Sprecher und der Hörer nicht miteinander verbunden werden können, wird in Schritt S550 ein Fehlerabwicklungsvorgang durchgeführt. Der Fehlerabwicklungsvorgang in Schritt S550 wird auch durchgeführt, wenn die Ressourcenverknüpfung in Schritt S530 fehlschlägt. Auf diese Weise ist der Sprecherinformations-Aktualisierungsvorgang abgeschlossen.
  • Der PIM 8 führt den Sprecherinformations-Aktualisierungsvorgang immer dann durch, wenn der PIM 8 das Sprecherinformations-Berichtspaket empfängt. Wenn jedoch ein Knoten, der vor Rücksetzung des Busses einen aktiven Sprecher hat, entfernt wird und nach Abschluss der Busrücksetzung nicht mehr existiert, wird das Sprecherinformations-Berichtspaket nicht rundgesendet. In diesem Fall wird der Pfadeintrag, der dem Sprecher des entfernten Knotens entspricht, als "getrennt" belassen, so dass der Pfad nicht wiederhergestellt wird, auch wenn die alte Pfadinformation aufbewahrt wird. In einem solchen Fall wird die Pfadinformation so belassen, wie sie war, so dass der Pfad umkonfiguriert werden kann, wenn in Reaktion auf die Wiederherstellung des einmal entfernten Knotens bei einer nächsten Rücksetzung des Busses ein Sprecherinformations-Berichtspaket rundgesendet wird. Der PIM 8 kann einen Dienst für die obere Schicht bereitstellen, um eine solche "aufbewahrte, jedoch getrennte" Pfadinformation zu löschen. Bei der Neukonfiguration des Pfads können die Hostanwendungen die Datenübertragung vor und nach der Busrücksetzung wieder aufnehmen.
  • Der PIM 8 führt einen in 28 gezeigten Mitteilungsvorgang erfolgloser Ereignisse durch. Der PIM 8 leitet verschiedene Berichte über erfolglose Ereignisse von den Unterschichtmodulen an die Oberschichtmodule weiter.
  • 2.5.5 Kommunikation mit NIM
  • Der PIM 8 sieht die unten angegebenen Dienstelemente zur Kommunikation mit dem NIM 9 vor.
    PIM-Steueranforderung
    PIM-Steuerbestätigung
    PIM-Ereignisanzeige
  • Der NIM 9 verwendet diese Dienstelemente zum Rücksetzen bzw. Initialisieren der PIM-8-Interna.
  • 2.6 NIM (Knoteninformationsmanager)
  • Der NIM 9 ist in der mLAN-Transportschicht 10 des jeweiligen Knotens angeordnet und hat die unten angegebenen Leistungsmerkmale.
  • A. Initialisierung der mLAN-Transportschicht 10 gemäß dem Busstatus
  • Der NIM 9 fungiert als die Oberschicht des Knotencontrollers 4. Der NIM 9 setzt die internen Module der mLAN-Transportschicht 10 rück oder initialisiert sie je nach der Veränderung des Busstatus, der vom Knotencontroller 4 mitgeteilt wird.
  • B. Liefern von Knoteninformation für entfernte Knoten
  • Die mLAN-Transportschicht 10 sieht Dienste zum Austauschen von Daten zwischen Ports vor, doch kann eine Hostanwendung nicht auf die internen Adressen in entfernten Knoten zugreifen. Jeder Knoten hat Register zum Speichern verschiedener Informationen und Konfigurationen, die in ihren internen Adressen residieren. Um auf diese Adressen in entfernten Knoten zuzugreifen, bietet der NIM 9 eine Schnittstelle für Hostanwendungen. Der NIM 9 hat einen Transaktionsport zum Entgegennehmen von Nachfragen von entfernten Knoten. Der Transaktionsport wird als NIM-Port bezeichnet. Die Port-ID des NIM-Ports ist für alle Knoten gleich, und alle Knoten sollten die Port-ID im Voraus kennen. Nach einer Nachfrage gibt der NIM 9 Information, die für die Nachfrage relevant ist, zurück, indem auf die Konfigurations-ROM-Einträge Portinformationseinträge usw. zugegriffen wird.
  • C. Sprecherinformations-Berichtspaket-Abwicklung
  • Das Sprecherinformations-Berichtspaket wird von dem isochronen oder dem Multicast-Manager in dem Fall ausgegeben, dass ein isochroner oder ein Multicast-Sprecherport geschaffen wird. Das Sprecherinformations-Berichtspaket wird für die NIM-Ports aller Knoten ausgegeben, um die Information zu liefern, die für jeden Sprecherport relevant ist. Nach Empfang des Pakets leitet der NIM 9 den Paketinhalt an den isochronen Manager 7 oder den Multicast-Manager 6 weiter. Welcher Manager angesprochen wird, wird auf der Grundlage der mit dem Sprecherport verknüpften Ressource entschieden. Der Betrieb des NIM 9, der die obigen Eigenschaften vorsieht, wird im Folgenden beschrieben.
  • 2.6.1 Portinformationsanfrage
  • Bei der Verknüpfung von Ressourcen mit einem Hörerport innerhalb des eigenen Knotens sollte die Hostanwendung die mit dem entsprechenden Sprecherport verknüpfte Ressource kennen. Um eine solche Ressource zu erhalten, fragt die Hostanwendung beim NIM nach, um die Information des Sprecherports zu bekommen oder einzusammeln. Der Portinformations-Nachfragevorgang ist in 30 gezeigt. Nach Empfang der Nachfrageanordnung beginn der NIM 9 mit dem Vorgang. In Schritt S900 greift der NIM 9 auf die Portinformationstabelle zu, um Information eines Eintrags des Ports zu bekommen, die für die Nachfrage relevant ist, und gibt die erhaltene Information an die obere Schicht weiter. Die Information eines in einem entfernten Knoten vorgesehenen Ports wird durch die Durchführung einer Transaktion an einen entsprechenden NIM im relevanten Knoten und von diesem kommend durchgeführt. Die Portinformation enthält den Porttyp und die Ressourceninformation, welche an die Hostanwendung zurückgegeben werden.
  • 2.6.2 Sprecherinformations-Berichtspaketabwicklung
  • Nach Empfang des Sprecherinformations-Berichtspakets führt der NIM 9 einen Abwicklungsvorgang für das Paket durch, der in 31 gezeigt ist. Nach Empfang des Sprecherinformations-Berichtspakets leitet der NIM in Schritt S910 den Vorgang ein, bei dem die Knoteninformationstabelle durch Schreiben der Knoten-ID und der eindeutigen Knoten-ID, die in dem Paket enthalten sind, in der Knoteninformationstabelle aktualisiert. Dann wird in Schritt S920 je nach der mit dem für das Paket relevanten Sprecherport verknüpften Ressource geprüft, ob der Typ des Sprechers isochron oder multicast ist. Wenn der Sprecherport ein isochroner Sprecher ist, wird das Sprecherinformations-Berichtspaket in Schritt S930 an den isochronen Manager 7 übertragen. Wenn jedoch der Sprecherport ein Multicast-Sprecher ist, wird das Berichtspaket in Schritt S940 an den Multicast-Manager 6 übertragen. Die Paketübertragung an die obere Schicht schließt den Paketabwicklungsvorgang ab.
  • 2.6.3 Kommunikation mit unterer Schicht
  • Der NIM 9 verwendet Dienstelemente, die vom Knotencontroller 4 zur Kommunikation mit diesem verwendet werden. Der Knotencontroller 4 sieht die unten angegebenen Dienstelemente vor.
    SB-Steueranforderung (SB_CONTROL.request)
    SB-Steuerbestätigung (SB_CONTROL.confirmation)
    SB-Ereignisanzeige (SB_EVENT.indication)
  • 2.6.4 Busrücksetzungsabwicklung
  • Wenn eine Busrücksetzung erfolgt, gibt der Knotencontroller 4 eine Busrücksetzungsanforderung (SB-Ereignisanzeige (BUS-RÜCKSETZ-START)) an den NIM 9. Nach Empfang der Anforderung leitet der NIM 9 den Busrücksetz-Abwicklungsvorgang ein. Der Betrieb der Busrücksetzabwicklung ist in 32 gezeigt. Nach Empfang der Busrücksetzanforderung gibt der NIM 9 eine Rücksetzanforderung (Isochron-Manager-Steueranforderung (RÜCKSETZEN)) an den isochronen Manager 7 in der mLAN-Transportschicht 10 aus. Dann gibt in Schritt S960 der NIM 9 auch eine Rücksetzanforderung (Multicast-Manager-Steueranforderung (RÜCKSETZEN)) an den Multicast-Manager 6 aus. Schließlich gibt in Schritt S970 der NIM 9 eine Rücksetzanforderung (PIM-Steueranforderung (RÜCKSETZEN)) an den PIM 8 aus.
  • Wenn die Busrücksetzung abgeschlossen ist, gibt der Knotencontroller 4 eine Bus-Rücksetzungs-Abschluss-Mitteilung (SB-Ereignisanzeige (BUSRÜCKSETZUNG FERTIG)) an den NIM 9 aus. Nach Empfang dieser Mitteilung leitet der NIM einen Bus-Rücksetzungs-Abschluss-Vorgang, der in 33 gezeigt ist, ein. Im Bus-Rücksetz-Abschluss-Vorgang gibt der NIM 9 eine Rücksetzungs-Abschluss-Nachricht an den isochronen Manager 7 in der mLAN-Transportschicht 10 in Schritt S980 aus. Außerdem gibt in Schritt S990 der NIM 9 eine Rücksetz-Abschluss-Nachricht an den Multicast-Manager 6 aus.
  • 2.7 mLAN-Transportschicht-Einrichtung
  • 2.7.1 Pfadinformationstabelle
  • Die Pfadinformationstabelle speichert die für die Hörerports (isochronen oder Multicast-Hörer) in Knoten vorgesehene Pfadinformation. Die Pfadinformationstabelle wird vom PIM 8 unterhalten. Auf den Inhalt der Pfadinformationstabelle kann auch vom NIM 9 zugegriffen werden, der die in der Tabelle gespeicherte Pfadinformation an entfernte Knoten weiterleiten kann. Das Format der Pfadinformationstabelle ist in 4 veranschaulicht. In der Tabelle ist ein Pfadinformationseintrag aus für einen Pfad relevanter Information zusammengesetzt. Der Pfadinformationseintrag enthält die unten angegebenen Informationen.
    • A. Port-ID des Hörers (16 Bit): Eine Portnummer im lokalen Knoten.
    • B. Port-ID des Sprechers (16 Bit): Eine Portnummer im entfernten Knoten.
    • C. Eindeutige Knoten-ID (64 Bit) des Knotens, bei dem der Sprecher residiert: Eine ID zum Identifizieren des entfernten Knotens. Sie hat eine Länge von 64 Bit, und der Wert wird durch einen Hersteller des Knotengeräts im Voraus definiert. Die eindeutige Knoten-ID wird niemals geändert, auch nicht bei einer Rücksetzung des Busses oder bei einer Rücksetzung beim Einschalten.
    • D. Verbindungsflag: Ein Flag, der den Verbindungsstatus des relevanten Pfads anzeigt. Es kann sein, dass einige Pfadinformationstabelleneinträge nach einer erneuten Initialisierung aufgrund einer Veränderung der Netzwerkarchitektur, wie zum Beispiel der Abwesenheit eines entsprechenden Knotens, nicht erneut konfiguriert werden. Der Flag zeigt an, ob der für den Eintrag relevante Pfad tatsächlich eingerichtet ist oder nicht.
  • 2.7.2 Knoteninformationstabelle
  • In der Knoteninformationstabelle ist Information über die Korrespondenz zwischen den Knoten-IDs und der eindeutigen Knoten-ID im lokalen Bus gespeichert. Die Knoteninformationstabelle wird vom NIM 9 unterhalten. Der NIM 9 aktualisiert die Knoteninformationstabelle nach einer Busrücksetzung, da im mLAN die Knoten-ID durch eine Rücksetzung des Busses geändert werden kann. Die Knoteninformationstabelle enthält die unten angeführten Informationen, die wie in 5 gezeigt formatiert sind.
    • A. Knoten-ID: Eine ID, die jedem Knoten nach einer Businitialisierung dynamisch zugewiesen wird.
    • B. Eindeutige Knoten-ID: Eine 64-Bit-ID, die für jedes Knotengerät im Voraus zugewiesen wird. Bei dem mLAN werden die oberen 24 Bits für eine Knoten-Verkäufer-ID zugewiesen, und die unteren 40 Bits werden für eine eindeutige Verkäufer-ID zugewiesen. Auf diese Weise wird die Eindeutigkeit der eindeutigen Knoten-ID sichergestellt.
  • 2.7.3 Multicast-Informationstabelle
  • Die Multicast-Informationstabelle wird vom Multicast-Manager 6 unterhalten. In der Tabelle ist Information über die Korrespondenz zwischen den Port-IDs der Multicast-Ports im Knoten und den mit den Ports verknüpften Multicast-Ressourcen gespeichert. Ein Eintrag für jeden Multicast-Port enthält die unten angegebenen Informationen, die wie in 6 gezeigt formatiert sind.
    • A. Port-ID: Eine Port-ID des Ports, mit dem eine Multicast-Ressource verknüpft ist.
    • B. Porttyp: Typinformation, die angibt, dass der Port ein Multicast-Sprecher bzw. -hörer ist.
    • C. Multicast-Ressource: Eine Multicast-Kanalnummer.
  • Nach einem Rücksetzen des Busses wird die Multicast-Ressource (Kanalnummer) gelöscht. Die Port-ID des Multicast-Ports wird vor und nach dem Rücksetzen des Busses beibehalten, und eine neue Multicast-Kanalnummer wird für jeden Port nach Abschluss der Busrücksetzung zugewiesen. Der Inhalt der Multicast-Informationstabelle wird jedoch beim Einschalt-Rücksetzen (Ein- bzw. Ausschalten der Stromversorgung) nicht beibehalten.
  • 2.7.4 Isochrone Informationstabelle
  • Die isochrone Informationstabelle wird vom isochronen Manager 7 unterhalten. In der Tabelle ist Information über die Korrespondenz zwischen der Port-ID des isochronen Ports im Knoten und der mit diesem Port verknüpften isochronen Ressource gespeichert. Ein Eintrag für jeden isochronen Port enthält die unten angegebenen Informationen, die wie in 7 gezeigt formatiert sind.
    • A. Port-ID: Eine Port-ID des Ports, mit dem die isochrone Ressource verknüpft ist
    • B. Port-Typ: Typinformation, die angibt, dass der Port ein isochroner Sprecher bzw. Hörer ist.
    • C. Isochrone Ressource: Mit dem Port verknüpfte Ressourcen. Ein isochroner Sprecher ist mit einer isochronen Kanalnummer und einer Bandbreite verknüpft, während ein isochroner Hörer allein mit einer isochronen Kanalnummer verknüpft ist.
  • Der Inhalt der isochronen Informationstabelle wird vor und nach der Busrücksetzung beibehalten.
  • 2.7.5 Portinformationseintrag
  • Der Portinformationseintrag wird vom NIM 9 unterhalten und beschreibt Eigenschaften eines jeden im Knoten geschaffenen Ports. Der Portinformationseintrag ist im Adressraum des Knotens angeordnet. Der Portinformationseintrag für jeden Port wird bei einem Adressversatz zugewiesen, der durch die entsprechende Port-ID eindeutig identifiziert werden kann. Ein entfernter Knoten kann nicht direkt auf die Adresse des Portinformationseintrags zugreifen. Jeder Portinformationseintrag enthält die unten angegebenen Informationen, die sich auf die Ressource beziehen, die dem Porttyp entspricht. Das Format der Einträge ist in 8 veranschaulicht.
    • A. Port-ID: Eine 16-Bit-ID, die für jeden Port zum Identifizieren des Ports zugewiesen wird. Die Eindeutigkeit der Port-ID ist innerhalb eines Knotens gewährleistet. Port-IDs von Spezialports (z.B. PIM 8/NIM 9 usw.) werden fest zugewiesen, und sind über die Knoten hinweg dieselben.
    • B. Porttyp: Eine Typinformation, die den Übertragungsmodus anzeigt. 4 Bits (d d d d) des Porttyps zeigen den Übertragungsmodus (Multicast/Isochron/Transaktion) an und weitere 4 Bits (k k k k) zeigen die Richtung der Datenübertragung (Senden/Empfangen/Bidirektional) an.
    • C. Ressource: Mit dem Port verknüpfte Ressourcen. Die Ressourcen können sich je nach dem Typ des Ports ändern.
  • 2.7.6 Sprecherinformations-Berichtspaket
  • Das Sprecherinformations-Berichtspaket wird an alle Knoten innerhalb des lokalen Busses rundgesendet, um mitzuteilen, dass ein neuer Port geschaffen wurde und mit bestimmten Ressourcen verknüpft ist. Das Paket wird an den NIM 9 aller Knoten rundgesendet. Für den Fall des Multicast-Sprechers, wird das Sprecherinformations-Berichtspaket zur Zeit der Schaffung des Ports rundgesendet. Die Transportschicht 10 in jedem Knoten weist eine Multicast-Kanalnummer für Multicastsprecher in der Reihenfolge der Ankunft der Sprecherinformations-Berichtspakete zu. In dem Fall eines isochronen Sprechers wird das Paket ausgegeben, wenn der isochrone Manager in jedem Knoten die isochronen Ressourcen erhält. Das Sprecherinformations-Berichtspaket enthält die unten angegebenen Informationen, und sein Format ist in 9 gezeigt.
    • A. Paket-ID: Eine ID zum Anzeigen, dass das Paket das Sprecherinformations-Berichtspaket ist.
    • B. Sprecherport-ID: Eine Port-ID des geschaffenen Sprecherports.
    • C. Sprecher-Knoten-ID: Eine Knoten-ID des Knotens, zu dem der entsprechende Sprecherport gehört.
    • D. Eindeutige Sprecher-ID: Die 64-Bit-ID, die für jeden Knoten wie oben beschrieben zugewiesen wird.
    • E. Sprecherressourceninformation: Information über mit dem geschaffenen Sprecherport verknüpfte Ressourcen.
  • 2.8. mLAN-Zyklusstruktur
  • Ein Beispiel der oben beschriebenen mLAN-Zyklusstruktur ist in 34 veranschaulicht. In 34 ist hauptsächlich der Zyklus #m gezeigt. Jeder Transferzyklus hat eine nominale Zyklusperiode von 125 μs. Die Startzeit (Zyklus-Synchronisation) wird von einem Zyklusmaster an alle Knoten gesendet. Der isochrone Manager 7 empfängt die Zyklussynchronisation und führt die isochrone Übertragung durch, wenn Daten zu übertragen sind. Bei der isochronen Übertragung kann nur ein Knoten die Daten unter der Konkurrenzbereinigungssteuerung der physikalischen Schicht 1 durchführen. So werden zum Beispiel die den betreffenden Bändern entsprechenden Daten nacheinander über isochrone Kanäle J, K, ..., N, wie gezeigt, übertragen. Die isochronen Daten werden pro Einheit des Übertragungszyklus übertragen, da die Bandbreite jedem Kanal entsprechend zugewiesen wird. Wenn die isochrone Übertragung beendet ist, wird die Multicast-Übertragung unter der Steuerung des Multicast-Managers 6 durchgeführt. Bei diesem Beispiel werden die Kanäle A, B und C als die Multicast-Kanäle verwendet. Bei der Multicast-Übertragung kann es sein, dass eine Paketübertragung nicht innerhalb eines Transferzyklus abgeschlossen werden kann, da eine bevorzugte Bandbreite innerhalb eines bestimmten begrenzten Bereichs erhalten werden kann. In diesem Fall wird die Multicast-Übertragung über die Länge eines Transferzyklus hinaus fortgesetzt. Der Beginn des nächsten Zyklus (#m + 1) wird wie gezeigt verzögert. Die Multicast-Übertragung kann nach Bedarf nur dann durchgeführt werden, wenn es zu sendende Daten gibt, so dass dieses Verfahren für Situationen geeignet ist, wo zu sendende Daten diskret oder in Abständen erzeugt werden.
  • 2.9 Die Verwendung der Multicast-Übertragung und der isochronen Übertragung
  • Von der Anwendungsseite scheint es, dass sowohl die Multicast- als auch die isochrone Übertragung auf die gleiche Weise funktionieren. Die Daten werden übertragen, als ob es keinen Unterschied zwischen dem Multicast- und dem isochronen Betrieb gäbe. Demnach können bestimmte MIDI-Daten durch eines der beiden Übertragungsverfahren übertragen werden, je nach der für die Daten erforderten Bandbreite und der Verfügbarkeit der isochronen Kanäle. In diesem Fall kann der Sprecherporttyp sich je nach dem ausgeführten Status der Anwendung ändern, während der Hörerporttyp unter der Steuerung der Pfadkonfiguration durch den PIM 8 von dem Typ des Sprecherports kopiert wird. Auf diese Weise kann der Benutzer der Anwendung, insbesondere der Zuhörerbenutzer die logischen Pfade konfigurieren, ohne dass er dabei berücksichtigen muss, welches Übertragungsverfahren eingesetzt wird. Bei der Sprecher-Anwendungsseite kann das Übertragungsverfahren vom Benutzer ausgewählt oder automatisch durch die Anwendung ausgewählt werden, je nach der Verfügbarkeit der isochronen Bänder.
  • 2.10 Plug-and-Play
  • Plug-and-Play ist ein Verfahren, durch das ein elektronisches Gerät einfach dadurch eingesetzt wird, dass das Gerät ohne komplizierte Konfiguration angeschlossen wird. Im mLAN werden alle Daten im Multicast- oder isochronen Übertragungsverfahren übertragen, so dass die Geräte (Knoten) nicht ohne die Pfadkonfiguration Daten austauschen können. Zur Erzielung eines Plug-and-Play-Betriebs im mLAN wird bei der vorliegenden Erfindung ein sogenannter "Well-known"-Kanal definiert, und es wird ein bestimmtes Protokoll über einen festen Kanal im Anfangszustand ausgetauscht, so dass die Daten zumindest auf der Basis des Protokolls übertragen werden können. Der Well-known-Kanal stellt den Datenaustausch in Situationen sicher, in denen kein spezifischer Pfad eingerichtet wurde. Außerdem kann es, auch wenn der Pfad eingerichtet wurde, sein, dass die Datenübertragung ohne den Well-known-Kanal unmöglich ist, nämlich, wenn ein neues Gerät (ein neuer Knoten) in das Netzwerk eingeführt wird.
  • Bei dem Empfangen von Daten wird ein Sprecherinformations-Berichtspaket nach dem Rücksetzen des Busses rundgesendet, das von der Einführung eines neuen Knotens verursacht wurde, so dass die Daten durch Erfassen der mit dem Sprecherport verknüpften Kanalnummer empfangen werden können, und durch die Schaffung eines Hörerports des dem Sprecherport entsprechenden Protokolltyps. In diesem Fall kann die Hostanwendung die von einer Vielzahl von Hörerports beschaffte Information verwenden. In dem Fall eines Sendens von Daten wird nichts unternommen, weil eine Übertragung ohne Auswirkungen auf den Status der Hörer unmöglich ist.
  • Aus Gründen der Effizienz kann die MIDI-Nachricht unverändert in einem Paket gesendet werden. Beliebige Daten, die keine Echtzeitabwicklung benötigen, können mit anderen Protokollen, wie zum Beispiel einem normalen File Transfer Protocol (FTP) übertragen werden. Die Daten, wie zum Beispiel digitale Audiodaten, können vorzugsweise als ein Strom durch das isochrone Übertragungsverfahren übertragen werden.
  • 36 zeigt eine weitere Ausführungsform des erfindungsgemäßen mLAN. Diese Ausführungsform hat im Grunde genommen dieselbe Konstruktion wie diejenige der in 1 gezeigten vorhergehenden Ausführungsform. Daher sind die entsprechenden Blöcke mit denselben Bezugszeichen als diejenigen der vorhergehenden Ausführungsform bezeichnet, um das Verständnis dieser Ausführungsform zu erleichtern. Das vorliegende mLAN wird durch ein Computersystem implementiert, in dem alle Knoten #1–#4 in der Form eines PCs implementiert sind und von einer jeweiligen CPU gesteuert werden. Das mLAN-System wird nach Anwendungsprogrammen betrieben, die mittels eines maschinenlesbaren Mediums 50, wie zum Beispiel einer optischen Speicherplatte und einer magnetischen Speicherplatte in die jeweiligen Knoten #1–#4 geladen werden.
  • Wie nämlich in 36 gezeigt, sind beim erfindungsgemäßen mLAN die Vielzahl der Knoten #1–#4 fähig zur Kommunikation miteinander, um Information auszutauschen und Daten zu übertragen, und der Bus ist zur Verbindung der Knoten #1–#4 und zur Konfiguration der logischen bzw. virtuellen Pfade zum logischen Verbinden eines Knotens mit einem anderen Knoten vorgesehen, um so eine sichere Übertragung der Daten zu garantieren. Jeder Knoten verfügt über mindestens einen Port, der zum Zugreifen auf den Bus zugewiesen ist und der in die vier Typen des isochronen Sprechers, des isochronen Hörers, des Multicast-Sprechers und des Multicast-Hörers klassifiziert ist. Zum Beispiel verknüpft der Knoten #1 eine isochrone Kanalnummer und ein Kommunikationsband mit dem isochronen Sprecher 1-T1, wenn dieser zum isochronen Übertragen der Daten, die mit der verknüpften isochronen Kanalnummer beschriftet sind, durch das verknüpfte Kommunikationsband dem Bus zugewiesen ist. Der Knoten #4 verknüpft eine isochrone Kanalnummer mit dem isochronen Hörer 4-R2, wenn dieser so zugewiesen wurde, dass der isochrone Hörer 4-R2 exklusiv Daten empfangen kann, die von einem anderen isochronen Sprecher 1-T1 gesendet wurden, der einem anderen Knoten #1 zugewiesen wurde, wenn die übertragenen Daten mit derselben isochronen Kanalnummer beschriftet sind, wie diejenige, die mit dem isochronen Hörer 4-R2 verknüpft ist. Der Knoten #3 verknüpft eine Multicast-Kanalnummer mit dem Multicast-Sprecher 3-T1, wenn dieser zur asynchronen Rundsendung von Daten zugewiesen ist, die mit der mit dem Bus verknüpften Multicast-Kanalnummer beschriftet sind. Der Knoten #2 verknüpft eine Multicast-Kanalnummer mit dem Multicast-Hörer 2-R1, wenn dieser so zugewiesen ist, dass der Multicast-Hörer 2-R1 exklusiv Daten empfangen kann, die von einem anderen Multicast-Sprecher 3-T1 gesendet wurden, der einem anderen Knoten #3 zugewiesen wurde, wenn die gesendeten Daten mit derselben Multicast-Kanalnummer beschriftet sind, wie diejenige, die mit dem Multicast-Hörer 2-R1 verknüpft ist.
  • In einer spezifischen Ausführungsform wird ein Senderknoten, der entweder über einen isochronen Sprecher oder den Multicast-Sprecher verfügt, wenn die logischen Pfade zurückgesetzt werden, zum Rundsenden von Sprecherinformation, die für Ressourcen repräsentativ ist, die eine isochrone Kanalnummer enthalten, eines Kommunikationsbands und einer Multicast-Kanalnummer betrieben, die nach dem Rücksetzen der logischen Pfade neu mit dem isochronen Sprecher bzw. dem Multicast-Sprecher verknüpft werden kann, während ein Empfängerknoten, der entweder über den isochronen Hörer oder den Multicast-Hörer verfügt, wenn die rundgesendete Sprecherinformation empfangen wird, zum neuen Verknüpfen von Ressourcen betrieben wird, die eine isochrone Kanalnummer für den isochronen Hörer und den Multicast-Hörer enthält, um hierdurch die logischen Pfade wiederherzustellen. In diesem Fall speichert der Empfängerknoten die für die logischen Pfade repräsentative Pfadinformation und verknüpft die Ressourcen gemäß der rundgesendeten Sprecherinformation und der gespeicherten Pfadinformation neu, um eine Korrespondenz zwischen den Ressourcen des Empfängerknotens und den Ressourcen des Senderknotens hinsichtlich der isochronen Kanalnummer und der Multicast-Kanalnummer sicherzustellen. Jeder Knoten hat eine spezifische Kommunikationsarchitektur, die aus Protokollschichten besteht, die eine Transportschicht enthalten, die einen isochronen Manager zum Akquirieren isochroner Ressourcen und zum Verknüpfen der akquirierten isochronen Ressourcen entweder mit dem zugewiesenen isochronen Sprecher oder dem isochronen Hörer enthält, einen Multicast-Manager zum Akquirieren von Multicast-Ressourcen und zum Verknüpfen der akquirierten Multicast-Ressourcen entweder mit dem zugewiesenen Multicast-Sprecher oder dem Multicast-Hörer, sowie einen Pfadinformationsmanager, der mit dem isochronen Manager und dem Multicast-Manager zusammenarbeitet, um der oberen Protokollschicht einen Dienst zum Setzen der logischen Pfade und zum Verwalten der gesetzten logischen Pfade zur Verfügung zu stellen. Normalerweise wird dem Senderknoten sowohl der isochrone Sprecher als auch der Multicast-Sprecher zugewiesen, so dass der Senderknoten wiederholt einen Transferzyklus durchführt, der eine isochrone Übertragung von Daten durch den isochronen Sprecher und eine asynchrone Rundsendung von Daten durch den Multicast-Sprecher enthält, und so dass der Senderknoten die Daten in jedem Transferzyklus entweder an den isochronen Sprecher oder den Multicast-Sprecher gemäß der Eigenschaft der Daten und der Verfügbarkeit des isochronen Sprechers und des Multicast-Sprechers sendet. In diesem Fall verarbeitet der Senderknoten eine Mischung kontinuierlicher Musikdaten und diskreter Musikdaten und verteilt die kontinuierlichen Musikdaten an den isochronen Sprecher, während er die diskreten Musikdaten an den Multicast-Sprecher verteilt.
  • Wie oben beschrieben, können gemäß der vorliegenden Erfindung virtuelle und logische Pfade in dem Netzwerk unabhängig von der physikalischen Verbindungstopologie konfiguriert werden. Wenn zwei Geräte an das Netzwerk angeschlossen sind, kann zwischen den beiden Geräten unabhängig von ihrem physischen Standort ein Pfad eingerichtet werden und können über diesen Pfad Daten ausgetauscht werden. Die Daten können daher über die virtuellen Pfade unabhängig von der Netzwerktopologie ausgetauscht werden, so dass die Anschlussreihenfolge der Vielzahl von Geräten nicht zu Fehlern führt bzw. irrelevant ist, und die Daten zuverlässig übertragen werden können. Die Datenverbindung kann leicht geändert werden, ohne dass dadurch die physische Verbindung der Geräte geändert wird, da der Pfad logisch zwischen den Geräten konfiguriert ist. Die virtuelle Pfadinformation wird in jedem an das Netzwerk angeschlossenen Gerät gespeichert. Daher kann die ganze Pfadinformation des gesamten Netzwerksystems in einem Speichermedium gesichert werden, und dieselbe Netzwerkkonfiguration kann leicht und sofort durch ein Laden der gesicherten Pfadinformation vom Medium wieder hergestellt werden. Die vorliegende Erfindung ermöglicht die Verwendung nicht nur des isochronen Übertragungsverfahrens, bei dem die Bandbreite der Übertragung sichergestellt wird, sondern auch das Multicast-Übertragungsverfahren, bei dem Daten bei Bedarf an eine spezifische Vielzahl von Knoten übertragen werden können. Daher können die Daten wirkungsvoll übertragen werden, und zwar unabhängig davon, wie die diskreten Daten erzeugt werden. Außerdem können Musikdaten, wie zum Beispiel MIDI-Daten und Audiodaten, die eine Echtzeitübertragung erfordern, wirkungsvoll übertragen werden.

Claims (16)

  1. Netzwerksystem aufweisend: eine Vielzahl von Knoten, welche zum Austausch von Informationen und zur Datenübertragung miteinander kommunizieren können; und einen Bus für die Verbindung zu den Knoten und für die Konfiguration der logischen Pfade, um einen Konten mit einem anderen Knoten logisch zu verbinden, um die Datenübertragung sicherzustellen, wobei jeder Knoten mindestens einen Anschluss besitzt, der dazu ausgelegt ist, für den Zugriff auf den Bus zugewiesen zu werden, und Mittel zur Klassifizierung der Anschlüsse in vier Arten besitzt: einen isochronen Sender, einen isochronen Empfänger, einen Multicast-Sender und einen Multicast-Empfänger, jeder Knoten Mittel aufweist, eine isochrone Kanalnummer und ein Datenübertragungsband mit dem isochronen Sender zu verknüpfen, wenn dieser dafür zugewiesen ist, die Daten, die durch die daran gebundene Kanalnummer gekennzeichnet sind, isochron durch das angebundene Datenübertragungsband an den Bus zu übertragen, jeder Knoten Mittel aufweist, eine isochrone Kanalnummer mit dem isochronen Empfänger zu verknüpfen, wenn dieser dafür zugewiesen ist, dass der isochrone Empfänger ausschließlich Daten empfangen kann, die von einem anderen isochronen Sender gesendet wurden, welcher einem anderen Knoten zugewiesen ist, falls die gesendeten Daten durch die selbe isochrone Kanalnummer gekennzeichnet sind, wie die, die mit dem isochronen Empfänger verknüpft ist, jeder Knoten Mittel aufweist, eine Multicast-Kanalnummer mit dem Multicast-Sender zu verknüpfen, wenn dieser dafür zugewiesen ist, asynchron Daten, die durch die damit verknüpfte Multicast-Kanalnummer gekennzeichnet sind, an den Bus zu senden, jeder Knoten Mittel aufweist, eine Multicast-Kanalnummer mit dem Multicast-Empfänger zu verknüpfen, wenn dieser dafür zugewiesen ist ist, dass der Multicast-Empfänger ausschließlich Daten empfangen kann, die von einem anderen Multicast-Sender gesendet wurden, welcher einem anderen Knoten zugewiesen ist, falls die gesendeten Daten durch die selbe Multicast-Kanalnummer gekennzeichnet sind, wie die, die mit dem Multicast-Empfänger verknüpft ist.
  2. Netzwerksystem gemäß Anspruch 1, wobei ein Datenübertragungsknoten, der entweder den isochronen Sender oder den Multicast-Sender hat, dazu ausgelegt ist zu arbeiten, wenn die logischen Pfade zurückgesetzt sind, um Senderinformation zu übertragen, welche Resourcen repräsentiert, einschließlich einer isochronen Kanalnummer, eines Datenübertragungsbands und einer Multicast-Kanalnummer, die auf Zurücksetzen der logischen Pfade hin neu mit dem isochronen Sender bzw. dem Multicast-Sender verknüpft werden können, und ein Empfängerknoten, der entweder den isochronen Empfänger oder den Multicast-Empfänger hat, dazu ausgelegt ist zu arbeiten, wenn die übertragene Senderinformation empfangen wird, um die Resourcen einschließlich einer isochronen Kanalnummer und einer Multicast-Kanalnummer mit dem isochronen Empfänger und dem Multicast-Empfänger neu zu verknüpfen und dadurch die logischen Pfade wieder herzustellen.
  3. Netzwerksystem gemäß Anspruch 2, wobei der Empfängerknoten Mittel (8) zum Speichern von Pfadinformationen, welche die logischen Pfade repräsentieren, aufweist, und Mittel aufweist, um die Resourcen entsprechend den übertragenen Senderinformation und der gespeicherten Pfadinformation neu zu verknüpfen, um die Übereinstimmung zwischen den Resourcen des Empfängerknotens und den Resourcen des Senderknotens hinsichtlich der isochronen Kanalnummer und der Multicast-Kanalnummer sicher zu stellen.
  4. Netzwerksystem gemäß Anspruch 1, wobei jeder Knoten eine Kommunikationsarchitektur hat, die aus Protokollebenen einschließlich einer Transportebene (10), beinhaltend einen isochronen Manager (7) zum Erfassen von isochronen Resourcen und zum Verknüpfen der erfassten isochronen Resourcen entweder mit dem zugewiesenen isochronen Sender oder mit dem isochronen Empfänger, einen Multicast-Manager (6) zum Erfassen von Multicast-Resourcen entweder an den zugewiesenen Multicast-Sender oder den Multicast-Empfänger, einen Pfad-Informations-Manager (8), der mit dem isochronen Manager (7) und dem Multicast-Manager (6) zusammenwirkt, um eine obere Protokollebene mit einem Service bereitzustellen, um die logischen Pfade zu setzen und um die gesetzten logischen Pfade zu verwalten.
  5. Netzwerksystem gemäß Anspruch 1, umfassend einen Übertragungsknoten, der mit dem isochronen Sender und dem Multicast-Sender zugewiesen ist; wobei der Übertragungsknoten Mittel aufweist zur wiederholten Ausführung von Übertragungszyklen beinhaltend isochrone Übertragung von Daten durch den isochronen Sender und asynchrones Senden von Daten durch den Multicast-Sender; und wobei der Übertragungsknoten Mittel zum Verteilen der Daten in jedem Übertragungszyklus an den isochronen Sender oder an den Multicast-Sender aufweist, entsprechend der Eigenschaft der Daten und der Verfügbarkeit des isochronen Senders und des Multicast-Senders.
  6. Netzwerksystem gemäß Anspruch 5, wobei der Übertragungsknoten dazu ausgelegt ist, eine Mischung kontinuierlicher Musikdaten und einzelner Musikdaten zu bearbeiten und die kontinuierlichen Musikdaten an den isochronen Sender zu verteilen, während er die einzelnen Musikdaten an den Multicast-Sender verteilt.
  7. Datenübertragungsverfahren in einem Netzwerksystem aufweisend eine Vielzahl von Knoten, welche zum Austausch von Informationen und zur Datenübertragung miteinander kommunizieren können; und einen Bus für die Verbindung zu den Knoten und für die Konfiguration der logischen Pfade, um einen Knoten mit einem anderen Knoten logisch zu verbinden, damit die Datenübertragung sichergestellt ist, wobei das Verfahren folgende Schritte aufweist: jedem Knoten mindestens einen Anschluß zuweisen, der für den Zugriff auf den Bus verwendet wird und der in vier Typen eingeteilt ist: einen isochronen Sender, einen isochronen Empfänger, einen Multicast-Sender und ein Multicast-Empfänger, Verknüpfen einer isochrone Kanalnummer und eines Datenübertragungsbands mit dem isochronen Sender (S30), wenn dieser dem Knoten zugewiesen ist, um die Daten, die durch die damit verknüpfte Kanalnummer gekennzeichnet sind, isochron durch das verknüpfte Datenübertragungsband an den Bus zu übertragen, Verknüpfen einer isochrone Kanalnummer mit dem isochronen Empfänger, wenn dieser dem Knoten zugewiesen ist, so dass der isochrone Empfänger ausschließlich Daten empfangen kann, die von einem anderen isochronen Sender übertragen werden, welcher einem anderen Knoten zugewiesen ist, falls die gesendeten Daten durch die selbe isochrone Kanalnummer gekennzeichnet sind, wie die, die mit dem isochronen Empfänger verknüpft ist, Verknüpfen einer Multicast-Kanalnummer mit dem Multicast-Sender (S620), wenn dieser dem Knoten zugewiesen ist, um asynchron Daten, die durch die damit verknüpfte Multicast-Kanalnummer gekennzeichnet sind, an den Bus zu senden, und andernfalls Verknüpfen einer Multicast-Kanalnummer mit dem Multicast-Empfänger, wenn dieser so dem Knoten zugewiesen ist, dass der Multicast-Empfänger ausschließlich Daten empfangen kann, die von einem anderen Multicast-Sender gesendet werden, welcher einem anderen Knoten zugewiesen ist, falls die gesendeten Daten durch die selbe Multicast-Kanalnummer gekennzeichnet sind, wie die, die mit dem Multicast-Empfänger verknüpft ist.
  8. Datenübertragungsverfahren gemäß Anspruch 7, weiterhin aufweisend Schritte zum Betreiben eines Übertragungsknotens, der entweder den isochronen Sender oder den Multicast-Sender hat, wenn die logischen Pfade zurückgesetzt sind, um Senderinformation zu übertragen, welche repräsentativ für die Resourcen einschließlich einer isochronen Kanalnummer, eines Datenübertragungsbands und einer Multicast-Kanalnummer ist, die durch Zurücksetzen der logischen Pfade neu mit dem isochronen Sender bzw. dem Multicast-Sender verknüpft werden kann, und zum Betreiben eines Empfängerknotens, der entweder den isochrone Empfänger oder den Multicast-Empfänger hat, wenn die übertragene Senderinformation empfangen wird, um die Resourcen beinhaltend eine isochrone Kanalnummer und eine Multicast-Kanalnummer mit dem isochronen Empfänger und dem Multicast-Empfänger neu zu verknüpfen und dadurch die logischen Pfade wiederherzustellen.
  9. Datenübertragungsverfahren gemäß Anspruch 8, weiterhin aufweisend Schritte zum Betreiben eines Empfängerknotens zum Speichern von Pfadinformationen, welche die logischen Pfade repräsentieren, und um die Resourcen entsprechend den übertragenen Senderinformation und der gespeicherten Pfadinformation neu zu verknüpfen, um die Übereinstimmung zwischen den Resourcen des Empfängerknotens und den Resourcen des Senderknotens bezüglich der isochronen Kanalnummer und der Multicast-Kanalnummer sicher zu stellen.
  10. Datenübertragungsverfahren gemäß Anspruch 7, weiterhin aufweisend Schritte zum Betreiben eines Übertragungsknotens, dem der isochrone Sender und der Multicast-Sender zugewiesen ist, so dass der Übertragungsknoten zur wiederholt Übertragungszyklen ausführt beinhaltend isochrone Übertragung von Daten durch den isochronen Sender und asynchrones Senden von Daten durch den Multicast-Sender, und so dass der Übertragungsknoten die Daten in jedem Übertragungszyklus an den isochronen Sender oder an den Multicast-Sender verteilt entsprechend der Eigenschaft der Daten und der Verfügbarkeit des isochronen Senders und des Multicast-Senders.
  11. Datenübertragungsverfahren gemäß Anspruch 10, weiterhin aufweisend einen Schritt zum Betreiben des Übertragungsknotens zum Bearbeiten einer Mischung kontinuierlicher Musikdaten und einzelner Musikdaten, und zum Verteilen der kontinuierlichen Musikdaten an den isochronen Sender, während er die einzelnen Musikdaten an den Multicast-Sender verteilt.
  12. Maschinenlesbares Medium (50) enthaltend Befehle um ein Netzwerksystem, aufweisend eine Vielzahl von Knoten, welche zum Austausch von Informationen und zur Datenübertragung miteinander kommunizieren können, und einen Bus für die Verbindung zu den Knoten und für die Konfiguration der logischen Pfade, um einen Konten mit einem anderer Knoten logisch zu verbinden, damit die Datenübertragung sichergestellt ist, dazu zu befähigen, ein Verfahren durchzuführen, das folgende Schritte aufweist: jedem Knoten mindestens einen Anschluß zuweisen, der für den Zugriff auf den Bus verwendet wird und der in vier Typen eingeteilt ist: einen isochronen Sender, einen isochronen Empfänger, einen Multicast-Sender und ein Multicast-Empfänger, Verknüpfen einer isochrone Kanalnummer und eines Datenübertragungsbands mit dem isochronen Sender (S30), wenn dieser dem Knoten zugewiesen ist, um die Daten, die durch die damit verknüpfte Kanalnummer gekennzeichnet sind, isochron durch das verknüpfte Datenübertragungsband an den Bus zu übertragen, Verknüpfen einer isochrone Kanalnummer mit dem isochronen Empfänger, wenn dieser dem Knoten zugewiesen ist, so dass der isochrone Empfänger ausschließlich Daten empfangen kann, die von einem anderen isochronen Sender übertragen werden, welcher einem anderen Knoten zugewiesen ist, falls die gesendeten Daten durch die selbe isochrone Kanalnummer gekennzeichnet sind, wie die, die mit dem isochronen Empfänger verknüpft ist, Verknüpfen einer Multicast-Kanalnummer mit dem Multicast-Sender (S620), wenn dieser dem Knoten zugewiesen ist, um asynchron Daten, die durch die damit verknüpfte Multicast-Kanalnummer gekennzeichnet sind, an den Bus zu senden, und andernfalls Verknüpfen einer Multicast-Kanalnummer mit dem Multicast-Empfänger, wenn dieser so dem Knoten zugewiesen ist, dass der Multicast-Empfänger ausschließlich Daten empfangen kann, die von einem anderen Multicast-Sender gesendet werden, welcher einem anderen Knoten zugewiesen ist, falls die gesendeten Daten durch die selbe Multicast-Kanalnummer gekennzeichnet sind, wie die, die mit dem Multicast-Empfänger verknüpft ist.
  13. Maschinenlesbares Medium (50) gemäß Anspruch 12, wobei das Verfahren weiterhin Schritte aufweist zum Betreiben eines Übertragungsknotens, der entweder den isochronen Sender oder den Multicast-Sender hat, wenn die logischen Pfade zurückgesetzt sind, um Senderinformation zu übertragen, welche repräsentativ für die Resourcen einschließlich einer isochronen Kanalnummer, eines Datenübertragungsbands und einer Multicast-Kanalnummer ist, die durch Zurücksetzen der logischen Pfade neu mit dem isochronen Sender bzw. dem Multicast-Sender verknüpft werden kann, und zum Betreiben eines Empfängerknotens, der entweder den isochrone Empfänger oder den Multicast-Empfänger hat, wenn die übertragene Senderinformation empfangen wird, um die Resourcen beinhaltend eine isochrone Kanalnummer und eine Multicast-Kanalnummer mit dem isochronen Empfänger und dem Multicast-Empfänger neu zu verknüpfen und dadurch die logischen Pfade wiederherzustellen.
  14. Maschinenlesbares Medium (50) gemäß Anspruch 13, wobei das Verfahren weiterhin Schritte aufweist zum Betreiben eines Empfängerknotens zum Speichern von Pfadinformationen, welche die logischen Pfade repräsentieren, und um die Resourcen entsprechend den übertragenen Senderinformation und der gespeicherten Pfadinformation neu zu verknüpfen, um die Übereinstimmung zwischen den Resourcen des Empfängerknotens und den Resourcen des Senderknotens bezüglich der isochronen Kanalnummer und der Multicast-Kanalnummer sicher zu stellen.
  15. Maschinenlesbares Medium (50) nach Anspruch 12, wobei das Verfahren weiterhin Schritte aufweist zum Betreiben eines Übertragungsknotens, dem der isochrone Sender und der Multicast-Sender zugewiesen ist, so dass der Übertragungsknoten zur wiederholt Übertragungszyklen ausführt beinhaltend isochrone Übertragung von Daten durch den isochronen Sender und asynchrones Senden von Daten durch den Multicast-Sender, und so dass der Übertragungsknoten die Daten in jedem Übertragungszyklus an den isochronen Sender oder an den Multicast-Sender verteilt entsprechend der Eigenschaft der Daten und der Verfügbarkeit des isochronen Senders und des Multicast-Senders.
  16. Maschinenlesbares Medium (50) nach Anspruch 15, wobei das Verfahren weiterhin einen Schritt aufweist zum Betreiben des Übertragungsknotens zum Bearbeiten einer Mischung kontinuierlicher Musikdaten und einzelner Musikdaten, und zum Verteilen der kontinuierlichen Musikdaten an den isochronen Sender, während er die einzelnen Musikdaten an den Multicast-Sender verteilt.
DE69634505T 1995-09-26 1996-09-25 Lokales Netz zum Übertragen von Daten unter Verwendung von isochronen und asynchronen Kanälen Expired - Lifetime DE69634505T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP27073895A JP3271493B2 (ja) 1995-09-26 1995-09-26 ネットワークおよびデータ伝送方法
JP27073895 1995-09-26

Publications (2)

Publication Number Publication Date
DE69634505D1 DE69634505D1 (de) 2005-04-28
DE69634505T2 true DE69634505T2 (de) 2006-02-16

Family

ID=17490289

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69634505T Expired - Lifetime DE69634505T2 (de) 1995-09-26 1996-09-25 Lokales Netz zum Übertragen von Daten unter Verwendung von isochronen und asynchronen Kanälen

Country Status (6)

Country Link
US (1) US5825752A (de)
EP (1) EP0766428B1 (de)
JP (1) JP3271493B2 (de)
KR (1) KR100305709B1 (de)
DE (1) DE69634505T2 (de)
SG (1) SG86309A1 (de)

Families Citing this family (73)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6067566A (en) * 1996-09-20 2000-05-23 Laboratory Technologies Corporation Methods and apparatus for distributing live performances on MIDI devices via a non-real-time network protocol
US6266694B1 (en) * 1997-06-19 2001-07-24 Nortel Networks Limited Architecture for network manager
US6404770B1 (en) 1997-12-02 2002-06-11 Yamaha Corporation Data communication interface with adjustable-size buffer
US6418493B1 (en) * 1997-12-29 2002-07-09 Intel Corporation Method and apparatus for robust addressing on a dynamically configurable bus
US6690648B2 (en) * 1998-02-24 2004-02-10 Canon Kabushiki Kaisha Data communication apparatus, method, and system utilizing reception capability information of a destination node
US7002964B1 (en) * 1998-02-24 2006-02-21 Canon Kabushiki Kaisha Communication system, method for a communication system and controller for a communication system
US7590133B2 (en) 1998-02-24 2009-09-15 Canon Kabushiki Kaisha Data communication system, data communication method, and data communication apparatus
US6804250B2 (en) 1998-02-24 2004-10-12 Canon Kabushiki Kaisha Data communication system and node, and method of using the system and the node
JP3171241B2 (ja) 1998-03-06 2001-05-28 日本電気株式会社 通信方法
US6366658B1 (en) 1998-05-07 2002-04-02 Mci Communications Corporation Telecommunications architecture for call center services using advanced interactive voice responsive service node
US6496567B1 (en) 1998-05-07 2002-12-17 Mci Communications Corporation Interactive voice response service node with advanced resource management
US6427002B2 (en) 1998-05-07 2002-07-30 Worldcom, Inc. Advanced interactive voice response service node
US6389126B1 (en) 1998-05-07 2002-05-14 Mci Communications Corporation Service provisioning system for interactive voice response services
US6493353B2 (en) 1998-05-07 2002-12-10 Mci Communications Corporation Communications signaling gateway and system for an advanced service node
US6647111B1 (en) * 1998-05-07 2003-11-11 Mci Communications Corporation System for executing advanced interactive voice response services using service-independent building blocks
US6418205B2 (en) * 1998-05-07 2002-07-09 Mci Communications Corporation Call and circuit state machine for a transaction control layer of a communications signaling gateway
JP3606423B2 (ja) * 1998-05-21 2005-01-05 株式会社ケンウッド Ｉｅｅｅ１３９４シリアルバス装備ａｖシステム
KR100316650B1 (ko) 1998-08-29 2002-01-12 윤종용 상위 계층 데이터 전송을 위한 상위 프로토콜과 ieee 1394버스 정합 방법
KR100354740B1 (ko) 1998-10-15 2002-12-18 삼성전자 주식회사 Ieee1394직렬버스를위한채널확장방법
JP3325839B2 (ja) * 1998-10-15 2002-09-17 パイオニア株式会社 情報送信装置及び方法、情報受信装置及び方法並びに情報送受信装置及び方法
KR100313769B1 (ko) * 1998-11-11 2001-12-31 구자홍 등시성 데이터 제어방법
KR100294671B1 (ko) * 1998-11-16 2001-08-07 구자홍 시리얼버스 매니지먼트장치 및 방법
US6539450B1 (en) * 1998-11-29 2003-03-25 Sony Corporation Method and system for adjusting isochronous bandwidths on a bus
JP4366741B2 (ja) * 1998-12-22 2009-11-18 ソニー株式会社 ディジタル放送の受信装置及びディジタル信号処理機器の認識方法
KR100323770B1 (ko) * 1999-03-08 2002-02-19 서평원 멀티캐스트 서비스를 위한 채널 구조 및 이를 이용한 서비스 운용 방법
JP3436174B2 (ja) * 1999-03-09 2003-08-11 日本電気株式会社 通信方法
US6810452B1 (en) 1999-03-19 2004-10-26 Sony Corporation Method and system for quarantine during bus topology configuration
US6631415B1 (en) * 1999-03-19 2003-10-07 Sony Corporation Method and system for providing a communication connection using stream identifiers
US6374316B1 (en) 1999-03-19 2002-04-16 Sony Corporation Method and system for circumscribing a topology to form ring structures
JP3417872B2 (ja) 1999-04-07 2003-06-16 日本電気株式会社 交換方法
US6502158B1 (en) 1999-04-23 2002-12-31 Sony Corporation Method and system for address spaces
US6751230B1 (en) 1999-05-24 2004-06-15 3Com Corporation Upstream channel multicast media access control (MAC) address method for data-over-cable systems
JP3784994B2 (ja) * 1999-05-27 2006-06-14 株式会社東芝 データ処理装置
JP2000341302A (ja) * 1999-05-27 2000-12-08 Sony Corp 電子機器
JP4505692B2 (ja) * 1999-06-18 2010-07-21 ソニー株式会社 データ通信装置および方法、並びに記録媒体
KR100331603B1 (ko) * 1999-08-13 2002-04-06 안병엽 분산 가상 환경에서의 확장성을 위한 영역간 상호 작용 관리방법
US7068674B1 (en) 1999-08-23 2006-06-27 Lg Electronics Inc. Method of controlling connection between nodes in digital interface
US6910090B1 (en) 1999-09-21 2005-06-21 Sony Corporation Maintaining communications in a bus bridge interconnect
JP3606133B2 (ja) * 1999-10-15 2005-01-05 セイコーエプソン株式会社 データ転送制御装置及び電子機器
EP1499069B1 (de) * 1999-10-29 2007-08-08 Sony Corporation Verfahren und System zur Nutzung einer Vielzahl von Übertragungsleitungen und Einstellung des Verbindungsbetriebsverfahrens
US6717919B1 (en) 1999-11-23 2004-04-06 3Com Corporation Imprinting method for automated registration and configuration of network devices
AU3643801A (en) * 1999-11-29 2001-06-04 Sony Electronics Inc. Method and system for adjusting isochronous bandwidths on a bus
US6728821B1 (en) * 1999-11-29 2004-04-27 Sony Corporation Method and system for adjusting isochronous bandwidths on a bus
EP1113626B1 (de) * 1999-12-30 2009-04-22 Sony Deutschland GmbH Schnittstellenverbindungsschicht- Einrichtung zum Aufbau eines verteilten Netzwerks
EP1266484B1 (de) 2000-01-27 2007-12-12 Thomson Licensing Verfahren zur isochronen betriebsmittelverwaltung in einem netz auf der basis von hiperlan2-technologie
US8090856B1 (en) 2000-01-31 2012-01-03 Telecommunication Systems, Inc. Intelligent messaging network server interconnection
US7003571B1 (en) 2000-01-31 2006-02-21 Telecommunication Systems Corporation Of Maryland System and method for re-directing requests from browsers for communication over non-IP based networks
US6647446B1 (en) 2000-03-18 2003-11-11 Sony Corporation Method and system for using a new bus identifier resulting from a bus topology change
US6757773B1 (en) 2000-06-30 2004-06-29 Sony Corporation System and method for determining support capability of a device coupled to a bus system
JP3896784B2 (ja) * 2000-10-10 2007-03-22 日本電気株式会社 パケット通信方法および装置
US7483983B1 (en) * 2000-11-13 2009-01-27 Telecommunication Systems, Inc. Method and system for deploying content to wireless devices
JP4586268B2 (ja) * 2000-12-25 2010-11-24 ヤマハ株式会社 ネットワークにおけるデータ送受信管理方法及び同データ送受信管理装置
JP3638255B2 (ja) * 2001-03-26 2005-04-13 富士通テン株式会社 通信シミュレーション装置および方法
JP3890927B2 (ja) * 2001-07-23 2007-03-07 ヤマハ株式会社 他ノードを管理する通信装置及び他ノードに管理される通信装置
US20030041333A1 (en) * 2001-08-27 2003-02-27 Allen Paul G. System and method for automatically answering and recording video calls
JP3882618B2 (ja) * 2002-01-18 2007-02-21 ヤマハ株式会社 通信装置およびネットワークシステム
US7110928B1 (en) * 2002-03-01 2006-09-19 Adaptec, Inc. Apparatuses and methods for modeling shared bus systems
EP1575229A3 (de) * 2002-07-30 2007-12-12 Yamaha Corporation Datenübertragungsvorrichtung mit dynamischer Zuweisung von Übertragungssequenzen
CN1181648C (zh) 2002-09-06 2004-12-22 联想(北京)有限公司 一种网络上设备间自动查找的方法
DE10250102A1 (de) 2002-10-28 2004-07-15 Deutsche Thomson-Brandt Gmbh Verfahren zur Verwaltung von eingerichteten logischen Verbindungen in einem Netzwerk verteilter Stationen sowie Netzwerkstation
US7178051B2 (en) * 2003-02-27 2007-02-13 Sun Microsystems, Inc. Method for synchronous support of fault-tolerant and adaptive communication
US8949304B2 (en) * 2003-08-20 2015-02-03 Apple Inc. Method and apparatus for accelerating the expiration of resource records in a local cache
US7742444B2 (en) 2005-03-15 2010-06-22 Qualcomm Incorporated Multiple other sector information combining for power control in a wireless communication system
US8750908B2 (en) 2005-06-16 2014-06-10 Qualcomm Incorporated Quick paging channel with reduced probability of missed page
US9055552B2 (en) 2005-06-16 2015-06-09 Qualcomm Incorporated Quick paging channel with reduced probability of missed page
US7847174B2 (en) 2005-10-19 2010-12-07 Yamaha Corporation Tone generation system controlling the music system
US20090207790A1 (en) 2005-10-27 2009-08-20 Qualcomm Incorporated Method and apparatus for settingtuneawaystatus in an open state in wireless communication system
WO2007050829A1 (en) 2005-10-27 2007-05-03 Qualcomm Incorporated A method of maintaining activecarriers and reqcarriers at the access network
US8850553B2 (en) * 2008-09-12 2014-09-30 Microsoft Corporation Service binding
US8332557B2 (en) * 2008-12-12 2012-12-11 Qualcomm, Incorporated System, apparatus, and method for broadcasting USB data streams
US8849112B2 (en) * 2011-12-15 2014-09-30 Level 3 Communications, Llc Apparatus, system, and method for asymmetrical and dynamic routing
US9641438B2 (en) 2011-12-15 2017-05-02 Level 3 Communications, Llc Apparatus, system, and method for asymmetrical and dynamic routing
US10140121B2 (en) * 2015-07-21 2018-11-27 Oracle International Corporation Sending a command with client information to allow any remote server to communicate directly with client

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4320683A (en) * 1980-01-14 1982-03-23 Allen Organ Company Asynchronous interface for keying electronic musical instruments using multiplexed note selection
US4412470A (en) * 1981-06-08 1983-11-01 Baldwin Piano & Organ Company System for communicating data among microcomputers in an electronic musical instrument
NO162098C (no) * 1982-11-30 1989-11-01 Alcatel Nv Fremgangsmaate for overfoering av tale og data.
US4568930A (en) * 1983-01-21 1986-02-04 E-Systems, Inc. Multinodal data communication network
DE3318667C1 (de) * 1983-05-21 1984-10-11 WERSI-electronic GmbH & Co KG, 5401 Halsenbach Elektronisches Tastenmusikinstrument und Verfahren zu dessen Betrieb
US5119710A (en) * 1986-03-09 1992-06-09 Nippon Gakki Seizo Kabushiki Kaisha Musical tone generator
US5170252A (en) * 1990-04-09 1992-12-08 Interactive Media Technologies, Inc. System and method for interconnecting and mixing multiple audio and video data streams associated with multiple media devices
FR2664771B1 (fr) * 1990-07-10 1992-09-18 Alcatel Business Systems Procede et agencement de transmission par bus.
US5237571A (en) * 1991-09-26 1993-08-17 Ipc Information Systems, Inc. Broadcast system for distributed switching network
JPH05101020A (ja) * 1991-10-04 1993-04-23 Matsushita Electric Ind Co Ltd ネツトワーク自動設定装置
JP2626387B2 (ja) * 1991-12-24 1997-07-02 ヤマハ株式会社 電子楽器
JP3086315B2 (ja) * 1992-01-14 2000-09-11 ヤマハ株式会社 音源装置
US5331111A (en) * 1992-10-27 1994-07-19 Korg, Inc. Sound model generator and synthesizer with graphical programming engine
US5406559A (en) * 1992-11-02 1995-04-11 National Semiconductor Corporation Isochronous link protocol
US5550802A (en) * 1992-11-02 1996-08-27 National Semiconductor Corporation Data communication network with management port for isochronous switch
US5544324A (en) * 1992-11-02 1996-08-06 National Semiconductor Corporation Network for transmitting isochronous-source data using a frame structure with variable number of time slots to compensate for timing variance between reference clock and data rate
US5689553A (en) * 1993-04-22 1997-11-18 At&T Corp. Multimedia telecommunications network and service
TW251402B (en) * 1994-01-17 1995-07-11 Ind Tech Res Inst Data processor of network connection
JP2830766B2 (ja) * 1994-02-24 1998-12-02 ヤマハ株式会社 ネットワーク構築方法
TW364241B (en) * 1994-02-24 1999-07-11 Yamaha Corp Network system containing electronic musical machines
JP2848779B2 (ja) * 1994-05-18 1999-01-20 沖電気工業株式会社 ネットワークノードシステム

Also Published As

Publication number Publication date
EP0766428A2 (de) 1997-04-02
EP0766428A3 (de) 2004-01-14
DE69634505D1 (de) 2005-04-28
JPH0993250A (ja) 1997-04-04
KR970019263A (ko) 1997-04-30
SG86309A1 (en) 2002-02-19
EP0766428B1 (de) 2005-03-23
JP3271493B2 (ja) 2002-04-02
KR100305709B1 (ko) 2001-11-30
US5825752A (en) 1998-10-20

Similar Documents

Publication Publication Date Title
DE69634505T2 (de) Lokales Netz zum Übertragen von Daten unter Verwendung von isochronen und asynchronen Kanälen
DE19581234B4 (de) Bussteuereinrichtung und Verfahren für eine hierarchische serielle Busanordnung unter Verwendung von Kommunikationspaketen
DE69922690T2 (de) Fehlertolerante netze
DE69812777T2 (de) Verbindung von Ethernetkompatiblen Netzwerken
DE69829346T2 (de) Ein-/Ausgabevorrichtung für ein Peripheriegerät
DE69636201T2 (de) Methode zur Mehrfachaussendung in Netzwerken mit ARQ zur Vermeidung unnötiger Wiederholungsübertragungen
DE69737643T2 (de) Vorrichtung zur Paketübertragung
DE69923981T2 (de) Verfahren und Anordnung in einem Telekommunikationsnetz
DE69535108T2 (de) Verfahren und apparat zum herstellen einer seriellen schnittstelle für isochrone und asynchrone peripheriegeräte
DE69631502T2 (de) Verteiltes interaktives Multimediadienstesystem
DE69332778T2 (de) Verfahren und geraet mit einzigadressenzuweisung, knotenselbstidentifizierung und topologieabbildung fuer einen gerichteten, acyclischen graph
DE60123915T2 (de) Kommunikationssystem und -vorrichtung
DE10296675T5 (de) Virtuelles Vernetzungssystem und -verfahren in einem Verarbeitungssystem
DE60131841T2 (de) Verfahren zur isochronen betriebsmittelverwaltung in einem netz auf der basis von hiperlan2-technologie
EP0996257A2 (de) Netzwerk mit Brücken-Terminal zur Übertragung von Daten zwischen mehreren Sub-Netzwerken
DE60131765T2 (de) Verfahren zur verbindung mehrerer kommunikationsbusse mit drahtlosen verbindungen
DE60026006T2 (de) System zum Empfang von Mehrfachdaten
CN102142978B (zh) 数据备份传输处理方法、装置及系统
JP2806466B2 (ja) データ伝送制御方法
DE60028174T2 (de) Datenübertragungsverfahren mittels Schicht-2-Signalisierung der Protokollkennung, Funkendgerät und Funk-Gateway
US6728821B1 (en) Method and system for adjusting isochronous bandwidths on a bus
DE19848342A1 (de) Lokales Netzwerk mit einem Brücken-Terminal zur Übertragung von Daten zwischen mehreren Sub-Netzwerken und zur Schleifendetektion
DE60034398T2 (de) Verfahren zur Datenübertragungsverwaltung
DE60103215T2 (de) Verwendung einer zentralen Datenanbieter zum Koordinieren von Erkennungenszuweisung in einem verteilten System
DE10252448A1 (de) Verfahren für das Identifizieren von Vorrichtungen, die ein Multicast-Kanalzuweisungsprotokoll (MCAP) auf demselben Netzwerk unterstützen und Multicast-Kommunikationsnetzwerk das dieses verwendet

Legal Events

Date Code Title Description
8364 No opposition during term of opposition