(57)【要約】  本発明は、サービス／サービス提供側探索サービスを用いて分散型の移動無線網においてサービス要求側（１）とサービス提供側（３）との間にコネクションを確立する方法に関する。この方法においてはサービス要求側が所望のサービスを提供する未知のサービス提供側（３）の位置特定のためにサービス要求メッセージ（４）をマルチキャストメッセージとして分散型の移動無線網の局所的に隣接しているＩＰルータである局（２）に送信し、この局が再びマルチキャストメッセージをこの局に隣接する局（２）に送信し、最終的にサービス提供側（３）に転送し、このサービス提供側（３）が応答メッセージ（７）でもって応答する。この方法は、サービス要求側（１）までの経路を追従するために局（２）のルーティングテーブルにサービス要求メッセージの経路情報およびこのサービス要求メッセージに対する応答メッセージの経路情報を付加することを特徴とする。
2007515871.tif 000002
【特許請求の範囲】
【請求項１】
サービス／サービス提供側探索（サービス発見）サービスを用いて分散型の移動無線網（８）においてサービス要求側（クライアント）（１）とサービス提供側（サーバ）（３）との間にコネクションを確立する方法であって、
前記サービス要求側（クライアント）が所望のサービスを提供する未知のサービス提供側（サーバ）（３）の位置特定のためにサービス要求メッセージ（サービス発見要求＝ＳＤ−ＲＥＱ）（４）をマルチキャストメッセージとして前記分散型の移動無線網（８）の局所的に隣接しているＩＰルータである局（２）に送信し、該局（２）が再び前記マルチキャストメッセージを該局に隣接する局（２）に送信し、最終的に前記サービス提供側（サーバ）（３）に転送し、該サービス提供側（サーバ）（３）が応答メッセージ（サービス発見応答＝ＳＥ−ＲＥＰ）（７）でもって応答する方法において
前記サービス要求側（クライアント）（１）までの経路を追従するために前記局（２）のルーティングテーブルに前記サービス要求メッセージの経路情報および該サービス要求メッセージに対する応答メッセージの経路情報を付加することを特徴とする、方法。
【請求項２】
少なくとも１つの前記サービス要求側（クライアント）（１）の前記サービス要求メッセージ（ＳＤ−ＲＥＱ）（４）を少なくとも１つの前記サービス提供側（サーバ）（３）の探索メッセージ（ルート要求＝Ｒ−ＲＥＱ）（５）の要素について拡張する、請求項１記載の方法。
【請求項３】
少なくとも１つの前記サービス提供側（サーバ）の前記応答メッセージ（ＳＤ−ＲＥＰ）（７）を少なくとも１つの前記サービス要求側（クライアント）（１）の経路応答メッセージ（ルート応答＝Ｒ−ＲＥＰ）（６）の全ての要素について拡張する、請求項１または２記載の方法。
【請求項４】
経路探索プロトコルとして、前記サービス要求メッセージ（ＳＤ−ＲＥＱ）（４）および前記応答メッセージ（ＳＤ−ＲＥＰ）（７）に組み込まれる、好適にはＡＯＤＶプロトコルまたはＤＳＲプロトコルを使用する、請求項１から３までのいずれか１項記載の方法。
【請求項５】
前記ルーティングプロトコル、好適にはＡＯＤＶまたはＤＳＲを、拡張された前記ＳＤ−ＲＥＱメッセージ（４ａ）および前記ＳＤ−ＲＥＰメッセージ（７）の受信の際に局所的なルーティングテーブルを相応に経路情報を用いて更新するように拡張する、請求項１から４までのいずれか１項記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス／サービス提供側探索（サービス発見；Service Discovery）サービスを用いて分散型の移動無線網においてサービス要求側（クライアント）とサービス提供側（サーバ）との間にコネクションを確立する方法に関し、この方法においてはサービス要求側（クライアント）が所望のサービスを提供する未知のサービス提供側（サーバ）の位置特定のためにサービス要求メッセージ（サービス発見要求；Service Discovery Request＝ＳＤ−ＲＥＱ）をマルチキャストメッセージとして分散型の移動無線網の局所的に隣接しているＩＰルータである局に送信し、この局が再びマルチキャストメッセージをこの局に隣接する局に送信し、最終的にサービス提供側（サーバ）に転送し、このサービス提供側（サーバ）が応答メッセージ（サービス発見応答；Service Discovery Reply＝ＳＥ−ＲＥＰ）でもって応答する。
【０００２】
将来的な公衆の広帯域の無線網においては、アドホックネットワーク（有利には移動局を備えた分散型のネットワーク）のルーティングメカニズム（経路探索メカニズム）が使用される。アドホックルーティングプロトコルはＩＰ（インターネットプロトコル）パケット交換を基礎としており、また無線網内においてデータフローのソースノードからデスティネーションノードまでの経路を発見するタスクを有する。直接的なコネクションが存在しない場合には、タスクはＩＰパケットの伝送を実現するルータのセットを選択することができる。ルータは受信したＩＰパケットをそれぞれ次のルータまたは目的の局に転送する。
【０００３】
アドホックネットワークに関して種々のルーティングプロトコルが存在する。経路探索のタスクは種々のやり方で、例えばＡＯＤＶ（アドホックのオンデマンドで距離ベクトル型のルーティングプロトコル；Ad hoc On Demand Distance Vector Routing Protocol）、ＤＳＲ（モバイルアドホックネットワーク用の動的なソースルーティングプロトコル；Dynamic Source Routing Protocol for Mobile Ad Hoc Networks）、ＤＳＤＶ（モバイルコンピュータ用の宛先シーケンスの距離ベクトル型のプロトコル；Destination-Sequence Distance-Vector for mobile Computers Protocol）を用いて解決される。以下では例えばＡＯＤＶプロトコルを考察する。
【０００４】
前述の全てのルーティングプロトコルは、経路探索を開始するために受信局のＩＰアドレスを入力パラメータとして使用する点で共通している。ルーティングプロトコルはこの情報に基づいてネットワークを通っている好適な経路を探索する。ルーティングプロトコルのメッセージのシグナリングは、局の可動性が増した際には大抵の場合いわゆるシグナリングオーバヘッド（遠距離通信の「足枷」）をもたらす。ＡＯＤＶのような応答型のルーティングプロトコルにおいては、ルートが未知であるか古くなっている場合「ルート要求（Ｒ−ＲＥＱ）」メッセージが無線ネットワーク全体にわたってマルチキャストされる。
【０００５】
宛先局のアドレスが差し当たり未知である、すなわちルーティングに関する入力情報が欠如している種々の適用事例が存在する。このことは例えば、モバイルのエンドカスタマがコンピュータ名またはＩＰアドレスを知らずとも、所定のサービスを提供する局とコンタクトを取ろうとする場合である。これに関する例として場所に関する情報の照会、局所的な天気情報の照会、または近くのＡＴＭの位置の照会などがある。
【０００６】
サービス提供側の探索（サービス発見）を中央において「ディレクトリサービス」を用いて行うことができるか、分散的に行うことができる。分散的な場合、サービス要求側（クライアント）は選択した範囲内の全ての局に「サービス発見要求（ＳＤ−ＲＥＱ）」メッセージを送信する。相応のサービスを提供する局（サーバ）がこのメッセージに応答する。ここでは応答を「サービス発見応答（ＳＤ−ＲＥＰ）」メッセージと称する。ＳＤ−ＲＥＱメッセージは地理的な範囲内の全ての局に到達するマルチキャストメッセージである。アドホックネットワークの各局はマルチキャストメッセージを隣接する局に転送する。サーバ局はＳＤ−ＲＥＰメッセージ内の要求されたサービスの詳細な記述でもって応答する。
【０００７】
有利にはサーバの応答は「サービス発見」メッセージが直前に通った経路を取る。ルーティングプロトコルＡＯＤＶにおいては原則として相応の動作が存在するが、これはＳＤ−ＲＥＱメッセージおよびＳＤ−ＲＥＰメッセージにおいては存在しない。ルータ内のルーティングテーブルはＡＯＤＶプロトコルを使用する場合にのみ適合されるが、サービス発見プロトコルのメッセージを転送する場合には適合されないので、目下のところ相応の局間のルートをサービス発見後に発見する必要がある。
【０００８】
以下のシーケンスはアドホックルーティングプロトコルのこの種の定義において遵守されなければならない：
−クライアントはＳＤ−ＲＥＱメッセージをマルチキャストする。
−サービスを提供する各サーバにおいて、サービス要求側への経路探索が開始される。すなわち各サーバはクライアントへのルートを形成するためにＲ−ＲＥＱメッセージをマルチキャストする。
−クライアントはその都度Ｒ−ＲＥＰでもって応答する。
−ここでサーバとクライアントには間のパスが存在するので、サーバはＳＤ−ＲＥＰでもって応答することができる。
−クライアントは必要に応じてサーバを選択して、そのサーバとのコネクションを確立することができ、要求したサービスを使用するか、さらなる情報を得る。
【０００９】
サービス発見においてマルチキャストメッセージを回避するための別の解決手段は、サーバがそのサービスを中央サーバに記録することである。この場合クライアントは先ずこの中央サーバにコンタクトを取り、探しているサービスを提供するサーバのＩＰアドレスを検出する。クライアントがサーバを発見すると、クライアントはこのサーバのＩＰアドレスも知るので、サーバへの経路を検出するために通常のＲ−ＲＥＱを送信することができる。
【００１０】
この第２の解決手段の欠点は、１つまたは複数のサーバデータバンクを準備しなければならないことである。これらの局のアドレスを何らかの方法で知らせなければならない。さらにはそれにもかかわらず、クライアント局はサーバデータバンクへのルート、また必要に応じてサーバへのルートを検出するためにマルチキャストメッセージをマルチキャストしなければならない。
【００１１】
したがって本発明の課題は、シグナリングオーバヘッドの問題を最小限にする、サービス／サービス提供側探索（サービス発見）サービスを用いて、分散型の移動無線網においてサービス要求側（クライアント）とサービス提供側（サーバ）との間にコネクションを確立する方法を提供することである。
【００１２】
本発明のこの課題は請求項１の特徴を備えた方法によって解決される。本発明の有利な実施形態は従属請求項に記載されている。
【００１３】
本発明者は、サービス要求側（クライアント）から送信されるマルチキャストメッセージ、サービス提供側（サーバ）を探索する際に使用されるルータ内のルーティングテーブルにもサービス要求側までの経路情報が設けられる場合にはシグナリングオーバヘッドを最小にできることを発見した。
【００１４】
この本発明の着想に従い本発明者は、サービス／サービス提供側探索（サービス発見）サービスを用いて分散型の移動無線網においてサービス要求側（クライアント）とサービス提供側（サーバ）との間にコネクションを確立する方法を提案し、この方法においてはサービス要求側（クライアント）が所望のサービスを提供する未知のサービス提供側（サーバ）の位置特定のためにサービス要求メッセージ（サービス発見要求＝ＳＤ−ＲＥＱ）をマルチキャストメッセージとして分散型の移動無線網の局所的に隣接しているＩＰルータである局に送信し、この局が再びマルチキャストメッセージをこの局に隣接する局に送信し、最終的にサービス提供側（サーバ）に転送し、このサービス提供側（サーバ）が応答メッセージ（サービス発見応答＝ＳＥ−ＲＥＰ）でもって応答するが、サービス要求側（クライアント）までの経路を遡って追従するために局のルーティングテーブルにはサービス要求側メッセージの経路情報およびその応答メッセージが付加されるよう改善されている。
【００１５】
これによって、これまでサービス提供側によって必要とされた経路探索照会（ルート要求＝Ｒ−ＲＥＱ）を回避することができるので、移動無線網におけるシグナリングオーバヘッドは著しく低減される。
【００１６】
本方法の有利な実施形態においては、少なくとも１つのサービス要求側（クライアント）のサービス要求メッセージ（サービス発見要求＝ＳＤ−ＲＥＱ）を少なくとも１つサービス提供側（サーバ）の探索メッセージ（ルート要求＝Ｒ−ＲＥＱ）の要素について拡張することができる。
【００１７】
このことはＡＯＤＶプロトコルのＲ−ＲＥＱの場合には、未知の宛先アドレスに該当するもの以外の全ての要素、すなわち「Ｄ」、「Ｇ」、「宛先ＩＰアドレス」および「宛先シーケンス番号」である。
【００１８】
さらに有利な実施形態においては、少なくとも１つのサービス提供側（サーバ）の応答メッセージ（サービス発見応答＝ＳＤ−ＲＥＰ）を少なくとも１つサービス要求側（クライアント）の経路応答メッセージ（ルート応答＝Ｒ−ＲＥＰ）の全ての要素について拡張することができる。
【００１９】
ＡＯＤＶプロトコルの場合には、付加的な情報要素に基づいて、これらのＳＤ−ＲＥＱメッセージおよびＳＤ−ＲＥＰメッセージを受信する各局が自身の内部のルーティングテーブルを更新することができるので、２回目の明示的な経路探索を省略することができる。
【００２０】
経路探索プロトコルとして、サービス要求メッセージ（サービス発見要求）および応答メッセージ（ＳＤ−ＲＥＰ）に組み込まれる、好適にはＡＯＤＶプロトコルまたはＤＳＲプロトコルが使用される場合には有利である。
【００２１】
これらの経路探索プロトコルは応答型のルーティングプロトコルに属し、これによって変化したルートまたは古くなったルートを容易に更新することができる。
【００２２】
これに択一的に、拡張されたＳＤ−ＲＥＱメッセージおよびＳＤ−ＲＥＰメッセージを受信した際に局所的なルーティングテーブルを相応に経路情報を用いて更新するようにルーティングプロトコル、有利にはＡＯＤＶまたはＤＳＲが拡張される場合には有利である。
【００２３】
以下では図１から図６を用いて有利な実施例に基づき本発明を説明する。ここで図面においては以下の参照番号が使用されている。１：サービス要求側（クライアント）／サービス要求側（クライアント）の局；２：別の局；３：サービス提供側（サーバ）／サービス提供側（サーバ）の局；４：サービス発見要求；４ａ：ルーティング情報要素が組み込まれているサービス発見要求；５：ルート要求；６：ルート応答；７：サービス発見応答；７ａ：ルーティング情報要素が組み込まれているサービス発見応答；８：アドホックネットワーク。
【００２４】
個々の図面において：
図１はクライアントがサービス要求メッセージをマルチキャストメッセージとして送信しているアドホックネットワークを示し、
図２は２つのサーバがクライアントに経路検索メッセージを同様にそれぞれマルチキャストメッセージとして送信している図１によるアドホックネットワークを示し、
図３はクライアントが経路探索メッセージに対する応答をサーバに送り返している図１および図２によるアドホックネットワークを示し、
図４はサーバが所望のサービスをクライアントに提供している図１から図３によるアドホックネットワークを示し、
図５はクライアントがサービス要求メッセージを特別なマルチキャストメッセージとして送信しているアドホックネットワークを示し、
図６は２つのサーバが所望のサービスをクライアントに提供している図５によるアドホックネットワークを示す。
【００２５】
図１から図４には、アドホックネットワーク８においてサービス要求側（クライアント）１とサービス提供側（サーバ）３との間にコネクションを確立するための公知の方法が示されている。明瞭にするために、種々のステップを図１から図４に別個に示している。図示されている実施形態においてアドホックネットワーク８は、所定のサービスをネットワーク８から呼び出そうとするサービス要求側（クライアント）１から構成されている。さらにこのアドホックネットワーク８には複数の局２が設けられており、これらの局２はまたモバイル局であってもよく、また種々のサービスを提供することができる。アドホックネットワーク８の全ての局はルータであり、使用されるルーティングプロトコルを介してアドホックネットワーク８の他の局とのコネクションを確立することができる。サービス要求側（クライアント）１の所望のサービスを提供する２つの特別な局を参照番号３で示した。これらの２つの特別な局をサービス提供側（サーバ）３と称する。これらの図面には以下のことが示されている。
【００２６】
図１は所望のサービス、例えば所定の地域の天気データを要求するサービス要求側（クライアント）１がどのようにしてサービスを獲得／取得するかを示す。通常の場合、サービス要求側（クライアント）１には天気データを供給することができるサービス提供側（サーバ）３のサーバアドレス／ＩＰアドレスが既知ではないので、サービス要求側（クライアント）１はサービス発見要求４とも称されるサービス要求メッセージをアドホックネットワーク８に発信する。サービス発見要求４（点線の矢印）はサービス要求側（クライアント）１から通常の場合マルチキャストメッセージまたはブロードキャストメッセージとして地理的に隣接する局２に送信される。このマルチキャストメッセージまたはブロードキャストメッセージは局２からこの局に隣接する局２に転送され、この転送は最終的に１つまたは複数の適切なサービス提供側（サーバ）３に到達するまで行われる。ここに挙げた全てのメッセージの配布、殊にこれらのメッセージによるアドホックネットワーク８の「フラッディング」はシグナリングオーバヘッドと称される。２つのサービス提供側（サーバ）３にはサービス要求側（クライアント）１のサービス要求メッセージないしサービス発見要求４が到達するだけである。サービス要求側（クライアント）１からサービス提供側（サーバ）３までのサービス発見要求４が通った経路またはパスをサービス発見（サービス／サービス提供側検索サービス）では追従することができない。
【００２７】
図２はどのようにして２つのサービス提供側（サーバ）３がサービス要求側（クライアント）１の位置特定を行うかを示す。２つのサービス提供側（サーバ）３はマルチキャストメッセージとしてルート要求５とも称する経路探索メッセージをこれらのサービス提供側３に局所的に隣接する局２に送信する。ルート要求５は図１によるサービス要求側（クライアント）１からのサービス発見要求４と同様に局２から局２へと転送され、最終的にはサービス要求側（クライアント１）に転送される。しかしながらサービス発見要求４との相違は、このルート要求５においては送信側、すなわち２つのサービス提供側（サーバ）３の経路またはパスが知らされる点にある。つまりＡＯＤＶプロトコルのルート要求メッセージ５を受信すると、局２は自身のルーティングテーブルを適合させることができる。この「経路マーキング」は局２の点線の円によって示唆されている。サービス提供側（サーバ）３がサービス要求側（クライアント）１までの経路を検索するこのステップにおいても、サービス要求側（クライアント）の局１までのルートが依然として未知であることが想定されるので、ネットワークのフロッディングが生じる。
【００２８】
図３には、どのようにしてサービス要求側（クライアント）１が２つのサービス提供側（サーバ）３の経路探索メッセージ、ルート要求５に応答するかが示されている。ここではサービス要求側（クライアント）１は、どの経路／パスで２つのサービス提供側（サーバ）３のルート要求５がサービス要求側（クライアント）１に到達したかを追従することができる。サービス要求側（クライアント）１は２つのサービス提供側（サーバ）３の各経路探索メッセージに対する応答「ルート応答」６を、例えばそれぞれ対応する経路探索メッセージが取った経路／パスにおいて送信する。この応答、ルート応答６は経路／パスが既知であることを示すために実線の矢印で表されている。
【００２９】
図４には、どのようにして２つのサービス提供側（サーバ）３が所定の経路／パスにおいて、サービス発見応答７としてのサービス提供側（サーバ）のサービス記述をサービス要求側（クライアント）１に伝送するかを示している。ここでサービス要求側（クライアント）１は例えば、どちらのサービス提供側（サーバ）３を使用するかを選択することができる。
【００３０】
図１から４に基づき説明した方法はアドホックネットワーク８における位置特定が如何に煩雑であるかを明らかにしている。殊に、図１および図２はシグナリングオーバヘッドの作用を示している。しかしながら多数のメッセージによるアドホックネットワーク８のフロッディングはまさに回避されるべきものである。このために図５および図６においては、シグナリングオーバヘッドを少なくとも低減する、サービス要求側（クライアント）とサービス提供側（サーバ）との間にコネクションを確立するための新たな方法が示されている。
【００３１】
図５は図１から図４に示されているものと同じアドホックネットワーク８を示す。図１と同様に、所望のサービスを提供する未知のサービス提供側（サーバ）３を探すデータ要求側（クライアント）１がマルチキャストメッセージを隣接する局２に送信する。図１との相違は、このマルチキャストメッセージが、ルート要求の情報要素が組み込まれているサービス発見要求４ａとも称するサービス要求メッセージから構成されている点にある。情報要素が組み込まれたルーティングメッセージによって、このマルチキャストメッセージを局２から隣接する局２へと転送する際にはルーティングテーブルが拡張されたルーティングプロトコルによって適合される。ルーティングテーブルを適合することによって、サービス要求側（クライアント）１への経路／パスをさかのぼって追従することができる。この「経路マーキング／パスマーキング」は局２の点線の円によって示唆されている。ここで局１および局３、すなわちデータ要求側（クライアント）と２つのサービス提供側（サーバ）は同時にルータであってもよいことを言及しておく。すなわち、これらのデータ要求側（クライアント）とデータ提供側（サーバ）もルーティングプロトコルのメッセージを形成、送受信および処理し、ルーティングテーブルの規則に従い動作する。殊にこれらのデータ要求側（クライアント）およびデータ提供側（サーバ）はルーティングテーブルも有する。この理由から、局１および局３も図５および図６においては点線の円によって表されている。
【００３２】
図６には、どのようにして２つのサービス提供側（サーバ）３がここでは既知となっている経路／パスにおいてこのサービス提供側（サーバ）３のサービス記述をサービス発見応答７ａとしてサービス要求側（クライアント）１に伝送するかを示している。図４との相違はこのメッセージがルート応答の全ての情報要素が組み込まれているサービス発見応答７ａとも称する応答メッセージから構成されていることである。全ての情報要素が組み込まれたルーティングメッセージによって、このメッセージを局２から隣接する局２に転送する際にルーティングテーブルは拡張されたルーティングプロトコルによって適合される。ルーティングテーブルの適合によって、サービス提供側（サーバ）３までの経路／パスをさかのぼって追従することができる。この「経路マーキング／パスマーキング」は局２の点線の円によって示唆されている。サービス要求側（クライアント）１は例えば、どちらのサービス提供側（サーバ）３を使用するかを選択することができ、またこれらのサービス提供側のうちの一方とのデータコネクションをさらなる経路探索を行うことなく確立することができる。
【００３３】
この新たな方法は、図２に示されているように、サービス提供側（サーバ）３からサービス要求側（クライアント）１へと経路探索メッセージをマルチキャストメッセージとして送信する際のシグナリングオーバヘッドを回避することができるという利点を有する。
【００３４】
総じて、より少ないマルチキャストメッセージしか必要とされず、したがってシグナリングオーバヘッドの問題を最小限にする、サービス／サービス提供側検索（サービス発見）サービスを用いて、分散型の移動無線網において、有利にはアドホック移動無線網または応答型のアドホックネットワークプロトコルを使用する移動無線網において、サービス要求側（クライアント）とサービス提供側（サーバ）との間にコネクションを確立する新たな方法が提供される。
【００３５】
本発明の前述の特徴は、記述したそれぞれの組み合わせにのみ制限されるものではなく、本発明の範囲を逸脱することなく他の組み合わせまたは単独で使用できると解される。
【図面の簡単な説明】
【００３６】
【図１】クライアントがサービス要求メッセージをマルチキャストメッセージとして送信しているアドホックネットワーク。
【図２】２つのサーバがクライアントに経路検索メッセージを同様にそれぞれマルチキャストメッセージとして送信している図１によるアドホックネットワーク。
【図３】クライアントが経路探索メッセージに対する応答をサーバに送り返している図１および図２によるアドホックネットワーク。
【図４】サーバが所望のサービスをクライアントに提供している図１から図３によるアドホックネットワーク。
【図５】クライアントがサービス要求メッセージを特別なマルチキャストメッセージとして送信しているアドホックネットワーク。
【図６】２つのサーバが所望のサービスをクライアントに提供している図５によるアドホックネットワーク。
【図１】
2007515871.tif 000003
【図２】
2007515871.tif 000004
【図３】
2007515871.tif 000005
【図４】
2007515871.tif 000006
【図５】
2007515871.tif 000007
【図６】
2007515871.tif 000008
【国際調査報告】
2007515871.tif 000009
2007515871.tif 000010
2007515871.tif 000011
2007515871.tif 000012
2007515871.tif 000013
2007515871.tif 000014