JP5885817B2 - 移動局及び受信方法 - Google Patents

Description

本発明は、クライアント協調動作を行う、移動局及び受信方法に関する。

ＩＥＥＥ（Institute of Electrical and Electronics Engineers、電気電子技術者協会）８０２．１６ワーキンググループは、ＩＭＴ（International Mobile Telecommunications）−アドバンスト次世代携帯電話システムの諸要件を満たす８０２．１６ｍ無線インタフェース仕様を作成中である。ＩＥＥＥ ８０２．１６ｍ草案標準（例えば、非特許文献１参照）に基づいて、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）フォーラムは、ＷｉＭＡＸ リリース２．０ ＭＳＰ（Mobile System Profile）及びＰＩＣＳ（Protocol Implementation Conformance Statement）を考案中である。ＩＥＥＥ ８０２．１６ｍ標準並びにＷｉＭＡＸリリース２．０ ＭＳＰ及びＰＩＣＳは、２０１１年早期には仕上げられると見込まれる。

また、ＩＥＥＥ８０２．１６ワーキンググループは、８０２．１６ｍ／ＷｉＭＡＸ２．０を超える将来の８０２．１６／ＷｉＭＡＸネットワークの構想設計を開始した。将来の８０２．１６／ＷｉＭＡＸネットワークは、大型画面の機器、マルチメディア・アプリケーション並びにさらに増加する接続ユーザ及び機器によって拍車をかけられる移動通信データ・トラフィックの爆発的な増加をサポートするものになるだろうという共通の認識が、８０２．１６／ＷｉＭＡＸコミュニティの間にはある。また、将来の８０２．１６／ＷｉＭＡＸネットワークは、例えば、８０２．１１／Ｗｉ−Ｆｉ（Wireless Fidelity）等の他の無線技術と効率的に連携動作するものになるであろう。

将来の８０２．１６／ＷｉＭＡＸネットワークは、スループットやＳＥ（Spectral Efficiency）等の様々な性能指標値に関して、８０２．１６ｍネットワークと比較して大幅に改良されたものになるであろう。例えば、都市区域におけるカバレッジを想定した場合、将来の８０２．１６／ＷｉＭＡＸネットワークは、ＵＬ（Uplink，アップリンク）とＤＬ（Downlink，ダウンリンク）の両方で、８０２．１６ｍ／ＷｉＭＡＸ２．０ネットワークの２倍のＳＥをセルエッジでの目標にしている（例えば、非特許文献２参照）。８０２．１６ｍ／ＷｉＭＡＸ２．０ネットワークは、４´２アンテナ構成で少なくとも０．０６ｂｐｓ／Ｈｚ／秒のＤＬのセルエッジでのＳＥと２´４アンテナ構成で少なくとも０．０３ｂｐｓ／Ｈｚ／秒のＵＬのセルエッジでのＳＥをもつことに留意されたい。

例えば、ＣｌｉＣｏ（Client Collaboration、クライアント協調動作）等の協調技術は、無線通信システムのセルエッジでのＳＥ及びネットワーク全体のエネルギー効率の大幅な改良を確かなものにした。ＣｌｉＣｏは、無線環境においてクライアント同士がデータを合同で送信／受信するために交信する技術である（例えば、非特許文献３参照）。ＣｌｉＣｏでは、ＢＳとクライアント間で複数の経路を介して情報を送信／受信するために、クライアント・クラスタリング（Client Clustering）及びピアツーピア（Peer-to-Peer）通信が利用される。その結果、設備コストの増加なしに、セルエッジでのＳＥを向上させることができる。さらに、劣悪なチャネルを有するクライアントの電池を長持ちさせることができる。

ＣｌｉＣｏを行う典型的な無線通信システム１００を例示する図を図１に示す。無線通信システム１００は、ＢＳ（Base Station，基地局）１０２と、例えば、ＭＳ１０４及びＭＳ１０６の複数のＭＳ（Mobile Station，移動局）とを含む構成を採る。

典型的なＢＳ１０２を例示するブロック図を図２に示す。ＢＳ１０２は、ここではＷｉＭＡＸによる通信機能のみを装備し、ＷｉＭＡＸ ＰＨＹブロック１３０とＷｉＭＡＸ ＭＡＣブロック１２０からなる。ＷｉＭＡＸ ＭＡＣブロック１２０は、ＷｉＭＡＸ ＯＦＤＭＡ（Orthogonal Frequency Division Multiple Access）ベースの媒体アクセス制御（Media Access Control：ＭＡＣ）プロトコルを実行する。ＷｉＭＡＸ ＰＨＹブロック１３０は、ＷｉＭＡＸ ＭＡＣブロック１２０の制御の下で、ＷｉＭＡＸ ＯＦＤＭＡベースの物理層プロトコルを実行する。

図２を参照すると、ＷｉＭＡＸ ＭＡＣブロック１２０はさらに、制御部１２２、スケジューラ１２４、メッセージ生成部１２６及びメッセージ処理部１２８を含む構成を採る。制御部１２２は、一般的なＭＡＣプロトコル動作を制御する。スケジューラ１２４は、制御部１２２の制御の下で、各ＭＳへのリソースの割当をスケジュールする。メッセージ生成部１２６は、スケジューラ１２４からリソース割当スケジューリング情報を受け取ると、データ・パケット及びＤＬ制御情報を生成する。メッセージ処理部１２８は、制御部１２２の制御の下で、複数のＭＳから受信したデータ・パケット及びＵＬ制御情報を分析し、その分析結果を制御部１２２へ報告する。

メッセージ生成部１２６によって生成されたデータ・パケット及びＤＬ制御情報は、ＷｉＭＡＸ ＰＨＹブロック１３０内のＯＦＤＭＡ送信器（図２では図示せず）を介してＢＳ１０２によって複数のＭＳへ送信されることに留意されたい。メッセージ処理部１２８によって分析されるデータ・パケット及びＵＬ制御情報は、ＷｉＭＡＸ ＰＨＹブロック１３０内のＯＦＤＭＡ受信器（図２では図示せず）を介してＢＳ１０２によって受信される。

図２を参照すると、メッセージ生成部１２６内には、ＨＦＢＣＨ（ＨＡＲＱフィードバック・チャネル）生成部１３２とリソース割当生成部１３４とが存在する。ここで、ＨＡＲＱはハイブリッド自動再送要求（Hybrid Automatic Repeat Request）を表す。ＨＦＢＣＨ生成部１３２は、ＵＬデータ送信に対するＨＡＲＱフィードバック情報（例えば、ＡＣＫ／ＮＡＣＫ）を通知する、ＵＬデータ送信に対するＨＡＲＱフィードバック・チャネルを生成する。リソース割当生成部１３４は、複数のＭＳの各々へのリソース割当情報を通知する、ＵＬ／ＤＬデータ送信のためのリソース割当制御情報を生成する。

ＧＲＡ（Group Resource Allocation）の観点では、リソース割当生成部１３４によって生成されるリソース割当制御情報は、グループ・コンフィギュレーション（Group Configuration）情報並びにＤＬ／ＵＬでのＧＲＡ送信のためのＨＦＢＣＨのインデックス情報を含むグループ・リソース割当情報を含み得る。ＨＦＢＣＨ生成部１３２によって生成されるＨＦＢＣＨは、ＵＬでのＧＲＡ送信に対するＨＡＲＱフィードバック情報を含み得る。

図２を参照するとメッセージ処理部１２８内には、ＨＦＢＣＨ分析部１３６が存在する。ＨＦＢＣＨ分析部１３６は、ＤＬでのデータ送信に対して受信したＨＦＢＣＨを分析し、その対応するＤＬデータ送信が成功したか否かを判断する。ＧＲＡの観点では、ＨＦＢＣＨ分析部１３６は、受信したＵＬ制御情報からＤＬでのＧＲＡ送信に対するＨＡＲＱフィードバック情報を導出し得る。

典型的なＭＳ１０４を例示するブロック図を図３に示す。ＭＳ１０４は、ＷｉＭＡＸ及びＷｉ−Ｆｉの両方による通信機能を装備し、ＷｉＭＡＸ ＰＨＹブロック１４２、Ｗｉ−Ｆｉ ＰＨＹブロック１４４、ＷｉＭＡＸ ＭＡＣブロック１４６、Ｗｉ−Ｆｉ ＭＡＣブロック１４８、及びＧＬＬ（Generic Link Layer）ブロック１５０から構成される。ＷｉＭＡＸ ＭＡＣブロック１４６は、ＷｉＭＡＸ ＯＦＤＭＡベースのＭＡＣ（媒体アクセス制御）プロトコルを実行する。ＷｉＭＡＸ ＰＨＹブロック１４２は、ＷｉＭＡＸ ＭＡＣブロック１４６の制御の下で、ＷｉＭＡＸ ＯＦＤＭＡベースの物理層プロトコルを実行する。Ｗｉ−Ｆｉ ＭＡＣブロック１４８は、Ｗｉ−Ｆｉ ＣＳＭＡ／ＣＡ（Carrier Sense Multiple Access with Collision Avoidance）ベースのＭＡＣ（媒体アクセス制御）プロトコルを実行する。Ｗｉ−Ｆｉ ＰＨＹブロック１４４は、Ｗｉ−Ｆｉ ＭＡＣブロック１４８の制御の下で、Ｗｉ−Ｆｉ ＯＦＤＭ（Orthogonal Frequency Division Multiplexing）／ＤＳＳＳ（Direct Sequence Spread Spectrum）ベースの物理層プロトコルを実行する。ＧＬＬブロック１５０は、異種のＷｉＭＡＸリンクとＷ−Ｆｉリンクとの間の連携動作を管理するものとして機能する。

図３を参照すると、ＷｉＭＡＸ ＭＡＣブロック１４６はさらに、制御部１５４、メッセージ生成部１５２、及びメッセージ処理部１５６を含む構成を採る。制御部１５４は、一般的なＭＡＣプロトコル動作を制御する。メッセージ生成部１５２は、制御部１５４の制御の下で、ＵＬ制御情報及びデータ・パケットを生成する。メッセージ処理部１５６は、制御部１５４の制御の下で、ＢＳ１０２から受信したデータ・パケット及びＤＬ制御情報を分析し、その分析結果を制御部１５４へ供給する。

メッセージ生成部１５２によって生成されたデータ・パケット及びＵＬ制御情報は、ＷｉＭＡＸ ＰＨＹブロック１４２内のＯＦＤＭＡ送信器（図３では図示せず）を介して、ＭＳ１０４からＢＳ１０２へ送信されることに留意されたい。メッセージ処理部１５６によって分析されるデータ・パケット及びＤＬ制御情報は、ＷｉＭＡＸ ＰＨＹブロック１４２内のＯＦＤＭＡ受信器（図３では図示せず）を介してＭＳ１０４によって受信される。

図３を参照すると、メッセージ処理部１５６内には、リソース分析部１５１とＨＦＢＣＨ分析部１５３とが存在する。ＨＦＢＣＨ分析部１５３は、ＵＬでのデータ送信に対して受信したＨＦＢＣＨを分析し、その対応するＵＬデータ送信が成功したか否かを判断する。リソース分析部１５１は、受信したリソース割当制御情報を分析し、ＭＳ１０４に対して特定されたリソース割当情報を導出する。ＵＬデータ送信の場合には、制御部１５４の制御の下でメッセージ生成部１５２によって生成されたデータ・パケットは、次に、導出されたリソース割当情報に従って、ＭＳ１０４からＢＳ１０２へ送信される。ＤＬデータ送信の場合には、ＢＳ１０２からＭＳ１０４へ送信されたデータ・パケットは、次に、導出されたリソース割当情報に従ってＭＳ１０４によって受信される。

ＧＲＡの観点では、メッセージ処理部１５６内のリソース分析部１５１は、受信したリソース割当制御情報から、グループ・コンフィギュレーション情報並びにＤＬ／ＵＬでのＧＲＡ送信のためのＨＦＢＣＨのインデックス情報を含むグループ・リソース割当情報を導出し得る。ＨＦＢＣＨ分析部１５３は、受信したＨＦＢＣＨから、ＵＬでのＧＲＡ送信に対するＨＡＲＱフィードバック情報を導出し得る。

図３を参照すると、メッセージ生成部１５２内にはＨＦＢＣＨ生成部１５５が存在する。ＨＦＢＣＨ生成部１５５は、ＤＬでのデータ送信に対するＨＡＲＱフィードバック情報を含むＨＡＲＱフィードバック・チャネルを生成する。ＧＲＡの観点では、ＨＦＢＣＨ生成部１５５は、ＤＬでのＧＲＡ送信に対するＨＡＲＱフィードバック・チャネルを生成し得る。

典型的なＭＳ１０６を例示するブロック図を図４に示す。ＭＳ１０６もまた、ＷｉＭＡＸ及びＷｉ−Ｆｉの両方による通信機能を装備し、ＭＳ１０４と全く同様の構成と機能性を有する。ＭＳ１０４とＭＳ１０６との主な相違点は、ＭＳ１０６とは異なり、ＭＳ１０４のＷｉ−Ｆｉ ＭＡＣブロック１４８内には図３に示したとおり、スケジューラ１５８があることであり、このスケジューラはＣｌｉＣｏのための協調動作スケジューリングのために使用される。

図１を参照すると、ＢＳ１０２は、 ＷｉＭＡＸリンク１０８ａ及び１０８ｂを介してＭＳ１０４と通信し、ＷｉＭＡＸリンク１１０ａ及び１１０ｂを介してＭＳ１０６と通信する。ＭＳ１０４は、ピアツーピアＷｉ−Ｆｉリンク１１２ａ，１１２ｂを介してＭＳ１０６と通信する。また、ＭＳ１０４は、利用可能であれば、例えば、ＷｉＭＡＸ、ブルートゥース、または６０ ＧＨｚ ｍｍＷ（ミリ波）等の他の無線技術を介してＭＳ１０６と通信してもよい。

ＣｌｉＣｏは、無線通信システム１００のＤＬ及びＵＬの両方で実現可能であることに留意されたい。一例として、無線通信システム１００におけるＵＬでのＣｌｉＣｏの動作を以下に説明する。

図１を参照すると、ＢＳ１０２とＭＳ１０４との間のＷｉＭＡＸリンク１０８ａの信号品質が悪くなると、ＭＳ１０４は、近隣探索、協調機選択／割当等のＵＬでのＣｌｉＣｏ手順を開始することができる。ＢＳ１０２とＭＳ１０６との間のＷｉＭＡＸリンク１１０ａの信号品質が良ければ、ＭＳ１０４は、ＭＳ１０６を協調機として選択できる。ＣｌｉＣｏのコンテクストでは、ＭＳ１０４は発信ＭＳと呼ばれ、ＭＳ１０６は協調ＭＳと呼ばれる。

ＣｌｉＣｏは、様々な状況において起こり得る。例えば、発信ＭＳ１０４がカフェテリア内の奥の方にあるとすると、そのため、発信ＭＳ１０４へのＷｉＭＡＸリンクの信号品質が非常に悪いことがあり得る。一方、協調ＭＳ１０６は、発信ＭＳ１０４に比べて、カフェテリアの窓または入口に非常に近いところにあるとすれば、協調ＭＳ１０６は発信ＭＳ１０４よりも非常に良いＷｉＭＡＸリンクの信号品質を有し得る。

図１に示したＣｌｉＣｏを行う無線通信システム１００に適用され得る、典型的なフレーム構成２００を例示する図を図５に示す。図５を参照すると、フレーム２０２及びフレーム２１２の各々は、８個のサブフレームからなる。そのうちの５個はＤＬサブフレームであり、その他はＵＬサブフレームである。

ＵＬでのＣｌｉＣｏに関する限り、フレーム２０２の最初のＤＬサブフレーム２０４中において、ＢＳ１０２は、ＣｌｉＣｏに関与する発信ＭＳ１０４と協調ＭＳ１０６とを含む、ＢＳ１０２に接続された複数の移動局へ制御情報を示すＭＡＰ ２２０を送信することができる。ＭＡＰ２２０は、複数のＭＡＰ ＩＥ（Information Element：情報要素）からなる。ＭＡＰ ＩＥの一部はＵＬデータ送信に対するＨＡＲＱフィードバック情報を通知することができ、ＭＡＰ ＩＥの一部はＤＬ／ＵＬデータ送信のためのリソース割当情報を通知することができる。ＨＡＲＱフィードバック情報を通知する、ＭＡＰ２２０中の１個のＭＡＰ ＩＥが、ＵＬデータ送信に対する１つのＨＢＦＣＨを形成する。

フレーム２０２の最初のＤＬサブフレーム２０４と最初のＵＬサブフレーム２０６との間の期間２０８中に、発信ＭＳ１０４と協調ＭＳ１０６は、ＨＦＢＣＨインデックス情報を含むそれぞれのリソース割当情報を得るために、ＭＡＰ２２０をそれぞれ復号する必要がある。また、発信ＭＳ１０４は、ピアツーピアＷｉ−Ｆｉリンク１１２ａを介して、ＵＬデータ・バースト２５０を協調ＭＳ１０６へ送信する必要がある。

発信ＭＳ１０４がＷｉＭＡＸ リンク１０８ｂを介してＢＳ１０２により送信されたＭＡＰ２２０の復号に成功しているならば、発信ＭＳ１０４は、その受信したリソース割当情報に従って、フレーム２０２の最初のＵＬサブフレーム２０６中においてＷｉＭＡＸリンク１０８ａを介してＵＬデータ・バースト２５０をＢＳ１０２へ送信する。他方、協調ＭＳ１０６がＷｉＭＡＸリンク１１０ｂを介してＢＳ１０２により送信されたＭＡＰ２２０の復号に成功していて、かつ、ピアツーピアＷｉ−Ｆｉリンク１１２ａを介して発信ＭＳ１０４により送信されたＵＬデータ・バースト２５０の受信に成功しているならば、協調ＭＳ１０６は、その受信したリソース割当情報に従って、ＷｉＭＡＸリンク１１０ａを介して同一のＵＬデータ・バースト２５０をＢＳ１０２へ同時に送信する。その結果、ＢＳ１０２は、受信信号の品質を向上させるために、ＷｉＭＡＸリンク１０８ａとＷｉＭＡＸリンク１１０ａとから受信したＵＬデータ・バースト２５０の２個のコピーを合成できる。

フレーム２１２の２番目のＤＬサブフレーム２１４中において、ＢＳ１０２は、ＣｌｉＣｏに関与する発信ＭＳ１０４及び協調ＭＳ１０６を含む、ＢＳ１０２に接続された複数の移動局へＭＡＰ２４０を送信することができる。上述のとおり、ＭＡＰ２４０中の一部を成すＨＦＢＣＨｓは、フレーム２０２の最初のＵＬサブフレーム２０６中において発信ＭＳ１０４及び協調ＭＳ１０６が送信したＵＬデータ・バースト２５０に対するＨＡＲＱフィードバック情報を通知することができる。

フレーム２１２の２番目のＤＬサブフレーム２１４と最初のＵＬサブフレーム２１６の間の期間２１８中に、発信ＭＳ１０４及び協調ＭＳ１０６は、期間２０８中においてＭＡＰ２２０を復号することによって得られる、それぞれのＨＦＢＣＨインデックス情報に従って、ＵＬデータ・バースト２５０に対するＨＡＲＱフィードバック情報を得るために、ＭＡＰ２４０中の対応するＨＦＢＣＨｓをそれぞれ復号する必要がある。

ＨＡＲＱフィードバック情報が、フレーム２０２の第１のＵＬサブフレーム２０６中において発信ＭＳ１０４及び協調ＭＳ１０６が送信したＵＬデータ・バースト２５０をＢＳ１０２が正常に復号していないことを示す場合、フレーム２１２の最初のＵＬサブフレーム２１６中において、発信ＭＳ１０４及び協調ＭＳ１０６は、ＵＬデータ・バースト２５０を再送する必要があり得る。

上述したとおり、将来の８０２．１６／ＷｉＭＡＸネットワークは、爆発的な移動通信データ・トラフィックをサポートしなくてはならない。さらに、将来の８０２．１６／ＷｉＭＡＸネットワークは、ＶｏＩＰ（Voice over Internet Protocol）等の移動通信インターネット・アプリケーションの実感品質（Quality of Experience）を向上させなくてはならない。ＶｏＩＰは周期的なトラフィック・パターンをもち、比較的固定したペイロード・サイズであることを考えると、例えば、ＰＡ（Persistent Allocation）及びＧＲＡといった、特にＶｏＩＰの実感の品質を向上させるために、様々なＰＨＹ／ＭＡＣメカニズムが設計された。本発明では、ＣｌｉＣｏへのＧＲＡの適用を取り上げる。

ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）で規定されたＧＲＡメカニズムは、ＣｌｉＣｏに対応していない。しかし、ＧＲＡメカニズムは、ＣｌｉＣｏに容易に対応可能である。

ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）によれば、ＧＲＡメカニズムは、制御オーバヘッドを節減するために、あるグループとしての複数のユーザにリソースを割り当てる。このリソース割当はトランスポート・フロー（Transport flow）単位である。図１を参照すると、ＧＲＡをＣｌｉＣｏに適用する方法は、二つの操作からなる。すなわち、ｉ）ＢＳ１０２は、発信ＭＳ１０４及び協調ＭＳ１０６のそれぞれのフローをあるグループに加える、または発信ＭＳ１０４及び協調ＭＳ１０６のそれぞれのフローをあるグループから削除する。ｉｉ）ＢＳ１０２は、同一グループ内の発信ＭＳ１０４及び協調ＭＳ１０６のそれぞれのフローにリソースを割り当てる。

ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）によれば、発信ＭＳ１０４（または協調ＭＳ１０６）のフローをあるグループに加えるときに、ＢＳ１０２は、ユニキャストＭＡＣ制御メッセージ中でグループ・コンフィギュレーション情報を発信ＭＳ１０４（または協調ＭＳ１０６）へ送信する。同一グループ内の発信ＭＳ１０４及び／または協調ＭＳ１０６のそれぞれのフローにリソースを割り当てる場合、ＢＳ１０２は、マルチキャストＭＡＰ ＩＥでＨＦＢＣＨインデックス情報を含むグループ・リソース割当情報を発信ＭＳ１０４及び協調ＭＳ１０６へ送信する。ユニキャストＭＡＣ制御メッセージ中で送信されるグループ・コンフィギュレーション情報とマルチキャストＭＡＰ ＩＥで送信されるグループ・リソース割当情報は、図２に示したメッセージ生成部１２６によって生成されることに留意されたい。

ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）によれば、ユニキャストＭＡＣ制御メッセージ中で送信されるグループ・コンフィギュレーション情報は、対応するマルチキャストＭＡＰ ＩＥで送信されるグループ・リソース割当情報を解釈するために使用され得る。グループ・コンフィギュレーション情報の内容は、次のものを含む。
・ フロー識別子（Flow identifier）、
・ ユーザ・ビットマップ・サイズ（User bitmap size）、
・ ＵＢＩ（User Bitmap Index，ユーザ・ビットマップ・インデックス）、
・ グループ識別子（Group identifier）、
・ 割当て周期（Allocation periodicity）、及び
・ ＭＩＭＯ（Multiple Input Multiple Output）モード・セット（MIMO mode set）、等

フロー識別子は、ＭＳのフローのうちのどのフローがグループに加えられるのかをＭＳに通知するために使用され、４ビットのサイズを有する。ユーザ・ビットマップ・サイズは、マルチキャストＭＡＰ ＩＥで送信されるユーザ・ビットマップに使用されるビット数を示す。ユーザ・ビットマップ・サイズは、４ビット、８ビット、及び３２ビットのうちの一つをとる。ＵＢＩは、ユーザ・ビットマップ中のＭＳのフローのインデックスを示し、５ビットのサイズを有する。グループ識別子は、ＭＳのフローが加えられるＤＬ／ＵＬグループを一意に識別し、１２ビットのサイズを有する。割当て周期は、対応するグループ・リソース割当情報を通知するマルチキャストＭＡＰ ＩＥが送信される頻度を指定し、周期は１フレーム、２フレーム、４フレーム及び８フレームのうちの一つであり得る。ＭＩＭＯモード・セットは、当グループ中でサポートされているＭＩＭＯモードを伝える。

発信ＭＳ１０４と協調ＭＳ１０６に向けたグループ・コンフィギュレーション情報の主な違いは、発信ＭＳ１０４と協調ＭＳ１０６のそれぞれのＵＢＩが異なることである。さらに、グループ・コンフィギュレーション情報は発信ＭＳ１０４と協調ＭＳ１０６へユニキャスト（unicast）されるので、協調ＭＳ１０６は発信ＭＳ１０４のＵＢＩを知らないし、逆の場合もそうである。

ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）によれば、グループ・コンフィギュレーション情報は、４個のＨＡＲＱバースト・サイズ（HARQ burst size）のセットをさらに含み得る。例えば、４個のＨＡＲＱバースト・サイズのセットは、｛６バイト、８バイト、９バイト、１０バイト｝であり得る。バースト・サイズは、複数のＦＥＣ（Forward Error Correction）ブロックに分割可能である、符号化されたパケットのサイズであることに留意されたい。バースト・サイズは、適用できる場合、バースト当たり及び／またはＦＥＣブロック当たりのＣＲＣ（Cyclic Redundancy Code）の追加を含み得る。

また、４個のＨＡＲＱバースト・サイズのそれぞれに対応して、グループ・コンフィギュレーション情報は、８個のリソース・サイズを含み得る。例えば、９バイトのＨＡＲＱバースト・サイズについては、８個のリソース・サイズのセットは、｛１ＬＲＵ、２ＬＲＵｓ、３ＬＲＵｓ、４ＬＲＵｓ、５ＬＲＵｓ、６ＬＲＵｓ、７ＬＲＵｓ、８ＬＲＵｓ｝となり得る。ここで、ＬＲＵは論理的リソース単位（Logical Resource Unit）を表わす。６バイト、８バイト、１０バイトの他の３個のＨＡＲＱバースト・サイズのそれぞれについては、８個のリソース・サイズのセットは、異なることもあるし、または９バイトのＨＡＲＱバースト・サイズと同じこともある。

ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）によれば、グループ・リソース割当情報の一部は、マルチキャストＭＡＰ ＩＥで送信されるビットマップによって運ばれる。ＩＥＥＥ ８０２．１６ｍ草案標準［１］による、一部のグループ・リソース割当情報を通知する典型的なビットマップを例示する図を図６に示す。一部のグループ・リソース割当情報を通知するために使用されるビットマップは二つある。一つはユーザ・ビットマップ３０２であり、もう一つはリソース割当ビットマップ３０４である。

ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）によれば、ユーザ・ビットマップ３０２は、現在のフレームにスケジュールされるのはどのフローであるかを伝えるためにフロー当たり１ビットを使用する。図６を参照すると、発信ＭＳ１０４のＵＢＩは「０００００」であるのでユーザ・ビットマップ３０２の１ビット目を参照する。協調ＭＳ１０６のＵＢＩは「０００１１」であるのでユーザ・ビットマップ３０２の４ビット目を参照する。したがって、発信ＭＳ１０４及び協調ＭＳ１０６両方のそれぞれのフロー（データに相当）はリソース割当ビットマップ３０４で指示され、現在のフレームに送信される。

図６を参照すると、リソース割当ビットマップ３０４は、複数の５ビットのリソース割当指示を含む構成を採り、各リソース割当指示は特定のスケジュールされたフローに対応する。５ビットのリソース割当指示の各々において、最初の２ビットはＨＡＲＱバースト・サイズを伝えるために使用され、最後の３ビットはリソース・サイズを伝えるために使用される。

図６を参照すると、ＨＡＲＱバースト・サイズは４個のバースト・サイズの種類｛６バイト、８バイト、９バイト、１０バイト｝から選択され、「００」, 「０１」、「１０」、「１１」によって指示される。図６では発信ＭＳ１０４及び協調ＭＳ１０６両方とも「１０」で示されるため、両方のＨＡＲＱバースト・サイズは９バイトである。発信ＭＳ１０４及び協調ＭＳ１０６のリソース・サイズは、それぞれ、「１１１」と「００１」によって示される。したがって、発信ＭＳ１０４及び協調ＭＳ１０６のリソース・サイズは、それぞれ、８ＬＲＵｓと２ＬＲＵｓであり得る。

ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）によれば、ユーザ・ビットマップ３０２及びリソース割当ビットマップ３０４に加えて、複数のＭＩＭＯモードがグループ中でサポートされる場合、ＭＩＭＯビットマップと呼ばれる他のビットマップが使用され得る。

ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）による、グループ・リソース割当情報を送信するための典型的なＧＲＡ ＭＡＰ ＩＥを例示する表を表１に示す。

さらに、ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）によれば、グループ内のスケジュールされたフローについてのＨＦＢＣＨインデックスは、そのＵＢＩ及び表１に示したＨＦＡオフセットの予め決められた関数である。換言すると、発信ＭＳ１０４及び協調ＭＳ１０６のそれぞれが、表１に示したＧＲＡ ＭＡＰ ＩＥを復号後、自機のＵＢＩにより自機のＨＦＢＣＨインデックスを算出することができる。

ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）において、発信ＭＳ１０４（または協調ＭＳ１０６）がリソース割当情報を受信する方法４００を例示するフローチャートを図７に示す。方法４００はステップ４０２で開始する。ステップ４０４において、発信ＭＳ１０４（または協調ＭＳ１０６）は、自機のＵＢＩに照らしてユーザ・ビットマップをチェックする。ステップ４０６では、発信ＭＳ１０４（または協調ＭＳ１０６）は、自機のフローが現在のフレームでスケジュールされているか否かを判定する。発信ＭＳ１０４（または協調ＭＳ１０６）のフローが現在のフレームにスケジュールされていれば、ステップ４０８において、発信ＭＳ１０４（または協調ＭＳ１０６）は、次に、自機のＨＡＲＱバースト・サイズとリソース・サイズを導出するために、自機のＵＢＩに照らしてリソース割当てビットマップをチェックする。その後、ステップ４１０で、発信ＭＳ１０４（または協調ＭＳ１０６）は、自機のＵＢＩに応じて自機のＨＦＢＣＨインデックスを算出する。ステップ４０６で、発信ＭＳ１０４（または協調ＭＳ１０６）のフローが現在のフレームにスケジュールされていなければ、方法４００はステップ４１２で終了する。

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

ＩＥＥＥ ８０２．１６ｍ草案標準（例えば非特許文献１参照）によれば、ＣｌｉＣｏに関与する発信ＭＳ１０４及び協調ＭＳ１０６の両方が同一のデータ・バーストを処理する。発信ＭＳ１０４及び協調ＭＳ１０６の両方に用いる一つのＨＦＢＣＨがあれば十分である。しかしながら、同一グループにおいてＵＢＩが異なるため、発信ＭＳ１０４及び協調ＭＳ１０６は２つの異なるＨＦＢＣＨを有する。これは、貴重なＨＦＢＣＨリソースを浪費することになる。

本発明の目的は、同一データ・バーストを処理する複数のＭＳに対して一つのＨＢＣＨを使用することで、不必要なＨＦＢＣＨリソースの浪費を避けることができる移動局及び受信方法を提供することである。

本発明の一態様によれば、複数の移動局（ＭＳｓ）と通信する基地局（ＢＳ）は、上記複数のＭＳｓの各々に対するリソース割当情報を示す制御信号を生成する制御信号生成部と上記複数のＭＳｓへ上記制御信号を送信する送信部を含む構成をとり、ある移動局（ＭＳ）に対する制御信号は、他のＭＳに関する情報を含む。

本発明の一態様によれば、ＢＳは、発信ＭＳと、ＢＳと上記発信ＭＳとの間の通信のために利用される協調ＭＳを含む複数のＭＳｓと通信し、上記複数のＭＳｓの各々に対するリソース割当情報を示す制御信号を生成する制御信号生成部と、上記複数のＭＳｓへ上記制御信号を送信する送信部を具備し、上記協調ＭＳに対する制御信号は、上記発信ＭＳに関する情報を含む。

本発明の一態様によれば、上記協調ＭＳのフローが上記発信ＭＳと同じグループに加えられる場合、上記協調ＭＳに対する制御信号は、上記発信ＭＳに関する情報を含む。

本発明の一態様によれば、上記発信ＭＳに関する情報は、上記協調ＭＳに対するリソース割当情報の中に含まれる。

本発明の一態様によれば、上記発信ＭＳに関する情報は、上記協調ＭＳに対するバースト・サイズ情報と入れ換えられる。

本発明の一態様によれば、上記発信ＭＳに関する情報のビット数は、上記発信ＭＳと同じグループに属するＭＳｓの数に応じて変わる。

本発明の一態様によれば、上記発信ＭＳと同じグループに属するＭＳｓの数に応じて、上記協調ＭＳに対するバースト・サイズ情報のビット数が増加するのに伴い、かつ、上記協調ＭＳに対するリソース・サイズ情報のビット数が減少するのに伴い、上記発信ＭＳに関する情報のビット数は変わる。

本発明の一態様によれば、上記協調ＭＳに対するリソース・サイズ情報のビット数が減少する場合、上記協調ＭＳの実際のリソース・サイズは、上記発信ＭＳのリソース・サイズと上記協調ＭＳの公称リソース・サイズのビット単位の演算結果として得られる。

本発明の一態様によれば、上記協調ＭＳのリソース・サイズは、上記発信ＭＳのリソース・サイズと同じであり、上記発信ＭＳに関する情報は、上記協調ＭＳに対するバースト・サイズ情報及びリソース・サイズ情報と入れ換えられる。

本発明の一態様によれば、上記協調ＭＳの実際のリソース・サイズは、上記発信ＭＳのリソース・サイズと上記協調ＭＳの公称リソース・サイズのビット単位の演算結果として得られる。

本発明の一態様によれば、上記協調ＭＳのリソース・サイズは予め決められた値に設定され、上記発信ＭＳに関する情報は、上記協調ＭＳに対するバースト・サイズ情報及びリソース・サイズ情報と入れ換えられる。

本発明の一態様によれば、上記発信ＭＳに関する情報は、上記発信ＭＳの識別情報である。

本発明の一態様によれば、上記発信ＭＳに関する情報は、上記協調ＭＳの識別情報に相対する、上記発信ＭＳの識別情報のオフセットである。

本発明の一態様によれば、ＭＳは、他のＭＳに関する情報を含む、自機に対する制御信号を受信する受信部と、上記制御信号、及び、上記他のＭＳに関する情報に応じて、送信リソースを算出するリソース算出部を具備する。

本発明の一態様によれば、ＢＳと発信ＭＳとの間の通信のために利用される協調ＭＳは、上記発信ＭＳに関する情報を含む自協調ＭＳに対する制御信号を受信する受信部、上記制御信号、及び、上記発信ＭＳに関する情報に応じて、送信リソースを算出するリソース算出部、及び上記発信ＭＳから受信した信号を、上記送信リソースを介して上記ＢＳへ送信する送信部を具備する。

本発明の一態様によれば、上記発信ＭＳに関する情報が上記協調ＭＳの識別情報を示す場合は、上記送信部は、上記ＢＳへの上記信号の送信を停止する。

本発明の一態様によれば、上記発信ＭＳに関する情報が上記協調ＭＳの識別情報を示す場合は、上記送信部は、予め決められた期間または設定可能な期間の間、上記ＢＳへの上記信号の送信を停止する。

本発明の一態様によれば、上記発信ＭＳに関する情報の一部分は、上記協調ＭＳに対するリソース割当情報の中に含まれ、上記発信ＭＳに関する情報のその他の部分は、上記協調ＭＳへ送信されるグループ・コンフィギュレーション情報の中に含まれる。

本発明の一実施形態によれば、複数のＭＳｓと通信するＢＳにおいて実行される送信方法は、上記複数のＭＳｓの各々に対するリソース割当情報を示す制御信号を生成し、上記複数のＭＳｓへ上記制御信号を送信し、あるＭＳに対する制御信号は、他のＭＳに関する情報を含む。

本発明の一実施形態によれば、発信ＭＳと、ＢＳと上記発信ＭＳとの間の通信のために利用される協調ＭＳを含む複数のＭＳｓと通信する基地局（ＢＳ）において実行される送信方法は、上記複数のＭＳｓの各々に対するリソース割当情報を示す制御信号を生成し、上記複数のＭＳｓへ上記制御信号を送信し、上記協調ＭＳに対する制御信号は、上記発信ＭＳに関する情報を含む。

本発明の一実施形態によれば、ＭＳにおいて実行される受信方法は、他のＭＳに関する情報を含む自機に対する制御信号を受信し、上記制御信号及び上記他のＭＳに関する情報に応じて送信リソースを算出する。

本発明の一実施形態によれば、ＢＳと発信ＭＳとの間の通信のために利用される協調ＭＳにおいて実行される受信方法は、上記発信ＭＳに関する情報を含む自機に対する制御信号を受信し、上記制御信号及び上記発信ＭＳに関する情報に応じて、送信リソースを算出し、上記発信ＭＳから受信した信号を、上記送信リソースを介して上記ＢＳへ送信する。

本発明の上記及びその他の特徴と利点は、添付の図面とともに本発明の以下の詳細な説明を参照し、添付の特許請求の範囲を参照することで、よりよく理解されることになろう。

本発明は同一データ・バーストを処理する複数のＭＳｓに対して一つのＨＢＣＨを使用するので、不必要なＨＦＢＣＨリソースの浪費を避けることができる。

ＣｌｉＣｏ（クライアント協調動作）を行う無線通信システムの一例を示す図 ＢＳ（基地局）の一例を示すブロック図 発信ＭＳ（移動局）の一例を示すブロック図 協調ＭＳ（移動局）の一例を示すブロック図 フレーム構成の一例を示す図 従来技術による、一部のグループ・リソース割当情報を通知するビットマップの一例を示す図 従来技術による、発信ＭＳ（または協調するＭＳ）でグループ・リソース割当情報を受信する方法を例示するフローチャート 本発明の実施の形態１に係る協調するＭＳでグループ・リソース割当情報を受信する方法を例示するフローチャート 本発明の実施の形態２に係る４ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためビットマップの一例を示す図 本発明の実施の形態２に係る４ビットのユーザ・ビットマップの場合における、協調するＭＳでグループ・リソース割当情報を受信する方法を例示するフローチャート 本発明の実施の形態２に係る８ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためビットマップの一例を示す図 本発明の実施の形態２に係る８ビットのユーザ・ビットマップの場合における、協調するＭＳでグループ・リソース割当情報を受信する方法を例示するフローチャート 本発明の実施の形態２に係る３２ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を示す図 本発明の実施の形態２に係る３２ビットのユーザ・ビットマップの場合における、協調するＭＳでグループ・リソース割当情報を受信する方法を例示するフローチャート 本発明の実施の形態３に係る４ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を示す図 本発明の実施の形態４に係る８ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を示す図 本発明の実施の形態５に係る８ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を示す図

以下、本発明の実施の形態について、添付図面を参照して詳細に説明する。本願明細書に援用する周知の機能及び構成の詳細な説明は、明確かつ簡潔にするために省略した。

（実施の形態１）
本発明の実施の形態１によれば、図１に準拠して、ＧＲＡをＣｌｉＣｏに適用する方法の基本概念は、ＢＳ１０２が、グループ・コンフィギュレーション情報を用いて、発信ＭＳ１０４のＵＢＩを協調ＭＳ１０６に共有させることである。より詳細には、ＢＳ１０２が協調ＭＳ１０６のフローをグループに加えるとき、ＢＳ１０２によって協調ＭＳ１０６へユニキャストされるグループ・コンフィギュレーション情報は、発信ＭＳ１０４のＵＢＩをも含む。ＢＳ１０２によって協調ＭＳ１０６へユニキャストされるグループ・コンフィギュレーション情報の内容は、以下に挙げることができる。
・ 協調ＭＳ１０６のフロー識別子、
・ ユーザ・ビットマップ・サイズ、
・ 発信ＭＳ１０４のＵＢＩ、
・ 協調ＭＳ１０６のＵＢＩ、
・ グループ識別子、
・ 割当て周期、及び
・ ＭＩＭＯモード・セット、等

本発明の実施の形態１によれば、協調ＭＳ１０６は発信ＭＳ１０４のＵＢＩを知るので、協調ＭＳ１０６は、自機のＨＦＢＣＨインデックスを導出するために、自機自身のＵＢＩの代わりに発信ＭＳ１０４のＵＢＩを使用することができる。その結果、同一のＨＦＢＣＨのみが、ＣｌｉＣｏに関与する発信ＭＳ１０４及び協調ＭＳ１０６の両方に割り当てられる。したがって、不必要なＨＦＢＣＨリソースの浪費が避けられる。

本発明の実施の形態１による、協調ＭＳ１０６でリソース・スケジューリング情報を受信するための方法５００を例示するフローチャートを図８に示す。方法５００はステップ５０２で開始する。ステップ５０４において、協調ＭＳ１０６は、自機のＵＢＩに照らしてユーザ・ビットマップをチェックする。ステップ５０６では、協調ＭＳ１０６は、自機のフローが現在のフレームにスケジュールされているか否かを判定する。協調ＭＳ１０６のフローが現在のフレームにスケジュールされていれば、ステップ５０８において、協調ＭＳ１０６は、自機のＨＡＲＱバースト・サイズ及びリソース・サイズを導出するために、自機のＵＢＩに照らしてリソース割当ビットマップをチェックする。ステップ５１０では、協調ＭＳ１０６は、発信ＭＳ１０４のＵＢＩに応じて自機のＨＦＢＣＨインデックスを算出する。ステップ５０６で、協調ＭＳ１０６のフローが現在のフレームにスケジュールされていなければ、方法５００はステップ５１２で終了する。

本発明の実施の形態１によれば、ＢＳ１０２によって発信ＭＳ１０４へユニキャストされるグループ・コンフィギュレーション情報の内容と、ＢＳ１０２によって発信ＭＳ１０４及び協調ＭＳ１０６へマルチキャストされるグループ・リソース割当情報の内容とは、ＩＥＥＥ ８０２．１６ｍ草案標準（例えば、非特許文献１参照）と同じである。しかしながら、ＢＳ１０２によって協調ＭＳ１０４へユニキャストされるグループ・コンフィギュレーション情報の内容は、ＩＥＥＥ ８０２．１６ｍ草案標準（例えば、非特許文献１参照）とは異なる。

本発明の実施の形態１によると、代替的な手法は、グループ・コンフィギュレーション情報が、ＢＳ１０２によって発信ＭＳ１０４と協調ＭＳ１０６の両方へマルチキャストされることである。ＢＳ１０２によって発信ＭＳ１０４及び協調ＭＳ１０６の両方へマルチキャストされるグループ・コンフィギュレーション情報の内容は、以下に挙げることができる。
・ 発信ＭＳ１０４のフロー識別子、
・ 協調ＭＳ１０６のフロー識別子、
・ ユーザ・ビットマップ・サイズ、
・ 発信ＭＳ１０４のＵＢＩ、
・ 協調ＭＳ１０６のＵＢＩ、
・ グループ識別子、
・ 割当て周期、及び
・ ＭＩＭＯモード・セット、等

本発明の実施の形態１によれば、グループ・コンフィギュレーション情報は、ＭＡＣ制御メッセージまたはＭＡＰ ＩＥのいずれかで送信され得る。

（実施の形態２）
本発明の実施の形態１によれば、発信ＭＳ１０４のＵＢＩを協調ＭＳ１０６に共有させることによって、グループ・リソース割当を開始する前の段階でグループ・コンフィギュレーション情報に追加の制御オーバヘッドが導入される可能性があるという欠点がある。

図１に準拠して、前述したとおり、ＣｌｉＣｏに関与する発信ＭＳ１０４及び協調ＭＳ１０６は同一のデータ・バーストを処理するため、同一のＨＡＲＱバースト・サイズを有することになる。したがって、発信ＭＳ１０４及び協調ＭＳ１０６のいずれか一方に対するＨＡＲＱバースト・サイズ指示は不必要である。さらに、実際に必要とされるＵＢＩの長さは、ユーザ・ビットマップ・サイズに依存する。例えば、ユーザ・ビットマップ・サイズが８ビットである場合、５ビットのＵＢＩではなく３ビットのＵＢＩのみが実際に必要とされる。

本発明の実施の形態２によれば、ＧＲＡをＣｌｉＣｏに適用する方法の基本概念は、ＢＳ１０２が、本発明の実施の形態１におけるグループ・コンフィギュレーション情報の代わりに、グループ・リソース割当情報を用いて、発信ＭＳ１０４のＵＢＩを協調ＭＳ１０６に共有させることである。より詳細には、ＢＳ１０２が発信ＭＳ１０４及び協調ＭＳ１０６にリソースを割り当てる場合、リソース割当ビットマップ中の協調ＭＳ１０６用の５ビットのリソース割当指示の可変部分が、発信ＭＳ１０４のＵＢＩを指示するために使用される。上記可変部分の長さはユーザ・ビットマップ・サイズに依存する。協調ＭＳ１０６用の上記５ビットのリソース割当指示の残りの部分は、協調ＭＳのリソース・サイズを指示するために使用される。ただし、協調ＭＳ１０６のリソース・サイズを指示するための方法は、ユーザ・ビットマップ・サイズに応じて異なる。

本発明の実施の形態２によれば、発信ＭＳ１０４のＵＢＩはリソース割当てビットマップに組み込まれているので、グループ・コンフィギュレーション情報に追加の制御オーバヘッドが導入されることはない。

本発明の実施の形態２による、４ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するビットマップの一例を図９に示す。図９を参照すると、リソース割当ビットマップ６０４の中で、協調ＭＳ１０６用の５ビットのリソース割当指示の最初の２ビット（例えば、「００」）が、協調ＭＳ１０６のＨＡＲＱバースト・サイズではなく、発信ＭＳ１０４のＵＢＩを指示するために使用され、最後の３ビット（例えば、「０１０」）が、協調ＭＳ１０６用のリソース・サイズを伝えるために使用される。なお、発信ＭＳ１０４用の５ビットのリソース割当指示の最初の２ビット（例えば、「１０」）は、発信ＭＳ１０４及び協調ＭＳ１０６の両方のＨＡＲＱバースト・サイズを伝えるために使用されることに留意されたい。

本発明の実施の形態２による、４ビットのユーザ・ビットマップの場合における、協調ＭＳ１０６でグループ・リソース割当情報を受信するための方法７００を例示するフローチャートを図１０に示す。方法７００はステップ７０２で開始する。ステップ７０４において、協調ＭＳ１０６は、自機のＵＢＩに照らしてユーザ・ビットマップをチェックする。ステップ７０６では、協調ＭＳ１０６は、自機のフローが現在のフレームにスケジュールされているか否かを判定する。協調ＭＳ１０６のフローが現在のフレームにスケジュールされていれば、ステップ７０８において、協調ＭＳ１０６は、発信ＭＳ１０４のＵＢＩと自機のリソース・サイズを導出するために、自機のＵＢＩに照らしてリソース割当ビットマップをチェックする。ステップ７１０では、協調ＭＳ１０６は、自機のＨＡＲＱバースト・サイズを導出するために、発信ＭＳ１０４のＵＢＩに照らしてリソース割当てビットマップを再びチェックする。ステップ７１２で、協調ＭＳ１０６は、発信ＭＳ１０４のＵＢＩに応じて自機のＨＦＢＣＨインデックスを算出する。ステップ７０６において、協調ＭＳ１０６のフローが現在のフレームにスケジュールされていなければ、方法７００はステップ７１４で終了する。

本発明の実施の形態２による、８ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図１１に示す。図１１を参照すると、リソース割当ビットマップ８０４の中で、協調ＭＳ１０６用の５ビットのリソース割当指示の最初の３ビットが、発信ＭＳ１０４のＵＢＩを指示するために使用され、最後の２ビットが、協調ＭＳ１０６の実際のリソース・サイズではなく、協調ＭＳ１０６の公称リソース・サイズを指示するために使用される。

協調ＭＳの公称リソース指示から協調ＭＳ１０６の実際のリソース・サイズ指示を算出する手法はいろいろある。一つの手法では、協調ＭＳ１０６の実際のリソース・サイズ指示は、発信ＭＳ１０４のリソース・サイズ指示と協調ＭＳ１０６の公称リソース・サイズ指示とのビット単位の排他論理和演算の結果として得ることができる。図１１を参照すると、発信ＭＳ１０４のリソース・サイズ指示が「１１１」であり、協調ＭＳ１０６の公称リソース・サイズ指示が「０１」である。したがって、協調ＭＳ１０６の実際のリソース・サイズ指示は、「１１１ ＸＯＲ ０１ ＝ １１０」となる。別の手法では、協調ＭＳ１０６の実際のリソース・サイズ指示は、発信ＭＳ１０４のリソース・サイズ指示と協調ＭＳ１０６の公称リソース・サイズ指示とのビット単位の論理和または論理積の結果として得ることができる。

本発明の実施の形態２による、８ビットのユーザ・ビットマップの場合における、協調ＭＳ１０６でグループ・リソース割当情報を受信するための方法９００を例示するフローチャートを図１２に示す。方法９００はステップ９０２で開始する。ステップ９０４において、協調ＭＳ１０６は、自機のＵＢＩに照らしてユーザ・ビットマップをチェックする。ステップ９０６で、協調ＭＳ１０６は、自機のフローが現在のフレームにスケジュールされているか否かを判定する。協調ＭＳ１０６のフローが現在のフレームにスケジュールされていれば、ステップ９０８において、協調ＭＳ１０６は、発信ＭＳ１０４のＵＢＩを導出するために、リソース割当てビットマップをチェックする。ステップ９１０では、協調ＭＳ１０６は、自機のＨＡＲＱバースト・サイズとリソース・サイズを導出するために、自機のＵＢＩと発信ＭＳ１０４のＵＢＩに照らしてリソース割当ビットマップを再びチェックする。ステップ９１２で、協調ＭＳ１０６は、発信ＭＳ１０４のＵＢＩにより自機のＨＦＢＣＨインデックスを算出する。ステップ９０６において、協調ＭＳ１０６のフローが現在のフレームにスケジュールされていなければ、方法９００はステップ９１４で終了する。

本発明の実施の形態２によれば、８ビットのユーザ・ビットマップの場合と同様に、１６ビットのユーザ・ビットマップの場合には、リソース割当ビットマップ中で、協調ＭＳ１０６用の５ビットのリソース割当指示の最初の４ビットが、発信ＭＳ１０４のＵＢＩを指示するために使用され、最後の１ビットが、協調ＭＳ１０６の実際のリソース・サイズではなく、協調ＭＳ１０６の公称リソース・サイズを指示するために使用される。

本発明の実施の形態２による、３２ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図１３に示す。図１３を参照すると、リソース割当てビットマップ１００４の中で、協調ＭＳ１０６用の５ビットのリソース割当指示の全部が、発信ＭＳ１０４のＵＢＩを指示するために使用される。協調ＭＳ１０６のリソース・サイズは、発信ＭＳ１０４用の３ビットのリソース・サイズ指示によって伝えられる。つまり、３２ビットのユーザ・ビットマップの場合には、発信ＭＳ１０４と協調ＭＳ１０６は常に同じリソース・サイズを有する。

本発明の実施の形態２による、グループ・リソース割当情報を送信するためのＧＲＡ ＭＡＰ ＩＥの一例を表２に示す。

本発明の実施の形態２による、３２ビットのユーザ・ビットマップの場合における、協調ＭＳ１０６でグループ・リソース割当情報を受信するための方法１１００を例示するフローチャートを図１４に示す。方法１１００はステップ１１０２で開始する。ステップ１１０４において、協調ＭＳ１０６は、自機のＵＢＩに照らしてユーザ・ビットマップをチェックする。ステップ１１０６で、協調ＭＳ１０６は、自機のフローが現在のフレームにスケジュールされているか否かを判定する。協調ＭＳ１０６のフローが現在のフレームにスケジュールされていれば、ステップ１１０８において、協調ＭＳ１０６は、発信ＭＳ１０４のＵＢＩを導出するために、リソース割当てビットマップをチェックする。ステップ１１１０では、協調ＭＳ１０６は、自機のＨＡＲＱバースト・サイズとリソース・サイズを導出するために、発信ＭＳ１０４のＵＢＩに照らしてリソース割当ビットマップを再びチェックする。ステップ１１１２で、協調ＭＳ１０６は、発信ＭＳ１０４のＵＢＩに応じて、自機のＨＦＢＣＨインデックスを算出する。ステップ１１０６において、協調ＭＳ１０６のフローが現在のフレームにスケジュールされていなければ、方法１１００はステップ１１１４で終了する。

協調ＭＳ１０６の視点からは、方法７００、９００及び１１００の間の違いは、自機のリソース・サイズを導出する方法にある。方法７００では、協調ＭＳ１０６のリソース・サイズは、自機自身のＵＢＩに照らして導出される。方法９００では、協調ＭＳ１０６のリソース・サイズは、自機自身のＵＢＩと発信ＭＳ１０４のＵＢＩとに照らして導出される。方法１１００では、協調ＭＳ１０６のリソース・サイズは、発信ＭＳ１０４のＵＢＩのみに照らして導出される。

本発明の実施の形態２によれば、８ビットのユーザ・ビットマップの場合の代替的な手法は、リソース割当ビットマップの中で、協調ＭＳ１０６用の５ビットのリソース割当指示の最初の３ビットは、発信ＭＳ１０４のＵＢＩを指示するために使用されるが、最後の２ビットは、協調ＭＳ１０６の公称リソース・サイズではなく、協調ＭＳ１０６の実際のリソース・サイズを伝えるために使用される。同様に、１６ビットのユーザ・ビットマップの場合の代替的な手法は、リソース割当ビットマップの中で、協調ＭＳ１０６用の５ビットのリソース割当指示の最初の４ビットは、発信ＭＳ１０４のＵＢＩを指示するために使用されるが、最後の１ビットは、協調ＭＳ１０６の実際のリソース・サイズを指示するために使用される。

本発明の実施の形態２によれば、４ビットのユーザ・ビットマップの場合の代替的な手法は、リソース割当ビットマップの中で、協調ＭＳ１０６用の５ビットのリソース割当指示の最初の２ビットは、発信ＭＳ１０４のＵＢＩを指示するために使用されるが、最後の３ビットは、協調ＭＳ１０６の実際のリソース・サイズではなく、協調ＭＳ１０６の公称リソース・サイズを指示するために使用される。協調ＭＳ１０６の実際のリソース・サイズは、発信ＭＳ１０４のリソース・サイズ指示と協調ＭＳ１０６の公称リソース・サイズ指示から上述した方式で導出することができる。

本発明の実施の形態２によれば、３２ビットのユーザ・ビットマップの場合の代替的な手法は、リソース割当ビットマップの中の協調ＭＳ１０６の５ビットのリソース割当指示の全部が、発信ＭＳ１０４のＵＢＩを伝えるために使用されるが、協調ＭＳ１０６のリソース・サイズは常に予め決められた値に設定される。

本発明の実施の形態２によれば、ＢＳ１０２によって発信ＭＳ１０４または協調ＭＳ１０６へユニキャストされるグループ・コンフィギュレーション情報の内容は、ＩＥＥＥ ８０２．１６ｍ草案標準（例えば、非特許文献１参照）と同じである。しかしながら、ＢＳ１０２によって発信ＭＳ１０４または協調ＭＳ１０６へマルチキャストされるグループ・リソース割当情報の内容は、ＩＥＥＥ ８０２．１６ｍ草案標準（例えば、非特許文献１参照）とは異なる。

本発明の実施の形態２によれば、グループ・リソース割当情報は、マルチキャストＭＡＣ制御情報またはマルチキャストＭＡＰ ＩＥのいずれかで送信され得る。

（実施の形態３）
本発明の第１及び実施の形態２によれば、リソース割当ビットマップの中の発信ＭＳ１０４のＵＢＩ指示は、協調ＭＳ１０６のＵＢＩとは異なると仮定されている。以下では、リソース割当ビットマップの中の発信ＭＳ１０４のＵＢＩ指示が協調ＭＳ１０６のＵＢＩと同じである場合を取り上げる。

本発明の実施の形態３による、４ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図１５に示す。図１５を参照すると、リソース割当ビットマップ１２０４の中で、協調ＭＳ１０６用の５ビットのリソース割当指示の最初の２ビットが、発信ＭＳ１０４のＵＢＩを指示するために使用される。発信ＭＳ１０４のＵＢＩ指示（例えば、「１０」）が協調ＭＳ１０６のＵＢＩと同じである場合には、様々な暗示を生じさせ得る。例えば、通信相手のＭＳ１０６は、その後のＮ個の連続割当期間にＵＬ／ＤＬデータ・バーストを送信／受信しないことを暗示し得る。ここでＮは予め決められている。または、Ｎの値は協調ＭＳ１０６用の５ビットのリソース割当指示の最後の３ビットによって指示される。あるいは、協調ＭＳ１０６が今後はＵＬ／ＤＬデータ・バーストを送信／受信しないことを暗示し得る。

本発明の実施の形態３によれば、８ビット、１６ビット、または３２ビットのユーザ・ビットマップの場合において、リソース割当ビットマップ中の発信ＭＳ１０４のＵＢＩ指示が協調ＭＳ１０６のＵＢＩと同じである場合、４ビットのユーザ・ビットマップの場合と同様の暗示を生じさせ得る。

（実施の形態４）
本発明の実施の形態１，２，３によれば、発信ＭＳ１０４のＵＢＩ指示値の長さは、ユーザ・ビットマップのサイズに依存している。その結果、４ビットのユーザ・ビットマップの場合には、協調ＭＳ１０６のリソース・サイズを伝えるために３ビットが使用可能である。したがって、協調ＭＳ１０６へリソースを割り当てるために８個のリソース・サイズのセットの全部が使用可能となる。しかし、８ビット、１６ビット、または３２ビットのユーザ・ビットマップの場合には、協調ＭＳ１０６へリソースを割り当てるために８個のリソース・サイズのセットの一部しか使用できない。これは、ＢＳ１０２のスケジューリングの柔軟性を低下させる。

本発明の実施の形態４による、８ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図１６に示す。図１６を参照すると、リソース割当ビットマップ１３０４の中で、協調ＭＳ１０６用の５ビットのリソース割当指示の最初の２ビットだけが、協調ＭＳ１０６のＵＢＩに相対する発信ＭＳ１０４のＵＢＩのオフセットを指示するために使用され、最後の３ビットが、協調ＭＳ１０６のリソース・サイズを指示するために使用される。

本発明の実施の形態４による、グループ・リソース割当情報を送信するためのＧＲＡ ＭＡＰ ＩＥの一例を表３に示す。

本発明の実施の形態４によれば、８ビット、１６ビット、または３２ビットのユーザ・ビットマップの場合に、発信ＭＳ１０６のＵＢＩ指示のために２ビットだけが使用されるので、ＢＳ１０２が発信ＭＳ１０４と協調ＭＳ１０６のそれぞれのフローをグループに加える際に、いろいろな制約が課せられる必要がある。発信ＭＳ１０４と協調ＭＳ１０６のそれぞれのフローをグループに加える際に、ＢＳ１０２は、例えば、下記の制約を受けることがあり得る。
・ 発信ＭＳ１０４のＵＢＩは協調ＭＳ１０６のＵＢＩよりも小さい、及び
・ 発信ＭＳ１０４のＵＢＩと協調ＭＳ１０６のＵＢＩとの差が４よりも大きい

本発明の実施の形態４によれば、協調ＭＳ１０６のリソース・サイズを指示するために３ビットが使用されるので、８ビット、１６ビット、または３２ビットのユーザ・ビットマップの場合にも、協調ＭＳ１０６のリソースを割り当てるために、８個のリソース・サイズのセットの全部を使用できる。

（実施の形態５）
本発明の実施の形態４によれば、ＢＳ１０２が発信ＭＳ１０４と協調ＭＳ１０６のそれぞれのフローをグループに加えるときに、いくつかの制約が課せられる必要がある。これは、ＢＳ１０２のグループ・コンフィギュレーションの柔軟性を低下させる可能性がある。

本発明の実施の形態５による、８ビットのユーザ・ビットマップの場合における、一部のグループ・リソース割当情報を通知するためのビットマップの一例を図１７に示す。図１７を参照すると、リソース割当ビットマップ１４０４の中で、協調ＭＳ１０６用の５ビットのリソース割当指示の最初の２ビットが、発信ＭＳ１０４のＵＢＩの第１の部分を指示するために使用され、最後の３ビットが、協調ＭＳ１０６のリソース・サイズを指示するために使用される。

本発明の実施の形態５による、グループ・リソース割当情報を送信するためのＧＲＡ ＭＡＰ ＩＥの一例を表４に示す。

本発明の実施の形態５によれば、ＢＳ１０２によって協調ＭＳ１０６へユニキャストされるグループ・コンフィギュレーション情報は、発信ＭＳ１０４のＵＢＩの第２の部分を含む。ＢＳ１０２によって協調ＭＳ１０６へユニキャストされるグループ・コンフィギュレーション情報の内容は、以下に挙げることができる。
・ 協調ＭＳ１０６のフロー識別子、
・ ユーザ・ビットマップ・サイズ、
・ 発信ＭＳ１０４のＵＢＩの第２の部分、
・ 協調ＭＳ１０６のＵＢＩ、
・ グループＩＤ、
・ 割当て周期、及び
・ ＭＩＭＯモード・セット、等

本発明の実施の形態５によれば、８ビットのユーザ・ビットマップの場合に、グループ・コンフィギュレーション情報及びグループ・リソース割当情報で通知される３ビットが、発信ＭＳ１０６のＵＢＩ指示のために使用され、ＢＳ１０２が発信ＭＳ１０４と協調ＭＳ１０６のそれぞれのフローをグループに加えるときに何の制約も課されない。

本発明の実施の形態５によれば、発信ＭＳ１０４のＵＢＩの第１の部分は、発信ＭＳ１０４のＵＢＩのＬＳＢ（最下位ビット）側の２ビットであり得る。発信ＭＳ１０４のＵＢＩの第２の部分は、８ビット、１６ビット及び３２ビットのユーザ・ビットマップの場合にそれぞれ対応して、発信ＭＳ１０４のＵＢＩのＭＳＢ（最上位ビット）の１ビット、ＭＳＢ側の２ビット及びＭＳＢ側の３ビットであり得る。

本発明の実施の形態５によれば、代替的に、発信ＭＳ１０４のＵＢＩの第１の部分は、発信ＭＳ１０４のＵＢＩのＭＳＢ側の２ビットであり得る。発信ＭＳ１０４のＵＢＩの第２の部分は、８ビット、１６ビット及び３２ビットのユーザ・ビットマップの場合にそれぞれ対応して、発信ＭＳ１０４のＵＢＩのＬＳＢの１ビット、ＬＳＢ側の２ビット及びＬＳＢ側の３ビットであり得る。本発明の上述した個々の実施形態によれば、協調ＭＳ１０６が自機のＨＦＢＣＨを算出するために発信ＭＳ１０４のＵＢＩを使用できるように、ＢＳ１０２は発信ＭＳ１０４のＵＢＩを 協調ＭＳ１０６に共有させる。ＢＳ１０２が協調ＭＳ１０６のＵＢＩを発信ＭＳ１０４に共有させるような、本発明の多様な変形及び／または修正が行なえることは当業者には当然理解されるであろう。

本発明の上述した個々の実施形態によれば、発信ＭＳ１０４に加えて、１台の協調ＭＳ１０６だけがＣｌｉＣｏにかかわり合う。２台以上の協調ＭＳがＣｌｉＣｏにかかわり合い、そしてＢＳ１０２は、ＣｌｉＣｏに関与する発信ＭＳと複数の協調ＭＳのうちの一つのＵＢＩをその他のＭＳに共有させるような、本発明の多様な変形及び／または修正が行なえることは当業者には当然理解されるであろう。

具体的な個々の実施形態として示した本発明のその他の多様な変形及び／または修正は、広義に記述された本発明の精神または範囲を逸脱しない限りにおいて行なえることは当業者には当然理解されるであろう。本文書に述べた個々の実施形態は、したがって、あらゆる点において例示であり、制限的ではないと見なされるべきある。

なお、上記実施の形態では、本発明をハードウェアで構成する場合を例にとって説明したが、本発明はハードウェアとの連携においてソフトウェアでも実現することも可能である。

また、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部または全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。

また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。

さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。

２０１０年４月２０日出願の特願２０１０−０９７０２６の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。

本発明は、移動体通信システム等に適用することができる。

Claims (16)

1. 基地局と他の移動局との間の通信を中継する移動局であって、
   前記基地局から自局宛の制御情報を受信する受信部を具備し、
   前記受信部は、前記他の移動局と同じグループに加わる際に、前記自局宛の制御情報の一部に、前記他の移動局の制御情報を含む制御情報を受信する、
   移動局。
2. 前記制御情報はリソース割当情報であって、
   自局宛のリソース割当情報、および、前記他の移動局のリソース割当情報に応じて、送信リソースを算出するリソース算出部をさらに具備する、
   請求項１に記載の移動局。
3. 前記制御情報は、リソース割当情報を通知するためのユーザ・ビットマップ情報を含み、
   自局用のユーザ・ビットマップの一部は前記他の移動局のリソース割当指示に使用される、
   請求項１に記載の移動局。
4. 前記他の移動局に関する制御情報は、自局に対するバースト・サイズ情報と入れ換えられる、
   請求項１に記載の移動局。
5. 前記他の移動局に関する制御情報のビット数は、前記他の移動局と同じグループに属する移動局数に応じて変わる、
   請求項１に記載の移動局。
6. 前記制御情報において、前記他の移動局と同じグループに属する移動局数に応じて、自局に対するバースト・サイズ情報のビット数が増加するのに伴い、かつ、自局に対するリソース・サイズ情報のビット数が減少するのに伴い、前記他の移動局に関する制御情報のビット数は変わる、
   請求項５に記載の移動局。
7. 前記制御情報において、自局に対するリソース・サイズ情報のビット数が減少する場合、自局の実際のリソース・サイズは、前記他の移動局のリソース・サイズと自局の公称リソース・サイズのビット単位の演算結果として得られる、
   請求項２に記載の移動局。
8. 前記制御情報において、自局のリソース・サイズは、前記他の移動局のリソース・サイズと同じであり、前記他の移動局に関する制御情報は、自局に対するバースト・サイズ情報及びリソース・サイズ情報と入れ換えられる、
   請求項２に記載の移動局。
9. 前記制御情報において、自局の実際のリソース・サイズは、前記他の移動局のリソース・サイズと自局の公称リソース・サイズのビット単位の演算結果として得られる、
   請求項２に記載の移動局。
10. 前記制御情報において、自局のリソース・サイズは予め決められた値に設定され、前記他の移動局に関する制御情報は、自局に対するバースト・サイズ情報及びリソース・サイズ情報と入れ換えられる、
    請求項２に記載の移動局。
11. 前記他の移動局に関する制御情報は、前記他の移動局の識別情報を含む、
    請求項１に記載の移動局。
12. 前記他の移動局に関する制御情報は、自局の識別情報に相対する、前記他の移動局の識別情報のオフセットを含む、
    請求項１に記載の移動局。
13. 前記他の移動局に関する制御情報の一部分は、自局に対するリソース割当情報の中に含まれ、前記他の移動局に関する制御情報のその他の部分は、自局へ送信されるグループ・コンフィギュレーション情報の中に含まれる、
    請求項１に記載の移動局。
14. 前記他の移動局から受信した信号を、前記リソース算出部で算出された送信リソースを介して前記基地局へ送信する送信部をさらに具備する、
    請求項２に記載の移動局。
15. 基地局と他の移動局との間の通信を中継する移動局における受信方法であって、
    前記他の移動局と同じグループに加わる際に、前記基地局から自局宛の制御情報を受信し、
    前記自局宛の制御情報は、その一部に前記他の移動局の制御情報を含む、
    受信方法。
16. 前記自局宛の制御情報、および、前記他の移動局の制御情報に応じて、
    送信リソースを算出する、
    請求項１５に記載の受信方法。

Images