DE3608126C2 - - Google Patents
Info
- Publication number
- DE3608126C2 DE3608126C2 DE3608126A DE3608126A DE3608126C2 DE 3608126 C2 DE3608126 C2 DE 3608126C2 DE 3608126 A DE3608126 A DE 3608126A DE 3608126 A DE3608126 A DE 3608126A DE 3608126 C2 DE3608126 C2 DE 3608126C2
- Authority
- DE
- Germany
- Prior art keywords
- address
- frame
- cable
- data frame
- subscriber
- 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
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/06—Addressing a physical block of locations, e.g. base addressing, module addressing, memory dedication
- G06F12/0646—Configuration or reconfiguration
- G06F12/0669—Configuration or reconfiguration with decentralised address assignment
-
- 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/407—Bus networks with decentralised control
- H04L12/413—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection (CSMA-CD)
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5038—Address allocation for local use, e.g. in LAN or USB networks, or in a controller area network [CAN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5092—Address allocation by self-assignment, e.g. picking addresses at random and testing if they are already in use
Description
Die Erfindung bezieht sich auf ein Verfahren zur Zuordnung einer
speziellen Adresse zu einem an ein Datenübertragungsmedium
angekoppelten Datenverarbeitungsgerät, im folgenden Teilnehmer genannt,
gemäß Oberbegriff des Anspruchs 1. Ein besonderes An
wendungsgebiet der Erfindung ist die Adreßzuordnung von Teilnehmern
in einem lokalen Netzwerk (LAN).
Bei bekannten lokalen Netzwerken (US-PS 40 63 220) finden in
der Regel komplexe Verkabelungstechniken und Protokolle Verwendung,
die den Datenverkehr zwischen mit dem LAN gekoppelten Da
tenverarbeitungsgeräten unter verschiedenen Bedingungen regeln.
Um den Datenverkehr zwischen den Teilnehmern störungsfrei zu
gewährleisten, ist es unter anderem erforderlich, jedem Teilnehmer
eine im Netzwerk einmalige Adresse eindeutig zuzuordnen.
Dies geschieht bisher durch die Vergabe von fest in jedem Daten
verarbeitungsgerät einzustellenden Adressen durch den Betreiber
des Netzwerks oder durch die Vergabe der Teilnehmer-Adressen
durch ein zentrales Datenverarbeitungsgerät. Das An- oder Abkoppeln
von Teilnehmern an das Netzwerk erfordert zusätzliche Be
legungszeiten des Busses und/oder Hardware-Mehraufwand durch zusätzliche
Leitungen zum zentralen Datenverarbeitungsgerät
und/oder zwischen den Teilnehmern.
Eine Verringerung dieses Aufwands erreichen neuere Lösungen
durch Einrichtungen und Protokolle, die eine Adressenauswahl und
-vergabe durch den sich ankoppelnden Teilnehmer selbst vorsehen.
Solche Lösungen ermöglichen eine Gleichberechtigung aller
Teilnehmer und einen vom Teilnehmer bestimmbaren Zeitpunkt der
Ankopplung.
Aus der EP-OS 00 74 865 ist ein Verfahren der eingangs genannten
Art bekannt, bei welchem ein sich ankoppelnder Teilnehmer
seine Adresse selbst auswählt.
Dabei beinhaltet der Adreßauswahlprozeß eine gegebenenfalls
wiederholte zufällige Auswahl einer Versuchsadresse, ihre Überprüfung
auf Zulässigkeit und die anschließende Vergabe als endgültige
Adresse. Der sich ankoppelnde Teilnehmer wählt zunächst
eine Zufallsadresse aus, berechnet aus dieser dann eine vorläufige
Adresse, die in einem von den bereits an das Netz angekoppelten
Teilnehmern nicht belegten Adreßbereich liegt. Dann sendet
der sich ankoppelnde Teilnehmer ein Abfrage-Signal aus, welches
als Zieladresse die Zufallsadresse und als Quelladresse
die daraus abgeleitete vorläufige Adresse enthält. Ist die Zu
fallsadresse bereits im Netzwerk vergeben, so antwortet der
Inhaber dieser Adresse mit einem Bestätigungs-Signal. Empfängt
der sich ankoppelnde Teilnehmer in einem vorgegebenen Zeitintervall
nach Absenden des Abfrage-Signals kein Bestätigungs-Signal,
so wiederholt er das Absenden des Abfrage-Signals in einer
vorbestimmten Anzahl von Zyklen. Bleibt auch das letzte der Ab
frage-Signale ohne Antwort, so ordnet sich der ankoppelnde Teilnehmer
die Zufallsadresse im letzten Schritt des Adreßauswahl
prozesses als endgültige Adresse zu. Empfängt er jedoch nach Absenden
eines Abfrage-Signals ein Bestätigungs-Signal, so wird
der gesamte Adreßauswahlprozeß wiederholt.
Aufgabe der Erfindung ist es, eine Verkürzung und Vereinfachung
der Adreßzuordnung und eine kürzere Belegung des Daten
übertragungsmediums bei hoher Sicherheit der Adreßauswahl zu erreichen.
Diese Aufgabe wird bei einem Verfahren der eingangs genannten
Art erfindungsgemäß durch die kennzeichnenden Merkmale des
Anspruchs 1 gelöst.
Die zufällige Versuchsadresse ist (ohne Offset) vom Beginn
des Absendens des ersten Abfrage-Datenrahmens oder -Datenblocks
an die vorläufige Adresse des sich ankoppelnden Teilnehmers. Sie
wird zur endgültigen Adresse, wenn der letzte ausgesandte Abfrage-
Datenrahmen innerhalb einer vorgegebenen Zeit von dem Da
tenübertragungsmedium unbeantwortet bleibt. Das Absenden eines
einzigen Synchronisations-Impulses mit nachfolgender Pause vor
Absenden des Abfrage-Datenrahmens dient dem Vermeiden von Kollisionen;
denn dieser Impuls stellt bei minimaler Netzbelegung
sämtliche an das Netzwerk angeschlossenen Teilnehmer im Moment
des Empfangs dieses Impulses auf den Empfang weiterer Signale
ein.
Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen
gekennzeichnet.
Im folgenden wird die Erfindung anhand eines in der Zeichnung
dargestellten Ausführungsbeispiels näher erläutert. Dabei wird
abkürzend der Abfrage-Datenrahmen als ENQ-Rahmen und der Bestätigungs-
Datenrahmen als ACK-Rahmen bezeichnet. In der Zeichnung
zeigt
Fig. 1 ein lokales Netzwerk, das zur Umsetzung der Lehre der
Erfindung geeignet ist;
Fig. 2 ein Zeitdiagramm, das die erfindungsgemäße Verwendung
einer frequenzmodulierten (FM-0)Codierung veranschaulicht;
Fig. 3 das von der Erfindung verwendete Rahmenformat zur Da
tenübertragung an verschiedene Datenverarbeitungsgeräte, die an das lokale Netzwerk angekoppelt sind;
Fig. 4 die erfindungsgemäß vorgesehene Verwendung eines Syn
chronisationsimpulses vor der Übertragung eines Datenrahmens;
Fig. 5 einen ENQ-Rahmen, der erfindungsgemäß während der dynamischen
Adreßzuordnung benutzt wird;
Fig. 6 ein Flußdiagramm, das die von einem angekoppelten
Datenverarbeitungsgerät während der dynamischen
Adreßzuordnung benutzte Folge von Operationen
veranschaulicht;
Fig. 7 schematisch die Verwendung von handshake-Signalen
zwischen sendenden und empfangenden Daten
verarbeitungsgeräten vor der Übertragung eines
Datenrahmens;
Fig. 8a und 8b ein Flußdiagramm, das die Operationsfolge
eines sendenden Geräts zur Gewinnung eines
Kabelzugriffs veranschaulicht;
Fig. 9 eine schematische Darstellung der Übertragung
eines "RTS"-Rahmens durch ein sendendes Gerät
nach der Abtastung eines freien Kabels;
Fig. 10 ein Blockschaltbild der vorgesehenen
Verwendung eines Seriensteuergeräts, das
mit dem Lokalen Netzwerk gekoppelt ist;
Fig. 11 die vorgesehene Kollisionsver
meidungsmethode einschließlich Zurückstellung;
Fig. 12 den Kollisions- und Auflösungsmechanismus,
wobei zwei "RTS"-Rahmen in einem
Lokalen Netzwerk kollidieren; und
Fig. 13a und 13b ein die Erzeugung der Zufallswarteperiode R
darstellendes Flußdiagramm.
Beschrieben wird ein Lokales Netzwerk (LAN) mit
einem Verfahren zur Datenübertragung zwischen einer
Vielzahl von Datenverarbeitungsresourcen, die an ein gemeinsames
Kabel angeschlossen sind. In der folgenden Beschreibung
werden zu Erläuterungszwecken spezielle Zahlen, Bytes, Register,
Adressen, Zeiten, Signale und Formate usw. angegeben, um
die Erfindung besser verständlich zu machen. Es ist für den
Fachmann jedoch klar, daß die Erfindung auch ohne diese besonderen
Detailangaben realisiert werden kann. In anderen Fällen
sind bekannte Schaltungen und Geräte in Blockschaltbildform
gezeigt, um das Ausführungsbeispiel der Erfindung nicht mit unnötigen Einzelheiten zu
belasten.
Im folgenden wird auf Fig. 1 Bezug genommen. Das die Erfindung umsetzende
LAN kann eine Vielzahl von Datenverarbeitungsgeräten, bezeichnet
mit den Bezugszeichen 25 bis 28, sowie Peripheriegeräte, wie
einen Drucker 30 (oder andere Geräte, z. B. einen Gesamtspeicher,
ein Plattenlaufwerk o. dgl.) enthalten. Für die Zwecke
der vorliegenden Beschreibung werden alle Datenverarbeitungs-
und Peripheriegeräte
insgesamt als "Teilnehmer"
bezeichnet. Wie gezeigt, sind die Datenverarbeitungsgeräte 25,
26, 27, 28 und der Drucker 30 zur gegenseitigen Datenübertragung
über ein gemeinsames Kabel (Datenübertragungsmedium) 32 miteinander verbunden. Die
verschiedenen Geräte sind an das Kabel 32 durch Verbindungsmoduln
34 angekoppelt, die bei dem bevorzugten Ausführungsbeispiel
einen passiven Koppeltransformator, Widerstands- und
Kapazitätsschaltungen enthalten und im Stand der Technik zum
Ankoppeln sowohl von Datenverarbeitungsgeräten als auch von
anderen Geräten an das Kabel 32 bekannt sind. Das Kabel 32 ist
so abgeschlossen, daß Signalreflexionen eliminiert werden. Bei
dem bevorzugten Ausführungsbeispiel ist das Kabel 32 mit 100-
Ohm-Widerständen abgeschlossen und besteht aus einem verdrillten
Leitungspaarkabel. Es ist für den Fachmann klar, daß das
Kabel 32 irgendein gemeinsam benutztes Medium, wie Koaxialkabel,
eine Faseroptik, ein Funkkanal o. dgl. sein kann. Da
bei dem beschriebenen Ausführungsbeispiel die Teilnehmer passiv
an das Kabel 32 angekoppelt sind, unterbricht das Fehlen
eines Teilnehmers oder eines Verbindungsmoduls die Datenübertragung
über das Kabel 32 nicht.
Wie beschrieben werden wird, stellt das Ausführungsbeispiel der Erfindung ein Verfahren
zur Verfügung, das eine synchrone Serien
kommunikation und Datenübertragung zwischen Datenverarbeitungsgeräten
25 bis 28 und anderen Peripheriegeräten, wie dem
Drucker 30 ermöglicht, und zwar unter Verwendung von Protokollen
und Kollisionsverhinderungs- und -bestimmungsverfahren und
-einrichtungen. Die vorgesehene Architektur
und die Protokolle minimieren komplizierte handshake- und
Kollisionsbestimmungsmaßnahmen, die bei bekannten Systemen
erforderlich sind, und erlauben eine extrem schnelle Serien
kommunikation über das Kabel 32. Es wird der
Zugriff zu verschiedenen Resourcen erlaubt, die an das Netz angeschaltet
sind, z. B. zu in örtlichen Speichern oder Platten gespeicherten
Daten, und die gemeinsame Verwendung globaler Drucker,
ohne komplizierte oder aktive Abschlußschaltungen an den Kabelenden
oder vordefinierte Adressen für jedes an das Kabel 32
angekoppelte Gerät zu benötigen. Bei dem beschriebenen Ausführungsbeispiel
arbeitet man mit etwa 230 Kilobits pro
Sekunde durch ein abgeschirmtes verdrilltes Leiterpaarkabel 32
und wird versorgt entsprechend der EIA-Norm RS-422 abgeglichenen
Spannungsspezifikationen.
Im folgenden wird auf Fig. 2 Bezug genommen. Daten werden
verschlüsselt und zum Kabel 32 übertragen unter Verwendung
einer Eigentaktmethode, die als FM-0 (Bi-Phasenabstand) bekannt
ist, wobei jede Bitzelle bei einer Dauer von typischerweise
4,43 µs an ihrem Ende durch einen Zustandsübergang begrenzt
ist, wodurch die notwendige Zeitinformation an den
Empfänger gegeben wird. Wie dargestellt, werden Nullen so
codiert, daß ein zusätzlicher Nulldurchlauf in der Zellenmitte
vorgesehen wird, so daß zwei Nulldurchläufe für jede 4,34-µs-Zelle
festgestellt werden. Eine logische Eins ist in einer
speziellen Zelle durch einen Nulldurchgang am Zellenende gekennzeichnet.
Durch die Verwendung der FM-0-Codierung wird die
Taktinformation in dem Datensignal selbst übertragen, wodurch
die Erfindung einen synchronen Betrieb gewährleistet.
Im folgenden wird auf Fig. 3 Bezug genommen. Das Ausführungsbeispiel der Erfindung
verwendet eine als "Datenrahmen" 36 bekannte Basiseinheit für die
Datenübertragung. Der Datenrahmen 36 enthält einen Vorspann (preamble),
bestehend aus zwei oder mehr Synchronisationsbytes 38
und 40 ("flags"). Bei dem beschriebenen Ausführungsbeispiel
enthält jedes Synchronisationsbyte die Bits 01111110. Bekanntlich
ermöglichen Synchronisationsbytes 38 und 40 den an das
Kabel 32 angekoppelten empfangenen Datenverarbeitungseinheiten
eine Synchronisation ihrer Empfangsschaltungen und einen
Erhalt der notwendigen Taktinformation (durch Verwendung der
FM-0-Codierung). Hinter den Synchronisationsbytes 38 und 40
ist eine 8-Bit-Bestimmungsadresse 41 vorgesehen, welche die
Adresse desjenigen Datenverarbeitungsteilnehmers angibt, für
die der Datenrahmen vorgesehen ist. Eine Quellenadresse 42 enthält
eine 8-Bit-Adresse des den Datenrahmen sendenden Daten
verarbeitungsteilnehmers. Ein Typ-Feld 45 dient zur Bezeichnung
des Datenrahmentyps, der unter Verwendung verschiedener Codes
gesendet wird. So kann beispielsewise das Typ-Feld 45 einen
Bestätigungs(ACK)rahmen, einen Abfrage(ENQ)rahmen sowie einen
RTS- und CTS-Rahmen bezeichnen, wie weiter unten genauer beschrieben
werden wird. Das Typ-Feld wird gefolgt von einem
Multi-Byte-Datenfeld (möglicherweise der Länge 0), das Ur
sprungsdaten, Nachrichten o. dgl. für die Übertragung zwischen
an das Kabel 32 angekoppelten Teilnehmern enthalten kann. Nach
dem Datenfeld 48 folgt eine 16-Bit-Rahmenprüffolge, die als
Funktion des Inhalts der Quellenadresse, der Bestimmungsadresse,
der Typ- und Datenfelder berechnet wird. Bei dem beschriebenen
Ausführungsbeispiel wird die Rahmenprüffolge (FCS) unter
Verwendung des CRC-CCITT Polynomialstandards definiert. Die
Rahmenprüffolge 50 wird gefolgt von einem 8-Bit-Synchronisations-
"flag"-Nachspann 52 (bestehend aus den logischen Bits
01111110) und einer Abbruchfolge 53, welche aus elf oder mehr
Einsen in einer Reihe besteht. Die Abbruchfolge 53 dient dazu,
das Ende des Rahmens 36 den an das Kabel 32 angeschlossenen
Teilnehmern zu bezeichnen. Wie beschrieben werden wird, wird
der Rahmen 36 über die Leitung 32 in einer seriellen synchronisierten
Weise unter Verwendung einer Handshake-Folge von
Steuerrahmen übertragen, die wiederum von dem Datenrahmen 36
gemäß Fig. 3 gefolgt werden.
Wie in Fig. 4 gezeigt ist, sendet ein im Sendebetrieb befindlicher,
an das Kabel 32 angekoppelter Teilnehmer vor der Übertragung
eines Rahmens einen Synchronisationsimpuls 56, der von
einer Ruheperiode von mehr als 2 Bitzeiten und weniger als 10 Bitzeiten
gefolgt ist. Der Impuls 56 kann irgendein einen
Nullübergang enthaltendes Signal aufweisen. Bei dem beschriebenen
Ausführungsbeispiel verwendet jeder an das Kabel 32
angekoppelte Teilnehmer ein Zilog Z8530 SCC Serienverbindungs
steuerchip 79 (Fig. 10), das über einen Leitungstreiber 80 und
einen Leitungsempfänger 82 zum Kabel 32 zugreift. (Vgl. Zilog
Technical Manual, Z8030/Z8530 SCC Serial Communications Controller,
Januar 1983). Das Z8530 SCC-Gerät 79 enthält eine
Schaltung, die in einem "Such-Modus" nach Synchronisationsflagbits
sucht. Wie oben erwähnt, benutzt man ein
Synchronisationsflagbyte mit den Bitzuständen 01111110.
Außerdem hat das Serienkommunikationssteuerchip die Fähigkeit,
einen fehlenden Taktzyklus festzustellen und ein "Fehlender-Takt"-
Bit innerhalb des Geräts zu setzen, wenn es einem vorgegebenen
Nulldurchgang folgt, eine vorgegebene Periode (länger
als die Zeit eines Bits) verstreicht, ohne daß ein nachfolgender
Nulldurchgang des einlaufenden Signals RxD auftritt.
Der von dem mit dem Kabel 32 gekoppelten sendenden Teilnehmer
gelieferte Synchronisationsimpuls 56 wird als ein Takt von allen empfangenden Teilnehmern
interpretiert. Da dieser Impuls jedoch von einer Ruheperiode
länger als 2 Bitzeiten gefolgt wird, wird ein fehlender
Takt festgestellt, und das "Fehlender-Takt"-Bit wird in dem
SCC-Gerät 79 jedes mit dem Kabel 32 verbundenen Teilnehmers
gesetzt, wodurch den Teilnehmern kenntlich gemacht wird, daß
das Kabel 32 in Benutzung ist. Bei dem bevorzugten Ausführungsbeispiel
wird der Synchronisationsimpuls 56 durch momentane
Aktivierung des Leitungstreibers 80 für wenigstens eine
Bitzeit gewonnen. Dies bewirkt für die Zeit der Impulsdauer
eine Übertragung des Signals TxD auf das Kabel 32, wodurch
wenigstens ein Nulldurchgang im Synchronisationsimpuls 56
sichergestellt wird. Außerdem löscht die Feststellung von
Synchronisations-flag-Bits (d. h. 38 und 40) das "Such"bit im
Z8530-Gerät und erlaubt jedem Teilnehmer, der an das Kabel 32
angekoppelt ist, eine wirksamere Feststellung, ob das Kabel 32
vor dem Senden eines Rahmens in Benutzung ist. Außerdem werden
die notwendigen Synchronisationsbits gebildet, welche dem
empfangenden Teilnehmer eine Taktanpassung an den einlaufenden
Datenrahmen ermöglichen. Es ist einzusehen, daß anstelle eines
gemäß vorliegender Beschreibung verwendeten Z8530 SCC-Geräts
zur Festellung fehlender Taktzyklen und Synchronisationsbytes
auch andere Schaltungen für gleiche Funktionen einsetzbar
sind.
Jeder an das Kabel 32 angekoppelte Teilnehmer wird durch eine
spezielle Binäradresse entlang des Kabels identifiziert. Ein
Merkmal besteht darin, daß ein an das Kabel 32
angekoppelter Teilnehmer keine vordefinierte Daueradresse
benötigt. So kann beispielsweise das Gerät 27 vom Kabel 32
abgetrennt und danach mit einem anderen Kabel an einer anderen
Stelle neu gekoppelt werden, ohne Konfiguration einer Adresse.
Wenn ein Teilnehmer neu an das Kabel 32 angekoppelt wird, wird
nach einem speziellen Protokoll vorgegangen, und zwar derart,
daß eine Adresse dynamisch erzeugt und durch den Teilnehmer
selbst sich zugeordnet wird. Bei dem bevorzugten Ausführungsbeispiel
wird die Adresse jedes Teilnehmers unter Verwendung
eines 8-Bit-Identifizierers identifiziert (wobei kein Teilnehmer
die Adresse 0 oder die Adresse 255 haben kann).
Die Operationsfolge, welche ein Teilnehmer ausführt, um eine
Adresse zu bestimmen und sich selbst zuzuordnen, wird im folgenden
kurz anhand von Fig. 6 erläutert. Es ist einleuchtend,
daß kein Teilnehmer dieselbe Adresse wie ein bereits arbeitender
Teilnehmer haben darf, wenn nicht der Service unterbrochen
werden soll. In der Praxis kann die Adresse von Teilnehmern
zwischen Universaldatenverarbeitungsgeräten und Dienststationen
("servers") zugeordnet werden, zu denen Großrechner oder andere
Maschinen gehören können. Bei dem beschriebenen Ausführungsbeispiel
sind Adressen 1 bis 127 Universalteilnehmern und
Adressen 128 bis 254 Dienststationen zugeordnet. Wie in Fig. 6
gezeigt, erzeugt jeder Teilnehmer nach der Ankopplung an das
Kabel 32 eine beliebige Zufallszahl oder -nummer innerhalb
eines vorgegebenen Bereichs oder erhält eine Startnummer von
einem Langzeitspeicher (beispielsweise einem Festwertspeicher
oder einem magnetischen Aufzeichnungsmedium), die als "Vorschlag"
bezeichnet wird. Diese Zufallsnummer (oder "Vorschlag")
wird als Versuchsadresse behandelt, und der Teilnehmer
sendet einen Abfrage(ENQ)rahmen, der die Versuchsadresse
als Bestimmungsadresse benutzt. Dem gesendeten ENQ-Rahmen,
der die in Fig. 5 dargestellte Form hat, ist ein Synchronisationsimpuls
56 um wenigstens zwei Bitzeiten vorangestellt, der vor
den Synchronisations-flag-bytes 38 und 40, zuvor beschrieben
mit Bezugnahme auf Fig. 3, erzeugt wird. Die Bestimmungsadresse
41 der Fig. 5 sowie die Quellenadresse 42 enthält die willkürlich
oder aufgrund des Vorschlags erzeugte Versuchsadresse.
Zu beachten ist, daß das Typ-Feld 45 in Fig. 5 einen Binärcode
enthält, der den Rahmen der Fig. 5 als ENQ-Rahmen
zur Verwendung bei der Adressenzuordnung identifiziert. Dieser
ENQ-Rahmen wird über das Kabel 32 übertragen. In dem Falle,
daß einem anderen Teilnehmer die Zufallsadresse bereits zuvor
zugeordnet worden ist, sendet der die Versuchsadresse bereits
benutzende Teilnehmer nach Empfang des ENQ-Rahmens als Antwort
einen Bestätigungsrahmen (ACK) zurück zum sendenden Teilnehmer.
In der Praxis ist der ACK-Rahmen ähnlich dem ENQ-Rahmen
gemäß Fig. 5 aufgebaut, mit der Ausnahme, daß das Typ-Feld
einen Binärcode enthält, der den Rahmen als ACK-Rahmen identifiziert.
Wie in Fig. 6 dargestellt, muß der sendende Teilnehmer bei
Empfang des ACK-Rahmens eine andere Zufallsnummer
als Versuchsadresse erzeugen und danach die Sendung dieser
neuen Versuchsadresse über das Kabel 32 wiederholen. In dem
Falle, daß kein ACK-Rahmen empfangen wird, setzt der neu an
das Kabel angekoppelte Teilnehmer die Übertragung von ENQ-Rahmen
auf das Kabel so lange fort, bis eine vorgegebene Maximalanzahl
von Versuchen stattgefunden hat. Wenn nach einer vorgegebenen
Anzahl von Versuchen kein ACK-Rahmen eingeht, ordnet
sich der sendende Teilnehmer die Versuchsadresse als endgültige
Adresse für alle zukünftigen Datenübertragungen über das
Kabel 32 zu. Die wiederholte Sendung von ENQ-Rahmen dient zur
Vermeidung von Fällen, bei denen ein spezieller Teilnehmer,
der die Versuchsadresse benutzt, augenblicklich belegt ist und
daher den Empfang einer Anfrage verfehlt.
Sobald eine endgültige Adresse einem Teilnehmer zugeordnet
ist, kann dieser mit anderen, mit dem Kabel 32 gekoppelten
Teilnehmern in Verbindung treten, wobei ein Handshake-Protokoll
und ein weiter unten beschriebener Kollisionsvermeidungsmechanismus
verwendet wird. Im folgenden wird auf die Fig. 7,
8a, 8b und 9 Bezug genommen. Eine Datenübertragung zwischen
mit dem Kabel 32 gekoppelten Teilnehmern findet über einen
Dreiwege-Handshake-Prozeß statt. Der Zweck der Handshake-Folge
besteht in der Steuerung des Zugriffs zum mehrfach ausgenutzten
Kabel 32 in einer geordneten Weise derart, daß die Wahr
scheinlichkeit einer Kollision verringert wird. Jede Datenübertragung
einschließlich des Handshakes (bekannt als "Dialog")
muß um einen Inter-Dialog-Mindestabstand (IDG) getrennt
sein, der bei dem beschriebenen Ausführungsbeispiel 400 µs
beträgt. Außerdem müssen die Rahmen innerhalb einer einzigen
Datenübertragung (Dialog) einander innerhalb eines maximalen
Zwischenrahmenabstands (IFG) von bei dem beschriebenen Ausführungsbeispiel
200 µs folgen. Eine Kollision wird als gegeben
angesehen, wenn zwei oder mehr Teilnehmer gleichzeitig auf dem
Kabel 32 senden.
Im folgenden wird auf die Fig. 7 und 8a sowie 8b Bezug
genommen. Der sendende Teilnehmer, beispielsweise die Daten
verarbeitungsstation 25, die mit einem anderen an das Kabel 32
angekoppelten Teilnehmer in Verbindung treten will, führt die
im Flußdiagramm gemäß den Fig. 8a und 8b angegebenen Operationen
aus. Ein sendender Teilnehmer stellt vor der Datenübertragung
fest, ob das "Such"bit im Z8530 SCC-Seriensteuergerät
oder einer anderen Maschine ein Synchronisations-flag-Byte
über das Kabel 32 festgestellt hat. Wenn ein Synchronisations-
flag-Byte festgestellt wurde, dem kein Abbruchbyte folgte,
so ist das Kabel 32 derzeit belegt bzw. in Gebrauch, und
der den Sendebetrieb anstrebende Teilnehmer stellt seine Übertragung
zurück. In dem Falle, daß kein Synchronisationsimpuls
56 oder Synchronisations-flag-Bytes (38 und 40) festgestellt
werden, führt der die Datenübertragung wünschende Teilnehmer
eine Frontenden-Warteoperation aus, die am besten in Fig. 8a
dargestellt ist. Die Frontenden-Warteoperation besteht aus
einer Folge von vier Warteperioden, von denen jede bei dem
beschriebenen Ausführungsbeispiel eine Dauer von 100 µs hat,
nach denen jeweils die flag-Erkennung ("Such"bit) geprüft
wird, um festzustellen, ob ein Synchronisations-flag-Byte auf
dem Kabel 32 empfangen worden ist. Die Feststellung eines Synchronisations-
flag-Bytes zeigt, daß ein anderen Teilnehmer das Kabel 32 im
Augenblick belegt. In einem solchen Falle muß der sendende
Teilnehmer darauf warten, daß die flag-Erkennung ("Such"bit)
gelöscht wird, wodurch das Ende der Kabelbelegung angezeigt
wird. An dieser Stelle wird die gesamte Frontenden-Wartefolge
gemäß Fig. 8a und 8b wiederholt.
Wenn andererseits ein flag-Byte nicht festgestellt wird, so
zeigt dies an, daß kein anderer Teilnehmer während der Frontenden-
Wartefolge versucht hat, das Kabel zu benutzen, und
daraufhin wird eine Zufallswarteoperation ausgeführt. Außerdem
wird während der Frontenden-Warteoperation die Synchronisa
tionsimpulsfeststellung gelöscht, nachdem die erste 100-µs-Warteperiode
abgelaufen ist.
Bevor die in Fig. 8b dargestellte Zufallswarteoperation ausgeführt
wird, wird eine Zufallswartenummer bzw. -zahl R erzeugt
(die Einzelheiten bezüglich der Erzeugung von R werden weiter
unten erörtert). Wie dargestellt, laufen die Zufallswarteope
rationszyklen R-mal durch eine Basisoperation von 100 µs,
bevor eine Prüfung vorgenommen wird, um zu sehen, ob ein flag
festgestellt worden ist ("Such"bit gelöscht). Wenn zu irgendeinem
Zeitpunkt ein flag festgestellt wird, so benutzt ein anderer
Teilnehmer das Kabel 32, und der sendende Teilnehmer muß
seine Übertragung zurückstellen bzw. aufschieben. Wenn jedoch
am Ende der Zufallswartefolge das Kabel weiter ruhig bleibt
(nicht in Benutzung ist), so wird eine letzte Prüfung vorgenommen,
um zu sehen, ob ein Synchronisationsimpuls festgestellt
worden ist, bevor ein RTS-Rahmen in der nachfolgend
beschriebenen Weise gesendet wird.
Wenn das Kabel 32 über diese willkürlich erzeugte Warteperiode R
freibleibt, fährt der sendende Teilnehmer mit der Übertragung
eines Synchronisationsimpulses 56 fort, gefolgt durch
einen "RTS"-Rahmen über das Kabel 32 zum empfangenden Teilnehmer.
Ein RTS-Rahmen ist im wesentlichen in derselben Weise wie
ein ENQ-Rahmen gemäß Fig. 5 aufgebaut; das Typfeld enthält
jedoch einen Binärcode, der den Rahmen als RTS-Rahmen und
nicht als ENQ-Rahmen identifiziert. Der empfangende Teilnehmer
sendet nach Empfang des RTS-Rahmens vom sendenden Teilnehmer
einen "CTS"-Rahmen zurück zum ursprünglich sendenden Teilnehmer,
und zwar innerhalb der durch den maximalen Zwischenrahmenabstand
(IFG) gebildeten Periode. Wie im Falle des RTS-Rahmens
ist ein CTS-Rahmen, der vom empfangenden Teilnehmer übertragen
wird, im wesentlichen ebenso wie der ENQ-Rahmen gemäß
Fig. 5 aufgebaut, mit der Ausnahme, daß das Typ-Feld einen den
Rahmen als CTS identifizierenden Code enthält. Sobald der
ursprünglich sendende Teilnehmer, beispielsweise die Datenver
arbeitungseinheit 25, den CTS-Rahmen empfängt, wird ein voller
Datenrahmen 36 entsprechend Darstellung in Fig. 3 zum empfangenden
Teilnehmer innerhalb eines IFG nach Empfang des CTS-Rahmens gesendet. In dem Falle, daß die Sendung eines CTS-
oder Daten-Rahmens innerhalb einer IFG nicht auftritt, nimmt
der sendende Teilnehmer an, daß eine Kollision aufgetreten ist
oder der Bestimmungsteilnehmer inaktiv oder in anderer Weise
unerreichbar ist.
Wenn eine Generalnachricht an alle mit dem Kabel 32 gekoppelten
Teilnehmer erwünscht ist, sendet der sendende Teilnehmer
einen RTS-Rahmen mit einer Bestimmungsadresse von 255 an alle
Teilnehmer der Leitung und wartet für eine IFG-Periode bis zur
Sendung eines Datenrahmens 36, der auch eine Bestimmungsadresse
von 255 hat. Demgemäß wartet der sendende Teilnehmer im
Falle einer Generalnachricht über das Kabel 32 nicht auf rücklaufende
CTS-Rahmen, sondern fährt unverzüglich mit der Sendung
der Generalnachricht fort, sobald nach dem Senden eines
RTS-Rahmens eine IFG-Periode verstrichen ist. Durch Bildung
eines Bestimmungsadreßfeldes 41 mit dem einer Sendeadresse
entsprechenden besonderen Wert (255) innerhalb des RTS-Rahmens
braucht nur ein RTS-Rahmen an alle Teilnehmer unter den verschiedenen
Adressen entlang des Kabels 32 gesendet zu werden.
Es ist für den Fachmann klar, daß der Zweck des oben beschriebenen
dreistufigen Handshake-Protokolls darin besteht, Kollisionen
durch Begrenzung derjenigen Perioden zu vermeiden, in
denen Kollisionen mit hoher Wahrscheinlichkeit auftreten (ty
pischerweise während der RTS- und CTS-Rahmen-Austausche), und
den zeitlichen Kabelzugriff der vor dem Beginn einer Sendung
auf ein freies Kabel 32 wartenden Sender auszudehnen. Ein
erfolgreicher RTS-CTS-Rahmen-Austausch zeigt, daß keine Kollision
aufgetreten ist und daß alle Teilnehmer, welche in den
Sendebetrieb gehen wollen, die einlaufenden Datenrahmen abgetastet
haben und bis zur Beendigung des laufenden Datenaustauschs
warten, bevor sie einen Versuch zur Übernahme der
Kabelkontrolle unternehmen.
In dem Falle, daß ein anderen Teilnehmer während des oben
beschriebenen RTS-CTS-Rahmen-Austausches einen Sendebetrieb
beginnt, wird der CTS-Rahmen nicht in geeigneter Weise empfangen
(z. B. die Rahmenprüffolge ist ungültig), und der sendende
Teilnehmer kann dann annehmen, daß eine Kollision aufgetreten
ist. Eine Kollision verhindert einen vollständigen RTS- und
CTS-Rahmen-Austausch und verhindert dadurch das Auftreten
eines geeigneten Handshakes. Wenn ein Daten über das Kabel 32
zu senden wünschender Teilnehmer feststellt, daß das Kabel
gegenwärtig belegt ist, stellt er den Sendebetrieb seines
eigenen RTS so lange zurück, bis das Kabel frei wird (siehe
Fig. 11 und 12).
Im folgenden wird unter Bezugnahme auf die Fig. 9, 13a und
13b die auszuführende Operationsfolge zur
Gewinnung des Werts der Zufallswartenummer R (zuvor unter
Bezugnahme auf Fig. 8 erläutert) beschrieben. Man
ändert dynamisch die Zufallswartenummer R in Abhängigkeit von
der jüngsten Kabelverkehrsgeschichte. Das dazu
benutzte Verfahren unterstellt, daß bei der Annahme von Kollisionen
für jüngst gesendete Datenrahmen das Kabel 32 derzeit
stark belastet und umstritten ist. Eine Zufallswarteperiode R
vor einem neuen Sendeversuch verteilt den Buszugriff zeitlich
auf die sich um die Kabelbenutzung bemühenden verschiedenen
Teilnehmer. Demgemäß werden die in Fig. 13a und 13b dargestellten
Operationen ausgeführt, um die Zufallswartenummer R
entsprechend der Operationsfolge gemäß den Fig. 8a und 8b
zu erzeugen und einzustellen. Es sind 8-Bit-
Schieberegister vorgesehen, um Kollisions- und Aufschubgeschichten
für jeden mit dem Kabel 32 gekoppelten Teilnehmer
verfolgen zu können. Für die Zwecke der vorliegenden Beschreibung
bezeichnet die Variable "C" ein 8-Bit-Schieberegister,
das zum Verfolgen der Kollisionsgeschichte über die letzten
acht, von einem Teilnehmer zu senden versuchten Nachrichten
verwendet wird, und eine Variable "D" bezeichnet ein 8-Bit-
Schieberegister, das die Aufschubgeschichte für wenigstens
acht Nachrichten darstellt, welche zu übertragen versucht
worden sind. Wie oben gesagt, wird eine Kollision unterstellt,
wenn das RTS-CTS-Rahmen-Handshake-Protokoll innerhalb der
IFG-Periode nicht auftritt, und ein Aufschub (Zurückstellen)
scheint aufzutreten, wenn ein Teilnehmer vor dem Senden einer
Nachricht ein flag-Byte oder einen Synchronisationsimpuls 56
feststellt, der anzeigt, daß das Kabel belegt ist. Eine Variable "G"
ist als 4-Bit-Globalmaske definiert, die eine Zahl
zur Bezeichnung eines Modifikationsfaktors darstellt, der alle
vorhergehenden Nachrichten darstellt, welche der Teilnehmer zu
senden versucht hat. Eine Variable "L" wird als lokale Maske
definiert, die Versuche zum Senden der laufenden Nachricht
durch einen an das Kabel 32 angekoppelten Teilnehmer darstellt.
Zusätzlich wird NC als Anzahl von Kollisionen definiert,
welche für einen speziellen Datenrahmen angenommen worden
sind, ND wird definiert als Anzahl von Aufschüben, die
vor dem Senden des laufenden Datenrahmens vorgetreten worden
sind.
Wie am besten in Fig. 13a und 13b dargestellt ist, wird die
Variable G vor dem Senden eines neuen Datenrahmens wie folgt
eingestellt:
Wenn die Anzahl von gesetzten Bits (d. h. gleich 1) in
dem 8-Bit-Register "C" größer als 2 ist, so werden alle
Bits in dem "G" definierenden 4-Bit-Schieberegister um
ein Bit nach links verschoben (das am niedrigsten bewertete
Bit (LSB) in Richtung des am höchsten bewerteten
Bit (MSB)). Außerdem wird G₀ (das am niedrigsten bewertete
Bit des 4-Bit-Schieberegisters G) auf 1 gestellt,
und die acht Bits von C werden auf 0 gesetzt.
Wenn die Zahl von gesetzten Bits im 8-Bit-Register "C" kleiner oder gleich 2 ist, wird D geprüpft, und wenn die in D gesetzte Anzahl von Bits kleiner als 2 ist, wird der Inhalt von G um ein Bit nach rechts (MSB in Richtung LSB) verschoben; G₃ (MSB von G) gleich 0 und der Wert von D gleich 255 gesetzt.
Wenn die Zahl von gesetzten Bits im 8-Bit-Register "C" kleiner oder gleich 2 ist, wird D geprüpft, und wenn die in D gesetzte Anzahl von Bits kleiner als 2 ist, wird der Inhalt von G um ein Bit nach rechts (MSB in Richtung LSB) verschoben; G₃ (MSB von G) gleich 0 und der Wert von D gleich 255 gesetzt.
Sobald G eingestellt worden ist, verschiebt man den
Inhalt der Register D und C um ein Bit nach links (in Richtung
MSB) und setzt das am niedrigsten bewertete Bit (LSB) von C
und D auf 0. In ähnlicher Weise werden auch die Variablen NC
und ND, welche die Anzahl von Kollisionen und Aufschüben für
eine besondere zu sendende Nachricht bezeichnen, auch auf 0
gesetzt. Ferner wird entsprechend der Darstellung in Fig. 13
der Wert von L sodann gleich dem Wert von G eingestellt.
Vor Beginn der Frontenden-Wartefolge, die anhand von Fig. 8a
beschrieben worden ist, bestimmt man, ob ein flag
(d. h. flag-Byte) auf dem Kabel 32 festgestellt worden ist. In
dem Falle, daß kein flag-Byte festgestellt worden ist, wird
die in Fig. 8a für die Frontenden-Warteperiode
dargestellte Operationsfolge ausgeführt. Nach der festen Frontenden-
Wartefolge wird eine Zufallsnummer "r" innerhalb
eines vorgegebenen Bereichs erzeugt und danach der
Wert von "R" durch logische "UND"-Verknüpfung des Werts von r
mit dem zuvor bestimmten Wert von L (lokale Maskenvariable) berechnet.
Sobald der Wert von R bestimmt ist, folgt der in
Fig. 8b gezeigte Zufallswartezyklus, und nach Beendigung der
Zufallswarteperiode wird der RTS-Rahmen entsprechend der Darstellung
in Fig. 13b gesendet.
Wenn der CTS-Rahmen vom sendenden Teilnehmer innerhalb der
IFG-Periode empfangen wird, so wird der Datenrahmen gesendet,
und der Nachrichtendialog ist abgeschlossen. Wenn andererseits
ein flag vor Beginn der Frontenden-Wartefolge festgestellt
wird, wird eine Aufschubeinstellung vorgesehen, in der D₀ (das
LSB des Registers D) auf 1 gesetzt und L₀ auf 1 gesetzt
wird. Zusätzlich enthält die Aufschubeinstellung das Setzen
von ND auf ND+1. Die flag-Festellung (Suchbit) wird
erneut geprüft. Wie in Fig. 13 gezeigt ist, findet die Auf
schubeinstellung in Fällen statt, wo festgestellt wird, daß
die Leitung vor der Sendung belegt ist.
Wenn das RTS/CTS-Handshake nicht erfolgreich ist, wird eine
Kollision angenommen, und es erfolgt eine Kollisionseinstellung.
C₀ wird gleich 1 gesetzt, und der Wert von L wird um
ein Bit nach links verschoben (LSB auf MSB). Zusätzlich wird
L₀ gleich 1 und NC gleich NC+1 gesetzt, wie in Fig. 13b
dargestellt ist.
Es hat sich gezeigt, daß die Verwendung der in Fig. 13 dargestellten
Schritte zu einer dynamischen Einstellung des zufällig
erzeugten Werts von r derart führt, daß die Zeitperiode
(in Schritten von 100 µs), die ein Teilnehmer zusätzlich zur
Frontenden-Warteperiode vor einem Sendeversuch wartet, entsprechend
der jüngsten Kabelverkehrsgeschichte geändert wird.
Diese Änderung der Zufallswarteperiode erhöht wesentlich die
Wahrscheinlichkeit eines erfolgreichen RTS/CTS-Rahmen-Austausches
und verhindert dadurch Kollisionen über das Kabel 32.
Claims (5)
1. Verfahren zur Zuordnung einer speziellen Adresse zu einem
an ein Datenübertragungsmedium angekoppelten Datenverarbeitungsgerät
oder Teilnehmer zur Ermöglichung der Datenübertragung
zwischen einer Mehrzahl von an das Datenübertragungsmedium
angekoppelten Teilnehmern,
wobei im Teilnehmer eine Zufallsnummer in einem vorgegebenen Bereich erzeugt wird,
wenigstens ein Abfrage-Datenrahmen oder -Datenblock erzeugt und über das Datenübertragungsmedium gesendet wird, der die Zufallsnummer als Zieladresse enthält,
auf eine Antwort (Bestätigungs-Datenrahmen oder -Datenblock) eines anderen Teilnehmers auf den Abfrage-Datenrahmen gewartet wird, dessen Adresse die Zieladresse ist, wobei in Abhängigkeit vom Empfang oder Nicht-Empfang des Bestätigungs-Datenrahmens die Adressenauswahl und -zuordnung durch den sich ankoppelnden Teilnehmer selbst erfolgt,
dadurch gekennzeichnet,
daß die Zufallsnummer im Teilnehmer gespeichert und ohne Offset-Adresse als vorläufige oder Versuchsadresse an den Teilnehmer vergeben wird,
daß ein Abfrage-Datenrahmen erzeugt wird, der die Ver suchsadresse sowohl als Ziel- als auch als Quelladresse enthält,
daß im Falle des Empfangs eines Bestätigungs-Datenrahmens eine als neue Versuchsadresse verwendete andere Zufallsnummer erzeugt, gespeichert und gesendet wird,
daß die Versuchsadresse als endgültige Adresse gespeichert wird, wenn innerhalb einer vorgegebenen Zeit, der maximalen Zwischenrahmen-Zeit, nach dem Senden des Abfrage-Datenrahmens kein Bestätigungs-Datenrahmen empfangen worden ist, und
daß ein Synchronisationsimpuls mit nachfolgender Pause (idle period) vor Senden der Datenrahmen, insbesondere des Ab frage-Datenrahmens, erzeugt und auf das Datenübertragungsmedium gesendet wird, wobei die anderen Teilnehmer bei Empfang des Synchronisationsimpulses mit nachfolgender Pause auf Empfang gestellt werden.
wobei im Teilnehmer eine Zufallsnummer in einem vorgegebenen Bereich erzeugt wird,
wenigstens ein Abfrage-Datenrahmen oder -Datenblock erzeugt und über das Datenübertragungsmedium gesendet wird, der die Zufallsnummer als Zieladresse enthält,
auf eine Antwort (Bestätigungs-Datenrahmen oder -Datenblock) eines anderen Teilnehmers auf den Abfrage-Datenrahmen gewartet wird, dessen Adresse die Zieladresse ist, wobei in Abhängigkeit vom Empfang oder Nicht-Empfang des Bestätigungs-Datenrahmens die Adressenauswahl und -zuordnung durch den sich ankoppelnden Teilnehmer selbst erfolgt,
dadurch gekennzeichnet,
daß die Zufallsnummer im Teilnehmer gespeichert und ohne Offset-Adresse als vorläufige oder Versuchsadresse an den Teilnehmer vergeben wird,
daß ein Abfrage-Datenrahmen erzeugt wird, der die Ver suchsadresse sowohl als Ziel- als auch als Quelladresse enthält,
daß im Falle des Empfangs eines Bestätigungs-Datenrahmens eine als neue Versuchsadresse verwendete andere Zufallsnummer erzeugt, gespeichert und gesendet wird,
daß die Versuchsadresse als endgültige Adresse gespeichert wird, wenn innerhalb einer vorgegebenen Zeit, der maximalen Zwischenrahmen-Zeit, nach dem Senden des Abfrage-Datenrahmens kein Bestätigungs-Datenrahmen empfangen worden ist, und
daß ein Synchronisationsimpuls mit nachfolgender Pause (idle period) vor Senden der Datenrahmen, insbesondere des Ab frage-Datenrahmens, erzeugt und auf das Datenübertragungsmedium gesendet wird, wobei die anderen Teilnehmer bei Empfang des Synchronisationsimpulses mit nachfolgender Pause auf Empfang gestellt werden.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß
eine Zufallsnummer im Bereich von 1 bis 256 verwendet wird.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet,
daß die dem Synchronisationsimpuls folgende Pause wenigstens
zwei und höchstens 10 Bitzeiten lang ist.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch ge
kennzeichnet, daß die maximale Zwischenrahmen-Zeit 200 µs ist.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch ge
kennzeichnet, daß Signale über das Datenübertragungsmedium unter
Verwendung einer FM-0-Codierung gesendet werden.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US06/715,066 US4689786A (en) | 1985-03-21 | 1985-03-21 | Local area network with self assigned address method |
Publications (2)
Publication Number | Publication Date |
---|---|
DE3608126A1 DE3608126A1 (de) | 1986-09-25 |
DE3608126C2 true DE3608126C2 (de) | 1991-11-14 |
Family
ID=24872538
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19863608126 Granted DE3608126A1 (de) | 1985-03-21 | 1986-03-12 | Einrichtung und verfahren zum zuordnen einer speziellen adresse zu einem mit einem datenuebertragungsmedium gekoppelten datenverarbeitungsgeraet |
Country Status (9)
Country | Link |
---|---|
US (1) | US4689786A (de) |
JP (1) | JPS61287354A (de) |
AU (1) | AU574891B2 (de) |
CA (1) | CA1244959A (de) |
DE (1) | DE3608126A1 (de) |
FR (1) | FR2579342A1 (de) |
GB (1) | GB2172779B (de) |
HK (1) | HK36490A (de) |
SG (1) | SG63489G (de) |
Families Citing this family (128)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4845609A (en) * | 1986-07-25 | 1989-07-04 | Systech Corporation | Computer communications subsystem using an embedded token-passing network |
AU7914387A (en) * | 1986-08-22 | 1988-03-08 | Farallon Computing, Inc. | Local area network interconnecting computer products via long telephone lines |
US4901342A (en) * | 1986-08-22 | 1990-02-13 | Jones Reese M | Local area network connecting computer products via long telephone lines |
DE3683778D1 (de) * | 1986-10-30 | 1992-03-12 | Ibm | Datenverarbeitungsanordnung mit vorrichtungen zur automatischen adresszuordnung zur adressierung von schnittstellenmodulen. |
US4815105A (en) * | 1987-04-07 | 1989-03-21 | Paradyne Corporation | Selective signalling encoder/decoder for multipoint data communication networks |
US4933936A (en) * | 1987-08-17 | 1990-06-12 | The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration | Distributed computing system with dual independent communications paths between computers and employing split tokens |
US4787083A (en) * | 1987-09-30 | 1988-11-22 | Nitsuko Limited | Bus-method communication network system capable of seizing transmission right by using timer means at each station |
US4964038A (en) * | 1987-10-28 | 1990-10-16 | International Business Machines Corp. | Data processing system having automatic address allocation arrangements for addressing interface cards |
US4941143A (en) * | 1987-11-10 | 1990-07-10 | Echelon Systems Corp. | Protocol for network having a plurality of intelligent cells |
JPH01185044A (ja) * | 1988-01-19 | 1989-07-24 | Mitsubishi Electric Corp | 端末識別子管理回路 |
JPH01288035A (ja) * | 1988-05-13 | 1989-11-20 | Matsushita Electric Ind Co Ltd | 端末制御装置 |
US4947317A (en) * | 1988-10-12 | 1990-08-07 | Pitney Bowes Inc. | Communication protocol for a three nodes system having dedicated connections and bit indicating function of exchanged message |
US5054019A (en) * | 1989-01-13 | 1991-10-01 | International Business Machines Corporation | Transfer direction turnaround in network data communications |
US4949337A (en) * | 1989-01-30 | 1990-08-14 | Honeywell Inc. | Token passing communication network including a node which maintains and transmits a list specifying the order in which the token is passed |
US5195183A (en) * | 1989-01-31 | 1993-03-16 | Norand Corporation | Data communication system with communicating and recharging docking apparatus for hand-held data terminal |
US4984233A (en) * | 1989-02-15 | 1991-01-08 | Hitachi, Ltd. | Method and apparatus for testing station address in network |
US7537167B1 (en) * | 1993-08-31 | 2009-05-26 | Broadcom Corporation | Modular, portable data processing terminal for use in a radio frequency communication network |
US5428636A (en) * | 1993-05-03 | 1995-06-27 | Norand Corporation | Radio frequency local area network |
US5528621A (en) * | 1989-06-29 | 1996-06-18 | Symbol Technologies, Inc. | Packet data communication system |
US5157687A (en) * | 1989-06-29 | 1992-10-20 | Symbol Technologies, Inc. | Packet data communication network |
US5142550A (en) * | 1989-06-29 | 1992-08-25 | Symbol Technologies, Inc. | Packet data communication system |
US5029183A (en) * | 1989-06-29 | 1991-07-02 | Symbol Technologies, Inc. | Packet data communication network |
US5280498A (en) * | 1989-06-29 | 1994-01-18 | Symbol Technologies, Inc. | Packet data communication system |
CA1338639C (en) * | 1989-09-26 | 1996-10-08 | Seiichi Kubo | Communication control device |
AU6519890A (en) * | 1989-09-29 | 1991-04-28 | Peerlogic, Inc. | Pipes logical network |
US5293493A (en) * | 1989-10-27 | 1994-03-08 | International Business Machines Corporation | Preemption control for central processor with cache |
US7383038B2 (en) * | 1990-01-18 | 2008-06-03 | Broadcom Corporation | Modular, portable data processing terminal for use in a radio frequency communication network |
DE4012544C2 (de) * | 1990-04-19 | 1999-04-15 | Siemens Ag | Verfahren zur Erkennung einer Mehrfachvergabe identischer Teilnehmeradressen in einem Datenübertragungssystem |
CA2047321C (en) * | 1990-07-19 | 1997-11-18 | Henry Yang | Testing a communications network for duplicate station addresses |
US5166931A (en) * | 1990-09-04 | 1992-11-24 | At&T Bell Laboratories | Communications network dynamic addressing arrangement |
US5351041A (en) * | 1990-10-25 | 1994-09-27 | Pioneer Electronic Corporation | Method of data communication in communication network on automobile |
US5393965A (en) * | 1990-11-13 | 1995-02-28 | Symbol Technologies, Inc. | Flexible merchandise checkout and inventory management system |
GB2251532B (en) * | 1990-11-16 | 1995-05-03 | Toshiba Kk | Method of allocating identifiers and apparatus for the same |
US5401944A (en) * | 1990-11-20 | 1995-03-28 | Symbol Technologies, Inc. | Traveler security and luggage control system |
CA2055991C (en) * | 1991-01-02 | 1997-04-22 | John Harris Blevin | Address management for remote terminals in digital loop transmission systems |
FI87290C (fi) * | 1991-01-17 | 1992-12-10 | Kone Oy | Foerfarande foer bestaemning av meddelandeidentifierare i ett foer hissar avsett datanaet |
FR2671884A1 (fr) * | 1991-01-17 | 1992-07-24 | Moulinex Sa | Procede d'attribution d'adresses dans un reseau domotique. |
US5276442A (en) * | 1991-02-22 | 1994-01-04 | Ericsson Ge Mobile Communications Inc. | Dynamic address allocation within RF trunking multisite switch |
US5317693A (en) * | 1991-04-04 | 1994-05-31 | Digital Equipment Corporation | Computer peripheral device network with peripheral address resetting capabilities |
US6374311B1 (en) | 1991-10-01 | 2002-04-16 | Intermec Ip Corp. | Communication network having a plurality of bridging nodes which transmit a beacon to terminal nodes in power saving state that it has messages awaiting delivery |
US6714559B1 (en) * | 1991-12-04 | 2004-03-30 | Broadcom Corporation | Redundant radio frequency network having a roaming terminal communication protocol |
US5940771A (en) * | 1991-05-13 | 1999-08-17 | Norand Corporation | Network supporting roaming, sleeping terminals |
US5394436A (en) * | 1991-10-01 | 1995-02-28 | Norand Corporation | Radio frequency local area network |
JPH04372037A (ja) * | 1991-06-21 | 1992-12-25 | Matsushita Electric Ind Co Ltd | システム管理情報設定装置 |
US5467266A (en) * | 1991-09-03 | 1995-11-14 | Lutron Electronics Co., Inc. | Motor-operated window cover |
US6400702B1 (en) * | 1991-10-01 | 2002-06-04 | Intermec Ip Corp. | Radio frequency local area network |
US6084867A (en) * | 1991-10-01 | 2000-07-04 | Intermec Ip Corp. | Apparatus and method of routing data in a radio frequency local area network |
US5504746A (en) * | 1991-10-01 | 1996-04-02 | Norand Corporation | Radio frequency local area network |
US6407991B1 (en) * | 1993-05-06 | 2002-06-18 | Intermec Ip Corp. | Communication network providing wireless and hard-wired dynamic routing |
US5974236A (en) * | 1992-03-25 | 1999-10-26 | Aes Corporation | Dynamically reconfigurable communications network and method |
CA2091851A1 (en) * | 1992-03-25 | 1993-09-26 | Michael J. Sherman | Link layered communications network and method |
US5305320A (en) * | 1992-10-06 | 1994-04-19 | At&T Bell Laboratories | Peripheral communications network |
US5373288A (en) * | 1992-10-23 | 1994-12-13 | At&T Corp. | Initializing terminals in a signal distribution system |
US5329619A (en) * | 1992-10-30 | 1994-07-12 | Software Ag | Cooperative processing interface and communication broker for heterogeneous computing environments |
USRE39116E1 (en) | 1992-11-02 | 2006-06-06 | Negotiated Data Solutions Llc | Network link detection and generation |
EP0596648A1 (de) | 1992-11-02 | 1994-05-11 | National Semiconductor Corporation | Erkennung du Fähigkeiten eines Netzendpunkts |
USRE39395E1 (en) | 1992-11-02 | 2006-11-14 | Negotiated Data Solutions Llc | Data communication network with transfer port, cascade port and/or frame synchronizing signal |
US5331634A (en) * | 1993-01-29 | 1994-07-19 | Digital Ocean, Inc. | Technique for bridging local area networks having non-unique node addresses |
DE4308568A1 (de) * | 1993-03-18 | 1994-09-22 | Telefunken Microelectron | Verfahren zum Betreiben einer Datenverarbeitungsanlage |
US5634074A (en) * | 1993-05-07 | 1997-05-27 | Apple Computer, Inc. | Serial I/O device identifies itself to a computer through a serial interface during power on reset then it is being configured by the computer |
JP2750315B2 (ja) * | 1993-05-14 | 1998-05-13 | インターナショナル・ビジネス・マシーンズ・コーポレイション | 識別子の指定方法およびコンピュータ・システム |
WO1995001025A1 (en) * | 1993-06-25 | 1995-01-05 | D2B Systems Company Limited | New d2b device address initialisation by use of default address |
US7853254B2 (en) * | 1993-08-31 | 2010-12-14 | Broadcom Corp. | Modular, portable data processing terminal for use in a radio frequency communication network |
US5530897A (en) * | 1993-10-01 | 1996-06-25 | International Business Machines Corporation | System for dynamic association of a variable number of device addresses with input/output devices to allow increased concurrent requests for access to the input/output devices |
JP3041200B2 (ja) * | 1994-07-21 | 2000-05-15 | シャープ株式会社 | データ通信装置およびその方法 |
JP3454931B2 (ja) * | 1994-08-30 | 2003-10-06 | 株式会社東芝 | ネットワークシステム |
US5715174A (en) * | 1994-11-15 | 1998-02-03 | Absolute Software Corporation | Security apparatus and method |
US7702540B1 (en) | 1995-04-26 | 2010-04-20 | Ebay Inc. | Computer-implement method and system for conducting auctions on the internet |
US7937312B1 (en) | 1995-04-26 | 2011-05-03 | Ebay Inc. | Facilitating electronic commerce transactions through binding offers |
DE29508882U1 (de) * | 1995-05-30 | 1996-01-25 | Popp & Co Gmbh | Adressierbarer Knoten |
GB9515741D0 (en) * | 1995-08-01 | 1995-10-04 | Plessey Semiconductors Ltd | Data transmission systems |
US5889962A (en) * | 1995-10-13 | 1999-03-30 | Apple Computer, Inc. | Method and system for providing an additional identifier for sessions in a file server |
US6098116A (en) * | 1996-04-12 | 2000-08-01 | Fisher-Rosemont Systems, Inc. | Process control system including a method and apparatus for automatically sensing the connection of devices to a network |
US5828851A (en) | 1996-04-12 | 1998-10-27 | Fisher-Rosemount Systems, Inc. | Process control system using standard protocol control of standard devices and nonstandard devices |
US5909368A (en) * | 1996-04-12 | 1999-06-01 | Fisher-Rosemount Systems, Inc. | Process control system using a process control strategy distributed among multiple control elements |
JP3359496B2 (ja) * | 1996-06-14 | 2002-12-24 | 沖電気工業株式会社 | 伝送装置識別番号付与方法、伝送装置及び伝送システム管理装置 |
US5708655A (en) * | 1996-06-14 | 1998-01-13 | Telefonaktiebolaget L M Ericsson Publ | Method and apparatus for addressing a wireless communication station with a dynamically-assigned address |
US5844905A (en) * | 1996-07-09 | 1998-12-01 | International Business Machines Corporation | Extensions to distributed MAC protocols with collision avoidance using RTS/CTS exchange |
US5724510A (en) * | 1996-09-06 | 1998-03-03 | Fluke Corporation | Method of configuring a valid IP address and detecting duplicate IP addresses in a local area network |
US5980078A (en) | 1997-02-14 | 1999-11-09 | Fisher-Rosemount Systems, Inc. | Process control system including automatic sensing and automatic configuration of devices |
US6111890A (en) * | 1997-03-25 | 2000-08-29 | Level One Communications, Inc. | Gigabuffer lite repeater scheme |
US5964815A (en) * | 1997-10-21 | 1999-10-12 | Trw Inc. | Occupant restraint system having serially connected devices, a method for providing the restraint system and a method for using the restraint system |
US6321374B1 (en) | 1997-11-07 | 2001-11-20 | International Business Machines Corporation | Application-independent generator to generate a database transaction manager in heterogeneous information systems |
US6061739A (en) * | 1997-11-26 | 2000-05-09 | International Business Machines Corp. | Network address assignment using physical address resolution protocols |
US6553437B1 (en) * | 1998-06-15 | 2003-04-22 | Texas Instruments Incorporated | Addressing and communication for multiple-chip optical sensor arrays |
US6532217B1 (en) * | 1998-06-29 | 2003-03-11 | Ip Dynamics, Inc. | System for automatically determining a network address |
GB2341057A (en) * | 1998-08-28 | 2000-03-01 | Ibm | Allocating names to network resources for shared access |
US6408334B1 (en) | 1999-01-13 | 2002-06-18 | Dell Usa, L.P. | Communications system for multiple computer system management circuits |
US6169759B1 (en) | 1999-03-22 | 2001-01-02 | Golden Bridge Technology | Common packet channel |
US6606341B1 (en) | 1999-03-22 | 2003-08-12 | Golden Bridge Technology, Inc. | Common packet channel with firm handoff |
US6574267B1 (en) * | 1999-03-22 | 2003-06-03 | Golden Bridge Technology, Inc. | Rach ramp-up acknowledgement |
GB2350032B (en) * | 1999-05-12 | 2001-04-11 | 3Com Corp | Method and apparatus for configuration of stackable units in packet-based communication systems |
US6320501B1 (en) | 1999-05-25 | 2001-11-20 | Pittway Corporation | Multiple sensor system for alarm determination with device-to-device communications |
US6711629B1 (en) | 1999-10-18 | 2004-03-23 | Fisher-Rosemount Systems, Inc. | Transparent support of remote I/O in a process control system |
ES2156766B1 (es) * | 1999-11-16 | 2001-11-16 | Iglesias Angel Sa | Sistema de autodireccionamiento para dispositivos conectados en bus. |
DE19961644A1 (de) * | 1999-12-21 | 2001-06-28 | Grundig Ag | Verfahren und System zur Steuerung und zum Austausch von Daten für multimediale Geräte sowie dafür geeignetes Gerät |
NL1016338C2 (nl) * | 2000-10-05 | 2002-04-11 | Roelof Reinders | Werkwijze voor het toekennen van een identificatiecode aan knooppunten in een netwerk, het communiceren in een netwerk, alsmede het aansturen van een netwerk. |
AU8932601A (en) * | 2000-11-28 | 2002-05-30 | Eaton Corporation | Motor vehicle communication protocol with automatic device address assignment |
FR2833126B1 (fr) * | 2001-12-05 | 2007-01-12 | Somfy | Constitution de reseau domotique |
KR100529876B1 (ko) * | 2002-10-10 | 2005-11-22 | 엘지전자 주식회사 | 홈 네트워크 시스템의 동작방법 |
US8601606B2 (en) | 2002-11-25 | 2013-12-03 | Carolyn W. Hafeman | Computer recovery or return |
US11294618B2 (en) | 2003-07-28 | 2022-04-05 | Sonos, Inc. | Media player system |
US8290603B1 (en) | 2004-06-05 | 2012-10-16 | Sonos, Inc. | User interfaces for controlling and manipulating groupings in a multi-zone media system |
US11106424B2 (en) | 2003-07-28 | 2021-08-31 | Sonos, Inc. | Synchronizing operations among a plurality of independently clocked digital data processing devices |
US8234395B2 (en) | 2003-07-28 | 2012-07-31 | Sonos, Inc. | System and method for synchronizing operations among a plurality of independently clocked digital data processing devices |
US11650784B2 (en) | 2003-07-28 | 2023-05-16 | Sonos, Inc. | Adjusting volume levels |
US11106425B2 (en) | 2003-07-28 | 2021-08-31 | Sonos, Inc. | Synchronizing operations among a plurality of independently clocked digital data processing devices |
US7107442B2 (en) * | 2003-08-20 | 2006-09-12 | Apple Computer, Inc. | Method and apparatus for implementing a sleep proxy for services on a network |
US8949304B2 (en) | 2003-08-20 | 2015-02-03 | Apple Inc. | Method and apparatus for accelerating the expiration of resource records in a local cache |
US7551739B2 (en) | 2003-11-13 | 2009-06-23 | Digital Authentication Technologies, Inc. | System and method for container monitoring, real time authentication, anomaly detection, and alerts |
KR20070001120A (ko) * | 2004-02-05 | 2007-01-03 | 코닌클리케 필립스 일렉트로닉스 엔.브이. | 802.3af를 통한 동기화 방법 및 장치 |
US9977561B2 (en) | 2004-04-01 | 2018-05-22 | Sonos, Inc. | Systems, methods, apparatus, and articles of manufacture to provide guest access |
US8326951B1 (en) | 2004-06-05 | 2012-12-04 | Sonos, Inc. | Establishing a secure wireless network with minimum human intervention |
US8868698B2 (en) | 2004-06-05 | 2014-10-21 | Sonos, Inc. | Establishing a secure wireless network with minimum human intervention |
TWI255404B (en) * | 2004-12-03 | 2006-05-21 | Hon Hai Prec Ind Co Ltd | System and method for dynamically allocating addresses to devices connected to an integrated circuit bus |
US9547780B2 (en) * | 2005-03-28 | 2017-01-17 | Absolute Software Corporation | Method for determining identification of an electronic device |
US8788080B1 (en) | 2006-09-12 | 2014-07-22 | Sonos, Inc. | Multi-channel pairing in a media system |
US8483853B1 (en) | 2006-09-12 | 2013-07-09 | Sonos, Inc. | Controlling and manipulating groupings in a multi-zone media system |
US9202509B2 (en) | 2006-09-12 | 2015-12-01 | Sonos, Inc. | Controlling and grouping in a multi-zone media system |
US8112358B2 (en) | 2007-06-04 | 2012-02-07 | Qualcomm Atheros, Inc. | Authorizing customer premise equipment on a sub-network |
JP2011524724A (ja) | 2008-06-16 | 2011-09-01 | ダブリュ. ヤング、ローレンス | 共用媒体上のシグナリングプロトコル間での共存の管理 |
US8301687B2 (en) * | 2009-03-31 | 2012-10-30 | Software Ag | Systems and/or methods for standards-based messaging |
US20110166968A1 (en) * | 2010-01-06 | 2011-07-07 | Richard Yin-Ching Houng | System and method for activating display device feature |
US11429343B2 (en) | 2011-01-25 | 2022-08-30 | Sonos, Inc. | Stereo playback configuration and control |
US11265652B2 (en) | 2011-01-25 | 2022-03-01 | Sonos, Inc. | Playback device pairing |
US10248376B2 (en) | 2015-06-11 | 2019-04-02 | Sonos, Inc. | Multiple groupings in a playback system |
US10712997B2 (en) | 2016-10-17 | 2020-07-14 | Sonos, Inc. | Room association based on name |
CN113612868B (zh) * | 2021-08-06 | 2023-08-29 | 深圳市欧瑞博科技股份有限公司 | 设备地址分配方法、装置以及系统 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3787627A (en) * | 1971-12-15 | 1974-01-22 | Adaptive Tech | Central address distributor |
US4063220A (en) * | 1975-03-31 | 1977-12-13 | Xerox Corporation | Multipoint data communication system with collision detection |
US4430651A (en) * | 1981-08-27 | 1984-02-07 | Burroughs Corporation | Expandable and contractible local area network system |
US4602366A (en) * | 1983-07-18 | 1986-07-22 | Nec Corporation | Systems for changing addresses of transmission apparatus |
DE3478656D1 (en) * | 1983-07-21 | 1989-07-13 | Hitachi Ltd | Structure detecting method for circular type transmission system |
US4626846A (en) * | 1984-05-22 | 1986-12-02 | Northern Telecom Limited | Bus arrangement for addressing equipment units and a method therefor |
-
1985
- 1985-03-21 US US06/715,066 patent/US4689786A/en not_active Expired - Lifetime
-
1986
- 1986-02-05 GB GB08602809A patent/GB2172779B/en not_active Expired
- 1986-02-10 AU AU53345/86A patent/AU574891B2/en not_active Expired
- 1986-03-11 CA CA000503767A patent/CA1244959A/en not_active Expired
- 1986-03-12 DE DE19863608126 patent/DE3608126A1/de active Granted
- 1986-03-19 FR FR8603930A patent/FR2579342A1/fr active Granted
- 1986-03-20 JP JP61063883A patent/JPS61287354A/ja active Pending
-
1989
- 1989-09-12 SG SG634/89A patent/SG63489G/en unknown
-
1990
- 1990-05-10 HK HK364/90A patent/HK36490A/xx not_active IP Right Cessation
Also Published As
Publication number | Publication date |
---|---|
CA1244959A (en) | 1988-11-15 |
FR2579342B1 (de) | 1994-04-22 |
GB2172779B (en) | 1988-12-14 |
FR2579342A1 (fr) | 1986-09-26 |
DE3608126A1 (de) | 1986-09-25 |
AU5334586A (en) | 1986-09-25 |
SG63489G (en) | 1990-03-09 |
JPS61287354A (ja) | 1986-12-17 |
GB2172779A (en) | 1986-09-24 |
HK36490A (en) | 1990-05-18 |
AU574891B2 (en) | 1988-07-14 |
US4689786A (en) | 1987-08-25 |
GB8602809D0 (en) | 1986-03-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE3608126C2 (de) | ||
DE3608173C2 (de) | Datenübertragungssystem und Verfahren zur Datenübertragung zwischen mehreren Datenverarbeitungsgeräten | |
DE2801608C3 (de) | Verfahren zur Bestätigung des Zustandegekommenseins einer zulässigen Datenübertragungs-Verbindung | |
DE69633894T2 (de) | Modem zur Kommunikation von Hochgeschwindigkeitsdaten | |
EP2622826B1 (de) | Verfahren zur automatischen adressvergabe an gleichartige busteilnehmer | |
DE3115455C2 (de) | ||
DE69433098T2 (de) | Vorrichtung zur Übertragung von Daten | |
DE2913288A1 (de) | Multiprozessorsystem | |
DE3814355A1 (de) | Nachrichtenuebertragungssystem | |
DE4308568A1 (de) | Verfahren zum Betreiben einer Datenverarbeitungsanlage | |
EP0035731A2 (de) | Verfahren und Anordnung zum Übertragen von Datensignalen | |
DE10246793B4 (de) | Übertragungssteuervorrichtung, welche ein CAN-Protokoll verwendet | |
EP0443003B1 (de) | Kanalzugriffsverfahren für ein als bus-system konfiguriertes lokales übertragungsnetz | |
DE69737017T2 (de) | Verwendung von Energiebursts in schnurlosen Netzwerken | |
EP0610202B1 (de) | Verfahren zur informationsübertragung in einem mehrere teilnehmer aufweisenden bussystem | |
DE2339392C3 (de) | Verfahren zum Aufrufen von Außenstationen durch eine Zentralstation und SHALTUNGSANORDNUNG ZUR Durchführung dieses Verfahrens | |
DE10127417A1 (de) | Transport-Protokoll für die Gerätekommunikation | |
DE10296916B4 (de) | Kommunikationsvorrichtung und Verfahren zum Unterstützen von Vielfachzugriff mit Leitungsüberwachung/Kollisionserfassung | |
DE102004062683A1 (de) | Verfahren zur Regelung einer Übertragung mit kurzen Datentelegrammen | |
DE102019125545B3 (de) | Datenübertragungsverfahren, segment-telegramm und automatisierungskommunikationsnetzwerk | |
EP1413114A1 (de) | Verfahren zur unterstützung mehrerer prüfsummenalgorithmen in einem netzknoten | |
DE102019213322A1 (de) | Ethernet Physical Layer Transceiver für Zweidraht-Bustopologie | |
EP0183998A2 (de) | Nachrichtenkollisionserkennung | |
DE2945710C2 (de) | Schaltungsanordnung zum Austausch von Informationen zwischen Steuereinrichtungen von Fernmelde-, insbesondere Fernsprechvermittlungsanlagen | |
WO2010000805A1 (de) | Verfahren und system zur seriellen übertragung von daten |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8110 | Request for examination paragraph 44 | ||
D2 | Grant after examination | ||
8364 | No opposition during term of opposition |