DE10234747B4 - Verfahren zur Dienstsuche in einem Weitverkehr-Kommunikationsnetz - Google Patents

Verfahren zur Dienstsuche in einem Weitverkehr-Kommunikationsnetz Download PDF

Info

Publication number
DE10234747B4
DE10234747B4 DE10234747A DE10234747A DE10234747B4 DE 10234747 B4 DE10234747 B4 DE 10234747B4 DE 10234747 A DE10234747 A DE 10234747A DE 10234747 A DE10234747 A DE 10234747A DE 10234747 B4 DE10234747 B4 DE 10234747B4
Authority
DE
Germany
Prior art keywords
service
protocol
sdp
tcp
communication network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE10234747A
Other languages
English (en)
Other versions
DE10234747A1 (de
Inventor
Thomas Dipl.-Inform. Strang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Deutsches Zentrum fuer Luft und Raumfahrt eV
Original Assignee
Deutsches Zentrum fuer Luft und Raumfahrt eV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Deutsches Zentrum fuer Luft und Raumfahrt eV filed Critical Deutsches Zentrum fuer Luft und Raumfahrt eV
Priority to DE10234747A priority Critical patent/DE10234747B4/de
Publication of DE10234747A1 publication Critical patent/DE10234747A1/de
Application granted granted Critical
Publication of DE10234747B4 publication Critical patent/DE10234747B4/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/52—Network services specially adapted for the location of the user terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/005—Discovery of network devices, e.g. terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Dienstsuchverfahren, das vor dem eigentlichen Aufbau oder ohne dann tatsächlich erfolgenden Aufbau einer einen gewünschten Dienst nutzenden Kommunikationsverbindung zwischen zwei oder mehr an einer Übertragung innerhalb eines grundsätzlich unlimitierten Weitverkehr-Kommunikationsnetzes beteiligten Kommunikationsgeräten wirksam wird, bei dem dienstcharakterisierende Parameter zur Auffindung des gewünschten Dienstes unter Anwendung des Weitverkehr-Kommunikationsnetz-Protokolls Internet Protocol IP, User Datagramm Protocol UDP oder Transport Control Protocol TCP und des im Rahmen der drahtlosen Kommunikationstechnik "BluetoothTM" spezifizierten Service Discovery Protocol SDP ausgetauscht werden und bei dem SDP in das beim betreffenden Weitverkehr-Kommunikationsnetz verwendete IP, UDP oder TCP als Payload eingebunden wird, dadurch gekennzeichnet, dass ein SDPoverIP-Server zusätzlich zu den dienstcharakterisierenden Parametern den Ort zumindest eines der beteiligten Kommunikationsgeräte bestimmt.

Description

  • Die Erfindung betrifft ein Dienstsuchverfahren, das vor dem eigentlichen Aufbau oder ohne dann tatsächlich erfolgenden Aufbau einer einen gewünschten Dienst nutzenden Kommunikationsverbindung zwischen zwei oder mehr an einer Übertragung innerhalb eines grundsätzlich unlimitierten Weitverkehr-Kommunikationsnetzes beteiligten Kommunikationsgeräten wirksam wird, bei dem dienstcharakterisierende Parameter zur Auffindung des gewünschten Dienstes unter Anwendung des Weitverkehr-Kommunikationsnetz-Protokolls Internet Protocol IP, User Datagramm Protocol UDP oder Transport Control Protocol TCP und des im Rahmen der drahtlosen Kommunikationstechnik "BluetoothTM" spezifizierten Service Discovery Protocol SDP ausgetauscht werden und bei dem SDP in das beim betreffenden Weitverkehr-Kommunikationsnetz verwendete IP, UDP oder TCP als Payload eingebunden wird.
  • In Ad-Hoc-Kommunikationsnetzwerken, insbesondere unter Verwendung drahtloser Kommunikationstechniken wie "BluetoothTM", stellt sich vor dem Aufbau einer Verbindung zwischen zwei oder mehr an der Übertragung beteiligten Kommunikationsgeräten das Problem der Notwendigkeit des Austausches von Parametern, welche die Verbindung selbst sowie darauf aufsetzende Protokolle und Dienste charakterisieren. Beispielsweise wird ein Gerät A nur dann eine Verbindung zu einem anderen Gerät B aufbauen, wenn ein für die jeweilige Aufgabenstellung notwendiges Merkmal der Verbindung, beispielsweise die Bereitstellung einer Adresse von Gerät B für Gerät A oder die Existenz einer bestimmten Dienst-Server-Komponente, vom Gerät B unterstützt wird.
  • Darüber hinaus stellt sich für das Gerät A das zusätzliche Problem, bei Existenz eines bestimmten Dienstes auf unterschiedlichen Geräten B, C, D, ... anhand verschiedener Merkmale den jeweiligen Dienst auf den unterschiedlichen Geräten B, C, D, ... zu bewerten, um einen für die jeweilige Aufgabenstellung optimalen Partner für einen Verbindungsaufbau zu bestimmen.
  • Bei der Auswahl eines Dienstes ist insbesondere das Merkmal der Zuständigkeit eines Dienstes für einen Ort und/oder die Nutzbarkeit von Ortsinformationen für einen Dienst ("location awareness", "Ortswissen") zu berücksichtigen. Dieses ermöglicht die Nutzung eines Dienstes an unterschiedlichen Orten in einer auf den jeweiligen Ort zugeschnittenen Art und Weise.
  • Das vor dem Verbindungsaufbau entstehende Problem der Notwendigkeit des Austauschs von Parametern wurde bisher in drahtlosen Ad-Hoc-Netzwerken vornehmlich entsprechend zwei verschiedenen Verfahrensweisen bewältigt.
  • Die erste bekannte Verfahrensweise besteht darin, daß fixe Parameter vorgesehen werden. Diese z. B. bei Wireless-LAN (WLAN) eingesetzte Verfahrensweise setzt eine administrative Konfiguration eines Gerätes voraus, die damit den oder die Kandidaten für einen Verbindungsaufbau unter Verwendung der einmal eingestellten Parameter festlegt.
  • Die zweite bekannte Verfahrensweise beruht auf einer Suche nach Diensten (Service Discovery). Diese z. B. bei "Bluetooth" in Form des Service Discovery Protocols SDP eingesetzte Verfahrensweise ermöglicht die Suche nach bestimmten Diensten, nach Diensten mit bestimmten Eigenschaften sowie nach Informationen, die für die Ausführung bestimmter Dienste erforderlich sind. Kommt ein Bluetooth-Gerät A in die funktechnische Reichweite eines anderen Bluetooth-Gerätes B, so kann das Gerät A unter Verwendung von SDP feststellen, ob das Gerät B "kompatibel" bezüglich der jeweiligen Aufgabenstellung für eine Verbindung ist und erfährt auch alle für die Verwendung des gewünschten Dienstes notwendigen Parameter, z. B. die IP-Adresse und Port-Nummer für einen Web-Dienst (WebService).
  • Die Zuständigkeit eines Dienstes für einen Ort und/oder die Nutzbarkeit von Ortsinformationen für einen Dienst ("location awareness", "Ortswissen") eines Dienstes werden in drahtlosen Nahbereichsnetzen naturgemäß durch die beschränkten Ausbreitungsbedingungen des Übertragungsverfahrens unterstützt. So kann der gleiche Dienst auf zwei Geräten an unterschiedlichen Orten in einer auf den jeweiligen Ort zugeschnittenen Art und Weise angeboten werden. Durch die beschränkte Reichweite der Sendeeinheit des jeweiligen Kommunikationsgerätes, bei "Bluetooth" in der Regel einige Meter, sind die örtliche Zuständigkeit eines Dienstes und/oder die Nutzbarkeit von Ortsinformationen für einen Dienst vorgegeben.
  • In Netzwerken, in welchen die zu Grunde liegende physikalische Topologie so weit abstrahiert wird, daß die Gültigkeit einer Information oder eines Dienstes nicht limitiert ist, also z. B. in einem IP-Netzwerk, wird gemäß dem heutigen Stand der Technik das Problem der Auffindung eines passenden Dienstes mit anderen Protokollen, wie z. B. mit JiniTM, bewältigt. Die Zuständigkeit eines Dienstes für einen Ort und/oder die Nutzbarkeit von Ortsinformationen für einen Dienst ("location awareness", "Ortswissen") werden in diesen Netzen zumeist durch zentrale Datenbanken abgebildet, die über diverse unterschiedliche Protokolle über die Zuständigkeit von Diensten für Regionen oder Orte Auskunft geben.
  • Ein Nachteil bei den bekannten Verfahren besteht darin, daß vor dem Verbindungsaufbau unterschiedliche, komplexe Protokolle zum Auffinden von Diensten und ihren Eigenschaften in drahtlosen und drahtgebundenen Netzwerken verwendet werden. Da drahtlose, mobile Endgeräte, typischerweise also Mobiltelefone oder Personal Digital Assistents (PDAs), in der Regel nur über sehr begrenzte Ressourcen verfügen, sollte hierbei möglichst viel Funktionalität mit einer Protokollimplementierung abgedeckt sein.
  • Darüber hinaus ist festzustellen, dass zwar in drahtlosen Nahbereichsnetzen die Zuständigkeit eines Dienstes für einen Ort und/oder die Nutzbarkeit von Ortsinformationen für einen Dienst ("location awareness", "Ortswissen") implizit gegeben sind, dieses Merkmal aber in Netzen ohne implizit gegebene Limitierung unter Verwendung mindestens eines anderen Protokolls die örtliche Gültigkeit nachgebildet werden muss. Ein weiterer Nachteil besteht darin, dass Service Discovery Protokolle, die für drahtgebundene Netzwerkverbindungen entworfen und ausgelegt worden sind, Störungen, wie sie in drahtlosen Netzen häufig auftreten, gewöhnlich nur sehr unzureichend berücksichtigen.
  • Aus US 2001/0033554 A1 ist eine Bluetooth-Brückenkoppelvorrichtung (Bluetooth Piconet Proxy-Bridge Device with IP/UPnP Bridge) bekannt, die dazu dient, zwischen einer oder mehreren Funk-Bluetooth-Einrichtungen und an das Internet-Netzwerk angeschlossenen Geräten oder Servern Informationspakete zu übertragen. Diese Bluetooth-Brückenkoppelvorrichtung arbeitet mit den Bluetooth-Einrichtungen über Funk mittels des Bluetooth-Protokolistacks zusammen. Darüber hinaus erlaubt der Protokollstack eine Anwendung, um mit einem an das Internet-Netzwerk angeschlossenen Gerät über das Internet-Protokoll IP zu kommunizieren. Die mithin zwei Protokolle benutzende Brückenkoppelvorrichtung versetzt entfernte Nutzer eines an das Internet angeschlossenen Gerätes in die Lage, das Vorhandensein eines in einer Bluetooth-Einrichtung angebotenen Dienstes zu entdecken (service discovering), so als sei diese in der Brückenkoppelvorrichtung eingebaut. Das Ganze funktioniert ebenso umgekehrt. Die Service Discovery Protocol(SDP)-Informationen werden auf einer übergeordneten Schicht umgesetzt, bevor sie an den TCP/IP-Stack übergeben werden. SDP ist somit in das beim betreffenden Weitverkehr-Kommunikationsnetz verwendete IP als Payload eingebunden.
  • Gemäß einem aus DE 101 49 956 A1 bekannten Verfahren zur Datenübertragung zwischen einer Steuereinheit und einem Bluetooth-Access-Point werden HCI (Host Controller Interface)-Informationen über TCP bzw. UDP als Transportprotokoll übertragen. HCI ist eine dem L2CAP von Bluetooth untergeordnete Ebene im Bluetooth-Protokollstack. Dieses bekannte Verfahren setzt demnach auf einer tieferen Ebene an, wobei zur Nutzung von SDP das Vorhandensein von L2CAP vorausgesetzt wird. Auch hier ist somit SDP in das beim betreffenden Weitverkehr-Kommunikationsnetz verwendete Transportprotokoll als Payload eingebunden.
  • Bei allen diesen bekannten Datenübertragungsverfahren mit Dienstsuche ist es jedoch nicht möglich, den momentanen Aufenthaltsort eines Kommunikationsgeräts zu bestimmen, so dass die Zuständigkeit eines Dienstes für diesen Ort und/oder die Nutzbarkeit von diesbezüglichen Ortsinformationen für einen Dienst erkannt und das betreffende Kommunikationsgerät an seinem Aufenthaltsort gewünschte Dienste nutzen kann.
  • Der Erfindung liegt die Aufgabe zu Grunde, ein vor dem eigentlichen Aufbau einer einen gewünschten Dienst einschließenden Verbindung zwischen zwei oder mehr Kommunikationsgeräten wirksames Verfahren zu schaffen, das in drahtlosen und drahtgebundenen Weitverkehr-Kommunikationsnetzwerken ohne Verwendung unterschiedlicher, komplexer Protokolle gewünschte ortsbezogene Dienste und ihre Eigenschaften auffindet, und dies mit dem Potential hoher lokaler Relevanz in eigentlich ortstransparenten Weitverkehr-Kommunikationsnetzen. Das durch die Erfindung zu schaffende Verfahren soll insbesondere in der Lage sein, für ein Kommunikationsgerät für seinen Aufenthaltsort zuständige Dienste aufzufinden und/oder seinen Aufenthaltsort betreffende Informationen für einen Dienst zu nutzen. Der ortszuständige Dienst soll auch dann aufgefunden werden, wenn danach kein Verbindungsaufbau zwischen Kommunikationsgeräten erfolgt.
  • Gemäß der Erfindung, die sich auf ein Verfahren der eingangs genannten Art bezieht, wird diese Aufgabe dadurch gelöst, dass ein SDPoverIP-Server zusätzlich zu den dienstcharakterisierenden Parametern den Ort zumindest eines der beteiligten Kommunikationsgeräte bestimmt.
  • Das im Rahmen von "Bluetooth" festgelegte Service Discovery Protocol SDP wird dabei zur Suche nach Diensten ausschließlich als einziges Protokoll in drahtlosen wie drahtgebundenen Netzen einheitlich verwendet.
  • Die einheitliche Verwendung ausschließlich eines Protokolls zur Suche nach Diensten im drahtlosen wie drahtgebundenen Netz ermöglicht den Einsatz bei ressourcenmäßig stark beschränkten, mobilen Geräten, wenn diese über Zugangsknoten mit dem Festnetz in Verbindung stehen.
  • Der Zugriff auf Informationen, welche die Zuständigkeit eines Dienstes für einen Ort und/oder die Nutzbarkeit von Ortsinformationen für einen Dienst ("location awareness", "Ortswissen") betreffen, kann über das in das Internet-Protokoll IP des betreffenden Weitverkehr-Kommunikationsnetzes als Payload eingebundene Service Discovery Protocol SDP abgewickelt werden.
  • Zum Datenaustausch mit einem IP-Server oder einem anderen IP-Kommunikationspartner können UDP(User Datagram Protocol)-Pakete verwendet werden. Für die Funktionalität der Dienstauffindung des als Payload in das Internet-Protokoll IP des Weitverkehr-Kommunikationsnetzes eingebundenen Service Discovery Protocol SDP kann eine Port-Nummer assoziiert werden.
  • Zum Datenaustausch mit einem IP-Server oder einem anderen IP-Kommunikationspartner können die in das Internet-Protokoll IP eingebundenen SDP-Nachrichten (SDPoverIP-messages) aber auch in ein auf TCP (Transport Control Protocol) aufsetzendes Request-Response-Protocol wie HTTP gekapselt werden.
  • In ähnlicher Weise können zum Datenaustausch mit einem IP-Server oder einem anderen IP-Kommunikationspartner aber auch die in das Internet-Protokoll IP eingebundenen SDP-Nachrichten (SDPoverIP-messages) auf einer höheren, auf dem TCP/IP-Stack aufsetzenden Ebene implementiert werden.
  • In diesem Falle kann dann in zweckmäßiger und beispielhafter Weise in Form eines Web-Dienstes (WebService) eine Realisierung erfolgen, bei der in Form von Remote-Procedure Calls (RPC) strukturierte Daten wie SDP-Nachrichten codiert über HTTP und TCP im Request-Response-Verfahren ausgetauscht werden.
  • Das Verfahren nach der Erfindung lässt sich in vorteilhafter Weise in Plattformen verwenden, welche die verteilte Ausführung von Diensten ermöglichen.
  • Das erfindungsgemäße Verfahren wird nachfolgend anhand von Zeichnungen erläutert. Es zeigen:
  • 1 in einem schematisch dargestellten Beispiel den bekannten Ablauf eines Verbindungsaufbaus mit vorheriger Dienstsuche unmittelbar zwischen zwei "Bluetooth"-Geräten unter Anwendung von SDP,
  • 2 in einem schematisch dargestellten Beispiel den Ablauf eines Verbindungsaufbaus zwischen zwei Geräten in einem unlimitierten Weitverkehr-Kommunikationsnetz mit vorheriger Dienstsuche im Wege über das in IP einbezogene SDP, und
  • 3 den beispielhaften Ablauf des Verfahrens nach der vorliegenden Erfindung in einer schematischen Darstellung, welche die Zuständigkeit eines Dienstes für einen Ort und/oder die Nutzbarkeit von Ortsinformationen für einen Dienst ("location awareness", "Ortswissen") im IP-Netzwerk ausschließlich unter Verwendung von in IP einbezogenem SDP (SDPoverIP) anhand des Zugriffs eines mobilen Endgerätes auf IP-basierte, ortsabhängige Dienste über SDPoverIP zeigt.
  • In 1 ist schematisch anhand eines Beispiel der bekannte Ablauf eines Verbindungsaufbaus mit vorheriger Dienstsuche unmittelbar zwischen zwei "Bluetooth"-Geräten A und B unter Anwendung von Service Discovery Protocol SDP dargestellt.
  • Zuerst wird ermittelt, ob in der gegenseitigen Funkreichweite ein Kommunikationspartner vorhanden ist. In 1 ist dieser Vorgang durch die Strecke (I) symbolisiert (Gerätesuche: Gerät A: "Ist da jemand?" Gerät B: "Ich, Gerät B, bin da."). Nach erfolgter Feststellung der Existenz eines möglichen Kommunikationspartners in Form des "Bluetooth"-Gerätes A oder B in der gegenseitigen Funkreichweite wird gemäß der "Bluetooth"-Protokollhierarchie eine L2CAP(Logical Link Control and Adaptation Protocol)-Verbindung hergestellt, über die dann das SDP-Request-Response-Protokoll abläuft, in dessen Verlauf ein Dienst auf dem Gerät B identifiziert wird, der über die vom Gerät A gewünschten Eigenschaften verfügt.
  • Dieser Vorgang ist in 1 durch die Strecke (II) symbolisiert (SDP over L2CAP: Gerät A: "Hast Du Dienst der Klasse X?" Gerät B: "Ja, handle = 4711."). Der Zugriff auf diesen Dienst, der von Gerät B bereitgestellt wird, erfolgt dann unter Verwendung der ausgehandelten Parameter über eine danach aufzubauende neue Verbindung. Dieser Vorgang ist in 1 durch die Strecke (III) symbolisiert (Dienstnutzung; "use service").
  • In 2 ist schematisch anhand eines Beispiels der Ablauf eines Verbindungsaufbaus mit vorheriger Dienstsuche zwischen zwei Geräten A und B innerhalb eines grundsätzlich unbeschränkten Weitverkehr-Kommunikationsnetzes im Wege über das in das Internet-Protokoll IP dieses Netzes einbezogene Service Discovery Protocol SDP (SDP over IP) gemäß der Erfindung dargestellt. Zunächst wird vom Gerät A ein möglicher Kommunikationspartner S für das SDP-Protokoll gefunden. Hier können in ähnlicher Weise wie beim DNS(Domain Name System)-Verfahren in IP-Netzen einige feste Root-Knoten kontaktiert werden oder per IP-Multicast mögliche SDPoverIP-Server ermittelt werden. Für die Bewältigung der hier aufgezeigten Aufgabe spielt die Art der Auffindung des Kommunikationspartners S keine Rolle. Im dargestellten Beispiel ist der kontaktierte Kommunikationspartner S ein SDPoverIP-Server.
  • Dieser Vorgang ist in 2 durch die Strecke (I) symbolisiert (Peer Discovery: Gerät A: "Ist da ein SDPoverIP-Server?" Kommunikationspartner S: "Ich, sdp.dlr.de:8000."), wobei das Gerät A die IP-Adresse aaa.bbb.ccc.ddd und der aufgefundene Kommunikationspartner S ein SDPoverIP-Server mit der Internet-Adresse sdp.dlr.de:8000 ist. Wichtig sind die danach folgenden Schritte, in deren Verlauf das "Bluetooth"-SDP-Request-Response-Protokoll als Payload von UDP(User Datagram Protocol)-Paketen zwischen dem Gerät A und dem als SDPoverIP-Server ausgebildeten Kommunikationspartner S ausgetauscht werden.
  • Dieser Vorgang ist in 2 durch die Strecke (II) symbolisiert (SDP over UDP(IP): Gerät A: "Hast Du Dienst der Klasse X?" Kommunikationspartner S: "Ja, handle = 4711. Zuständig = Gerät B"). Einer der dabei über SDP ausgetauschten Parameter gibt also darüber Auskunft, welcher Knoten im Netzwerk den gesuchten Dienst anbietet. In dem in 2 dar gestellten Beispiel ist dieser Knoten das Gerät B. Das Gerät A baut dann zur Nutzung des gewünschten Dienstes zu diesem Knoten, also zum Gerät B, eine Verbindung auf. Dieser Vorgang ist in 2 durch die Strecke (III) symbolisiert (Dienstnutzung; "use service"), wobei das angesprochene Gerät B im Beispiel die IP-Adresse eee.fff.ggg.hhh hat.
  • Eine Implementierung des den Kommunikationspartner S bildenden SDPoverIP-Servers unter Verwendung von Raw-IP-Paketen erscheint ebenfalls möglich, setzt aber in der Regel Zugriff auf Elemente des IP-Stacks voraus. Einfacher und zweckmäßiger ist hier gewöhnlich die Verwendung von UDP(User Datagram Protocol)-Paketen, da auf diese von der Anwendungsebene zugegriffen werden kann. Die Festlegung auf eine für diese Funktionalität reservierte Port-Nummer (Internet Assigned Number) ist vorteilhaft, ist aber nicht zwingend vorauszusetzen. Da es sich bei SDP um ein Request-Response-Protokoll handelt, ist die grundsätzliche Verwendung von TCP (Transmission Control Protocol) nicht zweckmäßig, da der Verkehr nicht streamorientiert ist. Die Kapselung der SDPoverIP-Messages in ein auf TCP aufsetzendes Request-Response-Protokoll wie HTTP ist z. B. dann zweckmäßig, wenn die zu Grunde liegende Plattform ausschließlich HTTP als einziges Kommunikationsprotokoll bietet, wie z. B. bei Geräten, die das Mobile Information Device Profile (MIDP) der Java2Micro EditionTM implementieren.
  • Weiterhin kann das Verfahren auf einer höheren, auf dem TCP/IP-Stack aufsetzenden Ebene implementiert werden. Hier bietet sich z. B. die Realisierung als Web-Dienst (WebService) an, die es als eine Form des Remote Procedure Calls (RPC) erlaubt, strukturierte Daten wie SDP-Nachrichten (SDP messages) in EXtendable Markup Language (XML) codiert über HTTP und TCP im Request-Response-Verfahren auszutauschen.
  • In 3 ist anhand eines Beispiels schematisch dargestellt, wie die Zuständigkeit eines Dienstes für einen Ort und/oder die Nutzbarkeit von Ortsinformationen für einen Dienst ("location awareness", "Ortswissen") im IP-Netzwerk ausschließlich unter Verwendung des in das Internet-Protokoll IP eingebundenen Service Discovery Protokolls SDP bewältigt werden (SDPoverIP).
  • Ein mobiles, drahtlos übertragendes Kommunikations-Endgerät WID baut eine Datenverbindung, z. B. per GPRS (General Packet Radio Service), zu einem Dial-In-Router DIR eines Netzwerkbetreibers auf und erhält von diesem eine für die Dauer der Verbindung gültige IP-Adresse zugewiesen.
  • Dieser Vorgang ist in 3 durch die Strecke (I) symbolisiert. Damit bildet das Kommunikations-Endgerät WID einen Knoten im IP-Netz und kann per UDP-Paketen samt SDP-Payload unter Angabe eines searchPatterns bei einem SDPoverIP-Server S seiner Wahl, z. B. mit der Internet-Adresse sdp.dlr.de:8000, nach einem Dienst mit den gewünschten Eigenschaften suchen. Dieser Vorgang ist in 3 durch die Strecke (II) symbolisiert. Der SDPoverIP-Server S kann zusätzlich zu den in der Anfrage enthaltenen Parametern bei einer Ortsdatenbank (Location Database) LD des Netzbetreibers über die IP-Adresse des Absenders der Anfrage, also des Kommunikations-Endgerätes WID, dessen momentanen Aufenthaltsort bestimmen. Dieser Vorgang ist in 3 durch die Strecke (III) symbolisiert. Mit diesen beiden Informationen kann der SDPoverIP-Server S in seiner Zuständigkeits-Datenbank ZD nachschlagen, welcher der Dienst-Server S1, S2, ... für den jeweiligen Dienst am jeweiligen Ort zuständig ist. Ein Beispiel für die verschiedenen Zuständigkeiten der Dienst-Server S1, S2, ... ist in 3 neben der Zuständigkeits-Datenbank ZD angegeben.
  • Nach dem Nachschlagen in der Zuständigkeits-Datenbank ZD kann der SDPoverIP-Server S diese Information in Form der z. B. dem Server S1 zugeordneten IP-Adresse an das Kommunikations-Endgerät WID übermitteln. Dieser Vorgang ist in 3 durch die Strecke (IV) symbolisiert. Das Kommunikations-Endgerät WID kann dann mit dem als zuständig erkannten und übermittelten Dienst-Server S1 in Verbindung treten, um den gewünschten Dienst zu nutzen. Dieser Vorgang ist in 3 durch die Strecke (V) symbolisiert.
  • Es ist anzumerken, daß jede so per UDP-Payload übermittelte Nachricht sowie alle Request-Response-Zyklen dem im "Bluetooth"-Standard spezifizierten Service Discovery Protocol SDP entsprechen.
    • A
    Gerät
    B
    Gerät, Knoten
    DIR
    Dial-In-Router
    LD
    Ortsdatenbank (Location Database)
    S
    Kommunikationspartner, SDPoverIP-Server
    S1, S2, ...
    Dienst-Server
    WID
    Kommunikations-Endgerät
    ZD
    Zuständigkeits-Datenbank

Claims (8)

  1. Dienstsuchverfahren, das vor dem eigentlichen Aufbau oder ohne dann tatsächlich erfolgenden Aufbau einer einen gewünschten Dienst nutzenden Kommunikationsverbindung zwischen zwei oder mehr an einer Übertragung innerhalb eines grundsätzlich unlimitierten Weitverkehr-Kommunikationsnetzes beteiligten Kommunikationsgeräten wirksam wird, bei dem dienstcharakterisierende Parameter zur Auffindung des gewünschten Dienstes unter Anwendung des Weitverkehr-Kommunikationsnetz-Protokolls Internet Protocol IP, User Datagramm Protocol UDP oder Transport Control Protocol TCP und des im Rahmen der drahtlosen Kommunikationstechnik "BluetoothTM" spezifizierten Service Discovery Protocol SDP ausgetauscht werden und bei dem SDP in das beim betreffenden Weitverkehr-Kommunikationsnetz verwendete IP, UDP oder TCP als Payload eingebunden wird, dadurch gekennzeichnet, dass ein SDPoverIP-Server zusätzlich zu den dienstcharakterisierenden Parametern den Ort zumindest eines der beteiligten Kommunikationsgeräte bestimmt.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Zugriff auf Informationen, welche die Zuständigkeit eines Dienstes für einen Ort und/oder die Nutzbarkeit von Ortsinformationen für einen Dienst ("location awareness", "Ortswissen") betreffen, über das in das Internet-Protokoll IP des betreffenden Weitverkehr-Kommunikationsnetzes als Payload eingebundene Service Discovery Protocol SDP abgewickelt wird.
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß zum Datenaustausch mit einem IP-Server (S) oder einem anderen IP-Kommunikationspartner UDP(User Datagram Protocol)-Pakete verwendet werden und daß für die Funktionalität der Dienstauffindung des als Payload in das Internet-Protokoll IP des Weitverkehr-Kommunikationsnetzes eingebundenen Service Discovery Protocol SDP eine Port-Nummer assoziiert wird.
  4. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß zum Datenaustausch mit einem IP-Server (S) oder einem anderen IP-Kommunikationspartner die in das Internet-Protokoll IP eingebundenen SDP-Nachrichten (SDPoverIP-messages) in ein auf TCP (Transport Control Protocol) aufsetzendes Request-Response-Protocol wie HTTP gekapselt werden.
  5. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß zum Datenaustausch mit einem IP-Server (S) oder einem anderen IP-Kommunikationspartner die in das Internet-Protokoll IP eingebundenen SDP-Nachrichten (SDPoverIP-messages) auf einer höheren, auf dem TCP/IP-Stack aufsetzenden Ebene implementiert werden.
  6. Verfahren nach Anspruch 4 oder 5, gekennzeichnet durch eine Realisierung als Web Service.
  7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, daß in Form von Remote-Procedure Calls (RPC) strukturierte Daten wie SDP-Nachrichten codiert über HTTP und TCP im Request-Response-Verfahren ausgetauscht werden.
  8. Verfahren nach einem der vorhergehenden Ansprüche, gekennzeichnet durch die Verwendung in Plattformen, welche die verteilte Ausführung von Diensten ermöglichen.
DE10234747A 2002-07-30 2002-07-30 Verfahren zur Dienstsuche in einem Weitverkehr-Kommunikationsnetz Expired - Fee Related DE10234747B4 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE10234747A DE10234747B4 (de) 2002-07-30 2002-07-30 Verfahren zur Dienstsuche in einem Weitverkehr-Kommunikationsnetz

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE10234747A DE10234747B4 (de) 2002-07-30 2002-07-30 Verfahren zur Dienstsuche in einem Weitverkehr-Kommunikationsnetz

Publications (2)

Publication Number Publication Date
DE10234747A1 DE10234747A1 (de) 2004-02-19
DE10234747B4 true DE10234747B4 (de) 2009-02-26

Family

ID=30469209

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10234747A Expired - Fee Related DE10234747B4 (de) 2002-07-30 2002-07-30 Verfahren zur Dienstsuche in einem Weitverkehr-Kommunikationsnetz

Country Status (1)

Country Link
DE (1) DE10234747B4 (de)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010033554A1 (en) * 2000-02-18 2001-10-25 Arun Ayyagari Proxy-bridge connecting remote users to a limited connectivity network
WO2002051067A2 (en) * 2000-12-19 2002-06-27 Koninklijke Philips Electronics N.V. Plug and play enabling device for heterogeneous networks of slave devices
EP1220510A2 (de) * 2000-12-22 2002-07-03 Microsoft Corporation Verfahren und System für Kontextbewussten Bestimmung und Durchfuhrung eines Richtlinien
DE10149956A1 (de) * 2001-10-10 2003-04-30 Tenovis Gmbh & Co Kg Verfahren und Anordnung zur Datenübertragung zwischen einer Steuereinheit und einem Bluetooth-Access-Point

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010033554A1 (en) * 2000-02-18 2001-10-25 Arun Ayyagari Proxy-bridge connecting remote users to a limited connectivity network
WO2002051067A2 (en) * 2000-12-19 2002-06-27 Koninklijke Philips Electronics N.V. Plug and play enabling device for heterogeneous networks of slave devices
EP1220510A2 (de) * 2000-12-22 2002-07-03 Microsoft Corporation Verfahren und System für Kontextbewussten Bestimmung und Durchfuhrung eines Richtlinien
DE10149956A1 (de) * 2001-10-10 2003-04-30 Tenovis Gmbh & Co Kg Verfahren und Anordnung zur Datenübertragung zwischen einer Steuereinheit und einem Bluetooth-Access-Point

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
DE 101 49 956 A1 (ältere Anmeldung); RAMAN, B.; BH AGWAT, P.; SESHAN, S.: Arguments for crosslayer op timizations in Bluetooth scatternets. In: Proceedi ngs of 2001 Symposium on Applications and the Inte rnet,8-12 Jan. 2001,S.176-184
RAMAN, B., BHAGWAT, P., SESHAN, S.: Arguments for crosslayer optimizations in Bluetooth scatternets. In: Proceedings of 2001 Symposium on Applications and the Internet,8-12 Jan. 2001,S.176-184 *

Also Published As

Publication number Publication date
DE10234747A1 (de) 2004-02-19

Similar Documents

Publication Publication Date Title
DE60127680T2 (de) Mobiles Endgerät und Verfahren zur Netz-zu-Netz-Verbindung
DE60206894T2 (de) Verfahren und vorrichtung zur herstellung eines protokoll-proxy für ein mobiles host-endgerät in einer multimediasitzung
DE19950653B4 (de) Verfahren zum Betreiben eines Mobilfunknetzes
DE69533740T2 (de) TCP/IP-Kopfendekompression in X.25-Netzwerken
DE69735426T2 (de) Nachrichtenübertragung in netzwerken bestehend aus unternetzwerken mit verschiedenen namensraümen
EP2005700B1 (de) Verfahren zur ermittlung einer aufgabenerlaubnis
EP2274935B1 (de) Verfahren und vorrichtung zum herstellen von zumindest einer erweiterung einer zuordnungsnachricht für wireless mesh netze
DE112004000040T5 (de) Verfahren und System für das Erzeugen von IP-Adressen von Zugangsterminals und das Senden von Nachrichten für die Erzeugung von IP-Adressen in einem IP-System
EP2387261B1 (de) Bereitstellung einer Ende-zu-Ende-Verbindung von einer Endeinheit in ein Netz
DE60211287T2 (de) Handhabung von Verbindungen, die zwischen Firewalls umziehen
EP1494434B1 (de) Verfahren zur Konfiguration einer Einrichtung in einem Datennetz
DE10316236B4 (de) Verfahren und Anordnung zur Konfiguration einer Einrichtung in einem Datennetz
DE102014000763B4 (de) Kommunikationssystem und Kommunikationsverfahren
DE10234747B4 (de) Verfahren zur Dienstsuche in einem Weitverkehr-Kommunikationsnetz
DE60213010T2 (de) Verfahren und vorrichtung zum herstellen eines l2cap-kanals, der fest für die datenflussübertragung in bluetooth-netzwerken zugewiesen ist
DE60320567T2 (de) Adressenverwaltungsverfahren
EP2171943B1 (de) Verfahren zum routen von dienstnachrichten
WO2001071986A1 (de) Verfahren und anordnung zum übertragen eines datenpakets von einer ersten vermittlungseinheit an eine zweite vermittlungseinheit in einem datennetz
DE102006009988B4 (de) Kommunikationssystem, Rechner und Verfahren zum Ermitteln eines zu verwendenden Kommunikationsprotokolls in einem Kommunikationssystem
WO2004100498A1 (de) Verfahren zum datenaustausch zwischen netzelementen in netzwerken mit verschiedenen adressbereichen
DE602004000630T2 (de) Adressverarbeitung von Kommunikationsendgeräten durch Integration und/oder Extraktion von Kommunikationsschnittstellenmerkmalen in der Adresse
WO2020038820A1 (de) Verfahren zum einrichten eines streams, verfahren zur bereitstellung von stream-kennungs-informationen, verwendung eines dns-servers, gerät, computerprogramm und computerlesbares medium
DE60209322T2 (de) Anschluss von Benutzergeräten Selektivezugangschnittstelle von einem ISP-router
EP1774754B1 (de) Mobiles kommunikationsendgerät zur verwendung in mehreren drahtlosen lokalen netzwerken und verfahren zum betrieb desselben
DE10061128A1 (de) Verfahren zur Durchführung von Überwachungsmaßnahmen in Telekommunikation- und Datennetzen mit beispielsweise IP-Protokoll (Internet Protokoll)

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8127 New person/name/address of the applicant

Owner name: DEUTSCHES ZENTRUM FUER LUFT- UND RAUMFAHRT E.V.

8127 New person/name/address of the applicant

Owner name: DEUTSCHES ZENTRUM FUER LUFT- UND RAUMFAHRT E.V.

8364 No opposition during term of opposition
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee

Effective date: 20150203