(57)【要約】本発明の一実施例による無線通信システムにおいて、複数のＴＴＩ（Transmission Time Interval）長をサポートする端末のためのスケジューリング要求（Scheduling Request；ＳＲ）送信方法であって、上記方法は端末によって行われ、下りリンクデータを受信するステップと、上記下りリンクデータに対応するＨＡＲＱ−ＡＣＫ（Hybrid Automatic Retransmission reQuest-ACKnowledgement/Non-ACKnowledgement）送信のための第１のＴＴＩ長の第１の物理上りリンク制御チャネル（Physical Uplink Control CHannel；ＰＵＣＣＨ）の送信時点とＳＲ送信のための第２のＰＵＣＣＨの送信時点とが重なる場合、第１のＰＵＣＣＨで上記ＨＡＲＱ−ＡＣＫを送信するステップと、を有し、上記第１のＰＵＣＣＨは、第２のＰＵＣＣＨよりも少ない数のシンボルからなり、上記第１のＰＵＣＣＨが有効なＳＲリソースを有しない場合、上記ＳＲは送信されなくてもよい。【選択図】図９
2019530382.tif 000002
【特許請求の範囲】
【請求項１】
無線通信システムにおいて、複数の送信時間間隔（Transmission Time Interval；ＴＴＩ）長をサポートする端末のためのスケジューリング要求（Scheduling Request；ＳＲ）送信方法であって、前記方法は端末によって行われ、
下りリンクデータを受信するステップと、
前記下りリンクデータに対応するハイブリッド自動再送要求確認応答（Hybrid Automatic Retransmission reQuest-ACKnowledgement/Non-ACKnowledgement；ＨＡＲＱ−ＡＣＫ）送信のための第１のＴＴＩ長の第１の物理上りリンク制御チャネル（Physical Uplink Control CHannel；ＰＵＣＣＨ）の送信時点とＳＲ送信のための第２のＰＵＣＣＨの送信時点とが重なる場合、
第１のＰＵＣＣＨで前記ＨＡＲＱ−ＡＣＫを送信するステップと、を有し、
前記第１のＰＵＣＣＨは、第２のＰＵＣＣＨよりも少ない数のシンボルからなり、前記第１のＰＵＣＣＨが有効なＳＲリソースを有しない場合、前記ＳＲは送信されない、方法。
【請求項２】
前記第１のＰＵＣＣＨが有効なＳＲリソースを有する場合、前記ＳＲは、前記第１のＰＵＣＣＨで送信される、請求項１に記載の方法。
【請求項３】
前記ＳＲは、上りリンク承認の不要な上りリンク送信に対する要求又はリソース設定要求を有する、請求項１に記載の方法。
【請求項４】
前記ＳＲは複数のビットで表現され、前記複数のビットで表現される各状態は、前記上りリンク送信に関連するＨＡＲＱプロセス番号に関係付けられる、請求項３に記載の方法。
【請求項５】
前記ＳＲは複数のビットで表現され、前記複数のビットと前記上りリンク送信が送信されるリソースとの組み合わせによって、前記上りリンク送信に関連するＨＡＲＱプロセス番号が決定される、請求項３に記載の方法。
【請求項６】
前記ＳＲ及び前記ＨＡＲＱ−ＡＣＫの送信時点とバッファ状態報告（Buffer State Report；ＢＳＲ）の送信時点とが重なる場合、
前記ＳＲ、前記ＨＡＲＱ−ＡＣＫ及び前記ＢＳＲのうち２種類の情報がバンドリングされて、送信される変調シンボルの状態にマッピングされる、請求項１に記載の方法。
【請求項７】
前記ＳＲ及び前記ＨＡＲＱ−ＡＣＫの送信時点とバッファ状態報告（Buffer State Report；ＢＳＲ）の送信時点とが重なる場合、
変更されたＰＵＣＣＨフォーマットを用いるか、又はより多くのリソースブロックを用いて、前記ＳＲ、前記ＨＡＲＱ−ＡＣＫ及び前記ＢＳＲがいずれも第１のＰＵＣＣＨ上で送信される、請求項１に記載の方法。
【請求項８】
前記ＳＲは、特定のサービス又は特定の要求事項のためのものであり、前記有効なＳＲリソースの時間間隔又は周期は、通常のデータトラフィックのためのＳＲリソースの時間間隔又は周期より短い、請求項１に記載の方法。
【請求項９】
無線通信システムにおいて、複数の送信時間間隔（Transmission Time Interval；ＴＴＩ）長をサポートする端末のためのスケジューリング要求（Scheduling Request；ＳＲ）を送信する端末であって、前記端末は、
受信器及び送信器と、
前記受信器及び送信器を制御するプロセッサと、を有し、
下りリンクデータを受信して、前記下りリンクデータに対応するハイブリッド自動再送要求確認応答（Hybrid Automatic Retransmission reQuest-ACKnowledgement/Non-ACKnowledgement；ＨＡＲＱ−ＡＣＫ）送信のための第１のＴＴＩ長の第１の物理上りリンク制御チャネル（Physical Uplink Control CHannel；ＰＵＣＣＨ）の送信時点とＳＲ送信のための第２のＰＵＣＣＨの送信時点とが重なる場合、
第１のＰＵＣＣＨで前記ＨＡＲＱ−ＡＣＫを送信し、
前記第１のＰＵＣＣＨは、第２のＰＵＣＣＨよりも少ない数のシンボルからなり、前記第１のＰＵＣＣＨが有効なＳＲリソースを有しない場合、前記ＳＲは送信されない、端末。
【請求項１０】
前記第１のＰＵＣＣＨが有効なＳＲリソースを有する場合、前記ＳＲは前記第１のＰＵＣＣＨで送信される、請求項９に記載の端末。
【請求項１１】
前記ＳＲは、上りリンク承認の不要な上りリンク送信に対する要求又はリソース設定要求を有する、請求項９に記載の端末。
【請求項１２】
前記ＳＲは複数のビットで表現され、前記複数のビットで表現される各状態は、前記上りリンク送信に関連するＨＡＲＱプロセス番号に関係付けられる、請求項１１に記載の端末。
【請求項１３】
前記ＳＲは複数のビットで表現され、前記複数のビットと前記上りリンク送信が送信されるリソースとの組み合わせによって、前記上りリンク送信に関連するＨＡＲＱプロセス番号が決定される、請求項１１に記載の端末。
【請求項１４】
前記ＳＲ及び前記ＨＡＲＱ−ＡＣＫの送信時点とバッファ状態報告（Buffer State Report；ＢＳＲ）の送信時点とが重なる場合、
前記ＳＲ、前記ＨＡＲＱ−ＡＣＫ及び前記ＢＳＲのうち２種類の情報がバンドリングされて、送信される変調シンボルの状態にマッピングされる、請求項９に記載の端末。
【請求項１５】
前記ＳＲ及び前記ＨＡＲＱ−ＡＣＫの送信時点とバッファ状態報告（Buffer State Report；ＢＳＲ）の送信時点とが重なる場合、
変更されたＰＵＣＣＨフォーマットを用いるか、又はより多くのリソースブロックを用いて、前記ＳＲ、前記ＨＡＲＱ−ＡＣＫ及び前記ＢＳＲがいずれも第１のＰＵＣＣＨ上で送信される、請求項９に記載の端末。
【請求項１６】
前記ＳＲは、特定のサービス又は特定の要求事項のためのものであり、前記有効なＳＲリソースの時間間隔又は周期は、通常のデータトラフィックのためのＳＲリソースの時間間隔又は周期より短い、請求項９に記載の端末。
【請求項１７】
無線通信システムにおいて、複数の送信時間間隔（Transmission Time Interval；ＴＴＩ）長をサポートする端末のためのスケジューリング要求（Scheduling Request；ＳＲ）受信方法であって、前記方法は基地局によって行われ、
下りリンクデータを送信するステップと、
前記下りリンクデータに対応するハイブリッド自動再送要求確認応答（Hybrid Automatic Retransmission reQuest-ACKnowledgement/Non-ACKnowledgement；ＨＡＲＱ−ＡＣＫ）送信のための第１のＴＴＩ長の第１の物理上りリンク制御チャネル（Physical Uplink Control CHannel；ＰＵＣＣＨ）の送信時点とＳＲ送信のための第２のＰＵＣＣＨの送信時点とが重なる場合、
第１のＰＵＣＣＨで前記ＨＡＲＱ−ＡＣＫを受信するステップと、を有し、
前記第１のＰＵＣＣＨは、第２のＰＵＣＣＨよりも少ない数のシンボルからなり、前記第１のＰＵＣＣＨが有効なＳＲリソースを有しない場合、前記ＳＲは受信されない、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信システムに関し、詳細には、複数の送信時間間隔、複数のサブキャリア間隔、又は複数の処理時間（プロセッシング時間）（processing times）をサポート（支援）する（supporting）方法及びそのための装置に関する。
【背景技術】
【０００２】
パケットデータのレイテンシは、重要な性能メトリック（メートル）（metric）の１つであり、これを減らして、より早いインターネットアクセスをエンド（最終）ユーザ（end user）に提供することは、ＬＥＴのみならず、次世代移動通信システム、いわゆる新しいＲＡＴ（ラット）（新しい無線アクセス技術）（new RAT）の設計においても重要な課題の１つといえる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
本発明は、複数の送信時間間隔、複数のサブキャリア間隔、又は複数の処理時間をサポートする端末の上りリンク送信動作又はそれと通信する基地局の上りリンク受信動作に関する。
【０００４】
本発明で達成し（遂げ）ようとする技術的課題は、以上で言及した事項に限定されず、言及していない別の技術的課題は、以下に説明する本発明の実施例から、本発明の属する技術分野における通常の知識を有する者に明確に理解されるであろう。
【課題を解決するための手段】
【０００５】
本発明の一実施例による無線通信システムにおいて、複数の送信時間間隔（Transmission Time Interval；ＴＴＩ）長をサポートする端末のためのスケジューリング要求（要請）（Scheduling Request；ＳＲ）送信方法であって、この方法は端末によって行われ、下りリンクデータを受信するステップと、下りリンクデータに対応するハイブリッド自動再送要求確認応答／否定応答（Hybrid Automatic Retransmission reQuest-ACKnowledgement/Non-ACKnowledgement；ＨＡＲＱ-ＡＣＫ）送信のための第１のＴＴＩ長の第１の物理上りリンク制御チャネル（Physical Uplink Control Channel；ＰＵＣＣＨ）の送信時点とＳＲ送信のための第２のＰＵＣＣＨの送信時点とが重なる場合、第１のＰＵＣＣＨでＨＡＲＱ−ＡＣＫを送信するステップと、を有してもよい。第１のＰＵＣＣＨは、第２のＰＵＣＣＨよりも少ない数のシンボルからなり、第１のＰＵＣＣＨが有効なＳＲリソースを有しない場合、ＳＲは送信されなくてもよい。ここで、第１のＰＵＣＣＨが有効なＳＲリソースを有する場合、ＳＲは、第１のＰＵＣＣＨで送信されてもよい。
【０００６】
追加又は代案として、ＳＲは、上りリンク承認の不要な上りリンク送信に対する要求又はリソース設定要求を有してもよい。
【０００７】
追加又は代案として、ＳＲは複数のビットで表現され、複数のビットで表現される各状態は、上りリンク送信に関連するＨＡＲＱプロセス番号に関係付けられ（連動され）（linked）てもよい。
【０００８】
追加又は代案として、ＳＲは複数のビットで表現され、複数のビットと上りリンク送信が送信されるリソースとの組み合わせによって、上りリンク送信に関連するＨＡＲＱプロセス番号が決定されてもよい。
【０００９】
追加又は代案として、ＳＲ及びＨＡＲＱ−ＡＣＫの送信時点とバッファ状態報告（Buffer State Report；ＢＳＲ）の送信時点とが重なる場合、ＳＲ、ＨＡＲＱ−ＡＣＫ及びＢＳＲのうち２種類の情報がバンドリングされて、送信される変調シンボルの状態にマッピングされてもよい。
【００１０】
追加又は代案として、ＳＲ及びＨＡＲＱ−ＡＣＫの送信時点とバッファ状態報告（Buffer State Report；ＢＳＲ）の送信時点とが重なる場合、変更されたＰＵＣＣＨフォーマットを用いるか、又はより多くのリソースブロックを用いて、ＳＲ、ＨＡＲＱ−ＡＣＫ及びＢＳＲがいずれも第１のＰＵＣＣＨ上で送信されてもよい。
【００１１】
追加又は代案として、ＳＲは、特定のサービス又は特定の要求事項のためのものであり、有効なＳＲリソースの時間間隔又は周期は、通常のデータトラフィックのためのＳＲリソースの時間間隔又は周期より短くてもよい。
【００１２】
本発明の別の一実施例による無線通信システムにおいて、複数の送信時間間隔（Transmission Time Interval；ＴＴＩ）長をサポートする端末のためのスケジューリング要求（Scheduling Request；ＳＲ）を送信する端末であって、端末は、受信器及び送信器と、受信器及び送信器を制御するプロセッサと、を有し、下りリンクデータを受信して、下りリンクデータに対応するハイブリッド自動再送要求確認応答／否定応答（Hybrid Automatic Retransmission Request-Acknowledgement/Non-Acknowledgement；ＨＡＲＱ−ＡＣＫ）送信のための第１のＴＴＩ長の第１の物理上りリンク制御チャネル（Physical Uplink Control Channel；ＰＵＣＣＨ）の送信時点とＳＲ送信のための第２のＰＵＣＣＨの送信時点とが重なる場合、第１のＰＵＣＣＨでＨＡＲＱ−ＡＣＫを送信し、第１のＰＵＣＣＨは、第２のＰＵＣＣＨよりも少ない数のシンボルからなり、第１のＰＵＣＣＨが有効なＳＲリソースを有しない場合、ＳＲは送信されなくてもよい。
【００１３】
追加又は代案として、ＳＲは、上りリンク承認の不要な上りリンク送信に対する要求又はリソース設定要求を有してもよい。
【００１４】
追加又は代案として、ＳＲは複数のビットで表現され、複数のビットで表現される各状態は、上りリンク送信に関連するＨＡＲＱプロセス番号に関係付けられてもよい。
【００１５】
追加又は代案として、ＳＲは複数のビットで表現され、複数のビットと上りリンク送信が送信されるリソースとの組み合わせによって、上りリンク送信に関連するＨＡＲＱプロセス番号が決定されてもよい。
【００１６】
追加又は代案として、ＳＲ及びＨＡＲＱ−ＡＣＫの送信時点とバッファ状態報告（Buffer State Report；ＢＳＲ）の送信時点とが重なる場合、ＳＲ、ＨＡＲＱ−ＡＣＫ及びＢＳＲのうち２種類の情報がバンドリングされて、送信される変調シンボルの状態にマッピングされてもよい。
【００１７】
追加又は代案として、ＳＲ及びＨＡＲＱ−ＡＣＫの送信時点とバッファ状態報告（Buffer State Report；ＢＳＲ）の送信時点とが重なる場合、変更されたＰＵＣＣＨフォーマットを用いるか、又はより多くのリソースブロックを用いて、ＳＲ、ＨＡＲＱ−ＡＣＫ及びＢＳＲがいずれも第１のＰＵＣＣＨ上で送信されてもよい。
【００１８】
追加又は代案として、ＳＲは、特定のサービス又は特定の要求事項のためのものであり、有効なＳＲリソースの時間間隔又は周期は、通常のデータトラフィックのためのＳＲリソースの時間間隔又は周期より短くてもよい。
【００１９】
本発明の別の一実施例による無線通信システムにおいて、複数のＴＴＩ（Transmission Time Interval）長をサポートする端末のためのスケジューリング要求（Scheduling Request；ＳＲ）受信方法であって、この方法は基地局によって行われ、下りリンクデータを送信するステップと、下りリンクデータに対応するハイブリッド自動再送要求確認応答／否定応答（Hybrid Automatic Retransmission Request-Acknowledgement/Non-Acknowledgement；ＨＡＲＱ−ＡＣＫ）送信のための第１のＴＴＩ長の第１の物理上りリンク制御チャネル（Physical Uplink Control Channel；ＰＵＣＣＨ）の送信時点とＳＲ送信のための第２のＰＵＣＣＨの送信時点とが重なる場合、第１のＰＵＣＣＨでＨＡＲＱ−ＡＣＫを受信するステップと、を有し、第１のＰＵＣＣＨは、第２のＰＵＣＣＨよりも少ない数のシンボルからなり、第１のＰＵＣＣＨが有効なＳＲリソースを有しない場合、ＳＲは受信されなくてもよい。
【００２０】
上述した本発明の様態は、本発明の好適な実施例の一部に過ぎず、本願発明の技術的特徴が反映された様々な実施例が、当該技術の分野における通常の知識を有する者にとって、以下に詳述する本発明の詳細な説明に基づいて導出され理解され得るだろう。
【発明の効果】
【００２１】
本発明の実施例によれば、複数のＴＴＩ長、複数のサブキャリア間隔、又は複数の処理時間をサポートする端末の上りリンク送信が効率的に行われることができる。
【００２２】
本発明から得られる効果は、以上で言及した効果に制限されず、言及していない他の効果は、以下の記載から、本発明の属する技術分野における通常の知識を有する者に明確に理解されるであろう。
【図面の簡単な説明】
【００２３】
【図１】無線通信システムにおいて用いられる無線フレーム構造の一例を示す図である。
【図２】無線通信システムにおける下りリンク／上りリンク（ＤＬ／ＵＬ）スロット構造の一例を示す図である。
【図３】３ＧＰＰ  ＬＴＥ／ＬＴＥ−Ａシステムにおいて用いられる下りリンク（Downlink，ＤＬ）サブフレームの構造を例示する図である。
【図４】３ＧＰＰ  ＬＴＥ／ＬＴＥ−Ａシステムにおいて用いられる上りリンク（Uplink，ＵＬ）サブフレームの構造を例示する図である。
【図５】ユーザプレーン（平面）（user plane）レイテンシの減少によるＴＴＩ長の減少を示す図である。
【図６】１つのサブフレーム内に複数の短いＴＴＩが設定された例を示す図である。
【図７】複数の長さ（シンボル数）の短いＴＴＩからなるＤＬサブフレームの構造を示す図である。
【図８】２個のシンボル又は３個のシンボルの短いＴＴＩからなるＤＬサブフレーム構造を示す図である。
【図９】本発明の実施例を具現するための装置を示すブロック図である。
【発明を実施するための形態】
【００２４】
添付する図面は、本発明に関する理解を助けるために詳細な説明の一部として含まれるものであり、本発明に関する実施例を提供し、詳細な説明と共に本発明の技術的思想を説明する。
【００２５】
以下、本発明に係る好適な実施形態を、添付の図面を参照して詳しく説明する。添付の図面と共に以下に開示される詳細な説明は、本発明の例示的な実施形態を説明するためのものであり、本発明が実施し得る唯一の実施形態を示すためのものではない。以下の詳細な説明は、本発明の完全な理解を提供するために具体的な細部事項を含む。しかしながら、当業者にとってはこのような具体的な細部事項無しでも本発明を実施できることは明らかである。
【００２６】
場合によっては、本発明の概念が曖昧になることを避けるために、公知の構造及び装置を省略したり、各構造及び装置の中核機能を中心にしたブロック図の形式で示すことができる。また、本明細書全体にわたって同一の構成要素については、同一の図面符号を付して説明する。
【００２７】
本発明において、ユーザ機器（user equipment，ＵＥ）は、固定していても、モビリティ（移動性）を有し（mobile）ていてもよいもので、基地局（Base Station，ＢＳ）と通信してユーザデータ及び／又は各種制御情報を送受信する各種機器を含む。ＵＥを、端末（Terminal Equipment）、ＭＳ（Mobile Station）、ＭＴ（Mobile Terminal）、ＵＴ（User Terminal）、ＳＳ（Subscribe Station）、無線機器（wireless device）、ＰＤＡ（Personal Digital Assistant）、無線モデム（wireless modem）、携帯機器（handheld device）などと呼ぶこともできる。また、本発明において、ＢＳは、一般に、ＵＥ及び／又は他のＢＳと通信する固定局（fixed station）を意味し、ＵＥ及び他のＢＳと通信して各種データ及び制御情報を交換する。ＢＳを、ＡＢＳ（Advanced Base Station）、ＮＢ（Node-B）、ｅＮＢ（evolved-NodeB）、ＢＴＳ（Base Transceiver System）、アクセスポイント（Access Point）、ＰＳ（Processing Server）、送信ポイント（Transmission Point；ＴＰ）などと呼ぶこともできる。以下の本発明に関する説明では、ＢＳをｅＮＢと総称する。
【００２８】
本発明におけるノード（node）とは、ユーザ機器と通信して無線信号を送信／受信できる固定したポイント（地点）（point）を指す。様々な形態のｅＮＢをその名称にかかわらずノードとして用いることができる。例えば、ＢＳ、ＮＢ、ｅＮＢ、ピコセルｅＮＢ（ＰｅＮＢ）、ホームｅＮＢ（ＨｅＮＢ）、リレー、リピータなどをノードとすることができる。また、ノードは、ｅＮＢでなくてもよい。例えば、無線リモートヘッド（Radio Remote Head，ＲＲＨ）、無線リモートユニット（Radio Remote Unit，ＲＲＵ）であってもよい。ＲＲＨ、ＲＲＵなどは、一般にｅＮＢの電力レベル（power level）よりも低い電力レベルを有する。ＲＲＨ又はＲＲＵ（以下、ＲＲＨ／ＲＲＵ）は、一般に、光ケーブルなどの専用回線（dedicated line）でｅＮＢに接続されており、よって、一般に無線回線で接続されているｅＮＢによる協調通信に比べて、ＲＲＨ／ＲＲＵとｅＮＢとによる協調通信を円滑に行うことができる。１つのノードには、少なくとも１つのアンテナが設置される。このアンテナは、物理アンテナを意味することもでき、アンテナポート、仮想アンテナ、又はアンテナグループを意味することもできる。ノードは、ポイント（point）と呼ばれることもある。アンテナが基地局に集中して位置して１つのｅＮＢコントローラ（controller）によって制御される既存の（conventional）中央集中型アンテナシステム（Centralized Antenna System，ＣＡＳ）（すなわち、単一ノードシステム）と違い、マルチ（多重）ノードシステム（multi-node system）において、複数のノードは、一般に一定間隔以上離れて位置する。これらの複数のノードは、各ノードの動作を制御したり、各ノードを通して送／受信されるデータをスケジューリング（scheduling）する１つ又は複数のｅＮＢ又はｅＮＢコントローラによって管理することができる。各ノードは、当該ノードを管理するｅＮＢ又はｅＮＢコントローラと、ケーブル（cable）又は専用回線（dedicated line）で接続することができる。マルチノードシステムにおいて、複数のノードへの／からの信号の送信／受信には、同一のセル識別子（IDentity，ＩＤ）が用いられてもよく、異なるセルＩＤが用いられてもよい。複数のノードが同一のセルＩＤを有すると、これらの複数のノードのそれぞれは、１つのセルにおける１つ（一部）のアンテナグループ（集団）（group）のように動作する。マルチノードシステムにおいて、ノードが互いに異なるセルＩＤを有すると、このようなマルチノードシステムをマルチセル（例えば、マクロセル／フェムトセル／ピコセル）システムと見なすことができる。複数のノードのそれぞれが形成したマルチセルが、カバレッジによってオーバーレイする形態で構成されると、これらのマルチセルが形成したネットワークを特にマルチレイヤ（多重−階層）（multi-tier）ネットワークと呼ぶ。ＲＲＨ／ＲＲＵのセルＩＤとｅＮＢのセルＩＤとは同一であっても、異なってもよい。ＲＲＨ／ＲＲＵとｅＮＢとが互いに異なるセルＩＤを用いる場合、ＲＲＨ／ＲＲＵとｅＮＢとは、いずれも独立した基地局として動作する。
【００２９】
以下に説明する本発明のマルチノードシステムにおいて、複数のノードに接続した１つ又は複数のｅＮＢ又はｅＮＢコントローラが、上記複数のノードの一部又は全てを介してＵＥに同時に信号を送信又は受信するように、上記複数のノードを制御することができる。各ノードの実体、各ノードの具現の形態などによって、マルチノードシステム間には差異があるが、複数のノードが共に所定の時間−周波数リソース上でＵＥに通信サービスを提供するために参加するという点で、これらのマルチノードシステムは、単一ノードシステム（例えば、ＣＡＳ、従来のＭＩＭＯシステム、従来の中継システム、従来のリピータシステムなど）とは異なる。そのため、複数のノードの一部又は全てを用いてデータ協調送信を行う方法に関する本発明の実施例は、種々のマルチノードシステムに適用可能である。例えば、ノードとは、通常、他のノードと一定間隔以上で離れて位置しているアンテナグループを指すが、後述する本発明の実施例は、ノードが間隔にかかわらずに任意のアンテナグループを意味する場合にも適用可能である。例えば、Ｘ−ｐｏｌ（Cross polarized）アンテナを備えたｅＮＢの場合、該ｅＮＢが、Ｈ−ｐｏｌアンテナで構成されたノードとＶ−ｐｏｌアンテナで構成されたノードとを制御すると見なし、本発明の実施例を適用することができる。
【００３０】
複数の送信（Ｔｘ）／受信（Ｒｘ）ノードを介して信号を送信／受信したり、複数の送信／受信ノードから選択された少なくとも１つのノードを介して信号を送信／受信したり、下りリンク信号を送信するノードと上りリンク信号を受信するノードとを別にし得る通信技法を、マルチ（多重−）ｅＮＢ  ＭＩＭＯ又はＣｏＭＰ（Coordinated Multi-Point TX/RX）という。このようなノード間協調通信のうち、協調送信技法は、ＪＰ（Joint Processing）とスケジューリング協調（scheduling coordination）とに区別（categorized into）できる。前者は、ＪＴ（Joint Transmission）／ＪＲ（Joint Reception）とＤＰＳ（Dynamic Point Selection）とに区別し（divided into）、後者は、ＣＳ（Coordinated Scheduling）とＣＢ（Coordinated Beamforming）とに区別できる。ＤＰＳは、ＤＣＳ（Dynamic Cell Selection）と呼ぶこともできる。他の協調通信技法に比べて、ノード間協調通信技法のうちＪＰを行うとき、より様々な通信環境を形成することができる。ＪＰにおいて、ＪＴは、複数のノードが同一のストリームをＵＥに送信する通信技法をいい、ＪＲは、複数のノードが同一のストリームをＵＥから受信する通信技法をいう。当該ＵＥ／ｅＮＢは、上記複数のノードから受信した信号を合成して上記ストリームを復元する。ＪＴ／ＪＲでは、同一のストリームが複数のノードから／に送信されるため、送信ダイバーシチ（diversity）によって信号送信の信頼度を向上させることができる。ＪＰのＤＰＳは、複数のノードから特定の規則によって選択された１つのノードを介して信号が送信／受信される通信技法をいう。ＤＰＳでは、通常、ＵＥとノードとの間のチャネル状態の良いノードが通信ノードとして選択されるはずであるため、信号送信の信頼度を向上させることができる。
【００３１】
本発明におけるセル（cell）とは、１つ又は複数のノードが通信サービスを提供する一定の地理的領域をいう。そのため、本発明で特定のセルと通信するということは、特定のセルに通信サービスを提供するｅＮＢ又はノードと通信することを意味できる。また、特定のセルの下りリンク／上りリンク信号は、該特定のセルに通信サービスを提供するｅＮＢ又はノードからの／への下りリンク／上りリンク信号を意味する。ＵＥに上り／下りリンク通信サービスを提供するセルを特にサービングセル（serving cell）という。また、特定のセルのチャネル状態／品質は、該特定のセルに通信サービスを提供するｅＮＢ又はノードとＵＥとの間に形成されたチャネル又は通信リンクのチャネル状態／品質を意味する。３ＧＰＰ  ＬＥＴ−Ａベースのシステムにおいて、ＵＥは、特定のノードからの下りリンクチャネル状態を、上記特定のノードのアンテナポートが上記特定のノードに割り当てられたチャネルＣＳＩ−ＲＳ（Channel State Information Reference Signal）リソース上で送信するＣＳＩ−ＲＳを用いて測定することができる。一般に、隣接するノードは、互いに直交するＣＳＩ−ＲＳリソース上で該当のＣＳＩ−ＲＳリソースを送信する。ＣＳＩ−ＲＳリソースが直交するということは、ＣＳＩ−ＲＳを運ぶシンボル及び副搬送波を特定するＣＳＩ−ＲＳリソース構成（resource configuration）、サブフレームオフセット（offset）及び送信周期（transmission period）などによってＣＳＩ−ＲＳが割り当てられたサブフレームを特定するサブフレーム構成（subframe configuration）、ＣＳＩ−ＲＳシーケンスのうちの少なくとも１つが互いに異なることを意味する。
【００３２】
本発明において、ＰＤＣＣＨ（Physical Downlink Control CHannel）／ＰＣＦＩＣＨ（Physical Control Format Indicator CHannel）／ＰＨＩＣＨ（Physical Hybrid automatic retransmit request Indicator CHannel）／ＰＤＳＣＨ（Physical Downlink Shared CHannel）は、それぞれ、ＤＣＩ（Downlink Control Information）／ＣＦＩ（Control Format Indicator）／下りリンクＡＣＫ／ＮＡＣＫ（ACKnowlegement／Negative ACK）／下りリンクデータを運ぶ時間−周波数リソースの集合又はリソース要素の集合を意味する。また、ＰＵＣＣＨ（Physical Uplink Control CHannel）／ＰＵＳＣＨ（Physical Uplink Shared CHannel）／ＰＲＡＣＨ（Physical Random Access CHannel）は、それぞれ、ＵＣＩ（Uplink Control Information）／上りリンクデータ／ランダムアクセス信号を運ぶ時間−周波数リソースの集合又はリソース要素の集合を意味する。本発明では、特に、ＰＤＣＣＨ／ＰＣＦＩＣＨ／ＰＨＩＣＨ／ＰＤＳＣＨ／ＰＵＣＣＨ／ＰＵＳＣＨ／ＰＲＡＣＨに割り当てられたり、又はそれに属した時間−周波数リソース又はリソース要素（Resource Element，ＲＥ）を、それぞれ、ＰＤＣＣＨ／ＰＣＦＩＣＨ／ＰＨＩＣＨ／ＰＤＳＣＨ／ＰＵＣＣＨ／ＰＵＳＣＨ／ＰＲＡＣＨ  ＲＥ又はＰＤＣＣＨ／ＰＣＦＩＣＨ／ＰＨＩＣＨ／ＰＤＳＣＨ／ＰＵＣＣＨ／ＰＵＳＣＨ／ＰＲＡＣＨリソースと呼ぶ。以下で、ユーザ機器がＰＵＣＣＨ／ＰＵＳＣＨ／ＰＲＡＣＨを送信するという表現は、それぞれ、ＰＵＳＣＨ／ＰＵＣＣＨ／ＰＲＡＣＨ上で又はこれを介して、上りリンク制御情報／上りリンクデータ／ランダムアクセス信号を送信するという表現と同じ意味で使われる。また、ｅＮＢがＰＤＣＣＨ／ＰＣＦＩＣＨ／ＰＨＩＣＨ／ＰＤＳＣＨを送信するという表現は、それぞれ、ＰＤＣＣＨ／ＰＣＦＩＣＨ／ＰＨＩＣＨ／ＰＤＳＣＨ上で又はこれを介して、下りリンクデータ／制御情報を送信するという表現と同じ意味で使われる。
【００３３】
図１は、無線通信システムで用いられる無線フレーム構造の一例を示す図である。特に、図１（ａ）は、３ＧＰＰ  ＬＥＴ／ＬＥＴ−Ａシステムで用いられる周波数分割デュプレックス（Frequency Division Duplex，ＦＤＤ）用フレーム構造を示しており、図１（ｂ）は、３ＧＰＰ  ＬＥＴ／ＬＥＴ−Ａシステムで用いられる時間分割デュプレックス（Time Division Duplex，ＴＤＤ）用フレーム構造を示している。
【００３４】
図１を参照すると、３ＧＰＰ  ＬＥＴ／ＬＥＴ−Ａシステムで用いられる無線フレームは、１０ｍｓ（３０７２００Ｔｓ）の長さを有し、１０個の均等なサイズのサブフレーム（Subframe，ＳＦ）で構成される。１つの無線フレームにおける１０個のサブフレームには、それぞれ番号を与えることができる。ここで、Ｔｓは、サンプリング時間を表し、Ｔｓ＝１／（２０４８＊１５ｋＨｚ）で表される（represented）。それぞれのサブフレームは、１ｍｓの長さを有し、２個のスロットで構成される。１つの無線フレームにおいて、２０個のスロットには、０から１９までの番号を順次与えることができる。それぞれのスロットは０．５ｍｓの長さを有する。１サブフレームを送信するための時間は、送信時間間隔（Transmission Time Interval，ＴＴＩ）として定義される。時間リソースは、無線フレーム番号（又は、無線フレームインデックスともいう）、サブフレーム番号（又は、サブフレームインデックスともいう）、スロット番号（又は、スロットインデックスともいう）などによって区別する（discriminated）ことができる。
【００３５】
無線フレームは、デュプレックス（duplex）技法によって別々に構成（configure）することができる。例えば、ＦＤＤにおいて、下りリンク送信及び上りリンク送信は周波数によって区別されるため、無線フレームは、特定の周波数帯域に対して下りリンクサブフレーム又は上りリンクサブフレームのいずれか１つのみを含む。ＴＤＤでは下りリンク送信及び上りリンク送信が時間によって区別されるため、特定の周波数帯域に対して、無線フレームは、下りリンクサブフレームも上りリンクサブフレームも含む。
【００３６】
表１は、ＴＤＤにおいて、無線フレームにおけるサブフレームのＤＬ−ＵＬ構成（configuration）を例示するものである。
【００３７】
＜表１＞
【表１】
2019530382.tif 000003
【００３８】
表１において、Ｄは下りリンクサブフレームを、Ｕは上りリンクサブフレームを、Ｓはスペシャル（特異）（special）サブフレームを表す。スペシャルサブフレームは、ＤｗＰＴＳ（Downlink Pilot Time Slot）、ＧＰ（Guard Period）、ＵｐＰＴＳ（Uplink Pilot Time Slot）の３つのフィールドを含む。ＤｗＰＴＳは、下りリンク送信のためにリザーブ（留保）される（reserved）時間区間であり、ＵｐＰＴＳは、上りリンク送信のためにリザーブされる時間区間である。表２は、スペシャルサブフレーム構成（configuration）を例示するものである。
【００３９】
＜表２＞
【表２】
2019530382.tif 000004
【００４０】
図２は、無線通信システムにおいて下りリンク／上りリンク（ＤＬ／ＵＬ）スロット構造の一例を示す図である。特に、図２は、３ＧＰＰ  ＬＥＴ／ＬＥＴ−Ａシステムのリソースグリッド（格子）（resource grid）の構造を示す。アンテナポート当たり１個のリソースグリッドがある。
【００４１】
図２を参照すると、スロットは、時間領域（ドメイン）（time domain）で複数のＯＦＤＭ（Orthogonal Frequency Division Multiplexing）シンボルを含み、周波数領域（ドメイン）（frequency domain）で複数のリソースブロック（Resource Block，ＲＢ）を含む。ＯＦＤＭシンボルは、１シンボル区間を意味することもある。図２を参照すると、各スロットで送信される信号は、
2019530382.tif 000005
*
2019530382.tif 000006
個の副搬送波（subcarrier）と
2019530382.tif 000007
個のＯＦＤＭシンボルとで構成されるリソースグリッド（resource grid）として表現することができる。ここで、
2019530382.tif 000008
は、下りリンクスロットにおけるリソースブロック（Resource Block，ＲＢ）の個数を表し、
2019530382.tif 000009
は、ＵＬスロットにおけるＲＢの個数を表す。
2019530382.tif 000010
及び
2019530382.tif 000011
は、ＤＬ送信帯域幅及びＵＬ送信帯域幅にそれぞれ依存する。
2019530382.tif 000012
は、下りリンクスロットにおけるＯＦＤＭシンボルの個数を表し、
2019530382.tif 000013
は、ＵＬスロットにおけるＯＦＤＭシンボルの個数を表す。
2019530382.tif 000014
は、１つのＲＢを構成する副搬送波の個数を表す。
【００４２】
ＯＦＤＭシンボルは、多元接続（多重接続）（multiple access）方式によって、ＯＦＤＭシンボル、ＳＣ−ＦＤＭ（Single Carrier Frequency Division Multiplexing）シンボルなどと呼ぶことができる。１つのスロットに含まれるＯＦＤＭシンボルの数は、チャネル帯域幅、ＣＰ（Cyclic Prefix）長によって様々に変更可能である。例えば、ノーマル（正規）（normal）ＣＰの場合は、１つのスロットが７個のＯＦＤＭシンボルを含むが、拡張（extended）ＣＰの場合は、１つのスロットが６個のＯＦＤＭシンボルを含む。図２では、説明の便宜のために、１つのスロットが７個のＯＦＤＭシンボルで構成されるサブフレームを例示するが、本発明の実施例は、その他の個数のＯＦＤＭシンボルを有するサブフレームにも同様の方式で適用されてもよい。図２を参照すると、各ＯＦＤＭシンボルは、周波数領域で、
2019530382.tif 000015
*
2019530382.tif 000016
個の副搬送波を含む。副搬送波のタイプ（類型）（type）は、データ送信のためのデータ副搬送波、参照信号（reference signal）の送信のための参照信号副搬送波、ガードバンド（guard band）及び直流（Direct Current，ＤＣ）成分のためのヌル（null）副搬送波に分類することができる。ＤＣ成分のためのヌル副搬送波は、未使用のまま残される副搬送波であり、ＯＦＤＭ信号生成過程又は周波数アップ（上り）変換（up-conversion）過程で搬送波周波数（carrier frequency，ｆ０）にマッピング（mapping）される。搬送波周波数は、中心周波数（center frequency）と呼ばれることもある。
【００４３】
１つのＲＢは、時間領域で
2019530382.tif 000017
個（例えば、７個）の連続するＯＦＤＭシンボルとして定義され、周波数領域で
2019530382.tif 000018
個（例えば、１２個）の連続する副搬送波として定義される。参考として、１つのＯＦＤＭシンボルと１つの副搬送波とで構成されたリソースをリソース要素（Resource Element，ＲＥ）又はトーン（tone）という。したがって、１つのＲＢは、
2019530382.tif 000019
*
2019530382.tif 000020
個のリソース要素で構成される。リソースグリッドにおける各リソース要素は、１つのスロットにおけるインデックス対（ｋ，１）によって一意に（固有に）（uniquely）定義できる。ｋは、周波数領域で０から
2019530382.tif 000021
*
2019530382.tif 000022
−１まで与えられるインデックスであり、ｌは、時間領域で０から
2019530382.tif 000023
−１まで与えられるインデックスである。
【００４４】
１サブフレームにおいて
2019530382.tif 000024
個の連続した同一副搬送波を占有し、当該サブフレームにおける２個のスロットのそれぞれに１個ずつ位置する２個のＲＢを、物理リソースブロック（Physical Resource Block，ＰＲＢ）対（pair）という。ＰＲＢ対を構成する２個のＲＢは、同一のＰＲＢ番号（又は、ＰＲＢインデックス（index）ともいう）を有する。ＶＲＢは、リソース割り当てのために導入された一種の論理的リソース割り当て単位である。ＶＲＢは、ＰＲＢと同じサイズを有する。ＶＲＢをＰＲＢにマッピングする方式によって、ＶＲＢは、局所（局部）（localized）タイプのＶＲＢと分散（distributed）タイプのＶＲＢとに区別される。局所タイプのＶＲＢは、ＰＲＢに直接マッピングされて、ＶＲＢ番号（ＶＲＢインデックスともいう）がＰＲＢ番号に直接対応する。すなわち、ｎPRB＝ｎVRBとなる。局所タイプのＶＲＢには、０から
2019530382.tif 000025
−１まで順に番号が与えられ、
2019530382.tif 000026
＝
2019530382.tif 000027
である。したがって、局所マッピング方式によれば、同一のＶＲＢ番号を有するＶＲＢが１番目のスロットと２番目のスロットとにおいて、同一のＰＲＢ番号のＰＲＢにマッピングされる。一方、分散タイプのＶＲＢは、インターリーブを経てＰＲＢにマッピングされる。そのため、同一のＶＲＢ番号を有する分散タイプのＶＲＢは、１番目のスロットと２番目のスロットとにおいて互いに異なる番号のＰＲＢにマッピングされることがある。サブフレームの２つのスロットに１個ずつ位置し、同一のＶＲＢ番号を有する２個のＰＲＢをＶＲＢ対と称する。
【００４５】
図３は、３ＧＰＰ  ＬＥＴ／ＬＥＴ−Ａシステムで用いられる下りリンク（Downlink，ＤＬ）サブフレーム構造を例示する図である。
【００４６】
図３を参照すると、ＤＬサブフレームは、時間領域で制御領域（control region）とデータ領域（data region）とに区別される。図３を参照すると、サブフレームの第１のスロットで先頭部における最大３（又は４）個のＯＦＤＭシンボルは、制御チャネルが割り当てられる制御領域（control region）に対応する。以下、ＤＬサブフレームでＰＤＣＣＨ送信に利用可能なリソース領域（resource region）をＰＤＣＣＨ領域と称する。制御領域に用いられるＯＦＤＭシンボル以外のＯＦＤＭシンボルは、ＰＤＳＣＨ（Physical Downlink Shared CHannel）が割り当てられるデータ領域（data region）に該当する。以下、ＤＬサブフレームでＰＤＳＣＨ送信に利用可能なリソース領域をＰＤＳＣＨ領域と称する。３ＧＰＰ  ＬＥＴで用いられるＤＬ制御チャネルの例としては、ＰＣＦＩＣＨ（Physical Control Format Indicator Channel）、ＰＤＣＣＨ（Physical Downlink Control Channel）、ＰＨＩＣＨ（Physical hybrid ARQ indicator Channel）などを含む。ＰＣＦＩＣＨは、サブフレームの最初のＯＦＤＭシンボルで送信され、サブフレームにおいて制御チャネルの送信に用いられるＯＦＤＭシンボルの個数に関する情報を運ぶ。ＰＨＩＣＨは、ＵＬ送信に対する応答としてＨＡＲＱ（Hybrid Automatic Repeat Request）ＡＣＫ／ＮＡＣＫ（acknowledgment/negative-acknowledgment）信号を運ぶ。
【００４７】
ＰＤＣＣＨを介して送信される制御情報を下りリンク制御情報（Downlink Control Information，ＤＣＩ）と呼ぶ。ＤＣＩは、ＵＥ又はＵＥグループのためのリソース割り当て情報及び他の制御情報を含む。例えば、ＤＣＩは、ＤＬ共有チャネル（Downlink Shared Channel，ＤＬ−ＳＣＨ）の送信フォーマット及びリソース割り当て情報、ＵＬ共有チャネル（Uplink Shared Channel，ＵＬ−ＳＣＨ）の送信フォーマット及びリソース割り当て情報、ページングチャネル（Paging Channel，ＰＣＨ）上のページング情報、ＤＬ−ＳＣＨ上のシステム情報、ＰＤＳＣＨ上で送信されるランダムアクセス応答などの上位層（upper layer）制御メッセージのリソース割り当て情報、ＵＥグループ内の個別ＵＥへの送信電力制御命令（セット）（Transmit Control Command Set）、送信電力制御（Transmit Power Control）命令、ＶｏＩＰ（Voice over IP）の活性化（activation）指示情報、ＤＡＩ（Downlink Assignment Index）などを含む。ＤＬ共有チャネル（Downlink Shared Channel，ＤＬ−ＳＣＨ）の送信フォーマット（Transmit Format）及びリソース割り当て情報は、ＤＬスケジューリング情報又はＤＬグラント（DL grant）とも呼ばれ、ＵＬ共有チャネル（Uplink Shared Channel，ＵＬ−ＳＣＨ）の送信フォーマット及びリソース割り当て情報は、ＵＬスケジューリング情報又はＵＬグラント（UL grant）とも呼ばれる。１つのＰＤＣＣＨが運ぶＤＣＩは、ＤＣＩフォーマットによってそのサイズ及び用途が異なり、符号化率によってそのサイズが異なり得る。現在、３ＧＰＰ  ＬＥＴシステムでは、上りリンク用にフォーマット０及び４、下りリンク用にフォーマット１、１Ａ、１Ｂ、１Ｃ、１Ｄ、２、２Ａ、２Ｂ、２Ｃ、３、３Ａなどの様々なフォーマットが定義されている。ＤＣＩフォーマットのそれぞれの用途に応じて、ホッピングフラグ、ＲＢ割り当て（RB allocation）、ＭＣＳ（Modulation Coding Scheme）、ＲＶ（Redundancy Version）、ＮＤＩ（New Data Indicator）、ＴＰＣ（Transmit Power Control）、巡回（循環）シフトＤＭＲＳ（Cyclic Shift Demodulation Reference Signal）、ＵＬインデックス、ＣＱＩ（Channel Quality Information）要求、ＤＬ割り当てインデックス（DL assignment index）、ＨＡＲＱプロセスナンバ、ＴＰＭＩ（Transmitted Precoding Matrix Indicator）、ＰＭＩ（Precoding Matrix Indicator）情報などの制御情報が適宜選択された組み合わせが、下りリンク制御情報としてＵＥに送信される。
【００４８】
一般に、ＵＥに対して構成された送信モード（Transmission Mode，ＴＭ）によって、当該ＵＥに送信可能なＤＣＩフォーマットが異なる。換言すれば、特定の送信モードに構成されたＵＥのためには、いかなるＤＣＩフォーマットを用いてもよいわけではなく、特定の送信モードに対応する一定のＤＣＩフォーマットのみを用いることができる。
【００４９】
ＰＤＣＣＨは、１つ又は複数の連続した制御チャネル要素（Control Channel Element，ＣＣＥ）のアグリゲーション（集約、集成）（aggregation）上で送信される。ＣＣＥは、ＰＤＣＣＨに無線チャネル状態に基づく符号化率（coding rate）を提供するために用いられる論理的割り当てユニット（unit）である。ＣＣＥは、複数のリソース要素グループ（Resource Element Group，ＲＥＧ）に対応する。例えば、１つのＣＣＥは９個のＲＥＧに対応し、１つのＲＥＧは４個のＲＥに対応する。３ＧＰＰ  ＬＥＴシステムの場合、それぞれのＵＥのためにＰＤＣＣＨが位置してもよいＣＣＥセットを定義した。ＵＥが自体のＰＤＣＣＨを発見し得るＣＣＥセットを、ＰＤＣＣＨサーチスペース（探索空間）、簡単にはサーチスペース（Search Space，ＳＳ）と呼ぶ。サーチスペース内でＰＤＣＣＨが送信されてもよい個別リソースをＰＤＣＣＨ候補（candidate）と呼ぶ。ＵＥがモニタリング（monitoring）するＰＤＣＣＨ候補の集合をサーチスペースとして定義する。３ＧＰＰ  ＬＥＴ／ＬＥＴ−ＡシステムでそれぞれのＤＣＩフォーマットのためのサーチスペースは異なるサイズを有してもよく、専用（dedicated）サーチスペースと共通（common）サーチスペースとが定義されている。専用サーチスペースは、ＵＥ固有（特定）（specific）サーチスペースであり、それぞれの個別のＵＥのために構成（configuration）される。共通サーチスペースは、複数のＵＥのために構成される。以下の表は、サーチスペースを定義するアグリゲーション（集成）レベル（aggregation level）を例示するものである。
【００５０】
＜表３＞
【表３】
2019530382.tif 000028
【００５１】
１つのＰＤＣＣＨ候補は、ＣＣＥアグリゲーションレベルによって１、２、４又は８個のＣＣＥに対応する。ｅＮＢは、サーチスペース内の任意のＰＤＣＣＨ候補上で実際のＰＤＣＣＨ（ＤＣＩ）を送信し、ＵＥは、ＰＤＣＣＨ（ＤＣＩ）を探すためにサーチスペースをモニタリングする。ここで、モニタリングとは、全てのモニタリングされるＤＣＩフォーマットによって当該サーチスペース内の各ＰＤＣＣＨの復号（decoding）を試みる（attempt）ことを意味する。ＵＥは、上記複数のＰＤＣＣＨをモニタリングし、自体のＰＤＣＣＨを検出することができる。基本的に、ＵＥは、自体のＰＤＣＣＨが送信される位置を知らないことから、サブフレーム毎に当該ＤＣＩフォーマットの全てのＰＤＣＣＨに対して、自体の識別子を有するＰＤＣＣＨを検出するまで復号を試みるが、このような過程をブラインド検出（blind detection）（ブラインド復号（Blind Decoding，ＢＤ））という。
【００５２】
ｅＮＢは、データ領域を通してＵＥ又はＵＥグループのためのデータを送信することができる。データ領域を通して送信されるデータをユーザデータと呼ぶこともできる。ユーザデータの送信のために、データ領域には、ＰＤＳＣＨ（Physical Downlink Shared CHannel）を割り当てることができる。ＰＣＨ（Paging Channel）及びＤＬ−ＳＣＨ（Downlink-shared channel）は、ＰＤＳＣＨを介して送信される。ＵＥは、ＰＤＣＣＨを介して送信される制御情報を復号し、ＰＤＳＣＨを介して送信されるデータを読むことができる。ＰＤＳＣＨのデータがどのＵＥ又はＵＥグループに送信されるか、上記ＵＥ又はＵＥグループがどのようにＰＤＳＣＨデータを受信して復号すればよいか、などを示す情報がＰＤＣＣＨに含まれて送信される。例えば、特定のＰＤＣＣＨが「Ａ」というＲＮＴＩ（Radio Network Temporary Identity）でＣＲＣ（Cyclic Redundancy Check）マスク（masking）されており、「Ｂ」という無線リソース（例えば、周波数位置）及び「Ｃ」という送信形式情報（例えば、送信ブロックサイズ、変調方式、コーディング情報など）を用いて送信されるデータに関する情報が、特定のＤＬサブフレームで送信されると仮定する。ＵＥは、自体が所有しているＲＮＴＩ情報を用いてＰＤＣＣＨをモニタリングし、「Ａ」というＲＮＴＩを有しているＵＥは、ＰＤＣＣＨを検出し、受信したＰＤＣＣＨの情報によって「Ｂ」及び「Ｃ」で示されるＰＤＳＣＨを受信する。
【００５３】
ＵＥがｅＮＢから受信した信号を復調するには、データ信号と比較する参照信号（Reference Signal，ＲＳ）が必要である。参照信号とは、ｅＮＢがＵＥに又はＵＥがｅＮＢに送信する、ｅＮＢとＵＥとが互いに知っている、予め定義された特別な波形の信号を意味し、パイロット（pilot）とも呼ばれる。参照信号は、セル内の全ＵＥに共用されるセル固有（cell-specific）ＲＳと特定のＵＥに専用される復調（demodulation）ＲＳ（ＤＭ  ＲＳ）とに区別される。ｅＮＢが特定のＵＥのための下りリンクデータの復調のために送信するＤＭ  ＲＳをＵＥ固有（UE-specific）ＲＳと特別に称することもできる。下りリンクでＤＭ  ＲＳとＣＲＳとは共に送信されてもよいが、いずれか一方のみが送信されてもよい。ただし、下りリンクでＣＲＳ無しでＤＭ  ＲＳのみが送信される場合、データと同じプリコーダを適用して送信されるＤＭ  ＲＳは、復調の目的にのみ用いることができるため、チャネル測定用ＲＳを別途提供しなければならない。例えば、３ＧＰＰ  ＬＴＥ（−Ａ）では、ＵＥがチャネル状態情報を測定できるようにするために、追加の測定用ＲＳであるＣＳＩ−ＲＳが当該ＵＥに送信される。ＣＳＩ−ＲＳは、チャネル状態について相対的に時間による変化（度）が大きくないという事実に着目し、サブフレーム毎に送信されるＣＲＳとは違い、複数のサブフレームで構成される所定の送信周期毎に送信される。
【００５４】
図４は、３ＧＰＰ  ＬＥＴ／ＬＥＴ−Ａシステムで用いられる上りリンク（Uplink，ＵＬ）サブフレーム構造の一例を示す図である。
【００５５】
図４を参照すると、ＵＬサブフレームは、周波数領域で制御領域とデータ領域とに区別できる（divided）。１つ又は複数のＰＵＣＣＨ（Physical Uplink Control Channels）を、上りリンク制御情報（Uplink Control Information，ＵＣＩ）を運ぶために制御領域に割り当てることができる。１つ又は複数のＰＵＳＣＨ（Physical Uplink Shared Channels）がユーザデータを運ぶためにＵＬサブフレームのデータ領域に割り当てられてもよい。
【００５６】
ＵＬサブフレームでは、ＤＣ（Direct Current）副搬送波から遠く離れた副搬送波が制御領域として用いられる。換言すれば、ＵＬ送信帯域幅の両端部に位置する副搬送波が上りリンク制御情報の送信に割り当てられる。ＤＣ副搬送波は、信号送信に用いられずに残される成分であり、周波数アップ変換過程で搬送波周波数ｆ０にマッピングされる。１つのＵＥのＰＵＣＣＨは、１つのサブフレームで、１つの搬送波周波数で動作するリソースに属したＲＢ対に割り当てられ、このＲＢ対に属したＲＢは、２つのスロットでそれぞれ異なる副搬送波を占有する。このように割り当てられるＰＵＣＣＨを、ＰＵＣＣＨに割り当てられたＲＢ対がスロット境界で周波数ホッピングすると表現する。ただし、周波数ホッピングが適用されない場合には、ＲＢ対が同一の副搬送波を占有する。
【００５７】
ＰＵＣＣＨは、次の制御情報を送信するために用いることができる。
【００５８】
−ＳＲ（Scheduling Request）：上りリンクＵＬ−ＳＣＨリソースを要求するために用いられる情報である。ＯＯＫ（On-Off Keying）方式を用いて送信される。
【００５９】
−ＨＡＲＱ−ＡＣＫ：ＰＤＣＣＨに対する応答及び／又はＰＤＳＣＨ上の下りリンクデータパケット（例えば、コードワード）に対する応答である。ＰＤＣＣＨ又はＰＤＳＣＨが成功裏に受信されたか否かを示す。単一の下りリンクコードワードに対する応答としてＨＡＲＱ−ＡＣＫ  １ビットが送信され、２つの下りリンクコードワードに対する応答としてＨＡＲＱ−ＡＣＫ  ２ビットが送信される。ＨＡＲＱ−ＡＣＫ応答は、ポジティブＡＣＫ（単に、ＡＣＫ）、ネガティブＡＣＫ（以下、ＮＡＣＫ）、ＤＴＸ（Discontinuous Transmission）又はＮＡＣＫ／ＤＴＸを含む。ここで、ＨＡＲＱ−ＡＣＫという用語は、ＨＡＲＱ  ＡＣＫ／ＮＡＣＫ、ＡＣＫ／ＮＡＣＫと同じ意味で使われる。
【００６０】
−ＣＳＩ（Channel State Information）：下りリンクチャネルに対するフィードバック情報（feedback information）である。ＭＩＭＯ（Multiple Input Multiple Output）−関連フィードバック情報は、ＲＩ（Rank Indicator）及びＰＭＩ（Precoding Matrix Indicator）を含む。
【００６１】
ＵＥがサブフレームで送信可能な上りリンク制御情報（ＵＣＩ）の量は、制御情報送信に使用可能（可用）（available）なＳＣ−ＦＤＭＡの個数に依存する。ＵＣＩに使用可能なＳＣ−ＦＤＭＡは、サブフレームにおいて参照信号の送信のためのＳＣ−ＦＤＭＡシンボルを除く残りのＳＣ−ＦＤＭＡシンボルを意味し、ＳＲＳ（Sounding Reference Signal）が構成されているサブフレームでは、サブフレームの最後のＳＣ−ＦＤＭＡシンボルも除く。参照信号は、ＰＵＣＣＨのコヒーレント（coherent）検出に用いられる。ＰＵＣＣＨは、送信される情報によって様々なフォーマットをサポートする。
【００６２】
下記の表４に、ＬＥＴ／ＬＥＴ−ＡシステムにおけるＰＵＣＣＨフォーマットとＵＣＩとのマッピング関係を示す。
【００６３】
＜表４＞
【表４】
2019530382.tif 000029
【００６４】
表４を参照すると、主に、ＰＵＣＣＨフォーマット１系列（1/1a/1b）は、ＡＣＫ／ＮＡＣＫ情報を送信するために用いられ、ＰＵＣＣＨフォーマット２系列（2/2a/2b）は、ＣＱＩ／ＰＭＩ／ＲＩなどのチャネル状態情報（Channel State Information，ＣＳＩ）を運ぶために用いられ、ＰＵＣＣＨフォーマット３系列（3）は、ＡＣＫ／ＮＡＣＫ情報を送信するために用いられる。
【００６５】
参照信号（Reference Signal；ＲＳ）
【００６６】
無線通信システムにおいてパケットを送信するとき、パケットは無線チャネルを通じて送信されるため、送信過程で信号の歪みが発生することがある。歪んだ信号を受信側で正しく受信するためには、チャネル情報を用いて受信信号において歪みを補正しなければならない。チャネル情報を知るために、送信側と受信側との両方で知っている信号を送信し、該信号がチャネルを通じて受信されるときの歪みの度合からチャネル情報を把握する方法を主に用いる。この信号をパイロット信号（Pilot Signal）又は参照信号（Reference Signal）という。
【００６７】
マルチ（多重）アンテナ（multiple antennas）を用いてデータを送受信する場合には、各送信アンテナと各受信アンテナとの間のチャネル状況を知ってこそ正しい信号を受信することができる。したがって、各送信アンテナ別に、より詳しくはアンテナポート（antenna port）別に、異なった参照信号が存在しなければならない。
【００６８】
参照信号は、上りリンク参照信号と下りリンク参照信号とに区別できる（classified into）。現在、ＬＥＴシステムには、上りリンク参照信号として、
【００６９】
i）ＰＵＳＣＨ及びＰＵＣＣＨを通じて送信された情報のコヒーレント（coherent）な復調のためのチャネル推定のための復調参照信号（DeModulation-Reference Signal，ＤＭ−ＲＳ）、
【００７０】
ii）基地局が、ネットワークの異なる周波数における上りリンクチャネル品質を測定するためのサウンディング参照信号（Sounding Reference Signal，ＳＲＳ）、がある。
【００７１】
一方、下りリンク参照信号としては、
【００７２】
i）セル内の全ての端末が共有するセル固有参照信号（Cell-Specific Reference Signal，ＣＲＳ）、
【００７３】
ii）特定の端末だけのための端末固有参照信号（UE-Specific Reference Signal）、
【００７４】
iii）ＰＤＳＣＨが送信される場合に、コヒーレントな復調のために送信される（DeModulation-Reference Signal，ＤＭ−ＲＳ）、
【００７５】
iv）下りリンクＤＭＲＳが送信される場合に、チャネル状態情報（Channel State Information；ＣＳＩ）を伝達するためのチャネル状態情報参照信号（Channel State Information-Reference Signal，ＣＳＩ−ＲＳ）、
【００７６】
v）ＭＢＳＦＮ（Multimedia Broadcast Single Frequency Network）モードで送信される信号に対するコヒーレントな復調のために送信されるＭＢＳＦＮ参照信号（MBSFN Reference Signal）、
【００７７】
vi）端末の地理的位置情報を推定するために用いられる位置参照信号（Positioning Reference Signal）、がある。
【００７８】
参照信号は、その目的によって２種類に大別できる。チャネル情報取得のために用いられる参照信号と、データ復調のために用いられる参照信号と、がある。前者は、ＵＥが下りリンク上のチャネル情報を取得できるようにすることに目的があるため、広帯域で送信されなければならず、特定のサブフレームで下りリンクデータを受信しない端末であってもその参照信号を受信しなければならない。また、これはハンドオーバなどの状況でも用いられる。後者は、基地局が下りリンクを送るときに該当のリソースと共に送る参照信号であって、端末は、当該参照信号を受信することによってチャネル測定を行ってデータを復調することが可能になる。この参照信号は、データの送信される領域で送信されなければならない。
【００７９】
スケジューリング要求（Scheduling Request；ＳＲ）
【００８０】
ＳＲは、新たな送信のためのＵＬ−ＳＣＨリソースを要求するために用いられる。
【００８１】
ＳＲがトリガされる場合、取り消されるまでにトリガされたＳＲはペンディング（pending）とみなされる。ＭＡＣ  ＰＤＵが組み立てられ（アセンブリされ）（assembled）て、該ＰＤＵがＢＳＲをトリガした最後のイベントまでバッファ状態を含むＢＳＲを包含する場合、又はＵＬ承認が送信のために利用可能な全てのペンディングデータを受容（accommodate）することができる場合、全てのペンディングＳＲは取り消され、ｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒは停止されなければならない。
【００８２】
ＳＲがトリガされて、他のＳＲペンディングがない場合、ＭＡＣ  ＮＴＴは、ＳＲ＿ＣＯＵＮＴＥＲを０に設定する。
【００８３】
１つのＳＲがペンディング中である限り、ＭＡＣ  ＮＴＴは、各ＴＴＩのために、
【００８４】
−ＵＬ−ＳＣＨリソースがこのＴＴＩにおける送信のために利用できない場合、
【００８５】
−ＭＡＣ  ＮＴＴが、任意のＴＴＩで設定されたＳＲのための有効ＰＵＣＣＨリソースを有していない場合、ｓＰＣｅｌｌ上のランダムアクセス手続きを開始して、全てのペンディングＳＲを取り消す。  
【００８６】
−一方、ＭＡＣ  ＮＴＴが、このＴＴＩのために設定されたＳＲのための有効ＰＵＣＣＨリソースを有して、このＴＴＩが測定ギャップ（gap）の一部ではなく、ｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒが動作中ではない場合、
【００８７】
ＳＲ＿ＣＯＵＮＴＥＲ＜ｄｓｒ−ＴｒａｎｓＭａｘである場合、
【００８８】
−ＳＲ＿ＣＯＵＮＴＥＲを１だけ増加させて、
【００８９】
−物理層にＰＵＣＣＨ上のＳＲをシグナリングするように指示して、
【００９０】
−ｓｒ−ＰｒｏｈｉｂｉｔＴｉｍｅｒを開始する。
【００９１】
そうでない場合、
【００９２】
−ＲＲＣに全てのサービングセルのためのＰＵＣＣＨ／ＳＲＳをリリース（release）することを通知して、
【００９３】
−任意の設定された下りリンク割り当て及び上りリンク承認をクリア（clear）して、
【００９４】
−ＳｐＣｅｌｌ上のランダムアクセス手続きを開始して、全てのペンディングＳＲを取り消す。
【００９５】
また、上記ＳＲは、予め設定されたＰＵＣＣＨ上のスケジューリング要求用リソースから送信される。スケジューリング要求用リソースは、ｎ番目のサブフレーム毎に発生して、ＰＵＣＣＨリソースインデックスによって表現される。また、スケジューリング要求用リソースが割り当てられなかった端末のために、ＬＴＥでは、コンテンション（競合）ベースの（contention-based）スケジューリング要求方式、すなわちランダムアクセス方式もサポートする。
【００９６】
上述したレイテンシの減少、すなわち低（ロー）レイテンシ（low latency）を満たすために、データ送信の最小単位であるＴＴＩを減らして０．５ｍｓｅｃ以下の短い（shortened）ＴＴＩ（ｓＴＴＩ）を新たにデザインする必要がある。例えば、図５のように、ｅＮＢがデータ（ＰＤＣＣＨ及びＰＤＳＣＨ）の送信を開始して、ＵＥがＡ／Ｎ（ＡＣＫ／ＮＡＣＫ）の送信を完了するまでのユーザプレーン（User plane；Ｕ−ｐｌａｎｅ）レイテンシを１ｍｓｅｃに減らすためには、約３ＯＦＤＭシンボルを単位としてｓＴＴＩを構成してもよい。
【００９７】
下りリンク環境では、このようなｓＴＴＩ内でデータの送信／スケジューリングのためのＰＤＣＣＨ（すなわち、ｓＰＤＣＣＨ）と、ｓＴＴＩ内で送信が行われるＰＤＳＣＨ（すなわち、ｓＰＤＳＣＨ）と、が送信されてもよく、例えば、図６のように、１つのサブフレーム内で複数のｓＴＴＩが互いに異なるＯＦＤＭシンボルを用いて構成されてもよい。具体的には、ｓＴＴＩを構成するＯＦＤＭシンボルは、レガシ制御チャネルが送信されるＯＦＤＭシンボルを除いて構成されてもよい。ｓＴＴＩ内においてｓＰＤＣＣＨとｓＰＤＳＣＨとの送信は、互いに異なるＯＦＤＭシンボル領域を用いて時分割多重化（ＴＤＭ）（Time Division Multiplexing）された形態で送信されてもよく、互いに異なるＰＲＢ領域／周波数リソースを用いて周波数分割多重化（ＦＤＭ）（Frequency Division Multiplexing）された形態で送信されてもよい。
【００９８】
本明細書においては、ＬＴＥ／ＬＴＥ−Ａシステムに基づいて発明を説明する。従来のＬＴＥ／ＬＴＥ−Ａで、１ｍｓのサブフレームは、ノーマル（一般）（normal）ＣＰを有する場合に１４個のＯＦＤＭシンボルからなり、これを１ｍｓよりも短い単位で構成する場合、１つのサブフレーム内に複数のＴＴＩを構成することができる。複数のＴＴＩを構成する方式は、以下の図７に示した実施例のように、２個のシンボル、３個のシンボル、４個のシンボル、７個のシンボルを１つのＴＴＩとして構成することができる。図示を省略するが、１個のシンボルをＴＴＩとする場合も考えられる。１シンボルを１つのＴＴＩ単位とする場合、２個のＯＦＤＭシンボルでレガシＰＤＣＣＨを送信するという仮定の下において、１２個のＴＴＩが生成される。同様に、図７（ａ）のように、２シンボルを１つのＴＴＩ単位とする場合、６個のＴＴＩ、図７（ｂ）のように、３シンボルを１つのＴＴＩ単位とする場合、４個のＴＴＩ、図７（ｃ）のように、４シンボルを１つのＴＴＩ単位とする場合、３個のＴＴＩを生成することができる。もちろん、この場合、最初の２個のＯＦＤＭシンボルは、レガシＰＤＣＣＨが送信されると仮定する。
【００９９】
図７（ｄ）のように、７シンボルを１つのＴＴＩ単位とする場合、レガシＰＤＣＣＨを含む７個のシンボル単位のＴＴＩの１つと後ろの７個のシンボルとが１つのＴＴＩで構成されてもよい。このとき、ｓＴＴＩをサポートする端末の場合、１つのＴＴＩが７シンボルからなる場合、１つのサブフレームの前端に位置するＴＴＩ（１番目のスロット）は、レガシＰＤＣＣＨが送信される前端の２個のＯＦＤＭシンボルに対してパンクチャ（puncture）又はレートマッチング（rate-matching）されたと仮定して、以後の５個のシンボルで自体のデータ及び／又は制御情報が送信されると仮定する。これに対して、１つのサブフレームの後端に位置するＴＴＩ（２番目のスロット）に対して、端末は、パンクチャ又はレートマッチングするリソース領域無しで７個の全てのシンボルでデータ及び／又は制御情報が送信され得ると仮定する。
【０１００】
また、本発明では、２個のＯＦＤＭシンボル（以下、「ＯＳ」という）からなるｓＴＴＩと３個のＯＳからなるｓＴＴＩとが、図８のように、１つのサブフレーム内で混合して存在するｓＴＴＩも考慮する。このような２−ＯＳ又は３−ＯＳ  ｓＴＴＩからなるｓＴＴＩを、単に２シンボルｓＴＴＩ（すなわち、２−ＯＳ  ｓＴＴＩ）として定義してもよい。また、２シンボルのｓＴＴＩ又は３シンボルのｓＴＴＩを単に２シンボルＴＴＩ又は３シンボルＴＴＩと称してもよく、これらの全ては、本発明が前提しているレガシＴＴＩである１ｍｓＴＴＩよりも短いＴＴＩであることを明らかにしたい。すなわち、明細書において「ＴＴＩ」と記載されても、ｓＴＴＩではないわけではないことは明らかであり、その名称には関係なく、本発明が提案しようとするのは、レガシＴＴＩよりも短い長さのＴＴＩからなるシステムにおける通信方式に関するものである。
【０１０１】
また、本明細書におけるニューマロロジ（numerology）とは、当該無線通信システムに適用されるＴＴＩ長、サブキャリア間隔などの決定又は決定されたＴＴＩ長又はサブキャリア間隔などのパラメータ又はそれに基づいた通信構造又はシステムなどを意味する。
【０１０２】
図８（ａ）に示された＜３，２，２，２，２，３＞ｓＴＴＩパターンでは、ＰＤＣＣＨのシンボル数に応じてｓＰＤＣＣＨが送信されてもよい。図８（ｂ）の＜２，３，２，２，２，３＞ｓＴＴＩパターンは、レガシＰＤＣＣＨ領域のためにｓＰＤＣＣＨの送信が難しいことがある。
【０１０３】
レイテンシ（遅れ速度）（latency）の減少のためのスケジューリング要求（Scheduling Request；ＳＲ）
【０１０４】
特定の要求事項（requirement）（例えば、最高の信頼度（ultra-reliable）及び／又は低レイテンシ）を満たすためのＳＲリソースの時間間隔は、通常のデータトラフィック（例えば、ｅＭＢＢ（enhanced Mobile Broadband））に用いられるスケジューリング基本単位よりも小さく設定されてもよい。一例として、従来の通常のｅＭＢＢトラフィックのためのＳＲリソースがスロット単位で設定され、これとは別のＵＲＬＬＣトラフィックのためのＳＲリソースが、ミニスロット（mini-slot）単位で設定されてもよい。また、別の一例として、１ｍｓのＴＴＩデータトラフィックのためのＳＲリソースが、１、２、５、１０、２０、４０又は８０ｍｓ単位で設定されてもよく、一方、ｓＴＴＩデータトラフィック（例えば、２／３シンボルｓＴＴＩ）のためのＳＲリソースが、これよりも短い時間間隔単位（例えば、１つのｓＴＴＩ又はＸ個のｓＴＴＩ）で設定されてもよい。
【０１０５】
互いに異なるサービス及び／又はレイテンシの要求事項に対して、各々のＳＲがトリガ（triggering）できるように規則が定義されてもよい。一例として、ＵＲＬＬＣ  ＳＲは、ｅＭＢＢ  ＳＲとは別に分離されて端末が送信するように規則が定義されてもよい。このとき、具体的には、特定のトラフィックに対するＵＬ承認が受信される状況でも、他のトラフィックに対するＳＲが送信できるように規則が定義されてもよい。
【０１０６】
特定のサービス及び／又はレイテンシの要求事項に対するＳＲは、ＭＡＣ  ＰＤＵで送信されるより、物理層シグナリングで送信されることで、レイテンシをさらに減らすこともできる。具体的には、当該ＳＲは、（ＨＡＲＱ−ＡＣＫと共に）（ｓ）ＰＵＣＣＨで（従来のＬＴＥと同様に）送信されてもよい。また、（ｓ）ＰＵＳＣＨにＳＲがピギーバック（piggyback）されて共に送信されてもよいが、この場合、当該ＳＲは、ＵＬ−ＳＣＨ領域をパンクチャ（puncturing）してマッピング（mapping）されてもよく、又はＵＬ−ＳＣＨ領域にレートマッチング（rate-matching）されてマッピングされてもよい。このとき、特定のサービス及び／又はレイテンシの要求事項に対するＳＲは、承認無し（grant-free）ベースのＰＵＳＣＨに含まれて送信されるように規則が定義されてもよい。これは、承認無しベースのＵＬ送信から承認ベースのＵＬ送信に切り替え（switching）ようとする状況に適用されてもよい。
【０１０７】
互いに異なる特定のサービス及び／又はレイテンシに対する複数のＳＲが同一時点で送信されなければならない場合、以下の方法（方案）（method）を提案する。
【０１０８】
Ａｌｔ  １：複数のＳＲが互いに異なる時間リソースを介して送信される（すなわち、ＴＤＭされる）。具体的には、複数のＳＲのうちレイテンシが厳しい（きつい）（tight）トラフィックに対するＳＲが、より高い優先順位を持って優先して送信される。
【０１０９】
Ａｌｔ  ２：各ＳＲが別の物理チャネルを介して同時に送信される。
【０１１０】
Ａｌｔ  ３：１つの物理チャネルで複数のＳＲが同時に送信される。
【０１１１】
このとき、１つの物理チャネルにおいて、再びＳＲのそれぞれが区分される形態であってもよい。一例として、（ｓ）ＰＵＣＣＨにｅＭＢＢ  ＳＲとＵＲＬＬＣ  ＳＲとが同時に送信されるとき、肯定／肯定（positive/positive）、肯定／否定（positive/negative）、否定／肯定（negative/positive）ＳＲに区分されてもよく、否定／否定（negative/negative）は、未送信として処理されてもよい。
【０１１２】
また、複数のＳＲに対してＳＲバンドリング（bundling）が考慮されてもよい。一例として、複数のＳＲのうちの１つでも肯定ＳＲであれば、送信されるＳＲは、肯定ＳＲであり、基地局は、肯定ＳＲを検出するとき、複数のトラフィックに対してＵＬ承認スケジューリングを行うように規則が定義されてもよい。
【０１１３】
Ａｌｔ  ４：複数のＳＲに対して優先順位を決定して、一部に対してのみ送信を行い、残りのＳＲは、ドロップ（drop）するように規則が定義されてもよい。一例として、ｅＭＢＢ  ＳＲとＵＲＬＬＣ  ＳＲとの送信時点が重畳（overlap）される場合、ＵＲＬＬＣ  ＳＲにより高い優先順位が割り当てられて送信され、ｅＭＢＢ  ＳＲは、ドロップ（drop）されるように規則が定義されてもよい。
【０１１４】
動的ＴＤＤのように柔軟（flexible）にＤＬ／ＵＬリソースが変更される状況では、ＤＬリソースにおけるＳＲ送信は、予め定義され、又は上位層信号（又は物理層信号）によって設定された優先順位によって送信が可能か否かが決定されるように規則が定義されてもよい。具体的には、特定のＤＬリソースにおいてＤＬチャネルと特定のサービス／トラフィックに対するＳＲとが重なったとき、ＤＬ  ＵＲＬＬＣ＞ＵＲＬＬＣ  ＳＲ＞ＤＬ  ｅＭＢＢ＞ｅＭＢＢ  ＳＲのような順に優先順位が決定されてもよい。また、ＤＬリソースでは、ＤＬトラフィックが高い優先順位を有するように、ＤＬ  ＵＲＬＬＣ＞ＤＬ  ｅＭＢＢ＞ＵＲＬＬＣ  ＳＲ＞ｅＭＢＢ  ＳＲのような順に優先順位が決定されてもよい。
【０１１５】
短い区間（duration）のＰＵＣＣＨの場合には、スロットの最後の１又は２シンボルに割り当てられるはずであるが、特定のサービス／トラフィックに対するＳＲの場合（例えば、ＵＲＬＬＣ  ＳＲ）、より頻繁に送信する必要があり得る。具体的には、特定のサービス／トラフィックに対するＳＲの場合（例えば、ＵＲＬＬＣ  ＳＲ）、例外的に、短い区間のＰＵＣＣＨがスロットの最初に及び／又は途中に割り当てられるように規則が定義されてもよい。より一般的には、ｅＭＢＢスケジューリングユニット（例えば、スロット）における全てのミニスロットにおいて、ＵＲＬＬＣ  ＳＲ及びＵＲＬＬＣ  ＨＡＲＱ−ＡＣＫに対する時間リソースがリザーブ（reserve）されてもよい。
【０１１６】
特定のサービス／トラフィックに対するＳＲ（例えば、ＵＲＬＬＣ  ＳＲ）送信が他のＵＬチャネルと時間上で重なる場合、最も簡単には、ＵＲＬＬＣに対するＳＲリソースのために専用周波数領域を割り当ててもよい。詳細には、同一の端末の観点からｅＭＢＢ  ＰＵＳＣＨ／ＰＵＣＣＨとＵＲＬＬＣ  ＳＲリソースとが衝突する際、ｅＭＢＢ  ＰＵＳＣＨにＳＲをピギーバック（piggyback）させたり、ＰＵＳＣＨ／ＰＵＣＣＨはドロップしてＵＲＬＬＣ  ＳＲのみを送信したり、ＳＲをドロップしてＰＵＳＣＨ／ＰＵＣＣＨを送信したり、ＳＲリソースに該当するｅＭＢＢ  ＰＵＳＣＨ／ＰＵＣＣＨ部分のみパンクチャ又はレートマッチングしてＳＲを送信したりするように規則が定義されてもよい。このとき、上述したパンクチャ又はレートマッチングは、全てのＳＲリソースに対して行う必要はなく、実際にＵＲＬＬＣ  ＳＲが送信される時点に限って行うように規則が定義されてもよい。互いに異なる端末の観点からのｅＭＢＢ  ＰＵＳＣＨ／ＰＵＣＣＨとＵＲＬＬＣ  ＳＲリソースとの衝突において、常にパンクチャ又はレートマッチングされる必要があり得る。よって、基地局は、複数のＳＲ時間／周波数（／空間）リソース情報を上位／物理層信号を通じて端末に通知して、端末は、ＰＵＳＣＨ又はＰＵＣＣＨと重なる部分に限ってパンクチャ又はレートマッチングを行うように規則が定義されてもよい。
【０１１７】
具体的には、ＳＲリソースと衝突するｅＭＢＢ  ＰＵＣＣＨの区間によって、端末の行動（behavior）の決定は、異なってもよく同一であってもよい。長いＰＵＣＣＨとＵＲＬＬＣ  ＳＲとが衝突した場合は、ｅＭＢＢ  ＰＵＣＣＨにＳＲをピギーバックさせたり、長いＰＵＣＣＨはドロップしてＵＲＬＬＣ  ＳＲのみを送信したり、ＳＲをドロップして長いＰＵＣＣＨを送信したり、同時送信したりするように規則が定義されてもよい。短いＰＵＣＣＨとＵＲＬＬＣ  ＳＲとが衝突した場合には、端末は、ジョイントコーディング（joint coding）してＰＵＣＣＨリソースで送信したり、ＰＵＣＣＨリソースとＳＲリソースとの組み合わせで最終リソースを決定して送信したり、同時送信したりするように規則が定義されてもよい。また、ＰＵＣＣＨに１ビットを追加してＰＵＣＣＨリソースとＳＲリソースとの組み合わせで決定された（又は、予め上位／物理層信号で設定された）第３のリソースでＰＵＣＣＨのＵＣＩとＳＲとを送信してもよい。又は、複数のリソースを上位／物理層信号で設定して、ＰＵＣＣＨのＵＣＩとＳＲとの状態によってチャネル選択して最終送信リソースを決定してもよい。
【０１１８】
上述した長いＰＵＣＣＨとＵＲＬＬＣ  ＳＲと、及び／若しくは短いＰＵＣＣＨとＵＲＬＬＣ  ＳＲと、の同時送信設定は、又は簡単には、ＰＵＣＣＨとＵＲＬＬＣ  ＳＲとの同時送信設定若しくはＰＵＳＣＨとＳＲとの同時送信設定は、ＵＥ固有に、又は予め約束又は設定されたセルグループ別、又はセル別、又は帯域／帯域の組み合わせ別に、端末に設定されてもよい。
【０１１９】
長いＰＵＣＣＨとＵＲＬＬＣ  ＳＲと、及び／若しくは短いＰＵＣＣＨとＵＲＬＬＣ  ＳＲと、の同時送信能力（capability）は（又は簡単には、ＰＵＣＣＨとＵＲＬＬＣ  ＳＲとの同時送信能力若しくはＰＵＳＣＨとＳＲとの同時送信能力は）、ＵＥ固有に、又は予め約束又は設定されたセルグループ別、又はセル別、又は帯域／帯域の組み合わせ別に、ネットワークに報告するように規則が定義されてもよい。
【０１２０】
レイテンシを減少させるために、ネットワークは、ＳＲを受信したときにＵＬ承認をできる限り早く行うことが望ましい。１つの方法としては、予め設定されたリソース及び／又はＴＢＳ（Transport Block Size）を用いてＵＬ承認を行うことである。予め設定されたリソースは、承認無しのリソースで設定されたリソースであってもよくその一部であってもよい。また、ＴＢＳも承認無しの用途として予め設定された複数の値のうちの１つであってもよい。すなわち、承認無しのリソースのうちいずれのリソース／ＴＢＳを端末が使用できるかをＵＬ承認で端末に指示することができる。このような決定は早くできるため、ネットワーク又は基地局は、ＳＲを受信し次第ＵＬ承認することができる。このとき、端末は、ＳＲ送信後、リソース及びＴＢＳをある程度予め予測しているため、ＰＵＳＣＨを予め生成しておくことができ、よって、ＵＬ承認−ｔｏ−ＰＵＳＣＨ送信タイミングが予め定義されているか、上位層／物理層信号を通じて指示された値よりも短く自動に決定されてもよい。また、上述のように予め設定されたリソース及び／又はＴＢＳを用いてＵＬ承認を与えるとき、デフォルト（default）値よりも短く上位／物理層信号を通じて設定／指示されてもよい。一例として、予め設定されたリソース及び／又はＴＢＳを用いてＵＬ承認を与える場合、端末は、最初に利用可能な承認無しのリソースでＰＵＳＣＨを送信できるように規則が定義されてもよい。
【０１２１】
レイテンシの減少のためのＢＳＲ（Buffer State Report）
【０１２２】
互いに異なるサービス及び／又はレイテンシの要求事項に対して、各々のＢＳＲ（Buffer State Report）が報告されるように規則が定義されてもよい。具体的には、互いに異なるサービス及び／又はレイテンシの要求事項に対する各々のＢＳＲは、相違する値の範囲を指示するように規則が定義されてもよい。具体的には、ｅＭＢＢのＢＳＲとＵＲＬＬＣのＢＳＲとの同様な状態が、互いに異なる値／範囲／粒度（granularity）を示すように規則が定義されてもよい。これは、独立した別途の表（table）がＵＲＬＬＣのＢＳＲ報告のために新たに定義されてもよく、ＵＲＬＬＣ  ＢＳＲの特定の状態が従来定義された表の特定の状態に対してオフセットによって調整された新たな値を指示する形態で規則が定義されてもよい。また、全て又は特定のＢＳＲは、当該トラフィックに対するレイテンシ及び／又は信頼度に関する情報が共に含まれて報告されるように規則が定義されてもよく、これに基づいて、ネットワークは、端末の要求に応じて、さらに適したスケジューリングを行うことができる。一例として、端末は、特定のＵＲＬＬＣトラフィックに対して、ｘ  ｍｓ内にＢＬＥＲ（Block Error Ratio）が１０^−５以下で送信されるべきであるという情報をＢＳＲに含ませて報告し、これに基づいて、ネットワークは、当該ＵＬをスケジューリングすることができる。
【０１２３】
ＳＲ及び／又はＢＳＲ及び／又はＨＡＲＱ−ＡＣＫの同時送信
【０１２４】
上りリンクデータ送信をより早く行うために、ＳＲと共にＢＳＲを送信する１つの方法として、複数のリソースを設定して、特定のリソースとＢＳＲ状態とをマッピングさせるマルチ（多重）レベル（multiple-level）ＳＲ方法がある。別の方法としては、ＱＰＳＫ（Quadrature Phase Shift Keying）、より一般には、変調されたシンボルでＳＲ送信を行い、各変調されたシンボルとＢＳＲ状態とをマッピングさせるように規則が定義されてもよい。上述した方法は、ＳＲを送信するときにＢＳＲ以外の他の情報が共に送信される場合にも同様に適用され得る。
【０１２５】
ＳＲ＋ＢＳＲを送信するとき、特定のＤＬデータチャネルに対するＨＡＲＱ−ＡＣＫも共に送信される場合、端末ができる限り全ての情報を送信することが望ましい。よって、上述のようにＳＲと共にＢＳＲ（又は、ＢＳＲ以外の他の情報）を送信するとき、特定のＤＬデータチャネルに対するＨＡＲＱ−ＡＣＫのタイミングが重なる場合の端末のＵＣＩ送信方法を以下のように提案する。
【０１２６】
Ａｌｔ  １：ＢＳＲをドロップしてＳＲとＨＡＲＱ−ＡＣＫとの状態が、ＱＰＳＫ、より一般的には、各変調されたシンボルとマッピングされるように規則が定義されてもよい。一例として、ＱＰＳＫの各状態は、｛肯定ＳＲ、ＡＣＫ｝、｛肯定（固定）ＳＲ、ＮＡＣＫ｝、｛否定ＳＲ、ＡＣＫ｝、｛否定ＳＲ、ＮＡＣＫ｝と構成されてもよい。具体的には、上述したマッピングは、ＤＬデータチャネルに対するＤＬ割り当てＤＣＩが欠落した（をミッシングする）（missing）とき、又はＤＬスケジューリングが不在のとき、すなわちＤＴＸの場合、｛肯定（固定）ＳＲ、ＢＳＲ状態１｝、｛肯定（固定）ＳＲ、ＢＳＲ状態２｝、｛否定ＳＲ、ＢＳＲ状態３｝、｛否定ＳＲ、ＢＳＲ状態４｝に振り替えられてもよい。
【０１２７】
Ａｌｔ  ２：ＨＡＲＱ−ＡＣＫバンドリング及び／又はＢＳＲサブサンプリング（sub-sampling）のような動作を行った後、ＳＲと｛バンドリングされたＨＡＲＱ−ＡＣＫ及び／又はサブサンプリングされたＢＳＲ｝との組み合わせからなる状態が、ＱＰＳＫ、より一般には、各変調されたシンボルとマッピングされるように規則が定義されてもよい。
【０１２８】
Ａｌｔ  ３：特定のリソースとＢＳＲ状態とをマッピングし、当該リソースにおける各変調されたシンボルとＨＡＲＱ−ＡＣＫ状態とがマッピングされるように規則が定義されてもよい。一例として、ＰＵＣＣＨリソース１、２、３、４を予め上位層信号を通じて端末に設定し、これが、ＢＳＲ状態１、２、３、４とそれぞれマッピングされてもよい。ＱＰＳＫの各状態は、｛肯定ＳＲ、ＡＣＫ｝、｛肯定ＳＲ、ＮＡＣＫ／ＤＴＸ｝、｛否定ＳＲ、ＡＣＫ｝、｛否定ＳＲ、ＮＡＣＫ／ＤＴＸ｝とマッピングされてもよい。
【０１２９】
逆に、特定のリソースとＨＡＲＱ−ＡＣＫ状態とをマッピングし、当該リソースにおける各変調されたシンボルとＢＳＲ状態とがマッピングされるように規則が定義されてもよい。一例として、このときには、ＰＵＣＣＨリソース１、２を予め上位層信号を通じて端末に設定し、これが、ＡＣＫ、ＮＡＣＫ／ＤＴＸとそれぞれマッピングされてもよい。ＱＰＳＫの各状態は、｛肯定ＳＲ、ＢＳＲ状態１｝、｛否定ＳＲ、ＢＳＲ状態２｝、｛否定ＳＲ、ＢＳＲ状態３｝、｛否定ＳＲ、ＢＳＲ状態４｝とマッピングされてもよい。
【０１３０】
Ａｌｔ  ４：特定のリソースとＢＳＲ状態とをマッピングし、当該リソースから送信されるシーケンスの巡回シフト（Cyclic Shift；ＣＳ）（又は、スクランブル識別子）とＨＡＲＱ−ＡＣＫ状態とがマッピングされるように規則が定義されてもよい。逆に、特定のリソースとＨＡＲＱ−ＡＣＫ状態とをマッピングして、当該リソースから送信されるシーケンスのＣＳ（又は、スクランブル識別子）とＢＳＲ状態とがマッピングされるように規則が定義されてもよい。
【０１３１】
Ａｌｔ  ５：ＢＳＲ状態のうちの一部は捨てて、否定ＳＲを含んでＳＲ＋ＢＳＲ送信を行うように規則が定義されてもよい。一例として、２ビットで｛肯定ＳＲ＋ＢＳＲ状態１｝、｛肯定ＳＲ＋ＢＳＲ状態２｝、｛肯定ＳＲ＋ＢＳＲ状態３｝、｛否定ＳＲ｝を表現するように規則が定義されてもよい。別の方法として、ＢＳＲ状態を捨てずに、さらにビットを用いてＳＲ＋ＢＳＲ送信を行うように規則が定義されてもよい。一例として、３ビットで｛肯定ＳＲ＋ＢＳＲ状態１｝、｛肯定ＳＲ＋ＢＳＲ状態２｝、｛肯定ＳＲ＋ＢＳＲ状態３｝、｛肯定ＳＲ＋ＢＳＲ状態４｝、｛否定ＳＲ｝を表現するように規則が定義されてもよい。
【０１３２】
Ａｌｔ  ６：ＳＲ＋ＢＳＲ送信時に特定のＤＬデータチャネルに対するＨＡＲＱ−ＡＣＫも共に送信される場合、情報損失無しで全ての情報を送信することが望ましいこともある。よって、上述した場合、ＰＵＣＣＨフォーマットの変更によってＳＲ、ＢＳＲ、ＨＡＲＱ−ＡＣＫを全て送信するように規則が定義されてもよい。このとき、ＨＡＲＱ−ＡＣＫのペイロードサイズに応じてＰＵＣＣＨフォーマットを変更するか否かが決定されてもよい。また、ＨＡＲＱ−ＡＣＫのペイロードサイズに応じて予め定義／約束された複数のＰＵＣＣＨフォーマットのうちの１つが決定されて、ＳＲ、ＢＳＲ、ＨＡＲＱ−ＡＣＫが送信されるように規則が定義されてもよい。一例として、ＳＲ＋ＢＳＲ送信時には、ＰＵＣＣＨフォーマット１ａ／１ｂ（又は、新しいＲＡＴ（ラット）（ＮＲ）で新たに定義された小さいペイロードのためのＰＵＣＣＨ）を用いて、Ｘビット（例えば、Ｘ＝２２）以下のＨＡＲＱ−ＡＣＫが共に送信される場合、ＰＵＣＣＨフォーマット３を用いて、Ｘビットよりも多いＨＡＲＱ−ＡＣＫが共に送信される場合、ＰＵＣＣＨフォーマット４（又は、ＮＲで新たに定義された大きいペイロードのためのＰＵＣＣＨ）を用いるように規則が定義されてもよい。
【０１３３】
Ａｌｔ  ７：ＳＲ＋ＢＳＲ送信時に特定のＤＬデータチャネルに対するＨＡＲＱ−ＡＣＫも共に送信される場合、ＰＵＣＣＨのＲＢ（Resource Block）が増加して、多重ＲＢ  ＰＵＣＣＨで、ＳＲ及び／又はＢＳＲ及び／又はＨＡＲＱ−ＡＣＫが送信されるように規則が定義されてもよい。送信される情報量／ペイロードを考慮して、ＲＢの数が決定されてもよく、又は上位層信号／物理層信号を介して設定されたＲＢ数を用いてＳＲ及び／又はＢＳＲ及び／又はＨＡＲＱ−ＡＣＫが送信されるように規則が定義されてもよい。一例として、Ｘビット（例えば、Ｘ＝２２）以下のＨＡＲＱ−ＡＣＫが共に送信される場合、１つのＲＢで送信され、Ｘビットよりも多いＨＡＲＱ−ＡＣＫが共に送信される場合、予め約束された数のＲＢ又は上位層信号を介して設定された（又は、ＤＣＩで指示された）ＲＢ数で送信されるように規則が定義されてもよい。
【０１３４】
Ａｌｔ  ８：別の方法として、ＳＲ、ＢＳＲ、ＨＡＲＱ−ＡＣＫを複数のＰＵＣＣＨ（format）に予め定義された規則に従って載せて、当該複数のＰＵＣＣＨ（format）がＴＤＭ及び／又はＦＤＭ及び／又はＣＤＭされて全て送信されてもよい。一例として、ＳＲ＋ＢＳＲが１つのＰＵＣＣＨ、ＨＡＲＱ−ＡＣＫがその他のＰＵＣＣＨにマッピングされて送信されてもよい。
【０１３５】
ＳＲ及びＨＡＲＱ−ＡＣＫ衝突処理
【０１３６】
相違するＴＴＩ長（及び／又はニューマロロジ（numerology）及び／又はサービス／レイテンシの要求事項及び／又は処理時間）を有する複数のＨＡＲＱ−ＡＣＫとＳＲの送信時点とが重なる場合、衝突処理が必要となる。詳しくは、以下の場合が含まれ得る。
【０１３７】
ケース１：より長い（longer）ＴＴＩ  ＨＡＲＱ−ＡＣＫ＋より長いＴＴＩ  ＳＲ＋より短い（shorter）ＴＴＩ  ＳＲ
【０１３８】
ケース２：より長いＴＴＩ  ＨＡＲＱ−ＡＣＫ＋より短いＴＴＩ  ＨＡＲＱ−ＡＣＫ＋より長いＴＴＩ  ＳＲ
【０１３９】
ケース３：より長いＴＴＩ  ＨＡＲＱ−ＡＣＫ＋より短いＴＴＩ  ＨＡＲＱ−ＡＣＫ＋より短いＴＴＩ  ＳＲ
【０１４０】
ケース４：より長いＴＴＩ  ＨＡＲＱ−ＡＣＫ＋より短いＴＴＩ  ＨＡＲＱ−ＡＣＫ＋より長いＴＴＩ  ＳＲ＋より短いＴＴＩ  ＳＲ
【０１４１】
ケース５：より短いＴＴＩ  ＨＡＲＱ−ＡＣＫ＋より長いＴＴＩ  ＳＲ＋より短いＴＴＩ  ＳＲ
【０１４２】
上述した衝突ケースが発生する場合、より短いＴＴＩ  ＰＵＣＣＨでＵＣＩを送信する方法が考慮されている。具体的には、ＳＲの数が単一である場合（例えば、ケース２又は３）、肯定ＳＲであれば、ＳＲ肯定により長いＴＴＩ  ＨＡＲＱ−ＡＣＫ及び／又はより短いＴＴＩ  ＨＡＲＱ−ＡＣＫを（ｓ）ＰＵＣＣＨを用いて送信して、否定ＳＲであれば、より短いＴＴＩ  ＨＡＲＱ−ＡＣＫリソースにおいてより長いＴＴＩ  ＨＡＲＱ−ＡＣＫ及び／又はより短いＴＴＩ  ＨＡＲＱ−ＡＣＫを（ｓ）ＰＵＣＣＨを用いて送信するように規則が定義されてもよい。このとき、ＳＲのＴＴＩ長（及び／又はニューマロロジ及び／又はサービス／レイテンシの要求事項及び／又は処理時間）に応じて、別のリソースが設定されてもよく、ケース２の場合は、より長いＴＴＩ  ＳＲのために設定されたＰＵＣＣＨリソースに肯定のより長いＴＴＩ  ＳＲを含む（ｓ）ＰＵＣＣＨを送信し、ケース３の場合は、より短いＴＴＩ  ＳＲのために設定されたＰＵＣＣＨリソースに肯定のより短い（positive shorter）ＴＴＩ  ＳＲを含む（ｓ）ＰＵＣＣＨを送信してもよい。
【０１４３】
一方、ＳＲの数が複数である場合（例えば、ケース１、４又は５）、優先順位の低いＳＲをドロップして、より優先順位の高いＳＲのみ送信するように規則が定義されてもよい。一例として、低レイテンシトラフィックにより高い優先順位を付与するために、より長いＴＴＩ  ＳＲをドロップし、より長い及び／又はより短いＴＴＩ  ＨＡＲＱ−ＡＣＫとより短いＴＴＩ  ＳＲのみとを送信するように規則が定義されてもよい。この場合、肯定のより短いＴＴＩ  ＳＲの場合、より短いＴＴＩ  ＳＲリソースにより長いＴＴＩ  ＨＡＲＱ−ＡＣＫ及び／又はより短いＴＴＩ  ＨＡＲＱ−ＡＣＫを（ｓ）ＰＵＣＣＨを用いて送信し、否定ＳＲである場合、より短いＴＴＩ  ＨＡＲＱ−ＡＣＫリソースにより長いＴＴＩ  ＨＡＲＱ−ＡＣ及び／又はより短いＴＴＩ  ＨＡＲＱ−ＡＣＫを（ｓ）ＰＵＣＣＨを用いて送信するように規則が定義されてもよい。すなわち、上記ＳＲの数が単一である場合と同様な方法が用いられる。具体的には、特定のＴＴＩ（及び／又はニューマロロジ及び／又はサービス／レイテンシの要求事項及び／又は処理時間）のＳＲがドロップされる場合、ＢＳＲに当該スケジューリングに対する要求情報が含まれてもよい。
【０１４４】
別の方法としては、より長いＴＴＩ  ＳＲとより短いＴＴＩ  ＳＲとを別のドロップ無しで全て送信するように規則が定義されてもよい。そのために、更なるリソースを予め設定しておいて、予め約束された規則によって、端末が複数のＳＲを全て送信してもよい。具体的な一例として、ＳＲ送信用のリソースを３つ設定しておいて、（否定のより長いＴＴＩ  ＳＲ、否定のより短いＴＴＩ  ＳＲ）の場合、より短いＴＴＩ  ＨＡＲＱ−ＡＣＫリソースに（ｓ）ＰＵＣＣＨを送信して、残りの３つのリソースに、それぞれ、（肯定のより長いＴＴＩ  ＳＲ、否定のより短いＴＴＩ  ＳＲ）、（否定のより長いＴＴＩ  ＳＲ、肯定のより短いＴＴＩ  ＳＲ）、（肯定のより長いＴＴＩ  ＳＲ、肯定のより短いＴＴＩ  ＳＲ）の場合を対応させて、（ｓ）ＰＵＣＣＨを送信するように規則が定義されてもよい。
【０１４５】
別の方法として、特定のＴＴＩ（及び／又はニューマロロジ及び／又はサービス／レイテンシの要求事項及び／又は処理時間）のＳＲは、ＳＲリソース及びＨＡＲＱ−ＡＣＫリソース送信が可能か否かによって状態を区分し（differentiate）、残りのＴＴＩ（及び／又はニューマロロジ及び／又はサービス／レイテンシの要求事項及び／又は処理時間）のＳＲは、（ｓ）ＰＵＣＣＨシーケンスのＣＳによって状態を区分するように規則が定義されてもよい。
【０１４６】
別の方法として、ＳＲの数が複数である場合（例えば、ケース１又は５）、ＨＡＲＱ−ＡＣＫのＴＴＩ長と同一のＴＴＩを有するＳＲを優先してトリガするように、且つ相違するＴＴＩを有するＳＲはドロップされるように、規則が定義されてもよい。
【０１４７】
多重ビットＳＲ送信
【０１４８】
次期のシステムでは、応用分野によっては送信速度を大幅に減らす方式の導入が考慮されている。特に、ＵＬ送信においては、従来ＵＬ承認に基づいてスケジューリングする代わりに、端末の決定によってＵＬ送信が始まる承認無しのＵＬ送信の導入が考慮されている。より詳しくは、基地局は、承認無しのＵＬ送信のためのリソース集合を設定して端末に指示することができ、端末は、ＵＬ承認無しでもＵＬ送信を開始することができる。説明の便宜のために、このような送信方式を「承認のないＵＬ送信」と称する。
【０１４９】
上記「承認のないＵＬ送信」の場合、後の結合又はいずれの送信に対する再送信を基地局が要求すべきかに関する曖昧さ（ambiguity）を防止するために、ＨＡＲＱプロセス番号のような一種の識別子が定義される必要がある。このような識別子をＳＲに共に送る方法として、以下のような多重ビットＳＲが考慮されてもよい。
【０１５０】
Ａｌｔ  １：複数のビットによって表現される状態がＨＡＲＱプロセス番号に関係付けるように規則が定義されてもよい。この場合、ＨＡＲＱプロセス番号の全数（total number）によって、これを表現するためのＳＲビット数が決定されてもよい。
【０１５１】
Ａｌｔ  ２：複数のビットと複数のＳＲリソースとの組み合わせによって、ＨＡＲＱプロセス番号が表現されるように規則が定義されてもよい。
【０１５２】
ＳＲの本来の目的は、端末が送信するＵＬトラフィックが発生する場合、これをスケジューリングするためのＵＬ承認を求めるためである。このような目的の他に、承認のないＵＬ送信のためのリソースの設定を要求するための信号を導入／送信してもよい。
【０１５３】
また、ＤＬに対する新たなデータを要求するための信号を導入／送信してもよい。これは、端末がＡＣＫを送信したにもかかわらず、ＡＣＫ−ｔｏ−ＮＡＣＫエラーによって基地局が再送信承認を行った場合に必要となり得る。具体的には、特定のＰＤＳＣＨをスケジューリングするＤＣＩ受信時点又は特定のＰＤＳＣＨ受信時点又はそれに対するＡＣＫを送信した時点から、予め定義／約束された、又は上位層信号を通じて設定された、又はＤＣＩを通じて指示された時間の間に、再送信がスケジューリングされない場合、上記「ＤＬに対する新たなデータの要求のための信号」を送信するように規則が定義されてもよい。
【０１５４】
又は、ＤＬに対する再送信の要求のための信号を導入／送信してもよい。これは、逆に、端末がＮＡＣＫを送信したにもかかわらず、ＮＡＣＫ−ｔｏ−ＡＣＫエラーによって基地局が新たなデータをスケジューリングする承認を行った場合に必要となり得る。具体的には、特定のＰＤＳＣＨをスケジューリングするＤＣＩ受信時点又は特定のＰＤＳＣＨ受信時点又はそれに対するＮＡＣＫを送信する時点から、予め定義／約束された、又は上位層信号を通じて設定された、又はＤＣＩを通じて指示された時間の間に、再送信がスケジューリングされない場合、上記「ＤＬに対する再送信の要求のための信号」を送信するように規則が定義されてもよい。
【０１５５】
上記「ＤＬに対する新たなデータの要求」及び／又は「ＤＬに対する再送信の要求」は、「ＵＬ承認の要求」及び／又は「承認のないＵＬ送信のためのリソースの設定の要求」とは別のリソースが設定されるように規則が定義されてもよい。これを通じて、基地局は、ＤＬ又はＵＬに対する要求であるか否か（ＤＬにおける要求か又はＵＬにおける要求か）を区分してもよい。
【０１５６】
上記「ＤＬに対する新たなデータの要求」及び／又は「ＤＬに対する再送信の要求」が、いずれのＰＤＳＣＨに対するものであるかに関する一種の識別子（例えば、ＨＡＲＱプロセス番号）が、上記要求のための信号に共に含まれて送信されてもよい。
【０１５７】
より具体的には、多重ビットＳＲを用いて、上述した様々な目的のための端末の要求が表現されてもよい。一例として、ＵＬ承認要求であるか、又は「承認のないＵＬ送信」のためのリソース要求であるかを多重ビットＳＲを用いて表現したり、ＵＬ承認要求、承認のないＵＬ送信のためのリソース要求、ＤＬ新たなデータ要求、ＤＬ再送信要求のうちの特定の組み合わせに対して、いずれの要求であるかを多重ビットＳＲを用いて表現してもよい。或いは、上記「承認のないＵＬ送信のためのリソース要求」と共に、予め設定されていたリソースよりも大きいリソースが必要であるか、又は小さいリソースが必要であるかなどの具体的な要求を多重ビットＳＲを通じて表現してもよい。この要求は、多重ビットＳＲではない別の信号で定義されてもよい。
【０１５８】
別の方法として、端末が特定のＰＤＳＣＨに対するＮＡＣＫを送信するとき、いずれのＰＤＳＣＨに対するものであるかに関する一種の識別子（例えば、ＨＡＲＱプロセス番号）を含んで送信するように規則が定義されてもよい。これは、特定のＰＤＳＣＨに対するＮＡＣＫを送信したにもかかわらず、基地局が新たなＰＤＳＣＨをスケジューリングする場合、完全に復号（decoding）できなかったＰＤＳＣＨに対して端末が再送信を要求するためである。具体的には、特定のＰＤＳＣＨをスケジューリングするＤＣＩ受信時点又は特定のＰＤＳＣＨ受信時点又はそれに対するＮＡＣＫを送信した時点から、予め定義／約束された、又は上位層信号を通じて設定された、又はＤＣＩを通じて指示された時間の間に、再送信がスケジューリングされない場合、上記ＮＡＣＫ＋ＨＡＲＱプロセス番号を送信するように規則が定義されてもよい。
【０１５９】
他のチャネル／信号とＳＲとの衝突処理
【０１６０】
次期のシステムでは、様々な長さのＴＴＩを有するＵＬ制御チャネルが考慮されており、これを通じてＳＲを送信する方法も考慮されている。ｘ−シンボルＰＵＣＣＨによって送信されるＳＲとｙ−シンボルＰＵＣＣＨによって送信されるＨＡＲＱ−ＡＣＫとの送信時点が重なる場合、当該ＳＲとＨＡＲＱ−ＡＣＫとの具体的な送信方法を提案する。
【０１６１】
ケース１：ｘ＜ｙ
【０１６２】
オプション１−１：ＳＲ情報がＨＡＲＱ−ＡＣＫを送信するためのＰＵＣＣＨの一部に含まれてもよいが、具体的には、シーケンスベースのＰＵＣＣＨ形態でＨＡＲＱ−ＡＣＫを送信する場合、各シンボルでシーケンスが繰り返される形態であってもよいため、ＳＲの送信タイミングに該当する時点（例えば、時間軸のシンボルに該当するリソース）でのみ当該時間リソースに送信されるシーケンスのリソース（例えば、巡回シフト及び／又は物理領域（ドメイン）（physical-domain）リソース）をさらに用いて、ＳＲ情報を含んでＰＵＣＣＨが送信されてもよい。又は、ＳＲの送信タイミングに該当する時点以後から予め定義／約束されたか、シグナリングされた時点又はＰＵＣＣＨの最後のシンボル（ending symbol）までのシーケンスのリソース（例えば、巡回シフト及び／又は物理領域リソース）をさらに用いて、ＳＲ情報を含んでＰＵＣＣＨが送信されてもよい。このとき、ＨＡＲＱ−ＡＣＫペイロードサイズ及び／又はＨＡＲＱ−ＡＣＫとＳＲとを合わせた全体のペイロードサイズ及び／又はＨＡＲＱ−ＡＣＫ  ＰＵＣＣＨのＴＴＩ長／ニューマロロジ及び／又はＨＡＲＱ−ＡＣＫ  ＰＵＣＣＨのフォーマットなどによって、実際にＨＡＲＱ−ＡＣＫ及びＳＲが送信されるＰＵＣＣＨフォーマット及び／又はＴＴＩ長が変更されてもよい。
【０１６３】
オプション１−２：ＳＲ情報がＨＡＲＱ−ＡＣＫを送信するためのＰＵＣＣＨに全体的に含まれてもよいが、具体的には、シーケンスベースのＰＵＣＣＨ形態でＨＡＲＱ−ＡＣＫを送信する場合、各シンボルにシーケンスが繰り返される形態であってもよいため、各シンボルに送信されるシーケンスのリソース（例えば、巡回シフト及び／又は物理領域リソース）をさらに用いて、ＳＲ情報を含んでＰＵＣＣＨが送信されてもよい。このとき、ＨＡＲＱ−ＡＣＫペイロードサイズ及び／又はＨＡＲＱ−ＡＣＫとＳＲとを合わせた全体のペイロードサイズ及び／又はＨＡＲＱ−ＡＣＫ  ＰＵＣＣＨのＴＴＩ長／ニューマロロジ及び／又はＨＡＲＱ−ＡＣＫ  ＰＵＣＣＨのフォーマットなどによって、実際にＨＡＲＱ−ＡＣＫ及びＳＲが送信されるＰＵＣＣＨフォーマット及び／又はＴＴＩ長が変更されてもよい。
【０１６４】
オプション１−３：ＳＲが、ＨＡＲＱ−ＡＣＫを送信するＰＵＣＣＨをパンクチャ又はレートマッチングして送信されるように規則が定義されてもよい。具体的には、このとき、パンクチャ又はレートマッチングされるＰＵＣＣＨ内の時間リソースは、ＳＲの本来の送信タイミングに該当する区間の間にのみ限られてもよい。また、パンクチャ又はレートマッチングされるＰＵＣＣＨ内の時間リソースは、ＳＲの本来の送信タイミング以後に、ＰＵＣＣＨの最後のシンボル又は予め定義／約束された区間の間、又は上位層／物理層信号を通じて設定／指示された区間の間にのみ限られてもよい。
【０１６５】
オプション１−４：ＳＲ送信が予め設定された（又は、シグナリングされた）周期及びオフセットによって決定される次の送信時点に遅延されるように規則が定義されてもよい。また、本来のＳＲ送信タイミング以後の最も早いＵＬ送信可能スロット／ミニスロットなどでＳＲが優先して送信されるように規則が定義されてもよい。
【０１６６】
オプション１−５：ＨＡＲＱ−ＡＣＫとＳＲとを送信する２つのＰＵＣＣＨが、同時送信されるように規則が定義されてもよい。具体的には、上述した同時送信は、相違するＴＴＩ長及び／又はニューマロロジに該当する複数のＵＬチャネルの同時送信に対する端末の能力及び／又はネットワーク設定が存在する場合に限って許可（許容）され（allowed）てもよい。具体的には、上述した同時送信は、上位層信号で設定された、又は物理層信号によって指示された２つのチャネルのＵＬ波形（waveform）が、ＣＰ−ＯＦＤＭ（Cyclic-Prefix Orthogonal Frequency Division Multiplexing）である場合に限って許可されてもよい。２つのうちの１つのチャネルがＳＣ−ＦＤＭＡである場合は、上記端末の能力及び／又はネットワーク設定を無視して、１つのＰＵＣＣＨがドロップされてもよい。ＳＲ−ＰＵＣＣＨとＨＡＲＱ−ＡＣＫ−ＰＵＣＣＨとの送信時点が重なる場合、一般には、ＳＲがドロップされてＨＡＲＱ−ＡＣＫ  ＰＵＣＣＨのみが送信されてもよいが、ＳＲのサービスタイプ及び／又はレイテンシの要求事項などを考慮して、ＵＲＬＬＣトラフィックのための、又は低レイテンシのためのスケジューリング要求である場合には、ＨＡＲＱ−ＡＣＫ  ＰＵＣＣＨがドロップされてＳＲを送信するＰＵＣＣＨのみが送信されてもよい。このオプションは、ｘ＞ｙである場合にも同様に適用されてもよい。
【０１６７】
ケース２：ｘ＞ｙ
【０１６８】
オプション２−１：ＨＡＲＱ−ＡＣＫ情報がＳＲを送信するためのＰＵＣＣＨの一部に含まれてもよい。具体的には、シーケンスベースのＰＵＣＣＨ形態でＳＲを送信する場合、各シンボルでシーケンスが繰り返される形態であってもよいため、ＨＡＲＱ−ＡＣＫの送信タイミングに該当する時点（例えば、時間軸のシンボルに該当するリソース）でのみ該当時間リソースに送信されるシーケンスのリソース（例えば、巡回シフト及び／又は物理領域リソース）をさらに用いて、ＨＡＲＱ−ＡＣＫ情報を含んでＰＵＣＣＨが送信されてもよい。また、ＨＡＲＱ−ＡＣＫの送信タイミングに該当する時点以後から予め定義／約束されたか、シグナリングされた時点又はＰＵＣＣＨの最後のシンボルまでのシーケンスのリソース（例えば、巡回シフト及び／又は物理領域リソース）をさらに用いて、ＨＡＲＱ−ＡＣＫ情報を含んでＰＵＣＣＨが送信されてもよい。このとき、ＨＡＲＱ−ＡＣＫペイロードサイズ及び／又はＨＡＲＱ−ＡＣＫとＳＲとを合わせた全体のペイロードサイズ及び／又はＳＲ  ＰＵＣＣＨのＴＴＩ長／ニューマロロジ及び／又はＳＲ  ＰＵＣＣＨのフォーマットなどによって、実際にＨＡＲＱ−ＡＣＫとＳＲが送信されるＰＵＣＣＨフォーマット及び／又はＴＴＩ長が変更されてもよい。
【０１６９】
オプション２−２：ＨＡＲＱ−ＡＣＫ情報がＳＲを送信するためのＰＵＣＣＨの全体に含まれて送信されてもよい。この場合、ＨＡＲＱ−ＡＣＫペイロードサイズ及び／又はＨＡＲＱ−ＡＣＫとＳＲとを合わせた全体のペイロードサイズ及び／又はＳＲ  ＰＵＣＣＨのＴＴＩ長／ニューマロロジ及び／又はＳＲ  ＰＵＣＣＨのフォーマットなどを考慮して、フォーマット適応（format adaptation）を通じてＨＡＲＱ−ＡＣＫ情報がＳＲと共に１つのＰＵＣＣＨチャネルに送信されてもよい。
【０１７０】
オプション２−３：ＨＡＲＱ−ＡＣＫが、ＳＲを送信するＰＵＣＣＨをパンクチャ又はレートマッチングして送信されるように規則が定義されてもよい。具体的には、このとき、パンクチャ又はレートマッチングされるＰＵＣＣＨ内の時間リソースは、ＨＡＲＱ−ＡＣＫの本来の送信タイミングに該当する区間の間にのみ限られてもよい。また、パンクチャ又はレートマッチングされるＰＵＣＣＨ内の時間リソースは、ＨＡＲＱ−ＡＣＫの本来の送信タイミング以後に、ＰＵＣＣＨの最後のシンボル又は予め定義／約束された区間の間、又は上位層／物理層信号を通じて設定／指示された区間の間にのみ限られてもよい。
【０１７１】
オプション２−４：本来のＨＡＲＱ−ＡＣＫ送信タイミング以後、最も早いＵＬ送信可能スロット／ミニスロットなどでＨＡＲＱ−ＡＣＫが優先して送信されるように規則が定義されてもよい。
【０１７２】
オプション２−５：重畳時点がｙ−シンボルＰＵＣＣＨのＳＲリソースのタイミングに該当しない場合（すなわち、ｙ−シンボルＰＵＣＣＨが該当重畳時点に有効なＳＲリソースを含まない場合）、ＳＲは送信されなくてもよい（ｘ−シンボルＰＵＣＣＨそのものもドロップされ得る）。上記ＳＲ送信は、予め設定された（又は、シグナリングされた）周期及びオフセットによって決定された次の送信時点に遅延されるように規則が定義されてもよい。また、ＳＲは送信されず（ｘ−シンボルＰＵＣＣＨそのものもドロップされ得る）、本来のＳＲ送信タイミング以後に、最も早いＳＲ送信有効リソースから送信されるように規則が定義されてもよい。
【０１７３】
換言すれば、上記重畳時点においてｙ−シンボルＰＵＣＣＨが有効なＳＲリソースを含む場合、ｘ−シンボルＰＵＣＣＨで送信しようとしたＳＲは、ｙ−シンボルＰＵＣＣＨ上から送信されてもよく、そうでない場合は、ＳＲの送信はドロップされてもよい。
【０１７４】
ｘ−シンボルＰＵＣＣＨによって送信されるＳＲとＳＲＳとの送信時点が重なる場合、当該ＳＲ及びＳＲＳの具体的な送信方法を提案する。
【０１７５】
オプション１：ＳＲＳをドロップしてＳＲを送信するように規則が定義されてもよい。このとき、ＳＲＳのドロップは、ＳＲＳのＴＴＩ長が所定値未満であるときにのみ適用されるように規則が定義されてもよい。ＳＲＳのＴＴＩ長が所定値以上である場合には、ＳＲをドロップしたり、ＳＲ送信区間の間にのみＳＲＳ送信をパンクチャして、ＳＲが送信されるように規則が定義されてもよい。
【０１７６】
オプション２：ＳＲ送信ＰＵＣＣＨのＴＴＩ長が所定値未満である場合、ＳＲＳをドロップして、所定値以上である場合には、ＳＲ送信をパンクチャして、ＳＲＳが送信されるように規則が定義されてもよい。
【０１７７】
オプション３：ＳＲＳとＳＲとが同時送信されるように規則が定義されてもよい。具体的には、上記同時送信は、相違するＴＴＩ長及び／又はニューマロロジに該当するＳＲＳとＳＲとの同時送信に対する端末の能力及び／又はネットワーク設定が存在する場合に限って許可されてもよい。具体的には、上記同時送信は、上位層信号で設定された、又は物理層信号によって指示されたＳＲＳ及びＳＲ  ＰＵＣＣＨのＵＬ波形がＣＰ−ＯＦＤＭである場合に限って許可されてもよい。２つ（両者）のうちの１つ（一方）でもＳＣ−ＦＤＭＡである場合には、上述した端末の能力及び／又はネットワーク設定を無視して１つがドロップされてもよい。ＳＲ−ＰＵＣＣＨとＳＲＳとの送信時点が重なる場合、一般には、ＳＲＳがドロップされてＳＲ  ＰＵＣＣＨのみが送信されてもよいが、（ビーム管理の用途などによって）ＳＲＳの優先順位がＳＲより高いと設定／定義される場合には、ＳＲをドロップしてＳＲＳを送信してもよい。
【０１７８】
肯定ＳＲのみ送信するためのリソース設定（resource configuration for positive SR only transmission）
【０１７９】
以下のような合意（協定）（agreements）が決定された。
【０１８０】
■上位層によって設定された４個のｓＰＵＣＣＨリソースのうちの１つは、少なくとも以下のｓＰＵＣＣＨフォーマットのためにｓＤＣＩ１の２ビットフィールドによって指示される。
【０１８１】
−２ビットを超えるＡＣＫ／ＮＡＣＫ＋ＳＲを載せる（carrying）２／３−ＯＳ  ｓＰＵＣＣＨフォーマット
【０１８２】
−２ビットのＡＣＫ／ＮＡＣＫまで載せる２／３−ＯＳ  ｓＰＵＣＣＨフォーマット、上位層によって設定された４個のｓＰＵＣＣＨリソースグループのうちの１つは、ｓＤＣＩ１の２ビットフィールドによって指示される。各グループは、上位層によって設定される（予想される数のＨＡＲＱ−ＡＣＫビットに依存する）２〜４個のｓＰＵＣＣＨリソースを含む。
【０１８３】
−２ビットを超えるＡＣＫ／ＮＡＣＫ＋ＳＲを載せる（carrying）７−ＯＳ  ｓＰＵＣＣＨフォーマット
【０１８４】
−２ビットのＡＣＫ／ＮＡＣＫまで載せる７−ＯＳ  ｓＰＵＣＣＨフォーマット。
【０１８５】
■２つのｓＰＵＣＣＨリソースがＳＲ及び１ビットのＨＡＲＱ−ＡＣＫのために設定される。
【０１８６】
−肯定ＳＲと１ビットＨＡＲＱ−ＡＣＫとが同一のｓＴＴＩで２／３シンボルｓＰＵＣＣＨ上で送信される必要がある場合、１つのリソースがＳＲ＋ＡＣＫのために用いられ、他方のものがＳＲ＋ＮＡＣＫに用いられる。
【０１８７】
■１／２ビットＨＡＲＱ−ＡＣＫが２／３−ＯＳ  ｓＰＵＣＣＨ上で送信される必要があり、同一のｓＴＴＩで２／３シンボルｓＰＵＣＣＨ上で送信される必要がある場合、ＨＡＲＱ−ＡＣＫは、ＨＡＲＱ−ＡＣＫのためのｓＰＵＣＣＨリソース上で送信される。
【０１８８】
このように、ｓＴＴＩが設定された端末が、１／２ビットＨＡＲＱ−ＡＣＫ又は１／２ビットHＡＲＱ−ＡＣＫ＋肯定ＳＲを２／３−ＯＳ（OFDM symbol）ｓＰＵＣＣＨに送信する必要がある場合、４個のリソースグループのうちＡＲＩ（ACK/NACK Resource Indicator）で指示された１つのグループ内で予め−設定されたｓＰＵＣＣＨリソースを用いることになる。ＰＤＳＣＨスケジューリングがなく、それに対応するＨＡＲＱ−ＡＣＫビット無しで肯定ＳＲのみを送信しなければならない場合、ＡＲＩもないはずであるため、いずれのリソースを用いて当該肯定ＳＲを送信するかに対する方法が必要となり得る。
【０１８９】
１つの方法として、従来のＬＴＥのように、ＳＲのための別のｓＰＵＣＣＨリソースを設定することであるが、ｓＰＵＣＣＨ送信のため過度にリソースをリザーブしてしまうことがある。それを緩和するための方法として、肯定ＳＲのみを送信するための別のリソースをリザーブせず、上記複数のリソースグループのうち予め約束された（又は、上位層信号を通じて設定された、又は物理層信号を通じて指示された）１つのリソースグループ内の特定のリソースが、肯定ＳＲのみを送信するための送信に用いられるように規則が定義されてもよい。
【０１９０】
一例として、リソースグループのうち最も低いインデックスを有するリソースグループの｛ＮＡＣＫ｝及び／又は｛ＮＡＣＫ，ＮＡＣＫ｝状態に対応するリソースが、肯定ＳＲのみの送信に用いられてもよい。また、別の一例として、予め約束／定義された数のリソース（例えば、２個又は４個）を有するリソースグループのうちの１つのリソースグループ内の特定のリソースが、肯定ＳＲのみの送信に用いられてもよい。
【０１９１】
上述した提案方式に対する一例も本発明の具現方法のうちの１つとして含まれてもよいため、一種の提案方式としてみなされるのは明白である。また、説明した提案方式は、独立して具現されてもよく、一部の提案方式の組み合わせ（又は、併合）の形態で具現されてもよい。提案方法の適用可否情報（又は、上述した提案方法の規則に関する情報）は、基地局が端末に予め定義されたシグナル（例えば、物理層シグナル又は上位層シグナル）を通じて知らせるように規則が定義されてもよい。
【０１９２】
図９は、本発明の実施例を実行する送信装置１０及び受信装置２０の構成要素を示すブロック図である。送信装置１０及び受信装置２０は、情報及び／又はデータ、信号、メッセージなどを運ぶ無線信号を送信又は受信できる送信器／受信器１３，２３と、無線通信システム内の通信と関連する各種情報を記憶するメモリ１２，２２と、送信器／受信器１３，２３及びメモリ１２，２２などの構成要素と動作的に（operatively）接続してこれらの構成要素を制御し、当該装置が前述の本発明の実施例の少なくとも一つを実行するようにメモリ１２，２２及び／又は送信器／受信器１３，２３を制御するように構成されたプロセッサ１１，２１と、をそれぞれ備える。
【０１９３】
メモリ１２，２２は、プロセッサ１１，２１の処理及び制御のためのプログラムを記憶することができ、入／出力される情報を一時的に（仮）（temporarily）記憶することができる。メモリ１２，２２がバッファとして活用されてもよい。プロセッサ１１，２１は、一般に、送信装置又は受信装置内の各種モジュールの動作全般を制御する。特に、プロセッサ１１，２１は、本発明を実行するための各種制御機能を果たすことができる。プロセッサ１１，２１をコントローラ（controller）、マイクロコントローラ（microcontroller）、マイクロプロセッサ（microprocessor）、マイクロコンピュータ（microcomputer）などと呼ぶこともできる。プロセッサ１１，２１は、ハードウェア（hardware）又はファームウェア（firmware）、ソフトウェア、又はこれらの結合によって具現されてもよい。ハードウェアを用いて本発明を具現する場合は、本発明を実行するように構成されたＡＳＩＣｓ（Application Specific Integrated Circuits）、ＤＳＰｓ（Digital Signal Processors）、ＤＳＰＤｓ（Digital Signal Processing Devices）、ＰＬＤｓ（Programmable Logic Devices）、ＦＰＧＡｓ（Field Programmable Gate Arrays）などがプロセッサ１１，２１に設けられてもよい。一方、ファームウェアやソフトウェアを用いて本発明を具現する場合は、本発明の機能又は動作を実行するモジュール、手順又は関数などを含むようにファームウェアやソフトウェアが構成されてもよい。本発明を実行できるように構成されたファームウェア又はソフトウェアは、プロセッサ１１，２１内に設けられたり、メモリ１２，２２に記憶されてプロセッサ１１，２１によって駆動されてもよい。
【０１９４】
送信装置１０におけるプロセッサ１１は、プロセッサ１１又はプロセッサ１１に接続しているスケジューラからスケジューリングされて、外部に送信される信号及び／又はデータに対して所定の符号化（coding）及び変調（modulation）を行った後、送信器／受信器１３に送信する。例えば、プロセッサ１１は、送信しようとするデータ列を逆多重化、チャネル符号化、スクランブル、及び変調の過程などを経てＫ個のレイヤに変換する。符号化されたデータ列は、コードワードとも呼ばれ、ＭＡＣ層が提供するデータブロックである伝送ブロックと等価である。一つの伝送ブロック（Transport Block，ＴＢ）は一つのコードワードに符号化され、各コードワードは、一つ又は複数のレイヤの形態で受信装置に送信される。周波数アップ変換のために送信器／受信器１３は、オシレータ（oscillator）を含むことができる。送信器／受信器１３は、Ｎｔ個（Ｎｔは１以上の正の整数）の送信アンテナを含むことができる。
【０１９５】
受信装置２０の信号処理過程は、送信装置１０の信号処理過程の逆となる。プロセッサ２１の制御下で、受信装置２０の送信器／受信器２３は、送信装置１０から送信された無線信号を受信する。送信器／受信器２３は、Ｎｒ個の受信アンテナを含むことができ、送信器／受信器２３は、受信アンテナから受信した信号のそれぞれを周波数ダウン（下り）変換して（frequency down-convert）ベースバンド信号に復元する。送信器／受信器２３は、周波数ダウン変換のためにオシレータを含むことができる。プロセッサ２１は、受信アンテナから受信した無線信号に対する復号（decoding）及び復調（demodulation）を行い、送信装置１０が本来送信しようとしたデータに復元することができる。
【０１９６】
送信器／受信器１３，２３は、一つ又は複数のアンテナを具備する。アンテナは、プロセッサ１１，２１の制御下で、本発明の一実施例によって、送信器／受信器１３，２３で処理された信号を外部に送信したり、外部から無線信号を受信して送信器／受信器１３，２３に伝達する機能を果たす。アンテナは、アンテナポートと呼ばれることもある。各アンテナは、１つの物理アンテナに該当したり、２以上の物理アンテナ要素（element）の組み合わせによって構成されてもよい。各アンテナから送信された信号は、受信装置２０によってそれ以上分解されることはない。当該アンテナに対応して送信された参照信号（Reference Signal，ＲＳ）は、受信装置２０の観点で見たアンテナを定義し、チャネルが一つの物理アンテナからの単一（single）無線チャネルであるか、或いは当該アンテナを含む複数の物理アンテナ要素（element）からの合成（composite）チャネルであるかに関係なく、受信装置２０による当該アンテナに対するチャネル推定を可能にする。すなわち、アンテナは、該アンテナ上のシンボルを伝達するチャネルが、同一のアンテナ上の他のシンボルが伝達されるチャネルから導出されるように定義される。複数のアンテナを用いてデータを送受信する多入力多出力（Multi-Input Multi-Output、ＭＩＭＯ）機能をサポートする送信器／受信器の場合は、２個以上のアンテナに接続されてもよい。
【０１９７】
本発明の実施例において、端末又はＵＥは、上りリンクでは送信装置１０として動作し、下りリンクでは受信装置２０として動作する。本発明の実施例において、基地局又はｅＮＢは、上りリンクでは受信装置２０として動作し、下りリンクでは送信装置１０として動作する。
【０１９８】
送信装置及び／又は受信装置は、上述した本発明の実施例のうちの少なくとも１つ又は２つ以上の実施例の組み合わせを実行することができる。
【０１９９】
このような実施例のうちの１つとして、無線通信システムにおいて、複数のＴＴＩ（Transmission Time Interval）長をサポートする端末のためのスケジューリング要求（Scheduling Request；ＳＲ）送信方法であって、上記方法は端末によって行われ、下りリンクデータを受信するステップと、上記下りリンクデータに対応するＨＡＲＱ−ＡＣＫ（hybrid automatic retransmission request-acknowledgement/non-acknowledgement）送信のための第１のＴＴＩ長の第１の物理上りリンク制御チャネル（Physical Uplink Control Channel；ＰＵＣＣＨ）とＳＲ送信のための第２のＰＵＣＣＨとの送信時点が重なる場合、第１のＰＵＣＣＨで上記ＨＡＲＱ−ＡＣＫを送信するステップを含んでもよい。上記第１のＰＵＣＣＨは、第２のＰＵＣＣＨよりも少ない数のシンボルからなり、上記第１のＰＵＣＣＨが有効なＳＲリソースを含まない場合、上記ＳＲは送信されなくてもよい。
【０２００】
ここで、上記第１のＰＵＣＣＨが有効なＳＲリソースを含む場合、上記ＳＲは上記第１のＰＵＣＣＨで送信されてもよい。
【０２０１】
また、上記ＳＲは、上りリンク承認の不要な上りリンク送信に対する要求又はリソース設定要求を含んでもよい。
【０２０２】
また、上記ＳＲは、複数のビットで表現され、上記複数のビットで表現される各状態は、上記上りリンク送信に関連するＨＡＲＱプロセス番号に関係付けられ（連動され）（linked）てもよい。
【０２０３】
また、上記ＳＲは、複数のビットで表現され、上記複数のビットと上記上りリンク送信が送信されるリソースとの組み合わせによって、上記上りリンク送信に関連するＨＡＲＱプロセス番号が決定されてもよい。
【０２０４】
また、上記ＳＲ及び上記ＨＡＲＱ−ＡＣＫの送信時点とバッファ状態報告（Buffer State Report；ＢＳＲ）の送信時点とが重なる場合、上記ＳＲ、上記ＨＡＲＱ−ＡＣＫ及び上記ＢＳＲのうち２種類の情報がバンドリングされて送信される変調シンボルの状態にマッピングされてもよい。
【０２０５】
また、上記ＳＲ及びＨＡＲＱ−ＡＣＫの送信時点とバッファ状態報告（Buffer State Report；ＢＳＲ）の送信時点とが重なる場合、変更されたＰＵＣＣＨフォーマットを用いるか、より多くのリソースブロックを用いて上記ＳＲ、上記ＨＡＲＱ−ＡＣＫ及び上記ＢＳＲのいずれも第１のＰＵＣＣＨ上で送信されてもよい。
【０２０６】
また、上記ＳＲは、特定のサービス又は特定の要求事項のためであり、上記有効なＳＲリソースの時間間隔又は周期は、通常のデータトラフィックのためのＳＲリソースの時間間隔又は周期より短くてもよい。
【０２０７】
上述したように、開示された本発明の好適な実施例に関する詳細な説明は、当業者が本発明を具現して実施し得るように提供された。以上では、本発明の好適な実施例を参照して説明したが、当該技術の分野における熟練した者には、添付の特許請求の範囲に記載された本発明を様々に修正及び変更できるということが理解できる。したがって、本発明は、ここに示した実施の形態に制限されるものではなく、ここに開示された原理及び新規な特徴と一致する最も広い範囲を付与するためのものである。
【産業上の利用可能性】
【０２０８】
本発明は、端末、リレー、基地局などの無線通信装置に利用可能である。
【図１】
2019530382.tif 000030
【図２】
2019530382.tif 000031
【図３】
2019530382.tif 000032
【図４】
2019530382.tif 000033
【図５】
2019530382.tif 000034
【図６】
2019530382.tif 000035
【図７】
2019530382.tif 000036
【図８】
2019530382.tif 000037
【図９】
2019530382.tif 000038
【手続補正書】
【提出日】平成31年3月6日(2019.3.6)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
無線通信システムにおいて、複数の送信時間間隔（Transmission Time Interval；ＴＴＩ）長をサポートする端末のための制御情報を送信する方法であって、前記方法は前記端末によって行われ、
下りリンクデータを受信するステップと、
前記下りリンクデータに対応するハイブリッド自動再送要求確認応答／否定応答（Hybrid Automatic Retransmission reQuest-ACKnowledgement/Non-ACKnowledgement；ＨＡＲＱ−ＡＣＫ）を送信する第１の物理上りリンク制御チャネル（Physical Uplink Control CHannel；ＰＵＣＣＨ）の送信時点とスケジューリング要求（Scheduling Request；ＳＲ）を送信する第２のＰＵＣＣＨの送信時点とが互いに重なる場合、
前記第１のＰＵＣＣＨで前記ＨＡＲＱ−ＡＣＫを送信するステップと、を有し、
前記第１のＰＵＣＣＨは、前記第２のＰＵＣＣＨより少ない数のシンボルを有し、
前記第１のＰＵＣＣＨと前記第２のＰＵＣＣＨとが互いに重なる時点が、前記第１のＰＵＣＣＨのＳＲ送信時点に対応しない場合、前記ＳＲは送信されない、方法。
【請求項２】
前記第１のＰＵＣＣＨと前記第２のＰＵＣＣＨとが互いに重なる前記時点が前記第１のＰＵＣＣＨのＳＲ送信時点に対応する場合、前記ＳＲは、前記第１のＰＵＣＣＨで送信される、請求項１に記載の方法。
【請求項３】
前記ＳＲは、上りリンク承認が不要な上りリンク送信に対する要求又はリソース設定要求を有する、請求項１に記載の方法。
【請求項４】
前記ＳＲは複数のビットで表現され、前記複数のビットで表現される各状態は、前記上りリンク送信に関連するＨＡＲＱプロセス番号に関係付けられる、請求項３に記載の方法。
【請求項５】
前記ＳＲは複数のビットで表現され、前記複数のビットと前記上りリンク送信が送信されるリソースとの組み合わせによって、前記上りリンク送信に関連するＨＡＲＱプロセス番号が決定される、請求項３に記載の方法。
【請求項６】
前記ＳＲ及び前記ＨＡＲＱ−ＡＣＫの送信時点とバッファ状態報告（Buffer State Report；ＢＳＲ）の送信時点とが互いに重なる場合、
前記ＳＲ、前記ＨＡＲＱ−ＡＣＫ及び前記ＢＳＲのうち２種類の情報がバンドリングされて、送信される変調シンボルの状態にマッピングされる、請求項１に記載の方法。
【請求項７】
前記ＳＲ及び前記ＨＡＲＱ−ＡＣＫの送信時点とバッファ状態報告（Buffer State Report；ＢＳＲ）の送信時点とが互いに重なる場合、
変更されたＰＵＣＣＨフォーマットを用いるか、又はより多くのリソースブロックを用いて、前記ＳＲ、前記ＨＡＲＱ−ＡＣＫ及び前記ＢＳＲの全てが第１のＰＵＣＣＨ上で送信される、請求項１に記載の方法。
【請求項８】
前記ＳＲは、特定のサービス又は特定の要求事項のためのものであり、前記第１のＰＵＣＣＨの前記ＳＲ送信時点の時間間隔又は周期は、通常のデータトラフィックのためのＳＲ送信時点の時間間隔又は周期より短い、請求項１に記載の方法。
【請求項９】
無線通信システムにおいて、複数の送信時間間隔（Transmission Time Interval；ＴＴＩ）長をサポートし、制御情報を送信する端末であって、前記端末は、
受信器及び送信器と、
前記受信器及び送信器を制御するプロセッサと、を有し、
前記プロセッサは、
下りリンクデータを受信し、
前記下りリンクデータに対応するハイブリッド自動再送要求確認応答／否定応答（Hybrid Automatic Retransmission reQuest-ACKnowledgement/Non-ACKnowledgement；ＨＡＲＱ−ＡＣＫ）を送信する第１の物理上りリンク制御チャネル（Physical Uplink Control CHannel；ＰＵＣＣＨ）の送信時点とスケジューリング要求（Scheduling Request；ＳＲ）を送信する第２のＰＵＣＣＨの送信時点とが互いに重なる場合、
前記第１のＰＵＣＣＨで前記ＨＡＲＱ−ＡＣＫを送信し、
前記第１のＰＵＣＣＨは、前記第２のＰＵＣＣＨより少ない数のシンボルを有し、
前記第１のＰＵＣＣＨと前記第２のＰＵＣＣＨとが互いに重なる時点が、前記第１のＰＵＣＣＨのＳＲ送信時点に対応しない場合、前記ＳＲは送信されない、端末。
【請求項１０】
前記第１のＰＵＣＣＨと前記第２のＰＵＣＣＨとが互いに重なる前記時点が前記第１のＰＵＣＣＨのＳＲ送信時点に対応する場合、前記ＳＲは、前記第１のＰＵＣＣＨで送信される、請求項９に記載の端末。
【請求項１１】
前記ＳＲは、上りリンク承認が不要な上りリンク送信に対する要求又はリソース設定要求を有する、請求項９に記載の端末。
【請求項１２】
前記ＳＲは複数のビットで表現され、前記複数のビットで表現される各状態は、前記上りリンク送信に関連するＨＡＲＱプロセス番号に関係付けられる、請求項１１に記載の端末。
【請求項１３】
前記ＳＲは複数のビットで表現され、前記複数のビットと前記上りリンク送信が送信されるリソースとの組み合わせによって、前記上りリンク送信に関連するＨＡＲＱプロセス番号が決定される、請求項１１に記載の端末。
【請求項１４】
前記ＳＲ及び前記ＨＡＲＱ−ＡＣＫの送信時点とバッファ状態報告（Buffer State Report；ＢＳＲ）の送信時点とが互いに重なる場合、
前記ＳＲ、前記ＨＡＲＱ−ＡＣＫ及び前記ＢＳＲのうち２種類の情報がバンドリングされて、送信される変調シンボルの状態にマッピングされる、請求項９に記載の端末。
【請求項１５】
前記ＳＲ及び前記ＨＡＲＱ−ＡＣＫの送信時点とバッファ状態報告（Buffer State Report；ＢＳＲ）の送信時点とが互いに重なる場合、
変更されたＰＵＣＣＨフォーマットを用いるか、又はより多くのリソースブロックを用いて、前記ＳＲ、前記ＨＡＲＱ−ＡＣＫ及び前記ＢＳＲの全てが第１のＰＵＣＣＨ上で送信される、請求項９に記載の端末。
【請求項１６】
前記ＳＲは、特定のサービス又は特定の要求事項のためのものであり、前記第１のＰＵＣＣＨの前記ＳＲ送信時点の時間間隔又は周期は、通常のデータトラフィックのためのＳＲ送信時点の時間間隔又は周期より短い、請求項９に記載の端末。
【請求項１７】
無線通信システムにおいて、複数の送信時間間隔（Transmission Time Interval；ＴＴＩ）長をサポートする端末が送信した制御情報を受信する方法であって、前記方法は基地局によって行われ、
下りリンクデータを送信するステップと、
前記下りリンクデータに対応するハイブリッド自動再送要求確認応答／否定応答（Hybrid Automatic Retransmission reQuest-ACKnowledgement/Non-ACKnowledgement；ＨＡＲＱ−ＡＣＫ）を送信する第１の物理上りリンク制御チャネル（Physical Uplink Control CHannel；ＰＵＣＣＨ）の送信時点とスケジューリング要求（Scheduling Request；ＳＲ）を送信する第２のＰＵＣＣＨの送信時点とが互いに重なる場合、
前記第１のＰＵＣＣＨで前記ＨＡＲＱ−ＡＣＫを受信するステップと、を有し、
前記第１のＰＵＣＣＨは、前記第２のＰＵＣＣＨより少ない数のシンボルを有し、
前記第１のＰＵＣＣＨと前記第２のＰＵＣＣＨとが互いに重なる時点が、前記第１のＰＵＣＣＨのＳＲ送信時点に対応しない場合、前記ＳＲは受信されない、方法。
【請求項１８】
前記第１のＰＵＣＣＨの送信時点と前記第２のＰＵＣＣＨの送信時点とは、完全に又は部分的に互いに重なる、請求項１に記載の方法。
【請求項１９】
前記第１のＰＵＣＣＨの送信時点と前記第２のＰＵＣＣＨの送信時点とは、完全に又は部分的に互いに重なる、請求項９に記載の端末。
【請求項２０】
複数の送信時間間隔（Transmission Time Interval；ＴＴＩ）長をサポートし、制御情報の送信を処理するプロセッサであって、前記プロセッサは、
受信器を介して下りリンクデータを受信し、
前記下りリンクデータに対応するハイブリッド自動再送要求確認応答／否定応答（Hybrid Automatic Retransmission reQuest-ACKnowledgement/Non-ACKnowledgement；ＨＡＲＱ−ＡＣＫ）を送信する第１の物理上りリンク制御チャネル（Physical Uplink Control CHannel；ＰＵＣＣＨ）の送信時点とスケジューリング要求（Scheduling Request；ＳＲ）を送信する第２のＰＵＣＣＨの送信時点とが互いに重なる場合、
送信器を介して前記第１のＰＵＣＣＨで前記ＨＡＲＱ−ＡＣＫを送信し、
前記第１のＰＵＣＣＨはｘ−シンボルで設定され、前記第２のＰＵＣＣＨはｙ−シンボルで設定され、ｘはｙより小さく、
前記第１のＰＵＣＣＨと前記第２のＰＵＣＣＨとが互いに重なる時点が、前記第１のＰＵＣＣＨのＳＲ送信時点に対応しない場合、前記ＳＲは送信されない、プロセッサ。
【国際調査報告】
2019530382.tif 000039
2019530382.tif 000040
2019530382.tif 000041
2019530382.tif 000042