(57)【要約】本発明は、受信したパケットを破棄しないようにし、ＲＯＨＣ仕様を修正しないでも無線リソースを節約するために、定常状態に留まることができるよりコンパクトなフォーマットを使用するために、データ・パケット・ストリームのＩＰヘッダに適用されるＲＯＨＣ  ＲＴＰ（ロバスト・ヘッダ圧縮リアルタイム・プロトコル）圧縮を最適化するための方法に関する。この方法の場合、ハンドオーバまたはモビリティ手順が開始されると、新しい基準値は、通常、スライディング圧縮ウインドウに追加されるが、ハンドオーバまたはモビリティ手順が行われている限り、基準値はウインドウから除去されない。ハンドオーバまたはモビリティ手順が完了した後で、新しい無線リンクにより送信された値の数が、新しいリンク上の誤り特性を適切に処理することができる場合には、すべての古い値を圧縮ウインドウから一度に除去することができ、それにより正常なウインドウ動作に復帰することができる。【選択図】図２
2009512231.tif 000002
【特許請求の範囲】
【請求項１】
セルラー通信ネットワーク内のセル上に位置する第１の移動端末とインターネットに接続している第２の端末との間で交換されるデータ・パケット・ストリームのＩＰヘッダに適用されるＲＯＨＣ  ＲＴＰ（ロバスト・ヘッダ圧縮リアルタイム・プロトコル）を最適化するための方法であって、
ＩＰヘッダ・フィールドを符号化するステップと、
前記第１の移動端末と前記第２の端末との間で、圧縮のために前記第１の移動端末（それぞれ前記第２の端末）が使用し、圧縮解除のために前記第２の端末（それぞれ前記第１の端末）が使用する少なくとも１つの基準値を備える圧縮ウインドウを交換するステップとを含み、前記方法が、
ハンドオーバまたはモビリティ手順が開始された場合に、前記ハンドオーバまたはモビリティ手順が進行中である限りは、前記ウインドウから前の基準値を除去しないで、以降の圧縮解除のために圧縮ウインドウに、少なくとも１つの新しい基準値を追加するステップと、
ハンドオーバまたはモビリティ手順が完了した後で、前記圧縮ウインドウから一度にすべての前の値を除去するステップと、
をさらに含むことを特徴とする方法。
【請求項２】
前記ヘッダ圧縮が、ウインドウ・ベースの最下位ビット符号化（Ｗ−ＬＳＢ）を使用する、請求項１に記載の方法。
【請求項３】
前記Ｗ−ＬＳＢ符号化ヘッダ・フィールドが、ＲＴＰタイムスタンプ（リアルタイム・プロトコル・タイムスタンプ）である、請求項２に記載の方法。
【請求項４】
前記Ｗ−ＬＳＢ符号化ヘッダ・フィールドが、ＲＴＰシーケンス番号（リアルタイム・プロトコル・シーケンス番号）である、請求項２に記載の方法。
【請求項５】
セルラー通信ネットワーク内のセル上に位置し、前記セルラー通信ネットワーク内の第２の端末とデータ・パケット・ストリームを交換する移動端末であって、前記移動端末が、圧縮装置および圧縮解除装置と、前記ＩＰヘッダ・フィールドを符号化するための手段と、第１の移動端末と第２の端末との間で、圧縮のために前記第１の移動端末が使用し、圧縮解除のために前記第２の端末が使用する少なくとも１つの基準値を備える圧縮ウインドウを交換するための手段とを備え、
前記移動端末が、
ハンドオーバまたはモビリティ手順が開始された場合に、ハンドオーバまたはモビリティ手順が進行中である限りは、前記ウインドウから前記前の基準値を除去しないで、以降の圧縮解除のために前記圧縮ウインドウに少なくとも１つの新しい基準値を追加するための手段と、
ハンドオーバまたはモビリティ手順が完了した後で、前記圧縮ウインドウからすべての前の値を一度に除去するための手段と、
をさらに含むことを特徴とする移動端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電気通信分野に関し、セルラー通信ネットワーク内のあるセル上に位置する第１の移動端末とインターネットに接続している第２の端末との間で交換するデータ・パケット・ストリームのＩＰ（インターネット・プロトコル）ヘッダ圧縮を最適化するための方法に関する。
【０００２】
この方法は、ＩＰヘッダ・フィールドを符号化するステップと、第１の移動端末と第２の端末との間で、圧縮のために第１の移動端末（それぞれ第２の端末）が使用し、圧縮解除のために第２の端末（それぞれ第１の端末）が使用する少なくとも１つの基準値を備える圧縮ウインドウを交換するステップとを含む。
【０００３】
第２の端末は、移動端末であってもよいし、またはセルラー通信ネットワークの特定のノードであってもよい。
【０００４】
本発明は、また、この方法を実施することができる移動端末に関する。
【背景技術】
【０００５】
今日、ＩＰ電話は、改善した技術的解決方法のお蔭で普及しつつある。今後、ＩＰは電話を携帯する一般的な方法になるだろう。ある種の未来のセルラー電話のリンクも、ＩＰおよびＩＰ電話をベースとすることができる。セルラーホンは、音声および映像ばかりでなく、ウェブ閲覧、電子メール、ゲーム等をサポートするＩＰスタックを有することができる。
【０００６】
対話型音声会話に使用した場合のセルラー・リンクを通してのＩＰに関する問題は、大きなヘッダ・オーバヘッドである。ＩＰ電話の音声データは、ＲＴＰ（リアルタイム・プロトコル）により送られる可能性が非常に高い。その場合、パケットは、リンク層フレーミングの他に、ＩＰｖ４ヘッダ（２０オクテット）、ＵＤＰ（ユーザ・データグラム・プロトコル）ヘッダ（８オクテット）、およびＲＴＰ（リアルタイム・プロトコル）ヘッダ（１２オクテット）を有し、全部で４０オクテットを有する。ＩＰｖ６の場合には、ＩＰヘッダは４０オクテットであり、全部で６０オクテットになる。ペイロードのサイズは、音声符号化、および使用するフレーム・サイズにより異なり、１５〜２０オクテット程度少なくなる場合がある。
【０００７】
ロバスト・ヘッダ圧縮（ＲＯＨＣ）は、通常、高い誤り率および大きな伝送遅延を起こすセルラー・リンク上で使用するために、ＩＰＨＣ（ＩＰヘッダ圧縮）の制限および３ＧＰＰのＲＦＣ２５０７仕様を克服するために生成されたものである。ＲＯＨＣは、このリンクを通して送信されたヘッダの圧縮解除を確実に成功させるために、ヘッダ圧縮を行っている間に、伝送リンクの誤り率を考慮に入れることができるようにするためのものである。これが、ＲＯＨＣが無線リンク上で使用することができるようになっている理由である。
【０００８】
しかし、ＵＭＴＳ（ユニバーサル移動体通信システム）内のＲＮＣ内（無線ネットワーク制御装置）ハード・ハンドオーバおよびＲＮＣ間ハード・ハンドオーバ（ハード・ハンドオーバとコンテキストの再配置を含むＳＮＲＳ再配置が結合したもの）などのセルラー通信ネットワーク内のハンドオーバ手順中、連続パケットの非常に大きいシーケンスが失われる恐れがあり、それにより、圧縮解除の失敗、パケットの喪失、長いヘッダ（ＩＲ−ＤＹＮフォーマット、１５バイト）を使用する圧縮コンテキストの部分的再初期化を起こす恐れがあり、そのため圧縮効率が劣化することになる。
【０００９】
それ故、ハンドオーバ手順中の上記問題を解決するために、ヘッダ圧縮スキームの性能を強化することが望ましい。
【００１０】
このような性能は、３つのパラメータ、すなわち、圧縮効率、ロバスト性、圧縮の透明性により説明することができる。ロバスト・スキームを使用すれば、追加のパケットを喪失することなしに、または圧縮解除ヘッダ内に追加の誤りを導入することなしに、ヘッダ圧縮が行われるリンク上の喪失および残留誤りがあっても大丈夫になる。
【００１１】
図１は、圧縮に対するＲＯＨＣの主要な原理の１つが、Ｗ−ＬＳＢ（ウインドウ・ベースの最下位ビット）符号化である場合を示す。
【００１２】
値ｖがｋ個のビット上の符号化された値である場合には、ＬＳＢ（最下位ビット）符号化値ｅは、０から２ｋ−１の範囲内にあり、「ｅ」は、２ｋによるｖの整数除算の余りであり、ｅ＝ｙ［２ｋ］で表すこともできる。
【００１３】
圧縮解除装置が、ｅからｖを決定するために、（符号化されてもいないし、圧縮解除されてもいない以前に受信した）基準値ｖｒｅｆを使用する場合には、圧縮解除装置は、ｅ＝ｙ［２ｋ］になるように、間隔ｆ（ｖｒｅｆ，ｋ）内の値ｖだけをピックアップする。この値は一意である。何故なら、間隔のサイズが２ｋであるからである。
【００１４】
圧縮解除装置が十分大きなｋを選択した場合には、一組の基準値ｖｉが存在し、そのため、値ｖは各ｖ１に対する間隔ｆ（ｖｉ，ｋ）内に位置し、すなわち、ｖは、これらの間隔の交点内に位置し、ｖｉ値のうちのいずれか１つが基準として使用され、一意の値ｖが存在し、そのためｅ＝ｙ［２ｋ］となる。
【００１５】
図１は、３つの基準値ｖ１、ｖ２、ｖ３を含む一例を示す。
【００１６】
ＵモードおよびＯモード（楽観モード）の場合のＲＯＨＣ圧縮装置の通常の挙動は、各値に対して、基準としてｎ個の以前に送信した値を使用して、ｋ個の十分大きなものを選択することである。従って０から２ｋ−１の間のこの値の圧縮解除結果は、元の値になる。一組の「ｎ」個の以前に送信した値は、通常、「ウインドウ」と呼ばれ、ｎは「最大ウインドウ幅」と呼ばれる。ｎは、パケットを喪失するおよび／または不正パケットを受信する確率により選択されるので、ｎ個の連続基準値を喪失する確率は十分低い。
【００１７】
伝送リンク特性による起こり得る喪失または誤りをうまく処理するために、圧縮装置のウインドウ内に十分な数の基準値を保持することにより適切なロバスト性が得られる。
【００１８】
３ＧＰＰのＲＦＣ３０９５に記載されているヘッダ圧縮技術の場合には、圧縮装置および圧縮解除装置が、それぞれ、元の値が常駐し、元の値だけが、送信されたものと正確に同じｋ個の最下位ビットを有する値である、解釈間隔を使用している場合には、スキームの正しいことが保証される。
【００１９】
解釈間隔は、下記の関数ｆ（ｖ＿ｒｅｆ，ｋ）として記述される。
【００２０】
ｆ（ｖ＿ｒｅｆ，ｋ）＝［ｖ＿ｒｅｆ−ｐ，ｖ＿ｒｅｆ＋（２ｋ−１）−ｐ］
ここで、ｐは整数である。
【００２１】
関数ｆは下記の特性を有する。任意の値ｋに対して、ｋ個の最下位ビットは、ｆ（ｖ＿ｒｅｆ，ｋ）内の値を一意に識別する。
【００２２】
パラメータｐは、ｖ＿ｒｅｆに対して解釈間隔をシフトすることができるように導入される。ｐに対してよい値を選択すれば、ｐはいくつかの特性を有するフィールドに対してより効率的な符号化を行うことができる。
【００２３】
値ｖを圧縮している場合には、圧縮装置は、ｖが間隔ｆ（ｖ＿ｒｅｆ−ｃ，ｋ）内に入るようなｋの最小値を発見する。この関数を、ｋ＝ｇ（ｖ＿ｒｅｆ＿ｃ，ｖ）と呼ぶ。
【００２４】
例えば、パケット・フォーマットにより課せられている制限のためにｋのいくつかの離れた値だけしか使用できない場合には、圧縮装置は、代わりに間隔ｆ（ｖ＿ｒｅｆ−ｃ，ｋ）内にｖを入れる最小のｋをピックアップする。
【００２５】
ＬＳＢを受信している場合には、圧縮解除装置は、間隔＿ｄと呼ぶ解釈間隔ｆ（ｖ＿ｒｅｆ−ｄ，ｍ）を使用する。圧縮解除装置は、圧縮解除値としてそのＬＳＢが受信したｍ個のビットと一致する間隔＿ｄ内の１つをピックアップする。
【００２６】
圧縮装置は、特定の値ｖに対して圧縮解除装置が使用するｖ＿ｒｅｆ＿ｄの正確な値を決定することができない場合がある。何故なら、ｖ＿ｒｅｆ＿ｄに対するいくつかの候補が喪失しているか、または損傷している場合があるからである。しかし、フィードバックを使用することにより、または妥当な仮定を行うことにより、圧縮装置は、一組の候補内のどのｖ＿ｒｅｆ＿ｄを圧縮解除装置が使用しても、ｖは結果として得られる間隔＿ｄによりカバーされるようにｋ個の候補を計算する。
【００２７】
圧縮解除装置は、いつでも基準としてＣＲＣ（巡回冗長検査）が後に続く最後に受信した値を使用するので、圧縮装置は、ｖ＿ｒｅｆ＿ｄに対する候補を含むスライディング・ウインドウを維持する。
【００２８】
このスライディング・ウインドウは、最初空である。圧縮装置によりスライディング・ウインドウ上で下記の動作が行われる。
【００２９】
・ＣＲＣにより保護されている（圧縮されたまたは圧縮されていない）値ｖを送信した後で、圧縮装置は、スライディング・ウインドウにｖを追加する。
【００３０】
・圧縮中の各値ｖに対して、圧縮装置は、ｋ＝ｍａｘ（ｇ（ｖ＿ｍｉｎ，ｖ），ｇ（ｖ＿ｍａｘ，ｖ）を選択する。ここで、ｖ＿ｍｉｎおよびｖ＿ｍａｘはスライディング・ウインドウ内の最小値および最大値であり、ｇは上記関数である。
【００３１】
・圧縮装置が、ある値ｖおよびｖより古いすべての値を、圧縮解除装置が基準として使用しないことを十分に確信している場合には、ウインドウは、これらの値（ｖを含む）を除去することにより前進する。
【００３２】
この自信は種々の手段により入手することができる。
【００３３】
Ｒモード（双方向信頼モード）の場合には、圧縮解除装置からのＡＣＫ（肯定応答）信号は、肯定応答したものより古い値をスライディング・ウインドウから除去することができることを意味する。
【００３４】
Ｕ／Ｏモード（一方向／楽観モード）の場合には、圧縮解除が正しいことを確認するためにＣＲＣがいつでも存在し、限定された最大幅を有するスライディング・ウインドウが使用される。
【００３５】
ウインドウ幅は、最適化パラメータに依存する実施である。
【００３６】
圧縮解除装置は、後続のＣＲＣと一緒に受信した各ヘッダに肯定応答しなければならないＲモードの場合を除いて、前節に記載した手順に従う。
【００３７】
すでに説明したように、従来のＲＯＨＣ動作の場合には、新しい値を送信した場合、その新しい値はウインドウに追加され、最も古い値がウインドウから除去される。システム間またはセルラー間ハンドオーバ手順が発生した場合、圧縮解除装置にとって困ったことになる場合がある。実際には、ハンドオーバ手順中、非常に多数の連続パケットが喪失するおそれがある。このような状況の場合には、同期が失われる恐れがあり、否定応答表示を圧縮装置に返送することになり、圧縮装置が初期化段階の第２のステップに戻るまですべての受信したパケットを破棄しなければならないことになる場合がある。それ故、将来、同期が失われるかも知れないし、すべての受信したパケットが破棄されるネガティブ・フィードバック表示の往復の遅延を避けるために、約１５バイトの長さのＩＲ−ＤＹＮフォーマットを使用して、自発的に初期化段階に戻るかも知れない。
【００３８】
ＲＯＨＣに対して現在行われている改良は、ＲＯＨＣ仕様では不可能な、Ｏモードでの「コンテキストを更新しない」ことを提案する３ＧＰＰ  ２５．３２３のような通常のＲＯＨＣ挙動とは互換性を持たない方法で挙動を変えることである。
【発明の開示】
【発明が解決しようとする課題】
【００３９】
本発明の１つの目的は、ハンドオーバ手順が発生した場合に、スライディング圧縮ウインドウを適合させることである。
【００４０】
本発明のもう１つの目的は、ハンドオーバ手順中圧縮を維持することである。
【００４１】
本発明のさらにもう１つの目的は、ハンドオーバの持続時間により可能な最小の圧縮フォーマットを使用することであり、３ＧＰＰにより現在指定されている大きなＩＲ−ＤＹＮパケット・フォーマットを使用しないことである。
【課題を解決するための手段】
【００４２】
本発明は、セルラー通信ネットワーク内のセル上に位置する第１の移動端末とセルラー通信ネットワーク内の特定のノードの第２の移動端末との間のセルラー・リンクを通して交換するＩＰパケット・ストリームのＩＰヘッダ・ファイルを圧縮するための技術を改善するためのものである。特定のノードは、例えば、ＵＭＴＳネットワークに対する無線ネットワーク制御装置ＲＮＣ、またはＧＳＭネットワークに対する（ＧＰＲＳにサービスを提供している）ＳＧＳＮである。
【００４３】
本発明によれば、ハンドオーバまたはモビリティ手順が開始されると、新しい基準値、すなわち、将来の圧縮解除のために圧縮解除装置がそれを使用するように、ヘッダ・フォーマットで送信される値が、通常、スライディング圧縮ウインドウに追加されるが、ハンドオーバまたはモビリティ手順が行われている限り、基準値は、ウインドウから除去されない。このことにより、ハンドオーバまたはモビリティ手順が進行している間に、ウインドウを恒久的に拡大する。
【００４４】
さらに、新しい無線リンクにより送信された、すなわちハンドオーバまたはモビリティ手順が完了した後で送信された値の数が、新しいリンク上の誤り特性を適切に処理することができる場合には、すべての古い値を圧縮ウインドウから一度に除去することができ、それにより正常なウインドウ動作に復帰することができる。
【００４５】
本発明の上記目的は、セルラー通信ネットワーク内のセル上に位置する第１の移動端末とインターネットに接続している第２の端末との間で交換するデータ・パケット・ストリームのＩＰヘッダに適用したＲＯＨＣ  ＲＴＰ（ロバスト・ヘッダ圧縮リアルタイム・プロトコル）圧縮を最適化するための方法により達成される。この方法は、ＩＰヘッダ・フィールドを符号化するステップと、第１の移動端末と第２の端末との間で、圧縮のために第１の移動端末（それぞれ第２の端末）が使用し、圧縮解除のために第２の端末（それぞれ第１の端末）が使用する少なくとも１つの基準値を有する圧縮ウインドウを交換するステップとを含み、この方法は、ハンドオーバおよびモビリティ手順が開始された場合に、ハンドオーバおよびモビリティ手順が進行中である限りは、ウインドウから前の基準値を除去しないで、以降の圧縮解除のために圧縮ウインドウに少なくとも１つの新しい基準値を追加するステップと、ハンドオーバおよびモビリティ手順が完了した後で、圧縮ウインドウからすべての前の値を除去するステップと、をさらに含むことを特徴とする。
【００４６】
本発明の好ましい実施形態によれば、ＲＯＨＣ  ＲＴＰ圧縮は、ウインドウ・ベースの最下位ビット符号化（Ｗ−ＬＳＢ）を使用する。
【００４７】
本発明の上記方法は、セルラー通信ネットワーク内のセル上に位置し、セルラー通信ネットワーク内の第２の端末とデータ・パケット・ストリームを交換する移動端末で実施される。移動端末は、圧縮装置および圧縮解除装置と、ＩＰヘッダ・フィールドを符号化するための手段と、第１の移動端末と第２の端末との間で、圧縮のために第１の移動端末が使用し、圧縮解除のために第２の端末が使用する少なくとも１つの基準値を有する圧縮ウインドウを交換する手段とを備える。
【００４８】
移動端末は、ハンドオーバおよびモビリティ手順が開始された場合に、ハンドオーバおよびモビリティ手順が進行中である限りは、ウインドウから前の基準値を除去しないで、以降の圧縮解除のために、圧縮ウインドウに少なくとも１つの新しい基準値を追加する手段と、ハンドオーバおよびモビリティ手順が完了した後で、圧縮ウインドウからすべての前の値を一度に除去する手段と、をさらに含むことを特徴とする。
【００４９】
それ故、本発明を使用すれば、ＵＯ−０の３バイトのハンドオーバ持続時間により、よりコンパクトなフォーマットを使用することができ、受信したパケットを破棄しないようにするために定常状態に留まることができる。また本発明を使用すれば、無線リソースを節約することができ、ＲＯＨＣ仕様を修正する必要もない。
【００５０】
さらに、ＲＡＮ２は、各ＲＯＨＣ段階のための２つのＲＡＢ定義を有し、両者の間で切り替えを行うためのＲＲＣ信号を使用すると仮定するＩＭＳを通しての音声のための最適化した無線アクセス・ベアラ（ＲＡＢ）を現在定義している。それ故、初期化段階に戻るのを避けることにより、ＲＲＣ信号を節約することもできる。
【発明を実施するための最良の形態】
【００５１】
以下の説明は、圧縮されるＩＰヘッダ値が、セルラー通信ネットワーク内のハンドオーバまたはモビリティ手順中に、第１のセルラー移動端末から第２のセルラー移動端末に送信したパケット・データ・ストリームのＲＴＰタイムスタンプ（リアルタイム・プロトコル・タイムスタンプ）またはＲＴＰシーケンス番号（リアルタイム・プロトコルシーケンス番号）である場合についてのものである。両方の移動端末は、本発明による最適化した方法を実施することができる圧縮装置および圧縮解除装置を含む。
【００５２】
圧縮装置のコンテキストは、圧縮装置がヘッダを圧縮するために使用する状態である。圧縮解除装置のコンテキストは、圧縮解除装置がヘッダを圧縮解除するために使用する状態である。これらのうちのどちらかまたは２つのＩ組合せは、通常「コンテキスト」と呼ばれる。コンテキストは、スタティック・フィールドおよび圧縮および圧縮解除のための可能な基準値のようなパケット・ストリーム内の前のヘッダからの関連情報を含む。さらに、例えば、ＩＰ識別子フィールドの変更方法、およびシーケンス番号またはタイムスタンプ内の典型的なパケット間増大に関する情報のようなパケット・ストリームを記述している追加情報もコンテキストの一部である。
【００５３】
Ｗ−ＬＳＢ（ウインドウ・ベースの最下位ビット）符号化されるＲＴＰ（リアルタイム・プロトコル）ヘッダ・フィールドのうちの１つに対する値のシーケンスを（ｘｎ）（ｎは、０と未定の大きな数の間である）と呼ぶことにしよう。符号化ウインドウは、ｋ個の値（ｗ１，．．．，ｗｋ）を含んでいるものとする。
【００５４】
ｇ（ｖｒｅｆ，ｘｎ）が基準値ｖｒｅｆによりｘ１を符号化するビットの最小数、すなわち、ｖｒｅｆを使用して元の値を正しく再構成するために必要なビットの最小数である場合には、符号化ウインドウ内のすべての基準値により、ｘ１を符号化するためのビットの最小数は、Ｍａｘ（ｋ＝０〜ｋ）ｇ（ｗ１，ｘｎ）である。すべての基準値による符号化ｘｎは、送信が行われるＲＯＨＣパケット内のｘｎに対する少なくともこの数のビットを使用することを意味する。
【００５５】
従来のＲＯＨＣ  Ｏモード（楽観モード）動作の場合には、新しい値が送信されると、その新しい値はウインドウに追加され、最も古い値がウインドウから除去される。すなわち、
圧縮装置が、
（ｘ０，ｘ１，．．．，ｘｎ−ｋ，．．．，ｘｎ−１，ｘｎ，．．．）を使用してｘｎを符号化すると、ウインドウは、
（ｘ０，ｘ１，．．．，ｘｎ−ｋ，ｘｎ＋１−ｋ，．．．，ｘｎ−１，ｘｎ，ｘｎ＋１，．．．）に更新されてｘｎ＋１を符号化し、次に、ウインドウは、
（ｘ０，ｘ１．．．，ｘｎ−ｋ，ｘｎ＋１−ｋ，ｘｎ＋２−ｋ，．．．，ｘｎ−１，ｘｎ，ｘｎ＋１，ｘｎ＋２，，．．．）に更新されて、以下同様に行われる。
【００５６】
通常の音声／ＩＰストリーム上でＯモードで動作している場合には、タイムスタンプの４ビットだけを送信すればよい。すなわち２バイトのＵＤＰチェックサムを含む各ヘッダに対する３バイトであるＵＯ−０パケット・フォーマットを使用することができる。
【００５７】
ハンドオーバまたはモビリティ手順が開始されると、ウインドウを異なる方法で更新するような提案がなされる。ｘｓがモビリティが開始された後で送信する最初の値である場合には、圧縮装置は、
（ｘ０，ｘ１，．．．，ｘｓ−ｋ，．．．，ｘｓ−１，ｘｓ，．．．）を使用してｘｓを符号化し、次に、ウインドウは、ｘｓ＋１を符号化するために、
（ｘ０，ｘ１，．．．，ｘｓ−ｋ，．．．，ｘｓ−１，ｘｓ，ｘｓ＋１，．．．）に更新され、次に、ウインドウは、
（ｘ０，ｘ１，．．．，ｘｓ−ｋ，．．．，ｘｓ−１，ｘｓ，ｘｓ＋１，ｘｓ＋２，．．．）に更新され、以下同様に行われる。
【００５８】
すなわち、ハンドオーバまたはモビリティ手順中に新しい値が送信されると、新しい値が追加された場合に、スライディング・ウインドウから古い基準値が除去されず、ウインドウ内の値の数が、送信した各値に対して１だけ増大する。
【００５９】
ＲＯＨＣ圧縮パケット・サイズは、下記のように決定される。スライディング・ウインドウ内の基準値の数が増大すると、（約２ｗｉｎｄｏｗ  ｓｉｚｅ）ＳＮのより多くのビットを送信しなければならないし、ＲＯＨＣパケット・ヘッダ・フォーマットは、ウインドウ内の値の数により決まる。すなわち、
・１６まで：ＵＯ−０（ＳＮの４ビットを含む３バイト長）
・６４まで：ＵＯ−２（ＳＮの６ビットを含む５バイト長）
・５１２まで：ＵＯ−２拡張０（ＳＮの９ビットを含む６バイト長）
ハンドオーバまたはモビリティ手順中に圧縮されたパケットは、送信することができないが、問題なのは、ハンドオーバまたはモビリティ手順完了後に、ＲＯＨＣ圧縮装置が、パケットを正しく圧縮することができるように更新されていることである。
【００６０】
ハンドオーバまたはモビリティ手順が完了すると、スライディング・ウインドウにより圧縮した値を送信することができるようになり、同じ方法でそれを更新することができる。ｘｅがハンドオーバまたはモビリティ手順完了後に送信する最初の値である場合には、ｍは、その誤り特性により新しい無線リンク上の正しい動作を確保するためのスライディング・ウインドウ内の値の数である。同時にウインドウからすべての古い値（イタリックで示す）を除去するために、スライディング・ウインドウからｘｅを除去することができるようになるまで、待つように提案する。すなわち、圧縮装置は、
（ｘ０，ｘ１，．．．，ｘｓ−ｋ，．．．，ｘｓ−１，ｘｅ，．．．）を使用してｘｅを符号化し、次に、ウインドウは、ｘｅ＋１を符号化するために、
（ｘ０，ｘ１，．．．，ｘｓ−ｋ，．．．，ｘｓ−１，ｘｅ，ｘｅ＋１，．．．）になるように更新され、次に、ウインドウは、
（ｘ０，ｘ１，．．．，ｘｓ−ｋ，．．．，ｘｓ−１，ｘｅ，ｘｅ＋１，ｘｅ＋２，．．．）になるように更新され、ｘｅ＋ｍ−１を符号化するために、ウインドウが、
（ｘ０，ｘ１，．．．，ｘｓ−ｋ，．．．，ｘｓ−１，ｘｅ，ｘｅ＋１，ｘｅ＋２，．．．，ｘｅ＋ｍ−２，ｘｅ＋ｍ−１，．．．）になるまで、以下同様に行われる。
【００６１】
圧縮したパケット・サイズは下記のとおりであるが、実際に送信される。
【００６２】
次に、ウインドウは、ｘｅ＋ｍ−１を符号化するために、
（ｘ０，ｘ１，．．．，ｘｓ−ｋ，．．．，ｘｓ−１，ｘｅ，ｘｅ＋１，ｘｅ＋２，．．．，ｘｅ＋ｍ−２，ｘｅ＋ｍ−１，．．．）に更新され、ｘｅ＋ｍを符号化するために、
（ｘ０，ｘ１，．．．，ｘｓ−ｋ，．．．，ｘｓ−１，ｘｅ，ｘｅ＋１，ｘｅ＋２，．．．，ｘｅ＋ｍ−２，ｘｅ＋ｍ−１，ｘｅ＋ｍ，．．．）に更新される。
【００６３】
ハンドオーバまたはモビリティ手順が行われない場合には、次に、スライディング・ウインドウは、通常の形になり、圧縮されたパケット・サイズは３バイト（ＵＯ−０フォーマット）に戻る。
【００６４】
本発明の方法を使用すれば、２０ｍｓ毎に１つのフレームを生成するＡＭＲコーデックを使用する通常の音声／ＩＰ呼の場合に、３ＧＰＰが現在規定しているＩＲ−ＤＹＮヘッダ０（１５バイト）ではなく、５バイトのヘッダで１秒のハンドオーバを処理することができ、５秒以下のハンドオーバを６バイトのヘッダで処理することができる。
【００６５】
図２は、ＵモードおよびＯモード（一方向モードおよび楽観モード）のＲＯＨＣ圧縮装置の通常の挙動を示す。
【００６６】
図２においては、ステップ２において、圧縮装置が、圧縮解除装置にそれを送信するために新しい値ｖを決定し、ステップ４において、圧縮解除装置が、ウインドウが最大ウインドウ幅値を含んでいるか否かを確認する。
【００６７】
ウインドウがＭａｘ＿ｗｉｄｔｈ値を含んでいる場合には、圧縮装置は、ステップ６において、Ｗ−ＬＳＢ符号化値を送信する。ステップ８において、圧縮解除装置は上記値をウインドウに追加し、圧縮解除装置は、ステップ１０において、ウインドウから最も古い値を除去する。
【００６８】
そうでない場合には、ステップ１２において、圧縮装置は、元の値ｖを送信し、圧縮解除装置はその値をステップ１４においてウインドウに追加する。
【００６９】
ここで図３を参照すると、この図は、ウインドウ内にＭａｘ＿ｗｉｄｔｈ値を含み、ハンドオーバまたはモビリティ手順が開始された場合を示す。
【００７０】
この状況の場合、図３に示すように、ステップ２０において、圧縮装置は、圧縮解除装置に送るための新しい値を決定する。その間、Ｗ−ＬＳＢは新しい値を符号化する。圧縮装置は、Ｗ−ＬＳＢ符号化値をステップ２２において圧縮解除装置に送信する。ステップ２４において、圧縮解除装置は、Ｗ−ＬＳＢ符号化値をウインドウに追加し、ステップ２０から最適化手順が再開される。
【００７１】
図３に示すように、ハンドオーバまたはモビリティ手順中、最も古い値はウインドウから除去されない。
【００７２】
図４は、ハンドオーバまたはモビリティ手順完了後の本発明による方法を示す。図４においては、ステップ３０において、圧縮装置が、圧縮解除装置に送るための新しい値ｖを決定する。ステップ３２において、圧縮解除装置が、ウインドウが、ハンドオーバまたはモビリティ手順完了後に送信した最大ウインドウ幅値を含んでいるか否かを確認する。
【００７３】
ウインドウがＭａｘ＿ｗｉｄｔｈ値を含んでいる場合には、圧縮装置は、ステップ３４において、Ｗ−ＬＳＢ符号化値を圧縮解除装置に送信する。ステップ３６において、圧縮解除装置はＷ−ＬＳＢ符号化値をウインドウに追加し、圧縮解除装置は、ステップ３８において、最大幅の最新のものを除いて、すべての値をウインドウから除去し、ステップ３９において、通常の手順に戻る。
【００７４】
そうでない場合には、図４のステップ４０において、圧縮装置は、Ｗ−ＬＳＢ符号化値を圧縮解除装置に送信し、ステップ４２において、圧縮解除装置は、Ｗ−ＬＳＢ符号化値をウインドウに追加し、ステップ３０から最適化手順を再開する。
【００７５】
本発明によれば、図４に示すように、ハンドオーバまたはモビリティ手順後に、リンクの誤り率により最大幅が設定される。新しいリンクが古いリンクとは異なる誤り特性を有している場合には、最大幅は異なるものであってもよい。
【図面の簡単な説明】
【００７６】
【図１】従来技術のＲＯＨＣ（ロバスト・ヘッダ圧縮）の主要な原理のうちの１つである。
【図２】ＵモードおよびＯモード（一方向モードおよび楽観モード）の本発明によるＲＯＨＣ圧縮装置の通常の挙動のフローチャートである。
【図３】ハンドオーバまたはモビリティ手順が開始された場合の本発明によるＲＯＨＣ圧縮装置の挙動のフローチャートである。
【図４】ハンドオーバまたはモビリティ手順が完了した場合の本発明によるＲＯＨＣ圧縮装置の挙動のフローチャートである。
【図１】
2009512231.tif 000003
【図２】
2009512231.tif 000004
【図３】
2009512231.tif 000005
【図４】
2009512231.tif 000006
【国際調査報告】
2009512231.tif 000007