本発明は、クライアント協調動作を行う、基地局、移動局、協調移動局、送信方法及び受信方法に関する。
IEEE(Institute of Electrical and Electronics Engineers、電気電子技術者協会)802.16ワーキンググループは、IMT(International Mobile Telecommunications)−アドバンスト次世代携帯電話システムの諸要件を満たす802.16m無線インタフェース仕様を作成中である。IEEE 802.16m草案標準(例えば、非特許文献1参照)に基づいて、WiMAX(Worldwide Interoperability for Microwave Access)フォーラムは、WiMAX リリース2.0 MSP(Mobile System Profile)及びPICS(Protocol Implementation Conformance Statement)を考案中である。IEEE 802.16m標準並びにWiMAXリリース2.0 MSP及びPICSは、2011年早期には仕上げられると見込まれる。
また、IEEE802.16ワーキンググループは、802.16m/WiMAX2.0を超える将来の802.16/WiMAXネットワークの構想設計を開始した。将来の802.16/WiMAXネットワークは、大型画面の機器、マルチメディア・アプリケーション並びにさらに増加する接続ユーザ及び機器によって拍車をかけられる移動通信データ・トラフィックの爆発的な増加をサポートするものになるだろうという共通の認識が、802.16/WiMAXコミュニティの間にはある。また、将来の802.16/WiMAXネットワークは、例えば、802.11/Wi−Fi(Wireless Fidelity)等の他の無線技術と効率的に連携動作するものになるであろう。
将来の802.16/WiMAXネットワークは、スループットやSE(Spectral Efficiency)等の様々な性能指標値に関して、802.16mネットワークと比較して大幅に改良されたものになるであろう。例えば、都市区域におけるカバレッジを想定した場合、将来の802.16/WiMAXネットワークは、UL(Uplink,アップリンク)とDL(Downlink,ダウンリンク)の両方で、802.16m/WiMAX2.0ネットワークの2倍のSEをセルエッジでの目標にしている(例えば、非特許文献2参照)。802.16m/WiMAX2.0ネットワークは、4´2アンテナ構成で少なくとも0.06bps/Hz/秒のDLのセルエッジでのSEと2´4アンテナ構成で少なくとも0.03bps/Hz/秒のULのセルエッジでのSEをもつことに留意されたい。
例えば、CliCo(Client Collaboration、クライアント協調動作)等の協調技術は、無線通信システムのセルエッジでのSE及びネットワーク全体のエネルギー効率の大幅な改良を確かなものにした。CliCoは、無線環境においてクライアント同士がデータを合同で送信/受信するために交信する技術である(例えば、非特許文献3参照)。CliCoでは、BSとクライアント間で複数の経路を介して情報を送信/受信するために、クライアント・クラスタリング(Client Clustering)及びピアツーピア(Peer-to-Peer)通信が利用される。その結果、設備コストの増加なしに、セルエッジでのSEを向上させることができる。さらに、劣悪なチャネルを有するクライアントの電池を長持ちさせることができる。
CliCoを行う典型的な無線通信システム100を例示する図を図1に示す。無線通信システム100は、BS(Base Station,基地局)102と、例えば、MS104及びMS106の複数のMS(Mobile Station,移動局)とを含む構成を採る。
典型的なBS102を例示するブロック図を図2に示す。BS102は、ここではWiMAXによる通信機能のみを装備し、WiMAX PHYブロック130とWiMAX MACブロック120からなる。WiMAX MACブロック120は、WiMAX OFDMA(Orthogonal Frequency Division Multiple Access)ベースの媒体アクセス制御(Media Access Control:MAC)プロトコルを実行する。WiMAX PHYブロック130は、WiMAX MACブロック120の制御の下で、WiMAX OFDMAベースの物理層プロトコルを実行する。
図2を参照すると、WiMAX MACブロック120はさらに、制御部122、スケジューラ124、メッセージ生成部126及びメッセージ処理部128を含む構成を採る。制御部122は、一般的なMACプロトコル動作を制御する。スケジューラ124は、制御部122の制御の下で、各MSへのリソースの割当をスケジュールする。メッセージ生成部126は、スケジューラ124からリソース割当スケジューリング情報を受け取ると、データ・パケット及びDL制御情報を生成する。メッセージ処理部128は、制御部122の制御の下で、複数のMSから受信したデータ・パケット及びUL制御情報を分析し、その分析結果を制御部122へ報告する。
メッセージ生成部126によって生成されたデータ・パケット及びDL制御情報は、WiMAX PHYブロック130内のOFDMA送信器(図2では図示せず)を介してBS102によって複数のMSへ送信されることに留意されたい。メッセージ処理部128によって分析されるデータ・パケット及びUL制御情報は、WiMAX PHYブロック130内のOFDMA受信器(図2では図示せず)を介してBS102によって受信される。
図2を参照すると、メッセージ生成部126内には、HFBCH(HARQフィードバック・チャネル)生成部132とリソース割当生成部134とが存在する。ここで、HARQはハイブリッド自動再送要求(Hybrid Automatic Repeat Request)を表す。HFBCH生成部132は、ULデータ送信に対するHARQフィードバック情報(例えば、ACK/NACK)を通知する、ULデータ送信に対するHARQフィードバック・チャネルを生成する。リソース割当生成部134は、複数のMSの各々へのリソース割当情報を通知する、UL/DLデータ送信のためのリソース割当制御情報を生成する。
GRA(Group Resource Allocation)の観点では、リソース割当生成部134によって生成されるリソース割当制御情報は、グループ・コンフィギュレーション(Group Configuration)情報並びにDL/ULでのGRA送信のためのHFBCHのインデックス情報を含むグループ・リソース割当情報を含み得る。HFBCH生成部132によって生成されるHFBCHは、ULでのGRA送信に対するHARQフィードバック情報を含み得る。
図2を参照するとメッセージ処理部128内には、HFBCH分析部136が存在する。HFBCH分析部136は、DLでのデータ送信に対して受信したHFBCHを分析し、その対応するDLデータ送信が成功したか否かを判断する。GRAの観点では、HFBCH分析部136は、受信したUL制御情報からDLでのGRA送信に対するHARQフィードバック情報を導出し得る。
典型的なMS104を例示するブロック図を図3に示す。MS104は、WiMAX及びWi−Fiの両方による通信機能を装備し、WiMAX PHYブロック142、Wi−Fi PHYブロック144、WiMAX MACブロック146、Wi−Fi MACブロック148、及びGLL(Generic Link Layer)ブロック150から構成される。WiMAX MACブロック146は、WiMAX OFDMAベースのMAC(媒体アクセス制御)プロトコルを実行する。WiMAX PHYブロック142は、WiMAX MACブロック146の制御の下で、WiMAX OFDMAベースの物理層プロトコルを実行する。Wi−Fi MACブロック148は、Wi−Fi CSMA/CA(Carrier Sense Multiple Access with Collision Avoidance)ベースのMAC(媒体アクセス制御)プロトコルを実行する。Wi−Fi PHYブロック144は、Wi−Fi MACブロック148の制御の下で、Wi−Fi OFDM(Orthogonal Frequency Division Multiplexing)/DSSS(Direct Sequence Spread Spectrum)ベースの物理層プロトコルを実行する。GLLブロック150は、異種のWiMAXリンクとW−Fiリンクとの間の連携動作を管理するものとして機能する。
図3を参照すると、WiMAX MACブロック146はさらに、制御部154、メッセージ生成部152、及びメッセージ処理部156を含む構成を採る。制御部154は、一般的なMACプロトコル動作を制御する。メッセージ生成部152は、制御部154の制御の下で、UL制御情報及びデータ・パケットを生成する。メッセージ処理部156は、制御部154の制御の下で、BS102から受信したデータ・パケット及びDL制御情報を分析し、その分析結果を制御部154へ供給する。
メッセージ生成部152によって生成されたデータ・パケット及びUL制御情報は、WiMAX PHYブロック142内のOFDMA送信器(図3では図示せず)を介して、MS104からBS102へ送信されることに留意されたい。メッセージ処理部156によって分析されるデータ・パケット及びDL制御情報は、WiMAX PHYブロック142内のOFDMA受信器(図3では図示せず)を介してMS104によって受信される。
図3を参照すると、メッセージ処理部156内には、リソース分析部151とHFBCH分析部153とが存在する。HFBCH分析部153は、ULでのデータ送信に対して受信したHFBCHを分析し、その対応するULデータ送信が成功したか否かを判断する。リソース分析部151は、受信したリソース割当制御情報を分析し、MS104に対して特定されたリソース割当情報を導出する。ULデータ送信の場合には、制御部154の制御の下でメッセージ生成部152によって生成されたデータ・パケットは、次に、導出されたリソース割当情報に従って、MS104からBS102へ送信される。DLデータ送信の場合には、BS102からMS104へ送信されたデータ・パケットは、次に、導出されたリソース割当情報に従ってMS104によって受信される。
GRAの観点では、メッセージ処理部156内のリソース分析部151は、受信したリソース割当制御情報から、グループ・コンフィギュレーション情報並びにDL/ULでのGRA送信のためのHFBCHのインデックス情報を含むグループ・リソース割当情報を導出し得る。HFBCH分析部153は、受信したHFBCHから、ULでのGRA送信に対するHARQフィードバック情報を導出し得る。
図3を参照すると、メッセージ生成部152内にはHFBCH生成部155が存在する。HFBCH生成部155は、DLでのデータ送信に対するHARQフィードバック情報を含むHARQフィードバック・チャネルを生成する。GRAの観点では、HFBCH生成部155は、DLでのGRA送信に対するHARQフィードバック・チャネルを生成し得る。
典型的なMS106を例示するブロック図を図4に示す。MS106もまた、WiMAX及びWi−Fiの両方による通信機能を装備し、MS104と全く同様の構成と機能性を有する。MS104とMS106との主な相違点は、MS106とは異なり、MS104のWi−Fi MACブロック148内には図3に示したとおり、スケジューラ158があることであり、このスケジューラはCliCoのための協調動作スケジューリングのために使用される。
図1を参照すると、BS102は、 WiMAXリンク108a及び108bを介してMS104と通信し、WiMAXリンク110a及び110bを介してMS106と通信する。MS104は、ピアツーピアWi−Fiリンク112a,112bを介してMS106と通信する。また、MS104は、利用可能であれば、例えば、WiMAX、ブルートゥース、または60 GHz mmW(ミリ波)等の他の無線技術を介してMS106と通信してもよい。
CliCoは、無線通信システム100のDL及びULの両方で実現可能であることに留意されたい。一例として、無線通信システム100におけるULでのCliCoの動作を以下に説明する。
図1を参照すると、BS102とMS104との間のWiMAXリンク108aの信号品質が悪くなると、MS104は、近隣探索、協調機選択/割当等のULでのCliCo手順を開始することができる。BS102とMS106との間のWiMAXリンク110aの信号品質が良ければ、MS104は、MS106を協調機として選択できる。CliCoのコンテクストでは、MS104は発信MSと呼ばれ、MS106は協調MSと呼ばれる。
CliCoは、様々な状況において起こり得る。例えば、発信MS104がカフェテリア内の奥の方にあるとすると、そのため、発信MS104へのWiMAXリンクの信号品質が非常に悪いことがあり得る。一方、協調MS106は、発信MS104に比べて、カフェテリアの窓または入口に非常に近いところにあるとすれば、協調MS106は発信MS104よりも非常に良いWiMAXリンクの信号品質を有し得る。
図1に示したCliCoを行う無線通信システム100に適用され得る、典型的なフレーム構成200を例示する図を図5に示す。図5を参照すると、フレーム202及びフレーム212の各々は、8個のサブフレームからなる。そのうちの5個はDLサブフレームであり、その他はULサブフレームである。
ULでのCliCoに関する限り、フレーム202の最初のDLサブフレーム204中において、BS102は、CliCoに関与する発信MS104と協調MS106とを含む、BS102に接続された複数の移動局へ制御情報を示すMAP 220を送信することができる。MAP220は、複数のMAP IE(Information Element:情報要素)からなる。MAP IEの一部はULデータ送信に対するHARQフィードバック情報を通知することができ、MAP IEの一部はDL/ULデータ送信のためのリソース割当情報を通知することができる。HARQフィードバック情報を通知する、MAP220中の1個のMAP IEが、ULデータ送信に対する1つのHBFCHを形成する。
フレーム202の最初のDLサブフレーム204と最初のULサブフレーム206との間の期間208中に、発信MS104と協調MS106は、HFBCHインデックス情報を含むそれぞれのリソース割当情報を得るために、MAP220をそれぞれ復号する必要がある。また、発信MS104は、ピアツーピアWi−Fiリンク112aを介して、ULデータ・バースト250を協調MS106へ送信する必要がある。
発信MS104がWiMAX リンク108bを介してBS102により送信されたMAP220の復号に成功しているならば、発信MS104は、その受信したリソース割当情報に従って、フレーム202の最初のULサブフレーム206中においてWiMAXリンク108aを介してULデータ・バースト250をBS102へ送信する。他方、協調MS106がWiMAXリンク110bを介してBS102により送信されたMAP220の復号に成功していて、かつ、ピアツーピアWi−Fiリンク112aを介して発信MS104により送信されたULデータ・バースト250の受信に成功しているならば、協調MS106は、その受信したリソース割当情報に従って、WiMAXリンク110aを介して同一のULデータ・バースト250をBS102へ同時に送信する。その結果、BS102は、受信信号の品質を向上させるために、WiMAXリンク108aとWiMAXリンク110aとから受信したULデータ・バースト250の2個のコピーを合成できる。
フレーム212の2番目のDLサブフレーム214中において、BS102は、CliCoに関与する発信MS104及び協調MS106を含む、BS102に接続された複数の移動局へMAP240を送信することができる。上述のとおり、MAP240中の一部を成すHFBCHsは、フレーム202の最初のULサブフレーム206中において発信MS104及び協調MS106が送信したULデータ・バースト250に対するHARQフィードバック情報を通知することができる。
フレーム212の2番目のDLサブフレーム214と最初のULサブフレーム216の間の期間218中に、発信MS104及び協調MS106は、期間208中においてMAP220を復号することによって得られる、それぞれのHFBCHインデックス情報に従って、ULデータ・バースト250に対するHARQフィードバック情報を得るために、MAP240中の対応するHFBCHsをそれぞれ復号する必要がある。
HARQフィードバック情報が、フレーム202の第1のULサブフレーム206中において発信MS104及び協調MS106が送信したULデータ・バースト250をBS102が正常に復号していないことを示す場合、フレーム212の最初のULサブフレーム216中において、発信MS104及び協調MS106は、ULデータ・バースト250を再送する必要があり得る。
上述したとおり、将来の802.16/WiMAXネットワークは、爆発的な移動通信データ・トラフィックをサポートしなくてはならない。さらに、将来の802.16/WiMAXネットワークは、VoIP(Voice over Internet Protocol)等の移動通信インターネット・アプリケーションの実感品質(Quality of Experience)を向上させなくてはならない。VoIPは周期的なトラフィック・パターンをもち、比較的固定したペイロード・サイズであることを考えると、例えば、PA(Persistent Allocation)及びGRAといった、特にVoIPの実感の品質を向上させるために、様々なPHY/MACメカニズムが設計された。本発明では、CliCoへのGRAの適用を取り上げる。
IEEE 802.16m草案標準(例えば非特許文献1参照)で規定されたGRAメカニズムは、CliCoに対応していない。しかし、GRAメカニズムは、CliCoに容易に対応可能である。
IEEE 802.16m草案標準(例えば非特許文献1参照)によれば、GRAメカニズムは、制御オーバヘッドを節減するために、あるグループとしての複数のユーザにリソースを割り当てる。このリソース割当はトランスポート・フロー(Transport flow)単位である。図1を参照すると、GRAをCliCoに適用する方法は、二つの操作からなる。すなわち、i)BS102は、発信MS104及び協調MS106のそれぞれのフローをあるグループに加える、または発信MS104及び協調MS106のそれぞれのフローをあるグループから削除する。ii)BS102は、同一グループ内の発信MS104及び協調MS106のそれぞれのフローにリソースを割り当てる。
IEEE 802.16m草案標準(例えば非特許文献1参照)によれば、発信MS104(または協調MS106)のフローをあるグループに加えるときに、BS102は、ユニキャストMAC制御メッセージ中でグループ・コンフィギュレーション情報を発信MS104(または協調MS106)へ送信する。同一グループ内の発信MS104及び/または協調MS106のそれぞれのフローにリソースを割り当てる場合、BS102は、マルチキャストMAP IEでHFBCHインデックス情報を含むグループ・リソース割当情報を発信MS104及び協調MS106へ送信する。ユニキャストMAC制御メッセージ中で送信されるグループ・コンフィギュレーション情報とマルチキャストMAP IEで送信されるグループ・リソース割当情報は、図2に示したメッセージ生成部126によって生成されることに留意されたい。
IEEE 802.16m草案標準(例えば非特許文献1参照)によれば、ユニキャストMAC制御メッセージ中で送信されるグループ・コンフィギュレーション情報は、対応するマルチキャストMAP IEで送信されるグループ・リソース割当情報を解釈するために使用され得る。グループ・コンフィギュレーション情報の内容は、次のものを含む。
・ フロー識別子(Flow identifier)、
・ ユーザ・ビットマップ・サイズ(User bitmap size)、
・ UBI(User Bitmap Index,ユーザ・ビットマップ・インデックス)、
・ グループ識別子(Group identifier)、
・ 割当て周期(Allocation periodicity)、及び
・ MIMO(Multiple Input Multiple Output)モード・セット(MIMO mode set)、等
フロー識別子は、MSのフローのうちのどのフローがグループに加えられるのかをMSに通知するために使用され、4ビットのサイズを有する。ユーザ・ビットマップ・サイズは、マルチキャストMAP IEで送信されるユーザ・ビットマップに使用されるビット数を示す。ユーザ・ビットマップ・サイズは、4ビット、8ビット、及び32ビットのうちの一つをとる。UBIは、ユーザ・ビットマップ中のMSのフローのインデックスを示し、5ビットのサイズを有する。グループ識別子は、MSのフローが加えられるDL/ULグループを一意に識別し、12ビットのサイズを有する。割当て周期は、対応するグループ・リソース割当情報を通知するマルチキャストMAP IEが送信される頻度を指定し、周期は1フレーム、2フレーム、4フレーム及び8フレームのうちの一つであり得る。MIMOモード・セットは、当グループ中でサポートされているMIMOモードを伝える。
発信MS104と協調MS106に向けたグループ・コンフィギュレーション情報の主な違いは、発信MS104と協調MS106のそれぞれのUBIが異なることである。さらに、グループ・コンフィギュレーション情報は発信MS104と協調MS106へユニキャスト(unicast)されるので、協調MS106は発信MS104のUBIを知らないし、逆の場合もそうである。
IEEE 802.16m草案標準(例えば非特許文献1参照)によれば、グループ・コンフィギュレーション情報は、4個のHARQバースト・サイズ(HARQ burst size)のセットをさらに含み得る。例えば、4個のHARQバースト・サイズのセットは、{6バイト、8バイト、9バイト、10バイト}であり得る。バースト・サイズは、複数のFEC(Forward Error Correction)ブロックに分割可能である、符号化されたパケットのサイズであることに留意されたい。バースト・サイズは、適用できる場合、バースト当たり及び/またはFECブロック当たりのCRC(Cyclic Redundancy Code)の追加を含み得る。
また、4個のHARQバースト・サイズのそれぞれに対応して、グループ・コンフィギュレーション情報は、8個のリソース・サイズを含み得る。例えば、9バイトのHARQバースト・サイズについては、8個のリソース・サイズのセットは、{1LRU、2LRUs、3LRUs、4LRUs、5LRUs、6LRUs、7LRUs、8LRUs}となり得る。ここで、LRUは論理的リソース単位(Logical Resource Unit)を表わす。6バイト、8バイト、10バイトの他の3個のHARQバースト・サイズのそれぞれについては、8個のリソース・サイズのセットは、異なることもあるし、または9バイトのHARQバースト・サイズと同じこともある。
IEEE 802.16m草案標準(例えば非特許文献1参照)によれば、グループ・リソース割当情報の一部は、マルチキャストMAP IEで送信されるビットマップによって運ばれる。IEEE 802.16m草案標準[1]による、一部のグループ・リソース割当情報を通知する典型的なビットマップを例示する図を図6に示す。一部のグループ・リソース割当情報を通知するために使用されるビットマップは二つある。一つはユーザ・ビットマップ302であり、もう一つはリソース割当ビットマップ304である。
IEEE 802.16m草案標準(例えば非特許文献1参照)によれば、ユーザ・ビットマップ302は、現在のフレームにスケジュールされるのはどのフローであるかを伝えるためにフロー当たり1ビットを使用する。図6を参照すると、発信MS104のUBIは「00000」であるのでユーザ・ビットマップ302の1ビット目を参照する。協調MS106のUBIは「00011」であるのでユーザ・ビットマップ302の4ビット目を参照する。したがって、発信MS104及び協調MS106両方のそれぞれのフロー(データに相当)はリソース割当ビットマップ304で指示され、現在のフレームに送信される。
図6を参照すると、リソース割当ビットマップ304は、複数の5ビットのリソース割当指示を含む構成を採り、各リソース割当指示は特定のスケジュールされたフローに対応する。5ビットのリソース割当指示の各々において、最初の2ビットはHARQバースト・サイズを伝えるために使用され、最後の3ビットはリソース・サイズを伝えるために使用される。
図6を参照すると、HARQバースト・サイズは4個のバースト・サイズの種類{6バイト、8バイト、9バイト、10バイト}から選択され、「00」, 「01」、「10」、「11」によって指示される。図6では発信MS104及び協調MS106両方とも「10」で示されるため、両方のHARQバースト・サイズは9バイトである。発信MS104及び協調MS106のリソース・サイズは、それぞれ、「111」と「001」によって示される。したがって、発信MS104及び協調MS106のリソース・サイズは、それぞれ、8LRUsと2LRUsであり得る。
IEEE 802.16m草案標準(例えば非特許文献1参照)によれば、ユーザ・ビットマップ302及びリソース割当ビットマップ304に加えて、複数のMIMOモードがグループ中でサポートされる場合、MIMOビットマップと呼ばれる他のビットマップが使用され得る。
IEEE 802.16m草案標準(例えば非特許文献1参照)による、グループ・リソース割当情報を送信するための典型的なGRA MAP IEを例示する表を表1に示す。
さらに、IEEE 802.16m草案標準(例えば非特許文献1参照)によれば、グループ内のスケジュールされたフローについてのHFBCHインデックスは、そのUBI及び表1に示したHFAオフセットの予め決められた関数である。換言すると、発信MS104及び協調MS106のそれぞれが、表1に示したGRA MAP IEを復号後、自機のUBIにより自機のHFBCHインデックスを算出することができる。
IEEE 802.16m草案標準(例えば非特許文献1参照)において、発信MS104(または協調MS106)がリソース割当情報を受信する方法400を例示するフローチャートを図7に示す。方法400はステップ402で開始する。ステップ404において、発信MS104(または協調MS106)は、自機のUBIに照らしてユーザ・ビットマップをチェックする。ステップ406では、発信MS104(または協調MS106)は、自機のフローが現在のフレームでスケジュールされているか否かを判定する。発信MS104(または協調MS106)のフローが現在のフレームにスケジュールされていれば、ステップ408において、発信MS104(または協調MS106)は、次に、自機のHARQバースト・サイズとリソース・サイズを導出するために、自機のUBIに照らしてリソース割当てビットマップをチェックする。その後、ステップ410で、発信MS104(または協調MS106)は、自機のUBIに応じて自機のHFBCHインデックスを算出する。ステップ406で、発信MS104(または協調MS106)のフローが現在のフレームにスケジュールされていなければ、方法400はステップ412で終了する。
IEEE P802.16m/D5, DRAFT Amendment to IEEE Standard for local and metropolitan area networks - Part 16: Air Interface for Broadband Wireless Access Systems - Advanced Air Interface
IEEE C802.16-10/0016r1, Future 802.16 Networks: Challenges and Possibilities
IEEE C802.16-10/0005r1, Client Cooperation in Future Wireless Broadband Networks
IEEE 802.16m草案標準(例えば非特許文献1参照)によれば、CliCoに関与する発信MS104及び協調MS106の両方が同一のデータ・バーストを処理する。発信MS104及び協調MS106の両方に用いる一つのHFBCHがあれば十分である。しかしながら、同一グループにおいてUBIが異なるため、発信MS104及び協調MS106は2つの異なるHFBCHを有する。これは、貴重なHFBCHリソースを浪費することになる。
本発明の目的は、同一データ・バーストを処理する複数のMSに対して一つのHBCHを使用することで、不必要なHFBCHリソースの浪費を避けることができる基地局、移動局、協調移動局、送信方法及び受信方法を提供することである。
本発明の一態様によれば、複数の移動局(MSs)と通信する基地局(BS)は、上記複数のMSsの各々に対するリソース割当情報を示す制御信号を生成する制御信号生成部と上記複数のMSsへ上記制御信号を送信する送信部を含む構成をとり、ある移動局(MS)に対する制御信号は、他のMSに関する情報を含む。
本発明の一態様によれば、BSは、発信MSと、BSと上記発信MSとの間の通信のために利用される協調MSを含む複数のMSsと通信し、上記複数のMSsの各々に対するリソース割当情報を示す制御信号を生成する制御信号生成部と、上記複数のMSsへ上記制御信号を送信する送信部を具備し、上記協調MSに対する制御信号は、上記発信MSに関する情報を含む。
本発明の一態様によれば、上記協調MSのフローが上記発信MSと同じグループに加えられる場合、上記協調MSに対する制御信号は、上記発信MSに関する情報を含む。
本発明の一態様によれば、上記発信MSに関する情報は、上記協調MSに対するリソース割当情報の中に含まれる。
本発明の一態様によれば、上記発信MSに関する情報は、上記協調MSに対するバースト・サイズ情報と入れ換えられる。
本発明の一態様によれば、上記発信MSに関する情報のビット数は、上記発信MSと同じグループに属するMSsの数に応じて変わる。
本発明の一態様によれば、上記発信MSと同じグループに属するMSsの数に応じて、上記協調MSに対するバースト・サイズ情報のビット数が増加するのに伴い、かつ、上記協調MSに対するリソース・サイズ情報のビット数が減少するのに伴い、上記発信MSに関する情報のビット数は変わる。
本発明の一態様によれば、上記協調MSに対するリソース・サイズ情報のビット数が減少する場合、上記協調MSの実際のリソース・サイズは、上記発信MSのリソース・サイズと上記協調MSの公称リソース・サイズのビット単位の演算結果として得られる。
本発明の一態様によれば、上記協調MSのリソース・サイズは、上記発信MSのリソース・サイズと同じであり、上記発信MSに関する情報は、上記協調MSに対するバースト・サイズ情報及びリソース・サイズ情報と入れ換えられる。
本発明の一態様によれば、上記協調MSの実際のリソース・サイズは、上記発信MSのリソース・サイズと上記協調MSの公称リソース・サイズのビット単位の演算結果として得られる。
本発明の一態様によれば、上記協調MSのリソース・サイズは予め決められた値に設定され、上記発信MSに関する情報は、上記協調MSに対するバースト・サイズ情報及びリソース・サイズ情報と入れ換えられる。
本発明の一態様によれば、上記発信MSに関する情報は、上記発信MSの識別情報である。
本発明の一態様によれば、上記発信MSに関する情報は、上記協調MSの識別情報に相対する、上記発信MSの識別情報のオフセットである。
本発明の一態様によれば、MSは、他のMSに関する情報を含む、自機に対する制御信号を受信する受信部と、上記制御信号、及び、上記他のMSに関する情報に応じて、送信リソースを算出するリソース算出部を具備する。
本発明の一態様によれば、BSと発信MSとの間の通信のために利用される協調MSは、上記発信MSに関する情報を含む自協調MSに対する制御信号を受信する受信部、上記制御信号、及び、上記発信MSに関する情報に応じて、送信リソースを算出するリソース算出部、及び上記発信MSから受信した信号を、上記送信リソースを介して上記BSへ送信する送信部を具備する。
本発明の一態様によれば、上記発信MSに関する情報が上記協調MSの識別情報を示す場合は、上記送信部は、上記BSへの上記信号の送信を停止する。
本発明の一態様によれば、上記発信MSに関する情報が上記協調MSの識別情報を示す場合は、上記送信部は、予め決められた期間または設定可能な期間の間、上記BSへの上記信号の送信を停止する。
本発明の一態様によれば、上記発信MSに関する情報の一部分は、上記協調MSに対するリソース割当情報の中に含まれ、上記発信MSに関する情報のその他の部分は、上記協調MSへ送信されるグループ・コンフィギュレーション情報の中に含まれる。
本発明の一実施形態によれば、複数のMSsと通信するBSにおいて実行される送信方法は、上記複数のMSsの各々に対するリソース割当情報を示す制御信号を生成し、上記複数のMSsへ上記制御信号を送信し、あるMSに対する制御信号は、他のMSに関する情報を含む。
本発明の一実施形態によれば、発信MSと、BSと上記発信MSとの間の通信のために利用される協調MSを含む複数のMSsと通信する基地局(BS)において実行される送信方法は、上記複数のMSsの各々に対するリソース割当情報を示す制御信号を生成し、上記複数のMSsへ上記制御信号を送信し、上記協調MSに対する制御信号は、上記発信MSに関する情報を含む。
本発明の一実施形態によれば、MSにおいて実行される受信方法は、他のMSに関する情報を含む自機に対する制御信号を受信し、上記制御信号及び上記他のMSに関する情報に応じて送信リソースを算出する。
本発明の一実施形態によれば、BSと発信MSとの間の通信のために利用される協調MSにおいて実行される受信方法は、上記発信MSに関する情報を含む自機に対する制御信号を受信し、上記制御信号及び上記発信MSに関する情報に応じて、送信リソースを算出し、上記発信MSから受信した信号を、上記送信リソースを介して上記BSへ送信する。
本発明の上記及びその他の特徴と利点は、添付の図面とともに本発明の以下の詳細な説明を参照し、添付の特許請求の範囲を参照することで、よりよく理解されることになろう。
本発明は同一データ・バーストを処理する複数のMSsに対して一つのHBCHを使用するので、不必要なHFBCHリソースの浪費を避けることができる。
CliCo(クライアント協調動作)を行う無線通信システムの一例を示す図
BS(基地局)の一例を示すブロック図
発信MS(移動局)の一例を示すブロック図
協調MS(移動局)の一例を示すブロック図
フレーム構成の一例を示す図
従来技術による、一部のグループ・リソース割当情報を通知するビットマップの一例を示す図
従来技術による、発信MS(または協調するMS)でグループ・リソース割当情報を受信する方法を例示するフローチャート
本発明の実施の形態1に係る協調するMSでグループ・リソース割当情報を受信する方法を例示するフローチャート
本発明の実施の形態2に係る4ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためビットマップの一例を示す図
本発明の実施の形態2に係る4ビットのユーザ・ビットマップの場合における、協調するMSでグループ・リソース割当情報を受信する方法を例示するフローチャート
本発明の実施の形態2に係る8ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためビットマップの一例を示す図
本発明の実施の形態2に係る8ビットのユーザ・ビットマップの場合における、協調するMSでグループ・リソース割当情報を受信する方法を例示するフローチャート
本発明の実施の形態2に係る32ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を示す図
本発明の実施の形態2に係る32ビットのユーザ・ビットマップの場合における、協調するMSでグループ・リソース割当情報を受信する方法を例示するフローチャート
本発明の実施の形態3に係る4ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を示す図
本発明の実施の形態4に係る8ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を示す図
本発明の実施の形態5に係る8ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を示す図
以下、本発明の実施の形態について、添付図面を参照して詳細に説明する。本願明細書に援用する周知の機能及び構成の詳細な説明は、明確かつ簡潔にするために省略した。
(実施の形態1)
本発明の実施の形態1によれば、図1に準拠して、GRAをCliCoに適用する方法の基本概念は、BS102が、グループ・コンフィギュレーション情報を用いて、発信MS104のUBIを協調MS106に共有させることである。より詳細には、BS102が協調MS106のフローをグループに加えるとき、BS102によって協調MS106へユニキャストされるグループ・コンフィギュレーション情報は、発信MS104のUBIをも含む。BS102によって協調MS106へユニキャストされるグループ・コンフィギュレーション情報の内容は、以下に挙げることができる。
・ 協調MS106のフロー識別子、
・ ユーザ・ビットマップ・サイズ、
・ 発信MS104のUBI、
・ 協調MS106のUBI、
・ グループ識別子、
・ 割当て周期、及び
・ MIMOモード・セット、等
本発明の実施の形態1によれば、協調MS106は発信MS104のUBIを知るので、協調MS106は、自機のHFBCHインデックスを導出するために、自機自身のUBIの代わりに発信MS104のUBIを使用することができる。その結果、同一のHFBCHのみが、CliCoに関与する発信MS104及び協調MS106の両方に割り当てられる。したがって、不必要なHFBCHリソースの浪費が避けられる。
本発明の実施の形態1による、協調MS106でリソース・スケジューリング情報を受信するための方法500を例示するフローチャートを図8に示す。方法500はステップ502で開始する。ステップ504において、協調MS106は、自機のUBIに照らしてユーザ・ビットマップをチェックする。ステップ506では、協調MS106は、自機のフローが現在のフレームにスケジュールされているか否かを判定する。協調MS106のフローが現在のフレームにスケジュールされていれば、ステップ508において、協調MS106は、自機のHARQバースト・サイズ及びリソース・サイズを導出するために、自機のUBIに照らしてリソース割当ビットマップをチェックする。ステップ510では、協調MS106は、発信MS104のUBIに応じて自機のHFBCHインデックスを算出する。ステップ506で、協調MS106のフローが現在のフレームにスケジュールされていなければ、方法500はステップ512で終了する。
本発明の実施の形態1によれば、BS102によって発信MS104へユニキャストされるグループ・コンフィギュレーション情報の内容と、BS102によって発信MS104及び協調MS106へマルチキャストされるグループ・リソース割当情報の内容とは、IEEE 802.16m草案標準(例えば、非特許文献1参照)と同じである。しかしながら、BS102によって協調MS104へユニキャストされるグループ・コンフィギュレーション情報の内容は、IEEE 802.16m草案標準(例えば、非特許文献1参照)とは異なる。
本発明の実施の形態1によると、代替的な手法は、グループ・コンフィギュレーション情報が、BS102によって発信MS104と協調MS106の両方へマルチキャストされることである。BS102によって発信MS104及び協調MS106の両方へマルチキャストされるグループ・コンフィギュレーション情報の内容は、以下に挙げることができる。
・ 発信MS104のフロー識別子、
・ 協調MS106のフロー識別子、
・ ユーザ・ビットマップ・サイズ、
・ 発信MS104のUBI、
・ 協調MS106のUBI、
・ グループ識別子、
・ 割当て周期、及び
・ MIMOモード・セット、等
本発明の実施の形態1によれば、グループ・コンフィギュレーション情報は、MAC制御メッセージまたはMAP IEのいずれかで送信され得る。
(実施の形態2)
本発明の実施の形態1によれば、発信MS104のUBIを協調MS106に共有させることによって、グループ・リソース割当を開始する前の段階でグループ・コンフィギュレーション情報に追加の制御オーバヘッドが導入される可能性があるという欠点がある。
図1に準拠して、前述したとおり、CliCoに関与する発信MS104及び協調MS106は同一のデータ・バーストを処理するため、同一のHARQバースト・サイズを有することになる。したがって、発信MS104及び協調MS106のいずれか一方に対するHARQバースト・サイズ指示は不必要である。さらに、実際に必要とされるUBIの長さは、ユーザ・ビットマップ・サイズに依存する。例えば、ユーザ・ビットマップ・サイズが8ビットである場合、5ビットのUBIではなく3ビットのUBIのみが実際に必要とされる。
本発明の実施の形態2によれば、GRAをCliCoに適用する方法の基本概念は、BS102が、本発明の実施の形態1におけるグループ・コンフィギュレーション情報の代わりに、グループ・リソース割当情報を用いて、発信MS104のUBIを協調MS106に共有させることである。より詳細には、BS102が発信MS104及び協調MS106にリソースを割り当てる場合、リソース割当ビットマップ中の協調MS106用の5ビットのリソース割当指示の可変部分が、発信MS104のUBIを指示するために使用される。上記可変部分の長さはユーザ・ビットマップ・サイズに依存する。協調MS106用の上記5ビットのリソース割当指示の残りの部分は、協調MSのリソース・サイズを指示するために使用される。ただし、協調MS106のリソース・サイズを指示するための方法は、ユーザ・ビットマップ・サイズに応じて異なる。
本発明の実施の形態2によれば、発信MS104のUBIはリソース割当てビットマップに組み込まれているので、グループ・コンフィギュレーション情報に追加の制御オーバヘッドが導入されることはない。
本発明の実施の形態2による、4ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するビットマップの一例を図9に示す。図9を参照すると、リソース割当ビットマップ604の中で、協調MS106用の5ビットのリソース割当指示の最初の2ビット(例えば、「00」)が、協調MS106のHARQバースト・サイズではなく、発信MS104のUBIを指示するために使用され、最後の3ビット(例えば、「010」)が、協調MS106用のリソース・サイズを伝えるために使用される。なお、発信MS104用の5ビットのリソース割当指示の最初の2ビット(例えば、「10」)は、発信MS104及び協調MS106の両方のHARQバースト・サイズを伝えるために使用されることに留意されたい。
本発明の実施の形態2による、4ビットのユーザ・ビットマップの場合における、協調MS106でグループ・リソース割当情報を受信するための方法700を例示するフローチャートを図10に示す。方法700はステップ702で開始する。ステップ704において、協調MS106は、自機のUBIに照らしてユーザ・ビットマップをチェックする。ステップ706では、協調MS106は、自機のフローが現在のフレームにスケジュールされているか否かを判定する。協調MS106のフローが現在のフレームにスケジュールされていれば、ステップ708において、協調MS106は、発信MS104のUBIと自機のリソース・サイズを導出するために、自機のUBIに照らしてリソース割当ビットマップをチェックする。ステップ710では、協調MS106は、自機のHARQバースト・サイズを導出するために、発信MS104のUBIに照らしてリソース割当てビットマップを再びチェックする。ステップ712で、協調MS106は、発信MS104のUBIに応じて自機のHFBCHインデックスを算出する。ステップ706において、協調MS106のフローが現在のフレームにスケジュールされていなければ、方法700はステップ714で終了する。
本発明の実施の形態2による、8ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図11に示す。図11を参照すると、リソース割当ビットマップ804の中で、協調MS106用の5ビットのリソース割当指示の最初の3ビットが、発信MS104のUBIを指示するために使用され、最後の2ビットが、協調MS106の実際のリソース・サイズではなく、協調MS106の公称リソース・サイズを指示するために使用される。
協調MSの公称リソース指示から協調MS106の実際のリソース・サイズ指示を算出する手法はいろいろある。一つの手法では、協調MS106の実際のリソース・サイズ指示は、発信MS104のリソース・サイズ指示と協調MS106の公称リソース・サイズ指示とのビット単位の排他論理和演算の結果として得ることができる。図11を参照すると、発信MS104のリソース・サイズ指示が「111」であり、協調MS106の公称リソース・サイズ指示が「01」である。したがって、協調MS106の実際のリソース・サイズ指示は、「111 XOR 01 = 110」となる。別の手法では、協調MS106の実際のリソース・サイズ指示は、発信MS104のリソース・サイズ指示と協調MS106の公称リソース・サイズ指示とのビット単位の論理和または論理積の結果として得ることができる。
本発明の実施の形態2による、8ビットのユーザ・ビットマップの場合における、協調MS106でグループ・リソース割当情報を受信するための方法900を例示するフローチャートを図12に示す。方法900はステップ902で開始する。ステップ904において、協調MS106は、自機のUBIに照らしてユーザ・ビットマップをチェックする。ステップ906で、協調MS106は、自機のフローが現在のフレームにスケジュールされているか否かを判定する。協調MS106のフローが現在のフレームにスケジュールされていれば、ステップ908において、協調MS106は、発信MS104のUBIを導出するために、リソース割当てビットマップをチェックする。ステップ910では、協調MS106は、自機のHARQバースト・サイズとリソース・サイズを導出するために、自機のUBIと発信MS104のUBIに照らしてリソース割当ビットマップを再びチェックする。ステップ912で、協調MS106は、発信MS104のUBIにより自機のHFBCHインデックスを算出する。ステップ906において、協調MS106のフローが現在のフレームにスケジュールされていなければ、方法900はステップ914で終了する。
本発明の実施の形態2によれば、8ビットのユーザ・ビットマップの場合と同様に、16ビットのユーザ・ビットマップの場合には、リソース割当ビットマップ中で、協調MS106用の5ビットのリソース割当指示の最初の4ビットが、発信MS104のUBIを指示するために使用され、最後の1ビットが、協調MS106の実際のリソース・サイズではなく、協調MS106の公称リソース・サイズを指示するために使用される。
本発明の実施の形態2による、32ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図13に示す。図13を参照すると、リソース割当てビットマップ1004の中で、協調MS106用の5ビットのリソース割当指示の全部が、発信MS104のUBIを指示するために使用される。協調MS106のリソース・サイズは、発信MS104用の3ビットのリソース・サイズ指示によって伝えられる。つまり、32ビットのユーザ・ビットマップの場合には、発信MS104と協調MS106は常に同じリソース・サイズを有する。
本発明の実施の形態2による、グループ・リソース割当情報を送信するためのGRA MAP IEの一例を表2に示す。
本発明の実施の形態2による、32ビットのユーザ・ビットマップの場合における、協調MS106でグループ・リソース割当情報を受信するための方法1100を例示するフローチャートを図14に示す。方法1100はステップ1102で開始する。ステップ1104において、協調MS106は、自機のUBIに照らしてユーザ・ビットマップをチェックする。ステップ1106で、協調MS106は、自機のフローが現在のフレームにスケジュールされているか否かを判定する。協調MS106のフローが現在のフレームにスケジュールされていれば、ステップ1108において、協調MS106は、発信MS104のUBIを導出するために、リソース割当てビットマップをチェックする。ステップ1110では、協調MS106は、自機のHARQバースト・サイズとリソース・サイズを導出するために、発信MS104のUBIに照らしてリソース割当ビットマップを再びチェックする。ステップ1112で、協調MS106は、発信MS104のUBIに応じて、自機のHFBCHインデックスを算出する。ステップ1106において、協調MS106のフローが現在のフレームにスケジュールされていなければ、方法1100はステップ1114で終了する。
協調MS106の視点からは、方法700、900及び1100の間の違いは、自機のリソース・サイズを導出する方法にある。方法700では、協調MS106のリソース・サイズは、自機自身のUBIに照らして導出される。方法900では、協調MS106のリソース・サイズは、自機自身のUBIと発信MS104のUBIとに照らして導出される。方法1100では、協調MS106のリソース・サイズは、発信MS104のUBIのみに照らして導出される。
本発明の実施の形態2によれば、8ビットのユーザ・ビットマップの場合の代替的な手法は、リソース割当ビットマップの中で、協調MS106用の5ビットのリソース割当指示の最初の3ビットは、発信MS104のUBIを指示するために使用されるが、最後の2ビットは、協調MS106の公称リソース・サイズではなく、協調MS106の実際のリソース・サイズを伝えるために使用される。同様に、16ビットのユーザ・ビットマップの場合の代替的な手法は、リソース割当ビットマップの中で、協調MS106用の5ビットのリソース割当指示の最初の4ビットは、発信MS104のUBIを指示するために使用されるが、最後の1ビットは、協調MS106の実際のリソース・サイズを指示するために使用される。
本発明の実施の形態2によれば、4ビットのユーザ・ビットマップの場合の代替的な手法は、リソース割当ビットマップの中で、協調MS106用の5ビットのリソース割当指示の最初の2ビットは、発信MS104のUBIを指示するために使用されるが、最後の3ビットは、協調MS106の実際のリソース・サイズではなく、協調MS106の公称リソース・サイズを指示するために使用される。協調MS106の実際のリソース・サイズは、発信MS104のリソース・サイズ指示と協調MS106の公称リソース・サイズ指示から上述した方式で導出することができる。
本発明の実施の形態2によれば、32ビットのユーザ・ビットマップの場合の代替的な手法は、リソース割当ビットマップの中の協調MS106の5ビットのリソース割当指示の全部が、発信MS104のUBIを伝えるために使用されるが、協調MS106のリソース・サイズは常に予め決められた値に設定される。
本発明の実施の形態2によれば、BS102によって発信MS104または協調MS106へユニキャストされるグループ・コンフィギュレーション情報の内容は、IEEE 802.16m草案標準(例えば、非特許文献1参照)と同じである。しかしながら、BS102によって発信MS104または協調MS106へマルチキャストされるグループ・リソース割当情報の内容は、IEEE 802.16m草案標準(例えば、非特許文献1参照)とは異なる。
本発明の実施の形態2によれば、グループ・リソース割当情報は、マルチキャストMAC制御情報またはマルチキャストMAP IEのいずれかで送信され得る。
(実施の形態3)
本発明の第1及び実施の形態2によれば、リソース割当ビットマップの中の発信MS104のUBI指示は、協調MS106のUBIとは異なると仮定されている。以下では、リソース割当ビットマップの中の発信MS104のUBI指示が協調MS106のUBIと同じである場合を取り上げる。
本発明の実施の形態3による、4ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図15に示す。図15を参照すると、リソース割当ビットマップ1204の中で、協調MS106用の5ビットのリソース割当指示の最初の2ビットが、発信MS104のUBIを指示するために使用される。発信MS104のUBI指示(例えば、「10」)が協調MS106のUBIと同じである場合には、様々な暗示を生じさせ得る。例えば、通信相手のMS106は、その後のN個の連続割当期間にUL/DLデータ・バーストを送信/受信しないことを暗示し得る。ここでNは予め決められている。または、Nの値は協調MS106用の5ビットのリソース割当指示の最後の3ビットによって指示される。あるいは、協調MS106が今後はUL/DLデータ・バーストを送信/受信しないことを暗示し得る。
本発明の実施の形態3によれば、8ビット、16ビット、または32ビットのユーザ・ビットマップの場合において、リソース割当ビットマップ中の発信MS104のUBI指示が協調MS106のUBIと同じである場合、4ビットのユーザ・ビットマップの場合と同様の暗示を生じさせ得る。
(実施の形態4)
本発明の実施の形態1,2,3によれば、発信MS104のUBI指示値の長さは、ユーザ・ビットマップのサイズに依存している。その結果、4ビットのユーザ・ビットマップの場合には、協調MS106のリソース・サイズを伝えるために3ビットが使用可能である。したがって、協調MS106へリソースを割り当てるために8個のリソース・サイズのセットの全部が使用可能となる。しかし、8ビット、16ビット、または32ビットのユーザ・ビットマップの場合には、協調MS106へリソースを割り当てるために8個のリソース・サイズのセットの一部しか使用できない。これは、BS102のスケジューリングの柔軟性を低下させる。
本発明の実施の形態4による、8ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図16に示す。図16を参照すると、リソース割当ビットマップ1304の中で、協調MS106用の5ビットのリソース割当指示の最初の2ビットだけが、協調MS106のUBIに相対する発信MS104のUBIのオフセットを指示するために使用され、最後の3ビットが、協調MS106のリソース・サイズを指示するために使用される。
本発明の実施の形態4による、グループ・リソース割当情報を送信するためのGRA MAP IEの一例を表3に示す。
本発明の実施の形態4によれば、8ビット、16ビット、または32ビットのユーザ・ビットマップの場合に、発信MS106のUBI指示のために2ビットだけが使用されるので、BS102が発信MS104と協調MS106のそれぞれのフローをグループに加える際に、いろいろな制約が課せられる必要がある。発信MS104と協調MS106のそれぞれのフローをグループに加える際に、BS102は、例えば、下記の制約を受けることがあり得る。
・ 発信MS104のUBIは協調MS106のUBIよりも小さい、及び
・ 発信MS104のUBIと協調MS106のUBIとの差が4よりも大きい
本発明の実施の形態4によれば、協調MS106のリソース・サイズを指示するために3ビットが使用されるので、8ビット、16ビット、または32ビットのユーザ・ビットマップの場合にも、協調MS106のリソースを割り当てるために、8個のリソース・サイズのセットの全部を使用できる。
(実施の形態5)
本発明の実施の形態4によれば、BS102が発信MS104と協調MS106のそれぞれのフローをグループに加えるときに、いくつかの制約が課せられる必要がある。これは、BS102のグループ・コンフィギュレーションの柔軟性を低下させる可能性がある。
本発明の実施の形態5による、8ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図17に示す。図17を参照すると、リソース割当ビットマップ1404の中で、協調MS106用の5ビットのリソース割当指示の最初の2ビットが、発信MS104のUBIの第1の部分を指示するために使用され、最後の3ビットが、協調MS106のリソース・サイズを指示するために使用される。
本発明の実施の形態5による、グループ・リソース割当情報を送信するためのGRA MAP IEの一例を表4に示す。
本発明の実施の形態5によれば、BS102によって協調MS106へユニキャストされるグループ・コンフィギュレーション情報は、発信MS104のUBIの第2の部分を含む。BS102によって協調MS106へユニキャストされるグループ・コンフィギュレーション情報の内容は、以下に挙げることができる。
・ 協調MS106のフロー識別子、
・ ユーザ・ビットマップ・サイズ、
・ 発信MS104のUBIの第2の部分、
・ 協調MS106のUBI、
・ グループID、
・ 割当て周期、及び
・ MIMOモード・セット、等
本発明の実施の形態5によれば、8ビットのユーザ・ビットマップの場合に、グループ・コンフィギュレーション情報及びグループ・リソース割当情報で通知される3ビットが、発信MS106のUBI指示のために使用され、BS102が発信MS104と協調MS106のそれぞれのフローをグループに加えるときに何の制約も課されない。
本発明の実施の形態5によれば、発信MS104のUBIの第1の部分は、発信MS104のUBIのLSB(最下位ビット)側の2ビットであり得る。発信MS104のUBIの第2の部分は、8ビット、16ビット及び32ビットのユーザ・ビットマップの場合にそれぞれ対応して、発信MS104のUBIのMSB(最上位ビット)の1ビット、MSB側の2ビット及びMSB側の3ビットであり得る。
本発明の実施の形態5によれば、代替的に、発信MS104のUBIの第1の部分は、発信MS104のUBIのMSB側の2ビットであり得る。発信MS104のUBIの第2の部分は、8ビット、16ビット及び32ビットのユーザ・ビットマップの場合にそれぞれ対応して、発信MS104のUBIのLSBの1ビット、LSB側の2ビット及びLSB側の3ビットであり得る。本発明の上述した個々の実施形態によれば、協調MS106が自機のHFBCHを算出するために発信MS104のUBIを使用できるように、BS102は発信MS104のUBIを 協調MS106に共有させる。BS102が協調MS106のUBIを発信MS104に共有させるような、本発明の多様な変形及び/または修正が行なえることは当業者には当然理解されるであろう。
本発明の上述した個々の実施形態によれば、発信MS104に加えて、1台の協調MS106だけがCliCoにかかわり合う。2台以上の協調MSがCliCoにかかわり合い、そしてBS102は、CliCoに関与する発信MSと複数の協調MSのうちの一つのUBIをその他のMSに共有させるような、本発明の多様な変形及び/または修正が行なえることは当業者には当然理解されるであろう。
具体的な個々の実施形態として示した本発明のその他の多様な変形及び/または修正は、広義に記述された本発明の精神または範囲を逸脱しない限りにおいて行なえることは当業者には当然理解されるであろう。本文書に述べた個々の実施形態は、したがって、あらゆる点において例示であり、制限的ではないと見なされるべきある。
なお、上記実施の形態では、本発明をハードウェアで構成する場合を例にとって説明したが、本発明はハードウェアとの連携においてソフトウェアでも実現することも可能である。
また、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるLSIとして実現される。これらは個別に1チップ化されてもよいし、一部または全てを含むように1チップ化されてもよい。ここでは、LSIとしたが、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。
また、集積回路化の手法はLSIに限るものではなく、専用回路または汎用プロセッサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
さらには、半導体技術の進歩または派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
2010年4月20日出願の特願2010−097026の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
本発明は、移動体通信システム等に適用することができる。