JP4735202B2

JP4735202B2 - アドホックネットワークについてルーティングプロトコルを選択する携帯端末及びプログラム

Info

Publication number: JP4735202B2
Application number: JP2005330077A
Authority: JP
Inventors: 健久保; 英俊横田; 彰井戸上
Original assignee: KDDI Corp
Current assignee: KDDI Corp
Priority date: 2005-11-15
Filing date: 2005-11-15
Publication date: 2011-07-27
Anticipated expiration: 2025-11-15
Also published as: JP2007142543A

Description

本発明は、アドホックネットワークについてルーティングプロトコルを選択する携帯端末及びプログラムに関する。

アドホックネットワークは、複数の端末間でバケツリレー式にパケットを転送する「マルチホップ通信」によって実現され、無線ＬＡＮにおける「アドホックモード」等、端末同士が直接的にパケットを送受信する機能によってサポートされる。通常、アドホックモードでは、端末同士１対１で通信する。どの端末がどのようにパケットを中継していくかを制御するための技術を、「アドホックルーティング」といい、これにより自端末に隣接した相手方端末のみならず、直接的には通信できない相手方端末と通信するためにどのような経路（中継端末）を経由するかを決定することができる。

アドホックルーティングプロトコルとしては、「リアクティブ型」と「プロアクティブ型」とがある（例えば非特許文献１及び２参照）。「リアクティブ型」は、端末が通信を開始しようとした際に経路確立手順を起動し、通信のための経路を確保する。「プロアクティブ型」は、予めネットワーク内に存在する端末を把握し、経路情報を常に保持することによって直ちに通信を開始する。

RFC3561、「Ad hoc On-Demand Distance Vector (AODV) Routing」、[online]、July 2003、[平成17年10月4日検索]、インターネット<URL:http://www.faqs.org/rfcs/rfc3561.html> draft-ietf-manet-dsr-09.txt、「The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)」、[online]、5 April 2003、[平成17年10月4日検索]、インターネット<URL: http://www.ietf.org/proceedings/04mar/I-D/draft-ietf-manet-dsr-09.txt>

しかしながら、従来のアドホックルーティングプロトコルによれば、アドホックネットワークにおいて１つのプロトコルのみを用いることを前提としている。また、複数のアドホックルーティングプロトコルを有する携帯端末が、アドホックネットワーク内に存在していても、プロトコルに選択する方法はない。結局、携帯端末を所持する利用者が、そのアドホックネットワークにおいて使用するプロトコルを手動選択によって設定する必要がある。

従って、本発明は、複数のアドホックルーティングプロトコルを有する端末が複数存在するアドホックネットワークにおいて、プロトコルを選択するための携帯端末及びプログラムを提供することを目的とする。

本発明によれば、１つ以上のアドホックルーティングプロトコルを有する携帯端末であって、
１つ以上のアドホックルーティングプロトコルを有する携帯端末であって、
アドホックルーティングのプロトコル情報テーブルを記憶したプロトコル情報テーブル管理手段と、
相手方端末から、プロトコル情報を含むプロトコル広告パケットを受信し、該プロトコル広告パケットに含まれるプロトコル情報を、プロトコル情報テーブル管理手段のプロトコル情報テーブルに登録し、該プロトコル情報テーブルの中から所望プロトコル情報を選択するプロトコル広告受信手段と、
所望プロトコル情報に基づくプロトコルを起動するルーティングプロトコル起動手段と
を有することを特徴とする。

本発明の携帯端末における他の実施形態によれば、
プロトコル広告パケットは、ＩＣＭＰヘッダによって規定されており、
プロトコル情報毎に、プロトコル名、バージョン番号、ネットワーク名及び優先度又はいずれかを含むことも好ましい。

更に、本発明の携帯端末における他の実施形態によれば、
プロトコル情報テーブル管理手段は、当該携帯端末が利用可能なプロトコル情報に対して第１のフラグを「１」に設定し、
プロトコル広告受信手段は、プロトコル情報テーブルについて、第１のフラグが「１」に設定されたプロトコル情報から所望プロトコルを選択することも好ましい。

更に、本発明の携帯端末における他の実施形態によれば、
定期的に、又はプロトコル問い合わせパケットを受信した際に、プロトコル広告パケットを送信するプロトコル広告送信手段を更に有し、
プロトコル広告送信手段は、定期的にプロトコル広告パケットを送信する場合、プロトコル広告パケットには、プロトコル情報テーブルに登録された全てのプロトコル情報が格納され、又は、
プロトコル問い合わせパケットを受信した際にプロトコル広告パケットを送信する場合、プロトコル問い合わせパケットに含まれるプロトコル情報に適合するように選択されたプロトコル情報が格納される
ことも好ましい。

本発明によれば、１つ以上のアドホックルーティングプロトコルを有する携帯端末に搭載されたコンピュータを機能させるプログラムであって、
アドホックルーティングのプロトコル情報テーブルを記憶したプロトコル情報テーブル管理手段と、
相手方端末から、プロトコル情報を含むプロトコル広告パケットを受信し、該プロトコル広告パケットに含まれるプロトコル情報を、プロトコル情報テーブル管理手段のプロトコル情報テーブルに登録し、該プロトコル情報テーブルの中から所望プロトコル情報を選択するプロトコル広告受信手段と、
所望プロトコル情報に基づくプロトコルを起動するルーティングプロトコル起動手段と
してコンピュータを機能させることを特徴とする。

本発明のプログラムにおける他の実施形態によれば、
プロトコル広告パケットは、ＩＣＭＰヘッダによって規定されており、
プロトコル情報毎に、プロトコル名、バージョン番号、ネットワーク名及び優先度又はいずれかを含むようにコンピュータを機能させることも好ましい。

更に、本発明のプログラムにおける他の実施形態によれば、
プロトコル情報テーブル管理手段は、当該携帯端末が利用可能なプロトコル情報に対して第１のフラグを「１」に設定し、
プロトコル広告受信手段は、プロトコル情報テーブルについて、第１のフラグが「１」に設定されたプロトコル情報から所望プロトコルを選択するようにコンピュータを機能させることも好ましい。

更に、本発明のプログラムにおける他の実施形態によれば、
定期的に、又はプロトコル問い合わせパケットを受信した際に、プロトコル広告パケットを送信するプロトコル広告送信手段を更に有し、
プロトコル広告送信手段は、定期的にプロトコル広告パケットを送信する場合、プロトコル広告パケットには、プロトコル情報テーブルに登録された全てのプロトコル情報が格納され、又は、
プロトコル問い合わせパケットを受信した際にプロトコル広告パケットを送信する場合、プロトコル問い合わせパケットに含まれるプロトコル情報に適合するように選択されたプロトコル情報が格納される
ようにコンピュータを機能させることも好ましい。

本発明の携帯端末及びプログラムによれば、複数のアドホックルーティングプロトコルを有する端末が複数存在するアドホックネットワークにおいて、プロトコルを選択することができる。

以下では、図面を用いて、本発明を実施するための最良の形態について詳細に説明する。

図１は、本発明におけるシーケンス図である。

携帯端末Ａ、Ｂ及びＣは、自身が利用可能な１つ以上のアドホックルーティングプロトコルを有し、そのプロトコル情報を予め保持する。ここで、携帯端末Ａ、Ｂ及びＣは、アドホックネットワークにおける通信可能な範囲に存在しているとする。

（Ｓ１０１）最初に、携帯端末Ａが、他の携帯端末との間でアドホックネットワークを構成したいとする。携帯端末Ａは、周囲にどのようなプロトコルをサポートした携帯端末が存在するかを確認するために、プロトコル問い合わせパケットを同報送信する。携帯端末Ａから送信されたプロトコル問い合わせパケットは、携帯端末Ｂ及びＣによって受信される。プロトコル問い合わせパケットは、携帯端末Ａ自身が利用可能な１つ以上のプロトコル情報を含む。

（Ｓ１０２）携帯端末Ｂは、携帯端末Ａから受信したプロトコル問い合わせパケットに対して、自身が利用可能な１つ以上のプロトコル情報を含むプロトコル広告パケットを同報送信する。プロトコル広告パケットは、携帯端末Ａ及びＣによって受信される。
（Ｓ１０３）携帯端末Ｃは、携帯端末Ａから受信したプロトコル問い合わせパケットに対して、自身が利用可能な１つ以上のプロトコル情報を含むプロトコル広告パケットを同報送信する。プロトコル広告パケットは、携帯端末Ａ及びＢによって受信される。

（Ｓ１０４）携帯端末Ａは、携帯端末Ｂ及びＣから受信したプロトコル広告パケットに応じて、１つのプロトコルを選択する。携帯端末Ｂ及びＣも、同様の方法で１つのプロトコルを選択する。全ての携帯端末は、同じ方法で１つのプロトコルを選択するので、必然的に同じプロトコルを選択することとなる。
（Ｓ１０５）携帯端末Ａ、Ｂ及びＣは、選択された１つのアドホックルーティングプロトコルを用いて、アドホックネットワークを構成する。

「プロトコル問い合わせパケット」及び「プロトコル広告パケット」は、ＩＣＭＰ(Internet Control Message Protocol：RFC792)ヘッダによって特定される。ＩＣＭＰとは、ＴＣＰ／ＩＰ(Transport Control Protocol / Internet Protocol)と組み合わせて、パケットの中継転送中に生じたエラーを送信元ノードへ返送する制御用プロトコルである。具体的には、ＴＣＰ／ＩＰの通信中にエラーが発生した場合、そのエラーが発生した場所（相手方ノード又はルータ）から、パケットの送信元アドレスに向かってエラー情報が転送される。これにより、ルータ又は送信元ノードは、エラーが発生したことを知ることができる。例えば、ＴＣＰ／ＩＰで接続されたネットワーク内において、互いのノードの状態を確認するために用いられる「ping」コマンドがある。

本発明におけるプロトコル問い合わせパケットは、以下の表１のような構成を有する。

表１によれば、宛先アドレスは、ブロードキャストアドレス又はマルチキャストアドレスとして設定され、送信元アドレスは、携帯端末自身のアドレスとなる。その下に、斜線部分で表された、３２ビットのＩＣＭＰヘッダがある。

既存のType部分は、例えば以下の表２のように規定されており、新たに「プロトコル問い合わせパケット」と「プロトコル広告パケット」とが規定される。

この場合、ＩＣＭＰヘッダの下に、１つ以上のプロトコル情報のエントリが付加される。表１によれば、エントリには、自携帯端末が使用したい所望の［エントリ情報の長さ(byte)］［プロトコル名］［バージョン］［ネットワーク名］の情報が設定される。勿論、複数のエントリが含まれていてもよい。

［エントリ情報の長さ］は、そのプロトコル情報の示すbyte数を表す。［プロトコル名］は、アドホックルーティングプロトコルの識別情報を表す。［バージョン番号］は、そのプロトコルのバージョンを表す。同一プロトコルであっても、バージョン番号によってはアドホックルーティングが十分に機能しない場合もあるからである。［ネットワーク名］は、ネットワーク識別子であって、例えば無線ＬＡＮにおけるＳＳＩＤ(Service Set Identifier)である。

［ネットワーク名］だけを指定するものであってもよいし、［プロトコル名］だけを指定するものであってもよい。特に指定しないその他の項目は、ワイルドカード「＊」のような指定にすることもできる。

携帯端末は、プロトコル問い合わせパケットを受信した際に、問い合わせ内容に適合したプロトコル情報を含むプロトコル広告パケットを返信する。例えば、受信した問い合わせパケットについて、全ての項目［プロトコル名］［バージョン］［ネットワーク名］がワイルドカード「＊」で指定されていた場合、その携帯端末は、自ら保持しているプロトコル情報テーブルに登録されている全てのエントリの情報を、プロトコル広告パケットに含めて送信する。

また、携帯端末は、定期的に、プロトコル広告パケットを送信するものであってもよい。この場合、プロトコル広告パケットには、プロトコル情報テーブルに含まれる全てのプロトコル情報を格納する。このようにプロトコル広告パケットをブロードキャストすることによって、携帯端末は、アドホックネットワーク内でどのようなプロトコルを使用可能かを知ることができる。

プロトコル広告パケットを受信した携帯端末は、そのパケットに含まれる所望プロトコル情報を満たすプロトコル情報を選択する。選択されたプロトコル情報は、プロトコル広告パケットに含められ、そのプロトコル広告パケットは、同報送信される。

本発明におけるプロトコル広告パケットは、以下の表３のような構成を有する。

前述した実施形態によれば、「プロトコル問い合わせパケット」及び「プロトコル広告パケット」を、ＩＣＭＰヘッダによって特定するように説明したが、ＵＤＰ又は他のレイヤ２フレームに含ませるものであってもよい。

［優先度］は、そのプロトコルの優先順位を表す。複数のプロトコル情報において、優先度の高いプロトコルから順に、プロトコル選択の候補とされる。

他の実施形態として、例えば主ノード（基地局）が、プロトコル広告パケットを定期的（自律的）に同報送信することにより、アドホックネットワークの構成を制御することもできる。

図２は、本発明における携帯端末の機能構成図である。

図２によれば、携帯端末１は、プロトコル情報テーブル管理部１０と、プロトコル広告受信部１１と、プロトコル広告送信部１２と、ルーティングプロトコル起動部１３と、１つ以上のルーティングプロトコル部１４１〜１４ｎとを有する。

プロトコル情報テーブル管理部１０は、携帯端末１自身がサポートするプロトコル情報を含むプロトコル情報テーブルを保持する。プロトコル情報テーブルは、プロトコル情報毎に、以下の情報を含む。

［activeフラグ］は、自発的に広告するエントリなのか、他の携帯端末からのプロトコル広告パケットを受信して生成したエントリなのかを示す。即ち、自携帯端末がサポートできるプロトコル情報については、当該プロトコルの[active]フラグを「１」にセットする。

［lifetime］は、一定の初期値から、時間経過と共に減分していく時間カウンタである。ライフタイムが満了すると、そのエントリは、削除される。

ここで、自携帯端末が使用したいプロトコルが予め決定されている場合、当該プロトコルの[active]フラグを「１」にセットし、［lifetime］を無限大とすることにより、常にそのプロトコルの存在を周囲に広告できるようになる。尚、［lifetime］の更新は、プロトコル広告の受信（当該プロトコルが含まれている場合）だけでなく、現在実際に利用中のルーティングプロセスからも更新できるものとする。また、プロセス起動中に限り、［lifetime］を無限大としてもよい。

プロトコル広告受信部１１は、所望プロトコル情報を含むプロトコル広告パケットを受信する。そして、プロトコル情報テーブル管理手段を参照し、所望プロトコル情報を満たすプロトコル情報を選択する。選択されたプロトコル情報は、ルーティングプロトコル起動部１３へ通知される。

また、プロトコル広告受信部１１は、周囲に存在する携帯端末からプロトコル広告パケットを受信するために、プロトコル問い合わせパケットを同報送信することができる。プロトコル問い合わせパケットには、携帯端末１自身が利用可能な１つ以上のプロトコル情報を含む。

プロトコル広告送信部１２は、定期的に、又は、プロトコル問い合わせパケットを受信した際に、プロトコル広告パケットを同報送信する。ここで、プロトコル広告パケットには、当該携帯端末の所望プロトコル情報が含まれる。更に、プロトコル広告送信部１２は、選択されたプロトコル情報をルーティングプロトコル起動部１３へ通知する。尚、プロトコル広告送信部１２は、プロトコル問い合わせパケットを受信した場合に、必ずしもそれに応答してプロトコル広告パケットを送信しなくてもよい。

ルーティングプロトコル起動部１３は、プロトコル広告受信部１１及びプロトコル広告送信部１２から、選択されたプロトコル情報の通知を受ける。ルーティングプロトコル起動部１３は、通知されたプロトコル情報に基づいて、ルーティングプロトコル１４１〜１４ｎのいずれかを起動する。

図３は、本発明におけるプロトコル広告パケットを受信した携帯端末のフローチャートである。

（Ｓ３０１）プロトコル広告パケットのプロトコル情報のネットワーク名と、プロトコル情報テーブル管理部に記憶されておりactiveフラグ＝「１」に設定されたプロトコル情報のネットワーク名とを比較し、同一のネットワーク名となるプロトコル情報のみを選択する。ここで、候補となるプロトコル情報が存在しない場合、プロトコル広告パケットは破棄して（Ｓ３０６）終了する。
（Ｓ３０２）Ｓ３０１によって選択されたプロトコル情報について、次に、プロトコル広告パケットのプロトコル情報のプロトコル名と、プロトコル情報テーブル管理部に記憶されておりactiveフラグ＝「１」に設定されたプロトコル情報のプロトコル名とを比較し、同一のプロトコル名となるプロトコル情報のみを選択する。ここで、候補となるプロトコル情報が存在しない場合、プロトコル広告パケットは破棄して（Ｓ３０６）終了する。

（Ｓ３０３）Ｓ３０２によって選択されたプロトコル情報が複数ある場合、プロトコル広告パケットのプロトコル情報の優先度と、プロトコル情報テーブル管理部に記憶されたプロトコル情報の優先度とを比較し、両優先度に応じてプロトコル情報を選択する。一般に、新しいバージョンのプロトコル情報は、高い優先度になされると考えられる。逆に、新しいバージョンであってもリリース後の期間が短く、安定していないプロトコル情報については、優先度を低く抑えることも好ましい。

（Ｓ３０４）Ｓ３０３によって選択されたアドホックルーティングプロトコルが起動され、経路が確立される。
（Ｓ３０５）アドホック通信が実現できる。

ここで、アドホックネットワーク全体で、ある程度、統一的にプロトコルを選択する方法もある。例えば、第１のアドホックルーティングプロトコルを起動したけれども、周囲にそのプロトコルを使用している端末が存在しないために動作しなかった場合、第１のアドホックルーティングプロトコルを終了させる。このとき、当該携帯端末は、プロトコル情報テーブル内の当該プロトコルに関する優先度を下げるように設定する。そして、当該携帯端末は、再度、優先度の高いプロトコルを選択し直す。新たに選択されたプロトコルについての問い合わせパケットを送信してもよい。即ち、起動したプロトコルを使用することができなかったといって、周囲に存在する端末がそのプロトコルをサポートしていないというわけではなく、単に起動されていない場合もあるからである。

図４は、本発明におけるプロトコル問い合わせパケットを受信した携帯端末のフローチャートである。

（Ｓ４０１）Ｓ３０１と同様であって、同一ネットワーク名のプロトコル情報を選択する。ここで、候補となるプロトコル情報が存在しない場合、プロトコル問い合わせパケットを破棄して（Ｓ４０５）終了する。
（Ｓ４０２）Ｓ３０２と同様であって、同一プロトコル名のプロトコル情報を選択する。ここで、候補となるプロトコル情報が存在しない場合、プロトコル問い合わせパケットを破棄して（Ｓ４０５）終了する。
（Ｓ４０３）同一バージョンのプロトコル情報を選択する。ここで、同一バージョンのプロトコル情報が存在しない場合、プロトコル問い合わせパケットを破棄して（Ｓ４０５）終了する。
（Ｓ４０４）選択されたプロトコル情報を含むプロトコル広告パケットを、同報送信する。尚、プロトコル問い合わせパケットを受信したからといって、プロトコル広告パケットを必ず送信する必要はない。

前述したように、本発明によれば、複数のアドホックルーティングプロトコルを有する端末が複数存在するアドホックネットワークにおいて、プロトコルを選択することができる。

前述した本発明における種々の実施形態によれば、本発明の技術思想及び見地の範囲の種々の変更、修正及び省略を、当業者によれば容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。

本発明におけるシーケンス図である。本発明における携帯端末の機能構成図である。本発明におけるプロトコル広告パケットを受信した携帯端末のフローチャートである。本発明におけるプロトコル問い合わせパケットを受信した携帯端末のフローチャートである。

符号の説明

１携帯端末
１０プロトコル情報テーブル管理部
１１プロトコル広告受信部
１２プロトコル広告送信部
１３ルーティングプロトコル起動部
１４１〜１４ｎ利用可能なアドホックルーティングプロトコル

Claims

１つ以上のアドホックルーティングプロトコルを有する携帯端末であって、
アドホックルーティングのプロトコル情報テーブルを記憶したプロトコル情報テーブル管理手段と、
相手方端末から、プロトコル情報を含むプロトコル広告パケットを受信し、該プロトコル広告パケットに含まれるプロトコル情報を、前記プロトコル情報テーブル管理手段の前記プロトコル情報テーブルに登録し、該プロトコル情報テーブルの中から所望プロトコル情報を選択するプロトコル広告受信手段と、
前記所望プロトコル情報に基づくプロトコルを起動するルーティングプロトコル起動手段と
を有することを特徴とする携帯端末。
前記プロトコル広告パケットは、ＩＣＭＰヘッダによって規定されており、
前記プロトコル情報毎に、プロトコル名、バージョン番号、ネットワーク名及び優先度又はいずれかを含むことを特徴とする請求項１に記載の携帯端末。
前記プロトコル情報テーブル管理手段は、当該携帯端末が利用可能なプロトコル情報に対して第１のフラグを「１」に設定し、
前記プロトコル広告受信手段は、前記プロトコル情報テーブルについて、前記第１のフラグが「１」に設定されたプロトコル情報から前記所望プロトコルを選択することを特徴とする請求項１又は２に記載の携帯端末。
定期的に、又はプロトコル問い合わせパケットを受信した際に、前記プロトコル広告パケットを送信するプロトコル広告送信手段を更に有し、
前記プロトコル広告送信手段は、定期的に前記プロトコル広告パケットを送信する場合、前記プロトコル広告パケットには、前記プロトコル情報テーブルに登録された全てのプロトコル情報が格納され、又は、
前記プロトコル問い合わせパケットを受信した際に前記プロトコル広告パケットを送信する場合、前記プロトコル問い合わせパケットに含まれる前記プロトコル情報に適合するように選択されたプロトコル情報が格納される
ことを特徴とする請求項１から３のいずれか１項に記載の携帯端末。
１つ以上のアドホックルーティングプロトコルを有する携帯端末に搭載されたコンピュータを機能させるプログラムであって、
アドホックルーティングのプロトコル情報テーブルを記憶したプロトコル情報テーブル管理手段と、
相手方端末から、プロトコル情報を含むプロトコル広告パケットを受信し、該プロトコル広告パケットに含まれるプロトコル情報を、前記プロトコル情報テーブル管理手段の前記プロトコル情報テーブルに登録し、該プロトコル情報テーブルの中から所望プロトコル情報を選択するプロトコル広告受信手段と、
前記所望プロトコル情報に基づくプロトコルを起動するルーティングプロトコル起動手段と
してコンピュータを機能させることを特徴とするプログラム。
前記プロトコル広告パケットは、ＩＣＭＰヘッダによって規定されており、
前記プロトコル情報毎に、プロトコル名、バージョン番号、ネットワーク名及び優先度又はいずれかを含むようにコンピュータを機能させることを特徴とする請求項５に記載のプログラム。
前記プロトコル情報テーブル管理手段は、当該携帯端末が利用可能なプロトコル情報に対して第１のフラグを「１」に設定し、
前記プロトコル広告受信手段は、前記プロトコル情報テーブルについて、前記第１のフラグが「１」に設定されたプロトコル情報から前記所望プロトコルを選択するようにコンピュータを機能させることを特徴とする請求項５又は６記載のプログラム。
定期的に、又はプロトコル問い合わせパケットを受信した際に、前記プロトコル広告パケットを送信するプロトコル広告送信手段を更に有し、
前記プロトコル広告送信手段は、定期的に前記プロトコル広告パケットを送信する場合、前記プロトコル広告パケットには、前記プロトコル情報テーブルに登録された全てのプロトコル情報が格納され、又は、
前記プロトコル問い合わせパケットを受信した際に前記プロトコル広告パケットを送信する場合、前記プロトコル問い合わせパケットに含まれる前記プロトコル情報に適合するように選択されたプロトコル情報が格納される
ようにコンピュータを機能させることを特徴とする請求項５から７のいずれか１項に記載のプログラム。