SIP 協調型自動運転ユースケースに関する通信
シナリオ／通信要件の検討資料
ITS FORUM RC-017 1.0 版

2022 年 6 月 24 日 策定
ITS 情報通信システム推進会議

SIP 協調型自動運転ユースケースに関する通信
シナリオ／通信要件の検討資料
ITS FORUM RC-017 1.0 版

2022 年 6 月 24 日 策定
ITS 情報通信システム推進会議

ITS FORUM RC-017
改訂履歴

版数

年月日

改定箇所

改定理由

1.0

2022 年 6 月 24 日

策定

新規策定

改定内容

ITS FORUM RC-017[余白]ITS FORUM RC-017
まえがき

本書は、SIP協調型自動運転ユースケースに関して、通信シナリオおよび、通信要件を検討したものである。
本書は、10章構成となっており、第1章に前提条件、第2章～第9章に各ユースケースに対する通信シナリオおよび通信要件、第10章にユースケースの通信要件のまとめを記載している。また付録
1にメッセージ構成を記載した。メッセージ構成については今後さらに具体的な検討を進めていく
予定である。さらに付録2として今後の検討課題を記載した。本書の記載内容に関して、残課題や検討未完了の項目がある事に留意して活用頂きたい。
ユースケースについては、関係者による実運用に向けた検討が今後さらに進むことで、その前提条件やサービス要件の設定が見直される可能性がある。本書はそれらの変更に対してアップデートを行っていく予定である。本検討を基に、自動運転に通信を活用する検討がさらに促進することを期待する。
(1) 背景高度化専門委員会 無線方式検討タスクグループでは、自動運転を想定したユースケース向けの通信仕様などを検討してきた。これまでに、一般社団法人日本自動車工業会が自動車専用道路の自動運転を想定して作成した「自動運転向け ITS 通信活用シーンと通信手順（案）」などに基づき、暫定的な通信仕様を検討し、2019 年 10 月に「自動運転(自専道)通信活用ユースケース向け通信システムの実験用ガイドライン ITS FORUM RC-015 1.0 版」を発行した。その後、内閣
府 戦略的イノベーション創造プログラム(SIP)に設置された協調型自動運転通信方式検討タスク
フォースにおいて、将来の協調型自動運転に必要な通信方式を検討するためのユースケースが検討され、2020 年 9 月に SIP 協調型自動運転ユースケース第 1 版が公開された。無線方式検討タ
スクグループでは、SIP 協調型自動運転ユースケースを実現する通信方式の策定に必要とされる、各ユースケースの通信シナリオや通信要件などの検討を SIP 協調型自動運転通信方式検討タスク
フォースや他の関連団体と連携して実施してきた。
(2) 目的
本書は、SIP 協調型自動運転ユースケースに適した通信方式の策定に向け、各ユースケースの通信シナリオや通信要件について、現時点での検討内容をまとめたものである。
自動運転向け通信方式の候補となる通信仕様を記載した「自動運転(自専道)通信活用ユース
ケース向け通信システムの実験用ガイドライン ITS FORUM RC-015」に掲載の通信方式をベースとして、本書の通信シナリオ・通信要件検討を用いて、SIP 協調型自動運転ユースケースへの適用可否の検討、通信仕様の見直しなどが今後進められることを目的とする。

ITS FORUM RC-017(3) 対象としたユースケース
本書においては、SIP 協調型自動運転ユースケース第 1 版[1]における以下 25 のユースケース
を検討対象とした。
対象とした SIP 協調型自動運転ユースケース

機能分類

ユースケース名

a.合流・車線変更支援

a-1-1.予備加減速合流支援

V2I

a-1-2.本線隙間狙い合流支援V2I

a-1-3.路側管制による本線車両協調合流支援V2I

a-1-4.車同士のネゴシエーションによる合流支援

V2V

a-2.混雑時の車線変更の支援

V2V

a-3.渋滞時の非優先道路から優先道路への進入支援

V2V

b-1-1.信号情報による走行支援（V2I）

V2I

b-1-2.信号情報による走行支援（V2N）

V2N

c.先読み情報：衝突回

c-1.前方での急停止、急減速時の衝突回避支援V2V

避c-2-1.交差点の情報による走行支援（V2V）

V2V

c-2-2.交差点の情報による走行支援（V2I）

V2I

c-3.ハザード情報による衝突回避支援

V2V

d.先読み情報：走行計

d-1.異常車両の通知による走行支援

V2I, V2N

画変更

d-2.逆走車の通知による走行支援

V2I, V2N

d-3.渋滞の情報による走行支援

V2I, V2N

d-4.分岐・出口渋滞支援

V2I, V2N

d-5.ハザード情報による走行支援

V2I, V2N

e-1.緊急車両の情報による走行支援

V2V, V2I,

b.信号情報e.先読み情報：緊急車

V2N

両回避
f.インフラによる情報

f-1.救援要請(e-Call)

収集・配信

f-2.交通流の最適化のための情報収集

g.隊列・追従走行

通信

V2N
V2I, V2N

f-3.地図更新・自動生成

V2N

f-4.ダイナミックマップ情報配信

V2N

g-1. 電子牽引による後続車無人隊列走行

V2V

g-2.追従走行並びに追従走行を利用した後続車有人隊

V2V

列走行
h.遠隔操作h-1.移動サービスカーの操作・管理

V2N

ITS FORUM RC-017(4) その他の留意事項
本書は検討資料という位置づけから、各所に ”NOTE” を記載している。これは本文中の説明においての注意点や検討における残課題を記載したものである。留意のうえ参考にして頂きたい。これら NOTE については、付録 2 の今後の検討課題とあわせて、今後アップデートを進める。
(5) 参考文献[1] SIP 協調型自動運転ユースケース -2019 年度協調型自動運転方式検討 TF 活動報告
https://www.sip-adus.go.jp/rd/rddata/usecase.pdf

ITS FORUM RC-017［余白］

ITS FORUM RC-017

SIP 協調型自動運転ユースケースに関する通信シナリオ／通信要件の検討資料
目次
第 1 章 前提条件 .................................................................................................................................1
1.1 基本条件 ...................................................................................................................................1
1.2 ダイナミックマップとの関係について ....................................................................................1
1.3 遅延の定義 ................................................................................................................................2
1.4 通信品質の規定について ..........................................................................................................4
1.5 参考文献 ...................................................................................................................................5
別添 1A

積算パケット到達率と 1 メッセージ当たりの到達率の関係について.............................6

第 2 章 a.合流・車線変更支援のユースケース ..................................................................................9
2.1 前提条件 ...................................................................................................................................9
2.2 シナリオ検討の進め方............................................................................................................11
2.3 想定する道路条件 ...................................................................................................................122.3.1

合流・車線変更支援の道路条件 ......................................................................................122.3.2

交差点進入支援の道路条件..............................................................................................14

2.4 合流・車線変更支援のユースケース......................................................................................15
2.4.1

ユースケース a-1-1. 予備加減速合流支援 ......................................................................15

2.4.1.1 想定する通信シナリオ ..............................................................................................15
2.4.1.2 想定される計測位置 ..................................................................................................15
2.4.1.3 必要な通信エリアの条件...........................................................................................15
2.4.1.4 車両 ID と車載器 ID の紐付け ..................................................................................16
2.4.1.5 メッセージ送受信シーケンス ...................................................................................172.4.1.6 通信内容 ....................................................................................................................172.4.1.7 想定される報知車両数 ..............................................................................................17
2.4.2

ユースケース a-1-2. 本線隙間狙い合流支援...................................................................18

2.4.2.1 想定する通信シナリオ ..............................................................................................18
2.4.2.2 想定される計測範囲の検討 .......................................................................................18
2.4.2.3 必要な通信エリアの条件...........................................................................................192.4.2.4 車両 ID と車載器 ID の紐付け ..................................................................................20
2.4.2.5 メッセージ送受信シーケンス ...................................................................................20
2.4.2.6 通信内容 ....................................................................................................................20
2.4.2.7 想定される報知車両数 ..............................................................................................20
2.4.3

ユースケース a-1-3. 路側管制による本線車両協調合流支援 .........................................222.4.3.1 想定する通信シナリオ ..............................................................................................22― i ―ITS FORUM RC-017
2.4.3.2 想定される計測範囲の検討 .......................................................................................222.4.3.3 必要な通信エリアの条件...........................................................................................222.4.3.4 車両 ID と車載器 ID の紐付け ..................................................................................23
2.4.3.5 メッセージ送受信シーケンス ...................................................................................25
2.4.3.6 通信内容 ....................................................................................................................27
2.4.3.7 想定される報知車両数 ..............................................................................................29
2.5 管制/合意のユースケース .......................................................................................................30
2.5.1

ユースケース a-1-3. 路側管制による本線車両協調合流支援 .........................................30

2.5.1.1 想定する通信シナリオ ..............................................................................................30
2.5.1.2 想定される管制範囲と通信エリアの検討 .................................................................30
2.5.1.3 メッセージ送受信シーケンス ...................................................................................312.5.1.4 路側管制で想定されるシーケンス遅延.....................................................................36
2.5.1.5 通信内容 ....................................................................................................................38
2.5.1.6 想定される送信数と送信頻度 ...................................................................................39
2.5.1.7 対応ユースケースについて .......................................................................................40
2.5.2

ユースケース a-1-4. 車同士のネゴシエーションによる合流支援 ..................................41

2.5.2.1 想定する通信シナリオ ..............................................................................................41
2.5.2.2 想定される通信範囲の検討 .......................................................................................41
2.5.2.3 メッセージ送受信シーケンス ...................................................................................45
2.5.2.4 通信内容 ....................................................................................................................47
2.5.2.5 想定される要求車両数と応答車両数 ........................................................................48
2.5.3

ユースケース a-2. 混雑時の車線変更の支援 ..................................................................49

2.5.3.1 想定する通信シナリオ ..............................................................................................49
2.5.3.2 想定される通信範囲の条件 .......................................................................................49
2.5.3.3 メッセージ送受信シーケンス ...................................................................................49
2.5.3.4 通信内容 ....................................................................................................................50
2.5.3.5 要求車両数と応答車両数...........................................................................................50
2.6 交差点進入支援のユースケース .............................................................................................51
2.6.1

ユースケース a-3. 渋滞時の非優先道路から優先道路への進入支援 ..............................51

2.6.1.1 想定する通信シナリオ ..............................................................................................51
2.6.1.2 想定される通信範囲の条件 .......................................................................................51
2.6.1.3 メッセージ送受信シーケンス ...................................................................................52
2.6.1.4 通信内容 ....................................................................................................................53
2.6.1.5 要求車両数と応答車両数...........................................................................................54
2.7 参考文献 .................................................................................................................................54― ii ―ITS FORUM RC-017
別添 2A

想定されるスポット計測位置の検討 ..............................................................................55

別添 2B

スポット計測における課題点 .........................................................................................64

別添 2C

十分な合流車線長が得られない場合の猶予時間について .............................................65

第 3 章 b.信号情報のユースケース ..................................................................................................71
3.1 前提条件 .................................................................................................................................71
3.2 シナリオ検討の進め方............................................................................................................71
3.3 信号情報における走行支援のユースケース...........................................................................71
3.3.1

ユースケース b-1-1. 信号情報による走行支援（V2I）..................................................71

3.3.1.1 想定する通信シナリオ ..............................................................................................73
3.3.1.2 想定される計測位置の検討 .......................................................................................73
3.3.1.3 必要な通信エリアの条件...........................................................................................73
3.3.1.4 車両 ID と車載器 ID の紐付け ..................................................................................75
3.3.1.5 メッセージ送受信シーケンス ...................................................................................75
3.3.1.6 通信内容 ....................................................................................................................76
3.3.2

ユースケース b-1-2. 信号情報による走行支援（V2N） ................................................82

3.3.2.1 想定する通信シナリオ ..............................................................................................82
3.3.2.2 想定される信号情報生成の方式................................................................................85
3.3.2.3 必要な通信エリアの条件...........................................................................................85
3.3.2.4 車両位置と近傍信号の紐付け ...................................................................................85
3.3.2.5 メッセージ送受信シーケンス ...................................................................................86
3.3.2.6 通信内容 ....................................................................................................................89
3.3.2.7 課題・検討項目 .........................................................................................................89
3.4 参考文献 .................................................................................................................................90
第 4 章 c.先読み情報：衝突回避のユースケース .............................................................................91
4.1 前提条件 .................................................................................................................................91
4.2 検討の進め方 ..........................................................................................................................91
4.3 想定する道路条件 ...................................................................................................................914.3.1

衝突回避支援の道路条件 .................................................................................................91

4.3.2

交差点の情報による走行支援の道路条件........................................................................91

4.4 衝突回避のユースケース ........................................................................................................93
4.4.1

ユースケース c-3. ハザード情報による衝突回避支援 ....................................................93

4.4.1.1 想定シナリオ .............................................................................................................93
4.4.1.2 想定する通信エリア ..................................................................................................93
4.4.1.3 想定する通信遅延......................................................................................................94
4.4.1.4 想定する通信品質......................................................................................................94― iii ―ITS FORUM RC-017
4.4.1.5 メッセージ送受信手順 ..............................................................................................95
4.4.1.6 通信内容 ....................................................................................................................96
4.4.1.7 想定されるメッセージ送信車両台数 ........................................................................96
4.5 交差点の情報による走行支援のユースケース .......................................................................98
4.5.1

ユースケース c-2-1. 交差点の情報による走行支援（V2V）.........................................98

4.5.1.1 想定シナリオ .............................................................................................................98
4.5.1.2 想定する通信エリア及び、通信距離 ........................................................................98
4.5.1.3 想定する通信遅延....................................................................................................100
4.5.1.4 想定する通信品質....................................................................................................100
4.5.1.5 メッセージ送受信手順 ............................................................................................100
4.5.1.6 通信内容 ..................................................................................................................101
4.5.1.7 想定されるメッセージ送信車両台数 ......................................................................101
4.5.2

ユースケース c-2-2. 交差点の情報による走行支援（V2I） .........................................104

4.5.2.1 想定シナリオ ...........................................................................................................104
4.5.2.2 想定する通信エリア及び、路側センサ検知範囲 ....................................................104
4.5.2.3 想定する通信遅延....................................................................................................106
4.5.2.4 想定する通信品質....................................................................................................106
4.5.2.5 メッセージ送受信手順 ............................................................................................106
4.5.2.6 通信内容 ..................................................................................................................1084.5.2.7 想定されるメッセージ送信車両台数 ......................................................................111
4.6 参考文献 ...............................................................................................................................111
第 5 章 d.先読み情報：走行計画変更のユースケース ...................................................................113
5.1 前提条件 ...............................................................................................................................113
5.1.1

通信システムの前提 ......................................................................................................113

5.1.2

想定する道路条件 ..........................................................................................................116

5.1.3

路側インフラの設置条件 ...............................................................................................116

5.1.4

無線通信エリアの条件 ...................................................................................................116

5.1.5

広域通信におけるサービス提供エリアの考え方 ...........................................................117

5.1.6

広域通信（V2N）活用の考え方 ....................................................................................118

5.1.7

通信遅延.........................................................................................................................118

5.2 先読み情報：走行計画変更のユースケース.........................................................................119
5.2.1

ユースケース d-1. 異常車両の通知による走行支援 .....................................................1195.2.1.1 通信の目的 ..............................................................................................................1195.2.1.2 通信の概要 ..............................................................................................................1195.2.1.3 ハザード情報の配信方法.........................................................................................119― iv ―ITS FORUM RC-017
5.2.1.4 想定シナリオ ...........................................................................................................122
5.2.1.5 通信シーケンスと内容 ............................................................................................124
5.2.1.6 メッセージサイズ....................................................................................................130
5.2.2

ユースケース d-2. 逆走車の通知による走行支援 .........................................................132

5.2.2.1 通信の目的 ..............................................................................................................132
5.2.2.2 通信の概要 ..............................................................................................................132
5.2.2.3 逆走車の検知 ...........................................................................................................132
5.2.2.4 想定シナリオ ...........................................................................................................133
5.2.2.5 通信シーケンスと内容 ............................................................................................135
5.2.2.6 メッセージサイズ....................................................................................................141
5.2.3

ユースケース d-3. 渋滞の情報による走行支援.............................................................142

5.2.3.1 通信の目的 ..............................................................................................................142
5.2.3.2 通信の概要 ..............................................................................................................142
5.2.3.3 渋滞情報の配信方法 ................................................................................................142
5.2.3.4 想定シナリオ ...........................................................................................................146
5.2.3.5 通信シーケンスと内容 ............................................................................................148
5.2.3.6 メッセージサイズ....................................................................................................154
5.2.4

ユースケース d-4. 分岐・出口渋滞支援........................................................................156

5.2.4.1 通信の目的 ..............................................................................................................156
5.2.4.2 通信の概要 ..............................................................................................................156
5.2.4.3 分岐・出口渋滞の判断 ............................................................................................156
5.2.4.4 分岐・出口渋滞情報の配信（V2I、V2N） ............................................................156
5.2.4.5 通信エリアの条件....................................................................................................158
5.2.4.6 想定シナリオ ...........................................................................................................160
5.2.4.7 通信シーケンスと内容 ............................................................................................161
5.2.4.8 メッセージサイズ....................................................................................................167
5.2.5

ユースケース d-5. ハザード情報による走行支援 .........................................................169

5.2.5.1 通信の目的 ..............................................................................................................169
5.2.5.2 通信の概要 ..............................................................................................................169
5.2.5.3 ハザード情報の配信方法.........................................................................................169
5.2.5.4 想定シナリオ ...........................................................................................................171
5.2.5.5 通信シーケンスと内容 ............................................................................................173
5.2.5.6 メッセージサイズ....................................................................................................179
第 6 章 e.先読み情報：緊急車両回避のユースケース ...................................................................181
6.1 前提条件 ...............................................................................................................................181― v ―ITS FORUM RC-017
6.2 先読み情報：緊急車両回避のユースケース.........................................................................181
6.2.1

ユースケース e-1. 緊急車両の情報による走行支援......................................................181

6.2.1.1 通信の目的 ..............................................................................................................181
6.2.1.2 通信の概要 ..............................................................................................................181
6.2.1.3 想定する道路条件....................................................................................................181
6.2.1.4 想定する前提条件....................................................................................................182
6.2.1.5 緊急車両接近情報の配信.........................................................................................182
6.2.1.6 通信エリアの条件....................................................................................................184
6.2.1.7 通信遅延 ..................................................................................................................189
6.2.1.8 想定シナリオ ...........................................................................................................189
6.2.1.9 通信シーケンスと内容 ............................................................................................191
6.2.1.10

メッセージサイズ .................................................................................................197

第 7 章 f.インフラによる情報収集・配信のユースケース .............................................................201
7.1 インフラによる情報収集・配信における条件 .....................................................................201
7.2 f.インフラによる情報収集・配信のユースケース ...............................................................203
7.2.1

ユースケース f-1. 救援要請(e-Call) ..............................................................................2037.2.1.1 通信の目的 ..............................................................................................................2037.2.1.2 通信の概要 ..............................................................................................................2037.2.1.3 救援要請の配信方法 ................................................................................................2037.2.1.4 要件 .........................................................................................................................2047.2.1.5 目標とする通信品質 ................................................................................................2047.2.1.6 通信エリアの条件....................................................................................................2047.2.1.7 想定シナリオ ...........................................................................................................2057.2.1.8 メッセージ送受信シーケンス .................................................................................206
7.2.1.9 メッセージサイズ....................................................................................................207
7.2.2

ユースケース f-2. 交通流の最適化のための情報収集...................................................208

7.2.2.1 通信の目的 ..............................................................................................................208
7.2.2.2 通信の概要 ..............................................................................................................208
7.2.2.3 車両情報の配信方法 ................................................................................................208
7.2.2.4 目標とする通信品質（V2N） .................................................................................216
7.2.2.5 メッセージサイズ....................................................................................................216
7.2.3

ユースケース f-3. 地図更新・自動生成 ........................................................................217

7.2.3.1 通信の目的 ..............................................................................................................217
7.2.3.2 通信の概要 ..............................................................................................................217
7.2.3.3 地図情報（変化点の情報）の送信方法...................................................................217― vi ―ITS FORUM RC-017
7.2.3.4 要件 .........................................................................................................................218
7.2.3.5 目標とする通信品質 ................................................................................................219
7.2.3.6 通信エリアの条件....................................................................................................219
7.2.3.7 想定シナリオ目標とする通信品質 ..........................................................................219
7.2.3.8 メッセージ送受信シーケンス .................................................................................220
7.2.3.9 メッセージサイズ....................................................................................................221
7.2.4

ユースケース f-4. ダイナミックマップ情報配信 ..........................................................222

7.2.4.1 通信の目的 ..............................................................................................................222
7.2.4.2 通信の概要 ..............................................................................................................222
7.2.4.3 目標とする通信品質 ................................................................................................222
7.2.4.4 通信エリアの条件....................................................................................................222
7.2.4.5 地図データサイズ....................................................................................................222
7.2.4.6 自動運転車のふるまい ............................................................................................222
7.2.4.7 データ配信の条件....................................................................................................223
7.2.4.8 想定シナリオ ...........................................................................................................223
7.2.4.9 メッセージ送受信シーケンス .................................................................................225
7.2.4.10

メッセージサイズ .................................................................................................225

7.3 参考文献 ...............................................................................................................................226
第 8 章 g.隊列・追従走行のユースケース......................................................................................227
8.1 前提条件 ...............................................................................................................................227
8.2 検討の進め方 ........................................................................................................................227
8.3 隊列走行のユースケース ......................................................................................................227
8.3.1

ユースケース g-1. 電子牽引による後続車無人隊列走行 ..............................................227

8.3.1.1 想定する通信シナリオ ............................................................................................227
8.3.1.2 必要な通信エリアの条件.........................................................................................228
8.3.1.3 車両 ID と車載器 ID の紐付け ................................................................................228
8.3.1.4 メッセージ送受信シーケンス .................................................................................228
8.3.1.5 通信内容 ..................................................................................................................230
8.3.2

ユースケース g-2. 追従走行並びに追従走行を利用した後続車有人隊列走行 .............231

8.3.2.1 想定する通信シナリオ ............................................................................................235
8.3.2.2 必要な通信エリアの条件.........................................................................................235
8.3.2.3 車両 ID と車載器 ID の紐付け ................................................................................235
8.3.2.4 メッセージセット....................................................................................................235
8.3.2.5 メッセージ送受信シーケンス .................................................................................236
8.4 参考文献 ...............................................................................................................................237― vii ―ITS FORUM RC-017
第 9 章 h.遠隔操作のユースケース ................................................................................................239
9.1 遠隔操作における条件..........................................................................................................239
9.2 h.遠隔操作のユースケース...................................................................................................240
9.2.1

ユースケース h-1. 移動サービスカーの操作・管理 .....................................................240

9.2.1.1 通信の目的 ..............................................................................................................240
9.2.1.2 通信の概要 ..............................................................................................................240
9.2.1.3 目標とする通信品質 ................................................................................................241
9.2.1.4 通信エリアの条件....................................................................................................241
9.2.1.5 想定シナリオ ...........................................................................................................242
9.2.1.6 メッセージ送受信シーケンス .................................................................................244
9.2.1.7 メッセージサイズ....................................................................................................247
9.3 参考文献 ...............................................................................................................................248
第 10 章 通信要件まとめ ................................................................................................................249
付録 1 メッセージ構成の検討 ........................................................................................................2651

概要..........................................................................................................................................2652

前提条件 ..................................................................................................................................265

3

メッセージ構造........................................................................................................................265
3.1 メッセージ情報 .................................................................................................................267
3.1.1

利用ユースケース.......................................................................................................267

3.1.2

情報要素詳細 ..............................................................................................................267

3.2 路側インフラ基本情報 ......................................................................................................270
3.2.1

利用ユースケース.......................................................................................................270

3.2.2

情報要素詳細 ..............................................................................................................270

3.3 車両基本情報 ....................................................................................................................270
3.3.1

利用ユースケース.......................................................................................................271

3.3.2

情報要素詳細 ..............................................................................................................271

3.4 ユースケース固有情報 ......................................................................................................278
3.4.1

路側管制情報 ..............................................................................................................278

3.4.1.1 利用ユースケース ................................................................................................278
3.4.1.2 情報要素詳細 .......................................................................................................278
3.4.2

周辺車両情報 ..............................................................................................................278

3.4.2.1 利用ユースケース ................................................................................................278
3.4.2.2 情報要素詳細 .......................................................................................................278
3.4.3

調定情報 .....................................................................................................................281

3.4.3.1 利用ユースケース ................................................................................................281― viii ―ITS FORUM RC-017
3.4.3.2 情報要素詳細 .......................................................................................................281
3.4.4

交差点情報 .................................................................................................................282

3.4.4.1 利用ユースケース ................................................................................................282
3.4.4.2 情報要素詳細 .......................................................................................................282
3.4.5

ハザード情報 ..............................................................................................................284

3.4.5.1 利用ユースケース ................................................................................................284
3.4.5.2 情報要素詳細 .......................................................................................................284
3.4.6

後続車無人隊列走行情報............................................................................................286

3.4.6.1 利用ユースケース ................................................................................................286
3.4.6.2 情報要素詳細 .......................................................................................................286
3.4.7

後続車有人隊列走行情報............................................................................................286

3.4.7.1 利用ユースケース ................................................................................................286
3.4.7.2 情報要素詳細 .......................................................................................................286
4

情報要素の多重........................................................................................................................2875

参考文献 ..................................................................................................................................289

付録 2 今後の検討課題 ...................................................................................................................291― ix ―ITS FORUM RC-017

［余白］

― x ―

ITS FORUM RC-017

第1章

前提条件

本検討における前提条件について記載する。
1.1 基本条件
SIP協調型自動運転ユースケース[1]で定義された協調型自動運転システム（自律型自動運転シス
テムをベースに、車載センサ検知外の情報や自車が保有する情報の提供及び車車／路車間の意思疎通を通信で行うことで、より安全でスムーズな自動運転制御を可能とするシステム)を利用して走行する車両を自車と想定する。
周辺の他車両としては、協調型自動運転システムで自動走行している車両を“協調走行車”、協調型自動運転システムを搭載していない、ドライバが運転する車両（協調型自動運転システムを使用
せずにドライバが運転する車両を含む）や、自律型自動運転システムで自動走行している車両を“V2X非対応車”とする。
1.2 ダイナミックマップとの関係について
ダイナミックマップとは、静的情報である高精度3次元地図情報と、動的データ（準静的情報、
準動的情報、動的情報)とを紐づけたもので、自動運転車の判断や走行計画作成等に活用するものである（ユースケースによっては路側インフラ等においても活用されることが考えられる)。
協調型自動運転システムは、自車の自律センサ以外に、周辺車両や路側インフラ、クラウドサー
バ等から動的データを取得し、それらを自車が持つ高精度3次元地図情報と紐づけ、ダイナミック
マップとして使用することが想定されたものである（図1.2-1参照）。本書の内容は、これら動的データを取得する無線通信を対象に検討したものである（ユースケースによっては、静的データも取得する)。

―1―

ITS FORUM RC-017

図 1.2-1 ダイナミックマップの構築イメージ[2]NOTE: 高精度3次元地図においては、参照ポイント（Common Reference Point、以下CRPとする)に基づく相対的位置参照方式が検討されており、無線通信で動的データを送受信する際の位置情報や道路/車線情報等は、絶対位置ではなくCRPに基づく相対位置を用いて表現することも考えられる[2]。本版においては、CRPに基づく相対位置による表現の活用については十分な検討が出来ておらず、今後検討を行う。
1.3 遅延の定義
本書で扱う遅延の定義として、システム各部における遅延の関係を、路側インフラから車両へ送信を行うケースを例に、図1.3-1に示す。

―2―

ITS FORUM RC-017

T1
走行車両の速度・車長などを測定したセンサ出力T2
無線方式非依存の遅延

センサ・インフラ
での遅延-センサ信号処理遅延
センサ・インフラ間通信遅延
インフラ信号処理遅延

無線方式依存の遅延- インフラ送信遅延

初回送信

最終送信

無線区間での通信

T3
受信機
処理遅延

受信側での遅延受信機
処理遅延

無線区間許容遅延(T3 – T2)
センサ出力から無線での受信・復号処理完了までの遅延(T3 – T1)

図 1.3-1 システム各部における遅延の関係

本検討においては、図1.3-1にあるようにシステム全体の遅延の内、T3-T2で求められる遅延を無線区間許容遅延と定義した。無線区間許容遅延は、無線アクセスレイヤが所要品質（所要のパケッ
ト到達率や通信距離など）を実現するためにシステムが許容する最大遅延時間であり、無線アクセ
ス方式の比較などに用いることが想定される。

NOTE:無線区間以外の部分も含めたサービス観点の所要通信エリア・距離などの検討には、図1.31のT3-T1で求められる、センサ出力から無線での受信・復号処理完了までの遅延を見る必要があり、サービス提供者などとの議論が必要である。
NOTE：図1.3-1は、V2Iを活用したシステムについて例示したものであるが、ここに記載した以外にも遅延は存在する可能性がある。例えばV2Nを活用したシステムにおいては、サーバ処理遅延や、送信情報を更新するまでの判断遅延等が考えられる。

―3―

ITS FORUM RC-017
また、無線区間許容遅延について、無線アクセスレイヤにおける遅延の関係を図1.3-2に示す。

送信側の無線アクセスレイヤ
より上位

上位からのメッセージ#n

上位からのメッセージ#n+1

無線送信遅延（e.g. 送信機会待ち遅延、送信時間）

送信側

初送

無線アクセスレイヤ(再送/連送)

初送(再送/連送)受信側
無線受信遅延（e.g. 復号遅延、データ再構築遅延）

受信側の無線アクセスレイヤ
より上位
無線区間許容遅延

無線区間許容遅延

図 1.3-2 無線アクセスレイヤにおける遅延の関係

図1.3-2のように無線アクセスレイヤでは、上位レイヤからの各メッセージに対して所要品質（所要のパケット到達率や通信距離など）を実現するために、再送/連送が必要に応じて実施される。このため、無線区間許容遅延には無線アクセスレイヤにおける送信機会待ち遅延、送信時間、
再送/連送にかかる遅延、受信側信号処理遅延などが含まれる。無線アクセスレイヤの通信方式としては、ITS FORUM RC-015 自動運転（自専道）通信活用ユースケース向け通信システムの実験用ガイドラインに記載されている通信方式などの適用が想定され、連送／再送処理は、例えばITSFORUM RC-005 参照方式ではレイヤ7で行われ、LTE-V2XではMACサブレイヤを含むレイヤ2で行われる。無線区間許容遅延を超えたメッセージは、復号結果にかかわらず未到達とみなす。
1.4 通信品質の規定について本書で扱う通信品質の定義は、1.3節の無線区間許容遅延における1メッセージあたりのパケット到達率（Packet Arrival Rate: PAR）として規定する（安全運転支援システムで主に用いられている積算パケット到達率と、1メッセージあたりの到達率の関係については別添1A参照）。

―4―

ITS FORUM RC-017
1.5 参考文献[1] SIP 協 調 型 自 動 運 転 ユ ー ス ケ ー ス -2019 年 度 協 調 型 自 動 運 転 方 式 検 討 TF 活 動 報 告https://www.sip-adus.go.jp/rd/rddata/usecase.pdf[2] SIP 第 2 期／自動運転(システムとサービスの拡張)／高 精度 3 次元地図における位置参照点(CRP)のあり方に関する調査検討 (2019 年度～2020 年度)
https://www.sip-adus.go.jp/rd/rddata/rd04/210.pdf―5―ITS FORUM RC-017
別添 1A

積算パケット到達率と 1 メッセージ当たりの到達率の関係について

従来、車車間/路車間通信における所要通信品質の指標として、積算パケット到達率（アプリ
ケーション視点の考え方）が用いられている（文末記載参考資料[1-4]）。積算パケット到達率では、所定の移動区間において通信が最低一回成立すればよく、一回でも通信が成功すれば当該地点
から 1 秒程度は車両位置と挙動は予測可能との考えにのっとっている[2]。例えば、移動区間（評価区間）5m における積算パケット到達率 95%以上を所要品質とし、車両速度を 70km、情報配信
車両のメッセージ配信周期を 100ms（各メッセージの内容は異なりうる)とする。その場合、所定エリアである移動区間（評価区間）5m（時間で 260ms）では 2 回の受信機会があるため、そのう
ち 1 つを受信する確率が 95%以上であれば、所要の品質を満足しているとみなす。つまり、単一のメッセージのパケット誤り率が 20%以下であれば 1-(0.2)2=0.96 であるため、所要品質を満たすことができる。
周期的に配信される情報のように積算パケット到達率の考え方が適用しうるユースケースの場合には、パケット到達率を算出するための条件（パケット到達率での評価区間、車両速度、所要品
質、所要遅延など）の明確化が必要である（尚、文献[1]では「車車間通信における通信品質は、
車両が 10m 走行する間に累積したパケット到達率が 95％となることを想定している。今後、位置測位精度向上の状況によって、車両が 5m 走行する際の累積パケット到達率が 95%以上となるよう検討を進めることが重要である。」としている）。
周期的に配信される情報においても、移動速度が高速な場合には情報受信機会が制限されるた
め、積算パケット到達率からの要求を 1 メッセージで満たす必要があり、無線区間許容遅延で実現すべきパケット到達率と等価となる。例えば、評価区間 5m、情報配信周期を 100ms、積算パケッ
ト到達率 95%以上の場合、車両移動速度が 100km/h 以上となると評価区間内における情報受信機
会は 1 回しかなく、1 メッセージの到達率 95%以上を満たす必要がある。
また、車車間/路車間のネゴシエーションに用いるメッセージなどは、評価区間内において通信相手から受信した情報などによってメッセージ毎の内容が変わりうるため、単純に積算パケット到
達率の考え方を適用できない。よって、積算パケット到達率の適用については、ユースケースや情報の性質毎に、アプリケーションの成立性の観点で見極める必要がある。

―6―

ITS FORUM RC-017

図 1A-1. ITS 無線システムの高度化に関する研究会 H21 年６月報告書[1]―7―ITS FORUM RC-017（参考資料）[1] ITS 無線システムの高度化に関する研究会 H21 年 6 月報告書、総務省 ITS 無線システムの高度化に関する研究会、https://www.soumu.go.jp/main_content/000025421.pdf[2]先進安全自動車(ASV)推進計画 報告書 第 4 期 ASV 計画における活動成果について、国土交通
省自動車交通局 先進安全自動車推進検討会、
https://www.mlit.go.jp/jidosha/anzen/01asv/data/asv4pamphlet_seika.pdf[3] マシンツーマシン通信を代表とする ITS の現状と展望、堀松哲夫、佐々木邦彦、浜口雅春、
https://www.jstage.jst.go.jp/article/bplus/5/3/5_3_220/_pdf[4] 車車間通信を利用した運転支援システム-第 4 期 ASV の取組みから-、藤本浩、
https://www.ieice.org/jpn/books/kaishikiji/2012/201208.pdf―8―ITS FORUM RC-017

第2章

a.合流・車線変更支援のユースケース

2.1 前提条件
本検討のシナリオや通信車両台数の試算では、以下の条件で検討した。

メッセージと車両の挙動との関係・ 送受信したメッセージと整合した走行を自動運転により行うことを想定する。なお、メッセージ送信後に緊急制動といったより優先度の高い動作を実施する場合には、対応するメッセージを送信することを想定する。
・ 周辺の協調走行車については、緊急制動や非自動運転時も含めて、送受信したメッセー
ジと整合した走行を行うことを想定する（例えば、右折の意図を表明するが右折しない
ケースは想定しない）。

時刻精度
・ 路側インフラおよび協調走行車は、メッセージ内容の時刻情報の理解のため、それぞれ
GNSS同期の時刻情報を持っているものとする。ただし、所持する時刻精度およびGNSS非捕捉時に許容される時刻精度は要検討。
車線数
・ 自専道の車線数：片側6車線（合流・分岐レーンのある所は7車線)を最大として検討する・ 連絡路の車線数：片側2車線を最大として検討する
・ 一般道の車線数：信号のない非優先道路となるため片側3車線で検討する

想定車間距離・ 通常環境：2秒車間で検討する

・ 混雑した環境：1秒車間で検討する（合流、車線変更の直後と隊列走行車の車間は除外）―9―

ITS FORUM RC-017
速度条件・ 自動走行中の車両：

法定速度を順守した走行・ 運転者が操作する車両： 法定速度＋10km/hを上限速度とした走行
渋滞時の検討が必要な場合は、全ての車両が、自専道：40km/h、一般道：5km/h（仮値）とみなして検討する。全車両が停止していても問題が無いようにする。

最大加減速条件
最大加減速は、緊急時を除いて全ての車両が下記条件で運行されるとみなして検討する。
・ 最大加速度：普通車は 0.2G、大型車は0.15G
・ 最大減速度：普通車は0.25G、大型車は0.15G目標とする通信性能
・ 1メッセージあたりの通信パケット到達率を無線区間許容遅延:100msで99%以上とする。
・ 700MHz帯システム[1]（スライド3など）やLTE-V2Xなどで、周期的なメッセージの無線アクセスレイヤへの入力タイミングがシステム固有のGNSSなどから同期した100ms
周期と異なる場合に、追加の100ms遅延を考慮するかは検討が必要である。

隊列走行車や追従走行車の車長について・ 隊列走行車や追従走行車が、合流や車線変更を行う事象では、他の車両を車両間へ割り込ませない工夫が必要と推定されるため、追従走行中や隊列走行中は、後続の車両から車両情報（全長と車間距離）を得られるとみなして、車長を自車の全長＋後続車の全長＋車間距離として扱うものとする（トレーラーや牽引車も、けん引の有無を同様に扱うことが可能と思われる）。

―10―

ITS FORUM RC-017
2.2 シナリオ検討の進め方
以下のユースケースについてのシナリオ検討進める。
・ ユースケース a-1-1. 予備加減速合流支援・ ユースケース a-1-2. 本線隙間狙い合流支援・ ユースケース a-1-3. 路側管制による本線車両協調合流支援・ ユースケース a-1-4. 車同士のネゴシエーションによる合流支援・ ユースケース a-2.

混雑時の車線変更支援

・ ユースケース a-3.

渋滞時の非優先道路から優先道路への進入支援

上記シナリオのうち、ユースケース a-1-1、a-1-2 および a-1-3 は、通信の目的は異なるが、ユー
スケース a-1-3 で必要となる路側管制を除けば、いずれも合流車に対する路側インフラからの情報提供（a-1-3 では本線への情報提供を含む）となっている。
また、ユースケース a-1-2 はユースケース a-1-1 の上位互換、ユースケース a-1-3 の情報提供は
ユースケース a-1-2 の上位互換の関係となるため、これらを共通の位置情報メッセージとして、合流支援のユースケースとして並行して検討する。
なお、ユースケース a-1-3 で必要となる路側管制を、情報提供の通信シーケンスと切り分けた場
合、路側インフラと協調走行車の違いや管制と合意の違いはあるが、ユースケース a-1-4 およびユー
スケース a-2 の通信シーケンスと共通化することが可能と考えられるため、本章では情報提供と路側管制を切り分けて管制/合意の通信シーケンスに適用することを検討する。

―11―

ITS FORUM RC-017
2.3 想定する道路条件
2.2 節で記した通り、合流・車線変更と交差点進入のシナリオに分類される。それぞれの道路条件について以下に記す。
2.3.1

合流・車線変更支援の道路条件

合流支援が行われる道路の分類を、表 2.3.1-1 に記す。
表 2.3.1-1 合流支援が行われる道路の分類

本検討で想定したモデル

想定する道路の例

法定速度の上限

一時停止の有無1

都市間高速120km/h

無

制限なし

2

都市高速道路80km/h無制限あり（50m)

3

地域高規格道路や一般道

70km/h有

制限あり（ 0m)

ランプ・連絡路長

表 2.3.1-1 の通り、モデル 1 の移動距離が最も大きく、計測センサから合流起点までの距離を必要とする（速度変化に応じて車両数が大きく変動する）。
なお、モデル 1 の国内の都市間高速では、一般的な本線の法定速度：100km/h、連絡路の法定速度：40km/h での合流路（合流車線長：255m）の道路条件（図 2.3.1-1 参照）とし、モデル 2 の様な十分な連絡が得られない条件となる、本線の法定速度：80km/h、料金所から合流起点までの距離
50m の道路条件（図 2.3.1-2 参照）についても検討する。
また、モデル 3 の地域高規格道路では、一般的な本線の法定速度：70km/h、合流起点に一時停止のある合流路（合流車線長：190m）の道路条件（図 2.3.1-3 参照）とする。
なお、合流車線および本線の各部名称として、図 2.3.1-1 へ記した通り、合流起点から上流を「連絡路」、合流起点から下流を「合流路」、合流路に隣接する本線を「流入路」と称する（合流路の法定速度は本線に準じる）。
また、連絡路から流入路を走行する車両は検知不可（自律センサの検知外）とみなし、合流路から流入路を走行する車両は検知可能とみなす。

―12―

ITS FORUM RC-017

255.0m
合流終点（合流車線長終端）（合流車線長）合流起点(加速レーン起点）
本線側：流入路、 連絡路側：合流路

図 2.3.1-1 都市間高速の合流で想定する道路の例と各部名称

料金所

連絡路：50.0m

210.0m（合流車線長）合流起点（加速レーン起点）

合流完了位置（合流車線長終端）

図 2.3.1-2 都市高速道路の合流で想定する道路の例と各部名称

190.0m（合流車線長：70km/h標準条件）

合流完了位置（合流車線長終端）

合流起点(一時停止線）

図 2.3.1-3 地域高規格道路の合流で想定する道路の例と各部名称

車線変更は様々な状況で発生するが、本検討では混雑時の車線変更が目的のため、同一進行方向の車線間とし、自動走行する車線の混雑によって法定速度との速度差が大きく、かつ前後の車両によって見通しが悪く隣接車線との相対速度が把握できず、自律走行の車線変更が困難な状況とする。
ただし、隣接車線との相対速度が大きいと車線変更は困難となるため、法定速度：100km/h の道路で走行車線が混雑して 80km/h@1 秒車間、隣接する走行車線が 100km/h@2 秒車間（相対速度 20km/h）の道路条件（図 2.3.1-4）で検討する。

―13―

ITS FORUM RC-017

80km/h,1秒車間
22.2m

55.6m
100km/h,2秒車間

図 2.3.1-4 車線変更で想定する道路の例

2.3.2

交差点進入支援の道路条件

信号のない交差点にて、非優先道路から優先道路へ進入する状況は、様々な道路事情が想定されるため、通信台数が最も多くなると予測される優先道路が横断可能な道路条件とする。
ただし、法定速度の高い道路幅のある道路では、中央分離帯で対向車線と分離され、右折や道路横断が不可となっている場合が多いため、優先道路側が片側 3 車線、法定速度：50km/h、非優先道路との交差点における中央分離帯が安全帯となっている道路条件（図 2.3.2-1）で検討する。

図 2.3.2-1 交差点進入支援で想定する道路の例―14―

ITS FORUM RC-017
2.4 合流・車線変更支援のユースケース
2.4.1

ユースケース a-1-1. 予備加減速合流支援

ユースケース a-1-1 は、スポット計測センサを本線上流部へ設置し、合流車線に隣接する本線を走行する車両の速度や車長を計測して、路側インフラから連絡路の協調走行車へ配信し、予備加減速の判断材料として活用する。
2.4.1.1 想定する通信シナリオ
予備加減速合流支援で想定するシナリオは以下の通り①

路側インフラは一定周期で、計測時刻、速度、車長、到達予測時刻を含む位置情報メッセージを送信する。連絡路を走行する自車が通信エリアへ侵入すると、位置情報メッセージを受信する。

②

自車は、受信した（合流起点への）到達予測時間から速度調整のための猶予時間を考慮して合流予定場所と時刻の判断や、走行計画の見直しが行われる。

③

自律走行での合流が可能と判断した自車は、合流起点に向かって法定速度内での予備加減速を行い（予備加減速中に通信エリアを通過する）、合流起点を通過すると予定していた合流開始位
置へ向かって加速を開始する。
（加速中に自車の自律センサ情報が反映され、合流場所の決定と加減速制御が行われる。）

2.4.1.2 想定される計測位置
ユースケース a-1-1 の計測センサはスポット計測センサとなるため、本線上流の流入路を走行する車両に対して、情報提供までに計測が行える場所へ設置される。
スポット計測センサの設置場所は実装依存となる（設置場所の交通流を考慮した上で、可能な限り下流へ設置すると考えられる）が、本書では報知車両の最大数を得るため、最長時間の設置場所とみなして検討を進めることとし、別添 2B で検討した結果を踏まえて、スポット計測センサの設
置位置がより上流となる表 2A-5 の結果を用いて検討した。
2.4.1.3 必要な通信エリアの条件
ユースケース a-1-1 で位置情報メッセージに必要な通信エリアは、別添 2A における表 2A-5 の結果を用いて検討を行った。モデル 1（図 2.3.1-1）の連絡路の法定速度：40km/h においては、自車が合流起点の 6.1 秒前までに位置情報メッセージを受信すると想定すると、通信エリアは合流起点
から、連絡路の少なくとも（連絡路の法定速度：40km/h）×6.1 秒に対応する距離分上流にある地点周辺を網羅する必要がある。また、自車の前方を法定速度に満たない速度で走行する車両が存在
し、法定速度に満たない速度での走行を強いられる場合、合流起点の 6.1 秒前の自車位置は、より下流側になるため、下流側も網羅するようなある程度広い通信エリアが必要といえる。

―15―

ITS FORUM RC-017
仮に、連絡路の法定速度に対して、法定速度の半分の走行速度までの速度低下を許容した場合の必要な通信エリアを表 2.4.1.3-1 に記す（一時停止までを許容する場合、通信エリアを合流起点まで拡大する必要がある）。ただし、モデル 2(都市高速道路)については、表 2A-8 にあるように大型車の場合には 2 秒の猶予時間の確保が難しいことが想定されるため、通信エリアの上限側は、少なくとも料金所通過点を含む必要がある。下流側は低速になる場合を考慮し、合流基点までとした。
ユースケース a-1-1 の位置情報メッセージの通信エリアは、下流側をユースケース a-1-2 と同様に合流起点としても問題ないが、表 2.4.1.3-1 のエリアに制限することも可能である。
表 2.4.1.3-1 連絡路の道路モデルと必要な通信エリアの関係

道路モデル

a-1-1.に必要な通信エリア（合流起点から上流距離）

モデル 1 (都市間高速)連絡路法定速度：40km/h

33.9m（ 67.8m ～ 33.9m）

モデル 2 (都市高速道路)

50m（ 50m ～ 0m）

モデル 1 の道路条件に対して、スポット計測位置、通信エリアと、参考として 100km/h、2 秒車間で車両を配置すると図 2.4.1.3-1 の位置関係となる。

：スポットセンサで計測された、位置情報提供対象の対象車両（6台）：車線変更中の車両（5台）：a-1-1.通信に関与しない車両

想定される配信エリア（加速レーン起点6.1秒手前@40km～6秒手前@20km/h）
合流完了位置合流起点（合流車線長終端）
255.0m（合流車線長）合流開始位置(合流車線長終端の3秒手前）※A
加速レーン起点5秒前
スポットセンサの位置

加速・合流 定速・合流 約1秒車間区間(※2): 区間(※3): @100km/h
34.7m
27.8m
46.4m

加速区間(※1)：
173.9m※Aの合流予定位置

225.0m100.0m

スポットセンサの位置条件（100km/h×8.1秒）

合流禁止区間

55.6m
2秒車間@100km/h※1: 40→90.7km/h、0.15G、9.58秒間※2： 90.7→100km/h、0.15G、1.75秒間※3: 100km/h、1.25秒間

図 2.4.1.3-1 想定する道路と通信エリアの関係

NOTE: 通信エリアで所要通信品質を満足するにあたり、一つのアンテナで実現するか、複数のアンテナによりアンテナダイバーシチを適用するかは無線方式および実装時依存である。
2.4.1.4 車両 ID と車載器 ID の紐付け
ユースケース a-1-1 では、車載器 ID が取得できないため、路側インフラの割り当てる車両 ID の
みとなる。

―16―

ITS FORUM RC-017
2.4.1.5 メッセージ送受信シーケンス
合流・車線変更支援の共通シーケンスとなるので、ユースケース a-1-3（2.4.3.5 項）へ記載する。
2.4.1.6 通信内容
合流・車線変更支援の共通シーケンスとなるので、ユースケース a-1-3（2.4.3.6 項）へ記載する。
2.4.1.7 想定される報知車両数
位置情報メッセージの 1 メッセージあたりの報知車両数は、スポットセンサの位置や本線の走行速度によって大きく変化する。
モデル 1 の道路条件に対して乗用車（5m）を配置した場合の走行速度と車両検知数及び情報提供
期間から、1 車線あたりの報知車両数を計算した結果を表 2.4.1.7-1 に記す。ただし、報知車両数を想定するため、モデル 1 の計測範囲に合流禁止区間を含めた距離で検知車両を試算する。
表 2.4.1.7-1 本線走行速度と報知車両数及び情報提供期間の関係

本線走行速度

報知車両数

情報提供期間@1 秒車間@2 秒車間110 km/h

9～10 台5～ 6 台10.5 秒

100 km/h

10～11 台5～ 6 台11.6 秒80 km/h11～12 台6～ 7 台14.5 秒60 km/h14～15 台8～ 9 台19.3 秒40 km/h20～21 台11～12 台29.0 秒30 km/h24～25 台14～15 台38.7 秒

20 km/h30～31 台19～20 台58.0 秒（スポット計測位置：222.2m に合流禁止区間：100m を加えた条件で試算）
モデル 1 の道路条件にて、ユースケース a-1-1 で想定される報知車両数は 31 台となる。また、本線走行速度が 60km/h を境に、報知車両数と情報提供期間が増加するのが分かる。
下流の渋滞などで全車両が 20km/h に満たない速度まで低下する様なケースにおいては、最大検知車両数がさらに増加し、乗用車：5m、車間距離：2m で配置した場合は 46 台となる。
なお、スポット計測特有の懸念事項として、計測時の速度と合流起点での速度差による合流位置のズレが想定される（別添 2B 参照）。

―17―

ITS FORUM RC-017
2.4.2

ユースケース a-1-2. 本線隙間狙い合流支援

ユースケース a-1-2 は、本線を面的に計測するセンサを設置し、本線を走行する車両の位置や速度等を連絡路の協調走行車へ配信して、協調走行車が合流を予定している車間（隙間）に対する速度調整を行うための判断材料として活用する。
2.4.2.1 想定する通信シナリオ
本線隙間狙い合流支援で想定するシナリオは以下の通り①

路側インフラは一定周期で、計測時刻、速度、車長、到達予測時刻を含む位置情報メッセージを送信する。連絡路を走行する自車は、通信エリアへ侵入すると、位置情報メッセージを受信する。

②

自車は、受信した（合流起点への）到達予測時間から合流予定場所と時刻の判断や、走行計画の見直しなどを行う。

③

自律走行での合流が可能と判断した自車は、一定周期で更新される位置情報メッセージによって自車の走行計画を更新しながら合流起点に向かって法定速度内での予備加減速が行われる。

④

合流起点を通過した自車は、予定していた合流開始位置へ向かって加速を開始する。

（加速中に通信エリアを通過すると共に、自車の自律センサ情報が反映され、合流場所の決定と加減速制御が行われる。）
2.4.2.2 想定される計測範囲の検討
ユースケース a-1-2 における計測センサ（面的センサとする）は面的な計測であり、ユースケー
ス a-1-1.の上位互換となる。
計測する対象車線は、本線の混雑状況や車線変更の可能性を把握するためにも、流入路のみだけ
ではなく本線の全てのレーン情報を提供するのが理想である。なお、面的センサの検知能力が不足する場合、最低でも流入路と、流入路に隣接する（流入路への車線変更の可能性がある）本線の情報提供が必要と考える。
計測する車線方向の計測範囲は、ユースケース a-1-1 におけるスポット計測位置から合流起点までの区間における情報を提供するのが理想である。しかしながら面的センサの検知能力と本線の車両速度によっては計測範囲が不足する可能性がある。例えば、面的センサの検知範囲が 200m の場
合、表 2.4.2.2-1 は法定速度:100km/h 以上、表 2.4.2.2-2 は法定速度:80km/h 以上になると検知範囲が不足することになる。

―18―

ITS FORUM RC-017
表 2.4.2.2-1 本線の法定速度と面的センサの検知範囲の関係（モデル 1）

法定速度
（本線）

理想的な検知範囲（合流起点から上流）

計測範囲：200m 時の検知範囲（合流起点から上流）120km/h

270.0m ～ 0m

270.0m ～ 70.0m（70.0m 不足）

100km/h

225.0m ～ 0m

225.0m ～ 25.0m（25.0m 不足）

80km/h

180.0m ～ 0m

180.0m ～ -20.0m

60km/h

135.0m ～ 0m

135.0m ～ -65.0m

50km/h

112.5m ～ 0m

112.5m ～ -87.5m

表 2.4.2.2-2 本線の法定速度と面的センサの検知範囲の関係（モデル 2）

法定速度
（本線）

理想的な検知範囲（合流起点から上流）

計測範囲：200m 時の検知範囲（合流起点から上流）

80km/h212.9m ～ 0m

212.9m ～ 12.9m（12.9m 不足）

60km/h159.7m ～ 0m

222.2m ～ -40.3m

50km/h133.1m ～ 0m

133.1m ～ -66.9m

検知範囲が不足する対策として、計測するセンサを追加して検知範囲を補う方法もあるが、検知外の位置情報を予測位置情報として混在して配信する方法も考えられる。予測位置情報を配信する
場合、センサで実測した情報なのか、予測情報なのかを車両側で判別できる情報として配信する必要がある。
ユースケース a-1-2 の配信目的は本線隙間狙い合流支援なので、速度調整で重要となる合流起点に近い場所で計測精度がある程度とれるような計測センサの設置場所が望ましいが、上流から下流方向へ向けて計測センサを設置した場合や路側帯から計測した場合などでは、本線の混雑度や計測対象範囲によっては車両遮蔽によって必要な計測精度がとれないことがありうるため、位置情報取得時刻が混在しても情報提供が成立するメッセージにする必要がある。
2.4.2.3 必要な通信エリアの条件
ユースケース a-1-2 で位置情報メッセージに必要な通信エリアは、上流側はユースケース a-1-1（2.4.1.3 項）と同様に（連絡路の法定速度：40km/h）× 6.1 秒に対応する距離分上流にある地点周辺とし、下流側は合流起点まで（合流起点以降は自律センサで行われる）とする。配信に必要な区間（通信エリア）を表 2.4.2.3-1 に記す。
ユースケース a-1-2 の通信エリアは、ユースケース a-1-3 と同様に本線への通信エリアが含まれてもユースケース a-1-2 としての通信に影響ないメッセージにする。

―19―

ITS FORUM RC-017
表 2.4.2.3-1 連絡路の法定速度と必要な通信エリアの関係

法定速度
（連絡路）

a-1-2 に必要な通信エリア（合流起点から上流距離）

40km/h67.8m （67.8m ～ 0m）

想定する道路条件へ、スポット計測位置、必要な通信エリアを配置すると図 2.4.2.3-1 の位置関係となる。

：センサで計測された、位置情報の配信対象車両（必須：7台）：センサで計測された、位置情報の配信対象車両（オプション：10台）：車線変更中の車両（5台）：a-1-2.通信に関与しない車両

想定される配信エリア（加速レーン起点6.1秒手前@40km～6秒手前@20km/h）
合流起点

合流完了位置（合流車線長終端）

255.0m（合流車線長）合流開始位置(合流車線長終端の3秒手前）※A
加速レーン起点5秒前
センサの計測範囲※Aの合流予定位置

約1秒車間
加速・合流 定速・合流@100km/h
区間(※2): 区間(※3):
34.7m
46.4m
27.8m

加速区間(※1)：
173.9m

：必須：オプション

55.6m
2秒車間@100km/h

225.0mセンサの計測範囲（100km/h×8秒）※1: 40→90.7km/h、0.15G、9.58秒間※2: 90.7→100km/h、0.15G、1.75秒間※3: 100km/h、1.25秒間

図 2.4.2.3-1 想定する道路と必要な通信エリアの関係

NOTE: 通信エリアで所要通信品質を満足するにあたり、一つのアンテナで実現するか、複数のアンテナによりアンテナダイバーシチを適用するかは無線方式および実装時依存である。
2.4.2.4 車両 ID と車載器 ID の紐付け
ユースケース a-1-2 は、ユースケース a-1-1 と同じく車載器 ID が取得できないため、路側インフ
ラの割り当てる車両 ID のみとなる。
2.4.2.5 メッセージ送受信シーケンス
合流・車線変更支援の共通シーケンスとなるので、ユースケース a-1-3（2.4.3.5 項）へ記載する。
2.4.2.6 通信内容
合流・車線変更支援の共通シーケンスとなるので、ユースケース a-1-3（2.4.3.6 項）へ記載する。
2.4.2.7 想定される報知車両数
位置情報メッセージの 1 メッセージあたりの報知車両数は、ユースケース a-1-1（2.4.1.7 項）で検討した報知車両数（流入路の 1 車線）に対して、流入路に隣接する本線を加えた値となる。1 車―20―

ITS FORUM RC-017
線あたりの車両数は 31 台なので、報知車両数は 2 車線で 62 台、3 車線で 93 台（理想的な条件として最大 6 車線の検知が可能であれば 186 台）となる。
また、下流の渋滞などで全車両が 20km/h に満たない速度まで低下する様なケースにおいては、
最大検知車両数が増加する。仮に、対象となる本線で渋滞が生じた状況として、乗用車：5m、車間距離：2m で配置した場合、1 車線あたりの車両数は 46 台となるので、報知車両数は 2 車線で 92
台、3 車線で 138 台、6 車線で 276 台となる。
なお、無線容量の不足により全車両の通知ができない場合は、対象車両を限定する必要がある（例
えば、より下流に位置する車両の情報を優先するなどが考えられる）。

―21―

ITS FORUM RC-017
2.4.3

ユースケース a-1-3. 路側管制による本線車両協調合流支援

ユースケース a-1-3 は、管制範囲内を走行する各車両の速度と位置を、計測センサおよび協調走
行車から情報を得て走行状況を把握し、本線および連絡路に対して情報提供すると共に、管制に応じる協調走行車に対して走行目標を指示する。
なお、2.2 節で説明した通り、通信シーケンスを位置情報提供と路側管制に切り分けるため、本項では位置情報提供についての検討結果をまとめる（路側管制については、2.5.1 節参照）。
2.4.3.1 想定する通信シナリオ
ユースケース a-1-3 の位置情報提供で想定されるシナリオは、ユースケース a-1-2 （2.4.2.1 節参照）と同様となる。ただし、通信エリア内で路側管制の通信シーケンスが実施される点が、ユース
ケース a-1-2 とは異なる（路側管制については 2.2 節参照）。
2.4.3.2 想定される計測範囲の検討
ユースケース a-1-3 は路側管制による本線車両協調合流支援のため、本線に加えて連絡路を走行する車両の情報も路側インフラが把握する必要がある。
ただし、連絡路を走行する車両が全て協調走行車である場合は、路側インフラから連絡路を走行する車両に対して路車間通信を使って位置情報を取得可能(路側インフラから要求を出し、車両が位置情報を送信する想定)なので、計測範囲はユースケース a-1-2 と同じとなる(2.4.2.2 参照)。
なお、ユースケース a-1-3 は路側管制となるため、流入路への車線変更を抑制する以外に、流入路から隣接する本線（隣接車線）への車線変更の誘導や、隣接車線の車両を流入路と反対車線（隣々接車線）へ車線変更を誘導する必要も生じるため、最低でも隣々接車線までの 3 車線分の検知が必要と考える。
2.4.3.3 必要な通信エリアの条件
ユースケース a-1-3 で位置情報メッセージに必要な通信エリアは、路側管制を行う範囲となるので 2.4.2.3 項の通信エリアに加えて、本線の管制範囲に対する通信エリアが必要となる。
また、路側管制による本線車両協調合流支援が目的のため、合流完了まで路側管制することが望
ましいが、合流起点以降は自律センサによる合流を想定して通信エリアの管制対象外とみなすと、想定する道路条件へ必要な通信エリアを配置した場合、図 2.4.3.3-1 の位置関係となる。

―22―

ITS FORUM RC-017：センサで計測された、位置情報の配信対象車両：計測範囲を通過した本線走行車両

本線および連絡路側の通信エリア（連絡路：合流起点6.1秒手前～合流起点、
本線：合流起点8.1秒手前～合流起点）：車線変更行動中の車両：通信に関与しない車両

※A
合流起点

合流起点5秒前※Aの合流予定位置

225.0m（100km/h×8.1秒）

図 2.4.3.3-1 想定する道路と必要な通信エリアの関係

なお、図 2.4.3.3-1 では、本線と連絡路を１つの通信エリアで示しているが、道路や設置環境により 1 つの連続した通信エリアを形成することが困難な場合や、周辺に設置された他の路側アンテナとの干渉回避のためアンテナ指向性へ制限を設ける場合など、本線と連絡路が個別の通信エリアとなっても、共通の情報が送信される条件で検討を進める。

NOTE: 通信エリアで所要通信品質を満足するにあたり、一つのアンテナで実現するか、複数のアンテナによりアンテナダイバーシチを適用するかは無線方式および実装時依存である。
2.4.3.4 車両 ID と車載器 ID の紐付け
路側インフラの割り当てる車両 ID は、各車両の車載器 ID を考慮せずに、異なる時間で送信される位置情報メッセージ間で、路側インフラが同一と想定する車両に、共通の車両 ID を付与する。管制のシーケンスにおいて、合流車や受入/応答車は、車載器 ID を含んだメッセージを送信するので、路側インフラは車載器 ID を把握することができる。位置情報メッセージと管制のシーケンスにおいて、車両 ID と車載器 ID の紐づけに関して以下の方法がある。
方法 1: 路側インフラは、位置情報メッセージでは、車両 ID のみを送信し、管制のシーケンス
では、車載器 ID のみを送信する。
方法 2: 路側インフラは、位置情報メッセージでは、車載器 ID が入手できた場合は、車両 IDと車載器 ID の両方をペアにして送信し、管制のシーケンスでは車載器 ID を送信する。
方法 3: 路側インフラは、位置情報メッセージでは、車両 ID のみを送信し、管制のシーケンス
では、車両 ID と車載器 ID の両方をペアにして送信する。
管制のシーケンスという観点からは、方法 1 のみでも動作させることは可能である。方法 2 は、管制のシーケンスを受信する必要なく、路側インフラがどの車両を把握しているかが位置情報メッ―23―

ITS FORUM RC-017
セージから把握することができる。方法 3 は、位置情報メッセージサイズを抑えつつ、路側インフ
ラが位置情報メッセージのどの車両を把握しているかが管制のシーケンスから把握することができる。
位置情報メッセージは、周期的なメッセージなので無線容量の利用という観点からは、方式 2 が無線容量の利用を増やすことになる。
位置情報メッセージでは、時々刻々と変化しうる合流起点到達予定時刻を周期的に通知することで、路側インフラの想定する車両間の相対関係も通知することができる。管制/合意の通信シーケンスに関わった本線の受入/応答車は、方式 2 もしくは 3 を用いることで、自車の本線の車群のなかでの路側インフラの想定する相対位置関係と合流起点到達予定時刻を考慮して本線を走行することができるようになる。ユースケース a-1-3 の連絡路の要求車も、連絡路の走行であっても、位置情報メッ
セージの中に、路側インフラの想定する相対位置関係と合流起点到達予定時刻を含めて通知することで、連絡路の要求車は、本線の車群のなかでの路側インフラの想定する相対位置関係と合流起点
到達予定時刻を考慮して連絡路を走行し、本線の車両は、連絡路の要求車の進入を想定した走行ができるようになる。これらのメリットから方式 2 もしくは 3 をさらに検討する必要がある。
位置情報メッセージで、実際に本線を走行している実車両と、実際には連絡路を走行しているが仮想的に路側インフラが想定する相対位置関係と合流起点到達予定時刻を通知する車両との区別方
法として、通知される車両が、実車両なのか仮想車両なのかを通知する方法としては、以下の候補がある。
区別方法 1: 実車両もしくは仮想車両であるかの識別フラグを別途の情報要素として、用意する。
区別方法 2: 実車両もしくは仮想車両であるかの識別を走行車線の情報要素のなかで、仮想車両を示す走行車線を定義することで、識別する。
区別方法 3: 走行車線が、本線を実車両とし、走行車線が連絡路を仮想車両とする。

―24―

ITS FORUM RC-017
2.4.3.5 メッセージ送受信シーケンス
ユースケース a-1-3 で位置情報の提供に想定されるメッセージ送受信シーケンスを図 2.4.3.5-1 に
記す。
計測センサ

協調走行車

路側インフラ（スポット計測）

計測結果（計測なし）（流入路、連絡路）

1.位置情報メッセージ（計測なし）

2.計測結果（車両 A 情報：計測時刻、速度、車長）

100ms 周期で送信
3.位置情報メッセージ（車両 A 情報＋車両 A 到達予測時刻）

計測結果（計測なし）

3a.位置情報メッセージ（車両 A 情報＋車両 A 到達予測時刻）

4.計測結果（車両 B 情報：計測時刻、速度、車長）

5.位置情報メッセージ（車両 A 情報＋車両 A 到達予測時刻＋車両 B 情報＋車両 B 到達予測時刻）

5a.位置情報メッセージ

計測結果（計測なし）（車両 A 情報＋車両 A 到達予測時刻＋車両 B 情報＋車両 B 到達予測時刻）（車両 A の到達予測時刻を経過）

計測結果（計測なし）

6.位置情報メッセージ（車両 B 情報＋車両 B 到達予測時刻）

図 2.4.3.5-1 ユースケース a-1-3 での位置情報メッセージ送受信シーケンス（上記シーケンスは、計測センサおよび路側インフラで生じる処理遅延を含めていない）

NOTE: 計測センサと路側インフラ間の破線は、計測センサの正常動作を通知するために、計測なしを通知する場合を示す。計測センサの正常動作が通知できればそれ以外の方法でも問題ない。
1. 路側インフラは、計測センサからの計測結果（計測時刻、速度、車長）の有無に関わらず、100ms 周期で位置情報メッセージを本線および連絡路へ送信する（計測結果なしの場合は、計測結果なしを送信する）。
2. 計測センサで車両 A を検知すると、路側インフラへ計測結果（車両 A 情報）を提供す―25―

ITS FORUM RC-017
る。路側インフラでは、提供された車両 A 情報に対して車両 ID を付与すると共に、ユー
スケース a-1-1 の上位互換となる車両 A の到達予測時刻を計算する。
3. 周期的な送信において、計測センサからの情報および到着予測時刻をもとに、路側イン
フラは、位置情報メッセージを送信する。
3a. ユースケース a-1-1 で使用するスポット計測センサでは新たな計測結果の提供がなければ、車両 A の到達予測時刻を経過するまで 3 と同じ位置情報メッセージを繰り返し送信する。ユースケース a-1-2 と a-1-3 で使われる面的センサであれば、車両 A の更新情報が提供されるまでの間は 3 と同じ位置情報メッセージを送信するか、予測位置情報が推定可能な路側インフラでは送信時刻における予測位置を更新した位置情報メッセー
ジを送信する。
4. 計測センサで車両 B を検知すると、路側インフラへ計測結果（車両 B 情報）を提供する。路側インフラでは提供された車両 B 情報から、車両 B の到達予測時刻を計算する。
5. 路側インフラは、ユースケース a-1-3 として車両 A と車両 B の位置情報メッセージを送信する。
5a. 計測センサから新たな計測結果の提供がなければ、3a と同様な通信シーケンスを実行する。
6. 路側インフラは、車両 A の到達予測時刻を経過するとユースケース a-1-3 として、車両B の位置情報メッセージのみに切替えて送信する。

―26―

ITS FORUM RC-017
2.4.3.6 通信内容
位置情報の提供で想定される通信内容を表 2.4.3.6-1 に記す（情報要素と内容については付録 1 参照）。
表 2.4.3.6-1 位置情報メッセージ内容

情報要素

共
通
情
報

(

位
置
情
報
走
行
車
両
数
で
変
動

データサイズ ※1)

ユースケース a-1-1

ユースケース a-1-2

ユースケース a-1-3

メッセージ ID
インクリメント ID
または情報更新時刻

16 bit16 bit16 bit32 bit32 bit32 bit

路側管制情報

8 bit

8 bit

8 bit

路側機 ID

32 bit32 bit32 bit合流起点情報16 bit16 bit16 bit

道路番号

32 bit32 bit32 bit

走行車両数

8 bit

8 bit

8 bit

車両 ID

16 bit16 bit16 bit

車両位置（緯度経度高度）―

88 bit88 bit

走行車線

8 bit

8 bit

8 bit

走行速度

16 bit16 bit16 bit

車両長さ

14 bit(+空 2 bit)

14 bit(+空 2 bit)

14 bit(+空 2 bit)

合流起点到達予定時刻

32 bit32 bit32 bitセンサ情報取得時刻 ※2

32 bit32 bit32 bit

情報信頼度 ※2

8 bit

8 bit

8 bit

※1 無線通信ではオーバヘッドを別途追加する必要がある。
※2 設置されるセンサの種類によって、取得周期や得られる位置精度が異なる場合を考慮した情報要素や、計測した位置情報と予測位置情報を区別するための情報を付与する。

―27―

ITS FORUM RC-017
提供する位置情報として実測と予測の使い分けについては、以下の方法について今後の検討が必要となる。
方法 1. 一台ごとの位置情報のうち、車両位置、走行車線、走行速度のいずれもメッセージ
送信時の予測時刻で提供し、センサ情報取得時刻は、実データ測定時の時刻とする。
合流起点到達予定時刻は、センサ情報取得時刻からの予測時刻とする。
方法 2. 一台ごとの位置情報のうち、車両位置、走行車線、走行速度のいずれも実測時のメッセージで提供し、センサ情報取得時刻は、実データ測定時の時刻とする。
合流起点到達予定時刻は、センサ情報取得時刻からの予測時刻とする。
方法 3. 一台ごとの位置情報のうち、車両位置、走行車線が実測時、走行速度を予測のメッセージで提供し、センサ情報取得時刻は、実データ測定時の時刻とする。
走行速度は、V2X 非搭載車を含む周辺車両の状況から推定値（予測）される速度とする。
合流起点到達予定時刻は、走行速度とセンサ情報取得時刻からの予測時刻とする。
方法 4. 一台ごとの位置情報のうち、車両位置、走行車線、走行速度は、実測か予測のどちらかを伝えているかも含めてメッセージで提供し、センサ情報取得時刻は、実データ測定時の時刻とする。
合流起点到達予定時刻は、走行速度とセンサ情報取得時刻からの予測時刻とする。
上記の方法 1、2、3、4 は以下の表としてまとめられる。
表 2.4.3.6-2 実測と予測の使い分け方法

提供情報

方法 1

方法 2

方法 3

方式 4

車両位置

予測

実測

実測

実測か予測を選択して通知

走行車線

予測

実測

実測

実測か予測を選択して通知

走行速度

予測

実測

予測

実測か予測を選択して通知

センサ情報取得時刻

実測

実測

実測

実測

合流遅延到達予定時刻

予測

予測

予測

予測

なお、計測センサから路側インフラへの検知車両数の提供方法やアルゴリズムに関しては本書の適用外のため規定しない。

―28―

ITS FORUM RC-017
2.4.3.7 想定される報知車両数
情報提供が必要な 1 メッセージあたりの報知車両数は、表 2.4.1.7-1 の通り本線速度 20km/h、1秒車間で、1 車線あたり 31 台なので、受入路、隣接車線、隣々接車線の合計 3 車線の提供で 93 台
（理想的な条件として最大 6 車線の検知が可能であれば 186 台）となる。ただし、位置情報メッセー
ジとして合流車に関する情報（路側インフラが想定する合流車の合流起点到達予測時刻）を加える
場合、合流路の情報を追加する必要があり、1 車線あたり本線と同等の 31 台、連絡路が 2 車線とした場合、62 台を追加して 248 台となる。
また、渋滞により静止している場合、路側管制を行うため管制範囲内の全ての車両位置情報を把握する必要があり、乗用車：5m、車間距離を 2m で配置した場合の 1 車線あたりの車両数は 46 台
（3 車線で 138 台、6 車線で 276 台、さらに 2 車線の連絡路を含めた 8 車線で 368 台）となる。

―29―

ITS FORUM RC-017
2.5 管制/合意のユースケース
2.5.1

ユースケース a-1-3. 路側管制による本線車両協調合流支援

ユースケース a-1-3 の路側管制では、路側インフラより本線および連絡路を走行する協調走行車に対して管制要求を行うと共に、走行目標を指示する。
なお、2.2 節で説明した通り、通信シーケンスを位置情報提供と路側管制に切り分けるため、本項では路側管制についての検討結果をまとめる（位置情報提供については、2.4.3 節参照）。
2.5.1.1 想定する通信シナリオ
ユースケース a-1-3 の路側管制で想定されるシナリオは以下の通りとなる。
なお、連絡路を走行する車両は全て協調走行車とみなし、位置情報が入手できる前提とする。
①

連絡路を走行する自車は、位置情報メッセージを受信して条件を満たした場合に、管制要求メッ
セージを送信する。

②

路側インフラは、路側インフラの判断で連絡路および流入路を走行する車両に対して調定要求
メッセージを送信する。

③

連絡路を走行する自車は、調定要求メッセージおよび位置情報メッセージの受信を継続する。
調定要求メッセージを受信した本線の協調走行車は、車載器 ID と合流の受け入れ可否を応答する調定応答メッセージを送信する。

④

路側インフラは、適切な車両の車載器 ID と共に合意のための更新要求メッセージを路側管制が必要な複数の車両に対して送信する。

⑤

管制対象の協調走行車は、自車の車載器 ID が更新要求メッセージ内の車載器 ID と一致する場
合、合流のための制御を開始すると共に、路側インフラに対して更新応答メッセージで合意の応答を送信する。

⑥

路側インフラは、管制不要と判断するまで更新要求メッセージと更新応答メッセージの繰り返
しが一定周期で行われる。

2.5.1.2 想定される管制範囲と通信エリアの検討
ユースケース a-1-3 の路側管制範囲を行うためには 2.4.3.3 項の通信エリアに加えて、図 2.3.1-1の合流起点から合流終点までを含めた範囲を管制できるのが理想となるが、本項では、合流起点以降は自律走行での合流が可能とみなし 2.4.3.3 項に準じた範囲とする。

―30―

ITS FORUM RC-017
2.5.1.3 メッセージ送受信シーケンス
ユースケース a-1-3 の管制要求で想定されるメッセージ送受信シーケンスは、以下の 3 組のメッセージの組み合わせを用いて実現される。

位置情報メッセージと管制要求メッセージ
要求車

路側インフラ（連絡路）

受入/応答車（流入路)

1.位置情報メッセージ
2.管制要求メッセージ

図 2.5.1.3-1 位置情報と管制要求メッセージ 送受信シーケンス

1. 路側インフラは、ユースケース a-1-1、a-1-2 と同様に位置情報メッセージを送信する。ユー
スケース a-1-1、a-1-2 と異なっている点は、路側管制情報において、管制要求メッセージを受け付けることを示す。
2. 連絡路を走行する自車（要求車）は、位置情報メッセージを受信し、以下の条件 a, b を満たしており、かつ、自車の判断で、管制要求メッセージを送信する。
a. 路側インフラからの位置情報メッセージで管制要求受付をする旨が報知。
b. 自車が路側管制対象の合流路の特定地点（自車が路側管制対象の合流路で、合流起点の 5.9 秒前の位置）に位置すると判断。

NOTE: 要求車が、管制要求メッセージに対する応答を受信できない場合、路側インフラが受信できなかったとみなして、要求車が必要と考えるならば管制要求メッセージを再送信する。何を管制要求メッセージに対する応答とみなすかについて、以下があり検討中である。
・ 応答案 A：受入車の合意の確認後に送信する更新要求メッセージを要求メッセージに対する応答とする。合意を確認するシーケンスに要する時間を想定した時間の後で、更新要
求メッセージを再送するので、管制要求メッセージが路側インフラで受信できなかった
場合の遅延が大きい。
・ 応答案 B：受入車の合意に関わらず、要求車の車載器 ID を含んだ位置情報メッセージを管制要求メッセージに対する応答とする。位置情報メッセージの情報量が増加する。
・ 応答案 C：受入車の合意に関わらず、本線の受入／応答車への調定要求メッセージ中の連絡路の要求車の車載器 ID を確認して、管制要求メッセージに対する応答とする。本線の―31―

ITS FORUM RC-017

受入／応答車への調定要求メッセージが、本線・連絡路に同様に送信することを想定する。管制要求メッセージに対して調定要求メッセージを送信するという関連付けが必要となる。
・ 応答案 D：受入車の合意に関わらず、要求車の車載器 ID を含んだ新規に定義する管制応

答メッセージを管制要求メッセージに対する応答とする。管制応答メッセージを新規に規定する必要がある。
その他に、管制要求メッセージを再要求する条件（応答待ち時間、下記に記した様な再送条件）について、さらに検討が必要である。
・路側インフラが同一要求車からの複数の管制要求メッセージを受信した場合の動作
・路側インフラが異なった要求車からの複数の管制要求メッセージを受信した場合の動作・周辺車両が同一要求車に関する複数の管制要求メッセージを受信した場合の動作・周辺車両が異なった要求車に関する複数の管制要求メッセージを受信した場合の動作・要求車両が同一要求車に関する複数の管制要求メッセージを受信した場合の動作・要求車両が異なった要求車に関する複数の管制要求メッセージを受信した場合の動作
調定要求メッセージと調定応答メッセージ
要求車

路側インフラ

受入/応答車1.調定要求メッセージ
2.調定応答メッセージ

図 2.5.1.3-2 調定要求と調定応答メッセージ 送受信シーケンス

1. 路側インフラは、調定要求メッセージを送信する。調定要求メッセージは、どの位置の車両が調定応答メッセージを送信するかという場所情報を含む。
2. 調定要求メッセージを受信した車両は、以下の条件 a を満たしており、かつ、自車の判断で、調定応答メッセージを送信する。
a.自車の現在位置と、どの位置の車両が調定応答メッセージを送信するかという場所
情報が、一致すると判断。
調定応答メッセージは、“ユニーク ID となる車載器 ID”と“自車の位置情報および当該周辺車両が決定した合意に応じられるかの意図”を含む―32―

ITS FORUM RC-017
更新要求メッセージと更新応答メッセージ
要求車

受入/応答車路側インフラ

1.更新要求メッセージ
2.更新応答メッセージ

図 2.5.1.3-3 更新要求と更新応答メッセージ 送受信シーケンス

1. 路側インフラは、更新要求メッセージを送信する。更新要求メッセージは、路側インフラが受入車と判断した車載器 ID を含む。
2. 更新要求メッセージを受信した車両は、以下の条件 a を満たしており、かつ、自車の判断で、更新応答メッセージを送信する。
a. 自車の車載器 ID が更新要求メッセージ内の車載器 ID と一致する
更新応答メッセージは、路側インフラに対する合意可否を含む。合意可否の判断は、車両の判断となるが、一例として“自車の現在位置と照合して要求範囲内かどうか”が考えられる。

NOTE: 連絡路の要求車に対しても、更新要求メッセージと更新応答メッセージを用いるのかは、今後検討予定である。
・2.4.3.4 項の方法 1 または前述の応答案 A では、更新要求メッセージを要求メッセージに対する応答とし、本線の協調走行車に対して要求車の位置情報を提供する目的で、更新要求メッセージを用いる。連絡路の要求車は、更新要求メッセージが得られないと判断した場合などの協調走行不要と判断した場合は、路側インフラに対して管制終了もしくは、“合意終了”として更新応答メッセージを送信し、位置情報メッセージと自律走行で合流可能な場所を推定した制御を行うことを想定する。なお、要求車が要求範囲外へ移動した
場合や、緊急事態などで更新要求メッセージに対して合意できないと車両が判断した場合における応答要否については検討が必要である。
・2.4.3.4 項の方法 2 および 3 では、連絡路の要求車は、位置情報メッセージの中で、路側インフラの想定する各車両の位置情報と合流起点到達予定時刻を含めて通知されているので、本ステップでの要求車に対しての更新要求メッセージは、不要である。

―33―

ITS FORUM RC-017
路側インフラでの位置情報メッセージ、調定要求メッセージの送信方法
路側インフラが、位置情報メッセージと調定要求メッセージをどのように発行するかは、路側イ
ンフラの実装依存となる。実装例を以下に示す。
・位置情報メッセージを周期的に送信する。連絡路からの要求車からの管制要求メッセージがあったときのみ、調定要求メッセージを送信する。調停要求メッセージ内の“返信要求範囲”には、ある程度の大きさの範囲が指定され、該当範囲の複数台の本線車両から同時に調定応答メッ
セージを受信する。
・位置情報メッセージを周期的に送信する。調停要求メッセージも周期的に送信する。二つのメッ
セージの送信周期は同じである必要はない。調停要求メッセージ内の“返信要求範囲”には比較的狭い範囲が指定され、該当場所を通過した 1 台の本線車両から調定応答メッセージを受信する。
この場合、複数台の本線車両から、同時に調定応答メッセージを受信することは発生しにくい。
・連絡路にあるセンサ情報などをもとに、連絡路からの要求車からの管制要求メッセージに依存
せずに、調定要求メッセージを送信する。

路側インフラでの更新要求メッセージの送信方法
路側インフラが、どの車両を対象とし、どのように更新要求メッセージを発行するかは、路側イ
ンフラの実装依存となるが、実装例を以下に示す。
・周辺車両からの調定応答メッセージを受信して要求車が合流する場所を決定し、合流車の後方に位置する予定の車両に対して、更新要求メッセージを発行する。
・対象車両から更新応答メッセージが得られない場合には、再送するか、他の車両を受入車と想定する。
・路側インフラが有する位置情報にて、合流車の受入場所が見当たらず、受入路から隣接する本線への車線変更の管制が必要な場合は、隣接車線に対しても調定要求メッセージや更新要求メッ
セージを送信する。
・路側インフラは、以下の条件を満たすまで更新要求メッセージを繰り返し送信する。繰り返し
送信周期は仮に 100ms とする。
・路側インフラが管制不要と判断する・要求車が管制エリアを通過したと判断する
・要求車または受入車からの管制終了の通知を受信する―34―

ITS FORUM RC-017
ユースケース a-1-3 の管制を実現する一例
連絡路から一台の要求車が進入し、流入路において一台の受入/応答車が反応するケースを記載する。連絡路の要求車に対して、更新要求メッセージと更新応答メッセージを用いる案と位置情報メッ
セージを用いる案の 2 案をそれぞれ実現例 1 および実現例 2 として記載している。複数の要求車および受入/応答車が存在するときは、位置情報メッセージ、調定要求メッセージ、更新要求メッセー
ジを、路側インフラが組み合わせて発行することで実現する。

要求車

受入/応答車路側インフラ

（連絡路）

（流入路）

位置情報メッセージ
管制要求メッセージ
調定要求メッセージ
調定応答メッセージ
更新要求メッセージ
更新応答メッセージ
更新要求メッセージ
更新応答メッセージ
更新要求メッセージ
更新要求メッセージ
更新応答メッセージ
更新応答メッセージ（要求車が管制エリアを経過）

図 2.5.1.3-4 ユースケース a-1-3 の管制要求の実現例 1―35―

ITS FORUM RC-017

要求車

受入/応答車路側インフラ

（連絡路）

（流入路）

位置情報メッセージ
管制要求メッセージ
調定要求メッセージ
調定応答メッセージ
更新要求メッセージ
更新応答メッセージ
位置情報メッセージ

更新要求メッセージ
位置情報メッセージ
更新応答メッセージ

図 2.5.1.3-5 ユースケース a-1-3 の管制要求の実現例 2

2.5.1.4 路側管制で想定されるシーケンス遅延
合流予定の協調走行車が、合流制御を開始するまでに必要となる通信シーケンスとして、2.5.1.3
項の応答案 A（管制要求メッセージ→調定要求メッセージ→調定応答メッセージ→受け入れ車への更新要求メッセージ→受け入れ車からの更新応答メッセージ→合流車への更新要求メッセージまでの連続したシーケンス）で想定される遅延は、走行車両からの調定応答数や走行車両数による路側
インフラの処理能力、更新要求メッセージと更新応答メッセージが 1 回で完了するとは限らない場合が想定されるが、仮に、路側インフラの処理遅延時間を Rt、協調走行車の処理遅延時時間を Vt、
1 回の更新要求メッセージと更新応答メッセージで合意完了するとみなした場合、表 2.5.1.4-1 の通
りとなる。

―36―

ITS FORUM RC-017
表 2.5.1.4-1 位置情報メッセージ受信から合流制御開始までに想定されるシーケンス遅延

時間
[ms]

処理内容
車両が、位置情報メッセージを受信してから管制要求メッセージを送信するまでの処理時間
管制要求メッセージに対する無線区間許容遅延
路側インフラが、管制要求メッセージを受信してから調定要求メッセージを送信するまでの処理時間
調定要求メッセージに対する無線区間処理遅延
各車両が、調整要求メッセージを受信してから調定応答メッセージを送信するまでの処理時間
調定応答メッセージに対する無線区間処理遅延
路側インフラが、調定応答メッセージを受信してから受入車に対して更新要求
メッセージを送信するまでの処理時間
更新要求メッセージに対する無線区間処理遅延
受入車が、更新要求メッセージを受信してから更新応答メッセージを送信するまでの処理時間
更新応答メッセージに対する無線区間処理遅延
路側インフラが、受入車からの更新応答メッセージを受信してから要求車へ更新要求メッセージを送信するまでの処理時間

Vt
At
Rt
At
Vt
At
Rt
At
Vt
At
Rt

更新要求メッセージに対する無線区間処理遅延

At

要求車が、更新要求メッセージの受信から合流制御を開始するまでの処理時間

Vt

表 2.5.1.4-1 で想定される遅延時間は単純に Vt×4＋Rt×3＋At×6［ms］となる。以下において At
を 100ms、Rt、Vt を共に 10ms と仮定した場合は 670ms となる。
また、更新要求メッセージと更新応答メッセージが 1 回のシーケンスで完了せず、2 回繰り返した場合、Vt＋Rt＋At×2＝220［ms］が加算され 890ms、さらに複数の車両に対する管制が必要とな
り、Rt、Vt を共に 50ms と仮定した場合は 950ms となる。
このため、表 2.5.1.4-1 の Rt、Vt、At で想定される遅延時間の設定と、更新要求メッセージと更新応答メッセージの繰り返し回数の想定によって、路側管制時の通信エリアを見直すかは、採用する通信方式によって、今後の検討が必要である。
合流予定の協調走行車が、合流制御を開始するまでに必要となる通信シーケンスとして 2.5.1.3 項の応答案 B、C、D を適用する場合、管制要求メッセージへの合流車への応答を、受入車に対する調停完了を待たずに行うので、遅延時間としては、管制要求メッセージ→調定要求メッセージ→調定
応答メッセージ→受け入れ車への更新要求メッセージまでのシーケンスにかかる遅延時間を見込めばよいため、Vt×2＋Rt×2＋At×4［ms］となる。

―37―

ITS FORUM RC-017
前述の計算条件と同様に At を 100ms、Rt、Vt を共に 10ms と仮定した場合は 440ms、更新要求
メッセージと更新応答メッセージが 1 回のシーケンスで完了せず、2 回繰り返した場合でも 660msとなる。

NOTE: 応答案 B、C、D において、路側インフラが受入車との合意を得る前に、合流車が合流制御を開始するならば、どのように本線の合流先スペースを確保するかは継続検討。
2.5.1.5 通信内容
管制要求メッセージ、調定要求メッセージ、調定応答メッセージ、更新要求メッセージおよび更新応答メッセージのメッセージ内容を表 2.5.1.5-1 に示す。
表 2.5.1.5-1 管制要求メッセージ、調定要求メッセージ、調定応答メッセージ、更新要求メッセージおよび更新応答メッセージ内容

データサイズ ※1
管制要求メッセージ
調定応答メッセージ
更新応答メッセージ

管制応答メッセージ
調定要求メッセージ
更新要求メッセージ

メッセージ ID

16 bit16 bit

合意応答

8 bit

―

路側機、車載器 ID（自車）

32 bit32 bit道路番号 ※2

32 bit(32 bit)

走行車線 ※2

8 bit( 8 bit)

車載器 ID（通信対象）

32 bit32 bit

情報更新時刻32 bit32 bit

車両位置（緯度経度高度）※2

88 bit(88 bit)

車両速度（目標速度）

16 bit16 bit

車両長さ ※2

14 bit（+空:2 bit）

(14 bit+空:2bit)

返信要求範囲―112 bit

合流先（目標）車線

―

8 bit

16 bit16 bit―16 bit

情報要素

先行車との（目標）車間距離
行動開始予定時間 ※3※1 無線通信ではオーバヘッドを別途追加する必要がある。
また、検討する方式に応じて情報要素を追加する場合がある。
※2 路側インフラは、調定要求と更新要求では送信しない（ユースケース a-1-4、a-2 のみ）。
路側インフラより送信される調定要求および更新要求は、報知されている位置情報で提供済みの情報となるため、道路番号、走行車線、車両位置、車両速度、車両長さの情報提供は不要となる（ユースケース a-1-4 および a-2 では、要求車両側の情報提供が必要）。
※3 管制応答メッセージが必要な場合は、情報要素として追加が必要となる。

―38―

ITS FORUM RC-017
2.5.1.6 想定される送信数と送信頻度
ユースケース a-1-3 で発生する送信数と送信頻度は、路側インフラで管制処理可能な台数や本線を走行する車両密度や速度で大きく変化するため、以下の通りと仮定した。
モデル 1 の道路条件にて、本線を 3 車線として 1 車線あたり 100km/h、2 秒車間で全長：5m の乗用車を配置（1 車線あたりの車両密度：4 台）し、連絡路の車両密度を本線の 1 車線あたりの車両密度と同等（4 台）とみなした場合、2.5.1.2 項の管制範囲に存在する車両は 16 台となる。この時、路側インフラが、合流後の本線における車両密度を平均化するように管制を実施すると想定した場
合に、メッセージを送信する送信ノード数および、１送信ノード当たりの送信頻度を検討する（送信数が最も多くなるケースの例として、合流後に本線における車両密度が平均化されるように管制を実施するケースを想定した）。
合流における各メッセージの送信ノードとしては以下が想定される：-

調停要求メッセージ、更新要求メッセージ：路側インフラ-

更新応答メッセージ：車線変更を実施する車両及び、車線変更してくる車両を前方へ受け入れる車両-

調停応答メッセージ：管制範囲内における上記以外の車両

上記では、車両は自車に該当する更新要求がある場合、更新応答のメッセージを送信して、自車に該当する更新要求のメッセージがない場合は、調定要求に対するメッセージを送信することを想定する。
合流後（4 車線→3 車線）の車両密度を平均化する（合流後は 1 車線あたりの車両密度：5～6 台）
ために車線変更が必要な車両数は、合流路から流入路へ 4 台、流入路から隣接する本線へ 4×2/3 台≒3 台、隣接車線から隣々接車線へ 4×1/3 台≒1 台となる。また、それら車線変更車両を受け入れる
ために管制が実施される車両数は、min(当該車線へ流入してくる車両数、車線変更せずに当該車線を走行し続ける車両数)で求められるため、流入路で 1 台、隣接車線で 3 台、隣々接車線で 1 台となる。これらから更新要求メッセージが送受信される車両数は、13 台として求められ、管制範囲内の残りの 3 台車両は調停応答メッセージを送信する。
路側インフラが 100ms 周期で更新要求、調定要求の順で複数のメッセージを送信し、車両側ではそれに対して応答メッセージを 100ms で 1 回送信するとした場合、100ms あたりに想定される送信数と送信頻度を表 2.5.1.6-1 に記す。
表 2.5.1.6-1 想定される送信数と送信頻度の例

メッセージ種類

調定要求

調定応答

更新要求

更新応答

100ms あたりの送信ノード数

1台

3台

1台

13 台

100ms あたりの 1 送信ノード
の送信頻度

1回

1回

13 回

1回

―39―

ITS FORUM RC-017
なお、走行車両数がさらに増加(混雑)した場合、本線の速度抑制を伴う路側管制が必要になる。
上記と同様にモデル 1 の道路条件（管制範囲：合流起点から 222.2m 上流まで）にて、本線速度を
1 車線あたり 50km/h、1 秒車間で乗用車を配置（1 車線あたりの車両密度：12 台）し、連絡路の車両密度を本線の 1 車線あたりの車両密度と同等（12 台）とみなした場合、2.5.1.2 項の管制範囲に存在する車両は 48 台となる。
この条件では、本線の速度抑制が必要であり、全ての車両に対して更新要求と更新応答を行うことから、想定される送信数と送信頻度を表 2.5.1.6-2 に記す。
表 2.5.1.6-2 想定される送信数と送信頻度の例（混雑時）メッセージ種類

調定要求

調定応答

更新要求

更新応答

100ms あたりの送信ノード数

1台

0台

1台

48 台

100ms あたりの 1 送信ノード
の送信頻度

1回

―

48 回

1回

当然ながら、管制範囲を最大となる本線：6 車線、連絡路：2 車線とみなした場合、調定要求の送信頻度 1 回、更新要求の送信頻度は 96 回、調定応答または更新応答の送信数は 96 台となる。
2.5.1.7 対応ユースケースについて
本ユースケースでは、連絡路を走行する車両は全て協調走行車と想定し、連絡路を走行する要求
車が、路側インフラに対して管制要求メッセージを送信することで、管制/合意のメッセージ送受信
シーケンスが行われる。
V2X 非搭載車の合流支援については、例えば、連絡路にセンサを配置することで、路側インフラ
が V2X 非対応車を検知し、本線車両に対して管制/合意のメッセージ送受信シーケンスを実施できる可能性はあるが検討対象としない。

―40―

ITS FORUM RC-017
2.5.2

ユースケース a-1-4. 車同士のネゴシエーションによる合流支援

ユースケース a-1-4 は、合流路の手前に一時停止のある場合または本線が混雑等によって速度低下しており、路側インフラで管制できない状況で本線へ合流する場合に、関係車両間で相互の走行情報を交換し円滑な合流を行う。
2.5.2.1 想定する通信シナリオ
ユースケース a-1-4 の車同士のネゴシエーションによる合流支援は、ユースケース a-1-3 の管制要求メッセージを除いたシナリオに準じる（詳細は 2.5.2.3 項参照）。
調定要求と調定応答は、本線を走行する車両が少なく自律走行での合流が可能なのか、混雑等によって速度低下したなのかの判断に用いられ、後者の場合のみ更新要求と更新応答が発生するシナリオを考える。
2.5.2.2 想定される通信範囲の検討
ユースケース a-1-4 における通信範囲については、①地域高規格道路にみられる合流開始直前に一時停止のある環境において一時停止（0km/h）で行われる調定要求と調定応答の通信シーケンス、②混雑時の合流前後で行われる調定要求と調定応答の通信シーケンスおよび①と②それぞれのシー
ケンスに続く、➂更新要求と更新応答の通信シーケンスの 3 つを検討する。
① 一時停止（0km/h）で想定される調定要求の通信範囲
合流開始前に一時停止のある環境における本線側の法定速度の上限値については調査していない
が、地域高規格道路において合流起点に一時停止のある環境を想定すると、図 2.3.1-3 の道路モデルの合流起点に一時停止があり、本線の法定速度：70km/h とした場合、想定する道路と通信エリアの関係を図 2.5.2.2-1 に記す。

：合流車との通信が必要な対象車両（10台）

想定される通信エリア（停止線から半径231.7m(192.8m+38.9m)@本線70km/h）※図は道路幅方向を省略
合流起点(一時停止線）：車線変更中の車両（10台）：a-1-4.通信に関与しない車両

合流完了位置（合流車線長終端）
190.0m（合流車線長：70km/h標準条件）※Aの合流予定位置※A

192.8m38.9m

Aの加速：0～70km/h、0.2Gに必要な時間：
9.91sで、本線車両が移動する距離

2秒車間@70km/h

図 2.5.2.2-1 ユースケース a-1-4 の合流起点で想定する道路と通信エリアの関係―41―

ITS FORUM RC-017
ユースケース a-1-4 の一時停止で必要となる通信距離は、一時停止線で停止した位置から本線の法定速度へ加速するのに必要な時間：9.91 秒で本線上の車両が移動する距離と車間距離：2 秒車間を加えた距離とみなして、調定要求で必要となる最大通信距離（半径）は、表 2.5.2.2-1 の通りと考えられる。
表 2.5.2.2-1 地域高規格道路における本線の法定速度と通信距離の関係（調定要求）

本線の法定速度

必要な通信距離（応答要求範囲、半径）70km/h231.7m

乗用車： 96.4m、大型車：128.5m

60km/h204.1m

乗用車： 70.8m、大型車： 94.4m

50km/h

176.6m

乗用車： 49.2m、大型車： 65.6m

参考：指定加速度で必要な距離

なお、本線を走行する全ての車両が協調走行車であり、合流車両からの要求に対して応答するとは限らないため、合流車両は一定時間後に本線に車両が存在しないとみなして加速を開始し、自律走行で合流するか、自動運転での合流が困難と判断してドライバへのハンドオーバ要求を実行する
か、いずれかのシナリオが想定される（本書のシナリオ外）。

―42―

ITS FORUM RC-017② 混雑時の合流前後で想定される調定要求の通信範囲
混雑時の合流前後で行われる通信シーケンスでは、本線の混雑によって速度低下して、路側イン
フラで管制できない状況で本線へ合流する場合を想定する。
ただし、合流路の前方には車両が存在しない状況においては、法令に従って合流路の前方へ移動した後の合流が必要となるため、調定要求で必要な通信範囲は、合流開始時に自車の前方となる車両から合流起点までの範囲に位置する車両とみなせる。なお、合流開始位置は特定できないため、本検討では、モデル１（図 2.3.1-1）、モデル 2（図 2.3.1-2）、モデル 3（図 2.3.1-3）の合流車線長となる 255m、210m、190m とみなす。
図 2.3.1-1 の合流起点から合流終点までに想定される車両配置と合流起点直後を走行する要求車の通信エリアを、図 2.5.2.2-2 に記す。

：調定応答の対象車両（19台）：更新応答または更新要求の車両（5台）：調定要求の車両（1台）想定される要求エリア（合流車線長を半径：255mとした範囲）※図は前方と道路幅方向を省略：a-1-4.通信に関与しない車両
合流完了位置（合流車線長終端）

合流起点
255.0m（合流車線長）合流開始位置

5.6m
2秒車間@20km/h

図 2.5.2.2-2 ユースケース a-1-4 の合流車線で想定する車両配置と通信エリアの関係

なお、各車両が自車情報を周期送信する方式により本線車両の位置情報を得られる場合や、前走する合流車の通信によって本線車両の位置情報が得られている場合、一時停止時の調定要求で合流予定の前後複数台分の位置情報を得られている場合においては、必ずしも図 2.5.2.2-2 で示される範囲の車両全体と調定を行う必要はなく、合流予定となる車両の前方および後方の複数台の範囲と通信できる状態で、調定できれば合流は可能と考えられる。
流入路を乗用車が速度：40km/h@１秒車間で走行している本線へ合流する状況において、ウィン
カの点灯時間と車線変更に要する時間として約 6 秒間とした場合、遅くとも合流終点の 66.7m 手前で更新要求が開始されるとみなせる。
この時、更新要求として情報提供が必要な範囲は、合流終端までの距離に相当する範囲とみなせ
ば、流入路を走行する前後 66.7m の範囲となり、乗用車：5m を 1 秒車間（11.1m）で配置した場
合、図 2.5.2.2-3 に記す通り、要求車の前後に位置する流入路を走行する 8 台の車両との通信が必要
となる。

―43―

ITS FORUM RC-017：調定応答および更新応答の対象車両（4台）：調定応答または更新要求の車両（4台）：調定要求および更新要求の車両（1台）想定される要求エリア（合流終端手前：66.7mを半径とした範囲）※図は前方と道路幅方向を省略：a-1-4.通信に関与しない車両
合流完了位置（合流車線長終端）

合流起点
255.0m（合流車線長）11.1m
1秒車間@40km/h

図 2.5.2.2-3 ユースケース a-1-4 の合流車線で想定する車両配置と通信エリアの関係（混雑時）

なお、流入路の速度がさらに低下した場合、必要な通信距離が短くなるが、合流路終端では車幅減少となるため 40km/h での通信距離が適当な長さではないかと思われる。
➂ 更新要求と更新応答の通信範囲
更新要求と更新応答は調定応答を受けた車両に対する通信シーケンスとなるため、上記①と②のいずれにおいても調定要求の通信範囲と同じまたは狭くなると考えられる。

―44―

ITS FORUM RC-017
2.5.2.3 メッセージ送受信シーケンス
ユースケース a-1-4 で想定されるメッセージ送受信シーケンスを図 2.5.2.3-1 に記す。
なお、2.5.2.1 項で説明した通り、調定要求と調定応答のみで完了こともあるが、以下では協調走
行による合流が完了（更新要求と更新応答）するまでのシーケンスを説明する。
管制/合意のシーケンスと異なる点は、路側インフラの代わりに自車が調定要求メッセージや更新要求メッセージを送信し、管制要求メッセージがない点にある（基本的には、図 2.5.1.3-2 と図
2.5.1.3-3 のシーケンスを用いて実行される）。

要求車

1.調定要求メッセージ

受入/応答車

（要求車情報）2.調定応答メッセージ（受入/応答車位置情報＋合意判定）

3.更新要求メッセージ（受入車送信：要求車情報＋受入車情報）

4.更新応答メッセージ（受入/応答車位置情報＋合意判定）

3a.更新要求メッセージ（受入車送信：要求車情報＋受入車情報）

4a.更新応答メッセージ（受入/応答車位置情報＋合意判定）

図 2.5.2.3-1 管制/合意で想定されるメッセージ送受信シーケンス

1. 要求車は、要求範囲の周辺車両に対して調定要求メッセージを車両の判断で、送信する。

NOTE: 要求範囲は、合流や車線変更の際、自車の前後に位置すると予測される車両範囲として、ユースケース a-1-4 は本線の法定速度（流入路）、ユースケース a-2 は車線変更先との相対速度などで決定する。
2. 周辺車両は、要求車からの調定要求メッセージを受信すると、自車の現在位置と照合して要求範囲内と判断した場合、応答としてユニーク ID となる車載器 ID と、位置情報および当該周辺車両が決定した合意に応じられるかの結果（調定）を、調定応答メッセージとして送信する（以降、要求範囲の通過または要求車からの更新要求が確認できるまでは車載器 IDを固定する）。
3. 要求車は、周辺車両からの調定応答メッセージ受信や、自車の自律情報(e.g., 自律センサで取得した情報など)から更なる更新要求メッセージの発行を行うケース（本線が混雑等によって速度低下しているかなど）かどうかを判断する。更新要求メッセージの発行を行う
ケースでは、合流または車線変更する場所を決定し、要求車の後方に位置する予定の応答車―45―

ITS FORUM RC-017（受入車）に対して車載器 ID と共に合意のための更新要求メッセージ（受入車要求）を車両が判断して、送信する。

NOTE: 合流終点付近で混雑が始まっている場合や既に本線が混雑している場合、合流車線に先行する車両が存在して前方の状況が不明な場合などで更新要求メッセージを車両が送信すると想定する。
4. 自車の車載器 ID と一致する更新要求メッセージを受信した協調走行車（受入車）は、メッ
セージの情報に従い要求車を受け入れるための制御を開始すると共に、要求車に対する合意したことを通知する更新応答メッセージを車両の判断で、送信する。

NOTE: 受入車が要求範囲外へ移動した場合や、緊急事態などで更新要求メッセージに対して合意できないと車両が判断した場合における応答要否については検討が必要
5. 要求車は、受入車からの合意が得られた場合、合流または車線変更に向けて自車の制御が開始されることを想定。

NOTE: 受入車からの合意が得られない場合、後続の協調走行車から要求車が合流する場所を変更し、更新要求メッセージ送信と更新応答メッセージ受信の繰り返しを想定。
3a. 要求車は、以下の条件などを満たすまで受入車に対して車両の判断で、更新要求メッセー
ジを繰り返し送信する。
-

要求車が自律センサによる合流または車線変更が可能と判断する-受入車から合意終了となる更新応答メッセージを受信する

NOTE: 更新要求メッセージの繰り返し送信周期は仮に 100ms とする。通信トラヒックがひっ迫する場合、更新要求メッセージの繰り返し送信周期を広げる場合も想定される。
4a. 受入車は、要求車からの更新要求メッセージに対する応答を繰り返して行い、自車が、要求車を認識または自車が要求範囲外へ移動したと判断し、車両の判断で、合意応答を“合意終了”として更新応答メッセージを応答する。

―46―

ITS FORUM RC-017
2.5.2.4 通信内容
調定要求メッセージ、調定応答メッセージ、更新要求メッセージ、更新応答メッセージのメッセー
ジ内容を表 2.5.2.4-1 に示す。
表 2.5.2.4-1 調定要求メッセージ、調定応答メッセージ、更新要求メッセージ
および更新応答メッセージ内容

データサイズ ※1
情報要素

調定応答メッセージ
更新応答メッセージ

調定要求メッセージ
更新要求メッセージ

メッセージ ID

16 bit16 bit

合意応答

8 bit

―

路側機、車載器 ID（自車）

32 bit32 bit

道路番号

32 bit32 bit

走行車線

8 bit

8 bit

車載器 ID（通信対象）

32 bit32 bit

情報更新時刻32 bit32 bit

車両位置（緯度経度高度）

88 bit88 bit

車両速度（目標速度）

16 bit16 bit14 bit（+空:2 bit）

14 bit（+空:2bit）

返信要求距離―16 bit合流先（目標）車線

―

8 bit

16 bit16 bit―16 bit

車両長さ

先行車との（目標）車間距離
行動開始予定時間※1 無線通信ではオーバヘッドを別途追加する必要がある。

―47―

ITS FORUM RC-017
2.5.2.5 想定される要求車両数と応答車両数
ユースケース a-1-4 の停止線から調定要求と調定応答が行われるモデル 3（合流車線長：190m）の道路条件では、要求範囲に位置する車両が 100ms 内にいずれかの要求または応答を 1 回行うとみなすと、合流車線においては、停止線で調定要求を開始する 1 台に対して、本線の受入車線においては、合流起点から上流 190ｍまでの渋滞（本線側速度 0km/h）を想定して車間距離：2m の条件で配置すると、約 27 台となる。
なお、更新要求メッセージまたは更新応答メッセージが行われている車両では、合流（車線変更）を開始している車両は、自律による合流が可能な状況（通信完了）へ移行している可能性が高いが、上記のいずれにおいても通信を継続しているとみなして台数に加えている。
また、ユースケース a-1-4 の合流開始時に調定要求と調定応答が行われるモデル 1 の道路条件では、上記と同様に要求範囲内の合流車線を走行する車両のみが 100ms 内にいずれかの応答を 1 回のみ行うとして調定要求を 1 台とみなしても、本線上の受入車線を乗用車（5m）、20km/h、1 秒車
間：約 5.6m の条件で配置すると約 24 台、渋滞を想定して車間距離：2m で配置すると約 36 台と、要求範囲が広いため応答台数も増加する結果となる。こちらも、上記と同様に車線変更中の車両においても通信を行うとみなして台数に加えている。

―48―

ITS FORUM RC-017
2.5.3

ユースケース a-2. 混雑時の車線変更の支援

ユースケース a-2 は、混雑等によって見通しの悪い車線から車線変更を行う際、関係車両間で相互の走行情報を交換し、円滑な車線変更を行う。
2.5.3.1 想定する通信シナリオ
ユースケース a-2 で想定されるシナリオは、2.5.2.1 項のシナリオに準じる。
調定要求メッセージを送信するトリガとして、自車が走行する車線が、混雑等によって法定速度に満たない速度での走行を強いられ、かつ隣接車線の見通しが悪く自車のセンサでは車線変更が行えない場合、隣接車線を走行する協調走行車に対して調定要求メッセージの送信が行われる。
ただし、相対速度：20km/h を超えると車線変更が難しくなるため、相対速度：20km/h 以下の状
況でのみ更新要求と更新応答が行われ、相対速度：20km/h を超えた状況においては、調定要求と調定応答のみが行われることを想定する。更新要求と更新応答がどの状況で用いられるかは車両の判断となる。
2.5.3.2 想定される通信範囲の条件
ユースケース a-2 は、隣接車線との相対速度が把握できず、自律走行による車線変更が困難な状況の例として、図 2.3.1-4 の道路条件に対して法定速度：100km/h の道路にて路肩に隣接する車線が混雑し、80km/h@1 秒車間、隣接する走行車線が 100km/h@2 秒車間（相対速度 20km/h）の環境を想定すると図 2.5.3.1 の位置関係となる。この時、調定要求がユースケース a-1-3 の通信エリアに準じて 255m で行われるとみなした場合、図 2.5.3.2-1 の通信範囲となる。

：車線変更要求車両（1台）：車線変更応答車両（9台）：a-2通信に関与しない車両

80km/h、1秒車間
22.2m

55.6m
100km/h、2秒車間

図 2.5.3.2-1 ユースケース a-2 で想定する道路と通信エリアの関係

また、ユースケース a-2 の更新要求と更新応答で必要となる通信距離（最小応答要求範囲）は、
ウィンカの点灯時間と車線変更に要する時間として約 6 秒間、車間距離として 1 秒を加えた 7 秒とみなし、相対速度：20km/h で行われた場合は 38.9m となる。
2.5.3.3 メッセージ送受信シーケンス
管制/合意の共通シーケンスとなるので、2.5.2.3 項に準じる。

―49―

ITS FORUM RC-017
2.5.3.4 通信内容
管制/合意の共通メッセージ内容となるので、2.5.2.4 項に準じる。
2.5.3.5 要求車両数と応答車両数
ユースケース a-2 が発生する要求車両数と応答車両数は不確定なため以下の通りと仮定した。
調定要求を行う車両が、速度に関係なく要求車両の半径：255m に存在する隣接車線の車両より調定応答を受信する場合、混雑した状態が最も多くなるため、乗用車：5m を要求車線：静止状態、
車間距離：2m、受入車線：20km/h、1 秒車間で配置した場合、それぞれの車線に配置される車両台数は、要求車線：73 台、受入車線：48 台となる。
要求車線と受入車線の車両密度を平均化させるには、12 台の車線変更が必要となるため、更新のメッセージが発生しているとみなせば、受入車線：48 台のうち、0～12 台が更新応答メッセージを送信し、残りの 48～36 台は調定応答メッセージを送信すると考えられる。
同様な考え方として、受入車線：6km/h、1 秒車間の場合は 77 台となり、車両密度を平均化させるには 3～4 台の車線変更となるため、相対速度差が低下すると要求台数が減少する。
なお、車線数が 3 車線ある場合、受入車線から隣接車線への車線変更も発生することが想定される。隣接車線の車両密度が、受入車線と同等（48 台）とみなした場合、車両密度を平均化するには、要求車線から受入車線への車線変更：16 台、受入車線から隣接車線への車線変更：8 台となるため、受入車線：48 台のうち 0～16 台が更新応答メッセージまたは更新要求メッセージを、残りの 48～
24 台は調定応答メッセージを送信し、隣接車線：48 台のうち 0～8 台が更新応答メッセージを、残りの 48～40 台が調定応答メッセージを送信すると考えられる。

―50―

ITS FORUM RC-017
2.6 交差点進入支援のユースケース
2.6.1

ユースケース a-3. 渋滞時の非優先道路から優先道路への進入支援

信号のない交差点において、一時停止後に、位置や速度の情報および進入意思を車両間で通信し、非優先道路から優先道路上へ進入するための走行支援を行う。
2.6.1.1 想定する通信シナリオ
ユースケース a-3 で想定されるシナリオは、基本的には 2.5.2.1 項のシナリオに準じたものとなるが、合流や車線変更のユースケースでは更新要求が単一車線なのに対して、シナリオによっては複数車線の更新要求を必要とする点が大きく異なる。
本シナリオでは優先道路を走行する全ての車両が協調走行車とみなし、非優先道路から進入する
車両が渋滞する優先道路を横断するシナリオで検討する。
2.6.1.2 想定される通信範囲の条件
ユースケース a-3 で必要となる通信距離（応答要求範囲）として、図 2.3.2-1 の道路条件にて、非優先道路上の大型車が、優先道路を横断する場合、法定速度：50km/h、2 秒車間で車両配置した場
合と渋滞中で停止した場合の交差点と通信エリアの関係を図 2.6.1.2-1 に記す。
：要求車両（1台）：応答車両（18台）：a-3.通信に関与しない車両

27.8m
約2秒車間
@50km/h：要求車両（1台）：応答車両（72台）：a-3.通信に関与しない車両

車間距離
（停止時）
2.0m

横断予定の車両（大型車）

図 2.6.1.2-1 ユースケース a-3.で想定する交差点と通信エリアの関係（上：50km/h、2 秒車間、下：渋滞中）―51―

ITS FORUM RC-017
位置情報を要求する通信エリアは、優先道路上を走行する車両が交差点の手前で安全に停止できるのに必要な距離として、0.15G の減速距離とみなした場合の関係を表 2.6.1.2-1 に記す。
表 2.6.1.2-1 優先道路側の法定速度と位置情報要求エリアの関係

優先道路側の法定速度

位置情報要求エリア（参考：0.15G での減速距離）60km/h111.1m（94.4 m）

50km/h79.8 m（65.6 m）

40km/h53.1 m（42.0 m）

30km/h31.9 m（23.6 m）

2.6.1.3 メッセージ送受信シーケンス
基本的には管制/合意の共通シーケンス（2.5.2.3 項参照）となるが、複数車線にわたる調定要求
メッセージ/調定応答メッセージおよび更新要求メッセージ/更新応答メッセージが発生する点が異なる。
1. 自動運転する車両（要求車）が、優先道路へ侵入する手前にある停止線で一時停止した後、優先道路へ進入する直前まで徐行する間に、優先道路を走行する車両に対して車両の判断で、調定要求メッセージを送信する。

NOTE: 100ms 以内に全ての車両から次の２での調定応答メッセージでの応答を得られない可能性があるため、得られた情報量に応じて複数回実施する。
2. 優先道路の対象車線を走行する各車両は、調定要求メッセージを受信すると自車の位置情報と比較して、要求範囲内であり、かつ進行方向の前方に位置すると判断した場合、応答としてユ
ニーク ID となる車載器 ID と、位置情報および当該車両が決定した合意に応じられるかを調定応答メッセージで送信する（以降、要求範囲を通過するまでは車載器 ID を固定する）。

NOTE: 既に、要求車とは別の協調走行車からの位置情報要求や、進入支援の調停が実施され、100ms 以内に位置情報を送信している場合は再送信しない。
3. 要求車は、周辺車両からの調定応答メッセージを受信して要求車が合流する場所を決定し、交差が予測される車両（受入車）に対して車載器 ID を含んだ更新要求メッセージを車両の判断で、送信する。
複数車線の車両に対して連続または一括して更新要求メッセージと更新応答メッセージを送信する場合は、対象の受入車全てに対して送信し、車線毎に更新要求メッセージと更新応答
メッセージを繰り返す場合は、隣接する車線の受入車から順次送信と受信を車両の判断で、繰
り返す。

―52―

ITS FORUM RC-017
4. 自車の車載器 ID が更新要求メッセージ内の車載器 ID と一致する更新要求メッセージを受信した協調走行車（受入車）は、自車の前方を交差する車両が生じると判断して交差点の手前で停止可能な速度へ減速を開始すると共に、要求車に対する更新応答メッセージを送信する。

NOTE: 受入車が要求範囲外へ移動した場合や、緊急事態などで更新要求メッセージに対して合意できないと車両が判断した場合における応答要否については検討が必要
5. 要求車は、受入車からの更新応答を受けて、更新要求を維持しながら次の横断車線に対する受入車に対して車両の判断で、調停要求メッセージを送信する

NOTE: 車線毎に更新要求メッセージを送信と応答を繰り返す場合は、横断する車線に対して
2 から 5 のシーケンスが繰り返して実施される。
3a. 要求車は、以下の条件を満たすまで受入車に対して更新要求メッセージを繰り返し送信する。
-

要求車が受入車の車線を通過したなどと判断する-受入車から合意終了の更新応答メッセージを受信する

NOTE: 更新要求メッセージの繰り返し送信周期は仮に 100ms とする。通信トラヒックがひっ迫する場合、更新要求メッセージの繰り返し送信周期を広げる場合も想定される。
4a. 受入車は、要求車からの更新要求メッセージに対する応答を繰り返して行い、受入車が要求
車を認識または要求車が要求範囲外へ移動したと車両が判断した場合、合意応答を“合意終了”として更新応答メッセージを応答する。
2.6.1.4 通信内容
基本的には管制/合意と共通メッセージ内容（2.5.1.4 項参照）となるが、複数車線にわたる調定要
求メッセージ/調定応答メッセージおよび更新要求メッセージ/更新応答メッセージが発生する点が異なる。
複数車線の車両へ合意を要求する際、要求手順を実施する方法として、以下について今後の検討が必要となる。
方法 1: 要求-応答手順を車線毎に応答が完了してから逐次実施する。
（本シナリオだと 6 車線それぞれに対して 1 回ずつ実施）
1 つの更新要求メッセージで合意のための要求を行う通信対象車両は 1 台（2.5.1.4 節の管制/合意のメッセージが流用可能）
方法 2: 要求-応答手順を複数車線に対して同時に実施する。
（本シナリオだと 6 車線に対して 1 回実施）
方法 1 では手前の車線から順に調停要求と調定応答および更新要求と更新応答を行うため、交差点の途中で更新要求が得られないと、優先道路を渋滞させる要因となってしまう可能性がある。
方法 2 では全ての対象車線からの調停応答を受信してから更新要求メッセージを送信するため、調定要求が得られない車線が生じると優先道路への侵入が実施できない状態が継続する可能性があ
る。

―53―

ITS FORUM RC-017
交差点を左折する場合はいずれの方法でも差はない。
なお、本ユースケースでは、交差点情報の共有が必要となるが、ダイナミックマップ情報で共有可能と解釈してメッセージには含めていない（共有が不可能な場合、メッセージへ交差点情報（80bit）を追加する必要がある）。
2.6.1.5 要求車両数と応答車両数
要求車両数は、周辺の道路環境や、優先道路へ進入する車両数で変化する。
本シナリオで検討した図 2.3.2-1 の道路条件は、非優先道路を対向車線からの進入を含めた 2 台が互いに優先道路を横断すると仮定し、優先道路へ渋滞した車両を配置（乗用車（5m）を車間距離：2m で配置）した場合、要求車からの位置情報要求が異なる車線に対して同時に行われたとすれば、渋滞時に同時に発生する応答車両数は約 68 台となる。
2.7 参考文献[1] 「700MHz 帯高度道路交通システムの高度化に関する技術的条件」の検討開始について
https://www.soumu.go.jp/main_content/000442474.pdf―54―

ITS FORUM RC-017
別添 2A

想定されるスポット計測位置の検討

ユースケース a-1-1 の計測センサはスポット計測センサとなるため、本線上流の流入路を走行する車両に対して、情報提供までに計測が行える場所へ設置される。
この条件として、協調走行車の予備加減速に必要となる、合流起点への到達時間を制御する時間幅（猶予時間）を考慮する必要があり、本線を走行する 2 秒車間の隙間への合流を想定すると、予備加減速で約 2 秒の猶予時間が必要と思われる。
モデル 1 の道路条件にて、合流起点で法定速度へ回復する前提で、法定速度から減速して、法定速度へ復帰（加速）した場合の時間と、同じ移動距離を法定速度で定速移動した場合の時間差（猶予時間）を、表 2A-1（普通車）と表 2A-2（大型車）に記す。
表 2A-1 法定速度:40km/h の連絡路における速度調整幅と定速移動の関係（普通車）

速度調整幅［km/h］

加減速に要する時間［秒］
減速(0.25G) 加速(0.2G)
合計

移動距離
[m]

定速移動
時間 [秒]

時間差[秒](猶予時間)

5

0.57

0.71

1.28

13.28

1.20

0.08

10

1.13

1.42

2.55

24.79

2.23

0.32

15

1.70

2.12

3.82

34.52

3.11

0.71

20

2.27

2.83

5.10

42.48

3.82

1.28

25

2.83

3.54

6.37

48.68

4.38

1.99

速度
［km/h］
50

合流起点50m手前に料金ブース出口がある場合の距離と経過時間の関係
猶予時間:1.27秒

猶予時間:0.32秒
猶予時間:0.08秒

猶予時間:0.72秒

猶予時間:1.99秒

40

30

20
速度調整幅:5km/h
速度調整幅:10km/h
速度調整幅:15km/h
速度調整幅:20km/h
速度調整幅:25km/h

10

0
0

1

2

3

4
経過時間［秒］

5

6

7

8

図 2A-1 法定速度:40km/h の連絡路における速度調整幅と定速移動の関係（普通車）―55―

ITS FORUM RC-017
表 2A-2 法定速度:40km/h の連絡路における速度調整幅と定速移動の関係（大型車）

速度調整幅［km/h］

加減速に要する時間［秒］
減速(0.15G) 加速(0.15G)
合計

移動距離
[m]

定速移動
時間 [秒]

時間差[秒](猶予時間)

5

0.94

0.94

1.88

19.68

1.77

0.11

10

1.89

1.89

3.78

36.72

3.30

0.48

15

2.83

2.83

5.66

51.14

4.60

1.06

20

3.78

3.78

7.56

62.94

5.66

1.90

速度
［km/h］
50

合流起点50m手前に料金ブース出口がある場合の距離と経過時間の関係
猶予時間:0.11秒

猶予時間:0.48秒

猶予時間:1.06秒

猶予時間:1.9秒

40

30

20
速度調整幅:5km/h
速度調整幅:10km/h

10速度調整幅:15km/h
速度調整幅:20km/h

0
0

1

2

3

4
経過時間［秒］

5

6

7

8

図 2A-2 法定速度:40km/h の連絡路における速度調整幅と定速移動の関係（大型車）

協調走行車が連絡路において、最短の移動距離で約 2 秒の猶予時間を得るためには、法定速度:40km/h から 20km/h 以上減速する条件であれば普通車で 4.38 秒（移動距離：48.68m）、大型車
で 5.66 秒（移動距離：62.94m）となり、大型車の加減速に要する時間が支配的となる。
また、速度調整幅が同じ条件であれば、連絡路の法定速度に関係なく加減速に要する時間は変化
しないが、加減速に伴う移動距離が変化する。そのため、ある速度調整幅（加減速に要する時間）に対して、連絡路の法定速度を大きくしていくと、それに応じて“同じ移動距離 を法定速度で定速移動した場合の時間”が大きくなり、結果的に確保できる猶予時間が減少していく。法定速度と速度調整幅および猶予時間の関係を表 2A-3（普通車）と表 2A-4（大型車）の通りとなる（表中の“―”は検討の対象外として計算していない）。

―56―

ITS FORUM RC-017
表 2A-3 連絡路の法定速度と速度調整幅および猶予時間の関係（普通車）

法定速度と速度調整幅に対する移動距離と猶予時間
40km/h
50km/h
60km/h
70km/h
移動
移動
移動
移動
猶予
猶予
猶予
猶予
時間
時間
時間
時間
距離
距離
距離
距離

速度
調整幅
[km/h]

加減速
時間
[秒]

25

6.4

48.7

2.0

66.4

1.6

84.1

1.3

101.8

1.1

28

7.1

―

―

71.4

2.0

―

―

―

―

31

7.9

―

―

―

―

97.7

2.0

―

―

33

8.4

―

―

―

―

―

―

125.0

2.0

移動時間幅：

4.4～6.4

5.1～7.1

5.9～7.9

6.4～8.4

表 2A-4 連絡路の法定速度と速度調整幅および猶予時間の関係（大型車）

速度
調整幅[km/h]

加減速
時間
[秒]

20

法定速度と速度調整幅に対する移動距離と猶予時間
40km/h移動猶予
距離時間50km/h移動猶予
距離時間60km/h移動猶予
距離時間70km/h
移動
猶予
距離
時間

7.6

62.9

1.9

83.9

1.5

104.9

1.3

125.9

1.1

23

8.7

―

―

92.9

2.0

―

―

―

―

25

9.4

―

―

―

―

124.6

2.0

―

―

27

10.2

―

―

―

―

―

―

160.4

2.0

移動時間幅：

5.7～7.6

6.7～8.7

7.4～9.4

8.2～10.2

表 2A-3 と表 2A-4 を比較しても分かる通り、同じ速度調整幅で連絡路の法定速度を変化させた場
合（普通車の場合：25km/h のケース、大型車の場合：20km/h のケース）、連絡路の法定速度が大きくなると猶予時間:約 2 秒を確保できなくなる。大型車を含めて猶予時間:約 2 秒を確保するためには、連絡路の法定速度に応じて計算された大型車の加減速時間（移動距離）を考慮した場所へス
ポット計測センサを設置する必要がある。
本線のスポット計測センサは、合流路が本線車両の状況を鑑みて連絡路で速度調整できるように設置されるため、連絡路の移動距離（移動時間）が大きいほど、本線のより上流に設定され、結果的に合流車が得られる情報の信頼度が低下する恐れが生じる。
大型車の移動距離と猶予時間の関係である表 2A-4 の結果を参考に、連絡路の法定速度毎に設定
距離（速度調整幅：2s を確保するのに必要と想定さる連絡路長。表 2A-4 の移動距離を 5m の粒度で繰り上げた値）を定め、普通車は大型車の最長時間に合わせて速度調整した場合の、連絡路の法定速度と移動時間、最低速度の関係を表 2A-5 に、また参考として、普通車の移動距離と猶予時間の関係である表 2A-3 の結果を参考にした例として、大型車の猶予時間を得るため、設定距離への進入速度を法定速度－10km まで予め減速させ、かつ最低速度は普通車を同じ速度とする条件で得られる猶予時間について試算した結果を、表 2A-6 に記す。

―57―

ITS FORUM RC-017
表 2A-5 連絡路の法定速度と移動時間、最低速度の関係

移動時間（普通車・大型車）
最短 [秒] 最長 [秒]最低速度［km/h］
普通車
大型車

連絡路の
法定速度
［km/h］

設定距離
［m］

40

65

5.9

7.9

27.1

22.1

50

95

6.8

8.8

35.8

31.0

60

125

7.5

9.5

35.8

31.0

70

165

8.5

10.5

53.2

47.6

法定速度:40km/h、設定距離:65mにおける速度と経過時間の例

速度［km/h］
50

猶予時間:2秒4030
20

普通車、最短時間
普通車、最長時間最低速度
普通車:27.1km/h
大型車:22.1km/h

10

大型車、最短時間
大型車、最長時間

0
0

1

2

3

4

5
経過時間［秒］

6

7

8

9

10

図 2A-3 法定速度:40km/h、設定距離:65m における速度と経過時間の例

法定速度:50km/h、設定距離:95mにおける速度と経過時間の例

速度［km/h］
60

猶予時間:2秒

50
40
30
20

普通車、最短時間

最低速度
普通車:35.8km/h
大型車:31.0km/h

10普通車、最長時間
大型車、最短時間
大型車、最長時間

0
0

1

2

3

4

5
経過時間［秒］

6

7

8

9

図 2A-4 法定速度:50km/h、設定距離:95m における速度と経過時間の例

―58―

10

ITS FORUM RC-017

法定速度:60km/h、設定距離:125mにおける速度と経過時間の例

速度［km/h］
70

猶予時間:2秒

60
50
40
30
普通車、最短時間

最低速度
普通車:43.9km/h
大型車:35.0km/h

2010普通車、最長時間
大型車、最短時間
大型車、最長時間

0
0

1

2

3

4

5
経過時間［秒］

6

7

8

9

10

図 2A-5 法定速度:60km/h、設定距離:125m における速度と経過時間の例

法定速度:70km/h、設定距離:165mにおける速度と経過時間の例

速度［km/h］
80

猶予時間:2秒

70
60
50
40
最低速度
普通車：53.2km/h
大型車：47.6km/h

3020

普通車、最短時間
普通車、最長時間
大型車、最短時間

10

大型車、最長時間
0
0

1

2

3

4

6
5
経過時間［秒］

7

8

9

10

11

図 2A-6 法定速度:70km/h、設定距離:165m における速度と経過時間の例
表 2A-6 連絡路の法定速度と最低速度・大型車の進入速度および猶予時間の関係

普通車の移動時間と速度
大型車の移動時間と速度
最短
最長
最低速度 進入速度
最短
最長
最低速度
［秒］
［秒］
［km/h］ ［km/h］ ［秒］ ［秒］ ［km/h］

連絡路の
法定速度
［km/h］

設定距離
［m］

40

60

5.4

7.4

25.7

34.1

5.5

7.4

25.7

50

80

5.8

7.8

31.5

42.4

5.9

7.8

31.5

60

100

6.0

8.0

35.1

50

6.2

8.0

35.1

70

130

6.7

8.7

43.8

60

6.8

8.6

43.8

―59―

ITS FORUM RC-017

速度［km/h］
50

法定速度:40km/h、設定距離:60mにおける速度と経過時間の例
猶予時間:2秒
猶予時間:1.93秒

40
30
20

最低速度:25.7km/h

普通車、最短時間
普通車、最長時間

10

大型車、最短時間
大型車、最長時間

0
0

1

2

3

4
経過時間［秒］

5

6

7

8

図 2A-7 法定速度:40km/h、設定距離:60m における速度と経過時間の例

速度［km/h］
60

法定速度:50km/h、設定距離:80mにおける速度と経過時間の例
猶予時間:2秒
猶予時間:1.89秒

50
40
30
最低速度:31.5km/h

20

普通車、最短時間
普通車、最長時間

10

大型車、最短時間
大型車、最長時間

0
0

1

2

3

4
経過時間［秒］

5

6

7

8

図 2A-8 法定速度:50km/h、設定距離:80m における速度と経過時間の例

速度［km/h］
70

法定速度:60km/h、設定距離:100mにおける速度と経過時間の例
猶予時間:2秒
猶予時間:1.83秒

60
50
40
30
普通車、最短時間

最低速度:35.1km/h

20普通車、最長時間
大型車、最短時間

10

大型車、最長時間
0
0

1

2

3

4
5
経過時間［秒］

6

7

8

図 2A-9 法定速度:60km/h、設定距離:100m における速度と経過時間の例

―60―

9

ITS FORUM RC-017

速度［km/h］
80

法定速度:70km/h、設定距離:130mにおける速度と経過時間の例
猶予時間:2秒
猶予時間:1.82秒

70
60
50
40
最低速度:43.8km/h

30普通車、最短時間
普通車、最長時間

20

大型車、最短時間

10

大型車、最長時間
0
0

1

2

3

4
5
経過時間［秒］

6

7

8

9

図 2A-10 法定速度:70km/h、設定距離:130m における速度と経過時間の例

表 2A-6 に記した通り、大型車の猶予時間を稼ぐ手段として、予め進入速度を法定速度から最大10km/h まで低下させる条件が可能であれば、最低速度を乗用車と同じ最低速度へ制限しても 1.93
秒（40km/h）から 1.82 秒（70km/h、設定距離：130m）を確保できるのが分かる。
また、本検討では本線走行速度への加速に必要な合流車線長が得られる前提としているが、加速に必要な合流車線長が得られない場所においては、連絡路で確保した猶予時間では不足となり、猶予時間を拡大する必要がある（別添 2C 参照）。
モデル 1（図 2.3.1-1 参照）において、表 2A-5 で移動時間が最小となるケース（連絡路の法定速度が 40km/h、加減速に要する時間を 5.9 秒）を想定した場合、合流車両（自車）が、本線上に予測される車両位置情報を受信する時間として 100ms、走行計画を見直すまでの時間として 100ms の時間を要すると仮定し、合流起点の 6.1 秒前には路側インフラの通信エリア内へ侵入する。
この時、円滑に本線へ合流するためにも、少なくとも自車が合流する際の 2 秒後方の車両情報を得る必要があるとみなし、スポット計測するセンサは連絡路から合流路へ変化する起点（合流起点）
から、法定速度×8.1 秒上流に設置されると仮定した場合の結果を表 2A-7 に記す。
ユースケース a-1-1 の計測センサ位置は、ユースケース a-1-2 での最上流の検知位置と同じとな
る。

―61―

ITS FORUM RC-017
表 2A-7 本線の法定速度とスポット計測の設置場所の関係（連絡路：40km/h）

法定速度
（本線）

スポット計測の設置場所（合流起点から上流）

スポット計測の設置場所（路側インフラの処理遅延時間を500ms と仮定、合流起点から上流）120km/h

270.0m286.7m

100km/h

225.0m238.9m

80km/h

180.0m191.1m

60km/h

135.0m143.3m

50km/h

112.5m119.4m

スポット計測センサを設置する位置は、自動運転レベル 0 の車両やマニュアル走行中の自動運転車に関しては、法定速度で走行するとは限らないことや、計測センサが車両検知と処理に必要な遅延時間を考慮した位置へ配置することも想定される。路側インフラの処理遅延時間を 500m と仮定した場合の設置場所を表 2A-7 の右列に記す。
モデル 1 の道路条件に対して、モデル 2（図 2.3.1-2 参照）の都市高速道路では、合流起点の手前に料金所があり、合流起点まで十分な距離が得られず、場合によっては法定速度へ満たない速度での走行を強いられる可能性が想定される。
この条件下においても合流支援を可能とするには、モデル 1 の場合と同様に約 2 秒の猶予時間を得られるか、また、合流起点までの到達時間が最長となる時間を考慮し、本線上流へスポット計測
センサを配置する必要があるが、本線上流へ設置すると、計測時の速度と合流起点での速度差による合流位置のズレによって得られる情報の精度が低下する可能性（別添 2C 参照）や、最短時間で走行する車両に対して情報提供のタイミングが遅れてしまう可能性が懸念される。
モデル 2 における、最短と最長の到達時間および到達時間差として合流起点で 40km/h で走行できる前提条件で試算した結果は、表 2A-8 の通りとなる。
表 2A-8 モデル 2 の到達時間と猶予時間の関係

車種（加速度）

最短時間［秒］

最長時間［秒］

猶予時間［秒］

普通車（0.2G）

5.21

7.58

2.38

大型車（0.15G）

5.44

7.11

1.67

―62―

ITS FORUM RC-017

速度［km/h］

合流起点50m手前に料金ブース出口がある場合の距離と経過時間の関係

50

40
合流起点ポイント30

20
普通車、最短時間
普通車、最長時間

10

大型車、最短時間
大型車、最長時間

0
0

1

2

3

4

5
6
経過時間［秒］

7

8

9

10

図 2A-11 モデル 2 の到達時間と猶予時間の関係

表 2A-8 の通り、猶予時間は普通車で 2.4 秒、大型車で 1.67 秒となるが、最長時間は大型車で 7.11
秒、普通車で 7.58 秒とモデル 1 よりも長い時間となる。
表 B-1 と同様な考え方（合流時に 2 秒後方までの車両情報を得る）で、それぞれの時間において理想とされるスポット計測センサの設置場所を計算すると、表 2A-9 の通りとなる。
表 2A-9 モデル 2(都市高速道路)の本線法定速度とスポット計測の設置場所の関係理想とされるスポット計測の設置場所（合流起点から上流）
法定速度
（本線）

最短時間に対する設置場所（処理時間：500ms 追加）

最長時間に対する設置場所（処理時間：500ms 追加）

80km/h160.2m（171.3m）

212.9m（224.0m）

60km/h120.2m（128.5m）

159.7m（168.0m）

50km/h100.1m（107.1m）

133.1m（140.0m）―63―ITS FORUM RC-017
別添 2B

スポット計測における課題点

スポット計測特有の懸念事項として、計測時の速度と合流起点での速度差による合流位置のズレが想定される。
仮に、前方の混雑により 2 秒車間を維持した状態で、80km/h から 40km/h まで 0.15G で減速しながらスポット計測センサを通過すると、図 2B-1 の様な関係となる。
80
速度［km/h］
75

70

65

60

55

50

45

路側インフラが提供する予測速度
40-100
スポット計測センサ

の計測位置

0

100

200

300

400

500

移動距離［m］

図 2B-1 前方の混雑により 2 秒車間を維持しながら 0.15G で減速した場合の移動距離と速度の関係

この対策として様々な案が考えられるが、配信する車両情報に信頼度の情報を追加して、前後車両間の速度差や検知車両数に応じて信頼度を変化させて、協調走行車側で受信した信頼度に応じて個々に判断する（信頼度の分類に関しては通信要件とは関係ないため説明を省く）。

―64―

ITS FORUM RC-017
別添 2C

十分な合流車線長が得られない場合の猶予時間について

本線速度への加速と合流に必要な移動距離が得られない場合、本線速度へ満たない速度での合流開始を強いられ、連絡路で確保した猶予時間を削減されてしまう事象が想定される。
本線を走行する大型車（全長 12m）が、速度 80km/h（22.2m）、2 秒車間（44.4m）で連なって走行する場合を想定すると、合流に必要な猶予時間は（44.4＋12×2）÷22.2≒3.1 秒となり、連絡路
で猶予時間：2 秒を確保できる場合は、合流路での加速調整で 1.1 秒の猶予時間を確保する必要があるが、十分な合流車線長が得られず 1.1 秒の猶予時間を確保できない場合、連絡路で不足分を補う必要が生じる。
仮に、本線を 80km/h、2 秒車間で走行する車両の間へ合流する状況において、十分な加速が得られず加速しながら合流する場合、前走車との車間距離：5m で合流を開始して 3 秒後に合流を完了
した時、後続車との車間距離：1 秒車間となる条件で得られる残り猶予時間を計算すると、0.2G で加速する普通車（車長：5m）が合流する場合を表 2C-1 に、0.15G で加速する大型車（車長：12m）が合流する場合を表 2C-2 に記す。
表 2C-1 合流車の速度および移動距離と後続車との車間距離の関係（普通車）

No.

合流車の速度 [km/h]
初速
3 秒後

車線変更
移動距離

後続車との車間距離 [m]
初速
3 秒後

残り猶予時間

1

40.0

61.2

42.2 m56.7 ～ 46.7

32.2 ～ 22.2

0.5

2

50.0

71.2

50.5 m56.7 ～ 38.4

40.5 ～ 22.2

0.8

3

58.8

80.0

57.9 m56.7 ～ 31.0

47.9 ～ 22.2

1.2

4

80.0

80.0

66.7 m56.7 ～ 22.2

56.7 ～ 22.2

1.6

表 2C-2 合流車の速度および移動距離と後続車との車間距離の関係（大型車）

No.

合流車の速度 [km/h]
初速
3 秒後

車線変更
移動距離

後続車との車間距離 [m]
初速
3 秒後

残り猶予時間

1

40.0

55.9

40.0 m49.7 ～ 48.9

23.0 ～ 22.2

0

2

50.0

65.9

48.3 m49.7 ～ 34.3

37.6 ～ 22.2

0.7

3

64.1

80.0

60.1 m49.7 ～ 28.8

43.1 ～ 22.2

0.9

4

80.0

80.0

66.7 m49.7 ～ 22.2

49.7 ～ 22.2

1.2

表 2C-1 と表 2C-2 で記した通り、数値的には連絡路から合流起点までの速度が 40km/h の場合であっても合流可能な値となっているが、合流後の後続車両に対して減速を強いる懸念があるため、本線速度で合流を開始するか、少なむとも合流完了時に本線速度まで加速する必要がある。
なお、定速で合流を開始できる場合は、残り猶予時間は合流路で必要な猶予時間：1.1 秒よりも大きく、連絡路の猶予時間：2 秒で合流できると考えられる。
連絡路速度：40km/h から合流開始時に本線速度と同じ速度となる前提で、普通車・大型車共に同―65―

ITS FORUM RC-017
じ移動距離で 2 秒の猶予時間を確保した結果を表 2C-3 に記す。
なお、試算条件として、加減速 G の小さい大型車の最短での移動時間に対し、初速の 80%まで減速して短い距離で猶予時間を確保することを条件として試算した結果となる。
表 2C-3 本線速度と猶予時間:2 秒の確保に必要な距離

移動時間 [秒]最短
最長

最低速度 [km/h]
普通車
大型車

97.7

6.5

8.5

36.9

32.0

40

125.5

7.7

9.7

40.0

32.0

40

161.1

9.1

11.1

40.0

32.0

No.

本線速度
[km/h]

連絡路初速[km/h]

移動距離
[m]

1

60

40

2

70

3

80

速度
［km/h］
70

本線速度:60km/h、猶予時間:2秒に必要な速度と経過時間の例
猶予時間:2秒

60
50
40
30
普通車、最短時間20

普通車、最長時間最低速度
普通車：36.9km/h
大型車：32.0km/h

10

大型車、最短時間
大型車、最長時間

0
0

1

2

3

4
5
経過時間［秒］

6

7

図 2C-1 本線速度:60km/h、猶予時間:2 秒に必要な速度と経過時間の例

―66―

8

9

ITS FORUM RC-017

本線速度:70km/h、猶予時間:2秒に必要な速度と経過時間の例

速度［km/h］
80

猶予時間:2秒

70
60
50
40
30

普通車、最短時間20

普通車、最長時間最低速度
普通車：40.0km/h
大型車：32.0km/h

10

大型車、最短時間
大型車、最長時間

0
0

1

2

3

4

5
経過時間［秒］

7

6

8

9

10

図 2C-2 本線速度:70km/h、猶予時間:2 秒に必要な速度と経過時間の例

本線速度:80km/h、猶予時間:2秒に必要な速度と経過時間の例

速度［km/h］
90

猶予時間:2秒

80
70
60
50
40
普通車、最短時間3020

普通車、最長時間最低速度
普通車：40.0km/h
大型車：32.0km/h

10

大型車、最短時間
大型車、最長時間

0
0

1

2

3

4

5

6
7
経過時間［秒］

8

9

10

11

12

図 2C-3 本線速度:80km/h、猶予時間:2 秒に必要な速度と経過時間の例

表 2C-3 に記した通り、合流起点の手前で猶予時間：2 秒を確保するには、本線速度が 60km/h では 97.7m 手前で 8.5 秒前の本線情報を、80km/h では 161.1m 手前で 11.1 秒前の本線情報が必要となる。
ただし、表 2C-1 から表 2C-3 は本線の車間距離：2 秒の前提で行っており、本線の車間距離が短くなると必要な猶予時間は小さくなるが、残り猶予時間も小さくなる。
参考までに、本線が 1.5 秒車間（33.3m）で必要な猶予時間は（33.3＋12×2）÷22.2≒2.6 秒、1 秒
車間（22.2m）で必要な猶予時間は（22.2＋12×2）÷22.2≒2.1 秒となるが、大型車（全長：12m）の合流だと 1.5 秒車間の場合は、前方：5m の車間距離とした場合でも後方：16.3m の車間距離、1
秒車間では前後に 5m の車間距離での合流となるため、いずれも合流車の後方に 1 秒車間に満たな―67―

ITS FORUM RC-017
い車間での合流であり、本線速度での合流開始が前提となる。
このため、猶予時間を大きくした状況も必要となる可能性を考慮し、表 2C-3 と同じ条件で、猶予
時間：3.1 秒の確保が必要となった場合の試算結果を表 2C-4 に記す。
表 2C-4 本線速度と猶予時間:3.1 秒の確保に必要な距離

移動時間 [秒]最短
最長

最低速度 [km/h]
普通車
大型車

118.7

7.7

10.8

35.3

32.0

40

143.5

8.6

11.7

37.9

32.0

40

177.5

9.9

13.0

40.0

32.0

No.

本線速度
[km/h]

連絡路初速[km/h]

移動距離
[m]

1

60

40

2

70

3

80

本線速度:60km/h、猶予時間:3.1秒に必要な速度と経過時間の例

速度［km/h］
70

猶予時間:3.1秒

60
50
40
30
普通車、最短時間20

普通車、最長時間最低速度
普通車：35.3km/h
大型車：32.0km/h

10

大型車、最短時間
大型車、最長時間

0
0

1

2

3

4

5
6
経過時間［秒］

7

8

9

図 2C-4 本線速度:60km/h、猶予時間:3.1 秒に必要な速度と経過時間の例

―68―

10

11

ITS FORUM RC-017

本線速度:70km/h、猶予時間:2秒に必要な速度と経過時間の例

速度［km/h］
80

猶予時間:3.1

70
60
50
40
30

普通車、最短時間20

普通車、最長時間最低速度
普通車：37.9km/h
大型車：32.0km/h

10

大型車、最短時間
大型車、最長時間

0
1

0

2

3

4

5

8

6
7
経過時間［秒］

9

10

11

12

図 2C-5 本線速度:70km/h、猶予時間:3.1 秒に必要な速度と経過時間の例

本線速度:80km/h、猶予時間:3.1秒に必要な速度と経過時間の例

速度［km/h］
90

猶予時間:3.1秒

80
70
60
50
40
普通車、最短時間3020

普通車、最長時間最低速度
普通車：40.0km/h
大型車：32.0km/h

10

大型車、最短時間
大型車、最長時間

0
0

1

2

3

4

5

6
7
経過時間［秒］

8

9

10

11

12

13

図 2C-6 本線速度:80km/h、猶予時間:3.1 秒に必要な速度と経過時間の例

合流起点の手前で猶予時間：3.1 秒を確保する必要がある場合は、
本線速度が 60km/h では 118.7m
手前で 10.8 秒前の本線情報を、80km/h では 177.5m 手前で 13 秒前の本線情報が必要となる。

―69―

ITS FORUM RC-017

［余白］

―70―

ITS FORUM RC-017

第3章

b.信号情報のユースケース

3.1 前提条件
本章固有の前提条件は特にない。
3.2 シナリオ検討の進め方
以下のユースケースについてのシナリオ検討進めた。
・ ユースケース b-1-1. 信号情報による走行支援(V2I)
・ ユースケース b-1-2. 信号情報による走行支援(V2N)
以下のポイントについて考慮がさらに必要である。
・ユースケース b-1-1 と b-1-2 においてメッセージ内容が共通化できる部分を考慮。
・ユースケース b-1-2 において先読み情報のユースケースにおける V2N の設計と共通化できる部分を考慮。

3.3 信号情報における走行支援のユースケース
3.3.1

ユースケース b-1-1. 信号情報による走行支援（V2I）

協調走行車が、信号を遵守して交差点を通過できるようにする。
交差点の信号機の現在灯色および信号サイクル情報（信号灯色のシーケンスと切り替わりタイミング）等を、路側インフラから交差点進入車両に提供し、信号サイクルの先読み情報を V2I で受信した車両が、余裕をもって減速・停止することを支援する。

―71―

ITS FORUM RC-017

図 3.3.1-1 信号サイクル先読み情報の必要性 [1]より具体的な活用例として、信号が黄色に変わったとき、通過することも停止することもできな
いエリア(ジレンマゾーン)に進入しないように、信号サイクルを受信して、予め緩やかに減速することを支援する。

図 3.3.1-2 ジレンマゾーン[1]―72―ITS FORUM RC-017
3.3.1.1 想定する通信シナリオ
・100ms 周期で常に交差点の信号機の現在の信号灯色および信号サイクル情報等の最新情報をブロードキャストで配信する。
・1 交差点毎に全方路の情報を提供することとする。同一通信領域で、複数交差点の情報を送信することはできるようにする。

3.3.1.2 想定される計測位置の検討
感応式信号を扱えるような検討は行うが、感応式信号における信号情報生成のための計測は本ユースケースでは扱わない。
3.3.1.3 必要な通信エリアの条件
ジレンマゾーン回避のため以下のような減速方法を想定する。

図 3.3.1.3-1 ジレンマゾーン回避のための減速方法[1]―73―ITS FORUM RC-017

図 3.3.1.3-2 Δt 算出の考え方 [1]

図 3.3.1.3-3 計算結果(黄色時間=4 秒の場合) [1]―74―

ITS FORUM RC-017
上記より、黄色時間 4 秒、V0＝60km/h、Δt＝4.91s において、情報を受信するのに必要な停止線
からの距離(信号情報のゆらぎ考慮せず)は、約 138.5m の計算になると想定される。
同様に大型車の場合は、約 206.3m の計算になると想定される。
3.3.1.4 車両 ID と車載器 ID の紐付け
本ユースケースでは、特定の車両(車載器)を指定しての指示は行われないので、路側インフラが検知した車両に一時的に付与する車両 ID と、車載器識別用の車載器 ID との紐づけは不要である。
3.3.1.5 メッセージ送受信シーケンス
路側インフラ

走行車

信号サイクル情報
100ms 周期で送信
信号サイクル情報

信号サイクル情報

図 3.3.1.5-1 ユースケース b-1-1 で想定されるメッセージ送受信シーケンス―75―

ITS FORUM RC-017
3.3.1.6 通信内容
メッセージ内容は、[2]に記載の「別添４ＩＴＳ無線路側機東京臨海部実証実験版」及び「別添５ ＩＴＳ無線路側機

通信アプリケーション共通規格

ＤＳＳＳ及び自動走行システム用 路

車間通信アプリケーション規格 東京臨海部実証実験版」の信号情報を基本として、生成時刻と生成時刻からの残秒数を付与することを想定する。検討対象とした交差点(図 3.3.1.6-1)における、想定メッセージ内容及びサイズの例を表 3.3.1.6-1、表 3.3.1.6-2、表 3.3.1.6-3 に示す。

4 方路へのサービスあり

右折矢印灯器あり

図 3.3.1.6-1 信号情報による走行支援(V2I)検討対象の交差点イメージ[3]―76―ITS FORUM RC-017
表 3.3.1.6-1 には、共通ヘッダとなる送信時刻情報を示す。
表 3.3.1.6-1 ユースケース b-1-1 での想定メッセージ内容及びサイズの例(共通ヘッダ)

構成 DF/DE
DE_メッセージ種別コード
DE_メッセージバージョ
ン
DE_予備 1
DF_無線機管理番号
DE_運用区分コード
DE_メッセージ ID
DE_インクリメントカウ
ンタ
DF_送信時刻

DE_メッセージサイズ
DE_予備 8DE_予備 8
合計

bit

値
3
4
1

DE_都道府県コード
DE_無線機 ID

8
16
1
7
8

DE_年
DE_月
DE_日
DE_サマータイム指定
DE_休日指定
DE_曜日
DE_予備 3
DE_時刻(時)DE_時刻(分)DE_時刻(秒)DE_時刻(100ms)
DE_予備 8

16
8
8
1
1
3
3
8
8
8
8
8
16
8
8
160

―77―

備考

ITS FORUM RC-017
表 3.3.1.6-2 には、検討対象とした交差点(図 3.3.1.6-1)の信号情報を示す。
表 3.3.1.6-2 ユースケース b-1-1 での想定メッセージ内容及びサイズの例(信号情報)

構成 DF/DE
DF_提供点管理番号

bit
DE_都道府県コード
DE_提供点種別コード
DE_交差点 ID/単路 ID

値(※1) 備考

8
1
15
8
8
8
8

4

DE_歩灯器数

80

DE_接続方路数(I)DE_サービス方路数(J)DF_サービス方路信号情報：1

8
8

4
4

DE_方路 ID
DE_信号通行方向情報有無フラグ
DE_予備 7
DE_信号通行方向情報
DE_車灯器情報ポインタ：1
DE_車灯器情報ポインタ：2
DE_車灯器情報ポインタ：3
DE_車灯器情報ポインタ：I=4

8
1
7
8
16
16
16
16

1

DE_歩灯器情報ポインタ：1

16

DE_歩灯器情報ポインタ：2

16

DE_歩灯器情報ポインタ：3

16

DE_歩灯器情報ポインタ：I=416

省略(サイズは同上)

152

省略(サイズは同上)

152

省略(サイズは同上)

152

DE_予備 8DE_システム状態
DE_イベントカウンタ
DE_車灯機数

DF_サービス方路信号情報：2
DF_サービス方路信号情報：3
DF_サービス方路信号情報：J=4
DF_車灯器情報
DE_車灯器 ID
DE_灯色出力変化数(K)

―78―

歩灯器な
し

U ターン
左折
直進
右折
無効値の
フルビッ
トを格納
無効値の
フルビッ
トを格納
無効値の
フルビッ
トを格納
無効値の
フルビッ
トを格納

4

1

4

例)青黄
赤青黄赤
6
の場合

ITS FORUM RC-017
DF_車両灯器情報(1)DF_車両灯器情報(2)DE_丸信号灯色表示
DE_青矢印信号表示方向
DE_カウントダウン停止フラグ
DE_最小残秒数(0.1 秒)
DE_最大残秒数(0.1 秒)

8
8
1
15
16

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

DF_車両灯器情報(3)DF_車両灯器情報(4)DF_車両灯器情報(5)DF_車両灯器情報(K=6)
DF_車灯器情報
DE_車灯器 ID
DE_灯色出力変化数(K)DF_車両灯器情報(1)DF_車両灯器情報(2)

2

4

例)青黄
(右矢)黄
10 赤青黄(右矢)黄赤の場合

DE_丸信号灯色表示
DE_青矢印信号表示方向
DE_カウントダウン停止フラグ
DE_最小残秒数(0.1 秒)
DE_最大残秒数(0.1 秒)

8
8
1
15
16

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

DF_車両灯器情報(3)DF_車両灯器情報(4)DF_車両灯器情報(5)DF_車両灯器情報(6)DF_車両灯器情報(7)DF_車両灯器情報(8)DF_車両灯器情報(9)4DF_車両灯器情報(K=10)―79―

ITS FORUM RC-017
DF_車灯器情報
DE_車灯器 ID

43

DE_灯色出力変化数(K)4例)赤青
7 黄赤青黄赤の場合

DF_車両灯器情報(1)DF_車両灯器情報(2)DE_丸信号灯色表示
DE_青矢印信号表示方向
DE_カウントダウン停止フラグ
DE_最小残秒数(0.1 秒)
DE_最大残秒数(0.1 秒)

8
8
1
15
16

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

DF_車両灯器情報(3)DF_車両灯器情報(4)DF_車両灯器情報(5)DF_車両灯器情報(6)DF_車両灯器情報(K=7)
DF_車灯器情報
DE_車灯器 ID
DE_灯色出力変化数(K)DF_車両灯器情報(1)DF_車両灯器情報(2)

4

4

4

例)赤青
黄(右矢)
11 黄赤青黄(右矢)黄赤の場合

DE_丸信号灯色表示
DE_青矢印信号表示方向
DE_カウントダウン停止フラグ
DE_最小残秒数(0.1 秒)
DE_最大残秒数(0.1 秒)

8
8
1
15
16

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

DF_車両灯器情報(3)DF_車両灯器情報(4)DF_車両灯器情報(5)DF_車両灯器情報(6)DF_車両灯器情報(7)―80―

ITS FORUM RC-017

DF_車両灯器情報(8)省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48

省略(サイズは同上)

48
2352

DF_車両灯器情報(9)DF_車両灯器情報(10)DF_車両灯器情報(K=11)

合計(※1)参考として一部のメッセージに値を記入している

表 3.3.1.6-3 には、検討対象とした交差点(図 3.3.1.6-1)の交差点識別情報を示す。
表 3.3.1.6-3 ユースケース b-1-1 での想定メッセージ内容及びサイズの例(交差点識別情報)

構成 DF/DE
DF_提供点管理番号

登録予備
DE_接続方路数(I)DF_方路識別情報：1

bit
DE_都道府県コード
DE_提供点種別コード
DE_交差点 ID/単路 ID

DE_方路 ID
登録予備

8
48

省略(サイズは同上)

56

省略(サイズは同上)

56

DF_方路識別情報：2
DF_方路識別情報：3
DF_方路識別情報：
I=4

8
1
15
80
8

値(※1)

備考

4
1

省略(サイズは同上)
56
合計
336
(※1)参考として一部のメッセージに値を記入している
共通ヘッダ(表 3.3.1.6-1)は。信号情報(表 3.3.1.6-2)と交差点識別情報(表 3.3.1.6-3)のそれぞれに付加され、共通ヘッダの内容により続くデータが何の情報かが識別される。本例におけるメッセー
ジサイズは、
共通ヘッダ(表 3.3.1.6-1)が 2 回分と、信号情報(表 3.3.1.6-2)、
交差点識別情報(表 3.3.1.63)を足し合わせたものとなり、3008bit となることが想定されるが、無線パケットと信号情報、交差
点識別情報の多重・分割については検討が必要である。

―81―

ITS FORUM RC-017
3.3.2

ユースケース b-1-2. 信号情報による走行支援（V2N）

協調走行車が、信号を遵守して交差点を通過できるようにする。
交差点の信号機の信号サイクル情報等を、ネットワーク経由で交差点進入車両に提供し、車両の減速、停止の支援によりジレンマ回避を行う。

図 3.3.2-1 信号情報による走行支援(V2N)ユースケースイメージ[3]

本検討では、SIP 第２期/クラウド等を活用した信号情報提供に係る研究開発の成果[6][7]を参照
する。

3.3.2.1 想定する通信シナリオ
信号サイクル情報等を V2N で送信するシステムは、[6]によると以下の図で示される。
「交通信号
制御機～交通管制センタ間」、「交通管制センタ～警察庁信号情報集約システム間」、「警察庁信号情報集約システム～信号情報センタ（仮称）間」は非競争領域である。
「信号情報センタ（仮称）～配信センタ」が競争領域との境界点となる。
「配信センタ～車載器間」は競争領域である。本検討では「配信センタ～車載器間」を対象とする。
本ユースケースにおける信号予定情報は、絶対時刻に基づいた表現になっているため、通信遅延と比較して十分に手前で生成されていれば、通信遅延の影響を受けない。ただし、感応制御など、信号機が周辺交通量などによりリアルタイムに信号サイクルを制御する信号交差点においては、予め信号予定情報を生成することができないため、通信遅延が問題になる。

―82―

ITS FORUM RC-017

図 3.3.2.1-1 信号情報による走行支援(V2N)システム構成と通信経路[6]「配信センタ～車載器間」の実現には、以下のシーケンス案がある。

・完全プル方式：信号付近の指定の場所に近づくと、車両から現在地の情報もしくは信号の識別情報を[4]で記載の配信センタに送信し、[4]で記載の配信センタから該当の信号情報を入手する。車両からのプル要求のあったときにのみ信号情報が車両に、通知されるため、信号情報センタからの感応式信号などのイベント発生や、信号の故障などのイベントに応じて車両に信号情報を通知することはできない。
・位置情報非周期・信号情報プッシュ方式：信号付近の指定の場所に近づくと、車両から現在地の情報もしくは信号の識別情報を[4]で記載の配信センタに送信する。V2N の回線を維持し、信号情報センタからの信号情報のイベント発生に応じて車両に信号情報をプッシュする。
・位置情報周期・信号情報プッシュ方式： 先読み情報のユースケース(異常車両、逆走車、渋滞、分岐、ハザード、緊急車両の通知: d-1、d-2、d-3、d-4、d-5)において、V2N のユニキャストのために、各車両の位置情報を定期的に管理サーバに送信し、この情報を車両と該当信号機の紐づけに用いる。V2N の回線を維持し、信号情報センタからの信号情報のイベント発生に応じて車両に信号情報をプッシュする。
上記の 3 方式は以下の表としてまとめられる。位置情報の通信では、完全プル方式と位置情報非周期・信号情報プッシュ方式は同一である。信号情報通信では、位置情報非周期・信号情報プッシュ方式と位置情報周期・信号情報プッシュ方式は同一である。感応制御などの信号へ対応するには、
信号情報センタからの信号情報のイベント発生に応じて車両に信号情報を伝える必要があり、完全プル方式では実現は不可能である。

―83―

ITS FORUM RC-017
表 3.3.2.1-1 シーケンス案の比較

シーケンス案
完全プル方式

位置情報非周期・信号情報プッシュ方式
位置情報周期・
信号情報プッシュ方式

位置情報通信信号情報通信感応制御などの信号への対応の可能性
対応不可能

特定の場所に近づくと、 プル時に信号情報を提供
車 両から 現在 地もし く
は 信号の 識別 情報を 配
信センタに送信する
特定の場所に近づくと、 信号情報センタからの信 対応の可能性あり
車 両から 現在 地もし く 号情報のイベント発生には 信号の 識別 情報を 配 応じて車両に信号情報を信センタに送信する
プッシュ
異常車両、逆走車、渋滞、 信号情報センタからの信 対応の可能性あり
分岐、ハザード、緊急車 号情報のイベント発生に両の通知と共用で、車両 応じて車両に信号情報をの 位置情 報を 定期的 に プッシュ
管理サーバに送信

位置情報周期・信号情報プッシュ方式では、先読み情報のユースケースでの管理サーバの把握する無線通信エリアは、66.6m（２回の通信が２秒で行われる範囲を時速 120km/h）を想定している。
位置情報非周期・信号情報プッシュ方式と位置情報周期・信号情報プッシュ方式での信号情報通信として、ユニキャストの他に、管理サーバが指定するエリアへのブロードキャスト配信を先読み
情報のユースケースと同様に実現できる可能性はあるが、先読み情報：走行計画変更のユースケー
スでの議論の動向に合わせて更新を行う。

位置情報非周期・信号情報プッシュ方式と位置情報周期・信号情報プッシュ方式での信号情報通信において、先読み情報のユースケースでの管理サーバと[6]で記載の配信センタの関係としては少なくとも以下の方式があり、今後の決定が必要である。
方式 1：

先読み情報のユースケースでの管理サーバと、配信センタが同一である。

方式 2： 先読み情報のユースケースでの管理サーバと、配信センタは異なり、管理サーバが、配信センタに、車両の V2N での ID、位置情報などを通知し、信号情報は配信センタから入手する。
方式 3： 先読み情報のユースケースでの管理サーバと、配信センタは異なり、管理サーバが、配信センタに、どの信号情報を通知するかを、配信センタに通達し、配信センタが信号情報を車載器に通信する。

位置情報非周期・信号情報プッシュ方式と位置情報周期・信号情報プッシュ方式での信号情報通信においては、先読み情報のユースケースでの管理サーバ管理もしくは、移動通信オペレータネッ
ト ワ ー ク の 管 理 に よ り 、 端 末 は 、 待 ち 受 け 状 態 で あ る RRC_IDLE か ら 通 信 状 態 で あ る
RRC_CONNECTED への状態遷移により通信遅延が増大することでゆらぎ時間が増大しない想定―84―

ITS FORUM RC-017
をする。これは、自動車工業会からの要望事項である”ゆらぎ時間の規定 ±300msec 以内 遅延時間は規定しない”[4]を満たすために重要であると想定する。
f-4 ダイナミックマップ情報配信のシナリオにより、静的地図を入手するものとする。

3.3.2.2 想定される信号情報生成の方式
信号予定情報生成の方式として、[6]では、「管制方式」、「集中方式」、「制御機方式」を記載している。
「管制方式」、「集中方式」、「制御機方式」のどの方式においても、信号情報センタを経由するため、完全プル方式、位置情報非周期・信号情報プッシュ方式、位置情報周期・信号情報プッシュ方式の違いに影響しないことを想定する。
3.3.2.3 必要な通信エリアの条件
既存のセルラーシステムの通信エリアを利用することを想定する。

NOTE: 車両からの位置情報に応じて、どれだけの周辺の信号情報を提供するかは、配信センタもし
くは管理センタが、決定する。車両から周辺のどの信号の情報を必要とするといった要求を出すのか、もしくは配信センタもしくは管理センタのみで決定するのかについて検討が必要である。
NOTE: トンネルなどで圏外などになって位置情報が通知できないが、その後、圏内になったときに信号情報の配信をどのように扱うかの検討が必要である。
完全プル方式、位置情報非周期・信号情報プッシュ方式、位置情報周期・信号情報プッシュ方式の違いは本章には影響しない。
3.3.2.4 車両位置と近傍信号の紐付け
完全プル方式、および位置情報非周期・信号情報プッシュ方式では、特定の場所に近づくと、信号の識別情報もしくは車両から現在地を配信センタに送信するため、この情報により車両位置と近傍信号の紐づけが行われる。信号情報を配信している信号機が少ない場合や、先読み情報のユース
ケース (異常車両、逆走車、渋滞、分岐、ハザード、緊急車両の通知: d-1、d-2、d-3、d-4、d-5)が適用されない場合は、車両からの信号の識別情報もしくは車両から現在地情報の通知頻度を下げる
ことで通信量を下げることができる。
位置情報周期・信号情報プッシュ方式では、先読み情報のユースケースでの管理サーバにより場所が把握される。信号情報を配信している信号機が多い場合や、先読み情報のユースケース (異常車両、逆走車、渋滞、分岐、ハザード、緊急車両の通知: d-1、d-2、d-3、d-4、d-5)が適用される場
合は、車両からの位置情報の通知を共用することで通信量を下げることができる。

―85―

ITS FORUM RC-017
位置情報非周期・信号情報プッシュ方式と位置情報周期・信号情報プッシュ方式を、信号情報を配信している信号機の数や、先読み情報のユースケースとの共用に応じてなどで、地域ごとに使い分ける方式も一案である。

3.3.2.5 メッセージ送受信シーケンス
信号情報通知シーケンスでは、先読み情報のユースケースでの異常車両、逆走車、渋滞、分岐、
ハザード、緊急車両の通知メッセージと異なったタイミングや頻度で送信できる動作を想定する。
信号情報通知シーケンスの遅延時間や揺らぎ時間は、絶対時刻と残秒数による提供のため、誤差には影響しないが、信号が黄色に変わった時に通過することも停止することもできないエリア（ジレンマゾーン）を避けるために自動運転車が黄色に変わる前に減速を開始する時間（Δt と呼ばれる）に関係する。信号情報通知シーケンスの遅延は、絶対時刻に基づく情報提供のため、基本的には影響しない。ただし、信号予定情報が更新される場合には、遅延の影響を受ける。自動車工業会による検討では、ジレンマゾーン(3.3.1 参照)への進入回避のための走行制御の判断には、交差点へ進入するΔt 秒前に信号予定情報が確定されている必要がある。遅延の大きさによっては、更新された信号予定情報がΔt 秒前に届かないことが考えられる。特に、感応制御等が適用されている交差点においては、信号予定情報がリアルタイムに更新されるため、影響を受けやすい。また、感応制御等が適用されていない交差点においても、信号故障等が発生した場合は同様に影響を受ける。そのような様々なケースに対応するには、遅延を短くする必要がある。

完全プル方式における位置情報通信および信号情報通信のシーケンスを以下に示す。現在の信号周期が終わる場合、次の周期に対応する信号情報を配信サーバに要求する」ような処理を検討する必要がある。

―86―ITS FORUM RC-017[1]で記載の配
信センタ

協調走行車

信号付近の指定の場所に近づく
位置情報報告メッセージ
信号情報通知メッセージ

信号付近の指定の場所に近づく

位置情報報告メッセージ
信号情報通知メッセージ

図 3.3.2.5-1 完全プル方式における位置情報通信および信号情報通信のシーケンス

位置情報非周期・信号情報プッシュ方式における位置情報通信シーケンスを以下に示す。
[4]で記載の配
信センタ

協調走行車

信号付近の指定の場所に近づく
位置情報報告メッセージ

信号付近の指定の場所に近づく

位置情報報告メッセージ

図 3.3.2.5-2 位置情報非周期・信号情報プッシュ方式における位置情報通信シーケンス―87―

ITS FORUM RC-017
位置情報周期・信号情報プッシュ方式における位置情報通信シーケンスを以下に示す。
先読み情報のユースケースでの管理サーバ

協調走行車

位置情報報告メッセージ
一定周期で送信
位置情報報告メッセージ

位置情報報告メッセージ

図 3.3.2.5-3 位置情報周期・信号情報プッシュ方式における位置情報通信シーケンス

位置情報非周期・信号情報プッシュ方式および位置情報周期・信号情報プッシュ方式における信号情報通信のシーケンスを以下に示す。以下の図では、信号情報センタからのメッセージが一対一で協調走行車へのメッセージとして記載しているが、異なった信号もしくは異なった時間の複数のメッセージをまとめる動作について今後の検討が必要である。
信号情報センタ[4]で記載の配信センタ

信号情報通知メッセージ

信号情報通知メッセージ

信号情報通知メッセージ

協調走行車

信号情報通知メッセージ

信号情報通知メッセージ

信号情報通知メッセージ

図 3.3.2.5-4 信号情報による走行支援(V2N)での信号情報通知シーケンス―88―

ITS FORUM RC-017
サイクル途中で変わり得る交差点を含めて、信号情報が確定した場合に信号予定情報が[4]で記載の配信センタから送信される。

位置情報非周期・信号情報プッシュ方式および位置情報周期・信号情報プッシュ方式における先
読み情報のユースケースでの管理サーバと、[4]で記載の配信サーバのアドレスを車載器が事前に設定済みなのか、動的に割り当てがあるのかは要検討。

3.3.2.6 通信内容
メッセージ内容は、[4]により「ITS 無線路側機 DSSS 用路車間通信アプリケーション規格」の信号情報を基本として、生成時刻と生成時刻からの残秒数を付与する。V2I のメッセージサイズが、
1Kbyte/交差点程度の想定で少なくとも 3 交差点程度までを一つのメッセージで送信できるものと想定する。どれだけの周辺の信号を通知するかは、検討が必要である。
ダイナミックマップ上の灯器と配信情報の紐づけがされていて、ダイナミックマップ上での信号
情報位置の通知が必要である。
プロトコルとして[4]では、信号情報センタへの通信として MQTT を用いている。配信サーバと車両において、先読み情報のユースケースと同様にするのか、信号情報センタへの通信と同様にするのかなどのどのプロトコルを用いるのか検討が必要である。
セキュリティとして、[4]で記載の配信サーバから車両へはセルラー方式でのセキュリティが適用されるものとする。

3.3.2.7 課題・検討項目[4]を検討している UTMS 協会では、検討範囲は一般道に限られているが、SIP 協調型自動運転
ユースケース b-1-2 は、一般道と高速道路の両方を対象としている。高速道路での信号の管理や生成方式が一般道と異なるのかや、車速が一般道と同等のときのみに限定してよいのかなどの検討・決定が必要である。

―89―

ITS FORUM RC-017
3.4 参考文献[1]2019 年度

戦略的イノベーション創造プログラム（SIP）第 2 期／自動運転（システムとサービ

スの拡張）／ITS 無線路側機等の路車間通信以外の手法による信号情報の提供に係る研究開発 成果報告書 https://www.sip-adus.go.jp/rd/rddata/rd03/205.pdf[2] 平成 30 年度成果報告書 戦略的イノベーション創造プログラム（SIP）第 2 期／自動運転（システムとサービスの拡張）／自動運転の実現に向けた信号情報提供技術等の高度化に係る調査、https://www.nedo.go.jp/content/100890621.pdf[3]

SIP 協 調型 自 動運 転 ユー ス ケー ス -2019 年 度 協 調型 自 動運 転 方式 検 討 TF 活 動報 告https://www.sip-adus.go.jp/rd/rddata/usecase.pdf[4] 2019 年度 戦略的イノベーション創造プログラム(SIP)第２期／自動運転（システムとサービスの拡張）／ITS 無線路側機等の路車間通信以外の手法による信号情報の提供に係る研究開発 成果報
告書 https://www.sip-adus.go.jp/rd/rddata/rd03/205.pdf[5] 戦略的イノベーション創造プログラム(SIP)第２期／自動運転（システムとサービスの拡張）／
ITS 無線路側機等の路車間通信以外の手法による信号情報の提供に係る研究開発 2019 年度

成

果報告、https://www.sip-adus.go.jp/rd/rddata/rd03/205s.pdf[6] SIP 第 2 期／自動運転(システムとサービスの拡張)／クラウド等を活用した信号情報提供に係る研究開発 成果報告書、2021 年 2 月 https://www.sip-adus.go.jp/rd/rddata/rd04/212.pdf[7] SIP 第 2 期／自動運転(システムとサービスの拡張)／クラウド等を活用した信号情報提供に係る研究開発 2020 年度分 成果報告書 概要版、2021 年 3 月
https://www.sip-adus.go.jp/rd/rddata/rd04/212s.pdf―90―

ITS FORUM RC-017

第4章

c.先読み情報：衝突回避のユースケース

4.1 前提条件
特に断りのない限り 2.1 記載の条件を適用した。4 章の条件について以下に記載する。
車線数
・ 一般道の車線数：片側 6 車線、片側 3 車線
車両の長さ
・ 全車両 5m

NOTE: 車長の長い大型車などは本版では考慮していない目標とする通信性能
各ユースケース毎に記載する
4.2 検討の進め方
以下のユースケースについてのシナリオを検討した。
衝突回避支援のユースケース
・ユースケース c-1. 前方での急停止、急減速時の衝突回避支援

・

ユースケース c-3. ハザード情報による衝突回避支援

交差点の情報による走行支援のユースケース
・ユースケース c-2-1. 交差点の情報による走行支援（V2V）

・

ユースケース c-2-2. 交差点の情報による走行支援（V2I）

上記シナリオのうち c-1 と c-3 は、SIP 協調型自動運転ユースケースでは、異なる事象であることから個別のユースケースとして定義されているが、通信要件観点では c-1 は c-3 のサブセットと考えられるため、本検討では c-3 向けに検討した前提・通信要件を c-1 へも適用することを想定した。
4.3 想定する道路条件
4.3.1

衝突回避支援の道路条件

本ユースケースでは、特別な条件はないが、急減速や急停止によって後続車両との相対速度が大きくなる道路（例えば、高速道路や規制速度の大きい一般道）などでの適用が想定される。
4.3.2

交差点の情報による走行支援の道路条件

右折可能な交差点を想定し、想定する車線数は片側 3 車線(内、右折車線 1 車線)、6 車線(内、右折車線 2 車線)とし、交差点当たりの方路数は 4 とした。

―91―

ITS FORUM RC-017

右折レーン

図 4.3.2-1 交差点の情報による走行支援で想定する道路の例（片側 3 車線）

右折レーン
右折レーン

図 4.3.2-2 交差点の情報による走行支援で想定する道路の例（片側 6 車線）―92―ITS FORUM RC-017
4.4 衝突回避のユースケース
4.4.1

ユースケース c-3. ハザード情報による衝突回避支援

ユースケース c-3 では、協調走行車が急減速や緊急車線変更を行った場合に、後続車へ緊急ハザー
ド情報を配信し、後続車が円滑に回避制御を実施する。また、協調走行車が前走車両から緊急ハザー
ド情報を受信した場合、急減速や緊急車線変更を実施しない場合であっても、前走車両から受信した緊急ハザード情報を後続車へ配信する。

NOTE：4.4.1 の検討内容は c-1 へも適用される。
4.4.1.1 想定シナリオ想定されるシナリオを以下に示す①

道路を走行する協調走行車は、自車の走行状況を周期的に配信する。

②

当該協調走行車は、自車が“急減速、或いは緊急車線変更を実行した”と判定した場合に、後方の車両に対しハザード情報を配信する。

NOTE: 当該車両が急減速の結果停車した場合、周囲の車両は当該車両から周期的に配信される自車の走行状況にて停車状態であることを検出することを想定する。
NOTE: ハザード情報の配信は、“急減速或いは、緊急車線変更を実行した”と判定されている限り実施される。車両の判定ロジックは本書のスコープ外とする。
NOTE：急減速情報は、周期的に配信される車両情報の中での通知および、個別の配信メッセー
ジでの通知の両方が想定され、どちらを用いるかは当該急減速情報の遅延要求に依存して決定される。
③

当該急減速情報を受信した協調走行車は、自車のダイナミックマップ上へ前走車の情報を反映し、必要に応じて減速や停止を実施することで前走車両との衝突を回避する。

④

協調走行車は、自車両の位置がハザード情報の有効範囲内にある場合には、当該情報を後続車へ転送する。

NOTE: ハザード情報がリレー車両によって後続車へリレーされる場合には、当該ハザード情報の格納された前走車からのメッセージを透過的にリレーする方法や、リレー車両が自身の走行情報を配信するための周期送信メッセージにアドオンする方法が考えられる。
いずれを用いるかは、オーバヘッドやメッセージ間の優先度制御などを考慮する必要がある。
NOTE: 協調走行車において、他車両から V2V で取得した情報と路側インフラから取得した情報の両方がある場合の判断は車両で実施する
4.4.1.2 想定する通信エリア
想定する通信エリアは、自車両の後方を走行する同一進行方向の車両と直接通信が可能な距離として 250m とした。尚、“後方を走行する同一進行方向の車両”は、自車両と同じ車線を走行するす―93―

ITS FORUM RC-017
べての後続車や、同一進行方向の別車線を走行する車両を対象とした。想定する道路条件へ、通信エリアを配置した位置関係を図 4.4.1.2-1 に示す。尚、想定する送信先車両数は不定である。自車両が前走車から受信した緊急ハザード情報を後続車へリレーする場合には、当該緊急ハザード情報の有効範囲内（急減速や緊急車線変更発生場所から上流 1km まで）でのみ実施される。尚、通信相手となる車両は非特定車両である（同報配信）。

NOTE: 緊急ハザード情報の有効範囲内において、急減速や緊急車線変更発生場所の上流 250m 地
点から上流へ緊急ハザード情報が転送される場合には、V2I や V2N 経由で転送されてもよい。
NOTE: 一般道においては道路形状・構造によって、上流(道のり距離)1km の範囲に自車両が位置しているかの判定が難しい場合があるが、自動運転車両であれば走行計画を管理していることが想定されるため、一般道でも判定可能とする。
緊急回避行動車両
通信エリア内のリレー車両

緊急ハザード情報有効範囲(1km)

250m

250m

図 4.4.1.2-1 想定する道路と通信エリア、有効範囲の関係

4.4.1.3 想定する通信遅延
車車間の直接通信における無線区間許容遅延として 100ms とする。また、メッセージがリレーされる場合においては、急減速や緊急車線変更発生時から後続車両がリレーされたメッセージを受信するまでの遅延は、上流 1 km までは距離に応じて 30s まで許容される。
4.4.1.4 想定する通信品質
車車間の直接通信について、無線区間許容遅延における 1 メッセージあたりのパケット到達率を99%以上とする。

NOTE：上記は暫定的な値。必要に応じて値は精査。

―94―

ITS FORUM RC-017
4.4.1.5 メッセージ送受信手順想定されるメッセージ送受信シーケンスを図 4.4.1.5-1 に示す。

後続車両
(リレー車両)前走車

後続車両

1. 自車の走行情報（緊急ハザード情報無し）
1. 自車の走行情報（緊急ハザード情報無し）
100ms周期で配信
100ms周期で配信
1a. 自車の走行情報（緊急ハザード情報無し）
1a. 自車の走行情報（緊急ハザード情報無し）
2. （周期配信情報にアドオンしない場合）
緊急ハザード情報

4. （周期配信情報にアドオンしない場合）
緊急ハザード情報

3. 自車の走行情報（緊急ハザード情報あり）
5. 自車の走行情報（緊急ハザード情報あり）
2a. （周期配信情報にアドオンしない場合）
緊急ハザード情報

3a. 自車の走行情報（緊急ハザード情報あり）

4a. （周期配信情報にアドオンしない場合）
緊急ハザード情報
5a. 自車の走行情報（緊急ハザード情報あり）

6. 自車の走行情報（緊急ハザード情報無し）
6. 自車の走行情報（緊急ハザード情報無し）

・・・

・・・

図 4.4.1.5-1 メッセージ送受信手順

1/1a. 前走車、後続車（リレー車両）及び後続車は、自車の走行情報（位置情報、加減速情報、速度情報など）を周辺車両に対して 100ms 周期で配信する。

NOTE: 図簡易化のため、後続車の周期的な走行情報の配信の矢印及び、後続車（リレー車両）
から前走車に対する周期的な走行情報の配信の矢印は省略している。
2/2a/3/3a. 前走車は急減速する場合、急減速動作が継続する限り、急減速情報を周期メッセージとは別メッセージ（2/2a）あるいは、周期メッセージにアドオンして（3/3a）後方車両に対して100ms 周期で配信する。
4/4a/5/5a. 後続車（リレー車両）は、前走車から緊急ハザード情報を受信した場合、有効範囲内であれば、当該緊急ハザード情報を後続車へ転送する。
6. 前走車は、急減速や緊急車線変更動作停止時に、緊急ハザード情報の配信を停止する（本停止に伴い、後続車（リレー車両）の後続車に対する緊急ハザード情報配信も停止する）。

―95―

ITS FORUM RC-017
4.4.1.6 通信内容
c-3 における想定メッセージ内容及びサイズの例を表 4.4.1.6-1 に示す。
表 4.4.1.6-1 ユースケース c-3 での想定メッセージ内容及びサイズの例

説明

サイズ

メッセージ種別の識別子

16 bit

車載器 ID

送信元車両の識別子

32 bit

情報更新時刻情報を更新した時刻

32 bit

車両位置

自車両の緯度経度高度情報

88 bit

車両速度

自車両走行速度

16 bit

車両加減速情報

自車両加減速情報

16 bit

車両長さ

自車両長さ情報

16 bit

緊急行動発生時刻

急減速・緊急車線変更を実施した時刻

32 bit

緊急行動種別緊急行動種別

8 bit

対象物情報

車両速度、車両種別

24 bit事象位置情報事象発生の緯度経度高度情報

88 bit

事象距離情報事象発生地点までの距離

16 bit車線情報

事象発生地点の車線情報

8 bit

道路種別情報事象発生地点の道路種別

8 bit

通行可否情報事象発生地点の通行可否情報

8 bit

発信元車載器 ID

事象発生車両の ID

32 bit

配信対象車線情報

リレー先の対象車線

8 bit

情報要素
管理情報 メッセージ ID

車両情報

事象情報

情報有効時間メッセージをリレーする際に有効とみなす時間 32 bit

再配信距離

メッセージをリレーする際に有効とみなす範囲 16 bit
62 byte

合計
4.4.1.7 想定されるメッセージ送信車両台数

ユースケース c-3 においては、各協調走行車は緊急行動実施有無に関わらず、自車情報を周期配信すること及び、緊急行動発生地点から上流 1km の車両がリレー送信を実施しうることから、緊急行動実施車両（１台と想定する）と、緊急行動発生地点から上流 1km までの区間を走行する全協調走行車が送信車両とみなせる。当該区間を走行する車両台数は車両密度に依存するため、以下車両
速度や車両間隔で隊列走行する場合の台数を表 4.4.1.7-1 に示す。尚、表 4.4.1.7-1 においては片側車線の車両のみをカウント対象とした。

―96―

ITS FORUM RC-017
表 4.4.1.7-1 c-3 における送信台数

走行速度

車間距離

120 km/h
100 km/h
80 km/h
60 km/h

2s
2s
2s
2s
1s

車両台数
(6 車線合計)
79 台
97 台
121 台
157 台
277 台

NOTE: 無線容量評価時においては、リレーされる情報の送信方法（各車両の走行情報を配信するための周期送信メッセージにアドオンするか、別メッセージとして送信されるかなど）や、協調走行車が複数の前方車両よりリレーメッセージを受信した場合の挙動などに応じて追加で送信されるメッセージの量も加味する必要がある。

―97―

ITS FORUM RC-017
4.5 交差点の情報による走行支援のユースケース
4.5.1

ユースケース c-2-1. 交差点の情報による走行支援（V2V）

ユースケース c-2-1 では、交差点に接近する車両の位置や速度の情報を、接近車両から交差点に接近または交差点を通過する車両に提供することで、交差点における右折支援を行う。
4.5.1.1 想定シナリオ想定されるシナリオを以下に示す。尚、協調走行車同士の通信となるため右折車両及び、対向車
両は協調走行車と想定した。

① 対向車両は、一定周期で自車の車両情報を周囲の車両へ配信する。

NOTE: 対向車両は、進行予定方向に関わらず周期的な配信を行う。イベントドリブンの送信
トリガは想定しない。
② 右折車両は、対向車からの情報を受信すると、自車のダイナミックマップ上へ反映し、右折可否を判定する。
③ 右折車両は、右折可能と判定した場合、右折を実行する。
4.5.1.2 想定する通信エリア及び、通信距離想定する右折車両と対向直進車両との通信エリアは、1) 右折車両が配信情報を必要とする通信エリア及び、2) 右折車両が検出する対向直進車両の範囲を考慮した。
1) 右折車両が配信情報を必要とする通信エリア-上流側：右折車両のウィンカ ON 位置（停止線から 30m 上流地点）より上流-下流側：右折先終点地点
2) 右折車両が情報を必要とする対向車両の範囲-上流側：交差点中心又は右折待ちポイントを基点とし、交差点内の右折待ちポイントで右折待ちしている状況において、交差点内の右折待ちポイントから安全な加速度で右折を開始し、対向車線を横断し終えることができる位置の対向車。尚、右折待ちポイントが交差点中心を超える場合は、右折待ちポイントを基点とし、その際、右折待ちポイントが複数ある場合は、より対向車線に近いポイントとすること。
-下流側：右折車から対向直進車両を見たときの見通し外（死角）となる位置。当該位置が対向
直進車両が走行する車線の停止線より上流側にくる場合には、停止線位置とする。
想定する右折車両と対向直進車両との通信必要距離は、1 と 2 の間で最も離れる地点間の距離となる。c-2-1 で想定する道路の例における 1、2 及び、右折車両と対向直進車両との通信必要距離は
図 4.4.1.2-1 のようになる。尚、通信相手となる車両は非特定車両である（同報配信）。

―98―

ITS FORUM RC-017

右折車両通信エリア端（上流側）
停止線から30m上流

右折レーン
右折レーン

通信必要距離右折車両が必要とする対向車両の範囲
基点から右折車両が必要とする対向車両範囲上流端までの距離(L)

右折車通信エリア端（下流側）

図 4.5.1.2-1 右折車両と対向車両との通信必要距離(片側 6 車線の場合)

2 について、基点から右折車両が情報を必要とする対向車両の範囲上流端までの距離(L)は、“対向直進車の速度(V1)”に対し、“交差点内の右折待ちポイントから安全な加速度で右折を開始し、対向車線を横断し終えるまでの時間(Tr)及び、右折車遅延時間(Ts)の総和(Tr + Ts)”を乗じることで算出される。尚、Tr は、{ (Lr + Lv) / (D / 2) }^(1/2)で算出される。ここで、以下とする- Lr: 右折待ちポイントから右折完了終了位置までの道程距離(片側 6 車線の場合：39.97[m]、片側 3 車線の場合：16.48[m])- Lv: 右折車両長(5 [m])- D: 右折車両の右折時加速度(2.07 [m/s2])※ただし、右折速度は 30km/h を上限とする。
- Ts: 右折車両のシステムの処理遅延（200ms）と通信遅延(最大 100ms)の合計(0.3 [s])対向直進車両の速度毎の L 及び“右折車両と対向直進車両との所要通信距離”は、表 4.5.1.2-1、表
4.5.1.2-2 のようになる。
表 4.5.1.2-1 L 及び想定する右折車両と対向車両との所要通信距離（片側 6 車線）

対向車両の速度70 km/h
60 km/h
50 km/h
40 km/h
30 km/h

基点から右折車両が情報を必要とす
る対向車両の範囲上流端までの距離(L)
138.2 m118.5m
98.7 m79.0 m59.2 m―99―

所要通信距離190.8 m171.2 m151.7 m132.3 m112.93m

ITS FORUM RC-017
表 4.5.1.2-2 L 及び想定する右折車両と対向車両との所要通信距離（片側 3 車線）

対向車両の速度70 km/h
60 km/h
50 km/h
40 km/h
30 km/h

基点から右折車両が情報を必要とす
る対向車両の範囲上流端までの距離(L)
94.4 m80.9 m67.4 m54.0 m40.5 m

所要通信距離135.3 m121.9 m108.5 m95.0 m81.6 m

4.5.1.3 想定する通信遅延
無線区間許容遅延として 100ms とする。

NOTE: 上記は暫定的な値。必要に応じて値は精査。本遅延が大きい場合、メッセージ配信車両の状
況（位置、速度、方位角など）について、実際の状況と受信車両の認識との間に乖離が発生しえる。
4.5.1.4 想定する通信品質
無線区間許容遅延における 1 メッセージあたりのパケット到達率を 99%以上とする。

NOTE：上記は暫定的な値。必要に応じて値は精査。
4.5.1.5 メッセージ送受信手順
c-2-1 で想定されるメッセージ送受信シーケンスは図 4.5.1.5-1 の通りとなる。
右折車両

対向車両

1. ユースケースc-2-1情報

100ms周期で配信
1. ユースケースc-2-1情報

・・・

図 4.5.1.5-1 メッセージ送受信手順

1 右折車両の対向車両は、100ms 周期でユースケース c-2-1 情報（計測時刻、速度、車長、方路）を送信する。

―100―

ITS FORUM RC-017
4.5.1.6 通信内容
c-2-1 における想定メッセージ内容及びサイズの例を表 4.5.1.6-1 に示す。
表 4.5.1.6-1 ユースケース c-2-1 での想定メッセージ内容の例

説明

サイズ

メッセージ ID

メッセージ種別の識別子

16 bit

インクリメントカウンタ

メッセージ毎にインクリメントする値

8 bit

データ長

後続データ長

8 bit

時刻情報

メッセージ時刻情報

32 bit

車載器 ID

送信元車両の識別子

32 bit

車両位置

車両の緯度経度高度情報

88 bit

車両速度

車両走行速度

16 bit

車両加速度情報

車両の加速度情報

16 bit

車両方位角

車両の方位角16 bit

車両長さ

車両長さ情報16 bit

車両属性情報

車両用途

8 bit

情報要素

管理情報

車両情報

32 byte

合計
4.5.1.7 想定されるメッセージ送信車両台数

本ユースケースにおいては、各協調走行車が周期的に自車両情報を配信するため、交差点において右折車両が通信範囲内にある全協調走行車の数をメッセージ送信車両台数とカウントした。具体的には図 4.5.1.7-1 のように、交差点中央において右折待ちをしている右折車両を中心とし、4.5.1.2
章記載の通信距離を半径とした円に含まれる車両数をカウントした。

―101―

ITS FORUM RC-017

右折レーン
右折レーン
右折レーン
右折レーン

4.5.1.2章の通信距離を半径とする円

図 4.5.1.7-1 右折待ち車両が通信範囲内となる周辺車両

以下を想定した-進行が可能な方路


右折車線以外は簡単のため直進のみを想定し、一定の速度で隊列走行する(車長 5m、車間距離 2s とする)

-

進行が不可能な方路-

右折車線では、右折待ち車両が車長と同等の車間距離で停止している

全車線で車両が車長と同等の車間距離で停止している

全車両が周期的な送信を実施するとし、車両速度や混雑度に応じた送信抑制制御などは適用していない―102―

ITS FORUM RC-017
想定されるメッセージ送信車両台数を表 4.5.1.7-1、表 4.5.1.7-2 に示す。
表 4.5.1.7-1 メッセージ送信車両数(片側 6 車線)

直進車両
速度

通信距離
(4.5.1.2 参照)

車両台数進行が可能な方路
右折車線以外(8 車線)

右折車線(4 車線)

進行が不可能な方路(12 車線)

合計

70 km/h

190.8 m

69 台

76 台

203 台

348 台

60 km/h171.2 m

71 台

68 台

180 台

319 台

50 km/h151.7 m

74 台

69 台

156 台

290 台

40 km/h132.3 m

77 台

52 台

133 台

262 台

30 km/h112.9m

83 台

45 台

110 台

238 台

表 4.5.1.7-2 メッセージ送信車両数(片側 3 車線)

直進車両
速度

通信距離
(4.5.1.2 参照)

車両台数進行が可能な方路
右折車線以外(4 車線)

右折車線(2 車線)

進行が不可能な方路(6 車線)

合計

70 km/h135.3 m

24 台

27 台

74 台

125 台

60 km/h

121.9 m

25 台

24 台

66 台

115 台

50 km/h108.5 m

26 台

21 台

58 台

105 台

40 km/h95.0 m

27 台

19 台

50 台

96 台

30 km/h81.6 m

30 台

16 台

42 台

88 台

―103―

ITS FORUM RC-017
4.5.2

ユースケース c-2-2. 交差点の情報による走行支援（V2I）

ユースケース c-2-2 では、交差点において路側インフラが、信号情報及び、路側センサから取得した交差点に接近する車両の位置や速度の情報を交差点に接近または交差点を通過する車両に提供することで、車両の交差点における右折支援を行う。

NOTE: SIP 協調型自動運転ユースケースでは、路側インフラが対向車両から V2I で情報収集を実施する方法も想定されているが、c-2-2 では路側センサからの情報があること、対向車両が協調走行車の場合には c-2-1 のケースにより右折車への直接的な情報送信が適用可能であることから、本検討においては、対向車両からの V2I の情報収集は検討条件として含めなかった。
4.5.2.1 想定シナリオ想定されるシナリオは以下の通り。尚、本ユースケースは、対向車両として V2X 非対応車両も想定した。

①

路側インフラは、一定周期でユースケース c-2-2 情報を右折車両へ送信する。

②

路側インフラは、路側センサからの計測結果を得ると、検知した車両情報を反映したユー
スケース c-2-2 情報を右折車両へ配信する。

NOTE: 路側センサの検知能力は、最大 5 台/車線を想定する。
NOTE: 路側インフラの情報処理・送信能力は、（路側センサの検知能力） * （車線数）以上と想定する。
③

右折車両は、路側インフラとの通信エリアへ侵入すると、ユースケース c-2-2 情報の受信を開始し、自車のダイナミックマップ上へ反映し、右折可否を判定する。

④

右折車両は、右折可能と判定した場合、右折を実行する。

4.5.2.2 想定する通信エリア及び、路側センサ検知範囲
路側インフラが右折車両へ提供する通信エリアは、c-2-1 における“右折車両が配信情報を必要とする通信エリア”と同じ。
路側センサ検知範囲は、c-2-1 における“右折車両が必要とする対向車両の範囲”と同様の考え方となるが、範囲の上流端については c-2-2 では路側インフラの標準処理遅延(500ms)を加味する必要がある。路側センサの検知範囲の下流側を停止線周辺とした場合の、c-2-2 の、“交差点中心又は右折
待ちポイントを基点とした路側センサ検知範囲(L1)”及び、路側センサの車線方向の検知範囲を、表
4.5.2.2-1、表 4.5.2.2-2 に示す。

―104―

ITS FORUM RC-017
表 4.5.2.2-1 路側センサ検知範囲（6 車線）

対向車両の速度70 km/h
60 km/h
50 km/h
40 km/h
30 km/h

L1 ( = L + (対向車両の速度)*500ms)
148.0 m126.8 m105.7 m84.5 m
63.4 m

路側センサの車線方向の検知範囲
127.0 m105.8 m84.7 m
63.5 m42.4 m

表 4.5.2.2-2 路側センサ検知範囲（3 車線）

対向車両の速度

L1 ( = L + (対向車両の速度)* 500ms)

路側センサの車線方向の検知範囲

70 km/h
60 km/h
50 km/h
40 km/h
30 km/h

104.1 m89.3 m74.4 m59.5 m44.6 m93.6 m
78.7 m
63.9 m49.0 m34.1 mc-2-2 で想定する道路の例における、路側インフラが右折車両へ提供する通信エリア及び、路側セ
ンサ検知範囲を図 4.5.2.2-1 に示す。路側センサが検知対象とする車線は、対向車線すべてを対象とした（最大 6 車線）。尚、通信相手となる車両は非特定車両である（同報配信）。

NOTE: 交差点当たりの路側インフラの数は 1 台以上を想定し、交差点あたりの路側センサの数は
1 台/方路（交差点あたり最大 4 台（方路））を想定する。
右折車両通信エリア端（上流側）
停止線から30m上流
路側インフラ

右折レーン
右折レーン

路側センサ検知範囲

右折車通信エリア端（下流側）

図 4.5.2.2-1 c-2-2 で想定する道路の例における通信エリア及び、路側センサ検知範囲

路車間の通信距離は、路側インフラのアンテナ設置位置に依存する。例えば、図 4.5.2.2-1 のように路側インフラのアンテナが交差点脇に設置される場合、通信距離として最も遠方となるのは同図―105―

ITS FORUM RC-017
における右折予定車両の通信エリア侵入時となる。この時の路側インフラのアンテナ高を 6m とした場合の所要通信距離を表 4.5.2.2-3 に示す。

NOTE: 路側インフラのアンテナ高は参考資料[1] 付属資料 4 を参考とした。
表 4.5.2.2-3 c-2-2 における所要通信距離の例

片側車線数
6 車線
3 車線

所要通信距離75.2 m52.4 m

4.5.2.3 想定する通信遅延
路車間の無線区間許容遅延として 100ms とする。

NOTE: 上記は暫定的な値。必要に応じて値は精査。本遅延が大きい場合、対向車線上の車両の状況（位置、速度など）について、実際の状況とメッセージ受信車両の認識との間に乖離が発生しえる。
4.5.2.4 想定する通信品質
無線区間許容遅延における 1 メッセージあたりのパケット到達率を 99%以上とする。

NOTE：上記は暫定的な値。必要に応じて値は精査。
4.5.2.5 メッセージ送受信手順
c-2-2 で想定されるメッセージ送受信シーケンスを図 4.5.2.5-1 に示す。

NOTE：図 4.5.2.5-1 では、路側インフラの標準処理遅延を 500ms と想定した。

―106―

ITS FORUM RC-017

路側センサ

右折車両

路側インフラ

計測結果(計測無）1.ユースケースc-2-2情報（計測なし）
100ms周期で配信
2. 計測結果(車両A情報）
1a.ユースケースc-2-2情報（計測なし）

2a. 計測結果(車両A情報）
1a.ユースケースc-2-2情報（計測なし）

3. 計測結果(車両A、車両B情報）
1a.ユースケースc-2-2情報（計測なし）

3a. 計測結果(車両A、車両B情報）
1a.ユースケースc-2-2情報（計測なし）

3a. 計測結果(車両A、車両B情報）
1a.ユースケースc-2-2情報（計測なし）

3a. 計測結果(車両A、車両B情報）
4.ユースケースc-2-2情報（車両A情報）3a. 計測結果(車両A、車両B情報）
4a.ユースケースc-2-2情報（車両A情報）3a. 計測結果(車両A、車両B情報）
5.ユースケースc-2-2情報（車両A情報、車両B情報）

3a. 計測結果(車両A、車両B情報）
5a.ユースケースc-2-2情報（車両A情報、車両B情報）
・・・

・・・

図 4.5.2.5-1 メッセージ送受信手順―107―

ITS FORUM RC-017

NOTE: 計測センサと路側インフラ間の破線は、計測センサの正常動作を通知するために、計測なしを通知する場合を示す。計測センサの正常動作が通知できればそれ以外の方法でも問題ない。
1/1a 路側インフラは、100ms 周期でユースケース c-2-2 情報を送信する。路側センサからの情報提供がないため、計測結果（計測時刻、速度、車長）なしを右折車両へ送信する。

NOTE:一つの路側インフラから、交差点の全方路向けの信号情報を送信することも想定される。
2/2a 路側センサは対向車両 A を検知すると路側インフラへ計測結果を提供する。

NOTE: 路側センサが提供する位置情報は、交差点からの距離情報（緯度経度ではない）を想定する
3/3a 路側センサは対向車両 B を検知すると路側インフラへ計測結果を提供する。
4/4a 路側インフラは、車両 A 情報を含むユースケース c-2-2 情報を送信する。
5/5a 路側インフラは、車両 A 情報及び、車両 B 情報を含むユースケース c-2-2 情報を送信する。
4.5.2.6 通信内容
c-2-2 における想定メッセージ内容及びサイズの例については、参考資料[2]における「別添４ Ｉ
ＴＳ無線路側機

通信アプリケーション共通規格 東京臨海部実証実験版」及び「別添５ ＩＴＳ

無線路側機 ＤＳＳＳ及び自動走行システム用 路車間通信アプリケーション規格

東京臨海部実証実験版」を参考に検討を行った。
ユースケース c-2-2 情報で送信される情報として、信号情報、車両検知情報、交差点識別情報を想定した。情報配信の方法は以下のいずれも可能とすることを想定し、いずれの配信方法とするかは路側インフラ実装依存である（例えば、セキュリティの要件、適用する無線方式、機器の制約、路側インフラ設置位置といった運用の制約等が考慮されて選択される）。
- 配信方法①：3 つの情報を 1 つのメッセージとして構成し、100ms 周期配信タイミングで配信する- 配信方法②：3 つの情報を複数のメッセージとして構成し、各メッセージ個別の 100ms 周期配
信タイミングで配信する(例えば、信号情報と交差点識別情報で 1 メッセージ、車両検知情報で 1
メッセージ)

NOTE: 配信方法②では、セキュリティ情報は各メッセージに対して付与される。

―108―

ITS FORUM RC-017


共通ヘッダ
共通ヘッダは、信号情報、交差点識別情報、車両検知情報のそれぞれに付与され、メッセージ ID、

インクリメントカウンタ、送信時刻などの情報要素が含まれる。情報要素やサイズなどの詳細については、ユースケース b-1-1 シナリオ検討における表 3.3.1.6-1 を参照する。サイズは 20 byte を想
定する。



信号情報
信号情報は、各方路における信号機の灯色情報や信号サイクル情報などが含まれる。情報要素やサイズなどの詳細については、ユースケース b-1-1 シナリオ検討資料における表 3.3.1.6-2 を参照する。ただし、ユースケース c-2-2 情報のメッセージサイズ算出においては以下を考慮する：-

想定する道路条件は 4.3.2 章のものを適用する-

想定する最大方路数分の有効な歩灯器情報を含める（青、青点滅、赤の 3 変化）

c-2-2 における信号情報のサイズは、共通ヘッダ（20byte）を含めると 378 byte となる。
交差点識別情報
交差点識別情報は、交差点 ID とダイナミックマップで規定された交差点 ID とを紐付ける情報が含まれる。情報要素やサイズなどの詳細については、ユースケース b-1-1 シナリオ検討資料における表 3.3.1.6-3 を参照する。c-2-2 における交差点識別情報のサイズは、共通ヘッダ（20byte）を含
めると 62 byte となる。


車両検知情報車両検知情報は、路側センサ情報や路側センサが検知した車両の速度や位置などの情報が含まれる。c-2-2 における想定メッセージ内容及びサイズの例(車両検知情報)を表 4.5.2.6-1 に示す。

―109―

ITS FORUM RC-017
表 4.5.2.6-1 ユースケース c-2-2 での想定メッセージ内容及びサイズの例(車両検知情報)

構成 DF/DE
DF_提供点管理番号
DE_都道府県コード
DE_提供点種別コード
DE_交差点 ID/単路 ID
DE_センサ ID
DE_システム状態
DE_センサバージョン
DE_位置種別
DE_システム設計遅延時間
DE_再送遅延時間
DF_車道検知エリア情報
DE_方路 ID
DE_基点ノード ID
DE_基点から近端までの道程距離
DE_基点から遠端までの道程距離
DE_車道検知エリア単位数(I)DF_車道検知エリア単位(1)DE_検知対象車線
DE_四輪車存在有無
DE_二輪車存在有無
DE_予備 6
DE_予備 8DE_予備 8
DE_四輪検知数上限フラグ
DE_四輪情報格納数(J)DF_四輪車両情報(1)
DE_速度
DE_基点からの道程距離
DE_拡張領域サイズ…
DF_四輪車両情報(J = 5)
省略(サイズは同上)
DE_二輪検知上限フラグ
DE_二輪情報格納数(K)…
DF_車道検知エリア単位(I = 3 or 6)
省略(サイズは同上)

サイズ[bit]

値(※1)

備考

8
1
15
8
8
8
1
7

合計
(※1)参考として一部の情報要素に値を記入している

8
8
16
16
8

3 or 6

16
1
1
6
8
8
1
7

5

8
16
16

0

1
7

0

440 byte(片側 3 車線)824 byte(片側 6 車線)c-2-2 における車両検知情報のサイズは、共通ヘッダ（20byte）を含めると 460 byte（片側 3 車線） 、844 byte（片側 6 車線）となる。

―110―

ITS FORUM RC-017

NOTE：4 方路分の車両検知情報に対して 1 つの共通ヘッダが付与される前提で算出した。
NOTE：ある交差点において同時に右折支援を必要とする方路は 4 方路の内の一部（例えば、2 方路）であることが想定されるが、路側インフラの実装としては常に全方路の車両検知情報を配信するという実装も想定されるため、車両検知情報のメッセージサイズ計算においては 4 方路分を考慮する。
4.5.2.7 想定されるメッセージ送信車両台数
本検討では、対向車から路側機への V2I での情報配信は検討条件として含めない。
4.6 参考文献[1] 自動運転(自専道)通信活用ユースケース向け通信システムの実験用ガイドライン ITS FORUM
RC-015 1.0 版 https://itsforum.gr.jp/Public/J7Database/p64/ITS_FORUM_RC-015_v10.pdf[2] 平成 30 年度成果報告書 戦略的イノベーション創造プログラム（SIP）第 2 期／自動運転（システムとサービスの拡張）／自動運転の実現に向けた信号情報提供技術等の高度化に係る調査
https://www.nedo.go.jp/content/100890621.pdf―111―

ITS FORUM RC-017

［余白］

―112―

ITS FORUM RC-017

第5章

d.先読み情報：走行計画変更のユースケース

5.1 前提条件
5.1.1

通信システムの前提

以下の図に示す通信システムでユースケースシナリオを想定した。
通信として、V2I、V2N の優先順はなく、想定シナリオの状況下で利用可能なものを使用する。
・キャリア広域網 ユニキャスト

図 5.1.1-1 キャリア広域網 ユニキャスト―113―

ITS FORUM RC-017
・キャリア広域網 ブロードキャスト

図 5.1.1-2 キャリア広域網 ブロードキャスト

なお、路側インフラ、および管理サーバは以下の役割を持つことを想定した。
(1)路側インフラ・周辺車両の位置情報（緯度経度情報）は管理しない。
・車両から受信した車路間メッセージを管理サーバへ送信する。
・管理サーバから受信した路車間メッセージを通信エリア内の車両へブロードキャスト配信する。
(2)管理サーバ・周辺車両の位置情報（緯度経度情報）を管理する。[※1]・路側インフラのエリア情報を管理する。
・車両から受信したメッセージをもとに、事象を判断する。
（発生事象の判断・確認）・車両から受信したメッセージをもとに、メッセージを加工する。
（発生事象を確認し、必要に応じてメッセージに通行可否情報を付与する。
・メッセージを配信するエリアを判断する。
・V2N でメッセージを周辺車両へ配信する。
配信するエリア内の車両を特定してユニキャストにて配信する。
または配信するエリア内へブロードキャスト[※2]にて配信する。

―114―

ITS FORUM RC-017（周期的（7.65s 毎（仮）[※3]）に配信する）
・V2I でメッセージを路側インフラ経由にて周辺車両へ配信する。
配信するエリア内の路側インフラを特定して送信する。
（路車間メッセージを周期的（1s 毎（仮））に送信する。）[※1] 前提として、周辺車両の詳細位置の情報が定期的に管理サーバへ収集されていることを想定。
[※2] ブロードキャスト（MBMS 等）で配信することは、将来的な可能性として想定。
[※3] 詳細は 5.1.6 節にて説明する。
補足：サーバ構成について
・現状想定としては、サーバ構成は負荷分散のため、以下の図の様にエリア（都道府県などの単位）毎に分けて、設置されているものと想定した。

図 5.1.1-3 サーバ構成（想定）―115―

ITS FORUM RC-017
また、以下の項目はユースケース d での共通事項としてまとめた。
5.1.2

想定する道路条件

高速道路および一般道を想定した。
想定速度(自動運転車両)
上限：高速道路/120km/h、一般道路/60km/h
下限： 20km/h
本ユースケースにおける走行支援の対象とする車両は、現時点では自動運転車両とした。
一般車両については、想定速度および回避行動に必要な時間（距離）などの条件の特定が難しい
ため今後の検討課題とした。
5.1.3

路側インフラの設置条件

路側インフラのみではすべての道路をカバーしきれないため、渋滞多発地点など発生頻度の高い
場所、およびその上流エリアへの設置を推奨する。
5.1.4

無線通信エリアの条件

・想定する無線通信エリアの最小範囲は 33.3m×2 とした。
通信エリア内で車両との通信が最低 1 回行えることを想定するが、通信環境が悪い場合を考慮して 2 回行なえることを想定した。
※車両の速度上限を 120km/h（33.3m/s）、通信の間隔を 1s とした場合、車両が通信エリアにどのタイミングで進入しても 2 回通信を行なうには、33.3m×2=66.6m
必要のため

図 5.1.4-1 無線通信エリアの条件―116―

ITS FORUM RC-017
5.1.5

広域通信におけるサービス提供エリアの考え方

・安全な車線変更に必要な距離（SD：Safty Distance、下図参照)
周辺車両はハザード発生地点に到達する 255m 前にハザード情報を受信することで安全な車線変更が行えると仮定した。
・ハザード情報を受信したいエリア
時速 120km/h で走行する車両は、30s で 1km 進むため、余裕もって車線変更させるための準備期間は 255m～1km と仮定した。
これらより、サービス提供エリアを 1km とする。
なお、d-2 逆走車の通知による走行支援のユースケースにおいては、逆走車と情報通知が必要な車両との相対速度が高まるため他のユースケースの倍の上流にむかって 2km を対象の範囲
とする。

補足：
ハザード情報は、管理サーバ側(道路管理者)でハザードの発生を認識してから配信される。そのため、異常が発生し管理者がハザードを認識、情報を配信するまでに時間が生じる。この間に
SD 以遠にいた車両が異常車両に接近し SD 以内でハザード情報を受信することが考えられるが、その場合は V2V での緊急回避や、自律センサによる回避を行うものと想定した。
SD

図 5.1.5-1 サービス提供エリア―117―

ITS FORUM RC-017
5.1.6

広域通信（V2N）活用の考え方

・V2N のユニキャスト通信でのサービス提供のための通信頻度を 7.65 秒／回[※1][※2]と設定した。
このインターバルで車両からのアップリンクで管理サーバへ必要な情報が伝達される。
また、同時にダウンリンクで、現在発生中の事象情報が管理サーバから各車両へ伝えられる。
この時、管理サーバは発生事象の位置情報と各車両の位置情報を鑑み、有効なエリア内に存在する車両に対してのみ当該情報を配信する。
情報を受け取った各車両は自車の位置情報、速度情報から有効なエリア内の情報であるかを判断して、当該情報の走行計画変更への活用を判断する。
※1：時速 120km/h で走行する車両の場合は、255m 進むには 7.65s となる。
※2：定周期に車両情報を管理サーバへ送信しているため、セッションが張られている前提で、通信頻度を検討。

・なお、将来の可能性として、ダウンリンクでは管理サーバが指定するエリアへのブロードキ
ャスト配信もスコープに入れるものとする。
5.1.7

通信遅延

本ユースケースでは、先読みによる走行支援のため、即応性は不要として規定しない。

―118―

ITS FORUM RC-017
5.2 先読み情報：走行計画変更のユースケース
5.2.1

ユースケース d-1. 異常車両の通知による走行支援

5.2.1.1 通信の目的
異常車両の通知による走行支援
5.2.1.2 通信の概要
道路上に停止している異常車両の事象情報（故障者、事故車、等）と位置情報（存在区間、レーン）を、インフラから車両周辺に提供または異常車両から周辺車両に提供し、早めの車線変更、走行計画変更の支援を行なう。
5.2.1.3 ハザード情報の配信方法
異常車両は、車両に異常が発生すると、自動でのハザード検出または手動でのスイッチ操作により、ハザード情報を管理サーバへ送信する。
管理サーバは、異常車両からハザード情報を受信すると、周辺車両へ早めの車線変更や走行計画変更を行なえるようにハザード情報を配信するエリアを判断して、異常車両のハザードが解消[※1]されるまで、周辺車両へハザード情報を周期的に提供する。
※1：道路管理者により異常車両および周辺の安全を確認後に何らかの手段で管理サーバと連携して解消を通知することを想定した。

異常車両から管理サーバへハザード情報を送信する通信手段（アップリンク側）は、キャリア広域通信網のネットワーク(V2N)と路側インフラ(V2I)を使用する。
管理サーバから周辺車両へハザード情報を配信する通信手段（ダウンリンク側）も、キャリア広域通信網のネットワーク(V2N)と路側インフラ(V2I)を使用する。
V2N と V2I の配信方法のイメージを以下の(1)(2)に示す。
(1) V2N(a) アップリンク側
異常車両は、キャリア広域通信網の通信エリア内であれば、ネットワーク（基地局）経由にて、管理サーバへハザード情報を即時送信する。
※管理サーバは、ハザード情報を重複して受信した場合は、1 つのハザード情報として扱
う。

―119―

ITS FORUM RC-017(b) ダウンリンク側(i) ユニキャスト方式
管理サーバは、ハザード情報を配信するエリア内の車両を特定[※1]して、キャリア広域通信網のネットワーク（基地局）経由にて、周辺車両へハザード情報をユニキャスト配信する。異常車両のハザードが解消されるまで、7.65s 毎（仮定）に周期的に配信する。
※1：前提として、周辺車両の位置情報が定期的に管理サーバへ収集されている想定。
(ii) ブロードキャスト方式
管理サーバは、ハザード情報を配信するエリアを特定して、キャリア広域通信網のネットワーク（基地局）経由にて、配信するエリア内へハザード情報をブロードキャスト配信する。[※2]
異常車両のハザードが解消されるまで、7.65s 毎（仮定）に周期的に配信する。
※2：将来的な可能性としてブロードキャスト(MBMS 等)での配信を想定。

・ユニキャスト・ブロードキャスト

図 5.2.1.3-1 V2N における配信方法―120―

ITS FORUM RC-017(2) V2I(a) アップリンク側
異常車両は、路側インフラ（直近）の通信エリア内であれば、路側インフラ経由にて、管理サーバへハザード情報を送信する。
(b) ダウンリンク側
管理サーバは、ハザード情報を配信するエリアを判断して、配信する対象エリア内の路側
インフラ経由にて、周辺車両へハザード情報を配信する。
※管理サーバは、ハザード情報を重複して受信した場合は、1 つのハザード情報として扱う。
異常車両のハザードが解消されるまで、1s 毎（仮定）に周期的に配信する。

図 5.2.1.3-2 V2I における配信方法―121―

ITS FORUM RC-017
5.2.1.4 想定シナリオ
異常車両の通知による走行支援で想定されるシナリオは以下の通り(1) V2N 活用想定(a) ユニキャスト配信①異常車両は、自動でのハザード検出または手動でのスイッチ操作を契機に、ハザード情報をキャ
リア広域通信網のネットワーク（基地局）を経由して管理サーバへ送信する。
※ハザード情報は路側インフラ経由でも管理サーバへ送信する。（シナリオ(2)V2I を参照）②管理サーバは、異常車両から受信したハザード情報をもとに配信するエリアを判断する。
なお、管理サーバは、ハザード情報を重複して受信した場合は、１つのハザード情報として扱う。
③管理サーバは、ハザード情報を配信するエリア内の車両を特定して、配信対象エリア内のキャ
リア広域通信網のネットワーク（基地局）経由にて、周辺車両へハザード情報を周期的にユニキャストにて配信する。
※ハザード情報は路側インフラ経由でも周辺車両へ配信する。（シナリオ(2)V2I を参照）
④周辺車両は、ハザード情報を受信して、自車のダイナミックマップ上へ本線車両情報を反映して、自車の走行計画の見直しを行なう。
⑤道路管理者は、異常車両および周辺の安全を確認後、管理サーバからのハザード情報の配信を停止する。
(b) ブロードキャスト配信①異常車両は、自動でのハザード検出または手動でのスイッチ操作を契機に、ハザード情報をキャ
リア広域通信網のネットワーク（基地局）を経由して管理サーバへ送信する。
※ハザード情報は路側インフラ経由でも管理サーバへ送信する。（シナリオ(2)V2I を参照）
②管理サーバは、異常車両から受信したハザード情報をもとに配信するエリアを判断する。
なお、管理サーバは、ハザード情報を重複して受信した場合は１つのハザード情報として扱う。
③管理サーバは、ハザード情報を配信するエリアを判断して、キャリア広域通信網のネットワー
ク（基地局）経由にて、周辺車両へハザード情報を周期的にブロードキャストにて配信する。
※ハザード情報は路側インフラ経由でも周辺車両へ配信する。（シナリオ(2)V2I を参照）
④周辺車両は、ハザード情報を受信して、自車のダイナミックマップ上へ本線車両情報を反映して、自車の走行計画の見直しを行なう。
⑤道路管理者は、異常車両および周辺の安全を確認後、管理サーバからのハザード情報の配信を
停止する。

―122―

ITS FORUM RC-017(2) V2I 活用想定
①異常車両は、自動でのハザード検出または手動でのスイッチ操作を契機に、異常車両が路側
インフラ（直近）の通信エリア内の場合は、ハザード情報を路側インフラ経由にて管理サー
バへ送信する。
※ハザード情報はキャリア広域通信網のネットワーク（基地局）経由でも管理サーバへ送信する。（シナリオ(1)V2N を参照）
②管理サーバは、異常車両から受信したハザード情報をもとに配信するエリアを判断する。
なお、管理サーバは、ハザード情報を重複して受信した場合は、１つのハザード情報として扱う。
③管理サーバは、配信対象エリア内の路側インフラ経由にて、周辺車両へハザード情報を周期的にブロードキャストにて配信する。
※ハザード情報はキャリア広域通信網のネットワーク（基地局）経由でも周辺車両へ配信する。
（シナリオ(1)V2N を参照）
④周辺車両は、ハザード情報を受信して、自車のダイナミックマップ上へ本線車両情報を反映して、自車の走行計画の見直しを行なう。
⑤道路管理者は、異常車両および周辺の安全を確認後、管理サーバからのハザード情報の配信を停止する。

―123―

ITS FORUM RC-017
5.2.1.5 通信シーケンスと内容
ユースケース d-1 で異常車両情報の提供に想定されるメッセージ送受信シーケンスは下図の通りとなる。
(1) V2N 活用想定(a) ユニキャスト方式

車両 A（異常車両）

通信インフラ
（基地局）

管理サーバ

通信インフラ（基地局）

車両 B

1.ユースケース d-1-a 情報（車両情報：
車両 ID＋発生時刻＋
速度＋緯度経度高度）7.65s 周期で送信

1.ユースケース d-1-a 情報（車両情報)

2.ユースケース d-1-a 情報（異常車両情報：
車両 ID＋発生時刻＋
発生事象(ハザード種別)＋

7.65s 周期で送信

緯度経度高度＋
異常発生

距離＋レーン情報/上下線＋
道路種別等 ）
1.ユースケース d-1-a 情報（車両情報）

発生を認識

3.ユースケース d-1-b 情報（異常車両情報＋通行可否情報）

7.65s 周期で送信

1.ユースケース d-1-a 情報（車両情報）
3.ユースケース d-1-b 情報（異常車両情報＋通行可否情報

1.ユースケース d-1-a 情報）（車両情報）

7.65s 周期で3.ユースケース d-1-b 情報（異常車両情報＋通行可否情報）

送信

1.ユースケース d-1-a 情報（車両情報)
3.ユースケース d-1-b 情報

4.ユースケース d-1-a 情報
異常解消（異常車両情報＋通行可否情報（異常車両情報））※異常車両がメッセージ送信可能な状態であれば異常解消を伝達する
解消を認識

図 5.2.1.5-1 ユースケース d-1(V2N、ユニキャスト)で想定されるメッセージ送信シーケンス―124―

ITS FORUM RC-017
1. 車両は周期的に自車の位置情報を含む d-1-a 情報（車両情報：車両 ID＋発生時刻＋速度＋
緯度経度高度）を管理サーバに送信する。
2. 車両は、自動でのハザード検出または手動でのスイッチ操作を契機に、管理サーバへ即時に
ユースケース d-1-a 情報（異常車両情報：車両 ID＋発生時刻＋発生事象(ハザード種別)＋
緯度経度高度＋距離＋レーン情報/上下線＋道路種別等）を送信する。
管理サーバでは、提供された異常車両情報に対して、以下の判断を行なう。
-

提供された異常車両情報の妥当性を道路管理者などにより認証する。

-

すでに提供されている異常車両情報と重複するかを判断して、重複であれば後発の異常車両情報は破棄する。

3. 管理サーバは、異常車両情報が認証されてからハザードが解消されるまで、車両から 7.65s
周期の位置情報の提供を受けると、ハザード情報を配信する対象エリア内かを判断して、車両への応答でユースケース d-1-b 情報（異常車両情報＋通行可否情報）を送信する。なお、
ハザード情報を配信する対象エリア外であれば、車両への応答は送信しない。
4. 車両でのハザード解消検出または管理サーバ側でのハザード解消確認等により、道路管理者によってハザード解消の妥当性が認証された場合、車両への配信情報 d-1-b 情報の送信を停止する。

―125―

ITS FORUM RC-017(b) ブロードキャスト方式
車両 A（異常車両）

通信インフラ（基地局）

通信インフラ
（基地局）

管理サーバ

車両 B

1.ユースケース d-1-a 情報（異常車両情報：
車両 ID＋発生時刻＋
発生事象(ハザード種別)＋
緯度経度高度＋
距離＋
異常発生

レーン情報/上下線＋
道路種別等

）

2.ユースケース d-1-b 情報

発生を認識（異常車両情報＋
通行可否情報2.ユースケース d-1-b 情報（異常車両情報＋）

通行可否情報）7.65s 周期で送信

2.ユースケース d-1-b 情報

2.ユースケース d-1-b 情報（異常車両情報＋（異常車両情報＋
通行可否情報

異常解消

通行可否情報））3.ユースケース d-1-a 情報（異常車両情報）※異常車両がメッセージ送信可能な状態であれば異常解消を伝達する

解消を認識
3. 解消（配信停止）を通知する

3. 解消（配信停止）を通知する

図 5.2.1.5-2 ユースケース d-1(V2N、ブロードキャスト)で想定されるメッセージ送信シーケンス―126―

ITS FORUM RC-017
1.

車両は、自動でのハザード検出または手動でのスイッチ操作を契機に、管理サーバへ即時にユースケース d-1-a 情報（異常車両情報：車両 ID＋発生時刻＋発生事象(ハザード種別)＋緯度経度高度＋距離＋レーン情報/上下線＋道路種別等）を送信する。
管理サーバでは、提供された異常車両情報に対して、以下の判断を行なう。
-

提供された異常車両情報の妥当性を道路管理者などにより認証する。

-

すでに提供されている異常車両情報と重複するかを判断して、重複であれば後発の異常車両情報は破棄する。

2.

管理サーバは、異常車両情報を認証すると、ハザード情報を配信する対象エリア内へ 7.65s
周期で d-1-b 情報（異常車両情報＋通行可否情報）をブロードキャストで送信する。

NOTE:ブロードキャストでは対象エリアと配信基地局の紐づけをキャリア網にて実施する想定。
3.

車両でのハザード解消検出または管理サーバ側でのハザード解消確認等により、道路管理者によってハザード解消の妥当性が認証された場合、通信インフラ(基地局)にハザードの解消が通知され、ブロードキャスト配信を停止する。

―127―

ITS FORUM RC-017(1) V2I 活用想定
車両 A
（異常車両）

路側インフラ

管理サーバ

車両 B

路側インフラ1.ユースケース d-1-a 情報（異常車両情報：
車両 ID＋発生時刻＋
発生事象(ハザード種別)＋
緯度経度高度＋
距離＋
レーン情報/上下線＋

異常発生

道路種別等 ）

2.ユースケース d-1-b 情報

発生を認識

2.ユースケース d-1-b 情報（異常車両情報＋（異常車両情報＋

通行可否情報通行可否情報））7.65s 周期で
送信
1s 周期で1s 周期で

送信

送信

2.ユースケース d-1-b 情報

2.ユースケース d-1-b 情報（異常車両情報＋（異常車両情報＋

通行可否情報通行可否情報））1s 周期で1s 周期で

送信

送信

3.ユースケース d-1-a 情報
異常解消（異常車両情報）※異常車両がメッセージ送信可能な状態であれば異常解消を伝達する

解消を認識

3. 解消（配信停止）を通知する

3. 解消（配信停止）を通知する

図 5.2.1.5-3 ユースケース d-1(V2I)で想定されるメッセージ送信シーケンス―128―

ITS FORUM RC-017
1. 車両は、自動でのハザード検出または手動でのスイッチ操作を契機に、管理サーバへ即時に
ユースケース d-1-a 情報（異常車両情報：車両 ID＋発生時刻＋発生事象(ハザード種別)＋
緯度経度高度＋距離＋レーン情報/上下線＋道路種別等）を送信する。
管理サーバでは、提供された異常車両情報に対して、以下の判断を行なう。
-

提供された異常車両情報の妥当性を道路管理者などにより認証する。

-

すでに提供されている異常車両情報と重複するかを判断して、重複であれば後発の異常車両情報は破棄する。

2. 管理サーバは、異常車両情報を認証すると、ハザード情報を配信する対象エリア内の路側インフラへ 7.65s 周期で d-1-b 情報（異常車両情報＋通行可否情報）を送信する。路側インフ
ラは、1s 周期で d-1-b 情報（異常車両情報＋通行可否情報）を通信エリア内にブロードキャ
ストで送信する。
3. 車両でのハザード解消検出または管理サーバ側でのハザード解消確認等により、道路管理者によってハザード解消の妥当性が認証された場合、路側インフラにハザードの解消が通知され、ブロードキャスト配信を停止する。

―129―

ITS FORUM RC-017
5.2.1.6 メッセージサイズ(1) d-1-a 情報：車路間通信
表 5.2.1.6-1 ユースケース d-1 で想定される車路間通信のメッセージサイズ

データ名

データサイズ

管理情報

説明

メッセージ ID

8bit

メッセージを特定する ID

車両 ID

32bit

送信元の車両 ID
最大 20 ハザード分

個別ハザード情報
発生時刻

32bit

ハザードが発生した時刻

発生事象(ハザード種別)

8bit

発生事象を通知

速度

16bit

走行速度

経度緯度高度

88bit

ハザード発生地点

距離

16bit

レーン情報/上下線

4bit

ハザード発生レーン

道路種別等

8bit

道路種別

通行情報

通行可否情報8bit

通行可否の情報

―

(空き)

4bit

―

事象情報

地点情報

配信する距離(ハザード発生地点からの距離)(2) d-1-b 情報：路車間通信
表 5.2.1.6-2 ユースケース d-1 で想定される路車間通信のメッセージサイズ

データ名
管理情報

データサイズメッセージ ID

8bit

路側機 ID

32bit

説明
メッセージを特定する ID
送信元の路側機 ID
送信元が管理サーバの場合は未定
最大 20 ハザード分

個別ハザード情報
発生時刻

32bit

ハザードが発生した時刻

発生事象(ハザード種別)

8bit

発生事象を通知

速度

16bit

走行速度

経度緯度高度

88bit

ハザード発生地点

距離

16bit

レーン情報/上下線

4bit

ハザード発生レーン

道路種別等

8bit

道路種別

通行情報

通行可否情報8bit

通行可否の情報

―

(空き)

4bit

―

事象情報

地点情報

―130―

配信する距離(ハザード発生地点からの距離)

ITS FORUM RC-017※基本的に自工会にて検討されている路車間通信メッセージを流用して本ユースケースにおいても適用が可能か検討を進めた。

【補足】●想定されるケースと方針
・異常車両が車線を跨っているケース
例えば車線２と車線３に跨っている場合は、個別ハザード情報×２件分のハザード情報を送信する。

図 5.2.1.6-1 異常車両が車両を跨っているケース

・玉突き衝突等により、複数の異常車両が近接して存在するケース
各々の異常車両からハザード情報を送信する。

図 5.2.1.6-2 複数の異常車両が近接して存在するケース

・周辺車両がハザード情報を重複して受信するケース
例えば、路側インフラ経由と基地局経由の両方から同じハザード情報を受信した場合は、車両側にて重複したハザード情報の取捨を選択する。

―131―

ITS FORUM RC-017
5.2.2

ユースケース d-2. 逆走車の通知による走行支援

5.2.2.1 通信の目的
道路上の逆走車の情報を周辺車両へ伝達し、早めの車線変更や路肩退避を促す。
5.2.2.2 通信の概要
逆走車の位置や速度および逆走車の存在情報を、インフラから周辺車両に提供し、あらかじめ車
線変更等を促して衝突回避の支援を行う。
5.2.2.3 逆走車の検知想定される逆走車両の検知については、以下の通り。
(1) 逆走車両の位置情報および走行レーンから自動的に検知。
場合によっては、手動でのスイッチ操作による検知も想定される。
(2) 周辺車両による逆走車両の検知。
(3) 路側機センサによる逆走車両の検知。
周辺車両への配信方法、通信エリアの条件、通信遅延については 5.1 章に準じる。

―132―

ITS FORUM RC-017
5.2.2.4 想定シナリオ
逆走車の通知による走行支援で想定されるシナリオは以下の通り。
(1) V2N 活用想定(a) ユニキャスト配信①逆走車両、周辺車両は、自動での逆走検出または手動でのスイッチ操作を契機に、ハザード情報をキャリア広域通信網のネットワーク（基地局）を経由して管理サーバへ送信する。
※ハザード情報は路側インフラ経由でも管理サーバへ送信する。（シナリオ(2)V2I を参照）②管理サーバは、受信したハザード情報の妥当性を判断し、逆走と判定した場合には、その情報をもとに配信するエリアを判断する。
なお、管理サーバは、ハザード情報を重複して受信した場合は、１つのハザード情報として扱う。
③管理サーバは、配信対象エリア内のキャリア広域通信網のネットワーク（基地局）を経由して、周辺車両へハザード情報を周期的にユニキャストにて配信する。
※ハザード情報は路側インフラ経由でも周辺車両へ配信する。（シナリオ(2)V2I を参
照）④周辺車両は、ハザード情報を受信して、自車のダイナミックマップ上へ本線車両情報を反映して、自車の走行計画の見直しを行なう。
⑤道路管理者は、逆走車両および周辺の安全を確認後、管理サーバからのハザード情報の配信を停止する。
(b) ブロードキャスト配信①逆走車両またはその周辺車両は、自動でのハザード検出または手動でのスイッチ操作を契機に、
ハザード情報をキャリア広域通信網のネットワーク（基地局）を経由して管理サーバへ送信する。
※ハザード情報は路側インフラ経由でも管理サーバへ送信する。（シナリオ(2)V2I を参照）
②管理サーバは、受信したハザード情報の妥当性を判断し、逆走と判定した場合には、その情報もとに配信するエリアを判断する。
なお、管理サーバは、ハザード情報を重複して受信した場合は、１つのハザード情報として扱う。
③管理サーバは、ハザード情報を配信するエリアを判断して、キャリア広域通信網のネットワー
ク（基地局）経由にて、周辺車両へハザード情報を周期的にブロードキャストにて配信する。
※ハザード情報は路側インフラ経由でも周辺車両へ配信する。（シナリオ(2)V2I を参照）

―133―

ITS FORUM RC-017④周辺車両は、ハザード情報を受信して、自車のダイナミックマップ上へ本線車両情報を反映して、自車の走行計画の見直しを行なう。
⑤道路管理者は、逆走車両および周辺の安全を確認後、管理サーバからのハザード情報の配信を停止する。
(2) V2I 活用想定
①逆走車両、周辺車両は、自動での逆走検出または手動でのスイッチ操作を契機に、異常車両が路側インフラ（直近）の通信エリア内の場合は、ハザード情報を路側インフラ経由で管理サーバへ送信する。また路側機センサによる逆走車両の検出をした場合には、路側インフラから管理サーバへ送信する。
※ハザード情報はキャリア広域通信網のネットワーク（基地局）経由でも管理サーバへ送信する。（シナリオ(1)V2N を参照）
②管理サーバは、受信したハザード情報の妥当性を判断し逆走と判定した場合には、その情報をもとに配信するエリアを判断する。
なお、管理サーバは、ハザード情報を重複して受信した場合は、１つのハザード情報として扱う。
③管理サーバは、配信対象エリア内の路側インフラを経由して、周辺車両へハザード情報を周期的にブロードキャストにて配信する。
※ハザード情報はキャリア広域通信網のネットワーク（基地局）経由でも周辺車両へ配信する。
（シナリオ(1)V2N を参照）
④周辺車両は、ハザード情報を受信して、自車のダイナミックマップ上へ本線車両情報を反映して、自車の走行計画の見直しを行なう。
⑤道路管理者は、逆走車両および周辺の安全を確認後、管理サーバからのハザード情報の配信を
停止する。

―134―

ITS FORUM RC-017
5.2.2.5 通信シーケンスと内容(1) V2N 活用想定
ユースケース d-2 で逆走車両情報の提供に想定されるメッセージ送受信シーケンスは下図の通りとなる。
(a) ユニキャスト方式
車両 A(逆走車両)

通信インフラ
(基地局)

通信インフラ
(基地局)

管理サーバ

車両 B

1.ユースケース d-2-a 情報（車両情報：
車両 ID＋
発生時刻＋
速度＋
緯度経度高度）
7.65s 周期で送信
1.ユースケース d-2-a(車両情報）
2.ユースケース d-2-a 情報（逆走車両情報：
車両 ID＋

7.65s 周期で

発生時刻＋

送信

発生事象(ハザード種別)＋
速度＋緯度経度高度＋
距離＋
逆走発生

レーン情報/上下線＋
道路種別等

）

逆走認識
1.ユースケース d-2-a 情報(逆走車両情報)
3.ユースケース d-2-b 情報（逆走車両情報＋
通行可否情報）1.ユースケース d-2-a 情報(車両情報)
3.ユースケース d-2-b 情報（逆走車両情報＋

4.ユースケース d-2-a 情報

通行可否情報）（逆走車両情報）
逆走解消※逆走車がメッセージ送信可能な状態であれば逆走解消を伝達する。

解消認識
図 5.2.2.5-1 ユースケース d-2(V2N、ユニキャスト)で想定されるメッセージ送信シーケンス―135―

ITS FORUM RC-017

1. 車両は周期的に自車の位置情報を含む d-2-a 情報（車両情報：車両 ID＋発生時刻＋速度＋
緯度経度高度）を管理サーバに送信する。
2. 車両は、自動でのハザード検出または手動でのスイッチ操作を契機に、管理サーバへ即時に
ユースケース d-2-a 情報（逆走車両情報：車両 ID＋発生時刻＋発生事象(ハザード種別)＋
速度＋緯度経度高度＋距離＋レーン情報/上下線＋道路種別等）を送信する。
管理サーバでは、提供された逆走車両情報に対して、以下の判断を行なう。
-

提供された逆走車両情報の妥当性を道路管理者などにより認証する。

-

すでに提供されている逆走車両情報と重複するかを判断して、重複であれば後発の逆走車両情報は破棄する。

3. 管理サーバは、逆走車両情報が認証されてからハザードが解消されるまで、車両から 7.65s
周期の車両情報または逆走車両情報の提供を受けると、ハザード情報を配信する対象エリ
ア内かを判断して、車両への応答でユースケース d-2-b 情報（逆走車両情報＋通行可否情報）を送信する。なお、ハザード情報を配信する対象エリア外であれば、車両への応答は送信しない。
4. 車両でのハザード解消検出または管理サーバ側でのハザード解消確認等により、道路管理者によってハザード解消の妥当性が認証された場合、車両への配信情報 d-2-b 情報は配信が停止される。

―136―

ITS FORUM RC-017(b) ブロードキャスト方式
車両 A（逆走車両）

通信インフラ
(基地局)

管理サーバ

通信インフラ(基地局)

逆走認識

2.ユースケース d-2-b 情報

車両 B

1.ユースケース d-2-a 情報（逆走車両情報：
車両 ID＋
発生時刻＋発生事象(ハザード種別)＋
緯度経度高度＋
距離＋

逆走発生

レーン情報/上下線＋
道路種別等 ）

2.ユースケース d-2-b 情報（逆走車両情報＋（逆走車両情報＋

通行可否情報通行可否情報）7.65s 周期で）7.65s 周期で

送信

送信

3.ユースケース d-2-a 情報（逆走車両情報）
3.ユースケース d-2-b 情報

3.ユースケース d-2-b 情報（逆走車両情報＋（逆走車両情報＋

通行可否情報通行可否情報））4.ユースケース d-2-a 情報（逆走車両情報）
逆走解消※逆走車がメッセージ送信可能な状態であれば逆走解消を伝達する。

逆走解消

4. 解消（配信停止）を通知する

4. 解消（配信停止）を通知する

図 5.2.2.5-2 ユースケース d-2(V2N、ブロードキャスト)で想定されるメッセージ送信シーケンス―137―

ITS FORUM RC-017
1.

車両は、自動でのハザード検出または手動でのスイッチ操作を契機に、管理サーバへ即時にユー
スケース d-2-a 情報（逆走車両情報：車両 ID＋発生時刻＋発生事象(ハザード種別)＋速度＋緯度経度高度＋距離＋レーン情報/上下線＋道路種別等）を送信する。
管理サーバでは、提供された逆走車両情報に対して、以下の判断を行なう。
-

提供された逆走車両情報の妥当性を道路管理者などにより認証する。

-

すでに提供されている逆走車両情報と重複するかを判断して、重複であれば後発の逆走車両情報は破棄する。

2.

管理サーバは、逆走車両情報を認証すると、ハザード情報を配信する対象エリア内へ 7.65s 周期で d-2-b 情報（逆走車両情報＋通行可否情報）をブロードキャストで送信する。

NOTE:ブロードキャストでは対象エリアと配信基地局の紐づけをキャリア網にて実施する想定。
3.

管理サーバは、逆走車両情報が認証されると、逆走車両から 7.65s 周期の d-2-a 情報の提供を受け、情報の更新有無を判断する。更新がある場合、更新された情報をブロードキャストにて
送信する。

4.

車両でのハザード解消検出または管理サーバ側でのハザード解消確認等により、道路管理者によってハザード解消の妥当性が認証された場合、通信インフラ(キャリア網)にハザードの解消が通知され、ブロードキャスト配信を停止する。

―138―

ITS FORUM RC-017(2) V2I 活用想定
車両 A
（逆走車両）

路側インフラ

管理サーバ

路側インフラ

車両 B

1.ユースケース d-2-a 情報（逆走車両情報：
車両 ID＋
発生時刻＋発生事象(ハザード種別)＋
緯度経度高度＋
距離＋
レーン情報/上下線＋
逆走発生

道路種別等 ）

7.65s 周期で送信

逆走認識
2.ユースケース d-2-b 情報

2.ユースケース d-2-b 情報（逆走車両情報＋（逆走車両情報＋

通行可否情報通行可否情報）7.65ns 周期で

1s 周期で1s 周期で

送信

送信

）

送信

3.ユースケース d-2-a 情報（逆走車両情報）
3.ユースケース d-2-b 情報

3.ユースケース d-2-b 情報（逆走車両情報＋（逆走車両情報＋

通行可否情報通行可否情報））1s 周期で1s 周期で

送信

送信

4.ユースケース d-2-a 情報（逆走車両情報）
逆走解消 ※逆走車がメッセージ送信可能な状態であれば逆走解消を伝達する。

逆走解消
4. 解消（配信停止）を通知する

4. 解消（配信停止）を通知する

図 5.2.2.5-3 ユースケース d-2(V2I)で想定されるメッセージ送信シーケンス―139―

ITS FORUM RC-017

1.

車両は、自動でのハザード検出または手動でのスイッチ操作を契機に、管理サーバへ即時にユースケース d-2-a 情報（逆走車両情報：車両 ID＋発生時刻＋発生事象(ハザード種別)＋速度＋緯度経度高度＋距離＋レーン情報/上下線＋道路種別等）を送信する。
管理サーバでは、提供された逆走車両情報に対して、以下の判断を行なう。
-

提供された逆走車両情報の妥当性を道路管理者などにより認証する。

-

すでに提供されている逆走車両情報と重複するかを判断して、重複であれば後発の逆走車両情報は破棄する。

2.

管理サーバは、逆走車両情報を認証すると、ハザード情報を配信する対象エリア内の路側
インフラへ 7.65s 周期で d-2-b 情報（逆走車両情報＋通行可否情報）を送信する。路側イ
ンフラは、1s 周期で d-2-b 情報（逆走車両情報＋通行可否情報）を通信エリア内にブロードキャストで送信する。

3.

管理サーバは、逆走車両情報が認証されると、逆走車両から 7.65s 周期の d-2-a 情報の提供を受け、情報の更新有無を判断する。更新がある場合、更新された情報をブロードキャ
ストにて送信する。

4.

車両でのハザード解消検出または管理サーバ側でのハザード解消確認等により、道路管理者によってハザード解消の妥当性が認証された場合、路側インフラにハザードの解消が通知され、ブロードキャスト配信を停止する。

―140―

ITS FORUM RC-017
5.2.2.6 メッセージサイズ(1) d-2-a 情報：車路間通信
表 5.2.2.6-1 ユースケース d-2 で想定される車路間通信のメッセージサイズ

データ名

データサイズ

管理情報

説明

メッセージ ID

8bit

メッセージを特定する ID

車両 ID

32bit

送信元の車両 ID
最大 20 ハザード分

個別ハザード情報
発生時刻

32bit

ハザードが発生した時刻

発生事象(ハザード種別)

8bit

発生事象(逆走事象識別)を通知

速度

16bit

車両速度

経度緯度高度

88bit

ハザード発生地点

距離

16bit

配信する距離レーン情報/上下線

4bit

ハザード発生レーン

道路種別等

8bit

道路種別

通行情報

通行可否情報8bit

通行可否の情報

―

(空き)

4bit

―

事象情報

地点情報

(ハザード発生地点からの距離)(2) d-2-b 情報：路車間通信
表 5.2.2.6-2 ユースケース d-2 で想定される路車間通信のメッセージサイズ

データ名
管理情報

データサイズメッセージ ID

8bit

路側機 ID

32bit

説明
メッセージを特定する ID
送信元の路側機 ID
送信元が管理サーバの場合は未定
最大 20 ハザード分

個別ハザード情報
発生時刻

32bit

ハザードが発生した時刻

発生事象(ハザード種別)

8bit

発生事象(逆走事象識別)を通知

速度

16bit

車両速度

経度緯度高度

88bit

ハザード発生地点

距離

16bit

配信する距離(ハザード発生地点からの距離)

レーン情報/上下線

4bit

ハザード発生レーン

道路種別等

8bit

道路種別

通行情報

通行可否情報8bit

通行可否の情報

―

(空き)

4bit

―

事象情報

地点情報

※基本的に自工会にて検討されている路車間通信メッセージを流用しても適用が可能か検討を進めた。

―141―

本ユースケースにおいてITS FORUM RC-017
5.2.3

ユースケース d-3. 渋滞の情報による走行支援

5.2.3.1 通信の目的
渋滞情報配信による走行支援、走行計画変更、速度調整、停止動作
5.2.3.2 通信の概要
車両にて計測した車両情報（位置情報や速度情報）は、キャリア広域通信網のネットワーク（基地局）または路側インフラを経由して道路管理者へ送信される。道路管理者にて判定された渋滞有
無情報は、キャリア広域通信網の基地局および路側インフラに通知され、キャリア広域通信網のネッ
トワーク（基地局）からはブロードキャストまたはユニキャスト、路側インフラからはブロードキャ
ストでそれぞれ車両に通知される。
5.2.3.3 渋滞情報の配信方法
車両はエンジン始動から停止までの間、定期的に車両情報（時刻、位置情報、速度情報）を管理サーバに送信する。
管理サーバは、車両から車両情報を受信すると、周辺車両へ早めの車線変更や走行計画変更を行
なえるように渋滞情報を配信するエリアを判断して、渋滞が解消[※１]されるまで、周辺車両へ渋滞情報を周期的に提供する。

※１：道路管理者により渋滞の発生・解消の確認後に何らかの手段で管理サーバと連携して渋滞発生・解消を通知することを想定した。

車両から管理サーバへ車両情報を送信する通信手段（アップリンク側）は、キャリア広域通信網のネットワーク(V2N)と路側インフラ(V2I)を使用する。
管理サーバから周辺車両へ渋滞情報を配信する通信手段（ダウンリンク側）も、キャリア広域通
信網のネットワーク(V2N)と路側インフラ(V2I)を使用する。
V2N と V2I の配信方法のイメージを以下の(1)(2)に示す。
(1) V2N 活用想定(a) アップリンク側
車両は、キャリア広域通信網の通信エリア内であれば、ネットワーク（基地局）経由にて、管理サーバへ車両情報を送信する。
※管理サーバは、車両情報を重複して受信した場合は、1 つの車両情報として扱う。

―142―

ITS FORUM RC-017(b) ダウンリンク側(i) ユニキャスト方式
管理サーバは、渋滞情報を配信するエリア内の車両を特定[※1]して、キャリア広域通信網のネットワーク（基地局）経由にて、周辺車両へ渋滞情報をユニキャスト配信する。
渋滞が解消されるまで、7.65s 毎（仮定）に周期的に配信する。
※1：前提として、周辺車両の詳細位置の情報が定期的に管理サーバへ収集されていることを想定(ii) ブロードキャスト方式
管理サーバは、渋滞情報を配信するエリアを特定して、キャリア広域通信網のネットワー
ク（基地局）経由にて、配信するエリア内へ渋滞情報をブロードキャスト配信する。[※2]
渋滞が解消されるまで、7.65s 毎（仮定）に周期的に配信する。
※2：将来的な可能性としてブロードキャスト(MBMS 等)で配信することを想定。

―143―

ITS FORUM RC-017

・ユニキャスト・ブロードキャスト

図 5.2.3.3-1 V2N における配信方法―144―

ITS FORUM RC-017(2) V2I 活用想定(a) アップリンク側
車両は、路側インフラ（直近）の通信エリア内であれば、路側インフラ経由にて、管理サーバへ渋滞情報を送信する。
通信品質を考慮して、送達の精度をある程度確保するために 1s 間隔（仮定）送信する。
(b) ダウンリンク側
管理サーバは、渋滞情報を配信するエリアを判断して、配信する対象エリア内の路側インフラ経由にて、周辺車両へ渋滞情報を配信する。
※管理サーバは、車両情報を重複して受信した場合は、1 つの車両情報として扱う。
渋滞が解消されるまで、1s 毎（仮定）に周期的に配信する。

図 5.2.3.3-2 V2I における配信方法―145―

ITS FORUM RC-017
5.2.3.4 想定シナリオ
d-3 渋滞の情報による走行支援で想定されるシナリオは以下の通り(1) V2N 活用想定(a) ユニキャスト配信① 車両はエンジン始動から停止までの間、定期的に車両情報（時刻、位置情報、速度情報）をキャリア広域通信網のネットワーク（基地局）を経由して管理サーバへ送信する。
※車両情報は路側インフラ経由でも管理サーバへ送信する。（シナリオ(2)V2I を参照）② 管理サーバは、車両から受信した車両情報をもとに渋滞の発生・解消の判定、および配信するエリアを判断する。
なお、管理サーバは、車両情報を重複して受信した場合は、1 つの車両情報として扱う。
③ 管理サーバは、渋滞情報を配信するエリア内の車両を特定して、配信対象エリア内のキャリ
ア広域通信網のネットワーク（基地局）経由にて、周辺車両へ渋滞情報を周期的にユニキャ
ストにて配信する。
※渋滞情報は路側インフラ経由でも周辺車両へ配信する。（シナリオ(2)V2I を参照）
④ 周辺車両は、渋滞情報を受信して、自車のダイナミックマップ上へ本線車両情報を反映して、自車の走行計画の見直しを行なう。
⑤ 道路管理者は、渋滞の解消を確認後、管理サーバからの渋滞情報の配信を停止する。
(b) ブロードキャスト配信① 車両はエンジン始動から停止までの間、定期的に車両情報（時刻、位置情報、速度情報）をキャリア広域通信網のネットワーク（基地局）を経由して管理サーバへ送信する。
※車両情報は路側インフラ経由でも管理サーバへ送信する。（シナリオ(2)V2I を参照）② 管理サーバは、車両から受信した車両情報をもとに渋滞の発生・解消の判定、および配信するエリアを判断する。
なお、管理サーバは、車両情報を重複して受信した場合は、１つの車両情報として扱う。
③ 管理サーバは、渋滞情報を配信するエリアを判断して、キャリア広域通信網のネットワーク（基地局）経由にて、周辺車両へ渋滞情報を周期的にブロードキャストにて配信する。
※渋滞情報は路側インフラ経由でも周辺車両へ配信する。（シナリオ(2)V2I を参照）
④ 周辺車両は、渋滞情報を受信して、自車のダイナミックマップ上へ本線車両情報を反映して、自車の走行計画の見直しを行なう。
⑤ 道路管理者は、渋滞の解消を確認後、管理サーバからの渋滞情報の配信を停止する。

―146―

ITS FORUM RC-017(2) V2I 活用想定
① 車両はエンジン始動から停止までの間、路側インフラ（直近）の通信エリア内の場合は、定期的に車両情報（時刻、位置情報、速度情報）を路側インフラ経由にて管理サーバへ送信する。
※車両情報はキャリア広域通信網のネットワーク（基地局）経由でも管理サーバへ送信する。（シナリオ(1)V2N を参照）
② 管理サーバは、車両から受信した車両情報をもとに渋滞の発生・解消の判定、および配信するエリアを判断する。
なお、管理サーバは、車両情報を重複して受信した場合は、１つの車両情報として扱う。
③ 管理サーバは、配信対象エリア内の路側インフラ経由にて、周辺車両へ渋滞情報を周期的にブロードキャストにて配信する。
※渋滞情報はキャリア広域通信網のネットワーク（基地局）経由でも周辺車両へ配信する。（シナリオ(1)V2N を参照）
④ 周辺車両は、渋滞情報を受信して、自車のダイナミックマップ上へ本線車両情報を反映して、自車の走行計画の見直しを行なう。
⑤ 道路管理者は、渋滞の解消を確認後、管理サーバからの渋滞情報の配信を停止する。

―147―

ITS FORUM RC-017
5.2.3.5 通信シーケンスと内容
ユースケース d-3 で渋滞情報の提供に想定されるメッセージ送受信シーケンスは下図の通りとなる。
(1) V2N 活用想定(a) ユニキャスト方式
通信インフラ
(基地局)

車両 A

管理サーバ

通信インフラ
(基地局)

車両 B

1.ユースケース d-3-a 情報（個別車両情報：車両 ID＋発生時刻＋
発生事象(ハザード種別)＋走行速度＋
緯度経度高度＋距離＋レーン情報/上下線＋道路種別等）
1.ユースケース d-3-a 情報

7.65s 周期で（個別車両情報）

送信

7.65s 周期で渋滞発生と判定

送信

1.ユースケース d-3-a 情報（個別車両情報）

1.ユースケース d-3-a 情報

2.ユースケース d-3-b 情報（個別車両情報）（個別渋滞情報：発生時刻＋発生事象＋
緯度経度高度+レーン情報/上下線+
通行可否情報等）

2.ユースケース d-3-b 情報（個別渋滞情報）

1.ユースケース d-3-a 情報（個別車両情報）
1.ユースケース d-3-a 情報（個別車両情報）
2.ユースケース d-3-b 情報（個別渋滞情報）

2.ユースケース d-3-b 情報（個別渋滞情報）

渋滞解消と判定

図 5.2.3.5-1 ユースケース d-3(V2N、ユニキャスト)で想定されるメッセージ送信シーケンス―148―

ITS FORUM RC-017

1. 車両はエンジン始動から停止までの間、キャリア広域通信網ネットワークの通信エリア内に位置する場合は、7.65s 周期(仮定)でユースケース d-3-a 情報（個別車両情報：車両 ID＋発生時刻＋発生事象(ハザード種別)＋走行速度＋緯度経度高度＋距離＋レーン情報/上下線＋道路種別等）を提供する。
2.

管理サーバでは、ユースケース d-3-a 情報を基に渋滞の発生・解消の判定、および配信するエリアを判断し、配信する対象エリア内の車両へユースケース d-3-b 情報（個別渋滞情報：発生時刻＋発生事象＋緯度経度高度+レーン情報/上下線+通行可
否情報等）を 7.65s 周期(仮定)で送信する。なお、管理サーバ→周辺車両はサーバ側で車両を特定し個別配信を行う。

―149―

ITS FORUM RC-017(b) ブロードキャスト方式
車両 A

通信インフラ
(基地局)

管理サーバ

通信インフラ
(基地局)

車両 B

1.ユースケース d-3-a 情報（個別車両情報：車両 ID＋発生時刻＋
発生事象(ハザード種別)＋走行速度＋
緯度経度高度＋距離＋レーン情報/上下線＋道路種別等）

7.65s 周期で1.ユースケース d-3-a 情報（個別車両情報）

送信
2.ユースケース d-3-b 情報（個別渋滞情報：発生時刻＋発生事象＋
緯度経度高度+レーン情報/上下線+
通行可否情報等

7.65s 周期で渋滞発生と判定

送信

2.ユースケース d-3-b 情報（個別渋滞情報））

7.65s 周期で1.ユースケース d-3-a 情報（個別車両情報）

送信
1.ユースケース d-3-a 情報（個別車両情報）

2.ユースケース d-3-b 情報（個別渋滞情報）

2.ユースケース d-3-b 情報（個別渋滞情報）

1.ユースケース d-3-a 情報（個別車両情報）
1.ユースケース d-3-a 情報（個別車両情報）
渋滞解消と判定
3.ブロードキャスト配信停止

3.ブロードキャスト配信停止

図 5.2.3.5-2 ユースケース d-3(V2N、ブロードキャスト)で想定されるメッセージ送信シーケンス―150―

ITS FORUM RC-017

1.

車両はエンジン始動から停止までの間、キャリア広域通信網ネットワークの通信
エリア内に位置する場合は、7.65s 周期(仮定)でユースケース d-3-a 情報（個別車
両情報：車両 ID＋発生時刻＋発生事象(ハザード種別)＋走行速度＋緯度経度高度＋距離＋レーン情報/上下線＋道路種別等）を提供する。

2.

管理サーバでは、ユースケース d-3-a 情報を基に渋滞の発生・解消の判定、および配信するエリアを判断し、配信する対象エリア内の車両へユースケース d-3-b 情報（個別渋滞情報：発生時刻＋発生事象＋緯度経度高度+レーン情報/上下線+通行可
否情報等）を 7.65s 周期(仮定)で送信する。

3.

管理サーバ側での渋滞解消の妥当性が確認された場合、通信インフラ(キャリア網)に渋滞解消を通知するメッセージが送信され、ブロードキャスト配信を停止する。

―151―

ITS FORUM RC-017(2) V2I 活用想定
V2I を用いた渋滞情報の提供に想定されるメッセージ送受信シーケンスは下図の通りと
なる。

車両 A

路側インフラ

管理サーバ

路側インフラ

車両 B

1.ユースケース d-3-a 情報（個別車両情報：車両 ID＋発生時刻＋
発生事象(ハザード種別)＋走行速度＋
緯度経度高度＋距離＋レーン情報/上下線＋道路種別等）

7.65s 周期で1.ユースケース d-3-a 情報（個別車両情報）

送信
2.ユースケース d-3-b 情報（個別渋滞情報：発生時刻＋発生事象＋
緯度経度高度+レーン情報/上下線+
1s 周期で通行可否情報等

7.65s 周期で渋滞発生と判定

送信

2.ユースケース d-3-b 情報（個別渋滞情報））

7.65s 周期で送信
1.ユースケース d-3-a 情報（個別車両情報）

送信
1.ユースケース d-3-a 情報（個別車両情報）

2.ユースケース d-3-b 情報（個別渋滞情報）

1.ユースケース d-3-a 情報（個別車両情報）

2.ユースケース d-3-b 情報（個別渋滞情報）

1.ユースケース d-3-a 情報（個別車両情報）

渋滞解消と判定
3. ブロードキャスト配信停止

3. ブロードキャスト配信停止

図 5.2.3.5-3 ユースケース d-3(V2I)で想定されるメッセージ送信シーケンス―152―

1s 周期で
送信ITS FORUM RC-017

1. 車両はエンジン始動から停止までの間、路側インフラからの報知情報の受信し、路側インフラの通信エリア内にいると認識した場合は、ユースケース d-3-a 情報（個別車両情報：車両 ID＋発生時刻＋発生事象(ハザード種別)＋走行速度＋緯度経度高度＋距離＋レーン情報/上下線＋道路種別等）を提供する。なお、同一の路側インフ
ラ通信エリア内での送信周期は V2N のシナリオと同じく 7.65s 周期(仮定)とする。
別の路側インフラの通信圏内に移動した場合は、7.65s 周期(仮定)以内であっても送信可能とする。
2. 管理サーバでは、ユースケース d-3-a 情報を基に渋滞の発生・解消の判定、および配信するエリアを判断し、配信する対象エリア内の車両へユースケース d-3-b 情報（個別渋滞情報：発生時刻＋発生事象＋緯度経度高度+レーン情報/上下線+通行可
否情報等）を 7.65s 周期(仮定)で路側インフラに送信する。
路側インフラは、管理サーバからの d-3-b 情報を周辺車両へ 1s 間隔で同一メッセー
ジを送信する。7.65s 後(仮定)に管理サーバから最新の d-3-b 情報を受信すると、送信情報を更新し同様に 1s 間隔で送信する。
3. 管理サーバ側での渋滞解消の妥当性が確認された場合、路側インフラに渋滞解消が通知され旨を通知し、ブロードキャスト配信を停止する。

―153―

ITS FORUM RC-017
5.2.3.6 メッセージサイズ(1) d-3-a 情報：車路間通信
表 5.2.3.6-1 ユースケース d-3 で想定される車路間通信のメッセージサイズ

データ名

データサイズ

管理情報

説明

メッセージ ID

8bit

メッセージを特定する ID

車両 ID

32bit

送信元の車両 ID
最大 20 車両分※1

個別車両情報
発生時刻

32bit

走行情報を配信する時刻

発生事象(ハザード種別)

8bit(使用しない)

走行速度

16bit

車両速度

経度緯度高度

88bit

車両の位置

距離

16bit

(使用しない)レーン情報/上下線

4bit

車両のレーン

道路種別等

8bit

(使用しない)通行情報

通行可否情報8bit(使用しない)

―

(空き)

4bit

―

事象情報

地点情報

*1：個別車両情報であり自車 1 台分の想定(2) d-3-b 情報：路車間通信
表 5.2.3.6-2 ユースケース d-3 で想定される路車間通信のメッセージサイズ

データ名

管理情報

データサイズメッセージ ID

8bit

路側機 ID

32bit

説明
メッセージを特定する ID
送信元の路側機 ID
送信元が管理サーバの場合は未定
最大 20 渋滞分

個別渋滞情報発生時刻

32bit

渋滞中の現在時刻

発生事象(ハザード種別)

8bit

渋滞を通知

走行速度

16bit

車両速度

経度緯度高度

88bit

渋滞位置

距離

16bit

(使用しない)レーン情報/上下線

4bit

渋滞レーン

道路種別等

8bit

(使用しない？)通行情報

通行可否情報8bit

通行可否の情報

―

(空き)

4bit

―

事象情報

地点情報

―154―

ITS FORUM RC-017※基本的に自工会にて検討されている路車間通信メッセージを流用して本ユースケースにおいても適用が可能か検討を進めた。
●想定されるケースと方針
・渋滞情報を重複して受信するケース
例えば、路側インフラ経由と基地局経由の両方から同じ渋滞情報を受信した場合は、車両側にて重複した渋滞情報の取捨選択する―155―

ITS FORUM RC-017
5.2.4

ユースケース d-4. 分岐・出口渋滞支援

5.2.4.1 通信の目的
路肩渋滞情報の通知による、本線車両の走行計画支援のため
5.2.4.2 通信の概要
路肩渋滞の情報（位置や速度）を、インフラから本線車両に提供し、分岐部進入の支援を行う。
5.2.4.3 分岐・出口渋滞の判断•

分岐・出口には路側インフラ（分岐）が設置されている想定（設置されていない場合はキャリア広域通信網を用いる）•

車両から定期的に送信される車両情報（時刻と位置情報）と分岐・出口のエリア情報を基に、管理サーバで渋滞が発生したことを判断する。
※ 車両はエンジン始動から停止までの間、定期的に車両情報（時刻と位置情報）を管理サーバに送信、管理サーバ側で各車両から送信された情報を基に渋滞の発生、解消等を判断することを想定

5.2.4.4 分岐・出口渋滞情報の配信（V2I、V2N）
管理サーバは情報配信のために以下の処理を行う•

渋滞発生と解消の判断•配信するエリア（配信対象エリア）、周辺の路側インフラの通信エリア、車両の位置情報をもとに、配信方法を判断する（次頁参照）(1) 路側インフラで賄えるエリアへの配信
路側インフラ経由で各車両へブロードキャスト配信する(2) 路側インフラで賄えないエリアへの配信
キャリア広域通信網を通じて車両の位置情報をもとに通知エリア内の各車両へユニキャスト配信する―156―

ITS FORUM RC-017(1) 路側インフラで賄えるエリアへの配信

図 5.2.4.4-1 路側インフラで賄えるエリアへの配信方法(2) 路側インフラで賄えないエリアへの配信

図 5.2.4.4-2 路側インフラで賄えないエリアへの配信方法―157―

ITS FORUM RC-017
5.2.4.5 通信エリアの条件•

分岐・出口渋滞情報を配信するエリア•

分岐から 1km(仮定)手前のエリア
分岐方向に向かう運行計画であった場合、渋滞の状況により計画を見直す（直進）ことも想定、分岐に差し掛かる約 30s 前（120km/h で 1km 走行）に情報を受信するため
分岐手前の渋滞は別のユースケース（d-3 渋滞情報による走行支援）となる想定
同様に分岐から先も上記ユースケースと考える•

高速道路等の一つ前の分岐・出口手前のエリアの配信の場合、手前の分岐・出口での走行計画の変更が可能（一つ手前の出口で一般道に降りる等）•

V2I
分岐から 1km 手前（または一つ前の分岐・出口の手前）に設置されている路側インフラ•

V2N
分岐から 1km 手前（または一つ前の分岐・出口の手前）を走行中の車両
道路上はすべてキャリア網のカバレッジエリアと仮定

図 5.2.4.5-1 サービス提供エリア•

V2N（ユニキャストの場合）

図 5.2.4.5-2 通信エリアの条件(V2N、ユニキャスト)―158―

ITS FORUM RC-017•

V2N (ブロードキャストの場合)

図 5.2.4.5-3 通信エリアの条件(V2N、ブロードキャスト)•

V2I

図 5.2.4.5-4 通信エリアの条件(V2I)―159―

ITS FORUM RC-017
5.2.4.6 想定シナリオ
分岐・出口渋滞支援で想定されるシナリオは以下の通り(1) V2N 活用想定
分岐・出口付近には路側インフラが設置される想定であるが、設置されない場合には、以下のシナリオとなる。
(a) ユニキャスト配信① 車両は車両情報をキャリア広域通信網を通じて管理サーバに送信する② 管理サーバは受信した車両情報を基に分岐・出口エリアの交通状況を監視する。渋滞が発生したと判断した場合、位置情報をもとに配信対象エリアの車両を特定し、分岐・出口渋滞情報を通知する（ユニキャスト）③ 分岐・出口渋滞情報を受信した各車両は、自車のダイナミックマップ上へ情報を反映して、自車の運行計画の見直しを行なう④ 管理サーバは各車両から送信された車両情報から渋滞が解消されたと判断したら渋滞情報の通知を停止する(b) ブロードキャスト配信① 車両は車両情報をキャリア広域通信網を通じて管理サーバに送信する② 管理サーバは受信した車両情報を基に分岐・出口エリアの交通状況を監視する。渋滞が発生したと判断した場合、位置情報をもとに配信対象エリアを特定する。
③ 管理サーバまたはキャリア広域網により配信対象エリアをカバーする基地局を特定しそのエリアに分岐・出口渋滞情報を通知する（ブロードキャスト）④ 分岐・出口渋滞情報を受信した各車両は、自車のダイナミックマップ上へ情報を反映して、自車の運行計画の見直しを行なう⑤ 管理サーバは各車両から送信された車両情報から渋滞が解消されたと判断したら渋滞情報の通知を停止する(2) V2I 活用想定
① 車両は分岐・出口付近に設置された路側インフラ（分岐）に車両情報を送信する② 路側インフラ（分岐）は受信した車両情報を管理サーバへ送信する③ 管理サーバは受信した車両情報を基に分岐・出口エリアの交通状況を監視する。渋滞が発生したと判断した場合、配信対象エリアの路側インフラに分岐・出口渋滞情報を配信する④ 路側インフラは、分岐・出口渋滞情報を通信エリア内の車両へブロードキャストにて配信する。
⑤ 配信エリアにある車両は分岐・出口渋滞情報を受信して、自車のダイナミックマップ上へ情―160―

ITS FORUM RC-017
報を反映して、自車の運行計画の見直しを行なう⑥ 管理サーバは路側インフラ（分岐）から送信された車両情報から渋滞が解消されたと判断したら配信を停止する
5.2.4.7 通信シーケンスと内容
ユースケース d-4 で渋滞情報の提供に想定されるメッセージ送受信シーケンスは下図の通り。
(1) 管理サーバを経由して本線車両へ配信する通信シーケンス(V2N)(a) ユニキャスト方式
車両 A

通信インフラ
(基地局)

管理サーバ

通信インフラ
(基地局)

車両 B

1.ユースケース d-4-a 情報（個別車両情報：車両 ID＋発生時刻＋
発生事象(ハザード種別)＋走行速度＋
緯度経度高度＋距離＋レーン情報/上下線＋道路種別等）
1.ユースケース d-4-a 情報（個別車両情報）

7.65s 周期で送信

渋滞発生と判定

7.65s 周期で送信

1.ユースケース d-4-a 情報（個別車両情報）
1.ユースケース d-4-a 情報（個別車両情報）

2.ユースケース d-4-b 情報（個別渋滞情報：発生時刻＋発生事象＋
緯度経度高度+レーン情報/上下線+
通行可否情報等）
2.ユースケース d-4-b 情報（個別渋滞情報）

1.ユースケース d-4-a 情報（個別車両情報）
2.ユースケース d-4-b 情報（個別渋滞情報）
渋滞解消と判定

図 5.2.4.7-1 ユースケース d-4(V2N、ユニキャスト)で想定されるメッセージ送信シーケンス―161―

ITS FORUM RC-017
1.

車両はエンジン始動から停止までの間、キャリア広域通信網ネットワークの通信
エリア内に位置する場合は、7.65s 周期(仮定)でユースケース d-4-a 情報（個別車
両情報：車両 ID＋発生時刻＋発生事象(ハザード種別)＋走行速度＋緯度経度高度＋距離＋レーン情報/上下線＋道路種別等）を提供する。

2.

管理サーバでは、ユースケース d-4-a 情報を基に渋滞の発生・解消の判定、および配信するエリアを判断し、配信する対象エリア内の車両へユースケース d-4-b 情報（個別渋滞情報：発生時刻＋発生事象＋緯度経度高度+レーン情報/上下線+通行可
否情報等）を 7.65s 周期(仮定)で送信する。なお、管理サーバ→周辺車両はサーバ側で車両を特定し個別配信を行う。

―162―

ITS FORUM RC-017(b) ブロードキャスト方式
車両 A

通信インフラ
(基地局)

管理サーバ

通信インフラ
(基地局)

車両 B

1.ユースケース d-4-a 情報（個別車両情報：車両 ID＋発生時刻＋
発生事象(ハザード種別)＋走行速度＋
緯度経度高度＋距離＋レーン情報/上下線＋道路種別等）

7.65s 周期で1.ユースケース d-4-a 情報（個別車両情報）

送信
2.ユースケース d-4-b 情報（個別渋滞情報：発生時刻＋発生事象＋
緯度経度高度+レーン情報/上下線+
通行可否情報等

7.65s 周期で渋滞発生と判定

送信

2.ユースケース d-4-b 情報（個別渋滞情報））

7.65s 周期で1.ユースケース d-4-a 情報（個別車両情報）

送信
1.ユースケース d-4-a 情報（個別車両情報）

2.ユースケース d-4-b 情報（個別渋滞情報）

1.ユースケース d-4-a 情報（個別車両情報）

2.ユースケース d-4-b 情報（個別渋滞情報）

1.ユースケース d-4-a 情報（個別車両情報）

渋滞解消と判定
3.ブロードキャスト配信停止

3.ブロードキャスト配信停止

図 5.2.4.7-2 ユースケース d-4(V2N、ブロードキャスト)で想定されるメッセージ送信シーケンス―163―

ITS FORUM RC-017
1.

車両はエンジン始動から停止までの間、キャリア広域通信網ネットワークの通信
エリア内に位置する場合は、7.65s 周期(仮定)でユースケース d-4-a 情報（個別車
両情報：車両 ID＋発生時刻＋発生事象(ハザード種別)＋走行速度＋緯度経度高度＋距離＋レーン情報/上下線＋道路種別等）を提供する。

2.

管理サーバでは、ユースケース d-4-a 情報を基に渋滞の発生・解消の判定、および配信するエリアを判断し、配信する対象エリア内の車両へユースケース d-4-b 情報（個別渋滞情報：発生時刻＋発生事象＋緯度経度高度+レーン情報/上下線+通行可
否情報等）を 7.65s 周期(仮定)で送信する。

3.

管理サーバ側での渋滞解消の妥当性が確認された場合、通信インフラ(キャリア網)に渋滞解消を通知するメッセージが送信され、ブロードキャスト配信を停止する。

―164―

ITS FORUM RC-017(2) 管理サーバを経由して本線車両へ配信する通信シーケンス(V2I)
V2I を用いた渋滞情報の提供に想定されるメッセージ送受信シーケンスは下図の通りとなる。

車両 A

路側インフラ路側インフラ

管理サーバ

車両 B

1.ユースケース d-4-a 情報（個別車両情報：車両 ID＋発生時刻＋
発生事象(ハザード種別)＋走行速度＋
緯度経度高度＋距離＋レーン情報/上下線＋道路種別等）

7.65s 周期で1.ユースケース d-4-a 情報（個別車両情報）

送信
2.ユースケース d-4-b 情報（個別渋滞情報：発生時刻＋発生事象＋
緯度経度高度+レーン情報/上下線+
1s 周期で通行可否情報等

7.65s 周期で渋滞発生と判定

送信

2.ユースケース d-4-b 情報（個別渋滞情報））

7.65s 周期で送信
1.ユースケース d-4-a 情報（個別車両情報）

送信
1.ユースケース d-4-a 情報（個別車両情報）

2.ユースケース d-4-b 情報（個別渋滞情報）

2.ユースケース d-4-b 情報（個別渋滞情報）
情報

1.ユースケース d-4-a 情報（個別車両情報）

1.ユースケース d-4-a 情報（個別車両情報）

渋滞解消と判定
3. ブロードキャスト配信停止

3. ブロードキャスト配信停止

図 5.2.4.7-3 ユースケース d-4(V2I)で想定されるメッセージ送信シーケンス―165―

1s 周期で
送信ITS FORUM RC-017
1. 車両はエンジン始動から停止までの間、路側インフラからの報知情報の受信し、路側インフラの通信エリア内にいると認識した場合は、ユースケース d-4-a 情報（個別車両情報：車両 ID＋発生時刻＋発生事象(ハザード種別)＋走行速度＋緯度経度高度＋距離＋レーン情報/上下線＋道路種別等）を提供する。なお、同一の路側インフ
ラ通信エリア内での送信周期は V2N のシナリオと同じく 7.65s 周期(仮定)とする。
別の路側インフラの通信圏内に移動した場合は、7.65s 周期(仮定)以内であっても送信可能とする。
2. 管理サーバでは、ユースケース d-4-a 情報を基に渋滞の発生・解消の判定、および配信するエリアを判断し、配信する対象エリア内の車両へユースケース d-4-b 情報（個別渋滞情報：発生時刻＋発生事象＋緯度経度高度+レーン情報/上下線+通行可
否情報等）を 7.65s 周期(仮定)で路側インフラに送信する。
路側インフラは、管理サーバからの d-4-b 情報を周辺車両へ 1s 間隔で同一メッセー
ジを送信する。7.65s 後(仮定)に管理サーバから最新の d-4-b 情報を受信すると、送信情報を更新し同様に 1s 間隔で送信する。
3. 管理サーバ側での渋滞解消の妥当性が確認された場合、路側インフラに渋滞解消が通知され旨を通知し、ブロードキャスト配信を停止する。

―166―

ITS FORUM RC-017
5.2.4.8 メッセージサイズ
・d-4-a 情報：車路間通信
表 5.2.4.8-1 ユースケース d-4 で想定される車路間通信のメッセージサイズ

データ名

データサイズ

管理情報

説明

メッセージ ID

8bit

メッセージを特定する ID

車両 ID

32bit

送信元の車両 ID
最大 20 車両分※1

個別車両情報
発生時刻

32bit

車両情報を配信する時刻

発生事象(ハザード種別)

8bit(使用しない)

速度

16bit

走行速度

経度緯度高度

88bit

車両の位置

距離

16bit

(使用しない)レーン情報/上下線

4bit

車両のレーン

道路種別等

8bit

(使用しない)通行情報

通行可否情報8bit(使用しない)

―

(空き)

4bit

―

事象情報

地点情報

*1：個別車両情報であり自車 1 台分の想定
・d-4-b 情報：路車間通信
表 5.2.4.8-2 ユースケース d-4 で想定される路車間通信のメッセージサイズ

データ名

管理情報

データサイズメッセージ ID

8bit

路側機 ID

32bit

説明
メッセージを特定する ID
送信元の路側機 ID
送信元が管理サーバの場合は未定
最大 20 渋滞分

個別渋滞情報発生時刻

32bit

渋滞中の現在時刻

発生事象(ハザード種別)

8bit

渋滞を通知

速度

16bit

走行速度

経度緯度高度

88bit

渋滞位置

距離

16bit

(使用しない)レーン情報/上下線

4bit

渋滞レーン

道路種別等

8bit

(使用しない？)通行情報

通行可否情報8bit

通行可否の情報

―

(空き)

4bit

―

事象情報

地点情報

―167―

ITS FORUM RC-017※基本的に自工会にて検討されている路車間通信メッセージを流用して本ユースケースにおいても適用が可能か検討を進めた。

【補足】●想定されるケースと方針
・渋滞情報を重複して受信するケース
例えば、路側インフラ経由と基地局経由の両方から同じ渋滞情報を受信した場合は、車両側にて重複した渋滞情報の取捨を選択する―168―

ITS FORUM RC-017
5.2.5

ユースケース d-5. ハザード情報による走行支援

5.2.5.1 通信の目的
ハザード情報による走行支援
5.2.5.2 通信の概要
障害物・工事・渋滞等の情報を、インフラから周辺車両に提供し、走行支援を行う。
5.2.5.3 ハザード情報の配信方法
管理サーバは、道路事業者が円滑な交通のための必要と道路事業者が入手・判断したハザード情報を、ハザード発生地点からサービス提供が必要となる周辺車両へ早めの車線変更や走行計画変更
を行なえるようにハザード情報を配信するエリアを判断して、ハザードが解消[※１]されるまで、周辺車両へハザード情報を周期的に提供する。
※１：道路管理者により異常車両および周辺の安全を確認後に何らかの手段で管理サーバと連携して解消を通知することを想定した。

管理サーバから周辺車両へハザード情報を配信する通信手段（ダウンリンク側）も、キャリア広域通信網のネットワーク(V2N)と路側インフラ(V2I)を使用する。
V2N と V2I の配信方法のイメージを以下の(1)(2)に示す。
(1) V2N 活用想定(a) ユニキャスト方式
管理サーバは、ハザード情報を配信するエリア内の車両を特定[※1]して、キャリア広域通信網のネットワーク（基地局）経由にて、周辺車両へハザード情報を
ユニキャスト配信する。
異常車両のハザードが解消されるまで、7.65s 毎（仮定）に周期的に配信する。
※1：前提として、周辺車両の詳細位置の情報が定期的に管理サーバへ収集されていることを想定。
(b) ブロードキャスト方式
管理サーバは、ハザード情報を配信するエリアを特定して、キャリア広域通信網のネットワーク（基地局）経由にて、配信するエリア内へハザード情報をブロードキャスト配信する。[※2]
異常車両のハザードが解消されるまで、7.65s 毎（仮定）に周期的に配信する。
※2：将来的な可能性としてブロードキャスト(MBMS 等)で配信することを想定。

―169―

ITS FORUM RC-017

・ユニキャスト・ブロードキャスト

図 5.2.5.3-1 V2N における配信方法―170―

ITS FORUM RC-017(2) V2I 活用想定
管理サーバは、ハザード情報を配信するエリアを判断して、配信する対象エリア内の路側インフラ経由にて、周辺車両へハザード情報を配信する。
※管理サーバは、ハザード情報を重複して受信した場合は、1 つのハザード情報として扱う。
異常車両のハザードが解消されるまで、1s 毎（仮定）に周期的に配信する。

図 5.2.5.3-2 V2I における配信方法

5.2.5.4 想定シナリオ
ハザード情報による走行支援で想定されるシナリオは以下の通り(1) V2N 活用想定(a) ユニキャスト配信①管理サーバは、管理サーバに登録されたハザード情報をもとに配信するエリアを判断する。
なお、管理サーバは、ハザード情報を重複して受信した場合は、１つのハザード情報として扱う。
②管理サーバは、ハザード情報を配信するエリア内の車両を特定して、配信対象エリア内のキャ
リア広域通信網のネットワーク（基地局）経由にて、周辺車両へハザード情報を周期的にユニキャストにて配信する。
※ハザード情報は路側インフラ経由でも周辺車両へ配信する。（シナリオ(2)V2I を参照）
③周辺車両は、ハザード情報を受信して、自車のダイナミックマップ上へ本線車両情報を反映して、自車の運行計画の見直しを行なう④道路管理者は、異常車両および周辺の安全を確認後、管理サーバからのハザード情報の配信を
停止する。

―171―

ITS FORUM RC-017(b) ブロードキャスト配信①管理サーバは、管理サーバに登録されたハザード情報をもとに配信するエリアを判断する。
なお、管理サーバは、ハザード情報を重複して受信した場合は、１つのハザード情報として扱う。
②管理サーバは、ハザード情報を配信するエリアを判断して、キャリア広域通信網のネットワー
ク（基地局）経由にて、周辺車両へハザード情報を周期的にブロードキャストにて配信する。
※ハザード情報は路側インフラ経由でも周辺車両へ配信する。（シナリオ(2)V2I を参照）
③周辺車両は、ハザード情報を受信して、自車のダイナミックマップ上へ本線車両情報を反映して、自車の運行計画の見直しを行なう。
④道路管理者は、異常車両および周辺の安全を確認後、管理サーバからのハザード情報の配信を停止する。
(2) V2I 活用想定
①管理サーバは、管理サーバに登録されたハザード情報をもとに配信するエリアを判断する。
なお、管理サーバは、ハザード情報を重複して受信した場合は、１つのハザード情報として扱う。
②管理サーバは、配信対象エリア内の路側インフラ経由にて、周辺車両へハザード情報を周期的にブロードキャストにて配信する。
※ハザード情報はキャリア広域通信網のネットワーク（基地局）経由でも周辺車両へ配信する。（シナリオ(1)V2N を参照）
③周辺車両は、ハザード情報を受信して、自車のダイナミックマップ上へ本線車両情報を反映して、自車の運行計画の見直しを行なう。
④道路管理者は、異常車両および周辺の安全を確認後、管理サーバからのハザード情報の配信を
停止する。

―172―

ITS FORUM RC-017
5.2.5.5 通信シーケンスと内容
ユースケース d-5 でハザード情報の提供に想定されるメッセージ送受信シーケンスは下図の通りとなる。
(1) V2N 活用想定(a) ユニキャスト方式
通信インフラ
（基地局）

管理サーバ

周辺車両

1.ユースケース d-1-a 情報（車両情報：
車両 ID＋
発生時刻＋
速度＋
緯度経度高度）

7.65s 周期で送信

ハザード発生ハザード発生を認識
1. ユースケース d-1-a 情報（車両情報）
2.ユースケース d-5 情報（ハザード情報：
発生時刻＋発生事象（ハザード種別）＋
緯度経度高度+
レーン情報/上下線+
通行可否情報等）

7.65s 周期で送信

1. ユースケース d-1-a 情報（車両情報)
2.ユースケース d-5 情報
ハザード解消（ハザード情報）

ハザード解消を認識

図 5.2.5.5-1 ユースケース d-5(V2N、ユニキャスト)で想定されるメッセージ送信シーケンス―173―

ITS FORUM RC-017
1.

車両は周期的に自車の位置情報を含む d-1-a 情報（車両情報：車両 ID＋発生時刻＋速度＋
緯度経度高度）を管理サーバに送信する。

2.

管理サーバは、配信する必要があるハザード情報が登録された際、配信するエリアを判断し、配信する対象エリア内の車両へユースケース d-5 情報（ハザード情報:発生時刻＋発生
事象(ハザード種別)＋経度緯度高度＋レーン情報/上下線+通行可否情報等）を 7.65s 周期(仮定)で送信する。なお、管理サーバ→周辺車両はサーバ側で車両を特定し個別配信を行
う。

―174―

ITS FORUM RC-017(b) ブロードキャスト方式
通信インフラ
（基地局）

管理サーバ

周辺車両

ハザード発生
1.ユースケース d-5 情報（ハザード情報：
発生時刻＋
ハザード発生を認識

発生事象（ハザード種別）＋
緯度経度高度+
レーン情報/上下線+
通行可否情報等）

7.65s 周期で送信

1.ユースケース d-5 情報（ハザード情報）

ハザード解消ハザード解消を認識

2. 解消（配信停止）を通知する

図 5.2.5.5-2 ユースケース d-5(V2N、ブロードキャスト)で想定されるメッセージ送信シーケンス―175―

ITS FORUM RC-017
1.

管理サーバは、配信する必要があるハザード情報が登録されると、ハザード情報を配信する対象エリア内へ 7.65s 周期で d-5 情報（ハザード情報）をブロードキャストで送信する。

NOTE:ブロードキャストでは対象エリアと配信基地局の紐づけをキャリア網にて実施する想定。
2.

管理サーバ側でのハザード解消確認等により、道路管理者によってハザード解消の妥当性が認証された場合、通信インフラ(基地局)にハザードの解消が通知され、ブロードキャスト
配信を停止する。

―176―

ITS FORUM RC-017(2) V2I 活用想定
管理サーバ

路側インフラ周辺車両

ハザード発生
1.ユースケース d-5 情報（ハザード情報：
発生時刻＋発生事象（ハザード種別）＋
ハザード発生を認識

緯度経度高度+
レーン情報/上下線+
通行可否情報等）

7.65s 周期で
送信
1s 周期で送信

1.ユースケース d-5 情報（ハザード情報）

1s 周期で送信

ハザード解消ハザード解消を認識

2. 解消（配信停止）を通知する

図 5.2.5.5-3 ユースケース d-5(V2I)で想定されるメッセージ送信シーケンス―177―

ITS FORUM RC-017

1.

管理サーバは、配信する必要があるハザード情報が登録された際、配信するエリアを判断し、路側インフラのエリア内の車両へユースケース d-5 情報（ハザード情報:発生時刻＋発
生事象(ハザード種別)＋経度緯度高度＋レーン情報/上下線+通行可否情報等）を 7.65s 周期(仮定)で送信する。
路側インフラは、管理サーバからの d-5 情報を周辺車両へ 1s 間隔で同一メッセージを送信する。7.65s 後(仮定)に管理サーバから最新の d-5 情報を受信すると、送信情報を更新し同様に 1s 間隔で送信する。

2.

管理サーバ側でのハザード解消確認等により、道路管理者によってハザード解消の妥当性が認証された場合、路側インフラにハザードの解消が通知され、ブロードキャスト配信を
停止する。

―178―

ITS FORUM RC-017
5.2.5.6 メッセージサイズ(1) d-5 情報：路車間通信
表 5.2.5.6-1 ユースケース d-5 で想定される路車間通信のメッセージサイズ

データ名
管理情報

データサイズメッセージ ID

8bit

路側機 ID

32bit

地点情報

メッセージを特定する ID
送信元の路側機 ID
送信元が管理サーバの場合は未定
最大 20 ハザード分

個別ハザード情報

事象情報

説明

発生時刻

32bit

ハザードが発生した時刻

発生事象(ハザード種別)

8bit

発生事象を通知

速度

16bit

走行速度

経度緯度高度

88bit

ハザード発生地点

16bit

配信する距離距離(ハザード発生地点からの距離)

レーン情報/上下線

4bit

ハザード発生レーン

道路種別等

8bit

道路種別

通行情報

通行可否情報8bit

通行可否の情報

―

(空き)

4bit

―

※基本的に自工会にて検討されている路車間通信メッセージを流用して本ユースケースにおいても適用が可能か検討を進めた。

―179―

ITS FORUM RC-017

［余白］

―180―

ITS FORUM RC-017

第6章

e.先読み情報：緊急車両回避のユースケース

6.1 前提条件
本章に関する前提条件は 5.1.1 節と同等である。
6.2 先読み情報：緊急車両回避のユースケース
6.2.1

ユースケース e-1. 緊急車両の情報による走行支援

6.2.1.1 通信の目的
緊急車両の情報による走行支援
6.2.1.2 通信の概要
緊急車両の移動方向や速度、走行予定経路（走行予定車線）の情報を、緊急車両から周辺車両に提供し、周辺車両の徐行や停車等を促して緊急車両の円滑な通過を支援する。
6.2.1.3 想定する道路条件
高速道路および一般道を想定した。

・ 速度、加減速度
表 6.2.1.3-1 速度、加減速度

車両

最高速[km/h]
一般道

高速道路

大型車

60

80

普通車

60

120

最低速[km/h]
一般道
-

※1

高速道路
40

加速度

減速度

[G]

[G] ※2

0.15

0.15

0.20

0.25

緊急車両
80
120
0.20
0.25
※1 最低速は自工会が提示する前提条件とした。渋滞も加味した最低速度は 20km/h と仮定。
※2 安全な減速は 0.3G 未満と考え、本ユースケースでは自工会が提示する減速度を用いる。
※3 緊急車両の最高速度は、道路交通法施行令 第 12 条 3 項を参考に想定※3・ 道路
表 6.2.1.3-2 道路

道路区分

一車線の幅[m]

車線数

一般道

3.5

2

高速道路

3.5

3

本ユースケースにおける走行支援の対象とする車両は、自動運転車両とする。
一般車両については、想定速度および回避行動に必要な時間（距離）が不明のためまずは対象外として検討を進めた。

―181―

ITS FORUM RC-017
6.2.1.4 想定する前提条件•

緊急車両

本ユースケースにおいて緊急車両とはサイレンを鳴らし赤色の警光灯をつけて走行し、緊急車
両接近情報を送信している車両とする（目的によりサイレンを鳴らさない場合など(道路交通法
施行令 第十四条)、緊急車両接近情報を送信しない想定）。
6.2.1.5 緊急車両接近情報の配信
緊急車両は情報の配信を以下の 2 つの手段で行う(1) 直接通信による配信 V2V(2) キャリア広域通信網経由の配信

V2N※ 見通し距離では V2V、見通し外では V2N で対応することを想定し、これら 2 つを検討対象とした。本ユースケースの V2I の対応については役割等を含め継続検討とする。
以降にそれぞれの配信イメージを記す(1) 直接通信による配信 V2V
緊急車両は目的地へ到着するまで、周辺車両へ V2V で緊急車両接近情報を 100ms 周期で配信する。

図 6.2.1.5-1 V2V における配信方法―182―

ITS FORUM RC-017(2) キャリア広域通信網経由の配信

V2N(2-1) ユニキャスト方式
管理サーバは、緊急車両接近情報を配信するエリア内の車両を特定[※1]して、キャリア広域通信網のネットワーク（基地局）経由にて、周辺車両へ緊急車両接近情報をユニキャス
ト配信する。
※1：前提として、周辺車両の詳細位置の情報が定期的に管理サーバへ収集されていることを想定。
(2-2) ブロードキャスト方式
管理サーバは、緊急車両接近情報を配信するエリアを特定して、キャリア広域通信網のネッ
トワーク（基地局）経由にて、配信するエリア内へ緊急車両接近情報をブロードキャスト
配信する。

緊急車両は目的地に到着するまで、7.65s 毎に周期的に配信する。[※2]※2：5.1.5 広域通信におけるサービス提供エリアの考え方と同様に、周辺車両は、緊急車両の回避を行う際、安全な車線変更に必要な距離は 255ｍであると仮定した。
時速 120km/h で走行する車両の場合は、255m 進むには 7.65s となる。
・ユニキャスト

管理サーバ
基地局

基地局

緊急車両

管理サーバ

・ブロードキャスト

基地局

基地局

緊急車両

図 6.2.1.5-2 V2N における配信方法―183―

ITS FORUM RC-017
6.2.1.6 通信エリアの条件•

直接通信による配信エリア（V2V）

150m

緊急車両から車車間通信で配信できるエリアは、ITS Connect の配信エリアに準拠して150m とした。

図 6.2.1.6-1 通信エリアの条件•

緊急車両接近情報を配信するエリア（V2N）
緊急車両接近情報を受信した車両が緊急車両の走行を妨げないよう、以下の 2 つに分けて車両の動作、配信が必要な通信エリアを考えた。
(1) 緊急車両の進行方向進行方向にある車両は円滑に回避行動を行えるようにする。
(2) 進行方向と交差する道路
緊急車両の進路に交差する道路にある車両は、緊急車両の進路に侵入せず、停止する。

図 6.2.1.6-2 車両の動作のイメージ―184―

ITS FORUM RC-017(1) 緊急車両の進行方向
緊急車両の進行方向にある車両が、緊急車両の進路を妨げないように円滑に回避行動を行うた
めに 30s 必要と想定した。この場合、進行方向に必要な配信は一般道、高速道で以下の距離(進行方向距離)となる。
表 6.2.1.6-1 進行方向に必要な配信の距離

最高速度

進行方向距離[km/h]

[m]

一般道

80

700

80km/h×1000m/3600s×30s=666.6m

高速道路

120

1000

120km/h×1000m/3600s×30s=1000m

道路区分

備考

・一般道

・高速道路

図 6.2.1.6-3 進行方向距離のイメージ(2) 進行方向と交差する道路
緊急車両の進路に交差する道路にある車両は、緊急車両の進路に侵入せず、停止する必要がある。
緊急車両の進路に侵入せずに安全に停止するまでの距離を以下のように算出する。
①

緊急車両接近情報配信から車両が受信するまでに進む距離
緊急車両が緊急車両接近情報を配信してから配信エリアの車両が受信するまで（緊急車両 → 基地局 → 管理サーバ → 基地局 → 車両）の時間を 5s と仮定して算出。

―185―

ITS FORUM RC-017②

空走距離
車両が緊急車両接近情報を受信し、運行計画を見直しブレーキが利き始めるまでの時間を 1s と仮定して算出。

③

制動距離
車両の速度、減速度から等加速度運動から算出。

④

車道の幅

また、進路には左右方向から進入が考えられるため、必要なエリアは進路に対して両方向
となる。
①
②

交差方向距離

目的地

③

緊急車両

④

図 6.2.1.6-4 交差方向距離のイメージ

一般道、高速道路とも同様の考え方で交差方向距離を算出。
上述の仮定と以下の条件から必要な距離を算出、緊急車両の進行方向に交差する道路に配信が必
要な交差方向距離は以下とした。
一般道

：250m

高速道路：450m
表 6.2.1.6-2 交差方向に必要な配信の距離
最高速

減速度

①＋②

③制動距離

④車道の幅

交差方向距離[km/h]

[G]

[m]※1

[m]

[m]※2

[m] ※3

大型車

60

0.15

100

95

7

202

普通車

60

0.25

100

57

7

164

大型車

80

0.15

133

168

11

312

普通車

120

0.25

200

226

11

437

道路区分

車両

一
般
道

高
速
道
路

―186―

ITS FORUM RC-017※1

緊急車両接近情報配信から車両が受信(5s)+空想時間(1s)※2

一般道：3.5×2 車線→ 7[m]、高速道路：3.5m×3 車線→10.5[m]≒11[m]※3

緊急車両の進路方向を中心に左右に必要になる。
➀+②+③+④(3) 配信エリア
目的地が下記の場合を考慮、配信エリアは緊急車両を中心に(1)で求めた進行方向距離を半径とす
る半円とする。 （(2)の交差方向距離も満足する）• 右左折先の目的地 (下図 一般道)
目的地が右折もしくは左折した先にあり、進行方向が変わった場合、緊急車両接近情報の配信に必要なエリアは 「(1) 緊急車両の進行方向」 の場合と同様と考える。
一般道：半径 700m の半円

図 6.2.1.6-5 通信エリアの条件(一般道)―187―ITS FORUM RC-017
高速道路：半径 1000m の半円

図 6.2.1.6-6 通信エリアの条件(高速道路)[補足]
目的地が反対車線や鋭角に戻るように折り返す場合が考えられる。この場合、前方から緊急車両が接近した時に緊急車両接近情報を受信することで自車両に接近してくることが分かるため、
緊急車両の後方も含めた円は必要とせず半円とした。

図 6.2.1.6-7 通信エリアの条件の補足―188―

ITS FORUM RC-017
6.2.1.7 通信遅延
本ユースケースでは、V2V を用いた緊急車両接近情報の配信遅延を 100ms 未満とする。
※ITS FORUM RC-015 P.50 の 通信遅延参照。
V2N は先読みによる走行支援のため、即応性は不要として規定しない。
6.2.1.8 想定シナリオ
緊急車両の通知による走行支援で想定されるシナリオは以下の通り。
(1) 直接通信による配信 V2V① 緊急車両は、30s 後の地点情報（緊急車両推定走行地点、緊急車両走行レーン、道路種別）を含んだ緊急車両接近情報をブロードキャストで配信する。
② 緊急車両接近情報を受信した周辺車両は、自車のダイナミックマップ上へ本車両情報を反映して、自車の運行計画の見直しを行う。
③ 緊急車両は目的地に到着した後、緊急車両接近情報の配信を停止する。
(2) V2N 活用想定：緊急車両→基地局→管理サーバ→基地局→周辺車両(2-1) ユニキャスト配信① 緊急車両は、30s 後の地点情報（緊急車両推定走行地点、緊急車両走行レーン、道路種別）を含んだ緊急車両接近情報をキャリア広域通信網のネットワーク（基地局）を経由して管理サーバへ送信する。
② 管理サーバは、緊急車両から受信した緊急車両接近情報をもとに配信するエリアを判断する。
③ 管理サーバは、緊急車両接近情報を配信エリア内の車両を特定して、配信エリア内のキャリ
ア広域通信網のネットワーク（基地局）経由にて周辺車両へ緊急車両接近情報をユニキャス
トにて送信する。
④ 周辺車両は、緊急車両接近情報を受信して、自車のダイナミックマップ上へ本線車両情報を反映して、自車の運行計画の見直しを行う。
⑤ 緊急車両は目的地に到着した後、緊急車両接近情報の配信を停止する。
(2-2) ブロードキャスト配信① 緊急車両は、30s 後の地点情報（緊急車両推定走行地点、緊急車両走行レーン、道路種別）を含んだ緊急車両接近情報をキャリア広域通信網のネットワーク（基地局）を経由して管理サーバへ送信する。
② 管理サーバは、緊急車両から受信した緊急車両接近情報をもとに配信するエリアを判断する。
③ 管理サーバは、緊急車両接近情報を配信するエリア内を判断して、キャリア広域通信網のネットワーク（基地局）経由にて周辺車両へ緊急車両接近情報をブロードキャストにて送信
する。

―189―

ITS FORUM RC-017④ 周辺車両は、緊急車両接近情報を受信して、自車のダイナミックマップ上へ本線車両情報を反映して、自車の運行計画の見直しを行う。
⑤ 緊急車両は目的地に到着した後、緊急車両接近情報の配信を停止する。

NOTE: 緊急車両から配信する情報として 30 秒後の地点情報としたが、これは暫定であり、どういった情報を配信すべきかについては検討の余地がある。

―190―

ITS FORUM RC-017
6.2.1.9 通信シーケンスと内容(1) V2V 緊急車両→周辺車両
ユースケース e-1(V2V)で緊急車両接近情報の提供に想定されるメッセージ送受信シーケンス
は下図の通りとなる。

車両 A（緊急車両）

車両 B

1.ユースケース e-1-a 情報（緊急車両接近情報：
車両 ID＋
発生時刻＋
発生事象＋
対象物事象(速度、車両種別)＋
緯度経度高度＋緯度経度高度 2+
距離＋
レーン情報/上下線＋レーン情報/上下線 2
配信開始

道路種別等＋道路種別等 2
通行可否情報）100ms 周期で送信

1.ユースケース e-1-a 情報（緊急車両接近情報）

1.ユースケース e-1-a 情報（緊急車両接近情報）

配信停止

図 6.2.1.9-1 ユースケース e-1(V2V)で想定されるメッセージ送信シーケンス―191―

ITS FORUM RC-017

1. 緊急車両は、緊急車両接近情報を送信する必要がある間、ユースケース e-1-a 情報（緊急車両接近情報：車両 ID＋発生時刻＋発生事象＋対象物事象(速度、車両種別)＋緯度経度高度＋緯度経度高度 2+距離＋レーン情報/上下線＋レーン情報/上下線 2+道路種別等＋道路種別
等 2+通行可否情報）をブロードキャストにて 100ms 周期に配信する。

NOTE: 緊急車両接近情報を送信する条件は、6.2.1.4 節に記載する。
緊急車両は、目的地に到着するとユースケース e-1-a 情報（緊急車両接近情報）の配信を停
止する。

―192―

ITS FORUM RC-017(2) V2N 活用想定：緊急車両→通信インフラ（基地局）→管理サーバ→通信インフラ（基地局）→周辺車両(2-1) ユニキャスト
方式ユースケース e-1(V2N)で緊急車両接近情報の提供に想定されるメッセージ送受信
シーケンスは下図の通りとなる。

車両 A（緊急車両）

通信インフラ（基地局）

通信インフラ
（基地局）

管理サーバ

車両 B

1.ユースケース e-1-b（車両情報：
車両 ID ＋発生時刻＋
経度緯度高度＋速度）

1.ユースケース e-1-b（車両情報)

7.65s 周期で送信

7.65s 周期で送信

2.ユースケース e-1-b 情報（緊急車両接近情報：
車両 ID＋発生時刻＋発生事象＋速度＋
現在時刻＋緯度経度高度＋緯度経度高度 2＋
距離＋
配信開始

レーン情報/上下線＋レーン情報/上下線 2＋
道路種別等＋道路種別等 2＋
通行可否情報）発生を認識
2.ユースケース e-1-b（緊急車両接近情報)

1.ユースケース e-1-b（車両情報)
3.ユースケース e-1-c 情報（緊急車両接近情報）

2.ユースケース e-1-b（緊急車両接近情報)
1.ユースケース e-1-b（車両情報)
3.ユースケース e-1-c 情報（緊急車両接近情報）
配信停止 4.ユースケース e-1-b（緊急車両接近情報）※配信停止を通知
解消を認識

図 6.2.1.9-2 ユースケース e-1(V2N)で想定されるメッセージ送信シーケンス―193―

ITS FORUM RC-017
1. 車両は、キャリア広域通信網ネットワークの通信エリア内に位置する場合は、管理サーバへ
e-1-b 情報(車両情報：車両 ID＋発生時刻＋経度緯度高度＋速度)を 7.65s 周期(仮定)で送信する。なお、管理サーバは、通知するべき緊急車両接近情報がない場合は、車両への応答を行わない。
2. 緊急車両は、緊急車両接近情報の配信を開始する際にキャリア広域通信網ネットワークの通信エリア内に位置する場合は、管理サーバへユースケース e-1-b 情報（緊急車両接近情
報：車両 ID＋発生時刻＋発生事象＋速度＋現在時刻＋緯度経度高度＋経度緯度高度 2＋距
離＋レーン情報/上下線＋レーン情報/上下線 2＋道路種別等＋道路種別等 2＋通行可否情報）
を一度送信する。その後、次の 7.65s 周期に合わせて管理サーバへユースケース e-1-b 情報（緊急車両接近情報）を送信する。

NOTE: 緊急車両接近情報を送信する条件は、6.2.1.4 節に記載する。
3. 管理サーバは、ユースケース e-1-b 情報を基に緊急車両の発生の判定、および配信するエリ
アを判断し、配信する対象エリア内の車両へユースケース e-1-c 情報（緊急車両接近情報）
を応答として返す。なお、管理サーバ→周辺車両はサーバ側で車両を特定し個別配信を行う。
4. 緊急車両は、緊急車両接近情報の配信を停止する際にキャリア広域通信網ネットワークの通信エリア内に位置する場合は、管理サーバへユースケース e-1-b 情報（車両情報）を一度
送信する。

―194―

ITS FORUM RC-017(2-2) ブロードキャスト方式
ユ ー ス ケ ー ス e-1(V2N) で 緊 急 車 両 接 近 情 報 の 提 供 に 想 定 さ れ る メ ッ セ ー ジ 送 受 信
シーケンスは下図の通りとなる。

車両 A（緊急車両）

通信インフラ（基地局）

通信インフラ
（基地局）

管理サーバ

車両 B

1.ユースケース e-1-b（車両情報：
車両 ID ＋発生時刻＋
経度緯度高度＋速度）

1 ユースケース e-1-b（車両情報)

7.65s 周期で送信
2.ユースケース e-1-b 情報

7.65s 周期で送信（緊急車両接近情報：
車両 ID＋発生時刻＋発生事象＋速度＋
現在時刻＋緯度経度高度＋緯度経度高度 2＋
距離＋
レーン情報/上下線＋レーン情報/上下線 2＋
配信開始 道路種別等＋道路種別等 2＋
通行可否情報）発生を認識
2.ユースケース e-1-b（緊急車両接近情報)

1.ユースケース e-1-b（車両情報)
3.ユースケース e-1-c 情報（緊急車両接近情報）

2.ユースケース e-1-b（緊急車両接近情報)

1.ユースケース e-1-b（車両情報)
3.ユースケース e-1-c 情報（緊急車両接近情報）

配信停止 4.ユースケース e-1-b（緊急車両接近情報）※配信停止を通知
解消を認識

図 6.2.1.9-3 ユースケース e-1(V2N)で想定されるメッセージ送信シーケンス―195―

ITS FORUM RC-017
1. 緊急車両は、緊急車両接近情報を送信する必要がある間、キャリア広域通信網ネットワークの通信エリア内に位置する場合は、管理サーバへユースケース e-1-b 情報（緊急車両接近情
報：車両 ID＋発生時刻＋発生事象＋速度＋現在時刻＋緯度経度高度＋経度緯度高度 2＋距
離＋レーン情報/上下線＋レーン情報/上下線 2＋道路種別等＋道路種別等 2＋通行可否情報）
を 7.65s 周期(仮定)で提供する。

NOTE: 緊急車両接近情報を送信する条件は、6.2.1.4 節に記載する。
2. 管理サーバでは、ユースケース e-1-b 情報を基に緊急車両の発生判定、および配信するエリ
アを判断し、配信する対象エリア内の車両へユースケース e-1-c 情報（緊急車両接近情報）
を 7.65s 周期(仮定)で送信する。ただし、管理サーバ→周辺車両はサーバ側で車両を特定する事なくエリア一斉配信を行う。
3. 緊急車両が目的地へ到着し緊急車両接近情報の配信を停止する際にキャリア広域通信網
ネットワークの通信エリア内に位置する場合は、管理サーバへユースケース e-1-b 情報（緊
急車両接近情報）を送信し、緊急車両接近情報の配信を停止する。
4. 管理サーバは、ユースケース e-1-b 情報を基に緊急車両の解消の判定をし、通信インフラ（基地局）へ配信停止を通知する。

NOTE:「配信停止」を示すメッセージフォーマット/データは検討中（Null 埋め等を想定）。

―196―

ITS FORUM RC-017
6.2.1.10

メッセージサイズ(1) e-1-a 情報 (V2V)
表 6.2.1.10-1 ユースケース e-1 で想定される車車間通信(V2V)のメッセージサイズ

データ名

データサ

説明

イズ
管理情報

事象情報

地点情報

通行情報

配信指定情報メッセージ ID

8bit

メッセージを特定する ID

車両 ID

32bit

送信元の緊急車両 ID

発生時刻

32bit

緊急車両が発進した時刻

発生事象

8bit

緊急車両の接近を通知

対象物情報(速度、車両種別)

24bit

速度、車両種別

経度緯度高度88bit

緊急車両走行地点

経度緯度高度 2

88bit

30s 後の緊急車両推定走行地点

距離

16bit

使用しない想定

レーン情報/上下線

4bit

緊急車両走行レーン

レーン情報/上下線 2

4bit

30s 後の緊急車両走行レーン

道路種別等

8bit

道路種別

道路種別等 28bit

30s 後の道路種別

通行可否情報8bit

通行可否の情報

発信元車載器 ID

32bit

使用しない想定

配信対象車線情報

8bit

使用しない想定

情報有効時間32bit

使用しない想定

再配信距離

16bit

使用しない想定

予備(本線規制情報等)

4bit

―

―197―

ITS FORUM RC-017(2) e-1-b 情報(V2N)
表 6.2.1.10-2 ユースケース e-1 で想定される車路間通信(V2N)のメッセージサイズ

データ名
管理情報

データサイズ

説明

メッセージ ID

8bit

メッセージを特定する ID

車両 ID

32bit

送信元の緊急車両 ID
最大 20 緊急車両分

個別緊急車両接近情報
発生時刻

32bit

緊急車両が発進した時刻

発生事象

8bit

緊急車両の接近を通知

速度

16bit

緊急車両の走行速度

現在時刻

32bit

緊急車両の現在時刻

経度緯度高度

88bit

現在の緊急車両走行地点

経度緯度高度 2

88bit

30s 後の緊急車両推定走行地点

距離

16bit

配信する距離レーン情報/上下線

4bit

緊急車両走行レーン

レーン情報/上下線 2

4bit

30s 後の緊急車両走行レーン

道路種別等

8bit

道路種別

道路種別等 28bit

30s 後の道路種別

通行情報

通行可否情報8bit

通行可否の情報

―

(空き)

―

―

事象情報

地点情報

―198―

ITS FORUM RC-017(3) e-1-c 情報(V2N)
表 6.2.1.10-3 ユースケース e-1 で想定される路車間通信(V2N)のメッセージサイズ

データ名
管理情報

データサイズメッセージ ID

8bit

路側機 ID

32bit

説明
メッセージを特定する ID
送信元の路側機 ID
送信元が管理サーバの場合は未定
最大 20 緊急車両分

個別緊急車両接近情報
発生時刻

32bit

緊急車両が発進した時刻

発生事象

8bit

緊急車両の接近を通知

速度

16bit

緊急車両の走行速度

現在時刻

32bit

緊急車両の現在時刻

経度緯度高度88bit

緊急車両走行地点

経度緯度高度 2

88bit

30s 後の緊急車両推定走行地点

距離

16bit

配信する距離レーン情報/上下線

4bit

緊急車両走行レーン

レーン情報/上下線 2

4bit

30s 後の緊急車両走行レーン

道路種別等

8bit

道路種別

道路種別等 28bit

30s 後の道路種別

通行情報

通行可否情報8bit

通行可否の情報

―

(空き)

―

―

事象情報

地点情報

※基本的に自工会にて検討されている路車間通信メッセージを流用して本ユースケースにおいても適用が可能か検討を進めた。

―199―

ITS FORUM RC-017【補足】● 想定されるケースと方針
・大規模な事故など、複数の緊急車両が近接して走行するケース
各々の緊急車両が緊急車両接近情報を送信する

図 6.2.1.10-1 複数の緊急車両が近接して走行するケース● 想定されるケースと方針
・周辺車両が緊急車両接近情報を重複して受信するケース
例えば、直接通信と基地局経由の両方から同じ緊急車両接近情報を受信した場合は、車両側にて重複した緊急車両接近情報の取捨を選択する。

―200―

ITS FORUM RC-017

第7章

f.インフラによる情報収集・配信のユースケース

7.1 インフラによる情報収集・配信における条件
インフラによる情報収集・配信のシナリオにおいては、以下の条件で検討した。

ユースケース・ ユースケース f-1. 救援要請(e-Call)・ ユースケース f-2. 交通流の最適化のための情報収集
・ ユースケース f-3. 地図更新・自動生成・ ユースケース f-4. ダイナミックマップ情報配信
対象車両
・ オーナーカーを対象とする

自動運転レベル・ 情報収集に対応した車両は自動運転レベル 0 からレベル 5 までの全てのレベルを対象とする

時刻精度
・ インフラおよび協調走行車は、メッセージ内容の時刻情報の理解のため、それぞれ GNSS
同期の時刻情報を持っているものとする。ただし、所持する時刻精度および GNSS 非補足時に許容される時刻精度は要検討―201―

ITS FORUM RC-017
道路条件・ 自専道、一般道における任意の道路を対象とする
但し、ユースケース f-3 における更新対象の地図でカバーする道路として、自動車専用
道路・国道・県道・市町村道のうち片側 1 車線以上がある路線を想定する。
車線数
・ 自専道の車線数：片側 6 車線を最大とする
・ 一般道の車線数：片側 3 車線を最大とする
想定車間距離・ 通常環境：2 秒車間とする

・ 混雑した環境：1 秒車間とする

速度条件
・以下の条件とする
自動走行中の車両：法定速度を順守した走行

運転者が操作する車両：法定速度＋10km/h を上限速度とした走行
渋滞時の検討が必要な場合は、全ての車両が、自専道：40km/h、一般道：5km/hとみなす。

目標とする通信品質
・ 通信品質は各ユースケースにおける要求条件として検討した。

―202―

ITS FORUM RC-017
7.2 f.インフラによる情報収集・配信のユースケース
7.2.1

ユースケース f-1. 救援要請(e-Call)

7.2.1.1 通信の目的
事故車など異常車両からの救援要請。
7.2.1.2 通信の概要
事故⾞等の異常⾞両から自動、もしくは車両搭乗者の手動で救援サービス事業者に事象や位置情報などを設定した救援要請を送信し、救援を要請する。異常車両と救援サービス事業者間でメッセー
ジ通信完了後、音声通話により更なる詳細な情報を収集し救援に活用する。
7.2.1.3 救援要請の配信方法
異常車両は、車両に異常が発生すると、自動での異常検出または車両搭乗者のスイッチ操作により、救援情報を救援サービス事業者へ送信する。救援サービス事業者からの応答を受領するまで、周期的に救援要請を送信する。
救援サービス事業者は、異常車両から救援要請を受信すると、救援要請に含まれる情報（時刻、位置、進行方向等）を把握し、応答メッセージを異常車両に送信する。応答メッセージ送信後、異常車両搭乗者と音声による通信を行い、詳細な状況（事故か異常か等）のヒアリングを行う。

異常車両から救援サービス事業者への救援要請の送信、およびその後の車両搭乗者から救護サー
ビス事業者方向への音声の通信手段（アップリンク側）は、キャリア広域通信網のネットワーク(V2N)を使用する。
救援サービス事業者から異常車両への応答の送信、およびその後の救援サービス事業差から車両
搭乗者方向への音声の通信手段（ダウンリンク側）も、キャリア広域通信網のネットワーク(V2N)
を使用する。
V2N の通信方法のイメージを以下の(1)に示す。
(1) V2N(a) アップリンク側
異常車両は、キャリア広域通信網の通信エリア内であれば、ネットワーク（基地局）経由にて、救援サービス事業者へ救援要請メッセージを送信する。
また、救援サービス事業者からの応答受信後の音声通話における異常車両（搭乗者）から救援サービス事業者方向の音声についてもネットワーク（基地局）経由にて、救援サービス事
業者へ送信する。

―203―

ITS FORUM RC-017(b) ダウンリンク側
救援サービス事業者は、異常車両からの救援要請メッセージを受信時、応答をネットワーク（基地局）経由にて異常車両へ送信する。
また、応答の異常車両到達後の音声通話において、救援サービス事業者から異常車両（搭乗者）方向の音声についても、ネットワーク（基地局）経由にて、異常車両へ送信する。

図 7.2.1.3-1 救援要請(eCall) [1]

7.2.1.4 要件
事故自動緊急通報装置に係る協定規則（第 144 号）、および現行の HELPNET サービスを参考とする。
協定規則における主な要件は以下の通りである。
・激しい衝突の発生（エアバッグの作動）を契機として自動で発報すること・明瞭に聞き取りができるハンズフリーの音声通話ができること
・以下のような情報が発報されること
事故発生時刻、位置情報、車両特定情報 等
・位置情報は一定の精度を有すること・衝突などの衝撃を受けた後も作動すること
7.2.1.5 目標とする通信品質
事故自動緊急通報装置に係る協定規則（第 144 号）においては特に規定がなく、アプリケーショ
ン（応答有無による再送等）による通信保証を前提とする。音声通信に関しては、公衆網サービスの現行品質と同等とする。
7.2.1.6 通信エリアの条件
V2N として、通信事業者における公衆網の通信エリアを前提とする。

―204―

ITS FORUM RC-017
7.2.1.7 想定シナリオ
異常車両の通知による救援要請で想定されるシナリオは以下の通り。
1. 異常車両は、規定値以上の急減速・事故など車両の異常を自動で検出、もしくは車両搭乗者による任意のタイミングでの手動操作を契機とし、救護サービス事業者へ通知するユースケース f-1
情報（共通情報＋異常車両情報）を設定した救護要請メッセージを救護サービス事業者のサーバへ送信する。
なお、所定時間内に応答メッセージを受信するまで、同メッセージをインフラ（基地局）へ定周
期で送信する。
2. 異常車両からの救護要請メッセージを受信した救護サービス事業者は、これを受信したことを示す救援要請応答メッセージを異常車両へ送信する。
3. 救護サービス事業者のサーバからの救援要請応答メッセージを受信した異常車両は、救護サー
ビス事業者へ全ての情報を通知した場合、メッセージの送信を終了し、救護サービス事業者との音声通話を開始し、通話が終了時に通信を終了する。まだ救護サービス事業者へ通知すべき情報が存在する場合、これを設定した救護要請メッセージを救護サービス事業者のサーバに送信する。以降、全ての情報を救護サービス事業者のサーバへ送信するまで 1～2 を繰り返す。
4. 音声通話終了時、救護サービス事業者は装置を操作し、サーバから通信終了メッセージを異常車両へ送信する。
5. 救護サービス事業者のサーバから通信終了メッセージを受信した異常車両は、通信終了応答
メッセージを救護サービス事業者のサーバへ送信する。
6. 異常車両からの通信終了応答メッセージを受信した救護サービス事業者のサーバは全ての通信を終了する。

―205―

ITS FORUM RC-017
7.2.1.8 メッセージ送受信シーケンス

異常車両

インフラ
(基地局)

救護サービス
事業者サーバ

1.救護要請（共通情報＋異常車両情報）

2.救護要請応答

3.音声通話

4.通信終了5 通信終了応答
6 終了

図 7.2.1.8-1 ユースケース f-1 メッセージ送受信シーケンス―206―

ITS FORUM RC-017
7.2.1.9 メッセージサイズ
メッセージで通知する救援支援情報は、警察庁・消防庁・国土交通省発行の「接続機関における自動車からの緊急通報の取扱いに関するガイドライン」を基に、必要情報を追記した。尚、同ガイドラインにデータサイズは規定されていない。
表 7.2.1.9-1 救援要請メッセージ内容

情報要素

データサイズ

説明

メッセージ ID

8 bit

メッセージを特定する ID

車両 ID

32 bit

救援支援

自動/手動通報

1 bit(+7 bit)

情報

車両位置（緯度経度高度）

88 bit

位置精度

8 bit

車両進行方向

16 bit

走行軌跡1120 bit

車両の種類

480 bit

車体番号

8 bit

燃料種類

8 bit

ガソリン、電気等

発生時刻

32 bit異常が発生した時刻

呼び返し用電話番号

256 bit(16 bit×16(桁))共通情報

自動通報/手動通報を識別（車両位置＋位置精度＋車両進行方向）×10 地点分
車種名等(16 bit×30(文字))

契約者氏名（法人含）480 bit(16 bit×30(文字))登録ナンバー256 bit(16 bit×16(文字))事業者 ID(接続機関識別子)

16 bit

発信元電話番号

256 bit(16 bit×16(桁))

通報要因

8 bit

事故、事件など

道路番号32 bit

走行レーン

8 bit

D-Call Net 相当情報

NOTE：以下の情報要素はガイドラインでは異常車両→救護サービス事業者間では設定されず、救護サービス事業者が警察・消防への通信の際に追加設定を行う可能性がある。
車両の種類
呼び返し用電話番号
契約者氏名（法人含）登録ナンバー
発信元電話番号
通報要因

―207―

ITS FORUM RC-017
7.2.2

ユースケース f-2. 交通流の最適化のための情報収集

7.2.2.1 通信の目的
自動運転車から送信される車両情報による交通流の最適化。
7.2.2.2 通信の概要
自動運転車から自動車メーカ、交通情報提供事業者等に⾛⾏⾞両の位置や速度のデータを付加したメッセージを公衆通信網及び、路側インフラ経由で送信し、交通量の分析や最適化を⾏なうために収集する。
インフラ(路側インフラ、基地局)

自動車メーカ、交通情報提供事業者等

図 7.2.2.2-1 交通流の最適化のための情報収集 [1]7.2.2.3 車両情報の配信方法
自動運転車から情報収集を行う契機は以下の 3 種類とする。それぞれ相互に干渉せず独立して処理を行う。
・交差点周辺における情報収集
・車両の動作に関する所定イベント（規定値以上の急減速時等）発生時の情報収集
・走行エリアや車両動作に依存しない定周期での情報収集
また、其々の契機における情報収集で使用する通信方式は以下の通りである。
・交差点周辺における情報収集
自動運転車から路側インフラ(V2I)経由で車メーカ、交通情報提供事業者等にメッセージを配信
・車両の動作に関する所定イベント（規定値以上の急減速時等）発生時の情報収集
・走行エリアや車両動作に依存しない定周期での情報収集
自動運転車からキャリア広域通信網のネットワーク(V2N)経由で車メーカ、交通情報提供事業者
等にメッセージを配信―208―

ITS FORUM RC-017(1) 路側インフラ(V2I)経由で情報収集する方式
自動運転車が路側インフラのある交差点に接近した際に、路側インフラが発信しているブロード
キャスト通信を自動運転車が受信したことを契機に通信を開始する。
自動運転車両は車両情報(時刻、車両位置、車両状態等)を 1 秒周期で路側インフラに対して送信する。
(a) 想定される通信エリアの検討(V2I)
交差点における情報収取は、右折車線など車両が走行する車線情報の収集により交差点通過後の車両の進路も予測が可能であることから、交差点の中央部から右折車線の開始位置までの範囲を通信エリアと定める。
具体的には路側機設置場所(交差点の 4 隅のいずれか)から半径 171.8(m)の円を通信エリアとする。
以下に通信エリアの算出根拠を示す。
前提条件：道路の設計速度＝60(km/h)、：片側３車線の十字路交差点：道路の幅員 3.5(m)
通信エリアの半径は、以下の３つの合計値となる。
・右折車線（＝左折車線）の長さ
・停止線から交差点中央部までの距離・交差点中央部から路側機設置場所(交差点の 4 隅のいずれか)までの距離
それぞれの長さを以下に算出する
・右折車線の長さ

図 7.2.2.3-1 右折車線の構成 [2]ld:テーパ長（ｍ）：以下の lb、lc の大きい方の値―209―

ITS FORUM RC-017
lb:減速のため必要な最小値(m)下表に示す通り、設計速度、道路区分により決定される。
表 7.2.2.3-1 lb:減速のために必要な最小値(m)区分

地方部の主要道(m)

設計速度(km/h)

地方部の主要道および都市部の道路(m)

80

60

45

60

40

30

50

30

20

40

20

15

30

10

10

20

10

10

前提条件（設計速度 60(km/h)）より、lb は値の大きな 40(m)となる。
lc:次の計算式より算出(m)lc＝(V×ΔW)÷6
V:設計速度(km/h)

ΔW:横方向のシフト長(付加車線の幅員と考えてよい) (m)前提条件（設計速度 60(km/h)）より
lc=（60×3.5）÷6=210÷6=35
lb＝40(m)、lc=35(m)より、ld は 40(m)ls:滞留長（ｍ）
計算式 ls = λr × N × S(m)λr

：右折車線長係数N：１サイクル当たりの平均右折台数(台/サイクル)S：平均車頭間隔(m)―210―ITS FORUM RC-017
N：10 とする。
大型の交差点で 1 サイクル当たり 10 台右折するものと想定する。
S：6 とする。
車両長 5(m)、車両間隔 1(m)とする。
λr：1 サイクル当たりの右折車両数により変動。下表より、N が 10 であれば λr は 1.5。
表 7.2.2.3-2 右折車線長係数 λr:の値

平均右折台数

2 以下

3

5

8

10 以上

2.2

2.0

1.8

1.6

1.5

(台/サイクル)
λr以上より、
ls = λr × N × S＝1.5×10×6＝90(m)
よって、右折車線長 L（ｍ）はld+ls=40＋90＝130(m)・停止線から交差点中央部までの距離
停止線から交差点中央部までの距離は、下図で示すと”d+横断歩道幅+a+交差路の片側車線幅”となる。
図 7.2.2.3-2 交差点における路側機の通信範囲 [3]d=2m、横断歩道幅＝4m、a=4m、とする。

―211―

ITS FORUM RC-017
また、交差路の片側車線幅は、3.5m×3(車線)＝10.5m。
以上より、”d+横断歩道幅+a+交差路の片側車線幅”＝2+4+4+10.5＝20.5m となる。
・交差点中央部から路側機設置場所(交差点の 4 隅のいずれか)までの距離
路側機の設置場所を停止線位置+d とすると、交差点中央から路側機設置場所までの距離は、”交差路の片側車線幅(10.5m)+a(4m)+横断歩道幅(4m)”、と”片側車線数(10.5m)“辺とした直角三角形の斜辺長であり、三平方の定理より 21.3m となる。
以上より、円形の通信エリアの半径は・右折車線の長さ：130(m)・停止線から交差点中央部までの距離：20.5(m)・交差点中央部から路側機設置場所(交差点の 4 隅のいずれか)までの距離：21.3(m)130(m)＋20.5(m)＋21.3(m)＝171.8(m)半径171.8(m)

右折レーン

図 7.2.2.3-3 交差点における路側機の通信範囲(b) 想定される報知車両数(V2I)
以下の前提条件より、最大数は（171.8×3×2×4）/（5.6×1+5）＝389（台）対象エリア：交差点半径 171.8m、360 度
車線数/差路数：片側 3 車線/4 差路―212―

ITS FORUM RC-017
車両速度：20km/h(5.6m/s)
車両間隔：1s
車両長：5ｍ(c) 車両 ID(V2I)
路側インフラが車両 ID を割り当てることを前提とする。
(d) 想定する通信シナリオ(V2I)
交通流の最適化のための情報収集(V2I)で想定するシナリオは以下の通り
1.

路側インフラは 1 秒周期で情報収集エリアに存在する車両から情報を収集するためにブロードキャストでメッセージを送信する。

2.

路側インフラの情報収集範囲内に存在する自動運転車は、路側インフラからのブロードキャ
ストを受信した場合に車両情報を路側インフラに送信する。

3.

路側インフラは自動運転車から受信した車両情報を車メーカ、交通情報提供事業者等にメッセージとして送信する(e) メッセージ送受信シーケンス(V2I)

路側インフラ

自動運転車

車メーカ
交通情報提供事業者等

1.ブロードキャスト

2.ユースケース f-2 情報（共通情報＋車両情報）
3.ユースケース f-2 情報（共通情報＋車両情報）

図 7.2.2.3-4 ユースケース f-2.(V2I)メッセージ送受信シーケンス(f) 目標とする通信品質(V2I)
アプリケーション（応答有無による再送等）による通信保証を前提とする。

―213―

ITS FORUM RC-017(2)

キャリア広域通信網のネットワーク(V2N)経由で配信する方式

自動運転車は所定イベント（規定値以上の急減速時等）が発生したことを検出した場合、または定周期(60 秒)が経過したことを契機に通信を開始する。
自動運転車両は通信時に車両情報(時刻、車両位置、車両状態等)を公衆網経由で車メーカ、交通情報提供事業者等のサーバへ送信する。
(a) 想定される通信エリアの検討(V2N)
通信事業者における公衆網の通信エリアを前提とする。
(b) 車両 ID(V2N)
車両に車両 ID が付与されていることを前提とする。
(c) 想定する通信シナリオ(V2N)
・所定イベント（規定値以上の急減速時等）による起動
交通流の最適化のための情報収集(V2N)（所定イベントによる起動）で想定するシナリオは以下の通り。
1.

自動運転車は所定イベント（規定値以上の急減速時等）が発生したことを検知する度に、自動運転車から車メーカ、交通情報提供事業者等へ通知するデータ(時刻、車両位置、車線、車速、
急加減速値など)を設定したメッセージを車メーカ、交通情報提供事業者等のサーバに送信する。

2.

自動運転車は車メーカ、交通情報提供事業者等へ通知すべきデータがまだ存在する場合、通知すべきデータを設定したメッセージを車メーカ、交通情報提供事業者等のサーバに送信する。
以降、全てのデータを車メーカ、交通情報提供事業者等のサーバへ送信するまで 1 を繰り返す。
・定周期における起動1.

自動運転車は、定周期ごとに自動運転車から車メーカ、交通情報提供事業者等へ通知するデー
タ(時刻、車両位置、車線、車速、急加減速値など)を設定したメッセージを車メーカ、交通情報提供事業者等のサーバへ送信する。

―214―

ITS FORUM RC-017(d) メッセージ送受信シーケンス(V2N)
・所定イベント（規定値以上の急減速時等）による起動

自動運転車

インフラ
（基地局）

車メーカ
交通情報提供事業者等
サーバ

1.ユースケース f-2 情報（共通情報＋車両情報）

Yes

通知すべきデータが存在する

No

図 7.2.2.3-5 ユースケース f-2.(V2N)所定イベントによる起動のメッセージ送受信シーケンス

・定周期による起動

自動運転車

インフラ
（基地局）

車メーカ
交通情報提供事業者等
サーバ

1.ユースケース f-2 情報（共通情報＋車両情報）

図 7.2.2.3-6 ユースケース f-2.(V2N)定周期による起動のメッセージ送受信シーケンス―215―

ITS FORUM RC-017
7.2.2.4 目標とする通信品質（V2N）
アプリケーション（応答有無による再送等）による通信保証を前提とする。
7.2.2.5 メッセージサイズ
表 7.2.2.5-1 f-2.メッセージ内容(V2I/V2N 共通)

情報要素
共通情報

車両情報

データサイズ

説明

メッセージ ID

8 bit

メッセージを特定する ID

車両 ID

32 bitV2I/定期/イベント配信

2 bit(+空き 6 bit)

車両長さ

14 bit(+空き 2 bit)

車両情報送信時刻

32 bit

レーン情報
車両位置（緯度経度高度）

14 bit(+空き 2 bit)
88 bit

車両進行方向

16 bit

車両速度

16 bit前後加速度

16 bit―216―

V2I/定期/イベントを識別

ITS FORUM RC-017
7.2.3

ユースケース f-3. 地図更新・自動生成

7.2.3.1 通信の目的
車両で収集した地図情報の自動車メーカ、地図情報提供事業者への提供。
7.2.3.2 通信の概要
車両で走行時、収集した検出対象情報と保持する地図情報に変化点が検出された場合、地図情報（変化点の情報）を、車両から自動車メーカ、地図情報提供事業者へ送信する。

図 7.2.3.2-1 地図更新・自動生成 [1]7.2.3.3 地図情報（変化点の情報）の送信方法
車両にて走行時に収集した検出対象情報と保持する地図情報に変化点が検出された場合、車両からインフラ（基地局）を介し、自動車メーカ、地図情報提供事業者のデータ収集センタ(以下、データ収集センタ)へ変化点に関する地図情報を直ちに送信する。データ収集センタは、車両からの地図情報を受信すると、これを蓄積し、応答を車両に送信する。
車両からデータ収集センタへの地図情報の送信（アップリンク側）は、キャリア広域通信網のネットワーク(V2N)を使用する。
データ収集センタから車両への応答の送信（ダウンリンク側）も、キャリア広域通信網のネット
ワーク(V2N)を使用する。
V2N の通信方法のイメージを以下の(1)に示す。

―217―

ITS FORUM RC-017(1) V2N(a) アップリンク側
車両は、キャリア広域通信網の通信エリア内であれば、ネットワーク（基地局）経由にて、自動車メーカ、地図情報提供事業者へ地図情報を送信する。
(b) ダウンリンク側
データ収集センタは、車両からの地図情報を受信時、ネットワーク（基地局）経由にて、応答を車両へ送信する。
7.2.3.4 要件
・地図情報の更新に際し、車両で検出した変化点はリアルタイムで送信する。
・新規に開通した道路など、道路自体が車両の地図に未登録であるケースは想定しない。
・車両における変化点検出対象は以下の 2 つとする。
① 道路標識・信号機② 道路ペイント（道路標示・区画線：車線の実線、点線、色、右左折直進レーンの矢印等）
道路交通法「道路標識、区画線及びによる道路標示に関する命令（総理府・建設省令）」より、変化点検出対象となる道路標識、道路ペイントの種類は 247 種類、道路標示は 44 種類、区画線は 8 種類。
・車両は変化点検出時、地図情報として変化点の検出対象とその位置情報、画像を提供する。LiDAR
点群データは提供しない。

―218―

ITS FORUM RC-017
7.2.3.5 目標とする通信品質
通信事業者における公衆網での通信品質とし、特に規定しない。
アプリケーション（応答有無による再送等）による通信保証を前提とする。
7.2.3.6 通信エリアの条件
V2N として、通信事業者における公衆網の通信エリアを前提とする。
7.2.3.7 想定シナリオ目標とする通信品質
本シナリオは、車両からインフラ（基地局）を介した自動車メーカ、地図情報提供事業者のデー
タ収集センタへの通信を対象とする。データ収集センタで収集したデータの分析・活用を行うため、データ収集センタから自動車メーカ、地図情報提供事業者のデータ分析システムへのデータの通信を行うことが想定されるが、本ユースケースではこの間の通信は考慮しない。
1. 走行中時に収集した検出対象情報（標識・信号種別、道路ペイント）と自車が所有する地図情報
間の変化点を検出した車両は、自動で変化点に関するデータを設定した地図情報メッセージをデータ収集センタのサーバへ送信する。
2. 車両は、まだデータ収集センタへ通知すべきデータが存在する場合、これを設定した地図情報
メッセージをデータ収集センタのサーバへ送信する。以降、全てのデータをデータ収集センタへ送信するまで 1.を繰り返す。

―219―

ITS FORUM RC-017
7.2.3.8 メッセージ送受信シーケンス

インフラ
（基地局）

車両

データ収集
センターサーバ

1.地図情報（共通情報＋変化点情報）

2 全ての地図情報を全て送信し応答を受信するまで 1 を繰り返す

1.地図情報（共通情報＋変化点情報）

1.地図情報（共通情報＋変化点情報）：

図 7.2.3.8-1 ユースケース f-3 メッセージ送受信シーケンス―220―

ITS FORUM RC-017
7.2.3.9 メッセージサイズ
表 7.2.3.9-1 地図情報メッセージ内容

・地図情報要素

データサイズ

説明

メッセージ ID

8 bit

メッセージを特定する ID

車両 ID

32 bit変化点

時刻

32 bit情報

車両位置（緯度経度高度）

88 bit

道路番号

32 bit

共通情報

走行レーン

8 bit

方位情報

8 bit

変化点検出対象の位置

88 bit変化点を検出した時刻

画像を撮影した瞬間のカメラの絶対方位（緯度経度高度）（変化が検出された標識・
16 bit

変化点情報

信号・道路の種別）最大 80
bit
(注 2)

8 bit

変化種別
バージョン情報
画像データ

追加、削除、変更など
最大 40 bit
地図バージョン

4.1MByte(１画像)

4K、JPEG（非圧縮）で×送信データ数

サイズを算出NOTE：情報要素の、変化点情報、変化種別は、1 メッセージ内に最大 5 セット設定可とする
NOTE：情報要素の変化点情報に設定する標識の種類は 247 種類、道路標示は 44 種類、区画線は 8
種類で合計 299 種類、信号機種別含め 16bit 長で表現可能。具体的な変化点の内容は画像データにより判断を行う
画像データ除く最大合計サイズ：752 bit (94 Byte)
画像データで少なくとも 4.1Mbyte 以上―221―ITS FORUM RC-017
7.2.4

ユースケース f-4. ダイナミックマップ情報配信

7.2.4.1 通信の目的
ダイナミックマップ情報を、インフラから車両に提供する。
7.2.4.2 通信の概要
本項ではダイナミックマップ情報の配信として、地物の変化などによる静的地図の差分更新を対象とする（動的地図については他のユースケースで考慮する）。自動運転車が走行中、Push ないしPull 型通信により、走行対象ルート上の静的地図の差分更新を行う。配信されるデータには競争領
域・協調領域それぞれの情報が包含され、車両メーカ単位、かつ車種やシステム単位で配信が行われる。したがって少なくとも当面はユニキャスト通信により配信が行われると想定する。
7.2.4.3 目標とする通信品質
通信事業者における公衆網での通信品質とし、特に規定しない。
アプリケーション（応答有無による再送等）による通信保証を前提とする。
7.2.4.4 通信エリアの条件
V2N として、通信事業者における公衆網の通信エリアを前提とする。
7.2.4.5 地図データサイズ
静的地図の非圧縮時データサイズ例を下表に示す。本データサイズはあくまで一例であり、自動運転車の実装により実際のサイズは異なる。また、実際にはデータ圧縮や差分更新でこれよりも小さいデータサイズとなる。
表 7.2.4.5-1 静的地図のデータサイズ（非圧縮）

都市部
地方
全国

高速道路
数 MB/km2
十数 MB/km2
十数 GB

一般道路
百数十 MB/km2
数百 MB/km2
1 TB 前後

7.2.4.6 自動運転車のふるまい
静的地図更新状況に応じた自動運転車のふるまいとして、ルート選択条件に着目して 3 通りに分類する。
1. ルート選択条件として、対象ルート内の静的地図が更新済みであることを含む
2. ルート選択条件として、走行中に対象ルート内の静的地図が更新可能であることを含む
3. ルート選択条件として、対象ルート内の静的地図更新を考慮しない（必須としない）―222―

ITS FORUM RC-017
これらのうち、(1) は夜間バッチ更新などの手段での情報配信が必要となり、モバイル通信を必須としないため検討対象から除外する。また、(3)についてもモバイル通信での情報配信を必須としないため検討対象から除外する。以上より本書では(2)の場合についての通信要件を検討する。
7.2.4.7 データ配信の条件
自動運転車は ODD や目的地が設定されていることから、走行ルート上の地図更新を配信サーバに対して問い合わせ、更新データの配信を受ける Pull 型の配信形態を想定する。
7.2.4.8 想定シナリオ
本通信シナリオ案では簡単のため L km 先の W km × D km の矩形エリアの地図タイルを先読みする形態について通信要件の検討を行う。ここで、L は通信速度のゆらぎ、地図先読みヒット率、
走行開始前の地図配信待機時間などの設計値に基づき設定されるもので、本書では具体的には定めない。W および D はリルート確率、地図先読みヒット率などの設計値に基づき設定されるものであり、一定以上の面積とすることで地図更新が間に合わないことによるリルート NG 判断を回避する。以降ではルート判断の自由度を一定確保する観点から、ルート変更ポイントの 60 秒手前まで
はリルート判断ができる W、 L を高速道路、一般道路について仮定して通信要件の試算を行う。

配信対象地図タイル
リルート確率、地図先読みヒット率などの設計値に基づき設定

W km

自車位置

設定ルート

L km
通信速度のゆらぎ、地図先読みヒット率
走行開始前の地図配信待機時間などの設計値に基づき設定

D km

図 7.2.4.8-1 ダイナミックマップ情報配信モデル―223―

ITS FORUM RC-017
遅延本モデルでは通信遅延に応じた L を設定することが可能であるため、遅延に関する要件は生
じない。
通信速度
地図配信のためダウンロード速度に関する通信要件が生じる。
地図データ量、時速を高速道路、一般道それぞれについて下表のように定めた場合、それぞれの平均ダウンロード速度に関する要件は最大で 67 Mbps（地方の一般道路）となる。
表 7.2.4.8-1 通信速度試算例（走行中の静的地図の先読み更新）

単位

高速道路

一般道路

都市

地方

都市

地方

X:地図データ量MB/km2

5

15

150

500

V:時速

km/h

120

120

60

60

W:タイル幅

Km

2

2

1

1

D:タイル奥行き

Km

2

2

1

1

T:タイル通過時間(D/V)

sec

60

60

60

60

X’:タイルデータ量(X×W×D)

MB

20

60

150

500

所要 DL 速度(X’/T)

Mbps

2.7

8.0

20.0

66.7

算出した所要ダウンロード速度が必要となる連続的な地図更新が実際に生じえる例として、新たな道路の開通に伴い広域にわたり地図更新が生じるケースが考えられる。模式図を下図に示す。
t=0
自車位置

地図タイル
#1 （更新あり）

で配信完了

t= Δt

自車位置

地図タイル
#2 （更新あり）

で配信完了

t= 2 Δt

自車位置

地図タイル
#3 （更新あり）

で配信完了

図 7.2.4.8-2 連続的なダイナミックマップ情報配信の例―224―

ITS FORUM RC-017
7.2.4.9 メッセージ送受信シーケンス
情報配信
センタ
サーバ

インフラ
（基地局）

車両

1.地図情報問合せ（共通情報＋地図情報）

2.地図情報応答（更新有無）

地図タイルデータ応答

図 7.2.4.9-1 ユースケース f-4 メッセージ送受信シーケンス

7.2.4.10

メッセージサイズ
表 7.2.4.10-1 f-4.メッセージ内容

・情報要素
共通情報

地図情報

データサイズ

説明

メッセージ ID

8 bit

メッセージを特定する ID

車両 ID

32 bit

車両を特定する ID
問合せ対象の地図タイルの

地図タイル ID

ID

バージョン情報―225―

ITS FORUM RC-017
7.3 参考文献[1] SIP 協 調 型 自 動 運 転 ユ ー ス ケ ー ス -2019 年 度 協 調 型 自 動 運 転 方 式 検 討 TF 活 動 報 告https://www.sip-adus.go.jp/rd/rddata/usecase.pdf[2] 日本道路協会：技術情報＞「道路構造令の解説と運用」平成 15 年度
４年３月）Ⅲ道路の構造

第４章

地区講習会資料（２００

平面交差

https://www.road.or.jp/technique/pdf/09_kouzou4.pdf[3] 岐阜県：社会基盤 > 道路 > 道路建設 > 岐阜県道路設計要領 道路設計要領

面交差 https://www.pref.gifu.lg.jp/uploaded/attachment/240637.pdf

―226―

第5章 平

ITS FORUM RC-017

第8章

g.隊列・追従走行のユースケース

8.1 前提条件
本章固有の条件は特にない。
8.2 検討の進め方
以下のユースケースについてのシナリオ検討を進めた。
・ ユースケース g-1. 電子牽引による後続車無人隊列走行
・ ユースケース g-1. 追従走行並びに追従走行を利用した後続車有人隊列走行
8.3 隊列走行のユースケース
8.3.1

ユースケース g-1. 電子牽引による後続車無人隊列走行

ユースケース g-1 は、隊列車両の操作情報等を、隊列を形成するトラック間で通信し、隊列走行（電子牽引）の支援を行う。後続車は無人を想定し、有人/無人の混在は考えない。

図 8.3.1-1：電子牽引による後続車無人隊列走行ユースケースイメージ[1]8.3.1.1 想定する通信シナリオ①

運行計画時
下記を事前に決めておく。
（通信の対象外）
・ 隊列を形成する車両・ 隊列を形成する場所② 運行時
・ 各車両が一直線に停車している状態で隊列を形成する。先頭車両からの通信開始により隊列を開始する。
・ 車間距離は低速時 5m、最長 10m とする。（3 台で隊列長最大 60m）
・ 走行中は、すべての車両間で通信を行う。1:1 通信もしくは、ブロードキャスト通信を用いてアプリケーションで仮想的に 1:1 通信を行っても良い。

―227―

ITS FORUM RC-017
・ 走行中の通信は、非リッチコンテンツ（アクセル、ブレーキ、操舵操作、後続車両情報、
位置、速度、車間距離、加減速度）の通信と、リッチコンテンツ（電子ミラーによる２号
車から先頭車への映像伝送）を別途のメッセージとする。非リッチコンテンツがリッチコ
ンテンツに対して、優先的に送信されるものとする。
・ 非リッチコンテンツは、100ms で他車両に対して周期的に送信する。通信の信頼度は 98%
で、緊急時には 20ms 周期で 5 連送の送信を行う。
・ システムにより必要があれば、多重系で通信を行う。
・ リッチコンテンツは、映像伝送に必要な周期およびデータ量で送られる。
・ 隊列の解除は、各車両が一直線に停車している状態で解除する。
（走行中に通信を介して解除は行わない）・ 通信が途絶した場合は、隊列走行状態の維持が困難な異常とし、後続車はハザードランプ
を点灯しながら減速し停車する。

8.3.1.2 必要な通信エリアの条件
最大通信距離 60m（トラック 12m 3 台＋最大車間距離 10m）
8.3.1.3 車両 ID と車載器 ID の紐付け
通信上の ID と実車との紐づけは、事前の設定や他の通信などにより実現されているものとする。
8.3.1.4 メッセージ送受信シーケンス
・通常時
各車がアクセル、ブレーキ等の非リッチコンテンツを 100ms 周期で他の車両に送信する。
2 号車から先頭車両へ電子ミラーによる映像を伝送する。

―228―

ITS FORUM RC-017

自車両

前後の車両

非リッチコンテンツ

100ms 周期で送信
非リッチコンテンツ

非リッチコンテンツ

図 8.3.1.4-1：通常時の非リッチコンテンツ送信シーケンス

・急制動時
先頭車両から後続車両に向けて、急制動の情報を 20ms 周期で 5 連送する。
自車両

後続車両

急制動情報
20ms 周期で送信

急制動情報
急制動情報
急制動情報
急制動情報

図 8.3.1.4-2：緊急時の非リッチコンテンツ送信シーケンス―229―

ITS FORUM RC-017
8.3.1.5 通信内容
隊列走行において想定する送信データと要求条件を表にまとめる。
表 8.3.1.5-1 送信データと要求条件（非リッチコンテンツ：通常時）

送信データ
データ量
データ更新周期同一データ送信回数
信頼度
許容遅延

要求条件
100bytes 程度
100ms
2 連送で 98%
100ms

備考

送 受 処 理 遅 延 200ms 想 定 で ト ー タ ル
300ms 以内

表 8.3.1.5-2 送信データと要求条件（非リッチコンテンツ：急制動時）

送信データ
データ量
データ更新周期同一データ送信回数
信頼度
許容遅延

要求条件
100bytes 程度
更新なし
20ms 間隔で 5 連送
5 連送で 99.99%
100ms？

表 8.3.1.5-3

情報要素
共通領域管理情報
時刻情報
位置情報
車両状態情報車両属性情報後続車両情報車間距離
アクセル、ブレーキ

備考
ブレーキ情報は必須とする
1 データ 5 回の送信後は各車両で制動動作

通常時と同じ？

ITS Connect システム 車間通信メッセージ仕様[2]から

データサイズ(bytes)
8
4
11
9

内容

備考
ITS Connect 必須
ITS Connect 必須
ITS Connect 必須
ITS Connect 必須

車速、方位、加速度、シ
フトポジション、ステア
リング角度
4
車両サイズ、車長等
ITS Connect 必須
ITS Connect の場合は エンジン始動状況、水 ITS Connect 自由領域
合わせて最大 60
温、燃料残量、異常情報（システム故障情報等）
ITS Connect 自由領域
ITS Connect 自由領域

リッチコンテンツについては、フルハイビジョンのリアルタイム通信を必要とし、カメラ～ディ
スプレイ区間での遅延や通信品質としては、国連欧州委員会 Regulation 46 電子ミラー規定が参考になりうるが、どの画像符号化方式を用いるかに応じて、画像の符号化・復号化の遅延が異なり、その結果、無線区間に要求される伝送帯域幅と通信遅延が異なる。カメラやディスプレイでの遅延も実装を考慮して無線区間の通信遅延を規定する必要がある。これらから、具体的な内容やサイズについては、本資料では規定できていない。

―230―

ITS FORUM RC-017
8.3.2

ユースケース g-2. 追従走行並びに追従走行を利用した後続車有人隊列走行

位置や速度や前方車両の運転操作情報等を、前後の車両間で通信し、追従走行の支援を行う。

図 8.3.2-1：追従走行並びに追従走行を利用した後続車有人隊列走行ユースケースイメージ[1]本ユースケースは【追従走行】（上記図中の乗用車 2 台で例示）と【後続車有人隊列】（上記図中のトラック 4 台で例示）に分かれる。まずは各ユースケースのサービス概要を以下に説明し、その後、双方のユースケースを提供可能な通信に係る要件・条件等を記載する。

―231―

ITS FORUM RC-017【追従走行】の概要(1) サービス前提
・ACC(Adaptive Cruise Control))が機能している状態を前提とする。
・加減速や車間の制御は ACC の範囲内とする。
(2) サービスコンセプト・CACC(Cooperative Adaptive Cruise Control)による追従走行は、ACC の追従機能を更にスムーズにするもの。先行車両がベーシックセーフティな情報（位置、方位、車速、加速度等）
を定期的に送信し、追従車両は自律センサからの情報に加え、先行車両のベーシックセーフ
ティな情報を活用することでよりスムーズに追従制御する。
(3) サービス目標
CACC は、ACC よりもスムーズに追従することを目標とする。具体的には、・先行車の加速／減速に追従する際の加速度／減速度の最大値を ACC よりも小さくする
・先行車の加速／減速に追従する際の車間の変化量を ACC よりも小さくする
・先行車の加速／減速に追従する際の追従遅れ（時間）を ACC よりも小さくする※通信要件を検討する上では、定量的な目標値は置かない（先行車両の挙動と追従車両を完全にシンクロすることが追従車両のドライバにとって best ではないため）。
(4) サービスシナリオ①ACC による追従走行開始②先行車両がベーシックセーフティな情報を定期的に送信③追従車両が自律センサ（ACC）で捉えている先行車両と、通信上の先行車両が一致しているかを検証④先行車両のベーシックセーフティな情報を ACC の制御に活用し、自律センサ単独の制御よりもスムーズに追従する。
(5) サービス中断条件
・先行車両が ACC の動作範囲を超える加減速・車速で走行した場合（例）急減速であれば CACC からプリクラッシュブレーキへ移行
・先行車両が同一車線上からいなくなった場合・間に他の車両が割り込んだ場合（例）割り込み車両が通信非搭載であれば先行車両への CACC から割込み車両への ACC―232―

ITS FORUM RC-017(6) 車間・ACC の設定に準じる。つまり OEM のシステム設計やドライバの選択により車間は変わる。
・トラックではヒアリング結果によると車間は 35m・乗用車では、ACC の車間は 30m～80m [3][4]―233―

ITS FORUM RC-017【後続車有人隊列】(1) サービス前提
追従と同じ(2) サービスコンセプト
CACC 隊列走行は、ACC の追従機能を更にスムーズにするもの。隊列の各車両がベーシック
セーフティな情報（位置、方位、車速、加速度等）を定期的に送信し、自律センサからの情報に加え、各車両のベーシックセーフティな情報を活用することでよりスムーズに追従制御する。
（CACC 追従を連ねた場合、1 台目の加減速に 2 台目が追従するのに 3 台目が追従…と 1 台 1 台
波及するが、CACC 隊列であれば（システム設計によるが）例えば 1 台目の加減速に 2～4 台目が揃ってスムーズに追従することが想定できる。事業者ヒアリングでも、隊列内の全ての車両のメッセージを使用する必要があるかはシステム設計次第とのことだが、通信要件検討上は使用する前提で考える）(3) サービス目標
追従と同じ(4) サービスシナリオ①ACC による追従走行開始②各車両がベーシックセーフティな情報を定期的に送信③各追従車両が自律センサ（ACC）で捉えている先行車両と、通信上の先行車両が一致しているかを検証④各車両が通信上の先行車両の ID を送信し、各車両の隊列内における順番を特定する。
⑤先頭車両～先行車両のベーシックセーフティな情報を ACC の制御に活用し、自律センサ単独の制御よりも早く追従する。
(5) サービス中断条件
追従と同じ(6) 車間の想定
・1 台 1 台の車間は追従走行と同様に考える。
・CACC 隊列走行をする場合、車間を広くとるとサービス中断条件を容易に満たしサービス性が損なわれるため、短い側で検討する。
・4 台連なる場合、隊列の車長は車長 12m×4＋車間 35m×3＝153m
先頭車両アンテナと 4 台目アンテナの間隔は、（車間 35m＋車長 12m）×3＝141ｍ―234―

ITS FORUM RC-017

8.3.2.1 想定する通信シナリオ
・本サービスシナリオの全てのステップにおいて、先行車両、追従車両が約 100msec に一度の周期でベーシックセーフティな情報をブロードキャストし続ける。
8.3.2.2 必要な通信エリアの条件
・通信要件を検討する上では、-最大の車間距離は通信距離に影響する-最小の車間距離は主に先行車両の急減速時のメッセージ間隔に影響する可能性がある。
（例）g-1 では車間 10m 以内のため、先行車両急ブレーキ時は 20msec が必要。
・最大の通信エリアは CACC 隊列でトラック 4 台の場合 141m（
（車間 35m＋車長 12m）×3）
・最小の通信エリアは CACC 追従の乗用車で 30m
本ユースケースでは ACC の範囲内で車間を設定することから、先行車両が急減速時には自律系で対応する。よって、100msec より高頻度のメッセージ送信は不要と考える。
8.3.2.3 車両 ID と車載器 ID の紐付け
・追従車両は先行車両を自律センサと通信で捉え、双方が合致していることを確かめることで車両と車載器 ID を紐づける。
8.3.2.4 メッセージセット
・位置、方位、車速、ブレーキ、加速度等のベーシックセーフティな情報（TD-001[2]の共通領域相当）に加え、ITS Connect 推進協議会規定の CACC メッセージセット（TD-001 自由領
域に格納）と同様、追従の可否やメーカを示す情報や、通信先行車 ID などを送信する。
・合計 100byte 以内。

―235―

ITS FORUM RC-017
8.3.2.5 メッセージ送受信シーケンス

図 8.3.2.5-1 追従走行の通信シーケンス

図 8.3.2.5-2 後続車有人隊列走行の通信シーケンス・サービス前中後でベーシックセーフティな情報を周期的にブロードキャストする。
※CACC 対応車両は CACC に必要なデータ（メーカやバージョン、追従可否、通信先行車 ID等）もベーシックセーフティ情報の中に含める想定。CACC 前後では一部情報は不定値とす
る）
・送信周期は 100msec※ヒアリングでは発展形として「割込み車の発生」「車間距離が開いた場合に先頭車に減速要求」「車線変更指示」というイベントベースの通信の可能性も示唆されましたが、いずれのイベ―236―

ITS FORUM RC-017
ントも元々のメッセージ（位置、車速、ウィンカ情報など）と自律センサで判断するか、メッ
セージで指示するにしても、数バイト程度であり、100msec 周期のメッセージと別に送らなければならない程の緊急性がないことから、ベーシックセーフティメッセージに載せる想定とする。
※電子牽引と異なり車間が確保されていることから、急ブレーキ時の連送は不要（CACC→自律制御）
8.4 参考文献[1] SIP 協 調 型 自 動 運 転 ユ ー ス ケ ー ス -2019 年 度 協 調 型 自 動 運 転 方 式 検 討 TF 活 動 報 告https://www.sip-adus.go.jp/rd/rddata/usecase.pdf[2] ITS Connect システム 車間通信メッセージ仕様 ITS Connect TD-001 1. 1 版
https://www.itsconnect-pc.org/_img/about/td_001.pdf[3] トヨタ PRIUS 取扱書
https://toyota.jp/pages/contents/ownersmanual/pdf/prius/prius_202010.pdf[4] Honda e 渋 滞 追 従 機 能 付 ACC （ ア ダ プ テ ィ ブ ・ ク ル ー ズ ・ コ ン ト ロ ー ル ）https://www.honda.co.jp/ownersmanual/webom/jpn/hondae/2020/details/136192090-85520.html―237―

ITS FORUM RC-017

[余白]

―238―

ITS FORUM RC-017

第9章

h.遠隔操作のユースケース

9.1 遠隔操作における条件
遠隔操作のシナリオにおいて、以下の条件で検討した。

ユースケース・ ユースケース h-1. 移動サービスカーの操作・管理
対象車両
・ バス、タクシーを対象とする

自動運転レベル・ 車両に運転者が存在しない自動運転レベル 4、レベル 5 の車両を対象とする
時刻精度
・ インフラおよび協調走行車は、メッセージ内容の時刻情報の理解のため、それぞれ GNSS
同期の時刻情報を持っているものとする。ただし、所持する時刻精度および GNSS 非補足時に許容される時刻精度は要検討

道路条件
・ 自専道、一般道における任意の道路を対象とする

車線数
・ 自専道の車線数：片側 6 車線を最大とする
・ 一般道の車線数：片側 3 車線を最大とする
想定車間距離・ 通常環境：2 秒車間とする

・ 混雑した環境：1 秒車間とする

速度条件
・継続検討とする

目標とする通信品質
・ 通信品質は各ユースケースにおける要求条件として検討する―239―

ITS FORUM RC-017
9.2 h.遠隔操作のユースケース
9.2.1

ユースケース h-1. 移動サービスカーの操作・管理

9.2.1.1 通信の目的
自律型自動運転システムでは回避困難な交通環境の場合、移動サービスカーからの映像情報等と運行管理者からの遠隔操作指示を、運行管理者と移動サービスカー間で通信し、遠隔地からの車両操作・管理を行う。

図 9.2.1.1-1 移動サービスカーの操作・管理[1]

9.2.1.2 通信の概要
自律型自動運転システムは、レベル 4 ないしレベル 5 に対応した車両を前提とし、以下の通信を行う。

・車両～遠隔監視センタ間の疎通確認
遠隔操作を実施するに際し、運行管理者と移動サービスカー間の通信時間（応答性）により、遠隔操作の内容（例：経路指示、遠隔操縦等）が異なることが想定される。車両が回避困難な交通環境に遭遇した場合、その時点での遠隔操作の内容を車両と遠隔監視センタの間で的確に判断できるよう、車両と遠隔監視センタの間で通信時間（応答性）の把握を定期的に実施する。

・車両が回避困難な交通環境に遭遇時
以下の 2 つのケースに応じた通信を行う。

―240―

ITS FORUM RC-017
ケース h-1a：遠隔監視センタから遠隔操縦を実施（車両は ODD の条件外における遠隔操縦の指示：SAE J3016_202104 における
「REMOTE DRIVING 」に相当。本ケースの適用中はレベル 4/5 に対応した自動運
転車がレベル 3 以下の自動運転レベルで運用される状態を想定する。）
遠隔監視センタでは、車両から受信した遠隔操作要求情報、および車両から配信された車両周辺映像等に基づき、遠隔監視センタから遠隔操縦を行う。車両が自身で自動運転が可能な地点へ到達したことの判断を以て、遠隔操縦を終了する。この間は車両から配信された車両周辺映像等に基づき、遠隔監視センタで遠隔監視を行う。
ケース h-1b：遠隔監視センタから車両に経路を指示し、車両が自律型自動運転を実施（ODD の条件下における走行経路の指示：SAE J3016_202104 における「REMOTEASSISTANCE」に相当）
遠隔監視センタでは、車両から受信した遠隔操作要求情報に基づき、車両が自身で自動運転が可能な地点へ移動を行うための経路情報を車両に送信する。車両では、遠隔監視センタから受信した経路情報に従い、自律型自動運転を行う。この間は車両から配信された車両周辺映像等に基づき、遠隔監視センタで遠隔監視を行う。
なお、車両が自身で自動運転が可能な地点へ移動を行うための経路情報は、複数回の情報が必要となるケースも考えられる。この場合には車両は再度遠隔監視センタへ遠隔操作要求を行い、遠隔監視センタから受信した経路情報に従い、自律型自動運転を行う。自身で自動運転が可能な地点への移動が完了するまで、これを繰り返す。
9.2.1.3 目標とする通信品質
アプリケーション（応答有無による再送等）による通信保証を前提とする。無線区間許容遅延、及び 1 パケット当たりのパケット到達率については今後の課題とする。
9.2.1.4 通信エリアの条件
V2N として、通信事業者における公衆網の通信エリアを前提とする。

―241―

ITS FORUM RC-017
9.2.1.5 想定シナリオ(1) 車両～遠隔監視センタ間の疎通確認
1. 車両は起動を契機とし、遠隔監視センタとの間で通信の疎通確認を行うため、遠隔監視疎通
確認メッセージを遠隔監視センタのサーバへ送信する。
2. 車両からの遠隔監視疎通確認メッセージを受信した遠隔監視センタのサーバは、応答を車両へ送信する。
3. 遠隔監視センタのサーバからの応答を受信した車両は、電源が OFF されるまで、一定の間隔を設け、1～2 を継続して実施する。
4. 疎通確認において通信品質要件を満たさなかった場合、移動サービスカーが h-1 のユースケースが実施できないことを車両ないし管制センタに通達する。
(2) 車両が回避困難な交通環境に遭遇：ケース h-1a
＜遠隔監視センタから遠隔操縦を実施＞
1. 車両は、回避困難な交通環境に遭遇時、遠隔監視センタへ支援を仰ぐため、位置情報等の遠隔操作に必要な情報を設定した遠隔操作要求メッセージを遠隔監視センタのサーバへ送信する。
2. 車両からの遠隔操作要求メッセージを受信した遠隔監視センタのサーバは、応答を車両へ送信する。
3. 遠隔監視センタのサーバからの応答を受信した車両は、車両周辺映像等を遠隔監視センタのサーバへ常時配信を行う。
4. 遠隔監視センタは、遠隔操作要求メッセージで車両から受信した情報と車両周辺映像等に基づき遠隔操縦を行う。遠隔操縦データはサーバから車両へ常時配信を行う。
5. 車両は自身で自動運転が可能な地点へ移動するため、位置情報など遠隔操縦に必要な情報を設定した遠隔操作要求メッセージを遠隔監視センタのサーバへ送信する。
以降、車両が自身で自動運転が可能な地点へ到達するまで、3～4 を繰り返す。
6. 遠隔監視センタでは、車両が自身で自動運転が可能な地点への到達を検出時、遠隔監視センタのサーバから車両へ遠隔操作終了メッセージを送信する。
7. 遠隔監視センタのサーバからの遠操操作終了メッセージを受信した車両は遠隔監視センタからの遠隔操縦が終了したことを認識する。以降、車両自身による自動運編を実施する。

―242―

ITS FORUM RC-017(3) 車両が回避困難な交通環境に遭遇：ケース h-1b
＜遠隔監視センタから車両に経路を指示し、車両が自律型自動運転を実施＞
1. 車両は、回避困難な交通環境に遭遇時、遠隔監視センタへ、位置情報等の遠隔操作に必要な情報を設定した遠隔操作要求メッセージを遠隔監視センタのサーバへ送信する。
2. 車両からの遠隔操作要求メッセージを受信した遠隔監視センタのサーバは、応答を車両へ送信する。
3. 遠隔監視センタのサーバからの応答を受信した車両は、車両周辺映像等を遠隔監視センタのサーバへ常時配信を行う。
4. 遠隔監視センタのサーバは、車両から遠隔操作要求メッセージで受信した情報や映像等に基づき、車両が自身で自動運転が可能な地点へ移動を行うための経路情報を遠隔操作
指示メッセージに設定し、車両へ送信する。
5. 遠隔監視センタのサーバからの遠隔操作指示メッセージを受信した車両は、同メッセー
ジに設定された経路情報などに基づき、自身で自動運転が可能な地点へ向け、遠隔監視
センタの指示による自律型自動運転を開始する。また、同地点へ移動するために追加情報が必要な場合、遠隔操作要求メッセージを遠隔監視センタのサーバへ送信する。
6. 車両からの遠操操作要求メッセージを受信した遠隔監視センタのサーバは、車両が自身で自動運転が可能な地点へ移動を行うための経路情報を遠隔操作指示メッセージに設定し、同メッセージを車両へ送信する。
以降、車両が自身で自動運転が可能な地点へ到達するまで、5～6 を繰り返す。
7. 遠隔監視センタでは、車両は自身で自動運転が可能な地点への到達を検出時、サーバから車両へ遠隔操作終了メッセージを送信する
8. 遠隔監視センタのサーバからの遠隔操作終メッセージを受信した車両は、遠隔監視センタの指示による自動運転を終了する。以降、車両自身による自動運編を実施する。

―243―

ITS FORUM RC-017
9.2.1.6 メッセージ送受信シーケンス(1) 車両～遠隔監視センタ間の疎通確認
インフラ
（基地局）

車両

遠隔監視
センタ
サーバ

起動
1.遠隔監視疎通確認

2 応答
3
一定間隔で 1 送信を実施(2 受信を繰り返す)

1.遠隔監視疎通確認

2 応答
繰り
返し
1.遠隔監視疎通確認

2 応答

：
4
一定間隔内に 2 未受信時 h-1 のユースケースが実施できないことを車両ないし管制センタに通達

図 9.2.1.6-1 ユースケース h-1 車両～遠隔監視センタ間の疎通確認のメッセージ送受信シーケンス―244―

ITS FORUM RC-017(2) 車両が回避困難な交通環境に遭遇：ケース h-1a
＜遠隔監視センタから遠隔操縦を実施＞
車両

インフラ
（基地局）

遠隔監視
センタ
サーバ

1.遠隔操作要求（共通情報＋遠隔操作情報）

2.応答

3.映像
4.遠隔操縦データ
5.遠隔操作要求（共通情報＋遠隔操作情報）

車両自身で
自動運転
可能な
エリアに

5.遠隔操作要求

到達するまで（共通情報＋遠隔操作情報）

繰り返す

：
車両自身で
自動運転
可能な
6.遠隔操作終了（共通情報）

地点に到達→遠隔操縦終了

7 遠隔
操縦
終了

車両周辺映像

遠隔操縦データ

図 9.2.1.6-2 ユースケース h-1a のメッセージ送受信シーケンス―245―

ITS FORUM RC-017(3) 車両が回避困難な交通環境に遭遇：ケース h-1b
＜遠隔監視センタから車両に経路を指示し、車両が自律型自動運転を実施＞

車両

インフラ
(基地局)

遠隔監視
センタ
サーバ

1.遠隔操作要求（共通情報＋遠隔操作情報）

2.応答

3 車両周辺映像
4.遠隔操作指示（共通情報＋遠隔操作情報）
5
遠隔監視
センタ
の指示

5.遠隔操作要求

車両自身で

による

（共通情報＋遠隔操作情報）

自動運転
可能なエリア

自動運転
6.遠隔操作指示（共通情報＋遠隔操作情報）に到達するまで繰り返す：7.遠隔操作終了（共通情報）

車両自身で自動運転可能な地点に到達→経路指示提供終了

8
遠隔監視
センタ
の指示
による
自動運転
終了

車両周辺映像図 9.2.1.6-3 ユースケース h-1b のメッセージ送受信シーケンス―246―ITS FORUM RC-017
9.2.1.7 メッセージサイズ
・車両～遠隔監視センタ間の疎通確認
表 9.2.1.7-1 遠隔監視疎通確認メッセージ（車両→遠隔監視センタ：Uplink）内容

情報要素
共通情報

個別情報

データサイズ

説明

メッセージ ID

8 bit

メッセージを特定する ID

車両 ID

32 bit時刻

32 bit

送信時刻

・車両が回避困難な交通環境に遭遇
表 9.2.1.7-2 遠隔操作要求メッセージ（車両→遠隔監視センタ：Uplink）内容

ケース h-1a、ケース h-1b 共通
情報要素

データサイズ

説明

メッセージ ID

8 bit

メッセージを特定する ID

車両 ID

32 bit遠隔操作

時刻

32 bit情報

発進・停止情報

1 bit(+7 bit)

車両位置（緯度経度高度）
速度88 bit8 bit

道路番号32 bit

走行レーン

8 bit

共通情報

運転速度

表 9.2.1.7-3 遠隔操作指示メッセージ（遠隔監視センタ→車両：Downlink）内容

ケース h-1b
情報要素

データサイズ

説明

メッセージ ID

8 bit

メッセージを特定する ID

車両 ID

32 bit遠隔操作

時刻

32 bit情報

発信・停止情報

1 bit(+7 bit)

車両位置（緯度経度高度）

88 bit

目的位置（緯度経度高度）

88 bit共通情報

経路情報

目的地までの経路

速度

8 bit

道路番号

32 bit

走行レーン

8 bit

―247―

遠隔操作中の運転速度

ITS FORUM RC-017
表 9.2.1.7-4 遠隔操作終了メッセージ（遠隔監視センタ→車両：Downlink）内容

ケース h-1.、ケース h-1b 共通
情報要素
共通情報

データサイズ

説明

メッセージ ID

8 bit

メッセージを特定する ID

車両 ID

32 bit

遠隔操作中に常時接続で配信される情報
ケース h-1a、ケース h-1b 共通 ：車両周辺映像情報（車両→遠隔監視センタ：Uplink）（現状未定より継続検討とする）
ケース h-1b：遠隔操縦データ（遠隔監視センタ→車両：Downlink）（現状未定より継続検討とする）

9.3 参考文献[1] SIP 協 調 型 自 動 運 転 ユ ー ス ケ ー ス -2019 年 度 協 調 型 自 動 運 転 方 式 検 討 TF 活 動 報 告https://www.sip-adus.go.jp/rd/rddata/usecase.pdf―248―

ITS FORUM RC-017

第 10 章

通信要件まとめ

各ユースケースの通信要件を以下の表にまとめる。

―249―

ITS FORUM RC-017
項目

説明

機能分類

機能分類名

ユースケース

ユースケース名称No.

ユースケース番号

メッセージ名メッセージ名がある場合は記載

通信形態

V2V、V2I、V2N の種別を記載

通信相手

RC-017 記載における特定車両もしくは不特定車両を記載。ITS FORUM RC-015 で規定する無線アクセスレイヤでのブロードキャスト、ユニキャ
ストとは必ずしも一致しない。

対象エリア(最小範囲)

V2V の場合は、通信距離と同じ。V2I の場合はインフラエリア、V2N の場合はセルラー提供範囲

エリアあたり送信台数

V2V および V2I では上記対象エリアあたりの送信台数。V2N ユニキャストの場合は、空白。

必要通信距離V2V、V2I における所要通信距離、あるいは V2V、V2I、V2N でメッセージ内の情報が有効な距離範囲

最大相対速度V2V では車車間の最大相対速度。V2I、V2N では車両最大速度

最大データサイズ

１メッセージ当たりの最大メッセージサイズ オーバヘッド 250byte を含む。

周期型もしくは非周期型

周期型もしくは非周期型の区別

送信周期

周期型の場合に、情報要素を更新して送信する周期

1 パケット当たり PAR

無線区間許容遅延内で実現すべき最大データサイズのパケットの到達率(Packet Arrival Rate)(パケット到達率)
無線区間許容遅延

ITS FORUM RC-015 で規定する無線アクセスレイヤが、所要信頼度を実現するためにシステムが許容する最大遅延時間（無線アクセスレイヤにおける送信待ち時間や連送/再送時間などを含む）。無線区間許容遅延を超えたメッセージは、復号結果にかかわらず未到達とする。

―250―

ITS FORUM RC-017
機能分類

a.合流・車線変更支援

ユースケース

予備加減速合流支援

本線隙間狙い合流支援

路側管制による本線車両協調合流支援

No.

a-1-1

a-1-2

a-1-3

位置情報

位置情報

位置情報

管制要求

通信形態

V2I（I → V）

V2I（I → V）

V2I（I → V）

通信相手

非特定車両

非特定車両

非特定車両

対象エリア(最小範囲)

合流起点 6 秒前から

合流起点 6 秒前から

合流起点 6 秒前から

合流起点まで合流起点まで

1台

1台

メッセージ名合流起点 6 秒前と合流
起点の中央まで
エリアあたり送信台数

必要通信距離 ※1
最大相対速度

1台
33.9～59.3m(国総研仕様書：95m)

67.8～118.6m

連絡路：20~70km/h

連絡路：20~70km/h

調定要求

調定応答

更新要求

更新応答

V2I（V → I）

V2I（I → V）

V2I（V → I）

路側インフラ

特定車両

特定車両

管制要求範囲内管制要求範囲内管制要求範囲内

1台

1 台（×管制数）

48 台 ※567.8～118.6m

連絡路：67.8～118.6m
本線：112.5～270.0m（管制数、混雑時）
連絡路：67.8～118.6m
本線：112.5～270.0m

連絡路：20~70km/h

連絡路：20~70km/h

連絡路：20~70km/h

連絡路：20~70km/h

本線：20～120 ㎞/h

本線：20～120 ㎞/h

本線：20～120 ㎞/h

本線：20～120 ㎞/h

連絡路：67.8～118.6m
本線：112.5～270m

1510 byte (1260+250)2752 byte (2502+250)

5236 byte (4986+250)

287 byte

369 byte

287 byte

想定台数：46 台

想定台数：92 台 ※2

想定台数：184 台 ※3

(37+250)(119+250) ※4(37+250)周期型もしくは非周期型

周期型

周期型

周期型

非周期型

非周期型

非周期型

送信周期

100ms

100ms

100ms

不定 ※6

1 パケット当たり PAR

PAR≧99％（仮）PAR≧99％（仮）PAR≧99％（仮）PAR≧99％（仮）PAR≧99％（仮）PAR≧99％（仮）無線区間許容遅延とし無線区間許容遅延とし無線区間許容遅延とし

規定しない

規定しない

規定しない

て 100ms を想定て 100ms を想定て 100ms を想定

最大データサイズ

無線区間許容遅延※1 路側インフラを合流起点に設置し、高低差を無視した値となる。合流起点からある程度離れた場所へ路側インフラのアンテナが設置されることも予想されるが考慮していない。
実際には、路側インフラアンテナ設置場所および高低差も含めた必要通信距離の計算を要する。
※2 本線：2 車線の情報提供を行った場合となる。本線：3 車線（想定台数：138 台）では 3744+250=3994 byte。本線：6 車線（想定台数：276 台）では 7470+250=7720 byte となる。

―251―

ITS FORUM RC-017※3 本線：3 車線、連絡路：1 車線の情報提供を行った場合となる。連絡路：2 車線と本線：6 車線（想定台数：368 台）では 9954+250=10204 byte となる。
※4 管制応答メッセージでは、行動開始予定時間の情報要素：2 byte を追加した 121＋250=371 byte となる。
※5 本線：3 車線、連絡路：1 車線で車両密度を 12 台/車線で試算した場合となる。本線：6 車線、連絡路：2 車線では、送信台数が 96 台となる。
※6 ユースケース a-1-3 の送信周期については 2.5.1.4 節や 2.5.1.6 節の説明を参照のこと。

―252―

ITS FORUM RC-017
機能分類

a.合流・車線変更支援

ユースケース

車同士のネゴシエーションによる合流支援

混雑時の車線変更の支援

渋滞時の非優先道路から優先道路への進入支援

No.

a-1-4

a-2

a-3

メッセージ名

調定要求

調定応答

調定要求

調定応答

調定要求

調定応答

更新要求

更新応答

更新要求

更新応答

更新要求

更新応答

通信形態

V2V

V2V

V2V

V2V

V2V

V2V

通信相手

非特定車両(調定要求)

特定車両

非特定車両(調定要求)

特定車両

非特定車両(調定要求)

特定車両

特定車両(更新要求)（要求車）

特定車両(更新要求)（要求車）

特定車両(更新要求)（要求車）

対象エリア(最小範囲)

調定要求範囲内調定要求範囲内

車線変更要求範囲内

車線変更要求範囲内

交差点要求範囲内

交差点要求範囲内

エリアあたり送信台数

一時停止時:1 台 ※7

一時停止時：27 台 ※7

合流開始時:1 台 ※7

合流開始時：36 台 ※7

73 台

48 台

2台

68 台

255m

255m

調定要求：255m

調定応答：255m

更新要求：38.9m

更新応答：38.9m

111.1m111.1m20～70 ㎞/h

20～70 ㎞/h

調定要求：0~120km/h

調定応答：0~120km/h

更新要求：0～20km/h

更新応答：0～20km/h

0～60km/h

0～60km/h

291 byte

287 byte

291 byte

287 byte

291 byte

287 byte(41+250)(37+250)(41+250)(37+250)(41+250) ※9(37+250)周期型もしくは非周期型

非周期型

非周期型

非周期型

非周期型

非周期型

非周期型

送信周期

不定 ※8

1 パケット当たり PAR

PAR≧99％（仮）PAR≧99％（仮）PAR≧99％（仮）PAR≧99％（仮）PAR≧99％（仮）PAR≧99％（仮）無線区間許容遅延

無線区間許容遅延とし無線区間許容遅延とし無線区間許容遅延とし無線区間許容遅延とし無線区間許容遅延とし無線区間許容遅延として 100ms を想定て 100ms を想定て 100ms を想定て 100ms を想定て 100ms を想定て 100ms を想定

必要通信距離最大相対速度

最大データサイズ

不定 ※8

不定 ※8

※7

一時停止のシナリオは合流車線長:190m@70km/h、合流開始時のシナリオは合流車線長：255m@100km/h を想定した台数となる。

※8

ユースケース a-1-4、a-2、a-3.の送信周期については、2.5.1.4 節や 2.5.2.5 節の説明を参照のこと。

※9

交差点情報がダイナミックマップより得られない場合、10 byte を追加する必要がある。

―253―

ITS FORUM RC-017
b.信号情報機能分類
ユースケース

信号情報による走行支援（V2I）

信号情報による走行支援（V2N）

No.

b-1-1

b-1-2

メッセージ名

-

-

通信形態

V2I

V2N

通信相手

非特定車両

左と同じ

対象エリア(最小範囲)

乗用車：約 138.5ｍ(仮)交差点あたりは右と同じ。サービスエリアはセルラーの提供範囲

大型車：約 206.3ｍ(仮)(黄色 4 秒。60km/h)
エリアあたり送信台数

路側機設置モデル

左と同じ(https://www.soumu.go.jp/main_content/000455914.pdf 4.2 章)参照
必要通信距離乗用車：約 138.5ｍ(仮)左と同じ

大型車：約 206.3ｍ(仮)(黄色 4 秒。60km/h)
なお、700MHz 帯システムの要求値は 240m
最大相対速度

70 km/h

左と同じ

最大データサイズ

1Kbyte/交差点程度

700MHz 帯システムでの値*3 程度

周期型もしくは非周期型

周期型

検討中

送信周期

100 ms

1 パケット当たり PAR

5m 評価区間で 99%以上※１(700MHz 帯システムと同様)

検討中

無線区間許容遅延

遅延は規定せず。ゆらぎは、±300ms 以

システム全体の遅延を通して検討が必要

内(https://www.sip-adus.go.jp/rd/rddata/rd03/205.pdf)※1: 70km/hは、秒速約20m。5m評価区間の走行には250ms要する。250ms内に、100ms周期の送信は、2回発生。
累積パケット到達率99%は、1-(0.1*0.1)=0.99から1パケットあたり90%以上のパケット到達を満たせばよい。
そのため、無線区間許容遅延100msで90%のパケット到達率―254―

ITS FORUM RC-017
機能分類

c. 先読み情報：衝突回避

ユースケース

前方での急交差点の情報による走行支援

交差点の情報による走行支援

ハザード情報による衝突回避

停止、急減速支援/前方での急停止、急減速

時の衝突回

時の衝突回避支援

避支援
No.

c-1

c-2-1

c-2-2

メッセージ名c-3 にマージ

-

検討対象と

c-3
-

-

しない
通信形態

c-3 にマージ

V2V

V2I (V=>I)

V2I (I => V)

V2V

通信相手

c-3 にマージ

非特定車両

検討対象と

非特定車両

非特定車両

しない
対象エリア(最小範囲)

c-3 にマージ(右折車両が配信情報を必要とする通信エリア)

検討対象と( 右折車両が配信

・車車間直接通信：事象発生地-上流側：右折車両のウィンカ ON 位置（停止線から 30m 上流地点）よしない

情報を必要とする点から上流 250m

り上流

通信エリア)

・リレーの場合：事象発生地点-下流側：右折先終点地点

c-2-1 と同じから上流 1km(右折車両が情報を必要とする対向車両の範囲)※対象車線は全直進車線-上流側：交差点中心又は右折待ちポイントを基点とし、交差点内の右折
待ちポイントで右折待ちしている状況において、交差点内の右折待ちポ
イントから安全な加速度で右折を開始し、対向車線を横断し終える詩集
える ことができる位置の対向車。尚、右折待ちポイントが交差点中心を超える場合は、右折待ちポイントを基点とし、その際、右折待ちポイ
ントが複数ある場合は、より対向車線に近いポイントとすること）。
-下流側：右折車から対向直進車両を見たときの見通し外（死角）となる位置。当該位置が対向直進車両が走行する車線の停止線より上流側にくる場合には、停止線位置とする―255―

ITS FORUM RC-017
エリアあたり送信台数

c-3 にマージ（片側車線数：6、対向車両速度：70km/h）348 台

検討対象と（片側車線数：3、対向車両速度：70km/h）125 台

しない

N/A

(車両速度:120km/h、車間距離:2s) 79 台(車両速度:60km/h、車間距離:
1s) 277 台（緊急行動実施地点から 1km
区間における 6 車線の総台数

必要通信距離c-3 にマージ（片側車線数：6、対向車両速度：70km/h）190m

検討対象と路側インフラのア

・車車間直接通信：事象発生地（片側車線数：3、対向車両速度：70km/h）135m

しない

ンテナ位置に依存

点から上流 250mする。路側インフ・リレーの場合：事象発生地点

ラのアンテナを交から上流 1km

差点脇に設置、アンテナ高を 6m とすると以下：（片側車線数：6）75.2m（片側車線数：3）52.4m
最大相対速度c-3 にマージ~70km/h

検討対象と~70km/h~120km/h

しない
最大データサイズ

c-3 にマージ

282 byte

検討対象と（片側車線数：6） 312 byte

しない

1534 byte（片側車線数：3）
1150 byte (※1)

周期型もしくは非周期型

c-3 にマージ

周期型

検討対象と
しない

―256―

周期型

周期型

ITS FORUM RC-017
送信周期

c-3 にマージ

100ms

100ms

100ms

検討対象と

PAR≧99％ (暫定

車車間の直接通信におけるしない的な値。必要に応PAR≧99％ (暫定的な値。必要

じて値は精査)に応じて値は精査)

検討対象と
しない

1 パケット当たり PAR

無線区間許容遅延

c-3 にマージ

c-3 にマージPAR≧99％ (暫定的な値。必要に応じて値は精査)

無線区間許容遅延として[100]ms を想定する

検討対象と無線区間許容遅延・緊急回避行動発生場所から上(暫定的な値。必要に応じて値は精査)しないとして[100]ms を流 255m まで：[100]ms 以内想定する

・上記より上流地点：上流 1km(暫定的な値。必要までは距離に応じて 30s までに応じて値は精緩和

査)(暫定的な値。必要に応じて値は精査)※1: 信号情報、交差点識別情報、車両検知情報をまとめて一つのメッセージで送信する場合のメッセージサイズ。各情報を個別のメッセージで送信する場合には、セキュリティオーバヘッド
は各情報に対して加味される。

―257―

ITS FORUM RC-017
機能分類

d. 先読み情報：走行計画変更

ユースケース

異常車両の通知による走行支援

逆走車の通知による走行支援

渋滞の情報による走行支援

No.

d-1

d-2

d-3

メッセージ名

-

-

-

-

-

-

通信形態

V2I

V2N

V2I

V2N

V2I

V2N

通信相手

ハザード情報が有効にハザード情報が有効にハザード情報が有効にハザード情報が有効にハザード情報が有効にハザード情報が有効に活用できるエリアに存活用できるエリアに存活用できるエリアに存活用できるエリアに存活用できるエリアに存活用できるエリアに存在する非特定の車両

在する非特定の車両

在する非特定の車両

在する非特定の車両

在する非特定の車両

在する非特定の車両

最小 66.6m~

事象発生時点から 1km

最小 66.6m~

事象発生時点から 2km

最小 66.6m~

事象発生時点から 1km

対象エリア(最小範囲)まで(仮）エリアあたり送信台数

まで(仮）

まで(仮）

Uplink：異常車両台数

Uplink：異常車両台数

Uplink：異常車両台数

Uplink：異常車両台数

Uplink：異常車両台数

Uplink：異常車両台数（通常１台）（通常１台）（通常１台）（通常１台）（通常１台）（通常１台）

Downlink: ブ ロ ー ド

Downlink：285（ユニDownlink: ブ ロ ー ド

Downlink：567（ユニDownlink: ブ ロ ー ド

Downlink：285（ユニキャスト

キャスト想定）キャスト

キャスト想定）キャスト

キャスト想定）必要通信距離事象発生時点から上流

事象発生時点から上流
最小 66.6m~

255m から 1km まで

最小 66.6m~

510m から 2km まで

事象発生時点から上流
最小 66.6m~

255m から 1km まで

(仮）

(仮）

(仮）

ｻｰﾋﾞｽ提供範囲としてｻｰﾋﾞｽ提供範囲としてｻｰﾋﾞｽ提供範囲として

最大相対速度

20km/h~120km/h

20km/h~120km/h

20km/h~120km/h

20km/h~120km/h

20km/h~120km/h

20km/h~120km/h

最大データサイズ

715Byte

715Byte

715Byte

715Byte

715Byte

715Byte（465+250）（465+250）（465+250）（465+250）（465+250）（465+250）

周期型もしくは非周期型

周期型

周期型

周期型

周期型

周期型

周期型

送信周期

最小 1 秒

最小 7.65 秒

最小 1 秒

最小 7.65 秒

最小 1 秒

最小 7.65 秒

1 パケット当たり PAR

PAR≧99％（仮）PAR≧99％（仮）PAR≧99％（仮）PAR≧99％（仮）PAR≧99％（仮）PAR≧99％（仮）無線区間許容遅延

規定しない

規定しない

規定しない

規定しない

規定しない

規定しない

―258―

ITS FORUM RC-017

機能分類

d. 先読み情報：走行計画変更

ユースケース

分岐・出口渋滞支援

ハザード情報による走行支援

No.

d-4

d-5

メッセージ名

-

-

-

-

通信形態

V2I

V2N

V2I

V2N

通信相手

ハザード情報が有効に活用でハザード情報が有効に活用できるエ

ハザード情報が有効に活用できる

ハザード情報が有効に活用できるエリアに存在する非特定の車両

エリアに存在する非特定の車両

リアに存在する非特定の車両

きるエリアに存在する非特定の車両
対象エリア(最小範囲)

最小 66.6m~

事象発生時点から 1km まで(仮）および、上流の 1 つ前の分岐・出口か最小 66.6m~

事象発生時点から 1km まで(仮）ら 1km 上流
エリアあたり送信台数

Uplink：異常車両台数（通常１台）
Downlink: ブロードキャスト

必要通信距離最小 66.6m~

Uplink：異常車両台数（通常１台）
Downlink：570（ユニキャスト想定）
事象発生時点から上流 255m から
1km まで(仮）Downlink: ブロードキャスト

最小 66.6m~

Downlink：285（ユニキャスト想定）
事象発生時点から上流 255m から
1km まで(仮）ｻｰﾋﾞｽ提供範囲としてｻｰﾋﾞｽ提供範囲として
最大相対速度

20km/h~120km/h

20km/h~120km/h

20km/h~120km/h

20km/h~120km/h

最大データサイズ

715Byte

715Byte

715Byte

715Byte（465+250）（465+250）（465+250）（465+250）

周期型もしくは非周期型

周期的

周期的

周期的

周期的

送信周期

最小 1 秒

最小 7.65 秒

最小 1 秒

最小 7.65 秒

1 パケット当たり PAR

PAR≧99％（仮）PAR≧99％（仮）PAR≧99％（仮）PAR≧99％（仮）無線区間許容遅延

規定しない

規定しない

規定しない

規定しない

―259―

ITS FORUM RC-017
機能分類

e.先読み情報：緊急車両回避

ユースケース

緊急車両の情報による走行支援

No.

e-1

メッセージ名

-

-

通信形態

V2V

V2N

通信相手

緊急車両情報が有効に活用できるエ

緊急車両情報が有効に活用できるエリアに存在する非特定の車両

リアに存在する非特定の車両

対象エリア(最小範囲)

150m の半円

一般道：半径 700m の半円
高速道路：半径 1000m の半円
Uplink:緊急車両台数（通常１台）

エリアあたり送信台数
Downlink：ブロードキャスト

Downlink：285（仮、ユニキャスト想定）

必要通信距離最小 150m

一般道：半径 700m の半円
高速道路：半径 1000m の半円

最大相対速度

20km/h~120km/h

20km/h~120km/h

最大データサイズ

302Byte(52+250)

1035Byte（785+250）

周期型もしくは非周期型

周期的

周期的

送信周期

100 ミリ秒

最小 7.65 秒

1 パケット当たり PAR

PAR≧99％（仮）PAR≧99％（仮）無線区間許容遅延

V2V：100 ミリ秒以下

規定しない

―260―

ITS FORUM RC-017
機能分類

f.インフラによる情報収集・配信

ユースケース

救援要請(e-Call)

交通流の最適化のための情報収集）

地図更新・自動生成

ダイナミックマップ情報配信

No.

f-1

f-2

f-3

f-4

メッセージ名

-

-

-

-

通信形態

V2N

V2I／V2N

V2N

V2N

通信相手

非特定車両

非特定車両

非特定車両

非特定車両

対象エリア(最小範囲)

通信事業者における公衆網の通信エ

V2I：半径 171.8m の円※1

通信事業者における公衆網の通信エ

通信事業者における公衆網の通信エリア

V2N：通信事業者における公衆網の

リア

リア

規定しない

規定しない

-

-

通信エリア
エリアあたり送信台数

規定しない

V2I：389 台(最大ケース)※1

V2N：規定しない
必要通信距離V2I：最小 33.3m-＊時速 120km で走行時の 1 秒間での移動距離
最大相対速度

20km/h~120km/h

20km/h~120km/h

20km/h~120km/h

20km/h~120km/h

最大データサイズ

Uplink：675Byte (425+250)

Uplink：279Byte(29+250)

Uplink：20.5MByte(画像データ(最Uplink：規定しない※2

Downlink：規定しない

Downlink：規定しない

大 5 枚)含)Downlink：67 Mbps

Downlink：規定しない（最大ケース）＊通信中は上記以外に Uplink /Downlink 共に音声を常時通信
周期型もしくは非周期型

非周期型

周期型

非周期型

非周期型

送信周期

-

V2I：最小 1 秒--

V2N：最小１分※3
1 パケット当たり PAR-

V2I：PAR≧99％（仮）

-

-

規定しない

規定しない

規定しない

規定しない

※4
無線区間許容遅延―261―

ITS FORUM RC-017※1: 通信エリア:171.8m（360 度）、片方向最大 3 車線、2 差路交差点、車両速度 20km/h、車両間隔 1s、平均車長 5m を想定
エリアあたり送信台数：171.8×3×2×4÷(5.6×1+5)＝389 台)※2:アプリケーションレイヤにおけるデータサイズを示す※3:アプリケーションレイヤにおける送信周期を示す※4: 無線レイヤにおける PAR を示す―262―

ITS FORUM RC-017
機能分類

g.隊列・追従走行

ユースケース

電子牽引による後続車無人隊列走行

電子牽引による後続車無人隊列走行(非リッチコンテンツ)(リッチコンテンツ)

No.

g-1

g-1

g-2

メッセージ名

-

-

-

通信形態

V2V

V2V

V2V

通信相手

特定車両(1 対 N を用いて 1 対 1 を実現)

特定車両(1 対 N を用いて 1 対 1 を実現)

非特定車両

対象エリア(最小範囲)

相対距離 60m 程度

相対距離 60m 程度

141m

エリアあたり送信台数

3台

3台

4 台での計算

必要通信距離相対距離 60m 程度

相対距離 60m 程度

141m

最大相対速度

大型 80km/h

大型 80km/h

乗用車 100km/h 大型 80km/h

最大データサイズ

700MHz 帯システムと同様まで※1

700MHz 帯システムと同様まで周期型もしくは非周期型

周期型

※1

周期型

送信周期

100ms、緊急時 20ms

※1

100ms

1 パケット当たり PAR

通常時 100ms あたり 98%、緊急時 100ms あた※1

10m 走行でのパケット累積率 95%(700MHz 帯システム

り 99.99%以上
無線区間許容遅延

100ms(車間距離 10m 速度 80km/h)

追従走行並びに追従走行を利用した後続車有人隊列走行と同様)以上100ms 以下

※1

※1:フルハイビジョンのリアルタイム通信を必要とし、カメラ～ディスプレイ 区間での遅延や通信品質としては、国連欧州委員会Regulation 46電子ミラー規定が参考になりうるが、どの画像符号化方式を用いるかに応じて、画像の符号化・復号化の遅延が異なり、その結果、無線区間に要求される伝送帯域幅と通信遅延が異なる。カメラやディスプレイでの遅延も実装を考慮して無線区間の通信遅延を規定する必要がある。これらから、具体的な内容やサイズについては、本資料では規定できていない。

―263―

ITS FORUM RC-017
機能分類

h.遠隔操作

ユースケース

移動サービスカーの操作・管理（ODD の条件外における遠隔操縦の指示)

移動サービスカーの操作・管理（ODD の条件下における走行経路の指示）

No.

h-1a

h-1b

-

-

通信形態

V2N

V2N

通信相手

非特定車両

非特定車両

対象エリア(最小範囲)

通信事業者における公衆網の通信エリア

通信事業者における公衆網の通信エリア

エリアあたり送信台数

規定しない

規定しない

-

-

T.B.D.

T.B.D.

※1

Uplink：車両周辺映像情報、遠隔操作要求
Downlink：遠隔操縦データ（遠隔操縦実施
時）

Uplink：車両周辺映像情報、経路指示要求
Downlink：走行経路（走行経路指示実施時）

周期型もしくは非周期型

非周期型

非周期型

-

-

T.B.D.

T.B.D.

T.B.D.

T.B.D.

メッセージ名

必要通信距離最大相対速度
最大データサイズ

送信周期※2
1 パケット当たり PAR※3
無線区間許容遅延※1: アプリケーションレイヤにおけるデータサイズを示す※2: アプリケーションレイヤにおける送信周期を示す※3: 無線レイヤにおける PAR を示す―264―

ITS FORUM RC-017

付録 1
1

メッセージ構成の検討

概要
SIP 協調型自動運転ユースケースに関して検討された通信内容を基に、V2V や V2I において車両や路側インフラが送受信するメッセージ構成の検討を行った。複数のユースケースが同時に提供されうることを考慮し、それぞれのユースケースで使用されるメッセージの中で共通化可能と考えられる情報要素を抽出し、グルーピングを行った。さらなる検討が必要な項目は付録 2 参照。
2

前提条件
本検討における前提条件を以下に記す。
・特定の無線方式を想定しない。
・無線方式において、メッセージサイズの制限があることを考慮する。
・他サービス/ユースケースへ影響しない範囲で、情報要素の追加・修正ができる構成とする。
・各ユースケースの実用化の時期が異なってもシステムが動作可能とする-

車両間でサポートするユースケースに違いがあったとしても全ての車両間で通信可能とするための、最低限の情報要素を基本情報として抽出する。

-

車両間および、車両-路側インフラ間で対応するユースケースが異なる場合、受信側は対応していないユースケースのメッセージを受信しても廃棄する。

・将来的なユースケースなどに向けた拡張性を考慮する。

3

メッセージ構造
図 3-1、図 3-2 に本検討におけるメッセージ分類のフレームワーク及び、メッセージの構成例を示す。メッセージは、①メッセージ情報、②路側インフラ基本情報、③車両基本情報、④ユースケー
ス固有情報から構成される。①メッセージ情報、②路側インフラ基本情報、③車両基本情報はユー
スケースや場所・時間・走行状態などのイベントに依存せずに送信され、④ユースケース固有情報
は、ユースケースに応じて送信される。また、④ユースケース固有情報については、路側管制情報、
周辺車両情報、調停情報、交差点情報、ハザード情報、後続車無人隊列走行情報、後続車有人隊列
走行情報について検討を行った。

―265―

ITS FORUM RC-017

ユースケースに依存しない情報（場所・時間・走行状態などに紐付くイベントなどに依存せずに送信されうる情報要素など。）

メッセージ内容に依存せず含まれる情報要素
路側インフラ/車両が送信する情報要素①メッセージ情報③車両基本情報②路側インフラ基本情報

メッセージ内容

大まかな意図・目的を基に分類
路側管制情報周辺車両情報調停情報④ユースケース固有情報

交差点情報
ハザード情報後続車無人隊列走行情報
後続車有人隊列走行情報

図 3-1 情報要素分類のフレームワーク①メッセージ情報①メッセージ情報②路側インフラ基本情報③車両基本情報④ユースケース固有情報④ユースケース固有情報

路側管制情報調停情報

周辺車両情報ハザード情報調停情報

後続車無人隊列走行情報

交差点情報

後続車有人隊列走行情報

ハザード情報図 3-2 メッセージ構成例（左：路側インフラのメッセージ、右：車両のメッセージ）―266―

ITS FORUM RC-017

NOTE: 路側インフラ基本情報については、今回検討対象としたユースケースにおいては、該当する
情報は見出されなかったが、便宜上図 2.1-1 に含めた。
NOTE: 適用される無線方式の制約や機能（例えば、サポートする最大メッセージサイズやメッセー
ジ毎に異なる無線特性を適用可能であるかなど）によって、車両基本情報/路側インフラ基本情報やユースケース固有情報とを 1 つにまとめて送信するだけでなく、それぞれを独立して送信したり、異なる送信周期で送信したりすることも考えられる。
3.1 メッセージ情報
メッセージ内容に依存せず含まれる情報要素。
3.1.1

利用ユースケース

全てのユースケース
3.1.2

情報要素詳細データ長・メッセー
ジサイズ

b-1-1、c-2-2
データ長

NOTE: メッセージ全体のデータ長情報は、無線アクセスレイヤなどの他のレイヤで提供されれば、メッセージ情報には不要。ユースケース固有にデータサイズが必要な場合には、ユースケース固有情報へ含めることを想定する。
共通バージョン

b-1-1、c-2-2
メッセージ情報要素が準ずる規格の識別情報

NOTE: [1]における DE_共通サービス規格や、DSSS 仕様における DE_
メッセージ種別コードに相当する情報要素。

―267―

ITS FORUM RC-017
メッセージ ID

全てのユースケース
メッセージ毎の ID を提供する。以下を区別する。
・位置情報メッセージ
・管制要求メッセージ
・管制応答メッセージ・調定要求メッセージ・調定応答メッセージ
・更新要求メッセージ・更新応答メッセージ・ユースケース c-3 でのメッセージ・ユースケース c-2-1 でのメッセージ・ユースケース c-2-2 でのメッセージ・信号情報のメッセージ
・後続車無人隊列走行非リッチコンテンツメッセージ
・後続車無人隊列走行リッチコンテンツメッセージ
・後続車有人隊列走行メッセージ・ユースケース d-x での車路間通信メッセージ、路車間通信メッセージ・ユースケース e-1 での車路間通信メッセージ、路車間通信メッセージ、
車車間通信メッセージ・ユースケース f-x でのメッセージ・ユースケース h-1 でのメッセージ

NOTE: 上記のメッセージ種別は現状の検討内容をベースにしており、今後、情報要素をグルーピングする場合や、異なる複数のメッセージへ分離する場合には、適宜追加・削除を行う。
NOTE: ユースケースの内、類似の車両情報を通知するメッセージ（c1&3、c-2-1、d-x の車路間/路車間/車車間通信メッセージ）について、メッセージ ID の付与の仕方は要検討。
NOTE:路側機か車載器かのを区別を、メッセージ ID で行うのか、送信元
ID(路側機 ID と車載器 ID)で行うのか、固有の送信元種別フィールドを世定義するのか要検討
メッセージバージョン

b-1-1、c-2-2

NOTE: [1]における DE_バージョン情報や DSSS 仕様における DE_メッ
セージバージョンに相当する情報要素。

―268―

ITS FORUM RC-017

インクリメント ID

a-1-x、b-1-1、c-2-2
受信側でメッセージ取得済み可否を判定するため、インクリメント ID
インクリメント ID はメッセージ毎にインクリメントする番号を付与して提供する（インクリメント番号が最大値に達した後は 0 に戻り、連送や再送の場合は同一のインクリメント値で行う）

NOTE: 暫定的にメッセージ情報に含めている。インクリメント ID をメッセージ情報に含めるか、ユースケース個別情報に含めるかは継続検討
NOTE: ユースケース a-1-x においては“インクリメント ID または情報更新時刻”となっているが、情報更新時刻をどの情報に含めるか（基本情報
やユースケース固有情報）は継続検討。
路側機 ID

a-1-x、b-1-1、c-2-2

ダイナミックマップと整合したメッセージの送信元ノードの識別子

NOTE: 暫定的に路側機 ID と車載器 ID を別としている。路側機 ID と車載器 ID を別の ID として定義する（i.e., 後続の情報要素が車両情報か路
側インフラ情報か識別する）か、両方をカバーする“送信元 ID”として定義するか（i.e., 車両メッセージと路側インフラメッセージはメッセージ
構成が異なると想定）は継続議論。
NOTE: b-1-1. c-2-2 における共通ヘッダの DF_無線機管理番号に含まれる“DE_都道府県コード”、“DE_無線機 ID”との関係について、継続議論。
車載器 ID(自車）a-1-3、a-1-4、a-2、a-3、c-1、c-2-1、c-3、d-x、e-1、f-2
車両の識別子であり、メッセージの送信元ノードの識別子）
車載器の電源 ON の度にランダムな値がセットされる。

NOTE: [1]の“DE_車両 ID”との関係について、継続議論（e.g., 併存がありうるのか、その際は同一の ID をわりふるのか）
NOTE: 車載器 ID は、ユースケース毎に異なる値を用いる必要があるかについて、継続議論。

―269―

ITS FORUM RC-017

NOTE: 以下の情報要素は、現状のユースケース検討では必要性が把握されていないが、将来の拡張性を考慮して含めるか、どの情報に含めるか継続議論。
送信タイプ識別ブロードキャスト、マルチキャスト、ユニキャストの識別
現時点の仕様では、常にブロードキャストを指示することを想定
a-1-3、a-1-4、a-2、a-3 における要求メッセージ、調定要求メッセージ、
調定応答メッセージ、更新要求メッセージおよび更新応答メッセージは、情報としてはユニキャストであるが、対象外の車両が受信することも排除していないので、ブロードキャストを用いている想定。
ユニキャストでの宛先およびグループキャストでのグループ ID

宛先

ブロードキャストでは、送信しないもしくは、all 0 などの固定値を想定

NOTE: 以下の情報要素は、現状のユースケース検討では必要性が把握されていないが、[1]の DF_
共通領域管理情報に含まれる情報。必要性について継続議論。
DE_オプションフラグ

格納するオプション情報を示すフラグ情報。格納するオプション情報に該当するオプションフラグのビットに 1 をセットする。

NOTE: エンコーディング方法として ASN.1 を用いるのであれば ASN.1
内で記載可能。
3.2 路側インフラ基本情報
路側インフラから送信される情報要素の内、基本的にはユースケースやイベントなどに依存せずに送信される情報要素。
3.2.1

利用ユースケース

現状利用無し3.2.2

情報要素詳細現状利用無し3.3 車両基本情報
車両から送信される情報要素の内、基本的にはユースケースや、自車両の位置・速度・長さ・属性情報など場所・時間・走行状態などのイベントなどに依存せずに送信される情報要素。

NOTE: 本情報を、ユースケースに関わらず定常的に周期送信するかは継続議論。メッセージ
ID やインクリメント ID がユースケース依存の場合は、それらをどのように扱うかも継続議論―270―

ITS FORUM RC-017

3.3.1

利用ユースケース

車両通信のあるすべてのユースケース。
3.3.2

情報要素詳細NOTE: 情報の性質に基づいた大まかなグループ単位で表を分けているが、どのようにグルーピングするかは継続議論。
・情報の時刻に関する情報
時刻情報

c-1、c-2-1、c-3、g-1、f-2
車両情報の送信時刻情報

NOTE: [1]における DF_時刻情報（32bit）との関係を継続議論。

―271―

ITS FORUM RC-017
・車両の位置に関する情報
道路番号a-1-3、a-1-4、a-2、a-3
ダイナミックマップと整合した車両が認識している道路番号

NOTE: 車両位置情報（緯度緯度経度）に加えて、本情報についても車両基本情報として送信するか CRP 議論なども鑑みながら継続議論。
走行車線

a-1-3、a-1-4、a-2、a-3、f-2
ダイナミックマップと整合した車両が認識している走行車線番号

NOTE: 車両位置情報（緯度緯度経度）に加えて、本情報についても車両基本情報として送信するか CRP 議論なども鑑みながら継続議論。
車両位置（緯度経度高度）a-1-3、a-1-4、a-2、a-3、c-1、c-2-1、c-3、g-x
ダイナミックマップと整合した車両が認識している車両が認識している
メッセージ決定時の車両（車頭？）位置情報

NOTE: CRP との相対位置参照時に、追加で”CRP の識別子”および”CRPとの相対位置”を通知するのか、緯度経度高度を置き換えるのか決定が必要。相対位置の精度は、高速合流支援では 1m 精度．一般道交差点で25cm 程度[CRP のあり方に関する調査検討より]
NOTE: [1]における DF_位置情報（88bit）との関係を継続議論。

―272―

ITS FORUM RC-017

・車両の状態に関する情報
車両速度a-1-3、a-1-4、a-2、a-3、c-1、c-2-1、c-3、f-2、g-x.

（目標速度）

車両が認識している自車速度

NOTE: [1]における DE_車速（16bit）との関係を継続議論。

車両方位角c-2-1、f-2、g-x
自車両の方位角NOTE: [1]における DE_車両方位角（16bit）との関係を継続議論。

車両加減速情報c-1、c-2-1、c-3、f-2、g-x
自車両加減速情報

NOTE: [1]における DE_前後加速度（16bit）との関係を継続議論。

―273―

ITS FORUM RC-017

NOTE: 以下の情報要素は、現状のユースケース検討では必要性が把握されていないが、[1]の DF_
車両状態情報に含まれる情報。必要性と、どの情報に含めるかについて継続議論。
車速取得情報[1]での DF_車両状態情報に含まれる
車速の信頼度を示す情報

車両方位角取得情報[1]での DF_車両状態情報に含まれる
車両方位角の信頼度を示す情報

車両加減速取得情報[1]での DF_車両状態情報に含まれる DF_前後加速度と同等のものを想定。
車両加減速情報の信頼度を示す情報

シフトポジション[1]での DF_車両状態情報に含まれる車両のシフトポジション情報。マニュアル変速、無段階変速の車両の場
合、前進のポジションになっている場合はドライブをセットする。

ステアリング角度[1]での DF_車両状態情報に含まれる
ステアリングの操舵角度情報。プラスを時計回りとする。

（参考）[1]の DF_車両状態情報―274―

ITS FORUM RC-017

・車両の属性に関する情報
車両長さ

a-1-3、a-1-4、a-2、a-3、c-1、c-2-1、c-3、g-1
車両長さ

NOTE: [1]における DE_車長（14bit）との関係を継続議論。

車両属性情報c-2-1
車両用途

NOTE: [1]における DE_車両用途種別（4bit）との関係を継続議論。

―275―

ITS FORUM RC-017

NOTE: 以下の情報要素は、現状のユースケース検討では必要性が把握されていないが、[1]の DF_
車両属性情報に含まれる情報。必要性と、どの情報に含めるかについて継続議論。
車両サイズ種別[1]の DF_ 車両属性情報に含まれる。
車両のサイズ種別情報

車幅[1]の DF_ 車両属性情報に含まれる。
車両の全幅情報―276―

ITS FORUM RC-017（参考）[1]の DF_車両属性情報

・車両のその他の情報
車両情報

f-2
ユースケース f-2 交通流の最適化のための情報収集において、V2I/定期/
イベント配信：V2I/定期/イベントを識別

NOTE: 暫定的に車両基本情報へ含めているが、他の情報（e.g., ユース
ケース固有情報）に含めるか、別の情報（e.g., メッセージ ID）で識別
するかについて継続議論。

[1]の共通領域相当

g-2
ブレーキ等の基本的な情報

NOTE: g-2 において“[1]の共通領域相当”の情報要素を送信することが想定されている。追加で必要な情報要素の有無や、どの情報に含めるかについて継続議論。
（参考）[1]における共通領域―277―

ITS FORUM RC-017
3.4 ユースケース固有情報
車両及び、路側インフラから送信される情報要素の内、ユースケースや、自車両の位置・速度・
長さ・属性情報など場所・時間・走行状態などのイベントなどに依存して送信されうる情報要素。
3.4.1

路側管制情報路側インフラが路側管制受付状況を通知する情報要素。
3.4.1.1 利用ユースケース
a-1-3
3.4.1.2 情報要素詳細
路側管制情報a-1-3
管制要求メッセージを受け付けしているかどうかを示す。a-1-1、a-1-2においては“受付無し”として通知される。

NOTE: サービスアドバタイズ情報（どのユースケースやサービスを運営しているか）に相当する情報要素。現状のユースケースでは上記の情報要素しか把握されていないため、他の情報に含める案（e.g., 路側インフラ基本情報）や他の情報要素で識別する案（e.g., メッセージ ID）なども含めて
継続議論。
3.4.2

周辺車両情報路側インフラが検知した車両の情報を通知するための情報要素。
3.4.2.1 利用ユースケース
a-1-1、a-1-2、a-1-3、c-2-2
3.4.2.2 情報要素詳細

NOTE: 個々の車両情報に含まれる情報要素は、基本車両情報と類似のものが多い。車両基本情報と情報要素やグルーピングをそろえるかは継続議論。
NOTE: a-1-x と c-2-2 間において、差分のある情報の扱いについては継続議論。

―278―

ITS FORUM RC-017

・a-1-x において路側インフラが送信する情報要素
合流起点情報
道路番号
走行車両数
車両 ID

a-1-1、a-1-2、a-1-3
ダイナミックマップと整合した情報
a-1-1、a-1-2、a-1-3
ダイナミックマップと整合した情報
a-1-1、a-1-2、a-1-3
位置情報・管制情報で提供する車両数を提供する
a-1-1、a-1-2、a-1-3
路側インフラで付与した ID を提供する。異なったタイミングや異なったメッセージ種別で送信するメッセージ間において、路側インフラが同一車両と認識している場合は同一の車両 ID を付与する

NOTE:“車両 ID”は[1]で別の意味で用いられている。”割り当て車両 ID”などへ改名するか継続議論。
車両位置（緯度経度高度）

走行車線
走行速度

車両長さ
合流起点到達予定時
刻

センサ情報取得時刻

情報信頼度

a-1-1、a-1-2、a-1-3
路側センサにて計測または各車両から得た最新の位置情報を提供する
連絡路上の協調走行車は、車両位置と車両長さ情報の組み合わせから、合流場所の特定に利用する
CRP との相対位置参照時に、追加で”CRP の識別子”および”CRP との相対位置”を通知するのか、緯度経度高度を置き換えるのか決定が必要。相対位置の精度は、高速合流支援では 1m 精度．一般道交差点で 25cm 程度[CRP のあり方に関する調査検討より]
a-1-1、a-1-2、a-1-3
路側インフラが認識している走行車線を提供する。
a-1-1、a-1-2、a-1-3
スポットセンサの場合は検知時の速度を、面的センサの場合は更新前後の時間と位置から計算される速度を提供する
連絡路上の協調走行車は予備加減速と合流起点以降の加速を調整する
a-1-1、a-1-2、a-1-3
センサにて計測または各車両から得た車両長さを提供する
a-1-1、a-1-2、a-1-3
推定した到達予定時刻を絶対時刻で提供する連絡路上の協調走行車は、合流起点の通過予定時刻を調整する
路側インフラは、加減速情報やその他の情報も考慮して計算するため、同一メッセージ内の車両位置と走行速度のみからの計算した到着予定時
刻とは異なることがある。
a-1-1、a-1-2、a-1-3
走行車両ごとに取得した時刻または予測した時刻情報を提供する（1.1.3
項の T1 に相当）
a-1-1、a-1-2、a-1-3
設置されるセンサの種類によって、取得周期や得られる位置精度が異なる場合を考慮した情報や予測情報の区別を提供する―279―

ITS FORUM RC-017
・c-2-2 において路側インフラが送信する情報要素
DF_提供点管理番号

DE_センサ ID
DE_システム状態
DE_センサバージョ

c-2-2
DE_都道府県コード
DE_提供点種別コード
DE_交差点 ID/単路 ID
c-2-2
路側センサの識別子
c-2-2
c-2-2

ン
DE_位置種別
DE_システム設計遅
延時間
DE_再送遅延時間

c-2-2
c-2-2
c-2-2

情報

c-2-2
DE_方路 ID
DE_基点ノード ID
DE_基点から近端までの道程距離
DE_基点から遠端までの道程距離

DE_車道検知エリア

c-2-2

DF_車道検知エリア

単位数(I)
DF_車道検知エリア
単位

c-2-2
DE_検知対象車線
DE_四輪車存在有無
DE_二輪車存在有無
DE_四輪検知数上限フラグ
DE_四輪情報格納数(J)
DE_速度
DE_基点からの道程距離
DE_拡張領域サイズ
DE_二輪検知上限フラグ
DE_二輪情報格納数(K)
DE_速度
DE_基点からの道程距離
DE_拡張領域サイズ―280―

ITS FORUM RC-017

3.4.3

調定情報

路側インフラや車両が調停情報を通知するための情報要素。
3.4.3.1 利用ユースケース
a-1-3、a-1-4、a-2、a-3
3.4.3.2 情報要素詳細
合意応答

a-1-3、a-1-4、a-2、a-3
管制（合意）に応じる/応じない の応答や、応答に関する情報（例えば、自動運転レベルや自動走行状態）および合意終了を路側インフラ（要求車）へ応答することを想定

NOTE: 応じる・応じないなどで別のメッセージ ID が割り当てられる場合
は、合意応答としては不要になる。要検討

車両速度a-1-3、a-1-4、a-2、a-3（目標速度）

・管制要求メッセージ、調定応答メッセージ、更新応答メッセージでは車両

車載器 ID（通信対象）

情報更新時刻返信要求範囲合流先（目標）車線が認識している自車速度を提供する・調定要求メッセージは、路側インフラの場合は、要求車の速度を提供し、車両の場合は、車両が認識している自車速度を提供する
・更新要求メッセージは、路側インフラが送信する場合は、対象車の目標とする車両速度を提供し、車両が送信する場合は、車両が認識している自車速度を提供するa-1-3、a-1-4、a-2、a-3
管制要求メッセージ：路側インフラ ID
管制応答メッセージ：管制要求車の車載器 ID
調定要求メッセージ：不特定値。
a-1-3 の応答案 C では管制要求車の車載器 ID
調定応答メッセージ：対応する調定要求メッセージの路側機 ID または
車載器 ID（自車）更新要求メッセージ：要求対象の車載器 ID
更新応答メッセージ：対応する調定要求メッセージの路側機 ID または
車載器 ID（自車）a-1-3、a-1-4、a-2、a-3
送信するメッセージをアプリケーションレイヤで決定した時の時刻情報（メッセージ決定時）を想定
a-1-3、a-1-4、a-2、a-3
調定要求メッセージ、更新要求メッセージで、応答車が応答要否を判断するための範囲を提供することを想定。当該範囲は 88bit（基点の絶対位置）＋
16bit（基点から上流の距離）＋8bit（車線）a-1-3、a-1-4、a-2、a-3
調定要求メッセージ、更新要求メッセージで、路側インフラまたは要求車
が、要求をうける車両が合流起点で走行すべき車線を提供することで、受入車での車間距離制御や合意可否の判断に役立てることを想定―281―

ITS FORUM RC-017

先行車との（目標）
車間距離

行動開始予定時間

3.4.4

a-1-3、a-1-4、a-2、a-3
調定要求メッセージ、更新要求メッセージで、路側インフラまたは要求車が、合流起点で必要とする車間距離を提供することで、受入車での車間距離制御や合意可否の判断に役立てることを想定
管制要求メッセージ、調定応答メッセージ、更新応答メッセージでは、メッ
セージ決定時の先行車との車間距離を提供することを想定
a-1-3、a-1-4、a-2、a-3
更新要求メッセージとして、ユースケース a-1-4 は合流開始までの予定時
間、ユースケース a-2 は車線変更開始までの予定時間を提供することで応答
車へ性急度を提供することを想定（ユースケース a-1-3 では管制応答が必要な場合に合流起点までの予定時間を提供）※ 必要性について継続議論

交差点情報

路側インフラが交差点情報を通知するための情報。
3.4.4.1 利用ユースケース
b-1、c-2-2
3.4.4.2 情報要素詳細
DE_運用区分コード
DF_送信時刻

DF_提供点管理番号

DE_システム状態
DE_イベントカウンタ
DE_車灯機数
DE_歩灯器数
DE_接続方路数(I)DE_サービス方路数(J)b-1、c-2-2
b-1、c-2-2
DE_年
DE_月
DE_日
DE_サマータイム指定
DE_休日指定
DE_曜日
DE_予備 3
DE_時刻(時)DE_時刻(分)DE_時刻(秒)DE_時刻(100ms)
DE_予備 8b-1、c-2-2
DE_都道府県コード
DE_提供点種別コード
DE_交差点 ID/単路 ID
b-1、c-2-2
b-1、c-2-2
b-1、c-2-2
b-1、c-2-2
b-1、c-2-2
b-1、c-2-2―282―

ITS FORUM RC-017

DF_サービス方路信号
情報

DF_車灯器情報

DF_歩灯器情報

DF_方路識別情報

b-1、c-2-2
DE_方路 ID
DE_信号通行方向情報有無フラグ
DE_信号通行方向情報
DE_車灯器情報ポインタ
DE_歩灯器情報ポインタ
b-1、c-2-2
DE_車灯器 ID
DE_灯色出力変化数(K)DE_丸信号灯色表示
DE_青矢印信号表示方向
DE_カウントダウン停止フラグ
DE_最小残秒数(0.1 秒)
DE_最大残秒数(0.1 秒)

c-2-2
DE_歩灯器 ID
DE_灯色出力変化数(L)
DE_歩行者信号表示
DE_カウントダウン停止フラグ
DE_最小残秒数(0.1 秒)
DE_最大残秒数(0.1 秒)
b-1、c-2-2
DE_方路 ID

―283―

ITS FORUM RC-017
3.4.5

ハザード情報路側インフラや車両がハザード情報を通知するための情報要素。
3.4.5.1 利用ユースケース
c-1、c-3、d-1、d-2、d-3、d-4、d-5、e-1
3.4.5.2 情報要素詳細
・c-1、c-3 において車両が送信する情報要素
情報更新時刻c-1、c-3
情報を更新した時刻

NOTE: ハザード情報自体に、情報更新時刻情報が必要かは継続議論。
緊急行動発生時刻
緊急行動種別対象物情報
事象位置情報c-1、c-3
急減速・緊急車線変更を実施した時刻
c-1、c-3
緊急行動種別c-1、c-3
車両速度、車両種別
c-1、c-3
事象発生の緯度経度高度情報

事象距離情報
車線情報
道路種別情報通行可否情報発信元車載器 ID
配信対象車線情報
情報有効時間
再配信距離

c-1、c-3
事象発生地点までの距離
c-1、c-3
事象発生地点の車線情報
c-1、c-3地点の道路種別
c-1、c-3
事象発生地点の通行可否情報
c-1、c-3
事象発生車両の ID
c-1、c-3
リレー先の対象車線
c-1、c-3
メッセージをリレーする際に有効とみなす時間
c-1、c-3
メッセージをリレーする際に有効とみなす範囲―284―

ITS FORUM RC-017

・d-1、d-2、d-3、d-4、d-5 において路側インフラ或いは、車両が送信する情報要素
事象情報

d-x
発生時刻：ハザードが発生した時刻
発生事象(ハザード種別)：発生事象を通知
速度：走行速度（走行速度：車両速度）

地点情報

d-x
経度緯度高度：ハザード発生地点

通行情報

距離：配信する距離(ハザード発生地点からの距離)
レーン情報/上下線：ハザード発生レーン
道路種別等：道路種別d-x
通行可否情報：通行可否の情報

・e-1 において車両が送信する情報要素
事象情報

地点情報

通行情報
再配信指定情報予備

e-1
発生時刻：緊急車両が発進した時刻
発生事象：緊急車両の接近を通知
対象物情報(速度、車両種別)：速度、車両種別
e-1
経度緯度高度：緊急車両走行地点
経度緯度高度 2：30s 後の緊急車両推定走行地点
距離：使用しない想定
レーン情報/上下線：緊急車両走行レーン
レーン情報/上下線 2：30s 後の緊急車両走行レーン
道路種別等：道路種別
道路種別等 2：30s 後の道路種別
e-1
通行可否情報：通行可否の情報
e-1
発信元車載器 ID：使用しない想定
再配信対象レーン/上下線：使用しない想定
情報有効時間：使用しない想定
再配信距離：使用しない想定
e-1(本線規制情報等)―285―

ITS FORUM RC-017
3.4.6

後続車無人隊列走行情報

車両が後続車無人隊列走行に関連する情報を通知するための情報要素
3.4.6.1 利用ユースケース
g-1
3.4.6.2 情報要素詳細
車両状態情報車両属性情報後続車両情報車間距離
アクセル、ブレーキ
電子ミラー映像

3.4.7

g-1
シフトポジション、ステアリング角度
g-1
車両サイズ、車両幅
g-1
エンジン始動状況、水温、燃料残量、異常情報（システム故障情報等）
g-1
g-1
g-1
フルハイビジョンの映像

後続車有人隊列走行情報

車両が後続車有人隊列走行に関連する情報を通知するための情報要素
3.4.7.1 利用ユースケース
g-2
3.4.7.2 情報要素詳細
追従の可否やメーカ等を示す情報追従車両は対象の先行車両の ID 等
CACC 対応車の情報

g-2
g-2
g-2

―286―

ITS FORUM RC-017

4

情報要素の多重
本検討では、情報要素はユースケースや情報要素のタイプ毎にメッセージが生成され、無線アクセスレイヤでは、少なくともそれぞれのメッセージが独立に送受信できる想定で検討した。
以下のようなケースでは、いずれかのレイヤで情報要素/メッセージの多重を行うことが考えられる。

ケース 1) 同一ユースケースで送信側に異なるタイプの情報要素/メッセージが複数発生する
場合


例として、合流支援のユースケース a-1-3 で、路側インフラにおいて位置情報メッセー
ジのように周期的に送信される情報と、管制/合意の通信シーケンスのように特定のイベ
ント/シーケンスで送信される情報が発生している状況が考えられる。



ケース 2) 同一ユースケースで送信側に宛先の異なる情報要素/メッセージが複数発生する場
合

例として、合流支援のユースケース a-1-3 で、路側インフラが複数車両に対して管制制御手順を並行に実施し、複数の管制情報が発生している状況が考えられる。



ケース 3) 送信側に、異なるユースケース向けの情報要素/メッセージが複数発生する場合


例として、路側インフラにおいて、合流支援のユースケース a-1-3 の位置情報メッセー
ジと、ユースケース d-4 の分岐・出口渋滞支援に必要となるメッセージが同時に発生している状況が考えられる。

上記のようにタイプ、宛先、ユースケースの異なる複数の情報要素が同時に発生しているケースの扱いについては、以下の方法が考えられる。無線アクセスレイヤの能力により適用できる方式が異なる可能性があるため、無線アクセスレイヤの能力を考慮した方式の検討が必要である。本版では以下の情報要素多重方式について検討を行った。図 4-1 に各多重方式の例を示す。


方式 1：RC-017 記載の範囲で複数の情報要素/メッセージを多重する


方式 1a：1 つのメッセージで異なるタイプや異なる宛先向けの情報要素を複数含むことのできるメッセージフォーマットとする

方式 1b：1 つのメッセージでは一つのタイプや宛先向けの情報要素を含むが、それら複数のメッセージを多重するサブレイヤを本書記載のレイヤにもうける。



方式 2：無線アクセスレイヤで、無線通信路に送信前に複数の情報要素/メッセージを多重する方式 3：無線アクセスレイヤで、送信前には情報要素/メッセージの多重を行わないが、異なった時間や周波数などを用いて無線通信路のマルチプルアクセスにより多重する。



方式 4： 優先度の低い情報要素/メッセージや、待機時間に余裕のある情報要素/メッセージ―287―

ITS FORUM RC-017
は廃棄する、もしくは遅延させて送信する。
メッセージ#m

メッセージ#m
情報要素（群）#A

無線アクセスレイヤより上位のレイヤ(本書記載のレイヤ)

情報要素
（群）#B

メッセージ#n

情報要素
（群）#A

情報要素
（群）#B

H

無線アクセスレイヤ

H

H

物理チャネルへマッピングされるプロトコルデータユニット

物理チャネルへマッピングされるプロトコルデータユニット

方式1a

無線アクセスレイヤより上位のレイヤ(本書記載のレイヤ)

無線アクセスレイヤ

方式1b

メッセージ#m

メッセージ#n

メッセージ#m

メッセージ#n

情報要素
（群）#A

情報要素
（群）#B

情報要素
（群）#A

情報要素
（群）#B

H

H

物理チャネルへマッピングされるプロトコルデータユニット

H

物理チャネルへマッピングされるプロトコルデータユニット(異なった時間や周波数などを用いて無線通信路のマルチプルアクセスにより多重)

方式3

方式2

図 4-1. 情報要素の多重方式の例

NOTE: メッセージ#m、n は、タイプ、宛先、ユースケースなどが異なる情報要素（群）を含む
メッセージを示す。
NOTE: “H”は各レイヤで付与されるヘッダの例を示しており、多重するメッセージの長さ情報などが格納される。付与される位置や情報は各レイヤのプロトコルフォーマットに依存する。
方式 1 は、本書の範囲でメッセージの構成を検討する必要がある。
方式 1a は、情報要素間で共通化できる部分（たとえば、共通情報など）は、いずれか 1 度の通信が成立すればよいため、他方式に比べて無線で送信する情報量を低減できるメリットはあるが、それぞれの情報要素ごとの検討が必要になることと、メッセージ構造が複雑になり、応答のメッセー
ジが必要な場合は応答でどの部分に対する応答であること（たとえば、要求毎に割り振られる識別子などによって）を通知する必要がある。

―288―

ITS FORUM RC-017

方式 1 と方式 2 では、無線アクセスレイヤにおいて、方式 3 に比べて大きなパケットサイズを扱える能力が必要となる。
方式 3 では、他方式に比べて無線通信路へのアクセス回数が多くなる。また、方式 3 では誤り訂正の程度や送信パワーを変えることによりメッセージ毎の信頼度、到達距離を変更することもできる。
方式 4 では、情報要素/メッセージが無線区間許容遅延時間の要求を満たすことができなくなるこ
とがある。
5

参考文献
[1] 700MHz 帯高度道路交通システム実験用車車間通信メッセージガイドライン ITS FORUM
RC-013 1.1 版 https://itsforum.gr.jp/Public/J7Database/p60/p60.html―289―

ITS FORUM RC-017

［余白］

―290―

ITS FORUM RC-017

付録 2

今後の検討課題

表 1 に本書の検討に関する主な残課題／継続検討項目を示す。
ユースケースに関して、実運用に向けた検討が関係者により進展し、各種前提条件やサービス要件の設定が今後見直されることが予想されため、それらへの対応も含めて本資料のアップデートを適宜進める予定である。
表 1 本資料の検討に関する残存課題/継続検討項目

No.
1

対象
全体

章番号

2

a-1-3

3

項目

残課題／継続検討項目の概要
高精度 3 次元地図における CRP を用いた相対位置参照を適用するかどうか、適用する場合どの情報要素に適用すべきかの検討が必要。

2.4.3.6

提供する位置情報の実測と予測の使い分け

a-1-3

2.5.1.2

通信エリアの見直し

4

a-1-3

2.5.1.3

管制要求メッセージの受信到達確認方法

5a-1-3

2.5.1.3

複数車両が混在するときのシーケンス

路側インフラが提供する本線車両の位置情報として実測値と予測値が考えられるため、それらをどのように使い分けるか。
想定される遅延時間の設定と、更新要求メッセージと更新応答メッセー
ジの繰り返し回数の想定によって、路側管制時の通信エリアを見直すか
は、採用する通信方式によって検討が必要となる。
合流車が送信した管制要求が路側インフラで受信されたことを検出するための方法として複数の案があり、いずれを用いるかの検討が必要。
複数車両が混在する場合の規定の検
討

6

a-3

2.6.1.4

複数車線の車両への合
意調定手順

7

b-1-2

3.3.2.1

V2N のネットワーク
アーキテクチャ

位置情報

―291―

複数車線の車両と調停が必要な場合
において、一台ずつシリアルに調停を実施するか、複数車両に並行して調停を実施できるようにするのか
ネットワーク構成の検討範囲の明確化

ITS FORUM RC-017
8

b-1-2

3.3.2.1

9d-x（共通） 5.1.2

想定する道路条件

10e-1

6.2.1.5

配信方式

11

e-1

6.2.1.8

緊急車両からの配信情
報

12

e-1

6.2.1.9

配信情報の停止

13

g-1

8.5.1

無人隊列走行の急制動
情報の実現

14

g-1

8.5.1

リッチコンテンツ

15h-1

9.2.1.3

通信遅延、通信品質

16

h-1

9.2.1.7

配信情報

17

メッセージ
構成

-

情報要素のグルーピン
グ

18

メッセージ
構成

-

同時に運用されうる
ユースケース組み合わせ

車両位置情報と通信内
容の紐づけシーケンス―292―

シーケンスの候補として、完全プル方式、位置情報非同期・信号情報
プッシュ方式、位置情報周期・信号
情報プッシュ方式があり、いずれを用いるか。
一般車両について、想定速度および回避行動に必要な時間（距離）など。
見通し距離では V2V、見通し外ではV2N で対応することを想定し、これら 2 つを検討対象とした。本ユース
ケースの V2I の対応については役割等を含め継続検討。
30 秒後の地点情報としたが、これは暫定であり、どのような情報を送信するかは継続検討
管理サーバは、車両からの情報を基に緊急車両の解消の判定をし、通信インフラ（基地局）へ配信停止を通知する。その際の「配信停止」を示
すメッセージフォーマット/データは検討中（Null 埋め等を想定）。
20ms 周期で 5 連送の実現方式
フルハイビジョンのリアルタイム通信対応
無線区間許容遅延、及び 1 パケット当たりのパケット到達率は今後の課題とする
遠隔操作中に常時接続で配信される情報については現時点では特定出来ていないことから、継続検討とする
・情報要素のグルーピング妥当性の
継続確認
・情報要素のグルーピングの粒度の検討（e.g., TD-001 におけるデータフ
レーム（DF）レベルなど）
・類似の情報要素を送信する異なる
ユースケースにおいて、情報要素にバリエーションがある場合の扱い（e.g., a-1-x と c-2-2 や、c-1/3 と dx/e-1 など）
実運用などをより考慮した場合に同時に発生しうるユースケースの組み合わせと、そのメッセージ構成検討

ITS FORUM RC-017

19

メッセージ
構成

-

情報要素の詳細議論

20

メッセージ
構成

-

その他

―293―

・全体的な過不足確認（e.g., シナリ
オには入っていないが、TD-001 の共通領域に定義されている情報要素など）・異なるユースケースにおける類似/
同等の情報要素がある場合の定義方
法（e.g,, メッセージ ID、路側機 ID/
車載器 ID/車両 ID）
・既存仕様（e.g., TD-001 や DSSS仕様）の情報要素との整合・車両基本情報の送信方法（ユース
ケースによらず定常的に周期送信する、など）
・想定するメッセージの Encoding 方法（e.g., ASN.1 など）や情報要素単位でのバイトアラインの検討