(57)【要約】【課題】ヘッダ圧縮効率を改善し且つ移動ノードセキュリティを改善する技術を提供する。【解決手段】本発明の方法は、他の情報で変更された場合はその後のヘッダ圧縮で、情報が変更されなかった場合より大きくヘッダを圧縮するのを許すという情報を受信パケットがそのパケットのヘッダに有するとの決定に応答して、その情報を他の情報で変更することを含む。又、この方法は、少なくともヘッダを圧縮し、そしてその圧縮されたヘッダを含むパケットを送信することも含む。別の方法は、受信パケットがそのパケットのヘッダに順次の識別を有するとの決定に応答して、その順次の識別をランダムな識別へ変更し；及びそのパケットをコアネットワークへ送信する；ことを含む。装置及びプログラム製品も開示される。【選択図】図１
2015506151.tif 000002
【特許請求の範囲】
【請求項１】
他の情報で変更された場合はその後のヘッダ圧縮で、情報が変更されなかった場合より大きくヘッダを圧縮するのを許すという情報を受信パケットがそのパケットのヘッダに有するとの決定に応答して、その情報を他の情報で変更し；
少なくとも前記ヘッダを圧縮し；及び
前記圧縮されたヘッダを含むパケットを送信する；
ことを含む方法。
【請求項２】
前記圧縮の前に、ランダムな識別を順次の識別へ変更するのに基づき、パケットのヘッダにおける１つ以上の新たなチェック和を計算し；及びヘッダにおける１つ以上の元のチェック和を前記計算された１つ以上のチェック和に置き換える；ことを更に含む、請求項１に記載の方法。
【請求項３】
前記受信パケットのユーザデータグラムチェック和がイネーブルされることを決定し；及びユーザデータプロトコルチェック和をディスエイブルする；ことを含む請求項１又は２に記載の方法。
【請求項４】
前記情報は、パケットのヘッダにおけるランダムな識別であり、前記変更することは、更に、ランダムな識別を順次の識別に変更することを含む、請求項１に記載の方法。
【請求項５】
少なくとも、パケットの識別フィールドの現在値を、少なくとも１つの以前に受信したパケットの識別フィールドの少なくとも１つの値と比較することにより、前記受信パケットがそのパケットのヘッダにランダムな識別を有することを決定する；ことを更に含む、請求項４に記載の方法。
【請求項６】
前記方法は、更に、一連のパケットを受信し；及びその一連のパケットに対して変更、圧縮及び送信を遂行する；ことを含み、前記変更することは、パケットの識別フィールドにおけるランダムな値を、一連の順次の値からの値に置き換えるように遂行される、請求項４又は５のいずれかに記載の方法。
【請求項７】
前記変更することは、前記受信パケットが断片化パケットでないとの決定のみに応答して遂行される、請求項４又は５に記載の方法。
【請求項８】
前記パケットは、複数の識別を含み、前記変更及び圧縮することは、その複数の識別の各々について遂行される、請求項４又は５に記載の方法。
【請求項９】
前記受信パケットがそのパケットのヘッダに順次の識別を有するとの決定に応答して、前記変更を遂行せずに前記圧縮を遂行する；ことを更に含む、請求項４から８のいずれかに記載の方法。
【請求項１０】
前記方法は、更に、
パケットが属するフローのフロータイプを決定し；
前記フロータイプに基づいて、パケットのヘッダのフィールドから対応情報を抽出し；及び
前記対応情報が１つ以上の以前に受信したパケットに対し変化したかどうか決定する；
ことを含み、前記変更することは、更に、前記対応情報のいずれかが変化したとの決定に応答して、変化した対応情報をフィールドの元の情報に置き換えることを含み、その元の情報は、１つ以上の以前に受信したパケットを使用して以前に決定されたものである、請求項１に記載の方法。
【請求項１１】
付加的な情報を元の情報に置き換えることに基づいて、１つ以上の新たなチェック和を計算し；及びヘッダの１つ以上の元のチェック和をその計算された１つ以上のチェック和に置き換える；ことを更に含む、請求項１０に記載の方法。
【請求項１２】
前記付加的な情報は、次のもの、即ちインターネットプロトコルバージョン６（ＩＰｖ６）タイプのサービス、ＩＰｖ６ホップリミット、インターネットプロトコルバージョン４（ＩＰｖ４）タイプのサービス、又はＩＰｖ４有効期間、のうちの１つ以上を含む、請求項１０に記載の方法。
【請求項１３】
前記フロータイプは、第１のフロータイプ又は第２のフロータイプを含み、前記抽出することは、更に、その第１のフロータイプについては、ヘッダの識別フィールドにおけるランダムな識別を抽出することを含み、前記変更することは、更に、ランダムな識別を順次の識別に変更することを含む、請求項１０に記載の方法。
【請求項１４】
移動ノードによって遂行されるもので、前記送信は、ワイヤレスリンクを使用してパケットをベースステーションへ送信する、請求項１から１３のいずれかに記載の方法。
【請求項１５】
ベースステーションによって遂行されるもので、前記送信は、ワイヤレスリンクを使用してパケットを移動ノードへ送信する、請求項１から１４のいずれかに記載の方法。
【請求項１６】
前記パケットは、インターネットプロトコルを使用して少なくとも一部分フォーマットされる、請求項１から１５のいずれかに記載の方法。
【請求項１７】
１つ以上のプロセッサと、
コンピュータプログラムコードを含む１つ以上のメモリと、
を備えた装置において、前記１つ以上のメモリ及びコンピュータプログラムコードは、前記１つ以上のプロセッサと共に、前記装置が、少なくとも次のこと、即ち、
他の情報で変更された場合はその後のヘッダ圧縮で、情報が変更されなかった場合より大きくヘッダを圧縮するのを許すという情報を受信パケットがそのパケットのヘッダに有するとの決定に応答して、その情報を他の情報で変更し；
少なくともヘッダを圧縮し；及び
前記圧縮されたヘッダを含むパケットを送信する；
ことを遂行させるよう構成された、装置。
【請求項１８】
前記１つ以上のメモリ及びコンピュータプログラムコードは、前記１つ以上のプロセッサと共に、前記装置が、請求項２から１６に記載の方法のいずれか１つを遂行させるように更に構成された、請求項１７に記載の装置。
【請求項１９】
コンピュータに使用するためにここに実施されるコンピュータプログラムコードを保持するコンピュータ読み取り可能な媒体を備えたコンピュータプログラム製品において、コンピュータプログラムコードは、
他の情報で変更された場合はその後のヘッダ圧縮で、情報が変更されなかった場合より大きくヘッダを圧縮するのを許すという情報を受信パケットがそのパケットのヘッダに有するとの決定に応答して、その情報を他の情報で変更するためのコードと；
少なくともヘッダを圧縮するためのコードと；
前記圧縮されたヘッダを含むパケットを送信するためのコードと；
を含むものである、コンピュータプログラム製品。
【請求項２０】
請求項２から１６に記載の方法のいずれか１つを遂行するためのコードを更に含む、請求項１９に記載のコンピュータプログラム製品。
【請求項２１】
他の情報で変更された場合はその後のヘッダ圧縮で、情報が変更されなかった場合より大きくヘッダを圧縮するのを許すという情報を受信パケットがそのパケットのヘッダに有するとの決定に応答して、その情報を他の情報で変更するための手段と；
少なくともヘッダを圧縮するための手段と；
前記圧縮されたヘッダを含むパケットを送信するための手段と；
を備えた装置。
【請求項２２】
受信パケットがそのパケットのヘッダに順次識別を有するとの決定に応答して、その順次識別をランダムな識別へ変更し；及び
前記パケットをコアネットワークへ送信する；
ことを含む方法。
【請求項２３】
順次の識別をランダムな識別へ変更するのに基づきパケットのヘッダにおける１つ以上の新たなチェック和を計算し；及びヘッダにおける１つ以上の元のチェック和を前記計算された１つ以上のチェック和に置き換える；ことを更に含む、請求項２２に記載の方法。
【請求項２４】
前記少なくとも１つのチェック和のうちの少なくとも１つは、ユーザデータグラムプロトコルチェック和であり、前記方法は、更に、ユーザデータプロトコルチェック和をイネーブルすることを含む、請求項２３に記載の方法。
【請求項２５】
少なくとも、パケットの識別フィールドの現在値を、少なくとも１つの以前に受信したパケットの識別フィールドの少なくとも１つの値と比較することにより、前記受信パケットがそのパケットのヘッダに順次の識別を有することを決定する；ことを更に含む、請求項２２から２４のいずれかに記載の方法。
【請求項２６】
前記方法は、更に、一連のパケットを受信し；及びその一連のパケットに対して変更、圧縮及び送信を遂行する；ことを含み、前記変更することは、パケットの識別フィールドにおけるランダムな値を、一連の順次の値からの値に置き換えるように遂行される、請求項２２から２５のいずれかに記載の方法。
【請求項２７】
ベースステーションによって遂行されるもので、前記送信は、パケットをコアネットワークへ送信する、請求項２２から２６のいずれかに記載の方法。
【請求項２８】
前記変更することは、前記受信パケットが断片化パケットでないとの決定のみに応答して遂行される、請求項２２から２７に記載の方法。
【請求項２９】
前記パケットは、複数の識別を含み、前記変更及び圧縮することは、その複数の識別の各々について遂行される、請求項２２に記載の方法。
【請求項３０】
前記パケットは、インターネットプロトコルを使用して少なくとも一部分フォーマットされる、請求項２２から２９のいずれかに記載の方法。
【請求項３１】
１つ以上のプロセッサと、
コンピュータプログラムコードを含む１つ以上のメモリと、
を備えた装置において、前記１つ以上のメモリ及びコンピュータプログラムコードは、前記１つ以上のプロセッサと共に、前記装置が、少なくとも次のこと、即ち、
受信パケットがそのパケットのヘッダに順次の識別を有するとの決定に応答して、その順次の識別をランダムな識別へ変更し；及び
前記パケットをコアネットワークへ送信する；
ことを遂行させるように構成された、装置。
【請求項３２】
前記１つ以上のメモリ及びコンピュータプログラムコードは、前記１つ以上のプロセッサと共に、前記装置が、請求項２３から２９に記載の方法のいずれか１つを遂行させるように更に構成された、請求項３１に記載の装置。
【請求項３３】
コンピュータに使用するために実施されるコンピュータプログラムコードを保持するコンピュータ読み取り可能な媒体を備えたコンピュータプログラム製品において、そのコンピュータプログラムコードは、
受信パケットがそのパケットのヘッダに順次の識別を有するとの決定に応答して、その順次の識別をランダムな識別へ変更するコードと；
前記パケットをコアネットワークへ送信するコードと；
を含む、コンピュータプログラム製品。
【請求項３４】
請求項２３から２９に記載の方法のいずれか１つを遂行するためのコードを更に含む、請求項３３に記載のコンピュータプログラム製品。
【請求項３５】
受信パケットがそのパケットのヘッダに順次の識別を有するとの決定に応答して、その順次の識別をランダムな識別へ変更するための手段と；
前記パケットをコアネットワークへ送信するための手段と；
を備えた、装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、パケットネットワークに関するもので、より詳細には、パケットを使用するワイヤレスネットワークとのワイヤレス通信において移動ノードへ情報を配信することに関する。
【背景技術】
【０００２】
本章は、以下に述べる発明の背景又は状況を示すことが意図される。ここでの説明は、遂行はできるが必ずしも以前に考案され、具現化され又は説明されたものではない概念を含み得る。それ故、特に指示のない限り、本章に述べることは、本願の説明に対する従来技術でもないし、且つ本章に含ませることにより従来技術であると認めるものでもない。
【０００３】
明細書及び／又は図面に見られる以下の省略形は、次のように定義される。
ＡＭＲ                    適応マルチレート
ＤＬ                      ダウンリンク（ベースステーションから移動ノードへ）
ｅＮＢ又はｅＮｏｄｅＢ    進化型ＮｏｄｅＢ（ＬＴＥのベースステーション）
ＧＰＲＳ                  汎用パケット無線サービス
ＧＴＰ                    ＧＰＲＳトンネルプロトコル
ＩＤ                      識別
ＩＥＴＦ                  インターネットエンジニアリングタスクフォース
ＩＰ                      インターネットプロトコル
Ｌ１                      レイヤ１（例えば、物理的レイヤ）
ＬＴＥ                    長期進化
ＭＡＣ                    メディアアクセスコントロール
ＭＮ                      移動ノード
ＰＤＣＰ                  パケットデータコンバージェンスプロトコル
ＰＤＵ                    プロトコルデータユニット
ＰＥＲ                    パケットエラー率
ＲＬＣ                    無線リンクプロトコル
ＲＯＨＣ                  頑健なヘッダ圧縮
ＲＴＰ                    リアルタイムプロトコル
ＴＢＳ                    送信ブロックサイズ
ＴＴＩ                    送信時間インターバル
ＵＤＰ                    ユーザデータグラムプロトコル
ＵＬ                      アップリンク（移動ノードからベースステーションへ）
ＶＯＩＰ                  ボイスオーバーＩＰ
ＷＢ                      ワイドバンド
ＷＩＭＡＸ                マイクロ波アクセスのための世界的規模の相互運用性
【０００４】
ワイヤレスアクセスネットワークにおいてオールＩＰ及びボイスオーバーＩＰへ移行する（例えば、ＬＴＥ、ＷＩＭＡＸ、等）ことは、ヘッダのためにオーバーヘッドを劇的に増加させる。例えば、ＶＯＩＰは、ＲＴＰ／ＵＤＰ／ＩＰプロトコルの組で搬送される。１２．２ｋｂｐｓ（キロビット／秒）のセルラーコーデックエンコードレートを仮定すれば、ＲＴＰ／ＵＤＰ／ＩＰｖ４（ＩＰバージョン４）に対してペイロードが３４バイトとなり且つヘッダーオーバーヘッドが４０バイトとなる。これは、膨大なオーバーヘッドであり、明らかに、貴重なワイヤレス帯域巾を受け容れられないほど使用することになる。これは、ＶＯＩＰの場合、各クライアント装置が２０ｍｓ（ミリ秒）ごとに１つのＲＴＰ／ＵＤＰ／ＩＰフレームを送信するために特に言えることである。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ＩＥＴＦは、ＲＴＰ／ＵＤＰ／ＩＰｖ４ヘッダを１バイトまで圧縮するためにＲＯＨＣプロトコル（ＲＦＣ３０９５）を定義した。しかしながら、ＲＯＨＣプロトコルを具現化する圧縮器は、特に、圧縮器がランダムＩＰ−ＩＤ遭遇するときには、ＲＴＰ／ＵＤＰ／ＩＰｖ４ヘッダを１バイトに圧縮するのに使用することができない。ランダムＩＰ−ＩＤの場合には、ＲＯＨＣ圧縮器は、未圧縮のＩＰ−ＩＤを下位レイヤへ送信する。この場合に、ＲＯＨＣ圧縮器は、ＩＰパケットによりランダムＩＰ−ＩＤが使用されそしてＵＤＰチェック和がディスエイブルされるときには、ＲＴＰ／ＵＤＰ／ＩＰｖ４ヘッダを５バイトまでしか圧縮できない。
【０００６】
クライアントマシンが常に順次ＩＰ−ＩＤを使用することを保証することで、ランダムＩＰ−ＩＤの影響を軽減することができる。しかしながら、エンドホストが効率を上げるため順次ＩＰ−ＩＤの使用を強いられる場合には、ワイヤレス装置は、次のようなセキュリティ攻撃、即ちＯＳ（オペレーティングシステム）指紋攻撃；アイドルスキャン；及び推定データボリューム又はパケットレート；を受け易い。これらのセキュリティ問題は、順次ＩＰ−ＩＤをもつパケットがコアネットワーク又はインターネットを通してルーティングされるときに導入される。
【０００７】
更に、インターネットでは、ほとんどのセキュアなクライアントマシンが、それらのセキュリティ問題を回避するためランダムＩＰ−ＩＤを使用するように構成されており又は構成されるであろうから、種々のクライアントの振る舞いを変更することはできない。
【課題を解決するための手段】
【０００８】
規範的実施形態における方法は、他の情報で変更された場合はその後のヘッダ圧縮で、情報が変更されなかった場合より大きくヘッダを圧縮するのを許すという情報を受信パケットがそのパケットのヘッダに有するとの決定に応答して、その情報を他の情報で変更することを含む。又、この方法は、少なくともヘッダを圧縮し、そしてその圧縮されたヘッダを含むパケットを送信することも含む。
【０００９】
更に別の規範的な実施形態における装置は、１つ以上のプロセッサと、コンピュータプログラムコードを含む１つ以上のメモリとを備えている。１つ以上のメモリ及びコンピュータプログラムコードは、１つ以上のプロセッサと共に、装置が、少なくとも次のこと：即ち他の情報で変更された場合はその後のヘッダ圧縮で、情報が変更されなかった場合より大きくヘッダを圧縮するのを許すという情報を受信パケットがそのパケットのヘッダに有するとの決定に応答して、その情報を他の情報で変更し；少なくともヘッダを圧縮し；及びその圧縮されたヘッダを含むパケットを送信する；ことを遂行させるように構成される。
【００１０】
付加的な規範的な実施形態において、コンピュータに使用するためにここに実施されるコンピュータプログラムコードを保持するコンピュータ読み取り可能な媒体を備えたコンピュータプログラム製品が開示される。コンピュータプログラムコードは、他の情報で変更された場合はその後のヘッダ圧縮で、情報が変更されなかった場合より大きくヘッダを圧縮するのを許すという情報を受信パケットがそのパケットのヘッダに有するとの決定に応答して、その情報を他の情報で変更するためのコードと；少なくともヘッダを圧縮するためのコードと；その圧縮されたヘッダを含むパケットを送信するためのコードと；を含む。
【００１１】
更に別の規範的実施形態における装置は、他の情報で変更された場合はその後のヘッダ圧縮で、情報が変更されなかった場合より大きくヘッダを圧縮するのを許すという情報を受信パケットがそのパケットのヘッダに有するとの決定に応答して、その情報を他の情報で変更するための手段と；少なくともヘッダを圧縮するための手段と；その圧縮されたヘッダを含むパケットを送信するための手段と；を備えている。
【００１２】
別の規範的な実施形態における方法は、受信パケットがそのパケットのヘッダに順次の識別を有するとの決定に応答して、その順次の識別をランダムな識別へ変更し；及びそのパケットをコアネットワークへ送信する；ことを含む。
【００１３】
更に別の規範的な実施形態における装置は、１つ以上のプロセッサと、コンピュータプログラムコードを含む１つ以上のメモリとを備えている。１つ以上のメモリ及びコンピュータプログラムコードは、１つ以上のプロセッサと共に、装置が、少なくとも次のこと：即ち受信パケットがそのパケットのヘッダに順次の識別を有するとの決定に応答して、その順次の識別をランダムな識別へ変更し；及びそのパケットをコアネットワークへ送信する；ことを遂行させるように構成される。
【００１４】
付加的な規範的な実施形態において、コンピュータに使用するためにここに実施されるコンピュータプログラムコードを保持するコンピュータ読み取り可能な媒体を備えたコンピュータプログラム製品が開示される。コンピュータプログラムコードは、受信パケットがそのパケットのヘッダに順次の識別を有するとの決定に応答して、順次の識別をランダムな識別へ変更し；及びそのパケットをコアネットワークへ送信する；ことを含む。
【００１５】
更に別の規範的な実施形態において、開示される装置は、受信パケットがそのパケットのヘッダに順次の識別を有するとの決定に応答して、その順次の識別をランダムな識別へ変更するための手段と；そのパケットをコアネットワークへ送信するための手段と；を備えている。
【図面の簡単な説明】
【００１６】
【図１】本発明が使用される規範的システムのブロック図である。
【図２】移動ノード及びｅＮＢの論理的構成を示すブロック図である。
【図３Ａ】ＰＥＲ（パケットエラー率）が２％の場合のＲＯＨＣ性能に対してＩＰｖ４ヘッダにランダムなＩＰ  ＩＤフィールドをもたせた結果を示すテーブルである。
【図３Ｂ】本発明の規範的実施形態の性能上の利益を示すテーブルである。
【図４】ＲＴＰ／ＵＤＰ／ＩＰｖ４ヘッダ及びそれらのフィールドを含むパケットヘッダを示す一例である。
【図５】ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダ及びそれらのフィールドを含むパケットヘッダを示す一例である。
【図６】アップリンクでは移動ノード又はダウンリンクではｅＮＢにより遂行されて、ヘッダ圧縮効率を改善し且つ移動ノードセキュリティを改善する方法のフローチャートである。
【図７】アップリンクにおいてｅＮＢにより遂行されて、ＶｏＩＰセッションの端−端信頼性を改善し且つ移動ノードセキュリティを改善するための方法のフローチャートである。
【図８】ダウンリンクにおいてｅＮＢにより遂行されて、ヘッダ圧縮効率を改善し且つ移動ノードセキュリティを改善するための別の方法のフローチャートである。
【図９】リレーノードを使用する規範的システムを示す。
【発明を実施するための形態】
【００１７】
ヘッダ圧縮効率を改善し且つ移動ノードセキュリティを改善する規範的な技術の更なる説明を進める前に、本発明が使用される規範的なシステムについて述べる。例えば、図１は、本発明が使用される規範的なシステムのブロック図である。図１において、移動ノード１１０は、ワイヤレスリンク１２９を経て、ＬＴＥのベースステーションである進化型ＮｏｄｅＢ（ｅＮＢ）１３６とワイヤレス通信する。ネットワーク１００は、この例では、ｅＮＢ１３６と、サービングゲートウェイ（ＳＧＷ）１５１と、移動管理エンティティ（ＭＭＥ）１９１と、パケットデータネットワーク（ＰＤＮ）ゲートウェイ（ＧＷ）１９４とを備えている。ネットワーク１００は、ＰＤＮ  ＧＷ１９４を経て別のネットワーク（例えば、インターネット１４０）に結合される。コアネットワークは、ＳＧＷ１５１、ＭＭＥ１９１、及びＰＤＮ  ＧＷ１９４を含む。ＲＡＮは、ｅＮＢ１３６を含み、そしてコアネットワークは、ＳＧＷ１５１、ＭＭＥ１９１、及びＰＤＮ  ＧＷ１９４を含む。
【００１８】
ＭＮ１１０は、１つ以上のプロセッサ１２０、１つ以上のメモリ１２５及び１つ以上のトランシーバ１３０を備え、これらは、１つ以上のバス１２７を通して相互接続される。１つ以上のトランシーバ１３０は、１つ以上のアンテナ１２８に接続される。１つ以上のメモリ１２５は、コンピュータプログラムコード１２３を含む。１つ以上のメモリ１２５及びコンピュータプログラムコード１２３は、１つ以上のプロセッサ１２０とで、ＭＮ１１０に、ここに述べるオペレーションの１つ以上を遂行させるように構成される。
【００１９】
ｅＮＢ１３６は、１つ以上のプロセッサ１５０と、１つ以上のメモリ１５５と、１つ以上のネットワークインターフェイス（Ｎ／Ｗ  Ｉ／Ｆ）１６１と、１つ以上のトランシーバ１６０とを備え、それらは、１つ以上のバス１５７を経て相互接続される。１つ以上のトランシーバ１６０は、１つ以上のアンテナ１５８に接続される。１つ以上のメモリ１５５は、コンピュータプログラムコード１５３を含む。１つ以上のメモリ１５５及びコンピュータプログラムコード１５３は、１つ以上のプロセッサ１５０とで、ｅＮＢ１３６に、ここに述べるオペレーションの１つ以上を遂行させるように構成される。
【００２０】
ＳＧＷ１５１は、１つ以上のプロセッサ１８０と、１つ以上のメモリ１９５と、１つ以上のネットワークインターフェイス（Ｎ／Ｗ  Ｉ／Ｆ）１９０とを備え、それらは、１つ以上のバス１８７を経て相互接続される。１つ以上のメモリ１９５は、コンピュータプログラムコード１９７を含む。１つ以上のメモリ１９５及びコンピュータプログラムコード１９７は、１つ以上のプロセッサ１８０とで、ＳＧＷ１５１に、ここに述べるオペレーションの１つ以上を遂行させるように構成される。
【００２１】
ネットワークインターフェイス１６１、１９０は、例えば、良く知られた種々のインターフェイスを使用してネットワーク１００の他の要素へのアクセスを与える。例えば、ｅＮＢ１３６とＳＧＷ１５１との間のインターフェイスは、ｅＮＢ１３６とＭＭＥ１９１との間のインターフェイスと同様に、Ｓ１インターフェイスを含む。ＭＭＥ１９１とＳＧＷ１５１との間のインターフェイスは、Ｓ１１インターフェイスを含み、そしてＰＤＮ  ＧＷ１９４とＳＧＷ１５１との間のインターフェイスは、Ｓ５／Ｓ８インターフェイスを含む。
【００２２】
１つの例において、ＭＮ１１０のコンピュータプログラムコード１２３の一部分として実施されるアプリケーション１３１は、インターネット１４０の対応ノード１４３と通信する。アプリケーション１３１と対応ノード１４３との間でＩＰパケット（図１には示さず）が交換される。
【００２３】
ＭＮ１１０の種々の実施形態は、これに限定されないが、セルラー電話、スマートホン、リレーノード、Ｍ２Ｍ装置、ワイヤレス通信能力を有するパーソナルデジタルアシスタント（ＰＤＡ）、ワイヤレス通信能力を有するポータブルコンピュータ、ワイヤレス通信能力を有するデジタルカメラのような画像捕獲装置、ワイヤレス通信能力を有するゲーム機、ワイヤレス通信能力を有する音楽記憶及び再生機器、ワイヤレスインターネットアクセス及びブラウジングを許すインターネット機器、並びにそのような機能を組み合わせて合体するポータブルユニット又はターミナルを含む。又、ポータブルノード１１０は、ユーザ装置又は移動装置のような他の名前で呼ばれてもよい。
【００２４】
メモリ１２５、１５５及び１９５は、ローカル技術環境に適した任意の形式のもので、半導体ベースのメモリ装置、磁気メモリ装置及びシステム、光学メモリ装置及びシステム、固定メモリ及び取り外し可能なメモリのような適当なデータ記憶技術を使用して具現化される。プロセッサ１２０、１５０及び１８０は、ローカル技術環境に適した任意の形式のもので、非限定例として、汎用コンピュータ、特殊目的コンピュータ、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、及びマルチコアプロセッサアーキテクチャーに基づくプロセッサを含む。
【００２５】
図２は、移動ノード１１０及びｅＮＢ１３６の論理的構成を示すブロック図である。ＭＮ１１０は、アプリケーションレイヤ、ＩＰレイヤ、ＰＤＣＰレイヤ、ＲＬＣレイヤ、ＭＡＣレイヤ、及びＬ１レイヤを含む。ｅＮＢ１３６は、上位／他のレイヤ（例えば、リレーレイヤ）、ＰＤＣＰレイヤ、ＲＬＣレイヤ、ＭＡＣレイヤ、及びＬ１レイヤを含む。ここに示すレイヤは、ユーザプレーンプロトコルアーキテクチャー／スタックのレイヤである。これらレイヤは、少なくとも一部分は、対応するコンピュータプログラムコード１２３、１５３において具現化される。
【００２６】
ＭＮ１１０では、アプリケーション１３１は、少なくとも一部分は、アプリケーションレイヤにおいて具現化される。ＩＰパケット２０５は、ＭＮ１１０及びｅＮＢ１３６のレイヤ（及び図２に示されていない他のコアネットワーク要素）を通過した後に、アプリケーション１３１と対応ノード１４３との間で通信される。ヘッダ変更プロセス２１０は、（ヘッダを変更したパケット２１１を生成するため）ＩＰヘッダに対してある変更を遂行するか、或いは以下に詳細に述べる技術に基づき変更なしにパケット２０５を通過させるプロセスである。ヘッダ変更プロセス２１０は、ＩＰフローテーブル２３４を使用する。アップリンクでは、ＲＯＨＣ圧縮器２２０は、パケット２１１、２０５に基づき圧縮パケット２２１を生成する。それらの圧縮パケット２２１は、下位レイヤ（ＲＬＣ、ＭＡＣ、及びＬ１レイヤ）を経、リンク１２９を通して、ｅＮＢ１３６へ送信される。
【００２７】
ｅＮＢ１３６において、Ｌ１、ＭＡＣ及びＲＬＣレイヤは、圧縮パケット２４１を発生する。ＲＯＨＣ解凍器２５０は、圧縮パケット２４１に対して動作して、非圧縮パケット２５１を生成する。ヘッダ変更プロセス２６０は、ヘッダを変更したパケット２７１を生成するか又はＩＰパケット２５１を通過させるために以下に詳細に述べる幾つかのオペレーションを遂行するプロセスである。ヘッダ変更プロセス２６０は、ＩＰフローテーブル２８４を使用する。
【００２８】
ダウンリンクに関しては、対応ノード１４３から受け取られたＩＰパケット２５５は、以下に述べるオペレーションを使用して、ヘッダ変更プロセス２６０により作用されて、ヘッダを変更したパケット２６１を生成するか、又はパケット２５５を通過させる。ＲＯＨＣ圧縮器２４０は、パケット２６１、２５５に基づき圧縮パケット２４１を生成する。それらの圧縮パケット２４１は、下位レイヤ（ＲＬＣ、ＭＡＣ、及びＬ１レイヤ）を経、リンク１２９を通して、ＭＮ１１０へ送信される。
【００２９】
ＭＮ１１０において、Ｌ１、ＭＡＣ及びＲＬＣレイヤは、圧縮パケット２２１を発生する。ＲＯＨＣ解凍器２３０は、圧縮パケット２２１に対して作用して、非圧縮パケット２３１を生成する。ダウンリンクにおけるヘッダ変更プロセス２１０は、非圧縮パケット２３１に対してオペレーションを行っても行わなくてもよい。例えば、移動ノード１１０がハンドセットである場合には、プロセッサ２１０は、付加的な処理を遂行しない。しかしながら、移動ノード１１０がルータとして動作する場合には、この機能は、例えば、図７について述べるように、順次ＩＰ−ＩＤをランダムなＩＰ−ＩＤへと変換することができる。
【００３０】
ヘッダ変更プロセス２１０／２６０は、ここでは、説明を容易にするために使用されたに過ぎない。ヘッダ変更プロセス２１０／２６０に関するここに開示するオペレーションは、他のエンティティ（例えば、ＰＤＣＰレイヤ）によって遂行されてもよく、それらのオペレーション専用の実際のプロセス２１０／２６０はない。
【００３１】
ヘッダの現在圧縮に伴う問題に戻ると、図３Ａに示すテーブルは、ＰＥＲが２パーセントの場合のＲＯＨＣ性能に対しＩＰｖ４ヘッダのＩＰ−ＩＤフィールドにランダムなＩＰ−ＩＤをもたせた結果を示す。又、この図は、ＲＴＰ／ＵＤＰ／ＩＰｖ４ヘッダ圧縮効率をディスエイブルＵＤＰチェック和と共に使用している。平均圧縮ヘッダサイズは、１．０１９１から３．０２０９へほぼ２バイト増加することが分かる。ＩＰｖ４（ＩＰバージョン４）のＩＰ−ＩＤフィールドは、２バイト長さであり、このフィールドがランダムであるとき、ＲＯＨＣ圧縮器２２０、２４０は、フィールドを変更せずに送信する。トンネル型のＩＰｖ４・イン・ＩＰｖ４ヘッダの場合には、ランダムＩＰ−ＩＤは、圧縮ヘッダの平均サイズに４バイトを付加することができる。ＩＰ−ＩＤフィールド及びＵＤＰチェック和の圧縮が許されない場合には、おそらく、全レート１２．２ＫｂｐｓのＡＭＲデータが、２９６ビットのＴＢＳサイズでは受け容れられず、ボイスＰＤＵは、次に利用可能な３２８ビットのＴＢＳ値で送信されねばならない。図３Ｂに示すシミュレーション結果は、２９６ビットではなく３２８ビットのＴＢＳサイズの使用で容量／サブフレームが２３．７から２５．１（ビット／秒／サブフレーム）へ変化し、５．９パーセントの低下となることを予想している。又、このシミュレーション結果は、データレート８．８５Ｋｂｐｓでは、節約が１０．６％（パーセント）となり、そして６．６Ｋｂｐｓのデータレートでは、節約が１２．５％（パーセント）となることを予想している。
【００３２】
又、ＩＰｖ４・イン・ＩＰｖ４トンネル又はＴＴＩバンドルは、この問題を更に悪化させる。ＴＴＩバンドルは、ＶｏＩＰカバレージを拡張するために配備され、それ故、これも考慮に入れねばならない。
【００３３】
図４及び５は、ヘッダ及びそれらのフィールドを示すと共に、ヘッダフィールドが頻繁に変化することを示すのに使用される。図４は、ＲＴＰ／ＵＤＰ／ＩＰｖ４ヘッダ及びそれらのフィールドを含むパケットヘッダ４００−１を示す例である。図４では、次の頭字語が使用される。Ｒは、「予約(Reserved)」を意味し、ＤＦは、「断片化しない(Don’t Fragment)」を意味し、ＭＦは、「より多くの断片(More Fragment)」を意味し、Ｖは、「バージョン(Version)」を意味し、Ｐは、「パッディング(Padding)」を意味し、Ｘは、「拡張(Extension)」を意味し、ＣＣは、「ＣＳＲＣカウント(CSRC Count)」を意味し、Ｍは、「マーカー(Marker)」を意味し、そしてＰＴは、「ペイロードタイプ(Payload Type)」を意味する。識別フィールドは、典型的に、１６ビットであり、あるデータグラムの断片を別のデータグラムの断片から識別するのに使用される。インターネットデータグラムの起点プロトコルモジュールは、識別フィールドを、そのデータグラムがインターネットシステムにおいてアクティブである時間中にそのソース・行先対及びプロトコルに対して独特であるべき値にセットする。しかしながら、識別フィールドを擬似ランダム数に基づいてセットするシステムは多数ある。例えば、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）のセクション３．５．２．１、コメントの要求：６２７４、“Security Assessment of the Internet Protocol Version 4”（２０１１年７月）を参照されたい。完全なデータグラムの起点プロトコルモジュールは、ＭＦビットをゼロにクリアすると共に、断片オフセットフィールドをゼロにクリアする。ＤＦは、データグラムの断片化をコントロールするビットで、０（零）は、必要に応じて断片を指示し、１（一）は、断片化しないことを指示する。ＭＦは、データグラムが付加的な断片を含むかどうか指示するビットで、０（零）は、このパケットが最後の断片であることを指示し、１（一）は、この断片に続く付加的なパケット（断片）を指示する。断片オフセットは、１３ビットであり、断片化されたデータグラムの再アッセンブルを指令するのに使用される。
【００３４】
ある頻度で変化するアイテムは、次のフィールド、即ちサービスのタイプ、ＩＰ−ＩＤ（「識別」として示された）、有効期間、チェック和、ＣＣ、Ｍ、ＰＴ、シーケンス番号、タイムスタンプ、及びＣＳＲＣ識別子、である。
【００３５】
図５は、ＲＴＰ／ＵＤＰ／ＩＰｖ６（ＩＰｖ６は、ＩＰバージョン６を意味する））ヘッダ及びそれらのフィールドを含むパケットヘッダ４００−２を示す例である。図５では、次の頭字語が使用される。Ｖは、「バージョン」を意味し、Ｐは、「パッディング」を意味し、Ｘは、「拡張」を意味し、ＣＣは、「ＣＳＲＣカウント」を意味し、Ｍは、「マーカー」を意味し、そしてＰＴは、「ペイロードタイプ」を意味する。
【００３６】
特に関心があるのは、パケットヘッダ４００−１に示されたＩＰ−ＩＤである。上述したように、ＩＰ−ＩＤフィールドにランダムなＩＰ−ＩＤをもたせることで、ＲＯＨＣ圧縮器２２０、２４０による圧縮が減少される。というのは、ＲＯＨＣ圧縮器２２０、２４０は、ＩＰ−ＩＤを圧縮せずにランダムなＩＰ−ＩＤをもつパケット２０５、２５５を転送するからである。この開示は、ヘッダ圧縮効率を改善すると同時に、前記セキュリティ攻撃からの移動ノードの端−端セキュリティを改善する上で助けとなる解決策を提案する。即ち、ここに述べる規範的な実施形態は、ワイヤレスアクセスネットワークのエッジノード（例えば、ｅＮｏｄｅＢ又はＭＮ１１０）が、無線リンク１２９を経てヘッダ圧縮がイネーブルされるところの移動ノード１１０と対応ノード１４３との間に確立される種々のＩＰフローに関連したダウンリンク／アップリンクＩＰパケット１０５、２５５のＩＰ−ＩＤを監視して、特定のフローがランダムなＩＰ−ＩＤを使用しているか否か決定することを提案する。特定のフローがランダムなＩＰ−ＩＤを使用することをエッジノードが識別する場合には、エッジノードは、ランダムなＩＰ−ＩＤを順次のＩＰ−ＩＤへ変更して、その変更したパケット２１１、２６１をＲＯＨＣ圧縮器２２０、２４０へ送信する。
【００３７】
ＩＰ−ＩＤフィールドに加えて、圧縮効率を改善できる他の考えられるエリアもある。ある頻度で変化するアイテムは、次のフィールド、即ちＤＳ（区別化サービス）タイプ、ＩＰｖ６ホップリミット、チェック和、ＣＣ、Ｍ、ＰＴ、シーケンス番号、タイムスタンプ、ＣＳＲＣ識別子、ＩＰｖ４タイプ・オブ・サービス（ＴＯＳ）、及びＩＰｖ４タイム・ツー・リブ（ＴＴＬ）、である。ダウンリンクでは、パケットが対応ノードからｅＮｏｄｅＢへルーティングされる間に所与のデータフローにおいて前記フィールドの幾つかが変化することも考えられる。例えば、ＴＴＬ又はＩＰｖ６ホップカウントの値は、ＩＰパケットが対応ノードからｅＮｏｄｅＢへどのようにルーティングされるかに依存する。進行するホップの数に基づいて、各パケットのＩＰｖ４  ＴＴＬ（又はＩＰｖ６ホップリミット）は、異なる値を有する。ＩＰｖ４  ＴＯＳ（又はＩＰｖ６トラフィッククラス）は、サービスクオリティの理由で中間ルータにより変更することができる。対応ノードは、２つのノード、典型的に、ＭＮとインターネットのようなネットワーク上のノードとの間の通信におけるエンドポイントであることに注意されたい。
【００３８】
従って、ＩＰｖ４  ＩＰ−ＩＤに加えて、ｅＮｏｄｅＢは、前記パラメータを監視し、変化した値を以前の値へ変更して、ヘッダ圧縮性能への影響を回避する。これを行うのが適当であるのは、ホップカウント及びＴＯＳが変化しても、移動ノードの振る舞いに影響を及ぼさないからである。
【００３９】
ＩＰ−ＩＤの変更に関して、端−端データ転送への機能的影響を回避するために、次のことを行う。
【００４０】
１）ｅＮｏｄｅＢ／ＭＮ下位レイヤ（例えば、ＰＤＣＰレイヤ）は、ＩＰパケット２０５、２５５が断片化されない場合だけＩＰ−ＩＤを順次へ変更する。断片化されたＩＰパケットのＩＰ−ＩＤは、不変のまま送信される。
【００４１】
必要に応じて、ｅＮｏｄｅＢ／ＭＮ下位レイヤ（例えば、ＰＤＣＰレイヤ）は、ＩＰ−ＩＤが変更された後もＩＰパケットに関連したチェック和が有効であるよう保証するために、ＩＰ−ＩＤを変更した後にチェック和を再計算する。
【００４２】
移動装置のセキュリティを改善するために、ｅＮｏｄｅＢ１３６は、アップリンクパケット（例えば、２５１）の順次ＩＰ−ＩＤをランダムなＩＰ−ＩＤへと変化させた後に、アップリンクパケット２７１をコアネットワークへ送信する。ＩＰ−ＩＤを変化させた後に、ｅＮｏｄｅＢ１３６は、必要に応じて、ＵＤＰ／ＴＣＰのチェック和も再計算する。
【００４３】
図６は、ヘッダ圧縮効率を改善する方法のフローチャートである。図６に示す方法は、アップリンクでは移動ノード１１０により（例えば、ヘッダ変更プロセス２１０により）又はダウンリンクではｅＮＢ１３６により（例えば、ヘッダ変更プロセス２６０により）遂行される。それ故、ブロック６０５において、ヘッダ変更プロセス２１０／２６０は、アップリンクではＭＮ１１０における上位レイヤ（例えば、ＩＰレイヤ）から、又はダウンリンクではｅＮＢ１３６における対応ノードから、パケットを受け取る。
【００４４】
例えば、ブロック６１０の前にＰＤＣＰレイヤにより付加的な処理が行われてもよいことに注意されたい。例えば、ＰＤＣＰレイヤは、上位レイヤ又は対応ノードにより送られたパケット２０５／２５５を受け取り、次いで、その受け取ったパケット２０５／２５５を、ＳＲＣ（ソース）ＩＰアドレス、ＤＥＳＴ（行先）ＩＰアドレス、ＳＲＣポート及びＤＥＳＴポート、プロトコルタイプ、等に基づいて分類する。それとは別に、ＰＤＣＰレイヤは、分類の目的でＬＴＥ特有の情報も使用することができる。例えば、ＬＴＥでは、ＲＴＰ／ＵＤＰ／ＩＰパケットは、ＱＣＩ  １（ＱｏＳ、サービスクオリティ、クラス識別子）専用ベアラに関連し、それ故、ｅＮｏｄｅＢ１３６（例えば）は、ＧＴＰトンネルＩＤ又はＰＤＣＰフローに関連した論理的チャンネルを分類の目的で使用することもできる。分類は、例えば、フローが新たなフローであるか又は以前に見たフローであるか決定するために有用である。
【００４５】
ブロック６１０において、ヘッダ変更プロセス２１０／２６０は、受け取ったＩＰパケット２０５／２５５がＩＰ断片（例えば、複数のパケットに分割された情報）であるかどうか決定する。ヘッダ変更プロセス２１０／２６０は、例えば、ＩＰｖ４ヘッダのＭＦフラグ及び断片オフセットの組み合わせを監視することにより、パケットが断片化されたか否か識別することができる。受け取ったＩＰパケット２０５／２５５がＩＰ断片である場合には（ブロック６１０＝イエス）、ヘッダ変更プロセス２１０／２６０は、ブロック６５０においてパケットを不変のまま（例えば、パケット２０５／２５５として）ＲＯＨＣ圧縮器２２０／２４０へ送出する。
【００４６】
受け取ったＩＰパケット２０５／２５５がＩＰ断片でない場合には（ブロック６１０＝ノー）、ヘッダ変更プロセス２１０／２６０は、ブロック６１５において、受け取ったＩＰパケット２０５／２５５が新たなフローの一部分であるかどうか決定する。もしそうであれば（ブロック６１５＝イエス）、ヘッダ変更プロセス２１０／２６０は、ＰＤＣＰ  ＩＰフローテーブル２３４／２８４における新たなフローとしてコンテキストを生成する（ブロック６２０）。コンテキストは、図２において、コンテキスト２１３として示されている。一例において、各フローは、フローＩＤ２１２、コンテキスト２１３、及びランダム／順次フラグ２１４を有すると仮定する。フローＩＤ２１２は、特定のフローに対してテーブルにアクセスする手段であり、そのようなＩＤ２１２は、ある具現化では（例えば、コンテキスト２１３がフローも定義する場合には）使用されない。もしそうでなければ（ブロック６１５＝ノー）、ヘッダ変更プロセス２１０／２６０は、ＩＰヘッダ（例えば、ヘッダ４００の一部分）からＩＰ−ＩＤを抽出し、そしてそのＩＰ−ＩＤをＰＤＣＰＩＰフローテーブル２３４／２８４に記憶する（ブロック６２５）。
【００４７】
ブロック６３０において、ヘッダ変更プロセス２１０／２６０は、現在受け取ったパケットの受け取ったＩＰ−ＩＤを、以前に受け取ったパケットの記憶されたＩＰ−ＩＤと比較する。ブロック６３５において、ヘッダ変更プロセス２１０／２６０は、ＩＰ−ＩＤがランダムであるかどうか決定する。現在ＩＰ−ＩＤと、その前の（直前の）ＩＰ−ＩＤとの比較が、ある数の差以外の何かである場合には、ＩＰ−ＩＤがランダムであると仮定される。又、ブロック６３５は、このフローがランダムなＩＰ−ＩＤを使用するか又は順次のＩＰ−ＩＤを使用するか指示するためにフラグ２１４を調整する。ＩＰ−ＩＤがランダムでない場合には（ブロック６３５＝ノー）（即ち、順次である）、ヘッダ変更プロセス２１０／２６０は、受け取った非変更のパケット２０５／２５５をＲＯＨＣ圧縮器２２０／２４０へ送出する。
【００４８】
ＩＰ−ＩＤがランダムであると決定される場合には（ブロック６３５＝イエス）、ブロック６４０において、ヘッダ変更プロセス２１０／２６０は、新たな順次のＩＰ−ＩＤをＩＰパケット２０５／２５５に指定し（ＰＤＣＰ  ＩＰフローテーブル２３４／２８４が更新されて、例えば、フラグ２１４により、所与のＩＰフローがランダムなＩＰ−ＩＤを使用することを示すことに注意されたい）、そしてブロック６４５において、ヘッダ変更プロセス２１０／２６０は、チェック和がディスエイブルされない場合には新たなチェック和を計算する。フラグ２１４が使用される場合に、フローがランダムな又は順次のＩＰ−ＩＤを使用すると決定されると、ブロック６３０及び６３５は、受け取って記憶したＩＰ−ＩＤを比較するのではなく、フラグ２１４をテストすることに注意されたい。ブロック６４０及び６４５は、ヘッダが変更されたパケット２１１／２６１を生成する。チェック和に関して、ＵＤＰチェック和は、そのチェック和がゼロにセットされない場合には、ブロック６４５において、再計算しなければならない。ＵＤＰチェック和は、そのチェック和の値がゼロでない場合には（ゼロは、ＵＤＰチェック和がディスエイブルされることを示す）、イネーブルされる。しかしながら、ＩＰチェック和は、ブロック６４５に対して計算されねばならない。ブロック６４５に示す別の選択肢は、ＵＤＰチェック和をディスエイブルすることであり、これは、ＵＤＰチェック和がイネーブルされた場合に対して付加的な圧縮を許さねばならない。
【００４９】
ブロック６５０において、ヘッダが変更されたパケット２１１／２６１は、ＲＯＨＣ圧縮器２２０／２４へ送出される。ＲＯＨＣ圧縮器２２０／２４０は、圧縮されたパケット２２１／２４１を下位レイヤへ転送し、そしてそれに対応する装置（例えば、ＭＮ１１０又はｅＮＢ１３６）は、リンク１２９を使用してパケットを送信する。ブロック６５０の後に、この方法は、ブロック６０５へ続く。
【００５０】
図７は、アップリンクにおいてｅＮＢ１３６により遂行されて、パケットセッションの端−端信頼性を改善し且つ移動ノードセキュリティを改善する方法のフローチャートである。それ故、ブロック７０５において、ヘッダ変更プロセス２６０は、ＭＮ１１０からパケットを受け取る(例えば、ＲＯＨＣ解凍器２５０から非圧縮のパケット２５１を受け取る)。
【００５１】
ブロック７１０の前に、例えば、ＰＤＣＰレイヤにより、付加的な処理が行われることに注意されたい。例えば、ＰＤＣＰレイヤは、ＲＯＨＣ解凍器２５０により送られたパケット２５１を受け取り、次いで、その受け取ったパケット２５１を、ＳＲＣ（ソース)ＩＰアドレス、ＤＥＳＴ（行先)ＩＰアドレス、ＳＲＣポート及びＤＥＳＴポート、プロトコルタイプ、等に基づいて分類する。或いは又、ＰＤＣＰレイヤは、ＬＴＥ特有の情報を分類目的で使用することもできる。例えば、ＬＴＥでは、ＲＴＰ／ＵＤＰ／ＩＰパケットは、ＱＣＩ  １専用ベアラに関連され、それ故、ｅＮｏｄｅＢ１３６（例えば）も、ＰＤＣＰフローに関連した論理的チャンネルを分類目的で使用することができる。
【００５２】
ブロック７１０において、ヘッダ変更プロセス２６０は、受け取ったＩＰパケット２５１がＩＰ断片であるかどうか決定する。ヘッダ変更プロセス２６０は、ＩＰｖ４ヘッダのＭＦフラグ及び断片オフセットの組み合わせを監視することによりパケットが断片化されたかどうか識別することができる。受け取ったＩＰパケット２５１がＩＰ断片である場合には（ブロック７１０＝イエス）、ヘッダ変更プロセス２６０は、ブロック７５０において、パケットを不変のまま（例えば、パケット２５１として）コアネットワークへ送り出す。
【００５３】
受け取ったＩＰパケット２５１がＩＰ断片でない場合には（ブロック７１０＝ノー）、ヘッダ変更プロセス２６０は、ブロック７１５において、受け取ったＩＰパケット２５１が新たなフローの一部分であるかどうか決定する。もしそうであれば（ブロック７１５＝イエス）、ヘッダ変更プロセス２６０は、ＰＤＣＰ  ＩＰフローテーブル２８４における新たなフローとしてコンテキスト２１３（及びおそらくは対応フローＩＤ２１２）を生成する（ブロック７２０）。もしそうでなければ（ブロック７１５＝ノー）、ヘッダ変更プロセス２６０は、ＩＰヘッダ（例えば、ヘッダ４００の一部分）からＩＰ−ＩＤを抽出し、そしてそのＩＰ−ＩＤをＰＤＣＰ  ＩＰフローテーブル２８４に記憶する（ブロック７２５）。
【００５４】
ブロック７３０において、ヘッダ変更プロセス２６０は、受け取ったＩＰ−ＩＤを、そのフローに対して以前に受け取ったパケットの記憶されたＩＰ−ＩＤと比較する。ブロック７３５において、ヘッダ変更プロセス２６０は、ＩＰ−ＩＤがランダムであるかどうか決定する。又、ブロック７３５は、対応するフローがランダムなＩＰ−ＩＤを使用するか又は順次のＩＰ−ＩＤを使用するか指示するためにフラグ２１４を調整する。ＩＰ−ＩＤがランダムである場合には（ブロック７３５＝イエス）、ヘッダ変更プロセス２６０は、非変更の受け取ったパケット２５１をコアネットワークへ送り出す。
【００５５】
ＩＰ−ＩＤがランダムでないと決定された場合には（ブロック７３５＝イエス）、ブロック７４０において、ヘッダ変更プロセス２６０は、新たなランダムなＩＰ−ＩＤをＩＰパケット２５１に指定し、そしてブロック７４５において、ヘッダ変更プロセス２６０は、必要に応じて新たなチェック和を計算し（及び元のチェック和がもしあれば置き換え）、そしてＵＤＰチェック和をイネーブルする（例えば、対応するフィールドに非ゼロのＵＤＰチェック和を入れることにより）。ブロック７４０及び７４５は、ヘッダが変更されたパケット２７１を生成する。ブロック７５０において、ヘッダが変更されたパケット２７１は、コアネットワークへ送られる。ブロック７５０の後に、この方法は、ブロック７０５へ続く。
【００５６】
図８は、ダウンリンクにおいてｅＮＢにより遂行されて、ヘッダ圧縮効率を改善するための別の方法のフローチャートである。この例では、ヘッダ４００のＩＰ−ＩＤ以外のエントリが検査されて変更される。ブロック８０５において、ＩＰパケット２５５が、対応ノード１４３から受け取られる。上述したように、ブロック８１０の前に、例えば、ＰＤＣＰレイヤにより、付加的な処理が行われることに注意されたい。
【００５７】
ブロック８１０において、ヘッダ変更プロセス２６０は、フローが新たなフローであるかどうか決定する。もしそうであれば（ブロック８１０＝イエス）、ヘッダ変更プロセス２６０は、ＰＤＣＰ  ＩＰフローテーブル２８４における新たなフローとしてコンテキスト２１３（及びおそらくフローＩＤ２１２）を生成する（ブロック８２０）。コンテキスト２１３は、ＩＰｖ４又はＩＰｖ６フローに関連した情報を含む。ＩＰｖ６コンテキストは、ＩＰｖ６  ＴｏＳ及びホップリミットを含み、そしてＩＰｖ４コンテキストは、ＩＰ−ＩＤ、ＩＰｖ４  ＴＴＬ及びＩＰｖ４  ＴＯＳ、等を含む。各コンテキスト２１３は、標準的なＩＰｖ４又はＩＰｖ６分類子で識別される。フローが新たなフローでないか（ブロック８１０＝ノー）又はブロック８２０が遂行された場合には、ブロック８１５において、ヘッダ変更プロセス２６０は、フローがＩＰｖ４フローであるかどうか決定する。これは、ＩＰヘッダのバージョンフィールドを使用して遂行される。パケットがＩＰｖ６パケットであることをバージョンが示す場合には（ブロック８１５＝ノー）、この方法は、ブロック８４５へ進む。フローがＩＰｖ４フローである場合には（ブロック８１５＝イエス）、この方法は、ブロック８１６へ進む。
【００５８】
ブロック８１６において、ヘッダ変更プロセス２６０は、受け取ったＩＰパケット２５５がＩＰ断片であるかどうか決定する。ヘッダ変更プロセス２６０は、上述した技術によりパケットが断片化されたかどうか識別する。受け取ったＩＰパケット２５５がＩＰ断片である場合には（ブロック８１６＝イエス）、ヘッダ変更プロセス２６０は、ブロック８６５において、パケットをＲＯＨＣ圧縮器２４０へ不変のまま（例えば、パケット２５５として）送出する。受け取ったＩＰパケット２５５がＩＰ断片でない場合には（ブロック８１６＝ノー）、ヘッダ変更プロセス２６０は、ＩＰヘッダ（例えば、ヘッダ４００の一部分）からＩＰ−ＩＤを抽出し、そしてそのＩＰ−ＩＤをＰＤＣＰ  ＩＰフローテーブル２８４に記憶する（ブロック８２５）。ブロック８３０において、ヘッダ変更プロセス２６０は、受け取ったＩＰ−ＩＤを、以前のパケットの記憶されたＩＰ−ＩＤと比較する。ブロック８３５において、ヘッダ変更プロセス２６０は、ＩＰ−ＩＤがランダムであるかどうか決定する。又、ブロック８３５は、フラグ２１４のための適当な値もセットする。ＩＰ−ＩＤがランダムであると決定された場合には（ブロック８３５＝イエス）、ブロック８４０において、ヘッダ変更プロセス２６０は、新たな順次ＩＰ−ＩＤをＩＰパケット２５５に指定する。ＩＰ−ＩＤがランダムではない場合には（ブロック８３５＝ノー）、ブロック８４５が遂行される。ブロック８４５において、フローのタイプに基づき、ヘッダ変更プロセス２６０は、次の情報の幾つか、即ちＩＰｖ６  ＴｏＳ、ＩＰｖ６ホップリミット、ＩＰｖ４  ＴｏＳ、及び／又はＩＰｖ４  ＴＴＬを抽出する。ＩＰｖ６  ＴｏＳ及びＩＰｖ６ホップリミットは、ＩＰｖ６ヘッダの一部分であり、一方、ＩＰｖ４  ＴｏＳ及びＩＰｖ４  ＴＴＬは、ＩＰｖ４ヘッダの一部分である。ブロック８４５は、フローがＩＰｖ４であるかＩＰｖ６であるか決定するために別のチェックを含んでもよい。これは、ＩＰヘッダのバージョンフィールドを使用して遂行される。パケットがＩＰｖ４パケットであることをバージョンフィールドが示す場合には、ＩＰｖ４  ＴｏＳ及びＩＰｖ４ＴＴＬが処理され、さもなければ、ＩＰｖ６  ＴｏＳ及びＩＰｖ６ホップリミットが処理される。
【００５９】
ブロック８５０において、ヘッダ変更プロセス２６０は、例えば、直前のパケット以来、又はＰＤＣＰ  ＩＰフローテーブル２８４（例えば、コンテキスト２１３）の記憶値に基づき、これらフィールドのいずれかが変化したかどうか決定する（例えば、ＰＤＣＰ  ＩＰフローテーブル２８４を使用して）。これらフィールドがどれも変化していない場合には（ブロック８５０＝ノー）、この方法は、ブロック８６０へ進む。１つ以上のフィールドが変化した場合には（ブロック８５０＝イエス）、ブロック８５５において、ヘッダ変更プロセス２６０は、変化した値を、ＰＤＣＰ  ＩＰフローテーブル２８４のコンテキストからの元の値と置き換える。
【００６０】
ブロック８６０において、ヘッダ変更プロセス２６０は、チェック和がディスエイブルされない場合には、新たなチェック和を計算する（そして例えば、元のチェック和を計算されたチェック和に置き換える）。ブロック８４０−８６０は、ヘッダが変更されたパケット２６１を生成する。ブロック８６５において、ヘッダが変更されたパケット２６１は、ＲＯＨＣ圧縮器２４０へ送られ、この圧縮器は、パケットを圧縮パケット２４１として下位レイヤへ転送し、リンク１２９を経てＭＮ１１０へ伝送する。ブロック８６５の後に、この方法は、ブロック８０５へ続く。
【００６１】
図９を参照すれば、図９は、リレーノードを使用する規範的なシステムを示す。ここに示す技術は、そのようなシステムにも使用できる。この図は、ＤｅＮＢ（ドナーｅＮＢ）を経てプロキシーＳ１（及びＸ２）を有するＬＴＥ−Ａリレーアーキテクチャーを示す。ＭＭＥ及び隣接ｅＮＢからは、ＵＥがＤｅＮＢに接続されたかのように見える。ＲＡＮからは、ＲＡＮが、Ｓ１−ＣについてはＭＭＥと話をし、Ｘ２については隣接ｅＮＢと話をし、そしてＳ１−ＵについてはＳ−ＧＷと話をするかのように見える。インターフェイスＳ１及びＸ２は、ＤｅＮＢ（プロキシーファンクション）によりＲＮへ転送される。ＤｅＮＢとＲＮとの間のＵｎインターフェイスは、標準化され、このインターフェイスは、ＵｕからのＭＡＣ／ＲＬＣ／ＰＤＣＰ／ＲＲＣを再使用する。規範的な実施形態では、リレーノードのＰＤＣＰレイヤ（「リレー／ｅＮＢ」として示された）は、ここに示す規範的実施形態を具現化することができる。
【００６２】
従って、少なくとも一部分は上述したが、次のような規範的な実施形態が開示された。規範的な実施形態において、ワイヤレスリンクの効率を改善し且つワイヤレス装置のセキュリティを向上させるためにＰＤＣＰを最適化する方法が開示される。規範的な実施形態において、受け取ったパケットのＩＰ−ＩＤがランダムであり且つ受け取ったＩＰパケットがＩＰ断片の一部分ではないことに応答して、ＰＤＣＰレイヤ（例えば、ヘッダ変更プロセス２１０／２６０のようなプロセス）は、ランダムなＩＰ−ＩＤを順次のＩＰ−ＩＤに置き換え、そして上位レイヤのチェック和がディスエイブルされない場合にはＲＯＨＣを使用してヘッダを圧縮する前にそのようなチェック和を再計算する。付加的な規範的な実施形態において、付加的な圧縮効率利得を更に得るために、ＰＤＣＰレイヤは、ＩＰ−ＩＤがランダムなＩＰ−ＩＤから順次のＩＰ−ＩＤへ変換されるや否やＵＤＰチェック和をディスエイブルすることを決定する。
【００６３】
別の規範的な実施形態において、ＲＴＰ／ＵＤＰ／ＩＰパケットが別のＩＰｖ４パケット内でトンネル化された場合には、ＰＤＣＰレイヤは、ＲＯＨＣを使用してヘッダを圧縮する前に内側及び外側の両ＩＰｖ４ヘッダのランダムなＩＰ−ＩＤを順次へ変化させる。更に別の規範的な実施形態において、移動ノード１１０のセキュリティを改善するため、ｅＮｏｄｅＢ１３６は、アップリンクパケットをコアネットワークへ送信する前にアップリンクパケットの順次のＩＰ−ＩＤをランダムなＩＰ−ＩＤへ変化させる。ＩＰ−ＩＤを変化させた後に、ｅＮｏｄｅＢは、ＵＤＰ／ＴＣＰチェック和の再計算も行う。ＶｏＩＰセッションの端−端信頼性を更に向上させるため、更に別の規範的な実施形態では、ｅＮｏｄｅＢ１３６は、ＩＰ−ＩＤを順次からランダムへ変化させた後にＵＤＰチェック和をイネーブルし、ＲＴＰ／ＵＤＰ／ＩＰパケットがコアネットワークを経て対応ノード１４３へルーティングされる間にそれらパケットが付加的な内蔵エラー検出メカニズムをもつようにする。
【００６４】
以上の例は、例えば、ＬＴＥ  ＰＤＣＰレイヤに適用されてもよいし、又は３Ｇ／４Ｇ／４Ｇ＋（第３世代、第４世代、第４以降の世代）のワイヤレスアクセスネットワークに適用することもできる。例えば、上述した実施形態は、ＵＭＴＳ（ユニバーサル移動テレコミュニケーションズシステム）／ＨＳＰＡ（高速パケットアクセス）／ＣＤＭＡ（コード分割多重アクセス）及び／又はＷＩＭＡＸに適用することができる。ＵＭＴＳ／ＨＳＰＡでは、ＲＯＨＣは、ＲＮＣ及びＭＮ  ＰＤＣＰレイヤにより具現化される。ＣＤＭＡでは、ＲＯＨＣは、ＯＤＳＮ（パケットデータサービングノード）及びＭＮ  ＰＰＰ（ポイント・ツー・ポイントプロトコル）レイヤにより具現化される。ＷＩＭＡＸでは、ＲＯＨＣは、ＡＳＮ−ＧＷ（アクセスサービスネットワーク・ゲートウェイ）（又はＢＴＳ  ＭＡＣ、ベーストランシーバステーションメディアアクセスコントロール）レイヤ及びＭＮＭＡＣレイヤにおいて具現化される。
【００６５】
これらの教示の技術的な効果は、パケットヘッダの改善された圧縮を可能にすることである。更に別の技術的な作用は、移動ノードのセキュリティを更に向上させながら圧縮を遂行できることである。
【００６６】
本発明の実施形態は、ソフトウェア（１つ以上のプロセッサにより実行される）、ハードウェア（例えば、特定用途向け集積回路）、又はソフトウェア及びハードウェアの組み合わせで具現化される。規範的な実施形態において、ソフトウェア（例えば、アプリケーションロジック、インストラクションセット）は、種々の従来のコンピュータ読み取り可能な媒体のいずれかに維持される。本書の文脈において、「コンピュータ読み取り可能な媒体」とは、コンピュータのようなインストラクション実行システム、装置又はデバイスに関連して又はそれにより使用するためにインストラクションを収容し、記憶し、通信し、伝播し又は搬送することのできる媒体又は手段であり、コンピュータの一例は、図１に示して説明した。コンピュータ読み取り可能な媒体は、コンピュータのようなインストラクション実行システム、装置又はデバイスに関連して又はそれにより使用するためにインストラクションを収容し又は記憶することのできる媒体又は手段であるコンピュータ読み取り可能な記憶媒体（例えば、メモリ１２５、１５５又は他のデバイス）を含む。
【００６７】
要望があれば、ここに述べた異なる機能は、互いに異なる順序で及び／又は同時に遂行することもできる。更に、要望があれば、上述した機能の１つ以上は、任意なものでもよいし、又は組み合わせてもよい。
【００６８】
本発明の種々の態様を独立請求項に述べるが、本発明の他の態様は、請求項に明確に述べる組み合わせだけでなく、ここに述べる実施形態、及び／又は独立請求項の特徴をもつ従属請求項からの特徴の他の組み合わせも包含する。
【００６９】
又、本発明の規範的な実施形態を上述したが、本発明は、それらの説明に限定されないことに注意されたい。むしろ、特許請求の範囲に規定された本発明の範囲から逸脱せずに多数の変更や修正がなされ得る。
【符号の説明】
【００７０】
１００：ネットワーク
１１０：移動ノード
１２０：プロセッサ
１２３：コンピュータプログラムコード
１２５：メモリ
１２７：バス
１２８：アンテナ
１２９：ワイヤレスリンク
１３０：トランシーバ
１３１：アプリケーション
１３６：ＮｏｄｅＢ（ｅＮＢ）
１４０：インターネット
１４３：対応ノード
１５０：プロセッサ
１５１：サービングゲートウェイ（ＳＧＷ）
１５３：コンピュータプログラムコード
１５５：メモリ
１５７：バス
１５８：アンテナ
１６０：トランシーバ
１６１：ネットワークインターフェイス（Ｎ／Ｗ  Ｉ／Ｆ）
１８０：プロセッサ
１８７：バス
１９０：ネットワークインターフェイス（Ｎ／Ｗ  Ｉ／Ｆ）
１９１：移動管理エンティティ（ＭＭＥ）
１９４：パケットデータネットワーク（ＰＤＮ）ゲートウェイＧＷ）
１９５：メモリ
１９７：コンピュータプログラムコード
２０５：ＩＰパケット
２１０：ヘッダ変更プロセス
２１１：ヘッダを変更したパケット
２２０：ＲＯＣＨ圧縮器
２２１：圧縮パケット
２３０：ＲＯＨＣ解凍器
２３１：非圧縮パケット
２３４：ＩＰフローテーブル
２４０：ＲＯＨＣ圧縮器
２４１：圧縮パケット
２５０：ＲＯＨＣ解凍器
２５１：非圧縮パケット
２５５：ＩＰパケット
２６０：ヘッダ変更プロセス
２６１：ヘッダを変更したパケット
２７１：ヘッダを変更したパケット
２８４：ＩＰフローテーブル
４００−１、４００−２：パケットヘッダ
【図１】
2015506151.tif 000003
【図２】
2015506151.tif 000004
【図３Ａ】
2015506151.tif 000005
【図３Ｂ】
2015506151.tif 000006
【図４】
2015506151.tif 000007
【図５】
2015506151.tif 000008
【図６】
2015506151.tif 000009
【図７】
2015506151.tif 000010
【図８Ａ】
2015506151.tif 000011
【図８Ｂ】
2015506151.tif 000012
【図９】
2015506151.tif 000013
【国際調査報告】
2015506151.tif 000014
2015506151.tif 000015
2015506151.tif 000016
2015506151.tif 000017
2015506151.tif 000018