JP4944906B2 - マルチキャリア資源管理 - Google Patents

Description

優先権情報
本出願は、２００６年１月１９日に出願された米国特許出願第１１／３３４，４２１号の一部継続出願であり、その内容全体が参照により本明細書に組み込まれる。

符号分割多元接続（ＣＤＭＡ）通信システムは、固定サイズの帯域幅で動作するように設計されている。例えば、１ｘ−ＥＶＤＯ通信システムは、１．２５ＭＨｚの帯域幅で動作する。このように限られた資源であるため、資源管理は、ＣＤＭＡ通信システムで重要な役割を果たす。１ｘ−ＥＶＤＯ通信システムでは、基地トランシーバ局（ＢＴＳ）が、ＢＴＳのサービス・エリア内のアクセス端末（ＡＴ）の通信要求に応える。ＡＴは、無線電話、無線通信機能付きＰＤＡまたはコンピュータなどであってよく、また移動局もしくは移動ユニットと呼ぶこともできる。ＢＴＳからＡＴへの通信は、フォワード・リンクまたはダウンリンク通信と呼ばれ、ＡＴからＢＴＳへの通信は、リバース・リンクまたはアップリンク通信と呼ばれる。

３ＧＰＰ２ Ｃ．Ｓ００２４−Ａ ｖ２．０で策定された１ｘ−ＥＶＤＯ標準の現行バージョンは、「バケット・フィリング（バケツを水で満たす）」という概念に基づきリバース・リンクにおいて資源管理の方法を規定しおり、これは、参照により全体が本明細書に組み込まれている。この標準はよく知られているため、この標準については、本発明に関係していることもあり、詳しくは説明せず、代わりに簡単に説明しておく。さらに、この説明では、簡単のため、リバース・リンク資源管理を取りあげる。

１ｘ−ＥＶＤＯ Ｒｅｖｉｓｉｏｎ Ａシステムのリバース・リンクでは、全部でユーザー１人当たり６チャネルあり、トラヒック・チャネルが１つ、オーバーヘッド・チャネルが５つである。この５つのオーバーヘッド・チャネルは、パイロット・チャネル、データ・レート制御（ＤＲＣ）チャネル、データ・ソース制御（ＤＳＣ）チャネル、確認応答（ＡＣＫ）チャネル、およびリバース・レート通知（ＲＲＩ）チャネルである。パイロット・チャネルは、ＢＴＳとＡＴとの間の無線インターフェイスのチャネル推定に使用され、また電力制御目的に使用される。電力制御は、ＢＴＳで受信されたパイロット・チャネル電力が安定し、その結果チャネル推定が安定することを確実にする。したがって、他のチャネルの送信電力は、パイロット・チャネルに関してチャネル利得により定義される。トラヒック・チャネルでは、送信電力は、トラヒック−パイロット（Ｔ２Ｐ）間電力利得と呼ばれる電力利得により指定される。

１ｘ−ＥＶＤＯ ＲｅｖＡ標準に存在するバケット・フィリング法では、Ｔ２Ｐを資源として取り扱うが、それは貯めて使うことができるからである。典型的には、バケットは、それぞれの無線リンク・フロー、例えばＡＴで実行されているアプリケーションの１つから出るデータ・フローについて定義される。簡単のため、単一無線リンクまたはアプリケーション・フローの場合についてバケット・フィリング法を説明する。しかし、１ｘ−ＥＶＤＯは、マルチリンク・フローに対するＴ２Ｐ資源の管理を規定すると理解される。

バケットに加えられるＴ２Ｐ資源の量は、Ｔ２ＰＩｎｆｌｏｗと名付けられ、また使用されるＴ２Ｐ資源の量は、Ｔ２ＰＯｕｔｆｌｏｗと名付けられる。その結果、バケット内のＴ２Ｐ資源の量は、ＢｕｃｋｅｔＬｅｖｅｌと名付けられ、Ｔ２ＰＩｎｆｌｏｗおよびＴ２ＰＯｕｔｆｌｏｗを変数とする関数となる。

ＡＴは、ＢＴＳからＡＴにより受信されるリバース・アクティビティ・ビット（ＲＡＢ）、およびフォワード・リンク・パイロット信号のパイロット信号強度に基づいてＴ２ＰＩｎｆｌｏｗを決定する。ＢＴＳは、タイム・スロット（短い継続時間）毎にＲＡＢをＡＴに送信し、ＢＴＳにおける負荷状態をＡＴに知らせる。負荷、つまり全受信電力が閾値よりも低い場合、ＲＡＢビットは「０」にセットされる。そうでなければ、負荷が閾値よりも高い場合、ＲＡＢビットは「１」にセットされる。ＲＡＢビットの値は、基地局の現在の負荷状態を示す。ＲＡＢビットは、バイナリ変調され（例えば、値「０」に対しては「−１」、値「１」に対しては「１」に）、ＡＴに送信される。ＡＴは、時間の経過とともに受信されるＲＡＢを使用して、クイックＲＡＢ（ＱＲＡＢ）およびフィルターされたＲＡＢ（ＦＲＡＢ）を決定する。ＱＲＡＢとＦＲＡＢは両方とも、時間の経過に従って受信されるＲＡＢのフィルタリングされたバージョンであるが、ＱＲＡＢは、ＦＲＡＢと比べて時定数が著しく小さい。言い換えると、ＱＲＡＢは、短期負荷指標であり、ＦＲＡＢは、長期負荷指標である。ＡＴは、ＱＲＡＢ、ＦＲＡＢ、および測定されたパイロット強度の関数としてＴ２ＰＩｎｆｌｏｗを決定する。

ＡＴは、Ｔ２Ｐ流入フローとＢｕｃｋｅｔＬｅｖｅｌに基づき、ＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗと名付けられた、送信用の潜在的流出フローを決定する。ＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗは、送信時に使用されうるＴ２Ｐ資源の量を示し、したがって現在の送信に使用可能なＴ２Ｐ資源の量を示す。ＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗは、ＢｕｃｋｅｔＬｅｖｅｌ、ＦＲＡＢ、Ｔ２ＰＩｎｆｌｏｗ、およびＢｕｃｋｅｔＦａｃｔｏｒの関数である。ＢｕｃｋｅｔＦａｃｔｏｒは、Ｔ２ＰＯｕｔｆｌｏｗがＴ２ＰＩｎｆｌｏｗよりも何倍大きいかを示す。ＡＴは、ＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗを使用して、送信用のパケット・サイズを決定し、ＴｘＴ２Ｐと名付けられた、送信で使用される実電力つまりＴ２Ｐは、パケット・サイズと伝送モードの関数として決定される。当業で周知のように、ＡＴは、低遅延（ＬｏＬａｔ）伝送モードまたは大容量（ＨｉＣａｐ）伝送モードで動作することができる。

当業者であれば理解するように、送信されたパケットは、アプリケーションからのデータｄに加えてプロトコルによるヘッダなどを含む。したがって、ＡＴは、送信後に、データｄ（通常は、オクテット単位）とＴｘＴ２Ｐの関数としてＴ２ＰＯｕｔｆｌｏｗを決定する。

当業者であれば理解するように、この説明は、単に、１ｘ−ＥＶＤＯの資源管理方法の概要を述べているにすぎず、上述のさまざまな機能などの正確な内容は、よく知られており、この標準から容易に得られる。それに加えて、簡単のため、この概要では、この方法に含まれていると当業者が理解する最小および最大許容Ｔ２ＰＩｎｆｌｏｗなどのさまざまな制約条件に言及することを除外している。

上述の資源管理方法は、容量を高め、加入ＡＴのサービスの品質（ＱｏＳ）要件を満たすのには有益であるが、上述の単一キャリア・アーキテクチャは、データ通信量を増やすことにより生じるニーズに応えられない。その結果、増大するユーザーおよび高まるデータ・スループットに対応するために、必要な帯域幅がますます増えることになる。１ｘ−ＥＶＤＯの単一キャリア設計のコアにあまり大きな変更を持ち込むことなく、より広い帯域幅が利用可能になったときにシステム容量を拡大するマルチキャリアＣＤＭＡ（ＭＣ−ＣＤＭＡ）システムが提案されている。例えば、５ＭＨｚの帯域幅が利用可能な場合、３キャリア１ｘ−ＥＶＤＯシステムを使用して、単一キャリア１ｘ−ＥＶＤＯシステムの容量を少なくとも３倍に増大することができる。最も単純な形では、それぞれのキャリアは、１ｘ−ＥＶＤＯ標準に従って独立して管理される。

ＭＣ−ＣＤＭＡシステムの運用は、資源管理の分野では、いくつかの課題があるとともに、いくつかの好機をもたらす。例えば、ＭＣ−ＣＤＭＡシステムは、消費される資源を最小限に抑えつつさまざまなアプリケーション向けにＱｏＳ（サービスの品質）を維持しなければならない。第２に、ＭＣ−ＣＤＭＡは、マルチキャリア・ダイバーシティ利得を有効利用できなければならない。第３に、ＭＣ−ＣＤＭＡシステムは、キャリア間の負荷分散を行い、システム内のプーリング効率を有効利用できなければならない。
米国特許出願第１１／３３４，４２１号

本発明は、マルチキャリア通信システムの資源管理方法を実現する。

一実施形態では、マルチキャリア通信システム内の多数のアプリケーションからデータを送信するための伝送資源が管理される。この実施形態では、多数のアプリケーションに利用できる総伝送資源が決定され、決定された総伝送資源の一部が、それぞれのキャリア上の負荷に基づきそれぞれのキャリアに分配される。複数のアプリケーションのうちの少なくとも１つから送られたデータは、少なくとも１つのキャリアに分配された決定された総伝送資源の部分に基づきキャリアの少なくとも１つに割り当てられ、割り当てられたデータは、少なくとも１つのキャリア上で送信される。

一実施形態では、複数のキャリア上の集合的負荷を代表する大域的負荷が決定され、総伝送資源は、決定された大域的負荷に基づき決定される。

他の実施形態では、伝送資源は、トラヒック−パイロット間電力利得である。
他の実施形態では、それぞれのキャリアに対する伝送パケットのパケット・サイズは、キャリアに分配される決定された総伝送資源の部分に基づき決定される。データは、少なくとも１つのキャリアに対する伝送パケットの決定されたパケット・サイズに基づきキャリアに対する伝送パケット内にロードされる。例えば、一実施形態では、アプリケーションから利用できる個別の伝送資源が、決定される。次いで、キャリア上にロードするアプリケーションからのデータの量が、アプリケーションから利用可能な決定された個別伝送資源、決定された総伝送資源、およびキャリアに対するパケットの決定されたパケット・サイズに基づき決定される。

一実施形態では、キャリアに対する伝送パケットは、伝送パケットのサイズに関連付けられている電力で送信される。

他の実施形態では、それぞれのアプリケーションに対する潜在的伝送資源が決定され、それぞれのキャリアに対するキャリア伝送資源は、キャリア上のそれぞれのアプリケーションに対する決定された潜在的伝送資源に基づき決定される。次いで、複数のアプリケーションのうちの少なくとも１つから送られたデータは、少なくとも１つのキャリアに対する決定されたキャリア伝送資源に基づきキャリアの少なくとも１つに割り当てられ、割り当てられたデータは、少なくとも１つのキャリア上で送信される。

この実施形態は、さらに、キャリア上のそれぞれのアプリケーションに対する潜在的伝送資源を決定することと、それぞれのキャリア上のアプリケーションに対する決定された潜在的伝送資源を、それらのキャリア上のそのアプリケーションに対する決定された潜在的伝送資源に基づき選択的に調節することを含むことができる。

他の実施形態では、この方法は、キャリア上のそれぞれのアプリケーションに対する決定された潜在的伝送資源を、伝送に関してサポートされている多数のキャリアに基づきスケーリングすることと、調節オペレーションにおいてキャリア上のそれぞれのアプリケーションに対するスケーリングされ決定された潜在的伝送資源を使用することとを含む。

他の実施形態では、少なくとも１つのキャリアに対する伝送パケットのパケット・サイズは、少なくとも１つのキャリアに対する決定されたキャリア伝送資源に基づき決定され、データは、少なくとも１つのキャリアに対する伝送パケットの決定されたパケット・サイズに基づき少なくとも１つのキャリアに対する伝送パケットにロードされる。

本発明は、以下に示される詳細な説明および付属の図面を読むことでより完全に理解され、類似の要素は類似の参照番号により表され、これらは、例としてのみ示され、本発明を制限するものではない。

本発明の実施形態は、ＭＣ−ＣＤＭＡシステムの資源管理方法を実現する。本発明の記述する実施形態では、３ＧＰＰ２ Ｃ．Ｓ００２４−Ａ ｖ２．０で規定されている１ｘ−ＥＶＤＯシステムにおいて使用されているのと同じ用語が使用される。さらに、これらの用語は同じ定義を有し、そうでないと明確に記述されていない限り３ＧＰＰ２ Ｃ．Ｓ００２４−Ａ ｖ２．０において規定されているのと同様にして決定される。簡潔にするため、本発明の実施形態は、リバース・リンク資源管理について説明される。さらに、簡単のため、本発明の実施形態は、任意の個数の無線リンクまたはアプリケーション・フロー（例えば、ＡＴで実行されている１つまたは複数のアプリケーション）、およびＮが１よりも大きいものとするＮ個のキャリアを使用するＭＣ−ＣＤＭＡシステムの場合について説明される。

図１は、本発明の一実施形態によるＡＴで使用される資源管理方法の流れ図である。図に示されているように、ステップＳ１０で、ＡＴは大域的負荷を計算する。より具体的には、ＡＴは、ＱＲＡＢおよびＦＲＡＢの大域バージョンを決定する。

図２は、本発明の一実施形態によりＱＲＡＢおよびＦＲＡＢの大域バージョンを決定する方法の流れ図を例示している。図に示されているように、ステップＳ１２で、ＡＴはキャリア毎にＲＡＢを受信する。次いで、ステップＳ１４で、ＡＴは、３ＧＰＰ２ Ｃ．Ｓ００２４−Ａ ｖ２．０で規定されているよく知られている方法で時間の経過とともにそのキャリアについて受信されたＲＡＢを使用してそれぞれのキャリアに対しＱＲＡＢおよびＦＲＡＢを決定する。

例えば、受信されたそれぞれのＲＡＢについて、ＡＴは、まず最初に、変調されたＲＡＢビットに対しソフト判定を下すが、これは、−１と１の間の実数である。次いで、このソフト・メトリックは、２つのＩＩＲフィルタ（無限インパルス応答フィルタ）に渡されるが、これらのフィルタは、時定数の短い（例えば、４個のＲＡＢをフィルタリングする）フィルタと時定数の長いフィルタ（例えば、３８４個のＲＡＢをフィルタリングする）である。次いで、フィルタリングの後、短期フィルタからの出力は、ＱＲＡＢと呼ばれる、−１または１のいずれかの２進値に量子化される。量子化は、０以上のフィルタリングされたソフト・メトリック値が１と判定され、０未満のフィルタリングされたソフト・メトリック値が−１と判定されるようにゼロの閾値に基づくことができる。

他方、長期フィルタからの負荷出力は、量子化されず、ＦＲＡＢと表される、−１と１との間の実数のままである。

次に、ステップ１６で、ＡＴは大域的負荷を決定する。特に、ＡＴは、大域的ＱＲＡＢおよび大域的ＦＲＡＢを決定する。これらの値は、ＱＲＡＢ_{ｇＩｏｂａｌ}およびＦＲＡＢ_{ｇｌｏｂａｌ}がＮ個のキャリアに対するＱＲＡＢおよびＦＲＡＢをまとめて表しているという点で大域的と考えられる。ＱＲＡＢ_{ｇｌｏｂａｌ}は、以下の式（１）で表されるようなＮ個のキャリアに対するＱＲＡＢの最小値として決定される。

ただし、ｎ＝１からＮまでである。

ＦＲＡＢ_{ｇｌｏｂａｌ}も、以下の式（２）で表されるようなＮ個のキャリアに対するＦＲＡＢの最小値として決定できる。

ただし、ｎ＝１からＮまでである。

それとは別に、ＦＲＡＢ_{ｇｌｏｂａｌ}は、以下の式（3）で表されるようなＮ個のキャリアに対するＦＲＡＢの平均値として決定できる。

ただし、ｎ＝１からＮまでである。

さらに他の代替え手段として、ＦＲＡＢ_{ｇｌｏｂａｌ}は、ＢＴＳから、負荷情報を伝達する別のフォワード・リンク・チャネル上で直接フィードバックされる。

図１の流れ図を再び参照すると、ＡＴは、ステップＳ２０で、それぞれのアプリケーション（例えば、それぞれの無線リンク・フロー）についてＴ２ＰＩｎｆｌｏｗ、ＢｕｃｋｅｔＬｅｖｅｌ、およびＰｏｔｅｎｔｉａｌＴ２Ｐを決定する。これらの値はそれぞれ、ＦＲＡＢ_{ｇＩｏｂａｌ}およびＱＲＡＢ_{ｇｌｏｂａｌ}がＦＲＡＢおよびＱＲＡＢの代わりに使用されることを除き３ＧＰＰ２ Ｃ．Ｓ００２４−Ａ ｖ２．０で規定されているのと同じ方法で決定される。つまり、背景技術の節で説明されているように、Ｔ２ＰＩｎｆｌｏｗは、フォワード・リンク上の測定されたパイロット強度、Ｔ２ＰＯｕｔｆｌｏｗ、およびＦＲＡＢとＱＲＡＢの関数になっている。

背景技術の節でも説明されているように、アプリケーションに対するＢｕｃｋｅｔＬｅｖｅｌは、Ｔ２ＰＯｕｔｆｌｏｗおよびＴ２ＰＩｎｆｌｏｗの関数である。Ｔ２ＰＯｕｔｆｌｏｗの決定は、以下のステップＳ５０に関して説明される。ＢｕｃｋｅｔＬｅｖｅｌを決定するために、図１の前の繰り返しで決定されたアプリケーションに対するＴ２ＰＯｕｔｆｌｏｗがステップＳ２０で現在の繰り返しの間に使用される。

背景技術の節では、さらに、アプリケーションに対するＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗは、ＢｕｃｋｅｔＬｅｖｅｌ、ＦＲＡＢ、Ｔ２ＰＩｎｆｌｏｗ、およびＢｕｃｋｅｔＦａｃｔｏｒの関数であると言及されていた。したがって、本発明のこの実施形態では、アプリケーションに対するＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗを決定する際に、特定のキャリアに対するＦＲＡＢの代わりに、大域的ＦＲＡＢが使用される。ＢｕｃｋｅｔＦａｃｔｏｒは、Ｔ２ＰＯｕｔｆｌｏｗがＴ２ＰＩｎｆｌｏｗよりも何倍大きいかを示すということに留意されたい。

次に、ステップＳ３０で、ＡＴは、それぞれのキャリアがＴ２Ｐ資源をどれだけ消費すべきかを決定する。Ｔ２Ｐ資源の消費は、それぞれのキャリアに対するパケット・サイズに関して特徴付けられる。したがって、ステップＳ３０で、ＡＴは、それぞれのキャリアが対応できるパケット・サイズ（ＰＳ）を決定する。図３は、本発明の一実施形態によりそれぞれのキャリアに対するパケット・サイズを決定する方法の流れ図である。

図に示されているように、ステップＳ３２で、ＡＴは、伝送モード・ベースでデータを送信するためにアプリケーションから利用可能なＴ２Ｐ資源の総計を決定する。上述のように、１ｘ−ＥＶＤＯは、低遅延（ＬｏＬａｔ）伝送モードまたは大容量（ＨｉＣａｐ）伝送モードを規定している。異なる伝送モードに対するＴ２Ｐ資源は、総計されることはなく、この実施形態では、ＡＴは、フロー毎に１つの伝送モードにのみ従って伝送すると仮定される。この総計は、ステップＳ２０で決定されたキャリアに対するＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗｓの総和であり、ＳｕｍＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗ_ＴＭと名付けられるが、ただし、ＴＭは伝送モードを示す。これは、以下の式（４）で表すことができる。

ただし、

ｆ２（；）＝ＢｕｃｋｅｔＦａｃｔｏｒ_ｉ（１０＊ｌｏｇ１０（Ｔ２ＰＩｎｆｌｏｗ_ｉ），ＦＲＡＢ_{ｇｌｏｂａｌ}）＊Ｔ２ＰＩｎｆｌｏｗ_ｉ。
ＢｕｃｋｅｔＬｅｖｅｌ_ｉは、アプリケーションｉのバケット・レベルである。
Ｔ２ＰＩｎｆｌｏｗ_ｉは、アプリケーションｉのバケットへの流入である。
ＴＭ：伝送モード
ＦＲＡＢ_{ｇｌｏｂａｌ}：すべてのキャリアからのＦＲＡＢの大域的ビュー
ｉは、ｉ番目のアプリケーションである。
ＦＲＡＢの代わりにＦＲＡＢ_{ｇｌｏｂａｌ}を使用することを除き、当業者であれば、以下の最小化関数がアプリケーション（または無線リンク・フロー）ｉに対するＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗを決定するため１ｘＥＶＤＯに用意されているよく知られている関数であると理解するであろう。
ｍｉｎ（ｆｌ_ＴＭ（ＢｕｃｋｅｔＬｅｖｅｌ_ｉ， Ｔ２ＰＩｎｆｌｏｗ_ｉ）， ｆ２（ＢｕｃｋｅｔＦａｃｔｏｒ_ｉ，ＦＲＡＢ_{ｇｌｏｂａｌ}，Ｔ２ＰＩｎｆｌｏｗ_ｉ）） （５）

次に、ステップ３４で、ＡＴは、それぞれのキャリア負荷に基づきキャリア間に総Ｔ２Ｐ資源を分配する。つまり、ＳｕｍＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗ_ＴＭの一部ｐ_ｎは、ステップＳ１４で決定されたｎ番目のキャリアに対するＦＲＡＢである、ＦＲＡＢ_ｎに基づきｎ番目のキャリアに割り当てられる。ｎ番目のキャリアに対する部分ｐ_ｎおよびＰｏｔｅｎｔｉａｌＴ２Ｐｏｕｔｆｌｏｗ_ＴＭを決定する例示的一実施形態は、式（６）および（７）により以下で定められる。

ＰｏｔｏｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗ_ＴＭ＿Ｃａｒｒｉｅｒ_ｎ＝ｐ_ｎ＊ＳｕｍＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗ_ＴＭ （７）

キャリアに割り当てられた潜在的資源ＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗ_ＴＭ＿Ｃａｒｒｉｅｒ_ｎを決定した後、この値を経験的に決定された閾値Ｔｈｒｅｓｈｏｌｄ＿Ｔ２ＰＯｕｔｆｌｏｗと比較する。ＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗ_ＴＭ＿Ｃａｒｒｉｅｒ_ｎが、Ｔｈｒｅｓｈｏｌｄ＿Ｔ２Ｐｏｕｔｆｌｏｗ未満である場合、ｎ番目のキャリアに対する部分ｐ_ｎは、０に設定され、他のキャリアに対するＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗｓは、このｐ_ｎを正規化することにより再計算される。言い換えると、それぞれのｐ_ｎは、ｐ_{ｎ＿ｎｅｗ}の総和が１に等しくなるように

として更新される。

ＡＴは、それぞれのキャリアに対し決定されたＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗｓを使用して、それぞれのキャリアに対する最大の対応可能なパケット・サイズ（ＰＳ）を決定する。つまり、ＡＴは、以下の制約条件を適用して、キャリアに対するパケット・サイズを選択する。

ただし、ＴｘＴ２ＰＴＭＮｏｍｉｎａｌＰＳ_ＴＭは、伝送モードＴＭで送信されるサイズＰＳのパケットに対する伝送Ｔ２Ｐ値である。それぞれのキャリアについて、ＡＴは、標準に従って許容される最大のパケット・サイズから始めて、伝送モードＴＭを指定してこのパケット・サイズに対する伝送Ｔ２Ｐ値を決定する。式（８）に示されているように、この伝送Ｔ２Ｐ値は、ＴｘＴ２ＰＴＭＮｏｍｉｎａｌＰＳと呼ばれ、パケット・サイズを使用してＡＴに格納されているルックアップ・テーブルからアクセスできる。ルックアップ・テーブル値は、標準に従って確定され、確定されない場合には、経験的に決定することができる。制約条件が満たされる場合、このキャリアについてパケット・サイズが決定される。制約条件が満たされない場合、パケット・サイズは、次に大きいパケット・サイズにまで縮小され、再び制約条件がテストされる。このプロセスは、制約条件を満たすパケット・サイズが、そのキャリアについて決定されるまで続けられる。次いで、最大パケット・サイズから始まるこのプロセス全体を、それぞれのキャリアに対するパケット・サイズがそれぞれのキャリアに対するそれぞれのＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗ_ＴＭに基づき決定されるようにそれぞれのキャリアについて繰り返す。

ステップＳ３８では、キャリアの１つまたは複数について確定されたパケット・サイズをＡＴの送信電力に基づき調節することができる。つまり、ＡＴは、これらのキャリアについてＴｘＴ２ＰＴＭＮｏｍｉｎａｌＰＳ値を総和して、それぞれのキャリアについてパケットを送信する際に使用される全送信電力を得る。全送信電力がＡＴの最大送信電力を超える場合、キャリアの少なくとも１つに対して確定されたパケット・サイズ（ＰＳ）が調節される（例えば、縮小される）。本発明の一実施形態では、これらのキャリアは、最小のパケット・サイズから最大のパケット・サイズまでランク付けされる。次いで、最小のパケット・サイズを有するキャリアは、パケット・サイズが縮小されている。次いで、ＴｘＴ２ＰＮｏｍｉｎａｌが、ルックアップ・テーブルから決定され、全送信電力が、再び決定される。全送信電力がまだＡＴの最大送信電力を超えている場合、このプロセスは繰り返される。当業者であれば理解するように、キャリアのパケット・サイズは、０にまで縮小でき、その場合、キャリアは、もはや使用されない。この場合、パケット・サイズの昇順によるキャリアのランク付けは、もはや、未使用キャリアを含まず、プロセスは、全送信電力がＡＴの最大送信電力以下になるまで継続する。

要するに、ステップＳ３０で、ＡＴは、それぞれのキャリアが資源をどれだけ消費すべきかを決定する。これは、すべての適格なアプリケーションから総利用可能資源を計算することにより達成され、次いで、それぞれのキャリアの負荷状態に基づき、それぞれのキャリアにより消費されうる潜在的資源が決定される。この資源分配原理は、負荷分散を実現するために重い負荷がかかっているキャリア比べて軽い負荷がかかっているキャリアにより多くの資源を割り当てるというものである。それに加えて、キャリアの許容可能資源が小さすぎる場合、このキャリア上で伝送は許されず、適宜、資源が他のキャリア上に再分配される。最後に、それぞれのキャリア上の資源予算に基づき、ＡＴの最大送信電力により制約される、それぞれのキャリア上の許容可能伝送パケット・サイズが得られる。

再び図１を参照すると、ステップＳ４０で、ＡＴは、それぞれのアプリケーションからのデータをそれぞれのパケットにロードし、負荷に基づきキャリアに対する実際の伝送Ｔ２Ｐを決定する。図４は、このステップの流れ図をさらに詳しく示すものである。図に示されているように、ステップＳ４２で、それぞれのアプリケーションｉからの情報ビット寄与分ｄ_ｉが決定される。一実施形態では、この情報ビット寄与分は、以下の式（９）に従って決定されうる。

ただし、Ｆ_ＴＭは、伝送モードＴＭを使用して送信するのに適しているアプリケーションの集合であり、ｄ_ｉは、アプリケーションｉからのペイロード寄与分であり、Ｑ_ｉは、アプリケーションｉに対する送信バッファ内のデータの量である。

次に、ステップＳ４４で、キャリアは、最大のパケット・サイズから最小のパケット・サイズまでランク付けされる。ＡＴは、最大のパケット・サイズを有するキャリアから始まるアプリケーションからの情報ビットを、パケット・サイズの降順でキャリアのパケットに詰め込む操作を行い、すべてのキャリアのパケットに詰め込まれるか、またはすべての情報ビットが尽きてしまうまでその操作を行う。一実施形態では、情報ビットは、最大のペイロード寄与分（例えば、ロードされるべき最大量の情報ビット）を有するアプリケーションから最小のペイロード寄与分を有するアプリケーションまでロードされる。さらに、キャリアのパケットがより小さなパケット・サイズに縮小することができ、それでも同じ情報ビット量を伝送できる場合、そのキャリアに対するパケット・サイズは縮小される。このステップでは、それぞれの個別ＱｏＳ要件が満たされるようにアプリケーション間に資源を分配する。

次に、上述のルックアップ・テーブルを使用して、ＡＴは、ステップＳ４６におけるそれぞれのキャリアの最終パケット・サイズに基づきそれぞれのキャリアについて伝送Ｔ２Ｐをアクセスする。この実際の伝送Ｔ２Ｐは、キャリアｎについてＴｘＴ２ＰＰＳ_ｎと名付けられる。次いで、これらのパケットは、それぞれのＴｘＴ２ＰＰＳにおいてそれぞれのキャリア上で送信される。

再び図１を参照すると、図４のステップＳ４６でパケットを送信する際にＴ２Ｐ資源を使用していたが、ステップＳ５０で、ＡＴは、使用された実際のＴ２Ｐ資源に基づきそれぞれのアプリケーションについてＴ２ＰＯｕｔｆｌｏｗを決定する。本発明の一実施形態では、それぞれのアプリケーションｉに対するＴ２ＰＯｕｔｆｌｏｗは、以下の式（１０）に従って決定されうる。

図５は、本発明の他の実施形態によるＡＴで使用される資源管理方法の流れ図である。図に示されているように、ステップＳ１０で、ＡＴは大域的負荷を計算する。より具体的には、ＡＴは、図２に関してすでに説明されているようにＱＲＡＢおよびＦＲＡＢの大域バージョンを決定する。

この実施形態では、資源管理は、２つのレベルに従ってＴ２Ｐ資源を取り扱うことを伴う。上位層または上位レベルでは、資源監察管理を規定し、下位そうまたは下位レベルでは、資源供給管理を規定する。上位層では、キャリア上のアプリケーション毎に１つのバケットを使用するバケット・フィリング法が、図１に関して上で説明されているのと同様に維持される。下位レベルでは、バケットは、アプリケーション毎、キャリア毎に維持される。例えば、第１および第２のキャリア、および第１および第２のアプリケーションを仮定すると、下位レベルは、第１のキャリア上の第１のアプリケーションに対するバケット、第２のキャリア上の第１のアプリケーションに対するバケット、第１のキャリア上の第２のアプリケーションに対するバケット、および第２のキャリア上の第２のアプリケーションに対するバケットを維持する。

次に、これらの上位層および下位層のバケットの管理は、ステップＳ２０〜Ｓ２４、さらにはステップＳ５０およびＳ６０に関して説明される。第１に、上位層バケット管理は、ステップＳ２０およびＳ２２に関して説明される。ステップＳ２０で、ＡＴは、図１のステップＳ２０に関して説明されているようにキャリア上のそれぞれのアプリケーションについてＴ２ＰＩｎｆｌｏｗ、ＢｕｃｋｅｔＬｅｖｅｌ、およびＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗを決定する。つまり、これらの値はそれぞれ、ＦＲＡＢ_{ｇＩｏｂａｌ}およびＱＲＡＢ_{ｇｌｏｂａｌ}がＦＲＡＢおよびＱＲＡＢの代わりに使用されることを除き３ＧＰＰ２ Ｃ．Ｓ００２４−Ａ ｖ２．０で規定されているのと同じ方法で決定される。つまり、背景技術の節で説明されているように、Ｔ２ＰＩｎｆｌｏｗは、フォワード・リンク上の測定されたパイロット強度、Ｔ２ＰＯｕｔｆｌｏｗ、およびＦＲＡＢとＱＲＡＢの関数になっている。

背景技術の節でも説明されているように、アプリケーションに対するＢｕｃｋｅｔＬｅｖｅｌは、Ｔ２ＰＯｕｔｆｌｏｗおよびＴ２ＰＩｎｆｌｏｗの関数である。Ｔ２ＰＯｕｔｆｌｏｗの決定は、以下のステップＳ７０に関して説明される。ＢｕｃｋｅｔＬｅｖｅｌを決定するために、図５の前の繰り返しで決定されたアプリケーションに対するＴ２ＰＯｕｔｆｌｏｗがステップＳ２０で現在の繰り返しの間に使用される。背景技術の節では、さらに、アプリケーションに対するＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗは、ＢｕｃｋｅｔＬｅｖｅｌ、ＦＲＡＢ、Ｔ２ＰＩｎｆｌｏｗ、およびＢｕｃｋｅｔＦａｃｔｏｒの関数であると言及されていた。したがって、本発明のこの実施形態では、キャリア上のアプリケーションに対するＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗを決定する際に、特定のキャリアに対するＦＲＡＢの代わりに、大域的ＦＲＡＢが使用される。ＢｕｃｋｅｔＦａｃｔｏｒは、Ｔ２ＰＯｕｔｆｌｏｗがＴ２ＰＩｎｆｌｏｗよりも何倍大きいかを示すということに留意されたい。

次に、ステップＳ２２で、ＡＴは、ステップＳ２０で決定されたそれぞれのアプリケーションのＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗをスケーリングする。つまり、キャリア上のアプリケーションｉのＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗ_ｉに、例えば、スケーリング・ファクターＴ２ＰＳｃａｌｉｎｇＦａｃｔｏｒを掛けて、Ｓｃａｌｅｄ＿ＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗ_ｉを出力するということである。このスケーリング・ファクターは、以下の式に従って決定される。

ただし、Ｎｕｍ＿Ｃａｒｒｉｅｒｓは、ＡＴが対応しているキャリアの数である。

次に、下位層バケット管理が、ステップＳ２４に関して説明される。ステップＳ２４で、ＡＴは、アプリケーション毎、キャリア毎にＴ２ＰＩｎｆｌｏｗ、ＢｕｃｋｅｔＬｅｖｅｌ、およびＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗを決定する。つまり、これらの値はそれぞれ、特定のキャリア上のアプリケーションに関する情報のみが使用されることを除き３ＧＰＰ２ Ｃ．Ｓ００２４−Ａ ｖ２．０で規定されているのと同じ方法で決定される。例えば、特定のキャリア上のアプリケーションに対するＦＲＡＢおよびＱＲＡＢが使用される。つまり、背景技術の節で説明されているように、Ｔ２ＰＩｎｆｌｏｗは、アプリケーションのデータを伝送するキャリアのその部分についてフォワード・リンク上の測定されたパイロット強度、Ｔ２ＰＯｕｔｆｌｏｗ、およびＦＲＡＢとＱＲＡＢの関数になっている。

当業者であれば理解するように、アプリケーション毎、キャリア毎のＢｕｃｋｅｔＬｅｖｅｌは、アプリケーション毎、キャリア毎のＴ２ＰＯｕｔｆｌｏｗおよびＴ２ＰＩｎｆｌｏｗの関数である。アプリケーション毎、キャリア毎のＴ２ＰＯｕｔｆｌｏｗの決定は、以下のステップＳ６０に関して説明される。ＢｕｃｋｅｔＬｅｖｅｌを決定するために、図５の前の繰り返しで決定されたアプリケーション毎、キャリア毎のＴ２ＰＯｕｔｆｌｏｗがステップＳ２４で現在の繰り返しの間に使用される。

アプリケーション毎、キャリア毎のＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗは、以下の式に従って決定される。

ただし、

は、キャリアＣａｒｒｉｅｒ_ｎ上のアプリケーションｉのバケット・レベルである。

は、キャリアＣａｒｒｉｅｒ_ｎ上のアプリケーションｉのバケットへの流入である。
ＴＭ：伝送モード

：Ｃａｒｒｉｅｒ_ｎのＦＲＡＢ。
ＢｕｃｋｅｔＦａｃｔｏｒ_{ｉ，ｃａｒｒｉｅｒ ｎ}は、設計面の配慮に基づきＢｕｃｋｅｔＦａｃｔｏｒ_ｉに等しく、または異なるように設定することができる。

次に、ステップＳ３０’で、ＡＴは、それぞれのキャリアに対するパケット・サイズを決定する。この方法は、図６に詳しく例示されている。図に示されているように、ステップＳ３１で、ＡＴは、キャリア上のアプリケーションｉに対するスケーリングされた上位レベル・バケットの潜在的出力Ｓｃａｌｅｄ＿ＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗ_ｉを使用して、キャリア上の下位レベルのアプリケーション毎、キャリア毎のバケット潜在的出力ＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗ_{ｉ，ｃａｒｒｉｅｒ ｎ}の総和を制約する。特に、

である場合、

を式

に従って再計算する。そうでない場合、ＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗ_{ＴＭ，ｉ，ｃａｒｒｉｅｒ ｎ}は変わらない。

次に、ステップＳ３３で、ＡＴは、以下の式に従ってそれぞれのキャリア上の潜在的資源を計算する。

ただし、ＳｕｍＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗ_{ＴＭ， Ｃａｒｒｉｅｒ ｎ}は、すべてのアプリケーション間のキャリアｎ上で利用可能な資源である。

ステップＳ３３の後、ＡＴは、図３に関して上で説明されているのと同じようにしてステップＳ３６およびＳ３８を実行し、それぞれのキャリアが対応できるパケット・サイズを決定するが、しかし、ステップＳ３６では、ＳｕｍＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗ_{ＴＭ，Ｃａｒｒｉｅｒ ｎ}が、ＰｏｔｅｎｔｉａｌＴ２ＰＯｕｔｆｌｏｗ_ＴＭ＿Ｃａｒｒｉｅｒ_ｎの代わりに使用される。

再び図５を参照すると、ステップＳ４０で、図４に関して詳述されているように、ＡＴは、それぞれのアプリケーションからのデータをそれぞれのパケットにロードし、負荷に基づきキャリアに対する実際の伝送Ｔ２Ｐを決定する。次いで、ステップＳ６０で、ＡＴは、アプリケーション毎、キャリア毎にＴ２ＰＯｕｔｆｌｏｗ_{ｉ，ｃａｒｒｉｅｒ ｎ}を決定する。例示的な一実施形態では、これは、以下の式に従って行われる。

ただし、ｄｉ＿ｃａｒｒｉｅｒ_ｎは、キャリアｎ上のアプリケーションｉに対するデータであり、ＴｘＴ２ＰＰＳ＿Ｃａｒｒｉｅｒ_ｎは、キャリアｎ上の送信電力である。次に、Ｓ７０で、ＡＴは、以下の式で定められるようにキャリア上のアプリケーションｉに対するＴ２ＰＯｕｔｆｌｏｗ_{ｉ，ｃａｒｒｉｅｒ ｎ}を総計することによりキャリア上のそれぞれのアプリケーションｉに対しＴ２ＰＯｕｔｆｌｏｗ_ｉを決定する。

本発明の実施形態は、個々の性能を犠牲にすることなくシステム性能を高められるようにマルチキャリア資源管理を行うものである。容量を改善することで、費用効果を高めることができる。

本発明がこうして説明されたが、同じことをさまざまな方法で変えられることは明らかであろう。例えば、リバース・リンクについて説明されているが、これらの実施形態の全部または一部がフォワード・リンクにも適用されうることは理解されるであろう。他の実施例として、マルチキャリアＣＤＭＡシステムに関して説明されているが、本発明は、他のタイプのマルチキャリア・システムに適用可能と思われる。このような変更形態は、本発明からの逸脱とみなされず、このような修正形態はすべて、本発明の範囲内に含まれることが意図される。

本発明の一実施形態によるＡＴで使用される資源管理方法の流れ図である。 本発明の一実施形態により大域的負荷を決定する方法の流れ図である。 本発明の一実施形態によりそれぞれのキャリアに対するパケット・サイズを決定する方法の流れ図である。 本発明の一実施形態による図１のステップＳ４０の流れ図である。 本発明の他の実施形態によるＡＴで使用される資源管理方法の流れ図である。 本発明の一実施形態による図５のステップＳ３０’の流れ図である。

Claims (12)

1. マルチキャリア通信システム内の多数のアプリケーションからデータを送信するため伝送資源を管理する方法であって、
   前記多数のアプリケーションで利用できる総伝送資源を決定するステップと、
   前記決定された総伝送資源の複数の部分を前記複数のキャリアに、それぞれのキャリア上の負荷に基づき分配するステップと、
   前記複数のアプリケーションのうちの少なくとも１つからのデータを前記複数のキャリアのうちの少なくとも１つに、前記少なくとも１つのキャリアに分配された前記決定された総伝送資源の前記部分に基づき割り当てるステップと、
   前記割り当てられたデータを前記少なくとも１つのキャリア上で送信するステップとを含む方法。
2. さらに、
   前記複数のキャリア上の集合的負荷を表す大域的負荷を決定するステップを含み、
   総伝送資源を決定する前記ステップでは、前記総伝送資源を前記決定された大域的負荷に基づき決定する請求項１に記載の方法。
3. 前記伝送資源は、トラヒック−パイロット間電力利得である請求項１に記載の方法。
4. 前記分配するステップは、負荷の高いキャリアに比べて負荷の低いキャリアに前記決定された総伝送資源のうちの複数を分配する請求項１に記載の方法。
5. さらに、
   それぞれのキャリアに対する伝送パケットのパケット・サイズを、前記キャリアに分配される前記決定された総伝送資源の前記部分に基づき決定するステップを含み、
   前記割り当てるステップは、前記少なくとも１つのキャリアに対する前記伝送パケット内の前記データを前記少なくとも１つのキャリアに対する前記伝送パケットの前記決定されたパケット・サイズに基づきロードする請求項１に記載の方法。
6. さらに、
   前記少なくとも１つのアプリケーションで利用できる個別伝送資源を決定するステップを含み、
   前記割り当てるステップは、前記複数のキャリア上にロードすべき前記少なくとも１つのアプリケーションからの一定量のデータを、前記少なくとも１つのアプリケーションで利用できる前記決定された個別伝送資源、前記決定された総伝送資源、および前記複数のキャリアに対する前記複数のパケットの前記決定されたパケット・サイズに基づき決定するステップを含む請求項５に記載の方法。
7. さらに、
   前記少なくとも１つのアプリケーションで利用できる個別伝送資源を決定するステップを含み、
   前記割り当てるステップは、前記複数のキャリアに割り当てるべき前記少なくとも１つのアプリケーションからの一定量のデータを前記少なくとも１つのアプリケーションで利用できる前記決定された個別伝送資源および前記決定された総伝送資源に基づき決定するステップを含む請求項１に記載の方法。
8. マルチキャリア通信システム内の多数のアプリケーションからデータを送信するための伝送資源を管理する方法であって、
   それぞれのキャリア上のそれぞれのアプリケーションに対して潜在的伝送資源を決定するステップと、
   それぞれのキャリアに対するキャリア伝送資源を前記キャリア上のそれぞれのアプリケーションに対する前記決定された潜在的伝送資源に基づき決定するステップと、
   前記複数のアプリケーションのうちの少なくとも１つからのデータを前記複数のキャリアのうちの少なくとも１つに、前記少なくとも１つのキャリアに対する前記決定されたキャリア伝送資源に基づき割り当てるステップと、
   前記割り当てられたデータを前記少なくとも１つのキャリア上で送信するステップとを含む方法。
9. さらに、
   前記キャリア上のそれぞれのアプリケーションに対して潜在的伝送資源を決定するステップと、
   それぞれのキャリア上のアプリケーションに対して前記決定された潜在的伝送資源を前記キャリア上の前記アプリケーションに対する前記決定された潜在的伝送資源に基づき選択的に調節するステップとを含む請求項８に記載の方法。
10. さらに、
    前記キャリア上のそれぞれのアプリケーションに対し前記決定された潜在的伝送資源を送信に対応した多数の前記キャリアに基づきスケーリングするステップを含む請求項９に記載の方法。
11. 前記選択的に調節するステップは、それぞれのキャリア上のアプリケーションに対する前記決定された潜在的伝送資源を、それぞれのキャリア上の前記アプリケーションに対する前記決定された潜在的伝送資源の総和が前記キャリア上の前記アプリケーションに対する前記スケーリングされた決定された潜在的伝送資源を超える場合に調節する請求項１０に記載の方法。
12. 前記キャリア上のそれぞれのアプリケーションに対する潜在的伝送資源を決定する前記ステップは、前記キャリア上のそれぞれのアプリケーションに対する潜在的伝送資源を前記キャリア上の負荷を示す少なくとも１つの大域的負荷インジケータに基づき決定し、
    それぞれのキャリア上のそれぞれのアプリケーションに対する潜在的伝送資源を決定する前記ステップは、キャリア上のそれぞれのアプリケーションに対する前記潜在的伝送資源を前記キャリア上の負荷を示すキャリア負荷インジケータに基づき決定する請求項９に記載の方法。

Images