JP2015520533A - 移動通信ネットワークのスケジューリングリクエストリソースを割り当てる方法 - Google Patents

Abstract

【課題】ＳＲリソースの使用率を増加し、且つＱｏＳを得る。【解決手段】移動通信ネットワークでユーザー端末（ＵＥ）と基地局によって 無線リソース制御（ＲＲＣ）接続を確立するステップ、スケジューリングリクエスト（ＳＲ）リソースの割り当てに関連する補助情報を基地局に提供するステップ、および前記補助情報に応じて前記基地局から、ＳＲリソース割り当て用のＳＲ周期とＳＲオフセットと関連するスケジューリングリクエスト（ＳＲ）設定を受信するステップを含む方法。【選択図】 図１３

Description

本発明は、移動通信ネットワークに関し、特に、サービス品質（ＱｏＳ）リクエストを維持しながらスケジューリングリクエストリソースを割り当て、スケジューリングリクエストの使用率を増加させることに関するものである。

ロングタームエボリューション（ＬＴＥ）システムは、高ピークデータレート、低遅延、改善されたシステム容量が多くのオペレータによって用いられる。ＬＴＥシステムにおいて、発展型ユニバーサル地上波無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ：Ｅｖｏｌｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）は、ＬＴＥ−Ｕｕインターフェースを介して、複数の移動局と通信する、ユーザー端末（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔｓ）と呼ばれる複数の発展型ノードＢ（ｅＮＢｓ：ｅｖｏｌｖｅｄ Ｎｏｄｅ−Ｂｓ）を含む。無線アクセスネットワークは、移動管理エンティティ（ＭＭＥ）、サービングゲートウェイ（Ｓ−ＧＷ）、およびパケットデータネットワークゲートウェイ（Ｐ−ＧＷ）を含むコアネットワーク（ＣＮ）と更に接続し、エンドツーエンドのサービスを提供する。ＬＴＥネットワークはシステム容量を増加させており、すぐに容量の問題に直面することが予測される。携帯電話加入者の指数関数的な増加は、ネットワーク容量の大幅な増加を必要とする。ユーザー数が急増するこの問題と同時に、例えばｉＰｈｏｎｅ、Ａｎｄｒｏｉｄフォン、およびＢｌａｃｋｂｅｒｒｙフォンユーザーなどのスマートフォンの加入者の急激な機種の上位化もある。

例えば、ニュース、天気、およびソーシャルネットワーキングなどの多くのスマートフォンのアプリケーションは、更新用に定期的にネットワークと接続、またはネットワークから切断する。これらのアプリケーションは、大量のシグナリングトラフィックをなお必要とすると同時に、少量のユーザーデータを含んで、セッションの確立と解除をする。結果、コアネットワークは、ＵＥをスマートフォンのアプリケーションに接続した状態にする。多様なデータアプリケーション（ＤＤＡ）（バックグラウンド／ＩＭ）環境において、ＵＥを無線リソース制御（ＲＲＣ）接続モードに保持することになり、ＲＲＣ遷移を防止する。より小さいＲＲＣ遷移は、不連続受信（ＤＲＸ）が適切に設定されている場合、同様の省電力性能を有する。

しかしながら、物理アップリンク制御チャネル（ＰＵＣＣＨ）のための無線リソース使用率は、接続されたＵＥの数が増加した時、特にスケジューリングリクエスト（ＳＲ）リソースがＰＵＣＣＨに割り当てられた時、問題になる。これは、ＳＲリソースが専用のリソースであり、且つ周期的であるため、ＳＲリソースの浪費は、接続されたＵＥの数の増加に伴い、線形的に増加する。例えば、１０ＭＨｚ（５０個の物理リソースブロック（ＰＲＢ））の帯域幅で、３００のＵＥが全て接続されている場合、ＰＵＣＣＨの割り当ては、ＳＲ周期が５ｍｓの時、８個のＰＲＢを必要とする。８個のＰＲＢの中、ＳＲの使用率（使用されているリソース）は、バックグランドトラフィックにおいて０.０４％だけである。ＳＲ周期が５ｍｓから８０ｍｓに延伸された時でも、ＳＲリソースの使用率は、０.６７％だけである。また、より長いＳＲ周期を用いて直接使用率を増加させる時、割り当ては、アクセス遅延を大きく増加させる。より多くのリソースがＳＲに確保されている場合、より少ないリソースが物理アップリンク制御チャネル（ＰＵＣＣＨ）を介してアップリンクデータ伝送に使用可能となり、アップリンク容量を減少する。そのため、トラフィックがより多様になった時、従来の単一のＳＲリソース割り当ての方式は、ネットワークおよびＵＥリクエストを十分に、または効果的に満たすことができない可能性がある。

本発明の目的は、ＳＲリソースの使用率を増加し、且つＱｏＳを得ることであり、その解決法が求められている。

ＰＵＣＣＨのスケジューリングリクエスト（ＳＲ）リソースは、ＵＥがアップリンクデータ用にＳＲ指示を送信するように基地局によって割り当てられる。ＳＲリソースは、専用であり周期的である。各種の方式が本発明に提供され、ＳＲリソースの割り当てをトラフィックパターンに適応させることによってＳＲリソースの使用率を向上させる。

第１の方式では、ＳＲリソースの割り当ては、ＵＥによって提供された補助情報に基づいてより正確に設定される。ＵＥは、ｅＮＢに補助情報を提供し、受信した補助情報に基づいてＳＲ設定を決定または調整する。ＳＲ設定は、ＳＲ周期とＳＲオフセットに関連付けされたＳＲ設定インデックスを含む。１つの例では、補助情報は、ＵＥに望ましい（ＵＥ−ｐｒｅｆｅｒｒｅｄ）ＳＲ設定インデックスを含む。もう１つの例では、補助情報は、ＵＥに望ましいＳＲ周期／オフセット、および／またはパケット到着間隔（ＩＡＴ）に関連したトラフィックパターン情報を含む。ＵＥは、ＱｏＳリクエスト、トラフィックパターン統計、およびＤＲＸ設定などの考慮に基づき、補助情報を提供するため、ｅＮＢは、より正確にＳＲリソースを割り当てることができる。ＵＥは、更にリクエストメッセージを送信し、ＳＲ割り当てを解除する。

第２の方式では、複数のＳＲ周期が設定され、トラフィックパターンに適応される。基地局は、複数のＳＲ周期を用いてセットのＳＲリソースを設定し、ＵＥは、所定のトリガーイベントに基づいて異なるＳＲ周期を用いる。１つの例では、トリガーイベントは、ＳＲ設定によって設定されたＳＲタイマーに基づく。もう１つの実施形態では、トリガー条件は、特定のアプリケーション用のアップリンクデータが基地局に送信された時、満たされる。トリガー条件は、不連続受信（ＤＲＸ）の動作状態に基づくこともできる。１つの有利な実施形態では、ＰＵＣＣＨの未使用のＳＲリソースは、他のＵＥ用に、または物理アップリンク共有チャネル（ＰＵＳＣＨ）のデータ伝送用にリサイクルされることができる。異なるＳＲ周期のＳＲリソースを設定することによって、ＳＲリソースの使用率は、トラフィックパターンに適応される。

第３の方式では、複数のＳＲ割り当てが設定され、関連したアプリケーションに適用される。基地局は、所定のアプリケーションに適応された複数のセットのＳＲリソースを設定し、ＵＥは、対応するアプリケーションに基づいてＳＲ設定を用いる。複数の予め割り当てられたＳＲリソースが決定され、アプリケーションのサービス品質（ＱｏＳ）リクエストを満たす。１つの実施形態では、割り当てられたＳＲ無線リソースは、アプリケーションの開始および／または停止に基づき、アクティブ化または非アクティブ化される。複数の予め割り当てられたＳＲ設定でＳＲリソースの使用は、関連するアプリケーションに適応される。

他の実施形態及び利点が以下に詳細に説明される。この概要は、本発明を限定するものではない。本発明は請求項によって限定される。

図１は、１つの新しい実施形態に基づく無線通信システムのＳＲリソースの使用率を向上させるいくつかの方式を示す図である。 図２は、本発明の特定の実施形態をサポートするＵＥおよびｅＮＢの簡略化したブロック図である。 図３は、ＳＲ周期およびＳＲオフセットと関連したＳＲ設定インデックスを示す図である。 図４は、望ましいＳＲ設定インデックスをＵＥからｅＮＢに提供する第１の実施形態を示す図である。 図５は、トラフィックパターンとＳＲリソース割り当てと関連した関連パラメータを示す図である。 図６は、ＳＲリソース割り当て用のＵＥからｅＮＢに補助情報を提供する第２の実施形態を示す図である。 図７は、２つの異なるＳＲ周期を有するＳＲ設定を示す図である。 図８は、適応性のＳＲ設定の方法を示す図である。 図９は、ＳＲリソースのリサイクルを有する適応性のＳＲ設定の方法を示す図である。 図１０は、ＰＵＳＣＨのデータ伝送に用いられることができる仮想のＰＵＣＣＨを示す図である。 図１１は、異なるアプリケーションに対応する異なるＳＲ設定を示す図である。 図１２は、所定のアプリケーションの複数のＳＲ設定を設定する方法を示す図である。 図１３は、１つの新しい実施形態に基づくＳＲリソース割り当て用の補助情報を提供する方法のフローチャートである。 図１４は、１つの新しい実施形態に基づくＳＲ設定の適応およびＳＲリソースのリサイクルを用いる方法のフローチャートである。 図１５は、１つの新しい実施形態に基づく所定のアプリケーションの複数のＳＲ設定を設定する方法のフローチャートである。

以下、本発明の様々な実施形態を詳細に説明する。その実施形態は添付図面に例証されている。

図１は、１つの新しい実施形態に基づく無線通信システム１００のスケジューリングリクエスト（ＳＲ）リソースの使用率を向上させるいくつかの方式を示している。無線通信システム１００は、ユーザー端末ＵＥ１０１と基地局ｅＮＢ１０２を含む。ＬＴＥシステムでは、物理アップリンク共有チャネル（ＰＵＳＣＨ）は、ＵＥ１０１からｅＮＢ１０２にアップリンクデータを搬送するように用いられ、物理アップリンク制御チャネル（ＰＵＣＣＨ）は、ダウンリンク伝送、スケジューリングリクエスト（ＳＲ）、およびチャネル品質表示（ＣＱＩ）報告に応じて、自動再送リクエスト（ＡＲＱ）またはハイブリッド再送リクエスト（ＨＡＲＱ）などの各種のアップリンク制御情報を搬送するように用いられる。ＵＥ１０１がｅＮＢ１０２に送信されるアップリンクデータを有する時、ＵＥ１０１は、ＰＵＣＣＨの割り当てられたＳＲリソースによってＳＲ指示をｅＮＢ１０２に送信し、それに応じてｅＮＢ１０２からアップリンクグラントを受信し、アップリンクデータがＰＵＳＣＨによってＵＥ１０１からｅＮＢ１０２に伝送されることができる。

多様なデータアプリケーション（ＤＤＡ）（バックグラウンド／ＩＭ）環境において、ＵＥを無線リソース制御（ＲＲＣ）接続モードに保持することになり、ＲＲＣ遷移を防止する。より小さいＲＲＣ遷移は、不連続受信（ＤＲＸ）が適切に設定されている場合、同様の省電力性能を有する。しかしながら、ＰＵＣＣＨに割り当てられたＳＲリソースは、ＲＲＣ接続モードの各ＵＥ専用であり、周期的である。そのため、ＳＲリソースの浪費は、ＲＲＣ接続モードの複数のＵＥの数の増加に伴い、線形的に増加する。ほとんどのＵＥがＲＲＣ接続モードで保持された時、長いＳＲ周期設定（例えば、ＳＲ周期＝８０ｍｓ）を用いても、ＳＲリソースの使用率は、なお非常に低い（例えば、０.６７％）。また、長いＳＲ周期は、アクセス遅延を大きく増加させる。

１つの新しい実施形態では、各種の方式は、ＳＲリソース割り当てをトラフィックパターンに適応させることによって、ＳＲリソースの使用率を向上させる。図１に示されるように、第１の方式＃１では、ＳＲリソース割り当てはより正確に設定される。例えば、ＵＥ１０１は、補助情報を提供し、ｅＮＢ１０２は、受信した補助情報に基づいてＳＲ設定を決定または調整する。第２の方式＃２では、ＳＲ周期は、トラフィックパターンに適応される。例えば、ｅＮＢ１０２は、複数のＳＲ周期を用いて１セットのＳＲリソースを設定し、ＵＥ１０１は、所定のイベントに基づいて異なるＳＲ周期を用いる。未使用のＳＲリソースは、ＰＵＳＣＨのデータ伝送用にｅＮＢ１０２によってリサイクルされることができる。第３の方式＃３では、複数のＳＲ割り当ては、関連したアプリケーションに適用される。例えば、ｅＮＢ１０２は、所定のアプリケーションに適応された複数のセットのＳＲリソースを設定し、ＵＥ１０１は、対応するアプリケーションに基づいてＳＲ設定を用いる。追加のＳＲ設定は、対応するアプリケーションの開始および／または停止に基づいてアクティブ化および／または非アクティブ化されることができる。

図２は、本発明の特定の実施形態をサポートするＵＥ２０１およびｅＮＢ２０２の簡略化したブロック図である。アンテナ２２５は、ＲＦ信号を送受信する。ＲＦトランシーバモジュール２１１は、アンテナ２２５と接続され、アンテナからＲＦ信号を受信し、受信したＲＦ信号をベースバンド信号に変換し、それらをプロセッサ２１２に送信する。ＲＦトランシーバ２１１は、プロセッサ２１２から、受信したベースバンド信号を変換し、変換した信号をＲＦ信号に変換してアンテナ２２５に送出する。プロセッサ２１２は、受信したベースバンド信号を処理し、異なる機能モジュールを呼び出し、ＵＥ２０１の機能を実行する。メモリ２１３は、プログラム命令とデータ２１４を保存し、ＵＥ２０１の動作を制御する。

同様の設定がｅＮＢ２０２に存在し、アンテナ２４５は、ＲＦ信号を送受信する。ＲＦトランシーバモジュール２３１は、アンテナ２４５と接続され、アンテナからＲＦ信号を受信し、受信したＲＦ信号をベースバンド信号に変換し、それらをプロセッサ２３２に送信する。ＲＦトランシーバ２３１は、プロセッサ２３２から、受信したベースバンド信号も変換し、変換した信号をＲＦ信号に変換してアンテナ２４５に送出する。プロセッサ２３２は、受信したベースバンド信号を処理し、異なる機能モジュールを呼び出し、ｅＮＢ２０２の機能を実行する。メモリ２３３は、プログラム命令とデータ２３４を保存し、ｅＮＢ２０２の動作を制御する。

図２は、本発明の実施形態を実行するＵＥ２０１およびｅＮＢ２０２の機能モジュールも示している。例えば、ＲＲＣ管理モジュール２２１と２４１は、ＲＲＣ状態を管理し、ＲＲＣ接続のステップを実行し、且つＲＲＣシグナリング用にＲＲＣ接続を保持する。状態収集モジュール２２２は、異なるアプリケーションと関連する各種のトラフィックパターンのトラフィック統計を収集する。ＳＲ適応モジュール２２３は、ｅＮＢ２０２からＳＲ設定を受け（ＳＲ設定モジュール２４３によって）、必要な場合、ＳＲ設定に適応させる。アプリケーションモジュール２２４は、ＵＥ２０１で動作する各種のアプリケーションを管理する。異なる機能モジュールは、ソフトウェア、ファームウェア、ハードウェア、またはその組み合わせによって実行されることができる。例えば、機能モジュールがプロセッサ２１２と２３２によって実行された時（例えばプログラムコード２１４と２３４を実行することによって）、ＵＥ２０１に収集させ、補助情報となるトラフィック統計をｅＮＢ２０２に提供し、受信した補助情報に基づき、ＱｏＳリクエスト（ＱｏＳ管理モジュール２４２によって）にも基づいて、ＵＥ２０１にＳＲリソース割り当てを設定させ、且つそれに応じてＵＥ２０１にＳＲ設定を用いて適応させ、ＱｏＳを保持しながらＳＲリソースの使用率を向上させる。

図３は、ＳＲ周期およびＳＲオフセットと関連したＳＲ設定インデックスを示している。ＬＴＥシステムでは、情報要素（ＩＥ）ＳｃｈｅｄｕｌｉｎｇＲｅｑｕｅｓｔＣｏｎｆｉｇは、ＳＲの周期性およびＳＲサブフレームオフセットを含むＳＲパラメータを特定するように用いられ、対応するＳＲ設定インデックスと関連する。図３の表３００に示されるように、ＳＲの伝送周期性ＳＲ_{ＰＥＲＩＯＤＩＣＩＴＹ}とＳＲのサブフレームオフセットＮ_{ＯＦＦＳＥＴ}用のＳＲ設定は、上層より与えられたパラメータｓｒ−ＣｏｎｆｉｇＩｎｄｅｘ およびＩ_ＳＲによって表３００に定められる。ＳＲ設定インデックスは、０〜１５７であり、各インデックスは、ＳＲの周期性（例えば、１ｍｓ〜８０ｍｓのＳＲ_{ＰＥＲＩＯＤＩＣＩＴＹ}）とＳＲのサブフレームオフセット（例えば、Ｉ_ＳＲが上層より与えられるＮ_{ＯＦＦＳＥＴ}）に対応する。ＳＲ伝送の例は、式：（１０ｘＮｆ ＋ ［Ｎｓ／２］） ｍｏｄ ＳＲＰＥＲＩＯＤＩＣＩＴＹ ＝ ０、を満たすアップリンクサブフレームであり、その中のＮｆは、システムフレーム番号であり、Ｎｓは、スロット番号である。

伝統的に、ｅＮＢは、ＱｏＳリクエストに基づいてＳＲ設定を割り当てるが、コアネットワークから受信したＱｏＳリクエストは、ｅＮＢがＳＲリソース割り当てのための最良の解決を決定するのに十分でない可能性がある。例えば、ＵＥは、ｅＮＢが長いパケット到着間隔（ｉｎｔｅｒ−ａｒｒｉｖａｌ−ｔｉｍｅ；ＩＡＴ）を有するトラフィック用に短いＳＲ周期を割り当てるのを避けることができ、ＵＥは、ｅＮＢがＳＲオフセットと第２の層（Ｌ２）のバッファに入るアップリンクデータのタイミングをより正確に位置合わせするのを助ける。１つの新しい実施形態では、トラフィックパターンとＵＥ知能（ｉｎｔｅｌｌｉｇｅｎｃｅ）に応じて、ＵＥは、その望ましいｓｒ−ＣｏｎｆｉｇＩｎｄｅｘをｅＮＢに、特にＳＲオフセットにフィードバックすることができる。

図４は、望ましいＳＲ設定インデックスをＵＥからｅＮＢに提供する第１の実施形態を示している。ステップ４１１では、ＵＥ４０１は、ｅＮＢ４０２から第１のＳＲ設定＃１を受信する。第１のＳＲ設定は、ＳＲ周期とＳＲオフセットと関連した第１のｓｒ−ＣｏｎｆｉｇＩｎｄｅｘを含む。しかしながら、このようなＳＲ設定は、ＵＥ４０１に望まれない可能性がある。例えば、ＵＥ４０１は、ＳＲの使用を評価し、低い使用率（ｐｏｏｒ ｕｔｉｌｉｚａｔｉｏｎ）を見つける。このため、ＵＥ４０１は、フィードバックを初期化することができる。ＵＥ４０１は、基準のリストに応じてＳＲの適当な周期性とオフセットを決定する。第１に、ＵＥ４０１は、実行アプリケーションのＱｏＳリクエストを考慮することができる。第２に、ＵＥ４０１は、トラフィックパターンの履歴（ｈｉｓｔｏｒｙ）を考慮し、Ｌ２バッファに入るユーザーデータのタイミングを予測する。第３にＵＥ４０１は、そのＤＲＸ設定を考慮することができる。例えば、ＳＲリソースは、ＤＲＸ動作の期間に、またはＤＲＸ動作の期間のわずか前に割り当てられることができる。ＤＲＸ設定は、ＵＥアクティブ期間（Ａｃｔｉｖｅ Ｔｉｍｅ）を減少する利点を有するため、ＵＥの電力消費を節約するが、より長い遅延も発生させる。そのため、ＳＲの周期性をＤＲＸサイクルと位置合わせすることが望ましい。例えば、ＳＲ周期の値の範囲は、１、２、５、１０、２０、４０、および８０であり、短ＤＲＸサイクルの値の範囲は、２、５、８、１０、１６、２０、３２、４０、６４、８０、１２８、１６０、２５６、３２０、５１２、および６４０である。ＳＲ設定がＤＲＸ ｃｙｃｌｅ ＝ ｎ ^＊ ＳＲ ｐｅｒｉｏｄを満たすならば望ましい。このような決定がされた後、ステップ４１２では、ＵＥ４０１は、その望ましいｓｒ−ＣｏｎｆｉｇＩｎｄｅｘをｅＮＢ４０２に送信する。望ましいｓｒ−ＣｏｎｆｉｇＩｎｄｅｘは、ＲＲＣシグナリングメッセージによって（例えばボックス４２１に表される）、またはメディアアクセス制御（ＭＡＣ）の制御要素（ＣＥ）（例えば、ボックス４２２に表される）によって送信されることができる。ＵＥの望ましいｓｒ−ＣｏｎｆｉｇＩｎｄｅｘを受信した後、ｅＮＢ４０２は、現在のＰＵＣＣＨの負荷と使用可能なリソースを考慮することができ、ＳＲ設定を調整するかどうか決定する。調整する場合、ステップ４１３では、ｅＮＢ４０２は、第２のＳＲ設定＃２をＵＥ４０１に送信し、ＳＲ設定を調整する。または、ｅＮＢ４０２は、明示的に拒絶メッセージを無視するか、または送信することによって、提案を拒絶することができる。

望ましいＳＲ設定インデックスの送信に加え、ＵＥは他の補助情報をｅＮＢに報告し、ＳＲリソースの設定の正確さを向上させる。異なるタイプの補助情報がある。一般的に、ＵＬのパケット到着間隔（ＩＡＴ）の情報は、非常に有用である。このような情報は、２つの隣接のパケット間の時差であるパケット到着間隔の累積分布関数（ＣＤＦ）曲線または確率密度関数（ＰＤＦ）図によって表示されることができる。例えば、一系列の点（ａ ｓｅｑｕｅｎｃｅ ｏｆ ｐｏｉｎｔｓ）（確率ｖｓ到着間隔）、または一系列のスロープ（ａ ｓｅｑｕｅｎｃｅ ｏｆ ｓｌｏｐｅ）によるＣＤＦ曲線、およびＬ２のバッファに入るユーザーデータのＩＡＴ用のＣＤＦが用いられることができる。

図５は、トラフィックパターンとＳＲリソース割り当てと関連した関連パラメータを示している。図５の例では、矢印線５０１は、ＵＬパケット用のＩＡＴ値を示し、破線矢印線５０２は、ユーザーデータがＬ２バッファに入った後の次のＳＲの機会までの各種の待ち時間を示している。注意するのは、時にＵｐｌｉｎｋ Ｓｈａｐｉｎｇがスケジューリングリクエストのウェイクアップを減少するように用いられることができることである。その考えは、ＵＥが複数のアップリンクパケットを集約して１つのスケジューリングリクエストを作り出すことである。例えば、図５では、ＵＥは、３つの連続的なバケットを集約し、１つのＳＲを作り出す。このケースにおいて、ＳＲ周期とオフセット上で統計を行っている時、ＵＥは、それらを一つにまとめ、最新のパケットを用いてオフセット（例えば、報告３のオフセット）とＳＲ周期（例えば、報告３のＩＡＴ）を計算する。平均のＩＡＴ値がＳＲの周期性を決定するのに非常に役立つことがみられ、平均のＩＡＴ値がＳＲの周期性を決定するのに非常に役立つことがみられる。

図６は、ＳＲリソース割り当て用のＵＥからｅＮＢに補助情報を提供する第２の実施形態を示している。ステップ６１１では、ＵＥ６０１は、補助情報をｅＮＢ６０２に送信する。補助情報は、ボックス６２１によって表されるＲＲＣシグナリングによって送信されることができる。例えば、補助情報は、３つのタイプに報告されることができる。第１の報告のタイプでは、一系列のペアが報告され、各ペアは、ＩＡＴ値と確率からなる。第２の報告のタイプでは、両平均のＩＡＴと平均の待ち時間が報告される。第３の報告のタイプでは、推奨されるＳＲ周期（平均のＩＡＴに基づき）と推奨されるＳＲオフセット（平均の待ち時間に基づき）が報告される。注意するのは、推奨されるＳＲ周期は、平均のＩＡＴと異なってもよいことである。例えば、ＵＥ６０１は、所定の基準に応じて、緊急でないＵＬパケットを遅延させ、ＳＲ指示だけを送信することによって、ＵＬトラフィックシェーピングを行うことができる。また、推奨されるＳＲオフセットは、ユーザーデータがＬ２バッファに入る平均の待ち時間でない可能性がある。その代り、ＵＬトラフィックシェーピングが用いられた後の結果であることができる。

特定のトラフィックでは、ランダムアクセスＳＲ（ＲＡ−ＳＲ）によるＵＬアクセスは、専用ＳＲ（Ｄ−ＳＲ）によるＵＬアクセスより、より効果的（遅延とリソース利用に関して）であることができる。しかしながら、現在のＬＴＥ仕様は、Ｄ−ＳＲが設定された場合、ＵＥがＲＡ−ＳＲを実行するのを防ぐ。このため、Ｄ−ＳＲリソースを解除するメカニズムは、このような必要性がある時に望ましい。指示をＵＥによって提供された補助情報内に挿入することで、前記指示はｅＮＢにＵＥがＳＲリソースを解除したいことを知らせることができる。図４に関する第１の実施形態では、ＵＥ４０１は、望ましいｓｒ−ＣｏｎｆｉｇＩｎｄｅｘで特定値（例えば、ｓｒ−ＣｏｎｆｉｇＩｎｄｅｘに使用されていない１５８）を示し、ｅＮＢ４０２は、特定値を１つの指示として解釈し、ＳＲリソースの解除をリクエストする。図６に関する第２の実施形態では、ＵＥ６０１は、平均または推奨されるＩＡＴ値用の特定値（例えば、０）を示し、ｅＮＢ６０２は、特定値を１つの指示として解釈し、ＳＲリソースの解除をリクエストする。

現存するＳＲ設定と補助情報は、ハンドオーバー（ＨＯ）動作およびＲＲＣ接続の再確立に役立つ可能性がある。ＨＯの間、ソースｅＮＢは、関連するＳＲ設定または補助情報をターゲットｅＮＢにパスすることができ、ターゲットｅＮＢは、ＳＲ設定用に関連するＳＲ設定または補助情報を用いることができる。ＵＥがＲＲＣアイドルモードに解除されると、ｅＮＢは、ＳＲ設定または補助情報を移動管理エンティティ（ＭＭＥ）または隣接セルに送信することができる。後にＵＥがＲＲＣ接続の再確立リクエストをセルに送信した時、セルは既にその情報を有するか、またはＭＭＦから情報を得ることができる。

上述の方法では（例えば図１の方式＃１）、ｅＮＢは、ＵＥのフィードバックに基づき、ＳＲリソースをより正確に割り当てることができる。しかしながら、トラフィックパターンは変わるため、動的にＳＲ設定を適応させるメカニズムが必要である。現在のＬＴＥ仕様では、ＲＲＣの再設定以外に、ＳＲ用に適応するメカニズムはない。タイムアラインメントタイマー（ＴＡＴ）の終了時にだけ、ＵＥは、ＳＲ用にＰＵＣＣＨリソースを解除する。一般的に、ＴＡＴは、セルサイズまたはＵＥの速度に基づいて設定される。ＴＡＴが長い場合、ＵＥはＵＬの同期に留まり、割り当てられたＰＵＣＣＨリソースを保持する。ＵＥは、補助情報をｅＮＢに送信し続け、ＳＲの使用率を向上させることができる。しかしながら、このようなメカニズムは、更新頻度に伴ってシグナリングオーバーヘッドを増加させる。頻繁なＲＲＣの再設定と補助情報は、余分なシグナリングオーバーヘッドを要する。ＵＥ側の自律的適応は、シグナリングオーバーヘッドの問題を回避することができる。

１つの新しい実施形態では（例えば図１の方式＃２）、ＳＲ周期は、シグナリングオーバーヘッドを増加させることなく、自律的にトラフィックパターンに適応される。バックグラウンドトラフィックと正常なトラフィックは、異なる到着間隔を有することができるため、適応性のＳＲ周期を有するＳＲ割り当ての方式は、ＳＲが実行アプリケーションのトラフィックに適応される場合、ＳＲの効率を向上させる。一般的に、ｅＮＢは、複数のＳＲ周期を有するセットのＳＲリソースを設定することができ、１つのＳＲ周期は、他のより長い。１つの代替例では、ＵＥは、設定の中の１つを用い、次いで所定のイベントに応じて２つの設定の間を切り替える。もう１つの代替例では、ＵＥは、設定の両方を用いて、所定のイベントに基づき、設定をオン／オフにする。全ての場合において、ｅＮＢとＵＥは、同期していなければならない。例えば、ｅＮＢは、ＰＵＣＣＨリソースがＵＥによって用いられるかどうか知らなければならない。

図７は、適応用の２つの異なるＳＲ周期を有するＳＲ設定を示している。図７の例では、基地局はＵＥ用にＰＵＣＣＨにセットの物理無線リソースを割り当てるＳＲ設定を送信する（時間Ｔ０で）。ＳＲ設定は、２つのＳＲ周期（周期＃１と周期＃２）を設定する。ＳＲ設定は、２つの設定されたＳＲ周期の間を切り替えるように用いられるＳＲタイマーも含む。第１のＳＲリソースは、時間Ｔ１に発生し、周期＃１の第１の設定されたＳＲ周期に応じて周期的に発生する。ＵＥが送信されるアップリンクデータがない場合、ＳＲタイマーは時間Ｔ２で終了する。ＳＲタイマーの終了後、ｅＮＢは、第２の設定されたＳＲ周期に切り替える。これは、後に続くＳＲリソースがその後、周期＃２のＳＲ周期で周期的に出現することを意味する。時間Ｔ３では、ＵＬデータはＬ２バッファに入り、ＵＥは、時間Ｔ４でＳＲの指示をｅＮＢに送信する。このようなイベントの後、ｅＮＢは、周期＃１を有する第１の設定されたＳＲ周期などに切り戻す。

図８は、適応性のＳＲ設定の方法を示している。ステップ８１１では、ＵＥ８０１は、ＳＲ設定をｅＮＢ８０２から受信する。ＳＲ設定は、ボックス８２１によって表されるＲＲＣシグナリングによって送信されることができる。例えば、ＳＲ設定は、ｓｒ−ＰＵＣＣＨ−ＲｅｓｏｕｒｃｅＩｎｄｅｘに基づき、ＰＵＣＣＨにセットの物理無線リソースを割り当てる。ＳＲ設定は、ＳＲ周期とＳＲオフセットにそれぞれ関連付けされた２つのｓｒ−ＣｏｎｆｉｇＩｎｄｅｘも含む。また、ＳＲ設定は、ＳＲ−Ｔｉｍｅｒを含む。ＳＲ−Ｔｉｍｅｒは、ＳＲ設定がどのぐらいの有効かを示すように用いられ、ＳＲ伝送と同時に再開される。第１のＳＲ設定が無効になった時、第２のＳＲ設定が代わりに有効になる。もう１つの例では、２つのＳＲ周期の間のスイッチングは、特定のアプリケーションのＵＬデータがｅＮＢによって受信された後、発生する。特定のアプリケーションは、パワープレファレンス指示（ｐｏｗｅｒ ｐｒｅｆｅｒｅｎｃｅ ｉｎｄｉｃａｔｉｏｎ； ＰＰＩ）を基地局に送信することによって示されることができる。２つの異なるＳＲ周期とＳＲ−Ｔｉｍｅｒを設定することで、適応性のＳＲ設定が得られ、ｅＮＢ８０２とＵＥ８０１の間で切り替えられる余分なシグナリングのない、異なるトラフィックタイプに適応する。

タイマーまたはデータ着信を異なるＳＲ設定の間を切り替えるトリガーとして用いる他に、ＤＲＸ遷移状態が用いられることもできる。第１の例では、アクティブ状態とＤＲＸ状態間の遷移は、ＳＲ設定間の切り替えに用いられることができる。アクティブ時間中（インアクティビティタイマーまたはオンデュレーション（ｏｎＤｕｒａｔｉｏｎ）タイマーのいずれかが動作している）、第１のセットのＳＲ設定が用いられる。ＵＥがＤＲＸに入ると、第２のセットのＳＲ設定が用いられる。第２の例では、短いＤＲＸサイクルと長いＳＲＸサイクル間の遷移は、ＳＲ設定間の切り替えに用いられることができる。短いＤＲＸサイクルが用いられる時、第１のセットのＳＲ設定が用いられる。長いＤＲＸサイクルが用いられる時、第２のセットのＳＲ設定が用いられる。両実施例では、ＤＲＸ状態の遷移は、シグナリングオーバーヘッドを発生させることなく、ＳＲ設定をトラフィックパターンに自動的に用いることを実現することができる。注意するのは、タイマーまたはデータ着信、またはＳＲ適応用のＤＲＸ遷移を用いることは非対称的であることができることである。例えば、長いＳＲ周期が短いＳＲ周期に切り替わるのは、タイマー制御に頼ることができるが、短いＳＲ周期が長いＳＲ周期に切り替わるのは、ＤＲＸサイクルの変更に頼ることができる。

１つの実施形態では、複数のＳＲ設定は、ＵＥによって提案されることができる。例えば、ＵＥが補助情報を報告する時、ＵＥは、少なくとも２つの望ましいＳＲ設定を提案し、ｅＮＢが適応用の複数のＳＲ設定を決定するのを助ける。

図９は、ＳＲリソースのリサイクルを有する適応性のＳＲ設定の方法を示している。ステップ９１１では、ＵＥ９０１は、ｅＮＢ９０２からスケジューリングリクエスト設定を受信する。ＳＲ設定は、２つの異なる設定されたＳＲ周期でＳＲ伝送用にセットのリソースを割り当てる。ステップ９１２では、ＵＥ９０１は、第１のＳＲ周期を用いてＳＲ指示を送信する。ステップ９１３では、トリガーイベントはＵＥ９０１によって検出される。トリガー条件は、常に同期されるようにＵＥ９０１とｅＮＢ９０１との間に予め定義される（例えばＳＲタイマー）。ステップ９１４では、ＵＥ９０１は、第２のＳＲ周期を用い初めてＳＲ指示を送信する。第２のＳＲ周期が第１のＳＲ周期より長い場合、割り当てられたＳＲリソースは、完全に用いられない。リソースの使用率を向上させるために、ステップ９１５では、ｅＮＢ９０２は、未使用のＳＲリソースをリサイクルする。ＵＥ９０１専用の未使用のＳＲリソースは、ＰＵＣＣＨリソースとして他のＵＥに再割り当てされることができるか、またはＰＵＣＣＨリソースとしてデータ伝送用にＵＥに再割り当てされることができる。

図１０は、ＰＵＳＣＨのデータ伝送に用いられ得る仮想のＰＵＣＣＨを示している。適応性のＳＲ設定中、ＰＵＣＣＨの未使用のＳＲリソースは、ＰＵＳＣＨ用にリサイクルされることができる。一般的に、ｅＮＢは、ＵＥからの指示に基づき、ＲＲＣシグナリングでＰＵＣＣＨ設定を更新することができる。しかしながら、これは、仮にトラフィックパターンが大きく変化し、周波数の更新がリクエストされた場合、余分なシグナリングオーバーヘッドを発生し、ｅＮＢからＵＥにＲＲＣ再設定とＳＲ設定を送信する可能性がある。オーバーヘッドを制限するために、仮想のＰＵＣＣＨの概念が用いられ、既に割り当てられたＰＵＣＣＨリソースをリサイクルする。仮想のＰＵＣＣＨとは、割り当てられたＰＵＣＣＨリソースのサブセットがｅＮＢに指示された時、無効になることを意味する。前記指示は、黙示的または明示的であることができる。図１０に示されるように、ＤＤＡ ＵＥ用のＰＵＣＣＨは、ＰＵＳＣＨ領域に近い領域に割り当てられる。例えば、ＰＵＣＣＨ領域１００１とＰＵＣＣＨ領域１００２は、ＳＲ伝送用にＤＤＡ ＵＥに割り当てられる。１つの例では、ＳＲの周期性がｅＮＢからの指示の後、Ｎ倍変わった時、割り当てられたＰＵＣＣＨの領域は、ＰＵＳＣＨ用にリサイクルされる。Ｎは、所定の番号であることができ、前記指示は、黙示的または明示的であることができる。

異なるアプリケーションは、異なるＱｏＳリクエストを有することができ（例えば、遅延、ジッター（ｊｉｔｔｅｒ）、低下率（ｄｒｏｐｐｉｎｇ ｒａｔｅ））、従来の単一のＳＲ設定は、アプリケーションのサブセットの必要に応えることができるだけか、または効率／利用の問題を有するだけである。従って、複数のＳＲ設定が異なるアプリケーションに対して割り当てられることができる場合、ＰＵＣＣＨパフォーマンスまたは効率は向上されることができるＵＥが複数のＳＲリソースを有することができる場合、ＳＲの使用は関連するアプリケーションに応用されることができる。全てのアプリケーションからトラフィック用に一般のＳＲを用いる代わりに、個別のＳＲが、単一のアプリケーションまたはサブセットのアプリケーションによって用いられることができる。追加のＳＲ設定は、アクティブ化または非アクティブ化されることができる。

図１１は、異なるアプリケーションに対応する異なるＳＲ設定を示している。時間Ｔ１では、アプリケーション１は、動作を開始する。時間Ｔ２では、ｅＮＢは、第１のＳＲ設定を設定し、ＵＥは、ＳＲ指示用にＰＵＣＣＨのリソースＳＲ１に割り当てられる。時間Ｔ３では、アプリケーション２は、動作を開始する。時間Ｔ４では、ｅＮＢは、第２のＳＲ設定を設定し、ＵＥは、ＳＲ指示用にＰＵＣＣＨのリソースＳＲ２に割り当てられる。注意するのは、両ＳＲ１とＳＲ２リソースは、同じ送信時間間隔（ＴＴＩ）でＵＥに割り当てられる。このＴＴＩでは、ＰＵＣＣＨ上のＵＥの送信電力を考慮し、ＵＥは、ＳＲの１つを選び、リクエストを作り出し、更に後のシグナリングで情報（アプリケーションと対応のサイズ）を報告することができる。時間Ｔ５では、アプリケーション１は動作を停止する。時間Ｔ６では、ｅＮＢは、第１の割り当てられたＳＲリソースを解除し、よって、ＳＲ２だけがＵＥに設定される。

図１２は、所定のアプリケーションの複数のＳＲ設定を設定する方法を示している。ステップ１２１１では、ＵＥ１２０１は、ｅＮＢ１２０２から第１のセットのＳＲリソースを割り当てる第１のＳＲ設定＃１を受信する。ステップ１２１２では、ＵＥ１２０１は、ｅＮＢ１２０２から第２のセットのＳＲリソースを割り当てる第２のＳＲ設定＃２を受信する。ステップ１２１３では、ｅＮＢ１２０２は、セットの所定のイベントをＵＥ１２０１に伝え、所定のイベントは、予め割り当てられたＳＲリソースと関連し、ＳＲリソースの使用が所定のイベントによって制御されることができる。例えば、各所定のＳＲリソースは、アプリケーションのＱｏＳリクエストに基づき、１つ以上のセットの所定のアプリケーションと関連することができる。ステップ１２１４では、ＵＥ１２０１は、アプリケーション＃１の動作を開始し、第１のセットのＳＲリソースを用いて関連のＱｏＳリクエストに応える。ステップ１２１５では、ＵＥ１２０１は、アプリケーション＃２の動作を開始し、第２のセットのＳＲリソースを用いる。ステップ１２１６では、アプリケーション＃１は動作を停止し、ＵＥ１２０１は、第１のセットの使用を停止する。ステップ１２１７では、ｅＮＢ１２０２は、他の使用に用いるために、未使用の第１のセットのＳＲリソースをリサイクルする。

セットのリソースの使用の開始と停止は、トラフィックまたは予め定義されることによって自動的に制御されることができる（オン／オフのアプリケーショの、および個別のアプリケーションを識別することによってＵＥ／ｅＮＢがＳＲの使用を同期させる）。１つの例では、アプリケーションの開始／停止は、パワープレファレンス指示（ＰＰＩ）によって示される。または、セットのリソースの使用の開始と停止は、ＵＥまたはｅＮＢによって明示的に示されることができる。ＭＡＣ ＣＥまたはＲＲＣメッセージは、望ましいＳＲの使用をシグナリングし、互いに同期するように用いられることができる。

ｅＮＢとＵＥは、ＳＲの使用で同期していなければならず、複数のＳＲ割り当ては、ＤＲＸ状態の遷移によって、制御（例えば、アクティブ化および／または非アクティブ化）されることができる。２つのＳＲリソースＳＲ１とＳＲ２が予め割り当てられているとする。１つの例では、ＤＲＸ ＯＮ周期は、第１のＳＲ割り当てＳＲ１と関連付けられることができ、ＤＲＸ ＯＦＦ周期は、他のＳＲ割り当てＳＲ２と関連付けられることができる。もう１つの例では、アクティブの時間の時、両ＳＲ設定がアクティブ化される。一旦ＵＥがＤＲＸに入ると、第２のＳＲ割り当てＳＲ２は、ＳＲ１がアクティブのままで自動的に非アクティブ化される。ＳＲの使用は所定のイベントによって制御されるため、余分なＲＲＣシグナリングがない。

全てのアプリケーションによってシェアされる１つだけのＳＲ設定と比べ、アプリケーションが結合したＳＲ設定は、より多くの情報をｅＮＢに提供することができる。特定のＳＲ設定を１つまたはサブセットのアプリケーションと関連付けることは、開始から更なる情報をｅＮＢに提供することができる。例えば、遅延耐性（ｄｅｌａｙ−ｔｏｌｅｒａｎｔ）のアプリケーションに割り当てられた特定のリソースでＳＲの指示を受信した時、ｅＮＢは、ＵＬデータが緊急でないことを知り、このような情報は、今後のスケジューリングに用いられることができる。

図１３は、１つの新しい実施形態に基づくＳＲリソース割り当て用の補助情報を提供する方法のフローチャートである。ステップ１３０１では、ＵＥは、基地局とＲＲＣ接続を確立する。ＵＥは、ＲＲＣ接続モードにある。一般的にＵＥは、ＳＲリソース割り当て用にｅＮＢによって初期のＳＲ設定で設定される。ステップ１３０２では、ＵＥは、ＳＲリソースの使用率を評価し、補助情報をｅＮＢに送信して、ＳＲリソースの使用率を向上させる必要があるかどうかを決定する。次いで、必要がある場合、ステップ１３０３では、ＵＥは、補助情報をｅＮＢに提供する。補助情報は、ＰＵＣＣＨのＳＲリソース割り当てに関連している。１つの例では、補助情報は、ＵＥに望ましい（ＵＥ−ｐｒｅｆｅｒｒｅｄ）ＳＲ設定インデックスを含む。もう１つの例では、補助情報は、ＵＥに望ましいＳＲ周期／オフセット、および／またはパケット到着間隔（ＩＡＴ）に関連したトラフィックパターン情報を含む。ステップ１３０４では、ＵＥは、補助情報に応じてｅＮＢからＳＲ設定を受信する。ＳＲ設定は、ＳＲリソース割り当て用にＳＲ周期とＳＲオフセットと関連したＳＲ設定インデックスを含む。ＵＥは、ＱｏＳリクエスト、トラフィックパターン／統計、およびＤＲＸ設定を含んだ考慮に基づき、補助情報を提供するため、ｅＮＢは、より正確にＳＲリソースを割り当てることができる。ＵＥは、更にリクエストメッセージを送信し、ＳＲ割り当てを解除する。

図１４は、１つの新しい実施形態に基づくＳＲ設定の適応およびＳＲリソースのリサイクルを用いる方法のフローチャートである。ステップ１４０１では、ＵＥは、基地局からスケジューリングリクエスト（ＳＲ）設定を受信する。ＳＲ設定は、ＳＲ伝送用にセットの無線リソースを割り当て、割り当てられたＳＲリソースは、第１のＳＲ周期と第２のＳＲ周期と関連付けられる。ステップ１４０２では、ＵＥは、第１のＳＲ周期を用いてＳＲの送信をする。ステップ１４０３では、ＵＥは、第１の所定のトリガー条件が満たされた後、第２のＳＲ周期を用いてＳＲの送信をする。１つの実施形態では、トリガー条件は、ＳＲ設定によって設定されたＳＲタイマーに基づく。もう１つの実施形態では、トリガー条件は、特定のアプリケーション用のアップリンクデータが基地局に送信された時、満たされる。トリガー条件は、不連続受信（ＤＲＸ）動作の状態に基づくこともできる。ステップ１４０４では、ＵＥは、第２の所定のトリガー条件が満たされた後、切り戻され、第１のＳＲ周期を用いる。第２の所定のトリガー条件は、第１のトリガー条件と同じまたは異なってもよい。１つの有利な実施形態では、ＰＵＣＣＨの未使用のＳＲリソースは、他のＵＥ用に、またはＰＵＳＣＨのデータ伝送用にリサイクルされることができる。異なるＳＲ周期のＳＲリソースを設定することによって、ＳＲリソースの使用率は、トラフィックパターンに適応される。

図１５は、１つの新しい実施形態に基づく所定のアプリケーションの複数のＳＲ設定を設定する方法のフローチャートである。ステップ１５０１では、ＵＥは、基地局から第１のＳＲ設定を受信する。第１のＳＲ設定は、ＳＲ伝送用にＰＵＣＣＨの第１のセットのリソースを割り当てる。ステップ１５０２では、ＵＥは、基地局から第２のＳＲ設定を受信する。第２のＳＲ設定は、ＳＲ伝送用にＰＵＣＣＨの第２のセットのリソースを割り当てる。ステップ１５０３では、ＵＥは、第１のアプリケーションが動作している時、第１のセットのＳＲリソースを用いる。ステップ１５０４では、ＵＥは、第２のアプリケーションが動作している時、第２のセットのＳＲリソースを用いる。ステップ１５０５では、ＵＥは、第１のアプリケーションが動作を停止した時、第１のセットのＳＲリソースの使用を停止する。各ＳＲ設定は、１つ以上の所定のアプリケーションと関連付けされる。複数の予め割り当てられたＳＲリソースは、アプリケーションのサービス品質（ＱｏＳ）リクエストを満たすように決定される。１つの実施形態では、割り当てられたＳＲ無線リソースは、ＤＲＸ状態の遷移に基づき、アクティブ化または非アクティブ化される。複数の予め割り当てられたＳＲ設定でＳＲリソースの使用は、関連するアプリケーションに適応される。

本発明は、説明のためにある特定の実施の形態に関連して述べられているが本発明はこれを制限するものではない。よって、種々の変更、改造、及び上述の実施の形態の種々の特徴の組み合わせがこの請求項に記載したような本発明の範囲を逸脱せずに行い得る。

１００ 無線通信システム
１０１、２０１、４０１、６０１、８０１、９０１、１２０１ ユーザー端末
１０２、２０２、４０２、６０２、８０２、９０２、１２０２ 基地局
２１１、２３１ ＲＦトランシーバモジュール
２１２、２３２ プロセッサ
２１３、２３３ メモリ
２１４、２３４ プログラム命令とデータ
２２１、２４１ ＲＲＣ管理モジュール
２２４、２３４ アプリケーション
２２３ ＳＲアプリケーション
２２２ 状態収集モジュール
２２５ アンテナ
２４５ アンテナ
２４３ ＳＲ ＣＯＮＦＩＧ
２４２ ＱｏＳ管理モジュール
３００ 図３の表

Claims (24)

1. 移動通信ネットワークでユーザー端末（ＵＥ）と基地局によって 無線リソース制御（ＲＲＣ）接続を確立するステップ、
   スケジューリングリクエスト（ＳＲ）リソースの割り当てに関連する補助情報を基地局に提供するステップ、および
   前記補助情報に応じて前記基地局から、ＳＲリソース割り当て用のＳＲ周期とＳＲオフセットと関連するスケジューリングリクエスト（ＳＲ）設定を受信するステップを含む方法。
2. 前記補助情報は、ＵＥに望ましい（ＵＥ−ｐｒｅｆｅｒｒｅｄ）ＳＲ−ＣＯＮＦＩＧインデックスを含む請求項１に記載の方法。
3. 前記補助情報は、ＵＥに望ましいＳＲ周期とＵＥに望ましいＳＲオフセットを含む請求項１に記載の方法。
4. 前記補助情報は、パケット到着間隔（ＩＡＴ）に関連したトラフィックパターン情報を含む請求項１に記載の方法。
5. 前記基地局から初期のＳＲ設定を受信するステップ、および
   ＳＲの使用を評価し、前記補助情報を前記基地局に送信するかどうかを決定するステップを更に含む請求項１に記載の方法。
6. 前記基地局に指示を送信し、割り当てられたＳＲリソースを解除するステップを更に含む請求項１に記載の方法。
7. 前記指示は、ＳＲ−ＣＯＮＦＩＧインデックスの特定値を含む請求項６に記載の方法。
8. 前記指示は、パケット到着間隔の特定値を含む請求項６に記載の方法。
9. ユーザー端末（ＵＥ）によって基地局から、ＳＲ用のセットの無線リソースを割り当て、前記割り当てられたＳＲ無線リソースは、第１のＳＲ周期と第２のＳＲ周期と関連付けられるスケジューリングリクエスト（ＳＲ）設定を受信するステップ、
   前記第１のＳＲ周期を用い、前記基地局にＳＲを送信するステップ、および
   第１の所定のトリガー条件が満たされた後、前記第２のＳＲ周期を用いるステップを含む方法。
10. 第２の所定のトリガー条件が満たされた後、切り戻され、第１のＳＲ周期をＳＲの伝送に用いるステップを更に含む請求項９に記載の方法。
11. 前記第１または第２のトリガー条件は、前記ＳＲ設定によって設定されたＳＲタイマーに基づき、ＳＲ設定によって設定されたＳＲタイマーに基づく請求項１０に記載の方法。
12. 前記第１または第２のトリガー条件は、特定のアプリケーション用のアップリンクデータが前記基地局に送信された時、満たされる請求項１０に記載の方法。
13. 前記特定のアプリケーションは、パワープレファレンス指示を前記基地局に送信することによって示される請求項１２に記載の方法。
14. 前記第１または前記第２のトリガー条件は、不連続受信（ＤＲＸ）の動作状態に基づく請求項１０に記載の方法。
15. 前記第２のＳＲ周期は、前記第１のＳＲ周期より長く、前記ＵＥが前記第１のＳＲ周期を用いる時、より多くのＳＲリソースが割り当てられる請求項９に記載の方法。
16. 前記ＵＥが前記第２のＳＲ周期を用いた時、前記未使用のＳＲリソースは、他のＵＥに用いるように、物理アップリンク制御チャネル（ＰＵＣＣＨ）用にリサイクルされる請求項１５に記載の方法。
17. 前記ＵＥが前記第２のＳＲ周期を用いた時、前記未使用のＳＲリソースは、データ伝送に用いるように物理アップリンク共有チャネル（ＰＵＳＣＨ）にリサイクルされる請求項１５に記載の方法。
18. ユーザー端末によって基地局から、物理アップリンク制御チャネル（ＰＵＣＣＨ）の第１のセットの無線リソースを割り当てる第１のスケジューリングリクエスト（ＳＲ）設定を受信するステップ、
    前記基地局から、ＰＵＣＣＨの第２のセットの無線リソースを割り当てる第２のＳＲ設定を受信するステップ、
    第１のアプリケーションが動作している時、前記第１のセットの無線リソースを用いるステップ、および
    第２のアプリケーションが動作している時、前記第２のセットの無線リソースを用いるステップを含む方法。
19. 前記ＳＲ設定は、セットの所定のアプリケーションに対応する請求項１８に記載の方法。
20. 前記割り当てられた無線リソースは、前記アプリケーションのサービス品質（ＱｏＳ）リクエストを満たすように決定される請求項１９に記載の方法。
21. 前記ＵＥは、前記第１のアプリケーションが動作を停止した時、前記第１のセットの無線リソースの使用を停止する請求項１８に記載の方法。
22. 前記第１のアプリケーションの停止は、パワープレファレンス指示によって指示される請求項２１に記載の方法。
23. 前記第１のセットの無線リソースは、他の使用に用いるために、リサイクルされる請求項２１に記載の方法。
24. 前記割り当てられたＳＲ無線リソースは、不連続受信（ＤＲＸ）状態の遷移に基づき、アクティブ化または非アクティブ化される請求項１８に記載の方法。

Images