(57)【要約】  無線通信システムのユーザ機器（２００）は、スケジューリング情報を監視し、監視されるスケジューリング情報に基づいてアップリンクチャネルのリンクデータレートの変化をローカルで検出する。このように、リンクデータレートの変化は、大きな遅延なく直接検出される。このレートの変化の直接的な検出又は早期検出は、適切なシステムの反応と組み合わされる。検出されたリンクデータレートの変化の情報は、ユーザ機器において実行するＩＰアプリケーションのアプリケーションデータレートを適応させるために利用されるのが好ましい。あるいは、又は補完的役割として、データパケットは相対的な重要度に基づいて分類され、データパケットの分類に基づき且つ検出したリンクデータレートの変化に依存してアップリンクチャネルを介する情報の転送のために選択される。
2009526432.tif 000002
【特許請求の範囲】
【請求項１】
無線通信システムにおいて、インターネットプロトコル（ＩＰ）スタックを実装するユーザ機器と基地局との間のアップリンクチャネルの性能を向上する方法であって、
前記ユーザ機器がスケジューリング情報を監視するステップと、
前記ユーザ機器が前記スケジューリング情報に基づいて前記アップリンクチャネルのリンクデータレートの変化をローカルで検出するステップと、
前記アップリンクチャネルの前記検出したリンクデータレートの変化に基づいてＩＰアプリケーションのアプリケーションデータレートを適応させるステップと、
を有することを特徴とする方法。
【請求項２】
前記スケジューリング情報は、前記基地局から受信される
ことを特徴とする請求項１記載の方法。
【請求項３】
前記アップリンクチャネルは専用データチャネルであり、
前記スケジューリング情報は、前記専用データチャネルにおいて費やされる前記ユーザ機器の送信電力の総量を判定する電力比に関する情報を含む
ことを特徴とする請求項１又は２記載の方法。
【請求項４】
前記ユーザ機器が前記データレートの変化を検出する前記ステップは、前記基地局から信号伝送される電力比の変化を検出することに基づく
ことを特徴とする請求項３記載の方法。
【請求項５】
前記ユーザ機器が前記データレートの変化を検出する前記ステップは、前記基地局から信号伝送される現在の電力比に到達するのに十分な送信電力を前記ユーザ機器が有するかを判定することに基づく
ことを特徴とする請求項３記載の方法。
【請求項６】
前記スケジューリング情報は、前記ユーザ機器のデータバッファの状態を表す情報を含み、
データレートの変化をローカルで検出する前記ステップには、前記ユーザ機器におけるデータバッファ蓄積をローカルで識別するステップが含まれる
ことを特徴とする請求項１記載の方法。
【請求項７】
前記方法は、前記アップリンクチャネルのデータレートの相対的な変化を前記アプリケーションに信号伝送するステップを更に有し、
アプリケーションデータレートを適応させる前記ステップは、前記チャネルデータレートの相対的な変化に基づく
ことを特徴とする請求項１記載の方法。
【請求項８】
アプリケーションデータレートを適応させる前記ステップは、前記ユーザ機器のアプリケーション層において実行される
ことを特徴とする請求項１記載の方法。
【請求項９】
アプリケーションデータレートを適応させる前記ステップには、所定のアプリケーションに対してサポートするサービスコンポーネントを判定するステップが含まれる
ことを特徴とする請求項１記載の方法。
【請求項１０】
アプリケーションデータレートを適応させる前記ステップは、前記無線通信システムのネットワーク側から実行される
ことを特徴とする請求項９記載の方法。
【請求項１１】
前記チャネルを介する情報の転送に対する各データパケットの相対的な重要度に基づいてデータパケットを分類するステップと、
データパケットの前記分類に基づいて前記チャネルを介する情報の転送のためにデータパケットを選択するステップと、
を更に有することを特徴とする請求項１記載の方法。
【請求項１２】
前記アップリンクチャネルは、ＷＣＤＭＡ無線アクセスインタフェースを介してＩＰパケットを送信するための拡張専用チャネル（Ｅ−ＤＣＨ）に基づく
ことを特徴とする請求項１記載の方法。
【請求項１３】
無線通信システムにおいて、インターネットプロトコル（ＩＰ）スタックを実装するユーザ機器と基地局との間のアップリンクチャネルの性能を向上する方法であって、
前記ユーザ機器がスケジューリング情報を監視するステップと、
前記ユーザ機器が前記スケジューリング情報に基づいて前記アップリンクチャネルのリンクデータレートの変化をローカルで検出するステップと、
前記チャネルを介する情報の転送に対する各データパケットの相対的な重要度に基づいてデータパケットを分類するステップと、
データパケットの前記分類及び前記アップリンクチャネルの前記検出したリンクデータレートの変化に基づいて前記アップリンクチャネルを介する情報の転送のためにデータパケットを選択するステップと、
を有することを特徴とする方法。
【請求項１４】
前記スケジューリング情報は、前記基地局から受信される
ことを特徴とする請求項１３記載の方法。
【請求項１５】
前記アップリンクチャネルは専用データチャネルであり、前記スケジューリング情報は、前記専用データチャネルにおいて費やされる前記ユーザ機器の送信電力の総量を判定する電力比に関する情報を含む
ことを特徴とする請求項１３又は１４記載の方法。
【請求項１６】
前記ユーザ機器が前記データレートの変化を検出する前記ステップは、前記基地局から信号伝送される電力比の変化を検出することに基づく
ことを特徴とする請求項１５記載の方法。
【請求項１７】
前記ユーザ機器が前記データレートの変化を検出する前記ステップは、前記基地局から信号伝送される現在の電力比に到達するのに十分な送信電力を前記ユーザ機器が有するかを判定することに基づく
ことを特徴とする請求項１５記載の方法。
【請求項１８】
前記スケジューリング情報は、前記ユーザ機器のデータバッファの状態を表す情報を含み、
データレートの変化をローカルで検出する前記ステップには、前記ユーザ機器におけるデータバッファ蓄積をローカルで識別するステップが含まれる
ことを特徴とする請求項１３記載の方法。
【請求項１９】
データパケットを選択する前記ステップには、送信に対して重要度がより低いとして分類されたデータパケットの前に重要度がより高いとして分類されたデータパケットをスケジュールするステップを含まれる
ことを特徴とする請求項１３記載の方法。
【請求項２０】
データパケットを選択する前記ステップには、より重要なデータパケットに対する送信試行の回数を増加するステップが含まれる
ことを特徴とする請求項１９記載の方法。
【請求項２１】
データパケットを選択する前記ステップには、前記ユーザ機器のデータパケットキューのデータパケットの部分集合のみを選択し、データパケットを効果的にドロップするステップが含まれる
ことを特徴とする請求項１３記載の方法。
【請求項２２】
データパケットを効果的にドロップするためにデータパケットの部分集合のみを選択する前記ステップには、データパケットの前記分類に基づいてドロップされるべきデータパケットを判定するステップが含まれる
ことを特徴とする請求項２１記載の方法。
【請求項２３】
前記データパケットはメディアフレームを含み、データパケットを分類する前記ステップには、各メディアフレームの損失により発生する歪み量に基づいて前記データパケットの前記メディアフレームを分類するステップが含まれる
ことを特徴とする請求項１３記載の方法。
【請求項２４】
前記データパケットの前記メディアフレームを分類する前記ステップは、各メディアフレームの損失がエラー隠蔽によりどの程度隠蔽されるかに基づく
ことを特徴とする請求項２３記載の方法。
【請求項２５】
データパケットを分類する前記ステップには、前記チャネルを介する情報の転送に対する各ヘッダの相対的な重要度に基づいて前記データパケットのヘッダを分類するステップが含まれる
ことを特徴とする請求項１３記載の方法。
【請求項２６】
前記ヘッダは、前記各ヘッダの種類及び目的のうち少なくとも一方に対する相対的な重要度に基づいて分類される
ことを特徴とする請求項２５記載の方法。
【請求項２７】
前記アップリンクチャネルの前記検出したデータレートの変化に基づいてＩＰアプリケーションの適切なアプリケーションデータレートを選択するステップを更に有する
ことを特徴とする請求項１３記載の方法。
【請求項２８】
前記アップリンクチャネルは、ＷＣＤＭＡ無線アクセスインタフェースを介してＩＰパケットを送信するための拡張専用チャネル（Ｅ−ＤＣＨ）に基づく
ことを特徴とする請求項１３記載の方法。
【請求項２９】
前記ユーザ機器はＶｏＩＰ（Voice over IP）アプリケーションを実装し、前記データパケットは音声フレームを表す
ことを特徴とする請求項１３記載の方法。
【請求項３０】
インターネットプロトコル（ＩＰ）スタックを実装し、無線通信システムにおいて基地局とパケットを使用する無線通信を行なうように構成されるユーザ機器であって、
スケジューリング情報を監視する手段と、
前記スケジューリング情報に基づいて前記ユーザ機器から前記基地局へのアップリンクチャネルのリンクデータレートの変化をローカルで検出する手段と、
前記アップリンクチャネルの前記検出したリンクデータレートの変化に基づいてＩＰアプリケーションのアプリケーションデータレートを適応させる手段と、
を備えることを特徴とするユーザ機器。
【請求項３１】
前記スケジューリング情報を前記基地局から受信する手段を更に備える
ことを特徴とする請求項３０記載のユーザ機器。
【請求項３２】
前記アップリンクチャネルは専用データチャネルであり、
前記スケジューリング情報は、前記専用データチャネルにおいて費やされる前記ユーザ機器の送信電力の総量を判定する電力比に関する情報を含む
ことを特徴とする請求項３０又は３１記載のユーザ機器。
【請求項３３】
データレートの変化を検出する前記手段は、前記基地局から信号伝送される電力比の変化を検出するように動作可能である
ことを特徴とする請求項３２記載のユーザ機器。
【請求項３４】
データレートの変化を検出する前記手段は、前記ユーザ機器が前記基地局から信号伝送される現在の電力比に到達するのに十分な送信電力を有するかを判定するように動作可能である
ことを特徴とする請求項３２記載のユーザ機器。
【請求項３５】
前記アップリンクチャネルのデータレートの相対的な変化を前記アプリケーションに信号伝送する手段を更に備え、
アプリケーションデータレートを適応させる前記手段は、前記チャネルデータレートの相対的な変化に基づいて前記アプリケーションデータレートを調整するように動作可能である
ことを特徴とする請求項３０記載のユーザ機器。
【請求項３６】
前記チャネルを介する情報の転送に対する各データパケットの相対的な重要度に基づいてデータパケットを分類する手段と、
データパケットの前記分類に基づいて前記チャネルを介する情報の転送のためにデータパケットを選択する手段と、
を更に備えることを特徴とする請求項３０記載のユーザ機器。
【請求項３７】
前記ユーザ機器は、ＷＣＤＭＡ無線アクセスインタフェースを介してＩＰパケットを送信するための拡張専用チャネル（Ｅ−ＤＣＨ）に基づくアップリンクチャネルをサポートするように構成される
ことを特徴とする請求項３０記載のユーザ機器。
【請求項３８】
インターネットプロトコル（ＩＰ）スタックを実装し、無線通信システムにおいて基地局とパケットを使用する無線通信を行なうように構成されるユーザ機器であって、
スケジューリング情報を監視する手段と、
前記スケジューリング情報に基づいて前記ユーザ機器から前記基地局へのアップリンクチャネルのリンクデータレートの変化をローカルで検出する手段と、
前記チャネルを介する情報の転送に対する各データパケットの相対的な重要度に基づいてデータパケットを分類する手段と、
データパケットの前記分類及び前記アップリンクチャネルの前記検出したリンクデータレートの変化に基づいて前記アップリンクチャネルを介する情報の転送のためにデータパケットを選択する手段と、
を備えることを特徴とするユーザ機器。
【請求項３９】
前記スケジューリング情報を前記基地局から受信する手段を更に備える
ことを特徴とする請求項３８記載のユーザ機器。
【請求項４０】
前記アップリンクチャネルは専用データチャネルであり、
前記スケジューリング情報は、前記専用データチャネルにおいて費やされる前記ユーザ機器の送信電力の総量を判定する電力比に関する情報を含む
ことを特徴とする請求項３８又は３９記載のユーザ機器。
【請求項４１】
データレートの変化を検出する前記手段は、前記基地局から信号伝送される電力比の変化を検出するように動作可能である
ことを特徴とする請求項４０記載のユーザ機器。
【請求項４２】
データレートの変化を検出する前記手段は、前記ユーザ機器が前記基地局から信号伝送される現在の電力比に到達するのに十分な送信電力を有するかを判定するように動作可能である
ことを特徴とする請求項４０記載のユーザ機器。
【請求項４３】
データパケットを選択する前記手段は、より重要なデータパケットに対する送信試行の回数を増加する手段を含む
ことを特徴とする請求項３８記載のユーザ機器。
【請求項４４】
データパケットを選択する前記手段は、前記ユーザ機器のデータパケットキューのデータパケットの部分集合のみを選択し、データパケットを効果的にドロップする手段を備える
ことを特徴とする請求項３８記載のユーザ機器。
【請求項４５】
前記データパケットはメディアフレームを含み、
データパケットを分類する前記手段は、各メディアフレームの損失により発生する歪み量に基づいて前記データパケットの前記メディアフレームを分類する手段を備える
ことを特徴とする請求項３８記載のユーザ機器。
【請求項４６】
データパケットを分類する前記手段は、前記チャネルを介する情報の転送に対する各ヘッダの相対的な重要度に基づいて前記データパケットのヘッダを分類する手段を備える
ことを特徴とする請求項３８記載のユーザ機器。
【請求項４７】
前記アップリンクチャネルの前記検出したリンクデータレートの変化に基づいてＩＰアプリケーションの適切なアプリケーションデータレートを選択する手段を更に備える
ことを特徴とする請求項３８記載のユーザ機器。
【請求項４８】
前記ユーザ機器は、ＷＣＤＭＡ無線アクセスインタフェースを介してＩＰパケットを送信するための拡張専用チャネル（Ｅ−ＤＣＨ）に基づくアップリンクチャネルをサポートするように構成される
ことを特徴とする請求項３８記載のユーザ機器。
【請求項４９】
前記ユーザ機器はＶｏＩＰ（Voice over IP）アプリケーションを実装するように構成され、前記データパケットは音声フレームを表す
ことを特徴とする請求項３８記載のユーザ機器。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に無線通信に関し、特にインターネットプロトコル（ＩＰ）を使用する無線通信技術に関する。
【背景技術】
【０００２】
無線通信は、この１０年間で非常に発展してきた。無線ネットワークが第３世代以上に向けて進展及び発達すると共に、パケットデータサービスは、例えばより大きい帯域幅及びインターネットへのより高いアクセス可能性を提供することを主な目的としてきた。従って、通常、エンドユーザデバイス及び端末を含むネットワークアーキテクチャ、並びにプロトコルは、可能な限り効率的にインターネットプロトコル（ＩＰ）サービスをサポートするように設計及び構築される。
【０００３】
例えば、ダウンリンクにおける高速ダウンリンク・パケットアクセス（ＨＳＤＰＡ：High Speed Downlink Packet Access）及びアップリンクにおける拡張専用チャネル（Ｅ−ＤＣＨ：Enhanced Dedicated Channel）を含むＷＣＤＭＡ仕様の進展により、ＷＣＤＭＡ無線アクセスインタフェースを介してＩＰパケットを送信するように最適化されたエアインタフェースが提供される。その結果、高いスペクトル効率（既存の回線交換会話型ベアラの性能に匹敵するか又はそれを上回る）を有するＩＰを介する会話型サービス（メディアアプリケーション）を提供する可能性が導かれた。図１は、従来のダウンリンク及びアップリンクを介してユーザ機器（ＵＥ：User Equipment）２００と通信するノードＢ等の基地局１００を含む簡単化された無線通信システムの関連部分を示す。ＵＥ２００は、容認された標準技術に従ってＩＰスタックを実装する。通常、プロトコルスタックは、物理層、データリンク層、ネットワーク層、トランスポート層及びアプリケーション層を含む。ＩＰスタックの場合、ネットワーク層は、ＩＰｖ４又はＩＰｖ６に基づくか、あるいはＭＩＰｖ４又はＭＩＰｖ６等のモバイルＩＰｖ４又はモバイルＩＰｖ６に基づく。多くの場合、ネットワーク層はＩＰ層又はインターネット層と呼ばれる。
【０００４】
会話型サービスは、音声、ビデオ又はテキストを使用する通信等の種々のサービスコンポーネント又はアプリケーションコンポーネントから構成されてもよい。各サービスコンポーネントは、使用可能な最低データレート、データレートの変動に適応する可能性、許可される遅延及びパケット損失等に関して異なる要求を有する。通信アプリケーションは、以下のような種々の方法で変化に適応してしてもよい。：
・ＡＭＲに基づく音声コーデックは、種々のアプリケーションを結果として与える種々のモードを使用してもよい。
・アプリケーションに対するサービスコンポーネントの数は、例えばビデオコンポーネントをドロップし且つ音声のみを保持することにより減少されてもよい。
【０００５】
標準化の文献である非特許文献１及び非特許文献２で特定されるように、Ｅ−ＤＣＨはＩＰ送信に対して拡張された専用チャネルを提供する。その拡張は以下を含む。：
・より短いＴＴＩ（Transmission Time Interval、送信時間間隔）を使用する可能性。
・移動端末と基地局との間の高速ハイブリッドＡＲＱ（ＨＡＲＱ）。
・基地局からの移動端末の送信レートのスケジューリング。
【０００６】
ダウンリンクにおけるＨＳＤＰＡと同様に、アップリンクにおいてＥ−ＤＣＨに対するパケットスケジューラがあるが、通常、これは要求許可の原理に基づいて動作する。この要求許可の原理において、ユーザ機器（ＵＥ）又は端末はデータ送出の許可を要求し、端末が送出を行なう時期とその端末の台数をネットワーク側のスケジューラが決定する。通常、送信の要求は、送信データバッファの状態、端末側のキュー及び端末の利用可能な電力余裕に関するデータを含む。規格は、２つの基本的なスケジューリング方法を考慮している。長期許可は、符号多重化を使用して同時にデータを送出できるいくつかの端末に対して発行される。一方、短期許可は時間領域において端末の多重化を可能にする。符号及び時間領域の双方におけるいくつかの端末のアップリンク送信の多重化を可能にするために、スクランブルコード及びチャネライゼーションコードは異なる端末間で共有されないと予想される。
【０００７】
専用物理データチャネル（ＤＰＤＣＨ：Dedicated Physical Data Channel）及び専用物理制御チャネル（ＤＰＣＣＨ：Dedicated Physical Control Channel）が同時に符号多重化され且つ送信されると仮定すると、それらの送信電力間の比は達成可能なペイロードデータレートに対して重要である。端末の電力のうち多くの電力がＤＰＤＣＨに割り当てられると、達成可能なペイロードデータレートは増加する。非特許文献３において、ＤＰＤＣＨの電力とＤＰＣＣＨの電力との比は固定値に設定された。Ｅ−ＤＣＨの場合、この比は一般に基地局（ノードＢ）により制御され、スケジューリング許可コマンドで端末に信号伝送される。
【０００８】
Ｅ−ＤＣＨ又は同様のアップリンク技術を使用する場合、個別のＵＥのデータレートを制限できる機構が２つある。第１に、基地局はサービング許可を更新することにより（すなわち、スケジュールすることにより）ＵＥの現在のデータレートを低下してもよい。第２に、ＵＥは現在のデータレートを維持するのに十分な送信電力を有さない可能性があり、この場合、ＵＥは送信レートを自動的に制限する。一般に、ＵＥがセルの端部に近い場合にこの自律的な低下は行なわれる。
【０００９】
同様に、個別のＵＥのレートはノードＢからのサービング許可を更新することにより増加されてもよく、あるいはＵＥの電力が制限される場合、ＵＥは十分な電力が利用可能になるとすぐに自律的にレートを増加してもよい。
【００１０】
リンクデータレートを低下することにより、会話型アプリケーションに問題が発生する可能性がある。一般に、アプリケーションのデータレートがリンクデータレートを超える場合、パケットはまずバッファリングされ、最終的に（バッファがオーバフローすると）ドロップされる。バッファリングにより、送信遅延が伸び且つ会話の品質が低下する。また、パケット損失は直接的に品質の低下となる。
【００１１】
リンクレートが増加すると、アプリケーションは、例えばデータレートを増加することにより又は新しいサービスコンポーネントを通話に追加することにより品質を向上できるだろう。しかし、アプリケーションは品質を向上する前に利用可能な帯域幅を調査する必要がある（例えば、送信レートの増加を試み、結果として起こるパケット損失と遅延との少なくともいずれかを観察することにより）。この調査（プローブ）機構は、輻輳状況における必然的な遅延負荷の増加を回避する程度のものである必要がある。
【００１２】
一般に、エンド・ツー・エンドのパケット損失又は受信信号強度等の、リンク品質尺度を使用することにより、Ｅ−ＤＣＨ又は同様のアップリンクチャネルのレートの変化の検出が遅くなり、新しいリンクデータレートを検出する可能性は制限される。
【００１３】
レートの変化の検出が遅くなった結果、パケットはＥ−ＤＣＨリンク層によりキュー登録される。キュー登録により、会話の遅延又は遅延ロスは増加する。
【００１４】
一般に、利用可能なデータレートの増加を検出するために調査機構を使用することにより、低下したリンクレートからの回復は遅くなり、利用可能な速いデータレートへの反応も遅くなる。更に全ての調査機構は、輻輳状況における負荷を増加し、性能を低下させる可能性がある。
【００１５】
リンクデータレートを速く推定すると、キュー登録とパケット損失との少なくともいずれかを引き起こす。リンクデータレートを遅く推定すると、使用されるアプリケーションデータレートが遅くなりすぎる。その結果、一般に品質（音声の）は低下する。
【００１６】
従って、一般に、無線通信システムにおけるユーザ機器と基地局との間のアップリンクチャネルの性能の向上が要求されている。
【非特許文献１】3GPP TS 25.309
【非特許文献２】3GPP TS 25.319
【非特許文献３】UMTS Release 99
【発明の開示】
【発明が解決しようとする課題】
【００１７】
本発明は、従来技術の構成の上記欠点及び他の欠点を克服する。
【００１８】
本発明の一般的な目的は、無線ネットワークにおいてインターネットプロトコル（ＩＰ）スタックを実装するユーザ機器と基地局との間のアップリンクチャネルの性能を向上することである。
【００１９】
特に無線条件が困難な場合とシステムが輻輳している場合との少なくともいずれかの場合に、ＶｏＩＰ（Voice over IP）等のＩＰアプリケーションの動作をサポートし且つ向上するのが特に望ましい。
【００２０】
本発明の特定の目的は、無線ネットワークにおいてユーザ機器と基地局との間のアップリンクチャネルの性能を向上する方法を提供することである。
【００２１】
本発明の別の特定の目的は、ＩＰスタックを実装し且つ性能が向上したＩＰアプリケーションを実行するように構成されたユーザ機器を提供することである。
【００２２】
上記目的及び他の目的は、添付の請求の範囲により規定されるような本発明により達成される。
【００２３】
既存の解決策に関する主な問題は、エンド・ツー・エンドのパケット損失又は受信信号強度等の間接的なリンク品質尺度により、アップリンクチャネルのレートの変化の検出が遅くなり且つ新しいリンクデータレートを検出する手段が制限されることであることが、慎重な解析により明らかになった。レートの変化の検出が遅くなった結果、パケットはリンク層によりキュー登録される。キュー登録により、会話の遅延又は遅延ロスが増加する。キュー登録を減少するために、パケットをドロップするのが好ましいだろう。しかし、従来、リンク層は種々のフレームの重要度に関する情報を有さず、パケットをドロップすることにより品質が低下する可能性がある。
【課題を解決するための手段】
【００２４】
本発明の第１の面によると、基本概念は、ユーザ機器においてスケジューリング情報を監視し、監視されるスケジューリング情報に基づいてアップリンクチャネルのリンクデータレートの変化をローカルで検出し、その後、ユーザ機器において実行するＩＰアプリケーションのアプリケーションデータレートを適応させるために検出したリンクデータレートの変化の情報を使用することである。
【００２５】
このように、リンクデータレートの変化は大きな遅延なく直接検出され、アプリケーションの挙動は必然的にリンクデータレートの変化を早期検出することに適応される。
【００２６】
一般に、アプリケーションデータレートの適応は、ユーザ機器のアプリケーション層において実行されるか又はネットワーク側から制御される。
【００２７】
本発明の第２の面によると、基本概念は、ユーザ機器においてスケジューリング情報を監視し、監視されるスケジューリング情報に基づいてアップリンクチャネルのリンクデータレートの変化をローカルで検出し、その後、相対的な重要度に基づいてデータパケットを分類し、データパケットの分類に基づき且つ検出されたリンクデータレートの変化に依存してアップリンクチャネルを介する情報の転送のためにデータパケットを選択することである。
【００２８】
このように、リンクデータレートの変化は大きな遅延なく直接検出される。データパケットは、検出されたリンクデータレートの変化に依存して、スケジューリングとドロップとの少なくともいずれかがなされる。
【００２９】
本発明の全ての面において、スケジューリング情報は、必ずではないが基地局から受信されるのが好ましい。例えば、その情報は、アップリンクのデータ通信に使用される専用データチャネルにおいて費やされるユーザ機器の送信電力の総量を判定する電力比に関する情報を含んでもよい。
【００３０】
一般に、本発明は、任意の種類のアップリンクチャネルの性能を向上するために適用可能であるが、ＷＣＤＭＡ無線アクセスインタフェースを介してＩＰパケットを送信するＥ−ＤＣＨに特に適する。
【００３１】
本発明の第１の面及び第２の面が組み合わされてもよいことが理解されるべきである。すなわち、リンクデータレートの変化が早期検出されることに応答してアプリケーションデータレートを直接適応させること及びデータパケットの分類に更に基づいてデータパケットを選択することの双方を使用する。
【００３２】
本発明は、以下の主な利点を提供する。：
・アップリンクチャネルの性能の向上。
・遅延の短縮。
・パケット損失の減少。
・メディア品質の向上。
【００３３】
本発明により提供される他の利点は、本発明の実施形態の以下の説明を読むことにより理解されるだろう。
【発明を実施するための最良の形態】
【００３４】
添付の図面と共に以下の説明を参照することにより、本発明は、本発明の更なる目的及び利点と共に最もよく理解されるだろう。
【００３５】
図中、同一の図中符号は対応する要素又は同様の要素に対して使用される。
【００３６】
上述のように、従来技術の主な問題の１つは、エンド・ツー・エンドのパケット損失又は受信信号強度等の間接的なリンク品質尺度により、アップリンクチャネルのレートの変化の検出が遅くなり且つ新しいリンクデータレートを検出する手段が制限されることである。レートの変化の検出が遅くなった結果、パケットはリンク層によりキュー登録される。キュー登録により、会話の遅延又は遅延ロスが増加する。キュー登録を減少するために、パケットをドロップするのが好ましいだろう。しかし、従来、リンク層は種々のフレームの重要度に関する情報を有さず、パケットをドロップすることにより品質が低下する可能性がある。これは、複雑で多少矛盾する状況を引き起こす。
【００３７】
本発明は、検出された変化に応答して適切なシステムの反応と組み合わされる当該アップリンクチャネルのリンクデータレートの変化を早期検出するための新しい機構に基づいて上記問題に対する解決策を提供する。
【００３８】
本発明の第１の面において、図２を参照すると、ユーザ機器は、スケジューリング情報を監視し（Ｓ１）、監視されるスケジューリング情報に基づいてアップリンクチャネルのリンクデータレートの変化をローカルで検出する（Ｓ２）。検出したリンクデータレートの変化の情報は、ユーザ機器において実行するＩＰアプリケーションのアプリケーションデータレートを適応させる（Ｓ３）ために使用される。このように、リンクデータレートの変化は大きな遅延なく直接検出され、アプリケーションの挙動はリンクデータレートの変化を早期検出することに適応される。
【００３９】
アプリケーションデータレートの適応は、ユーザ機器のアプリケーション層において実行されるか又はネットワーク側から開始される。例えば新しいリンクデータレートに関する情報は、アプリケーション層に信号伝送されてもよい。アプリケーション層において、より適切なアプリケーションデータレートが選択される。アプリケーションデータレートの適応は、サポートされなくなったコンポーネントを除去するか又はサポートされるコンポーネントを追加するなど、所定のアプリケーションに対してサポートするサービスコンポーネント（例えば、音声、ビデオ、テキスト）を決定することにより、あるいはマルチメディアアプリケーションのフレームレートを低下することにより実行されてもよい。更に、ネットワーク側が信号伝送された新しいリンクデータレートに関する情報に基づいてサポートするサービスコンポーネントを判定するようにすることが可能である。
【００４０】
図３は、本発明の第１の面に係る好適な一実施形態を更に詳細に示すフローチャートである。この特定の実施形態において、ユーザ機器は、アップリンクのデータ通信に使用される専用データチャネル（例えば、Ｅ−ＤＣＨ）において費やされるユーザ機器の送信電力の総量を判定する電力比に関する情報を含む基地局からのスケジューリングコマンドを監視する（Ｓ１１）。この情報を使用して、ユーザ機器はリンクデータレートの変化をローカルで検出する（Ｓ１２）。電力比に関する情報に基づいてデータレートの変化を検出する方法は多く存在する。例えば、データレートの変化は、基地局から信号伝送された電力比の変化を検出することにより検出される。電力比の変化は、データレートの増加又は低下にマップされる。あるいは、ユーザ機器は、専用データチャネルにおいて送信するためにＵＥが利用可能な電力の推定値と信号伝送された電力比とを比較することにより、基地局から信号伝送された現在の電力比に到達するのに十分な送信電力を有しているかを判定する。ＵＥの利用可能なデータ送信電力が信号伝送された電力比を下回る場合（ＵＥの電力が制限される場合）、データレートは効果的に低下される。通常、アプリケーションレベルのデータレートは電力比の値に比例し、レートの相対的な変化をアプリケーション層に信号伝送できる（Ｓ１３）。これにより、リンクデータレートの相対的な変化に基づいてアプリケーションデータレートを適応させることが可能になる（Ｓ１４）。例えばアプリケーションは、アプリケーションに使用する符号化モードと、冗長モードと、ビットレートと、フレームレートとの少なくともいずれかを判定するために、並びに／あるいはサポートするサービスコンポーネントを判定するために、（相対的な）データレートを使用してもよい。
【００４１】
データレートの変化を検出する別の方法は、電力比情報を含む基地局からのスケジューリングコマンドを使用するのではなく、ＵＥのデータバッファの状態を表すローカルスケジューリング情報を使用する。この別の実施形態において、レートの変化は、ＵＥにおけるデータバッファ蓄積（data buffer build-up）をローカルで識別することにより検出される。
【００４２】
本発明の第２の面において、図４を参照すると、ユーザ機器はスケジューリング情報を監視し（Ｓ２１）、監視されるスケジューリング情報に基づいてアップリンクチャネルのリンクデータレートの変化をローカルで検出する（Ｓ２２）。次に、データパケットは、アップリンクチャネルを介する情報の転送のために各パケットの相対的な重要度に基づいて分類される（Ｓ２３）。これにより、データパケットの分類及び検出されたリンクデータレートの変化に基づいてアップリンクチャネルを介する転送のためにデータパケットを選択できる（Ｓ２４）。このように、リンクデータレートの変化は大きな遅延なく直接検出され、データパケットは、検出されたリンクデータレートの変化に依存して、スケジューリングとドロップとの少なくともいずれかがなされる。
【００４３】
図５は、本発明の第２の面に係る好適な実施形態を更に詳細に示すフローチャートである。この特定の実施形態において、ユーザ機器は、専用データチャネル（例えば、Ｅ−ＤＣＨ）において費やされる送信電力の総量を判定する電力比に関する情報を含む基地局からのスケジューリングコマンドを監視する（Ｓ３１）。ユーザ機器は、この情報に基づいてリンクデータレートの変化をローカルで検出する（Ｓ３２）。データパケットは、例えばアプリケーション層又はヘッダ圧縮層等のＩＰスタックの下位層において相対的な重要度に基づいて分類される（Ｓ３３）。その後、データパケットはパケットの分類に基づいて、スケジューリングとドロップとの少なくともいずれかがなされる（Ｓ３４）。
【００４４】
電力比情報に基づくレートの変化の検出は、例えば本発明の第１の面と関連して説明した方法で実装できる。あるいは、レートの変化は、上述したデータバッファ蓄積機構により検出されてもよい。
【００４５】
リンクデータレートが低下する場合、送信に対する重要度がより低いと分類されるデータパケットの前に重要度がより高いと分類されるデータパケットをスケジュールすることと、データパケットキューのデータパケットの部分集合のみを選択する（データパケットをドロップする）こととの少なくともいずれかを行うのが好ましい。例えば、重要度がより高いデータパケットに対する送信試行の回数を増加することと、重要度がより低いと分類されるデータパケットから開始してデータパケットをドロップすることとの少なくともいずれかを行うのが適切であろう。
【００４６】
最も単純な分類の結果、２つの異なる種別（例えば「重要」及び「通常」）に分類されるが、好適な実施形態においては、「重要」、「通常」及び「より重要でない」の３つの異なる品質種別が使用されると推測される。より多くの種別に対する一般化が可能であり、それはアプリケーション及び状況によっては望ましいだろう。
【００４７】
本発明の第２の面の特定の実施形態において、データパケットは、ＶｏＩＰアプリケーションの音声フレーム又はＩＰを使用するマルチメディアアプリケーションのビデオフレーム等のメディアフレームを含む。各メディアフレームの損失により発生する歪み量に基づいてデータパケットのメディアフレームを分類することが特に有用であることが分かった。より詳細には、各フレームの損失がエラー隠蔽によりどの程度隠蔽されるかに基づいてフレームを分類するのは有益である。この場合、分類はアプリケーション層において実行されるのが好ましい。
【００４８】
しかし、リンク層のヘッダ圧縮層等のＩＰスタックの下位層において分類を実行し、データパケットのヘッダを分類することによりデータパケットを分類することも可能である。パケットヘッダは、各ヘッダの種類及び目的の少なくともいずれかに対する相対的な重要度に基づいて分類されてもよい。通常、ロバストヘッダ圧縮（ＲＯＨＣ、ＲＦＣ３０９５を参照）等のヘッダ圧縮は、異なる種類の圧縮ヘッダ、すなわち新しい伸張コンテキスト（ＲＯＨＣ ＩＲパケット）を初期化するための（又は既存の伸張コンテキストを再開するための）より大きなヘッダ及びより小さな圧縮ヘッダを規定する。
【００４９】
より大きなヘッダは、ヘッダ圧縮を使用して、アルゴリズムが必要とする時にのみ例えば以下のために送出される。：
・新しいコンテキストを作成する。
・伸張失敗に対する頑強性を維持する。
・先の失敗から回復する。
・例えば元のヘッダの変更パターンが確立されたパターンに準拠していない場合に、コンテキストの要素を更新する。
【００５０】
通常、ヘッダ圧縮は、ＩＰ層の下で、すなわちアプリケーション層とＭＡＣ層との間のいずれかの場所において行なわれる。１つのサービスコンポーネントに対応する単一のヘッダ圧縮フロー内において、サービスデータユニット（ＳＤＵ）は例えばコンテキストの同期に対する相対的な影響力により分類される。特に、圧縮ヘッダの種類は互いに対する相対的な重要度を有しているため分類できる。例えば、ＲＯＨＣの場合、ＩＲパケットは最大の重要度で分類され、ＩＲ−ＤＹＮ及びＵＯＲ−２パケットは、ＰＴ−１及びＰＴ−０等のより小さいパケットより重要度が高いものとして分類される。
【００５１】
パケット自体の種類（すなわち、そのパケット自体が行なえ且つ情報として保持できるもの）に対してだけでなく（又はその代わりとして）パケットの目的（すなわち、ヘッダ圧縮アルゴリズムがそのパケットを選択した理由）に関してヘッダ圧縮パケットの重要度の分類を一般化できる。換言すると、例えば故障事象（受信したフィードバック等）及びロバストネスの論理から、伸張器コンテキストの状態の圧縮器の「ビュー」を含むように分類を拡大するのが望ましい。
【００５２】
例えば、ＵＯＲ−２圧縮ヘッダ（ＲＦＣ３０９５）は、以下の目的のためにヘッダ圧縮コンテキストの動的部分の一部、多くの部分又は全てを伝達できる：
１）追加のシーケンス情報を搬送するため。
２）非圧縮ヘッダの更新パターン変更を伝達するため。
３）ＮＡＣＫフィードバックの結果としてコンテキストを修復するため。
４）非圧縮ヘッダの非更新パターン変更を伝達するため。
５）頑強性を増加するためにコンテキストを周期的に「リフレッシュ」するため。
【００５３】
図示した一例のように、ＵＯＲ−２パケットは、その種類及び目的から例１に対して「通常」の優先順位で分類されるが、例２及び例３に対しては「重要」と分類され、例４及び例５に対しては「より重要でない」と分類される。
【００５４】
これは、「種類」及び「目的」の組合せに関して一般化され、通常、目的の知識は圧縮器により分類器に与えられる。
【００５５】
圧縮ヘッダの種類及び目的の少なくともいずれかの分類は、上記の好適な分類（例えば、「重要」、「通常」及び「より重要でない」）及びより一般化された分類に容易に適合可能である。
【００５６】
圧縮ヘッダの種類及び目的の少なくともいずれかの相対的な重要度に関連する情報は、上記の層において行なわれる分類を改良するために使用される。
【００５７】
あるいは、その情報はパケットの分類の主な方法及び／又は唯一の方法として直接使用される。
【００５８】
本発明の第１の面及び第２の面は組み合わされ、それぞれ上述されたように、リンクデータレートの変化が早期検出されることに応答してアプリケーションデータレートを直接適応させること及びデータパケットの分類に更に基づいてデータパケットを選択することの双方を使用する。
【００５９】
図６は、本発明の第１の面及び第２の面を組み合わせる好適な実施形態を概略的に示すフローチャートである。ユーザ機器は、監視されるスケジューリング情報に基づいてアップリンクチャネルのリンクデータレートの変化をローカルで検出する（Ｓ４１）。検出したリンクデータレートの変化の情報は、アプリケーション層に信号伝送され（Ｓ４２）、ユーザ機器において実行するＩＰアプリケーションのアプリケーションデータレートを適応させる（Ｓ４３）のに使用される。データパケットは、アップリンクチャネルを介する情報の転送に対する各パケットの相対的な重要度に基づいて分類される（Ｓ４４）。これにより、データパケットが検出されたリンクデータレートの変化に依存してスケジュール及びドロップの少なくともいずれかがなされるように、データパケットの分類に基づいてデータパケットを選択する（Ｓ４５）ことが可能になる。
【００６０】
図７は、本発明の第１の面に係る好適な実施形態を概略的に示すブロック図である。ＵＥ２００は、従来の無線トランシーバ機能性及び他の従来の無線通信ユニットを具備するが、それらについては更に詳細に説明しない。本発明に関係する部分を以下に説明する。ＵＥ２００は、ローカルレート変化検出器２１０と、アプリケーションレートを適応させるためのモジュール２２０と、１つ以上のデータバッファ２３０及びパケットスケジューラ２４０を含むリンク層パケットプロセッサ２５０とを更に具備する。検出器２１０は、基地局からのスケジューリングコマンドを監視し、スケジューリングコマンドから電力比情報等のスケジューリング情報を抽出するのが好ましい。この情報は、アップリンクチャネルのリンクデータレートの変化を検出するために検出器２１０により使用される。要望に応じて、利用可能な送信電力に関する情報は、検出器モジュール２１０に入力され、データレートの変化を検出するために電力比情報と共に使用される。あるいは、好ましくはデータバッファのパケットの蓄積を識別し且つバッファ蓄積をレートの変化に変換することにより、検出器２１０はデータバッファ２３０からのスケジューリング情報に基づいて動作する。通常、リンクデータレートの変化はアプリケーション層に信号伝送され、アプリケーション層は信号伝送されたリンクデータレートの変化に従ってモジュール２２０によりアプリケーションデータレートを適応させる。アプリケーションは、選択されたデータレートを使用して、適切なデータパケットにカプセル化されたアプリケーションデータをリンク層パケットプロセッサ２５０に転送する。リンク層パケットプロセッサ２５０において、データパケットはデータバッファ２３０にバッファリングされ、アップリンクチャネルを介する送信のためにパケットスケジューラ２４０によりスケジュールされる。アプリケーションデータレート及びリンクデータレートは、基本的に最適な性能に対応するのが好ましい。
【００６１】
図８は、本発明の第２の面に係る好適な実施形態を概略的に示すブロック図である。図７の実施形態と同様に、ＵＥ２００は、リンクデータレートの変化をローカルで検出するための検出器２１０と、データバッファ２３０及びパケットスケジューラ２４０を含むリンク層パケットプロセッサ２５０とを具備する。しかし、図８の実施形態において、ＵＥ２００はデータパケットの分類のための手段２２５を更に具備する。例えば上述したように、データパケットの分類は、アプリケーション層とヘッダ圧縮層等の下位層との少なくともいずれかにおいて実行される。パケット分類器２２５は、アップリンクチャネルを介するアプリケーションデータの転送に対する各パケットの相対的な重要度に基づいてデータパケットを分類するのが好ましい。この情報は、各パケットと共にリンク層パケットプロセッサ２５０に渡されるのが好ましい。分類は、リンクレートの変化に依存してデータバッファ２３０から重要度のより低いパケットをドロップすることと、パケットスケジューラ２４０において他のパケットの前により重要なデータパケットをスケジュールすることとの少なくともいずれかのために、リンク層パケットプロセッサ２５０により使用される。
【００６２】
図９は、本発明の第１の面及び第２の面を組み合わせる好適な実施形態を概略的に示すブロック図である。本実施形態において、上述のように、ＵＥはリンクデータレートの変化を直接検出するための検出器２１０を更に具備する。リンクレートの変化はアプリケーション層に信号伝送される。アプリケーション層において、モジュール２２０はアプリケーションデータレートを適応させるように動作する。アプリケーションは、モジュール２２５において相対的な重要度に従ってパケットを分類してもよい。あるいは、又は補完的役割として、このパケットの分類はヘッダ圧縮層において実装される。パケットの分類に関する情報は、データバッファ２３０とデータパケットスケジューラ２４０との少なくともいずれかと関連して送信するデータパケットを選択するために、リンク層パケットプロセッサ２５０により使用される。
【００６３】
任意の一般的なアップリンクチャネルに関連して本発明を主に説明してきた。以下においては、ＷＣＤＭＡ無線アクセスインタフェースを介してＩＰパケットを送信するためのＥ−ＤＣＨの特定の例を参照して本発明を説明する。しかし、本発明は、Ｅ−ＤＣＨにも以下の詳細な実装例にも限定されないことが理解されるべきである。
【００６４】
好適な一実施形態において、本発明は以下の複数の主なステップを含む。ＵＥは、使用された送信電力及び基地局からのスケジューリングコマンドを（直接）監視し、この情報に基づいてＥ−ＤＣＨデータレートの変化を直接検出するのが好ましい。通常、Ｅ−ＤＣＨデータレートに関するこの情報はアプリケーションに信号伝送され、アプリケーションはより適切なアプリケーションデータレートを選択できる。アプリケーションは、音声フレーム又はメディアフレームの損失がエラー隠蔽ユニットでどの程度隠蔽されるかに基づいてそれらフレームを分類するのが好ましい。通常、この情報は各パケットと共にＭＡＣ−ｅサブレイヤに渡される。ＭＡＣ−ｅはこの情報を使用して、より重要な音声フレーム又はメディアフレームに対する送信試行の回数を増加してもよい。パケットのドロップが必要な場合、ＲＬＣサブレイヤはパケットの分類を使用して、ドロップされるべきパケットを判定してもよい。
【００６５】
図１０は、本発明の一実施形態に係る特定の実装例を示す概略図である。この特定の実施形態は、音声符号化器を実装するＶｏＩＰアプリケーションに関する。ＶｏＩＰアプリケーションは、重要度に基づいて音声フレームを分類する。フレームは、ＲＬＣ（無線リンク制御）キュー及びＭＡＣ−ｅ（MAC enhanced）ＨＡＲＱ（ハイブリッドＡＲＱ）キューにバッファリングされる。最大の送信電力に到達すると、ＵＥ Ｅ−ＴＦＣＩ制限はＥ−ＤＰＤＣＨに対する送信電力を制限し、その結果として実際にはデータレートが低下する。ＭＡＣ−ｅは、遅いレートを使用することと、ロバストモード（フレーム間予測がより少ない）に入ることとの少なくともいずれかのために、ＶｏＩＰアプリケーションに信号伝送する。ＭＡＣ−ｅは、大量のキュー登録を防止するために最も重要でないパケットをドロップし、より重要なパケットに対して追加のリソースを費やす（例えば、追加の再送信により）のが好ましい。
【００６６】
詳細及び変形例を以下に説明する。
【００６７】
（Ｅ−ＤＣＨデータレートに対する変化の判定）
既存の技術は、リンク層データレートの変化を検出するためにブロック化／非ブロック化ＴＦＣを検出する方法（3GPP TS 25.133）に依存している。本発明において、「十分に大きな」Ｅ−ＴＦＣは依然として非ブロック化であり、余剰電力の要求によりＨＡＲＱ送信のブロック誤り率が増加し、更にはスループットを低下させる。
【００６８】
Ｅ−ＤＣＨを使用する場合、個別のＵＥのデータレートを制限できる機構が２つ存在する。第１に、基地局はサービング許可を更新することにより（すなわち、スケジュールすることにより）ＵＥの現在のデータレートを低下してもよい。第２に、ＵＥは現在のデータレートを維持するのに十分な送信電力を有さなくてもよく、この場合、ＵＥは送信レートを自動的に制限する。ＵＥがセルの端部に近い場合にこの自律的な低下は行なわれる。
【００６９】
同様に、個別のＵＥのレートはノードＢからのサービング許可を更新することにより増加されてもよく、あるいはＵＥの電力が制限される場合、ＵＥは十分な電力が利用可能になるとすぐに自律的にレートを増加してもよい。
【００７０】
レート低下機構及びレート増加機構の双方は、Ｅ−ＤＣＨにおいて費やされた送信電力の総量を判定するＥ−ＤＰＤＣＨ／ＤＰＣＣＨ電力比(βeで動作する。(βeを制限することにより、ＴＴＩ毎に送信されるビット数を制限することと、パケットを正常に送信するのに必要な再送信の回数を増加することとの少なくともいずれかが可能である。同様に、(βeを増加することにより、ＴＴＩ毎のビット数を増加することと、再送信の回数を減少することとの少なくともいずれかが可能である。現在のＥ−ＤＣＨ仕様（及び各ＭＡＣ−ｄフローに対して構成される）において、全てのトランスポートフォーマット（ＴＦ、すなわちＴＴＩ毎のビット）は特有のオフセット値(βeにマップする。従って、ＨＡＲＱ再送信の回数は以下の場合に変更される。
・ＵＥの電力が制限される場合。
・トランスポートフォーマットへのオフセットのマッピングが再構成される場合。
・参照チャネル（Ｅ−ＤＰＤＣＨ）のＳＩＲが変化した場合。
【００７１】
例えば、ＵＥは以下の２つの機構を介してＥ−ＤＣＨデータレートに関する情報を取得してもよい：
１．ＵＥは、Ｅ−ＡＧＣＨ及びＥ−ＲＧＣＨチャネルにおいて基地局から絶対許可及び相対許可を受信する。それら許可は、許容される最大のＥ−ＤＰＤＣＨ／ＤＰＣＣＨ電力比(βeに関する情報を含む。(βeの変化は、データレートの増加又は低下にマップされる。
２．ＵＥは、Ｅ−ＤＰＤＣＨを送信するのに利用可能な最大電力を推定する。ＵＥが現在の最大の(βeに到達するのに十分な電力を有さないと判定した場合、ＵＥは、3GPP TS 25.133で特定される規則に従って使用される(βeを減少する。この結果、ＨＡＲＱ再送信の回数及びキュー登録されたデータフレームの数が増加する。同様に、使用される(βeを減少した後、ＵＥがより大きな電力で送信するのに十分な電力を有し且つ使用される(βeを増加することを判定してもよい。
【００７２】
スループットの低下はバッファ蓄積を通して識別され、これは3GPP TS 25.133に関係する。この低下したスループットを識別すること及びＨＡＲＱドリフトからの回復を識別することは、提案された実施形態である測定機能である。
【００７３】
アプリケーション送出レートを適応させる周知の機構が存在する。アプリケーションは、バンド内（例えば、ＣＳ ＡＭＲの要求コーデックモード）又はバンド外（例えば、受信パケット損失とＲＴＣＰ受信者レポートのジッタとの少なくともいずれか、あるいはＲＴＣＰ−ＡＰＰレポートの適応情報）信号伝送を介してピアアプリケーションから情報を受け取れるか、あるいは受信信号強度を介してローカルリンクの品質を監視できる。そのような挙動の一例は、3GPP TS 25.133（第６．４．２節）において見つけられる。その例において、利用可能なビットレートが変化した時、ＭＡＣ層は上位層に報告する。その情報は、例えばより遅いコーデックレートを使用することにより又はアプリケーションにおいて音声フレームをドロップすることにより、アプリケーションデータレートを調整するために使用される。
【００７４】
（Ｅ−ＤＣＨレートの変化のアプリケーションへの信号伝送）
(βeは、許可される最大のトランスポートフォーマットコンビネーション（ＴＦＣ）を判定する。各ＴＦＣは、端末がＴＴＩ毎に送信可能なビット数を含むが、再送信のために、ＴＦＣはアプリケーション層ビットレートに直接変換できない。しかし、アプリケーションレベルのデータレートは(βeの値に正比例するため、相対的なレートの変化をアプリケーションに信号伝送できる。例えば(βeが半分に低下した場合、ＭＡＣ−ｅエンティティは、データレートが半分に低下したことをアプリケーション層に信号伝送する。
【００７５】
アプリケーションは、この（相対的な）データレートを使用して、符号化処理に使用する符号化モード又はビットレートを判定する。
【００７６】
一実施形態（ＡＭＲによるＶｏＩＰ）において、ＶｏＩＰアプリケーションは、使用するコーデックモード及び冗長モードの少なくともいずれかを判定すると、その（相対的な）データレート（Ｅ−ＤＣＨからの）を使用し、それを他のＵＥから受信されるコーデックモード要求（ＣＭＲ）と組み合わせる。組み合わせでは、最高それら２つのビットレート（又はコーデックモード）となる。
【００７７】
別の一実施形態（テレビ電話）において、アプリケーションは、使用するビットレート及びフレームレートの少なくともいずれかを判定する時にその（相対的な）データレート（Ｅ−ＤＣＨからの）を使用する。
【００７８】
別の一実施形態において、アプリケーションはサポートされるサービスコンポーネント（例えば、音声、ビデオ、テキスト）を判定するためにその（相対的な）データレートを使用する。現在使用されているコンポーネントがこれ以上サポートされないことを検出すると、アプリケーションはそのコンポーネントを除去できる。同様に、現在使用されていないコンポーネントがサポートされることを検出すると、アプリケーションはそのコンポーネントを通話に追加できる（可能性として、ユーザからのフィードバックに基づいて）。
【００７９】
尚、必要とされる送信電力が時間内に大きく変動することがあるため、フィルタリングされたレート又は平均レートがアプリケーションに信号伝送される必要があることが予想される。例えば3GPP TS 25.133は、必要とされるＵＥ送信電力が２０ｍｓの時間に対応する評価の直前の連続する３０スロット（２／３ｍｓ）のうち少なくとも１５スロットの間に最大ＵＥ送信機電力を上回る場合、ＴＦＣが余剰電力状態にあることを特定する。ＴＦＣは、５０〜９０ｍｓ（又はそれ以上）の間余剰電力状態であった場合にブロック化される。Ｅ−ＤＣＨの場合、同様の手順が使用できるが、測定期間は１０〜２０ｍｓ程度のより短い期間であると予想される。
【００８０】
（メディアフレームの分類）
メディアフレームは、いくつかの方法で分類される。
【００８１】
いくつかのサービスコンポーネント（音声、ビデオ、テキスト）がサポートされている場合、１つのコンポーネントからのフレームは他からのコンポーネントより絶対的に高い優先度を有することができる。
【００８２】
単一のサービスコンポーネント内において、フレームは、例えば歪みに基づくマーキングにより分類される。このマーキングは、損失により発生する歪み量を評価しようとする。歪みに基づくマーキングに関する更なる情報は、音声通信に対する文献「Source-Driven Packet Marking For Speech Transmission Over Differentiated-Services Networks」Juan Carlos De Martin、IEEE International Conference on Audio, Speech and Signal Processing、Salt Lake City、USA、２００１年５月において見つけられるが、他の実装例（例えば、ビデオに対する）も可能である。
【００８３】
最も単純な分類の結果、２つの異なる種別（例えば「重要」及び「通常」）に分類されるが、好適な実施形態においては、「重要」、「通常」及び「より重要でない」の３つの異なる品質種別が使用されると推測される。より多くの種別に対する一般化が可能であり、それが望ましい場合がある。
【００８４】
（メディアフレームを含むサービスデータユニットの分類）
無線リソースを節約するために、通常、ＩＰヘッダ圧縮がメディアフレームの転送に使用されるＩＰパケットに適用される。通常、ロバストヘッダ圧縮（ＲＯＨＣ、ＲＦＣ３０９５を参照）等のヘッダ圧縮は、異なる種類の圧縮ヘッダ、すなわち新しい伸張コンテキスト（ＲＯＨＣ ＩＲパケット）を初期化するための（又は既存の伸張コンテキストを再開するための）より大きなヘッダ及びより小さな圧縮ヘッダを規定する。ここで、ヘッダの各種類は、圧縮されるプロトコルヘッダの種々のフィールドの変更の可能性に基づいて情報の異なる組合せを搬送する。
【００８５】
ＩＲパケットは、非圧縮ＩＰヘッダとほぼ同一の大きさであるが、本来、例えばペイロードとして含まれるメディアフレームと比較して相対的に大きくてもよい。通常、ＲＴＰ／ＵＤＰ／ＩＰｖ４ヘッダの大きさは４０オクテットであり、ＲＴＰ／ＵＤＰ／ＩＰｖ６ヘッダの大きさは６０オクテットである。ＩＲパケットは、フローに対して変更されないと予想されるフィールドである静的フィールドと、変更されると予想されるフィールドである動的フィールドとを含む。ＩＲパケットは、新しいコンテキストを初期化するために圧縮の開始時に送出され、致命的な伸張失敗から回復するために伸張器（双方向動作）からの要求（static NACK）時に又は周期的に後で送出されてもよい。
【００８６】
ある程度小さなＩＲ−ＤＹＮは、静的なヘッダ情報を除いて全ての動的な情報のみを搬送する。その大きさは約１８〜２０オクテット（ＩＰｖ４／ＩＰｖ６）である。圧縮器と伸張器との間の動的なコンテキスト情報の同期外れが繰り返される伸張失敗の原因と仮定される場合、ＩＲ−ＤＹＮパケットはその伸張失敗から回復するために有用である（例えば、ＮＡＣＫが双方向動作において受信された場合に送信される）。更にＩＲ−ＤＹＮパケットは、例えば単一方向動作においてコンテキストをリフレッシュするために周期的に使用されてもよい。
【００８７】
圧縮率が最適な場合、より小さなパケットが送出される。それらパケットの種類に対する圧縮ヘッダは、１オクテット（ＩＰｖ４、ＵＤＰチェックサム無効）又は３オクテット（ＩＰｖ６）から最大１８オクテットまでの範囲である。
【００８８】
通常、例えば新しいコンテキストを作成するため、伸張失敗に対する頑強性を維持するため、先の失敗から回復するため及びコンテキストの要素を更新するため（例えば、元のヘッダの変更パターンが確立されたパターンに準拠していない時）にアルゴリズムが必要とする場合にのみ、より大きなヘッダはヘッダ圧縮を使用して送出される。
【００８９】
通常、ヘッダ圧縮は、ＩＰ層の下で、すなわちアプリケーション層とＭＡＣ層との間のいずれかの場所において行なわれる。１つのサービスコンポーネントに対応する単一のヘッダ圧縮フロー内において、サービスデータユニット（ＳＤＵ）は例えばコンテキストの同期に対する相対的な影響力により分類される。特に、圧縮ヘッダの種類は互いに対する相対的な重要度を有しているため分類できる。例えば、ＲＯＨＣの場合、ＩＲパケットは最も重要であり、ＩＲ−ＤＹＮ及びＵＯＲ−２パケットはより小さいパケット（ＰＴ−１及びＰＴ−０）より重要である。
【００９０】
圧縮ヘッダの種類の分類は、上記の好適な分類（例えば、「重要」、「通常」及び「より重要でない」）及びより一般化された分類に容易に適合可能である。
【００９１】
圧縮ヘッダの種類の相対的な重要度に関連する情報は、上記の層において行なわれる分類を改良するために使用される。あるいは（上位層が分類情報を提供しない場合又は要望に応じて）、相対的な重要度が高い圧縮ヘッダの種類（例えば、ＩＲ，ＩＲ−ＤＹＮ、ＵＯＲ−２）を含むＳＤＵの送信が成功する可能性を高くする目的か、又はキューを管理し、ヘッダ圧縮アルゴリズムにとって相対的な重要度が低く且つより小さなヘッダのみを有する第１のパケットをドロップする時点かに、その情報は分類方法として直接使用される。
【００９２】
上述したように、パケット自体の種類（すなわち、そのパケット自体が行なえ且つ情報として保持できるもの）に対してだけでなく、パケットの目的（すなわち、ヘッダ圧縮アルゴリズムがそのパケットを選択した理由）に関してヘッダ圧縮パケットの重要度の分類を一般化できる。換言すると、例えば故障事象（受信したフィードバック等）及びロバストネスの論理から、伸張器コンテキストの状態の圧縮器の「ビュー」を含むように分類を拡大するのが望ましい。
【００９３】
ＲＯＨＣが好適なヘッダ圧縮アルゴリズムであるが、概念はＲＯＨＣに限定されず、任意の他のヘッダ圧縮アルゴリズムに適用可能である。特にそれらアルゴリズムは、ＲＦＣ１１４４、ＲＦＣ２５０７、ＲＦＣ２５０８、ＲＦＣ３０９５、ＲＦＣ３５４５、ＲＦＣ３８４３、ＲＦＣ４０１９、ＲＦＣ４１６４、IETF draft「The Robust Header Compression (ROHC) Framework」２００６年１１月２９日、IETF draft「Robust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP Lite」２００６年９月６日、並びにIETF draft「Robust Header Compression (ROHC): A profile for TCP/IP (ROHC-TCP)」２００６年１２月１１日により規定される。
【００９４】
（重要なフレームの送信の向上）
ＵＥは、ＨＡＲＱ ＰＤＵを送信し続けることにより送信が成功する可能性を高めることができる。しかし、これはアプリケーション層が利用可能なデータレートを低下させるため、ＭＡＣ−ｅエンティティは「重要」と分類されたパケットから開始して選択されたパケットに対してのみそれを行なうべきである。また、パケットをドロップする必要がある場合もあり、その場合、「より重要でない」と分類されたパケットが「通常」及び「重要」と分類されたパケットの前にドロップされるべきである。
【００９５】
（ＲＬＣキューの能動的な管理）
従来の品質を保持するために、ＲＬＣサブレイヤにおいてキューが大きくなりすぎるのを防止する必要がある。最も単純には、これは、最低の優先度（例えば、「より重要でない」）を有するとして分類されたパケットをまずドロップし、より高い優先度を有するパケットのドロップを続けて行なうことにより達成される。
【００９６】
本発明により、Ｅ−ＤＣＨ機能を介する音声は向上する。特に本発明は、輻輳したシステムにおいて種々の無線条件（例えば、有効範囲の境界）でＥ−ＤＣＨ動作を介するＶｏＩＰを向上する。
【００９７】
上述の実施形態は単なる例として与えられており、本発明はそれらに限定されないことが理解されるべきである。本明細書において開示され且つ請求される基本原理を保持する更なる変形、変更及び改良は本発明の範囲内である。
【００９８】
（略語）
ＩＰ   インターネットプロトコル
ＩＰｖ４  ＩＰバージョン４
ＩＰｖ６  ＩＰバージョン６
ＶｏＩＰ  Voice over IP
Ｅ−ＤＣＨ  拡張専用チャネル
ＷＣＤＭＡ  広帯域符号分割多元接続
ＨＳＤＰＡ  高速パケットデータアクセス
ＡＭＲ  適応マルチレート
ＴＴＩ  送信時間間隔
ＡＲＱ  自動再送要求
ＨＡＲＱ  ハイブリッドＡＲＱ
ＵＥ   ユーザ機器
ＤＰＣＣＨ  専用物理制御チャネル
Ｅ−ＤＰＤＣＨ Ｅ−ＤＣＨ専用物理データチャネル
ＭＡＣ  媒体アクセス制御
ＭＡＣ−ｄ  MAC dedicated
ＭＡＣ−ｅ  MAC enhanced
ＲＬＣ  無線リンク制御
ＴＦ   トランスポートフォーマット
ＴＦＣ  トランスポートフォーマットコンビネーション
Ｅ−ＴＦＣ  拡張ＴＦＣ
ＳＩＲ  信号対干渉比
ＲＴＰ  リアルタイム転送プロトコル
ＲＴＣＰ  ＲＴＰ制御プロトコル
ＲＴＣＰ−ＡＰＰ アプリケーション定義ＲＴＣＰパケット
Ｅ−ＡＧＣＨ  Ｅ−ＤＣＨ絶対許可チャネル
Ｅ−ＡＧＣＨ  Ｅ−ＤＣＨ相対許可チャネル
ＣＭＲ  コーデックモード要求
ＰＤＵ  プロトコルデータユニット
ＳＤＵ  サービスデータユニット
ＲＯＨＣ  ロバストヘッダ圧縮
ＩＲ   初期化及びリフレッシュ
ＩＲ−ＤＹＮ  ＩＲ動的部分
ＵＯＲ−２  パケットタイプ２、Ｕ／Ｏ／Ｒモードに共通
ＰＴ−１  パケットタイプ１
ＰＴ−０  パケットタイプ０
【図面の簡単な説明】
【００９９】
【図１】ユーザ機器と通信している基地局を例示する簡単化された無線通信システムを概略的に示す図である。
【図２】本発明の第１の面に係る基本的な方法の一例を概略的に示すフローチャートである。
【図３】本発明の第１の面に係る好適な一実施形態を更に詳細に示すフローチャートである。
【図４】本発明の第２の面に係る基本的な方法の一例を概略的に示すフローチャートである。
【図５】本発明の第２の面に係る好適な一実施形態を更に詳細に示すフローチャートである。
【図６】本発明の第１の面及び第２の面を組み合わせる好適な一実施形態を概略的に示すフローチャートである。
【図７】本発明の第１の面に係る好適な一実施形態を概略的に示すブロック図である。
【図８】本発明の第２の面に係る好適な一実施形態を概略的に示すブロック図である。
【図９】本発明の第１の面及び第２の面を組み合わせる好適な一実施形態を概略的に示すブロック図である。
【図１０】本発明の一実施形態に係る特定の実装例を示す概略図である。
【図１】
2009526432.tif 000003
【図２】
2009526432.tif 000004
【図３】
2009526432.tif 000005
【図４】
2009526432.tif 000006
【図５】
2009526432.tif 000007
【図６】
2009526432.tif 000008
【図７】
2009526432.tif 000009
【図８】
2009526432.tif 000010
【図９】
2009526432.tif 000011
【図１０】
2009526432.tif 000012
【国際調査報告】
2009526432.tif 000013
2009526432.tif 000014
2009526432.tif 000015