長期進化型（ＬＴＥ）システムにおけるアップリンク欠乏状態回避を支援するための方法および装置
【課題】ＵＬ欠乏状態回避を支援するための方法および装置を提供する。
【解決手段】ＵＬ（ＵｐＬｉｎｋ：アップリンク）欠乏状態回避のための方法および装置は、現在のバッファー状態情報を判定することを含む。現在のバッファー状態情報は、ｅＮＢ（ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ：高度化ノードＢ）に報告される。ＷＴＲＵ（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ Ｒｅｃｅｉｖｅ Ｕｎｉｔ：無線送受信ユニット）が蓄積することができるトークンの数の判定を含む許可をそのｅＮＢから受け取る。
【解決手段】ＵＬ（ＵｐＬｉｎｋ：アップリンク）欠乏状態回避のための方法および装置は、現在のバッファー状態情報を判定することを含む。現在のバッファー状態情報は、ｅＮＢ（ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ：高度化ノードＢ）に報告される。ＷＴＲＵ（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ Ｒｅｃｅｉｖｅ Ｕｎｉｔ：無線送受信ユニット）が蓄積することができるトークンの数の判定を含む許可をそのｅＮＢから受け取る。
【発明の詳細な説明】
【技術分野】
【０００１】
この出願は無線通信に関する。
【背景技術】
【０００２】
３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ：第３世代パートナーシップ・プロジェクト）ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ：長期進化型）プログラムは、新しいＬＴＥ設定および構成に向けての、新技術、新しいアーキテクチャ、および新しい方法をもたらそうとしている。ＬＴＥプログラムは、スペクトル効率の改善、待ち時間の削減、および無線資源のより上手い利用を提供するために進められ、これにより、より速いユーザー体験、ならびにより少ない費用によるより豊かなアプリケーションおよびサービスが提供される。
【０００３】
Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ：発展型ＵＴＲＡＮ）およびＵＴＲＡＮの目的は高いデータレート、低遅延、改良されたシステム容量および改良された適用範囲（coverage）を有する、パケットに最適化されたシステムに向けて適合された無線アクセス・ネットワークを開発することである。これを達成するために、無線ネットワーク・アーキテクチャと共に無線インターフェイスの進化が必要となる場合がある。例えば、現在３ＧＰＰで使用されるようなＣＤＭＡ（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：符号分割多元接続）無線インターフェイス技術を使用するのではなく、ＤＬ（ＤｏｗｎＬｉｎｋ：ダウンリンク）およびＵＬ（ＵｐＬｉｎｋ：アップリンク）送信においてそれぞれＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：直交周波数分割多元接続）およびＦＤＭＡ（Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：周波数分割多元接続）を使用する場合がある。さらに、ＬＴＥは全パケット交換のサービスを採用することができ、これはすべての音声通話もがパケット交換に基づき為されることを意味するであろう。
【０００４】
無線資源が制限されているシナリオにおいては、ビデオ会議などの高優先度のサービスは、ＷＴＲＵ（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ Ｒｅｃｅｉｖｅ Ｕｎｉｔ：無線送受信ユニット）に割り当てられる無線資源から可能な限り多くの利用可能な無線資源を獲得するべく試みる。アプリケーションの間で許可された資源を如何に分配するかに関してＮＷ（ＮｅｔＷｏｒｋ：ネットワーク）は制御しないため、このことが、より高優先度フローが利用可能な帯域幅まで拡大すると、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などの低優先度のフローが欠乏状態になることをもたらす場合がある。
【０００５】
ＨＳＵＰＡ（Ｈｉｇｈ Ｓｐｅｅｄ Ｕｐｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ：高速アップリンク・パケット・アクセス）においては、拡張版ＵＬは既存のＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ：サービス品質）モデルで構築された。このモデルにおいては、ネットワークが無線資源をＷＴＲＵに許可した場合には、ＷＴＲＵは、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ：無線資源制御）信号方式により供給されるそれぞれのフローに対して関連付けられた優先度を使用して、何れのアップリンクＱｏＳフローを提供すべきかを選択することに対して責任がある。この方式においては、ネットワークが低優先度フローの資源欠乏状態（ｒｅｓｏｕｒｃｅ ｓｔａｒｖａｔｉｏｎ）を回避するためには、より高い優先度のフローと同じ優先度をそれらのフローに提供することを必要とする場合がある。そうであっても、これらのフローを本質的に一まとめに集約することによって、ＷＴＲＵはそれぞれのフローに、それぞれの待ち行列に対する等しい送信権を割り当てる。
【０００６】
ＲＡＮ２（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ２：無線アクセス・ネットワーク２）におけるＵＬ欠乏状態問題を解決するために２つの提案がある。１つはＮＷ中心の解決策であり、そして他方がＷＴＲＵ中心の解決策である。ＮＷ中心の解決策は、ＷＴＲＵからデータを受信した後にＮＷによって行われる送信後トラフィックの監視により特徴付けられる。ＧＢＲ（Ｇｕａｒａｎｔｅｅｄ Ｂｉｔ Ｒａｔｅ：保証伝送レート）、ＭＢＲ（Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ：上限伝送レート）、およびＰＢＲ（Ｐｒｉｏｒｉｔｉｚｅｄ Ｂｉｔ Ｒａｔｅ：優先伝送レート）情報をＷＴＲＵに送信するべきではない。
【０００７】
ＷＴＲＵ中心の解決策は、伝送前のトラフィック監視を含むことができる。トラフィック監視は、データが無線を通して送信される前にＷＴＲＵにより実行され、そしてＲＢ（Ｒａｄｉｏ Ｂｅａｒｅｒ：無線ベアラ）確立または修正時にＧＢＲ、ＭＢＲ、およびＰＢＲ情報をＷＴＲＵに送信することができる。ＷＴＲＵ中心の解決策は、ＬＴＥにおけるＵＬ欠乏状態回避に使用でき、そしてトークン・バケットの数に基づき指定することができる。図１は、一例のトークン・バケット構成１００を示す。
【０００８】
図１において示されるように、トークンは、あるレート（例えばトークン数／セクション）に従ってそれぞれのバケットに加えられる。Ｘトークン分のサイズのパケットをスケジューリングしてＷＴＲＵから送出するために、ＷＴＲＵは、このパケットの送出が可能な充分なトークンがあるか（すなわち、パケットのサイズ＜＝トークン・バケットのサイズ、であるか）、を確認するために、現在のトークン・バケットのサイズをチェックし、そして充分なトークンがあれば、ＷＴＲＵはパケットを送出することができる。パケットの送出を可能にするために充分なトークンがなければ、ＷＴＲＵはその時点ではパケットを送出しないことになるが、十分な数のトークンが蓄積されればそれを送出することができる。
【０００９】
しかしながら、ＬＴＥシステムにおけるＵＬ欠乏状態回避に対してＷＴＲＵ中心の解決策を使用する場合、様々な問題がある。ＲＡＮ２においてはＢＳＲ（Ｂｕｆｆｅｒ Ｓｔａｔｕｓ Ｒｅｐｏｒｔｉｎｇ：バッファー状態報告）と設定されたＭＢＲ／ＧＢＲとの間の関係を扱えないので、目前の（ｉｍｐｅｎｄｉｎｇ）許可のロス問題が生ずる場合がある。許可のロス（ｇｒａｎｔ ｌｏｓｓ：許可ロス）が発生すると、信号方式のオーバーヘッド、資源割り付けのロス等が発生する場合がある。
【００１０】
一般に許可ロスは、ＷＴＲＵが許可を受け取っているが、それを完全には利用できないことを意味する。ＷＴＲＵは何れのレートにより許可を受け取ることになるかを知らないので、あるバッファーレベルを取り扱うときにこのバッファーレベルが設定されたＭＢＲ／ａＭＢＲ（ａｇｇｒｅｇａｔｅ ＭＢＲ：集約されたＭＢＲ）を上回ることになるか否かをＷＴＲＵが予め判定することを困難にしているため、許可ロスが発生する場合がある。このように現時点では、ＢＳＲを報告する際にＷＴＲＵが設定されたＭＢＲ／ａＭＢＲを考慮に入れるための機構が無い。結果として、ＷＴＲＵがあるバッファーレベルを報告しても、このバッファーレベルを取り扱うためのＵＬ許可を獲得しようとしているときには、設定されたＭＢＲ／ａＭＢＲを越えることを意味することになるため、その関係するＳＡＥベアラをスケジュールすることができない、という状況が発生するかもしれない。これこそが「許可ロス（ｇｒａｎｔ ｌｏｓｓ）」と呼ぶことができるものある。ｅＮＢ（ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ：高度化ノードＢ）がただＢＳＲにおいて表されたデータに対応して許可を提供するのみであっても、許可ロスは発生する場合がある。
【００１１】
したがって、ＬＴＥシステムにおいてＵＬ欠乏状態回避を支援するための方法および装置を提供することは有益であろう。
【発明の概要】
【００１２】
ＵＬ（ＵｐＬｉｎｋ：アップリンク）欠乏状態回避のための方法および装置が開示される。この方法は、現在のバッファー状態情報を判定することを含む。現在のバッファー状態情報は、ｅＮＢ（ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ：高度化ノードＢ）に報告される。ＷＴＲＵ（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ Ｒｅｃｅｉｖｅ Ｕｎｉｔ：無線送受信ユニット）が蓄積することができるトークンの数の判定を含む許可をそのｅＮＢから受け取る。
【００１３】
添付された図面に関連して例として与えられる以下の記述から、より詳細な理解を得ることができる。
【図面の簡単な説明】
【００１４】
【図１】一例のトークン・バケット構成を示す図である。
【図２】複数のＷＴＲＵおよび１つのｅＮＢを含む一例の無線通信システムを示す図である。
【図３】図２のＷＴＲＵおよびｅＮＢの一例の機能的ブロック図である。
【図４】ＵＬ欠乏状態回避を支援する方法のフロー図である。
【図５】ＵＬ欠乏状態回避を支援する代替の方法のフロー図である。
【発明を実施するための形態】
【００１５】
これ以後参照されると、用語「ＷＴＲＵ（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ Ｒｅｃｅｉｖｅ Ｕｎｉｔ：無線送受信ユニット）」は、限定的ではなく、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ユーザー機器）、移動端末、固定型または移動体の加入者ユニット、ページャー、携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ：携帯情報端末）、コンピューター、または無線環境において動作する能力のある他の如何なる種別のユーザー・デバイスをも含む。これ以後参照されると、用語「基地局（ｂａｓｅ ｓｔａｔｉｏｎ）」は、限定的ではなく、ノードＢ（Ｎｏｄｅ−Ｂ）、サイトコントローラー、ＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ：アクセス・ポイント）、または無線環境において動作する能力のある他の如何なる種別のインターフェイス・デバイスをも含む。
【００１６】
図２は、複数のＷＴＲＵ２１０および１つのｅＮＢ２２０を含む無線通信システム２００を示す。図２に示されるように、ＷＴＲＵ２１０はｅＮＢ２２０と通信状態にある。図２においてはＷＴＲＵ２１０および基地局２２０という一例の構成が表現されるが、無線通信システム２００においては、無線のそして有線の装置の何れの組み合わせをも含むことができることに注意するべきである。
【００１７】
図３は、図２の無線通信システム２００のＷＴＲＵ２１０およびｅＮＢ２２０の機能的ブロック図３００である。図３に示されるように、ＷＴＲＵ２１０はｅＮＢ２２０と通信状態にあり、そして両方がアップリンク欠乏状態回避を支援する方法を実行するように構成されている。
【００１８】
典型的なＷＴＲＵにおいて見出すことができる構成要素に加えて、ＷＴＲＵ２１０は処理装置２１５、受信機２１６、送信機２１７、およびアンテナ２１８を含む。処理装置２１５は、アップリンク欠乏状態回避を支援する方法を実行するように構成されている。受信機２１６および送信機２１７は、処理装置２１５と通信状態にある。アンテナ２１８は、受信機２１６および送信機２１７の両方と通信状態にあり、無線データの送信および受信を容易にする。
【００１９】
典型的なｅＮＢにおいて見出すことができる構成要素に加えて、ｅＮＢ２２０は処理装置２２５、受信機２２６、送信機２２７、およびアンテナ２２８を含む。処理装置２２５は、アップリンク欠乏状態回避を支援する方法を実行するように構成されている。受信機２２６および送信機２２７は、処理装置２２５と通信状態にある。アンテナ２２８は、受信機２２６および送信機２２７の両方と通信状態にあり、無線データの送信および受信を容易にする。
【００２０】
図４は、ＵＬ欠乏状態回避を支援する方法４００のフロー図である。ステップ４１０において、ＷＴＲＵ２１０は現在のバッファー状態情報をｅＮＢ２２０に報告する。この情報には、いくつかのまたはすべてのＲＢに対する情報を含めることができ、そして許可ロスを防ぐように向かわせることができる。この情報には、ＢＯ（Ｂｕｆｆｅｒ Ｏｃｃｕｐａｎｃｙ：バッファー占有率）情報、ＰＢＲ、ＧＢＲ ＭＢＲ、およびｅＭＢＲそれぞれに対するそれぞれのＲＢのトークン・バケットのサイズ、ＷＴＲＵにおけるトークン蓄積パターン、電力残量等を含めることができる。
【００２１】
ＢＯ情報は、１つのＲＢ、ＲＢのグループ、またはすべてのＲＢに対するものであることができ、一方電力残量は、すべてのＲＢに対するものである。トークンのサイズおよびトークン蓄積パターンは、ＲＢに対するＰＢＳ、ＧＢＲ、ＭＢＲ、およびａＭＢＲそれぞれに対するものであることができる。あるいはまた、いくつかのＲＢに対するトークンの集約数を報告し、そして別の集約を個々に報告することができる。例えばＧＢＳ、ＭＢＲ、およびｅＭＢＲに対する集約トークンを、お互いの如何にかかわらず報告することができる。許可がＷＴＲＵ単位であるため、ＷＴＲＵ２１０が利用できるトークンの総数は、許可をスケジューリングするために効率的な方法を提供することが可能である。
【００２２】
ステップ４１０における報告の間に、ＷＴＲＵ２１０はトークン・バケットの最大のサイズに対するトークンの割合を報告することができる。例えば、ＷＴＲＵ２１０がトークン・バケットの最大のサイズの０〜１／４、１／４〜１／２、１／２〜３／４、３／４〜１００パーセントを有することを表すために２ビットを使用することができる。トークンなし、１／４トークン未満、１／４トークンと１／２トークンの間、１／２トークンより大などの不均一な範囲を支援するためにその２ビットを定義することができることにまた注意するべきである。
【００２３】
例として、２ビットが一定範囲を表すために使用されるなら、「００」は範囲０〜１／４に、「０１」は１／４〜１／２に、「１０」は１／２〜３／４に、「１１」は３／４〜１００パーセントに対して利用することができる。これら記述されたものとは異なり別の範囲を表すために任意のビットの組み合わせをも使用することができることに注意するべきである。不均一な範囲に対して同様の規則を使用可能である（例えば、「００」はトークンなしを表し、「０１」は１／４トークン未満を表し、以下同様）。
【００２４】
上で記述されたようにｅＮＢ２２０が同期することを支援するために、ＷＴＲＵ２１０は、ＷＴＲＵ２１０に関連する情報の全てのまたは全体の一部のみをｅＮＢ２２０に報告する。従ってｅＮＢ２２０はＷＴＲＵの状況を承知しており、そして正確な許可判定を発行し、許可ロスを回避する支援をすることが可能である。さらにＷＴＲＵ２１０は、それぞれのＲＢ、ＲＢのグループ、すべてのＲＢ、高優先度のＲＢのみ、または任意の組み合わせに対して報告することができる。ＷＴＲＵ２１０はまた、自身のバッファー状態（例えば許可要求）において、ＷＴＲＵ２１０が少なくとも１つのパケット（例えば最小のＴＢ（Ｔｒａｎｓｐｏｒｔ Ｂｌｏｃｋ：トランスポート・ブロック）のサイズ）を送るために充分なトークンを蓄積するであろう目標時間を指定し、ｅＮＢ２２０が当該示された時間にまたはその後に許可をスケジューリングできるようにすることができる。ＷＴＲＵ２１０は、ＴＴＩ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ Ｉｎｔｅｒｖａｌ：送信時間間隔）毎に、またはＲＢ確立または修正処理の間のＲＲＣ信号方式により設定することができるいくつかのＴＴＩ毎に、情報の任意の部分、または全てを報告可能である。
【００２５】
ＷＴＲＵ２１０は、自身の報告またはトークン・バケット情報を定期的に送信する（ステップ４１０）ことができ、または予め定義されたイベントによりそれをトリガーすることができる。報告をトリガーするために利用することができるイベントは、予め記述された情報に対する値が閾値を超過するか、または下回るというイベントを含む。例えば、あるＲＢまたはＲＢ群に対するトークンの量が、予め定義された閾値を下回るなら、報告するべくＷＴＲＵ２１０をトリガーすることができる。閾値は、ＲＢ確立にてＲＲＣ信号方式により設定することができ、そしてトークン・バケットの最大のサイズの一部分（ｆｒａｃｔｉｏｎ）であると定義することができる。
【００２６】
この様に、ＷＴＲＵ２１０の状態情報（例えばバッファー状態）は、スライディング・ウィンドウ（ｓｌｉｄｉｎｇ ｗｉｎｄｏｗ）上でＷＴＲＵ２１０により評価することができるが、ｅＮＢ２２０にはＴＴＩ毎または２以上のＴＴＩの後に送ることができる。
【００２７】
ステップ４２０においては、ＷＴＲＵ２１０がいくつのトークンを蓄積可能であるかをｅＮＢ２２０が判定する。一実施形態においては、それぞれのアプリケーションおよびネットワークへの信号に対応するそれぞれのバケットに重みを提供する。これらの重み付けされた値は累積値の形に形成され、ＷＴＲＵ２１０に信号送出することができる。全てが同一のレートにてパケットを送信する種々のＷＴＲＵ２１０に関してたとえ複数のＲＢがあっても、アプリケーションの優先度によっては、あるＷＴＲＵ２１０が、より多くの資源を要求するかもしれない。従って優先度は、ＮＷから信号送出された重みに基づき種々のＷＴＲＵ２１０の間で共有することが可能である。
【００２８】
ｅＮＢ２２０が許可割り付けをするために必要とするすべての情報を得ると、ｅＮＢ２２０はＷＴＲＵ２１０に許可割り付けを信号で知らせる（ステップ４３０）。ｅＮＢ２２０は、個々のＷＴＲＵ２１０、ＷＴＲＵ２１０のグループ、または無線通信システム２００中のすべてのＷＴＲＵ２１０に対して、許可割り付けを信号送出することができることが理解されるべきである。
【００２９】
図５は、ＵＬ欠乏状態回避を支援する代替の方法５００のフロー図である。ステップ５１０において、ＷＴＲＵ２１０は自身のバッファー状態を判定する。一例においてはＷＴＲＵ２１０は、自身のバッファー状態を計算しかつ評価し、そしてその評価に基づきｅＮＢ２２０に許可要求を送信することができる（ステップ５２０）。
【００３０】
許可要求は、ＴＴＩ毎またはいくつかのＴＴＩ毎に送られる相対的または絶対的要求であることが可能である。相対的または絶対的許可要求の何れを送るか、およびＷＴＲＵからどのような頻度にて許可を送るべきであるかは、ＲＢ確立または修正段階にてＲＲＣ信号方式により設定されるべきである。例えば相対的許可要求は、以前使用された値に対して相対するものであり、そして前の許可および現在の許可からＷＴＲＵ２１０が実際の許可を導出可能なように変更分がＷＴＲＵ２１０に信号送出される。絶対的許可に対しては、ＷＴＲＵ２１０が使用するべき値が、ＷＴＲＵ２１０が何らかの導出を為す必要性なしで表される。
【００３１】
許可要求は「ハッピー・ビット（Ｈａｐｐｙ Ｂｉｔ）」の形態であることができ、単一ビットまたは複数のビットがハッピー・ビット形式にてｅＮＢ２２０に送信される。単一ビットの許可要求が利用される場合には、その単一ビットは、全てのＲＢの（例えば、ＰＢＲ、ＧＢＲ、ＭＢＲ、ａＭＢＲに対する）、ＷＴＲＵバッファー占有状態、パケット情報、電力残量、トークン残量、および同様のものなどの、全ての種々の属性に対する評価結果を代表するべきである。
【００３２】
ハッピー・ビットは、１つのＲＢに対する状態かまたはそれぞれのＲＢの属性のみを表すことができ、そしてスライディング・ウィンドウ（ｓｌｉｄｉｎｇ ｗｉｎｄｏｗ）上で評価することができる。ハッピー・ビットは、あらゆるＲＢ、高優先度ＲＢ、またはその任意の組み合わせを表すことができ、そしてＴＴＩ毎または多くのＴＴＩの後にｅＮＢ２２０に報告することができる。ハッピー・ビットはまた、ＷＴＲＵ２１０が希望する許可要求の量を表すことができる。
【００３３】
許可要求が複数のビットを含むなら、１ビットは、１つのＲＢかまたはＲＢの（例えば、優先度およびなどと同様の特性を有する）グループのすべての属性を代表するものであり得るか、またはその１ビットは、すべてのＲＢの１つの属性を代表するもの（例えば、トークン残量、ＢＯ、または電力残量）であり得る。さらに複数のビットは、許可要求に対するＷＴＲＵ２１０の状態の様々な組み合わせを表すインデックスとして使用することが可能である。例えばその複数のビットは、ＷＴＲＵ２１０がトークン、電力、またはデータ制限であるかを表すことができる。許可要求目的のためより多くのビットが必要であるなら、ＷＴＲＵ２１０からの許可要求を表すために、ＢＳＲ（Ｂｕｆｆｅｒ Ｓｔａｔｕｓ Ｒｅｐｏｒｔ：バッファー状態報告）を使用することが可能である。
【００３４】
下の表１は、種々の許可対状態表示要求を反映する対応付けを表す一例のインデックスを示す。
【００３５】
【表１】
【００３６】
上の表１において示されるように、ＷＴＲＵ２１０がトークン制限か、電力制限か、データ制限か、またはそれらの何れかの組み合わせであるかを、いくつかのインデックス値が表す。表１は一例の対応付けを示すが、他の対応付けもまた利用することができ、そして他の制限を報告することができることに注意するべきである。例えばＷＴＲＵ２１０は、ＷＴＲＵ２１０のデータを送信するためにＷＴＲＵ２１０に与えられたＴＴＩの数が不十分であったと言うことを含むことができる。ＷＴＲＵ２１０から情報を受け取った後に、ｅＮＢ２２０はＷＴＲＵ２１０に許可を信号送出する（ステップ５３０）。
【００３７】
ＵＬ欠乏状態回避を支援するために、支援に向けられたパラメータを含むＲＲＣ信号方式を必要とする場合がある。下の表２は、ＵＬ欠乏状態回避を支援するための例としてのＲＲＣパラメータを示し、ＩＥ（Ｉｎｆｏｒｍａｔｉｏｎ Ｅｌｅｍｅｎｔ：情報要素）に種別が対応付けられる。
【００３８】
【表２】
【００３９】
信号送出される必要がある場合があるもうひとつのパラメータは、トークン・バケットがマイナスになることが許容されるか否かである。この追加的パラメータは、トークン・バケット実施方法の種々の変形を可能にする。例えば、いくつかのＷＴＲＵ２１０は、パケットを送るために十分な数のトークンがあるかをチェックすることを欲する場合があるが、一方でトークン・バケットの他の実施方法では、トークンの数が０より大きい限り、ＷＴＲＵ２１０はパケットを送ることを許容されることになる。後者の実施方法においては、トークン・バケットはマイナスになることが許容される。トークン・バケットの実施方法がマイナスのトークン・バケットを可能にするか否かは、ＷＴＲＵ２１０がｅＮＢ２２０にこのパラメータを信号送出するか、またはネットワークがｅＮＢ２２０を介してＷＴＲＵ２１０にそれを信号送出するか、の何れかの、追加的信号方式パラメータであることが可能である。信号方式の組み合わせをもまた、支援することができる。
【００４０】
下の表３は、表２において示されたパラメータに加えて信号送出することができる例としてのトークン・バケット・パラメータを示す。
【００４１】
【表３】
【００４２】
ＲＢ確立または修正段階にて、ＲＲＣメッセージを通して多くのパラメータが信号送出される必要があることが起こり得る。トークン・バケットに関係するパラメータは、準静的であり、そして許可毎に更新する必要はないため、トークン・バケットに関係するパラメータが信号送出されねばならなくとも、ネットワークは、それらのパラメータ（例えば、バケットのサイズ、トークンの到着時間間隔、および同様のもの）を必ずしも許可毎において含む必要はない。代わりに、ＲＢ確立において最初にまたはＲＢ修正の間に、それらのパラメータを信号送出することが可能である。表２または表３において記述されたトークン・バケット・パラメータの何れかを更新する必要がある場合には、ｅＮＢ２２０からＷＴＲＵ２１０へはそれらのパラメータのみが信号送出される必要がある。従って表２または表３において記述されたパラメータを利用して、ＷＴＲＵ２１０が支援することが可能なトークン到着時間間隔の「範囲（ｒａｎｇｅ）」、および／または「細かさ（ｇｒａｎｕｌａｒｉｔｙ）」、ならびにＷＴＲＵ２１０が支援することが可能な最小のおよび／または最大のバケットのサイズなどの、ＷＴＲＵ２１０の能力、ならびに同様のものが信号送出される。例えば、ＲＲＣ接続再構成（ｒｅ−ｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを通してＲＢ確立または修正段階にてこれらのパラメータを信号送出することができる。
【００４３】
表２および表３において定義されたパラメータに代わるものとして、それぞれのＲＢに対して、インデックスを貼り付けたそれぞれのトークン・バケットに関係するパラメータの種々の変形を有する表を予め定義することができる。そのＲＢに対するそれぞれのトークンに関係するパラメータのインデックスを次に信号送出することができる。１つのＲＢに対するトークンに関連するパラメータの種々の組み合わせに対してもまた、インデックスを提供することができ、そのＲＢの関連するトークン・パラメータに対する１つのインデックスのみが信号送出される。ＧＢＲ、およびＧＢＲまたはＭＢＲトークン・バケットなどの非ＧＢＲに対するパラメータは、信号方式目的のために１つのインデックス表を共有することができる。あるいは、種々のＲＢに対する種々のトークンに関連するパラメータを１つの表の形式にてインデックスを提供することができる。しかしながら、１つのＲＢのＧＢＲまたはＭＢＲに対して１式のパラメータのみがある場合には、規格化するなど、これらのパラメータを事前に定義することが可能であり、そして信号送出することを必要とはしない場合がある。従ってインデックスは、１つのＲＢに関連するパラメータか、または複数のＲＢに関連するパラメータを含むことができる。
【００４４】
ＷＴＲＵ２１０はまた、トークン関連のパラメータを局所的に格納し、そして適切なパラメータをネットワークに通信することができる。例えばＷＴＲＵ２１０は、それ自身の実施方法に依存するトークン・バケットのサイズ、トークンの到着周期を持つことができる。この場合には、必要ならこれらのパラメータを信号送出することによりそれはネットワークに通知することができる。一例においてはこの信号方式は、ＷＴＲＵ能力情報報告の形態である場合がある。
【００４５】
機能および要素が特定の組み合わせにて上にて記述されているが、それぞれの機能または要素は、他の機能および要素なしで単独にて、または他の機能および要素のあるなしに拘わらず様々な組み合わせにて使用可能である。ここに提供される方法またはフロー図は、汎用目的のコンピューターまたは処理装置による実行のための、コンピューターにて読み取り可能な記憶媒体にて具現化されるコンピューター・プログラム、ソフトウェア、またはファームウェアにて実施することができる。コンピューターにて読み取り可能な記憶媒体の例としては、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ：リード・オンリー・メモリ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ：ランダム・アクセス・メモリ）、レジスター、キャッシュ・メモリ、半導体メモリ・デバイス、内蔵ハード・ディスクおよび着脱可能ディスクなどの磁気媒体、磁気−光学媒体、ならびにＣＤ−ＲＯＭディスクおよびＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ：デジタル多用途ディスク）などの光学媒体が含まれる。
【００４６】
適切な処理装置の例としては、汎用目的処理装置、専用目的処理装置、従来の処理装置、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ：デジタル信号処理装置）、複数のマイクロ処理装置、ＤＳＰコアに関連付けられた１つまたは複数のマイクロ処理装置、制御装置、マイクロ制御装置、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ：特定用途向けＩＣ）、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）回路、他の何れかの種別のＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ：集積回路）、および／または状態マシンが含まれる。
【００４７】
ＷＴＲＵ（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ Ｒｅｃｅｉｖｅ Ｕｎｉｔ：無線送受信ユニット）、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ユーザー機器）、端末、基地局（ｂａｓｅ ｓｔａｔｉｏｎ）、ＲＮＣ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ：無線ネットワーク制御装置）、または任意のホスト・コンピューターにおいて使用するための無線周波数送受信機を実施するために、ソフトウェアに関連付けられた処理装置を使用することができる。ＷＴＲＵは、ハードウェアおよび／またはソフトウェアにて実施され、カメラ、ビデオ・カメラ・モジュール、テレビ電話、スピーカーフォン、振動デバイス、スピーカー、マイクロホン、テレビ送受信機、ハンズフリー受話器、キーボード、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ（登録商標））モジュール、ＦＭ（Ｆｒｅｑｕｅｎｃｙ Ｍｏｄｕｌａｔｅｄ：周波数変調された）無線ユニット、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ：液晶表示）表示ユニット、ＯＬＥＤ（Ｏｒｇａｎｉｃ Ｌｉｇｈｔ−Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ：有機発光ダイオード）表示ユニット、デジタル音楽プレーヤー、メディア・プレーヤー、テレビゲーム・プレーヤー・モジュール、インターネット・ブラウザー、ならびに／または任意のＷＬＡＮ（Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ：無線ＬＡＮ）またはＵＷＢ（Ｕｌｔｒａ Ｗｉｄｅ Ｂａｎｄ：超広帯域無線）モジュールなどのモジュールと連動して使用することができる。
【００４８】
実施形態
１．ＷＴＲＵ（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ Ｒｅｃｅｉｖｅ Ｕｎｉｔ：無線送受信ユニット）に実装されたＵＬ（ＵｐＬｉｎｋ：アップリンク）欠乏状態回避のための方法。
【００４９】
２．現在のバッファー状態情報を判定することをさらに具備する、実施形態１の方法。
【００５０】
３．現在のバッファー状態情報をｅＮＢ（ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ：高度化ノードＢ）に報告することをさらに具備する、前の何れかの実施形態における方法。
【００５１】
４．ｅＮＢから許可を受信することをさらに具備することであって、前記許可が、ＷＴＲＵが蓄積することができるトークンの数の判定を含む、前の何れかの実施形態における方法。
【００５２】
５．現在のバッファー状態情報は、少なくとも１つのＲＢ（Ｒａｄｉｏ Ｂｅａｒｅｒ：無線ベアラ）に対する情報を含む、前の何れかの実施形態における方法。
【００５３】
６．現在のバッファー状態情報が、複数のＲＢに対する情報を含む、前の何れかの実施形態における方法。
【００５４】
７．ＷＴＲＵが蓄積することができるトークンの数の判定は、少なくとも１つのＲＢに対する現在のトークン・バケットのサイズに基づく、前の何れかの実施形態における方法。
【００５５】
８．トークン・バケットのサイズは、以下の：ＧＢＲ（Ｇｕａｒａｎｔｅｅｄ Ｂｉｔ Ｒａｔｅ：保証伝送レート）、ＭＢＲ（Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ：上限伝送レート）、および／またはＰＢＲ（Ｐｒｉｏｒｉｔｉｚｅｄ Ｂｉｔ Ｒａｔｅ：優先伝送レート）、の何れかに対するものである、前の何れかの実施形態における方法。
【００５６】
９．複数のＲＢに対するトークンの集約数を報告することをさらに具備する、前の何れかの実施形態における方法。
【００５７】
１０．報告するステップをトリガーすることをさらに具備する、前の何れかの実施形態における方法。
【００５８】
１１．報告をトリガーすることは、ＲＢに対するトークンの値が予め定義された閾値より下まで減少していることを含む、前の何れかの実施形態における方法。
【００５９】
１２．現在のバッファー状態情報は、ＢＯ（Ｂｕｆｆｅｒ Ｏｃｃｕｐａｎｃｙ：バッファー占有率）情報を含む、前の何れかの実施形態における方法。
【００６０】
１３．少なくとも１つのパケットを送るために十分なトークンがそれにより蓄積されるであろう目標時間を報告することをさらに具備する、前の何れかの実施形態における方法。
【００６１】
１４．バッファー状態を評価することをさらに具備する、前の何れかの実施形態における方法。
【００６２】
１５．バッファー状態の評価に基づき許可要求を送信することをさらに具備する、前の何れかの実施形態における方法。
【００６３】
１６．バッファー状態を計算することを具備する、前の何れかの実施形態における方法。
【００６４】
１７．許可要求は、少なくとも１ビットを含む、前の何れかの実施形態における方法。
【００６５】
１８．許可要求は、複数のビットをさらに具備する、前の何れかの実施形態における方法。
【００６６】
１９．少なくとも１ビットは、少なくとも１つのＲＢ（Ｒａｄｉｏ Ｂｅａｒｅｒ：無線ベアラ）の少なくとも１つの属性を表す、前の何れかの実施形態における方法。
【００６７】
２０．許可要求は、少なくとも１つのトークン・バケット・パラメータを含む、前の何れかの実施形態における方法。
【００６８】
２１．トークン・バケット中のパケット送信のためのトークンの値が閾値を超過するか否かを判定することをさらに具備する、前の何れかの実施形態における方法。
【００６９】
２２．少なくとも１つのパケットを送信することをさらに具備する、前の何れかの実施形態における方法。
【００７０】
２３．少なくとも１つの送信パケットのサイズに等価なトークンの値をトークン・バケットから差し引くことをさらに具備する、前の何れかの実施形態における方法。
【００７１】
２４．トークン・バケットからトークンの値を差し引くことは、トークンの数をゼロ未満に減少させる、前の何れかの実施形態における方法。
【００７２】
２５．トークン・バケット中のパケット送信のためのトークンの最小の数を表す設定パラメータを受信することをさらに具備する、前の何れかの実施形態における方法。
【００７３】
２６．少なくとも１つのパケットを送信することは、トークン・バケット中のトークンの数をトークンの最小の数未満に減少させることになるか否かを判定することをさらに具備する、前の何れかの実施形態における方法。
【００７４】
２７．判定に基づき少なくとも１つのパケットを送信することをさらに具備する、前の何れかの実施形態における方法。
【００７５】
２８．設定パラメータは、パケット送信のための前記トークンの最小の数がゼロ未満であることを表す、前の何れかの実施形態における方法。
【００７６】
２９．設定パラメータは、前記トークンの最小の数を明示的に表す、前の何れかの実施形態における方法。
【００７７】
３０．前の何れかの実施形態における方法を実行するように構成されているＷＴＲＵ。
【００７８】
３１．受信機をさらに具備する、実施形態３０のＷＴＲＵ。
【００７９】
３２．送信機をさらに具備する、実施形態３０〜３１の何れかのＷＴＲＵ。
【００８０】
３３．前記受信機および前記送信機と通信状態にある処理装置をさらに具備する、実施形態３０〜３２の何れかのＷＴＲＵ。
【００８１】
３４．処理装置は、現在のバッファー状態情報を判定するように構成されている、実施形態３０〜３３の何れかのＷＴＲＵ。
【００８２】
３５．処理装置は、現在のバッファー状態情報をｅＮＢに報告するように構成されている、実施形態３０〜３４の何れかのＷＴＲＵ。
【００８３】
３６．処理装置は、ｅＮＢから許可を受信するように構成され、前記許可は、前記ＷＴＲＵが蓄積することができるトークンの数の判定を含む、実施形態３０〜３５の何れかのＷＴＲＵ。
【００８４】
３７．処理装置は、バッファー状態情報中に少なくとも１つのＲＢに対する情報を含めるように構成されている、実施形態３０〜３６の何れかのＷＴＲＵ。
【００８５】
３８．処理装置は、バッファー状態情報中に複数のＲＢに対する情報を含めるように構成されている、実施形態３０〜３７の何れかのＷＴＲＵ。
【００８６】
３９．処理装置は、トークン・バケット中のパケット送信のためのトークンの値が閾値を超過するか否かを判定するように構成されている、実施形態３０〜３８の何れかのＷＴＲＵ。
【００８７】
４０．処理装置は、少なくとも１つのパケットを送信するように、および前記少なくとも１つの送信パケットのサイズに等価なトークンの値をトークン・バケットから差し引くように構成されている、実施形態３０〜３９の何れかのＷＴＲＵ。
【００８８】
４１．前記トークン・バケットから前記トークンの値を前記差し引くことは、前記トークンの数をゼロ未満に減少させる、実施形態３０〜４０の何れかのＷＴＲＵ。
【００８９】
４２．閾値は、設定パラメータによって前記ＷＴＲＵに示される、実施形態３０〜４１の何れかのＷＴＲＵ。
【００９０】
４３．設定パラメータは、明示的に信号送出される、実施形態３０〜４２の何れかのＷＴＲＵ。
【００９１】
４４．実施形態１〜２９の何れかの方法を実行するように構成されている、ｅＮＢ。
【００９２】
４５．受信機をさらに具備する、実施形態４４のｅＮＢ。
【００９３】
４６．送信機をさらに具備する、実施形態４４〜４５の何れかのｅＮＢ。
【００９４】
４７．前記受信機および前記送信機と通信状態にある処理装置をさらに具備する、実施形態４４〜４６の何れかのｅＮＢ。
【００９５】
４８．処理装置は、ＷＴＲＵから現在のバッファー状態情報を受信するように構成されている、実施形態４４〜４７の何れかのｅＮＢ。
【００９６】
４９．処理装置は、ＷＴＲＵが蓄積することが可能なトークンの数を判定するように構成されている、実施形態４４〜４８の何れかのｅＮＢ。
【００９７】
５０．処理装置は、許可をＷＴＲＵに送信するように構成されている、実施形態４４〜４９の何れかのｅＮＢ。
【技術分野】
【０００１】
この出願は無線通信に関する。
【背景技術】
【０００２】
３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ：第３世代パートナーシップ・プロジェクト）ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ：長期進化型）プログラムは、新しいＬＴＥ設定および構成に向けての、新技術、新しいアーキテクチャ、および新しい方法をもたらそうとしている。ＬＴＥプログラムは、スペクトル効率の改善、待ち時間の削減、および無線資源のより上手い利用を提供するために進められ、これにより、より速いユーザー体験、ならびにより少ない費用によるより豊かなアプリケーションおよびサービスが提供される。
【０００３】
Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ：発展型ＵＴＲＡＮ）およびＵＴＲＡＮの目的は高いデータレート、低遅延、改良されたシステム容量および改良された適用範囲（coverage）を有する、パケットに最適化されたシステムに向けて適合された無線アクセス・ネットワークを開発することである。これを達成するために、無線ネットワーク・アーキテクチャと共に無線インターフェイスの進化が必要となる場合がある。例えば、現在３ＧＰＰで使用されるようなＣＤＭＡ（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：符号分割多元接続）無線インターフェイス技術を使用するのではなく、ＤＬ（ＤｏｗｎＬｉｎｋ：ダウンリンク）およびＵＬ（ＵｐＬｉｎｋ：アップリンク）送信においてそれぞれＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：直交周波数分割多元接続）およびＦＤＭＡ（Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：周波数分割多元接続）を使用する場合がある。さらに、ＬＴＥは全パケット交換のサービスを採用することができ、これはすべての音声通話もがパケット交換に基づき為されることを意味するであろう。
【０００４】
無線資源が制限されているシナリオにおいては、ビデオ会議などの高優先度のサービスは、ＷＴＲＵ（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ Ｒｅｃｅｉｖｅ Ｕｎｉｔ：無線送受信ユニット）に割り当てられる無線資源から可能な限り多くの利用可能な無線資源を獲得するべく試みる。アプリケーションの間で許可された資源を如何に分配するかに関してＮＷ（ＮｅｔＷｏｒｋ：ネットワーク）は制御しないため、このことが、より高優先度フローが利用可能な帯域幅まで拡大すると、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などの低優先度のフローが欠乏状態になることをもたらす場合がある。
【０００５】
ＨＳＵＰＡ（Ｈｉｇｈ Ｓｐｅｅｄ Ｕｐｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ：高速アップリンク・パケット・アクセス）においては、拡張版ＵＬは既存のＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ：サービス品質）モデルで構築された。このモデルにおいては、ネットワークが無線資源をＷＴＲＵに許可した場合には、ＷＴＲＵは、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ：無線資源制御）信号方式により供給されるそれぞれのフローに対して関連付けられた優先度を使用して、何れのアップリンクＱｏＳフローを提供すべきかを選択することに対して責任がある。この方式においては、ネットワークが低優先度フローの資源欠乏状態（ｒｅｓｏｕｒｃｅ ｓｔａｒｖａｔｉｏｎ）を回避するためには、より高い優先度のフローと同じ優先度をそれらのフローに提供することを必要とする場合がある。そうであっても、これらのフローを本質的に一まとめに集約することによって、ＷＴＲＵはそれぞれのフローに、それぞれの待ち行列に対する等しい送信権を割り当てる。
【０００６】
ＲＡＮ２（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ２：無線アクセス・ネットワーク２）におけるＵＬ欠乏状態問題を解決するために２つの提案がある。１つはＮＷ中心の解決策であり、そして他方がＷＴＲＵ中心の解決策である。ＮＷ中心の解決策は、ＷＴＲＵからデータを受信した後にＮＷによって行われる送信後トラフィックの監視により特徴付けられる。ＧＢＲ（Ｇｕａｒａｎｔｅｅｄ Ｂｉｔ Ｒａｔｅ：保証伝送レート）、ＭＢＲ（Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ：上限伝送レート）、およびＰＢＲ（Ｐｒｉｏｒｉｔｉｚｅｄ Ｂｉｔ Ｒａｔｅ：優先伝送レート）情報をＷＴＲＵに送信するべきではない。
【０００７】
ＷＴＲＵ中心の解決策は、伝送前のトラフィック監視を含むことができる。トラフィック監視は、データが無線を通して送信される前にＷＴＲＵにより実行され、そしてＲＢ（Ｒａｄｉｏ Ｂｅａｒｅｒ：無線ベアラ）確立または修正時にＧＢＲ、ＭＢＲ、およびＰＢＲ情報をＷＴＲＵに送信することができる。ＷＴＲＵ中心の解決策は、ＬＴＥにおけるＵＬ欠乏状態回避に使用でき、そしてトークン・バケットの数に基づき指定することができる。図１は、一例のトークン・バケット構成１００を示す。
【０００８】
図１において示されるように、トークンは、あるレート（例えばトークン数／セクション）に従ってそれぞれのバケットに加えられる。Ｘトークン分のサイズのパケットをスケジューリングしてＷＴＲＵから送出するために、ＷＴＲＵは、このパケットの送出が可能な充分なトークンがあるか（すなわち、パケットのサイズ＜＝トークン・バケットのサイズ、であるか）、を確認するために、現在のトークン・バケットのサイズをチェックし、そして充分なトークンがあれば、ＷＴＲＵはパケットを送出することができる。パケットの送出を可能にするために充分なトークンがなければ、ＷＴＲＵはその時点ではパケットを送出しないことになるが、十分な数のトークンが蓄積されればそれを送出することができる。
【０００９】
しかしながら、ＬＴＥシステムにおけるＵＬ欠乏状態回避に対してＷＴＲＵ中心の解決策を使用する場合、様々な問題がある。ＲＡＮ２においてはＢＳＲ（Ｂｕｆｆｅｒ Ｓｔａｔｕｓ Ｒｅｐｏｒｔｉｎｇ：バッファー状態報告）と設定されたＭＢＲ／ＧＢＲとの間の関係を扱えないので、目前の（ｉｍｐｅｎｄｉｎｇ）許可のロス問題が生ずる場合がある。許可のロス（ｇｒａｎｔ ｌｏｓｓ：許可ロス）が発生すると、信号方式のオーバーヘッド、資源割り付けのロス等が発生する場合がある。
【００１０】
一般に許可ロスは、ＷＴＲＵが許可を受け取っているが、それを完全には利用できないことを意味する。ＷＴＲＵは何れのレートにより許可を受け取ることになるかを知らないので、あるバッファーレベルを取り扱うときにこのバッファーレベルが設定されたＭＢＲ／ａＭＢＲ（ａｇｇｒｅｇａｔｅ ＭＢＲ：集約されたＭＢＲ）を上回ることになるか否かをＷＴＲＵが予め判定することを困難にしているため、許可ロスが発生する場合がある。このように現時点では、ＢＳＲを報告する際にＷＴＲＵが設定されたＭＢＲ／ａＭＢＲを考慮に入れるための機構が無い。結果として、ＷＴＲＵがあるバッファーレベルを報告しても、このバッファーレベルを取り扱うためのＵＬ許可を獲得しようとしているときには、設定されたＭＢＲ／ａＭＢＲを越えることを意味することになるため、その関係するＳＡＥベアラをスケジュールすることができない、という状況が発生するかもしれない。これこそが「許可ロス（ｇｒａｎｔ ｌｏｓｓ）」と呼ぶことができるものある。ｅＮＢ（ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ：高度化ノードＢ）がただＢＳＲにおいて表されたデータに対応して許可を提供するのみであっても、許可ロスは発生する場合がある。
【００１１】
したがって、ＬＴＥシステムにおいてＵＬ欠乏状態回避を支援するための方法および装置を提供することは有益であろう。
【発明の概要】
【００１２】
ＵＬ（ＵｐＬｉｎｋ：アップリンク）欠乏状態回避のための方法および装置が開示される。この方法は、現在のバッファー状態情報を判定することを含む。現在のバッファー状態情報は、ｅＮＢ（ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ：高度化ノードＢ）に報告される。ＷＴＲＵ（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ Ｒｅｃｅｉｖｅ Ｕｎｉｔ：無線送受信ユニット）が蓄積することができるトークンの数の判定を含む許可をそのｅＮＢから受け取る。
【００１３】
添付された図面に関連して例として与えられる以下の記述から、より詳細な理解を得ることができる。
【図面の簡単な説明】
【００１４】
【図１】一例のトークン・バケット構成を示す図である。
【図２】複数のＷＴＲＵおよび１つのｅＮＢを含む一例の無線通信システムを示す図である。
【図３】図２のＷＴＲＵおよびｅＮＢの一例の機能的ブロック図である。
【図４】ＵＬ欠乏状態回避を支援する方法のフロー図である。
【図５】ＵＬ欠乏状態回避を支援する代替の方法のフロー図である。
【発明を実施するための形態】
【００１５】
これ以後参照されると、用語「ＷＴＲＵ（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ Ｒｅｃｅｉｖｅ Ｕｎｉｔ：無線送受信ユニット）」は、限定的ではなく、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ユーザー機器）、移動端末、固定型または移動体の加入者ユニット、ページャー、携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ：携帯情報端末）、コンピューター、または無線環境において動作する能力のある他の如何なる種別のユーザー・デバイスをも含む。これ以後参照されると、用語「基地局（ｂａｓｅ ｓｔａｔｉｏｎ）」は、限定的ではなく、ノードＢ（Ｎｏｄｅ−Ｂ）、サイトコントローラー、ＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ：アクセス・ポイント）、または無線環境において動作する能力のある他の如何なる種別のインターフェイス・デバイスをも含む。
【００１６】
図２は、複数のＷＴＲＵ２１０および１つのｅＮＢ２２０を含む無線通信システム２００を示す。図２に示されるように、ＷＴＲＵ２１０はｅＮＢ２２０と通信状態にある。図２においてはＷＴＲＵ２１０および基地局２２０という一例の構成が表現されるが、無線通信システム２００においては、無線のそして有線の装置の何れの組み合わせをも含むことができることに注意するべきである。
【００１７】
図３は、図２の無線通信システム２００のＷＴＲＵ２１０およびｅＮＢ２２０の機能的ブロック図３００である。図３に示されるように、ＷＴＲＵ２１０はｅＮＢ２２０と通信状態にあり、そして両方がアップリンク欠乏状態回避を支援する方法を実行するように構成されている。
【００１８】
典型的なＷＴＲＵにおいて見出すことができる構成要素に加えて、ＷＴＲＵ２１０は処理装置２１５、受信機２１６、送信機２１７、およびアンテナ２１８を含む。処理装置２１５は、アップリンク欠乏状態回避を支援する方法を実行するように構成されている。受信機２１６および送信機２１７は、処理装置２１５と通信状態にある。アンテナ２１８は、受信機２１６および送信機２１７の両方と通信状態にあり、無線データの送信および受信を容易にする。
【００１９】
典型的なｅＮＢにおいて見出すことができる構成要素に加えて、ｅＮＢ２２０は処理装置２２５、受信機２２６、送信機２２７、およびアンテナ２２８を含む。処理装置２２５は、アップリンク欠乏状態回避を支援する方法を実行するように構成されている。受信機２２６および送信機２２７は、処理装置２２５と通信状態にある。アンテナ２２８は、受信機２２６および送信機２２７の両方と通信状態にあり、無線データの送信および受信を容易にする。
【００２０】
図４は、ＵＬ欠乏状態回避を支援する方法４００のフロー図である。ステップ４１０において、ＷＴＲＵ２１０は現在のバッファー状態情報をｅＮＢ２２０に報告する。この情報には、いくつかのまたはすべてのＲＢに対する情報を含めることができ、そして許可ロスを防ぐように向かわせることができる。この情報には、ＢＯ（Ｂｕｆｆｅｒ Ｏｃｃｕｐａｎｃｙ：バッファー占有率）情報、ＰＢＲ、ＧＢＲ ＭＢＲ、およびｅＭＢＲそれぞれに対するそれぞれのＲＢのトークン・バケットのサイズ、ＷＴＲＵにおけるトークン蓄積パターン、電力残量等を含めることができる。
【００２１】
ＢＯ情報は、１つのＲＢ、ＲＢのグループ、またはすべてのＲＢに対するものであることができ、一方電力残量は、すべてのＲＢに対するものである。トークンのサイズおよびトークン蓄積パターンは、ＲＢに対するＰＢＳ、ＧＢＲ、ＭＢＲ、およびａＭＢＲそれぞれに対するものであることができる。あるいはまた、いくつかのＲＢに対するトークンの集約数を報告し、そして別の集約を個々に報告することができる。例えばＧＢＳ、ＭＢＲ、およびｅＭＢＲに対する集約トークンを、お互いの如何にかかわらず報告することができる。許可がＷＴＲＵ単位であるため、ＷＴＲＵ２１０が利用できるトークンの総数は、許可をスケジューリングするために効率的な方法を提供することが可能である。
【００２２】
ステップ４１０における報告の間に、ＷＴＲＵ２１０はトークン・バケットの最大のサイズに対するトークンの割合を報告することができる。例えば、ＷＴＲＵ２１０がトークン・バケットの最大のサイズの０〜１／４、１／４〜１／２、１／２〜３／４、３／４〜１００パーセントを有することを表すために２ビットを使用することができる。トークンなし、１／４トークン未満、１／４トークンと１／２トークンの間、１／２トークンより大などの不均一な範囲を支援するためにその２ビットを定義することができることにまた注意するべきである。
【００２３】
例として、２ビットが一定範囲を表すために使用されるなら、「００」は範囲０〜１／４に、「０１」は１／４〜１／２に、「１０」は１／２〜３／４に、「１１」は３／４〜１００パーセントに対して利用することができる。これら記述されたものとは異なり別の範囲を表すために任意のビットの組み合わせをも使用することができることに注意するべきである。不均一な範囲に対して同様の規則を使用可能である（例えば、「００」はトークンなしを表し、「０１」は１／４トークン未満を表し、以下同様）。
【００２４】
上で記述されたようにｅＮＢ２２０が同期することを支援するために、ＷＴＲＵ２１０は、ＷＴＲＵ２１０に関連する情報の全てのまたは全体の一部のみをｅＮＢ２２０に報告する。従ってｅＮＢ２２０はＷＴＲＵの状況を承知しており、そして正確な許可判定を発行し、許可ロスを回避する支援をすることが可能である。さらにＷＴＲＵ２１０は、それぞれのＲＢ、ＲＢのグループ、すべてのＲＢ、高優先度のＲＢのみ、または任意の組み合わせに対して報告することができる。ＷＴＲＵ２１０はまた、自身のバッファー状態（例えば許可要求）において、ＷＴＲＵ２１０が少なくとも１つのパケット（例えば最小のＴＢ（Ｔｒａｎｓｐｏｒｔ Ｂｌｏｃｋ：トランスポート・ブロック）のサイズ）を送るために充分なトークンを蓄積するであろう目標時間を指定し、ｅＮＢ２２０が当該示された時間にまたはその後に許可をスケジューリングできるようにすることができる。ＷＴＲＵ２１０は、ＴＴＩ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ Ｉｎｔｅｒｖａｌ：送信時間間隔）毎に、またはＲＢ確立または修正処理の間のＲＲＣ信号方式により設定することができるいくつかのＴＴＩ毎に、情報の任意の部分、または全てを報告可能である。
【００２５】
ＷＴＲＵ２１０は、自身の報告またはトークン・バケット情報を定期的に送信する（ステップ４１０）ことができ、または予め定義されたイベントによりそれをトリガーすることができる。報告をトリガーするために利用することができるイベントは、予め記述された情報に対する値が閾値を超過するか、または下回るというイベントを含む。例えば、あるＲＢまたはＲＢ群に対するトークンの量が、予め定義された閾値を下回るなら、報告するべくＷＴＲＵ２１０をトリガーすることができる。閾値は、ＲＢ確立にてＲＲＣ信号方式により設定することができ、そしてトークン・バケットの最大のサイズの一部分（ｆｒａｃｔｉｏｎ）であると定義することができる。
【００２６】
この様に、ＷＴＲＵ２１０の状態情報（例えばバッファー状態）は、スライディング・ウィンドウ（ｓｌｉｄｉｎｇ ｗｉｎｄｏｗ）上でＷＴＲＵ２１０により評価することができるが、ｅＮＢ２２０にはＴＴＩ毎または２以上のＴＴＩの後に送ることができる。
【００２７】
ステップ４２０においては、ＷＴＲＵ２１０がいくつのトークンを蓄積可能であるかをｅＮＢ２２０が判定する。一実施形態においては、それぞれのアプリケーションおよびネットワークへの信号に対応するそれぞれのバケットに重みを提供する。これらの重み付けされた値は累積値の形に形成され、ＷＴＲＵ２１０に信号送出することができる。全てが同一のレートにてパケットを送信する種々のＷＴＲＵ２１０に関してたとえ複数のＲＢがあっても、アプリケーションの優先度によっては、あるＷＴＲＵ２１０が、より多くの資源を要求するかもしれない。従って優先度は、ＮＷから信号送出された重みに基づき種々のＷＴＲＵ２１０の間で共有することが可能である。
【００２８】
ｅＮＢ２２０が許可割り付けをするために必要とするすべての情報を得ると、ｅＮＢ２２０はＷＴＲＵ２１０に許可割り付けを信号で知らせる（ステップ４３０）。ｅＮＢ２２０は、個々のＷＴＲＵ２１０、ＷＴＲＵ２１０のグループ、または無線通信システム２００中のすべてのＷＴＲＵ２１０に対して、許可割り付けを信号送出することができることが理解されるべきである。
【００２９】
図５は、ＵＬ欠乏状態回避を支援する代替の方法５００のフロー図である。ステップ５１０において、ＷＴＲＵ２１０は自身のバッファー状態を判定する。一例においてはＷＴＲＵ２１０は、自身のバッファー状態を計算しかつ評価し、そしてその評価に基づきｅＮＢ２２０に許可要求を送信することができる（ステップ５２０）。
【００３０】
許可要求は、ＴＴＩ毎またはいくつかのＴＴＩ毎に送られる相対的または絶対的要求であることが可能である。相対的または絶対的許可要求の何れを送るか、およびＷＴＲＵからどのような頻度にて許可を送るべきであるかは、ＲＢ確立または修正段階にてＲＲＣ信号方式により設定されるべきである。例えば相対的許可要求は、以前使用された値に対して相対するものであり、そして前の許可および現在の許可からＷＴＲＵ２１０が実際の許可を導出可能なように変更分がＷＴＲＵ２１０に信号送出される。絶対的許可に対しては、ＷＴＲＵ２１０が使用するべき値が、ＷＴＲＵ２１０が何らかの導出を為す必要性なしで表される。
【００３１】
許可要求は「ハッピー・ビット（Ｈａｐｐｙ Ｂｉｔ）」の形態であることができ、単一ビットまたは複数のビットがハッピー・ビット形式にてｅＮＢ２２０に送信される。単一ビットの許可要求が利用される場合には、その単一ビットは、全てのＲＢの（例えば、ＰＢＲ、ＧＢＲ、ＭＢＲ、ａＭＢＲに対する）、ＷＴＲＵバッファー占有状態、パケット情報、電力残量、トークン残量、および同様のものなどの、全ての種々の属性に対する評価結果を代表するべきである。
【００３２】
ハッピー・ビットは、１つのＲＢに対する状態かまたはそれぞれのＲＢの属性のみを表すことができ、そしてスライディング・ウィンドウ（ｓｌｉｄｉｎｇ ｗｉｎｄｏｗ）上で評価することができる。ハッピー・ビットは、あらゆるＲＢ、高優先度ＲＢ、またはその任意の組み合わせを表すことができ、そしてＴＴＩ毎または多くのＴＴＩの後にｅＮＢ２２０に報告することができる。ハッピー・ビットはまた、ＷＴＲＵ２１０が希望する許可要求の量を表すことができる。
【００３３】
許可要求が複数のビットを含むなら、１ビットは、１つのＲＢかまたはＲＢの（例えば、優先度およびなどと同様の特性を有する）グループのすべての属性を代表するものであり得るか、またはその１ビットは、すべてのＲＢの１つの属性を代表するもの（例えば、トークン残量、ＢＯ、または電力残量）であり得る。さらに複数のビットは、許可要求に対するＷＴＲＵ２１０の状態の様々な組み合わせを表すインデックスとして使用することが可能である。例えばその複数のビットは、ＷＴＲＵ２１０がトークン、電力、またはデータ制限であるかを表すことができる。許可要求目的のためより多くのビットが必要であるなら、ＷＴＲＵ２１０からの許可要求を表すために、ＢＳＲ（Ｂｕｆｆｅｒ Ｓｔａｔｕｓ Ｒｅｐｏｒｔ：バッファー状態報告）を使用することが可能である。
【００３４】
下の表１は、種々の許可対状態表示要求を反映する対応付けを表す一例のインデックスを示す。
【００３５】
【表１】
【００３６】
上の表１において示されるように、ＷＴＲＵ２１０がトークン制限か、電力制限か、データ制限か、またはそれらの何れかの組み合わせであるかを、いくつかのインデックス値が表す。表１は一例の対応付けを示すが、他の対応付けもまた利用することができ、そして他の制限を報告することができることに注意するべきである。例えばＷＴＲＵ２１０は、ＷＴＲＵ２１０のデータを送信するためにＷＴＲＵ２１０に与えられたＴＴＩの数が不十分であったと言うことを含むことができる。ＷＴＲＵ２１０から情報を受け取った後に、ｅＮＢ２２０はＷＴＲＵ２１０に許可を信号送出する（ステップ５３０）。
【００３７】
ＵＬ欠乏状態回避を支援するために、支援に向けられたパラメータを含むＲＲＣ信号方式を必要とする場合がある。下の表２は、ＵＬ欠乏状態回避を支援するための例としてのＲＲＣパラメータを示し、ＩＥ（Ｉｎｆｏｒｍａｔｉｏｎ Ｅｌｅｍｅｎｔ：情報要素）に種別が対応付けられる。
【００３８】
【表２】
【００３９】
信号送出される必要がある場合があるもうひとつのパラメータは、トークン・バケットがマイナスになることが許容されるか否かである。この追加的パラメータは、トークン・バケット実施方法の種々の変形を可能にする。例えば、いくつかのＷＴＲＵ２１０は、パケットを送るために十分な数のトークンがあるかをチェックすることを欲する場合があるが、一方でトークン・バケットの他の実施方法では、トークンの数が０より大きい限り、ＷＴＲＵ２１０はパケットを送ることを許容されることになる。後者の実施方法においては、トークン・バケットはマイナスになることが許容される。トークン・バケットの実施方法がマイナスのトークン・バケットを可能にするか否かは、ＷＴＲＵ２１０がｅＮＢ２２０にこのパラメータを信号送出するか、またはネットワークがｅＮＢ２２０を介してＷＴＲＵ２１０にそれを信号送出するか、の何れかの、追加的信号方式パラメータであることが可能である。信号方式の組み合わせをもまた、支援することができる。
【００４０】
下の表３は、表２において示されたパラメータに加えて信号送出することができる例としてのトークン・バケット・パラメータを示す。
【００４１】
【表３】
【００４２】
ＲＢ確立または修正段階にて、ＲＲＣメッセージを通して多くのパラメータが信号送出される必要があることが起こり得る。トークン・バケットに関係するパラメータは、準静的であり、そして許可毎に更新する必要はないため、トークン・バケットに関係するパラメータが信号送出されねばならなくとも、ネットワークは、それらのパラメータ（例えば、バケットのサイズ、トークンの到着時間間隔、および同様のもの）を必ずしも許可毎において含む必要はない。代わりに、ＲＢ確立において最初にまたはＲＢ修正の間に、それらのパラメータを信号送出することが可能である。表２または表３において記述されたトークン・バケット・パラメータの何れかを更新する必要がある場合には、ｅＮＢ２２０からＷＴＲＵ２１０へはそれらのパラメータのみが信号送出される必要がある。従って表２または表３において記述されたパラメータを利用して、ＷＴＲＵ２１０が支援することが可能なトークン到着時間間隔の「範囲（ｒａｎｇｅ）」、および／または「細かさ（ｇｒａｎｕｌａｒｉｔｙ）」、ならびにＷＴＲＵ２１０が支援することが可能な最小のおよび／または最大のバケットのサイズなどの、ＷＴＲＵ２１０の能力、ならびに同様のものが信号送出される。例えば、ＲＲＣ接続再構成（ｒｅ−ｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを通してＲＢ確立または修正段階にてこれらのパラメータを信号送出することができる。
【００４３】
表２および表３において定義されたパラメータに代わるものとして、それぞれのＲＢに対して、インデックスを貼り付けたそれぞれのトークン・バケットに関係するパラメータの種々の変形を有する表を予め定義することができる。そのＲＢに対するそれぞれのトークンに関係するパラメータのインデックスを次に信号送出することができる。１つのＲＢに対するトークンに関連するパラメータの種々の組み合わせに対してもまた、インデックスを提供することができ、そのＲＢの関連するトークン・パラメータに対する１つのインデックスのみが信号送出される。ＧＢＲ、およびＧＢＲまたはＭＢＲトークン・バケットなどの非ＧＢＲに対するパラメータは、信号方式目的のために１つのインデックス表を共有することができる。あるいは、種々のＲＢに対する種々のトークンに関連するパラメータを１つの表の形式にてインデックスを提供することができる。しかしながら、１つのＲＢのＧＢＲまたはＭＢＲに対して１式のパラメータのみがある場合には、規格化するなど、これらのパラメータを事前に定義することが可能であり、そして信号送出することを必要とはしない場合がある。従ってインデックスは、１つのＲＢに関連するパラメータか、または複数のＲＢに関連するパラメータを含むことができる。
【００４４】
ＷＴＲＵ２１０はまた、トークン関連のパラメータを局所的に格納し、そして適切なパラメータをネットワークに通信することができる。例えばＷＴＲＵ２１０は、それ自身の実施方法に依存するトークン・バケットのサイズ、トークンの到着周期を持つことができる。この場合には、必要ならこれらのパラメータを信号送出することによりそれはネットワークに通知することができる。一例においてはこの信号方式は、ＷＴＲＵ能力情報報告の形態である場合がある。
【００４５】
機能および要素が特定の組み合わせにて上にて記述されているが、それぞれの機能または要素は、他の機能および要素なしで単独にて、または他の機能および要素のあるなしに拘わらず様々な組み合わせにて使用可能である。ここに提供される方法またはフロー図は、汎用目的のコンピューターまたは処理装置による実行のための、コンピューターにて読み取り可能な記憶媒体にて具現化されるコンピューター・プログラム、ソフトウェア、またはファームウェアにて実施することができる。コンピューターにて読み取り可能な記憶媒体の例としては、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ：リード・オンリー・メモリ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ：ランダム・アクセス・メモリ）、レジスター、キャッシュ・メモリ、半導体メモリ・デバイス、内蔵ハード・ディスクおよび着脱可能ディスクなどの磁気媒体、磁気−光学媒体、ならびにＣＤ−ＲＯＭディスクおよびＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ：デジタル多用途ディスク）などの光学媒体が含まれる。
【００４６】
適切な処理装置の例としては、汎用目的処理装置、専用目的処理装置、従来の処理装置、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ：デジタル信号処理装置）、複数のマイクロ処理装置、ＤＳＰコアに関連付けられた１つまたは複数のマイクロ処理装置、制御装置、マイクロ制御装置、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ：特定用途向けＩＣ）、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）回路、他の何れかの種別のＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ：集積回路）、および／または状態マシンが含まれる。
【００４７】
ＷＴＲＵ（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ Ｒｅｃｅｉｖｅ Ｕｎｉｔ：無線送受信ユニット）、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ユーザー機器）、端末、基地局（ｂａｓｅ ｓｔａｔｉｏｎ）、ＲＮＣ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ：無線ネットワーク制御装置）、または任意のホスト・コンピューターにおいて使用するための無線周波数送受信機を実施するために、ソフトウェアに関連付けられた処理装置を使用することができる。ＷＴＲＵは、ハードウェアおよび／またはソフトウェアにて実施され、カメラ、ビデオ・カメラ・モジュール、テレビ電話、スピーカーフォン、振動デバイス、スピーカー、マイクロホン、テレビ送受信機、ハンズフリー受話器、キーボード、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ（登録商標））モジュール、ＦＭ（Ｆｒｅｑｕｅｎｃｙ Ｍｏｄｕｌａｔｅｄ：周波数変調された）無線ユニット、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ：液晶表示）表示ユニット、ＯＬＥＤ（Ｏｒｇａｎｉｃ Ｌｉｇｈｔ−Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ：有機発光ダイオード）表示ユニット、デジタル音楽プレーヤー、メディア・プレーヤー、テレビゲーム・プレーヤー・モジュール、インターネット・ブラウザー、ならびに／または任意のＷＬＡＮ（Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ：無線ＬＡＮ）またはＵＷＢ（Ｕｌｔｒａ Ｗｉｄｅ Ｂａｎｄ：超広帯域無線）モジュールなどのモジュールと連動して使用することができる。
【００４８】
実施形態
１．ＷＴＲＵ（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ Ｒｅｃｅｉｖｅ Ｕｎｉｔ：無線送受信ユニット）に実装されたＵＬ（ＵｐＬｉｎｋ：アップリンク）欠乏状態回避のための方法。
【００４９】
２．現在のバッファー状態情報を判定することをさらに具備する、実施形態１の方法。
【００５０】
３．現在のバッファー状態情報をｅＮＢ（ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ：高度化ノードＢ）に報告することをさらに具備する、前の何れかの実施形態における方法。
【００５１】
４．ｅＮＢから許可を受信することをさらに具備することであって、前記許可が、ＷＴＲＵが蓄積することができるトークンの数の判定を含む、前の何れかの実施形態における方法。
【００５２】
５．現在のバッファー状態情報は、少なくとも１つのＲＢ（Ｒａｄｉｏ Ｂｅａｒｅｒ：無線ベアラ）に対する情報を含む、前の何れかの実施形態における方法。
【００５３】
６．現在のバッファー状態情報が、複数のＲＢに対する情報を含む、前の何れかの実施形態における方法。
【００５４】
７．ＷＴＲＵが蓄積することができるトークンの数の判定は、少なくとも１つのＲＢに対する現在のトークン・バケットのサイズに基づく、前の何れかの実施形態における方法。
【００５５】
８．トークン・バケットのサイズは、以下の：ＧＢＲ（Ｇｕａｒａｎｔｅｅｄ Ｂｉｔ Ｒａｔｅ：保証伝送レート）、ＭＢＲ（Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ：上限伝送レート）、および／またはＰＢＲ（Ｐｒｉｏｒｉｔｉｚｅｄ Ｂｉｔ Ｒａｔｅ：優先伝送レート）、の何れかに対するものである、前の何れかの実施形態における方法。
【００５６】
９．複数のＲＢに対するトークンの集約数を報告することをさらに具備する、前の何れかの実施形態における方法。
【００５７】
１０．報告するステップをトリガーすることをさらに具備する、前の何れかの実施形態における方法。
【００５８】
１１．報告をトリガーすることは、ＲＢに対するトークンの値が予め定義された閾値より下まで減少していることを含む、前の何れかの実施形態における方法。
【００５９】
１２．現在のバッファー状態情報は、ＢＯ（Ｂｕｆｆｅｒ Ｏｃｃｕｐａｎｃｙ：バッファー占有率）情報を含む、前の何れかの実施形態における方法。
【００６０】
１３．少なくとも１つのパケットを送るために十分なトークンがそれにより蓄積されるであろう目標時間を報告することをさらに具備する、前の何れかの実施形態における方法。
【００６１】
１４．バッファー状態を評価することをさらに具備する、前の何れかの実施形態における方法。
【００６２】
１５．バッファー状態の評価に基づき許可要求を送信することをさらに具備する、前の何れかの実施形態における方法。
【００６３】
１６．バッファー状態を計算することを具備する、前の何れかの実施形態における方法。
【００６４】
１７．許可要求は、少なくとも１ビットを含む、前の何れかの実施形態における方法。
【００６５】
１８．許可要求は、複数のビットをさらに具備する、前の何れかの実施形態における方法。
【００６６】
１９．少なくとも１ビットは、少なくとも１つのＲＢ（Ｒａｄｉｏ Ｂｅａｒｅｒ：無線ベアラ）の少なくとも１つの属性を表す、前の何れかの実施形態における方法。
【００６７】
２０．許可要求は、少なくとも１つのトークン・バケット・パラメータを含む、前の何れかの実施形態における方法。
【００６８】
２１．トークン・バケット中のパケット送信のためのトークンの値が閾値を超過するか否かを判定することをさらに具備する、前の何れかの実施形態における方法。
【００６９】
２２．少なくとも１つのパケットを送信することをさらに具備する、前の何れかの実施形態における方法。
【００７０】
２３．少なくとも１つの送信パケットのサイズに等価なトークンの値をトークン・バケットから差し引くことをさらに具備する、前の何れかの実施形態における方法。
【００７１】
２４．トークン・バケットからトークンの値を差し引くことは、トークンの数をゼロ未満に減少させる、前の何れかの実施形態における方法。
【００７２】
２５．トークン・バケット中のパケット送信のためのトークンの最小の数を表す設定パラメータを受信することをさらに具備する、前の何れかの実施形態における方法。
【００７３】
２６．少なくとも１つのパケットを送信することは、トークン・バケット中のトークンの数をトークンの最小の数未満に減少させることになるか否かを判定することをさらに具備する、前の何れかの実施形態における方法。
【００７４】
２７．判定に基づき少なくとも１つのパケットを送信することをさらに具備する、前の何れかの実施形態における方法。
【００７５】
２８．設定パラメータは、パケット送信のための前記トークンの最小の数がゼロ未満であることを表す、前の何れかの実施形態における方法。
【００７６】
２９．設定パラメータは、前記トークンの最小の数を明示的に表す、前の何れかの実施形態における方法。
【００７７】
３０．前の何れかの実施形態における方法を実行するように構成されているＷＴＲＵ。
【００７８】
３１．受信機をさらに具備する、実施形態３０のＷＴＲＵ。
【００７９】
３２．送信機をさらに具備する、実施形態３０〜３１の何れかのＷＴＲＵ。
【００８０】
３３．前記受信機および前記送信機と通信状態にある処理装置をさらに具備する、実施形態３０〜３２の何れかのＷＴＲＵ。
【００８１】
３４．処理装置は、現在のバッファー状態情報を判定するように構成されている、実施形態３０〜３３の何れかのＷＴＲＵ。
【００８２】
３５．処理装置は、現在のバッファー状態情報をｅＮＢに報告するように構成されている、実施形態３０〜３４の何れかのＷＴＲＵ。
【００８３】
３６．処理装置は、ｅＮＢから許可を受信するように構成され、前記許可は、前記ＷＴＲＵが蓄積することができるトークンの数の判定を含む、実施形態３０〜３５の何れかのＷＴＲＵ。
【００８４】
３７．処理装置は、バッファー状態情報中に少なくとも１つのＲＢに対する情報を含めるように構成されている、実施形態３０〜３６の何れかのＷＴＲＵ。
【００８５】
３８．処理装置は、バッファー状態情報中に複数のＲＢに対する情報を含めるように構成されている、実施形態３０〜３７の何れかのＷＴＲＵ。
【００８６】
３９．処理装置は、トークン・バケット中のパケット送信のためのトークンの値が閾値を超過するか否かを判定するように構成されている、実施形態３０〜３８の何れかのＷＴＲＵ。
【００８７】
４０．処理装置は、少なくとも１つのパケットを送信するように、および前記少なくとも１つの送信パケットのサイズに等価なトークンの値をトークン・バケットから差し引くように構成されている、実施形態３０〜３９の何れかのＷＴＲＵ。
【００８８】
４１．前記トークン・バケットから前記トークンの値を前記差し引くことは、前記トークンの数をゼロ未満に減少させる、実施形態３０〜４０の何れかのＷＴＲＵ。
【００８９】
４２．閾値は、設定パラメータによって前記ＷＴＲＵに示される、実施形態３０〜４１の何れかのＷＴＲＵ。
【００９０】
４３．設定パラメータは、明示的に信号送出される、実施形態３０〜４２の何れかのＷＴＲＵ。
【００９１】
４４．実施形態１〜２９の何れかの方法を実行するように構成されている、ｅＮＢ。
【００９２】
４５．受信機をさらに具備する、実施形態４４のｅＮＢ。
【００９３】
４６．送信機をさらに具備する、実施形態４４〜４５の何れかのｅＮＢ。
【００９４】
４７．前記受信機および前記送信機と通信状態にある処理装置をさらに具備する、実施形態４４〜４６の何れかのｅＮＢ。
【００９５】
４８．処理装置は、ＷＴＲＵから現在のバッファー状態情報を受信するように構成されている、実施形態４４〜４７の何れかのｅＮＢ。
【００９６】
４９．処理装置は、ＷＴＲＵが蓄積することが可能なトークンの数を判定するように構成されている、実施形態４４〜４８の何れかのｅＮＢ。
【００９７】
５０．処理装置は、許可をＷＴＲＵに送信するように構成されている、実施形態４４〜４９の何れかのｅＮＢ。
【特許請求の範囲】
【請求項１】
無線送受信ユニット（ＷＴＲＵ）からのアップリンクのデータの送信をスケジューリングするための方法であって、
前記ＷＴＲＵにおけるバッファー中の送信のための未処理のアップリンクのデータの量を判定することと、
ビットレートに対するリソースブロック（ＲＢ）のトークンバケットのサイズに基づき、複数のアップリンクチャンネルと前記複数のアップリンクチャンネルに関連付けられた現在のバッファー状態とを判定することと、
前記未処理のデータの量の判定および前記複数のアップリンクチャンネルの判定に基づいて、バッファー状態報告を提供することと、
提供した前記バッファー状態報告の送信の応答である、前記未処理のアップリンクのデータの送信に対する許可を受信することと
を具備し、前記複数のアップリンクチャンネルについての前記現在のバッファー状態はトークンバケットが負の値であることを示すが、前記未処理のアップリンクのデータの送信が許可される、ことを特徴とする方法。
【請求項２】
前記複数のアップリンクチャンネルに対して：
前記現在のバッファー状態が予め決定された閾値を超過するかを判定することと、
前記現在のバッファー状態が前記予め決定された閾値を超過するという条件において、未処理のアップリンクのデータの少なくとも１つのパケットを送信することと、
送信された前記未処理のアップリンクのデータの少なくとも１つのパケットのサイズだけ減少された前記現在のバッファー状態に等しく、前記現在のバッファー状態を設定することと
をさらに具備することを特徴とする請求項１に記載の方法。
【請求項３】
前記バッファー状態報告は、前のアップリンク許可において割り当てられたアップリンクチャンネル上で送信されることを特徴とする請求項１に記載の方法。
【請求項４】
前記ビットレートは、保証伝送レート（ＧＢＲ）のリソースブロック（ＲＢ）のトークンバケットのサイズ、上限伝送レート（ＭＢＲ）のリソースブロック（ＲＢ）のトークンバケットのサイズ、優先伝送レート（ＰＢＲ）のリソースブロック（ＲＢ）のトークンバケットのサイズ、および集約されたＭＢＲ（ａＭＢＲ）のリソースブロック（ＲＢ）のトークンバケットのサイズ、の内の少なくとも１つを含むことを特徴とする請求項１に記載の方法。
【請求項５】
複数のリソースブロック（ＲＢｓ）についてのトークンの集約数を報告することをさらに具備することを特徴とする請求項１に記載の方法。
【請求項６】
前記バッファー状態報告はリソースブロック（ＲＢ）についてのトークンの値を含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記現在のバッファー状態は、バッファー占有率（ＢＯ）情報を含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記未処理のアップリンクのデータの少なくとも１つのパケットを送信するために十分なトークンが蓄積するであろう目標時間を報告することをさらに具備することを特徴とする請求項１に記載の方法。
【請求項９】
受信部と、
送信部と、
前記受信部および前記送信部と通信するプロセッサと
を備えた無線送受信ユニット（ＷＴＲＵ）であって、前記プロセッサはアップリンクのデータの送信をスケジューリングするように構成されており、
前記プロセッサは、
当該ＷＴＲＵにおけるバッファー中の送信のための未処理のアップリンクのデータの量を判定し、
ビットレートに対するリソースブロック（ＲＢ）のトークンバケットのサイズに基づき、複数のアップリンクチャンネルと前記複数のアップリンクチャンネルに関連付けられた現在のバッファー状態とを判定し、
前記未処理のデータの量の判定および前記複数のアップリンクチャンネルの判定に基づいて、許可要求を含むバッファー状態報告を提供し、
提供した前記バッファー状態報告の送信の応答である、前記未処理のアップリンクのデータの送信に対する許可を受信する
ようにさらに構成されており、
前記複数のアップリンクチャンネルについての前記現在のバッファー状態は、トークンバケットが負の値であること、および前記未処理のアップリンクのデータの送信が許可されることを示す、ことを特徴とするＷＴＲＵ。
【請求項１０】
前記プロセッサは、
前記複数のアップリンクチャンネルの各々について、前記現在のバッファー状態が予め決定された閾値を超過するかを判定し、
前記現在のバッファー状態が前記予め決定された閾値を超過するという条件において、未処理のアップリンクのデータの少なくとも１つのパケットを送信し、
送信された前記未処理のアップリンクのデータの少なくとも１つのパケットのサイズだけ減少された前記現在のバッファー状態に等しく、前記現在のバッファー状態を設定するようにさらに構成されている
ことを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１１】
前記ビットレートは、保証伝送レート（ＧＢＲ）のリソースブロック（ＲＢ）のトークンバケットのサイズ、上限伝送レート（ＭＢＲ）のリソースブロック（ＲＢ）のトークンバケットのサイズ、優先伝送レート（ＰＢＲ）のリソースブロック（ＲＢ）のトークンバケットのサイズ、および集約されたＭＢＲ（ａＭＢＲ）のリソースブロック（ＲＢ）のトークンバケットのサイズ、の内の少なくとも１つを含むことを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１２】
前記プロセッサは、複数のリソースブロック（ＲＢｓ）についてのトークンの集約数を報告するようにさらに構成されていることを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１３】
前記バッファー状態報告はリソースブロック（ＲＢ）についてのトークンの値を含むことを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１４】
前記現在のバッファー状態は、バッファー占有率（ＢＯ）情報を含むことを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１５】
前記プロセッサは、前記未処理のアップリンクのデータの少なくとも１つのパケットを送信するために十分なトークンが蓄積するであろう目標時間を報告するようにさらに構成されていることを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１】
無線送受信ユニット（ＷＴＲＵ）からのアップリンクのデータの送信をスケジューリングするための方法であって、
前記ＷＴＲＵにおけるバッファー中の送信のための未処理のアップリンクのデータの量を判定することと、
ビットレートに対するリソースブロック（ＲＢ）のトークンバケットのサイズに基づき、複数のアップリンクチャンネルと前記複数のアップリンクチャンネルに関連付けられた現在のバッファー状態とを判定することと、
前記未処理のデータの量の判定および前記複数のアップリンクチャンネルの判定に基づいて、バッファー状態報告を提供することと、
提供した前記バッファー状態報告の送信の応答である、前記未処理のアップリンクのデータの送信に対する許可を受信することと
を具備し、前記複数のアップリンクチャンネルについての前記現在のバッファー状態はトークンバケットが負の値であることを示すが、前記未処理のアップリンクのデータの送信が許可される、ことを特徴とする方法。
【請求項２】
前記複数のアップリンクチャンネルに対して：
前記現在のバッファー状態が予め決定された閾値を超過するかを判定することと、
前記現在のバッファー状態が前記予め決定された閾値を超過するという条件において、未処理のアップリンクのデータの少なくとも１つのパケットを送信することと、
送信された前記未処理のアップリンクのデータの少なくとも１つのパケットのサイズだけ減少された前記現在のバッファー状態に等しく、前記現在のバッファー状態を設定することと
をさらに具備することを特徴とする請求項１に記載の方法。
【請求項３】
前記バッファー状態報告は、前のアップリンク許可において割り当てられたアップリンクチャンネル上で送信されることを特徴とする請求項１に記載の方法。
【請求項４】
前記ビットレートは、保証伝送レート（ＧＢＲ）のリソースブロック（ＲＢ）のトークンバケットのサイズ、上限伝送レート（ＭＢＲ）のリソースブロック（ＲＢ）のトークンバケットのサイズ、優先伝送レート（ＰＢＲ）のリソースブロック（ＲＢ）のトークンバケットのサイズ、および集約されたＭＢＲ（ａＭＢＲ）のリソースブロック（ＲＢ）のトークンバケットのサイズ、の内の少なくとも１つを含むことを特徴とする請求項１に記載の方法。
【請求項５】
複数のリソースブロック（ＲＢｓ）についてのトークンの集約数を報告することをさらに具備することを特徴とする請求項１に記載の方法。
【請求項６】
前記バッファー状態報告はリソースブロック（ＲＢ）についてのトークンの値を含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記現在のバッファー状態は、バッファー占有率（ＢＯ）情報を含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記未処理のアップリンクのデータの少なくとも１つのパケットを送信するために十分なトークンが蓄積するであろう目標時間を報告することをさらに具備することを特徴とする請求項１に記載の方法。
【請求項９】
受信部と、
送信部と、
前記受信部および前記送信部と通信するプロセッサと
を備えた無線送受信ユニット（ＷＴＲＵ）であって、前記プロセッサはアップリンクのデータの送信をスケジューリングするように構成されており、
前記プロセッサは、
当該ＷＴＲＵにおけるバッファー中の送信のための未処理のアップリンクのデータの量を判定し、
ビットレートに対するリソースブロック（ＲＢ）のトークンバケットのサイズに基づき、複数のアップリンクチャンネルと前記複数のアップリンクチャンネルに関連付けられた現在のバッファー状態とを判定し、
前記未処理のデータの量の判定および前記複数のアップリンクチャンネルの判定に基づいて、許可要求を含むバッファー状態報告を提供し、
提供した前記バッファー状態報告の送信の応答である、前記未処理のアップリンクのデータの送信に対する許可を受信する
ようにさらに構成されており、
前記複数のアップリンクチャンネルについての前記現在のバッファー状態は、トークンバケットが負の値であること、および前記未処理のアップリンクのデータの送信が許可されることを示す、ことを特徴とするＷＴＲＵ。
【請求項１０】
前記プロセッサは、
前記複数のアップリンクチャンネルの各々について、前記現在のバッファー状態が予め決定された閾値を超過するかを判定し、
前記現在のバッファー状態が前記予め決定された閾値を超過するという条件において、未処理のアップリンクのデータの少なくとも１つのパケットを送信し、
送信された前記未処理のアップリンクのデータの少なくとも１つのパケットのサイズだけ減少された前記現在のバッファー状態に等しく、前記現在のバッファー状態を設定するようにさらに構成されている
ことを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１１】
前記ビットレートは、保証伝送レート（ＧＢＲ）のリソースブロック（ＲＢ）のトークンバケットのサイズ、上限伝送レート（ＭＢＲ）のリソースブロック（ＲＢ）のトークンバケットのサイズ、優先伝送レート（ＰＢＲ）のリソースブロック（ＲＢ）のトークンバケットのサイズ、および集約されたＭＢＲ（ａＭＢＲ）のリソースブロック（ＲＢ）のトークンバケットのサイズ、の内の少なくとも１つを含むことを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１２】
前記プロセッサは、複数のリソースブロック（ＲＢｓ）についてのトークンの集約数を報告するようにさらに構成されていることを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１３】
前記バッファー状態報告はリソースブロック（ＲＢ）についてのトークンの値を含むことを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１４】
前記現在のバッファー状態は、バッファー占有率（ＢＯ）情報を含むことを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１５】
前記プロセッサは、前記未処理のアップリンクのデータの少なくとも１つのパケットを送信するために十分なトークンが蓄積するであろう目標時間を報告するようにさらに構成されていることを特徴とする請求項９に記載のＷＴＲＵ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１２−５１４１（Ｐ２０１２−５１４１Ａ）
【公開日】平成２４年１月５日（２０１２．１．５）
【国際特許分類】
【出願番号】特願２０１１−１７５９１６（Ｐ２０１１−１７５９１６）
【出願日】平成２３年８月１１日（２０１１．８．１１）
【分割の表示】特願２００９−５５３６０７（Ｐ２００９−５５３６０７）の分割
【原出願日】平成２０年３月１２日（２００８．３．１２）
【出願人】（５９６００８６２２）インターデイジタル テクノロジー コーポレーション (871)
【Ｆターム（参考）】
【公開日】平成２４年１月５日（２０１２．１．５）
【国際特許分類】
【出願日】平成２３年８月１１日（２０１１．８．１１）
【分割の表示】特願２００９−５５３６０７（Ｐ２００９−５５３６０７）の分割
【原出願日】平成２０年３月１２日（２００８．３．１２）
【出願人】（５９６００８６２２）インターデイジタル テクノロジー コーポレーション (871)
【Ｆターム（参考）】
[ Back to top ]