"複数の移動局と通信する基地局であって、前記複数の移動局の各々に対するリソース割当情報を示す制御信号を生成する制御信号生成部と、前記生成された制御信号を、前記複数の移動局へ送信する送信部と、を具備し、前記複数の移動局の中の第1の移動局に対する制御信号は、前記複数の移動局の中の第2の移動局に関する情報を含む、基地局。前記第2の移動局は前記基地局と直接通信を行う発信移動局であり、前記第1の移動局は前記基地局と前記発信移動局との間の通信のために利用される協調移動局であって、前記協調移動局に対する制御信号は、前記発信移動局に関する情報を含む、請求項1に記載の基地局。前記協調移動局が前記発信移動局と同じグループに加えられる場合、前記協調移動局に対する前記制御信号は、前記発信移動局に関する情報を含む、請求項2に記載の基地局。前記発信移動局に関する情報は、前記協調移動局に対するリソース割当情報の中に含まれる、請求項2に記載の基地局。前記発信移動局に関する情報は、前記協調移動局に対するバーストサイズ情報と入れ換えられる、請求項4に記載の基地局。前記発信移動局に関する情報のビット数は、前記発信移動局と同じグループに属する移動局の数に応じて変わる、請求項2に記載の基地局。前記発信移動局と同じグループに属する移動局の数に応じて、前記協調移動局に対するバーストサイズ情報のビット数が増加するのに伴い、かつ、前記協調移動局に対するリソースサイズ情報のビット数が減少するのに伴い、前記発信移動局に関する前記情報のビット数は変わる、請求項6に記載の基地局。前記協調移動局に対するリソースサイズ情報のビット数が減少する場合、前記協調移動局の実際のリソースサイズは、前記発信移動局のリソースサイズと前記協調移動局の公称リソースサイズのビット単位の演算結果として得られる、請求項7に記載の基地局。前記協調移動局のリソースサイズは、前記発信移動局のリソースサイズと同じであり、前記発信移動局に関する情報は、前記協調移動局に対するバーストサイズ情報及びリソースサイズ情報と入れ換えられる、請求項4に記載の基地局。前記協調移動局の実際のリソースサイズは、前記発信移動局のリソースサイズと前記協調移動局の公称リソースサイズのビット単位の演算結果として得られる、請求項4に記載の基地局。前記協調移動局のリソースサイズは予め決められた値に設定され、前記発信移動局に関する情報は、前記協調移動局に対するバーストサイズ情報及びリソースサイズ情報と入れ換えられる、請求項5に記載の基地局。前記発信移動局に関する情報は、前記発信移動局の識別情報である、請求項2に記載の基地局。前記発信移動局に関する情報は、前記協調移動局の識別情報に相対する、前記発信移動局の識別情報のオフセットである、請求項2に記載の基地局。他の移動局に関する情報を含む、自局に対する制御信号を受信する受信部と、前記制御信号、及び、前記他の移動局に関する情報に応じて、送信リソースを算出するリソース算出部と、を具備する移動局。前記他の移動局は基地局と直接通信を行う発信移動局であり、前記移動局は前記基地局と前記発信移動局との間の通信のために利用される協調移動局であって、前記制御情報に含まれる前記他の移動局に関する情報は、前記発信移動局に関する情報であり、前記発信移動局から受信した信号を、前記送信リソースを介して前記基地局へ送信する送信部をさらに具備する、請求項14に記載の移動局。前記発信移動局に関する情報が前記協調移動局の識別情報を示す場合、前記送信部は、前記基地局への前記信号の送信を停止する、請求項15に記載の協調移動局。前記発信移動局に関する情報が前記協調移動局の識別情報を示す場合、前記送信部は、予め決められた期間または設定可能な期間の間、前記基地局への前記信号の送信を停止する、請求項15に記載の協調移動局。前記発信移動局に関する情報の一部分は、前記協調移動局に対するリソース割当情報の中に含まれ、前記発信移動局に関する情報のその他の部分は、前記協調移動局へ送信されるグループコンフィギュレーション情報の中に含まれる、請求項2に記載の基地局。複数の移動局と通信する基地局において実行される送信方法であって、前記複数の移動局の各々に対するリソース割当情報を示す制御信号を生成し、前記生成された制御信号を、前記複数の移動局へ送信し、前記複数の移動局の中の第1の移動局に対する制御信号は、前記複数の移動局の中の第2の移動局に関する情報を含む、送信方法。移動局において実行される受信方法であって、他の移動局に関する情報を含む前記移動局に対する制御信号を受信し、前記制御信号、及び、前記他の移動局に関する情報に応じて、送信リソースを算出する、受信方法。IEEE802.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リソースの浪費を避けることができる。以下、本発明の実施の形態について、添付図面を参照して詳細に説明する。本願明細書に援用する周知の機能及び構成の詳細な説明は、明確かつ簡潔にするために省略した。実施の形態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へマルチキャストされるグループリソース割当情報の内容とは、IEEE802.16m草案標準例えば、非特許文献1参照と同じである。しかしながら、BS102によって協調MS104へユニキャストされるグループコンフィギュレーション情報の内容は、IEEE802.16m草案標準例えば、非特許文献1参照とは異なる。本発明の実施の形態1によると、代替的な手法は、グループコンフィギュレーション情報が、BS102によって発信MS104と協調MS106の両方へマルチキャストされることである。BS102によって発信MS104及び協調MS106の両方へマルチキャストされるグループコンフィギュレーション情報の内容は、以下に挙げることができる。発信MS104のフロー識別子、協調MS106のフロー識別子、ユーザビットマップサイズ、発信MS104のUBI、協調MS106のUBI、グループ識別子、割当て周期、及びMIMOモードセット、等本発明の実施の形態1によれば、グループコンフィギュレーション情報は、MAC制御メッセージまたはMAPIEのいずれかで送信され得る。実施の形態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の実際のリソースサイズ指示は、111XOR01=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による、グループリソース割当情報を送信するためのGRAMAPIEの一例を表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へユニキャストされるグループコンフィギュレーション情報の内容は、IEEE802.16m草案標準例えば、非特許文献1参照と同じである。しかしながら、BS102によって発信MS104または協調MS106へマルチキャストされるグループリソース割当情報の内容は、IEEE802.16m草案標準例えば、非特許文献1参照とは異なる。本発明の実施の形態2によれば、グループリソース割当情報は、マルチキャストMAC制御情報またはマルチキャストMAPIEのいずれかで送信され得る。実施の形態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による、グループリソース割当情報を送信するためのGRAMAPIEの一例を表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による、グループリソース割当情報を送信するためのGRAMAPIEの一例を表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製造後に、プログラムすることが可能なFPGAFieldProgrammableGateArrayや、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブルプロセッサを利用してもよい。さらには、半導体技術の進歩または派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。2010年4月20日出願の特願2010-097026の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。"