EP1719303A1 - Procede pour etablir une liaison entre un demandeur de service (client) et un prestataire de services (serveur) dans un reseau de communication mobile decentralise - Google Patents

Procede pour etablir une liaison entre un demandeur de service (client) et un prestataire de services (serveur) dans un reseau de communication mobile decentralise

Info

Publication number
EP1719303A1
EP1719303A1 EP04803179A EP04803179A EP1719303A1 EP 1719303 A1 EP1719303 A1 EP 1719303A1 EP 04803179 A EP04803179 A EP 04803179A EP 04803179 A EP04803179 A EP 04803179A EP 1719303 A1 EP1719303 A1 EP 1719303A1
Authority
EP
European Patent Office
Prior art keywords
service
client
server
message
route
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.)
Withdrawn
Application number
EP04803179A
Other languages
German (de)
English (en)
Inventor
Reinhold Braam
Michael Franzen
Wolfgang Gröting
Gesa Lorenz
Sebastian Obermanns
Malte Schmidt
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.)
Unify GmbH and Co KG
Original Assignee
Siemens AG
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 Siemens AG filed Critical Siemens AG
Publication of EP1719303A1 publication Critical patent/EP1719303A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/26—Route discovery packet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding

Definitions

  • the routing mechanisms In future public broadband radio networks, the routing mechanisms (path search mechanisms) of ad hoc networks (decentralized networks with preferably mobile stations) will be used.
  • the ad-hoc routing protocol is based on IP (Internet Protocol) packet switching and has the task of finding a way within the radio network from the origin to the destination node of a data flow. In the event that there is no direct connection, the task is to select a set of routers that enables the transmission of the IP packets. The routers forward received IP packets to the next router or the destination station.
  • IP Internet Protocol
  • AODV Ad hoc On Demand Distance Vector Routing Protocol
  • DSR Dynamic Source Routing Protocol for Mobile Ad Hoc Networks
  • DSDV Destination-Sequence Distance-Vector for mobile Computers
  • the search for a service provider can be done centrally with a "directory service” or decentrally.
  • the service requester client
  • the stations that offer the corresponding service (server) respond to this.
  • the answer is then called the "Service Discovery Reply (SD-REP)" message.
  • SD-REQ message is a multicast message that all stations in a geographical area reach. Every station in the ad hoc network is enough forward the multicast message to its neighboring stations. Server stations respond with a detailed description of the requested service in the SD-REP message.
  • the response from a server now takes the path that the "Service Discovery" message traveled a short time earlier. While there is in principle a corresponding behavior in the routing protocol AODV, this is not provided for in SD-REQ and SD-REP messages. Since routing tables in the routers are only adapted when using the AODV protocol, but not when forwarding messages of the Service Discovery protocol, a route between the corresponding stations must currently still be found after the Service Discovery.
  • the client floods an SD-REQ message.
  • the search for the service requester is started for each server that offers the service. This means that every server floods R-REQ messages in order to generate a route to the client.
  • the client responds with R-REP.
  • the path between server and client now exists and the server can respond with SD-REP.
  • the client can now select a server and establish a connection to this server in order to use the service sought or to obtain further information.
  • Another solution to avoid multicast messages during service discovery is for servers to register their services with a central server. Clients would then first contact this central server in order to determine the IP addresses of the servers that offer the service they are looking for.
  • a client If a client has now selected a server, it also knows its IP address and can then send the normal R-REQ to determine a route to the server.
  • the disadvantage of this second solution is that one or more server databases have to be set up. The addresses of these stations have to be announced somehow.
  • the client station still has to flood multicast messages in order to determine the route to the server database and, if necessary, the route to the server.
  • the inventors have recognized that it is possible to minimize the signaling overhead, even if the multicast message sent by the service requester (client), the routing tables used in the routers when the service provider (server) is sought, with route information to the service requester (client ) is provided.
  • service Discovery Request SD-REQ
  • each station receiving these SD-REQ and SD-REP messages can update its internal routing tables due to the additional information elements, so that a second explicit route search can be omitted. It is advantageous if an AODV or a DSR protocol is used as the route search protocol, which is integrated in the service request message (Service Discovery Request) and in the response message (SD-REP).
  • routing protocols are reactive routing protocols, making it easy to update a changing or outdated route.
  • the routing protocol preferably AODV or DSR
  • the routing protocol is expanded in such a way that when it receives the extended SD-REQ and SD-REP messages it updates the local routing tables accordingly with the route information.
  • FIG. 1 Ad hoc network in which a client sends a service request message in the form of a multicast message
  • FIG. 2 Ad hoc network from FIG. 1, in which two servers send a route search message to the client, likewise in the form of a multicast message in each case;
  • FIG. 3 ad hoc network from FIGS. 1 and 2, in which the client sends a response to the route search message back to the servers;
  • Figure 4 Ad hoc network from Figures 1 to 3, in which the server offer the desired service to the client;
  • FIG. 5 ad hoc network in which a client sends a service request message in the form of a special multicast message
  • FIG. 6 Ad hoc network of Figure 5, in which two servers offer the desired service to the client.
  • FIGS. 1 to 4 show the known method for establishing a connection between a service requester (client) 1 and a service provider (server) 3 in an ad hoc network 8.
  • the ad hoc network 8 consists of a service requester (client) 1 who wants to call up a specific service from the network 8.
  • stations 2 in this ad hoc network 8 which can also be mobile and can offer various services. All stations of the ad hoc network 8 are routers and can create connections to other stations of the ad hoc network 8 via the routing protocol used.
  • the two special stations, which offer the desired service of the service requester (client) 1 have been given the reference symbol 3. These are then called service providers (servers) 3.
  • the figures show:
  • Figure 1 shows how the service requester (client) 1, which, going on a desired service, for example weather information in a certain area, for mastery / Er Weg • the service. Since the service requester (client) 1 is generally not aware of the server address / IP address of the service provider (server) 3 that can provide the weather data, the service requester (client) 1 becomes a service request message, or also with Service discovery Send request 4, send it to the ad hoc network 8.
  • the service discovery request 4 (dotted arrows) is usually sent by the service requester (client) 1 as a multicast or broadcast message to geographically adjacent stations 2. This multicast or broadcast message is forwarded by the stations 2 to their neighboring stations 2 until they ultimately also reach the right service provider (s) 3.
  • the distribution of all the messages mentioned here and in particular the “flooding” of the ad hoc network 8 with these messages is referred to as signaling overhead.
  • the two service providers (server) 3 only receive the service request message or the service discovery request 4 of the service requester (client) 1.
  • the way or the path on which this service discovery request 4 came from the service requester (client) 1 to the service provider (server) 3 cannot be traced under service discovery (service / provider search service).
  • FIG. 2 now shows how the two service providers (servers) 3 locate the service requester (client) 1.
  • the two service providers (servers) 3 send in the form of a multicast message a route search message, or designated route request 5, to their locally neighboring stations 2.
  • the route request 5 is similar to the service discovery request 4 from
  • Service requester (client) 1 from FIG. 1 forwarded from station 2 to station 2 and finally to service requester (client) 1.
  • the route or path of the sender ie the two service providers (servers) 3 is identified in route request 5.
  • stations 2 can adapt their routing tables. This "path marking" is indicated by the dotted circles of the stations 2.
  • This method step in which the service provider (server) 3 searches for the route to the service requester (client) 1, also results in a Flooding the network, assuming that a route to station 1 of the service requester (clients) is still unknown.
  • FIG. 3 shows how the service requester (client) 1 answers the route search message Route Request 5 from the two service providers (servers) 3.
  • the service requester (client) 1 can now understand in which ways / routes the route request 5 of the two service providers (servers) 3 reached him.
  • the service requester (client) 1 sends a "Route Reply 6" response to each route search message from the two service providers (servers) 3, for example on the route / path that the associated route search message had taken.
  • This route reply reply 6 is symbolized by a solid arrow in order to indicate that the route / path is known.
  • FIG. 4 shows how the two service providers (servers) 3 transmit their service description in the form of a service discovery reply 7 to the service requester (client) 1 in the form of a service discovery.
  • the service requester (client) 1 can now choose, for example, which service provider (server) 3 he uses.
  • FIGS. 1 to 4 clearly shows how complex the localization in the ad hoc network 8 is.
  • Figures 1 and 2 in particular show the effect of the signaling overhead.
  • the "flooding" of the ad hoc network 8 with too many messages should be avoided.
  • a new method for establishing the connection between a service requester (client) and a service provider (server) is described in FIGS. 5 and 6, which at least reduces the signaling overhead.
  • FIG. 5 shows the same ad hoc network 8 as in FIGS. 1 to 4.
  • the service requester (client) 1 sends a service provider (service provider) ver) 3, which offers a desired service, visits a multicast message to locally neighboring stations 2.
  • this multicast message consists of a service request message, also called service discovery request 4a, in which information elements of the route request are integrated are.
  • the routing tables are adapted by the extended routing protocol when this multicast message is forwarded from station 2 to neighboring station 2.
  • the path / path to the service requester (client) 1 can be traced. This "path marking / path marking" is indicated by the dotted circles of the stations 2.
  • stations 1 and 3 i.e. the service requester (client) and the two service providers (server), are also routers at the same time. This means that they also generate, send and receive and process messages of the routing protocol and behave according to the rules of the routing protocol. In particular, they also have routing tables. For this reason, stations 1 and 3 in FIGS. 5 and 6 are represented by circles with a dotted line.
  • FIG. 6 shows how the two service providers (servers) 3 use the now known path / path to describe their service in the form of a service discovery reply 7a
  • Submit service requester (client) 1 In contrast to FIG. 4, this message consists of a reply message, also called service discovery reply 7a, in which all information elements of the route reply are integrated. Through the integrated routing message, these are forwarded
  • the service requester (client) 1 can now choose, for example, which service provider ter (server) 3 it uses and, for example, establishes a data connection to one of the two without having to search further.
  • the advantage of this new method is that the signaling overhead that is required when sending route search messages from the service provider (server) 3 to the service requester (client) 1 in the form of multicast messages, as shown in FIG. 2, can be eliminated.
  • a new method for establishing a connection between a service requester (client) and a service provider (server) in a decentralized mobile radio network preferably in an ad hoc mobile radio network or a mobile radio network using ad hoc network protocols, with service / Service Discovery service, which uses fewer multicast messages and thus minimizes the problem of signaling overhead.

Abstract

La présente invention concerne un procédé pour établir une liaison entre un demandeur de service (client) (1) et un prestataire de services (serveur) (3) dans un réseau de communication mobile décentralisé (8) comprenant des services de recherche de services/de prestataire de services (Service Discovery). Selon l'invention, le demandeur de service (client), pour localiser un prestataire de services inconnu (serveur) (3) qui met à disposition le service souhaité, envoie un message de demande de service (Service Discovery Request = SD-REQ) (4) sous la forme d'un message de multidiffusion, à des stations locales voisines (2) du réseau de communication mobile décentralisé (8), qui sont des routeurs IP, et ces stations (2) transmettent à leur tour le message de multidiffusion à leurs stations voisines (2), et finalement à un prestataire de services (serveur) (3) qui répond avec un message de réponse (Service Discovery Reply = SD-REP) (7). Le procédé se caractérise en ce que les informations de trajectoire relatives au message de demande de service et au message de réponse, sont ajoutées aux tables de routage des stations (2) pour permettre à la trajectoire de retour vers le demandeur de service (client) (1) d'être suivie.
EP04803179A 2003-11-24 2004-11-18 Procede pour etablir une liaison entre un demandeur de service (client) et un prestataire de services (serveur) dans un reseau de communication mobile decentralise Withdrawn EP1719303A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10354877A DE10354877B4 (de) 2003-11-24 2003-11-24 Verfahren zur Herstellung einer Verbindung zwischen einem Dienstanforderer (Client) und einem Dienstanbieter (Server) in einem dezentralen Mobilfunknetz
PCT/EP2004/013125 WO2005055529A1 (fr) 2003-11-24 2004-11-18 Procede pour etablir une liaison entre un demandeur de service (client) et un prestataire de services (serveur) dans un reseau de communication mobile decentralise

Publications (1)

Publication Number Publication Date
EP1719303A1 true EP1719303A1 (fr) 2006-11-08

Family

ID=34625210

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04803179A Withdrawn EP1719303A1 (fr) 2003-11-24 2004-11-18 Procede pour etablir une liaison entre un demandeur de service (client) et un prestataire de services (serveur) dans un reseau de communication mobile decentralise

Country Status (6)

Country Link
US (1) US20070147313A1 (fr)
EP (1) EP1719303A1 (fr)
JP (1) JP2007515871A (fr)
CN (1) CN1886945B (fr)
DE (1) DE10354877B4 (fr)
WO (1) WO2005055529A1 (fr)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8085672B2 (en) * 2005-01-28 2011-12-27 Honeywell International Inc. Wireless routing implementation
KR100664953B1 (ko) 2005-10-04 2007-01-04 삼성전자주식회사 모바일 애드 혹 네트워크 환경에서의 멀티캐스트 라우팅방법
US7613426B2 (en) * 2005-12-20 2009-11-03 Microsoft Corporation Proximity service discovery in wireless networks
US8478300B2 (en) * 2005-12-20 2013-07-02 Microsoft Corporation Proximity service discovery in wireless networks
US8559350B2 (en) * 2005-12-20 2013-10-15 Microsoft Corporation Mechanism to convey discovery information in a wireless network
US10681151B2 (en) 2006-05-15 2020-06-09 Microsoft Technology Licensing, Llc Notification framework for wireless networks
US20070264991A1 (en) * 2006-05-15 2007-11-15 Microsoft Corporation Services near me: discovering and connecting to available wireless services utilizing proximity discovery
US7974574B2 (en) * 2007-07-25 2011-07-05 Microsoft Corporation Base station initiated proximity service discovery and connection establishment
US8681691B2 (en) 2007-07-25 2014-03-25 Microsoft Corporation Base station initiated proximity service discovery and connection establishment
CN101159688B (zh) * 2007-11-08 2010-06-23 华为技术有限公司 组播路由跟踪的方法和路由器
US9105031B2 (en) * 2008-02-22 2015-08-11 Microsoft Technology Licensing, Llc Authentication mechanisms for wireless networks
US20090276520A1 (en) * 2008-05-05 2009-11-05 Lockheed Martin Corporation Method and apparatus for server election, discovery and selection in mobile ad hoc networks
US9246939B2 (en) * 2011-06-21 2016-01-26 Telefonaktiebolaget L M Ericsson (Publ) Preventing neighbor-discovery based denial of service attacks
EP2813057B1 (fr) * 2012-02-08 2020-09-16 Marvell Asia Pte, Ltd. Procédé et appareil pour rechercher des dispositifs sans fil
EP2797267B1 (fr) * 2013-04-26 2016-07-27 Airbus Defence and Space Limited Acheminement de données dans un réseau de communications
JP5770256B2 (ja) * 2013-12-12 2015-08-26 インテル・コーポレーション 群知能を利用する大規模分散型システムにおける情報ルーティングのために枠組みを利用するシステムおよび方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6101528A (en) * 1996-03-27 2000-08-08 Intel Corporation Method and apparatus for discovering server applications by a client application in a network of computer systems
US8126982B2 (en) * 2001-02-16 2012-02-28 International Business Machines Corporation Method, network device and computer program product for performing service discovery in a pervasive network
DE10143228B4 (de) 2001-09-04 2006-05-18 Siemens Ag Verfahren zum Routen von Verbindungen in einem funkgestützen Ad-hoc-Netz und Netzstation zum Durchführen eines solchen Verfahrens
US8351339B2 (en) * 2002-04-25 2013-01-08 Samsung Electronics Co., Ltd. Method for bluetooth on-demand routing and network formation, and communication method in bluetooth group ad hoc network
US7415019B2 (en) * 2003-08-22 2008-08-19 Samsung Electronics Co., Ltd. Apparatus and method for collecting active route topology information in a mobile ad hoc network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005055529A1 *

Also Published As

Publication number Publication date
WO2005055529A1 (fr) 2005-06-16
JP2007515871A (ja) 2007-06-14
CN1886945A (zh) 2006-12-27
DE10354877A1 (de) 2005-06-30
CN1886945B (zh) 2011-08-03
DE10354877B4 (de) 2005-12-01
US20070147313A1 (en) 2007-06-28

Similar Documents

Publication Publication Date Title
EP1465443B1 (fr) Procédé et appareil pour traiter des services positionnels
DE69936925T2 (de) Verfahren und vorrichtung zur übertragung von datenpaketen von einem externen paketnetz zu einer mobilen funkstation
DE10085302B3 (de) Mobile-IP für Mobil-Ad-Hoc-Netze
DE60207100T2 (de) Geheimhalten des aufenthaltsortes in kommunikationsnetzwerken
DE69735227T2 (de) Lokalisierungsmanagement von Mobileinheiten in ATM-Netzwerken
DE60221228T2 (de) Verfahren und system zur anycast-wegleitung zwischen mehreren wirtsrechnern
DE69923034T2 (de) Mobilkommunikationssystem zur Bereitstellung eines IP-Paketkommunikationsdienstes und Vorrichtung zur Leitweglenkung von IP-Paketen
DE10354877B4 (de) Verfahren zur Herstellung einer Verbindung zwischen einem Dienstanforderer (Client) und einem Dienstanbieter (Server) in einem dezentralen Mobilfunknetz
DE60215005T2 (de) Dynamisches Netzwerk und Wegeleitverfahren für ein dynamisches Netzwerk
DE60216862T2 (de) System und Verfahren zum mikromobilitätsbasierten Netz-Routing
DE60028254T2 (de) Steuerungsgerät und -verfahren für paketbasierte kommunikation
EP2135404B1 (fr) Procédé d'exploitation d'un réseau de type maillé, notamment selon la norme ieee 802.11s, constitué d'une pluralité de noeuds de réseau
EP2274935B1 (fr) Procédé et dispositif de production d'au moins une extension d'un message d'attribution pour des réseaux maillés sans fil
EP2005700B1 (fr) Procédé de détermination d'une autorisation de tâche
DE112005003332T5 (de) Multicast-Architektur für drahtlose Maschennetze
DE60037914T2 (de) Multicasting von Daten in einem mobilen IP-Kommunikationsnetz
DE602005000724T2 (de) Wegleitung in einem Kommunikationsnetzwerk
DE60126725T2 (de) Adressierungsverfahren in einem Satelliten Zugriff- oder Infrastruktur- netzwerk für Datenübertragung in einem nicht geschaltetem Modus
EP1117083B1 (fr) Procédé pour la transmission décentralisée et la distribution de données utiles entre les utilisateurs d'un réseau de télécommunications
DE60311547T2 (de) Hierarchisches Paketfunkkommunikationsnetz und Kommunikationsverfahren dafür
DE10046343B4 (de) Verfahren zum Registrieren eines Endgerätes in einem Paketdatennetzwerk
DE10064107A1 (de) Verfahren zum Verteilen einer Gruppennachricht in einem Funkkommunikationssystem sowie zugehöriges Funkkommunikationssystem
DE10047131B4 (de) Verfahren zum Betreiben eines Zugangsnetzes
EP1994676B1 (fr) Procédé de création d'un champ d'adresse, procédé et dispositif de transmission d'un message électronique et paquet de données
DE102020123413B4 (de) Verfahren zur Datenübertragung in einem Ad-hoc-Netzwerk

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060412

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB IT SE

17Q First examination report despatched

Effective date: 20061110

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB IT SE

APBK Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOSNREFNE

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS ENTERPRISE COMMUNICATIONS GMBH & CO. KG

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20120503