DE69923981T2 - Verfahren und Anordnung in einem Telekommunikationsnetz - Google Patents

Verfahren und Anordnung in einem Telekommunikationsnetz Download PDF

Info

Publication number
DE69923981T2
DE69923981T2 DE69923981T DE69923981T DE69923981T2 DE 69923981 T2 DE69923981 T2 DE 69923981T2 DE 69923981 T DE69923981 T DE 69923981T DE 69923981 T DE69923981 T DE 69923981T DE 69923981 T2 DE69923981 T2 DE 69923981T2
Authority
DE
Germany
Prior art keywords
node
information
nodes
piconet
unit
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 - Fee Related
Application number
DE69923981T
Other languages
English (en)
Other versions
DE69923981D1 (de
Inventor
Johan Rune
Tony Larsson
Per Johansson
Christian Gehrmann
Johan Sorensen
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of DE69923981D1 publication Critical patent/DE69923981D1/de
Application granted granted Critical
Publication of DE69923981T2 publication Critical patent/DE69923981T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks
    • 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
    • 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
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/02—Inter-networking arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)
  • Exchange Systems With Centralized Control (AREA)
  • Vending Machines For Individual Products (AREA)
  • Electrotherapy Devices (AREA)
  • Transition And Organic Metals Composition Catalysts For Addition Polymerization (AREA)

Description

  • Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft ein Verfahren und eine Anordnung in einem ein Netz von mehreren Knoten bildenden Digitalkommunikationssystem. Speziell betrifft die vorliegende Erfindung ein Verfahren und eine Anordnung zum Vorsehen von Verteilung innerhalb eines Pikonetzes unter Verwendung von Kurzbereichs-Funktechnologie.
  • Beschreibung der betroffenen Technik
  • Bluetooth-Schnittstellen sind ein Beispiel einer Kurzbereichs-Schnittstelle, welche ursprünglich als Ersatz von Zwischenkabeln in elektrischen Einrichtungen gedacht war. Der Begriff Bluetooth wird in dieser Offenbarung verwendet als ein Beispiel der Verwendung von Kurzbereichs-Funkkommunikation. Drucker, Digitalkameras, Telefone, Laptop-Computer, Videomonitore, elektronische Kalender (PDA), Tischrechner, Faxgeräte, Tastaturen, Joysticks sowie gewöhnliche Computer und praktisch irgendeine andere digitale Einrichtung können Teil eines solchen Kurzbereich-Funksystems sein, d.h. irgendwelche dieser Einrichtungen könnten einen Bluetooth-Funkchip haben und die dazu erforderliche Software. Aber über das Loslösen von Einrichtungen durch das Ersetzen von Kabeln hinaus kann Kurzbereichs-Funkkommunikation eine universelle Brücke zu existierenden Datennetzen als eine Peripherieschnittstelle bilden. Es kann auch zum Bilden von kleinen privaten Ad-hoc-Gruppierungen von untereinander verbundenen Einrichtungen verwendet werden, getrennt von festen Netzinfrastrukturen oder verbunden mit einer festen Netzinfrastruktur über ein Gateway. Das Bluetooth-Funkkommunikationssystem ist entworfen worden zum Arbeiten in einer verrauschten Funkfrequenz-Umgebung und verwendet demnach ein schnelles Bestätigungs- und Frequenzhüpf-Schema (fast acknowledgement and frequency hopping scheme), um Verbindungen zwischen den Einheiten in dem System robust zu machen. Demnach vermeiden Bluetooth-Funkmodule Interferenz von anderen Signalen durch Hüpfen zu einer neuen Frequenz nach dem Senden oder Empfangen eines Datenpaketes, wie in 5 erläutert. Verglichen mit anderen, in demselben Frequenzband arbeitenden Systemen hüpft das Bluetooth-Funkkommunikationssystem üblicherweise schneller und verwendet kürzere Datenpakete. Dies macht das Bluetooth-Funkkommunikationssystem robuster als andere Systeme. Die Verwendung von Vorwärtsfehlerkorrektur (FEC) begrenzt den Einfluss von Zufallsrauschen auf Langstreckenverbindungen zwischen Einheiten in dem System.
  • Ein Bluetooth-Funkkommunikationssystem verwendet ein Frequenzhüpf- bzw. Hopping-Schema innerhalb des unlizensierten ISM-Bandes (Industrial, Scientific, Medical bzw. industriell, wissenschaftlich, medizinisch) bei 2,4 GHz. In den Einheiten wird ein Frequenzhüpf-Sendeempfänger zum Reduzieren des Einflusses von Interferenz und von Fading verwendet. Ein geformtes Binär-FM-Modulationsschema wird zum Minimieren der Komplexität des Empfängers verwendet. Die Hauptdatenrate ist 1 Mb/s, und ein TDD-Schema (Time-Division-Duplex) wird verwendet für Vollduplex-Übertragung.
  • Das Bluetooth-Basisbandprotokoll ist eine Kombination aus Schaltungs- und Paketvermittlung, wie in 5 gezeigt. In 5 kennzeichnet s1 einen einzelnen Zeitschlitz, und p1 kennzeichnet ein Paket, dessen Übertragung drei Zeitschlitze erfordert. Die Pakete werden normalerweise unter Verwendung unterschiedlicher Hüpf-Frequenzen übertragen. Ein Paket wird normalerweise in einem einzelnen Schlitz übertragen, aber ein einzelnes Paket kann bis zu fünf Schlitze erfordern. Bluetooth kann einen asynchronen Datenkanal unterstützen, bis zu drei synchrone Sprachkanäle oder einen Kanal, der simultan asynchrone Daten und synchrone Sprache unterstützt. Jeder Sprachkanal unterstützt eine 64 kb/s-Synchronverbindung (Sprachverbindung). Der Asynchronkanal kann eine asymmetrische Verbindung von maximal 721 kb/s in einer der Richtungen unterstützen, während er 57,6 kb/s in der Rückwärtsrichtung zulässt, oder eine symmetrische 462,6 kb/s-Verbindung.
  • In 2 sind Funktionsblöcke einer Einheit mit einem Kurzbereichs-Funksenderempfänger, wie zum Beispiel Bluetooth, gezeigt. Eine Funkeinheit 300, die mit einer Antenne versehen ist, ist mit einer Verbindungssteuereinheit 310 verbunden, die das Basisband bereitstellt. Die Verbindungssteuereinheit 310 ist mit der zentralen Verarbeitungseinheit 320 verbunden, die CPU genannt wird und das Verbindungsmanagement bereitstellt. Die CPU ist mit einem Speicher 360 verbunden, der die Software speichert und aus zwei Speichereinheiten besteht: einem SRAM 330 und einem Flash-Speicher 340. Die CPU 320 ist mit einer Host-Schnittstelle 350 verbunden. Ein SRAM ist ein schneller temporärer Speicher. Ein Flash-Speicher ist ein programmierbares ROM.
  • 8 zeigt zwei Pikonetze A1 und B1 in einem Streunetz. Das Pikonetz A1 umfasst vier Einheiten 10, 20, 30, 40; und das Pikonetz B1 umfasst drei Einheiten 40, 50 und 60. In dem Pikonetz A1 ist die Einheit 10 eine Haupteinheit (Master). Die Einheit 40 ist ein Mitglied sowohl des Pikonetzes A1 als auch des Pikonetzes B1. Zwei oder mehr Bluetooth-Einheiten (BT), die Bluetooth zur Kommunikation miteinander verwenden und denselben Kanal teilen (d.h. dieselbe Frequenz-Hüpfabfolge und Zeitschlitzsynchronisation), bilden ein Pikonetz, d.h. ein Pikonetz ist eine Ansammlung von untereinander unter Verwendung von Bluetooth in ad-hoc-Weise verbundenen Einheiten. Innerhalb eines Pikonetzes kann eine Bluetooth-Einheit eine von zwei Rollen innehaben, sie kann ein Master sein oder ein Slave. Innerhalb jedes Pikonetzes gibt es nur einen Master, und bis zu sieben aktive Slaves können verbunden sein, d.h. ein Pikonetz beginnt mit zwei miteinander verbundenen Einheiten, wie zum Beispiel einem tragbaren PC und einem Mobilfunktelefon, und es kann anwachsen auf acht miteinander verbundene Einheiten. Alle Bluetooth-Einheiten sind Peer-Einheiten (gleichrangige Einheiten) und haben im Grunde identische Implementierungen. Jede BT-Einheit kann Master in einem Pikonetz werden. Jedoch, wenn ein Pikonetz gebildet wird, wird eine Einheit die Rolle des Masters übernehmen und die andere bzw. anderen werden Slave für die Dauer des Pikonetzes. Ein Streunetz oder ein Ad-hoc-Netz ist ein Netz, das mehrere unabhängige und nicht synchronisierte Pikonetze umfasst. Der Master oder die Mastereinheit bzw. Haupteinheit ist die Einheit in einem Pikonetz, deren Takt- und Hüpfabfolge verwendet werden zum Synchronisieren aller anderen Einheiten im Pikonetz. Ein Slave oder eine Sklaveneinheit ist jede Einheit in einem Pikonetz, die nicht der Master in dem Pikonetz ist. Zwei oder mehr Pikonetze können miteinander verbunden sein, ein Streunetz bildend, das bereits definiert worden ist. Der Verbindungspunkt zwischen zwei Pikonetzen besteht aus einer einzelnen BT-Einheit, die ein Mitglied beider Pikonetze ist. Eine BT-Einheit kann simultan ein Slave einer Vielzahl von Pikonetzen sein, aber nur Master in einem Pikonetz. Das heißt, eine BT-Einheit, die als Master in einem Pikonetz funktioniert, arbeitet als ein Slave in einem anderen Pikonetz oder in Pikonetzen. Eine BT-Einheit kann zu einer Zeit nur Daten in einem Pikonetz senden und empfangen, so dass die Teilnehmerschaft in mehreren Pikonetzen auf einer Zeit-Multiplex-Basis stattfinden muss. Das Bluetooth-System unterstützt sowohl Punkt-zu-Punkt als auch Punkt-zu-Mehrpunkt-Verbindungen. Mehrere Pikonetze können miteinander ad hoc verbunden werden, wobei jedes Pikonetz identifiziert wird durch eine abweichende Frequenz-Hüpfabfolge. Alle an einem selben Pikonetz teilhabenden Einheiten werden auf die Hüpfabfolge des Pikonetzes synchronisiert. Die Streunetz-Topologie kann am besten beschrieben werden als eine Vielzahl von Pikonetzstrukturen, siehe 8. Jedoch sind Bluetooth- Einheiten zur Verwendung in Streunetzen nicht kommerziell verfügbar.
  • 3a zeigt einen persönlichen digitalen Assistenten PDA 500 unter Verwendung einer Zusatz-Bluetooth-Kommunikationseinrichtung 510. Die Bluetooth-Kommunikationseinheit 510, die mit einer Antenne versehen ist, wird in einen Schlitz in dem PDA eingefügt. Die Bluetooth-Kommunikationseinheit kann eine PC-Karte sein oder eine "Compakt Flash Card" (kompakte Flash-Speicherkarte), die mit einem Bluetooth-Chipsatz versehen ist.
  • 3b zeigt einen PDA unter Verwendung einer eingebauten Bluetooth-Kommunikationseinrichtung. Hier ist der PDA mit einer Antenne versehen.
  • 3c zeigt ein Mobiltelefon unter Verwendung einer eingebauten Bluetooth-Kommunikationseinrichtung, wobei der Bluetooth-Senderempfänger eine nicht dargestellte Antenne hat, die sich von der des Mobiltelefons unterscheidet.
  • Ein Bluetooth-System stellt, wie bereits gesagt, Vollduplex-Übertragung bereit, aufgebaut auf geschlitztem TDD (Time Division Duplex). Jeder verwendete Schlitz hat eine Länge von 0,625 ms. Die Zeitschlitze sind aufeinanderfolgend unter Verwendung eines sehr großen Zahlenbereiches nummeriert (der Bereich ist zyklisch mit einem Zyklus von 227). Die Übertragung von Master zu Slave beginnt immer in einem gerade nummerierten Zeitschlitz, wohingegen die Übertragung von Slave zu Master immer in einem ungerade nummerierten Zeitschlitz beginnt. Der Begriff "Rahmen" bzw. Frame, wie er hier verwendet wird, ist definiert als die Kombination von einem geradzahlig nummerierten Zeitschlitz und dem darauffolgenden ungeradzahlig nummerierten Zeitschlitz (d.h. einem Master-zu-Slave-Zeitschlitz und einem Slave-zu-Master-Zeitschlitz), mit der Ausnahme, dass Mehrschlitz-Pakete verwendet werden und dann andere Konventionen angewendet werden. In einem Kommunikationssystem mit Bluetooth gibt es keine direkte Übertragung zwischen Slaves in einem Pikonetz.
  • Die Kommunikation zwischen den Einheiten eines Pikonetzes ist derart organisiert, dass der Master jeden Slave in Übereinstimmung mit einem gewissen Polling-Schema bzw. Abfrageschema abfragt bzw. pollt. Mit einer Ausnahme ist es einem Slave nur erlaubt, zu senden, nachdem er von einem Master abgefragt bzw. gepollt worden ist. Der Slave wird dann seine Sendung in dem Slave-zu-Master-Zeitschlitz beginnen, der unmittelbar auf das von dem Master empfangene Paket folgt. Der Master kann oder kann nicht Daten, z.B. Nutzlastdaten, in den Paketen einschließen, die zum Pollen des Slave verwendet werden. Die einzige Ausnahme zu dem obigen Prinzip ist, dass wenn ein Slave eine SCO-Verbindung (Synchronous Connection-Oriented bzw. synchron verbindungsorientiert) zu dem Master eingerichtet hat, es immer zugelassen ist, in einen vorzugeordneten Slave-zu-Master-Schlitz zu übertragen, selbst wenn nicht explizit von dem Master in den direkt vorangegangenen Master-zu-Slave-Schlitz gepollt. SCO-Links unterstützen Echtzeit-Sprachverkehr unter Verwendung von reservierter Bandbreite.
  • Jede BT-Einheit hat eine global einzigartige 48-Bit-Adresse. Diese Adresse, die Bluetooth-Einrichtungsadresse (BD_ADDR), wird zugewiesen, wenn die Bluetooth-Einheit hergestellt wird, und sie wird nie geändert. Zusätzlich hierzu weist der Master eines Pikonetzes eine lokale Aktiv-Mitgliedsadresse (AM_ADDR) für jeden aktiven Slave des Pikonetzes zu. Die AM_ADDR ist nur drei Bit lang und ist einzigartig nur innerhalb eines einzelnen Pikonetzes. Der Master verwendet die AM_ADDR beim Abfragen bzw. Polling eines Slave in einem Pikonetz. Wenn der Slave, getriggert durch ein von dem Master empfangenes Paket und adressiert unter Verwendung des AM_ADDR des Slave, ein Paket zu dem Master sendet, schließt er seine eigene AM_ADDR in dem Kopf des Paketes ein.
  • Das Paket kann sowohl synchrone Daten auf synchronen verbindungsorientierten Verbindungen bzw. SCO-Links als auch asynchrone Daten auf asynchronen verbindungslosen Verbindungen bzw. ACL-Links übertragen. Für einige Arten von verwendeten Paketen wird ein Bestätigungs- und Neusendeschema verwendet zum Sicherstellen des zuverlässigen Transfers von Daten. Solch ein Schema wird nicht verwendet für SOC-Pakete, die Synchrondaten übertragen. Ebenfalls kann Vorwärtsfehlerkorrektur (FEC) in Form von Kanalkodierung verwendet werden.
  • Das Standardformat eines Bluetooth-Basisbandpaketes ist in 1a gezeigt. Es umfasst ein Feld für einen Zugangscode, ein Kopf- bzw. Header-Feld und ein Nutzlast- bzw. Payload-Feld. 1c erläutert das Format des Kopffeldes, welches ein AM_ADDR-Feld umfasst, gefolgt von einem Typen-Feld TYPE, das den Typ des Paketes anzeigt. Das Ablauf-Feld FLOW umfasst ein Bit, das verwendet wird zur Ablaufsteuerung. Die Felder ARQN und SEQN steuern und bestätigen das neue Sendeschema. Das Kopf-Fehlerprüffeld bzw. HEC-Feld (Header Error Check) hat Information für das Überprüfen der Integrität des Kopfes. Beim Empfangen eines Paktes und dem Verwenden der Information in dem HEC-Feld zum Prüfen des Kopffeldes. Das Kopffeld kann fehlerhaft erkannt werden, und dann wird das Paket verworfen. Andernfalls wird das Paket beibehalten und weitere Prüfungen können vorgenommen werden. Das Format der Nutzlast hängt von der Art des übertragenen Paketes ab. Ein SCO-Paket ist ein Paket, das auf einer SCO-Verbindung übertragen wird, und ein ACL-Paket ist ein Paket, das auf einer ACL-Verbindung übertragen wird. Das Nutzlastfeld eines SCO-Paketes umfasst nur ein Datenfeld. Die Payload eines ACL-Paketes, die in 1b gezeigt ist, umfasst ein Kopffeld, ein Datenfeld und ein Feld zum Übertragen von Information für die zyklische Redundanzprüfung bzw. "Cycling Redundancy Check" (CRC). Zusätzlich gibt es Hybrid-Pakete, die zwei Datenfelder einschließen, eines für Synchrondaten und das andere für Asynchrondaten. Hybridpakete werden verwendet, wenn Sprachinformation und Daten über dieselbe Verbindung gesendet werden. Pakete mit einem Nutzlastfeld, die nicht mit einem CRC-Feld versehen sind, werden weder bestätigt noch neu gesendet. Es gibt zwei unterschiedliche Formate des Nutzlast-Kopffeldes. In 1d ist das Format des Nutzlast-Kopffeldes für Einzelschlitzpakete dargestellt. In 1e ist das Format des Nutzlast-Kopffeldes für Mehrschlitz-Pakete dargestellt. L_CH ist ein Zwei-Bit-Feld, das die Art von Nutzlast anzeigt. L_CH=00 bedeutet, dass der "00"-Wert nicht definiert ist und demnach nicht verwendet wird. L_CH=1 zeigt ein Fortsetzungsfragment einer L2CAP-Meldung, wie nachstehend beschrieben. L_CH=1 zeigt den Start einer L2CAP-Meldung ohne Fragmentierung an. Fragmentierung bedeutet, dass das L2CAP zu groß ist, um durch ein einzelnes Basisbandpaket übertragen zu werden, und es demnach aufgespalten worden ist in mehrere Teile, sogenannte Fragmente, wobei jedes Fragment von einem einzelnen Basisbandpaket ausgeführt wird. Bei dem Zielknoten werden die Fragmente neu zusammengestellt in ein komplettes L2CAP-Paket. L_CH=11 gibt eine LMP-Meldung an. Das Feld FLOW wird zur Ablaufsteuerung verwendet. Das FLOW-Bit in dem Kopffeld wird zur Ablaufsteuerung in der L2CAP-Schicht verwendet. FLOW=0 gibt "Senden stoppen" an. FLOW=1 gibt an "bereit zum Senden". Das FLOW-Bit in dem zuletzt korrekt empfangenen Nutzlast-Kopf bestimmt den Ablaufzustand. Das LENGTH-Feld gibt die Länge des Datenfeldes an. Da Mehrschlitz-Pakete ein längeres Datenfeld übertragen können, ist das LENGTH-Feld des Mehrschlitz-Nutzlast-Kopfes (1e) länger (nicht in der Fig. gezeigt) als das LENGTH-Feld des Einzelschlitz-Nutzlast-Kopfes (1d). Wie in 1e gezeigt, sind in dem Nutzlast-Kopffeld eines Mehrschlitzpaketes die vier letzten Bits nicht definiert.
  • In einem Bluetooth-System werden einige Protokollschichten verwendet, die in 4 gezeigt sind und das Basisbandprotokoll bzw. BB-Protokoll zwischen der physikalischen Schicht 103 und der Datenverbindungsschicht (data link layer) 104 umfassen, das Link-Manager-Protokoll (LMP) und das Logical-Link-Control- und Adaption-Layer-Protokoll (L2CAP (Protokoll der logischen Verbindungssteuerung und der Anpassungsschicht)) in der Datenvermittlungsschicht bzw. Data-Link-Layer 104. Eine Höcherschichtenprotokoll- oder Anwendungsschicht (106 (High 1evel protocol or application layer)) kann oder kann nicht vorgesehen sein sowie eine Netzwerkschicht (105). Zusätzlich kann eine nicht gezeigt Netzanpassungsschicht (NAL (Network Adaption Layer)), die sich zwischen der Datenverbindungsschicht (104) und der Netzschicht (105) befindet, vorgesehen sein.
  • Nun wird der Bluetooth-Protokoll-Stack (Protokollstapel) unter Bezugnahme auf 4 beschrieben. In 4 sind zwei Bluetooth-Einheiten dargestellt: eine Einheit Nr. 1, 101, und eine Einheit Nr. 2, 102.
  • Das Basisband- bzw. BB-Protokoll beschreibt die Spezifikationen des Digitalsignalverarbeitungsteils der Hardware – des Bluetooth-Link-Controllers, welche die Basisbandprotokolle übertragen und andere Verbindungsroutinen niederer Schicht. Es verwendet zwei Link-Arten (Schicht-Verbindungstypen): synchronverbindungsorientierte Links (SCO-Links) und asynchronverbindungslose Links (ACL-Links). Das Verbindungs-Management-Protokoll bzw. Link-Management-Protokoll LMP behandelt Meldungen zur Verwendung für das Einrichten von Links, Sicherheit und Steuerung. Das LMP befindet sich oberhalb des Basisbandprotokolls.
  • Das Logical-Link-Steuerungs- und Anpassungsschicht-Protokoll L2CAP befindet sich auch oberhalb des Basisbandprotokolls. L2CAP stellt verbindungsorientierte und verbindungslose Datendienste bereit zu Protokollen oberer Schichten mit Protokoll-Multiplex-Fähigkeit, Segmentierung, Neuzusammenstellungsoperation und Gruppenabstraktionen. Das L2CAP ist nur für ACL-Verbindungen definiert.
  • Wie zuvor dargelegt, wird physikalisches Senden in einem Pikonetz nur exklusiv zwischen dem Master und jedem Slave und umgekehrt zugelassen. Demnach gibt es keine Möglichkeit für einen Slave, Daten zu einem anderen Slave in einem Pikonetz zu senden, da Direktkommunikation nicht zugelassen ist.
  • In einem Bluetooth-System ist keine Art spezifiziert zum Adressieren und Routen von Paketen von einem Pikonetz zu einem anderen. Jedoch kann eine BT-Einheit, die ein Mitglied von mehr als einem Pikonetz ist, verwendet werden zum Weiterleiten von Paketen von einem Pikonetz zu einem anderen. Solch eine PT-Einheit wird hier als Weiterleitungsknoten bezeichnet.
  • Um eine Slave-zu-Slave-Kommunikation in einem Pikonetz und eine Inter-Pikonetz-Kommunikation zu ermöglichen, ist eine wichtige Information ein Slave, der eine Nachricht zu einem anderen Slave in einem Pikonetz senden soll, z.B. die Adresse wie BD_ADDR jedes der anderen Mitglieder des Pikonetzes. Diese Information ist normalerweise nur der Haupteinheit bzw. Master-Einheit in einem Pikonetz bekannt. Ein anderes Beispiel wichtiger Information kann sein, ob eine empfangene BT-Einheit Slave-zu-Slave-Kommunikation unterstützt.
  • Nokia hat der Bluetooth-SIG (Special Interest Group), der Organisation, die den Bluetooth-Standard schreibt, ein neues Verfahren vorgeschlagen, das ein Inter-Pikonetz-Routing in einem Streunetz ermöglicht sowie Intrapikonetz-Routing zwischen Slaves innerhalb desselben Pikonetzes. In dem Vorschlag von Nokia ist ein Virtual-Network-Segment bzw. virtuelles Netzsegment (VNS) eingefügt zwischen der L2CAP- und der Netzschicht 104, siehe 4, um ein geteiltes Mediennetz zu emulieren, d.h. ein Rundsendemedium zu der Netzschicht, d.h. die VNS-Schicht dient demselben Zweck wie die NAL-Schicht. Die VNS-Einheit in einem Weiterleitungsknoten wird sich selbst bei der Master-Einheit durch Senden einer Meldung zu ihrer Peer-Einheit in der Master-Einheit registrieren. Beim Übertragen von Nachrichten verwenden die Slave-Einheiten die Kenntnis des Masters. Wenn eine Slave-Einheit wünscht, eine Meldung zu einem Weiterleitungsknoten zu senden, z.B. eine Anfrage zum Erstellen eines Routings zu einem speziellen Ziel in einem anderen Pikonetz, sendet sie die Meldung zu der Master-Einheit. Die Master-Einheit wird dann die Meldung basierend auf ihrer enthaltenen Information weiterleiten zu dem bzw. den geeigneten Weiterleitungsknoten.
  • Ein anderes sich aus der Bluetooth-Kernspezifikation (Bluetooth Core Specification) 1.0 (d.h. der Spezifikation des Bluetooth-Systems; Core; Spezifikation Volume 1:1, Version 1.0) ergebendes Beispiel betrifft die Kompatibilität zwischen unterschiedlichen BT-Einheiten. Wenn zwei BT-Einheiten über eine direkte drahtlose Verbindung kommunizieren, d.h. keine Slave-zu-Slave-Kommunikation über die Master-Einheit, wird das Kompatibilitätsproblem gelöst durch Austauschen von Merkmalen einschließlich Angaben bzw. Indikation für jedes Merkmal, ob es unterstützt wird oder nicht. Dieser Informationsaustausch wird unter Verwendung der LMP PDU (Protocol Data Unit bzw. Protokolldateinheit), LMP_feature_req und LMP_features_res ausgeführt. Eine Nachricht in dem Link-Manager-Protokoll (LMP) wird "LMP PDU" genannt, PDU steht für "Protocol Data Unit" bzw. Protokolldateneinheit. LMP_features_req und LMP_features_res geben zwei LMP_PDUs in Übereinstimmung mit der Bluetooth-Kernspezifikation 1.0 an. Tatsächlich wird es einer BT-Einheit ermöglicht, bevor dieser Informationsaustausch ausgeführt wird, nur eine kleine Untermenge der Bluetooth-Merkmale zu verwenden, z.B. Paketarten, wenn sie mit den anderen BT-Einheiten kommuniziert. Nachdem der Informationsaustausch stattgefunden hat, kann die Schnittmenge der in beiden BT-Einheiten unterstützten Merkmale verwendet werden. Die unter Verwendung von LMP_features_req und LMP_features_res ausgetauschte Information ist eine Liste von Bluetooth -Merkmalen und ein Bit für jedes Merkmal. Das Bit zeigt an, ob das Merkmal unterstützt wird oder nicht, siehe Seite 235-236 in der Bluetooth Core Specification, Volume 1:1 (Bluetooth-Hauptspezifikation, Band 1:1).
  • Patentdokument WO 99 14897 offenbart ein System und ein Verfahren, durch welches Drahtlosknoten eines Ad-hoc-Netzes ihre eigenen Adressen und Adressen ihrer erreichbaren Nachbarn zu einem Master-Knoten senden.
  • Resümee der Erfindung
  • Die in der vorliegenden Offenbarung definierten Probleme sind folgende:
    • • Der VNS-Ansatz behandelt nur einen kleinen Teil der Gesamtverteilung von Information.
    • • In Bezug auf die LMP-Prozedur zum Austauschen von Listen von unterstützten Merkmalen ist dies beschränkt auf BT-Einheiten, die über eine direkte Verbindung kommunizieren, d.h. eine Master-Einheit und eine mit dieser kommunizierende Slave-Einheit. Die sich ergebenden Kompatibilitätsangelegenheiten, wenn Slave-zu-Slave-Verbindung betrachtet wird, sind nicht behandelt.
    • • Wenn eine Slave-zu-Slave-Verbindung innerhalb eines Pikonetzes eingeführt wird, gibt es ein Problem dahingehend, dass weder AM_ADDR noch BD_ADDR oder eine mögliche IP-Adresse anderer Slave-Einheiten in dem Pikonetz für eine Slave-Einheit in dem Pikonetz verfügbar sind.
  • Da Bluetooth das Hauptziel der Erfindung ist, werden die Verfahren und Anordnungen wie hier offenbart in einem Bluetooth-Zusammenhang unter Verwendung von Bluetooth- Terminologie beschrieben. Der Begriff "Bluetooth" ist die Bezeichnung einer eingetragenen Marke eines Kurzbereich-Funksenderempfängers und des Kommunikationssystems, das einen solchen Senderempfänger verwendet. Ein Fachmann versteht, dass andere Arten von Kurzbereichs-Kommunikation verwendet werden können, z.B. Infrarotlicht, wobei die Einrichtungen in einem solchen System mit Hilfe von Kommunikation durch Infrarotlicht bereitgestellt werden. Weitere Arten von Kurzbereichskommunikation können Ultraschall- oder hydrophonische Kommunikation sein. Ferner kann die Erfindung anwendbar sein auf andere Netztechnologien, sowohl drahtgebundene als auch drahtlose.
  • Demnach wird ein Zielsystem betrachtet, welches ein digitales, drahtgebundenes oder drahtloses Kommunikationssystem ist, das ein Netz von mehreren Knoten bildet. Das Netz umfasst einen Zentralknoten, der auch Master genannt wird, und zwei oder mehr periphere Knoten, die auch Slaves oder Sklaveneinheiten genannt werden. Der Zentralknoten steuert die Gesamtkommunikation im Netz. Auf der niedrigsten Protokollschicht, der physikalischen Schicht, fließt die Gesamtkommunikation exklusiv zwischen dem Zentralknoten und einem peripheren Knoten und umgekehrt. Keine Kommunikation verläuft auf der niedrigsten Protokollschicht direkt zwischen zwei peripheren Knoten. In einem solchen System kann sich auf das System selbst oder auf die Knoten in dem System beziehende Information von dem Zentralknoten oder den peripheren Knoten im Netz verteilt werden oder in einer Datenbank im Zentralknoten gehalten werden, auf welche Datenbank auf Anfrage von den peripheren Knoten im Netz zugegriffen werden kann. Die Information kann von den peripheren Knoten zu dem Zentralknoten entweder auf Befehl des Zentralknotens selbst oder auf Anfrage von einem peripheren Knoten, ausgelöst durch das Intervallereignis im peripheren Knoten, z.B. eine Zustandsänderung mit externen Folgen, vermittelt werden. Die verteilte Information kann umfassen:
    • • Anzahl peripherer Knoten
    • • Adressen peripherer Knoten
    • • IP-Adressen aller Knoten
    • • Zuordnungen zwischen einer IP-Adresse und einer Adresse einer niedrigen Schicht (z.B. MAC-Adresse der Medienzugangssteuerung) für einen peripheren Knoten oder für alle Knoten
    • • Adressen von Weiterleitungsknoten
    • • Unterstützte Merkmale peripherer Knoten
    • • Zustandsänderungen in peripheren Knoten (z.B. wenn ein Knoten Weiterleitungsknoten wird oder dieses aufgibt)
    • • Weiterleitungs-Bitraten-Kapazität von Weiterleitungsknoten
    • • Meldungen, wenn Knoten dem Netz beitreten oder es verlassen
    • • Meldungen, wenn eine Verbindung zu einer festen Infrastruktur verfügbar wird oder die Verfügbarkeit aufgibt
    • • Meldungen anderer Ereignisse
    • • Information in Bezug auf Weiterleitungsvereinbarungen
  • Zudem sollte bemerkt werden, dass die in einem Bluetooth-System zu verwendenden Verfahren nicht beschränkt sind auf die Art von im Zusammenhang mit den Mechanismen erwähnter Information. Jedwede Art von Information, die sich auf das System individueller Knoten bezieht, sollte unter Verwendung irgendeines der beschriebenen Mechanismen gemanagt werden. Solche Information kann die oben aufgelistete Information sein und kann enthalten:
    • • AM_ADDR von Slaves
    • • BD_ADDR von Slaves
    • • IP-Adresse von Slaves
    • • Inter-Pikonetz-Zeitplanungsparameter für Weiterleitungsknoten
  • Demnach, um die oben beschriebenen Probleme auszuräumen und eine allgemein praktikable Lösung bereitzustellen, muss ein Pikonetz einen effizienten Mechanismus einschließen, um die gesamte relevante Information allen Sklaveneinheiten rechtzeitig verfügbar zu machen. Dies kann auf unterschiedliche Arten erreicht werden. Obwohl unterschiedliche Arten von Information in Verbindung mit unterschiedlichen Mechanismen beschrieben werden, könnte die Verteilung aller unterschiedlichen Informationsarten von einem gemeinsamen Protokoll behandelt werden, aber getrennte Protokolle sind ebenfalls möglich. Es ist auch möglich, unterschiedliche Protokolle für dieselbe Information in unterschiedlichen Situationen zu verwenden.
  • Der Zweck der Erfindung ist es, Mechanismen zum effizienten Verteilen von relevanter Information in einem Pikonetz bereitzustellen.
  • In einem System unter Verwendung von Bluetooth-Technologie ist ein Vorteil des hier offenbarten Verfahrens und der Anordnung, dass Slave-zu-Slave-Kommunikation unterstützt wird, da eine Verteilung nützlicher system- oder knotenbezogener Information in einem Pikonetz ermöglicht wird. Wenn Slave-zu-Slave-Kommunikation zugelassen wird, genügt es nicht länger, dass die Master-Einheit über relevante Information in Bezug auf die Slave-Einheiten informiert wird. Nützliche Information kann beispielsweise sein:
    • • Adressinformation in Bezug auf die Mitgliedseinheiten in einem Pikonetz einschließlich Mitteilungen, wenn BT-Einheiten dem Pikonetz beitreten oder es verlassen;
    • • Weiterleitungsknoteninformation, welche auch Inter-Pikonetz-Kommunikation erleichtert;
    • • kompabilitätsbezogene Information;
  • In einem System unter Verwendung von Bluetooth-Technologie ist ein weiterer Vorteil des hier offenbarten Verfahrens und der Anordnung, dass Slave-zu-Slave-LMP-PDU auch Slave-zu-Slave-Kommunikation erleichtert.
  • In einer ein Netz von mehreren Knoten bildenden Mobiltelekommunikation, die einen Zentralknoten und mindestens zwei periphere Knoten einschließt, wobei der Zentralknoten die gesamte Kommunikation im Netz steuert, ist ein Vorteil des hier offenbarten Verfahrens und der Anordnung, dass Kommunikation zwischen peripheren Knoten über den Zentralknoten erleichtert wird, da relevante Information in Bezug auf das System und die individuellen Knoten verteilt werden kann unter den peripheren Knoten. Die Information kann irgendeine der oben aufgelisteten sein.
  • Der Begriff "umfasst bzw. umfassend" wird, wenn er in dieser Beschreibung verwendet wird, verwendet zum Spezifizieren des Vorhandenseins von genannten Merkmalen, Ganzzahlen, Schritten oder Komponenten, aber schließt das Vorhandensein oder das Hinzufügen eines oder mehrerer anderer Merkmale, Ganzzahlen, Schritte, Komponenten oder Gruppen davon nicht aus.
  • Der weitere Umfang der Anwendbarkeit der vorliegenden Erfindung wird ersichtlich werden aus der nachstehend wiedergegebenen detaillierten Beschreibung. Jedoch sollte verstanden werden, dass die detaillierte Beschreibung und die spezifischen Beispiele zwar bevorzugte Ausführungsformen der Erfindung angeben, jedoch nur zum Zwecke der Erläuterung wiedergegeben werden, da verschiedene Änderungen und Modifikationen innerhalb des Schutzbereichs der beiliegenden Ansprüche Fachleuten aus dieser detaillierten Beschreibung ersichtlich werden.
  • Kurzbeschreibung der Zeichnungen
  • Es zeigt:
  • 1a ein Diagramm eines Standard-Basisband-Paketformats;
  • 1b ein Diagramm des Formats eines ACL-Pakets;
  • 1c ein Diagramm eines Basisband-Paketkopfs bzw. Headers;
  • 1d eine Diagramm eines Basisband-Nutzlastkopfs für ein Einzelschlitzpaket;
  • 1e ein Diagramm eines Basisband-Nutzlastkopfs für ein Mehrschlitzpaket;
  • 2 eine schematische Ansicht eines Bluetooth-Senderempfängers;
  • 3a–c schematische Ansichten dreier elektronischer Einrichtungen, die mit einem Bluetooth-Senderempfänger versehen sind;
  • 4 ein Diagramm der Bluetooth-Protokollschichten;
  • 5 ein Diagramm des Zusammenhangs zwischen Zeitschlitzen und Frequenz-Hops bzw. -Hüpfungen in einem Bluetooth verwendenden System;
  • 6 ein Diagramm zum Erläutern eines Weiterleitungs-Szenarios;
  • 7a–7c Diagramme des Basisband-Paketformats;
  • 8 eine schematische Ansicht zweier Pikonetze in einem Streunetz;
  • 9 ein Ablaufdiagramm des Routings eines Paketes;
  • 10 ein Diagramm einer Bluetooth-Einheit;
  • 11 ein Ablaufdiagramm des Prozesses einer ein Weiterleitungsknoten werdenden Bluetooth-Einheit;
  • 12a,b Ablaufdiagramme eines Beispiels eines Prozesses, wenn eine Bluetooth-Einheit ein Weiterleitungsknoten wird;
  • 13a,b Ablaufdiagramme eines anderen Beispiels eines Prozesses, wenn eine Bluetooth-Einheit ein Weiterleitungsknoten wird;
  • 14 ein Ablaufdiagramm des Prozesses eines Weiterleitungsknotens, der es aufgibt, ein Weiterleitungsknoten zu sein, und des Informationsstroms in einem ersten Pikonetz;
  • 15a,b Ablaufdiagramme des Prozesses eines Weiterleitungsknotens, der es aufgibt, Weiterleitungsknoten zu sein, und des Informationsstroms in einem zweiten Pikonetz.
  • Die Erfindung wird nun detaillierter unter Bezugnahme auf bevorzugte beispielhafte Ausführungsformen davon beschrieben und auch unter Bezugnahme auf die beiliegenden Zeichnungen.
  • Detaillierte Beschreibung
  • Der innere logische Aufbau einer Bluetooth-Einheit mit verbesserter Kommunikationsfähigkeit erscheint aus 10. Die Bluetooth-Einheit 1195 umfasst Basis-Bluetooth-Funktionen 1150, Weiterleitungsfunktionen 1160 und eine Datenbank 1180. Der Block Basis-Bluetooth-Funktionen 1150 umfasst die Funktionen, die von einem Senderempfänger durchgeführt werden, eine Taktquelle, einen Speicher, eine Energiequelle, Logikschaltungen zum Implementieren der Bluetooth-Protokollstapel bzw. Protocol Stacks, Logikschaltungen zum Analysieren von Signalisierungsmeldungen und Logikschaltungen zum Erzeugen von Signalisierungsmeldungen, etc. Der Block Weiterleitungsfunktionen 1160 umfasst die von Weiterleitungslogikschaltungen ausgeführten Funktionen, d.h. Logikschaltungen zum Empfangen eines Paketes in einem ersten Pikonetz, Logikschaltungen zum Analysieren der Routing- bzw. der Wegelenkungs- und Adressinformation, die in dem Paket enthalten ist, und Logikschaltungen zum Senden eines Paketes zu einem zweiten Pikonetz, etc. Der Block Datenbank 1180 umfasst einen physikalischen Speicher zum Speichern von Daten, einen Pikonetz-Indikator 1198, Blöcke 1197, die mit Daten in Bezug auf jedes Pikonetz versehen sind, in welchem die Bluetooth-Einheit momentan ein Mitglied ist, einen Block 1197, der Inter-Pikonetz-Zeitplanungsparameter enthält, einen Block 1178, der Daten enthält, die sich auf die BT-Einheit beziehen. Der einen Pikonetz-Indikator umfassende Block 1198 schließt eine Dateneinheit ein, die das Pikonetz angibt, falls anwendbar, in welchem die BT-Einheit momentan aktiv ist, d.h. der Satz von Pikonetz-bezogenen Daten, die momentan gültig sind. Der Block 1179 "Inter-Pikonetz-Zeitplanungsparameter" schließt Timing- bzw. Zeitabstimmungsparameter ein, die regeln, wann eine BT- Einheit im jeweiligen Pikonetz aktiv zu sein hat, d.h. wann von einem Satz von Pikonetz-bezogenen Daten (insbesondere die Funk-bezogenen Parameter 1173 und die Zeitabstimmungsparameter 1175) zu einem anderen umzuschalten ist. Der Block 1178 "BT-Einheits-bezogene Daten" schließt Daten ein in Bezug auf die BT-Einheit unabhängig von dem Pikonetz, zu welchem die BT-Einheit sich befindet, z.B. Batteriezustand, Benutzerschnittstellenoptionen, Daten, die von dem Benutzer eingegeben sind. Die Blöcke 1197 "Daten in Bezug auf das k-te Pikonetz" umfassen einen Block 1196 "Master/Slave-Indikator", einen Block 1194 "Weiterleitungsindikator/Nichtweiterleitungsindikator", einen Block 1192 "weiterleitungsbezogene Daten", einen Block 1190 "Liste von Pikonetz-Mitgliedern", d.h. Bluetooth-Einheiten, die mit dem Pikonetz verbunden sind, einen Block 1170 "Liste von Weiterleitungsknoten in dem Pikonetz", einen Block 1173" funkbezogene Parameter" und andere Pikonetz-bezogene Daten. Der Block 1196 "Master/Slave-Indikator" schließt eine Dateneinheit ein, die anzeigt, ob die BT-Einheit ein Master oder ein Slave in dem Pikonetz ist. Der Block 1194 "Weiterleitungsknotenindikator/Nichtweiterleitungsknotenindikator" schließt eine Dateneinheit ein, die angibt, ob die BT-Einheit in dem Pikonetz ein Weiterleitungsknoten ist oder nicht. Der Block 1192 "weiterleitungsbezogene Daten" schließt Daten ein, die erforderlich sind zum Durchführen von Weiterleitung von Daten von einem Pikonetz zu einem anderen, z.B. eine Liste von Pikonetzen, die momentan miteinander verbunden sind. Der Block 1173 "funkbezogene Parameter" umfasst Frequenz-Hüpfabfolgen und momentan verwendete Sendeleistung. Der Block 1175 "Zeitabstimmungsparameter" schließt eine Schätzung des Taktwertes der Master-Einheit ein. Die Liste von Weiterleitungsknoten im Block 1170 umfasst einen Datensatz bzw. -Record jedes Weiterleitungsknotens im Pikonetz, wobei jeder Datensatz mindestens umfasst:
    • • Die AM_ADDR des Weiterleitungsknotens;
    • • die BD_ADDR des Weiterleitungsknotens.
  • Die Liste der Pikonetz-Mitglieder des Blocks 1190 umfasst:
    • • Einen Datensatz bzw. -Record jeder Mitgliedseinheit des Pikonetzes mit Ausnahme – in einigen Fällen – der Bluetooth-Einheit selbst, wobei jeder Datensatz umfasst:
    • • Die AM_ADDR der Bluetooth-Einheit;
    • • Die BD_ADDR der Bluetooth-Einheit;
    • • andere optionale Information über die Bluetooth-Einheit, z.B. Kompatibilitätsinformation.
  • Um zu ermöglichen, dass Information von einem Slave zu einem anderen Slave in einem Pikonetz übertragen wird, muss die Information über die Mitglieder des Pikonetzes an alle Mitglieder des Pikonetzes verteilt werden. Wenn eine Quellen-Sklaveneinheit Information zu einer anderen Sklaveneinheit übertragen will, muss demnach der Quellen-Slave Zugang zu der Adresse der anderen Slave-Einheit haben. Diese Adresse könnte die BD_ADDR oder die AM_ADDR oder irgendeine andere Adresse sein, die verwendet wird auf einer höheren Schicht, z.B. die IP-Adresse. Die beste Wahl der Adresse hängt von dem Adressierschema ab, das in dem Pikonetz verwendet wird. Eine Kombination einiger Adressen könnte manchmal auch verwendet werden, um die Umsetzung zwischen Adressen zu ermöglichen, z.B. zwischen einer IP-Adresse und einer BD_ADDR und/oder zwischen einer BD_ADDR und einer AM_ADDR.
  • Demnach sollten z.B. die AM_ADDR und die BD_ADDR aller Slaves für alle Slaves verfügbar gemacht werden.
  • Beim Übertragen von Information zwischen Slaves in einem Pikonetz wird das Routing unter Verwendung des Basisband-Schichtprotokolls ausgeführt, hierdurch den Bedarf des Durchquerens aller Protokollschichten bis zu der Netzwerkschicht 105 oder einer NAL-Schicht eliminierend. Die die zu übertragende Information enthaltenden Pakete können Basisband-Pakete genannt werden und sie werden von einem ersten Slave über den Master zu einem zweiten Slave übertragen. Der erste Slave erhält die Adresse des zweiten Slave von dem Master, fügt sie in ein Kopffeld von Basisband-Paketen ein und übermittelt sie zu dem Master. Der Master analysiert die Adresse im Kopf und leitet das Paket zu dem zweiten Slave in Übereinstimmung mit der Adresse weiter. Zudem, wenn AM_ADDR die verwendete Adressierung ist, wird der Daten-Overhead, der repräsentiert wird durch eine Zieladresse höherer Schicht (z.B. eine IP-Adresse in der IP-Schicht oder eine BD_ADDR in der NAL-Schicht) vollständig eliminiert.
  • Um das Vorhandensein eines neuen Mitgliedes und die relevante bzw. relevanten Adresse/n dieses neuen Mitgliedes den anderen Sklaveneinheiten in dem Pikonetz sobald wie möglich bekannt zu machen, wird vorgezogen, dass die Master-Einheit Adressinformation der neuen Sklaveneinheit verteilt, sobald die neue Sklaveneinheit mit dem Master verbunden ist. Die Master-Einheit sollte auch die neue Sklaveneinheit in Bezug auf die bereits im Pikonetz vorhandenen Sklaveneinheiten informieren durch Übermitteln der relevanten Information und insbesondere der Adressinformation für alle bereits existierenden Sklaveneinheiten. In ähnlicher Weise informiert die Master-Einheit alle anderen Sklaveneinheiten im Pikonetz, wenn eine Sklaveneinheit das Pikonetz verlässt. Wenn eine Sklaveneinheit das Pikonetz verlässt, wird dies explizit oder implizit durch Auszeit bedingt durch Verlust von Funkkontakt erfasst. Eine alternativer Verteilungsmechanismus ist, dass der Master periodisch die Adressinformation aller Sklaveneinheiten im Pikonetz verteilt. Sicherlich ist es auch möglich, die zeitangetriebene Verteilung der Information "ereignisausgelöst" zu kombinieren.
  • Der Verteilungsmechanismus könnte entweder rundsenden (Broadcast) an alle Pikonetz-Mitglieder auf einmal, obwohl der Bluetooth-Intra-Pikonetz-Rundsendemechanismus nicht zuverlässig ist, da Meldungen nicht bestätigt werden, oder, senden in eins-zu-eins-Zuordnung (Unicast) von der Master-Einheit zu jeder Sklaveneinheit, eine nach der anderen, einschließen. Wenn die Adressinformation aller Sklaveneinheiten periodisch per Unicast an jede Sklaveneinheit übermittelt wird, sollte die Adressinformation der Sklaveneinheit, die die Information empfängt, sicherlich ausgeschlossen sein von der Meldung. Das zu verwendende Protokoll könnte das LMP (einschließlich neuer PDUs) sein oder ein VNS-Schichtprotokoll. Es gibt auch andere Vorschläge der Anpassungsschichten zwischen L2CAP und der Netzschicht, die beispielsweise Netzanpassungsschicht bzw. Network-Adaption-Layer (NAL) genannt wird, welche auch eingeschlossen sein könnten in diesem Protokoll. Andere Protokolle können ebenfalls zu diesem Zweck verwendet werden.
  • Eine BT-Einheit kann nur Daten in einem Pikonetz auf einmal senden und empfangen, so dass die Teilnahme in mehreren Pikonetzen auf einer Zeit-Multiplex-Basis sein muss. Die in jedem Pikonetz verbrachte Zeit wird von einem Zeitplanungs-Algorithmus (Scheduling) verwaltet. Dieser Algorithmus könnte auf verschiedene Arten in Übereinstimmung mit unterschiedlichen Prinzipien entworfen sein, z.B. fester zyklischer Warteschlangenbetrieb, Verhandlung zwischen einer Slave-Einheit und einer Master-Einheit (wenn anwendbar), dynamisches Zuordnen von Zeitfenstern (durch den Master eines Pikonetzes basierend auf dem vorliegenden Verkehr), etc. Wenn eine BT-Einheit von einem Pikonetz zu einem anderen umschaltet, muss sie die Verwendung eines anderen Satzes von Pikonetz-bezogenen Daten beginnen, wie in 10 gezeigt. Speziell die funkbezogenen Parameter, z.B. die Frequenz-Hüpfabfolge, die Zeitabstimmungsparameter, z.B. der Taktwert des Masters des Pikonetzes müssen umgeschaltet werden, damit die Bluetooth-Einheit in der Lage ist, in dem neuen Pikonetz zu kommunizieren. In 10 sind unterschiedliche Sätze von Pikonetz-bezogenen Daten in einer BT-Einheit dargestellt sowie ein Pikonetz-Indikator, der anzeigt, welcher der Sätze von Pikonetz-bezogenen Daten momentan gültig ist.
  • Um eine Inter-Pikonetz-Kommunikation zu ermöglichen, muss die Adresse jedes im Pikonetz vorliegenden Weiterleitungsknoten ebenfalls verteilt werden. Diese Adresse könnte AM_ADDR sein, BD_ADDR, eine IP-Adresse oder selbst eine VNS- oder NAL-spezifische Adresse oder eine ähnliche Adresse. Auf dieselbe Weise wie für allgemeine Adressinformation eines Slave-Mitglieds könnte auch in diesem Fall irgendeine Kombination dieser Adressen nützlich sein, abhängig von dem Adressierungs- und Routing-Mechanismus, der in dem Pikonetz und dem Streunetz verwendet wird, und die unabhängige Verwendung der Adressinformation. Eine Verteilung von Weiterleitungsknoteninformation könnte separat oder in Verbindung mit der Verteilung der allgemeinen Adressinformation aller Sklaveneinheiten im Pikonetz vorgenommen werden. Wenn in Verbindung mit der Adressinformation bereitgestellt, könnte ein Indikator für jede Sklaveneinheit vorgesehen sein, der anzeigt, ob es ein Weiterleitungsknoten ist oder nicht. Wenn eine Weiterleitungsknoteninformation betrachtet wird, betrifft dies auch den Master, da der Master auch ein Weiterleitungsknoten sein kann. Wenn die Weiterleitungsknoteninformation gemeinsam mit der Sklaveneinheitsadressinformation verteilt wird und die Master-Einheit zufällig ein Weiterleitungsknoten ist, muss dieser Zustand der Master-Einheit zu der Information der Sklaveneinheiten hinzugefügt werden.
  • Selbst wenn die Weiterleitungsknoteninformation in der Verteilung von Sklaveneinheitsadressinformation enthalten ist, muss es dennoch möglich sein, Weiterleitungsknoteninformation getrennt zu verteilen, wenn ereignisausgelöste Verteilung verwendet wird. Wenn eine BT- Einheit ein Weiterleitungsknoten wird, müssen die anderen Mitglieder des Pikonetzes informiert werden. In ähnlicher Weise, wenn eine BT-Einheit aufgibt, Weiterleitungsknoten zu sein, sollten die anderen Pikonetzmitglieder informiert werden. Diese Information könnte von der Master-Einheit zu den anderen Slave-Einheiten rundgesendet werden oder per Unicast zugestellt werden, aber zuerst muss die betroffene BT-Einheit, d.h. die Einheit, die ein Weiterleitungsknoten wird oder diesen Zustand aufgibt, die Master-Einheit informieren. Dies wird vorzugsweise über Meldungen in der VNS-Schicht oder NAL-Schicht oder einer ähnlichen Schicht ausgeführt, aber die Meldungen könnten auch mit neuen LMP-PDUs oder durch ein anderes Protokoll übertragen werden.
  • In einer weiteren Ausführungsform meldet die BT-Einheit, die ihren Weiterleitungszustand davon, kein Weiterleitungsknoten zu sein, in den Zustand, ein Weiterleitungsknoten zu sein, geändert hat, dies den anderen Pikonetz-Mitgliedern direkt über die Slave-zu-Slave-Kommunikation.
  • Um das Kompatibilitätsproblem in Slave-zu-Slave-Kommunikation innerhalb eines Pikonetzes zu behandeln, könnte die Master-Einheit einfach die Liste von unterstützten und nicht unterstützten Merkmalen für eine bestimmte Slave-Einheit gemeinsam mit der Adressinformation für die betreffende Slave-Einheit verteilen. Die Liste von Merkmalen sollte zuerst von der neuen Slave-Einheit durch die Master-Einheit erhalten werden über die Prozeduren LMP-features-req, LMP features res, obwohl die Liste von Merkmalen bzw. Features ausgedehnt werden muss, um beispielsweise die gemeinsame Medienemulationsschicht (Shared Medium Emulation Layer) zu unterstützen, z.B. die NAL-Schicht, falls verwendet, Fähigkeiten weiterleitend, Unterstützung für Slave-zu-Slave-Intra-Pikonetz-Kommunikation, etc. Änderungen in der Liste unterstützter Merkmale in bereits existierenden Pikonetz-Mitgliedern sollten ebenfalls an die anderen Pikonetz-Mitglieder kommuniziert werden. Dies könnte dadurch ausgeführt werden, dass zuerst die Master-Einheit informiert wird, es sei denn, die betroffene Einheit ist selbst die Master-Einheit, welche dies dann an die anderen Sklaveneinheiten unter Verwendung von Rundsenden oder mehreren Unicast-Meldungen verteilt. Eine Alternative ist, dass die betroffene Slave-Einheit die neue Liste unterstützter und nicht unterstützter Merkmale oder möglicherweise nur die Modifikationen der alten Liste an die anderen Slave-Einheiten per Slave-zu-Slave-Kommunikation verteilt und an die Master-Einheit unter Verwendung von Slave-zu-Master-Einzelsenden (Unicast) verteilt.
  • In noch einem weiteren Verfahren zum Bereitstellen nützlicher Information, d.h. irgendeiner der oben erwähnten Arten von Information und möglicherweise anderer nützlicher Information, an alle Mitglieds-Einheiten eines Pikonetzes ist es, die gesamte Information in der Master-Einheit, beispielsweise einer Datenbank, zu speichert und diese Information für die Sklaveneinheiten auf Anfrage hin zugreifbar zu machen. Eine Sklaveneinheit würde dann in der Lage sein, die gesamte Information in der Datenbank des Masters oder eine relevante Untermenge der Information von dem Master anzufordern. Eine relevante Untermenge würde zum Beispiel die gesamte Adressinformation sein, die gesamte Weiterleitungsknoteninformation oder Adressinformation für eine ausgewählte Einheit. Die Anfrage und Antwort könnten durch LMP oder ein speziell bezeichnetes Protokoll übertragen werden oder durch unterschiedliche Protokolle, abhängig von der Art der angeforderten Information.
  • Bevor eine Slave-Einheit irgendwelche Information von der Master-Einheit anfordern kann, muss die relevante Information von den Slave-Einheiten zu der Master-Einheit übermittelt werden. Dies könnte auf Anfrage von der Master-Einheit vorgenommen werden oder von einer Slave-Einheit gesendet, ausgelöst durch ein internes Ereignis in der Slave-Einheit, z.B. ein Umschalten von dem Zustand, ein Weiterleitungsknoten zu sein, zu dem, keiner zu sein. Ein solches "Master-Einheits-Datenbank"-Verfahren kann als Einzellösung verwendet werden oder als ein Sicherungsmechanismus für irgendwelche der oben beschriebenen Verteilungsmechanismen.
  • In einer anderen Ausführungsform ist ein Verfahren zum Behandeln von Kompatibilitätsproblemen während einer Slavezu-Slave-Kommunikation, es den LMP_features_req und LMP_features_res PDU zu ermöglichen, Slave-zu-Slave zu funktionieren, d.h. im wesentlichen Durchlaufen zweier Hops innerhalb eines Pikonetzes. Dieses Verfahren erfordert, dass beide involvierte Slave-Einheiten Slave-zu-Slave-Kommunikation unterstützen, aber auch andere Information der Unterstützung anderer Merkmale, z.B. die Unterstützung von dem modifizierten Basisband-Paketkopfformat, das in der gleichzeitig angemeldeten Patentanmeldung beschrieben worden ist (Verfahren, Knoten und Anordnung in einem Kommunikationsnetz) und detailliert in Verbindung mit 1a–e besprochen ist.
  • In 6 ist ein Bluetooth-Netz oder Streunetz 601 dargestellt, das zwei Pikonetze umfasst. Das erste Pikonetz 602 umfasst mehrere Knoten A, B, C, D, E und F, wobei der Knoten F der Master ist und die anderen Knoten A, B, C, D, E Slaves sind. Das zweite Pikonetz 603 umfasst mehrere Knoten E, G, H, I und J, wobei der Knoten J der Master ist und die anderen Knoten E, G, H und I Slaves sind. Jeweilige Slaves A, B, C, D und E kommunizieren mit dem Master F über Funkverbindungen 604. Die jeweiligen Slaves E, G, H und I kommunizieren mit dem Master J über Funkverbindungen 605. Die Einheit E ist ein Slave in sowohl dem ersten Pikonetz 602 als auch dem zweiten Pikonetz 603 und dient als Weiterleitungsknoten beim Übertragen von Paketen zwischen dem ersten Pikonetz 602 und dem zweiten Pikonetz 603. Das Bluetooth-Netz 601 umfasst demnach zwei Master F und J und einen Weiterleitungsknoten E. Innerhalb des Netzes wird ein Basisbandpaket übertragen, wobei das Basisbandpaket einen Kopf bzw. Header hat, wie in 1a und 1b gezeigt. Der Master F steuert die gesamte Kommunikation innerhalb des ersten Pikonetzes 602, und der Master J steuert die gesamte Kommunikation innerhalb des zweiten Pikonetzes 603. Ein Paket, das auch ein Basisbandpaket genannt wird, wie bei der Slave-zu-Slave-Kommunikation, kann von einem ersten Knoten A im ersten Pikonetz über den Master F, den Weiterleitungsknoten E und den Master J zu einem zweiten Knoten G im zweiten Pikonetz geroutet werden. Zum Ausführen der Übertragung des Paketes wird eine Übertragungsstrecke bzw. -route erstellt zwischen dem ersten Knoten A und dem zweiten Knoten G, wobei jedes Paket, das entlang der Route gesendet wird, die Routing-Information umfasst, die von der Netzwerkschicht oder NAL-Schicht stammt. Wenn ein Routing-Protokoll, das AODV (Ad-hoc On demand Distance Vector) genannt wird, verwendet wird, ist die Routing-Information die Adresse des Zielknotens, in diesem Fall die des zweiten Knotens G. wenn ein Routing-Protokoll verwendet wird, das Dynamic-Source-Routing bzw. dynamische Quellen-Wegelenkung genannt wird, umfasst die Routing-Information die Adresse jedes Knotens, der zu durchqueren ist entlang der Route bzw. Übertragungsstrecke, und die Zieladresse, was in diesem Fall die Adressen der Knoten F, E, J und G umfasst. Um die Paketübertragung unter Verwendung des Basisbandprotokolls in der physikalischen Schicht auszuführen, ist die Routing-Information in einem Kopf bzw. Header eines niederen Protokolls angeordnet, d.h. im Nutzlast-Headerfeld, das eine Kurzschließung sowohl der Basisband-Nutzlast-Unterschicht als auch der L2CAP-Schicht impliziert. Der Begriff Kurzschließen einer Protokollschicht, wie er hier verwendet wird, bedeutet, dass der Weiterleitungsknoten und der Master-Knoten die Information dieser Protokollschicht nicht auszupacken und zu analysieren zu haben, um das Paket weiterzuleiten.
  • In 7c ist ein Diagramm des Basisbandpaket-Headerformates gezeigt. In 7a ist das Nutzlast-Headerformat eines Basisbandpakets für Einzelschlitzpakete gezeigt. In 7b ist ein Diagramm des Formats für Basisbandpakete vom Mehrschlitztyp gezeigt. Die in 7a–cgezeigten Header sind in Bezug auf die in 1c–e dargestellten Header vergrößert um ein Weiterleitungsindikatorfeld "Weiterl.-Flag" (engl.: FORW IND) und ein relevantes Routing-Indikatorfeld ROUTING INFO. Der Weiterleitungsindikator weist einen Weiterleitungsknoten an, dass er die Pakete zu den Protokollen der oberen Schicht senden sollte, wenn der Weiterleitungsindikator nicht gesetzt ist, z.B. FORW IND=0, oder dass er einen Weiterleitungsprozess aufrufen sollte innerhalb der unteren Schicht, wenn der Weiterleitungs-Indikator gesetzt ist, z.B. FORW IND=1. Das Setzen des Weiterleitungsindikators gibt auch an, dass er gefolgt wird von der Adressinformation, die zum Weiterleiten des Paketes erforderlich ist. Wenn der Weiterleitungsindikator nicht gesetzt ist, ist keine Routing-Information eingeschlossen. Alternativ kann die Routing-Information eingeschlossen sein, angebend an den Empfangsknoten, dass der Empfangsknoten der Bestimmungsortknoten ist und demnach, dass das Paket zu Protokollen der oberen Schicht zu senden ist. Dieses Niederschicht-Routingverfahren kann verwendet werden für Datenpakete, die entlang eines bereits eingerichteten Leitwegs zu senden sind. Die Meldung, die verwendet wurde zum Erstellen des Leitwegs zum ersten Mal, z.B. NAL- oder eine Netzschichtmeldung, kann nicht das hier beschriebene Verfahren anwenden.
  • Nun kann bei Paketübertragung in der Netzschicht das Paket viel größer sein als in der physikalischen Schicht. Die NAL- oder Netzschichtpakete werden möglicherweise in ein einzelnes L2CAP-Paket passen, aber die L2CAP-Pakete können häufig segmentiert werden müssen, bevor sie in mehreren Basisbandpaketen übertragen werden. Die Tatsache, dass die Routing-Information in jedem Basisbandpaket statt nur in dem NAL- oder Netzschichtpaket enthalten ist, erhöht den Overhead bzw. Datenzusatz. In einer Ausführungsform wird ein L2CAP-Paket segmentiert in mehrere Basisbandpakete, um übertragen zu werden, wobei ein erstes Basisbandpaket das erste Segment des L2CAP-Paketes enthält und die nachfolgenden Basisbandpakete die jeweiligen nachfolgenden Segmente des L2CAP-Paketes enthalten. In einer weiteren Ausführungsform wird der Weiterleitungsindikator gesetzt und die Routing-Information wird in die ersten und die nachfolgenden Basisbandpakete eingefügt.
  • In noch einer weiteren Ausführungsform wird der Weiterleitungsindikator gesetzt und die Routing-Information wird nur in das erste Basisbandpaket eingefügt, aber in nachfolgenden Basisbandpaketen ist keine Routing-Information enthalten. In diesem Fall weist der Weiterleitungsindikator in dem ersten Basisbandpaket auch den Weiterleitungsknoten E und die Master F und J (wie in 6 gezeigt) an, die Routing-Information des ersten Basisbandpaketes zu speichern und die Routing-Information der ankommenden Verbindung zuzuordnen, d.h. der Verbindung, auf welcher das erste Basisbandpaket durch den Weiterleitungsknoten E empfangen worden ist und auf welcher auch die nachfolgenden Basisbandpakete von dem Weiterleitungsknoten E empfangen werden. Der Weiterleitungsindikator muss mit noch einem Ein-Bit-Indikator vervollständigt werden, welcher Routing-Informations-Indikator (RII) genannt wird. Der RII wird nur gesetzt, wenn der Weiterleitungsindikator gesetzt wird. Der Zweck des RII ist, anzuzeigen, ob die Routing-Information tatsächlich eingeschlossen wird nach dem Weiterleitungs-Indikator. Für das erste Basisbandpaket wird das RII-Paket gesetzt, z.B. =1, anzeigend, dass die Routing-Information vorliegt. In den nachfolgenden jeweiligen Basisbandpaketen wird das Weiterleitungs-Bit gesetzt, RII wird gelöscht, z.B. =0, zum Anzeigen, dass keine Routing-Information vorliegt. Dann verwenden der Weiterleitungsknoten E und die Master-Knoten F und J die zuletzt empfangene Routing-Information zum Weiterleiten der darauffolgend empfangenen Basisbandpakete bis neue Routing-Information in einem Basisbandpaket empfangen wird.
  • In 9 ist ein Ablaufdiagramm zum Anzeigen, wie ein Paket geroutet wird von einem ersten Knoten A in einem ersten Pikonetz über einen Weiterleitungsknoten E zu einem zweiten Knoten G in einem zweiten unterschiedlichen Pikonetz in der physikalischen Schicht unter Verwendung des Bluetooth-Protokolls eines Bluetooth-Netzes, das mehrere Knoten umfasst. Im Block 901 gibt der erste Knoten in einem Header eines Basisbandpaketes an, dass das Paket weitergeleitet werden sollte. Daraufhin fügt im Block 902 der erste Knoten A relevante Information in den Header des Basisbandpaketes ein. Dann übermittelt im Block 903 der erste Knoten das Paket unter Verwendung von Slave-zu-Slave-Kommunikation zu dem Weiterleitungsknoten E. Dann analysiert im Block 904 der Weiterleitungsknoten E die Weiterleitungsanzeige und die Routing-Information des empfangenen Basisbandpakets. Daraufhin schließt im Block 905 der Weiterleitungsknoten E die Logical-Link-Control- und die Anwendungsschichtprotokoll-Schicht (L2CAP-Schicht) des Pakets kurz. Schließlich leitet im Block 906 der Weiterleitungsknoten E das Paket zu dem Zielknoten weiter, d.h. dem zweiten Knoten G, in Übereinstimmung mit der empfangenen Routing-Information unter Verwendung von Slave-zu-Slave Kommunikation.
  • Nun wird ein Prozess beschrieben zum Erläutern, wie ein Knoten ein Weiterleitungsknoten wird. Zuerst wird der Informationsstrom im ersten Pikonetz beschrieben unter Bezugnahme auf das Ablaufdiagramm in 11. Es müssen zwei Fälle betrachtet werden; die betrachtete Bluetooth-Einheit kann eine Slave-Einheit oder eine Master-Einheit des ersten Pikonetzes sein. Im Block 1510 ist die Bluetooth-Einheit A ein Mitglied eines ersten Pikonetzes. Dann tritt im Block 1520 die Einheit A einem zweiten Pikonetz unter Verwendung von INQUIRY- und PAGE-Prozeduren bei, die im Bluetooth-Standard spezifiziert sind. Im Block 1530 wird geprüft, ob die Einheit A der Master im ersten Pikonetz ist. Wenn die Einheit A der Master des ersten Pikonetzes ist, geht der Ablauf direkt zu Block 1550. Wenn die Einheit A nicht der Master des ersten Pikonetzes ist, geht der Ablauf zu Block 1540. Im Block 1540 informiert die Einheit A den Master des ersten Pikonetzes von ihrem neuen Weiterleitungsknoten-Zustand, optional einschließlich anderer Information, wie zum Beispiel der BD_ADDR des Masters des zweiten Pikonetzes, des Master-Taktwertes und Zeitabstimmungsparameter des zweiten Pikonetzes. Dann gibt im Block 1550 die Master-Einheit des ersten Pikonetzes die Einheit A betreffende Daten in ihre Liste von Weiterleitungsknoten im Pikonetz, einschließlich z.B. der AM_ADDR und BD_ADDR der Einheit A und anderer optionaler Information. Daraufhin übermittelt im Block 1560 die Master-Einheit des ersten Pikonetzes Information über den neuen Weiterleitungsknoten, wobei die gesamte Information in der Master-Einheit oder einer Untereinheit davon gespeichert ist, zu der mindestens einen der Slave-Einheiten, mit Ausnahme der Einheit A, wenn die Einheit A eine Slave-Einheit im ersten Pikonetz ist und sofern nicht der Intra-Pikonetz-Rundsendemechanismus bzw. Broadcast-Mechanismus verwendet wird zum Übermitteln der Information. Schließlich geht der Ablauf zu Block 1570. Im Block 1570 fügt jede empfangende Slave-Einheit die empfangene Weiterleitungsknoteninformation in ihre Liste von Weiterleitungsknoten in dem Pikonetz, von dem die empfangende Slave-Einheit ein Mitglied ist, ein.
  • Nun wird der Informationsablauf in dem zweiten Pikonetz dargelegt, wenn ein Knoten ein Weiterleitungsknoten wird. Es gibt zwei Fälle mit zwei alternativen Arten des Verteilens von Information im Pikonetz, was zu vier unterschiedlichen Fällen führt:
    • • Die neue Einheit ist ein Slave im zweiten Pikonetz Fall 1: Zuerst wird die Pikonetz-Mitgliedsinformation verteilt, daraufhin wird die Weiterleitungsknoteninformation verteilt. Fall 2: Die Pikonetzinformation und die Weiterleitungsknoteninformation werden gemeinsam verteilt.
    • • Die neue Einheit ist der Master des zweiten Pikonetzes, d.h. das zweite Pikonetz wurde gerade erstellt. Fall 3: Zuerst wird die Pikonetz-Mitgliedsinformation verteilt, daraufhin wird die Weiterleitungsknoteninformation verteilt. Fall 4: Pikonetz-Mitgliedsinformation und Weiterleitungsknoteninformation werden gemeinsam verteilt.
  • Die Fälle 1 und 3 werden nun unter Bezugnahme auf das Ablaufdiagramm in 12a und 12b dargelegt. Im Block 2100 der 12a ist eine Bluetooth-Einheit A ein Mitglied eines ersten Pikonetzes. Dann tritt die Einheit A im Block 2110 einem zweiten Pikonetz bei unter Verwendung der in dem Bluetooth-Standard spezifizierten INQUIRY- und PAGE-Prozeduren. Im Block 2115 wird bestimmt, ob die Einheit A ein Master des zweiten Pikonetzes ist. Wenn die Einheit A der Master des zweiten Pikonetzes ist, ist die BD_ADDR der Einheit A bereits der mindestens einen Slave-Einheit des zweiten Pikonetzes bekannt. Da die Einheit A die Master-Einheit ist, hat sie keine AM-ADDR-Adresse. Wenn die Einheit A der Master des zweiten Pikonetzes ist, geht demnach der Ablauf zu Block 2120, in welchem andere relevante Information, z.B. Kompatibilitätsinformation wie eine Liste von unterstützten und nicht unterstützten Merkmalen, IP-Adressen, etc. zu der mindestens einen Slave-Einheiten des zweiten Pikonetzes übertragen wird. Daraufhin geht der Ablauf zu 12b, welcher nachstehend diskutiert wird. Wenn die Einheit A eine Slave-Einheit des zweiten Pikonetzes ist, geht der Ablauf von Block 2115 zu Block 2125. Wenn die Einheit A eine Slave-Einheit des zweiten Pikonetzes ist, sind die BD_ADDR und AM_ADDR der Einheit A bereits dem Master des zweiten Pikonetzes bekannt. Im Block 2125 wird andere relevante Information, z.B. Kompatibilitätsinformation wie eine Liste von unterstützten und nicht unterstützten Merkmalen, IP-Adressen, etc. von der Einheit A zur Master-Einheit des zweiten Pikonetzes übertragen. Daraufhin geht der Ablauf zu Block 2130. In dem Block 2130 speichert die Master-Einheit des zweiten Pikonetzes die empfangene Information in ihrer Datenbank, vorzugsweise in ihrer Liste von Pikonetz-Mitgliedern. Dann sendet im Block 2135 die Master-Einheit des zweiten Pikonetzes BD_ADDR und AM_ADDR jeder der anderen Slave-Einheiten im zweiten Pikonetz Information, welche sie zuvor von jeder der anderen Slave-Einheiten im zweiten Pikonetz erhalten hat, vollständig oder eine Untergruppe davon, und die entsprechende Information der Master-Einheit des zweiten Pikonetzes, ausschließlich BD_ADDR, welche bereits der Einheit A bekannt ist, und AM_ADDR, welche nicht vorliegt, zur Einheit A. Gemeinsam mit der obigen Information oder als eine getrennte Übertragung sendet der Master des zweiten Pikonetzes auch Information über die Weiterleitungsknoten im zweiten Pikonetz an die Einheit A. Dann fügt im Block 2140 die Einheit A einen neuen Record mit relevanten Daten für jede der anderen Slave-Einheiten in dem zweiten Pikonetz in ihre Datenbank ein, vorzugsweise in ihre Liste von Pikonetz-Mitgliedern. Die empfangene Information über die Master-Einheit des zweiten Pikonetzes wird auch in der Liste von Pikonetz-Mitgliedern gespeichert oder woanders in der Datenbank. Daraufhin geht der Ablauf zu Block 2145, in welchem die Einheit A einen neuen Record mit relevanten Daten für jeden der anderen Weiterleitungsknoten im zweiten Pikonetz in ihre Datenbank einfügt, vorzugsweise in die Liste von Weiterleitungsknoten im Pikonetz, einschließlich jedes Records, z.B. BD_ADDR und AM_ADDR, falls vorhanden, des Weiterleitungsknotens und andere optionale Information. Dann sendet im Block 2150 die Master-Einheit des zweiten Pikonetzes die BD_ADDR und die AM_ADDR der Einheit A und die Information, die von der Einheit A erhalten wird, insgesamt oder als Untergruppe davon an die andere mindestens eine Slave-Einheit in dem zweiten Pikonetz, d.h. ausschließlich der Einheit A, es sei denn, der Intra-Pikonetz-Rundsende- bzw. Broadcast-Mechanismus wird verwendet zum Übermitteln der Information. Daraufhin geht der Ablauf zu Block 2155, in welchem jede empfangende Slave-Einheit einen neuen Record mit relevanten Daten in Bezug auf die Einheit A in ihre Datenbank einfügt, vorzugsweise in ihre Liste von Pikonetz-Mitgliedern. Dann liefert in Block 2160 die Einheit A Information über ihren Weiterleitungsknoten-Zustand an die Master-Einheit des zweiten Pikonetzes. Daraufhin fügt im Block 2165 die Master-Einheit des zweiten Pikonetzes einen Record in Bezug auf die Einheit A in ihre Liste von Weiterleitungsknoten im Pikonetz ein, umfassend z.B. die AM_ADDR und die BD_ADDR der Einheit A und andere optionale Information. Dann übermittelt im Block 2170 die Master-Einheit des ersten Pikonetzes Information in Bezug auf den neuen Weiterleitungsknoten, die gesamte in der Master-Einheit oder einer Untergruppe davon gespeicherte Information zu der mindestens einen Slave-Einheit mit Ausnahme der Einheit A, wenn die Einheit A eine Slave-Einheit des ersten Pikonetzes ist und solange nicht der Intra-Pikonetz-Broadcast-Mechanismus verwendet wird zum Übermitteln der Information. Schließlich fügt im Block 2175 jede empfangende Slave-Einheit die empfangene Knotenweiterleitungsinformation in ihre Liste von Weiterleitungsknoten im Pikonetz ein.
  • 12b offenbart den fortgesetzten Informationsablauf nach Block 2120. Die BD_ADDR und die AM_ADDR jeder der Slave-Einheiten im zweiten Pikonetz sind bereits der Einheit A bekannt, da die Einheit A die Master-Einheit des zweiten Pikonetzes ist, und im Block 2180 sammelt die Einheit A andere Information, die in Bezug auf die Slaves relevant ist, falls verfügbar, z.B. Kompatibilitätsinformation wie eine Liste unterstützter und nicht unterstützter Merkmale. Wenn eine Slave-Einheit ein Weiterleitungsknoten ist, wird auch der Weiterleitungsknoten-Zustand und optionale zugehörige Information zu der Einheit A übertragen und von ihr gesammelt. Dann fügt die Einheit A im Block 2182 die empfangene Information in die bereits existierenden Records in ihrer Liste von Pikonetz-Mitgliedern ein. Daraufhin fügt im Block 2184 die Einheit A Information jeder Slave-Einheit, die ein Weiterleitungsknoten ist, in ihre Liste von Weiterleitungsknoten im Pikonetz ein, wobei die Information z.B. AM_ADDR und BD_ADDR und andere optionale Information umfasst. Die BD_ADDR der Einheit A ist bereits den Slave-Einheiten des zweiten Pikonetzes bekannt und da die Einheit A die Master-Einheit ist, hat sie keine AM_ADDR, aber im nächsten Block wird andere relevante Information zu der mindestens einen Slave-Einheit des zweiten Pikonetzes übermittelt, z.B. Kompatibilitätsinformation wie eine Liste unterstützter und nicht unterstützter Merkmale, IP-Adressen, etc. Dann speichert im Block 2190 jede empfangende Slave-Einheit die relevanten Daten in Bezug auf die Einheit A in ihrer Datenbank, z.B. in ihrer Liste von Pikonetz-Mitgliedern. Dann sendet im Block 2192 die Einheit A Information in Bezug auf ihren Weiterleitungsknoten-Zustand zu der mindestens einen Slave-Einheit des zweiten Pikonetzes. Schließlich fügt im Block 2194 jedes empfangende Slave-Einheit die empfangene Weiterleitungsknoteninformation in ihre Liste von Weiterleitungsknoten im Pikonetz ein, einschließlich z.B. der BD_ADDR und anderer optionaler Information.
  • Die Fälle 2 und 4 werden nun unter Bezugnahme auf das Ablaufdiagramm der 13a und 13b diskutiert. Im Block 5500, 13a, ist eine Bluetooth-Einheit A ein Mitglied eines ersten Pikonetzes. Dann tritt im Block 5510 die Einheit A einem zweiten Pikonetz bei unter Verwendung der INQUIRY- und PAGE-Prozeduren, die in der Bluetooth-Spezifikation spezifiziert sind. Im Block 5520 wird bestimmt, ob die Einheit A der Master des zweiten Pikonetzes ist. Wenn die Einheit A der Master des zweiten Pikonetzes ist, geht der Ablauf zu Schritt 13b, welcher nachstehend diskutiert wird. Im Fall, dass die Einheit A eine Slave-Einheit des zweiten Pikonetzes ist, geht der Ablauf von Block 5520 zu 5530. Wenn die Einheit A eine Slave-Einheit des zweiten Pikonetzes ist, sind die BD_ADDR und die AM_ADDR der Einheit A bereits dem Master des zweiten Pikonetzes bekannt. Im Block 5530 wird andere relevante Information, z.B.
  • Inkompatibilitätsinformation wie eine Liste von unterstützten und nicht unterstützten Merkmalen, IP-Adresse, etc. gemeinsam mit Information in Bezug auf den Weiterleitungsknoten-Zustand der Einheit A von der Einheit A zur Master-Einheit des zweiten Pikonetzes übermittelt. Daraufhin geht der Ablauf zu Block 5535. Im Block 5535 speichert die Master-Einheit des zweiten Pikonetzes die empfangene Information in ihrer Datenbank. Vorzugsweise wird ein Teil der Information, z.B. ausschließlich der Information in Bezug auf den Weiterleitungszustand der Einheit A, in der Liste von Pikonetz-Mitgliedern gespeichert, und die Information in Bezug auf den Weiterleitungsknotenzustand der Einheit A wird gemeinsam mit z.B. BD_ADDR und AM_ADDR der Einheit A in die Liste von Weiterleitungsknoten eingegeben. Dann sendet im Block 5540 die Master-Einheit des zweiten Pikonetzes BD_ADDR und AM_ADDR jeder der anderen Slave-Einheiten in das zweite Pikonetz, deren Information zuvor von jeder der anderen Slave-Einheiten in dem zweiten Pikonetz empfangen worden ist, insgesamt oder eine Untermenge davon, und die entsprechende Information über die Master-Einheit des zweiten Pikonetzes, ausschließlich BD_ADDR, welche bereits der Einheit A bekannt ist, und AM_ADDR, welche nicht vorliegt, zur Einheit A. Gemeinsam mit der oben erwähnten Information oder als eine getrennte Übertragung sendet der Master des zweiten Pikonetzes auch Information über die Weiterleitungsknoten des zweiten Pikonetzes zur Einheit A. Dann fügt im Block 5545 die Einheit A einen neuen Record mit relevanten Daten für jede der anderen Slave-Einheiten in dem zweiten Pikonetz in seine Datenbank ein, vorzugsweise in seine Liste von Pikonetz-Mitgliedern. Die empfangene Information über die Master-Einheit des zweiten Pikonetzes wird auch in der Liste von Pikonetz-Mitgliedern gespeichert oder andernfalls in der Datenbank. Daraufhin geht der Ablauf zu Block 5550, wobei die Einheit A einen neuen Datensatz (Record) mit relevanten Daten für jeden der Weiterleitungsknoten im zweiten Pikonetz in seiner Datenbank speichert, vorzugsweise in der Liste von Weiterleitungsknoten im Pikonetz, dabei in jedem Datensatz z.B. BD_ADDR und AM_ADDR, falls vorhanden, des Weiterleitungsknotens und andere optionale Information einschließend. Dann sendet in Block 5555 die Master-Einheit des zweiten Pikonetzes die BD_ADDR und die AM_ADDR der Einheit A und die Information, die von der Einheit A empfangen worden ist, insgesamt oder als Untermenge davon, an die andere mindestens eine Sklaveneinheit in dem zweiten Pikonetz, d.h. ausschließlich der Einheit A, solange nicht der Intra-Pikonetz-Rundsendemechanismus verwendet wird zum Übermitteln der Information. Schließlich geht der Ablauf zu Block 5560, wobei jede empfangende Slave-Einheit alle oder einen Teil der empfangenen Daten in ihrer Datenbank speichert. Vorzugsweise wird ein Teil der Daten, z.B. ausschließlich der den Weiterleitungsknoten-Status betreffenden Daten der Einheit A, eingefügt in die Liste von Pikonetz-Mitgliedern. Die Daten in Bezug auf den Weiterleitungsknoten-Zustand der Einheit A gemeinsam mit z.B. der BD_ADDR und der AM_ADDR der Einheit A werden in die Liste von Weiterleitungsknoten eingefügt.
  • 13b offenbart den Informationsablauf in dem Fall, in welchem die Einheit A ein Master ist, nach dem Block 5520 in 13a. Die BD_ADDR und die AM_ADDR jeder der Slave-Einheiten in dem zweiten Pikonetz sind der Einheit A bereits bekannt, da die Einheit A die Master-Einheit des zweiten Pikonetzes ist. Demnach sammelt in Block 5560 die Einheit A andere relevante Information, falls vorhanden, z.B. Kompatibilitätsinformation wie eine Liste unterstützter und nicht unterstützter Merkmale. Wenn eine Slave-Einheit ein Weiterleitungsknoten ist, wird der Weiterleitungsknoten-Zustand und optionale bezogene Information ebenfalls zur Einheit A übermittelt. Dann fügt im Block 5562 die Einheit A die empfangene Information in die bereits existierenden Records bzw. Datensätze in ihrer Liste von Pikonetz- Mitgliedern ein. Daraufhin fügt im Block 5564 die Einheit A Information der möglicherweise mindestens einen Slave-Einheit, die Weiterleitungsknoten ist, in ihre Liste von Weiterleitungsknoten in dem Pikonetz ein, die z.B. AM_ADDR und BD_ADDR und andere Information umfasst. Die BD_ADDR der Einheit A ist bereits den Slave-Einheiten des zweiten Pikonetzes bekannt und da die Einheit A die Master-Einheit ist, hat sie keine AM_ADDR. Demnach wird im Block 5560 andere relevante Information an die mindestens eine Slave-Einheit des zweiten Pikonetzes übermittelt, z.B. Kompatibilitätsinformation wie eine Liste unterstützter oder nicht unterstützter Merkmale, IP-Adresse, etc. Dann speichert im Block 5570 jede empfangende Slave-Einheit die relevanten Daten in Bezug auf die Einheit A in ihrer Datenbank, z.B. in ihrer Liste von Pikonetz-Mitgliedern. Dann fügt im Block 5572 jede empfangende Slave-Einheit die empfangene Weiterleitungsknoteninformation in ihre Liste von Weiterleitungsknoten im Pikonetz ein, einschließlich z.B. der BD_ADDR und anderer optionaler Information.
  • Das Szenario, wenn eine Bluetooth-Einheit aufgibt, Weiterleitungsknoten zu sein, wird nun betrachten. Eine Bluetooth-Einheit A wird als ein Mitglied eines ersten und eines zweiten Pikonetzes angenommen und bildet demnach einen Weiterleitungsknoten in beiden Pikonetzen. Die Einheit A verlässt dann das zweite Pikonetz. 14 ist ein Ablaufdiagramm zum Erläutern des Informationsablaufs im ersten Pikonetz, wenn eine Einheit A aufgibt, Weiterleitungsknoten zu sein. Es gibt zwei Fälle zu betrachten:
    • • Einheit A ist eine Slave-Einheit im ersten Pikonetz;
    • • Einheit A ist der Master des ersten Pikonetzes.
  • In 14, wie in Block 4100 angegeben, ist die Einheit A ein Mitglied eines ersten und eines zweiten Pikonetzes. Dann geht der Ablauf zu Block 4110, wobei die Einheit A das zweite Pikonetz verlässt in Übereinstimmung mit bekannten Prozeduren, die in dem Bluetooth-Standard spezifiziert sind, entweder explizit durch Senden oder Empfangen von LMP PDU LMP_detach oder implizit durch Verbindungszeitunterbrechung bedingt durch Verlust des Funkkontaktes Dann wird in Block 4120 entschieden, ob die Einheit A der Master des ersten Pikonetzes ist. Wenn die Einheit A der Master ist, geht der Ablauf zu Block 4130. Wenn die Einheit A in dem ersten Pikonetz eine Slave-Einheit ist, sendet die Einheit A eine Meldung an die Master-Einheit des ersten Pikonetzes, anzeigend, dass die Einheit A nicht länger ein Weiterleitungsknoten ist. Wenn die Einheit A in ihrer eigenen Liste von Weiterleitungsknoten vorliegt, dann wird der die Einheit A umfassende Datensatz von dieser Liste entfernt. Dann entfernt in Block 4130 die Master-Einheit des ersten Pikonetzes den die Einheit A umfassenden Record bzw. Datensatz von ihrer Liste von Weiterleitungsknoten. Daraufhin informiert in Block 4135 die Master-Einheit des ersten Pikonetzes die mindestens eine Slave-Einheit des ersten Pikonetzes, ausschließlich A, wenn A eine Slave-Einheit des ersten Pikonetzes ist und wenn nicht ein Intra-Pikonetz-Rundsendemechanimsus verwendet wird zum Übermitteln der Information, dass die Einheit A aufgegeben hat, ein Weiterleitungsknoten zu sein. Schließlich entfernt in Block 4140 jede empfangende Slave-Einheit den die Einheit A umfassenden Record aus ihrer Liste von Weiterleitungsknoten.
  • Nun wird der Informationsablauf, wenn eine Bluetooth-Einheit aufgibt, Weiterleitungsknoten im zweiten Pikonetz zu sein, unter Bezugnahme auf 15a und 15b beschrieben. Es gibt zwei zu betrachtende Fälle:
    • • Fall 1: Zuerst wird die Anzeige, dass die Einheit A aufgegeben hat, Weiterleitungsknoten zu sein, verteilt, daraufhin wird die Angabe, dass die Einheit A das Pikonetz verlassen hat, verteilt.
    • • Fall 2: Nur die Angabe, dass die Einheit A aufgegeben hat, Weiterleitungsknoten zu sein, wird verteilt. Die Tatsache, dass die Einheit A nicht länger ein Weiterleitungsknoten im Pikonetz ist, wird implizit angenommen.
  • Der triviale Fall, in welchem die Einheit A der Master des zweiten Pikonetzes ist, in welchem Fall das zweite Pikonetz zusammenbricht, wenn die Master-Einheit es verlässt, und wobei das zweite Pikonetz nur eine Einheit abgesehen von der Einheit A umfasst, in welchem Fall es keine anderen Einheiten gibt, an welche Information zu verteilen ist, werden nicht detailliert beschrieben.
  • Nun wird der erste Fall unter Bezugnahme auf 15a beschrieben. Zuerst, wie im Block 7100 angegeben, wird angenommen, dass die Einheit A ein Mitglied eines ersten und eines zweiten Pikonetzes ist, wobei die Einheit A eine Sklaven-Einheit im zweiten Pikonetz ist. Dann verlässt in Block 7110 die Einheit A das zweite Pikonetz in Übereinstimmung mit Prozeduren, die im Bluetooth-Standard spezifiziert sind, und zwar entweder explizit durch Senden oder Empfangen von LMP PDU LMP_detach oder implizit durch durch den Verlust von Funkkontakt bedingte Verbindungszeitunterbrechung (connection time-out). Daraufhin erfasst die Master-Einheit des zweiten Pikonetzes, dass die Einheit A das zweite Pikonetz verlassen hat, unter Verwendung von bekannten Mechanismen, die im Bluetooth-Standard spezifiziert sind. Dann entfernt im Block 7120 die Master-Einheit des zweiten Pikonetzes den die Einheit A umfassenden Datensatz aus ihrer Liste von Weiterleitungsknoten. Im Block 7125 informiert die Master-Einheit des zweiten Pikonetzes die mindestens eine Slave-Einheit des zweiten Pikonetzes darüber, dass die Einheit A aufgegeben hat, ein Weiterleitungsknoten zu sein. Dann entfernt jede Slave-Einheit in Schritt 7130 den die Einheit A umfassenden Record aus ihrer Liste von Weiterleitungsknoten. In Block 7140 entfernt die Master-Einheit des zweiten Pikonetzes den die Einheit A umfassenden Record aus ihrer Liste von Pikonetz-Mitgliedern. Daraufhin informiert in Block 7145 die Master-Einheit des zweiten Pikonetzes die mindestens eine Slave-Einheit des Pikonetzes darüber, dass die Einheit A das Pikonetz verlassen hat. Schließlich entfernt in Block 7150 jede empfangende Slave-Einheit den die Einheit A umfassende Liste aus ihrer Liste von Pikonetz-Mitglieder.
  • Nun wird der zweite Fall unter Bezugnahme auf 15b beschrieben. Zuerst ist in Block 7200 eine Einheit A ein Mitglied eines ersten und zweiten Pikonetzes, wobei die Einheit A eine Slave-Einheit im zweiten Pikonetz ist. Dann verlässt in Block 7210 die Einheit A das zweite Pikonetz in Übereinstimmung mit in dem Bluetooth-Standard spezifizierten Prozeduren, entweder explizit durch Senden oder Empfangen des LMP PDU LMP_detach oder implizit durch Verbindungszeitunterbrechung, bedingt durch den Verlust von Funkkontakt. Daraufhin erfasst in Block 7220 die Master-Einheit des zweiten Pikonetzes, dass die Einheit A das zweite Pikonetz verlassen hat, unter Verwendung bekannter in dem Bluetooth-Standard spezifizierter Mechanismen. Dann prüft im Block 7230 die Master-Einheit des zweiten Pikonetzes, ob Einheit A in der Liste von Weiterleitungsknoten enthalten war, und entfernt den die Einheit A umfassenden Record von ihrer Liste von Weiterleitungsknoten. Im Block 7240 entfernt die Master-Einheit des zweiten Pikonetzes den die Einheit A umfassenden Record von ihrer Liste von Pikonetz-Mitgliedern. Im Block 7250 informiert die Master-Einheit des zweiten Pikonetzes die mindestens eine Slave-Einheit des zweiten Pikonetzes darüber, dass die Einheit A das Pikonetz verlassen hat. Im Block 7260 prüft jede empfangende Slave-Einheit, ob die Einheit A in der Liste von Weiterleitungsknoten enthalten war, und entfernt dann den die Einheit A umfassenden Record von ihrer Liste von Weiterleitungsknoten. Schließlich entfernt im Block 7270 jede empfangende Slave-Einheit den die Einheit A umfassenden Record von ihrer Liste von Pikonetz-Mitgliedern.
  • Es ist offensichtlich, dass die derart beschriebene Erfindung in vielerlei Art variiert werden kann. Solche Variationen und alle derartigen Modifikationen, wie sie Fachleuten offenbar wären, sind als innerhalb des Schutzbereichs der folgenden Patentansprüche eingeschlossen angesehen.

Claims (26)

  1. Digitalkommunikationssystem (601), die Knoten (A, B, C, D, E, F) umfassend, wobei die Knoten (A, B, C, D, E, F) einen Zentralknoten (F) und mindestens zwei periphere Knoten (A, B) einschließen, der Zentralknoten alle Vorrichtungen für die Kommunikation in dem System umfasst und einen Speicher (1180) zum Speichern von das System selbst und/oder die individuellen Knoten betreffender Information, wobei jeder der Knoten einen Sender umfasst und einen Empfänger (11), und Information nur direkt übertragen wird zwischen dem Zentralknoten und jedem der peripheren Knoten, gekennzeichnet durch eine Steuervorrichtung in dem Zentralknoten (11) zum Übertragen von in der dem System und/oder den individuellen Knoten zugeordneten Speichervorrichtung für jeden peripheren Knoten.
  2. Digitalkommunikationssystem nach Anspruch 1, dadurch gekennzeichnet, dass jeder periphere Knoten eine Vorrichtung umfasst zum Speichern der Information.
  3. Digitalkommunikationssystem nach Anspruch 1, dadurch gekennzeichnet, dass das direkte Übertragen von Information drahtlos ausgeführt wird, insbesondere unter Verwendung von Kurzbereichsfunkwellen.
  4. Digitalkommunikationssystem nach Anspruch 1, dadurch gekennzeichnet, dass die Steuervorrichtung in dem Zentralknoten eingerichtet ist zum Übertragen von mindestens eine Adresse jedes peripheren Knoten umfassender Adressinformation.
  5. Digitalkommunikationssystem nach Anspruch 1, dadurch gekennzeichnet, dass die Steuervorrichtung in dem Zentralknoten eingerichtet ist zum Übertragen von kompatibilitätsbezogener Information.
  6. Digitalkommunikationssystem nach Anspruch 1, dadurch gekennzeichnet, dass das System ein Bluetooth-Pikonetz ist.
  7. Digitalkommunikationssystem nach Anspruch 1, dadurch gekennzeichnet, dass ein erster der Knoten ein Zentralknoten einer ersten Gruppe von Knoten ist und ein zweiter der Knoten ein Zentralknoten einer zweiten Gruppe von Knoten ist, die ersten und zweiten Knoten unterschiedliche Knoten sind und die Knoten imstande sind, Mitglied in sowohl der ersten als auch der zweiten Gruppe zu sein, wobei jeder Knoten eine erste Speichervorrichtung hat zum Speichern von Information in Bezug auf Information über den ersten der Knoten und die Knoten der ersten Gruppe und eine zweite Speichervorrichtung zum Speichern von Information in Bezug auf Information über den zweiten der Knoten und die Knoten der zweiten Gruppe.
  8. Digitalkommunikationssystem nach Anspruch 7, dadurch gekennzeichnet, dass die Knoten mit den Sendern und Empfängern verbundene Steuereinheiten haben zum Übertragen von Information zu einem Zentralknoten auf eine Änderung eines Knotens dahingehend, dass er sowohl in der ersten als auch der zweiten Gruppe ein Mitglied ist oder die Mitgliedschaft beendet.
  9. Verfahren in einem Digitalkommunikationssystem (601), welches Knoten (A, B, C, D, E, F) umfasst, wobei die Knoten einen Zentralknoten (F) und mindestens zwei periphere Knoten (A, B) einschließen, wobei Information nur direkt zwischen dem Zentralknoten und jedem der peripheren Knoten übertragen wird, der Zentralknoten die gesamte Kommunikation in dem System steuert und das System selbst und/oder die individuellen Knoten betreffende Information in dem Zentralknoten gespeichert ist (1180), dadurch gekennzeichnet, dass in dem Zentralknoten gespeicherte Information in Bezug auf das System und/oder die Knoten von dem Zentralknoten zu jedem peripheren Knoten übertragen wird.
  10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass ein Teil der zu jedem peripheren Knoten übertragenen Information von Information hergeleitet wird, die auf Anfrage des Zentralknotens von den peripheren Knoten dem Zentralknoten zugeführt wird.
  11. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass ein Teil der zu jedem peripheren Knoten übertragene Information von Information hergeleitet wird, die von den peripheren Knoten dem Zentralknoten zugeführt wird, veranlasst durch die peripheren Knoten, insbesondere ausgelöst durch ein Ereignis in dem jeweiligen peripheren Knoten.
  12. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass die Information insgesamt oder teilweise Adressinformation ist, die eine Adresse jedes der peripheren Knoten umfasst.
  13. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass die Information insgesamt oder teilweise kompatibilitätsbezogene Information ist.
  14. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass die gesamte direkte Übertragung von Information drahtlos ausgeführt wird, insbesondere unter Verwendung von Kurzbereichsfunkwellen.
  15. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass das Digitalkommunikationssystem ein Bluetooth-Pikonetz ist.
  16. Verfahren nach einem der Ansprüche 9–15, dadurch gekennzeichnet, dass die Übertragung der Information unter Verwendung eines Bluetooth-Rundsendemechanismus ausgeführt wird.
  17. Verfahren nach einem der Ansprüche 9–15, dadurch gekennzeichnet, dass die Übertragung der Information unter wechselweiser Verwendung des Bluetooth-Unicast-Systems zu jedem Peripherieknoten ausgeführt wird.
  18. Verfahren nach einem der Ansprüche 9–17, dadurch gekennzeichnet, dass die Übertragung der Information unter Verwendung des Bluetooth-LMP-Protokolls ausgeführt wird.
  19. Verfahren nach einem der Ansprüche 9–17, dadurch gekennzeichnet, dass das Übertragen der Information unter Verwendung einer Protokollschicht zwischen der L2CAP- und der Netzwerkschicht ausgeführt wird, wobei die Protokollschicht ein Netz geteilter Medien in Richtung der Netzschicht emuliert.
  20. Verfahren nach einem der Ansprüche 13–19, dadurch gekennzeichnet, dass das Übertragen der Information ausgeführt wird, wenn ein neuer peripherer Knoten zu dem Digitalkommunikationssystem hinzu kommt.
  21. Verfahren nach einem der Ansprüche 13–20, dadurch gekennzeichnet, dass wenn ein neuer peripherer Knoten zu dem System hinzu kommt, der Teil der alle der anderen peripheren Knoten betreffenden Information von dem Zentralknoten zu dem neuen Peripherieknoten übertragen wird.
  22. Verfahren nach einem der Ansprüche 9–20, dadurch gekennzeichnet, dass eine Meldung von dem zentralen Knoten zu allen peripheren Knoten übertragen wird, wenn einer der peripheren Knoten das System verlassen hat.
  23. Verfahren nach Anspruch 9, wobei ein erster der Knoten ein Haupt-Knoten der ersten Gruppe der Knoten ist, ein zweiter der Knoten ein Haupt-Knoten einer zweiten Gruppe der Gruppen ist, die ersten und zweiten der Knoten unterschiedliche Knoten sind und die Gruppe der ersten Knoten und die Gruppe der zweiten Knoten gemeinsam mit dem zweiten der Knoten einen gemeinsamen Knoten haben, und dieser Knoten ein Weiterleitungsknoten ist, dadurch gekennzeichnet, dass wenn ein Knoten seinen Zustand, ein Weiterleitungsknoten zu sein, ändert in einen Zustand, kein Weiterleitungsknoten zu sein oder umgekehrt, eine Meldung an alle Knoten in den ersten und zweiten Gruppen gesendet wird mit Ausnahme des Knotens selbst.
  24. Verfahren nach Anspruch 23, dadurch gekennzeichnet, dass die Meldung in den Haupt-Knoten der ersten und zweiten Gruppen gesendet wird.
  25. Verfahren nach Anspruch 23, dadurch gekennzeichnet, dass die Meldung von dem Knoten selbst gesendet wird.
  26. Verfahren nach Anspruch 23, dadurch gekennzeichnet, dass vor dem Senden der Meldung eine Information bezüglich der Änderung des Weiterleitungsknotenzustandes in dem Knoten von dem Knoten zu dem Haupt-Knoten der ersten Gruppe übertragen wird und zu dem Haupt-Knoten der zweiten Gruppe, vorausgesetzt, dass der Knoten nicht der Hauptknoten der zweiten Gruppe ist.
DE69923981T 1999-12-06 1999-12-06 Verfahren und Anordnung in einem Telekommunikationsnetz Expired - Fee Related DE69923981T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP99850192A EP1107516B1 (de) 1999-12-06 1999-12-06 Verfahren und Anordnungen in einem Telekommunikationsnetz

Publications (2)

Publication Number Publication Date
DE69923981D1 DE69923981D1 (de) 2005-04-07
DE69923981T2 true DE69923981T2 (de) 2006-03-16

Family

ID=8243779

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69923981T Expired - Fee Related DE69923981T2 (de) 1999-12-06 1999-12-06 Verfahren und Anordnung in einem Telekommunikationsnetz

Country Status (6)

Country Link
US (1) US20010002912A1 (de)
EP (1) EP1107516B1 (de)
AT (1) ATE290283T1 (de)
AU (1) AU1392001A (de)
DE (1) DE69923981T2 (de)
WO (1) WO2001043362A1 (de)

Families Citing this family (61)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8982856B2 (en) * 1996-12-06 2015-03-17 Ipco, Llc Systems and methods for facilitating wireless network communication, satellite-based wireless network systems, and aircraft-based wireless network systems, and related methods
US20080043675A1 (en) * 1998-05-29 2008-02-21 Research In Motion Limited System and Method for Redirecting Data to a Wireless Device Over a Plurality of Communication Paths
US6804232B1 (en) 2000-03-27 2004-10-12 Bbnt Solutions Llc Personal area network with automatic attachment and detachment
US6831896B1 (en) 2000-07-11 2004-12-14 Nokia Corporation Short range RF network
WO2002028052A2 (en) * 2000-09-28 2002-04-04 Koninklijke Philips Electronics N.V. Wireless network interface
US6920171B2 (en) * 2000-12-14 2005-07-19 Motorola, Inc. Multiple access frequency hopping network with interference anticipation
FI20002860A (fi) * 2000-12-27 2002-06-28 Nokia Corp Laiteroolit ja pikoverkkoyhteydet
KR100555664B1 (ko) * 2001-01-08 2006-03-03 삼성전자주식회사 무선 통신기기 및 이를 적용한 무선 통신시스템 및 그통신방법
GB2371449A (en) * 2001-01-22 2002-07-24 Nokia Mobile Phones Ltd Synchronizing a new device to a synchronized network of devices
US7177594B2 (en) * 2001-09-06 2007-02-13 Intel Corporation Controlling communications between devices within a mobile and ad hoc network
GB0102813D0 (en) * 2001-02-05 2001-03-21 Nokia Mobile Phones Ltd Exchange of information in Bluetooth
US7200130B2 (en) 2001-02-13 2007-04-03 Nokia Corporation Short range RF network configuration
US6973071B1 (en) * 2001-03-06 2005-12-06 Rfmd Wpan, Inc. Method and apparatus for controlling the flow of data in a wireless communication system
JP5105665B2 (ja) * 2001-03-13 2012-12-26 キヤノン株式会社 通信装置および制御方法、並びにプログラム
US7577451B2 (en) * 2001-04-04 2009-08-18 Intel Corporation Extending personal area networks
US6990316B2 (en) 2001-06-26 2006-01-24 Nokia Corporation Short range RF network configuration
US20030036408A1 (en) * 2001-08-17 2003-02-20 Johansson Lars Olof High-density radio access system
DE10141815A1 (de) * 2001-08-27 2003-04-03 Siemens Ag Verfahren zur Paketdatenübertragung
EP1425883A1 (de) * 2001-09-10 2004-06-09 Nokia Corporation Verfahren zum übertragen von zeitkritischer steuerungsinformation zwischen einzelnen netzwerkeinrichtungen in einem drahtlosen netzwerk unter verwendung von geschlitzten punkt-zu-punkt verbindungen
US20030069989A1 (en) * 2001-10-05 2003-04-10 Silvester Kelan C. Extending bluetooth personal area networks
CN100433673C (zh) * 2001-11-28 2008-11-12 自由度半导体公司 在多点协同无线网络之间通信的***和方法
US20030110291A1 (en) * 2001-12-12 2003-06-12 Nokia Corporation Method and device for route searching in a bluetooth ad-hoc network
US7499977B1 (en) * 2002-01-14 2009-03-03 Cisco Technology, Inc. Method and system for fault management in a distributed network management station
CA2416228C (en) * 2002-01-15 2010-07-13 Olsonet Communications Corporation Communication nodes for use with a wireless ad-hoc communication network
US7558953B2 (en) * 2002-01-18 2009-07-07 Telefonaktiebolaget L M Ericsson (Publ) Loading data into a mobile terminal
WO2003077480A1 (en) * 2002-03-12 2003-09-18 Nokia Corporation Method and device for wireless network formation
CN1656743A (zh) * 2002-05-31 2005-08-17 皇家飞利浦电子股份有限公司 无线网络中的信息路由
US20040078170A1 (en) * 2002-10-17 2004-04-22 Don Di Marzio System and method for monitoring a structure
US7808939B2 (en) * 2003-03-28 2010-10-05 Lenovo (Singapore) Pte Ltd. Routing in wireless ad-hoc networks
US8903385B2 (en) 2003-05-29 2014-12-02 Kyocera Corporation Wireless transmission system
US20050063419A1 (en) * 2003-07-25 2005-03-24 Schrader Mark E. Method of creating, controlling, and maintaining a wireless communication mesh of piconets
US20050243765A1 (en) * 2003-07-25 2005-11-03 Schrader Mark E Mesh network and piconet work system and method
KR100547788B1 (ko) * 2003-07-31 2006-01-31 삼성전자주식회사 피코넷들의 디바이스들 간의 통신이 가능한 고속 개인용무선 네트워크 및 데이터 전송 방법
US7468969B2 (en) * 2003-11-07 2008-12-23 Interdigital Technology Corporation Apparatus and methods for central control of mesh networks
US7133373B2 (en) * 2003-12-19 2006-11-07 Motorola, Inc. Wireless network with improved sharing of high power consumption tasks
JP4266165B2 (ja) * 2003-12-19 2009-05-20 株式会社東芝 通信装置および通信制御プログラム
WO2005065035A2 (en) * 2004-01-08 2005-07-21 Wisair Ltd. Distributed and centralized media access control device and method
US8639819B2 (en) * 2004-02-05 2014-01-28 Nokia Corporation Ad-hoc connection between electronic devices
KR20070026413A (ko) * 2004-03-08 2007-03-08 코닌클리케 필립스 일렉트로닉스 엔.브이. 무선 ａｄ－ｈｏｃ 네트워크들에서 동적 네트워크 결합
US7907898B2 (en) * 2004-03-26 2011-03-15 Qualcomm Incorporated Asynchronous inter-piconet routing
SE0401574D0 (sv) * 2004-06-18 2004-06-18 Henrik Ehrnlund Trådlöst sensornätverk
ATE520222T1 (de) * 2004-06-24 2011-08-15 Ericsson Telefon Ab L M Verfahren und protokoll zur verwaltung von einrichtungen in einem persönlichen netzwerk
CN100542113C (zh) * 2004-09-29 2009-09-16 皇家飞利浦电子股份有限公司 网络阵列、转发器设备及操作转发器设备的方法
DE102004047370A1 (de) * 2004-09-29 2006-03-30 Siemens Ag Verfahren zum Betreiben eines ad-hoc-Kommunikationsnetzwerks und entsprechende Vorrichtung
KR100757260B1 (ko) * 2004-12-14 2007-09-11 전자부품연구원 개인 무선 네트워크에서 스캐터넷 구현 방법
US7460511B2 (en) * 2004-12-23 2008-12-02 Nokia Corporation Device connectivity
US7773569B2 (en) * 2005-05-19 2010-08-10 Meshnetworks, Inc. System and method for efficiently routing data packets and managing channel access and bandwidth in wireless multi-hopping networks
US7639652B1 (en) * 2005-09-28 2009-12-29 Rockwell Collins, Inc. Inter-channel bridge node communications protocol for TDMA networks
US7394366B2 (en) 2005-11-15 2008-07-01 Mitel Networks Corporation Method of detecting audio/video devices within a room
US9351132B2 (en) * 2005-12-15 2016-05-24 Telefonaktiebolaget Lm Ericsson (Publ) Event notification in a half duplex communication environment
US20080127223A1 (en) * 2006-06-27 2008-05-29 Christian Zechlin System and method for communications operations
US8229427B2 (en) 2006-07-14 2012-07-24 Qualcomm Incorporated Status validation for terminals in a wireless communication system
DE102007004386B4 (de) * 2007-01-29 2015-10-08 Intel Mobile Communications GmbH Ad-hoc-Kommunikationsnetzwerk, Ad-hoc-Kommunikationsnetzwerk-Speicherverwaltungseinheit, Ad-hoc-Kommunikationseinrichtung, Verfahren zum Betreiben eines Ad-hoc-Kommunikationsnetzwerks, Verfahren zum Betreiben einer Ad-hoc-Kommunikationseinrichtung
GB0725052D0 (en) * 2007-12-21 2008-01-30 Fujitsu Lab Of Europ Ltd Communications system
US20090270036A1 (en) * 2008-04-29 2009-10-29 Microsoft Corporation Wireless Pairing Ceremony
KR101598886B1 (ko) * 2009-10-13 2016-03-03 삼성전자주식회사 이동통신 단말기에서 무선랜을 이용한 피어투피어 연결 방법 및 장치
JP5782698B2 (ja) 2009-11-20 2015-09-24 ソニー株式会社 通信装置、プログラム、および通信方法
CN104041067B (zh) * 2012-10-10 2018-04-20 松下电器（美国）知识产权公司 通信装置、通信***、移动终端、记录介质以及服务器
US20150281943A1 (en) * 2012-10-16 2015-10-01 Nec Casio Mobile Communications, Ltd. Communication terminal, communication system, method for controlling communication terminal, and program
JP6372594B2 (ja) * 2017-06-02 2018-08-15 ソニー株式会社 情報処理装置、および情報処理方法
WO2022164430A1 (en) * 2021-01-28 2022-08-04 Hewlett-Packard Development Company, L.P. Peripheral electronic device representation via uniform transmission protocol

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6282572B1 (en) * 1994-05-04 2001-08-28 Telefonaktieboalget Lm Ericsson (Publ) Providing a master device with slave device capability information
CA2129197C (en) * 1994-07-29 1999-11-09 Roger Y.M. Cheung Method and apparatus for connecting a wireless lan to a wired lan
JP3349861B2 (ja) * 1995-03-17 2002-11-25 富士通株式会社 ワイヤレスｌａｎシステム
US5768531A (en) * 1995-03-27 1998-06-16 Toshiba America Information Systems Apparatus and method for using multiple communication paths in a wireless LAN
US6088591A (en) * 1996-06-28 2000-07-11 Aironet Wireless Communications, Inc. Cellular system hand-off protocol
US6590928B1 (en) * 1997-09-17 2003-07-08 Telefonaktiebolaget Lm Ericsson (Publ) Frequency hopping piconets in an uncoordinated wireless multi-user system
US6691173B2 (en) * 1999-07-06 2004-02-10 Widcomm, Inc. Distributed management of an extended network containing short-range wireless links
US6683886B1 (en) * 1999-10-19 2004-01-27 Koninklijke Philips Electronics N.V. Bluetooth communication units, wireless communication systems, wireless communication devices, bluetooth communications methods, and wireless communication methods
US20010033554A1 (en) * 2000-02-18 2001-10-25 Arun Ayyagari Proxy-bridge connecting remote users to a limited connectivity network
US6622018B1 (en) * 2000-04-24 2003-09-16 3Com Corporation Portable device control console with wireless connection
US7146636B2 (en) * 2000-07-24 2006-12-05 Bluesocket, Inc. Method and system for enabling centralized control of wireless local area networks

Also Published As

Publication number Publication date
AU1392001A (en) 2001-06-18
DE69923981D1 (de) 2005-04-07
EP1107516B1 (de) 2005-03-02
ATE290283T1 (de) 2005-03-15
WO2001043362A1 (en) 2001-06-14
US20010002912A1 (en) 2001-06-07
EP1107516A1 (de) 2001-06-13

Similar Documents

Publication Publication Date Title
DE69923981T2 (de) Verfahren und Anordnung in einem Telekommunikationsnetz
DE60202491T2 (de) Verfahren und System zum Steuern eines Kommunikationsnetzes und eines im Netz angewandten Routers
DE60219932T2 (de) Ssystgem und Verfahren zur Verwendung von Algorithmen und Protokollen zur optimierung von CSMA-Protokollen (Carrier Sense Multiple Access) in drahtlosen Netzwerken
DE60224212T2 (de) Netzwerk mit mehreren sub-netzwerken
EP0996257B1 (de) Netzwerk mit Brücken-Terminal zur Übertragung von Daten zwischen mehreren Sub-Netzwerken
EP1226692B1 (de) Verfahren zum betreiben eines mobilfunknetzes
DE60130418T2 (de) Verfahren und gerät um ein digitales, drahtloses kommunikationssystem mit verteilter architektur zur verfügung zu stellen
DE102006061879B4 (de) System und Verfahren zur Verbesserung von WiFi-Realzeit-Kommunikationen
DE602005005122T2 (de) Vertikales sanftes Weiterreichen in drahtlosen Netzen
DE10053809A1 (de) Adhoc-Netzwerk mit mehreren Terminals zur Bestimmung von Terminals als Controller von Sub-Netzwerken
DE19752697A1 (de) Drahtloses lokales Netzwerk mit Controller und wenigstens einem als Controller einsetzbaren Terminal
WO2002067492A1 (de) Netzwerk mit einer anpassung des modulationsverfahrens
EP0833542B1 (de) Lokales Netzwerk mit Sende- und Empfangsvorrichtung
DE10001608A1 (de) Verfahren zum Betreiben eines Mobilfunknetzes
DE69938350T2 (de) Verteilter verbindungsmechanismus für ein vhf-netzwerk
EP1187397B1 (de) Neukonfigurierung eines Adhoc-Netzwerks
DE10053854A1 (de) Netzwerk mit mehreren Sub-Netzwerken zur Bestimmung von Brücken-Terminals
AT508676B1 (de) Drahtloses telekommunikationssystem zur vernetzung ortsfester objekte
DE19848342A1 (de) Lokales Netzwerk mit einem Brücken-Terminal zur Übertragung von Daten zwischen mehreren Sub-Netzwerken und zur Schleifendetektion
DE10122044A1 (de) Netzwerk mit über Brücken-Terminals verbindbaren Sub-Netzwerken
EP0831620A2 (de) Lokales Netzwerk mit zur Funkübertragung vorgesehenen Terminals
EP0996259B1 (de) Automatische Konfigurierung eines Brücken-Terminals zur Uebertragung von Daten zwischen mehreren Sub-Netzwerken in einem lokalen Netzwerk
DE60019474T2 (de) Leitweglenkungsverfahren in einem Intranetzwerk mit sehr niedriger Bandbreite
DE19636394A1 (de) Lokales, nach dem asynchronen Transfermodus arbeitendes Netzwerk in Ringstruktur mit drahtlosen Terminals
DE60025757T2 (de) Funkkommunikationsvorrichtung und -verfahren

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee