JPWO2019058418A1

JPWO2019058418A1 - 通信装置

Info

Publication number: JPWO2019058418A1
Application number: JP2019542835A
Authority: JP
Inventors: 智也庄司; 鈴木　道奉; 道奉鈴木; 信幸内川
Original assignee: Hitachi Kokusai Electric Inc
Current assignee: Hitachi Kokusai Electric Inc
Priority date: 2017-09-19
Filing date: 2017-09-19
Publication date: 2020-10-08
Anticipated expiration: 2037-09-19
Also published as: WO2019058418A1; US11172051B2; US20210051216A1; JP7008714B2

Abstract

複数の通信装置から構成され、１つ以上の通信装置を経由して通信を行う無線システムに用いられる通信装置は、前記複数の通信装置間での近隣探索メッセージとその応答、またはアドホックルーティングプロトコルによる経路制御情報の交換に基づいて通信制御情報の圧縮可否を判断する第一手段と、前記通信制御情報の圧縮が可能な場合、前記通信制御情報の内容を判断し、冗長な情報または常時固定な情報を削減または置換することで、前記通信制御情報の情報量を圧縮する第二手段と、を備える。

Description

本開示は通信装置に関し、例えばＩＰｖ６ネットワークに用いる通信装置に適用可能である。

今日のネットワーク通信方式として、インターネット(ＷＥＢ)、電子メールではＩＰ（Internet Protocol）が用いられている。一部の広帯域回線を除けば、現在多く使用されている方式はＩＰｖ４（Internet Protocol version 4）であり、送信元／宛先を示すものとして３２ビットからなるアドレス（ＩＰアドレス）が用いられている。インターネット通信においては、このＩＰアドレスを各送信元／宛先にユニークに割り当てるグローバルＩＰアドレスを採用し、ＩＰアドレスに応じて、個々の発信元／宛先を判別している。しかし、インターネットの世界は急速に広がりを見せており、ＩＰｖ４アドレスの３２ビットで定義可能な範囲が全て使用され、新規に割り当てできない状態、すなわちグローバルアドレスの枯渇が問題となっている。

これを解決するためにＩＥＴＦ（Internet Engineering Task Force）では、次世代のネットワーク通信方式とし、ＩＰアドレスを３２ビットから１２８ビットに拡張したＩＰｖ６（Internet Protocol version 6）の利用を提唱し、移行を推奨している。

無線ネットワークにおいては、ＷｉＭＡＸ(Worldwide Interoperability for Microwave Access)にて、モバイルＩＰ（Mobile IP）と呼ばれる通信方式を採用している。しかし、システムが複雑であることや広帯域回線を利用する前提であることから、簡易利用はできず、無線ＬＡＮ等を初めとした一般無線回線では普及は進んでいない状況である。

このような背景から、簡易的または広帯域な無線ネットワークにおいてもＩＰｖ６でのネットワークおよび通信は今後利用されていく状況にあるが、一方でアドレス情報の拡張により制御情報が増大し、無線回線の使用率が増大することから、利用者が本来宛先に送るべきデータ量が抑制されてしまう恐れがある。

ＢＬＥ（Bluetooth Low Energy）を初めとしたＰＡＮ(Personal Area Network)では、上記の懸念から独自に６ＬｏＷＰＡＮと呼ばれる通信方式を決め、情報量の削減を実施しているが、利用する場合は全通信装置の対応が必要であることや、ＰＡＮの特性上通信相手が小規模であること、さらにはデータリンク層プロトコルであるＢＬＥプロトコルの情報を利用した削減処理から、同一の方式を中規模ならびに広帯域ネットワークに適用することは不可能である。

特開２０１６−２５４０１号公報

前述の通り、ＩＰｖ６ネットワークへの移行が進められる一方で、無線ネットワークへのトラフィック増加が見込まれるが、従来方式は小規模かつＢＬＥの方式を利用した情報量削減処理であるため、中規模または大規模な無線ネットワークでは適用できない。中規模および大規模な無線ネットワークでは様々な通信装置が存在するため、低性能の通信装置では情報量削減処理ができない可能性もあるため、情報圧縮処理のできない通信装置を考慮した上での、最適なトラフィック抑制が必要になる。
本開示の課題は、情報圧縮処理のできない通信装置を考慮した上での、最適なトラフィック抑制が可能な通信装置を提供することにある。
その他の課題と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本開示のうち代表的なものの概要を簡単に説明すれば下記の通りである。
すなわち、複数の通信装置から構成され、１つ以上の通信装置を経由して通信を行う無線システムに用いられる通信装置は、前記複数の通信装置間での近隣探索メッセージとその応答、またはアドホックルーティングプロトコルによる経路制御情報の交換に基づいて通信制御情報の圧縮可否を判断する第一手段と、前記通信制御情報の圧縮が可能な場合、前記通信制御情報の内容を判断し、冗長な情報または常時固定な情報を削減または置換することで、前記通信制御情報の情報量を圧縮する第二手段と、を備える。

上記通信装置によれば、情報圧縮処理のできない通信装置を考慮した上での、最適なトラフィック抑制が可能となる。

ネットワーク構成を説明する図である。比較例に係る通信装置の構成を説明する図である。実施例に係る通信装置の構成を説明する図である。図３の通信装置の無線送信の処理を説明する図である。図３の通信装置の無線受信の処理を説明する図である。ＩＰｖ６ヘッダ情報を説明する図である。ＩＰｖ６フラグメントヘッダ情報を説明する図である。ＵＤＰヘッダ情報を説明する図である。圧縮アルゴリズム情報の例を説明する図である。圧縮ＩＰｖ６ヘッダ情報の例を説明する図である。圧縮ＩＰｖ６フラグメントヘッダ情報の例を説明する図である。圧縮ＵＤＰヘッダ情報の例を説明する図である。圧縮前の全ヘッダ情報の例を説明する図である。圧縮後の全ヘッダ情報の例を説明する図である。

実施例形態の通信装置は無線通信におけるＩＰｖ６通信または中継（ルーティング）において通信トラフィックの管理、抑制に関する機能を備える。実施形態では、ＩＰｖ６のアドレス情報を初めとした制御情報（ヘッダ情報）の削減ならびに情報置換を行うことで、制御情報を圧縮しトラフィックを抑制することができる。また、ヘッダ情報が圧縮可能な通信装置を判断し、ヘッダ情報が圧縮不可能な通信装置に対しては圧縮を行わずに無線伝送することによって、ネットワークの通信不全などを未然に防ぐことができる。

以下、実施例について、図面を用いて説明する。ただし、以下の説明において、同一構成要素には同一符号を付し繰り返しの説明を省略することがある。

ネットワークの構成例について図１を用いて説明する。図１はネットワーク構成を示す図である。ネットワーク１００は通信装置＃１（１０１）、通信装置＃２（１０２）、通信装置＃３（１０３）、通信装置＃４（１０４）および通信装置＃５（１０５）で構成される。

ネットワーク１００では、通信装置＃１〜＃５（１０１〜１０５）がアドホックネットワーク（無線ネットワーク（点線両方向矢印）を構成しており、各通信装置＃１〜＃５（１０１〜１０５）には、それぞれ有線自立ネットワーク（実線）で端末＃１〜＃５（１１１〜１１５）が接続されている。通信装置＃１（１０１）には、端末＃６（１１６）も接続されている。通信装置＃１〜＃５（１０１〜１０５）は有線自律ネットワーク及び無線ネットワークの双方を中継する通信装置である。

次に、通信装置の構成例について図２、３を用いて説明する。図２は比較例に係る通信装置の構成を示す図である。図３は実施例に係る通信装置の構成を示す図である。

図２に示すように、比較例に係る通信装置２００では、レイヤー４（Ｌ４）であるトランスポート層以上に、ＩＣＭＰｖ６（Internet Control Message Protocol for IPv6）とアドホックルーティングプロトコル（無線ネットワークルーティングプロトコル）を実現するネットワークモジュール（ＮＷＭ）２０１が配置され、レイヤー３（Ｌ３）であるネットワーク（ＮＷ）層にルーティングテーブル（ＲＴ）２０７配置される。また、レイヤー２（Ｌ２）である媒体アクセス制御（ＭＡＣ）層に有線ネットワークのＭＡＣ層（Ethernet MAC）２１０および無線ネットワークのＭＡＣ層（Wireless MAC）２１１が配置され、レイヤー１（Ｌ１）である物理（ＰＨＹ）層に有線ネットワークのＰＨＹ層（Ethernet PHY）２１２および無線ネットワークのＰＨＹ層（Wireless Network PHY）２１３が配置される。

有線自律ネットワークからのＩＰｖ６パケット入力があった場合、通信装置２００は、自身のルーティングテーブル２０７に登録されている通信経路を確認する。確認の後、ＩＰｖ６パケットの宛先ＩＰアドレスと自身のルーティングテーブル２０７に登録されている通信経路に合致したものがあれば、登録時に設定した、出力インタフェースに対して、ＩＰｖ６パケットを出力する。ここで、ＩＰｖ６パケットは、ＩＰｖ６ヘッダとペイロード（拡張ヘッダおよびデータ）で構成される。

また、ルーティングテーブル２０７は、無線側のインタフェースから入力されたＩＰｖ６パケットにも同様に作用する。その際、ルーティングテーブル２０７に登録されている経路の出力先が有線自律ネットワーク側インタフェースにも、また無線側のインタフェースにもなりうる。また通信装置２００は、入力データに合致した経路の情報を一時的な記憶領域（ルーティングテーブルキャッシュ（ＲＴＣ））２１７に保管する機能を有する。

次に、図３に示すように、実施例に係る通信装置３００は比較例に係る通信装置の構成に加え、ＮＷ層にＩＰｖ６ヘッダ情報の圧縮および伸張等を行うＩＰｖ６Ｃｏｍｐ／ＤｅＣｏｍｐ（ＩＰ６ＣＤ）モジュール３０１を備える。ＩＰ６ＣＤモジュール３０１は例えばソフトウェアで構成される。よって、通信装置３００はソフトウェアを実行するＣＰＵとソフトウェアを格納するメモリとを備える。

次に、通信装置３００のＩＰｖ６ヘッダの圧縮可否の情報通知および判断における処理について図４、５を用いて説明する。図４は図３の通信装置の無線送信時の処理を示すフローチャートである。図５は図３の通信装置の無線受信時の処理を示すフローチャートである。

図４に示すように、まず、ＩＰ６ＣＤモジュール３０１は有線ネットワークからＩＰｖ６パケットを受信する（ステップＳ１１）。次に、ＩＰ６ＣＤモジュール３０１では、入力された情報（受信したＩＰｖ６パケットの上位プロトコル）が自装置を送信元とするＩＣＭＰｖ６による近隣ノード探索メッセージかどうかを判別し（ステップＳ１２）、近隣ノード探索メッセージの場合（ＹＥＳの場合）は、メッセージ内のペイロード情報に自通信装置が圧縮可能な旨の情報を格納して（ステップＳ１３）、ＩＰｖ６パケットを無線ネットワークのＭＡＣ層２１１以降に出力（転送）して、無線送信する（ステップＳ１４）。ステップＳ１２での判断がＮＯの場合は、受信したＩＰｖ６パケットの上位プロトコルがアドホックルーティングメッセージかどうかを判断し（ステップＳ１５）、ＹＥＳの場合はステップＳ１３に移る。これにより、近隣ノード探索メッセージ送信またはアドホックルーティングメッセージ送信において通信装置３００は自装置がＩＰｖ６ヘッダ情報を圧縮可能であること示す情報を付与して通知することができる。

一方、無線受信の場合は、図５に示すように、無線ネットワークからＩＰｖ６パケットを受信する（ステップＳ２１）。次に、ＩＰ６ＣＤモジュール３０１では、無線ネットワークのＭＡＣ層２１１から入力されたデータ（受信したＩＰｖ６パケットの上位プロトコル）がＩＣＭＰｖ６による近隣ノード探索メッセージかどうかを判別し（ステップＳ２２）、近隣ノード探索メッセージであれば（ＹＥＳの場合）、近隣ノード探索メッセージ内に通信装置が圧縮可能な旨の情報（圧縮可能情報）が格納されているかを確認する（ステップＳ２３）。近隣ノード探索メッセージ内に圧縮可能情報が格納されているかどうかを判断し（ステップＳ２４）、格納されている場合（ＹＥＳの場合）は、対象の通信装置に送信するＩＰｖ６パケットに対してはＩＰｖ６ヘッダ情報が圧縮可能であること（圧縮可能通信装置としてそのＩＰｖ６アドレス）をＩＰｖ６圧縮データベース（IPv6CompDataBase）に登録する（ステップＳ２５）。そして、ＩＰｖ６パケットを有線ネットワーク側に転送する（ステップＳ２６）。ステップＳ２４でＮＯの場合はステップＳ２６に移る。この処理は上位のアドホックルーティングによる近接ノード確認処理についても同様である（ステップＳ２２での判断がＮＯの場合は、受信したパケットの上位プロトコルがアドホックルーティングメッセージかどうかを判断し（ステップＳ２７）、ＹＥＳの場合はステップＳ２３に移る）。

上記実施後、通信装置３００に有線自律ネットワークからＩＰｖ６パケット入力があった場合はステップＳ１２でＮＯ、ステップＳ１５でＮＯになり、ＩＰｖ６圧縮データベースの内容を確認（ＩＰｖ６圧縮データベースで圧縮可能な通信装置を検索）し（ステップＳ１６）、宛先ＩＰｖ６アドレスまたは宛先ＭＡＣアドレスが圧縮可能な通信装置のものかどうかを判断する（ステップＳ１７）。ＩＰｖ６パケットの宛先が圧縮可能な通信装置であった場合、またはＩＰｖ６パケット中継先が圧縮可能な通信装置であった場合（ステップＳ１７でＹＥＳの場合）は、ＩＰｖ６ヘッダ情報の圧縮処理を実施する（ステップＳ１８）。そして、圧縮したＩＰｖ６パケットを無線ネットワークのＭＡＣ層２１１以降に出力（転送）して、無線送信する（ステップＳ１４）。これにより、圧縮可能な通信装置のみに対して圧縮済ＩＰｖ６パケットを送信することができる。

通信装置３００に無線ネットワークからＩＰｖ６パケット入力があった場合はステップＳ２２でＮＯ、ステップＳ２７でＮＯになり、受信したＩＰｖ６パケットの先頭が圧縮ヘッダ情報かどうかを判断する（ステップＳ２８）。ＩＰｖ６パケットの先頭が圧縮ヘッダ情報の場合（ＹＥＳの場合）、ＩＰｖ６パケットの伸長処理を行い（ステップＳ２９）、ＩＰｖ６パケットを有線ネットワーク側に転送する（ステップＳ２６）。ステップＳ２８でＮＯの場合、ＩＰｖ６パケットを有線ネットワーク側に転送する（ステップＳ２６）。

次に、ステップＳ１８の圧縮処理について図６〜１４を用いて説明する。図６はＩＰｖ６ヘッダ情報を示す図である。図７はＩＰｖ６フラグメントヘッダ情報を示す図である。図８はＵＤＰヘッダ情報を示す図である。図９は圧縮アルゴリズム情報の例を示す図である。図１０は圧縮ＩＰｖ６ヘッダ情報の例を示す図である。図１１は圧縮ＩＰｖ６フラグメントヘッダ情報の例を示す図である。図１２は圧縮ＵＤＰヘッダ情報の例を示す図である。図１３は圧縮前の全ヘッダ情報の例を示す図である。図１４は圧縮後の全ヘッダ情報の例を示す図である。

ＩＰｖ６パケットとして、ＩＰｖ６ヘッダの他に、拡張ヘッダとしてＩＰｖ６フラグメントヘッダおよびＵＤＰヘッダを有する例について以下説明する。なお、ＩＰｖ６パケットでは拡張ヘッダの後にペイロード情報が格納される。

図６に示すように、ＩＰｖ６ヘッダは３２０ビット（４０オクテット）長であり、４ビットのバージョン（ＩＰｖ６ Version）、８ビットのトラフィック・クラス（Traffic Class）、１６ビットのフロー・ラベル（Flow Label）、１６ビットのペイロード長（Payload Length）、８ビットのネクスト・ヘッダ（Next Header）、８ビットのホップ・リミット（Hop Limit）、１２８ビットの送信元アドレス（Source Address）、１２８ビットの宛先アドレス（Destination Address）、の各フィールドを有する。

バージョン（ＩＰｖ６ Version）にはＩＰｖ６を表す「０１１０（２進数表示）」が格納される。

トラフィック・クラス（Traffic Class）にはパケット送信時のＱｏＳ（Quality of Service）を指定し、パケット送信時の優先度を表す情報が格納される。

フロー・ラベル（Flow Label）にはマルチキャスト通信などにおいて、通信経路の品質を確保したり、経路を優先的に選択させたりするための情報が格納される。

ペイロード長（Payload Length）には拡張ヘッダとペイロード・データの合計サイズを指定する情報が格納される。

ネクスト・ヘッダ（Next Header）にはこのＩＰｖ６ヘッダに続く、拡張ヘッダや上位プロトコルのタイプを表す情報が格納される。拡張ヘッダが複数ある場合は、最初の拡張ヘッダのタイプを表す情報が格納される。以後のヘッダは、数珠つなぎで並べられる。

ホップ・リミット（Hop Limit）いは通過可能なルータの最大数が格納される。ルータを１つ通過するたびに１ずつ減算される。０になるとパケットは破棄され、送信元に対してＩＣＭＰｖ６の「hop limit exceeded in transit」が返信される。

送信元アドレス（Source Address）には送信元ノードのＩＰｖ６アドレスが格納される。宛先アドレス（Destination Address）は送信先ノードのＩＰｖ６アドレスが格納される。

ＩＰｖ６フラグメントヘッダは、宛先へパスＭＴＵ（Maximum Transmission Unit）に入るより大きいパケットを送信するために送信元によって用いられるヘッダである。ＩＰｖ６フラグメントヘッダは直前のヘッダのネクスト・ヘッダ値“４４”によって識別され、図７に示すようなフォーマットである。

ＩＰｖ６フラグメントヘッダは６４ビット長であり、８ビットのネクスト・ヘッダ（Next Header）、８ビットの予約済み（ＲＳＶ）、１３ビットのフラグメント・オフセット（Fragment Offset）、２ビットの予約済み（ＲＳＶ）、１ビットのフラグ（Flag）、３２ビットの識別子（Identification）、の各フィールドを有する。

ネクスト・ヘッダ（Next Header）には元のパケットのフラグメント可能部分の初期ヘッダタイプを識別する情報が格納される。二つのフィールドの予約済み（ＲＳＶ）はそれぞれ転送時に０に初期化され、受信時に無視される。

フラグメント・オフセット（Fragment Offset）には符号無し整数で、このヘッダに続くデータの８オクテット単位のオフセットで、元のパケットのフラグメント可能部分の開始からの相対値が格納される。

フラグ（Flag）にはフラグメント情報が格納され、さらにフラグメント有る場合は１、最終フラグメントの場合は０が格納される。

識別子（Identification）にはフラグメント化されたパケットの識別用番号が格納される。パケットをフラグメント化すると、すべて同じ識別子を持つ。これを元に、元のパケットが識別・復元される。

図８に示すように、ＵＤＰヘッダは６４ビット長であり、１６ビットの送信元ポート番号（Source Port）、宛先ポート番号（Destination Port）、セグメント長（Segment Length）、チェックサム（Checksum）、の各フィールドを有する。

送信元ポート番号（Source Port）には送信元のアプリケーションを識別するための番号が格納される。返信を要求しないＵＤＰパケットの場合は、送信元ポート番号を０にする。宛先ポート番号（Destination Port）は宛先のアプリケーションを識別するための番号が格納される。

セグメント長（Segment Length）にはＵＤＰパケットの長さを表す情報が格納され、ＵＤＰで送信するデータ部分の長さを加えたバイト数が格納される。

チェックサム（Checksum）にはＵＤＰパケットの整合性を検査するための検査用データが格納される。

ＩＰｖ６ヘッダ、ＩＰｖ６フラグメントヘッダおよびＵＤＰヘッダの圧縮処理は、図９に記載する圧縮アルゴリズム情報により実施する。図６〜図８に示すＩＰｖ６ヘッダ、ＩＰｖ６フラグメントヘッダおよびＵＤＰヘッダの内容が、図９の圧縮アルゴリズム情報の内容（条件）と一致するものについては、圧縮処理およびデータ置換処理を実施する。

圧縮処理およびデータ置換を実施した場合は圧縮済ヘッダ（圧縮ヘッダ可変部）の前に図１０〜図１２に示すような圧縮情報ヘッダ（圧縮ヘッダ固定部）を配置する。

図１０に示すように、圧縮情報ＩＰｖ６ヘッダは１６ビット長であり、４ビットのバージョン（ＩＰｖ６ Version）、２ビットのＱｏＳ情報圧縮情報（qos_comp）、１ビットの次プロトコル圧縮情報（nexthead_comp）、２ビットのホップ情報圧縮情報（hoplimit_comp）、１ビットのペイロード長（payload length）、２ビットの送信元アドレス圧縮情報（sa_mode）、１ビットのマルチキャストフラグ（m_flag）、３ビットの宛先アドレス圧縮情報（da_mode）のフィールドを有する。

バージョン（ＩＰｖ６ Version）には圧縮情報ＩＰｖ６ヘッダであることを示す情報（0x7）が格納される。

ＱｏＳ情報圧縮情報（qos_comp）にはトラフィック・クラスのフィールドおよびフロー・ラベルのフィールドの圧縮の情報が格納される。トラフィック・クラスの上位６ビットはＤＳＣＰ（Differentiated Services Code Point）を格納している。最後の２ビットはＥＣＮ（Explicit Congestion Notification）という輻輳制御の仕組みに使われる。ＥＣＮは、ＥＣＴ（ECN Capable Transport）とＣＥ（Congestion Experienced）の２ビットから構成され、ネットワークが輻輳を起こした際、実際にネットワーク機器がパケット破棄を始める前に、データ通信をしているホストに輻輳を知らせる役目を持つ。トラフィック・クラスおよびフロー・ラベルのフィールドの格納値が０の場合、ＱｏＳ情報圧縮情報に３を格納し、トラフィック・クラスおよびフロー・ラベルのフィールドを０バイトに圧縮する。トラフィック・クラスにＤＳＣＰを格納する場合は、ＱｏＳ情報圧縮情報に２を格納し、トラフィック・クラスおよびフロー・ラベルのフィールドを１バイトに圧縮する。トラフィック・クラスにＥＣＮを格納し、フロー・ラベルを格納する場合は、ＱｏＳ情報圧縮情報に１を格納し、トラフィック・クラスおよびフロー・ラベルのフィールドを３バイトに圧縮する。トラフィック・クラスおよびフロー・ラベルのフィールドを圧縮しない場合は、ＱｏＳ情報圧縮情報に０を格納し、トラフィック・クラスおよびフロー・ラベルのフィールドは２８ビットのままにする。

次プロトコル圧縮情報（nexthead_comp）にはネクスト・ヘッダのフィールドの圧縮情報が格納される。ネクスト・ヘッダがない場合、次プロトコル圧縮情報に１を格納し、ネクスト・ヘッダのフィールドを省略する。ネクスト・ヘッダのフィールドを圧縮しない場合、次プロトコル圧縮情報に０を格納し、ネクスト・ヘッダのフィールドは８ビットのままにする。

ホップ情報圧縮情報（hoplimit_comp）にはホップ・リミットのフィールドの圧縮情報が格納される。ホップ・リミットのフィールドの格納値が２５４、２５５の場合は、ホップ情報圧縮情報に３を格納し、ホップ・リミットのフィールドを省略する。ホップ・リミットのフィールドの格納値が６３、６４の場合は、ホップ情報圧縮情報に２を格納し、ホップ・リミットのフィールドを省略する。よって、ホップ・リミットのフィールドの値がホップ情報圧縮情報にデータ置換される。ホップ・リミットのフィールドの格納値が１の場合は、ホップ情報圧縮情報に１を格納し、ホップ・リミットのフィールドを省略する。ホップ・リミットのフィールドを圧縮しない場合は、ホップ情報圧縮情報に０を格納し、ホップ・リミットのフィールドは８ビットのままにする。

ペイロード長圧縮情報（payload length）にはペイロード長のフィールドの圧縮情報が格納される。ペイロード長のフィールドの格納値が２５５以下の場合、ペイロード長圧縮情報に１を格納し、ペイロード長のフィールドを８ビットに圧縮する。ペイロード長のフィールドを圧縮しない場合は、ペイロード長圧縮情報に０を格納し、ペイロード長のフィールドは１６ビットのままにする。

送信元アドレス圧縮情報（sa_mode）には送信元アドレスのフィールドの圧縮情報が格納される。送信元アドレスのフィールドのアドレスがリンクローカルアドレスであり、かつＥＩＡであり、かつＭＡＣアドレスを無線送信する場合（EIA + MAC ADDRESS TRANSPARENT）、送信アドレス元圧縮情報に３を格納し、送信元アドレスのフィールドを４８ビットに圧縮する。送信元アドレスのフィールドのアドレスがリンクローカルアドレスであり、かつＥＩＡである場合（link local : EIA）、送信アドレス圧縮情報に２を格納し、送信元アドレスのフィールドを９６ビットに圧縮する。送信元アドレスのフィールドのアドレスがリンクローカルアドレスであり、かつＥＩＡでない場合（link local : NOT_EIA）、送信元アドレス圧縮情報に１を格納し、送信元アドレスのフィールドを１１２ビットに圧縮する。送信元アドレスのフィールドを圧縮しない場合は、送信元アドレス圧縮情報に０を格納し、送信元アドレスのフィールドは１２８ビットのままにする。

マルチキャストフラグ（m_flag）には宛先アドレスがマルチキャストであるかどうかの情報が格納される。

宛先アドレス圧縮情報（da_mode）には宛先アドレスのフィールドの圧縮情報が格納される。宛先アドレスのフィールドのアドレスがユニキャストであり、送信元アドレスと１２０ビット重複している場合（same prefix source）、宛先アドレス圧縮情報に７を格納し、宛先アドレスのフィールドを８ビットに圧縮する。宛先アドレスのフィールドのアドレスがユニキャストであり、送信元アドレスと１１２ビット重複している場合、宛先アドレス圧縮情報に６を格納し、宛先アドレスのフィールドを１６ビットに圧縮する。宛先アドレスのフィールドのアドレスがユニキャストであり、送信元アドレスと９６ビット重複している場合、宛先アドレス圧縮情報に５を格納し、宛先アドレスのフィールドを３２ビットに圧縮する。宛先アドレスのフィールドのアドレスがユニキャストであり、送信元アドレスと８０ビット重複している場合、宛先アドレス圧縮情報に４を格納し、宛先アドレスのフィールドを４８ビットに圧縮する。宛先アドレスのフィールドのアドレスがユニキャストであり、送信元アドレスと６４ビット重複している場合、宛先アドレス圧縮情報に３を格納し、宛先アドレスのフィールドを６４ビットに圧縮する。宛先アドレスのフィールドのアドレスがユニキャストのリンクローカルアドレスであり、かつＥＩＡである場合（link local）、宛先アドレス圧縮情報に２を格納し、宛先アドレスのフィールドを９６ビットに圧縮する。宛先アドレスのフィールドのアドレスがユニキャストのリンクローカルアドレスであり、かつ送信元と同一ベンダである場合（link local same vender）、宛先アドレス圧縮情報に１を格納し、宛先アドレスのフィールドを２４ビットに圧縮する。

図１１に示すように、圧縮情報ＩＰｖ６フラグメントヘッダは１６ビット長であり、１ビットの次プロトコル圧縮情報（nexthead_comp）、１ビットのIdentification圧縮情報（ID_comp）、１ビットのフラグメントフラグ（flag）、１３ビットのフラグメント・オフセット（fragment offset）のフィールドを有する。

Identification圧縮情報（ID_comp）には識別子のフィールドの圧縮情報が格納される。識別子のフィールドが８ビット表現以下である場合、Identification圧縮情報に３を格納し、識別子のフィールドを８ビットに圧縮する。Identificationのフィールドが１６ビット表現以下である場合、Identification圧縮情報に２を格納し、識別子のフィールドを１６ビットに圧縮する。Identificationのフィールドが２４ビット表現以下である場合、Identification圧縮情報に１を格納し、識別子のフィールドを２４ビットに圧縮する。識別子のフィールドを圧縮しない場合、Identification圧縮情報に０を格納し、識別子のフィールドは３２ビットのままにする。

フラグメントフラグ（flag）にはフラグメントがあるかどうかの情報が格納される。フラグメント・オフセット（fragment offset）にはフラグメント・オフセットのフィールドの値が格納される。

図１２に示すように、圧縮情報ＵＤＰヘッダは８ビット長であり、１ビットのポート番号圧縮可否情報（port_comp）、２ビットの送信元ポート番号圧縮情報（srcportcomp）、３ビットの宛先ポート番号圧縮情報（dstportcomp）、１ビットのチェックサム圧縮情報（checksum_comp）、１ビットのペイロード長圧縮情報（len_comp）のフィールドを有する。

ポート番号圧縮可否情報（port_comp）にはポート番号の圧縮が可能かどうかの情報が格納される。ポート番号を圧縮する場合、ポート番号圧縮可否情報に１を格納し、ポート番号を圧縮しない場合、ポート番号圧縮可否情報に０を格納する。

送信元ポート番号圧縮情報（srcportcomp）には送信元ポート番号のフィールドの圧縮情報が格納される。ポート番号が規定の範囲の場合、例えば５００００の場合は１、６００００の場合は２、３００００の場合は３を格納し、ポート番号が３０００１であれば、３を格納値し、ポート情報を１バイトに圧縮する。送信元ポート番号のフィールドを圧縮しない場合、送信元ポート番号圧縮情報に０を格納し、送信元ポート番号のフィールドを２バイトのままとする。

宛先ポート番号圧縮情報（srcportcomp）には宛先ポート番号のフィールドの圧縮情報が格納される。ポート番号が規定の範囲の場合、送信元ポート番号圧縮情報と同様である。宛先ポート番号が送信元ポート番号と同じである場合（dst port same）、宛先ポート番号圧縮情報に４を格納し、宛先ポート番号を省略する。０＜（宛先ポート番号）−（送信元ポート番号）＜２５５である場合(dst port differ less than plus 255)、宛先ポート番号圧縮情報に５を格納し、宛先ポート番号のフィールドを１バイトに圧縮する。０＞（宛先ポート番号）−（送信元ポート番号）＞−２５５である場合(dst port differ less than mius 255)、宛先ポート番号圧縮情報に６を格納し、宛先ポート番号のフィールドを１バイトに圧縮する。宛先ポート番号のフィールドを圧縮しない場合、宛先ポート番号圧縮情報に０を格納し、宛先ポート番号のフィールドを２バイトのままとする。

チェックサム圧縮情報（checksum_comp）にはチェックサムのフィールドの圧縮情報が格納される。チェックサムのフィールドを圧縮する場合、チェックサム圧縮情報に１を格納し、チェックサムのフィールドを省略する。この場合、受信側でチェックサムを計算し再生する。チェックサムのフィールドを圧縮しない場合、チェックサム圧縮情報に０を格納し、チェックサムのフィールドは２バイトのままとする。

ペイロード長圧縮情報（len_comp）にはセグメント長のフィールドの圧縮情報が格納される。セグメント長が２５５以下の場合、ペイロード長圧縮情報に１を格納し、セグメント長のフィールドを１バイトに圧縮する。セグメント長のフィールドを圧縮しない場合、ペイロード長圧縮情報に０を格納し、セグメント長のフィールドは２バイトのままとする。

図１３に示すように、圧縮前の全ヘッダ情報（ＩＰｖ６ヘッダ、ＩＰｖ６フラグメントヘッダ、ＵＤＰヘッダ）は５６バイト長であり、図１４に示すように圧縮後の全ヘッダ情報は２２バイト長である。なお、図１４では、トラフィック・クラスおよびフロー・ラベルが０バイト、ペイロード長が１バイト、ネクスト・ヘッダが１バイト、ホップ・リミットが０バイト、送信元アドレスが６バイト、宛先アドレスが６バイトに圧縮されている。セグメント長が１バイトに圧縮されている。

図１４に示すような圧縮されたＩＰｖ６ヘッダを含むＩＰｖ６パケットを受信した通信装置は、図１０〜１２に示すような圧縮情報ヘッダに基づいて伸長処理を実施し、図１３に示すようなＩＰｖ６ヘッダを得る。

以上、本発明者によってなされた発明を実施形態および実施例に基づき具体的に説明したが、本発明は、上記実施形態および実施例に限定されるものではなく、種々変更可能であることはいうまでもない。

１００・・・ネットワーク
１０１・・・通信装置
１１１・・・端末
２００・・・通信装置
２０１・・・ネットワークモジュール
２０７・・・ルーティングテーブル
２０８・・・有線自律ネットワークのインタフェース
２０９・・・無線自律ネットワークのインタフェース
２１０・・・有線ネットワークのＭＡＣ層（Ethernet MAC）
２１１・・・無線ネットワークのＭＡＣ層（Wireless Network MAC）
２１２・・・有線ネットワークのＰＨＹ層（Ethernet PHY）
２１３・・・無線ネットワークのＰＨＹ層（Wireless Network PHY）
２１７・・・ルーティングテーブルキャッシュ（ＲＴＣ）
３０１・・・ＩＰｖ６Ｃｏｍｐ／ＤｅＣｏｍｐ（ＩＰ６ＣＤ）モジュール

本開示のうち代表的なものの概要を簡単に説明すれば下記の通りである。
すなわち、複数の通信装置から構成され、１つ以上の通信装置を経由して通信を行う無線システムに用いられる通信装置は、前記複数の通信装置間での近隣ノード探索メッセージとその応答、またはアドホックルーティングプロトコルによる経路制御情報の交換に基づいて通信制御情報の圧縮可否を判断する第一手段と、前記通信制御情報の圧縮が可能な場合、前記通信制御情報の内容を判断し、冗長な情報または常時固定な情報を削減または置換することで、前記通信制御情報の情報量を圧縮する第二手段と、を備える。

図１０に示すように、圧縮情報ＩＰｖ６ヘッダは１６ビット長であり、４ビットのバージョン（ＩＰｖ６ Version）、２ビットのＱｏＳ情報圧縮情報（qos_comp）、１ビットの次プロトコル圧縮情報（nexthead_comp）、２ビットのホップ情報圧縮情（hoplimit_comp）、１ビットのペイロード長圧縮（payload-comp）、２ビットの送信元アドレス圧縮情報（sa_mode）、１ビットのマルチキャストフラグ（m_flag）、３ビットの宛先アドレス圧縮情報（da_mode）のフィールドを有する。

ペイロード長圧縮情報（payload-comp）にはペイロード長のフィールドの圧縮情報が格納される。ペイロード長のフィールドの格納値が２５５以下の場合、ペイロード長圧縮情報に１を格納し、ペイロード長のフィールドを８ビットに圧縮する。ペイロード長のフィールドを圧縮しない場合は、ペイロード長圧縮情報に０を格納し、ペイロード長のフィールドは１６ビットのままにする。

送信元アドレス圧縮情報（sa_mode）には送信元アドレスのフィールドの圧縮情報が格納される。送信元アドレスのフィールドのアドレスがリンクローカルアドレスであり、かつＥＩＡであり、かつＭＡＣアドレスを無線送信する場合（EIA + MAC ADDRESSTRANSPARENT）、送信元アドレス圧縮情報に３を格納し、送信元アドレスのフィールドを４８ビットに圧縮する。送信元アドレスのフィールドのアドレスがリンクローカルアドレスであり、かつＥＩＡである場合（link local : EIA）、送信元アドレス圧縮情報に２を格納し、送信元アドレスのフィールドを９６ビットに圧縮する。送信元アドレスのフィールドのアドレスがリンクローカルアドレスであり、かつＥＩＡでない場合（linklocal : NOT_EIA）、送信元アドレス圧縮情報に１を格納し、送信元アドレスのフィールドを１１２ビットに圧縮する。送信元アドレスのフィールドを圧縮しない場合は、送信元アドレス圧縮情報に０を格納し、送信元アドレスのフィールドは１２８ビットのままにする。

ポート番号圧縮可否情報（port_comp）には送信元ポート番号と宛先ポート番号の中の少なくとも一つのポート番号の圧縮が可能かどうかの情報が格納される。ポート番号を圧縮する場合、ポート番号圧縮可否情報に１を格納し、ポート番号を圧縮しない場合、ポート番号圧縮可否情報に０を格納する。

宛先ポート番号圧縮情報（dstportcomp）には宛先ポート番号のフィールドの圧縮情報が格納される。ポート番号が規定の範囲の場合、送信元ポート番号圧縮情報と同様である。宛先ポート番号が送信元ポート番号と同じである場合（dst port same）、宛先ポート番号圧縮情報に４を格納し、宛先ポート番号を省略する。０＜（宛先ポート番号）−（送信元ポート番号）＜２５５である場合(dst port differ less than plus 255)、宛先ポート番号圧縮情報に５を格納し、宛先ポート番号のフィールドを１バイトに圧縮する。０＞（宛先ポート番号）−（送信元ポート番号）＞−２５５である場合(dst port differ less than mius 255)、宛先ポート番号圧縮情報に６を格納し、宛先ポート番号のフィールドを１バイトに圧縮する。宛先ポート番号のフィールドを圧縮しない場合、宛先ポート番号圧縮情報に０を格納し、宛先ポート番号のフィールドを２バイトのままとする。

図１４に示すような圧縮されたＩＰｖ６ヘッダを含むＩＰｖ６パケットを受信した通信装置は、図１０〜１２に示すような圧縮情報ヘッダに基づいて伸長処理を実施し、図１３に示すようなＩＰｖ６ヘッダ、ＩＰｖ６フラグメントヘッダ、ＵＤＰヘッダを得る。

Claims

複数の通信装置から構成され、１つ以上の通信装置を経由して通信を行う無線システムに用いられる通信装置であって、
前記複数の通信装置間での近隣探索メッセージとその応答、またはアドホックルーティングプロトコルによる経路制御情報の交換に基づいて通信制御情報の圧縮可否を判断する第一手段と、
前記通信制御情報の圧縮が可能な場合、前記通信制御情報の内容を判断し、冗長な情報または常時固定な情報を削減または置換することで、前記通信制御情報の情報量を圧縮する第二手段と、
を備える通信装置。
請求項１において、
前記第一手段は、
受信したＩＰｖ６パケットの上位プロトコルが、自通信装置を送信元とするＩＣＭＰｖ６による近隣ノード探索のメッセージまたはアドホックルーティングのメッセージである場合、前記メッセージ内のペイロード情報に自通信装置が圧縮可能な旨の圧縮可能情報を格納する手段と、
前記メッセージ内に他通信装置の圧縮可能情報が格納されている場合、前記他通信装置を圧縮可能通信装置としてそのアドレスをデータベースに登録する手段と、
前記データベースを検索し宛先ＩＰｖ６アドレスまたは宛先ＭＡＣアドレスが圧縮可能通信装置である場合、前記通信制御情報を圧縮可能と判断する手段と、
を備える通信装置。
請求項２において、
前記第二手段は、所定の圧縮アルゴリズムに基づいて前記通信制御情報の所定のフィールドの情報を削減または置換して圧縮し、圧縮した前記所定のフィールドの情報の前に圧縮の状態を示す圧縮情報ヘッダを付加して圧縮された通信制御情報を得る通信装置。
請求項３において、
さらに、受信したＩＰｖ６パケットの先頭が前記圧縮情報ヘッダである場合、前記圧縮された通信制御情報を伸長する第三手段を備える通信装置。
請求項３において、
前記第三手段は、前記圧縮情報ヘッダに基づいて前記圧縮された通信制御情報を前記通信制御情報に復元する通信装置。