▶ サムスン エレクトロニクス カンパニー リミテッドの特許一覧
特表2023-515093Ｖ２Ｘシステムで端末の間の協力を通じるリソース割り当て方法及び装置
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-04-12
(54)【発明の名称】Ｖ２Ｘシステムで端末の間の協力を通じるリソース割り当て方法及び装置
(51)【国際特許分類】
H04W 72/25 20230101AFI20230405BHJP
H04W 92/18 20090101ALI20230405BHJP
H04W 72/563 20230101ALI20230405BHJP
H04W 72/0453 20230101ALI20230405BHJP
【ＦＩ】
H04W72/25
H04W92/18
H04W72/563
H04W72/0453
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2022550010
(86)(22)【出願日】2021-02-22
(85)【翻訳文提出日】2022-08-19
(86)【国際出願番号】 KR2021002206
(87)【国際公開番号】W WO2021167427
(87)【国際公開日】2021-08-26
(31)【優先権主張番号】10-2020-0021249
(32)【優先日】2020-02-20
(33)【優先権主張国・地域又は機関】KR
(81)【指定国・地域】
(71)【出願人】
【識別番号】503447036
【氏名又は名称】サムスン エレクトロニクス カンパニー リミテッド
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100154922
【弁理士】
【氏名又は名称】崔 允辰
(72)【発明者】
【氏名】チョルキュ・シン
(72)【発明者】
【氏名】ヒョンソク・リュ
(72)【発明者】
【氏名】ジョンホ・ヨ
(72)【発明者】
【氏名】サンヨブ・ジュン
(72)【発明者】
【氏名】スンジン・パク
(72)【発明者】
【氏名】ジョンヒョン・バン
(72)【発明者】
【氏名】ジンヨン・オ
【テーマコード（参考）】
5K067
【Ｆターム（参考）】
5K067AA21
5K067CC02
5K067DD11
5K067EE02
5K067EE25
(57)【要約】
本開示は、４Ｇシステム以後より高いデータ送信率をサポートするための５Ｇ通信システムをＩｏＴ技術とコンバージェンスする通信技法及びそのシステムに関する。本開示は５Ｇ通信技術及びＩｏＴ関連技術に基づいて知能型サービス（例えば、スマートホーム、スマートビルディング、スマートシティ、スマートカー又はコネクテッドカー、ヘルスケア、デジタル教育、スマート小売り、保安及び安全サービスなど）に適用されることができる。本開示の一実施例による通信システムの第１端末の方法は、第２端末とリソースプール（ｒｅｓｏｕｒｃｅ ｐｏｏｌ）に対する情報を共有する段階と、前記第２端末からリソース割り当て情報に対するリクエストを受信する段階と、及び前記第２端末と共有されたリソースプールに係る少なくとも一つのリソースを指示するリソース割り当て情報を前記第２端末で送信する段階と、を含むことができる。
【特許請求の範囲】
【請求項1】
通信システムの第１端末の方法であって、第２端末とリソースプール（ｒｅｓｏｕｒｃｅ ｐｏｏｌ）に対する情報を共有する段階と、
前記第２端末からリソース割り当て情報に対するリクエストを受信する段階と、及び
前記第２端末と共有されたリソースプールに係る少なくとも一つのリソースを指示するリソース割り当て情報を前記第２端末で送信する段階と、を含む方法。
【請求項2】
前記第２端末と複数個のリソースプールが共有された場合、前記複数個のリソースプールのうちの少なくとも一つのリソースプールを指示するための情報を前記第２端末に送信する段階をさらにと含み、前記複数個のリソースプールのうちの少なくとも一つのリソースプールはＣＢＲ（ｃｈａｎｎｅｌ ｂｕｓｙ ｒａｔｉｏ）に基づいて決定されることを特徴とする、請求項１に記載の方法。
【請求項3】
優先順位情報、残りのパケット遅延バジェット（ｒｅｍａｉｎｉｎｇ ｐａｃｋｅｔ ｄｅｌａｙ ｂｕｄｇｅｔ）、バッファー状態報告、ＨＡＲＱ ｆｅｅｄｂａｃｋ認可するかどうか、及び周波数上の連続されるサブチャンネルの数に対する情報のうちの少なくとも一つを前記第２端末から受信する段階をさらに含み、前記リソース割り当て情報は前記第２端末から受信した情報に基づいて決定されることを特徴とする、請求項１に記載の方法。
【請求項4】
前記リソース割り当て情報は、少なくとも一つの送信ブロックに対する初期リソースの位置情報及び再送信リソースの位置情報を含むことを特徴とする、請求項１に記載の方法。
【請求項5】
通信システムの第２端末の方法であって、第１端末とリソースプール（ｒｅｓｏｕｒｃｅ ｐｏｏｌ）に対する情報を共有する段階と、
前記第１端末でリソース割り当て情報に対するリクエストを送信する段階と、及び
前記第１端末と共有されたリソースプールに係る少なくとも一つのリソースを指示するリソース割り当て情報を前記第１端末から受信する段階と、を含む、方法。
【請求項6】
前記第１端末と複数個のリソースプールが共有された場合、前記複数個のリソースプールのうちの少なくとも一つのリソースプールを指示するための情報を前記第１端末から受信する段階をさらに含み、前記複数個のリソースプールのうちの少なくとも一つのリソースプールはＣＢＲ（ｃｈａｎｎｅｌ ｂｕｓｙ ｒａｔｉｏ）に基づいて決定されることを特徴とする、請求項５に記載の方法。
【請求項7】
優先順位情報、残りのパケット遅延バジェット（ｒｅｍａｉｎｉｎｇ ｐａｃｋｅｔ ｄｅｌａｙ ｂｕｄｇｅｔ）、バッファー状態報告、ＨＡＲＱ ｆｅｅｄｂａｃｋ認可するかどうか、及び周波数上の連続されるサブチャンネルの数に対する情報のうちの少なくとも一つを前記第１端末で送信する段階をさらに含み、前記リソース割り当て情報は前記第１端末で送信された情報に基づいて決定されることを特徴とする、請求項５に記載の方法。
【請求項8】
前記リソース割り当て情報は、少なくとも一つの送信ブロックに対する初期リソースの位置情報及び再送信リソースの位置情報を含むことを特徴とする、請求項５に記載の方法。
【請求項9】
通信システムの第１端末であって、送受信部と、及び
第２端末とリソースプール（ｒｅｓｏｕｒｃｅ ｐｏｏｌ）に対する情報を共有し、前記第２端末からリソース割り当て情報に対するリクエストを受信し、前記第２端末と共有されたリソースプールに係る少なくとも一つのリソースを指示するリソース割り当て情報を前記第２端末で送信するように構成される制御部と、を含む、第１端末。
【請求項10】
前記制御部は前記第２端末と複数個のリソースプールが共有された場合、前記複数個のリソースプールのうちの少なくとも一つのリソースプールを指示するための情報を前記第２端末に送信するようにさらに構成され、前記複数個のリソースプールのうちの少なくとも一つのリソースプールはＣＢＲ（ｃｈａｎｎｅｌ ｂｕｓｙ ｒａｔｉｏ）に基づいて決定されることを特徴とする、請求項９に記載の第１端末。
【請求項11】
前記制御部は優先順位情報、残りのパケット遅延バジェット（ｒｅｍａｉｎｉｎｇ ｐａｃｋｅｔ ｄｅｌａｙ ｂｕｄｇｅｔ）、バッファー状態報告、ＨＡＲＱ ｆｅｅｄｂａｃｋ認可するかどうか、及び周波数上の連続されるサブチャンネルの数に対する情報のうちの少なくとも一つを前記第２端末から受信するようにさらに構成され、前記リソース割り当て情報は前記第２端末から受信した情報に基づいて決定されることを特徴とする、請求項９に記載の第１端末。
【請求項12】
前記リソース割り当て情報は、少なくとも一つの送信ブロックに対する初期リソースの位置情報及び再送信リソースの位置情報を含むことを特徴とする、請求項９に記載の第１端末。
【請求項13】
通信システムの第２端末であって、送受信部と、及び
第１端末とリソースプール（ｒｅｓｏｕｒｃｅ ｐｏｏｌ）に対する情報を共有し、前記第１端末でリソース割り当て情報に対するリクエストを送信し、前記第１端末と共有されたリソースプールに係る少なくとも一つのリソースを指示するリソース割り当て情報を前記第１端末から受信するように構成される制御部と、を含む、第２端末。
【請求項14】
前記制御部は前記第１端末と複数個のリソースプールが共有された場合、前記複数個のリソースプールのうちの少なくとも一つのリソースプールを指示するための情報を前記第１端末から受信するようにさらに構成され、前記複数個のリソースプールのうちの少なくとも一つのリソースプールはＣＢＲ（ｃｈａｎｎｅｌ ｂｕｓｙ ｒａｔｉｏ）に基づいて決定されることを特徴とする、請求項１３に記載の第２端末。
【請求項15】
前記制御部は優先順位情報、残りのパケット遅延バジェット（ｒｅｍａｉｎｉｎｇ ｐａｃｋｅｔ ｄｅｌａｙ ｂｕｄｇｅｔ）、バッファー状態報告、ＨＡＲＱ ｆｅｅｄｂａｃｋ認可するかどうか、及び周波数上の連続されるサブチャンネルの数に対する情報のうちの少なくとも一つを前記第１端末で送信するようにさらに構成され、前記リソース割り当て情報は前記第１端末で送信された情報に基づいて決定されることを特徴とする、請求項１３に記載の第２端末。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、無線移動通信システムに関し、特に、 Ｖ２Ｘ (ｖｅｈｉｃｌｅ－ｔｏ－ｅｖｅｒｙｔｈｉｎｇ）をサポートする車両端末が他の車両端末及び歩行者の携帯端末とサイドリンクを用いて情報を送受信する過程で端末の間の協力を介してリソース割り当て（Ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ）を行う方法及び装置に関する。
【背景技術】
【0002】
４Ｇ通信システム商用化以後の増加趨勢にある無線データトラフィック需要を満たすために、改善された５Ｇ通信システム又はｐｒｅ－５Ｇ通信システムを開発するための努力が行われている。このような理由で、５Ｇ通信システム又はｐｒｅ－５Ｇ通信システムは４Ｇネットワーク以後（Ｂｅｙｏｎｄ ４Ｇ Ｎｅｔｗｏｒｋ）通信システム又はＬＴＥシステム以後（Ｐｏｓｔ ＬＴＥ）システムと呼ばれている。高いデータ送信率を達成するために、５Ｇ通信システムは超高周波(ｍｍＷａｖｅ）帯域(例えば、６０ギガ(６０ＧＨｚ）帯域のような）での具現が考慮されている。超高周波の帯域での伝播の経路損失緩和及び伝達距離を増加させるために、５Ｇ通信システムではビームフォーミング（ｂｅａｍｆｏｒｍｉｎｇ）、ｍａｓｓｉｖｅ ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ－Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ－Ｏｕｔｐｕｔ）、ＦＤ－ＭＩＭＯ（Ｆｕｌｌ Ｄｉｍｅｎｓｉｏｎａｌ ＭＩＭＯ）、アレイアンテナ(ａｒｒａｙ ａｎｔｅｎｎａ）、アナログビームフォーミング(ａｎａｌｏｇ ｂｅａｍ－ｆｏｒｍｉｎｇ）、及び大規模アンテナ(ｌａｒｇｅ ｓｃａｌｅ ａｎｔｅｎｎａ）技術が論議されている。さらに、システムのネットワーク改善のために、５Ｇ通信システムでは進化された小型セル、改善された小型セル(ａｄｖａｎｃｅｄ ｓｍａｌｌ ｃｅｌｌ）、クラウド無線アクセスネットワーク(ｃｌｏｕｄ ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ：ｃｌｏｕｄ ＲＡＮ）、超高密度ネットワーク(ｕｌｔｒａ－ｄｅｎｓｅ ｎｅｔｗｏｒｋ）、Ｄ２Ｄ通信（Ｄｅｖｉｃｅ－ｔｏ－Ｄｅｖｉｃｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）、無線バックホール(ｗｉｒｅｌｅｓｓ ｂａｃｋｈａｕｌ）、移動ネットワーク（ｍｏｖｉｎｇ ｎｅｔｗｏｒｋ）、協力通信（ｃｏｏｐｅｒａｔｉｖｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）、ＣｏＭＰ（Ｃｏｏｒｄｉｎａｔｅｄ Ｍｕｌｔｉ－Ｐｏｉｎｔｓ）、及び受信干渉除去（ｉｎｔｅｒｆｅｒｅｎｃｅ ｃａｎｃｅｌｌａｔｉｏｎ）などの技術開発が行われている。その他にも、５Ｇシステムでは進歩されたコーディング変調(Ａｄｖａｎｃｅｄ Ｃｏｄｉｎｇ Ｍｏｄｕｌａｔｉｏｎ：ＡＣＭ）方式である ＦＱＡＭ（Ｈｙｂｒｉｄ ＦＳＫ ａｎｄ ＱＡＭ Ｍｏｄｕｌａｔｉｏｎ）及びＳＷＳＣ（Ｓｌｉｄｉｎｇ Ｗｉｎｄｏｗ Ｓｕｐｅｒｐｏｓｉｔｉｏｎ Ｃｏｄｉｎｇ）と、進歩された接続技術であるＦＢＭＣ（Ｆｉｌｔｅｒ Ｂａｎｋ Ｍｕｌｔｉ Ｃａｒｒｉｅｒ）、ＮＯＭＡ（ｎｏｎ ｏｒｔｈｏｇｏｎａｌ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）、及びＳＣＭＡ（ｓｐａｒｓｅ ｃｏｄｅ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）などが開発されている。
【0003】
一方、インターネットは人間が情報を生成して消費する人間中心の接続網から、事物などの分散された構成要素の間に情報を交換して処理するＩＯＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ、モノのインターネット）網へ進化しつつある。クラウドサーバーなどとの接続を通じたビッグデータ（Ｂｉｇ ｄａｔａ）処理技術などがＩｏＴ技術に結合されたＩｏＥ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｅｖｅｒｙｔｈｉｎｇ）技術も台頭している。ＩｏＴを具現するには、センシング技術、有無線通信及びネットワークインフラ、サービスインタフェース技術、セキュリティ技術のような技術要素が要求され、近年には物事の間の接続のためのセンサネットワーク（ｓｅｎｓｏｒ ｎｅｔｗｏｒｋ）、Ｍ２Ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）、ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などの技術が研究されている。ＩｏＴ環境は接続された事物の間に生成されるデータを収集、分析して人間の生活に新しい価値を創出する知能型ＩＴ（Ｉｎｔｅｒｎｅｔ Ｔｅｃｈｎｏｌｏｇｙ）サービスが提供されている。ＩｏＴは既存のＩＴ（ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ）技術と多様な産業の間のコンバージェンス及び複合を介してスマートホーム、スマートビルディング、スマートシティ、スマートカー又はコネクテッドカー、スマートグリド、ヘルスケア、スマート家電、先端医療サービスなどの分野に適用されている。
【0004】
これによって、５Ｇ通信システムをＩｏＴ網に適用するための多様な試みが行われている。例えば、センサネットワーク（ｓｅｎｓｏｒ ｎｅｔｗｏｒｋ）、Ｍ２Ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）、ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などの５Ｇ通信技術がビームフォーミング、ＭＩＭＯ、及びアレイアンテナなどの技法によって具現されることができる。前述のビッグデータ処理技術としてクラウド無線アクセスネットワーク（ｃｌｏｕｄ ＲＡＮ）が応用されることも５Ｇ技術とＩｏＴ技術のコンバージェンスの例と見なされることができる
【発明の概要】
【発明が解決しようとする課題】
【0005】
本発明は、無線通信システムに関し、Ｖ２Ｘをサポートする車両端末が他の車両端末及び歩行者の携帯端末とサイドリンクを用いて情報を取り交わす過程で端末の間の協力を介して送信リソースを割り当てる方法及び装置に関する。具体的に、端末の間の協力のために情報を取り交わす方法と、これを介してサイドリンク送信リソースを割り当てる方法、及びこれに対する基地局及び端末動作に関する。
【課題を解決するための手段】
【0006】
前記のような問題点を解決するための本開示の一実施例による通信システムの第１端末の方法は、第２端末とリソースプール（ｒｅｓｏｕｒｃｅ ｐｏｏｌ）に対する情報を共有する段階と、前記第２端末からリソース割り当て情報に対するリクエストを受信する段階と、及び前記第２端末と共有されたリソースプールに係る少なくとも一つのリソースを指示するリソース割り当て情報を前記第２端末で送信する段階と、を含むことができる。
【0007】
一実施例によれば、前記方法は、前記第２端末と複数個のリソースプールが共有された場合、前記複数個のリソースプールのうちの少なくとも一つのリソースプールを指示するための情報を前記第２端末に送信する段階をさらに含み、前記複数個のリソースプールのうちの少なくとも一つのリソースプールはＣＢＲ（ｃｈａｎｎｅｌ ｂｕｓｙ ｒａｔｉｏ）に基づいて決定されることができる。
【0008】
一実施例によれば、前記方法は、優先順位情報、残りのパケット遅延バジェット（ｒｅｍａｉｎｉｎｇ ｐａｃｋｅｔ ｄｅｌａｙ ｂｕｄｇｅｔ）、バッファー状態報告、ＨＡＲＱ ｆｅｅｄｂａｃｋ認可するかどうか、及び周波数上の連続されるサブチャンネルの数に対する情報のうちの少なくとも一つを前記第２端末から受信する段階をさらに含み、前記リソース割り当て情報は前記第２端末から受信した情報に基づいて決定されることができる。
【0009】
一実施例によれば、前記リソース割り当て情報は、少なくとも一つの送信ブロックに対する初期リソースの位置情報及び再送信リソースの位置情報を含むことができる。
【0010】
本開示の一実施例による通信システムの第２端末の方法は、第１端末とリソースプール（ｒｅｓｏｕｒｃｅ ｐｏｏｌ）に対する情報を共有する段階と、前記第１端末でリソース割り当て情報に対するリクエストを送信する段階と、及び前記第１端末と共有されたリソースプールに係る少なくとも一つのリソースを指示するリソース割り当て情報を前記第１端末から受信する段階と、を含むことができる。
【0011】
本開示の一実施例による通信システムの第１端末は、送受信部と、及び第２端末とリソースプール（ｒｅｓｏｕｒｃｅ ｐｏｏｌ）に対する情報を共有し、前記第２端末からリソース割り当て情報に対するリクエストを受信し、前記第２端末と共有されたリソースプールに係る少なくとも一つのリソースを指示するリソース割り当て情報を前記第２端末で送信するように構成される制御部と、を含むことができる。
【0012】
本開示の一実施例による通信システムの第２端末は、送受信部と、及び第１端末とリソースプール（ｒｅｓｏｕｒｃｅ ｐｏｏｌ）に対する情報を共有し、前記第１端末でリソース割り当て情報に対するリクエストを送信し、前記第１端末と共有されたリソースプールに係る少なくとも一つのリソースを指示するリソース割り当て情報を前記第１端末から受信するように構成される制御部と、を含むことができる。
【発明の効果】
【0013】
本発明においてはサイドリンク通信で端末がリソース割り当てを行う手順を提案するためのことである。提案された方法を介してリソース割り当て（Ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ）の性能を向上させることができる。また、端末の端末の電力消費を最小化するのに効果的に用いられることができる。
【図面の簡単な説明】
【0014】
【図1】本開示の実施例によるシステムを示す図面である。
【図2】本開示の一実施例によるサイドリンクを介して行われるＶ２Ｘ通信方法を示す図面である。
【図3】本開示の一実施例によるサイドリンクの送信及び受信に用いられる時間及び周波数上でリソースのセット（集合）で定義されるリソースプール（ｒｅｓｏｕｒｃｅ ｐｏｏｌ）を示す図面である。
【図4】本開示の一実施例によって基地局がサイドリンクで送信リソースを割り当てる方法を示す図面である。
【図5】本開示の一実施例によるサイドリンクで端末がセンシングを介してサイドリンクの送信リソースを直接割り当てる方法を示す図面である。
【図6】本開示の一実施例によるサイドリンクでの一つのスロットにマッピングされた物理チャンネルのマッピング構造を示す図面である。
【図7】本開示の一実施例によってリソース割り当て関連情報を他の端末から提供されるために端末の間の協力を行うシナリオを示す図面である。
【図8】本開示の一実施例によるＵＥ－ＡがＵＥ－Ｂのリソース割り当てのためにリソース（再）割り当て及び再評価を行うのに必要なｓｅｎｓｉｎｇ ｗｉｄｏｗとｒｅｓｏｕｒｃｅ ｓｅｌｅｃｔｉｏｎ ｗｉｄｏｗを定義するための図面である。
【図9】本開示の一実施例によるサイドリンク通信で端末の間の協力を行う全体的なフローチャートを示す説明する図である。
【図10】本開示の一実施例による端末の構成を示すブロック図である。
【図11】本開示の一実施例による基地局の構成を示すブロック図である。
【発明を実施するための形態】
【0015】
以下、本開示の実施例を添付された図面を参照して詳細に説明する。
【0016】
実施例を説明するに当り本開示が属する技術分野によく知られており、本開示と直接的に関連がない技術内容に対しては説明を省略する。これは不必要な説明を省略することによって本開示の要旨を明瞭にしてより明確に伝達するためことである。
【0017】
同様の理由で添付図面において一部構成要素は誇張されたり省略されたり概略的に図示された。また、各構成要素のサイズは実際サイズを全的に反映することではない。各図面で同一又は対応する構成要素には同一な参照番号を付した。
【0018】
本開示の利点及び特徴、及びそれらを達成する方法は添付される図面と共に詳細に後述されている実施例を参考すれば明確になるだろう。しかし、本開示は以下で開示される実施例に限定されるのではなく互いに異なる多様な形態で具現されることができ、ただ、本実施例は本開示を完全にし、本開示が属する技術分野で通常の知識を有する者に開示の範疇を完全に知らせるために提供されることであり、本開示は請求項の範囲によって定義されるだけである。明細書全体にかけて同一参照番号は同一構成要素を称する。
【0019】
このとき、処理フローチャートの各ブロックとフローチャートの図面の組み合せは、コンピュータープログラムインストラクションによって行われることが理解できるだろう。これらコンピュータープログラムインストラクションは汎用コンピューター、特殊用コンピューター又はその他のプログラム可能なデータプロセッシング装備のプロセッサに搭載されることができるので、コンピューター又はその他のプログラム可能なデータプロセッシング装備のプロセッサを介して行われるそのインストラクションが、フローチャートブロックで説明された機能を行う手段を生成するようになる。これらコンピュータープログラムインストラクションは、特定方式で機能を具現するためにコンピューター又はその他のプログラム可能なデータプロセッシング装備を志向することができるコンピューター利用可能、又はコンピューター可読メモリーに記憶されることも可能であるので、そのコンピューター利用可能又はコンピューター可読メモリーに記憶されたインストラクションはフローチャートブロックで説明された機能を行うインストラクション手段を内包する製造品目を生産することも可能である。コンピュータープログラムインストラクションはコンピューター又はその他のプログラム可能なデータプロセッシング装備上に搭載されることも可能であるので、コンピューター又はその他のプログラム可能なデータプロセッシング装備上で一連の動作段階が行われ、コンピューターで実行されるプロセスを生成してコンピューター又はその他のプログラム可能なデータプロセッシング装備を行うインストラクションはフローチャートブロックで説明された機能を行うための段階を提供することも可能である。
【0020】
また、各ブロックは、特定された論理的機能を行うための１つ以上の実行可能なインストラクションを含むモジュール、セグメント又はコードの一部を示すことができる。また、幾つか代替実行例ではブロックで言及された機能が順序を外れて発生することも可能であることを注目しなければならない。例えば、接して示されている２つのブロックは、実は実質的に同時に行われることも可能で、又はそのブロックが時々該当する機能によって逆順で行われることも可能である。
【0021】
このとき、本実施形態に用いられる‘～部’という用語は、ソフトウェア又はＦＰＧＡ又はＡＳＩＣのようなハードウェア構成要素を意味し、‘～部’はどんな役目を行う。しかし、‘～部’は、ソフトウェア又はハードウェアに限定される意味ではない。‘～部’はアドレシングすることができる記憶媒体にあるように構成されることもでき、１つ又はその以上のプロセッサを再生させるように構成されることもできる。したがって、一例として‘～部’はソフトウェア構成要素、客体志向ソフトウェア構成要素、クラス構成要素及びタスク構成要素のような構成要素と、プロセス、関数、属性、プロシージャ、サブルーティン、プログラムコードのセグメント、ドライバー、ファームウエア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ、及び変数を含む。構成要素と‘～部’のうちで提供される機能はより小さい数の構成要素及び‘～部’に結合されたり追加的な構成要素と‘～部’でさらに分離されることができる。だけでなく、構成要素及び‘～部’はデバイス又は保安マルチメディアカード内の１つ又はその以上のＣＰＵを再生させるように具現されることもできる。また、実施例で‘～部’は一つ以上のプロセッサを含むことができる。
【0022】
本開示の実施例を具体的に説明するに当たり、移動通信規格標準化団体である３ＧＰＰ（登録商標）（３ｒｄ ｇｅｎｅｒａｔｉｏｎ ｐａｒｔｎｅｒｓｈｉｐ ｐｒｏｊｅｃｔ ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ）が開示している５Ｇ移動通信規格上の無線接続網Ｎｅｗ ＲＡＮ（ＮＲ）とコア網であるパケットコア（５Ｇ Ｓｙｓｔｅｍ、又は５Ｇ Ｃｏｒｅ Ｎｅｔｗｏｒｋ、若しくはＮＧ Ｃｏｒｅ：ｎｅｘｔ ｇｅｎｅｒａｔｉｏｎ ｃｏｒｅ）を主な対象とするが、本開示の主な要旨は類似の技術的背景を有するその他の通信システムにも本開示の範囲を大きく逸脱せず範囲で少しの変形で適用可能であり、これは本開示の技術分野で熟練された技術的知識を有する者の判断で可能になるだろう。
【0023】
５Ｇシステムでは、ネットワーク自動化のサポートのため、５Ｇネットワーク網で収集されたデータを分析して提供する機能を提供するネットワーク機能であるネットワークデータ収集及び分析関数（ｎｅｔｗｏｒｋ ｄａｔａ ｃｏｌｌｅｃｔｉｏｎ ａｎｄ ａｎａｌｙｓｉｓ ｆｕｎｃｔｉｏｎ、ＮＷＤＡＦ）が定義されることができる。ＮＷＤＡＦは５Ｇネットワークから情報を収集／記憶／分析し、その結果を不特定ネットワーク機能（ｎｅｔｗｏｒｋ ｆｕｎｃｔｉｏｎ、ＮＦ）に提供することができ、分析結果は各ＮＦで独立的に用いられることができる。
【0024】
以下、説明の便宜のために、３ＧＰＰ（登録商標）規格（５Ｇ、ＮＲ、ＬＴＥ又はこれと類似のシステムの規格）で定義している用語及び名称が一部用いられることができる。しかし、本開示が用語及び名称によって限定されることではなく、他の規格によるシステムにも同様に適用されることができる。
【0025】
また、以下の説明で用いられる接続ノード（ｎｏｄｅ）を識別するための用語、網客体（ｎｅｔｗｏｒｋ ｅｎｔｉｔｙ、ネットワークエンティティー）を指称する用語、メッセージを指称する用語、ネットワークエンティティーの間のインターフェースを指称する用語、多様な識別情報を指称する用語などは説明の便宜のために例示されたことである。したがって、本開示で用いる用語に限定されることではなく、同等な技術的意味を有する対象を指称する他の用語が用いられることができる。
【0026】
４Ｇ通信システム商用化以後の増加趨勢にある無線データトラフィック需要を満たすため、改善した５Ｇ通信システム（ＮＲ、Ｎｅｗ Ｒａｄｉｏ）を開発するための努力が行われている。高いデータ送信率を達成するために、５Ｇ通信システムは超高周波の帯域（ｍｍＷａｖｅ）帯域（例えば、２８ＧＨｚ周波数帯域のような）でのリソースも可能するようにデザインされた。超高周波帯域での伝播の経路損失緩和及び伝達距離を増加させるために、５Ｇ通信システムではビームフォーミング（ｂｅａｍｆｏｒｍｉｎｇ）、ｍａｓｓｉｖｅ ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ－Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ－Ｏｕｔｐｕｔ）、ＦＤ－ＭＩＭＯ（Ｆｕｌｌ Ｄｉｍｅｎｓｉｏｎａｌ ＭＩＭＯ）、アレイアンテナ(ａｒｒａｙ ａｎｔｅｎｎａ）、アナログビームフォーミング(ａｎａｌｏｇ ｂｅａｍ－ｆｏｒｍｉｎｇ）、及び大規模アンテナ(ｌａｒｇｅ ｓｃａｌｅ ａｎｔｅｎｎａ）技術が論議されている。その以外に５Ｇ通信システムではＬＴＥと異なり１５ｋＨｚを含み、３０ｋＨｚ、６０ｋＨｚ、１２０ｋＨｚなどの多様なサブキャリア間隔（ｓｕｂｃａｒｒｉｅｒ ｓｐａｃｉｎｇ）をリソースし、物理制御チャンネル（Ｐｈｙｓｉｃａｌ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）はＰｏｌａｒ Ｃｏｄｉｎｇを用い、物理データチャンネル（Ｐｈｙｓｉｃａｌ Ｄａｔａ Ｃｈａｎｎｅｌ）はＬＤＰＣ（Ｌｏｗ Ｄｅｎｓｉｔｙ Ｐａｒｉｔｙ Ｃｈｅｃｋ）を用いる。その以外にアップリンク送信のための波形（ｗａｖｅｆｏｒｍ）としてはＤＦＴ－Ｓ－ＯＦＤＭだけでなくＣＰ－ＯＦＤＭも用いられる。ＬＴＥはＴＢ（Ｔｒａｎｓｐｏｒｔ Ｂｌｏｃｋ）単位のＨＡＲＱ（Ｈｙｂｒｉｄ ＡＲＱ）再送信がリソースされた一方に５ＧはＣＢ（Ｃｏｄｅ Ｂｌｏｃｋ）を複数個が結ばれたＣＢＧ（Ｃｏｄｅ Ｂｌｏｃｋ Ｇｒｏｕｐ）基盤のＨＡＲＱ再送信を追加的にリソースすることができる。
【0027】
また、システムのネットワーク改善のために、５Ｇ通信システムでは進化された小型セル、改善した小型セル（ａｄｖａｎｃｅｄ ｓｍａｌｌ ｃｅｌｌ）、クラウド無線アクセスネットワーク（ｃｌｏｕｄ ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ：ｃｌｏｕｄ ＲＡＮ）、超高密度ネットワーク（ｕｌｔｒａ－ｄｅｎｓｅ ｎｅｔｗｏｒｋ）、Ｄ２Ｄ通信（Ｄｅｖｉｃｅ ｔｏ Ｄｅｖｉｃｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）、無線バックホール（ｗｉｒｅｌｅｓｓ ｂａｃｋｈａｕｌ）、車両通信ネットワーク（Ｖ２Ｘ（Ｖｅｈｉｃｌｅ ｔｏ Ｅｖｅｒｙｔｈｉｎｇ）ｎｅｔｗｏｒｋ）、協力通信（ｃｏｏｐｅｒａｔｉｖｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）、ＣｏＭＰ（Ｃｏｏｒｄｉｎａｔｅｄ Ｍｕｌｔｉ－Ｐｏｉｎｔｓ）、及び受信干渉除去（ｉｎｔｅｒｆｅｒｅｎｃｅ ｃａｎｃｅｌｌａｔｉｏｎ）などの技術開発が行われている。
【0028】
一方、インターネットは人間が情報を生成して消費する人間中心の接続網から、事物などの分散された構成要素の間で情報を交換して処理するＩＯＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ、モノのインターネット）網へ進化しつつある。クラウドサーバーなどとの接続を通じたビッグデータ（Ｂｉｇ ｄａｔａ）処理技術などがＩｏＴ技術に結合されたＩｏＥ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｅｖｅｒｙｔｈｉｎｇ）技術も台頭している。ＩｏＴを具現するには、センシング技術、有無線通信及びネットワークインフラ、サービスインタフェース技術、セキュリティ技術のような技術要素が要求され、近年には物事の間の接続のためのセンサネットワーク（ｓｅｎｓｏｒ ｎｅｔｗｏｒｋ）、Ｍ２Ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）、ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などの技術が研究されている。ＩｏＴ環境では接続された事物で生成されるデータを収集、分析して人間の生活に新しい価値を創出する知能型ＩＴ（Ｉｎｔｅｒｎｅｔ Ｔｅｃｈｎｏｌｏｇｙ）サービスが提供されることができる。ＩｏＴは既存のＩＴ（ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ）技術と多様な産業の間のコンバージェンス及び複合を介してスマートホーム、スマートビルディング、スマートシティ、スマートカー又はコネクテッドカー、スマートグリド、ヘルスケア、スマート家電、先端医療サービスなどの分野に応用されることができる。
【0029】
これによって、５Ｇ通信システムをＩｏＴ網に適用するための多様な試みが行われている。例えば、センサネットワーク（ｓｅｎｓｏｒ ｎｅｔｗｏｒｋ）、Ｍ２Ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）、ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などの技術が５Ｇ通信技術がビームフォーミング、ＭＩＭＯ、及びアレイアンテナなどの技法によって具現されることができる。前述のビッグデータ処理技術としてクラウド無線アクセスネットワーク（ｃｌｏｕｄ ＲＡＮ）が応用されることも５Ｇ技術とＩｏＴ技術のコンバージェンスの例と見なされることができる。このように通信システムにおいて複数のサービスがユーザに提供されることができ、このような複数のサービスをユーザに提供するために特徴に当たるように各サービスを同一な時区間内で提供することができる方法及びこれを用いた装置が要求される。５Ｇ通信システムで提供される多様なサービスが研究され、このうちの一つは低い遅延時間（ｌｏｗ ｌａｔｅｎｃｙ）及び高い信頼性（ｈｉｇｈ ｒｅｌｉａｂｉｌｉｔｙ）要求条件を満足させるサービスである。
【0030】
車両通信の場合、ＮＲ Ｖ２Ｘシステムでは端末と端末の間のユニキャスト（ｕｎｉｃａｓｔ）通信、グループキャスト（ｇｒｏｕｐｃａｓｔ）（又はマルチキャスト（ｍｕｌｔｉｃａｓｔ））通信及びブロードキャスト（ｂｒｏａｄｃａｓｔ）通信がサポートされる。また、ＮＲ Ｖ２Ｘは車両の道路走行に必要な基本的な安全情報送受信を目的とするＬＴＥ Ｖ２Ｘと異なり、グループ走行（Ｐｌａｔｏｏｎｉｎｇ）、進歩された走行（Ａｄｖａｎｃｅｄ Ｄｒｉｖｉｎｇ）、拡張センサー（Ｅｘｔｅｎｄｅｄ Ｓｅｎｓｏｒ）、遠隔走行（Ｒｅｍｏｔｅ Ｄｒｉｖｉｎｇ）のようにより進歩されたサービスを提供することを目標としている。また、ＮＲ Ｖ２Ｘシステムでは周期的なトラフィック及び非周期的なトラフィックをいずれも考慮して端末が直接センシングをしてサイドリンク送信リソースを割り当てる方法をサポートする。この時、リソース割り当て関連情報を他の端末から提供される方法を考慮することができる。リソース割り当て関連情報を他の端末から提供されることによってリソース割り当ての性能向上を期待することだけではなく端末の電力消費を減らすことができる。例えば、基地局はカバレッジの内に位置している端末からＣＢＲ（Ｃｈａｎｎｅｌ Ｂｕｓｙ Ｒａｔｉｏ）のようなチャンネルの混雑であるかどうかが報告されることができ、したがって、端末が基地局のカバレッジの内に位置している場合、基地局からサイドリンクの送信及び受信に用いられる時間及び周波数上でリソースのセット（集合）で定義されるリソースプール（ｒｅｓｏｕｒｃｅ ｐｏｏｌ）をよりよく設定されることができる。したがって、基地局のカバレッジの外に位置している端末が予め設定されているリソースプールでリソースを割り当てるより基地局カバレッジの内にある端末からリソース割り当て関連情報が提供される場合、リソース割り当ての性能向上を期待することができる。また他の例で、サイドリンクでグループ走行のような進歩されたサービスをサポートする場合にグループ走行で接続されたグループのリーダーノードが一つの特定ノードをコントロールするか特定の多数のノードからなるグループを同時にコントロールするための目的にリソース割り当て関連情報を提供するシナリオを考慮することができる。このような場合にグループの各ノードが各各のリソースを割り当てるよりリーダーノードがグループの状態をよりよく把握してリソース割り当て関連情報を提供してグループ走行の性能向上を期待することができる。だけでなく、端末がサイドリンク送信リソースの選択のためにセンシングを行うのに多くの電力が消耗するため、もし、他の端末がリソース割り当てを代わりに行う場合に端末の電力消耗を最小化できる。特に、歩行者携帯端末の場合には端末の電力消耗を最小化して送信リソースを割り当てる方法及び手順が必要なことがある。したがって、このような解決策を提供するための端末及び基地局動作が定義されなければならない。しかし、これに係る論議は全くない状態である。したがって、本発明ではリソース割り当て関連情報を他の端末から提供されるために端末の間の協力を行うための方法を提案する。
【0031】
本明細書の実施例は上述したシナリオをサポートするために提案されたことで、特に、サイドリンクで端末がセンシング及びリソース割り当てを行う手順（Ｍｏｄｅ２）に対する方法及び装置を提供することを目的とする。さらに、端末の電力消耗を最小化するためのＭｏｄｅ２方法を提案する。
【0032】
図１は、本開示の実施例によるシステムを示す図面である。
【0033】
図１の（ａ）はすべてのＶ２Ｘ端末（ＵＥ－１とＵＥ－２）が基地局のカバレッジの内に位置している場合（Ｉｎ－Ｃｏｖｅｒａｇｅ、ＩＣ）に対する例示を示す。すべてのＶ２Ｘ端末は基地局からダウンリンク（ｄｏｗｎｌｉｎｋ：ＤＬ）を介してデータ及び制御情報を受信するか基地局へアップリンク（ｕｐｌｉｎｋ：ＵＬ）を介してデータ及び制御情報を送信することができる。この時、データ及び制御情報はＶ２Ｘ通信のためのデータ及び制御情報であれば良い。データ及び制御情報は一般的なセルラー通信のためのデータ及び制御情報であっても良い。また、Ｖ２Ｘ端末はサイドリンク（Ｓｉｄｅｌｉｎｋ、ＳＬ）を介してＶ２Ｘ通信のためのデータ及び制御情報を送／受信することができる。
【0034】
図１の（ｂ）はＶ２Ｘ端末のうちのＵＥ－１は基地局のカバレッジの内に位置してＵＥ－２は基地局のカバレッジの外に位置する場合に対する例示を示す。すなわち、図１の（ｂ）は一部Ｖ２Ｘ端末（ＵＥ－２）が基地局のカバレッジの外に位置する部分カバレッジ（ｐａｒｔｉａｌ ｃｏｖｅｒａｇｅ、ＰＣ）に関する例示を示す。基地局のカバレッジの内に位置したＶ２Ｘ端末（ＵＥ－１）は基地局からダウンリンクを介してデータ及び制御情報を受信するか基地局でアップリンクを介してデータ及び制御情報を送信することができる。基地局のカバレッジの外に位置したＶ２Ｘ端末（ＵＥ－２）は基地局からダウンリンクを介してデータ及び制御情報を受信することができなく、基地局でアップリンクを介してデータ及び制御情報を送信することができない。Ｖ２Ｘ端末（ＵＥ－２）はＶ２Ｘ端末（ＵＥ－１）とサイドリンクを介してＶ２Ｘ通信のためのデータ及び制御情報を送／受信することができる。
【0035】
図１の（ｃ）はすべてのＶ２Ｘ端末が基地局のカバレッジの外（ｏｕｔ－ｏｆ ｃｏｖｅｒａｇｅ、ＯＯＣ）に位置した場合に対する例示を示す。したがって、Ｖ２Ｘ端末（ＵＥ－１、ＵＥ－２）は基地局からダウンリンクを介してデータ及び制御情報を受信することができなく、基地局でアップリンクを介してデータ及び制御情報を送信することができない。Ｖ２Ｘ端末（ＵＥ－１、ＵＥ－２）はサイドリンクを介してＶ２Ｘ通信のためのデータ及び制御情報を送／受信することができる。
【0036】
図１の（ｄ）は互いに異なるセルに位置したＶ２Ｘ端末（ＵＥ－１、ＵＥ－２）の間のＶ２Ｘ通信を行うシナリオに対する例示を示す。具体的に、図１の（ｄ）はＶ２Ｘ端末（ＵＥ－１、ＵＥ－２）が互いに異なる基地局に接続しているか（ＲＲＣ接続状態）キャンピングしている場合（ＲＲＣ接続解除状態、すなわち、ＲＲＣ ｉｄｌｅ状態）を示す。この時、Ｖ２Ｘ端末（ＵＥ－１）はＶ２Ｘ送信端末でＶ２Ｘ端末（ＵＥ－２）はＶ２Ｘ受信端末であれば良い。又は、Ｖ２Ｘ端末（ＵＥ－１）がＶ２Ｘ受信端末であり、Ｖ２Ｘ端末（ＵＥ－２）がＶ２Ｘ送信端末であっても良い。Ｖ２Ｘ端末（ＵＥ－１）は自分が接続した（又は自分がキャンピングしている）基地局からＳＩＢ（ｓｙｓｔｅｍ ｉｎｆｏｒｍａｔｉｏｎ ｂｌｏｃｋ）を受信することができ、Ｖ２Ｘ端末（ＵＥ－２）は自分が接続した（又は自分がキャンピングしている）他の基地局からＳＩＢを受信することができる。この時、前記ＳＩＢは既存のＳＩＢが用いられるか、若しくはＶ２Ｘのために別に定義されたＳＩＢが用いられることができる。また、Ｖ２Ｘ端末（ＵＥ－１）が受信したＳＩＢの情報とＶ２Ｘ端末（ＵＥ－２）が受信したＳＩＢの情報が互いに異なることができる。したがって、互いに異なるセルに位置した端末（ＵＥ－１、ＵＥ－２）の間のＶ２Ｘ通信を行うためには情報が統一されるか、これに対する情報がシグナリングされて互いに異なるセルから送信されたＳＩＢ情報を解釈方法が追加的に必要な場合がある。
【0037】
図１では説明の便宜のために２個のＶ２Ｘ端末（ＵＥ－１、ＵＥ－２）から構成されたＶ２Ｘシステムを示すが、ここに限らず、より多いＶ２Ｘ端末の間に通信が行うことができる。また、基地局とＶ２Ｘ端末とのインターフェース（アップリンク及びダウンリンク）はＵｕインターフェースで名付けることができ、Ｖ２Ｘ端末の間のサイドリンクはＰＣ５インターフェースで名付けることができる。したがって、本開示ではこれらを混用して用いることができる。一方、本開示で端末は車両の間の通信（ｖｅｈｉｃｕｌａｒ－ｔｏ－ｖｅｈｉｃｕｌａｒ、Ｖ２Ｖ）をサポートする車両、車両と歩行者の間の通信（ｖｅｈｉｃｕｌａｒ－ｔｏ－ｐｅｄｅｓｔｒｉａｎ、Ｖ２Ｐ）をサポートする車両又は歩行者のハンドセット（例えば、スマートフォン）、車両とネットワークの間の通信（ｖｅｈｉｃｕｌａｒ－ｔｏ－ｎｅｔｗｏｒｋ、Ｖ２Ｎ）をサポートする車両又は車両と交通インフラ（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）の間の通信（ｖｅｈｉｃｕｌａｒ－ｔｏ－ｉｎｆｒａｓｔｒｕｃｔｕｒｅ、Ｖ２Ｉ）をサポートする車両を含むことができる。また、本開示で端末は、端末機能を装着したＲＳＵ（ｒｏａｄ ｓｉｄｅ ｕｎｉｔ）、基地局機能を装着したＲＳＵ、又は基地局機能の一部及び端末機能の一部を装着したＲＳＵを含むことができる。
【0038】
また、本開示の一実施例よれば、基地局はＶ２Ｘ通信と一般セルラー通信をいずれもサポートする基地局であるか、Ｖ２Ｘ通信のみをサポートする基地局であっても良い。この時、基地局は５Ｇ基地局（ｇＮＢ）、４Ｇ基地局（ｅＮＢ）、又はＲＳＵであってもよい。したがって、本開示で基地局はＲＳＵと指称されることもできる。
【0039】
図２は、本開示の一実施例によるサイドリンクを介して行われるＶ２Ｘ通信方法を示す図面である。
【0040】
図２の（ａ）を参考すれば、ＵＥ－１（２０１、例えば、ＴＸ端末）とＵＥ－２（２０２、例えば、ＲＸ端末）が一対一で通信を行うことができ、これをユニキャスト（ｕｎｉｃａｓｔ）通信と名付けることができる。
【0041】
図２の（ｂ）を参考すれば、ＴＸ端末とＲＸ端末が一対一多で通信を行うことができ、これをグループキャスト（ｇｒｏｕｐｃａｓｔ）又はマルチキャスト（ｍｕｌｔｉｃａｓｔ）で名付けることができる。図２の（ｂ）でＵＥ－１（２１１）、ＵＥ－２（２１２）、及びＵＥ－３（２１３）は一つのグループ（ｇｒｏｕｐ）を形成して（Ｇｒｏｕｐ Ａ）グループキャスト（ｇｒｏｕｐｃａｓｔ）通信を行い、ＵＥ－４（２１４）、ＵＥ－５（２１５）、ＵＥ－６（２１６）、及びＵＥ－７（２１７）はまた他のグループ（ｇｒｏｕｐ）を形成して（Ｇｒｏｕｐ Ｂ）グループキャスト（ｇｒｏｕｐｃａｓｔ）通信を行うことができる。各端末は自分が属したグループ内にだけグループキャスト（ｇｒｏｕｐｃａｓｔ）通信を行い、互いに異なるグループの間の通信はユニキャスト、グループキャスト又はブロードキャスト通信を介して行われることができる。図２の（ｂ）では２つのグループ（Ｇｒｏｕｐ Ａ、Ｇｒｏｕｐ Ｂ）が形成されていることを示すが、これに限定されない。
【0042】
一方、図２に示されなかったが、Ｖ２Ｘ端末はブロードキャスト（ｂｒｏａｄｃａｓｔ） 通信を行うことができる。ブロードキャスト（ｂｒｏａｄｃａｓｔ）通信は、Ｖ２Ｘ送信端末がサイドリンクを介して送信したデータ及び制御情報をすべてのＶ２Ｘ端末が受信する場合を意味する。例えば、図２の（ｂ）でＵＥ－１（２１１）がブロードキャスト（ｂｒｏａｄｃａｓｔ）のための送信端末と仮定する場合、すべての端末（ＵＥ－２（２１２）、ＵＥ－３（２１３）、ＵＥ－４（２１４）、ＵＥ－５（２１５）、ＵＥ－６（２１６）、及びＵＥ－７（２１７））はＵＥ－１（２１１）が送信するデータ及び制御情報を受信することができる。
【0043】
ＮＲ Ｖ２ＸではＬＴＥ Ｖ２Ｘと異なり、車両端末がユニキャストを介して一つの特定ノードにだけデータを送信する形態及びグループキャスト（ｇｒｏｕｐｃａｓｔ）を介して特定多数のノードにデータを送信する形態のサポートが考慮されることができる。例えば、２台以上の車両を一つのネットワークで接続して群集形態に移動する技術者グループ走行（Ｐｌａｔｏｏｎｉｎｇ）のようなサービスシナリオでこのようなユニキャスト及びグループキャスト技術が有用に用いられることができる。具体的に、グループ走行で接続されたグループのリーダーノードが一つの特定ノードをコントロールするための目的にユニキャスト通信が必要なことがあって、特定多数のノードからなるグループを同時にコントロールするための目的にグループキャスト通信が必要なことがある。
【0044】
図３は、本開示の一実施例によるサイドリンクの送信及び受信に用いられる時間及び周波数上でリソースのセット（集合）で定義されるリソースプール（ｒｅｓｏｕｒｃｅ ｐｏｏｌ）を示す図面である。
【0045】
リソースプールで時間軸のリソース割り当て単位（ｒｅｓｏｕｒｃｅ ｇｒａｎｕｌａｒｉｔｙ）はスロット（Ｓｌｏｔ）されることができる。また、周波数軸のリソース割り当て単位は一つ以上のＰＲＢ（ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）から構成されたサブチャンネル（Ｓｕｂ－ｃｈａｎｎｅｌ）になることができる。
【0046】
リソースプールが時間及び周波数上で割り当てられた場合（３１０）に色が塗られた領域が時間及び周波数上でリソースプールと設定された領域を示す。本開示ではリソースプールが時間上で非連続的に割り当てられた場合の例を挙げて説明するが、時間上でリソースプールが連続的に割り当てられることもできる。また、本開示ではリソースプールが周波数上で連続的に割り当てられた場合の例えて説明するが、周波数上でリソースプールが非連続的に割り当てられる方法を排除しない。
【0047】
図３を参照すれば、リソースプールが時間上に非連続的に割り当てられた場合（３２０）が図示された。図３を参照すれば、時間上リソース割り当ての単位（ｇｒａｎｕｌａｒｉｔｙ）がスロット（ｓｌｏｔ）からなる場合を示す。具体的に、複数個のＯＦＤＭシンボルから構成された一つのスロットが時間軸のリソース割り当て基本単位になることができる。この時、前記スロットを構成するすべてのＯＦＤＭシンボルがサイドリンク送信に用いられることもでき、スロットを構成する一部のＯＦＤＭシンボルがサイドリンク送信に用いられることもできる。例えば、スロットの一部は基地局端末の間のＵｕインターフェースで用いられるダウンリンク／アップリンクで用いられることもできる。図３を参照すれば、色が塗られたスロットが時間上でリソースプールに含まれたスロットを示し、前記リソースプールで割り当てられたスロットは時間上リソースプール情報で（ｐｒｅ－）ｃｏｎｆｉｇｕｒａｔｉｏｎされることができる。例えば、時間上リソースプール情報はＳＩＢを介してビットマップに指示されることができる。
【0048】
図３を参照すれば、時間上に非連続的なリソースプールに属したｐｈｙｓｉｃａｌスロット３２０をｌｏｇｉｃａｌスロット３２１にマッピングすることができる。一般的に、ＰＳＳＣＨ（ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）リソースプールに属するスロットのセット（集合）は（ｔ０，ｔ１，．．．，ｔｉ，．．．，ｔＴｍａｘ）で示されることができる。
【0049】
図３を参照すれば、リソースプールが周波数上で連続的に割り当てられた場合（３３０）が示す。
【0050】
周波数軸でリソース割り当てはサブチャンネル（ｓｕｂ－ｃｈａｎｎｅｌ）３３１単位でから行うことができる。サブチャンネル３３１は一つ以上のＲＢから構成された周波数上のリソース割り当て単位で定義されることができる。すなわち、サブチャンネル３３１はＲＢの整数倍で定義されることができる。図３を参照すれば、サブチャンネル３３１は５個の連続的なＰＲＢから構成されることができ、サブチャンネルサイズ（ｓｉｚｅＳｕｂｃｈａｎｎｅｌ）は５個の連続的なＰＲＢのサイズであれば良い。ただ、図面に示された内容は本発明の一例だけで、サブチャンネルのサイズは異なるように設定されることができ、一つのサブチャンネルは連続的なＰＲＢから構成されることが一般的であるが、必ず連続的なＰＲＢで構成されなければならないことではない。サブチャンネル３３１はＰＳＳＣＨに対するリソース割り当ての基本単位になることができる。
【0051】
ｓｔａｒｔＲＢ－Ｓｕｂｃｈａｎｎｅｌ３３２はリソースプールで周波数上のサブチャンネル３３１の開始位置を指示することができる。周波数軸でリソース割り当てがサブチャンネル３３１単位からなる場合、サブチャンネル３３１が開始されるＲＢインデックス（ｓｔａｒｔＲＢ－Ｓｕｂｃｈａｎｎｅｌ、３３２）、サブチャンネル３３１がいくつのＲＢから構成されるかどうかの情報（ｓｉｚｅＳｕｂｃｈａｎｎｅｌ）、及びサブチャンネル３３１の総数（ｎｕｍＳｕｂｃｈａｎｎｅｌ）などに対する設定情報を介して周波数上のリソースが割り当てられることができる。この時のｓｔａｒｔＲＢ－Ｓｕｂｃｈａｎｎｅｌ、ｓｉｚｅＳｕｂｃｈａｎｎｅｌ、及びｎｕｍＳｕｂｃｈａｎｎｅｌなどに対する情報は周波数上のリソースプール情報で（ｐｒｅ－）ｃｏｎｆｉｇｕｒａｔｉｏｎされることができる。例えば、周波数リソースプール情報はＳＩＢを介して設定されて指示されることができる。
【0052】
図４は、本開示の一実施例によって基地局がサイドリンクで送信リソースを割り当てる方法を示す図面である。
【0053】
基地局がサイドリンクで送信リソースを割り当てる方法は以下でＭｏｄｅ１と指称する。Ｍｏｄｅ１はスケジューリングされたリソース割り当て（ｓｃｈｅｄｕｌｅｄ ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ）であれば良い。Ｍｏｄｅ１は基地局がＲＲＣ接続された端末にｄｅｄｉｃａｔｅｄスケジューリング方式でサイドリンク送信に用いられるリソースを割り当てる方法を示すことができる。Ｍｏｄｅ１の方法は基地局がサイドリンクのリソースを管理することができるため、干渉管理とリソースプールの管理に効果的である。
【0054】
図４を参照すれば、キャンプオン４０５している送信端末４０１及び受信端末４０２は基地局４０３からＳＬ－ＳＩＢ（ｓｉｄｅｌｉｎｋ ｓｙｓｔｅｍ ｉｎｆｏｒｍａｔｉｏｎ ｂｌｏｃｋ）を受信することができる（４１０）。ここで、受信端末４０２は送信端末４０１が送信するデータを受信する端末を示す。ＳＬ－ＳＩＢ情報にはサイドリンク送受信のためのサイドリンクリソースプール情報、センシング動作のためのパラメーター設定情報、サイドリンク同期を設定するための情報、又は互いに異なる周波数で動作するサイドリンク送受信のためのキャリア情報などが含まれることができる。
【0055】
送信端末４０１にＶ２Ｘのためのデータトラフィックが生成されると、送信端末４０１は基地局４０３とＲＲＣ接続されることができる（４２０）。ここで、端末と基地局の間のＲＲＣ接続をＵｕ－ＲＲＣと指称することができる。Ｕｕ－ＲＲＣ接続過程４２０は送信端末４０１のデータトラフィック生成以前に行われることもできる。また、Ｍｏｄｅ１では基地局４０３と受信端末４０２の間のＵｕ－ＲＲＣ接続過程４２０が行われた状態で送信端末がサイドリンクを介して受信端末で送信を行うことができる。これと異なり、Ｍｏｄｅ１では基地局４０３と受信端末４０２の間のＵｕ－ＲＲＣ接続過程４２０が行われない状態でも送信端末がサイドリンクを介して受信端末で送信を行うことができる。
【0056】
送信端末４０１は基地局４０３に受信端末４０２とＶ２Ｘ通信ができる送信リソースをリクエストすることができる（４３０）。この時、送信端末４０１は基地局４０３にアップリンク物理制御チャンネル（ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ、ＰＵＣＣＨ）、ＲＲＣメッセージ又はＭＡＣ ＣＥを用いてサイドリンク送信リソースをリクエストすることができる。一方、ＭＡＣ ＣＥは新しいフォーマット（少なくともＶ２Ｘ通信のためのバッファー状態報告であることを通知するインジケーターとＤ２Ｄ通信のためにバッファーされているデータのサイズに対する情報含み）のバッファー状態報告（ｂｕｆｆｅｒ ｓｔａｔｕｓ ｒｅｐｏｒｔ、ＢＳＲ）ＭＡＣ ＣＥなどであれば良い。また、送信端末４０１はアップリンク物理制御チャンネルを介して送信されるスケジューリングリクエスト（ｓｃｈｅｄｕｌｉｎｇ ｒｅｑｕｅｓｔ、ＳＲ）ビットを介してサイドリンクリソースをリクエストすることができる。
【0057】
次に、基地局４０３は送信端末４０１にＶ２Ｘ送信リソースを割り当てることができる。この時、基地局はｄｙｎａｍｉｃ ｇｒａｎｔ又はｃｏｎｆｉｇｕｒｅｄ ｇｒａｎｔ方式で送信リソースを割り当てることができる。
【0058】
先ず、ｄｙｎａｍｉｃ ｇｒａｎｔ方式の場合、基地局はＤＣＩ（ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）を介してＴＢ送信に対するリソースを割り当てることができる。ＤＣＩに含まれるサイドリンクスケジューリング情報としては初期送信及び再送信の送信時点及び周波数割り当て位置情報フィールドに係るパラメーターが含まれることができる。ｄｙｎａｍｉｃ ｇｒａｎｔ方式に対するＤＣＩはｄｙｎａｍｉｃ ｇｒａｎｔ方式であることを指示するようにＳＬ－Ｖ－ＲＮＴＩでスクランブリンされるＣＲＣ（ｃｙｃｌｉｃ ｒｅｄｕｎｄａｎｃｙ ｃｈｅｃｋ）を含むことができる。
【0059】
次に、ｃｏｎｆｉｇｕｒｅｄ ｇｒａｎｔ方式の場合、基地局はＵｕ－ＲＲＣを介してＳＰＳ（ｓｅｍｉ－ｐｅｒｓｉｓｔｅｎｔ ｓｃｈｅｄｕｌｉｎｇ）ｉｎｔｅｒｖａｌを設定することによってＴＢ送信に対するリソースを周期的に割り当てることができる。この時、基地局はＤＣＩを介して一つのＴＢに対するリソースを割り当てることができる。ＤＣＩに含まれる一つのＴＢに対するサイドリンクスケジューリング情報には初期送信及び再送信リソースの送信時点及び周波数割り当て位置情報と、関連するパラメーターが含まれることができる。ｃｏｎｆｉｇｕｒｅｄ ｇｒａｎｔ方式でリソースが割り当てられる場合、前記ＤＣＩによって一つのＴＢに対する初期送信及び再送信の送信時点（ｏｃｃａｓｉｏｎ）及び周波数割り当て位置が決定されることができ、次のＴＢに対するリソースはＵｕ－ＲＲＣを介して設定されたＳＰＳ ｉｎｔｅｒｖａｌ間隔で繰り返されることができる。ｃｏｎｆｉｇｕｒｅｄ ｇｒａｎｔ方式に対するＤＣＩはｃｏｎｆｉｇｕｒｅｄ ｇｒａｎｔ方式であることを指示するようにＳＬ－ＳＰＳ－Ｖ－ＲＮＴＩでスクランブリングされるＣＲＣを含むことができる。また、ｃｏｎｆｉｇｕｒｅｄ ｇｒａｎｔ（ＣＧ）方式はｔｙｐｅ１ ＣＧとｔｙｐｅ２ＣＧに区分されることができる。Ｔｙｐｅ２ＣＧの場合、ＤＣＩを介してｃｏｎｆｉｇｕｒｅｄ ｇｒａｎｔと設定されたリソースがａｃｔｉｖａｔｉｏｎ／ｄｅａｃｔｉｖａｔｉｏｎできる。
【0060】
したがって、Ｍｏｄｅ１の場合、基地局４０３はＰＤＣＣＨを通じるＤＣＩ送信で送信端末４０１に受信端末４０２とサイドリンク通信のためのスケジューリングを指示することができる（４４０）。
【0061】
ブロードキャスト送信の場合に送信端末４０１はサイドリンクに対するＲＲＣ設定４１５無しにブロードキャストでＰＳＣＣＨを介して受信端末４０２にＳＣＩ（１ｓｔ ｓｔａｇｅ）をブロードキャストできる（４６０）。また、送信端末４０１はＰＳＳＣＨを介して受信端末４０２にデータをブロードキャストできる（４８０）。ブロードキャスト送信の場合にはＰＳＳＣＨを通じるＳＣＩ送信（２ｎｄ ｓｔａｇｅ ＳＣＩ、４７０）が行われないこともある。
【0062】
これと異なり、ユニキャスト又はグループキャスト送信の場合に送信端末４０１は他の端末と一対一でＲＲＣ接続を行うこともできる。ここでＵｕ－ＲＲＣと区分して端末の間のＲＲＣ接続をＰＣ５－ＲＲＣ４１５と指称することができる。グループキャストの場合にもＰＣ５－ＲＲＣ４１５はグループにある端末と端末の間で個別的に接続されることができる。図４を参照すれば、ＰＣ５－ＲＲＣ４１５の接続がＳＬ－ＳＩＢの送信４１０以後の動作で図示されたがＳＬ－ＳＩＢの送信４１０以前又はＳＣＩの送信以前に常に行われることもできる。もし、端末の間のＲＲＣ接続が必要な場合にサイドリンクのＰＣ５－ＲＲＣ接続が行われて送信端末４０１はＰＳＣＣＨを介して受信端末４０２にＳＣＩ（１ｓｔ ｓｔａｇｅ）をユニキャスト又はグループキャストで送信することができる（４６０）。この時のＳＣＩのグループキャスト送信はグループＳＣＩで解釈されることもできる。また、送信端末４０１はＰＳＳＣＨを介して受信端末４０２にＳＣＩ（２ｎｄ ｓｔａｇｅ）をユニキャスト又はグループキャストで送信することができる（４７０）。この時の１ｓｔ ｓｔａｇｅ ＳＣＩにはリソース割り当てに係る情報、及び２ｎｄ ｓｔａｇｅ ＳＣＩにはその以外の制御情報が含まれることができる。また、送信端末４０１はＰＳＳＣＨを介して受信端末４０２にデータをユニキャスト又はグループキャストで送信することができる（４８０）。
【0063】
図５は、本開示の一実施例によるサイドリンクで端末がセンシングを介してサイドリンクの送信リソースを直接割り当てる方法を示す図面である。以下ではサイドリンクで端末がセンシングを介してサイドリンクの送信リソースを直接割り当てる方法をＭｏｄｅ２と指称する。Ｍｏｄｅ２の場合、ＵＥ ａｕｔｏｎｏｍｏｕｓ ｒｅｓｏｕｒｃｅ ｓｅｌｅｃｔｉｏｎと指称されることもできる。Ｍｏｄｅ２で基地局５０３はＶ２Ｘのためのサイドリンク送受信リソースプールをシステム情報で提供し、送信端末５０１が定められたルールによって送信リソースを割り当てることができる。基地局が直接リソース割り当てに関与するＭｏｄｅ１と異なり図５では送信端末５０１がシステム情報を介して予め受信したリソースプールに基づいて自律的にリソースを割り当ててデータを送信する点において差がある。
【0064】
図５を参照すれば、キャンプオン（ｃａｍｐ ｏｎ）５０５している送信端末５０１及び受信端末５０２は基地局５０３からＳＬ－ＳＩＢを受信することができる（５１０）。ここで、受信端末５０２は送信端末５０１が送信するデータを受信する端末を示す。ＳＬ－ＳＩＢ情報にはサイドリンク送受信のためのサイドリンクリソースプール情報、センシング動作のためのパラメーター設定情報、サイドリンク同期を設定するための情報、又は互いに異なる周波数で動作するサイドリンク送受信のためのキャリア情報などが含まれることができる。
【0065】
図４乃至図５の差異点は図４の場合、基地局５０３と送信端末５０１がＲＲＣ接続された状態（ＲＲＣ ｃｏｎｎｅｃｔｅｄ ｓｔａｔｅ）で動作する一方、図５では送信端末５０１がｉｄｌｅモード５２０（ＲＲＣ接続されない状態）でも動作することができるという点である。また、ＲＲＣ接続状態５２０でも基地局５０３はリソース割り当てに直接関与せず送信端末５０１が自律的に送信リソースを割り当てるようにできる。ここで送信端末５０１と基地局５０３の間のＲＲＣ接続をＵｕ－ＲＲＣ５２０と指称することができる。送信端末５０１にＶ２Ｘのためのデータトラフィックが生成されると、送信端末５０１は基地局５０３から受信されたシステム情報を介してリソースプールが設定されて送信端末５０１は設定されたリソースプール内でセンシングを介して時間／周波数領域のリソースを直接選択することができる（５３０）。
【0066】
ブロードキャスト送信の場合に送信端末５０１はサイドリンクに対するＲＲＣ設定５１５なしにブロードキャストでＰＳＣＣＨを介して受信端末５０２にＳＣＩ（１ｓｔ ｓｔａｇｅ）をブロードキャストできる（５５０）。また、送信端末５０１はＰＳＳＣＨを介して受信端末５０２にデータをブロードキャストできる（５７０）。ブロードキャスト送信の場合にはＰＳＳＣＨを通じるＳＣＩ送信（２ｎｄ ｓｔａｇｅ ＳＣＩ、５６０）が行われないこともある。
【0067】
これと異なり、ユニキャスト及びグループキャスト送信の場合に送信端末５０１は他の端末と一対一でＲＲＣ接続を行うことができる。ここで、Ｕｕ－ＲＲＣと区分して端末の間のＲＲＣ接続はＰＣ５－ＲＲＣ５１５と指称することができる。グループキャストの場合にもＰＣ５－ＲＲＣはグループにある端末の間に個別的に接続されることができる。図５ではＰＣ５－ＲＲＣ５１５接続がＳＬ－ＳＩＢの送信５１０以後の動作で図示されたがＳＬ－ＳＩＢの送信５１０以前又はＳＣＩの送信５５０以前に常に行われることもできる。もし、端末の間のＲＲＣ接続が必要な場合、サイドリンクのＰＣ５－ＲＲＣ接続が行われて（５１５）送信端末５０１はＰＳＣＣＨを介して受信端末５０２にＳＣＩ（１ｓｔ ｓｔａｇｅ）をユニキャスト又はグループキャストで送信することができる（５５０）。この時のＳＣＩのグループキャスト送信はグループＳＣＩと解釈されることもできる。また、送信端末５０１はＰＳＳＣＨを介して受信端末５０２にＳＣＩ（２ｎｄ ｓｔａｇｅ）をユニキャスト又はグループキャストで送信することができる（５６０）。この時の１ｓｔ ｓｔａｇｅ ＳＣＩにはリソース割り当てに係る情報、及び２ｎｄ ｓｔａｇｅ ＳＣＩにはその以外の制御情報が含まれることができる。また、送信端末５０１はＰＳＳＣＨを介して受信端末５０２にデータをユニキャスト又はグループキャストで送信することができる（５７０）。
【0068】
図６は、本開示の一実施例によるサイドリンクで一つのスロットにマッピングされた物理チャンネルのマッピング構造を示す図面である。
【0069】
具体的に、図６にＰＳＣＣＨ／ＰＳＳＣＨ／ＰＳＦＣＨ物理チャンネルに対するマッピングが図示された。ＰＳＣＣＨ／ＰＳＳＣＨ／ＰＳＦＣＨは周波数上に一つ以上のサブチャンネルに割り当てられることができる。サブチャンネル割り当てに対する詳細は図３の説明を参考する。次に、ＰＳＣＣＨ／ＰＳＳＣＨ／ＰＳＦＣＨの時間上マッピングを説明するために図６を参照すれば、送信端末が当該スロット６０１にＰＳＣＣＨ／ＰＳＳＣＨ／ＰＳＦＣＨを送信する前の一つ以上のシンボルがＡＧＣ（ａｕｔｏｍａｔｉｃ ｇａｉｎ ｃｏｎｔｒｏｌ）のための領域６０２で用いられることができる。当該シンボルがＡＧＣのために用いられる場合、当該シンボル領域に他のチャンネルの信号を繰り返して（ｒｅｐｅｔｉｔｉｏｎ）送信する方法を考慮することができる。この時、他のチャンネルの繰り返される信号はＰＳＣＣＨシンボルやＰＳＳＣＨシンボルのうちの一部が考慮されることができる。これと異なり、ＡＧＣ領域にプリアンブルが送信されることもできる。プリアンブル信号が送信される場合に他のチャンネルの信号を繰り返し送信する方法よりＡＧＣ実行時間がさらに短縮されることができる長所がある。ＡＧＣのためにプリアンブル信号が送信される場合にプリアンブル信号６０２では特定シーケンスが用いられることができ、この時のプリアンブルでＰＳＳＣＨ ＤＭＲＳ、ＰＳＣＣＨ ＤＭＲＳ、ＣＳＩ－ＲＳなどのシーケンスが用いられることができる。本開示でプリアンブルで用いられるシーケンスを前述した例に限定しない。追加的に図６によれば、スロットの初盤シンボルに制御情報を含むＰＳＣＣＨ６０３が送信され、ＰＳＣＣＨ６０３の制御情報によってスケジューリングされるデータがＰＳＳＣＨ６０４を介して送信されることができる。ＰＳＣＣＨ６０３には制御情報であるＳＣＩ（ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）の一部（１ｓｔ ｓｔａｇｅ ＳＣＩ）がマッピングされて送信されることができる。ＰＳＳＣＨ６０４にはデータだけではなく制御情報であるＳＣＩのまた他の一部（２ｎｄ ｓｔａｇｅ ＳＣＩ）がマッピングされて送信されることができる。また、図６はフィードバック情報を送信する物理チャンネルであるＰＳＦＣＨ６０５（ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｆｅｅｄｂａｃｋ ｃｈａｎｎｅｌ）がスロットの最後の部分に位置することを示す。ＰＳＳＣＨ６０４とＰＳＦＣＨ６０５の間に所定の空いている時間（Ｇａｐ）を確保してＰＳＳＣＨ６０４を送受信した端末がＰＳＦＣＨ６０５を送信又は受信するための準備ができるようにできる。また、ＰＳＦＣＨ６０５の送受信以後には一定時間の空いている区間（Ｇａｐ）を確保することができる。
【0070】
図７は、本開示の一実施例によってリソース割り当て関連情報を他の端末から提供されるために端末の間の協力を行うシナリオを示す図面である。
【0071】
具体的に、図７に端末の間の協力を行うサイドリンクシナリオが図示された。図７でＵＥ－Ａは端末の間の協力のための情報を提供する端末に該当し、ＵＥ－Ｂは端末の間協力のための情報が提供されてサイドリンク送信を行う端末に該当する。ここで端末は車両端末及び歩行者端末であることができることに注目する。この時、端末の間の協力のための情報はリソース割り当て情報であれば良い。しかし、本発明において端末の間の協力のための情報をリソース割り当て情報にだけ限定しない。図７でＵＥ－Ａが端末の間協力のための情報を提供する端末で定義したが、ＵＥ－ＡがＵＥ－Ｂで端末の間の協力のための情報を提供する前に２つの端末の間の協力のための情報７０１が互いに共有されることができる。この時、２つの端末の間の協力のための情報７０１はＵＥ－ＡがＵＥ－Ｂで提供するか、ＵＥ－ＢがＵＥ－Ａで提供するか、又は２つの端末（ＵＥ－Ａ、ＵＥ－Ｂ）の間の両方向で提供されることができる。また、本発明においてサイドリンクから端末の間の協力を行う環境で特定送信方法のみを仮定しない。言い換えれば、ブロードキャスト、ユニキャスト及びグループキャスト送信への適用をいずれも考慮することができる。しかし、前述したようにユニキャスト及びグループキャスト送信環境が端末の間の協力を行う有用なシナリオになることができることに注目する。サイドリンクで端末の間の協力を行う条件はネットワークによって上位レイアで活性化されるか（ｐｒｅ－）ｃｏｎｆｉｇｕｒａｔｉｏｎによって活性化されることができる。又は、端末の間のＰＣ５－ＲＲＣを介して端末の間の協力に対する行うかどうかが設定されることができる。言い換えれば、端末の間の協力に対する活性化が行われた時のＵＥ－Ａは端末の間の協力のための情報を提供することができ、ＵＥ－Ｂはこれを利用してサイドリンク送信を行うことができるだろう。
【0072】
図７でＵＥ－ＡとＵＥ－Ｂが端末の間の協力を行う一例でＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供するシナリオを考慮することができる。この時のＵＥ－Ａが提供するリソース割り当て情報はＵＥ－Ｂに対する一つ以上のリソースプール候補情報であれば良い。これと異なり、ＵＥ－Ａが提供するリソース割り当て情報はＵＥ－Ｂに対する一つ以上の割り当てられたリソース候補情報であれば良い。もし、リソースプール候補情報の場合にＵＥ－ＢはＵＥ－Ａから提供されたリソースプールのうちの一つのリソースプールでリソースを割り当ててサイドリンク送信を行うことができる。前述したようにリソースプールはサイドリンクでリソースを割り当てることができる時間及び周波数領域を示し、端末はリソースプール内で基地局から送信リソースが割り当てられるか、端末が直接センシング及びリソース割り当てを行って送信リソースを割り当てることができる。もし、ＵＥ－Ａが提供するリソース割り当て情報が割り当てられたリソース候補情報の場合、前記割り当てられたリソース候補情報はリソースプールで割り当てられたリソース候補としてＵＥ－Ａは当該リソースでＵＥ－Ｂがサイドリンク送信を行うことを期待し、また、当該リソースでＵＥ－Ｂからサイドリンク送信を受信することを期待する場合であれば良い。したがって、ＵＥ－ＢはＵＥ－Ａから提供された割り当てられたリソース候補のうちのサイドリンク送信を行うことができる。ここでＵＥ－ＢがＵＥ－Ａから提供されたリソース割り当て情報を利用するか又は利用しないこともある。
【0073】
図７でＵＥ－ＡとＵＥ－Ｂは以下の表１のように基地局のカバレッジの内に位置するＩＣ（Ｉｎ－Ｃｏｖｅｒａｇｅ）であるか基地局のカバレッジの外に位置するＰＣ（ｐａｒｔｉａｌ ｃｏｖｅｒａｇｅ）又はＯＯＣ（ｏｕｔ－ｏｆ ｃｏｖｅｒａｇｅ）である端末であれば良い。
【0074】
【表1】
【0075】
前記表１でＣａｓｅ Ａの場合、ＵＥ－ＡとＵＥ－Ｂが皆基地局カバレッジの内に位置するため、ＵＥ－Ａが基地局から設定されたリソース割り当て情報をＵＥ－Ｂで提供することができる。もし、ＵＥ－ＡとＵＥ－Ｂがそれぞれ異なる基地局のカバレッジの内に位置する場合にはリソース割り当てのためのＵＥ－Ｂの情報が基地局の間の互いに交換されることができる。表１でＣａｓｅ Ｂの場合、ＵＥ－Ａは基地局カバレッジの内に位置するがＵＥ－Ｂは基地局カバレッジの外に位置するためＵＥ－Ａが基地局から設定されたリソース割り当て情報をＵＥ－Ｂで提供するためにはリソース割り当てのためのＵＥ－Ｂの情報がＵＥ－Ａが属した基地局に提供される時にできる。表１でＣａｓｅ ＡとＣａｓｅ Ｂの場合にＵＥ－ＡがＵＥ－Ｂのためのリソース割り当てのために直接センシング及びリソース割り当て動作を行ってリソース割り当て情報をＵＥ－Ｂで提供することが可能できる。表１でＣａｓｅ ＣとＣａｓｅ Ｄの場合にＵＥ－Ａが基地局のカバレッジの外に位置するためＵＥ－Ａが直接ＵＥ－Ｂのためのリソース割り当てのために直接センシング及びリソース割り当て動作を行ってリソース割り当て情報をＵＥ－Ｂで提供する方法だけができる。
【0076】
前記表１でＣａｓｅ Ａの場合で２つの端末が同じ基地局のカバレッジのにある場合にはＵＥ－ＡとＵＥ－Ｂに同じなリソースプールが設定されることができる。しかし、一般的にＵＥ－ＡとＵＥ－Ｂにサイドリンク送信のために設定されたリソースプール情報が異なることができる。そして、サイドリンクでは各端末に一つ以上のリソースプールが設定されることができる。もし、サイドリンクで端末に多数のリソースプールが設定される場合、端末は送信に適合な一つのリソースプールを選択して当該リソースプールでサイドリンク送信を行うことができる。例えば、ＵＥ－ＡにリソースプールＡ、Ｂ、Ｃが割り当てられてＵＥ－ＢにリソースプールＤとＥが割り当てられた場合を検討する。ＵＥ－ＡとＵＥ－Ｂが端末の間の協力を行う時、ＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供するシナリオでＵＥ－Ｂがサイドリンク送信に用いるリソースプールに対する以下のような場合が考慮されることができる。
【0077】
＊Ｃａｓｅ－１：ＵＥ－Ｂに設定されたリソースプールでＵＥ－Ｂがサイドリンク送信を実行
【0078】
＊Ｃａｓｅ－２：ＵＥ－Ｂに設定されたリソースプールではないＵＥ－Ａに設定されたリソースプールでＵＥ－Ｂがサイドリンク送信を実行
【0079】
＊Ｃａｓｅ－３：ＵＥ－ＡとＵＥ－Ｂが端末の間の協力のために設定されたリソースプールでＵＥ－Ｂがサイドリンク送信を実行
【0080】
前記のＣａｓｅ－１の場合、ＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供するためにはＵＥ－Ｂに割り当てられたリソースプールＤとＥに対する情報がＵＥ－Ａに共有されなければならない。前記のＣａｓｅ－２の場合、ＵＥ－ＢがＵＥ－Ａが提供したリソース割り当て情報を利用するためにはＵＥ－Ａに割り当てられたリソースプールＡ、Ｂ、Ｃに対する情報がＵＥ－Ｂに共有されなければならない。前記のＣａｓｅ－３の場合はＵＥ－ＡとＵＥ－Ｂが互いに共有されたリソースプールから端末の間の協力を行う場合である。例えば、ＵＥ－ＡとＵＥ－Ｂが互いに共有されたリソースプールＦとＧで端末の間の協力を行うことができる。したがって、表１のすべての場合に対してＵＥ－ＡとＵＥ－Ｂが端末の間の協力を行ってＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供するためには端末の間のリソースプール情報が共有されなければならない。これに対する詳細は以下の第１実施例を参考する。
【0081】
次にＵＥ－ＡとＵＥ－Ｂが端末の間の協力を行ってＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供する時、前述したようにＵＥ－Ａが提供するリソース割り当て情報はＵＥ－Ｂに対する一つ以上の割り当てられたリソース候補情報であれば良い。この時、ＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供するためには端末の間のリソースプール情報が共有されなければならない。具体的に、ＵＥ－Ａは基地局から送信リソースが割り当てられるか直接センシング及びリソース割り当てを介して送信リソースを割り当てることができる。これをできるようにするためにＵＥ－ＡはＵＥ－Ｂに対するリソース割り当てに係る情報が提供されなければならない。また、ＵＥ－Ａがリソース割り当てを指示する場合にＵＥ－Ａ及びＵＥ－Ｂの間のリソースプール情報が共有されると指示したリソース割り当て情報を解釈することができる。先ず、ＵＥ－ＡがＵＥ－Ｂから提供される情報として次が含まれることができる。以下の情報は例示のためのことであるだけ、本発明でＵＥ－ＢがＵＥ－Ａで提供するリソース割り当て関連情報は下の情報にだけ限定されない。
【0082】
リソース割り当て情報が提供されるためにＵＥ－ＢがＵＥ－Ａで提供する情報
【0083】
＊ＵＥ－Ｂに対するＴＸ ｐｒｉｏｒｉｔｙ
【0084】
＊ＵＥ－Ｂに対するＲｅｍａｉｎｉｎｇ Ｐａｃｋｅｔ ｄｅｌａｙ ｂｕｄｇｅｔ（ＰＤＢ）
【0085】
＊ＵＥ－Ｂに対するＢＳＲ（Ｂｕｆｆｅｒ Ｓｔａｔｅ Ｒｅｐｏｒｔ）
【0086】
＊ＵＥ－Ｂに対するＨＡＲＱ ｆｅｅｄｂａｃｋ ｉｓ ｅｎａｂｌｅｄ／ｄｉｓａｂｌｅｄ
【0087】
＊ＵＥ－Ｂに対するＭｏｄｅ２リソース割り当て情報
【0088】
前記情報のうちのＵＥ－Ｂに対するＲｅｍａｉｎｉｎｇ ＰＤＢはパケットに対するｌａｔｅｎｃｙ又はｄｅｌａｙ ｒｅｑｕｉｒｅｍｅｎｔに該当される情報であれば良い。前記情報のうちのＵＥ－Ｂに対するＭｏｄｅ２情報ではＬｓｕｂｃｈのような情報が含まれることができる。ここでＬｓｕｂｃｈはＵＥ－ＢがＭｏｄｅ２を通じるリソース割り当て時のリソース候補の周波数上で連続的なサブチャンネルの数である。しかし、ＬｓｕｂｃｈはシグナルされずＵＥ－Ａが直接選択する方法が考慮されることもできる。このような場合にＵＥ－ＡはＵＥ－Ｂのリソース割り当て情報を介してＬｓｕｂｃｈの情報をＵＥ－Ｂで指示しなければならない必要がある。本発明においてＵＥ－Ｂに対するＭｏｄｅ２リソース割り当て情報をＬｓｕｂｃｈ情報にだけ限定しない。したがって、ＵＥ－ＡがＵＥ－Ｂから前記情報のうちの一つ以上が提供される場合、ＵＥ－Ａはカバレッジの内にある基地局にこの情報をＵｕ ＲＲＣを介して伝達する方法が共に考慮されることができる。このようにＵＥ－Ｂのリソース割り当て情報がＵＥ－Ａに属した基地局に提供される場合に、ＵＥ－Ａは基地局からＵＥ－Ｂのための送信リソースを割り当てられることもできる。
【0089】
以下の実施例は前述したサイドリンクでの端末がセンシング及びリソース割り当てを行う手順（Ｍｏｄｅ２）を提案するためのことである。また、端末の電力消耗を最小化するためのＭｏｄｅ２方法を提案する。このためにリソース割り当て関連情報を他の端末から提供される端末の間の協力を行うための方法を提案する。そして、これによる端末及び基地局の動作に関する。以下、本開示による実施例は端末の間のユニキャスト（ｕｎｉｃａｓｔ）、グループキャスト（ｇｒｏｕｐｃａｓｔ）及びブロードキャスト（ｂｒｏａｄｃａｓｔ）を含む任意の通信環境で通信を行う端末に適用されることができる。
【0090】
＜第１実施例＞
【0091】
第１実施例はサイドリンクで端末の間の協力を行う場合にリソースプール情報を共有する方法を提案する。前記図７を介してＵＥ－ＡとＵＥ－Ｂが端末の間の協力を行ってＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供するためにはＵＥ－Ａ及びＵＥ－Ｂの間のリソースプール情報が共有されなければならないことを説明した。リソースプールはサイドリンクでリソースを割り当てることができる時間及び周波数領域を示し、リソースを割り当てることができる時間及び周波数領域情報だけではなくリソースプールに係る多様なパラメーターが前記リソースプールに対する情報として共に設定されることができる。例えば、表２はＬＴＥ Ｖ２Ｘでリソースプールに含まれるパラメーター情報の例示を示す。例えば、表２を参考すれば、リソースプールごとにｃｂｒ－ｐｓｓｃｈ－ＴｘＣｏｎｆｉｇＬｉｓｔ－ｒ１４が設定されることができ、前記ｃｂｒ－ｐｓｓｃｈ－ＴｘＣｏｎｆｉｇＬｉｓｔ－ｒ１４に基づいてＣＢＲ測定結果によって送信パラメーターが決定されることができる。
【0092】
【表2】
【0093】
また他の一例で、表３はＮＲ Ｖ２Ｘでリソースプールに含まれるパラメーター情報の例示を示す。例えば、表３を参考すれば、リソースプールごとにｓｌ－ＭＣＳ－Ｔａｂｌｅ－ｒ１６街設定されて設定されたＭＣＳテーブルのサポートに対する決定が行うことができる。
【0094】
【表3】
【0095】
前記表２と表３のようにリソースプールに対してリソースを割り当てることができる時間及び周波数領域情報だけではなくリソースプールに係る多様なパラメーターが共に設定されることができる。したがって、端末の間のリソースプール情報が共有されるためには多くの情報量が必要なことがある。したがって、端末の間のリソースプール情報を共有するために次の方法が考慮されることができる。
【0096】
端末の間のリソースプール情報を共有するための方法
【0097】
＊方法１：ＰＣ５－ＲＲＣを通じる設定
【0098】
＊方法２：ＳＬ ＭＡＣ ＣＥを通じる設定
【0099】
＊方法３：２ｎｄ ｓｔａｇｅ ＳＣＩを通じる設定
【0100】
先ず、方法１はサイドリンクで端末の間のＰＣ５－ＲＲＣ接続が確立される場合これを介してリソースプール情報を共有する方法である。方法２はサイドリンクでＰＣ５－ＲＲＣ接続が確立される場合、ＭＡＣ ＣＥを介してリソースプール情報を共有する方法である。そして、方法３は２ｎｄ ｓｔａｇｅ ＳＣＩを介してリソースプール情報を共有する方法である。前記方法を介して図７のＵＥ－ＡとＵＥ－ＢがリソースプールＡ、Ｂ、Ｃを共有したと仮定する。この時、共有されたリソースプールは図７で説明したＣａｓｅ１／２／３に該当する場合であっても良い。言い換えれば、リソースプールＡ、Ｂ、ＣはＵＥ－Ｂが割り当てられたリソースプールであっても良く（Ｃａｓｅ－１）、ＵＥ－Ａが割り当てられたリソースプールであっても良く（Ｃａｓｅ－２）、ＵＥ－ＡとＵＥ－Ｂに割り当てられたリソースプールと独立的に端末の間の協力のために共有されたリソースプールであっても良い（Ｃａｓｅ－３）。この時、各端末が割り当てられることができるリソースプールの最大個数が決定されることができる。もし、各端末が割り当てられることができるリソースプールの最大個数がＸ個で制限され、端末の間の共有されたリソースプールによって端末に設定されたリソースプールの数がＸ個を超過する場合、端末の間の共有することができるリソースプールが限定されるか、以前に端末に割り当てられたリソースプールのうちの先ず割り当てられたリソースプールからｏｖｅｒｗｒｉｔｅする方法が考慮されることができる。
【0101】
本発明においてリソースプール情報を共有する方法を前記方法１乃至方法３に限定しない。また、リソースプール情報を共有する方法で前記方法の組み合せを考慮することもできる。例えば、次のような組み合せが考慮されることができる。
【0102】
＊方法１＋２：ＰＣ５－ＲＲＣを介して多数のリソースプール情報が共有された以後にＳＬ ＭＡＣ ＣＥを介して共有するリソースプールｉｎｄｅｘを指示する方法
【0103】
＊方法１＋３：ＰＣ５－ＲＲＣを介して多数のリソースプール情報が共有された以後に２ｎｄ ｓｔａｇｅＳＣＩを介して共有するリソースプールｉｎｄｅｘを指示する方法
【0104】
＊方法２＋３：ＳＬ ＭＡＣ ＣＥを介して多数のリソースプール情報が共有された以後に２ｎｄ ｓｔａｇｅ ＳＣＩを介して共有するリソースプールｉｎｄｅｘを指示する方法
【0105】
前記に方法の組み合せは端末の間の協力を行う場合、多数のリソースプールが設定されて一つ以上のリソースプール情報が共有されなければならない場合に、より効果的な方法であれば良い。例えば、方法１＋２の場合にＵＥ－ＡとＵＥ－Ｂの間のリソースプールＡ、Ｂ、ＣがＰＣ５－ＲＲＣを介して共有された以後、リソースプールＡに対応されるｉｎｄｅｘを指示するＳＬ ＭＡＣ ＣＥを介してリソースプールＡが共有されることができる。又は、ＵＥ－ＡとＵＥ－Ｂの間のリソースプールＡ、Ｂ、ＣがＰＣ５－ＲＲＣを介して共有された以後、リソースプールＡとＢに対応されるｉｎｄｅｘを指示するＳＬ ＭＡＣ ＣＥを介してリソースプールＡ及びＢが共有されることができる。多数のリソースプール情報が共有される場合に共有しなければならないリソースプールに係る情報量が増加するようになるが、前記のような方法の組み合せを介してこのような問題点が緩和されることができる。
【0106】
もし、端末の間の協力のために多数のリソースプールが共有された場合に、端末はリソースプールでのＣＢＲに基づいて用いるリソースプールを選択する方法が考慮されることもできる。先ず、特定スロットｎで測定されるＣＢＲは次のようで定義されることができる。
【0107】
＊ＣＢＲはリソースプールで端末が測定したサイドリンクＲＳＳＩ（ｒｅｃｅｉｖｅｄ ｓｉｇｎａｌ ｓｔｒｅｎｇｔｈ ｉｎｄｉｃａｔｏｒ）が（予め）設定されたしきい値を超過するサブチャンネルの割合で定義されることができる。ここで、ＣＢＲ測定はスロット［ｎ－Ｘ、ｎ－１］で行われることができ、スロットインデックスは物理的スロットインデックスに基づくことができる。
【0108】
＊＊送信観点でのＣＢＲ測定はＰＳＳＣＨ領域とＰＳＣＣＨ領域のいずれもに対して同時に行われることもできる。図６を参考すれば、ＰＳＣＣＨの一部に係るＰＳＳＣＨがＰＳＣＣＨとオーバーラップしない周波数リソース及びＰＳＣＣＨとオーバーラップする時間リソースで送信されることもでき、また他の例示によって、互いに関連するＰＳＳＣＨとＰＳＣＣＨの少なくとも一部がオーバーラップしない時間リソースで送信されることもできる。ここで‘関連する’の意味はＰＳＣＣＨが少なくともＰＳＳＣＨをデコーディングするために必要な情報を含むことを意味する。前述のようにＰＳＣＣＨとＰＳＳＣＨが多重化（ｍｕｌｔｉｐｌｅｘｉｎｇ）される場合、ＰＳＣＣＨ領域とＰＳＳＣＨ領域の送信電力が一定で、これによるＲＳＳＩがＰＳＣＣＨ領域とＰＳＳＣＨ領域で同様に測定されることができるという仮定下に、ＰＳＳＣＨ領域とＰＳＣＣＨ領域を区分せず２つの領域で同時にＣＢＲ測定が行われることができる。具体的に、図６でＰＳＣＣＨ領域とＰＳＳＣＨ領域のシンボルでＲＳＳＩが測定されることができる。図６のようにＰＳＣＣＨとＰＳＳＣＨが多重化（ｍｕｌｔｉｐｌｅｘｉｎｇ）される場合、端末がＣＢＲ測定時のＰＳＣＣＨ領域とＰＳＳＣＨ領域を区分しにくいことがある。したがって、ＰＳＣＣＨ領域とＰＳＳＣＨ領域を区分せず、ＰＳＣＣＨ領域とＰＳＳＣＨ領域のシンボルの全てでＣＢＲ測定が行われることができる。
【0109】
＊＊ＸはＣＢＲが測定されるウィンドウ（ｗｉｎｄｏｗ）のサイズの値であり、Ｘは固定された値であるか、設定可能な値であれば良い。Ｘが一つの固定された値の場合の一例としてＸは１００スロットと設定されることができる。Ｘが設定可能な値の場合、Ｘの設定値はリソースプール設定情報に含まれることができる。端末が基地局とＲＲＣ接続される前には当該値が端末に対して予め構成（ｐｒｅ－ｃｏｎｆｉｇｕｒａｔｉｏｎ）されるか、又は端末が基地局からＳＩＢを介して設定されることができる。端末が基地局とＲＲＣ接続された以後には端末に特定（ＵＥ ｓｐｅｃｉｆｉｃ）するようにＸが設定されることができる。また、端末と端末の間のＰＣ５－ＲＲＣ接続を介してＸが設定されることができる。例えば、Ｘは｛１００・２μ、１００｝スロットのうちの一つの値でリソースプール設定情報を介して設定できる。ここで、μはヌマララジ（ｎｕｍｅｒｏｌｏｇｙ）に該当するインデックス（ｉｎｄｅｘ）でＳＣＳ（ｓｕｂｃａｒｒｉｅｒ ｓｐａｃｉｎｇ）によって次のような値で設定される。
【0110】
＊＊＊ＳＣＳ＝１５ｋＨｚ、μ＝０
【0111】
＊＊＊ＳＣＳ＝３０ｋＨｚ、μ＝１
【0112】
＊＊＊ＳＣＳ＝６０ｋＨｚ、μ＝２
【0113】
＊＊＊ＳＣＳ＝１２０ｋＨｚ、μ＝３
【0114】
前記の２つの設定方法のうちのＸ＝１００・２μで設定される場合はＳＣＳにしたがって１００ｍｓに該当するＣＢＲウィンドウ（ＣＢＲ ｗｉｎｄｏｗ）のスロット個数が変更される方法に該当し、Ｘ＝１００と設定される場合はＳＣＳに関わらずＣＢＲウィンドウが１００スロットで固定される方法に該当する。したがって、Ｘ＝１００と設定される場合にはＣＢＲウィンドウ（ＣＢＲ ｗｉｎｄｏｗ）の測定時間（ｍｓ）が変わることができる。
【0115】
＊＊サイドリンクＲＳＳＩは受信信号強度を意味する。すなわち、サイドリンクＲＳＳＩは受信端末によって受信される電力（単位：［Ｗ］）を示し、サイドリンクのスロット内の当該チャンネルの有効なＯＦＤＭシンボル位置及び設定されたサブチャンネルによって観察される。
【0116】
前記ＣＢＲの定義によって測定されたＣＢＲ値に基づいて当該チャンネルの混雑するかどうかが判断されることができる。端末は測定したＣＢＲを基地局に報告することができる。具体的に、基地局と端末がＵｕ－ＲＲＣで接続された場合に、端末が測定したＣＢＲ値がＵｕ－ＲＲＣを介して基地局に報告されることができる。サイドリンクリソース割り当て方式のうちのＭｏｄｅ１で、送信端末が基地局に受信端末とサイドリンク通信を行うための送信リソースをリクエストする場合、基地局は報告されたＣＢＲ情報を利用して送信リソースを割り当てることができる。一方、サイドリンクリソース割り当て方式のうちのＭｏｄｅ２で、端末はセンシングを介して直接リソース割り当てを行うだけでなく端末が測定したＣＢＲを反映してチャンネル接続するかどうか及び送信パラメーターを決定すべきである。したがって、Ｍｏｄｅ２で端末はＣＢＲ測定と共にＣＲ（ｃｈａｎｎｅｌ ｏｃｃｕｐａｎｃｙ ｒａｔｉｏ）を測定することによって混雑制御を行うことができる。この場合、パケットの優先順位（ｐｒｉｏｒｉｔｙ）が反映されることができる。送信端末がパッケージを送信する場合、当該パケットの優先順位を指示するための値がＳＣＩを介して受信端末に伝達することができる。ＣＲは端末がチャンネルを何の位の占有したか示す指数として、ＣＢＲ値にしたがって端末がチャンネルを占有することができるＣＲ制限（ＣＲ ｌｉｍｉｔ）が決定されることができる。例えば、チャンネルが混雑する場合（すなわち、ＣＢＲ値が高く測定された場合）にはＣＲ制限が低く設定され、端末は測定されたＣＲがＣＲ制限を超過しないように混雑制御を行うことができる。混雑制御を行うため、端末は送信をドロップ（ｄｒｏｐ）するか又はスケジューリング具現を介して測定されたＣＲがＣＲ制限を満足させるようにできる。チャンネルが混雑しない場合（すなわち、ＣＢＲ値が低く測定された場合）にはＣＲ制限が高く設定され、測定されたＣＲがＣＲ制限を超過しない可能性が高くなるため、端末がよりチャンネルを占有して用いることが可能になることができる。
【0117】
しかし、サイドリンクで各送受信を行う端末が測定したＣＢＲ値は互いに異なる値を有することができる。例えば、図７でＵＥ－Ｂがサイドリンク送信を行う端末で、ＵＥ－Ａは端末の間の協力を行ってＵＥ－Ｂでリソース割り当て情報を提供してＵＥ－Ｂのサイドリンク送信を受信する端末の場合に、ＵＥ－Ａが測定したＣＢＲ値とＵＥ－Ｂが測定したＣＢＲ値は異なることができる。例えば、ＵＥ－Ｂの周辺には端末が少なく分布してＣＢＲが低く測定され、ＵＥ－Ａ周辺には端末が多数の分布してＣＢＲが高く測定されることができる。したがって、端末の間のリソースプール情報を共有する過程で、各端末が測定したＣＢＲ情報も共に共有されることができる。例えば、図７のＵＥ－ＡとＵＥ－ＢがリソースプールＡ、Ｂ、Ｃを共有する場合を仮定する時、各リソースプールに対してＵＥ－Ａが測定したＣＢＲ情報とＵＥ－Ｂが測定したＣＢＲ情報がＵＥ－Ａ及びＵＥ－Ｂの間の共有されることができる。具体的に、次のようなＣＢＲ情報が端末の間の共有されることができる。
【0118】
＊リソースプールＡでＵＥ－Ａが測定したＣＢＲとＵＥ－Ｂが測定したＣＢＲ情報が互いに異なることができ、このＣＢＲ情報がＵＥ－Ａ及びＵＥ－Ｂの間の共有されることができる。
【0119】
＊リソースプールＢでＵＥ－Ａが測定したＣＢＲとＵＥ－Ｂが測定したＣＢＲ情報が互いに異なることができ、このＣＢＲ情報がＵＥ－Ａ及びＵＥ－Ｂの間の共有されることができる。
【0120】
＊リソースプールＣでＵＥ－Ａが測定したＣＢＲとＵＥ－Ｂが測定したＣＢＲ情報が互いに異なることができ、このＣＢＲ情報がＵＥ－Ａ及びＵＥ－Ｂの間の共有されることができる。
【0121】
この時、ＣＢＲが共有される方法では前述したリソースプールが共有される方法１乃至方法３又はこれらの組み合せが用いられることができる。また、もし、前記のように端末の間のＣＢＲ情報が共有される場合に、各リソースプールのＣＢＲに基づいて多数のリソースプールのうちの用いる一つのリソースプールを選択する方法で以下のような方法が考慮されることができる。
【0122】
【数1】
【0123】
前記数式でｉは図７でＵＥ－Ａ又はＵＥ－Ｂを指示するｉｎｄｅｘである。そして、ｊはリソースプールを指示するｉｎｄｅｘである。前記数式によれば、端末は多数のリソースプールで２つの端末がそれぞれ測定したＣＢＲ値のうちの大きい値を基準で最も低いＣＢＲ値を有するリソースプールを選択することができる。
【0124】
＜第２実施例＞
【0125】
第２実施例は図７のようにサイドリンクで端末の間の協力を行う場合にＵＥ－ＢがＵＥ－Ａにリソース割り当てをリクエストする方法を提供する。これはＵＥ－ＢがＵＥ－ＡにＳＲ（Ｓｃｈｅｄｕｌｉｎｇ Ｒｅｑｕｅｓｔ）を送信する動作で解釈することができる。ＵＥ－ＢがＵＥ－ＡにＳＲを送る条件で、ＵＥ－Ｂは端末の間の協力に発生されるｄｅｌａｙを考慮する時のＵＥ－Ｂのパッケージ送信に対するｒｅｍａｉｎｉｎｇ ＰＤＢ（ｐａｃｋｅｔ ｄｅｌａｙ ｂｕｄｇｅｔ）が充分に大きい場合にＵＥ－ＡにＳＲを送信することができる。このような条件が満足されない場合、ＵＥ－ＢがＵＥ－Ａにリソース割り当てをリクエストして受信した情報は有用な情報ではないことがある。このような条件が満足される仮定下にＵＥ－ＢがＵＥ－ＡにＳＲをリクエストする方法以下の方法が考慮されることができる。以下、実施例を説明するに当りＳＲ（Ｓｃｈｅｄｕｌｉｎｇ ｒｅｑｕｅｓｔ）は一例示に命名されたことであるだけ本発明を制限せず、第２実施例で説明する動作はサイドリンクで端末の間の協力を行う場合にＵＥ－ＢがＵＥ－Ａにリソース割り当てをリクエストするための、すなわち、ｉｎｔｅｒ－ＵＥ ｃｏｏｒｄｉｎａｔｉｏｎをリクエストするための任意の動作を含むことができ、ＳＲ（ｓｃｈｅｄｕｌｉｎｇ ｒｅｑｕｅｓｔ）は前記リソース割り当て情報をリクエストするための任意のメッセージ又はシグナリングで取り替えられることができる。
ＵＥ－ＢがＵＥ－ＡにＳＲをリクエストする方法
ＵＥ－ＢがＵＥ－ＡにＳＲをリクエストする方法
【0126】
＊方法１：ＳＬ ＭＡＣ ＣＥを通じるリクエスト
【0127】
＊方法２：１ｓｔ ｓｔａｇｅ ＳＣＩを通じるリクエスト
【0128】
＊方法３：２ｎｄ ｓｔａｇｅ ＳＣＩを通じるリクエスト
【0129】
先ず、方法１はサイドリンクでＰＣ５－ＲＲＣ接続が確立される場合、サイドリンクＭＡＣ ＣＥを介してリソースプール情報を共有する方法である。そして、方法２と３はそれぞれ１ｓｔ ｓｔａｇｅ ＳＣＩと２ｎｄ ｓｔａｇｅ ＳＣＩを介してリソースプール情報を共有する方法である。方法２を用いる場合にＲｅｌ－１６サイドリンクの１ｓｔ ｓｔａｇｅ ＳＣＩにはＳＲに係るフィールドがないため、既存の端末には適用されることができない問題点がある。本発明でＳＲをリクエストする方法を前記方法に限定しない。また、ＵＥ－ＢはＵＥ－ＡにＳＲを送信しながら、前述した‘リソース割り当て情報を提供されるためにＵＥ－ＢがＵＥ－Ａで提供する情報’の一部を共に伝達することができる。しかし、‘リソース割り当て情報を提供されるためにＵＥ－ＢがＵＥ－Ａで提供する情報’は関連情報を提供するためのシグナリングオーバーヘッドが非常に大きいため前記方法２ではない他の方法を用いることができる。
【0130】
次に、ＵＥ－ＢがＵＥ－ＡにＳＲをリクエストした場合に、ＵＥ－Ａはこれを受信した後、ＵＥ－Ａが属した基地局にＵＥ－Ｂのリソース割り当てをリクエストするかＵＥ－Ａが直接センシングを介してＵＥ－Ｂのためのリソースを割り当ててＵＥ－Ｂにリソース割り当て情報を提供することができる。ＵＥ－Ａが直接センシングを介してＵＥ－Ｂのためのリソースを割り当てる詳細方法は以下の第４実施例を参考する。本実施例ではＵＥ－ＡがＵＥ－ＢからＳＲを受信したがＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供することができない場合を説明する。ＵＥ－ＡがＵＥ－ＢからＳＲを受信してＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供する場合に対する詳細方法は以下の第３実施例を参考する。先ず、ＵＥ－ＡがＵＥ－ＢからＳＲを受信したがＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供することができない場合として以下のような場合が考慮されることができる。
【0131】
＊Ｃａｓｅ－１：ＵＥ－Ａがｅｘｃｅｐｔｉｏｎａｌ ｐｏｏｌで動作する場合
【0132】
＊Ｃａｓｅ－２：ｄｅｌａｙによって端末の間の協力が不可能であると判断された場合
【0133】
前記Ｃａｓｅ－１はＵＥ－Ａがｈａｎｄｏｖｅｒを行う場合、ＵＥ－Ａはｅｘｃｅｐｔｉｏｎａｌ ｐｏｏｌで動作し、この場合、ＵＥ－Ａは基地局でＵＥ－Ｂに対するリソース割り当てをリクエストし難い状況になり、またｅｘｃｅｐｔｉｏｎａｌ ｐｏｏｌで動作する場合にはＵＥ－Ａが直接リソース割り当て時のｒａｎｄｏｍ ｓｅｌｅｃｔｉｏｎを行うためＵＥ－Ｂで有効なリソース割り当て情報を提供し難くなる。前記Ｃａｓｅ－２はＵＥ－Ａが属した基地局にＵＥ－Ｂのリソース割り当てをリクエストするかＵＥ－Ａが直接センシングを介してＵＥ－Ｂのためのリソースを割り当ててＵＥ－Ｂに提供しようとするリソース割り当て情報が、端末の間の協力過程で発生されたｄｅｌａｙによってこれ以上有効ではない場合であることができる。例えば、ＵＥ－Ｂのリソース送信に対するＰＤＢがＸｍｓやＵＥ－ＢのためのリソースがＸｍｓ内で選択されることができないと判断された場合に該当することができる。本発明でＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供することができない場合を前記の場合に限定しない。ＵＥ－ＢからＳＲリクエストを受信したがＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供することができないと判断される場合にこれに対するｒｅｓｐｏｎｓｅを行う動作を考慮することができる。例えば、簡単に１ｂｉｔ情報を介してＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供することができるか否かをシグナリングでき、ＳＬ ＭＡＣ ＣＥを介して指示するか２ｎｄ ｓｔａｇｅ ＳＣＩを通じる指示方法が考慮されることができる。一方、前述の方法は例示のためのことであるだけ本発明でＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供することができるか否かを指示する方法は前記方法に限定されない。
【0134】
＜第３実施例＞
【0135】
第３実施例は図７のようにサイドリンクから端末の間の協力を行う場合にＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供する方法を提供する。前記第２実施例によってＵＥ－ＢがＵＥ－ＡにＳＲを送信した場合に、ＵＥ－Ａはこれを受信した後のＵＥ－Ａが属した基地局にＵＥ－Ｂのリソース割り当てをリクエストするかＵＥ－Ａが直接センシングを介してＵＥ－Ｂのためのリソースを割り当ててＵＥ－Ｂにリソース割り当て情報を提供することができる。この時のＵＥ－Ａが選択されたリソース割り当て情報をＵＥ－Ｂに提供する方法で以下の方法が考慮されることができる。
【0136】
ＵＥ－ＡがＵＥ－Ｂにリソース割り当て情報を提供する方法
【0137】
＊方法１：ＳＬ ＭＡＣ ＣＥを通じるリソース割り当て情報提供
【0138】
＊方法２：１ｓｔ ｓｔａｇｅ ＳＣＩを通じるリソース割り当て情報提供
【0139】
＊方法３：２ｎｄ ｓｔａｇｅ ＳＣＩを通じるリソース割り当て情報提供
【0140】
先ず、方法１はサイドリンクでＰＣ５－ＲＲＣ接続が確立される場合、サイドリンクＭＡＣＣＥを介してリソース割り当て情報をシグナリングする方法である。そして、方法２と３はそれぞれの１ｓｔ ｓｔａｇｅ ＳＣＩと２ｎｄ ｓｔａｇｅ ＳＣＩを介してリソース割り当て情報をシグナリングする方法である。方法２を用いる場合にＲｅｌ－１６サイドリンクの１ｓｔ ｓｔａｇｅ ＳＣＩにはこれに係るフィールドがないため既存の端末には適用されることができない問題点がある。しかし、Ｒｅｌ－１６サイドリンクの１ｓｔ ｓｔａｇｅ ＳＣＩには端末がサイドリンク送信のために予約したリソース割り当て情報を指示するフィールドがある。これは異なり、端末が当該情報を受信して送信リソースを割り当てるのに用いるようにするためである。一実施例では、ＵＥ－Ａ及びＵＥ－Ｂが当該フィールドをＵＥ－Ａが予約したリソース割り当て情報ではないＵＥ－ＡがＵＥ－Ｂに指示するリソース割り当て情報で解釈するようにする方法を考慮することができる。これは１ｓｔ ｓｔａｇｅ ＳＣＩに追加的な１ｂｉｔ ｆｉｅｌｄを導入して当該フィールドがＵＥ－Ａが予約したリソース割り当て情報であるか、ＵＥ－ＡがＵＥ－Ｂに指示するリソース割り当て情報であるかを指示することによって可能できる。本発明においてＵＥ－ＡがＵＥ－Ｂにリソース割り当て情報を提供する方法を前記方法に限定しない。
【0141】
また、ＵＥ－ＡがＵＥ－Ｂにリソース割り当て情報は次が含まれることができる。
【0142】
＊同じ一つのＴＢに対する初期リソースの位置情報
【0143】
＊同じ一つのＴＢに対する再送信リソースの位置情報
【0144】
先ず、前記リソース割り当て情報のうちの少なくとも一つのＴＢに対する初期リソースの位置情報が含まれることができる。本発明で前記初期リソースと再送信リソースの周波数上のサブチャンネル数は同じであると仮定されることができる。もし、異なる場合に、追加的な情報が指示されなければならない。したがって、リソースの位置情報は送信される時間上の位置と周波数上のサブチャンネル開始位置情報であれば良い。一般的に、サイドリンクのＭｏｄｅ２動作で端末が自分のサイドリンク送信のためのリソースを割り当てる場合に前記の初期リソースに対する位置情報はＰＳＣＣＨが送信された位置情報によって決定されるため、当該情報を別にシグナリングする必要がない。しかし、本発明のようにサイドリンクから端末の間の協力を行ってＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供する場合にはＵＥ－ＡがＵＥ－Ｂで初期リソースの位置情報（時間上の位置と周波数上のサブチャンネル開始位置）を追加的に指示する必要がある。この時、時間上の位置は決定する方法で次のような方法が考慮されることができる。
【0145】
＊Ａｌｔ－１：ＳＦＮ（Ｓｙｓｔｅｍ Ｆｒａｍｅ Ｎｕｍｂｅｒ）又はＤＦＮ（Ｄｉｒｅｃｔ Ｆｒａｍｅ ｎｕｍｂｅｒ）を基準で、決定されたＰＳＳＣＨのリソースプールの第１のスロットを基準でｏｆｆｓｅｔを指示する。
【0146】
＊Ａｌｔ－２：ＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を指示した時、これを受信したスロット以後にＰＳＳＣＨリソースプールに属する第１のスロットを初期送信の時間上の位置に決定する。
【0147】
また、前記のようにＵＥ－ＡがＵＥ－Ｂにリソース割り当て情報を介して同じな一つのＴＢに対する初期及び再送信リソースの位置が指示された時、ＵＥ－Ｂは上位で指示された予約周期（Ｒｅｓｏｕｒｃｅ ｒｅｓｅｒｖａｔｉｏｎ ｐｅｒｉｏｄ、Ｐ）に基づいて前記ＵＥ－Ａから指示された一つのＴＢに対するリソース位置を基準で周期的なリソース予約を行うこともできる。
【0148】
＜第４実施例＞
【0149】
第４実施例はサイドリンクで図７のようにサイドリンクから端末の間の協力を行う場合にＵＥ－Ａが直接センシング及びリソース割り当て過程（Ｍｏｄｅ ２）を介してＵＥ－Ｂでリソース割り当て情報を提供する方法を提供する。図８は、本開示の一実施例によるＵＥ－ＡがＵＥ－Ｂのリソース割り当てのためにリソース（再）選択及び再評価を行うのに必要なｓｅｎｓｉｎｇ ｗｉｄｏｗとｒｅｓｏｕｒｃｅ ｓｅｌｅｃｔｉｏｎ ｗｉｄｏｗを定義するための図面である。
【0150】
具体的に、図８では時点ｎでリソース（再）選択（ｒｅｓｏｕｒｃｅ（ｒｅ－）ｓｅｌｅｃｔｉｏｎ）に対するｔｒｉｇｇｅｒｉｎｇが行われて（再）選択ｔｒｉｇｇｅｒｉｎｇ時点ｎ以後にも持続的にセンシングを行って再評価（ｒｅ－ｅｖａｌｕａｔｉｏｎ）のためのｔｒｉｇｇｅｒｉｎｇがｎ’（ｎ’＞ｎ）で行われる例示が示されている。リソース（再）選択に対するｔｒｉｇｇｅｒｉｎｇをする条件は端末が他の端末からリソース割り当てリクエストを受けた時になることができる。具体的に、図７でＵＥ－ＢがＵＥ－ＡにＳＲを送信してＵＥ－Ａがこれを受信した時点になることができる。リソース(再)選択ｔｒｉｇｇｅｒｉｎｇが時点ｎで先ず発生された時、リソースが選択された以後の選択されたリソースに対する予約がＳＣＩでシグナリングされ以前に、時点ｎ’（ｎ’＞ｎ）で再評価（ｒｅ－ｅｖａｌｕａｔｉｏｎ）条件が満足される場合、リソース（再）選択に対するｔｒｉｇｇｅｒｉｎｇが再び発生されることができる。
【0151】
リソース（再）選択に対するｔｒｉｇｇｅｒｉｎｇが時点ｎで行われる時、ｓｅｎｓｉｎｇ ｗｉｎｄｏｗ８０１は［ｎ－Ｔ０、ｎ－Ｔｐｒｏｃ，０）で定義されることができる。ここで、Ｔ０はｓｅｎｓｉｎｇ ｗｉｎｄｏｗの開始時点でリソースプール情報で（ｐｒｅ－）ｃｏｎｆｉｇｕｒａｔｉｏｎされることができる。例えば、Ｔ０はｍｓ単位の量の整数であっても良いが、本開示はＴ０を特定値に限定しない。また、Ｔｐｒｏｃ，０はセンシングした結果を処理するのに必要な時間で定義されることができる。本開示はＴｐｒｏｃ，０で設定される値を特定値に限定しない。もし、Ｔｐｒｏｃ，０がｍｓ単位の量の整数やスロットの単位で定義される場合にｓｅｎｓｉｎｇ ｗｉｎｄｏｗ８０１は［ｎ－Ｔ０、ｎ－Ｔｐｒｏｃ，０］で定義されることができる。また、ｓｅｎｓｉｎｇ ｗｉｎｄｏｗはスロットｎ以前にリソースプールに属したｌｏｇｉｃａｌ ｓｌｏｔに変換されて設定された区間を意味することができる。
【0152】
次に、リソース（再）選択に対するｔｒｉｇｇｅｒｉｎｇが時点ｎで行われる時、ｒｅｓｏｕｒｃｅ ｓｅｌｅｃｔｉｏｎ ｗｉｎｄｏｗ（８０２）は［ｎ＋ＴＸ，ｎ＋Ｔ２］で決定されることができる。ここで、ＴＸは次のような条件によって決定されることができる。
【0153】
＊ＴＸ＝Ｔ１ ｉｆ Ｔｄ＜Ｔ１
【0154】
＊ＴＸ＝Ｔｄ ｉｆ Ｔｄ≧Ｔ１
【0155】
ここで、Ｔ１はスロット単位の値でＴ１≦Ｔｐｒｏｃ，１に対して端末具現で選択されることができる。Ｔｐｒｏｃ，１はリソースを割り当てるのに必要な処理時間が考慮された最大基準値で定義されることができる。例えば、当該値Ｔｐｒｏｃ，１は４ｍｓで固定されることができる。また、Ｔｄはサイドリンクから端末の間の協力を行うのに発生されるｄｅｌａｙが反映された値で定義されることができ、上位レイヤを介して設定されることができる。本開示はＴｐｒｏｃ，１及びＴｄで設定される値を特定値に限定しない。また、Ｔ２はＴＸより大きいスロットの単位の値でＴ２ｍｉｎ≦Ｔ２≦Ｒｅｍａｉｎｉｎｇ Ｐａｃｋｅｔ ｄｅｌａｙ ｂｕｄｇｅｔ（ＰＤＢ）を満足させる範囲のうちで端末が選択することができる。ここで、Ｔ２ｍｉｎは端末が小さすぎる値のＴ２を選択することを防止するためである。ここでｐｒｉｏｒｉｔｙによるＴ２ｍｉｎ値‘Ｔ２ｍｉｎ（ｐｒｉｏｒｉｔｙ）’は上位レイヤを介して設定されることができる。
【0156】
次に、リソース(再)選択に対するｔｒｉｇｇｅｒｉｎｇが時点ｎで行われる以後にも持続的にセンシングを行って再評価（ｒｅ－ｅｖａｌｕａｔｉｏｎ）を行う動作が考慮されることができる。時点ｎでリソース（再）選択に対するｔｒｉｇｇｅｒｉｎｇが行って送信リソースを割り当てた以後に持続的にセンシングを行って選択したリソースが送信に適合しないと判断される場合、時点ｎ’（ｎ’＞ｎ）で既に選択したリソース８０３を変更するためのｔｒｉｇｇｅｒｉｎｇが再評価（ｒｅ－ｅｖａｌｕａｔｉｏｎ）で定義されることができる。この時、再評価をｔｒｉｇｇｅｒｉｎｇする条件によってリソース８０６が再選択されることができる。端末がリソース（再）選択に対するｔｒｉｇｇｅｒｉｎｇが行われる時点ｎ以後に時点ｎ’（ｎ’＞ｎ）で選択したリソースに対する再評価をｔｒｉｇｇｅｒｉｎｇをする動作は、端末がリソース(再)選択に対するｔｒｉｇｇｅｒｉｎｇで選択したリソース８０３をｒｅｓｅｒｖａｔｉｏｎしない場合に行われることができる。この時、リソースに対するｒｅｓｅｒｖａｔｉｏｎは選択したリソースに対する情報を他の端末で提供する動作に解釈されることもできる。したがって、前記条件は図７でＵＥ－ＡがＵＥ－Ｂのために選択したリソースに対する情報を前記‘ＵＥ－ＡがＵＥ－Ｂにリソース割り当て情報を提供する方法’を介して指示する以前で定義されることもできる。図８に再評価をｔｒｉｇｇｅｒｉｎｇをする時点ｎ’（ｎ’＞ｎ）に対するｓｅｎｓｉｎｇ ｗｉｎｄｏｗ８０４とｒｅｓｏｕｒｃｅ ｓｅｌｅｃｔｉｏｎ ｗｉｎｄｏｗ８０５が共に図示された。
【0157】
本発明でＵＥ－Ａが端末の間協力のための情報を提供する端末で、ＵＥ－Ｂが端末の間の協力のための情報が提供されてサイドリンク送信を行う端末で定義した時、ＵＥ－Ａはｒｅｓｏｕｒｃｅ ｓｅｌｅｃｔｉｏｎ ｗｉｎｄｏｗの内でリソース割り当てのための候補リソースをＩｄｅｎｔｉｆｉｃａｔｉｏｎする動作とＩｄｅｎｔｉｆｉｃａｔｉｏｎされたリソース候補から送信のためのリソースを割り当てる動作を行って一つのＴＢに対するＮ≦Ｎｍａｘ個のリソースを割り当てて、これに対する周波数－時間リソース割り当て情報をＵＥ－Ｂに伝達することができる。
【0158】
＜第５実施例＞
【0159】
第５実施例では前記第１実施例から第４実施例を介してサイドリンクから端末の間の協力を行う全体的なフローチャートを図９を介して説明する。図９でＵＥ－Ａは端末の間協力のための情報を提供する端末に該当し、ＵＥ－Ｂは端末の間の協力のための情報が提供されてサイドリンク送信を行う端末に該当する。図９に示されたフローチャートは第１実施例から第４実施例で提案された方法をいずれも含んでいるがサイドリンクで端末の間の協力を行う動作でこの中の一部動作が省略されるか一部動作だけが行われることもできることに注目する。
【0160】
先ず、図９の９０１は第１実施例で提案されたサイドリンクで端末の間の協力を行う場合にリソースプール情報を共有する動作を示す。９０１に示されたようにリソースプールの共有はＵＥ－ＡからＵＥ－Ｂに、又はＵＥ－ＢからＵＥ－Ａに、若しくは両方向で行うことができ、第１実施例の‘端末の間のリソースプール情報を共有するための方法’を参考する。端末の間の協力のために用いられるリソースプールが一つ以上設定された時、９０２段階のようにＵＥ－Ａは好むリソースプール情報をＵＥ－Ｂに指示することができる。一実施例で、もし、端末の間の協力のために用いられるリソースプールが一つだけ設定されるか、複数個のリソースプールが設定されたが好むリソースプール情報が予め決定された規則に従って決定されることができる場合のように別途のシグナリングが必要ではない場合には９０２段階は省略されることもできる。
【0161】
次に、図９の９０３は第２実施例で提案されたＵＥ－ＢがＵＥ－Ａにリソース割り当てをリクエストする動作を示す。これはＵＥ－ＢがＵＥ－ＡにＳＲ（Ｓｃｈｅｄｕｌｉｎｇ Ｒｅｑｕｅｓｔ）を送信する動作で解釈されることができる。この時のＵＥ－ＢはＵＥ－ＡがＵＥ－Ｂに対するリソース割り当てのために必要な情報をＳＲと共に又は別にＵＥ－Ａに伝達することができる。この時のＵＥ－Ｂがリソース割り当てのためにＵＥ－Ａへ伝達することができる関連情報は前記の‘リソース割り当て情報が提供されるためにＵＥ－ＢがＵＥ－Ａで提供する情報’を参考する。ＵＥ－ＡがＵＥ－ＢからＳＲがリクエストされた時、ＵＥ－Ａは基地局にＵＥ－Ｂのリソース割り当てをリクエストするかＵＥ－Ａが直接センシングを介してＵＥ－Ｂのためのリソースを割り当ててＵＥ－Ｂにリソース割り当て情報を提供することができる。ＵＥ－Ａが直接センシングを介してＵＥ－Ｂのためのリソースを割り当てる詳細動作は第４実施例を参考する。ＵＥ－Ａが直接センシングを介してＵＥ－Ｂのためのリソースを割り当てる選択する動作を行う時、当該リソースプールＵＥ－Ａのサイドリンク送信のためのリソース割り当ての可能なプールの場合に端末は該当プールでＵＥ－Ｂのためのリソース割り当てとＵＥ－Ａのサイドリンク送信のためのセンシング及びリソース割り当て動作を同時に行うこともできる。この時、同じのＳｅｎｓｉｎｇ ｗｉｎｄｏｗとＲｅｓｏｕｒｃｅ ｓｅｌｅｃｔｉｏｎ ｗｉｎｄｏｗが仮定されることもできる。しかし、ＵＥ－Ｂのためのリソース割り当てを行うリソースプールとＵＥ－Ａのサイドリンク送信のためのリソースプールが区分される場合に端末は各当該リソースプールでセンシング及びリソース割り当て動作をそれぞれ行うこともできる。
【0162】
最後に、図９の９０４は第３実施例で提案されたＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供する動作が図示された。リソース割り当て情報を指示する方法及びリソース割り当て情報に対する詳細内容は第３実施例を参考する。ＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供した時のＵＥ－Ｂは当該情報を参照だけし、サイドリンク送信リソースで選択するかどうかを選択するように動作することができる。又は、これと異なり、ＵＥ－ＡがＵＥ－Ｂでリソース割り当て情報を提供した時のＵＥ－Ｂは当該情報を利用してサイドリンク送信を行うように動作することができる。後者の場合、ＵＥ－Ｂがサイドリンク送信リソース割り当てのためのＭｏｄｅ２動作を別に行わなくて良いため、当該端末は電力消耗を減らすことができる利点がある。
【0163】
本発明の前記実施例を行うために端末と基地局の送信部、受信部、処理部がそれぞれの図１０及び図１１に示されている。前記実施例でサイドリンクで端末がセンシング及びリソース割り当てを行うための方法が示され、これを行うために基地局と端末の受信部、処理部、送信部がそれぞれ実施例によって動作することができる。
【0164】
具体的に、図１０は本発明の実施例による端末の内部構造を示すブロック図である。
【0165】
図１０で示されるように、本発明の端末は端末機受信部１０００、端末機送信部１００４、端末機処理部１００２を含むことができる。端末機受信部１０００と端末機送信部１００４を通称して本発明の実施例では送受信部と称することができる。送受信部は基地局と信号を送受信することができる。前記信号は制御情報と、データを含むことができる。このために、送受信部は送信される信号の周波数を上昇変換及び増幅するＲＦ送信機と、受信される信号を低雑音増幅して周波数を下降変換するＲＦ受信機などから構成されることができる。また、送受信部は無線チャンネルを介して信号を受信して端末機処理部１００２に出力し、端末機処理部１００２から出力された信号を無線チャンネルを介して送信することができる。端末機処理部１００２は上述した本発明の実施例によって端末が動作するように一連の過程を制御することができる。
【0166】
図１１は、本発明の実施例による基地局の内部構造を示すブロック図である。
【0167】
図１１で示されるように、本発明の基地局は基地局受信部１１０１、基地局送信部１１０５、基地局処理部１１０３を含むことができる。基地局受信部１１０１と基地局送信部１１０５を通称して本発明の実施例では送受信部と称することができる。送受信部は端末と信号を送受信することができる。前記信号は制御情報と、データを含むことができる。このために、送受信部は送信される信号の周波数を上昇変換及び増幅するＲＦ送信機と、受信される信号を低雑音増幅して周波数を下降変換するＲＦ受信機などから構成されることができる。また、送受信部は無線チャンネルを介して信号を受信して基地局処理部１１０３に出力し、基地局処理部１１０３から出力された信号を無線チャンネルを介して送信することができる。基地局処理部１１０３は上述した本発明の実施例によって基地局が動作するように一連の過程を制御することができる。
【0168】
一方、本明細書と図面に開示された本発明の実施例は本発明の技術内容を容易に説明して本発明の理解を助けるために特定例を提示したことだけ、本発明の範囲を限定しようとすることではない。すなわち、本発明の技術的思想に基づいた他の変形例が実施可能であるということは本発明の属する技術分野で通常の知識を有する者に自明なことである。また、前記のそれぞれの実施例は必要によって互いに組み合せて操作することができる。例えば、本発明のすべての実施例は一部分が互いに組み合せて基地局と端末が操作されることができる。
【符号の説明】
【0169】
４０１ 送信端末
４０２ 受信端末
４０３ 基地局
５０１ 送信端末
５０２ 受信端末
５０３ 基地局
１０００ 端末機受信部
１００２ 端末機処理部
１００４ 端末機送信部
１１０１ 基地局受信部
１１０３ 基地局処理部
１１０５ 基地局送信部
４０２ 受信端末
４０３ 基地局
５０１ 送信端末
５０２ 受信端末
５０３ 基地局
１０００ 端末機受信部
１００２ 端末機処理部
１００４ 端末機送信部
１１０１ 基地局受信部
１１０３ 基地局処理部
１１０５ 基地局送信部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【手続補正書】
【提出日】2022-08-23
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
通信システムの第１端末の方法において、
端末間協力（ｉｎｔｅｒ－ＵＥ ｃｏｏｒｄｉｎａｔｉｏｎ）情報をリクエストする第１情報を第２端末から受信する段階と、
前記端末間協力情報を提供する第２情報を前記第２端末に送信する段階と、
前記端末間協力情報に基づいて選択されたリソースで、ＰＳＳＣＨ（ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）又はＰＳＣＣＨ（ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）を前記第２端末から受信する段階と、
を含み、
前記第１情報は、優先順位についての情報及びサブチャンネルの数についての情報を含むことを特徴とする方法。
【請求項2】
前記端末間協力情報をリクエストする第１情報は、２
ｎｄ
－ｓｔａｇｅ ＳＣＩ（ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）又はＭＡＣ ＣＥ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｃｏｎｔｒｏｌ ｅｌｅｍｅｎｔ）を通じて受信されることを特徴とする、請求項１に記載の方法。
【請求項3】
前記端末間協力情報を提供する第２情報は、２
ｎｄ
－ｓｔａｇｅ ＳＣＩ（ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）又はＭＡＣ ＣＥ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｃｏｎｔｒｏｌ ｅｌｅｍｅｎｔ）を通じて送信されることを特徴とする、請求項１に記載の方法。
【請求項4】
前記第１情報は、リソース予約周期についての情報及びリソース選択ウィンドウについての情報を含むことを特徴とする、請求項１に記載の方法。
【請求項5】
通信システムの第２端末の方法において、
端末間協力（ｉｎｔｅｒ－ＵＥ ｃｏｏｒｄｉｎａｔｉｏｎ）情報をリクエストする第１情報を第１端末に送信する段階と、
前記端末間協力情報を提供する第２情報を前記第１端末から受信する段階と、
前記端末間協力情報に基づいて選択されたリソースで、ＰＳＳＣＨ（ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）又はＰＳＣＣＨ（ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）を前記第１端末に送信する段階と、
を含み、
前記第１情報は、優先順位についての情報及びサブチャンネルの数についての情報を含むことを特徴とする方法。
【請求項6】
前記端末間協力情報をリクエストする第１情報は、２
ｎｄ
－ｓｔａｇｅ ＳＣＩ（ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）又はＭＡＣ ＣＥ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｃｏｎｔｒｏｌ ｅｌｅｍｅｎｔ）を通じて送信されることを特徴とする、請求項５に記載の方法。
【請求項7】
前記端末間協力情報を提供する第２情報は、２
ｎｄ
－ｓｔａｇｅ ＳＣＩ（ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）又はＭＡＣ ＣＥ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｃｏｎｔｒｏｌ ｅｌｅｍｅｎｔ）を通じて受信されることを特徴とする、請求項５に記載の方法。
【請求項8】
前記第１情報は、リソース予約周期についての情報及びリソース選択ウィンドウについての情報を含むことを特徴とする、請求項５に記載の方法。
【請求項9】
通信システムの第１端末において、
送受信部と、
端末間協力（ｉｎｔｅｒ－ＵＥ ｃｏｏｒｄｉｎａｔｉｏｎ）情報をリクエストする第１情報を第２端末から受信し、前記端末間協力情報を提供する第２情報を前記第２端末に送信し、前記端末間協力情報に基づいて選択されたリソースで、ＰＳＳＣＨ（ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）又はＰＳＣＣＨ（ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）を前記第２端末から受信するように構成される制御部と、
を含み、
前記第１情報は、優先順位についての情報及びサブチャンネルの数についての情報を含むことを特徴とする第１端末。
【請求項10】
前記端末間協力情報をリクエストする第１情報は、２
ｎｄ
－ｓｔａｇｅ ＳＣＩ（ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）又はＭＡＣ ＣＥ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｃｏｎｔｒｏｌ ｅｌｅｍｅｎｔ）を通じて受信されることを特徴とする、請求項９に記載の第１端末。
【請求項11】
前記端末間協力情報を提供する第２情報は、２
ｎｄ
－ｓｔａｇｅ ＳＣＩ（ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）又はＭＡＣ ＣＥ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｃｏｎｔｒｏｌ ｅｌｅｍｅｎｔ）を通じて送信されることを特徴とする、請求項９に記載の第１端末。
【請求項12】
前記第１情報は、リソース予約周期についての情報及びリソース選択ウィンドウについての情報を含むことを特徴とする、請求項９に記載の第１端末。
【請求項13】
通信システムの第２端末において、
送受信部と、
端末間協力（ｉｎｔｅｒ－ＵＥ ｃｏｏｒｄｉｎａｔｉｏｎ）情報をリクエストする第１情報を第１端末に送信し、前記端末間協力情報を提供する第２情報を前記第１端末から受信し、前記端末間協力情報に基づいて選択されたリソースで、ＰＳＳＣＨ（ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）又はＰＳＣＣＨ（ｐｈｙｓｉｃａｌ ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）を前記第１端末に送信するように構成される制御部と、
を含み、
前記第１情報は、優先順位についての情報及びサブチャンネルの数についての情報を含むことを特徴とする第２端末。
【請求項14】
前記端末間協力情報をリクエストする第１情報は、２
ｎｄ
－ｓｔａｇｅ ＳＣＩ（ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）又はＭＡＣ ＣＥ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｃｏｎｔｒｏｌ ｅｌｅｍｅｎｔ）を通じて送信されることを特徴とする、請求項１３に記載の第２端末。
【請求項15】
前記端末間協力情報を提供する第２情報は、２
ｎｄ
－ｓｔａｇｅ ＳＣＩ（ｓｉｄｅｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）又はＭＡＣ ＣＥ（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｃｏｎｔｒｏｌ ｅｌｅｍｅｎｔ）を通じて受信されることを特徴とする、請求項１３に記載の第２端末。
【国際調査報告】