JP4904396B2 - ルート発見プロシージャのための拡張ルート要求メッセージの発生方法および拡張ルート応答メッセージの発生方法 - Google Patents
ルート発見プロシージャのための拡張ルート要求メッセージの発生方法および拡張ルート応答メッセージの発生方法 Download PDFInfo
- Publication number
- JP4904396B2 JP4904396B2 JP2009519947A JP2009519947A JP4904396B2 JP 4904396 B2 JP4904396 B2 JP 4904396B2 JP 2009519947 A JP2009519947 A JP 2009519947A JP 2009519947 A JP2009519947 A JP 2009519947A JP 4904396 B2 JP4904396 B2 JP 4904396B2
- Authority
- JP
- Japan
- Prior art keywords
- node
- mesh
- destination
- source
- connection
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
- H04W40/246—Connectivity information discovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
- H04W40/20—Communication route or path selection, e.g. power-based or shortest path routing based on geographic position or location
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
- H04W40/28—Connectivity information management, e.g. connectivity discovery or connectivity update for reactive routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/26—Network addressing or numbering for mobility support
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Description
本発明は、IEEE802コネクションのソースノードからIEEE802コネクションの宛先ノードに至るルートに対してルート発見するための拡張ルート要求メッセージの発生方法、および拡張ルート応答メッセージの発生方法に関するものである。このルートは、メッシュパスのソースノードとメッシュパスの宛先ノードを備えるメッシュネットワークパスを含む。本発明はまた、拡張ルール要求メッセージおよび拡張ルート応答メッセージに関するものである。最後に本発明はまた、メッシュネットワークにおける第１ノードおよび第２ノードに関するものである。
タスクグループ IEEE 802.11s(IEEE - Institute of Electrical & Electronics Engineers)は、OSIレイヤ2(OSI - Open Systems Interconnection)におけるWLANメッシュネットワーキング(WLAN - Wireless Local Area Network)のための規格を定義する。IEEE 802.11sメッシュを備えるネットワークのためのネットワーク構造が図１に示されている。すべてのノードは１つのIPホップ内に存在することができる(IP -Internet Protocol)。すなわちフレームを、ネットワークの任意の部分の任意のノードから、宛先のMACアドレス(MAC - Media Access Control)だけに基づいてネットワークの任意の部分の他の任意のノードに送信することができる。IPでは、IPアドレスがネットワーク構造も記述するが、IPとは異なりMACアドレスはリアルインタフェースID(ID - identification)であり、ネットワーク構造に関する付加的情報を備えていない。より詳細には、MACアドレスは、そのMACアドレスとのインタフェースが(LAN -Local Area Network)に配置されているのか、WLANメッシュに配置されていのか、または「WLANセル」に配置されているのかについての糸口を与えない。
WLANメッシュネットワークは、特別のルーティングプロトコルまたはパス選択プロトコルを、ネットワーク全体におけるそのWLANメッシュネットワーク部分内に展開する。すなわち、そこにはメッシュソースノードとメッシュ宛先ノードが存在しなければならない。図１に示されたネットワークアーキテクチャに関しては、WLANメッシュメットワークとの関連で３つのネスト「コネクション」が示されている。すなわち、
・ワイヤレスリンク：無線信号の送信機とこの無線信号の受信機により規定される実際のワイヤレスリンク。
・メッシュパス：このパスは、WLANメッシュネットワークを通り、メッシュソースノード/メッシュ入口からメッシュ宛先ノード/メッシュ出口に至る。メッシュソースノードおよびメッシュ宛先ノードは、フレームがWLANメッシュに入るノード、および去るノードである。メッシュパスは、１つまたは複数のワイヤレスリンクからなる。
・802コネクション/レイヤ2コネクション：このコネクションは、上記ネットワーク(図１)の任意の部分からのソースMACアドレスと宛先MACアドレスにより記述される。通常、ソースMACアドレスは、IPパケットがレイヤ2に入るインタフェースのMACアドレスであり、宛先MACアドレスは、レイヤ2フレームがIPレイヤに戻されるインタフェースのMACアドレスである。802コネクション/レイヤ2コネクションは、１つまたは複数のメッシュパスを含むことができる。または802コネクション/レイヤ2コネクションは、メッシュパスと同じであっても良い。
・ワイヤレスリンク：無線信号の送信機とこの無線信号の受信機により規定される実際のワイヤレスリンク。
・メッシュパス：このパスは、WLANメッシュネットワークを通り、メッシュソースノード/メッシュ入口からメッシュ宛先ノード/メッシュ出口に至る。メッシュソースノードおよびメッシュ宛先ノードは、フレームがWLANメッシュに入るノード、および去るノードである。メッシュパスは、１つまたは複数のワイヤレスリンクからなる。
・802コネクション/レイヤ2コネクション：このコネクションは、上記ネットワーク(図１)の任意の部分からのソースMACアドレスと宛先MACアドレスにより記述される。通常、ソースMACアドレスは、IPパケットがレイヤ2に入るインタフェースのMACアドレスであり、宛先MACアドレスは、レイヤ2フレームがIPレイヤに戻されるインタフェースのMACアドレスである。802コネクション/レイヤ2コネクションは、１つまたは複数のメッシュパスを含むことができる。または802コネクション/レイヤ2コネクションは、メッシュパスと同じであっても良い。
図１は、上記のことを例として示し、これにより短縮されたMACアドレスが使用される。図１は、有線LAN NET1、WLANメッシュネットワーク NET2、およびWALNセル NET3を示す。メッシュノードは楕円で示されており、参照符合A-Hを使用する。データフレームを、LAN部分にあるMACアドレス27:45のノードX1から、MACアドレスe3:33の非メッシュ局STAに、WLANメッシュを経由して送信しなければならない。これは、802コネクション/レイヤ2コネクションである。パケットがWLANメッシュを通過するこのメッシュパスは、メッシュソースとしてMACアドレス21:e5を備えるメッシュノードVと、メッシュ宛先としてMACアドレス37:faを備えるメッシュノードEを有する。MACアドレス12:faを備えるメッシュノードGがデータフレームを転送しなければならない場合、ワイヤレスリンクは、MACアドレス12:faの送信機とMACアドレス72:54の受信機Dにより記述される。
６つすべてのMACアドレスは、上記のように異なっているから、メッシュデータフレームは６つのMACアドレスをいくつかの場合でサポートしなければならない。現在のメッシュフレームフォーマットは、[1]での定義のように４つのMACアドレスを有する：すなわち、ワイヤレスリンクに対する２つと、メッシュパスまたはソースと宛先に対する２つである。６つのMACアドレスを使用するためのスキームは[2]から公知である。これによれば、MACアドレス1と2がワイヤレスリンクに対するものであり、MACアドレス3と4がメッシュパスに対するものであり、MACアドレス5と6が802コネクションに対するものである。MACアドレス5と6は、メッシュパスと802コネクションが一致する場合、省略することができる。図１の付加的な参照符合は次の機能を表わす。
「11」 (非IEEE 802.11)有線LAN、例えばツリー構造に広がるイーサネット。
「12」 WLANメッシュ ad hocルーティング。
「13」 MAPとSTAとの間の通信接続を備えるWLANセル(標準ワイヤレスIEEE 802.11通信接続)。
「14」 NET1に配置することのできるDHCPサーバ(DHCP - Dynamic Host Configuration Protocol)。
「15」 IPベースのパケットを他のIPベースのネットワークにルーティングするための、NET1に配置することのできるIPルータ(IP-Internet Protocol)。
「16」 IPサブネット。
「11」 (非IEEE 802.11)有線LAN、例えばツリー構造に広がるイーサネット。
「12」 WLANメッシュ ad hocルーティング。
「13」 MAPとSTAとの間の通信接続を備えるWLANセル(標準ワイヤレスIEEE 802.11通信接続)。
「14」 NET1に配置することのできるDHCPサーバ(DHCP - Dynamic Host Configuration Protocol)。
「15」 IPベースのパケットを他のIPベースのネットワークにルーティングするための、NET1に配置することのできるIPルータ(IP-Internet Protocol)。
「16」 IPサブネット。
IEEE 802.11sの現在のドラフトは、HWMPにあるメッシュパスと802コネクションとの間のマッピングを確定するのにさほど明確ではない。さらに、この問題が十分に考慮されているとは思えない。一般的思想は、メッシュ入口/メッシュ出口が、非メッシュノードの代わりにルーティングメッセージを発生し、管理することである。このことは、非メッシュノードは仮想的にメッシュノードとなるが、ルーティングメッセージの処理は、非メッシュノードの代わりに、真のメッシュノードによって実行されることを意味する。非メッシュノードのMACアドレスはメッシュ内では既知となり、ルーティングすることができる。このコンセプトは、WLAN局のコネクション(図１のSAT)に対して、[1]のセクション11A.4.3.1.4.2 (78頁)に記述されている。これは有線LANに接続されたメッシュポータルに容易に拡張することができる。
刊行物[3]は、ルート要求(RREQ)とルート応答(RREP)のメッセージスキームを、例えば図１の局Gであるメッシュノードと、非メッシュ局またはルーティング不能デバイスをサポートするために提案している。非メッシュ局は、[1]の6頁ではSTA(STA = stations)と呼ばれる。これらの局は、アクセスポイント(AP)をサポートする特定のメッシュノードによって管理される。[3]で発信デバイスのMACアドレスはRREQメッセージに含まれる。これによりこのMACアドレスは、例えばメッシュノードのようなルーティング可能デバイスのアドレス、またはルーティング不能デバイスアドレスとなる。前者は、トラフィックがメッシュノード自体に宛てられたものである場合であり、後者は、トラフィックがルーティング不能デバイスに宛てられたものである場合である。ルーティング不能デバイスは例えばSTAであり、一般的に自身によりプロキシーされる。[3]で発信デバイスのMACアドレスはRREQメッセージに含まれる。これによりこのMACアドレスは、例えばメッシュノードのようなルーティング可能デバイスのアドレス、またはルーティング不能デバイスアドレスとなる。前者は、トラフィックがメッシュノード自体に宛てられたものである場合であり、後者は、トラフィックがルーティング不能デバイスに宛てられたものである場合である。ルーティング不能デバイスは例えばSTAであり、一般的に自身によりプロキシーされる。
しかし現在の提案はいずれも、メッシュ入口とメッシュ出口との間でマッピングを確立するためのメカニズムを完全にはサポートしない。とりわけ、AODV[2]およびHWMPで使用されるような応答ルート発見に対して定義されたメカニズムは存在しない。HWMPは、IEEE 802.11sのデフォルトルーティングプロトコルである[1]。
IEEE P802.11s(TM)/D0.02, Draft amendment to standard IEEE 802.11 : ESS Mesh Networking. IEEE, June 2006, http://grouper.ieee.org/groups/802/11
Chu et. al., "Extension to 6-Address Scheme for TGs Mesh", 26.06.2006, document number IEEE 802.11-06/841rl
Gossain et. al., "Packet forwarding for non-routable devices in Multi-hop Wireless Mesh", 15.05.2006, document number IEEE 802.11-06/0661r0
したがって本発明の課題は、メッシュノードのようなルーティング可能デバイスと、局STAおよびIEEE 802.11デバイスのようなすべての形式のルーティング不能デバイスの両方を、応答ルート発見のためにサポートし、要求されるシグナリングオーバヘッドを最小にする方法および装置を提供することである。
この課題は、独立請求項によって解決される。従属請求項は、本発明の改善を開示する。
本発明は、IEEE802コネクションのソースノードからIEEE802コネクションの宛先ノードに至るルートに対してルート発見するための拡張ルート要求メッセージの発生方法に関するものであり、このルートは、メッシュパスのソースノードとメッシュパスの宛先ノードを備えるメッシュネットワークパスを含む。この方法は、
・IEEE 802コネクションのソースノードがメッシュネットワーク内にあるか、外にあるかを決定するステップ；
・IEEE 802コネクションのソースノードがメッシュネットワーク内にあるノードである場合、次のような拡張ルート要求メッセージを発生し、
すなわち前記拡張ルート要求メッセージは、メッシュパスのソースノードの１つのソースアドレスとフラグを含んでおり、該フラグは、拡張ルート要求メッセージが前記１つのソースアドレスをカバーすることを指示するステップ；
・IEEE 802コネクションのソースノードがメッシュネットワーク外にあるノードである場合、次のような拡張ルート要求メッセージを発生し、
すなわち前記拡張ルート要求メッセージは、２つのソースアドレスとフラグを含んでおり、
前記２つのソースアドレスは、(a)メッシュパスのソースノードのソースアドレスと、(b)IEEE 802コネクションのソースノードのソースアドレスをカバーし、
前記フラグは、拡張ルート要求メッセージが前記２つのソースアドレスをカバーすることを指示するステップ；
を有する。
・IEEE 802コネクションのソースノードがメッシュネットワーク内にあるか、外にあるかを決定するステップ；
・IEEE 802コネクションのソースノードがメッシュネットワーク内にあるノードである場合、次のような拡張ルート要求メッセージを発生し、
すなわち前記拡張ルート要求メッセージは、メッシュパスのソースノードの１つのソースアドレスとフラグを含んでおり、該フラグは、拡張ルート要求メッセージが前記１つのソースアドレスをカバーすることを指示するステップ；
・IEEE 802コネクションのソースノードがメッシュネットワーク外にあるノードである場合、次のような拡張ルート要求メッセージを発生し、
すなわち前記拡張ルート要求メッセージは、２つのソースアドレスとフラグを含んでおり、
前記２つのソースアドレスは、(a)メッシュパスのソースノードのソースアドレスと、(b)IEEE 802コネクションのソースノードのソースアドレスをカバーし、
前記フラグは、拡張ルート要求メッセージが前記２つのソースアドレスをカバーすることを指示するステップ；
を有する。
この方法は、拡張ルート要求メッセージをIEEE 802コネクションのソースノードの位置に依存して発生する。したがって拡張ルート要求メッセージを伝送するための伝送帯域幅、すなわちシグナリングオーバヘッドは、IEEE 802コネクションのソースノードの位置に依存して最適化される。なぜなら、IEEE 802コネクションのソースノードがメッシュネットワーク内のノードに由来するものである場合、拡張ルート要求メッセージはただ１つのソースアドレスしかカバーせず、それ以外の場合に２つのソースアドレスをカバーするからである。加えて、フラグを使用することにより、伝送のために固定帯域幅が使用される場合にはルート要求メッセージの伝送が高速化される。なぜならこのフラグは、１つのソースアドレスだけが伝送されるか、または２つのソースアドレスが伝送されるかを指示するからであり、常に２つのソースアドレスを伝送しなければならない場合と比較して高速化される。
前記方法の拡張では、メッシュパスのソースノードがメッシュノードに割り当てられる。このメッシュノードは、メッシュネットワークの入口ノード、メッシュアクセスポイント、またはメッシュポータルを表わし、IEEE 802コネクションのソースノードがメッシュネットワーク外のノードから由来する場合、IEEE 802コネクションのソースノードをアドレシングする。
この割り当ては、IEEE 802コネクションのソースノードがメッシュネットワーク外のノードから由来する場合に、メッシュネットワーク内でのソースアドレスの正しいマッピングをサポートする。加えてこの割り当てにより、ルート応答メッセージが、メッシュネットワークにあるメッシュパスのソースノードへの正しい道を発見することができるようになる。さらにこの拡張により、ルート要求メッセージとルート応答メッセージのスムーズな操作が、そのノードがメッシュネットワーク内にあるか、外にあるかに関係なく保証される。
本発明はまた、IEEE802コネクションのソースノードからIEEE802コネクションの宛先ノードに至るルートに対してルート発見するための拡張ルート応答メッセージの発生方法に関するものであり、このルートは、メッシュパスのソースノードとメッシュパスの宛先ノードを備えるメッシュネットワークパスを含む。この方法は、
・IEEE 802コネクションの宛先ノードがメッシュネットワーク内にあるか、外にあるかを決定するステップ；
・IEEE 802コネクションの宛先ノードがメッシュネットワーク内からのノードである場合、次のような拡張ルート応答メッセージを発生し、
すなわち前記拡張ルート応答メッセージは、メッシュパスの宛先ノードの１つの宛先アドレスとフラグを含んでおり、前記フラグは、拡張ルート応答メッセージが前記１つの宛先アドレスをカバーすることを指示するステップ；
・IEEE 802コネクションの宛先ノードがメッシュネットワーク外からのノードである場合、次のような拡張ルート応答メッセージを発生し、
すなわち前記拡張ルート応答メッセージは、２つの宛先アドレスとフラグを含んでおり、
前記２つの宛先アドレスは、(a)メッシュパスの宛先ノードの宛先アドレスと、(b)IEEE 802コネクションの宛先ノードの宛先アドレスをカバーし、
前記フラグは、拡張ルート応答メッセージが前記２つの宛先アドレスをカバーすることを指示するステップ；
を有する。
・IEEE 802コネクションの宛先ノードがメッシュネットワーク内にあるか、外にあるかを決定するステップ；
・IEEE 802コネクションの宛先ノードがメッシュネットワーク内からのノードである場合、次のような拡張ルート応答メッセージを発生し、
すなわち前記拡張ルート応答メッセージは、メッシュパスの宛先ノードの１つの宛先アドレスとフラグを含んでおり、前記フラグは、拡張ルート応答メッセージが前記１つの宛先アドレスをカバーすることを指示するステップ；
・IEEE 802コネクションの宛先ノードがメッシュネットワーク外からのノードである場合、次のような拡張ルート応答メッセージを発生し、
すなわち前記拡張ルート応答メッセージは、２つの宛先アドレスとフラグを含んでおり、
前記２つの宛先アドレスは、(a)メッシュパスの宛先ノードの宛先アドレスと、(b)IEEE 802コネクションの宛先ノードの宛先アドレスをカバーし、
前記フラグは、拡張ルート応答メッセージが前記２つの宛先アドレスをカバーすることを指示するステップ；
を有する。
この方法は、拡張ルート応答メッセージをIEEE 802コネクションの宛先ノードの位置に依存して発生する。したがって拡張ルート応答メッセージを伝送するための伝送帯域幅、すなわちシグナリングオーバヘッドは、IEEE 802コネクションの宛先ノードの位置に依存して最適化される。なぜなら、IEEE 802コネクションの宛先ノードがメッシュネットワーク内のノードに由来するものである場合、拡張ルート応答メッセージはただ１つの宛先アドレスしかカバーせず、それ以外の場合に２つの宛先アドレスをカバーするからである。加えて、フラグを使用することにより、伝送のために固定帯域幅が使用される場合にはルート応答メッセージの伝送が高速化される。なぜならこのフラグは、１つの宛先アドレスだけが伝送されるか、または２つの宛先アドレスが伝送されるかを指示するからであり、常に２つの宛先アドレスを伝送しなければならない場合と比較して高速化される。
前記方法の拡張では、メッシュパスの宛先ノードがメッシュノードに割り当てられる。このメッシュノードは、メッシュネットワークの出口ノード、メッシュアクセスポイント、またはメッシュポータルを表わし、IEEE 802コネクションの宛先ノードがメッシュネットワーク外のノードから由来する場合、IEEE 802コネクションの宛先ノードをアドレシングする。
この割り当ては、IEEE 802コネクションの宛先ノードがメッシュネットワーク外のノードから由来する場合に、メッシュネットワーク内での宛先アドレスの正しいマッピングをサポートする。加えてこの割り当てにより、フレームが、メッシュネットワーク外のノードへの正しい道をメッシュ宛先により発見することができるようになる。さらにこの拡張により、ルート要求メッセージとルート応答メッセージのスムーズな操作が、そのノードがメッシュネットワーク内にあるか、外にあるかに関係なく保証される。
前記方法の１つは、WLANを、IEEE802.11規格に基づきメッシュネットワークに割り当てることによって拡張することができる。したがって前記方法は、WLANがIEEE 802.11規格により規定されていても使用することができる。
本発明の方法の拡張では、局が、IEEE 802.11規格および/またはIEEE 802.3規格に基づき、IEEE 802コネクションのソースノードまたは宛先ノードに割り当てられる。この拡張により、局を、IEEE 802.11規格および/またはIEEE 802.3規格に基づき実現された上記方法によってサポートすることができる。
本発明はまた、IEEE802コネクションのソースノードからIEEE802コネクションの宛先ノードに至るルートに対してルート発見のために使用される拡張ルート要求メッセージに関するものであり、このルートは、メッシュパスのソースノードとメッシュパスの宛先ノードを備えるメッシュネットワークパスを含む。この拡張ルート要求メッセージは、
・IEEE 802コネクションのソースノードがメッシュネットワーク内にあるノードである場合、メッシュパスのソースノードの１つのソースアドレスと、フラグを有し、
該フラグは、拡張ルート要求メッセージが前記１つのソースアドレスをカバーすることを指示し；
・IEEE 802コネクションのソースノードがメッシュネットワーク外にあるノードである場合、前記拡張ルート要求メッセージは、２つのソースアドレスとフラグを有し、
前記２つのソースアドレスは、(a)メッシュパスのソースノードのソースアドレスと、(b)IEEE 802コネクションのソースノードのソースアドレスをカバーし、
前記フラグは、拡張ルート要求メッセージが前記２つのソースアドレスをカバーすることを指示する。
・IEEE 802コネクションのソースノードがメッシュネットワーク内にあるノードである場合、メッシュパスのソースノードの１つのソースアドレスと、フラグを有し、
該フラグは、拡張ルート要求メッセージが前記１つのソースアドレスをカバーすることを指示し；
・IEEE 802コネクションのソースノードがメッシュネットワーク外にあるノードである場合、前記拡張ルート要求メッセージは、２つのソースアドレスとフラグを有し、
前記２つのソースアドレスは、(a)メッシュパスのソースノードのソースアドレスと、(b)IEEE 802コネクションのソースノードのソースアドレスをカバーし、
前記フラグは、拡張ルート要求メッセージが前記２つのソースアドレスをカバーすることを指示する。
改善実施形態で、前記拡張ルート要求メッセージは、メッシュパスのソースノードをメッシュノードに割り当てる。このメッシュノードは、メッシュネットワークの入口ノード、メッシュアクセスポイント、またはメッシュポータルを表わし、IEEE 802コネクションのソースノードがメッシュネットワーク外のノードから由来する場合、IEEE 802コネクションのソースノードをアドレシングする。
この拡張ルート要求メッセージは、これらのメッセージを発生する方法と同じ利点を有する。
加えて本発明はまた、IEEE802コネクションのソースノードからIEEE802コネクションの宛先ノードに至るルートに対してルート発見するための拡張ルート応答メッセージに関するものであり、このルートは、メッシュパスのソースノードとメッシュパスの宛先ノードを備えるメッシュネットワークパスを含む。この拡張ルート応答メッセージは、
・IEEE 802コネクションの宛先ノードがメッシュネットワーク内にあるノードである場合、メッシュパスの宛先ノードの１つの宛先アドレスと、フラグを有し、
該フラグは、拡張ルート応答メッセージが前記１つの宛先アドレスをカバーすることを指示し；
・IEEE 802コネクションの宛先ノードがメッシュネットワーク外にあるノードである場合、前記拡張ルート応答メッセージは、２つの宛先アドレスとフラグを有し、
前記２つの宛先アドレスは、(a)メッシュパスの宛先ノードの宛先アドレスと、(b)IEEE 802コネクションの宛先ノードの宛先アドレスをカバーし、
前記フラグは、拡張ルート応答メッセージが前記２つの宛先アドレスをカバーすることを指示する。
・IEEE 802コネクションの宛先ノードがメッシュネットワーク内にあるノードである場合、メッシュパスの宛先ノードの１つの宛先アドレスと、フラグを有し、
該フラグは、拡張ルート応答メッセージが前記１つの宛先アドレスをカバーすることを指示し；
・IEEE 802コネクションの宛先ノードがメッシュネットワーク外にあるノードである場合、前記拡張ルート応答メッセージは、２つの宛先アドレスとフラグを有し、
前記２つの宛先アドレスは、(a)メッシュパスの宛先ノードの宛先アドレスと、(b)IEEE 802コネクションの宛先ノードの宛先アドレスをカバーし、
前記フラグは、拡張ルート応答メッセージが前記２つの宛先アドレスをカバーすることを指示する。
拡張実施形態で前記拡張ルート応答メッセージは、メッシュパスの宛先ノードをメッシュノードに割り当てる。このメッシュノードは、メッシュネットワークの出口ノード、メッシュアクセスポイント、またはメッシュポータルを表わし、IEEE 802コネクションの宛先ノードがメッシュネットワーク外のノードから由来する場合、IEEE 802コネクションの宛先ノードをアドレシングする。
この拡張ルート応答メッセージは、これらのメッセージを発生する方法と同じ利点を有する。
さらに本発明はまた、メッシュネットワークにある第１のノードに関するものである。この第１のノードは、拡張ルート応答メッセージおよび/または拡張ルート要求メッセージを前記方法の１つにしたがい発生する第１の手段を有する。
この第１の手段によって、拡張ルート応答メッセージおよび/または拡張ルート要求メッセージを発生することができる。
最後に、メッシュネットワークにある第２のノードは本発明の一部であり、拡張ルート応答メッセージおよび/または拡張ルート要求メッセージを評価する第２の手段を有する。これによりこれらのメッセージは上記のようにセットアップされる。この第２の手段は、拡張ルート要求メッセージを分析し、１つまたは２つのソースアドレスを、このメッセージのフラグに依存して読み出すことができる。この第２の手段は、拡張ルート応答メッセージを分析し、１つまたは２つの宛先アドレスを、このメッセージのフラグに依存して読み出すことができる。
本発明は、MAP(MAP - Mesh Access Point)および/またはMPP(MPP - Mesh Portal)により実現し、実行することができる。
第１および/または第２の手段はソフトウエアによって、ハードウエアによって、またはソフトウエアとハードウエアの組合わせによって実現することができ、例えばマイクロコントローラ上で実行される。
本発明とその拡張実施形態を、複数の図面を用いて説明する。
同じ機能および同じ動作モードを備えるエレメントには同じ参照符合が付してある。
図１は冒頭にすでに説明した。６つすべてのMACアドレスは、図１に示すように異なっているから、メッシュデータフレームは６つのMACアドレスをいくつかの場合でサポートしなければならない。６つのMACアドレスを使用するためのスキームは[2]から公知である。これによれば、MACアドレス1と2がワイヤレスリンクに対するものであり、MACアドレス3と4がメッシュパスに対するものであり、MACアドレス5と6が802コネクションに対するものである。MACアドレス5と6は、メッシュパスと802コネクションが一致する場合、省略することができる。本明細書で「802」とは、あらゆる種類のノード、すなわちメッシュネットワーク内のメッシュノード、非メッシュノード/ルート不能ノードを表わすものであり、例えばSTA(STA - stations、[1]参照)および非IEEE 802.11ノード、例えばIEEE 802.3ノードである。加えて用語「デバイス」と「ノード」は同義に使用される。メッシュパスは、WLANメッシュネットワーク内のパスである。802コネクションは、802ノード/デバイスから802ノードへのパスであり、メッシュネットワーク内および/または外にあるパス部分を含む。
HWMP [1] (HWMP - Hybrid Wireless Mesh Protocol)の現在のルート発見プロセスが、メッシュパスと802コネクションとの間の関係が維持され、かつ６つの使用可能アドレスに正しくマッピングされるように拡張される。基本思想は、ルート発見のメッセージ(ルート要求メッセージおよびルート応答メッセージ)をMACアドレスの付加的フィールドにより拡張し、ソースと宛先を802コネクションとメッシュパスの両方でユニークに識別できるようにすることである。802コネクションおよびとメッシュパスのソースと宛先との間のマッピングは、リストまたはテーブルでメッシュノードに記憶することができる。この情報は、メッシュ入口ノードおよびメッシュ出口ノードに、例えば図１のメッシュノードEとVに記憶すれば十分である。オプションとして中間メッシュノードも、このマッピング情報をそれらの相応のリストまたはテーブルに記憶することができる。このことは、いくつかのルート発見を不要にするが、これらエントリーの保守を必要とする。例えば、メッシュアクセスポイントからの局STAの解離は、マッピング deassociated_STA-MAP (MAP - Mesh Access. Point)をそれらのリストまたはテーブルに有するすべてのメッシュノードに送信しなければならない。アクセスポイント(AP-access point)を備えるメッシュノードMAPが、１つまたは複数のSTAの接続のために使用される。図１のメッシュノードEを参照。
メッシュ入口またはメッシュ出口として動作することのできる各メッシュノードは、次の２つのマッピングリストを維持する：
・１つは入口リストであり、ここで802コネクションの特定宛先のためにメッシュ宛先アドレスが決定される。
・もう１つは出口リストであり、ここにはメッシュ宛先ノード(メッシュ出口)として動作することのできるメッシュノードのために802コネクションの宛先が記憶されている。
・１つは入口リストであり、ここで802コネクションの特定宛先のためにメッシュ宛先アドレスが決定される。
・もう１つは出口リストであり、ここにはメッシュ宛先ノード(メッシュ出口)として動作することのできるメッシュノードのために802コネクションの宛先が記憶されている。
一般的に、拡張ルート発見は、本願発明では次のように動作する。
S802conn 802コネクションのソースノード
D802conn 802コネクションの宛先ノード
Smesh メッシュパスのソースノード
Dmesh メッシュパスの宛先ノード。
S802conn 802コネクションのソースノード
D802conn 802コネクションの宛先ノード
Smesh メッシュパスのソースノード
Dmesh メッシュパスの宛先ノード。
メッシュノードMはフレームを、メッシュ外のノードEEから受信する。このフレームを、D802connに転送しなければならない。Mはフレームを非メッシュノードEEに転送することができるから、MはEEのMACアドレスをその出口リストに追加する。MがD802connへの有効なパスを有しておらず、入口リストからD802connに対するDmeshを引き出すこともできないとすると、MはD802connに対するルート発見を開始しなければならない。Mは、２つのMACソースアドレス、すなわちSmeshとS802connを備えるルート要求メッセージRREQを発生する。メッシュノードMは、自分のMACアドレスMAC(M)を、RREQのSmeshに対するフィールドに挿入し、S802connに対するフィールドのMAC値を受信したフレームから取り出す。
RREQはすべてのメッシュネットワークに同報送信され、したがってメッシュノードN1はこれを受信する。RREQを受信するすべてのメッシュノードは、S802connとSmeshのペアを自分の入口リストに追加する。
メッシュノードN1は、D802connであると仮定する(802宛先はメッシュネットワーク内にある)。メッシュノードN1はS802connとSmeshのペアを自分の入口リストに追加し、[1]に定義されるように通常のようにルート応答メッセージを発生する。このルート応答メッセージは、メッシュノードMであるSmeshに送信される。
D802connがメッシュの外にあり、メッシュノードPはその出口リストからフレームをD802connに転送できることを知っていると仮定する。メッシュノードPはS802connとSmeshのペアを自分の入口リストに追加し、ルート応答メッセージを発生する。このルート応答メッセージで起源/ソースアドレスはSmeshであり、２つの宛先アドレスを備えている。１つの宛先アドレスはDmeshであり、もう１つはD802connである。このルート応答メッセージは、メッシュノードMであるSmeshに送信される。
最後にメッシュノードMは、ルート応答をD802connから受信する。このルート応答がDmeshとD802connに対して別個のアドレスを含んでいれば、MはD802connとDmeshのペアをその入口リストに挿入する。この例でDmeshはPである。なぜならD802connはメッシュネットワークNET2の外にあるからである。
こうしてD802connに対してバッファされたパケットを、新たに形成されたパスでDmeshに転送することができる。
D802connがメッシュの外にある場合に、D802connに宛てられた後続のフレームに対しては、メッシュ入口Mが自分の入口リスト中にD802connに対するエントリーを見つけることになる。これによりメッシュデータフレーム中で６つのアドレスが使用されるようになる。
ここで、
Smsh=M
Dmesh=P、入口リストのエントリーから引き出される
S802connは受信されたフレームから取り出される
D802connは受信されたフレームから取り出される。
Smsh=M
Dmesh=P、入口リストのエントリーから引き出される
S802connは受信されたフレームから取り出される
D802connは受信されたフレームから取り出される。
拡張ルート要求メッセージ(eRREQ)ではソースMACアドレスが拡張されており、このソースMACアドレスは、メッシュソースアドレスと802コネクションのソースアドレスからなる。
このようにするには２つの手段がある：
・802コネクションのソースアドレスがメッシュソースアドレスと一致しても、常に２つのMACアドレスを使用する。このように拡張されたHWMP RREQの構造が図２に示されている。
・１つのソースMACアドレスが使用されるか(802コネクションのソースアドレスとメッシュソースアドレスが一致する場合)、または２つのソースMACアドレスが使用されるか(802コネクションのソースアドレスとメッシュソースアドレスが異なる場合)を指示するフラグを使用する。このように拡張されたHWMP RREQの構造が図３に示されている。
・802コネクションのソースアドレスがメッシュソースアドレスと一致しても、常に２つのMACアドレスを使用する。このように拡張されたHWMP RREQの構造が図２に示されている。
・１つのソースMACアドレスが使用されるか(802コネクションのソースアドレスとメッシュソースアドレスが一致する場合)、または２つのソースMACアドレスが使用されるか(802コネクションのソースアドレスとメッシュソースアドレスが異なる場合)を指示するフラグを使用する。このように拡張されたHWMP RREQの構造が図３に示されている。
この例でのeRREQメッセージのフィールドの機能が図２と３に示されており、以下の参照符合を使用して説明する。これらの参照符合は刊行物[1-3]から由来するものである：
21 エレメントID
22 長さ
23 フラグ
24 TTL(Time-To-Live)
25 宛先カウントN
26 ホップカウント
27 RREQ ID
28 メッシュソースMACアドレス
29 メッシュソース連続番号
2A 802ソースMACアドレス
2B 距離
2C 802宛先ごとのフラグ #1
2D 802宛先MACアドレス #1
2E 宛先連続番号 #1
2F 付加的フィールド
2G 802宛先ごとのフラグ #N
2H 802宛先MACアドレス #N
21 宛先連続番号 #N
2J オクテット
31 フラグ
32 802ソースMACアドレス
33 ユニキャスト/同報通信
34 リザーブ
35 別個の802ソースMACアドレス
36 リザーブ
37 ビット。
21 エレメントID
22 長さ
23 フラグ
24 TTL(Time-To-Live)
25 宛先カウントN
26 ホップカウント
27 RREQ ID
28 メッシュソースMACアドレス
29 メッシュソース連続番号
2A 802ソースMACアドレス
2B 距離
2C 802宛先ごとのフラグ #1
2D 802宛先MACアドレス #1
2E 宛先連続番号 #1
2F 付加的フィールド
2G 802宛先ごとのフラグ #N
2H 802宛先MACアドレス #N
21 宛先連続番号 #N
2J オクテット
31 フラグ
32 802ソースMACアドレス
33 ユニキャスト/同報通信
34 リザーブ
35 別個の802ソースMACアドレス
36 リザーブ
37 ビット。
802ソースMACアドレス32の長さは、フラグフィールド31の第6ビットから導かれる。このフラグフィールドは、フラグ6掛ける6オクテットとして記述することができ、したがいフラグ6×6である。この例でフラグ31の第6ビットは、参照符合35により示されている。フィールド「別個の802ソースMACアドレス」35は、0または1であるから、802ソースMACアドレス32の長さは0オクテットまたは6オクテットである。
拡張ルート応答メッセージeRREPでは宛先MACアドレスが拡張されており、この宛先MACアドレスは、メッシュ宛先MACアドレスと802コネクションの宛先MACアドレスからなる。802コネクションの宛先MACアドレスはルート発見が実行されるアドレスであり、メッシュ宛先MACアドレスはメッシュ出口のアドレスである。このメッシュ出口は、フレームを802コネクションの宛先に転送することができ、したがってRREQにRREPを以て応答する。
ここでも、このようにするには２つの手段がある：
・802コネクションの宛先アドレスがメッシュ宛先アドレスと一致しても、常に２つのMACアドレスを使用する。このように拡張されたHWMP RREPの構造が図４に示されている。
・１つの宛先MACアドレスが使用されるか(802コネクションの宛先アドレスとメッシュ宛先アドレスが一致する場合)、または２つの宛先MACアドレスが使用されるか(802コネクションの宛先アドレスとメッシュ宛先アドレスが異なる場合)を指示するフラグを使用する。このように拡張されたHWMP RREPの構造が図５に示されている。
・802コネクションの宛先アドレスがメッシュ宛先アドレスと一致しても、常に２つのMACアドレスを使用する。このように拡張されたHWMP RREPの構造が図４に示されている。
・１つの宛先MACアドレスが使用されるか(802コネクションの宛先アドレスとメッシュ宛先アドレスが一致する場合)、または２つの宛先MACアドレスが使用されるか(802コネクションの宛先アドレスとメッシュ宛先アドレスが異なる場合)を指示するフラグを使用する。このように拡張されたHWMP RREPの構造が図５に示されている。
この例でのeRREPメッセージのフィールドの機能が図４と５に示されており、以下の参照符合を使用して説明する。これらの参照符合は刊行物[1-3]から由来するものである：
41 エレメントID
42 長さ
43 フラグ
44 ホップカウント
45 メッシュ宛先MACアドレス
46 メッシュ宛先連続番号
47 802宛先MACアドレス
48 存続時間
49 距離
4A メッシュソースMACアドレス
4B メッシュソース連続番号
4C 非メッシュSTAカウント N
4D 非メッシュSTA MACアドレス #1
4E 非メッシュSTA連続番号
4F 付加的フィールド
4G 非メッシュSTA MACアドレス #1
4H 非メッシュSTA連続番号
2J オクテット
51 フラグ
52 802宛先MACアドレス
53 リザーブ
54 別個の802宛先MACアドレス
55 リザーブ
37 ビット。
41 エレメントID
42 長さ
43 フラグ
44 ホップカウント
45 メッシュ宛先MACアドレス
46 メッシュ宛先連続番号
47 802宛先MACアドレス
48 存続時間
49 距離
4A メッシュソースMACアドレス
4B メッシュソース連続番号
4C 非メッシュSTAカウント N
4D 非メッシュSTA MACアドレス #1
4E 非メッシュSTA連続番号
4F 付加的フィールド
4G 非メッシュSTA MACアドレス #1
4H 非メッシュSTA連続番号
2J オクテット
51 フラグ
52 802宛先MACアドレス
53 リザーブ
54 別個の802宛先MACアドレス
55 リザーブ
37 ビット。
802宛先MACアドレス52の長さは、フラグフィールド51の第２ビットから導かれる。このフラグフィールドは、フラグ2掛ける6オクテットとして記述することができ、したがいフラグ2×6である。この例でフラグ51の第２ビットは、参照符合54により示されている。フィールド「別個の802宛先MACアドレス」54は0または1であるから、802宛先MACアドレス52の長さは0オクテットまたは6オクテットである。
メッシュソースアドレスだけがRREPでの起源MACアドレスとして使用されれば十分である。にもかかわらず、メッシュソースアドレスと802コネクションのソースアドレスの両方をこのルート要求の発信者のアドレスとして与えることもできる。ここでも、このことは２つのやり方で行うことができる(２つに２つのアドレスを使用するか、または２つのアドレスの指示のためにフラグを使用する)。
図６は、eRREQメッセージを発生するためのフローチャートであり、この発生は802コネクションのソースノードS802connのソースMACアドレスに依存して行われる。このフローチャートはステップSTAでスタートする。第１ステップS1でメッシュノードが、802コネクションのソースMACアドレスがメッシュネットワーク内のノードからのものか、または外のノードからのものかを決定する。この分析により、ステップS2参照、このソースMACアドレスがメッシュネットワーク内に起源するものであることが判明すると、ステップS3が実行される。eRREQメッセージが１つのソースMACアドレスを伴って発生され、このソースMACアドレスはメッシュノードSmeshのソースアドレスを表わす。加えて、フラグ「別個の802ソースMACアドレス」(図３の参照符合35)がセットされ、このフラグは発生されたeRREQメッセージが１つのソースアドレス、すなわちメッシュノードソースアドレスだけをカバーすることを指示する。図３の参照符合28「メッシュソースMACアドレス」参照のこと。メッシュネットワーク外に起源する場合、ステップS4がeRREQメッセージ中に２つのソースアドレスを使用して実行される。この２つのソースアドレスは、ソースメッシュノードSmeshと、IEEE 802コネクションS802connの802ソースノードのソースアドレスである。図３の参照符合28「メッシュソースMACアドレス」と、参照符合32「802ソースMACアドレス」参照のこと。加えて、図３の参照符合35「別個の802ソースMACアドレス」を備えるフラグがセットされ、このフラグは発生されたRREQメッセージが２つのソースアドレスをカバーすることを指示する。両方のステップS3とS4は、ステップENDで終了する。
決定ステップS1は、メッシュノードにより次のプロシージャの１つによって実行することができる。
(a) 出口リストがソースノードS802connのソースMACアドレスをカバーしていれば、このソースノードはメッシュネットワークの外にある。それ以外の場合、このソースノードはメッシュネットワーク内にあると予想される。
(b) メッシュノードのMACアドレスがソースノードS802connのソースMACアドレスと等しければ、このソースノードはメッシュネットワーク内にある。それ以外の場合、このソースノードはメッシュネットワークの外にある。
(c) メッシュノードがノードS802connからのフレームを、その非メッシュ通信インタフェースの１つを通して受信すれば、このソースノードS802connはメッシュネットワークの外にある。
(a) 出口リストがソースノードS802connのソースMACアドレスをカバーしていれば、このソースノードはメッシュネットワークの外にある。それ以外の場合、このソースノードはメッシュネットワーク内にあると予想される。
(b) メッシュノードのMACアドレスがソースノードS802connのソースMACアドレスと等しければ、このソースノードはメッシュネットワーク内にある。それ以外の場合、このソースノードはメッシュネットワークの外にある。
(c) メッシュノードがノードS802connからのフレームを、その非メッシュ通信インタフェースの１つを通して受信すれば、このソースノードS802connはメッシュネットワークの外にある。
図７は、eRREPメッセージを発生するためのフローチャートであり、この発生は802コネクションの宛先ノードD802connの宛先MACアドレスに依存して行われる。このフローチャートはステップSTAでスタートする。第5ステップS5でメッシュノードが、802コネクションの宛先MACアドレスがメッシュネットワーク内のノードからのものか、または外のノードからのものかを決定する。この決定の結果(ステップS6参照)、宛先MACアドレスがメッシュネットワーク内からのものであれば、ステップS7が実行される。eRREPメッセージが１つの宛先MACアドレスを伴って発生され、この宛先MACアドレスはメッシュノードDmeshの宛先アドレスを表わす。加えて、フラグ「別個の802宛先MACアドレス」(図５の参照符合54)がセットされ、このフラグは発生されたeRREPメッセージが１つの宛先アドレス、すなわちメッシュノード宛先アドレスだけをカバーすることを指示する。図５の参照符合45「メッシュ宛先MACアドレス」参照のこと。メッシュネットワーク外に起源する場合、ステップS8がeRREPメッセージ中に２つの宛先アドレスを使用して実行される。この２つの宛先アドレスは、メッシュノードDmeshと、802宛先アドレスD802connである。図５の参照符合45「メッシュ宛先MACアドレス」と、参照符合52「802宛先MACアドレス」参照のこと。加えて、図５の参照符合54「別個の802宛先MACアドレス」を備えるフラグがセットされ、このフラグは発生されたRREPメッセージが２つの宛先アドレスをカバーすることを指示する。両方のステップS7とS8は、ステップENDで終了する。
決定ステップS5は、メッシュノードにより次のプロシージャの１つによって実行することができる。
(a) 出口リストが宛先ノードD802connの宛先MACアドレスをカバーしていれば、この宛先ノードはメッシュネットワークの外にある。それ以外の場合、この宛先ノードはメッシュネットワーク内にあると予想される。
(b) メッシュノードのMACアドレスが宛先ノードD802connの宛先MACアドレスに等しいか、またはメッシュノードがルート要求メッセージまたは拡張ルート要求メッセージに、他のメッシュノードに対する中間ノードとして応答すれば、この宛先ノードはメッシュネットワーク内にある。それ以外の場合、この宛先ノードはメッシュネットワークの外にある。
(c) メッシュノードがノードD802connからのフレームを、その非メッシュ通信インタフェースの１つを通して受信すれば、この宛先ノードD802connはメッシュネットワークの外にある。
(a) 出口リストが宛先ノードD802connの宛先MACアドレスをカバーしていれば、この宛先ノードはメッシュネットワークの外にある。それ以外の場合、この宛先ノードはメッシュネットワーク内にあると予想される。
(b) メッシュノードのMACアドレスが宛先ノードD802connの宛先MACアドレスに等しいか、またはメッシュノードがルート要求メッセージまたは拡張ルート要求メッセージに、他のメッシュノードに対する中間ノードとして応答すれば、この宛先ノードはメッシュネットワーク内にある。それ以外の場合、この宛先ノードはメッシュネットワークの外にある。
(c) メッシュノードがノードD802connからのフレームを、その非メッシュ通信インタフェースの１つを通して受信すれば、この宛先ノードD802connはメッシュネットワークの外にある。
[1]におけるRREP情報エレメントの説明は不完全であることを述べておく。そこには宛先とソースとの混同が存在する。この明細書では正しいバージョンを使用する。
RREPメッセージに拡張されたHWMP。この補足は、レジストレーションモードでのHWMPの順向拡張(ツリーベースのルーティング)に使用される。ルーツプロトコル声明の受領後、メッシュポイントは自分自身をルーツメッシュポータルとともに、ルート応答をこのルーツメッシュポータルに送信することによって登録する。またメッシュアクセスポイントは、関連する非メッシュ局をこのルート応答メッセージに含むようになる。第１宛先MACアドレス(図４と５の参照符合45)はメッシュアクセスポイントであり、後続の非メッシュSTA MACアドレス(図４と５の参照符合4D、4F、4G)は非メッシュ局である。本発明によれば、非メッシュ局のアドレスは802コネクションの宛先アドレスである。したがってルーツメッシュポータルは、MAPと非メッシュ局をカバーする相応の数のペアをその入口リストに挿入する(非メッシュSTAカウントN(図５の参照符合4C)のペア)。
メッシュポイントはメッシュネットワーク内にあるから、フラグ「別個の802宛先MACアドレス」(図５の参照符合54)がセットされ、これはただ１つの宛先アドレス、すなわち「メッシュ宛先MACアドレス」(図５の参照符合45)がルート応答メッセージに含まれていることを指示する。この宛先アドレスは、このルート応答を発生するメッシュポイントのアドレスである。
本発明は、[1]の既存のメカニズムと組み合わせることができる。メッシュアクセスポイントは、関連する非メッシュ局の代わりにメッシュポイントとして動作することができる。一方、メッシュポータルは本発明によれば、有線LANからのパケットを取り扱うとき、IEEE 802.3ノード/デバイスとして動作する。
本発明は、IEEE 802.11s WLANメッシュネットワークを備えるネットワーク内でのメッシュポイントと802コネクションとの間で正しくマッピングするためのギャップを無くす。この拡張は、現在の規格ドラフトの既存の仕様に容易に追加することができる。この拡張は、HWMPの技術思想に上手く適合する。
本発明は、ネットワーク構造に関する情報をアドレシングスキームから引き出すことができない場合に、種々の「ルーティングドメイン」またはサブネットワークを取り扱うための一般的概念を規定する。本発明はまた、階層ルーティングアーキテクチャにも使用することができる。
例を図８に基づいて説明する。そこではMPPがメッシュポータルを表わし、MAPがメッシュアクセスポイントを表わす。したがってMPPは第１手段MMMを使用し、MAPは第２手段NNNを使用する。
前提：
・MPPの入口リストは空である。・MPPの出口リストは空である。
・MAPの入口リストは空である。
・MAPの出口リストは{STA1,STA2}を含む。
・MPPのルーティングテーブルは空である。
・MAPのルーティングテーブルは空である。・非メッシュノードAXは、フレームを非メッシュ局STA2に送信しようとしないことを前提とする。
・MPPの入口リストは空である。・MPPの出口リストは空である。
・MAPの入口リストは空である。
・MAPの出口リストは{STA1,STA2}を含む。
・MPPのルーティングテーブルは空である。
・MAPのルーティングテーブルは空である。・非メッシュノードAXは、フレームを非メッシュ局STA2に送信しようとしないことを前提とする。
処理プロセス：
1. メッシュポータルMPPがデータフレームを、D802conn=STA2とS802conn=AXを備えるAXから受信する。
2. MPPが、S802conn=AXをその出口リストに挿入する。MPPの出口リストは{AX}を含む。
3. MPPは、D802conn=STA2に対するエントリーをその入口リストに有していない。
4. MPPは、D802=STA2に対するエントリーをそのルーティングテーブルに有していない → MPPはD802conn=STA2に対するルート発見を開始しなければならない。
5. MPPはRREQを、
・rreq.mesh_source_MAC_address = MPP;
・rreq.802_source_MAC_address = AX;
・rreq.802_destination_MAC_address = STA2
により作成する。
6. MPPはRREQを同報送信する。
7. 中間メッシュノードB,E,C,F,D,GがRREQを受信する。
8. 中間メッシュノードは、S802conn=AX-Smesh=MPPをそれらの入口リストに挿入する。
9. 中間メッシュノードは、ルーティングテーブル中のSmeshに対するエントリーを作成または更新する。
10. 中間メッシュノードは更新されたRREQｑを、再同報送信/転送する。
11. RREQはMAPにより場合により受信されている → MPAはMPPへのパスを有する。
12. MAPはSTA2をその出口リストに有する → MAPはRREPを以て応答することができる。
13. MAPは、S802conn=AX-Smesh=MPPをその入口リストに挿入する。MAPの入口リストは{AX-MPP}を含む。
14. MAPは、STA2に対するRREPを、
・rrep.mesh_destination_MAC_address = MAP;
・rrep.802_destination_MAC__address = STA2;
・rreq.mesh_source_MAC_address = MPP;
により作成する。
15. MAPはRREPをMPPに、MPPへのパスで送信する。
16. MPPはRRERPをMPPから受信する → MPPはMAPへのパスを有する。
17. MPPは、D802conn=STA2-Dmesh=MAPをその入口リストに挿入する。MPPの入口リストは{STA2-MPP}を含む。
18. D802conn=STA2とS802conn=AXを備える、バッファされたデータフレームが再処理される。
19. MPPはその入口リストにエントリー{STA2-MAP}を発見する → データフレームを６つのアドレスを備えるメッシュデータフレームとして転送することができる。
20. MPPはデータフレームを、６つのアドレスを備えるメッシュデータフレームに次のようにして変換する。
・アドレス3 Dmeshy=MAP → D802conn=STA2に対するエントリーを入口リストから取り出す。
・アドレス4 Smesh=MAP → それ自体、メッシュ入口ノードとして。
アドレス5 D802conn=STA2 → 受信されたデータフレームから取り出す。
・アドレス6 S802conn=AX → 受信されたデータフレームから取り出す。
21. メッシュデータフレームは、メッシュ転送ルールに従い、MAPへのパスに転送される。
22. MAPはメッシュデータフレームを受信する。
23. MAPは、これがDmeshであることを知る → データフレームをD802conn=STA2に転送しなければならない。
24. MAPは、D802conn=STA2をその出口リストに見つける。
25. MAPはメッシュデータフレームを、D802conn=STA2に対するインタフェースのフレームフォーマットに変換する。
26. MAPはデータフレームを、D802conn=STA2に転送する。
1. メッシュポータルMPPがデータフレームを、D802conn=STA2とS802conn=AXを備えるAXから受信する。
2. MPPが、S802conn=AXをその出口リストに挿入する。MPPの出口リストは{AX}を含む。
3. MPPは、D802conn=STA2に対するエントリーをその入口リストに有していない。
4. MPPは、D802=STA2に対するエントリーをそのルーティングテーブルに有していない → MPPはD802conn=STA2に対するルート発見を開始しなければならない。
5. MPPはRREQを、
・rreq.mesh_source_MAC_address = MPP;
・rreq.802_source_MAC_address = AX;
・rreq.802_destination_MAC_address = STA2
により作成する。
6. MPPはRREQを同報送信する。
7. 中間メッシュノードB,E,C,F,D,GがRREQを受信する。
8. 中間メッシュノードは、S802conn=AX-Smesh=MPPをそれらの入口リストに挿入する。
9. 中間メッシュノードは、ルーティングテーブル中のSmeshに対するエントリーを作成または更新する。
10. 中間メッシュノードは更新されたRREQｑを、再同報送信/転送する。
11. RREQはMAPにより場合により受信されている → MPAはMPPへのパスを有する。
12. MAPはSTA2をその出口リストに有する → MAPはRREPを以て応答することができる。
13. MAPは、S802conn=AX-Smesh=MPPをその入口リストに挿入する。MAPの入口リストは{AX-MPP}を含む。
14. MAPは、STA2に対するRREPを、
・rrep.mesh_destination_MAC_address = MAP;
・rrep.802_destination_MAC__address = STA2;
・rreq.mesh_source_MAC_address = MPP;
により作成する。
15. MAPはRREPをMPPに、MPPへのパスで送信する。
16. MPPはRRERPをMPPから受信する → MPPはMAPへのパスを有する。
17. MPPは、D802conn=STA2-Dmesh=MAPをその入口リストに挿入する。MPPの入口リストは{STA2-MPP}を含む。
18. D802conn=STA2とS802conn=AXを備える、バッファされたデータフレームが再処理される。
19. MPPはその入口リストにエントリー{STA2-MAP}を発見する → データフレームを６つのアドレスを備えるメッシュデータフレームとして転送することができる。
20. MPPはデータフレームを、６つのアドレスを備えるメッシュデータフレームに次のようにして変換する。
・アドレス3 Dmeshy=MAP → D802conn=STA2に対するエントリーを入口リストから取り出す。
・アドレス4 Smesh=MAP → それ自体、メッシュ入口ノードとして。
アドレス5 D802conn=STA2 → 受信されたデータフレームから取り出す。
・アドレス6 S802conn=AX → 受信されたデータフレームから取り出す。
21. メッシュデータフレームは、メッシュ転送ルールに従い、MAPへのパスに転送される。
22. MAPはメッシュデータフレームを受信する。
23. MAPは、これがDmeshであることを知る → データフレームをD802conn=STA2に転送しなければならない。
24. MAPは、D802conn=STA2をその出口リストに見つける。
25. MAPはメッシュデータフレームを、D802conn=STA2に対するインタフェースのフレームフォーマットに変換する。
26. MAPはデータフレームを、D802conn=STA2に転送する。
Claims (12)
- IEEE802コネクションのソースノード(S802conn)からIEEE802コネクションの宛先ノード(D802conn)に至るルートに対してルート発見するための拡張ルート要求メッセージ(eRREQ)の発生方法であって、
前記ルートは、メッシュパスのソースノード(M)とメッシュパスの宛先ノード(P)を備えるメッシュネットワーク(NET2)パスを含む方法において、
・IEEE 802コネクションのソースノード(S802conn)がメッシュネットワーク(NET2)内にあるか、外にあるかを決定するステップ；
・IEEE 802コネクションのソースノード(S802conn)がメッシュネットワーク(NET2)内にあるノードである場合、次のような拡張ルート要求メッセージ(eRREQ)を発生するステップ、
すなわち前記拡張ルート要求メッセージは、メッシュパスのソースノード(M)の１つのソースアドレスとフラグ(35)を含んでおり、該フラグは、拡張ルート要求メッセージ(eRREQ)が前記１つのソースアドレスをカバーすることを指示する；
・IEEE 802コネクションのソースノード（S802conn）がメッシュネットワーク(NET2)外にあるノードである場合、次のような拡張ルート要求メッセージ(eRREQ)を発生するステップ、
すなわち前記拡張ルート要求メッセージは、２つのソースアドレスとフラグを含んでおり、
前記２つのソースアドレスは、(a)メッシュパスのソースノード(M)のソースアドレスと、(b)IEEE 802コネクションのソースノード（S802conn）のソースアドレスをカバーし、
前記フラグは、拡張ルート要求メッセージ(eRREQ)が前記２つのソースアドレスをカバーすることを指示する；
を有することを特徴とする発生方法。 - 請求項１記載の方法であって、
前記メッシュパスのソースノード(M)がメッシュノード(V)に割り当てられ、
該メッシュノードは、メッシュネットワーク(NET2)の入口ノード、メッシュアクセスポイント、またはメッシュポータルを表わし、IEEE 802コネクションのソースノード（S802conn）がメッシュネットワーク(NET2)外のノードから由来する場合、IEEE 802コネクションのソースノード（S802conn）をアドレシングする方法。 - IEEE802コネクションのソースノード(S802conn)からIEEE802コネクションの宛先ノード(D802conn)に至るルートに対してルート発見するための拡張ルート応答メッセージ(eRREP)の発生方法であって、
前記ルートは、メッシュパスのソースノード(M)とメッシュパスの宛先ノード(P)を備えるメッシュネットワーク(NET2)パスを含む方法において、
・IEEE 802コネクションの宛先ノード(D802conn)がメッシュネットワーク(NET2)内にあるか、外にあるかを決定するステップ；
・IEEE 802コネクションの宛先ノード(D802conn)がメッシュネットワーク(NET2)内にあるノードである場合、次のような拡張ルート応答メッセージ(eRREP)を発生するステップ、
すなわち前記拡張ルート応答メッセージは、メッシュパスの宛先ノード(P)の１つの宛先アドレスとフラグ(54)を含んでおり、該フラグは、拡張ルート応答メッセージ(eRREP)が前記１つのソースアドレスをカバーすることを指示する；
・IEEE 802コネクションの宛先ノード（D802conn）がメッシュネットワーク(NET2)外にあるノードである場合、次のような拡張ルート応答メッセージ(eRREP)を発生するステップ、
すなわち前記拡張ルート応答メッセージは、２つの宛先アドレスとフラグを含んでおり、
前記２つの宛先アドレスは、(a)メッシュパスの宛先ノード(P)の宛先アドレスと、(b)IEEE 802コネクションの宛先ノード（D802conn）の宛先アドレスをカバーし、
前記フラグは、拡張ルート応答メッセージ(eRREP)が前記２つの宛先アドレスをカバーすることを指示する；
を有することを特徴とする発生方法。 - 請求項３記載の方法であって、
前記メッシュパスの宛先ノード(P)がメッシュノード(V)に割り当てられ、
該メッシュノードは、メッシュネットワーク(NET2)の出口ノード、メッシュアクセスポイントまたはメッシュポータルを表わし、
IEEE 802コネクションの宛先ノード（D802conn）がメッシュネットワーク(NET2)外のノードから由来する場合、IEEE 802コネクションの宛先ノード（D802conn）をアドレシングする方法。 - 請求項１から４までのいずれか一項記載の方法であって、
WLANが、IEEE 802.11規格に基づき、メッシュネットワーク(NET2)に割り当てられる方法。 - 請求項１から５までのいずれか一項記載の方法であって、
局(STA)が、IEEE 802.11規格および/またはIEEE 802.3規格に基づき、IEEE 802コネクションのソースノード（S802conn）または宛先ノード(D802conn)に割り当てられる方法。 - IEEE802コネクションのソースノード(S802conn)からIEEE802コネクションの宛先ノード(D802conn)に至るルートに対してルート発見するために使用される拡張ルート要求メッセージ(eRREQ)であって、
前記ルートは、メッシュパスのソースノード(M)とメッシュパスの宛先ノード(P)を備えるメッシュネットワーク(NET2)パスを含む拡張ルート要求メッセージにおいて、
・IEEE 802コネクションのソースノード（S802conn）がメッシュネットワーク（NET2）内にあるノードである場合、メッシュパスのソースノード(M)の１つのソースアドレスと、フラグ(35)を有し、
該フラグは、拡張ルート要求メッセージ(eRREQ)が前記１つのソースアドレスをカバーすることを指示し；
・IEEE 802コネクションのソースノード（S802conn）がメッシュネットワーク(NET2)外にあるノードである場合、前記拡張ルート要求メッセージ(eRREQ)は、２つのソースアドレスとフラグ(35)を有し、
前記２つのソースアドレスは、(a)メッシュパスのソースノード(M)のソースアドレスと、(b)IEEE 802コネクションのソースノード（S802conn）のソースアドレスをカバーし、
前記フラグは、拡張ルート要求メッセージ(eRREQ)が前記２つのソースアドレスをカバーすることを指示する拡張ルート要求メッセージ。 - 請求項７記載の拡張ルート要求メッセージ(eRREQ)であって、
前記メッシュパスのソースノード(M)がメッシュノード(V)に割り当てられ、
該メッシュノードは、メッシュネットワーク(NET2)の入口ノード、メッシュアクセスポイント、またはメッシュポータルを表わし、
IEEE 802コネクションのソースノード（S802conn）がメッシュネットワーク(NET2)外のノードから由来する場合、IEEE 802コネクションのソースノード（S802conn）をアドレシングする拡張ルート要求メッセージ。 - IEEE802コネクションのソースノード(S802conn)からIEEE802コネクションの宛先ノード(D802conn)に至るルートに対してルート発見するための拡張ルート応答メッセージ(eRREP)であって、
前記ルートは、メッシュパスのソースノード(M)とメッシュパスの宛先ノード(P)を備えるメッシュネットワーク(NET2)パスを含む拡張ルート応答メッセージにおいて、
・IEEE 802コネクションの宛先ノード（D802conn）がメッシュネットワーク（NET2）内にあるノードである場合、メッシュパスの宛先ノード(P)の１つの宛先アドレスと、フラグ(54)を有し、
該フラグは、拡張ルート応答メッセージ(eRREP)が前記１つの宛先アドレスをカバーすることを指示し；
・IEEE 802コネクションの宛先ノード(D802conn)がメッシュネットワーク(NET2)外にあるノードである場合、前記拡張ルート応答メッセージ(eRREP)は、２つの宛先アドレスとフラグ(54)を有し、
前記２つの宛先アドレスは、(a)メッシュパスの宛先ノード(P)の宛先アドレスと、(b)IEEE 802コネクションの宛先ノード(D802conn)の宛先アドレスをカバーし、
前記フラグは、拡張ルート応答メッセージ(eRREP)が前記２つの宛先アドレスをカバーすることを指示する拡張ルート応答メッセージ。 - 請求項９記載の拡張ルート応答メッセージ(eRREP)であって、
前記メッシュパスの宛先ノード(P)がメッシュノード(V)に割り当てられ、
該メッシュノードは、メッシュネットワーク(NET2)の出口ノード、メッシュアクセスポイントまたはメッシュポータルを表わし、
IEEE 802コネクションの宛先ノード（D802conn）がメッシュネットワーク(NET2)外のノードから由来する場合、IEEE 802コネクションの宛先ノード（D802conn）をアドレシングする拡張ルート応答メッセージ。 - メッシュネットワーク(NET")内の第１のノードが、
請求項３または４による拡張ルート応答メッセージ(eRREP)、および/または請求項１または２による拡張ルート要求メッセージ(eRREQ)を発生する第１の手段(MMM)を有する。 - メッシュネットワーク(NET2)内の第２のノードが、
請求項９または１０に規定された拡張ルート応答メッセージ(eRREP)、および/または請求項７または８に規定された拡張ルート要求メッセージ(eRREQ)を評価する第２の手段（NNN）を有する。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP06014744 | 2006-07-14 | ||
| EP06014744.4 | 2006-07-14 | ||
| PCT/EP2007/057192 WO2008006882A1 (en) | 2006-07-14 | 2007-07-12 | Method for generating an extended route request message and an extended route reply message for route discovery procedures |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2009544209A JP2009544209A (ja) | 2009-12-10 |
| JP4904396B2 true JP4904396B2 (ja) | 2012-03-28 |
Family
ID=38441871
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2009519947A Expired - Fee Related JP4904396B2 (ja) | 2006-07-14 | 2007-07-12 | ルート発見プロシージャのための拡張ルート要求メッセージの発生方法および拡張ルート応答メッセージの発生方法 |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US8908670B2 (ja) |
| EP (1) | EP2041922B1 (ja) |
| JP (1) | JP4904396B2 (ja) |
| CN (1) | CN101491011B (ja) |
| ES (1) | ES2402826T3 (ja) |
| PL (1) | PL2041922T3 (ja) |
| WO (1) | WO2008006882A1 (ja) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8982908B1 (en) * | 2008-12-01 | 2015-03-17 | Marvell International Ltd. | Extension of path reply message to encode multiple route information in a mesh network |
| JP5854450B2 (ja) * | 2010-01-13 | 2016-02-09 | 日本電気株式会社 | 無線通信システム、無線通信装置、無線通信方法及びプログラム |
| KR20120071924A (ko) * | 2010-12-23 | 2012-07-03 | 한국전자통신연구원 | 무선 메쉬 네트워크에서 노드의 이동성을 지원하는 방법 |
| US20160081005A1 (en) * | 2014-09-17 | 2016-03-17 | Qualcomm Incorporated | Route formation and message transmission in a data link group over multiple channels |
| WO2018054468A1 (en) * | 2016-09-22 | 2018-03-29 | Telefonaktiebolaget Lm Ericsson (Publ) | A method, devices and a wireless mesh network for establishing a route between a route originator, ro, mesh node and a route destination, rd, mesh node in a mesh network |
| US10171343B2 (en) | 2016-12-21 | 2019-01-01 | Sony Corporation | Routing multiple data streams simultaneously in wireless networks |
| CN111935780B (zh) * | 2020-08-13 | 2024-03-26 | 杭州萤石软件有限公司 | 一种无线网格网络中流量负载分担的方法、网络系统 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005079025A (ja) * | 2003-09-02 | 2005-03-24 | Honda Motor Co Ltd | 押ボタンスイッチ構造 |
| JP2005236767A (ja) * | 2004-02-20 | 2005-09-02 | Ntt Docomo Inc | 通信装置、中継装置及び通信システム並びに通信方法 |
| WO2006031445A2 (en) * | 2004-09-10 | 2006-03-23 | Interdigital Technology Corporation | Method for sending an acknowledgement to an ingress mesh point in a mesh network and a medium access control frame format |
| JP2006166232A (ja) * | 2004-12-09 | 2006-06-22 | Oki Electric Ind Co Ltd | ネットワークスイッチ装置及び方法、無線アクセス装置、および、無線ネットワークシステム |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2212278C (en) * | 1995-08-07 | 2001-03-27 | British Telecommunications Public Limited Company | Route finding in communications networks |
| WO2002032058A2 (en) * | 2000-10-13 | 2002-04-18 | General Instrument Corporation | Spanning tree alternate routing bridge protocol |
| EP1460807A1 (en) * | 2003-03-21 | 2004-09-22 | Siemens Aktiengesellschaft | System method and apparatus for routing traffic in a telecommunications network |
| JP2005286989A (ja) * | 2004-03-02 | 2005-10-13 | Ntt Docomo Inc | 通信端末及びアドホックネットワーク経路制御方法 |
| WO2006029126A2 (en) * | 2004-09-07 | 2006-03-16 | Meshnetworks, Inc. | System and method for associating different types of nodes with access point nodes in wireless network to route data in the wireless network |
| US7787361B2 (en) | 2005-07-29 | 2010-08-31 | Cisco Technology, Inc. | Hybrid distance vector protocol for wireless mesh networks |
| US20070091871A1 (en) * | 2005-10-26 | 2007-04-26 | Intel Corporation | Mesh network portal node and method for bridging in mesh networks |
| KR101183342B1 (ko) * | 2005-11-09 | 2012-09-14 | 톰슨 라이센싱 | 무선 네트워크에서의 경로 선택 |
| US7782835B2 (en) * | 2006-01-17 | 2010-08-24 | Motorola, Inc. | System and method for multihop packet forwarding |
| US20070248089A1 (en) * | 2006-04-19 | 2007-10-25 | Jason Redi | Systems and methods for incorporating information corresponding to an end-to-end transmission in determining access to a communication medium |
| US7894408B2 (en) * | 2006-05-12 | 2011-02-22 | Motorola Solutions, Inc. | System and method for distributing proxying error information in wireless networks |
-
2007
- 2007-07-12 CN CN2007800267839A patent/CN101491011B/zh active Active
- 2007-07-12 WO PCT/EP2007/057192 patent/WO2008006882A1/en active Application Filing
- 2007-07-12 JP JP2009519947A patent/JP4904396B2/ja not_active Expired - Fee Related
- 2007-07-12 ES ES07787463T patent/ES2402826T3/es active Active
- 2007-07-12 EP EP07787463A patent/EP2041922B1/en active Active
- 2007-07-12 US US12/309,317 patent/US8908670B2/en active Active
- 2007-07-12 PL PL07787463T patent/PL2041922T3/pl unknown
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005079025A (ja) * | 2003-09-02 | 2005-03-24 | Honda Motor Co Ltd | 押ボタンスイッチ構造 |
| JP2005236767A (ja) * | 2004-02-20 | 2005-09-02 | Ntt Docomo Inc | 通信装置、中継装置及び通信システム並びに通信方法 |
| WO2006031445A2 (en) * | 2004-09-10 | 2006-03-23 | Interdigital Technology Corporation | Method for sending an acknowledgement to an ingress mesh point in a mesh network and a medium access control frame format |
| JP2006166232A (ja) * | 2004-12-09 | 2006-06-22 | Oki Electric Ind Co Ltd | ネットワークスイッチ装置及び方法、無線アクセス装置、および、無線ネットワークシステム |
Also Published As
| Publication number | Publication date |
|---|---|
| ES2402826T3 (es) | 2013-05-09 |
| EP2041922A1 (en) | 2009-04-01 |
| PL2041922T3 (pl) | 2013-08-30 |
| CN101491011A (zh) | 2009-07-22 |
| EP2041922B1 (en) | 2013-03-06 |
| JP2009544209A (ja) | 2009-12-10 |
| CN101491011B (zh) | 2011-10-05 |
| WO2008006882A1 (en) | 2008-01-17 |
| US20090316668A1 (en) | 2009-12-24 |
| US8908670B2 (en) | 2014-12-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| USRE42712E1 (en) | Ad-hoc network for routing extension to support internet protocol version 6(IPV6) and method thereof | |
| US8441958B2 (en) | Directed acyclic graph discovery and network prefix information distribution relative to a clusterhead in an ad hoc mobile network | |
| US7782835B2 (en) | System and method for multihop packet forwarding | |
| US7382759B2 (en) | System and method for associating different types of nodes with access point nodes in a wireless network to route data in the wireless network | |
| US7333461B2 (en) | Arrangement in a router of a mobile network for generating a local router prefix for anonymous route connections | |
| US7894408B2 (en) | System and method for distributing proxying error information in wireless networks | |
| US8009615B2 (en) | Multi-hop ad-hoc wireless networks that support non-multi-hop wireless terminals | |
| JP4904396B2 (ja) | ルート発見プロシージャのための拡張ルート要求メッセージの発生方法および拡張ルート応答メッセージの発生方法 | |
| US20080095059A1 (en) | System and method for providing an adaptive value of TTL (Time to Live) for broadcast/multicast messages in a mesh network using a hybrid wireless mesh protocol | |
| US20120014309A1 (en) | Wireless communication apparatus, wireless network system, data transfer method, and recording medium | |
| EP2636273A1 (en) | A method and device for transmitting an ipv6 over low power wireless personal area network data packet | |
| US20070115828A1 (en) | Method for sending requests in a network | |
| US9232389B2 (en) | Mixed mode security for mesh networks | |
| Singh et al. | Non-root-based hybrid wireless mesh protocol for wireless mesh networks | |
| KR100521139B1 (ko) | Ａｄ-Ｈｏｃ 네트워크에서의 패킷 처리 방법 | |
| JP5018490B2 (ja) | 中継装置 | |
| KR101029497B1 (ko) | 리엑티브 방식의 라우팅 프로토콜을 사용하는 이동 애드혹 네트워크 상에서 경로탐색 과정을 통한 에이알피 프로토콜 대체 방법 | |
| KR100639961B1 (ko) | ＩＰｖ６ 이동 애드혹 네트워크의 인터넷 연결성을 위한확장 지원방법 | |
| Chelius et al. | IPv6 addressing scheme and self-configuration for multi-hops wireless ad hoc network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20101227 Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20101228 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20110427 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110428 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20110725 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20110801 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20110825 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20110901 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20110927 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20111004 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20111024 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20111208 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20120106 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4904396 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20150113 Year of fee payment: 3 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |