(57)【要約】  ステート情報を維持すること及び／又は中間ノードなしで必要に応じて元々のＩＰｖ６ヘッダーが再構成され得るように、より下位層のネットワーク層に含まれる情報を用いることによってＩＰｖ６ヘッダーを４０オクテットから４オクテットの最小値ほどまでステートレスに圧縮する方法が提供される。典型的な４０オクテットのＩＰｖ６ヘッダーを、ローカル・エリア・ネットワークでの伝送のために最小の４オクテットまで圧縮することにより、ラインから電力供給されないローカル装置の電池寿命が延長され得る。パケットがローカル・エリア・ネットワーク外に送信されるとき、完全なＩＰｖ６ヘッダーが伝送に先立って再構築され得る。
2008518511.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク通信フォーマットを用いて構成された、ヘッダーと情報ペイロードとを含むパケットについて、その長さをステートレスに縮小する方法であって：
ローカルルータと交信する少なくとも１つの装置を含むローカル・エリア・ネットワーク（ＬＡＮ）の該ローカルルータにて、広域ネットワーク（ＷＡＮ）からのパケットを受け取る段階；
ローカルルータから前記少なくとも１つの装置へのパケットの伝送に先立って、情報ペイロードの前記ヘッダーを圧縮する段階；及び
圧縮されたヘッダーを含むパケットを前記少なくとも１つの装置に伝送する段階；
を有する方法。
【請求項２】
前記ヘッダーを圧縮する段階が：
前記ヘッダーからバージョン番号を除去すること；
前記ヘッダーからトラフィッククラスを除去すること；
前記ヘッダーからフローラベルを除去すること；及び
前記ヘッダーから宛先アドレスを除去すること；
を含む、請求項１に記載の方法。
【請求項３】
パケットの前記ヘッダーは４０オクテットの長さを有し、圧縮されたヘッダーは２０オクテットの長さを有する、請求項２に記載の方法。
【請求項４】
装置の１つにてローカルルータからのパケットを受け取る段階；及び
バージョン番号、トラフィッククラス及びフローラベルを挿入すること、及びパケットのＭＡＣヘッダー又はネットワークヘッダーから宛先アドレスを取り出すことによって、パケットの前記ヘッダーをステートレスに解凍する段階；
を更に有する請求項２に記載の方法。
【請求項５】
前記少なくとも１つの装置はＲＦ送信機を含み、応答パケットは装置からローカルルータにＲＦ送信機を用いて伝送される、請求項１に記載の方法。
【請求項６】
ローカルルータにて、前記少なくとも１つの装置から、圧縮されたヘッダーと情報ペイロードとを有するローカルパケットを受け取る段階；
ローカルパケットのＷＡＮ上での伝送に先立って、圧縮されたヘッダーをローカルルータにて解凍する段階；及び
解凍されたヘッダーを含むローカルパケットをＷＡＮ上で伝送する段階；
を更に有する請求項１に記載の方法。
【請求項７】
ローカルルータにて前記少なくとも１つの装置から、圧縮されたヘッダーと情報ペイロードとを有するパケットを受け取る段階；
該パケットのＷＡＮ上での伝送に先立って、圧縮されたヘッダーをローカルルータにてステートレスに解凍する段階；及び
解凍されたヘッダーを含むパケットをＷＡＮ上で伝送する段階；
を更に有する請求項４に記載の方法。
【請求項８】
圧縮されたヘッダーをローカルルータにて解凍する段階が：
パケットのＭＡＣヘッダー又はネットワークヘッダーから送信元アドレスを回収する段階；及び
ヘッダーを再構成するために、圧縮されたヘッダーにバージョン番号、トラフィッククラス、フローラベル、及び送信元アドレスを再挿入する段階；
を含む、請求項６に記載の方法。
【請求項９】
ＩＰｖ６フォーマットを用いて伝達される、ＩＰｖ６ヘッダーと情報ペイロードとを含むパケットについて、その長さをステートレスに縮小する方法であって：
ローカルルータと交信する複数の装置を含むローカル・エリア・ネットワーク（ＬＡＮ）又はパーソナル・エリア・ネットワーク（ＰＡＮ）の該ローカルルータにて、広域ネットワーク（ＷＡＮ）からのパケットを受け取る段階；
ローカルルータから前記複数の装置の何れか１つへのパケットの伝送に先立って、情報ペイロードのＩＰｖ６ヘッダーを圧縮する段階；
圧縮されたヘッダーを含むパケットを前記複数の装置の少なくとも１つに伝送する段階；
ローカルルータにて前記複数の装置の何れか１つから、圧縮されたヘッダーと情報ペイロードとを有する応答パケットを受け取る段階；
応答パケットのＷＡＮ上での伝送に先立って、圧縮されたヘッダーをローカルルータにてステートレスに解凍する段階；及び
解凍されたヘッダーを含む応答パケットをＷＡＮ上で伝送する段階；
を有する方法。
【請求項１０】
ＩＰｖ６ヘッダーを圧縮する段階が：
ＩＰｖ６ヘッダーからバージョン番号を除去すること；
ＩＰｖ６ヘッダーからトラフィッククラスを除去すること；
ＩＰｖ６ヘッダーからフローラベルを除去すること；及び
ＩＰｖ６ヘッダーから宛先アドレスを除去すること；
を含む、請求項９に記載の方法。
【請求項１１】
パケットのＩＰｖ６ヘッダーは４０オクテットの長さを有し、圧縮されたヘッダーは１６オクテットの長さを有する、請求項１０に記載の方法。
【請求項１２】
前記複数の装置の１つにてローカルルータからのパケットを受け取る段階；及び
パケットのＭＡＣヘッダー又はネットワークヘッダーから宛先アドレスを取り出す段階；
を更に有する請求項９に記載の方法。
【請求項１３】
前記複数の装置の各々はＲＦ送信機を含み、応答パケットは装置からローカルルータにＲＦ送信機を用いて伝送される、請求項９に記載の方法。
【請求項１４】
圧縮されたヘッダーをローカルルータにてステートレスに解凍する段階が：
パケットのＭＡＣヘッダー又はネットワークヘッダーから宛先アドレスを回収する段階；及び
ＩＰｖ６ヘッダーを再構成するために、圧縮されたヘッダーにバージョン番号、トラフィッククラス、フローラベル、及び宛先アドレスを再挿入する段階；
を含む、請求項１０に記載の方法。
【請求項１５】
ルータ及び該ルータと交信する複数の装置を有するローカル・エリア・ネットワークにおいて、バージョン番号、トラフィッククラス、フローラベル、ペイロード長、次ヘッダー、ホップ限界、送信元アドレス、及び宛先アドレスを有するＩＰｖ６ヘッダーと情報ペイロードとを有するパケットを圧縮する方法であって：
ローカルルータにてパケットを受け取る段階；
圧縮されたヘッダーを作り出すために、ローカルルータにて、ＩＰｖ６ヘッダーからバージョン番号、トラフィッククラス、フローラベル、送信元アドレス、及び宛先アドレスを除去する段階；
圧縮されたヘッダーを含むパケットを前記複数の装置の少なくとも１つに伝送する段階；及び
装置にて、ＭＡＣヘッダー又はネットワークヘッダーから送信元アドレス及び宛先アドレスを決定する段階；
を有する方法。
【請求項１６】
サーバと複数の装置との間の通信に関して、バージョン番号、トラフィッククラス及びフローラベルは一定である、請求項１５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、標準ネットワークプロトコルを用いて伝達されるネットワークパケットの長さをステートレス（stateless）に縮小する方法に関し、より具体的には、接続状態を維持する必要がなく、ローカル・エリア・ネットワーク（ＬＡＮ）内の無線通信装置の電池寿命を延長し且つ帯域効率を向上させることができる、ＩＰｖ６フォーマットのヘッダー圧縮方法に関する。
【背景技術】
【０００２】
現在、インターネットプロトコル・バージョン４（ＩＰｖ４）がインターネット上で情報を伝送するために使用される最も知られた標準的なプロトコルとなっている。過去の数年にわたって、インターネット上で情報をアドレス指定して伝送する、ＩＰｖ６と呼ばれる新たな規格が策定されてきた。ＩＰｖ６規格は未だ広くは採用されていないものの、現在でも数多くのアプリケーションで使用されている。また、最近になり米国国防総省によって使用が命じられたり、アジア太平洋諸国全体で先導的な新プロトコルとなってきたりしている。ＩＰｖ６は非常に近い将来、インターネット通信の標準になると予想される。
【０００３】
以前から使用されるＩＰｖ４プロトコルにおいては、メッセージヘッダーの宛先及び送信元のアドレス欄（フィールド）には各々３２ビットのアドレスが割り当てられていた。３２ビットのアドレス空間は導入当初は豊富なものであったが、それらは非効率的に割り当てられているため、インターネットアドレスの数は枯渇し始めている。ＩＰｖ６規格はパケットヘッダーに１２８ビットの送信元及び宛先アドレス空間を提供するように開発されている。３２ビットから１２８ビットへのアドレス長の拡張は、この新プロトコルは約3×1038個のアドレス、すなわち8×1028倍多いアドレスに対応できるようになることを意味している。ＩＰｖ４及びＩＰｖ６のヘッダーを圧縮するための公表された方法はあるにはあるが、それらの全てが、接続及び変更されるパケットについてのナレッジ及びステート情報を維持するように、ヘッダーを圧縮及び解凍する装置を必要としていた。故に、このようなステート情報を維持することを必要とせずにヘッダー圧縮を実現できる方法を提供することが望まれる。
【０００４】
ＩＰｖ６はＩＰｖ４規格の改善版として理解されるが、ＩＰｖ６規格は各メッセージのヘッダー内で伝送されるデータ量を増大させている。具体的には、各メッセージのヘッダーはＩＰｖ４での１６０ビット（２０バイト／オクテット）からＩＰｖ６メッセージでの３２０ビット（４０バイト／オクテット）の情報に増大している（この出願全体を通して、８ビットのデータを記述するために、あまり正確な用語ではない“バイト”ではなく、用語“オクテット”が使用される）。インターネット上での通信速度はますます高速化しているため、このヘッダー長の増大はごく僅かであると見られがちであるが、この増大されたヘッダー長は、ラインから電力供給されない装置の電池寿命と、パーソナル・エリア・ネットワーク（ＰＡＮ）上でメッセージを送信する装置に関する伝送時間とに有意な効果を有するものである。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明は、メッセージの伝送に必要な時間を縮小し、それによって電池寿命の延長及び伝送時間の短縮を実現するために、ＩＰｖ６ヘッダーを４０オクテットから、より小さいサイズにステートレスに圧縮する方法及び手段を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明は、ＩＰｖ６フォーマットを用いて伝達されるパケットの長さを縮小する方法に係る。ＩＰｖ６プロトコルを用いて伝送されるパケットはＩＰｖ６ヘッダーとデータ・ペイロードとを含んでおり、ＩＰｖ６ヘッダーは４０オクテットの長さを有している。本発明に係る方法は、ＩＰｖ６ヘッダーの全体長を縮小し、故に、パケット全体の長さを縮小するものである。
【０００７】
広域ネットワーク（ＷＡＮ）上を送られるパケットはＩＰｖ６プロトコルを用いて送信・受信され、４０オクテットの長さを有するＩＰｖ６ヘッダーを含んでいる。パケットがローカルルータ、又は広域ネットワークに接続されたブリッジにて受け取られると、ローカルルータ又はブリッジはパケットを翻訳し、ローカル・エリア・ネットワーク（ＬＡＮ）又はパーソナル・エリア・ネットワーク（ＰＡＮ）の部分としてローカルルータ又はブリッジと交信する１つ以上の何らかの装置にパケットを伝達する。ローカル・エリア・ネットワークの多くの意図される構成において、各装置はＲＦ通信を用いてローカルルータと交信している。典型的には、各装置からのＲＦ通信は内蔵型の電池によって駆動されている。故に、各パケットを伝送するのに必要な時間は装置内の電池の寿命に直接的に影響を及ぼす。
【０００８】
ローカルルータから、ＬＡＮ又はＰＡＮを形成する１つ以上の何らかの装置へのパケット伝送に先立って、ローカルルータはＩＰｖ６ヘッダーを圧縮する。具体的には、ローカルルータはＩＰｖ６ヘッダーの様々な部分を除去し、ＩＰｖ６ヘッダーを４０オクテットから４オクテット又は２０オクテットの圧縮されたヘッダー長まで縮小する。
【０００９】
ＬＡＮ外部の送信元からのパケットのＩＰｖ６ヘッダーの圧縮において、ＬＡＮ又はＰＡＮの部分を形成する装置の何れか１つへのパケット伝送に先立って、ローカルルータはバージョン番号、トラフィッククラス部、フローラベル、及び宛先アドレスを除去する。ローカルルータとＬＡＮ又はＰＡＮの装置との間を送られるパケット各々のバージョン番号、トラフィッククラス部及びフローラベルは同一であるので、ＩＰｖ６ヘッダーのこれらの部分は除去されることができる。さらに、ＬＡＮ若しくはＰＡＮのカプセル化ヘッダー（ＭＡＣヘッダー）、又はＬＡＮ若しくはＰＡＮのネットワーク層は宛先アドレスを含んでいるので、ＩＰｖ６ヘッダーのこの部分は情報の如何なる損失もなく除去されることができる。圧縮されたパケットが何れか１つの装置にて、あるいはローカルルータに戻って受け取られると、除去されたアドレスは各メッセージのＭＡＣヘッダー又はネットワークヘッダーから取り出されることができる。故に、ＩＰｖ６ヘッダー及び静的なＩＰｖ６ヘッダー欄からのアドレス部分の除去により、伝送に先立ってヘッダー長がデータの喪失なく縮小される。
【００１０】
ＬＡＮ又はＰＡＮの部分を形成する装置の何れか１つからの圧縮されたパケットがローカルルータで受け取られると、ローカルルータは送信元アドレスをＭＡＣヘッダー又はネットワークヘッダーから取り出すことによってＩＰｖ６ヘッダーを再構成する。さらに、ローカルルータはバージョン番号、トラフィッククラス部及びフローラベルを圧縮されたヘッダーに再挿入することによってＩＰｖ６ヘッダーを再構成する。ＩＰｖ６ヘッダーが再構成されると、ＩＰｖ６ヘッダーは完全なものとなるため、ローカルルータは非圧縮のパケットをＷＡＮ上に送信することができる。
【００１１】
上述のヘッダー圧縮方法を用いることにより、ローカル・エリア・ネットワークの部分を形成する装置の各々はローカルルータと交信できるとともに、電池寿命を延長し且つ帯域幅の消費を削減させるように、ＰＡＮ及びＬＡＮの装置間で更に効率的に通信することができる。送信元アドレス及び宛先アドレスの双方は、ＭＡＣヘッダー又はネットワークヘッダーの一部として含まれているので、ＩＰｖ６ヘッダーは必要に応じてＷＡＮ上へのメッセージ伝送に先立ってローカルルータによって再構成されることができる。
【発明を実施するための最良の形態】
【００１２】
図面は本発明を実施する上で現在考えられるベストモードを例示している。
【００１３】
先ず図１を参照するに、送信元10と複数の装置12a乃至12cとの間の、例えばインターネット14等の広域ネットワーク（ＷＡＮ）を介した一般的な通信方法が例示されている。例示された実施形態において、送信元10はルータ15を介して、ローカル・エリア・ネットワーク（ＬＡＮ）18a又はパーソナル・エリア・ネットワーク（ＰＡＮ）18bの何れかのローカルルータ16と交信している。本発明のこの実施形態においては、ローカルルータ16はビル内に配置されており、装置12a乃至12cの各々はルータ16と交信している。一例として、装置12a乃至12cの各々は、コンピュータ化された温度自動調節器、コンピュータ化された電気機器、空気調整ユニット、煙検出器又は他の同様な如何なる装置ともし得る。図１に例示されるように、装置12a乃至12cの各々は、先ずローカルルータ16に、続いてインターネット14を介して送信元10に通信可能であり、送信元10は装置12a乃至12cの何れか１つを遠隔的に監視、制御又は起動できるようになっている。
【００１４】
一例として、装置12a乃至12cの各々は、ユーザがユーザの家庭内の複数の装置を遠隔的に監視・制御することを可能にする完全なホームネットワークの部分として使用されることができる。一例として、ユーザは家庭内の温度自動調節器を遠隔位置から遠隔的に監視・制御することができる。同様に、ユーザは電気機器、空気調整ユニット又は他の電子装置を遠隔位置からオフ又はオンに切り替えることが可能であってもよい。さらに、危険状態検知器が警告状態を検知した場合、警告状態にある家庭の所有者に警告するために警告状態がインターネット14上に送信されてもよい。
【００１５】
図１に示されたネットワークにおいては、ローカル・エリア・ネットワーク18a又はパーソナル・エリア・ネットワーク18bの部分を形成する装置の各々は自身に固有のＩＰアドレスを有している。典型的には、単一のＬＡＮ又はＰＡＮ内の装置12a乃至12c各々のアドレスは、ＬＡＮ18a又はＰＡＮ18b内の装置12a乃至12c全てに共通のネットワーク・プレフィックスと、一般的に装置のＭＡＣアドレスであるリンクローカルアドレスとを有する。図１にて明確に理解され得るように、ユーザの家庭内の装置12a乃至12cの各々にＩＰアドレスが割り当てられる場合、必要なＩＰアドレス数は膨大となり、ＩＰｖ６ネットワークプロトコルが必要となる。
【００１６】
図１に示された本発明の実施形態においては、装置12a乃至12cの各々は、ローカルルータ16に配線接続されている、あるいは代わりに、装置からそれぞれのルータ16に情報を送信する無線送信装置21を含んでいる、の何れであってもよい。装置12a乃至12cの各々は、ＲＦ信号を用いて情報を伝送する無線通信装置を含むことが考えられるが、如何なる伝送機構が用いられてもよい。装置12a乃至12cの各々がルータ16から遠隔に配置される場合、無線送信装置21は該装置自体に内蔵された電池によって電力供給されてもよい。故に、装置12a乃至12cの各々の電池寿命は関心事であり、電池寿命を最大化することが望まれる。また、ＲＦネットワークは共有媒体であるのでネットワークトラフィックを減少させることも有意に有益である。
【００１７】
図１にて理解され得るように、ブロードキャスト送信元10から遠隔ルータ16にインターネット14を介して情報パケットが伝送されるべきとき、情報はＩＰｖ６通信プロトコルを用いたパケットにて送られる。このＩＰｖ６通信プロトコルを用いたパケットはＩＰｖ４インターネット接続を経由してトンネリングされてもよい。典型的には、各情報パケットはヘッダーと情報ペイロードとの双方を含んでいる。ＩＰｖ６ヘッダーは、送信元１０からルータ16へ、そして最終的には所望の装置12a乃至12cへと通信を導くために必要な情報を提供する。
【００１８】
次に図２を参照するに、ＩＰｖ６ヘッダー20のフォーマットが示されている。ＩＰｖ６ヘッダー20は、図２に示されるように分割された４０オクテットの長さを有している。例示されるように、ヘッダー20の第１の部分はバージョン番号22であり、これは４ビットを有し、インターネットプロトコルのバージョンを規定している。ヘッダー20の次の部分はトラフィッククラス24であり、これも４ビットを有している。トラフィッククラス24に続くのはフローラベル26であり、これは２４ビットの長さを有している。ヘッダーの次の部分はペイロード長28であり、これは１６ビットのセグメントである。ペイロード長28に続くのは８ビットの長さを有する次（next）ヘッダーセグメント30であり、その直後は８ビットを含むホップ制限32である。故に、アドレスセグメントまで先導するヘッダー20の部分は、１６０ビットの情報を有する。
【００１９】
ヘッダーの最初の部分に続いて、ＩＰｖ６ヘッダーフォーマットは１２８ビットの長さを有する送信元アドレス34を含んでいる。同様に、宛先アドレス36も１２８ビットのアドレスである。上述のように、ＩＰｖ６ヘッダーフォーマット20は、ＩＰｖ４フォーマットでは送信元アドレス及び宛先アドレスの双方が３２ビット部分であったのに対し、送信元アドレス34及び宛先アドレス36の双方を１２８ビットアドレスに拡張している。図２にて理解され得るように、ＩＰｖ６フォーマットにおけるヘッダー20全体は４０オクテットの長さであり、インターネット上を伝送される情報ペイロードに先行している。
【００２０】
再び図１を参照するに、パケットがローカルルータ16にて受信されると、ローカルルータ16は情報を所望の装置12a乃至12cへと導く。しかしながら、装置12a乃至12cは全て共有ＬＡＮ18a又はＰＡＮ18bに含まれているので、ＩＰｖ６ヘッダー20内に含まれるアドレス情報の多くはＬＡＮ／ＰＡＮ内の正確な情報伝送を確保するためには不要である。ＩＰｖ６ヘッダーは従来のＩＰｖ４ヘッダー情報より遙かに長いので、情報パケット全体を送信するために無線送信装置によって必要とされる時間を最小化するようにヘッダー情報を圧縮する方法及びシステムを提供することが望まれる。しかしながら、情報がインターネット14上を返送される必要があることもあり得るので、ヘッダー情報は関連アドレス及び送信元情報が喪失される程度までには圧縮され得ないことも理解されるべきである。
【００２１】
パケットがローカルルータ16にて受信されると、ローカルルータ16はヘッダー情報から、このパケットが導かれるべき装置12a乃至12cを決定することができる。しかしながら、ローカルルータ16が装置12a乃至12cの何れかと無線通信によって通信する場合、４０オクテットのヘッダーフォーマットは、無線送信装置がＩＰｖ６ヘッダー20を含むパケットを送信するために動作しなければならない時間を増大させる。各ローカルルータ16が交信するのはＬＡＮ18a又はＰＡＮ18bの部分を形成する装置12a乃至12cであるので、ＩＰｖ６ヘッダー20に含まれる情報の多くは、ＭＡＣヘッダー又はネットワークヘッダーの何れであるかに拘わらず、一定値であるか、パケット内の何処か他の場所に含まれるかの何れかである。
【００２２】
再び図２を参照するに、典型的なＩＰｖ６ヘッダー20においては、バージョン番号欄22はプロトコルバージョンを規定する数字の６に設定される。ローカルルータ16はＩＰｖ６のみを用いて通信しようとするので、バージョン欄22は如何なる情報の損失もなく０ビットに圧縮されることができる。さらに、トラフィッククラス欄24及びフローラベル26は、ローカルサーバ16と個々の装置12a乃至12cとの間の通信に関しては常に０に設定されることになる。従って、トラフィッククラス欄24及びフローラベル26の双方は０に設定されるが故に、０ビットに圧縮されることができる。
【００２３】
ペイロード長28、次ヘッダー欄30及びホップ制限32を含んだ次の３つの欄は原型のまま残されなければならないため圧縮されない。故に、ＩＰｖ６ヘッダー20の最初の６つの欄は、完全な非圧縮のＩＰｖ６ヘッダー20に要求される８オクテットではなく、４オクテットのみを包含するように圧縮されることができる。
【００２４】
図２に例示されるように、送信元アドレス欄34及び宛先アドレス欄36は各々、１２８ビットのデータを含んでいる。図３に示されるように、各アドレス34、36の最初の６４ビットは、ＬＡＮ18a又はＰＡＮ18bの外部に割り当てられる一定のネットワーク・プレフィックス38である。ネットワーク・プレフィックス38はＬＡＮ又はＰＡＮ上の装置12a乃至12cの全てに共通である。故に、ローカルルータ16と個々の装置12a乃至12cとの間の通信に関しては、ネットワーク・プレフィックス値38はＬＡＮ又はＰＡＮ内を伝送される全パケットに対して０ビットに圧縮されることができる。ＷＡＮ14上をＬＡＮ18へ配信される、あるいはＬＡＮ18から配信される全ての伝送に関しては、ネットワーク・プレフィックス38は、ＰＡＮの外側から送られるパケットの送信元アドレス内と、ＰＡＮの外側の宛先に送られるパケットの宛先アドレス内とに存在していなければならない。
【００２５】
図３に例示されるように、各アドレス欄の第２の６４ビットはリンクローカルアドレス40である。リンクローカルアドレス40は、ローカル・エリア・ネットワーク18a又はパーソナル・エリア・ネットワーク18bの部分を形成する個々の装置12a乃至12cへとメッセージを導くアドレスである。リンクローカルアドレス40はＩＰｖ６ヘッダー20内の送信元アドレス34及び宛先アドレス36の双方に含まれるが、この情報はパケットの他の部分にも含まれている。
【００２６】
一例として、図５に示される標準的なイーサネット（登録商標）のペイロードフォーマット41によってパケットが送られるとき、イーサネット（登録商標）の４８ビットの宛先アドレス42及び４８ビットの送信元アドレス44は拡張されるとＩＰｖ６ヘッダー内のリンクローカルアドレスと同じになる。アドレス42、44は、ＩＰｖ６ヘッダー20内の送信元アドレス34又は宛先アドレス36の何れかの部分として含まれるリンク層アドレス40に対応するように拡張されたＩＥＥＥ６４ビットである。宛先アドレス42及び送信元アドレス44の双方がＭＡＣヘッダー又はネットワークヘッダーの部分として含まれているので、ＬＡＮ又はＰＡＮ上の装置間を伝送されるときには、ＩＰｖ６ヘッダー20内の送信元アドレス34及び宛先アドレス36は何れも０ビットに圧縮されることができる。ＬＡＮ又はＰＡＮの外側の宛先にパケットを送るときには宛先のＩＰｖ６アドレスは原型のまま残され、ＬＡＮ又はＰＡＮの外側の送信元からＬＡＮ又はＰＡＮ内にパケットを送るときには送信元アドレスが原型のまま残される。
【００２７】
次に図４を参照するに、802.15.4ネットワークにて使用されるパケットフォーマットが示されている。この形式のネットワークにおいては、リンク層フレームが送信元リンク層アドレス46、及び宛先リンク層アドレス48を含んでいる。好適な実施形態において、リンク層内のアドレスは完全な６４ビットＩＥＥＥ  ＥＩＵアドレスであり、４８ビットから６４ビットへのアドレス拡張を必要としない。故に、ＩＰｖ６ヘッダーにて使用されるリンク層アドレス40は、同様にペイロードフォーマット47のリンク層内で運ばれるため、ローカル・エリア・ネットワーク18内での伝送中には、ＩＰｖ６ヘッダー内で０オクテットに圧縮されることができる。マルチホップ性を利用する802.15.4ネットワークにおいては、宛先リンクアドレスはネットワーク層内で運ばれるため、送信元アドレスと同様に圧縮されることができる。リンク層アドレスは、リンク層又はネットワーク層の情報からステートレスに再構築され得るため、ＩＰｖ６ヘッダーから圧縮されることができる。
【００２８】
図６は、本発明に係る方法を用いて作り出される圧縮されたヘッダー50を示している。例示されるように、圧縮されたヘッダー50は４オクテットのみの長さを有し、２オクテットのペイロード長28、１オクテットの次ヘッダー部30、及びやはり１オクテットのホップ制限32を含んでいる。圧縮されたヘッダー50はローカルルータ16と、ＬＡＮ18a又はＰＡＮ18bの部分を形成する装置12a乃至12cとの間で情報を通信するために使用可能である。標準ＩＰｖ６ヘッダー20内の残りのアドレス情報及び他の欄は、圧縮されたヘッダー50を作り出すようにＩＰｖ６ヘッダーから外に圧縮されることができる。上述のように、宛先アドレス48及び送信元アドレス46は、図４及び５にて説明されたように、リンク層又はネットワークヘッダーから回収されることが可能である。
【００２９】
パケットがローカルネットワーク18a又は18bの外側に送られるとき、他のネットワークへ、あるいは他のローカル装置への何れかに拘わらず、上述の圧縮法を逆にし、且つネットワーク・プレフィックス38及びリンク層アドレス40を送信元アドレス欄34及び宛先アドレス欄36に挿入することにより、完全なＩＰｖ６ヘッダーがステートレスに再構築され得る。ネットワーク・プレフィックス38及びリンク層アドレス40を再挿入することに加え、圧縮処理中に除去されたバージョン番号22、トラフィッククラス24、及びフローラベル26を再挿入することによってＩＰｖ６パケットヘッダー20は再構築され得る。ＩＰｖ６ヘッダー20が再構成されると、パケットは従来通りにＷＡＮ14を横切って伝送されることができる。
【００３０】
一例として、装置12a乃至12cの何れか１つがＷＡＮ14上でブロードキャスト送信元に通信する必要がある場合、装置12a乃至12cは先ずはローカルルータ16にパケットを伝達する。ローカルルータ16が装置12a乃至12cの１つからパケットを受け取る時、このバケットは圧縮されたヘッダーを含んでいる。ローカルルータ16は先ず、バージョンブロック22、トラフィッククラス24、フローラベル26及び送信元アドレス34を再挿入して、このヘッダーをステートレスにＩＰｖ６パケットヘッダーに再構成することにより圧縮されたヘッダーを解凍する。上述のように、送信元アドレス34は装置12a乃至12cから受け取られたパケットのＭＡＣヘッダー又はネットワークヘッダーから回収されることが可能である。
【００３１】
パケットのヘッダーが完全にＩＰｖ６ヘッダー20となるように再構成されると、パケットはローカルサーバ16によってＷＡＮ14上に送信されることが可能である。
【００３２】
次に図７を参照するに、非圧縮のＩＰｖ６ヘッダー20と情報ペイロード54とを有する元々のパケット52が示されている。元々のパケット52は４０オクテットのヘッダー20及び従来のペイロード54を含んでいる。一例として、ペイロード54は３０オクテットのペイロードを含んでおり、その結果、全体のパケット52は７０オクテットである。このパケット52が伝送されるとき、伝送時間の57.14％（７０オクテットの内の４０オクテット）が非圧縮のヘッダー20を伝送するために使用される。３０オクテットのペイロードはＰＡＮのデータとして典型的なサイズである。
【００３３】
圧縮後、矢印56によって例示されるように、圧縮されたパケット58は圧縮されたヘッダー50及び同一のペイロード54を有する。上述のように、非圧縮のヘッダー20は４０オクテットの長さを有するのに対し、圧縮されたヘッダー50は４オクテットの全長を有する。ペイロード54は一定の３０オクテット長のままであるので、圧縮されたパケット58は３４オクテットの全長を有する。この圧縮されたパケット58が伝送されるとき、ヘッダー20が圧縮されないときには57.14％必要であったのに対し、伝送時間の約11.76％（３４オクテットの内の４オクテット）のみが圧縮されたヘッダー50の伝送のために必要とされる。
【００３４】
以上の記載により理解され得るように、蓄電池によって電力供給されるＲＦ伝送によってパケット伝送が行われるとき、ヘッダーの伝送に必要な時間を縮小することは、非圧縮のヘッダーと比較して優位な改善となる。電池寿命を節約することに加え、ＩＰｖ６ヘッダーの圧縮は伝送に必要な帯域幅を狭くし、スループットを有意に増大させる。
【００３５】
以上の記載が指し示すように、典型的に４０オクテットであるＩＰｖ６ヘッダーは、イントラＬＡＮ又はイントラＰＡＮ（ＬＡＮ又はＰＡＮの内部）で通信するとき４オクテットまで圧縮されることができる。パケットの送信元又は宛先がＰＡＮ又はＬＡＮの外側にあるとき、ＩＰｖ６ヘッダー内のそれぞれのアドレスは圧縮されず、得られるパケットサイズは２０オクテットとなる。ヘッダー20のこれらの削減により、ローカル装置12a乃至12cの各々はローカル・エリア・ネットワーク18a若しくはパーソナル・エリア・ネットワーク18bの内部での通信、及びＬＡＮ若しくはＰＡＮの外部との通信の何れに対する伝送時間をも削減することができる。アドレス情報はリンク層の各メッセージ内で運ばれるので、ＷＡＮ14上での情報の伝送に先立って、送信元欄及び宛先欄はステートレスに再構築されることができる。ＩＰｖ６ヘッダーサイズの縮小は遠隔装置12a乃至12cの電池寿命、並びにチャンネルの競合及び干渉に有意な効果をもたらす。
【００３６】
様々な代替例及び実施例は、本発明とされる対象を具体的に指摘し、はっきりと主張する添付の請求項の範囲に含まれるものである。
【図面の簡単な説明】
【００３７】
【図１】広域ネットワーク（ＷＡＮ）上で行われる通信と、有線及び無線の双方のローカル・エリア・ネットワーク（ＬＡＮ）又はパーソナル・エリア・ネットワーク（ＰＡＮ）上での通信を例示する概略図である。
【図２】ＩＰｖ６フォーマットにおけるヘッダー構成を例示する図である。
【図３】ＩＰｖ６ヘッダーフォーマットの送信元及び宛先アドレス欄を示す図である。
【図４】ＩＥＥＥ802.15.4ネットワークにて使用されるフレームフォーマットを例示する図である。
【図５】イーサネット（登録商標）フォーマットにて使用されるフレームフォーマットを例示する図である。
【図６】本発明に係る方法を用いて圧縮されたＩＰｖ６ヘッダーを例示する図である。
【図７】ＩＰｖ６ヘッダーの圧縮後におけるパケット長の縮小を例示する図である。
【図１】
2008518511.tif 000003
【図２】
2008518511.tif 000004
【図３】
2008518511.tif 000005
【図４】
2008518511.tif 000006
【図５】
2008518511.tif 000007
【図６】
2008518511.tif 000008
【図７】
2008518511.tif 000009
【国際調査報告】
2008518511.tif 000010
2008518511.tif 000011