JP2004511136A

JP2004511136A - 通信ネットワークのためのインターネット・プロトコル・ヘッダ

Info

Publication number: JP2004511136A
Application number: JP2002531715A
Authority: JP
Inventors: ホビス，ケヴァン; フリン，ポール・ヴィンセント; リンチューソ，ジョセフ; デクラーク，ダニエル・ジェイ
Original assignee: Motorola Inc
Current assignee: Motorola Solutions Inc
Priority date: 2000-09-27
Filing date: 2001-09-24
Publication date: 2004-04-08
Also published as: CN1554174A; AU2001289918A1; WO2002028056A3; WO2002028056A2; EP1371204A2

Abstract

本発明は、「ルックアップ・テーブル」を用いて、ＩＰパケットを移動通信装置１との間で移送する際にエア・インタフェース（及び場合によっては地上のバックホール）を介したＩＰヘッダを移送する必要を除去する。これにより、ＩＰパケットの移送に関するスペクトル効率問題の一部が解決される。

Description

【０００１】
［発明の背景］
本発明は、通信ネットワークにおけるインターネット・プロトコル（ＩＰ）の伝送に関するものであり、特に第三世代通信ネットワークいわゆるＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ　Ｍｏｂｉｌｅ　Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ　Ｓｙｓｔｅｍ）に適用されるものである。
【０００２】
今日、通信システムは、無線有線ともに、通信ユニット間におけるデータ転送の要求を持っている。本文脈において、データには音声通信も含むものとする。限られた通信資源の利用を最適化するため、そのようなデータ転送は有効かつ効率的に提供される必要がある。
【０００３】
通信ネットワーク間でデータを転送するためには、通信ユニット・アドレッシング・プロトコルが必要である。データをアドレスされたユニットに転送する方法を決定するため、通信ユニットには、一般に、通信ブリッジ、ゲートウェイ及び／又はルータにより読み取られるアドレスが割り当てられる。ネットワーク間の相互接続は、一般にインターネットワーキング（或いはインターネット）として知られている。
【０００４】
ネットワークはしばしばサブ・ネットワークに分割され、情報の順序だった交換を可能とする一組の規則を定義するためにプロトコルが設定される。現在、通信システムにおいてデータを転送するのに用いられる二つの最も普及しているプロトコルは、トランスファ・コントロール・プロトコル（ＴＣＰ）とインターネット・プロトコル（ＩＰ）である。最も単純なものを除く全ての通信システムにおいて、この二つのプロトコルはしばしば、相補的な一対として働く。ＩＰ部分は周知のＯＳＩモデルのネットワーク層におけるデータ転送に対応し、ＴＣＰ部分はＯＳＩモデルのトランスポート層におけるデータ転送に対応する。それらの働きは物理層およびデータ・リンク層に対してトランスペアレントであるため、イーサネット、ＦＤＤＩ或いはトークン・リングといった任意の標準的なケーブル配線ネットワーク上で利用されることが可能である。
【０００５】
インターネット・プロトコルはトランスポート層から渡された情報にデータ・ヘッダを付加する。結果として生ずるデータ・パケットは、インターネット・データグラムとして知られる。データグラムのヘッダは、宛先及び送信元のＩＰアドレス、ＩＰプロトコルのバージョン番号などといった情報を含む。ＩＰアドレスは、インターネット上の個々のノードに割り当てられ、そしてネットワーク及び任意のサブ・ネットワークの位置を識別するために用いられる。
【０００６】
現在、第三世代システムには、「全ＩＰ（Ａｌｌ−ＩＰ）」解決策を目指す強いトレンドがある。多くの場合、これはエンド・ツー・エンドとして、すなわち通信ユニットからネットワーク・サーバまでとみなされる。ネットワーク接続のためのＩＰの利用、すなわち無線基地局（ＢＴＳ）（或いはノードＢ）と基地局制御装置（ＢＳＣ）（或いは無線ネットワーク制御装置）（ＲＮＣ）との間におけるＩＰの利用も検討された。
【０００７】
ＩＰヘッダの無線での、及び内部無線ネットワーク・インタフェース上での移送に関連したスペクトル効率問題がある。ＩＰバージョン４のヘッダは最小で２０バイト長であり、ＩＰバージョン６のヘッダは最小で４０バイト長である。音声のような短いパケットを伝送する際、これが非常に非効率的であることが明らかにわかる。
【０００８】
ＩＰの利用を可能とするが、ヘッダ情報をどうにかして圧縮するか、或いはヘッダ情報を伝送する必要性を除去する解決策が求められている。
【０００９】
［発明の概要］
本発明の第一の態様によれば、通信ネットワークにおけるパケット・データの送受信方法であって、
通信ユニット及びネットワーク制御局においてインターネット・プロトコル（ＩＰ）・ヘッダの内容及び対応するルックアップ・テーブル識別情報を受信するステップと、
受信したＩＰヘッダの内容及びそれらに対応する識別情報を、通信ユニット及びネットワーク制御局に配置されたルックアップ・テーブルに格納するステップと、
ルックアップ・テーブル識別情報を含むデータ・パケットを通信ユニットとネットワーク制御局間で交換するステップと
を含む送受信方法が提供される。
【００１０】
本発明の第二の態様によれば、パケット・データを送受信する装置であって、
インターネット・プロトコル（ＩＰ）・ヘッダの内容及び対応するルックアップ・テーブル識別情報を受信する手段と、
受信したＩＰヘッダの内容及び対応する識別情報を格納するルックアップ・テーブルと、
データ・パケットにルックアップ・テーブル識別情報を添付して、前記データ・パケットをエア・インタフェース（ａｉｒ　ｉｎｔｅｒｆａｃｅ）を介して送信する手段と
を備えた装置が提供される。
【００１１】
このため、本発明は、無線（エア）（ａｉｒ）を介して（及び潜在的には、ある場合にはＢＴＳからＢＳＣ／ＲＮＣへのインタフェースを介して）ＩＰヘッダ全体を転送する必要を除去するために、通信ユニットおよびネットワーク・インフラストラクチャにおける動的なルックアップ・テーブルの利用を提案する。
【００１２】
好ましい実施の形態においては、以下に説明されるプロトコルおよび方法は、現存のＵＭＴＳ仕様書に含まれる現行のＰＤＣＰプロトコルの代わりに用いられてもよい。本発明はＩＰバージョン４又はＩＰバージョン６に適用することができ、また単信方式のリンクにも適する。
【００１３】
本発明は、ＩＰヘッダの内容の大半が、１つのパケットと次のパケットとでは変わらないという法則を利用する。例えば、送信元アドレスは（２つ以上の送信元アドレスを持つことは有り得るとはいえ）、送信の際、同じである頻度が最も高いが、このことは受信の際にも当てはまる（例えば、電子メール・サーバからのファイル転送或いはダウンロード）。宛先アドレスについても同じような議論ができる。ＩＰヘッダ情報の多くは、ポイント・ツー・ポイントのリンクでは必要とされないか、接続の性質に起因して、まったく同じなのである。
【００１４】
本発明が提案する解決策には、ＩＰヘッダ・ルックアップ・テーブルを設定するための、通信ユニットからネットワーク・インフラストラクチャへの（及びその逆の）交換が含まれる。テーブルの大きさは、通信ユニットが使用する可能性のあるサービスのレベル及び種類に従って変わってもよい。
【００１５】
交換はエア・インタフェース上の両方向で起こる。転送される内容は、ルックアップＩＤ（ＬＵＩＤ）及びＩＰヘッダ内容全体から構成されるテーブルである。ヘッダ内容はルックアップ・テーブルに格納され、ＬＵＩＤに対して相互参照される。それ故、通信ユニット及びネットワーク・インフラストラクチャは、ＩＰヘッダ全体ではなくこのＬＵＩＤだけを用いて、エア・インタフェースを介してパケットを伝送する。動的でありそして無線で時折伝送されることが必要であり得るヘッダからの別データがあり得る。
【００１６】
ルックアップ・テーブルはＢＴＳに又はＢＳＣ／ＲＮＣに配置されてもよい。テーブルがＢＳＣ／ＲＮＣに格納された場合、ＢＴＳからＢＳＣ／ＲＮＣへのバックホール（ｂａｃｋｈａｕｌ）・リンクについても、帯域幅効率が節約される。しかしこれは、ＢＴＳとＲＮＣとの間の経路を定められたＩＰネットワークの利用を妨げる（しかし、これを可能にするようＩＰネットワークはまだＩＰトネリング技術を利用する）ので、テーブルはＢＴＳに格納されることが好ましい。以下に説明される技術は、いずれの場合においても働く。
発明の実施の形態は、以下の図面に関連して、例としてのみ説明される。
【００１７】
［好ましい実施の形態の詳細な説明］
図１において、本例では移動局（例えば、携帯電話機（ｃｅｌｌ　ｐｈｏｎｅ））である通信ユニットは、エア・インタフェース３を介して無線基地局（基地局送受信機）ＢＴＳ２と通信している。ＢＴＳ２は無線ネットワーク制御装置４にリンクされており、それによりインターネット・プロトコル・コア・ネットワーク５と移動局１との通信が確立され得る。コア・ネットワーク５は更に、適切なシグナリング・ゲートウェイを経由して、インターネット・パケット・データ網、インターネット・サービス・プロバイダ又は電話網のような他のネットワーク及びネットワーク構成要素（図示せず）に対する接続を有する。移動局１とＢＴＳ２はともに、ルックアップ・テーブル６を備えている。
【００１８】
ルックアップ・テーブル６は、特定の移動局１がネットワーク５、４、２内に存在する状況の続く期間、ＢＴＳ２および移動局１において保持される。テーブルの初期化は、以下のような様々な方法でなされ得る。
【００１９】
第一の例では、ルックアップ・テーブル６は空であるため、以下に記載される保持技術がテーブル６を満たすために用いられる。
第二の例では、購読データベースからのダウンロードにより、デフォルト項目が設定される。これは例えば、電子メール・サーバの詳細に対して用いられ得る。
【００２０】
第三の例では、移動局１及び／又はＢＴＳ２が、データと、呼びにおいて接触されるべき宛先とについてのなんらかの事前の知識に基づいて、初期化の際にある一定数のヘッダを送信する。これは、単一のメッセージにおいて複数のヘッダが初期化されるという違いはあるが、以下に記述される保持技術と同様である。
【００２１】
特定のテーブル項目（例えば、デフォルト項目）は、固定のものとしてマークされているため、以下に記述される保持技術により上書きされることはない。
一度初期化が起こると、移動局１はＩＰパケットの送受信を始めることができる。パケットが移動局１又はＢＴＳ２によりエア・インタフェース３を介して送信される際、標準構成のうちのひとつが参照されるかどうかを決定するために、ルックアップ・テーブル６が調べられる。参照される場合、パケットは、ＩＰヘッダが取り除かれ、２０バイトよりはるかに小さくて（おそらく１バイトまたはそれ以下で）よいＬＵＩＤにより置き換えられて送信される。保持技術は以下の通りである。
【００２２】
ルックアップ・テーブル内に項目が見当たらない場合、以下のような多数の選択肢がある。
１）ヘッダ全体と共にパケットを送信する。
２）項目を作成し、エア・インタフェース３を介して通信する（ヘッダに、割り当てられたＬＵＩＤを加えたものになる）。その上で、この新しく割り当てられたＬＵＩＤをその後の転送に利用する。
３）新しい項目の作成については、既存の項目を新しいもので置き換え、これをエア・インタフェース３を介して通信する。置き換えられるべき項目の選択基準は特定されていないが、例えば、最も使われない項目や最も古い項目を選択するなど、いくつかの技術を利用することができる。
【００２３】
ある場合には、変更されたフィールドがわずかに異なったり一時的に異なったりはするがルックアップ・テーブルを更新しないで、該変更されたフィールドが送信される。
【００２４】
好ましくは、新しいテーブル項目の転送は、損失から保護されている必要がある。例えば、「項目の置き換え」作業がその宛先への到達に失敗すると、移動局またはＢＴＳの受信機は当該ＬＵＩＤを利用して、その後のパケットの経路を誤って決定してしまう。従って、その操作については、受信確認がなされることが望ましい。
【００２５】
ＩＰバージョン４ヘッダのヘッダ・フィールド、及びＬＵＩＤとの関係は、図２に関連して以下に記述される。
ＶＥＲＳ：　本項目は、ＩＰプロトコルのバージョン４又はバージョン６などを定義する。全ての転送に特定のバージョンを使うというネゴシエーションにより、又は、単に、適宜のルックアップ・テーブル項目にバージョンを入れることにより、エア・インタフェース上では本項目は除去されてもよい。ＶＥＲＳは所与のルックアップ・テーブル項目に対しては転送される必要がない（すなわちデフォルト値を使用することができる）。
【００２６】
ＨＬＥＮ：　本項目はヘッダ長である。何のオプションも使われていない場合、本項目は特定の項目に対しては、ルックアップ・テーブル内で固定の項目になり得るため、ルックアップ・テーブル転送において交換される必要がない（すなわちデフォルト値を使用することができる）。ＩＰバージョン６では、基本ＩＰヘッダの長さが常に変わらないため、本フィールドは不要である。
【００２７】
サービス種別：　本項目はサービス品質を示し、いくつかのサブ・フィールドを持つ。本項目はルックアップ・テーブル項目により除去され得る。本項目は、例えばボイス・オーバー・ＩＰ（ＶｏＩＰ）チャネル及びウェブ・ブラウザ・チャネルが同じアドレスに対して開かれている場合に、所与の宛先アドレスに対して２以上のルックアップ・テーブル項目を生成することができる。また、移動局により要求されたサービスに基づいて、ネットワーク内でマッピングがなされ得る。ＩＰバージョン６においては、フロー・ラベルが、同様の目的を果たすことができ、同様の方法でルックアップ・テーブルとともに圧縮されることができる。
【００２８】
パケット全長：　本項目はＩＰパケットの全長（ヘッダとデータ部を合わせたもの）を識別する。それは、エア・インタフェースを介して転送される必要も、ルックアップ・テーブルに格納される必要もない。実際には、ＲＬＣレイヤが区分化および再組立てを行い、移送される情報のパケットの全長を転送することになっているため、本項目はエア・インタフェースを介して転送される。従ってＩＰレイヤのパケット全長は再構成され得る。
【００２９】
ＩＤ、フラグ、フラグメント・オフセット：　これらのフィールドはＩＰレベルの断片化のために利用される。一般には、ＩＰレベルにおいては断片化は利用されないため、それを許可しないように制限する操作は、問題にならない。従って本フィールドは常に利用されず、無線を介して（ルックアップ・テーブル設定メッセージの転送においてさえも）転送されない。
【００３０】
ＴＴＬ：　本項目は本パケットが廃棄され得るまでの最大ホップ数を効果的に定義する。デフォルト値を利用するか、及び／又は、それは、ルックアップ・テーブル項目設定において設定されてもよい。アップリンク（移動局からＢＴＳへ）においては、おそらく移動局が最終ホップであるため、デフォルト値がかなり頻繁に役立ち得る。ダウンリンク（ＢＴＳから移動局へ）においては、おそらく小さな範囲の値が、役に立ち、そして新しい値が現れるにつれて保持モードにおいて増加され得る。
【００３１】
プロトコル：　本項目は本ＩＰパケットが運んでいるプロトコルの種類、例えばＩＣＭＰ、ＩＧＭＰ、ＧＧＰ、ＩＰ、ＴＣＰ、ＵＤＰなどを示す。本項目は特定の宛先アドレスのために変化し得るが、送信元と宛先のアドレスの各組み合わせにはセットされた数のオプションがあり、それらオプションをカバーするためにある一定数のルックアップ・テーブル項目が構成され得る。ＩＰバージョン６においては、ネクスト・ヘッダ・フィールドが同様の目的を果たし、同様の方法で圧縮され得る。
【００３２】
ヘッダ・チェックサム：　エア・インタフェースを介して転送されるデータはそれ自体がチェックを持っているため、本項目はネットワーク内または移動局内においてヘッダ内容に基づいて再生成されることができる（本項目は事実上使用されていない）。例えば、チェックサムは、ダウンリンク方向においては、ネットワーク構成要素により事実上終了される。本フィールドはＩＰバージョン６では除去されている。
【００３３】
送信元ＩＰアドレス：　本項目はルックアップ・テーブル項目の中で設定される。
宛先ＩＰアドレス：　本項目はルックアップ・テーブル項目の中で設定される。
【００３４】
オプション：　オプション・フィールドは、任意の１つのパケットにおいて、使用される長さや数が変わり得る。ある一定のアプリケーションに特定のオプション・フィールドもある。これらのフィールドは可能であれば回避され得るが、必要な場合にはエア・インタフェースを介するデータ転送を潜在的に要求する。
【００３５】
上位レイヤのプロトコルに関しては、移動局はＩＰと関連した上位レイヤ・プロトコル、例えばＴＣＰ、ＵＤＰ、ＲＴＰ及びその他を利用する。ヘッダ内のプロトコル・フィールドはこのことを示し、ルックアップ・テーブルを適切に設定するために利用される。これらのプロトコル・ヘッダの多くにおいて、例えばシーケンス番号のように、パケットごとに変化するフィールドがある。
【００３６】
これらのプロトコルは、ネットワーク内のルックアップ・テーブルの場所において終了される可能性がある。そこで、ＢＴＳはあたかも移動局のＩＰアドレスを持っているかのように振舞い（プロキシとして振舞い）、ＩＰおよびその他のプロトコルを生成し終了させる。これにより、無線で伝送される必要のあるデータが最小化される。従って、無線を介するプロトコルは、多くのレイヤのヘッダによって妨害されることなく、ユーザのデータを移送するために使用される。
【００３７】
ＨＴＴＰヘッダが利用される場合には、本発明のルックアップ・テーブル解決策は、（ＨＴＴＰのような）上位レイヤの圧縮（例えば、ＬＺＨ）と結びついて、ＩＰやＴＣＰのような安定した下位レイヤに利用されることが好ましい。
【００３８】
ヘッダの設定を構成するエア・インタフェース・パケットは図３ａおよび図３ｂに図示されたように構成される。
ＬＵＩＤ項目メッセージ（図３ａ）は、ＬＵＩＤ項目を設定するのに利用されるエア・インタフェース・パケットの一般的な構造を示している。これはいずれの方向にも利用され得るものであり、対応する受信確認メッセージを有する。パケットは非常に単純であり、種別（本パケットをデータ・メッセージおよび受信確認パケットから識別するために利用される）と、ＬＵＩＤ（本パケットが関連しているはずの項目番号）と、格納されるべきＩＰヘッダ情報とから構成される。図示されていないが、ＩＰヘッダのある一定の部分は可変なものとして示され得ること、及びそれらは従って必要に応じてデータ・メッセージ内で伝送されることに注意すべきである。ＩＰバージョン６は基本ヘッダと拡張ヘッダとで構成されているため、この手法に対し非常に従順である。基本ＩＰバージョン６ヘッダは、特に可変ではない拡張ヘッダと同様、ルックアップ・テーブルの手法を用いて圧縮され得る。例えば、送信元がネットワークを介して経路を特定できるようにする経路決定拡張ヘッダは、かなり大きくなることがあり、しばしばセッションを通じて同じであり続ける。ルックアップ・テーブル項目はそのような拡張を圧縮する良い方法である。他方、認証拡張ヘッダは、個々のデータグラムと共に予測できない方法で変化し、データ・メッセージ内で移送されることが最良である。
【００３９】
図３ｂのデータ・メッセージは、（そのメッセージをデータ転送として識別する）種別フィールドと、適切なヘッダを生成するために利用されるべきテーブル項目を識別するＬＵＩＤとによって構成される。これにはＵＤＰ、ＲＴＰなどのような上位レイヤのプロトコルへの参照が含まれ得る。そのため、これらのヘッダをデータの一部として転送する必要がなく、ＢＴＳ内の「プロキシ」エンティティがシーケンス番号等と共にパケット全体を生成することが可能となる。動的データ・フィールドにはオプションがある。
【００４０】
これまでの記述により理解されるように、本発明は、通信ユニットおよびネットワーク・インフラストラクチャにおいてＩＰベースのプロトコル・スタックが利用されている場合に、容量の限られたエア・インタフェース上で（及び実際にはＢＴＳのバックホール・リンクにおいて）送られるデータを最小化することを可能とする。
【図面の簡単な説明】
【図１】
図１は、本発明に従って動作する通信ネットワークの概略図である。
【図２】
図２は、既知のＩＰバージョン４ヘッダの図である。
【図３】
図３ａ及び図３ｂは、本発明に従ったヘッダ設定手順のためのパケットを図解したものである。

Claims

通信ネットワークにおけるパケット・データの送受信方法であって、
通信ユニット及びネットワーク制御局においてインターネット・プロトコル（ＩＰ）・ヘッダの内容および対応するルックアップ・テーブル識別情報を受信するステップと、
前記の受信したＩＰヘッダの内容とそれらに対応する識別情報とを前記通信ユニット及び前記ネットワーク制御局に配置されたルックアップ・テーブルに格納するステップと、
ルックアップ・テーブル識別情報を含むデータ・パケットを前記通信ユニットと前記ネットワーク制御局との間で交換するステップと
を含む送受信方法。
請求項１記載の方法であって、ＩＰヘッダの内容及び対応するルックアップ・テーブル識別情報を受信する前記ステップが、前記通信ユニットと前記ネットワーク制御局との間でＩＰヘッダの内容及び対応するルックアップ・テーブル識別情報を交換することを含む方法。
請求項１記載の方法であって、ＩＰヘッダの内容及び対応するルックアップ・テーブル識別情報を受信する前記ステップが、遠隔データベースからＩＰヘッダの内容及び対応するルックアップ・テーブル識別情報をダウンロードすることを含む方法。
請求項１〜３のうちのいずれか一つに記載された方法であって、更に、ルックアップ・テーブル識別情報の受信を確認するステップを含む方法。
請求項１〜４のうちのいずれか一つに記載された方法であって、更に、前記ルックアップ・テーブル識別情報が、
（１）サービス品質
（２）所与のデータ・パケットが運んでいるプロトコルの種別
（３）送信元ＩＰアドレス
（４）宛先ＩＰアドレス
のうちの少なくともひとつに対応する方法。
パケット・データを送受信する装置であって、
インターネット・プロトコル（ＩＰ）・ヘッダの内容及び対応するルックアップ・テーブル識別情報を受信する手段と、
前記の受信したＩＰヘッダの内容及び対応する識別情報を格納するルックアップ・テーブルと、
ルックアップ・テーブル識別情報をデータ・パケットに添付し、前記データ・パケットをエア・インタフェースを介して送信する手段と
を備えた装置。
請求項６記載の装置であって、前記ルックアップ・テーブルが
（１）ＩＰヘッダ長
（２）ＩＰバージョン
（３）最大ホップ数
のうち少なくとも１つに対する格納された値を含み、前記の格納された値のそれぞれがルックアップ・テーブル識別情報と関連づけられている装置。
請求項６または７に記載された装置であって、移動通信ユニットを含む装置。
請求項６または７に記載された装置であって、通信ネットワーク制御局を含む装置。
請求項９記載の装置であって、プロトコルを終了させるようになされた装置。