Mobile Systeme und drahtlose Netzwerke

Slides:



Advertisements
Ähnliche Präsentationen
Powerpoint-Präsentation
Advertisements

Einer der Dienste im Internet
Routing – Routing Protokolle
Studienarbeit Entwurf und Implementierung eines UPnP-Browsers
Attribute Protocol.
Link Layer Security in BT LE.
Systemverwaltung wie es Ihnen gefällt.
Bluetooth H. Hassold.
Sebastian Peters TIB-Workshop zur DOI-Registrierung 3. November 2011 DataCite Technik Vertiefung.
© 2003 Patrick Brunner Spontane Vernetzung – Jini 9. Januar 2004 Spontane Vernetzung Patrick Brunner.
© 2003 Guido Badertscher Spontane Vernetzung - UPnP 9. Jänner 2004 Spontane Vernetzung Guido Badertscher.
HCI.
Attribute Profile.
Architektur.
Spontane Vernetzung mit Bluetooth / Kleines Seminar / SS 2002 / Sascha Seipp.
Lightweight Directory Access Protocol
Tiny TP Tiny TP gehört zwar zu den optionalen Komponenten wird aber dringend empfohlen. Tiny TP erfüllt folgende Aufgaben: 1.Zerlegung von großen Nachrichten.
Infrared Link Management Protocol IrLMP Das Link Management erfüllt folgende grundlegende Aufgaben 1.Aufgabe von Primary und Secondary können getauscht.
Client-Server-Architekturen
Oracle WebServer - Einführung. © Prof. T. Kudraß, HTWK Leipzig Oracle Web Application Server HTML WebServer ® File system Static HTML PL/SQL Packages.
IKS – Informations und Kommunikations-systeme
JAVA RMI.
GAP Generic Access Profile. Physical Layer Link Layer Host Controller Interface L2CAP Attribute Protocol Attribute Profile PUIDRemote ControlProximityBatteryThermostatHeart.
Security Manager Protocol. Physical Layer Link Layer Host Controller Interface L2CAP Attribute Protocol Attribute Profile PUIDRemote ControlProximityBatteryThermostatHeart.
Strukturänderungen Verteilte Anwendungen Wintersemester 06/07 © Wolfgang Schönfeld.
Access 2000 Datenbanken.
1. Einführung Lernziele: Auffrischen des Wissens aus Rechnernetze
RDF-Schema Seminar: „Semantic Web“ André Rosin,
Einführung in die Technik des Internets
1 Grundlagen und Anwendung der Extensible Markup Language (XML ) Peter Buxmann Institut für Wirtschaftsinformatik Johann Wolfgang Goethe-Universität Frankfurt.
UML Begleitdokumentation des Projekts
Workshop: Active Directory
IGEL UMS Universal Management Suite Oktober 2011 Florian Spatz
Die .NET Common Language Runtime
Referent: Kiron Mirdha Betreuer: Rene Hilden Juli 2012
WAP = Wireless Application Protocol Protokollstack Ein Protokoll ...
PSI - Überblick und Szenarien
Rechnerkommunikation und Vernetzung Teil 6 – Anwendungen auf mobilen Geräten Stephan Rupp Nachrichtentechnik
Integration heterogener verteilter Systeme mit WS-BPEL – ein Praxisbeispiel Dr. Wolf-Dieter Heinrichs.
Webservice Grundlagen
Aichinger Christian, Strasser Jürgen. Inhalt JSF EJB Praxis - Integration.
Typo3 Templates und TypoScript
Grundlagen: Client-Server-Modell
Julia Grabsch Florian Hillnhütter Fabian Riebschläger
Entwicklung verteilter Anwendungen II, SS 13 Prof. Dr. Herrad Schmidt SS 13 Kapitel 4 Folie 2 REST Web Services (1)
Netzwerke Ein Referat.
Die Architektur von Jini Präsentation von Thomas Heinis & Michea Wankerl Seminar Information & Kommunikation WS 2000/01.
OSI- MODELL 7 Schichten Gruppe : WRJ.
Warum gibt es Netzwerke?
Netzwerke.
The EventCollector Concept Präsentation der Diplomarbeit von Thomas Moser und Lukas Karrer Distributed System Group,
Client-Server-Modell
1 Karim El Jed TECHNISCHE UNIVERSITÄT ZU BRAUNSCHWEIG CAROLO-WILHELMINA Institut für Betriebssysteme und Rechnerverbund
VPN – Virtual Private Network
Willkommen zum Brückensemester
->Prinzip ->Systeme ->Peer – to – Peer
Universal Plug and Play
Ein Referat von Rahul Chanana, Sebastian Callian und Steffen Klikar.
TCP/IP.
Schutzvermerk nach DIN 34 beachten TCP / IP. Schutzvermerk nach DIN 34 beachten TCP / IP und das OSI-Referenzmodell Process / Application Host-to-Host.
Kirsten Kropmanns Allgemeine Technologien II 9. März 2009
© 2003 Marc Dörflinger Spontane Vernetzung - Salutation 9. Jänner 2004 Spontane Vernetzung Salutation Marc Dörflinger.
IS: Datenbanken, © Till Hänisch 2000 Windows Netzwerke TCP/IP oder was ?
Patrick Richterich Lattwein GmbH Web Services Softwareentwicklung mit SOAP.
© WZL/Fraunhofer IPT Eine Gegenüberstellung von Websockets und RESTful Web Services Seminarvortrag von Lucie Mades.
Webservices SOAP und REST Nicole Fronhofs 1. Betreuer: Prof. Dr. Volker Sander 2. Betreuer: B. Sc. Sebastian Olscher.
Technische Universität München, Informatik XI Angewandte Informatik / Kooperative Systeme Verteilte Anwendungen: Web Services Dr. Wolfgang Wörndl
Aufbau und Konfigurationen
Ich brauche eine Web-Seite vom Server im Internet
 Präsentation transkript:

Mobile Systeme und drahtlose Netzwerke Vorlesung VII

Gliederung

Ziele der Vorlesung Bluetooth-Details HCI, SDP und RFCOMM

SDP Gliederung SDP Protokoll Setup SDP Services Service Discovery Überblick PDU Format Partial Responses und Continuation Error Handling SDP Services Service Record Service Attribute Service Claas Service Discovery Searching for Services Browsing for Services Daten Repräsentation Daten Element Header Feld Daten Element Daten Feld Hintergrund Information Bluetooth Service Discovery

Das Service Discovery-Protokoll The service discovery mechanism provides the means for client applications to discover the existence of services provided by server applications as well as the attributes of those services. The attributes of a service include the type or class of service offered and the mechanism or protocol information needed to utilize the service. SDP ist ein Protokoll, das es Anwendungen gestattet, verfügbare Dienste (von Geräten) ausfindig zu machen und Auch die Eigenschaften dieser Dienste Die Attribute der Dienste enthalten den Typ oder die Klasse des Dienstes und den notwendigen Mechanismus oder die Protokollinformationen zur Nutzung des Dienstes

Das Service Discovery-Protokoll Insbesondere wichtig für Ad-hoc-Netzwerke: Geräte können zwar Verbindungen (auf Linkmanager-Ebene) zueinander aufbauen, erhalten jedoch keine Informationen darüber, welche Dienste verfügbar sind. Ist Drucker innerhalb der Richweite? Nicht aus Bluetooth-Adresse ableitbar Eine zentrale Verwaltung der Dienstleistungstabellen, würde den Gedanken des dynamischen Ad-hoc Netzwerkes widersprechen Gerät muss selbst Informationen über seine Dienste verwalten Aufgabe von SDP Die Menge der verfügbaren Dienste ändert sich dynamisch. Hängt ab von der RF-Nähe der Geräte zueinander, die in Bewegung sind Hierin unterscheidet sich das Service Discovery in Ad-Hoc Netzen vom SD in traditionellen netzwerkbasierten Umgebungen.

SDP im Bluetooth Protokoll Stack SDP liegt oberhalb von L2CAP PSM (Protocol Service Multiplexer) = 0x0001 in L2CAP PDU´s (PSM=0x003 für RFCOMM) SDP L2CAP HCI LMP PSM Länge CID 0x0002 Nutzdaten (Payload) MSB LSB 16

L2CAP Paketformat Wiederholung CL connection less CO connection-oriented

Gelbe Seiten SDP stellt in einer Service-Datenbank die Dienste bereit Dienste können auf Anfrage einem dienstwilligen Gerät zur Verfügung gestellt werden Dienste werde kategorisiert, hierarchisch gegliedert Es sind Informationen verfügbar, wie die Dienste erreichbar sind Ist folglich kein vermittelnder Dienst (wie D2VODAFONE-Auskunft) SDP benötigt Server und Client

SDP-Kommunikation SDP Server SDP Client Server Anwendung SDP request SDP response Client Anwendung Server Anwendung

SDP Protocol Setup SDP verwendet ein request/response (client/server) Modell PDU Protocol Data Unit Jede Transaktion besteht aus einem Request PDU vom Clienten und einem Response PDU von einem Server Ein SDP Client ist ein Bluetooth Gerät, das Dienste in seiner Umgebung sucht Ein SDP Server ist ein Gerät, das Dienste anbietet Informationen über Dienste sind in SDP Datenbank gespeichert Client Anwendung Server Anwendung SDP request SDP Client SDP Server SDP response

SDP Client und Server SDP-Client hat Schnittstelle zur Anwendung, die nach Services suchen will. Diese Anwendung stellt über den SDP-Client Anfragen an den SDP-Server des Remote-Gerätes. SDP-Server muss in der Lage sein, Service-Informationen von Anwendungen bereitzustellen und auf Anfrage, diese dem Client bereitstellen

Lokale Service-Description-Anwendung holt über den SDP-Client Dienstinformationen beim SDP-Server des Remote-Gerätes ab. Basisband ACL L2CAP layer CO SDP BT_module_Cntrl SrvDscApp LM RemSrvApp Service- Records DB Lokales Gerät Remote-Gerät

Dienstanfrage – Service Discovery DB: i.d.R. Textdatei Service Informationen in Service Records. SR sind hierarchisch organisiert. Bei Eintreffen einer Anfrage, kann Service-Baum, über mehrere Telegramme verteilt, übertragen werden. Anhand der Service Attribute kann das lokale Gerät entscheiden, welche Dienste es nutzen kann bzw. nutzen darf. Mit den Einträgen in den SR kann das lokale Gerät nun eine Verbindung zu einem Dienst aufbauen. SDP wird dann nicht mehr benötigt.

SDP PDU Format Jedes SDP-PDU besteht aus einem PDU-Header und nachfolgenden PDU-spezifischen Parametern

Partial Responses und Continuation State Einige SDP Requests können Responses erfordern, die größer sind als eine einzelne Response PDU sein. In einem solchen Fall wird der SDP Server eine partielle Response gemeinsam mit einem Fortsetzungszustandparameter (continuation state) generieren. Der Fortsetzungszustandparameter kann vom Client in einem nachfolgenden Request verwendet werden, um die nächste Portion der Gesamtnachricht zu erhalten.

Fehlerbehandlung Jede Transaktion besteht aus einem Request PDU einem Response PDU. Jeder Typ eines Request PDU besitz einen korrespondierenden Response PDU Wenn der Server feststellt, dass der Request PDU falsch ist, dann kann nicht der zugehörige Request PDU gesendet werden Server sendet dann einen Error-PDU (SDP_ErrorResponse)

SDP Services Jeder Eintrag, der Information bereitstellt, eine Aktion ausführt, oder eine Ressource steuert, im Auftrag eines anderen Eintrages Service kann in SW, HW oder SW/HW implementiert sein Service Records Service Attribute 1 Service Attribute 2 Service Attribute 3 … Service Attribute n Service Record

Service Records Definition von Service Records, um problemlosen Datenaustausch zu gewähren Diese repräsentieren die notwendigen Service-Informationen Dienstleistungen können frei definiert werden Nicht notwendig, diese an einer zentralen Stelle zu registrieren Service Attribute 1 Service Attribute 2 Service Attribute 3 … Service Attribute n Service Record

Service Records Service Record (SR) beschreibt genau einen Dienst, der zu einer Serviceklasse gehört Alle SR eines Servers in DB SR speichert seine Dienstinformationen in Dienstattributen Wichtigstes Dienstattribut ist SR-Handle, zur eindeutigen Adressierung des Dienstes in der DB Mit dem SR-Handle kann Client auf alle Attribute des SR zugreifen SR-Handle ist 32-Bit Wert Service Attribute 1 Service Attribute 2 Service Attribute 3 … Service Attribute n Service Record

Service Attribute Beschreiben die Eigenschaften eines Dienstes Jedes Serviceattribut beschreibt eine einzelne Eigenschaft eines Dienstes, wie z.B. ProviderName Attribut besteht aus Attribut –ID Eine Attribut-ID (16bits) unterscheidet jedes Serviceattribut von anderen Serviceattributen innerhalb eines Servicerecords Sie identifiziert ebenfalls die Semantik des zugehörigen Attributwertes Attribut –Werten (einzelner Wert oder Liste) Kann unterschiedliche Größe annnehmen Attribute ID Attribute Value Service Attribute 16 Bits Variable Länge

Service Attribute Jedes Service Attribut beschreibt eine einzelne Eigenschaft eines Services. Beispiele solcher Attribute sind:

Service Attribute - Kategorien Standard Service Attribute Beschreiben die Charakteristika von Serviceklassen, die einen Dienst in Form von Anwendungsprofilen bzw. Anwendungen unterstützen Service –Klassen –Attribute des Service –Discovery –Servers Beschreiben Eigenschaften des SDP-Servers (z.B. Versionsnummer, Statusinformationen) Service –Klassen –Attribute des Browsergruppen-Descriptors Ermöglichen hierarchische Strukturierung von Dienstgruppen

Allgemeine Service Attribute Einheitlich in allen Service Records 2 Attribute sind in jedem Service Record erforderlich ServiceRecordHandle Identifiziert jeden Service auf einem SDP-Server Nur bedeutsam für den jeweiligen SDP-Server ServiceClassIDList

Andere typische universelle Attribute ServiceID ProtocolDescriptorList Ein oder mehrere Protokollstacks, die verwendet werden , um den Service zu errreichen BrowserGroupList Browsergruppe, der der Service angehört BluetoothProfileDescriptorList Repräsentiert Profile mit denen der Service konform ist ServiceName

Service-Klassen Jedem Dienst, der von einem Gerät angeboten wird, wird eine Serviceklasse zugeordnet Es finden sich Dienstklassen, die in Bluetooth-Profilen definiert sind Jedes SR ist als Instanz einer Service-Klasse zu verstehen Jede Serviceklasse hat einmaligen Identifier UUID (universal unique identifier) Dieser UUID ist enthalten im Attributwert für das ServiceClassIDList Attribut UUID ist einmalig in Raum und Zeit Keine zentrale Registry notwendig UUID ist 128-Bit-Wert

Drucker-Beispiel Farbpostscript-Duplex-Drucker ist mit 4 ServiceClass-Definitionen konform, die mittels UUIDs repräsentiert werden DuplexColorPostscriptPrinterServiceID ColorPostscriptPrinterServiceID PostscriptPrinterServiceID PrinterServiceID

Beispiel-Bluetooth-Headset ServiceRecordHandle(Uint32) ID=0x0000 ServiceClassIDList ID=0x0001 ServiceClass0 (UUID=headset) ID=0x1108 ServiceClass1 (UUID=generic audio) ID=0x1203 ProtocolDescriptorList ID=0x0004 Protocol0 (UUID=L2CAP) ID=0x100 Protocol1 (UUID=RFCOMM) ID=0x003 ProtocolSpecificParameter0 (Unit8= server channel #) ServiceName (string=„Headset“)

Service Discovery Ermöglicht es einem BT-Gerät zu erfragen, welche Services andere BT-Geräte anbieten Suche (Searching): Nach einem speziellen Dienst suchen. Auflisten (Browsing): Nachsehen, welche Dienste gerade bereitgestellt werden Servicesuche: Ermöglicht es einem Client an den SR-Handle für bestimmte SR zu gelangen. Ein Dienstsuchmuster ist eine Liste von UUIDs (Serviceattributen), die verwendet wird um zugehörige Service Records zu lokalisieren Auflistung (Browsing): Basiert auf einem Attribute, das von allen Serviceklassen genutzt wird: BrowseGroupList – Attribut BrowseGroupList – Attribut enthält eine Liste von UUIDs. Jede Liste

Beispiel für die Verwendung von SDP Verbindung mittels L2CAP herstellen Nach Service fragen Nach einer spezifischen Serviceklasse fragen Services durchsuchen (browse) Aber SDP bietet keine Mechanismen, um gefundene Services auch nutzen zu können – dazu Protokolle höher in Hierachie notwendig

Daten Repräsentation

Datenelement Typendescriptor Type Descriptor und valid Size Descriptor

Data element size descriptor table

Beispiele für Daten Null Ein 16-bit Integer-Wert Der 3-Buchstaben umfassenden String „Hat“

Protocol description

PDU IDs Es sind nur 7 SDP PDU definiert 0x01: SDP_ErrorResponse 0x02: SDP_ServiceSearchRequest 0x03: SDP_ServiceSearchResponse 0x04: SDP_ServiceAttributRequest 0x05: SDP_ServiceAttributResponse 0x06: SDP_ServiceSearchAttributeRequest 0x07: SDP_ServiceSearchAttributeResponse

SDP_XXXXResponse oder SDP_ErrorResponse PDU Austausch Der Client initiiert einen Request Der Server antwortet mit einem Response Einige Responses werden in mehrere PDUs aufgeteilt Alle PDUs haben eine ContinuationState als letzten Parameter (ausser SDP_ErrorResponse) SDP_XXXXRequest SDP_XXXXResponse oder SDP_ErrorResponse SDP Client Server

SDP Client SDP Server 1A. Service_Search_Request 1B. Service_Search_Response 2A. Service_Attribute_Request 2B. Service_Search_Response

Bluetooth Profile

Schematischer Aufbau der Datenpakete des Service-Discovery-Protokolls mit den einzelnen Basisklassen

Eine fiktive Service Browsing Hierarchie Zeigt Nutzung des Browse Group Descriptors Browse Group Descriptoren (G) Andere (S)

Eine Beispiel SDP-Session Inquiry SDP Client SDP Server Link Controller Setup Page Link Manager Setup LMP Host Connection request LMP Accepted L2Cap Setup L2CAP Connection request L2CAP Connection response SDP session SDP inquiries SDP responses

RFCOMM Serielle Port Emulation oberhalb Paketorientierter Verbindung Ähnlich HDLC Zur Unterstützung von „Legacy“ Anwendungen Das RFCOMM-Protokoll unterstützt die Emulation der seriellen Ports über das L2CAP-Protokoll. Das Protokoll basiert auf dem ETSI standard TS 07.10. Nur eine Untermenge des TS 07.10-Strandards wird verwendet. Einige Bluetooth-spezifische Änderungen sind in der RFCOMM-Spezifikation festgelegt

RFCOMM - Gliederung Überblick TS07.10 Adaption für RFCOMM Geräte Typen Steuersignale Null Modem Emulation Mehrere emulierte serielle Ports TS07.10 Adaption für RFCOMM Media Adaption TS 07.10 Multiplexer Startup & Closedown Procedure DLCI Allocation with RFCOMM Server Channels Multiplexer Control Commands Verwendete Methoden zur Flußkontrolle L2CAP Flusskontrolle Wired Serial Port Flow Control RFCOMM Flow Control Port Emulation Entity : Serial Flow Control Credit Based Flow Control Andere Entity Interaction Port Emulation und Port Proxy Entities Service Registration und Discovery Zuverlässigkeit (Reliability) Energiesparende Betriebsarten (Low Power Modes)