DE112008003065B4

DE112008003065B4 - Ad-hoc-Kommunikations-Funkmodul, Ad-hoc-Kommunikationseinrichtung und Verfahren zum Steuern eines Ad-hoc-Kommunikations-Funkmoduls

Info

Publication number: DE112008003065B4
Application number: DE112008003065.0T
Authority: DE
Inventors: Achim Luft; Andreas Schmidt
Original assignee: Intel Mobile Communications GmbH
Current assignee: Intel Deutschland GmbH
Priority date: 2008-01-09
Filing date: 2008-01-09
Publication date: 2014-06-26
Anticipated expiration: 2028-01-10
Also published as: US20100284337A1; WO2009086796A1; US9433033B2; DE112008003065A5

Abstract

Ad-hoc-Kommunikations-Funkmodul, aufweisend: mehrere Ad-hoc-Kommunikations-Empfangsschaltkreise (206, 506) und/oder mehrere Ad-hoc-Kommunikations-Sendeschaltkreise (204, 504), die verschiedene Frequenzbandgruppen verwenden; und eine Ad-hoc-Kommunikationsprotokollstapel-externe Steuer-Schnittstelle (212) zum Ad-hoc-Kommunikationsprotokollstapel-externen Auswählen und Steuern der Medium Access Control (MAC) Schicht oder Physical Layer (PHY)Schicht eines der mehreren Ad-hoc-Kommunikations-Empfangsschaltkreise (206, 506) und/oder Ad-hoc-Kommunikations-Sendeschaltkreise (204, 504) von mehreren Ad-hoc-Kommunikationsprotokollstapel-externen Anwendungen (540, 542, 544) gleichzeitig und unabhängig voneinander.

Description

Die Erfindung betrifft ein Ad-hoc-Kommunikations-Funkmodul, eine Ad-hoc-Kommunikationseinrichtung und ein Verfahren zum externen Steuern eines Ad-hoc-Kommunikations-Funkmoduls.
US 2005/0068965 beschriebt ein Verfahren und eine Vorrichtung zum Steuern von Multi-Mode Radio Zugriff, insbesondere für Multi-Mode rekonfigurierbaren und nahtlosen Übergang in verschiedenen Radio Systemen.
US 2005/0239453 bescheibt ein mobiles Telekommunikationsnetzwerk mit mehreren Basis Stationen, welche mit dem Kern-Netzwerk über eine vorbestimmte Netzwerk-Schnittstelle kommunizieren, und mindestens eine lokale Basis Station, welche mit dem Kern-Netzwerk über eine lizenzlose Radio-Schnittstelle kommuniziert.
US 2006/0019656 bescheibt einen lizenzlosen, drahtlosen Dienst, der konfiguriert ist, Schnittstellenprotokolle für einen lizenzierten drahtlosen Dienst zu generieren, um einen transparenten Übergang von Kommunikationssitzungen zwischen einem lizenzierten drahtlosen Dienst und einem lizenzlosen drahtlosen Dienst bereitzustellen.
US 2006/0258355 beschreibt ein Verfahren und eine Vorrichtung zum Unterstützen von einer Media-unabhängigen Übergabe zwischen einem öffentlichen mobilen Netzwerk und einem lizenzlosen mobilen Zugriffsnetzwerk.
Wünschenswert ist eine Steuerung eines Ad-hoc-Kommunikations-Funkmoduls über eine externe Schnittstelle.
Ausführungsbeispiele der Erfindung sind in den Figuren dargestellt und werden im Folgenden näher erläutert.
Es zeigen
1A Bluetooth Protokollschichten gemäß dem Stand der Technik;
1B das Prinzip von Dienstzugangspunkten gemäß einem Ausführungsbeispiel der Erfindung;
2A und 2B die Steuerung eines Kommunikations-Funkmoduls gemäß einem Ausführungsbeispiel der Erfindung;
3 eine mögliche Bluetooth System-Architektur nach der Integration weiterer Sende-/Empfangsmodule gemäß einem Ausführungsbeispiel der Erfindung;
4 ZigBee Protokollschichten gemäß dem Stand der Technik;
5A, 5B, 5C, 5D und 5E die Steuerung mehrerer Kommunikations-Funkmodule gemäß verschiedenen Ausführungsbeispielen der Erfindung;
6 Architekturblöcke einer Smart-Card am Beispiel einer UICC gemäß dem Stand der Technik;
7 ein Verfahren zum externen Steuern eines Ad-hoc-Kommunikations-Funkmoduls gemäß einem Ausführungsbeispiel der Erfindung;
8A, 8B und 8C Funktionsblöcke in einem ersten Gesamtsystem bzw. einem zweiten Gesamtsystem gemäß einem Ausführungsbeispiel der Erfindung;
9 ein Transaktionsdiagramm A gemäß einem Ausführungsbeispiel der Erfindung;
10 ein Transaktionsdiagramm B gemäß einem weiteren Ausführungsbeispiel der Erfindung;
11 ein Transaktionsdiagramm C gemäß einem Ausführungsbeispiel der Erfindung;
12 ein Transaktionsdiagramm D gemäß einem Ausführungsbeispiel der Erfindung;
13 ein Transaktionsdiagramm E gemäß einem Ausführungsbeispiel der Erfindung;
14 eine Dienste-Tabelle gemäß einem Ausführungsbeispiel der Erfindung;
Im Rahmen dieser Beschreibung werden die Begriffe ”verbunden”, ”angeschlossen” sowie ”gekoppelt” verwendet zum Beschreiben sowohl einer direkten als auch einer indirekten Verbindung, eines direkten oder indirekten Anschlusses sowie einer direkten oder indirekten Kopplung. In den Figuren werden identische oder ähnliche Elemente mit identischen Bezugszeichen versehen, soweit dies zweckmäßig ist.
Im Rahmen dieser Beschreibung wird unter einem Schaltkreis beispielsweise jede Art hartverdrahteter Logik oder programmierbarer Logik verstanden. Ein Schaltkreis kann somit beispielsweise ein programmierbarer Prozessor sein (beispielsweise ein programmierbarer Mikroprozessor (beispielsweise ein Complex Instruction Set Controller(CISC)-Mikroprozessor oder ein Reduced Instruction Set Controller(RISC)-Mikroprozessor), der die jeweilige Funktionalität des Schaltkreises implementiert (beispielsweise mittels eines entsprechend eingerichteten Programmcodes). Es können mehrere Schaltkreise in einem gemeinsamen Schaltkreis integriert vorgesehen sein oder in separaten Schaltkreisen. So kann in einem Ausführungsbeispiel vorgesehen sein, dass die Funktionalitäten beispielsweise eines Bluetooth Controller Subsystems implementiert sind in einem oder in mehreren Mikroprozessoren des Bluetooth Controller Subsystems.
Weiterhin werden die Begriffe „Schicht” und „Ebene” in Bezug auf Protokollschichten gleichbedeutend verwendet. Je nach Kontext, wird der Begriff „Ebene” auch für eine Ebene innerhalb einer Schicht verwendet.
Bluetooth-Systeme der nächsten Generation sollen zukünftig eine Vielzahl von unterschiedlichen Sende-/Empfangsmodulen umfassen, die zum Teil deutlich höhere Datenraten liefern, als das heute etablierte Bluetooth Sende-/Empfangsmodul. Die einzelnen Übertragungstechnologien dieser neuen Sende-/Empfangsmodule können dabei durchaus verschieden sein. In der Bluetooth SIG (Special Interest Group) werden sie unter dem Namen AMP (Alternate MAC (Medium Access Control) PHY (Physical Layer)) zusammengefasst. Derzeit wird in der Bluetooth SIG auch die Einführung einer logischen AMP-Steuereinheit im Bluetooth Core Layer (Sitzungsschicht) diskutiert, die auch als AMP Manager bezeichnet wird. Nach derzeitigem Diskussionsstand bleibt auch das Bluetooth der nächsten Generation (d. h. die etablierte Bluetooth Übertragungstechnik plus ein oder mehrere AMPs) ein in sich geschlossenes System. Dienstzugangspunkte SAPs (Service Access Points) zur Steuerung der AMP Manager Funktionalität von außen sind bislang nicht vorgesehen.
Bluetooth wird wegen seines geringen Stromverbrauchs, der kleinen Bauteilgröße und den vergleichsweise geringen Kosten der Bluetooth Module gerade in mobilen Geräten bevorzugt eingesetzt. Schon heute wird der überwiegende Prozentsatz von Mobilfunkendgeräten mit Bluetooth Wireless Technology ausgeliefert. Die Anwender haben den Mehrwert dieser Technologie mittlerweile erkannt und nutzen sie immer stärker.
Die drahtlose Kopplung von Mobilfunkendgeräten mit Freisprecheinrichtungen im Auto oder von Mobilfunkendgeräten mit drahtlosen Headsets (in der Mono-Variante zum Telefonieren oder in der Stereo-Variante für die Musikübertragung) sind nur zwei der derzeit beliebtesten Anwendungsgebiete für Bluetooth.
Die geplanten AMP-Erweiterungen (zum Zwecke höherer Datenraten) werden voraussichtlich erneut für einen Anstieg der Verbreitung von Bluetooth Systemen in Mobilfunkendgeräten sorgen und zugleich die Entwicklung neuer Anwendungen (beispielsweise die Entwicklung neuer Bluetooth Profile) stimulieren.
In einem Ausführungsbeispiel wird ein Ad-hoc-Kommunikations-Funkmodul gemäß Anspruch 1 bereitgestellt.
In einem weiteren Ausführungsbeispiel wird eine Ad-hoc-Kommunikationseinrichtung gemäß Anspruch 7 bereitgestellt.
In einem weiteren Ausführungsbeispiel wird eine Ad-hoc-Kommunikationseinrichtung gemäß Anspruch 8 bereitgestellt.
In einem weiteren Ausführungsbeispiel wird ein Verfahren zum Steuern eines Ad-hoc-Kommunikations-Funkmoduls gemäß Anspruch 19 bereitgestellt.
Gemäß verschiedenen Ausführungsbeispielen der Erfindung wird eine Öffnung des bisher in sich geschlossenen Bluetooth-Systems beispielsweise zur Steuerung durch vertrauenswürdige Applikationen erreicht.
Gemäß einem Ausführungsbeispiel wird eine Steuerung eines Ad-hoc-Funkkommunikationsmoduls über eine bezüglich des Ad-hoc-Funkkommunikationsprotokolls externe Schnittstelle entworfen. Darüber hinaus wird die Steuerung am Beispiel von über eine neue, externe Schnittstelle zugreifenden Applikationen beschrieben.
Hierdurch könnten die folgenden Wirkungen erzielt werden:

• Beispielsweise könnte eine von einem Netzwerkbetreiber kontrollierte (und somit vertrauenswürdige) Applikation auf einer intelligenten Mobilfunk-Chipkarte, wie z. B. einer Subscriber Identity Module(SIM)-Karte oder Universal Integrated Circuit Card (UICC), bestimmte AMP Manager-Funktionalitäten steuern.
• Beispielsweise könnte in einem Mobilfunkendgerät ein TPM (TPM – Trusted Platform Module) Applikationen vertrauenswürdig kontrollieren, um bestimmte AMP Manager-Funktionalitäten zu steuern.
• Konkret können die besagten vertrauenswürdigen Applikationen das Einschalten und Ausschalten bestimmter AMPs unter vorgegebenen Randbedingungen kontrollieren.
• Ein anderes Beispiel wäre die Steuerung der Benutzung bestimmter Frequenzbandgruppen eines AMPs und/oder Sendeleistungen abhängig vom Aufenthaltsort des Mobilfunkendgeräts (beispielsweise basierend auf der Länderkennung des Mobilfunknetzes) durch die besagten vertrauenswürdigen Applikationen. Regional unterschiedliche Bedingungen der Regulierungsbehörden könnten somit verlässlich erfüllt werden, ohne dass sich der Anwender darum kümmern braucht.

Ausführungsbeispiele der Erfindung beziehen sich auf Teile der Schichten gemäß dem ISO/OSI(International Organization for Standardization/Open System Interconnection)-7-Schicht-Modell.
Das ISO/OSI-Modell ist ein von der ISO genormtes und aus sieben Schichten bestehendes Referenzmodell für die Beschreibung herstellerunabhängiger Kommunikationssysteme. OSI bedeutet Open System Interconnection (Offenes System für Kommunikationsverbindungen). Das ISO/OSI-Modell wird als Hilfsmittel verwendet, um eine offene Kommunikation zwischen verschiedenen Netzwerkgeräten unterschiedlicher Hersteller zu beschreiben. Die meisten frei nutzbaren Netzwerkprotokolle basieren auf diesem Referenzmodell, ein Beispiel für ein solches Netzwerkprotokoll ist TCP/IP.
Die sieben Ebenen sind so festgelegt, dass sie aufeinander aufbauen und jede einzelne unabhängig von den anderen benutzt werden kann. Die von der OSI definierten Schichten lassen sich in zwei Hauptgruppen unterteilen:

• die Schichten eins bis vier stellen das Transportsystem dar; hier werden die Kommunikationskanäle physikalisch und logisch festgelegt;
• die Schichten fünf bis sieben stellen das Anwendungssystem dar; sie dienen vorwiegend der Darstellung von Informationen.

Die Schichten werden üblicherweise so dargestellt, dass die Schicht 1 unten wiedergegeben wird und die Schicht 7 oben (vergleiche Tabelle 1). Die einzelnen Schichten können in realen Systemen nicht immer klar voneinander getrennt werden.

Nr.	Englische Bezeichnung	Deutsche Bezeichnung	Beispiele
7	Application Layer	Anwendungsschicht	Web-Browser, Mail Programm
6	Presentation Layer	Darstellungsschicht	HTML, XML, MIME
5	Session Layer	Sitzungsschicht	http, FTP, POP3, SMTP
4	Transport Layer	Transportschicht	TCP
3	Network Layer	Netzwerkschicht	IP
2	Data Link Layer	Verbindungsschicht	PPP
1	Physical Layer	Physikalische Schicht	IEEE 802

Tabelle 1: Das ISO Schichten-Modell.

Auf die unteren vier Schichten des ISO/OSI-Modells soll an dieser Stelle etwas genauer eingegangen werden, da sie für die in dieser Beschreibung vorgestellte Problematik von Bedeutung sind:
Die Transportschicht (Schicht 4; engl.: Transport Layer) gibt die Möglichkeit, Verbindungen ordnungsgemäß aufzubauen und abzubauen, Verbindungen zu synchronisieren und Datenpakete auf mehrere Verbindungen zu verteilen (Multiplexing). Diese Schicht verbindet das Transportsystem mit dem Anwendungssystem des ISO/OSI-Modells (siehe oben). Des Weiteren werden Datenpakete segmentiert und der Stau von Paketen verhindert.
Die Netzwerkschicht (Schicht 3; engl.: Network Layer) übernimmt die Vermittlung und Zustellung von Datenpaketen. Hier erfolgen auch die Zusammenstellung von Routingtabellen und das Routing an sich. Weiterzuleitende Pakete erhalten eine neue Zwischenzieladresse und gelangen nicht in höhere Schichten. Auch die Kopplung verschiedener Netzwerktopologien erfolgt auf dieser Ebene.
Die Verbindungsschicht (Schicht 2; engl.: Data Link Layer) organisiert und überwacht den Zugriff auf das Übertragungsmedium. Der Bitstrom wird auf dieser Ebene segmentiert und in Paketen zusammengefasst. Außerdem können Daten einer Fehlerpüfung unterzogen werden; z. B. kann eine Prüfsumme an ein Paket gehängt werden. Es ist auch eine Komprimierung der Daten möglich. Weitere Bestandteile sind Sequenzüberwachung und Zeitüberwachung sowie die Flusskontrolle.
Die Verbindungsschicht lässt sich noch einmal in zwei Teilschichten (engl.: sublayer) aufteilen. Die obere Teilschicht wird als LLC-Schicht (LLC – Logical Link Control) und die untere Teilschicht als MAC-Schicht (MAC – Medium Access Control) bezeichnet.
Die Funktionalität der MAC-Schicht kann je nach eingesetztem Übertragungsmedium (physikalische Schicht) unterschiedlich ausgeprägt sein. Zu ihren Hauptaufgaben gehören üblicherweise:

• Erkennen, wo Datenpakete (engl.: frames) in dem von der physikalischen Schicht empfangenen Bitstrom anfangen und aufhören (beim Empfang von Daten).
• Einteilen des Datenstroms in Datenpakete (engl.: frames) und gegebenenfalls Einfügen von Zusatzbits in die Datenpaketstruktur, damit der Anfang und das Ende eines Datenpaketes im Empfänger detektiert werden kann (beim Senden von Daten).
• Feststellen von Übertragungsfehlern, beispielsweise durch das Einfügen einer Prüfsumme beim Senden bzw. durch entsprechende Kontroll-Berechnungen (beim Empfang).
• Einfügen bzw. Auswerten von MAC-Adressen im Sender bzw. Empfänger.
• Zugriffskontrolle (z. B. welche der auf das physikalische Medium zugreifenden Instanzen hat das Senderecht?).

In der Physikalischen Schicht (Schicht 1; engl.: Physical Layer) werden Steckverbindungen, Wellenlängen und Signalpegel definiert. Die Bitsequenzen werden in dieser Schicht in übertragbare Formate gewandelt. Auch die Eigenschaften der Übertragungsmedien (Kabel, Funk, Lichtwellenleiter) sind hier festgelegt.
Im Folgenden werden die für die beschriebenenen Ausführungsbeispiele der Erfindung relevanten Eigenschaften der Bluetooth-Technologie näher erläutert.
Die unteren Protokollschichten der Bluetooth-Architektur in herkömmlicher Weise sind in 1A dargestellt: Die drei unteren Schichten (Physikalische Schicht, hier: Radio Layer 102, Verbindungsschicht, hier: Baseband Layer 104 und Netzwerkschicht, hier: Link Management Layer LML 106) werden in der Literatur häufig zu dem Untersystem „Bluetooth Controller” 112 zusammengefasst. Die über dem Bluetooth Controller 112 liegende Transportschicht wird durch die mit der in 1A gezeigten optionalen „Host to Controller Interface”(HCI)-Schnittstelle 108 abgeschlossen. Das HCI 108 dient in der allgemeinen Bluetooth-Architektur als Service Access Point (SAP) zum Bluetooth Controller 112. Das Prinzip der SAPs wird weiter unten anhand von 1B erläutert.
Über dem HCI 108 liegt die als L2CAP (Logical Link Control and Adaptation Protocol) bezeichnete Sitzungsschicht 110. Sie wird allerdings nur bei ACL-Verbindungen (ACL: asynchroner, verbindungsloser und paketvermittelnder Dienst) benötigt; SCO-Verbindungen (SCO: synchroner, verbindungsorientierter und leitungsvermittelter Dienst), die darauf ausgerichtet sind, eine effiziente Sprachübertragung mit konstanter Datenrate von üblicherweise beispielsweise 64 kbit/s zu gewährleisten, kommen ohne L2CAP 110 aus. Leider lässt sich die strenge Enteilung des ISO/OSI-Modells in der Praxis nicht immer einhalten. In der allgemeinen Bluetooth-Architektur erstrecken sich auch Teile der Netzwerkschicht (hier: Link Management Layer) 106 in die Verbindungsschicht, (hier: Baseband Layer) 104.
Die Darstellungsschicht und die Anwendungsschicht sind in 1A der Einfachheit halber nicht gezeigt. Steuersignale (für Device Control und Transport Control) werden durch die unterbrochenen schwarzen Verbindungspfeile repräsentiert („C-Ebene” oder unterbrochenen schwarzen Verbindungspfeile repräsentiert (,,C-Ebene'' oder Verbindungspfeile dargestellt sind („U-Plane”). Interoperabilität in Bluetooth wird dadurch garantiert, dass zum einen eine saubere Schnittstelle zwischen dem Bluetooth Controller 112 (alle Schichten von LML 106 abwärts) und dem Bluetooth Host (die Schichten ab L2CAP 110 aufwärts) innerhalb eines Bluetooth Systems definiert ist (nämlich beispielsweise HCI 108) und zum anderen der Austausch von Protokollnachrichten zwischen gleichen Schichten zweier unterschiedlicher Bluetooth-Systeme klar geregelt ist (Verbindungspfeile 120, 122, 124, 126 in 1A).
2A zeigt ein Ad-hoc-Kommunikations-Funkmodul 202 gemäß einem Ausführungsbeispiel der Erfindung, das einen Ad-hoc-Kommunikations-Empfangsschaltkreis 206 und/oder einen Ad-hoc-Kommunikations-Sendeschaltkreis 204 und eine Ad-hoc-Kommunikationsprotokollstapel-externe Steuer-Schnittstelle 212 zum Ad-hoc-Kommunikationsprotokollstapel-externen Steuern des Ad-hoc-Kommunikations-Empfangsschaltkreises 206 bzw. des Ad-hoc-Kommunikations-Sendeschaltkreises 204 aufweist.
Unter Steuern wird gemäß verschiedenen Ausführungsbeispielen der Erfindung beispielsweise auch im weiteren Sinn das Übertragen von Informationen bzw. Nachrichten verstanden, die z. B. zur Steuerung des Ad-hoc-Kommunikations-Empfangsschaltkreises oder des Ad-hoc-Kommunikations-Sendeschaltkreises notwendig sind oder notwendig sein könnten, wie z. B. Informationen über deren Eigenschaften und Identifikationsmerkmale. Dies wird im weiteren Verlauf dieser Beschreibung noch detailliert ausgeführt.
Weiterhin wird unter „Kommunikationsprotokollstapel-externer Schnittstelle” beispielsweise verstanden, dass die Schnittstelle einen Zugang von einer Stelle außerhalb des Kommunikationsprotokolls des Ad-hoc-Kommunikationssystems zu einer Stelle innerhalb des Kommunikationsprotokolls, bzw. umgekehrt, bildet, wobei auch die von dem Kommunikationsprotokoll umfassten Einrichtungen mit eingeschlossen sind.
Die Schnittstelle ist hierbei z. B. eine Schnittstelle, die nicht Teil des Kommunikationsprotokolls ist. Alternativ kann sie aber auch Teil des Kommunikationsprotokolls sein oder in das Kommunikationsprotokoll integriert werden.
Aus Hardwaresicht kann die protokoll-externe Steuerung z. B. von mehr oder weniger integrierten Subsystemen oder Schaltkreisen oder Einrichtungen innerhalb eines Kommunikationsgerätes oder auch von sich in einem anderen Kommunikationsgerät befindenden Subsystemen oder Schaltkreisen oder Einrichtungen, beispielsweise einer intelligenten Karte, erfolgen.
Durch den Zugang können Funktionen und Informationen des Kommunikationsprotokolls angesprochen werden, und zwar von z. B. einer höheren Ebene, in der sich der Zugang befindet, gemäß dem Kommunikationsprotokoll bis hinunter zur physikalischen Ebene. Als höhere Ebene kann dabei z. B. eine Ebene gewählt werden, auf der auch die internen Schnittstellen zur Steuerung von Funktionen und Diensten implementiert sind, wie z. B. die Ebene, die sich unterhalb der Applikationsebene befindet. In einem Bluetooth-System wäre dies beispielsweise die Logical Link Control and Adaptation (L2CAP) – Ebene.
Gemäß einem Ausführungsbeispiel weist die Ad-hoc-Kommunikationsprotokollstapel-externe Steuer-Schnittstelle 212 des Ad-hoc-Kommunikations-Funkmoduls 202 mindestens einen Ad-hoc-Kommunikationsprotokollstapel-externen Dienstzugangspunkt 214 auf.
Somit können die Dienste der entsprechenden Schicht innerhalb des Kommunikationsprotokolls von außen in Anspruch genommen werden und Informationen und Steueranweisungen z. B. mittels definierten Dienstprimitiven ausgetauscht werden, in analoger Weise wie für die entsprechenden internen Dienstzugangspunkte. Dadurch wird die Konformität zum konventionellen System gewahrt und eine einfache Erweiterung ermöglicht.
Ein Dienstzugangspunkt (Service Access Point, SAP) ist die Schnittstelle zur Interaktion mit einer Kommunikations-Schicht beispielsweise an der oberen Grenze selbiger Schicht. Traditionell modelliert man in der Telekommunikation Kommunikationssysteme und Kommunikationsprotokolle mit so genannten Schichten-Modellen, wie dem oben beschriebenen ISO/OSI-7-Schicht-Modell. Funktionen, die zur Kommunikation notwendig sind, werden dabei in übereinander liegenden Schichten modelliert und dargestellt. Jede Schicht erfüllt eine spezifische Aufgabe (zum Beispiel eine Datenkodierung/Datendekodierung). Anders ausgedrückt, jede Schicht erbringt einen gewissen Dienst für das Gesamtsystem, welche von der nächst höheren Schicht genutzt wird. Eine Schnittstelle, die von einer Schicht für ihren Dienst nach oben hin angeboten wird, ist ein Service Access Point (SAP). Details dazu sind in 1B gezeigt.
Die höhere Schicht, z. B. die gegenüber der N-Schicht 154 höhere (N + 1)-Schicht 152 stellt den so genannten Dienstbenutzer (service user) dar, der nur über den Service Access Point (SAP), z. B. 158, 160, 162 auf den Dienst der niedrigeren Schicht z. B. 154 (den Dienstanbieter, service provider) zugreift. Die Schichten, wie z. B. Schicht 154 werden durch Instanzen gebildet, wie z. B. die N-Instanzen 164, 166 in 1B, in denen das entsprechende Protokoll implementiert ist, wie z. B. das N-Protokoll für die N-Instanzen 164, 166. Zur Kommunikation werden dabei so genannte Dienstelemente (engl.: primitives) verwendet, mit deren Hilfe zum Beispiel die höhere Schicht, z. B. Schicht 152 Anforderungen an die niedrigere Schicht, z. B. Schicht 154 sendet oder Daten von dieser Schicht 154 erhält.
Eine Schicht kann durchaus mehrere identische oder unterschiedliche Dienste gleichzeitig anbieten – zum Beispiel, wenn mehrere Verbindungen gleichzeitig abgewickelt werden. Dies bedeutet, eine Schicht, wie z. B. Schicht 154, kann mehrere Service Access Points 158, 160, 162 besitzen. In vielen Protokollen ist es dann üblich, diese Service Access Points 158, 160, 162 durch eine Nummerierung, Namen oder Ähnliches zu bezeichnen, um sie zu unterscheiden. Ein solcher Bezeichner wird Service Access Point Identifier (SAPI) genannt. Höher liegende Schichten adressieren einen Dienst dann über einen entsprechenden SAPI, um zum Beispiel sicherzustellen, dass die Anfrage der Verbindung zugeordnet werden kann, für die sie bestimmt ist.
Das mit der Standardisierung der Bluetooth Technologie betraute Gremium Bluetooth SIG (SIG – Special Interest Group) hat sich im Frühjahr 2006 dazu entschieden, neben der bewährten physikalischen Übertragungsschicht 102, die Netto-Datenraten von bis zu 2,2 Mbit/s (beim Download gemäß Bluetooth Version 2.0 + Enhanced Data Rate, die Brutto-Datenrate beträgt ca. 3 Mbit/s) zur Verfügung stellt, zusätzlich noch ein (oder mehrere) alternative „Controller”, die deutlich höhere Netto-Datenraten von über 100 Mbit/s bieten sollen, in die existierende Bluetooth-Architektur einzubinden. Wie in 3 gezeigt, werden die Sende-/Empfangsmodule 350, 360, 370 der anderen Funktechnologien, die integriert werden sollen, innerhalb der Bluetooth SIG als AMPs (Alternate MAC/PHY) bezeichnet und bestehen mindestens aus einer physikalischen Schicht (Schicht 1, PHY) 352, 362, 372 und einer zugehörigen Verbindungsschicht 354, 364, 374 (Schicht 2; MAC). Eventuell kommt noch ein PAL (Protocol Adaptation Layer) 356, 366, 376 hinzu, der oberhalb der MAC-Schicht 354, 364, 374 angesiedelt ist und der das „Andocken” des alternativen „Controllers” 350, 360, 370 an den Host 300 vereinfachen soll. Zunächst soll die auf OFDM (Orthogonal Frequency Division Multiplexing) basierende UWB (Ultra Wide Band) Lösung gemäß den Standards ECMA-368 und ECMA-369 der WiMedia Alliance in die existierende Bluetooth-Architektur integriert werden. Bekannte Beispiele für die OFDM Technologie sind: Digital Video Broadcasting (DVB), Digital Audio Broadcasting (DAB), x Digital Subscriber Line (xDSL) und Power Line Communications (PLC). Später können noch weitere Funktechnologien hinzukommen. WLAN (Wireless Local Area Network) gemäß IEEE 802.11b/g hat in diesem Zusammenhang die größte Chance, als nächste Funktechnologie in die existierende Bluetooth-Architektur integriert zu werden. In der Bluetooth SIG wurde zu diesem Zweck bereits eine separate Study Group gegründet.
Als zentrales Element in der Bluetooth System-Architektur der nächsten Generation von Bluetooth wird derzeit ein so genannter „AMP Manager” 330 diskutiert, wie in 3 gezeigt. Er soll beispielsweise die Kontrolle darüber übernehmen, welche der unterschiedlichen Sende-/Empfangsmodule 340, 350, 360, 370 zu welchem Zeitpunkt bzw. beim Eintreffen welcher Ereignisse eingeschaltet bzw. ausgeschaltet werden.
Nach heutigem Stand der Diskussionen sollen dafür zukünftig mindestens

• der Legacy Bluetooth Controller 340,
• AMP1 350 basierend auf UWB Technologie (gemäß der WiMedia Alliance), und
• AMP2 360 basierend auf WLAN Technologie (gemäß IEEE 802.11b/g), zur Auswahl stehen.

Den AMP Manager 330 kann man als logische Funktionseinheit ansehen. Er kann beispielsweise in der Sitzungsschicht 324 (neben dem L2CAP Resource Manager 326 und dem Channel Manager 328) implementiert sein, wo er den höheren Protokollschichten über einen dedizierten AMP Manager SAP 320 die folgenden Dienste anbietet:

• Entdecken von AMP Managern auf der Gegenseite (d. h. in benachbarten Geräten, zu denen eine Verbindung aufgebaut ist oder werden kann),
• Entdecken von unterstützten AMP Technologien auf der Gegenseite,
• Gewinnen von Detailinformationen (z. B. unterstützte Parameter) über bestimmte AMP Technologien auf der Gegenseite,
• Gewinnen von Detailinformationen (z. B. unterstützte Parameter) über eingesetzte AMP Technologien im eigenen Gerät,
• Aufbau einer physikalischen AMP-Verbindung,
• Verwaltung einer physikalischen AMP-Verbindung,
• Abbau einer physikalischen AMP-Verbindung.

Es ist beispielsweise vorgesehen, dass auch die L2CAP-Schicht 324 (Sitzungsschicht oder Bluetooth Core Layer nach 3) für die Integration weiterer Sende-/Empfangsmodule (AMPs) 350, 360, 370 verändert wird, damit logische Kanäle über unterschiedliche Sende-/Empfangsmodule 340, 350, 360, 370 gemultiplext werden können. Im Gespräch ist derzeit die Einführung eines „Multi-Radio Selection and Routing Moduls” 334 in der Sitzungsschicht 324.
Um den höheren Schichten im Gesamtsystem die Dienste der neuen Funktionseinheiten im Bluetooth Core Layer (L2CAP-Schicht) 324 anbieten zu können, ist es beispielsweise vorgesehen, den existierenden L2CAP SAP 316 zu erweitern oder einen dedizierten L2CAP AMP SAP 318 hinzuzufügen. Mit Hilfe dieser beiden möglichen SAPs 316, 318 ist die erweiterte L2CAP-Schicht 324 in der Lage, die folgenden Dienste anzubieten:

• Aufbau eines logischen L2CAP-Datenkanals über eine ausgewählte bestehende physikalische AMP Verbindung,
• Übergabe eines bestehenden logischen L2CAP-Datenkanals von einer ersten aktiven AMP-Verbindung zu einer anderen aktiven AMP-Verbindung.
• Übergabe eines bestehenden logischen L2CAP-Datenkanals von einer aktiven AMP-Verbindung zur etablierten Bluetooth-Verbindung („Legacy Bluetooth Controller” 340 bei 2.4 GHz) bzw. anders herum.

Im weiteren Verlauf der AMP Integrationsbemühungen ist es durchaus denkbar, dass der Funktionsumfang der L2CAP-Schicht 324 in Zukunft noch weiter anwachsen wird und in Folge dessen noch weitere neue SAPs definiert werden (denkbar ist z. B. ein dedizierter Ranging SAP 322 zum Durchführen von Entfernungsmessungen, usw.), bzw. dass einige der oben erwähnten dedizierten SAPs zusammengelegt werden.
Wenn im weiteren Verlauf der Beschreibung der Ausführungsbeispiele der Erfindung vom neuen externen Dienstzugangspunkt SAPext die Rede ist, so soll dieser beispielsweise auch mehrere der oben bereits erwähnten Dienstzugangspunkte umfassen können, wie beispielsweise den „AMP Manager SAP” 330, den „L2CAP AMP SAP” 318, den „Ranging SAP” 322, usw.
3 zeigt ein allgemeines Blockdiagramm für die geplante Integration von alternativen Sende-/Empfangsmodulen (AMPs) 350, 360, 370 für die nächste Generation von Bluetooth. Jeder AMP 350, 360, 370 besteht aus einer PHY-Schicht 352, 362, 372 und MAC-Schicht 354, 364, 374. Der ebenfalls gezeigte PAL (Protocol Adaptation Layer) 356, 366, 376 dient der besseren Anpassung der individuellen Schnittstellen der unterschiedlichen Sende-/Empfangsmodule an die vom Host-System geforderten Eigenschaften (HCI-Schnittstelle 336) und ist optional. Der herkömmliche Bluetooth 2,4 GHz Controller („Legacy Bluetooth Controller” 340 in 3) bedarf keines PALs, da die HCI Schnittstelle 336 optimal auf diesen Controller zugeschnitten ist. Oberhalb der HCI Schnittstelle 336 ist die L2CAP (Logical Link Control and Adaptation Layer) Schicht 324 gezeigt. Konventionell umfasst sie einen Ressourcen-Manager (Resource Manager) 326 und einen Kanal-Manager (Channel Manager) 328. Die Einführung eines AMP Managers 330 wird derzeit im Rahmen der Einbindung von UWB gemäß ECMA-368 und ECMA-369 und der Einbindung von WLAN gemäß 802.11b/g diskutiert. Die L2CAP-Schicht 324 bietet der Application/Profile Management Entity 308 über die gezeigten SAPs 310, 312, 134, 316, 318, 320, 322 verschiedene Dienste an. Die ersten vier SAPs (Synch SAP 310, Control SAP 312, SDP SAP 314 und L2CAP SAP 316) sind in der Bluetooth Specification Version 2.0 detailliert beschrieben.
Die im Rahmen der AMP Erweiterungen diskutierten Architektur-Blöcke in 3 sind der AMP Manager 320 und das Multi-Radio Selection and Routing Modul 334. Durch zukünftige Funktionserweiterungen können in der L2CAP Schicht 324 noch weitere logische Funktionseinheiten hinzukommen. Am oberen Ende der L2CAP-Schicht 324 sind die heute diskutierten SAPs gezeigt:

• L2CAP AMP SAP 318,
• AMP Manager SAP 320, und
• Ranging SAP 322.

Für die Anbindung der einzelnen AMPs 350, 360, 370 am Host-System sind eventuell Adaptionen sowohl im jeweiligen Sende-/Empfangsmodul 350, 360, 370 als auch im Host-System notwendig. So kann es sein, dass es zu einer Aufspaltung der in 3 gezeigten PAL-Blöcke kommen wird, und zwar in einen L-PAL (L für „lower”; engl: unterer) in den einzelnen Sende-/Empfangsmodulen 350, 360, 370 und einen U-PAL (U für „upper”; engl: oberer) in der L2CAP-Schicht 324. Dies ist in
3 nicht gezeigt, soll hier aber der Vollständigkeit halber nicht unerwähnt bleiben. Im weiteren Verlauf dieser Beschreibung wird von einer System-Architektur gemäß 3 ausgegangen, d. h. es wird nur die Variante betrachtet, in der sämtliche PAL-Funktionalitäten in den einzelnen Sende-/Empfangsmodulen 350, 360, 370 (Bluetooth Terminologie: „Controller”) implementiert ist. Eine Übertragung auf die andere Architektur-Variante mit aufgeteilter PAL-Funktionalität ist trivial und wird in dieser Beschreibung nicht gesondert behandelt, ist jedoch in einem alternativen Ausführungsbeispiel der Erfindung ebenfalls vorgesehen.
2B zeigt in einem Ausführungsbeispiel der Erfindung eine Ad-hoc-Kommunikationsprotokollstapel-externe Steuer-Schnittstelle 212 des Ad-hoc-Kommunikations-Funkmoduls 202, die mehrere Ad-hoc-Kommunikationsprotokollstapel-externe Dienstzugangspunkte 214, 216, 218 aufweist.
Durch die Implementierung mehrerer externer Dienstzugangspunkte können mehrere Kommunikationsprotokollstapel-externe Anwendungen 220, 222, 224 gleichzeitig und aus ihrer Sicht unabhängig voneinander die Sende- und/oder Empfangsmodule 204, 206 steuern, wie beispielsweise in 2B dargestellt. Hierbei ist unter Steuern beispielsweise wiederum auch der bidirektionale Informationsaustausch zwischen externen Applikationen 220, 222, 224 und den Sende- und/oder Empfangsmodulen 204, 206 zu verstehen. Die Steuerung erfolgt dabei selbstverständlich nicht direkt, sondern indirekt mit Zwischeninstanzen gemäß den Regeln des Kommunikationsprotokolls.
In einem Ausführungsbeispiel der Erfindung ist das Ad-hoc-Kommunikations-Funkmodul 202 gemäß Bluetooth oder ZigBee eingerichtet.
Das Bluetooth-Protokoll wurde bezüglich der Ausführungsbeispiele der Erfindung weiter oben bereits ausführlich beschrieben. ZigBee ist ein weiterer Ad-hoc-Funkstandard für Kurzstrecken bis ca. 10–100 m, dessen Protokollstack im Folgenden kurz erläutert wird.
Wie in 4 gezeigt, besitzt ZigBee eine physikalische Ebene PHY 402 und eine Mediumzugriffsebene MAC 404 nach dem OSI-Modell, die auf dem IEEE 802.15.4-Standard basieren. Die PHY und MAC Layer-Funktionen sind neben IEEE 802.15.4 auch durch die Hardware (ZigBee/IEEE 802.15.4 Controller) bestimmt.
Über der MAC-Ebene 404 befindet sich ein Network Layer (NWK) 406, der die PHY und MAC Layer Funktionen auf die höheren Schichten des ZigBee Stack adaptiert.
Die Service Access Points werden gemäß ihrer Schicht bezeichnet: APSDE(Application Support Sublayer Data Entity)-SAP 416, 418, 420, APSME(Application Support Sublayer Managment Entity)-SAP 422, NLDE(Network Layer Data Entity)-SAP 424, NLME(Network Layer Managment Entity)-SAP 426, MLDE(MAC Layer Data Entity)-SAP 428, MLME(MAC Layer Managment Entity)-SAP 430, PD(Physical Device)-SAP 432 und PLME(Physical Layer Managment Entity)-SAP 434.
Der über der MAC-Ebene liegende Application Support Sublayer (APS) 408 definiert den logischen Gerätetyp (engl.: „Device Type”) im Netzwerk, multiplext die eingehenden Daten und ist zuständig für Sicherheitsmechanismen. Er stellt eine Schnittstelle durch den APSDE und den APSME zur Verfügung. Der APSDE stellt den Datenübertragungsservice für die PDUs (Packet Data Units, Protokolldateneinheiten) zwischen zwei oder mehreren Geräten im gleichen Netzwerk zur Verfügung. Der APSME stellt Dienste für das Entdecken und Verbinden neuer Geräte zur Verfügung und führt eine Datenbank mit verwalteten Objekten.
Das ZDO (ZigBee Device Object) 436 ist zuständig für die Initialisierung des APS, des NWK und der Sicherheitsdienstespezifikation (Security Services Specification, SSS). Das ZDO 436 setzt die Konfigurationsinformation von den Endapplikationen zusammen um das Entdecken von Devices, das Sicherheitsmanagement, das Netzwerkmanagement und das Verbindungsmanagement zu bestimmen bzw. zu implementieren.
Über dem APS 408 befindet sich der Application Framework 410, wobei der APS 408 mit den Applikationen 412, 414 über die APSDE(Application Support Sublayer Device Entity)-SAPs 416, 418 in Verbindung steht. Im ZigBee Application Framework 410 werden die Applikationsobjekte 412, 414 auf einem ZigBee Device abgelegt. Innerhalb des Application Frameworks 410 senden und empfangen die Application Objects 412, 414 Daten über die APSDE-SAPs 416, 418.
Entsprechend zu der Beschreibung bezüglich Bluetooth könnten bei ZigBee Sende- und Empfangsmodule, auf denen der PHY und der MAC implementiert sind, über Kommunikationsprotokoll-externe Schnittstellen gesteuert werden. Die externen Dienstzugriffspunkte könnten beispielsweise auf dem APS aufsitzen.
Wie in 5A gezeigt, weist eine Ad-hoc-Kommunikations-Funkmodul-Anordnug 500 gemäß einem Ausführungsbeispiel zusätzlich zu dem Funkmodul 202, mindestens ein weiteres Funkmodul 501 mit einem zusätzlichen Empfangsschaltkreis 506 und/oder mindestens einem zusätzlichen Sendeschaltkreis 504 und eine Steuerung 502 zum Steuern des Ad-hoc-Kommunikations-Empfangsschaltkreises 206 bzw. des Ad-hoc-Kommunikations-Sendeschaltkreises 204 sowie des zusätzlichen Empfangsschaltkreises 506 bzw. des zusätzlichen Sendeschaltkreises 504 auf, wobei die Steuerung 502 eine Ad-hoc-Kommunikationsprotokollstapel-externe Steuer-Schnittstelle 212 aufweist.
Die Steuerung 502 könnte beispielsweise die oben diskutierte logische AMP-Steuereinheit, der AMP Manager 330, sein.
Gemäß einem Ausführungsbeispiel ist der mindestens eine zusätzliche Empfangsschaltkreis 506 des Ad-hoc-Kommunikations-Funkmoduls 202 und/oder der mindestens eine zusätzliche Sendeschaltkreis 504 gemäß einer anderen Funktechnologie als der Ad-hoc-Kommunikations-Empfangsschaltkreis 206 bzw. der Ad-hoc-Kommunikations-Sendeschaltkreis 204 eingerichtet.
Das heißt, das Bluetooth-Gerät oder das ZigBee-Gerät kann noch weitere Sende-/Empfangsschaltkreise besitzen, die sich von der eigentlichen Bluetooth- bzw. ZigBee-Funktechnologie unterscheiden. Physikalisch können sich diese außenstehenden Einrichtungen im gleichen Gerät befinden; sie können sich aber auch in einem anderen Gerät befinden.
Bei Vorhandensein mehrerer externer Dienstzugangspunkte können mehrere Kommunikationsprotokollstapel-externe Anwendungen gleichzeitig und aus ihrer Sicht unabhängig voneinander die Sende- und/oder Empfangsschaltkreise steuern, wie beispielsweise in 5B dargestellt, über die Dienstzugangspunkte 508 oder 510 und den Dienstzugangspunkt 512.
Es ist aber auch möglich, dass, wie in dem Beispiel in 5C gezeigt, eine externe Applikation 520 mehrere Funkmodule 202, 501, 526 und damit mehrere Sende- und/oder Empfangsschaltkreise 204, 206, 504, 506, 522, 524 gleichzeitig und aus ihrer Sicht unabhängig voneinander über die Dienstzugangspunkte 508, 510, 512 steuert.
5D zeigt ein Beispiel, in dem jeweils eine Applikation 540, 542, 544 genau einen Sende- und/oder Empfangsschaltkreis 204, 206, 504, 506 bzw. 522, 524 steuert.
Auch eine Kombination hiervon ist möglich, wie beispielhaft ebenfalls in 5B zu sehen ist, wo die Applikation 514 noch zusätzlich über den Dienstzugangspunkt 512 den Sendeschaltkreis 204 und den Empfangsschaltkreis 206 steuert.
Auch hier erfolgt die Steuerung nicht direkt, sondern gemäß den Regeln des Kommunikationsprotokolls, so dass ein geordneter Datenfluss z. B. durch entsprechendes Multiplexing und Routing stattfindet, und so dass z. B. nicht zwei Sendeschaltkreise gleichzeitig senden, wenn dies z. B. generell ausgeschlossen sein soll.
Gemäß einem Ausführungsbeispiel ist der mindestens eine zusätzliche Empfangsschaltkreis 506 und/oder der mindestens eine zusätzliche Sendeschaltkreis 504 des Ad-hoc-Kommunikations-Funkmoduls 202 gemäß einer der folgenden Funktechnologien eingerichtet: Ultra-Breitband-Funktechnologie (z. B. gemäß der WiMedia Alliance); Drahtlos-Lokales-Netzwerk-Funktechnologie (z. B. gemäß IEEE 802.11 b/g). Letztere ist auch unter dem Begriff WLAN bekannt.
Es kommen jedoch auch weitere, hier nicht genannte Ad-hoc Funktechnologien in alternativen Ausführungsbeispielen der Erfindung in Frage; beispielsweise Funktechnologien, die einen Aufbau gemäß oder angelehnt an das OSI-Modell besitzen, d. h. eine physikalische Schicht PHY und eine MAC-Schicht aufweisen, sind hierfür geeignet.
Es sei angemerkt, dass in den Figuren nur die Teile gezeigt werden, die der Illustration der Ausführungsbeispiele der Erfindung dienlich sind.
5E zeigt in einem Ausführungsbeispiel der Erfindung eine Ad-hoc-Kommunikationseinrichtung 550, die ein erstes Ad-hoc-Kommunikations-Funkmodul 202, aufweisend einen Ad-hoc-Kommunikations-Empfangsschaltkreis 206 und/oder einen Ad-hoc-Kommunikations-Sendeschaltkreis 204, und ein zweites Ad-hoc-Kommunikations-Funkmodul 501, welches ebenfalls einen Ad-hoc-Kommunikations-Empfangsschaltkreis 506 und/oder einen Ad-hoc-Kommunikations-Sendeschaltkreis 504 aufweist, und ein eine Ad-hoc-Kommunikationsprotokollstapel-externe Steuer-Schnittstelle 212 zum Ad-hoc-Kommunikationsprotokollstapel-externen Steuern der Ad-hoc-Kommunikations-Empfangsschaltkreise 206 und 506 bzw. zum Ad-hoc-Kommunikationsprotokollstapel-externen Steuern der Ad-hoc-Kommunikations-Sendeschaltkreise 204 und 504, sowie einen Speicher 552 zum Speichern eines Steuerprogramms 554 zum Ad-hoc-Kommunikationsprotokollstapel-externen Steuern der Ad-hoc-Kommunikations-Empfangsschaltkreise 206 und 506 bzw. Ad-hoc-Kommunikations-Sendeschaltkreise 204 und 504 der beiden Ad-hoc-Kommunikations-Funkmodule 202 und 501 umfasst.
Das Steuerprogramm 554 greift z. B. auf die Schnittstellen 556 und 212 zu und kann hierdurch die Steuerung 502 ansprechen, die ihrerseits auf Basis der von dem Steuerprogramm 554 gesendeten Nachrichten die Sende- und Empfangsmodule 204, 206, 504 und 506 steuert.
Im Falle von Bluetooth könnte das in 5E gezeigte Ad-Hoc-Funkmodul 202 beispielsweise als herkömmlicher Bluetooth Controller ausgestaltet sein und 560 den Bluetooth Host repräsentieren. Das Ad-Hoc-Modul 501 könnte in einem Ausführungsbeispiel als WLAN- oder UWB-Modul ausgestaltet sein.
Unterschiedliche Kommunikations-Funkmodule können auch in einer Funktionseinheit zusammengefasst werden, sie könnten sogar auf dem gleichen Chip (Substrat) realisiert werden. Diese Möglichkeit wird durch den Kasten 203 angedeutet. Ferner ist es denkbar, eines (oder beide) der Funkmodule 202 bzw. 501 (oder die Funktionseinheit 203) funktional in den Bluetooth Host 560 zu integrieren.
Gemäß einem Ausführungsbeispiel ist das Steuerprogramm 554 ein für das Ad-hoc-Kommunikations-Funkmodul 202 vertrauenswürdiges Steuerprogramm.
Die Vertrauenswürdigkeit kann z. B. durch aktiviertes Trusted Platform Module (TPM) sichergestellt werden.
Das Trusted Platform Module (TPM) ist ein Chip, der als Teil der TCG-Spezifikation (TCG – Trusted Computing Group), ursprünglich PCs sicherer machen sollte. Er entspricht einer fest eingebauten Smartcard mit dem wichtigen Unterschied, dass er nicht an einen konkreten Benutzer, sondern an ein System gebunden ist. Neben der Verwendung in PCs soll er in PDAs, Mobiltelefonen und neuerdings auch in Geräten der Unterhaltungselektronik integriert werden. Der TPM-Chip ist passiv und kann weder den Bootvorgang noch den Betrieb direkt beeinflussen. Er enthält eine eindeutige Kennung und dient damit zur Identifizierung des Rechners. Außerdem können innerhalb des TPMs eine Vielzahl von unterschiedlichen digitalen Schlüsseln erzeugt, benutzt und sicher abgelegt werden. Eine Wirkung ist, dass diese Schlüssel das TPM nie verlassen braucht. Dadurch sind sie vor Software-Angriffen geschützt. Vor Hardware-Angriffen besteht ebenfalls ein relativ hoher Schutz (Sicherheit ist mit Smartcards vergleichbar). Auch sind die TPMs so hergestellt, dass eine physische Manipulation die unweigerliche Zerstörung der Daten zur Folge hat. Die für diese Erfindung wichtigste Funktionalität ist die TPM-unterstütze Beglaubigung. Durch sie kann eine entfernte Partei davon überzeugt werden, dass die Trusted Computing Plattform bestimmte Fähigkeiten besitzt und sich in einem wohl definierten Zustand befindet, mit anderen Worten, vertrauenswürdig ist. In manchen Fällen ist ein aktiviertes TPM Voraussetzung zum Ausführen von bestimmten Applikationen.
Gemäß einem Ausführungsbeispiel der Erfindung weist die Ad-hoc-Kommunikationseinrichtung 550 ferner einen Mobilfunk-Kommunikations-Empfangsschaltkreis 506 und/oder einen Mobilfunk-Kommunikations-Sendeschaltkreis 504 auf.
Somit können mit z. B. einem Bluetooth-Gerät Mobilfunk-Sprach- und Datenverbindungen aufgebaut werden, die sich über die externe Schnittstelle 212 steuern lassen. Ein Anwendungsbeispiel wäre zum Beispiel ein Wechsel einer aktuellen Verbindung über einen Bluetooth-Sende-/Empfangsschaltkreis, z. B. 204, 206, zu einer Mobilfunkverbindung, wenn das Bluetooth-Gerät außerhalb der Reichweite der Bluetoothverbindung gerät. Eine Applikation kann die Eigenschaften der Mobilfunk-Sende/Empfangsschaltkreise, z. B. 504, 506, abfragen und den Verbindungswechsel veranlassen.
Gemäß einem Ausführungsbeispiel ist der Mobilfunk-Kommunikations-Empfangsschaltkreis bzw. der Mobilfunk-Kommunikations-Sendeschaltkreis der Ad-hoc-Kommunikationseinrichtung 550 gemäß einer Mobilfunk-Technologie der zweiten Generation oder gemäß einer Mobilfunk-Technologie der dritten Generation eingerichtet.
In einem Ausführungsbeispiel ist der Mobilfunk-Kommunikations-Empfangsschaltkreis bzw. der Mobilfunk-Kommunikations-Sendeschaltkreis der Ad-hoc-Kommunikationseinrichtung 550 gemäß einer der folgenden Mobilfunk-Technologien eingerichtet: Global System for Mobile Communications Mobilfunk-Technologie (GSM), Universal Mobile Telecommunication System Mobilfunk-Technologie (UMTS), Code Division Multiple Access Mobilfunk-Technologie (CDMA), Code Division Multiple Access 2000 Mobilfunk-Technologie (CDMA2000), Freedom of Mobile Multimedia Access Mobilfunk-Technologie (FOMA).
Es kommen aber ferner auch hier nicht genannte bestehende oder zukünftige Mobilfunk-Technologien in Frage, wie z. B. Satelliten-Mobilfunksysteme.
Weiterhin weist die Ad-hoc-Kommunikationseinrichtung 550 ferner gemäß einem Ausführungsbeispiel einen Schnurlos-Kommunikations-Empfangsschaltkreis und/oder einen Schnurlos-Kommunikations-Sendeschaltkreis auf.
Da das ISO/OSI-Schichtenmodell auch weithin im Bereich der schnurlosen (engl.: ”cordless”) Kommunikation wie z. B. der Schnurlos-Telefonie, manchmal auch als Drahtlos-Telefonie bezeichnet, und Schnurlos-Datenübertragung verbreitet ist, sind z. B. auch insbesondere Schnurlos-Kommunikations-Empfangsschaltkreise und Schnurlos-Kommunikations-Sendeschaltkreise, die auf diesem Modell aufbauen, geeignet.
Gemäß einem Ausführungsbeispiel ist der Schnurlos-Kommunikations-Empfangsschaltkreis bzw. der Schnurlos-Kommunikations-Sendeschaltkreis der Ad-hoc-Kommunikationseinrichtung gemäß einer der folgenden Mobilfunk-Technologien eingerichtet: Digital Enhanced Cordless Telecommunication Schnurlos-Technologie, Wideband Digital Enhanced Cordless Telecommunication Schnurlos-Technologie, Cordless Telephony 2 Schnurlos-Technologie, Cordless Advanced Technology – internet and quality Schnurlos-Technologie.
Somit können auch die unterschiedlichsten Kombinationen aus verschiedenen schnurlosen Kommunikationseinrichtungen und verschiedenen Mobilfunk-Kommunikationseinrichtungen sowie weiteren Kommunikationseinrichtungen mit ähnlichem Protokollstack in den unteren Schichten gebildet werden gemäß alternativen Ausführungsbeispielen der Erfindung.
Es ist weiterhin z. B. auch eine Konstellation denkbar, bei der ein Bluetooth-Gerät ein ZigBee-Funkmodul aufweist, bzw. umgekehrt.
5E zeigt weiterhin ein Ausführungsbeispiel der Erfindung, in welchem die Ad-hoc-Kommunikationseinrichtung 550 ferner eine Benutzer-Identifikationselement-Schnittstelle 556 zur Kommunikation mit einem Benutzer-Identifikationselement 536 eines Benutzers der Ad-hoc-Kommunikationseinrichtung 550 aufweist.
Bedeutend hierbei ist, dass zumindest ein Teil der Identifikationselement-Schnittstelle 556 mit der Ad-hoc-Kommunikationsprotokollstapel-externen Steuer-Schnittstelle 212 entweder identisch ist oder die Schnittstelle 556 an die Schnittstelle 212 angepasst wird, so dass die Kommunikation mit dem Kommunikations-Funkmodul 202 über diese Schnittstellen 556, 212 stattfinden kann und wodurch schließlich auch die Steuerung der Kommunikationsempfangs- und/oder -sendeschaltkreise (ggf. unter Einbeziehung der Steuereinheit 502) erreicht wird.
Gemäß einem Ausführungsbeispiel weist die Ad-hoc-Kommunikationseinrichtung 550 ferner ein mit der Benutzer-Identifikationselement-Schnittstelle 556 zur Kommunikation gekoppeltes Benutzer-Identifikationselement 536 auf.
Das Benutzer-Identifikationselement 536 ist aus 5E ersichtlich, das über die Benutzer-Identifikationselement-Schnittstelle 556 an die Einheit 562 gekoppelt ist.
Das Steuerprogramm 554 ist gemäß einem Ausführungsbeispiel der Erfindung der Ad-hoc-Kommunikationseinrichtung 550 in einem Speicher 554 des Benutzer-Identifikationselements 536 gespeichert.
Als Speicher für das Steuerprogramm wird, wie weiter unten detaillierter ausgeführt wird, beispielsweise ein EEPROM (Electrically Erasable Read Only Memory) verwendet. Der Speicher 554 kann für datenreiche Anwendungen aber auch z. B. ein Flash-Speicher sein bzw. im Falle eines EEPROMS mit einem Flash-Speicher erweitert werden. Der Speichertyp ist jedoch generell nicht auf die genannten Speichertypen beschränkt.
Gemäß einem Ausführungsbeispiel ist das Benutzer-Identifikationselement 536 der Ad-hoc-Kommunikationseinrichtung 550 ein Teilnehmer-Identifikations-Modul.
Beispielsweise handelt es sich bei dem Identifikationselement 536 um eine SIM-Karte, eine SIM-Toolkit-Karte, eine UICC-Karte mit einer oder mehreren Applikationen, wie z. B. SIM-Applikationen oder eine USIM-Applikationen oder eine andere Smart Card. Die Applikationen auf den Smart Cards können z. B. als Java-Applets implementiert sein.
Mobilfunkendgeräte gemäß dem GSM Standard benötigen zum Betrieb im Mobilfunknetz eine SIM-Karte, Mobilfunkendgeräte nach dem UMTS Standard eine UICC (Universal Integrated Circuit Card), auf der das Vorhandensein mindestens eines USIM (Universal Subscriber Identity Module) erforderlich ist. Sowohl auf SIM-Karten als auch auf UICCs können Applikationen installiert sein. Viele dieser Applikationen sind in der Regel mobilfunkspezifisch und werden ausschließlich vom Netzbetreiber bereitgestellt und kontrolliert (auch nachträglich aktualisiert). Vertrauenswürdige Applikationen zum Ausführen bestimmter Funktionen, wie sie für diese Erfindung von Bedeutung sind, können ebenfalls auf derartigen intelligenten Mobilfunk-Chipkarten gespeichert sein.
6 beschreibt vereinfacht fünf Architektur-Blöcke einer Smart Card 600 am Beispiel einer UICC mit:

• Applikationsspeicher (Application Memory) 602, z. B. einem EE-PROM (Electrically Erasable Programmable Read Only Memory). Der Applikationsspeicher 602 enthält Applikationen, USAT (USIM Application Toolkit) applets, und Daten, wie z. B. (SMS Short Message Service), MMS (Multimedia Messaging Service), Telefonbuch, usw.;
• Nur-Lese-Speicher (ROM, Read Only Memory) 604, welches das USAT, Smart Card Applikationen, das Dateisystem (File System), Algorithmen, JAVA VM (virtual machine) und Betriebssysteme enthält;
• Vielfachzugriffsspeicher (RAM, Random Access Memory) 606, das den Arbeitsspeicher darstellt und Rechenergebnisse oder Daten der Eingabe-/Ausgabekommunikation speichert;
• Mikroprozessoreinheit MPU (Microprocessor Unit) 608, die Befehle ausführt; und
• Eingabe/Ausgabe-Steuerung (I/O (Input/Output) Controller) 610, dessen Aufgabe das Management des Datenflusses zwischen dem Mobilfunkendgerät und der Mikroprozessoreinheit MPU ist.

In einem Mobilfunksystem gemäß dem GSM-Standard bilden die SIM-Karte und das Mobile Equipment ME (Mobilfunkendgerät) zusammen eine Mobilstation (Mobile Station, MS). In einem Mobilfunksystem gemäß dem UMTS-Standard hingegen bilden die UICC (in deren ROM mehrere SIM und USIM liegen können) und das Mobile Equipment ME (Mobilfunkendgerät) zusammen das so genannte User Equipment UE (3GPP Terminologie, Teilnehmergerät).
Wird eine intelligente Mobilfunk-Chipkarte, wie eine SIM-Karte oder eine UICC, mit einem Mobile Equipment ME (Mobilfunkendgerät) verbunden, beispielsweise indem die Karte in das Gerät gesteckt wird, können die Applikationen (wie z. B. SIM, USIM, ISIM, etc.) auf der intelligenten Mobilfunk-Chipkarte mit dem Mobilfunkendgerät eine Vielzahl von Informationen austauschen. Einerseits kann das Mobilfunkendgerät Kommandos an die intelligente Mobilfunk-Chipkarte schicken, oder die intelligente Mobilfunk-Chipkarte kann das Mobilfunkendgerät über das Eintreten zuvor definierter Ereignisse in Kenntnis setzen. Den für diesen Zweck definierten generischen Befehlssatz nennt man CAT (Card Application Toolkit). Dort ist ganz allgemein von NAAs (Network Access Application; Netzwerk-Zugangs-Anwendungen) die Rede, die auf intelligenten Chipkarten – wie sie im Mobilfunk zum Einsatz kommen – installiert sein können. Im Falle von Mobilfunkendgeräten, die gemäß dem 2G-Standard GSM eingerichtet sind, handelt es sich bei der NAA um eine SIM, im Falle von Mobilfunkendgeräten, die gemäß dem 3G-Standard UMTS eingerichtet sind, handelt es sich bei der NAA um eine USIM. Die SIM bzw. USIM spezifischen CAT Erweiterungen werden als SAT (SIM Application Toolkit) und USAT (USIM Application Toolkit) bezeichnet.
Sowohl SAT für den 2G-Mobilfunk als auch USAT für den 3G-Mobilfunk werden in 3GPP standardisiert. Die Begriffe CAT, SAT und USAT umfassen in der Regel nicht nur einen Satz von Kommandos, welche über die Schnittstelle zwischen einer intelligente Mobilfunk-Chipkarte und einem Mobilfunkendgerät ausgetauscht werden können, sondern auch die zu einem bestimmten Befehlssatz passenden obligatorischen Prozeduren auf Seiten der Applikationen auf der Karte (wie z. B. SIM, USIM, etc.), als auch die passenden obligatorischen Funktionalitäten auf Seiten des Mobile Equipment ME (Mobilfunkendgeräts).
In der Regel teilt ein Mobilfunkendgerät einem sich auf einer intelligenten Mobilfunk-Chipkarte befindlichen SIM bzw. USIM die von ihm aktuell unterstützten optionalen SIM- bzw. USIM-spezifischen Funktionalitäten gleich nach dem Anschalten des Mobilfunkendgerätes im Rahmen des Profile Downloads mit. Anschaulich erfährt auf diese Weise das SIM bzw. USIM auf der Karte, „was das Mobilfunkendgerät alles kann” (Initiative geht vom Mobilfunkendgerät aus). Dies hat beispielsweise die Wirkung, dass das SIM bzw. das USIM sein Funktionsangebot optimal an das Mobilfunkendgerät anpassen kann, beispielsweise indem es den Umfang des SAT bzw. USAT Befehlsatzes einschränkt oder seinen Befehlsatz um optionale, aber vom Mobilfunkendgerät unterstützte Kommandos erweitert.
Ein Informationsaustausch ist auch in die andere Richtung möglich: Applikationen auf einer intelligenten Chipkarte, beispielsweise ein USIM, können auch einem Mobilfunkendgerät anzeigen, dass sie Daten an das Mobilfunkendgerät senden möchten (falls beide Seiten die so genannte UICC Proactive Command Funktionalität unterstützen). Technisch gesehen holt sich das Mobilfunkendgerät als Reaktion auf eine derartige Anzeige die Daten dann von der Chipkarte mittels eines ”Hole”(”Fetch”)-Befehls.
Die USIM durchläuft zunächst einen Initialisierungsprozess. Teil dieses Prozesses ist eine Abfrage der generell vom USIM unterstützten Dienste (USIM Service Table Request) bzw. der aktuell vom USIM freigegebenen Dienste (USIM Enabled Services Table Request) durch das Mobilfunkendgerät. Ein USIM-Dienst, der in diesen Service Tabellen als nicht verfügbar bzw. als nicht freigegeben gekennzeichnet ist, darf vom Mobilfunkendgerät nicht ausgewählt bzw. angesprochen werden.
Ein Ausführungsbeispiel der Erfindung umfasst weiterhin ein Verfahren, mittels dessen Kommunikationsmodule in einem Adhoc-Kommunikationsgerät gesteuert werden können.
7 zeigt in Verbindung mit 2A ein Verfahren 700 gemäß einem Ausführungsbeispiel der Erfindung zum Steuern eines Ad-hoc-Kommunikations-Funkmoduls 206, bei dem in 702 Steuerinformation eines Ad-hoc-Kommunikations-Empfangsschaltkreises 202 und/oder eines Ad-hoc-Kommunikations-Sendeschaltkreises, wie z. B. 204, mittels einer Ad-hoc-Kommunikationsprotokollstapel-externen Steuer-Schnittstelle 212 zugeführt wird, um gemäß 704 den Ad-hoc-Kommunikations-Empfangsschaltkreis 206 bzw. Ad-hoc-Kommunikations-Sendeschaltkreis 204 Ad-hoc-Kommunikationsprotokollstapel-extern zu steuern.
Durch das Verfahren können also im Gegensatz zu konventionellen Verfahren z. B. Ad-hoc-Kommunikations-Empfangsschaltkreise bzw. Ad-hoc-Kommunikations-Sendeschaltkreise von Applikationen außerhalb des Ad-hoc-Kommunikationsprotokolls gesteuert werden. Dies betrifft nicht nur das Funk-Kommunikationsmodul des Ad-hoc-Kommunikationsprotokolls, wie z. B. Bluetooth, sondern auch Kommunikationsmodule anderer Protokolle, wie in den folgenden Ausführungsbeispielen ausgeführt wird. Die Schnittstelle bildet hierbei den Zugang von und zu den Kommunikationsmodulen.
Da die Steuerung von außen z. B. auf einer Applikation beruht, erfolgt der Zugang über eine Schnittstelle zu einer Schicht unterhalb der Applikationsschicht des Kommunikationsprotokolls, wie z. B. dem L2CAP 324 im Falle von Bluetooth, unter Inanspruchnahme der Dienste dieser nächst tieferen Protokollschicht. Bei Ad-hoc-Kommunikationsprotokollen erfolgt diese Inanspruchnahme, wie bereits oben beschrieben, unter Verwendung von Dienstzugangspunkten.
Daher weist die Ad-hoc-Kommunikationsprotokollstapel-externe Steuer-Schnittstelle des Verfahrens 700 gemäß einem Ausführungsbeispiel mindestens einen Ad-hoc-Kommunikationsprotokollstapel-externen Dienstzugangspunkt auf.
Ein derartiger Zugangspunkt wurde bereits z. B. anhand der 1 erläutert und in einem Ausführungsbeispiel der Erfindung anhand 2A veranschaulicht, bei dem eine Applikation über den Dienstzugangspunkt 214 der Schnittstelle 212 den Sendeschaltkreis 204 bzw. den Empfangsschaltkreis 206 steuert.
Gemäß einem Ausführungsbeispiel weist die Ad-hoc-Kommunikationsprotokollstapel-externe Steuer-Schnittstelle 212 des Verfahrens 700 mehrere Ad-hoc-Kommunikationsprotokollstapel-externe Dienstzugangspunkte auf.
Beispiele für eine Steuer-Schnittstelle mit mehreren Dienstzugangspunkten wurden bereits weiter oben anhand der 5A, 5B, 5C, 5D und 5E vorgestellt, bei denen eine oder mehrere Applikationen in verschiedenen Kombinationen ein oder mehrere Sende- und/oder Empfangsschaltkreise steuern. Die in diesen Figuren gezeigten Beispiele und Ausführungen dazu können auch auf die nachfolgenden Ausführungsbeispiele für das Verfahren 700 übertragen werden.
Gemäß einem Ausführungsbeispiel ist das Ad-hoc-Kommunikations-Funkmodul 202 des Verfahrens 700 gemäß Bluetooth oder ZigBee eingerichtet.
Gemäß einem weiteren Ausführungsbeispiel wird die Steuerinformation des Verfahrens 700 einer Steuerung 502 zugeführt, wobei die Steuerung 502 den Ad-hoc-Kommunikations-Empfangsschaltkreis 206 und/oder den Ad-hoc-Kommunikations-Sendeschaltkreis 204 und/oder einen zusätzlichen Empfangsschaltkreis 506 und/oder einen zusätzlichen Sendeschaltkreis 504 steuert.
Gemäß einem Ausführungsbeispiel des Verfahrens ist der mindestens eine zusätzliche Empfangsschaltkreis 506 und/oder der mindestens eine zusätzliche Sendeschaltkreis 504 des Verfahrens gemäß einer anderen Funktechnologie als der Ad-hoc-Kommunikations-Empfangsschaltkreis 206 bzw. der Ad-hoc-Kommunikations-Sendeschaltkreis 204 eingerichtet.
Gemäß einem Ausführungsbeispiel ist der mindestens eine zusätzliche Empfangsschaltkreis 506 und/oder der mindestens eine zusätzliche Sendeschaltkreis 504 des Verfahrens gemäß einer Ultra-Breitband-Funktechnologie (z. B. gemäß den Standards ECMA-368 und ECMA-369 der WiMedia Alliance) oder einer Drahtlos-Lokales-Netzwerk-Funktechnologie (z. B. gemäß IEEE 802.11 b/g) eingerichtet.
Im Nachfolgenden werden detaillierte Ausführungsbeispiele der Erfindung erläutert.
8A zeigt eine beispielhafte Übersicht von Funktionsblöcken in einem ersten Gesamtsystem (Gerät D) 800, aufweisend eine erste Applikation AP1 802, welche sich im Einflussbereich eines TPM 806 befindet und dadurch als vertrauenswürdig einzustufen ist, ein Bluetooth Host Subsystem 810, welches einen AMP Manager 814 umfasst, und mehrere Bluetooth Controller Subsysteme Cl1 816 bis Cln 818. Der Einflussbereich des TPM 806 wird vereinfacht durch den gestrichelten Kasten („Trusted Computing Platform”) 808 dargestellt. Ebenfalls im Einflussbereich des TPM 806 befindet sich eine Funktionseinheit zur Standortbestimmung 804 des Geräts D 800, welches beispielsweise ein GPS-Modul sein könnte („Location Module”).
Alle Funktionsblöcke im Einflussbereich TCP 808 des TPMs 806 kommunizieren in dieser vereinfachten Darstellung über die Schnittstellen Iint 822, 820 miteinander. Die erste Applikation AP1 802 kommuniziert mit dem AMP Manager 814 im Bluetooth Host Subsystem 810 über die Schnittstelle I2 824. Der neue Dienstzugangspunkt SAPext 830 für externe Zugriffe auf das Bluetooth System wird in 8A als dedizierter Dienstzugangspunkt SAPext 830 in den Bluetooth Core Layer (L2CAP-Schicht 324 aus 3) gezeigt und liegt somit auf der gleichen Ebene wie beispielsweise der AMP Manager SAP 320 aus 3.
8B zeigt eine beispielhafte Übersicht von Funktionsblöcken in einem zweiten Gesamtsystem ME 840, aufweisend eine UICC 850, welche hier stellvertretend für eine intelligente Mobilfunk-Chipkarte steht, mit einer vertrauenswürdigen ersten Applikation AP1 848, ein Mobilfunkendgerät 854, welches beispielsweise gemäß dem Mobilfunkstandard UMTS eingerichtet ist, mit einer zweiten Applikation AP2 844, ein Bluetooth Host Subsystem 810, welches einen AMP Manager 814 umfasst, und mehrere Bluetooth Controller Subsystemen Cl1 816 bis Cln 818. Ferner umfasst die UICC 850 noch eine Funktionseinheit 852 zur Standortbestimmung des Mobilfunkendgeräts (ME) 854, welches beispielsweise ein GPS-Modul sein könnte („Location Module”). Die erste Applikation AP1 848 kommuniziert mit der zweiten Applikation AP2 844 über eine erste Schnittstelle I1 846. Wenn man die Begriffe CAT, SAT und USAT wie oben bereits erläutert weiter fasst, beinhalten diese nicht nur die über die Schnittstelle I1 846 ausgetauschten Nachrichten, sondern auch die zu einem bestimmten Befehlssatz passenden obligatorischen Prozeduren, sowohl auf Seite der ersten Applikation AP1 848 (d. h. auf der intelligente Mobilfunk-Chipkarte), als auch auf Seite der zweiten Applikation AP2 844 (d. h. im Mobilfunkendgerät ME 854).
Das in 8B gezeigte USAT (gestrichelter Kasten) 842 umfasst aus diesem Grund auch die beiden Applikationen AP1 848 und AP2 844, in denen die zum Befehlssatz gehörigen Funktionalitäten implementiert sind. Das Mobilfunkendgerät (ME) 854 kommuniziert mit dem AMP Manager 814 über eine zweite Schnittstelle I2 824. Zu diesem Zweck weist der Bluetooth Core Layer (L2CAP-Schicht) einen dedizierten Dienstzugangspunkt SAPext 830 auf, durch den das konventionelle geschlossene Bluetooth System gemäß einem Ausführungsbeispiel der Erfindung nach außen hin zum Zwecke einer Beeinflussung durch eine erste vertrauenswürdige Applikation AP1 848 und/oder eine zweite (unter Umständen ebenfalls vertrauenswürdige) Applikation AP2 844 geöffnet wird. Auf diese Weise können Kommandos bzw. Nachrichten, welche das Mobilfunkendgerät (ME) 854 in einer ersten Phase über ein CAT/SAT/USAT von einer intelligenten Mobilfunk-Chipkarte erhalten hat, von dem Mobilfunkendgerät (ME) 854 in einer zweiten Phase an logische Funktionseinheiten innerhalb des Bluetooth Host Subsystems 810, wie beispielsweise dem AMP Manager 814 oder andere zukünftig noch zu definierende logische Funktionseinheiten, und in umgekehrter Richtung übergeben werden.
Besonders vorteilhaft ist die Definition des externen Dienstzugangspunktes SAPext 830 am oberen Ende der L2CAP Schicht (Bluetooth Core Layer 324 aus 3), wie es die 8A und 8B zeigen. Wie oben bereits erläutert, kann in einem zukünftigen realen System ein Dienstzugangspunkt auch den jeweils anderen umfassen. Insbesondere kann der neue SAPext 830 Funktionen des AMP Manager SAPs 320 oder des L2CAP AMP SAPs 318 oder der Ranging SAPs 322 ganz oder teilweise umfassen.
8C zeigt eine beispielhafte Übersicht von Funktionsblöcken in einem dritten Gesamtsystem ME 860, das im Unterschied zu der in 8B gezeigten Anordnung nur ein lokales Bluetooth Controller Subsystem 818 aufweist. Somit wird der Dienstzugangspunkt SAPext 830 z. B. genutzt, um ein Bluetooth-System, das wie die bisherigen, konventionellen Bluetooth-Systeme lediglich ein Funksende- und/oder Empangsmodul im Bluetooth Controller Subsystem beinhaltet, dieses Funksende- und/oder Empangsmodul, hier alleinig repräsentiert durch das Modul 818, durch die Applikation AP1 848 bzw. die Applikation AP2 844 von außen (ggf. unter Einbeziehung des AMP Managers 814) zu steuern.
Das Funksende- und/oder Empangsmodul 818 ist in diesem Beispiel ein Bluetooth-Modul, es wäre aber auch ein Modul eines anderen Protokolls bzw. Standards in einem alternativen Ausführungsbeispiel der Erfindung denkbar.
Das Bluetooth Host Subsystem 810 kommuniziert in den obigen Beispielen mit den einzelnen Bluetooth Controller Subsystemen 816, 818 über die Schnittstelle I3 826, welche üblicherweise als HCI gemäß der Bluetooth-Spezifikation ausgebildet ist. Es existieren auch Implementierungen, in denen ein (oder mehrere) Bluetooth Controller Subsysteme) mit dem Bluetooth Host Subsystem 810 enger verschmolzen ist (sind). In diesen Fällen tritt die Schnittstelle I3 826 nach außen hin nicht in Erscheinung.
Jedes Sende-/Empfangsmodul in einem Endgerät (beispielsweise einem Mobilfunkendgerät) soll gemäß verschiedenen Ausführungsbeispielen der Erfindung mit einem 1 Byte großen, lokal individuellen Identifikationsmerkmal versehen werden, wobei das Byte mit dem Wert ,0' den Legacy Bluetooth Controller bei 2.4 GHz spezifiziert. Aus dem Identifikationsmerkmal geht in der Regel nicht der Typ des Sende-/Empfangsmoduls hervor.
In Entsprechung zu den 5A, 5B, 5C, 5D, und 5E lassen sich in Abhängigkeit von der Anzahl an vorhandenen Dienstzugriffspunkten, Applikationen und Sende- und Empfangsschaltkreise die unterschiedlichsten Varianten erarbeiten, die sich sehr leicht aus den 5A, 5B, 5C, 5D, und 5E sowie 8A, 8B, und 8C bzw. deren Beschreibung ableiten lassen und daher nicht gesondert aufgezeigt werden.
Die folgenden Nachrichtenflussdiagramme 900, 1000, 1100, 1200 und 1300 beschreiben den Austausch von Steuerkommandos und Ereignismeldungen basierend auf dem beispielhaften Gesamtsystem 840 gemäß 8B, d. h. es werden Bluetooth relevante Information sukzessive über die beiden Schnittstellen I1 846 und I2 824 ausgetauscht, wobei der Datentransfer über die erste Schnittstelle I1 846 durch CAT, SAT und USAT Erweiterungen realisiert wird. Gegebenenfalls ist eine Anpassung der auszutauschenden Informationen an die jeweils andere Schnittstelle nötig. Diese Aufgabe wird von Applikation AP2 844 durchgeführt. Auch Applikation AP2 844 kann im Einflussbereich einer TCP 842 liegen. Dies ist in 8B aus Gründen einer besseren Übersichtlichkeit nicht dargestellt.
Eine Übertragung der im Folgenden gezeigten Nachrichtenflussdiagramme 900, 1000, 1100, 1200 und 1300 auf das erste beispielhafte Gesamtsystem 800 nach 8A, bei dem die Bluetooth relevanten Steuerkommandos und Ereignismeldungen lediglich über die Schnittstelle I2 824 ausgetauscht werden, ist trivial. Deshalb wird an dieser Stelle auf eine ausführliche Behandlung von Nachrichtenflussdiagrammen für 8A verzichtet.
A) Nachrichtenflussdiagramm 900: Entdecken von AMP Technologien
9 zeigt den Austausch von Nachrichten zwischen den drei Hauptfunktionsblöcken (Applikation AP1 848, Applikation AP2 844 und AMP Manager 814) im Gesamtsystem 840 oder 860 zum Zwecke des Entdeckens aktuell am lokalen Bluetooth Host Subsystem 810 angeschlossener (d. h. aktuell lokal verfügbarer) Sende-/Empfangsmodule Cl1 816 bis Cln 818 (der Index ,l' steht für ,lokal') bzw. zum Zwecke des Entdeckens momentan in benachbarten Geräten verfügbarer Sende-/Empfangsmodule Cb1 bis Cbn (der Index ,b' steht für ,benachbart'). Das Entdecken der in benachbarten Geräten momentan verfügbaren Sende-/Empfangsmodule Cb1 bis Cbn erfolgt beispielsweise über den herkömmlichen Bluetooth Controller bei 2,4 GHz (lokales individuelles Identifikationsmerkmal: Byte mit dem Wert ,0').
In 902 sendet die Applikation AP1 848, die sich beispielsweise auf einer intelligenten Mobilfunk-Chipkarte befindet, eine Nachricht vom Typ Discover_Available_AMPs, welche beispielsweise mindestens eine der in Tabelle 2 gezeigten Informationen enthalten soll, über die Schnittstelle I1 846 an das Mobilfunkgerät 854. Tabelle 3 zeigt den möglichen Aufbau einer passenden Empfangsbestätigung_1.

Technisch gesehen zeigt die intelligente Mobilfunk-Chipkarte dem Mobilfunkendgerät ME 854 zunächst an, dass sie Daten an das Mobilfunkendgerät 854 verschicken möchte. Dieses holt sich die bereitliegenden Daten danach (im Rahmen der „UICC Proactive Command” Funktionalität) mittels eines ”Hole”(”Fetch”)-Befehls. Zur Vereinfachung sind in 9 aber nur zwei Nachrichten gezeigt: Mit der ersten Nachricht (durchgezogener Pfeil) wird der Discover_Available_AMPs Befehl an das Mobilfunkgerät 854 geschickt, mit der zweiten Nachricht (gestrichelter Pfeil) kann eine Empfangsbestätigung_1 (optional) vom Mobilfunkgerät 854 an die intelligente Mobilfunk-Chipkarte 850 geschickt werden, um den fehlerfreien Empfang des Befehls zu quittieren bzw. um eine fehlerhafte Übertragung zu melden (inkl. Fehlercode).

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als Discover_Available_AMPs.
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
SAPI	Obligatorisch	Identifiziert den Service Access Point (SAP) in den Bluetooth Core Layer.
AMP-Manager-ID	Obligatorisch	Identifiziert den AMP Manager.
Sende-Instanz-ID	Obligatorisch	Identifiziert die anfragende Applikation auf der Chipkarte.
Bluetooth Device Address	Optional	Ermöglicht die Angabe der BD-ADDR gemäß Bluetooth-Spezifikation.
Interne Abfrage	Optional	Einschalten und Ausschalten der Entdeckung aktuell lokal verfügbarer Sende-/Empfangsmodule Cl1 bis Cln.
Externe Abfrage	Optional	Einschalten und Ausschalten der Entdeckung momentan verfügbarer Sende-/Empfangsmodule Cb1 bis Cbn in benachbarten Geräten.
Ergebnisformat	Optional	Ermöglicht die Angabe des gewünschten Formates für die Übergabe der Ergebnisse.
Rückmeldung	Optional	Ermöglicht die Anfrage einer Statusmeldung durch die anfragende Applikation AP1 auf der Chipkarte.

Tabelle 2: Mögliche Informationselemente in der Nachricht Discover_Available_AMPs, welche von einer Applikation AP1 (Mobilfunk-Chipkarte) über die CAT/SAT/USAT Schnittstelle I1 an eine Applikation AP2 (Mobilfunkendgerät) übergeben werden.

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als Empfangsbestätigung_1
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
Empfangs-Instanz-ID	Obligatorisch	Identifiziert die anfragende Applikation auf der Chipkarte.
Statusmeldung	Optional	Gibt an, ob die Anfrage wie gewünscht von Applikation AP2 ausgeführt werden konnte. Enthält gegebenenfalls einen Fehlercode.

Tabelle 3: Mögliche Informationselemente in der Empfangsbestätigung_1, mit der die Applikation AP2 der Applikation AP1 antworten kann (optional).

In 904 reicht die Applikation AP2 844 die Informationen des Discover_Available_AMPs Befehls, welche sie über CAT/SAT/USAT erhalten hat, ganz oder teilweise an den AMP Manager 814 weiter. Dazu werden die Informationen gegebenenfalls noch für eine Übertragung über die I2 Schnittstelle 824 entsprechend aufbereitet. Die Informationen werden dem AMP Manager 814 über einen dedizierten SAP 830 zugeführt (vergleiche Informationselement „SAPI” in Tabelle 2). Auf Basis der im Discover_Available_AMPs Befehl enthaltenen Randbedingungen (beispielsweise ausgedrückt durch die Informationselemente „Interne Abfrage” oder „Externe Abfrage” in Tabelle 2 ermittelt der AMP Manager 814 alle lokal verfügbaren Sende-/Empfangsmodule Cl1 816 bis Cln 818 und/oder alle verfügbaren Sende-/Empfangsmodule auf benachbarten Geräten Cb1 bis Cbn. Die so gewonnene Liste gibt er in dem gewünschten Ausgabeformat (beispielsweise spezifiziert durch das Informationselement „Ergebnisformat” in Tabelle 2) über den dedizierten SAP 830 zurück an die Applikation AP2 844, wo eine CAT/SAT/USAT-gemäße Aufbereitung der Daten erfolgt. Gemäß einem Ausführungsbeispiel der Erfindung enthält die vom AMP Manager 814 erstellte Liste ein Identifikationsmerkmal und eine Intern/Extern-Kennung für jedes gefundene Sende-/Empfangsmodul. Alternativ dazu können auch zwei getrennte Listen (eine für interne Sende-/Empfangsmodule 816, 818, eine für externe Sende-/Empfangsmodule) mit Identifikationsmerkmalen zurückgegeben werden.

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als Discovered_AMPs.
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
SAPI	Obligatorisch	Identifiziert den Service Access Point (SAP) des Bluetooth Core Layers, von dem diese Informationen stammen.
Sende-Instanz-ID	Obligatorisch	Identifiziert die sendende Applikation im Mobilfunkendgerät.
AMP-Manager-ID	Optional	Identifiziert den AMP Manager.
Bluetooth Device Address	Optional	Ermöglicht die Angabe der BD-ADDR gemäß Bluetooth-Spezifikation.
Interne Ergebnisliste	Optional	Identifikationsmerkmale aller detektierten lokalen Sende-/Empfangsmodule.
Externe Ergebnisliste	Optional	Identifikationsmerkmale aller detektierten verfügbaren Sende-/Empfangsmodule auf benachbarten Geräten.
Zeitstempel	Optional	Zeitinformation, wann die Detektion von verfügbaren Sende-/Empfangsmodulen durchgeführt wurde.
Rückmeldung	Optional	Ermöglicht die Anfrage einer Statusmeldung durch die anfragende Applikation AP2 im Mobilfunkendgerät.

Tabelle 4: Mögliche Informationselemente in der Nachricht Discovered_AMPs, welche von einer Applikation AP2 (Mobilfunkendgerät) über die CAT/SAT/USAT Schnittstelle I1 an eine Applikation AP1 (Mobilfunk-Chipkarte) übergeben werden.

In 906 reicht die Applikation AP2 844 mit einer ersten Nachricht vom Typ_Discovered_AMPs (durchgezogener Pfeil) die vom AMP Manager 814 erhaltenen Daten mittels CAT/SAT/USAT an die intelligente Mobilfunk-Chipkarte 850 weiter (Tabelle 4). Hierfür werden die Informationen eventuell wieder für die Übertragung über die I1 846 Schnittstelle von Applikation AP2 844 entsprechend aufbereitet. Die Applikation AP1 848 kann danach optional eine zweite Nachricht vom Typ Empfangsbestätigung_2 an das Mobilfunkgerät zurückschicken (gestrichelter Pfeil), um entweder den fehlerfreien Empfang der Discovered_AMPs Nachricht zu quittieren bzw. um eine fehlerhafte Übertragung zu melden (inkl. Fehlercode). Tabelle 5 zeigt einen möglichen Aufbau der zweiten Nachricht des Typs Empfangsbestätigung_2.

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als Empfangsbestätigung_2
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
Empfangs-Instanz-ID	Obligatorisch	Identifiziert die Applikation im Mobilfunkendgerät
Statusmeldung	Optional	Gibt an, ob die von Applikation AP2 gesendete Nachricht die Applikation AP1 fehlerfrei erreicht hat. Enthält gegebenenfalls einen Fehlercode.

Tabelle 5: Mögliche Informationselemente in der Empfangsbestätigung_2, mit der die Applikation AP1 (Mobilfunk-Chipkarte) der Applikation AP2 (Mobilfunkendgerät) antworten kann (optional).

Zum Zeitpunkt 908 hat Applikation AP1 848 und damit auch andere, beispielsweise vom Netzbetreiber kontrollierte Applikationen auf der intelligenten Mobilfunk-Chipkarte Kenntnis sowohl über die lokal verfügbaren Sende-/Empfangsmodule, als auch über die verfügbaren Sende-/Empfangsmodule auf benachbarten Geräten. Konkret bedeutet dies beispielsweise, dass Applikation AP1 848 und andere auf der intelligenten Mobilfunk-Chipkarte 850 residierende Applikationen den AMP Manager 814 im Bluetooth Host Subsystem 810 des Mobilfunkendgerätes 854 gezielt ansprechen können, um Details einzelner Sende-/Empfangsmodule 816, 818 in Erfahrung zu bringen, bzw. um auf das Verhalten einzelner Sende-/Empfangsmodule 816, 818 gezielt Einfluss zu nehmen.
B) Nachrichtenflussdiagramm 1000: Meldung einer Zustandsänderung
10 zeigt den Austausch von Nachrichten zwischen den drei Hauptfunktionsblöcken (Applikation AP1 848, Applikation AP2 844 und AMP Manager 814) im Gesamtsystem 840, 860 zum Zwecke des Meldens einer Änderung hinsichtlich der Verfügbarkeit lokaler und/oder benachbarter Sende-/Empfangsmodule. Dieser Fall tritt beispielsweise dann ein, wenn ein Bluetooth Controller Subsystem Cx über eine flexible Kabelverbindung (z. B. als USB-Dongle) mit einem Bluetooth Host Subsystem auf dem lokalen oder einem benachbarten Gerät verbunden worden war und diese Kabelverbindung nun gelöst worden ist. War das entfernte Bluetooth Controller Subsystem Cx an dem lokalen Bluetooth Host Subsystem angeschlossen, so erfährt der lokale AMP Manager 814 dies unmittelbar. War hingegen das entfernte Bluetooth Controller Subsystem Cx dem Bluetooth Host Subsystem eines benachbarten Geräts angeschlossen, so kann der lokale AMP Manager 814 über die Luftschnittstelle über dieses Ereignis informiert werden, indem ein anderes noch arbeitsfähiges Bluetooth Controller Subsystem zur Hilfe genommen wird, beispielsweise das Legacy Bluetooth Controller Paar, welches bei 2.4 GHz operiert (lokales individuelles Identifikationsmerkmal: Byte mit dem Wert ,0').

In 1002 stellt der lokale AMP Manager 814 fest, dass ein lokales Bluetooth Controller Subsystem Clx 816, 818 entfernt worden ist, oder dass ein Bluetooth Controller Subsystem Cbx auf einem benachbarten Gerät nicht mehr verfügbar ist.

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als AMP_Configuration_Change.
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
SAPI	Obligatorisch	Identifiziert den Service Access Point (SAP) des Bluetooth Core Layers, von dem diese Informationen stammen.
Empfangs-Instanz-ID	Obligatorisch	Identifiziert die empfangende Applikation im Mobilfunkendgerät.
AMP-Manager-ID	Optional	Identifiziert den AMP Manager.
Bluetooth Device Address	Optional	Ermöglicht die Angabe der BD-ADDR gemäß Bluetooth-Spezifikation.
Interne Ereignisliste	Optional	Liste bzw. Tabelle mit Ereignissen, welche die lokalen Sende-/Empfangsmodule betreffen (Beispiel: Local AMP-Manager ID/Local AMP Nummer/Local AMP Status.
Externe Ereignisliste	Optional	Liste bzw. Tabelle mit Ereignissen, welche Sende-/Empfangsmodule auf benachbarten Geräten betreffen (Beispiel: Remote AMP-Manager ID/Remote AMP Nummer/Remote AMP Status).
Zeitstempel	Optional	Zeitinformation, wann die Änderung der AMP Konfiguration detektiert worden ist.
Rückmeldung	Optional	Ermöglicht die Anfrage einer Statusmeldung.

Tabelle 6: Mögliche Informationselemente in der Nachricht AMP_Configuration_Change, welche von einem lokalen AMP Manager über einen dedizierten SAP (und danch über die Schnittstelle I2) an eine Applikation AP2 (im Mobilfunkendgerät) übergeben werden.

In 1004 informiert der lokale AMP Manager 814 die Applikation AP2 844 unter Einsatz des AMP_Configuration_Change Befehls über das in 1002 eingetretene Ereignis.

Tabelle 6 zeigt einige Informationselemente, die gemäß verschiedenen Ausführungsbeispielen der Erfindung mindestens in der Nachricht vom Typ AMP_Configuration_Change enthalten sein sollten. Die Applikation AP2 844 kann danach optional eine zweite Nachricht vom Typ Empfangsbestätigung_3 an den AMP Manager 814 zurückschicken (gestrichelter Pfeil), um entweder den fehlerfreien Empfang der AMP_Configuration_Change Nachricht zu quittieren oder um eine fehlerhafte Übertragung zu melden (inkl. Fehlercode). Tabelle 7 zeigt einen möglichen Aufbau dieser zweiten Nachricht. Beide dieser Nachrichten werden über einen dedizierten SAP, wie beispielsweise dem SAPext ausgetauscht.

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als Empfangsbestätigung_3
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
Sende-Instanz-ID	Obligatorisch	Identifiziert die Applikation im Mobilfunkendgerät.
AMP-Manager-ID	Optional	Identifiziert den AMP Manager.
Statusmeldung	Optional	Gibt an, ob die vom AMP Manager gesendete Nachricht die Applikation AP2 fehlerfrei erreicht hat. Enthält gegebenenfalls einen Fehlercode.

Tabelle 7: Mögliche Informationselemente in der Empfangsbestätigung_3, mit der die Applikation AP2 dem AMP Manager antworten kann (optional).

In 1006 bereitet die Applikation AP2 844 die in 1004 empfangenen Informationen gegebenenfalls für die Übertragung über die I1 Schnittstelle 846 entsprechend auf. Anschließend sendet Applikation AP2 844 mit der Nachricht vom Typ AMP_Configuration_Change_2 die zuvor empfangenen Informationen – eventuell leicht modifiziert – mittels CAT/SAT/USAT über die Schnittstelle I1 846 an die intelligente Mobilfunk-Chipkarte 850 (Tabelle 8).

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als AMP_Configuration_Change_2.
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
SAPI	Obligatorisch	Identifiziert den Service Access Point (SAP) des Bluetooth Core Layers, von dem diese Informationen stammen.
Empfangs-Instanz-ID	Obligatorisch	Identifiziert die empfangende Applikation auf der Chipkarte.
Sende-Instanz-ID	Obligatorisch	Identifiziert die Applikation im Mobilfunkendgerät.
AMP-Manager-ID	Optional	Identifiziert den AMP Manager.
Bluetooth Device Address	Optional	Ermöglicht die Angabe der BD-ADDR gemäß Bluetooth-Spezifikation
Interne Ereignisliste	Optional	Liste bzw. Tabelle mit Ereignissen, welche die lokalen Sende-/Empfangsmodule betreffen (Beispiel: Local AMP-Manager ID/Local AMP Nummer/Local AMP Status.
Externe Ereignisliste	Optional	Liste bzw. Tabelle mit Ereignissen, welche Sende-/Empfangsmodule auf benachbarten Geräten betreffen (Beispiel: Remote AMP-Manager ID/Remote AMP Nummer/Remote AMP Status).
Zeitstempel	Optional	Zeitinformation, wann die Änderung der AMP Konfiguration detektiert worden ist.
Rückmeldung	Optional	Ermöglicht die Anfrage einer Statusmeldung.

Tabelle 8: Mögliche Informationselemente in der Nachricht AMP_Configuration_Change_2, welche von einer Applikation AP2 (Mobilfunkendgerät) über die CAT/SAT/USAT Schnittstelle I1 an eine Applikation AP1 848 (Mobilfunk-Chipkarte) übergeben werden.

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als Empfangsbestätigung_4
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
Sende-Instanz-ID	Obligatorisch	Identifiziert die empfangende Applikation auf der Chipkarte.
Empfangs-Instanz-ID	Obligatorisch	Identifiziert die Applikation im Mobilfunkendgerät.
AMP-Manager-ID	Optional	Identifiziert den AMP Manager.
Statusmeldung	Optional	Gibt an, ob die von Applikation AP2 gesendete Nachricht die Applikation AP1 fehlerfrei erreicht hat. Enthält gegebenenfalls einen Fehlercode.

Tabelle 9: Mögliche Informationselemente in der Empfangsbestätigung_4, mit denen die Applikation AP1 (Mobilfunk-Chipkarte) der Applikation AP2 844 (Mobilfunkendgerät) antworten kann (optional).

Tabelle 9 zeigt einige Informationselemente, die gemäß verschiedenen Ausführungsbeispielen der Erfindung mindestens in der Nachricht vom Typ Empfangsbestätigung_4 enthalten sein könnten (gestrichelter Pfeil in 1000).
Zum Zeitpunkt 1008 hat die Applikation AP1 848 und damit auch andere, beispielsweise vom Netzbetreiber kontrollierte Applikationen auf der intelligenten Mobilfunk-Chipkarte 850 Kenntnis über Konfigurationsänderungen hinsichtlich lokal verfügbarer Sende-/Empfangsmodule bzw. hinsichtlich verfügbarer Sende-/Empfangsmodule auf benachbarten Geräten. Konkret bedeutet dies, dass Applikation AP1 848 und andere auf der intelligenten Mobilfunk-Chipkarte 850 residierende Applikationen den AMP Manager 814 im Bluetooth Host Subsystem des Mobilfunkendgerätes gezielt ansprechen können, um auf diese Änderungen zu reagieren.
Der Empfang einer Nachricht des Typs AMP_Configuration_Change_2, welche die Informationen (Local = lokal; Remote = entfernt)
enthält, könnte beispielsweise bewirken, dass die Applikation AP1 848 keine weiteren Datenübertragungen über das (in der internen Ereignisliste) direkt identifizierte lokale Sende-/Empfangsmodul, z. B. das Modul 816 aufbaut bzw. über dasjenige lokale Sende-/Empfangsmodul, welches mit dem (in der externen Ereignisliste) identifizierten Sende-/Empfangsmodul auf einem benachbarten Gerät in Verbindung steht, initiiert.
C) Nachrichtenflussdiagramm 1100: Details bestimmter Sende-/Empfangsmodule in Erfahrung bringen
11 zeigt den Austausch von Nachrichten zwischen den drei Hauptfunktionsblöcken (Applikation AP1 848, Applikation AP2 844 und AMP Manager 814) im Gesamtsystem 840, 860, daraufhin abzielend, bestimmte Details der aktuell am lokalen Bluetooth Host Subsystem angeschlossenen Sende-/Empfangsmodule Cl1 816 bis Cln 818 (der Index ,l' steht für ,lokal') bzw. der in benachbarten Geräten verfügbaren Sende-/Empfangsmodule Cb1 bis Cbn (der Index ,b' steht für ,benachbart') in Erfahrung zu bringen. Im Falle von Sende-/Empfangsmodule Cb1 bis Cbn in benachbarten Geräten geschieht dies idealerweise über das herkömmliche Bluetooth Controller Paar (lokales individuelles Identifikationsmerkmal: Byte mit dem Wert ,0'), welches bei 2,4 GHz operiert.
In 1102 sendet die Applikation AP1 848, die sich beispielsweise auf einer intelligenten Mobilfunk-Chipkarte 850 befindet, eine Nachricht vom Typ Get_AMP_Info an das Mobilfunkgerät 854, welche gemäß verschiedenen Ausführungsbeispielen der Erfindung mindestens eine der in Tabelle 10 gezeigten Informationen enthalten soll. Tabelle 11 zeigt den möglichen Aufbau einer passenden Empfangsbestätigung_5.

Technisch gesehen zeigt auch hier wieder die intelligente Mobilfunk-Chipkarte 850 dem Mobilfunkendgerät ME 854 zunächst an, dass sie Daten an das Mobilfunkendgerät 854 verschicken möchte. Dieses holt sich die bereitliegenden Daten danach (im Rahmen der UICC Proactive Command Funktionalität) mittels eines Fetch-Befehls. Zur Vereinfachung sind in 8 aber nur zwei Nachrichten in 1102 gezeigt: Mit der ersten Nachricht (durchgezogener Pfeil) wird der Get_AMP_Info Befehl an das Mobilfunkgerät 854 geschickt, mit der zweiten Nachricht (gestrichelter Pfeil) kann eine Empfangsbestätigung_5 (optional) vom Mobilfunkgerät 854 an die intelligenten Mobilfunk-Chipkarte 850 geschickt werden, um den fehlerfreien Empfang des Befehls zu quittieren bzw. um eine fehlerhafte Übertragung zu melden (inkl. Fehlercode).

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als Get_AMP_Info.
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
SAPI	Obligatorisch	Identifiziert den Service Access Point (SAP) in den Bluetooth Core Layer.
AMP-Manager-ID	Obligatorisch	Identifiziert den AMP Manager.
Sende-Instanz-ID	Obligatorisch	Identifiziert die anfragende Applikation auf der Chipkarte.
Bluetooth Device Address	Optional	Ermöglicht die Angabe der BD-ADDR gemäß Bluetooth-Spezifikation.
Interne Abfrageliste	Optional	Tabelle, in der diejenigen lokalen Sende-/Empfangsmodule gelistet sind, deren Eigenschaften abgefragt werden sollen (Beispiel: Local AMP-Manager ID/Local AMP Nummer).
Externe Abfrageliste	Optional	Tabelle, in der diejenigen Sende-/Empfangsmodule auf benachbarten Geräten gelistet sind, deren Eigenschaften abgefragt werden sollen (Beispiel: Remote AMP-Manager ID/Remote AMP Nummer).
Ergebnisformat	Optional	Ermöglicht die Angabe des gewünschten Formates für die Übergabe der Abfrageergebnisse.
Rückmeldung	Optional	Ermöglicht die Anfrage einer Statusmeldung durch die anfragende Applikation AP1 auf der Chipkarte.

Tabelle 10: Mögliche Informationselemente in der Nachricht Get_AMP_Info, welche von einer Applikation AP1 (Mobilfunk-Chipkarte) über die CAT/SAT/USAT Schnittstelle I1 an eine Applikation AP2 (Mobilfunkendgerät) übergeben werden.

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als Empfangsbestätigung_5
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
Empfangs-Instanz-ID	Obligatorisch	Identifiziert die anfragende Applikation auf der Chipkarte.
Statusmeldung	Optional	Gibt an, ob die Anfrage wie gewünscht von Applikation AP2 ausgeführt werden konnte. Enthält gegebenenfalls einen Fehlercode.

Tabelle 11: Mögliche Informationselemente in der Empfangsbestätigung_5, mit der die Applikation AP2 (Mobilfunkendgerät) der Applikation AP1 (Mobilfunk-Chipkarte) antworten kann (optional).

In 1104 reicht die Applikation AP2 844 die Informationen des Get_AMP_Info Befehls, welche sie über die CAT/SAT/USAT Schnittstelle I1 846 erhalten hat, ganz oder teilweise an den AMP Manager 814 weiter. Zuvor werden die Informationen gegebenenfalls für eine Übertragung über die I2 Schnittstelle 842 entsprechend aufbereitet. Die Informationen werden dem AMP Manager 814 über einen dedizierten SAP 830 zugeführt (vergleiche Informationselement „SAPI” in Tabelle 10). Auf Basis der im Get_AMP_Info Befehl enthaltenen Randbedingungen (beispielsweise ausgedrückt durch die Informationselemente „Interne Abfrageliste” oder „Externe Abfrageliste” in Tabelle 10) ermittelt der AMP Manager 814 die gewünschten Eigenschaften der referenzierten lokal verfügbaren Sende-/Empfangsmodule Cl1 816 bis Cln 818 und/oder die gewünschten Eigenschaften der referenzierten Sende-/Empfangsmodule auf benachbarten Geräten Cb1 bis Cbn. Die so gewonnenen Abfrageergebnisse gibt er in dem gewünschten Ausgabeformat (beispielsweise spezifiziert durch das Informationselement „Ergebnisformat” in Tabelle 10) über den dedizierten SAP 830 zurück an die Applikation AP2 844, wo gegebenenfalls eine CAT/SAT/USAT gemäße Aufbereitung der Daten erfolgt. Gemäß verschiedenen Ausführungsbeispielen der Erfindung soll die vom AMP Manager 814 erstellte Liste ein Identifikationsmerkmal, eine Intern/Extern-Kennung und die ermittelten Eigenschaften der einzelnen Sende-/Empfangsmodule enthalten. Alternativ dazu können auch zwei getrennte Listen (eine für interne Sende-/Empfangsmodule und eine für externe Sende-/Empfangsmodule) mit Identifikationsmerkmalen und den ermittelten Eigenschaften zurückgegeben werden.

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als AMP_Info.
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
SAPI	Obligatorisch	Identifiziert den Service Access Point (SAP) des Bluetooth Core Layers, von dem diese Informationen stammen.
Sende-Instanz-ID	Obligatorisch	Identifiziert die sendende Applikation im Mobilfunkendgerät.
AMP-Manager-ID	Optional	Identifiziert den AMP Manager.
Bluetooth Device Address	Optional	Ermöglicht die Angabe der BD-ADDR gemäß Bluetooth-Spezifikation.
Eigenschaften interner AMPs	Optional	Liste mit Eigenschaften der lokalen Sende-/Empfangsmodule (Beispiel: Local-AMP-Manager-ID/Local-AMP-Nummer/AMP-Properties-Container).
Eigenschaften externer AMPs	Optional	Liste mit Eigenschaften von Sende-/Empfangsmodulen auf benachbarten Geräten (Beispiel: Remote-AMP-Manager-ID/Remote-AMP-Nummer/AMP-Properties-Container).
Zeitstempel	Optional	Zeitinformation, wann die Eigenschaften der Sende-/Empfangsmodulen ermittelt wurden.
Rückmeldung	Optional	Ermöglicht die Anfrage einer Statusmeldung durch die anfragende Applikation AP2 im Mobilfunkendgerät.

Tabelle 12: Mögliche Informationselemente in der Nachricht AMP_Info, welche von einer Applikation AP2 (Mobilfunkendgerät) über die CAT/SAT/USAT Schnittstelle I1 an eine Applikation AP2 (Mobilfunk-Chipkarte) übergeben werden.

In 1106 reicht die Applikation AP2 844 mit einer ersten Nachricht vom Typ AMP_Info (durchgezogener Pfeil) die vom AMP Manager 814 erhaltenen Daten über die CAT/SAT/USAT Schnittstelle I1 846 an die intelligente Mobilfunk-Chipkarte 850 weiter (Tabelle 12). Die Applikation AP1 848 kann danach optional eine zweite Nachricht vom Typ Empfangsbestätigung_6 über die CAT/SAT/USAT Schnittstelle I1 846 an das Mobilfunkgerät 854 zurückschicken (gestrichelter Pfeil), um entweder den fehlerfreien Empfang der AMP_Info Nachricht zu quittieren bzw. um eine fehlerhafte Übertragung zu melden (inkl. Fehlercode). Tabelle 13 zeigt einen möglichen Aufbau der zweiten Nachricht des Typs Empfangsbestätigung_6.

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als Empfangsbestätigung_6
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
Empfangs-Instanz-ID	Obligatorisch	Identifiziert die Applikation im Mobilfunkendgerät
Statusmeldung	Optional	Gibt an, ob die von Applikation AP2 gesendete Nachricht die Applikation AP1 fehlerfrei erreicht hat. Enthält gegebenenfalls einen Fehlercode.

Tabelle 13: Mögliche Informationselemente in der Empfangsbestätigung_6, mit der die Applikation AP2 der Applikation AP1 antworten kann (optional).

Die Informationselemente „Eigenschaften interner AMPs” und „Eigenschaften externer AMPs” können gemäß verschiedenen Ausführungsbeispielen der Erfindung den folgenden Aufbau haben:
Local-AMP-Manager-ID = '00000110'
Local-AMP-Nummer = '00000001'
AMP-Properties-Container
wobei der „AMP-Properties-Container” wiederum mindestens einen der in Tabelle 14 beschriebenen Datenblöcke umfassen soll.

Name	Typ	Wertebereich	Beschreibung
AMP_Status	Token	„EIN” oder „AUS”	„EIN” zeigt an, dass das entsprechende Sende-/Empfangsmodul eingeschaltet bzw. funktionsbereit ist. „AUS” zeigt an, dass das entsprechende Sende-/Empfangsmodul ausgeschaltet ist, oder sich im Energiesparmodus befindet.
AMP_Type	Token	2.4 GHz, WiMedia, 802.11, usw.	Spezifiziert den Typ des entsprechenden Sende-/Empfangsmoduls.
Free_BW	Integer	4 Octets: 0x00000000–0xFFFFFFFE (wobei 0xFFFFFFFF für „unbekannt” steht)	Schätzung der maximal verfügbaren Bandbreite für das entsprechende Sende-/Empfangsmodul. Angabe erfolgt beispielsweise in kbps. Dieses Feld braucht nur interpretiert werden, wenn AMP_Status auf „EIN” gesetzt ist.
Min_Data_Size	Integer	4 Octets: 0x00000000–0xFFFFFFFF (wobei 0x00000000 für „egal” steht)	Zur Erhöhung der Energieeffizienz kann ein Schwellwert für die Datenrate angegeben werden. Das entsprechende Sende-/Empfangsmodul wird erst bei Überschreitung dieses Schwellwertes aktiviert.
AMP_Block	Octet String	Variable	Datenblock, der weitere charakteristische Kenngrößen des entsprechenden Sende-/Empfangsmoduls beispielsweise zur Angabe alternativ unterstützter Datenraten, Frequenzbereiche oder Energieschemata umfassen kann.

Tabelle 14: Möglicher Aufbau eines „AMP-Properties-Containers”

Zum Zeitpunkt 1108 hat Applikation AP1 848 und damit auch andere, beispielsweise vom Netzbetreiber kontrollierte Applikationen auf der intelligenten Mobilfunk-Chipkarte 850 Kenntnis sowohl über die Eigenschaften der lokalen Sende-/Empfangsmodule 816, 818, als auch über die Eigenschaften der Sende-/Empfangsmodule auf benachbarten Geräten. Konkret bedeutet dies, dass Applikation AP1 848 sowie andere auf der intelligenten Mobilfunk-Chipkarte residierende Applikationen den AMP Manager 814 im Bluetooth Host Subsystem 810 des Mobilfunkendgerätes 854 optimal informiert ansprechen und steuern können, wenn sie den Dienst eines bestimmten Sende-/Empfangsmoduls in Anspruch nehmen wollen. Insbesondere ist es mittels des Verfahrens gemäß einem Ausführungsbeispiel der Erfindung möglich, standortbezogen (Land, Region, Funkzelle, auf Basis von GPS-Koordinaten, usw.) den Betrieb sämtlicher Sende-/Empfangsmodule für die nächste Generation von Bluetooth Wireless Technology zu steuern, da der Standort des Mobilfunkendgerätes 854 auf einer intelligenten Mobilfunk-Chipkarte 850 auf unterschiedliche Weise mit unterschiedlichen Genauigkeiten ermittelt werden kann.
D) Nachrichtenflussdiagramm 1200 Verwaltung einer physikalischen Verbindung (physical AMP link)
12 zeigt den Austausch von Nachrichten zwischen den drei Hauptfunktionsblöcken (Applikation AP1 848, Applikation AP2 844 und AMP Manager 814) im Gesamtsystem 840, 860, daraufhin abzielend, eine physikalische Verbindung über ein verfügbares Sende-/Empfangsmodul-Paar (AMP-Paar) einzuleiten bzw. abzubauen. Dabei wird vorausgesetzt, dass die Details über das entsprechende Sende-/Empfangsmodul-Paar bereits nach den obigen Ausführungen ermittelt worden sind. Idealerweise geschehen der Auf- und Abbau der Verbindung über das herkömmliche Bluetooth Controller Paar, welches bei 2,4 GHz operiert (lokales individuelles Identifikationsmerkmal: Byte mit dem Wert „0”).
In 1202 sendet die Applikation AP1 848, die sich beispielsweise auf einer intelligenten Mobilfunk-Chipkarte 850 befindet, eine Nachricht vom Typ Manage_AMP_Link, welche erfindungsgemäß mindestens eine der in Tabelle 15 gezeigten Informationen enthalten könnte, an das Mobilfunkgerät 854. Tabelle 16 zeigt den möglichen Aufbau einer passenden Empfangsbestätigung_7.

In 1204 reicht die Applikation AP2 844 die Informationen des Manage_AMP_Link Befehls, welche sie über die CAT/SAT/USAT Schnittstelle I1 846 erhalten hat, ganz oder teilweise an den AMP Manager 814 weiter. Zuvor werden die Informationen gegebenenfalls für eine Übertragung über die I2 Schnittstelle 842 entsprechend aufbereitet. Die Informationen werden dem AMP Manager 814 über einen dedizierten SAP zugeführt (vergleiche Informationselement „SAPI” in Tabelle 15). Auf Basis der im Manage_AMP_Link Befehl enthaltenen Steuerkommandos (ausgedrückt durch das Informationselement „Link Command”) sorgt der lokale AMP Manager 814 für den Aufbau bzw. Abbau einer physikalischen Verbindung. Anschließend kann er über den dedizierten SAP eine Rückmeldung an die Applikation AP2 844 zurückschicken, wo gegebenenfalls eine CAT/SAT/USAT gemäße Aufbereitung dieser Daten für die weitere Übertragung über die Schnittstelle I1 846 erfolgt.

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als Manage_AMP_Link.
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
SAPI	Optional	Identifiziert den Service Access Point (SAP) in den Bluetooth Core Layer.
Local Bluetooth Device Address	Optional	Ermöglicht die Angabe der BD-ADDR gemäß Bluetooth-Spezifikation für das lokale Endgerät.
Local AMP-Manager-ID	Obligatorisch	Identifiziert den lokalen AMP Manager.
Local AMP Nummer	Obligatorisch	Identifiziert das lokale Sende-/Empfangsmodul
Remote Bluetooth Device Address	Optional	Ermöglicht die Angabe der BD-ADDR gemäß Bluetooth-Spezifikation für das benachbarte Endgerät.
Remote AMP-Manager-ID	Optional	Identifiziert den AMP Manager im benachbarten Gerät.
Remote AMP Nummer	Optional	Identifiziert das Sende-/Empfangsmodul im benachbarten Gerät.
Sende-Instanz-ID	Obligatorisch	Identifiziert die anfragende Applikation auf der Chipkarte.
Link Command	Obligatorisch	Gibt an, ob eine physikalische Verbindung auf- oder abgebaut werden soll. Mögliche Werte: 'Create_Link' oder 'Disconnect_Link'
Physical Link ID	Optional	Ermöglicht die Angabe eines Identifikationsmerkmals einer physikalischen Verbindung (beispielsweise derjenigen Verbindung, die abgebaut werden soll).
Rückmeldung	Optional	Ermöglicht die Anfrage einer Statusmeldung durch die anfragende Applikation AP2 im Mobilfunkgerät.

Tabelle 15: Mögliche Informationselemente in der Nachricht Manage_AMP_Link, welche von einer Applikation AP1 (Mobilfunk-Chipkarte) über die CAT/SAT/USAT Schnittstelle I1 an eine Applikation AP2 (Mobilfunkendgerät) übergeben werden.

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als Empfangsbestätigung_7
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
Empfangs-Instanz-ID	Obligatorisch	Identifiziert die anfragende Applikation im Mobilfunkgerät.
Physical Link ID	Optional	Ermöglicht die Angabe eines Identifikationsmerkmals einer physikalischen Verbindung (beispielsweise für eine gerade aufgebaute physikalische Verbindung).
Statusmeldung	Optional	Gibt an, ob die Anfrage wie gewünscht vom AMP Manager ausgeführt werden konnte. Enthält gegebenenfalls einen Fehlercode.

Tabelle 16: Mögliche Informationselemente in der Empfangsbestätigung_7, mit der der AMP Manager der Applikation AP2 antworten kann (optional).

In 1206 reicht die Applikation AP2 844 mit einer ersten Nachricht vom Typ Manage_AMP_Link_Feedback (durchgezogener Pfeil) die vom AMP Manager 814 erhaltene Rückmeldung über die CAT/SAT/USAT Schnittstelle I1 846 an die intelligente Mobilfunk-Chipkarte 850 weiter (Tabelle 17). Die Applikation AP1 848 kann danach optional eine zweite Nachricht vom Typ Empfangsbestätigung_8 über die CAT/SAT/USAT Schnittstelle I1 846 an das Mobilfunkgerät zurückschicken (gestrichelter Pfeil), um den fehlerfreien Empfang der Manage_AMP_Link_Feedback Nachricht zu quittieren oder um eine fehlerhafte Übertragung zu melden (inkl. Fehlercode). Tabelle 18 zeigt einen möglichen Aufbau der zweiten Nachricht des Typs Empfangsbestätigung_8.

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als Manage_AMP_Link_Feedback.
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
SAPI	Obligatorisch	Identifiziert den Service Access Point (SAP) des Bluetooth Core Layers, von dem diese Informationen stammen.
Local Bluetooth Device Address	Optional	Ermöglicht die Angabe der BD-ADDR gemäß Bluetooth-Spezifikation für das lokale Endgerät.
Local AMP-Manager-ID	Obligatorisch	Identifiziert den lokalen AMP Manager.
Local AMP Nummer	Obligatorisch	Identifiziert das lokale Sende-/Empfangsmodul
Remote Bluetooth Device Address	Optional	Ermöglicht die Angabe der BD-ADDR gemäß Bluetooth-Spezifikation für das benachbarte Endgerät.
Remote AMP-Manager-ID	Optional	Identifiziert den AMP Manager im benachbarten Gerät.
Remote AMP Nummer	Optional	Identifiziert das Sende-/Empfangsmodul im benachbarten Gerät.
Sende-Instanz-ID	Obligatorisch	Identifiziert die sendende Applikation im Mobilfunkendgerät.
Zeitstempel	Optional	Zeitinformation: Gibt an, wann eine physikalische Verbindung auf- oder abgebaut wurde.
Physical Link ID	Optional	Ermöglicht die Angabe eines Identifikationsmerkmals einer physikalischen Verbindung (beispielsweise für eine gerade aufgebaute oder abgebaute physikalische Verbindung).
Rückmeldung	Optional	Statusmeldung. Enthält gegebenenfalls einen Fehlercode.

Tabelle 17: Mögliche Informationselemente in der Nachricht Manage_AMP_Link_Feedback, welche von einer Applikation AP2 844 (Mobilfunkendgerät) über die CAT/SAT/USAT-Schnittstelle I1 an eine Applikation AP1 (Mobilfunk-Chipkarte) übergeben werden.

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als Empfangsbestätigung_8
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
Empfangs-Instanz-ID	Obligatorisch	Identifiziert die Applikation im Mobilfunkendgerät
Statusmeldung	Optional	Gibt an, ob die von Applikation AP2 gesendete Nachricht die Applikation AP1 fehlerfrei erreicht hat. Enthält gegebenenfalls einen Fehlercode.

Tabelle 18: Mögliche Informationselemente in der Empfangsbestätigung_8, mit der die Applikation AP1 der Applikation AP2 antworten kann (optional).

E) Nachrichtenflussdiagramm 1300: Verwaltung eines logischen Kanals (logical AMP channel)
13 zeigt den Austausch von Nachrichten zwischen den drei Hauptfunktionsblöcken (Applikation AP1 848, Applikation AP2 844 und AMP Manager 814) im Gesamtsystem 840, 860, daraufhin abzielend, einen logischen Kanal zu verwalten. Unter dem Begriff „Verwaltung” ist in diesem Zusammenhang Aufbau, Abbau und Verlegung eines logischen Kanals zu verstehen.
In 1302 sendet die Applikation AP1 848, die sich beispielsweise auf einer intelligenten Mobilfunk-Chipkarte 850 befindet, eine Nachricht vom Typ Manage_AMP_Channel, welche gemäß verschiedenen Ausführungsbeispielen der Erfindung mindestens eine der in Tabelle 19 gezeigten Informationen enthalten soll, an das Mobilfunkgerät 854. Für die Funktionalität „Verwaltung eines logischen Kanals” hervorzuheben sind in diesem Zusammenhang die Informationselemente „Channel Command”, „Physical Link ID”, „Logical Channel ID” und „Target Physical Link ID”.
Aufbau eines Kanals: Mit Hilfe der beiden Informationselemente „Channel Command” und „Physical Link ID” kann beispielsweise ein neuer logischer Kanal (über eine existierende physikalische Verbindung) aufgebaut werden (Channel Command = „Create_Channel”). Das Identifikationsmerkmal kann im Informationselement „Logical Channel ID” zurückgegeben werden.
Abbau eines Kanals: Mit Hilfe der Informationselemente „Channel Command” und „Logical Channel ID” (und optional „Physical Link ID”) kann beispielsweise ein existierender logischer Kanal (über eine bekannte physikalische Verbindung) abgebaut werden (Channel Command = 'Disconnect_Channel').
Verlegung eines Kanals: Ferner kann unter Zuhilfenahme der Informationselemente „Channel Command”, „Physical Link ID”, „Logical Channel ID” und „Target Physical Link ID” ein existierender logischer Kanal von einer ersten bestehenden physikalischen Verbindung auf eine zweite bestehenden physikalischen Verbindung umgelegt werden (Channel Command = „Move_Channel”).

Tabelle 20 zeigt den möglichen Aufbau einer passenden Empfangsbestätigung_9.

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als Manage_AMP_Channel.
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
SAPI	Optional	Identifiziert den Service Access Point (SAP) in den Bluetooth Core Layer.
Local Bluetooth Device Address	Optional	Ermöglicht die Angabe der BD-ADDR gemäß Bluetooth-Spezifikation für das lokale Endgerät.
Local AMP-Manager-ID	Obligatorisch	Identifiziert den lokalen AMP Manager.
Local AMP Nummer	Optional	Identifiziert das lokale Sende-/Empfangsmodul.
Remote Bluetooth Device Address	Optional	Ermöglicht die Angabe der BD-ADDR gemäß Bluetooth-Spezifikation für das benachbarte Endgerät.
Remote AMP-Manager-ID	Obligatorisch	Identifiziert den AMP Manager im benachbarten Gerät.
Remote AMP Nummer	Optional	Identifiziert das Sende-/Empfangsmodul im benachbarten Gerät.
Sende-Instanz-ID	Obligatorisch	Identifiziert die anfragende Applikation auf der Chipkarte.
Physical Link ID	Optional	Identifikationsmerkmals einer physikalischen Verbindung.
Channel Command	Obligatorisch	Gibt an, ob ein logischer Kanal aufgebaut oder abgebaut oder verlegt werden soll. Mögliche Werte sind: ”Create_Channel” oder ”Disconnect_Channel” oder ”Move_Channel”.
Target Physical Link ID	Optional	Identifikationsmerkmals einer physikalischen Verbindung für das Kommando „Move_Channel”.
Logical Channel ID	Optional	Ermöglicht die Angabe desjenigen logischen Kanals, welcher beispielsweise abgebaut oder verlegt werden soll.
Rückmeldung	Optional	Ermöglicht die Anfrage einer Statusmeldung durch die anfragende Applikation AP1 auf der Chipkarte.

Tabelle 19: Mögliche Informationselemente in der Nachricht Manage_AMP_Channel, welche von einer Applikation AP1 (Mobilfunk-Chipkarte) über die CAT/SAT/USAT – Schnittstelle I1 an eine Applikation AP2 (Mobilfunkendgerät) übergeben werden.

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als Empfangsbestätigung_9
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
Empfangs-Instanz-ID	Obligatorisch	Identifiziert die anfragende Applikation auf der Chipkarte.
Logical Channel ID	Optional	Ermöglicht die Angabe eines Identifikationsmerkmals eines logischen Kanals (beispielsweise für einen gerade aufgebauten logischen Kanal).
Statusmeldung	Optional	Gibt an, ob die Anfrage wie gewünscht von Applikation AP2 ausgeführt werden konnte. Enthält gegebenenfalls einen Fehlercode.

Tabelle 20: Mögliche Informationselemente in der Empfangsbestätigung_9, mit der die Applikation AP2 der Applikation AP1 antworten kann (optional).

In 1304 reicht die Applikation AP2 844 die Informationen des Manage_AMP_Channel Befehls, welche sie über die CAT/SAT/USAT Schnittstelle I1 846 erhalten hat, ganz oder teilweise an den AMP Manager 814 weiter. Zuvor werden die Informationen gegebenenfalls für eine Übertragung über die I2 Schnittstelle 842 entsprechend aufbereitet. Die Informationen werden dem AMP Manager 814 über einen dedizierten SAP zugeführt (vergleiche Informationselement „SAPI” in Tabelle 19). Auf Basis der in der Nachricht Manage_AMP_Channel enthaltenen Steuerbefehle (ausgedrückt in erster Linie durch das Informationselement „Channel Command”) sorgt der lokale AMP Manager 814 für den Aufbau, den Abbau, oder die Verlegung eines logischen Kanals. Anschließend kann er über den dedizierten SAP 830 eine Rückmeldung an die Applikation AP2 844 zurückschicken, wo gegebenenfalls eine CAT/SAT/USAT-gemäße Aufbereitung dieser Daten für die weitere Übertragung über die Schnittstelle I1 846 erfolgt.

In 1306 reicht die Applikation AP2 844 mit einer ersten Nachricht vom Typ Manage_AMP_Channel_Feedback (durchgezogener Pfeil) die vom AMP Manager 814 erhaltene Rückmeldung über die CAT/SAT/USAT Schnittstelle I1 846 an die intelligente Mobilfunk-Chipkarte 850 weiter (Tabelle 21). Die Applikation AP1 848 kann danach optional eine zweite Nachricht vom Typ Empfangsbestätigung_10 über die CAT/SAT/USAT Schnittstelle I1 846 an das Mobilfunkgerät 854 zurückschicken (gestrichelter Pfeil), um den fehlerfreien Empfang der Manage_AMP_Channel_Feedback Nachricht zu quittieren bzw. um eine fehlerhafte Übertragung zu melden (inkl. Fehlercode). Tabelle 22 zeigt einen möglichen Aufbau der zweiten Nachricht des Typs Empfangsbestätigung_10.

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als Manage_AMP_Channel_Feedback.
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
SAPI	Obligatorisch	Identifiziert den Service Access Point (SAP) des Bluetooth Core Layers, von dem diese Informationen stammen.
Local Bluetooth Device Address	Optional	Ermöglicht die Angabe der BD-ADDR gemäß Bluetooth-Spezifikation für das lokale Endgerät.
Local AMP-Manager-ID	Optional	Identifiziert den lokalen AMP Manager.
Local AMP Nummer	Optional	Identifiziert das lokale Sende-/Empfangsmodul.
Remote Bluetooth Device Address	Optional	Ermöglicht die Angabe der BD-ADDR gemäß Bluetooth-Spezifikation für das benachbarte Endgerät.
Remote AMP-Manager-ID	Optional	Identifiziert den AMP Manager im benachbarten Gerät.
Remote AMP Nummer	Optional	Identifiziert das Sende-/Empfangsmodul im benachbarten Gerät.
Sende-Instanz-ID	Obligatorisch	Identifiziert die sendende Applikation im Mobilfunkendgerät.
Zeitstempel	Optional	Zeitinformation: Gibt an, wann ein logischer Kanal aufgebaut oder abgebaut bzw. verlegt wurde.
Logical Channel ID	Optional	Ermöglicht die Angabe eines Identifikationsmerkmals eines logischen Kanals (beispielsweise für einen neu aufgebauten, abgebauten oder verlegten logischen Kanal).
Rückmeldung	Optional	Statusmeldung.

Tabelle 21: Mögliche Informationselemente in der Nachricht Manage_AMP_Channel_Feedback, welche von einer Applikation AP2 (Mobilfunkendgerät) über die CAT/SAT/USAT – Schnittstelle I1 an eine Applikation AP1 (Mobilfunk-Chipkarte) übergeben werden.

Informationselement	Anwesenheit	Beschreibung
Nachrichtentyp	Obligatorisch	Kennzeichnet diese Nachricht als Empfangsbestätigung_10
Transaktionsmerkmal	Obligatorisch	Applikationseigene Kennung dieser Transaktion.
Versionskennziffer	Optional	Ermöglicht die Angabe einer Protokoll-Versionsnummer.
Empfangs-Instanz-ID	Obligatorisch	Identifiziert die Applikation im Mobilfunkendgerät
Statusmeldung	Optional	Gibt an, ob die von Applikation AP2 gesendete Nachricht die Applikation AP1 fehlerfrei erreicht hat. Enthält gegebenenfalls einen Fehlercode.

Tabelle 22: Mögliche Informationselemente in der Empfangsbestätigung_10, mit der die Applikation APa der Applikation AP2 antworten kann (optional).

Einleitend wurde bereits kurz der USIM Initialisierungsprozess gemäß der UMTS-Spezifikation beschrieben. Dieser Initialisierungsprozess ermöglicht unter anderem, dass die allgemein vom USIM unterstützten Dienste (USIM Service Table Request) bzw. die aktuell vom USIM freigegebenen Dienste (USIM Enabled Services Table Request) durch das Mobilfunkendgerät abgefragt werden können.
Damit das beschriebene Verfahren – insbesondere die Variante gemäß 8B (Gesamtsystem ME 840), wo die vertrauenswürdige Applikation AP1 848 zum gezielten Beeinflussen der Bluetooth Funktionalität auf einer intelligenten Mobilfunk-Chipkarte 850 gespeichert ist – zuverlässig funktioniert, werden gemäß einem Ausführungsbeispiel der Erfindung auch in den USIM Service Tabellen einige Ergänzungen vorgenommen, welche im Folgenden im Detail anhand von 14 beschrieben sind. Die Dienste #06 bis #69 sind aus Gründen einer besseren Übersichtlichkeit nicht dargestellt. Außerdem wird hier nur auf die Liste der allgemein vom USIM unterstützten Dienste (USIM Service Table Request) eingegangen. Gemäß verschiedenen Ausführungsbeispielen der Erfindung neu sind die Dienste #75 „Basic Bluetooth AMP Control” und #76 „Advanced Bluetooth AMP Control” 1402. Ein Übertragen dieser beiden Einträge auf die Liste der aktuell vom USIM freigegebenen Dienste (USIM Enabled Services Table Request) ist selbsterklärend.
Eine Unterscheidung zwischen „Basic Bluetooth AMP Control” (Dienst #75) und „Advanced Bluetooth AMP Control” (Dienst #76) macht insofern Sinn, als dass unter „Advanced Bluetooth AMP Control” das Einbeziehen einer im Zugriffsbereich der intelligenten Mobilfunk-Chipkarte (und somit ebenfalls vertrauenswürdigen) liegenden Funktionseinheit (beispielsweise ein GPS-Modul) zum Bestimmen des Aufenthalts des Mobilfunkendgerätes (Land, Region, Stadt, Funkzelle, usw.) verstanden werden kann, während ein USIM, welches lediglich „Basic Bluetooth AMP Control” anbietet, diese Funktionalität nicht anbieten kann.
Obwohl die Erfindung vor allem im Zusammenhang mit spezifischen Ausführungsbeispielen gezeigt und beschrieben worden ist, sollte es von denjenigen mit dem Fachgebiet vertrauten Personen verstanden werden, dass vielfältige Änderungen der Ausgestaltung und der Details daran vorgenommen werden können, ohne vom Wesen und Bereich der Erfindung, wie er durch die nachfolgenden Ansprüche definiert wird, abzuweichen. Der Bereich der Erfindung wird daher durch die angefügten Ansprüche bestimmt, und es ist beabsichtigt, dass sämtliche Veränderungen, welche in Reichweite der Bedeutung und des Äquivalenzbereichs der Ansprüche liegen, von den Ansprüchen umfasst werden.

Claims

Ad-hoc-Kommunikations-Funkmodul, aufweisend: mehrere Ad-hoc-Kommunikations-Empfangsschaltkreise (206, 506) und/oder mehrere Ad-hoc-Kommunikations-Sendeschaltkreise (204, 504), die verschiedene Frequenzbandgruppen verwenden; und eine Ad-hoc-Kommunikationsprotokollstapel-externe Steuer-Schnittstelle (212) zum Ad-hoc-Kommunikationsprotokollstapel-externen Auswählen und Steuern der Medium Access Control (MAC) Schicht oder Physical Layer (PHY)Schicht eines der mehreren Ad-hoc-Kommunikations-Empfangsschaltkreise (206, 506) und/oder Ad-hoc-Kommunikations-Sendeschaltkreise (204, 504) von mehreren Ad-hoc-Kommunikationsprotokollstapel-externen Anwendungen (540, 542, 544) gleichzeitig und unabhängig voneinander.
Ad-hoc-Kommunikations-Funkmodul gemäß Anspruch 1, wobei die Ad-hoc-Kommunikationsprotokollstapel-externe Steuer-Schnittstelle (212) mehrere Ad-hoc-Kommunikationsprotokollstapel-externe Dienstzugangspunkte (508, 510, 512) aufweist.
Ad-hoc-Kommunikations-Funkmodul gemäß einem der Ansprüche 1 bis 2, eingerichtet gemäß Bluetooth oder ZigBee.
Ad-hoc-Kommunikations-Funkmodul gemäß einem der Ansprüche 1 bis 3, ferner aufweisend: mindestens einen zusätzlichen Empfangsschaltkreis (524) zu den mehreren Ad-hoc-Kommunikations-Empfangsschaltkreisen (206, 506); und/oder mindestens einen zusätzlichen Sendeschaltkreis (522) zu den mehreren Ad-hoc-Kommunikations-Sendeschaltkreisen (204, 504); und eine Steuerungseinheit (502) zum Steuernder Ad-hoc-Kommunikations-Empfangsschaltkreise und/oder der Ad-hoc-Kommunikations-Sendeschaltkreise sowie des zusätzlichen Empfangsschaltkreises (524) und/oder des zusätzlichen Sendeschaltkreises (522); wobei die Steuerungseinheit (502) die Ad-hoc-Kommunikationsprotokollstapel-externe Steuer-Schnittstelle (212) aufweist.
Ad-hoc-Kommunikations-Funkmodul gemäß Anspruch 4, wobei der mindestens eine zusätzliche Empfangsschaltkreis (524) und/oder der mindestens eine zusätzliche Sendeschaltkreis (522) eingerichtet sind/ist gemäß einer anderen Funktechnologie als der Ad-hoc-Kommunikations-Empfangsschaltkreise (206, 506) und/oder der Ad-hoc-Kommunikations-Sendeschaltkreise (204, 504).
Ad-hoc-Kommunikations-Funkmodul gemäß Anspruch 5, wobei der mindestens eine zusätzliche Empfangsschaltkreis (524) und/oder der mindestens eine zusätzliche Sendeschaltkreis (522) eingerichtet sind/ist gemäß einer der folgenden Funktechnologien: Ultra-Breitband-Funktechnologie; Drahtlos-Lokales-Netzwerk-Funktechnologie.
Ad-hoc-Kommunikationseinrichtung, aufweisend: ein Ad-hoc-Kommunikations-Funkmodul (220), das aufweist: mehrere Ad-hoc-Kommunikations-Empfangsschaltkreise (206, 506), und/oder mehrere Ad-hoc-Kommunikations-Sendeschaltkreise (204, 504), die verschiedene Frequenzbandgruppen verwenden; und eine Ad-hoc-Kommunikationsprotokollstapel-externe Steuer-Schnittstelle (212) zum Ad-hoc-Kommunikationsprotokollstapel-externen Auswählen und Steuern der Medium Access Control (MAC) Schicht oder der Physical Layer (PHY) Schicht eines der mehreren Ad-hoc-Kommunikations-Empfangsschaltkreise (206, 506) und/oder Ad-hoc-Kommunikations-Sendeschaltkreise (204, 504) von mehreren Ad-hoc-Kommunikationsprotokollstapel-externen Anwendungen (540, 542, 544) gleichzeitig und unabhängig voneinander; einen Speicher (552) zum Speichern eines Steuerprogramms zum Ad-hoc-Kommunikationsprotokollstapel-externen Steuern des Ad-hoc-Kommunikations-Empfangsschaltkreises (206, 506) und/oder des Ad-hoc-Kommunikations-Sendeschaltkreis (204, 504) des Ad-hoc-Kommunikations-Funkmoduls (220).
Ad-hoc-Kommunikationseinrichtung gemäß Anspruch 7, wobei das Steuerprogramm ein für das Ad-hoc-Kommunikations-Funkmodul (220) vertrauenswürdiges Steuerprogramm ist.
Ad-hoc-Kommunikationseinrichtung gemäß Anspruch 7 oder 8, ferner aufweisend: einen Mobilfunk-Kommunikations-Empfangsschaltkreis (524); und/oder einen Mobilfunk-Kommunikations-Sendeschaltkreis (522).
Ad-hoc-Kommunikationseinrichtung gemäß Anspruch 9, wobei der Mobilfunk-Kommunikations-Empfangsschaltkreis (524) und/oder der Mobilfunk-Kommunikations-Sendeschaltkreis (522) eingerichtet ist gemäß einer Mobilfunk-Technologie der zweiten Generation, oder gemäß einer Mobilfunk-Technologie der dritten Generation.
Ad-hoc-Kommunikationseinrichtung gemäß Anspruch 9 oder 10, wobei der Mobilfunk-Kommunikations-Empfangsschaltkreis (524) und/oder der Mobilfunk-Kommunikations-Sendeschaltkreis (522) eingerichtet ist gemäß einer der folgenden Mobilfunk-Technologien: Global System for Mobile Communications Mobilfunk-Technologie; Universal Mobile Telecommunication System Mobilfunk-Technologie; Code Division Multiple Access Mobilfunk-Technologie; Code Division Multiple Access 2000 Mobilfunk-Technologie; Freedom of Mobile Multimedia Access Mobilfunk-Technologie;
Ad-hoc-Kommunikationseinrichtung gemäß einem der Ansprüche 7 bis 11, ferner aufweisend: einen Schnurlos-Kommunikations-Empfangsschaltkreis; und/oder einen Schnurlos-Kommunikations-Sendeschaltkreis.
Ad-hoc-Kommunikationseinrichtung gemäß Anspruch 12, wobei der Schnurlos-Kommunikations-Empfangsschaltkreis und/oder der Schnurlos-Kommunikations-Sendeschaltkreis eingerichtet ist gemäß einer der folgenden Mobilfunk-Technologien: Digital Enhanced Cordless Telecommunication Schnurlos-Technologie; Wideband Digital Enhanced Cordless Telecommunication Schnurlos-Technologie; Cordless Telephony 2 Schnurlos-Technologie; Cordless Advanced Technology – internet and quality Schnurlos-Technologie.
Ad-hoc-Kommunikationseinrichtung gemäß einem der Ansprüche 7 bis 13, ferner aufweisend: eine Benutzer-Identifikationselement-Schnittstelle (556) zur Kommunikation mit einem Benutzer-Identifikationselement (536) eines Benutzers der Ad-hoc-Kommunikationseinrichtung.
Ad-hoc-Kommunikationseinrichtung gemäß einem der Ansprüche 7 bis 14, ferner aufweisend: ein mit der Benutzer-Identifikationselement-Schnittstelle (556) zur Kommunikation gekoppeltes Benutzer-Identifikationselement (536).
Ad-hoc-Kommunikationseinrichtung gemäß Anspruch 15, wobei das Steuerprogramm zum Ad-hoc-Kommunikationsprotokollstapel-externen Steuern über die Ad-hoc-Kommunikationsprotokollstapel-externe Steuer-Schnittstelle (212) in einem Speicher des Benutzer-Identifikationselements (536) gespeichert ist.
Ad-hoc-Kommunikationseinrichtung gemäß Anspruch 15 oder 16, wobei das Benutzer-Identifikationselement (536) ein Teilnehmer-Identifikations-Modul ist.
Verfahren zum Steuern eines Ad-hoc-Kommunikations-Funkmoduls, wobei das Verfahren aufweist: Zuführen von Steuerinformation einem von mehreren Ad-hoc-Kommunikations-Empfangsschaltkreisen (206, 506) und/oder mehreren Ad-hoc-Kommunikations-Sendeschaltkreisen (204, 504), die verschiedene Frequenzbandgruppen verwenden, mittels einer Ad-hoc-Kommunikationsprotokollstapel-externen Steuer-Schnittstelle (212) zum Ad-hoc-Kommunikationsprotokollstapel-externen Auswählen und Steuern der Medium Access Control (MAC) Schicht oder der Physical Layer (PHY) Schicht des einen Ad-hoc-Kommunikations-Empfangsschaltkreises (206, 506) und/oder Ad-hoc-Kommunikations-Sendeschaltkreises (204, 504) von mehreren Ad-hoc-Kommunikationsprotokollstapel-externen Anwendungen (540, 542, 544) gleichzeitig und unabhängig voneinander.
Verfahren gemäß Anspruch 18, wobei die Ad-hoc-Kommunikationsprotokollstapel-externe Steuer-Schnittstelle (212) mehrere Ad-hoc-Kommunikationsprotokollstapel-externe Dienstzugangspunkte (508, 510, 512) aufweist.
Verfahren gemäß einem der Ansprüche 18 bis 19, wobei das Ad-hoc-Kommunikations-Funkmodul eingerichtet ist gemäß Bluetooth oder ZigBee.
Verfahren gemäß einem der Ansprüche 18 bis 20, wobei die Steuerinformation einer Steuerung (502) zugeführt wird, wobei die Steuerung folgende Einrichtungen steuert: die Ad-hoc-Kommunikations-Empfangsschaltkreise (206, 506); und/oder die Ad-hoc-Kommunikations-Sendeschaltkreise (206, 506); und/oder einen zusätzlichen Empfangsschaltkreis (524) zu den Ad-hoc-Kommunikations-Empfangsschaltkreisen (206, 506); und/oder einen zusätzlichen Sendeschaltkreis (522) zu den Ad-hoc-Kommunikations-Sendeschaltkreisen (204, 504).
Verfahren gemäß Anspruch 21, wobei der mindestens eine zusätzliche Empfangsschaltkreis (524) und/oder der mindestens eine zusätzliche Sendeschaltkreis (522) eingerichtet sind/ist gemäß einer anderen Funktechnologie als die Ad-hoc-Kommunikations-Empfangsschaltkreise (206, 506) und/oder die Ad-hoc-Kommunikations-Sendeschaltkreise (204, 504).
Verfahren gemäß Anspruch 22, wobei der mindestens eine zusätzliche Empfangsschaltkreis (524) und/oder der mindestens eine zusätzliche Sendeschaltkreis (522) eingerichtet sind/ist gemäß einer der folgenden Funktechnologien: Ultra-Breitband-Funktechnologie; Drahtlos-Lokales-Netzwerk-Funktechnologie.