JP2006121754A - 高速ダウンリンク・パケット・データ・サービスのために無線ネットワークコントローラおよびノードｂリソース管理デバイスを連係するための方法および装置 - Google Patents

Abstract

【課題】高速ダウンリンク・パケット・データ・サービスのために無線ネットワークコントローラおよびノードＢリソース管理デバイスを連係するための方法および装置を提供する。
【解決手段】ノードＢ（１４’）とインターフェースする無線ネットワークコントローラ（ＲＮＣ）（１２”）のリソース管理（１８）を可能にするための方法および装置であって、ＲＮＣ（１２”）はリアルタイムおよび非リアルタイムのユーザーにリソースを割り当てるための手段（１８）と、ＲＴリソースに物理チャンネル割り当てを提供するための手段（２０）と、カップリングのための手段（１６）とを有し、ノードＢ（１４’）はＮＲＴリソースに物理チャンネル割り当てを提供するための手段（２６’）と、各ＮＲＴユーザーに現在の割り振りの報告を提供するための手段（２６’）とを有する。
【選択図】図１

Description

本発明は無線通信システムにおける無線リソース管理に関する。より詳細には、本発明は高速ダウンリンク・パケット・アクセス・サービスにおけるリソース管理に必要なデータの通信に関する。

ＴＤＤおよびＦＤＤの第３世代のセルラーシステムにおいて、ほとんどすべてのリソースはノードＢ無線リソースを制御するＣ−ＲＮＣ（Ｃｏｎｔｒｏｌｌｉｎｇ Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）により完全に割り振られ、制御されている。専用チャンネル（ＤＣＨ：Ｄｅｄｉｃａｔｅｄ Ｃｈａｎｎｅｌ）に対して、Ｃ−ＲＮＣはリソースプールから固定量のリソースを割り振り、ＤＣＨにサービスするためにそれを割り当てる。ＤＣＨサービスの一例には、音声サービスがある。データタイプのサービスに対して、Ｃ−ＲＮＣはダウンリンク共有チャンネル（ＤＳＣＨ：Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）を割り振ることができる。ＤＳＣＨサービスの例には、Ｗｅｂダウンロード、ファイル転送プロトコル（ＦＴＰ）サービスまたは電子メールのようなデータサービスがある。複数のユーザーが時間を通じてこのチャンネルを共有し、チャンネルのスケジューリング、たとえばどのユーザーがそのチャンネルへのアクセスを得るかは、Ｃ−ＲＮＣで行われている。

これらのリソースは、セルのリソースについてどの程度をＤＣＨサービスに割り振り、どの程度をＤＳＣＨサービスに割り振るかを決定することができるＣ−ＲＮＣによって管理されている。というのは、各リソースはある瞬間には１つのタイプのサービス（ＤＣＨかＤＳＣＨ）しかサービスすることができないからである。しかし、リソースは、必要に応じて、２つのリソースプールの間で相互に移動することができる。

Ｃ−ＲＮＣにおけるＤＳＣＨのリソース割り振りでは、可変データレートの複数のサービスを取り扱う共有リソースなので、さらなる複雑性が生じる。ユーザーの総和によって要求されるリソースの最大量は、頻繁にこのタイプのサービスに割り振られたプールのリソースの量を超えることがある。これが起こり得るのは、すべてのユーザー、統計的にはデータサービスユーザーをモニターして、無線リソースが効率的に利用されていることだけでなく、ユーザーが利用可能なリソースに関して過度に供給されすぎていないことを判定する必要があるためである。というのは、いずれの条件もユーザーのサービス品質（ＱｏＳ）を悪化させる原因となるであろうためである。

Ｃ−ＲＮＣは、高速ダウンリンク・パケット・アクセス（ＨＳＤＰＡ）サービスの動作について最適な知識を得るために次の一般的な問に答えなくてはならない。第１の問は、「ＱｏＳ要求がそれぞれのユーザーについてどの程度良好に満たされているか？」である。特に、動作上のパラメーターのすべてが共有および専用のサービスの両方に対して最適なレベルに設定されているかどうか判定する必要があるであろう。第２の問は、「全体のリソースが２つのタイプのサービス（専用および共有サービス）によりどの程度良好に利用されているか？」である。それぞれのサービスの現在の使用／需要を前提として、専用および共有サービスの間に最適なリソース分割がなされているか？
さらにもう１つの問は、「セルにある特定のＱｏＳ要求のユーザーを加えることにより、全体的なシステム性能にどの程度のコストが生じるであろうか？」である。これは、ユーザーが本当に必要とするサービスレートが通常時間とともに可変であり、ユーザーに割り振られたリソースが通常過度に供給される共有サービスについて特に問題である。

ほとんどのサービスにおいてＣ−ＲＮＣはこれらの問に直に答えることができる。専用サービスのある特定のユーザーに対して、Ｃ−ＲＮＣは固定量のリソースを割り振る。というのは、そのユーザーにより使用されるリソースの量は時間的にかなりスタティックであるためである。共有サービスでの可変データレートのユーザーに対して、Ｃ−ＲＮＣはユーザー間でリソースがどの程度良好に使われているかを理解するのに十分な情報を有している。

しかしながら、高速ダウンリンク・パケット・アクセス（ＨＳＤＰＡ）サービスは、ＤＳＣＨより高いデータサービス用のデータレートを提供する高速ダウンリンク共有チャンネル（ＨＳ−ＤＳＣＨ）という新しいチャンネルを使用する。ＨＳ−ＤＳＣＨサービスは伝送すべきデータを有するユーザーにより良いサービスを提供するために伝送をよりダイナミックに適応させるノードＢに基づいている。それゆえ、Ｃ−ＲＮＣはもはやある特定の瞬間に伝送されるべきデータ、またはその伝送のために用いられる実際のリソースをスケジューリングしない。Ｃ−ＲＮＣは、基本的にデータリソースプールにおけるある所与の量のパワーおよびリソースをノードＢに割り当て、ノードＢがユーザーのデータを現在の無線条件に基づいて動的にスケジューリングする。

Ｃ−ＲＮＣにおけるデータサービスの機能性におけるこのアーキテクチャー変更により、他のサービスに対して有していた基本的な情報の一部を取り残すことになる。結果的に、先に問われた（１）ＱｏＳがどの程度良好に満たされたか；（２）全体的なリソースの利用；そして（３）システムにユーザーを加えることの影響；のような問に対して完全に答えることができなくなる。

高速の共有サービスのアーキテクチャーでは、データサービスが答える必要があったであろう３つの基本的な問に答える種々の情報をノードＢが有することが重要性を持つ。本発明は、ＨＳＤＰＡに対応可能なノードＢにリソースマネージャーが効率的にリソースを割り振ることができるようにする情報を提供するスケジューラーを提供する。

本発明は図面を考慮することにより理解されるであろう。これらの図面では、同様の要素は同様の数字により指定されている。

高速ダウンリンク・パケット・データ・アクセス（ＨＳＤＰＡ）は、高速ダウンリンク共有チャンネル（ＨＳ−ＤＳＣＨ）を通して、容量を増大し、往復遅延を低減し、ピークデータレートを増大するために提供されている。さらに、密接に結合され、伝送パラメーターの瞬間的な無線条件への迅速な適応に依拠する３つの基本的な技術として下記のものを含む：
(ａ)フェーディングのピークやフェーディングの落ち込みのようなチャンネル条件に応じて変調の変更を使用できるようにする高速リンク適応技術；
(ｂ)喪失データエンティティーの再送を迅速に要求し、メッセージを復号する試みがなされる前に元の伝送と任意の後続の再送からソフト情報を合成するための高速ハイブリッド自動繰り返し要求（ＡＲＱ）の技術；および、
(ｃ)マルチユーザダイバーシティを通じて、好ましい無線条件でユーザーに伝送することができるＨＳ−ＤＳＣＨを共有しているユーザーの高速スケジューリング。

チャンネル条件に合致させるためにパラメーターの伝送の高速適応、および高速リンク適応や高速スケジューリングのような機能を利用するＨＳＤＰＡによって採用された技術は、エアインターフェースの近く、すなわちノードＢに配置され、以前は無線ネットワークコントローラ（ＲＮＣ）において行われていた機能性の一部をノードＢに移動するようにし、新しいノードＢエンティティーであるＭＡＣ−ＨＳＤＰＡを形成する。このようにノードＢの機能を拡張することにより高速データレートをサポートする非常に信頼性の高いチャンネルが提供される。

図１〜３は、適正な無線リソース管理（ＲＲＭ）の機能性に必要な典型的な実装形態および種々のメッセージフローを示している。図１は、ＨＳＤＰＡが創作される以前の関連技術を示す図である。図２は、ＨＳＤＰＡ変更に関わる関連技術を示す図である。図３は、本発明の概念を採用する正しい機能性を示す図である。

図１は、ＲＮＣ１２およびノードＢ１４、そしてリアルタイム（ＲＴ）および非リアルタイム（ＮＲＴ）サービスのＲＲＭの割り振りの適正な機能性に必要ないくつかのハイレベル機能およびメッセージングを示している。ノード（ＲＮＣまたはノードＢ）内で定義された機能およびメッセージングは、実装形態に大いに依存する。ノード内で、ラベル付けされた機能は、専用のプロセッサにより実行することができ、または１つ以上の機能からなるタスク行う組み合わせのタスク内にあることができ、これらの機能を行うタスクは本発明と無関係な他の機能を行うことがある。ＲＮＣ１２とノードＢ１４の間は、標準化されたＩｕｂインターフェース１６があり、これによりメッセージングは、形式上適切な標準内で定義されている。

機能１（Ｆ１）はＲＴおよびＮＲＴリソースマネージャー１８である。この機能はトラフィックバランス機能を行い、リアルタイム（ＲＴ）および非リアルタイムの（ＮＲＴ）機能にリソースのプールを与え、加えて現在の負荷を考慮して、そのセルが特定のタイプ、データレートおよびＱｏＳ属性の新規ユーザーを収容することができるかどうか判定するコールアドミッション制御機能を行う。

機能２（Ｆ２）はリアルタイムスケジューラー２０である。リアルタイムスケジューラー２０は、音声ユーザーのようなリアルタイム加入者にリソースを割り当てる役割を担う。トラフィックのタイプが与えられると、その割り振りは一旦割り当てられると通常スタティックである。

機能３（Ｆ３）は非リアルタイムスケジューラー２２である。非リアルタイムスケジューラーは、非リアルタイムのユーザーに対してデータの各バーストのためのリソースを割り当てる役割を担う。トラフィックのタイプが与えられると、その割り振りは比較的頻繁であり、典型的な非リアルタイムのコールに対してたくさん生じるであろう。

機能４（Ｆ４）は物理層２４である。レイヤ２４は物理的なエアインターフェース機能のすべてを行って、エアインターフェースを介してユーザーのデータを適正に送る。各伝送に用いられるリソースは、リアルタイムまたは非リアルタイムスケジューラーによって割り当てられる。

Ｆ１からＦ３の機能のそれぞれは、いくつかのタイプのメッセージセットを用いてＦ１からＦ３の他の機能のそれぞれと通信する。これらのセットは標準（たとえば、Iｕｂインターフェースを介して伝搬するメッセージセット）により形式上定義することができるか、または内部的に、すなわち実装形態に特有な形で定義することができる。実際、１つ以上の機能を行う単一タスクを用いた実装形態では、その通信は瑣末なことであり得る。しかしながら、この実装形態は、機能間で受け渡される必要がある論理的なメッセージに関係するだけであることに注意されたい。また、たとえ図に記載した通りに正確にソフトウェアで実装されたとしても、これらの機能は、他の機能と交換する必要があるであろう他のメッセージセットを、本発明の範囲外のものを含み、有するであろうことに注意されたい。

メッセージセット１（Ｍ１）１８ａは、ＲＴおよびＮＲＴリソースマネージャーがＲＴコールに現在のリソースのプールを割り当てることができ、リアルタイムスケジューラー（Ｆ２）が必要とする情報を得るために使用されるメッセージのセットである。

メッセージセット２（Ｍ２）２０ａは、ＲＴおよびＮＲＴリソースマネージャーがＲＴユーザーに対する現在の割り振りを知ることができるために使用されるメッセージのセットである。ＲＴの割り振りが通常スタティックであるとすれば、これらのメッセージは、厳しい輻輳が存在しない限り、瑣末である。

メッセージセット３（Ｍ３）１８ｂは、ＲＴおよびＮＲＴリソースマネージャー１８がすべてのＮＲＴ割り振りのために現在のリソースのプールを割り当てることができ、非リアルタイムスケジューラー（Ｆ３）が必要とする情報を得てリソースを割り振りすることができるように使用されるメッセージのセットである。

メッセージセット４（Ｍ４）２２ａは、ＲＴおよびＮＲＴリソースマネージャー１８が、ＮＲＴユーザーに対する現在の割り振り（すなわち、割り振りの結果または測定）を知ることができるように使用されるメッセージのセットである。リソースは、バースト的なトラフィックのために定期的に割り当てられるので、このフィードバックは重要であり、それでＲＴおよびＮＲＴリソースマネージャー１８は、過度の加入による一時的な（または一時的どころではない）輻輳によって引き起こされるいかなる輻輳をも軽減することができる。

メッセージセット５（Ｍ５）２０ｂは、ＲＴサービスのユーザーに対するリソースの割り振りについてレイヤ１（物理層）に伝えるためのメッセージのセットである。

メッセージセット６（Ｍ６）２２ｂは、ＮＲＴサービスのユーザーに対するリソースの割り振りについてレイヤ１（物理層）に伝えるためのメッセージのセットである。

図２において、Ｍ１〜Ｍ４のメッセージセットはＲＮＣの内部にあることに注意されたい。というのは、ＲＴおよびＮＲＴリソースマネージャーならびにＲＴおよびＮＲＴスケジューラーもまたＲＮＣに位置しているためである。メッセージセットＭ５およびＭ６は標準化されたＩｕｂメッセージの一部として送られる。

図２では、ＮＲＴサービスを取り扱うためのＨＳ−ＤＳＣＨチャンネルの付加を示している。新しいＨＳ−ＤＳＣＨについて、非リアルタイムスケジューラー２６はノードＢに移動され、メッセージセット３（１８ａ）が今度は標準化されたＩｕｂインターフェースを介して送信されることに留意し、メッセージセット４が省かれていることに留意されたい。これは、ＲＴおよびＮＲＴリソースマネージャーが非リアルタイムスケジューラーからのフィードバックを持たずにＲＴおよびＮＲＴサービス間のトラフィックをバランスしたり、ＮＲＴサービスに伴うコールアドミッション機能に入力を提供したりすることができるようにすることを意味する。

図３では、本発明を組み込むＨＳ−ＤＳＣＨを示している。標準化されたＩｕｂインターフェース上で定義された新しいメッセージＭ４（２６ａ’）により、ＲＴおよびＮＲＴリソースマネージャーがフィードバックを得て適正なトラフィックバランスおよびコールアドミッション制御を提供することができるようになるであろう。新しいメッセージセットＭ４は、従来技術であるノードＢにおける他の物理層の測定と同じように定義されることになる。従来技術のように、ＣＲＮＣは報告および時間経過に対する所望の平均化をスケジュールして、その要求を満すことができる。上で指摘したようにデータサービスが答える必要のある基本的な問の例として、１つの例は「サービス品質（ＱｏＳ）がどの程度良好に満たされるか？」である。この点に関して、ノードＢは、データを伝送するために受信成功までに何回の試みを行ったかを知り、従って、どの時点においても伝送された実際のレートデータを知っている。この値はユーザーによって実際に伝送されたデータとは異なる値である。というのは、何回か再試行されねばならない伝送は、ユーザーがそのデータを１回しか送っておらず、それゆえそのユーザーのＱｏＳがどのように満たされるかを判定するにあたって１回しかカウントされないとしても、それが伝送されるたびにチャンネルの容量を占有するためである。本発明は、しかしながら、その必要とされる情報を提供する。

さらに、本発明は、セルによって提供される他のサービスにより使われたパワーと比較して、高速データサービスにより使われる総パワーのような、その他のことを把握しており、これは、割り振られたパワーが処理されたデータ量に対してどの程度効率的に使われているかを知るにあたって、追加的な要因である。高速データサービスの品質を判定するにあたって有用でノードＢが行うことができる他の多くの潜在的な測定がある。１つの例は、データが正確に、または不正確に受信されたとき、ノードＢにユーザーにより送られた受信肯定または否定応答の信頼性である。

このタイプのデータが答えることができるその他の問は：
(ａ)２つのタイプのサービスによって全体のリソースがどの程度良好に利用されているか？
(ｂ)各サービスの現在の使用／需要を前提として、専用およびデータサービスの間のリソース分割は最適になされているか？ この質問に対してノードＢは、ユーザーデータがどれほど効率的に伝送されたかを把握している。たとえば、他のノードＢより多くの再送を有するノードＢは、他のノードＢが行うことができるのと同じくらい多くのユーザーデータを扱うことができない。

(ｃ)ある特定のＱｏＳ要求のユーザーをセルに加えることにより、全体のシステム性能をどれぐらい犠牲にするか？ ノードＢは、この質問に答えるために、全体的なリソース利用に関する上記の答えを考慮して、新規ユーザーに利用可能である利用可能なリソースを推定することができる。

それゆえ、ノードＢは、これらの機能を行うために必要なこの情報のすべてを有しているので、そして専用およびすべてのデータサービスの両方についてＣ−ＲＮＣリソース割り振りのすべてをノードＢに移動するアーキテクチャー変更を行うことは効率的でないとすれば、ノードＢがこれらのパラメーターをＣ−ＲＮＣに報告しなければならないということは極めて重要であり、これにより、Ｃ−ＲＮＣにこの情報を、ＤＣＨおよびＤＳＣＨのリソースについてＣ−ＲＮＣが有する他の情報と合体できるようにして、Ｃ−ＲＮＣが最適なリソース割り振りの決定を行うことが可能になる。潜在的な情報のリストは、ノードＢからＣ−ＲＮＣへ受け渡されることが望ましく、セルの全体、またはユーザーの優先クラスによって測定されたものは、データのブロック数または伝送された実際のデータのサイズのような測定において単位時間当たりに成功伝送されたデータの量である。さらにリスト中に含まれるものには：成功伝送の数；１回目の伝送での成功；２回目の伝送での成功；３回目の伝送での成功；不成功伝送の数；１回目の伝送での破棄；２回目の伝送での破棄；３回目の伝送での破棄；総失敗；各変調スキームの使用；ソフトハンドオーバー状況と通常の状況の性能；ＡＣＫ／ＮＡＫ受信品質エラー；およびＨＳＤＰＡ伝送のパワー使用がある。

本発明について詳細に説明したが、本発明はこれに限定されず、添付の特許請求の範囲によって定義される本発明の精神および範囲から逸脱することなく、これらに種々の変更を為しうることを理解されたい。

高速ダウンリンク共有チャンネル（ＨＳ−ＤＳＣＨ）を有していないノードＢとインターフェースされた無線ネットワークコントローラ（ＲＮＣ）を示す図である。 高速ダウンリンク共有チャンネル（ＨＳ−ＤＳＣＨ）を有しているノードＢとインターフェースされた無線ネットワークコントローラ（ＲＮＣ）を示す図である。 ＨＳ−ＤＳＣＨチャンネルを有し、本発明の原理を実装しているノードＢとのＲＮＣインターフェースを示す図である。

Claims (16)

1. ノードＢとインターフェースされ、リアルタイムおよび非リアルタイムユーザーにリソースを割り当てる無線ネットワークコントローラ（ＲＮＣ）のリソース管理を可能にするための方法であって、
   （ａ）前記ＲＮＣは、リアルタイムリソースの割り当てに応答して物理チャンネル割り当てを前記ノードＢに提供すること、
   （ｂ）前記ＲＮＣは、非リアルタイムユーザーのリソースの割り当てを前記ノードＢにカップリングすること、
   （ｃ）前記ノードＢは、前記ＲＮＣにより提供される非リアルタイムユーザーのリソースの割り当てに応答して非リアルタイムリソースの物理チャンネル割り当てを物理層に提供すること、および
   （ｄ）前記ノードＢは、各ＮＲＴユーザーの現在の割り振りの結果の報告を前記ＲＮＣに提供すること
   を特徴とする方法。
2. ステップ（ｄ）は、単位時間当たりに成功伝送されたデータの量を前記ＲＮＣに提供することを含むことを特徴とする請求項１に記載の方法。
3. 前記単位時間当たりに成功伝送されたデータの量は、データのブロックの数および伝送された実際のデータのサイズのうちの１つを提示することを含むことを特徴とする請求項２に記載の方法。
4. ステップ（ｄ）で提供される情報は、成功した１回目の伝送の数を伝送することを含むことを特徴とする請求項２に記載の方法。
5. ステップ（ｄ）で提供される情報は、成功した２回目の伝送の数を伝送することを含むことを特徴とする請求項２に記載の方法。
6. ステップ（ｄ）で提供される情報は、成功した３回目の伝送の数を伝送することを含むことを特徴とする請求項２に記載の方法。
7. ステップ（ｄ）で提供される情報は、不成功の伝送の数を伝送することを含むことを特徴とする請求項２に記載の方法。
8. ステップ（ｄ）で提供される情報は、破棄された１回目の伝送の数を伝送することを含むことを特徴とする請求項２に記載の方法。
9. ステップ（ｄ）で提供される情報は、破棄された２回目の伝送の数を伝送することを含むことを特徴とする請求項２に記載の方法。
10. ステップ（ｄ）で提供される情報は、破棄された３回目の伝送の数を伝送することを含むことを特徴とする請求項２に記載の方法。
11. ステップ（ｄ）で提供される情報は、総失敗の数を伝送することを含むことを特徴とする請求項２に記載の方法。
12. ステップ（ｄ）で提供される情報は、各変調スキームの使用を伝送することを含むことを特徴とする請求項２に記載の方法。
13. ステップ（ｄ）で提供される情報は、通常の状況に対してソフトハンドオーバー状況の性能を伝送することを含むことを特徴とする請求項２に記載の方法。
14. ステップ（ｄ）で提供される情報は、応答／否定応答受信品質エラーの数を伝送することを含むことを特徴とする請求項２に記載の方法。
15. ステップ（ｄ）で提供される情報は、他のすべてのサ−ビスに対する高速ダウンリンク・パケット・アクセス（ＨＳＤＰＡ）伝送のパワー使用の計算のためのパワー使用を伝送することを含むことを特徴とする請求項２に記載の方法。
16. 前記提供するための手段は、
    不成功の伝送の数、
    破棄された１回目の伝送の数、
    破棄された２回目の伝送の数、
    破棄された３回目の伝送の数、
    総失敗の数、
    各変調スキームの使用、
    通常の状況に対するソフトハンドオーバー状況の性能、
    応答／否定応答受信品質エラーの数、および
    高速ダウンリンク・パケット・アクセス（ＨＳＤＰＡ）伝送のためのパワー使用
    のうちの１または複数を伝送することを含むことを特徴とする請求項２に記載の方法。

Images