IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ エルジー エレクトロニクス インコーポレイティドの特許一覧

特許7195416NR V2XにおけるサイドリンクHARQフィードバックを送信する方法及び装置
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-12-15
(45)【発行日】2022-12-23
(54)【発明の名称】NR V2XにおけるサイドリンクHARQフィードバックを送信する方法及び装置
(51)【国際特許分類】
   H04W 28/04 20090101AFI20221216BHJP
   H04W 52/18 20090101ALI20221216BHJP
   H04W 72/04 20090101ALI20221216BHJP
   H04W 92/18 20090101ALI20221216BHJP
【FI】
H04W28/04 110
H04W52/18
H04W72/04 136
H04W92/18
【請求項の数】 12
(21)【出願番号】P 2021518093
(86)(22)【出願日】2019-10-02
(65)【公表番号】
(43)【公表日】2022-01-11
(86)【国際出願番号】 KR2019012906
(87)【国際公開番号】W WO2020071783
(87)【国際公開日】2020-04-09
【審査請求日】2021-04-16
(31)【優先権主張番号】62/741,474
(32)【優先日】2018-10-04
(33)【優先権主張国・地域又は機関】US
【前置審査】
(73)【特許権者】
【識別番号】502032105
【氏名又は名称】エルジー エレクトロニクス インコーポレイティド
【氏名又は名称原語表記】LG ELECTRONICS INC.
【住所又は居所原語表記】128, Yeoui-daero, Yeongdeungpo-gu, 07336 Seoul,Republic of Korea
(74)【代理人】
【識別番号】100109841
【弁理士】
【氏名又は名称】堅田 健史
(74)【代理人】
【識別番号】230112025
【弁護士】
【氏名又は名称】小林 英了
(74)【代理人】
【識別番号】230117802
【弁護士】
【氏名又は名称】大野 浩之
(74)【代理人】
【識別番号】100131451
【弁理士】
【氏名又は名称】津田 理
(74)【代理人】
【識別番号】100167933
【弁理士】
【氏名又は名称】松野 知紘
(74)【代理人】
【識別番号】100174137
【弁理士】
【氏名又は名称】酒谷 誠一
(74)【代理人】
【識別番号】100184181
【弁理士】
【氏名又は名称】野本 裕史
(72)【発明者】
【氏名】リ,ソンミン
(72)【発明者】
【氏名】ソ,ハンピョル
【審査官】深津 始
(56)【参考文献】
【文献】国際公開第2020/144787(WO,A1)
【文献】国際公開第2019/064983(WO,A1)
【文献】特表2020-507264(JP,A)
【文献】ITL,Discussion on NR V2X HARQ mechanism[online],3GPP TSG RAN WG1 #94b R1-1811615,2018年09月29日,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_94b/Docs/R1-1811615.zip>
【文献】LG Electronics,Discussion on physical layer procedures for NR sidelink[online],3GPP TSG RAN WG1 #96b R1-1905443,2019年04月03日,Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_96b/Docs/R1-1905443.zip>
(58)【調査した分野】(Int.Cl.,DB名)
H04B 7/24 -H04B 7/26
H04W 4/00 -H04W 99/00
3GPP TSG RAN WG1-4
SA WG1-4
CT WG1、4
(57)【特許請求の範囲】
【請求項1】
第1の装置がSL HARQ(Sidelink Hybrid Automatic Repeat Request)フィードバックを送信する方法において、
第2の装置からPSCCH(Physical Sidelink Control Channel)を受信するステップと、
前記第2の装置から前記PSCCHと関連したPSSCH(Physical Sidelink Shared Channel)を受信するステップと、
前記第1の装置のID(identifier)、および前記第2の装置のソースIDに基づいて、複数のフィードバックリソースのうち前記SL HARQフィードバックの送信と関連したフィードバックリソースを決定するステップであって、前記第1の装置の前記IDが、グループ内でグループキャスト通信を実行する複数の装置のうち前記第1の装置を識別するために、前記グループ内で前記第1の装置に付与されたIDである、ステップと、
前記フィードバックリソースに基づいて前記PSSCHと関連した前記SL HARQフィードバックを前記第2の装置に送信するステップとを含む方法。
【請求項2】
前記グループは、前記第1の装置および前記第2の装置が属するグループである、請求項1に記載の方法。
【請求項3】
前記複数の装置のIDは、前記グループ内で互いに異なる、請求項2に記載の方法。
【請求項4】
前記SL HARQフィードバックの送信と関連した前記フィードバックリソースは、前記PSSCHと関連した前記リソースに関連する、請求項1に記載の方法。
【請求項5】
前記第2の装置の前記ソースIDは、前記第2の装置から受信される、請求項1に記載の方法。
【請求項6】
前記PSSCHと関連したリソースと前記SL HARQフィードバックの送信と関連した前記フィードバックリソースとの間の時間ギャップ(time gap)が前記第1の装置及び前記第2の装置に対して設定される、請求項1に記載の方法。
【請求項7】
前記SL HARQフィードバックの送信と関連した前記フィードバックリソースは、前記PSSCHと関連した周波数領域に含まれる、請求項1に記載の方法。
【請求項8】
前記PSSCH上に含まれているDMRSに基づいて前記第1の装置と前記第2の装置との間のチャネル状態を測定するステップと、
前記チャネル状態に基づいて前記SL HARQフィードバックの送信電力を決定するステップとをさらに含む、請求項1に記載の方法。
【請求項9】
前記SL HARQフィードバックの前記送信電力は、サービスのタイプ、前記サービスと関連した優先順位、SL通信のタイプ、前記サービスと関連したセッション、前記サービスと関連したPPPP(ProSe Per Packet Priority)、前記サービスと関連したPPPR(ProSe Per Packet Reliability)、前記サービスと関連したターゲットBLER(Block Error Rate)、前記サービスと関連したターゲットSINR(Signal to Interference plus Noise Ratio)、および前記サービスと関連した遅延バジェット(latency budget)のうち少なくとも一つに基づいて決定される、請求項に記載の方法。
【請求項10】
第2の装置がSL HARQ(Sidelink Hybrid Automatic Repeat Request)フィードバックを受信する方法において、
PSCCH(Physical Sidelink Control Channel)を第1の装置に送信するステップと、
前記PSCCHと関連したPSSCH(Physical Sidelink Shared Channel)を前記第1の装置に送信するステップと、
前記第1の装置のID(identifier)、および前記第2の装置のソースIDに基づいて、複数のフィードバックリソースのうち前記SL HARQフィードバックの受信と関連したフィードバックリソースを決定するステップであって、前記第1の装置の前記IDが、グループ内でグループキャスト通信を実行する複数の装置のうち前記第1の装置を識別するために、前記グループ内で前記第1の装置に付与されたIDである、ステップと、
前記フィードバックリソースに基づいて前記PSSCHと関連した前記SL HARQフィードバックを前記第1の装置から受信するステップとを含む方法。
【請求項11】
前記複数の装置のIDは、前記グループ内で互いに異なる、請求項10に記載の方法。
【請求項12】
SL HARQ(Sidelink Hybrid Automatic Repeat Request)フィードバックを送信するように構成された第1の装置において、
一つ以上のメモリと、一つ以上の送受信機と、前記一つ以上のメモリと前記一つ以上の送受信機を動作可能に接続する一つ以上のプロセッサとを含み、前記プロセッサは、
第2の装置からPSCCH(Physical Sidelink Control Channel)を受信するように前記一つ以上の送受信機を制御し、
前記第2の装置から前記PSCCHと関連したPSSCH(Physical Sidelink Shared Channel)を受信するように前記一つ以上の送受信機を制御し、
前記第1の装置のID(identifier)、および前記第2の装置のソースIDに基づいて、複数のフィードバックリソースのうち前記SL HARQフィードバックの送信と関連したフィードバックリソースを決定し、前記第1の装置の前記IDが、グループ内でグループキャスト通信を実行する複数の装置のうち前記第1の装置を識別するために、前記グループ内で前記第1の装置に付与されたIDであり、
前記フィードバックリソースに基づいて前記PSSCHと関連した前記SL HARQフィードバックを前記第2の装置に送信するように前記一つ以上の送受信機を制御するように構成される、第1の装置。
【発明の詳細な説明】
【技術分野】
【0001】
[1] 本開示は、無線通信システムに関する。
【背景技術】
【0002】
[2] 移動通信システムは、可用なシステムリソース(例えば、帯域幅、送信パワー等)を共有して多重ユーザとの通信をサポートする多重アクセス(multiple access)システムである。多重アクセスシステムの例としては、CDMA(code division multiple access)システム、FDMA(frequency division multiple access)システム、TDMA(time division multiple access)システム、OFDMA(orthogonal frequency division multiple access)システム、SC-FDMA(single carrier frequency division multiple access)システム、MC-FDMA(multi carrier frequency division multiple access)システム等がある。
【0003】
[3] 一方、無線通信システムではデータの送/受信、システム同期取得、チャネル情報フィードバックなどのためにアップリンクチャネルまたはダウンリンクチャネルを推定する必要がある。無線通信システム環境では多重経路時間遅延によってフェーディングが発生するようになる。フェーディングによる急激な環境変化により発生する信号の歪曲を補償して送信信号を復元する過程をチャネル推定という。また、端末が属するセルまたは他のセルに対するチャネル状態(channel state)を測定する必要がある。チャネル推定またはチャネル状態測定のために、一般的に送受信機が相互間に知っている参照信号(RS;reference signal)を利用してチャネル推定を実行するようになる。
【0004】
[4] 端末は、下記の三つの方法で測定を実行することができる。
【0005】
[5] 1)RSRP(reference signal received power):全帯域にわたって送信されるCRSを運搬する全てのREの平均受信電力を示す。このとき、CRSの代わりにCSI RSを運搬する全てのREの平均受信電力を測定することもできる。
【0006】
[6] 2)RSSI(received signal strength indicator):全体帯域で測定された受信電力を示す。RSSIは、信号、干渉(interference)、熱雑音(thermal noise)を全て含む。
【0007】
[7] 3)RSRQ(reference symbol received quality):CQIを示し、測定帯域幅(bandwidth)またはサブバンドによるRSRP/RSSIに決定されることができる。即ち、RSRQは、信号対雑音干渉比(SINR;signal-to-noise interference ratio)を意味する。RSRPは、十分な移動性(mobility)情報を提供することができないため、ハンドオーバまたはセル再選択(cell reselection)過程ではRSRPの代わりにRSRQが使われることができる。
【0008】
[8] RSRQ=RSSI/RSSPに算出されることができる。または、RSRQ=N*RSSI/RSSに算出されることもできる。ここで、Nは、RSSIを測定する帯域幅に関連した変数(例えば、PRB個数)または関数である。
【0009】
[9] 一方、サイドリンク(sidelink)とは、端末(User Equipment、UE)間に直接的なリンクを設定し、基地局(Base Station、BS)を経ずに、端末間で音声またはデータ等を直接やり取りをする通信方式をいう。サイドリンクは、急速に増加するデータトラフィックによる基地局の負担を解決することができる一つの案として考慮されている。
【0010】
[10] V2X(vehicle-to-everything)は、有/無線通信を介して他の車両、歩行者、インフラが構築されたモノ等と情報を交換する通信技術を意味する。V2Xは、V2V(vehicle-to-vehicle)、V2I(vehicle-to-infrastructure)、V2N(vehicle-to-network)、及びV2P(vehicle-to-pedestrian)のような4つの類型に区分できる。V2X通信は、PC5インターフェース及び/またはUuインターフェースを介して提供されることができる。
【0011】
[11] 一方、より多くの通信機器がより大きな通信容量を要求することになり、これに伴って既存の無線アクセス技術(Radio Access Technology;RAT)に比べて向上したモバイルブロードバンド(mobile broadband)通信に対する必要性が台頭している。これによって、信頼度(reliability)及び遅延(latency)に敏感なサービスまたは端末を考慮した通信システムが議論されているが、改善されたモバイルブロードバンド通信、Massive MTC、URLLC(Ultra-Reliable and Low Latency Communication)等を考慮した次世代の無線アクセス技術を新しいRAT(new radio access technology)またはNR(new radio)と称し得る。NRでも、V2X(vehicle-to-everything)通信がサポートできる。
【発明の概要】
【0012】
[12] 一方、例えば、高い信頼度の要求事項を有するサービスまたは相対的に高い信頼度の要求事項を有するサービスと関連したSL通信の場合、端末のSL HARQフィードバック動作及び/またはメカニズムが有用である。例えば、複数の端末がHARQフィードバック送信を実行する場合、前記HARQフィードバック送信間に衝突が発生できる。これは、サービス遅延に引き継がれることができる。したがって、複数の端末がHARQフィードバック送信を実行する場合、衝突を最小化する方法及びこれをサポートする装置が提案される必要がある。
【0013】
[13] 一実施例において、第1の装置100がSL HARQ(Sidelink Hybrid Automatic Repeat Request)フィードバックを送信する方法が提供される。前記方法は、PSSCH(Physical Sidelink Shared Channel)を第2の装置200から受信するステップ;及び、前記PSSCHと関連したSL HARQフィードバックを前記第2の装置200に送信するステップ;を含み、前記SL HARQフィードバックが送信されるリソースは、前記第1の装置100のID(identifier)に基づいて決定される。
【0014】
[14] 他の実施例において、第2の装置200がSL HARQ(Sidelink Hybrid Automatic Repeat Request)フィードバックを受信する方法が提供される。前記方法は、PSSCH(Physical Sidelink Shared Channel)をグループ内の複数の端末に送信するステップ;及び、前記PSSCHと関連したSL HARQフィードバックを前記複数の端末から受信するステップ;を含み、前記SL HARQフィードバックが受信されるリソースは、前記複数の端末のID(identifier)に基づいて決定される。
【0015】
[15] 他の実施例において、SL HARQ(Sidelink Hybrid Automatic Repeat Request)フィードバックを送信する第1の装置100が提供される。前記第1の装置100は、一つ以上のメモリ;一つ以上の送受信機;及び、前記一つ以上のメモリと前記一つ以上の送受信機を連結する一つ以上のプロセッサ;を含む。前記プロセッサは、PSSCH(Physical Sidelink Shared Channel)を第2の装置200から受信するように前記送受信機106を制御し、及び前記PSSCHと関連したSL HARQフィードバックを前記第2の装置200に送信するように前記送受信機106を制御するように構成され、前記SL HARQフィードバックが送信されるリソースは、前記第1の装置100のID(identifier)に基づいて決定される。
【0016】
[16] 端末がSL通信を効率的に実行することができる。
【図面の簡単な説明】
【0017】
図1】[17] 図1は、本開示の一実施例に係る、LTEシステムの構造を示す。
図2】[18] 図2は、本開示の一実施例に係る、ユーザ平面(user plane)に対する無線プロトコル構造(radio protocol architecture)を示す。
図3】[19] 図3は、本開示の一実施例に係る、制御平面(control plane)に対する無線プロトコル構造(radio protocol architecture)を示す。
図4】[20] 図4は、本開示の一実施例に係る、NRシステムの構造を示す。
図5】[21] 図5は、本開示の一実施例に係る、NG-RANと5GCとの間の機能的分割を示す。
図6】[22] 図6は、本開示の一実施例に係る、NRの無線フレームの構造を示す。
図7】[23] 図7は、本開示の一実施例に係る、NRフレームのスロット構造を示す。
図8】[24] 図8は、本開示の一実施例に係る、BWPの一例を示す。
図9】[25] 図9は、本開示の一実施例に係る、SL通信のための無線プロトコル構造(radio protocol architecture)を示す。
図10】[26] 図10は、本開示の一実施例に係る、SL通信のための無線プロトコル構造(radio protocol architecture)を示す。
図11】[27] 図11は、本開示の一実施例に係る、V2XまたはSL通信を実行する端末を示す。
図12】[28] 図12は、本開示の一実施例に係る、V2XまたはSL通信のためのリソース単位を示す。
図13】[29] 図13は、本開示の一実施例によって、端末がTM(Transmission Mode)によってV2XまたはSL通信を実行する手順を示す。
図14】[30] 図14は、本開示の一実施例によって、端末が送信リソースを選択する方法を示す。
図15】[31] 図15は、本開示の一実施例に係る、三つのキャストタイプを示す。
図16】[32] 図16は、本開示の一実施例によって、端末がHARQフィードバックを送受信する手順を示す。
図17】[33] 図17は、本開示の一実施例に係るHARQフィードバックリソースを示す。
図18】[34] 図18は、本開示の一実施例によって、グループキャストSL通信で、端末がHARQフィードバックを送受信する手順を示す。
図19】[35] 図19は、本開示の一実施例によって、端末がHARQフィードバックを送受信する手順を示す。
図20】[36] 図20は、本開示の一実施例によって、端末がHARQフィードバックを送受信する手順を示す。
図21】[37] 図21は、本開示の一実施例によって、第1の装置100がSL HARQフィードバックを送信する手順を示す。
図22】[38] 図22は、本開示の一実施例によって、第2の装置200がSL HARQフィードバックを受信する手順を示す。
図23】[39] 図23は、本開示の一実施例に係る、通信システム1を示す。
図24】[40] 図24は、本開示の一実施例に係る、無線機器を示す。
図25】[41] 図25は、本開示の一実施例に係る、送信信号のための信号処理回路を示す。
図26】[42] 図26は、本開示の一実施例に係る、無線機器を示す。
図27】[43] 図27は、本開示の一実施例に係る、携帯機器を示す。
図28】[44] 図28は、本開示の一実施例に係る、車両または自律走行車両を示す。
図29】[45] 図29は、本開示の一実施例に係る、車両を示す。
図30】[46] 図30は、本開示の一実施例に係る、XR機器を示す。
図31】[47] 図31は、本開示の一実施例に係る、ロボットを示す。
図32】[48] 図32は、本開示の一実施例に係る、AI機器を示す。
【発明を実施するための形態】
【0018】
[49] 本開示の多様な実施例において、“/”及び“、”は“及び/または”を意味すると解釈されなければならない。例えば、“A/B”は“A及び/またはB”を意味することができる。なお、“A、B”は“A及び/またはB”を意味することができる。また、“A/B/C”は“A、B及び/またはCのうち少なくともいずれか一つ”を意味することができる。また、“A、B、C”は“A、B及び/またはCのうち少なくともいずれか一つ”を意味することができる。
【0019】
[50] さらに、本開示の多様な実施例において、“または”は“及び/または”を意味すると解釈されなければならない。例えば、“AまたはB”は“ただA”、“ただB”、及び/または“A及びBの両方とも”を含むことができる。即ち、本開示の多様な実施例において、“または”は“付加的にまたは代案として”を意味すると解釈されなければならない。
【0020】
[51] 以下の技術は、CDMA(code division multiple access)、FDMA(frequency division multiple access)、TDMA(time division multiple access)、OFDMA(orthogonal frequency division multiple access)、SC-FDMA(single carrier frequency division multiple access)などの様々な無線通信システムに使用されることができる。CDMAは、UTRA(universal terrestrial radio access)やCDMA2000のような無線技術で実現されることができる。TDMAは、GSM(global system for mobile communications)/GPRS(general packet radio service)/EDGE(enhanced data rates for GSM evolution)のような無線技術で実現されることができる。OFDMAは、IEEE(institute of electrical and electronics engineers) 802.11(Wi-Fi)、IEEE 802.16(WiMAX)、IEEE 802-20、E-UTRA(evolved UTRA)などの無線技術で実現されることができる。IEEE 802.16mはIEEE 802.16eの進化であって、IEEE 802.16eに基づくシステムとの下位互換性(backward compatibility)を提供する。UTRAは、UMTS(universal mobile telecommunications system)の一部である。3GPP(3rd generation partnership project)LTE(long term evolution)は、E-UTRA(evolved-UMTS terrestrial radio access)を使用するE-UMTS(evolved UMTS)の一部であって、ダウンリンクでOFDMAを採用し、アップリンクでSC-FDMAを採用する。LTE-A(advanced)は3GPP LTEの進化である。
【0021】
[52] 5G NRはLTE-Aの後続技術であって、高性能、低遅延、高可用性などの特性を有する新しいClean-slateの形態の移動通信システムである。5G NRは、1GHz未満の低周波帯域から1GHz~10GHzの中間周波帯域、24GHz以上の高周波(ミリ波)帯域などの使用可能な全てのスペクトルリソースを活用することができる。
【0022】
[53] 説明を明確にするために、LTE-Aまたは5G NRを中心に記述するが、本開示の技術的思想がこれに制限されるものではない。
【0023】
[54] 図1は、本開示の一実施例に係る、LTEシステムの構造を示す。これはE-UTRAN(Evolved-UMTS Terrestrial Radio Access Network)、またはLTE(Long Term Evolution)/LTE-Aシステムと呼ばれることができる。
【0024】
[55] 図1を参照すると、E-UTRANは、端末10にコントロールプレーン(control plane)とユーザプレーン(user plane)を提供する基地局20(Base Station、BS)を含む。端末10は、固定されるか移動性を有することができ、MS(Mobile Station)、UT(User Terminal)、SS(Subscriber Station)、MT(Mobile Terminal)、無線機器(Wireless Device)など他の用語で呼ばれ得る。基地局20は、端末10と通信する固定された地点(fixed station)を言い、eNB(evolved-NodeB)、BTS(Base Transceiver System)、アクセスポイント(Access Point)など他の用語で呼ばれ得る。
【0025】
[56] 基地局20は、S1インターフェースを介して互いに連結されることができる。基地局20は、S1インターフェースを介して、EPC30(Evolved Packet Core)、より詳細には、S1-MMEを介してMME(Mobility Management Entity)と、S1-Uを介してS-GW(Serving Gateway)と連結される。
【0026】
[57] EPC30は、MME、S-GW、及びP-GW(Packet Data Network-Gateway)から構成される。MMEは、端末のアクセス情報や、端末の能力に関する情報を有しており、このような情報は、端末の移動性管理に主に使用される。S-GWは、E-UTRANを終端点として有するゲートウェイであり、P-GWは、PDN(Packet Data Network)を終端点として有するゲートウェイである。
【0027】
[58] 端末ネットワークとの無線インターフェースプロトコル(Radio Interface Protocol)の層は、通信システムで広く知られている開放型システム間相互接続(Open System Interconnection、OSI)の基準モデルの下位3層に基づいて、L1(第1層)、L2(第2層)、L3(第3層)に区分されることができる。このうち、第1層に属する物理層は、物理チャネル(Physical Channel)を用いた情報伝送サービス(Information Transfer Service)を提供し、第3層に位置するRRC(Radio Resource Control)層は、端末とネットワークとの間に無線リソースを制御する役割をする。このために、RRC層は端末と基地局間にRRCメッセージを交換する。
【0028】
[59] 図2は、本開示の一実施例に係る、ユーザ平面(user plane)に対する無線プロトコル構造(radio protocol architecture)を示す。図3は、本開示の一実施例に係る、制御平面(control plane)に対する無線プロトコル構造(radio protocol architecture)を示す。ユーザ平面は、ユーザデータ送信のためのプロトコルスタック(protocol stack)であり、制御平面は、制御信号送信のためのプロトコルスタックである。
【0029】
[60] 図2及び図3を参照すると、物理層(physical layer)は、物理チャネルを用いて上位層に情報伝送サービスを提供する。物理層は、上位層であるMAC(Medium Access Control)層とは送信チャネル(transport channel)を介して連結されている。送信チャネルを介してMAC層と物理層との間にデータが移動する。送信チャネルは、無線インターフェースを介して、データがどのようにどんな特徴で送信されるかに応じて分類される。
【0030】
[61] 互いに異なる物理層間、即ち、送信機と受信機の物理層間は物理チャネルを介してデータが移動する。前記物理チャネルは、OFDM(Orthogonal Frequency Division Multiplexing)方式で変調されることができ、時間と周波数を無線リソースとして活用する。
【0031】
[62] MAC層は、論理チャネル(logical channel)を介して上位層であるRLC(radio link control)層にサービスを提供する。MAC層は、複数の論理チャネルから複数の送信チャネルへのマッピング機能を提供する。また、MAC層は、複数の論理チャネルから単数の送信チャネルへのマッピングによる論理チャネルの多重化機能を提供する。MAC副層は、論理チャネル上のデータ伝送サービスを提供する。
【0032】
[63] RLC層は、RLC SDU(Radio Link Control Service Data Unit)の連結(concatenation)、分割(segmentation)、及び再結合(reassembly)を行う。無線ベアラー(Radio Bearer、RB)が要求する様々なQoS(Quality of Service)を保証するために、RLC層は、透明モード(Transparent Mode、TM)、非確認モード(Unacknowledged Mode、UM)、及び確認モード(Acknowledged Mode、AM)の三つの動作モードを提供する。AM RLCはARQ(automatic repeat request)を介してエラー訂正を提供する。
【0033】
[64] RRC(Radio Resource Control)層は、コントロールプレーンでのみ定義される。RRC層は、無線ベアラーの設定(configuration)、再設定(re-configuration)、及び解除(release)に関して、論理チャネル、送信チャネル、及び物理チャネルの制御を担当する。RBは、端末とネットワーク間のデータ伝達のために、第1層(PHY層)及び第2層(MAC層、RLC層、PDCP(Packet Data Convergence Protocol)層)によって提供される論理的経路を意味する。
【0034】
[65] ユーザプレーンでのPDCP層の機能は、ユーザデータの伝達、ヘッダ圧縮(header compression)、及び暗号化(ciphering)を含む。コントロールプレーンでのPDCP層の機能は、コントロールプレーンデータの伝達及び暗号化/整合性保護(integrity protection)を含む。
【0035】
[66] RBが設定されるというのは、特定のサービスを提供するために、無線プロトコル層及びチャネルの特性を規定し、各々の具体的なパラメータ及び動作方法を設定する過程を意味する。RBは、再度SRB(Signaling Radio Bearer)とDRB(Data Radio Bearer)の二つに分けられる。SRBは、コントロールプレーンでRRCメッセージを送信する通路として使用され、DRBは、ユーザプレーンでユーザデータを送信する通路として使用される。
【0036】
[67] 端末のRRC層とE-UTRANのRRC層との間にRRC接続(RRC Connection)が確立すると、端末はRRC_CONNEDTEDの状態にあることになり、そうでない場合、RRC_IDLEの状態にあることになる。NRの場合、RRC_INACTIVEの状態がさらに定義され、RRC_INACTIVEの状態の端末は、コアネットワークとの連結を維持する反面、基地局との連結を解除(release)することができる。
【0037】
[68] ネットワークから端末へデータを送信するダウンリンク送信チャネルとしては、システム情報を送信するBCH(Broadcast Channel)と、それ以外にユーザトラフィックや制御メッセージを送信するダウンリンクSCH(Shared Channel)とがある。ダウンリンクマルチキャストまたはブロードキャストサービスのトラフィックまたは制御メッセージの場合、ダウンリンクSCHを介して送信されてもよく、または別途のダウンリンクMCH(Multicast Channel)を介して送信されてもよい。一方、端末からネットワークへデータを送信するアップリンク送信チャネルとしては、初期の制御メッセージを送信するRACH(Random Access Channel)と、それ以外にユーザトラフィックや制御メッセージを送信するアップリンクSCH(Shared Channel)とがある。
【0038】
[69] 送信チャネルの上位にあり、送信チャネルにマッピングされる論理チャネル(Logical Channel)としては、BCCH(Broadcast Control Channel)、PCCH(Paging Control Channel)、CCCH(Common Control Channel)、MCCH(Multicast Control Channel)、MTCH(Multicast Traffic Channel)等がある。
【0039】
[70] 物理チャネル(Physical Channel)は、時間領域で多数個のOFDMシンボルと周波数領域で多数個の副搬送波(Sub-carrier)から構成される。一つのサブフレーム(sub-frame)は、時間領域で複数のOFDMシンボル(symbol)から構成される。リソースブロックは、リソース割り当ての単位であって、複数のOFDMシンボルと複数の副搬送波(sub-carrier)から構成される。また、各サブフレームは、PDCCH(Physical Downlink Control Channel)、即ち、L1/L2制御チャネルのために該当サブフレームの特定のOFDMシンボル(例えば、一番目のOFDMシンボル)の特定の副搬送波を用いることができる。TTI(Transmission Time Interval)は、サブフレーム送信の単位時間である。
【0040】
[71] 図4は、本開示の一実施例に係る、NRシステムの構造を示す。
【0041】
[72] 図4を参照すると、NG-RAN(Next Generation-Radio Access Network)は、端末にユーザプレーン及びコントロールプレーンのプロトコル終端(termination)を提供するgNB(next generation-Node B)及び/またはeNBを含むことができる。図4では、gNBのみを含む場合を例示する。gNB及びeNBは、相互間にXnインターフェースで連結されている。gNB及びeNBは、5世代コアネットワーク(5G Core Network:5GC)とNGインターフェースを介して連結されている。より具体的に、AMF(access and mobility management function)とはNG-Cインターフェースを介して連結され、UPF(user plane function)とはNG-Uインターフェースを介して連結される。
【0042】
[73] 図5は、本開示の一実施例に係る、NG-RANと5GCとの間の機能的分割を示す。
【0043】
[74] 図5を参照すると、gNBは、インターセル間の無線リソース管理(Inter Cell RRM)、無線ベアラー管理(RB control)、連結移動性制御(Connection Mobility Control)、無線許可制御(Radio Admission Control)、測定設定及び提供(Measurement configuration & Provision)、動的リソース割り当て(dynamic resource allocation)等の機能を提供することができる。AMFは、NAS(Non Access Stratum)セキュリティ、アイドル状態の移動性処理等の機能を提供することができる。UPFは、移動性アンカーリング(Mobility Anchoring)、PDU(Protocol Data Unit)処理等の機能を提供することができる。SMF(Session Management Function)は、端末IP(Internet Protocol)アドレスの割り当て、PDUセッション制御等の機能を提供することができる。
【0044】
[75] 図6は、本開示の一実施例に係る、NRの無線フレームの構造を示す。
【0045】
[76] 図6を参照すると、NRでアップリンク及びダウンリンクの送信のために無線フレームが使用できる。無線フレームは、10msの長さを有し、2個の5msのハーフ-フレーム(Half-Frame、HF)で定義され得る。ハーフ-フレームは、5個の1msのサブフレーム(Subframe、SF)を含むことができる。サブフレームは、一つ以上のスロットに分割されることができ、サブフレーム内のスロットの数は、副搬送波間隔(Subcarrier Spacing、SCS)に応じて決定されることができる。各スロットは、CP(cyclic prefix)に応じて、12個または14個のOFDM(A)シンボルを含むことができる。
【0046】
[77] ノーマルCP(normal CP)が使用される場合、各スロットは14個のシンボルを含むことができる。拡張CPが使用される場合、各スロットは、12個のシンボルを含むことができる。ここで、シンボルは、OFDMシンボル(または、CP-OFDMシンボル)、SC-FDMA(Single Carrier-FDMA)シンボル(または、DFT-s-OFDM(Discrete Fourier Transform-spread-OFDM)シンボル)を含むことができる。
【0047】
[78] 以下の表1は、ノーマルCPが使用される場合、SCS設定(u)に応じて、スロット別シンボルの数(Nslot symb)、フレーム別スロットの数(Nframe,u slot)と、サブフレーム別スロットの数(Nsubframe,u slot)を例示する。
【0048】
[79]
【表1】
【0049】
[80] 表2は、拡張CPが使用される場合、SCSに応じて、スロット別シンボルの数、フレーム別スロットの数とサブフレーム別スロットの数を例示する。
【0050】
[81]
【表2】
【0051】
[82] NRシステムでは、一つの端末に併合される複数のセル間にOFDM(A)ヌメロロジー(numerology)(例えば、SCS、CP長さなど)が異なって設定できる。これによって、同じ数のシンボルで構成された時間リソース(例えば、サブフレーム、スロットまたはTTI)(便宜上、TU(Time Unit)と通称)の(絶対時間)区間が併合されたセル間に異なって設定できる。
【0052】
[83] NRにおいて、多様な5Gサービスをサポートするための多数のヌメロロジー(numerology)またはSCSがサポートされることができる。例えば、SCSが15kHzである場合、伝統的なセルラーバンドでの広い領域(wide area)がサポートされることができ、SCSが30kHz/60kHzである場合、密集した-都市(dense-urban)、より低い遅延(lower latency)、及びより広いキャリア帯域幅(wider carrier bandwidth)がサポートされることができる。SCSが60kHzまたはそれより高い場合、位相雑音(phase noise)を克服するために24.25GHzより大きい帯域幅がサポートされることができる。
【0053】
[84] NR周波数バンド(frequency band)は、二つのタイプの周波数範囲(frequency range)に定義されることができる。前記二つのタイプの周波数範囲は、FR1及びFR2である。周波数範囲の数値は、変更されることができ、例えば、前記二つのタイプの周波数範囲は、以下の表3の通りである。NRシステムで使われる周波数範囲のうち、FR1は“sub 6GHz range”を意味することができ、FR2は“above 6GHz range”を意味することができ、ミリ波(millimeter wave、mmW)と呼ばれることができる。
【0054】
[85]
【表3】
【0055】
[86] 前述したように、NRシステムの周波数範囲の数値は、変更されることができる。例えば、FR1は、以下の表4のように410MHz乃至7125MHzの帯域を含むことができる。即ち、FR1は、6GHz(または、5850、5900、5925MHz等)以上の周波数帯域を含むことができる。例えば、FR1内で含まれる6GHz(または、5850、5900、5925MHz等)以上の周波数帯域は、非免許帯域(unlicensed band)を含むことができる。非免許帯域は、多様な用途で使われることができ、例えば、車両のための通信(例えば、自律走行)のために使われることができる。
【0056】
[87]
【表4】
【0057】
[88] 図7は、本開示の一実施例に係る、NRフレームのスロット構造を示す。
【0058】
[89] 図7を参照すると、スロットは、時間領域で複数のシンボルを含む。例えば、ノーマルCPの場合、一つのスロットが14個のシンボルを含むが、拡張CPの場合、一つのスロットが12個のシンボルを含むことができる。或いは、ノーマルCPの場合、一つのスロットが7個のシンボルを含むが、拡張CPの場合、一つのスロットが6個のシンボルを含むことができる。
【0059】
[90] 搬送波は、周波数領域で複数の副搬送波を含む。RB(Resource Block)は周波数領域で複数(例えば、12)の連続した副搬送波で定義され得る。BWP(Bandwidth Part)は、周波数領域で複数の連続した(P)RB((Physical) Resource Block)で定義され得、一つのヌメロロジー(numerology)(例えば、SCS、CP長さなど)に対応し得る。搬送波は、最大N個(例えば、5個)のBWPを含むことができる。データ通信は、活性化されたBWPを介して行われることができる。各々の要素は、リソースグリッドでリソース要素(Resource Element、RE)と称され得、一つの複素シンボルがマッピングできる。
【0060】
[91] 以下、BWP(Bandwidth Part)及びキャリアに対して説明する。
【0061】
[92] BWP(Bandwidth Part)は、与えられたヌメロロジーでPRB(physical resource block)の連続的な集合である。PRBは、与えられたキャリア上で与えられたヌメロロジーに対するCRB(common resource block)の連続的な部分集合から選択されることができる。
【0062】
[93] BA(Bandwidth Adaptation)を使用すると、端末の受信帯域幅及び送信帯域幅は、セルの帯域幅ほど大きい必要がないし、端末の受信帯域幅及び送信帯域幅は、調整されることができる。例えば、ネットワーク/基地局は、帯域幅調整を端末に知らせることができる。例えば、端末は、帯域幅調整のための情報/設定をネットワーク/基地局から受信することができる。この場合、端末は、前記受信された情報/設定に基づいて帯域幅調整を実行することができる。例えば、前記帯域幅調整は、帯域幅の縮小/拡大、帯域幅の位置変更または帯域幅のサブキャリアスペーシングの変更を含むことができる。
【0063】
[94] 例えば、帯域幅は、パワーをセイブするために活動が少ない期間の間に縮小されることができる。例えば、帯域幅の位置は、周波数ドメインで移動できる。例えば、帯域幅の位置は、スケジューリング柔軟性(scheduling flexibility)を増加させるために周波数ドメインで移動できる。例えば、帯域幅のサブキャリアスペーシング(subcarrier spacing)は、変更されることができる。例えば、帯域幅のサブキャリアスペーシングは、異なるサービスを許容するために変更されることができる。セルの総セル帯域幅のサブセットは、BWP(Bandwidth Part)と称することができる。BAは、基地局/ネットワークが端末にBWPを設定し、基地局/ネットワークが設定されたBWPのうち現在活性状態であるBWPを端末に知らせることによって実行されることができる。
【0064】
[95] 例えば、BWPは、活性(active)BWP、イニシャル(initial)BWP及び/またはデフォルト(default)BWPのうち少なくともいずれか一つである。例えば、端末は、PCell(primary cell)上の活性(active)DL BWP以外のDL BWPでダウンリンク無線リンク品質(downlink radio link quality)をモニタリングしない。例えば、端末は、活性DL BWPの外部でPDCCH、PDSCHまたはCSI-RS(ただし、RRM除外)を受信しない。例えば、端末は、非活性DL BWPに対するCSI(Channel State Information)報告をトリガしない。例えば、端末は、活性UL BWP外部でPUCCHまたはPUSCHを送信しない。例えば、ダウンリンクの場合、イニシャルBWPは、(PBCHにより設定された)RMSI CORESETに対する連続的なRBセットで与えられることができる。例えば、アップリンクの場合、イニシャルBWPは、ランダムアクセス手順のためにSIBにより与えられることができる。例えば、デフォルトBWPは、上位階層により設定されることができる。例えば、デフォルトBWPの初期値は、イニシャルDL BWPである。エネルギーセイビングのために、端末が一定期間の間にDCIを検出することができない場合、端末は、前記端末の活性BWPをデフォルトBWPにスイッチングできる。
【0065】
[96] 一方、BWPは、SLに対して定義されることができる。同じSL BWPは、送信及び受信に使われることができる。例えば、送信端末は、特定BWP上でSLチャネルまたはSL信号を送信することができ、受信端末は、前記特定BWP上でSLチャネルまたはSL信号を受信することができる。免許キャリア(licensed carrier)で、SL BWPは、Uu BWPと別途に定義されることができ、SL BWPは、Uu BWPと別途の設定シグナリング(separate configuration signalling)を有することができる。例えば、端末は、SL BWPのための設定を基地局/ネットワークから受信することができる。SL BWPは、キャリア内でout-of-coverage NR V2X端末及びRRC_IDLE端末に対して(あらかじめ)設定されることができる。RRC_CONNECTEDモードの端末に対して、少なくとも一つのSL BWPがキャリア内で活性化されることができる。
【0066】
[97] 図8は、本開示の一実施例に係る、BWPの一例を示す。図8の実施例において、BWPは、3個と仮定する。
【0067】
[98] 図8を参照すると、CRB(common resource block)は、キャリアバンドの一側端から他側端まで番号が付けられたキャリアリソースブロックである。そして、PRBは、各BWP内で番号が付けられたリソースブロックである。ポイントAは、リソースブロックグリッド(resource block grid)に対する共通参照ポイント(common reference point)を指示することができる。
【0068】
[99] BWPは、ポイントA、ポイントAからのオフセット(Nstart BWP)及び帯域幅(Nsize BWP)により設定されることができる。例えば、ポイントAは、全てのヌメロロジー(例えば、該当キャリアでネットワークによりサポートされる全てのヌメロロジー)のサブキャリア0が整列されるキャリアのPRBの外部参照ポイントである。例えば、オフセットは、与えられたヌメロロジーで最も低いサブキャリアとポイントAとの間のPRB間隔である。例えば、帯域幅は、与えられたヌメロロジーでPRBの変調である。
【0069】
[100] 以下、V2XまたはSL通信に対して説明する。
【0070】
[101] 図9は、本開示の一実施例に係る、SL通信のための無線プロトコル構造(radio protocol architecture)を示す。具体的に、図9の(a)は、LTEのユーザ平面プロトコルスタックを示し、図9の(b)は、LTEの制御平面プロトコルスタックを示す。
【0071】
[102] 図10は、本開示の一実施例に係る、SL通信のための無線プロトコル構造(radio protocol architecture)を示す。具体的に、図10の(a)は、NRのユーザ平面プロトコルスタックを示し、図10の(b)は、NRの制御平面プロトコルスタックを示す。
【0072】
[103] 以下、サイドリンク同期信号(Sidelink Synchronization Signal、SLSS)及び同期化情報について説明する。
【0073】
[104] SLSSは、サイドリンク特定的なシーケンス(sequence)であって、PSSS(Primary Sidelink Synchronization Signal)とSSSS(Secondary Sidelink Synchronization Signal)とを含むことができる。前記PSSSは、S-PSS(Sidelink Primary Synchronization Signal)と称してもよく、前記SSSSは、S-SSS(Sidelink Secondary Synchronization Signal)と称してもよい。
【0074】
[105] PSBCH(Physical Sidelink Broadcast Channel)は、サイドリンク信号の送受信前に端末が真っ先に知るべきである基本になる(システム)情報が送信される(放送)チャネルであり得る。例えば、基本になる情報は、SLSSに関する情報、デュプレックスモード(Duplex Mode、DM)、TDD UL/DL(Time Division Duplex Uplink/Downlink)の構成、リソースプールに関する情報、SLSSに関するアプリケーションの種類、サブフレームオフセット、放送情報などであり得る。
【0075】
[106] S-PSS、S-SSS、及びPSBCHは周期的送信をサポートするブロックフォーマット(例えば、サイドリンクSS(Synchronization Signal)/PSBCHブロック、以下S-SSB)に含まれ得る。前記S-SSB(Sidelink-Synchronization Signal Block)は、キャリア内のPSCCH(Physical Sidelink Control Channel)/PSSCH(Physical Sidelink Shared Channel)と同じヌメロロジー(即ち、SCS及びCP長さ)を有することができ、送信帯域幅は、(予め)設定されたSL BWP(Sidelink Bandwidth Part)内にあり得る。また、S-SSBの周波数位置は、(予め)設定されることができる。したがって、端末はキャリアでS-SSBを見つけるために周波数で仮設検出(hypothesis detection)を行う必要がない。
【0076】
[107] 各SLSSは、物理層のサイドリンク同期化ID(identity)を有してもよく、その値は0から335のうち何れか一つであってもよい。前記値のうちいずれの値を使用するかに応じて、同期化ソースが識別されることもある。例えば、0、168、169はGNSS(global navigation satellite systems)を意味してもよく、1乃至167は基地局を意味してもよく、170乃至335はカバレッジの外部であることを意味してもよい。或いは、物理層のサイドリンク同期化ID(identity)の値のうち、0乃至167はネットワークによって使用される値であってもよく、168乃至335はネットワークのカバレッジの外部で使用される値であってもよい。
【0077】
[108] 図11は、本開示の一実施例に係る、V2XまたはSL通信を実行する端末を示す。
【0078】
[109] 図11を参照すると、V2X/サイドリンク通信における端末という用語は、主にユーザの端末を意味することができる。しかしながら、基地局のようなネットワーク装備が端末間の通信方式に応じて信号を送受信する場合、基地局もまた一種の端末と見なされることもできる。
【0079】
[110] 端末1は、一連のリソースの集合を意味するリソースプール(resource pool)内で特定のリソースに該当するリソース単位(resource unit)を選択し、該当リソース単位を使用してサイドリンク信号を送信するように動作することができる。受信端末である端末2は、端末1が信号を送信することができるリソースプールが設定され、該当リソースプール内で端末1の信号を検出することができる。
【0080】
[111] ここで、端末1が基地局の連結範囲内にある場合、基地局がリソースプールを知らせることができる。これに対して、端末1が基地局の連結範囲外にある場合、他の端末がリソースプールを知らせるか、または事前に決められたリソースで決定されることもできる。
【0081】
[112] 一般に、リソースプールは、複数のリソース単位で構成されることができ、各端末は一つまたは複数のリソース単位を選定し、自分のサイドリンク信号の送信に使用することができる。
【0082】
[113] 図12は、本開示の一実施例に係る、V2XまたはSL通信のためのリソース単位を示す。
【0083】
[114] 図12を参照すると、リソースプールの全周波数リソースがN個に分割でき、リソースプールの全時間リソースがN個に分割できる。従って、計N*N個のリソース単位がリソースプール内で定義され得る。図12は、該当リソースプールがN個のサブフレームの周期に繰り返される場合の例を示す。
【0084】
[115] 図12に示すように、一つのリソース単位(例えば、Unit #0)は、周期的に繰り返して表され得る。或いは、時間または周波数次元でのダイバーシティ(diversity)効果を得るために、一つの論理的なリソース単位がマッピングされる物理的リソース単位のインデックスが時間に応じて事前に決められたパターンに変化することもできる。このようなリソース単位の構造において、リソースプールとは、サイドリンク信号を送信しようとする端末が送信に使用することができるリソース単位の集合を意味することができる。
【0085】
[116] リソースプールは、様々な種類に細分化できる。例えば、各リソースプールで送信されるサイドリンク信号のコンテンツ(content)に応じて、リソースプールは下記のように区分できる。
【0086】
[117] (1)スケジューリング割り当て(Scheduling Assignment、SA)は、送信端末がサイドリンクデータチャネルの送信として使用するリソースの位置、その他にデータチャネルの復調のために必要なMCS(Modulation and Coding Scheme)またはMIMO(Multiple Input Multiple Output)送信方式、TA(Timing Advance)などの情報を含む信号であり得る。SAは、同じリソース単位上でサイドリンクデータと共にマルチプレクシングされて送信されることも可能であり、この場合、SAリソースプールとは、SAがサイドリンクデータとマルチプレクシングされて送信されるリソースプールを意味することができる。SAは、サイドリンク制御チャネル(control channel)とも呼ばれ得る。
【0087】
[118] (2)サイドリンクデータチャネル(Physical Sidelink Shared Channel、PSSCH)は、送信端末がユーザデータを送信するのに使用するリソースプールであり得る。もし、同じリソース単位上でサイドリンクデータと共にSAがマルチプレクシングされて送信される場合、SA情報を除いた形態のサイドリンクデータチャネルのみがサイドリンクデータチャネルのためのリソースプールで送信されることができる。言い換えると、SAリソースプール内の個別のリソース単位上でSA情報を送信するのに使用されたREs(Resource Elements)は、サイドリンクデータチャネルのリソースプールで依然としてサイドリンクデータを送信するために使用されることができる。
【0088】
[119] (3)ディスカバリーチャネルは、送信端末が自分のIDなどの情報を送信するためのリソースプールであり得る。これを介して、送信端末は隣接端末が自分を見つけるようにすることができる。
【0089】
[120] 以上で説明したサイドリンク信号のコンテンツが同一である場合にも、サイドリンク信号の送受信属性に応じて、異なるリソースプールを使用することができる。一例として、同じサイドリンクデータチャネルやディスカバリーメッセージであっても、サイドリンク信号の送信タイミング決定方式(例えば、同期基準信号の受信時点で送信されるか、それとも前記受信時点で一定のタイミングアドバンスを適用して送信されるか)、リソース割り当て方式(例えば、個別信号の送信リソースを基地局が個別送信端末に指定するか、それとも個別送信端末がリソースプール内で自体的に個別信号の送信リソースを選択するか)、信号フォーマット(例えば、各サイドリンク信号が一つのサブフレームで占めるシンボルの数、または一つのサイドリンク信号の送信に使用されるサブフレームの数)、基地局からの信号強度、サイドリンク端末の送信電力強度等に応じて、再度異なるリソースプールに区分されることもできる。
【0090】
[121] 以下、サイドリンクにおけるリソース割り当て(resource allocation)について説明する。
【0091】
[122] 図13は、本開示の一実施例によって、端末がTM(Transmission Mode)によってV2XまたはSL通信を実行する手順を示す。具体的に、図13の(a)は、送信モード1または送信モード3と関連した端末動作を示し、図13の(b)は、送信モード2または送信モード4と関連した端末動作を示す。
【0092】
[123] 図13の(a)を参照すると、送信モード1/3で、基地局は端末1にPDCCH(より具体的にDCI(Downlink Control Information))を介してリソーススケジューリングを行い、端末1は、該当リソーススケジューリングによって端末2とサイドリンク/V2X通信を行う。端末1は端末2にPSCCH(physical sidelink control channel)を介してSCI(sidelink control information)を送信した後、前記SCIに基づくデータをPSSCH(physical sidelink shared channel)を介して送信することができる。LTEサイドリンクの場合、送信モード1は一般的なサイドリンク通信に適用されることができ、送信モード3はV2Xのサイドリンク通信に適用されることができる。
【0093】
[124] 図13の(b)を参照すると、送信モード2/4で、端末は自分でリソースをスケジューリングすることができる。より具体的に、LTEサイドリンクの場合、送信モード2は、一般的なサイドリンク通信に適用され、端末が設定されたリソースプール内でリソースを自分で選択してサイドリンク動作を行うことができる。送信モード4は、V2Xのサイドリンク通信に適用され、端末がセンシング/SAデコーディング過程などを経て、選択ウィンドウ内で自分でリソースを選択した後、V2Xのサイドリンク動作を行うことができる。端末1は端末2にPSCCHを介してSCIを送信した後、前記SCIに基づくデータをPSSCHを介して送信することができる。以下、送信モードをモードと略称してもよい。
【0094】
[125] NRのサイドリンクの場合、少なくとも二つのサイドリンクのリソース割り当てモードが定義され得る。モード1の場合、基地局はサイドリンク送信のために端末により使用されるサイドリンクリソースをスケジューリングすることができる。モード2の場合、端末は基地局/ネットワークにより設定されたサイドリンクリソースまたは予め設定されたサイドリンクリソース内でサイドリンク送信リソースを決定することができる。前記設定されたサイドリンクリソースまたは予め設定されたサイドリンクリソースは、リソース/リソースプールであり得る。例えば、モード2の場合、端末は自律的に送信のためのサイドリンクリソースを選択することができる。例えば、モード2の場合、端末は他の端末に対するサイドリンクリソースの選択を助けることができる。例えば、モード2の場合、端末はサイドリンク送信のためのNR configured grantの設定を受けることができる。例えば、モード2の場合、端末は他の端末のサイドリンク送信をスケジューリングすることができる。また、モード2は少なくともブラインド再送信のためのサイドリンクリソースの予約をサポートすることができる。
【0095】
[126] センシング(sensing)及びリソースの(再)選択に関する手続は、リソース割り当てモード2でサポートされることができる。前記センシング手続は、他の端末及び/またはサイドリンクの測定からSCIをデコーディングすると定義され得る。前記センシング手続でSCIをデコーディングすることは、少なくともSCIを送信する端末により指示されるサイドリンクリソースに対する情報を提供することができる。該当SCIがデコーディングされる際、前記センシング手続はSL DMRS(Demodulation Reference Signal)に基づくL1 SL RSRP(Reference Signal Received Power)測定を使用することができる。前記リソースの(再)選択手続はサイドリンク送信のためのリソースを決定するために、前記センシング手続の結果を使用することができる。
【0096】
[127] 図14は、本開示の一実施例によって、端末が送信リソースを選択する方法を示す。
【0097】
[128] 図14を参照すると、端末はセンシングウィンドウ内でセンシングを介して他の端末が予約した送信リソースまたは他の端末が使用しているリソースを把握することができ、選択ウィンドウ内でこれを排除した後、残っているリソースのうち、干渉の少ないリソースからランダムにリソースを選択することができる。
【0098】
[129] 例えば、端末は、センシングウィンドウ内で、予約されたリソースの周期に対する情報を含むPSCCHをデコーディングし、前記PSCCHに基づいて周期的に決定されたリソースでPSSCH RSRPを測定することができる。端末は、前記PSSCH RSRP値が閾値を超えるリソースを選択ウィンドウ内から除外することができる。その後、端末は選択ウィンドウ内の残っているリソースのうちからサイドリンクリソースをランダムに選択することができる。
【0099】
[130] 或いは、端末はセンシングウィンドウ内で周期的なリソースのRSSI(Received signal strength indication)を測定し、干渉の少ないリソース(例えば、下位20%に該当するリソース)を決定することができる。また、端末は前記周期的なリソースのうち、選択ウィンドウに含まれているリソースのうちからサイドリンクリソースをランダムに選択することもできる。例えば、端末がPSCCHのデコーディングを失敗した場合、端末は前記のような方法を使用することができる。
【0100】
[131] 図15は、本開示の一実施例に係る、三つのキャストタイプを示す。
【0101】
[132] 具体的に、図15の(a)は、ブロードキャスト(broadcast)タイプのSL通信を示し、図15の(b)は、ユニキャスト(unicast)タイプのSL通信を示し、図15の(c)は、グループキャスト(groupcast)タイプのSL通信を示す。ユニキャストタイプのSL通信の場合、端末は、他の端末と一対一通信を実行することができる。グループキャストタイプのSL通信の場合、端末は、自分が属するグループ内の一つ以上の端末とSL通信を実行することができる。本開示の多様な実施例において、SLグループキャスト通信は、SLマルチキャスト(multicast)通信、SL一対多(one-to-many)通信などに代替されることができる。
【0102】
[133] 以下、SLでHARQ(Hybrid Automatic Repeat Request)手順に対して説明する。
【0103】
[134] SLユニキャスト及びグループキャストの場合、物理階層でのHARQフィードバック及びHARQコンバイニング(combining)がサポートされることができる。例えば、受信端末がリソース割当モード1または2で動作する場合、受信端末は、PSSCHを送信端末から受信することができ、PSFCH(Physical Sidelink Feedback Channel)を介してSFCI(Sidelink Feedback Control Information)フォーマットを使用してPSSCHに対するHARQフィードバックを送信端末に送信できる。
【0104】
[135] 例えば、SL HARQフィードバックは、ユニキャストに対してイネイブルされることができる。このとき、non-CBG(non-Code Block Group)動作で、受信端末が前記受信端末をターゲットとするPSCCHをデコーディングし、及び前記PSCCHと関連した送信ブロックを成功的にデコーディングする場合、受信端末は、HARQ-ACKを生成することができる。そして、受信端末は、HARQ-ACKを送信端末に送信できる。それに対して、受信端末が前記受信端末をターゲットとするPSCCHをデコーディングした以後、前記PSCCHと関連した送信ブロックを成功的にデコーディングできない場合、受信端末は、HARQ-NACKを生成することができる。そして、受信端末は、HARQ-NACKを送信端末に送信できる。
【0105】
[136] 例えば、SL HARQフィードバックは、グループキャストに対してイネイブルされることができる。例えば、non-CBG動作で、二つのHARQフィードバックオプションがグループキャストに対してサポートされることができる。
【0106】
[137] (1)グループキャストオプション1:受信端末が前記受信端末をターゲットとするPSCCHをデコーディングした以後、前記PSCCHと関連した送信ブロックのデコーディングに失敗する場合、受信端末は、HARQ-NACKをPSFCHを介して送信端末に送信できる。それに対して、受信端末が前記受信端末をターゲットとするPSCCHをデコーディングし、及び前記PSCCHと関連した送信ブロックを成功的にデコーディングする場合、受信端末は、HARQ-ACKを送信端末に送信しない。
【0107】
[138] (2)グループキャストオプション2:受信端末が前記受信端末をターゲットとするPSCCHをデコーディングした以後、前記PSCCHと関連した送信ブロックのデコーディングに失敗する場合、受信端末は、HARQ-NACKをPSFCHを介して送信端末に送信できる。そして、受信端末が前記受信端末をターゲットとするPSCCHをデコーディングし、及び前記PSCCHと関連した送信ブロックを成功的にデコーディングする場合、受信端末は、HARQ-ACKをPSFCHを介して送信端末に送信できる。
【0108】
[139] 一方、例えば、高い信頼度の要求事項を有するサービスまたは相対的に高い信頼度の要求事項を有するサービスと関連したSL通信の場合、端末のSL HARQフィードバック動作及び/またはメカニズムが有用である。例えば、高い信頼度の要求事項を有するサービスと関連したSL通信の場合、前記サービスを受信した端末が前記サービスを送信した端末にSL HARQフィードバックを送信する動作が前記高い信頼度の要求事項を満たすときに有用である。
【0109】
[140] 以下、本開示の多様な実施例によって、端末がSL HARQフィードバック送信と関連したリソースまたは送信電力を決定する方法及びこれをサポートする装置に対して説明する。本開示の多様な実施例において、SL通信は、V2X通信を含むことができる。
【0110】
[141] 本開示の多様な実施例によって提案された少なくとも一つの提案方式は、ユニキャスト通信、グループキャスト通信及び/またはブロードキャスト通信のうち少なくともいずれか一つに、適用されることができる。
【0111】
[142] 本開示の多様な実施例によって提案された少なくとも一つの提案方式は、PC5インターフェースまたはSLインターフェース(例えば、PSCCH、PSSCH、PSBCH、PSSS/SSSS等)ベースのSL通信またはV2X通信だけでなく、Uuインターフェース(例えば、PUSCH、PDSCH、PDCCH、PUCCH等)ベースのSL通信またはV2X通信にも、適用されることができる。
【0112】
[143] 本開示の多様な実施例において、端末の受信動作は、SLチャネル及び/またはSL信号(例えば、PSCCH、PSSCH、PSFCH、PSBCH、PSSS/SSSS等)のデコーディング動作及び/または受信動作を含むことができる。端末の受信動作は、WAN DLチャネル及び/またはWAN DL信号(例えば、PDCCH、PDSCH、PSS/SSS等)のデコーディング動作及び/または受信動作を含むことができる。端末の受信動作は、センシング動作及び/またはCBR測定動作を含むことができる。本開示の多様な実施例において、端末のセンシング動作は、PSSCH DM-RSシーケンスベースのPSSCH-RSRP測定動作、端末が成功的にデコーディングしたPSCCHによりスケジューリングされるPSSCH DM-RSシーケンスベースのPSSCH-RSRP測定動作、S-RSSI(sidelink RSSI)測定動作、及び/またはV2Xリソースプール関連サブチャネルベースのS-RSSI測定動作を含むことができる。本開示の多様な実施例において、端末の送信動作は、SLチャネル及び/またはSL信号(例えば、PSCCH、PSSCH、PSFCH、PSBCH、PSSS/SSSS等)の送信動作を含むことができる。端末の送信動作は、WAN ULチャネル及び/またはWAN UL信号(例えば、PUSCH、PUCCH、SRS等)の送信動作を含むことができる。本開示の多様な実施例において、同期信号は、SLSS及び/またはPSBCHを含むことができる。
【0113】
[144] 本開示の多様な実施例において、設定は、シグナリング、ネットワークからのシグナリング、ネットワークからの設定、及び/またはネットワークからあらかじめ設定を含むことができる。本開示の多様な実施例において、定義は、シグナリング、ネットワークからのシグナリング、ネットワークからの設定、及び/またはネットワークからあらかじめ設定を含むことができる。本開示の多様な実施例において、指定は、シグナリング、ネットワークからのシグナリング、ネットワークからの設定、及び/またはネットワークからあらかじめ設定を含むことができる。
【0114】
[145] 本開示の多様な実施例において、PPPP(ProSe Per Packet Priority)はPPPR(ProSe Per Packet Reliability)に代替されることができ、PPPRはPPPPに代替されることができる。例えば、PPPP値が小さいほど高い優先順位を意味することができ、PPPP値が大きいほど低い優先順位を意味することができる。例えば、PPPR値が小さいほど高い信頼性を意味することができ、PPPR値が大きいほど低い信頼性を意味することができる。例えば、高い優先順位と関連したサービス、パケットまたはメッセージと関連したPPPP値は、低い優先順位と関連したサービス、パケットまたはメッセージと関連したPPPP値より小さい。例えば、高い信頼性と関連したサービス、パケットまたはメッセージと関連したPPPR値は、低い信頼性と関連したサービス、パケットまたはメッセージと関連したPPPR値より小さい。
【0115】
[146] 本開示の多様な実施例において、セッション(session)は、ユニキャストセッション(例えば、SLのためのユニキャストセッション)、グループキャスト/マルチキャストセッション(例えば、SLのためのグループキャスト/マルチキャストセッション)、及び/またはブロードキャストセッション(例えば、SLのためのブロードキャストセッション)のうち少なくともいずれか一つを含むことができる。
【0116】
[147] 本開示の多様な実施例において、キャリアは、BWP及び/またはリソースプールのうち少なくともいずれか一つとして相互拡張解釈されることができる。例えば、キャリアは、BWP及び/またはリソースプールのうち少なくともいずれか一つを含むことができる。例えば、キャリアは、一つ以上のBWPを含むことができる。例えば、BWPは、一つ以上のリソースプールを含むことができる。
【0117】
[148] 本開示の多様な実施例において、HARQフィードバックリソースは、HARQフィードバック送信リソース及び/またはHARQフィードバック受信リソースを含むことができる。例えば、前記HARQフィードバック送信リソースは、HARQフィードバックの送信のためのリソース及び/またはHARQフィードバックの送信と関連したリソースを含むことができる。例えば、前記HARQフィードバック受信リソースは、HARQフィードバックの受信のためのリソース及び/またはHARQフィードバックの受信と関連したリソースを含むことができる。
【0118】
[149] 本開示の多様な実施例において、PSSCHリソースは、PSSCH送信リソース及び/またはPSSCH受信リソースを含むことができる。例えば、前記PSSCH送信リソースは、PSSCHの送信のためのリソース及び/またはPSSCHの送信と関連したリソースを含むことができる。例えば、前記PSSCH受信リソースは、PSSCHの受信のためのリソース及び/またはPSSCHの受信と関連したリソースを含むことができる。
【0119】
[150] 本開示の多様な実施例において、PSCCHリソースは、PSCCH送信リソース及び/またはPSSCH受信リソースを含むことができる。例えば、前記PSCCH送信リソースは、PSCCHの送信のためのリソース及び/またはPSCCHの送信と関連したリソースを含むことができる。例えば、前記PSCCH受信リソースは、PSCCHの受信のためのリソース及び/またはPSCCHの受信と関連したリソースを含むことができる。
【0120】
[151] 本開示の多様な実施例において、前記リソースは、時間領域リソース(time domain resource)、周波数領域リソース(frequency domain resource)、及び/またはコード領域リソース(code domain resource)のうち少なくともいずれか一つを含むことができる。
【0121】
[152] 例えば、リソース衝突が端末のPSSCH送信、PSCCH送信及び/またはHARQフィードバック送信のうち少なくともいずれか一つで発行する場合、端末のSL HARQフィードバック手順及び/または動作は、正しく動作しにくい。例えば、リソース衝突が端末のPSSCH送信、PSCCH送信及び/またはHARQフィードバック送信のうち少なくともいずれか一つで発行する場合、端末の全般的なSL HARQフィードバック手順及び/または動作は、正確に実行しにくい。
【0122】
[153] 例えば、受信端末がPSSCHを成功的に受信したが、リソース衝突によってHARQフィードバック(例えば、HARQ ACK)上にエラーが発生された場合、送信端末は、不必要に受信端末に前記PSSCHを再送信しなければならない。例えば、受信端末がPSSCHの受信に失敗し、及びHARQフィードバックがリソース衝突によって送信端末に伝達されることができない場合、SL通信関連信頼度または性能が低下されることができる。例えば、受信端末が送信端末から送信されたPSCCH及び/またはPSSCHの受信に失敗し、かつPSCCH及び/またはPSSCHに対応するHARQ NACKがリソース衝突によって送信端末に正しく伝達されることができない場合、SL通信関連信頼度または性能が低下されることができる。したがって、HARQフィードバックリソースは、複数の端末間で衝突されないようにまたは衝突を最小化するように決定される必要がある。
【0123】
[154] 図16は、本開示の一実施例によって、端末がHARQフィードバックを送受信する手順を示す。図16の実施例は、本開示の多様な実施例と結合されることができる。
【0124】
[155] 図16を参照すると、ステップS1610において、送信端末は、PSCCH及び/またはPSSCHを受信端末に送信できる。例えば、送信端末は、PSCCHリソース及び/またはPSSCHリソースを利用してSL情報を受信端末に送信できる。例えば、前記SL情報は、SL制御情報、SLデータ、SLパケット、SL TB(Transport Block)、SLメッセージ及び/またはSLサービスのうち少なくともいずれか一つを含むことができる。
【0125】
[156] ステップS1620において、受信端末は、HARQフィードバックリソースを決定することができる。付加的に、例えば、送信端末は、HARQフィードバックリソースを決定することができる。
【0126】
[157] 例えば、前記HARQフィードバックリソースは、前記PSSCHと連関関係またはリンケージを有するように設定されることができる。例えば、前記HARQフィードバックリソースは、時間領域リソース(time domain resource)、周波数領域リソース(frequency domain resource)、及び/またはコード領域リソース(code domain resource)のうち少なくともいずれか一つを含むことができる。例えば、前記HARQフィードバックリソースの位置は、連動されたPSSCHリソースと連関関係またはリンケージを有するように設定されることができる。例えば、前記HARQフィードバックリソースの位置は、連動されたPSSCHリソースの位置と事前に定義された関数に基づいて連関関係またはリンケージを有するように設定されることができる。例えば、前記HARQフィードバックリソースは、前記PSSCHと関連した時間領域に対する情報、前記PSSCHと関連した周波数領域に対する情報、及び/または前記PSSCHと関連したコード領域に対する情報のうち少なくともいずれか一つに基づいて決定されることができる。
【0127】
[158] そして/または、例えば、前記HARQフィードバックリソースは、前記PSCCHと連関関係またはリンケージを有するように設定されることができる。例えば、前記HARQフィードバックリソースの位置は、連動されたPSCCHリソースと連関関係またはリンケージを有するように設定されることができる。例えば、前記HARQフィードバックリソースの位置は、連動されたPSCCHリソースの位置と事前に定義された関数に基づいて連関関係またはリンケージを有するように設定されることができる。例えば、前記HARQフィードバックリソースは、前記PSCCHと関連した時間領域に対する情報、前記PSCCHと関連した周波数領域に対する情報、及び/または前記PSCCHと関連したコード領域に対する情報のうち少なくともいずれか一つに基づいて決定されることができる。
【0128】
[159] 例えば、前記HARQフィードバックリソースは、PSSCH送信及び/またはPSCCH送信に使われる周波数リソースの部分集合(subset)形態で設定されることができる。例えば、前記HARQフィードバックリソースの周波数領域は、連動されたPSSCHリソース及び/またはPSCCHリソースの周波数領域の部分集合形態で設定されることができる。例えば、前記HARQフィードバックリソースの周波数領域は、PSSCHリソース及び/またはPSCCHリソースの周波数領域に含まれることができる。
【0129】
[160] 図17は、本開示の一実施例に係るHARQフィードバックリソースを示す。図17の実施例は、本開示の多様な実施例と結合されることができる。
【0130】
[161] 図17を参照すると、送信端末は、4個のサブチャネルを介してPSCCH及び/またはPSSCHを受信端末に送信できる。この場合、前記PSCCH及び/またはPSSCHと関連したHARQフィードバックリソースの周波数領域は、送信端末がPSCCH及び/またはPSSCHを送信するために使用する周波数リソースの部分集合である。
【0131】
[162] 本開示の一実施例によると、HARQフィードバックリソースとPSSCHリソースとの間の時間ギャップ(time gap)が設定されることができる。そして/または、例えば、HARQフィードバックリソースとPSCCHリソースとの間の時間ギャップ(time gap)が設定されることができる。例えば、端末のデコーディング能力(decoding capability)及び/または遅延要求事項(例えば、V2Xメッセージ及び/またはサービス関連遅延要求事項)などを考慮し、時間ギャップが受信端末のPSSCH及び/またはPSCCH受信時点と前記受信端末のHARQフィードバック送信時点との間に設定されることができる。例えば、端末のデコーディング能力及び/または遅延要求事項などを考慮し、時間ギャップが送信端末のHARQフィードバック受信時点と前記送信端末のPSSCH及び/またはPSCCH(再)送信時点との間に設定されることができる。
【0132】
[163] 例えば、前記時間ギャップは、リソースプール内で共通的に設定されることができる。例えば、前記時間ギャップは、リソースプール内で異なる端末間に共通的に設定されることができる。例えば、前記時間ギャップは、前記送信端末及び前記受信端末に共通的に設定されることができる。したがって、端末は、HARQフィードバックリソースを簡単に決定できる。例えば、前記時間ギャップは、リソースプール特定的に設定されることができる。
【0133】
[164] 例えば、前記時間ギャップは、リソースプール上に共存するサービスの遅延バジェット(latency budget)のうち、最も小さい値より小さい及び/または同一に設定または指定されることができる。例えば、サービスA及びサービスBがリソースプール上に共存し、かつサービスAの遅延バジェットがサービスBの遅延バジェットより小さい場合、前記時間ギャップは、前記サービスAの遅延バジェットより小さいまたは同じ値に設定または指定されることができる。
【0134】
[165] 例えば、リソースプール、サービスのタイプ、サービスの優先順位、キャストのタイプ、及び/またはサービスのQoS要求事項特定的に設定されたTB(Transport Block)関連最大再送信回数がリソースプール上の(関連)サービスに対して遅延バジェット内で(全て)サポート/実行されることができるように、前記時間ギャップが指定されることができる。例えば、前記最大再送信回数は、初期送信を含む最大許容再送信回数である。
【0135】
[166] 例えば、前記時間ギャップは、端末のデコーディング能力のうち、最も大きい値より大きい及び/または同一に設定または指定されることができる。ここで、例えば、前記デコーディング能力は、前記端末のPSSCH受信終了/終わり時点から前記端末のPSFCH送信開始時点まで必要な端末のプロセシング時間である。そして/または、例えば、前記デコーディング能力は、前記端末のPSCCH受信終了/終わり時点から前記端末のPSFCH送信開始時点まで必要な端末のプロセシング時間である。例えば、前記時間ギャップは、リソースプール内の端末のデコーディング能力の中で、最も大きい値より大きい及び/または同一に設定または指定されることができる。例えば、端末A、端末B、及び端末Cがリソースプール内でSL通信を実行し、かつ端末Aのデコーディング能力が最もよくない場合、前記時間ギャップは、端末AのPSSCH及び/またはPSCCH受信終了/終わり時点から端末AのPSFCH送信開始時点まで要求されるプロセシング時間より大きいまたは同じ値に設定または指定されることができる。
【0136】
[167] 例えば、前記時間ギャップは、サービスのタイプ、サービスの優先順位、SL通信のタイプ、サービスと関連したセッション、サービスと関連したPPPP、サービスと関連したPPPR、サービスと関連したターゲットBLER(Block Error Rate)、サービスと関連したターゲットSINR(Signal to Interference plus Noise Ratio)、サービスと関連した遅延バジェット、及び/または端末能力別に異なるようにまたは独立的に設定されることができる。例えば、前記時間ギャップは、リソースプール内でサービスのタイプ、サービスの優先順位、SL通信のタイプ、サービスと関連したセッション、サービスと関連したPPPP、サービスと関連したPPPR、サービスと関連したターゲットBLER、サービスと関連したターゲットSINR、サービスと関連した遅延バジェット、及び/または端末能力別に異なるようにまたは独立的に設定されることができる。例えば、前記SL通信のタイプは、ユニキャスト、グループキャスト及び/またはブロードキャストのうち少なくともいずれか一つを含むことができる。
【0137】
[168] 再び、図16を参照すると、ステップS1630において、受信端末は、HARQフィードバックを送信端末に送信できる。例えば、受信端末は、前記PSCCH及び/またはPSSCHに対応するHARQフィードバックを送信端末に送信できる。例えば、受信端末は、前記PSCCHリソース及び/またはPSSCHリソースに基づいて決定されたHARQフィードバックリソースを利用して前記HARQフィードバックを送信端末に送信できる。例えば、送信端末は、前記PSCCHリソース及び/またはPSSCHリソースに基づいて決定されたHARQフィードバックリソース上でHARQフィードバックを受信端末から受信することができる。
【0138】
[169] 例えば、受信端末がPSCCH及び/またはPSSCHを成功的に受信した場合、前記HARQフィードバックは、HARQ ACKである。例えば、受信端末がPSCCH及び/またはPSSCHを受信することに失敗した場合、前記HARQフィードバックは、HARQ NACK及び/またはDTX(discontinuous detection)のうち少なくともいずれか一つである。
【0139】
[170] 本発明の一実施例によると、グループ内の複数の端末が互いにSL通信を実行するグループキャストの場合、HARQフィードバックリソースは、二つの形態で具現されることができる。
【0140】
[171] (1)オプションA:共通的なHARQフィードバックリソースが受信端末間に設定されることができる。例えば、送信端末がPSSCH及び/またはPSCCHを複数の受信端末に送信した場合、HARQフィードバックリソースは、前記PSSCH及び/またはPSCCHを受信した複数の受信端末に対して共通的に設定されることができる。
【0141】
[172] (2)オプションB:互いに異なるまたは独立的なHARQフィードバックリソースが受信端末間に設定されることができる。例えば、各々の受信端末別にまたは一つ以上の受信端末を含むサブグループ別に、互いに異なるまたは独立的なHARQフィードバックリソースが設定されることができる。例えば、送信端末がPSSCH及び/またはPSCCHを複数の受信端末に送信した場合、互いに異なるまたは独立的なHARQフィードバックリソースが前記PSSCH及び/またはPSCCHを受信した複数の受信端末または複数のサブグループに対して各々設定されることができる。
【0142】
[173] 例えば、オプションAは、前記グループキャストオプション1に対してのみ限定的に適用されることができる。例えば、グループキャストオプション1で、複数の受信端末は、PSCCH及び/またはPSSCHの受信に失敗した場合にのみ、複数の受信端末に対して共通的に設定されたHARQフィードバックリソースを利用してHARQ NACKを送信端末に送信できる。例えば、前記HARQ NACKは、SFN(Single Frequency Network)形態で具現されることができる。この場合、送信端末は、複数の受信端末により送信されたHARQ NACKを分離して受信することができない。したがって、送信端末は、どの受信端末がHARQ NACKを送信したかを知ることができない。しかしながら、送信端末は、複数の受信端末のうち少なくとも一つの受信端末がHARQ NACKを送信したことを知ることができ、送信端末は、PSCCH及び/またはPSSCHを複数の受信端末に再送信できる。
【0143】
[174] 例えば、オプションAの場合、ユニキャスト関連HARQフィードバックリソース構造が再利用されることができる。そして/または、例えば、オプションAの場合、HARQフィードバックリソースと関連したオーバーヘッドが減少されることができる。それに対して、オプションAの場合、送信端末がDTXを判別/認知することができないという限界がある。例えば、送信端末がPSSCH及び/またはPSCCHを受信端末に送信した場合、受信端末は、PSSCHをスケジューリングするPSCCHの受信に失敗できる。この場合、オプションAによると、前記受信端末は、HARQ NACKを送信端末に送信しない。したがって、送信端末は、前記受信端末がPSSCHを成功的に受信したと誤認する問題が発生できる。
【0144】
[175] 例えば、オプションBの場合、複数の受信端末を含むグループ内で、互いに異なるまたは独立的なHARQフィードバックリソースが受信端末別にまたはサブグループ別に割り当てられることができる。ここで、例えば、オプションBによると、前記グループに含まれている受信端末の個数またはサブグループの個数が多くなるほど、より多い量のHARQフィードバックリソースが要求されることができる。例えば、N個の受信端末を含むグループの場合、N-1個のHARQフィードバックリソースが要求されることができる。例えば、オプションBは、前記グループキャストオプション2に対してのみ限定的に適用されることができる。
【0145】
[176] 図18は、本開示の一実施例によって、グループキャストSL通信で、端末がHARQフィードバックを送受信する手順を示す。図18の実施例は、本開示の多様な実施例と結合されることができる。
【0146】
[177] 図18の実施例において、N個の端末がグループ内に含まれると仮定する。例えば、前記グループは、グループキャストSL通信と関連したグループである。例えば、図18の実施例は、前記オプションBに対して適用されることができる。例えば、図18の実施例は、前記グループキャストオプション2に対して適用されることができる。
【0147】
[178] 図18を参照すると、ステップS1810において、送信端末は、PSCCH及び/またはPSSCHをグループ内の複数の受信端末に送信できる。例えば、送信端末は、PSCCHリソース及び/またはPSSCHリソースを利用してSL情報をグループ内の複数の受信端末に送信できる。例えば、前記SL情報は、SL制御情報、SLデータ、SLパケット、SL TB(Transport Block)、SLメッセージ及び/またはSLサービスのうち少なくともいずれか一つを含むことができる。
【0148】
[179] ステップS1820において、複数の受信端末は、HARQフィードバックリソースを決定することができる。付加的に、例えば、送信端末は、HARQフィードバックリソースを決定することができる。
【0149】
[180] 例えば、前記グループが生成される場合、前記グループ内部で使われる識別子(以下、GUE_ID)が端末別に割り当てられることができる。例えば、前記グループが生成される場合、GUE_IDがサブグループ別に割り当てられることができる。例えば、GUE_IDは、特定端末が生成してグループ内の端末に伝達できる。例えば、前記特定端末は、GO(Group Owner)端末である。例えば、GUE_IDは、ネットワークまたは基地局から設定され、または事前に設定されることができる。例えば、GUE_IDは、端末に対してあらかじめ定義されることができる。例えば、GUE_IDは、前記グループ内の複数の端末に対して異なるように割り当てられることができる。例えば、GUE_IDは、前記グループ内の複数のサブグループに対して異なるように割り当てられることができる。
【0150】
[181] 例えば、複数の受信端末は、自分のGUE_IDに基づいてHARQフィードバックリソースを各々決定することができる。例えば、受信端末1は、自分に割り当てられたGUE_IDを利用してHARQフィードバックリソースを決定することができ、受信端末2は、自分に割り当てられたGUE_IDを利用してHARQフィードバックリソースを決定することができ、受信端末N-1は、自分に割り当てられたGUE_IDを利用してHARQフィードバックリソースを決定することができる。したがって、HARQフィードバックリソースは、グループ内の複数の受信端末に対して異なるように決定されることができる。
【0151】
[182] 例えば、送信端末を除いた残りの端末(例えば、受信端末)は、複数のHARQフィードバックリソース(例えば、N-1個のHARQフィードバックリソース)をGUE_IDの昇順によって順次に使用することができる。例えば、送信端末を除いた残りの端末(例えば、受信端末)は、複数のHARQフィードバックリソース(例えば、N-1個のHARQフィードバックリソース)をGUE_IDの降順によって順次に使用することができる。例えば、送信端末を除いた残りの端末(例えば、受信端末)は、複数のHARQフィードバックリソース(例えば、N-1個のHARQフィードバックリソース)を事前に設定された関数/規則に基づいて導出されたGUE_IDの順序によって順次に使用することができる。例えば、前記複数のHARQフィードバックリソースは、事前に設定されることができる。例えば、前記送信端末は、PSSCH及び/またはPSCCHを複数の受信端末に送信した端末である。
【0152】
[183] 例えば、送信端末を除いた残りのサブグループは、複数のHARQフィードバックリソースをGUE_IDの昇順によって順次に使用することができる。例えば、送信端末を除いた残りのサブグループは、複数のHARQフィードバックリソースをGUE_IDの降順によって順次に使用することができる。例えば、送信端末を除いた残りのサブグループは、複数のHARQフィードバックリソースを事前に設定された関数/規則に基づいて導出されたGUE_IDの順序によって順次に使用することができる。例えば、前記複数のHARQフィードバックリソースは、事前に設定されることができる。例えば、前記送信端末は、PSSCH及び/またはPSCCHを複数の受信端末に送信した端末である。
【0153】
[184] ステップS1830において、複数の受信端末は、HARQフィードバックを送信端末に各々送信できる。例えば、複数の受信端末は、前記PSCCH及び/またはPSSCHに対応するHARQフィードバックを送信端末に各々送信できる。例えば、複数の受信端末は、前記PSCCHリソース及び/またはPSSCHリソースに基づいて決定されたHARQフィードバックリソースを利用して前記HARQフィードバックを送信端末に各々送信できる。
【0154】
[185] 例えば、受信端末がPSCCH及び/またはPSSCHを成功的に受信した場合、前記HARQフィードバックはHARQ ACKである。例えば、受信端末がPSCCH及び/またはPSSCHを受信することに失敗した場合、前記HARQフィードバックは、HARQ NACK及び/またはDTX(discontinuous detection)のうち少なくともいずれか一つである。
【0155】
[186] 本開示の一実施例によると、HARQ RTT(Round Trip Time)を減少させるために、HARQフィードバックリソースがグループ内の端末間でまたはサブグループ間でFDMされることができる。ここで、例えば、受信端末からHARQフィードバックを受信する送信端末の観点で、帯域内の放射(in-band emission)によるNear-Far問題を緩和させるために、HARQフィードバック送信と関連した電力制御が必要である。例えば、受信端末からHARQフィードバックを受信するPSSCH及び/またはPSCCH送信端末の観点で、帯域内の放射(in-band emission)によるNear-Far問題を緩和させるために、受信端末に対するHARQフィードバック送信と関連した電力制御が必要である。
【0156】
[187] 本開示の一実施例によると、端末は、SLチャネル上の参照信号に基づいて導出/取得されたSL経路損失値、SLチャネル上の参照信号に基づいて導出/取得されたSL RSRP値、SLチャネル上の参照信号に基づいて導出/取得されたSL RSRQ値、開ループ電力制御パラメータ、及び/または閉ループ電力制御パラメータのうち少なくともいずれか一つに基づいてHARQフィードバック送信電力を決定することができる。例えば、送信端末が参照信号をSLチャネルを介して受信端末に送信する場合、受信端末は、SLチャネル上の参照信号に基づいて導出/取得されたSL経路損失値、SLチャネル上の参照信号に基づいて導出/取得されたSL RSRP値、SLチャネル上の参照信号に基づいて導出/取得されたSL RSRQ値、開ループ電力制御パラメータ、及び/または閉ループ電力制御パラメータのうち少なくともいずれか一つに基づいてHARQフィードバック送信電力を決定することができる。
【0157】
[188] 例えば、前記SLチャネル上の参照信号は、事前に定義されることができる。例えば、前記SLチャネル上の参照信号は、PSSCH上で送信されるDMRS(即ち、PSSCH DMRS)またはPSCCH上で送信されるDMRS(即ち、PSCCH DMRS)である。例えば、前記SLチャネル上の参照信号は、PSSCH上で送信されるCSI-RSである。例えば、前記SLチャネル上の参照信号は、SLチャネルの品質推定(例えば、CQI、PMI、RI)に使われる参照信号である。例えば、前記SLチャネル上の参照信号は、SL経路損失値、SL RSRP値及び/またはSL RSRQ値のうち少なくともいずれか一つの測定に使われる参照信号である。
【0158】
[189] 例えば、前記SL経路損失は、送信端末と受信端末との間のリンクに対する経路損失である。例えば、開ループ電力制御パラメータ及び/または閉ループ電力制御パラメータは、事前に設定されることができる。例えば、開ループ電力制御パラメータは、Po及び/またはアルファ値を含むことができる。
【0159】
[190] 例えば、Poは、パケット/メッセージ送信関連ターゲットエラー率(例えば、BLER(Block Error Rate)、FER(Frame Error Rate))を平均的に満たすための電力制御パラメータである。そして/または、例えば、Poは、送信端末と受信端末との間の平均受信SINRと関連した電力制御パラメータである。例えば、Poは、端末、リソースプール、サービスのタイプ、サービスの優先順位、サービスと関連したQoS要求事項、SL送信に使われる(周波数)リソース大きさ、SL送信に使われるMCS値、リソースプール関連混雑レベル(例、CBR)、及び/またはキャストのタイプに特定的な電力制御パラメータである。例えば、HARQフィードバック送信電力がSL RSRP及び/またはSL RSRQ値/範囲に基づいて計算/導出される場合、(事前に設定された)SL RSRP及び/またはSL RSRQ値/範囲別に異なるPo値/範囲がマッピング/設定されることができる。
【0160】
[191] 例えば、HARQフィードバック送信電力がSL経路損失に基づいて導出/計算される時、アルファ値は、(測定された)経路損失補償に適用される加重値である。そして/または、例えば、HARQフィードバック送信電力がSL RSRP及び/またはSL RSRQ値/範囲に基づいて計算/導出される時、アルファ値は、(測定された)SL RSRP及び/またはSL RSRQ値/範囲に適用される加重値である。そして/または、例えば、HARQフィードバック送信電力がSL RSRP及び/またはSL RSRQ値/範囲に基づいて計算/導出される時、アルファ値は、(測定された)SL RSRP及び/またはSL RSRQ値/範囲別にマッピング/設定されたHARQフィードバック送信電力に適用される加重値である。ここで、例えば、アルファ値/範囲は、端末、リソースプール、サービスのタイプ、サービスの優先順位、サービスと関連したQoS要求事項、SL送信に使われる(周波数)リソース大きさ、SL送信に使われるMCS値、リソースプール関連混雑レベル(例、CBR)、及び/またはキャストのタイプに特定的に設定されることができる。例えば、HARQフィードバック送信電力がSL RSRP及び/またはSL RSRQ値/範囲に基づいて計算/導出される場合、(事前に設定された)SL RSRP及び/またはSL RSRQ値/範囲別に異なるアルファ値/範囲がマッピング/設定されることができる。
【0161】
[192] 例えば、HARQフィードバック送信電力がSL RSRP及び/またはSL RSRQ値/範囲に基づいて計算/導出される場合、(事前に設定された)SL RSRP及び/またはSL RSRQ値/範囲別に異なるオフセット値/範囲がマッピング/設定されることができる。SL RSRP及び/またはSL RSRQを測定した端末は、(事前に設定された正規化されたまたは名目的な)SL(HARQフィードバック)(最大)送信電力に前記SL RSRP値及び/またはSL RSRQ値と関連したオフセットを適用し、最終HARQフィードバック送信電力を決定することができる。ここで、例えば、オフセット値/範囲は、端末、リソースプール、サービスのタイプ、サービスの優先順位、サービスと関連したQoS要求事項、SL送信に使われる(周波数)リソース大きさ、SL送信に使われるMCS値、リソースプール関連混雑レベル(例、CBR)、及び/またはキャストのタイプに特定的に設定されることができる。
【0162】
[193] 例えば、SL RSRP及び/またはSL RSRQ値/範囲別に異なる(正規化されたまたは名目的な)(最大)HARQフィードバック送信電力値/範囲がマッピング/設定されることができる。例えば、(正規化されたまたは名目的な)(最大)HARQフィードバック送信電力値/範囲は、端末、リソースプール、サービスのタイプ、サービスの優先順位、サービスと関連したQoS要求事項、SL送信に使われる(周波数)リソース大きさ、SL送信に使われるMCS値、リソースプール関連混雑レベル(例、CBR)、及び/またはキャストのタイプに特定的に設定されることができる。
【0163】
[194] 例えば、前記参照信号及び/または前記参照信号を含むSLチャネルと関連した送信電力値は、事前に定義されたチャネルを介して端末にシグナリングされることができる。例えば、送信端末は、前記参照信号及び/または前記参照信号を含むSLチャネルと関連した送信電力値を事前に定義されたチャネルを介して受信端末に送信できる。例えば、前記事前に定義されたチャネルは、PSCCHである。例えば、前記受信端末は、前記参照信号に基づいてSL経路損失、SL RSRP、及び/またはSL RSRQのうち少なくともいずれか一つを測定する端末である。
【0164】
[195] 例えば、前記開ループ電力制御パラメータ(及び/またはSL RSRP(及び/またはSL RSRQ)値/範囲別にマッピング/設定された(最大または最小)HARQフィードバック送信電力値)は、サービスのタイプ、サービスの優先順位、SL通信のタイプ(例えば、ユニキャスト、グループキャスト、ブロードキャスト)、(リソースプール関連)混雑レベル(例えば、CBR(Channel Busy Ratio))、サービスと関連したセッション、サービスと関連したPPPP、サービスと関連したPPPR、サービスと関連したターゲットBLER(Block Error Rate)、サービスと関連したターゲットSINR(Signal to Interference plus Noise Ratio)、サービスと関連した(最小または最大)ターゲット通信距離、及び/またはサービスと関連した遅延バジェット別に異なるようにまたは独立的に設定されることができる。そして/または、例えば、閉ループ電力制御動作/パラメータは、サービスのタイプ、サービスの優先順位、SL通信のタイプ(例えば、ユニキャスト、グループキャスト、ブロードキャスト)、(リソースプール関連)混雑レベル(例えば、CBR)、サービスと関連したセッション、サービスと関連したPPPP、サービスと関連したPPPR、サービスと関連したターゲットBLER(Block Error Rate)、サービスと関連したターゲットSINR(Signal to Interference plus Noise Ratio)、サービスと関連した(最小または最大)ターゲット通信距離、及び/またはサービスと関連した遅延バジェット別に異なるようにまたは独立的に運営/設定されることができる。
【0165】
[196] 例えば、HARQフィードバックと関連した開ループ電力制御パラメータは、PSSCH及び/またはPSCCHと関連した開ループ電力制御パラメータと異なるようにまたは独立的に設定されることができる。そして/または、例えば、HARQフィードバックと関連した閉ループ電力制御動作/パラメータは、PSSCH及び/またはPSCCHと関連した閉ループ電力制御動作/パラメータと異なるようにまたは独立的に運営/設定されることができる。
【0166】
[197] 本開示の一実施例によると、HARQフィードバックを受信する送信端末から離れた距離差が事前に設定された閾値以内である受信端末に対してのみ、HARQフィードバックリソースのFDMが許容または設定されることができる。そして/または、例えば、送信端末と受信端末との間のリンクに対するSL経路損失差が事前に設定された閾値以内である受信端末に対してのみ、HARQフィードバックリソースのFDMが許容または設定されることができる。そして/または、例えば、送信端末と受信端末との間のリンクに対するSL RSRP差が事前に設定された閾値以内である受信端末に対してのみ、HARQフィードバックリソースのFDMが許容または設定されることができる。そして/または、例えば、送信端末と受信端末との間のリンクに対するSL RSRQ差が事前に設定された閾値以内である受信端末に対してのみ、HARQフィードバックリソースのFDMが許容または設定されることができる。
【0167】
[198] 例えば、複数の受信端末と送信端末との間の距離差が事前に設定された閾値以内である場合、前記複数の受信端末は、HARQフィードバックを周波数軸上のFDMされたリソースを介して送信できる。そして/または、例えば、複数の受信端末と送信端末との間の経路損失差が事前に設定された閾値以内である場合、前記複数の受信端末は、HARQフィードバックを周波数軸上のFDMされたリソースを介して送信できる。そして/または、例えば、複数の受信端末と送信端末との間の(測定された)RSRP値差が事前に設定された閾値以内である場合、前記複数の受信端末は、HARQフィードバックを周波数軸上のFDMされたリソースを介して送信できる。そして/または、例えば、複数の受信端末と送信端末との間の(測定された)RSRQ値差が事前に設定された閾値以内である場合、前記複数の受信端末は、HARQフィードバックを周波数軸上のFDMされたリソースを介して送信できる。
【0168】
[199] 例えば、グループ内の端末またはサブグループ間で、HARQフィードバックリソースがFDMされることは好ましくない。例えば、HARQフィードバック送信関連電力制御が適用されない場合、グループ内の異なる端末または異なるサブグループ間で、HARQフィードバックリソースがFDMされることは好ましくない。例えば、グループ内の異なる端末または異なるサブグループ間のHARQフィードバック受信電力差が事前に設定された閾値より大きい場合、グループ内の異なる端末または異なるサブグループ間で、HARQフィードバックリソースがFDMされることは好ましくない。例えば、グループ内の異なる端末または異なるサブグループ間のSL経路損失差が事前に設定された閾値より大きい場合、グループ内の異なる端末または異なるサブグループ間で、HARQフィードバックリソースがFDMされることは好ましくない。例えば、グループ内の異なる端末または異なるサブグループ間のSL RSRP差が事前に設定された閾値より大きい場合、グループ内の異なる端末または異なるサブグループ間で、HARQフィードバックリソースがFDMされることは好ましくない。例えば、グループ内の異なる端末または異なるサブグループ間のSL RSRQ差が事前に設定された閾値より大きい場合、グループ内の異なる端末または異なるサブグループ間で、HARQフィードバックリソースがFDMされることは好ましくない。
【0169】
[200] 例えば、前述した例示のように、HARQフィードバックリソースがFDMされることが好ましくない場合、HARQフィードバックリソースは、GUE_ID、受信端末関連識別子、SL HARQプロセスID、及び/または送信端末関連識別子のうち少なくともいずれか一つに基づいて疑似ランダム(pseudo random)にTDMされることができる。例えば、HARQフィードバックリソースは、GUE_ID、受信端末関連識別子、SL HARQプロセスID、及び/または送信端末関連識別子のうち少なくともいずれか一つに基づいて疑似ランダム(pseudo random)に決定されることができる。例えば、HARQフィードバックリソースは、GUE_ID、受信端末関連識別子、SL HARQプロセスID、及び/または送信端末関連識別子のうち少なくともいずれか一つを入力パラメータとして有する関数によりTDMされ、または決定されることができる。例えば、前記HARQフィードバックリソースは、グループ内の複数の端末の各々に対するHARQフィードバックリソースである。例えば、HARQフィードバックリソースは、グループ内のサブグループの各々に対するHARQフィードバックリソースである。例えば、受信端末関連識別子は、目的地(destination)IDである。例えば、送信端末関連識別子は、ソース(source)IDである。例えば、前記関数は、事前に定義されることができる。
【0170】
[201] 図19は、本開示の一実施例によって、端末がHARQフィードバックを送受信する手順を示す。図19の実施例は、本開示の多様な実施例と結合されることができる。
【0171】
[202] 図19を参照すると、ステップS1910において、送信端末は、PSCCH及び/またはPSSCHを受信端末に送信できる。例えば、送信端末は、PSCCHリソース及び/またはPSSCHリソースを利用してSL情報を受信端末に送信できる。例えば、前記SL情報は、SL制御情報、SLデータ、SLパケット、SL TB(Transport Block)、SLメッセージ及び/またはSLサービスのうち少なくともいずれか一つを含むことができる。
【0172】
[203] ステップS1920において、受信端末は、HARQフィードバックリソースを決定することができる。付加的に、例えば、送信端末は、HARQフィードバックリソースを決定することができる。例えば、前記受信端末は、グループ内でグループキャスト通信を実行する複数の端末のうちいずれか一つの端末である。
【0173】
[204] 例えば、前記HARQフィードバックリソースは、前記PSCCHリソース、前記PSSCHリソース、及び/またはGUE_IDのうち少なくともいずれか一つに基づいて決定されることができる。例えば、グループ内の複数の受信端末が、異なるPSFCHリソースを利用してHARQ ACKまたはHARQ NACKを送信端末にフィードバックする場合、前記グループ内の複数の受信端末は、GUE_IDを利用してHARQフィードバックリソースを決定することができる。例えば、前記リソースは、時間領域リソース(time domain resource)、周波数領域リソース(frequency domain resource)、及び/またはコード領域リソース(code domain resource)のうち少なくともいずれか一つを含むことができる。例えば、前記GUE_IDは、前記グループ内で端末を識別するための情報である。
【0174】
[205] ステップS1930において、受信端末は、HARQフィードバックを送信端末に送信できる。例えば、受信端末は、前記PSCCH及び/またはPSSCHに対応するHARQフィードバックを送信端末に送信できる。例えば、受信端末は、前記PSCCHリソース、前記PSSCHリソース、及び/またはGUE_IDのうち少なくともいずれか一つに基づいて決定されたHARQフィードバックリソースを利用して前記HARQフィードバックを送信端末に送信できる。
【0175】
[206] 例えば、受信端末がPSCCH及び/またはPSSCHを成功的に受信した場合、前記HARQフィードバックはHARQ ACKである。例えば、受信端末がPSCCH及び/またはPSSCHを受信することに失敗した場合、前記HARQフィードバックは、HARQ NACK及び/またはDTX(discontinuous detection)のうち少なくともいずれか一つである。
【0176】
[207] 本開示の多様な実施例によると、送信端末がPSSCH及び/またはPSCCH送信リソースをセンシング動作を介して選択する場合、HARQフィードバック送信関連リソースが衝突する問題が発生しない。例えば、複数の送信端末が互いに異なるPSSCH及び/またはPSCCH送信リソースをセンシング動作を介して選択する場合、HARQフィードバックリソースは、PSSCHリソース及び/またはPSCCHリソースに基づいて決定されることができる。したがって、センシング動作に基づいて互いに異なるPSSCH及び/またはPSCCH送信リソースを選択した端末間で、HARQフィードバックリソースの衝突は、自動的に回避されることができる。
【0177】
[208] 本開示の多様な実施例によると、送信端末がグループ内の複数の受信端末に同じPSSCH及び/またはPSCCHを送信する場合、複数の受信端末は、互いに異なるGUE_IDを利用してHARQフィードバックリソースを決定することができる。したがって、グループ内の複数の受信端末が同じPSSCH及び/またはPSCCHを受信したにもかかわらず、HARQフィードバックリソースが衝突することを防止することができる。
【0178】
[209] 図20は、本開示の一実施例によって、端末がHARQフィードバックを送受信する手順を示す。図20の実施例は、本開示の多様な実施例と結合されることができる。
【0179】
[210] 例えば、グループ内の複数の端末にグループ内部で端末を識別するためのIDが割当/指定されることができる。例えば、前記IDは、内部(inner)IDと称することができる。例えば、前記内部IDは、GUE_IDのような用途またはパラメータである。例えば、特定グループキャストトラフィックに対して、応用階層(application layer)は、V2X階層に端末の内部IDに対する情報及びグループ内の端末の数に対する情報を伝達することができる。例えば、前記端末は、前記特定グループキャストトラフィックを送信する端末である。例えば、特定グループキャストトラフィックに対して、応用階層は、V2X階層にグループ内の他の端末の内部IDに対する情報を伝達しない。例えば、グループキャストトラフィックは、グループキャストサービス、グループキャストデータ、グループキャストパケット、及び/またはグループキャストメッセージのうち少なくともいずれか一つを含むことができる。
【0180】
[211] 例えば、図20の実施例において、送信端末がグループキャストと関連した第1のトラフィックをグループ内の複数の受信端末に送信しようとする場合、前記送信端末の応用階層は、前記送信端末の内部IDに対する情報(例えば、ID=2)及びグループ内の端末の数に対する情報(例えば、5個)を前記送信端末のV2X階層に伝達できる。例えば、受信端末1の応用階層は、前記受信端末1の内部IDに対する情報(例えば、ID=0)及びグループ内の端末の数に対する情報(例えば、5個)を前記受信端末1のV2X階層に伝達できる。例えば、受信端末2の応用階層は、前記受信端末2の内部IDに対する情報(例えば、ID=1)及びグループ内の端末の数に対する情報(例えば、5個)を前記受信端末2のV2X階層に伝達できる。例えば、受信端末3の応用階層は、前記受信端末3の内部IDに対する情報(例えば、ID=3)及びグループ内の端末の数に対する情報(例えば、5個)を前記受信端末3のV2X階層に伝達できる。例えば、受信端末4の応用階層は、前記受信端末4の内部IDに対する情報(例えば、ID=4)及びグループ内の端末の数に対する情報(例えば、5個)を前記受信端末4のV2X階層に伝達できる。
【0181】
[212] そして、例えば、端末のV2X階層は、前記端末のAS階層に前記端末の内部IDに対する情報及びグループ内の端末の数に対する情報を伝達することができる。また、例えば、端末のV2X階層は、前記端末のAS階層にL2 ID(例えば、ソースL2 ID、目的地L2 ID)及び/またはQoS情報などを共に伝達できる。
【0182】
[213] 図20を参照すると、ステップS2010において、送信端末は、特定グループキャストトラフィックを複数の受信端末に送信できる。例えば、前記特定グループキャストトラフィックは、PSSCH及び/またはPSCCHを介して送信されることができる。
【0183】
[214] ステップS2020において、複数の受信端末は、HARQフィードバックリソースを決定することができる。例えば、複数の受信端末(例えば、複数の受信端末のAS階層)は、事前に定義された規則によって自分の内部IDに対する情報及びグループ内の端末の数に対する情報に基づいて、特定グループキャストトラフィックに対するHARQフィードバックリソースを決定することができる。
【0184】
[215] 例えば、送信端末は、(自分が受信すべき)HARQフィードバックリソースを決定することができる。例えば、送信端末は、自分の内部IDに対する情報及びグループ内の端末の数に対する情報に基づいて、特定グループキャストトラフィックと関連した前記複数の受信端末のHARQフィードバックリソースを導出または決定することができる。
【0185】
[216] 例えば、応用階層が端末の内部IDに対する情報及びグループ内の端末の数に対する情報を端末のV2X階層に提供する場合、前記端末は、前記グループキャストオプション1または前記グループキャストオプション2のうちいずれか一つを前記特定グループキャストトラフィックに対する(選択可能な)HARQフィードバックオプションに決定または見なすことができる。例えば、前記端末のV2X階層は、前記グループキャストオプション1または前記グループキャストオプション2のうちいずれか一つを前記特定グループキャストトラフィックに対する(選択可能な)HARQフィードバックオプションに決定または見なすことができる。付加的に、例えば、事前に設定された条件が満たすかどうかによって、端末は、前記グループキャストオプション1または前記グループキャストオプション2のうちいずれか一つを前記特定グループキャストトラフィックに対するHARQフィードバックオプションに最終的に決定または見なすことができる。例えば、グループキャストに参加する複数の端末のための各々のHARQフィードバックリソースがリソースプールで全てサポートされる場合、端末は、前記グループキャストオプション2を前記特定グループキャストトラフィックに対するHARQフィードバックオプションに最終的に決定または見なすことができる。例えば、グループキャストに参加する複数の端末のための各々のHARQフィードバックリソースがリソースプールで全てサポートされない場合、端末は、前記グループキャストオプション1を前記特定グループキャストトラフィックに対するHARQフィードバックオプションに最終的に決定または見なすことができる。例えば、前記決定は、端末のAS階層で実行されることができる。
【0186】
[217] 例えば、応用階層がグループ内の端末の数に対する情報を端末のV2X階層に提供しない場合、前記端末は、前記グループキャストオプション1を前記特定グループキャストトラフィックに対するHARQフィードバックオプションに決定または見なすことができる。例えば、応用階層が端末の内部IDに対する情報及び/またはグループ内の端末の数に対する情報を端末のV2X階層に提供しない場合、前記端末は、前記グループキャストオプション1を前記特定グループキャストトラフィックに対するHARQフィードバックオプションに決定または見なすことができる。例えば、前記端末のV2X階層は、前記グループキャストオプション1を前記特定グループキャストトラフィックに対するHARQフィードバックオプションに決定または見なすことができる。
【0187】
[218] 例えば、応用階層及び/またはV2X階層が端末の内部IDに対する情報及びグループ内の端末の数に対する情報を端末のAS階層に提供する場合、前記端末は、前記グループキャストオプション1または前記グループキャストオプション2のうちいずれか一つを前記特定グループキャストトラフィックに対する(選択可能な)HARQフィードバックオプションに決定または見なすことができる。例えば、前記端末のAS階層は、前記グループキャストオプション1または前記グループキャストオプション2のうちいずれか一つを前記特定グループキャストトラフィックに対する(選択可能な)HARQフィードバックオプションに決定または見なすことができる。付加的に、例えば、事前に設定された条件が満たすかどうかによって、端末は、前記グループキャストオプション1または前記グループキャストオプション2のうちいずれか一つを前記特定グループキャストトラフィックに対するHARQフィードバックオプションに最終的に決定または見なすことができる。例えば、グループキャストに参加する複数の端末のための各々のHARQフィードバックリソースがリソースプールで全てサポートされる場合、端末は、前記グループキャストオプション2を前記特定グループキャストトラフィックに対するHARQフィードバックオプションに最終的に決定または見なすことができる。例えば、グループキャストに参加する複数の端末のための各々のHARQフィードバックリソースがリソースプールで全てサポートされない場合、端末は、前記グループキャストオプション1を前記特定グループキャストトラフィックに対するHARQフィードバックオプションに最終的に決定または見なすことができる。例えば、前記決定は、端末のAS階層で実行されることができる。
【0188】
[219] 例えば、応用階層及び/またはV2X階層がグループ内の端末の数に対する情報を端末のAS階層に提供しない場合、前記端末は、前記グループキャストオプション1を前記特定グループキャストトラフィックに対するHARQフィードバックオプションに決定または見なすことができる。例えば、応用階層及び/またはV2X階層が端末の内部IDに対する情報及び/またはグループ内の端末の数に対する情報を端末のAS階層に提供しない場合、前記端末は、前記グループキャストオプション1を前記特定グループキャストトラフィックに対するHARQフィードバックオプションに決定または見なすことができる。例えば、前記端末のAS階層は、前記グループキャストオプション1を前記特定グループキャストトラフィックに対するHARQフィードバックオプションに決定または見なすことができる。
【0189】
[220] 例えば、リソースプール特定的に、グループキャストオプション1及び/またはグループキャストオプション2うち少なくともいずれか一つのサポート可否が端末に対してシグナリングされることができる。例えば、リソースプール特定的に、サービスのタイプ、キャストのタイプまたはQoS要求事項別に、グループキャストオプション1及び/またはグループキャストオプション2うち少なくともいずれか一つのサポート可否が端末に対してシグナリングされることができる。例えば、リソースプール特定的に、サービスのタイプ、キャストのタイプまたはQoS要求事項別に、グループキャストオプション1と関連したPSFCHリソースが設定されるかどうかが端末に対してシグナリングされることができる。例えば、リソースプール特定的に、サービスのタイプ、キャストのタイプまたはQoS要求事項別に、グループキャストオプション2と関連したPSFCHリソースが設定されるかどうかが端末に対してシグナリングされることができる。
【0190】
[221] ステップS2030において、送信端末は、複数の受信端末からHARQフィードバックを受信することができる。例えば、送信端末は、複数の受信端末からグループキャストオプション1ベースのHARQフィードバックを受信することができる。例えば、送信端末は、複数の受信端末からグループキャストオプション2ベースのHARQフィードバックを受信することができる。
【0191】
[222] 例えば、特定グループキャストオプションベースのHARQフィードバック動作が特定グループキャストトラフィックに対して要求されることができる。例えば、サービスと関連した信頼度要求事項が高い場合、送信端末が前記サービスを受信端末に送信すると、受信端末は、グループキャストオプション2ベースのHARQフィードバック動作を実行する必要がある。もし、受信端末が前記サービスに対してグループキャストオプション1ベースのHARQフィードバック動作を実行する場合、DTX問題が発生できるため、受信端末は、信頼度要求事項が高いサービスに対してグループキャストオプション2ベースのHARQフィードバック動作を実行する必要がある。例えば、DTX問題は、受信端末がPSCCH受信に失敗し、かつ送信端末にNACKを送信しない場合、送信端末が、受信端末がPSCCH及びPSSCHの受信に成功したと誤認する問題である。例えば、前記DTX問題によって、前記サービスの信頼度要求事項が満たしにくい。したがって、もし、リソースプール上で特定グループキャストオプションがサポートされない場合、例えば、該当トラフィック及び/またはサービスに対して特定グループキャストオプションがサポートされない場合、送信端末は、ブラインド再送信動作を実行することができる。例えば、もし、特定グループキャストオプションと関連したPSFCHリソースが設定されていない場合、送信端末は、ブラインド再送信動作を実行することができる。例えば、送信端末は、受信端末からのHARQフィードバック受信無しで再送信を実行することができる。
【0192】
[223] 本発明の多様な実施例によると、SL HARQフィードバック送信の信頼度が向上することができ、SLサービスの遅延が減少されることができ、及び/またはSLサービスの信頼度が増加されることができる。
【0193】
[224] 図21は、本開示の一実施例によって、第1の装置100がSL HARQフィードバックを送信する方法を示す。図21の実施例は、本開示の多様な実施例と結合されることができる。
【0194】
[225] 図21を参照すると、ステップS2110において、第1の装置100は、PSSCH(Physical Sidelink Shared Channel)を第2の装置200から受信することができる。
【0195】
[226] ステップS2120において、第1の装置100は、前記PSSCHと関連したSL HARQフィードバックを前記第2の装置200に送信できる。例えば、前記SL HARQフィードバックが送信されるリソースは、前記第1の装置100のID(identifier)に基づいて決定されることができる。例えば、前記第1の装置100のIDは、グループ内でグループキャスト通信を実行する複数の端末のうち前記第1の装置100を識別するためのIDである。例えば、前記複数の端末のIDは、前記グループ内で互いに異なる。
【0196】
[227] 例えば、前記SL HARQフィードバックが送信されるリソースは、前記PSSCHと関連したリソースに対する情報に基づいて決定されることができる。例えば、前記PSSCHと関連したリソースに対する情報は、前記PSSCHと関連した時間に対する情報または前記PSSCHと関連した周波数に対する情報のうち少なくともいずれか一つを含むことができる。
【0197】
[228] 付加的に、第1の装置100は、PSCCH(Physical Sidelink Control Channel)を前記第2の装置200から受信することができる。例えば、前記SL HARQフィードバックが送信されるリソースは、前記PSCCHと関連したリソースに対する情報に基づいて決定されることができる。例えば、前記PSCCHと関連したリソースに対する情報は、前記PSCCHと関連した時間に対する情報または前記PSCCHと関連した周波数に対する情報のうち少なくともいずれか一つを含むことができる。
【0198】
[229] 例えば、前記PSSCHと関連したリソースと前記SL HARQフィードバックが送信されるリソースとの間の時間ギャップ(time gap)が前記第1の装置100及び前記第2の装置200に対して設定されることができる。
【0199】
[230] 例えば、前記SL HARQフィードバックが送信されるリソースは、前記PSSCHと関連した周波数領域に含まれることができる。
【0200】
[231] 付加的に、第1の装置100は、前記PSSCH上に含まれているDMRSに基づいて前記第1の装置100と前記第2の装置200との間のチャネル状態を測定することができ、第1の装置100は、前記チャネル状態に基づいて前記SL HARQフィードバックの送信電力を決定することができる。例えば、前記SL HARQフィードバックの送信電力は、サービスのタイプ、前記サービスの優先順位、SL通信のタイプ、前記サービスと関連したセッション、前記サービスと関連したPPPP(ProSe Per Packet Priority)、前記サービスと関連したPPPR(ProSe Per Packet Reliability)、前記サービスと関連したターゲットBLER(Block Error Rate)、前記サービスと関連したターゲットSINR(Signal to Interference plus Noise Ratio)、または前記サービスと関連した遅延バジェット(latency budget)のうち少なくともいずれか一つに基づいて決定されることができる。
【0201】
[232] 前記提案された方法は、本開示の多様な実施例に係る装置により実行されることができる。まず、第1の装置100のプロセッサ102は、PSSCH(Physical Sidelink Shared Channel)を第2の装置200から受信するように送受信機106を制御することができる。そして、第1の装置100のプロセッサ102は、前記PSSCHと関連したSL HARQフィードバックを前記第2の装置200に送信するように送受信機106を制御することができる。
【0202】
[233] 図22は、本開示の一実施例によって、第2の装置200がSL HARQフィードバックを受信する方法を示す。図22の実施例は、本開示の多様な実施例と結合されることができる。
【0203】
[234] 図22を参照すると、ステップS2210において、第2の装置200は、PSSCH(Physical Sidelink Shared Channel)をグループ内の複数の端末に送信できる。
【0204】
[235] ステップS2220において、第2の装置200は、前記PSSCHと関連したSL HARQフィードバックを前記複数の端末から受信することができる。例えば、前記SL HARQフィードバックが受信されるリソースは、前記複数の端末のID(identifier)に基づいて決定されることができる。例えば、前記複数の端末のIDは、前記グループ内で互いに異なる。例えば、前記SL HARQフィードバックは、互いに異なるリソース上で前記グループ内の複数の端末から受信されることができる。
【0205】
[236] 前記提案された方法は、本開示の多様な実施例に係る装置により実行されることができる。まず、第2の装置200のプロセッサ202は、PSSCH(Physical Sidelink Shared Channel)をグループ内の複数の端末に送信するように送受信機206を制御することができる。そして、第2の装置200のプロセッサ202は、前記PSSCHと関連したSL HARQフィードバックを前記複数の端末から受信するように送受信機206を制御することができる。
【0206】
[237] 本開示の多様な実施例は、独立的に具現されることができる。または、本開示の多様な実施例は、相互組み合わせまたは併合されて具現されることができる。例えば、本開示の多様な実施例は、説明の便宜のために3GPPシステムに基づいて説明されたが、本開示の多様な実施例は、3GPPシステム外に他のシステムに拡張可能である。
【0207】
[238] 以下、本開示の多様な実施例が適用されることができる装置に対して説明する。
【0208】
[239] これに制限されるものではないが、本文書に開示された多様な説明、機能、手順、提案、方法及び/または動作流れ図は、機器間に無線通信/連結(例えば、5G)を必要とする多様な分野に適用されることができる。
【0209】
[240] 以下、図面を参照としてより具体的に例示する。以下の図面/設定で同一の図面符号は、異なって記述しない限り、同一または対応するハードウェアブロック、ソフトウェアブロック、または機能ブロックを例示することができる。
【0210】
[241] 図23は、本開示の一実施例に係る、通信システム1を示す。
【0211】
[242] 図23を参照すると、本開示の多様な実施例が適用される通信システム1は、無線機器、基地局、及びネットワークを含む。ここで、無線機器は、無線接続技術(例えば、5G NR(New RAT)、LTE(Long Term Evolution))を利用して通信を実行する機器を意味し、通信/無線/5G機器と呼ばれる。これに制限されるものではないが、無線機器は、ロボット100a、車両100b-1、100b-2、XR(eXtended Reality)機器100c、携帯機器(Hand-held device)100d、家電100e、IoT(Internet of Thing)機器100f、AI機器/サーバ400を含むことができる。例えば、車両は、無線通信機能が備えられた車両、自律走行車両、車両間の通信を実行することができる車両などを含むことができる。ここで、車両は、UAV(Unmanned Aerial Vehicle)(例えば、ドローン)を含むことができる。XR機器は、AR(Augmented Reality)/VR(Virtual Reality)/MR(Mixed Reality)機器を含み、HMD(Head-Mounted Device)、車両に備えられたHUD(Head-Up Display)、テレビ、スマートフォン、コンピュータ、ウェアラブルデバイス、家電機器、デジタルサイネージ(signage)、車両、ロボットなどの形態で具現されることができる。携帯機器は、スマートフォン、スマートパッド、ウェアラブル機器(例えば、スマートウォッチ、スマートグラス)、コンピュータ(例えば、ノートブック等)などを含むことができる。家電は、TV、冷蔵庫、洗濯機などを含むことができる。IoT機器は、センサ、スマートメーターなどを含むことができる。例えば、基地局、ネットワークは、無線機器で具現されることもでき、特定無線機器200aは、他の無線機器に基地局/ネットワークノードとして動作することもできる。
【0212】
[243] 無線機器100a~100fは、基地局200を介してネットワーク300と連結されることができる。無線機器100a~100fにはAI(Artificial Intelligence)技術が適用でき、無線機器100a~100fはネットワーク300を介してAIサーバ400と連結されることができる。ネットワーク300は、3Gネットワーク、4G(例えば、LTE)ネットワークまたは5G(例えば、NR)ネットワークなどを用いて構成されることができる。無線機器100a~100fは、基地局200/ネットワーク300を介して互いに通信することもできるが、基地局/ネットワークを介することなく、直接通信(例えば、サイドリンク通信(sidelink communication))することもできる。例えば、車両100b-1、100b-2は、直接通信(例えば、V2V(Vehicle to Vehicle)/V2X(Vehicle to everything) communication)をすることができる。また、IoT機器(例えば、センサ)は、他のIoT機器(例えば、センサ)または他の無線機器100a~100fと直接通信を行うことができる。
【0213】
[244] 無線機器100a~100f/基地局200、基地局200/基地局200間には無線通信/連結150a、150b、150cが行われることができる。ここで、無線通信/連結は、アップリンク/ダウンリンク通信150a、サイドリンク通信150b(または、D2D通信)、及び基地局間の通信150c(例えば、relay、IAB(Integrated Access Backhaul)のような多様な無線接続技術(例えば、5G NR)を介して行われることができる。無線通信/連結150a、150b、150cを介して無線機器と基地局/無線機器、基地局と基地局は、互いに無線信号を送信/受信することができる。例えば、無線通信/連結150a、150b、150cは、多様な物理チャネルを介して信号を送信/受信することができる。このために、本開示の多様な提案に基づいて、無線信号の送信/受信のための多様な構成情報設定過程、多様な信号処理過程(例えば、チャネルエンコーディング/デコーディング、変調/復調、リソースマッピング/デマッピング等)、リソース割当過程などのうち少なくとも一部が実行されることができる。
【0214】
[245] 図24は、本開示の一実施例に係る、無線機器を示す。
【0215】
[246] 図24を参照すると、第1の無線機器100と第2の無線機器200は、様々な無線アクセス技術(例えば、LTE、NR)を介して無線信号を送受信することができる。ここで、{第1の無線機器100、第2の無線機器200}は、図23の{無線機器100x、基地局200}及び/または{無線機器100x、無線機器100x}に対応し得る。
【0216】
[247] 第1の無線機器100は、一つ以上のプロセッサ102及び一つ以上のメモリ104を含み、追加的に一つ以上の送受信機106及び/または一つ以上のアンテナ108をさらに含むことができる。プロセッサ102は、メモリ104及び/または送受信機106を制御し、本文書に開示された説明、機能、手順、提案、方法及び/または動作流れ図を具現するように構成されることができる。例えば、プロセッサ102は、メモリ104内の情報を処理して第1の情報/信号を生成した後、送受信機106を介して第1の情報/信号を含む無線信号を送信することができる。また、プロセッサ102は、送受信機106を介して第2の情報/信号を含む無線信号を受信した後、第2の情報/信号の信号処理から得た情報をメモリ104に格納することができる。メモリ104は、プロセッサ102と連結されることができ、プロセッサ102の動作と関連した多様な情報を格納することができる。例えば、メモリ104は、プロセッサ102により制御されるプロセスのうち一部または全部を実行し、または本文書に開示された説明、機能、手順、提案、方法及び/または動作流れ図を実行するための命令を含むソフトウェアコードを格納することができる。ここで、プロセッサ102とメモリ104は、無線通信技術(例えば、LTE、NR)を具現するように設計された通信モデム/回路/チップの一部である。送受信機106は、プロセッサ102と連結されることができ、一つ以上のアンテナ108を介して無線信号を送信及び/または受信することができる。送受信機106は、送信機及び/または受信機を含むことができる。送受信機106は、RF(Radio Frequency)ユニットと混用されることができる。本開示において、無線機器は、通信モデム/回路/チップを意味することもできる。
【0217】
[248] 第2の無線機器200は、一つ以上のプロセッサ202、一つ以上のメモリ204を含み、追加的に一つ以上の送受信機206及び/または一つ以上のアンテナ208をさらに含むことができる。プロセッサ202は、メモリ204及び/または送受信機206を制御し、本文書に開示された説明、機能、手順、提案、方法及び/または動作流れ図を具現するように構成されることができる。例えば、プロセッサ202は、メモリ204内の情報を処理して第3の情報/信号を生成した後、送受信機206を介して第3の情報/信号を含む無線信号を送信することができる。また、プロセッサ202は、送受信機206を介して第4の情報/信号を含む無線信号を受信した後、第4の情報/信号の信号処理から得た情報をメモリ204に格納することができる。メモリ204は、プロセッサ202と連結されることができ、プロセッサ202の動作と関連した多様な情報を格納することができる。例えば、メモリ204は、プロセッサ202により制御されるプロセスのうち一部または全部を実行し、または本文書に開示された説明、機能、手順、提案、方法及び/または動作流れ図を実行するための命令を含むソフトウェアコードを格納することができる。ここで、プロセッサ202とメモリ204は、無線通信技術(例えば、LTE、NR)を具現するように設計された通信モデム/回路/チップの一部である。送受信機206は、プロセッサ202と連結されることができ、一つ以上のアンテナ208を介して無線信号を送信及び/または受信することができる。送受信機206は、送信機及び/または受信機を含むことができる。送受信機206は、RFユニットと混用されることができる。本開示において、無線機器は、通信モデム/回路/チップを意味することもできる。
【0218】
[249] 以下、無線機器100、200のハードウェア要素に対してより具体的に説明する。これに制限されるものではないが、一つ以上のプロトコル階層が一つ以上のプロセッサ102、202により具現されることができる。例えば、一つ以上のプロセッサ102、202は、一つ以上の階層(例えば、PHY、MAC、RLC、PDCP、RRC、SDAPのような機能的階層)を具現することができる。一つ以上のプロセッサ102、202は、本文書に開示された説明、機能、手順、提案、方法及び/または動作流れ図によって、一つ以上のPDU(Protocol Data Unit)及び/または一つ以上のSDU(Service Data Unit)を生成することができる。一つ以上のプロセッサ102、202は、本文書に開示された説明、機能、手順、提案、方法及び/または動作流れ図によって、メッセージ、制御情報、データまたは情報を生成することができる。一つ以上のプロセッサ102、202は、本文書に開示された機能、手順、提案及び/または方法によって、PDU、SDU、メッセージ、制御情報、データまたは情報を含む信号(例えば、ベースバンド信号)を生成し、一つ以上の送受信機106、206に提供できる。一つ以上のプロセッサ102、202は、一つ以上の送受信機106、206から信号(例えば、ベースバンド信号)を受信することができ、本文書に開示された説明、機能、手順、提案、方法及び/または動作流れ図によって、PDU、SDU、メッセージ、制御情報、データまたは情報を取得することができる。
【0219】
[250] 一つ以上のプロセッサ102、202は、コントローラ、マイクロコントローラ、マイクロプロセッサまたはマイクロコンピュータと呼ばれる。一つ以上のプロセッサ102、202は、ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせにより具現されることができる。一例として、一つ以上のASIC(Application Specific Integrated Circuit)、一つ以上のDSP(Digital Signal Processor)、一つ以上のDSPD(Digital Signal Processing Device)、一つ以上のPLD(Programmable Logic Device)または一つ以上のFPGA(Field Programmable Gate Arrays)が一つ以上のプロセッサ102、202に含まれることができる。本文書に開示された説明、機能、手順、提案、方法及び/または動作流れ図は、ファームウェアまたはソフトウェアを使用して具現されることができ、ファームウェアまたはソフトウェアは、モジュール、手順、機能などを含むように具現されることができる。本文書に開示された説明、機能、手順、提案、方法及び/または動作流れ図は、実行するように設定されたファームウェアまたはソフトウェアは、一つ以上のプロセッサ102、202に含まれ、または一つ以上のメモリ104、204に格納されて一つ以上のプロセッサ102、202により駆動されることができる。本文書に開示された説明、機能、手順、提案、方法及び/または動作流れ図は、コード、命令語及び/または命令語の集合形態でファームウェアまたはソフトウェアを使用して具現されることができる。
【0220】
[251] 一つ以上のメモリ104、204は、一つ以上のプロセッサ102、202と連結されることができ、様々な形態のデータ、信号、メッセージ、情報、プログラム、コード、指示及び/または命令を格納することができる。一つ以上のメモリ104、204は、ROM、RAM、EPROM、フラッシュメモリ、ハードドライブ、レジスタ、キャッシュメモリ、コンピュータ読取格納媒体及び/またはこれらの組み合わせで構成されることができる。一つ以上のメモリ104、204は、一つ以上のプロセッサ102、202の内部及び/または外部に位置し得る。また、一つ以上のメモリ104、204は、有線または無線連結のような様々な技術を介して、一つ以上のプロセッサ102、202と連結されることができる。
【0221】
[252] 一つ以上の送受信機106、206は、一つ以上の他の装置に本文書の方法及び/または動作流れ図等で言及されるユーザデータ、制御情報、無線信号/チャネルなどを送信することができる。一つ以上の送受信機106、206は、一つ以上の他の装置から本文書に開示された説明、機能、手順、提案、方法及び/または動作流れ図等で言及されるユーザデータ、制御情報、無線信号/チャネルなどを受信することができる。例えば、一つ以上の送受信機106、206は、一つ以上のプロセッサ102、202と連結されることができ、無線信号を送受信することができる。例えば、一つ以上のプロセッサ102、202は、一つ以上の送受信機106、206が一つ以上の他の装置にユーザデータ、制御情報または無線信号を送信するように制御できる。また、一つ以上のプロセッサ102、202は、一つ以上の送受信機106、206が一つ以上の他の装置からユーザデータ、制御情報または無線信号を受信するように制御できる。また、一つ以上の送受信機106、206は、一つ以上のアンテナ108、208と連結されることができ、一つ以上の送受信機106、206は、一つ以上のアンテナ108、208を介して本文書に開示された説明、機能、手順、提案、方法及び/または動作流れ図等で言及されるユーザデータ、制御情報、無線信号/チャネルなどを送受信するように設定されることができる。本文書で、一つ以上のアンテナは、複数の物理アンテナであり、または複数の論理アンテナ(例えば、アンテナポート)である。一つ以上の送受信機106、206は、受信されたユーザデータ、制御情報、無線信号/チャネルなどを一つ以上のプロセッサ102、202を利用して処理するために、受信された無線信号/チャネルなどをRFバンド信号からベースバンド信号に変換(Convert)できる。一つ以上の送受信機106、206は、一つ以上のプロセッサ102、202を利用して処理されたユーザデータ、制御情報、無線信号/チャネルなどをベースバンド信号からRFバンド信号に変換できる。このために、一つ以上の送受信機106、206は、(アナログ)オシレータ及び/またはフィルタを含むことができる。
【0222】
[253] 図25は、本開示の一実施例に係る、送信信号のための信号処理回路を示す。
【0223】
[254] 図25を参照すると、信号処理回路1000は、スクランブラー1010、変調器1020、レイヤーマッパー1030、プリコーダ1040、リソースマッパー1050、信号生成器1060を含むことができる。これに制限されるわけではないが、図25の動作/機能は、図24のプロセッサ102、202及び/または送受信機106、206で行われることができる。図25のハードウェア要素は、図24のプロセッサ102、202及び/または送受信機106、206で実現できる。例えば、ブロック1010~1060は、図24のプロセッサ102、202で実現できる。また、ブロック1010~1050は、図24のプロセッサ102、202で実現され、ブロック1060は、図24の送受信機106、206で実現できる。
【0224】
[255] コードワードは、図25の信号処理回路1000を経て、無線信号に変換されることができる。ここで、コードワードは、情報ブロックの符号化されたビットシーケンスである。情報ブロックは、送信ブロック(例えば、UL-SCHの送信ブロック、DL-SCHの送信ブロック)を含むことができる。無線信号は、様々な物理チャネル(例えば、PUSCH、PDSCH)を介して送信されることができる。
【0225】
[256] 具体的に、コードワードは、スクランブラー1010によりスクランブルされたビットシーケンスに変換されることができる。スクランブルに使用されるスクランブルシーケンスは、初期化値に基づいて生成され、初期化値は無線機器のID情報などが含まれることができる。スクランブルされたビットシーケンスは、変調器1020により変調シンボルのシーケンスに変調されることができる。変調方式は、pi/2-BPSK(pi/2-Binary Phase Shift Keying)、m-PSK(m-Phase Shift Keying)、m-QAM(m-Quadrature Amplitude Modulation)などを含むことができる。複素変調シンボルのシーケンスは、レイヤーマッパー1030により一つ以上の送信レイヤーにマッピングされることができる。各送信レイヤーの変調シンボルは、プリコーダ1040により該当アンテナポートにマッピングされることができる(プリコーディング)。プリコーダ1040の出力zは、レイヤーマッパー1030の出力yをN*Mのプリコーディング行列Wと掛けて得られる。ここで、Nはアンテナポートの数、Mは送信レイヤーの数である。ここで、プリコーダ1040は、複素変調シンボルに対するトランスフォーム(transform)プリコーディング(例えば、DFT変換)を行った以降にプリコーディングを行うことができる。また、プリコーダ1040は、トランスフォームプリコーディングを行わずにプリコーディングを行うことができる。
【0226】
[257] リソースマッパー1050は、各アンテナポートの変調シンボルを時間-周波数リソースにマッピングできる。時間-周波数リソースは、時間ドメインで複数のシンボル(例えば、CP-OFDMAシンボル、DFT-s-OFDMAシンボル)を含み、周波数ドメインで複数の副搬送波を含むことができる。信号生成器1060は、マッピングされた変調シンボルから無線信号を生成し、生成された無線信号は各アンテナを介して他の機器へ送信されることができる。このために、信号生成器1060は、IFFT(Inverse Fast Fourier Transform)モジュール及びCP(Cyclic Prefix)挿入器、DAC(Digital-to-Analog Converter)、周波数アップリンク変換器(frequency uplink converter)などを含むことができる。
【0227】
[258] 無線機器における受信信号のための信号処理過程は、図25の信号処理過程1010~1060の逆で構成されることができる。例えば、無線機器(例えば、図24の100、200)は、アンテナポート/送受信機を介して外部から無線信号を受信することができる。受信された無線信号は、信号復元器を介してベースバンド信号に変換されることができる。このために、信号復元装置は、周波数ダウンリンク変換器(frequency downlink converter)、ADC(analog-to-digital converter)、CP除去器、FFT(Fast Fourier Transform)モジュールを含むことができる。以降、ベースバンド信号は、リソースデマッパー過程、ポストコーディング(postcoding)過程、復調過程、及びデスクランブル過程を経て、コードワードに復元されることができる。コードワードは、復号(decoding)を経て、元の情報ブロックに復元されることができる。従って、受信信号のための信号処理回路(図示せず)は、信号復元器、リソースデマッパー、ポストコーダー、復調器、デスクランブラー、及び復号器を含むことができる。
【0228】
[259] 図26は、本開示の一実施例に係る、無線機器を示す。無線機器は使用-例/サービスによって多様な形態で具現されることができる(図23参照)。
【0229】
[260] 図26を参照すると、無線機器100、200は、図24の無線機器100、200に対応し、様々な要素(element)、成分(component)、ユニット/部(unit)、及び/またはモジュール(module)で構成されることができる。例えば、無線機器100、200は、通信部110、制御部120、メモリ部130、及び追加要素140を含むことができる。通信部は、通信回路112及び送受信機114を含むことができる。例えば、通信回路112は、図24の一つ以上のプロセッサ102、202及び/または一つ以上のメモリ104、204を含むことができる。例えば、送受信機114は、図24の一つ以上の送受信機106、206及び/または一つ以上のアンテナ108、208を含むことができる。制御部120は、通信部110、メモリ部130、及び追加要素140と電気的に連結され、無線機器の諸般動作を制御する。例えば、制御部120は、メモリ部130に格納されたプログラム/コード/命令/情報に基づいて、無線機器の電気的/機械的動作を制御することができる。また、制御部120は、メモリ部130に格納された情報を通信部110を介して、外部(例えば、他の通信機器)に無線/有線インターフェースを介して送信するか、通信部110を介して、外部(例えば、他の通信機器)から無線/有線インターフェースを介して受信された情報をメモリ部130に格納することができる。
【0230】
[261] 追加要素140は、無線機器の種類に応じて多様に構成されることができる。例えば、追加要素140は、パワーユニット/バッテリー、入出力部(I/O部)、駆動部、及びコンピューティング部のうち少なくとも一つを含むことができる。これに制限されるわけではないが、無線機器は、ロボット(図23、100a)、車両100b-1、100b-2(図23)、XR機器100c(図23)携帯機器100d(図23)、家電100e(図23)、IoT機器100f(図23)、デジタル放送用端末、ホログラム装置、公共安全装置、MTC装置、医療装置、フィンテック装置(または、金融装置)、保安装置、気候/環境装置、AIサーバ/機器400(図23)、基地局200(図23)、ネットワークノード等の形態で実現できる。無線機器は、使用-例/サービスに応じて、移動可能であるか、固定された場所で使用できる。
【0231】
[262] 図26で、無線機器100、200内の様々な要素、成分、ユニット/部、及び/またはモジュールは、全体が有線インターフェースを介して相互連結されるか、少なくとも一部が通信部110を介して無線で連結されることができる。例えば、無線機器100、200内で制御部120と通信部110は有線で連結され、制御部120と第1ユニット(例えば、130、140)は、通信部110を介して無線で連結されることができる。また、無線機器100、200内の各要素、成分、ユニット/部、要素、及び/またはモジュールは、一つ以上の要素をさらに含むことができる。例えば、制御部120は、一つ以上のプロセッサの集合で構成されることができる。例えば、制御部120は、通信制御プロセッサ、アプリケーションプロセッサ(Application processor)、ECU(Electronic Control Unit)、グラフィック処理プロセッサ、メモリ制御プロセッサ等の集合で構成されることができる。別の例として、メモリ部130は、RAM(Random Access Memory)、DRAM(Dynamic RAM)、ROM(Read Only Memory)、フラッシュメモリ(flash memory)、揮発性メモリ(volatile memory)、非-揮発性メモリ(non-volatile memory)及び/またはこれらの組み合わせで構成されることができる。
【0232】
[263] 以下、図26の実現例について、図を参照としてより詳細に説明する。
【0233】
[264] 図27は、本開示の一実施例に係る、携帯機器を示す。携帯機器は、スマートフォン、スマートパッド、ウェアラブル機器(例えば、スマートウォッチ、スマートグラス)、携帯用コンピュータ(例えば、ノートブック等)を含むことができる。携帯機器は、MS(Mobile Station)、UT(user terminal)、MSS(Mobile Subscriber Station)、SS(Subscriber Station)、AMS(Advanced Mobile Station)またはWT(Wireless terminal)と呼ばれる。
【0234】
[265] 図27を参照すると、携帯機器100は、アンテナ部108、通信部110、制御部120、メモリ部130、電源供給部140a、インターフェース部140b、及び入出力部140cを含むことができる。アンテナ部108は、通信部110の一部で構成されることができる。ブロック110~130/140a~140cは、各々、図26のブロック110~130/140に対応する。
【0235】
[266] 通信部110は、他の無線機器、基地局と信号(例えば、データ、制御信号など)を送受信することができる。制御部120は、携帯機器100の構成要素を制御し、様々な動作を行うことができる。制御部120は、AP(Application Processor)を含むことができる。メモリ部130は、携帯機器100の駆動に必要なデータ/パラメータ/プログラム/コード/命令を格納することができる。また、メモリ部130は、入/出力されるデータ/情報等を格納することができる。電源供給部140aは、携帯機器100に電源を供給し、有/無線充電回路、バッテリーなどを含むことができる。インターフェース部140bは、携帯機器100と他の外部機器の連結をサポートすることができる。インターフェース部140bは、外部機器との連結のための様々なポート(例えば、オーディオの入/出力ポート、ビデオの入/出力ポート)を含むことができる。入出力部140cは、画像情報/信号、オーディオ情報/信号、データ、及び/またはユーザから入力される情報が入力されるか、出力することができる。入出力部140cは、カメラ、マイクロフォン、ユーザ入力部、ディスプレイ部140d、スピーカー及び/またはハプティックモジュールなどを含むことができる。
【0236】
[267] 一例として、データ通信の場合、入出力部140cは、ユーザから入力された情報/信号(例えば、タッチ、文字、音声、イメージ、ビデオ)を取得し、取得された情報/信号はメモリ部130に格納されることができる。通信部110は、メモリに格納された情報/信号を無線信号に変換し、変換された無線信号を他の無線機器に直接送信するか、基地局に送信できる。また、通信部110は、他の無線機器または基地局から無線信号を受信した後、受信された無線信号を元の情報/信号に復元できる。復元された情報/信号は、メモリ部130に格納された後、入出力部140cを介して様々な形態(例えば、文字、音声、イメージ、ビデオ、ハプティック)で出力されることができる。
【0237】
[268] 図28は、本開示の一実施例に係る、車両または自律走行車両を示す。車両または自律走行車両は、移動型ロボット、車両、汽車、有/無人飛行体(Aerial Vehicle、AV)、船舶などで具現されることができる。
【0238】
[269] 図28を参照すると、車両または自律走行車両100は、アンテナ部108、通信部110、制御部120、駆動部140a、電源供給部140b、センサ部140c、及び自律走行部140dを含むことができる。アンテナ部108は、通信部110の一部で構成されることができる。ブロック110/130/140a~140dは、各々、図26のブロック110/130/140に対応する。
【0239】
[270] 通信部110は、他の車両、基地局(例えば、基地局、路辺基地局(Road Side unit)等)、サーバなどの外部機器と信号(例えば、データ、制御信号等)を送受信することができる。制御部120は、車両または自律走行車両100の要素を制御し、様々な動作を行うことができる。制御部120は、ECU(Electronic Control Unit)を含むことができる。駆動部140aは、車両または自律走行車両100を地上で走行させることができる。駆動部140aは、エンジン、モータ、パワートレーン、輪、ブレーキ、ステアリングなどを含むことができる。電源供給部140bは、車両または自律走行車両100に電源を供給し、有/無線充電回路、バッテリーなどを含むことができる。センサ部140cは、車両状態、周辺環境情報、ユーザ情報等が得られる。センサ部140cは、IMU(inertial measurement unit)センサ、衝突センサ、ホイールセンサ(wheel sensor)、速度センサ、傾斜センサ、重量感知センサ、ヘッディングセンサ(heading sensor)、ポジションモジュール(position module)、車両の前進/後進センサ、バッテリーセンサ、燃料センサ、タイヤセンサ、ステアリングセンサ、温度センサ、湿度センサ、超音波センサ、照度センサ、ペダルポジションセンサなどを含むことができる。自律走行部140dは、走行中である車線を維持する技術、アダプティブ・クルーズ・コントロールのように速度を自動で調節する技術、決められた経路に沿って自動で走行する技術、目的地が設定されると、自動で経路を設定して走行する技術などを実現することができる。
【0240】
[271] 一例として、通信部110は、外部サーバから地図データ、交通情報データ等を受信することができる。自律走行部140dは、取得されたデータに基づいて自律走行経路とドライビングプランを生成することができる。制御部120は、ドライビングプランに従って、車両または自律走行車両100が自律走行経路に沿って移動するように駆動部140aを制御することができる(例えば、速度/方向調節)。自律走行の途中、通信部110は外部サーバから最新の交通情報データを非/周期的に取得し、周辺の車両から周辺の交通情報データを取得することができる。また、自律走行の途中、センサ部140cは、車両状態、周辺環境情報を取得することができる。自律走行部140dは、新たに取得されたデータ/情報に基づいて自律走行経路とドライビングプランを更新することができる。通信部110は、車両位置、自律走行経路、ドライビングプランなどに関する情報を外部サーバに伝達することができる。外部サーバは、車両または自律走行車両から収集された情報に基づいて、AI技術などを利用して交通情報データを予め予測することができ、予測された交通情報データを車両または自律走行車両に提供できる。
【0241】
[272] 図29は、本開示の一実施例に係る、車両を示す。車両は、運送手段、汽車、飛行体、船舶などで具現されることもできる。
【0242】
[273] 図29を参照すると、車両100は、通信部110、制御部120、メモリ部130、入出力部140a、及び位置測定部140bを含むことができる。ここで、ブロック110~130/140a~140bは、各々、図26のブロック110~130/140に対応する。
【0243】
[274] 通信部110は、他の車両、または基地局などの外部機器と信号(例えば、データ、制御信号等)を送受信することができる。制御部120は、車両100の構成要素を制御して様々な動作を行うことができる。メモリ部130は、車両100の様々な機能をサポートするデータ/パラメータ/プログラム/コード/命令を格納することができる。入出力部140aは、メモリ部130内の情報に基づいて、AR/VRオブジェクトを出力することができる。入出力部140aは、HUDを含むことができる。位置測定部140bは、車両100の位置情報を取得することができる。位置情報は、車両100の絶対位置情報、走行線内での位置情報、加速度情報、周辺車両との位置などを含むことができる。位置測定部140bは、GPS及び様々なセンサを含むことができる。
【0244】
[275] 一例として、車両100の通信部110は、外部サーバから地図情報、交通情報などを受信してメモリ部130に格納することができる。位置測定部140bは、GPS及び様々なセンサを介して、車両の位置情報を取得してメモリ部130に格納することができる。制御部120は、地図情報、交通情報、及び車両の位置情報等に基づいて仮想のオブジェクトを生成し、入出力部140aは、生成された仮想のオブジェクトを車両内のガラス窓に表示できる(1410、1420)。また、制御部120は、車両の位置情報に基づいて車両100が走行線内で正常に運行されているか判断できる。車両100が走行線を非正常に外れる場合、制御部120は、入出力部140aを介して車両内ガラス窓に警告を表示することができる。また、制御部120は、通信部110を介して、周辺の車両に走行異常に関する警告メッセージを放送することができる。状況に応じて、制御部120は通信部110を介して、関係機関に車両の位置情報と、走行/車両異常に関する情報を送信することができる。
【0245】
[276] 図30は、本開示の一実施例に係る、XR機器を示す。XR機器は、HMD、車両に備えられたHUD(Head-Up Display)、テレビ、スマートフォン、コンピュータ、ウェアラブルデバイス、家電機器、デジタルサイネージ(signage)、車両、ロボットなどで具現されることができる。
【0246】
[277] 図30を参照すると、XR機器100aは、通信部110、制御部120、メモリ部130、入出力部140a、センサ部140b、及び電源供給部140cを含むことができる。ここで、ブロック110~130/140a~140cは、各々、図26のブロック110~130/140に対応する。
【0247】
[278] 通信部110は、他の無線機器、携帯機器、またはメディアサーバなどの外部機器と信号(例えば、メディアデータ、制御信号等)を送受信することができる。メディアデータは、画像、イメージ、音などを含むことができる。制御部120は、XR機器100aの構成要素を制御し、様々な動作を行うことができる。例えば、制御部120は、ビデオ/イメージの取得、(ビデオ/イメージ)エンコーディング、メタデータの生成及び処理などの手続を制御及び/または実行するように構成されることができる。メモリ部130は、XR機器100aの駆動/XRオブジェクトの生成に必要なデータ/パラメータ/プログラム/コード/命令を格納することができる。入出力部140aは外部から制御情報、データ等を取得し、生成されたXRオブジェクトを出力することができる。入出力部140aは、カメラ、マイクロフォン、ユーザ入力部、ディスプレイ部、スピーカ及び/またはハプティックモジュールなどを含むことができる。センサ部140bは、XR機器の状態、周辺環境情報、ユーザ情報等が得られる。センサ部140bは、近接センサ、照度センサ、加速度センサ、磁気センサ、ジャイロセンサ、慣性センサ、RGBセンサ、IRセンサ、指紋認識センサ、超音波センサ、光センサ、マイクロフォン、及び/またはレーダー等を含むことができる。電源供給部140cは、XR機器100aに電源を供給し、有/無線充電回路、バッテリーなどを含むことができる。
【0248】
[279] 一例として、XR機器100aのメモリ部130は、XRオブジェクト(例えば、AR/VR/MRオブジェクト)の生成に必要な情報(例えば、データ等)を含むことができる。入出力部140aは、ユーザからXR機器100aを操作する命令を取得することができ、制御部120は、ユーザの駆動命令によってXR機器100aを駆動させることができる。例えば、ユーザがXR機器100aを介して、映画、ニュース等を視聴しようとする場合、制御部120は、通信部130を介してコンテンツ要求情報を他の機器(例えば、携帯機器100b)またはメディアサーバに送信できる。通信部130は、他の機器(例えば、携帯機器100b)またはメディアサーバから映画、ニュース等のコンテンツをメモリ部130にダウンロード/ストリーミングを受けることができる。制御部120は、コンテンツに対してビデオ/イメージ取得、(ビデオ/イメージ)エンコーディング、メタデータの生成/処理などの手続を制御及び/または実行し、入出力部140a/センサ部140bを介して取得した周辺空間または現実のオブジェクトに対する情報に基づいて、XRオブジェクトを生成/出力することができる。
【0249】
[280] また、XR機器100aは、通信部110を介して携帯機器100bと無線で連結され、XR機器100aの動作は携帯機器100bにより制御されることができる。例えば、携帯機器100bは、XR機器100aに対するコントローラとして動作できる。このために、XR機器100aは携帯機器100bの3次元の位置情報を取得した後、携帯機器100bに対応するXR個体を生成して出力することができる。
【0250】
[281] 図31は、本開示の一実施例に係る、ロボットを示す。ロボットは、使用目的や分野によって、産業用、医療用、家庭用、軍事用等に分類されることができる。
【0251】
[282] 図31を参照すると、ロボット100は、通信部110、制御部120、メモリ部130、入出力部140a、センサ部140b、及び駆動部140cを含むことができる。ここで、ブロック110~130/140a~140cは、各々、図26のブロック110~130/140に対応する。
【0252】
[283] 通信部110は、他の無線機器、他のロボット、または制御サーバなどの外部機器と信号(例えば、駆動情報、制御信号等)を送受信することができる。制御部120は、ロボット100の構成要素を制御して様々な動作を行うことができる。メモリ部130は、ロボット100の様々な機能をサポートするデータ/パラメータ/プログラム/コード/命令を格納することができる。入出力部140aは、ロボット100の外部から情報を取得し、ロボット100の外部に情報を出力することができる。入出力部140aは、カメラ、マイクロフォン、ユーザ入力部、ディスプレイ部、スピーカ及び/またはハプティックモジュールなどを含むことができる。センサ部140bは、ロボット100の内部情報、周辺環境情報、ユーザ情報等が得られる。センサ部140bは、近接センサ、照度センサ、加速度センサ、磁気センサ、ジャイロセンサ、慣性センサ、IRセンサ、指紋認識センサ、超音波センサ、光センサ、マイクロフォン、レーダー等を含むことができる。駆動部140cは、ロボットの関節を動くなどの様々な物理的動作を行うことができる。また、駆動部140cは、ロボット100を地上で走行するか、空中で飛行させることができる。駆動部140cはアクチュエータ、モータ、輪、ブレーキ、プロペラなどを含むことができる。
【0253】
[284] 図32は、本開示の一実施例に係る、AI機器を示す。AI機器は、TV、プロジェクター、スマートフォン、PC、ノートブック、デジタル放送用端末機、タブレートPC、ウェアラブル装置、セットトップボックス(STB)、ラジオ、洗濯機、冷蔵庫、デジタルサイネージ、ロボット、車両などのような、固定型機器または移動可能な機器などで具現されることができる。
【0254】
[285] 図32を参照すると、AI機器100は、通信部110、制御部120、メモリ部130、入/出力部140a/140b、ラーニングプロセッサ部140c、及びセンサ部140dを含むことができる。ブロック110~130/140a~140dは、各々、図26のブロック110~130/140に対応する。
【0255】
[286] 通信部110は、有無線通信技術を利用して他のAI機器(例えば、図23、100x、200、400)やAIサーバ(例えば、図23の400)などの外部機器と有無線信号(例えば、センサ情報、ユーザ入力、学習モデル、制御信号等)を送受信することができる。このために、通信部110は、メモリ部130内の情報を外部機器に送信し、または外部機器から受信された信号をメモリ部130に伝達できる。
【0256】
[287] 制御部120は、データ分析のアルゴリズムまたはマシンラーニングのアルゴリズムを使用して決定されるか、生成された情報に基づいて、AI機器100の少なくとも一つの実行可能な動作を決定することができる。また、制御部120は、AI機器100の構成要素を制御し、決定された動作を行うことができる。例えば、制御部120は、ラーニングプロセッサ部140cまたはメモリ部130のデータを要求、検索、受信または活用することができ、少なくとも一つの実行可能な動作中予測される動作や、好ましいと判断される動作を実行するようにAI機器100の構成要素を制御することができる。また、制御部120は、AI装置100の動作内容や動作に対するユーザのフィードバックなどを含む履歴情報を収集してメモリ部130またはラーニングプロセッサ部140cに格納するか、AIサーバ400(図23)等の外部装置に送信できる。収集された履歴情報は、学習モデルを更新するのに利用されることができる。
【0257】
[288] メモリ部130は、AI機器100の様々な機能をサポートするデータを格納することができる。例えば、メモリ部130は入力部140aから得たデータ、通信部110から得たデータ、ラーニングプロセッサ部140cの出力データ、及びセンシング部140から得たデータを格納することができる。また、メモリ部130は、制御部120の動作/実行に必要な制御情報及び/またはソフトウェアコードを格納することができる。
【0258】
[289] 入力部140aは、AI機器100の外部から様々な種類のデータを取得することができる。例えば、入力部140aは、モデル学習のための学習データ、及び学習モデルが適用される入力データ等を取得することができる。入力部140aは、カメラ、マイクロフォン、及び/またはユーザ入力部などを含むことができる。出力部140bは、視覚、聴覚、または触覚等に関する出力を発生させることができる。出力部140bは、ディスプレイ部、スピーカー、及び/またはハプティックモジュールなどを含むことができる。センシング部140は、様々なセンサを用いてAI機器100の内部情報、AI機器100の周辺環境情報、及びユーザ情報のうち少なくとも一つが得られる。センシング部140は、近接センサ、照度センサ、加速度センサ、磁気センサ、ジャイロセンサ、慣性センサ、RGBセンサ、IRセンサ、指紋認識センサ、超音波センサ、光センサ、マイクロフォン、及び/またはレーダー等を含むことができる。
【0259】
[290] ラーニングプロセッサ部140cは、学習データを用いて、人工神経網で構成されたモデルを学習させることができる。ラーニングプロセッサ部140cは、AIサーバ400(図23)のラーニングプロセッサ部と共にAIプロセシングを行うことができる。ラーニングプロセッサ部140cは、通信部110を介して、外部機器から受信された情報、及び/またはメモリ部130に格納された情報を処理することができる。また、ラーニングプロセッサ部140cの出力値は、通信部110を介して外部機器に送信されるか/送信され、メモリ部130に格納されることができる。
【0260】
[291] 本明細書に記載された請求項は、多様な方式に組み合わせ可能である。例えば、本明細書の方法請求項の技術的特徴が組み合わせられて装置で具現されることができ、本明細書の装置請求項の技術的特徴が組み合わせられて方法で具現されることができる。また、本明細書の方法請求項の技術的特徴と装置請求項の技術的特徴が組み合わせられて装置で具現されることができ、本明細書の方法請求項の技術的特徴と装置請求項の技術的特徴が組み合わせられて方法で具現されることができる。
図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