JP2022502960A - Ｎｒ ｖ２ｘにおけるサイドリンクｈａｒｑフィードバックを送信する方法及び装置 - Google Patents

Abstract

第１の装置１００がＳＬ ＨＡＲＱ（Ｓｉｄｅｌｉｎｋ Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）フィードバックを送信する方法及びこれをサポートする装置が提供される。前記方法は、ＰＳＳＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）を第２の装置２００から受信するステップ；及び、前記ＰＳＳＣＨと関連したＳＬ ＨＡＲＱフィードバックを前記第２の装置２００に送信するステップ；を含み、前記ＳＬ ＨＡＲＱフィードバックが送信されるリソースは、前記第１の装置１００のＩＤ（ｉｄｅｎｔｉｆｉｅｒ）に基づいて決定される。

Description

[1] 本開示は、無線通信システムに関する。

[2] 移動通信システムは、可用なシステムリソース（例えば、帯域幅、送信パワー等）を共有して多重ユーザとの通信をサポートする多重アクセス（ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）システムである。多重アクセスシステムの例としては、ＣＤＭＡ（ｃｏｄｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）システム、ＦＤＭＡ（ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）システム、ＴＤＭＡ（ｔｉｍｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）システム、ＯＦＤＭＡ（ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）システム、ＳＣ−ＦＤＭＡ（ｓｉｎｇｌｅ ｃａｒｒｉｅｒ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）システム、ＭＣ−ＦＤＭＡ（ｍｕｌｔｉ ｃａｒｒｉｅｒ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）システム等がある。

[3] 一方、無線通信システムではデータの送／受信、システム同期取得、チャネル情報フィードバックなどのためにアップリンクチャネルまたはダウンリンクチャネルを推定する必要がある。無線通信システム環境では多重経路時間遅延によってフェーディングが発生するようになる。フェーディングによる急激な環境変化により発生する信号の歪曲を補償して送信信号を復元する過程をチャネル推定という。また、端末が属するセルまたは他のセルに対するチャネル状態（ｃｈａｎｎｅｌ ｓｔａｔｅ）を測定する必要がある。チャネル推定またはチャネル状態測定のために、一般的に送受信機が相互間に知っている参照信号（ＲＳ；ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）を利用してチャネル推定を実行するようになる。

[4] 端末は、下記の三つの方法で測定を実行することができる。

[5] １）ＲＳＲＰ（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ ｒｅｃｅｉｖｅｄ ｐｏｗｅｒ）：全帯域にわたって送信されるＣＲＳを運搬する全てのＲＥの平均受信電力を示す。このとき、ＣＲＳの代わりにＣＳＩ ＲＳを運搬する全てのＲＥの平均受信電力を測定することもできる。

[6] ２）ＲＳＳＩ（ｒｅｃｅｉｖｅｄ ｓｉｇｎａｌ ｓｔｒｅｎｇｔｈ ｉｎｄｉｃａｔｏｒ）：全体帯域で測定された受信電力を示す。ＲＳＳＩは、信号、干渉（ｉｎｔｅｒｆｅｒｅｎｃｅ）、熱雑音（ｔｈｅｒｍａｌ ｎｏｉｓｅ）を全て含む。

[7] ３）ＲＳＲＱ（ｒｅｆｅｒｅｎｃｅ ｓｙｍｂｏｌ ｒｅｃｅｉｖｅｄ ｑｕａｌｉｔｙ）：ＣＱＩを示し、測定帯域幅（ｂａｎｄｗｉｄｔｈ）またはサブバンドによるＲＳＲＰ／ＲＳＳＩに決定されることができる。即ち、ＲＳＲＱは、信号対雑音干渉比（ＳＩＮＲ；ｓｉｇｎａｌ−ｔｏ−ｎｏｉｓｅ ｉｎｔｅｒｆｅｒｅｎｃｅ ｒａｔｉｏ）を意味する。ＲＳＲＰは、十分な移動性（ｍｏｂｉｌｉｔｙ）情報を提供することができないため、ハンドオーバまたはセル再選択（ｃｅｌｌ ｒｅｓｅｌｅｃｔｉｏｎ）過程ではＲＳＲＰの代わりにＲＳＲＱが使われることができる。

[8] ＲＳＲＱ＝ＲＳＳＩ／ＲＳＳＰに算出されることができる。または、ＲＳＲＱ＝Ｎ＊ＲＳＳＩ／ＲＳＳに算出されることもできる。ここで、Ｎは、ＲＳＳＩを測定する帯域幅に関連した変数（例えば、ＰＲＢ個数）または関数である。

[9] 一方、サイドリンク（ｓｉｄｅｌｉｎｋ）とは、端末（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、ＵＥ）間に直接的なリンクを設定し、基地局（Ｂａｓｅ Ｓｔａｔｉｏｎ、ＢＳ）を経ずに、端末間で音声またはデータ等を直接やり取りをする通信方式をいう。サイドリンクは、急速に増加するデータトラフィックによる基地局の負担を解決することができる一つの案として考慮されている。

[10] Ｖ２Ｘ（ｖｅｈｉｃｌｅ−ｔｏ−ｅｖｅｒｙｔｈｉｎｇ）は、有／無線通信を介して他の車両、歩行者、インフラが構築されたモノ等と情報を交換する通信技術を意味する。Ｖ２Ｘは、Ｖ２Ｖ（ｖｅｈｉｃｌｅ−ｔｏ−ｖｅｈｉｃｌｅ）、Ｖ２Ｉ（ｖｅｈｉｃｌｅ−ｔｏ−ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）、Ｖ２Ｎ（ｖｅｈｉｃｌｅ−ｔｏ−ｎｅｔｗｏｒｋ）、及びＶ２Ｐ（ｖｅｈｉｃｌｅ−ｔｏ−ｐｅｄｅｓｔｒｉａｎ）のような４つの類型に区分できる。Ｖ２Ｘ通信は、ＰＣ５インターフェース及び／またはＵｕインターフェースを介して提供されることができる。

[11] 一方、より多くの通信機器がより大きな通信容量を要求することになり、これに伴って既存の無線アクセス技術（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ；ＲＡＴ）に比べて向上したモバイルブロードバンド（ｍｏｂｉｌｅ ｂｒｏａｄｂａｎｄ）通信に対する必要性が台頭している。これによって、信頼度（ｒｅｌｉａｂｉｌｉｔｙ）及び遅延（ｌａｔｅｎｃｙ）に敏感なサービスまたは端末を考慮した通信システムが議論されているが、改善されたモバイルブロードバンド通信、Ｍａｓｓｉｖｅ ＭＴＣ、ＵＲＬＬＣ（Ｕｌｔｒａ−Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）等を考慮した次世代の無線アクセス技術を新しいＲＡＴ（ｎｅｗ ｒａｄｉｏ ａｃｃｅｓｓ ｔｅｃｈｎｏｌｏｇｙ）またはＮＲ（ｎｅｗ ｒａｄｉｏ）と称し得る。ＮＲでも、Ｖ２Ｘ（ｖｅｈｉｃｌｅ−ｔｏ−ｅｖｅｒｙｔｈｉｎｇ）通信がサポートできる。

[12] 一方、例えば、高い信頼度の要求事項を有するサービスまたは相対的に高い信頼度の要求事項を有するサービスと関連したＳＬ通信の場合、端末のＳＬ ＨＡＲＱフィードバック動作及び／またはメカニズムが有用である。例えば、複数の端末がＨＡＲＱフィードバック送信を実行する場合、前記ＨＡＲＱフィードバック送信間に衝突が発生できる。これは、サービス遅延に引き継がれることができる。したがって、複数の端末がＨＡＲＱフィードバック送信を実行する場合、衝突を最小化する方法及びこれをサポートする装置が提案される必要がある。

[13] 一実施例において、第１の装置１００がＳＬ ＨＡＲＱ（Ｓｉｄｅｌｉｎｋ Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）フィードバックを送信する方法が提供される。前記方法は、ＰＳＳＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）を第２の装置２００から受信するステップ；及び、前記ＰＳＳＣＨと関連したＳＬ ＨＡＲＱフィードバックを前記第２の装置２００に送信するステップ；を含み、前記ＳＬ ＨＡＲＱフィードバックが送信されるリソースは、前記第１の装置１００のＩＤ（ｉｄｅｎｔｉｆｉｅｒ）に基づいて決定される。

[14] 他の実施例において、第２の装置２００がＳＬ ＨＡＲＱ（Ｓｉｄｅｌｉｎｋ Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）フィードバックを受信する方法が提供される。前記方法は、ＰＳＳＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）をグループ内の複数の端末に送信するステップ；及び、前記ＰＳＳＣＨと関連したＳＬ ＨＡＲＱフィードバックを前記複数の端末から受信するステップ；を含み、前記ＳＬ ＨＡＲＱフィードバックが受信されるリソースは、前記複数の端末のＩＤ（ｉｄｅｎｔｉｆｉｅｒ）に基づいて決定される。

[15] 他の実施例において、ＳＬ ＨＡＲＱ（Ｓｉｄｅｌｉｎｋ Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）フィードバックを送信する第１の装置１００が提供される。前記第１の装置１００は、一つ以上のメモリ；一つ以上の送受信機；及び、前記一つ以上のメモリと前記一つ以上の送受信機を連結する一つ以上のプロセッサ；を含む。前記プロセッサは、ＰＳＳＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）を第２の装置２００から受信するように前記送受信機１０６を制御し、及び前記ＰＳＳＣＨと関連したＳＬ ＨＡＲＱフィードバックを前記第２の装置２００に送信するように前記送受信機１０６を制御するように構成され、前記ＳＬ ＨＡＲＱフィードバックが送信されるリソースは、前記第１の装置１００のＩＤ（ｉｄｅｎｔｉｆｉｅｒ）に基づいて決定される。

[16] 端末がＳＬ通信を効率的に実行することができる。

[17] 図１は、本開示の一実施例に係る、ＬＴＥシステムの構造を示す。 [18] 図２は、本開示の一実施例に係る、ユーザ平面（ｕｓｅｒ ｐｌａｎｅ）に対する無線プロトコル構造（ｒａｄｉｏ ｐｒｏｔｏｃｏｌ ａｒｃｈｉｔｅｃｔｕｒｅ）を示す。 [19] 図３は、本開示の一実施例に係る、制御平面（ｃｏｎｔｒｏｌ ｐｌａｎｅ）に対する無線プロトコル構造（ｒａｄｉｏ ｐｒｏｔｏｃｏｌ ａｒｃｈｉｔｅｃｔｕｒｅ）を示す。 [20] 図４は、本開示の一実施例に係る、ＮＲシステムの構造を示す。 [21] 図５は、本開示の一実施例に係る、ＮＧ−ＲＡＮと５ＧＣとの間の機能的分割を示す。 [22] 図６は、本開示の一実施例に係る、ＮＲの無線フレームの構造を示す。 [23] 図７は、本開示の一実施例に係る、ＮＲフレームのスロット構造を示す。 [24] 図８は、本開示の一実施例に係る、ＢＷＰの一例を示す。 [25] 図９は、本開示の一実施例に係る、ＳＬ通信のための無線プロトコル構造（ｒａｄｉｏ ｐｒｏｔｏｃｏｌ ａｒｃｈｉｔｅｃｔｕｒｅ）を示す。 [26] 図１０は、本開示の一実施例に係る、ＳＬ通信のための無線プロトコル構造（ｒａｄｉｏ ｐｒｏｔｏｃｏｌ ａｒｃｈｉｔｅｃｔｕｒｅ）を示す。 [27] 図１１は、本開示の一実施例に係る、Ｖ２ＸまたはＳＬ通信を実行する端末を示す。 [28] 図１２は、本開示の一実施例に係る、Ｖ２ＸまたはＳＬ通信のためのリソース単位を示す。 [29] 図１３は、本開示の一実施例によって、端末がＴＭ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｍｏｄｅ）によってＶ２ＸまたはＳＬ通信を実行する手順を示す。 [30] 図１４は、本開示の一実施例によって、端末が送信リソースを選択する方法を示す。 [31] 図１５は、本開示の一実施例に係る、三つのキャストタイプを示す。 [32] 図１６は、本開示の一実施例によって、端末がＨＡＲＱフィードバックを送受信する手順を示す。 [33] 図１７は、本開示の一実施例に係るＨＡＲＱフィードバックリソースを示す。 [34] 図１８は、本開示の一実施例によって、グループキャストＳＬ通信で、端末がＨＡＲＱフィードバックを送受信する手順を示す。 [35] 図１９は、本開示の一実施例によって、端末がＨＡＲＱフィードバックを送受信する手順を示す。 [36] 図２０は、本開示の一実施例によって、端末がＨＡＲＱフィードバックを送受信する手順を示す。 [37] 図２１は、本開示の一実施例によって、第１の装置１００がＳＬ ＨＡＲＱフィードバックを送信する手順を示す。 [38] 図２２は、本開示の一実施例によって、第２の装置２００がＳＬ ＨＡＲＱフィードバックを受信する手順を示す。 [39] 図２３は、本開示の一実施例に係る、通信システム１を示す。 [40] 図２４は、本開示の一実施例に係る、無線機器を示す。 [41] 図２５は、本開示の一実施例に係る、送信信号のための信号処理回路を示す。 [42] 図２６は、本開示の一実施例に係る、無線機器を示す。 [43] 図２７は、本開示の一実施例に係る、携帯機器を示す。 [44] 図２８は、本開示の一実施例に係る、車両または自律走行車両を示す。 [45] 図２９は、本開示の一実施例に係る、車両を示す。 [46] 図３０は、本開示の一実施例に係る、ＸＲ機器を示す。 [47] 図３１は、本開示の一実施例に係る、ロボットを示す。 [48] 図３２は、本開示の一実施例に係る、ＡＩ機器を示す。

[49] 本開示の多様な実施例において、“／”及び“、”は“及び／または”を意味すると解釈されなければならない。例えば、“Ａ／Ｂ”は“Ａ及び／またはＢ”を意味することができる。なお、“Ａ、Ｂ”は“Ａ及び／またはＢ”を意味することができる。また、“Ａ／Ｂ／Ｃ”は“Ａ、Ｂ及び／またはＣのうち少なくともいずれか一つ”を意味することができる。また、“Ａ、Ｂ、Ｃ”は“Ａ、Ｂ及び／またはＣのうち少なくともいずれか一つ”を意味することができる。

[50] さらに、本開示の多様な実施例において、“または”は“及び／または”を意味すると解釈されなければならない。例えば、“ＡまたはＢ”は“ただＡ”、“ただＢ”、及び／または“Ａ及びＢの両方とも”を含むことができる。即ち、本開示の多様な実施例において、“または”は“付加的にまたは代案として”を意味すると解釈されなければならない。

[51] 以下の技術は、ＣＤＭＡ（ｃｏｄｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）、ＦＤＭＡ（ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）、ＴＤＭＡ（ｔｉｍｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）、ＯＦＤＭＡ（ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）、ＳＣ−ＦＤＭＡ（ｓｉｎｇｌｅ ｃａｒｒｉｅｒ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）などの様々な無線通信システムに使用されることができる。ＣＤＭＡは、ＵＴＲＡ（ｕｎｉｖｅｒｓａｌ ｔｅｒｒｅｓｔｒｉａｌ ｒａｄｉｏ ａｃｃｅｓｓ）やＣＤＭＡ２０００のような無線技術で実現されることができる。ＴＤＭＡは、ＧＳＭ（ｇｌｏｂａｌ ｓｙｓｔｅｍ ｆｏｒ ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）／ＧＰＲＳ（ｇｅｎｅｒａｌ ｐａｃｋｅｔ ｒａｄｉｏ ｓｅｒｖｉｃｅ）／ＥＤＧＥ（ｅｎｈａｎｃｅｄ ｄａｔａ ｒａｔｅｓ ｆｏｒ ＧＳＭ ｅｖｏｌｕｔｉｏｎ）のような無線技術で実現されることができる。ＯＦＤＭＡは、ＩＥＥＥ（ｉｎｓｔｉｔｕｔｅ ｏｆ ｅｌｅｃｔｒｉｃａｌ ａｎｄ ｅｌｅｃｔｒｏｎｉｃｓ ｅｎｇｉｎｅｅｒｓ） ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ ８０２−２０、Ｅ−ＵＴＲＡ（ｅｖｏｌｖｅｄ ＵＴＲＡ）などの無線技術で実現されることができる。ＩＥＥＥ ８０２．１６ｍはＩＥＥＥ ８０２．１６ｅの進化であって、ＩＥＥＥ ８０２．１６ｅに基づくシステムとの下位互換性（ｂａｃｋｗａｒｄ ｃｏｍｐａｔｉｂｉｌｉｔｙ）を提供する。ＵＴＲＡは、ＵＭＴＳ（ｕｎｉｖｅｒｓａｌ ｍｏｂｉｌｅ ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｓｙｓｔｅｍ）の一部である。３ＧＰＰ（３ｒｄ ｇｅｎｅｒａｔｉｏｎ ｐａｒｔｎｅｒｓｈｉｐ ｐｒｏｊｅｃｔ）ＬＴＥ（ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ）は、Ｅ−ＵＴＲＡ（ｅｖｏｌｖｅｄ−ＵＭＴＳ ｔｅｒｒｅｓｔｒｉａｌ ｒａｄｉｏ ａｃｃｅｓｓ）を使用するＥ−ＵＭＴＳ（ｅｖｏｌｖｅｄ ＵＭＴＳ）の一部であって、ダウンリンクでＯＦＤＭＡを採用し、アップリンクでＳＣ−ＦＤＭＡを採用する。ＬＴＥ−Ａ（ａｄｖａｎｃｅｄ）は３ＧＰＰ ＬＴＥの進化である。

[52] ５Ｇ ＮＲはＬＴＥ−Ａの後続技術であって、高性能、低遅延、高可用性などの特性を有する新しいＣｌｅａｎ−ｓｌａｔｅの形態の移動通信システムである。５Ｇ ＮＲは、１ＧＨｚ未満の低周波帯域から１ＧＨｚ〜１０ＧＨｚの中間周波帯域、２４ＧＨｚ以上の高周波（ミリ波）帯域などの使用可能な全てのスペクトルリソースを活用することができる。

[53] 説明を明確にするために、ＬＴＥ−Ａまたは５Ｇ ＮＲを中心に記述するが、本開示の技術的思想がこれに制限されるものではない。

[54] 図１は、本開示の一実施例に係る、ＬＴＥシステムの構造を示す。これはＥ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）、またはＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）／ＬＴＥ−Ａシステムと呼ばれることができる。

[55] 図１を参照すると、Ｅ−ＵＴＲＡＮは、端末１０にコントロールプレーン（ｃｏｎｔｒｏｌ ｐｌａｎｅ）とユーザプレーン（ｕｓｅｒ ｐｌａｎｅ）を提供する基地局２０（Ｂａｓｅ Ｓｔａｔｉｏｎ、ＢＳ）を含む。端末１０は、固定されるか移動性を有することができ、ＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、ＵＴ（Ｕｓｅｒ Ｔｅｒｍｉｎａｌ）、ＳＳ（Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）、ＭＴ（Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｌ）、無線機器（Ｗｉｒｅｌｅｓｓ Ｄｅｖｉｃｅ）など他の用語で呼ばれ得る。基地局２０は、端末１０と通信する固定された地点（ｆｉｘｅｄ ｓｔａｔｉｏｎ）を言い、ｅＮＢ（ｅｖｏｌｖｅｄ−ＮｏｄｅＢ）、ＢＴＳ（Ｂａｓｅ Ｔｒａｎｓｃｅｉｖｅｒ Ｓｙｓｔｅｍ）、アクセスポイント（Ａｃｃｅｓｓ Ｐｏｉｎｔ）など他の用語で呼ばれ得る。

[56] 基地局２０は、Ｓ１インターフェースを介して互いに連結されることができる。基地局２０は、Ｓ１インターフェースを介して、ＥＰＣ３０（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）、より詳細には、Ｓ１−ＭＭＥを介してＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）と、Ｓ１−Ｕを介してＳ−ＧＷ（Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）と連結される。

[57] ＥＰＣ３０は、ＭＭＥ、Ｓ−ＧＷ、及びＰ−ＧＷ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ−Ｇａｔｅｗａｙ）から構成される。ＭＭＥは、端末のアクセス情報や、端末の能力に関する情報を有しており、このような情報は、端末の移動性管理に主に使用される。Ｓ−ＧＷは、Ｅ−ＵＴＲＡＮを終端点として有するゲートウェイであり、Ｐ−ＧＷは、ＰＤＮ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ）を終端点として有するゲートウェイである。

[58] 端末ネットワークとの無線インターフェースプロトコル（Ｒａｄｉｏ Ｉｎｔｅｒｆａｃｅ Ｐｒｏｔｏｃｏｌ）の層は、通信システムで広く知られている開放型システム間相互接続（Ｏｐｅｎ Ｓｙｓｔｅｍ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ、ＯＳＩ）の基準モデルの下位３層に基づいて、Ｌ１（第１層）、Ｌ２（第２層）、Ｌ３（第３層）に区分されることができる。このうち、第１層に属する物理層は、物理チャネル（Ｐｈｙｓｉｃａｌ Ｃｈａｎｎｅｌ）を用いた情報伝送サービス（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｒａｎｓｆｅｒ Ｓｅｒｖｉｃｅ）を提供し、第３層に位置するＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）層は、端末とネットワークとの間に無線リソースを制御する役割をする。このために、ＲＲＣ層は端末と基地局間にＲＲＣメッセージを交換する。

[59] 図２は、本開示の一実施例に係る、ユーザ平面（ｕｓｅｒ ｐｌａｎｅ）に対する無線プロトコル構造（ｒａｄｉｏ ｐｒｏｔｏｃｏｌ ａｒｃｈｉｔｅｃｔｕｒｅ）を示す。図３は、本開示の一実施例に係る、制御平面（ｃｏｎｔｒｏｌ ｐｌａｎｅ）に対する無線プロトコル構造（ｒａｄｉｏ ｐｒｏｔｏｃｏｌ ａｒｃｈｉｔｅｃｔｕｒｅ）を示す。ユーザ平面は、ユーザデータ送信のためのプロトコルスタック（ｐｒｏｔｏｃｏｌ ｓｔａｃｋ）であり、制御平面は、制御信号送信のためのプロトコルスタックである。

[60] 図２及び図３を参照すると、物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ）は、物理チャネルを用いて上位層に情報伝送サービスを提供する。物理層は、上位層であるＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）層とは送信チャネル（ｔｒａｎｓｐｏｒｔ ｃｈａｎｎｅｌ）を介して連結されている。送信チャネルを介してＭＡＣ層と物理層との間にデータが移動する。送信チャネルは、無線インターフェースを介して、データがどのようにどんな特徴で送信されるかに応じて分類される。

[61] 互いに異なる物理層間、即ち、送信機と受信機の物理層間は物理チャネルを介してデータが移動する。前記物理チャネルは、ＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）方式で変調されることができ、時間と周波数を無線リソースとして活用する。

[62] ＭＡＣ層は、論理チャネル（ｌｏｇｉｃａｌ ｃｈａｎｎｅｌ）を介して上位層であるＲＬＣ（ｒａｄｉｏ ｌｉｎｋ ｃｏｎｔｒｏｌ）層にサービスを提供する。ＭＡＣ層は、複数の論理チャネルから複数の送信チャネルへのマッピング機能を提供する。また、ＭＡＣ層は、複数の論理チャネルから単数の送信チャネルへのマッピングによる論理チャネルの多重化機能を提供する。ＭＡＣ副層は、論理チャネル上のデータ伝送サービスを提供する。

[63] ＲＬＣ層は、ＲＬＣ ＳＤＵ(Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ)の連結（ｃｏｎｃａｔｅｎａｔｉｏｎ）、分割（ｓｅｇｍｅｎｔａｔｉｏｎ）、及び再結合（ｒｅａｓｓｅｍｂｌｙ）を行う。無線ベアラー（Ｒａｄｉｏ Ｂｅａｒｅｒ、ＲＢ）が要求する様々なＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を保証するために、ＲＬＣ層は、透明モード（Ｔｒａｎｓｐａｒｅｎｔ Ｍｏｄｅ、ＴＭ）、非確認モード（Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ、ＵＭ）、及び確認モード（Ａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ、ＡＭ）の三つの動作モードを提供する。ＡＭ ＲＬＣはＡＲＱ（ａｕｔｏｍａｔｉｃ ｒｅｐｅａｔ ｒｅｑｕｅｓｔ）を介してエラー訂正を提供する。

[64] ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）層は、コントロールプレーンでのみ定義される。ＲＲＣ層は、無線ベアラーの設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）、再設定（ｒｅ−ｃｏｎｆｉｇｕｒａｔｉｏｎ）、及び解除（ｒｅｌｅａｓｅ）に関して、論理チャネル、送信チャネル、及び物理チャネルの制御を担当する。ＲＢは、端末とネットワーク間のデータ伝達のために、第１層（ＰＨＹ層）及び第２層（ＭＡＣ層、ＲＬＣ層、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）層）によって提供される論理的経路を意味する。

[65] ユーザプレーンでのＰＤＣＰ層の機能は、ユーザデータの伝達、ヘッダ圧縮（ｈｅａｄｅｒ ｃｏｍｐｒｅｓｓｉｏｎ）、及び暗号化（ｃｉｐｈｅｒｉｎｇ）を含む。コントロールプレーンでのＰＤＣＰ層の機能は、コントロールプレーンデータの伝達及び暗号化／整合性保護（ｉｎｔｅｇｒｉｔｙ ｐｒｏｔｅｃｔｉｏｎ）を含む。

[66] ＲＢが設定されるというのは、特定のサービスを提供するために、無線プロトコル層及びチャネルの特性を規定し、各々の具体的なパラメータ及び動作方法を設定する過程を意味する。ＲＢは、再度ＳＲＢ（Ｓｉｇｎａｌｉｎｇ Ｒａｄｉｏ Ｂｅａｒｅｒ）とＤＲＢ（Ｄａｔａ Ｒａｄｉｏ Ｂｅａｒｅｒ）の二つに分けられる。ＳＲＢは、コントロールプレーンでＲＲＣメッセージを送信する通路として使用され、ＤＲＢは、ユーザプレーンでユーザデータを送信する通路として使用される。

[67] 端末のＲＲＣ層とＥ−ＵＴＲＡＮのＲＲＣ層との間にＲＲＣ接続（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ）が確立すると、端末はＲＲＣ＿ＣＯＮＮＥＤＴＥＤの状態にあることになり、そうでない場合、ＲＲＣ＿ＩＤＬＥの状態にあることになる。ＮＲの場合、ＲＲＣ＿ＩＮＡＣＴＩＶＥの状態がさらに定義され、ＲＲＣ＿ＩＮＡＣＴＩＶＥの状態の端末は、コアネットワークとの連結を維持する反面、基地局との連結を解除（ｒｅｌｅａｓｅ）することができる。

[68] ネットワークから端末へデータを送信するダウンリンク送信チャネルとしては、システム情報を送信するＢＣＨ（Ｂｒｏａｄｃａｓｔ Ｃｈａｎｎｅｌ）と、それ以外にユーザトラフィックや制御メッセージを送信するダウンリンクＳＣＨ（Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）とがある。ダウンリンクマルチキャストまたはブロードキャストサービスのトラフィックまたは制御メッセージの場合、ダウンリンクＳＣＨを介して送信されてもよく、または別途のダウンリンクＭＣＨ（Ｍｕｌｔｉｃａｓｔ Ｃｈａｎｎｅｌ）を介して送信されてもよい。一方、端末からネットワークへデータを送信するアップリンク送信チャネルとしては、初期の制御メッセージを送信するＲＡＣＨ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）と、それ以外にユーザトラフィックや制御メッセージを送信するアップリンクＳＣＨ（Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）とがある。

[69] 送信チャネルの上位にあり、送信チャネルにマッピングされる論理チャネル（Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ）としては、ＢＣＣＨ（Ｂｒｏａｄｃａｓｔ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＰＣＣＨ（Ｐａｇｉｎｇ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＣＣＣＨ（Ｃｏｍｍｏｎ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＭＣＣＨ（Ｍｕｌｔｉｃａｓｔ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、ＭＴＣＨ（Ｍｕｌｔｉｃａｓｔ Ｔｒａｆｆｉｃ Ｃｈａｎｎｅｌ）等がある。

[70] 物理チャネル（Ｐｈｙｓｉｃａｌ Ｃｈａｎｎｅｌ）は、時間領域で多数個のＯＦＤＭシンボルと周波数領域で多数個の副搬送波（Ｓｕｂ−ｃａｒｒｉｅｒ）から構成される。一つのサブフレーム（ｓｕｂ−ｆｒａｍｅ）は、時間領域で複数のＯＦＤＭシンボル（ｓｙｍｂｏｌ）から構成される。リソースブロックは、リソース割り当ての単位であって、複数のＯＦＤＭシンボルと複数の副搬送波（ｓｕｂ−ｃａｒｒｉｅｒ）から構成される。また、各サブフレームは、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）、即ち、Ｌ１／Ｌ２制御チャネルのために該当サブフレームの特定のＯＦＤＭシンボル（例えば、一番目のＯＦＤＭシンボル）の特定の副搬送波を用いることができる。ＴＴＩ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ Ｉｎｔｅｒｖａｌ）は、サブフレーム送信の単位時間である。

[71] 図４は、本開示の一実施例に係る、ＮＲシステムの構造を示す。

[72] 図４を参照すると、ＮＧ−ＲＡＮ(Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ−Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ)は、端末にユーザプレーン及びコントロールプレーンのプロトコル終端（ｔｅｒｍｉｎａｔｉｏｎ）を提供するｇＮＢ(ｎｅｘｔ ｇｅｎｅｒａｔｉｏｎ−Ｎｏｄｅ Ｂ)及び／またはｅＮＢを含むことができる。図４では、ｇＮＢのみを含む場合を例示する。ｇＮＢ及びｅＮＢは、相互間にＸｎインターフェースで連結されている。ｇＮＢ及びｅＮＢは、５世代コアネットワーク（５Ｇ Ｃｏｒｅ Ｎｅｔｗｏｒｋ：５ＧＣ）とＮＧインターフェースを介して連結されている。より具体的に、ＡＭＦ（ａｃｃｅｓｓ ａｎｄ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）とはＮＧ−Ｃインターフェースを介して連結され、ＵＰＦ（ｕｓｅｒ ｐｌａｎｅ ｆｕｎｃｔｉｏｎ）とはＮＧ−Ｕインターフェースを介して連結される。

[73] 図５は、本開示の一実施例に係る、ＮＧ−ＲＡＮと５ＧＣとの間の機能的分割を示す。

[74] 図５を参照すると、ｇＮＢは、インターセル間の無線リソース管理（Ｉｎｔｅｒ Ｃｅｌｌ ＲＲＭ）、無線ベアラー管理（ＲＢ ｃｏｎｔｒｏｌ）、連結移動性制御（Ｃｏｎｎｅｃｔｉｏｎ Ｍｏｂｉｌｉｔｙ Ｃｏｎｔｒｏｌ）、無線許可制御（Ｒａｄｉｏ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ）、測定設定及び提供（Ｍｅａｓｕｒｅｍｅｎｔ ｃｏｎｆｉｇｕｒａｔｉｏｎ ＆ Ｐｒｏｖｉｓｉｏｎ）、動的リソース割り当て（ｄｙｎａｍｉｃ ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ）等の機能を提供することができる。ＡＭＦは、ＮＡＳ(Ｎｏｎ Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ)セキュリティ、アイドル状態の移動性処理等の機能を提供することができる。ＵＰＦは、移動性アンカーリング（Ｍｏｂｉｌｉｔｙ Ａｎｃｈｏｒｉｎｇ）、ＰＤＵ(Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ)処理等の機能を提供することができる。ＳＭＦ（Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）は、端末ＩＰ(Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ)アドレスの割り当て、ＰＤＵセッション制御等の機能を提供することができる。

[75] 図６は、本開示の一実施例に係る、ＮＲの無線フレームの構造を示す。

[76] 図６を参照すると、ＮＲでアップリンク及びダウンリンクの送信のために無線フレームが使用できる。無線フレームは、１０ｍｓの長さを有し、２個の５ｍｓのハーフ−フレーム（Ｈａｌｆ−Ｆｒａｍｅ、ＨＦ）で定義され得る。ハーフ−フレームは、５個の１ｍｓのサブフレーム（Ｓｕｂｆｒａｍｅ、ＳＦ）を含むことができる。サブフレームは、一つ以上のスロットに分割されることができ、サブフレーム内のスロットの数は、副搬送波間隔（Ｓｕｂｃａｒｒｉｅｒ Ｓｐａｃｉｎｇ、ＳＣＳ）に応じて決定されることができる。各スロットは、ＣＰ（ｃｙｃｌｉｃ ｐｒｅｆｉｘ）に応じて、１２個または１４個のＯＦＤＭ（Ａ）シンボルを含むことができる。

[77] ノーマルＣＰ（ｎｏｒｍａｌ ＣＰ）が使用される場合、各スロットは１４個のシンボルを含むことができる。拡張ＣＰが使用される場合、各スロットは、１２個のシンボルを含むことができる。ここで、シンボルは、ＯＦＤＭシンボル（または、ＣＰ−ＯＦＤＭシンボル）、ＳＣ−ＦＤＭＡ(Ｓｉｎｇｌｅ Ｃａｒｒｉｅｒ−ＦＤＭＡ)シンボル（または、ＤＦＴ−ｓ−ＯＦＤＭ(Ｄｉｓｃｒｅｔｅ Ｆｏｕｒｉｅｒ Ｔｒａｎｓｆｏｒｍ−ｓｐｒｅａｄ−ＯＦＤＭ)シンボル）を含むことができる。

[78] 以下の表１は、ノーマルＣＰが使用される場合、ＳＣＳ設定（ｕ）に応じて、スロット別シンボルの数（Ｎ^ｓｌｏｔ _ｓｙｍｂ）、フレーム別スロットの数（Ｎ^{ｆｒａｍｅ，ｕ} _ｓｌｏｔ）と、サブフレーム別スロットの数（Ｎ^{ｓｕｂｆｒａｍｅ，ｕ} _ｓｌｏｔ）を例示する。

[79]

[80] 表２は、拡張ＣＰが使用される場合、ＳＣＳに応じて、スロット別シンボルの数、フレーム別スロットの数とサブフレーム別スロットの数を例示する。

[81]

[82] ＮＲシステムでは、一つの端末に併合される複数のセル間にＯＦＤＭ（Ａ）ヌメロロジー（ｎｕｍｅｒｏｌｏｇｙ）（例えば、ＳＣＳ、ＣＰ長さなど）が異なって設定できる。これによって、同じ数のシンボルで構成された時間リソース（例えば、サブフレーム、スロットまたはＴＴＩ）（便宜上、ＴＵ（Ｔｉｍｅ Ｕｎｉｔ）と通称）の（絶対時間）区間が併合されたセル間に異なって設定できる。

[83] ＮＲにおいて、多様な５Ｇサービスをサポートするための多数のヌメロロジー（ｎｕｍｅｒｏｌｏｇｙ）またはＳＣＳがサポートされることができる。例えば、ＳＣＳが１５ｋＨｚである場合、伝統的なセルラーバンドでの広い領域（ｗｉｄｅ ａｒｅａ）がサポートされることができ、ＳＣＳが３０ｋＨｚ／６０ｋＨｚである場合、密集した−都市（ｄｅｎｓｅ−ｕｒｂａｎ）、より低い遅延（ｌｏｗｅｒ ｌａｔｅｎｃｙ）、及びより広いキャリア帯域幅（ｗｉｄｅｒ ｃａｒｒｉｅｒ ｂａｎｄｗｉｄｔｈ）がサポートされることができる。ＳＣＳが６０ｋＨｚまたはそれより高い場合、位相雑音（ｐｈａｓｅ ｎｏｉｓｅ）を克服するために２４．２５ＧＨｚより大きい帯域幅がサポートされることができる。

[84] ＮＲ周波数バンド（ｆｒｅｑｕｅｎｃｙ ｂａｎｄ）は、二つのタイプの周波数範囲（ｆｒｅｑｕｅｎｃｙ ｒａｎｇｅ）に定義されることができる。前記二つのタイプの周波数範囲は、ＦＲ１及びＦＲ２である。周波数範囲の数値は、変更されることができ、例えば、前記二つのタイプの周波数範囲は、以下の表３の通りである。ＮＲシステムで使われる周波数範囲のうち、ＦＲ１は“ｓｕｂ ６ＧＨｚ ｒａｎｇｅ”を意味することができ、ＦＲ２は“ａｂｏｖｅ ６ＧＨｚ ｒａｎｇｅ”を意味することができ、ミリ波（ｍｉｌｌｉｍｅｔｅｒ ｗａｖｅ、ｍｍＷ）と呼ばれることができる。

[85]

[86] 前述したように、ＮＲシステムの周波数範囲の数値は、変更されることができる。例えば、ＦＲ１は、以下の表４のように４１０ＭＨｚ乃至７１２５ＭＨｚの帯域を含むことができる。即ち、ＦＲ１は、６ＧＨｚ（または、５８５０、５９００、５９２５ＭＨｚ等）以上の周波数帯域を含むことができる。例えば、ＦＲ１内で含まれる６ＧＨｚ（または、５８５０、５９００、５９２５ＭＨｚ等）以上の周波数帯域は、非免許帯域（ｕｎｌｉｃｅｎｓｅｄ ｂａｎｄ）を含むことができる。非免許帯域は、多様な用途で使われることができ、例えば、車両のための通信（例えば、自律走行）のために使われることができる。

[87]

[88] 図７は、本開示の一実施例に係る、ＮＲフレームのスロット構造を示す。

[89] 図７を参照すると、スロットは、時間領域で複数のシンボルを含む。例えば、ノーマルＣＰの場合、一つのスロットが１４個のシンボルを含むが、拡張ＣＰの場合、一つのスロットが１２個のシンボルを含むことができる。或いは、ノーマルＣＰの場合、一つのスロットが７個のシンボルを含むが、拡張ＣＰの場合、一つのスロットが６個のシンボルを含むことができる。

[90] 搬送波は、周波数領域で複数の副搬送波を含む。ＲＢ（Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ）は周波数領域で複数（例えば、１２）の連続した副搬送波で定義され得る。ＢＷＰ（Ｂａｎｄｗｉｄｔｈ Ｐａｒｔ）は、周波数領域で複数の連続した（Ｐ）ＲＢ((Ｐｈｙｓｉｃａｌ) Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ)で定義され得、一つのヌメロロジー（ｎｕｍｅｒｏｌｏｇｙ）（例えば、ＳＣＳ、ＣＰ長さなど）に対応し得る。搬送波は、最大Ｎ個（例えば、５個）のＢＷＰを含むことができる。データ通信は、活性化されたＢＷＰを介して行われることができる。各々の要素は、リソースグリッドでリソース要素（Ｒｅｓｏｕｒｃｅ Ｅｌｅｍｅｎｔ、ＲＥ）と称され得、一つの複素シンボルがマッピングできる。

[91] 以下、ＢＷＰ（Ｂａｎｄｗｉｄｔｈ Ｐａｒｔ）及びキャリアに対して説明する。

[92] ＢＷＰ（Ｂａｎｄｗｉｄｔｈ Ｐａｒｔ）は、与えられたヌメロロジーでＰＲＢ（ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）の連続的な集合である。ＰＲＢは、与えられたキャリア上で与えられたヌメロロジーに対するＣＲＢ（ｃｏｍｍｏｎ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）の連続的な部分集合から選択されることができる。

[93] ＢＡ（Ｂａｎｄｗｉｄｔｈ Ａｄａｐｔａｔｉｏｎ）を使用すると、端末の受信帯域幅及び送信帯域幅は、セルの帯域幅ほど大きい必要がないし、端末の受信帯域幅及び送信帯域幅は、調整されることができる。例えば、ネットワーク／基地局は、帯域幅調整を端末に知らせることができる。例えば、端末は、帯域幅調整のための情報／設定をネットワーク／基地局から受信することができる。この場合、端末は、前記受信された情報／設定に基づいて帯域幅調整を実行することができる。例えば、前記帯域幅調整は、帯域幅の縮小／拡大、帯域幅の位置変更または帯域幅のサブキャリアスペーシングの変更を含むことができる。

[94] 例えば、帯域幅は、パワーをセイブするために活動が少ない期間の間に縮小されることができる。例えば、帯域幅の位置は、周波数ドメインで移動できる。例えば、帯域幅の位置は、スケジューリング柔軟性（ｓｃｈｅｄｕｌｉｎｇ ｆｌｅｘｉｂｉｌｉｔｙ）を増加させるために周波数ドメインで移動できる。例えば、帯域幅のサブキャリアスペーシング（ｓｕｂｃａｒｒｉｅｒ ｓｐａｃｉｎｇ）は、変更されることができる。例えば、帯域幅のサブキャリアスペーシングは、異なるサービスを許容するために変更されることができる。セルの総セル帯域幅のサブセットは、ＢＷＰ（Ｂａｎｄｗｉｄｔｈ Ｐａｒｔ）と称することができる。ＢＡは、基地局／ネットワークが端末にＢＷＰを設定し、基地局／ネットワークが設定されたＢＷＰのうち現在活性状態であるＢＷＰを端末に知らせることによって実行されることができる。

[95] 例えば、ＢＷＰは、活性（ａｃｔｉｖｅ）ＢＷＰ、イニシャル（ｉｎｉｔｉａｌ）ＢＷＰ及び／またはデフォルト（ｄｅｆａｕｌｔ）ＢＷＰのうち少なくともいずれか一つである。例えば、端末は、ＰＣｅｌｌ（ｐｒｉｍａｒｙ ｃｅｌｌ）上の活性（ａｃｔｉｖｅ）ＤＬ ＢＷＰ以外のＤＬ ＢＷＰでダウンリンク無線リンク品質（ｄｏｗｎｌｉｎｋ ｒａｄｉｏ ｌｉｎｋ ｑｕａｌｉｔｙ）をモニタリングしない。例えば、端末は、活性ＤＬ ＢＷＰの外部でＰＤＣＣＨ、ＰＤＳＣＨまたはＣＳＩ−ＲＳ（ただし、ＲＲＭ除外）を受信しない。例えば、端末は、非活性ＤＬ ＢＷＰに対するＣＳＩ（Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ）報告をトリガしない。例えば、端末は、活性ＵＬ ＢＷＰ外部でＰＵＣＣＨまたはＰＵＳＣＨを送信しない。例えば、ダウンリンクの場合、イニシャルＢＷＰは、（ＰＢＣＨにより設定された）ＲＭＳＩ ＣＯＲＥＳＥＴに対する連続的なＲＢセットで与えられることができる。例えば、アップリンクの場合、イニシャルＢＷＰは、ランダムアクセス手順のためにＳＩＢにより与えられることができる。例えば、デフォルトＢＷＰは、上位階層により設定されることができる。例えば、デフォルトＢＷＰの初期値は、イニシャルＤＬ ＢＷＰである。エネルギーセイビングのために、端末が一定期間の間にＤＣＩを検出することができない場合、端末は、前記端末の活性ＢＷＰをデフォルトＢＷＰにスイッチングできる。

[96] 一方、ＢＷＰは、ＳＬに対して定義されることができる。同じＳＬ ＢＷＰは、送信及び受信に使われることができる。例えば、送信端末は、特定ＢＷＰ上でＳＬチャネルまたはＳＬ信号を送信することができ、受信端末は、前記特定ＢＷＰ上でＳＬチャネルまたはＳＬ信号を受信することができる。免許キャリア（ｌｉｃｅｎｓｅｄ ｃａｒｒｉｅｒ）で、ＳＬ ＢＷＰは、Ｕｕ ＢＷＰと別途に定義されることができ、ＳＬ ＢＷＰは、Ｕｕ ＢＷＰと別途の設定シグナリング（ｓｅｐａｒａｔｅ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｓｉｇｎａｌｌｉｎｇ）を有することができる。例えば、端末は、ＳＬ ＢＷＰのための設定を基地局／ネットワークから受信することができる。ＳＬ ＢＷＰは、キャリア内でｏｕｔ−ｏｆ−ｃｏｖｅｒａｇｅ ＮＲ Ｖ２Ｘ端末及びＲＲＣ＿ＩＤＬＥ端末に対して（あらかじめ）設定されることができる。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤモードの端末に対して、少なくとも一つのＳＬ ＢＷＰがキャリア内で活性化されることができる。

[97] 図８は、本開示の一実施例に係る、ＢＷＰの一例を示す。図８の実施例において、ＢＷＰは、３個と仮定する。

[98] 図８を参照すると、ＣＲＢ（ｃｏｍｍｏｎ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）は、キャリアバンドの一側端から他側端まで番号が付けられたキャリアリソースブロックである。そして、ＰＲＢは、各ＢＷＰ内で番号が付けられたリソースブロックである。ポイントＡは、リソースブロックグリッド（ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ ｇｒｉｄ）に対する共通参照ポイント（ｃｏｍｍｏｎ ｒｅｆｅｒｅｎｃｅ ｐｏｉｎｔ）を指示することができる。

[99] ＢＷＰは、ポイントＡ、ポイントＡからのオフセット（Ｎ^{ｓｔａｒｔ} _ＢＷＰ）及び帯域幅（Ｎ^ｓｉｚｅ _ＢＷＰ）により設定されることができる。例えば、ポイントＡは、全てのヌメロロジー（例えば、該当キャリアでネットワークによりサポートされる全てのヌメロロジー）のサブキャリア０が整列されるキャリアのＰＲＢの外部参照ポイントである。例えば、オフセットは、与えられたヌメロロジーで最も低いサブキャリアとポイントＡとの間のＰＲＢ間隔である。例えば、帯域幅は、与えられたヌメロロジーでＰＲＢの変調である。

[100] 以下、Ｖ２ＸまたはＳＬ通信に対して説明する。

[101] 図９は、本開示の一実施例に係る、ＳＬ通信のための無線プロトコル構造（ｒａｄｉｏ ｐｒｏｔｏｃｏｌ ａｒｃｈｉｔｅｃｔｕｒｅ）を示す。具体的に、図９の（ａ）は、ＬＴＥのユーザ平面プロトコルスタックを示し、図９の（ｂ）は、ＬＴＥの制御平面プロトコルスタックを示す。

[102] 図１０は、本開示の一実施例に係る、ＳＬ通信のための無線プロトコル構造（ｒａｄｉｏ ｐｒｏｔｏｃｏｌ ａｒｃｈｉｔｅｃｔｕｒｅ）を示す。具体的に、図１０の（ａ）は、ＮＲのユーザ平面プロトコルスタックを示し、図１０の（ｂ）は、ＮＲの制御平面プロトコルスタックを示す。

[103] 以下、サイドリンク同期信号（Ｓｉｄｅｌｉｎｋ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ、ＳＬＳＳ）及び同期化情報について説明する。

[104] ＳＬＳＳは、サイドリンク特定的なシーケンス（ｓｅｑｕｅｎｃｅ）であって、ＰＳＳＳ（Ｐｒｉｍａｒｙ Ｓｉｄｅｌｉｎｋ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ）とＳＳＳＳ（Ｓｅｃｏｎｄａｒｙ Ｓｉｄｅｌｉｎｋ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ）とを含むことができる。前記ＰＳＳＳは、Ｓ−ＰＳＳ（Ｓｉｄｅｌｉｎｋ Ｐｒｉｍａｒｙ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ）と称してもよく、前記ＳＳＳＳは、Ｓ−ＳＳＳ（Ｓｉｄｅｌｉｎｋ Ｓｅｃｏｎｄａｒｙ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ）と称してもよい。

[105] ＰＳＢＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｂｒｏａｄｃａｓｔ Ｃｈａｎｎｅｌ）は、サイドリンク信号の送受信前に端末が真っ先に知るべきである基本になる（システム）情報が送信される（放送）チャネルであり得る。例えば、基本になる情報は、ＳＬＳＳに関する情報、デュプレックスモード（Ｄｕｐｌｅｘ Ｍｏｄｅ、ＤＭ）、ＴＤＤ ＵＬ／ＤＬ(Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘ Ｕｐｌｉｎｋ/Ｄｏｗｎｌｉｎｋ)の構成、リソースプールに関する情報、ＳＬＳＳに関するアプリケーションの種類、サブフレームオフセット、放送情報などであり得る。

[106] Ｓ−ＰＳＳ、Ｓ−ＳＳＳ、及びＰＳＢＣＨは周期的送信をサポートするブロックフォーマット（例えば、サイドリンクＳＳ(Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ)／ＰＳＢＣＨブロック、以下Ｓ−ＳＳＢ）に含まれ得る。前記Ｓ−ＳＳＢ(Ｓｉｄｅｌｉｎｋ−Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ Ｂｌｏｃｋ)は、キャリア内のＰＳＣＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）／ＰＳＳＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）と同じヌメロロジー（即ち、ＳＣＳ及びＣＰ長さ）を有することができ、送信帯域幅は、（予め）設定されたＳＬ ＢＷＰ(Ｓｉｄｅｌｉｎｋ Ｂａｎｄｗｉｄｔｈ Ｐａｒｔ)内にあり得る。また、Ｓ−ＳＳＢの周波数位置は、（予め）設定されることができる。したがって、端末はキャリアでＳ−ＳＳＢを見つけるために周波数で仮設検出（ｈｙｐｏｔｈｅｓｉｓ ｄｅｔｅｃｔｉｏｎ）を行う必要がない。

[107] 各ＳＬＳＳは、物理層のサイドリンク同期化ＩＤ（ｉｄｅｎｔｉｔｙ）を有してもよく、その値は０から３３５のうち何れか一つであってもよい。前記値のうちいずれの値を使用するかに応じて、同期化ソースが識別されることもある。例えば、０、１６８、１６９はＧＮＳＳ（ｇｌｏｂａｌ ｎａｖｉｇａｔｉｏｎ ｓａｔｅｌｌｉｔｅ ｓｙｓｔｅｍｓ）を意味してもよく、１乃至１６７は基地局を意味してもよく、１７０乃至３３５はカバレッジの外部であることを意味してもよい。或いは、物理層のサイドリンク同期化ＩＤ（ｉｄｅｎｔｉｔｙ）の値のうち、０乃至１６７はネットワークによって使用される値であってもよく、１６８乃至３３５はネットワークのカバレッジの外部で使用される値であってもよい。

[108] 図１１は、本開示の一実施例に係る、Ｖ２ＸまたはＳＬ通信を実行する端末を示す。

[109] 図１１を参照すると、Ｖ２Ｘ／サイドリンク通信における端末という用語は、主にユーザの端末を意味することができる。しかしながら、基地局のようなネットワーク装備が端末間の通信方式に応じて信号を送受信する場合、基地局もまた一種の端末と見なされることもできる。

[110] 端末１は、一連のリソースの集合を意味するリソースプール（ｒｅｓｏｕｒｃｅ ｐｏｏｌ）内で特定のリソースに該当するリソース単位（ｒｅｓｏｕｒｃｅ ｕｎｉｔ）を選択し、該当リソース単位を使用してサイドリンク信号を送信するように動作することができる。受信端末である端末２は、端末１が信号を送信することができるリソースプールが設定され、該当リソースプール内で端末１の信号を検出することができる。

[111] ここで、端末１が基地局の連結範囲内にある場合、基地局がリソースプールを知らせることができる。これに対して、端末１が基地局の連結範囲外にある場合、他の端末がリソースプールを知らせるか、または事前に決められたリソースで決定されることもできる。

[112] 一般に、リソースプールは、複数のリソース単位で構成されることができ、各端末は一つまたは複数のリソース単位を選定し、自分のサイドリンク信号の送信に使用することができる。

[113] 図１２は、本開示の一実施例に係る、Ｖ２ＸまたはＳＬ通信のためのリソース単位を示す。

[114] 図１２を参照すると、リソースプールの全周波数リソースがＮ_Ｆ個に分割でき、リソースプールの全時間リソースがＮ_Ｔ個に分割できる。従って、計Ｎ_Ｆ＊Ｎ_Ｔ個のリソース単位がリソースプール内で定義され得る。図１２は、該当リソースプールがＮ_Ｔ個のサブフレームの周期に繰り返される場合の例を示す。

[115] 図１２に示すように、一つのリソース単位（例えば、Ｕｎｉｔ ＃０）は、周期的に繰り返して表され得る。或いは、時間または周波数次元でのダイバーシティ（ｄｉｖｅｒｓｉｔｙ）効果を得るために、一つの論理的なリソース単位がマッピングされる物理的リソース単位のインデックスが時間に応じて事前に決められたパターンに変化することもできる。このようなリソース単位の構造において、リソースプールとは、サイドリンク信号を送信しようとする端末が送信に使用することができるリソース単位の集合を意味することができる。

[116] リソースプールは、様々な種類に細分化できる。例えば、各リソースプールで送信されるサイドリンク信号のコンテンツ（ｃｏｎｔｅｎｔ）に応じて、リソースプールは下記のように区分できる。

[117] （１）スケジューリング割り当て（Ｓｃｈｅｄｕｌｉｎｇ Ａｓｓｉｇｎｍｅｎｔ、ＳＡ）は、送信端末がサイドリンクデータチャネルの送信として使用するリソースの位置、その他にデータチャネルの復調のために必要なＭＣＳ（Ｍｏｄｕｌａｔｉｏｎ ａｎｄ Ｃｏｄｉｎｇ Ｓｃｈｅｍｅ）またはＭＩＭＯ(Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ)送信方式、ＴＡ（Ｔｉｍｉｎｇ Ａｄｖａｎｃｅ）などの情報を含む信号であり得る。ＳＡは、同じリソース単位上でサイドリンクデータと共にマルチプレクシングされて送信されることも可能であり、この場合、ＳＡリソースプールとは、ＳＡがサイドリンクデータとマルチプレクシングされて送信されるリソースプールを意味することができる。ＳＡは、サイドリンク制御チャネル（ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）とも呼ばれ得る。

[118] （２）サイドリンクデータチャネル（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ、ＰＳＳＣＨ）は、送信端末がユーザデータを送信するのに使用するリソースプールであり得る。もし、同じリソース単位上でサイドリンクデータと共にＳＡがマルチプレクシングされて送信される場合、ＳＡ情報を除いた形態のサイドリンクデータチャネルのみがサイドリンクデータチャネルのためのリソースプールで送信されることができる。言い換えると、ＳＡリソースプール内の個別のリソース単位上でＳＡ情報を送信するのに使用されたＲＥｓ(Ｒｅｓｏｕｒｃｅ Ｅｌｅｍｅｎｔｓ)は、サイドリンクデータチャネルのリソースプールで依然としてサイドリンクデータを送信するために使用されることができる。

[119] （３）ディスカバリーチャネルは、送信端末が自分のＩＤなどの情報を送信するためのリソースプールであり得る。これを介して、送信端末は隣接端末が自分を見つけるようにすることができる。

[120] 以上で説明したサイドリンク信号のコンテンツが同一である場合にも、サイドリンク信号の送受信属性に応じて、異なるリソースプールを使用することができる。一例として、同じサイドリンクデータチャネルやディスカバリーメッセージであっても、サイドリンク信号の送信タイミング決定方式（例えば、同期基準信号の受信時点で送信されるか、それとも前記受信時点で一定のタイミングアドバンスを適用して送信されるか）、リソース割り当て方式（例えば、個別信号の送信リソースを基地局が個別送信端末に指定するか、それとも個別送信端末がリソースプール内で自体的に個別信号の送信リソースを選択するか）、信号フォーマット（例えば、各サイドリンク信号が一つのサブフレームで占めるシンボルの数、または一つのサイドリンク信号の送信に使用されるサブフレームの数）、基地局からの信号強度、サイドリンク端末の送信電力強度等に応じて、再度異なるリソースプールに区分されることもできる。

[121] 以下、サイドリンクにおけるリソース割り当て（ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ）について説明する。

[122] 図１３は、本開示の一実施例によって、端末がＴＭ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｍｏｄｅ）によってＶ２ＸまたはＳＬ通信を実行する手順を示す。具体的に、図１３の（ａ）は、送信モード１または送信モード３と関連した端末動作を示し、図１３の（ｂ）は、送信モード２または送信モード４と関連した端末動作を示す。

[123] 図１３の（ａ）を参照すると、送信モード１／３で、基地局は端末１にＰＤＣＣＨ（より具体的にＤＣＩ(Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ)）を介してリソーススケジューリングを行い、端末１は、該当リソーススケジューリングによって端末２とサイドリンク／Ｖ２Ｘ通信を行う。端末１は端末２にＰＳＣＣＨ（ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）を介してＳＣＩ（ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）を送信した後、前記ＳＣＩに基づくデータをＰＳＳＣＨ（ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）を介して送信することができる。ＬＴＥサイドリンクの場合、送信モード１は一般的なサイドリンク通信に適用されることができ、送信モード３はＶ２Ｘのサイドリンク通信に適用されることができる。

[124] 図１３の（ｂ）を参照すると、送信モード２／４で、端末は自分でリソースをスケジューリングすることができる。より具体的に、ＬＴＥサイドリンクの場合、送信モード２は、一般的なサイドリンク通信に適用され、端末が設定されたリソースプール内でリソースを自分で選択してサイドリンク動作を行うことができる。送信モード４は、Ｖ２Ｘのサイドリンク通信に適用され、端末がセンシング／ＳＡデコーディング過程などを経て、選択ウィンドウ内で自分でリソースを選択した後、Ｖ２Ｘのサイドリンク動作を行うことができる。端末１は端末２にＰＳＣＣＨを介してＳＣＩを送信した後、前記ＳＣＩに基づくデータをＰＳＳＣＨを介して送信することができる。以下、送信モードをモードと略称してもよい。

[125] ＮＲのサイドリンクの場合、少なくとも二つのサイドリンクのリソース割り当てモードが定義され得る。モード１の場合、基地局はサイドリンク送信のために端末により使用されるサイドリンクリソースをスケジューリングすることができる。モード２の場合、端末は基地局／ネットワークにより設定されたサイドリンクリソースまたは予め設定されたサイドリンクリソース内でサイドリンク送信リソースを決定することができる。前記設定されたサイドリンクリソースまたは予め設定されたサイドリンクリソースは、リソース／リソースプールであり得る。例えば、モード２の場合、端末は自律的に送信のためのサイドリンクリソースを選択することができる。例えば、モード２の場合、端末は他の端末に対するサイドリンクリソースの選択を助けることができる。例えば、モード２の場合、端末はサイドリンク送信のためのＮＲ ｃｏｎｆｉｇｕｒｅｄ ｇｒａｎｔの設定を受けることができる。例えば、モード２の場合、端末は他の端末のサイドリンク送信をスケジューリングすることができる。また、モード２は少なくともブラインド再送信のためのサイドリンクリソースの予約をサポートすることができる。

[126] センシング（ｓｅｎｓｉｎｇ）及びリソースの（再）選択に関する手続は、リソース割り当てモード２でサポートされることができる。前記センシング手続は、他の端末及び／またはサイドリンクの測定からＳＣＩをデコーディングすると定義され得る。前記センシング手続でＳＣＩをデコーディングすることは、少なくともＳＣＩを送信する端末により指示されるサイドリンクリソースに対する情報を提供することができる。該当ＳＣＩがデコーディングされる際、前記センシング手続はＳＬ ＤＭＲＳ(Ｄｅｍｏｄｕｌａｔｉｏｎ Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ)に基づくＬ１ ＳＬ ＲＳＲＰ(Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｐｏｗｅｒ)測定を使用することができる。前記リソースの（再）選択手続はサイドリンク送信のためのリソースを決定するために、前記センシング手続の結果を使用することができる。

[127] 図１４は、本開示の一実施例によって、端末が送信リソースを選択する方法を示す。

[128] 図１４を参照すると、端末はセンシングウィンドウ内でセンシングを介して他の端末が予約した送信リソースまたは他の端末が使用しているリソースを把握することができ、選択ウィンドウ内でこれを排除した後、残っているリソースのうち、干渉の少ないリソースからランダムにリソースを選択することができる。

[129] 例えば、端末は、センシングウィンドウ内で、予約されたリソースの周期に対する情報を含むＰＳＣＣＨをデコーディングし、前記ＰＳＣＣＨに基づいて周期的に決定されたリソースでＰＳＳＣＨ ＲＳＲＰを測定することができる。端末は、前記ＰＳＳＣＨ ＲＳＲＰ値が閾値を超えるリソースを選択ウィンドウ内から除外することができる。その後、端末は選択ウィンドウ内の残っているリソースのうちからサイドリンクリソースをランダムに選択することができる。

[130] 或いは、端末はセンシングウィンドウ内で周期的なリソースのＲＳＳＩ（Ｒｅｃｅｉｖｅｄ ｓｉｇｎａｌ ｓｔｒｅｎｇｔｈ ｉｎｄｉｃａｔｉｏｎ）を測定し、干渉の少ないリソース（例えば、下位２０％に該当するリソース）を決定することができる。また、端末は前記周期的なリソースのうち、選択ウィンドウに含まれているリソースのうちからサイドリンクリソースをランダムに選択することもできる。例えば、端末がＰＳＣＣＨのデコーディングを失敗した場合、端末は前記のような方法を使用することができる。

[131] 図１５は、本開示の一実施例に係る、三つのキャストタイプを示す。

[132] 具体的に、図１５の（ａ）は、ブロードキャスト（ｂｒｏａｄｃａｓｔ）タイプのＳＬ通信を示し、図１５の（ｂ）は、ユニキャスト（ｕｎｉｃａｓｔ）タイプのＳＬ通信を示し、図１５の（ｃ）は、グループキャスト（ｇｒｏｕｐｃａｓｔ）タイプのＳＬ通信を示す。ユニキャストタイプのＳＬ通信の場合、端末は、他の端末と一対一通信を実行することができる。グループキャストタイプのＳＬ通信の場合、端末は、自分が属するグループ内の一つ以上の端末とＳＬ通信を実行することができる。本開示の多様な実施例において、ＳＬグループキャスト通信は、ＳＬマルチキャスト（ｍｕｌｔｉｃａｓｔ）通信、ＳＬ一対多（ｏｎｅ−ｔｏ−ｍａｎｙ）通信などに代替されることができる。

[133] 以下、ＳＬでＨＡＲＱ（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）手順に対して説明する。

[134] ＳＬユニキャスト及びグループキャストの場合、物理階層でのＨＡＲＱフィードバック及びＨＡＲＱコンバイニング（ｃｏｍｂｉｎｉｎｇ）がサポートされることができる。例えば、受信端末がリソース割当モード１または２で動作する場合、受信端末は、ＰＳＳＣＨを送信端末から受信することができ、ＰＳＦＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｆｅｅｄｂａｃｋ Ｃｈａｎｎｅｌ）を介してＳＦＣＩ（Ｓｉｄｅｌｉｎｋ Ｆｅｅｄｂａｃｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）フォーマットを使用してＰＳＳＣＨに対するＨＡＲＱフィードバックを送信端末に送信できる。

[135] 例えば、ＳＬ ＨＡＲＱフィードバックは、ユニキャストに対してイネイブルされることができる。このとき、ｎｏｎ−ＣＢＧ（ｎｏｎ−Ｃｏｄｅ Ｂｌｏｃｋ Ｇｒｏｕｐ）動作で、受信端末が前記受信端末をターゲットとするＰＳＣＣＨをデコーディングし、及び前記ＰＳＣＣＨと関連した送信ブロックを成功的にデコーディングする場合、受信端末は、ＨＡＲＱ−ＡＣＫを生成することができる。そして、受信端末は、ＨＡＲＱ−ＡＣＫを送信端末に送信できる。それに対して、受信端末が前記受信端末をターゲットとするＰＳＣＣＨをデコーディングした以後、前記ＰＳＣＣＨと関連した送信ブロックを成功的にデコーディングできない場合、受信端末は、ＨＡＲＱ−ＮＡＣＫを生成することができる。そして、受信端末は、ＨＡＲＱ−ＮＡＣＫを送信端末に送信できる。

[136] 例えば、ＳＬ ＨＡＲＱフィードバックは、グループキャストに対してイネイブルされることができる。例えば、ｎｏｎ−ＣＢＧ動作で、二つのＨＡＲＱフィードバックオプションがグループキャストに対してサポートされることができる。

[137] （１）グループキャストオプション１:受信端末が前記受信端末をターゲットとするＰＳＣＣＨをデコーディングした以後、前記ＰＳＣＣＨと関連した送信ブロックのデコーディングに失敗する場合、受信端末は、ＨＡＲＱ−ＮＡＣＫをＰＳＦＣＨを介して送信端末に送信できる。それに対して、受信端末が前記受信端末をターゲットとするＰＳＣＣＨをデコーディングし、及び前記ＰＳＣＣＨと関連した送信ブロックを成功的にデコーディングする場合、受信端末は、ＨＡＲＱ−ＡＣＫを送信端末に送信しない。

[138] （２）グループキャストオプション２:受信端末が前記受信端末をターゲットとするＰＳＣＣＨをデコーディングした以後、前記ＰＳＣＣＨと関連した送信ブロックのデコーディングに失敗する場合、受信端末は、ＨＡＲＱ−ＮＡＣＫをＰＳＦＣＨを介して送信端末に送信できる。そして、受信端末が前記受信端末をターゲットとするＰＳＣＣＨをデコーディングし、及び前記ＰＳＣＣＨと関連した送信ブロックを成功的にデコーディングする場合、受信端末は、ＨＡＲＱ−ＡＣＫをＰＳＦＣＨを介して送信端末に送信できる。

[139] 一方、例えば、高い信頼度の要求事項を有するサービスまたは相対的に高い信頼度の要求事項を有するサービスと関連したＳＬ通信の場合、端末のＳＬ ＨＡＲＱフィードバック動作及び／またはメカニズムが有用である。例えば、高い信頼度の要求事項を有するサービスと関連したＳＬ通信の場合、前記サービスを受信した端末が前記サービスを送信した端末にＳＬ ＨＡＲＱフィードバックを送信する動作が前記高い信頼度の要求事項を満たすときに有用である。

[140] 以下、本開示の多様な実施例によって、端末がＳＬ ＨＡＲＱフィードバック送信と関連したリソースまたは送信電力を決定する方法及びこれをサポートする装置に対して説明する。本開示の多様な実施例において、ＳＬ通信は、Ｖ２Ｘ通信を含むことができる。

[141] 本開示の多様な実施例によって提案された少なくとも一つの提案方式は、ユニキャスト通信、グループキャスト通信及び／またはブロードキャスト通信のうち少なくともいずれか一つに、適用されることができる。

[142] 本開示の多様な実施例によって提案された少なくとも一つの提案方式は、ＰＣ５インターフェースまたはＳＬインターフェース（例えば、ＰＳＣＣＨ、ＰＳＳＣＨ、ＰＳＢＣＨ、ＰＳＳＳ／ＳＳＳＳ等）ベースのＳＬ通信またはＶ２Ｘ通信だけでなく、Ｕｕインターフェース（例えば、ＰＵＳＣＨ、ＰＤＳＣＨ、ＰＤＣＣＨ、ＰＵＣＣＨ等）ベースのＳＬ通信またはＶ２Ｘ通信にも、適用されることができる。

[143] 本開示の多様な実施例において、端末の受信動作は、ＳＬチャネル及び／またはＳＬ信号（例えば、ＰＳＣＣＨ、ＰＳＳＣＨ、ＰＳＦＣＨ、ＰＳＢＣＨ、ＰＳＳＳ／ＳＳＳＳ等）のデコーディング動作及び／または受信動作を含むことができる。端末の受信動作は、ＷＡＮ ＤＬチャネル及び／またはＷＡＮ ＤＬ信号（例えば、ＰＤＣＣＨ、ＰＤＳＣＨ、ＰＳＳ／ＳＳＳ等）のデコーディング動作及び／または受信動作を含むことができる。端末の受信動作は、センシング動作及び／またはＣＢＲ測定動作を含むことができる。本開示の多様な実施例において、端末のセンシング動作は、ＰＳＳＣＨ ＤＭ−ＲＳシーケンスベースのＰＳＳＣＨ−ＲＳＲＰ測定動作、端末が成功的にデコーディングしたＰＳＣＣＨによりスケジューリングされるＰＳＳＣＨ ＤＭ−ＲＳシーケンスベースのＰＳＳＣＨ−ＲＳＲＰ測定動作、Ｓ−ＲＳＳＩ（ｓｉｄｅｌｉｎｋ ＲＳＳＩ）測定動作、及び／またはＶ２Ｘリソースプール関連サブチャネルベースのＳ−ＲＳＳＩ測定動作を含むことができる。本開示の多様な実施例において、端末の送信動作は、ＳＬチャネル及び／またはＳＬ信号（例えば、ＰＳＣＣＨ、ＰＳＳＣＨ、ＰＳＦＣＨ、ＰＳＢＣＨ、ＰＳＳＳ／ＳＳＳＳ等）の送信動作を含むことができる。端末の送信動作は、ＷＡＮ ＵＬチャネル及び／またはＷＡＮ ＵＬ信号（例えば、ＰＵＳＣＨ、ＰＵＣＣＨ、ＳＲＳ等）の送信動作を含むことができる。本開示の多様な実施例において、同期信号は、ＳＬＳＳ及び／またはＰＳＢＣＨを含むことができる。

[144] 本開示の多様な実施例において、設定は、シグナリング、ネットワークからのシグナリング、ネットワークからの設定、及び／またはネットワークからあらかじめ設定を含むことができる。本開示の多様な実施例において、定義は、シグナリング、ネットワークからのシグナリング、ネットワークからの設定、及び／またはネットワークからあらかじめ設定を含むことができる。本開示の多様な実施例において、指定は、シグナリング、ネットワークからのシグナリング、ネットワークからの設定、及び／またはネットワークからあらかじめ設定を含むことができる。

[145] 本開示の多様な実施例において、ＰＰＰＰ（ＰｒｏＳｅ Ｐｅｒ Ｐａｃｋｅｔ Ｐｒｉｏｒｉｔｙ）はＰＰＰＲ（ＰｒｏＳｅ Ｐｅｒ Ｐａｃｋｅｔ Ｒｅｌｉａｂｉｌｉｔｙ）に代替されることができ、ＰＰＰＲはＰＰＰＰに代替されることができる。例えば、ＰＰＰＰ値が小さいほど高い優先順位を意味することができ、ＰＰＰＰ値が大きいほど低い優先順位を意味することができる。例えば、ＰＰＰＲ値が小さいほど高い信頼性を意味することができ、ＰＰＰＲ値が大きいほど低い信頼性を意味することができる。例えば、高い優先順位と関連したサービス、パケットまたはメッセージと関連したＰＰＰＰ値は、低い優先順位と関連したサービス、パケットまたはメッセージと関連したＰＰＰＰ値より小さい。例えば、高い信頼性と関連したサービス、パケットまたはメッセージと関連したＰＰＰＲ値は、低い信頼性と関連したサービス、パケットまたはメッセージと関連したＰＰＰＲ値より小さい。

[146] 本開示の多様な実施例において、セッション（ｓｅｓｓｉｏｎ）は、ユニキャストセッション（例えば、ＳＬのためのユニキャストセッション）、グループキャスト／マルチキャストセッション（例えば、ＳＬのためのグループキャスト／マルチキャストセッション）、及び／またはブロードキャストセッション（例えば、ＳＬのためのブロードキャストセッション）のうち少なくともいずれか一つを含むことができる。

[147] 本開示の多様な実施例において、キャリアは、ＢＷＰ及び／またはリソースプールのうち少なくともいずれか一つとして相互拡張解釈されることができる。例えば、キャリアは、ＢＷＰ及び／またはリソースプールのうち少なくともいずれか一つを含むことができる。例えば、キャリアは、一つ以上のＢＷＰを含むことができる。例えば、ＢＷＰは、一つ以上のリソースプールを含むことができる。

[148] 本開示の多様な実施例において、ＨＡＲＱフィードバックリソースは、ＨＡＲＱフィードバック送信リソース及び／またはＨＡＲＱフィードバック受信リソースを含むことができる。例えば、前記ＨＡＲＱフィードバック送信リソースは、ＨＡＲＱフィードバックの送信のためのリソース及び／またはＨＡＲＱフィードバックの送信と関連したリソースを含むことができる。例えば、前記ＨＡＲＱフィードバック受信リソースは、ＨＡＲＱフィードバックの受信のためのリソース及び／またはＨＡＲＱフィードバックの受信と関連したリソースを含むことができる。

[149] 本開示の多様な実施例において、ＰＳＳＣＨリソースは、ＰＳＳＣＨ送信リソース及び／またはＰＳＳＣＨ受信リソースを含むことができる。例えば、前記ＰＳＳＣＨ送信リソースは、ＰＳＳＣＨの送信のためのリソース及び／またはＰＳＳＣＨの送信と関連したリソースを含むことができる。例えば、前記ＰＳＳＣＨ受信リソースは、ＰＳＳＣＨの受信のためのリソース及び／またはＰＳＳＣＨの受信と関連したリソースを含むことができる。

[150] 本開示の多様な実施例において、ＰＳＣＣＨリソースは、ＰＳＣＣＨ送信リソース及び／またはＰＳＳＣＨ受信リソースを含むことができる。例えば、前記ＰＳＣＣＨ送信リソースは、ＰＳＣＣＨの送信のためのリソース及び／またはＰＳＣＣＨの送信と関連したリソースを含むことができる。例えば、前記ＰＳＣＣＨ受信リソースは、ＰＳＣＣＨの受信のためのリソース及び／またはＰＳＣＣＨの受信と関連したリソースを含むことができる。

[151] 本開示の多様な実施例において、前記リソースは、時間領域リソース（ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ）、周波数領域リソース（ｆｒｅｑｕｅｎｃｙ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ）、及び／またはコード領域リソース（ｃｏｄｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ）のうち少なくともいずれか一つを含むことができる。

[152] 例えば、リソース衝突が端末のＰＳＳＣＨ送信、ＰＳＣＣＨ送信及び／またはＨＡＲＱフィードバック送信のうち少なくともいずれか一つで発行する場合、端末のＳＬ ＨＡＲＱフィードバック手順及び／または動作は、正しく動作しにくい。例えば、リソース衝突が端末のＰＳＳＣＨ送信、ＰＳＣＣＨ送信及び／またはＨＡＲＱフィードバック送信のうち少なくともいずれか一つで発行する場合、端末の全般的なＳＬ ＨＡＲＱフィードバック手順及び／または動作は、正確に実行しにくい。

[153] 例えば、受信端末がＰＳＳＣＨを成功的に受信したが、リソース衝突によってＨＡＲＱフィードバック（例えば、ＨＡＲＱ ＡＣＫ）上にエラーが発生された場合、送信端末は、不必要に受信端末に前記ＰＳＳＣＨを再送信しなければならない。例えば、受信端末がＰＳＳＣＨの受信に失敗し、及びＨＡＲＱフィードバックがリソース衝突によって送信端末に伝達されることができない場合、ＳＬ通信関連信頼度または性能が低下されることができる。例えば、受信端末が送信端末から送信されたＰＳＣＣＨ及び／またはＰＳＳＣＨの受信に失敗し、かつＰＳＣＣＨ及び／またはＰＳＳＣＨに対応するＨＡＲＱ ＮＡＣＫがリソース衝突によって送信端末に正しく伝達されることができない場合、ＳＬ通信関連信頼度または性能が低下されることができる。したがって、ＨＡＲＱフィードバックリソースは、複数の端末間で衝突されないようにまたは衝突を最小化するように決定される必要がある。

[154] 図１６は、本開示の一実施例によって、端末がＨＡＲＱフィードバックを送受信する手順を示す。図１６の実施例は、本開示の多様な実施例と結合されることができる。

[155] 図１６を参照すると、ステップＳ１６１０において、送信端末は、ＰＳＣＣＨ及び／またはＰＳＳＣＨを受信端末に送信できる。例えば、送信端末は、ＰＳＣＣＨリソース及び／またはＰＳＳＣＨリソースを利用してＳＬ情報を受信端末に送信できる。例えば、前記ＳＬ情報は、ＳＬ制御情報、ＳＬデータ、ＳＬパケット、ＳＬ ＴＢ（Ｔｒａｎｓｐｏｒｔ Ｂｌｏｃｋ）、ＳＬメッセージ及び／またはＳＬサービスのうち少なくともいずれか一つを含むことができる。

[156] ステップＳ１６２０において、受信端末は、ＨＡＲＱフィードバックリソースを決定することができる。付加的に、例えば、送信端末は、ＨＡＲＱフィードバックリソースを決定することができる。

[157] 例えば、前記ＨＡＲＱフィードバックリソースは、前記ＰＳＳＣＨと連関関係またはリンケージを有するように設定されることができる。例えば、前記ＨＡＲＱフィードバックリソースは、時間領域リソース（ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ）、周波数領域リソース（ｆｒｅｑｕｅｎｃｙ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ）、及び／またはコード領域リソース（ｃｏｄｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ）のうち少なくともいずれか一つを含むことができる。例えば、前記ＨＡＲＱフィードバックリソースの位置は、連動されたＰＳＳＣＨリソースと連関関係またはリンケージを有するように設定されることができる。例えば、前記ＨＡＲＱフィードバックリソースの位置は、連動されたＰＳＳＣＨリソースの位置と事前に定義された関数に基づいて連関関係またはリンケージを有するように設定されることができる。例えば、前記ＨＡＲＱフィードバックリソースは、前記ＰＳＳＣＨと関連した時間領域に対する情報、前記ＰＳＳＣＨと関連した周波数領域に対する情報、及び／または前記ＰＳＳＣＨと関連したコード領域に対する情報のうち少なくともいずれか一つに基づいて決定されることができる。

[158] そして／または、例えば、前記ＨＡＲＱフィードバックリソースは、前記ＰＳＣＣＨと連関関係またはリンケージを有するように設定されることができる。例えば、前記ＨＡＲＱフィードバックリソースの位置は、連動されたＰＳＣＣＨリソースと連関関係またはリンケージを有するように設定されることができる。例えば、前記ＨＡＲＱフィードバックリソースの位置は、連動されたＰＳＣＣＨリソースの位置と事前に定義された関数に基づいて連関関係またはリンケージを有するように設定されることができる。例えば、前記ＨＡＲＱフィードバックリソースは、前記ＰＳＣＣＨと関連した時間領域に対する情報、前記ＰＳＣＣＨと関連した周波数領域に対する情報、及び／または前記ＰＳＣＣＨと関連したコード領域に対する情報のうち少なくともいずれか一つに基づいて決定されることができる。

[159] 例えば、前記ＨＡＲＱフィードバックリソースは、ＰＳＳＣＨ送信及び／またはＰＳＣＣＨ送信に使われる周波数リソースの部分集合（ｓｕｂｓｅｔ）形態で設定されることができる。例えば、前記ＨＡＲＱフィードバックリソースの周波数領域は、連動されたＰＳＳＣＨリソース及び／またはＰＳＣＣＨリソースの周波数領域の部分集合形態で設定されることができる。例えば、前記ＨＡＲＱフィードバックリソースの周波数領域は、ＰＳＳＣＨリソース及び／またはＰＳＣＣＨリソースの周波数領域に含まれることができる。

[160] 図１７は、本開示の一実施例に係るＨＡＲＱフィードバックリソースを示す。図１７の実施例は、本開示の多様な実施例と結合されることができる。

[161] 図１７を参照すると、送信端末は、４個のサブチャネルを介してＰＳＣＣＨ及び／またはＰＳＳＣＨを受信端末に送信できる。この場合、前記ＰＳＣＣＨ及び／またはＰＳＳＣＨと関連したＨＡＲＱフィードバックリソースの周波数領域は、送信端末がＰＳＣＣＨ及び／またはＰＳＳＣＨを送信するために使用する周波数リソースの部分集合である。

[162] 本開示の一実施例によると、ＨＡＲＱフィードバックリソースとＰＳＳＣＨリソースとの間の時間ギャップ（ｔｉｍｅ ｇａｐ）が設定されることができる。そして／または、例えば、ＨＡＲＱフィードバックリソースとＰＳＣＣＨリソースとの間の時間ギャップ（ｔｉｍｅ ｇａｐ）が設定されることができる。例えば、端末のデコーディング能力（ｄｅｃｏｄｉｎｇ ｃａｐａｂｉｌｉｔｙ）及び／または遅延要求事項（例えば、Ｖ２Ｘメッセージ及び／またはサービス関連遅延要求事項）などを考慮し、時間ギャップが受信端末のＰＳＳＣＨ及び／またはＰＳＣＣＨ受信時点と前記受信端末のＨＡＲＱフィードバック送信時点との間に設定されることができる。例えば、端末のデコーディング能力及び／または遅延要求事項などを考慮し、時間ギャップが送信端末のＨＡＲＱフィードバック受信時点と前記送信端末のＰＳＳＣＨ及び／またはＰＳＣＣＨ（再）送信時点との間に設定されることができる。

[163] 例えば、前記時間ギャップは、リソースプール内で共通的に設定されることができる。例えば、前記時間ギャップは、リソースプール内で異なる端末間に共通的に設定されることができる。例えば、前記時間ギャップは、前記送信端末及び前記受信端末に共通的に設定されることができる。したがって、端末は、ＨＡＲＱフィードバックリソースを簡単に決定できる。例えば、前記時間ギャップは、リソースプール特定的に設定されることができる。

[164] 例えば、前記時間ギャップは、リソースプール上に共存するサービスの遅延バジェット（ｌａｔｅｎｃｙ ｂｕｄｇｅｔ）のうち、最も小さい値より小さい及び／または同一に設定または指定されることができる。例えば、サービスＡ及びサービスＢがリソースプール上に共存し、かつサービスＡの遅延バジェットがサービスＢの遅延バジェットより小さい場合、前記時間ギャップは、前記サービスＡの遅延バジェットより小さいまたは同じ値に設定または指定されることができる。

[165] 例えば、リソースプール、サービスのタイプ、サービスの優先順位、キャストのタイプ、及び／またはサービスのＱｏＳ要求事項特定的に設定されたＴＢ（Ｔｒａｎｓｐｏｒｔ Ｂｌｏｃｋ）関連最大再送信回数がリソースプール上の（関連）サービスに対して遅延バジェット内で（全て）サポート／実行されることができるように、前記時間ギャップが指定されることができる。例えば、前記最大再送信回数は、初期送信を含む最大許容再送信回数である。

[166] 例えば、前記時間ギャップは、端末のデコーディング能力のうち、最も大きい値より大きい及び／または同一に設定または指定されることができる。ここで、例えば、前記デコーディング能力は、前記端末のＰＳＳＣＨ受信終了／終わり時点から前記端末のＰＳＦＣＨ送信開始時点まで必要な端末のプロセシング時間である。そして／または、例えば、前記デコーディング能力は、前記端末のＰＳＣＣＨ受信終了／終わり時点から前記端末のＰＳＦＣＨ送信開始時点まで必要な端末のプロセシング時間である。例えば、前記時間ギャップは、リソースプール内の端末のデコーディング能力の中で、最も大きい値より大きい及び／または同一に設定または指定されることができる。例えば、端末Ａ、端末Ｂ、及び端末Ｃがリソースプール内でＳＬ通信を実行し、かつ端末Ａのデコーディング能力が最もよくない場合、前記時間ギャップは、端末ＡのＰＳＳＣＨ及び／またはＰＳＣＣＨ受信終了／終わり時点から端末ＡのＰＳＦＣＨ送信開始時点まで要求されるプロセシング時間より大きいまたは同じ値に設定または指定されることができる。

[167] 例えば、前記時間ギャップは、サービスのタイプ、サービスの優先順位、ＳＬ通信のタイプ、サービスと関連したセッション、サービスと関連したＰＰＰＰ、サービスと関連したＰＰＰＲ、サービスと関連したターゲットＢＬＥＲ（Ｂｌｏｃｋ Ｅｒｒｏｒ Ｒａｔｅ）、サービスと関連したターゲットＳＩＮＲ（Ｓｉｇｎａｌ ｔｏ Ｉｎｔｅｒｆｅｒｅｎｃｅ ｐｌｕｓ Ｎｏｉｓｅ Ｒａｔｉｏ）、サービスと関連した遅延バジェット、及び／または端末能力別に異なるようにまたは独立的に設定されることができる。例えば、前記時間ギャップは、リソースプール内でサービスのタイプ、サービスの優先順位、ＳＬ通信のタイプ、サービスと関連したセッション、サービスと関連したＰＰＰＰ、サービスと関連したＰＰＰＲ、サービスと関連したターゲットＢＬＥＲ、サービスと関連したターゲットＳＩＮＲ、サービスと関連した遅延バジェット、及び／または端末能力別に異なるようにまたは独立的に設定されることができる。例えば、前記ＳＬ通信のタイプは、ユニキャスト、グループキャスト及び／またはブロードキャストのうち少なくともいずれか一つを含むことができる。

[168] 再び、図１６を参照すると、ステップＳ１６３０において、受信端末は、ＨＡＲＱフィードバックを送信端末に送信できる。例えば、受信端末は、前記ＰＳＣＣＨ及び／またはＰＳＳＣＨに対応するＨＡＲＱフィードバックを送信端末に送信できる。例えば、受信端末は、前記ＰＳＣＣＨリソース及び／またはＰＳＳＣＨリソースに基づいて決定されたＨＡＲＱフィードバックリソースを利用して前記ＨＡＲＱフィードバックを送信端末に送信できる。例えば、送信端末は、前記ＰＳＣＣＨリソース及び／またはＰＳＳＣＨリソースに基づいて決定されたＨＡＲＱフィードバックリソース上でＨＡＲＱフィードバックを受信端末から受信することができる。

[169] 例えば、受信端末がＰＳＣＣＨ及び／またはＰＳＳＣＨを成功的に受信した場合、前記ＨＡＲＱフィードバックは、ＨＡＲＱ ＡＣＫである。例えば、受信端末がＰＳＣＣＨ及び／またはＰＳＳＣＨを受信することに失敗した場合、前記ＨＡＲＱフィードバックは、ＨＡＲＱ ＮＡＣＫ及び／またはＤＴＸ（ｄｉｓｃｏｎｔｉｎｕｏｕｓ ｄｅｔｅｃｔｉｏｎ）のうち少なくともいずれか一つである。

[170] 本発明の一実施例によると、グループ内の複数の端末が互いにＳＬ通信を実行するグループキャストの場合、ＨＡＲＱフィードバックリソースは、二つの形態で具現されることができる。

[171] （１）オプションＡ：共通的なＨＡＲＱフィードバックリソースが受信端末間に設定されることができる。例えば、送信端末がＰＳＳＣＨ及び／またはＰＳＣＣＨを複数の受信端末に送信した場合、ＨＡＲＱフィードバックリソースは、前記ＰＳＳＣＨ及び／またはＰＳＣＣＨを受信した複数の受信端末に対して共通的に設定されることができる。

[172] （２）オプションＢ：互いに異なるまたは独立的なＨＡＲＱフィードバックリソースが受信端末間に設定されることができる。例えば、各々の受信端末別にまたは一つ以上の受信端末を含むサブグループ別に、互いに異なるまたは独立的なＨＡＲＱフィードバックリソースが設定されることができる。例えば、送信端末がＰＳＳＣＨ及び／またはＰＳＣＣＨを複数の受信端末に送信した場合、互いに異なるまたは独立的なＨＡＲＱフィードバックリソースが前記ＰＳＳＣＨ及び／またはＰＳＣＣＨを受信した複数の受信端末または複数のサブグループに対して各々設定されることができる。

[173] 例えば、オプションＡは、前記グループキャストオプション１に対してのみ限定的に適用されることができる。例えば、グループキャストオプション１で、複数の受信端末は、ＰＳＣＣＨ及び／またはＰＳＳＣＨの受信に失敗した場合にのみ、複数の受信端末に対して共通的に設定されたＨＡＲＱフィードバックリソースを利用してＨＡＲＱ ＮＡＣＫを送信端末に送信できる。例えば、前記ＨＡＲＱ ＮＡＣＫは、ＳＦＮ（Ｓｉｎｇｌｅ Ｆｒｅｑｕｅｎｃｙ Ｎｅｔｗｏｒｋ）形態で具現されることができる。この場合、送信端末は、複数の受信端末により送信されたＨＡＲＱ ＮＡＣＫを分離して受信することができない。したがって、送信端末は、どの受信端末がＨＡＲＱ ＮＡＣＫを送信したかを知ることができない。しかしながら、送信端末は、複数の受信端末のうち少なくとも一つの受信端末がＨＡＲＱ ＮＡＣＫを送信したことを知ることができ、送信端末は、ＰＳＣＣＨ及び／またはＰＳＳＣＨを複数の受信端末に再送信できる。

[174] 例えば、オプションＡの場合、ユニキャスト関連ＨＡＲＱフィードバックリソース構造が再利用されることができる。そして／または、例えば、オプションＡの場合、ＨＡＲＱフィードバックリソースと関連したオーバーヘッドが減少されることができる。それに対して、オプションＡの場合、送信端末がＤＴＸを判別／認知することができないという限界がある。例えば、送信端末がＰＳＳＣＨ及び／またはＰＳＣＣＨを受信端末に送信した場合、受信端末は、ＰＳＳＣＨをスケジューリングするＰＳＣＣＨの受信に失敗できる。この場合、オプションＡによると、前記受信端末は、ＨＡＲＱ ＮＡＣＫを送信端末に送信しない。したがって、送信端末は、前記受信端末がＰＳＳＣＨを成功的に受信したと誤認する問題が発生できる。

[175] 例えば、オプションＢの場合、複数の受信端末を含むグループ内で、互いに異なるまたは独立的なＨＡＲＱフィードバックリソースが受信端末別にまたはサブグループ別に割り当てられることができる。ここで、例えば、オプションＢによると、前記グループに含まれている受信端末の個数またはサブグループの個数が多くなるほど、より多い量のＨＡＲＱフィードバックリソースが要求されることができる。例えば、Ｎ個の受信端末を含むグループの場合、Ｎ−１個のＨＡＲＱフィードバックリソースが要求されることができる。例えば、オプションＢは、前記グループキャストオプション２に対してのみ限定的に適用されることができる。

[176] 図１８は、本開示の一実施例によって、グループキャストＳＬ通信で、端末がＨＡＲＱフィードバックを送受信する手順を示す。図１８の実施例は、本開示の多様な実施例と結合されることができる。

[177] 図１８の実施例において、Ｎ個の端末がグループ内に含まれると仮定する。例えば、前記グループは、グループキャストＳＬ通信と関連したグループである。例えば、図１８の実施例は、前記オプションＢに対して適用されることができる。例えば、図１８の実施例は、前記グループキャストオプション２に対して適用されることができる。

[178] 図１８を参照すると、ステップＳ１８１０において、送信端末は、ＰＳＣＣＨ及び／またはＰＳＳＣＨをグループ内の複数の受信端末に送信できる。例えば、送信端末は、ＰＳＣＣＨリソース及び／またはＰＳＳＣＨリソースを利用してＳＬ情報をグループ内の複数の受信端末に送信できる。例えば、前記ＳＬ情報は、ＳＬ制御情報、ＳＬデータ、ＳＬパケット、ＳＬ ＴＢ（Ｔｒａｎｓｐｏｒｔ Ｂｌｏｃｋ）、ＳＬメッセージ及び／またはＳＬサービスのうち少なくともいずれか一つを含むことができる。

[179] ステップＳ１８２０において、複数の受信端末は、ＨＡＲＱフィードバックリソースを決定することができる。付加的に、例えば、送信端末は、ＨＡＲＱフィードバックリソースを決定することができる。

[180] 例えば、前記グループが生成される場合、前記グループ内部で使われる識別子（以下、ＧＵＥ＿ＩＤ）が端末別に割り当てられることができる。例えば、前記グループが生成される場合、ＧＵＥ＿ＩＤがサブグループ別に割り当てられることができる。例えば、ＧＵＥ＿ＩＤは、特定端末が生成してグループ内の端末に伝達できる。例えば、前記特定端末は、ＧＯ（Ｇｒｏｕｐ Ｏｗｎｅｒ）端末である。例えば、ＧＵＥ＿ＩＤは、ネットワークまたは基地局から設定され、または事前に設定されることができる。例えば、ＧＵＥ＿ＩＤは、端末に対してあらかじめ定義されることができる。例えば、ＧＵＥ＿ＩＤは、前記グループ内の複数の端末に対して異なるように割り当てられることができる。例えば、ＧＵＥ＿ＩＤは、前記グループ内の複数のサブグループに対して異なるように割り当てられることができる。

[181] 例えば、複数の受信端末は、自分のＧＵＥ＿ＩＤに基づいてＨＡＲＱフィードバックリソースを各々決定することができる。例えば、受信端末１は、自分に割り当てられたＧＵＥ＿ＩＤを利用してＨＡＲＱフィードバックリソースを決定することができ、受信端末２は、自分に割り当てられたＧＵＥ＿ＩＤを利用してＨＡＲＱフィードバックリソースを決定することができ、受信端末Ｎ−１は、自分に割り当てられたＧＵＥ＿ＩＤを利用してＨＡＲＱフィードバックリソースを決定することができる。したがって、ＨＡＲＱフィードバックリソースは、グループ内の複数の受信端末に対して異なるように決定されることができる。

[182] 例えば、送信端末を除いた残りの端末（例えば、受信端末）は、複数のＨＡＲＱフィードバックリソース（例えば、Ｎ−１個のＨＡＲＱフィードバックリソース）をＧＵＥ＿ＩＤの昇順によって順次に使用することができる。例えば、送信端末を除いた残りの端末（例えば、受信端末）は、複数のＨＡＲＱフィードバックリソース（例えば、Ｎ−１個のＨＡＲＱフィードバックリソース）をＧＵＥ＿ＩＤの降順によって順次に使用することができる。例えば、送信端末を除いた残りの端末（例えば、受信端末）は、複数のＨＡＲＱフィードバックリソース（例えば、Ｎ−１個のＨＡＲＱフィードバックリソース）を事前に設定された関数／規則に基づいて導出されたＧＵＥ＿ＩＤの順序によって順次に使用することができる。例えば、前記複数のＨＡＲＱフィードバックリソースは、事前に設定されることができる。例えば、前記送信端末は、ＰＳＳＣＨ及び／またはＰＳＣＣＨを複数の受信端末に送信した端末である。

[183] 例えば、送信端末を除いた残りのサブグループは、複数のＨＡＲＱフィードバックリソースをＧＵＥ＿ＩＤの昇順によって順次に使用することができる。例えば、送信端末を除いた残りのサブグループは、複数のＨＡＲＱフィードバックリソースをＧＵＥ＿ＩＤの降順によって順次に使用することができる。例えば、送信端末を除いた残りのサブグループは、複数のＨＡＲＱフィードバックリソースを事前に設定された関数／規則に基づいて導出されたＧＵＥ＿ＩＤの順序によって順次に使用することができる。例えば、前記複数のＨＡＲＱフィードバックリソースは、事前に設定されることができる。例えば、前記送信端末は、ＰＳＳＣＨ及び／またはＰＳＣＣＨを複数の受信端末に送信した端末である。

[184] ステップＳ１８３０において、複数の受信端末は、ＨＡＲＱフィードバックを送信端末に各々送信できる。例えば、複数の受信端末は、前記ＰＳＣＣＨ及び／またはＰＳＳＣＨに対応するＨＡＲＱフィードバックを送信端末に各々送信できる。例えば、複数の受信端末は、前記ＰＳＣＣＨリソース及び／またはＰＳＳＣＨリソースに基づいて決定されたＨＡＲＱフィードバックリソースを利用して前記ＨＡＲＱフィードバックを送信端末に各々送信できる。

[185] 例えば、受信端末がＰＳＣＣＨ及び／またはＰＳＳＣＨを成功的に受信した場合、前記ＨＡＲＱフィードバックはＨＡＲＱ ＡＣＫである。例えば、受信端末がＰＳＣＣＨ及び／またはＰＳＳＣＨを受信することに失敗した場合、前記ＨＡＲＱフィードバックは、ＨＡＲＱ ＮＡＣＫ及び／またはＤＴＸ（ｄｉｓｃｏｎｔｉｎｕｏｕｓ ｄｅｔｅｃｔｉｏｎ）のうち少なくともいずれか一つである。

[186] 本開示の一実施例によると、ＨＡＲＱ ＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）を減少させるために、ＨＡＲＱフィードバックリソースがグループ内の端末間でまたはサブグループ間でＦＤＭされることができる。ここで、例えば、受信端末からＨＡＲＱフィードバックを受信する送信端末の観点で、帯域内の放射（ｉｎ−ｂａｎｄ ｅｍｉｓｓｉｏｎ）によるＮｅａｒ−Ｆａｒ問題を緩和させるために、ＨＡＲＱフィードバック送信と関連した電力制御が必要である。例えば、受信端末からＨＡＲＱフィードバックを受信するＰＳＳＣＨ及び／またはＰＳＣＣＨ送信端末の観点で、帯域内の放射（ｉｎ−ｂａｎｄ ｅｍｉｓｓｉｏｎ）によるＮｅａｒ−Ｆａｒ問題を緩和させるために、受信端末に対するＨＡＲＱフィードバック送信と関連した電力制御が必要である。

[187] 本開示の一実施例によると、端末は、ＳＬチャネル上の参照信号に基づいて導出／取得されたＳＬ経路損失値、ＳＬチャネル上の参照信号に基づいて導出／取得されたＳＬ ＲＳＲＰ値、ＳＬチャネル上の参照信号に基づいて導出／取得されたＳＬ ＲＳＲＱ値、開ループ電力制御パラメータ、及び／または閉ループ電力制御パラメータのうち少なくともいずれか一つに基づいてＨＡＲＱフィードバック送信電力を決定することができる。例えば、送信端末が参照信号をＳＬチャネルを介して受信端末に送信する場合、受信端末は、ＳＬチャネル上の参照信号に基づいて導出／取得されたＳＬ経路損失値、ＳＬチャネル上の参照信号に基づいて導出／取得されたＳＬ ＲＳＲＰ値、ＳＬチャネル上の参照信号に基づいて導出／取得されたＳＬ ＲＳＲＱ値、開ループ電力制御パラメータ、及び／または閉ループ電力制御パラメータのうち少なくともいずれか一つに基づいてＨＡＲＱフィードバック送信電力を決定することができる。

[188] 例えば、前記ＳＬチャネル上の参照信号は、事前に定義されることができる。例えば、前記ＳＬチャネル上の参照信号は、ＰＳＳＣＨ上で送信されるＤＭＲＳ（即ち、ＰＳＳＣＨ ＤＭＲＳ）またはＰＳＣＣＨ上で送信されるＤＭＲＳ（即ち、ＰＳＣＣＨ ＤＭＲＳ）である。例えば、前記ＳＬチャネル上の参照信号は、ＰＳＳＣＨ上で送信されるＣＳＩ−ＲＳである。例えば、前記ＳＬチャネル上の参照信号は、ＳＬチャネルの品質推定（例えば、ＣＱＩ、ＰＭＩ、ＲＩ）に使われる参照信号である。例えば、前記ＳＬチャネル上の参照信号は、ＳＬ経路損失値、ＳＬ ＲＳＲＰ値及び／またはＳＬ ＲＳＲＱ値のうち少なくともいずれか一つの測定に使われる参照信号である。

[189] 例えば、前記ＳＬ経路損失は、送信端末と受信端末との間のリンクに対する経路損失である。例えば、開ループ電力制御パラメータ及び／または閉ループ電力制御パラメータは、事前に設定されることができる。例えば、開ループ電力制御パラメータは、Ｐｏ及び／またはアルファ値を含むことができる。

[190] 例えば、Ｐｏは、パケット／メッセージ送信関連ターゲットエラー率（例えば、ＢＬＥＲ（Ｂｌｏｃｋ Ｅｒｒｏｒ Ｒａｔｅ）、ＦＥＲ（Ｆｒａｍｅ Ｅｒｒｏｒ Ｒａｔｅ））を平均的に満たすための電力制御パラメータである。そして／または、例えば、Ｐｏは、送信端末と受信端末との間の平均受信ＳＩＮＲと関連した電力制御パラメータである。例えば、Ｐｏは、端末、リソースプール、サービスのタイプ、サービスの優先順位、サービスと関連したＱｏＳ要求事項、ＳＬ送信に使われる（周波数）リソース大きさ、ＳＬ送信に使われるＭＣＳ値、リソースプール関連混雑レベル（例、ＣＢＲ）、及び／またはキャストのタイプに特定的な電力制御パラメータである。例えば、ＨＡＲＱフィードバック送信電力がＳＬ ＲＳＲＰ及び／またはＳＬ ＲＳＲＱ値／範囲に基づいて計算／導出される場合、（事前に設定された）ＳＬ ＲＳＲＰ及び／またはＳＬ ＲＳＲＱ値／範囲別に異なるＰｏ値／範囲がマッピング／設定されることができる。

[191] 例えば、ＨＡＲＱフィードバック送信電力がＳＬ経路損失に基づいて導出／計算される時、アルファ値は、（測定された）経路損失補償に適用される加重値である。そして／または、例えば、ＨＡＲＱフィードバック送信電力がＳＬ ＲＳＲＰ及び／またはＳＬ ＲＳＲＱ値／範囲に基づいて計算／導出される時、アルファ値は、（測定された）ＳＬ ＲＳＲＰ及び／またはＳＬ ＲＳＲＱ値／範囲に適用される加重値である。そして／または、例えば、ＨＡＲＱフィードバック送信電力がＳＬ ＲＳＲＰ及び／またはＳＬ ＲＳＲＱ値／範囲に基づいて計算／導出される時、アルファ値は、（測定された）ＳＬ ＲＳＲＰ及び／またはＳＬ ＲＳＲＱ値／範囲別にマッピング／設定されたＨＡＲＱフィードバック送信電力に適用される加重値である。ここで、例えば、アルファ値／範囲は、端末、リソースプール、サービスのタイプ、サービスの優先順位、サービスと関連したＱｏＳ要求事項、ＳＬ送信に使われる（周波数）リソース大きさ、ＳＬ送信に使われるＭＣＳ値、リソースプール関連混雑レベル（例、ＣＢＲ）、及び／またはキャストのタイプに特定的に設定されることができる。例えば、ＨＡＲＱフィードバック送信電力がＳＬ ＲＳＲＰ及び／またはＳＬ ＲＳＲＱ値／範囲に基づいて計算／導出される場合、（事前に設定された）ＳＬ ＲＳＲＰ及び／またはＳＬ ＲＳＲＱ値／範囲別に異なるアルファ値／範囲がマッピング／設定されることができる。

[192] 例えば、ＨＡＲＱフィードバック送信電力がＳＬ ＲＳＲＰ及び／またはＳＬ ＲＳＲＱ値／範囲に基づいて計算／導出される場合、（事前に設定された）ＳＬ ＲＳＲＰ及び／またはＳＬ ＲＳＲＱ値／範囲別に異なるオフセット値／範囲がマッピング／設定されることができる。ＳＬ ＲＳＲＰ及び／またはＳＬ ＲＳＲＱを測定した端末は、（事前に設定された正規化されたまたは名目的な）ＳＬ（ＨＡＲＱフィードバック）（最大）送信電力に前記ＳＬ ＲＳＲＰ値及び／またはＳＬ ＲＳＲＱ値と関連したオフセットを適用し、最終ＨＡＲＱフィードバック送信電力を決定することができる。ここで、例えば、オフセット値／範囲は、端末、リソースプール、サービスのタイプ、サービスの優先順位、サービスと関連したＱｏＳ要求事項、ＳＬ送信に使われる（周波数）リソース大きさ、ＳＬ送信に使われるＭＣＳ値、リソースプール関連混雑レベル（例、ＣＢＲ）、及び／またはキャストのタイプに特定的に設定されることができる。

[193] 例えば、ＳＬ ＲＳＲＰ及び／またはＳＬ ＲＳＲＱ値／範囲別に異なる（正規化されたまたは名目的な）（最大）ＨＡＲＱフィードバック送信電力値／範囲がマッピング／設定されることができる。例えば、（正規化されたまたは名目的な）（最大）ＨＡＲＱフィードバック送信電力値／範囲は、端末、リソースプール、サービスのタイプ、サービスの優先順位、サービスと関連したＱｏＳ要求事項、ＳＬ送信に使われる（周波数）リソース大きさ、ＳＬ送信に使われるＭＣＳ値、リソースプール関連混雑レベル（例、ＣＢＲ）、及び／またはキャストのタイプに特定的に設定されることができる。

[194] 例えば、前記参照信号及び／または前記参照信号を含むＳＬチャネルと関連した送信電力値は、事前に定義されたチャネルを介して端末にシグナリングされることができる。例えば、送信端末は、前記参照信号及び／または前記参照信号を含むＳＬチャネルと関連した送信電力値を事前に定義されたチャネルを介して受信端末に送信できる。例えば、前記事前に定義されたチャネルは、ＰＳＣＣＨである。例えば、前記受信端末は、前記参照信号に基づいてＳＬ経路損失、ＳＬ ＲＳＲＰ、及び／またはＳＬ ＲＳＲＱのうち少なくともいずれか一つを測定する端末である。

[195] 例えば、前記開ループ電力制御パラメータ（及び／またはＳＬ ＲＳＲＰ（及び／またはＳＬ ＲＳＲＱ）値／範囲別にマッピング／設定された（最大または最小）ＨＡＲＱフィードバック送信電力値）は、サービスのタイプ、サービスの優先順位、ＳＬ通信のタイプ（例えば、ユニキャスト、グループキャスト、ブロードキャスト）、（リソースプール関連）混雑レベル（例えば、ＣＢＲ（Ｃｈａｎｎｅｌ Ｂｕｓｙ Ｒａｔｉｏ））、サービスと関連したセッション、サービスと関連したＰＰＰＰ、サービスと関連したＰＰＰＲ、サービスと関連したターゲットＢＬＥＲ（Ｂｌｏｃｋ Ｅｒｒｏｒ Ｒａｔｅ）、サービスと関連したターゲットＳＩＮＲ（Ｓｉｇｎａｌ ｔｏ Ｉｎｔｅｒｆｅｒｅｎｃｅ ｐｌｕｓ Ｎｏｉｓｅ Ｒａｔｉｏ）、サービスと関連した（最小または最大）ターゲット通信距離、及び／またはサービスと関連した遅延バジェット別に異なるようにまたは独立的に設定されることができる。そして／または、例えば、閉ループ電力制御動作／パラメータは、サービスのタイプ、サービスの優先順位、ＳＬ通信のタイプ（例えば、ユニキャスト、グループキャスト、ブロードキャスト）、（リソースプール関連）混雑レベル（例えば、ＣＢＲ）、サービスと関連したセッション、サービスと関連したＰＰＰＰ、サービスと関連したＰＰＰＲ、サービスと関連したターゲットＢＬＥＲ（Ｂｌｏｃｋ Ｅｒｒｏｒ Ｒａｔｅ）、サービスと関連したターゲットＳＩＮＲ（Ｓｉｇｎａｌ ｔｏ Ｉｎｔｅｒｆｅｒｅｎｃｅ ｐｌｕｓ Ｎｏｉｓｅ Ｒａｔｉｏ）、サービスと関連した（最小または最大）ターゲット通信距離、及び／またはサービスと関連した遅延バジェット別に異なるようにまたは独立的に運営／設定されることができる。

[196] 例えば、ＨＡＲＱフィードバックと関連した開ループ電力制御パラメータは、ＰＳＳＣＨ及び／またはＰＳＣＣＨと関連した開ループ電力制御パラメータと異なるようにまたは独立的に設定されることができる。そして／または、例えば、ＨＡＲＱフィードバックと関連した閉ループ電力制御動作／パラメータは、ＰＳＳＣＨ及び／またはＰＳＣＣＨと関連した閉ループ電力制御動作／パラメータと異なるようにまたは独立的に運営／設定されることができる。

[197] 本開示の一実施例によると、ＨＡＲＱフィードバックを受信する送信端末から離れた距離差が事前に設定された閾値以内である受信端末に対してのみ、ＨＡＲＱフィードバックリソースのＦＤＭが許容または設定されることができる。そして／または、例えば、送信端末と受信端末との間のリンクに対するＳＬ経路損失差が事前に設定された閾値以内である受信端末に対してのみ、ＨＡＲＱフィードバックリソースのＦＤＭが許容または設定されることができる。そして／または、例えば、送信端末と受信端末との間のリンクに対するＳＬ ＲＳＲＰ差が事前に設定された閾値以内である受信端末に対してのみ、ＨＡＲＱフィードバックリソースのＦＤＭが許容または設定されることができる。そして／または、例えば、送信端末と受信端末との間のリンクに対するＳＬ ＲＳＲＱ差が事前に設定された閾値以内である受信端末に対してのみ、ＨＡＲＱフィードバックリソースのＦＤＭが許容または設定されることができる。

[198] 例えば、複数の受信端末と送信端末との間の距離差が事前に設定された閾値以内である場合、前記複数の受信端末は、ＨＡＲＱフィードバックを周波数軸上のＦＤＭされたリソースを介して送信できる。そして／または、例えば、複数の受信端末と送信端末との間の経路損失差が事前に設定された閾値以内である場合、前記複数の受信端末は、ＨＡＲＱフィードバックを周波数軸上のＦＤＭされたリソースを介して送信できる。そして／または、例えば、複数の受信端末と送信端末との間の（測定された）ＲＳＲＰ値差が事前に設定された閾値以内である場合、前記複数の受信端末は、ＨＡＲＱフィードバックを周波数軸上のＦＤＭされたリソースを介して送信できる。そして／または、例えば、複数の受信端末と送信端末との間の（測定された）ＲＳＲＱ値差が事前に設定された閾値以内である場合、前記複数の受信端末は、ＨＡＲＱフィードバックを周波数軸上のＦＤＭされたリソースを介して送信できる。

[199] 例えば、グループ内の端末またはサブグループ間で、ＨＡＲＱフィードバックリソースがＦＤＭされることは好ましくない。例えば、ＨＡＲＱフィードバック送信関連電力制御が適用されない場合、グループ内の異なる端末または異なるサブグループ間で、ＨＡＲＱフィードバックリソースがＦＤＭされることは好ましくない。例えば、グループ内の異なる端末または異なるサブグループ間のＨＡＲＱフィードバック受信電力差が事前に設定された閾値より大きい場合、グループ内の異なる端末または異なるサブグループ間で、ＨＡＲＱフィードバックリソースがＦＤＭされることは好ましくない。例えば、グループ内の異なる端末または異なるサブグループ間のＳＬ経路損失差が事前に設定された閾値より大きい場合、グループ内の異なる端末または異なるサブグループ間で、ＨＡＲＱフィードバックリソースがＦＤＭされることは好ましくない。例えば、グループ内の異なる端末または異なるサブグループ間のＳＬ ＲＳＲＰ差が事前に設定された閾値より大きい場合、グループ内の異なる端末または異なるサブグループ間で、ＨＡＲＱフィードバックリソースがＦＤＭされることは好ましくない。例えば、グループ内の異なる端末または異なるサブグループ間のＳＬ ＲＳＲＱ差が事前に設定された閾値より大きい場合、グループ内の異なる端末または異なるサブグループ間で、ＨＡＲＱフィードバックリソースがＦＤＭされることは好ましくない。

[200] 例えば、前述した例示のように、ＨＡＲＱフィードバックリソースがＦＤＭされることが好ましくない場合、ＨＡＲＱフィードバックリソースは、ＧＵＥ＿ＩＤ、受信端末関連識別子、ＳＬ ＨＡＲＱプロセスＩＤ、及び／または送信端末関連識別子のうち少なくともいずれか一つに基づいて疑似ランダム（ｐｓｅｕｄｏ ｒａｎｄｏｍ）にＴＤＭされることができる。例えば、ＨＡＲＱフィードバックリソースは、ＧＵＥ＿ＩＤ、受信端末関連識別子、ＳＬ ＨＡＲＱプロセスＩＤ、及び／または送信端末関連識別子のうち少なくともいずれか一つに基づいて疑似ランダム（ｐｓｅｕｄｏ ｒａｎｄｏｍ）に決定されることができる。例えば、ＨＡＲＱフィードバックリソースは、ＧＵＥ＿ＩＤ、受信端末関連識別子、ＳＬ ＨＡＲＱプロセスＩＤ、及び／または送信端末関連識別子のうち少なくともいずれか一つを入力パラメータとして有する関数によりＴＤＭされ、または決定されることができる。例えば、前記ＨＡＲＱフィードバックリソースは、グループ内の複数の端末の各々に対するＨＡＲＱフィードバックリソースである。例えば、ＨＡＲＱフィードバックリソースは、グループ内のサブグループの各々に対するＨＡＲＱフィードバックリソースである。例えば、受信端末関連識別子は、目的地（ｄｅｓｔｉｎａｔｉｏｎ）ＩＤである。例えば、送信端末関連識別子は、ソース（ｓｏｕｒｃｅ）ＩＤである。例えば、前記関数は、事前に定義されることができる。

[201] 図１９は、本開示の一実施例によって、端末がＨＡＲＱフィードバックを送受信する手順を示す。図１９の実施例は、本開示の多様な実施例と結合されることができる。

[202] 図１９を参照すると、ステップＳ１９１０において、送信端末は、ＰＳＣＣＨ及び／またはＰＳＳＣＨを受信端末に送信できる。例えば、送信端末は、ＰＳＣＣＨリソース及び／またはＰＳＳＣＨリソースを利用してＳＬ情報を受信端末に送信できる。例えば、前記ＳＬ情報は、ＳＬ制御情報、ＳＬデータ、ＳＬパケット、ＳＬ ＴＢ（Ｔｒａｎｓｐｏｒｔ Ｂｌｏｃｋ）、ＳＬメッセージ及び／またはＳＬサービスのうち少なくともいずれか一つを含むことができる。

[203] ステップＳ１９２０において、受信端末は、ＨＡＲＱフィードバックリソースを決定することができる。付加的に、例えば、送信端末は、ＨＡＲＱフィードバックリソースを決定することができる。例えば、前記受信端末は、グループ内でグループキャスト通信を実行する複数の端末のうちいずれか一つの端末である。

[204] 例えば、前記ＨＡＲＱフィードバックリソースは、前記ＰＳＣＣＨリソース、前記ＰＳＳＣＨリソース、及び／またはＧＵＥ＿ＩＤのうち少なくともいずれか一つに基づいて決定されることができる。例えば、グループ内の複数の受信端末が、異なるＰＳＦＣＨリソースを利用してＨＡＲＱ ＡＣＫまたはＨＡＲＱ ＮＡＣＫを送信端末にフィードバックする場合、前記グループ内の複数の受信端末は、ＧＵＥ＿ＩＤを利用してＨＡＲＱフィードバックリソースを決定することができる。例えば、前記リソースは、時間領域リソース（ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ）、周波数領域リソース（ｆｒｅｑｕｅｎｃｙ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ）、及び／またはコード領域リソース（ｃｏｄｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ）のうち少なくともいずれか一つを含むことができる。例えば、前記ＧＵＥ＿ＩＤは、前記グループ内で端末を識別するための情報である。

[205] ステップＳ１９３０において、受信端末は、ＨＡＲＱフィードバックを送信端末に送信できる。例えば、受信端末は、前記ＰＳＣＣＨ及び／またはＰＳＳＣＨに対応するＨＡＲＱフィードバックを送信端末に送信できる。例えば、受信端末は、前記ＰＳＣＣＨリソース、前記ＰＳＳＣＨリソース、及び／またはＧＵＥ＿ＩＤのうち少なくともいずれか一つに基づいて決定されたＨＡＲＱフィードバックリソースを利用して前記ＨＡＲＱフィードバックを送信端末に送信できる。

[206] 例えば、受信端末がＰＳＣＣＨ及び／またはＰＳＳＣＨを成功的に受信した場合、前記ＨＡＲＱフィードバックはＨＡＲＱ ＡＣＫである。例えば、受信端末がＰＳＣＣＨ及び／またはＰＳＳＣＨを受信することに失敗した場合、前記ＨＡＲＱフィードバックは、ＨＡＲＱ ＮＡＣＫ及び／またはＤＴＸ（ｄｉｓｃｏｎｔｉｎｕｏｕｓ ｄｅｔｅｃｔｉｏｎ）のうち少なくともいずれか一つである。

[207] 本開示の多様な実施例によると、送信端末がＰＳＳＣＨ及び／またはＰＳＣＣＨ送信リソースをセンシング動作を介して選択する場合、ＨＡＲＱフィードバック送信関連リソースが衝突する問題が発生しない。例えば、複数の送信端末が互いに異なるＰＳＳＣＨ及び／またはＰＳＣＣＨ送信リソースをセンシング動作を介して選択する場合、ＨＡＲＱフィードバックリソースは、ＰＳＳＣＨリソース及び／またはＰＳＣＣＨリソースに基づいて決定されることができる。したがって、センシング動作に基づいて互いに異なるＰＳＳＣＨ及び／またはＰＳＣＣＨ送信リソースを選択した端末間で、ＨＡＲＱフィードバックリソースの衝突は、自動的に回避されることができる。

[208] 本開示の多様な実施例によると、送信端末がグループ内の複数の受信端末に同じＰＳＳＣＨ及び／またはＰＳＣＣＨを送信する場合、複数の受信端末は、互いに異なるＧＵＥ＿ＩＤを利用してＨＡＲＱフィードバックリソースを決定することができる。したがって、グループ内の複数の受信端末が同じＰＳＳＣＨ及び／またはＰＳＣＣＨを受信したにもかかわらず、ＨＡＲＱフィードバックリソースが衝突することを防止することができる。

[209] 図２０は、本開示の一実施例によって、端末がＨＡＲＱフィードバックを送受信する手順を示す。図２０の実施例は、本開示の多様な実施例と結合されることができる。

[210] 例えば、グループ内の複数の端末にグループ内部で端末を識別するためのＩＤが割当／指定されることができる。例えば、前記ＩＤは、内部（ｉｎｎｅｒ）ＩＤと称することができる。例えば、前記内部ＩＤは、ＧＵＥ＿ＩＤのような用途またはパラメータである。例えば、特定グループキャストトラフィックに対して、応用階層（ａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ）は、Ｖ２Ｘ階層に端末の内部ＩＤに対する情報及びグループ内の端末の数に対する情報を伝達することができる。例えば、前記端末は、前記特定グループキャストトラフィックを送信する端末である。例えば、特定グループキャストトラフィックに対して、応用階層は、Ｖ２Ｘ階層にグループ内の他の端末の内部ＩＤに対する情報を伝達しない。例えば、グループキャストトラフィックは、グループキャストサービス、グループキャストデータ、グループキャストパケット、及び／またはグループキャストメッセージのうち少なくともいずれか一つを含むことができる。

[211] 例えば、図２０の実施例において、送信端末がグループキャストと関連した第１のトラフィックをグループ内の複数の受信端末に送信しようとする場合、前記送信端末の応用階層は、前記送信端末の内部ＩＤに対する情報（例えば、ＩＤ＝２）及びグループ内の端末の数に対する情報（例えば、５個）を前記送信端末のＶ２Ｘ階層に伝達できる。例えば、受信端末１の応用階層は、前記受信端末１の内部ＩＤに対する情報（例えば、ＩＤ＝０）及びグループ内の端末の数に対する情報（例えば、５個）を前記受信端末１のＶ２Ｘ階層に伝達できる。例えば、受信端末２の応用階層は、前記受信端末２の内部ＩＤに対する情報（例えば、ＩＤ＝１）及びグループ内の端末の数に対する情報（例えば、５個）を前記受信端末２のＶ２Ｘ階層に伝達できる。例えば、受信端末３の応用階層は、前記受信端末３の内部ＩＤに対する情報（例えば、ＩＤ＝３）及びグループ内の端末の数に対する情報（例えば、５個）を前記受信端末３のＶ２Ｘ階層に伝達できる。例えば、受信端末４の応用階層は、前記受信端末４の内部ＩＤに対する情報（例えば、ＩＤ＝４）及びグループ内の端末の数に対する情報（例えば、５個）を前記受信端末４のＶ２Ｘ階層に伝達できる。

[212] そして、例えば、端末のＶ２Ｘ階層は、前記端末のＡＳ階層に前記端末の内部ＩＤに対する情報及びグループ内の端末の数に対する情報を伝達することができる。また、例えば、端末のＶ２Ｘ階層は、前記端末のＡＳ階層にＬ２ ＩＤ（例えば、ソースＬ２ ＩＤ、目的地Ｌ２ ＩＤ）及び／またはＱｏＳ情報などを共に伝達できる。

[213] 図２０を参照すると、ステップＳ２０１０において、送信端末は、特定グループキャストトラフィックを複数の受信端末に送信できる。例えば、前記特定グループキャストトラフィックは、ＰＳＳＣＨ及び／またはＰＳＣＣＨを介して送信されることができる。

[214] ステップＳ２０２０において、複数の受信端末は、ＨＡＲＱフィードバックリソースを決定することができる。例えば、複数の受信端末（例えば、複数の受信端末のＡＳ階層）は、事前に定義された規則によって自分の内部ＩＤに対する情報及びグループ内の端末の数に対する情報に基づいて、特定グループキャストトラフィックに対するＨＡＲＱフィードバックリソースを決定することができる。

[215] 例えば、送信端末は、（自分が受信すべき）ＨＡＲＱフィードバックリソースを決定することができる。例えば、送信端末は、自分の内部ＩＤに対する情報及びグループ内の端末の数に対する情報に基づいて、特定グループキャストトラフィックと関連した前記複数の受信端末のＨＡＲＱフィードバックリソースを導出または決定することができる。

[216] 例えば、応用階層が端末の内部ＩＤに対する情報及びグループ内の端末の数に対する情報を端末のＶ２Ｘ階層に提供する場合、前記端末は、前記グループキャストオプション１または前記グループキャストオプション２のうちいずれか一つを前記特定グループキャストトラフィックに対する（選択可能な）ＨＡＲＱフィードバックオプションに決定または見なすことができる。例えば、前記端末のＶ２Ｘ階層は、前記グループキャストオプション１または前記グループキャストオプション２のうちいずれか一つを前記特定グループキャストトラフィックに対する（選択可能な）ＨＡＲＱフィードバックオプションに決定または見なすことができる。付加的に、例えば、事前に設定された条件が満たすかどうかによって、端末は、前記グループキャストオプション１または前記グループキャストオプション２のうちいずれか一つを前記特定グループキャストトラフィックに対するＨＡＲＱフィードバックオプションに最終的に決定または見なすことができる。例えば、グループキャストに参加する複数の端末のための各々のＨＡＲＱフィードバックリソースがリソースプールで全てサポートされる場合、端末は、前記グループキャストオプション２を前記特定グループキャストトラフィックに対するＨＡＲＱフィードバックオプションに最終的に決定または見なすことができる。例えば、グループキャストに参加する複数の端末のための各々のＨＡＲＱフィードバックリソースがリソースプールで全てサポートされない場合、端末は、前記グループキャストオプション１を前記特定グループキャストトラフィックに対するＨＡＲＱフィードバックオプションに最終的に決定または見なすことができる。例えば、前記決定は、端末のＡＳ階層で実行されることができる。

[217] 例えば、応用階層がグループ内の端末の数に対する情報を端末のＶ２Ｘ階層に提供しない場合、前記端末は、前記グループキャストオプション１を前記特定グループキャストトラフィックに対するＨＡＲＱフィードバックオプションに決定または見なすことができる。例えば、応用階層が端末の内部ＩＤに対する情報及び／またはグループ内の端末の数に対する情報を端末のＶ２Ｘ階層に提供しない場合、前記端末は、前記グループキャストオプション１を前記特定グループキャストトラフィックに対するＨＡＲＱフィードバックオプションに決定または見なすことができる。例えば、前記端末のＶ２Ｘ階層は、前記グループキャストオプション１を前記特定グループキャストトラフィックに対するＨＡＲＱフィードバックオプションに決定または見なすことができる。

[218] 例えば、応用階層及び／またはＶ２Ｘ階層が端末の内部ＩＤに対する情報及びグループ内の端末の数に対する情報を端末のＡＳ階層に提供する場合、前記端末は、前記グループキャストオプション１または前記グループキャストオプション２のうちいずれか一つを前記特定グループキャストトラフィックに対する（選択可能な）ＨＡＲＱフィードバックオプションに決定または見なすことができる。例えば、前記端末のＡＳ階層は、前記グループキャストオプション１または前記グループキャストオプション２のうちいずれか一つを前記特定グループキャストトラフィックに対する（選択可能な）ＨＡＲＱフィードバックオプションに決定または見なすことができる。付加的に、例えば、事前に設定された条件が満たすかどうかによって、端末は、前記グループキャストオプション１または前記グループキャストオプション２のうちいずれか一つを前記特定グループキャストトラフィックに対するＨＡＲＱフィードバックオプションに最終的に決定または見なすことができる。例えば、グループキャストに参加する複数の端末のための各々のＨＡＲＱフィードバックリソースがリソースプールで全てサポートされる場合、端末は、前記グループキャストオプション２を前記特定グループキャストトラフィックに対するＨＡＲＱフィードバックオプションに最終的に決定または見なすことができる。例えば、グループキャストに参加する複数の端末のための各々のＨＡＲＱフィードバックリソースがリソースプールで全てサポートされない場合、端末は、前記グループキャストオプション１を前記特定グループキャストトラフィックに対するＨＡＲＱフィードバックオプションに最終的に決定または見なすことができる。例えば、前記決定は、端末のＡＳ階層で実行されることができる。

[219] 例えば、応用階層及び／またはＶ２Ｘ階層がグループ内の端末の数に対する情報を端末のＡＳ階層に提供しない場合、前記端末は、前記グループキャストオプション１を前記特定グループキャストトラフィックに対するＨＡＲＱフィードバックオプションに決定または見なすことができる。例えば、応用階層及び／またはＶ２Ｘ階層が端末の内部ＩＤに対する情報及び／またはグループ内の端末の数に対する情報を端末のＡＳ階層に提供しない場合、前記端末は、前記グループキャストオプション１を前記特定グループキャストトラフィックに対するＨＡＲＱフィードバックオプションに決定または見なすことができる。例えば、前記端末のＡＳ階層は、前記グループキャストオプション１を前記特定グループキャストトラフィックに対するＨＡＲＱフィードバックオプションに決定または見なすことができる。

[220] 例えば、リソースプール特定的に、グループキャストオプション１及び／またはグループキャストオプション２うち少なくともいずれか一つのサポート可否が端末に対してシグナリングされることができる。例えば、リソースプール特定的に、サービスのタイプ、キャストのタイプまたはＱｏＳ要求事項別に、グループキャストオプション１及び／またはグループキャストオプション２うち少なくともいずれか一つのサポート可否が端末に対してシグナリングされることができる。例えば、リソースプール特定的に、サービスのタイプ、キャストのタイプまたはＱｏＳ要求事項別に、グループキャストオプション１と関連したＰＳＦＣＨリソースが設定されるかどうかが端末に対してシグナリングされることができる。例えば、リソースプール特定的に、サービスのタイプ、キャストのタイプまたはＱｏＳ要求事項別に、グループキャストオプション２と関連したＰＳＦＣＨリソースが設定されるかどうかが端末に対してシグナリングされることができる。

[221] ステップＳ２０３０において、送信端末は、複数の受信端末からＨＡＲＱフィードバックを受信することができる。例えば、送信端末は、複数の受信端末からグループキャストオプション１ベースのＨＡＲＱフィードバックを受信することができる。例えば、送信端末は、複数の受信端末からグループキャストオプション２ベースのＨＡＲＱフィードバックを受信することができる。

[222] 例えば、特定グループキャストオプションベースのＨＡＲＱフィードバック動作が特定グループキャストトラフィックに対して要求されることができる。例えば、サービスと関連した信頼度要求事項が高い場合、送信端末が前記サービスを受信端末に送信すると、受信端末は、グループキャストオプション２ベースのＨＡＲＱフィードバック動作を実行する必要がある。もし、受信端末が前記サービスに対してグループキャストオプション１ベースのＨＡＲＱフィードバック動作を実行する場合、ＤＴＸ問題が発生できるため、受信端末は、信頼度要求事項が高いサービスに対してグループキャストオプション２ベースのＨＡＲＱフィードバック動作を実行する必要がある。例えば、ＤＴＸ問題は、受信端末がＰＳＣＣＨ受信に失敗し、かつ送信端末にＮＡＣＫを送信しない場合、送信端末が、受信端末がＰＳＣＣＨ及びＰＳＳＣＨの受信に成功したと誤認する問題である。例えば、前記ＤＴＸ問題によって、前記サービスの信頼度要求事項が満たしにくい。したがって、もし、リソースプール上で特定グループキャストオプションがサポートされない場合、例えば、該当トラフィック及び／またはサービスに対して特定グループキャストオプションがサポートされない場合、送信端末は、ブラインド再送信動作を実行することができる。例えば、もし、特定グループキャストオプションと関連したＰＳＦＣＨリソースが設定されていない場合、送信端末は、ブラインド再送信動作を実行することができる。例えば、送信端末は、受信端末からのＨＡＲＱフィードバック受信無しで再送信を実行することができる。

[223] 本発明の多様な実施例によると、ＳＬ ＨＡＲＱフィードバック送信の信頼度が向上することができ、ＳＬサービスの遅延が減少されることができ、及び／またはＳＬサービスの信頼度が増加されることができる。

[224] 図２１は、本開示の一実施例によって、第１の装置１００がＳＬ ＨＡＲＱフィードバックを送信する方法を示す。図２１の実施例は、本開示の多様な実施例と結合されることができる。

[225] 図２１を参照すると、ステップＳ２１１０において、第１の装置１００は、ＰＳＳＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）を第２の装置２００から受信することができる。

[226] ステップＳ２１２０において、第１の装置１００は、前記ＰＳＳＣＨと関連したＳＬ ＨＡＲＱフィードバックを前記第２の装置２００に送信できる。例えば、前記ＳＬ ＨＡＲＱフィードバックが送信されるリソースは、前記第１の装置１００のＩＤ（ｉｄｅｎｔｉｆｉｅｒ）に基づいて決定されることができる。例えば、前記第１の装置１００のＩＤは、グループ内でグループキャスト通信を実行する複数の端末のうち前記第１の装置１００を識別するためのＩＤである。例えば、前記複数の端末のＩＤは、前記グループ内で互いに異なる。

[227] 例えば、前記ＳＬ ＨＡＲＱフィードバックが送信されるリソースは、前記ＰＳＳＣＨと関連したリソースに対する情報に基づいて決定されることができる。例えば、前記ＰＳＳＣＨと関連したリソースに対する情報は、前記ＰＳＳＣＨと関連した時間に対する情報または前記ＰＳＳＣＨと関連した周波数に対する情報のうち少なくともいずれか一つを含むことができる。

[228] 付加的に、第１の装置１００は、ＰＳＣＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）を前記第２の装置２００から受信することができる。例えば、前記ＳＬ ＨＡＲＱフィードバックが送信されるリソースは、前記ＰＳＣＣＨと関連したリソースに対する情報に基づいて決定されることができる。例えば、前記ＰＳＣＣＨと関連したリソースに対する情報は、前記ＰＳＣＣＨと関連した時間に対する情報または前記ＰＳＣＣＨと関連した周波数に対する情報のうち少なくともいずれか一つを含むことができる。

[229] 例えば、前記ＰＳＳＣＨと関連したリソースと前記ＳＬ ＨＡＲＱフィードバックが送信されるリソースとの間の時間ギャップ（ｔｉｍｅ ｇａｐ）が前記第１の装置１００及び前記第２の装置２００に対して設定されることができる。

[230] 例えば、前記ＳＬ ＨＡＲＱフィードバックが送信されるリソースは、前記ＰＳＳＣＨと関連した周波数領域に含まれることができる。

[231] 付加的に、第１の装置１００は、前記ＰＳＳＣＨ上に含まれているＤＭＲＳに基づいて前記第１の装置１００と前記第２の装置２００との間のチャネル状態を測定することができ、第１の装置１００は、前記チャネル状態に基づいて前記ＳＬ ＨＡＲＱフィードバックの送信電力を決定することができる。例えば、前記ＳＬ ＨＡＲＱフィードバックの送信電力は、サービスのタイプ、前記サービスの優先順位、ＳＬ通信のタイプ、前記サービスと関連したセッション、前記サービスと関連したＰＰＰＰ（ＰｒｏＳｅ Ｐｅｒ Ｐａｃｋｅｔ Ｐｒｉｏｒｉｔｙ）、前記サービスと関連したＰＰＰＲ（ＰｒｏＳｅ Ｐｅｒ Ｐａｃｋｅｔ Ｒｅｌｉａｂｉｌｉｔｙ）、前記サービスと関連したターゲットＢＬＥＲ（Ｂｌｏｃｋ Ｅｒｒｏｒ Ｒａｔｅ）、前記サービスと関連したターゲットＳＩＮＲ（Ｓｉｇｎａｌ ｔｏ Ｉｎｔｅｒｆｅｒｅｎｃｅ ｐｌｕｓ Ｎｏｉｓｅ Ｒａｔｉｏ）、または前記サービスと関連した遅延バジェット（ｌａｔｅｎｃｙ ｂｕｄｇｅｔ）のうち少なくともいずれか一つに基づいて決定されることができる。

[232] 前記提案された方法は、本開示の多様な実施例に係る装置により実行されることができる。まず、第１の装置１００のプロセッサ１０２は、ＰＳＳＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）を第２の装置２００から受信するように送受信機１０６を制御することができる。そして、第１の装置１００のプロセッサ１０２は、前記ＰＳＳＣＨと関連したＳＬ ＨＡＲＱフィードバックを前記第２の装置２００に送信するように送受信機１０６を制御することができる。

[233] 図２２は、本開示の一実施例によって、第２の装置２００がＳＬ ＨＡＲＱフィードバックを受信する方法を示す。図２２の実施例は、本開示の多様な実施例と結合されることができる。

[234] 図２２を参照すると、ステップＳ２２１０において、第２の装置２００は、ＰＳＳＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）をグループ内の複数の端末に送信できる。

[235] ステップＳ２２２０において、第２の装置２００は、前記ＰＳＳＣＨと関連したＳＬ ＨＡＲＱフィードバックを前記複数の端末から受信することができる。例えば、前記ＳＬ ＨＡＲＱフィードバックが受信されるリソースは、前記複数の端末のＩＤ（ｉｄｅｎｔｉｆｉｅｒ）に基づいて決定されることができる。例えば、前記複数の端末のＩＤは、前記グループ内で互いに異なる。例えば、前記ＳＬ ＨＡＲＱフィードバックは、互いに異なるリソース上で前記グループ内の複数の端末から受信されることができる。

[236] 前記提案された方法は、本開示の多様な実施例に係る装置により実行されることができる。まず、第２の装置２００のプロセッサ２０２は、ＰＳＳＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）をグループ内の複数の端末に送信するように送受信機２０６を制御することができる。そして、第２の装置２００のプロセッサ２０２は、前記ＰＳＳＣＨと関連したＳＬ ＨＡＲＱフィードバックを前記複数の端末から受信するように送受信機２０６を制御することができる。

[237] 本開示の多様な実施例は、独立的に具現されることができる。または、本開示の多様な実施例は、相互組み合わせまたは併合されて具現されることができる。例えば、本開示の多様な実施例は、説明の便宜のために３ＧＰＰシステムに基づいて説明されたが、本開示の多様な実施例は、３ＧＰＰシステム外に他のシステムに拡張可能である。

[238] 以下、本開示の多様な実施例が適用されることができる装置に対して説明する。

[239] これに制限されるものではないが、本文書に開示された多様な説明、機能、手順、提案、方法及び／または動作流れ図は、機器間に無線通信／連結（例えば、５Ｇ）を必要とする多様な分野に適用されることができる。

[240] 以下、図面を参照としてより具体的に例示する。以下の図面／設定で同一の図面符号は、異なって記述しない限り、同一または対応するハードウェアブロック、ソフトウェアブロック、または機能ブロックを例示することができる。

[241] 図２３は、本開示の一実施例に係る、通信システム１を示す。

[242] 図２３を参照すると、本開示の多様な実施例が適用される通信システム１は、無線機器、基地局、及びネットワークを含む。ここで、無線機器は、無線接続技術（例えば、５Ｇ ＮＲ（Ｎｅｗ ＲＡＴ）、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ））を利用して通信を実行する機器を意味し、通信／無線／５Ｇ機器と呼ばれる。これに制限されるものではないが、無線機器は、ロボット１００ａ、車両１００ｂ−１、１００ｂ−２、ＸＲ（ｅＸｔｅｎｄｅｄ Ｒｅａｌｉｔｙ）機器１００ｃ、携帯機器（Ｈａｎｄ−ｈｅｌｄ ｄｅｖｉｃｅ）１００ｄ、家電１００ｅ、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇ）機器１００ｆ、ＡＩ機器／サーバ４００を含むことができる。例えば、車両は、無線通信機能が備えられた車両、自律走行車両、車両間の通信を実行することができる車両などを含むことができる。ここで、車両は、ＵＡＶ（Ｕｎｍａｎｎｅｄ Ａｅｒｉａｌ Ｖｅｈｉｃｌｅ）（例えば、ドローン）を含むことができる。ＸＲ機器は、ＡＲ（Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ）／ＶＲ（Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ）／ＭＲ（Ｍｉｘｅｄ Ｒｅａｌｉｔｙ）機器を含み、ＨＭＤ（Ｈｅａｄ−Ｍｏｕｎｔｅｄ Ｄｅｖｉｃｅ）、車両に備えられたＨＵＤ（Ｈｅａｄ−Ｕｐ Ｄｉｓｐｌａｙ）、テレビ、スマートフォン、コンピュータ、ウェアラブルデバイス、家電機器、デジタルサイネージ（ｓｉｇｎａｇｅ）、車両、ロボットなどの形態で具現されることができる。携帯機器は、スマートフォン、スマートパッド、ウェアラブル機器（例えば、スマートウォッチ、スマートグラス）、コンピュータ（例えば、ノートブック等）などを含むことができる。家電は、ＴＶ、冷蔵庫、洗濯機などを含むことができる。ＩｏＴ機器は、センサ、スマートメーターなどを含むことができる。例えば、基地局、ネットワークは、無線機器で具現されることもでき、特定無線機器２００ａは、他の無線機器に基地局／ネットワークノードとして動作することもできる。

[243] 無線機器１００ａ〜１００ｆは、基地局２００を介してネットワーク３００と連結されることができる。無線機器１００ａ〜１００ｆにはＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）技術が適用でき、無線機器１００ａ〜１００ｆはネットワーク３００を介してＡＩサーバ４００と連結されることができる。ネットワーク３００は、３Ｇネットワーク、４Ｇ（例えば、ＬＴＥ）ネットワークまたは５Ｇ（例えば、ＮＲ）ネットワークなどを用いて構成されることができる。無線機器１００ａ〜１００ｆは、基地局２００／ネットワーク３００を介して互いに通信することもできるが、基地局／ネットワークを介することなく、直接通信（例えば、サイドリンク通信（ｓｉｄｅｌｉｎｋ ｃｏｍｍｕｎｉｃａｔｉｏｎ））することもできる。例えば、車両１００ｂ−１、１００ｂ−２は、直接通信（例えば、Ｖ２Ｖ（Ｖｅｈｉｃｌｅ ｔｏ Ｖｅｈｉｃｌｅ）／Ｖ２Ｘ（Ｖｅｈｉｃｌｅ ｔｏ ｅｖｅｒｙｔｈｉｎｇ） ｃｏｍｍｕｎｉｃａｔｉｏｎ）をすることができる。また、ＩｏＴ機器（例えば、センサ）は、他のＩｏＴ機器（例えば、センサ）または他の無線機器１００ａ〜１００ｆと直接通信を行うことができる。

[244] 無線機器１００ａ〜１００ｆ／基地局２００、基地局２００／基地局２００間には無線通信／連結１５０ａ、１５０ｂ、１５０ｃが行われることができる。ここで、無線通信／連結は、アップリンク／ダウンリンク通信１５０ａ、サイドリンク通信１５０ｂ（または、Ｄ２Ｄ通信）、及び基地局間の通信１５０ｃ（例えば、ｒｅｌａｙ、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ Ｂａｃｋｈａｕｌ）のような多様な無線接続技術（例えば、５Ｇ ＮＲ）を介して行われることができる。無線通信／連結１５０ａ、１５０ｂ、１５０ｃを介して無線機器と基地局／無線機器、基地局と基地局は、互いに無線信号を送信／受信することができる。例えば、無線通信／連結１５０ａ、１５０ｂ、１５０ｃは、多様な物理チャネルを介して信号を送信／受信することができる。このために、本開示の多様な提案に基づいて、無線信号の送信／受信のための多様な構成情報設定過程、多様な信号処理過程（例えば、チャネルエンコーディング／デコーディング、変調／復調、リソースマッピング／デマッピング等）、リソース割当過程などのうち少なくとも一部が実行されることができる。

[245] 図２４は、本開示の一実施例に係る、無線機器を示す。

[246] 図２４を参照すると、第１の無線機器１００と第２の無線機器２００は、様々な無線アクセス技術（例えば、ＬＴＥ、ＮＲ）を介して無線信号を送受信することができる。ここで、｛第１の無線機器１００、第２の無線機器２００｝は、図２３の｛無線機器１００ｘ、基地局２００｝及び／または｛無線機器１００ｘ、無線機器１００ｘ｝に対応し得る。

[247] 第１の無線機器１００は、一つ以上のプロセッサ１０２及び一つ以上のメモリ１０４を含み、追加的に一つ以上の送受信機１０６及び／または一つ以上のアンテナ１０８をさらに含むことができる。プロセッサ１０２は、メモリ１０４及び／または送受信機１０６を制御し、本文書に開示された説明、機能、手順、提案、方法及び／または動作流れ図を具現するように構成されることができる。例えば、プロセッサ１０２は、メモリ１０４内の情報を処理して第１の情報／信号を生成した後、送受信機１０６を介して第１の情報／信号を含む無線信号を送信することができる。また、プロセッサ１０２は、送受信機１０６を介して第２の情報／信号を含む無線信号を受信した後、第２の情報／信号の信号処理から得た情報をメモリ１０４に格納することができる。メモリ１０４は、プロセッサ１０２と連結されることができ、プロセッサ１０２の動作と関連した多様な情報を格納することができる。例えば、メモリ１０４は、プロセッサ１０２により制御されるプロセスのうち一部または全部を実行し、または本文書に開示された説明、機能、手順、提案、方法及び／または動作流れ図を実行するための命令を含むソフトウェアコードを格納することができる。ここで、プロセッサ１０２とメモリ１０４は、無線通信技術（例えば、ＬＴＥ、ＮＲ）を具現するように設計された通信モデム／回路／チップの一部である。送受信機１０６は、プロセッサ１０２と連結されることができ、一つ以上のアンテナ１０８を介して無線信号を送信及び／または受信することができる。送受信機１０６は、送信機及び／または受信機を含むことができる。送受信機１０６は、ＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）ユニットと混用されることができる。本開示において、無線機器は、通信モデム／回路／チップを意味することもできる。

[248] 第２の無線機器２００は、一つ以上のプロセッサ２０２、一つ以上のメモリ２０４を含み、追加的に一つ以上の送受信機２０６及び／または一つ以上のアンテナ２０８をさらに含むことができる。プロセッサ２０２は、メモリ２０４及び／または送受信機２０６を制御し、本文書に開示された説明、機能、手順、提案、方法及び／または動作流れ図を具現するように構成されることができる。例えば、プロセッサ２０２は、メモリ２０４内の情報を処理して第３の情報／信号を生成した後、送受信機２０６を介して第３の情報／信号を含む無線信号を送信することができる。また、プロセッサ２０２は、送受信機２０６を介して第４の情報／信号を含む無線信号を受信した後、第４の情報／信号の信号処理から得た情報をメモリ２０４に格納することができる。メモリ２０４は、プロセッサ２０２と連結されることができ、プロセッサ２０２の動作と関連した多様な情報を格納することができる。例えば、メモリ２０４は、プロセッサ２０２により制御されるプロセスのうち一部または全部を実行し、または本文書に開示された説明、機能、手順、提案、方法及び／または動作流れ図を実行するための命令を含むソフトウェアコードを格納することができる。ここで、プロセッサ２０２とメモリ２０４は、無線通信技術（例えば、ＬＴＥ、ＮＲ）を具現するように設計された通信モデム／回路／チップの一部である。送受信機２０６は、プロセッサ２０２と連結されることができ、一つ以上のアンテナ２０８を介して無線信号を送信及び／または受信することができる。送受信機２０６は、送信機及び／または受信機を含むことができる。送受信機２０６は、ＲＦユニットと混用されることができる。本開示において、無線機器は、通信モデム／回路／チップを意味することもできる。

[249] 以下、無線機器１００、２００のハードウェア要素に対してより具体的に説明する。これに制限されるものではないが、一つ以上のプロトコル階層が一つ以上のプロセッサ１０２、２０２により具現されることができる。例えば、一つ以上のプロセッサ１０２、２０２は、一つ以上の階層（例えば、ＰＨＹ、ＭＡＣ、ＲＬＣ、ＰＤＣＰ、ＲＲＣ、ＳＤＡＰのような機能的階層）を具現することができる。一つ以上のプロセッサ１０２、２０２は、本文書に開示された説明、機能、手順、提案、方法及び／または動作流れ図によって、一つ以上のＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）及び／または一つ以上のＳＤＵ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）を生成することができる。一つ以上のプロセッサ１０２、２０２は、本文書に開示された説明、機能、手順、提案、方法及び／または動作流れ図によって、メッセージ、制御情報、データまたは情報を生成することができる。一つ以上のプロセッサ１０２、２０２は、本文書に開示された機能、手順、提案及び／または方法によって、ＰＤＵ、ＳＤＵ、メッセージ、制御情報、データまたは情報を含む信号（例えば、ベースバンド信号）を生成し、一つ以上の送受信機１０６、２０６に提供できる。一つ以上のプロセッサ１０２、２０２は、一つ以上の送受信機１０６、２０６から信号（例えば、ベースバンド信号）を受信することができ、本文書に開示された説明、機能、手順、提案、方法及び／または動作流れ図によって、ＰＤＵ、ＳＤＵ、メッセージ、制御情報、データまたは情報を取得することができる。

[250] 一つ以上のプロセッサ１０２、２０２は、コントローラ、マイクロコントローラ、マイクロプロセッサまたはマイクロコンピュータと呼ばれる。一つ以上のプロセッサ１０２、２０２は、ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせにより具現されることができる。一例として、一つ以上のＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、一つ以上のＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、一つ以上のＤＳＰＤ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｄｅｖｉｃｅ）、一つ以上のＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）または一つ以上のＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙｓ）が一つ以上のプロセッサ１０２、２０２に含まれることができる。本文書に開示された説明、機能、手順、提案、方法及び／または動作流れ図は、ファームウェアまたはソフトウェアを使用して具現されることができ、ファームウェアまたはソフトウェアは、モジュール、手順、機能などを含むように具現されることができる。本文書に開示された説明、機能、手順、提案、方法及び／または動作流れ図は、実行するように設定されたファームウェアまたはソフトウェアは、一つ以上のプロセッサ１０２、２０２に含まれ、または一つ以上のメモリ１０４、２０４に格納されて一つ以上のプロセッサ１０２、２０２により駆動されることができる。本文書に開示された説明、機能、手順、提案、方法及び／または動作流れ図は、コード、命令語及び／または命令語の集合形態でファームウェアまたはソフトウェアを使用して具現されることができる。

[251] 一つ以上のメモリ１０４、２０４は、一つ以上のプロセッサ１０２、２０２と連結されることができ、様々な形態のデータ、信号、メッセージ、情報、プログラム、コード、指示及び／または命令を格納することができる。一つ以上のメモリ１０４、２０４は、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、フラッシュメモリ、ハードドライブ、レジスタ、キャッシュメモリ、コンピュータ読取格納媒体及び／またはこれらの組み合わせで構成されることができる。一つ以上のメモリ１０４、２０４は、一つ以上のプロセッサ１０２、２０２の内部及び／または外部に位置し得る。また、一つ以上のメモリ１０４、２０４は、有線または無線連結のような様々な技術を介して、一つ以上のプロセッサ１０２、２０２と連結されることができる。

[252] 一つ以上の送受信機１０６、２０６は、一つ以上の他の装置に本文書の方法及び／または動作流れ図等で言及されるユーザデータ、制御情報、無線信号／チャネルなどを送信することができる。一つ以上の送受信機１０６、２０６は、一つ以上の他の装置から本文書に開示された説明、機能、手順、提案、方法及び／または動作流れ図等で言及されるユーザデータ、制御情報、無線信号／チャネルなどを受信することができる。例えば、一つ以上の送受信機１０６、２０６は、一つ以上のプロセッサ１０２、２０２と連結されることができ、無線信号を送受信することができる。例えば、一つ以上のプロセッサ１０２、２０２は、一つ以上の送受信機１０６、２０６が一つ以上の他の装置にユーザデータ、制御情報または無線信号を送信するように制御できる。また、一つ以上のプロセッサ１０２、２０２は、一つ以上の送受信機１０６、２０６が一つ以上の他の装置からユーザデータ、制御情報または無線信号を受信するように制御できる。また、一つ以上の送受信機１０６、２０６は、一つ以上のアンテナ１０８、２０８と連結されることができ、一つ以上の送受信機１０６、２０６は、一つ以上のアンテナ１０８、２０８を介して本文書に開示された説明、機能、手順、提案、方法及び／または動作流れ図等で言及されるユーザデータ、制御情報、無線信号／チャネルなどを送受信するように設定されることができる。本文書で、一つ以上のアンテナは、複数の物理アンテナであり、または複数の論理アンテナ（例えば、アンテナポート）である。一つ以上の送受信機１０６、２０６は、受信されたユーザデータ、制御情報、無線信号／チャネルなどを一つ以上のプロセッサ１０２、２０２を利用して処理するために、受信された無線信号／チャネルなどをＲＦバンド信号からベースバンド信号に変換（Ｃｏｎｖｅｒｔ）できる。一つ以上の送受信機１０６、２０６は、一つ以上のプロセッサ１０２、２０２を利用して処理されたユーザデータ、制御情報、無線信号／チャネルなどをベースバンド信号からＲＦバンド信号に変換できる。このために、一つ以上の送受信機１０６、２０６は、（アナログ）オシレータ及び／またはフィルタを含むことができる。

[253] 図２５は、本開示の一実施例に係る、送信信号のための信号処理回路を示す。

[254] 図２５を参照すると、信号処理回路１０００は、スクランブラー１０１０、変調器１０２０、レイヤーマッパー１０３０、プリコーダ１０４０、リソースマッパー１０５０、信号生成器１０６０を含むことができる。これに制限されるわけではないが、図２５の動作／機能は、図２４のプロセッサ１０２、２０２及び／または送受信機１０６、２０６で行われることができる。図２５のハードウェア要素は、図２４のプロセッサ１０２、２０２及び／または送受信機１０６、２０６で実現できる。例えば、ブロック１０１０〜１０６０は、図２４のプロセッサ１０２、２０２で実現できる。また、ブロック１０１０〜１０５０は、図２４のプロセッサ１０２、２０２で実現され、ブロック１０６０は、図２４の送受信機１０６、２０６で実現できる。

[255] コードワードは、図２５の信号処理回路１０００を経て、無線信号に変換されることができる。ここで、コードワードは、情報ブロックの符号化されたビットシーケンスである。情報ブロックは、送信ブロック（例えば、ＵＬ−ＳＣＨの送信ブロック、ＤＬ−ＳＣＨの送信ブロック）を含むことができる。無線信号は、様々な物理チャネル（例えば、ＰＵＳＣＨ、ＰＤＳＣＨ）を介して送信されることができる。

[256] 具体的に、コードワードは、スクランブラー１０１０によりスクランブルされたビットシーケンスに変換されることができる。スクランブルに使用されるスクランブルシーケンスは、初期化値に基づいて生成され、初期化値は無線機器のＩＤ情報などが含まれることができる。スクランブルされたビットシーケンスは、変調器１０２０により変調シンボルのシーケンスに変調されることができる。変調方式は、ｐｉ／２−ＢＰＳＫ（ｐｉ／２−Ｂｉｎａｒｙ Ｐｈａｓｅ Ｓｈｉｆｔ Ｋｅｙｉｎｇ）、ｍ−ＰＳＫ（ｍ−Ｐｈａｓｅ Ｓｈｉｆｔ Ｋｅｙｉｎｇ）、ｍ−ＱＡＭ（ｍ−Ｑｕａｄｒａｔｕｒｅ Ａｍｐｌｉｔｕｄｅ Ｍｏｄｕｌａｔｉｏｎ）などを含むことができる。複素変調シンボルのシーケンスは、レイヤーマッパー１０３０により一つ以上の送信レイヤーにマッピングされることができる。各送信レイヤーの変調シンボルは、プリコーダ１０４０により該当アンテナポートにマッピングされることができる（プリコーディング）。プリコーダ１０４０の出力ｚは、レイヤーマッパー１０３０の出力ｙをＮ＊Ｍのプリコーディング行列Ｗと掛けて得られる。ここで、Ｎはアンテナポートの数、Ｍは送信レイヤーの数である。ここで、プリコーダ１０４０は、複素変調シンボルに対するトランスフォーム（ｔｒａｎｓｆｏｒｍ）プリコーディング（例えば、ＤＦＴ変換）を行った以降にプリコーディングを行うことができる。また、プリコーダ１０４０は、トランスフォームプリコーディングを行わずにプリコーディングを行うことができる。

[257] リソースマッパー１０５０は、各アンテナポートの変調シンボルを時間−周波数リソースにマッピングできる。時間−周波数リソースは、時間ドメインで複数のシンボル（例えば、ＣＰ−ＯＦＤＭＡシンボル、ＤＦＴ−ｓ−ＯＦＤＭＡシンボル）を含み、周波数ドメインで複数の副搬送波を含むことができる。信号生成器１０６０は、マッピングされた変調シンボルから無線信号を生成し、生成された無線信号は各アンテナを介して他の機器へ送信されることができる。このために、信号生成器１０６０は、ＩＦＦＴ（Ｉｎｖｅｒｓｅ Ｆａｓｔ Ｆｏｕｒｉｅｒ Ｔｒａｎｓｆｏｒｍ）モジュール及びＣＰ（Ｃｙｃｌｉｃ Ｐｒｅｆｉｘ）挿入器、ＤＡＣ（Ｄｉｇｉｔａｌ−ｔｏ−Ａｎａｌｏｇ Ｃｏｎｖｅｒｔｅｒ）、周波数アップリンク変換器（ｆｒｅｑｕｅｎｃｙ ｕｐｌｉｎｋ ｃｏｎｖｅｒｔｅｒ）などを含むことができる。

[258] 無線機器における受信信号のための信号処理過程は、図２５の信号処理過程１０１０〜１０６０の逆で構成されることができる。例えば、無線機器（例えば、図２４の１００、２００）は、アンテナポート／送受信機を介して外部から無線信号を受信することができる。受信された無線信号は、信号復元器を介してベースバンド信号に変換されることができる。このために、信号復元装置は、周波数ダウンリンク変換器（ｆｒｅｑｕｅｎｃｙ ｄｏｗｎｌｉｎｋ ｃｏｎｖｅｒｔｅｒ）、ＡＤＣ（ａｎａｌｏｇ−ｔｏ−ｄｉｇｉｔａｌ ｃｏｎｖｅｒｔｅｒ）、ＣＰ除去器、ＦＦＴ（Ｆａｓｔ Ｆｏｕｒｉｅｒ Ｔｒａｎｓｆｏｒｍ）モジュールを含むことができる。以降、ベースバンド信号は、リソースデマッパー過程、ポストコーディング（ｐｏｓｔｃｏｄｉｎｇ）過程、復調過程、及びデスクランブル過程を経て、コードワードに復元されることができる。コードワードは、復号（ｄｅｃｏｄｉｎｇ）を経て、元の情報ブロックに復元されることができる。従って、受信信号のための信号処理回路（図示せず）は、信号復元器、リソースデマッパー、ポストコーダー、復調器、デスクランブラー、及び復号器を含むことができる。

[259] 図２６は、本開示の一実施例に係る、無線機器を示す。無線機器は使用−例／サービスによって多様な形態で具現されることができる（図２３参照）。

[260] 図２６を参照すると、無線機器１００、２００は、図２４の無線機器１００、２００に対応し、様々な要素（ｅｌｅｍｅｎｔ）、成分（ｃｏｍｐｏｎｅｎｔ）、ユニット／部（ｕｎｉｔ）、及び／またはモジュール（ｍｏｄｕｌｅ）で構成されることができる。例えば、無線機器１００、２００は、通信部１１０、制御部１２０、メモリ部１３０、及び追加要素１４０を含むことができる。通信部は、通信回路１１２及び送受信機１１４を含むことができる。例えば、通信回路１１２は、図２４の一つ以上のプロセッサ１０２、２０２及び／または一つ以上のメモリ１０４、２０４を含むことができる。例えば、送受信機１１４は、図２４の一つ以上の送受信機１０６、２０６及び／または一つ以上のアンテナ１０８、２０８を含むことができる。制御部１２０は、通信部１１０、メモリ部１３０、及び追加要素１４０と電気的に連結され、無線機器の諸般動作を制御する。例えば、制御部１２０は、メモリ部１３０に格納されたプログラム／コード／命令／情報に基づいて、無線機器の電気的／機械的動作を制御することができる。また、制御部１２０は、メモリ部１３０に格納された情報を通信部１１０を介して、外部（例えば、他の通信機器）に無線／有線インターフェースを介して送信するか、通信部１１０を介して、外部（例えば、他の通信機器）から無線／有線インターフェースを介して受信された情報をメモリ部１３０に格納することができる。

[261] 追加要素１４０は、無線機器の種類に応じて多様に構成されることができる。例えば、追加要素１４０は、パワーユニット／バッテリー、入出力部（Ｉ／Ｏ部）、駆動部、及びコンピューティング部のうち少なくとも一つを含むことができる。これに制限されるわけではないが、無線機器は、ロボット（図２３、１００ａ）、車両１００ｂ−１、１００ｂ−２（図２３）、ＸＲ機器１００ｃ（図２３）携帯機器１００ｄ（図２３）、家電１００ｅ（図２３）、ＩｏＴ機器１００ｆ（図２３）、デジタル放送用端末、ホログラム装置、公共安全装置、ＭＴＣ装置、医療装置、フィンテック装置（または、金融装置）、保安装置、気候／環境装置、ＡＩサーバ／機器４００（図２３）、基地局２００（図２３）、ネットワークノード等の形態で実現できる。無線機器は、使用−例／サービスに応じて、移動可能であるか、固定された場所で使用できる。

[262] 図２６で、無線機器１００、２００内の様々な要素、成分、ユニット／部、及び／またはモジュールは、全体が有線インターフェースを介して相互連結されるか、少なくとも一部が通信部１１０を介して無線で連結されることができる。例えば、無線機器１００、２００内で制御部１２０と通信部１１０は有線で連結され、制御部１２０と第１ユニット（例えば、１３０、１４０）は、通信部１１０を介して無線で連結されることができる。また、無線機器１００、２００内の各要素、成分、ユニット／部、要素、及び／またはモジュールは、一つ以上の要素をさらに含むことができる。例えば、制御部１２０は、一つ以上のプロセッサの集合で構成されることができる。例えば、制御部１２０は、通信制御プロセッサ、アプリケーションプロセッサ（Ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｃｅｓｓｏｒ）、ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）、グラフィック処理プロセッサ、メモリ制御プロセッサ等の集合で構成されることができる。別の例として、メモリ部１３０は、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ ＲＡＭ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フラッシュメモリ（ｆｌａｓｈ ｍｅｍｏｒｙ）、揮発性メモリ（ｖｏｌａｔｉｌｅ ｍｅｍｏｒｙ）、非−揮発性メモリ（ｎｏｎ−ｖｏｌａｔｉｌｅ ｍｅｍｏｒｙ）及び／またはこれらの組み合わせで構成されることができる。

[263] 以下、図２６の実現例について、図を参照としてより詳細に説明する。

[264] 図２７は、本開示の一実施例に係る、携帯機器を示す。携帯機器は、スマートフォン、スマートパッド、ウェアラブル機器（例えば、スマートウォッチ、スマートグラス）、携帯用コンピュータ（例えば、ノートブック等）を含むことができる。携帯機器は、ＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、ＵＴ（ｕｓｅｒ ｔｅｒｍｉｎａｌ）、ＭＳＳ（Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）、ＳＳ（Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）、ＡＭＳ（Ａｄｖａｎｃｅｄ Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）またはＷＴ（Ｗｉｒｅｌｅｓｓ ｔｅｒｍｉｎａｌ）と呼ばれる。

[265] 図２７を参照すると、携帯機器１００は、アンテナ部１０８、通信部１１０、制御部１２０、メモリ部１３０、電源供給部１４０ａ、インターフェース部１４０ｂ、及び入出力部１４０ｃを含むことができる。アンテナ部１０８は、通信部１１０の一部で構成されることができる。ブロック１１０〜１３０／１４０ａ〜１４０ｃは、各々、図２６のブロック１１０〜１３０／１４０に対応する。

[266] 通信部１１０は、他の無線機器、基地局と信号（例えば、データ、制御信号など）を送受信することができる。制御部１２０は、携帯機器１００の構成要素を制御し、様々な動作を行うことができる。制御部１２０は、ＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｃｅｓｓｏｒ）を含むことができる。メモリ部１３０は、携帯機器１００の駆動に必要なデータ／パラメータ／プログラム／コード／命令を格納することができる。また、メモリ部１３０は、入／出力されるデータ／情報等を格納することができる。電源供給部１４０ａは、携帯機器１００に電源を供給し、有／無線充電回路、バッテリーなどを含むことができる。インターフェース部１４０ｂは、携帯機器１００と他の外部機器の連結をサポートすることができる。インターフェース部１４０ｂは、外部機器との連結のための様々なポート（例えば、オーディオの入／出力ポート、ビデオの入／出力ポート）を含むことができる。入出力部１４０ｃは、画像情報／信号、オーディオ情報／信号、データ、及び／またはユーザから入力される情報が入力されるか、出力することができる。入出力部１４０ｃは、カメラ、マイクロフォン、ユーザ入力部、ディスプレイ部１４０ｄ、スピーカー及び／またはハプティックモジュールなどを含むことができる。

[267] 一例として、データ通信の場合、入出力部１４０ｃは、ユーザから入力された情報／信号（例えば、タッチ、文字、音声、イメージ、ビデオ）を取得し、取得された情報／信号はメモリ部１３０に格納されることができる。通信部１１０は、メモリに格納された情報／信号を無線信号に変換し、変換された無線信号を他の無線機器に直接送信するか、基地局に送信できる。また、通信部１１０は、他の無線機器または基地局から無線信号を受信した後、受信された無線信号を元の情報／信号に復元できる。復元された情報／信号は、メモリ部１３０に格納された後、入出力部１４０ｃを介して様々な形態（例えば、文字、音声、イメージ、ビデオ、ハプティック）で出力されることができる。

[268] 図２８は、本開示の一実施例に係る、車両または自律走行車両を示す。車両または自律走行車両は、移動型ロボット、車両、汽車、有／無人飛行体（Ａｅｒｉａｌ Ｖｅｈｉｃｌｅ、ＡＶ）、船舶などで具現されることができる。

[269] 図２８を参照すると、車両または自律走行車両１００は、アンテナ部１０８、通信部１１０、制御部１２０、駆動部１４０ａ、電源供給部１４０ｂ、センサ部１４０ｃ、及び自律走行部１４０ｄを含むことができる。アンテナ部１０８は、通信部１１０の一部で構成されることができる。ブロック１１０／１３０／１４０ａ〜１４０ｄは、各々、図２６のブロック１１０／１３０／１４０に対応する。

[270] 通信部１１０は、他の車両、基地局（例えば、基地局、路辺基地局（Ｒｏａｄ Ｓｉｄｅ ｕｎｉｔ）等）、サーバなどの外部機器と信号（例えば、データ、制御信号等）を送受信することができる。制御部１２０は、車両または自律走行車両１００の要素を制御し、様々な動作を行うことができる。制御部１２０は、ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）を含むことができる。駆動部１４０ａは、車両または自律走行車両１００を地上で走行させることができる。駆動部１４０ａは、エンジン、モータ、パワートレーン、輪、ブレーキ、ステアリングなどを含むことができる。電源供給部１４０ｂは、車両または自律走行車両１００に電源を供給し、有／無線充電回路、バッテリーなどを含むことができる。センサ部１４０ｃは、車両状態、周辺環境情報、ユーザ情報等が得られる。センサ部１４０ｃは、ＩＭＵ（ｉｎｅｒｔｉａｌ ｍｅａｓｕｒｅｍｅｎｔ ｕｎｉｔ）センサ、衝突センサ、ホイールセンサ（ｗｈｅｅｌ ｓｅｎｓｏｒ）、速度センサ、傾斜センサ、重量感知センサ、ヘッディングセンサ（ｈｅａｄｉｎｇ ｓｅｎｓｏｒ）、ポジションモジュール（ｐｏｓｉｔｉｏｎ ｍｏｄｕｌｅ）、車両の前進／後進センサ、バッテリーセンサ、燃料センサ、タイヤセンサ、ステアリングセンサ、温度センサ、湿度センサ、超音波センサ、照度センサ、ペダルポジションセンサなどを含むことができる。自律走行部１４０ｄは、走行中である車線を維持する技術、アダプティブ・クルーズ・コントロールのように速度を自動で調節する技術、決められた経路に沿って自動で走行する技術、目的地が設定されると、自動で経路を設定して走行する技術などを実現することができる。

[271] 一例として、通信部１１０は、外部サーバから地図データ、交通情報データ等を受信することができる。自律走行部１４０ｄは、取得されたデータに基づいて自律走行経路とドライビングプランを生成することができる。制御部１２０は、ドライビングプランに従って、車両または自律走行車両１００が自律走行経路に沿って移動するように駆動部１４０ａを制御することができる（例えば、速度／方向調節）。自律走行の途中、通信部１１０は外部サーバから最新の交通情報データを非／周期的に取得し、周辺の車両から周辺の交通情報データを取得することができる。また、自律走行の途中、センサ部１４０ｃは、車両状態、周辺環境情報を取得することができる。自律走行部１４０ｄは、新たに取得されたデータ／情報に基づいて自律走行経路とドライビングプランを更新することができる。通信部１１０は、車両位置、自律走行経路、ドライビングプランなどに関する情報を外部サーバに伝達することができる。外部サーバは、車両または自律走行車両から収集された情報に基づいて、ＡＩ技術などを利用して交通情報データを予め予測することができ、予測された交通情報データを車両または自律走行車両に提供できる。

[272] 図２９は、本開示の一実施例に係る、車両を示す。車両は、運送手段、汽車、飛行体、船舶などで具現されることもできる。

[273] 図２９を参照すると、車両１００は、通信部１１０、制御部１２０、メモリ部１３０、入出力部１４０ａ、及び位置測定部１４０ｂを含むことができる。ここで、ブロック１１０〜１３０／１４０ａ〜１４０ｂは、各々、図２６のブロック１１０〜１３０／１４０に対応する。

[274] 通信部１１０は、他の車両、または基地局などの外部機器と信号（例えば、データ、制御信号等）を送受信することができる。制御部１２０は、車両１００の構成要素を制御して様々な動作を行うことができる。メモリ部１３０は、車両１００の様々な機能をサポートするデータ／パラメータ／プログラム／コード／命令を格納することができる。入出力部１４０ａは、メモリ部１３０内の情報に基づいて、ＡＲ／ＶＲオブジェクトを出力することができる。入出力部１４０ａは、ＨＵＤを含むことができる。位置測定部１４０ｂは、車両１００の位置情報を取得することができる。位置情報は、車両１００の絶対位置情報、走行線内での位置情報、加速度情報、周辺車両との位置などを含むことができる。位置測定部１４０ｂは、ＧＰＳ及び様々なセンサを含むことができる。

[275] 一例として、車両１００の通信部１１０は、外部サーバから地図情報、交通情報などを受信してメモリ部１３０に格納することができる。位置測定部１４０ｂは、ＧＰＳ及び様々なセンサを介して、車両の位置情報を取得してメモリ部１３０に格納することができる。制御部１２０は、地図情報、交通情報、及び車両の位置情報等に基づいて仮想のオブジェクトを生成し、入出力部１４０ａは、生成された仮想のオブジェクトを車両内のガラス窓に表示できる（１４１０、１４２０）。また、制御部１２０は、車両の位置情報に基づいて車両１００が走行線内で正常に運行されているか判断できる。車両１００が走行線を非正常に外れる場合、制御部１２０は、入出力部１４０ａを介して車両内ガラス窓に警告を表示することができる。また、制御部１２０は、通信部１１０を介して、周辺の車両に走行異常に関する警告メッセージを放送することができる。状況に応じて、制御部１２０は通信部１１０を介して、関係機関に車両の位置情報と、走行／車両異常に関する情報を送信することができる。

[276] 図３０は、本開示の一実施例に係る、ＸＲ機器を示す。ＸＲ機器は、ＨＭＤ、車両に備えられたＨＵＤ（Ｈｅａｄ−Ｕｐ Ｄｉｓｐｌａｙ）、テレビ、スマートフォン、コンピュータ、ウェアラブルデバイス、家電機器、デジタルサイネージ（ｓｉｇｎａｇｅ）、車両、ロボットなどで具現されることができる。

[277] 図３０を参照すると、ＸＲ機器１００ａは、通信部１１０、制御部１２０、メモリ部１３０、入出力部１４０ａ、センサ部１４０ｂ、及び電源供給部１４０ｃを含むことができる。ここで、ブロック１１０〜１３０／１４０ａ〜１４０ｃは、各々、図２６のブロック１１０〜１３０／１４０に対応する。

[278] 通信部１１０は、他の無線機器、携帯機器、またはメディアサーバなどの外部機器と信号（例えば、メディアデータ、制御信号等）を送受信することができる。メディアデータは、画像、イメージ、音などを含むことができる。制御部１２０は、ＸＲ機器１００ａの構成要素を制御し、様々な動作を行うことができる。例えば、制御部１２０は、ビデオ／イメージの取得、（ビデオ／イメージ）エンコーディング、メタデータの生成及び処理などの手続を制御及び／または実行するように構成されることができる。メモリ部１３０は、ＸＲ機器１００ａの駆動／ＸＲオブジェクトの生成に必要なデータ／パラメータ／プログラム／コード／命令を格納することができる。入出力部１４０ａは外部から制御情報、データ等を取得し、生成されたＸＲオブジェクトを出力することができる。入出力部１４０ａは、カメラ、マイクロフォン、ユーザ入力部、ディスプレイ部、スピーカ及び／またはハプティックモジュールなどを含むことができる。センサ部１４０ｂは、ＸＲ機器の状態、周辺環境情報、ユーザ情報等が得られる。センサ部１４０ｂは、近接センサ、照度センサ、加速度センサ、磁気センサ、ジャイロセンサ、慣性センサ、ＲＧＢセンサ、ＩＲセンサ、指紋認識センサ、超音波センサ、光センサ、マイクロフォン、及び／またはレーダー等を含むことができる。電源供給部１４０ｃは、ＸＲ機器１００ａに電源を供給し、有／無線充電回路、バッテリーなどを含むことができる。

[279] 一例として、ＸＲ機器１００ａのメモリ部１３０は、ＸＲオブジェクト（例えば、ＡＲ／ＶＲ／ＭＲオブジェクト）の生成に必要な情報（例えば、データ等）を含むことができる。入出力部１４０ａは、ユーザからＸＲ機器１００ａを操作する命令を取得することができ、制御部１２０は、ユーザの駆動命令によってＸＲ機器１００ａを駆動させることができる。例えば、ユーザがＸＲ機器１００ａを介して、映画、ニュース等を視聴しようとする場合、制御部１２０は、通信部１３０を介してコンテンツ要求情報を他の機器（例えば、携帯機器１００ｂ）またはメディアサーバに送信できる。通信部１３０は、他の機器（例えば、携帯機器１００ｂ）またはメディアサーバから映画、ニュース等のコンテンツをメモリ部１３０にダウンロード／ストリーミングを受けることができる。制御部１２０は、コンテンツに対してビデオ／イメージ取得、（ビデオ／イメージ）エンコーディング、メタデータの生成／処理などの手続を制御及び／または実行し、入出力部１４０ａ／センサ部１４０ｂを介して取得した周辺空間または現実のオブジェクトに対する情報に基づいて、ＸＲオブジェクトを生成／出力することができる。

[280] また、ＸＲ機器１００ａは、通信部１１０を介して携帯機器１００ｂと無線で連結され、ＸＲ機器１００ａの動作は携帯機器１００ｂにより制御されることができる。例えば、携帯機器１００ｂは、ＸＲ機器１００ａに対するコントローラとして動作できる。このために、ＸＲ機器１００ａは携帯機器１００ｂの３次元の位置情報を取得した後、携帯機器１００ｂに対応するＸＲ個体を生成して出力することができる。

[281] 図３１は、本開示の一実施例に係る、ロボットを示す。ロボットは、使用目的や分野によって、産業用、医療用、家庭用、軍事用等に分類されることができる。

[282] 図３１を参照すると、ロボット１００は、通信部１１０、制御部１２０、メモリ部１３０、入出力部１４０ａ、センサ部１４０ｂ、及び駆動部１４０ｃを含むことができる。ここで、ブロック１１０〜１３０／１４０ａ〜１４０ｃは、各々、図２６のブロック１１０〜１３０／１４０に対応する。

[283] 通信部１１０は、他の無線機器、他のロボット、または制御サーバなどの外部機器と信号（例えば、駆動情報、制御信号等）を送受信することができる。制御部１２０は、ロボット１００の構成要素を制御して様々な動作を行うことができる。メモリ部１３０は、ロボット１００の様々な機能をサポートするデータ／パラメータ／プログラム／コード／命令を格納することができる。入出力部１４０ａは、ロボット１００の外部から情報を取得し、ロボット１００の外部に情報を出力することができる。入出力部１４０ａは、カメラ、マイクロフォン、ユーザ入力部、ディスプレイ部、スピーカ及び／またはハプティックモジュールなどを含むことができる。センサ部１４０ｂは、ロボット１００の内部情報、周辺環境情報、ユーザ情報等が得られる。センサ部１４０ｂは、近接センサ、照度センサ、加速度センサ、磁気センサ、ジャイロセンサ、慣性センサ、ＩＲセンサ、指紋認識センサ、超音波センサ、光センサ、マイクロフォン、レーダー等を含むことができる。駆動部１４０ｃは、ロボットの関節を動くなどの様々な物理的動作を行うことができる。また、駆動部１４０ｃは、ロボット１００を地上で走行するか、空中で飛行させることができる。駆動部１４０ｃはアクチュエータ、モータ、輪、ブレーキ、プロペラなどを含むことができる。

[284] 図３２は、本開示の一実施例に係る、ＡＩ機器を示す。ＡＩ機器は、ＴＶ、プロジェクター、スマートフォン、ＰＣ、ノートブック、デジタル放送用端末機、タブレートＰＣ、ウェアラブル装置、セットトップボックス（ＳＴＢ）、ラジオ、洗濯機、冷蔵庫、デジタルサイネージ、ロボット、車両などのような、固定型機器または移動可能な機器などで具現されることができる。

[285] 図３２を参照すると、ＡＩ機器１００は、通信部１１０、制御部１２０、メモリ部１３０、入／出力部１４０ａ／１４０ｂ、ラーニングプロセッサ部１４０ｃ、及びセンサ部１４０ｄを含むことができる。ブロック１１０〜１３０／１４０ａ〜１４０ｄは、各々、図２６のブロック１１０〜１３０／１４０に対応する。

[286] 通信部１１０は、有無線通信技術を利用して他のＡＩ機器（例えば、図２３、１００ｘ、２００、４００）やＡＩサーバ（例えば、図２３の４００）などの外部機器と有無線信号（例えば、センサ情報、ユーザ入力、学習モデル、制御信号等）を送受信することができる。このために、通信部１１０は、メモリ部１３０内の情報を外部機器に送信し、または外部機器から受信された信号をメモリ部１３０に伝達できる。

[287] 制御部１２０は、データ分析のアルゴリズムまたはマシンラーニングのアルゴリズムを使用して決定されるか、生成された情報に基づいて、ＡＩ機器１００の少なくとも一つの実行可能な動作を決定することができる。また、制御部１２０は、ＡＩ機器１００の構成要素を制御し、決定された動作を行うことができる。例えば、制御部１２０は、ラーニングプロセッサ部１４０ｃまたはメモリ部１３０のデータを要求、検索、受信または活用することができ、少なくとも一つの実行可能な動作中予測される動作や、好ましいと判断される動作を実行するようにＡＩ機器１００の構成要素を制御することができる。また、制御部１２０は、ＡＩ装置１００の動作内容や動作に対するユーザのフィードバックなどを含む履歴情報を収集してメモリ部１３０またはラーニングプロセッサ部１４０ｃに格納するか、ＡＩサーバ４００（図２３）等の外部装置に送信できる。収集された履歴情報は、学習モデルを更新するのに利用されることができる。

[288] メモリ部１３０は、ＡＩ機器１００の様々な機能をサポートするデータを格納することができる。例えば、メモリ部１３０は入力部１４０ａから得たデータ、通信部１１０から得たデータ、ラーニングプロセッサ部１４０ｃの出力データ、及びセンシング部１４０から得たデータを格納することができる。また、メモリ部１３０は、制御部１２０の動作／実行に必要な制御情報及び／またはソフトウェアコードを格納することができる。

[289] 入力部１４０ａは、ＡＩ機器１００の外部から様々な種類のデータを取得することができる。例えば、入力部１４０ａは、モデル学習のための学習データ、及び学習モデルが適用される入力データ等を取得することができる。入力部１４０ａは、カメラ、マイクロフォン、及び／またはユーザ入力部などを含むことができる。出力部１４０ｂは、視覚、聴覚、または触覚等に関する出力を発生させることができる。出力部１４０ｂは、ディスプレイ部、スピーカー、及び／またはハプティックモジュールなどを含むことができる。センシング部１４０は、様々なセンサを用いてＡＩ機器１００の内部情報、ＡＩ機器１００の周辺環境情報、及びユーザ情報のうち少なくとも一つが得られる。センシング部１４０は、近接センサ、照度センサ、加速度センサ、磁気センサ、ジャイロセンサ、慣性センサ、ＲＧＢセンサ、ＩＲセンサ、指紋認識センサ、超音波センサ、光センサ、マイクロフォン、及び／またはレーダー等を含むことができる。

[290] ラーニングプロセッサ部１４０ｃは、学習データを用いて、人工神経網で構成されたモデルを学習させることができる。ラーニングプロセッサ部１４０ｃは、ＡＩサーバ４００（図２３）のラーニングプロセッサ部と共にＡＩプロセシングを行うことができる。ラーニングプロセッサ部１４０ｃは、通信部１１０を介して、外部機器から受信された情報、及び／またはメモリ部１３０に格納された情報を処理することができる。また、ラーニングプロセッサ部１４０ｃの出力値は、通信部１１０を介して外部機器に送信されるか／送信され、メモリ部１３０に格納されることができる。

[291] 本明細書に記載された請求項は、多様な方式に組み合わせ可能である。例えば、本明細書の方法請求項の技術的特徴が組み合わせられて装置で具現されることができ、本明細書の装置請求項の技術的特徴が組み合わせられて方法で具現されることができる。また、本明細書の方法請求項の技術的特徴と装置請求項の技術的特徴が組み合わせられて装置で具現されることができ、本明細書の方法請求項の技術的特徴と装置請求項の技術的特徴が組み合わせられて方法で具現されることができる。

Claims (15)

1. 第１の装置１００がＳＬ ＨＡＲＱ（Ｓｉｄｅｌｉｎｋ Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）フィードバックを送信する方法において、
   ＰＳＳＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）を第２の装置２００から受信するステップ；及び、
   前記ＰＳＳＣＨと関連したＳＬ ＨＡＲＱフィードバックを前記第２の装置２００に送信するステップ；を含み、
   前記ＳＬ ＨＡＲＱフィードバックが送信されるリソースは、前記第１の装置１００のＩＤ（ｉｄｅｎｔｉｆｉｅｒ）に基づいて決定されることを特徴とする方法。
2. 前記第１の装置１００のＩＤは、グループ内でグループキャスト通信を実行する複数の端末のうち前記第１の装置１００を識別するためのＩＤであることを特徴とする請求項１に記載の方法。
3. 前記複数の端末のＩＤは、前記グループ内で互いに異なることを特徴とする請求項２に記載の方法。
4. 前記ＳＬ ＨＡＲＱフィードバックが送信されるリソースは、前記ＰＳＳＣＨと関連したリソースに対する情報に基づいて決定されることを特徴とする請求項１に記載の方法。
5. 前記ＰＳＳＣＨと関連したリソースに対する情報は、前記ＰＳＳＣＨと関連した時間に対する情報または前記ＰＳＳＣＨと関連した周波数に対する情報のうち少なくともいずれか一つを含むことを特徴とする請求項４に記載の方法。
6. ＰＳＣＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）を前記第２の装置２００から受信するステップ；をさらに含み、
   前記ＳＬ ＨＡＲＱフィードバックが送信されるリソースは、前記ＰＳＣＣＨと関連したリソースに対する情報に基づいて決定されることを特徴とする請求項１に記載の方法。
7. 前記ＰＳＣＣＨと関連したリソースに対する情報は、前記ＰＳＣＣＨと関連した時間に対する情報または前記ＰＳＣＣＨと関連した周波数に対する情報のうち少なくともいずれか一つを含むことを特徴とする請求項６に記載の方法。
8. 前記ＰＳＳＣＨと関連したリソースと前記ＳＬ ＨＡＲＱフィードバックが送信されるリソースとの間の時間ギャップ（ｔｉｍｅ ｇａｐ）が前記第１の装置１００及び前記第２の装置２００に対して設定されることを特徴とする請求項１に記載の方法。
9. 前記ＳＬ ＨＡＲＱフィードバックが送信されるリソースは、前記ＰＳＳＣＨと関連した周波数領域に含まれることを特徴とする請求項１に記載の方法。
10. 前記ＰＳＳＣＨ上に含まれているＤＭＲＳに基づいて前記第１の装置１００と前記第２の装置２００との間のチャネル状態を測定するステップ；及び、
    前記チャネル状態に基づいて前記ＳＬ ＨＡＲＱフィードバックの送信電力を決定するステップ；をさらに含むことを特徴とする請求項１に記載の方法。
11. 前記ＳＬ ＨＡＲＱフィードバックの送信電力は、サービスのタイプ、前記サービスの優先順位、ＳＬ通信のタイプ、前記サービスと関連したセッション、前記サービスと関連したＰＰＰＰ（ＰｒｏＳｅ Ｐｅｒ Ｐａｃｋｅｔ Ｐｒｉｏｒｉｔｙ）、前記サービスと関連したＰＰＰＲ（ＰｒｏＳｅ Ｐｅｒ Ｐａｃｋｅｔ Ｒｅｌｉａｂｉｌｉｔｙ）、前記サービスと関連したターゲットＢＬＥＲ（Ｂｌｏｃｋ Ｅｒｒｏｒ Ｒａｔｅ）、前記サービスと関連したターゲットＳＩＮＲ（Ｓｉｇｎａｌ ｔｏ Ｉｎｔｅｒｆｅｒｅｎｃｅ ｐｌｕｓ Ｎｏｉｓｅ Ｒａｔｉｏ）、または前記サービスと関連した遅延バジェット（ｌａｔｅｎｃｙ ｂｕｄｇｅｔ）のうち少なくともいずれか一つに基づいて決定されることを特徴とする請求項１０に記載の方法。
12. 第２の装置２００がＳＬ ＨＡＲＱ（Ｓｉｄｅｌｉｎｋ Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）フィードバックを受信する方法において、
    ＰＳＳＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）をグループ内の複数の端末に送信するステップ；及び、
    前記ＰＳＳＣＨと関連したＳＬ ＨＡＲＱフィードバックを前記複数の端末から受信するステップ；を含み、
    前記ＳＬ ＨＡＲＱフィードバックが受信されるリソースは、前記複数の端末のＩＤ（ｉｄｅｎｔｉｆｉｅｒ）に基づいて決定されることを特徴とする方法。
13. 前記複数の端末のＩＤは、前記グループ内で互いに異なることを特徴とする請求項１２に記載の方法。
14. 前記ＳＬ ＨＡＲＱフィードバックは、互いに異なるリソース上で前記グループ内の複数の端末から受信されることを特徴とする請求項１２に記載の方法。
15. ＳＬ ＨＡＲＱ（Ｓｉｄｅｌｉｎｋ Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）フィードバックを送信する第１の装置１００において、
    一つ以上のメモリ；一つ以上の送受信機；及び、前記一つ以上のメモリと前記一つ以上の送受信機を連結する一つ以上のプロセッサ；を含み、前記プロセッサは、
    ＰＳＳＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）を第２の装置２００から受信するように前記送受信機１０６を制御し、及び
    前記ＰＳＳＣＨと関連したＳＬ ＨＡＲＱフィードバックを前記第２の装置２００に送信するように前記送受信機１０６を制御するように構成され、
    前記ＳＬ ＨＡＲＱフィードバックが送信されるリソースは、前記第１の装置１００のＩＤ（ｉｄｅｎｔｉｆｉｅｒ）に基づいて決定されることを特徴とする第１の装置１００。
    
    

Images