JP2008211443A - 通信システム及び通信方法 - Google Patents
通信システム及び通信方法 Download PDFInfo
- Publication number
- JP2008211443A JP2008211443A JP2007045242A JP2007045242A JP2008211443A JP 2008211443 A JP2008211443 A JP 2008211443A JP 2007045242 A JP2007045242 A JP 2007045242A JP 2007045242 A JP2007045242 A JP 2007045242A JP 2008211443 A JP2008211443 A JP 2008211443A
- Authority
- JP
- Japan
- Prior art keywords
- communication
- terminal
- wireless node
- path
- receiving terminal
- 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.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Radio Relay Systems (AREA)
Abstract
【課題】無線アドホックネットワークにおいて、所要のQoSを満足する通信経路を効率良く見つけ出すことができる通信システムを提供する。
【解決手段】本発明に係る通信システムは、無線アドホックネットワークを構成する通信システムにおいて、送信端末と、送信端末から送信されるデータを受信する受信端末と、送信端末と受信端末との間に設けられ、1以上の通信経路の中継を夫々行う複数の無線ノードと、複数の無線ノードの夫々の通信状況をモニタし、所定の通信品質を満たす送信端末から受信端末までの通信経路を決定する通信経路制御装置と、を備えたことを特徴とする。
【選択図】 図1
【解決手段】本発明に係る通信システムは、無線アドホックネットワークを構成する通信システムにおいて、送信端末と、送信端末から送信されるデータを受信する受信端末と、送信端末と受信端末との間に設けられ、1以上の通信経路の中継を夫々行う複数の無線ノードと、複数の無線ノードの夫々の通信状況をモニタし、所定の通信品質を満たす送信端末から受信端末までの通信経路を決定する通信経路制御装置と、を備えたことを特徴とする。
【選択図】 図1
Description
本発明は、通信システム及び通信方法に係り、特に、無線アドホックネットワークを構成する通信システム及び通信方法に関する。
アドホックネットワークとは、「特別に」、「その場に限って」といった意味をもつラテン語からきたアドホック(ad hoc)と、ネットワークとを組み合わせた用語である。無線アドホックネットワークは、無線で接続できる端末で構成されたネットワークであり、必要に応じて動的なネットワークの構築が可能である。従来の無線通信システムやインターネット、或いは社内LANのように予め中継局やルータが静的に固定されているネットワークが常設的なネットワークであるのに対して、無線アドホックネットワークは非常設的なネットワークであるともいうことができる。無線アドホックネットワークによって柔軟性の高いネットワークが構築できる。
一方、複数の無線端末によってネットワークを構築する場合、特に無線端末が移動中継局の場合には建物や地形の影響によって一部の移動中継局が使用不可能となる場合がある。特許文献1には、このような場合であっても、使用可能な複数の移動中継局の範囲のなかで最適な通信経路や使用周波数を選択する技術が開示されている。
特開2002−290304号公報
ところで、無線ネットワークをIPネットワークで構築しようとした場合、1つの中継局としての無線端末(この、無線端末を以下、ノード或いはルータと呼ぶ場合がある)には複数のIPアドレスの送信元から複数のIPアドレスの送信先に対する複数の通信経路が中継されうる。このため、各通信経路の輻輳を回避すべく、各ノードではQoS制御と呼ばれる制御が行われている。
QoS(Quality of Service)とは、通信サービスの品質を定量的に表現する指標であり、具体的には、通信の帯域、パケットの遅延時間やジッタの量、パケットの損失率等の総称である。また、QoS制御とは、所望のQoSを実現するためにノードで行われる処理であり、従来から種々のQoS制御方法が提案されている。
動画や音声のような連続的でリアルタイム性が要求されるデータを送信する場合には、QoSのうち特に通信帯域の確保が重要になる。送信すべきデータの帯域よりも狭い帯域のノードが通信経路上に存在すると通信データの一部が途切れてしまい、連続的なデータ通信がリアルタイムで送信できなくなってしまう。このような事態を回避するため、必要な帯域を通信系路上の各ノード(ルータ)に対して予約する方法が考えられている。
例えば、RSVP(ReSerVation Protocol)と呼ばれる、受信者主導型で帯域予約を行うプロトコルがある。受信者(送信先)の下流から送信元の上流に向かって、必要な帯域予約を各ノードに対して順次行っていくプロトコルである。
しかしながら、帯域予約を行おうとしても、そもそも必要な帯域が通信経路状の各ノードで実現可能であるか否かが定かではない。特に、無線アドホックネットワークでは、通信経路は流動的であり、また不安定でもある。即ち、QoSの低いノードとQoSの高いノードが混在し、かつこれらのノードのQoSの状態が変化するネットワークである。
このため、無線アドホックネットワークでは、所要の帯域等のQoSを満たす通信経路を、送信元から送信先までの間に複数存在しうる通信経路の中から見つけ出すことが重要となる。
本発明は、上記事情に鑑みてなされたもので、無線アドホックネットワークにおいて、所要のQoSを満足する通信経路を効率良く見つけ出すことができる通信システム、及び通信方法を提供することを目的とする。
上記課題を解決するため、本発明に係る通信システムは、請求項1に記載したように、無線アドホックネットワークを構成する通信システムにおいて、送信端末と、前記送信端末から送信されるデータを受信する受信端末と、前記送信端末と前記受信端末との間に設けられ、1以上の通信経路の中継を夫々行う複数の無線ノードと、前記複数の無線ノードの夫々の通信状況をモニタし、所定の通信品質を満たす前記送信端末から前記受信端末までの通信経路を決定する通信経路制御装置と、を備えたことを特徴とする。
また、上記課題を解決するため、本発明に係る通信方法は、請求項9に記載したように、送信端末、受信端末、及び前記送信端末と前記受信端末との間に設けられ、1以上の通信経路の中継を夫々行う複数の無線ノードを有する無線アドホックネットワークの通信方法おいて、(a)前記複数の無線ノードの夫々の通信状況をモニタし、所定の通信品質を満たす前記送信端末から前記受信端末までの通信経路を決定し、(b)決定された前記通信経路上の無線ノードを介して前記送信端末と前記受信端末との間の通信を行う、ステップを備えたことを特徴とする。
本発明に係る通信システム、及び通信方法によれば、無線アドホックネットワークにおいて、所要のQoSを満足する通信経路を効率良く見つけ出すことができる。
本発明に係る通信システム、及び通信方法の実施形態について添付図面を参照して説明する。
(1)構成
図1は、本発明の一実施形態に係る通信システム1のシステム構成例を示す図である。通信システム1は、送信端末S1、受信端末L1、L2,及び送信端末S1から受信端末L1、L2の間の通信を中継する複数の無線ノードN1〜N16、及び通信経路制御装置としてのデスパッチャDを有している。
図1は、本発明の一実施形態に係る通信システム1のシステム構成例を示す図である。通信システム1は、送信端末S1、受信端末L1、L2,及び送信端末S1から受信端末L1、L2の間の通信を中継する複数の無線ノードN1〜N16、及び通信経路制御装置としてのデスパッチャDを有している。
図1では、16個の無線ノードN1〜N16を例示しているが、無線ノードN(以下、無線ノードの総称として単に無線ノードNと表記するものとする)の数は特に限定するものではない。各無線ノードNは無線アドホックネットワークを構成するノードであり、ルータの機能を有している。
送信端末S1は無線通信可能な端末であり、例えばストリームデータ等をマルチキャスト送信するサーバである。また、受信端末L1、L2も無線通信可能な端末であり、例えばマルチキャストグループのメンバーとして送信端末S1からのデータを受信する受信者である。なお、マルチキャストグループのメンバーの数も図1に例示した2に限定するものではない。また、以下の説明では、送信端末S1から受信端末L1に向けてマルチキャスト通信を行う場合を例として説明するが、本発明の要旨はマルチキャスト通信に限定するものではなく、より広く行われているユニキャスト通信にも適用できるものである。
デスパッチャDは、データ送信サーバである送信端末S1を制御する他、各無線ノードNから通信状況に関する情報を吸い上げ、送信端末S1から受信端末L1へ至る通信経路P1を形成するために重要な役割を果たす。
通常、ユニキャスト通信やマルチキャスト通信では、各ノード(ルータ)は通信可能な隣接するノード(ルータ)とお互いの通信状況をやり取りし、経路を徐々に形成してネットワークを構築している。このようにして形成された通信経路は、通信可能性(通信ができること)は保証されるものの、必ずしもその通信経路のQoS(通信品質)までを保証するものではない。
通信するデータの内容によってはQoSの確保が重要になる場合がある。特に動画や音声のようなリアルタイム性が要求されるデータを通信、或いは配信する場合にはQoSの確保は非常に重要である。また、マルチキャスト通信では動画データや音声データの配信が行われる場合が多い。
デスパッチャDは、通信経路の形成にあたって、単に通信可能性を保証するだけでなく、所望のQoSを確保できる通信経路を形成するように動作する。デスパッチャDの詳細動作については後述する。
なお、図1では1つのデスパッチャDを例示しているが、複数のデスパッチャDを無線ノードNの間に配置する構成としても良い。この場合、複数のデスパッチャDに階層的な上下関係を構築し、最終的に1つの主デスパッチャDに情報を集約させると共にこの主デスパッチャDから下部の複数のデスパッチャDに対して指示する構成としても良い。
他方、無線アドホックネットワークにおいては、各ノードは無線によって通信を行うため容易に移動することができる。このため、有線通信のように配線の物理的な制約を受けることがなく、各ノードは配置上の制約を受けることが比較的少ない。その反面、移動が自由に行われるがゆえに各ノード間の接続が不安定となりがちである。例えば、あるノードが移動によって電波障害物の陰に入ったような場合にはそのノードとの接続が急に不安定になり、場合によっては接続ができなくなる。
このように通信中に一部のノードが接続不可となった場合、通信可能なノードを探し出し新たな通信経路を形成する必要がある。また、受信端末L1が通信を一旦中断しその後通信を再開しようとした場合に、中断期間中に通信経路上のいずれかのノードが接続不可となったときは過去の通信経路は使用できないため、同様に新たな通信経路を形成する必要がある。
このような場合にも、デスパッチャDは所望のQoSを確保できる通信経路を形成するように動作する。
(2)通信経路形成方法(新たに通信経路を形成する場合)
次に、本実施形態に係る通信方法について、特にデスパッチャDが主体として行う通信経路形成方法について説明する。
次に、本実施形態に係る通信方法について、特にデスパッチャDが主体として行う通信経路形成方法について説明する。
受信端末L1は、マルチキャストデータを受信しようとするとき、デスパッチャDに対してマルチキャストグループへの参加を通知する。デスパッチャDはこの通知を受けて、送信端末S1から受信端末L1に向けて、QoSの確保が可能な通信経路を形成する。
図2は、QoSを確保できる通信経路を新たに形成する手順の一例を示すフローチャートである。
まず、ステップST1にて、通常用いられているユニキャストルーティングプロトコルを利用して初期経路P0を形成する。図3は、この初期経路P0を例示する図であり、例えば、送信端末S1から受信端末L1へ最短経路で初期経路P0が形成される。ユニキャストルーティングプロトコルとしては、例えば、RIP(Routing Information Protocol)やOSPF(Open Shortest Path First)等の既存技術を利用することができる。ここで形成される初期経路P0は、現在の接続可能性のみが考慮された経路であり、QoSの確保可能性までが保証されたものではない。初期経路P0の形成は、既存のユニキャストルーティングプロトコルを利用して各無線ノードNが自律的に形成することができる。
ステップST2以降の手順は、デスパッチャDがQoSの確保可能性を考慮して経路形成を行っていく手順である。また、図4乃至図6は、デスパッチャDがQoSが確保可能な経路(以下、単にQoS経路という)を形成していく様子を例示する図である。
まず、ステップST2で、現在の経路上の確定ノードから通信可能なノードを初期経路上のノードを優先して選択する。この段階での現在の経路は初期経路P0である。また、QoSの確保可能な無線ノードNの確定は上流(送信端末S1側)から下流(受信端末L1側)に向けて順次行うため、この段階での確定ノードは、送信端末S1に最も近接した無線ノードN1となる。デスパッチャDは、現在の確定ノードである無線ノードN1から通信可能なノードを初期経路上のノードを優先して選択する。
デスパッチャDは各無線ノードNの夫々が通信可能な無線ノードNに関する情報を、各無線ノードNから常時、或いは定期的にモニタしている。例えば、図4の例では、無線ノードN1と通信可能なノードは、無線ノードN2、N5、及びN6であることをデスパッチャDは認識している。このうち、初期経路P0上の無線ノードN6が優先的に候補として最初に選択される。
次のステップST3〜ステップST5は、選択した無線ノードN、この場合無線ノードN6が所定のQoSを満たしているか否かをデスパッチャDで判定する手順である。
デスパッチャDは、各無線ノードNの現在の通信状況もモニタしており、この通信状況から各無線ノードNが所定のQoSを満たしているか否かを判定することができる。
QoSの種類や数は特に限定するものではないが、動画や音声等のリアルタイムデータを無線で通信するという観点からは、少なくともMTU(Maximum Transfer Unit)、余裕帯域、及び接続経過時間をQoSとすることが好適である。
MTUは、一度に送信できるデータの最大パケットサイズである。
余裕帯域は、無線ノードNの最大帯域から現在既に使用している帯域を除いた帯域である。動画等のリアルタイムデータの通信を行う場合、通信経路上のノードに対して必要な帯域の予約を行う(これを帯域予約という)が、送信端末S1から受信端末L1に向けてこれから送信しようとするデータの帯域(必要帯域)より余裕帯域が小さいと、そもそも帯域予約ができなくなり安定な通信ができない。その意味で各無線ノードNの余裕帯域はQoSとして重要である。
また、各ノードの接続経過時間をQoSとすることは、本実施形態のように各ノードが無線による通信を行う場合に特に意味がある。無線ノードNは容易に移動ができるため、電波環境等の変化によって接続が停止する可能性が十分ある。接続経過時間が長い無線ノードNは、一定の場所に長時間固定されているノードであり安定した通信が可能であると推定できる一方、接続経過時間が短い無線ノードNは、頻繁に移動している可能性が高く安定な通信が得られにくいと推定できる。つまり、接続経過時間を無線ノードNの安定性の指標とすることができる。このため、接続経過時間をQoSの1つとしている。
ステップST3からステップST5にて3つのQoS(MTU、余裕帯域、接続経過時間)が要求値を満たすか否かを順次判定し、1つでも要求値を満たさない場合にはステップST6へ進む。
ステップST6では、判定する無線ノードNを無線ノードN6から他の通信可能な無線ノードN、今の例では無線ノードN2又はN5に変更し、変更した無線ノードNに対してステップST3からステップST5の判定を再度行う。
図4の例では、無線ノードN2が所定のQoS要求値を満たす無線ノードNであると判定されたため、無線ノードN2を確定ノードとする。なお、確定したノード間の経路は太い実線(QoS経路)で示している。
ステップST7では、送信端末S1から受信端末L1までのノードが総て確定されたか否かの判定を行う。今の場合、無線ノードN2までしか確定されていないため、ステップST2に戻る。ステップST2では、確定された無線ノードN2と通信可能ノードを初期経路上のノードを優先して選択する。この場合無線ノードN6がまず選択される。
無線ノードN6がQoSの要求値を満たしている場合は、無線ノードN6が確定ノードとなる。以下、同様にして確定ノードを順次下流方向にむけて決定していく。
図5は、無線ノードN14までの経路が確定した状態を示しており、ノードの確定手順はさらに継続する。
図6は、最終的に決定された送信端末S1から受信端末L1までの無線ノードN(N1、N2、N6、N10、N14、N15、N16)とその間を結ぶQoS経路を示している。
確定されたQoS経路上の各無線ノードNの情報はデスパッチャDが保有している。デスパッチャDは、ノード確定後、QoS経路上の各無線ノードNに対して、宛先(受信端末L1)と直接送信対象となる無線ノードNを通信方向として通知する。例えば、無線ノードN1に対しては、宛先は受信端末L1であり、通信方向は無線ノードN2であることを通知する。また、無線ノードN2に対しては、宛先は受信端末L1であり、通信方向は無線ノードN6であることを通知する。QoS経路上の各無線ノードNは、デスパッチャDから通知されたこの情報に基づいて、宛先(受信端末L1)に向けたデータについては通知された通信方向の無線ノードNに送信する。
QoS経路上の各無線ノードNは、必要な帯域が確保可能であることが保証されたノードである。従って、既存の帯域予約プロトコルを用いて各無線ノードNに対して帯域予約を行なえば、確実に必要な帯域を確保することができる。
図7は、RSVP(ReSource reserVation Protocol)と呼ばれる帯域予約プロトコルの動作概念を示す図である。RSVPは、通信を行う端点の間で帯域の予約を事前に行うプロトコルである。帯域予約は送信アドレス/ポート番号と、受信アドレス/ポート番号の組合せで管理されている。
まず、送信元(送信端末S1)から、下流(受信端末L1の方向)に向けて経路上のルータ(無線ノードN)にPathメッセージを送信する。ルータは有効なPathメッセージを受け取ると、その送信元についての経路ステータスを更新する。ルータ(無線ノードN)はPathメッセージが受信者(受信端末L1)に届くまで経路表に従ってPathメッセージを転送する。
Pathメッセージを受信した受信者(受信端末L1)は、Pathメッセージが来た逆順の経路をたどって送信元(送信端末S1)に各ルータ(無線ノードN)を経由してRecvメッセージを送信する。このRecvメッセージには予約帯域の情報が含まれており、Recvメッセージを中継する各ルータ(無線ノードN)はRecvメッセージに含まれる予約帯域の情報に基づいて帯域予約を行う。
このようにして必要帯域の予約が完了とすると送信端末S1から受信端末L1に対してQoSが確保された安定な通信が可能となる。送信端末S1からマルチキャスト通信を行う場合には、送信端末S1からマルチキャストアドレス(例えば、IPv4の場合には、224.0.0.1から239.255.255.255までのIPアドレス、IPv6の場合には、FFで始まるIPアドレス)をもつ受信端末L1を宛先としてデータを送信する。
(3)通信の中断及び通信経路の再形成
受信端末L1が通信を中断、或いは停止する場合(マルチキャストグループから離脱する場合)には、終了報告を受信端末L1に最も近い無線ノードNに送信する一方、デスパッチャDに対しても同様の終了報告を送信する。デスパッチャDは、受信端末L1からの終了報告を受信すると、通信経路上の各無線ノードNに対して受信端末L1の通信終了を通知する。この通知により、各無線ノードNは自分の経路表から受信端末L1を直ちに削除する。
受信端末L1が通信を中断、或いは停止する場合(マルチキャストグループから離脱する場合)には、終了報告を受信端末L1に最も近い無線ノードNに送信する一方、デスパッチャDに対しても同様の終了報告を送信する。デスパッチャDは、受信端末L1からの終了報告を受信すると、通信経路上の各無線ノードNに対して受信端末L1の通信終了を通知する。この通知により、各無線ノードNは自分の経路表から受信端末L1を直ちに削除する。
デスパッチャDが存在しない通常のケースでは、受信端末L1に近い無線ノードNから上流に向けて徐々に受信端末L1の終了報告が伝播していくため、総ての無線ノードNの経路表から受信端末L1が削除されるのに時間を要す。このため、受信端末L1に向けて無駄なパケットがしばらく配信されることになる。
これに対して、本実施形態では、デスパッチャDが受信端末L1の終了報告を総ての無線ノードNに対して同時に通知するため、総ての無線ノードNの経路表から即座に受信端末L1が削除され、無駄なパケットが配信されることを防ぐことができる。
受信端末L1が、中断した通信を再開する場合(離脱したマルチキャストグループに再度参加する場合)、送信端末S1から受信端末L1へのQoS経路を再形成する必要がある。無線ノードNは移動可能であり、中断期間中に過去のQoS経路上のいずれかの無線ノードNが移動して接続不可となっている可能性があるためである。
但し、この場合、全く新規に通信経路を形成するよりも過去に形成したQoS経路を可能な限り有効活用した方が短時間でQoS経路が構築される可能性が高い。本実施形態ではこの考えに基づいてQoS経路の再形成を行っている。
図8は、デスパッチャDがQoS経路の再形成を行う場合の手順の一例を示すフローチャートである。受信端末L1から通信再開の要求を受けると、デスパッチャDは送信端末S1と受信端末L1との間の過去のQoS経路P0’を初期経路として形成する(ステップST11)。デスパッチャDは過去のQoS経路を記憶しており、送信端末S1と受信端末L1との組み合わせからこれらの間に過去にQoS経路が存在していたことを検出し、この過去のQoS経路(図9に破線で示した経路)を初期経路とする。
新たなQoS経路を形成する場合には、図2に示したようにユニキャストルーティングによって形成した経路を初期経路としたが、QoS経路の再形成手順では、初期経路として過去のQoS経路を利用する点が異なっている。これ以外の手順(図8のステップST12以降の手順)は、基本的には図2のステップST2以降の手順と同じものである。
即ち、図10に示したように、まず無線ノードN1と通信可能なノードが所定のQoSの要求を満足しているか否かを判定し、満足している場合はその無線ノードNを無線ノードN1の次のノードとして確定していく。この場合、過去のQoS経路上のノードである無線ノードN2が優先的に最初に判定される。
中断前の無線ノードN2の通信状況(通信の輻輳状態や無線ノードN2の設置場所)と現在の通信状況とが大きく変化していない限り、無線ノードN2が所定のQoSを満足するはずである。従って、この無線ノードN2が確定される可能性は高く、無線ノードN2を最初に判定することによりQoS経路検索に要する時間が短縮される。
もっとも、中断期間中に無線ノードNが移動し、或いは無線ノードNの他のトラフィックが大きく増大した場合には、過去のQoS経路上の無線ノードNであっても所定のQoSが確保できない場合も生じ得る。
図11は、このような場合の経路形成の様子を例示する図である。無線ノードN6が確定された後、次の無線ノードNを確定しようとする場合、まず、過去のQoS経路上にある無線ノードN10が判定される。しかしながら、中断期間中に無線ノードN10の通信状況が変化し、現在では所定のQoS要求値を満たさなくなったと判定された場合には、他の無線ノードNを候補として判定していく。図11の例では無線ノードN9がQoS要求値を満たすと判定され、無線ノードN9が確定される。
無線ノードN9の確定後も同様にして下流側の無線ノードNの確定が進められ、最終的には図12に示すように所定のQoSを満足するQoS経路が再形成される。
(4)同じ受信端末が新たな送信端末と通信する場合の通信経路形成方法
送信端末S1が、例えば動画等のマルチメディアデータをマルチキャスト通信によって受信端末L1に配信しており、他の送信端末S2が連続するマルチメディアデータを続いてマルチキャスト通信によって受信端末L1に配信する場合がある。
送信端末S1が、例えば動画等のマルチメディアデータをマルチキャスト通信によって受信端末L1に配信しており、他の送信端末S2が連続するマルチメディアデータを続いてマルチキャスト通信によって受信端末L1に配信する場合がある。
例えば次のような場合である。まず、受信端末L1がデスパッチャDに対して送信端末S1からのデータ受信(例えば、マルチメディアデータの配信)を要求し、デスパッチャDはこの要求に応じてQoS経路を形成する。形成されたQoS経路を用いて送信端末S1と受信端末L1との間で通信(マルチキャスト通信)が行われる。その後、受信端末L1は送信端末S1に換えて別の送信端末S2から同種のデータの受信(例えば、同種のマルチメディアデータの配信)を希望し、デスパッチャDに対して送信端末S2からのデータ受信を要求する。要求を受けたデスパッチャDは、送信端末S2と受信端末L1との間に新たなQoS経路を形成しようとする。
このような場合、送信端末S2と受信端末L1との間で全く新規の経路を独立に形成するよりも、既に実績のある送信端末S1から受信端末L1へ至るQoS経路を可能な限り活用した方が有利である。送信端末S1と送信端末S2とでは同種のデータを送信しており、各無線ノードNに要求されるQoSも同程度であると考えられるからである。
図13は、このような場合におけるデスパッチャDのQoS経路形成の手順の一例を示すフローチャートである。
まず、ステップST21において、デスパッチャDは過去のQoS経路及びその経路に最も少ないホップ数で達する経路を初期経路として形成する。この初期経路形成の過程を図14及び図15を用いて説明する。
図14に示したように、ここでの過去のQoS経路とは、送信端末S1から受信端末L1へ至るQoS経路のことである。送信端末S2から、この過去のQoS経路に達する経路としては、無線ノードN4から無線ノードN3を経由して無線ノードN2に達する経路と、無線ノードN4から無線ノードN8、N12を経由して無線ノードN16に達する経路がある。前者のホップ数は2であり、後者のホップ数は3であるため前者の経路が選択される。なお、最も少ないホップ数の経路が複数ある場合には、他の選択基準、例えば最短の距離等を用いて1つの経路に絞り込む。
結局、初期経路としては、図15に示したように、送信端末S2から無線ノードN4、N3を経て無線ノードN2に達し、その後過去のQoS経路としての無線ノードN2から無線ノードN16へ向かう経路となる。
初期経路が決定されると、それ以降の手順は図2或いは図8の手順と同様の手順となる。即ち、送信端末S2に最も近接した無線ノードN4から順次各無線ノードNが所定のQoSの要求値を満足しているか否かを判定し、満足している無線ノードNを確定していく手順である。この場合にも最初に判定される無線ノードNは、初期経路上の無線ノードNとなる。
図16、図17、及び図18は無線ノードNが順次確定されていく様子を例示する図である。本例では、無線ノードN3の次に無線ノードN6が確定される。無線ノードN6は過去のQoS経路上のノードであり、直前までQoSが確保されていた経路である。従って、短時間の間にトラフィックの輻輳が突然発生した等の特段の事情が無い限り、これ以降はあらためてQoSを判定する必要は無く、この時点で送信端末S2から受信端末L1へ至るQoS経路が形成されたことになる。図19は、送信端末S2から受信端末L1へ至る最終的なQoS経路を示す図である。
図20は、上述した経路形成方法の適用例を示す図である。図20では、複数の送信サーバ(送信端末S1、S2、S3)がマルチキャスト通信を行っており、各送信サーバがインターネット放送をそれぞれタイムシフト送信している例を示している。
現在のインターネット放送を送信端末S1がマルチキャストアドレスFF0E::91で放送しており、送信端末S2はその内容よりも時間的に進んだ内容をマルチキャストアドレスFF0E::90で放送し、送信端末S3は、時間的に遅れた内容をマルチキャストアドレスFF0E::92で放送している例を示している。
マルチキャストアドレスをFF0E::91からFF0E::90やFF0E::92に切換えるだけで、あたかもDVDのチャプタを切換えるように1つのマルチキャストデータをタイムシフトすることが可能となる。
また、従来のインターネット放送では、送信端末S1と受信端末L1との間の通信でパケット抜け等が発生し聞き逃しが生じた場合、聞き逃した内容を取り戻すことは通常できなかった。これに対して、図20に示した構成とすれば、受信端末L1がマルチキャストアドレスをFF0E::91からFF0E::92に切換えるだけで聞き逃した過去の放送内容を受信することができる。
また、タイムシフトの実現や聞き逃し防止として、過去に受信したデータを一旦受信端末L1等のメモリの保存する形態がとられることがある。上記のタイムシフトマルチキャストの形態であればこれらのメモリは不要であり、大容量のメモリを保有できない携帯電話やPDAにおいてもタイムシフト再生や聞き逃しの防止が可能となる。
このようなタイムシフト/マルチキャストシステムを実現する上において、複数の送信端末に対しても短時間で効率良くQoS経路を形成することができる本実施形態の効果が大いに発揮される。
他の適用例として、トランシーバによる音声同報通信等も考えられる。トランシーバ等による音声データの通信において、複数の人間がマルチキャストデータを送信するような場合である。チームの作戦行動中に、ある操作者Aの指示を受けてさらに別の操作者Bが追加の指示を出すような場合、それぞれ別の経路によって信頼性を実現しようとしても、不安定な無線アドホックネットワークにおいては通信が成功しない場合もありうる。こういった状況においては、なるべく同じ安定したQoSをもって通信することが望ましい。上述した実施形態では、送信端末が異なる場合であってもQoS経路の共有化が可能であり、安定した通信の実現が容易となる。このため、全体としては不安定なアドホックネットワークであっても、その中からQoSが確保された経路を見つけ出し、かつ、この経路を複数の送信端末が共有することにより、安定な通信が可能となる。
以上説明してきたように、本実施形態に係る通信システム1及び通信方法によれば、無線アドホックネットワークにおいて、所要のQoSを満足する通信経路を効率良く見つけ出すことができるとともに、中断後に再開される通信や新たな送信端末との通信の通信経路も、既に形成されたQoS経路を有効活用することで効率良く見つけ出すことができる。
なお、本発明は上記の実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせても良い。
1 通信システム
D デスパッチャ(通信経路制御装置)
S1、S2 送信端末
L1、L2 受信端末
N 無線ノード
D デスパッチャ(通信経路制御装置)
S1、S2 送信端末
L1、L2 受信端末
N 無線ノード
Claims (16)
- 無線アドホックネットワークを構成する通信システムにおいて、
送信端末と、
前記送信端末から送信されるデータを受信する受信端末と、
前記送信端末と前記受信端末との間に設けられ、1以上の通信経路の中継を夫々行う複数の無線ノードと、
前記複数の無線ノードの夫々の通信状況をモニタし、所定の通信品質を満たす前記送信端末から前記受信端末までの通信経路を決定する通信経路制御装置と、
を備えたことを特徴とする通信システム。 - 前記通信経路制御装置は、
ある無線ノードと通信可能な複数の無線ノードの中から、所定の通信品質を満たす無線ノードを選択し、これを前記送信端末に近接する無線ノードから前記受信端末に近接する無線ノードまで順次繰り返すことで前記送信端末から前記受信端末までの通信経路を決定する、
ことを特徴とする請求項1に記載の通信システム。
通信経路制御装置と、 - 前記通信品質は、各無線ノードの最大通信帯域から既に使用中の通信帯域を除いた余裕帯域及び各無線ノードにおける通信の継続時間を含む通信品質である、
ことを特徴とする請求項1に記載の通信システム。 - 前記送信端末から前記受信端末への通信は、マルチキャスト通信で行われる、
ことを特徴とする請求項1に記載の通信システム。 - 前記受信端末は、
マルチキャストグループから離脱するときには、前記受信端末と直接接続されている前記無線ノードに離脱を通知すると共に前記通信経路制御装置にも離脱を通知し、
前記通信経路制御装置は、
前記受信端末の離脱を前記送信端末から前記受信端末の間に形成されている前記通信経路の他の無線ノードにも通知する、
ことを特徴とする請求項4に記載の通信システム。 - 前記通信経路制御装置は、
前記所定の通信品質を満たす通信経路にて前記送信端末と前記受信端末との間で通信が行われた後にその通信が中断され、その後前記送信端末と前記受信端末との間で通信を再開する場合には、
中断前の通信系路を基準として通信経路を形成し、前記中断前の通信経路にある無線ノードが前記所定の通信品質を満たさない場合には、その周囲の無線ノードの中から、前記所定の通信品質を満たす無線ノードを選択して再開後の通信経路を決定する、
ことを特徴とする請求項1に記載の通信システム。 - 前記通信経路制御装置は、
前記所定の通信品質を満たす通信経路にて前記送信端末と前記受信端末との間で第1の通信が行われ、その後前記受信端末から、第2の送信端末との間の通信であって前記第1の通信と実質的に同じ通信品質を満たす第2の通信の要求があった場合には、
前記第2の送信端末から前記受信端末に至る第2の通信の通信経路を、前記第1の通信が行われた通信経路を利用して決定する、
ことを特徴とする請求項1に記載の通信システム。 - 前記送信端末および前記第2の送信端末は、ストリームデータを所定のタイムシフトをもってそれぞれマルチキャスト通信で配信するサーバである、
ことを特徴とする請求項7に記載の通信システム。 - 送信端末、受信端末、及び前記送信端末と前記受信端末との間に設けられ、1以上の通信経路の中継を夫々行う複数の無線ノードを有する無線アドホックネットワークの通信方法おいて、
(a)前記複数の無線ノードの夫々の通信状況をモニタし、所定の通信品質を満たす前記送信端末から前記受信端末までの通信経路を決定し、
(b)決定された前記通信経路上の無線ノードを介して前記送信端末と前記受信端末との間の通信を行う、
ステップを備えたことを特徴とする通信方法。 - ステップ(a)とステップ(b)の間に、
前記所定の通信品質に含まれる通信帯域の予約を、前記受信端末から前記通信経路上の各無線ノードに対して行うステップ、
をさらに備えたことを特徴とする請求項9に記載の通信方法。 - ステップ(a)では、
ある無線ノードと通信可能な複数の無線ノードの中から、所定の通信品質を満たす無線ノードを選択し、これを前記送信端末に近接する無線ノードから前記受信端末に近接する無線ノードまで順次繰り返すことで前記送信端末から前記受信端末までの通信経路を決定する、
ことを特徴とする請求項9に記載の通信方法。
通信経路制御装置と、 - 前記通信品質は、各無線ノードの最大通信帯域から既に使用中の通信帯域を除いた余裕帯域及び各無線ノードにおける通信の継続時間を含む通信品質である、
ことを特徴とする請求項9に記載の通信方法。 - 前記送信端末から前記受信端末への通信は、マルチキャスト通信で行われる、
ことを特徴とする請求項9に記載の通信方法。 - マルチキャストグループから離脱するときには、前記受信端末と直接接続されている前記無線ノードに離脱を通知すると共に、前記送信端末から前記受信端末の間に形成されている前記通信経路の他の無線ノードにも通知する、
ことを特徴とする請求項13に記載の通信方法。 - 前記所定の通信品質を満たす通信経路にて前記送信端末と前記受信端末との間で通信が行われた後にその通信が中断され、その後前記送信端末と前記受信端末との間で通信を再開する場合には、
中断前の通信系路を基準として通信経路を形成し、前記中断前の通信経路にある無線ノードが前記所定の通信品質を満たさない場合には、その周囲の無線ノードの中から、前記所定の通信品質を満たす無線ノードを選択して通信再開時の通信経路を決定する、
ステップをさらに備えたことを特徴とする請求項9に記載の通信方法。 - 前記所定の通信品質を満たす通信経路にて前記送信端末と前記受信端末との間で第1の通信が行われ、その後前記受信端末から、第2の送信端末との間の通信であって前記第1の通信と実質的に同じ通信品質を満たす第2の通信の要求があった場合には、
前記第2の送信端末から前記受信端末に至る第2の通信の通信経路を、前記第1の通信が行われた通信経路を利用して決定する、
ステップをさらに備えたことを特徴とする請求項9に記載の通信方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007045242A JP2008211443A (ja) | 2007-02-26 | 2007-02-26 | 通信システム及び通信方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2007045242A JP2008211443A (ja) | 2007-02-26 | 2007-02-26 | 通信システム及び通信方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2008211443A true JP2008211443A (ja) | 2008-09-11 |
Family
ID=39787385
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2007045242A Pending JP2008211443A (ja) | 2007-02-26 | 2007-02-26 | 通信システム及び通信方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2008211443A (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2013021689A (ja) * | 2011-07-07 | 2013-01-31 | Hitachi Ltd | 制御装置および制御方法 |
JP5803911B2 (ja) * | 2010-06-17 | 2015-11-04 | 日本電気株式会社 | 経路制御装置及び経路制御方法 |
WO2024024051A1 (ja) * | 2022-07-28 | 2024-02-01 | 日本電信電話株式会社 | 無線通信システム、通信経路制御装置、通信経路制御方法および通信経路制御用プログラム |
WO2024057392A1 (ja) * | 2022-09-13 | 2024-03-21 | 日本電信電話株式会社 | ルーティング情報生成装置、ルーティング情報生成方法、および、ルーティング情報生成プログラム |
-
2007
- 2007-02-26 JP JP2007045242A patent/JP2008211443A/ja active Pending
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5803911B2 (ja) * | 2010-06-17 | 2015-11-04 | 日本電気株式会社 | 経路制御装置及び経路制御方法 |
JP2013021689A (ja) * | 2011-07-07 | 2013-01-31 | Hitachi Ltd | 制御装置および制御方法 |
WO2024024051A1 (ja) * | 2022-07-28 | 2024-02-01 | 日本電信電話株式会社 | 無線通信システム、通信経路制御装置、通信経路制御方法および通信経路制御用プログラム |
WO2024057392A1 (ja) * | 2022-09-13 | 2024-03-21 | 日本電信電話株式会社 | ルーティング情報生成装置、ルーティング情報生成方法、および、ルーティング情報生成プログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4807701B2 (ja) | 移動端末装置、制御方法及び移動通信システム | |
US7768989B2 (en) | Method and apparatus for multipoint voice operation in a wireless, Ad-Hoc environment | |
US7457304B2 (en) | Method for service discovery in mobile ad-hoc network | |
JP4714274B2 (ja) | 複数の無線を用いて無線通信ネットワークの容量を増加させるためのシステムおよび方法 | |
KR100940948B1 (ko) | 무선 네트워크에서의 접속 파라미터들을 조정하기 위한시스템 및 방법 | |
TWI404372B (zh) | 於無線多重跳頻中繼通信系統中多點傳播分佈樹的建立及維護 | |
US8971231B2 (en) | Systems and methods for mobile communications | |
US7894378B2 (en) | Method for updating a multicast state of a multicast group | |
WO2010044187A1 (ja) | 通信端末及び通信方法 | |
US9014051B2 (en) | Updating multicast group information of a client device of a wireless mesh network | |
CN101478474B (zh) | 跨域建立mpls te lsp的方法、装置和*** | |
WO2007048349A1 (en) | Multi-hop routing method with bandwidth reservation in wireless network | |
KR20130108250A (ko) | 멀티-홉 무선 홈 네트워크에서 대역폭 인식 라우팅을 채널 선택 및 채널 스위칭과 결합 | |
JP4689630B2 (ja) | 通信端末及び通信制御方法 | |
JP2008211443A (ja) | 通信システム及び通信方法 | |
KR101481428B1 (ko) | 이동 애드 혹 네트워크의 라우팅 방법 및 장치 | |
EP2482589B1 (en) | Method and system for flooding and multicast routing in an AD-HOC network | |
JP5029131B2 (ja) | 移動端末装置、制御方法および移動通信システム | |
JP4357321B2 (ja) | パケット伝送装置およびプログラム | |
CN106211255A (zh) | 一种无线自组网网络层和mac层的联合优化方法 | |
JP3888536B2 (ja) | アドホック網のルーティング方法 | |
JP2007274658A (ja) | 移動制御ネットワークシステム、ルータ及び移動端末 | |
CN110996269B (zh) | 一种基于令牌环的无线自组网QoS增强应用方法 | |
Pei et al. | Distributed flow admission control for multimedia services over wireless ad hoc networks | |
JP4421419B2 (ja) | 移動局、基地局及びこれらを備えた無線通信システム、並びに、移動局の基地局接続方法、基地局の移動局管理方法、これらを実行させるためのプログラム及びこのプログラムを記録した記録媒体 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20100426 |