JP6623802B2 - ユーザ端末、通信装置及び方法 - Google Patents

ユーザ端末、通信装置及び方法 Download PDF

Info

Publication number
JP6623802B2
JP6623802B2 JP2016020142A JP2016020142A JP6623802B2 JP 6623802 B2 JP6623802 B2 JP 6623802B2 JP 2016020142 A JP2016020142 A JP 2016020142A JP 2016020142 A JP2016020142 A JP 2016020142A JP 6623802 B2 JP6623802 B2 JP 6623802B2
Authority
JP
Japan
Prior art keywords
communication
user terminal
information
rsu
processing unit
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.)
Active
Application number
JP2016020142A
Other languages
English (en)
Other versions
JP2017139659A (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
Priority to JP2016020142A priority Critical patent/JP6623802B2/ja
Application filed by Sony Corp filed Critical Sony Corp
Priority to RU2018127198A priority patent/RU2732994C2/ru
Priority to PCT/JP2017/001611 priority patent/WO2017135036A1/en
Priority to US15/766,654 priority patent/US10568029B2/en
Priority to MX2018009198A priority patent/MX2018009198A/es
Priority to EP17703480.8A priority patent/EP3412109B1/en
Priority to SG11201804837PA priority patent/SG11201804837PA/en
Priority to ES17703480T priority patent/ES2930438T3/es
Priority to TW106102452A priority patent/TWI752936B/zh
Publication of JP2017139659A publication Critical patent/JP2017139659A/ja
Priority to ZA2018/03066A priority patent/ZA201803066B/en
Application granted granted Critical
Publication of JP6623802B2 publication Critical patent/JP6623802B2/ja
Priority to US16/784,244 priority patent/US11272448B2/en
Priority to US17/685,382 priority patent/US11683754B2/en
Priority to US18/198,285 priority patent/US20230292239A1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0212—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave
    • H04W52/0216—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave using a pre-established activity schedule, e.g. traffic indication frame
    • 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
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0212—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave
    • H04W52/0219—Power saving arrangements in terminal devices managed by the network, e.g. network or access point is master and terminal is slave where the power saving management affects multiple terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0251—Power saving arrangements in terminal devices using monitoring of local events, e.g. events related to user activity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/14—Direct-mode setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/28—Discontinuous transmission [DTX]; Discontinuous reception [DRX]
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Description

本開示は、ユーザ端末、通信装置及び方法に関する。
車両等の移動体に搭載された通信装置を利用することによって、移動体と種々の対象物との間における直接的な通信が実現される。移動体に搭載された通信装置と種々の他の通信装置との間における通信は、Ｖ２Ｘ（Ｖｅｈｉｃｌｅ ｔｏ Ｘ）通信と称されている。Ｖ２Ｘ通信については、これまで、ＤＳＲＣ（Ｄｅｄｉｃａｔｅｄ Ｓｈｏｒｔ Ｒａｎｇｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）が利用される通信システムについて検討されてきたが、近年、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）等の携帯電話の通信規格が利用される通信システムについての検討が進められている。なお、ＬＴＥの通信規格に関するシステムについては、例えば下記非特許文献１に開示されている。
上記のＶ２Ｘ通信において、歩行者に携行される通信装置は、移動体に搭載された通信装置又は道路脇に設置される通信装置等と通信を行うことで、歩行者の安全の確保等に寄与し得る。しかし、歩行者に携行される通信装置は、電力量が豊富でない又はＶ２Ｘ通信のために使用可能な電力量が制限されて、安全の確保等を十分に行うことが困難になるおそれがある。そのため、歩行者に携行される通信装置のための電力消費を低減したＶ２Ｘ通信の仕組みが提供されることが望ましい。
本開示によれば、移動体、ＲＳＵ（Road Side Unit）又は基地局との通信を行う通信部と、移動体又はＲＳＵとの間欠的な通信のためのパラメータを設定する処理部と、を備えるユーザ端末が提供される。
また、本開示によれば、移動体に搭載される通信装置であって、ユーザ端末の間欠的に通信可能になるタイミングに応じて前記ユーザ端末との通信を行う処理部、を備える通信装置が提供される。
また、本開示によれば、移動体、ＲＳＵ又は基地局との通信を行うことと、移動体又はＲＳＵとの間欠的な通信のためのパラメータをプロセッサにより設定することと、を含む方法が提供される。
また、本開示によれば、ユーザ端末の間欠的に通信可能になるタイミングに応じて、移動体に搭載される通信装置により前記ユーザ端末との通信を行うこと、を含む方法が提供される。
以上説明したように本開示によれば、歩行者に携行される通信装置のための電力消費を低減したＶ２Ｘ通信の仕組みが提供される。なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。
Ｖ２Ｘ通信の概要について説明するための説明図である。 Ｖ２Ｖ通信の第１のシナリオを説明するための説明図である。 Ｖ２Ｖ通信の第２のシナリオを説明するための説明図である。 Ｖ２Ｖ通信の第３のシナリオを説明するための説明図である。 Ｖ２Ｖ通信の第４のシナリオを説明するための説明図である。 Ｖ２Ｖ通信の第５のシナリオを説明するための説明図である。 本開示の一実施形態による無線通信システムの構成を示す説明図である。 同実施形態に係るＵＥの論理的な構成の一例を示すブロック図である。 同実施形態に係るＵＥの論理的な構成の一例を示すブロック図である。 同実施形態に係るｅＮＢの論理的な構成の一例を示すブロック図である。 同実施形態に係るＲＳＵの論理的な構成の一例を示すブロック図である。 第１の実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 第２の実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 同実施形態の技術的特徴を説明するための図である。 ｅＮＢの概略的な構成の第１の例を示すブロック図である。 ｅＮＢの概略的な構成の第２の例を示すブロック図である。 スマートフォンの概略的な構成の一例を示すブロック図である。 カーナビゲーション装置の概略的な構成の一例を示すブロック図である。
以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
また、本明細書及び図面において、実質的に同一の機能構成を有する複数の構成要素を、同一の符号の後に異なるアルファベットを付して区別する場合もある。例えば、実質的に同一の機能構成または論理的意義を有する複数の構成を、必要に応じてＵＥ１０Ａ、１０Ｂおよび１０Ｃのように区別する。ただし、実質的に同一の機能構成を有する複数の構成要素の各々が特に区別されなくてもよい場合、同一符号のみを付する。例えば、ＵＥ１０Ａ、１０Ｂおよび１０Ｃが特に区別されなくてもよい場合には、ＵＥ１０Ａ、１０Ｂおよび１０Ｃの各々を単にＵＥ１０と称する。
なお、説明は以下の順序で行うものとする。
１．はじめに
１．１．Ｖ２Ｘ通信
１．２．技術的課題
２．構成例
２．１．システムの構成例
２．２．ＵＥ（ユーザ端末）の構成例
２．３．ＵＥ（移動体）の構成例
２．４．ｅＮＢの構成例
２．５．ＲＳＵの構成例
３．第１の実施形態
４．第２の実施形態
５．応用例
６．まとめ
＜＜１．はじめに＞＞
＜１．１．Ｖ２Ｘ通信＞
車両等の移動体に搭載された通信装置を利用することによって、移動体と種々の対象物との間における直接的な通信が実現される。車両と種々の対象物との間における通信は、Ｖ２Ｘ（Ｖｅｈｉｃｌｅ ｔｏ Ｘ）通信と称されている。図１は、Ｖ２Ｘ通信の概要について説明するための説明図である。図１に示したように、Ｖ２Ｘ通信として、例えば、Ｖ２Ｖ（Ｖｅｈｉｃｌｅ ｔｏ Ｖｅｈｉｃｌｅ）通信、Ｖ２Ｉ（Ｖｅｈｉｃｌｅ ｔｏ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）通信、Ｖ２Ｐ（Ｖｅｈｉｃｌｅ ｔｏ Ｐｅｄｅｓｔｒｉａｎ）通信、Ｖ２Ｈ（Ｖｅｈｉｃｌｅ ｔｏ Ｈｏｍｅ）通信がある。その他、図示はされていないが、Ｖ２Ｘ通信として、例えばＶ２Ｎ（Ｖｅｈｉｃｌｅ ｔｏ Ｎｏｍａｄｉｃ ｄｅｖｉｃｅ）通信もある。ここで、Ｖ２Ｖ通信等の１文字目と３文字目は、それぞれ始点と終点とを意味しており、通信経路を限定するものではない。例えば、Ｖ２Ｖ通信は、移動体同士が直接的に通信すること、及び基地局等を介して間接的に通信することを含む概念である。
図１に示したように、Ｖ２Ｖ通信における車両の通信対象として、例えば、乗用車（ｐａｓｓｅｎｇｅｒ ｖｅｈｉｃｌｅ）、商用車（Ｃｏｍｍｅｒｃｉａｌ ｏｒ ｆｌｅｅｔ ｖｅｈｉｃｌｅ）、緊急車両（Ｅｍｅｒｇｅｎｃｙ ｖｅｈｉｃｌｅ）又は輸送車（Ｔｒａｎｓｉｔ ｖｅｈｉｃｌｅ）が挙げられる。また、Ｖ２Ｉ通信における車両の通信対象として、例えば、セルラーネットワーク（Ｃｅｌｌｕｌｅｒ ｎｅｔｗｏｒｋ）、データセンタ（Ｄａｔａ ｃｅｎｔｒｅ）、商用車管理センタ（ｆｌｅｅｔ ｏｒ ｆｒｅｉｇｈｔ ｍａｎａｇｅｍｅｎｔ ｃｅｎｔｒｅ）、交通管理センタ（Ｔｒａｆｆｉｃ ｍａｎａｇｅｍｅｎｔ ｃｅｎｔｒｅ）、気象サービス（Ｗｅａｔｈｅｒ ｓｅｒｖｉｃｅ）、列車運行センタ（Ｒａｉｌ ｏｐｅｒａｔｉｏｎ ｃｅｎｔｒｅ）、駐車システム（Ｐａｒｋｉｎｇ ｓｙｓｔｅｍ）又は料金システム（Ｔｏｌｌ ｓｙｓｔｅｍ）が挙げられる。また、Ｖ２Ｐ通信における車両の通信対象として、例えば、自転車の運転者（Ｃｙｃｌｉｓｔ）、歩行者用シェルタ（Ｐｅｄｅｓｔｒｉａｎ ｓｈｅｌｔｅｒ）、又は自動二輪（Ｍｏｔｏｒｃｙｃｌｅ）が挙げられる。また、Ｖ２Ｈ通信における車両の通信対象として、例えば、家庭用ネットワーク（Ｈｏｍｅ ｎｅｔｗｏｒｋ）、車庫（Ｇａｒａｇｅ）、又は商用ネットワーク（Ｅｎｔｅｒｐｒｉｓｅ ｏｒ ｄｅｅｌｅｒ ｎｅｔｗｏｒｋｓ）が挙げられる。
なお、Ｖ２Ｘ通信では、ＤＳＲＣ（Ｄｅｄｉｃａｔｅｄ Ｓｈｏｒｔ Ｒａｎｇｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）が利用される通信システムについて検討されてきたが、近年、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）等の携帯電話の通信規格が利用される通信システムについての検討が進められている。
Ｖ２Ｘ通信の適用例として、例えば、前方衝突警告、制御不能警告、緊急車両警告、緊急停車、適応走行支援、交通状態警告、交通安全、自動駐車、経路逸脱警告、メッセージ送信、衝突警告、通信範囲拡大、交通量適正化、カーブ速度警報、歩行者衝突警告又は脆弱者安全等を目的とした通信システムが挙げられる。その他、ＲＳＵ（Ｒｏａｄ Ｓｉｄｅ Ｕｎｉｔ）タイプのユーザ端末（ＵＥ：User Equipment）によるＶ２Ｘ通信、Ｖ２Ｘ通信の最低ＱｏＳ、ローミング時のＶ２Ｘアクセス、歩行者の交通安全のためのＶ２Ｐ通信を介したメッセージの提供、交通管理のための混合使用、又は交通参加者のための位置測定精度の向上等が検討されている。
上記の適用例のための要求事項の一覧を、下記の表１に示す。
Figure 0006623802
上記の要求事項を満たすために、Ｖ２Ｘ通信の物理レイヤの標準化が３ＧＰＰにおいて検討されている。Ｖ２Ｘ通信のベース技術としては、３ＧＰＰで過去に規格化されたＤ２Ｄ（Ｄｅｖｉｃｅ ｔｏ ｄｅｖｉｃｅ）通信が挙げられる。Ｄ２Ｄ通信は、基地局を介さない端末間通信であるため、Ｖ２Ｖ通信、Ｖ２Ｐ通信又は一部のＶ２Ｉ通信への拡張に向くと言える。このような、端末間のインタフェースは、ＰＣ５インタフェースとも称される。一方、Ｖ２Ｉ通信又はＶ２Ｎに関しては、ＬＴＥ等の既存の基地局と端末との通信技術を拡張することが想定されている。このような、基地局と端末とのインタフェースは、Ｕｕインタフェースとも称される。今後の検討では、ＰＣ５インタフェース及びＵｕインタフェースを、上記の要求事項を満たすよう拡張することが求められる。主な拡張ポイントとしては、例えばリソース割り当ての改善、ドップラー周波数対策、同期手法の確立、低消費電力通信の実現、及び低遅延通信の実現等が挙げられる。
Ｖ２Ｘ通信のオペレーションシナリオは多様に考えられる。一例として、図２〜図６を参照しながら、Ｖ２Ｖ通信のオペレーションシナリオの例を説明する。
図２は、Ｖ２Ｖ通信の第１のシナリオを説明するための説明図である。第１のシナリオでは、車両等の移動体同士が直接的にＶ２Ｖ通信を行う。この場合の通信リンクは、ＳＬ（SideLink）とも称される。
図３は、Ｖ２Ｖ通信の第２のシナリオを説明するための説明図である。第２のシナリオでは、車両等の移動体同士が、Ｅ−ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access）を介して、即ち基地局を介して間接的にＶ２Ｖ通信を行う。送信側から基地局への通信リンクはＵＬ（Uplink）とも称され、基地局から受信側への通信リンクはＤＬ（Downlink）とも称される。
図４は、Ｖ２Ｖ通信の第３のシナリオを説明するための説明図である。第３のシナリオでは、車両等の移動体が、ＲＳＵ又はＲＳＵタイプのＵＥ、及びＥ−ＵＴＲＡＮを順に介して他の移動体へ信号を送信する。各装置間の通信リンクは、順にＳＬ、ＵＬ、及びＤＬである。
図５は、Ｖ２Ｖ通信の第４のシナリオを説明するための説明図である。第４のシナリオでは、車両等の移動体が、Ｅ−ＵＴＲＡＮ、及びＲＳＵ又はＲＳＵタイプのＵＥを順に介して他の移動体へ信号を送信する。各装置間の通信リンクは、順にＵＬ、ＤＬ及びＳＬである。
図６は、Ｖ２Ｖ通信の第５のシナリオを説明するための説明図である。第５のシナリオでは、車両等の移動体同士が、ＲＳＵ又はＲＳＵタイプのＵＥを介して間接的にＶ２Ｖ通信を行う。移動体とＲＳＵ又はＲＳＵタイプのＵＥとの間の通信リンクは、ＳＬである。
以上説明した各シナリオは、移動体の片方を歩行者に変えると、Ｖ２Ｐ通信のシナリオとなる。同様に、各シナリオは、移動体の片方をインフラ又はネットワークに変えると、それぞれＶ２Ｉ通信又はＶ２Ｎ通信のシナリオとなる。
＜１．２．技術的課題＞
Ｖ２Ｐ通信では、移動体に搭載された通信装置と歩行者が携行する通信装置との間で通信が行われる。Ｖ２Ｐ通信における要求項目の一例を以下に説明する。遅延要求としては、サーバーから端末まで５００ｍｓ以内、且つＥｎｄ−ｔｏ−ｅｎｄで１００ｍｓ以内の遅延であることが挙げられる。オペレーション要求としては、マルチＭＮＯ（mobile network operator）対応であることが挙げられる。消費電力要求としては、バッテリー消費を最小化することが挙げられる。カバレッジ要求としては、衝突４秒以上前にＶ２Ｐ通信可能な範囲がカバーされることが挙げられる。例えば、時速１００ｋｍであれば、２７．７ｍ／ｓ×４ｓの約１１０．８ｍ以上を半径とするカバレッジが要求される。メッセージ要求としては、典型的には５０〜３００バイト、最大１２００バイトであることが挙げられる。通信品質要求としては、バイクと車との相対速度で時速２８０ｋｍ、歩行者と車との相対速度で時速１６０ｋｍの環境での通信が確立されることが挙げられる。
本開示では、上述した要求項目のうち、バッテリー消費の最小化を技術的課題とする。歩行者が携行する通信装置として想定されるスマートフォン等は、バッテリー量が豊富ではない場合が多い。そのため、バッテリー消費の最小化は、Ｖ２Ｐ通信の導入のために重要な課題であると言える。
＜＜２．構成例＞＞
以下、各実施形態において共通する無線通信システムの構成例を説明する。
＜２．１．システムの構成例＞
図７は、本開示の一実施形態による無線通信システムの構成を示す説明図である。図７に示したように、本開示の実施形態による無線通信システムは、ＵＥ１０、ＵＥ２０、車両２２、ｅＮＢ３０、ＧＮＳＳ衛星４０、及びＲＳＵ５０を有する。
ｅＮＢ３０は、セル内に位置するＵＥ２０にセルラー通信サービスを提供するセルラー基地局である。例えば、ｅＮＢ３０は、ＵＥ１０及びＵＥ２０が通信するためのリソースをスケジュールし、スケジュールしたリソースをＵＥ１０及びＵＥ２０に通知する。そして、ｅＮＢ３０は、当該リソースにおいてＵＥ１０及びＵＥ２０との間でアップリンク通信またはダウンリンク通信を行う。
ＧＮＳＳ衛星４０は、地球を所定の軌道に沿って周回する人工衛星（通信装置）である。ＧＮＳＳ衛星４０は、航法メッセージを含むＧＮＳＳ（Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ）信号を送信する。航法メッセージは、ＧＮＳＳ衛星４０の軌道情報および時間情報などの、位置測定のための種々の情報を含む。
ＲＳＵ５０は、道路脇に設置される通信装置である。ＲＳＵ５０は、車両２２若しくは車両２２に搭載されたＵＥ２０、又はユーザ１２が携行するＵＥ１０と双方向通信を行うことができる。なお、ＲＳＵ５０は、車両２２若しくは車両２２に搭載されたＵＥ２０、又はユーザ１２が携行するＵＥ１０とＤＳＲＣ通信を行い得るが、本実施形態においては、ＲＳＵ５０が、車両２２若しくは車両２２に搭載されたＵＥ２０、又はユーザ１２が携行するＵＥ１０とセルラー通信の方式に従って通信することも想定される。
ＵＥ２０は、車両２２に搭載され、車両２２の走行に伴って移動する通信装置である。ＵＥ２０は、ｅＮＢ３０による制御に従ってｅＮＢ３０と通信する機能を有する。また、ＵＥ２０は、ＧＮＳＳ衛星４０から送信されるＧＮＳＳ信号を受信し、ＧＮＳＳ信号に含まれる航法メッセージからＵＥ２０の位置情報を測定する機能を有する。また、ＵＥ２０は、ＲＳＵ５０と通信する機能を有する。さらに、本実施形態によるＵＥ２０は、ユーザ１２に携行されるＵＥ１０、又は他の車両２２に搭載されたＵＥ２０と直接通信すること、すなわち、Ｄ２Ｄ通信を行うことも可能である。以下では、ＵＥ２０及び移動体２２を特に区別する必要がない場合、ＵＥ２０と総称する。
ＵＥ１０は、ユーザ１２に携行され、ユーザ１２の歩行、走行又はユーザ１２が乗車した乗り物（バス、バイク、又は車等）の移動に伴って移動する通信装置である。ＵＥ１０は、ｅＮＢ３０による制御に従ってｅＮＢ３０と通信する機能を有する。また、ＵＥ１０は、ＧＮＳＳ衛星４０から送信されるＧＮＳＳ信号を受信し、ＧＮＳＳ信号に含まれる航法メッセージからＵＥ１０の位置情報を測定する機能を有する。また、ＵＥ１０は、ＲＳＵ５０と通信する機能を有する。さらに、本実施形態によるＵＥ１０は、他のＵＥ１０又はＵＥ２０と直接通信すること、すなわち、Ｄ２Ｄ通信を行うことも可能である。ＵＥ１０とＵＥ２０との通信はＶ２Ｐ通信とも称される。
なお、図７においては移動体の一例として車両２２を示しているが、移動体は車両２２に限定されない。例えば、移動体は、船舶、航空機および自転車などであってもよい。また、上記では、ＵＥ２０がＧＮＳＳ信号を受信する機能を有することを説明したが、車両２２がＧＮＳＳ信号を受信する機能を有し、車両２２がＧＮＳＳ信号の受信結果をＵＥ２０に出力してもよい。
＜２．２．ＵＥ（ユーザ端末）の構成例＞
図８は、本開示の一実施形態に係るＵＥ１０の論理的な構成の一例を示すブロック図である。図８に示すように、本実施形態に係るＵＥ１０は、アンテナ部１１０、無線通信部１２０、ＧＮＳＳ信号処理部１３０、記憶部１４０及び処理部１５０を含む。
アンテナ部１１０は、無線通信部１２０により出力される信号を電波として空間に放射する。また、アンテナ部１１０は、空間の電波を信号に変換し、当該信号を無線通信部１２０へ出力する。
無線通信部１２０は、信号を送受信する。例えば、無線通信部１２０は、ｅＮＢ３０からのダウンリンク信号を受信し、ｅＮＢ３０へのアップリンク信号を送信する。また、無線通信部１２０は、他のＵＥ１０、ＵＥ２０又はＲＳＵ５０との間でサイドリンク信号を送受信する。
ＧＮＳＳ信号処理部１３０は、ＧＮＳＳ衛星４０から送信されたＧＮＳＳ信号についての処理を行う構成である。例えば、ＧＮＳＳ信号処理部１３０は、ＧＮＳＳ信号を処理することにより、ＵＥ１０の位置情報および時間情報を測定する。
記憶部１４０は、ＵＥ１０の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。
処理部１５０は、ＵＥ１０の様々な機能を提供する。例えば、処理部１５０は、無線通信部１２０により行われる通信を制御する。
＜２．３．ＵＥ（移動体）の構成例＞
図９は、本開示の一実施形態に係るＵＥ２０の論理的な構成の一例を示すブロック図である。図９に示すように、本実施形態に係るＵＥ２０は、アンテナ部２１０、無線通信部２２０、ＧＮＳＳ信号処理部２３０、記憶部２４０及び処理部２５０を含む。
アンテナ部２１０は、無線通信部２２０により出力される信号を電波として空間に放射する。また、アンテナ部２１０は、空間の電波を信号に変換し、当該信号を無線通信部２２０へ出力する。
無線通信部２２０は、信号を送受信する。例えば、無線通信部２２０は、ｅＮＢ３０からのダウンリンク信号を受信し、ｅＮＢ３０へのアップリンク信号を送信する。また、無線通信部２２０は、ＵＥ１０、他のＵＥ２０又はＲＳＵ５０との間でサイドリンク信号を送受信する。
ＧＮＳＳ信号処理部２３０は、ＧＮＳＳ衛星４０から送信されたＧＮＳＳ信号についての処理を行う構成である。例えば、ＧＮＳＳ信号処理部２３０は、ＧＮＳＳ信号を処理することにより、ＵＥ２０の位置情報および時間情報を測定する。
記憶部２４０は、ＵＥ２０の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。
処理部２５０は、ＵＥ２０の様々な機能を提供する。例えば、処理部２５０は、無線通信部２２０により行われる通信を制御する。
＜２．４．ｅＮＢの構成例＞
図１０は、本開示の一実施形態に係るｅＮＢ３０の論理的な構成の一例を示すブロック図である。図１０に示すように、本実施形態に係るｅＮＢ３０は、アンテナ部３１０、無線通信部３２０、ネットワーク通信部３３０、記憶部３４０及び処理部３５０を含む。
アンテナ部３１０は、無線通信部３２０により出力される信号を電波として空間に放射する。また、アンテナ部３１０は、空間の電波を信号に変換し、当該信号を無線通信部３２０へ出力する。
無線通信部３２０は、信号を送受信する。例えば、無線通信部３２０は、ＵＥ１０、ＵＥ２０又はＲＳＵ５０からのアップリンク信号を受信し、ＵＥ１０、ＵＥ２０又はＲＳＵ５０へのダウンリンク信号を送信する。
ネットワーク通信部３３０は、情報を送受信する。例えば、ネットワーク通信部３３０は、他のノードへの情報を送信し、他のノードからの情報を受信する。例えば、上記他のノードは、他の基地局及びコアネットワークノードを含む。
記憶部３４０は、ｅＮＢ３０の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。
処理部３５０は、ｅＮＢ３０の様々な機能を提供する。例えば、処理部３５０は、配下のＵＥ１０、ＵＥ２０、及びＲＳＵ５０により行われる通信を制御する。
＜２．５．ＲＳＵの構成例＞
図１１は、本開示の一実施形態に係るＲＳＵ５０の論理的な構成の一例を示すブロック図である。図１１に示すように、本実施形態に係るＲＳＵ５０は、アンテナ部５１０、無線通信部５２０、記憶部５３０及び処理部５４０を含む。
アンテナ部５１０は、無線通信部５２０により出力される信号を電波として空間に放射する。また、アンテナ部５１０は、空間の電波を信号に変換し、当該信号を無線通信部５２０へ出力する。
無線通信部５２０は、信号を送受信する。例えば、無線通信部５２０は、ｅＮＢ３０からのダウンリンク信号を受信し、ｅＮＢ３０へのアップリンク信号を送信する。また、無線通信部５２０は、ＵＥ１０、ＵＥ２０又は他のＲＳＵ５０との間でサイドリンク信号を送受信する。
記憶部５３０は、ＲＳＵ５０の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。
処理部５４０は、ＲＳＵ５０の様々な機能を提供する。例えば、処理部５４０は、無線通信部５２０により行われる通信を制御する。
以上、各実施形態において共通する構成例を説明した。続いて、各実施形態の技術的特徴を詳細に説明する。
＜＜３．第１の実施形態＞＞
本実施形態は、場所に応じてＵＥ１０の通信機能をアクティベート又はディアクティベートすることで、電力消費を低減する形態である。
ＵＥ１０は、場所に応じて取得される情報に基づいて無線通信部１２０による通信機能をアクティベート又はディアクティベートする。例えば、ＵＥ１０は、移動体２２との事故の可能性が高い場所（例えば、道路近傍等）では通信機能をアクティベートし、可能性が低い場所（例えば、建物内）では通信機能をディアクティベートする。これにより、通信機能をアクティベートする期間を必要最低限にすることが可能となり、それに伴い電力消費を低減することが可能となる。
とりわけ本実施形態では、アクティベート又はディアクティベートされる通信機能は、Ｖ２Ｐ通信の機能であるものとする。もちろん、アクティベート又はディアクティベート対象のＶ２Ｐ通信の機能は、ＵＥ２０とサイドリンクを用いて直接的に通信する機能、並びにサイドリンク、アップリンク及びダウンリンク等を用いて間接的に通信する機能を含む。
他方、ＵＥ２０、ｅＮＢ３０、又はＲＳＵ５０は、ＵＥ１０がＶ２Ｐ通信をアクティベート又はディアクティベートするための情報をＵＥ１０に通知する。そのような情報としては、例えば後述する通信パラメータ、及び測定パラメータ等が挙げられる。
なお、アクティベートとは、通信機能の一部又は全部の有効化、省電力モードから通常動作モードへの動作モードの変更等を含む概念である。また、ディアクティベートとは、通信機能の一部又は全部の無効化、通常動作モードから省電力モードへの動作モードの変更等を含む概念である。
（１）位置情報に応じたアクティベート／ディアクティベート
場所に応じて取得される情報とは、ＵＥ１０の位置情報であってもよい。例えば、ＵＥ１０は、位置情報を測定し、アクティベート又はディアクティベートの要否を判断し、アクティベート又はディアクティベート処理を制御する。これらのステップは、ＵＥ１０により行われてもよいし、ＵＥ１０以外の装置により行われてもよい。ＵＥ１０以外の装置としては、例えば、ｅＮＢ３０又はＲＳＵ５０等が挙げられ、これらをＵＥ１０と対比させてネットワーク装置とも総称する。
（１．１）機能
（ａ）測定
ＵＥ１０が位置情報を測定する場合について説明する。例えば、ＵＥ１０は、ＧＮＳＳ測位、又はＡ−ＧＮＳＳ（Ａｓｓｉｓｔｅｄ ＧＰＳ）測位により、位置情報を測定し得る。他にも、ＵＥ１０は、端末同士でのＤ２Ｄ通信により位置を測定するＤ２Ｄ支援測位（Ｄ２Ｄ ａｉｄｅｄ ｐｏｓｉｔｉｏｎｉｎｇ）技術を用いて、位置情報を測定し得る。
続いて、ネットワーク装置がＵＥ１０の位置情報を測定する場合について説明する。例えば、ｅＮＢ３０は、ＯＴＤＯＡ（Ｏｂｓｅｒｖｅｄ Ｔｉｍｅ Ｄｉｆｆｅｒｅｎｃｅ ｏｆ Ａｒｒｉｖａｌ）技術、ＵＴＤＯＡ（Ｕｐｌｉｎｋ Ｔｉｍｅ Ｄｉｆｆｅｒｅｎｃｅ ｏｆ Ａｒｒｉｖａｌ）、又はＥ−ＣＩＤ（Ｅｎｈａｎｃｅｄ Ｃｅｌｌ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）技術を用いて位置情報を測定し得る。また、ＲＳＵ５０は、Ｄ２Ｄ支援測位技術を用いて、位置情報を推定し得る。その他、ネットワーク装置は、ＴＢＳ（Ｔｅｒｒｅｓｔｒｉａｌ ｂｅａｃｏｎ ｓｙｓｔｅｍｓ）技術、又はＷｉ−Ｆｉ（登録商標）若しくはＢｌｕｅｔｏｏｔｈ（登録商標）を用いた位置測位技術を用いて、位置情報を推定し得る。
位置情報は、高度情報を含んでいてもよい。高度情報は、例えば３ＧＰＰ屋内測位（３ＧＰＰ ｉｎｄｏｏｒ ｐｏｓｉｔｉｏｎｉｎｇ）技術により測定され得る。
（ｂ）判断
例えば、ＵＥ１０は、マップ情報を事前に取得して記憶しておく。そして、ＵＥ１０は、自身の位置情報とマップ情報とを比較結果に基づいて、Ｖ２Ｐ通信をアクティベート又はディアクティベートするか否かを判断する。例えば、ＵＥ１０は、移動体２２との事故の可能性が高い場所（例えば、道路近傍等）ではＶ２Ｐ通信をアクティベートすると判断し、可能性が低い場所（例えば、建物内）ではＶ２Ｐ通信をディアクティベートすると判断する。また、ＵＥ１０は、道路から所定距離以内に位置する場合にアクティベートすると判断してもよい。
他にも、ＵＥ１０は、特定エリアの範囲内に自身が位置する場合にＶ２Ｐ通信をアクティベートすると判断してもよい。ここでの特定エリアとは、例えばＲＳＵ５０が設置されていない交差点等である。Ｖ２Ｐ通信の特性を考慮すると、都市部のスクランブル交差点のような歩行者が多いエリアではＶ２Ｐ通信は行われないものと想定される。そこで、そのようなエリアでは、イメージセンサを搭載したＲＳＵ５０が設置され、事故の可能性を判断して周囲のＵＥ１０等へ通知することが想定される。そのため、ＲＳＵ５０が設置されたエリアではＵＥ１０のＶ２Ｐ通信がディアクティベートされ、ＲＳＵ５０が設置されないエリアではＶ２Ｐ通信がアクティベートされることが望ましい。
なお、上記では判断主体がＵＥ１０である場合について説明したが、判断主体がネットワーク装置である場合も、同様の方法で判断が行われ得る。
（ｃ）制御
ＵＥ１０は、上述した判断の結果に従って、アクティベート処理又はディアクティベート処理を制御する。アクティベートする場合、ＵＥ１０は、アクティベートするＶ２Ｐ通信に関するパラメータ（以下、通信パラメータとも称する）を取得する。ＵＥ１０は、ネットワーク装置から通信パラメータを取得してもよいし、予め通信パラメータを記憶していてもよい。
・送信／受信に共通する通信パラメータ
例えば、通信パラメータは、通信に用いる帯域情報又は多重化情報等を含んでいてもよい。多重化情報は、例えばＴＤＤ（Time Division Duplex）のコンフィギュレーション情報を含んでいてもよい。また、多重化情報は、アップリンクとダウンリンクとの多重化のための情報を含んでいてもよいし、ＵｕインタフェースとＰＣ５インタフェースとの多重化のための情報で含んでいてもよい。
また、通信パラメータは、同期関連情報を含んでいてもよい。同期関連情報は、ＰＣ５インタフェースにより取得される、フレームタイミングを示す情報、又は周波数情報を含んでいてもよい。また、同期関連情報は、ＵＴＣ（Universal Time， Coordinated）からのタイミングオフセット情報を含んでいてもよい。ここでのオフセットとは、ＵｕインタフェースとＰＣインタフェースとの間のフレームタイミングのずれを意味する。
また、通信パラメータは、ＧＮＳＳ機能のアクティベーション指示を含んでいてもよい。
・受信のための通信パラメータ
例えば、通信パラメータは、ＵＥ１０が受信するためにモニタリングするリソースに関する情報を含み得る。ここでのリソースとは、制御チャネル及びデータチャネルの両方を意味し得る。リソースに関する情報は、例えばリソースプールを示す情報、モニタリングする時間窓を示す情報、及び時間リソースパターンを示す情報等を含み得る。
・送信のための通信パラメータ
例えば、ＵＥ１０は、ＵＥ１０が送信するために用いるリソースに関する情報を含み得る。ここでのリソースとは、制御チャネル及びデータチャネルの両方を意味し得る。リソースに関する情報は、例えばリソースプールを示す情報、時間リソースパターンを示す情報、送信電力情報、ＭＣＳ（modulation and coding scheme）情報、及び再送回数情報等を含み得る。
以上、通信パラメータの一例を説明した。ＵＥ１０は、取得した通信パラメータを用いて、Ｖ２Ｐ通信をアクティベートする。
（１．２）処理の流れ
以下、図１２〜図１７を参照して、上述した測定、判断、及び制御の処理の流れのバリエーションを説明する。図１２〜図１７は、位置情報に応じたアクティベート処理の流れの一例を示すシーケンス図である。各シーケンスは、ネットワーク装置（ｅＮＢ３０又はＲＳＵ５０）及びＵＥ１０が関与する。
・第１のケース（ＵＥ→ＵＥ→ＵＥ）
本ケースは、測定、判断、及び制御をすべてＵＥ１０が行うケースである。本ケースでは、ＵＥ１０と他の装置とのシグナリングが不要となる。ネットワーク装置が存在しない場合、本ケースが採用される。
・第２のケース（ＵＥ→ＵＥ→ネットワーク装置）
本ケースは、測定及び判断をＵＥ１０が行い、制御をネットワーク装置が行うケースである。本ケースのシーケンスを図１２に示した。図１２に示すように、まず、ＵＥ１０は、測定（ステップＳ１０１）及び判断（ステップＳ１０２）を行い、判断結果を示す情報をネットワーク装置に通知する（ステップＳ１０３）。次いで、ネットワーク装置は、制御を行い（ステップＳ１０４）、アクティベートすることを指示するアクティベーション通知及び通信パラメータをＵＥ１０へ通知する（ステップＳ１０５）。
・第３のケース（ＵＥ→ネットワーク装置→ＵＥ）
本ケースは、測定及び制御をＵＥ１０が行い、判断をネットワーク装置が行うケースである。本ケースでは、ＵＥ１０が制御を行うので、その通信態様はＤ２Ｄ通信におけるＭｏｄｅ ２ ｃｏｍｍｕｎｉｃａｔｉｏｎのような自律通信型となる。本ケースのシーケンスを図１３に示した。図１３に示すように、まず、ＵＥ１０は、測定を行い（ステップＳ１１１）、測定した位置情報をネットワーク装置に通知する（ステップＳ１１２）。次いで、ネットワーク装置は、判断を行い（ステップＳ１１３）、アクティベーション通知をＵＥ１０に通知する（ステップＳ１１４）。次に、ＵＥ１０は、アクティベーション通知に従い制御を行う（ステップＳ１１５）。
・第４のケース（ＵＥ→ネットワーク装置→ネットワーク装置）
本ケースは、測定をＵＥ１０が行い、判断及び制御をネットワーク装置が行うケースである。本ケースのシーケンスを図１４に示した。図１４に示すように、まず、ＵＥ１０は、測定を行い（ステップＳ１２１）、測定した位置情報をネットワーク装置に通知する（ステップＳ１２２）。次いで、ネットワーク装置は、判断（ステップＳ１２３）及び制御（ステップＳ１２４）を行い、アクティベーション通知及び通信パラメータをＵＥ１０に通知する（ステップＳ１２５）。
・第５のケース（ネットワーク装置→ＵＥ→ＵＥ）
本ケースは、測定をネットワーク装置が行い、判断及び制御をＵＥ１０が行うケースである。本ケースのシーケンスを図１５に示した。図１５に示すように、まず、ネットワーク装置は、測定を行い（ステップＳ１３１）、測定した位置情報をＵＥ１０に通知する（ステップＳ１３２）。次いで、ＵＥ１０は、判断（ステップＳ１３３）及び制御（ステップＳ１３４）を行う。
・第６のケース（ネットワーク装置→ＵＥ→ネットワーク装置）
本ケースは、測定及び制御をネットワーク装置が行い、判断をＵＥ１０が行うケースである。本ケースのシーケンスを図１６に示した。図１６に示すように、まず、ネットワーク装置は、測定を行い（ステップＳ１４１）、測定した位置情報をＵＥ１０に通知する（ステップＳ１４２）。次いで、ＵＥ１０は、判断を行い（ステップＳ１４３）、判断結果をネットワーク装置に通知する（ステップＳ１４４）。次に、ネットワーク装置は、判断結果に従い制御を行い（ステップＳ１４５）、アクティベーション通知及び通信パラメータをＵＥ１０に通知する（ステップＳ１４６）。
・第７のケース（ネットワーク装置→ネットワーク装置→ＵＥ）
本ケースは、測定及び判断をネットワーク装置が行い、制御をＵＥ１０が行うケースである。本ケースでは、ＵＥ１０が制御を行うので、その通信態様はＤ２Ｄ通信におけるＭｏｄｅ ２ ｃｏｍｍｕｎｉｃａｔｉｏｎのような自律通信型となる。本ケースのシーケンスを図１７に示した。図１７に示すように、まず、ネットワーク装置は測定（ステップＳ１５１）及び判断（ステップＳ１５２）を行い、判断結果を示す情報をＵＥ１０に通知する（ステップＳ１５３）。次いで、ＵＥ１０は、制御を行う（ステップＳ１５４）。
・第８のケース（ネットワーク装置→ネットワーク装置→ネットワーク装置）
本ケースは、測定、判断、及び制御をすべてネットワーク装置が行うケースである。本ケースはレアケースである。
（２）相対関係に応じたアクティベート
場所に応じて取得される情報は、他の装置（例えば、ＵＥ２０又はＲＳＵ５０等）との相対関係を示す情報であってもよい。例えば、ＵＥ１０は、他の装置が送信した信号を測定し、測定結果が示す他の装置との相対関係に基づいてアクティベート又はディアクティベートの要否を判断し、アクティベート又はディアクティベート処理を制御する。これらのステップは、ＵＥ１０により行われてもよいし、ＵＥ１０以外のネットワーク装置により行われてもよい。以下では、これらのステップをＵＥ１０が行うものとして説明する。なお、相対関係とは、相対的な位置関係の他、相対的な速度の関係を含む概念である。
（２．１）機能
（ａ）測定
ＵＥ１０は、他の装置が送信した信号を測定し、測定結果に基づいて相対関係を推定する。例えば、測定対象は、Ｖ２Ｐ通信帯域の電力であってもよいし、とりわけ所定のリソースプールの電力であってもよい。また、測定対象は、ディスカバリ信号であってもよい。また、測定対象は、サイドリンク同期信号又はサイドリンクブロードキャスト信号であってもよい。また、ＲＳＵ５０がｅＮＢタイプである場合、ＲＳＵ５０から送信されるダウンリンク制御信号が測定対象であってもよい。
ＵＥ１０は、相対関係を推定するためのパラメータとして、上述した測定対象を測定するためのパラメータ（以下、測定パラメータとも称する）を取得する。ＵＥ１０は、ネットワーク装置から測定パラメータを取得してもよいし、予め測定パラメータを記憶していてもよい。例えば、測定パラメータは、モニタリングを行う帯域を示す帯域情報を含んでいてもよい。また、測定パラメータは、モニタリングを行う帯域における、フレームタイミング及び中心周波数情報等を含む同期情報を含んでいてもよい。なお、同期情報は、ＧＮＳＳ衛星４０からのＧＮＳＳ信号から取得されてもよい。また、測定パラメータは、測定周期、測定期間、及び測定対象のリソースプール情報等を含むメジャメントギャップ情報を含んでいてもよい。ＵＥ１０は、測定対象に応じて、上述した帯域情報、同期情報又はメジャメントギャップ情報のうちひとつ以上を取得する。
ＵＥ１０は、取得した測定パラメータを用いて、測定対象を測定する。これにより、ＵＥ１０は、測定する周波数、及びタイミング等を適切に限定して、消費電力を低減することが可能となる。ここで、ＵＥ１０は、測定パラメータをＵＥ１０の情報に応じて変更してもよい。例えば、ＵＥ１０は、自身の位置情報に応じて、道路から離れていれば測定周期を長く、測定期間を短くする等、メジャメントギャップ情報を変更してもよい。他にも、ＵＥ１０は、ＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）数（例えば、ＲＦ回路の数）、又はバッテリー残量に応じて測定パラメータを変更してもよい。このような変更により、ＵＥ１０の状況に応じたさらなる電力消費の低減が可能となる。
（ｂ）判断
ＵＥ１０は、上述した測定の結果に基づいて、Ｖ２Ｐ通信をアクティベート又はディアクティベートするか否かを判断する。例えば、ＵＥ１０は、測定の結果に基づいて他の装置との相対関係を推定し、推定した相対関係に基づいてこの判断を行う。
例えば、相対関係を示す情報は、ＵＥ２０又はＲＳＵ５０から送信される信号の受信電力が閾値を超えるか否かを示す情報であってもよい。例えば、ＵＥ１０は、帯域のＲＳＳＩ（Received Signal Strength Indicator）、ＲＳＲＰ（Reference Signal Received Power）、ＲＳＲＱ（Reference Signal Received Quality）に基づいて、ＲＳＵ５０又はＵＥ２０との相対距離を推定して、Ｖ２Ｐ通信のアクティベート又はディアクティベートの必要有無を判断し得る。
例えば、相対関係を示す情報は、ＵＥ２０又はＲＳＵ５０から送信される信号に含まれる情報であってもよい。例えば、ＵＥ１０は、ディスカバリ信号又はブロードキャスト信号に含まれる送信元装置の識別情報（例えば、ＲＳＵ ＩＤ）に基づいてＲＳＵ５０の存在を知得して、Ｖ２Ｐ通信のアクティベート又はディアクティベートの必要有無を判断し得る。また、ＵＥ１０は、ディスカバリ信号又はブロードキャスト信号に含まれる、Ｖ２Ｐ通信が必要なエリアであるか否かを示すフラグ情報に基づいて、Ｖ２Ｐ通信のアクティベート又はディアクティベートの必要有無を判断し得る。
ＵＥ１０は、以上説明した情報を適宜組み合わせて判断を行ってもよい。その際、ＵＥ１０は、相対関係を、段階的に推定してもよい。例えば、ＵＥ１０は、受信電力が閾値を超えた場合にのみ、信号をデコードして信号に含まれる情報を取得してもよい。
続いて、具体的な判断基準の一例を説明する。
例えば、ＵＥ１０は、ＲＳＵ５０が所定距離以内に存在すると推定される場合に、Ｖ２Ｐ通信をアクティベートしてもよい。この判断基準により、道路付近でのＶ２Ｐ通信を用いた事故防止が可能となる。
逆に、ＵＥ１０は、ＲＳＵ５０が所定距離以内に存在しないと推定される場合に、Ｖ２Ｐ通信をアクティベートしてもよい。この判断基準により、付近にＲＳＵ５０が存在しないエリアでの自衛が可能となる。このエリアは、例えば上述した、都市部のスクランブル交差点のような歩行者が多いエリアであって、ＲＳＵ５０が設置されない交差点等が想定される。
（ｃ）制御
ＵＥ１０は、上述した判断の結果に従って、アクティベート処理又はディアクティベート処理を制御する。アクティベートする場合、ＵＥ１０は、アクティベートするＶ２Ｐ通信に関する通信パラメータを取得する。ＵＥ１０は、ネットワーク装置から通信パラメータを取得してもよいし、予め通信パラメータを記憶していてもよい。通信パラメータの内容は、上述した通りである。
例えば、上述した測定においてデコードした信号により通信パラメータが提供済みである場合、ＵＥ１０は、当該通信パラメータを利用してもよいし、新たに取得して通信パラメータを更新してもよい。
また、ＵＥ１０は、ｅＮＢ３０又はＲＳＵ５０に通信パラメータの問い合わせを行ってもよい。ｅＮＢ３０の場合、当該問い合わせはスケジューリングリクエストであってもよい。
また、ＵＥ１０は、ｅＮＢ３０又はＲＳＵ５０からブロードキャストされる信号から通信パラメータを取得してもよい。例えば、ｅＮＢ３０又はＲＳＵ５０は、ディスカバリ信号に通信パラメータを含めて送信してもよい。また、ＲＳＵ５０は、ローカルで使用している通信パラメータを定期的にブロードキャストしてもよい。
ここで、ＵＥ１０は、通信パラメータを段階的に取得してもよい。例えば、ＵＥ１０は、微弱ながら電力を検出した段階で事前に通信パラメータの取得を開始して、Ｖ２Ｐ通信がアクティベートされたときのための準備を行ってもよい。他にも、ＵＥ１０は、受信電力が閾値を超えた場合にのみ、通信パラメータを取得してもよい。
ＵＥ１０は、このようにして取得した通信パラメータを用いて、Ｖ２Ｐ通信をアクティベートする。
ＵＥ１０は、Ｖ２Ｐ通信を開始するに際して、アクティベートするＶ２Ｐ通信のためにＧＮＳＳ信号を用いて同期を獲得してもよい。その場合、ＵＥ１０は、同期関連情報を取得して、ＧＮＳＳ機能をアクティベートする。
ＵＥ１０は、Ｖ２Ｐ通信をアクティベートしたことをｅＮＢ３０又はＲＳＵ５０に報告してもよい。これにより、例えばｅＮＢ３０からのダウンリンクのマルチキャスト通信の対象ＩＤに、ＵＥ１０を含ませることが可能となる。
（２．２）処理の流れ
以下、図１８〜図２０を参照して、上述した測定、判断、及び制御の処理の流れを説明する。
図１８は、相対関係に応じたアクティベート処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＥ１０、Ｖｅｈｉｃｌｅ２０（即ち、ＵＥ２０）、及びｅＮＢ３０又はＲＳＵ５０が関与する。図１８に示すように、まず、ｅＮＢ３０又はＲＳＵ５０は、測定パラメータをＵＥ１０に通知する（ステップＳ２０２）。次いで、ＵＥ１０は、測定パラメータを用いて、ＵＥ２０、ｅＮＢ３０又はＲＳＵ５０から送信されるディスカバリ信号、同期信号又はブロードキャスト信号を測定する（ステップＳ２０４）。そして、ＵＥ１０は、測定結果に基づいて判断を行い（ステップＳ２０６）、判断結果をｅＮＢ３０又はＲＳＵ５０に通知する（ステップＳ２０８）。判断結果を通知されたｅＮＢ３０又はＲＳＵ５０は、当該判断結果に基づいて制御を行い（ステップＳ２１０）、通信パラメータをＵＥ１０に通知する（ステップＳ２１２）。そして、ＵＥ１０は、通信パラメータを用いてＶ２Ｐ通信をアクティベートして、Ｖ２Ｐ通信を開始する（ステップＳ２１６）。
図１９及び図２０は、段階的な通信パラメータの取得処理の流れの一例を示すフローチャートである。本フローは、ＵＥ１０により実行される。
図１９に示すように、まず、ＵＥ１０は、他の装置からの信号の受信電力を測定し（ステップＳ３０２）、受信電力が閾値以上であるかを判定する（ステップＳ３０４）。受信電力は閾値以上であると判定された場合（ステップＳ３０４／ＹＥＳ）、ＵＥ１０は、通信パラメータの事前取得を行い（ステップＳ３０６）、処理を終了する。一方で、受信電力は閾値以上でないと判定された場合（ステップＳ３０４／ＮＯ）、そのまま処理は終了する。
図２０に示すように、まず、ＵＥ１０は、他の装置からの信号の受信電力を測定し（ステップＳ４０２）、受信電力が閾値以上であるかを判定する（ステップＳ４０４）。受信電力は閾値以上であると判定された場合（ステップＳ４０４／ＹＥＳ）、ＵＥ１０は、当該信号の復号のための復号パラメータを取得して（ステップＳ４０６）、復号を行う（ステップＳ４０８）。この復号により、例えば通信パラメータが取得される。そして、ＵＥ１０は、Ｖ２Ｐ通信をアクティベートするか否かを判断する（ステップＳ４１０）。アクティベートすると判断された場合（ステップＳ４１０／ＹＥＳ）、ＵＥ１０は、Ｖ２Ｐ通信のアクティベート処理を制御して、Ｖ２Ｐ通信をアクティベートして（ステップＳ４１２）、処理を終了する。他方、他の装置からの信号の受信電力が閾値以上でないと判定された場合（ステップＳ４０４／ＮＯ）、及びＶ２Ｐ通信をアクティベートしないと判断された場合（ステップＳ４１０／ＮＯ）、そのまま処理は終了する。
（３）移動体への乗降に応じたアクティベート／ディアクティベート
場所に応じて取得される情報とは、ＵＥ１０を運搬する移動体への乗降に関する情報（以下、乗降情報とも称する）であってもよい。例えば、ＵＥ１０は、車、バス、タクシー又は路面電車等の移動体２２にユーザ１２が乗ったこと、即ち移動体２２により運搬されていることと検知された場合、Ｖ２Ｐ通信をディアクティベートしてもよい。また、ＵＥ１０は、移動体２２からユーザ１２が降りたこと、即ち移動体２２により運搬されていないことが検知された場合、Ｖ２Ｐ通信をアクティベートしてもよい。
（ａ）無線通信に基づく乗降情報
例えば、ＵＥ２０からの信号の受信電力又は受信信号に含まれる情報に基づいて、ＵＥ１０が移動体により運搬されているか、即ち乗降情報が取得され得る。なお、乗降情報の取得は、ＵＥ１０により行われてもよいし、ｅＮＢ３０又はＲＳＵ５０等のネットワーク装置により行われてもよい。
他にも、例えば、ＵＥ２０により形成されるムービングセルへのアタッチ手続き又はデタッチ手続きにより、乗降情報が取得され得る。例えば、ＵＥ１０によるアタッチ手続きが行われた場合、ＵＥ１０が移動体により運搬されていることを示す乗降情報が取得される。また、ＵＥ１０によるデタッチ手続きが行われた場合、ＵＥ１０が移動体により運搬されなくなったことを示す乗降情報が取得される。
（ｂ）近距離無線通信に基づく乗降情報
例えば、ＵＥ１０は、移動体２２との、より正確には移動体２２に設置されている近距離無線通信端末との通信、即ち接触の有無により乗降情報が取得されてもよい。近距離無線通信の方式としては、ＮＦＣ（Near Field Communication）、Ｂｌｕｅｔｏｏｔｈ、ＩｒＤＡ（Infrared Data Association）及びＺｉＢｅｅ（登録商標）等が挙げられる。そのような近距離無線通信端末としては、バスの乗車料金精算機、又は自家用車のキーレスエントリーシステム等が挙げられる。
（ｃ）位置情報のトラッキングに基づく乗降情報
例えば、ＵＥ１０の位置情報のトラッキング結果に基づいて、乗降情報が取得されてもよい。その際、ＵＥ１０が車道に位置するか否か、又は移動速度等が参照され得る。
＜＜４．第２の実施形態＞＞
本実施形態は、ＵＥ１０の通信機能がアクティベートされている状態において、受信タイミング又は送信タイミングの制御を行うことで、さらに電力消費を低減する形態である。
具体的には、ＵＥ１０はＵＥ２０又はＲＳＵ５０との間で、間欠的な通信を行う。送信側は、ＤＴＸ（Discontinuous Transmission）の仕組みを用いて間欠的な送信を行う。他方、受信側は、ＤＲＸ（Discontinuous Reception）の仕組みを用いて間欠的な受信を行う。ＵＥ１０が送信側となる場合、受信側となる場合の双方において、ＵＥ１０の通信機会が低減されるので、電力消費の低減が可能となる。
以下、ＵＥ１０が受信側としてＤＲＸを行う場合をまず説明し、その後ＵＥ１０が送信側としてＤＴＸを行う場合を説明する。また、以下では、ＵＥ１０による間欠的な通信の相手はＵＥ２０であるものとして説明する。
（１）ＤＲＸ
・概要
図２１は、典型的なＶ２Ｐ通信の送受信処理の一例を説明するための説明図である。図２１に示すように、移動体（Vehicle A、Vehicle B）は、典型的には各自の周期的なタイミングで通常メッセージ（DEFAULT MESSAGE）を送信する。Ｖ２Ｐ通信向けのメッセージは、Ｖ２Ｖ通信と比較して送信周期が長いものになる（例えば１Ｈｚ程度）と想定される。さらに、Ｖ２Ｐ通信においては、細かい送受信タイミングを集中制御する基地局が不在である場合も多く、自律分散的な通信が行われることが想定される。このような事情により、歩行者側（Pedestrian A）は、図２１に示すように常に受信スタンバイ状態（RECEPTION STANDBY）で待機して、移動体側から各々のタイミングで送信されるメッセージを受信していた。
本実施形態では、受信側はＤＲＸの仕組みを用いて、間欠的に受信スタンバイ状態となる。受信スタンバイ状態とは、信号の受信を行う状態である。逆に、信号の受信を行わない状態を、受信スリープ状態とも称する。もちろん、受信スリープ状態の方が受信スタンバイ状態よりも電力消費は少ない。間欠的にスタンバイ状態となる期間を、以下ではＤＲＸウィンドウとも称する。送信側は、ＤＲＸウィンドウのタイミングに合わせて、メッセージを送信する。
具体的には、ＵＥ１０は、ＤＲＸの仕組みを用いて、ＵＥ２０との間で間欠的な通信（即ち、受信）を行う。そのために、ＵＥ２０は、ＤＴＸの仕組みを用いて、ＵＥ１０の間欠的に通信可能になるタイミングに応じてＵＥ１０との通信（即ち、送信）を行う。ＵＥ１０が受信スタンバイ状態となるタイミングに合わせてＵＥ２０が送信を行うことで、ＵＥ１０は受信スタンバイ状態を短くすることが可能となり、それに伴いＵＥ１０の消費電力の低減が可能となる。
（ａ）パラメータ設定
・ＤＲＸパラメータ
ＵＥ１０は、ＤＲＸを用いた間欠的な受信を行うためのパラメータ（以下、ＤＲＸパラメータとも称する）を設定する。
ＤＲＸパラメータは、例えばＤＲＸ周期（DRX cycle）を含んでいてもよい。例えば、ＤＲＸウィンドウの期間と他の受信スリープ状態の期間との組み合わせにより、１周期が規定される。また、ＤＲＸ周期は、１周期の開始タイミング（例えば、フレーム番号等）を含んでいてもよい。
ＤＲＸパラメータは、オン期間（On duration）を含んでいてもよい。オン期間とは、ＤＲＸウィンドウの長さを示す情報である。同様に、ＤＲＸパラメータは、受信スリープ状態の期間の長さを示すオフ期間（Off duration）を含んでいてもよい。
ＤＲＸパラメータは、ＤＲＸエクステンション（DRX extension）を含んでいてもよい。ＤＲＸエクステンションとは、デフォルトのＤＲＸウィンドウからの延長分であってもよく、例えば±αで設定され得る。
ＤＲＸパラメータは、ＤＲＸリソースプール（DRX resource pool）を含んでいてもよい。ＤＲＸリソースプールとは、ＤＲＸを行う通信に利用されるリソースプールに関する情報である。
ＤＲＸパラメータは、ＤＲＸ周波数（DRX frequency）を含んでいてもよい。ＤＲＸ周波数とは、ＤＲＸに利用される周波数に関する情報である。これにより、マルチキャリアＶ２Ｐ通信の場合に、特定の周波数でのみＤＲＸを行う等の対応が可能となる。
ＤＲＸパラメータは、ＤＲＸグループ番号を含んでいてもよい。ＤＲＸグループ番号とは、ＤＲＸを行うひとつ以上の端末のグループの識別情報であって、ＵＥ１０自身が属するグループの識別情報である。ＤＲＸグループ番号により、ＵＥ１０は自身のグループを識別して、対応する事前設定情報を用いてもよい。ＤＲＸグループ番号は、端末情報に基づき設定されてもよい。例えば、ＤＲＸグループ番号は、ＲＮＴＩ（Radio Network Temporary Identifier） ｍｏｄ Ｘ、ＩＭＳＩ（International Mobile Subscriber Identity） ｍｏｄ Ｘ、又はＵＥカテゴリであってもよい。
ＤＲＸパラメータは、イベントトリガメッセージ等のための、イレギュラーなＤＲＸのためのパラメータを含んでいてもよい。そのようなパラメータとしては、開始フレーム番号（Start frame number）、開始サブフレーム番号（Start sub-frame number）、及びオン期間（On duration）等が挙げられる。
・ＤＲＸコンフィギュレーション
ＵＥ１０は、ＤＲＸパラメータを他の装置から取得して設定し得る。例えば、ＵＥ１０は、ｅＮＢ３０からシステム情報としてＳＩＢ（System Information Block）により提供されたＤＲＸパラメータを取得し得る。
ＤＲＸパラメータは、送受信されるメッセージタイプごとに設定されてもよい。メッセージタイプとしては、定期メッセージ（Periodical message）、及びイベントトリガメッセージ（Event trigger message）等が挙げられる。なお、イベントトリガメッセージに関しては、例えばオン期間を短く設定し、且つ周期性を増やして設定することが考えられる。その場合、低遅延が達成される。
ＤＲＸパラメータは、複数のＵＥ１０で共通していてもよいし、ＵＥ１０ごとに異なっていてもよい。例えば、ＤＲＸパラメータは、ＵＥ１０が属するグループ（即ち、ＤＲＸグループ）ごとに設定されてもよい。例えば、ＤＲＸグループごとにＤＲＸパラメータを相違させることで、特定のリソースが混雑することが回避される。
ＤＲＸパラメータは、ＵＥ１０の位置情報に応じて設定されてもよい。例えば、ＵＥ１０が特定のｅＮＢ３０又はＲＳＵ５０のカバレッジ内に位置するか否か、又は規定のエリアに内に位置するか否かに応じて、ＤＲＸパラメータが設定されてもよい。ＵＥ１０がｅＮＢ３０のカバレッジ外に位置する場合、ＵＥ１０は、予め記憶した事前設定情報からＤＲＸパラメータを取得してもよいし、ＤＲＸパラメータの設定自体を行わなくてもよい。また、ＤＲＸパラメータは、ＵＥ１０の速度情報を応じて設定されてもよい。
・送信側の設定
ＵＥ２０は、受信側のＤＲＸウィンドウに合わせて、少なくとも１回以上メッセージを送信する。ＵＥ２０による送信頻度とＵＥ１０による受信頻度とは一致していなくてもよい。具体的には、受信頻度は送信頻度と比較して少なくてもよい。例えば、ＵＥ２０は１０Ｈｚの頻度で定期メッセージを送信して、ＵＥ１０は１Ｈｚの頻度で受信してもよい。ＵＥ２０は、要求されたメッセージ頻度を最低限保てるように、ＵＥ１０のＤＲＸウィンドウ内でメッセージの送信を行うよう送信パラメータを設定する。
（ｂ）制御
ＵＥ２０は、受信側の受信タイミング（即ち、ＤＲＸウィンドウ）に合わせてメッセージを送信する。
この送信タイミングの制御には、３通りの方法が考えられる。第１に、ｅＮＢ３０が送信リソースを正確に決定する方法である。第２に、ｅＮＢ３０がリソースプールを決定し、その中から送信側が送信リソースを選択する方法である。第３に、送信側が、事前に設定されたリソースプールから送信リソースを選択する方法である。ＵＥ２０は、以上３通りの方法のうちいずれかの方法で特定された送信リソースを用いて、メッセージを送信する。
受信側のＤＲＸウィンドウに合わせるための制御方法には、送信タイミングの追加、送信タイミングの変更、及び繰り返し回数の分割が考えられる。
・送信タイミングの追加
ＵＥ２０は、ＵＥ１０の受信タイミングに応じた送信タイミングを追加してもよい。例えば、ＵＥ２０は、通常の周期的なメッセージ送信を保ちつつ、ＵＥ１０の受信タイミングに応じて追加的にメッセージ送信を行ってもよい。この追加されたタイミングで送信されるメッセージを、以下では追加メッセージとも称する。追加メッセージは、通常のメッセージの再送であってもよい。以下、図２２及び図２３を参照して詳しく説明する。
図２２は、送信タイミングが追加されるＶ２Ｐ通信の送受信処理の一例を説明するための説明図である。図２２に示すように、ＵＥ２０Ａ（Vehicle A）及びＵＥ２０Ｂ（Vehicle B）は、同一周期（１０フレーム（１００ｍｓ））でそれぞれ異なるタイミングで通常メッセージ（DEFAULT MESSAGE）を送信している。ＵＥ１０（Pedestrian A）のＤＲＸウィンドウは、１００フレーム（１ｓ）に一度の周期で設定されている。そして、ＵＥ２０Ａ及びＵＥ２０Ｂは、ＵＥ１０のＤＲＸウィンドウのタイミングで、追加メッセージ（ADDITIONAL MESSAGE）を送信している。
図２３は、送信タイミングが追加されるＶ２Ｐ通信の送受信処理の一例を説明するための説明図である。図２２に示すように、ＵＥ２０Ａ（Vehicle A）及びＵＥ２０Ｂ（Vehicle B）は、同一周期（１０フレーム（１００ｍｓ））でそれぞれ異なるタイミングで通常メッセージ（DEFAULT MESSAGE）を送信している。ＵＥ１０（Pedestrian A）のＤＲＸウィンドウは、２０フレームに一度の周期で設定されている。そして、ＵＥ２０Ａ及びＵＥ２０Ｂは、ＵＥ１０のＤＲＸウィンドウのタイミングで、かつ各々異なるタイミングで、追加メッセージ（ADDITIONAL MESSAGE）を送信している。
ＵＥ２０は、ｅＮＢ３０又はＲＳＵ５０等のネットワーク装置から、上述した追加メッセージのための送信リソース情報を取得してもよい。取得される送信リソース情報は、正確に決定された送信リソース情報であってもよいし、選択の幅を持たせたリソースプール情報であってもよい。いずれにしろ、ＵＥ２０は、追加メッセージのための時間リソース及び周波数リソースを示す情報を取得する。また、ＵＥ２０は、ＵＥ１０のＤＲＸウィンドウに関する情報を取得してもよい。
ＵＥ２０は、独力で追加メッセージのための送信リソース情報を取得してもよい。例えば、ＵＥ２０は、ＵＥ１０又はＵＥ２０の位置情報に基づいて、追加メッセージのための送信リソース情報を取得してもよい。また、ＵＥ２０は、キャリアセンスを行って空きを確認したリソースを、追加メッセージのための送信リソースとしてもよい。また、ＵＥ２０は、事前設定情報から追加メッセージのための送信リソース情報を取得してもよい。
ＵＥ２０は、このようにして取得した送信リソース情報に従って、追加メッセージを送信する。なお、追加メッセージのための送信リソースを以下では追加リソースとも称する。
例えば、ＵＥ２０は、追加リソースにおいて、同一のメッセージを複数回繰り返し送信してもよい。また、ＵＥ２０は、追加メッセージを、通常メッセージよりも低コードレートで送信してもよい。また、ＵＥ２０は、追加メッセージを、通常メッセージよりも高い送信電力で送信してもよい。これらの制御により、受信側でのエラーレートを改善することが可能である。
ここで、ＵＥ２０は、追加した送信タイミングに関する情報をサイドリンクで（例えば、ＵＥ１０に）通知することが望ましい。そのために、サイドリンクで送信される既存の制御信号（PSCCH：Physical Sidelink Control Channel）に新たなパラメータを追加する、又は新たな制御信号が規定されることが望ましい。このような制御信号において規定されるべきパラメータとしては、例えば同一のメッセージの繰り返し送信回数を示す情報、繰り返し送信におけるＲＶ（Redundancy version）情報、ＭＣＳ情報、及び送信電力情報が挙げられる。
・送信タイミングの変更
ＵＥ２０は、既存の送信タイミングを、ＵＥ１０の受信タイミングに応じて変更してもよい。例えば、ＵＥ２０は、通常の周期的なメッセージ送信のうち一部の送信タイミングを、ＵＥ１０の受信タイミングに応じて変更してもよい。この変更されたタイミングで送信されるメッセージを、以下では変更メッセージとも称する。以下、図２４及び図２５を参照して詳しく説明する。
図２４は、送信タイミングが変更されるＶ２Ｐ通信の送受信処理の一例を説明するための説明図である。図２４に示すように、ＵＥ２０Ａ（Vehicle A）及びＵＥ２０Ｂ（Vehicle B）は、同一周期（１０フレーム（１００ｍｓ））でそれぞれ異なるタイミングで通常メッセージ（DEFAULT MESSAGE）を送信している。ＵＥ１０（Pedestrian A）のＤＲＸウィンドウは、２０フレームに一度の周期で設定されている。そして、ＵＥ２０Ａ及びＵＥ２０Ｂは、ＵＥ１０のＤＲＸウィンドウのタイミングに合うように、自身の通常メッセージの送信タイミングを一部ずらして、変更メッセージ（MODIFIED MESSAGE）を送信している。
図２５は、送信タイミングが変更されるＶ２Ｐ通信の送受信処理の一例を説明するための説明図である。図２５に示すように、ＵＥ２０Ａ（Vehicle A）及びＵＥ２０Ｂ（Vehicle B）は、同一周期（１０フレーム（１００ｍｓ））でそれぞれ異なるタイミングで通常メッセージ（DEFAULT MESSAGE）を送信している。ＵＥ１０Ａ（Pedestrian A）及びＵＥ１０Ｂ（Pedestrian B）のＤＲＸウィンドウは、２０フレームに一度の周期で設定されている。そして、ＵＥ２０Ａ及びＵＥ２０Ｂは、ＵＥ１０Ａ又はＵＥ１０ＢのＤＲＸウィンドウのタイミングに合うように、自身の通常メッセージの送信タイミングを一部ずらして、変更メッセージ（MODIFIED MESSAGE）を送信している。
ここで、ＵＥ２０は、既存の通常メッセージの送信タイミングを変更するため、変更した送信タイミングに関する情報をサイドリンクで（例えば、ＵＥ１０に）通知することが望ましい。そのために、例えば制御信号が変更又は新たに規定され得る。これらの制御信号において、規定されるべきパラメータとしては、送信タイミングを変更するフレーム番号、時間方向のずれを示すオフセット値、及び周波数方向のずれを示すオフセット値等が挙げられる。なお、時間方向のずれを示すオフセット値は、フレーム又はサブフレームの開始点を基準としたオフセット値であってもよい。また、周波数方向のずれを示すオフセット値は、中心周波数を基準としたオフセット値であってもよい。その他、規定されるべきパラメータとしては、例えば同一のメッセージの繰り返し送信回数を示す情報、繰り返し送信におけるＲＶ情報、ＭＣＳ情報、及び送信電力情報が挙げられる。
・繰り返し回数の分割
ＵＥ２０は、既存の送信タイミングにおける同一メッセージの繰り返し送信の少なくとも一部を、ＵＥ１０の受信タイミングに応じて追加した送信タイミングにおいて行ってもよい。例えば、ＵＥ２０は、ＤＲＸが割り当てられているフレームにおいて行われていた、同一の通常メッセージの繰り返し送信回数を減らして、減らした分を追加した送信タイミングにおいて行う。Ｖ２Ｘ通信においては、典型的には、送信側は同一の通常メッセージを複数回繰り返して送信するものである。本制御方法は、この繰り返し回数を分割して、一部を既存の送信タイミングに残し、他の一部を追加する送信タイミングに移行するものである。
ここで、ＵＥ２０は、既存の送信タイミングにおける同一の通常メッセージの繰り返し送信回数を変更するため、繰り返し送信回数の変更に関する情報をサイドリンクで（例えば、ＵＥ１０に）通知することが望ましい。そのために、例えば制御信号が変更又は新たに規定され得る。これらの制御信号において、規定されるべきパラメータとしては、繰り返し回数分割指標、繰り返し回数更新情報、及びＲＶ情報等が挙げられる。なお、繰り返し回数分割指標とは、送信回数が分割されているか否かを示す情報である。繰り返し回数更新情報とは、既存の送信タイミングにおける繰り返し回数が何回減ったかを示す情報である。さらに、上述した追加した送信タイミングに関する情報も、制御信号に含まれることが望ましい。
（ｃ）処理の流れ
図２６は、ＤＲＸを用いたメッセージ送受信処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＥ１０、Ｖｅｈｉｃｌｅ２０（即ち、ＵＥ２０）、及びｅＮＢ３０又はＲＳＵ５０が関与する。図２６に示すように、まず、ｅＮＢ３０又はＲＳＵ５０は、ＤＲＸパラメータをＵＥ１０へ送信する（ステップＳ５０２）。次いで、ＵＥ１０は、受信したＤＲＸパラメータを設定して、間欠的に受信スタンバイ状態となる（ステップＳ５０４）。他方、ｅＮＢ３０又はＲＳＵ５０は、ＤＲＸウィンドウに応じた送信リソースを示す送信リソース情報をＵＥ２０へ送信する（ステップＳ５０６）。次に、ＵＥ２０は、送信リソース情報に基づいて送信タイミングを設定し（ステップＳ５０８）、設定した送信タイミングに関する情報を制御信号に含めて例えばＵＥ１０に通知する（ステップＳ５１０）。この制御信号には、追加若しくは変更した送信タイミングに関する情報、又は繰り返し送信回数の変更に関する情報が含まれる。次いで、ＵＥ２０は、送信リソース情報に基づいて、ＤＲＸウィンドウに応じたタイミングでメッセージを送信し（ステップＳ５１２）、ＵＥ１０は、ＤＲＸウィンドウにおいてメッセージを受信する（ステップＳ５１４）。
（２）ＤＴＸ
本実施形態では、送信側はＤＴＸの仕組みを用いて、間欠的に送信中状態となる。送信中状態とは、信号の送信を行っている状態である。逆に、信号の送信を行わない状態を、送信停止状態とも称する。もちろん、送信停止状態の方が送信中状態よりも電力消費は少ない。間欠的に送信中状態となる期間を、以下ではＤＴＸウィンドウとも称する。受信側は、ＤＴＸウィンドウのタイミングに合わせて、メッセージを受信する。
具体的には、ＵＥ１０は、ＤＴＸの仕組みを用いて、ＵＥ２０との間で間欠的な通信（即ち、送信）を行う。そのために、ＵＥ２０は、ＵＥ１０の間欠的に通信可能になるタイミングに応じてＵＥ１０との通信（即ち、受信）を行う。ＵＥ２０は、ＤＲＸの仕組みを用いてもよいし、常に受信スタンバイ状態で待機していてもよい。
ここで、送信メッセージが典型的には定期的に送信される定期メッセージであることを考慮すると、定期的にＤＴＸウィンドウが割り当てられることが望ましい。一方、イベントトリガメッセージに関しては、イレギュラーケースとしてＤＴＸウィンドウが割り当てられず、特に制約なく送信が行われてもよい。
（ａ）パラメータ設定
ＵＥ１０は、ＤＴＸを用いた間欠的な送信を行うためのパラメータ（以下、ＤＴＸパラメータとも称する）を設定する。
・ＤＴＸパラメータ
ＤＴＸパラメータは、例えばＤＴＸ周期（DTX cycle）を含んでいてもよい。例えば、ＤＴＸウィンドウの期間と他の送信停止状態の期間との組み合わせにより、１周期が規定される。また、ＤＴＸ周期は、１周期の開始タイミング（例えば、フレーム番号等）を含んでいてもよい。
ＤＴＸパラメータは、オン期間（On duration）を含んでいてもよい。オン期間とは、ＤＴＸウィンドウの長さを示す情報である。同様に、ＤＴＸパラメータは、送信停止状態の期間の長さを示すオフ期間（Off duration）を含んでいてもよい。
ＤＴＸパラメータは、ＤＴＸエクステンション（DTX extension）を含んでいてもよい。ＤＴＸエクステンションとは、デフォルトのＤＴＸウィンドウからの延長分であってもよく、例えば±αで設定され得る。
ＤＴＸパラメータは、ＤＴＸリソースプール（DTX resource pool）を含んでいてもよい。ＤＴＸリソースプールとは、ＤＴＸを行う通信に利用されるリソースプールに関する情報である。
ＤＴＸパラメータは、ＤＴＸ周波数（DTX frequency）を含んでいてもよい。ＤＴＸ周波数とは、ＤＴＸに利用される周波数に関する情報である。これにより、マルチキャリアＶ２Ｐ通信の場合に、特定の周波数でのみＤＴＸを行う等の対応が可能となる。
ＤＴＸパラメータは、ＤＴＸグループ番号を含んでいてもよい。ＤＴＸグループ番号とは、ＤＴＸを行うひとつ以上の端末のグループの識別情報であって、ＵＥ１０自身が属するグループの識別情報である。ＤＴＸグループ番号により、ＵＥ１０は自身のグループを識別して、対応する事前設定情報を用いてもよい。ＤＴＸグループ番号は、端末情報に基づき設定されてもよい。例えば、ＤＴＸグループ番号は、ＲＮＴＩ ｍｏｄ Ｘ、ＩＭＳＩ ｍｏｄ Ｘ、又はＵＥカテゴリであってもよい。
ＤＴＸパラメータは、イベントトリガメッセージ等のための、イレギュラーなＤＴＸのためのパラメータを含んでいてもよい。そのようなパラメータとしては、開始フレーム番号（Start frame number）、開始サブフレーム番号（Start sub-frame number）、及びオン期間（On duration）等が挙げられる。
・ＤＴＸコンフィギュレーション
ＵＥ１０は、ＤＴＸパラメータを他の装置から取得して設定し得る。例えば、ＵＥ１０は、ｅＮＢ３０からシステム情報としてＳＩＢにより提供されたＤＴＸパラメータを取得し得る。
ＤＴＸパラメータは、送受信されるメッセージタイプごとに設定されてもよい。メッセージタイプとしては、定期メッセージ、及びイベントトリガメッセージ等が挙げられる。なお、イベントトリガメッセージに関しては、例えばオン期間を短く設定し、且つ周期性を増やして設定することが考えられる。その場合、低遅延が達成される。
ＤＴＸパラメータは、複数のＵＥ１０で共通していてもよいし、ＵＥ１０ごとに異なっていてもよい。例えば、ＤＴＸパラメータは、ＵＥ１０が属するグループ（即ち、ＤＴＸグループ）ごとに設定されてもよい。例えば、ＤＴＸグループごとにＤＴＸパラメータを相違させることで、特定のリソースが混雑することが回避される。
ＤＴＸパラメータは、ＵＥ１０の位置情報に応じて設定されてもよい。例えば、ＵＥ１０が特定のｅＮＢ３０又はＲＳＵ５０のカバレッジ内に位置するか否か、又は規定のエリアに内に位置するか否かに応じて、ＤＴＸパラメータが設定されてもよい。ＵＥ１０がｅＮＢ３０のカバレッジ外に位置する場合、ＵＥ１０は、予め記憶した事前設定情報からＤＴＸパラメータを取得してもよいし、ＤＲＸパラメータの設定自体を行わなくてもよい。また、ＤＴＸパラメータは、ＵＥ１０の速度情報を応じて設定されてもよい。他にも、ＵＥ１０は、キャリアセンスを行って空きを確認したリソースを、ＤＴＸのための送信リソースとしてもよい。
・ＤＴＸパラメータのための事前情報
ＵＥ１０は、ＤＴＸパラメータを制御する他の装置（例えば、ＵＥ２０、ｅＮＢ３０、又はＲＳＵ５０）に、上述したＤＴＸパラメータをさせるための情報を通知してもよい。この情報を、以下では事前情報とも称する。
例えば、事前情報は、ＤＴＸグループ形成のためのＵＥ１０の情報を含んでいてもよい。具体的には、事前情報は、Ｖ２Ｘ通信に関するＢＳＲ（buffer status report）を含んでいてもよい。さらには、事前情報は、定期メッセージのバッファ量を示すＰｅｒｉｏｄｉｃａｌ ＢＳＲを含んでいてもよい。また、事前情報は、ＲＮＴＩ、ＩＭＳＩ、又はＵＥカテゴリ等の、ＵＥ１０に固有の情報を含んでいてもよい。また、事前情報は、一時的なＤＴＸ機会（ＤＴＸウィンドウサイズ又は頻度等）の増加を要求する、ＤＴＸ拡張リクエスト（DTX extension request）を含んでいてもよい。これにより、メッセージサイズが一時的に増加した場合に対応可能となる。
ｅＮＢ３０等は、このような事前情報に基づいてＤＴＸパラメータを各ＵＥ１０に割り当て得る。
（ｂ）処理の流れ
図２７は、ＤＴＸを用いたメッセージ送受信処理の流れの一例を示すシーケンス図である。本シーケンスには、ＵＥ１０、Ｖｅｈｉｃｌｅ２０（即ち、ＵＥ２０）、及びｅＮＢ３０又はＲＳＵ５０が関与する。図２７に示すように、まず、ＵＥ１０は、ＤＴＸパラメータのための事前情報をｅＮＢ３０又はＲＳＵ５０へ送信する（ステップＳ６０２）。次いで、事前情報を受信したｅＮＢ３０又はＲＳＵ５０は、事前情報に基づいてＤＴＸパラメータを生成し（ステップＳ６０４）、生成したＤＴＸパラメータをＵＥ１０へ通知する（ステップＳ６０６）。次に、ＵＥ１０は、受信したＤＴＸパラメータを設定して（ステップＳ６０８）、間欠的にメッセージを送信する（ステップＳ６１０）。そして、ＵＥ２０、ｅＮＢ３０又はＲＳＵ５０は、メッセージを受信する（ステップＳ６１２）。
＜＜５．応用例＞＞
本開示に係る技術は、様々な製品へ応用可能である。例えば、ｅＮＢ３０は、マクロｅＮＢ又はスモールｅＮＢなどのいずれかの種類のｅＮＢ（evolved Node B）として実現されてもよい。スモールｅＮＢは、ピコｅＮＢ、マイクロｅＮＢ又はホーム（フェムト）ｅＮＢなどの、マクロセルよりも小さいセルをカバーするｅＮＢであってよい。その代わりに、ｅＮＢ３０は、ＮｏｄｅＢ又はＢＴＳ（Base Transceiver Station）などの他の種類の基地局として実現されてもよい。ｅＮＢ３０は、無線通信を制御する本体（基地局装置ともいう）と、本体とは別の場所に配置される１つ以上のＲＲＨ（Remote Radio Head）とを含んでもよい。また、後述する様々な種類の端末が一時的に又は半永続的に基地局機能を実行することにより、ｅＮＢ３０として動作してもよい。さらに、ｅＮＢ３０の少なくとも一部の構成要素は、基地局装置又は基地局装置のためのモジュールにおいて実現されてもよい。
また、例えば、ＵＥ１０、ＵＥ２０又はＲＳＵ５０は、スマートフォン、タブレットＰＣ（Personal Computer）、ノートＰＣ、携帯型ゲーム端末、携帯型／ドングル型のモバイルルータ若しくはデジタルカメラなどのモバイル端末、又はカーナビゲーション装置などの車載端末として実現されてもよい。また、ＵＥ１０、ＵＥ２０又はＲＳＵ５０は、Ｍ２Ｍ（Machine To Machine）通信を行う端末（ＭＴＣ（Machine Type Communication）端末ともいう）として実現されてもよい。さらに、ＵＥ１０、ＵＥ２０又はＲＳＵ５０の少なくとも一部の構成要素は、これら端末に搭載されるモジュール（例えば、１つのダイで構成される集積回路モジュール）において実現されてもよい。
＜５．１．ｅＮＢに関する応用例＞
（第１の応用例）
図２８は、本開示に係る技術が適用され得るｅＮＢの概略的な構成の第１の例を示すブロック図である。ｅＮＢ８００は、１つ以上のアンテナ８１０、及び基地局装置８２０を有する。各アンテナ８１０及び基地局装置８２０は、ＲＦケーブルを介して互いに接続され得る。
アンテナ８１０の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、基地局装置８２０による無線信号の送受信のために使用される。ｅＮＢ８００は、図２８に示したように複数のアンテナ８１０を有し、複数のアンテナ８１０は、例えばｅＮＢ８００が使用する複数の周波数帯域にそれぞれ対応してもよい。なお、図２８にはｅＮＢ８００が複数のアンテナ８１０を有する例を示したが、ｅＮＢ８００は単一のアンテナ８１０を有してもよい。
基地局装置８２０は、コントローラ８２１、メモリ８２２、ネットワークインタフェース８２３及び無線通信インタフェース８２５を備える。
コントローラ８２１は、例えばＣＰＵ又はＤＳＰであってよく、基地局装置８２０の上位レイヤの様々な機能を動作させる。例えば、コントローラ８２１は、無線通信インタフェース８２５により処理された信号内のデータからデータパケットを生成し、生成したパケットをネットワークインタフェース８２３を介して転送する。コントローラ８２１は、複数のベースバンドプロセッサからのデータをバンドリングすることによりバンドルドパケットを生成し、生成したバンドルドパケットを転送してもよい。また、コントローラ８２１は、無線リソース管理（Radio Resource Control）、無線ベアラ制御（Radio Bearer Control）、移動性管理（Mobility Management）、流入制御（Admission Control）又はスケジューリング（Scheduling）などの制御を実行する論理的な機能を有してもよい。また、当該制御は、周辺のｅＮＢ又はコアネットワークノードと連携して実行されてもよい。メモリ８２２は、ＲＡＭ及びＲＯＭを含み、コントローラ８２１により実行されるプログラム、及び様々な制御データ（例えば、端末リスト、送信電力データ及びスケジューリングデータなど）を記憶する。
ネットワークインタフェース８２３は、基地局装置８２０をコアネットワーク８２４に接続するための通信インタフェースである。コントローラ８２１は、ネットワークインタフェース８２３を介して、コアネットワークノード又は他のｅＮＢと通信してもよい。その場合に、ｅＮＢ８００と、コアネットワークノード又は他のｅＮＢとは、論理的なインタフェース（例えば、Ｓ１インタフェース又はＸ２インタフェース）により互いに接続されてもよい。ネットワークインタフェース８２３は、有線通信インタフェースであってもよく、又は無線バックホールのための無線通信インタフェースであってもよい。ネットワークインタフェース８２３が無線通信インタフェースである場合、ネットワークインタフェース８２３は、無線通信インタフェース８２５により使用される周波数帯域よりもより高い周波数帯域を無線通信に使用してもよい。
無線通信インタフェース８２５は、ＬＴＥ（Long Term Evolution）又はＬＴＥ−Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、アンテナ８１０を介して、ｅＮＢ８００のセル内に位置する端末に無線接続を提供する。無線通信インタフェース８２５は、典型的には、ベースバンド（ＢＢ）プロセッサ８２６及びＲＦ回路８２７などを含み得る。ＢＢプロセッサ８２６は、例えば、符号化／復号、変調／復調及び多重化／逆多重化などを行なってよく、各レイヤ（例えば、Ｌ１、ＭＡＣ（Medium Access Control）、ＲＬＣ（Radio Link Control）及びＰＤＣＰ（Packet Data Convergence Protocol））の様々な信号処理を実行する。ＢＢプロセッサ８２６は、コントローラ８２１の代わりに、上述した論理的な機能の一部又は全部を有してもよい。ＢＢプロセッサ８２６は、通信制御プログラムを記憶するメモリ、当該プログラムを実行するプロセッサ及び関連する回路を含むモジュールであってもよく、ＢＢプロセッサ８２６の機能は、上記プログラムのアップデートにより変更可能であってもよい。また、上記モジュールは、基地局装置８２０のスロットに挿入されるカード若しくはブレードであってもよく、又は上記カード若しくは上記ブレードに搭載されるチップであってもよい。一方、ＲＦ回路８２７は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ８１０を介して無線信号を送受信する。
無線通信インタフェース８２５は、図２８に示したように複数のＢＢプロセッサ８２６を含み、複数のＢＢプロセッサ８２６は、例えばｅＮＢ８００が使用する複数の周波数帯域にそれぞれ対応してもよい。また、無線通信インタフェース８２５は、図２８に示したように複数のＲＦ回路８２７を含み、複数のＲＦ回路８２７は、例えば複数のアンテナ素子にそれぞれ対応してもよい。なお、図２８には無線通信インタフェース８２５が複数のＢＢプロセッサ８２６及び複数のＲＦ回路８２７を含む例を示したが、無線通信インタフェース８２５は単一のＢＢプロセッサ８２６又は単一のＲＦ回路８２７を含んでもよい。
図２８に示したｅＮＢ８００において、図１０を参照して説明した処理部３５０は、無線通信インタフェース８２５（例えば、ＢＢプロセッサ８２６）、又はコントローラ８２１において実装されてもよい。また、無線通信部３２０は、無線通信インタフェース８２５（例えば、ＲＦ回路８２７）において実装されてもよい。また、アンテナ部３１０は、アンテナ８１０において実装されてもよい。また、ネットワーク通信部３３０は、コントローラ８２１及び／又はネットワークインタフェース８２３において実装されてもよい。また、記憶部３４０は、メモリ８２２において実装されてもよい。
（第２の応用例）
図２９は、本開示に係る技術が適用され得るｅＮＢの概略的な構成の第２の例を示すブロック図である。ｅＮＢ８３０は、１つ以上のアンテナ８４０、基地局装置８５０、及びＲＲＨ８６０を有する。各アンテナ８４０及びＲＲＨ８６０は、ＲＦケーブルを介して互いに接続され得る。また、基地局装置８５０及びＲＲＨ８６０は、光ファイバケーブルなどの高速回線で互いに接続され得る。
アンテナ８４０の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、ＲＲＨ８６０による無線信号の送受信のために使用される。ｅＮＢ８３０は、図２９に示したように複数のアンテナ８４０を有し、複数のアンテナ８４０は、例えばｅＮＢ８３０が使用する複数の周波数帯域にそれぞれ対応してもよい。なお、図２９にはｅＮＢ８３０が複数のアンテナ８４０を有する例を示したが、ｅＮＢ８３０は単一のアンテナ８４０を有してもよい。
基地局装置８５０は、コントローラ８５１、メモリ８５２、ネットワークインタフェース８５３、無線通信インタフェース８５５及び接続インタフェース８５７を備える。コントローラ８５１、メモリ８５２及びネットワークインタフェース８５３は、図２８を参照して説明したコントローラ８２１、メモリ８２２及びネットワークインタフェース８２３と同様のものである。
無線通信インタフェース８５５は、ＬＴＥ又はＬＴＥ−Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、ＲＲＨ８６０及びアンテナ８４０を介して、ＲＲＨ８６０に対応するセクタ内に位置する端末に無線接続を提供する。無線通信インタフェース８５５は、典型的には、ＢＢプロセッサ８５６などを含み得る。ＢＢプロセッサ８５６は、接続インタフェース８５７を介してＲＲＨ８６０のＲＦ回路８６４と接続されることを除き、図２８を参照して説明したＢＢプロセッサ８２６と同様のものである。無線通信インタフェース８５５は、図２９に示したように複数のＢＢプロセッサ８５６を含み、複数のＢＢプロセッサ８５６は、例えばｅＮＢ８３０が使用する複数の周波数帯域にそれぞれ対応してもよい。なお、図２９には無線通信インタフェース８５５が複数のＢＢプロセッサ８５６を含む例を示したが、無線通信インタフェース８５５は単一のＢＢプロセッサ８５６を含んでもよい。
接続インタフェース８５７は、基地局装置８５０（無線通信インタフェース８５５）をＲＲＨ８６０と接続するためのインタフェースである。接続インタフェース８５７は、基地局装置８５０（無線通信インタフェース８５５）とＲＲＨ８６０とを接続する上記高速回線での通信のための通信モジュールであってもよい。
また、ＲＲＨ８６０は、接続インタフェース８６１及び無線通信インタフェース８６３を備える。
接続インタフェース８６１は、ＲＲＨ８６０（無線通信インタフェース８６３）を基地局装置８５０と接続するためのインタフェースである。接続インタフェース８６１は、上記高速回線での通信のための通信モジュールであってもよい。
無線通信インタフェース８６３は、アンテナ８４０を介して無線信号を送受信する。無線通信インタフェース８６３は、典型的には、ＲＦ回路８６４などを含み得る。ＲＦ回路８６４は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ８４０を介して無線信号を送受信する。無線通信インタフェース８６３は、図２９に示したように複数のＲＦ回路８６４を含み、複数のＲＦ回路８６４は、例えば複数のアンテナ素子にそれぞれ対応してもよい。なお、図２９には無線通信インタフェース８６３が複数のＲＦ回路８６４を含む例を示したが、無線通信インタフェース８６３は単一のＲＦ回路８６４を含んでもよい。
図２９に示したｅＮＢ８３０において、図１０を参照して説明した処理部３５０は、無線通信インタフェース８５５、無線通信インタフェース８６３及び／又はコントローラ８５１において実装されてもよい。また、無線通信部３２０は、無線通信インタフェース８６３（例えば、ＲＦ回路８６４）において実装されてもよい。また、アンテナ部３１０は、アンテナ８４０において実装されてもよい。また、ネットワーク通信部３３０は、コントローラ８５１及び／又はネットワークインタフェース８５３において実装されてもよい。また、記憶部３４０は、メモリ８５２において実装されてもよい。
＜５．２．ＵＥ及びＲＳＵに関する応用例＞
（第１の応用例）
図３０は、本開示に係る技術が適用され得るスマートフォン９００の概略的な構成の一例を示すブロック図である。スマートフォン９００は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１２、１つ以上のアンテナスイッチ９１５、１つ以上のアンテナ９１６、バス９１７、バッテリー９１８及び補助コントローラ９１９を備える。
プロセッサ９０１は、例えばＣＰＵ又はＳｏＣ（System on Chip）であってよく、スマートフォン９００のアプリケーションレイヤ及びその他のレイヤの機能を制御する。メモリ９０２は、ＲＡＭ及びＲＯＭを含み、プロセッサ９０１により実行されるプログラム及びデータを記憶する。ストレージ９０３は、半導体メモリ又はハードディスクなどの記憶媒体を含み得る。外部接続インタフェース９０４は、メモリーカード又はＵＳＢ（Universal Serial Bus）デバイスなどの外付けデバイスをスマートフォン９００へ接続するためのインタフェースである。
カメラ９０６は、例えば、ＣＣＤ（Charge Coupled Device）又はＣＭＯＳ（Complementary Metal Oxide Semiconductor）などの撮像素子を有し、撮像画像を生成する。センサ９０７は、例えば、測位センサ、ジャイロセンサ、地磁気センサ及び加速度センサなどのセンサ群を含み得る。マイクロフォン９０８は、スマートフォン９００へ入力される音声を音声信号へ変換する。入力デバイス９０９は、例えば、表示デバイス９１０の画面上へのタッチを検出するタッチセンサ、キーパッド、キーボード、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス９１０は、液晶ディスプレイ（ＬＣＤ）又は有機発光ダイオード（ＯＬＥＤ）ディスプレイなどの画面を有し、スマートフォン９００の出力画像を表示する。スピーカ９１１は、スマートフォン９００から出力される音声信号を音声に変換する。
無線通信インタフェース９１２は、ＬＴＥ又はＬＴＥ−Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、無線通信を実行する。無線通信インタフェース９１２は、典型的には、ＢＢプロセッサ９１３及びＲＦ回路９１４などを含み得る。ＢＢプロセッサ９１３は、例えば、符号化／復号、変調／復調及び多重化／逆多重化などを行なってよく、無線通信のための様々な信号処理を実行する。一方、ＲＦ回路９１４は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ９１６を介して無線信号を送受信する。無線通信インタフェース９１２は、ＢＢプロセッサ９１３及びＲＦ回路９１４を集積したワンチップのモジュールであってもよい。無線通信インタフェース９１２は、図３０に示したように複数のＢＢプロセッサ９１３及び複数のＲＦ回路９１４を含んでもよい。なお、図３０には無線通信インタフェース９１２が複数のＢＢプロセッサ９１３及び複数のＲＦ回路９１４を含む例を示したが、無線通信インタフェース９１２は単一のＢＢプロセッサ９１３又は単一のＲＦ回路９１４を含んでもよい。
さらに、無線通信インタフェース９１２は、セルラー通信方式に加えて、近距離無線通信方式、近接無線通信方式又は無線ＬＡＮ（Local Area Network）方式などの他の種類の無線通信方式をサポートしてもよく、その場合に、無線通信方式ごとのＢＢプロセッサ９１３及びＲＦ回路９１４を含んでもよい。
アンテナスイッチ９１５の各々は、無線通信インタフェース９１２に含まれる複数の回路（例えば、異なる無線通信方式のための回路）の間でアンテナ９１６の接続先を切り替える。
アンテナ９１６の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、無線通信インタフェース９１２による無線信号の送受信のために使用される。スマートフォン９００は、図３０に示したように複数のアンテナ９１６を有してもよい。なお、図３０にはスマートフォン９００が複数のアンテナ９１６を有する例を示したが、スマートフォン９００は単一のアンテナ９１６を有してもよい。
さらに、スマートフォン９００は、無線通信方式ごとにアンテナ９１６を備えてもよい。その場合に、アンテナスイッチ９１５は、スマートフォン９００の構成から省略されてもよい。
バス９１７は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１２及び補助コントローラ９１９を互いに接続する。バッテリー９１８は、図中に破線で部分的に示した給電ラインを介して、図３０に示したスマートフォン９００の各ブロックへ電力を供給する。補助コントローラ９１９は、例えば、スリープモードにおいて、スマートフォン９００の必要最低限の機能を動作させる。
図３０に示したスマートフォン９００において、図８を参照して説明した処理部１５０、図９を参照して説明した処理部２５０、又は図１１を参照して説明した処理部５４０は、無線通信インタフェース９１２又はプロセッサ９０１において実装されてもよい。また、無線通信部１２０、無線通信部２２０、又は無線通信部５２０は、無線通信インタフェース９１２（例えば、ＲＦ回路９１４）において実装されてもよい。また、ＧＮＳＳ信号処理部１３０又はＧＮＳＳ信号処理部２３０は、センサ９０７において実装されてもよい。また、アンテナ部１１０、アンテナ部２１０又はアンテナ部５１０は、アンテナ９１６において実装されてもよい。また、記憶部１４０、記憶部２４０又は記憶部５３０は、メモリ９０２において実装されてもよい。
（第２の応用例）
図３１は、本開示に係る技術が適用され得るカーナビゲーション装置９２０の概略的な構成の一例を示すブロック図である。カーナビゲーション装置９２０は、プロセッサ９２１、メモリ９２２、ＧＰＳ（Global Positioning System）モジュール９２４、センサ９２５、データインタフェース９２６、コンテンツプレーヤ９２７、記憶媒体インタフェース９２８、入力デバイス９２９、表示デバイス９３０、スピーカ９３１、無線通信インタフェース９３３、１つ以上のアンテナスイッチ９３６、１つ以上のアンテナ９３７及びバッテリー９３８を備える。
プロセッサ９２１は、例えばＣＰＵ又はＳｏＣであってよく、カーナビゲーション装置９２０のナビゲーション機能及びその他の機能を制御する。メモリ９２２は、ＲＡＭ及びＲＯＭを含み、プロセッサ９２１により実行されるプログラム及びデータを記憶する。
ＧＰＳモジュール９２４は、ＧＰＳ衛星から受信されるＧＰＳ信号を用いて、カーナビゲーション装置９２０の位置（例えば、緯度、経度及び高度）を測定する。センサ９２５は、例えば、ジャイロセンサ、地磁気センサ及び気圧センサなどのセンサ群を含み得る。データインタフェース９２６は、例えば、図示しない端子を介して車載ネットワーク９４１に接続され、車速データなどの車両側で生成されるデータを取得する。
コンテンツプレーヤ９２７は、記憶媒体インタフェース９２８に挿入される記憶媒体（例えば、ＣＤ又はＤＶＤ）に記憶されているコンテンツを再生する。入力デバイス９２９は、例えば、表示デバイス９３０の画面上へのタッチを検出するタッチセンサ、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス９３０は、ＬＣＤ又はＯＬＥＤディスプレイなどの画面を有し、ナビゲーション機能又は再生されるコンテンツの画像を表示する。スピーカ９３１は、ナビゲーション機能又は再生されるコンテンツの音声を出力する。
無線通信インタフェース９３３は、ＬＴＥ又はＬＴＥ−Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、無線通信を実行する。無線通信インタフェース９３３は、典型的には、ＢＢプロセッサ９３４及びＲＦ回路９３５などを含み得る。ＢＢプロセッサ９３４は、例えば、符号化／復号、変調／復調及び多重化／逆多重化などを行なってよく、無線通信のための様々な信号処理を実行する。一方、ＲＦ回路９３５は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ９３７を介して無線信号を送受信する。無線通信インタフェース９３３は、ＢＢプロセッサ９３４及びＲＦ回路９３５を集積したワンチップのモジュールであってもよい。無線通信インタフェース９３３は、図３１に示したように複数のＢＢプロセッサ９３４及び複数のＲＦ回路９３５を含んでもよい。なお、図３１には無線通信インタフェース９３３が複数のＢＢプロセッサ９３４及び複数のＲＦ回路９３５を含む例を示したが、無線通信インタフェース９３３は単一のＢＢプロセッサ９３４又は単一のＲＦ回路９３５を含んでもよい。
さらに、無線通信インタフェース９３３は、セルラー通信方式に加えて、近距離無線通信方式、近接無線通信方式又は無線ＬＡＮ方式などの他の種類の無線通信方式をサポートしてもよく、その場合に、無線通信方式ごとのＢＢプロセッサ９３４及びＲＦ回路９３５を含んでもよい。
アンテナスイッチ９３６の各々は、無線通信インタフェース９３３に含まれる複数の回路（例えば、異なる無線通信方式のための回路）の間でアンテナ９３７の接続先を切り替える。
アンテナ９３７の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、無線通信インタフェース９３３による無線信号の送受信のために使用される。カーナビゲーション装置９２０は、図３１に示したように複数のアンテナ９３７を有してもよい。なお、図３１にはカーナビゲーション装置９２０が複数のアンテナ９３７を有する例を示したが、カーナビゲーション装置９２０は単一のアンテナ９３７を有してもよい。
さらに、カーナビゲーション装置９２０は、無線通信方式ごとにアンテナ９３７を備えてもよい。その場合に、アンテナスイッチ９３６は、カーナビゲーション装置９２０の構成から省略されてもよい。
バッテリー９３８は、図中に破線で部分的に示した給電ラインを介して、図３１に示したカーナビゲーション装置９２０の各ブロックへ電力を供給する。また、バッテリー９３８は、車両側から給電される電力を蓄積する。
図３１に示したカーナビゲーション装置９２０において、図８を参照して説明した処理部１５０、図９を参照して説明した処理部２５０、又は図１１を参照して説明した処理部５４０は、無線通信インタフェース９３３又はプロセッサ９２１において実装されてもよい。また、無線通信部１２０、無線通信部２２０、又は無線通信部５２０は、無線通信インタフェース９３３（例えば、ＲＦ回路９３５）において実装されてもよい。また、ＧＮＳＳ信号処理部１３０又はＧＮＳＳ信号処理部２３０は、ＧＰＳモジュール９２４において実装されてもよい。また、アンテナ部１１０、アンテナ部２１０又はアンテナ部５１０は、アンテナ９３７において実装されてもよい。また、記憶部１４０、記憶部２４０又は記憶部５３０は、メモリ９２２において実装されてもよい。
また、本開示に係る技術は、上述したカーナビゲーション装置９２０の１つ以上のブロックと、車載ネットワーク９４１と、車両側モジュール９４２とを含む車載システム（又は車両）９４０として実現されてもよい。即ち、図９を参照して説明した処理部２５０を備える装置として車載システム（又は車両）９４０が提供されてもよい。車両側モジュール９４２は、車速、エンジン回転数又は故障情報などの車両側データを生成し、生成したデータを車載ネットワーク９４１へ出力する。
＜＜６．まとめ＞＞
以上、図１〜図３１を参照して、本開示の一実施形態について詳細に説明した。
第１の実施形態によれば、ＵＥ１０は、移動体（即ち、ＵＥ２０）、ＲＳＵ５０又はｅＮＢ３０との通信を行い、場所に応じて取得される情報に基づいて通信機能をアクティベート又はディアクティベートする。これにより、通信機能をアクティベートする期間を必要最低限にすることが可能となり、それに伴い電力消費を低減することが可能となる。
第２の実施形態によれば、ＵＥ１０は、移動体（即ち、ＵＥ２０）、ＲＳＵ５０又はｅＮＢ３０との通信を行い、ＵＥ２０又はＲＳＵ５０との間欠的な通信のためのパラメータを設定する。ＵＥ１０は、間欠的に通信を行うことで、通信機能がアクティベートされている状態において、さらに電力消費を低減することが可能である。
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
また、本明細書においてフローチャート及びシーケンス図を用いて説明した処理は、必ずしも図示された順序で実行されなくてもよい。いくつかの処理ステップは、並列的に実行されてもよい。また、追加的な処理ステップが採用されてもよく、一部の処理ステップが省略されてもよい。
また、本明細書の装置（例えば、ＵＥ１０、ＵＥ２０、ｅＮＢ３０又はＲＳＵ５０、又はこれらの装置のためのモジュール）に備えられるプロセッサ（例えば、ＣＰＵ、ＤＳＰなど）を上記装置の構成要素（例えば、処理部１５０、処理部２５０、処理部３５０又は処理部５４０など）として機能させるためのコンピュータプログラム（換言すると、上記プロセッサに上記装置の構成要素の動作を実行させるためのコンピュータプログラム）も作成可能である。また、当該コンピュータプログラムを記録した記録媒体も提供されてもよい。また、上記コンピュータプログラムを記憶するメモリと、上記コンピュータプログラムを実行可能な１つ以上のプロセッサとを備える装置（例えば、基地局、基地局装置若しくは基地局装置のためのモジュール、又は、端末装置若しくは端末装置のためのモジュール）も提供されてもよい。また、上記装置の構成要素の動作を含む方法も、本開示に係る技術に含まれる。
また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。
なお、以下のような構成も本開示の技術的範囲に属する。
（１）
移動体、ＲＳＵ（Road Side Unit）又は基地局との通信を行う通信部と、
移動体又はＲＳＵとの間欠的な通信のためのパラメータを設定する処理部と、
を備えるユーザ端末。
（２）
前記パラメータは、通信に利用されるリソースプールに関する情報を含む、前記（１）に記載のユーザ端末。
（３）
前記パラメータは、通信に利用される周波数に関する情報を含む、前記（１）又は（２）に記載のユーザ端末。
（４）
前記パラメータは、前記ユーザ端末が属するグループの識別情報を含む、前記（１）〜（３）のいずれか一項に記載のユーザ端末。
（５）
前記パラメータは、送受信されるメッセージタイプごとに設定される、前記（１）〜（４）のいずれか一項に記載のユーザ端末。
（６）
前記パラメータは、前記ユーザ端末が属するグループごとに設定される、前記（１）〜（５）のいずれか一項に記載のユーザ端末。
（７）
前記処理部は、前記パラメータを他の装置から取得する、前記（１）〜（６）のいずれか一項に記載のユーザ端末。
（８）
前記処理部は、前記他の装置に前記パラメータを生成させるための情報を通知する、前記（７）に記載のユーザ端末。
（９）
前記パラメータを生成させるための情報は、バッファステータスレポートを含む、前記（８）に記載のユーザ端末。
（１０）
前記パラメータを生成させるための情報は、前記ユーザ端末に固有の情報を含む、前記（８）又は（９）に記載のユーザ端末。
（１１）
前記移動体又はＲＳＵとの間欠的な通信は、前記移動体又はＲＳＵへの間欠的な送信又は前記移動体又はＲＳＵからの間欠的な受信である、前記（１）〜（１０）のいずれか一項に記載のユーザ端末。
（１２）
移動体に搭載される通信装置であって、
ユーザ端末の間欠的に通信可能になるタイミングに応じて前記ユーザ端末との通信を行う処理部、
を備える通信装置。
（１３）
前記処理部は、前記ユーザ端末の受信タイミングに応じた送信タイミングを追加する、前記（１２）に記載の通信装置。
（１４）
前記処理部は、追加した送信タイミングに関する情報を前記ユーザ端末に通知する、前記（１３）に記載の通信装置。
（１５）
前記処理部は、既存の送信タイミングを前記ユーザ端末の受信タイミングに応じて変更する、前記（１２）〜（１４）のいずれか一項に記載の通信装置。
（１６）
前記処理部は、変更した送信タイミングに関する情報を前記ユーザ端末に通知する、前記（１５）に記載の通信装置。
（１７）
前記処理部は、既存の送信タイミングにおける同一メッセージの繰り返し送信の少なくとも一部を、前記ユーザ端末の受信タイミングに応じて追加した送信タイミングにおいて行う、前記（１２）〜（１６）のいずれか一項に記載の通信装置。
（１８）
前記処理部は、既存の送信タイミングにおける同一メッセージの繰り返し送信回数の変更に関する情報を前記ユーザ端末に通知する、前記（１７）に記載の通信装置。
（１９）
移動体、ＲＳＵ又は基地局との通信を行うことと、
移動体又はＲＳＵとの間欠的な通信のためのパラメータをプロセッサにより設定することと、
を含む方法。
（２０）
ユーザ端末の間欠的に通信可能になるタイミングに応じて、移動体に搭載される通信装置により前記ユーザ端末との通信を行うこと、
を含む方法。
１０ ＵＥ
１２ ユーザ
２０ ＵＥ
２２ 移動体
３０ ｅＮＢ
４０ ＧＮＳＳ衛星
５０ ＲＳＵ
１１０ アンテナ部
１２０ 無線通信部
１３０ ＧＮＳＳ信号処理部
１４０ 記憶部
１５０ 処理部
２１０ アンテナ部
２２０ 無線通信部
２３０ ＧＮＳＳ信号処理部
２４０ 記憶部
２５０ 処理部
３１０ アンテナ部
３２０ 無線通信部
３３０ ネットワーク通信部
３４０ 記憶部
３５０ 処理部
５１０ アンテナ部
５２０ 無線通信部
５３０ 記憶部
５４０ 処理部

Claims (18)

  1. 移動体、ＲＳＵ（Road Side Unit）又は基地局との通信を行う通信部と、
    移動体又はＲＳＵとの間欠的な通信のためのパラメータを設定する処理部と、
    を備え、
    前記パラメータは、送受信されるメッセージタイプごとに設定される、ユーザ端末。
  2. 前記パラメータは、通信に利用されるリソースプールに関する情報を含む、請求項１に記載のユーザ端末。
  3. 前記パラメータは、通信に利用される周波数に関する情報を含む、請求項１に記載のユーザ端末。
  4. 前記パラメータは、前記ユーザ端末が属するグループの識別情報を含む、請求項１に記載のユーザ端末。
  5. 前記パラメータは、前記ユーザ端末が属するグループごとに設定される、請求項１に記載のユーザ端末。
  6. 前記処理部は、前記パラメータを他の装置から取得する、請求項１に記載のユーザ端末。
  7. 前記処理部は、前記他の装置に前記パラメータを生成させるための情報を通知する、請求項６に記載のユーザ端末。
  8. 前記パラメータを生成させるための情報は、バッファステータスレポートを含む、請求項７に記載のユーザ端末。
  9. 前記パラメータを生成させるための情報は、前記ユーザ端末に固有の情報を含む、請求項７に記載のユーザ端末。
  10. 前記移動体又はＲＳＵとの間欠的な通信は、前記移動体又はＲＳＵへの間欠的な送信又は前記移動体又はＲＳＵからの間欠的な受信である、請求項１に記載のユーザ端末。
  11. 移動体に搭載される通信装置であって、
    ユーザ端末の間欠的に通信可能になるタイミングに応じて前記ユーザ端末との通信を行う処理部を備え、
    前記処理部は、既存の送信タイミングにおける同一メッセージの繰り返し送信の少なくとも一部を、前記ユーザ端末の受信タイミングに応じて追加した送信タイミングにおいて行う、通信装置。
  12. 前記処理部は、前記ユーザ端末の受信タイミングに応じた送信タイミングを追加する、請求項１１に記載の通信装置。
  13. 前記処理部は、追加した送信タイミングに関する情報を前記ユーザ端末に通知する、請求項１２に記載の通信装置。
  14. 前記処理部は、既存の送信タイミングを前記ユーザ端末の受信タイミングに応じて変更する、請求項１１に記載の通信装置。
  15. 前記処理部は、変更した送信タイミングに関する情報を前記ユーザ端末に通知する、請求項１４に記載の通信装置。
  16. 前記処理部は、既存の送信タイミングにおける同一メッセージの繰り返し送信回数の変更に関する情報を前記ユーザ端末に通知する、請求項１１に記載の通信装置。
  17. ユーザ端末のプロセッサが、
    移動体、ＲＳＵ又は基地局との通信を行うことと、
    移動体又はＲＳＵとの間欠的な通信のためのパラメータであって、送受信されるメッセージタイプごとに設定されるパラメータを設定することと、
    を含む方法。
  18. ユーザ端末の間欠的に通信可能になるタイミングに応じて、移動体に搭載される通信装置により前記ユーザ端末との通信を行うことと、
    既存の送信タイミングにおける同一メッセージの繰り返し送信回数の変更に関する情報を前記ユーザ端末に通知することと、
    を含む方法。
JP2016020142A 2016-02-04 2016-02-04 ユーザ端末、通信装置及び方法 Active JP6623802B2 (ja)

Priority Applications (13)

Application Number Priority Date Filing Date Title
JP2016020142A JP6623802B2 (ja) 2016-02-04 2016-02-04 ユーザ端末、通信装置及び方法
SG11201804837PA SG11201804837PA (en) 2016-02-04 2017-01-18 Electronic devices and method for direct communication
PCT/JP2017/001611 WO2017135036A1 (en) 2016-02-04 2017-01-18 Electronic devices and method for direct communication
US15/766,654 US10568029B2 (en) 2016-02-04 2017-01-18 Method and device for D2D communication
MX2018009198A MX2018009198A (es) 2016-02-04 2017-01-18 Terminal de usuario, dispositivo de comunicacion y metodo.
EP17703480.8A EP3412109B1 (en) 2016-02-04 2017-01-18 Electronic device and method for direct communication
RU2018127198A RU2732994C2 (ru) 2016-02-04 2017-01-18 Абонентский терминал, устройство связи и способ связи
ES17703480T ES2930438T3 (es) 2016-02-04 2017-01-18 Dispositivo electrónico y método para una comunicación directa
TW106102452A TWI752936B (zh) 2016-02-04 2017-01-23 使用者終端、通訊裝置及方法
ZA2018/03066A ZA201803066B (en) 2016-02-04 2018-05-10 Electronic devices and method for direct communication
US16/784,244 US11272448B2 (en) 2016-02-04 2020-02-07 Method and device for D2D communication
US17/685,382 US11683754B2 (en) 2016-02-04 2022-03-03 Method and device for sidelink communication based on parameters
US18/198,285 US20230292239A1 (en) 2016-02-04 2023-05-17 Method and device for sidelink communication based on parameters

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2016020142A JP6623802B2 (ja) 2016-02-04 2016-02-04 ユーザ端末、通信装置及び方法

Publications (2)

Publication Number Publication Date
JP2017139659A JP2017139659A (ja) 2017-08-10
JP6623802B2 true JP6623802B2 (ja) 2019-12-25

Family

ID=57966065

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016020142A Active JP6623802B2 (ja) 2016-02-04 2016-02-04 ユーザ端末、通信装置及び方法

Country Status (10)

Country Link
US (4) US10568029B2 (ja)
EP (1) EP3412109B1 (ja)
JP (1) JP6623802B2 (ja)
ES (1) ES2930438T3 (ja)
MX (1) MX2018009198A (ja)
RU (1) RU2732994C2 (ja)
SG (1) SG11201804837PA (ja)
TW (1) TWI752936B (ja)
WO (1) WO2017135036A1 (ja)
ZA (1) ZA201803066B (ja)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6623802B2 (ja) 2016-02-04 2019-12-25 ソニー株式会社 ユーザ端末、通信装置及び方法
US20190141602A1 (en) * 2016-06-29 2019-05-09 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Communication method, forwarding device, and terminal device
TWI622025B (zh) * 2017-05-24 2018-04-21 財團法人工業技術研究院 弱勢用路人的訊息傳輸方法及其行動裝置與系統
KR102367053B1 (ko) * 2017-07-13 2022-02-24 삼성전자주식회사 외부 전자 장치와 통신을 수행하기 위한 전자 장치
US11212653B2 (en) 2017-08-29 2021-12-28 Panasonic Corporation Terminal device, roadside device, communications system, and communications method
WO2019044007A1 (ja) * 2017-08-29 2019-03-07 パナソニック株式会社 端末装置、路側装置、通信システム、および通信方法
EP3691361A4 (en) 2017-09-27 2021-03-10 Sony Corporation COMMUNICATION DEVICE
WO2019064986A1 (ja) 2017-09-29 2019-04-04 ソニー株式会社 通信装置及び通信方法
RU2020130778A (ru) 2018-03-27 2022-03-17 Сони Корпорейшн Оконечное устройство, способ и носитель записи
EP3797550A4 (en) * 2018-05-21 2022-01-19 Nokia Technologies Oy AUTOMATIC HYBRID REPEAT REQUEST IN OFF-LAND NETWORKS
WO2019239881A1 (ja) * 2018-06-11 2019-12-19 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 送信方法、および送信装置
US20210344454A1 (en) * 2018-09-28 2021-11-04 Lg Electronics Inc. Method and device for determining dtx on basis of reference signal in nr v2x
US10750556B2 (en) * 2018-12-11 2020-08-18 Shimano Inc. Wireless communication device and operating system
CN113016218A (zh) * 2019-01-04 2021-06-22 株式会社Ntt都科摩 无线通信方法及设备
US11452043B2 (en) * 2019-06-24 2022-09-20 Qualcomm Incorporated Power enhancement techniques for vehicle-to-pedestrian wireless communication systems
DE102019209988A1 (de) * 2019-07-08 2021-01-14 Robert Bosch Gmbh Verfahren zum Kommunizieren mit einem Verkehrsteilnehmer
CN110889978A (zh) * 2019-11-25 2020-03-17 东风商用车有限公司 一种自动驾驶交通环境下的道路工作人员安全增强系统
EP4108041A1 (en) * 2020-02-21 2022-12-28 Qualcomm Incorporated Discontinuous transmission and discontinuous reception configurations for sidelink communications
EP4085709A4 (en) * 2020-03-18 2023-04-12 ZTE Corporation METHOD AND DEVICE FOR SAVING ENERGY IN WIRELESS SIDE LINK COMMUNICATION
WO2021205628A1 (ja) * 2020-04-09 2021-10-14 富士通株式会社 無線通信装置、無線通信システム及び電力制御方法
WO2021205627A1 (ja) * 2020-04-09 2021-10-14 富士通株式会社 無線通信装置、無線通信システム及び電力制御方法
US11564071B2 (en) * 2020-06-12 2023-01-24 Qualcomm Incorporated Techniques for vehicle based wireless communications
JP7364539B2 (ja) 2020-08-03 2023-10-18 本田技研工業株式会社 ネットワーク管理装置、ネットワーク管理方法、及びプログラム
JP7406003B2 (ja) 2020-10-06 2023-12-26 京セラ株式会社 通信制御方法、ユーザ装置及びプロセッサ
WO2022074805A1 (ja) * 2020-10-08 2022-04-14 富士通株式会社 無線通信装置、無線通信システム及び電力制御方法
CN218547006U (zh) * 2022-08-11 2023-02-28 中兴通讯股份有限公司 追踪器
WO2024053055A1 (ja) * 2022-09-08 2024-03-14 本田技研工業株式会社 端末装置及び通信制御方法

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0884111A (ja) * 1994-09-09 1996-03-26 Canon Inc 無線システム
WO2008107984A1 (ja) * 2007-03-07 2008-09-12 Panasonic Corporation 携帯端末装置および携帯端末システム
US8768362B2 (en) * 2009-06-22 2014-07-01 Sharp Kabushiki Kaisha Communication system, mobile station, base station, and communication method
US8976691B2 (en) * 2010-10-06 2015-03-10 Blackbird Technology Holdings, Inc. Method and apparatus for adaptive searching of distributed datasets
EP2557870B1 (en) * 2011-08-10 2020-07-08 Alcatel Lucent Configuring transmissions
FI3761740T3 (fi) * 2012-09-13 2023-09-05 Huawei Tech Co Ltd Viestintämenetelmä, tukiasema, radioviestintäsolmu ja käyttäjälaite
WO2014092612A1 (en) 2012-12-10 2014-06-19 Telefonaktiebolaget L M Ericsson (Publ) A wireless device, a radio network node and methods for discontinuous reception in device to device communications
JP6429368B2 (ja) * 2013-08-02 2018-11-28 本田技研工業株式会社 歩車間通信システムおよび方法
CN106465438A (zh) * 2014-01-30 2017-02-22 瑞典爱立信有限公司 支持国家安全通信和公共安全通信的装置的预配置
EP3461156B1 (en) * 2014-02-02 2020-12-09 LG Electronics Inc. D2d gap for d2d discovery signal
KR102118402B1 (ko) * 2014-02-25 2020-06-03 삼성전자 주식회사 단말 간 직접 통신을 지원하는 무선 통신 시스템에서 단말의 전력 감소 방법 및 장치
RU2689428C2 (ru) * 2014-03-13 2019-05-28 Филипс Лайтинг Холдинг Б.В. Способ конфигурирования узлового устройства, сеть и узловое устройство
US9609680B2 (en) 2014-03-18 2017-03-28 Qualcomm Incorporated Signaling flows and buffer status report for a group in device-to-device broadcast communication
CN106105305B (zh) 2014-03-19 2019-07-09 Lg电子株式会社 在无线通信系统中配置用于公共安全传输或者车辆有关传输的缓冲器状态报告的方法和装置
WO2015147523A1 (en) * 2014-03-24 2015-10-01 Samsung Electronics Co., Ltd. Apparatus and method for monitoring d2d transmission in connected state
EP3141076B1 (en) 2014-05-08 2022-05-04 Telefonaktiebolaget LM Ericsson (publ) Relating activity periods for a ue performing device-to-device (d2d) and cellular operations
CN105379406B (zh) * 2014-05-21 2019-12-06 华为技术有限公司 一种设备到设备d2d通信中的信号传输方法及装置
CA2957406C (en) * 2014-08-06 2023-10-10 Interdigital Patent Holdings, Inc. Device-to-device (d2d) pre-emption and access control
US9661684B2 (en) * 2014-08-11 2017-05-23 Telefonaktiebolaget L M Ericsson (Publ) Method of sharing a UE receiver between D2D and cellular operations based on activity
JP6566957B2 (ja) * 2014-09-24 2019-08-28 シャープ株式会社 端末装置、基地局装置、通信方法および集積回路
EP3354081B1 (en) * 2015-09-25 2019-11-06 Sony Corporation Wireless telecommunications system
JP6623802B2 (ja) * 2016-02-04 2019-12-25 ソニー株式会社 ユーザ端末、通信装置及び方法

Also Published As

Publication number Publication date
US10568029B2 (en) 2020-02-18
ZA201803066B (en) 2018-12-19
US20180324694A1 (en) 2018-11-08
JP2017139659A (ja) 2017-08-10
WO2017135036A1 (en) 2017-08-10
ES2930438T3 (es) 2022-12-13
TWI752936B (zh) 2022-01-21
RU2732994C2 (ru) 2020-09-28
EP3412109B1 (en) 2022-10-19
SG11201804837PA (en) 2018-07-30
RU2018127198A (ru) 2020-01-27
US20230292239A1 (en) 2023-09-14
TW201739274A (zh) 2017-11-01
US11272448B2 (en) 2022-03-08
RU2018127198A3 (ja) 2020-04-21
US20200178174A1 (en) 2020-06-04
US11683754B2 (en) 2023-06-20
US20220191791A1 (en) 2022-06-16
MX2018009198A (es) 2018-08-28
EP3412109A1 (en) 2018-12-12

Similar Documents

Publication Publication Date Title
US11683754B2 (en) Method and device for sidelink communication based on parameters
US10728723B2 (en) User terminal, RSU, method and program
JP6849116B2 (ja) 通信装置、通信方法及びコンピュータプログラム
US11363429B2 (en) Communication device, communication method, transmission device and reception device
US10993245B2 (en) Terminal apparatus, base station, method, and recording medium
WO2017195535A1 (ja) 通信装置、通信方法及びコンピュータプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20181213

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20190208

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20190214

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20190222

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20190515

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20190522

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20190802

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190820

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20191011

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: 20191029

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20191111

R151 Written notification of patent or utility model registration

Ref document number: 6623802

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151