DE60213010T2

DE60213010T2 - Verfahren und vorrichtung zum herstellen eines l2cap-kanals, der fest für die datenflussübertragung in bluetooth-netzwerken zugewiesen ist

Info

Publication number: DE60213010T2
Application number: DE60213010T
Authority: DE
Inventors: Sander Van Valkenburg
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2002-05-15
Filing date: 2002-05-15
Publication date: 2007-07-05
Anticipated expiration: 2022-05-16
Also published as: EP1504572B1; AU2002302879A1; TWI240511B; MY135240A; TW200402215A; WO2003098881A1; DE60213010D1; EP1504572A1; US20050261007A1

Description

Die vorliegende Erfindung bezieht sich allgemein auf die Datenübertragung in Netzen. Sie bezieht sich auch auf drahtlose persönliche Gebietsnetze (personal area networks, PAN). Insbesondere bezieht sich die Erfindung auf ein einfaches Verfahren, um die Datenübertragung von Datenflüssen in einem Bluetooth-Netz zu optimieren. Zusätzlich Information über lokale drahtlose Vernetzungen können von http://www.bluetooth.org herabgeladen werden.
Aktuell ist die IP-(Internet-Protokoll)-Vernetzung über Bluetooth definiert durch das Bluetooth-PAN-Profil. Das PAN-Profil emuliert eine Ethernet-Schnittstelle zum IP durch BNEP (Bluetooth-Netz-Verkapselungs-Protokoll). Eine BNEP-Verbindung wird durch einen spezifischen, festen Protokoll/Dienst-Multiplexer-(PSM)-Wert identifiziert (siehe http.//www.bluetooth.org/assigned-numbers(12/cap.htm). Es ist spezifiziert, dass nur eine BNEP-Verbindung zwischen zwei Vorrichtungen bestehen kann, was (aktuell) bedeutet, dass nur eine L2CAP-(Logisches-Link-und-Adaptions-Protokoll)-Verbindung mit dem reservierten PSM-Wert für BNEP existieren kann. BNEP multiplext allen BNEP-Verkehr (und somit IP-Verkehr) über einen logischen (L2CAP) Kanal gemäß dem Logischen-Link-Steuer-und-Adaptionsprotokoll (L2CAP). Bluetooth liefert eine Dienstgüte-(QoS)-Unterscheidung oben auf dem L2CAP, das heißt L2CAP-Kanäle können mit spezifischen QoS-Parametern konfiguriert werden. Aktuell ist eine Priorisierung von IP-Paketen innerhalb des PAN-Profils möglich durch die Verwendung von Prioritätskennzeichnungen in BNEP-Paketen gemäß der Spezifikation IEEE 802.1p (Teil der Spezifikation IEEE 802.1d). Dies erlaubt eine relative Priorisierung von IP-Paketen über eine L2CAP-Verbindung für BNEP. Tatsächlich verwendet BNEP nur einen L2CAP-Kanal zwischen einem Paar von Vorrichtungen, so dass aktuell eine Unterscheidung verschiedener IP-Flüsse über BNEP nicht möglich ist.
Die Dienstgüte wird eine andere Bedeutung erfahren, wenn Netze kompatibel zum Partnerschaftsprojekt der 3. Generation (3GPPP), Ausgabe 5, ein Internet-Multimedia-Untersystem (IMS) enthalten werden. Wenn ein Mobilendgerät (MT) eine IMS-Anschlussmöglichkeit zu einer Endgerätausrüstung (TE), wie einem Notebook oder einem persönlichen digitalen Assistenten (PDA), unter Verwendung von Bluetooth liefert, können mehrere IP-Verbindungen über dieselbe Bluetooth-Verbindung gemultiplext werden. Um die QoS-Erfordernisse solcher IP-Verbindungen für das Zugreifen auf Multimediadienste (wie sie beispielsweise durch IMS geliefert werden) zu erfüllen, müssen Pakete, die zu solchen IP-Verbindungen gehören, getrennt auch auf niedrigeren Bluetooth-Schichten gehandhabt werden. Auf diese Weise können die Erfordernisse der spezifische Verzögerungszeit und/oder Bandbreite erfüllt werden, und sie werden von Best-Effort-Verkehr, wie einem Webbrowsing, das auch auf derselben Bluetooth-Verbindung stattfinden kann, unterschieden. Zusätzlich zum Zugreifen auf Multimediananwendungen durch ein zellulares Netz, können Bluetooth-Vorrichtungen, die an Adhoc-Netzen teilnehmen, auch Host-Anwendungen sein, die eine spezielle QoS-Handhabung erfordern.
Ein Dokument, das sich auf die Übertragung von Daten über Bluetooth-Verbindungen bezieht, ist das Dokument US 2002044540 , das ein Verfahren für das effiziente Ausbilden eines Scatter-Netzes beschreibt. Dieses Dokument bezieht sich auf die Auswahl eines Übertragungspfades durch ein Scatter-Netz, das durch eine Anzahl von Pico-Netzen gebildet wird. Dieses Dokument lehrt das Aufbauen reservierter Scatter-Netze für die Datenübertragung zwischen Vorrichtungen, die zu verschiedenen Pico-Netzen gehören, um die Anzahl von Teilstrecken im Datenübertragungspfad zu reduzieren.
Aktuell weist das PAN-Profil eine Begrenzung auf einen L2CAP-Kanal für die BNEP-Verbindung zwischen einem Paar von PAN-ermöglichenden Vorrichtungen auf. Dies schränkt die Differenzierung von Datenflüssen über eine Bluetooth-PAN-Verbindung und somit eine einzelne Basisbandverbindung ein. Es schränkt auch die Ressourcenreservierung für Flüsse mit im Konflikt stehenden QoS-Parametern ein.
Somit würde es wünschenswert sein, einen Mechanismus für das Abbilden von vom Datenfluss abhängigem QoS-Verhalten auf Bluetooth-L2CAP-Kanäle durch BNEP zu haben, um eine Ressourcenreservierung und/oder Priorisierung für den Datenfluss zu ermöglichen.
Es ist weiter wünschenswert, die aktuellen Bluetooth-Protokolle (BNEP und L2CAP) zu verbessern, um mehrfache Basisbandverbindungen zwischen einem Paar von Bluetooth-Vorrichtungen zu ermöglichen und zu verbessern.
Gemäß einer ersten Ausführungsform der vorliegenden Erfindung wird ein Verfahren für das Übertragen von Datenflüssen oder Signalen über eine Bluetooth-Verbindung zwischen zwei Vorrichtungen gemäß dem Bluetooth-Netz-Verkapselungs-Protokoll (BNEP) geliefert. Der Datenfluss wird zusätzlich zu anderen Datenflüssen auf der BNEP-Verbindung übertragen. Das Verfahren umfasst die Operation einer Erkennung eines zu übertragenden Datenflusses, und ist gekennzeichnet durch das Erkennen und/oder Bestimmen eines Dienstgüteerfordernisses dieses Datenstroms und das Aufbauen eines (Logischen-Link-Steuerungs- und Apdaptions)-Protokoll-(L2CAP)-Kanals, der für diesen Datenfluss reserviert ist, der mindestens das bestimmte Erfordernis der Dienstgüte erfüllt.
Ein Aspekt der Erfindung kann beispielsweise durch das Beispiel eines IP-Flusses erläutert werden. Die Hauptidee dieses Beispiels besteht darin, einen L2CAP-Kanal für einen IP-Fluss aufzubauen, wenn man den Fluss aufbaut. Dieser Fluss existiert gemeinsam mit anderen L2CAP-Kanälen, die die Haupt-BNEP-Verbindung einschließen. Im Bluetooth-PAN-Profil wird der IP-Verkehr auf die BNEP-Verbindung abgebildet. Somit sind die zusätzlichen L2CAP-Kanäle für spezifische IP-Flüsse Teil der BNEP-Verbindung zwischen den zwei Vorrichtungen. Die vorliegende Erfindung liefert auch ein Rahmenwerk für das Abbilden von IP-basierten QoS-Mechanismen auf Bluetooth-spezifische QoS-Mechanismen.
Der Aufbau des Datenflusses wird unter Verwendung von BNEP-Steuerungspaketen signalisiert, um anzuzeigen, welcher Fluss zu dem L2CAP-Kanal gehört, um die Quelle und das Ziel des Flusses in der Bluetooth-Ebene anzuzeigen, und um die QoS-Parameter für die L2CAP-Verbindung auszuhandeln. Die Erfindung überwindet die aktuelle Beschränkung des PAN-Profils, das nur einen L2CAP-Kanal für die BNEP-Verbindung zwischen einem Paar PAN-ermöglichenden Vorrichtungen liefert. Dies schränkt die Differenzierung von IP-Flüssen über eine Bluetooth-PAN-Verbindung und somit eine einzelne Basisbandverbindung ein. Es schränkt auch die Ressourcenreservierung für Flüsse mit im Konflikt stehenden QoS-Parametern ein.
Die Erfindung kann verstanden werden durch die Errichtung mehrer unterschiedlicher L2CAP-Verbindungen zwischen zwei Bluetooth-Vorrichtungen, um fähig zu sein, eine Dienstgüte (QoS) zu liefern, die für gewisse Typen von Datenflüssen reserviert ist. Im Unterschied zum aktuellen Stand der Technik, bei dem alle Daten über einen einzigen L2CAP-Kanal zeit-gemultiplext werden, werden mehrere L2CAP-Verbindungen zwischen verschiedenen Vorrichtungen aufgebaut, um verschiedene QoS-Parameter anzubieten. So wird statt dem Anbieten eines gewissen Datenübertragungsplans beim Übertragen unterschiedlicher Datenflüsse über einen einzigen Kanal für jeden Datenfluss ein einzelner kundenspezifischer Kanal aufgebaut, um die QoS-Parameter für jeden Datenfluss gewähren zu können. Es sei angemerkt, dass die Anzahl von Datenflüssen und/oder L2CAP-Kanälen im Prinzip nicht beschränkt ist, wobei aber die gesamte QoS durch die physikalische Schicht der Bluetooth-Verbindung beschränkt sein kann.
Es sein weiter angemerkt, dass es im Stand der Technik keine spezifische Lösung für das Aufbauen von L2CAP-Kanälen für spezifische IP-QoS-Flüsse durch BNEP gegeben hat. Noch hat der Stand der Technik eine spezifische Lösung für das Reservieren von Ressourcen auf einer Verbindungsschicht für mehr als einen Fluss anders als durch ein Anhäufen der QoS-Parameter angeboten, das heißt, es hat keinen Weg gegeben, Verbindungsschichtressourcen unabhängig für unabhängige Flüsse zu reservieren und aufrecht zu halten.
Es sei weiter angemerkt, dass die Verbindung zwischen solchen Vorrichtungen oder Anwendungen über eine einzelne Bluetooth-Verbindung stattfinden kann, oder dass sie das Weitergeben von Datenpaketen erfordert, so dass ein korrektes Handhaben der Verbindung für mehrere Bluetooth-Verbindungen in einer Verbindung einer Ende-zu-Ende-Anwendung notwendig ist.
Im Gegensatz zur vorliegenden Erfindung liefert das Priorisierungsschema von 802.1p keinen Mechanismus für das Aufbauen von flusspezifischen Kanälen, noch liefert es irgend eine Vorwegnahme von 2P-QoS-Flüssen (beispielsweise eine Bandbreitenreservierung, eine Spezifikation von Erfordernissen einer minimalen Verzögerung). Bluetooth bietet eine Ressourcenzuweisung für L2CAP-Kanäle mit spezifischen QoS-Parametern, aber aktuell erlaubt ein BNEP des Stands der Technik nur einem L2CAP-Kanal (für BNEP) zwischen einem Paar Bluetooth-Vorrichtungen. Die vorliegende Erfindung bietet den Vorteil des Aufbaus von reservierten L2CAP-Kanälen für spezifische IP-Flüsse oder Verkehrsklassen, während dennoch das Konzept einer BNEP-Verbindung aufrecht gehalten wird, indem es eine Steuerung über die zusätzlichen Verbindungen durch BNEP ermöglicht. Die Erfindung liefert auch ein Rahmenwerk für das Abbilden von IP-basierten QoS-Mechanismen auf Bluetooth-QoS-Mechanismen.
Die vorliegende Erfindung führt die Möglichkeit ein, zusätzliche L2CAP-Verbindungen für spezifische IP-Flüsse aufzubauen. Jede solche L2CAP-Verbindung wird mit einem dynamisch zugewiesenen PSM-Wert (der in einem Bereich von 0x1001 – 0xFFFF liegt) identifiziert. Dieser L2CAP-Kanal ist mit einem spezifischen Fluss oder Flüssen, für den er aufgebaut wurde, verbunden. Pakete, die zu diesem Fluss gehören, werden durch einen Flussbezeichner höherer Ebene oder einen Paketbezeichner identifiziert (beispielsweise die IP-Flussmarkierung, die Quellen- und Zieladressen und die Anschlussnummern oder die 802.1p-Prioritätskennzeichnung. Der L2CAP-Kanal ist mit spezifischen QoS-Parametern konfiguriert, die die Forderung des IP-Flusses erfüllen. Die Information für das Aufbauen dieses spezifischen L2CAP-Kanals wird unter Verwendung von BNEP-Signalisierpaketen ausgetauscht. Diese Information besteht mindestens aus dem dynamischen PSM-Wert, dem Typ und dem Wert der Identifikation von Paketen, die zum Fluss gehören, und dem Satz von QoS-Parametern für den L2CAP-Kanal. Auch kann der neu errichtete L2CAP-Kanal frei von Steuerpaketen gehalten werden. Zusätzlich behält das BNEP die Kontrolle über die Errichtung der L2CAP-Kanäle.
Vorzugsweise wird eine Steuerungssignalisierung, die für das Aufbauen dieses logischen Kanals und das Betreiben/Aufrechthalten dieses logischen Kanals notwendig ist, über die Datenverbindung mit dem Bluetooth-Netz-Verkapselungsprotokoll (BNEP) übertragen. Im Gegensatz zum einfachen Erzeugen eines zusätzlichen L2CAP-Kanals für einen erkannten Datenfluss, was einfach dem Aufbauen eines neuen L2CAP-Kanals oder einer zusätzlichen Bluetooth-Verbindung entsprechen würde, wird die Steuerungssignalisierung für den neuen L2CAP weiter über die BNEP-Verbindung übertragen. Somit kann der neu aufgebaute L2CAP-Kanal frei von Steuerpaketen gehalten werden. Zusätzlich behält das BNEP die Steuerung über die Errichtung von L2CAP-Kanälen. Statt dem Anbieten eines gewissen Datenübertragungsplanes für das Übertragen verschiedener Datenflüsse über einen einzelnen Kanal wird für jeden Datenfluss ein einzelner kundenspezifischer Kanal errichtet, um fähig zu sein, die QoS-Parameter für jeden Datenfluss zu gewähren, während der "administrative" Signalisierungsverkehr über die Standard-BNEP-Verbindung übertragen wird. Dies führt zu einer Trennung des Datenflusses vom Signalisierungsverkehr des L2CAP-Kanals, der für diesen Datenfluss reserviert ist.
Vorteilhafterweise umfasst diese Steuerungssignalisierung weiter das Identifizieren des Datenflusses. Die Identifikation kann die Basisinformation einschließen, wie die Adresse des Datenflusses, aber sie kann natürlich auch die Identifikation der Protokoll/Dienst-Multiplexer-(PSM)-Werte des IP-Flusses einschließen, da eine BNEP-L2CAP-Verbindung durch einen spezifischen festen PSM-Wert identifiziert wird.
Vorzugsweise umfasst die Steuerungssignalisierung die Übertragung von Dienstgüteparametern gemäß den Erfordernissen der Dienstgüte. Dies dient nur, um hervorzuheben, dass die Steuerpakete, die über die BNEP-Verbindung übertragen werden, auch die QoS-Parameter enthalten, die vom L2CAP-Kanal erfüllt werden müssen.
Vorteilhafterweise umfasst das Verfahren weiter das Auswerten der geforderten Dienstgüte. Es sein angemerkt, dass der QoS-Wert des Datenflusses und der QoS-Wert der BNEP-Verbindung/des L2CAP-Kanals unterschiedlich sein können, da die Datenraten beispielsweise in Bezug zum Paketdatenstrom oder zur Netzdatenrate stehen. Es kann sein, dass die QoS-Erfordernisse umgewandelt werden müssen, um die geforderte Netz-QoS in jedem Teil der Übertragung zu gewähren. Die Auswertung kann sogar zusätzliche Information, beispielsweise von benachbarten Übertragungskanälen, verwenden, um beispielsweise eine vorbestimmte Gesamt-QoS beispielsweise für eine Mehrteilstreckenverbindung zu liefern. Ein Schritt der Auswertung des geforderten QoS-Wertes kann helfen, zu entscheiden, ob ein zugewiesener L2CAP-Kanal erforderlich ist oder nicht. So wird gemäß der Auswertung ein L2CAP-Kanal aufgebaut oder anderem Datenverkehr über die BNEP-Verbindung zugewiesen. Diese Auswertung kann eine Überwachung des Datenverkehrs der BNEP-Verbindung einschließen, um die Anzahl der verwendeten L2CAP-Kanäle zu optimieren.
Vorzugsweise umfasst das Aufbauen des L2CAP-Kanals das Aushandeln der Dienstgüte zwischen den zwei Vorrichtungen. Als illustrierendes Beispiel der vorliegenden Erfindung existiert eine BNEP-Verbindung zwischen zwei Bluetooth-Vorrichtungen, und eine der Vorrichtungen wünscht eine Verbindungsressource für eine spezifische (IP)-Anwendung für eine einstückige (Bluetooth)-Verbindung zu reservieren.
Die Vorrichtung schickt die folgenden Daten an die Partnervorrichtung:

– Quelle und Ziel des QoS-Flusses (innerhalb der Bluetooth-Ebene)
– vorgeschlagener PSM-Wert (aus dem Bereich der PSMs, die dynamisch zugewiesen werden können);
– eine Flussidentifikation der höheren Ebene [beispielsweise 802.1p oder Diffserv-Verkehrsklasse (Differenzierte Dienste), Intserv (Integrierte Dienste) Verbindungsidentifikation (Quelle- und Ziel-IP-Adressen und Anschlussnummern), IP-Flusskennzeichnung, etc.];
– L2CAP QoS-Parameter.

Die Signalisierungsinformation wird in einem spezifischen BNEP-Signalisierungspaket oder einem Erweiterungskopfteil befördert. Die Partnervorrichtung kann mit einer Bestätigung dieser Parameter antworten oder alternative Werte vorschlagen (für die QoS-Parameter) oder die Anforderung zurückweisen. Wenn eine Bestätigung erfolgt, wird ein L2CAP-Kanal aufgebaut und konfiguriert unter Verwendung der ausgehandelten QoS-Paramter, und nachfolgend werden alle Pakete, die zum QoS-Fluss gehören, über den neu aufgebauten L2CAP-Kanal gesendet. Die Pakete werden als normalen BNEP-Pakete gesendet, die der BNEP-Spezifikation entsprechen. Jedes Paket, das über die L2CAP-Kanal gesendet wird, trägt die Identifikation, die im Signalisierungspaket angezeigt ist.
Es sein angemerkt, dass die Aushandlung der QoS-Parameter zu einer L2CAP-Verbindung mit höheren oder besseren QoS-Parameter, als sie gefordert sind, führt, wenn beispielsweise der aktuelle Datenverkehr zwischen den zwei Vorrichtungen dies erlaubt. Es sei ferner angemerkt, dass die vorliegende Erfindung mit Verfahren kombiniert werden kann, um den Datenverkehr in Bluetooth-Pico-Netzen oder in Scatter-Netzen zu optimieren, da alle QoS-Erfordernisse über eine einzelne BNEP-Verbindung übertragen werden, so dass es nicht notwendig ist, die gesamten QoS-Erfordernisse Bit um Bit zu bestimmen.
Gemäß der Erfindung umfasst das Verfahren weiter die Übertragung dieses Datenflusses über die reservierte L2CAP-Verbindung.
Vorzugsweise ist dieser Datenfluss ein Internet-Protokoll-(IP)-Datenfluss. Im Fall mehrere L2CAP-Kanäle zwischen zwei Bluetooth-Vorrichtungen oder sogar mehrerer Basisbandverbindungen zwischen zwei Bluetooth-Vorrichtungen, haben verschiedene L2CAP-Kanäle (und möglicherweise Basisbandverbindungen) unterschiedliche QoS-Parameter in Abhängigkeit von den QoS-Erfordernissen ihrer jeweiligen Datenflüsse.
Vorzugsweise werden die Datenpakete dieses auf dem Internet basierenden Datenflusses auf den L2CAP-Kanal auf der Basis von den Bezeichnern dieser Datenpakete abgebildet. Dies ermöglicht eindeutiges Abbilden der IP-Datenpakete auf den L2CAP-Kanal, was das Abbilden des Datenflusses vom IP auf den L2CAP vereinfacht. Es sei angemerkt, dass dies auch umgekehrt betrieben werden kann, um eine richtiggehende bidirektionale Datenübertragung zwischen dem Datenfluss und dem L2CAP-Kanal, beispielsweise zwischen dem Internet und einem Pico-Netz zu liefern.
Vorteilhafterweise wird dieses QoS-Erfordernis aus einer Gruppe ausgewählt, die die spezifische Verzögerungszeit, Verzögerung, Fehlerrate, Datenrate, Priorität, Paketlänge, Nutzlastlänge, Paketreihenfolge und Bandbreite umfasst. Die Spezifikation der QoS-Parameter und die QoS-Parameter selbst hängen von der Eigenschaft des Datenflusses ab. Der Ausdruck "spezifische Verzögerungszeit" beschreibt einen Wert einer mittleren Verzögerung von Paketen, die Verzögerung beschreibt gewöhnlicherweise ein konstantes Aufhalten von Datenpaketen während der Übertragung.
Gemäß einer anderen Ausführungsform der vorliegenden Erfindung wird dieser Datenfluss über mehr als eine einzelne Bluetooth-Verbindung übertragen. Der Datenfluss kann über mehr als einen L2CAP-Kanal für jede BNEP-Verbindung übertragen werden. Der Datenfluss kann über mehr als eine Bluetooth-Vorrichtung mittels der Anzeige der Quellen- und Zieladressen (auf BNEP-Ebene) des Flusses übertragen werden. Somit kann in Scatter-Netzen eine Mehrteilstreckenverbindung über mehrere Bluetooth-Vorrichtungen aufgebaut werden, um die QoS-Erfordernisse zu erfüllen.
Eine andere Ausführungsform der vorliegenden Erfindung liefert ein Computerprogrammwerkzeug, das Programmkodemittel für das Ausführen des Verfahrens für das Übertragen von Datenflüssen zwischen Bluetooth-Vorrichtungen, die über eine BNEP-Datenverbindung verbunden sind, auf zugewiesenen L2CAP-Kanälen umfasst. Das Softwarewerkzeug umfasst Programmkodemittel für das Ausführen aller Schritte, die in der vorangehenden Beschreibung angegebenen wurden, wenn das Programm auf einem Computer oder einer Netzvorrichtung zum Ablauf gebracht wird.
Gemäß einer nochmals anderen Ausführungsform der Erfindung wird ein Computerprogramm geliefert. Das Computerprogramm umfasst Programmkodemittel, die auf einem computerlesbaren Medium gespeichert sind, für das Ausführen des Verfahrens für die Übertragung von Datenflüssen zwischen zwei Bluetooth-Vorrichtungen, die über eine BNEP-Datenverbindung verbunden sind. Die Ausführung des Programms auf einem Computer oder einer Netzvorrichtung führt zu einem Aufbau der zugewiesenen L2CAP-Kanäle, die den Datenflüssen zugewiesen sind, gemäß der vorangehenden Beschreibung.
Gemäß einer nochmals anderen Ausführungsform der Erfindung wird ein Computerprogrammprodukt geliefert, das Programmkodemittel umfasst, die auf einem computerlesbaren Medium gespeichert wird, für das Ausführen des Verfahrens für das Übertragen von Datenflüssen zwischen zwei Bluetooth-Vorrichtungen, die über eine BNEP-Datenverbindung verbunden sind, gemäß der vorangehenden Beschreibung, wenn das Programmprodukt auf einem Computer oder einer Netzvorrichtung zum Ablauf gebracht wird.
Gemäß einer anderen Ausführungsform der vorliegenden Erfindung wird eine Netzvorrichtung für das Übertragen von mindestens einem Datenfluss oder Signals über eine Bluetooth-Verbindung zwischen zwei Netzvorrichtungen geliefert. Die Bluetooth-Verbindung entspricht dem Bluetooth-Netz-Verkapselungsprotokoll (BNEP). Die Vorrichtung umfasst eine Komponente für das Erkennen von mindestens einem Datenfluss, der zu übertragen ist, und sie ist gekennzeichnet durch eine Komponente für das Erkennen eines Dienstgüte-(QoS)-Erfordernisses des mindestens einen Datenflusses und eine Komponente für das Aufbauen eines logischen (L2CAP)-Kanals, der für diesen Datenfluss reserviert ist, wobei der Kanal ein Logisches-Link-Steuerungs-und-Adpations-Protokoll liefert, wobei der Kanal mindestens das erkannte Dienstgüte-(QoS)-Erfordernis erfüllt. Die Vorrichtung überträgt den mindestens einen Datenfluss gemäß dem Verfahren, das in der vorangehenden Beschreibung angegeben ist, wobei für jeden Datenfluss ein reservierter L2CAP-Kanal für die Datenübertragung verwendet wird.
Nachfolgend wird die Erfindung im Detail unter Bezug auf die angefügten Zeichnungen beschrieben.
1 ist ein Flussdiagramm einer konventionellen Übertragung zweier unterschiedlicher Datenflüsse von einer Bluetooth-Vorrichtung zu einer anderen über einen einzigen L2CAP-Kanal, und
2 ist ein Beispiel einer Übertragung zweier unterschiedlicher Datenflüsse von einer Bluetooth-Vorrichtung zu einer anderen gemäß einem Aspekt der vorliegenden Erfindung.
3 ist ein Beispiel einer Bluetooth-Piconetz-Mehrteilstrecken-Anwendung gemäß einer Ausführungsform der vorliegenden Erfindung.
4 ist ein anderes Beispiel einer Kommunikation zwischen einem Host in einem Netz und einem Piconetz-Nutzer über einen Netzzugangspunkt gemäß einer anderen Ausführungsform der vorliegenden Erfindung, und
5 zeigt eine Situation einer Mehrteilstrecken-Bluetooth-Verbindung zu einem Internet-Host über einen Netzzugangspunkt.
1 zeigt eine konventionelle Datenübertragung von einer Bluetooth-Vorrichtung zu einer anderen. Im Bild sind zwei Bluetooth ermöglichende Vorrichtungen 2 und 4 dargestellt. Die Vorrichtungen 2, 4 sind im wesentlichen ähnlich und lassen jeweils zwei unterschiedliche Anwendungen 6, 10 und 8, 12 ablaufen. Im Fall der Standarddatenübertragung werden die Datenflüsse beider Anwendungen 6, 10 und 8, 12 zur L2CAP-Schicht mit im wesentlichen demselben Verbindungsverwaltungsprotokoll (LMP) 16 und Einheiten 14 des Logischen-Link-Steuerungs-und-Adaptions-Protokolls übertragen. Die Einheiten übertragen beide Datenflüsse über dieselbe logische L2CAP- Kanaldatenverbindung 18. Die Datenpakete werden über dieselbe physikalische Verbindung 22 über dieselben, im wesentlichen ähnliche Basisbandsende-/Empfangseinheiten 20 übertragen. Die konventionelle Datenübertragung ist im Grunde dreischichtig, wobei in den zwei unteren Schichten nur eine logische Verbindung vorhanden ist.
2 zeigt eine Datenübertragung von einer Bluetooth-Vorrichtung zu einer anderen gemäß einer Ausführungsform der vorliegenden Erfindung. Wie im Fall der 1 gibt es zwei Bluetooth ermöglichende Vorrichtungen 2 und 4. Die Elemente der beiden Vorrichtungen sind im wesentlichen dieselben, mit dem Unterschied, dass in der L2CAP-Schicht mit den Einheiten LMP 16 und L2CAP 14 die Datenflüsse der unterschiedlichen Anwendungen getrennt in zwei verschiedenen L2CAP-Kanälen gehandhabt werden. Die Einheiten übertragen beide Datenflüsse über verschiedene logische L2CAP-Kanaldatenverbindungen 18 und 19, wobei jeder der Kanäle einem der Datenflüsse zugewiesen ist. Wie im Fall der 1 können die Datenpakete über dieselbe physikalische Verbindung 22 übertragen werden, über dieselben im wesentlichen ähnlichen Basisbandsende-/Empfangseinheiten 20. Die erfinderische Datenübertragung ist im Grunde dreischichtig, wobei es in der L2CAP-Schicht mindestens zwei unterschiedliche logische Verbindungen gibt.
Es sei angemerkt, dass die Beispiele der 1 und 2 zwei unterschiedliche Datenflüsse zeigen, wobei die Erfindung auch auf einen einzelnen Datenfluss angewandt werden kann, bei dem die BNEP-Verbindung einen einzelnen L2CAP-Kanal verwendet und einen zusätzlichen L2CAP-Kanal für jeden erkannten zu übertragenden Datenfluss aufbaut.
3 ist ein Beispiel einer Bluetooth-Mehrteilstreckenanwendung gemäß einer Ausführungsform der vorliegenden Erfindung. Die Figur wird verwendet, um zu betonen, dass die Erfindung nicht auf das Vorsehen einer Verbindungsschicht-Ressourcenreservierung für eine Einstreckenverbindung beschränkt ist. Der Datenfluss in diesem Beispiel ist ein IP-Datenfluss, der mehrere Bluetooth-Verbindungen 44, 46 innerhalb des Bluetooth-Bereichs überspannt, beispielsweise von einer Nutzervorrichtung eines Netzes des persönlichen Bereichs (PANU, PAN-Nutzer-Rolle innerhalb des Bluetooth-PAN-Profils) 30 über einen Gruppenknoten 38 (GN, eine Rolle innerhalb des Bluetooth-PAN-Profils) zur PANU 34. Nachfolgend wird BNEP-Verkehr, der für einander bestimmt ist (und somit IP-Verkehr) durch die Vorrichtung GN 38 weitergegeben. Wenn er eine IP-basierende Verbindung aufbauen, die spezifische QoS-Parameter benötigt, müssen L2CAP-Kanäle 46, 44 zwischen der Quellen-PANU 30 und dem GN 38 und zwischen dem GN 38 und der Ziel-PANU 34 aufgebaut werden. Um zu betonen, dass die Verbindungen zwischen dem GN 38 und den PANUs 30, 34 mehrere L2CAP-Verbindungen umfassen, sind die Verbindungen mit zwei 44 und drei 46 Paaren von Pfeilen zwischen den PANUs 30, 34 und dem GN 38 bezeichnet.
4 ist ein Beispiel einer Kommunikation zwischen einem Host in einem Netz und einem Piconetz-Nutzer über einen Netzzugangspunkt. 4 enthält nur zwei Vorrichtungen, die PANU 30 und den Netzzugangspunkt (NAP) 36, der mit einem Netz 50 verbunden ist. Das Netz kann beispielsweise ein lokales Netz (LAN) sein, oder es kann beispielsweise das Internet sein. Es kann angenommen werden, dass das Netz Daten gemäß dem Internetprotokoll (IP) überträgt. Das Verfahren gemäß der Erfindung kann angewandt werden, wenn die PANU 30 einen IP-Fluss mit einer vorbestimmten QoS zum Netz 50 übertragen will, oder wenn der NAP 36 einen Datenfluss im Netz 50 für die PANU 30 erkennt. Um die Verwendung von mehr als einem L2CAP-Kanal für die Übertragung von Daten zwischen dem NAP 36 und der PANU 30 anzuzeigen, ist die Verbindung 46 zwischen den zwei Vorrichtungen durch drei Paare von Pfeilen bezeichnet. Es sei angemerkt, dass die Paare von Pfeilen interpretiert werden können, als beispielsweise ein Paar der Pfeile für die BNEP-Verbindung, für die Übertragung der Steuerpakete und die Übertragung der anderen Daten, und die verbleibende zwei Paare für die Übertragung der zwei IP-Datenflüsse vom NAP 36 zur PANU 30 und umgekehrt. Die beiden Paare der Pfeile können auch zwei IP-Flüsse vom oder zum Netz anzeigen, und sie können auch einen einzigen IP-Datenfluss anzeigen, der eine große Menge von Daten aufweist, die in zwei L2CAP-Datenkanäle aufgeteilt werden.
5 zeigt eine Situation einer Mehrteilstrecken-Bluetooth-Verbindung zu einem Internet-Host über einen Netzzugangspunkt. 5 ist im wesentlichen eine Kombination der 3 und 4, wobei der IP-Datenfluss sich über mehrere Bluetooth-Verbindungen 44, 46 erstreckt, beispielsweise von der PANU 34 zum Netzzugangspunkt (NAP) 36 über den GN 38 und sich außerhalb des Bluetooth-Bereichs beispielsweise zum Netz 50 erstreckt. Ein Beispiel des vorherigen Szenarios sind mehrere PANU-Vorrichtungen 34, 36, die mit einer GN-Vorrichtung 38 verbunden sind. Nachfolgend wird BNEP-Verkehr, der für einander bestimmt ist (und somit IP-Verkehr), durch die GN-Vorrichtung 38 weitergegeben. Wenn sie eine IP-Verbindung errichten, die spezifische QoS-Parameter erfordert, müssen reservierte L2CAP-Kanäle 46, 44 sowohl zwischen der Quellen-PANU 36 als auch dem GN 38 und zwischen dem GN 38 und der Ziel-PANU 34 errichtet werden. Ein Beispiel des letzteren Szenarios ist beispielsweise eine PANU-Vorrichtung 36, die sich mit einem IP-Host im Internet durch einen zugewiesenen Netzzugangspunkt (NAP) 36 verbindet, der mit einem lokalen Netz (LAN) 50 verbunden ist, oder durch ein Mobiltelefon, das beispielsweise mit einem UMTS-Netz verbunden ist. In 3 befindet sich der GN 38 in der Masterrolle des Pico-Netzes, und die PANUs 30, 32, 34, 36 befinden sich in der Slave-Rolle, wohingegen die PANU 36 gleichzeitig als NAP 36 arbeitet. Die Rollen können auf andere Weise verteilt werden, beispielsweise kann der NAP 36 der Master der GN 38 sein, der wiederum der Master gegenüber den PANUs 30, 32, 34 ist. Es sei angemerkt, dass dieses Beispiel nur illustrativ ist und nicht auf die dargestellte Piconetz-Topographie beschränkt.
Die Quellen-IP-Hosts und die Ziel-IP-Hosts des IP-Flusses könnten identifizieren, dass ein Paket zu einem spezifischen Fluss gehört, ohne einen Identifikation in IP-Paketen einzuschließen, wenn das Paket zur BNEP-Schicht gegeben wird, und die BNEP-Implementierung könnte dennoch das Paket über den korrekten L2CAP-Kanal senden. Dies gilt nur, wenn die Ende-zu-Ende-IP-Verbindung eine Abbildung auf eine einzelne Bluetooth-Verbindung ausführt (beispielsweise zwischen dem NAP 36 und GN 38). Wenn dies nicht der Fall ist, ist es wesentlich, dass eine Identifikation in das Paket eingefügt wird, so dass der Rückverkehr auch auf die entsprechende L2CAP-Verbindung abgebildet werden kann. Optional könnte die Quelle eines IP-Pakets, das zu einem solchen Fluss gehört, das Paket identifizieren durch das Einschieben einer Flusskennzeichnung in einen BNEP-Erweiterungskopfabschnitt des spezifischen Typs. Dies hat den Vorteil, dass weitergebende Bluetooth-Vorrichtungen nicht in die Paketkopfabschnitte höhere Schichtenprotokolle schauen müssen.
Das präsentierte Verfahren könnte in Verbindung mit IP-basierten Ressourcenreservierungsprotokollen verwendet werden. Beispielsweise könnte das Ressourcenreservierungsprotokoll (RSVP) verwendet werden, um die Verbindungsressourcenreservierung auszulösen. Andererseits könnte die präsentierte Erfindung auch mit Verkehrsklassifikations- oder Priorisierungsschemata verwendet werden, durch das Reservieren der notwendigen Ressourcen auf der Verbindungsschicht, um die QoS-Parameter zu erfüllen, die in der Verkehrsklasse definiert sind. Dies könnte eine formale (standardisierte) Definition oder eine Anwendungs-/Vorrichtungs-spezifische Abbildung der QoS-Parameter auf ein Prioritätsniveau auf einem Niveau höher als Bluetooth sein, das nachfolgend auf einen Satz von Verbindungs-QoS-Parameter abgebildet wird. In jeder Weise kann die Verbindungsreservierung helfen, eine (minimale) Leistung zu erzielen, die für die Verkehrsklasse/das Prioritätsniveau erwartet werden kann, um zu helfen, Verkehrsflüsse mit höherer Priorität von anderen Flüssen (mit niedrigerer Priorität) zu unterscheiden. Die Ressourcenreservierung der Verbindungsschicht kann auch verwendet werden, um mehrere Flüsse, die zur selben Klasse/Priorität gehören, zu transportieren.
Eine Mehrteilstrecken-Ressourcenreservierung könnte erzielt werden durch eine Initiierung der Reservierung Teilstrecke für Teilstrecke (und nachfolgend das Aufbauen einer reservierten L2CAP-Verbindung) beispielsweise unter Verwendung des RSVP. Die präsentierte Erfindung könnte auch ausgebaut werden, durch das Vorsehen einer Mehrstrecken-Ressourcenreservierung auf der BNEP-Ebene. Wenn die Zieladresse des Flusses, die im BNEP-Signalisierungspaket angezeigt wird, nicht die Adresse des Empfängers des Pakets ist (das heißt, das Paket wird durch einen Zwischenknoten empfangen, der sich um das Weitergeben des Verkehrs zwischen Quelle und Ziel kümmert), und der Zwischenknoten den Pfad zum Ziel kennt, so kann dieser Zwischenknoten einen reservierten L2CAP-Kanal mit dem Ziel (oder der nächsten Teilstrecke in einem Fall, bei dem es mehrere weitergebende Vorrichtungen im Pfad gibt) zusätzlich zum L2CAP-Kanal, der mit der Quelle errichtet wird, aufbauen. Beide L2CAP-Kanäle können mit denselben QoS-Parametern konfiguriert werden, um eine Ende-zu-Ende-QoS innerhalb des Mehrteilstreckenpfades zu liefern (innerhalb des Bluetooth-Bereichs). Eine solche weitergebende Vorrichtung könnte der GN 38 in einem der vorangehenden Beispiele sein. Die Natur des BNEP ist so, dass es die Bluetooth-Topologie vor der Verbindungsschicht verbirgt, um somit die Lösung zu gerechtfertigen, die QoS-Ressourcenreservierung der Verbindungsschicht vor der IP-Schicht der weitergebenden Knoten zu verbergen.
Es sei angemerkt, dass die Implementierung des erfinderischen Verfahrens vom Betriebssystem abhängt. Die API (Anwendungsprotokollschnittstelle) zwischen der IP-Schicht und der BNEP-Schicht sollte einen Mechanismus einschließen, um die Ressourcenreservierung der Verbindungssicht und/oder die Paketklassifizierung/Priorität anzuzeigen. Die L2CAP API sollte einen Mechanismus einschließen, um einen L2CAP-Kanal mit QoS-Parametern zu konfigurieren.
Es sei angemerkt, dass der Ausdruck "Datenfluss" jedes Datensignal beschreiben soll, das mehr als ein Datenpaket umfasst, und das eine vorbestimmte Dienstgüte erfordert.
Die Anmeldung enthält die Beschreibung von Implementierungen und Ausführungsformen der vorliegenden Erfindung anhand von Beispielen. Ein Fachmann wird erkennen, dass die vorliegende Erfindung nicht auf die Details der Ausführungsformen, die oben präsentiert wurden, beschränkt ist, und dass die Erfindung auch in einer anderen Form implementiert werden kann, ohne von den Eigenschaften der Erfindung abzuweichen. Die oben präsentierten Ausführungsformen sollten als illustrativ aber nicht als einschränkend angesehen werden. Somit sind die Möglichkeiten der Implementierung und der Verwendung der Erfindung nur durch die eingeschlossenen Ansprüche beschränkt. Somit sollen verschiedene Optionen der Implementierung der Erfindung, wie sie durch die Ansprüche bestimmt sind, die äquivalente Implementierungen einschließen, auch zum Umfang der Erfindung gehören.
ABKÜRZUNGEN

3GPP

Partnerschaftsprojekt der 3. Generation

API

Anwendungsprotokollschnittstelle

BNEP

Bluetooth-Netz-Verkapselungs-Protokoll

Diffserv

Differenzierte Dienste

GN

Gruppenknoten, Rolle innerhalb des Bluetooth-PAN-Profils

IMS

Internet-Multimedia-Untersystem

Intserv

Integrierte Dienste

IP

Internetprotokoll

L2CAP

Logisches-Link-Steuer-und-Adpations-Protokoll

MT

Mobiles Endgerät

NAP

Netzzugangspunkt, Rolle innerhalb des Bluetooth-PAN-Profils

PAN

Vernetzung im persönlichen Bereich

PANU

PAN-Nutzer, Rolle im Bluetooth-PAN-Profil

PDA

Persönlicher Datenassistent

PSM

Protokoll/Dienst-Multiplexer

QoS

Dienstgüte

RSVP

Ressourcenreservierungsprotokoll

TE

Endgeräteinrichtung

UMTS

Universales Mobiles Telekommunikationssystem

Claims

Verfahren zum Übertragen von mindestens einem Datenfluss zusätzlich zu anderen Datenflüssen zwischen zwei Bluetooth-Vorrichtungen (2, 4, 30, 34, 36, 38), die über eine Datenverbindung mit einem Bluetooth-Netz-Verkapselungs-Protokoll (BNEP) verbunden sind, umfassend: – Ermitteln von mindestens einem Datenfluss, der zu übertragen ist, gekennzeichnet durch – Ermitteln eines Dienstgüten (QoS)-Erfordernisses des mindestens einem Datenflusses, und – Aufbauen von mindestens einem logischen Kanal (L2CAP) (18, 19, 44, 46), der für den Datenfluss reserviert ist, wobei der logische Kanal (18, 19, 44, 46) ein Logisches-Link-Steuerungs-und-Adaptations-Protokoll bereitstellt, worin der Kanal zumindest das ermittelte Dienstgüte (QoS)-Erfordenis erfüllt.
Verfahren gemäß Anspruch 1, wobei die Steuerungssignalisierung für das Aufbauen des logischen Kanals und für den Betrieb des logischen Kanals über die Datenverbindung mit einem Bluetooth-Netz-Verkapselungs-Protokoll (BNEP) übertragen wird.
Verfahren gemäß Anspruch 2, wobei die Steuerungssignalisierung weiter eine Identifizierung des Datenflusses einschließt.
Verfahren gemäß Anspruch 2 oder 3, wobei die Steuerungssignalisierung den Übertrag eines Dienstgüte-Parameters gemäß dem Dienstgüte-Erfordernis einschließt.
Verfahren gemäß einem der vorangegangenen Ansprüche, das weiter ein Bewerten des ermittelten Dienstgüte-Erfordernisses umfasst.
Verfahren gemäß einem der vorangegangenen Ansprüche, wobei der Schritt des Aufbauens des L2CAP-Kanals ein Aushandeln des Dienstgüte-Erfordernisses den zwischen zwei Vorrichtungen einschließt.
Verfahren gemäß Anspruch 6, wobei das Aushandeln des Diensterfordernisses zwischen den Vorrichtungen durch Abbilden des Bezeichnen des Datenflusses auf den spezifischen L2CAP-Kanal ausgeführt wird.
Verfahren gemäß einem der vorangegangenen Ansprüche, weiter umfassend Übertragen des Datenflusses über den geeigneten L2CAP-Kanal umfasst.
Verfahren gemäß einem der vorangegangenen Ansprüche, wobei der Datenfluss ein Internet-Protokoll (IP) basierter Datenfluss ist.
Verfahren gemäß Anspruch 9, wobei Datenpakete des Internet basierten Datenflusses, auf Grundlage der Bezeichner der Datenpakete auf den L2CAP-Kanal abgebildet werden.
Verfahren gemäß einem der vorangegangenen Ansprüche, wobei das Dienstgüte-Erfordernis von einer Gruppe ausgewählt wird, die spezifische Verzögerungszeit, Reservierung, Verzögerung, Fehlerrate, Datenrate, Priorität und Bandbreite umfasst.
Verfahren gemäß einem der vorangegangenen Ansprüche, wobei der Datenfluss über mehr als eine Bluetooth-Verbindung übertragen wird.
Computerprogramm, um das Verfahren zur Übertragung von Datenflüssen in einem kabellosen Netz auszuführen, umfassend Programmcodemittel, um irgendeinem der Schritte der Ansprüche 1 bis 12 durchzuführen, wenn das Programm auf einem Computer oder einer Netzwerkvorrichtung ausgeführt wird.
Computerprogramm-Produkt umfassend Programmcodemittel, die auf einem computerlesbaren Medium gespeichert sind, um das Verfahren von irgendeinem der Ansprüche 1 bis 12 durchzuführen, wenn das Programmprodukt auf einem Computer oder einer Netzwerkvorrichtung ausgeführt wird.
Vorrichtung (2, 4, 30, 34, 36, 38), um mindestens einen Datenfluss über eine Datenverbindung mit einem Bluetooth-Netz-Verkapselungs-Protokoll (BNEP) zu übertragen, umfassend: – eine Komponente zum Ermitteln von mindestens einem Datenfluss, der zu übertragen ist, gekennzeichnet, durch – eine Komponente zum Ermitteln eines Dienstgüten (QoS)-Erfordernisses des mindestens einem Datenfluss, und – eine Komponente zum Aufbauen von mindestens einem logischen Kanal (L2CAP) (18, 19), der für den Datenfluss reserviert ist, wobei der Kanal ein Logisches-Link-Steuerungs-und-Adaptations-Protokoll bereitstellt, worin der Kanal zumindest das ermittelte Dienstgüte (QoS)-Erfordernis erfüllt.