JPWO2019064983A1 - 通信装置 - Google Patents

通信装置 Download PDF

Info

Publication number
JPWO2019064983A1
JPWO2019064983A1 JP2019544408A JP2019544408A JPWO2019064983A1 JP WO2019064983 A1 JPWO2019064983 A1 JP WO2019064983A1 JP 2019544408 A JP2019544408 A JP 2019544408A JP 2019544408 A JP2019544408 A JP 2019544408A JP WO2019064983 A1 JPWO2019064983 A1 JP WO2019064983A1
Authority
JP
Japan
Prior art keywords
feedback
resource
communication
data
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2019544408A
Other languages
English (en)
Other versions
JP7230815B2 (ja
Inventor
博允 内山
博允 内山
寿之 示沢
寿之 示沢
直紀 草島
直紀 草島
大輝 松田
大輝 松田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Publication of JPWO2019064983A1 publication Critical patent/JPWO2019064983A1/ja
Application granted granted Critical
Publication of JP7230815B2 publication Critical patent/JP7230815B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1861—Physical mapping arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053—Allocation of signaling, i.e. of overhead other than pilot signals
    • H04L5/0055—Physical resource allocation for ACK/NACK
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/04—Error control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/26—Resource reservation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/02—Selection of wireless resources by user or terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/27—Transitions between radio resource control [RRC] states
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/18—Interfaces between hierarchically similar devices between terminal devices

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

端末間で直接通信を行う通信装置を提供する。通信装置は、無線信号を送受信する通信部と、前記通信部による、所定のリソースプールを用いたデータの送信と、前記データの送信先の端末からのフィードバックの受信を制御する制御部を具備する。前記制御部は、前記データの送信用のリソース及び前記データの送信先の端末のための前記フィードバック用リソースを前記所定のリソースプール内で確保し、前記送信先の端末に対してＳＣＩを用いて前記フィードバック用リソースに関する情報を通知するように制御する。

Description

本明細書で開示する技術は、端末間で直接通信を行う通信装置に関する。
将来の自動運転の実現のため、近年、車載通信（Ｖ２Ｘ通信）への期待が高まってきている。Ｖ２Ｘ通信とは、Ｖｅｈｉｃｌｅｔｏ Ｘ通信の略であり、車と「何か」が通信を行うシステムである。ここでの「何か」の例として、Ｖｅｈｉｃｌｅ、 Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ、Ｐｅｄｅｓｔｒｉａｎなどが挙げられる（Ｖ２Ｖ、Ｖ２Ｉ／Ｎ、Ｖ２Ｐ）。
自動車向けの無線通信としては、これまで主に、ＩＥＥＥ８０２．１１ｐベースのＤＳＲＣ（Ｄｅｄｉｃａｔｅｄ Ｓｈｏｒｔ Ｒａｎｇｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）の開発が進められてきた。近年になり、３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）において、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）ベースの車載通信である“ＬＴＥ−ｂａｓｅｄＶ２Ｘ”の標準規格化が行われた。３ＧＰＰにおいては、さらに、５Ｇ（ＮＲ：Ｎｅｗ Ｒａｄｉｏ）において、Ｖ２Ｘの標準化活動が継続している。
特開２０１７−１３９６５９号公報 特開２０１７−１３９６６１号公報
本明細書で開示する技術の目的は、端末間で直接通信を行う通信装置を提供することにある。
本明細書で開示する技術の第１の側面は、
無線信号を送受信する通信部と、
前記通信部による、所定のリソースプールを用いたデータの送信と、前記データの送信先の端末からのフィードバックの受信を制御する制御部と、
を具備する通信装置である。第１の側面に係る通信装置は、例えば、Ｖ２Ｘ通信においてサイドリンクの送信端末として好適に動作することができる。
前記制御部は、前記データの送信用のリソース及び前記データの送信先の端末のための前記フィードバック用リソースを前記所定のリソースプール内で確保し、確保した前記フィードバック用リソースを前記送信先の端末に通知するように、さらに制御する。
また、前記制御部は、前記フィードバックを受信したことに応答して、前記データの再送をさらに制御する。例えば、前記制御部は、再送上限数、受信したＮＡＣＫ数、送信した前記データの優先度、前記データ及び前記フィードバックを送受信するリンクのチャネル状況、又は、前記送信先の端末におけるデータ再送に関するプロセス状況のうち少なくとも１つからなる条件に基づいて、データ再送を行うかどうかを判断する。
また、本明細書で開示する技術の第２の側面は、
端末からのアップリンクの無線信号を受信し、端末へのダウンリンクの無線信号を送信する通信部と、
前記端末間で通信するサイドリンクのためのリソースの割り当てを制御する制御部と、
を具備し、
前記制御部は、前記サイドリンクに割り当てたリソースプール内でフィードバック用リソースを割り当てる、
通信装置である。第２の側面に係る通信装置は、例えば、Ｖ２Ｘ通信において基地局として動作することができる。
前記制御部は、前記所定のリソースプール内に前記フィードバック用リソースを周期的に割り当てて、前記端末に通知するように、さらに制御する。また、前記制御部は、符号化多重又はプリアンブル送信を用いて、同じリソースを複数の端末の前記フィードバック用リソースに多重化するようにしてよい。
また、本明細書で開示する技術の第３の側面は、
無線信号を送受信する通信部と、
前記通信部による、所定のリソースプールを用いて送信されたデータの受信と、前記データの送信元の端末へのフィードバックの送信を制御する制御部と、
を具備する通信装置である。第３の側面に係る通信装置は、例えば、Ｖ２Ｘ通信においてサイドリンクの受信端末として好適に動作することができる。
前記制御部は、前記送信元の端末が確保したフィードバック用リソースを用いてフィードバックを送信するように制御する。
あるいは、前記制御部は、基地局が前記所定のリソースプール内に周期的に割り当てたフィードバック用リソースを用いてフィードバックを送信するように制御する。
本明細書で開示する技術によれば、端末間で直接通信を行う通信装置を提供することができる。
なお、本明細書に記載された効果は、あくまでも例示であり、本発明の効果はこれに限定されるものではない。また、本発明が、上記の効果以外に、さらに付加的な効果を奏する場合もある。
本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
図１は、Ｖ２Ｘ通信の概要を示した図である。 図２は、Ｖ２Ｖ通信の第１のシナリオを示した図である。 図３は、Ｖ２Ｖ通信の第２のシナリオを示した図である。 図４は、Ｖ２Ｖ通信の第３のシナリオを示した図である。 図５は、Ｖ２Ｖ通信の第４のシナリオを示した図である。 図６は、Ｖ２Ｖ通信の第５のシナリオを示した図である。 図７は、Ｖ２Ｘ通信が実施される無線通信システムの構成例を模式的に示した図である。 図８は、車両などの移動体に搭載して用いられる通信装置（ＵＥ）の機能的構成例を模式的に示した図である。 図９は、フィードバック型サイドリンク通信におけるＨＡＲＱオペレーションの例を示した図である。 図１０は、サイドリンク通信時において送信端末が受信端末からのフィードバックに対応するための処理手順を示したフローチャートである。 図１１は、サイドリンク通信時において受信端末が送信端末に対して情報をフィードバックするための処理手順を示したフローチャートである。 図１２は、基地局がサイドリンクにおけるフィードバック用リソースの割り当てを行う通信シーケンス例を示した図である。 図１３は、サイドリンク用のリソースプール内にフィードバック用のリソースプールを設けた様子を示した図である。 図１４は、送信端末がサイドリンクにおけるフィードバック用リソースの割り当てを行う通信シーケンス例を示した図である。 図１５は、フィードバック用リソースの割り当て例を示した図である。 図１６は、受信端末がフィードバック信号を送信するための処理手順を示したフローチャートである。 図１７は、受信端末がフィードバック信号を送信するための処理手順を示したフローチャートである。 図１８は、データ送信を基準として複数の受信端末にフィードバック用リソースを割り当てた例を示した図である。 図１９は、送信端末が再送制御するための処理手順を示したフローチャートである。 図２０は、基地局（Ｅ−ＵＴＲＡＮ、ｅＮＢ）として動作する通信装置の機能的構成例を模式的に示した図である。
以下、図面を参照しながら本明細書で開示する技術の実施形態について詳細に説明する。
Ａ．システム構成
車両などの移動体に通信装置を搭載することによって、移動体と種々の対象物との間で直接的な通信が実現される。とりわけ、車両と種々の対象物との間の通信はＶ２Ｘ通信と呼ばれる。図１には、Ｖ２Ｘ通信の概要を示している。図示のように、Ｖ２Ｘ通信として、Ｖ２Ｖ（Ｖｅｈｉｃｌｅ ｔｏ Ｖｅｈｉｃｌｅ）通信、Ｖ２Ｉ（Ｖｅｈｉｃｌｅ ｔｏ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）通信、Ｖ２Ｐ（Ｖｅｈｉｃｌｅ ｔｏ Ｐｅｄｅｓｔｒｉａｎ）通信、Ｖ２Ｈ（Ｖｅｈｉｃｌｅ ｔｏ Ｈｏｍｅ）通信などが挙げられる。また、図示を省略するが、Ｖ２Ｎ（Ｖｅｈｉｃｌｅ ｔｏ Ｎｅｔｗｏｒｋ）通信も、Ｖ２Ｘ通信に含まれる。なお、Ｖ２Ｘ通信の１文字目と３文字目は、それぞれ通信の始点と終点を意味しており、通信経路を限定するものではない。例えば、Ｖ２Ｖ通信は、車両同士が直接的に通信することと、基地局などを介して車両同士が間接的に通信することの両方を含む概念である。
Ｖ２Ｖ通信における車両の通信対象として、乗用車（ｐａｓｓｅｎｇｅｒ ｖｅｈｉｃｌｅ）、商用車（Ｃｏｍｍｅｒｃｉａｌ ｏｒ ｆｌｅｅｔ ｖｅｈｉｃｌｅ）、緊急車両（Ｅｍｅｒｇｅｎｃｙ ｖｅｈｉｃｌｅ）、輸送車（Ｔｒａｎｓｉｔ ｖｅｈｉｃｌｅ）などが挙げられる。また、Ｖ２Ｉ通信における車両の通信対象として、セルラーネットワーク（Ｃｅｌｌｕｌｅｒ ｎｅｔｗｏｒｋ）、データセンタ（Ｄａｔａ ｃｅｎｔｒｅ）、商用車管理センタ（ｆｌｅｅｔ ｏｒ ｆｒｅｉｇｈｔ ｍａｎａｇｅｍｅｎｔ ｃｅｎｔｒｅ）、交通管理センタ（Ｔｒａｆｆｉｃ ｍａｎａｇｅｍｅｎｔ ｃｅｎｔｒｅ）、気象サービス（Ｗｅａｔｈｅｒ ｓｅｒｖｉｃｅ）、列車運行センタ（Ｒａｉｌ ｏｐｅｒａｔｉｏｎ ｃｅｎｔｒｅ）、駐車システム（Ｐａｒｋｉｎｇ ｓｙｓｔｅｍ）、料金システム（Ｔｏｌｌ ｓｙｓｔｅｍ）などが挙げられる。また、Ｖ２Ｐ通信における車両の通信対象として、自転車の運転者（Ｃｙｃｌｉｓｔ）、歩行者用シェルタ（Ｐｅｄｅｓｔｒｉａｎ ｓｈｅｌｔｅｒ）、自動二輪（Ｍｏｔｏｒｃｙｃｌｅ）などが挙げられる。また、Ｖ２Ｈ通信における車両の通信対象として、家庭用ネットワーク（Ｈｏｍｅ ｎｅｔｗｏｒｋ）、車庫（Ｇａｒａｇｅ）、商用ネットワーク（Ｅｎｔｅｒｐｒｉｓｅ ｏｒ ｄｅｅｌｅｒ ｎｅｔｗｏｒｋｓ）などが挙げられる。
自動車向けの無線通信としては、これまで主にＩＥＥＥ８０２．１１ｐベースのＤＳＲＣの開発が進められてきたが、近年になり、３ＧＰＰにおいてＬＴＥ−ｂａｓｅｄＶ２Ｘの標準規格化が行われた（前述）。ＬＴＥベースのＶ２Ｘ通信では、基本的なセーフティメッセージなどのやり取りなどがサポートされている。
一方で、さらなるＶ２Ｘ通信の改善をめざし、３ＧＰＰでは５Ｇ技術を用いたｅＶ２Ｘ（ｅｎｈａｎｃｅｄ Ｖ２Ｘ）通信の検討が行われている。ｅＶ２Ｘ通信では、これまでＬＴＥベースのＶ２Ｘではサポートできなかったような、高信頼性、低遅延、高速通信、及びハイキャパシティを必要とする新たなユースケースをサポートする。ｅＶ２Ｘ向けのユースケース及び要求事項は３ＧＰＰ ＴＲ２２．８８６に記載されている。ｅＶ２Ｘによってサポートされる主なユースケースとして、以下の（１）〜（４）が挙げられる。
（１）Ｖｅｈｉｃｌｅ Ｐｌａｔｏｏｎｎｉｎｇ
複数の車両が隊列となり、同じ方向に走行する、隊列走行のユースケースであり、隊列走行を主導する車から隊列走行を制御するための情報をやり取りする。これらの情報のやりとりにより、隊列走行の車間距離をより詰めることが可能となる。
（２）Ｅｘｔｅｎｄｅｄ Ｓｅｎｓｏｒｓ
センサー関連の情報（データ処理前のＲａｗデータや処理されたデータ）を車車間などで交換することを可能とする。センサー情報は、ローカルセンサーや、周辺の車両やＲＳＵ（Ｒｏａｄ Ｓｉｄｅ Ｕｎｉｔ：路側ユニット）や歩行者間のライブビデオイメージやＶ２Ｘアプリケーションサーバーなどを通して集められる。車両はこれらの情報交換により、自身のセンサー情報では得られない情報を入手することができ、より広範囲の環境を認知若しくは認識することが可能となる。多くの情報を交換する必要があるため、通信には高いデータレートが求められる。
（３）Ａｄｖａｎｃｅｄ Ｄｒｉｖｉｎｇ
準自動走行や、完全自動走行を可能とする。それぞれの車両はＲＳＵが自身のセンサーなどから得られた認知／認識情報を周辺車両へとシェアすることで、車両の軌道や操作を同期、協調しながら調整することができる。それぞれの車両は、ドライビングの意図や意思を周辺車両とシェアすることも可能である。
（４）Ｒｅｍｏｔｅ Ｄｒｉｖｉｎｇ
遠隔操縦者やＶ２Ｘアプリケーションに遠隔操縦させる。運転ができない人や、危険地域に対して遠隔操作が用いられる。ルートや走行する道がある程度決まっているような公共交通機関に対しては、クラウドコンピューティングをベースとした操縦を用いることも可能である。高い信頼性と低い伝送遅延が通信には求められる。
上述したようなユースケース（１）〜（４）を実現するためには、ｅＶ２Ｘ通信の物理レイヤのエンハンスメントが必要となる。主なエンハンスメントとしては、インフラ、端末間通信の改善、及び端末間通信の改善が挙げられる。インフラ、端末間通信としては、Ｖ２Ｎ通信並びにＶ２Ｉ（ｅＮＢ（ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ） ｔｙｐｅ ＲＳＵ：基地局型ＲＳＵ）通信が改善の対象となる。また、端末間通信としては、Ｖ２Ｖ通信並びにＶ２Ｐ通信が改善の対象となる。これらＶ２Ｘ通信の物理レイヤにおいて必要と考えられる主なエンハンスメントのポイントを以下に示す。
・チャネルフォーマット
−Ｆｌｅｘｉｂｌｅ ｎｕｍｅｒｏｌｏｇｙ
−ｓｈｏｒｔ ＴＴＩ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ Ｉｎｔｅｒｖａｌ）
−マルチアンテナ対応
−Ｗａｖｅｆｏｒｍエンハンスメント
・サイドリンクフィードバック通信
−ＨＡＲＱ（Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）
−ＣＳＩ（Ｃｈａｎｎｅｌ Ｓｔａｔｕｓ Ｉｎｆｏｒｍａｔｉｏｎ）
・サイドリンク通信におけるリソース割り当て方式
・車両位置情報推定技術
・端末間リレー通信
・ユニキャスト通信、マルチキャスト通信のサポート
・マルチキャリア通信、キャリアアグリゲーション
・高周波周波数（ミリ波）対応（例：６ＧＨｚ以上）
Ｖ２Ｘ通信のオペレーションシナリオはさまざまである。Ｖ２Ｘ通信のオペレーションシナリオは、Ｖ２Ｖ通信をベースに構成され、片方の自動車がＰｅｄｅｓｒｉａｎになるとＶ２Ｐ通信となり、ＩｎｆｒａｓｔｒｕｃｔｕｒｅやＮｅｔｗｏｒｋで終端するとＶ２Ｉ通信又はＶ２Ｎ通信となる。図２〜図６には、Ｖ２Ｘ通信のベースとなるＶ２Ｖ通信のシナリオを例示している。
図２には、Ｖ２Ｖ通信の第１のシナリオを示している。第１のシナリオでは、車両などの移動体同士が直接的にＶ２Ｖ通信を行う。この場合の車両同士が直接的に通信を行う通信リンクは、ＳＬ（サイドリンク）である。
図３には、Ｖ２Ｖ通信の第２のシナリオを示している。第２のシナリオでは、車両などの移動体同士が、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ）を介して、すなわち基地局を介して間接的にＶ２Ｖ通信を行う。送信側から基地局への通信リンクはＵＬ（アップリンク）であり、基地局から受信側への通信リンクはＤＬ（ダウンリンク）である。
図４には、Ｖ２Ｖ通信の第３のシナリオを示している。第３のシナリオでは、車両などの移動体が、ＲＳＵ又はＲＳＵタイプのユーザ端末（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ＵＥ）、及びＥ−ＵＴＲＡＮを順に介して他の移動体へ信号を送信する。各装置間の通信リンクは、順にＳＬ、ＵＬ、及びＤＬである。
図５には、Ｖ２Ｖ通信の第４のシナリオを示している。第４のシナリオでは、車両などの移動体が、Ｅ−ＵＴＲＡＮ、及びＲＳＵ又はＲＳＵタイプのＵＥを順に介して他の移動体へ信号を送信する。各装置間の通信リンクは、順にＵＬ、ＤＬ及びＳＬである。
図６には、Ｖ２Ｖ通信の第５のシナリオを示している。第５のシナリオでは、車両などの移動体同士が、ＲＳＵ又はＲＳＵタイプのＵＥを介して間接的にＶ２Ｖ通信を行う。移動体とＲＳＵ又はＲＳＵタイプのＵＥとの間の通信リンクは、ＳＬである。
図２〜図６に示した各シナリオは、移動体の片方を歩行者に変えると、Ｖ２Ｐ通信のシナリオとなる。同様に、各シナリオは、移動体の片方をインフラ又はネットワークに変えると、それぞれＶ２Ｉ通信又はＶ２Ｎ通信のシナリオとなる。
本明細書では、ｅＶ２Ｘ通信の物理レイヤのエンハンスメント（前述）のうち、とりわけサイドリンクフィードバック通信に着目する。
これまでのＶ２Ｘ通信においては、サイドリンクはブロードキャスト通信が採用されていた（例えば、特許文献１を参照のこと）。送信端末は受信端末からのフィードバックが得られないことから、初めから複数回繰り返し送信を行うことで信頼性の向上を行っている。すなわち、従来のサイドリンク通信では、物理層レベルでブロードキャスト信号が複数回送信され、受信側では取り敢えずすべての信号を受信して、上位レイヤにおいて受信信号が自分宛かどうかを判断する。したがって、再送の概念がそもそもない。しかしながら、このような繰り返し送信を行うような通信では、再送の仕組みがないことから信頼性を担保することが難しい。また、繰り返し送信により余分に周波数リソースを消費するので、周波数利用効率の観点からもあまり望ましくない。
そこで、本明細書では、受信側からのＨＡＲＱやチャネル情報などのフィードバックをベースに通信を行うフィードバック型サイドリンク通信に関して提案する。受信側がフィードバック信号（例えば、ＡＣＫ／ＮＡＣＫ、伝搬環境情報など）を送信することにより、信頼性が向上する。また、物理層レベルでブロードキャスト信号が複数回送信される場合と比較して、周波数利用効率が向上する。但し、フィードバック型サイドリンク通信の詳細については、後述に譲る。
図７には、Ｖ２Ｘ通信が実施される無線通信システムの構成例を模式的に示している。図示の無線通信システムは、ＵＥ１０と、ＵＥ２０と、車両２２と、ｅＮＢ（基地局）３０と、ＧＮＳＳ（Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ）衛星４０と、ＲＳＵ５０で構成される。
ｅＮＢ３０は、セル内に位置するＵＥ２０にセルラー通信サービスを提供するセルラー基地局である。例えば、ｅＮＢ３０は、ＵＥ１０及びＵＥ２０が通信するためのリソースをスケジュールし、スケジュールしたリソースをＵＥ１０及びＵＥ２０に通知する。そして、ｅＮＢ３０は、当該リソースにおいてＵＥ１０及びＵＥ２０との間でアップリンク通信又はダウンリンク通信を行う。
ＧＮＳＳ衛星４０は、地球を所定の軌道に沿って周回する人工衛星（通信装置）である。ＧＮＳＳ衛星４０は、航法メッセージを含むＧＮＳＳ信号を送信する。航法メッセージは、ＧＮＳＳ衛星４０の軌道情報及び時間情報などの、位置測定のための種々の情報を含む。
ＲＳＵ５０は、道路脇に設置される通信装置である。ＲＳＵ５０は、車両２２若しくは車両２２に搭載されたＵＥ２０、又はユーザ１２が携行するＵＥ１０と双方向通信を行うことができる。なお、ＲＳＵ５０は、車両２２若しくは車両２２に搭載されたＵＥ２０、又はユーザ１２が携行するＵＥ１０とＤＳＲＣ通信を行うことができる。また、本実施形態では、ＲＳＵ５０が、車両２２若しくは車両２２に搭載されたＵＥ２０、又はユーザ１２が携行するＵＥ１０とセルラー通信の方式に従って通信することも想定される。
ＵＥ２０は、車両２２に搭載され、車両２２の走行に伴って移動する通信装置である。ＵＥ２０は、ｅＮＢ３０による制御に従ってｅＮＢ３０と通信する機能を有する。また、ＵＥ２０は、ＧＮＳＳ衛星４０から送信されるＧＮＳＳ信号を受信し、ＧＮＳＳ信号に含まれる航法メッセージからＵＥ２０の位置情報を測定する機能を有する。また、ＵＥ２０は、ＲＳＵ５０と通信する機能を有する。さらに、本実施形態によるＵＥ２０は、ユーザ１２に携行されるＵＥ１０、又は他の車両２２に搭載されたＵＥ２０と直接通信すること、すなわち、サイドリンクなどのＤ２Ｄ通信を行うことも可能である。以下では、ＵＥ２０及び移動体２２を特に区別する必要がない場合、ＵＥ２０と総称する。
ＵＥ１０は、ユーザ１２に携行され、ユーザ１２の歩行、走行又はユーザ１２が乗車した乗り物（バス、バイク、又は車両など）の移動に伴って移動する通信装置である。ＵＥ１０は、ｅＮＢ３０による制御に従ってｅＮＢ３０と通信する機能を有する。また、ＵＥ１０は、ＧＮＳＳ衛星４０から送信されるＧＮＳＳ信号を受信し、ＧＮＳＳ信号に含まれる航法メッセージからＵＥ１０の位置情報を測定する機能を有する。また、ＵＥ１０は、ＲＳＵ５０と通信する機能を有する。さらに、本実施形態では、ＵＥ１０は、他のＵＥ１０又はＵＥ２０と直接通信すること、すなわち、サイドリンクなどのＤ２Ｄ通信を行うことも可能である。ＵＥ１０とＵＥ２０との通信はＶ２Ｐ通信でもある。
なお、図７では移動体の一例として車両２２を示しているが、移動体は車両２２に限定されない。例えば、移動体は、船舶、航空機及び自転車などであってもよい。また、上記では、ＵＥ２０がＧＮＳＳ信号を受信する機能を有することを説明したが、車両２２がＧＮＳＳ信号を受信する機能を有し、車両２２がＧＮＳＳ信号の受信結果をＵＥ２０に出力してもよい。
図８には、車両などの移動体に搭載して用いられる通信装置の機能的構成例を模式的に示している。図８に示す通信装置は、例えば、図７に示した無線通信システムのうち車両２２に搭載されるＵＥ２０に対応するが、ユーザ１２に携行されるＵＥ１０も同様の構成であると理解されたい。また、図８に示す通信装置は、フィードバック型サイドリンク通信における送信端末及び受信端末のいずれとしても動作するものとする。
図８に示すように、ＵＥ２０は、アンテナ部２１０と、無線通信部２２０、ＧＮＳＳ信号処理部２３０と、記憶部２４０と、処理部２５０を備えている。
アンテナ部２１０は、無線通信部２２０により出力される信号を電波として空間に放射する。また、アンテナ部２１０は、空間の電波を信号に変換し、当該信号を無線通信部２２０へ出力する。
無線通信部２２０は、信号を送受信する。例えば、無線通信部２２０は、ｅＮＢ３０からのダウンリンク信号を受信し、ｅＮＢ３０へのアップリンク信号を送信する。また、無線通信部２２０は、ＵＥ１０、他のＵＥ２０又はＲＳＵ５０との間でサイドリンク信号を送受信する。
ＧＮＳＳ信号処理部２３０は、ＧＮＳＳ衛星４０から送信されたＧＮＳＳ信号についての処理を行う構成である。例えば、ＧＮＳＳ信号処理部２３０は、ＧＮＳＳ信号を処理することにより、ＵＥ２０の位置情報及び時間情報を測定する。
記憶部２４０は、ＵＥ２０の動作のためのプログラム及びさまざまなデータを、一時的に又は不揮発的に記憶する。
処理部２５０は、ＵＥ２０のさまざまな機能を提供する。例えば、処理部２５０は、無線通信部２２０により行われる通信を制御する。後述するフィードバック型サイドリンク通信における送信端末又は受信端末としてのＵＥ２０の通信動作は、基本的には処理部２５０の制御によって実現されるものとする。
また、図２０には、主に基地局として動作する通信装置の機能的構成例を模式的に示している。図２０に示す通信装置は、例えば図２〜図６に示したＶ２Ｖ通信環境におけるＥ−ＵＴＲＡＮ、若しくは図７に示した無線通信システムにおけるｅＮＢ３０に対応する。
図２０に示すように、ｅＮＢ３０は、アンテナ部３１０と、無線通信部３２０、ネットワーク通信部３３０と、記憶部３４０と、処理部３５０を備えている。
アンテナ部３１０は、無線通信部３２０により出力される信号を電波として空間に放射する。また、アンテナ部３１０は、空間の電波を信号に変換し、当該信号を無線通信部３２０へ出力する。
無線通信部３２０は、信号を送受信する。例えば、無線通信部３２０は、ＵＥ１０、ＵＥ２０、又はＲＳＵ５０からのアップリンク信号を受信し、ＵＥ１０、ＵＥ２０、又はＲＳＵ５０へのダウンリンク信号を送信する。
ネットワーク通信部３３０は、図示しないネットワークを経由して情報を送受信する。例えば、ネットワーク通信部３３０は、他のノードへの情報を送信し、他のノードからの情報を受信する。ここで言う他のノードは、他の基地局及びコアネットワークノードを含むものとする。
記憶部３４０は、ｅＮＢ３０の動作のためのプログラム及びさまざまなデータを、一時的に又は不揮発的に記憶する。
処理部３５０は、ｅＮＢ３０のさまざまな機能を提供する。例えば、処理部３５０は、配下のユーザ端末（ＵＥ１０、ＵＥ２０）、及びＲＳＵ５０により行われる通信を制御する。
また、処理部３５０は、ユーザ端末間で直接行うデータ送信すなわちサイドリンク用のリソースプールの割り当てを行う。さらに本実施形態では、処理部３５０は、データ送信に対するＡＣＫ若しくはＮＡＣＫといったフィードバック信号を返信するためのフィードバック用リソースの割り当ても行なう場合もある。但し、フィードバックもサイドリンク通信の一部であり、フィードバック用リソースは基本的にはサイドリンク用のリソースプール内で割り当てられるものとする。
Ｂ．サイドリンク通信におけるフィードバック方法
本実施形態に係る無線通信システムでは、車両同士が直接的に通信を行うサイドリンクは、周波数利用効率及び信頼性向上の観点から、従来用いられていたブロードキャスト通信に変えて、フィードバック型サイドリンク通信を行う。従来のＤ２Ｄ通信では、サイドリンク通信は物理層レベルでブロードキャスト信号が複数回送信され、受信側では取り敢えずすべての信号を受信して、上位レイヤにおいて受信信号が自分宛かどうかを判断する。したがって、再送の概念がそもそもない。これに対し、本実施形態に係る無線通信システムでは、サイドリンク通信において送信される何らかの信号に対して、受信側がフィードバック信号（例えば、ＡＣＫ／ＮＡＣＫ、伝搬環境情報など）を送信する場面を想定している。
フィードバック型サイドリンク通信としては、送信端末が１台の受信端末と通信を行うユニキャスト通信と、複数台の受信端末と通信を行うマルチキャスト通信という２種類のシナリオが想定される。また、後者のマルチキャスト通信は、ブロードキャスト通信とは異なり、データをデコードする受信端末を制限することができる。１台の受信端末まで制限すると、ユニキャスト通信となる。マルチキャスト通信は、グループキャスト通信とも呼ばれる。
図９には、フィードバック型サイドリンク通信におけるＨＡＲＱオペレーションの例を示している。但し、図９は、送信端末が複数台の受信端末と通信を行うマルチキャスト通信のシナリオである。また、送信端末並びに受信端末は、図８に示した通信装置により構成されるものとする。
図９左に示すように、送信端末９０１は、複数台の受信端末９１１〜９１４に対して、データをデコードすることを制限したサイドリンク通信を実施する。そして、図９右に示すように、データの受信若しくはデコードに失敗した受信端末９１２が、送信端末９０１に対してＮＡＣＫを返信してフィードバックを行う。なお、図示を省略するがデータの受信に成功した受信端末９１１〜９１４が送信端末９０１に対してＡＣＫを返信してフィードバックを行うようにしてもよい。
ＮＡＣＫを受信した送信端末９０１は、データ再送を行うことにより信頼性を担保することができる。また、サイドリンク通信にフィードバック若しくは再送制御を採り入れることにより、ブロードキャスト通信を用いるときと比較して繰り返し送信回数を削減することができ、周波数利用効率を向上することができる。
また、受信端末９１１〜９１４は、ＨＡＲＱオペレーションを利用して、さまざまな情報のフィードバックを実施することができる。そして、送信端末９０１は、受信端末からフィードバックに関する情報を受信して、フィードバック対応を実施することができる。
図１０には、サイドリンク通信時において、送信端末が受信端末からのフィードバックに対応するための処理手順をフローチャートの形式で示している。また、図１１には、サイドリンク通信時において、受信端末が送信端末に対して情報をフィードバックするための処理手順をフローチャートの形式で示している。送信端末及び受信端末の各処理手順はいずれも、送信端末若しくは受信端末として動作する通信装置の処理部２５０が主導して実施される。
図１０を参照しながら、送信端末におけるフィードバック対応処理手順について説明する。
送信端末は、いずれかの受信端末からフィードバックに関する情報を受信すると（ステップＳ１００１）、フィードバック情報に応じてフィードバック対応処理を実施する（ステップＳ１００２）。
ステップＳ１００１におけるフィードバックの実施に関する指示は、通信を行っている送信端末自身でもよい、ＲＳＵや基地局などのインフラストラクチャでもよい。後述するように、フィードバックに使用するリソースは、ＲＳＵや基地局などのインフラストラクチャで割り当てられる場合と、送信端末が割り当てる場合と、フィードバックを実施する受信端末自身で確保する場合とが考えられる。
また、ステップＳ１００２では、フィードバック対応処理として、例えば送信リソース、消費電力、ＭＣＳ（Ｍｏｄｕｌａｉｔｏｎ ａｎｄ Ｃｏｄｉｎｇ Ｓｈｅｍｅ）、再送回数、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｍｏｄｅなどの制御を実施する。
また、送信端末は、オプションとして、フィードバック情報を受信するための対応を行ってもよい（ステップＳ１００３）。例えば、フィードバック情報を受信端末側から通知してもらう場合に使用するリソースなどをあらかじめ確保してもよい。
その後、送信端末は、ステップＳ１００２並びにステップＳ１００３で決定したパラメータを用いて、通信先の受信端末への信号送信を行う（ステップＳ１００４）。
続いて、図１１を参照しながら、受信端末におけるフィードバックを実施するための処理手順について説明する。
受信端末は、まずフィードバックを実施する上での設定を行う（ステップＳ１１０１）。この設定は、送信元の送信端末からでもよく、ＲＳＵや基地局などのインフラストラクチャから設定されてもよい。後述するように、フィードバックに使用するリソースは、ＲＳＵや基地局などのインフラストラクチャで割り当てられる場合と、送信端末が割り当てる場合と、フィードバックを実施する受信端末自身で確保する場合とが考えられる。
フィードバックを実施する上での設定を行った後、受信端末は、フィードバックを行うための測定を実施する（ステップＳ１１０２）。例えば、受信端末は、信号のデコーディングや、チャネル情報の測定、パスロスの計測のためのＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｐｏｗｅｒ）やＲＳＲＱ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｑｕａｌｉｔｙ）の計算などを実施する。
そして最後に、受信端末は、ステップＳ１１０２で測定したフィードバック結果を、送信端末、若しくはＲＳＵや基地局などのインフラストラクチャに送信して、フィードバックを実施する（ステップＳ１１０３）。
これまでのＶ２Ｘ通信においては、サイドリンクはブロードキャスト通信が採用され、且つ、フィードバックを用いた通信が導入されていない。したがって、図９〜図１１で示した、ＨＡＲＱのようなフィードバック通信をサイドリンクで行う際には、ＡＣＫやＮＡＣＫといったフィードバック信号を受信端末から送信端末へどのようにフィードバックするか、という課題がある。
サイドリンク通信は、通常、基地局からあらかじめ割り当てられたリソースプールを使って行われる。したがって、車両などの移動体に搭載されたＵＥ２０は、いずれのＵＥも自由に使えるリソースプールを使って、サイドリンク通信を行うことができる（例えば、特許文献２を参照のこと）。このような環境下においては、フィードバック型サイドリンク通信を行う送信端末と受信端末間で、ＡＣＫやＮＡＣＫなどフィードバック用のリソースをどのように規定し、どのタイミングでフィードバックを行うなどの情報をどのように共有するか、という２点が主な課題になる。
Ｂ−１．フィードバック用リソースの確保
ここでは、フィードバック型サイドリンク通信を実現する１つ目の課題である、フィードバック用リソースを確保する方法について説明する。
３ＧＰＰの規格書ＴＳ ３６．２１３では、基地局によるサイドリンクのリソース割り当て方式としてモード１及びモード３が記載され（モード３ではリソースが準静的に割り当てられるが、モード１によるリソース割り当ては準静的でない）、また、端末によるサイドリンクのリソース割り当て方式としてモード２及びモード４が規格化されている（モード４ではセンシングを伴うが、モード２ではセンシングを伴わない）。そこで、フィードバック型サイドリンク通信において、基地局がフィードバック用リソースを割り当てるケースと、端末がフィードバック用リソースを割り当てるケースについて、それぞれ考えてみる。但し、後者の端末がフィードバック用リソースを割り当てるケースは、送信端末がリソース割り当てを行うケースと受信端末がリソース割り当てを行うケースにさらに分けられる。さらにＰｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎによりフィードバック用リソースを割り当てるケースも想定される。
Ｂ−１−１．基地局がフィードバック用リソースの割り当てを行うケース
このケースでは、サイドリンクにおけるフィードバック用のリソースは、基地局によって割り当てられる。
送信端末がデータリソースを割り当てる場合、送信端末は、ＡＣＫ並びにＮＡＣＫ用のリソースを別途、基地局に割り当ててもらう必要がある。
図１２には、基地局がサイドリンクにおけるフィードバック用リソースの割り当てを行う通信シーケンス例を示している。なお、同図中の送信端末及び受信端末はそれぞれ異なる車両に搭載された通信装置（図８を参照のこと）であり、基地局はｅＮＢ又はＲＳＵに相当する。
送信端末は、トラフィックが発生すると（ＳＥＱ１２０１）、接続先の基地局に対して、スケジューリングリクエストによるサイドリンクのためのリソースを要求する（ＳＥＱ１２０２）。ここでは、送信端末は、データ送信のためのリソースに加えて、フィードバック（すなわち、ＡＣＫ／ＮＡＣＫ）のためのリソースを要求する。
基地局は、送信端末からのサイドリンクのためのリソース要求に応答して、データ送信のためのリソース、及び、ＡＣＫ／ＮＡＣＫのためのリソース割り当てを行う（ＳＥＱ１２０３）。そして、基地局は、送信端末と受信端末の各々に対し、ＤＣＩ（Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）経由で、割り当てたリソースを通知する（ＳＥＱ１２０４）。
その後、送信端末は、サイドリンクによるデータ送信に割り当てられたリソースを使って、受信端末へのデータ送信を行う（ＳＥＱ１２０５）。これに対し、受信端末は、送信端末からの送信データを受信し復号処理する（ＳＥＱ１２０６）。そして、受信端末は、データの受信結果若しくは受信データの復号結果に関するＡＣＫ若しくはＮＡＣＫを、フィードバック用に割り当てられたリソースを使って、送信端末に返信する（ＳＥＱ１２０７）。
例えば、送信端末は、データ送信前に基地局にフィードバック用リソースを割り当ててもらう。この場合、送信端末は、データ送信前に、通信対象のデバイス、及び、通信対象のデバイスへのサイドリンクの送信タイミングを、接続先の基地局に通知する。例えば、図９に示す例では、送信端末９０１にとって受信端末９１１〜９１４が通信対象のデバイスとなる。
これに対し、基地局は、送信端末からの要求に応答して、フィードバック用リソースの割り当てを実施する。そして、基地局は、ダウンリンクのＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ ＣＨａｎｎｅｌ）を用いて、フィードバック用のＳＬ Ｇｒａｎｔ（サイドリンクにおけるリソース割り当て結果）を通信対象のデバイスに通知する。また、基地局は、要求元の送信端末に対するリソース割り当て結果の通知も同時に行う。データ送信前に基地局がリソース割り当てを行う方法は、ダイナミックなリソース割り当て方法ということもできる。
また、基地局がフィードバック用リソースを割り当てる他の方法として、事前にすべての端末に対してフィードバック用リソースを周期的に割り当てておく方法も考えられる。この方法によれば、受信端末は、事前に割り当てられたリソースの一部を使って、送信端末に対してＡＣＫ若しくはＮＡＣＫを返信することができる。
基地局は、サイドリンクに割り当てたリソースプールの一部に、フィードバック用のリソースプールを設け、このフィードバック用のリソースプール内で配下の各端末向けのフィードバック用リソースを事前に割り当てる。このリソースの割り当て方法は、データ送信の度にフィードバック用リソースが変わることがないことから、準静的なリソース割り当て方法ということができる。
図１３には、サイドリンク用のリソースプール１３００内に、フィードバック用のリソースプール１３０１を設けた様子を示している。但し、横軸を時間軸とし、縦軸を周波数軸とする。図示のように、フィードバック用のリソースプール１３０１の中に、通信対象の端末Ａ及び端末Ｂの各々向けのフィードバック用リソースが事前に割り当てられている。
端末Ａと端末Ｂに対して直交したフィードバック用リソースを事前に割り当てることで、各々から送信されるＡＣＫ／ＮＡＣＫパケットの衝突を防ぐことが可能となる。そして、リソースプール１３００を使ってデータ送信１３０２が実施されると、通信対象の各デバイスはそれぞれ自端末向けに準静的に割り当てられたフィードバック用リソースプールを使って、ＡＣＫ若しくはＮＡＣＫを返信することができる。
サイドリンク用のリソースプール１３００の設定や、リソースプール１３００内でのフィードバック用リソース１３０１の準静的な割り当ては、基地局（ｅＮＢ）からのシステム情報（ＳＩＢ：Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）や、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）シグナリングを用いてＣｏｎｆｉｇｕｒｅされる。
ＬＴＥで標準化されているＳＰＳ（Ｓｅｍｉ−Ｐｅｒｓｉｓｔｅｎｔ Ｓｃｈｅｄｕｌｉｎｇ）は、データ用の準静的なリソース割り当てである。この場合、ＳＰＳ Ｃｏｎｆｉｇｕｒａｔｉｏｎを行い、実際にデータ通信を行う際には逐次的にＡｃｔｉｖａｔｉｏｎの指示が必要となる。これに対し、上記のように基地局が各端末にフィードバック用リソースを準静的に割り当てる場合には、Ａｃｔｉｖａｔｉｏｎの指示は必要ではなく、各端末はいつでも準静的に割り当てられたフィードバック用リソースを使用して、ＡＣＫ若しくはＮＡＣＫを返信することが可能となる。
再び図１３を参照すると、通信対象の端末Ａ及び端末Ｂはそれぞれ、データ１３０２を受信した後、フィードバック用リソース１３０１内の最も早く使用可能なリソースを選択して、ＡＣＫ若しくはＮＡＣＫを返信する。但し、受信端末は、これ以外の方法でフィードバック用リソースの選択を行ってもよい。データ送信完了とＡＣＫ／ＮＡＣＫ返信に用いるリソース選択との関連については、後に詳細に説明する。
各端末に直交したフィードバック用リソースを事前に割り当てることで、ＡＣＫ／ＮＡＣＫパケットの衝突を防ぐことが可能となる。また、符号多重やプリアンブル送信などを用いて、複数の受信端末を同じフィードバック用リソースに多重化するようにしてもよい。ここで言うプリアンブル送信においては、ＺＣ（Ｚａｄｏｆｆ−Ｃｈｕ）系列のようなＣＡＺＡＣ（Ｃｏｎｓｔａｎｔ Ａｍｐｌｉｔｕｄｅ ａｎｄ Ｚｅｒｏ Ａｕｔｏ−ｃｏｒｒｅｌａｔｉｏｎＣｏｄｅ）系列を用いてもよい。受信端末毎に異なる系列を事前に割り当てることで、同じリソースを使ってＡＣＫ／ＮＡＣＫが多重送信された場合であっても、送信端末側ではユーザ分離が可能となる。系列割り当ては、事前に基地局から各端末に対して設定されていてもよいし、Ｐｒｅ−ｃｏｎｆｉｇｕｒａｔｉｏｎされてもよい。また、送信端末から端末グルーピングを行う際に系列割り当てを行うようにしてもよい。
Ｂ−１−２．送信端末がフィードバック用リソースの割り当てを行うケース
送信端末がフィードバック用リソースの割り当てを行う場合、割り当てるリソースが他の端末によって使用されていないことを保証する必要がある。このため、送信端末が自分のデータ送信のためのセンシングを実施する際に、受信端末のフィードバック用リソースのセンシングまで併せて行い、そのリソースを予約しておく必要がある。また、送信端末は、予約したフィードバック用リソースを受信端末に通知しておく必要がある。送信端末は、例えば、ＳＣＩ（Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）を用いて、フィードバック用リソースの位置を受信端末に通知するようにしてもよい。ＳＣＩは、ＰＳＣＣＨ（Ｐｈｙｓｉｃａｌ Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ ＣＨａｎｎｅｌ）を用いて伝送されるメッセージである。
図１４には、送信端末がサイドリンクにおけるフィードバック用リソースの割り当てを行う通信シーケンス例を示している。なお、同図中の送信端末及び受信端末はそれぞれ異なる車両に搭載された通信装置（図８を参照のこと）である。
送信端末は、トラフィックが発生すると（ＳＥＱ１４０１）、センシングを用いてサイドリンクによるデータ送信を行うためのリソースを、リソースプール（前述）の中から選択する（ＳＥＱ１４０２）。このとき、送信端末は、サイドリンク用のリソースプール内に設けられたフィードバック用リソースプールの中で、受信端末用のリソースを併せて選択する。このようにして、送信端末は、自分のデータ送信用のリソース、並びに受信端末のフィードバック用リソースをそれぞれ確保する（ＳＥＱ１４０３）。
その後、送信端末は、ＳＣＩを用いて、データ送信用リソース及びフィードバック用リソースの位置を受信端末に通知し、続いて、ＳＣＩで通知したリソースを使って受信端末へのデータ送信を行う（ＳＥＱ１４０４）。
これに対し、受信端末は、ＳＣＩで通知されたデータ送信用のリソース位置にて送信端末からの送信データを受信し、復号処理する（ＳＥＱ１４０５）。そして、受信端末は、データの受信結果若しくは受信データの復号結果に関するＡＣＫ若しくはＮＡＣＫを、送信端末からＳＣＩで通知されたリソースを使って、送信端末に返信する（ＳＥＱ１４０６）。
また、送信端末は、Ｒｅｓｅｒｖａｔｉｏｎ ｉｎｄｉｃａｔｏｒを用いて、リソース予約を行ってもよい。データ送信完了とＡＣＫ／ＮＡＣＫ返信に用いるリソース選択との関連については、後に詳細に説明する。
ＳＥＱ１４０４において、送信端末がＳＣＩを用いてデータ送信用リソース及びフィードバック用リソースの位置を受信端末に通知する方法について、詳細に説明する。送信端末は、ＳＣＩ内に、データリソースの時間周波数領域と、フィードバック用リソースの時間周波数領域を指示する情報を含める。さらに、Ｒｅｓｅｒｖａｔｉｏｎ ｉｎｄｉｃａｔｏｒを用いてリソース予約を行う場合には、送信端末は、ＳＣＩ内にフィードバック用リソースのリソース予約を通知するＲｅｓｏｕｒｃｅ ｒｅｓｅｒｖａｔｉｏｎ ｉｎｄｉｃａｔｏｒを含める。
受信端末側では、ＳＣＩ内にＲｅｓｅｒｖａｔｉｏｎ ｉｎｄｉｃａｔｏｒが含まれていた場合には、フィードバック用のリソースは将来予約されているものと認識する。また、ＳＣＩで指示されたフィードバック用リソースと予約されたフィードバック用リソースの位置関係は、ＳＣＩ内で時間オフセット値として通知してもよい。このとき周波数方向のオフセット値も含めてよい。また、受信端末は、データの送信周期に基づいて時間オフセット値を推定してもよい。例えば、送信端末からデータが１００ミリ秒周期で到来していた場合、予約されたフィードバック用リソースも１００ミリ秒先のリソースで予約されていると推定することができる。
図１５には、フィードバック用リソースの割り当て例を示している。但し、同図において、横軸を時間軸とし、縦軸を周波数軸とする。送信端末は、サイドリンクにおいて、ＳＣＩを送信した後に、受信端末にデータを送信する。ＳＣＩ内には、参照番号１５０１で示す、データリソースの時間周波数領域を指示する情報と、参照番号１５０２で示す、フィードバック用リソースの時間周波数領域を指示する情報が含まれている。さらに、ＳＣＩ内には、Ｒｅｓｏｕｒｃｅ ｒｅｓｅｒｖａｔｉｏｎ ｉｎｄｉｃａｔｏｒが含まれている。このＩｎｄｉｃａｔｏｒは、参照番号１５０３で示すように、将来予約されているフィードバック用リソースを指示する。また、参照番号１５０４で示す、ＳＣＩで指示されたフィードバック用リソースと予約されたフィードバック用リソースの時間オフセット値は、ＳＣＩ内で通知してもよいし、受信端末が送信端末からのデータ送信周期に基づいて推定してもよい。
また、ＳＥＱ１４０２において、送信端末がリソースをセンシングする方法について、補足する。送信端末は、データ通信用のリソースのセンシング方法とは異なる方法を用いて、フィードバック用リソースのセンシングを行ってもよい。データ通信用のセンシングにおいては、送信データの優先度及び周辺で送信されているパケットの優先度比較を行いながらリソースの確保を行う。一方で、フィードバック用リソースのセンシングにおいては、ＡＣＫ若しくはＮＡＣＫの優先度を新たに規定して、リソースの確保を行ってもよい。リソース確保のための条件はデータとＡＣＫ／ＮＡＣＫでは異なるため、別々のセンシング設定でリソースセンシングを実施する。
Ｂ−１−３．受信端末がフィードバック用リソースの割り当てを行うケース
受信端末は、送信端末からのデータ信号を受信した後に、ＡＣＫ若しくはＮＡＣＫを返信するためのフィードバック用リソースをセンシングする。そして、受信端末は、センシングによりリソースを発見できたときには、そのリソースを用いて送信端末にＡＣＫ若しくはＮＡＣＫを返信する。
但し、受信端末は、パケットの最大遅延時間を超えない範囲でＡＣＫ／ＮＡＣＫを返信しなければならない。パケット毎の最大遅延時間は、例えば、送信端末がデータ送信前に送信するＳＣＩを通じて受信端末に通知される。この場合、受信端末は、ＳＣＩで通知された最大遅延時間以内に、ＡＣＫ／ＮＡＣＫ用のリソースを確保して、送信しなければならない。
また、受信端末は、自ら割り当てたフィードバック用リソースの位置を、例えばＳＣＩを用いて送信端末に通知するようにしてもよい。但し、受信端末自身のデータ送信がない場合に、ＳＣＩを無駄に送信する方法は好ましくない。このため、受信端末は、データ信号としてＰｉｇｇｙ ｂａｃｋして（すなわち、フィードバックパケットをデータパケットに乗せて）送信するようにしてもよい。この場合、データの最後にＡＣＫ若しくはＮＡＣＫを挿入するなどＩｍｐｌｉｃｉｔな送信方法を用いることができる。
図１６には、受信端末がフィードバック信号を送信するための処理手順をフローチャートの形式で示している。図示の処理手順は、受信端末として動作する通信装置の処理部２５０が主導して実施される。この処理手順は、受信端末がＡＣＫ／ＮＡＣＫをデータパケットのＰｉｇｇｙ ｂａｃｋして送信する点に主な特徴がある。
受信端末は、送信端末からデータパケットを受信すると（ステップＳ１６０１）、そのデータ送信の際に送信端末から受信したＳＣＩから、フィードバック信号を送信する最大遅延時間を取得する（ステップＳ１６０２）。
次いで、受信端末は、フィードバック信号の最大遅延時間内に送信するデータパケットがあるかどうかをチェックする（ステップＳ１６０３）。ここで、フィードバック信号の最大遅延時間内に送信するデータパケットがある場合には（ステップＳ１６０３のＹｅｓ）、受信端末は、そのデータパケットの宛先にステップＳ１６０１で受信したパケットの送信元の端末が含まれているか、若しくはそのデータパケットをブロードキャスト通信するかどうかを、さらにチェックする（ステップＳ１６０４）。
そして、受信端末は、自身のデータパケットの宛先にステップＳ１６０１で受信したパケットの送信元の端末が含まれているか、又は、ブロードキャスト通信を行うときには（ステップＳ１６０４のＹｅｓ）、ステップＳ１６０１で受信したパケットに関するＡＣＫ若しくはＮＡＣＫを自身のデータパケットにＰｉｇｇｙ ｂａｃｋして送信する（ステップＳ１６０５）。
一方、フィードバック信号の最大遅延時間内に送信するデータパケットがない場合（ステップＳ１６０３のＮｏ）、又は、自身のデータパケットの宛先にステップＳ１６０１で受信したパケットの送信元の端末が含まれず、且つ、ブロードキャスト通信でもない場合には（ステップＳ１６０４のＮｏ）、受信端末は、フィードバック用のリソースセンシングを実施する（ステップＳ１６０６）。
ここで、受信端末は、フィードバック用のリソースを確保することができた場合には（ステップＳ１６０７のＹｅｓ）、確保したリソースを使って、ステップＳ１６０１で受信したパケットの送信元の端末にＡＣＫ若しくはＮＡＣＫを返信する（ステップＳ１６０８）。その際、受信端末は、送信端末に対して、ＳＣＩにＡＣＫ若しくはＮＡＣＫの位置の情報を載せて通知するようにしてもよい。
一方、フィードバック用のリソースを確保することができなかった場合には（ステップＳ１６０７のＮｏ）、受信端末は、ＡＣＫ若しくはＮＡＣＫの返信を行わない（ステップＳ１６０９）。
図１６に示した処理手順によれば、受信端末は、可能な限りフィードバック信号をＰｉｇｇｙ ｂａｃｋして送信して、ＳＣＩを無駄に送信しないように動作することができる。
受信端末がフィードバック用リソースの割り当てを行うケースにおいて、送信端末が、受信端末に対して、フィードバック用に使用すべきリソースの領域を設定（若しくは制限）するようにしてもよい。このような場合、受信端末は、送信端末が設定した領域内で、フィードバック用のリソースをセンシングして、送信を行う。送信端末は、周波数方向及び時間方向のいずれか又は両方でフィードバック用のリソースの領域を制限してもよい。
また、フィードバック用のリソースを発見し易くするために、フィードバック用の専用リソースプールを端末に設定してもよい。この設定は、通常のリソースプール割り当てと同様に、基地局からのシステム情報（ＳＩＢ）や、ＲＲＣシグナリングを通して行うことができる。また、フィードバック用の専用リソースプールがＰｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎされてもよい。
受信端末は、上記のように指定されたリソースの領域内でフィードバック用のリソースを確保できない場合（若しくは、最大遅延時間内で指定された領域からリソースを確保できない場合）、サイドリンクによるフィードバック信号の送信を諦めて、基地局のアップリンクを用いたフィードバック信号の送信に切り替えてもよい。この場合、受信端末からのＡＣＫ／ＮＡＣＫは、基地局経由で送信端末に送信されることになる。
図１７には、受信端末がフィードバック信号を送信するための他の処理手順をフローチャートの形式で示している。図示の処理手順は、受信端末として動作する通信装置の処理部２５０が主導して実施される。この処理手順は、受信端末が最大遅延時間以内にサイドリンクでＡＣＫ／ＮＡＣＫを返信できない場合にはアップリンクを用いたフィードバック送信に切り替える点に主な特徴がある。
受信端末は、送信端末からデータパケットを受信すると（ステップＳ１７０１）、そのデータ送信の際に送信端末から受信したＳＣＩから、フィードバック信号を送信する最大遅延時間を取得する（ステップＳ１７０２）。
次いで、受信端末は、フィードバック用のリソースセンシングを実施する（ステップＳ１７０３）。そして、受信端末は、ステップＳ１７０２で取得した最大遅延時間以内でフィードバック用リソースを確保することができた場合には（ステップＳ１７０４のＹｅｓ）、確保したリソースを使って、ステップＳ１７０１で受信したパケットの送信元の端末にＡＣＫ若しくはＮＡＣＫを返信する（ステップＳ１７０５）。
一方、受信端末は、ステップＳ１７０２で取得した最大遅延時間以内でフィードバック用リソースを確保することができなかった場合には（ステップＳ１７０４のＮｏ）、アップリンク通信向け（すなわち、接続先の基地局向け）のリソースセンシングを実施する（ステップＳ１７０６）。
ここで、受信端末は、アップリンク通信向けのリソースを確保することができた場合には（ステップＳ１７０７のＹｅｓ）、基地局経由での、ステップＳ１７０１で受信したパケットの送信元の端末へのＡＣＫ若しくはＮＡＣＫ送信を実施する（ステップＳ１７０８）。
また、受信端末は、アップリンク通信向けのリソースを確保することができなかった場合には（ステップＳ１７０７のＮｏ）、ＡＣＫ若しくはＮＡＣＫの返信を行わない（ステップＳ１７０９）。
Ｂ−１−４．Ｐｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎによりフィードバック用リソースの割り当てを行うケース
Ｐｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎにより、すべての端末に対してデータ送信からＡＣＫ／ＮＡＣＫ送信までの関連を事前に設定しておくこともできる。この場合、データパケットを受信したすべての端末は、Ｐｒｅ−ｃｏｆｉｇｕｒｅされた設定に則って、ＡＣＫ若しくはＮＡＣＫを返信する。端末は、リソースセンシング実施時に、データ信号検出からＡＣＫ／ＮＡＣＫ送信で使用しているリソースを把握することができる。このため、端末は、データのみならずＡＣＫ／ＮＡＣＫ送信用のリソースを考慮してセンシングを行うことができる。なお、ここで言うＰｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎとは、例えば端末の出荷時に設定することに相当する（但し、基地局が書き換えを行うことも想定される）。
Ｂ−２．フィードバックタイミング
ここでは、フィードバック型サイドリンク通信を実現する２つ目の課題である、フィードバックタイミングを通知する方法について説明する。但し、フィードバックタイミングとは、端末がデータ受信を行ってからＡＣＫ若しくはＮＡＣＫを送信するタイミングまでの時間のことを示すものとする。フィードバックタイミングを通知する方法は、Ｉｍｐｌｉｃｉｔに通知する方法と、Ｅｘｐｌｉｃｉｔに通知する方法に大別される。以下では、各々の通知方法についてそれぞれ説明する。
Ｂ−２−１．Ｉｍｐｌｉｃｉｔに通知する方法
データ送信直後を基準としてフィードバック用リソースを割り当てるケースが考えられる。複数台の受信端末と通信を行うマルチキャスト通信の場合、各受信端末にフィードバック用リソースの割り当てを決定しなければならない。図１８には、複数の受信端末ｘ、ｙ、ｚの各々に対し、データ送信直後を基準としてフィードバック用リソースを割り当てた例を示している。
例えば、ｅＮＢ（基地局）が制御のために一時的に与える識別情報ＲＮＴＩ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ）を利用して、各端末のフィードバックタイミングを決定する方法を、Ｉｍｐｌｉｃｉｔに通知する方法として挙げることができる。受信端末は、マルチキャストグループを確立する際に入手した他端末のＲＮＴＩを用いて、自分が何番目のリソースを用いるかを決定してもよい。例えば、受信端末ｚ、ｘ、ｙにそれぞれ１、５、８といった番号が割り当てられていた場合には、端末ｙは、自身が３番目に大きな番号であるので、データ送信直後から３番目のリソースをＡＣＫ／ＮＡＣＫ用のリソースとして選択する。同様に、端末ｚは自身が最も小さな番号なのでデータ送信直後から１番目のリソースを選択し、端末ｘは自身が２番目に大きな番号なので２番目のリソースを選択する。
Ｂ−２−２．Ｅｘｐｌｉｃｉｔに通知する方法
フィードバックタイミングをＥｘｐｌｉｃｉｔに通知する方法として、以下の（１）〜（４）を挙げることができる。各通知方法についてそれぞれ説明する。
（１）ＳＣＩにオフセット情報を入れて受信端末に通知する。
送信端末が、受信端末に対して、データからＡＣＫ／ＮＡＣＫリソースまでの時間オフセット情報をＳＣＩに入れて通知する。逆に、受信端末が、送信端末に対して、ＡＣＫ／ＮＡＣＫを送信したいリソースの位置情報をＳＣＩに入れて送信するケースも考えられる。
（２）ＳＣＩにフィードバック用リソース位置情報を入れて受信端末に通知する。
送信端末は、ＳＣＩに時間方向及び周波数方向の座標情報を入れることで、受信端末に対してＡＣＫ／ＮＡＣＫのリソース位置を指定する。また、データ信号の場所を基準としたオフセット情報として、ＳＣＩを用いてＡＣＫ／ＮＡＣＫのリソース位置を通知するようにしてもよい。
（３）ＭＡＣ ＣＥを用いて通知する。
基地局（ｅＮＢ）がＵＥ端末に送信するＭＡＣ ＣＥ（ＭＡＣ Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ）に、時間方向及び周波数方向の座標情報を入れることで、ＡＣＫ／ＮＡＣＫのリソース位置を指定する。また、データ信号の場所を基準としたオフセット情報として、ＭＡＣ ＣＥを用いてＡＣＫ／ＮＡＣＫのリソース位置を通知するようにしてもよい。
（４）基地局（ｅＮＢ）からのＲＲＣシグナリングを用いてフィードバック用リソースを通知する。
基地局は、準静的なフィードバック用リソースを各端末に割り当てる。このとき、基地局は、ＲＲＣシグナリングを用いて、準静的に割り当てたフィードバック用リソースを各端末に通知する。あるいは、基地局は、システム情報（ＳＩＢ）を用いて各端末に割り当てたフィードバック用リソースを通知するようにしてもよい。また、基地局は。各端末にフィードバック用リソースを動的に割り当てて、ＤＣＩ経由で通知するようにしてもよい。
Ｃ．フィードバック型サイドリンク通信における再送方法
ここでは、受信端末からＮＡＣＫがフィードバックされた際の、送信端末による再送方法について説明する。
Ｃ−１．マルチキャスト通信時の再送方法
送信端末は、データパケットの宛先である受信端末からＮＡＣＫが返信されたときに、データ再送を行う。送信端末が複数台の受信端末に対して同時にデータパケットを送信するマルチキャスト通信を実施し、一部の受信端末からＮＡＣＫが返信されてきた場合の再送方法として、送信端末が再度マルチキャスト通信を実施する方法と、ＮＡＣＫを返信してきた受信端末に対してのみユニキャスト通信を実施する方法が考えられる。
Ｃ−２．受信端末における初送信号と再送信号の判断方法
ＮＤＩ（Ｎｅｗ Ｄａｔａ Ｉｎｄｉｃａｔｏｒ）は、当該信号が初期送信又は再送のいずれであるかを示す識別情報である。受信端末は、マルチキャスト用のＮＤＩを用いて、信号が初送又は再送のいずれであるかを判断することができる。
Ｃ−３．再送トリガ
送信端末は、１つ以上のパラメータを含んだ再送トリガ条件を設定して、再送判断を実施する。例えば、所定数以上のパラメータが条件を満たすときに、送信端末は再送を開始する。再送トリガ条件となるパラメータや再送判断のための閾値情報は、例えば基地局が設定してもよいし、Ｐｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎされてもよい。
再送トリガ条件となるパラメータを以下に示す。但し、以下のパラメータは例示列挙に過ぎず、再送トリガ条件はこれらに限定されるものではない。また、複数のパラメータを組み合わせて再送トリガ条件としてもよい。
・所定の時間に受信したＮＡＣＫ数、マルチキャスト通信した宛先の端末数に対するＮＡＣＫを返信した受信端末の割合。
・送信パケットの優先度情報。
・ＣＢＲ（Ｃｈａｎｎｅｌ Ｂｕｓｙ Ｒａｔｉｏ）、ＣＲ（Ｃｈａｎｎｅｌ Ｏｃｃｕｐａｎｃｙ Ｒａｔｉｏｎ）などで示される、チャネル混雑度やチャネル占有度などサイドリンクのチャネル状況。
・再送上限数に達していないか。
再送上限数は、基地局が設定してもよいし、Ｐｒｅ−ｃｏｆｉｇｕｒａｔｉｏｎされてもよい。
・端末のＨＡＲＱプロセス状況
例えば、送信端末は、受信端末のＨＡＲＱプロセス状況の情報を共有する。ここで言うＨＡＲＱプロセス状況には、対応可能プロセス数や残プロセス数などの情報が含まれる。そして、送信端末は、受信端末のＨＡＲＱプロセス状況に応じて、再送すべきかどうかを判断する。また、送信端末は、その判断結果を基地局（ｅＮＢ）に通知してもよい。送信端末は、残プロセス数が小さい受信端末に対しては、より確実に送信できるように送信パラメータを変更して再送するなどの対応を行うことができる。
また、送信端末は、自端末のＨＡＲＱプロセス状況に応じて、再送すべきかどうかを判断するようにしてもよい。例えば、残プロセス数が大きいなどビジーな状況下では、送信端末は再送を抑制するようにしてもよい。
図１９には、送信端末が再送制御するための処理手順をフローチャートの形式で示している。図示の処理手順は、送信端末として動作する通信装置の処理部２５０が主導して実施される。
送信端末は、受信端末に対してデータパケットを送信し（ステップＳ１９０１）、受信端末からのＡＣＮ若しくはＮＡＣＫを受信する（ステップＳ１９０２）。
そして、送信端末は、再送トリガ条件を満たしているかどうかをチェックして、再送トリガ条件を満たしているときには再送を実施するが（ステップＳ１９０７）、再送トリガ条件を満たしていないときには、再送せずに（ステップＳ１９０４）、本処理を終了する。
図１９に示す処理手順では、送信端末は、再送トリガ条件として、まず再送上限に達しているかどうかをチェックする（ステップＳ１９０３）。そして、再送上限に既に達しているときには（ステップＳ１９０３のＹｅｓ）、送信端末は、再送せずに（ステップＳ１９０４）、本処理を終了する。
一方、再送上限にまだ達していないときには（ステップＳ１９０３のＮｏ）、送信端末は、さらに他の再送トリガ条件についてチェックする。
具体的には、送信端末は、所定の時間に受信したＮＡＣＫ数が閾値以下であるかどうかをチェックする（ステップＳ１９０５）。そして、所定の時間に受信したＮＡＣＫ数が閾値以下であるときには（ステップＳ１９０５のＹｅｓ）、送信端末は、再送せずに（ステップＳ１９０４）、本処理を終了する。
また、送信端末は、ステップＳ１９０１で送信したパケットの優先度が閾値以下であるかどうかをチェックする（ステップＳ１９０６）。そして、送信パケットの優先度が閾値以下であるときには（ステップＳ１９０６のＹｅｓ）、送信端末は、再送せずに（ステップＳ１９０４）、本処理を終了する。
また、送信端末は、再送上限にまだ達しておらず（ステップＳ１９０３のＮｏ）、所定の時間に受信したＮＡＣＫ数が閾値を超え（ステップＳ１９０５のＮｏ）、且つ、送信パケットの優先度が閾値を超えるときには（ステップＳ１９０６のＮｏ）、再送を実施する（ステップＳ１９０７）。
Ｃ−４．再送時のＲＮＴＩ割り当て方法
マルチキャスト送信時には、グループＲＮＴＩのようなＲＮＴＩを宛先情報に用いて送信が行われる。グループＲＮＴＩは、グループリンクを確立する段階で、基地局から通知される。グループリンクは、Ｄｉｓｃｏｖｅｒｙプロセスを経て割り当てられてもよいし、基地局から割り当てられてもよい。
マルチキャスト送信時のグループＲＮＴＩが他のグループのＲＮＴＩと重複しないように、例えば以下の情報（１）又は（２）を用いてグループＲＮＴＩを作成するようにする。
（１）送信端末のＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ）情報
（２）送信端末の情報の一部を使用して生成したＲＮＴＩ（例えば、送信端末自身に割り当てられたＲＮＴＩを用いて、グループＲＮＴＩを生成する）
Ｄ．フィードバック受信時のオペレーション
ここでは、送信端末が、受信端末からのフィードバック信号を受信したときに行うオペレーションについて説明する。
サイドリンク通信時における、送信端末が受信端末からのフィードバックに対応するための処理手順については、図１０を参照しながら既に述べた。送信端末は、受信端末からＮＡＣＫを受信すると、送信パラメータを調整して再送を実施する（但し、前述したように、再送トリガ条件を満たさないときには再送が実施されない場合もある）。再送時に調整する送信パラメータを以下に例示しておく。
・繰り返し送信回数（１回の送信に対して同じパケットを繰り返し送信する回数）
・送信電力
・ＲＶ（Ｒｅｄｕｎｄａｎｃｙ Ｖｅｒｓｉｏｎ）情報
・ＭＣＳ
・周波数ホッピングの適用
・優先度（再送毎に優先度を上げてもよい）
・周波数帯域の変更
・ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）の適用、ビームフォーミングの適用
・ＣｏＭＰ（Ｃｏｏｒｄｉｎａｔｅｄ Ｍｕｌｔｉ−ｐｏｉｎｔ：高データレートのカバレッジ拡大や、セル端におけるスループット改善を目的とした多地点協調）の適用
・ＣＡ（Ｃａｒｒｉｅｒ Ａｇｇｒｅｇａｔｉｏｎ）の適用
・使用リソースの変更（リソースリザベーションの段階で他のキャリアをリザーブしておく方法もある）
・ＭＡ（Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ） ｓｉｇｎａｔｕｒｅ
・リソース割り当てモードの変更（基地局割り当てモード⇔端末割り当てモード）
送信端末は、上記のような送信パラメータを、例えばＳＣＩを用いて受信端末に通知する。
なお、送信パラメータの中には、初送時には必要であるが再送時には意味がなくなるものや、逆に、初送時には不要であるが再送時に必要となるものがある。そこで、ＳＣＩ中の一部のフィールドを、初送時と再送時とで読み替えを行って、メッセージのサイズを削減するようにしてもよい。例えば、繰り返し送信回数は初送時のみ必要であるが、再送データブロックの特徴を表すＲＶ情報は再送時から必要となる。したがって、初送時のＳＣＩにおいて繰り返し送信回数を記載していたフィールドを、再送時にはＲＶ情報を記載するフィールドに読み替えることができる。
Ｅ．まとめ
本明細書では、受信側からのＨＡＲＱやチャネル情報などのフィードバックをベースに通信を行うフィードバック型サイドリンク通信に関して説明してきた。従来のＤ２Ｄ通信では、サイドリンク通信は物理層レベルでブロードキャスト信号が複数回送信され、受信側では取り敢えずすべての信号を受信して、上位レイヤにおいて受信信号が自分宛かどうかを判断する。すなわち、再送の概念がそもそもない。これに対し、本明細書で開示する技術によれば、上記のようにサイドリンク通信にフィードバック若しくは再送制御を採り入れることができる。したがって、サイドリンク通信において送信される何らかの信号に対して、受信側がフィードバック信号（例えば、ＡＣＫ／ＮＡＣＫ、伝搬環境情報など）を送信するので、信頼性を担保することができる。また、ブロードキャスト通信を用いるときと比較して繰り返し送信回数を削減することができ、周波数利用効率を向上することができる。
以上、特定の実施形態を参照しながら、本明細書で開示する技術について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
本明細書では、Ｖ２Ｘ通信におけるサイドリンク通信に関する実施形態を中心に説明してきたが、本明細書で開示する技術の要旨はこれに限定されるものではない。すなわち、本明細書で開示する技術は、Ｖ２Ｘ通信以外のユースケースにも同様に適用することが可能である。本明細書で開示する技術は、Ｄ２Ｄ（Ｄｅｖｉｃｅ ｔｏ Ｄｅｖｉｃｅ）通信やＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などさまざまなタイプの端末間直接通信に適用することができる。また、本明細書で開示する技術は、Ｍｏｖｉｎｇ ｃｅｌｌ（移動式基地局）やＲｅｌａｙ通信などへも適用することができる。
要するに、例示という形態により本明細書で開示する技術について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。
なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）無線信号を送受信する通信部と、
前記通信部による、所定のリソースプールを用いたデータの送信と、前記データの送信先の端末からのフィードバックの受信を制御する制御部と、
を具備する通信装置。
（１−１）所定のリソースプールを用いてデータを送信するステップ、
前記データの送信先の端末から前記所定のリソースプール内で送信されたフィードバックを受信するステップと、
を有する通信方法。
（２）前記制御部は、前記データの送信用のリソース及び前記データの送信先の端末のための前記フィードバック用リソースを前記所定のリソースプール内で確保するように、さらに制御する、
上記（１）に記載の通信装置。
（３）前記制御部は、前記送信先の端末に対して、ＳＣＩを用いて前記フィードバック用リソースに関する情報を通知するように、さらに制御する、
上記（２）に記載の通信装置。
（４）前記制御部は、前記フィードバック用リソースの前記データの送信用のリソースからのオフセット又は位置情報を、前記ＳＣＩを用いて通知するように、制御する、
上記（３）に記載の通信装置。
（５）前記制御部は、Ｒｅｓｏｕｒｃｅ ｒｅｓｅｒｖａｔｉｏｎ ｉｎｄｉｃａｔｏｒを用いて前記フィードバック用リソースを予約するように、さらに制御する、
上記（３）又は（４）のいずれかに記載の通信装置。
（６）前記制御部は、前記ＳＣＩで指示した前記フィードバック用リソースと前記予約したフィードバック用リソースとの時間方向又は周波数方向のオフセットを前記ＳＣＩに含めるように、さらに制御する、
上記（５）に記載の通信装置。
（７）前記制御部は、データの送信周期に基づく時間方向のオフセットにより前記フィードバック用リソースを予約するように、さらに制御する、
上記（５）又は（６）のいずれかに記載の通信装置。
（８）前記制御部は、送信データの優先度及び周辺で送信されているパケットの優先度の比較に基づいて前記データの送信用のリソースをセンシングするとともに、フィードバックに関して規定した優先度に基づいて前記フィードバック用リソースをセンシングするように、さらに制御する、
上記（２）乃至（６）のいずれかに記載の通信装置。
（９）前記制御部は、確保した前記フィードバック用リソースを前記送信先の端末に通知するように、さらに制御する、
請求項２乃至８のいずれかに記載の通信装置。
（１０）前記制御部は、前記データの送信直後を基準として、複数の前記送信先の端末の前記フィードバック用リソースの割り当てを決定する、
上記（９）に記載の通信装置。
（１１）前記制御部は、複数の前記送信先の端末の所定の識別情報に基づく順番に従って、前記データの送信直後からの前記フィードバック用リソースを割り当てる、
上記（１０）に記載の通信装置。
（１２）前記制御部は、前記フィードバックを受信したことに応答して、前記データの再送をさらに制御する、
上記（１）乃至（１１）のいずれかに記載の通信装置。
（１３）前記制御部は、再送上限数、受信したＮＡＣＫ数、送信した前記データの優先度、前記データ及び前記フィードバックを送受信するリンクのチャネル状況、又は、前記送信先の端末におけるデータ再送に関するプロセス状況のうち少なくとも１つからなる条件に基づいて、データ再送を行うかどうかを判断する、
上記（１２）に記載の通信装置。
（１４）端末からのアップリンクの無線信号を受信し、端末へのダウンリンクの無線信号を送信する通信部と、
前記端末間で通信するサイドリンクのためのリソースの割り当てを制御する制御部と、
を具備し、
前記制御部は、前記サイドリンクに割り当てたリソースプール内でフィードバック用リソースを割り当てる、
通信装置。
（１５）前記制御部は、前記所定のリソースプール内に前記フィードバック用リソースを周期的に割り当てる、
上記（１４）に記載の通信装置。
（１６）前記制御部は、ＳＩＢ又はＲＲＣシグナリングを用いて前記フィードバック用リソースに関する情報を前記端末に通知するように、さらに制御する、
上記（１５）に記載の通信装置。
（１７）前記制御部は、符号化多重又はプリアンブル送信を用いて、同じリソースを複数の端末の前記フィードバック用リソースに多重化する、
上記（１５）又は（１６）のいずれかに記載の通信装置。
（１７−１）前記制御部は、前記送信先の端末において前記フィードバック用リソースに割り当て可能なリソースの制限を設定するように、さらに制御する、
上記（１４）に記載の通信装置。
（１７−２）前記制御部は、設定した前記リソースの制限に関する情報を、ＲＲＣシグナリング又はＳＩＢを用いて端末に通知する、
上記（１７−１）に記載の通信装置。
（１８）無線信号を送受信する通信部と、
前記通信部による、所定のリソースプールを用いて送信されたデータの受信と、前記データの送信元の端末へのフィードバックの送信を制御する制御部と、
を具備する通信装置。
（１８−１）所定のリソースプールを用いて伝送されるデータを受信するステップと、
前記データに対するフィードバックを前記所定のリソースプール内で送信するステップと、
を有する通信方法。
（１９）前記制御部は、前記送信元の端末が確保したフィードバック用リソースを用いてフィードバックを送信するように制御する、
上記（１８）に記載の通信装置。
（１９−１）前記制御部は、前記送信元の端末からＳＣＩを用いて通知されたフィードバック用リソースを用いてフィードバックを送信するように制御する、
上記（１８）又は（１９）のいずれかに記載の通信装置。
（１９−２）前記制御部は、前記ＳＣＩ内に含まれるＲｅｓｏｕｒｃｅ ｒｅｓｅｒｖａｔｉｏｎ ｉｎｄｉｃａｔｏｒから、予約されている前記フィードバック用リソースを認識する、
上記（１９−１）に記載の通信装置。
（２０）前記制御部は、基地局が前記所定のリソースプール内に周期的に割り当てたフィードバック用リソースを用いてフィードバックを送信するように制御する、
上記（１８）に記載の通信装置。
（２０−１）前記制御部は、前記基地局からＳＩＢ又はＲＲＣシグナリングを用いて通知された前記フィードバック用リソースを用いてフィードバックを送信するように制御する、
上記（２０）に記載の通信装置。
（２０−２）前記制御部は、前記フィードバック用リソースのうち最も早く使用可能なリソースを用いてフィードバックを送信するように制御する、
上記（２０）又は（２０−１）のいずれかに記載の通信装置。
（２０−３）前記制御部は、基地局からＭＡＣ ＣＥ又はＲＲＣシグナリングを用いて通知された前記フィードバック用リソースを用いてフィードバックを送信するように制御する、
上記（１８）、（２０）乃至（２０−２）のいずれかに記載の通信装置。
（２１）前記制御部は、前記フィードバック用リソースをセンシングして、発見できたリソースを用いて前記フィードバックを送信するように制御する、
上記（１９）に記載の通信装置。
（２２）前記制御部は、自ら前記フィードバック用リソースに関する情報を、ＳＣＩを用いて前記送信元の端末に通知するように、さらに制御する、
上記（２１）に記載の通信装置。
（２３）前記制御部は、基地局又は前記データの送信的の端末が設定したリソースの制限内で、前記フィードバック用リソースを確保するように、さらに制御する、
上記（２１）に記載の通信装置。
（２４）前記制御部は、前記データを受信してから所定の時間内に送信するデータに前記フィードバックをＰｉｇｇｙ ｂａｃｋして送信するように、さらに制御する、
上記（１８）又は（２１）のいずれかに記載の通信装置。
（２５）前記通信部は、接続先の基地局から割り当てられたサイドリンク用の前記所定のリソースプールを用いて無線信号の送受信を行う、
上記（１）乃至（１３）、又は上記（１８）乃至（２４）のいずれかに記載の通信装置。
（２６）前記制御部は、初送時と再送時でＳＣＩの少なくとも一部のパラメータを読み替えるように、さらに制御する、
上記（１）乃至（１３）、又は上記（１８）乃至（２４）のいずれかに記載の通信装置。
（２７）前記制御部は、初送時におけるＳＣＩ内で繰り返し送信回数を通知するフィールドを、再送時においてＲＶ情報を通知するフィールドに読み替えるように、さらに制御する、
上記（２６）に記載の通信装置。
１０…ＵＥ（ユーザ携行）、２０…ＵＥ（車両搭載）
２２…移動体（車両）、３０…ｅＮＢ、４０…ＧＮＳＳ衛星
５０…ＲＳＵ
２１０…アンテナ部、２２０…無線通信部
２３０…ＧＮＳＳ信号処理部、２４０…記憶部、２５０…処理部
３１０…アンテナ部、３２０…無線通信部
３３０…ネットワーク通信部、３４０…記憶部、３５０…処理部

Claims (20)

  1. 無線信号を送受信する通信部と、
    前記通信部による、所定のリソースプールを用いたデータの送信と、前記データの送信先の端末からのフィードバックの受信を制御する制御部と、
    を具備する通信装置。
  2. 前記制御部は、前記データの送信用のリソース及び前記データの送信先の端末のための前記フィードバック用リソースを前記所定のリソースプール内で確保するように、さらに制御する、
    請求項１に記載の通信装置。
  3. 前記制御部は、前記送信先の端末に対して、ＳＣＩ（Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）を用いて前記フィードバック用リソースに関する情報を通知するように、さらに制御する、
    請求項２に記載の通信装置。
  4. 前記制御部は、前記フィードバック用リソースの前記データの送信用のリソースからのオフセット又は位置情報を、前記ＳＣＩを用いて通知するように、制御する、
    請求項３に記載の通信装置。
  5. 前記制御部は、Ｒｅｓｏｕｒｃｅ ｒｅｓｅｒｖａｔｉｏｎ ｉｎｄｉｃａｔｏｒを用いて前記フィードバック用リソースを予約するように、さらに制御する、
    請求項３に記載の通信装置。
  6. 前記制御部は、前記ＳＣＩで指示した前記フィードバック用リソースと前記予約したフィードバック用リソースとの時間方向又は周波数方向のオフセットを前記ＳＣＩに含めるように、さらに制御する、
    請求項５に記載の通信装置。
  7. 前記制御部は、データの送信周期に基づく時間方向のオフセットにより前記フィードバック用リソースを予約するように、さらに制御する、
    請求項５に記載の通信装置。
  8. 前記制御部は、送信データの優先度及び周辺で送信されているパケットの優先度の比較に基づいて前記データの送信用のリソースをセンシングするとともに、フィードバックに関して規定した優先度に基づいて前記フィードバック用リソースをセンシングするように、さらに制御する、
    請求項２に記載の通信装置。
  9. 前記制御部は、確保した前記フィードバック用リソースを前記送信先の端末に通知するように、さらに制御する、
    請求項２に記載の通信装置。
  10. 前記制御部は、前記データの送信直後を基準として、複数の前記送信先の端末の前記フィードバック用リソースの割り当てを決定する、
    請求項９に記載の通信装置。
  11. 前記制御部は、複数の前記送信先の端末の所定の識別情報に基づく順番に従って、前記データの送信直後からの前記フィードバック用リソースを割り当てる、
    請求項１０に記載の通信装置。
  12. 前記制御部は、前記フィードバックを受信したことに応答して、前記データの再送をさらに制御する、
    請求項１に記載の通信装置。
  13. 前記制御部は、再送上限数、受信したＮＡＣＫ数、送信した前記データの優先度、前記データ及び前記フィードバックを送受信するリンクのチャネル状況、又は、前記送信先の端末におけるデータ再送に関するプロセス状況のうち少なくとも１つからなる条件に基づいて、データ再送を行うかどうかを判断する、
    請求項１２に記載の通信装置。
  14. 端末からのアップリンクの無線信号を受信し、端末へのダウンリンクの無線信号を送信する通信部と、
    前記端末間で通信するサイドリンクのためのリソースの割り当てを制御する制御部と、
    を具備し、
    前記制御部は、前記サイドリンクに割り当てたリソースプール内でフィードバック用リソースを割り当てる、
    通信装置。
  15. 前記制御部は、前記所定のリソースプール内に前記フィードバック用リソースを周期的に割り当てる、
    請求項１４に記載の通信装置。
  16. 前記制御部は、ＳＩＢ（Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）又はＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）シグナリングを用いて前記フィードバック用リソースに関する情報を前記端末に通知するように、さらに制御する、
    請求項１５に記載の通信装置。
  17. 前記制御部は、符号化多重又はプリアンブル送信を用いて、同じリソースを複数の端末の前記フィードバック用リソースに多重化する、
    請求項１５又は１６のいずれかに記載の通信装置。
  18. 無線信号を送受信する通信部と、
    前記通信部による、所定のリソースプールを用いて送信されたデータの受信と、前記データの送信元の端末へのフィードバックの送信を制御する制御部と、
    を具備する通信装置。
  19. 前記制御部は、前記送信元の端末が確保したフィードバック用リソースを用いてフィードバックを送信するように制御する、
    請求項１８に記載の通信装置。
  20. 前記制御部は、基地局が前記所定のリソースプール内に周期的に割り当てたフィードバック用リソースを用いてフィードバックを送信するように制御する、
    請求項１８に記載の通信装置。
JP2019544408A 2017-09-27 2018-08-16 通信装置 Active JP7230815B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2017186184 2017-09-27
JP2017186184 2017-09-27
PCT/JP2018/030454 WO2019064983A1 (ja) 2017-09-27 2018-08-16 通信装置

Publications (2)

Publication Number Publication Date
JPWO2019064983A1 true JPWO2019064983A1 (ja) 2020-10-22
JP7230815B2 JP7230815B2 (ja) 2023-03-01

Family

ID=65901200

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019544408A Active JP7230815B2 (ja) 2017-09-27 2018-08-16 通信装置

Country Status (5)

Country Link
US (1) US11272573B2 (ja)
EP (1) EP3691361A4 (ja)
JP (1) JP7230815B2 (ja)
CN (1) CN111133811B (ja)
WO (1) WO2019064983A1 (ja)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7230815B2 (ja) * 2017-09-27 2023-03-01 ソニーグループ株式会社 通信装置
CN109075955B (zh) * 2018-07-20 2020-12-04 北京小米移动软件有限公司 信息发送方法、装置、终端及存储介质
US11368201B2 (en) * 2018-09-28 2022-06-21 Electronics And Telecommunications Research Institute Method for groupcast transmission and reception with feedback information, and apparatus therefor
US11108507B2 (en) 2018-10-04 2021-08-31 Lg Electronics Inc. Method and apparatus for transmitting sidelink HARQ feedback in NR V2X
WO2020071783A1 (ko) * 2018-10-04 2020-04-09 엘지전자 주식회사 Nr v2x에서 사이드링크 harq 피드백을 전송하는 방법 및 장치
JP7201081B2 (ja) * 2018-11-01 2023-01-10 日本電気株式会社 ソースデバイスにより実行される方法、ネットワークノードにより実行される方法、宛先デバイスにより実行される方法、ソースデバイス及び宛先デバイス
CN113557685A (zh) * 2019-04-23 2021-10-26 Oppo广东移动通信有限公司 用于传输侧行数据的方法和终端设备
JP7292953B2 (ja) * 2019-04-25 2023-06-19 キヤノン株式会社 通信装置、通信装置の制御方法、およびプログラム
WO2020220290A1 (zh) * 2019-04-30 2020-11-05 富士通株式会社 边链路数据的发送和接收方法以及装置
CN113785636A (zh) 2019-05-10 2021-12-10 株式会社Ntt都科摩 用户装置和通信方法
WO2020230213A1 (ja) * 2019-05-10 2020-11-19 株式会社Ｎｔｔドコモ ユーザ装置
JP6826226B2 (ja) * 2019-06-10 2021-02-03 華碩電腦股▲ふん▼有限公司 無線通信システムにおけるサイドリンクにおいて、グループキャストのためのフィードバックリソースを処理するための方法および装置
KR20200143271A (ko) * 2019-06-14 2020-12-23 한국전자통신연구원 사이드 링크 통신 방법 및 장치
CN114553384A (zh) * 2019-07-24 2022-05-27 维沃移动通信有限公司 旁链路信息传输方法、终端和控制节点
CN111800219B (zh) * 2019-07-29 2022-05-24 维沃移动通信有限公司 数据传输方法、用户设备及控制节点
EP3994930A4 (en) 2019-08-05 2022-08-17 LG Electronics Inc. METHOD AND DEVICE FOR SELECTING RESOURCES IN V2X NR
CN112398593A (zh) * 2019-08-13 2021-02-23 上海朗桦通信技术有限公司 一种被用于无线通信的节点中的方法和装置
US11533134B2 (en) * 2019-08-15 2022-12-20 Qualcomm Incorporated Feedback communication on a sidelink
CN115051779A (zh) * 2019-10-12 2022-09-13 华为技术有限公司 通信方法及装置
CA3157609A1 (en) * 2019-11-07 2021-05-14 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Method and apparatus for determining sidelink feedback resource, and terminal and storage medium
CN114762281A (zh) * 2020-02-07 2022-07-15 Oppo广东移动通信有限公司 数据传输方法、装置及设备
CN113271182B (zh) * 2020-02-14 2022-12-06 中国移动通信有限公司研究院 一种确定直通链路进程的方法及设备
US11812412B2 (en) * 2020-06-29 2023-11-07 Qualcomm Incorporated Control information transmissions for side-link communication
CN114615743A (zh) * 2020-12-08 2022-06-10 华为技术有限公司 一种资源分配方法及装置
US11638284B2 (en) * 2021-01-08 2023-04-25 Qualcomm Incorporated Dynamic time division duplexing for enhanced sidelink control signaling
US11722991B2 (en) * 2021-01-12 2023-08-08 Qualcomm Incorporated Dynamic configuration of physical sidelink feedback channel format
WO2022153416A1 (ja) * 2021-01-13 2022-07-21 株式会社Ｎｔｔドコモ 端末、及び送信方法
WO2022254554A1 (ja) * 2021-05-31 2022-12-08 株式会社Ｎｔｔドコモ 端末及び通信方法
CN116828624A (zh) * 2022-03-05 2023-09-29 上海推络通信科技合伙企业(有限合伙) 一种被用于无线通信的通信节点中的方法和装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014167883A1 (ja) * 2013-04-10 2014-10-16 ソニー株式会社 端末装置、通信制御方法及び通信制御装置
WO2016076301A1 (ja) * 2014-11-14 2016-05-19 株式会社Ｎｔｔドコモ ユーザ装置、フィードバック制御方法、及び再送制御方法

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010090492A2 (ko) * 2009-02-09 2010-08-12 엘지전자주식회사 상향링크 제어정보 전송 방법 및 장치
FI20100056A0 (fi) * 2010-02-12 2010-02-12 Notava Oy Menetelmä ja palvelinjärjestelmä hallittuun verkonvalintaan ja dataliikenteen uudelleenohjaukseen
WO2012169756A2 (ko) * 2011-06-06 2012-12-13 엘지전자 주식회사 반송파 집성 기법이 적용된 무선 통신 시스템에서 복수의 단말에 관한 신호를 다중화하는 방법 및 이를 위한 장치
US8804689B2 (en) * 2012-05-16 2014-08-12 Qualcommm Incorporated Methods and apparatus for peer-to-peer communications resource scheduling
CN110177358B (zh) * 2013-05-01 2022-06-14 三星电子株式会社 用于设备到设备通信系统的方法和装置
JP5931828B2 (ja) * 2013-09-26 2016-06-08 株式会社Ｎｔｔドコモ ユーザ端末、基地局及び無線通信方法
CN110856271B (zh) * 2014-03-21 2024-06-04 三星电子株式会社 设备到设备终端的资源分配方法和装置
EP3614790A1 (en) * 2015-05-18 2020-02-26 Huawei Technologies Co., Ltd. Terminal device, network device, and data transmission method
JP6510661B2 (ja) * 2015-09-24 2019-05-08 株式会社Ｎｔｔドコモ ユーザ装置
JP6623802B2 (ja) 2016-02-04 2019-12-25 ソニー株式会社 ユーザ端末、通信装置及び方法
JP6696192B2 (ja) 2016-02-04 2020-05-20 ソニー株式会社 通信装置および通信方法
JP7230815B2 (ja) * 2017-09-27 2023-03-01 ソニーグループ株式会社 通信装置
WO2020218902A1 (ko) * 2019-04-25 2020-10-29 엘지전자 주식회사 무선 통신 시스템에서 사이드링크 자원을 할당 받기 위한 방법
CA3150268A1 (en) * 2019-08-08 2021-02-11 Zte Corporation Feedback channel allocation and transmission method and device

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014167883A1 (ja) * 2013-04-10 2014-10-16 ソニー株式会社 端末装置、通信制御方法及び通信制御装置
WO2016076301A1 (ja) * 2014-11-14 2016-05-19 株式会社Ｎｔｔドコモ ユーザ装置、フィードバック制御方法、及び再送制御方法

Also Published As

Publication number Publication date
WO2019064983A1 (ja) 2019-04-04
CN111133811A (zh) 2020-05-08
EP3691361A1 (en) 2020-08-05
US20200296796A1 (en) 2020-09-17
US11272573B2 (en) 2022-03-08
JP7230815B2 (ja) 2023-03-01
CN111133811B (zh) 2024-04-23
EP3691361A4 (en) 2021-03-10

Similar Documents

Publication Publication Date Title
JP7230815B2 (ja) 通信装置
US11363428B2 (en) System and method for providing vehicular communication in an advanced wireless network
CN108632779B (zh) 资源分配方法及装置、资源预留方法及装置
CN110139323B (zh) 在支持v2x的通信系统中进行负载分配的方法和装置
JP2020530673A (ja) 無線通信システムにおけるアップリンクリソースとサイドリンクリソースを共有して端末間通信を実行する方法及び装置
CN111108789B (zh) 通信设备和通信方法
CN113261312A (zh) 侧链路通信中的邻近意识
KR102387506B1 (ko) 데이터 송수신 방법 및 장치
US11582834B2 (en) Method and apparatus for deciding packet communication range in terminal direct communication system
KR20200099394A (ko) 무선통신 시스템에서 harq 재전송을 지원하는 방법 및 장치
US20210307029A1 (en) Communication device
CN107005592A (zh) 控制信令处理方法、装置及设备
US20240056233A1 (en) Method for user equipment to transmit and receive feedback information in wireless communication system supporting sidelink and device for same
EP4154629A1 (en) Cooperative sensing for sidelink communication
WO2020168900A1 (zh) 用于侧行链路通信的调度方法、终端装置以及网络装置
KR20170036623A (ko) 네트워크에서 직접 통신을 지원하는 통신 노드의 동작 방법
US20220061026A1 (en) Terminal device, base station, method, and recording medium
JP7190520B2 (ja) 端末間直接通信における無線リソース割当制御モードの選択制御を行うシステム、無線端末装置、車両、制御装置、基地局、方法及びプログラム
WO2022190791A1 (ja) 端末間直接通信における制御を行うシステム、無線端末装置、車両、制御装置、基地局、方法及びプログラム
JP7434623B2 (ja) 端末間直接通信を介したデータ伝送におけるｈａｒｑ再送制御を行うシステム、無線端末装置、車両、基地局、方法及びプログラム
WO2022117819A1 (en) Traffic based random resource selection on nr sidelink
WO2022238314A9 (en) Ue-a determination in inter-ue coordination

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210707

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220802

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220926

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230117

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230130

R151 Written notification of patent or utility model registration

Ref document number: 7230815

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151