本発明は、通信技術の分野に関し、より具体的には、リソーススケジューリング方法、装置、およびデバイスに関する。
直交周波数分割多元接続(OFDMA、Orthogonal Frequency Division Multiple Access)伝送技術およびマルチユーザ多入力多出力(MU-MIMO、Multiple User-MIMO)伝送技術などの技術の発展に伴い、現在では、通信システムは、マルチユーザ伝送を既にサポートすることが可能となっている、すなわち、データを同時に送信および受信する際に複数のステーションをサポートすることが可能になっている。
しかしながら、前述のマルチユーザ伝送(例えば、OFDMAモード、MU-MIMOモード、またはOFDMAおよびMU-MIMOハイブリッド伝送モードを含む)において複数のユーザのためのリソーススケジューリングをどのように行うかについては、ソリューションを提供する必要がある。
現在既知のリソーススケジューリングソリューションによれば、ビットシーケンスは、割り振り予定の帯域幅におけるリソースユニットを指示するものである、すなわち、ビットシーケンス中の1ビットは、1つのリソースサブユニット(1つのリソースサブユニットは1×26個のサブキャリアを含む)の割り振りを指示し、ビットシーケンス内での0と1との間の切り替えは、切り替え前のビットによって指示されるリソースユニットと切り替え後のビットによって指示されるリソースユニットとが異なるユーザに割り振られることを指示している。
例えば、割り振り予定の帯域幅が20メガヘルツ(MHz)である場合には、9つのリソースサブユニットが含まれており、9ビットのビットシーケンスは、リソース割り振りを指示するものである必要がある。さらに、帯域幅が増大するにつれて、ビットシーケンスの長さも連続的に増大することになる、すなわち、従来技術のリソーススケジューリングソリューションでは、大量の伝送リソースを、ビットシーケンスを送信するために占有する必要がある。
したがって、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることができる技術を提供することが期待されている。
本発明の実施形態は、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることができる、リソーススケジューリング方法、装置、およびデバイスを提供している。
第1の態様に従って、リソーススケジューリング方法を、提供しているとともに、無線ローカルエリアネットワークに適用し、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義し、方法は、送信端によって、リソーススケジューリング情報を生成するステップであって、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースに割り振られる可能性がある1つまたは複数のリソースユニットの位置が実際に割り振られたリソースユニットであるかどうかを指示するものである、ステップと、リソーススケジューリング情報を受信端に送信するステップとを含む。
第1の態様に準拠している、第1の態様の第1の実施様態においては、割り当て予定の周波数ドメインリソースは、対称中心を含む。
第1の態様および第1の態様の前述の実施様態に準拠している、第1の態様の第2の実施様態においては、割り当て予定の周波数ドメインリソースに割り振られる可能性があるリソースユニットの位置は、デフォルト位置を含み、デフォルト位置に対応するリソースユニットは、次世代プロトコルによって事前に定義されているような、ビットシーケンスによって指示されないリソースユニットである。
第1の態様および第1の態様の前述の実施様態に準拠している、第1の態様の第3の実施様態においては、ビットシーケンスは、複数のtype-1ビットを含み、複数のtype-1ビットは、1対1ベースで複数のリソースユニットの位置のペアに対応し、type-1ビットのうちの1つは、対応するリソースユニットの位置のペア中のリソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するものであり、1つのリソースユニットの位置のペアは、デフォルト位置の一方のサイド上に位置する2つの連続した最小のリソースユニットの位置を含む。
第1の態様および第1の態様の前述の実施様態に準拠している、第1の態様の第4の実施様態においては、ビットシーケンスは、複数のtype-2ビットを含み、type-2ビットは、対称中心の一方のサイド上における最大のリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。
第1の態様および第1の態様の前述の実施様態に準拠している、第1の態様の第5の実施様態においては、ビットシーケンスは、2つのtype-3ビットを含み、2つのtype-3ビットは、1対1ベースで対称中心の双方のサイド上に位置する2つのリソースユニット位置グループに対応し、type-3ビットは、対応するリソースユニット位置グループ中のリソースユニットの位置にあるすべてのリソースユニットが割り当て予定のリソースユニットであるかどうかを指示するものであり、1つのリソースユニット位置グループは、割り当て予定の周波数ドメインリソースの中心の一方のサイド上に位置する複数の最小のリソースユニットの位置を含む。
第1の態様および第1の態様の前述の実施様態に準拠している、第1の態様の第6の実施様態においては、リソーススケジューリング情報は、複数のスケジューリング済みの受信端の識別子をさらに含み、受信端の識別子は、実際の割り振りにおけるリソースユニットが複数の受信端に割り当てられていることを指示するものである。
第1の態様および第1の態様の前述の実施様態に準拠している、第1の態様の第7の実施様態においては、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースを指示する第1の指示情報をさらに含む。
第1の態様および第1の態様の前述の実施様態に準拠している、第1の態様の第8の実施様態においては、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットがマルチユーザ多入力多出力MU-MIMOのために使用されているかどうかを指示する第2の指示情報をさらに含む。
第1の態様および第1の態様の前述の実施様態に準拠している、第1の態様の第9の実施様態においては、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットが利用可能であるかどうかを指示する第3の指示情報をさらに含む。
第1の態様および第1の態様の前述の実施様態に準拠している、第1の態様の第10の実施様態においては、リソーススケジューリング情報を受信端に送信するステップは、ビットシーケンスをプリアンブル内の高効率シグナリングフィールドAまたは高効率シグナリングフィールドBに付加し、ビットシーケンスを受信端に送信するステップ、または、ビットシーケンスを媒体アクセス制御レイヤに付加し、ビットシーケンスを受信端に送信するステップを含む。
第1の態様および第1の態様の前述の実施様態に準拠している、第1の態様の第11の実施様態においては、送信端は、ネットワークデバイスであり、受信端は、端末デバイスである。
第2の態様に従って、リソーススケジューリング方法を、提供しているとともに、無線ローカルエリアネットワークに適用し、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義し、方法は、受信端によって、送信端によって送信されたリソーススケジューリング情報を受信するステップであって、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースについて実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置のうちの1つまたは複数のリソースユニットの位置にあるかどうかを指示するためのものである、ステップと、リソーススケジューリング情報に従って、受信端に送信端によって実際に割り振られたリソースユニットを決定するステップとを含む。
第2の態様に準拠している、第2の態様の第1の実施様態においては、割り当て予定の周波数ドメインリソースは、対称中心を含む。
第2の態様および第2の態様の前述の実施様態に準拠している、第2の態様の第2の実施様態においては、割り当て予定の周波数ドメインリソースに割り振られる可能性があるリソースユニットの位置は、デフォルト位置を含み、デフォルト位置に対応するリソースユニットは、次世代プロトコルによって事前に定義されているような、ビットシーケンスによって指示されないリソースユニットである。
第2の態様および第2の態様の前述の実施様態に準拠している、第2の態様の第3の実施様態においては、ビットシーケンスは、複数のtype-1ビットを含み、複数のtype-1ビットは、1対1ベースで複数のリソースユニットの位置のペアに対応し、type-1ビットのうちの1つは、対応するリソースユニットの位置のペア中のリソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するものであり、1つのリソースユニットの位置のペアは、デフォルト位置の一方のサイド上に位置する2つの連続した最小のリソースユニットの位置を含む。
第2の態様および第2の態様の前述の実施様態に準拠している、第2の態様の第4の実施様態においては、ビットシーケンスは、複数のtype-2ビットを含み、type-2ビットは、対称中心の一方のサイド上における最大のリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。
第2の態様および第2の態様の前述の実施様態に準拠している、第2の態様の第5の実施様態においては、ビットシーケンスは、2つのtype-3ビットを含み、2つのtype-3ビットは、1対1ベースで対称中心の双方のサイド上に位置する2つのリソースユニット位置グループに対応し、type-3ビットは、対応するリソースユニット位置グループ中のリソースユニットの位置にあるすべてのリソースユニットが割り当て予定のリソースユニットであるかどうかを指示するものであり、1つのリソースユニット位置グループは、割り当て予定の周波数ドメインリソースの中心の一方のサイド上に位置する複数の最小のリソースユニットの位置を含む。
第2の態様および第2の態様の前述の実施様態に準拠している、第2の態様の第6の実施様態においては、リソーススケジューリング情報は、複数のスケジューリング済みの受信端の識別子をさらに含み、受信端の識別子は、実際の割り振りにおけるリソースユニットが複数の受信端に割り当てられていることを指示するものである。
第2の態様および第2の態様の前述の実施様態に準拠している、第2の態様の第7の実施様態においては、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースを指示する第1の指示情報をさらに含む。
第2の態様および第2の態様の前述の実施様態に準拠している、第2の態様の第8の実施様態においては、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットが利用可能であるかどうかを指示する第3の指示情報をさらに含む。
第2の態様および第2の態様の前述の実施様態に準拠している、第2の態様の第9の実施様態においては、受信端によって、送信端によって送信されたリソーススケジューリング情報を受信するステップは、プリアンブル内の高効率シグナリングフィールドAまたは高効率シグナリングフィールドBにおいて搬送されるとともに送信端によって送信されたビットシーケンスを受信するステップ、または、媒体アクセス制御レイヤにおいて搬送されるとともに送信端によって送信されたビットシーケンスを受信するステップを含む。
第2の態様および第2の態様の前述の実施様態に準拠している、第2の態様の第10の実施様態においては、送信端は、ネットワークデバイスであり、受信端は、端末デバイスである。
第2の態様および第2の態様の前述の実施様態に準拠している、第2の態様の第11の実施様態においては、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットがマルチユーザ多入力多出力MU-MIMOのために使用されているかどうかを指示する第2の指示情報をさらに含む。
第3の態様に従って、リソーススケジューリング装置を、提供しているとともに、無線ローカルエリアネットワーク内に構成し、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義し、装置は、リソーススケジューリング情報を生成するように構成される、生成ユニットであって、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースについて実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置のうちの1つまたは複数のリソースユニットの位置にあるかどうかを指示するためのものである、生成ユニットと、リソーススケジューリング情報を受信端に送信するように構成される、送信ユニットとを備える。
第3の態様に準拠している、第3の態様の第1の実施様態においては、割り当て予定の周波数ドメインリソースは、対称中心を含む。
第3の態様および第3の態様の前述の実施様態に準拠している、第3の態様の第2の実施様態においては、割り当て予定の周波数ドメインリソースに割り振られる可能性があるリソースユニットの位置は、デフォルト位置を含み、デフォルト位置に対応するリソースユニットは、次世代プロトコルによって事前に定義されているような、ビットシーケンスによって指示されないリソースユニットである。
第3の態様および第3の態様の前述の実施様態に準拠している、第3の態様の第3の実施様態においては、ビットシーケンスは、複数のtype-1ビットを含み、複数のtype-1ビットは、1対1ベースで複数のリソースユニットの位置のペアに対応し、type-1ビットのうちの1つは、対応するリソースユニットの位置のペア中のリソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するものであり、1つのリソースユニットの位置のペアは、デフォルト位置の一方のサイド上に位置する2つの連続した最小のリソースユニットの位置を含む。
第3の態様および第3の態様の前述の実施様態に準拠している、第3の態様の第4の実施様態においては、ビットシーケンスは、複数のtype-2ビットを含み、type-2ビットは、対称中心の一方のサイド上における最大のリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。
第3の態様および第3の態様の前述の実施様態に準拠している、第3の態様の第5の実施様態においては、ビットシーケンスは、2つのtype-3ビットを含み、2つのtype-3ビットは、1対1ベースで対称中心の双方のサイド上に位置する2つのリソースユニット位置グループに対応し、type-3ビットは、対応するリソースユニット位置グループ中のリソースユニットの位置にあるすべてのリソースユニットが割り当て予定のリソースユニットであるかどうかを指示するものであり、1つのリソースユニット位置グループは、割り当て予定の周波数ドメインリソースの中心の一方のサイド上に位置する複数の最小のリソースユニットの位置を含む。
第3の態様および第3の態様の前述の実施様態に準拠している、第3の態様の第6の実施様態においては、リソーススケジューリング情報は、複数のスケジューリング済みの受信端の識別子をさらに含み、受信端の識別子は、実際の割り振りにおけるリソースユニットが複数の受信端に割り当てられていることを指示するものである。
第3の態様および第3の態様の前述の実施様態に準拠している、第3の態様の第7の実施様態においては、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースを指示する第1の指示情報をさらに含む。
第3の態様および第3の態様の前述の実施様態に準拠している、第3の態様の第8の実施様態においては、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットがマルチユーザ多入力多出力MU-MIMOのために使用されているかどうかを指示する第2の指示情報をさらに含む。
第3の態様および第3の態様の前述の実施様態に準拠している、第3の態様の第9の実施様態においては、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットが利用可能であるかどうかを指示する第3の指示情報をさらに含む。
第3の態様および第3の態様の前述の実施様態に準拠している、第3の態様の第10の実施様態においては、送信ユニットは、ビットシーケンスをプリアンブル内の高効率シグナリングフィールドAまたは高効率シグナリングフィールドBに付加し、ビットシーケンスを受信端に送信するように特に構成される、または送信ユニットは、ビットシーケンスを媒体アクセス制御レイヤに付加し、ビットシーケンスを受信端に送信するように特に構成される。
第3の態様および第3の態様の前述の実施様態に準拠している、第3の態様の第11の実施様態においては、装置は、ネットワークデバイスであり、受信端は、端末デバイスである。
第4の態様に従って、リソーススケジューリング装置を、提供しているとともに、無線ローカルエリアネットワーク内に構成し、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義し、装置は、送信端によって送信されたリソーススケジューリング情報を受信するように構成される、受信ユニットであって、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースについて実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置のうちの1つまたは複数のリソースユニットの位置にあるかどうかを指示するためのものである、受信ユニットと、リソーススケジューリング情報に従って、受信端に送信端によって実際に割り振られたリソースユニットを決定するように構成される、決定ユニットとを備える。
本発明の実施形態による、リソーススケジューリング方法、装置、およびデバイスにおいては、ビットシーケンス中の少なくともいくつかのビットが、実際の割り振りにおけるリソースユニットの割り振りに基づくとともに、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置と比較することによって、割り当て予定の周波数ドメインリソースから実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性がある1つまたは複数のリソースユニットの位置にあるかどうかを指示するものであり、異なる長さのビットシーケンスをフレキシブルに生成することを可能としている。したがって、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることを可能としている。
本発明の実施形態における技術的ソリューションをより明確に説明するために、実施形態または従来技術を説明するのに必要な添付の図面を以下に簡単に説明している。以下の説明における添付の図面が本発明の一部の実施形態を示しているにすぎず、当業者が創造的努力なしにこれらの添付の図面から他の図面をさらに導出し得ることは明らかであろう。
本発明の実施形態による、リソーススケジューリング方法の概略フローチャートである。
WLANシステムの概略アーキテクチャ図である。
20MHz帯域幅を有する周波数ドメインリソースの割り振りの概略図である。
20MHz帯域幅におけるリソースユニットの割り振り位置の概略図である。
40MHz帯域幅におけるリソースユニットの割り振り位置の概略図である。
80MHz帯域幅におけるリソースユニットの割り振り位置の概略図である。
ビットシーケンス生成プロセスの例の概略図である。
ビットシーケンス生成プロセスの別の例の概略図である。
ビットシーケンス生成プロセスのさらに別の例の概略図である。
ビットシーケンス生成プロセスのさらに別の例の概略図である。
ビットシーケンス生成プロセスのさらに別の例の概略図である。
ビットシーケンス生成プロセスのさらに別の例の概略図である。
ビットシーケンス生成プロセスのさらに別の例の概略図である。
本発明の実施形態による、割り当て予定の周波数ドメインリソースの例の概略図である。
802.11axパケットの概略構造図である。
本発明の実施形態による、リソーススケジューリング情報の例の概略図である。
本発明の実施形態による、リソーススケジューリング情報の別の例の概略図である。
本発明の実施形態による、リソーススケジューリング方法の概略フローチャートである。
本発明の実施形態による、リソーススケジューリング装置の概略ブロック図である。
本発明の別の実施形態による、リソーススケジューリング装置の概略ブロック図である。
本発明の実施形態による、リソーススケジューリングデバイスの概略構造図である。
本発明の別の実施形態による、リソーススケジューリングデバイスの概略構造図である。
本ソリューションにおけるビットシーケンスが表1のものと一致している、ビットシーケンス生成またはパースプロセスの簡略概略図である。
本ソリューションにおけるビットシーケンスが表1のものと一致している、ビットシーケンス生成またはパースプロセスの簡略概略図である。
本ソリューションにおけるビットシーケンスが表1のものと一致している、ビットシーケンス生成またはパースプロセスの簡略概略図である。
本ソリューションにおけるビットシーケンスが表3のものと一致している、別のビットシーケンス生成またはパースプロセスの簡略概略図である。
本ソリューションにおけるビットシーケンスが表3のものと一致している、別のビットシーケンス生成またはパースプロセスの簡略概略図である。
本発明の実施形態における添付の図面を参照して、本発明の実施形態における技術的解決手法を以下に明確かつ完全に説明する。説明した実施形態が本発明の実施形態のすべてではなく一部であることは明らかであろう。創造的努力なしに本発明の実施形態に基づいて当業者によって得られる他の実施形態のすべては、本発明の保護範囲に含まれるものとする。
図1は、本発明の実施形態による、リソーススケジューリング方法100の概略フローチャートである、ここで、方法を送信端の観点から説明している。方法100は、無線ローカルエリアネットワークに適用され、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義する。図1に示したように、方法100は、以下のステップを含む。
S110. 送信端が、リソーススケジューリング情報を生成する、ここで、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースについて実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置のうちの1つまたは複数のリソースユニットの位置にあるかどうかを指示するものである。
S120. リソーススケジューリング情報を受信端に送信する。
方法100は、リソーススケジューリングによってマルチユーザ伝送を実施する様々な通信システム、例えば、OFDMAモード、MU-MIMOモードなどで通信を行うシステムに適用され得る。
さらに、方法100は、無線ローカルエリアネットワーク(WLAN、Wireless Local Area Network)、例えば、ワイヤレス・フィディリティ(Wi-Fi、Wireless Fidelity)に適用され得る。
図2は、WLANシステムの概略図である。図2に示したように、WLANシステムは、1つまたは複数のアクセスポイントAP21を含み、1つまたは複数のステーションSTA22をさらに含む。データ伝送がアクセスポイントとステーションとの間で行われる。ステーションは、アクセスポイントによって送信されたプリアンブルに従って、ステーションのためにスケジューリングされたリソースを決定し、リソースに基づいて、アクセスポイントとデータ伝送を行う。
オプションとして、送信端は、ネットワークデバイスであり、受信端は、端末デバイスである。
特に、送信端デバイスとして、通信システム内のネットワークサイドデバイスが、図示され得るし、例えば、WLAN内のアクセスポイント(AP、Access Point)であり得る。APはまた、無線アクセスポイント、ブリッジ、ホットスポットなどと称され得るし、APは、サーバまたは通信ネットワークにアクセスし得る。
受信端デバイスとして、通信システム内の端末デバイスが、図示され得るし、例えば、WLAN内のステーション(STA)であり得る。STAはまた、ユーザと称され得るし、無線センサ、無線通信端末、または、例えば、携帯電話(もしくは、「セルラ」電話と称する)および無線通信機能を有するコンピュータといったモバイル端末であり得る。例えば、STAは、無線アクセスネットワークと音声およびデータなどの通信データを交換する、ポータブル型、ポケットサイズ型、ハンドヘルド型、コンピュータ内蔵型、ウェアラブル型、または車載型無線通信装置であり得る。
本発明の本実施形態の方法100が適用可能であるシステムを説明した上記は例にすぎず、本発明はそれに限定されないことを理解されたい。例えば、グローバル・システム・フォー・モバイル・コミュニケーションズ(GSM(登録商標)、Global System of Mobile communication)、符号分割多元接続(CDMA、Code Division Multiple Access)システム、広帯域符号分割多元接続(WCDMA(登録商標)、Wideband Code Division Multiple Access Wireless)、汎用パケット無線システム(GPRS、General Packet Radio Service)、およびロング・ターム・エボリューション(LTE、Long Term Evolution)システムを以下にさらに説明し得る。
それに対応するように、ネットワークデバイスは、GSM(登録商標)またはCDMAにおける基地局(BTS、Base Transceiver Station)であり得るし、または、WCDMA(登録商標)における基地局(NodeB)であり得るし、または、LTEにおける発展型基地局(eNBもしくはe-NodeB、evolutional Node B)であり得るし、スモールセル基地局であり得る、これは、マイクロ基地局(Micro)であり得るし、もしくはピコ基地局(Pico)であり得るし、もしくは、フェムトセル基地局(フェムト)とも称されるホーム基地局であり得るが、本発明においてこのことに限定されない。端末デバイスは、例えば、携帯電話(または、「セルラ」電話と称される)といった、モバイル端末(Mobile Terminal)、またはモバイルユーザ機器であり得る。
WLANシステムにおいて割り振られるリソースユニットのサイズに関するルールは、リソースユニットとして26個のサブキャリアを使用することである。
図3に示したように、一例として20メガヘルツ(MHz)帯域幅を使用すれば、WLANシステムにおけるデータシンボル部分の離散フーリエ変換または逆離散フーリエ変換(DFT/IDFT)の点の数量は、256である、すなわち、256個のサブキャリアが存在する。サブキャリア-1、0、および1は、直流(Direct Current、DC)成分であり、左サイドバンドサブキャリア-122からサブキャリア-2および右サイドバンドサブキャリア2からサブキャリア122は、データ情報を搬送するものである、すなわち、242個のサブキャリアがデータ情報を搬送するものである。サブキャリア-128からサブキャリア-123およびサブキャリア123からサブキャリア128は、ガードバンドである。したがって、一般的に、データ情報を搬送する242個のサブキャリアは、9つのリソースサブユニットにグループ分けされる、ここで、各リソースサブユニットは、26個のサブキャリアを含み、8つの残りのサブキャリアは未使用である。さらに、クロスDC(すなわち、サブキャリア-1、0、および1を含む)リソースサブユニットは、帯域幅の中心にある。本発明の本実施形態における方法100は、データ情報を搬送する242個のサブキャリアの割り振りに主に関連する。
異なる帯域幅を有する周波数ドメインリソース内に含むことができるリソースユニット(リソースブロックとも称する)のタイプは異なる。特に、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソース(20MHz、40MHz、80MHz、または160MHz)から割り振られる可能性があるリソースユニットの位置(リソース割り振りマップ)を事前に定義している。送信端は、リソーススケジューリング情報を生成および送信する、ここで、リソーススケジューリング情報は、割り振られた割り当て予定のリソースユニットを指示するビットシーケンスを含む。受信端は、ビットシーケンスを読み出すことによって、割り当て予定の周波数ドメインリソースを分割することでどのリソースユニットが取得されるかを知り得る。
加えて、リソーススケジューリング情報は、割り振られたリソースユニットに対応するスケジューリング済みの受信端に関する情報をさらに含み得る。このように、リソーススケジューリング情報を読み出すことによって、受信端は、受信端に割り振られるリソースユニット上でアップリンクおよびダウンリンク情報の伝送を実施する。
次世代プロトコルよって事前に定義されているような、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を(図4、図5、または図6に示したリソース割り振りマップを参照して)まず以下に詳細に説明する。
1. 20MHz帯域幅の周波数ドメインリソースについて
オプションとして、割り当て予定の周波数ドメインリソースに割り振られる可能性があるリソースユニットの位置は、デフォルト位置を含み、デフォルト位置に対応するリソースユニットは、次世代プロトコルによって事前に定義され得るような、ビットシーケンスによって指示されないリソースユニットである。オプションとして、1ビットが、デフォルト位置にあるリソースユニットが使用のためにユーザに割り振られているかどうかを指示するためのものであってもよい。
特に、図4に示したように、20MHz帯域幅の周波数ドメインリソースは、中心に位置するデフォルトリソースユニット(すなわち、デフォルト位置に位置するリソースユニット)を含み得るし、デフォルトリソースユニットは、1×26トーンリソースユニット、すなわち、26個のサブキャリアを含むクロスDC(すなわち、サブキャリア-1、0、および1)リソースユニットであり得る。デフォルトリソースユニットは、デフォルトで通信システムに存在しており、独立して割り振られる、すなわち、20MHz帯域幅を有する各割り当て予定のリソースにおいて、デフォルト1×26トーンリソースユニットは、リソースの中心位置から割り振られる。デフォルトリソースユニットは、受信端に独立して割り振られている。デフォルトリソースユニットが割り振られている受信端は、デフォルトリソースユニットの左サイドまたは右サイド上の隣接リソースユニットが割り振られている受信端と同一または異なり得る。このことは本発明において特に限定されない。20MHz帯域幅については、デフォルトリソースユニットが割り振られている受信端が、デフォルトリソースユニットの左サイドまたは右サイド上の隣接リソースユニットが割り振られている受信端と同一である場合には、20MHz帯域幅が1人のユーザだけに割り振られていることを指示する。さもなければ、デフォルトリソースユニットが割り振られている受信端は、デフォルトリソースユニットの左サイドまたは右サイド上の隣接リソースユニットが割り振られている受信端とは異なる。
デフォルト位置に位置するデフォルトリソースユニットに加えて、20MHz帯域幅の周波数ドメインリソースは、20MHz帯域幅の周波数ドメインリソースの中心におけるデフォルトリソースユニットの左サイドまたは右サイドにそれぞれ位置する、以下の4つのタイプのリソースユニットをさらに含む、すなわち、
リソースユニットが1つのリソースサブユニット(すなわち、26個のサブキャリア)を含んでいることを指示する、1×26トーンリソースユニット、20MHz帯域幅において割り振られる可能性がある最小のリソースユニットと、
リソースユニットが2つのリソースサブユニット(すなわち、2×26個のサブキャリア)を含んでいることを指示する、2×26トーンリソースユニットと、
リソースユニットが4つのリソースサブユニット(すなわち、4×26個のサブキャリア)を含んでいることを指示する、4×26トーンリソースユニットと、
リソースユニットが242個のサブキャリアを含んでいることを指示する、242トーンリソースユニット、20MHz帯域幅において割り振られる可能性がある最大のリソースユニットとをさらに含む。
4×26トーンリソースユニットは、106個のサブキャリアを含む、すなわち、102個のデータサブキャリアと4個のパイロットサブキャリアとを含む。繰り返しを避けるために、同一または同様のケースに関する説明は以下では省略する。
図4に示したように、割り振られる可能性があるリソースユニットの位置を簡潔に説明するために、20MHz帯域幅におけるリソースユニットの割り振りマップを4つのレイヤとして図示または説明している。
第1のレイヤは、1×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、20MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。中心に位置するデフォルトリソースユニットの左サイドおよび右サイド上に、4つの1×26トーンリソースユニットがそれぞれ存在する、すなわち、図4に示したリソースユニットの位置に位置するリソースユニット(略して、位置と以降称する)#7から位置#10および位置#11から位置#14が存在する。
第2のレイヤは、2×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、20MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。中心に位置するデフォルトリソースユニットの左サイドおよび右サイド上に、2つの2×26トーンリソースユニットがそれぞれ存在する、すなわち、図4に示した位置#1から位置#4に位置するリソースユニットが存在する。
第3のレイヤは、4×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、20MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。中心に位置するデフォルトリソースユニットの左サイドおよび右サイド上に、1つの4×26トーンリソースユニットがそれぞれ存在する、すなわち、図4に示した位置#5および位置#6に位置するリソースユニットが存在する。
第4のレイヤは、242トーンリソースユニットの割り振りマップである。図4に示したように、242トーンリソースユニットは、前述の対称中心が位置するサブキャリアを含む。
ある例においては、20MHz帯域幅の周波数ドメインリソース(すなわち、割り当て予定の周波数ドメインリソースの例)は、242個のサブキャリアを含み、図4中の第1のレイヤから第3のレイヤにおいて任意のリソースユニットに分割され得る。割り振られたリソースユニットを複数のユーザに割り振り、割り振られたただ1つのリソースユニットを各ユーザに割り振ることができる。
あるいは、別の例においては、20MHz帯域幅の周波数ドメインリソースは、第4のレイヤにおいてリソースユニットに分割されてもよい。この場合には、20MHz帯域幅の周波数ドメインリソースは、1人のユーザに割り振られ、リソース割り振りは、前述した帯域幅指示情報およびシングルユーザ伝送指示ビットを使用して指示され得る。
別の例においては、20MHz帯域幅の周波数ドメインリソースは、第4のレイヤにおいてリソースユニットに分割されてもよい。この場合には、20MHz帯域幅の周波数ドメインリソースは、MU-MIMOのための複数のユーザに割り振られ、リソース割り振りは、前述した帯域幅指示情報およびマルチユーザ伝送指示ビットを使用して指示され得る。
本発明におけるリソーススケジューリングモードは、20MHz帯域幅の周波数ドメインリソースが、第1のレイヤから第3のレイヤにおける任意のリソースユニットの組合せを含み、複数のユーザに割り振られるケースに主に関連する。
例えば、図7は、20MHz帯域幅の周波数ドメインリソースの例を示している。図7に示したように、周波数ドメインリソースは、(図7中では左から右の順に)2つの2×26トーンリソースユニット(すなわち、リソースユニット#1およびリソースユニット#2)、1つの1×26トーンリソースユニット(すなわち、デフォルトリソースユニットである、リソースユニット#0)、および1つの4×26トーンリソースユニット(すなわち、リソースユニット#3)に分割される。
別の例では、図8は、20MHz帯域幅の周波数ドメインリソースの別の例を示している。図8に示したように、周波数ドメインリソースは、(図8中では左から右の順に)1つの2×26トーンリソースユニット(すなわち、リソースユニット#1')、3つの1×26トーンリソースユニット(すなわち、リソースユニット#2'、リソースユニット#3'、およびリソースユニット#0'、ここで、リソースユニット#0'は、デフォルトリソースユニットである)、および1つの4×26トーンリソースユニット(すなわち、リソースユニット#4')に分割される。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を含む。
特に、図4に示したように、20MHz帯域幅の周波数ドメインリソースは、中心に位置するリソースユニット(すなわち、デフォルト位置にあるリソースユニット)を含み、中心に位置するリソースユニットの双方のサイド上のリソースユニットの位置は、対称的に配分されている、すなわち、中心に位置するリソースユニットは、20MHz帯域幅の周波数ドメインリソースの対称中心として使用され得る。
2. 40MHz帯域幅の周波数ドメインリソースについて
40MHz帯域幅の周波数ドメインリソースが2つの20MHz帯域幅の周波数ドメインリソースを含むと扱われ得る。それに対応するように、どちらかの20MHz帯域幅の周波数ドメインリソースが、20MHz帯域幅の中心に位置するデフォルトリソースユニット(すなわち、デフォルト位置に位置するリソースユニット)を含み得るし、40MHz帯域幅におけるデフォルトリソースユニット(合計で2つのデフォルトリソースユニット)のコンポーネントおよび割り振りモードは、コンポーネントおよび20MHz帯域幅におけるデフォルトリソースユニットの割り振りモードと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
オプションとして、2ビットが、帯域幅において2つのデフォルト位置にあるリソースユニットが使用のためにユーザに割り振られているかどうかをそれぞれ指示するものであってもよい。デフォルト位置に位置するデフォルトリソースユニットに加えて、40MHz帯域幅の周波数ドメインリソースは、40MHz帯域幅の周波数ドメインリソースの中心周波数の左サイドまたは右サイドにそれぞれ位置する、以下の5つのタイプのリソースユニットをさらに含む、すなわち、
リソースユニットが1つのリソースサブユニット(すなわち、26個のサブキャリア)を含んでいることを指示する、1×26トーンリソースユニット、40MHz帯域幅において割り振られる可能性がある最小のリソースユニットと、
リソースユニットが2つのリソースサブユニット(すなわち、2×26個のサブキャリア)を含んでいることを指示する、2×26トーンリソースユニットと、
リソースユニットが4つのリソースサブユニット(すなわち、4×26個のサブキャリア)を含んでいることを指示する、4×26トーンリソースユニットと、
リソースユニットが242個のサブキャリアを含んでいることを指示する、242トーンリソースユニットと、
リソースユニットが2×242個のサブキャリアを含んでいることを指示する、2×242、40MHz帯域幅において割り振られる可能性がある最大のリソースユニットとをさらに含む。
図5に示したように、割り振られる可能性があるリソースユニットの位置を簡潔に説明するために、40MHz帯域幅におけるリソースユニットの割り振りマップを5つのレイヤとして図示または説明している。
第1のレイヤは、1×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、どちらかの20MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。どちらかのデフォルトリソースユニットの左サイドおよび右サイド上には、4つの1×26トーンリソースユニットがそれぞれ存在している。どちらかの20MHz帯域幅における8つの1×26トーンリソースユニットの割り振りは、図4中の第1のレイヤにおいて示した1×26トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第2のレイヤは、2×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、どちらかの20MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。どちらかのデフォルトリソースユニットの左サイドおよび右サイド上には、2つの2×26トーンリソースユニット(例えば、図5中の位置#Eおよび位置#F)がそれぞれ存在している。どちらかの20MHz帯域幅における4つの2×26トーンリソースユニットの割り振りは、図4中の第2のレイヤにおいて示した1×26トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第3のレイヤは、4×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、どちらかの20MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。どちらかのデフォルトリソースユニットの左サイドおよび右サイド上には、1つの4×26トーンリソースユニット(例えば、図5中の位置#Cおよび位置#D)がそれぞれ存在している。どちらかの20MHz帯域幅における4×26トーンリソースユニットの割り振りは、図4中の第3のレイヤにおいて示した4×26トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第4のレイヤは、242トーンリソースユニットの割り振りマップである。40MHzの中心周波数(すなわち、サブキャリア0)の左サイドおよび右サイド上には、1つの242トーンリソースユニット、すなわち、図5に示した位置#Aおよび位置#Bに位置するリソースユニットがそれぞれ存在している。
第5のレイヤは、4×242トーンリソースユニットの割り振りマップである。
ある例においては、40MHz帯域幅の周波数ドメインリソース(すなわち、割り当て予定の周波数ドメインリソースの例)は、484個のサブキャリアを含み、図5中の第1のレイヤから第4のレイヤにおいて任意のリソースユニットに分割され得る。割り振られたリソースユニットを複数のユーザに割り振り、割り振られたただ1つのリソースユニットを各ユーザに割り振ることができる。
あるいは、別の例においては、40MHz帯域幅の周波数ドメインリソースは、第5のレイヤにおいてリソースユニットに分割されてもよい。この場合には、40MHz帯域幅の周波数ドメインリソースは、1人のユーザに割り振られ、リソース割り振りは、前述した帯域幅指示情報およびシングルユーザ伝送指示ビットを使用して指示され得る。
別の例においては、40MHz帯域幅の周波数ドメインリソースは、第5のレイヤにおいてリソースユニットに分割されてもよい。この場合には、40MHz帯域幅の周波数ドメインリソースは、MU-MIMOのための複数のユーザに割り振られ、リソース割り振りは、前述した帯域幅指示情報およびマルチユーザ伝送指示ビットを使用して指示され得る。
本発明におけるリソーススケジューリングモードは、40MHz帯域幅の周波数ドメインリソースが、第1のレイヤから第4のレイヤにおける任意のリソースユニットの組合せを含み、複数のユーザに割り振られるケースに主に関連する。
例えば、図10は、40MHz帯域幅の周波数ドメインリソースの例を示している。図10に示したように、周波数ドメインリソースは、(図10中では左から右の順に)2つの2×26トーンリソースユニット(すなわち、リソースユニット#1''およびリソースユニット#2'')、1つの1×26トーンリソースユニット(すなわち、デフォルトリソースユニットである、リソースユニット#0'')、1つの4×26トーンリソースユニット(すなわち、リソースユニット#3'')、および1つの242トーンリソースユニット(すなわち、リソースユニット#4'')に分割される。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を含む。
特に、図4に示したように、40MHz帯域幅の周波数ドメインリソースの中心周波数の双方のサイド上の様々なリソースユニットの位置は、対称的に配分されている、すなわち、中心周波数は、40MHz帯域幅の周波数ドメインリソースの対称中心として使用され得る。
3. 80MHz帯域幅の周波数ドメインリソースについて
オプションとして、割り当て予定の周波数ドメインリソースに割り振られる可能性があるリソースユニットの位置は、デフォルト位置を含み、デフォルト位置に対応するリソースユニットは、次世代プロトコルによって事前に定義され得るような、ビットシーケンスによって指示されないリソースユニットである。
オプションとして、5ビットが、帯域幅において5つのデフォルト位置にあるリソースユニットが使用のためにユーザに割り振られているかどうかをそれぞれ指示するものであってもよい。
特に、図6に示したように、80MHz帯域幅の周波数ドメインリソースは、中心に位置するデフォルトリソースユニット(すなわち、デフォルト位置に位置するリソースユニット)を含み得るし、デフォルトリソースユニットは、1×26トーンリソースユニット、すなわち、26個のサブキャリアを含むクロスDC(すなわち、サブキャリア-1、0、および1)リソースユニットであり得る。デフォルトリソースユニットは、デフォルトで通信システムに存在しており、独立して割り振られる、すなわち、80MHz帯域幅を有する各割り当て予定のリソースにおいて、デフォルト1×26トーンリソースユニットは、リソースの中心位置から割り振られる。デフォルトリソースユニットは、受信端に独立して割り振られている。デフォルトリソースユニットが割り振られている受信端は、デフォルトリソースユニットの左サイドまたは右サイド上の隣接リソースユニットが割り振られている受信端と同一または異なり得る。このことは本発明において特に限定されない。80MHz帯域幅については、デフォルトリソースユニットが割り振られている受信端が、デフォルトリソースユニットの左サイドまたは右サイド上の隣接リソースユニットが割り振られている受信端と同一である場合には、80MHz帯域幅が1人のユーザだけに割り振られていることを指示する。さもなければ、デフォルトリソースユニットが割り振られている受信端は、デフォルトリソースユニットの左サイドまたは右サイド上の隣接リソースユニットが割り振られている受信端とは異なる。
さらに、80MHz帯域幅の周波数ドメインリソースが2つの40MHz帯域幅の周波数ドメインリソースおよび対称中心に位置するデフォルトリソースユニットを含むと扱われ得るし、どちらかの40MHz帯域幅の周波数ドメインリソースが2つの20MHz周波数ドメインリソースを含むと扱われ得る。それに対応するように、各20MHz帯域幅の周波数ドメインリソースは、20MHz帯域幅の中心に位置するデフォルトリソースユニット(すなわち、デフォルト位置に位置するリソースユニット)を含み得る。
デフォルト位置に位置するデフォルトリソースユニットに加えて、80MHz帯域幅の周波数ドメインリソースは、80MHz帯域幅の周波数ドメインリソースの中心におけるデフォルトリソースユニットの左サイドまたは右サイドにそれぞれ位置する、以下の6つのタイプのリソースユニットをさらに含む、すなわち、
リソースユニットが1つのリソースサブユニット(すなわち、26個のサブキャリア)を含んでいることを指示する、1×26トーンリソースユニット、80MHz帯域幅において割り振られる可能性がある最小のリソースユニットと、
リソースユニットが2つのリソースサブユニット(すなわち、2×26個のサブキャリア)を含んでいることを指示する、2×26トーンリソースユニットと、
リソースユニットが4つのリソースサブユニット(すなわち、4×26個のサブキャリア)を含んでいることを指示する、4×26トーンリソースユニットと、
リソースユニットが242個のサブキャリアを含んでいることを指示する、242トーンリソースユニットと、
リソースユニットが2×242個のサブキャリアを含んでいることを指示する、2×242トーンリソースユニットと、
リソースユニットが996個のサブキャリアを含んでいることを指示する、996トーンリソースユニット、80MHz帯域幅において割り振られる可能性がある最大のリソースユニットとをさらに含む。
割り振られる可能性があるリソースユニットの位置を簡潔に説明するために、40MHz帯域幅におけるリソースユニットの割り振りマップを6つのレイヤとして図示または説明している。
第1のレイヤは、1×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、各20MHz帯域幅の中心位置に位置する1×26トーンリソースユニットおよび80MHz帯域幅の中心に位置する1×26トーンリソースユニット)の割り振りマップである。各20MHz帯域幅の中心位置にあるデフォルトリソースユニットの左サイドおよび右サイド上には、4つの1×26トーンリソースユニットがそれぞれ存在している。各20MHz帯域幅における1×26トーンリソースユニットの割り振りは、図4中の第1のレイヤにおいて示した1×26トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第2のレイヤは、2×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、各20MHz帯域幅の中心位置に位置する1×26トーンリソースユニットおよび80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。各20MHz帯域幅の中心位置にあるデフォルトリソースユニットの左サイドおよび右サイド上には、2つの2×26トーンリソースユニットがそれぞれ存在している。各20MHz帯域幅における2×26トーンリソースユニットの割り振りは、図4中の第2のレイヤにおいて示した2×26トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第3のレイヤは、4×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、各20MHz帯域幅の中心位置に位置する1×26トーンリソースユニットおよび80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。各20MHz帯域幅の中心位置にあるデフォルトリソースユニットの左サイドおよび右サイド上には、1つの4×26トーンリソースユニット(例えば、図6中の位置#eおよび位置#f)がそれぞれ存在している。各20MHz帯域幅における4×26トーンリソースユニットの割り振りは、図4中の第3のレイヤにおいて示した4×26トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第4のレイヤは、242トーンリソースユニットの割り振りマップおよびデフォルトリソースユニット(すなわち、80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。どちらかの40MHz帯域幅の中心周波数の左サイドおよび右サイド上には、1つの242トーンリソースユニット、すなわち、図6中に示した位置#cおよび位置#dに位置するリソースユニットがそれぞれ存在している。どちらかの40MHz帯域幅における242トーンリソースユニットの割り振りは、図5中の第4のレイヤにおいて示した242トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第5のレイヤは、2×242トーンリソースユニットの割り振りマップおよびデフォルトリソースユニット(すなわち、80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。80MHzの中心位置に位置するデフォルトリソースユニットの左サイドおよび右サイド上には、1つの242トーンリソースユニット、すなわち、図6に示した位置#aおよび位置#bに位置するリソースユニットがそれぞれ存在している。どちらかの40MHz帯域幅における242トーンリソースユニットの割り振りは、図5中の第5のレイヤにおいて示した242トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第6のレイヤは、996トーンリソースユニットの割り振りマップである。
ある例においては、80MHz帯域幅の周波数ドメインリソース(すなわち、割り当て予定の周波数ドメインリソースの例)は、996個のサブキャリアを含み、図6中の第1のレイヤから第5のレイヤにおいて任意のリソースユニットに分割され得る。割り振られたリソースユニットを複数のユーザに割り振り、割り振られたただ1つのリソースユニットを各ユーザに割り振ることができる。
あるいは、別の例においては、80MHz帯域幅の周波数ドメインリソースは、第6のレイヤにおいてリソースユニットに分割されてもよい。この場合には、80MHz帯域幅の周波数ドメインリソースは、1人のユーザに割り振られ、リソース割り振りは、前述した帯域幅指示情報およびシングルユーザ伝送指示ビットを使用して指示され得る。
別の例においては、80MHz帯域幅の周波数ドメインリソースは、第6のレイヤにおいてリソースユニットに分割されてもよい。この場合には、80MHz帯域幅の周波数ドメインリソースは、MU-MIMOのための複数のユーザに割り振られ、リソース割り振りは、前述した帯域幅指示情報およびマルチユーザ伝送指示ビットを使用して指示され得る。
本発明におけるリソーススケジューリングモードは、80MHz帯域幅の周波数ドメインリソースが、第1のレイヤから第5のレイヤにおける任意のリソースユニットの組合せを含み、複数のユーザに割り振られるケースに主に関連する。
例えば、図11は、80MHz帯域幅の周波数ドメインリソースの例を示している。図11に示したように、周波数ドメインリソースは、(図11中では左から右の順に)は、1つの4×26トーンリソースユニット(すなわち、リソースユニット#1''')、1つの1×26トーンリソースユニット(すなわち、デフォルトリソースユニットである、リソースユニット#0''')、1つの4×26トーンリソースユニット(すなわち、リソースユニット#2''')、1つの242トーンリソースユニット(すなわち、リソースユニット#3''')、1つの1×26トーンリソースユニット(すなわち、デフォルトリソースユニットである、リソースユニット#00''')、および1つの2×242トーンリソースユニット(すなわち、リソースユニット#4''')に分割される。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を含む。
特に、図4に示したように、80MHz帯域幅の周波数ドメインリソースは、中心に位置するリソースユニット(すなわち、デフォルト位置にあるリソースユニット)を含み、中心に位置するリソースユニットの双方のサイド上のリソースユニットの位置は、対称的に配分されている、すなわち、中心に位置するリソースユニットは、80MHz帯域幅の周波数ドメインリソースの対称中心として使用され得る。
4. 160MHz帯域幅の周波数ドメインリソースについて
160MHz帯域幅の周波数ドメインリソースが2つの80MHz周波数ドメインリソースを含むと扱われ得る。それに対応するように、どちらかの80MHz帯域幅の周波数ドメインリソースは、80MHz帯域幅の中心に位置するデフォルトリソースユニット(すなわち、デフォルト位置に位置するリソースユニット)を含み得るし、160MHz周波数ドメインリソースにおける各20MHz帯域幅の周波数ドメインリソースは、20MHz帯域幅の中心に位置するデフォルトリソースユニット(すなわち、デフォルト位置に位置するリソースユニット)を含み得る。
オプションとして、10ビットが、帯域幅において10個のデフォルト位置にあるリソースユニットが使用のためにユーザに割り振られているかどうかをそれぞれ指示するものであってもよい。
デフォルト位置に位置するデフォルトリソースユニットに加えて、160MHz帯域幅の周波数ドメインリソースは、160MHz帯域幅の周波数ドメインリソースの中心周波数の左サイドまたは右サイドにそれぞれ位置する、以下の7つのタイプのリソースユニットをさらに含む、すなわち、
リソースユニットが1つのリソースサブユニット(すなわち、26個のサブキャリア)を含んでいることを指示する、1×26トーンリソースユニット、80MHz帯域幅において割り振られる可能性がある最小のリソースユニットと、
リソースユニットが2つのリソースサブユニット(すなわち、2×26個のサブキャリア)を含んでいることを指示する、2×26トーンリソースユニットと、
リソースユニットが4つのリソースサブユニット(すなわち、4×26個のサブキャリア)を含んでいることを指示する、4×26トーンリソースユニットと、
リソースユニットが242個のサブキャリアを含んでいることを指示する、242トーンリソースユニットと、
リソースユニットが2×242個のサブキャリアを含んでいることを指示する、2×242トーンリソースユニットと、
リソースユニットが996個のサブキャリアを含んでいることを指示する、996トーンリソースユニットと、
リソースユニットが2×996個のサブキャリアを含んでいることを指示する、2×996トーンリソースユニット、160MHz帯域幅において割り振られる可能性がある最大のリソースユニットとをさらに含む。
割り振られる可能性があるリソースユニットの位置を簡潔に説明するために、160MHz帯域幅リソースユニットの割り振りマップを7つのレイヤとして図示または説明している。
第1のレイヤは、1×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、各20MHz帯域幅の中心位置に位置する1×26トーンリソースユニットおよびどちらかの80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。各20MHz帯域幅の中心位置にあるデフォルトリソースユニットの左サイドおよび右サイド上には、4つの1×26トーンリソースユニットがそれぞれ存在している。各20MHz帯域幅における1×26トーンリソースユニットの割り振りは、図4中の第1のレイヤにおいて示した1×26トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第2のレイヤは、2×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、各20MHz帯域幅の中心位置に位置する1×26トーンリソースユニットおよびどちらかの80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。各20MHz帯域幅の中心位置にあるデフォルトリソースユニットの左サイドおよび右サイド上には、2つの2×26トーンリソースユニットがそれぞれ存在している。各20MHz帯域幅における2×26トーンリソースユニットの割り振りは、図4中の第2のレイヤにおいて示した2×26トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第3のレイヤは、4×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、各20MHz帯域幅の中心位置に位置する1×26トーンリソースユニットおよびどちらかの80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。各20MHz帯域幅の中心位置にあるデフォルトリソースユニットの左サイドおよび右サイド上には、1つの4×26トーンリソースユニットがそれぞれ存在している。各20MHz帯域幅における4×26トーンリソースユニットの割り振りは、図4中の第3のレイヤにおいて示した4×26トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第4のレイヤは、242トーンリソースユニットの割り振りマップおよびデフォルトリソースユニット(すなわち、どちらかの80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。どちらかの40MHzの中心周波数の左サイドおよび右サイド上には、1つの242トーンリソースユニットがそれぞれ存在している。どちらかの40MHz帯域幅における242トーンリソースユニットの割り振りは、図5中の第4のレイヤにおいて示した242トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第5のレイヤは、2×242トーンリソースユニットの割り振りマップおよびデフォルトリソースユニット(すなわち、どちらかの80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。80MHzの中心位置に位置するデフォルトリソースユニットの左サイドおよび右サイド上には、1つの242トーンリソースユニットがそれぞれ存在している。各40MHz帯域幅における242トーンリソースユニットの割り振りは、図5中の第5のレイヤにおいて示した242トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第6のレイヤは、996トーンリソースユニットの割り振りマップおよびデフォルトリソースユニット(すなわち、各80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。160MHzの中心周波数の左サイドおよび右サイド上には、1つの996トーンリソースユニットがそれぞれ存在する。どちらかの80MHz帯域幅における242トーンリソースユニットの割り振りは、図6中の第6のレイヤにおいて示した996トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第7のレイヤは、2×996トーンリソースユニットの割り振りマップである。
ある例においては、160MHz帯域幅の周波数ドメインリソース(すなわち、割り当て予定の周波数ドメインリソースの例)は、2×996個のサブキャリアを含み、第1のレイヤから第6のレイヤにおいて任意のリソースユニットに分割され得る。割り振られたリソースユニットを複数のユーザに割り振り、割り振られたただ1つのリソースユニットを各ユーザに割り振ることができる。
あるいは、別の例においては、160MHz帯域幅の周波数ドメインリソースは、第7のレイヤにおいてリソースユニットに分割されてもよい。この場合には、160MHz帯域幅の周波数ドメインリソースは、1人のユーザに割り振られ、リソース割り振りは、前述した帯域幅指示情報およびシングルユーザ伝送指示ビットを使用して指示され得る。
別の例においては、160MHz帯域幅の周波数ドメインリソースは、第7のレイヤにおいてリソースユニットに分割されてもよい。この場合には、160MHz帯域幅の周波数ドメインリソースは、MU-MIMOのための複数のユーザに割り振られ、リソース割り振りは、前述した帯域幅指示情報およびマルチユーザ伝送指示ビットを使用して指示され得る。
本発明におけるリソーススケジューリングモードは、160MHz帯域幅の周波数ドメインリソースが、第1のレイヤから第6のレイヤにおける任意のリソースユニットの組合せを含み、複数のユーザに割り振られるケースに主に関連する。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を含む。
特に、図4に示したように、160MHz帯域幅の周波数ドメインリソースの中心周波数の左サイドおよび右サイド上の様々なリソースユニットの位置は、対称的に配分されている、すなわち、中心周波数は、160MHz帯域幅の周波数ドメインリソースの対称中心として使用され得る。
上記においては、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を説明している。下記においては、割り振られる可能性があるリソースユニットの位置に基づいてリソーススケジューリング情報を生成するプロセスを詳細に説明する。
本発明の本実施形態においては、送信端は、リソーススケジューリングを行う必要がある、例えば、受信端がリソースユニットを使用して伝送を行うために、リソーススケジューリング情報を使用して、受信端(受信端の数量は1つまたは複数であり得る)に受信端に対応するリソースユニットを通知する必要がある。
送信端は、ビットシーケンス、または、ビットマップ(bitmap)を使用して、システム内の各受信端に以下の情報、すなわち、
現在の割り当て予定の周波数ドメインリソースにおけるリソースユニットの割り振りを通知し得る。リソースユニットの割り振りは、一方では、割り振られた各リソースユニットに含まれるサブキャリアの数量、すなわち、割り振られた各リソースユニットのサイズを含む。リソースユニットの割り振りはまた、他方では、割り当て予定の周波数ドメインリソースにおける各割り振られるリソースユニットの位置を含む。以下の実施形態においては、リソースユニットの割り振りのための簡易化した指示を、各帯域幅に割り振られる可能性があるプロトコル事前定義リソースユニットに基づいて、例えば、各帯域幅において各サイズを有する各リソースユニットの事前に定義された数量および位置に基づいて、提供している。それに対応するように、受信端は、上述した情報に基づいて、送信端によって割り振られる各リソースユニットを決定し得る。スケジューリング済みの受信端に関する情報を組み合わせて、受信端は、対応するスケジューリング済みのリソースユニット上でその後の情報通信を行い得る。
以下の実施形態の各々は、割り当て予定の周波数ドメインリソース(帯域幅)におけるリソースユニットの割り振りを効率的に指示するためのソリューションを提供している。
実施形態1
オプションとして、ビットシーケンスは、複数のtype-1ビットを含み、複数のtype-1ビットは、1対1ベースで複数のリソースユニットの位置のペアに対応し、type-1ビットのうちの1つは、対応するリソースユニットの位置のペア中のリソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するものであり、1つのリソースユニットの位置のペアは、デフォルト位置の一方のサイド上に位置する2つの連続した最小のリソースユニットの位置を含む。特に、図7および図8を参照すれば、図7および図8は、割り振られた割り当て予定のリソースユニットを指示する、リソースユニット割り振り結果の簡略概略図および対応するビットシーケンスの概略図である。
様々な帯域幅(20MHzのみを図に示しているが、これは、40MHz、80MHz、および160MHzを含むがこれらに限定されない)について、ビットシーケンスは、少なくとも複数の(2つ以上の)type-1ビットを含む。type-1ビットは、割り振られる可能性があるとともに割り当て予定の周波数ドメインリソースにおいてデフォルト位置(すなわち、デフォルトリソースユニットが位置する位置)の一方のサイド上に位置する2つの連続した最小のリソースユニット(1×26)の位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するものである。
ここで、図4から図6に示したように、各帯域幅の第1のレイヤにおいては、各20MHz帯域幅におけるデフォルト位置の一方のサイド上に4つの1×26リソースユニットの位置が存在している。デフォルト位置の一方のサイドは、2つのリソースユニットの位置のペアを含み得る。各リソースユニットの位置のペアは、2つの連続した1×26リソースユニットの位置を含み得るし、各1×26リソースユニットの位置は、1つのリソースユニットの位置のペアに属するおよびそれのみに属する。
前述の説明によれば、異なる帯域幅において複数のデフォルト位置が存在し得ることに留意されたい。複数のデフォルト位置が存在する場合には、デフォルト位置の一方のサイドは、2つのデフォルト位置間のバンドリソースを指す。
オプションとして、方法は、2つの連続したtype-1ビットの両方が同一の割り当て予定のリソースユニットにおける割り振りを指示している場合には、ビットシーケンスは、複数(2つ以上の)type-4ビットをさらに含み、type-4ビットは、2つの連続した2番目に小さいリソースユニットの位置(2×26トーンリソースユニットの位置)が同一のリソースユニットに配分されているかどうかを指示するものである、ことをさらに含み得る。
異なる帯域幅においては、type-1ビットのみを含んでいてもよい。type-1ビット指示を除けば、他の方式は、すべてのリソースユニットの割り振りが指示されるまで、前述の指示原理に従ってリソースユニットの割り振りを指示するものであり得る。より大きな帯域幅については、より多くのビットがすべてのリソースユニットの割り振りを指示するために必要になることが理解できよう。
オプションとして、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースを指示する第1の指示情報をさらに含む。
一例として図7または図8に示した方式を使用すれば、第1の指示情報は、割り当て予定の周波数ドメインリソースが20MHzであり、ビットシーケンスが少なくとも4つのtype-1ビットを含むことを示す。各ビットは、左から右の順で配置された2つの1×26リソースユニットの位置に対応し、2つの1×26リソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを示すものである。
好ましくは、ソリューションは、type-4ビットをさらに含む。
4ビットのうちのビット#1およびビット#2が両方、2つの1×26リソースユニットが同一の割り当て予定のリソースユニットに配分されていることを指示している場合には、ビットシーケンスは、ビット#1およびビット#2に対応する2×26リソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示する、ビット#5をさらに含む、または、
4ビットのうちのビット#3およびビット#4が両方、2つの1×26リソースユニットが同一の割り当て予定のリソースユニットに配分されていることを指示している場合には、ビットシーケンスは、ビット#3およびビット#4に対応する2×26リソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示する、ビット#6をさらに含む。
加えて、4ビットのうちの2つの連続したビット(例えば、ビット#1およびビット#2、または、ビット#3およびビット#4)が、2つの1×26リソースユニットが同一の割り当て予定のリソースユニットに配分されていないことを指示している場合には、type-4ビットは必要ない。
異なる帯域幅において、type-1ビットを含み得ることは理解されよう。type-1ビット指示を除けば、他の方式は、前述の指示原理に従って他のリソースユニットの割り振りを指示するものであり得る。他のビットは、すべてのリソースユニットの割り振りが指示されるまで、割り振られた割り当て予定のリソースユニットが割り振られる可能性がある2つの連続した2番目に小さいリソースユニットの位置にあるかどうかを指示するものである。40MHz、80MHz、および160MHz帯域幅については、望ましい方式は、割り振られる可能性があるとともに割り当て予定の周波数ドメインリソースにおいてデフォルト位置(すなわち、デフォルトリソースユニットが位置する位置)の一方のサイド上に位置する2つの連続した最小のリソースユニット(1×26)の位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するのみである、または、割り振られた割り当て予定のリソースユニットが割り振られる可能性がある2つの連続した最小のリソースユニットの位置にあるか割り振られる可能性がある2つの連続した2番目に小さいリソースユニットの位置にあるかを指示するのみである。より大きなリソースユニットの位置については、他の可能な実施様態を指示のために使用する。
実施形態2
オプションとして、ビットシーケンスは、複数のtype-2ビットを含み、type-2ビットは、対称中心の一方のサイド上における最大のリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。
図9、図10、および図11を参照すれば、図9、図10、および図11は、割り振られた割り当て予定のリソースユニットを指示する、リソースユニット割り振り結果の簡略概略図および対応するビットシーケンスの概略図である。
様々な帯域幅(20MHz、40MHz、および80MHzのケースを図に別々に示しているが、これはまた、160MHzを含むとともに適用可能である)については、ビットシーケンスは、少なくとも複数の(2つ以上の)type-2ビットを含む。type-2ビットは、割り当て予定の周波数ドメインリソースが複数のユーザに割り振られている場合には、割り当て予定の周波数ドメインリソースにおける対称中心の一方のサイド上における最大のリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。前述の説明から分かるように、様々な帯域幅には、対称中心の一方のサイド上に位置する最大のリソースユニットの異なる位置が存在する。例えば、割り当て予定の周波数ドメインリソースが20MHzである場合には、割り振られる可能性がある最大のリソースユニットの位置は、4×26トーンリソースユニットの位置であり、別の例では、割り当て予定の周波数ドメインリソースが40MHzである場合には、割り振られる可能性がある最大のリソースユニットの位置は、242トーンリソースユニットの位置であり、別の例では、割り当て予定の周波数ドメインリソースが80MHzである場合には、割り振られる可能性がある最大のリソースユニットの位置は、2×242トーンリソースユニットの位置であり、別の例では、割り当て予定の周波数ドメインリソースが160MHzである場合には、割り振られる可能性がある最大のリソースユニットの位置は、996トーンリソースユニットの位置である。
オプションとして、方法は、割り振られる可能性がある最大のリソースユニットが実際の割り振りに存在しないことをあるtype-2ビットが指示している場合には、type-5ビットをさらに含む、ことをさらに含み得る。type-2ビットによって指示されるリソースユニットの位置の範囲において、type-5ビットは、対称中心の一方のサイド上に割り振られる可能性がある2番目に大きいリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。
異なる帯域幅においては、type-2ビットのみを含んでいてもよい。type-2ビット指示を除けば、他の方式は、他のリソースユニットの割り振りを指示するものであり得る。それはまた、前述の指示原理に従って、すべてのリソースユニットの割り振りが指示されるまで、3番目に大きいリソースユニットが実際に割り振られたリソースユニットであるかどうかを指示するために他のビットを使用してもよい。
40MHz、80MHz、および160MHzについては、望ましい方式は、対称中心の一方のサイド上に割り振られる可能性がある最大のリソースユニットが実際に割り振られたリソースユニットであるかどうかを指示するのみである、または、割り振られる可能性がある最大のリソースユニットおよび2番目に大きいリソースユニットの位置が実際に割り振られたリソースユニットであるかどうかを指示するのみであり、より小さいリソースユニットの位置については、他の可能な実施様態を指示のために使用してもよい。
オプションとして、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースを指示する第1の指示情報をさらに含む。
一例として図9に示した方式を使用すれば、第1の指示情報は、割り当て予定の周波数ドメインリソースが20MHzであることを指示している。ビットシーケンスは、少なくとも2ビット(すなわち、type-2ビットの例)を含み、少なくとも2ビットのうちビット#Aおよびのビット#Bは、20MHz帯域幅の対称中心(すなわち、20MHz帯域幅におけるデフォルト位置)の左サイドまたは右サイド上の4×26トーンリソースユニットの位置が実際に割り振られているかどうかをそれぞれ指示するものである。当然のことながら、ビット#Aは、右サイドを指示し得るし、ビット#Bは、左サイドを指示する。その原理は同一であるため再び説明はしない。
好ましくは、図9中の例は、以下のことをさらに含み得る。
type-2ビットのうちのビット#Aが、4×26トーンリソースユニットの位置が実際に割り振られていないことを指示している場合には、ビットシーケンスは、ビット#Cおよびビット#Dをさらに含み得る。ビット#Cは、ビット#Aに対応する前部の2×26トーンリソースユニットの位置が同一の割り当て予定のリソースユニット内に割り振られているかどうかを指示するものであり、ビット#Dは、割り振られた割り当て予定のリソースユニットがビット#Aに対応する後部の2×26トーンリソースユニットの位置に存在するかどうかを指示するものである、または、
type-2ビットのうちのビット#Bが、4×26トーンリソースユニットの位置が実際に割り振られていないことを指示している場合には、ビットシーケンスは、ビット#Eおよびビット#Fをさらに含む。ビット#Eは、ビット#Bに対応する前部の2×26トーンリソースユニットの位置が同一の割り当て予定のリソースユニット内に割り振られているかどうかを指示するものであり、ビット#Fは、ビット#Bに対応する後部の2×26トーンリソースユニットの位置が実際に割り振られているかどうかを指示するものである。
一例として図10に示した方式を使用すれば、第1の指示情報は、割り当て予定の周波数ドメインリソースが40MHzであることを指示している。ビットシーケンスは、少なくとも2ビット(すなわち、type-2ビットの別の例)を含み、少なくとも2ビットのうちのビット#A'およびビット#B'は、40MHz帯域幅の対称中心(すなわち、40MHz帯域幅における中心周波数)の左サイドまたは右サイド上の242トーンリソースユニットの位置が実際に割り振られているかどうかをそれぞれ指示するものである。当然のことながら、ビット#A'は、右サイドを指示し得るし、ビット#B'は、左サイドを指示する。その原理は同一であるため再び説明はしない。
242トーンリソースユニットの位置が実際に割り振られていない場合には、本実施様態に限定されないが、他の方式がまた、指示を継続するために使用され得る。
一例として図11に示した方式を使用すれば、第1の指示情報は、割り当て予定の周波数ドメインリソースが80MHzであることを指示している。ビットシーケンスは、少なくとも2ビット(すなわち、type-2ビットのさらに別の例)を含み、少なくとも2ビットのうちのビット#A''およびビット#B''は、80MHz帯域幅の対称中心(すなわち、80MHz帯域幅の中心におけるデフォルト位置)の左サイドまたは右サイド上の2×242トーンリソースユニットの位置が実際に割り振られているかどうかをそれぞれ指示するものである。当然のことながら、ビット#A''は、右サイドを指示し得るし、ビット#B''は、左サイドを指示する。その原理は同一であるため再び説明はしない。
2×242リソースユニットの位置が実際に割り振られていない場合には、本実施様態は、2×242リソースユニットの位置の範囲内の242リソースユニットの位置が実際に割り振られているかどうかを継続して指示するものであり得る。後続のリソースユニットについては、本実施様態に限定されないが、他の方式を指示のために継続して使用してもよい。
160MHzまたは他の帯域幅については、同様に、前述のソリューションを参照されたい。
実施形態3
オプションとして、ビットシーケンスは、2つのtype-3ビットを含み、2つのtype-3ビットは、1対1ベースで対称中心の双方のサイド上に位置する2つのリソースユニット位置グループに対応し、type-3ビットは、対応するリソースユニット位置グループ中のリソースユニットの位置にあるすべてのリソースユニットが割り当て予定のリソースユニットであるかどうかを指示するものであり、1つのリソースユニット位置グループは、割り当て予定の周波数ドメインリソースの中心の一方のサイド上に位置する複数の最小のリソースユニットの位置を含む。
図12および図13を参照すれば、図12および図13は、割り振られた割り当て予定のリソースユニットを指示する、リソースユニット割り振り結果の簡略概略図および対応するビットシーケンスの概略図である。
様々な帯域幅(20MHz、40MHz、および80MHzのケースのみを図に示しているが、これはまた、160MHzを含むとともに適用可能である)については、ビットシーケンスは、少なくとも複数のtype-3ビットを含む。いくつかのtype-3ビットは、割り振られる可能性があるとともに割り当て予定の周波数ドメインリソースにおいて対称中心(例えば、20MHz帯域幅におけるデフォルト位置、40MHz帯域幅における中心周波数、80MHz帯域幅の中心におけるデフォルト位置、または160MHz帯域幅における中心周波数)の一方のサイド上に位置する複数の最小のリソースユニットの位置にあるすべてのリソースユニットが割り振られた割り当て予定のリソースユニットであるかどうかを指示するものであり、残りのtype-3ビットは、割り振られる可能性があるとともに割り当て予定の周波数ドメインリソースにおけるデフォルト位置の残りの側上に位置する複数の最小のリソースユニットの位置にあるすべてのリソースユニットが割り振られた割り当て予定のリソースユニットであるかどうかをそれぞれ指示するものである。一般的に、各帯域幅における最小のリソースユニットのサイズは、1×26である。最小のリソースユニットの位置については、前述の詳細な説明を参照されたい。その詳細を本明細書では再び説明しない。
ここで、対称中心の一方のサイドは、リソースユニット位置グループを含み得る、または、各リソースユニット位置グループは、対称中心の一方のサイド上にデフォルト位置を除くすべての1×26リソースユニットの位置を含み得る、ここで、各1×26リソースユニットの位置は、1つのリソースユニット位置グループに属するおよびそれのみに属する。
オプションとして、方法は、あるtype-3ビットが、割り振られる可能性がある複数の最小のリソースユニットの位置にあるすべてのリソースユニットが割り振られた割り当て予定のリソースユニットではないことを指示している場合には、type-6ビットをさらに含む、ことをさらに含み得る。type-3ビットによって指示されるリソースユニットの位置の範囲において、type-6ビットは、割り振られる可能性がある複数の2番目に小さいリソースユニットの位置にあるすべてのリソースユニットが割り振られた割り当て予定のリソースユニットであるかどうかを指示するものである。
異なる帯域幅においては、type-3ビットのみを含んでいてもよい。type-3ビット指示を除けば、他の方式は、前述の指示原理に従って他のリソースユニットの割り振りを指示するものであり得る。他のビットは、すべてのリソースユニットの割り振りが指示されるまで、3番目に大きいリソースユニットが実際に割り振られたリソースユニットであるかどうかを指示するものである。40MHz、80MHz、および160MHzについては、望ましい方式は、割り振られる可能性がある最小のリソースユニットの位置が実際に割り振られたリソースユニットであるかどうかを指示するのみである、または、最小のリソースユニットの位置および2番目に小さいリソースユニットの位置が実際に割り振られたリソースユニットであるかどうかを指示するのみである。より大きなリソースユニットの位置については、他の可能な実施様態を指示のために使用する。
実施形態4
オプションとして、リソースユニット割り振りを指示する前述のビットシーケンスは、type-0ビットを含み、ビットは、割り振られる可能性があるとともに特定の帯域幅に対応する最大のリソースユニットの位置が実際に割り振られているかどうかを指示する、すなわち、ビットは、最大のリソースユニットがMU-MIMO伝送のために使用されていることを指示する。その後、他のリソース指示情報は、対応するステーションに割り振られる割り当て予定のリソースユニットを割り振るものである。割り振られる可能性があるとともに特定の帯域幅に対応する最大のリソースユニットの位置は、上述したように、例えば、20MHz帯域幅のための図4中の第4のレイヤ、40MHzのための図5中の第5のレイヤ、80MHzのための図6中の第6のレイヤ、または160MHzのための第7のレイヤである。
この場合には、type-0ビットが、現在の帯域幅から割り振られる可能性がある最大のリソースユニットが実際に割り振られたリソースユニットではないことを指示している場合には、その後、前述のtype-1ビット、type-2ビット、またはtype-3ビット、または、他のタイプのビットをリソースユニットの割り振りを指示するために含む必要があることは理解されよう。type-0ビットが、割り振られた割り当て予定のリソースユニットが現在の帯域幅に対応する最大のリソースユニットの位置にあることを指示している場合には、その後、他のビットシーケンスをリソースユニットの割り振りを指示するために含む必要はない。
加えて、同様の方式が異なる帯域幅のためのリソースユニットの割り振りを指示するために前述の実施形態における原理で使用されることに留意されたい。すなわち、40MHz、80MHz、および160MHz帯域幅については、前述の指示方法がその全体における指示のために使用される。
下記においては、前述の実施形態1、2、3、または4に基づいて前述のビットシーケンスを決定する方法およびプロセスを詳細に説明する。
オプションとして、送信端は、N個のマッピングルールを取得する、ここで、N個のマッピングルールは、1対1ベースでN個のプリセットサブキャリア数量に対応し、マッピングルールは、決定結果と指示識別子との間のマッピング関係を指示するものであり、決定結果は、マッピングルールに対応するプリセットサブキャリア数量と決定オブジェクトとの間の関係に基づいて取得され、N≧1であり、
割り当て予定の周波数ドメインリソースに含まれるM個の周波数ドメインリソースユニットをM個の受信端に割り振っている場合には、送信端は、決定オブジェクトとして各周波数ドメインリソースユニットに含まれるサブキャリアの数量を使用し、N個のマッピングルールに従って、各マッピングルール下で各周波数ドメインリソースユニットに対応する指示識別子を決定する、ここで、M個の周波数ドメインリソースユニットは、1対1ベースでM個の受信端に対応し、
送信端は、指示識別子に従ってビットシーケンスを決定する、ここで、ビットシーケンスは、割り当て予定の周波数ドメインリソースにおける各周波数ドメインリソースユニットに含まれるサブキャリアの数量および各周波数ドメインリソースユニットの位置を指示するものであり、
送信端は、受信端が、リソーススケジューリング情報に従って、受信端に対応する周波数ドメインリソースユニットを決定するために、ビットシーケンスを含むリソーススケジューリング情報を受信端に送信する。
オプションとして、プリセットサブキャリア数量をリソースユニットのタイプに従って決定する。
特に、本発明の本実施形態においては、プリセットサブキャリア数量をWLANシステム内のリソースユニットタイプの可能な数量に従って決定し得る。
オプションとして、送信端がN個のマッピングルールを取得することは、
割り当て予定の周波数ドメインリソースに含まれるサブキャリアの数量、プリセットサブキャリア数量の最小値、およびプリセットサブキャリア数量の最大値に従ってN個のマッピングルールを取得することを含む。
特に、本発明の本実施形態においては、プリセットルールは、割り当て予定の周波数ドメインリソースの帯域幅(すなわち、割り当て予定の周波数ドメインリソースに含まれるサブキャリアの数量(ここで、割り当て予定の周波数ドメインリソースに含まれるサブキャリアは、直流サブキャリアおよびサイドバンドガードサブキャリアを含んでおらず、以降繰り返しを避けるために、同一または同様のケースに関する説明は省略する))、前述のリソースサブユニットのサイズ(すなわち、プリセットサブキャリア数量の最小値)、および帯域幅においてリソースユニットに含まれるサブキャリアの数量の最大値(すなわち、プリセットサブキャリア数量の最大値)に従って決定され得る。
例えば、20MHz帯域幅の周波数ドメインリソースを使用する場合には、周波数ドメインリソースは、図4に示したリソースユニットの3つのタイプを含み得る。したがって、プリセットサブキャリア数量は、
1×26、2×26、および4×26であり得る。
別の例では、40MHz帯域幅の周波数ドメインリソースを使用する場合には、周波数ドメインリソースは、図5に示したリソースユニットの4つのタイプを含み得る。したがって、プリセットサブキャリア数量は、
1×26、2×26、4×26、および242であり得る。
別の例では、80MHz帯域幅の周波数ドメインリソースを使用する場合には、周波数ドメインリソースは、図6に示したリソースユニットの5つのタイプを含み得る。したがって、プリセットサブキャリア数量は、
1×26、2×26、4×26、242、および2×242であり得る。
別の例では、160MHz帯域幅の周波数ドメインリソースを使用する場合には、周波数ドメインリソースは、リソースユニットの6つのタイプを含み得るし、すなわち、プリセットサブキャリア数量は、
1×26、2×26、4×26、242、2×242、および996であり得る。
さらに、本発明の本実施形態においては、受信端も、プリセットサブキャリア数量を決定する同様の方法およびプロセスを使用してもよい。さらに、方法100の信頼性を保証するために、送信端および受信端によって決定されるプリセットサブキャリア数量が同一であることを保証すべきである。
プリセットサブキャリア数量を決定する方法を説明した上記は例にすぎず、本発明はそれに限定されないことを理解されたい。プリセットサブキャリア数量はまた、高位レイヤの管理デバイスによって送信端または受信端に指示され得る、または、ネットワーク管理者によって送信端または受信端に事前に設定され得る、または、送信端および受信端によって決定されるプリセットサブキャリア数量が同一であることを保証することができる限り、割り当て予定の周波数ドメインリソースの帯域幅に従って送信端または受信端によって直接決定され得る。このことは本発明において特に限定されない。
本発明の本実施形態においては、割り当て予定の周波数ドメインリソースにおける任意のリソースユニットの対応する指示識別子が、任意のマッピングルールのために取得され得る。すなわち、リソースユニットに含まれるサブキャリアの数量(または、リソースユニットのタイプ)とプリセットサブキャリア数量(または、プリセットサブキャリア数量に対応するリソースユニットのタイプ)との間の関係(例えば、大小関係)が決定され得るし、異なる関係は異なる指示識別子に対応し得る。
下記においては、マッピングルールのコンテンツおよび指示識別子を決定するための方法を詳細に説明する。
オプションとして、N個のマッピングルールに従って、各マッピングルール下で各リソースユニットに対応する指示識別子を決定することは、
各マッピングルールに対応するプリセットサブキャリア数量に基づいて、プリセット順序に従って、および、シーケンス内のN個のマッピングルールに従って、各マッピングルール下で各リソースユニットに対応する指示識別子を決定することを含む。
特に、本発明の本実施形態においては、ツリー方法は、プリセットサブキャリア数量の順序(例えば、降順または昇順)に従ってシーケンス内の各マッピングルール下で各リソースユニットの指示識別子を決定するものであり得る。
本発明の本実施形態においては、前述の決定したプリセットサブキャリア数量のためのマッピングルールとして、以下の3つのタイプを説明し得る。下記おいては、様々なマッピングルールおよび様々なマッピングルールに基づいた処理プロシージャを詳細に説明している。
α. Type-1マッピングルール(実施形態1に対応)
本発明の本実施形態においては、送信端は、プリセットサブキャリア数量の昇順で各マッピングルール下における各リソースユニットの識別子を決定し得る。
この場合には、type-1マッピングルール(理解および識別を容易にするために、マッピングルール#Aと以降示す)は、指定の周波数ドメイン位置に位置するリソースユニットのサイズ(すなわち、含まれているサブキャリアの数量)がマッピングルール#Aに対応するプリセットサブキャリア数量以上であるかどうかを決定するものとして記述され得る。yesと決定された場合には、マッピングルール#A下における周波数ドメイン位置の指示識別子は、1である。noと決定された場合には、マッピングルール#A下における周波数ドメイン位置の指示識別子は、0である。
換言すれば、プリセットサブキャリア数量の前述の順序は、図4から図7に示したレイヤの順序に対応するようになり得る、すなわち、送信端は、リソースユニットの前述の割り振りマップにおいてトップダウン順(すなわち、プリセットサブキャリア数量の昇順)で各レイヤに対応するマッピングルールを決定し得る。
すなわち、第Xのレイヤにおけるマッピングルール#Aは、指定の周波数ドメイン位置にある(1つまたは複数の)リソースユニットが第(X-1)のレイヤ(すなわち、第Xのレイヤの上位レイヤ)におけるリソースユニットのアグリゲーションによって形成されている場合には、マッピングルール#A下における周波数ドメイン位置の指示識別子は1である、または、指定の周波数ドメイン位置にある(1つまたは複数の)リソースユニットが第(X-1)のレイヤ(すなわち、第Xのレイヤの上位レイヤ)におけるリソースユニットのアグリゲーションによって形成されていない場合には、マッピングルール#A下における周波数ドメイン位置の指示識別子は0であるものとしてさらに記述され得る。
ここで、「アグリゲーション」は1つの上位レイヤにおける隣接リソースユニットのアグリゲーションのみであり得るものであって、2つの上位レイヤにおけるリソースユニットのアグリゲーションは存在しないことに特に留意すべきである。したがって、ビットは本ソリューションにおいてさらに圧縮され得る、すなわち、上位レイヤのアグリゲーションが不可能であることを指示するビットは省略され得る。例えば、1つの2×26および2つの1×26リソースユニットは、20MHz帯域幅における中心位置に位置する1×26トーンリソースユニット(すなわち、20MHz帯域幅の対称中心)の左サイド上にある。この場合には、上位レイヤにおけるリソースユニットは、4×26リソースユニットにアグリゲーションすることができず、したがって、対応する指示ビットは省略され得る。
図7は、type-1マッピングルールに基づいた決定プロセスの例のツリー図を示している。一例として20MHz帯域幅を有する割り当て予定の周波数ドメインリソースを使用すれば、割り当て予定の周波数ドメインリソースは、左から右の順に、2つの2×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#1およびリソースユニット#2と以降示す)、1つの1×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#0と以降示す)、および1つの4×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#3と以降示す)を含む。
20MHz帯域幅においては、帯域幅の真ん中の位置に位置する1つの1×26トーンリソースユニット(すなわち、リソースユニット#0)が常に存在しているため、リソースユニットが暗黙的に指示され得ることに留意されたい。したがって、方法100は、主に、リソースユニット#0を除く任意のリソースユニットに対応する指示識別子を決定することである。繰り返しを避けるために、同一または同様のケースに関する説明は以下では省略する。
当然のことながら、別の例においては、1ビットはまた、リソースユニット#0が利用可能であるかどうかを指示するものであり得る。
まず、図7に示したように、2×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#1と以降示す)が決定され、決定が左から右の順で行われる。
換言すれば、図4中の第2のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
送信端の決定プロセスにおいては、図4中の第2のレイヤにおける位置#1に対応するリソースユニットは、リソースユニット#1であり、リソースユニット#1に含まれるサブキャリアの数量は、2×26であり、プリセットルール#1に対応する決定条件を満たしている、すなわち、リソースユニット#1に含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量以上である。したがって、プリセットルール#1下における位置#1(または、リソースユニット#1)の指示識別子は、1である。換言すれば、リソースユニット#1は、2つ以上の2つの1×26リソースユニットのアグリゲーションによって形成される。したがって、プリセットルール#1下における位置#1(または、リソースユニット#1)の指示識別子は、1である。
図4中の第2のレイヤにおける位置#2に対応するリソースユニットは、リソースユニット#2であり、リソースユニット#2に含まれるサブキャリアの数量は、2×26であり、プリセットルール#1に対応する決定条件を満たしている、すなわち、リソースユニット#2に含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量以上である。したがって、プリセットルール#1下における位置#2(または、リソースユニット#2)の指示識別子は、1である。換言すれば、リソースユニット#2は、2つの1×26リソースユニットのアグリゲーションによって形成される。したがって、プリセットルール#1下における位置#2(または、リソースユニット#2)の指示識別子は、1である。
図4中の第2のレイヤにおける位置#3に対応するリソースユニットは、リソースユニット#3(すなわち、リソースユニット#3の一部)であり、リソースユニット#3に含まれるサブキャリアの数量は、4×26であり、プリセットルール#1に対応する決定条件を満たしている、すなわち、リソースユニット#3に含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量以上である。換言すれば、リソースユニット#3は、2つの1×26リソースユニットのアグリゲーションによって形成される。したがって、プリセットルール#1下における位置#3の指示識別子は、1である。
さらに、図4中の第2のレイヤにおける位置#4に対応するリソースユニットは、リソースユニット#3(すなわち、リソースユニット#3の一部)であり、リソースユニット#3に含まれるサブキャリアの数量は、4×26であり、プリセットルール#1に対応する決定条件を満たしている、すなわち、リソースユニット#3に含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量以上である。換言すれば、リソースユニット#3は、2つの1×26リソースユニットのアグリゲーションによって形成される。したがって、プリセットルール#1下における位置#4の指示識別子は、1である。
したがって、プリセットルール#1下におけるリソースユニット#3の指示識別子は、11である。
その後、図7に示したように、4×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#2と以降示す)が決定され、決定が左から右へと行われる。
換言すれば、図4中の第3のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
図4中の第3のレイヤにおける位置#5に対応するリソースユニットは、リソースユニット#1およびリソースユニット#2であり、リソースユニット#1およびリソースユニット#2に含まれるサブキャリアの数量は、2×26であり、プリセットルール#2に対応する決定条件を満たしていない、すなわち、リソースユニット#1およびリソースユニット#2に含まれるサブキャリアの数量は、プリセットルール#2に対応するプリセットサブキャリア数量未満である。したがって、プリセットルール#1下における位置#5(または、リソースユニット#1およびリソースユニット#2)の指示識別子は、0である。換言すれば、リソースユニット#1およびリソースユニット#2は、2つの2×26リソースユニットのアグリゲーションによって形成されていない。したがって、プリセットルール#2下における位置#5(または、リソースユニット#1およびリソースユニット#2)の指示識別子は0である、すなわち、ビット"0"は、プリセットルール#2下では、リソースユニット#1およびリソースユニット#2の指示識別子として使用される。
図4中の第3のレイヤにおける位置#6に対応するリソースユニットは、リソースユニット#3であり、リソースユニット#3に含まれるサブキャリアの数量は、4×26であり、プリセットルール#2に対応する決定条件を満たしている、すなわち、リソースユニット#2に含まれるサブキャリアの数量は、プリセットルール#2に対応するプリセットサブキャリア数量以上である。したがって、プリセットルール#2下における位置#6(または、リソースユニット#3)の指示識別子は、1である。換言すれば、リソースユニット#3は、2つの2×26リソースユニットのアグリゲーションによって形成される。したがって、プリセットルール#2下における位置#6(または、リソースユニット#3)の指示識別子は、1である。
type-1マッピングルールに基づいて図7に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、111101であり、従来技術におけるビットシーケンスを生成するための方法と比較して、3ビットのオーバーヘッドを使わずに済ますことができる。
それに対応するように、受信端の決定プロセスにおいては、ビットシーケンス中の最初の4ビットは、図4中の第2のレイヤにおける位置#1から位置#4における割り当て予定の周波数ドメインリソース内のリソースユニットの割り振りを指示する。
第1の指示識別子は、1である。したがって、受信端は、図4中の第2のレイヤにおける位置#1にあるリソースユニット(すなわち、リソースユニット#1)に含まれるサブキャリアの数量がプリセットルール#1に対応する決定条件を満たしている、すなわち、位置#1にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量(すなわち、2×26)以上である、と決定し得る。換言すれば、位置#1に位置するリソースユニットは、2つ以上の2つの1×26リソースユニットのアグリゲーションによって形成されている。
第2の指示識別子は、1である。したがって、受信端は、図4中の第2のレイヤにおける位置#2にあるリソースユニット(すなわち、リソースユニット#2)に含まれるサブキャリアの数量がプリセットルール#1に対応する決定条件を満たしている、すなわち、位置#2にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量(すなわち、2×26)以上である、と決定し得る。換言すれば、位置#2に位置するリソースユニットは、2つ以上の2つの1×26リソースユニットのアグリゲーションによって形成されている。
第3の指示識別子は、1である。したがって、受信端は、図4中の第2のレイヤにおける位置#3にあるリソースユニット(すなわち、リソースユニット#3)に含まれるサブキャリアの数量がプリセットルール#1に対応する決定条件を満たしている、すなわち、位置#3にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量(すなわち、2×26)以上である、と決定し得る。換言すれば、位置#3に位置するリソースユニットは、2つ以上の2つの1×26リソースユニットのアグリゲーションによって形成されている。
第4の指示識別子は、1である。したがって、受信端は、図4中の第2のレイヤにおける位置#4にあるリソースユニット(すなわち、リソースユニット#3)に含まれるサブキャリアの数量がプリセットルール#1に対応する決定条件を満たしている、すなわち、位置#4にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量(すなわち、2×26)以上である、と決定し得る。換言すれば、位置#4に位置するリソースユニットは、2つ以上の2つの1×26リソースユニットのアグリゲーションによって形成されている。
ビットシーケンス中の5番目のビットおよび6番目のビットは、図4中の第3のレイヤにおける位置#5および位置#6における割り当て予定の周波数ドメインリソース内のリソースユニットの割り振りを指示する。
第5の指示識別子は、0である。したがって、受信端は、図4中の第3のレイヤにおける位置#5にあるリソースユニット(すなわち、リソースユニット#1およびリソースユニット#2)に含まれるサブキャリアの数量がプリセットルール#2に対応する決定条件を満たしていない、すなわち、位置#5にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#2に対応するプリセットサブキャリア数量(すなわち、4×26)未満である、と決定し得る。換言すれば、位置#5に位置するリソースユニットは、2つの2×26リソースユニットのアグリゲーションによって形成されていない。
したがって、第1の指示識別子、第2の指示識別子、および第5の指示識別子を参照して、受信端は、位置#1に位置するリソースユニットおよび位置#2は、2つの2×26トーンリソースユニットであると決定することができる、すなわち、割り当て予定の周波数ドメインリソースがリソースユニット#1およびリソースユニット#2を含んでいると決定することができる。
第6の指示識別子は、1である。したがって、受信端は、図4中の第3のレイヤにおける位置#6にあるリソースユニット(すなわち、リソースユニット#3)に含まれるサブキャリアの数量がプリセットルール#2に対応する決定条件を満たしている、すなわち、位置#5にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#2に対応するプリセットサブキャリア数量(すなわち、4×26)以上である、と決定し得る。換言すれば、位置#5に位置するリソースユニットは、2つの2×26リソースユニットのアグリゲーションによって形成されている。
したがって、第3の指示識別子、第4の指示識別子、および第6の指示識別子を参照して、受信端は、位置#3に位置するリソースユニットおよび位置#4は、4×26トーンリソースユニットであると決定することができる、すなわち、割り当て予定の周波数ドメインリソースがリソースユニット#3を含んでいると決定することができる。
したがって、受信端は、割り当て予定の周波数ドメインリソースにおける1番目のリソースユニット(すなわち、リソースユニット#1)は、2×26トーンリソースユニットであり、割り当て予定の周波数ドメインリソースにおける2番目のリソースユニット(すなわち、リソースユニット#2)は、2×26トーンリソースユニットであり、割り当て予定の周波数ドメインリソースにおける3番目のリソースユニット(すなわち、リソースユニット#3)は、4×26トーンリソースユニットである、と決定し得る。
上述したように、受信端の決定プロセスは、送信端の決定プロセスとは逆のプロセスである。繰り返しを避けるために、以下では送信端の決定プロセスとは逆である受信端の決定プロセスに関する詳細な説明を省略する。
当然のことながら、前述の実施形態4を参照すれば、別のオプションの例においては、図7に示したリソースユニットの割り振りについては、まず、割り振られる可能性があるとともに現在の20MHz帯域幅に対応する最大のリソースユニットに含まれるサブキャリアの数量に従って決定が行われる、すなわち、242のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#22と以降示す)が決定され、決定がtype-0ビットの値を取得するために行われる。換言すれば、図4中の第4のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定がtype-0ビットの値を取得するために行われる。
特に、送信端の決定プロセスにおいては、図7に示したリソースユニットの割り振りは、リソースユニット#1、リソースユニット#2、リソースユニット#0、およびリソースユニット#3(図4中の第4のレイヤにおける全リソースユニット)であり、リソースユニットに含まれるサブキャリアの数量は、それぞれ、2×26、2×26、1×26、および4×26であり、プリセットルール#22に対応する決定条件を満たしていない、すなわち、リソースユニット#0、リソースユニット#1、リソースユニット#2、およびリソースユニット#3のうちのいずれか1つに含まれるサブキャリアの数量は、プリセットルール#22に対応するプリセットサブキャリア数量(すなわち、242)に等しくない。したがって、図4中のプリセットルール#22下における第4のレイヤの指示識別子は0であり、指示識別子はオプションである。すなわち、type-0ビットの値は0である。type-0ビットの値を取得した後に、前述のtype-1ビットの値が図7に示した方式に従って続けて取得される。
図8は、type-1マッピングルールに基づいた決定プロセスの別の例のツリー図を示している。一例として20MHz帯域幅を有する割り当て予定の周波数ドメインリソースを使用すれば、割り当て予定の周波数ドメインリソースは、左から右の順に、1つの2×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#1'と以降示す)、3つの1×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#2'、リソースユニット#3'、およびリソースユニット#0'と以降示す)、および1つの4×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#4'と以降示す)を含む。
20MHz帯域幅においては、帯域幅の中心位置に位置する1つの1×26トーンリソースユニット(すなわち、リソースユニット#0')が常に存在しているため、リソースユニットが暗黙的に指示され得ることに留意されたい。したがって、方法100は、主に、リソースユニット#0'を除く任意のリソースユニットに対応する指示識別子を決定することである。繰り返しを避けるために、同一または同様のケースに関する説明は以下では省略する。
まず、図8に示したように、2×26のプリセットサブキャリア数量に対応するプリセットルール(すなわち、プリセットルール#1)が決定され、決定が左から右の順で行われる。
換言すれば、図4中の第2のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
図4中の第2のレイヤにおける位置#1に対応するリソースユニットは、リソースユニット#1'であり、リソースユニット#1'に含まれるサブキャリアの数量は、2×26であり、プリセットルール#1に対応する決定条件を満たしている、すなわち、位置#1にあるリソースユニット(すなわち、リソースユニット#1')に含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量以上である。したがって、プリセットルール#1下における位置#1(または、リソースユニット#1')の指示識別子は、1である。換言すれば、リソースユニット#1は、2つの1×26リソースユニットのアグリゲーションによって形成される。したがって、プリセットルール#1下における位置#1(または、リソースユニット#1')の指示識別子は、1である。
図4中の第2のレイヤにおける位置#2に対応するリソースユニットは、リソースユニット#2'およびリソースユニット#3'であり、リソースユニット#2'およびリソースユニット#3'に含まれるサブキャリアの数量は、1×26であり、プリセットルール#1に対応する決定条件を満たしていない、すなわち、リソースユニット#2'およびリソースユニット#3'に含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量未満である。したがって、プリセットルール#1下における位置#2(または、リソースユニット#2'およびリソースユニット#3')の指示識別子は、0である。換言すれば、リソースユニット#2'およびリソースユニット#3'は、2つの1×26リソースユニットのアグリゲーションによって形成されていない。したがって、プリセットルール#1下における位置#2(または、リソースユニット#2'およびリソースユニット#3')の指示識別子は0である、すなわち、ビット"0"は、プリセットルール#1下では、リソースユニット#2'およびリソースユニット#3'の指示識別子として使用される。
図4中の第2のレイヤにおける位置#3に対応するリソースユニットは、リソースユニット#4'(すなわち、リソースユニット#4'の一部)であり、リソースユニット#4'に含まれるサブキャリアの数量は、4×26であり、プリセットルール#1に対応する決定条件を満たしている、すなわち、リソースユニット#4'に含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量以上である。換言すれば、リソースユニット#4'は、2つの1×26リソースユニットのアグリゲーションによって形成される。したがって、プリセットルール#1下における位置#3の指示識別子は、1である。
さらに、図4中の第2のレイヤにおける位置#4に対応するリソースユニットは、リソースユニット#4'(すなわち、リソースユニット#4'の一部)であり、リソースユニット#4'に含まれるサブキャリアの数量は、4×26であり、プリセットルール#1に対応する決定条件を満たしている、すなわち、リソースユニット#4'に含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量以上である。換言すれば、リソースユニット#4'は、2つの1×26リソースユニットのアグリゲーションによって形成される。したがって、プリセットルール#1下における位置#4の指示識別子は、1である。
したがって、プリセットルール#1下における位置#3および位置#4に位置するリソースユニット#4'の指示識別子は、11である。
その後、図8に示したように、4×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#2と以降示す)が決定され、決定が左から右へと行われる。
換言すれば、図4中の第3のレイヤにおけるリソースユニットの割り振りマップが決定基準として使用され、決定が左から右の順で行われる。
図4中の第3のレイヤにおける位置#5に対応するリソースユニットは、リソースユニット#1'、リソースユニット#2'、およびリソースユニット#3'であり、リソースユニット#1'、リソースユニット#2'、およびリソースユニット#3'に含まれるサブキャリアの数量のいずれも、プリセットルール#2に対応する決定条件を満たしている、すなわち、リソースユニット#1'、リソースユニット#2'、およびリソースユニット#3'に含まれるサブキャリアの数量のすべては、プリセットルール#2に対応するプリセットサブキャリア数量未満である。したがって、プリセットルール#2下における位置#5(または、リソースユニット#1'、リソースユニット#2'、およびリソースユニット#3')の指示識別子は、0である。換言すれば、リソースユニット#1'、リソースユニット#2'、およびリソースユニット#3'は、2つの2×26リソースユニットのアグリゲーションによって形成されていない。したがって、プリセットルール#2下におけるリソースユニット#1'、リソースユニット#2'、およびリソースユニット#3'の指示識別子は、0である。すなわち、ビット"0"は、プリセットルール#2下では、リソースユニット#1'、リソースユニット#2'、およびリソースユニット#3'の指示識別子として使用される。
加えて、図4中の第3のレイヤにおける位置#5にあるリソースユニットが1つの2×26リソースユニットおよび2つの1×26リソースユニットであるとルール1下で決定されるため、図4中の第3のレイヤにおける位置#5の割り振りは既に完了している。したがって、プリセットルール#2下におけるリソースユニット#1'、リソースユニット#2'、およびリソースユニット#3'の指示識別子も省略され得る。
図4中の第3のレイヤにおける位置#6に対応するリソースユニットは、リソースユニット#4'であり、リソースユニット#4'に含まれるサブキャリアの数量は、4×26であり、プリセットルール#2に対応する決定条件を満たしている、すなわち、リソースユニット#4'に含まれるサブキャリアの数量は、プリセットルール#2に対応するプリセットサブキャリア数量以上である。したがって、プリセットルール#2下における位置#6(または、リソースユニット#4')の指示識別子は、1である。換言すれば、リソースユニット#4'は、2つの2×26リソースユニットのアグリゲーションによって形成される。したがって、プリセットルール#2下におけるリソースユニット#4'の指示識別子は、1である。
すなわち、type-1マッピングルールに基づいて図8に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、101101または10111である。すなわち、従来技術におけるビットシーケンスを生成するための方法と比較して、3または4ビットのオーバーヘッドを使わずに済ますことができる。
当然のことながら、同様に、前述の実施形態4を参照すれば、別のオプションの例においては、図8に示したリソースユニットの割り振りについては、まず、割り振られる可能性があるとともに現在の20MHz帯域幅に対応する最大のリソースユニットに含まれるサブキャリアの数量に従って決定が行われる、すなわち、242のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#22と以降示す)が決定され、決定がtype-0ビットの値を取得するために行われる。換言すれば、図4中の第4のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定がtype-0ビットの値を取得するために行われる。
特に、送信端の決定プロセスにおいては、図8に示したリソースユニットの割り振りは、リソースユニット#1'、リソースユニット#2'、リソースユニット#3'、リソースユニット#0'、およびリソースユニット#4'であり、リソースユニットに含まれるサブキャリアの数量は、それぞれ、2×26、1×26、1×26、1×26、および4×26であり、プリセットルール#22に対応する決定条件を満たしていない、すなわち、リソースユニット#1'、リソースユニット#2'、リソースユニット#3'、リソースユニット#0'、およびリソースユニット#4'のうちのいずれか1つに含まれるサブキャリアの数量は、プリセットルール#22に対応するプリセットサブキャリア数量(すなわち、242)に等しくない。したがって、プリセットルール#22下における指示識別子は0であり、指示識別子はオプションである。すなわち、type-0ビットの値は0である。type-0ビットの値を取得した後に、前述のtype-1ビットの値が図8に示した方式に従って続けて取得される。
換言すれば、プリセットルール#22下におけるオプション指示識別子を含んでいる場合には、type-1マッピングルールに基づいて図8に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、0101101または010111であり、従来技術におけるビットシーケンスを生成するための方法と比較して、2または3ビットのオーバーヘッドを使わずに済ますことができる。オプションとして、デフォルトリソースユニットの位置が利用可能であるかどうかを指示する1ビットをさらに含み得る。
type-1マッピングルールおよびtype-1マッピングルールに基づいた処理プロシージャを図7および図8を参照して上記では説明している。type-2およびtype-3マッピングルールならびにtype-2およびtype-3マッピングルールに基づいた処理プロシージャを図9から図14を参照して以下に詳細に説明する。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を有し、
指示識別子に従ってビットシーケンスを決定することは、
割り当て予定の周波数ドメインリソースの対称中心に対する割り当て予定の周波数ドメインリソースにおける各リソースユニットの位置に従って配置順序を決定することと、
配置順序に基づくとともに指示識別子に従って、割り当て予定の周波数ドメインリソースを指示するビットシーケンスを決定することとを含む。
特に、図4から図6に示したように、各レイヤにおける20MHz帯域幅の周波数ドメインリソースのリソースユニットの割り振り(または、リソースユニットの位置)は、中心位置に位置する1×26トーンリソースサブユニットに対する対称性(すなわち、対称中心の例)があり、各レイヤにおける40MHz帯域幅の周波数ドメインリソースのリソースユニットの割り振りは、中心点に対する対称性(すなわち、対称中心の別の例)があり、各レイヤにおける80MHz帯域幅の周波数ドメインリソースのリソースユニットの割り振りは、中心位置に位置する1×26トーンリソースサブユニットに対する対称性(すなわち、対称中心のさらに別の例)があり、各レイヤにおける160MHz帯域幅の周波数ドメインリソースのリソースユニットの割り振りは、中心点に対する対称性(すなわち、対称中心のさらに別の例)がある。
本発明の本実施形態においては、送信端は、前述の対称性を使用して各マッピングルール下における各リソースユニットの識別子を決定し得る。
β. Type-2マッピングルール(実施形態2に対応)
本発明の本実施形態においては、送信端は、プリセットサブキャリア数量の降順で各マッピングルール下における各リソースユニットの識別子を決定し得る。
この場合には、type-2マッピングルール(理解および識別を容易にするために、マッピングルール#Bと以降示す)は、対称中心の左サイドまたは右サイド上の指定の周波数ドメイン位置に位置するリソースユニットのサイズ(すなわち、含まれているサブキャリアの数量)がマッピングルール#Bに対応するプリセットサブキャリア数量以上であるかどうかを決定するものとして記述され得る。yesと決定された場合には、マッピングルール#B下における周波数ドメイン位置の指示識別子は、1である。noと決定された場合には、マッピングルール#B下における周波数ドメイン位置の指示識別子は、0である。
換言すれば、プリセットサブキャリア数量の前述の順序は、図4から図6に示したレイヤの順序に対応するようになり得る、すなわち、送信端は、リソースユニットの前述の割り振りマップにおいてボトムアップ順(すなわち、プリセットサブキャリア数量の降順)で各レイヤに対応するマッピングルールを決定し得る。
図9は、type-2マッピングルールに基づいた決定プロセスの例のツリー図を示している。一例として20MHz帯域幅を有する割り当て予定の周波数ドメインリソースを使用すれば、割り当て予定の周波数ドメインリソースは、左から右の順に、2つの2×26トーンリソースユニット(すなわち、リソースユニット#1およびリソースユニット#2)、1つの1×26トーンリソースユニット(すなわち、リソースユニット#0)、および1つの4×26トーンリソースユニット(すなわち、リソースユニット#3)を含む。
同様に、20MHz帯域幅においては、帯域幅の真ん中の位置に位置する1つの1×26トーンリソースユニット(すなわち、リソースユニット#0)が常に存在しているため、リソースユニットが暗黙的に指示され得る。したがって、方法100は、主に、リソースユニット#0を除く任意のリソースユニットに対応する指示識別子を決定することである。
まず、図9に示したように、20MHz帯域幅におけるデフォルト位置の一方のサイド上に位置する最大のリソースユニットに含まれるサブキャリアの数量に従って決定が行われる、すなわち、4×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#3と以降示す)が決定され、決定が左から右の順で行われる。
換言すれば、図4中の第3のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
送信端の決定プロセスにおいては、図4中の第3のレイヤにおける位置#5に対応する(20MHzの対称中心の左サイド上の)リソースユニットは、リソースユニット#1およびリソースユニット#2であり、リソースユニット#1およびリソースユニット#2に含まれるサブキャリアの数量は、2×26であり、プリセットルール#3に対応する決定条件を満たしていない、すなわち、リソースユニット#1およびリソースユニット#2に含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量(すなわち、4×26)に等しくない。したがって、プリセットルール#3下における位置#1(または、リソースユニット#1およびリソースユニット#2)の指示識別子は、0である。
図4中の第3のレイヤにおける位置#6に対応する(すなわち、20MHzの対称中心の右サイド上の)リソースユニットは、リソースユニット#3であり、リソースユニット#3に含まれるサブキャリアの数量は、4×26であり、プリセットルール#3に対応する決定条件を満たしている、すなわち、リソースユニット#2に含まれるサブキャリアの数量は、プリセットルール#3に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#3下における位置#3(または、リソースユニット#3)の指示識別子は、1である。
ここで、20MHz帯域幅においては、対称中心の一方のサイド上の最大のリソースユニットのタイプが4×26RUである(242RUがシングルユーザ伝送のために1人のユーザに割り振られることは除く)ため、対称中心の右サイド上の周波数ドメインリソース、すなわち、位置#6(または、位置#3および位置#4)に対応する周波数ドメインリソースの割り振りは完了している。
その後、図9に示したように、2×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#4と以降示す)が決定され、決定が左から右へと行われる。
換言すれば、図4中の第2のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
図4中の第2のレイヤにおける位置#1に対応する(すなわち、10MHzの対称中心の左サイド上の)リソースユニットは、リソースユニット#1であり、リソースユニット#1に含まれるサブキャリアの数量は、2×26であり、プリセットルール#4に対応する決定条件を満たしている、すなわち、リソースユニット#1に含まれるサブキャリアの数量は、プリセットルール#4に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#4下における位置#1(または、リソースユニット#1)の指示識別子は、1である。
図4中の第2のレイヤにおける位置#2に対応する(すなわち、10MHzの対称中心の右サイド上の)リソースユニットは、リソースユニット#2であり、リソースユニット#2に含まれるサブキャリアの数量は、2×26であり、プリセットルール#4に対応する決定条件を満たしている、すなわち、リソースユニット#2に含まれるサブキャリアの数量は、プリセットルール#4に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#4下における位置#2(または、リソースユニット#2)の指示識別子は、1である。
したがって、対称中心の左サイド上の周波数ドメインリソース、すなわち、位置#5(または、位置#1および位置#2)に対応する周波数ドメインリソースの割り振りは完了している。
type-2マッピングルールに基づいて図9に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、0111であり、従来技術におけるビットシーケンスを生成するための方法と比較して、5ビットのオーバーヘッドを使わずに済ますことができる。
それに対応するように、受信端の決定プロセスにおいては、ビットシーケンス中の最初の2ビットは、図4中の第3のレイヤにおける位置#5および位置#6における割り当て予定の周波数ドメインリソース内のリソースユニットの割り振りを指示する。
第1の指示識別子は、1である。したがって、受信端は、図4中の第3のレイヤにおける位置#5にあるリソースユニット(すなわち、リソースユニット#1およびリソースユニット#2)に含まれるサブキャリアの数量がプリセットルール#3に対応する決定条件を満たしていない、すなわち、位置#5にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#3に対応するプリセットサブキャリア数量(すなわち、4×26)に等しくない、と決定し得る。換言すれば、位置#5に位置するリソースユニットは、4×26トーンリソースユニットではない。
第2の指示識別子は、1である。したがって、受信端は、図4中の第3のレイヤにおける位置#6にあるリソースユニット(すなわち、リソースユニット#3)に含まれるサブキャリアの数量がプリセットルール#3に対応する決定条件を満たしている、すなわち、位置#6にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#3に対応するプリセットサブキャリア数量(すなわち、4×26)と等しい、と決定し得る。
したがって、第2の指示識別子を参照して、受信端は、位置#6に位置するリソースユニットが4×26トーンリソースユニットであると決定することができる、すなわち、受信端は、対称中心の右サイド上のリソースユニットが4×26トーンリソースユニットであると決定することができる。したがって、対称中心の右サイド上に位置するリソースユニット#3(位置#3、位置#4、または位置#6)が決定され得る。
したがって、受信端は、ビットシーケンス中の3番目のビットおよび4番目のビットが図4中の第2のレイヤにおける位置#1および位置#2における割り当て予定の周波数ドメインリソース内のリソースユニットの割り振りを指示していると決定し得る。
第3の指示識別子は、1である。したがって、受信端は、図4中の第2のレイヤにおける位置#1にあるリソースユニット(すなわち、リソースユニット#1)に含まれるサブキャリアの数量がプリセットルール#4に対応する決定条件を満たしている、すなわち、位置#1にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#4に対応するプリセットサブキャリア数量(すなわち、2×26)と等しい、と決定し得る。換言すれば、位置#1に位置するリソースユニットは、2×26トーンリソースユニットである。
第4の指示識別子は、1である。したがって、受信端は、図4中の第2のレイヤにおける位置#2にあるリソースユニット(すなわち、リソースユニット#2)に含まれるサブキャリアの数量がプリセットルール#4に対応する決定条件を満たしている、すなわち、位置#2にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#4に対応するプリセットサブキャリア数量(すなわち、2×26)と等しい、と決定し得る。換言すれば、位置#2に位置するリソースユニットは、2×26トーンリソースユニットである。
したがって、第1の指示識別子、第3の指示識別子、および第4の指示識別子を参照して、受信端は、位置#1に位置するリソースユニットおよび位置#2は、2つの2×26トーンリソースユニットであると決定することができる、すなわち、割り当て予定の周波数ドメインリソースがリソースユニット#1およびリソースユニット#2を含んでいると決定することができる。
したがって、受信端は、割り当て予定の周波数ドメインリソースにおける1番目のリソースユニット(すなわち、リソースユニット#1)は、2×26トーンリソースユニットであり、割り当て予定の周波数ドメインリソースにおける2番目のリソースユニット(すなわち、リソースユニット#2)は、2×26トーンリソースユニットであり、割り当て予定の周波数ドメインリソースにおける3番目のリソースユニット(すなわち、リソースユニット#3)は、4×26トーンリソースユニットである、と決定し得る。
上述したように、受信端の決定プロセスは、送信端の決定プロセスとは逆のプロセスである。繰り返しを避けるために、以下では送信端の決定プロセスとは逆である受信端の決定プロセスに関する詳細な説明を省略する。
当然のことながら、同様に、前述の実施形態4を参照すれば、別のオプションの例においては、図9に示したリソースユニットの割り振りについては、まず、割り振られる可能性があるとともに20MHz帯域幅に対応する最大のリソースユニットに含まれるサブキャリアの数量に従って決定が行われる、すなわち、242のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#22と以降示す)が決定され、決定がtype-0ビットの値を取得するために行われる。換言すれば、図4中の第4のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定がtype-0ビットの値を取得するために行われる。
特に、送信端の決定プロセスにおいては、図9に示したリソースユニットの割り振りは、リソースユニット#1、リソースユニット#2、リソースユニット#0、およびリソースユニット#3であり、リソースユニットに含まれるサブキャリアの数量は、それぞれ、2×26、1×26、1×26、1×26、および4×26であり、プリセットルール#22に対応する決定条件を満たしていない、すなわち、リソースユニット#1、リソースユニット#2、リソースユニット#0、およびリソースユニット#3のうちのいずれか1つに含まれるサブキャリアの数量は、プリセットルール#22に対応するプリセットサブキャリア数量(すなわち、242)に等しくない。したがって、プリセットルール#22下における指示識別子は0であり、指示識別子はオプションである。すなわち、type-0ビットの値は0である。type-0ビットの値を取得した後に、前述のtype-2ビットの値が図9に示した方式に従って続けて取得される。
換言すれば、プリセットルール#22下におけるオプション指示識別子を含んでいる場合には、type-2マッピングルールに基づいて図9に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、00111であり、従来技術におけるビットシーケンスを生成するための方法と比較して、4ビットのオーバーヘッドを使わずに済ますことができる。オプションとして、デフォルトリソースユニットの位置が利用可能であるかどうかを指示する1ビットをさらに含み得る。
図10は、type-2マッピングルールに基づいた決定プロセスの別の例のツリー図を示している。一例として40MHz帯域幅を有する割り当て予定の周波数ドメインリソースを使用すれば、割り当て予定の周波数ドメインリソースは、左から右の順に、2つの2×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#1''およびリソースユニット#2''と以降示す)、1つの1×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#0''と以降示す)、1つの4×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#3''と以降示す)、および1つの4×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#4''と以降示す)を含む。
まず、図10に示したように、40MHz帯域幅における最大のリソースユニットに含まれるサブキャリアの数量を決定し、すなわち、242のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#7と以降示す)が決定され、決定が左から右の順で行われる。
換言すれば、図5中の第4のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
送信端の決定プロセスにおいては、図5中の第4のレイヤにおける位置#Aに対応する(すなわち、40MHzの対称中心の左サイド上の)リソースユニットは、リソースユニット#1''、リソースユニット#2''、リソースユニット#0''、およびリソースユニット#3''であり、リソースユニットに含まれるサブキャリアの数量は、242ではなく、プリセットルール#7に対応する決定条件を満たしていない、すなわち、リソースユニット#1''、リソースユニット#2''、リソースユニット#0''、およびリソースユニット#3''に含まれるサブキャリアの数量は、プリセットルール#7に対応するプリセットサブキャリア数量(すなわち、242)に等しくない。したがって、プリセットルール#7下における位置#A(または、リソースユニット#1''、リソースユニット#2''、リソースユニット#0''、およびリソースユニット#3'')の指示識別子は、0である。
図5中の第4のレイヤにおける位置#Bに対応する(すなわち、40MHzの対称中心の右サイド上の)リソースユニットは、リソースユニット#4''であり、リソースユニット#4''に含まれるサブキャリアの数量は、242であり、プリセットルール#7に対応する決定条件を満たしている、すなわち、リソースユニット#4''に含まれるサブキャリアの数量は、プリセットルール#7に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#7下における位置#B(または、リソースユニット#4'')の指示識別子は、1である。
ここで、40MHz帯域幅においては、最大のリソースユニットのタイプが242であるため、対称中心の右サイド上の周波数ドメインリソース、すなわち、位置#Bに対応する周波数ドメインリソースの割り振りは完了している。
その後、図10に示したように、対称中心の左サイド上で全体的に割り振られていない20MHz帯域幅の周波数ドメインリソースにおける、20MHz帯域幅における対称中心の一方のサイド上における最大のリソースユニットに含まれるサブキャリアの数量が決定される、すなわち、4×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#8と以降示す)が決定され、決定が左から右の順で行われる。
換言すれば、図5中の第3のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
送信端の決定プロセスにおいては、図5中の第3のレイヤにおける位置#Cに対応する(20MHzの対称中心の左サイド上の)リソースユニットは、リソースユニット#1''およびリソースユニット#2''であり、リソースユニット#1''およびリソースユニット#2''に含まれるサブキャリアの数量は、2×26であり、プリセットルール#8に対応する決定条件を満たしていない、すなわち、リソースユニット#1''およびリソースユニット#2''に含まれるサブキャリアの数量は、プリセットルール#8に対応するプリセットサブキャリア数量(すなわち、4×26)に等しくない。したがって、プリセットルール#8下における位置#C(または、リソースユニット#1''およびリソースユニット#2'')の指示識別子は、0である。
加えて、20MHz帯域幅においては、帯域幅の真ん中の位置に位置する1つの1×26トーンリソースユニット(すなわち、リソースユニット#0'')が常に存在しているため、リソースユニットが暗黙的に指示され得る。
図5中の第3のレイヤにおける位置#Dに対応する(すなわち、20MHzの対称中心の右サイド上の)リソースユニットは、リソースユニット#3''であり、リソースユニット#3''に含まれるサブキャリアの数量は、4×26であり、プリセットルール#8に対応する決定条件を満たしている、すなわち、リソースユニット#3''に含まれるサブキャリアの数量は、プリセットルール#8に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#8下における位置#D(または、リソースユニット#3'')の指示識別子は、1である。
ここで、20MHz帯域幅においては、最大のリソースユニットのタイプが4×26であるため、対称中心の右サイド上の周波数ドメインリソース、すなわち、位置#Dに対応する周波数ドメインリソースの割り振りは完了している。
その後、図10に示したように、2×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#9と以降示す)が決定され、決定が左から右へと行われる。
換言すれば、図5中の第2のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
図5中の第2のレイヤにおいては位置#Eに対応する(すなわち、10MHzの対称中心の左サイド上の)リソースユニットは、リソースユニット#1''であり、リソースユニット#1''に含まれるサブキャリアの数量は、2×26であり、プリセットルール#9に対応する決定条件を満たしている、すなわち、リソースユニット#1''に含まれるサブキャリアの数量は、プリセットルール#9に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#9下における位置#E(または、リソースユニット#1'')の指示識別子は、1である。
図5中の第2のレイヤにおける位置#Fに対応する(すなわち、10MHzの対称中心の右サイド上の)リソースユニットは、リソースユニット#2''であり、リソースユニット#2''に含まれるサブキャリアの数量は、2×26であり、プリセットルール#9に対応する決定条件を満たしている、すなわち、リソースユニット#2''に含まれるサブキャリアの数量は、プリセットルール#9に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#9下における位置#F(または、リソースユニット#2'')の指示識別子は、1である。
前述の説明においては、異なる帯域幅における処理に対応するために、プリセットルール#3とプリセットルール#8とを、同様に、プリセットルール#4とプリセットルール#9とを区別するために異なるマークを使用している、ただし、プリセットルールに対応するプリセットサブキャリア数量は同一であることに留意されたい。
type-1マッピングルールに基づいて図10に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、010111であり、従来技術におけるビットシーケンスを生成するための方法と比較して、12ビットのオーバーヘッドを使わずに済ますことができる。
当然のことながら、同様に、前述の実施形態4を参照すれば、別のオプションの例においては、図10に示したリソースユニットの割り振りについては、まず、割り振られる可能性があるとともに40MHz帯域幅に対応する最大のリソースユニットに含まれるサブキャリアの数量に従って決定が行われる、すなわち、484のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#23と以降示す)が決定され、決定がtype-0ビットの値を取得するために行われる。換言すれば、図5中の第5のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定がtype-0ビットの値を取得するために行われる。
特に、送信端の決定プロセスにおいては、図10に示したリソースユニットの割り振りは、リソースユニット#1''、リソースユニット#2''、リソースユニット#0''、リソースユニット#3''、およびリソースユニット#4''であり、リソースユニットに含まれるサブキャリアの数量は、それぞれ、2×26、2×26、1×26、4×26、および242であり、プリセットルール#22に対応する決定条件を満たしていない、すなわち、リソースユニット#1''、リソースユニット#2''、リソースユニット#0''、リソースユニット#3''、およびリソースユニット#4''のうちのいずれか1つに含まれるサブキャリアの数量は、プリセットルール#23に対応するプリセットサブキャリア数量(すなわち、484)に等しくない。したがって、プリセットルール#23下における指示識別子は0であり、指示識別子はオプションである。すなわち、type-0ビットの値は0である。type-0ビットの値を取得した後に、前述のtype-2ビットの値が図10に示した方式に従って続けて取得される。
換言すれば、プリセットルール#23下におけるオプション指示識別子を含んでいる場合には、type-2マッピングルールに基づいて図10に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、0010111であり、従来技術におけるビットシーケンスを生成するための方法と比較して、11ビットのオーバーヘッドを使わずに済ますことができる。オプションとして、2つのデフォルトリソースユニットの位置が利用可能であるかどうかを指示する2ビットをさらに含み得る。
図11は、type-2マッピングルールに基づいた決定プロセスのさらに別の例のツリー図を示している。一例として80MHz帯域幅を有する割り当て予定の周波数ドメインリソースを使用すれば、割り当て予定の周波数ドメインリソースは、左から右の順に、1つの4×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#1'''と以降示す)、1つの1×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#0'''と以降示す)、1つの4×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#2'''と以降示す)、1つの242トーンリソースユニット(理解および識別を容易にするために、リソースユニット#3'''と以降示す)、1つの1×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#00'''と以降示す)、および1つの2×242トーンリソースユニット(理解および識別を容易にするために、リソースユニット#4'''と以降示す)を含む。
まず、図11に示したように、80MHz帯域幅における対称中心の一方のサイド上に位置する最大のリソースユニットに含まれるサブキャリアの数量が決定される、すなわち、2×242のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#10と以降示す)が決定され、決定が左から右の順で行われる。
換言すれば、図6中の第5のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
送信端の決定プロセスにおいては、図6中の第5のレイヤにおける位置#aに対応する(すなわち、80MHzの対称中心におけるリソースユニット#00の左サイド上の)リソースユニットは、リソースユニット#1'''、リソースユニット#0'''、リソースユニット#2'''、およびリソースユニット#3'''であり、リソースユニットに含まれるサブキャリアの数量は、2×242ではなく、プリセットルール#10に対応する決定条件を満たしていない、すなわち、リソースユニット#1'''、リソースユニット#0'''、リソースユニット#2'''、およびリソースユニット#3''に含まれるサブキャリアの数量は、プリセットルール#10に対応するプリセットサブキャリア数量(すなわち、2×242)に等しくない。したがって、プリセットルール#10下における位置#A(または、リソースユニット#1'''、リソースユニット#0'''、リソースユニット#2'''、およびリソースユニット#3'')の指示識別子は、0である。
加えて、80MHz帯域幅においては、帯域幅の真ん中の位置に位置する1つの1×26トーンリソースユニット(すなわち、リソースユニット#00''')が常に存在しているため、リソースユニットが暗黙的に指示され得る。
図6中の第5のレイヤにおける位置#bに対応する(すなわち、80MHzの対称中心におけるリソースユニット#00''の右サイド上の)リソースユニットは、リソースユニット#4'''であり、リソースユニット#4'''に含まれるサブキャリアの数量は、2×242であり、プリセットルール#10に対応する決定条件を満たしている、すなわち、リソースユニット#4'''に含まれるサブキャリアの数量は、プリセットルール#10に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#10下における位置#b(または、リソースユニット#4''')の指示識別子は、1である。
ここで、80MHz帯域幅においては、最大のリソースユニットのタイプが2×242であるため、対称中心の右サイド上の周波数ドメインリソース、すなわち、位置#bに対応する周波数ドメインリソースの割り振りは完了している。
その後、図11に示したように、対称中心の左サイド上で全体的に割り振られていない40MHz帯域幅の周波数ドメインリソースにおける、40MHz帯域幅における最大のリソースユニットに含まれるサブキャリアの数量が決定される、すなわち、242のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#11と以降示す)が決定され、決定が左から右の順で行われる。
換言すれば、図6中の第4のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
送信端の決定プロセスにおいては、図6中の第4のレイヤにおける位置#cに対応する(すなわち、40MHzの対称中心の左サイド上の)リソースユニットは、リソースユニット#1'''、リソースユニット#0'''、およびリソースユニット#2'''であり、リソースユニットに含まれるサブキャリアの数量は、242ではなく、プリセットルール#11に対応する決定条件を満たしていない、すなわち、リソースユニット#1'''、リソースユニット#0'''、およびリソースユニット#2'''に含まれるサブキャリアの数量は、プリセットルール#11に対応するプリセットサブキャリア数量(すなわち、242)に等しくない。したがって、プリセットルール#11下における位置#c(または、リソースユニット#1'''、リソースユニット#0'''、およびリソースユニット#2''')の指示識別子は、0である。
図6中の第4のレイヤにおける位置#dに対応する(すなわち、40MHzの対称中心の右サイド上の)リソースユニットは、リソースユニット#3'''であり、リソースユニット#3'''に含まれるサブキャリアの数量は、242であり、プリセットルール#11に対応する決定条件を満たしている、すなわち、リソースユニット#3'''に含まれるサブキャリアの数量は、プリセットルール#11に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#11下における位置#d(または、リソースユニット#3''')の指示識別子は、1である。
ここで、40MHz帯域幅においては、最大のリソースユニットのタイプが242であるため、対称中心の右サイド上の周波数ドメインリソース、すなわち、位置#dに対応する周波数ドメインリソースの割り振りは完了している。
その後、図11に示したように、4×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#12と以降示す)が決定され、決定が左から右へと行われる。
換言すれば、図6中の第3のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
図6中の第3のレイヤにおける位置#eに対応する(すなわち、20MHzの対称中心の左サイド上の)リソースユニットは、リソースユニット#1'''であり、リソースユニット#1'''に含まれるサブキャリアの数量は、4×26であり、プリセットルール#12に対応する決定条件を満たしている、すなわち、リソースユニット#1'''に含まれるサブキャリアの数量は、プリセットルール#12に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#12下における位置#e(または、リソースユニット#1''')の指示識別子は、1である。
加えて、20MHz帯域幅においては、帯域幅の真ん中の位置に位置する1つの1×26トーンリソースユニット(すなわち、リソースユニット#0''')が常に存在しているため、リソースユニットが暗黙的に指示され得る。
図6中の第3のレイヤにおける位置#fに対応する(すなわち、20MHzの対称中心の右サイド上の)リソースユニットは、リソースユニット#2'''であり、リソースユニット#2'''に含まれるサブキャリアの数量は、4×26であり、プリセットルール#12に対応する決定条件を満たしている、すなわち、リソースユニット#2'''に含まれるサブキャリアの数量は、プリセットルール#12に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#12下における位置#f(または、リソースユニット#2''')の指示識別子は、1である。
ここで、20MHz帯域幅においては、最大のリソースユニットのタイプが4×26であるため、対称中心の左サイドおよび右サイド上の周波数ドメインリソース、すなわち、位置#eおよび位置#fに対応する周波数ドメインリソースの割り振りは完了している。
前述の説明においては、異なる帯域幅における処理に対応するために、プリセットルール#3とプリセットルール#8とを、同様に、プリセットルール#4とプリセットルール#9とを区別するために異なるマークを使用している、ただし、プリセットルールに対応するプリセットサブキャリア数量は同一であることに留意されたい。
type-1マッピングルールに基づいて図11に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、010111であり、従来技術におけるビットシーケンスを生成するための方法と比較して、31ビットのオーバーヘッドを使わずに済ますことができる。
当然のことながら、同様に、前述の実施形態4を参照すれば、別のオプションの例においては、図10に示したリソースユニットの割り振りについては、まず、割り振られる可能性があるとともに80MHz帯域幅に対応する最大のリソースユニットに含まれるサブキャリアの数量に従って決定が行われる、すなわち、996のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#24と以降示す)が決定され、決定がtype-0ビットの値を取得するために行われる。換言すれば、図6中の第6のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定がtype-0ビットの値を取得するために行われる。
特に、送信端の決定プロセスにおいては、図11に示したリソースユニットの割り振りは、リソースユニット#1''、リソースユニット#0''、リソースユニット#2''、リソースユニット#3''、リソースユニット#00''、およびリソースユニット#4''であり、リソースユニットに含まれるサブキャリアの数量は、それぞれ、4×26、1×26、4×26、242、1×26、および2×242であり、プリセットルール#24に対応する決定条件を満たしていない、すなわち、リソースユニット#1''、リソースユニット#0''、リソースユニット#2''、リソースユニット#3''、リソースユニット#00''、およびリソースユニット#4''のうちのいずれか1つに含まれるサブキャリアの数量は、プリセットルール#24に対応するプリセットサブキャリア数量(すなわち、996)に等しくない。したがって、プリセットルール#24下における指示識別子は0であり、指示識別子はオプションである。すなわち、type-0ビットの値は0である。type-0ビットの値を取得した後に、前述のtype-2ビットの値が図11に示した方式に従って続けて取得される。
換言すれば、プリセットルール#24下におけるオプション指示識別子を含んでいる場合には、type-2マッピングルールに基づいて図11に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、0010111であり、従来技術におけるビットシーケンスを生成するための方法と比較して、30ビットのオーバーヘッドを使わずに済ますことができる。オプションとして、5つのデフォルトリソースユニットの位置が利用可能であるかどうかを指示する5ビットをさらに含み得る。
大きな帯域幅(20MHzより大きい)については、図10および図11に対応する実施形態の方法はまた、最小粒度の20Mの帯域幅を指示するためだけに適用可能であり得る、すなわち、他の方法は、20Mの帯域幅内でのリソース割り振りを指示するためのものであり得る。この場合には、図10中の対応する破線ボックスを除去してもよく、type-1マッピングルールに基づいて図10中の割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、01である。図11中の対応する破線ボックスを除去してもよく、type-1マッピングルールに基づいて図11中の割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、0101である。
γ. type-3マッピングルール(実施形態3に対応)
本発明の本実施形態においては、送信端は、プリセットサブキャリア数量の昇順で各マッピングルール下における各リソースユニットの識別子を決定し得る。
この場合には、type-3マッピングルール(理解および識別を容易にするために、マッピングルール#Cと以降示す)は、対称中心の左サイドまたは右サイド上の指定の周波数ドメイン位置に位置するリソースユニットのサイズ(すなわち、含まれているサブキャリアの数量)がマッピングルール#Cに対応するプリセットサブキャリア数量以上であるかどうかを決定するものとして記述され得る。yesと決定された場合には、マッピングルール#C下における周波数ドメイン位置の指示識別子は、1である。noと決定された場合には、マッピングルール#C下における周波数ドメイン位置の指示識別子は、0である。
換言すれば、プリセットサブキャリア数量の前述の順序は、図4から図6に示したレイヤの順序に対応するようになり得る、すなわち、送信端は、リソースユニットの前述の割り振りマップにおいてボトムアップ順(すなわち、プリセットサブキャリア数量の昇順)で各レイヤに対応するマッピングルールを決定し得る。
図12は、type-3マッピングルールに基づいた決定プロセスの例のツリー図を示している。一例として20MHz帯域幅を有する割り当て予定の周波数ドメインリソースを使用すれば、割り当て予定の周波数ドメインリソースは、左から右の順に、2つの2×26トーンリソースユニット(すなわち、リソースユニット#1およびリソースユニット#2)、1つの1×26トーンリソースユニット(すなわち、リソースユニット#0)、および1つの4×26トーンリソースユニット(すなわち、リソースユニット#3)を含む。
20MHz帯域幅においては、帯域幅の真ん中の位置に位置する1つの1×26トーンリソースユニット(すなわち、リソースユニット#0)が常に存在しているため、リソースユニットが暗黙的に指示され得ることに留意されたい。したがって、方法100は、主に、リソースユニット#0を除く任意のリソースユニットに対応する指示識別子を決定することである。繰り返しを避けるために、同一または同様のケースに関する説明は以下では省略する。
まず、図12に示したように、1×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#5と以降示す)が決定され、決定が左から右の順で行われる。
換言すれば、図4中の第1のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
送信端の決定プロセスにおいては、まず、割り当て予定の周波数ドメインリソースの対称中心の左サイド(すなわち、図4中の位置#7から位置#10に対応)上のリソースユニット(すなわち、リソースユニット#1およびリソースユニット#2)のサイズがすべて1×26であるかどうかを決定する。リソースユニット#1およびリソースユニット#2に含まれるサブキャリアの数量は、2×26であり、プリセットルール#5に対応する決定条件を満たしていない、すなわち、リソースユニット#1およびリソースユニット#2に含まれるサブキャリアの数量は両方、プリセットルール#5に対応するプリセットサブキャリア数量に等しくないため、プリセットルール#5下における図4中の位置#7から位置#10(または、リソースユニット#1およびリソースユニット#2)の指示識別子は、0である。
その後、割り当て予定の周波数ドメインリソースの対称中心の右サイド(すなわち、図4中の位置#11から位置#14に対応)上のリソースユニット(すなわち、リソースユニット#3)のサイズがすべて1×26であるかどうかを決定する。リソースユニット#3に含まれるサブキャリアの数量は、4×26であり、プリセットルール#5に対応する決定条件を満たしていない、すなわち、リソースユニット#3に含まれるサブキャリアの数量は、プリセットルール#5に対応するプリセットサブキャリア数量に等しくないため、プリセットルール#5下における図4中の位置#11から位置#14(または、リソースユニット#3)の指示識別子は、0である。
その後、図12に示したように、2×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#6と以降示す)が決定され、決定が左から右へと行われる。
換言すれば、図4中の第2のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
図4中の第2のレイヤにおける位置#1に対応するリソースユニットは、リソースユニット#1であり、リソースユニット#1に含まれるサブキャリアの数量は、2×26であり、プリセットルール#6に対応する決定条件を満たしている、すなわち、リソースユニット#1に含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#6下における位置#1(または、リソースユニット#1)の指示識別子は、1である。
図4中の第2のレイヤにおける位置#2に対応するリソースユニットは、リソースユニット#2であり、リソースユニット#2に含まれるサブキャリアの数量は、2×26であり、プリセットルール#6に対応する決定条件を満たしている、すなわち、リソースユニット#2に含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#6下における位置#2(または、リソースユニット#2)の指示識別子は、1である。
図4中の第2のレイヤにおける位置#3に対応するリソースユニットは、リソースユニット#3であり、リソースユニット#3に含まれるサブキャリアの数量は、4×26であり、プリセットルール#6に対応する決定条件を満たしていない、すなわち、リソースユニット#3に含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量に等しくない。したがって、プリセットルール#6下における位置#3の指示識別子は、0である。
図4中の第2のレイヤにおける位置#4に対応するリソースユニットは、リソースユニット#3であり、リソースユニット#3に含まれるサブキャリアの数量は、4×26であり、プリセットルール#6に対応する決定条件を満たしていない、すなわち、リソースユニット#4に含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量に等しくない。したがって、プリセットルール#6下における位置#4の指示識別子は、0である。
すなわち、プリセットルール#6下におけるリソースユニット#3の指示識別子は、00である。
20MHz帯域幅の周波数ドメインリソースについては、図4に示したケースのみが、周波数ドメインリソースの対称中心のどちらかの側上のリソースユニットの割り振りにおいて存在している。したがって、位置#11から位置#14に対応する指示識別子が0である場合には、位置#4に対応する指示識別子は0であり、位置#6に対応するリソースユニット(すなわち、リソースユニット#3)が4×26トーンリソースユニットであると決定することができる。
type-3マッピングルールに基づいて図12に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、001100であり、従来技術におけるビットシーケンスを生成するための方法と比較して、3ビットのオーバーヘッドを使わずに済ますことができる。
それに対応するように、受信端の決定プロセスにおいては、ビットシーケンス中の1番目のビットは、図4中の第1のレイヤにおける位置#7から位置#10における割り当て予定の周波数ドメインリソース内のリソースユニットの割り振りを指示する。
第1の指示識別子は、0である。したがって、受信端は、図4中の第1のレイヤにおける位置#7から位置#10にあるリソースユニット(すなわち、リソースユニット#1およびリソースユニット#2)に含まれるサブキャリアの数量がプリセットルール#5に対応する決定条件を満たしていない、すなわち、位置#7から位置#10にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#5に対応するプリセットサブキャリア数量(すなわち、1×26)とすべて等しくない、と決定し得る。
第2の指示識別子は、0である。したがって、受信端は、図4中の第1のレイヤにおける位置#11から位置#14にあるリソースユニット(すなわち、リソースユニット#3)に含まれるサブキャリアの数量がプリセットルール#5に対応する決定条件を満たしていない、すなわち、位置#11から位置#14にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#5に対応するプリセットサブキャリア数量(すなわち、1×26)に等しくない、と決定し得る。
第3の指示識別子は、1である。したがって、受信端は、図4中の第2のレイヤにおける位置#1にあるリソースユニット(すなわち、リソースユニット#1)に含まれるサブキャリアの数量がプリセットルール#6に対応する決定条件を満たしている、すなわち、位置#1にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量(すなわち、2×26)と等しい、と決定し得る。
したがって、第1の指示識別子および第3の指示識別子を参照して、受信端は、左から1番目のリソースユニット、または、周波数ドメインリソースにおける位置#1にあるリソースユニット(すなわち、リソースユニット#1)のサイズが2×26であると決定することができる。
第4の指示識別子は、1である。したがって、受信端は、図4中の第2のレイヤにおける位置#2にあるリソースユニット(すなわち、リソースユニット#2)に含まれるサブキャリアの数量がプリセットルール#6に対応する決定条件を満たしている、すなわち、位置#2にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量(すなわち、2×26)と等しい、と決定し得る。
したがって、第1の指示識別子および第4の指示識別子を参照して、受信端は、左から2番目のリソースユニット、または、周波数ドメインリソースにおける位置#2にあるリソースユニット(すなわち、リソースユニット#1)のサイズが2×26であると決定することができる。
第5の指示識別子は、0である。したがって、受信端は、図4中の第2のレイヤにおける位置#3にあるリソースユニット(すなわち、リソースユニット#3)に含まれるサブキャリアの数量がプリセットルール#6に対応する決定条件を満たしていない、すなわち、位置#3にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量(すなわち、2×26)に等しくない、と決定し得る。
第6の指示識別子は、0である。したがって、受信端は、図4中の第2のレイヤにおける位置#3にあるリソースユニット(すなわち、リソースユニット#3)に含まれるサブキャリアの数量がプリセットルール#6に対応する決定条件を満たしていない、すなわち、位置#3にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量(すなわち、2×26)に等しくない、と決定し得る。
したがって、第1の指示識別子、第5の指示識別子、および第6の指示識別子を参照して、受信端は、左から4番目のリソースユニット、または、周波数ドメインリソースにおける位置#3および位置#4にあるリソースユニット(すなわち、リソースユニット#3)のサイズが4×26であると決定することができる。
上述したように、受信端の決定プロセスは、送信端の決定プロセスとは逆のプロセスである。繰り返しを避けるために、以下では送信端の決定プロセスとは逆である受信端の決定プロセスに関する詳細な説明を省略する。
図13は、type-3マッピングルールに基づいた決定プロセスの別の例のツリー図を示している。一例として20MHz帯域幅を有する割り当て予定の周波数ドメインリソースを使用すれば、割り当て予定の周波数ドメインリソースは、左から右の順に、1つの2×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#1'と以降示す)、3つの1×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#2'、リソースユニット#3'、およびリソースユニット#0'と以降示す)、および1つの4×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#4'と以降示す)を含む。
20MHz帯域幅においては、帯域幅の中心位置に位置する1つの1×26トーンリソースユニット(すなわち、リソースユニット#0')が常に存在しているため、リソースユニットが暗黙的に指示され得ることに留意されたい。したがって、方法100は、主に、リソースユニット#0'を除く任意のリソースユニットに対応する指示識別子を決定することである。繰り返しを避けるために、同一または同様のケースに関する説明は以下では省略する。
まず、図13に示したように、1×26のプリセットサブキャリア数量に対応するプリセットルール(すなわち、プリセットルール#5)が決定され、決定が左から右の順で行われる。
換言すれば、図4中の第1のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
送信端の決定プロセスにおいては、まず、割り当て予定の周波数ドメインリソースの対称中心の左サイド(すなわち、図4中の位置#7から位置#10に対応)上のリソースユニット(すなわち、リソースユニット#1'、リソースユニット#2'、およびリソースユニット#3')のサイズがすべて1×26であるかどうかを決定する。リソースユニット#1'に含まれるサブキャリアの数量が2×26であるため、対称中心の左サイド上に位置するリソースユニットは、プリセットルール#6に対応する決定条件を満たしていない。したがって、プリセットルール#5下における図4中の位置#7から位置#10(または、リソースユニット#1'、リソースユニット#2'、およびリソースユニット#3')の指示識別子は、0である。
その後、割り当て予定の周波数ドメインリソースの対称中心の右サイド(すなわち、図4中の位置#11から位置#14に対応)上のリソースユニット(すなわち、リソースユニット#3')のサイズがすべて1×26であるかどうかを決定する。リソースユニット#3'に含まれるサブキャリアの数量は、4×26であり、プリセットルール#5に対応する決定条件を満たしていないため、プリセットルール#5下における図4中の位置#11から位置#14(または、リソースユニット#3')の指示識別子は、0である。
その後、図13に示したように、2×26のプリセットサブキャリア数量に対応するプリセットルール(すなわち、プリセットルール#6)が決定され、決定が左から右へと行われる。
換言すれば、図4中の第2のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
図4中の第2のレイヤにおける位置#1に対応するリソースユニットは、リソースユニット#1'であり、リソースユニット#1'に含まれるサブキャリアの数量は、2×26であり、プリセットルール#6に対応する決定条件を満たしている、すなわち、リソースユニット#1に含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#6下における位置#1(または、リソースユニット#1)の指示識別子は、1である。
図4中の第2のレイヤにおける位置#2に対応するリソースユニットは、リソースユニット#2'およびリソースユニット#3'であり、リソースユニット#2'およびリソースユニット#3'に含まれるサブキャリアの数量は、1×26であり、プリセットルール#6に対応する決定条件を満たしていない、すなわち、リソースユニット#2'およびリソースユニット#3'に含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量に等しくない。したがって、プリセットルール#6下における位置#2(または、リソースユニット#2'およびリソースユニット#3')の指示識別子は、0である。
図4中の第2のレイヤにおける位置#3に対応するリソースユニットは、リソースユニット#3であり、リソースユニット#3に含まれるサブキャリアの数量は、4×26であり、プリセットルール#6に対応する決定条件を満たしていない、すなわち、リソースユニット#3に含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量に等しくない。したがって、プリセットルール#6下における位置#3の指示識別子は、0である。
図4中の第2のレイヤにおける位置#4に対応するリソースユニットは、リソースユニット#3であり、リソースユニット#3に含まれるサブキャリアの数量は、4×26であり、プリセットルール#6に対応する決定条件を満たしていない、すなわち、リソースユニット#4に含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#6下における位置#4の指示識別子は、0である。
すなわち、プリセットルール#6下におけるリソースユニット#3の指示識別子は、00である。
20MHz帯域幅の周波数ドメインリソースについては、図4に示したケースのみが、周波数ドメインリソースの対称中心のどちらかの側上のリソースユニットの割り振りにおいて存在している。したがって、位置#11から位置#14に対応する指示識別子が0である場合には、位置#4に対応する指示識別子は0であり、位置#6に対応するリソースユニット(すなわち、リソースユニット#3)が4×26トーンリソースユニットであると決定することができる。
type-3マッピングルールに基づいて図13に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、001000であり、従来技術におけるビットシーケンスを生成するための方法と比較して、3ビットのオーバーヘッドを使わずに済ますことができる。
各マッピングルールに基づいて各指示識別子およびビットシーケンスを決定する前述のプロセスは例にすぎず、本発明はそれに限定されないことを理解されたい。例えば、上記においては、左から右の順に決定するプロセスを説明しているが、決定はまた、受信端および送信端が対応する順序を使用することが保証されている限り右から左の順に行われてもよい。
加えて、割り当て予定の周波数ドメインリソースの帯域幅を説明した上記は例にすぎず、本発明はそれに限定されない。前述の3つのタイプのマッピングルールは、例えば、40MHz、80MHz、または160MHzといった、より大きな帯域幅を有する周波数ドメインリソースの割り振りを指示するためにさらに適用可能であり得る。加えて、具体的な決定プロセスは、type-2マッピングルールにおける40MHzまたは80MHzのための決定プロセスと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
前述の3つのタイプのマッピングルールは、例えば、40MHz、80MHz、または160MHzといった、より大きな帯域幅を有する周波数ドメインリソースの割り振りを指示するとともに最小粒度の20MHz(20MHz帯域幅内では、他の方法を指示するために使用してもよい)を指示するためにさらに適用可能であり得る。さらに、具体的な決定プロセスは、type-2マッピングルールにおける40MHzまたは80MHzのための決定プロセスと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
実施形態5
上述したように、前述の実施形態1、2、3、または4では、40MHz、80MHz、および160MHz帯域幅については、同様の方式が、その全体におけるリソースユニットの割り振りを指示することになる。
実施形態5では、40MHz、80MHz、および160MHz帯域幅における各20MHz帯域幅について、前述の実施形態1、2、3、もしくは4の方法、またはその可能な組合せが指示のために繰り返し使用され得る点で異なる。換言すれば、より大きな帯域幅については、帯域幅のリソースユニットの割り振りを指示するためのビットシーケンスは、各基本帯域幅におけるリソースユニットの割り振り(最小単位の帯域幅の割り振り、例えば、20MHz)を指示するビットシーケンスと、2つの隣接基本帯域幅が1つの割り当て予定のリソースユニットに配分されているかどうかを指示するアグリゲーション指示ビットとを含む。
例えば、割り当て予定の周波数ドメインリソースが40MHzである場合には、20MHz帯域幅指示方法が2回繰り返して使用される、すなわち、2ビットシーケンスが、前述の方法に従って第1の20MHz帯域幅および第2の20MHz帯域幅におけるリソースユニットの割り振りをそれぞれ指示するために含まれる。別の例では、割り当て予定の周波数ドメインリソースが80MHzである場合には、20MHz帯域幅指示方法が4回繰り返して使用される、すなわち、4つのセグメントのシーケンスが、前述の方法に従って第1の20MHz帯域幅、第2の20MHz帯域幅、第3の20MHz帯域幅、および第4の20MHz帯域幅におけるリソースユニットの割り振りをそれぞれ指示するために含まれる。
特定の例においては、各20Mの帯域幅を指示する方法では、type-0ビットが、20MHz帯域幅に対応する最大のリソースユニットが実際の割り振りにおいて存在していること、すなわち、242トーンリソースユニットが割り振られていることを指示している場合には、各20Mの帯域幅を指示するためのビットシーケンスは、アグリゲーションを行うかどうかを指示するための1ビットをさらに含み、このビットは特に、隣接する20Mが1つのリソースユニットに配分され得るかどうかを指示するためのものである。例えば、割り当て予定の周波数ドメインリソースが40MHzである場合には、2つの20MHz帯域幅をそれぞれ指示するための2つのセグメントにあるtype-0ビットが両方、242トーンリソースユニットが割り振られていることを指示し、アグリゲーションビットが両方、隣接する20Mが1つのリソースユニットに配分され得ることを指示している場合には、2つの20MHzが484トーンリソースユニットに配分されていることを指示する。別の例では、割り当て予定の周波数ドメインリソースが80MHzであるならば、4つのセグメントのビットのうちの、最後の2つの20MHz帯域幅を指示するための最後の2つのセグメントにあるtype-0ビットが両方、242トーンリソースユニットが割り振られていることを指示し、アグリゲーションビットが両方、隣接する20Mが1つのリソースユニットに配分され得ることを指示している場合には、最後の2つの20MHzが484トーンリソースユニットに配分されていることを指示し、4つの20MHz帯域幅を指示するための4つのセグメントにあるtype-0ビットがすべて、242トーンリソースユニットが割り振られていることを指示し、アグリゲーションビットがすべて、隣接する20Mが1つのリソースユニットに配分され得ることを指示している場合には、4つの20MHzが996トーンリソースユニットに配分されていることを指示する。
より具体的には、実施形態5においては、具体的な決定プロセスはまた、type-0ビット、type-1ビット、type-2ビット、またはtype-3ビットなどといった対応するビットを生成するための前述の決定方法の各々を参照されたい。
例えば、図10に示した割り当て予定の40MHz帯域幅については、20MHz指示方法(図9に対応する実施形態の方法)を、指示するために2回繰り返して使用してもよい。プリセットルール#22下におけるオプション指示識別子を含んでいる場合には、type-2マッピングルールに基づいて第1の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、00111である。type-2マッピングルールに基づいて第2の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは1である。ある20MHz帯域幅におけるプリセットルール#22下におけるオプション指示識別子が1である場合には、20MHz帯域幅を、242トーンリソースユニットに分割すること、または、隣接する20MHzを用いてより大きなリソースユニットに分割することを指示する。type-2マッピングルールに基づいて20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、アグリゲーションビットをさらに含み、このビットは、20MHz帯域幅を、242トーンリソースユニットに分割するかどうか、または、隣接する20MHzを用いてより大きなリソースユニットに分割するかどうかを指示するものである。第2の20MHz帯域幅が隣接する20MHzを用いてより大きなリソースユニットに分割されていないため、アグリゲーションビットは0である。したがって、type-2マッピングルールに基づいて第2の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、10である。20MHzの隣接性は、左から右に、2つの連続した20MHz、または4つの連続した20MHz、または8つの連続した20MHzを指し、これらは、484トーンリソースユニット、または996トーンリソースユニット、または996x2トーンリソースユニットにまとめて分割される。
したがって、type-2マッピングルールに基づいて図10に示した割り当て予定の40MHz帯域幅のために生成される様々な指示識別子によって形成されるビットシーケンスは、0011110である。オプションとして、デフォルトリソースユニットの位置が利用可能であるかどうかを指示する2ビットをさらに含み得る。
2つの連続した20MHzのうちの1つの20MHzを、242トーンリソースユニットに分割していない、または、隣接する20MHzを用いてより大きなリソースユニットに分割するが、残りの1つを、242トーンリソースユニットに分割する、または、隣接する20MHzを用いてより大きなリソースユニットに分割する場合には、type-1マッピングルールに基づいて第2の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、アグリゲーションビットを含まなくてもよい。したがって、type-2マッピングルールに基づいて図10に示した割り当て予定の40MHz帯域幅のために生成される様々な指示識別子によって形成されるビットシーケンスも、001111であり得る。
別の例では、図11に示した割り当て予定の80MHz帯域幅については、20MHz指示方法(図9に対応する実施形態の方法)が4回繰り返して使用され得る。プリセットルール#22下におけるオプション指示識別子を含んでいる場合には、type-2マッピングルールに基づいて第1の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、011である。type-2マッピングルールに基づいて第2の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは1である。type-2マッピングルールに基づいて第3の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは1である。type-2マッピングルールに基づいて第4の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは1である。ある20MHz帯域幅におけるプリセットルール#22下におけるオプション指示識別子が1である場合には、20MHz帯域幅を、242トーンリソースユニットに分割すること、または、隣接する20MHzを用いてより大きなリソースユニットに分割することを指示する。type-2マッピングルールに基づいて20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、アグリゲーションビットをさらに含み、このビットは、20MHz帯域幅を、242トーンリソースユニットに分割するかどうか、または、隣接する20MHzを用いてより大きなリソースユニットに分割するかどうかを指示するものである。第2の20MHz帯域幅が隣接する20MHzを用いてより大きなリソースユニットに分割されていないため、アグリゲーションビットは0である。したがって、type-2マッピングルールに基づいて第2の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、10である。第3の20MHz帯域幅が隣接する20MHzを用いてより大きなリソースユニットに分割されているため、アグリゲーションビットは1である。したがって、type-2マッピングルールに基づいて第3の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、11である。第4の20MHz帯域幅が隣接する20MHzを用いてより大きなリソースユニットに分割されているため、アグリゲーションビットは1である。したがって、type-2マッピングルールに基づいて第4の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、11である。20MHzの隣接性は、左から右に、2つの連続した20MHz、または4つの連続した20MHz、または8つの連続した20MHzを指し、これらは、484トーンリソースユニット、または996トーンリソースユニット、または996x2トーンリソースユニットにまとめて分割される。
隣接する20MHzを指示する1つのアグリゲーションビットは、左から右に2つの連続した20MHzが484トーンリソースユニットを構成し得ることを指示する。隣接する20MHzを指示する2つのアグリゲーションビットは、左から右に4つの連続した20MHzが996トーンリソースユニットを構成し得ることを指示する。隣接する20MHzを指示する3つのアグリゲーションビットは、左から右に4つの連続した20MHzが996x2トーンリソースユニットを構成し得ることを指示する。
したがって、type-2マッピングルールに基づいて図11に示した割り当て予定の80MHz帯域幅のために生成される様々な指示識別子によって形成されるビットシーケンスは、011101111である。オプションとして、5つのデフォルトリソースユニットの位置が利用可能であるかどうかを指示する5ビットをさらに含む。
2つの連続した20MHzのうちの1つの20MHzを、242トーンリソースユニットに分割していない、または、隣接する20MHzを用いてより大きなリソースユニットに分割するが、残りの1つを、242トーンリソースユニットに分割する、または、隣接する20MHzを用いてより大きなリソースユニットに分割する場合には、type-2マッピングルールに基づいて第2の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、アグリゲーションビットを含まなくてもよい。したがって、type-2マッピングルールに基づいて図10に示した割り当て予定の40MHz帯域幅のために生成される様々な指示識別子によって形成されるビットシーケンスも、01111111であり得る。
実施形態6
上述したように、前述の実施形態1、2、3、4、または5においては、20MHz、40MHz、80MHz、および160MHz帯域幅については、ビットシーケンスによって指示されるリソースユニットが、OFDMAにおけるシングルユーザ(Sigle User、SU)伝送のために使用され得る、または、OFDMAにおけるMU-MIMO伝送のために使用され得る、または、MU-MIMO伝送のために使用され得る。前者は、SU伝送として扱ってもよい。後者の2つは両方、MU伝送として扱ってもよい。
オプションとして、リソーススケジューリング情報は、リソーススケジューリング情報によって指示されるリソースユニットにおいて通信するステーションの数に関連する情報を指示する情報をさらに含む。2ビットまたは3ビットは、SUまたはMU-MIMO通信を行うステーションの数を指示するために使用される。例えば、"00"は、ステーションの数が1であることを指示する、すなわち、リソースユニットは、SU通信ために使用される。別の例では、"11"は、ステーションの数が4であることを指示し、リソースユニットは、MU通信のために使用されている。
通信プロトコルは、MU-MIMOを基本的にサポートする最小のサイズ、例えば、2×26トーンまたは4×26トーン、のリソースユニットを事前に定義し得る。ある例においては、4×26トーンリソースユニットは、MU-MIMO伝送が可能な最小の基本リソースユニットである。前記例においては、4×26サイズのリソースユニットは、MU-MIMO伝送において最大の4人のユーザをサポートし得るし、242サイズまたはより大きなサイズのリソースユニットは、MU-MIMO伝送において最大の8人のユーザをサポートし得る。したがって、MU-MIMOのための最小のサイズより小さい割り振りにおけるリソースユニットについては、SU伝送モードがデフォルトで実行され、リソースユニットにおいて通信を行うステーションの数を指示するためにビットは必要としない。
図11に示した80MHzのリソースユニットの割り振りの例においては、周波数ドメインリソースユニット#1''および周波数ドメインリソースユニット#3''は、MU-MIMO通信のために使用され、3つステーションおよび7つステーションにそれぞれ割り振られる。ビットシーケンスは、type-2マッピングルールに基づいて生成される指示識別子、すなわち、011101111を含む、ここで、第1の20MHzに対応するビットシーケンスは、011であり、第2の20MHzに対応するビットシーケンスは、10であり、第3の20MHzに対応するビットシーケンスは、11であり、第4の20MHzに対応するビットシーケンスは、11である。第1の20MHzリソースユニット内のステーションの数を指示するビットシーケンスは、1000であり、第2の20MHzリソースユニット内のステーションの数を指示するビットシーケンスは、111であり、第3の20MHzリソースユニット内のステーションの数を指示するビットシーケンスは、000であり、第4の20MHzリソースユニット内のステーションの数を指示するビットシーケンスは、000である。
実施形態7
前述の実施形態に基づいて、特定の例においては、少なくとも8ビットの長さを有するリソース割り振りのビットシーケンスを、提供しており、少なくとも実際に割り振られたリソースユニットと、リソースユニット上で伝送を行うステーションの数量に関連する(MU-MIMO伝送に関与するステーションの数量を特に指示する)情報とを指示するものである。特に、少なくとも8つの指示ビット、実際に割り振られるとともに指示ビットによって指示されるリソースユニット、およびリソースユニット上で伝送を行うステーションの数量は、テーブルを使用して簡単に表され得る。
無線ローカルエリアネットワークにおいては、このテーブルは、APおよび/またはSTAがこのテーブルに従ってリソース割り振りのビットシーケンスを生成またはパースし得るように、APおよび/またはSTA上に記憶されていてもよい。テーブルクエリ方式を使用しない場合には、前述のtype-1マッピングルール、type-2マッピングルール、またはtype-3マッピングルールも、リソース割り振りビットシーケンスを生成またはパースするものであり得る。
以下の表1に示した例においては、8ビットは、総計256個のリソース割り振りビットシーケンスを指示する。表1中の8ビットのリソース割り振りビットシーケンスは、実施形態4におけるtype-0ビット、実施形態2におけるtype-2ビット、実施形態6におけるリソースユニット上で伝送を行うステーションの数量に関連する情報を指示するビット、およびいくつかの予約(reserved)ビットを含み得る。テーブルストレージ方式を使用しない場合には、図23a-1、図23a-2、および図23bに示した特定の実施様態も、表1に示したような、実際に割り振られたリソースユニットに対応するリソース割り振りビットシーケンスおよびリソースユニット上で伝送を行うステーションの数量を取得するためのものであり得る。
表1は、基本帯域幅についてのリソース割り振り(最小単位の帯域幅割り振り、例えば、20MHz)のビットシーケンス、実際に割り振られるとともにリソース割り振りビットシーケンスによって指示されるリソースユニット、およびリソースユニット上で伝送を行うステーションの数量を指示している。実施形態5を参照すれば、40MHz、80MHz、および160MHz帯域幅における各20MHz帯域幅については、前述の実施形態1、2、3、もしくは4の方法、またはその可能な組合せが指示のために繰り返し使用され得る。換言すれば、より大きな帯域幅については、表1またはそのバリエーションは繰り返しすべての帯域幅のためのリソース割り振りビットシーケンスを取得されることになり得る。その詳細を本明細書では再び説明しない。
表1は、「リソース割り振りビットシーケンス」および対応する「実際に割り振られたリソースユニット」をリストアップしている。表1では、26は、1×26リソースユニットを指示し、52は、2×26リソースユニットを指示し、106は、4×26リソースユニットを指示し、242(n)は、242リソースユニットを指示し、リソース上で伝送を行うステーションの数量がnであり、nが1より大きい場合には、MU-MIMO伝送は、リソースユニット上で行われ、484(n)は、2×242リソースユニットを指示し、リソース上で伝送を行うステーションの数量がnであり、996(n)は、996リソースユニットに対応し、リソース上で伝送を行うステーションの数量がnであり、2×996(n)は、2×996リソースユニットに対応し、リソース上で伝送を行うステーションの数量がnである。
本例においては、MU-MIMO伝送が可能な最小のリソースユニットが106リソースユニットに制限されている。加えて、20MHzスペクトルリソースから実際に割り振られたリソースユニットが2つの106リソースユニットを含む場合には、106リソースユニット上で伝送を行うステーションの最大数量は、4である。他のケースにおいては、MU-MIMO伝送のためのリソースユニット上での伝送を行うステーションの最大数量は、8である。
特に、表1中のすべての8ビットのリソース割り振りビットシーケンス中の1番目のビットは、実施形態4におけるtype-0ビットであり、プロトコルにおける20MHzに対応する割り振られる可能性がある最大のリソースユニットが実際に割り振られるかどうか、すなわち、ステーションに実際に割り振られたおよび割り振り予定の現在のリソースユニットが242リソースユニットであるかどうかを指示する。現在の帯域幅が20MHzである場合には、type-0ビットが、実際に割り振られたリソースユニットが242リソースユニットより小さいかまたは242リソースユニットと等しいかを区別するものであり得ることを当業者は理解されよう。現在の帯域幅がより大きな帯域幅(例えば、40MHz、80MHz、または160MHz)である場合には、type-0ビットは、実際に割り振られたリソースユニットが242リソースユニットより小さいかまたは242リソースユニット以上であるかを区別するものであり得る。
加えて、シーケンス番号193からシーケンス番号256までの8ビットのリソース割り振りビットシーケンス中の3番目のビットおよび4番目のビットも、実施形態4におけるtype-0ビットである、ここで、3番目のビットは、実際に割り振られたリソースユニットが996リソースユニットであるかどうかを指示する。以下のテーブルは、特定の例である。3番目のビット"0"が、実際に割り振られたリソースユニットが996リソースユニットではないことを指示している場合には、4番目のビットは、実際に割り振られたリソースユニットが2×242リソースユニットであるかどうかを指示する。したがって、"10"は、実際に割り振られたリソースユニットが996リソースユニットであることを指示し、"01"は、実際に割り振られたリソースユニットが2×242リソースユニットであることを指示し、"00"は、実際に割り振られたリソースユニットが242リソースユニットであることを指示し、別の特別なビットシーケンス"11"は、実際に割り振られたリソースユニットが2×996リソースユニットであることを指示する。前記2ビットはまた、以下の小さなテーブルを使用して簡易に表され得る。3番目のビットおよび4番目のビットの位置が変更されている、または、ビットの値設定方式が変更されている(0および1の意味が入れ替えられている)場合には、テーブルの対応するバリエーションが存在し得るが、テーブルのバリエーションもすべて本実施形態の範囲に含まれることは理解されよう。
表1中のシーケンス番号1からシーケンス番号32までのビットシーケンス中の第2から7番目のビットは、実施形態2におけるtype-2ビットであり、図9に示したようなツリー図の原理に従って、実際に割り振られたリソースユニットを指示するためのビットが使用され得る、ここで、8番目のビットは、予約ビットである。
加えて、表1中のシーケンス番号33からシーケンス番号96までのビットシーケンス中の第2から5番目のビットも、実施形態2におけるtype-2ビットである。シーケンス番号97からシーケンス番号128までのビットシーケンス中の2番目のビットおよび3番目のビットも、実施形態2におけるtype-2ビットである。シーケンス番号129からシーケンス番号192までのビットシーケンスは、予約シーケンスである。
表1中のシーケンス番号33からシーケンス番号96までの8ビットのリソース割り振りビットシーケンス中の第6から8番目のビットは、実施形態6におけるリソースユニット上で伝送を行うステーションの数量を指示するためのビットである。シーケンス番号97からシーケンス番号128までのビットシーケンス中の第4から7番目のビットは、実施形態6におけるリソースユニット上で伝送を行うステーションの数量を指示するためのビットである、ここで、最初の2ビットは、第1の106リソースユニット上で伝送を行うステーションの数量を指示し、最後の2ビットは、第2の106リソースユニット上で伝送を行うステーションの数量を指示する。シーケンス番号193からシーケンス番号256までのビットシーケンス中の第5から7番目のビットはまた、実施形態6におけるリソースユニット上で伝送を行うステーションの数量を指示するためのビットである。
加えて、予約ビットは、対応するビットシーケンスが予約されているか未使用であるかを指示するものである。表1中のシーケンス番号1からシーケンス番号32までのビットシーケンスにおいては、8番目のビットは、予約ビットであり、シーケンス番号1からシーケンス番号16までのリソース割り振りシーケンス中の最初の7ビットは、シーケンス番号17からシーケンス番号32までのリソース割り振りシーケンス中の最初の7ビットにそれぞれ一致しており、8番目のビットは、対応するビットシーケンスが予約されているかどうかを指示するものである。シーケンス番号97からシーケンス番号128までのビットシーケンスにおいては、8番目のビットは、予約ビットであり、シーケンス番号97からシーケンス番号112までのリソース割り振りシーケンス中の最初の7ビットは、シーケンス番号113からシーケンス番号128までのリソース割り振りシーケンス中の最初の7ビットにそれぞれ一致している。シーケンス番号129からシーケンス番号256までのビットシーケンスにおいては、2番目のビットは、予約ビットであり、したがって、シーケンス番号129からシーケンス番号192までのリソース割り振りシーケンス中の他の7ビットは、シーケンス番号193からシーケンス番号256までのリソース割り振りシーケンス中の他の7ビットにそれぞれ一致している。シーケンス番号193からシーケンス番号208までの8ビットのリソース割り振りビットシーケンスにおいては、8番目のビットは、予約ビットであり、したがって、シーケンス番号193からシーケンス番号200までのビットシーケンス中の他の7ビットは、シーケンス番号201からシーケンス番号208までのビットシーケンス中の他の7ビットにそれぞれ一致している。シーケンス番号209からシーケンス番号224までの8ビットのリソース割り振りビットシーケンスにおいては、8番目のビットは、予約ビットであり、したがって、シーケンス番号209からシーケンス番号216までのビットシーケンス中の他の7ビットは、シーケンス番号217からシーケンス番号224までのビットシーケンス中の他の7ビットにそれぞれ一致している。シーケンス番号225からシーケンス番号240までの8ビットのリソース割り振りビットシーケンスにおいては、8番目のビットは、予約ビットであり、したがって、シーケンス番号225からシーケンス番号232までのビットシーケンス中の他の7ビットは、シーケンス番号233からシーケンス番号240までのビットシーケンス中の他の7ビットにそれぞれ一致している。シーケンス番号241からシーケンス番号256までの8ビットのリソース割り振りビットシーケンスにおいては、8番目のビットは、予約ビットであり、したがって、シーケンス番号241からシーケンス番号248までのビットシーケンス中の他の7ビットは、シーケンス番号249からシーケンス番号256までのビットシーケンス中の他の7ビットにそれぞれ一致している。
新規テーブルを形成するように、前述の複数のタイプのビットが異なる値設定方式(0および1の意味が入れ替えられているなど)を有し得るし、ビットの位置も変更され得ることは理解されよう、ただし、ビットの機能および技術的含意は同一であり、本発明の本実施形態においてさらに説明はしていない。例えば、表1中のtype-0ビットは、シーケンスの最終位置に配置されてもよい。別の例では、表1中のtype-2ビットのうちのいくつかのビットの位置を変更してもよい。加えて、リソースユニット上で通信を行うステーションの数を指示する、表1中のリソース割り振りを指示するビットシーケンスに含まれる、指示ビットは、他の機能、例えば、リソース割り振りシーケンスが位置する、20MHzチャネルにおけるHE-SIGBフィールド内のステーション情報のためのユーザフィールドの数を指示する機能を有し得る、ここで、ステーション情報のためのユーザフィールドは、ビットシーケンスによって指示されるリソースユニット上で通信を行うステーションに関する情報(例えば、図17に示したステーション情報のためのユーザフィールドの数)を含む。242より大きいサイズのリソースユニットについては、各20MHzチャネルのためのリソース割り振りのビットシーケンス中のこのタイプのビットは、対応する20MHzチャネル上で、HE-SIGBフィールド内のステーション情報のためのユーザフィールドの数を指示する、ここで、ステーション情報のための各ユーザフィールドは、ビットシーケンスによって指示されるこのリソースユニット上で通信を行う各ステーションに関する情報を含む。ある20MHzにおけるHE-SIGB内のステーション情報のためのユーザフィールドの数は0であってもよく、各20MHzにおけるHE-SIGBがステーション情報のためのユーザフィールドとほぼ等しい数を含むことができるという利点をもたらす。例えば、シーケンス番号217を有するリソース割り振りを指示するシーケンスは、第1の20MHzのために484(0)を指示するために使用される、ここで、484(0)は、この第1の20MHzおよび第2の隣接する20MHzが484トーンリソースユニットとして実際に割り振られ、この第1の20MHz(242)におけるHE-SIGBフィールド内のステーション情報のためのユーザフィールドの数が0であることを指示し、ステーション情報のためのユーザフィールドは、484トーンリソースユニット上で通信を行うステーションに関する情報を含む。別の例では、シーケンス番号233を有するリソース割り振りを指示するシーケンスは、996(0)を指示するものである。
例えば、HE-SIGBフィールドは、異なる20M個のチャネルにおいてそれぞれ搬送される、HE-SIGB1およびHE-SIGB2を含み、特定のHE-SIGBフィールドに含まれる、ステーション情報のためのユーザフィールドは、対応する帯域幅(チャネル)において受信または伝送を行うステーションに関する情報を含む。分かりやすい例としては、80MHz帯域幅においては、HE-SIGB1は、第1および第3の20MHzチャネル上で通信を行うステーションに関する、ステーション情報のためのユーザフィールドを含み、HE-SIGB2は、第2および第4の20MHzチャネル上で通信を行うステーションに関する、ステーション情報のためのユーザフィールドを含む。ある例においては、80MHz帯域幅内では、MU-MIMOが第1の40MHzにおいて行われ、合計で4つステーション(すなわち、第1の2つの20MHzチャネルにおいて合計で4つステーション)が通信に関与し、第3の20MHzチャネルが9つの26リソースユニットとして割り振られ、9つのステーションがOFDMA伝送に関与し、第4の20MHzチャネルが106リソースユニット、26リソースユニット、および106リソースユニットとして割り振られ、シングルステーション伝送がどちらかの106リソースユニット上で行われる、すなわち、3つのステーションがOFDMA伝送に関与する。2つのHE-SIGB内のユーザフィールドの数をほぼ同一にするために、第1の20MHzのビットシーケンスは、シーケンス番号217を有する484(0)を指示するシーケンス「11,01,000,1」であり、第2の20MHzのビットシーケンスは、シーケンス番号212を有する484(4)を指示するシーケンス「11,01,011,0」であり、第3の20MHzのビットシーケンスは、シーケンス番号1を有するシーケンス「000,0000,0」であり、第4の20MHzのビットシーケンスは、シーケンス番号97を有するシーケンス「011,0000,0」である。したがって、HE-SIGB1は、第1の20MHzチャネル上で通信を行うステーションに関する情報を含む、0個のステーション情報のためのユーザフィールドと、第3の20MHzチャネル上で通信を行うステーションに関する情報を含む、9つのステーション情報のためのユーザフィールドとを含む。HE-SIGB2は、第2の20MHzチャネル上で通信を行うステーションに関する情報を含む、4つステーション情報のためのユーザフィールドと、第4の20MHzチャネル上で通信を行うステーションに関する情報を含む、3つステーション情報のためのユーザフィールドとを含む。
その上さらに、表1中のいくつかの予約ビットは、割り振られるリソースユニットが帯域幅の中心に位置する26トーンリソースユニットを含んでいる場合に、中心の26トーンリソースユニットが使用予定であるかどうか(例えば、ステーションに割り当てられるかどうか)を指示するものであり得る。例えば、実際に割り振られるとともにシーケンス番号17から32までのリソース割り振りビットシーケンスによって指示されるリソースユニットは、シーケンス番号1から16までのリソース割り振りビットシーケンスによって指示されるものとそれぞれ一致している。しかしながら、シーケンス番号1から16までのビットシーケンスによってそれぞれ指示される中心の26トーンリソースユニットは、ステーションに割り当てられるが、シーケンス番号17から32までのビットシーケンスによってそれぞれ指示される中心の26トーンリソースユニットは、ステーションに割り当てられない。
表1では、実際に割り振られるとともにシーケンス番号241からシーケンス番号248までのリソース割り振りビットシーケンスによって指示されるリソースユニットは、現在の利用可能な最大帯域幅160Mに対応するリソースユニットである。しかしながら、スペクトルリソースの割り振りは、HE-SIGAフィールドによって指示されてもよい。この場合には、HE-SIGBに位置するリソース割り振りビットシーケンスは、もはや如何なる指示も与えなくてもよい。したがって、表1中のシーケンス番号241からシーケンス番号248までのリソース割り振りビットシーケンスはまた、予約シーケンスであり得る。
表3は、表1のバリエーションの例を指示している。例えば、106以上である各リソースユニット上で伝送を行う最大数量の8つのステーションをサポートするために、表1中のシーケンス番号129から192までのリソース割り振りビットシーケンスにおいては、最初の2ビットは、20MHzから実際に割り振られた、106リソースユニット、26リソースユニット、および106リソースユニットを指示するものであり、最後の6ビットのうちの3ビットのどれもが、それぞれ、106リソースユニット上で伝送を行うステーションの数量を指示するものである。しかしながら、表1中の20MHzから実際に割り振られた、106リソースユニット、26リソースユニット、および106リソースユニットを指示する、リソース割り振りビットシーケンス(シーケンス番号97から112)は表3中の予約シーケンスに変更されるが、実際に割り振られたリソースユニットを指示する他のリソース割り振りビットシーケンスの意味は変化しない。表1について記載した特別なまたは広範なケースを表3においても使用してもよいことは理解されよう。
特に、表1または表3などといったそのバリエーションは、APまたはSTA上に直接記憶され得る。しかしながら、上述したように、前述の実施様態はまた、シーケンスの生成またはパースのために使用され得る。図23a-1、図23a-2、および図23b内のフローチャートはまた、生成またはパースのために使用され、表1中の8ビットのリソース割り振りのビットシーケンスおよび実際に割り振られるとともに前記ビットによって指示されるリソースユニットと一致する結果を取得し得る。リソース割り振りビットシーケンスの生成中では、ビット(例えば、表1中の前述の1番目のビット、2番目のビット、および3番目のビットの指示機能)に関する所定のルールに従って、対応する指示値を取得する。それに対応するように、リソース割り振りビットシーケンスのパース中では、ビットをパースするたびに、現時点割り振られているリソースユニットの特定の状態を知る。その詳細を本明細書では再び説明しない。
図23a-1、図23a-2、および図23bにおいては、26は、1×26リソースユニットを指示し、52は、2×26リソースユニットを指示し、106は、4×26リソースユニットを指示し、242は、242リソースユニットを指示し、484は、2×242リソースユニットを指示し、996は、996リソースユニットに対応し、2×996は、2×996リソースユニットに対応する。加えて、周波数ドメインリソースを242より小さいリソースユニットに実際に分割する場合は、デフォルトの真ん中の位置に含まれる26リソースユニットは、フローチャートに反映されていない。実際に割り振られたリソースユニットの位置は、図23a-1、図23a-2、および図23bにおいて左から右に表示されているが、本発明の本実施形態はそれらに限定されない。リソースユニットの位置はまた、左から右に表示されてもよく、影響を受けるものはビットシーケンスの位置のみであるが、ビットの実際の機能は影響されない。図23b中のフローチャートは、106より小さく、"xx"が図23a-1および図23a-2中の3つの灰色ボックス内に生じている場合のさらなる分割によって取得される、リソースユニットをどのように指示するかさらに説明している、ここで、第3の灰色ボックス内に4つの"x"が存在しており、図23b中のフローチャートは、2つの"x"ごとに、どのように真ん中の26リソースユニットおよび20MHzにおける双方のサイド上の周波数ドメインリソースを106未満のリソースユニットに分割するかをそれぞれ指示するために使用される。最大帯域幅160MHzに対応する2×996リソースユニット(2×996リソースユニットとも表す)がHE-SIGAフィールドにおいて指示されていない場合には、図23a-1および図23a-2中の「11,11,yyy,b'→2×996リソースユニット」は、2×996リソースユニットを指示する。最大帯域幅160MHzに対応する2×996リソースユニット(2×996リソースユニットとも表す)がHE-SIGAフィールドにおいて指示されている場合には、図23a-1および図23a-2中の「11,11,yyy,b'→2×996リソースユニット」はまた、予約シーケンスとして使用され得る。
図23a-1、図23a-2、および図23bにおける前述のフローチャートは例にすぎないことは理解されよう。リソース割り振りシーケンス中の各ビットの位置または第1の識別子と各ビットの第2の識別子とが異なる場合には、フローチャートにおいて決定する対応する値もそれに対応するように変化する。このことは、テーブルのバリエーションと同様である。
本発明の本実施形態に基づいて、表3中の8ビットのリソース割り振りのビットシーケンスおよび実際に割り振られるとともに前記ビットによって指示されるリソースユニットについては、図24A、図24B、および図23b中のフローチャートはまた、リソース割り振りビットシーケンスを生成するものまたはリソース割り振りビットシーケンスをパースするものであり得る。他は、表1中のフローチャートと同一である。
表1および表3は例にすぎず、テーブルの内容は本明細書において説明した各実施形態でカバーされていることに留意されたい。例えば、要約した8ビットリソース割り振りシーケンスを本明細書のスライド11(Appendix 2)のページに記載しており、スライド11は、20MHz基本帯域幅から実際に割り振られたリソースユニットの4つのケース(すなわち1. 242またはより大きなリソースユニット、2. 2つの106リソースユニットを含む、3. 1つの106リソースユニットのみを含む、そして、4. 106リソースユニットを含まないが、それでも242リソースユニットより小さい)を指示するための8ビットリソース割り振りシーケンスに含まれるビットのタイプをリストアップしており、「RA within 20MHz」が1つのtype-0ビットおよび異なる数量のtype-2ビットを含み、「Num of STAs」が実施形態6におけるリソースユニット上で伝送を行うステーションの数量を指示するビットであることを記載している。しかしながら、中心の26リソースユニット(Use Central 26-RU)およびスライド11中のアグリゲーションビット(Aggregate)を使用するかどうかを指示するビットは、表1および表3にリストアップされていない。表1および表3は、実施形態1から6における指示ビットおよびスライド11中の要約のさらなる表形式の改良版であるが、本実施形態の本実施形態は表1および表3に限定されない。
オプションとして、リソーススケジューリング情報は、複数のスケジューリング済みの受信端の識別子をさらに含み、受信端の識別子は、実際の割り振りにおけるリソースユニットが複数の受信端に割り当てられていることを指示するものである。
オプションとして、リソーススケジューリング情報は、以下のことを含む。
リソーススケジューリング情報は、複数のスケジューリング済みの受信端のスケジューリング順序を指示する、第4の指示情報をさらに含む、ここで、第1の受信端のスケジューリング順序は、割り当て予定の周波数ドメインリソースにおける、第1の受信端に割り振られる割り当て予定のリソースユニットの位置に対応する。
例えば、送信端は、ビットシーケンスまたはビットマップ(ビットマップ)を使用してシステム内の各受信端に以下の情報を通知し得る。
A. 現在の周波数ドメインリソース(すなわち、割り当て予定の周波数ドメインリソース)のコンポーネント、すなわち、割り当て予定の周波数ドメインリソースにおいて、各リソースユニットによって含まれるサブキャリアの数量すなわち含まれている各リソースユニットのサイズ
B. 割り当て予定の周波数ドメインリソースにおける各リソースユニットの位置
さらに、送信端は、ユーザグループ情報(すなわち、第4の指示情報の例)、または、複数の受信端の識別子を含むステーション識別子リスト(STA IDリスト)を使用して、システム内の各受信端がスケジューリングされているかどうか、およびスケジューリング済みのユーザにおける位置を通知し得る。
したがって、受信端は、前述の情報に基づいて、受信端に送信端によって割り振られるリソースユニットを決定し得るし、リソースユニットを使用してデータを受信または送信する。
すなわち、ビットシーケンスを生成した後に、送信端は、ビットシーケンスを含むリソース割り振り指示情報を各受信端デバイスに送信し得る。したがって、受信端デバイスは、リソース割り振り指示情報に基づいて、受信端デバイスに送信端によって割り当てられる周波数ドメインリソースを決定し、割り当てられた周波数ドメインリソースを使用してデータまたはシグナリングを送信することができる。
リソース割り振り指示情報は、現在の帯域幅における周波数ドメインリソース割り振りを主に果たす。リソース割り振り指示情報を受信した後に、受信端は、前述のビットシーケンスを使用して、現在の伝送のリソース割り振りモードまたはサイズおよび割り当て予定の周波数ドメインリソースに含まれるリソースユニットの位置を知り得る。
その後、リソーススケジューリング情報内のSTA IDリスト部分を読み出すことによって、受信端は、その受信端自身がスケジューリングされているかどうか、および、どのスケジューリング済みのユーザまたはユーザグループにそれが属しているか(どのスケジューリング済みのユーザまたはユーザグループか)を知る。2つの部分の内容(リソース割り振り指示情報およびSTA IDリスト、すなわち、リソーススケジューリング情報の例)を参照して、受信端は、対応するスケジューリングされた位置においてデータを受信または送信し得る。
例えば、一例として図9に示した割り当て予定の周波数ドメインリソースを使用すれば、割り当て予定の周波数ドメインリソースは、左から右の順に、リソースユニット#1、リソースユニット#2、リソースユニット#0、およびリソースユニット#3を含む。
4つのリソースユニットが、4つの受信端(理解および識別を容易にするために、STA1、STA2、STA3、およびSTA4と以降示す)に割り振られており、STA IDリスト中のSTAの数量は、送信端(例えば、AP)によって割り振られる利用可能なリソースユニットの総数に等しく、STA IDリスト中のSTAの配置順序は、STA1、STA2、STA3、およびSTA4である。
図9に示した割り当て予定の周波数ドメインリソースのための取得したビットシーケンスは、"0111"である。ビットシーケンスおよびSTA IDリストをパースすることによって、受信端は、受信端にAPによって割り振られるリソースを知る。
すなわち、STA1は、STA IDリストにおいて1番目のものであるため、STA1は、割り振られるリソースは、割り当て予定の周波数ドメインリソースにおける1番目のリソースユニット、すなわち、リソースユニット#1であると決定することができる。
同様に、STA2は、STA IDリストにおいて2番目のものであるため、STA2は、割り振られるリソースは、割り当て予定の周波数ドメインリソースにおける2番目のリソースユニット、すなわち、リソースユニット#2であると決定することができ、STA3は、STA IDリストにおいて3番目のものであるため、STA3は、割り振られるリソースは、割り当て予定の周波数ドメインリソースにおける3番目のリソースユニット、すなわち、リソースユニット#0であると決定することができ、STA4は、STA IDリストにおいて4番目のものであるため、STA4は、割り振られるリソースは、割り当て予定の周波数ドメインリソースにおける4番目のリソースユニット、すなわち、リソースユニット#3であると決定することができる。
ビットシーケンスの前述のリソース指示情報およびSTA IDリストに基づいて行われるリソーススケジューリングの方式を説明した上記は例にすぎず、本発明はそれに限定されないことを理解されたい。
例えば、STAが固定的に不変であるシナリオにおいては、STAの順序が事前に設定されていてもよい。したがって、APは、リソース指示情報を使用して割り当て予定の周波数ドメインリソースにおける各リソースユニットのサイズおよび位置のみを各STAに通知する必要がある。したがって、STA IDリストの送信は省略され得る。
加えて、本発明の本実施形態においては、ユーザグループ情報は、ステーション識別子リストを含み、別々に送信されること、または、ユーザグループ情報は、ユーザ固有の情報の一部として使用され得る、すなわち、各STA IDは、対応するユーザ固有の情報に配置されることに留意されたい。
オプションとして、リソーススケジューリング情報は、ターゲット周波数ドメインの帯域幅を指示する第1の指示情報をさらに含む。
特に、割り当て予定の周波数ドメインリソースの帯域幅を決定した後に、受信端は、例えば、図4から図6に示したリソースユニットの割り振りに従って、割り当て予定の周波数ドメインリソースに含まれる最大のリソースユニットのサイズを決定することができる、したがって、各マッピングルールに対応するプリセットサブキャリア数量を決定することができる。したがって、送信端は、割り当て予定の周波数ドメインリソースの帯域幅を受信端に指示する帯域幅指示情報(第1の指示情報の例)をさらに送信し得る。
第1の指示情報に基づいて行われるリソーススケジューリングの方式を説明した上記は例にすぎず、本発明はそれに限定されないことを理解されたい。例えば、通信システムが指定の帯域幅を有する周波数ドメインリソースのみを使用する場合には、各マッピングルールに対応するプリセットサブキャリア数量が、デフォルト値として使用されてもよく、送信端および受信端において事前に設定されていてもよい。
オプションとして、リソーススケジューリング情報は、各リソースユニットがマルチユーザ多入力多出力MU-MIMOのために使用されているかどうかを指示する第2の指示情報をさらに含む。
特に、上述したように、受信端は、リソース割り振り指示情報に従って、サイズおよび割り当て予定の周波数ドメインリソースに含まれる各リソースユニットの位置を決定することができる。したがって、送信端は、MIMO指示情報(すなわち、第2の指示情報の例)を使用して、各リソースユニットがMU-MIMOを行うものであるかどうかをさらに通知し得る。
例えば、MU-MIMO伝送が可能なリソースユニットの最小粒度が242であると仮定すると、図14に示したように、MU-MIMO伝送は、第1のリソースユニット(2×242トーンリソースユニット)上で行われ、MU-MIMO伝送は、他のリソースユニット(すなわち、網掛け部分内のリソースユニット)では行われない。ここで、マッピングルール#Bを一例として使用する。マッピングルール#Aおよび#Cも同様であり得る。
ある方式では、MIMO指示情報は、4ビット指示情報であり得る、すなわち、"1000"で指示され得る。1番目のビット"1"は、対称中心の左サイド上の2×242トーンリソースユニットがMU-MIMO伝送のために使用されていることを指示する。2番目のビット"0"は、2×242トーンリソースユニットが対称中心の右サイド上にないことを指示し、したがって、右サイド上で2×242リソースユニット上で行われるMU-MIMO伝送のケースは存在しない。3番目のビット"0"は、対称中心の右サイド上の第1の242リソースユニットがMU-MIMO伝送のために使用されていないことを指示する。4番目のビット"0"は、対称中心の右サイド上の第2の242リソースユニットがMU-MIMO伝送のために使用されていないことを指示する。真ん中の1×26リソースユニットは、真ん中の1×26リソースユニットをMU-MIMO伝送のために使用できないことを暗黙的に示す。
この場合には、受信端が前述のリソース割り振り指示情報に基づいて各リソースユニットのサイズおよび位置を決定していなかった場合には、受信端は、MU-MIMO指示情報に基づいて、各リソースユニットをMU-MIMO伝送のために使用することができるかどうかを決定することができる。
別の方式では、周波数ドメインリソース割り振り指示情報(例えば、前述のマッピングルール#A、マッピングルール#B、およびマッピングルール#C)を参照して、割り当て予定の周波数ドメインリソースが分割されるリソースユニットの数量を知り得る。MU-MIMO指示情報は、3ビット指示情報であり得る、すなわち、"100"で指示され得る。1番目のビット"1"は、割り当て予定の周波数ドメインリソースにおける1番目のリソースユニットがMU-MIMO伝送のために使用されていることを指示する。割り当て予定の周波数ドメインリソースにおける2番目のリソースユニットのサイズが242未満であるため、第2のリソースユニットは、デフォルトでMU-MIMO伝送のために使用されない。2番目のビット"0"は、割り当て予定の周波数ドメインリソースにおける3番目のリソースユニットがMU-MIMO伝送のために使用されていないことを指示する。3番目の"0"は、割り当て予定の周波数ドメインリソースにおける4番目のリソースユニットがMU-MIMO伝送のために使用されていないことを指示する。
本発明の本実施形態によるリソーススケジューリング方法は、各リソースユニットがMU-MIMO伝送のために使用されているかどうかを受信端が知ることを可能にしており、したがって、伝送効率および信頼性を改善することを可能としている。
オプションとして、リソーススケジューリング情報は、各リソースユニットは、利用可能であるかどうかを指示する第3の指示情報をさらに含む。
特に、上述したように、受信端は、リソース割り振り指示情報に従って、サイズおよび割り当て予定の周波数ドメインリソースに含まれる各リソースユニットの位置を決定することができる。したがって、送信端は、各リソースユニットが利用可能であるかどうかを指示する指示情報(すなわち、第3の指示情報)を使用して、各リソースユニットが利用可能であるかどうかをさらに通知し得る。
例えば、割り当て予定の周波数ドメインリソースにおける各リソースユニットの割り振りが図14に示したものであると仮定すると、干渉などの因子により、網掛け部分内のリソースユニットは、利用不可である。
例えば、前述のtype-2マッピングルール(すなわち、マッピングルール#B)が使用されている場合には、割り当て予定の周波数ドメインリソースに対応するリソース割り振り指示情報は、"1011"である。真ん中のリソースユニットがデフォルトで存在しているため、受信端は、ビットシーケンスに従って、割り当て予定の周波数ドメインリソースを4つのリソースユニットに分割すると決定し得る。図14に示したように、第2、第3、および第4のリソースユニットは、利用不可である。したがって、受信端は、以下の方式で通知し得る。
方式1: 4ビットは、4つのリソースユニットが利用可能であるかどうかをそれぞれ指示するものであり得る。例えば、"0"は、リソースユニットが利用不可であることを指示し、"1"は、リソースユニットを指示する。ビットは、1対1ベースでリソースユニットに対応する。例えば、1番目のビットは、第1のリソースユニットに対応し、2番目のビットは、第2のリソースユニットに対応し、3番目のビットは、第3のリソースユニットに対応し、4番目のビットは、第4のリソースユニットに対応する。この場合には、4ビット指示情報は、"1000"である。
方式2: インデックス番号はまた、どのリソースユニットが利用不可であるかを指示するものであってもよい。割り当て予定の周波数ドメインリソースを4つのリソースユニットに分割するため、2ビットのみがインデックス番号を指示するために必要になる。例えば、"00"は、第1のリソースユニットを指示し、"01"は、第2のリソースユニットを指示し、"10"は、第3のリソースユニットを指示し、"11"は、第4のリソースユニットを指示する。この場合には、送信端は、第3の指示情報として利用可能なリソースユニットのインデックス番号"00"を受信端に送信し得る、または、送信端は、第3の指示情報として利用不可能なリソースユニットのインデックス番号"011011"を受信端に送信し得る。このことは本発明において特に限定されない。
本発明の本実施形態によるリソーススケジューリング方法は、各リソースユニットが利用可能であるかどうかを受信端が知ることを可能にしており、したがって、伝送効率および信頼性を改善することを可能としている。
オプションとして、方法は、無線ローカルエリアネットワークシステムに適用され、
ビットシーケンスを受信端に送信するステップは、
ビットシーケンスをプリアンブル内の高効率シグナリングフィールドAまたは高効率シグナリングフィールドBに付加し、ビットシーケンスを受信端に送信するステップ、または、
ビットシーケンスを媒体アクセス制御レイヤに付加し、ビットシーケンスを受信端に送信するステップを含む。
特に、WLANシステム内のパケット構造(例えば、802.11ax)を図15に示している。プリアンブル部分は、レガシープリアンブル(Legacy preamble、L-preamble)およびレガシープリアンブルの直後に続く高効率(High Efficient、HE)プリアンブルを含む。レガシープリアンブルは、ショートトレーニングフィールド(Legacy Shorting Training Field、L-STF)、ロングトレーニングフィールド(Legacy Long Training Field、L-LTF)、シグナリングフィールド(Legacy Signal Field、L-SIG)、およびリピーテッドシグナリングフィールド(Rpeated Legacy Signal Field、RL-SIG)を含む。高効率プリアンブルは、高効率シグナリングフィールドA(High Efficient Signal Field A、HE-SIGA)、高効率シグナリングフィールドB(High Efficient Signal Field B、HE-SIGB)、高効率ショートトレーニングフィールド(High Efficient Shorting Training Field、HE-STF)、および高効率ロングトレーニングフィールド(High Efficient Long Training Field、HE-LTF)を含む。オプションとして、高効率プリアンブルは、高効率シグナリングフィールドC(High Efficient Signal Field C、HE-SIGC)を含む。さらに、WLANシステム内のパケット構造は、データフィールド(DATA)をさらに含む。
HE-SIGAおよびHE-SIGBは、すべてのユーザにブロードキャストされ、802.11axパケット構造においてシグナリング情報を搬送する。HE-SIG-Bは、図16に示したように共通の情報パラメータ(Common Parameter)、リソース割り振り指示(Resource Allocation)、ステーション識別子リスト(STA IDリスト)、および各スケジューリング済みのユーザステーションに関する情報(STA Parameter)を含む。あるいは、ステーション識別子はまた、図17に示したように、対応するユーザステーション情報に配置され得る。共通の情報パラメータは、データ伝送、OFMDA/MU-MIMO指示、HE-LTF数量、およびモードのために使用されるガードインターバル(Guard Interval、GI)を含み、アップリンク/ダウンリンク指示、および従来のHE-SIGBが存在するかどうかといったパラメータを含み得る。ユーザステーション情報は、ユーザの空間ストリームの数量、データ伝送のために使用される変調符号化方式(MCS、Modulation and Coding Scheme)、符号化タイプ、時空間ブロック符号(STBC)を使用するかどうかに関する指示、ビームフォーミング(beamforming)技術を使用するかどうかに関する指示を含む。加えて、共通の情報パラメータはまた、HE-SIGAにおいて搬送されてもよい。
したがって、本発明の本実施形態においては、リソーススケジューリング情報は、HE-SIGA(例えば、HE-SIGAは、帯域幅情報を搬送し得る)、またはHE-SIGB(例えば、HE-SIGBは、前述のビットシーケンス、ユーザグループ情報などを含むリソース割り振り情報を搬送し得る)において搬送され、受信端に送信され得る。
あるいは、本発明の本実施形態においては、リソーススケジューリング情報は、媒体アクセス制御レイヤにおいて搬送され得る。例えば、リソーススケジューリング情報は、媒体アクセス制御レイヤまたはMACレイヤ内の別のフィールド内の媒体アクセス制御ヘッダ(MAC HEADER)において搬送されてもよい。
本発明の本実施形態による、リソーススケジューリング方法においては、ビットシーケンス中の少なくともいくつかのビットが、実際の割り振りにおけるリソースユニットの割り振りに基づくとともに、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置と比較することによって、割り当て予定の周波数ドメインリソースから実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースを分割することによって取得される可能性があるリソースユニットの位置にある1つまたは複数のリソースユニットの位置にあるかどうかを指示するものであり、異なる長さのビットシーケンスをフレキシブルに生成することを可能としている。したがって、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることを可能としている。
さらに、本発明の本実施形態による、リソーススケジューリング方法においては、N個のマッピングルールを取得し、各マッピングルール下の各リソースユニットに対応する指示識別子を割り当て予定の周波数ドメインリソースにおいて各リソースユニットに含まれるサブキャリアの数量に従って決定し、指示識別子に基づいて、割り当て予定の周波数ドメインリソースにおける各リソースユニットに含まれるサブキャリアの数量および各リソースユニットの位置を指示するビットシーケンスを決定し得る。したがって、異なる長さのビットシーケンスのフレキシブルな生成を、割り当て予定の周波数ドメインリソースにおいて各リソースユニットに含まれるサブキャリアの数量に従って、実施することができ、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることを可能としている。
図18は、本発明の別の実施形態による、リソーススケジューリング方法200の概略フローチャートである、ここで、方法を受信端の観点から説明している。方法200は、無線ローカルエリアネットワークに適用され、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義する。図18に示したように、方法200は、以下のステップを含む。
S210. 受信端が、送信端によって送信されたリソーススケジューリング情報を受信する、ここで、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースについて実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置のうちの1つまたは複数のリソースユニットの位置にあるかどうかを指示するものである。
S220. リソーススケジューリング情報に従って、受信端に送信端によって実際に割り振られたリソースユニットを決定する。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を含む。
オプションとして、割り当て予定の周波数ドメインリソースに割り振られる可能性があるリソースユニットの位置は、デフォルト位置を含み、デフォルト位置に対応するリソースユニットは、次世代プロトコルによって事前に定義されているような、ビットシーケンスによって指示されないリソースユニットである。
オプションとして、ビットシーケンスは、複数のtype-1ビットを含み、複数のtype-1ビットは、1対1ベースで複数のリソースユニットの位置のペアに対応し、type-1ビットのうちの1つは、対応するリソースユニットの位置のペア中のリソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するものであり、1つのリソースユニットの位置のペアは、デフォルト位置の一方のサイド上に位置する2つの連続した最小のリソースユニットの位置を含む。
オプションとして、ビットシーケンスは、複数のtype-2ビットを含み、type-2ビットは、対称中心の一方のサイド上における最大のリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。
オプションとして、ビットシーケンスは、2つのtype-3ビットを含み、2つのtype-3ビットは、1対1ベースで対称中心の双方のサイド上に位置する2つのリソースユニット位置グループに対応し、type-3ビットは、対応するリソースユニット位置グループ中のリソースユニットの位置にあるすべてのリソースユニットが割り当て予定のリソースユニットであるかどうかを指示するものであり、1つのリソースユニット位置グループは、割り当て予定の周波数ドメインリソースの中心の一方のサイド上に位置する複数の最小のリソースユニットの位置を含む。
オプションとして、リソーススケジューリング情報は、複数のスケジューリング済みの受信端の識別子をさらに含み、受信端の識別子は、実際の割り振りにおけるリソースユニットが複数の受信端に割り振られていることを指示するものである。
オプションとして、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースを指示する第1の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットがマルチユーザ多入力多出力MU-MIMOのために使用されているかどうかを指示する第2の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットが利用可能であるかどうかを指示する第3の指示情報をさらに含む。
オプションとして、受信端が送信端によって送信されたリソーススケジューリング情報を受信することは、
プリアンブル内の高効率シグナリングフィールドAまたは高効率シグナリングフィールドBにおいて搬送されるとともに送信端によって送信されたビットシーケンスを受信すること、または、
媒体アクセス制御レイヤにおいて搬送されるとともに送信端によって送信されたビットシーケンスを受信することを含む。
オプションとして、送信端は、ネットワークデバイスであり、受信端は、端末デバイスである。
方法200における受信端のアクションは、方法100における受信端(例えば、端末デバイス)のアクションと同様であり、方法200における送信端のアクションは、方法100における送信端(例えば、ネットワークデバイス)のアクションと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
本発明の本実施形態による、リソーススケジューリング方法においては、ビットシーケンス中の少なくともいくつかのビットが、実際の割り振りにおけるリソースユニットの割り振りに基づくとともに、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置と比較することによって、割り当て予定の周波数ドメインリソースから実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースを分割することによって取得される可能性があるリソースユニットの位置にある1つまたは複数のリソースユニットの位置にあるかどうかを指示するものであり、異なる長さのビットシーケンスをフレキシブルに生成することを可能としている。したがって、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることを可能としている。
上記においては、図1から図18を参照して、本発明の実施形態による、リソーススケジューリング方法を詳細に説明している。下記においては、図19および図20を参照して、本発明の実施形態による、詳細リソーススケジューリング装置を詳細に説明する。
図19は、本発明の実施形態による、リソーススケジューリング装置300の概略ブロック図を示している。装置300は、無線ローカルエリアネットワークに適用され、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義する。図18に示したように、装置300は、
リソーススケジューリング情報を生成するように構成される、生成ユニット310であって、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースについて実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置のうちの1つまたは複数のリソースユニットの位置にあるかどうかを指示するためのものである、生成ユニット310と、
リソーススケジューリング情報を受信端に送信するように構成される、送信ユニット320とを備える。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を含む。
オプションとして、割り当て予定の周波数ドメインリソースに割り振られる可能性があるリソースユニットの位置は、デフォルト位置を含み、デフォルト位置に対応するリソースユニットは、次世代プロトコルによって事前に定義されているような、ビットシーケンスによって指示されないリソースユニットである。
オプションとして、ビットシーケンスは、複数のtype-1ビットを含み、複数のtype-1ビットは、1対1ベースで複数のリソースユニットの位置のペアに対応し、type-1ビットのうちの1つは、対応するリソースユニットの位置のペア中のリソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するものであり、1つのリソースユニットの位置のペアは、デフォルト位置の一方のサイド上に位置する2つの連続した最小のリソースユニットの位置を含む。
オプションとして、ビットシーケンスは、複数のtype-2ビットを含み、type-2ビットは、対称中心の一方のサイド上における最大のリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。
オプションとして、ビットシーケンスは、2つのtype-3ビットを含み、2つのtype-3ビットは、1対1ベースで対称中心の双方のサイド上に位置する2つのリソースユニット位置グループに対応し、type-3ビットは、対応するリソースユニット位置グループ中のリソースユニットの位置にあるすべてのリソースユニットが割り当て予定のリソースユニットであるかどうかを指示するものであり、1つのリソースユニット位置グループは、割り当て予定の周波数ドメインリソースの中心の一方のサイド上に位置する複数の最小のリソースユニットの位置を含む。
オプションとして、リソーススケジューリング情報は、複数のスケジューリング済みの受信端の識別子をさらに含み、受信端の識別子は、実際の割り振りにおけるリソースユニットが複数の受信端に割り振られていることを指示するものである。
オプションとして、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースを指示する第1の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットがマルチユーザ多入力多出力MU-MIMOのために使用されているかどうかを指示する第2の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットが利用可能であるかどうかを指示する第3の指示情報をさらに含む。
オプションとして、送信ユニットは、ビットシーケンスをプリアンブル内の高効率シグナリングフィールドAまたは高効率シグナリングフィールドBに付加し、ビットシーケンスを受信端に送信するように特に構成される、または、
送信ユニットは、ビットシーケンスを媒体アクセス制御レイヤに付加し、ビットシーケンスを受信端に送信するように特に構成される。
オプションとして、装置300は、ネットワークデバイスであり、受信端は、端末デバイスである。
本発明の本実施形態による、リソーススケジューリング装置300は、本発明の実施形態の方法における送信端(例えば、ネットワークデバイス)に対応し得るし、リソーススケジューリング装置300内の各ユニットすなわち各モジュール、および前述の他の操作および/または機能は、図1中の方法100の対応するプロシージャを実施することをそれぞれ意図している。簡潔にするために、その詳細を本明細書では再び説明しない。
本発明の本実施形態による、リソーススケジューリング装置においては、ビットシーケンス中の少なくともいくつかのビットが、実際の割り振りにおけるリソースユニットの割り振りに基づくとともに、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置と比較することによって、割り当て予定の周波数ドメインリソースから実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースを分割することによって取得される可能性があるリソースユニットの位置にある1つまたは複数のリソースユニットの位置にあるかどうかを指示するものであり、異なる長さのビットシーケンスをフレキシブルに生成することを可能としている。したがって、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることを可能としている。
図20は、本発明の実施形態による、リソーススケジューリング装置400の概略ブロック図を示している。装置400は、無線ローカルエリアネットワークに適用され、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義する。図20に示したように、装置400は、
送信端によって送信されたリソーススケジューリング情報を受信するように構成される、受信ユニット410であって、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースについて実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置のうちの1つまたは複数のリソースユニットの位置にあるかどうかを指示するためのものである、受信ユニット410と、
リソーススケジューリング情報に従って、受信端に送信端によって実際に割り振られたリソースユニットを決定するように構成される、決定ユニット420とを備える。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を含む。
オプションとして、割り当て予定の周波数ドメインリソースに割り振られる可能性があるリソースユニットの位置は、デフォルト位置を含み、デフォルト位置に対応するリソースユニットは、次世代プロトコルによって事前に定義されているような、ビットシーケンスによって指示されないリソースユニットである。
オプションとして、ビットシーケンスは、複数のtype-1ビットを含み、複数のtype-1ビットは、1対1ベースで複数のリソースユニットの位置のペアに対応し、type-1ビットのうちの1つは、対応するリソースユニットの位置のペア中のリソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するものであり、1つのリソースユニットの位置のペアは、デフォルト位置の一方のサイド上に位置する2つの連続した最小のリソースユニットの位置を含む。
オプションとして、ビットシーケンスは、複数のtype-2ビットを含み、type-2ビットは、対称中心の一方のサイド上における最大のリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。
オプションとして、ビットシーケンスは、2つのtype-3ビットを含み、2つのtype-3ビットは、1対1ベースで対称中心の双方のサイド上に位置する2つのリソースユニット位置グループに対応し、type-3ビットは、対応するリソースユニット位置グループ中のリソースユニットの位置にあるすべてのリソースユニットが割り当て予定のリソースユニットであるかどうかを指示するものであり、1つのリソースユニット位置グループは、割り当て予定の周波数ドメインリソースの中心の一方のサイド上に位置する複数の最小のリソースユニットの位置を含む。
オプションとして、リソーススケジューリング情報は、複数のスケジューリング済みの受信端の識別子をさらに含み、受信端の識別子は、実際の割り振りにおけるリソースユニットが複数の受信端に割り振られていることを指示するものである。
オプションとして、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースを指示する第1の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットがマルチユーザ多入力多出力MU-MIMOのために使用されているかどうかを指示する第2の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットが利用可能であるかどうかを指示する第3の指示情報をさらに含む。
オプションとして、受信ユニットは、プリアンブル内の高効率シグナリングフィールドAまたは高効率シグナリングフィールドBにおいて搬送されるとともに送信端によって送信されたビットシーケンスを受信するように特に構成される、または、
受信ユニットは、媒体アクセス制御レイヤにおいて搬送されるとともに送信端によって送信されたビットシーケンスを受信するように特に構成される。
オプションとして、送信端は、ネットワークデバイスであり、装置400は、端末デバイスである。
本発明の本実施形態による、リソーススケジューリング装置400は、本発明の実施形態の方法における送信端(例えば、ネットワークデバイス)に対応し得るし、リソーススケジューリング装置400内の各ユニットすなわち各モジュール、および前述の他の操作および/または機能は、図18中の方法200の対応するプロシージャを実施することをそれぞれ意図している。簡潔にするために、その詳細を本明細書では再び説明しない。
本発明の本実施形態による、リソーススケジューリング装置においては、ビットシーケンス中の少なくともいくつかのビットが、実際の割り振りにおけるリソースユニットの割り振りに基づくとともに、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置と比較することによって、割り当て予定の周波数ドメインリソースから実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースを分割することによって取得される可能性があるリソースユニットの位置にある1つまたは複数のリソースユニットの位置にあるかどうかを指示するものであり、異なる長さのビットシーケンスをフレキシブルに生成することを可能としている。したがって、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることを可能としている。
上記においては、図1から図18を参照して、本発明の実施形態による、リソーススケジューリング方法を詳細に説明している。下記においては、図21および図22を参照して、本発明の実施形態による、リソーススケジューリングデバイスを詳細に説明する。
図21は、本発明の実施形態による、リソーススケジューリングデバイス500の概略構造図を示している。デバイス500は、無線ローカルエリアネットワークに適用され、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義する。図21に示したように、デバイス500は、
バス510と、
バスに接続されているプロセッサ520と、
バスに接続されているメモリ530と、
バスに接続されている送信機540とを備え、
プロセッサは、リソーススケジューリング情報を生成することであって、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースについて実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置のうちの1つまたは複数のリソースユニットの位置にあるかどうかを指示するためのものである、生成することをし、
リソーススケジューリング情報を受信端に送信するように送信機を制御するために、バスを使用して、メモリに記憶されているプログラムを実行する。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を含む。
オプションとして、割り当て予定の周波数ドメインリソースに割り振られる可能性があるリソースユニットの位置は、デフォルト位置を含み、デフォルト位置に対応するリソースユニットは、次世代プロトコルによって事前に定義されているような、ビットシーケンスによって指示されないリソースユニットである。
オプションとして、ビットシーケンスは、複数のtype-1ビットを含み、複数のtype-1ビットは、1対1ベースで複数のリソースユニットの位置のペアに対応し、type-1ビットのうちの1つは、対応するリソースユニットの位置のペア中のリソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するものであり、1つのリソースユニットの位置のペアは、デフォルト位置の一方のサイド上に位置する2つの連続した最小のリソースユニットの位置を含む。
オプションとして、ビットシーケンスは、複数のtype-2ビットを含み、type-2ビットは、対称中心の一方のサイド上における最大のリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。
オプションとして、ビットシーケンスは、2つのtype-3ビットを含み、2つのtype-3ビットは、1対1ベースで対称中心の双方のサイド上に位置する2つのリソースユニット位置グループに対応し、type-3ビットは、対応するリソースユニット位置グループ中のリソースユニットの位置にあるすべてのリソースユニットが割り当て予定のリソースユニットであるかどうかを指示するものであり、1つのリソースユニット位置グループは、割り当て予定の周波数ドメインリソースの中心の一方のサイド上に位置する複数の最小のリソースユニットの位置を含む。
オプションとして、リソーススケジューリング情報は、複数のスケジューリング済みの受信端の識別子をさらに含み、受信端の識別子は、実際の割り振りにおけるリソースユニットが複数の受信端に割り振られていることを指示するものである。
オプションとして、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースを指示する第1の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットがマルチユーザ多入力多出力MU-MIMOのために使用されているかどうかを指示する第2の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットが利用可能であるかどうかを指示する第3の指示情報をさらに含む。
オプションとして、プロセッサは、ビットシーケンスをプリアンブル内の高効率シグナリングフィールドAまたは高効率シグナリングフィールドBに付加し、ビットシーケンスを受信端に送信するように送信機を制御するように特に構成される、または、
プロセッサは、ビットシーケンスを媒体アクセス制御レイヤに付加し、ビットシーケンスを受信端に送信するように送信機を制御するように特に構成される。
オプションとして、デバイス500は、ネットワークデバイスであり、受信端は、端末デバイスである。
本発明の本実施形態は、様々な通信デバイスに適用され得る。
デバイス500の送信機は、送信機回路、電力コントローラ、エンコーダ、およびアンテナを備え得る。さらに、デバイス500は、受信機をさらに備え得る。受信機は、受信機回路、電力コントローラ、デコーダ、およびアンテナを備え得る。
プロセッサをCPUとさらに称し得る。メモリは、リードオンリーメモリおよびランダムアクセスメモリを含み、プロセッサに命令およびデータを提供し得る。メモリの一部は、不揮発性ランダムアクセスメモリ(NVRAM)をさらに含み得る。特定の活用においては、デバイス500が、内蔵されていてもよく、または、デバイス500自身が、ネットワークデバイスなどの無線通信デバイスであってもよく、デバイス500とリモートロケーションとの間のデータ伝送および受信を可能にするために、送信機回路および受信機回路を含むキャリアをさらに備えていてもよい。送信機回路および受信機回路は、アンテナに接続され得る。デバイス500内のコンポーネントは、バスを使用して一緒に結合される、ここで、バスは、データバスに加えて、電力バス、制御バス、および状態信号バスをさらに含む。しかしながら、明瞭な説明のために、様々なバスを図中ではバスとして示している。特に、異なる製品においては、デコーダを処理ユニットと一体化してもよい。
プロセッサは、本発明の方法の実施形態において開示したステップおよび論理ブロック図を実施または実行し得る。汎用プロセッサは、マイクロプロセッサであってもよいし、または、プロセッサは、任意の従来のプロセッサ、デコーダなどであってもよい。本発明の実施形態を参照して開示した方法のステップを、ハードウェアプロセッサによって直接実行および完了してもよいし、または、デコーディングプロセッサ内のハードウェアモジュールおよびソフトウェアモジュールの組合せを使用して実行および完了してもよい。ソフトウェアモジュールは、ランダムアクセスメモリ、フラッシュメモリ、リードオンリーメモリ、プログラマブルリードオンリーメモリ、電気的消去可能プログラマブルメモリ、またはレジスタなどといった、当該技術分野における成熟した記憶媒体にあってもよい。
本発明の実施形態においては、プロセッサは、中央処理ユニット(Central Processing Unit、略して、「CPU」)であり得る、または、プロセッサは、別の汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)または別のプログラマブルロジックデバイス、ディスクリートゲートまたはトランジスタロジックデバイス、ディスクリートハードウェアコンポーネントなどであり得ることを理解されたい。汎用プロセッサは、マイクロプロセッサであってもよいし、またはプロセッサは、任意の従来のプロセッサなどであってもよい。
メモリは、リードオンリーメモリおよびランダムアクセスメモリを含み、プロセッサに命令およびデータを提供し得る。メモリの一部は、不揮発性ランダムアクセスメモリをさらに含み得る。例えば、メモリは、デバイスタイプに関する情報をさらに記憶し得る。
バスシステムは、データバスに加えて、電力バス、制御バス、状態信号バスなどをさらに含み得る。しかしながら、明瞭な説明のために、図中の様々なバスをバスシステムとして示している。
ある実施プロセスにおいては、前述の方法の各ステップを、プロセッサ内のハードウェアの集積論理回路またはソフトウェアの形式の命令を使用して完了してもよい。本発明の実施形態を参照して開示した方法のステップを、ハードウェアプロセッサによって直接実行および完了してもよいし、または、プロセッサ内のハードウェアモジュールおよびソフトウェアモジュールの組合せを使用して実行および完了してもよい。ソフトウェアモジュールは、ランダムアクセスメモリ、フラッシュメモリ、リードオンリーメモリ、プログラマブルリードオンリーメモリ、電気的消去可能プログラマブルメモリ、またはレジスタなどといった、当該技術分野における成熟した記憶媒体にあってもよい。記憶媒体は、メモリにあり、プロセッサは、メモリ内の情報を読み出し、プロセッサのハードウェアと組み合わせて前述の方法におけるステップを完了する。繰り返しを避けるために、その詳細を本明細書では再び説明しない。
本発明の本実施形態による、リソーススケジューリングデバイス500は、本発明の実施形態の方法における送信端(例えば、ネットワークデバイス)に対応し得るし、リソーススケジューリングデバイス500内の各ユニットすなわち各モジュール、および前述の他の操作および/または機能は、図1中の方法100の対応するプロシージャを実施することをそれぞれ意図している。簡潔にするために、その詳細を本明細書では再び説明しない。
本発明の本実施形態による、リソーススケジューリングデバイスにおいては、ビットシーケンス中の少なくともいくつかのビットが、実際の割り振りにおけるリソースユニットの割り振りに基づくとともに、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置と比較することによって、割り当て予定の周波数ドメインリソースから実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースを分割することによって取得される可能性があるリソースユニットの位置にある1つまたは複数のリソースユニットの位置にあるかどうかを指示するものであり、異なる長さのビットシーケンスをフレキシブルに生成することを可能としている。したがって、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることを可能としている。
図22は、本発明の実施形態による、リソーススケジューリングデバイス600の概略ブロック図を示している。デバイス600は、無線ローカルエリアネットワークに適用され、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義する。図22に示したように、デバイス600は、
バス610と、
バスに接続されているプロセッサ620と、
バスに接続されているメモリ630と、
バスに接続されている受信機640とを備え、
プロセッサは、送信端によって送信されたリソーススケジューリング情報を受信するように受信機を制御することであって、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースについて実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置のうちの1つまたは複数のリソースユニットの位置にあるかどうかを指示するためのものである、制御することをし、
リソーススケジューリング情報に従って、受信端に送信端によって実際に割り振られたリソースユニットを決定するために、バスを使用して、メモリに記憶されているプログラムを実行する。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を含む。
オプションとして、割り当て予定の周波数ドメインリソースに割り振られる可能性があるリソースユニットの位置は、デフォルト位置を含み、デフォルト位置に対応するリソースユニットは、次世代プロトコルによって事前に定義されているような、ビットシーケンスによって指示されないリソースユニットである。
オプションとして、ビットシーケンスは、複数のtype-1ビットを含み、複数のtype-1ビットは、1対1ベースで複数のリソースユニットの位置のペアに対応し、type-1ビットのうちの1つは、対応するリソースユニットの位置のペア中のリソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するものであり、1つのリソースユニットの位置のペアは、デフォルト位置の一方のサイド上に位置する2つの連続した最小のリソースユニットの位置を含む。
オプションとして、ビットシーケンスは、複数のtype-2ビットを含み、type-2ビットは、対称中心の一方のサイド上における最大のリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。
オプションとして、ビットシーケンスは、2つのtype-3ビットを含み、2つのtype-3ビットは、1対1ベースで対称中心の双方のサイド上に位置する2つのリソースユニット位置グループに対応し、type-3ビットは、対応するリソースユニット位置グループ中のリソースユニットの位置にあるすべてのリソースユニットが割り当て予定のリソースユニットであるかどうかを指示するものであり、1つのリソースユニット位置グループは、割り当て予定の周波数ドメインリソースの中心の一方のサイド上に位置する複数の最小のリソースユニットの位置を含む。
オプションとして、リソーススケジューリング情報は、複数のスケジューリング済みの受信端の識別子をさらに含み、受信端の識別子は、実際の割り振りにおけるリソースユニットが複数の受信端に割り振られていることを指示するものである。
オプションとして、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースを指示する第1の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットがマルチユーザ多入力多出力MU-MIMOのために使用されているかどうかを指示する第2の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットが利用可能であるかどうかを指示する第3の指示情報をさらに含む。
オプションとして、受信端が送信端によって送信されたリソーススケジューリング情報を受信することは、
プリアンブル内の高効率シグナリングフィールドAまたは高効率シグナリングフィールドBにおいて搬送されるとともに送信端によって送信されたビットシーケンスを受信すること、または、
媒体アクセス制御レイヤにおいて搬送されるとともに送信端によって送信されたビットシーケンスを受信することを含む。
オプションとして、送信端は、ネットワークデバイスであり、デバイス600は、端末デバイスである。
本発明の本実施形態は、様々な通信デバイスに適用され得る。
デバイス600の受信機は、受信機回路、電力コントローラ、デコーダ、およびアンテナを備え得る。さらに、デバイス600は、送信機をさらに備え得る。送信機は、送信機回路、電力コントローラ、エンコーダ、およびアンテナを備え得る。
プロセッサをCPUとさらに称し得る。メモリは、リードオンリーメモリおよびランダムアクセスメモリを含み、プロセッサに命令およびデータを提供し得る。メモリの一部は、不揮発性ランダムアクセスメモリ(NVRAM)をさらに含み得る。特定の活用においては、デバイス600が、内蔵されていてもよく、または、デバイス600自身が、端末デバイスなどの無線通信デバイスであってもよく、デバイス600とリモートロケーションとの間のデータ伝送および受信を可能にするために、送信機回路および受信機回路を含むキャリアをさらに備えていてもよい。送信機回路および受信機回路は、アンテナに接続され得る。デバイス600内のコンポーネントは、バスを使用して一緒に結合される、ここで、バスは、データバスに加えて、電力バス、制御バス、および状態信号バスをさらに含む。しかしながら、明瞭な説明のために、様々なバスを図中ではバスとして示している。特に、異なる製品においては、デコーダを処理ユニットと一体化してもよい。
プロセッサは、本発明の方法の実施形態において開示したステップおよび論理ブロック図を実施または実行し得る。汎用プロセッサは、マイクロプロセッサであってもよいし、または、プロセッサは、任意の従来のプロセッサ、デコーダなどであってもよい。本発明の実施形態を参照して開示した方法のステップを、ハードウェアプロセッサによって直接実行および完了してもよいし、または、デコーディングプロセッサ内のハードウェアモジュールおよびソフトウェアモジュールの組合せを使用して実行および完了してもよい。ソフトウェアモジュールは、ランダムアクセスメモリ、フラッシュメモリ、リードオンリーメモリ、プログラマブルリードオンリーメモリ、電気的消去可能プログラマブルメモリ、またはレジスタなどといった、当該技術分野における成熟した記憶媒体にあってもよい。
本発明の実施形態においては、プロセッサは、中央処理ユニット(Central Processing Unit、略して、「CPU」)であり得る、または、プロセッサは、別の汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)または別のプログラマブルロジックデバイス、ディスクリートゲートまたはトランジスタロジックデバイス、ディスクリートハードウェアコンポーネントなどであり得ることを理解されたい。汎用プロセッサは、マイクロプロセッサであってもよいし、またはプロセッサは、任意の従来のプロセッサなどであってもよい。
メモリは、リードオンリーメモリおよびランダムアクセスメモリを含み、プロセッサに命令およびデータを提供し得る。メモリの一部は、不揮発性ランダムアクセスメモリをさらに含み得る。例えば、メモリは、デバイスタイプに関する情報をさらに記憶し得る。
バスシステムは、データバスに加えて、電力バス、制御バス、状態信号バスなどをさらに含み得る。しかしながら、明瞭な説明のために、図中の様々なバスをバスシステムとして示している。
ある実施プロセスにおいては、前述の方法の各ステップを、プロセッサ内のハードウェアの集積論理回路またはソフトウェアの形式の命令を使用して完了してもよい。本発明の実施形態を参照して開示した方法のステップを、ハードウェアプロセッサによって直接実行および完了してもよいし、または、プロセッサ内のハードウェアモジュールおよびソフトウェアモジュールの組合せを使用して実行および完了してもよい。ソフトウェアモジュールは、ランダムアクセスメモリ、フラッシュメモリ、リードオンリーメモリ、プログラマブルリードオンリーメモリ、電気的消去可能プログラマブルメモリ、またはレジスタなどといった、当該技術分野における成熟した記憶媒体にあってもよい。記憶媒体は、メモリにあり、プロセッサは、メモリ内の情報を読み出し、プロセッサのハードウェアと組み合わせて前述の方法におけるステップを完了する。繰り返しを避けるために、その詳細を本明細書では再び説明しない。
本発明の本実施形態による、リソーススケジューリングデバイス600は、本発明の実施形態の方法における受信端(例えば、端末デバイス)に対応し得るし、リソーススケジューリングデバイス600内の各ユニットすなわち各モジュール、および前述の他の操作および/または機能は、図18中の方法200の対応するプロシージャを実施することをそれぞれ意図している。簡潔にするために、その詳細を本明細書では再び説明しない。
本発明の本実施形態による、リソーススケジューリングデバイスにおいては、ビットシーケンス中の少なくともいくつかのビットが、実際の割り振りにおけるリソースユニットの割り振りに基づくとともに、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置と比較することによって、割り当て予定の周波数ドメインリソースから実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースを分割することによって取得される可能性があるリソースユニットの位置にある1つまたは複数のリソースユニットの位置にあるかどうかを指示するものであり、異なる長さのビットシーケンスをフレキシブルに生成することを可能としている。したがって、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることを可能としている。
前述のプロセスのシーケンス番号は本発明の様々な実施形態における実行順序を意味していないことを理解されたい。プロセスの実行順序は、プロセスの関数および内部ロジックに従って決定されるべきであり、本発明の実施形態の実施プロセスにおける如何なる限定としてもみなすべきではない。
当業者は、本明細書に開示した実施形態において説明した例と組み合わせて、ユニットおよびアルゴリズムステップを電子ハードウェアまたはコンピュータソフトウェアおよび電子ハードウェアの組合せによって実装することができることに気づくであろう。機能をハードウェアで行うかまたはソフトウェアで行うかは、具体的な活用および技術的ソリューションの設計上の制約条件に依存する。当業者は、異なる方法を使用して具体的な活用の各々のための説明した機能を実施してもよいが、その実施形態が本発明の範囲を逸脱しているとみなすべきではない。
簡便かつ簡潔な説明を目的として、前述のシステム、装置、およびユニットの詳細な動作プロセスについては、前述の方法の実施形態における対応するプロセスを参照されたいことは当業者によって明確に理解されよう、そのためその詳細を本明細書では再び説明しない。
本出願に提供したいくつかの実施形態においては、開示したシステム、装置、および方法を他の方式で実施してもよいことを理解されたい。例えば、説明した装置の実施形態は例にすぎない。例えば、ユニット分割は、論理的な機能分割にすぎず、実際の実施形態においては他の分割であってもよい。例えば、複数のユニットまたはコンポーネントを組み合わせても別のシステムと統合してもよいし、またはいくつかの特徴を無視しても行わなくてもよい。加えて、図示または記載した相互接続または直接接続または通信接続は、いくつかのインターフェースによって実施されてもよい。装置間またはユニット間の間接接続または通信接続は、電子的に、機械的に、または他の形式で実施されてもよい。
別個の部分として説明したユニットは、物理的に別個のものであってもなくてもよいし、ユニットとして図示した部分は、物理ユニットであってもなくてもよいし、1つのロケーションに配置されていてもよいし、または複数のネットワークユニットに分散されていてもよい。ユニットの一部またはすべては、実施形態のソリューションの目的を達成するために、実際の要件に従って選択してもよい。
加えて、本発明の実施形態における機能ユニットは1つの処理ユニットに統合されてもよいし、または、ユニットの各々は物理的に単独で存在してもよいし、または、2つ以上のユニットは1つのユニットに統合される。
機能を、ソフトウェア機能ユニットの形式で実装し、独立した製品として販売または使用する場合には、機能は、コンピュータ可読記憶媒体に記憶され得る。そのような理解に基づいて、基本的に、本発明の技術的解決手法、または従来技術に貢献する部分、またはいくつかの技術的解決手法は、ソフトウェア製品の形式で実装されてもよい。ソフトウェア製品は、記憶媒体に記憶されており、本発明の実施形態において説明した方法のステップのすべてまたは一部を行うように(パーソナルコンピュータ、サーバ、または送信端であり得る)コンピュータデバイスに命令するいくつかの命令を含む。前述の記憶媒体は、USBフラッシュドライブ、リムーバブルハードディスク、リードオンリーメモリ(ROM、Read-Only Memory)、ランダムアクセスメモリ(RAM、Random Access Memory)、磁気ディスク、または光ディスクなどといった、プログラムコードを記憶することができる任意の媒体を含む。
前述の説明は、本発明の特定の実施形態にすぎず、本発明の保護範囲を限定することを意図していない。本発明に開示の技術的範囲において当業者が容易に想到する任意の変形または置換は、本発明の保護範囲に含まれるものとする。したがって、本発明の保護範囲は、特許請求の範囲の保護範囲に従うものとする。
本発明の実施形態をより明確にするために、簡易な用語で表した実施形態を以下に提供する。
300 リソーススケジューリング装置
310 生成ユニット
320 送信ユニット
400 リソーススケジューリング装置
410 受信ユニット
420 決定ユニット
510 バス
520 プロセッサ
530 メモリ
540 送信機
610 バス
620 プロセッサ
630 メモリ
640 受信機
本発明は、通信技術の分野に関し、より具体的には、リソーススケジューリング方法、装置、およびデバイスに関する。
直交周波数分割多元接続(OFDMA、Orthogonal Frequency Division Multiple Access)伝送技術およびマルチユーザ多入力多出力(MU-MIMO、Multiple User-MIMO)伝送技術などの技術の発展に伴い、現在では、通信システムは、マルチユーザ伝送を既にサポートすることが可能となっている、すなわち、データを同時に送信および受信する際に複数のステーションをサポートすることが可能になっている。
しかしながら、前述のマルチユーザ伝送(例えば、OFDMAモード、MU-MIMOモード、またはOFDMAおよびMU-MIMOハイブリッド伝送モードを含む)において複数のユーザのためのリソーススケジューリングをどのように行うかについては、ソリューションを提供する必要がある。
現在既知のリソーススケジューリングソリューションによれば、ビットシーケンスは、割り振り予定の帯域幅におけるリソースユニットを指示するものである、すなわち、ビットシーケンス中の1ビットは、1つのリソースサブユニット(1つのリソースサブユニットは1×26個のサブキャリアを含む)の割り振りを指示し、ビットシーケンス内での0と1との間の切り替えは、切り替え前のビットによって指示されるリソースユニットと切り替え後のビットによって指示されるリソースユニットとが異なるユーザに割り振られることを指示している。
例えば、割り振り予定の帯域幅が20メガヘルツ(MHz)である場合には、9つのリソースサブユニットが含まれており、9ビットのビットシーケンスは、リソース割り振りを指示するものである必要がある。さらに、帯域幅が増大するにつれて、ビットシーケンスの長さも連続的に増大することになる、すなわち、従来技術のリソーススケジューリングソリューションでは、大量の伝送リソースを、ビットシーケンスを送信するために占有する必要がある。
したがって、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることができる技術を提供することが期待されている。
本発明の実施形態は、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることができる、リソーススケジューリング方法、装置、およびデバイスを提供している。
第1の態様に従って、リソーススケジューリング方法を、提供しているとともに、無線ローカルエリアネットワークに適用し、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義し、方法は、送信端によって、リソーススケジューリング情報を生成するステップであって、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースに割り振られる可能性がある1つまたは複数のリソースユニットの位置が実際に割り振られたリソースユニットであるかどうかを指示するものである、ステップと、リソーススケジューリング情報を受信端に送信するステップとを含む。
第2の態様に従って、リソーススケジューリング方法を、提供しているとともに、無線ローカルエリアネットワークに適用し、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義し、方法は、受信端によって、送信端によって送信されたリソーススケジューリング情報を受信するステップであって、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースについて実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置のうちの1つまたは複数のリソースユニットの位置にあるかどうかを指示するためのものである、ステップと、リソーススケジューリング情報に従って、受信端に送信端によって実際に割り振られたリソースユニットを決定するステップとを含む。
第3の態様に従って、リソーススケジューリング装置を、提供しているとともに、無線ローカルエリアネットワーク内に構成し、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義し、装置は、リソーススケジューリング情報を生成するように構成される、生成ユニットであって、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースについて実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置のうちの1つまたは複数のリソースユニットの位置にあるかどうかを指示するためのものである、生成ユニットと、リソーススケジューリング情報を受信端に送信するように構成される、送信ユニットとを備える。
第4の態様に従って、リソーススケジューリング装置を、提供しているとともに、無線ローカルエリアネットワーク内に構成し、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義し、装置は、送信端によって送信されたリソーススケジューリング情報を受信するように構成される、受信ユニットであって、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースについて実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置のうちの1つまたは複数のリソースユニットの位置にあるかどうかを指示するためのものである、受信ユニットと、リソーススケジューリング情報に従って、受信端に送信端によって実際に割り振られたリソースユニットを決定するように構成される、決定ユニットとを備える。
本発明の実施形態による、リソーススケジューリング方法、装置、およびデバイスにおいては、ビットシーケンス中の少なくともいくつかのビットが、実際の割り振りにおけるリソースユニットの割り振りに基づくとともに、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置と比較することによって、割り当て予定の周波数ドメインリソースから実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性がある1つまたは複数のリソースユニットの位置にあるかどうかを指示するものであり、異なる長さのビットシーケンスをフレキシブルに生成することを可能としている。したがって、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることを可能としている。
本発明の実施形態における技術的ソリューションをより明確に説明するために、実施形態または従来技術を説明するのに必要な添付の図面を以下に簡単に説明している。以下の説明における添付の図面が本発明の一部の実施形態を示しているにすぎず、当業者が創造的努力なしにこれらの添付の図面から他の図面をさらに導出し得ることは明らかであろう。
本発明の実施形態による、リソーススケジューリング方法の概略フローチャートである。
WLANシステムの概略アーキテクチャ図である。
20MHz帯域幅を有する周波数ドメインリソースの割り振りの概略図である。
20MHz帯域幅におけるリソースユニットの割り振り位置の概略図である。
40MHz帯域幅におけるリソースユニットの割り振り位置の概略図である。
80MHz帯域幅におけるリソースユニットの割り振り位置の概略図である。
ビットシーケンス生成プロセスの例の概略図である。
ビットシーケンス生成プロセスの別の例の概略図である。
ビットシーケンス生成プロセスのさらに別の例の概略図である。
ビットシーケンス生成プロセスのさらに別の例の概略図である。
ビットシーケンス生成プロセスのさらに別の例の概略図である。
ビットシーケンス生成プロセスのさらに別の例の概略図である。
ビットシーケンス生成プロセスのさらに別の例の概略図である。
本発明の実施形態による、割り当て予定の周波数ドメインリソースの例の概略図である。
802.11axパケットの概略構造図である。
本発明の実施形態による、リソーススケジューリング情報の例の概略図である。
本発明の実施形態による、リソーススケジューリング情報の別の例の概略図である。
本発明の実施形態による、リソーススケジューリング方法の概略フローチャートである。
本発明の実施形態による、リソーススケジューリング装置の概略ブロック図である。
本発明の別の実施形態による、リソーススケジューリング装置の概略ブロック図である。
本発明の実施形態による、リソーススケジューリングデバイスの概略構造図である。
本発明の別の実施形態による、リソーススケジューリングデバイスの概略構造図である。
本ソリューションにおけるビットシーケンスが表1のものと一致している、ビットシーケンス生成またはパースプロセスの簡略概略図である。
本ソリューションにおけるビットシーケンスが表1のものと一致している、ビットシーケンス生成またはパースプロセスの簡略概略図である。
本ソリューションにおけるビットシーケンスが表1のものと一致している、ビットシーケンス生成またはパースプロセスの簡略概略図である。
本ソリューションにおけるビットシーケンスが表3のものと一致している、別のビットシーケンス生成またはパースプロセスの簡略概略図である。
本ソリューションにおけるビットシーケンスが表3のものと一致している、別のビットシーケンス生成またはパースプロセスの簡略概略図である。
本発明の実施形態における添付の図面を参照して、本発明の実施形態における技術的解決手法を以下に明確かつ完全に説明する。説明した実施形態が本発明の実施形態のすべてではなく一部であることは明らかであろう。創造的努力なしに本発明の実施形態に基づいて当業者によって得られる他の実施形態のすべては、本発明の保護範囲に含まれるものとする。
図1は、本発明の実施形態による、リソーススケジューリング方法100の概略フローチャートである、ここで、方法を送信端の観点から説明している。方法100は、無線ローカルエリアネットワークに適用され、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義する。図1に示したように、方法100は、以下のステップを含む。
S110. 送信端が、リソーススケジューリング情報を生成する、ここで、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースについて実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置のうちの1つまたは複数のリソースユニットの位置にあるかどうかを指示するものである。
S120. リソーススケジューリング情報を受信端に送信する。
方法100は、リソーススケジューリングによってマルチユーザ伝送を実施する様々な通信システム、例えば、OFDMAモード、MU-MIMOモードなどで通信を行うシステムに適用され得る。
さらに、方法100は、無線ローカルエリアネットワーク(WLAN、Wireless Local Area Network)、例えば、ワイヤレス・フィディリティ(Wi-Fi、Wireless Fidelity)に適用され得る。
図2は、WLANシステムの概略図である。図2に示したように、WLANシステムは、1つまたは複数のアクセスポイントAP21を含み、1つまたは複数のステーションSTA22をさらに含む。データ伝送がアクセスポイントとステーションとの間で行われる。ステーションは、アクセスポイントによって送信されたプリアンブルに従って、ステーションのためにスケジューリングされたリソースを決定し、リソースに基づいて、アクセスポイントとデータ伝送を行う。
オプションとして、送信端は、ネットワークデバイスであり、受信端は、端末デバイスである。
特に、送信端デバイスとして、通信システム内のネットワークサイドデバイスが、図示され得るし、例えば、WLAN内のアクセスポイント(AP、Access Point)であり得る。APはまた、無線アクセスポイント、ブリッジ、ホットスポットなどと称され得るし、APは、サーバまたは通信ネットワークにアクセスし得る。
受信端デバイスとして、通信システム内の端末デバイスが、図示され得るし、例えば、WLAN内のステーション(STA)であり得る。STAはまた、ユーザと称され得るし、無線センサ、無線通信端末、または、例えば、携帯電話(もしくは、「セルラ」電話と称する)および無線通信機能を有するコンピュータといったモバイル端末であり得る。例えば、STAは、無線アクセスネットワークと音声およびデータなどの通信データを交換する、ポータブル型、ポケットサイズ型、ハンドヘルド型、コンピュータ内蔵型、ウェアラブル型、または車載型無線通信装置であり得る。
本発明の本実施形態の方法100が適用可能であるシステムを説明した上記は例にすぎず、本発明はそれに限定されないことを理解されたい。例えば、グローバル・システム・フォー・モバイル・コミュニケーションズ(GSM(登録商標)、Global System of Mobile communication)、符号分割多元接続(CDMA、Code Division Multiple Access)システム、広帯域符号分割多元接続(WCDMA(登録商標)、Wideband Code Division Multiple Access Wireless)、汎用パケット無線システム(GPRS、General Packet Radio Service)、およびロング・ターム・エボリューション(LTE、Long Term Evolution)システムを以下にさらに説明し得る。
それに対応するように、ネットワークデバイスは、GSM(登録商標)またはCDMAにおける基地局(BTS、Base Transceiver Station)であり得るし、または、WCDMA(登録商標)における基地局(NodeB)であり得るし、または、LTEにおける発展型基地局(eNBもしくはe-NodeB、evolutional Node B)であり得るし、スモールセル基地局であり得る、これは、マイクロ基地局(Micro)であり得るし、もしくはピコ基地局(Pico)であり得るし、もしくは、フェムトセル基地局(フェムト)とも称されるホーム基地局であり得るが、本発明においてこのことに限定されない。端末デバイスは、例えば、携帯電話(または、「セルラ」電話と称される)といった、モバイル端末(Mobile Terminal)、またはモバイルユーザ機器であり得る。
WLANシステムにおいて割り振られるリソースユニットのサイズに関するルールは、リソースユニットとして26個のサブキャリアを使用することである。
図3に示したように、一例として20メガヘルツ(MHz)帯域幅を使用すれば、WLANシステムにおけるデータシンボル部分の離散フーリエ変換または逆離散フーリエ変換(DFT/IDFT)の点の数量は、256である、すなわち、256個のサブキャリアが存在する。サブキャリア-1、0、および1は、直流(Direct Current、DC)成分であり、左サイドバンドサブキャリア-122からサブキャリア-2および右サイドバンドサブキャリア2からサブキャリア122は、データ情報を搬送するものである、すなわち、242個のサブキャリアがデータ情報を搬送するものである。サブキャリア-128からサブキャリア-123およびサブキャリア123からサブキャリア128は、ガードバンドである。したがって、一般的に、データ情報を搬送する242個のサブキャリアは、9つのリソースサブユニットにグループ分けされる、ここで、各リソースサブユニットは、26個のサブキャリアを含み、8つの残りのサブキャリアは未使用である。さらに、クロスDC(すなわち、サブキャリア-1、0、および1を含む)リソースサブユニットは、帯域幅の中心にある。本発明の本実施形態における方法100は、データ情報を搬送する242個のサブキャリアの割り振りに主に関連する。
異なる帯域幅を有する周波数ドメインリソース内に含むことができるリソースユニット(リソースブロックとも称する)のタイプは異なる。特に、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソース(20MHz、40MHz、80MHz、または160MHz)から割り振られる可能性があるリソースユニットの位置(リソース割り振りマップ)を事前に定義している。送信端は、リソーススケジューリング情報を生成および送信する、ここで、リソーススケジューリング情報は、割り振られた割り当て予定のリソースユニットを指示するビットシーケンスを含む。受信端は、ビットシーケンスを読み出すことによって、割り当て予定の周波数ドメインリソースを分割することでどのリソースユニットが取得されるかを知り得る。
加えて、リソーススケジューリング情報は、割り振られたリソースユニットに対応するスケジューリング済みの受信端に関する情報をさらに含み得る。このように、リソーススケジューリング情報を読み出すことによって、受信端は、受信端に割り振られるリソースユニット上でアップリンクおよびダウンリンク情報の伝送を実施する。
次世代プロトコルよって事前に定義されているような、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を(図4、図5、または図6に示したリソース割り振りマップを参照して)まず以下に詳細に説明する。
1. 20MHz帯域幅の周波数ドメインリソースについて
オプションとして、割り当て予定の周波数ドメインリソースに割り振られる可能性があるリソースユニットの位置は、デフォルト位置を含み、デフォルト位置に対応するリソースユニットは、次世代プロトコルによって事前に定義され得るような、ビットシーケンスによって指示されないリソースユニットである。オプションとして、1ビットが、デフォルト位置にあるリソースユニットが使用のためにユーザに割り振られているかどうかを指示するためのものであってもよい。
特に、図4に示したように、20MHz帯域幅の周波数ドメインリソースは、中心に位置するデフォルトリソースユニット(すなわち、デフォルト位置に位置するリソースユニット)を含み得るし、デフォルトリソースユニットは、1×26トーンリソースユニット、すなわち、26個のサブキャリアを含むクロスDC(すなわち、サブキャリア-1、0、および1)リソースユニットであり得る。デフォルトリソースユニットは、デフォルトで通信システムに存在しており、独立して割り振られる、すなわち、20MHz帯域幅を有する各割り当て予定のリソースにおいて、デフォルト1×26トーンリソースユニットは、リソースの中心位置から割り振られる。デフォルトリソースユニットは、受信端に独立して割り振られている。デフォルトリソースユニットが割り振られている受信端は、デフォルトリソースユニットの左サイドまたは右サイド上の隣接リソースユニットが割り振られている受信端と同一または異なり得る。このことは本発明において特に限定されない。20MHz帯域幅については、デフォルトリソースユニットが割り振られている受信端が、デフォルトリソースユニットの左サイドまたは右サイド上の隣接リソースユニットが割り振られている受信端と同一である場合には、20MHz帯域幅が1人のユーザだけに割り振られていることを指示する。さもなければ、デフォルトリソースユニットが割り振られている受信端は、デフォルトリソースユニットの左サイドまたは右サイド上の隣接リソースユニットが割り振られている受信端とは異なる。
デフォルト位置に位置するデフォルトリソースユニットに加えて、20MHz帯域幅の周波数ドメインリソースは、20MHz帯域幅の周波数ドメインリソースの中心におけるデフォルトリソースユニットの左サイドまたは右サイドにそれぞれ位置する、以下の4つのタイプのリソースユニットをさらに含む、すなわち、
リソースユニットが1つのリソースサブユニット(すなわち、26個のサブキャリア)を含んでいることを指示する、1×26トーンリソースユニット、20MHz帯域幅において割り振られる可能性がある最小のリソースユニットと、
リソースユニットが2つのリソースサブユニット(すなわち、2×26個のサブキャリア)を含んでいることを指示する、2×26トーンリソースユニットと、
リソースユニットが4つのリソースサブユニット(すなわち、4×26個のサブキャリア)を含んでいることを指示する、4×26トーンリソースユニットと、
リソースユニットが242個のサブキャリアを含んでいることを指示する、242トーンリソースユニット、20MHz帯域幅において割り振られる可能性がある最大のリソースユニットとをさらに含む。
4×26トーンリソースユニットは、106個のサブキャリアを含む、すなわち、102個のデータサブキャリアと4個のパイロットサブキャリアとを含む。繰り返しを避けるために、同一または同様のケースに関する説明は以下では省略する。
図4に示したように、割り振られる可能性があるリソースユニットの位置を簡潔に説明するために、20MHz帯域幅におけるリソースユニットの割り振りマップを4つのレイヤとして図示または説明している。
第1のレイヤは、1×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、20MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。中心に位置するデフォルトリソースユニットの左サイドおよび右サイド上に、4つの1×26トーンリソースユニットがそれぞれ存在する、すなわち、図4に示したリソースユニットの位置に位置するリソースユニット(略して、位置と以降称する)#7から位置#10および位置#11から位置#14が存在する。
第2のレイヤは、2×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、20MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。中心に位置するデフォルトリソースユニットの左サイドおよび右サイド上に、2つの2×26トーンリソースユニットがそれぞれ存在する、すなわち、図4に示した位置#1から位置#4に位置するリソースユニットが存在する。
第3のレイヤは、4×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、20MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。中心に位置するデフォルトリソースユニットの左サイドおよび右サイド上に、1つの4×26トーンリソースユニットがそれぞれ存在する、すなわち、図4に示した位置#5および位置#6に位置するリソースユニットが存在する。
第4のレイヤは、242トーンリソースユニットの割り振りマップである。図4に示したように、242トーンリソースユニットは、前述の対称中心が位置するサブキャリアを含む。
ある例においては、20MHz帯域幅の周波数ドメインリソース(すなわち、割り当て予定の周波数ドメインリソースの例)は、242個のサブキャリアを含み、図4中の第1のレイヤから第3のレイヤにおいて任意のリソースユニットに分割され得る。割り振られたリソースユニットを複数のユーザに割り振り、割り振られたただ1つのリソースユニットを各ユーザに割り振ることができる。
あるいは、別の例においては、20MHz帯域幅の周波数ドメインリソースは、第4のレイヤにおいてリソースユニットに分割されてもよい。この場合には、20MHz帯域幅の周波数ドメインリソースは、1人のユーザに割り振られ、リソース割り振りは、前述した帯域幅指示情報およびシングルユーザ伝送指示ビットを使用して指示され得る。
別の例においては、20MHz帯域幅の周波数ドメインリソースは、第4のレイヤにおいてリソースユニットに分割されてもよい。この場合には、20MHz帯域幅の周波数ドメインリソースは、MU-MIMOのための複数のユーザに割り振られ、リソース割り振りは、前述した帯域幅指示情報およびマルチユーザ伝送指示ビットを使用して指示され得る。
本発明におけるリソーススケジューリングモードは、20MHz帯域幅の周波数ドメインリソースが、第1のレイヤから第3のレイヤにおける任意のリソースユニットの組合せを含み、複数のユーザに割り振られるケースに主に関連する。
例えば、図7は、20MHz帯域幅の周波数ドメインリソースの例を示している。図7に示したように、周波数ドメインリソースは、(図7中では左から右の順に)2つの2×26トーンリソースユニット(すなわち、リソースユニット#1およびリソースユニット#2)、1つの1×26トーンリソースユニット(すなわち、デフォルトリソースユニットである、リソースユニット#0)、および1つの4×26トーンリソースユニット(すなわち、リソースユニット#3)に分割される。
別の例では、図8は、20MHz帯域幅の周波数ドメインリソースの別の例を示している。図8に示したように、周波数ドメインリソースは、(図8中では左から右の順に)1つの2×26トーンリソースユニット(すなわち、リソースユニット#1')、3つの1×26トーンリソースユニット(すなわち、リソースユニット#2'、リソースユニット#3'、およびリソースユニット#0'、ここで、リソースユニット#0'は、デフォルトリソースユニットである)、および1つの4×26トーンリソースユニット(すなわち、リソースユニット#4')に分割される。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を含む。
特に、図4に示したように、20MHz帯域幅の周波数ドメインリソースは、中心に位置するリソースユニット(すなわち、デフォルト位置にあるリソースユニット)を含み、中心に位置するリソースユニットの双方のサイド上のリソースユニットの位置は、対称的に配分されている、すなわち、中心に位置するリソースユニットは、20MHz帯域幅の周波数ドメインリソースの対称中心として使用され得る。
2. 40MHz帯域幅の周波数ドメインリソースについて
40MHz帯域幅の周波数ドメインリソースが2つの20MHz帯域幅の周波数ドメインリソースを含むと扱われ得る。それに対応するように、どちらかの20MHz帯域幅の周波数ドメインリソースが、20MHz帯域幅の中心に位置するデフォルトリソースユニット(すなわち、デフォルト位置に位置するリソースユニット)を含み得るし、40MHz帯域幅におけるデフォルトリソースユニット(合計で2つのデフォルトリソースユニット)のコンポーネントおよび割り振りモードは、コンポーネントおよび20MHz帯域幅におけるデフォルトリソースユニットの割り振りモードと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
オプションとして、2ビットが、帯域幅において2つのデフォルト位置にあるリソースユニットが使用のためにユーザに割り振られているかどうかをそれぞれ指示するものであってもよい。デフォルト位置に位置するデフォルトリソースユニットに加えて、40MHz帯域幅の周波数ドメインリソースは、40MHz帯域幅の周波数ドメインリソースの中心周波数の左サイドまたは右サイドにそれぞれ位置する、以下の5つのタイプのリソースユニットをさらに含む、すなわち、
リソースユニットが1つのリソースサブユニット(すなわち、26個のサブキャリア)を含んでいることを指示する、1×26トーンリソースユニット、40MHz帯域幅において割り振られる可能性がある最小のリソースユニットと、
リソースユニットが2つのリソースサブユニット(すなわち、2×26個のサブキャリア)を含んでいることを指示する、2×26トーンリソースユニットと、
リソースユニットが4つのリソースサブユニット(すなわち、4×26個のサブキャリア)を含んでいることを指示する、4×26トーンリソースユニットと、
リソースユニットが242個のサブキャリアを含んでいることを指示する、242トーンリソースユニットと、
リソースユニットが2×242個のサブキャリアを含んでいることを指示する、2×242、40MHz帯域幅において割り振られる可能性がある最大のリソースユニットとをさらに含む。
図5に示したように、割り振られる可能性があるリソースユニットの位置を簡潔に説明するために、40MHz帯域幅におけるリソースユニットの割り振りマップを5つのレイヤとして図示または説明している。
第1のレイヤは、1×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、どちらかの20MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。どちらかのデフォルトリソースユニットの左サイドおよび右サイド上には、4つの1×26トーンリソースユニットがそれぞれ存在している。どちらかの20MHz帯域幅における8つの1×26トーンリソースユニットの割り振りは、図4中の第1のレイヤにおいて示した1×26トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第2のレイヤは、2×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、どちらかの20MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。どちらかのデフォルトリソースユニットの左サイドおよび右サイド上には、2つの2×26トーンリソースユニット(例えば、図5中の位置#Eおよび位置#F)がそれぞれ存在している。どちらかの20MHz帯域幅における4つの2×26トーンリソースユニットの割り振りは、図4中の第2のレイヤにおいて示した1×26トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第3のレイヤは、4×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、どちらかの20MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。どちらかのデフォルトリソースユニットの左サイドおよび右サイド上には、1つの4×26トーンリソースユニット(例えば、図5中の位置#Cおよび位置#D)がそれぞれ存在している。どちらかの20MHz帯域幅における4×26トーンリソースユニットの割り振りは、図4中の第3のレイヤにおいて示した4×26トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第4のレイヤは、242トーンリソースユニットの割り振りマップである。40MHzの中心周波数(すなわち、サブキャリア0)の左サイドおよび右サイド上には、1つの242トーンリソースユニット、すなわち、図5に示した位置#Aおよび位置#Bに位置するリソースユニットがそれぞれ存在している。
第5のレイヤは、4×242トーンリソースユニットの割り振りマップである。
ある例においては、40MHz帯域幅の周波数ドメインリソース(すなわち、割り当て予定の周波数ドメインリソースの例)は、484個のサブキャリアを含み、図5中の第1のレイヤから第4のレイヤにおいて任意のリソースユニットに分割され得る。割り振られたリソースユニットを複数のユーザに割り振り、割り振られたただ1つのリソースユニットを各ユーザに割り振ることができる。
あるいは、別の例においては、40MHz帯域幅の周波数ドメインリソースは、第5のレイヤにおいてリソースユニットに分割されてもよい。この場合には、40MHz帯域幅の周波数ドメインリソースは、1人のユーザに割り振られ、リソース割り振りは、前述した帯域幅指示情報およびシングルユーザ伝送指示ビットを使用して指示され得る。
別の例においては、40MHz帯域幅の周波数ドメインリソースは、第5のレイヤにおいてリソースユニットに分割されてもよい。この場合には、40MHz帯域幅の周波数ドメインリソースは、MU-MIMOのための複数のユーザに割り振られ、リソース割り振りは、前述した帯域幅指示情報およびマルチユーザ伝送指示ビットを使用して指示され得る。
本発明におけるリソーススケジューリングモードは、40MHz帯域幅の周波数ドメインリソースが、第1のレイヤから第4のレイヤにおける任意のリソースユニットの組合せを含み、複数のユーザに割り振られるケースに主に関連する。
例えば、図10は、40MHz帯域幅の周波数ドメインリソースの例を示している。図10に示したように、周波数ドメインリソースは、(図10中では左から右の順に)2つの2×26トーンリソースユニット(すなわち、リソースユニット#1''およびリソースユニット#2'')、1つの1×26トーンリソースユニット(すなわち、デフォルトリソースユニットである、リソースユニット#0'')、1つの4×26トーンリソースユニット(すなわち、リソースユニット#3'')、および1つの242トーンリソースユニット(すなわち、リソースユニット#4'')に分割される。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を含む。
特に、図4に示したように、40MHz帯域幅の周波数ドメインリソースの中心周波数の双方のサイド上の様々なリソースユニットの位置は、対称的に配分されている、すなわち、中心周波数は、40MHz帯域幅の周波数ドメインリソースの対称中心として使用され得る。
3. 80MHz帯域幅の周波数ドメインリソースについて
オプションとして、割り当て予定の周波数ドメインリソースに割り振られる可能性があるリソースユニットの位置は、デフォルト位置を含み、デフォルト位置に対応するリソースユニットは、次世代プロトコルによって事前に定義され得るような、ビットシーケンスによって指示されないリソースユニットである。
オプションとして、5ビットが、帯域幅において5つのデフォルト位置にあるリソースユニットが使用のためにユーザに割り振られているかどうかをそれぞれ指示するものであってもよい。
特に、図6に示したように、80MHz帯域幅の周波数ドメインリソースは、中心に位置するデフォルトリソースユニット(すなわち、デフォルト位置に位置するリソースユニット)を含み得るし、デフォルトリソースユニットは、1×26トーンリソースユニット、すなわち、26個のサブキャリアを含むクロスDC(すなわち、サブキャリア-1、0、および1)リソースユニットであり得る。デフォルトリソースユニットは、デフォルトで通信システムに存在しており、独立して割り振られる、すなわち、80MHz帯域幅を有する各割り当て予定のリソースにおいて、デフォルト1×26トーンリソースユニットは、リソースの中心位置から割り振られる。デフォルトリソースユニットは、受信端に独立して割り振られている。デフォルトリソースユニットが割り振られている受信端は、デフォルトリソースユニットの左サイドまたは右サイド上の隣接リソースユニットが割り振られている受信端と同一または異なり得る。このことは本発明において特に限定されない。80MHz帯域幅については、デフォルトリソースユニットが割り振られている受信端が、デフォルトリソースユニットの左サイドまたは右サイド上の隣接リソースユニットが割り振られている受信端と同一である場合には、80MHz帯域幅が1人のユーザだけに割り振られていることを指示する。さもなければ、デフォルトリソースユニットが割り振られている受信端は、デフォルトリソースユニットの左サイドまたは右サイド上の隣接リソースユニットが割り振られている受信端とは異なる。
さらに、80MHz帯域幅の周波数ドメインリソースが2つの40MHz帯域幅の周波数ドメインリソースおよび対称中心に位置するデフォルトリソースユニットを含むと扱われ得るし、どちらかの40MHz帯域幅の周波数ドメインリソースが2つの20MHz周波数ドメインリソースを含むと扱われ得る。それに対応するように、各20MHz帯域幅の周波数ドメインリソースは、20MHz帯域幅の中心に位置するデフォルトリソースユニット(すなわち、デフォルト位置に位置するリソースユニット)を含み得る。
デフォルト位置に位置するデフォルトリソースユニットに加えて、80MHz帯域幅の周波数ドメインリソースは、80MHz帯域幅の周波数ドメインリソースの中心におけるデフォルトリソースユニットの左サイドまたは右サイドにそれぞれ位置する、以下の6つのタイプのリソースユニットをさらに含む、すなわち、
リソースユニットが1つのリソースサブユニット(すなわち、26個のサブキャリア)を含んでいることを指示する、1×26トーンリソースユニット、80MHz帯域幅において割り振られる可能性がある最小のリソースユニットと、
リソースユニットが2つのリソースサブユニット(すなわち、2×26個のサブキャリア)を含んでいることを指示する、2×26トーンリソースユニットと、
リソースユニットが4つのリソースサブユニット(すなわち、4×26個のサブキャリア)を含んでいることを指示する、4×26トーンリソースユニットと、
リソースユニットが242個のサブキャリアを含んでいることを指示する、242トーンリソースユニットと、
リソースユニットが2×242個のサブキャリアを含んでいることを指示する、2×242トーンリソースユニットと、
リソースユニットが996個のサブキャリアを含んでいることを指示する、996トーンリソースユニット、80MHz帯域幅において割り振られる可能性がある最大のリソースユニットとをさらに含む。
割り振られる可能性があるリソースユニットの位置を簡潔に説明するために、40MHz帯域幅におけるリソースユニットの割り振りマップを6つのレイヤとして図示または説明している。
第1のレイヤは、1×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、各20MHz帯域幅の中心位置に位置する1×26トーンリソースユニットおよび80MHz帯域幅の中心に位置する1×26トーンリソースユニット)の割り振りマップである。各20MHz帯域幅の中心位置にあるデフォルトリソースユニットの左サイドおよび右サイド上には、4つの1×26トーンリソースユニットがそれぞれ存在している。各20MHz帯域幅における1×26トーンリソースユニットの割り振りは、図4中の第1のレイヤにおいて示した1×26トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第2のレイヤは、2×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、各20MHz帯域幅の中心位置に位置する1×26トーンリソースユニットおよび80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。各20MHz帯域幅の中心位置にあるデフォルトリソースユニットの左サイドおよび右サイド上には、2つの2×26トーンリソースユニットがそれぞれ存在している。各20MHz帯域幅における2×26トーンリソースユニットの割り振りは、図4中の第2のレイヤにおいて示した2×26トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第3のレイヤは、4×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、各20MHz帯域幅の中心位置に位置する1×26トーンリソースユニットおよび80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。各20MHz帯域幅の中心位置にあるデフォルトリソースユニットの左サイドおよび右サイド上には、1つの4×26トーンリソースユニット(例えば、図6中の位置#eおよび位置#f)がそれぞれ存在している。各20MHz帯域幅における4×26トーンリソースユニットの割り振りは、図4中の第3のレイヤにおいて示した4×26トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第4のレイヤは、242トーンリソースユニットの割り振りマップおよびデフォルトリソースユニット(すなわち、80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。どちらかの40MHz帯域幅の中心周波数の左サイドおよび右サイド上には、1つの242トーンリソースユニット、すなわち、図6中に示した位置#cおよび位置#dに位置するリソースユニットがそれぞれ存在している。どちらかの40MHz帯域幅における242トーンリソースユニットの割り振りは、図5中の第4のレイヤにおいて示した242トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第5のレイヤは、2×242トーンリソースユニットの割り振りマップおよびデフォルトリソースユニット(すなわち、80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。80MHzの中心位置に位置するデフォルトリソースユニットの左サイドおよび右サイド上には、1つの242トーンリソースユニット、すなわち、図6に示した位置#aおよび位置#bに位置するリソースユニットがそれぞれ存在している。どちらかの40MHz帯域幅における242トーンリソースユニットの割り振りは、図5中の第5のレイヤにおいて示した242トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第6のレイヤは、996トーンリソースユニットの割り振りマップである。
ある例においては、80MHz帯域幅の周波数ドメインリソース(すなわち、割り当て予定の周波数ドメインリソースの例)は、996個のサブキャリアを含み、図6中の第1のレイヤから第5のレイヤにおいて任意のリソースユニットに分割され得る。割り振られたリソースユニットを複数のユーザに割り振り、割り振られたただ1つのリソースユニットを各ユーザに割り振ることができる。
あるいは、別の例においては、80MHz帯域幅の周波数ドメインリソースは、第6のレイヤにおいてリソースユニットに分割されてもよい。この場合には、80MHz帯域幅の周波数ドメインリソースは、1人のユーザに割り振られ、リソース割り振りは、前述した帯域幅指示情報およびシングルユーザ伝送指示ビットを使用して指示され得る。
別の例においては、80MHz帯域幅の周波数ドメインリソースは、第6のレイヤにおいてリソースユニットに分割されてもよい。この場合には、80MHz帯域幅の周波数ドメインリソースは、MU-MIMOのための複数のユーザに割り振られ、リソース割り振りは、前述した帯域幅指示情報およびマルチユーザ伝送指示ビットを使用して指示され得る。
本発明におけるリソーススケジューリングモードは、80MHz帯域幅の周波数ドメインリソースが、第1のレイヤから第5のレイヤにおける任意のリソースユニットの組合せを含み、複数のユーザに割り振られるケースに主に関連する。
例えば、図11は、80MHz帯域幅の周波数ドメインリソースの例を示している。図11に示したように、周波数ドメインリソースは、(図11中では左から右の順に)は、1つの4×26トーンリソースユニット(すなわち、リソースユニット#1''')、1つの1×26トーンリソースユニット(すなわち、デフォルトリソースユニットである、リソースユニット#0''')、1つの4×26トーンリソースユニット(すなわち、リソースユニット#2''')、1つの242トーンリソースユニット(すなわち、リソースユニット#3''')、1つの1×26トーンリソースユニット(すなわち、デフォルトリソースユニットである、リソースユニット#00''')、および1つの2×242トーンリソースユニット(すなわち、リソースユニット#4''')に分割される。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を含む。
特に、図4に示したように、80MHz帯域幅の周波数ドメインリソースは、中心に位置するリソースユニット(すなわち、デフォルト位置にあるリソースユニット)を含み、中心に位置するリソースユニットの双方のサイド上のリソースユニットの位置は、対称的に配分されている、すなわち、中心に位置するリソースユニットは、80MHz帯域幅の周波数ドメインリソースの対称中心として使用され得る。
4. 160MHz帯域幅の周波数ドメインリソースについて
160MHz帯域幅の周波数ドメインリソースが2つの80MHz周波数ドメインリソースを含むと扱われ得る。それに対応するように、どちらかの80MHz帯域幅の周波数ドメインリソースは、80MHz帯域幅の中心に位置するデフォルトリソースユニット(すなわち、デフォルト位置に位置するリソースユニット)を含み得るし、160MHz周波数ドメインリソースにおける各20MHz帯域幅の周波数ドメインリソースは、20MHz帯域幅の中心に位置するデフォルトリソースユニット(すなわち、デフォルト位置に位置するリソースユニット)を含み得る。
オプションとして、10ビットが、帯域幅において10個のデフォルト位置にあるリソースユニットが使用のためにユーザに割り振られているかどうかをそれぞれ指示するものであってもよい。
デフォルト位置に位置するデフォルトリソースユニットに加えて、160MHz帯域幅の周波数ドメインリソースは、160MHz帯域幅の周波数ドメインリソースの中心周波数の左サイドまたは右サイドにそれぞれ位置する、以下の7つのタイプのリソースユニットをさらに含む、すなわち、
リソースユニットが1つのリソースサブユニット(すなわち、26個のサブキャリア)を含んでいることを指示する、1×26トーンリソースユニット、80MHz帯域幅において割り振られる可能性がある最小のリソースユニットと、
リソースユニットが2つのリソースサブユニット(すなわち、2×26個のサブキャリア)を含んでいることを指示する、2×26トーンリソースユニットと、
リソースユニットが4つのリソースサブユニット(すなわち、4×26個のサブキャリア)を含んでいることを指示する、4×26トーンリソースユニットと、
リソースユニットが242個のサブキャリアを含んでいることを指示する、242トーンリソースユニットと、
リソースユニットが2×242個のサブキャリアを含んでいることを指示する、2×242トーンリソースユニットと、
リソースユニットが996個のサブキャリアを含んでいることを指示する、996トーンリソースユニットと、
リソースユニットが2×996個のサブキャリアを含んでいることを指示する、2×996トーンリソースユニット、160MHz帯域幅において割り振られる可能性がある最大のリソースユニットとをさらに含む。
割り振られる可能性があるリソースユニットの位置を簡潔に説明するために、160MHz帯域幅リソースユニットの割り振りマップを7つのレイヤとして図示または説明している。
第1のレイヤは、1×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、各20MHz帯域幅の中心位置に位置する1×26トーンリソースユニットおよびどちらかの80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。各20MHz帯域幅の中心位置にあるデフォルトリソースユニットの左サイドおよび右サイド上には、4つの1×26トーンリソースユニットがそれぞれ存在している。各20MHz帯域幅における1×26トーンリソースユニットの割り振りは、図4中の第1のレイヤにおいて示した1×26トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第2のレイヤは、2×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、各20MHz帯域幅の中心位置に位置する1×26トーンリソースユニットおよびどちらかの80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。各20MHz帯域幅の中心位置にあるデフォルトリソースユニットの左サイドおよび右サイド上には、2つの2×26トーンリソースユニットがそれぞれ存在している。各20MHz帯域幅における2×26トーンリソースユニットの割り振りは、図4中の第2のレイヤにおいて示した2×26トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第3のレイヤは、4×26トーンリソースユニットおよびデフォルトリソースユニット(すなわち、各20MHz帯域幅の中心位置に位置する1×26トーンリソースユニットおよびどちらかの80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。各20MHz帯域幅の中心位置にあるデフォルトリソースユニットの左サイドおよび右サイド上には、1つの4×26トーンリソースユニットがそれぞれ存在している。各20MHz帯域幅における4×26トーンリソースユニットの割り振りは、図4中の第3のレイヤにおいて示した4×26トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第4のレイヤは、242トーンリソースユニットの割り振りマップおよびデフォルトリソースユニット(すなわち、どちらかの80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。どちらかの40MHzの中心周波数の左サイドおよび右サイド上には、1つの242トーンリソースユニットがそれぞれ存在している。どちらかの40MHz帯域幅における242トーンリソースユニットの割り振りは、図5中の第4のレイヤにおいて示した242トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第5のレイヤは、2×242トーンリソースユニットの割り振りマップおよびデフォルトリソースユニット(すなわち、どちらかの80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。80MHzの中心位置に位置するデフォルトリソースユニットの左サイドおよび右サイド上には、1つの242トーンリソースユニットがそれぞれ存在している。各40MHz帯域幅における242トーンリソースユニットの割り振りは、図5中の第5のレイヤにおいて示した242トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第6のレイヤは、996トーンリソースユニットの割り振りマップおよびデフォルトリソースユニット(すなわち、各80MHz帯域幅の中心位置に位置する1×26トーンリソースユニット)の割り振りマップである。160MHzの中心周波数の左サイドおよび右サイド上には、1つの996トーンリソースユニットがそれぞれ存在する。どちらかの80MHz帯域幅における242トーンリソースユニットの割り振りは、図6中の第6のレイヤにおいて示した996トーンリソースユニットの割り振りと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
第7のレイヤは、2×996トーンリソースユニットの割り振りマップである。
ある例においては、160MHz帯域幅の周波数ドメインリソース(すなわち、割り当て予定の周波数ドメインリソースの例)は、2×996個のサブキャリアを含み、第1のレイヤから第6のレイヤにおいて任意のリソースユニットに分割され得る。割り振られたリソースユニットを複数のユーザに割り振り、割り振られたただ1つのリソースユニットを各ユーザに割り振ることができる。
あるいは、別の例においては、160MHz帯域幅の周波数ドメインリソースは、第7のレイヤにおいてリソースユニットに分割されてもよい。この場合には、160MHz帯域幅の周波数ドメインリソースは、1人のユーザに割り振られ、リソース割り振りは、前述した帯域幅指示情報およびシングルユーザ伝送指示ビットを使用して指示され得る。
別の例においては、160MHz帯域幅の周波数ドメインリソースは、第7のレイヤにおいてリソースユニットに分割されてもよい。この場合には、160MHz帯域幅の周波数ドメインリソースは、MU-MIMOのための複数のユーザに割り振られ、リソース割り振りは、前述した帯域幅指示情報およびマルチユーザ伝送指示ビットを使用して指示され得る。
本発明におけるリソーススケジューリングモードは、160MHz帯域幅の周波数ドメインリソースが、第1のレイヤから第6のレイヤにおける任意のリソースユニットの組合せを含み、複数のユーザに割り振られるケースに主に関連する。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を含む。
特に、図4に示したように、160MHz帯域幅の周波数ドメインリソースの中心周波数の左サイドおよび右サイド上の様々なリソースユニットの位置は、対称的に配分されている、すなわち、中心周波数は、160MHz帯域幅の周波数ドメインリソースの対称中心として使用され得る。
上記においては、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を説明している。下記においては、割り振られる可能性があるリソースユニットの位置に基づいてリソーススケジューリング情報を生成するプロセスを詳細に説明する。
本発明の本実施形態においては、送信端は、リソーススケジューリングを行う必要がある、例えば、受信端がリソースユニットを使用して伝送を行うために、リソーススケジューリング情報を使用して、受信端(受信端の数量は1つまたは複数であり得る)に受信端に対応するリソースユニットを通知する必要がある。
送信端は、ビットシーケンス、または、ビットマップ(bitmap)を使用して、システム内の各受信端に以下の情報、すなわち、
現在の割り当て予定の周波数ドメインリソースにおけるリソースユニットの割り振りを通知し得る。リソースユニットの割り振りは、一方では、割り振られた各リソースユニットに含まれるサブキャリアの数量、すなわち、割り振られた各リソースユニットのサイズを含む。リソースユニットの割り振りはまた、他方では、割り当て予定の周波数ドメインリソースにおける各割り振られるリソースユニットの位置を含む。以下の実施形態においては、リソースユニットの割り振りのための簡易化した指示を、各帯域幅に割り振られる可能性があるプロトコル事前定義リソースユニットに基づいて、例えば、各帯域幅において各サイズを有する各リソースユニットの事前に定義された数量および位置に基づいて、提供している。それに対応するように、受信端は、上述した情報に基づいて、送信端によって割り振られる各リソースユニットを決定し得る。スケジューリング済みの受信端に関する情報を組み合わせて、受信端は、対応するスケジューリング済みのリソースユニット上でその後の情報通信を行い得る。
以下の実施形態の各々は、割り当て予定の周波数ドメインリソース(帯域幅)におけるリソースユニットの割り振りを効率的に指示するためのソリューションを提供している。
実施形態1
オプションとして、ビットシーケンスは、複数のtype-1ビットを含み、複数のtype-1ビットは、1対1ベースで複数のリソースユニットの位置のペアに対応し、type-1ビットのうちの1つは、対応するリソースユニットの位置のペア中のリソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するものであり、1つのリソースユニットの位置のペアは、デフォルト位置の一方のサイド上に位置する2つの連続した最小のリソースユニットの位置を含む。特に、図7および図8を参照すれば、図7および図8は、割り振られた割り当て予定のリソースユニットを指示する、リソースユニット割り振り結果の簡略概略図および対応するビットシーケンスの概略図である。
様々な帯域幅(20MHzのみを図に示しているが、これは、40MHz、80MHz、および160MHzを含むがこれらに限定されない)について、ビットシーケンスは、少なくとも複数の(2つ以上の)type-1ビットを含む。type-1ビットは、割り振られる可能性があるとともに割り当て予定の周波数ドメインリソースにおいてデフォルト位置(すなわち、デフォルトリソースユニットが位置する位置)の一方のサイド上に位置する2つの連続した最小のリソースユニット(1×26)の位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するものである。
ここで、図4から図6に示したように、各帯域幅の第1のレイヤにおいては、各20MHz帯域幅におけるデフォルト位置の一方のサイド上に4つの1×26リソースユニットの位置が存在している。デフォルト位置の一方のサイドは、2つのリソースユニットの位置のペアを含み得る。各リソースユニットの位置のペアは、2つの連続した1×26リソースユニットの位置を含み得るし、各1×26リソースユニットの位置は、1つのリソースユニットの位置のペアに属するおよびそれのみに属する。
前述の説明によれば、異なる帯域幅において複数のデフォルト位置が存在し得ることに留意されたい。複数のデフォルト位置が存在する場合には、デフォルト位置の一方のサイドは、2つのデフォルト位置間のバンドリソースを指す。
オプションとして、方法は、2つの連続したtype-1ビットの両方が同一の割り当て予定のリソースユニットにおける割り振りを指示している場合には、ビットシーケンスは、複数(2つ以上の)type-4ビットをさらに含み、type-4ビットは、2つの連続した2番目に小さいリソースユニットの位置(2×26トーンリソースユニットの位置)が同一のリソースユニットに配分されているかどうかを指示するものである、ことをさらに含み得る。
異なる帯域幅においては、type-1ビットのみを含んでいてもよい。type-1ビット指示を除けば、他の方式は、すべてのリソースユニットの割り振りが指示されるまで、前述の指示原理に従ってリソースユニットの割り振りを指示するものであり得る。より大きな帯域幅については、より多くのビットがすべてのリソースユニットの割り振りを指示するために必要になることが理解できよう。
オプションとして、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースを指示する第1の指示情報をさらに含む。
一例として図7または図8に示した方式を使用すれば、第1の指示情報は、割り当て予定の周波数ドメインリソースが20MHzであり、ビットシーケンスが少なくとも4つのtype-1ビットを含むことを示す。各ビットは、左から右の順で配置された2つの1×26リソースユニットの位置に対応し、2つの1×26リソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを示すものである。
好ましくは、ソリューションは、type-4ビットをさらに含む。
4ビットのうちのビット#1およびビット#2が両方、2つの1×26リソースユニットが同一の割り当て予定のリソースユニットに配分されていることを指示している場合には、ビットシーケンスは、ビット#1およびビット#2に対応する2×26リソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示する、ビット#5をさらに含む、または、
4ビットのうちのビット#3およびビット#4が両方、2つの1×26リソースユニットが同一の割り当て予定のリソースユニットに配分されていることを指示している場合には、ビットシーケンスは、ビット#3およびビット#4に対応する2×26リソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示する、ビット#6をさらに含む。
加えて、4ビットのうちの2つの連続したビット(例えば、ビット#1およびビット#2、または、ビット#3およびビット#4)が、2つの1×26リソースユニットが同一の割り当て予定のリソースユニットに配分されていないことを指示している場合には、type-4ビットは必要ない。
異なる帯域幅において、type-1ビットを含み得ることは理解されよう。type-1ビット指示を除けば、他の方式は、前述の指示原理に従って他のリソースユニットの割り振りを指示するものであり得る。他のビットは、すべてのリソースユニットの割り振りが指示されるまで、割り振られた割り当て予定のリソースユニットが割り振られる可能性がある2つの連続した2番目に小さいリソースユニットの位置にあるかどうかを指示するものである。40MHz、80MHz、および160MHz帯域幅については、望ましい方式は、割り振られる可能性があるとともに割り当て予定の周波数ドメインリソースにおいてデフォルト位置(すなわち、デフォルトリソースユニットが位置する位置)の一方のサイド上に位置する2つの連続した最小のリソースユニット(1×26)の位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するのみである、または、割り振られた割り当て予定のリソースユニットが割り振られる可能性がある2つの連続した最小のリソースユニットの位置にあるか割り振られる可能性がある2つの連続した2番目に小さいリソースユニットの位置にあるかを指示するのみである。より大きなリソースユニットの位置については、他の可能な実施様態を指示のために使用する。
実施形態2
オプションとして、ビットシーケンスは、複数のtype-2ビットを含み、type-2ビットは、対称中心の一方のサイド上における最大のリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。
図9、図10、および図11を参照すれば、図9、図10、および図11は、割り振られた割り当て予定のリソースユニットを指示する、リソースユニット割り振り結果の簡略概略図および対応するビットシーケンスの概略図である。
様々な帯域幅(20MHz、40MHz、および80MHzのケースを図に別々に示しているが、これはまた、160MHzを含むとともに適用可能である)については、ビットシーケンスは、少なくとも複数の(2つ以上の)type-2ビットを含む。type-2ビットは、割り当て予定の周波数ドメインリソースが複数のユーザに割り振られている場合には、割り当て予定の周波数ドメインリソースにおける対称中心の一方のサイド上における最大のリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。前述の説明から分かるように、様々な帯域幅には、対称中心の一方のサイド上に位置する最大のリソースユニットの異なる位置が存在する。例えば、割り当て予定の周波数ドメインリソースが20MHzである場合には、割り振られる可能性がある最大のリソースユニットの位置は、4×26トーンリソースユニットの位置であり、別の例では、割り当て予定の周波数ドメインリソースが40MHzである場合には、割り振られる可能性がある最大のリソースユニットの位置は、242トーンリソースユニットの位置であり、別の例では、割り当て予定の周波数ドメインリソースが80MHzである場合には、割り振られる可能性がある最大のリソースユニットの位置は、2×242トーンリソースユニットの位置であり、別の例では、割り当て予定の周波数ドメインリソースが160MHzである場合には、割り振られる可能性がある最大のリソースユニットの位置は、996トーンリソースユニットの位置である。
オプションとして、方法は、割り振られる可能性がある最大のリソースユニットが実際の割り振りに存在しないことをあるtype-2ビットが指示している場合には、type-5ビットをさらに含む、ことをさらに含み得る。type-2ビットによって指示されるリソースユニットの位置の範囲において、type-5ビットは、対称中心の一方のサイド上に割り振られる可能性がある2番目に大きいリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。
異なる帯域幅においては、type-2ビットのみを含んでいてもよい。type-2ビット指示を除けば、他の方式は、他のリソースユニットの割り振りを指示するものであり得る。それはまた、前述の指示原理に従って、すべてのリソースユニットの割り振りが指示されるまで、3番目に大きいリソースユニットが実際に割り振られたリソースユニットであるかどうかを指示するために他のビットを使用してもよい。
40MHz、80MHz、および160MHzについては、望ましい方式は、対称中心の一方のサイド上に割り振られる可能性がある最大のリソースユニットが実際に割り振られたリソースユニットであるかどうかを指示するのみである、または、割り振られる可能性がある最大のリソースユニットおよび2番目に大きいリソースユニットの位置が実際に割り振られたリソースユニットであるかどうかを指示するのみであり、より小さいリソースユニットの位置については、他の可能な実施様態を指示のために使用してもよい。
オプションとして、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースを指示する第1の指示情報をさらに含む。
一例として図9に示した方式を使用すれば、第1の指示情報は、割り当て予定の周波数ドメインリソースが20MHzであることを指示している。ビットシーケンスは、少なくとも2ビット(すなわち、type-2ビットの例)を含み、少なくとも2ビットのうちビット#Aおよびのビット#Bは、20MHz帯域幅の対称中心(すなわち、20MHz帯域幅におけるデフォルト位置)の左サイドまたは右サイド上の4×26トーンリソースユニットの位置が実際に割り振られているかどうかをそれぞれ指示するものである。当然のことながら、ビット#Aは、右サイドを指示し得るし、ビット#Bは、左サイドを指示する。その原理は同一であるため再び説明はしない。
好ましくは、図9中の例は、以下のことをさらに含み得る。
type-2ビットのうちのビット#Aが、4×26トーンリソースユニットの位置が実際に割り振られていないことを指示している場合には、ビットシーケンスは、ビット#Cおよびビット#Dをさらに含み得る。ビット#Cは、ビット#Aに対応する前部の2×26トーンリソースユニットの位置が同一の割り当て予定のリソースユニット内に割り振られているかどうかを指示するものであり、ビット#Dは、割り振られた割り当て予定のリソースユニットがビット#Aに対応する後部の2×26トーンリソースユニットの位置に存在するかどうかを指示するものである、または、
type-2ビットのうちのビット#Bが、4×26トーンリソースユニットの位置が実際に割り振られていないことを指示している場合には、ビットシーケンスは、ビット#Eおよびビット#Fをさらに含む。ビット#Eは、ビット#Bに対応する前部の2×26トーンリソースユニットの位置が同一の割り当て予定のリソースユニット内に割り振られているかどうかを指示するものであり、ビット#Fは、ビット#Bに対応する後部の2×26トーンリソースユニットの位置が実際に割り振られているかどうかを指示するものである。
一例として図10に示した方式を使用すれば、第1の指示情報は、割り当て予定の周波数ドメインリソースが40MHzであることを指示している。ビットシーケンスは、少なくとも2ビット(すなわち、type-2ビットの別の例)を含み、少なくとも2ビットのうちのビット#A'およびビット#B'は、40MHz帯域幅の対称中心(すなわち、40MHz帯域幅における中心周波数)の左サイドまたは右サイド上の242トーンリソースユニットの位置が実際に割り振られているかどうかをそれぞれ指示するものである。当然のことながら、ビット#A'は、右サイドを指示し得るし、ビット#B'は、左サイドを指示する。その原理は同一であるため再び説明はしない。
242トーンリソースユニットの位置が実際に割り振られていない場合には、本実施様態に限定されないが、他の方式がまた、指示を継続するために使用され得る。
一例として図11に示した方式を使用すれば、第1の指示情報は、割り当て予定の周波数ドメインリソースが80MHzであることを指示している。ビットシーケンスは、少なくとも2ビット(すなわち、type-2ビットのさらに別の例)を含み、少なくとも2ビットのうちのビット#A''およびビット#B''は、80MHz帯域幅の対称中心(すなわち、80MHz帯域幅の中心におけるデフォルト位置)の左サイドまたは右サイド上の2×242トーンリソースユニットの位置が実際に割り振られているかどうかをそれぞれ指示するものである。当然のことながら、ビット#A''は、右サイドを指示し得るし、ビット#B''は、左サイドを指示する。その原理は同一であるため再び説明はしない。
2×242リソースユニットの位置が実際に割り振られていない場合には、本実施様態は、2×242リソースユニットの位置の範囲内の242リソースユニットの位置が実際に割り振られているかどうかを継続して指示するものであり得る。後続のリソースユニットについては、本実施様態に限定されないが、他の方式を指示のために継続して使用してもよい。
160MHzまたは他の帯域幅については、同様に、前述のソリューションを参照されたい。
実施形態3
オプションとして、ビットシーケンスは、2つのtype-3ビットを含み、2つのtype-3ビットは、1対1ベースで対称中心の双方のサイド上に位置する2つのリソースユニット位置グループに対応し、type-3ビットは、対応するリソースユニット位置グループ中のリソースユニットの位置にあるすべてのリソースユニットが割り当て予定のリソースユニットであるかどうかを指示するものであり、1つのリソースユニット位置グループは、割り当て予定の周波数ドメインリソースの中心の一方のサイド上に位置する複数の最小のリソースユニットの位置を含む。
図12および図13を参照すれば、図12および図13は、割り振られた割り当て予定のリソースユニットを指示する、リソースユニット割り振り結果の簡略概略図および対応するビットシーケンスの概略図である。
様々な帯域幅(20MHz、40MHz、および80MHzのケースのみを図に示しているが、これはまた、160MHzを含むとともに適用可能である)については、ビットシーケンスは、少なくとも複数のtype-3ビットを含む。いくつかのtype-3ビットは、割り振られる可能性があるとともに割り当て予定の周波数ドメインリソースにおいて対称中心(例えば、20MHz帯域幅におけるデフォルト位置、40MHz帯域幅における中心周波数、80MHz帯域幅の中心におけるデフォルト位置、または160MHz帯域幅における中心周波数)の一方のサイド上に位置する複数の最小のリソースユニットの位置にあるすべてのリソースユニットが割り振られた割り当て予定のリソースユニットであるかどうかを指示するものであり、残りのtype-3ビットは、割り振られる可能性があるとともに割り当て予定の周波数ドメインリソースにおけるデフォルト位置の残りの側上に位置する複数の最小のリソースユニットの位置にあるすべてのリソースユニットが割り振られた割り当て予定のリソースユニットであるかどうかをそれぞれ指示するものである。一般的に、各帯域幅における最小のリソースユニットのサイズは、1×26である。最小のリソースユニットの位置については、前述の詳細な説明を参照されたい。その詳細を本明細書では再び説明しない。
ここで、対称中心の一方のサイドは、リソースユニット位置グループを含み得る、または、各リソースユニット位置グループは、対称中心の一方のサイド上にデフォルト位置を除くすべての1×26リソースユニットの位置を含み得る、ここで、各1×26リソースユニットの位置は、1つのリソースユニット位置グループに属するおよびそれのみに属する。
オプションとして、方法は、あるtype-3ビットが、割り振られる可能性がある複数の最小のリソースユニットの位置にあるすべてのリソースユニットが割り振られた割り当て予定のリソースユニットではないことを指示している場合には、type-6ビットをさらに含む、ことをさらに含み得る。type-3ビットによって指示されるリソースユニットの位置の範囲において、type-6ビットは、割り振られる可能性がある複数の2番目に小さいリソースユニットの位置にあるすべてのリソースユニットが割り振られた割り当て予定のリソースユニットであるかどうかを指示するものである。
異なる帯域幅においては、type-3ビットのみを含んでいてもよい。type-3ビット指示を除けば、他の方式は、前述の指示原理に従って他のリソースユニットの割り振りを指示するものであり得る。他のビットは、すべてのリソースユニットの割り振りが指示されるまで、3番目に大きいリソースユニットが実際に割り振られたリソースユニットであるかどうかを指示するものである。40MHz、80MHz、および160MHzについては、望ましい方式は、割り振られる可能性がある最小のリソースユニットの位置が実際に割り振られたリソースユニットであるかどうかを指示するのみである、または、最小のリソースユニットの位置および2番目に小さいリソースユニットの位置が実際に割り振られたリソースユニットであるかどうかを指示するのみである。より大きなリソースユニットの位置については、他の可能な実施様態を指示のために使用する。
実施形態4
オプションとして、リソースユニット割り振りを指示する前述のビットシーケンスは、type-0ビットを含み、ビットは、割り振られる可能性があるとともに特定の帯域幅に対応する最大のリソースユニットの位置が実際に割り振られているかどうかを指示する、すなわち、ビットは、最大のリソースユニットがMU-MIMO伝送のために使用されていることを指示する。その後、他のリソース指示情報は、対応するステーションに割り振られる割り当て予定のリソースユニットを割り振るものである。割り振られる可能性があるとともに特定の帯域幅に対応する最大のリソースユニットの位置は、上述したように、例えば、20MHz帯域幅のための図4中の第4のレイヤ、40MHzのための図5中の第5のレイヤ、80MHzのための図6中の第6のレイヤ、または160MHzのための第7のレイヤである。
この場合には、type-0ビットが、現在の帯域幅から割り振られる可能性がある最大のリソースユニットが実際に割り振られたリソースユニットではないことを指示している場合には、その後、前述のtype-1ビット、type-2ビット、またはtype-3ビット、または、他のタイプのビットをリソースユニットの割り振りを指示するために含む必要があることは理解されよう。type-0ビットが、割り振られた割り当て予定のリソースユニットが現在の帯域幅に対応する最大のリソースユニットの位置にあることを指示している場合には、その後、他のビットシーケンスをリソースユニットの割り振りを指示するために含む必要はない。
加えて、同様の方式が異なる帯域幅のためのリソースユニットの割り振りを指示するために前述の実施形態における原理で使用されることに留意されたい。すなわち、40MHz、80MHz、および160MHz帯域幅については、前述の指示方法がその全体における指示のために使用される。
下記においては、前述の実施形態1、2、3、または4に基づいて前述のビットシーケンスを決定する方法およびプロセスを詳細に説明する。
オプションとして、送信端は、N個のマッピングルールを取得する、ここで、N個のマッピングルールは、1対1ベースでN個のプリセットサブキャリア数量に対応し、マッピングルールは、決定結果と指示識別子との間のマッピング関係を指示するものであり、決定結果は、マッピングルールに対応するプリセットサブキャリア数量と決定オブジェクトとの間の関係に基づいて取得され、N≧1であり、
割り当て予定の周波数ドメインリソースに含まれるM個の周波数ドメインリソースユニットをM個の受信端に割り振っている場合には、送信端は、決定オブジェクトとして各周波数ドメインリソースユニットに含まれるサブキャリアの数量を使用し、N個のマッピングルールに従って、各マッピングルール下で各周波数ドメインリソースユニットに対応する指示識別子を決定する、ここで、M個の周波数ドメインリソースユニットは、1対1ベースでM個の受信端に対応し、
送信端は、指示識別子に従ってビットシーケンスを決定する、ここで、ビットシーケンスは、割り当て予定の周波数ドメインリソースにおける各周波数ドメインリソースユニットに含まれるサブキャリアの数量および各周波数ドメインリソースユニットの位置を指示するものであり、
送信端は、受信端が、リソーススケジューリング情報に従って、受信端に対応する周波数ドメインリソースユニットを決定するために、ビットシーケンスを含むリソーススケジューリング情報を受信端に送信する。
オプションとして、プリセットサブキャリア数量をリソースユニットのタイプに従って決定する。
特に、本発明の本実施形態においては、プリセットサブキャリア数量をWLANシステム内のリソースユニットタイプの可能な数量に従って決定し得る。
オプションとして、送信端がN個のマッピングルールを取得することは、
割り当て予定の周波数ドメインリソースに含まれるサブキャリアの数量、プリセットサブキャリア数量の最小値、およびプリセットサブキャリア数量の最大値に従ってN個のマッピングルールを取得することを含む。
特に、本発明の本実施形態においては、プリセットルールは、割り当て予定の周波数ドメインリソースの帯域幅(すなわち、割り当て予定の周波数ドメインリソースに含まれるサブキャリアの数量(ここで、割り当て予定の周波数ドメインリソースに含まれるサブキャリアは、直流サブキャリアおよびサイドバンドガードサブキャリアを含んでおらず、以降繰り返しを避けるために、同一または同様のケースに関する説明は省略する))、前述のリソースサブユニットのサイズ(すなわち、プリセットサブキャリア数量の最小値)、および帯域幅においてリソースユニットに含まれるサブキャリアの数量の最大値(すなわち、プリセットサブキャリア数量の最大値)に従って決定され得る。
例えば、20MHz帯域幅の周波数ドメインリソースを使用する場合には、周波数ドメインリソースは、図4に示したリソースユニットの3つのタイプを含み得る。したがって、プリセットサブキャリア数量は、
1×26、2×26、および4×26であり得る。
別の例では、40MHz帯域幅の周波数ドメインリソースを使用する場合には、周波数ドメインリソースは、図5に示したリソースユニットの4つのタイプを含み得る。したがって、プリセットサブキャリア数量は、
1×26、2×26、4×26、および242であり得る。
別の例では、80MHz帯域幅の周波数ドメインリソースを使用する場合には、周波数ドメインリソースは、図6に示したリソースユニットの5つのタイプを含み得る。したがって、プリセットサブキャリア数量は、
1×26、2×26、4×26、242、および2×242であり得る。
別の例では、160MHz帯域幅の周波数ドメインリソースを使用する場合には、周波数ドメインリソースは、リソースユニットの6つのタイプを含み得るし、すなわち、プリセットサブキャリア数量は、
1×26、2×26、4×26、242、2×242、および996であり得る。
さらに、本発明の本実施形態においては、受信端も、プリセットサブキャリア数量を決定する同様の方法およびプロセスを使用してもよい。さらに、方法100の信頼性を保証するために、送信端および受信端によって決定されるプリセットサブキャリア数量が同一であることを保証すべきである。
プリセットサブキャリア数量を決定する方法を説明した上記は例にすぎず、本発明はそれに限定されないことを理解されたい。プリセットサブキャリア数量はまた、高位レイヤの管理デバイスによって送信端または受信端に指示され得る、または、ネットワーク管理者によって送信端または受信端に事前に設定され得る、または、送信端および受信端によって決定されるプリセットサブキャリア数量が同一であることを保証することができる限り、割り当て予定の周波数ドメインリソースの帯域幅に従って送信端または受信端によって直接決定され得る。このことは本発明において特に限定されない。
本発明の本実施形態においては、割り当て予定の周波数ドメインリソースにおける任意のリソースユニットの対応する指示識別子が、任意のマッピングルールのために取得され得る。すなわち、リソースユニットに含まれるサブキャリアの数量(または、リソースユニットのタイプ)とプリセットサブキャリア数量(または、プリセットサブキャリア数量に対応するリソースユニットのタイプ)との間の関係(例えば、大小関係)が決定され得るし、異なる関係は異なる指示識別子に対応し得る。
下記においては、マッピングルールのコンテンツおよび指示識別子を決定するための方法を詳細に説明する。
オプションとして、N個のマッピングルールに従って、各マッピングルール下で各リソースユニットに対応する指示識別子を決定することは、
各マッピングルールに対応するプリセットサブキャリア数量に基づいて、プリセット順序に従って、および、シーケンス内のN個のマッピングルールに従って、各マッピングルール下で各リソースユニットに対応する指示識別子を決定することを含む。
特に、本発明の本実施形態においては、ツリー方法は、プリセットサブキャリア数量の順序(例えば、降順または昇順)に従ってシーケンス内の各マッピングルール下で各リソースユニットの指示識別子を決定するものであり得る。
本発明の本実施形態においては、前述の決定したプリセットサブキャリア数量のためのマッピングルールとして、以下の3つのタイプを説明し得る。下記おいては、様々なマッピングルールおよび様々なマッピングルールに基づいた処理プロシージャを詳細に説明している。
α. Type-1マッピングルール(実施形態1に対応)
本発明の本実施形態においては、送信端は、プリセットサブキャリア数量の昇順で各マッピングルール下における各リソースユニットの識別子を決定し得る。
この場合には、type-1マッピングルール(理解および識別を容易にするために、マッピングルール#Aと以降示す)は、指定の周波数ドメイン位置に位置するリソースユニットのサイズ(すなわち、含まれているサブキャリアの数量)がマッピングルール#Aに対応するプリセットサブキャリア数量以上であるかどうかを決定するものとして記述され得る。yesと決定された場合には、マッピングルール#A下における周波数ドメイン位置の指示識別子は、1である。noと決定された場合には、マッピングルール#A下における周波数ドメイン位置の指示識別子は、0である。
換言すれば、プリセットサブキャリア数量の前述の順序は、図4から図7に示したレイヤの順序に対応するようになり得る、すなわち、送信端は、リソースユニットの前述の割り振りマップにおいてトップダウン順(すなわち、プリセットサブキャリア数量の昇順)で各レイヤに対応するマッピングルールを決定し得る。
すなわち、第Xのレイヤにおけるマッピングルール#Aは、指定の周波数ドメイン位置にある(1つまたは複数の)リソースユニットが第(X-1)のレイヤ(すなわち、第Xのレイヤの上位レイヤ)におけるリソースユニットのアグリゲーションによって形成されている場合には、マッピングルール#A下における周波数ドメイン位置の指示識別子は1である、または、指定の周波数ドメイン位置にある(1つまたは複数の)リソースユニットが第(X-1)のレイヤ(すなわち、第Xのレイヤの上位レイヤ)におけるリソースユニットのアグリゲーションによって形成されていない場合には、マッピングルール#A下における周波数ドメイン位置の指示識別子は0であるものとしてさらに記述され得る。
ここで、「アグリゲーション」は1つの上位レイヤにおける隣接リソースユニットのアグリゲーションのみであり得るものであって、2つの上位レイヤにおけるリソースユニットのアグリゲーションは存在しないことに特に留意すべきである。したがって、ビットは本ソリューションにおいてさらに圧縮され得る、すなわち、上位レイヤのアグリゲーションが不可能であることを指示するビットは省略され得る。例えば、1つの2×26および2つの1×26リソースユニットは、20MHz帯域幅における中心位置に位置する1×26トーンリソースユニット(すなわち、20MHz帯域幅の対称中心)の左サイド上にある。この場合には、上位レイヤにおけるリソースユニットは、4×26リソースユニットにアグリゲーションすることができず、したがって、対応する指示ビットは省略され得る。
図7は、type-1マッピングルールに基づいた決定プロセスの例のツリー図を示している。一例として20MHz帯域幅を有する割り当て予定の周波数ドメインリソースを使用すれば、割り当て予定の周波数ドメインリソースは、左から右の順に、2つの2×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#1およびリソースユニット#2と以降示す)、1つの1×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#0と以降示す)、および1つの4×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#3と以降示す)を含む。
20MHz帯域幅においては、帯域幅の真ん中の位置に位置する1つの1×26トーンリソースユニット(すなわち、リソースユニット#0)が常に存在しているため、リソースユニットが暗黙的に指示され得ることに留意されたい。したがって、方法100は、主に、リソースユニット#0を除く任意のリソースユニットに対応する指示識別子を決定することである。繰り返しを避けるために、同一または同様のケースに関する説明は以下では省略する。
当然のことながら、別の例においては、1ビットはまた、リソースユニット#0が利用可能であるかどうかを指示するものであり得る。
まず、図7に示したように、2×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#1と以降示す)が決定され、決定が左から右の順で行われる。
換言すれば、図4中の第2のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
送信端の決定プロセスにおいては、図4中の第2のレイヤにおける位置#1に対応するリソースユニットは、リソースユニット#1であり、リソースユニット#1に含まれるサブキャリアの数量は、2×26であり、プリセットルール#1に対応する決定条件を満たしている、すなわち、リソースユニット#1に含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量以上である。したがって、プリセットルール#1下における位置#1(または、リソースユニット#1)の指示識別子は、1である。換言すれば、リソースユニット#1は、2つ以上の2つの1×26リソースユニットのアグリゲーションによって形成される。したがって、プリセットルール#1下における位置#1(または、リソースユニット#1)の指示識別子は、1である。
図4中の第2のレイヤにおける位置#2に対応するリソースユニットは、リソースユニット#2であり、リソースユニット#2に含まれるサブキャリアの数量は、2×26であり、プリセットルール#1に対応する決定条件を満たしている、すなわち、リソースユニット#2に含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量以上である。したがって、プリセットルール#1下における位置#2(または、リソースユニット#2)の指示識別子は、1である。換言すれば、リソースユニット#2は、2つの1×26リソースユニットのアグリゲーションによって形成される。したがって、プリセットルール#1下における位置#2(または、リソースユニット#2)の指示識別子は、1である。
図4中の第2のレイヤにおける位置#3に対応するリソースユニットは、リソースユニット#3(すなわち、リソースユニット#3の一部)であり、リソースユニット#3に含まれるサブキャリアの数量は、4×26であり、プリセットルール#1に対応する決定条件を満たしている、すなわち、リソースユニット#3に含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量以上である。換言すれば、リソースユニット#3は、2つの1×26リソースユニットのアグリゲーションによって形成される。したがって、プリセットルール#1下における位置#3の指示識別子は、1である。
さらに、図4中の第2のレイヤにおける位置#4に対応するリソースユニットは、リソースユニット#3(すなわち、リソースユニット#3の一部)であり、リソースユニット#3に含まれるサブキャリアの数量は、4×26であり、プリセットルール#1に対応する決定条件を満たしている、すなわち、リソースユニット#3に含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量以上である。換言すれば、リソースユニット#3は、2つの1×26リソースユニットのアグリゲーションによって形成される。したがって、プリセットルール#1下における位置#4の指示識別子は、1である。
したがって、プリセットルール#1下におけるリソースユニット#3の指示識別子は、11である。
その後、図7に示したように、4×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#2と以降示す)が決定され、決定が左から右へと行われる。
換言すれば、図4中の第3のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
図4中の第3のレイヤにおける位置#5に対応するリソースユニットは、リソースユニット#1およびリソースユニット#2であり、リソースユニット#1およびリソースユニット#2に含まれるサブキャリアの数量は、2×26であり、プリセットルール#2に対応する決定条件を満たしていない、すなわち、リソースユニット#1およびリソースユニット#2に含まれるサブキャリアの数量は、プリセットルール#2に対応するプリセットサブキャリア数量未満である。したがって、プリセットルール#1下における位置#5(または、リソースユニット#1およびリソースユニット#2)の指示識別子は、0である。換言すれば、リソースユニット#1およびリソースユニット#2は、2つの2×26リソースユニットのアグリゲーションによって形成されていない。したがって、プリセットルール#2下における位置#5(または、リソースユニット#1およびリソースユニット#2)の指示識別子は0である、すなわち、ビット"0"は、プリセットルール#2下では、リソースユニット#1およびリソースユニット#2の指示識別子として使用される。
図4中の第3のレイヤにおける位置#6に対応するリソースユニットは、リソースユニット#3であり、リソースユニット#3に含まれるサブキャリアの数量は、4×26であり、プリセットルール#2に対応する決定条件を満たしている、すなわち、リソースユニット#2に含まれるサブキャリアの数量は、プリセットルール#2に対応するプリセットサブキャリア数量以上である。したがって、プリセットルール#2下における位置#6(または、リソースユニット#3)の指示識別子は、1である。換言すれば、リソースユニット#3は、2つの2×26リソースユニットのアグリゲーションによって形成される。したがって、プリセットルール#2下における位置#6(または、リソースユニット#3)の指示識別子は、1である。
type-1マッピングルールに基づいて図7に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、111101であり、従来技術におけるビットシーケンスを生成するための方法と比較して、3ビットのオーバーヘッドを使わずに済ますことができる。
それに対応するように、受信端の決定プロセスにおいては、ビットシーケンス中の最初の4ビットは、図4中の第2のレイヤにおける位置#1から位置#4における割り当て予定の周波数ドメインリソース内のリソースユニットの割り振りを指示する。
第1の指示識別子は、1である。したがって、受信端は、図4中の第2のレイヤにおける位置#1にあるリソースユニット(すなわち、リソースユニット#1)に含まれるサブキャリアの数量がプリセットルール#1に対応する決定条件を満たしている、すなわち、位置#1にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量(すなわち、2×26)以上である、と決定し得る。換言すれば、位置#1に位置するリソースユニットは、2つ以上の2つの1×26リソースユニットのアグリゲーションによって形成されている。
第2の指示識別子は、1である。したがって、受信端は、図4中の第2のレイヤにおける位置#2にあるリソースユニット(すなわち、リソースユニット#2)に含まれるサブキャリアの数量がプリセットルール#1に対応する決定条件を満たしている、すなわち、位置#2にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量(すなわち、2×26)以上である、と決定し得る。換言すれば、位置#2に位置するリソースユニットは、2つ以上の2つの1×26リソースユニットのアグリゲーションによって形成されている。
第3の指示識別子は、1である。したがって、受信端は、図4中の第2のレイヤにおける位置#3にあるリソースユニット(すなわち、リソースユニット#3)に含まれるサブキャリアの数量がプリセットルール#1に対応する決定条件を満たしている、すなわち、位置#3にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量(すなわち、2×26)以上である、と決定し得る。換言すれば、位置#3に位置するリソースユニットは、2つ以上の2つの1×26リソースユニットのアグリゲーションによって形成されている。
第4の指示識別子は、1である。したがって、受信端は、図4中の第2のレイヤにおける位置#4にあるリソースユニット(すなわち、リソースユニット#3)に含まれるサブキャリアの数量がプリセットルール#1に対応する決定条件を満たしている、すなわち、位置#4にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量(すなわち、2×26)以上である、と決定し得る。換言すれば、位置#4に位置するリソースユニットは、2つ以上の2つの1×26リソースユニットのアグリゲーションによって形成されている。
ビットシーケンス中の5番目のビットおよび6番目のビットは、図4中の第3のレイヤにおける位置#5および位置#6における割り当て予定の周波数ドメインリソース内のリソースユニットの割り振りを指示する。
第5の指示識別子は、0である。したがって、受信端は、図4中の第3のレイヤにおける位置#5にあるリソースユニット(すなわち、リソースユニット#1およびリソースユニット#2)に含まれるサブキャリアの数量がプリセットルール#2に対応する決定条件を満たしていない、すなわち、位置#5にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#2に対応するプリセットサブキャリア数量(すなわち、4×26)未満である、と決定し得る。換言すれば、位置#5に位置するリソースユニットは、2つの2×26リソースユニットのアグリゲーションによって形成されていない。
したがって、第1の指示識別子、第2の指示識別子、および第5の指示識別子を参照して、受信端は、位置#1に位置するリソースユニットおよび位置#2は、2つの2×26トーンリソースユニットであると決定することができる、すなわち、割り当て予定の周波数ドメインリソースがリソースユニット#1およびリソースユニット#2を含んでいると決定することができる。
第6の指示識別子は、1である。したがって、受信端は、図4中の第3のレイヤにおける位置#6にあるリソースユニット(すなわち、リソースユニット#3)に含まれるサブキャリアの数量がプリセットルール#2に対応する決定条件を満たしている、すなわち、位置#5にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#2に対応するプリセットサブキャリア数量(すなわち、4×26)以上である、と決定し得る。換言すれば、位置#5に位置するリソースユニットは、2つの2×26リソースユニットのアグリゲーションによって形成されている。
したがって、第3の指示識別子、第4の指示識別子、および第6の指示識別子を参照して、受信端は、位置#3に位置するリソースユニットおよび位置#4は、4×26トーンリソースユニットであると決定することができる、すなわち、割り当て予定の周波数ドメインリソースがリソースユニット#3を含んでいると決定することができる。
したがって、受信端は、割り当て予定の周波数ドメインリソースにおける1番目のリソースユニット(すなわち、リソースユニット#1)は、2×26トーンリソースユニットであり、割り当て予定の周波数ドメインリソースにおける2番目のリソースユニット(すなわち、リソースユニット#2)は、2×26トーンリソースユニットであり、割り当て予定の周波数ドメインリソースにおける3番目のリソースユニット(すなわち、リソースユニット#3)は、4×26トーンリソースユニットである、と決定し得る。
上述したように、受信端の決定プロセスは、送信端の決定プロセスとは逆のプロセスである。繰り返しを避けるために、以下では送信端の決定プロセスとは逆である受信端の決定プロセスに関する詳細な説明を省略する。
当然のことながら、前述の実施形態4を参照すれば、別のオプションの例においては、図7に示したリソースユニットの割り振りについては、まず、割り振られる可能性があるとともに現在の20MHz帯域幅に対応する最大のリソースユニットに含まれるサブキャリアの数量に従って決定が行われる、すなわち、242のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#22と以降示す)が決定され、決定がtype-0ビットの値を取得するために行われる。換言すれば、図4中の第4のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定がtype-0ビットの値を取得するために行われる。
特に、送信端の決定プロセスにおいては、図7に示したリソースユニットの割り振りは、リソースユニット#1、リソースユニット#2、リソースユニット#0、およびリソースユニット#3(図4中の第4のレイヤにおける全リソースユニット)であり、リソースユニットに含まれるサブキャリアの数量は、それぞれ、2×26、2×26、1×26、および4×26であり、プリセットルール#22に対応する決定条件を満たしていない、すなわち、リソースユニット#0、リソースユニット#1、リソースユニット#2、およびリソースユニット#3のうちのいずれか1つに含まれるサブキャリアの数量は、プリセットルール#22に対応するプリセットサブキャリア数量(すなわち、242)に等しくない。したがって、図4中のプリセットルール#22下における第4のレイヤの指示識別子は0であり、指示識別子はオプションである。すなわち、type-0ビットの値は0である。type-0ビットの値を取得した後に、前述のtype-1ビットの値が図7に示した方式に従って続けて取得される。
図8は、type-1マッピングルールに基づいた決定プロセスの別の例のツリー図を示している。一例として20MHz帯域幅を有する割り当て予定の周波数ドメインリソースを使用すれば、割り当て予定の周波数ドメインリソースは、左から右の順に、1つの2×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#1'と以降示す)、3つの1×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#2'、リソースユニット#3'、およびリソースユニット#0'と以降示す)、および1つの4×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#4'と以降示す)を含む。
20MHz帯域幅においては、帯域幅の中心位置に位置する1つの1×26トーンリソースユニット(すなわち、リソースユニット#0')が常に存在しているため、リソースユニットが暗黙的に指示され得ることに留意されたい。したがって、方法100は、主に、リソースユニット#0'を除く任意のリソースユニットに対応する指示識別子を決定することである。繰り返しを避けるために、同一または同様のケースに関する説明は以下では省略する。
まず、図8に示したように、2×26のプリセットサブキャリア数量に対応するプリセットルール(すなわち、プリセットルール#1)が決定され、決定が左から右の順で行われる。
換言すれば、図4中の第2のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
図4中の第2のレイヤにおける位置#1に対応するリソースユニットは、リソースユニット#1'であり、リソースユニット#1'に含まれるサブキャリアの数量は、2×26であり、プリセットルール#1に対応する決定条件を満たしている、すなわち、位置#1にあるリソースユニット(すなわち、リソースユニット#1')に含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量以上である。したがって、プリセットルール#1下における位置#1(または、リソースユニット#1')の指示識別子は、1である。換言すれば、リソースユニット#1は、2つの1×26リソースユニットのアグリゲーションによって形成される。したがって、プリセットルール#1下における位置#1(または、リソースユニット#1')の指示識別子は、1である。
図4中の第2のレイヤにおける位置#2に対応するリソースユニットは、リソースユニット#2'およびリソースユニット#3'であり、リソースユニット#2'およびリソースユニット#3'に含まれるサブキャリアの数量は、1×26であり、プリセットルール#1に対応する決定条件を満たしていない、すなわち、リソースユニット#2'およびリソースユニット#3'に含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量未満である。したがって、プリセットルール#1下における位置#2(または、リソースユニット#2'およびリソースユニット#3')の指示識別子は、0である。換言すれば、リソースユニット#2'およびリソースユニット#3'は、2つの1×26リソースユニットのアグリゲーションによって形成されていない。したがって、プリセットルール#1下における位置#2(または、リソースユニット#2'およびリソースユニット#3')の指示識別子は0である、すなわち、ビット"0"は、プリセットルール#1下では、リソースユニット#2'およびリソースユニット#3'の指示識別子として使用される。
図4中の第2のレイヤにおける位置#3に対応するリソースユニットは、リソースユニット#4'(すなわち、リソースユニット#4'の一部)であり、リソースユニット#4'に含まれるサブキャリアの数量は、4×26であり、プリセットルール#1に対応する決定条件を満たしている、すなわち、リソースユニット#4'に含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量以上である。換言すれば、リソースユニット#4'は、2つの1×26リソースユニットのアグリゲーションによって形成される。したがって、プリセットルール#1下における位置#3の指示識別子は、1である。
さらに、図4中の第2のレイヤにおける位置#4に対応するリソースユニットは、リソースユニット#4'(すなわち、リソースユニット#4'の一部)であり、リソースユニット#4'に含まれるサブキャリアの数量は、4×26であり、プリセットルール#1に対応する決定条件を満たしている、すなわち、リソースユニット#4'に含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量以上である。換言すれば、リソースユニット#4'は、2つの1×26リソースユニットのアグリゲーションによって形成される。したがって、プリセットルール#1下における位置#4の指示識別子は、1である。
したがって、プリセットルール#1下における位置#3および位置#4に位置するリソースユニット#4'の指示識別子は、11である。
その後、図8に示したように、4×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#2と以降示す)が決定され、決定が左から右へと行われる。
換言すれば、図4中の第3のレイヤにおけるリソースユニットの割り振りマップが決定基準として使用され、決定が左から右の順で行われる。
図4中の第3のレイヤにおける位置#5に対応するリソースユニットは、リソースユニット#1'、リソースユニット#2'、およびリソースユニット#3'であり、リソースユニット#1'、リソースユニット#2'、およびリソースユニット#3'に含まれるサブキャリアの数量のいずれも、プリセットルール#2に対応する決定条件を満たしている、すなわち、リソースユニット#1'、リソースユニット#2'、およびリソースユニット#3'に含まれるサブキャリアの数量のすべては、プリセットルール#2に対応するプリセットサブキャリア数量未満である。したがって、プリセットルール#2下における位置#5(または、リソースユニット#1'、リソースユニット#2'、およびリソースユニット#3')の指示識別子は、0である。換言すれば、リソースユニット#1'、リソースユニット#2'、およびリソースユニット#3'は、2つの2×26リソースユニットのアグリゲーションによって形成されていない。したがって、プリセットルール#2下におけるリソースユニット#1'、リソースユニット#2'、およびリソースユニット#3'の指示識別子は、0である。すなわち、ビット"0"は、プリセットルール#2下では、リソースユニット#1'、リソースユニット#2'、およびリソースユニット#3'の指示識別子として使用される。
加えて、図4中の第3のレイヤにおける位置#5にあるリソースユニットが1つの2×26リソースユニットおよび2つの1×26リソースユニットであるとルール1下で決定されるため、図4中の第3のレイヤにおける位置#5の割り振りは既に完了している。したがって、プリセットルール#2下におけるリソースユニット#1'、リソースユニット#2'、およびリソースユニット#3'の指示識別子も省略され得る。
図4中の第3のレイヤにおける位置#6に対応するリソースユニットは、リソースユニット#4'であり、リソースユニット#4'に含まれるサブキャリアの数量は、4×26であり、プリセットルール#2に対応する決定条件を満たしている、すなわち、リソースユニット#4'に含まれるサブキャリアの数量は、プリセットルール#2に対応するプリセットサブキャリア数量以上である。したがって、プリセットルール#2下における位置#6(または、リソースユニット#4')の指示識別子は、1である。換言すれば、リソースユニット#4'は、2つの2×26リソースユニットのアグリゲーションによって形成される。したがって、プリセットルール#2下におけるリソースユニット#4'の指示識別子は、1である。
すなわち、type-1マッピングルールに基づいて図8に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、101101または10111である。すなわち、従来技術におけるビットシーケンスを生成するための方法と比較して、3または4ビットのオーバーヘッドを使わずに済ますことができる。
当然のことながら、同様に、前述の実施形態4を参照すれば、別のオプションの例においては、図8に示したリソースユニットの割り振りについては、まず、割り振られる可能性があるとともに現在の20MHz帯域幅に対応する最大のリソースユニットに含まれるサブキャリアの数量に従って決定が行われる、すなわち、242のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#22と以降示す)が決定され、決定がtype-0ビットの値を取得するために行われる。換言すれば、図4中の第4のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定がtype-0ビットの値を取得するために行われる。
特に、送信端の決定プロセスにおいては、図8に示したリソースユニットの割り振りは、リソースユニット#1'、リソースユニット#2'、リソースユニット#3'、リソースユニット#0'、およびリソースユニット#4'であり、リソースユニットに含まれるサブキャリアの数量は、それぞれ、2×26、1×26、1×26、1×26、および4×26であり、プリセットルール#22に対応する決定条件を満たしていない、すなわち、リソースユニット#1'、リソースユニット#2'、リソースユニット#3'、リソースユニット#0'、およびリソースユニット#4'のうちのいずれか1つに含まれるサブキャリアの数量は、プリセットルール#22に対応するプリセットサブキャリア数量(すなわち、242)に等しくない。したがって、プリセットルール#22下における指示識別子は0であり、指示識別子はオプションである。すなわち、type-0ビットの値は0である。type-0ビットの値を取得した後に、前述のtype-1ビットの値が図8に示した方式に従って続けて取得される。
換言すれば、プリセットルール#22下におけるオプション指示識別子を含んでいる場合には、type-1マッピングルールに基づいて図8に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、0101101または010111であり、従来技術におけるビットシーケンスを生成するための方法と比較して、2または3ビットのオーバーヘッドを使わずに済ますことができる。オプションとして、デフォルトリソースユニットの位置が利用可能であるかどうかを指示する1ビットをさらに含み得る。
type-1マッピングルールおよびtype-1マッピングルールに基づいた処理プロシージャを図7および図8を参照して上記では説明している。type-2およびtype-3マッピングルールならびにtype-2およびtype-3マッピングルールに基づいた処理プロシージャを図9から図14を参照して以下に詳細に説明する。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を有し、
指示識別子に従ってビットシーケンスを決定することは、
割り当て予定の周波数ドメインリソースの対称中心に対する割り当て予定の周波数ドメインリソースにおける各リソースユニットの位置に従って配置順序を決定することと、
配置順序に基づくとともに指示識別子に従って、割り当て予定の周波数ドメインリソースを指示するビットシーケンスを決定することとを含む。
特に、図4から図6に示したように、各レイヤにおける20MHz帯域幅の周波数ドメインリソースのリソースユニットの割り振り(または、リソースユニットの位置)は、中心位置に位置する1×26トーンリソースサブユニットに対する対称性(すなわち、対称中心の例)があり、各レイヤにおける40MHz帯域幅の周波数ドメインリソースのリソースユニットの割り振りは、中心点に対する対称性(すなわち、対称中心の別の例)があり、各レイヤにおける80MHz帯域幅の周波数ドメインリソースのリソースユニットの割り振りは、中心位置に位置する1×26トーンリソースサブユニットに対する対称性(すなわち、対称中心のさらに別の例)があり、各レイヤにおける160MHz帯域幅の周波数ドメインリソースのリソースユニットの割り振りは、中心点に対する対称性(すなわち、対称中心のさらに別の例)がある。
本発明の本実施形態においては、送信端は、前述の対称性を使用して各マッピングルール下における各リソースユニットの識別子を決定し得る。
β. Type-2マッピングルール(実施形態2に対応)
本発明の本実施形態においては、送信端は、プリセットサブキャリア数量の降順で各マッピングルール下における各リソースユニットの識別子を決定し得る。
この場合には、type-2マッピングルール(理解および識別を容易にするために、マッピングルール#Bと以降示す)は、対称中心の左サイドまたは右サイド上の指定の周波数ドメイン位置に位置するリソースユニットのサイズ(すなわち、含まれているサブキャリアの数量)がマッピングルール#Bに対応するプリセットサブキャリア数量以上であるかどうかを決定するものとして記述され得る。yesと決定された場合には、マッピングルール#B下における周波数ドメイン位置の指示識別子は、1である。noと決定された場合には、マッピングルール#B下における周波数ドメイン位置の指示識別子は、0である。
換言すれば、プリセットサブキャリア数量の前述の順序は、図4から図6に示したレイヤの順序に対応するようになり得る、すなわち、送信端は、リソースユニットの前述の割り振りマップにおいてボトムアップ順(すなわち、プリセットサブキャリア数量の降順)で各レイヤに対応するマッピングルールを決定し得る。
図9は、type-2マッピングルールに基づいた決定プロセスの例のツリー図を示している。一例として20MHz帯域幅を有する割り当て予定の周波数ドメインリソースを使用すれば、割り当て予定の周波数ドメインリソースは、左から右の順に、2つの2×26トーンリソースユニット(すなわち、リソースユニット#1およびリソースユニット#2)、1つの1×26トーンリソースユニット(すなわち、リソースユニット#0)、および1つの4×26トーンリソースユニット(すなわち、リソースユニット#3)を含む。
同様に、20MHz帯域幅においては、帯域幅の真ん中の位置に位置する1つの1×26トーンリソースユニット(すなわち、リソースユニット#0)が常に存在しているため、リソースユニットが暗黙的に指示され得る。したがって、方法100は、主に、リソースユニット#0を除く任意のリソースユニットに対応する指示識別子を決定することである。
まず、図9に示したように、20MHz帯域幅におけるデフォルト位置の一方のサイド上に位置する最大のリソースユニットに含まれるサブキャリアの数量に従って決定が行われる、すなわち、4×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#3と以降示す)が決定され、決定が左から右の順で行われる。
換言すれば、図4中の第3のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
送信端の決定プロセスにおいては、図4中の第3のレイヤにおける位置#5に対応する(20MHzの対称中心の左サイド上の)リソースユニットは、リソースユニット#1およびリソースユニット#2であり、リソースユニット#1およびリソースユニット#2に含まれるサブキャリアの数量は、2×26であり、プリセットルール#3に対応する決定条件を満たしていない、すなわち、リソースユニット#1およびリソースユニット#2に含まれるサブキャリアの数量は、プリセットルール#1に対応するプリセットサブキャリア数量(すなわち、4×26)に等しくない。したがって、プリセットルール#3下における位置#1(または、リソースユニット#1およびリソースユニット#2)の指示識別子は、0である。
図4中の第3のレイヤにおける位置#6に対応する(すなわち、20MHzの対称中心の右サイド上の)リソースユニットは、リソースユニット#3であり、リソースユニット#3に含まれるサブキャリアの数量は、4×26であり、プリセットルール#3に対応する決定条件を満たしている、すなわち、リソースユニット#2に含まれるサブキャリアの数量は、プリセットルール#3に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#3下における位置#3(または、リソースユニット#3)の指示識別子は、1である。
ここで、20MHz帯域幅においては、対称中心の一方のサイド上の最大のリソースユニットのタイプが4×26RUである(242RUがシングルユーザ伝送のために1人のユーザに割り振られることは除く)ため、対称中心の右サイド上の周波数ドメインリソース、すなわち、位置#6(または、位置#3および位置#4)に対応する周波数ドメインリソースの割り振りは完了している。
その後、図9に示したように、2×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#4と以降示す)が決定され、決定が左から右へと行われる。
換言すれば、図4中の第2のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
図4中の第2のレイヤにおける位置#1に対応する(すなわち、10MHzの対称中心の左サイド上の)リソースユニットは、リソースユニット#1であり、リソースユニット#1に含まれるサブキャリアの数量は、2×26であり、プリセットルール#4に対応する決定条件を満たしている、すなわち、リソースユニット#1に含まれるサブキャリアの数量は、プリセットルール#4に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#4下における位置#1(または、リソースユニット#1)の指示識別子は、1である。
図4中の第2のレイヤにおける位置#2に対応する(すなわち、10MHzの対称中心の右サイド上の)リソースユニットは、リソースユニット#2であり、リソースユニット#2に含まれるサブキャリアの数量は、2×26であり、プリセットルール#4に対応する決定条件を満たしている、すなわち、リソースユニット#2に含まれるサブキャリアの数量は、プリセットルール#4に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#4下における位置#2(または、リソースユニット#2)の指示識別子は、1である。
したがって、対称中心の左サイド上の周波数ドメインリソース、すなわち、位置#5(または、位置#1および位置#2)に対応する周波数ドメインリソースの割り振りは完了している。
type-2マッピングルールに基づいて図9に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、0111であり、従来技術におけるビットシーケンスを生成するための方法と比較して、5ビットのオーバーヘッドを使わずに済ますことができる。
それに対応するように、受信端の決定プロセスにおいては、ビットシーケンス中の最初の2ビットは、図4中の第3のレイヤにおける位置#5および位置#6における割り当て予定の周波数ドメインリソース内のリソースユニットの割り振りを指示する。
第1の指示識別子は、1である。したがって、受信端は、図4中の第3のレイヤにおける位置#5にあるリソースユニット(すなわち、リソースユニット#1およびリソースユニット#2)に含まれるサブキャリアの数量がプリセットルール#3に対応する決定条件を満たしていない、すなわち、位置#5にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#3に対応するプリセットサブキャリア数量(すなわち、4×26)に等しくない、と決定し得る。換言すれば、位置#5に位置するリソースユニットは、4×26トーンリソースユニットではない。
第2の指示識別子は、1である。したがって、受信端は、図4中の第3のレイヤにおける位置#6にあるリソースユニット(すなわち、リソースユニット#3)に含まれるサブキャリアの数量がプリセットルール#3に対応する決定条件を満たしている、すなわち、位置#6にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#3に対応するプリセットサブキャリア数量(すなわち、4×26)と等しい、と決定し得る。
したがって、第2の指示識別子を参照して、受信端は、位置#6に位置するリソースユニットが4×26トーンリソースユニットであると決定することができる、すなわち、受信端は、対称中心の右サイド上のリソースユニットが4×26トーンリソースユニットであると決定することができる。したがって、対称中心の右サイド上に位置するリソースユニット#3(位置#3、位置#4、または位置#6)が決定され得る。
したがって、受信端は、ビットシーケンス中の3番目のビットおよび4番目のビットが図4中の第2のレイヤにおける位置#1および位置#2における割り当て予定の周波数ドメインリソース内のリソースユニットの割り振りを指示していると決定し得る。
第3の指示識別子は、1である。したがって、受信端は、図4中の第2のレイヤにおける位置#1にあるリソースユニット(すなわち、リソースユニット#1)に含まれるサブキャリアの数量がプリセットルール#4に対応する決定条件を満たしている、すなわち、位置#1にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#4に対応するプリセットサブキャリア数量(すなわち、2×26)と等しい、と決定し得る。換言すれば、位置#1に位置するリソースユニットは、2×26トーンリソースユニットである。
第4の指示識別子は、1である。したがって、受信端は、図4中の第2のレイヤにおける位置#2にあるリソースユニット(すなわち、リソースユニット#2)に含まれるサブキャリアの数量がプリセットルール#4に対応する決定条件を満たしている、すなわち、位置#2にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#4に対応するプリセットサブキャリア数量(すなわち、2×26)と等しい、と決定し得る。換言すれば、位置#2に位置するリソースユニットは、2×26トーンリソースユニットである。
したがって、第1の指示識別子、第3の指示識別子、および第4の指示識別子を参照して、受信端は、位置#1に位置するリソースユニットおよび位置#2は、2つの2×26トーンリソースユニットであると決定することができる、すなわち、割り当て予定の周波数ドメインリソースがリソースユニット#1およびリソースユニット#2を含んでいると決定することができる。
したがって、受信端は、割り当て予定の周波数ドメインリソースにおける1番目のリソースユニット(すなわち、リソースユニット#1)は、2×26トーンリソースユニットであり、割り当て予定の周波数ドメインリソースにおける2番目のリソースユニット(すなわち、リソースユニット#2)は、2×26トーンリソースユニットであり、割り当て予定の周波数ドメインリソースにおける3番目のリソースユニット(すなわち、リソースユニット#3)は、4×26トーンリソースユニットである、と決定し得る。
上述したように、受信端の決定プロセスは、送信端の決定プロセスとは逆のプロセスである。繰り返しを避けるために、以下では送信端の決定プロセスとは逆である受信端の決定プロセスに関する詳細な説明を省略する。
当然のことながら、同様に、前述の実施形態4を参照すれば、別のオプションの例においては、図9に示したリソースユニットの割り振りについては、まず、割り振られる可能性があるとともに20MHz帯域幅に対応する最大のリソースユニットに含まれるサブキャリアの数量に従って決定が行われる、すなわち、242のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#22と以降示す)が決定され、決定がtype-0ビットの値を取得するために行われる。換言すれば、図4中の第4のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定がtype-0ビットの値を取得するために行われる。
特に、送信端の決定プロセスにおいては、図9に示したリソースユニットの割り振りは、リソースユニット#1、リソースユニット#2、リソースユニット#0、およびリソースユニット#3であり、リソースユニットに含まれるサブキャリアの数量は、それぞれ、2×26、1×26、1×26、1×26、および4×26であり、プリセットルール#22に対応する決定条件を満たしていない、すなわち、リソースユニット#1、リソースユニット#2、リソースユニット#0、およびリソースユニット#3のうちのいずれか1つに含まれるサブキャリアの数量は、プリセットルール#22に対応するプリセットサブキャリア数量(すなわち、242)に等しくない。したがって、プリセットルール#22下における指示識別子は0であり、指示識別子はオプションである。すなわち、type-0ビットの値は0である。type-0ビットの値を取得した後に、前述のtype-2ビットの値が図9に示した方式に従って続けて取得される。
換言すれば、プリセットルール#22下におけるオプション指示識別子を含んでいる場合には、type-2マッピングルールに基づいて図9に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、00111であり、従来技術におけるビットシーケンスを生成するための方法と比較して、4ビットのオーバーヘッドを使わずに済ますことができる。オプションとして、デフォルトリソースユニットの位置が利用可能であるかどうかを指示する1ビットをさらに含み得る。
図10は、type-2マッピングルールに基づいた決定プロセスの別の例のツリー図を示している。一例として40MHz帯域幅を有する割り当て予定の周波数ドメインリソースを使用すれば、割り当て予定の周波数ドメインリソースは、左から右の順に、2つの2×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#1''およびリソースユニット#2''と以降示す)、1つの1×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#0''と以降示す)、1つの4×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#3''と以降示す)、および1つの4×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#4''と以降示す)を含む。
まず、図10に示したように、40MHz帯域幅における最大のリソースユニットに含まれるサブキャリアの数量を決定し、すなわち、242のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#7と以降示す)が決定され、決定が左から右の順で行われる。
換言すれば、図5中の第4のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
送信端の決定プロセスにおいては、図5中の第4のレイヤにおける位置#Aに対応する(すなわち、40MHzの対称中心の左サイド上の)リソースユニットは、リソースユニット#1''、リソースユニット#2''、リソースユニット#0''、およびリソースユニット#3''であり、リソースユニットに含まれるサブキャリアの数量は、242ではなく、プリセットルール#7に対応する決定条件を満たしていない、すなわち、リソースユニット#1''、リソースユニット#2''、リソースユニット#0''、およびリソースユニット#3''に含まれるサブキャリアの数量は、プリセットルール#7に対応するプリセットサブキャリア数量(すなわち、242)に等しくない。したがって、プリセットルール#7下における位置#A(または、リソースユニット#1''、リソースユニット#2''、リソースユニット#0''、およびリソースユニット#3'')の指示識別子は、0である。
図5中の第4のレイヤにおける位置#Bに対応する(すなわち、40MHzの対称中心の右サイド上の)リソースユニットは、リソースユニット#4''であり、リソースユニット#4''に含まれるサブキャリアの数量は、242であり、プリセットルール#7に対応する決定条件を満たしている、すなわち、リソースユニット#4''に含まれるサブキャリアの数量は、プリセットルール#7に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#7下における位置#B(または、リソースユニット#4'')の指示識別子は、1である。
ここで、40MHz帯域幅においては、最大のリソースユニットのタイプが242であるため、対称中心の右サイド上の周波数ドメインリソース、すなわち、位置#Bに対応する周波数ドメインリソースの割り振りは完了している。
その後、図10に示したように、対称中心の左サイド上で全体的に割り振られていない20MHz帯域幅の周波数ドメインリソースにおける、20MHz帯域幅における対称中心の一方のサイド上における最大のリソースユニットに含まれるサブキャリアの数量が決定される、すなわち、4×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#8と以降示す)が決定され、決定が左から右の順で行われる。
換言すれば、図5中の第3のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
送信端の決定プロセスにおいては、図5中の第3のレイヤにおける位置#Cに対応する(20MHzの対称中心の左サイド上の)リソースユニットは、リソースユニット#1''およびリソースユニット#2''であり、リソースユニット#1''およびリソースユニット#2''に含まれるサブキャリアの数量は、2×26であり、プリセットルール#8に対応する決定条件を満たしていない、すなわち、リソースユニット#1''およびリソースユニット#2''に含まれるサブキャリアの数量は、プリセットルール#8に対応するプリセットサブキャリア数量(すなわち、4×26)に等しくない。したがって、プリセットルール#8下における位置#C(または、リソースユニット#1''およびリソースユニット#2'')の指示識別子は、0である。
加えて、20MHz帯域幅においては、帯域幅の真ん中の位置に位置する1つの1×26トーンリソースユニット(すなわち、リソースユニット#0'')が常に存在しているため、リソースユニットが暗黙的に指示され得る。
図5中の第3のレイヤにおける位置#Dに対応する(すなわち、20MHzの対称中心の右サイド上の)リソースユニットは、リソースユニット#3''であり、リソースユニット#3''に含まれるサブキャリアの数量は、4×26であり、プリセットルール#8に対応する決定条件を満たしている、すなわち、リソースユニット#3''に含まれるサブキャリアの数量は、プリセットルール#8に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#8下における位置#D(または、リソースユニット#3'')の指示識別子は、1である。
ここで、20MHz帯域幅においては、最大のリソースユニットのタイプが4×26であるため、対称中心の右サイド上の周波数ドメインリソース、すなわち、位置#Dに対応する周波数ドメインリソースの割り振りは完了している。
その後、図10に示したように、2×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#9と以降示す)が決定され、決定が左から右へと行われる。
換言すれば、図5中の第2のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
図5中の第2のレイヤにおいては位置#Eに対応する(すなわち、10MHzの対称中心の左サイド上の)リソースユニットは、リソースユニット#1''であり、リソースユニット#1''に含まれるサブキャリアの数量は、2×26であり、プリセットルール#9に対応する決定条件を満たしている、すなわち、リソースユニット#1''に含まれるサブキャリアの数量は、プリセットルール#9に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#9下における位置#E(または、リソースユニット#1'')の指示識別子は、1である。
図5中の第2のレイヤにおける位置#Fに対応する(すなわち、10MHzの対称中心の右サイド上の)リソースユニットは、リソースユニット#2''であり、リソースユニット#2''に含まれるサブキャリアの数量は、2×26であり、プリセットルール#9に対応する決定条件を満たしている、すなわち、リソースユニット#2''に含まれるサブキャリアの数量は、プリセットルール#9に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#9下における位置#F(または、リソースユニット#2'')の指示識別子は、1である。
前述の説明においては、異なる帯域幅における処理に対応するために、プリセットルール#3とプリセットルール#8とを、同様に、プリセットルール#4とプリセットルール#9とを区別するために異なるマークを使用している、ただし、プリセットルールに対応するプリセットサブキャリア数量は同一であることに留意されたい。
type-1マッピングルールに基づいて図10に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、010111であり、従来技術におけるビットシーケンスを生成するための方法と比較して、12ビットのオーバーヘッドを使わずに済ますことができる。
当然のことながら、同様に、前述の実施形態4を参照すれば、別のオプションの例においては、図10に示したリソースユニットの割り振りについては、まず、割り振られる可能性があるとともに40MHz帯域幅に対応する最大のリソースユニットに含まれるサブキャリアの数量に従って決定が行われる、すなわち、484のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#23と以降示す)が決定され、決定がtype-0ビットの値を取得するために行われる。換言すれば、図5中の第5のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定がtype-0ビットの値を取得するために行われる。
特に、送信端の決定プロセスにおいては、図10に示したリソースユニットの割り振りは、リソースユニット#1''、リソースユニット#2''、リソースユニット#0''、リソースユニット#3''、およびリソースユニット#4''であり、リソースユニットに含まれるサブキャリアの数量は、それぞれ、2×26、2×26、1×26、4×26、および242であり、プリセットルール#22に対応する決定条件を満たしていない、すなわち、リソースユニット#1''、リソースユニット#2''、リソースユニット#0''、リソースユニット#3''、およびリソースユニット#4''のうちのいずれか1つに含まれるサブキャリアの数量は、プリセットルール#23に対応するプリセットサブキャリア数量(すなわち、484)に等しくない。したがって、プリセットルール#23下における指示識別子は0であり、指示識別子はオプションである。すなわち、type-0ビットの値は0である。type-0ビットの値を取得した後に、前述のtype-2ビットの値が図10に示した方式に従って続けて取得される。
換言すれば、プリセットルール#23下におけるオプション指示識別子を含んでいる場合には、type-2マッピングルールに基づいて図10に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、0010111であり、従来技術におけるビットシーケンスを生成するための方法と比較して、11ビットのオーバーヘッドを使わずに済ますことができる。オプションとして、2つのデフォルトリソースユニットの位置が利用可能であるかどうかを指示する2ビットをさらに含み得る。
図11は、type-2マッピングルールに基づいた決定プロセスのさらに別の例のツリー図を示している。一例として80MHz帯域幅を有する割り当て予定の周波数ドメインリソースを使用すれば、割り当て予定の周波数ドメインリソースは、左から右の順に、1つの4×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#1'''と以降示す)、1つの1×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#0'''と以降示す)、1つの4×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#2'''と以降示す)、1つの242トーンリソースユニット(理解および識別を容易にするために、リソースユニット#3'''と以降示す)、1つの1×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#00'''と以降示す)、および1つの2×242トーンリソースユニット(理解および識別を容易にするために、リソースユニット#4'''と以降示す)を含む。
まず、図11に示したように、80MHz帯域幅における対称中心の一方のサイド上に位置する最大のリソースユニットに含まれるサブキャリアの数量が決定される、すなわち、2×242のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#10と以降示す)が決定され、決定が左から右の順で行われる。
換言すれば、図6中の第5のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
送信端の決定プロセスにおいては、図6中の第5のレイヤにおける位置#aに対応する(すなわち、80MHzの対称中心におけるリソースユニット#00の左サイド上の)リソースユニットは、リソースユニット#1'''、リソースユニット#0'''、リソースユニット#2'''、およびリソースユニット#3'''であり、リソースユニットに含まれるサブキャリアの数量は、2×242ではなく、プリセットルール#10に対応する決定条件を満たしていない、すなわち、リソースユニット#1'''、リソースユニット#0'''、リソースユニット#2'''、およびリソースユニット#3''に含まれるサブキャリアの数量は、プリセットルール#10に対応するプリセットサブキャリア数量(すなわち、2×242)に等しくない。したがって、プリセットルール#10下における位置#A(または、リソースユニット#1'''、リソースユニット#0'''、リソースユニット#2'''、およびリソースユニット#3'')の指示識別子は、0である。
加えて、80MHz帯域幅においては、帯域幅の真ん中の位置に位置する1つの1×26トーンリソースユニット(すなわち、リソースユニット#00''')が常に存在しているため、リソースユニットが暗黙的に指示され得る。
図6中の第5のレイヤにおける位置#bに対応する(すなわち、80MHzの対称中心におけるリソースユニット#00''の右サイド上の)リソースユニットは、リソースユニット#4'''であり、リソースユニット#4'''に含まれるサブキャリアの数量は、2×242であり、プリセットルール#10に対応する決定条件を満たしている、すなわち、リソースユニット#4'''に含まれるサブキャリアの数量は、プリセットルール#10に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#10下における位置#b(または、リソースユニット#4''')の指示識別子は、1である。
ここで、80MHz帯域幅においては、最大のリソースユニットのタイプが2×242であるため、対称中心の右サイド上の周波数ドメインリソース、すなわち、位置#bに対応する周波数ドメインリソースの割り振りは完了している。
その後、図11に示したように、対称中心の左サイド上で全体的に割り振られていない40MHz帯域幅の周波数ドメインリソースにおける、40MHz帯域幅における最大のリソースユニットに含まれるサブキャリアの数量が決定される、すなわち、242のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#11と以降示す)が決定され、決定が左から右の順で行われる。
換言すれば、図6中の第4のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
送信端の決定プロセスにおいては、図6中の第4のレイヤにおける位置#cに対応する(すなわち、40MHzの対称中心の左サイド上の)リソースユニットは、リソースユニット#1'''、リソースユニット#0'''、およびリソースユニット#2'''であり、リソースユニットに含まれるサブキャリアの数量は、242ではなく、プリセットルール#11に対応する決定条件を満たしていない、すなわち、リソースユニット#1'''、リソースユニット#0'''、およびリソースユニット#2'''に含まれるサブキャリアの数量は、プリセットルール#11に対応するプリセットサブキャリア数量(すなわち、242)に等しくない。したがって、プリセットルール#11下における位置#c(または、リソースユニット#1'''、リソースユニット#0'''、およびリソースユニット#2''')の指示識別子は、0である。
図6中の第4のレイヤにおける位置#dに対応する(すなわち、40MHzの対称中心の右サイド上の)リソースユニットは、リソースユニット#3'''であり、リソースユニット#3'''に含まれるサブキャリアの数量は、242であり、プリセットルール#11に対応する決定条件を満たしている、すなわち、リソースユニット#3'''に含まれるサブキャリアの数量は、プリセットルール#11に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#11下における位置#d(または、リソースユニット#3''')の指示識別子は、1である。
ここで、40MHz帯域幅においては、最大のリソースユニットのタイプが242であるため、対称中心の右サイド上の周波数ドメインリソース、すなわち、位置#dに対応する周波数ドメインリソースの割り振りは完了している。
その後、図11に示したように、4×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#12と以降示す)が決定され、決定が左から右へと行われる。
換言すれば、図6中の第3のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
図6中の第3のレイヤにおける位置#eに対応する(すなわち、20MHzの対称中心の左サイド上の)リソースユニットは、リソースユニット#1'''であり、リソースユニット#1'''に含まれるサブキャリアの数量は、4×26であり、プリセットルール#12に対応する決定条件を満たしている、すなわち、リソースユニット#1'''に含まれるサブキャリアの数量は、プリセットルール#12に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#12下における位置#e(または、リソースユニット#1''')の指示識別子は、1である。
加えて、20MHz帯域幅においては、帯域幅の真ん中の位置に位置する1つの1×26トーンリソースユニット(すなわち、リソースユニット#0''')が常に存在しているため、リソースユニットが暗黙的に指示され得る。
図6中の第3のレイヤにおける位置#fに対応する(すなわち、20MHzの対称中心の右サイド上の)リソースユニットは、リソースユニット#2'''であり、リソースユニット#2'''に含まれるサブキャリアの数量は、4×26であり、プリセットルール#12に対応する決定条件を満たしている、すなわち、リソースユニット#2'''に含まれるサブキャリアの数量は、プリセットルール#12に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#12下における位置#f(または、リソースユニット#2''')の指示識別子は、1である。
ここで、20MHz帯域幅においては、最大のリソースユニットのタイプが4×26であるため、対称中心の左サイドおよび右サイド上の周波数ドメインリソース、すなわち、位置#eおよび位置#fに対応する周波数ドメインリソースの割り振りは完了している。
前述の説明においては、異なる帯域幅における処理に対応するために、プリセットルール#3とプリセットルール#8とを、同様に、プリセットルール#4とプリセットルール#9とを区別するために異なるマークを使用している、ただし、プリセットルールに対応するプリセットサブキャリア数量は同一であることに留意されたい。
type-1マッピングルールに基づいて図11に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、010111であり、従来技術におけるビットシーケンスを生成するための方法と比較して、31ビットのオーバーヘッドを使わずに済ますことができる。
当然のことながら、同様に、前述の実施形態4を参照すれば、別のオプションの例においては、図10に示したリソースユニットの割り振りについては、まず、割り振られる可能性があるとともに80MHz帯域幅に対応する最大のリソースユニットに含まれるサブキャリアの数量に従って決定が行われる、すなわち、996のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#24と以降示す)が決定され、決定がtype-0ビットの値を取得するために行われる。換言すれば、図6中の第6のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定がtype-0ビットの値を取得するために行われる。
特に、送信端の決定プロセスにおいては、図11に示したリソースユニットの割り振りは、リソースユニット#1''、リソースユニット#0''、リソースユニット#2''、リソースユニット#3''、リソースユニット#00''、およびリソースユニット#4''であり、リソースユニットに含まれるサブキャリアの数量は、それぞれ、4×26、1×26、4×26、242、1×26、および2×242であり、プリセットルール#24に対応する決定条件を満たしていない、すなわち、リソースユニット#1''、リソースユニット#0''、リソースユニット#2''、リソースユニット#3''、リソースユニット#00''、およびリソースユニット#4''のうちのいずれか1つに含まれるサブキャリアの数量は、プリセットルール#24に対応するプリセットサブキャリア数量(すなわち、996)に等しくない。したがって、プリセットルール#24下における指示識別子は0であり、指示識別子はオプションである。すなわち、type-0ビットの値は0である。type-0ビットの値を取得した後に、前述のtype-2ビットの値が図11に示した方式に従って続けて取得される。
換言すれば、プリセットルール#24下におけるオプション指示識別子を含んでいる場合には、type-2マッピングルールに基づいて図11に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、0010111であり、従来技術におけるビットシーケンスを生成するための方法と比較して、30ビットのオーバーヘッドを使わずに済ますことができる。オプションとして、5つのデフォルトリソースユニットの位置が利用可能であるかどうかを指示する5ビットをさらに含み得る。
大きな帯域幅(20MHzより大きい)については、図10および図11に対応する実施形態の方法はまた、最小粒度の20Mの帯域幅を指示するためだけに適用可能であり得る、すなわち、他の方法は、20Mの帯域幅内でのリソース割り振りを指示するためのものであり得る。この場合には、図10中の対応する破線ボックスを除去してもよく、type-1マッピングルールに基づいて図10中の割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、01である。図11中の対応する破線ボックスを除去してもよく、type-1マッピングルールに基づいて図11中の割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、0101である。
γ. type-3マッピングルール(実施形態3に対応)
本発明の本実施形態においては、送信端は、プリセットサブキャリア数量の昇順で各マッピングルール下における各リソースユニットの識別子を決定し得る。
この場合には、type-3マッピングルール(理解および識別を容易にするために、マッピングルール#Cと以降示す)は、対称中心の左サイドまたは右サイド上の指定の周波数ドメイン位置に位置するリソースユニットのサイズ(すなわち、含まれているサブキャリアの数量)がマッピングルール#Cに対応するプリセットサブキャリア数量以上であるかどうかを決定するものとして記述され得る。yesと決定された場合には、マッピングルール#C下における周波数ドメイン位置の指示識別子は、1である。noと決定された場合には、マッピングルール#C下における周波数ドメイン位置の指示識別子は、0である。
換言すれば、プリセットサブキャリア数量の前述の順序は、図4から図6に示したレイヤの順序に対応するようになり得る、すなわち、送信端は、リソースユニットの前述の割り振りマップにおいてボトムアップ順(すなわち、プリセットサブキャリア数量の昇順)で各レイヤに対応するマッピングルールを決定し得る。
図12は、type-3マッピングルールに基づいた決定プロセスの例のツリー図を示している。一例として20MHz帯域幅を有する割り当て予定の周波数ドメインリソースを使用すれば、割り当て予定の周波数ドメインリソースは、左から右の順に、2つの2×26トーンリソースユニット(すなわち、リソースユニット#1およびリソースユニット#2)、1つの1×26トーンリソースユニット(すなわち、リソースユニット#0)、および1つの4×26トーンリソースユニット(すなわち、リソースユニット#3)を含む。
20MHz帯域幅においては、帯域幅の真ん中の位置に位置する1つの1×26トーンリソースユニット(すなわち、リソースユニット#0)が常に存在しているため、リソースユニットが暗黙的に指示され得ることに留意されたい。したがって、方法100は、主に、リソースユニット#0を除く任意のリソースユニットに対応する指示識別子を決定することである。繰り返しを避けるために、同一または同様のケースに関する説明は以下では省略する。
まず、図12に示したように、1×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#5と以降示す)が決定され、決定が左から右の順で行われる。
換言すれば、図4中の第1のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
送信端の決定プロセスにおいては、まず、割り当て予定の周波数ドメインリソースの対称中心の左サイド(すなわち、図4中の位置#7から位置#10に対応)上のリソースユニット(すなわち、リソースユニット#1およびリソースユニット#2)のサイズがすべて1×26であるかどうかを決定する。リソースユニット#1およびリソースユニット#2に含まれるサブキャリアの数量は、2×26であり、プリセットルール#5に対応する決定条件を満たしていない、すなわち、リソースユニット#1およびリソースユニット#2に含まれるサブキャリアの数量は両方、プリセットルール#5に対応するプリセットサブキャリア数量に等しくないため、プリセットルール#5下における図4中の位置#7から位置#10(または、リソースユニット#1およびリソースユニット#2)の指示識別子は、0である。
その後、割り当て予定の周波数ドメインリソースの対称中心の右サイド(すなわち、図4中の位置#11から位置#14に対応)上のリソースユニット(すなわち、リソースユニット#3)のサイズがすべて1×26であるかどうかを決定する。リソースユニット#3に含まれるサブキャリアの数量は、4×26であり、プリセットルール#5に対応する決定条件を満たしていない、すなわち、リソースユニット#3に含まれるサブキャリアの数量は、プリセットルール#5に対応するプリセットサブキャリア数量に等しくないため、プリセットルール#5下における図4中の位置#11から位置#14(または、リソースユニット#3)の指示識別子は、0である。
その後、図12に示したように、2×26のプリセットサブキャリア数量に対応するプリセットルール(理解および識別を容易にするために、プリセットルール#6と以降示す)が決定され、決定が左から右へと行われる。
換言すれば、図4中の第2のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
図4中の第2のレイヤにおける位置#1に対応するリソースユニットは、リソースユニット#1であり、リソースユニット#1に含まれるサブキャリアの数量は、2×26であり、プリセットルール#6に対応する決定条件を満たしている、すなわち、リソースユニット#1に含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#6下における位置#1(または、リソースユニット#1)の指示識別子は、1である。
図4中の第2のレイヤにおける位置#2に対応するリソースユニットは、リソースユニット#2であり、リソースユニット#2に含まれるサブキャリアの数量は、2×26であり、プリセットルール#6に対応する決定条件を満たしている、すなわち、リソースユニット#2に含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#6下における位置#2(または、リソースユニット#2)の指示識別子は、1である。
図4中の第2のレイヤにおける位置#3に対応するリソースユニットは、リソースユニット#3であり、リソースユニット#3に含まれるサブキャリアの数量は、4×26であり、プリセットルール#6に対応する決定条件を満たしていない、すなわち、リソースユニット#3に含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量に等しくない。したがって、プリセットルール#6下における位置#3の指示識別子は、0である。
図4中の第2のレイヤにおける位置#4に対応するリソースユニットは、リソースユニット#3であり、リソースユニット#3に含まれるサブキャリアの数量は、4×26であり、プリセットルール#6に対応する決定条件を満たしていない、すなわち、リソースユニット#4に含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量に等しくない。したがって、プリセットルール#6下における位置#4の指示識別子は、0である。
すなわち、プリセットルール#6下におけるリソースユニット#3の指示識別子は、00である。
20MHz帯域幅の周波数ドメインリソースについては、図4に示したケースのみが、周波数ドメインリソースの対称中心のどちらかの側上のリソースユニットの割り振りにおいて存在している。したがって、位置#11から位置#14に対応する指示識別子が0である場合には、位置#4に対応する指示識別子は0であり、位置#6に対応するリソースユニット(すなわち、リソースユニット#3)が4×26トーンリソースユニットであると決定することができる。
type-3マッピングルールに基づいて図12に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、001100であり、従来技術におけるビットシーケンスを生成するための方法と比較して、3ビットのオーバーヘッドを使わずに済ますことができる。
それに対応するように、受信端の決定プロセスにおいては、ビットシーケンス中の1番目のビットは、図4中の第1のレイヤにおける位置#7から位置#10における割り当て予定の周波数ドメインリソース内のリソースユニットの割り振りを指示する。
第1の指示識別子は、0である。したがって、受信端は、図4中の第1のレイヤにおける位置#7から位置#10にあるリソースユニット(すなわち、リソースユニット#1およびリソースユニット#2)に含まれるサブキャリアの数量がプリセットルール#5に対応する決定条件を満たしていない、すなわち、位置#7から位置#10にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#5に対応するプリセットサブキャリア数量(すなわち、1×26)とすべて等しくない、と決定し得る。
第2の指示識別子は、0である。したがって、受信端は、図4中の第1のレイヤにおける位置#11から位置#14にあるリソースユニット(すなわち、リソースユニット#3)に含まれるサブキャリアの数量がプリセットルール#5に対応する決定条件を満たしていない、すなわち、位置#11から位置#14にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#5に対応するプリセットサブキャリア数量(すなわち、1×26)に等しくない、と決定し得る。
第3の指示識別子は、1である。したがって、受信端は、図4中の第2のレイヤにおける位置#1にあるリソースユニット(すなわち、リソースユニット#1)に含まれるサブキャリアの数量がプリセットルール#6に対応する決定条件を満たしている、すなわち、位置#1にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量(すなわち、2×26)と等しい、と決定し得る。
したがって、第1の指示識別子および第3の指示識別子を参照して、受信端は、左から1番目のリソースユニット、または、周波数ドメインリソースにおける位置#1にあるリソースユニット(すなわち、リソースユニット#1)のサイズが2×26であると決定することができる。
第4の指示識別子は、1である。したがって、受信端は、図4中の第2のレイヤにおける位置#2にあるリソースユニット(すなわち、リソースユニット#2)に含まれるサブキャリアの数量がプリセットルール#6に対応する決定条件を満たしている、すなわち、位置#2にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量(すなわち、2×26)と等しい、と決定し得る。
したがって、第1の指示識別子および第4の指示識別子を参照して、受信端は、左から2番目のリソースユニット、または、周波数ドメインリソースにおける位置#2にあるリソースユニット(すなわち、リソースユニット#1)のサイズが2×26であると決定することができる。
第5の指示識別子は、0である。したがって、受信端は、図4中の第2のレイヤにおける位置#3にあるリソースユニット(すなわち、リソースユニット#3)に含まれるサブキャリアの数量がプリセットルール#6に対応する決定条件を満たしていない、すなわち、位置#3にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量(すなわち、2×26)に等しくない、と決定し得る。
第6の指示識別子は、0である。したがって、受信端は、図4中の第2のレイヤにおける位置#3にあるリソースユニット(すなわち、リソースユニット#3)に含まれるサブキャリアの数量がプリセットルール#6に対応する決定条件を満たしていない、すなわち、位置#3にあるリソースユニットに含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量(すなわち、2×26)に等しくない、と決定し得る。
したがって、第1の指示識別子、第5の指示識別子、および第6の指示識別子を参照して、受信端は、左から4番目のリソースユニット、または、周波数ドメインリソースにおける位置#3および位置#4にあるリソースユニット(すなわち、リソースユニット#3)のサイズが4×26であると決定することができる。
上述したように、受信端の決定プロセスは、送信端の決定プロセスとは逆のプロセスである。繰り返しを避けるために、以下では送信端の決定プロセスとは逆である受信端の決定プロセスに関する詳細な説明を省略する。
図13は、type-3マッピングルールに基づいた決定プロセスの別の例のツリー図を示している。一例として20MHz帯域幅を有する割り当て予定の周波数ドメインリソースを使用すれば、割り当て予定の周波数ドメインリソースは、左から右の順に、1つの2×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#1'と以降示す)、3つの1×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#2'、リソースユニット#3'、およびリソースユニット#0'と以降示す)、および1つの4×26トーンリソースユニット(理解および識別を容易にするために、リソースユニット#4'と以降示す)を含む。
20MHz帯域幅においては、帯域幅の中心位置に位置する1つの1×26トーンリソースユニット(すなわち、リソースユニット#0')が常に存在しているため、リソースユニットが暗黙的に指示され得ることに留意されたい。したがって、方法100は、主に、リソースユニット#0'を除く任意のリソースユニットに対応する指示識別子を決定することである。繰り返しを避けるために、同一または同様のケースに関する説明は以下では省略する。
まず、図13に示したように、1×26のプリセットサブキャリア数量に対応するプリセットルール(すなわち、プリセットルール#5)が決定され、決定が左から右の順で行われる。
換言すれば、図4中の第1のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
送信端の決定プロセスにおいては、まず、割り当て予定の周波数ドメインリソースの対称中心の左サイド(すなわち、図4中の位置#7から位置#10に対応)上のリソースユニット(すなわち、リソースユニット#1'、リソースユニット#2'、およびリソースユニット#3')のサイズがすべて1×26であるかどうかを決定する。リソースユニット#1'に含まれるサブキャリアの数量が2×26であるため、対称中心の左サイド上に位置するリソースユニットは、プリセットルール#6に対応する決定条件を満たしていない。したがって、プリセットルール#5下における図4中の位置#7から位置#10(または、リソースユニット#1'、リソースユニット#2'、およびリソースユニット#3')の指示識別子は、0である。
その後、割り当て予定の周波数ドメインリソースの対称中心の右サイド(すなわち、図4中の位置#11から位置#14に対応)上のリソースユニット(すなわち、リソースユニット#3')のサイズがすべて1×26であるかどうかを決定する。リソースユニット#3'に含まれるサブキャリアの数量は、4×26であり、プリセットルール#5に対応する決定条件を満たしていないため、プリセットルール#5下における図4中の位置#11から位置#14(または、リソースユニット#3')の指示識別子は、0である。
その後、図13に示したように、2×26のプリセットサブキャリア数量に対応するプリセットルール(すなわち、プリセットルール#6)が決定され、決定が左から右へと行われる。
換言すれば、図4中の第2のレイヤにおけるリソースユニットの割り振りが決定基準として使用され、決定が左から右の順で行われる。
図4中の第2のレイヤにおける位置#1に対応するリソースユニットは、リソースユニット#1'であり、リソースユニット#1'に含まれるサブキャリアの数量は、2×26であり、プリセットルール#6に対応する決定条件を満たしている、すなわち、リソースユニット#1に含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#6下における位置#1(または、リソースユニット#1)の指示識別子は、1である。
図4中の第2のレイヤにおける位置#2に対応するリソースユニットは、リソースユニット#2'およびリソースユニット#3'であり、リソースユニット#2'およびリソースユニット#3'に含まれるサブキャリアの数量は、1×26であり、プリセットルール#6に対応する決定条件を満たしていない、すなわち、リソースユニット#2'およびリソースユニット#3'に含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量に等しくない。したがって、プリセットルール#6下における位置#2(または、リソースユニット#2'およびリソースユニット#3')の指示識別子は、0である。
図4中の第2のレイヤにおける位置#3に対応するリソースユニットは、リソースユニット#3であり、リソースユニット#3に含まれるサブキャリアの数量は、4×26であり、プリセットルール#6に対応する決定条件を満たしていない、すなわち、リソースユニット#3に含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量に等しくない。したがって、プリセットルール#6下における位置#3の指示識別子は、0である。
図4中の第2のレイヤにおける位置#4に対応するリソースユニットは、リソースユニット#3であり、リソースユニット#3に含まれるサブキャリアの数量は、4×26であり、プリセットルール#6に対応する決定条件を満たしていない、すなわち、リソースユニット#4に含まれるサブキャリアの数量は、プリセットルール#6に対応するプリセットサブキャリア数量と等しい。したがって、プリセットルール#6下における位置#4の指示識別子は、0である。
すなわち、プリセットルール#6下におけるリソースユニット#3の指示識別子は、00である。
20MHz帯域幅の周波数ドメインリソースについては、図4に示したケースのみが、周波数ドメインリソースの対称中心のどちらかの側上のリソースユニットの割り振りにおいて存在している。したがって、位置#11から位置#14に対応する指示識別子が0である場合には、位置#4に対応する指示識別子は0であり、位置#6に対応するリソースユニット(すなわち、リソースユニット#3)が4×26トーンリソースユニットであると決定することができる。
type-3マッピングルールに基づいて図13に示した割り当て予定の周波数ドメインリソースのために生成される様々な指示識別子によって形成されるビットシーケンスは、001000であり、従来技術におけるビットシーケンスを生成するための方法と比較して、3ビットのオーバーヘッドを使わずに済ますことができる。
各マッピングルールに基づいて各指示識別子およびビットシーケンスを決定する前述のプロセスは例にすぎず、本発明はそれに限定されないことを理解されたい。例えば、上記においては、左から右の順に決定するプロセスを説明しているが、決定はまた、受信端および送信端が対応する順序を使用することが保証されている限り右から左の順に行われてもよい。
加えて、割り当て予定の周波数ドメインリソースの帯域幅を説明した上記は例にすぎず、本発明はそれに限定されない。前述の3つのタイプのマッピングルールは、例えば、40MHz、80MHz、または160MHzといった、より大きな帯域幅を有する周波数ドメインリソースの割り振りを指示するためにさらに適用可能であり得る。加えて、具体的な決定プロセスは、type-2マッピングルールにおける40MHzまたは80MHzのための決定プロセスと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
前述の3つのタイプのマッピングルールは、例えば、40MHz、80MHz、または160MHzといった、より大きな帯域幅を有する周波数ドメインリソースの割り振りを指示するとともに最小粒度の20MHz(20MHz帯域幅内では、他の方法を指示するために使用してもよい)を指示するためにさらに適用可能であり得る。さらに、具体的な決定プロセスは、type-2マッピングルールにおける40MHzまたは80MHzのための決定プロセスと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
実施形態5
上述したように、前述の実施形態1、2、3、または4では、40MHz、80MHz、および160MHz帯域幅については、同様の方式が、その全体におけるリソースユニットの割り振りを指示することになる。
実施形態5では、40MHz、80MHz、および160MHz帯域幅における各20MHz帯域幅について、前述の実施形態1、2、3、もしくは4の方法、またはその可能な組合せが指示のために繰り返し使用され得る点で異なる。換言すれば、より大きな帯域幅については、帯域幅のリソースユニットの割り振りを指示するためのビットシーケンスは、各基本帯域幅におけるリソースユニットの割り振り(最小単位の帯域幅の割り振り、例えば、20MHz)を指示するビットシーケンスと、2つの隣接基本帯域幅が1つの割り当て予定のリソースユニットに配分されているかどうかを指示するアグリゲーション指示ビットとを含む。
例えば、割り当て予定の周波数ドメインリソースが40MHzである場合には、20MHz帯域幅指示方法が2回繰り返して使用される、すなわち、2ビットシーケンスが、前述の方法に従って第1の20MHz帯域幅および第2の20MHz帯域幅におけるリソースユニットの割り振りをそれぞれ指示するために含まれる。別の例では、割り当て予定の周波数ドメインリソースが80MHzである場合には、20MHz帯域幅指示方法が4回繰り返して使用される、すなわち、4つのセグメントのシーケンスが、前述の方法に従って第1の20MHz帯域幅、第2の20MHz帯域幅、第3の20MHz帯域幅、および第4の20MHz帯域幅におけるリソースユニットの割り振りをそれぞれ指示するために含まれる。
特定の例においては、各20Mの帯域幅を指示する方法では、type-0ビットが、20MHz帯域幅に対応する最大のリソースユニットが実際の割り振りにおいて存在していること、すなわち、242トーンリソースユニットが割り振られていることを指示している場合には、各20Mの帯域幅を指示するためのビットシーケンスは、アグリゲーションを行うかどうかを指示するための1ビットをさらに含み、このビットは特に、隣接する20Mが1つのリソースユニットに配分され得るかどうかを指示するためのものである。例えば、割り当て予定の周波数ドメインリソースが40MHzである場合には、2つの20MHz帯域幅をそれぞれ指示するための2つのセグメントにあるtype-0ビットが両方、242トーンリソースユニットが割り振られていることを指示し、アグリゲーションビットが両方、隣接する20Mが1つのリソースユニットに配分され得ることを指示している場合には、2つの20MHzが484トーンリソースユニットに配分されていることを指示する。別の例では、割り当て予定の周波数ドメインリソースが80MHzであるならば、4つのセグメントのビットのうちの、最後の2つの20MHz帯域幅を指示するための最後の2つのセグメントにあるtype-0ビットが両方、242トーンリソースユニットが割り振られていることを指示し、アグリゲーションビットが両方、隣接する20Mが1つのリソースユニットに配分され得ることを指示している場合には、最後の2つの20MHzが484トーンリソースユニットに配分されていることを指示し、4つの20MHz帯域幅を指示するための4つのセグメントにあるtype-0ビットがすべて、242トーンリソースユニットが割り振られていることを指示し、アグリゲーションビットがすべて、隣接する20Mが1つのリソースユニットに配分され得ることを指示している場合には、4つの20MHzが996トーンリソースユニットに配分されていることを指示する。
より具体的には、実施形態5においては、具体的な決定プロセスはまた、type-0ビット、type-1ビット、type-2ビット、またはtype-3ビットなどといった対応するビットを生成するための前述の決定方法の各々を参照されたい。
例えば、図10に示した割り当て予定の40MHz帯域幅については、20MHz指示方法(図9に対応する実施形態の方法)を、指示するために2回繰り返して使用してもよい。プリセットルール#22下におけるオプション指示識別子を含んでいる場合には、type-2マッピングルールに基づいて第1の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、00111である。type-2マッピングルールに基づいて第2の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは1である。ある20MHz帯域幅におけるプリセットルール#22下におけるオプション指示識別子が1である場合には、20MHz帯域幅を、242トーンリソースユニットに分割すること、または、隣接する20MHzを用いてより大きなリソースユニットに分割することを指示する。type-2マッピングルールに基づいて20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、アグリゲーションビットをさらに含み、このビットは、20MHz帯域幅を、242トーンリソースユニットに分割するかどうか、または、隣接する20MHzを用いてより大きなリソースユニットに分割するかどうかを指示するものである。第2の20MHz帯域幅が隣接する20MHzを用いてより大きなリソースユニットに分割されていないため、アグリゲーションビットは0である。したがって、type-2マッピングルールに基づいて第2の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、10である。20MHzの隣接性は、左から右に、2つの連続した20MHz、または4つの連続した20MHz、または8つの連続した20MHzを指し、これらは、484トーンリソースユニット、または996トーンリソースユニット、または996x2トーンリソースユニットにまとめて分割される。
したがって、type-2マッピングルールに基づいて図10に示した割り当て予定の40MHz帯域幅のために生成される様々な指示識別子によって形成されるビットシーケンスは、0011110である。オプションとして、デフォルトリソースユニットの位置が利用可能であるかどうかを指示する2ビットをさらに含み得る。
2つの連続した20MHzのうちの1つの20MHzを、242トーンリソースユニットに分割していない、または、隣接する20MHzを用いてより大きなリソースユニットに分割するが、残りの1つを、242トーンリソースユニットに分割する、または、隣接する20MHzを用いてより大きなリソースユニットに分割する場合には、type-1マッピングルールに基づいて第2の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、アグリゲーションビットを含まなくてもよい。したがって、type-2マッピングルールに基づいて図10に示した割り当て予定の40MHz帯域幅のために生成される様々な指示識別子によって形成されるビットシーケンスも、001111であり得る。
別の例では、図11に示した割り当て予定の80MHz帯域幅については、20MHz指示方法(図9に対応する実施形態の方法)が4回繰り返して使用され得る。プリセットルール#22下におけるオプション指示識別子を含んでいる場合には、type-2マッピングルールに基づいて第1の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、011である。type-2マッピングルールに基づいて第2の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは1である。type-2マッピングルールに基づいて第3の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは1である。type-2マッピングルールに基づいて第4の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは1である。ある20MHz帯域幅におけるプリセットルール#22下におけるオプション指示識別子が1である場合には、20MHz帯域幅を、242トーンリソースユニットに分割すること、または、隣接する20MHzを用いてより大きなリソースユニットに分割することを指示する。type-2マッピングルールに基づいて20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、アグリゲーションビットをさらに含み、このビットは、20MHz帯域幅を、242トーンリソースユニットに分割するかどうか、または、隣接する20MHzを用いてより大きなリソースユニットに分割するかどうかを指示するものである。第2の20MHz帯域幅が隣接する20MHzを用いてより大きなリソースユニットに分割されていないため、アグリゲーションビットは0である。したがって、type-2マッピングルールに基づいて第2の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、10である。第3の20MHz帯域幅が隣接する20MHzを用いてより大きなリソースユニットに分割されているため、アグリゲーションビットは1である。したがって、type-2マッピングルールに基づいて第3の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、11である。第4の20MHz帯域幅が隣接する20MHzを用いてより大きなリソースユニットに分割されているため、アグリゲーションビットは1である。したがって、type-2マッピングルールに基づいて第4の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、11である。20MHzの隣接性は、左から右に、2つの連続した20MHz、または4つの連続した20MHz、または8つの連続した20MHzを指し、これらは、484トーンリソースユニット、または996トーンリソースユニット、または996x2トーンリソースユニットにまとめて分割される。
隣接する20MHzを指示する1つのアグリゲーションビットは、左から右に2つの連続した20MHzが484トーンリソースユニットを構成し得ることを指示する。隣接する20MHzを指示する2つのアグリゲーションビットは、左から右に4つの連続した20MHzが996トーンリソースユニットを構成し得ることを指示する。隣接する20MHzを指示する3つのアグリゲーションビットは、左から右に4つの連続した20MHzが996x2トーンリソースユニットを構成し得ることを指示する。
したがって、type-2マッピングルールに基づいて図11に示した割り当て予定の80MHz帯域幅のために生成される様々な指示識別子によって形成されるビットシーケンスは、011101111である。オプションとして、5つのデフォルトリソースユニットの位置が利用可能であるかどうかを指示する5ビットをさらに含む。
2つの連続した20MHzのうちの1つの20MHzを、242トーンリソースユニットに分割していない、または、隣接する20MHzを用いてより大きなリソースユニットに分割するが、残りの1つを、242トーンリソースユニットに分割する、または、隣接する20MHzを用いてより大きなリソースユニットに分割する場合には、type-2マッピングルールに基づいて第2の20MHzのために生成される様々な指示識別子によって形成されるビットシーケンスは、アグリゲーションビットを含まなくてもよい。したがって、type-2マッピングルールに基づいて図10に示した割り当て予定の40MHz帯域幅のために生成される様々な指示識別子によって形成されるビットシーケンスも、01111111であり得る。
実施形態6
上述したように、前述の実施形態1、2、3、4、または5においては、20MHz、40MHz、80MHz、および160MHz帯域幅については、ビットシーケンスによって指示されるリソースユニットが、OFDMAにおけるシングルユーザ(Sigle User、SU)伝送のために使用され得る、または、OFDMAにおけるMU-MIMO伝送のために使用され得る、または、MU-MIMO伝送のために使用され得る。前者は、SU伝送として扱ってもよい。後者の2つは両方、MU伝送として扱ってもよい。
オプションとして、リソーススケジューリング情報は、リソーススケジューリング情報によって指示されるリソースユニットにおいて通信するステーションの数に関連する情報を指示する情報をさらに含む。2ビットまたは3ビットは、SUまたはMU-MIMO通信を行うステーションの数を指示するために使用される。例えば、"00"は、ステーションの数が1であることを指示する、すなわち、リソースユニットは、SU通信ために使用される。別の例では、"11"は、ステーションの数が4であることを指示し、リソースユニットは、MU通信のために使用されている。
通信プロトコルは、MU-MIMOを基本的にサポートする最小のサイズ、例えば、2×26トーンまたは4×26トーン、のリソースユニットを事前に定義し得る。ある例においては、4×26トーンリソースユニットは、MU-MIMO伝送が可能な最小の基本リソースユニットである。前記例においては、4×26サイズのリソースユニットは、MU-MIMO伝送において最大の4人のユーザをサポートし得るし、242サイズまたはより大きなサイズのリソースユニットは、MU-MIMO伝送において最大の8人のユーザをサポートし得る。したがって、MU-MIMOのための最小のサイズより小さい割り振りにおけるリソースユニットについては、SU伝送モードがデフォルトで実行され、リソースユニットにおいて通信を行うステーションの数を指示するためにビットは必要としない。
図11に示した80MHzのリソースユニットの割り振りの例においては、周波数ドメインリソースユニット#1''および周波数ドメインリソースユニット#3''は、MU-MIMO通信のために使用され、3つステーションおよび7つステーションにそれぞれ割り振られる。ビットシーケンスは、type-2マッピングルールに基づいて生成される指示識別子、すなわち、011101111を含む、ここで、第1の20MHzに対応するビットシーケンスは、011であり、第2の20MHzに対応するビットシーケンスは、10であり、第3の20MHzに対応するビットシーケンスは、11であり、第4の20MHzに対応するビットシーケンスは、11である。第1の20MHzリソースユニット内のステーションの数を指示するビットシーケンスは、1000であり、第2の20MHzリソースユニット内のステーションの数を指示するビットシーケンスは、111であり、第3の20MHzリソースユニット内のステーションの数を指示するビットシーケンスは、000であり、第4の20MHzリソースユニット内のステーションの数を指示するビットシーケンスは、000である。
実施形態7
前述の実施形態に基づいて、特定の例においては、少なくとも8ビットの長さを有するリソース割り振りのビットシーケンスを、提供しており、少なくとも実際に割り振られたリソースユニットと、リソースユニット上で伝送を行うステーションの数量に関連する(MU-MIMO伝送に関与するステーションの数量を特に指示する)情報とを指示するものである。特に、少なくとも8つの指示ビット、実際に割り振られるとともに指示ビットによって指示されるリソースユニット、およびリソースユニット上で伝送を行うステーションの数量は、テーブルを使用して簡単に表され得る。
無線ローカルエリアネットワークにおいては、このテーブルは、APおよび/またはSTAがこのテーブルに従ってリソース割り振りのビットシーケンスを生成またはパースし得るように、APおよび/またはSTA上に記憶されていてもよい。テーブルクエリ方式を使用しない場合には、前述のtype-1マッピングルール、type-2マッピングルール、またはtype-3マッピングルールも、リソース割り振りビットシーケンスを生成またはパースするものであり得る。
以下の表1に示した例においては、8ビットは、総計256個のリソース割り振りビットシーケンスを指示する。表1中の8ビットのリソース割り振りビットシーケンスは、実施形態4におけるtype-0ビット、実施形態2におけるtype-2ビット、実施形態6におけるリソースユニット上で伝送を行うステーションの数量に関連する情報を指示するビット、およびいくつかの予約(reserved)ビットを含み得る。テーブルストレージ方式を使用しない場合には、図23a-1、図23a-2、および図23bに示した特定の実施様態も、表1に示したような、実際に割り振られたリソースユニットに対応するリソース割り振りビットシーケンスおよびリソースユニット上で伝送を行うステーションの数量を取得するためのものであり得る。
表1は、基本帯域幅についてのリソース割り振り(最小単位の帯域幅割り振り、例えば、20MHz)のビットシーケンス、実際に割り振られるとともにリソース割り振りビットシーケンスによって指示されるリソースユニット、およびリソースユニット上で伝送を行うステーションの数量を指示している。実施形態5を参照すれば、40MHz、80MHz、および160MHz帯域幅における各20MHz帯域幅については、前述の実施形態1、2、3、もしくは4の方法、またはその可能な組合せが指示のために繰り返し使用され得る。換言すれば、より大きな帯域幅については、表1またはそのバリエーションは繰り返しすべての帯域幅のためのリソース割り振りビットシーケンスを取得されることになり得る。その詳細を本明細書では再び説明しない。
表1は、「リソース割り振りビットシーケンス」および対応する「実際に割り振られたリソースユニット」をリストアップしている。表1では、26は、1×26リソースユニットを指示し、52は、2×26リソースユニットを指示し、106は、4×26リソースユニットを指示し、242(n)は、242リソースユニットを指示し、リソース上で伝送を行うステーションの数量がnであり、nが1より大きい場合には、MU-MIMO伝送は、リソースユニット上で行われ、484(n)は、2×242リソースユニットを指示し、リソース上で伝送を行うステーションの数量がnであり、996(n)は、996リソースユニットに対応し、リソース上で伝送を行うステーションの数量がnであり、2×996(n)は、2×996リソースユニットに対応し、リソース上で伝送を行うステーションの数量がnである。
本例においては、MU-MIMO伝送が可能な最小のリソースユニットが106リソースユニットに制限されている。加えて、20MHzスペクトルリソースから実際に割り振られたリソースユニットが2つの106リソースユニットを含む場合には、106リソースユニット上で伝送を行うステーションの最大数量は、4である。他のケースにおいては、MU-MIMO伝送のためのリソースユニット上での伝送を行うステーションの最大数量は、8である。
特に、表1中のすべての8ビットのリソース割り振りビットシーケンス中の1番目のビットは、実施形態4におけるtype-0ビットであり、プロトコルにおける20MHzに対応する割り振られる可能性がある最大のリソースユニットが実際に割り振られるかどうか、すなわち、ステーションに実際に割り振られたおよび割り振り予定の現在のリソースユニットが242リソースユニットであるかどうかを指示する。現在の帯域幅が20MHzである場合には、type-0ビットが、実際に割り振られたリソースユニットが242リソースユニットより小さいかまたは242リソースユニットと等しいかを区別するものであり得ることを当業者は理解されよう。現在の帯域幅がより大きな帯域幅(例えば、40MHz、80MHz、または160MHz)である場合には、type-0ビットは、実際に割り振られたリソースユニットが242リソースユニットより小さいかまたは242リソースユニット以上であるかを区別するものであり得る。
加えて、シーケンス番号193からシーケンス番号256までの8ビットのリソース割り振りビットシーケンス中の3番目のビットおよび4番目のビットも、実施形態4におけるtype-0ビットである、ここで、3番目のビットは、実際に割り振られたリソースユニットが996リソースユニットであるかどうかを指示する。以下のテーブルは、特定の例である。3番目のビット"0"が、実際に割り振られたリソースユニットが996リソースユニットではないことを指示している場合には、4番目のビットは、実際に割り振られたリソースユニットが2×242リソースユニットであるかどうかを指示する。したがって、"10"は、実際に割り振られたリソースユニットが996リソースユニットであることを指示し、"01"は、実際に割り振られたリソースユニットが2×242リソースユニットであることを指示し、"00"は、実際に割り振られたリソースユニットが242リソースユニットであることを指示し、別の特別なビットシーケンス"11"は、実際に割り振られたリソースユニットが2×996リソースユニットであることを指示する。前記2ビットはまた、以下の小さなテーブルを使用して簡易に表され得る。3番目のビットおよび4番目のビットの位置が変更されている、または、ビットの値設定方式が変更されている(0および1の意味が入れ替えられている)場合には、テーブルの対応するバリエーションが存在し得るが、テーブルのバリエーションもすべて本実施形態の範囲に含まれることは理解されよう。
表1中のシーケンス番号1からシーケンス番号32までのビットシーケンス中の第2から7番目のビットは、実施形態2におけるtype-2ビットであり、図9に示したようなツリー図の原理に従って、実際に割り振られたリソースユニットを指示するためのビットが使用され得る、ここで、8番目のビットは、予約ビットである。
加えて、表1中のシーケンス番号33からシーケンス番号96までのビットシーケンス中の第2から5番目のビットも、実施形態2におけるtype-2ビットである。シーケンス番号97からシーケンス番号128までのビットシーケンス中の2番目のビットおよび3番目のビットも、実施形態2におけるtype-2ビットである。シーケンス番号129からシーケンス番号192までのビットシーケンスは、予約シーケンスである。
表1中のシーケンス番号33からシーケンス番号96までの8ビットのリソース割り振りビットシーケンス中の第6から8番目のビットは、実施形態6におけるリソースユニット上で伝送を行うステーションの数量を指示するためのビットである。シーケンス番号97からシーケンス番号128までのビットシーケンス中の第4から7番目のビットは、実施形態6におけるリソースユニット上で伝送を行うステーションの数量を指示するためのビットである、ここで、最初の2ビットは、第1の106リソースユニット上で伝送を行うステーションの数量を指示し、最後の2ビットは、第2の106リソースユニット上で伝送を行うステーションの数量を指示する。シーケンス番号193からシーケンス番号256までのビットシーケンス中の第5から7番目のビットはまた、実施形態6におけるリソースユニット上で伝送を行うステーションの数量を指示するためのビットである。
加えて、予約ビットは、対応するビットシーケンスが予約されているか未使用であるかを指示するものである。表1中のシーケンス番号1からシーケンス番号32までのビットシーケンスにおいては、8番目のビットは、予約ビットであり、シーケンス番号1からシーケンス番号16までのリソース割り振りシーケンス中の最初の7ビットは、シーケンス番号17からシーケンス番号32までのリソース割り振りシーケンス中の最初の7ビットにそれぞれ一致しており、8番目のビットは、対応するビットシーケンスが予約されているかどうかを指示するものである。シーケンス番号97からシーケンス番号128までのビットシーケンスにおいては、8番目のビットは、予約ビットであり、シーケンス番号97からシーケンス番号112までのリソース割り振りシーケンス中の最初の7ビットは、シーケンス番号113からシーケンス番号128までのリソース割り振りシーケンス中の最初の7ビットにそれぞれ一致している。シーケンス番号129からシーケンス番号256までのビットシーケンスにおいては、2番目のビットは、予約ビットであり、したがって、シーケンス番号129からシーケンス番号192までのリソース割り振りシーケンス中の他の7ビットは、シーケンス番号193からシーケンス番号256までのリソース割り振りシーケンス中の他の7ビットにそれぞれ一致している。シーケンス番号193からシーケンス番号208までの8ビットのリソース割り振りビットシーケンスにおいては、8番目のビットは、予約ビットであり、したがって、シーケンス番号193からシーケンス番号200までのビットシーケンス中の他の7ビットは、シーケンス番号201からシーケンス番号208までのビットシーケンス中の他の7ビットにそれぞれ一致している。シーケンス番号209からシーケンス番号224までの8ビットのリソース割り振りビットシーケンスにおいては、8番目のビットは、予約ビットであり、したがって、シーケンス番号209からシーケンス番号216までのビットシーケンス中の他の7ビットは、シーケンス番号217からシーケンス番号224までのビットシーケンス中の他の7ビットにそれぞれ一致している。シーケンス番号225からシーケンス番号240までの8ビットのリソース割り振りビットシーケンスにおいては、8番目のビットは、予約ビットであり、したがって、シーケンス番号225からシーケンス番号232までのビットシーケンス中の他の7ビットは、シーケンス番号233からシーケンス番号240までのビットシーケンス中の他の7ビットにそれぞれ一致している。シーケンス番号241からシーケンス番号256までの8ビットのリソース割り振りビットシーケンスにおいては、8番目のビットは、予約ビットであり、したがって、シーケンス番号241からシーケンス番号248までのビットシーケンス中の他の7ビットは、シーケンス番号249からシーケンス番号256までのビットシーケンス中の他の7ビットにそれぞれ一致している。
新規テーブルを形成するように、前述の複数のタイプのビットが異なる値設定方式(0および1の意味が入れ替えられているなど)を有し得るし、ビットの位置も変更され得ることは理解されよう、ただし、ビットの機能および技術的含意は同一であり、本発明の本実施形態においてさらに説明はしていない。例えば、表1中のtype-0ビットは、シーケンスの最終位置に配置されてもよい。別の例では、表1中のtype-2ビットのうちのいくつかのビットの位置を変更してもよい。加えて、リソースユニット上で通信を行うステーションの数を指示する、表1中のリソース割り振りを指示するビットシーケンスに含まれる、指示ビットは、他の機能、例えば、リソース割り振りシーケンスが位置する、20MHzチャネルにおけるHE-SIGBフィールド内のステーション情報のためのユーザフィールドの数を指示する機能を有し得る、ここで、ステーション情報のためのユーザフィールドは、ビットシーケンスによって指示されるリソースユニット上で通信を行うステーションに関する情報(例えば、図17に示したステーション情報のためのユーザフィールドの数)を含む。242より大きいサイズのリソースユニットについては、各20MHzチャネルのためのリソース割り振りのビットシーケンス中のこのタイプのビットは、対応する20MHzチャネル上で、HE-SIGBフィールド内のステーション情報のためのユーザフィールドの数を指示する、ここで、ステーション情報のための各ユーザフィールドは、ビットシーケンスによって指示されるこのリソースユニット上で通信を行う各ステーションに関する情報を含む。ある20MHzにおけるHE-SIGB内のステーション情報のためのユーザフィールドの数は0であってもよく、各20MHzにおけるHE-SIGBがステーション情報のためのユーザフィールドとほぼ等しい数を含むことができるという利点をもたらす。例えば、シーケンス番号217を有するリソース割り振りを指示するシーケンスは、第1の20MHzのために484(0)を指示するために使用される、ここで、484(0)は、この第1の20MHzおよび第2の隣接する20MHzが484トーンリソースユニットとして実際に割り振られ、この第1の20MHz(242)におけるHE-SIGBフィールド内のステーション情報のためのユーザフィールドの数が0であることを指示し、ステーション情報のためのユーザフィールドは、484トーンリソースユニット上で通信を行うステーションに関する情報を含む。別の例では、シーケンス番号233を有するリソース割り振りを指示するシーケンスは、996(0)を指示するものである。
例えば、HE-SIGBフィールドは、異なる20M個のチャネルにおいてそれぞれ搬送される、HE-SIGB1およびHE-SIGB2を含み、特定のHE-SIGBフィールドに含まれる、ステーション情報のためのユーザフィールドは、対応する帯域幅(チャネル)において受信または伝送を行うステーションに関する情報を含む。分かりやすい例としては、80MHz帯域幅においては、HE-SIGB1は、第1および第3の20MHzチャネル上で通信を行うステーションに関する、ステーション情報のためのユーザフィールドを含み、HE-SIGB2は、第2および第4の20MHzチャネル上で通信を行うステーションに関する、ステーション情報のためのユーザフィールドを含む。ある例においては、80MHz帯域幅内では、MU-MIMOが第1の40MHzにおいて行われ、合計で4つステーション(すなわち、第1の2つの20MHzチャネルにおいて合計で4つステーション)が通信に関与し、第3の20MHzチャネルが9つの26リソースユニットとして割り振られ、9つのステーションがOFDMA伝送に関与し、第4の20MHzチャネルが106リソースユニット、26リソースユニット、および106リソースユニットとして割り振られ、シングルステーション伝送がどちらかの106リソースユニット上で行われる、すなわち、3つのステーションがOFDMA伝送に関与する。2つのHE-SIGB内のユーザフィールドの数をほぼ同一にするために、第1の20MHzのビットシーケンスは、シーケンス番号217を有する484(0)を指示するシーケンス「11,01,000,1」であり、第2の20MHzのビットシーケンスは、シーケンス番号212を有する484(4)を指示するシーケンス「11,01,011,0」であり、第3の20MHzのビットシーケンスは、シーケンス番号1を有するシーケンス「000,0000,0」であり、第4の20MHzのビットシーケンスは、シーケンス番号97を有するシーケンス「011,0000,0」である。したがって、HE-SIGB1は、第1の20MHzチャネル上で通信を行うステーションに関する情報を含む、0個のステーション情報のためのユーザフィールドと、第3の20MHzチャネル上で通信を行うステーションに関する情報を含む、9つのステーション情報のためのユーザフィールドとを含む。HE-SIGB2は、第2の20MHzチャネル上で通信を行うステーションに関する情報を含む、4つステーション情報のためのユーザフィールドと、第4の20MHzチャネル上で通信を行うステーションに関する情報を含む、3つステーション情報のためのユーザフィールドとを含む。
その上さらに、表1中のいくつかの予約ビットは、割り振られるリソースユニットが帯域幅の中心に位置する26トーンリソースユニットを含んでいる場合に、中心の26トーンリソースユニットが使用予定であるかどうか(例えば、ステーションに割り当てられるかどうか)を指示するものであり得る。例えば、実際に割り振られるとともにシーケンス番号17から32までのリソース割り振りビットシーケンスによって指示されるリソースユニットは、シーケンス番号1から16までのリソース割り振りビットシーケンスによって指示されるものとそれぞれ一致している。しかしながら、シーケンス番号1から16までのビットシーケンスによってそれぞれ指示される中心の26トーンリソースユニットは、ステーションに割り当てられるが、シーケンス番号17から32までのビットシーケンスによってそれぞれ指示される中心の26トーンリソースユニットは、ステーションに割り当てられない。
表1では、実際に割り振られるとともにシーケンス番号241からシーケンス番号248までのリソース割り振りビットシーケンスによって指示されるリソースユニットは、現在の利用可能な最大帯域幅160Mに対応するリソースユニットである。しかしながら、スペクトルリソースの割り振りは、HE-SIGAフィールドによって指示されてもよい。この場合には、HE-SIGBに位置するリソース割り振りビットシーケンスは、もはや如何なる指示も与えなくてもよい。したがって、表1中のシーケンス番号241からシーケンス番号248までのリソース割り振りビットシーケンスはまた、予約シーケンスであり得る。
表3は、表1のバリエーションの例を指示している。例えば、106以上である各リソースユニット上で伝送を行う最大数量の8つのステーションをサポートするために、表1中のシーケンス番号129から192までのリソース割り振りビットシーケンスにおいては、最初の2ビットは、20MHzから実際に割り振られた、106リソースユニット、26リソースユニット、および106リソースユニットを指示するものであり、最後の6ビットのうちの3ビットのどれもが、それぞれ、106リソースユニット上で伝送を行うステーションの数量を指示するものである。しかしながら、表1中の20MHzから実際に割り振られた、106リソースユニット、26リソースユニット、および106リソースユニットを指示する、リソース割り振りビットシーケンス(シーケンス番号97から112)は表3中の予約シーケンスに変更されるが、実際に割り振られたリソースユニットを指示する他のリソース割り振りビットシーケンスの意味は変化しない。表1について記載した特別なまたは広範なケースを表3においても使用してもよいことは理解されよう。
特に、表1または表3などといったそのバリエーションは、APまたはSTA上に直接記憶され得る。しかしながら、上述したように、前述の実施様態はまた、シーケンスの生成またはパースのために使用され得る。図23a-1、図23a-2、および図23b内のフローチャートはまた、生成またはパースのために使用され、表1中の8ビットのリソース割り振りのビットシーケンスおよび実際に割り振られるとともに前記ビットによって指示されるリソースユニットと一致する結果を取得し得る。リソース割り振りビットシーケンスの生成中では、ビット(例えば、表1中の前述の1番目のビット、2番目のビット、および3番目のビットの指示機能)に関する所定のルールに従って、対応する指示値を取得する。それに対応するように、リソース割り振りビットシーケンスのパース中では、ビットをパースするたびに、現時点割り振られているリソースユニットの特定の状態を知る。その詳細を本明細書では再び説明しない。
図23a-1、図23a-2、および図23bにおいては、26は、1×26リソースユニットを指示し、52は、2×26リソースユニットを指示し、106は、4×26リソースユニットを指示し、242は、242リソースユニットを指示し、484は、2×242リソースユニットを指示し、996は、996リソースユニットに対応し、2×996は、2×996リソースユニットに対応する。加えて、周波数ドメインリソースを242より小さいリソースユニットに実際に分割する場合は、デフォルトの真ん中の位置に含まれる26リソースユニットは、フローチャートに反映されていない。実際に割り振られたリソースユニットの位置は、図23a-1、図23a-2、および図23bにおいて左から右に表示されているが、本発明の本実施形態はそれらに限定されない。リソースユニットの位置はまた、左から右に表示されてもよく、影響を受けるものはビットシーケンスの位置のみであるが、ビットの実際の機能は影響されない。図23b中のフローチャートは、106より小さく、"xx"が図23a-1および図23a-2中の3つの灰色ボックス内に生じている場合のさらなる分割によって取得される、リソースユニットをどのように指示するかさらに説明している、ここで、第3の灰色ボックス内に4つの"x"が存在しており、図23b中のフローチャートは、2つの"x"ごとに、どのように真ん中の26リソースユニットおよび20MHzにおける双方のサイド上の周波数ドメインリソースを106未満のリソースユニットに分割するかをそれぞれ指示するために使用される。最大帯域幅160MHzに対応する2×996リソースユニット(2×996リソースユニットとも表す)がHE-SIGAフィールドにおいて指示されていない場合には、図23a-1および図23a-2中の「11,11,yyy,b'→2×996リソースユニット」は、2×996リソースユニットを指示する。最大帯域幅160MHzに対応する2×996リソースユニット(2×996リソースユニットとも表す)がHE-SIGAフィールドにおいて指示されている場合には、図23a-1および図23a-2中の「11,11,yyy,b'→2×996リソースユニット」はまた、予約シーケンスとして使用され得る。
図23a-1、図23a-2、および図23bにおける前述のフローチャートは例にすぎないことは理解されよう。リソース割り振りシーケンス中の各ビットの位置または第1の識別子と各ビットの第2の識別子とが異なる場合には、フローチャートにおいて決定する対応する値もそれに対応するように変化する。このことは、テーブルのバリエーションと同様である。
本発明の本実施形態に基づいて、表3中の8ビットのリソース割り振りのビットシーケンスおよび実際に割り振られるとともに前記ビットによって指示されるリソースユニットについては、図24A、図24B、および図23b中のフローチャートはまた、リソース割り振りビットシーケンスを生成するものまたはリソース割り振りビットシーケンスをパースするものであり得る。他は、表1中のフローチャートと同一である。
表1および表3は例にすぎず、テーブルの内容は本明細書において説明した各実施形態でカバーされていることに留意されたい。例えば、要約した8ビットリソース割り振りシーケンスを本明細書のスライド11(Appendix 2)のページに記載しており、スライド11は、20MHz基本帯域幅から実際に割り振られたリソースユニットの4つのケース(すなわち1. 242またはより大きなリソースユニット、2. 2つの106リソースユニットを含む、3. 1つの106リソースユニットのみを含む、そして、4. 106リソースユニットを含まないが、それでも242リソースユニットより小さい)を指示するための8ビットリソース割り振りシーケンスに含まれるビットのタイプをリストアップしており、「RA within 20MHz」が1つのtype-0ビットおよび異なる数量のtype-2ビットを含み、「Num of STAs」が実施形態6におけるリソースユニット上で伝送を行うステーションの数量を指示するビットであることを記載している。しかしながら、中心の26リソースユニット(Use Central 26-RU)およびスライド11中のアグリゲーションビット(Aggregate)を使用するかどうかを指示するビットは、表1および表3にリストアップされていない。表1および表3は、実施形態1から6における指示ビットおよびスライド11中の要約のさらなる表形式の改良版であるが、本実施形態の本実施形態は表1および表3に限定されない。
オプションとして、リソーススケジューリング情報は、複数のスケジューリング済みの受信端の識別子をさらに含み、受信端の識別子は、実際の割り振りにおけるリソースユニットが複数の受信端に割り当てられていることを指示するものである。
オプションとして、リソーススケジューリング情報は、以下のことを含む。
リソーススケジューリング情報は、複数のスケジューリング済みの受信端のスケジューリング順序を指示する、第4の指示情報をさらに含む、ここで、第1の受信端のスケジューリング順序は、割り当て予定の周波数ドメインリソースにおける、第1の受信端に割り振られる割り当て予定のリソースユニットの位置に対応する。
例えば、送信端は、ビットシーケンスまたはビットマップ(ビットマップ)を使用してシステム内の各受信端に以下の情報を通知し得る。
A. 現在の周波数ドメインリソース(すなわち、割り当て予定の周波数ドメインリソース)のコンポーネント、すなわち、割り当て予定の周波数ドメインリソースにおいて、各リソースユニットによって含まれるサブキャリアの数量すなわち含まれている各リソースユニットのサイズ
B. 割り当て予定の周波数ドメインリソースにおける各リソースユニットの位置
さらに、送信端は、ユーザグループ情報(すなわち、第4の指示情報の例)、または、複数の受信端の識別子を含むステーション識別子リスト(STA IDリスト)を使用して、システム内の各受信端がスケジューリングされているかどうか、およびスケジューリング済みのユーザにおける位置を通知し得る。
したがって、受信端は、前述の情報に基づいて、受信端に送信端によって割り振られるリソースユニットを決定し得るし、リソースユニットを使用してデータを受信または送信する。
すなわち、ビットシーケンスを生成した後に、送信端は、ビットシーケンスを含むリソース割り振り指示情報を各受信端デバイスに送信し得る。したがって、受信端デバイスは、リソース割り振り指示情報に基づいて、受信端デバイスに送信端によって割り当てられる周波数ドメインリソースを決定し、割り当てられた周波数ドメインリソースを使用してデータまたはシグナリングを送信することができる。
リソース割り振り指示情報は、現在の帯域幅における周波数ドメインリソース割り振りを主に果たす。リソース割り振り指示情報を受信した後に、受信端は、前述のビットシーケンスを使用して、現在の伝送のリソース割り振りモードまたはサイズおよび割り当て予定の周波数ドメインリソースに含まれるリソースユニットの位置を知り得る。
その後、リソーススケジューリング情報内のSTA IDリスト部分を読み出すことによって、受信端は、その受信端自身がスケジューリングされているかどうか、および、どのスケジューリング済みのユーザまたはユーザグループにそれが属しているか(どのスケジューリング済みのユーザまたはユーザグループか)を知る。2つの部分の内容(リソース割り振り指示情報およびSTA IDリスト、すなわち、リソーススケジューリング情報の例)を参照して、受信端は、対応するスケジューリングされた位置においてデータを受信または送信し得る。
例えば、一例として図9に示した割り当て予定の周波数ドメインリソースを使用すれば、割り当て予定の周波数ドメインリソースは、左から右の順に、リソースユニット#1、リソースユニット#2、リソースユニット#0、およびリソースユニット#3を含む。
4つのリソースユニットが、4つの受信端(理解および識別を容易にするために、STA1、STA2、STA3、およびSTA4と以降示す)に割り振られており、STA IDリスト中のSTAの数量は、送信端(例えば、AP)によって割り振られる利用可能なリソースユニットの総数に等しく、STA IDリスト中のSTAの配置順序は、STA1、STA2、STA3、およびSTA4である。
図9に示した割り当て予定の周波数ドメインリソースのための取得したビットシーケンスは、"0111"である。ビットシーケンスおよびSTA IDリストをパースすることによって、受信端は、受信端にAPによって割り振られるリソースを知る。
すなわち、STA1は、STA IDリストにおいて1番目のものであるため、STA1は、割り振られるリソースは、割り当て予定の周波数ドメインリソースにおける1番目のリソースユニット、すなわち、リソースユニット#1であると決定することができる。
同様に、STA2は、STA IDリストにおいて2番目のものであるため、STA2は、割り振られるリソースは、割り当て予定の周波数ドメインリソースにおける2番目のリソースユニット、すなわち、リソースユニット#2であると決定することができ、STA3は、STA IDリストにおいて3番目のものであるため、STA3は、割り振られるリソースは、割り当て予定の周波数ドメインリソースにおける3番目のリソースユニット、すなわち、リソースユニット#0であると決定することができ、STA4は、STA IDリストにおいて4番目のものであるため、STA4は、割り振られるリソースは、割り当て予定の周波数ドメインリソースにおける4番目のリソースユニット、すなわち、リソースユニット#3であると決定することができる。
ビットシーケンスの前述のリソース指示情報およびSTA IDリストに基づいて行われるリソーススケジューリングの方式を説明した上記は例にすぎず、本発明はそれに限定されないことを理解されたい。
例えば、STAが固定的に不変であるシナリオにおいては、STAの順序が事前に設定されていてもよい。したがって、APは、リソース指示情報を使用して割り当て予定の周波数ドメインリソースにおける各リソースユニットのサイズおよび位置のみを各STAに通知する必要がある。したがって、STA IDリストの送信は省略され得る。
加えて、本発明の本実施形態においては、ユーザグループ情報は、ステーション識別子リストを含み、別々に送信されること、または、ユーザグループ情報は、ユーザ固有の情報の一部として使用され得る、すなわち、各STA IDは、対応するユーザ固有の情報に配置されることに留意されたい。
オプションとして、リソーススケジューリング情報は、ターゲット周波数ドメインの帯域幅を指示する第1の指示情報をさらに含む。
特に、割り当て予定の周波数ドメインリソースの帯域幅を決定した後に、受信端は、例えば、図4から図6に示したリソースユニットの割り振りに従って、割り当て予定の周波数ドメインリソースに含まれる最大のリソースユニットのサイズを決定することができる、したがって、各マッピングルールに対応するプリセットサブキャリア数量を決定することができる。したがって、送信端は、割り当て予定の周波数ドメインリソースの帯域幅を受信端に指示する帯域幅指示情報(第1の指示情報の例)をさらに送信し得る。
第1の指示情報に基づいて行われるリソーススケジューリングの方式を説明した上記は例にすぎず、本発明はそれに限定されないことを理解されたい。例えば、通信システムが指定の帯域幅を有する周波数ドメインリソースのみを使用する場合には、各マッピングルールに対応するプリセットサブキャリア数量が、デフォルト値として使用されてもよく、送信端および受信端において事前に設定されていてもよい。
オプションとして、リソーススケジューリング情報は、各リソースユニットがマルチユーザ多入力多出力MU-MIMOのために使用されているかどうかを指示する第2の指示情報をさらに含む。
特に、上述したように、受信端は、リソース割り振り指示情報に従って、サイズおよび割り当て予定の周波数ドメインリソースに含まれる各リソースユニットの位置を決定することができる。したがって、送信端は、MIMO指示情報(すなわち、第2の指示情報の例)を使用して、各リソースユニットがMU-MIMOを行うものであるかどうかをさらに通知し得る。
例えば、MU-MIMO伝送が可能なリソースユニットの最小粒度が242であると仮定すると、図14に示したように、MU-MIMO伝送は、第1のリソースユニット(2×242トーンリソースユニット)上で行われ、MU-MIMO伝送は、他のリソースユニット(すなわち、網掛け部分内のリソースユニット)では行われない。ここで、マッピングルール#Bを一例として使用する。マッピングルール#Aおよび#Cも同様であり得る。
ある方式では、MIMO指示情報は、4ビット指示情報であり得る、すなわち、"1000"で指示され得る。1番目のビット"1"は、対称中心の左サイド上の2×242トーンリソースユニットがMU-MIMO伝送のために使用されていることを指示する。2番目のビット"0"は、2×242トーンリソースユニットが対称中心の右サイド上にないことを指示し、したがって、右サイド上で2×242リソースユニット上で行われるMU-MIMO伝送のケースは存在しない。3番目のビット"0"は、対称中心の右サイド上の第1の242リソースユニットがMU-MIMO伝送のために使用されていないことを指示する。4番目のビット"0"は、対称中心の右サイド上の第2の242リソースユニットがMU-MIMO伝送のために使用されていないことを指示する。真ん中の1×26リソースユニットは、真ん中の1×26リソースユニットをMU-MIMO伝送のために使用できないことを暗黙的に示す。
この場合には、受信端が前述のリソース割り振り指示情報に基づいて各リソースユニットのサイズおよび位置を決定していなかった場合には、受信端は、MU-MIMO指示情報に基づいて、各リソースユニットをMU-MIMO伝送のために使用することができるかどうかを決定することができる。
別の方式では、周波数ドメインリソース割り振り指示情報(例えば、前述のマッピングルール#A、マッピングルール#B、およびマッピングルール#C)を参照して、割り当て予定の周波数ドメインリソースが分割されるリソースユニットの数量を知り得る。MU-MIMO指示情報は、3ビット指示情報であり得る、すなわち、"100"で指示され得る。1番目のビット"1"は、割り当て予定の周波数ドメインリソースにおける1番目のリソースユニットがMU-MIMO伝送のために使用されていることを指示する。割り当て予定の周波数ドメインリソースにおける2番目のリソースユニットのサイズが242未満であるため、第2のリソースユニットは、デフォルトでMU-MIMO伝送のために使用されない。2番目のビット"0"は、割り当て予定の周波数ドメインリソースにおける3番目のリソースユニットがMU-MIMO伝送のために使用されていないことを指示する。3番目の"0"は、割り当て予定の周波数ドメインリソースにおける4番目のリソースユニットがMU-MIMO伝送のために使用されていないことを指示する。
本発明の本実施形態によるリソーススケジューリング方法は、各リソースユニットがMU-MIMO伝送のために使用されているかどうかを受信端が知ることを可能にしており、したがって、伝送効率および信頼性を改善することを可能としている。
オプションとして、リソーススケジューリング情報は、各リソースユニットは、利用可能であるかどうかを指示する第3の指示情報をさらに含む。
特に、上述したように、受信端は、リソース割り振り指示情報に従って、サイズおよび割り当て予定の周波数ドメインリソースに含まれる各リソースユニットの位置を決定することができる。したがって、送信端は、各リソースユニットが利用可能であるかどうかを指示する指示情報(すなわち、第3の指示情報)を使用して、各リソースユニットが利用可能であるかどうかをさらに通知し得る。
例えば、割り当て予定の周波数ドメインリソースにおける各リソースユニットの割り振りが図14に示したものであると仮定すると、干渉などの因子により、網掛け部分内のリソースユニットは、利用不可である。
例えば、前述のtype-2マッピングルール(すなわち、マッピングルール#B)が使用されている場合には、割り当て予定の周波数ドメインリソースに対応するリソース割り振り指示情報は、"1011"である。真ん中のリソースユニットがデフォルトで存在しているため、受信端は、ビットシーケンスに従って、割り当て予定の周波数ドメインリソースを4つのリソースユニットに分割すると決定し得る。図14に示したように、第2、第3、および第4のリソースユニットは、利用不可である。したがって、受信端は、以下の方式で通知し得る。
方式1: 4ビットは、4つのリソースユニットが利用可能であるかどうかをそれぞれ指示するものであり得る。例えば、"0"は、リソースユニットが利用不可であることを指示し、"1"は、リソースユニットを指示する。ビットは、1対1ベースでリソースユニットに対応する。例えば、1番目のビットは、第1のリソースユニットに対応し、2番目のビットは、第2のリソースユニットに対応し、3番目のビットは、第3のリソースユニットに対応し、4番目のビットは、第4のリソースユニットに対応する。この場合には、4ビット指示情報は、"1000"である。
方式2: インデックス番号はまた、どのリソースユニットが利用不可であるかを指示するものであってもよい。割り当て予定の周波数ドメインリソースを4つのリソースユニットに分割するため、2ビットのみがインデックス番号を指示するために必要になる。例えば、"00"は、第1のリソースユニットを指示し、"01"は、第2のリソースユニットを指示し、"10"は、第3のリソースユニットを指示し、"11"は、第4のリソースユニットを指示する。この場合には、送信端は、第3の指示情報として利用可能なリソースユニットのインデックス番号"00"を受信端に送信し得る、または、送信端は、第3の指示情報として利用不可能なリソースユニットのインデックス番号"011011"を受信端に送信し得る。このことは本発明において特に限定されない。
本発明の本実施形態によるリソーススケジューリング方法は、各リソースユニットが利用可能であるかどうかを受信端が知ることを可能にしており、したがって、伝送効率および信頼性を改善することを可能としている。
オプションとして、方法は、無線ローカルエリアネットワークシステムに適用され、
ビットシーケンスを受信端に送信するステップは、
ビットシーケンスをプリアンブル内の高効率シグナリングフィールドAまたは高効率シグナリングフィールドBに付加し、ビットシーケンスを受信端に送信するステップ、または、
ビットシーケンスを媒体アクセス制御レイヤに付加し、ビットシーケンスを受信端に送信するステップを含む。
特に、WLANシステム内のパケット構造(例えば、802.11ax)を図15に示している。プリアンブル部分は、レガシープリアンブル(Legacy preamble、L-preamble)およびレガシープリアンブルの直後に続く高効率(High Efficient、HE)プリアンブルを含む。レガシープリアンブルは、ショートトレーニングフィールド(Legacy Shorting Training Field、L-STF)、ロングトレーニングフィールド(Legacy Long Training Field、L-LTF)、シグナリングフィールド(Legacy Signal Field、L-SIG)、およびリピーテッドシグナリングフィールド(Rpeated Legacy Signal Field、RL-SIG)を含む。高効率プリアンブルは、高効率シグナリングフィールドA(High Efficient Signal Field A、HE-SIGA)、高効率シグナリングフィールドB(High Efficient Signal Field B、HE-SIGB)、高効率ショートトレーニングフィールド(High Efficient Shorting Training Field、HE-STF)、および高効率ロングトレーニングフィールド(High Efficient Long Training Field、HE-LTF)を含む。オプションとして、高効率プリアンブルは、高効率シグナリングフィールドC(High Efficient Signal Field C、HE-SIGC)を含む。さらに、WLANシステム内のパケット構造は、データフィールド(DATA)をさらに含む。
HE-SIGAおよびHE-SIGBは、すべてのユーザにブロードキャストされ、802.11axパケット構造においてシグナリング情報を搬送する。HE-SIG-Bは、図16に示したように共通の情報パラメータ(Common Parameter)、リソース割り振り指示(Resource Allocation)、ステーション識別子リスト(STA IDリスト)、および各スケジューリング済みのユーザステーションに関する情報(STA Parameter)を含む。あるいは、ステーション識別子はまた、図17に示したように、対応するユーザステーション情報に配置され得る。共通の情報パラメータは、データ伝送、OFMDA/MU-MIMO指示、HE-LTF数量、およびモードのために使用されるガードインターバル(Guard Interval、GI)を含み、アップリンク/ダウンリンク指示、および従来のHE-SIGBが存在するかどうかといったパラメータを含み得る。ユーザステーション情報は、ユーザの空間ストリームの数量、データ伝送のために使用される変調符号化方式(MCS、Modulation and Coding Scheme)、符号化タイプ、時空間ブロック符号(STBC)を使用するかどうかに関する指示、ビームフォーミング(beamforming)技術を使用するかどうかに関する指示を含む。加えて、共通の情報パラメータはまた、HE-SIGAにおいて搬送されてもよい。
したがって、本発明の本実施形態においては、リソーススケジューリング情報は、HE-SIGA(例えば、HE-SIGAは、帯域幅情報を搬送し得る)、またはHE-SIGB(例えば、HE-SIGBは、前述のビットシーケンス、ユーザグループ情報などを含むリソース割り振り情報を搬送し得る)において搬送され、受信端に送信され得る。
あるいは、本発明の本実施形態においては、リソーススケジューリング情報は、媒体アクセス制御レイヤにおいて搬送され得る。例えば、リソーススケジューリング情報は、媒体アクセス制御レイヤまたはMACレイヤ内の別のフィールド内の媒体アクセス制御ヘッダ(MAC HEADER)において搬送されてもよい。
本発明の本実施形態による、リソーススケジューリング方法においては、ビットシーケンス中の少なくともいくつかのビットが、実際の割り振りにおけるリソースユニットの割り振りに基づくとともに、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置と比較することによって、割り当て予定の周波数ドメインリソースから実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースを分割することによって取得される可能性があるリソースユニットの位置にある1つまたは複数のリソースユニットの位置にあるかどうかを指示するものであり、異なる長さのビットシーケンスをフレキシブルに生成することを可能としている。したがって、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることを可能としている。
さらに、本発明の本実施形態による、リソーススケジューリング方法においては、N個のマッピングルールを取得し、各マッピングルール下の各リソースユニットに対応する指示識別子を割り当て予定の周波数ドメインリソースにおいて各リソースユニットに含まれるサブキャリアの数量に従って決定し、指示識別子に基づいて、割り当て予定の周波数ドメインリソースにおける各リソースユニットに含まれるサブキャリアの数量および各リソースユニットの位置を指示するビットシーケンスを決定し得る。したがって、異なる長さのビットシーケンスのフレキシブルな生成を、割り当て予定の周波数ドメインリソースにおいて各リソースユニットに含まれるサブキャリアの数量に従って、実施することができ、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることを可能としている。
図18は、本発明の別の実施形態による、リソーススケジューリング方法200の概略フローチャートである、ここで、方法を受信端の観点から説明している。方法200は、無線ローカルエリアネットワークに適用され、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義する。図18に示したように、方法200は、以下のステップを含む。
S210. 受信端が、送信端によって送信されたリソーススケジューリング情報を受信する、ここで、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースについて実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置のうちの1つまたは複数のリソースユニットの位置にあるかどうかを指示するものである。
S220. リソーススケジューリング情報に従って、受信端に送信端によって実際に割り振られたリソースユニットを決定する。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を含む。
オプションとして、割り当て予定の周波数ドメインリソースに割り振られる可能性があるリソースユニットの位置は、デフォルト位置を含み、デフォルト位置に対応するリソースユニットは、次世代プロトコルによって事前に定義されているような、ビットシーケンスによって指示されないリソースユニットである。
オプションとして、ビットシーケンスは、複数のtype-1ビットを含み、複数のtype-1ビットは、1対1ベースで複数のリソースユニットの位置のペアに対応し、type-1ビットのうちの1つは、対応するリソースユニットの位置のペア中のリソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するものであり、1つのリソースユニットの位置のペアは、デフォルト位置の一方のサイド上に位置する2つの連続した最小のリソースユニットの位置を含む。
オプションとして、ビットシーケンスは、複数のtype-2ビットを含み、type-2ビットは、対称中心の一方のサイド上における最大のリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。
オプションとして、ビットシーケンスは、2つのtype-3ビットを含み、2つのtype-3ビットは、1対1ベースで対称中心の双方のサイド上に位置する2つのリソースユニット位置グループに対応し、type-3ビットは、対応するリソースユニット位置グループ中のリソースユニットの位置にあるすべてのリソースユニットが割り当て予定のリソースユニットであるかどうかを指示するものであり、1つのリソースユニット位置グループは、割り当て予定の周波数ドメインリソースの中心の一方のサイド上に位置する複数の最小のリソースユニットの位置を含む。
オプションとして、リソーススケジューリング情報は、複数のスケジューリング済みの受信端の識別子をさらに含み、受信端の識別子は、実際の割り振りにおけるリソースユニットが複数の受信端に割り振られていることを指示するものである。
オプションとして、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースを指示する第1の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットがマルチユーザ多入力多出力MU-MIMOのために使用されているかどうかを指示する第2の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットが利用可能であるかどうかを指示する第3の指示情報をさらに含む。
オプションとして、受信端が送信端によって送信されたリソーススケジューリング情報を受信することは、
プリアンブル内の高効率シグナリングフィールドAまたは高効率シグナリングフィールドBにおいて搬送されるとともに送信端によって送信されたビットシーケンスを受信すること、または、
媒体アクセス制御レイヤにおいて搬送されるとともに送信端によって送信されたビットシーケンスを受信することを含む。
オプションとして、送信端は、ネットワークデバイスであり、受信端は、端末デバイスである。
方法200における受信端のアクションは、方法100における受信端(例えば、端末デバイス)のアクションと同様であり、方法200における送信端のアクションは、方法100における送信端(例えば、ネットワークデバイス)のアクションと同様である。本明細書では繰り返しを避けるためにその詳細な説明を省略する。
本発明の本実施形態による、リソーススケジューリング方法においては、ビットシーケンス中の少なくともいくつかのビットが、実際の割り振りにおけるリソースユニットの割り振りに基づくとともに、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置と比較することによって、割り当て予定の周波数ドメインリソースから実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースを分割することによって取得される可能性があるリソースユニットの位置にある1つまたは複数のリソースユニットの位置にあるかどうかを指示するものであり、異なる長さのビットシーケンスをフレキシブルに生成することを可能としている。したがって、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることを可能としている。
上記においては、図1から図18を参照して、本発明の実施形態による、リソーススケジューリング方法を詳細に説明している。下記においては、図19および図20を参照して、本発明の実施形態による、詳細リソーススケジューリング装置を詳細に説明する。
図19は、本発明の実施形態による、リソーススケジューリング装置300の概略ブロック図を示している。装置300は、無線ローカルエリアネットワークに適用され、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義する。図18に示したように、装置300は、
リソーススケジューリング情報を生成するように構成される、生成ユニット310であって、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースについて実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置のうちの1つまたは複数のリソースユニットの位置にあるかどうかを指示するためのものである、生成ユニット310と、
リソーススケジューリング情報を受信端に送信するように構成される、送信ユニット320とを備える。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を含む。
オプションとして、割り当て予定の周波数ドメインリソースに割り振られる可能性があるリソースユニットの位置は、デフォルト位置を含み、デフォルト位置に対応するリソースユニットは、次世代プロトコルによって事前に定義されているような、ビットシーケンスによって指示されないリソースユニットである。
オプションとして、ビットシーケンスは、複数のtype-1ビットを含み、複数のtype-1ビットは、1対1ベースで複数のリソースユニットの位置のペアに対応し、type-1ビットのうちの1つは、対応するリソースユニットの位置のペア中のリソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するものであり、1つのリソースユニットの位置のペアは、デフォルト位置の一方のサイド上に位置する2つの連続した最小のリソースユニットの位置を含む。
オプションとして、ビットシーケンスは、複数のtype-2ビットを含み、type-2ビットは、対称中心の一方のサイド上における最大のリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。
オプションとして、ビットシーケンスは、2つのtype-3ビットを含み、2つのtype-3ビットは、1対1ベースで対称中心の双方のサイド上に位置する2つのリソースユニット位置グループに対応し、type-3ビットは、対応するリソースユニット位置グループ中のリソースユニットの位置にあるすべてのリソースユニットが割り当て予定のリソースユニットであるかどうかを指示するものであり、1つのリソースユニット位置グループは、割り当て予定の周波数ドメインリソースの中心の一方のサイド上に位置する複数の最小のリソースユニットの位置を含む。
オプションとして、リソーススケジューリング情報は、複数のスケジューリング済みの受信端の識別子をさらに含み、受信端の識別子は、実際の割り振りにおけるリソースユニットが複数の受信端に割り振られていることを指示するものである。
オプションとして、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースを指示する第1の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットがマルチユーザ多入力多出力MU-MIMOのために使用されているかどうかを指示する第2の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットが利用可能であるかどうかを指示する第3の指示情報をさらに含む。
オプションとして、送信ユニットは、ビットシーケンスをプリアンブル内の高効率シグナリングフィールドAまたは高効率シグナリングフィールドBに付加し、ビットシーケンスを受信端に送信するように特に構成される、または、
送信ユニットは、ビットシーケンスを媒体アクセス制御レイヤに付加し、ビットシーケンスを受信端に送信するように特に構成される。
オプションとして、装置300は、ネットワークデバイスであり、受信端は、端末デバイスである。
本発明の本実施形態による、リソーススケジューリング装置300は、本発明の実施形態の方法における送信端(例えば、ネットワークデバイス)に対応し得るし、リソーススケジューリング装置300内の各ユニットすなわち各モジュール、および前述の他の操作および/または機能は、図1中の方法100の対応するプロシージャを実施することをそれぞれ意図している。簡潔にするために、その詳細を本明細書では再び説明しない。
本発明の本実施形態による、リソーススケジューリング装置においては、ビットシーケンス中の少なくともいくつかのビットが、実際の割り振りにおけるリソースユニットの割り振りに基づくとともに、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置と比較することによって、割り当て予定の周波数ドメインリソースから実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースを分割することによって取得される可能性があるリソースユニットの位置にある1つまたは複数のリソースユニットの位置にあるかどうかを指示するものであり、異なる長さのビットシーケンスをフレキシブルに生成することを可能としている。したがって、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることを可能としている。
図20は、本発明の実施形態による、リソーススケジューリング装置400の概略ブロック図を示している。装置400は、無線ローカルエリアネットワークに適用され、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義する。図20に示したように、装置400は、
送信端によって送信されたリソーススケジューリング情報を受信するように構成される、受信ユニット410であって、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースについて実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置のうちの1つまたは複数のリソースユニットの位置にあるかどうかを指示するためのものである、受信ユニット410と、
リソーススケジューリング情報に従って、受信端に送信端によって実際に割り振られたリソースユニットを決定するように構成される、決定ユニット420とを備える。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を含む。
オプションとして、割り当て予定の周波数ドメインリソースに割り振られる可能性があるリソースユニットの位置は、デフォルト位置を含み、デフォルト位置に対応するリソースユニットは、次世代プロトコルによって事前に定義されているような、ビットシーケンスによって指示されないリソースユニットである。
オプションとして、ビットシーケンスは、複数のtype-1ビットを含み、複数のtype-1ビットは、1対1ベースで複数のリソースユニットの位置のペアに対応し、type-1ビットのうちの1つは、対応するリソースユニットの位置のペア中のリソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するものであり、1つのリソースユニットの位置のペアは、デフォルト位置の一方のサイド上に位置する2つの連続した最小のリソースユニットの位置を含む。
オプションとして、ビットシーケンスは、複数のtype-2ビットを含み、type-2ビットは、対称中心の一方のサイド上における最大のリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。
オプションとして、ビットシーケンスは、2つのtype-3ビットを含み、2つのtype-3ビットは、1対1ベースで対称中心の双方のサイド上に位置する2つのリソースユニット位置グループに対応し、type-3ビットは、対応するリソースユニット位置グループ中のリソースユニットの位置にあるすべてのリソースユニットが割り当て予定のリソースユニットであるかどうかを指示するものであり、1つのリソースユニット位置グループは、割り当て予定の周波数ドメインリソースの中心の一方のサイド上に位置する複数の最小のリソースユニットの位置を含む。
オプションとして、リソーススケジューリング情報は、複数のスケジューリング済みの受信端の識別子をさらに含み、受信端の識別子は、実際の割り振りにおけるリソースユニットが複数の受信端に割り振られていることを指示するものである。
オプションとして、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースを指示する第1の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットがマルチユーザ多入力多出力MU-MIMOのために使用されているかどうかを指示する第2の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットが利用可能であるかどうかを指示する第3の指示情報をさらに含む。
オプションとして、受信ユニットは、プリアンブル内の高効率シグナリングフィールドAまたは高効率シグナリングフィールドBにおいて搬送されるとともに送信端によって送信されたビットシーケンスを受信するように特に構成される、または、
受信ユニットは、媒体アクセス制御レイヤにおいて搬送されるとともに送信端によって送信されたビットシーケンスを受信するように特に構成される。
オプションとして、送信端は、ネットワークデバイスであり、装置400は、端末デバイスである。
本発明の本実施形態による、リソーススケジューリング装置400は、本発明の実施形態の方法における送信端(例えば、ネットワークデバイス)に対応し得るし、リソーススケジューリング装置400内の各ユニットすなわち各モジュール、および前述の他の操作および/または機能は、図18中の方法200の対応するプロシージャを実施することをそれぞれ意図している。簡潔にするために、その詳細を本明細書では再び説明しない。
本発明の本実施形態による、リソーススケジューリング装置においては、ビットシーケンス中の少なくともいくつかのビットが、実際の割り振りにおけるリソースユニットの割り振りに基づくとともに、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置と比較することによって、割り当て予定の周波数ドメインリソースから実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースを分割することによって取得される可能性があるリソースユニットの位置にある1つまたは複数のリソースユニットの位置にあるかどうかを指示するものであり、異なる長さのビットシーケンスをフレキシブルに生成することを可能としている。したがって、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることを可能としている。
上記においては、図1から図18を参照して、本発明の実施形態による、リソーススケジューリング方法を詳細に説明している。下記においては、図21および図22を参照して、本発明の実施形態による、リソーススケジューリングデバイスを詳細に説明する。
図21は、本発明の実施形態による、リソーススケジューリングデバイス500の概略構造図を示している。デバイス500は、無線ローカルエリアネットワークに適用され、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義する。図21に示したように、デバイス500は、
バス510と、
バスに接続されているプロセッサ520と、
バスに接続されているメモリ530と、
バスに接続されている送信機540とを備え、
プロセッサは、リソーススケジューリング情報を生成することであって、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースについて実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置のうちの1つまたは複数のリソースユニットの位置にあるかどうかを指示するためのものである、生成することをし、
リソーススケジューリング情報を受信端に送信するように送信機を制御するために、バスを使用して、メモリに記憶されているプログラムを実行する。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を含む。
オプションとして、割り当て予定の周波数ドメインリソースに割り振られる可能性があるリソースユニットの位置は、デフォルト位置を含み、デフォルト位置に対応するリソースユニットは、次世代プロトコルによって事前に定義されているような、ビットシーケンスによって指示されないリソースユニットである。
オプションとして、ビットシーケンスは、複数のtype-1ビットを含み、複数のtype-1ビットは、1対1ベースで複数のリソースユニットの位置のペアに対応し、type-1ビットのうちの1つは、対応するリソースユニットの位置のペア中のリソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するものであり、1つのリソースユニットの位置のペアは、デフォルト位置の一方のサイド上に位置する2つの連続した最小のリソースユニットの位置を含む。
オプションとして、ビットシーケンスは、複数のtype-2ビットを含み、type-2ビットは、対称中心の一方のサイド上における最大のリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。
オプションとして、ビットシーケンスは、2つのtype-3ビットを含み、2つのtype-3ビットは、1対1ベースで対称中心の双方のサイド上に位置する2つのリソースユニット位置グループに対応し、type-3ビットは、対応するリソースユニット位置グループ中のリソースユニットの位置にあるすべてのリソースユニットが割り当て予定のリソースユニットであるかどうかを指示するものであり、1つのリソースユニット位置グループは、割り当て予定の周波数ドメインリソースの中心の一方のサイド上に位置する複数の最小のリソースユニットの位置を含む。
オプションとして、リソーススケジューリング情報は、複数のスケジューリング済みの受信端の識別子をさらに含み、受信端の識別子は、実際の割り振りにおけるリソースユニットが複数の受信端に割り振られていることを指示するものである。
オプションとして、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースを指示する第1の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットがマルチユーザ多入力多出力MU-MIMOのために使用されているかどうかを指示する第2の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットが利用可能であるかどうかを指示する第3の指示情報をさらに含む。
オプションとして、プロセッサは、ビットシーケンスをプリアンブル内の高効率シグナリングフィールドAまたは高効率シグナリングフィールドBに付加し、ビットシーケンスを受信端に送信するように送信機を制御するように特に構成される、または、
プロセッサは、ビットシーケンスを媒体アクセス制御レイヤに付加し、ビットシーケンスを受信端に送信するように送信機を制御するように特に構成される。
オプションとして、デバイス500は、ネットワークデバイスであり、受信端は、端末デバイスである。
本発明の本実施形態は、様々な通信デバイスに適用され得る。
デバイス500の送信機は、送信機回路、電力コントローラ、エンコーダ、およびアンテナを備え得る。さらに、デバイス500は、受信機をさらに備え得る。受信機は、受信機回路、電力コントローラ、デコーダ、およびアンテナを備え得る。
プロセッサをCPUとさらに称し得る。メモリは、リードオンリーメモリおよびランダムアクセスメモリを含み、プロセッサに命令およびデータを提供し得る。メモリの一部は、不揮発性ランダムアクセスメモリ(NVRAM)をさらに含み得る。特定の活用においては、デバイス500が、内蔵されていてもよく、または、デバイス500自身が、ネットワークデバイスなどの無線通信デバイスであってもよく、デバイス500とリモートロケーションとの間のデータ伝送および受信を可能にするために、送信機回路および受信機回路を含むキャリアをさらに備えていてもよい。送信機回路および受信機回路は、アンテナに接続され得る。デバイス500内のコンポーネントは、バスを使用して一緒に結合される、ここで、バスは、データバスに加えて、電力バス、制御バス、および状態信号バスをさらに含む。しかしながら、明瞭な説明のために、様々なバスを図中ではバスとして示している。特に、異なる製品においては、デコーダを処理ユニットと一体化してもよい。
プロセッサは、本発明の方法の実施形態において開示したステップおよび論理ブロック図を実施または実行し得る。汎用プロセッサは、マイクロプロセッサであってもよいし、または、プロセッサは、任意の従来のプロセッサ、デコーダなどであってもよい。本発明の実施形態を参照して開示した方法のステップを、ハードウェアプロセッサによって直接実行および完了してもよいし、または、デコーディングプロセッサ内のハードウェアモジュールおよびソフトウェアモジュールの組合せを使用して実行および完了してもよい。ソフトウェアモジュールは、ランダムアクセスメモリ、フラッシュメモリ、リードオンリーメモリ、プログラマブルリードオンリーメモリ、電気的消去可能プログラマブルメモリ、またはレジスタなどといった、当該技術分野における成熟した記憶媒体にあってもよい。
本発明の実施形態においては、プロセッサは、中央処理ユニット(Central Processing Unit、略して、「CPU」)であり得る、または、プロセッサは、別の汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)または別のプログラマブルロジックデバイス、ディスクリートゲートまたはトランジスタロジックデバイス、ディスクリートハードウェアコンポーネントなどであり得ることを理解されたい。汎用プロセッサは、マイクロプロセッサであってもよいし、またはプロセッサは、任意の従来のプロセッサなどであってもよい。
メモリは、リードオンリーメモリおよびランダムアクセスメモリを含み、プロセッサに命令およびデータを提供し得る。メモリの一部は、不揮発性ランダムアクセスメモリをさらに含み得る。例えば、メモリは、デバイスタイプに関する情報をさらに記憶し得る。
バスシステムは、データバスに加えて、電力バス、制御バス、状態信号バスなどをさらに含み得る。しかしながら、明瞭な説明のために、図中の様々なバスをバスシステムとして示している。
ある実施プロセスにおいては、前述の方法の各ステップを、プロセッサ内のハードウェアの集積論理回路またはソフトウェアの形式の命令を使用して完了してもよい。本発明の実施形態を参照して開示した方法のステップを、ハードウェアプロセッサによって直接実行および完了してもよいし、または、プロセッサ内のハードウェアモジュールおよびソフトウェアモジュールの組合せを使用して実行および完了してもよい。ソフトウェアモジュールは、ランダムアクセスメモリ、フラッシュメモリ、リードオンリーメモリ、プログラマブルリードオンリーメモリ、電気的消去可能プログラマブルメモリ、またはレジスタなどといった、当該技術分野における成熟した記憶媒体にあってもよい。記憶媒体は、メモリにあり、プロセッサは、メモリ内の情報を読み出し、プロセッサのハードウェアと組み合わせて前述の方法におけるステップを完了する。繰り返しを避けるために、その詳細を本明細書では再び説明しない。
本発明の本実施形態による、リソーススケジューリングデバイス500は、本発明の実施形態の方法における送信端(例えば、ネットワークデバイス)に対応し得るし、リソーススケジューリングデバイス500内の各ユニットすなわち各モジュール、および前述の他の操作および/または機能は、図1中の方法100の対応するプロシージャを実施することをそれぞれ意図している。簡潔にするために、その詳細を本明細書では再び説明しない。
本発明の本実施形態による、リソーススケジューリングデバイスにおいては、ビットシーケンス中の少なくともいくつかのビットが、実際の割り振りにおけるリソースユニットの割り振りに基づくとともに、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置と比較することによって、割り当て予定の周波数ドメインリソースから実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースを分割することによって取得される可能性があるリソースユニットの位置にある1つまたは複数のリソースユニットの位置にあるかどうかを指示するものであり、異なる長さのビットシーケンスをフレキシブルに生成することを可能としている。したがって、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることを可能としている。
図22は、本発明の実施形態による、リソーススケジューリングデバイス600の概略ブロック図を示している。デバイス600は、無線ローカルエリアネットワークに適用され、無線ローカルエリアネットワークが準拠する次世代プロトコルは、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置を事前に定義する。図22に示したように、デバイス600は、
バス610と、
バスに接続されているプロセッサ620と、
バスに接続されているメモリ630と、
バスに接続されている受信機640とを備え、
プロセッサは、送信端によって送信されたリソーススケジューリング情報を受信するように受信機を制御することであって、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースからのリソースユニットの実際の割り振りを指示するビットシーケンスを含み、ビットシーケンス中の少なくともいくつかのビットは、割り当て予定の周波数ドメインリソースについて実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置のうちの1つまたは複数のリソースユニットの位置にあるかどうかを指示するためのものである、制御することをし、
リソーススケジューリング情報に従って、受信端に送信端によって実際に割り振られたリソースユニットを決定するために、バスを使用して、メモリに記憶されているプログラムを実行する。
オプションとして、割り当て予定の周波数ドメインリソースは、対称中心を含む。
オプションとして、割り当て予定の周波数ドメインリソースに割り振られる可能性があるリソースユニットの位置は、デフォルト位置を含み、デフォルト位置に対応するリソースユニットは、次世代プロトコルによって事前に定義されているような、ビットシーケンスによって指示されないリソースユニットである。
オプションとして、ビットシーケンスは、複数のtype-1ビットを含み、複数のtype-1ビットは、1対1ベースで複数のリソースユニットの位置のペアに対応し、type-1ビットのうちの1つは、対応するリソースユニットの位置のペア中のリソースユニットの位置が同一の割り当て予定のリソースユニットに配分されているかどうかを指示するものであり、1つのリソースユニットの位置のペアは、デフォルト位置の一方のサイド上に位置する2つの連続した最小のリソースユニットの位置を含む。
オプションとして、ビットシーケンスは、複数のtype-2ビットを含み、type-2ビットは、対称中心の一方のサイド上における最大のリソースユニットが実際の割り振りにおいて存在しているかどうかを指示するものである。
オプションとして、ビットシーケンスは、2つのtype-3ビットを含み、2つのtype-3ビットは、1対1ベースで対称中心の双方のサイド上に位置する2つのリソースユニット位置グループに対応し、type-3ビットは、対応するリソースユニット位置グループ中のリソースユニットの位置にあるすべてのリソースユニットが割り当て予定のリソースユニットであるかどうかを指示するものであり、1つのリソースユニット位置グループは、割り当て予定の周波数ドメインリソースの中心の一方のサイド上に位置する複数の最小のリソースユニットの位置を含む。
オプションとして、リソーススケジューリング情報は、複数のスケジューリング済みの受信端の識別子をさらに含み、受信端の識別子は、実際の割り振りにおけるリソースユニットが複数の受信端に割り振られていることを指示するものである。
オプションとして、リソーススケジューリング情報は、割り当て予定の周波数ドメインリソースを指示する第1の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットがマルチユーザ多入力多出力MU-MIMOのために使用されているかどうかを指示する第2の指示情報をさらに含む。
オプションとして、リソーススケジューリング情報は、実際の割り振りにおけるリソースユニットが利用可能であるかどうかを指示する第3の指示情報をさらに含む。
オプションとして、受信端が送信端によって送信されたリソーススケジューリング情報を受信することは、
プリアンブル内の高効率シグナリングフィールドAまたは高効率シグナリングフィールドBにおいて搬送されるとともに送信端によって送信されたビットシーケンスを受信すること、または、
媒体アクセス制御レイヤにおいて搬送されるとともに送信端によって送信されたビットシーケンスを受信することを含む。
オプションとして、送信端は、ネットワークデバイスであり、デバイス600は、端末デバイスである。
本発明の本実施形態は、様々な通信デバイスに適用され得る。
デバイス600の受信機は、受信機回路、電力コントローラ、デコーダ、およびアンテナを備え得る。さらに、デバイス600は、送信機をさらに備え得る。送信機は、送信機回路、電力コントローラ、エンコーダ、およびアンテナを備え得る。
プロセッサをCPUとさらに称し得る。メモリは、リードオンリーメモリおよびランダムアクセスメモリを含み、プロセッサに命令およびデータを提供し得る。メモリの一部は、不揮発性ランダムアクセスメモリ(NVRAM)をさらに含み得る。特定の活用においては、デバイス600が、内蔵されていてもよく、または、デバイス600自身が、端末デバイスなどの無線通信デバイスであってもよく、デバイス600とリモートロケーションとの間のデータ伝送および受信を可能にするために、送信機回路および受信機回路を含むキャリアをさらに備えていてもよい。送信機回路および受信機回路は、アンテナに接続され得る。デバイス600内のコンポーネントは、バスを使用して一緒に結合される、ここで、バスは、データバスに加えて、電力バス、制御バス、および状態信号バスをさらに含む。しかしながら、明瞭な説明のために、様々なバスを図中ではバスとして示している。特に、異なる製品においては、デコーダを処理ユニットと一体化してもよい。
プロセッサは、本発明の方法の実施形態において開示したステップおよび論理ブロック図を実施または実行し得る。汎用プロセッサは、マイクロプロセッサであってもよいし、または、プロセッサは、任意の従来のプロセッサ、デコーダなどであってもよい。本発明の実施形態を参照して開示した方法のステップを、ハードウェアプロセッサによって直接実行および完了してもよいし、または、デコーディングプロセッサ内のハードウェアモジュールおよびソフトウェアモジュールの組合せを使用して実行および完了してもよい。ソフトウェアモジュールは、ランダムアクセスメモリ、フラッシュメモリ、リードオンリーメモリ、プログラマブルリードオンリーメモリ、電気的消去可能プログラマブルメモリ、またはレジスタなどといった、当該技術分野における成熟した記憶媒体にあってもよい。
本発明の実施形態においては、プロセッサは、中央処理ユニット(Central Processing Unit、略して、「CPU」)であり得る、または、プロセッサは、別の汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)または別のプログラマブルロジックデバイス、ディスクリートゲートまたはトランジスタロジックデバイス、ディスクリートハードウェアコンポーネントなどであり得ることを理解されたい。汎用プロセッサは、マイクロプロセッサであってもよいし、またはプロセッサは、任意の従来のプロセッサなどであってもよい。
メモリは、リードオンリーメモリおよびランダムアクセスメモリを含み、プロセッサに命令およびデータを提供し得る。メモリの一部は、不揮発性ランダムアクセスメモリをさらに含み得る。例えば、メモリは、デバイスタイプに関する情報をさらに記憶し得る。
バスシステムは、データバスに加えて、電力バス、制御バス、状態信号バスなどをさらに含み得る。しかしながら、明瞭な説明のために、図中の様々なバスをバスシステムとして示している。
ある実施プロセスにおいては、前述の方法の各ステップを、プロセッサ内のハードウェアの集積論理回路またはソフトウェアの形式の命令を使用して完了してもよい。本発明の実施形態を参照して開示した方法のステップを、ハードウェアプロセッサによって直接実行および完了してもよいし、または、プロセッサ内のハードウェアモジュールおよびソフトウェアモジュールの組合せを使用して実行および完了してもよい。ソフトウェアモジュールは、ランダムアクセスメモリ、フラッシュメモリ、リードオンリーメモリ、プログラマブルリードオンリーメモリ、電気的消去可能プログラマブルメモリ、またはレジスタなどといった、当該技術分野における成熟した記憶媒体にあってもよい。記憶媒体は、メモリにあり、プロセッサは、メモリ内の情報を読み出し、プロセッサのハードウェアと組み合わせて前述の方法におけるステップを完了する。繰り返しを避けるために、その詳細を本明細書では再び説明しない。
本発明の本実施形態による、リソーススケジューリングデバイス600は、本発明の実施形態の方法における受信端(例えば、端末デバイス)に対応し得るし、リソーススケジューリングデバイス600内の各ユニットすなわち各モジュール、および前述の他の操作および/または機能は、図18中の方法200の対応するプロシージャを実施することをそれぞれ意図している。簡潔にするために、その詳細を本明細書では再び説明しない。
本発明の本実施形態による、リソーススケジューリングデバイスにおいては、ビットシーケンス中の少なくともいくつかのビットが、実際の割り振りにおけるリソースユニットの割り振りに基づくとともに、割り当て予定の周波数ドメインリソースから割り振られる可能性があるリソースユニットの位置と比較することによって、割り当て予定の周波数ドメインリソースから実際に割り振られた割り当て予定のリソースユニットが割り当て予定の周波数ドメインリソースを分割することによって取得される可能性があるリソースユニットの位置にある1つまたは複数のリソースユニットの位置にあるかどうかを指示するものであり、異なる長さのビットシーケンスをフレキシブルに生成することを可能としている。したがって、リソーススケジューリングにおいて伝送リソースオーバーヘッドの低減をサポートすることを可能としている。
前述のプロセスのシーケンス番号は本発明の様々な実施形態における実行順序を意味していないことを理解されたい。プロセスの実行順序は、プロセスの関数および内部ロジックに従って決定されるべきであり、本発明の実施形態の実施プロセスにおける如何なる限定としてもみなすべきではない。
当業者は、本明細書に開示した実施形態において説明した例と組み合わせて、ユニットおよびアルゴリズムステップを電子ハードウェアまたはコンピュータソフトウェアおよび電子ハードウェアの組合せによって実装することができることに気づくであろう。機能をハードウェアで行うかまたはソフトウェアで行うかは、具体的な活用および技術的ソリューションの設計上の制約条件に依存する。当業者は、異なる方法を使用して具体的な活用の各々のための説明した機能を実施してもよいが、その実施形態が本発明の範囲を逸脱しているとみなすべきではない。
簡便かつ簡潔な説明を目的として、前述のシステム、装置、およびユニットの詳細な動作プロセスについては、前述の方法の実施形態における対応するプロセスを参照されたいことは当業者によって明確に理解されよう、そのためその詳細を本明細書では再び説明しない。
本出願に提供したいくつかの実施形態においては、開示したシステム、装置、および方法を他の方式で実施してもよいことを理解されたい。例えば、説明した装置の実施形態は例にすぎない。例えば、ユニット分割は、論理的な機能分割にすぎず、実際の実施形態においては他の分割であってもよい。例えば、複数のユニットまたはコンポーネントを組み合わせても別のシステムと統合してもよいし、またはいくつかの特徴を無視しても行わなくてもよい。加えて、図示または記載した相互接続または直接接続または通信接続は、いくつかのインターフェースによって実施されてもよい。装置間またはユニット間の間接接続または通信接続は、電子的に、機械的に、または他の形式で実施されてもよい。
別個の部分として説明したユニットは、物理的に別個のものであってもなくてもよいし、ユニットとして図示した部分は、物理ユニットであってもなくてもよいし、1つのロケーションに配置されていてもよいし、または複数のネットワークユニットに分散されていてもよい。ユニットの一部またはすべては、実施形態のソリューションの目的を達成するために、実際の要件に従って選択してもよい。
加えて、本発明の実施形態における機能ユニットは1つの処理ユニットに統合されてもよいし、または、ユニットの各々は物理的に単独で存在してもよいし、または、2つ以上のユニットは1つのユニットに統合される。
機能を、ソフトウェア機能ユニットの形式で実装し、独立した製品として販売または使用する場合には、機能は、コンピュータ可読記憶媒体に記憶され得る。そのような理解に基づいて、基本的に、本発明の技術的解決手法、または従来技術に貢献する部分、またはいくつかの技術的解決手法は、ソフトウェア製品の形式で実装されてもよい。ソフトウェア製品は、記憶媒体に記憶されており、本発明の実施形態において説明した方法のステップのすべてまたは一部を行うように(パーソナルコンピュータ、サーバ、または送信端であり得る)コンピュータデバイスに命令するいくつかの命令を含む。前述の記憶媒体は、USBフラッシュドライブ、リムーバブルハードディスク、リードオンリーメモリ(ROM、Read-Only Memory)、ランダムアクセスメモリ(RAM、Random Access Memory)、磁気ディスク、または光ディスクなどといった、プログラムコードを記憶することができる任意の媒体を含む。
前述の説明は、本発明の特定の実施形態にすぎず、本発明の保護範囲を限定することを意図していない。本発明に開示の技術的範囲において当業者が容易に想到する任意の変形または置換は、本発明の保護範囲に含まれるものとする。したがって、本発明の保護範囲は、特許請求の範囲の保護範囲に従うものとする。
本発明の実施形態をより明確にするために、簡易な用語で表した実施形態を以下に提供する。
300 リソーススケジューリング装置
310 生成ユニット
320 送信ユニット
400 リソーススケジューリング装置
410 受信ユニット
420 決定ユニット
510 バス
520 プロセッサ
530 メモリ
540 送信機
610 バス
620 プロセッサ
630 メモリ
640 受信機