JP6088859B2 - 通信装置および通信制御プログラム - Google Patents

Description

本発明の実施形態は、パケットを複数のフラグメントに分割する通信装置および通信制御プログラムに関する。

パケット通信では、一度に送信可能なデータサイズは予め決まっているため、このサイズを超えるサイズのパケットを送信する場合は、このパケットを複数のフラグメントに分割して送信する必要がある。

フラグメントのサイズの決め方について、従来から種々提案されているが、上位レイヤの特性まで考慮したフラグメントサイズの検討はされていない。

特開２０１２−２０９９０５号公報

D. Qiao, et. al, "Goodput Enhancement of IEEE 802.lla Wireless LAN via Link Adaptation", IEEE ICC 2001, VOL. 7, 2001 B. Kim, et. al, "Throughput Enhancement Through Dynamic Fragmentation in Wireless LANs", IEEE Trans. Vehicular Tech., Vol. 54, No. 4, July 2005

本発明の実施形態は、上位レイヤの通信品質を満たしつつ、ネットワークリソースの有効利用を図れるフラグメント化を行うことが可能な通信装置および通信制御プログラムを提供するものである。

本実施形態によれば、ネットワークを構成する複数レイヤのうち、上位側レイヤの評価パラメータを取得する上位レイヤ評価パラメータ取得部と、
前記上位レイヤ評価パラメータ取得部にて取得された評価パラメータに基づいて、上位側レイヤの情報を含むパケットをフラグメントに分割する際のフラグメントサイズを決定するフラグメントサイズ決定部と、
前記フラグメントサイズに基づいて、前記パケットを複数のフラグメントに分割するフラグメント制御部と、を備える通信装置が提供される。

第１の実施形態に係る通信装置１の機能ブロック図。 第１の実施形態におけるフラグメントサイズ決定部３がフラグメントサイズを決定するにあたって参照するテーブル９の一例を示す図。 ＲＦＣ２４７４で規定されるＤＳＣＰフィールド１１のフォーマットを示す図。 図１の通信装置１を複数台用いて構成される無線マルチホップネットワークシステムの一例を示す図。 第２の実施形態に係る通信装置１の機能ブロック図。 第２の実施形態における上位レイヤ種別と、上位レイヤ通信プロファイルと、下位レイヤ評価パラメータの閾値との対応関係を示すテーブル図。 第２の実施形態におけるフラグメントサイズ決定部３の処理手順の一例を示すフローチャート。 第３の実施形態におけるフラグメントサイズ決定部３がフラグメントサイズを決定するにあたって参照するテーブル２２の一例を示す図。 第３の実施形態における上位レイヤ種別と、上位レイヤ通信プロファイルと、下位レイヤ評価パラメータの閾値との対応関係を示すテーブル図。 第４の実施形態におけるフラグメントサイズ決定部３がフラグメントサイズを決定するにあたって参照するテーブル２３の一例を示す図。 第４の実施形態における上位レイヤ種別と、上位レイヤ通信プロファイルと、下位レイヤ評価パラメータの閾値との対応関係を示すテーブル図。 第４の実施形態による通信装置１を複数台用いて構成される無線マルチホップネットワークシステムを示す図。 送信元ノードの通信装置１におけるフラグメントサイズ決定部３の処理手順の一例を示すフローチャート。 図１３のステップＳ３２のコンテンツ種別判別処理の詳細な処理手順を示すフローチャート。 （ａ）と（ｂ）は6LoWPANフラグメントのデータ構造を示す図。 6LoWPANフラグメント、ＩＰパケット、IEEE802.15.4フレームのデータ構造を示す図。

以下、図面を参照しながら、本発明の実施形態を説明する。

（第１の実施形態）
第１の実施形態では、ＩＥＴＦ（internet Engineering Task Force）により策定されているIEEE802.15.4ネットワークにIPv6パケットを通すための通信プロトコルである6LoWPAN（IPv6 over Low-Power Wireless Personal Area Network）にてフラグメント化を行う例を説明する。

図１は第１の実施形態に係る通信装置１の機能ブロック図である。より具体的には、図１は通信装置１が送信ＩＰパケットについて6LoWPANのフラグメント化を行う場合の機能ブロック図である。なお、6LoWPANのフラグメント化を行う前に、ＩＰのフラグメント化を行ってもよい。

図１の通信装置１は、上位レイヤ評価パラメータ取得部２と、フラグメントサイズ決定部３と、フラグメント制御部４とを備えている。

上位レイヤ評価パラメータ取得部２は、ネットワークを構成する複数レイヤのうち、上位側レイヤの評価パラメータ（以下、上位レイヤ評価パラメータ）を取得する。

フラグメントサイズ決定部３は、上位レイヤ評価パラメータに基づいて、上位側レイヤの情報を含むパケットをフラグメントに分割する際のフラグメントサイズを決定する。決定されるフラグメントサイズは、データリンクレイヤの最大フレームサイズに収まる範囲内である必要がある。

フラグメント制御部４は、フラグメントサイズに基づいて、パケットを複数のフラグメントに分割する。

上位レイヤ評価パラメータ取得部２が取得する上位レイヤ評価パラメータは、例えば、各ＩＰパケットのＤＳＣＰ（Differentiated Services Code Point）フィールドに記述された値である。ＤＳＣＰフィールドは、ＩＰパケットの送信元の通信装置１によって、上位レイヤの通信品質に関連する値に設定されうる。この値は、例えば、送信するパケットに含まれるコンテンツ種別を判別するための値である。あるいは、送信元の通信装置１から送信されたパケットを中継する途中の通信装置１によって、ＤＳＣＰフィールドの値が設定または更新される場合もありうる。ＤＳＣＰフィールドの値を設定または更新する通信装置１は、図１に示した通信装置１と同じであってもよいし、別であってもよい。

図２は第１の実施形態におけるフラグメントサイズ決定部３がフラグメントサイズを決定するにあたって参照するテーブル９の一例を示す図である。このテーブル９は、例えば図１の通信装置１の内部に設けられている。図２のテーブル９には、ＩＰパケットのＤＳＣＰフィールドに記述された値と、決定するフラグメントサイズとの対応関係が登録されている。例えば、ＤＳＣＰフィールドの値が「１０１１１０」の場合は、フラグメントサイズとしてショートフレーム（例えば１２７オクテット）が選択され、ＤＳＣＰフィールドの値が「００００００」の場合は、フラグメントサイズとしてロングフレーム（例えば１３２７オクテット）が選択される。

なお、図２はテーブル９の一例であり、ＤＳＣＰフィールドに記述される値とフラグメントサイズとの対応関係は図２に示したテーブル９に限定されない。例えば、ＤＳＣＰフィールドに記述される値が３種類以上あれば、その値のそれぞれに対応づけて３種類以上のフラグメントサイズを設ければよい。

図３はＲＦＣ２４７４で規定されるＤＳＣＰフィールド１１のフォーマットを示す図である。図示のように、ＤＳＣＰフィールド１１は、ＤＳ（Differentiated Services）フィールド１０の先頭６ビットに位置し、残りの２ビットは未使用のＣＵ（Currently unused)フィールド１２である。ＤＳフィールド１０としては、例えばIPv4パケットのＴＯＳフィールドやIPv6パケットのTraffic Classフィールドが使用される。

図４は図１の通信装置１を複数台用いて構成される無線マルチホップネットワークシステムの一例を示す図である。図４では、送信元の通信装置１をノードＮ１、中継を行う通信装置１をノードＮ２、最終送信先の通信装置１をノードＮ３としている。ノードＮ１〜Ｎ３の各通信装置１は、いずれも図１と同様に構成されている。

ノードＮ１の通信装置１は、上位レイヤからデータ送信の指示を受けると、ＩＰパケット１３を生成し、その後、フラグメントサイズ決定部３が決定したフラグメントサイズにて、ＩＰパケット１３を例えば４つのフラグメントｆ１〜ｆ４に分割して、ノードＮ２の通信装置１に送信する。ノードＮ２の通信装置１は、受信された各フラグメントを組み立ててＩＰパケット１３を生成し、最終送付先を確認した後に、再度、例えば４つのフラグメントｆ５〜ｆ８に分割して、ノードＮ３の通信装置１に送信する。ノードＮ３の通信装置１は、受信された各フラグメントを組み立ててＩＰパケット１３を生成する。生成されたＩＰパケット１３は、ノードＮ３の通信装置１の上位レイヤにて処理される。

このように、第１の実施形態では、上位レイヤ評価パラメータに基づいてフラグメントサイズを決定し、決定したフラグメントサイズにてパケットを複数のフラグメントに分割するため、上位レイヤの通信品質を良好にできるようなフラグメント化が可能となる。また、ネットワークリソースを有効利用できるようなフラグメント化も可能となる。

上述した実施形態では、上位レイヤ評価パラメータとして、各ＩＰパケットのＤＳＣＰフィールドの値を利用したが、上位レイヤ評価パラメータとして利用する値は、ＤＳＣＰフィールドの値には限定されない。

（第２の実施形態）
以下に説明する第２の実施形態は、下位レイヤ評価パラメータも加味してフラグメントサイズを決定するものである。

図５は第２の実施形態に係る通信装置１の機能ブロック図である。図５の通信装置１は、図１に示した上位レイヤ評価パラメータ取得部２と、フラグメントサイズ決定部３と、フラグメント制御部４とに加えて、下位レイヤ評価パラメータ取得部５を備えている。

下位レイヤ評価パラメータ取得部５は、ネットワークを構成する複数レイヤのうち、下位側レイヤの評価パラメータ（以下、下位レイヤ評価パラメータ）を取得する。

フラグメントサイズ決定部３は、上位レイヤ評価パラメータと下位レイヤ評価パラメータに基づいて、上位レイヤの情報を含むパケットをフラグメントに分割する際のフラグメントサイズを決定する。決定されるフラグメントサイズは、データリンクレイヤの最大フレームサイズに収まる範囲内である必要がある。また、フラグメントサイズ決定部３は、受信パケットの上位レイヤのフロー識別情報を取得できない場合は、フラグメントサイズをデータリンクレイヤの最大フレームサイズとしてもよい。

上位レイヤ評価パラメータ取得部２は、上述した第１の実施形態と同様に、各ＩＰパケットのＤＳＣＰフィールドに記述された値を上位レイヤ評価パラメータとして取得してもよいし、上位レイヤ種別と上位レイヤ通信プロファイルの少なくとも一方を上位レイヤ評価パラメータとして取得してもよい。

下位レイヤ評価パラメータ取得部５は、例えば、ビットエラー率ＢＥＲとチャネルビジー率ＣＢＲの少なくとも一方を下位レイヤ評価パラメータとして取得する。

図６は、第２の実施形態における上位レイヤ種別と、上位レイヤ通信プロファイルと、下位レイヤ評価パラメータの閾値との対応関係を示すテーブル２１である。図６のテーブル２１中の「＊」は、任意の値を設定可能なエントリを示している。また、英文字「Ｓ」、「Ｄ」、「Ｐ」は、動的に値が設定される動的エントリを示している。これらのエントリ以外のエントリは、指定された固定値が設定される静的エントリである。本明細書では、動的エントリを含まないフロー識別情報に該当する上位レイヤプロトコルは静的フローと呼び、動的エントリを含むフロー識別情報に該当する上位レイヤプロトコルを動的フローと呼ぶ。

図６に示すように、上位レイヤ種別は、上位レイヤプロトコル名とフロー識別情報とを含んでいる。フロー識別情報はさらに、送信元ＩＰアドレス、宛先ＩＰプレフィックス、プロトコル、送信元ポート番号、および宛先ポート番号を含んでいる。フロー識別情報中のプロトコルは、ＩＰパケットのすぐ上の階層のプロトコルを指すのに対し、上位レイヤプロトコル名におけるプロトコルは、フロー識別情報中のプロトコルよりもさらに上の階層のプロトコルを指している。

図６において、上位レイヤプロトコルＲＴＰ、ＲＴＣＰは動的フローであり、それ以外は静的フローである。動的フローに対する動的エントリの実際の値は、上位レイヤ制御プロトコルなどの制御プロトコルから取得される。上位レイヤプロトコルＲＴＰ、ＲＴＣＰの動的フローは、ＲＦＣ−４５６６で規定されるＳＤＰ（Session Description Protocol）を上位レイヤ制御プロトコルとして使用する。このとき、上位レイヤ評価パラメータ取得部２は、まずＳＤＰから上位レイヤ種別を取得し、取得した上位レイヤ種別に含まれている上位レイヤプロトコル名からリアルタイム通信要件を定めた後、取得した上位レイヤ種別のフロー識別情報とリアルタイム通信要件との対応づけを行う。

図６における上位レイヤ通信プロファイルは、リアルタイムが要求されるか否かを示すリアルタイム要件を含んでいる。このリアルタイム要件の値は、例えばフロー識別情報中のプロトコルに依存して決まる。

例えば、プロトコルとしてＴＣＰまたはＰＡＮＡ／ＵＤＰを使用する任意の静的フローに対するリアルタイム要件の値は「０」、IPsec ESPとIPsec AHに対するリアルタイム要件の値は「−１」、その他の静的フローと動的フローに対するリアルタイム要件は「１」である。リアルタイム要件の値「１」はリアルタイム性が要求されることを意味し、値「０」はリアルタイム性が要求されないことを意味し、値「−１」はリアルタイム性が要求されるか否かが不明であることを意味する。

図６における下位レイヤ評価パラメータの閾値は、上位レイヤ評価パラメータによって決定される。例えば、フロー識別情報中のプロトコルがＴＣＰであれば、ビットエラー率の最大値BER_max＝0.00004、チャネルビジー率の最大値CBR_max＝0.7に設定され、フロー識別情報中のプロトコルがＰＡＮＡ／ＵＤＰであれば、BER_max＝0.00003、CBR_max＝０．６に設定される。

より詳細には、BER_maxとCBR_maxの値は、上位レイヤセッション確立失敗率と上位レイヤ通信プロファイルを含む上位レイヤ評価パラメータに基づいて、ネットワークシミュレーションや数値解析等を行って、算出することができる。このとき、上位レイヤ通信プロファイルには、上位レイヤセッション確立遅延要件を含めてもよい。この場合、上位レイヤセッション確立遅延要件として、上位レイヤセッション確立遅延時間の許容平均値、許容最大値、または、許容99%値を使用してもよい。

このように、BER_maxとして、ビットエラー率の最大値、最小値、平均値、累積加算値のいずれかを用いてもよい。同様に、CBR_maxとして、通信経路上の各リンクのチャネルビジー率の最大値、最小値、平均値、累積加算値のいずれかを用いてもよい。平均値を計算する際には、単純移動平均、加重移動平均、指数移動平均のいずれを用いてもよい。

また、上位レイヤ通信プロファイルは、上位レイヤメッセージ送信プロファイルと上位レイヤ再送プロファイルを含んでいてもよい。上位レイヤメッセージ送信プロファイルは例えば、上位レイヤメッセージ再送の有無ｒ、オクテット長Ｌの組（ｒ，Ｌ）のシーケンス｛（ｒ_1，Ｌ_1），（ｒ_2，Ｌ_2），…，（ｒ_n，Ｌ_n）｝で表される。ここで、ｒ_iは、ｉ番目の上位レイヤメッセージの再送の有無、Ｌ_iはｉ番目の上位レイヤメッセージのオクテット長をそれぞれ表す。偶数番目の上位レイヤメッセージの転送経路は、奇数番目の上位レイヤメッセージの転送経路の逆である。ｒ_i＝１のときｉ番目の上位レイヤメッセージは上位レイヤで再送されることを示し、ｒ_i＝０のときｉ番目の上位レイヤメッセージは上位レイヤで再送されないことを示す。上位レイヤがＰＡＮＡの場合、上位レイヤメッセージ送信プロファイルは例えば、（１，Ｌ_1），（１，Ｌ_2），（０，Ｌ_3），（１，Ｌ_4），（０，Ｌ_5），（１，Ｌ_6），（０，Ｌ_7），（１，Ｌ_8），（０，Ｌ_9）｝となる。このとき１番目のメッセージはPCI (PANA-Client-Initiation)メッセージ、２番目、４番目、６番目、８番目のメッセージはPAR (PANA-Auth-Request)メッセージ、３番目、５番目、７番目、９番目のメッセージは、それぞれ、２番目、４番目、６番目、８番目のメッセージに対応するPAN (PANA-Auth-Request)メッセージである。つまり、ＰＣＩとＰＡＲは再送され、ＰＡＮは再送されないことを示す。上位レイヤメッセージ再送プロファイルは、再送アルゴリズム（「指数バックオフ可変間隔」、「固定間隔」など）、再送間隔初期値、再送間隔最大値、最大再送数、最大再送試行期間の少なくとも一つを含んでいてもよい。

図７は第２の実施形態におけるフラグメントサイズ決定部３の処理手順の一例を示すフローチャートである。まず、リアルタイム要件ＲＴ（Ｆ）＝１か否かを判定する（ステップＳ１）。ＲＴ（Ｆ）＝−１であれば、リアルタイム性が要求されるか否かが不明であると判断して、フラグメントサイズをロングフレームにする（ステップＳ２）。なお、リアルタイム性が要求されるか否かが不明な場合に、フラグメントサイズをショートフレームにしてもよい。

一方、ＲＴ（Ｆ）＝−１でなければ、ＲＦ（Ｆ）＝１か否かを判定する（ステップＳ３）。ＲＴ（Ｆ）＝１であれば、リアルタイム性が要求されると判断して、フラグメントサイズをショートフレームにする（ステップＳ４）。

一方、ＲＴ（Ｆ）が「−１」と「１」のいずれでもない場合は、下位レイヤ評価パラメータであるビットエラー率ＢＥＲ≦BER_max（Ｆ）で、かつチャネルビジー率ＣＢＲ≦CBR_max（Ｆ）か否かを判定する（ステップＳ５）。ステップＳ５の判定がＹＥＳであれば、フラグメントサイズをロングフレームにする（ステップＳ６）。ステップＳ５の判定がＮＯであれば、フラグメントサイズをショートフレームにする（ステップＳ７）。

なお、図５の通信装置１を複数台用いることで、図４と同様の無線マルチホップネットワークシステムを構成できる。

ところで、図６では、暗号化されているプロトコルIP ESCとIPsec AHに対するリアルタイム要件の値を「−１」に設定する例を示したが、フラグメントサイズ決定部３は、上位レイヤのプロトコルを暗号化する前のフロー識別情報に基づいて、フラグメントサイズを決定してもよい。

このように、第２の実施形態によれば、上位レイヤ評価パラメータだけでなく、下位レイヤ評価パラメータも考慮に入れてフラグメントサイズを決定するため、上位レイヤの通信品質を良好にしつつネットワークリソースの有効利用を図れることに加えて、かつビットエラーやチャネルビジーを防止可能なフラグメント化を行える。

（第３の実施形態）
以下に説明する第３の実施形態は、下位レイヤ評価パラメータの内容が第２の実施形態と異なるものである。

第３の実施形態における下位レイヤ評価パラメータ取得部５は、平均フレーム送信回数ＥＴＸを下位レイヤ評価パラメータとして取得する。平均フレーム送信回数ＥＴＸとは、フラグメント化された各パケットの平均送信回数を意味する。

第３の実施形態における上位レイヤ評価パラメータ取得部２が取得する上位レイヤ評価パラメータは第２の実施形態と同様である。

図８は第３の実施形態におけるフラグメントサイズ決定部３がフラグメントサイズを決定するにあたって参照するテーブル２２の一例を示す図である。図８のテーブル２２は、図２と比べて、下位レイヤ評価パラメータの閾値の内容が異なっており、それ以外は図２と同じである。

図８の下位レイヤ評価パラメータの閾値は、平均フレーム送信回数ＥＴＸの最大許容値ETX_maxである。図８の例では、フロー識別情報中のプロトコルがＴＣＰの場合はETX_max＝２．６とし、ＰＡＮＡ／ＵＤＰの場合はETX_max=２．０としている。

図９は、第３の実施形態における上位レイヤ種別と、上位レイヤ通信プロファイルと、下位レイヤ評価パラメータの閾値との対応関係を示すテーブルである。図９のステップＳ１１〜Ｓ１４は図７のステップＳ１〜Ｓ４と同様である。ステップＳ１３の判定がＮＯの場合、すなわち、リアルタイム要件ＲＴ（Ｆ）が「−１」と「１」のいずれでもない場合は、平均フレーム送信回数ＥＴＸがその最大許容値ETX_max以下か否かを判定し（ステップＳ１４）、最大許容値ETX_max以下であればロングフレームを選択し（ステップＳ１５）、最大許容値ETX_maxより大きければショートフレームを選択する（ステップＳ１６）。

ここで、ETX_maxとして、通信経路上の各リンクの平均フレーム送信回数の最大値、最小値、平均値のいずれかを使用すればよい。平均値を計算する際には、単純移動平均、加重移動平均、指数移動平均のいずれを用いてもよい。

なお、図８の通信装置１を複数台用いることで、図４と同様の無線マルチホップネットワークシステムを構成できる。

このように、第３の実施形態では、下位レイヤ評価パラメータを、ビットエラー率ＢＥＲとチャネルビジー率ＣＢＲの両方の影響を考慮に入れた平均フレーム送信回数ＥＴＸとするため、フラグメントサイズ決定部３での処理を第２の実施形態よりも簡略化できる。

（第４の実施形態）
以下に説明する第４の実施形態は、下位レイヤ評価パラメータの内容が第１および第２の実施形態とは異なるものである。

第４の実施形態における下位レイヤ評価パラメータ取得部５は、通信経路上の各リンクのフレーム送信回数の平均値の累積加算値ETX_pathを下位レイヤ評価パラメータとして取得する。図４に示す無線マルチホップネットワークシステムでは、中継ノードである通信装置１にて、受信されたフラグメントを組み立ててパケットを作製し、その後に再度フラグメントに分割する処理を行っていた。これに対して、中継ノードで、フラグメントの組立と再分割を行わない場合もある。この場合、第３の実施形態のように、平均フレーム送信回数の平均値を下位評価パラメータとするよりも、本実施形態のように、フレーム送信回数の平均値の累積加算値ETX_pathを下位評価パラメータとするのが望ましい。

図１０は第４の実施形態におけるフラグメントサイズ決定部３がフラグメントサイズを決定するにあたって参照するテーブル２３の一例を示す図である。図１０のテーブル２３は、図２と比べて、下位レイヤ評価パラメータの閾値の内容が異なっており、それ以外は図２と同じである。

図１０の下位レイヤ評価パラメータの閾値は、フレーム送信回数の平均値の累積加算値ETX_pathの最大許容値ETX_path_maxである。このETX_path_maxは、ホップ数Ｈと平均フレーム送信回数ETX_maxとの積で表される動的エントリであり、Ｈの値はルーティングプロトコル等の制御プロトコルから取得することができる。平均値を計算する際には、単純移動平均、加重移動平均、指数移動平均のいずれを用いてもよい。

このように、下位レイヤ評価パラメータ取得部５は、ルーティングプロトコルから下位レイヤ評価パラメータを取得してもよい。例えば、ルーティングプロトコルとしてＲＦＣ６５５０で規定されたＲＰＬを用いる場合、通信経路上の各リンクのフレーム送信回数の平均値の累積加算値をルーティングプロトコルから取得できる。

また、下位レイヤ評価パラメータには、宛先ノードまでのホップ数を含めることができる。例えば、下位レイヤ評価パラメータに複数の次ホップノード候補を含めておき、フラグメントサイズ決定部３が個々の次ホップノード候補ごとにフラグメントサイズを決定してもよい。

図１１は、第４の実施形態における上位レイヤ種別と、上位レイヤ通信プロファイルと、下位レイヤ評価パラメータの閾値との対応関係を示すテーブルである。図１１のステップＳ２１〜Ｓ２４は図７のステップＳ２〜Ｓ４と同様である。ステップＳ２３の判定がＮＯの場合、すなわち、リアルタイム要件ＲＴ（Ｆ）が「−１」と「１」のいずれでもない場合は、フレーム送信回数の平均値の累積加算値ETX_pathがその最大許容値ETX_path_max以下か否かを判定し（ステップＳ２４）、最大許容値ETX_path_max以下であればロングフレームを選択し（ステップＳ２５）、最大許容値ETX_path_maxより大きければショートフレームを選択する（ステップＳ２６）。

図１２は第４の実施形態による通信装置１を複数台用いて構成される無線マルチホップネットワークシステムを示す図である。図１２は、図４と比べて、中継ノードＮ２の通信装置１がフラグメント化されたパケットの組立と再分割を行わない点で異なっている。すなわち、中継ノードＮ２では、フラグメント化されて受信されたパケットを、組立および再分割を行わずに、次の送り先に転送する処理を行う。

このように、第４の実施形態では、フレーム送信回数の平均値の累積加算値を下位評価パラメータとしてフラグメントサイズを決定するため、中継ノードでパケットの組立と再分割を行わない場合であっても、上位レイヤの通信品質を良好にでき、かつネットワークリソースの有効利用も図れる。

（第５の実施形態）
以下に説明する第５の実施形態では、コンテンツ種別まで参照してフラグメントサイズを決定するものである。

第５の実施形態に係る通信装置１は、例えば図５と同様に構成されており、上位レイヤ評価パラメータとして、例えば各ＩＰパケットのＤＳＣＰフィールドを使用することを想定している。

より具体的には、上位レイヤ評価パラメータとして、フロー識別情報、リアルタイム要件およびコンテンツ種別が使用される。フラグメントサイズ決定部３が決定したフラグメントサイズに対応するＤＳＣＰ値は、ＤＳＣＰフィールドに記述される。これにより、後続ノードの通信装置で、このＤＳＣＰフィールドを参照してフラグメント化を行うことができる。

本実施形態における上位レイヤプロトコルは、例えばＲＦＣ１８８９で規定されるＲＴＰ（A Transport Protocol for Real-Time Applications）である。コンテンツ種別は、ＲＴＰのＰＴ（Payload Type）を参照する。例えば、ＰＴが１４（MPEG1/MPEG2に対応）の場合、ＲＴＰペイロードの先頭４オクテットの部分にエンコードされるＲＦＣ２２５０に規定されるMPEG Viideo-specific headerのＰ（Picture Type）フィールドを参照する。Ｐフィールドは、階層符号化の階層レベルに対応する情報である。Ｐフィールド値が１の場合、基本階層である１フレームであることを示す。

このように、MPEG2などの階層符号化されたメディアデータを伝送する場合は、上位レイヤのコンテンツ種別として、階層符号化の階層レベルを使用してもよい。

本実施形態に係る通信装置１を複数台用いて構成される無線マルチホップネットワークシステムは、図４と同様に構成される。送信元ノードを含む通信経路上の各ノードでは、6LoWPANのフラグメント化を行う。なお、他の実施形態と同様に、送信元ノードでは、6LoWPANフラグメント化を行う前のＩＰパケットにＩＰフラグメント化を行ってもよい。

送信元ノードの通信装置１の内部構成は図５と同様であり、それ以外のノードの通信装置１の内部構成は図１と同様である。送信元ノード以外のノードの通信装置１は、上位レイヤ評価パラメータとして、例えばＩＰパケットのＤＳＣＰフィールドの値を使用する。ＤＳＣＰフィールドには、図２に示したように、ＤＳＣＰ値が記述されており、このＤＳＣＰ値によって、ロングフレームかショートフレームかを決定できる。

図１３は送信元ノードの通信装置１におけるフラグメントサイズ決定部３の処理手順の一例を示すフローチャートである。まず、フロー識別情報Ｆに対する上位レイヤプロトコルのコンテンツ種別まで参照するか否かを指定する情報CHECK_CONT(F)を確認し（ステップＳ３１）、１であれば、コンテンツ種別判別処理を起動する（ステップＳ３２）。０であれば、図１１のステップＳ２１以降と同様にフラグメントサイズの決定を行う（ステップＳ３３〜Ｓ３９）。

図１４は図１３のステップＳ３２のコンテンツ種別判別処理の詳細な処理手順を示すフローチャートである。まず、ＲＴＰヘッダのＰＴフィールド（RTP.PT）の値が１４か否かを判定する（ステップＳ４１）。１４であれば、次に、ＲＴＰペイロードのMPEG Viideo-specific headerのＰフィールド（RTP.PLD.MPH.P)が１か否かを判定する（ステップＳ４２）。１であればフラグメントサイズをショートフレームにし（ステップＳ４３）、１でなければロングフレームにする（ステップＳ４４）。ステップＳ４１にて１４でないと判定されると、フラグメントサイズをショートフレームにする（ステップＳ４５）。

このように、第５の実施形態では、コンテンツ種別まで参照してフラグメントサイズを決定するため、さらなるネットワークリソースの有効利用を図ることができる。また、送信元ノード以外のノードにおける通信装置１では、下位レイヤ評価パラメータを使用せずに、ＩＰパケットのＤＳＣＰフィールドを参照してフラグメントサイズを決定するため、通信装置１の内部構成を簡略化できる。さらに、パケットが暗号化されている等の理由で元々のフロー識別情報にアクセスできない場合にも、アクセスできる場合と同様の精度でフラグメントサイズを決定できる。

上述した第１〜第５の実施形態では、ＩＰパケットと6LoWPANフラグメント化を行う例を説明したが、図１５と図１６を用いて、6LoWPANフラグメント、ＩＰパケット、IEEE802.15.4フレームのデータ構造について説明する。

6LoWPANのフラグメントは、先頭フラグメントと２番目以降のフラグメントで異なっている。先頭フラグメントは、図１５（ａ）に示すように、先頭５ビットが"10000"で、その後に、１１ビットのdatagram_sizeフィールド３１、その後に１６ビットのdatagram_tag３２が続く。これに対して、２番目以降のフラグメントは、図１５（ｂ）に示すように、先頭５ビットが"11100"で、その後に、１１ビットのdatagram_sizeフィールド３３、その後に１６ビットのdatagram_tag３４、その後に８ビットのdatagra_offset３５が続く。datagram_sizeフィールド３３は、フラグメント化が行われる前のＩＰパケットの長さを表す。dataram_tag３４は、フラグメント化が行われる前のＩＰパケットを識別するタグで、同じＩＰパケットのフラグメントにはすべて同じ値が付与される。datagram_offset３５は、フラグメント化が行われる前のＩＰパケットの先頭からのオフセットを８オクテット単位で表したものである。

図１６は6LoWPANフラグメントをIEEE802.15.4のＭＡＣレイヤで伝送する場合のＭＡＣフレーム４０、6LoWPANフラグメント４１、およびＩＰパケット４２のフォーマットを示す図である。１６において、ＭＡＣフレーム４０は、ＭＨＲ（MAC Header）４３、Payload４４、ＭＦＲ（MAC Footer)４５で構成され、Payload４４部分に6LoWPANフラグメント４１が入る。

6LoWPANフラグメント４１は、Fragment Header４６とPayload４７とで構成され、Payload４７にIPパケット４２が入る。ＩＰパケット４２は、IP Header４８とPayload４９とで構成される。

上述した各実施形態において、フラグメントサイズは、例えば802.15.4フレームサイズに関する値である。

なお、上述した各実施形態は、6LoWPANのフラグメント化について説明したが、本発明は6LoWPANのフラグメント化に限定されるものではない。

また、図７、図９、図１１および図１３では、フラグメント化の処理手順を示したが、必ずしもこれらの処理手順と同様にフラグメント化を行うわけではない。パケットの種類や上位レイヤ評価パラメータ、下位レイヤ評価パラメータが変われば、フラグメント化の処理手順も変わる可能性がある。

上述した各実施形態に係る通信装置１は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、下位レイヤ評価パラメータ取得部５、上位レイヤ評価パラメータ取得部２、フラグメントサイズ決定部３、フラグメント制御部４は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、通信装置１は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、ＣＤ−ＲＯＭなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、フラグメントサイズ決定部３は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

１ 通信装置、２ 上位レイヤ評価パラメータ取得部、３ フラグメントサイズ決定部、４ フラグメント制御部、５ 下位レイヤ評価パラメータ取得部

Claims (11)

1. ネットワークを構成する複数レイヤのうち、上位側レイヤの評価パラメータを取得する上位レイヤ評価パラメータ取得部と、
   前記上位レイヤ評価パラメータ取得部にて取得された評価パラメータに基づいて、上位側レイヤの情報を含むパケットをフラグメントに分割する際のフラグメントサイズを決定するフラグメントサイズ決定部と、
   前記フラグメントサイズに基づいて、前記パケットを複数のフラグメントに分割するフラグメント制御部と、
   前記複数レイヤのうち、前記上位側レイヤよりも下位側のレイヤの評価パラメータを取得する下位レイヤ評価パラメータ取得部と、を備え、
   前記フラグメントサイズ決定部は、前記下位レイヤ評価パラメータ取得部および前記上位レイヤ評価パラメータ取得部にて取得された評価パラメータに基づいて、より上位のレイヤの情報を含むパケットをフラグメントに分割する際のフラグメントサイズを決定する通信装置。
2. 前記上位レイヤ評価パラメータ取得部で取得される評価パラメータは、ＩＰパケットのＩＰヘッダに含まれるＤＳＣＰフィールドの値を含む請求項１に記載の通信装置。
3. 前記上位レイヤ評価パラメータ取得部で取得される評価パラメータは、上位レイヤ種別を含む請求項１または２に記載の通信装置。
4. 前記上位レイヤ種別は、上位レイヤプロトコル名、フロー識別情報および上位レイヤ通信プロファイル名の少なくとも一つを含む請求項３に記載の通信装置。
5. 前記下位レイヤ評価パラメータ取得部で取得される評価パラメータは、ビットエラー率と、チャネルビジー率と、フラグメント化されたパケットの平均送信回数と、フラグメント化されたパケットの送信回数の平均値の累積加算値との少なくとも一つを含む請求項１乃至４のいずれか一項に記載の通信装置。
6. 前記下位レイヤ評価パラメータ取得部は、ルーティングプロトコルから前記評価パラメータを取得する請求項５に記載の通信装置。
7. 前記下位レイヤ評価パラメータ取得部で取得される評価パラメータは、宛先ノードまでのホップ数を含む請求項５または６に記載の通信装置。
8. 前記下位レイヤ評価パラメータ取得部で取得される評価パラメータは、次のホップ先ノードに関する情報を含んでおり、
   前記フラグメントサイズ決定部は、前記情報に基づいて、ホップ先ノードごとに前記フラグメントサイズを決定する請求項１乃至４のいずれか一項に記載の通信装置。
9. 前記フラグメントサイズ決定部は、受信パケットの上位レイヤのフロー識別情報を取得できない場合は、前記フラグメントサイズをリンクレイヤの最大フレームサイズとする請求項１乃至８のいずれかに記載の通信装置。
10. 前記フラグメントサイズ決定部は、決定した前記フラグメントサイズに対応するＤＳＣＰ（Differentiated Services Code Point）値をＩＰパケットのＤＳＣＰフィールドに書き込む請求項１乃至９のいずれかに記載の通信装置。
11. ネットワークを構成する複数レイヤのうち、上位側レイヤの評価パラメータを取得するステップと、
    前記取得された評価パラメータに基づいて、上位側レイヤの情報を含むパケットをフラグメントに分割する際のフラグメントサイズを決定するステップと、
    前記フラグメントサイズに基づいて、前記パケットを複数のフラグメントに分割するステップと、
    前記複数レイヤのうち、前記上位側レイヤよりも下位側のレイヤの評価パラメータを取得するステップと、を備え、
    前記フラグメントサイズを決定するステップは、前記上位側レイヤの評価パラメータおよび前記下位側レイヤの評価パラメータに基づいて、より上位のレイヤの情報を含むパケットをフラグメントに分割する際のフラグメントサイズを決定する、コンピュータに実行させるための通信制御プログラム。