JP2006211676A - パケット・データ・リソースを管理する方法および装置 - Google Patents

Abstract

【課題】パケット・データを効率的に送信するようにリソースを管理する装置および方法を提供すること。
【解決手段】より具体的には、最高優先順位ユーザについて最大支援可能パケット・サイズを決定することを備える、ベース局において送信リソースを割り付ける方法が提供される。決定は、利用可能な変調タイプ、パケット送信に利用可能なコードの総数、パケット送信に利用可能な利用可能送信電力の総量、およびベース局によって支援されるフレーム持続時間に少なくとも部分的に基づく。
【選択図】図１

Description

本発明は、一般に、電気通信に関し、より具体的には、無線電気通信システムに関する。

このセクションは、記述および主張される本発明の様々な態様に関する可能性がある当技術分野の様々な態様に読者を先導することを意図する。この議論は、本発明の様々な態様をよりよく理解するのを容易にするために、読者に背景情報を提供するのに有用であると考えられる。したがって、これらの記述は、これを考慮して読まれるべきであり、従来の技術の許容として読み取られるべきではないことを理解されたい。

過去数年にわたり、１ｘエボルーション・ボイス−データ・ボイス（「１ｘＥＶ−ＤＶ」）、高速ダウンリンク・パケット・アクセス（「ＨＳＤＰＡ」）、および他の同様のシステムなど、パケット送信を可能にするセルラ電話システムが、セルラ・システムの潜在的な能力を大きく増大させた。しかし、この能力は、依然として限定されており、セルラ・プロバイダは、この能力をほとんどのユーザの中で効率的かつ有益に分割するために、新しくより良好な方式を常に探求している。セルラ・プロバイダが利用可能帯域幅の分割をどのように選択するかについて影響を与える、または影響を及ぼすことがある多くのファクタが存在する。

第１に、セルラ・システムのモバイル装置の中に分配されるように利用可能である限定数のチャネル化（ｃｈａｎｎｅｌｉｚａｔｉｏｎ）／ウォルシュ・コードが存在する。さらに、これらのウォルシュ・コードの多くは、パイロット・チャネルおよびページング・チャネルなど、非パケット・レガシ・チャネルによって使用される。したがってセルラ・システムのオペレータに提示される課題の１つは、低フレーム・エラー率（「ＦＥＲ」）（たとえば、１％ＦＥＲ）を維持しながら、ほとんどのユーザを支援するように残りのウォルシュ・コードの割付けをどのように管理するかである。

第２に、セルラ・システムにおいて利用可能な送信電力量も限定されている。すべてが同様であるとすると、より高い送信電力で送信される信号（たとえば、電話呼）は、より少ないエラーを有する。残念ながら、送信電力は、無制限ではない。送信電力は、ある閾値品質レベルを維持しながら、セルラ・システムのユーザ間において再分割されなければならない。したがって、セルラのオペレータについての他の課題は、品質レベルを維持しながら、利用可能な電力を共有することができるユーザの数を最大にすることである。

第３に、セルラ・プロバイダは、各モバイル装置のサービス品質（「ＱｏＳ」）・パラメータに基づいて、帯域幅およびスループットを割り付けることに関心がある。ＱｏＳは、セルラ・ネットワークに関するアプリケーションまたはサービスのタイプの区別を可能にするプロトコルである。これらのＱｏＳパラメータは、遅延、ジッタ、スループット、およびエラー率を含む。効率を向上させるために、現在のセルラ・システムは、各特定のアプリケーションまたはサービスのＱｏＳパラメータに基づいて、帯域幅およびスループットを割り当てることが可能である。たとえば、ボイス・サービスは、遅延感応性であるが、エラー許容性ではなく、一方、ウエブ・ブラウジングは、遅延許容性であるが、エラー感応性ではない。これは、ユーザが、会話における時折のエラーは許容するが、電話の会話における長いギャップは許容しないことを望むからである。対照的に、消費者は、ウエブ・ページをダウンロードするための遅延は許容するが、ウエブ・ページ上のエラーは許容しないことを望む。特定のＱｏＳパラメータは、セルラ・サービスのオペレータによって決定されることが可能であり、また、提供される特定のサービスに応じて大きく変化する可能性がある。ＱｏＳパラメータに基づいてモバイル装置のそれぞれに対して帯域幅およびスループットを効率的に管理することは、有益である可能性がある。

第４に、無線インターネットなど、データ・ベース・サービスが迅速に成長するに従い、セルラ・プロバイダは、サービス・グレード（「ＧｏＳ」）にも関心がある。ＧｏＳは、異なるクラスのユーザの区別を可能にするプロトコルである。ＧｏＳにより、セルラ・プロバイダは、異なる価格において、ＧｏＳクラスと呼ばれる異なるサービス・パッケージを販売することが可能になる可能性がある。たとえば、より高価なアクセス・パッケージが、より速いダウンロード速度を提供することが可能であり、一方、より安価なアクセス・プランが、より遅いダウンロード速度のみを提供することが可能である。様々な価格／性能パッケージを提供することができるシステムが、セルラ・サービス・プロバイダにとって商業的に有利である可能性がある。

第５に、現在のセルラ・システムは、電力およびコードの割付けにおいて公平性を考慮することが可能である。理想的なシステムでは、各ユーザの各モバイル装置の要件を瞬時に満たすことが可能である。しかし、様々な理由で、これは、現実には可能ではない。したがって、あるユーザは、遅延またはエラーに遭遇する可能性がある。公平性の関心は、これらのエラーまたは遅延が、ＧｏＳクラスに応じてセルラ・システムのユーザのすべての中で公平に配分されることを保証することに向けられる可能性がある。

上記において概述された利用可能なファクタに基づいて、１ｘＥＶ−ＤＶ、ＨＳＤＰＡ、および他のパケット送信ネットワークにわたるパケット送信を管理することができるシステムが、有利である。

開示される実施形態の範囲に相応するいくつかの態様が、以下において記述される。これらの態様は、単に、本発明が取ることが可能であるある形態の簡潔な概略を読者に提供するために呈示され、これらの態様は、本発明の範囲を限定することを意図しないことを理解されたい。実際、本発明は、以下において述べられない可能性がある様々な態様を包含することが可能である。

一実施形態において、最高優先順位のユーザについて最大支援可能パケット・サイズを決定することを備える、ベース局において送信リソースを割り付ける方法が提供される。決定は、利用可能な変調タイプ、パケット送信に利用可能なコードの総数、パケット送信に利用可能な利用可能送信電力の総量、およびベース局によって支援されるフレーム持続時間の組合わせに少なくとも部分的に基づく。

他の実施形態において、複数のユーザのそれぞれについてデッドラインを計算することを備える、セルラ・システムの複数のユーザに優先順位を付ける方法が提供される。デッドラインの計算は、複数のユーザのそれぞれのチャネル率に部分的に基づく。

他の実施形態において、モバイル装置のハイブリッド自動繰返し要求プロセスを識別することを備える、セルラ・システムにおいて送信のハイブリッド自動繰返し要求プロセスを選択する方法が提供される。プロセスを識別することは、１つまたは複数の自由ハイブリッド自動繰返し要求プロセスを識別することと、１つまたは複数の自由ハイブリッド自動繰返し要求プロセスの１つを選択することとを備え、選択することは、最初期時間スタンプを有するハイブリッド自動繰返し要求を選択することを備える。
本発明の利点は、以下の詳細な記述を読み、かつ図面を参照することで、明らかになる。

本発明の１つまたは複数の特定の実施形態が、以下において記述される。これらの実施形態の簡潔な記述を提供するために、実際の実施態様のすべての特徴が明細書において記述されるわけではない。任意のエンジニアリングまたは設計プロジェクトの場合のように、あらゆるそのような実際の実施態様の開発において、実施態様ごとに異なる可能性があるシステムに関する制約、および企業に関する制約の遵守など、開発者の特定の目標を達成するために、多くの実施態様特有の決定が行われるはずであることを理解されたい。さらに、そのような開発努力は、複雑で時間がかかる可能性があるが、それにもかかわらず、本開示の利益を有する当業者にとって、設計、製作、および製造のルーチン作業であることを理解されたい。

以下において議論される技術のいくつかは、１ｘＥＶ−ＤＶネットワークまたはＨＳＤＰＡネットワークなど、パケット送信ネットワークにおけるパケットの管理を改善することが可能である。たとえば、利用可能な電力およびウォルシュ・コードを複数のユーザ間において割り付けることができる技術が、有益である可能性がある。第２に、信号タイミング、ユーザ・チャネル条件、ＱｏＳ、ＧｏＳ、および公平性に基づいて複数のユーザをランク付けする技術も、有利である可能性がある。第３に、特定の送信について使用される最適なＨＡＲＱプロセスを決定する技術も、有益である可能性がある。これらの技術のすべてを使用する実施形態が、以下において詳細に議論される。

ここで図面を参照して、参照符号１０によって示され、かつ指定される例示的な無線通信システムである図１をまず参照する。通常の大都市領域など、あらゆる所与のセルラ市場において、無線通信システム１０、またはセルラ・ネットワークは、少なくとも１つの移動交換センタ（「ＭＳＣ」）１２を含むことが可能である。ＭＳＣ１２は、無線システムにサーブするスイッチであり、適切な宛先にコールを切り替えて、接続を維持する機能を実施する。実際、ＭＳＣ１２の主な目的は、モバイル電話と別の電話と、他のモバイル電話または地上通信線電話との間において、音声またはデータの経路接続を提供することである。通常のＭＳＣ１２は、機能の切替え、コールの処理、チャネルの割当て、データ・インタフェース、追跡、ページング、コール・ハンドオフ、請求、およびユーザ・データ・ベースを制御するいくつかの装置を含む。

ＭＳＣ１２は、ゲートウエイ１６に結合されることが可能であり、ゲートウエイ１６は、地上通信線電話ネットワークとしばしば呼ばれる公衆交換電話ネットワーク１８（「ＰＳＴＮ」）に結合されることが可能である。通常のセルラ・ネットワークは、ＰＳＴＮへの接続を含むが、その理由は、すべてのセルラ電話コールの大部分が、ＰＳＴＮを通過するからである。ゲートウエイ１６は、インターネット・サービスをセルラ加入者に提供するように、インターネットなどのパケット交換データ・ネットワーク２０にも結合されることが可能である。

１つまたは複数の無線ネットワーク制御装置（「ＲＮＣ」）１４が、ＭＳＣ１２に結合されることも可能である。とりわけ、ＲＮＣ１４は、セルラ・ネットワーク１０の長期活動ユーザのプールを決定することが可能である。長期活動ユーザのプールを決定するプロセスは、当業者には周知である。ＲＮＣは、このユーザ・リストを１つまたは複数のベース局２２ａ、ｂに送信することが可能である。以下においてより詳細に記述されるように、セルラ・システム１０の構成に応じて、ベース局２２ａ、ｂは、ベース・トランシーバ局（「ＢＴＳ」）、ノードＢ、または他のタイプのトランシーバ・システムとすることが可能である。

ＲＮＣ１４は、長期活動ユーザのプールの各ユーザにＭＡＣ ＩＤまたは固有識別子（「ＵＩ」）の他の形態を割り当てることも可能である。代替実施形態では、ベース局２２ａ、ｂは、ＭＡＣ ＩＤを割り当てることが可能である。さらに、ＲＮＣ１４は、どのウォルシュ・コードまたはチャネル化コードが共有パケット・データおよび制御チャネルに現在利用可能であるかを決定することが可能であり、この情報をベース局２２ａ、２２ｂのそれぞれに送信することが可能である。具体的には、パケット・データ動作（１ｘＥＶ−ＤＶのＦ−ＰＤＣＣＨ’ｓおよびＦ−ＣＰＣＣＨ’ｓ、ならびにＨＳＤＰＡのＨＳ−ＳＣＣＨ’ｓおよびＤＬ−ＤＰＣＣＨ’ｓ）についてレガシ・チャネル（非パケット・チャネル）および制御チャネルのコードが割り付けられた後、ＲＮＣ１４は、どのコードが、高速パケット・データ・チャネル（１ｘＥＶ−ＤＶのＦ−ＰＤＣＨおよびＨＳＤＰＡのＨＳ−ＤＳＣＨ）に割り付けるために利用可能であるかを決定することが可能である。代替実施形態では、ベース局２２ａ、２２ｂは、これらの機能を実施することが可能である。

ＲＮＣ１４は、ＱｏＳおよびＧｏＳの情報をベース局２２ａ、ｂに提供することも可能である。上記で記述されたように、サービス品質（［ＱｏＳ］）は、インターネット・プロトコル上の音声（「ＶＯＩＰ」）、ファイル・ダウンロード（ＦＴＰ）、およびウエブ・ページ（ＨＴＴＰ）など、アプリケーションとサービスとの区別を可能にするプロトコルである。サービス・グレード（「ＧｏＳ」）は、様々なクラスのユーザを区別することを可能にするプロトコルである。とりわけ、ＲＮＣ１４は、ＱｏＳパラメータおよびＧｏＳクラスをベース局２２ａ、ｂに提供することが可能である。

最近、ＲＮＣ１４は、送信電力測定を提供することが可能であり、この送信電力測定から、ベース局２２ａ、ｂは、パケット・チャネルを送信するのに利用可能な電力を計算することが可能である。一実施形態では、ＲＮＣ１４は、共有パケット・データおよび制御チャネルについて瞬間ベース局送信電力測定を提供するように構成された電力検出モジュールを備えることが可能である。この情報を提供することができる機構は、当技術分野において周知である。ＲＮＣ１４は、所与の時間スロットの最大送信電力からレガシ・チャネルによって必要とされる推定電力を減算することによって、パケット・データおよび制御チャネルに利用可能な推定電力を計算することが可能である。ＲＮＣ１４は、電力推定をベース局２２ａ、ｂに送信することが可能である。

次に、ベース局２２ａ、ｂは、様々なモバイル装置２４ａ、２４ｂ、２４ｃ、２４ｄについてネットワーク・トラフィックのアクセス点として作用する送信および受信局とすることが可能である。通常、ベース局２２ａ、ｂは、１ｘＥＶ−ＤＶシステムにおいてＢＴＳを備え、ＨＳＤＰＡシステムにおいてノードＢを備える。しかし、異なる構成が、代替実施形態において可能である。たとえば、ベース局２２ａ、ｂは、塔の上に取り付けられたアンテナを含むことが可能であり、または、建物の上に取り付けられたアンテナを含むことが可能である。さらに、ベース局２２ａ、ｂは、携帯セルラ電話２４ａラップトップ・コンピュータ２４ｂ、車両システム２４ｃ、またはユーザ機器２４ｄなど、任意の適切なモバイル装置と音声またはデータを通信することが可能である。わずかに２つのベース局２２ａ、ｂが図１では示されているが、当業者なら、任意の適切な数のベース局２２ａ、ｂが、ＲＮＣ１４に結合されることが可能であることを理解するであろう。さらに、ベース局２２ａ、ｂおよびモバイル装置２４ａ、２４ｂ、２４ｃ、および２４ｄは、とりわけ、アンテナを介して空気インタフェース上で信号を送信および受信するトランシーバを含むことを理解されたい。

ここで図２を参照すると、本発明の実施形態による例示的なベース局が示されている。ベース局２２ａ、ｂは、受信器モジュール５２、外部ループ・パケット・データ・リソース・マネジャ・モジュール（「ＯＬＰＤＲＭ」モジュール）５４、内部ループ・パケット・データ・リソース・マネジャ・モジュール（「ＩＬＰＤＲＭ」モジュール）５６、および送信器モジュール５８を備えることが可能である。モジュール（ブロック５２、５４、５６、および５８）は、ハードウエア、ファームウエア、ソフトウエア、またはハードウエア、ファームウエア、およびソフトウエアのある組み合わせとすることが可能である。以下において記述されるように、これらのモジュールは、信号タイミング、ユーザ・チャネル条件、ユーザ・キュー条件、ＱｏＳ、ＧｏＳ、および公平性に基づいて複数のユーザをランク付けするために、または、モバイル装置２４ａ、ｂ、ｃ、およびｄのそれぞれについて最適なハイブリッドＡＲＱプロセスを決定するために、複数のユーザの中で利用可能な電力およびウォルシュ・コードを割り付けるように構成されることが可能である。当業者なら、以下で記述される実施形態が、上記で議論された機能を実施することができるシステムの単なる例であることを理解するであろう。すなわち、ブロック５２、５４、５６、および５８に示されるモジュールは、単なる例示であり、機能が異なるように分割される、またはいくつかのモジュールが含まれない、もしくは他のモジュールが含まれる、他の実施形態を考慮することができる。たとえば、一実施形態では、ＩＬＰＤＲＭモジュール５６およびＯＬＰＤＲＭモジュールの機能は、単一モジュールに組み合わせることが可能である。

複数のユーザ間において電力およびコードを割り付けるために使用されることが可能である１つの例示的な技術が、図３Ａに示されている。この技術は、参照符号１００によって全体的に表される。一実施形態において、技術１００は、ＩＬＰＤＲＭモジュール５６によって実行されることが可能である。代替実施形態では、技術１００は、ベース局２２ａ、ｂの他の箇所において実行されることが可能である。１ｘエボルーション音声−データのみ実施形態など、他の実施形態では、技術１００は、モバイル装置２４ａ、２４ｂ、２４ｃおよび２４ｄの１つの内部において実行されることが可能であり、ベース局２２ａ、ｂに送信されることが可能である。

技術１００は、ブロック１０２において示されるように、瞬間活動ユーザのプールを決定することによって、開始されることが可能である。瞬間活動ユーザのプールは、ベース局２２ａ、ｂにおいてキューにおいて待機する、ユーザに送信される送信のある形態（たとえば、データ）を有するユーザを備えることが可能である。すなわち、瞬間活動ユーザのプールは、ベース局２２ａ、ｂの「ｔｏ−ｄｏ」リストを備える。一実施形態では、ＩＬＰＲＤＭモジュール５６は、各フレーム後、またはさらには多重化の各ラウンド後（ＣＤＭＡシステムでは「ＣＤＭ化」とも呼ばれる）、瞬間活動ユーザのプールを更新することが可能である。本明細書の目的では、モバイル装置２４ａ、ｂ、ｃ、およびｄのそれぞれは、瞬間活動ユーザのプールにあると見なされる。

続行する前に、単一モバイル装置２４ａ、ｂ、ｃ、およびｄが、それぞれが異なるタイプの送信（たとえば、ウエブ・ページおよび音声会話）を備える複数の同時トラフィック・ストリームを有することが可能であることに留意することが重要である。一実施形態では、これらのトラフィック・ストリームのそれぞれは、別々のバッファに記憶されることが可能であり、また、キューイングおよび送信のために、別々のユーザとして扱われる（およびそのように呼ばれる）ことが可能である。

瞬間活動ユーザのプールが決定された後、技術１００は、ブロック１０４において示されるように、トラフィック・ストリームのそれぞれについてＨＡＲＱプロセスを選択することが可能である。上記で記述されたように、ＨＡＲＱプロセスは、セルラ・システム１０がモバイル装置２４ａ、ｂ、ｃ、およびｄへの交換パケットの送信を管理することを可能にする論理キューである。セルラ・システムによって支援されるＨＡＲＱプロセスの数は、代替実施形態では異なることが可能である。たとえば、１つの１ｘＥＶ−ＤＶ実施形態では、モバイル装置２４ａ、ｂ、ｃ、およびｄあたり４つの異なる進行中ＨＡＲＱプロセスが存在することが可能である。１つのＨＳＤＰＡ実施形態では、モバイル装置２４ａ、ｂ、ｃ、およびｄあたり、８つの進行中ＨＡＲＱプロセスが存在することが可能である。

ＨＡＲＱプロセスを選択するためにベース局２２ａによって使用されることが可能である１つの例示的な技術が、図４に示されている。この技術は、参照符号２００によって全体的に表される。技術２００の第１ステップは、ブロック２０２において示されるように、モバイル装置２４ａ、ｂ、ｃ、およびｄの特定の１つについて、ＨＡＲＱプロセスのそれぞれのＨＡＲＱプロセス・タイプを識別するとすることが可能である。一実施形態では、「自由」または「自由」ではないことが可能である未処理のＨＡＲＱプロセス、および空のＨＡＲＱプロセスの２つの異なるタイプのＨＡＲＱプロセスが存在する。

未処理のＨＡＲＱプロセス・タイプは、ある先行時間においてパケットがベース局２２ａ、ｂによってすでに送信されているが、ベース局２２ａが、モバイル装置２４ａ、ｂ、ｃ、およびｄからの確認を依然として待機しているプロセスＩＤである。未処理のＨＡＲＱプロセスは、肯定応答を待機している間、「自由」であるとは見なされず、したがって、追加の情報をモバイル装置２４ａ、ｂ、ｃ、およびｄに送信するために使用されない可能性がある。一実施形態では、ベース局２２ａが肯定応答を受信するために、パケットの送信後、４つのフレームを取ることが可能である。ベース局２２ａ、ｂが肯定応答（あるいは、最大可能送信ラウンド後、または、あるＨＡＲＱタイムアウト値の後、否定応答）を受信した後、自由であると見なされ、未処理のＨＡＲＱプロセスは、追加のパケットを送信するために使用することができる。

一方、空のＨＡＲＱプロセス・タイプは、応答されないデータが存在しないプロセスＩＤである。空のプロセスは、必要であれば、モバイル装置２４ａ、ｂ、ｃ、およびｄのトラフィック・ストリームのいずれかからフレッシュ・パケットでロードすることができる。当業者なら、すべての空のハイブリッドＡＲＱプロセスは、定義によって「自由」と見なされることを理解するであろう。

所与のモバイル装置２４ａ、ｂ、ｃ、およびｄについてＨＡＲＱプロセスを識別した後、技術２００は、ブロック２０４において示されるように、交換パケットが選択される元であるＨＡＲＱプロセスの「最適」を選択することによって続行されることが可能である。自由ＨＡＲＱプロセスのみが、スケジューリングについて考慮することができる。時間ｎにおいて所与のユーザｕについて自由であり、かつ再送信を必要とするすべての未処理のＨＡＲＱプロセスから、「最適」は、各トラフィック・ストリームのある基準に基づいて選択される。一実施形態では、基準は、セルラ・システム１０のオペレータによって選択されることが可能である。セルラ・システムのオペレータによって考慮することができるある例示的な基準が、以下において記述される。

第１に、ＨＡＲＱ選択は、「支援性」試験を通過するためにビットあたり最小増分エネルギーを必要とするＨＡＲＱプロセスを選択することに基づくことが可能である。すなわち、この選択は、ビットあたりほとんどのエネルギーを蓄積させたＨＡＲＱプロセスを選択することを含み、したがって、交換パケットを送信するために、最小量の追加のエネルギーを必要とする。ビットあたりの残りの必要エネルギー（「ＲＲＥＢ」）は、基準変調、コード率、およびブロック・サイズに関して計算されることが可能である。第２に、ＨＡＲＱ選択は、最初期に開始された（すなわち、最初期スタンプを有する）未処理のＨＡＲＱプロセスを選択することに基づくことが可能であり、空のＨＡＲＱプロセスは、現在時間に到着すると考えられる。

第３に、ＨＡＲＱ選択は、到着時間およびＲＲＥＢを均衡させる「デッドライン」を次いで計算することによってＨＡＲＱプロセスを選択することに基づくことが可能である。次いでＨＡＲＱプロセスは、以下のように計算されることが可能であるこのデッドラインＤに従ってランク付けすることができる。
Ｄ＝Ｓ（Ｂ／Ｒ）＋ａ_ｈ
上式で、Ｓは、システム伸張値（ｓｙｓｔｅｍ ｓｔｒｅｔｃｈ ｖａｌｕｅ）であり、すべてのリソースがジョブに割り付けられて、中断なしでサービスされる場合に経験する理想的な性能に関する、ジョブによって経験される真のサービスを反映し、Ｂは、以前に送信されたパケットのパケット・サイズであり、Ｒは、当業者には既知のシャノン・キャパシティであり、ａ_ｈは、第１送信の時間瞬間である。最低デッドラインを有するＨＡＲＱプロセスは、再送信のために選択されることが可能である。

未処理のＨＡＲＱプロセスのいずれも現在自由ではない、または送信される必要がある交換パケットが存在しない場合、自由ＨＡＲＱプロセスのいずれか１つが、新しいパケットを送信するために選択されることが可能である。

モバイル装置の所与の１つの「最適」ＨＡＲＱプロセスが計算された後、技術２００は、ブロック２０６において示されるように、特定のユーザのＨＡＲＱプロセスとしてそのＨＡＲＱプロセスを選択することが可能である。代替実施形態において、ＩＬＰＤＲＭモジュール５６は、図３Ａに示されるように、ＨＡＲＱプロセスを選択することを遅延させ、技術１００において後に最高優先順位ユーザを選択するために、異なるユーザとして各ＨＡＲＱプロセスを扱うことが可能である。

第１モバイル装置２４ａ、ｂ、ｃ、およびｄのＨＡＲＱプロセスが計算された後、技術２００は、ブロック２０８において示されるように、次のユーザに移行して、第２ユーザについて「最適」ＨＡＲＱプロセスを決定することが可能である。技術２００は、「最適」ＨＡＲＱプロセスがモバイル装置２４ａ、ｂ、ｃ、およびｄのそれぞれについて決定されるまで、このようにして続行されることが可能である。

ここで図３ａに戻ると、ＨＡＲＱプロセスが選択された後、技術１００は、ブロック１０６において示されるように、制御チャネル・オーバーヘッドを計算し、利用可能な電力から制御チャネル・オーバーヘッドを減算することによってパケット・データ・チャネルについて利用可能な電力を計算することによって、続行されることが可能である。一実施形態で、ＲＮＣ１４または受信器モジュール５２は、利用可能な電力および制御チャネル・オーバーヘッドの測定を提供することが可能であり、ＩＬＰＤＲＭモジュール５６は、パケット・データ・チャネルの利用可能電力を計算することが可能である。

次に、技術１００は、ブロック１０８において示されるように、各トラフィック・ストリームまたはユーザについてチャネル率を決定することを含むことが可能である。チャネル率は、情報ビット数（パケットにおける）対フレーム持続時間の比である。チャネル率を決定することは、ユーザまたはトラフィック・ストリームについて支援可能なパケット・サイズを決定することを備えることが可能である。初期パケット・サイズが、どのパケット・サイズが支援可能であるかを計算する開始点として作用することが可能である。送信が交換パケットである場合、初期パケット・サイズは、当初のパケットのサイズと整合する。送信が交換パケットではない場合、当初のパケット・サイズは、モバイル装置２４ａ、ｂ、ｃ、もしくはｄまたはセルラ・システム１０によって提供されることが可能である。

初期パケット・サイズが設定された後、ＩＬＰＲＤＭモジュール５６は、初期パケット・サイズに対応するチャネル率が支援可能であるかでどうか、利用可能なウォルシュ・コードおよび利用可能電力から決定されることが可能である。一実施形態では、これは、参照符号２５０によって全体的に表される、図５に示される例示的なＬＵＴなど、ルックアップ表（「ＬＵＴ」）にアクセスすることを備えることが可能である。このＬＵＴ２５０は、セルラ・システム１０によって支援される可能なパケット・サイズのリストを備えることが可能であり、各パケット・サイズは、空気・インタフェースの近似である１％ＦＥＲが与えられる追加の白色ガウス雑音と共にそのパケット・サイズを送信するために使用される必要なウォルシュ・コード数、変調のタイプ、チップ・エネルギーに対応する。

支援可能チャネル率を決定するためにＬＵＴ２５０を使用することが可能であるが、その理由は、チャネル率は、完全に決定されるからである（すなわち、任意の瞬間に入力の同じセットが与えられると、チャネル率の式は、同じ出力を生成する）。したがって、チャネル率は、特定のシステムにおける利用可能コード、利用可能電力、およびフレーム持続時間の可能な組み合わせに基づいて、オフラインで計算することができる。このようにして、特定の数の利用可能コード、特定の量の利用可能電力、および特定のフレーム持続時間に対応するＬＵＴ２５０の線に単にアクセスすることによって、チャネル率を決定することが可能である可能性がある。

当業者なら、ＬＵＴ２５０は、単に例示の目的で呈示されることを理解するであろう。したがって、例示的なＬＵＴ２５０は、各パケット・サイズ内における各可能なパケット・サイズ、またはコード、電力、変調などの各可能な配列を示さない。さらに、ＬＵＴ２５０に示されるコード、電力、および変調の組み合わせでさえ、単なる例示とすることが理解されるであろう。代替実施形態において、値は、異なることが可能である。たとえば、２％ＦＥＲを提供するように構成される実施形態では、チップ・エネルギーは異なることが可能である。

ＬＵＴ２５０を使用することによって、初期パケット・サイズ、コードの利用可能数未満のコード数、および利用可能電力未満のチップ・エネルギーを包含する少なくとも１つの線がＬＵＴ２５０に存在するかを判定することによって、特定数の利用可能コードおよび特定量の利用可能電力が与えられると、パケット・サイズが支援可能であるかを判定することが可能である可能性がある。たとえば、例示的なＬＵＴ２５０を見ると、初期パケット・サイズが３８６４ビットである場合、２０の利用可能コードが存在し、利用可能チップ・エネルギー（すなわち、利用可能電力）は５．５６６ｄＢであり、ＬＵＴ２５０の線２５２は、３８６４ビットのパケット・サイズが２つのスロット（すなわち、２．５ｍｓのフレーム持続時間）および４の変調オーダ（４ビット変調）にわたって支援可能であることを示す。しかし、７つの利用可能コードのみが存在し、利用可能チップ・エネルギーがわずかに１．７ｄＢである場合、３８６４ビットのパケット・サイズは、ＬＵＴ２５０の線がそれらの値に整合しないので支援可能ではない。

初期パケット・サイズが支援可能である場合、ＩＬＰＤＲＭモジュール５６は、支援可能パケット・サイズを送信するために必要な最小数のウォルシュ・コードを計算するループを実行することが可能である。上記の第１例において、これは、５．５６６ｄＢのチップ・エネルギーを有する３８６４ビットのパケット・サイズを支援するために、わずかに１７のコードが必要であると判定することを意味することが可能であるが、その理由は、ＬＵＴ２５０の線２５４は、値には整合するが、線２５２より少ないコードを必要とするからである。

初期パケット・サイズが支援可能ではない場合、ＩＬＰＤＲＭモジュール５６は、支援可能である最大パケット・サイズを計算するループを実行することが可能である。たとえば、わずかに７の利用可能コードが存在し、利用可能チップ・エネルギーはわずかに１．７ｄＢである上記で与えられた第２例では、３０９６ビットのパケット・サイズを使用して、７コードで、４スロットにわたって（すなわち、５ｍｓのフレーム持続時間）、４の変調オーダおよび１．７ｄＢのチップ・エネルギーで送信することが可能である可能性がある。これは、ＬＵＴ２５０の線２５６がこれらの値を支援するので、決定されることが可能である。

最小利用可能パケット・サイズでさえ支援可能ではない場合、ＩＬＰＲＤＭモジュール５６は、支援性の攻撃ファクタ（ａｇｇｒｅｓｓｉｏｎ ｆａｃｔｏｒ）ＡＦ_ｓｕｐｐを計算することが可能である。ＡＦ_ｓｕｐｐは、ＬＵＴ２５０のチップ・エネルギーを低減させる。たとえば、ＬＵＴの支援性のチップ・エネルギーが１ｄＢだけ低減されることが可能である場合、以前に支援可能ではなかったトラフィック・ストリームが、支援可能パケット・サイズを有することが可能である。ＡＦ_ｓｕｐｐに基づいてチップ・エネルギーの閾値を減少させることが人工的である場合（すなわち、チャネル条件に基づいていない）、ＡＦ_ｓｕｐｐにより、最小パケット・サイズが単一フレームにおいて支援可能ではない場合でも、送信についてトラフィック・ストリームを考慮することが可能になる。代替実施形態において、攻撃ファクタは、パケット・サイズを低減する代替として、増大されることも可能である。他の実施形態において、支援可能パケット・サイズは、ＬＵＴ２５０において記憶される代わりに、その場で計算されることが可能である。

ＩＬＰＤＲＭモジュール５６は、様々な可能なフレーム持続時間について最大支援可能パケット・サイズを計算することが可能であることに留意することが重要である。たとえば、１ｘＥＶ−ＤＶの場合、３つの可能なフレーム持続時間１．２５ｍｓ（ＬＵＴ２５０の１つのスロット）、２．５ｍｓ（ＬＵＴ２５０の２つのスロット）、および５ｍｓ（ＬＵＴ２５０の４つのスロット）に対応する３つのパケット・サイズを計算することが可能である。しかし、当業者なら、ＨＳＤＰＡなど、唯一のフレーム持続時間（たとえば、２ｍｓ）のみを支援する実施形態では、ＬＵＴ２５０は、その１つのフレーム持続時間に対応するチャネル率のみを含むことが可能であることを理解するであろう。この実施形態では、ＩＬＰＤＲＭモジュール５６は、単一フレーム持続時間に対応するパケット・サイズのみを決定することが可能である。

トラフィック・ストリームのそれぞれについてチャネル率が決定された後、技術１００は、ブロック１１０において示されるように、対応する各トラフィック・ストリームまたはユーザについて理想的なチャネル率を決定することが可能である。一実施形態では、瞬間ｎにおけるユーザｕの理想的なチャネル率ＣＲ（ｕ、ｎ）は、以下のように数学的に表されることが可能である。

上式で、Ｒ_{ｐｅｒ−ｃｏｄｅ}は、各コードに利用可能なデータ率、ＡＦ_ｃｏｅｆは、攻撃ファクタ係数、Ｗ_{ａｖａｉｌ}は、パケット・データを送信するために利用可能なウォルシュ・コードの総数である。より具体的には、Ｒ_{ｐｅｒ−ｃｏｄｅ}は、以下のように確定されることが可能である。

上式で、ＴＲは、データ送信率、Ｗは、コード割付けの最小数を表す。たとえば、ＬＵＴ２５０の線２５２を見ると、Ｒ_{ｐｅｒ−ｃｏｄｅ}は、ウォルシュ・コードの数Ｗ（ｕ，ｎ，Ｔ_ｆ）によってフレームあたりのデータ率ＴＲ（ｕ，ｎ，Ｔ_ｆ）を除算することによって計算されることが可能である。

ＡＦ_ｃｏｅｆは、以前に記述されたＡＦ_ｓｕｐｐと、送信中のドップラー効果を説明する２乗平均誤差攻撃ファクタＡＦ_ｍｓｅとの組合わせを表す。ＡＦ_ｃｏｅｆは、理想的なチャネル率を計算するとき、あらゆる人工的に課された効果およびあらゆるドップラー効果を排除するために、Ｒ_{ｐｅｒ−ｃｏｄｅ}から分割されることが可能である。最後に、Ｗ_{ａｖａｉｌ}は、ベース局２２ａ、ｂにおいて利用可能なコードの総数である。このコードの総数は、すべてのコードが特定のパケット・サイズを支援するために必要ではない場合でも使用される。たとえば、１７または２０のコードのみがパケット・サイズを支援するために必要な場合でも、Ｗ_{ａｖａｉｌ}は２０であり、１７ではないが、その理由は、全部で２０のコードが利用可能であるからである。

理想的なチャネル率は、理想的な送信率であり、ベース局２２ａ、ｂによって実際に使用される実際の送信率を反映しない可能性があることに留意することが重要である。以下でさらに記述されるように、トラフィック・ストリームが最高優先順位トラフィック・ストリームである場合でも、この理想的なチャネル率は、セルラ・システム１０の全スループットを向上させるために、またはセルラ・システム１０において送信が限定されているために、低下される可能性がある。

各トラフィック・ストリームの理想的なチャネル率が決定された後、技術１００は、図３のブロック１１２において示されるように、各トラフィック・ストリームのデッドラインを計算して、トラフィック・ストリームをランク付けすることが可能である。一実施形態では、デッドラインは、トラフィック・ストリームのＱｏＳパラメータおよびＧｏＳクラスと関連して、各トラフィック・ストリームのチャネル率を使用して計算されることが可能である。具体的には、各トラフィック・ストリームのデッドラインは、（１）トラフィック・ストリームのＱｏＳパラメータおよびＧｏＳクラスを反映する重みが乗算され、かつ、すべてのリソースがジョブに割り付けられ、中断ならびにベース局２２ａ、ｂにおけるジョブの到着時間を有さずにサービスされた場合に経験する理想的な性能に関して、ジョブによって経験される真のサービスの反映であるシステム伸張値が乗算されたジョブ・サイズ対チャネル率の比と、（２）ベース局２２ａ、ｂにおけるジョブの到着時間に特定のタイプのトラフィックに関連する最大遅延を足したものとの小さい方を選択することによって、計算されることが可能である。

この計算は、以下のように数学的に表すことが可能である。

上式で、Ｗ（ｕ，ｓ，ｎ）は、ＱｏＳパラメータおよびＧｏＳクラスに基づいてストリームに添付される重み、Ｓ（ｎ）はシステム伸張（ｓｙｓｔｅｍ ｓｔｒｅｔｃｈ）、Ｊ（ｕ，ｓ，ｎ）はジョブ・サイズ（すなわち、時間スロットｎにおけるユーザｕのストリームｓのビット数またはバイト数)、ＣＲ（ｕ，ｓ，ｎ）は、特定トラフィック・ストリームの理想的なチャネル率、ａ（ｕ，ｓ）はベース局２２ａ、ｂにおけるジョブの到着時間、Δ（ｕ，ｓ）はその特定のタイプのトラフィックについて許可される最大遅延である。ウエブ・ページまたはＦＴＰなど、ベスト・エフォート・トラフィック（すなわち遅延許容）では、Δ（ｕ，ｓ）は、無限に設定されることが可能である。一実施形態では、Ｗ（ｕ，ｓ，ｎ）は、ＯＬＰＤＲＭモジュール５４によって計算されて、ＩＬＰＤＲＭモジュール５６に送信されることが可能である。

デッドラインがトラフィック・ストリームのそれぞれについて計算された後、ＩＬＰＤＲＭモジュール５６は、ブロック１１４において示されるように、デッドラインに基づいてトラフィック・ストリームをランク付けすることが可能である。上記で概述されたトラフィック・ストリームをランク付けする技術は、ランク付け技術の単なる一例であり、また、排他的であることを意図していないことに留意することは重要である。代替実施形態では、ランク付け技術は、異なることが可能である。

最高優先順位ユーザが、計算された送信フォーマットの支援性についてすべてのリソースを必要としない場合、すべてのリソースを最高優先順位ユーザの排他的に割り付けることは、浪費となることがある。したがって、必要なだけの電力およびウォルシュ・コードのみを最高優先順位ユーザに割り付け、残りを追加のユーザに割り付けることが、しばしば賢明である。しかし、このステップを達成するために、追加のユーザ（ならびに適切なリソース割付けおよび送信フォーマット）を識別することが重要である可能性がある。１ｘＥＶ−ＤＶでは、唯一の追加ユーザが追加されることが可能であり、一方、非１ｘＥＶ−ＤＶ実施形態では、限界ははるかにより高いことが可能である、または、ユーザ数は限定されないことが可能であることに留意することが重要である。さらに、１ｘＥＶ−ＤＶ実施形態では、２人のユーザが同時にスケジュールされる場合、同じフレーム持続時間を有することが必要である（上記から、ＨＳＤＰＡとは異なり、１ｘＥＶ−ＤＶにより、複数のフレーム持続時間が可能になることを思い出されたい）。

ここで技術１００に戻ると、トラフィック・ストリームがランク付けされた後、技術１００は、最高優先順位トラフィック・ストリームについて送信フォーマットを決定することを追求することが可能である。図３Ａに示される技術１００の続きである図３Ｂを次に参照すると、ＩＬＰＤＲＭモジュール５６は、ブロック１１６において示されるように、送信フォーマットを決定するために、２つ以上の最適フレーム持続時間が存在するかを判定しなければならない可能性がある。上記から、実施形態に応じて、最高優先順位ユーザについて最大支援可能パケット・サイズを送信することができる２つ以上のフレーム持続時間が存在することが可能であることを思い出されたい。最大支援可能パケット・サイズを支援する２つ以上のフレーム持続時間が存在する場合、これらのフレーム持続時間は、Ｔショートリスト（ｕ１）と呼ばれることがある１セットのショートリスト・フレーム持続時間からとすることが可能である。この場合、送信フォーマットの選択は、次の１人または複数の「最適」ユーザを決定することができるまで、延期されることが可能である。１ｘＥＶ−ＤＶ実施形態の場合、次の最適ユーザのみが考慮されることが可能であるが、他の実施形態では、複数の異なるユーザが考慮されることが可能である。

送信フォーマットのショートリストがアセンブルされた後、技術１００は、ブロック１２０において示されるように、Ｔショートリスト（ｕ１）のフレーム持続時間のそれぞれに基づいて、ｕ１を除くユーザを再優先順序付けすることが可能である。これは、実施されることが可能であるが、その理由は、上記で計算されたデッドラインは、フレーム持続時間に関係なく、理想的なチャネル率を使用して計算されたからである。Ｔショートリストのフレーム持続時間に基づき、かつｕ１にすでに割り付けられている電力およびコードを考慮に入れて、ｕ１を除くユーザを再優先順序付けすることが有用である可能性がある。

一実施形態では、この再優先順序付けは、第１に、最高優先順位ユーザｕ_１を説明するために、利用可能な電力端数を更新することを備える（すなわち、利用可能な電力およびコードから最高優先順位ユーザに必要な電力およびコードを減算する）。次に、Ｔショートリストの各ショートリスト・フレームについて、上記で導出された利用可能な電力およびコードによって支援可能な最大パケット・サイズＢ（ｕ，ｎ，Ｔショートリスト，ＣＤＭ）が計算され、パケット・サイズは、キューのビット数ならびにモバイル装置２４ａ、ｂ、ｃ、およびｄの能力によって可能となるパケット・サイズに従う。数学的には、これは、以下のように表すことができる。

Ｂ（ｕ，ｎ，Ｔショートリスト，ＣＤＭ）＝ｍｉｎ｛Ｂｍａｘ（ｕ，ｎ，Ｔショートリスト，Ｗｐｅｒｍ，ＣＤＭ），Ｂｑ（ｕ，ｎ，ＣＤＭ）｝
ＨＡＲＱ再送信の事象では、当業者なら、実際の送信済みパケット・サイズは、先行送信に使用されたサイズに固定されるが、攻撃ファクタ・パラメータの増大が考慮されることが可能であることを理解するであろう。フレーム持続時間のショートリスト値の対応するデータ率は、数学的には以下のように表すことができる。

＃１ Ｔ_{ショートリスト}
上記のチャネル率の計算プロセスは、Ｔショートリストのフレーム持続時間のそれぞれについて、第１ユーザを除いて、ユーザ・プールのすべてのユーザについて実施されることが可能であり、ユーザ・プールは、新しいチャネル率に関連して上記で記述されたデッドラインおよびランク付けの技術を使用して、再優先順序付けされることが可能である。この再ランク付けが完了した後、再優先順序付けされたリストのそれぞれのユーザは、ランク付けに基づいて、ｕ２、ｕ３、ｕ４などとそれぞれラベル付けされることが可能である。次いで、ＩＬＰＤＲＭモジュール５６は、ブロック１２２において示されるように、ｕ１およびベース局２２ａ、ｂが支援することが可能である可能な限り多くの２次ユーザ（すなわち、ｕ１、ｕ２など）からのスループットを最大にするフレーム持続時間をＴショートリストから選択することが可能である。たとえば、１ｘＥＶ−ＤＶ実施形態の場合、ＩＬＰＤＲＭモジュール５６は、ｕ１およびｕ２からのスループットを最大にするようにフレーム持続時間を選択することが可能であるが、その理由は、１ｘＥＶ−ＤＶは、フレームあたり２人のユーザへのブロードキャストのみを可能にするからである。代替実施形態は異なることが可能である。

ブロック１１６に戻ると、最大パケット・サイズを支援する唯一のフレーム持続時間が存在する場合（たとえば、ＨＳＤＰＡ実施形態）、このフレーム持続時間は、送信フォーマットとして選択されることが可能である。最高優先順位ユーザを除くユーザ・プールは、ブロック１１８によって示されるように、最高優先順位ユーザのフレーム持続時間に基づいて、上記で記述されたように再優先順序付けされることが可能である。行為は、理想的なチャネル率に基づくランク付けが複数フレーム持続時間を含んでいた場合（たとえば、１ｘＥＶ−ＤＶ）、実施されることが可能である。最高優先順位ユーザが、１つの支援可能フレーム持続時間のみを有するとしても、必ずしも、理想的なチャネル率に基づく第２最高優先順位ユーザが同じフレーム持続時間を有することにはならない。この理由により、上記で概述されたように、ｕ１を除く残りのユーザを再優先順序付けすることが有用である可能性がある。当業者なら、再優先順序付けは、ＨＳＤＰＡ実施形態では冗長である（したがって必要ではない）可能性があるが、その理由は、初めから１つの利用可能なフレーム持続時間しか存在しないからであることを理解するであろう。さらに、いくつかの実施形態では、複数のフレーム持続時間が最高優先順位ユーザについて最大パケット・サイズを支援する場合でも、ユーザが再優先順序付けされないことも可能である。

送信フォーマットが選択された後、ＩＬＰＤＲＭモジュール５６は、ブロック１２４において示されるように、電力およびコードを最高優先順位ユーザｕ１に割り付けることが可能である。次いで、ＩＬＰＤＲＭモジュール５６は、ブロック１２６において示されるように、追加のユーザが許可されるかを判定することが可能である。このステップは、技術１００に含まれることが可能であるが、その理由は、ある実施形態は、各フレームにおいて電力およびコードを共有することが可能であるユーザ数に対して人工的な制限を含むことが可能であるからである。たとえば、１ｘＥＶ−ＤＶは、ユーザ数を２に限定する。より多くのユーザが許可される場合、ＩＬＰＤＲＭモジュール５６は、ブロック１３０において示されるように、割り付けられていない電力があるかを判定することが可能である。割り付けられる電力がさらにある場合、ＩＬＰＤＲＭモジュール５６は、ブロック１３２において示されるように、割り付けられていないウォルシュ・コードがさらに存在するか否かを判定することが可能である。追加のコードが存在する場合、ＩＬＰＤＲＭモジュール５６は、ブロック１２８において示されるように、割り付けられていないコードおよび電力を次の最高優先順位ユーザに割り付けることが可能である。割り付けられていない電力およびコードのいくつかまたはすべてを割り付けた後、技術１００は、再びブロック１２６にループすることが可能である。

しかし、割り付けられるコードがさらにはない場合、ブロック１３２後に、ＩＬＰＤＲＭモジュール５６は、ブロック１３６において示されるように、すでにコードが割り付けられているユーザに残りの電力を分配することが可能である。技術１００は、ユーザはさらには許可されないが（ブロック１２６）、依然として割り付けられていない電力が存在する場合（ブロック１３４）、過剰電力を分配することも可能である。この場合ＩＬＰＤＲＭモジュール５６は、電力およびコードがすでに割り付けられているユーザに、まだ割り付けられていないコードを分配することも可能である。

電力およびコードが割り付けられた後、ＩＬＰＤＲＭモジュール５６は、ブロック１３８において示されるように、モバイル装置２４ａ、ｂ、ｃ、およびｄに送信するために、関連する送信フォーマットと共に、ユーザの識別を送信器６０に渡すことが可能である。ほとんどのベース局２２ａ、ｂは、信号を送信する別個の送信率を有することに留意することが重要である。たとえば、電力およびコードの割付けにより、秒あたり４００ｋｂｉｔｓの送信が可能になる可能性がある場合でも、ベース局２２ａ、ｂは、秒あたり３８０ｋｂｉｔｓ、または秒あたり４２０ｋｂｉｔｓにおいてのみ送信するように構成されることが可能である。この場合、通常のベース局２２ａ、ｂは、より低い送信率において送信するように構成されることが可能である。

ウォルシュ・コードおよび電力など、送信リソースをより効率的に割り付けることによって、上記で概述された技術は、１ｘＥＶ−ＤＶネットワークまたはＨＳＤＰＡネットワークなどのパケット送信ネットワークにおいてパケットの管理を改善することが可能である。パケットの管理を改善することにより、パケット送信ネットワークは、より多くのモバイル装置を支援し、改善されたサービスをユーザに提供することが可能になる可能性がある。

本発明は、様々な修正および代替形態を受けることが可能であるが、特定の実施形態が、図面において例として示され、本明細書において詳細に記述された。しかし、本発明は、開示された特定の形態に限定されることを意図しないことを理解されたい。むしろ、本発明は、添付の請求項によって確定される本発明の精神および範囲内にあるすべての修正、均等物、および代替物を網羅するものである。

本発明の１つの例示的な実施形態による、例示的なセルラ・システムを開示する図である。 本発明の１つの例示的な実施形態による、例示的なベース局のブロック図である。 本発明の例示的な実施形態による、複数のユーザ間において電力およびコードを割り付ける例示的な技術を示すフロー・チャートである。 本発明の例示的な実施形態による、複数のユーザ間において電力をおよびコードを割り付ける例示的な技術を示すフロー・チャートである。 本発明の例示的な実施形態による、ＨＡＲＱプロセスを選択する例示的な技術を示すフロー・チャートである。 本発明の例示的な実施形態による、チャネル率を決定するための例示的なルックアップ表を示す図である。

Claims (10)

1. ベース局において送信リソースを割り付ける方法であって、
   最高優先順位ユーザについて最大支援可能パケット・サイズを決定するステップを備え、
   前記決定が、利用可能な変調タイプ、パケット送信に利用可能なコードの総数、パケット送信に利用可能な利用可能送信電力の総量、およびベース局によって支援されるフレーム持続時間の組合わせに少なくとも部分的に基づく、方法。
2. パケット送信に利用可能な送信電力の前記総量を決定するステップと、
   パケット送信に利用可能なコードの前記総数を決定するステップと、
   複数のユーザのそれぞれについてチャネル率を決定することによって、前記複数のユーザから前記最高優先順位ユーザを識別するステップと、
   第２最高優先順位ユーザを識別するステップと、
   前記最高優先順位ユーザの前記最大支援可能パケット・サイズに部分的に基づいて送信フォーマットを決定するステップと、
   送信電力およびコードを前記最高優先順位ユーザに割り付けるステップと、
   送信電力およびコードを前記第２最高優先順位ユーザに割り付けるステップとを備え、
   前記第２最高優先順位ユーザに割り付けられた前記送信電力が、送信電力の前記総量から前記最高優先順位ユーザに割り付けられた前記送信電力を減算したものを超えず、前記第２最高優先順位ユーザに割り付けられたコードの数が、コードの前記総数から前記最高優先順位ユーザに割り付けられた前記コードを減算したものを超えない、請求項１に記載の方法。
3. 前記複数のユーザから最高優先順位ユーザを識別するステップが、前記複数のユーザのそれぞれについてデッドラインを計算するステップを備える、請求項２に記載の方法。
4. 前記複数のユーザのそれぞれについてデッドラインを計算するステップが、前記複数のユーザのそれぞれのサービス・グレードに部分的に基づいてデッドラインを計算するステップを備える、請求項３に記載の方法。
5. 送信フォーマットを決定するステップが、
   前記最大支援可能パケット・サイズを支援する１セットの送信フォーマットを決定するステップと、
   送信フォーマットの前記セットから、前記最高優先順位ユーザおよび前記第２最高優先順位ユーザに送信されたビットの総数を最大にする前記送信フォーマットを選択するステップを備える、請求項２に記載の方法。
6. 前記最高優先順位ユーザと前記第２最高優先順位ユーザとの間において、前記最高優先順位ユーザまたは前記第２最高優先順位ユーザに割り付けられていない電力を分割するステップを備える、請求項２に記載の方法。
7. セルラ・システムの複数のユーザに優先順位を付ける方法であって、
   前記複数のユーザのそれぞれのチャネル率に部分的に基づくデッドラインを前記複数のユーザのそれぞれについて計算するステップを備える、方法。
8. 前記デッドラインを計算するステップが、前記複数のユーザのそれぞれに割り当てられた重み、前記複数のユーザのそれぞれに関連付けられたチャネル率、および前記複数のユーザのそれぞれに関連付けられたジョブの到着時間に少なくとも部分的に基づいてデッドラインを計算するステップを備える、請求項７に記載の方法。
9. 前記デッドラインを計算するステップが、以下の式を計算するステップを備え、
   

   

   上式で、Ｗ（ｕ，ｓ，ｎ）が、前記複数のユーザの前記それぞれに添付された重みを備え、Ｓ（ｎ）が、システム伸張を備え、Ｊ（ｕ，ｓ，ｎ）が、ジョブ・サイズを備え、ＣＲ（ｕ，ｓ，ｎ）が、特定トラフィック・ストリームの理想的なチャネル率を備え、ａ（ｕ，ｓ）が、前記ベース局２２ａ、ｂにおけるジョブの到着時間を備え、およびΔ（ｕ，ｓ）が、特定トラフィック・ストリームに関連付けられた最大遅延を備える、請求項７に記載の方法。
10. セルラ・システムにおいて送信するために、ハイブリッド自動繰返し要求プロセスを選択する方法であって、
    モバイル装置について前記ハイブリッド自動繰返し要求プロセスを識別するステップであって、前記プロセスの識別が、１つまたは複数の自由ハイブリッド自動繰返し要求プロセスを識別することを備えることと、
    前記１つまたは複数の自由ハイブリッド自動繰返し要求プロセスの１つを選択するステップであって、前記選択が、最初期時間スタンプを有するハイブリッド自動繰返し要求を選択することとを備える、方法。
    

Images