1 5GAA P-180106

Contents
Contents .........................................................................................................................................................2
1.0 Introduction .....................................................................................................................................5
2.0 5GAA WG1 Scope and Methodology ..................................................................................................5
2.1 Definitions and Templates .......................................................................................................5
2.2 Use Case Grouping ..................................................................................................................8
3.0 C-V2X Use Case Examples ............................................................................................................... 10
4.0 Service-level Requirements of Example C-V2X Use Cases ................................................................... 11
4.1 Cross-Traffic Left-Turn Assist................................................................................................. 11
4.2 Intersection Movement Assist ............................................................................................... 13
4.3 Emergency Brake Warning .................................................................................................... 14
4.4 Traffic Jam Warning ............................................................................................................. 16
4.5 Software Update ................................................................................................................. 22
4.6 Remote Vehicle Health Monitoring ........................................................................................ 31
4.7 Hazardous Location Warning ................................................................................................ 32
4.8 Speed Harmonization ........................................................................................................... 35
4.9 High Definition Sensor Sharing .............................................................................................. 37
4.10 See-Through for Pass Maneuver............................................................................................ 38
4.11 Lane Change Warning .......................................................................................................... 40
4.12 Vulnerable Road User........................................................................................................... 43
5.0 Conclusions and Next Steps ............................................................................................................ 47
Annex <A> 48
A.1 Use Case Description Template ................................................................................................. 48
A.2 Detailed Description of Example C-V2X Use Cases ....................................................................... 49

5GAA
 3

Version: 1.0
Date of publication: 19.06.2019
Document type: White Paper
Confidentiality class: P (Public use)
Reference 5GAA Working Group Working Group 1
Date of approval by 5GAA Board: 13.06.2019

5GAA

Postal address
5GAA c/o MCI Munich
Neumarkter Str. 21
81673 München, Germany

Internet
[Link]

Copyright Notification

No part may be reproduced except as authorized by written permission. The copyright and the foregoing
restriction extend to reproduction in all media.

5GAA
 4

5G Automotive Association (5GAA) have defined a methodology to describe Use

Cases(UC), UC descriptions have been done by numerous constellations during the
last decades, different in every region, using different terminology and different
ways to describe, etc, This have made it difficult to communicate in one ‘language’.
To overcome this, 5GAA as a leading global organisation with worldwide
representation from almost all sectors of the industry have set a common language
in this area in a way that is also suitable for Automakers (also known as OEMs) and
their interest.
This is also proposed since 5GAA works on new, innovative use cases that includes
complex interaction between vehicles and between vehicles and infrastructure in
relation to self-driving (autonomous) vehicles, so it is a good time for a new fresh
(re)start of this area.

5GAA have also aligned the UC groupings and characterization of UCs to make it
easier see where a UC have a benefit and to identify potential stakeholders, the
following UC grouping are used, Safety, Vehicle Operations Management,
Convenience, Autonomous driving, Platooning, Traffic Efficiency and Environmental
friendliness, Society and Community (These groupings are further described in the
white paper).

5GAA have also introduced the concept of Service Level Requirements (SLR) to
provide requirements for the UCs. (This is further described in the white paper.)

This white paper describes the 5GAA methodology used to create solution agnostic
UC descriptions in order to facilitate the selection of the most suitable technology
to realize a UCs. The white paper uses a few UCs to illustrate the methodology, note
that the described UCs are just some examples and do not reflect any 5GAA
prioritization of UCs.

4
 5
1.0 Introduction
5G Automotive Association (5GAA) bringing together automotive and telecommunications industries with the
goal is to accelerate the global deployment of Cellular Vehicle-To-Everything (C-V2X), as a first step towards a
fully integrated intelligent transport system with 5G. In order to achieve this goal 5GAA has organized its work
along five complementing work streams or work groups covering the following areas:

1. Use cases
2. Solutions and architecture
3. Testing, pilots, interoperability
4. Spectrum, regulatory and standards
5. Business and go to market strategies
Arguably the first step in understanding the value 5GAA brings to the communities is to clearly define the use
cases. As defined, the use case can be viewed as a “description of set of sequences of actions that a system
performs that yield an observable result of value to an actor”. We point out that while the use cases that are
defined by 5GAA represent the interaction between actors they can also be viewed as problem statements from
their communications viewpoint. In addition to use case description the work in Work Group 1 covers
development of detailed application requirements referred to as Service Level Requirements. Together with use
case description this information is subsequently used by other 5GAA Work Groups to develop solutions, create
test procedures and demos and pilots, evaluate spectrum needs and co-operate with standards development
organizations and finally create the business case and path for deployment.

This white paper describes 5GAA’s approach in defining use cases and associated Service Level Requirements.
In Section 2 we describe our methodology and present the format used to record use cases. Section 3 gives a
quick summary of use cases covered by this white paper providing enough information to follow the service level
requirements presented in Section 4. Detailed description of each use case can be found in the Appendix A. We
conclude the white paper with a summary in Section 5 and briefly present the planned future work.

2.0 5GAA WG1 Scope and Methodology

The main goals of 5GAA WG1 include the definition of solution agnostic automotive use cases for C-V2X and the
derivation of service level requirements from the use cases.

2.1 Definitions and Templates

For description of C-V2X use cases, WG1 firstly analyzed the relationship between road environments, use cases
and use cases scenarios by introducing a hierarchical classification:

5
 6
o Road environments: are the typical places where vehicle traffic and C-V2X use cases occur, such as

intersections, urban and rural streets, high speed roads (Autobahn), parking lots, etc. Each use case

should be mapped to at least one road environment, while the latter can be associated to one or more

use cases. In combination, multiple use cases form the communication performance requirements in

an environment.

o Use Cases: are the high level procedures of executing an application in a particular situation with a

specific purpose. A use case may entail a number of specific scenarios, where different requirements

may apply.

o User Stories: Given a high level use case description as described above, different specific use case

scenarios can be derived for different situations that may imply in different specific requirements. For

example, one use case may have a variation for driver assistance and another variant for fully automated

driving.

Based on the above definitions a 3-level hierarchy has been defined, where in the highest level we have the road
environment, in the middle level the use cases and in the lowest level the use cases scenarios.

Figure 1 Definition of the hierarchy between road environment, use cases and use cases scenarios

The hierarchy and the relation between the different levels is exemplified in Figure 1 and it is observed that:

o Every use case is connected to at least one road environment and at least one use case scenario

o Every road environment may serve a framework to many use cases

o Use case scenarios are specific variations of one use case; Solution-agnostic, our assumptions.

6
 7
The C-V2X use cases are described using a template applicable to a wide range of use cases that allows a more
detailed description of C-V2X use cases to support the derivation of the service-level requirements. The template
is presented in Annex A.2 with the corresponding explanation of the different fields.

The objective of the template is to remain as abstract as possible relative to the specific implementation and
architecture of the overlaying cellular system but define specific roles for the different actors, the applicable
road environment and the specific use case scenario/user story. The UC descriptions are written from the vehicle
perspective and strive to be solution agnostic and applicable to both driven and autonomous vehicles. The
realization of UCs do not preclude applications performing various tasks supporting the UCs, such as collecting
information, analysing etc. Furthermore, radio symbols in figures indicate a connected vehicle. It is also assumed
that messages are exchanged in a secure way between authenticated parties.

5GAA WG1 has defined service level requirements that describe C-V2X use case requirements in a technology
and implementation agnostic way. The list of considered service level requirements is provided below:

Definitions of C-V2X Service-level Requirements

Service level
Definition
Requirement
Range Expected distance from Host Vehicle (HV) to scenario application zone
Quality of information / Information needs of the end-user (e.g., a driver, a
Information passenger, robot in the car or remote, application program running in an ECU, etc…).
requested/generated In this description the end result of the information delivery is important while the
actual transfer is not a concern.
Measurements of time from the occurrence of the event in scenario application
zone to the beginning of the resulting actuation. Depending on implementation, this
includes one or more of following:
Service Level Latency o processing of the event into information by the information generator,
o communication of the information to end-user,
o processing of the information by the end-user and
o time to actuation driven by the result of processing of the information.
Based on an agreed QoS framework, the guaranteed and expected performance to
start/initialize, perform and finalize (end-to-end) applications within use cases.
Different agreed and provided QoS levels will result in different performances within
Service Level Reliability
the applications. Known or expected changes in service level reliability before
starting an application or during operation should be announced timely to the
relevant applications and entities involved.
Describes the maximum absolute speed of a vehicle at which a defined QoS can be
achieved (in km/h). Note: Describes the extent of mobility and the average speed of
Velocity the vehicle involved in the use case. Note that there may be a need to capture the
peak expected speed. This definition may also be required to be split to describe the
type of mobility from the speed. For instance, nomadic is a type of mobility.

7
 8
Expected number of vehicles per a given area (per km2) during the execution of the
Vehicle Density use case. Note: that this provides an indication that multiple vehicles within the
same area run the same (and potentially additional) use case(s) in parallel.
Positioning Accuracy / Position Accuracy / Location accuracy, at the time when
position information is delivered to end-user (HV), between the actual position and
Positioning the position information: a) Location type: absolute / geographical or relative or
N/A, b) KPI: accuracy level. Note: The confidence interval of position information is
provided in units of sigma e.g., 1-sigma (1, 2-sigma (23-sigma (3
Interoperability/
Yes / No, to indicate the need for inter-OEM interoperability, e.g., in case of
Regulatory/
cooperative safety use cases.
Standardization Required

2.2 Use Case Grouping

Taking into consideration that a number of new, innovative use cases have emerged during the last years and
many more will come in the following years, 5GAA has identified the following groups of use cases:

1. Safety
2. Vehicle Operations Management
3. Convenience
4. Autonomous driving
5. Platooning
6. Traffic Efficiency and Environmental friendliness
7. Society and Community
C-V2X use cases grouping helps to easier identify which stakeholder would benefit from a C-V2X use case. It
should be noted that a use case may belong to more than one of the proposed groups. A short description of
the identified groups is provided below.

Safety: This group includes use cases that provide enhanced safety for vehicle and driver. Examples of use cases
include Emergency Braking, Intersection Mgmt. Assist, Collision warning or Lane change. These use cases would
in many apply equally to autonomous vehicles or to provide assistance to drivers, with some notable exceptions
such as See-Trough, camera assistance with are intended for human drivers. It is expected that many of these
use cases would need to be defined into a standard and regulated mode to ensure consistent operation and
functioning between different OEMs.

Vehicle Operations Management: This group includes use cases that provide operational and management value
to the vehicle manufacturer. Use cases in this group would include sensors monitoring, software updates,
remote support, etc. From a business and monetization modelling point of view, these are use cases that could
be provided by vehicle manufacturers (OEMs) to improve efficiency of vehicle maintenance and vehicle
monitoring. Some use cases such as remote support would be attractive to vehicle owners/drivers,

8
 9
transport/delivery companies. These use case are likely not requiring standardization, as each OEM could be
developing them in their own proprietary mode. (Potentially a group of OEMs could agree on a proprietary
standard and implementation to save development cost for certain UCs)

Convenience: This group includes use cases that provide value and convenience to the driver. Examples for this
group can include Infotainment, assisted and cooperative navigation, and autonomous smart parking. These are
use cases which may not be mandated from a safety program point of view, but that provide significant value to
the driver or passengers in the vehicles. From a business modelling point of view, these are use cases that would
be attractive to vehicle drivers or passengers.

Autonomous Driving: This use case group address use cases that are relevant for Autonomous/self-driving
vehicles (Society of Automotive Engineers (SAE) level 4 and 5), examples in this group are control if autonomous
driving is allowed or not, Tele-operation (potentially with Augmented Reality support for a remote driver),
handling of dynamic maps (update/download), some of the Safety UCs that require cooperative interaction
between vehicles to be efficient and safe. These use cases are from a business modelling point of view attractive
of value to vehicle owners/drivers, transport/delivery companies.

Platooning: This use case group address use cases that are relevant for platooning, examples in this group are
platoon management, e.g., collect and establish a platoon, determine position in platoon, dissolve a platoon,
manage distance within platoon, leave a platoon, control of platoon in steady state, request passing through a
platoon. These use cases are of interest to transport companies and potentially by road operators/road traffic
authorities since road infrastructure could be used more efficiently. Potentially also for society as it could provide
environmental benefits such as reduced emissions. These use cases are from a business modelling point of view
attractive to vehicle owners/drivers, transport/delivery companies.

Traffic Efficiency and Environmental friendliness: This group includes use cases that provide enhanced value to
infrastructure or city providers, where the vehicles will be operating. As examples for this use case group, Green
Light Optimal Speed Advisory (GLOSA), traffic jam information, Routing advise e.g., Smart routing. These use
cases are from a business modelling point of view attractive of value to vehicle owners/drivers,
transport/delivery companies, potentially subsidized by public means since it could provide environmental
benefits.

Society and Community: This group includes use cases that are of value and interest to the society and public,
e.g., Vulnerable Road User (VRU) protection, public services, such as ambulance, police, fire brigades, Emergency
answering points, governments, road authorities, examples in this group are Emergency vehicle approaching,
traffic light priority, patient monitoring, crash report. These use cases are from a business modelling point of
view attractive to the public/private sector.

9
 10
3.0 C-V2X Use Case Examples
This section contains a short description of example use case descriptions developed by 5GAA WG1. Each use
case can be composed of multiple use case scenarios, wherein use case scenarios can differ in terms of road
configuration, actors involved, service flows, etc. A more detailed description of the use cases is provided in
Annex A.2.

Cross-Traffic Left-Turn Assist (Safety, Autonomous

Driving): Assist Host Vehicle (HV) attempting to
turn left across traffic approaching from the
opposite direction.

Intersection Movement Assist (Safety, Autonomous

Driving): Stationary HV proceeds straight from stop
at an intersection. HV is alerted if it is unsafe to
proceed through the intersection (i.e., alerts for
Figure 2 Intersection
approaching cross-traffic from the left or the right Movement Assist – Adjacent
side, incoming traffic intending to turn left). Traffic from the left

Emergency Break Warning (Safety, Autonomous Driving): Alert HV that a lead Remote Vehicle (RV) is undergoing
an emergency braking event.

Traffic Jam Warning (Convenience): Warn HV of

an approaching traffic jam on the road or notify
HV of a traffic jam on the navigation route.

Software Update (Vehicle Operations

Management): Vehicle manufacturer updates
electronic control module software for
targeted vehicles.

Remote Vehicle Health Monitoring (Vehicle

Operations Management): Owners, fleet
Figure 3 Traffic Jam Warning – On operators and authorized vehicle service
Route providers monitor the health of HV and are
alerted when maintenance or service is
required.

Hazardous Location Warning (Safety, Autonomous Driving): Warn the HV of a hazardous location and provide
additional information to safely navigate around the hazard.

Speed Harmonization (Traffic Efficiency and Environmental friendliness, Autonomous Driving): Notify HV of
recommended speed to be applied at certain location to optimize traffic flow, minimize emissions and to ensure
a smooth and safe ride.

10
 11
High Definition Sensor Sharing (Autonomous Driving): Vehicle uses its own sensors (e.g., HD camera, lidar), and
sensor information from other vehicles, to perceive its environment (e.g., come up with 3D model of world
around it) and safely performs an automated driving lane change.

See-Through for Pass Maneuver (Safety): Driver of Host Vehicle that signals an intention to pass a Remote Vehicle
(RV) using the oncoming traffic lane is provided a video stream showing the view in front of the RV.

Lane Change Warning (Safety): HV signals an intention to change lane and an alert is received by neighboring
vehicles in case of a lack of space, risk of collision or his maneuver is not permitted on the current road segment.

Vulnerable Road User (Society and Community, Safety): Alert HV of approaching VRU in the road or crossing an
intersection and warn of any risk of collision

.
Figure 4 Vulnerable Road User -
Intersection

4.0 Service-level Requirements of Example C-V2X Use Cases

This section provides the service level requirements of the example C-V2X use cases developed by 5GAA WG1.
For some of the use cases different user stories have been presented with different service level requirements.

4.1 Cross-Traffic Left-Turn Assist

User Story Detailed description and specifics

User Story #1 Automated vehicles exchange awareness messages (e.g., CAM, BSM). No information
about future trajectories is exchanged. Instead, a risk for collision is calculated based on
the data collected in the past and present and a warning is displayed to the driver,
consecutively.

User Story #2 In this user story, higher automation levels are considered. Autonomous cars exchange
planned, future trajectories with each other. Based on those, more accurate estimation
regarding possible collisions are possible.

User Story #1
(all scenarios, no matter which direction traffic is coming from)

11
 12
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] 350 Maximum communication range assumed, this allows
Range for ~ 5 s to react (at the max speed mentioned within
the velocity section).

Quality of 300 bytes LTA in user story one is based on normal awareness
Information
information / per messages (e.g., CAM, BSM) exchange.
requested/generat
Information message
ed
needs

Service Level
[ms] 100 Normal awareness messages (e.g., CAM, BSM) latency.
Latency

% 90 For single awareness messages (e.g., CAM, BSM)

without retransmission, this reliability is enough to
Service Level
ensure the ETSI requirement of <5% probability of two
Reliability
consecutive awareness message (e.g., CAM, BSM)
transmission failing.

[m/s] 33.3 Most critical situations are to be expected at rural

intersections. Here, the RV could be driving with up to
120 km/h, and the HV that wants to turn is on the way
Velocity
of slowing down, possibly also from 120 km/h.
Therefore, maximum speeds of 120 km/h seem to be a
reasonable value.

[vehicle/km^ 1500 This use case is expected to mostly happen not in very
2] dense metropolis areas, since sight at intersections is
Vehicle Density
mostly good, speeds are limited around 50 km/h, and
traffic lights can be expected at most intersections.

[m] 1.5 (3σ) The most probable scenario for the use case is
envisioned in rural intersections that are hard to see
Positioning
and where higher speeds of the participating cars are
expected.
Interoperability/
[yes/no] Yes / Yes / In order to perform lane-accurate positioning, a
Regulatory/
Standardization Yes positioning accuracy of around 1m should be provided.
Required

User Story #2
(all scenarios, no matter which direction traffic is coming from)
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement

12
 13

[m] 350 Maximum communication range assumed, this allows

Range for ~ 5 s to react (at the max speed mentioned within
the velocity section).

Quality of Approx. Intended trajectories have to be sent by the RVs, since

Information
information / 1000 bytes they determine whether or not a collision is imminent
requested/generat
Information per or not. In order to do so, some more payload than with
ed
needs message normal CAMs should be used.

[ms] 10 LTA is a rather critical use case. Depending on the

Service Level implementation, warning messages might be issued
Latency only shortly before actual turning is said to happen.
Therefore, this short of a latency seems reasonable.

% 99.9 A service level reliability this high should be enough to

Service Level allow perceived zero-error appearance of the cross-
Reliability traffic left-turn assist. False positives are more
problematic than false negatives.

[m/s] 33.3 Most critical situations are to be expected at rural

intersections. Here, the RV could be driving with up to
120 km/h, and the HV that wants to turn is on the way
Velocity
of slowing down, possibly also from 120 km/h.
Therefore, maximum speeds of 120 km/h seem to be a
reasonable value.

[vehicle/km^ 1500 This use case is expected to mostly happen not in very
2] dense metropolis areas, since sight at intersections is
Vehicle Density
mostly good, speeds are limited around 50 km/h, and
traffic lights can be expected at most intersections.

[m] 1.5 (3σ) In order to perform lane-accurate positioning, a

Positioning
positioning accuracy of around 1m should be provided.

[yes/no] Yes / Yes / Interoperability between different OEMs is needed.

Interoperability/ Yes It should be regulated that every vehicle has to make
Regulatory/ its presence known periodically (as a broadcast).
Standardization Standardization is required in the sense that the format
Required for trajectories should be common to all so that they
can be understood by all.

4.2 Intersection Movement Assist

User Story Detailed description and specifics

13
 14

User Story #1 Two vehicles are approaching an intersection (as described in main event flow). The
vehicles determine the risk for a collision based on the vehicles’ estimated trajectories.

User Story #1
(all scenarios, no matter which direction traffic is coming from)
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] Min 100 Braking distance at 0.4g from 100km/h, e.g., at an
Range
intersection on a rural road.

Quality of awareness Calculate trajectories based on exchanged data in

information / messages awareness messages (e.g., CAM, BSM). Changes in
Information
Information (e.g., CAM, kinematics of involved vehicles might require this
requested/generat
needs BSM) information to be updated (or shared periodically)
ed
(around within the boundaries given by the Service Level
300 bytes) Latency.

Service Level [ms] 100 Not highly time critical, but should stay below 100ms
Latency to be effective / comparable to other ADAS.

Service Level % High / Needs to reliably allow for trajectory calculation to

Reliability 99.99 avoid collisions.

Velocity [m/s] 33.3 Assuming speeds up to 120 km/h.

[vehicle/km^ 12000 Max assumed density in urban situation.

Vehicle Density
2]

[m] 1.5 (3σ) Required for accurate trajectory calculation and

Positioning
collision risk estimation in relation to vehicle size.

Interoperability/
[yes/no] Yes / Yes / Interoperability between manufacturers’
Regulatory/
Standardization Yes implementations to be guaranteed by standardization.
Required

4.3 Emergency Brake Warning

User Story Detailed description and specifics

User Story #1 HV is moving at very high speed different from RV in a highly congested traffic scenario
illustrated in Annex A.2. HV is driven by human driver. RV applies brake in order to make
an emergency stop. HV is at distance D behind the RV and the HV driver does not see RV
applying brake or is distracted. Wet road conditions assumed.

14
 15

User Story #2 HV is at least Level 2 automation. HV is moving at very high speed different from RV in a
highly congested traffic scenario illustrated in Annex A.2. HV is driven by human driver or
robot. RV applies breaks in order to make an emergency stop. Wet road conditions
assumed.

User Story #1
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] 360 Under the assumptions of Vrv=25 m/s, Vhv=50 m/s and
a=0.4g this is the minimum distance (400 ms margin or
Range
20 meters) at which HV needs to be warned to avoid
collision.

Quality of awareness The message should be delivered to HV. It contains the

information / messages information about the hard braking event at RV. It
Information Information (e.g., CAM, contains other information regarding RV such as
requested/generat needs BSM) location, velocity, acceleration, etc.
ed (between
200-400
bytes)

[ms] 120 Ideally, the information about the Hard Braking event
should be conveyed as soon as possible. Examining
current radar and camera vision sensors the detection
times are 100-300 ms which makes V2X latency within
the same budget. Additionally, for the reliability that
Service Level we are requesting this latency seems reasonable. For
Latency example, the latency of 100 ms causes the HV to travel
additional 5 meters before final stop at 50 m/s initial
velocity, however, this additional distance is budgeted
in the range estimate.

This includes handling, access, and OTA latency.

Service Level % 99.99 The Hard Braking event message needs to be delivered
Reliability to the HV with high reliability.

Velocity [m/s] 69.4 250km/h, as assumed maximum speed

[vehicle/km^ 12000 Assume maximum density.

Vehicle Density
2]

[m] 1.5 (3σ) HV needs to know whether the hard braking vehicle in
Positioning
the front is in the same lane.

15
 16
Interoperability/
[yes/no] Yes / Yes / Interoperability needs to be in place for HV to receive a
Regulatory/
Standardization Yes message from RV.
Required

User Story #2

Service level SLR Unit SLR Value Explanations/Reasoning/Background

Requirement
[m] 290 Under the assumptions of Vrv=25 m/s, Vhv=50 m/s, 0.5
second reaction time and a=0.4g (and 300 ms margin
Range or 15 meters) this is the minimum distance at which
the Level 3 system needs to be warned to avoid
collision.

Quality of awareness The message should be delivered to HV. It contains the

information / messages information about the hard braking event at RV. It
Information Information (e.g., CAM, contains other information regarding RV such as
requested/generat needs BSM) location, velocity, acceleration, etc.
ed (between
200-400
bytes)

[ms] 120 Reasonable latency in the context of the other existing

Service Level
sensor systems as well as taking into account the high
Latency
reliability needed.

Service Level % 99.99 The Hard Braking event message needs to be delivered
Reliability to the HV with high reliability.

Velocity [m/s] 69.4 250km/h, as assumed maximum speed.

[vehicle/km^ 12000 Assume maximum density.

Vehicle Density
2]

[m] 1.5 (3σ) HV needs to know whether the hard braking vehicle in
Positioning
the front is in the same lane.
Interoperability/
[yes/no] Yes / Yes / Interoperability needs to be in place for HV to receive a
Regulatory/
Standardization Yes message from RV.
Required

4.4 Traffic Jam Warning

User Story #1 Urban Scenario on Road Warning

16
 17
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] 1000 Warn early enough to safely brake when approaching
the traffic jam.

Range Calculation based on the duration of a traffic jam and

the possibility for it to still exist when a vehicle driving
on its way with an average speed is reaching the jam
(duration 2 h, speed 50 km/h).

Quality of Uplink Get Traffic jam information from awareness messages

information / awareness ((e.g., CAM, BSM, DENM) or from other (backend)
Information
Information messages services.
requested/generat
needs (e.g., CAM,
ed Size usually around 300bytes
BSM,
DENM)

[ms] 2000 Traffic jams are normally not happening within a very
short time period. If communication range is big
enough e.g., on a highway 2 seconds driving with 150
Service Level
km/s means 80 meters. Jam should be visible if you are
Latency
as close as 80 meters in urban environment (50 km/h)
2 seconds means 26 meters which should be close
enough to see the jam

% Medium / Normally a traffic jam contains several cars. Assuming

Service Level an equipment rate of 20% and an average of at least 10
50
Reliability cars per jam means that there are at least 2 cars which
send the message in parallel.

[m/s] 19.4 Assuming typical maximum allowed speeds and some

Velocity
safety (70 km/h).

[vehicle/km^ 12000 Max assumed density in urban situation.

Vehicle Density
2]

[m] 20 (1σ) As there is the assumption that the jam is not

something very spontaneously and as the warning is
Positioning
meant for areas higher than LoS the given values seem
reasonable.

Interoperability/
[yes/no] Yes / Yes / Interoperability between manufacturers’
Regulatory/
Standardization Yes implementations to be guaranteed by standardization.
Required

User Story #2 Rural Scenario on Road Warning

17
 18
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] 1000 Warn early enough to safely brake when approaching
the traffic jam.

Range Calculation based on the duration of a traffic jam and

the possibility for it to still exist when a vehicle driving
on its way with an average speed is reaching the jam
(duration 2 h, speed 50 km/h, 100 km/h 150 km/h)

Quality of Uplink Get Traffic jam information from awareness messages

information / awareness ((e.g., CAM, BSM, DENM) or from other (backend)
Information
Information messages services.
requested/generat
needs (e.g., CAM,
ed Size usually around 300bytes
BSM,
DENM)

[ms] 2000 Traffic jams are normally not happening within a very
short time period. If communication range is big
enough e.g., on a highway 2 seconds driving with 150
Service Level
km/s means 80 meters. Jam should be visible if you are
Latency
as close as 80 meters in urban environment (50 km/h)
2 seconds means 26 meters which should be close
enough to see the jam.

% Medium / Normally a traffic jam contains several cars. Assuming

Service Level 50 an equipment rate of 20% and an average of at least 10
Reliability cars per jam means that there are at least 2 cars which
send the message in parallel.

[m/s] 33.3 Assuming typical maximum allowed speeds and some

Velocity
safety (120 km/h).

[vehicle/km^ 9000 Max assumed density in rural situation.

Vehicle Density
2]

[m] 20 (1σ) As there is the assumption that the jam is not

something very spontaneously and as the warning is
Positioning
meant for areas higher than LoS the given values seem
reasonable.

Interoperability/
[yes/no] Yes / Yes / Interoperability between manufacturers’
Regulatory/
Standardization Yes implementations to be guaranteed by standardization.
Required

User Story #3 Highway Scenario on Road Warning

18
 19
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] 1000 Warn early enough to safely brake when approaching
the traffic jam.

Range Calculation based on the duration of a traffic jam and

the possibility for it to still exist when a vehicle driving
on its way with an average speed is reaching the jam
(duration 2 h, speed 50 km/h, 100 km/h 150 km/h)

Quality of Uplink Get Traffic jam information from awareness messages

information / awareness ((e.g., CAM, BSM, DENM) or from other (backend)
Information
Information messages services.
requested/generat
needs (e.g., CAM,
ed Size usually around 300bytes.
BSM,
DENM)

[ms] 2000 Traffic jams are normally not happening within a very
short time period. If communication range is big
enough e.g., on a highway 2 seconds driving with 150
Service Level
km/s means 80 meters. Jam should be visible if you are
Latency
as close as 80 meters in urban environment (50 km/h)
2 seconds means 26 meters which should be close
enough to see the jam

% Medium / Normally a traffic jam contains several cars. Assuming

Service Level 50 an equipment rate of 20% and an average of at least 10
Reliability cars per jam means that there are at least 2 cars which
send the message in parallel.

[m/s] 69.4 Assuming typical maximum allowed speeds and some

Velocity
safety (250 km/h).

[vehicle/km^ 4500 Max assumed density in highway situation.

Vehicle Density
2]

[m] 2 (1σ) As there is the assumption that the jam is not

something very spontaneously and as the warning is
Positioning
meant for areas higher than LoS the given values seem
reasonable.

Interoperability/
[yes/no] yes Interoperability between manufacturers’
Regulatory/
Standardization implementations to be guaranteed by standardization.
Required

User Story #4 Urban Scenario on Route Information

19
 20
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] 100000 Warn early enough to safely brake when approaching
the traffic jam.

Range Calculation based on the duration of a traffic jam and

the possibility for it to still exist when a vehicle driving
on its way with an average speed is reaching the jam
(duration 2 h, speed 50 km/h).

Quality of Uplink Get Traffic jam information from awareness messages

information / awareness ((e.g., CAM, BSM, DENM) or from other (backend)
Information
Information messages services.
requested/generat
needs (e.g., CAM,
ed Size usually around 300bytes.
BSM,
DENM)

[ms] Minutes Traffic jams are normally not happening within a very
short time period. If communication range is big
enough e.g., on a highway 2 seconds driving with 150
Service Level
km/s means 80 meters. Jam should be visible if you are
Latency
as close as 80 meters in urban environment (50 km/h)
2 seconds means 26 meters which should be close
enough to see the jam.

% Medium / Normally a traffic jam contains several cars. Assuming

Service Level 50 an equipment rate of 20% and an average of at least 10
Reliability cars per jam means that there are at least 2 cars which
send the message in parallel.

[m/s] 19.44 Assuming typical maximum allowed speeds and some

Velocity
safety (70 km/h).

[vehicle/km^ 12000 Max assumed density in urban situation.

Vehicle Density
2]

[m] 20 (1σ) As there is the assumption that the jam is not

something very spontaneously and as the warning is
Positioning
meant for areas higher than LoS the given values seem
reasonable.

Interoperability/
[yes/no] Yes / Yes / Interoperability between manufacturers’
Regulatory/
Standardization Yes implementations to be guaranteed by standardization.
Required

User Story #5 Rural Scenario on Route Information

20
 21
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] 200000 Warn early enough to safely brake when approaching
the traffic jam.

Range Calculation based on the duration of a traffic jam and

the possibility for it to still exist when a vehicle driving
on its way with an average speed is reaching the jam
(duration 2 h, speed 50 km/h, 100 km/h 150 km/h).

Quality of Uplink Get Traffic jam information from awareness messages

information / awareness ((e.g., CAM, BSM, DENM) or from other (backend)
Information
Information messages services.
requested/generat
needs (e.g., CAM,
ed Size usually around 300bytes.
BSM,
DENM)

[ms] Minutes Traffic jams are normally not happening within a very
short time period. If communication range is big
enough e.g., on a highway 2 seconds driving with 150
Service Level
km/s means 80 meters. Jam should be visible if you are
Latency
as close as 80 meters in urban environment (50 km/h)
2 seconds means 26 meters which should be close
enough to see the jam.

% Medium / Normally a traffic jam contains several cars. Assuming

Service Level 50 an equipment rate of 20% and an average of at least 10
Reliability cars per jam means that there are at least 2 cars which
send the message in parallel.

[m/s] 33.3 Assuming typical maximum allowed speeds and some

Velocity
safety (120 km/h).

[vehicle/km^ 9000 Max assumed density in rural situation.

Vehicle Density
2]

[m] 20 (1σ) As there is the assumption that the jam is not

something very spontaneously and as the warning is
Positioning
meant for areas higher than LoS the given values seem
reasonable.

Interoperability/
[yes/no] Yes / Yes / Interoperability between manufacturers’
Regulatory/
Standardization Yes implementations to be guaranteed by standardization.
Required

User Story #6 Highway Scenario on Route Information

21
 22
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] 300000 Warn early enough to safely brake when approaching
the traffic jam.

Range Calculation based on the duration of a traffic jam and

the possibility for it to still exist when a vehicle driving
on its way with an average speed is reaching the jam
(duration 2 h, speed 50 km/h, 100 km/h 150 km/h).

Quality of Uplink Get Traffic jam information from awareness messages

information / awareness ((e.g., CAM, BSM, DENM) or from other (backend)
Information
Information messages services.
requested/generat
needs (e.g., CAM,
ed Size usually around 300bytes.
BSM,
DENM)

[ms] Minutes Traffic jams are normally not happening within a very
short time period. If communication range is big
enough e.g., on a highway 2 seconds driving with 150
Service Level
km/s means 80 meters. Jam should be visible if you are
Latency
as close as 80 meters in urban environment (50 km/h)
2 seconds means 26 meters which should be close
enough to see the jam.

% Medium / Normally a traffic jam contains several cars. Assuming

Service Level 50 an equipment rate of 20% and an average of at least 10
Reliability cars per jam means that there are at least 2 cars which
send the message in parallel.

[m/s] 69.4 Assuming typical maximum allowed speeds and some

Velocity
safety (250 km/h).

[vehicle/km^ 4500 Max assumed density in highway situation.

Vehicle Density
2]

[m] 20 (1σ) As there is the assumption that the jam is not

something very spontaneously and as the warning is
Positioning
meant for areas higher than LoS the given values seem
reasonable.

Interoperability/
[yes/no] Yes / Yes / Interoperability between manufacturers’
Regulatory/
Standardization Yes implementations to be guaranteed by standardization.
Required

4.5 Software Update

22
 23

User Story Detailed description and specifics

The “normal” case requiring a software update in a conventional (non-autonomous)

vehicle. Software download and software installation are separate.

The software is downloaded securely and reliably, as coverage and bandwidth are
Software available. Its transmission must not adversely affect any safety-critical or user experience-
Update critical functions.
(Conventional- The driver is asked for consent to install the software when appropriate.
Routine)
Software installation is a separate process that occurs when safe and convenient. It may
also vary depending on the vehicle manufacturer, model, and specific ECUs. For example,
a non-critical system might be updated any time but a safety-critical system might only be
updated when the vehicle is securely parked and will not be used for an extended period.

Software Update (Conventional-Routine)

Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] Within In principle, the user story is applicable in the network
network service provider coverage area.
Range service
provider
coverage

Quality of 1.5GB This is a current-day example of a major OEM update

information / within 168 image that would be manually updated and installed
Information Information hours. today.
requested/generat needs
ed Normally the process of downloading the software
update occurs in the background and should defer to
more latency-sensitive applications.

Service Level [ms] Not Software updates themselves are not latency-sensitive.
Latency applicable

% 99 Software updates should successfully transfer reliably

but this can occur over an extended period as above.

Exceptions would be when a vehicle is persistently out-

Service Level of-range (for example, in long-term underground
Reliability parking), or only sporadically within range (such as a
farmer who only occasionally drives into town), in
which case priority may be given for a more rapid
download when they are in range.

[m/s] up to 19.4 This is a typical city speed, where it will be helpful to

Velocity (70 km/h) collect software updates over time. Note that a
consistent download rate is not required, since the
23
 24
download may collect parts of the software image as
available and pause and continue downloading as
needed.

[vehicle/km^ 1500 For instance, assuming an overall vehicle density of

2] vehicles/k 1500 vehicles/km^2, but only a fraction of these would
m^2 require a specific software update due to differing
vehicle manufacturers, vehicle platforms, on-board
< 15
equipment, and other factors.
vehicles/k
Vehicle Density m^2 We expect that <1% of vehicles would need a specific
typically software update at any given time.
need a
specific
update at a
time.

[m] 30 (1σ) It is typically enough for the network service provider

to identify in which street/road and approximate
position inside this street/road.
Positioning More precision could be helpful to validate that a
vehicle is safely parked before an update installation
begins, or whether it is within range of other
communications mechanisms (e.g., home Wi-Fi).

[yes/no] No / Yes / We expect individual vehicle manufacturers and 3rd

No party SW Update system developers will specify their
own software updates and this will not be
interoperable across manufacturers.

There may be regulatory requirements, and for

Interoperability/
conventional vehicles we rely on current expectations
Regulatory/
for updates, which typically require service by
Standardization
dealerships and may take months to schedule and
Required
implement.

Standardization could be helpful but is not required,

given the proprietary nature of updates and specific
architectural needs from different vehicle
manufacturers.

User Story Detailed description and specifics

Software
Update The “normal” case requiring a software update in an autonomous (self-driving) vehicle.
(Autonomous- The controlling party is asked for consent to install the software, potentially specifying
Routine)
preconditions (e.g., no passengers aboard, during off-peak hours, during next refueling /
recharging, etc).

24
 25
The software is downloaded securely and reliably, as coverage and bandwidth are
available. Its transmission must not adversely affect any safety-critical or user experience-
critical functions.

Software installation is a separate process that occurs when safe and the controlling party
conditions are met.

Software Update (Autonomous-Routine)

Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
Within In principle, the user story is applicable in the network
[m] network service provider coverage area.
Range service
provider
coverage
3GB within This is a conservative estimate of a current self-driving
Quality of 24 hours stack based on publicly-available information.
Information
information / Normally the process of downloading the software
requested/generat
Information update occurs in the background and should defer to
ed
needs more latency-sensitive applications.

Service Level Not Software updates themselves are not latency-

[ms] applicable
Latency sensitive.
99 Software updates should successfully transfer reliably
% but this can occur over an extended period as above.
Exceptions would be when a vehicle is persistently out-
Service Level of-range (for example, in long-term underground
Reliability parking), or only sporadically within range (such as a
farmer who only occasionally drives into town), in
which case priority may be given for a more rapid
download when they are in range.
19.4 (70 This is a typical city speed, where it will be helpful to
[m/s] km/h) collect software updates over time. Note that a
consistent download rate is not required, since the
Velocity
download may collect parts of the software image as
available and pause and continue downloading as
needed.
1500 For instance, assuming an overall vehicle density of
[vehicle/km^ vehicles/k 1500 vehicles/km^2, but only a fraction of these would
2] m^2 require a specific software update due to differing
< 15 vehicle manufacturers, vehicle platforms, on-board
vehicles/k equipment, and other factors.
Vehicle Density m^2 We expect that <1% of vehicles would need a specific
typically software update at any given time.
need a
specific
update at a
time.
30 (1σ) It is typically enough for the network service provider
Positioning [m] to identify in which street/road and approximate
position inside this street/road.

25
 26
More precision could be helpful to validate that a
vehicle is safely parked before an update installation
begins, or whether it is within range of other
communications mechanisms (e.g., home Wi-Fi).
No / Yes / We expect individual vehicle manufacturers and 3rd
[yes/no] No party SW Update system developers will specify their
own software updates and this will not be
interoperable across manufacturers.
There may be regulatory requirements, and for
conventional vehicles we rely on current expectations
for updates, which typically require service by
dealerships and may take months to schedule and
implement.
Interoperability/
However, the expectations for self-driving vehicles and
Regulatory/
corresponding regulations will require much greater
Standardization
urgency and may even include temporarily removing
Required an affected vehicle from normal driving operations.
Once the vehicle is parked, the urgency to apply the
software update depends on commercial concerns
such as the cost of vehicle downtime in an autonomous
fleet.
Standardization could be helpful but is not required,
given the proprietary nature of updates and specific
architectural needs from different vehicle
manufacturers.

User Story Detailed description and specifics

Software
Update Urgent need for critical software update in an autonomous (self-driving) vehicle. In this
(Autonomous- case, the first priority may be to order the vehicle to safely exit the roadway and park.
Urgent)
The controlling party is informed of a critical need for an update and agrees to the vehicle
state requirements to perform the download and update (e.g., in route or stopped,
passengers onboard or empty, etc.). With controlling party’s consent regarding the
conditions, the vehicle update is performed, which may require steps to stop in a safe
location and inform passengers on board. Once the controlling party agrees to the
conditions, the updates are downloaded to target vehicles, while necessary requirements
for update installation (like safely parking) are addressed in parallel.

If passengers are aboard, the controlling party (e.g., fleet operator) or vehicle informs
passengers of the situation and attends to their comfort and safety. For example, another
vehicle may be dispatched to carry the passengers to their destinations.

Assuming no passengers are aboard OR the download and installation can be completed
with high confidence quickly (within minutes), the software download and installation
proceed as in the routine case, but with a higher delivery priority (i.e. streaming or other
content downloads take lower priority).

In cases of longer update installation durations, passengers may be transferred to another

vehicle and the download will occur as if routine while the vehicle is parked. However, the
high cost of an expensive autonomous vehicle sitting idle while another is needed to deal
with passengers, or any time the update can be accomplished more quickly than the

26
 27
arrival of a replacement vehicle, make the “update while you wait” scenario more
compelling.

Software Update (Autonomous-Urgent)

Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] Within In principle, the use case is applicable in the network
network service provider coverage area.
Range service
provider
coverage

This is a conservative estimate for a current self-driving

Quality of 3GB within
stack based on publicly-available information.
Information information / 2 hours.
requested/generat Information
Normally the process of downloading the software
ed needs
update occurs in the background and should defer to
more latency-sensitive applications.

[ms] 10 minutes The most stringent requirement is to deliver the

to deliver “critical update required” message, especially in the
Service Level “critical case of an autonomous vehicle. But even this is in the
Latency update range of minutes.
required”
Software updates themselves are not latency-sensitive.
message

Software updates should successfully transfer reliably

% 99
but this can occur over an extended period as above.

Exceptions would be when a vehicle is persistently out-

Service Level of-range (for example, in long-term underground
Reliability parking), or only sporadically within range (such as a
farmer who only occasionally drives into town), in
which case priority may be given for a more rapid
download when they are in range.

[m/s] 69.4 (250 This is an allowed speed in some motorways and at

km/h) least the “critical update required” message should be
deliverable at any speed the vehicle is likely to travel.
Velocity
Ideally the download itself can be completed at this
speed. Once the vehicle is parked and secured,
installation can be completed over a longer period.

1500
[vehicle/km^ For instance, assuming an overall vehicle density of
vehicles/k
Vehicle Density 2] 1500 vehicles/km^2, but only a fraction of these would
m^2
require a specific software update due to differing

27
 28
< 15 vehicle manufacturers, vehicle platforms, on-board
vehicles/k equipment, and other factors.
m^2
We expect that <1% of vehicles would need a specific
typically
software update at any given time.
need a
specific
update at a
time.

[m] 30 (1σ) It is typically enough for the network service provider

to identify in which street/road and approximate
position inside this street/road.
Positioning More precision could be helpful to validate that a
vehicle is safely parked before an update installation
begins or whether it is within range of other
communications mechanisms (e.g., home Wi-Fi).

We expect individual vehicle manufacturers and 3rd

[yes/no] No / Yes /
party SW Update system developers will specify their
No
own software updates and this will not be
interoperable across manufacturers.

There may be regulatory requirements, and for

conventional vehicles we rely on current expectations
for updates, which typically require service by
dealerships and may take months to schedule and
implement.
Interoperability/
Regulatory/ However, the expectations for self-driving vehicles and
Standardization corresponding regulations will require much greater
Required urgency and may even include temporarily removing
an affected vehicle from normal driving operations.
Once the vehicle is parked, the urgency to apply the
software update depends on commercial concerns
such as the cost of vehicle downtime in an autonomous
fleet.

Standardization could be helpful but is not required,

given the proprietary nature of updates and specific
architectural needs from different vehicle
manufacturers.

User Story Detailed description and specifics

Software update delivery outside network service provider coverage. A vehicle is outside
Software
of V2I/V2N coverage and enters the C-V2X range of another vehicle with the appropriate
Update
software update available.

28
 29
(Without For example, two or more similar vehicles from the same managed fleet arrive in close
Infrastructure) proximity to transfer cargo, refuel / recharge, or for the explicit purpose of receiving an
update or other maintenance.

• Assumes a site outside network service or roadside infrastructure coverage

where at least two vehicles come into close proximity of each other.
• At least one vehicle (the “serving vehicle”) holds the appropriate software update
and can serve as a secure download server to the target vehicle(s).
• Before the software transfer is initiated, the system in the serving vehicle
identifies the target vehicle(s) and the need for software updates. This process
may be done through a bulletin published by the serving vehicle which identifies
vehicles needing specific updates.
• The driver (human or robot) is informed that a critical update is in progress and
that the vehicle should not be powered down or driven until update completion.
• The download must happen over a short period while the vehicles are in close
proximity of each other.

Software Update (Without Infrastructure)

Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
< 100m This user story assumes the vehicles are in close
[m]
Range between proximity.
vehicles
1.5GB This is a current-day example of a major OEM update
Quality of
Information image that would be manually updated and installed
information /
requested/generat today.
Information
ed
needs

Service Level 30 seconds The goal is to deliver updates vehicle-to-vehicle and

[ms]
Latency minimize disruption to their regular activity.
99 Software updates should successfully transfer
Service Level %
completely and reliably 99% of the time in the time
Reliability
desired above.
0 We assume the vehicles will be parked in close
Velocity [m/s]
proximity for this transfer.
1500 For instance, assuming an overall vehicle density of
[vehicle/km^
vehicles/k 1500 vehicles/km^2, but this is a Vehicle-to-Vehicle
2]
m^2 application for a “peer to peer” transfer.

Minimum Scenarios where one server delivers updates to

Vehicle Density
of 2 multiple targets at a time are also desirable.
vehicles
involved
(server and
target)
50 (1σ) Vehicles need to be in close proximity, and are
Positioning [m]
expected to identify each other directly.

29
 30
No / Yes / We expect individual vehicle manufacturers and 3rd
[yes/no]
No party SW Update system developers will specify their
own software updates and this will not be
interoperable across manufacturers.

There may be regulatory requirements, and for

Interoperability/
conventional vehicles we rely on current expectations
Regulatory/
for updates, which typically require service by
Standardization
dealerships and may take months to schedule and
Required
implement.

Standardization could be helpful but is not required,

given the proprietary nature of updates and specific
architectural needs from different vehicle
manufacturers.

User Story Detailed description and specifics

Software Software update delivery in a specific context, such as a dealership, workshop, or fleet
Update (Vehicle parking facility. A vehicle enters an area where “private” C-V2X capability / RSU can quickly
to Workshop) deliver a software update directly to the vehicle.

For example, a vehicle enters a workshop for a brief service such as changing tires or
replacing fluids, and relevant software updates are available. The software is delivered
quickly via a direct C-V2X connection while other services are performed. This reduces
total downtime and provides updates in a safe situation where technicians are available in
case of anomaly, taking advantage of close range and unlicensed spectrum.

• Assumes a controlled environment such as a dealership / workshop, fueling /

charging station, or fleet parking facility.
• The download must be completed quickly with the car stationary, with systems
powered on to handle the transfer and installation.
• The driver (human or robot) and technician (if applicable) are informed that a
critical update is in progress and that the vehicle should not be powered down or
driven until update completion.
• Before the software transfer is initiated, the secure local RSU identifies the target
vehicle(s) and the need for software updates. This process may be done through
a bulletin published by the RSU which identifies vehicles needing specific
updates.

Software Update (Vehicle to Workshop)

Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
< 100m Scenario is within a specific location and context as
Range [m]
between described.

30
 31
vehicle and
RSU
32GB This is a current-day example of a major OEM update
Quality of
Information package that today would be manually updated and
information /
requested/generat installed.
Information
ed
needs

Service Level 15 minutes The goal is to deliver updates while other minor
[ms]
Latency services such as tire changes are performed.
Service Level 99.9 Software updates should successfully transfer reliably
%
Reliability and within the desired timeframe.
0 We assume the vehicles will be parked during the
Velocity [m/s]
download.
1500 For instance, assuming an overall vehicle density of
[vehicle/km^
vehicles/k 1500 vehicles/km^2, but a maximum of 100 vehicles to
2]
m^2 be updated at any one time within the facility.

Vehicle Density Up to 100

vehicles
updated
simultaneo
usly
50 (1σ) Vehicles need to be in close proximity to the private C-
Positioning [m]
V2X RSU.
No / Yes / We expect individual vehicle manufacturers and 3rd
[yes/no]
No party SW Update system developers will specify their
own software updates and this will not be
interoperable across manufacturers.

There may be regulatory requirements, and for

Interoperability/
conventional vehicles we rely on current expectations
Regulatory/
for updates, which typically require service by
Standardization
dealerships and may take months to schedule and
Required
implement.

Standardization could be helpful but is not required,

given the proprietary nature of updates and specific
architectural needs from different vehicle
manufacturers.

4.6 Remote Vehicle Health Monitoring

User Story Detailed description and specifics

User Story #1 A vehicle is travelling on a highway and is losing air pressure in one or more of its tires. A
road or fleet operator needs to be made aware of the situation.

31
 32

User Story #1
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] N/A There is no concrete upper limit to the desired
range. The vehicle needs to convey the message to the
Range
road operator of fleet manager cloud which in most
cases is physically far away from the vehicle.

Quality of < 1KB The information must be timely and accurate. Since the
Information
information / information is safety related, it must be accurate.
requested/generat
Information
ed
needs

Service Level
[ms] < 30 sec Latency is not a critical factor.
Latency

Service Level % 99.99 It is critical that the information be sent and received
Reliability successfully.

[m/s] 69.4 Health monitoring related events and messages should

Velocity be able to be sent successfully at maximum highway
driving speeds (250 km/h).

[vehicle/km^ 12000 A vehicle that is on the verge of becoming stranded

2] due to a degrading condition should be able to
Vehicle Density
successfully send the information in a traffic congested
environment.

[m] 1.5 m (3σ) Since this information may be used to dispatch

assistance, the location of the vehicle must be known
Positioning within a lane width and within the vehicle’s length. 1.5
meters is the typical accuracy required to locate a
vehicle within a lane.

Interoperability/ [yes/no] Yes / Yes / Information should be standardized to enable road

Regulatory/ Yes operators to identify vehicles that are at risk of
Standardization becoming stranded and dispatch an appropriate level
Required of assistance.

4.7 Hazardous Location Warning

User Story Detailed description and specifics

HV only A Remote Vehicle (RV) is driving on the road and approaches a dangerous area which is
supported by detected by using RV’s sensors. The HV might drive behind the RV in the same direction,
RVs or in front of the RV in the opposite direction, so towards the area where the RV has

32
 33
detected the dangerous situation. RVs detecting such dangerous situations will broadcast
information about those with other vehicles, e.g., the HV.

The HV or HV driver can assume appropriate actions after having received the awareness
information.
HV receives This use case mainly refers to a Real Time HD Map update service. The HV is receiving
information information that is relevant for the road/route ahead from a backend, containing
from a information that might allow the HV to adjust its route accordingly. The traffic
backend/cloud management mentioned in ‘Other Actors’ roles’ could play a role here.

User Story #1 ( HV only supported by RVs)

Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] 300 – Communication is only done by vehicles in the vicinity
Range physical of the HV. It is limited to the range of physical
limit transmission.

Quality of 300 bytes Normal size of awareness messages (e.g., CAM, BSM)
information / should be enough, maybe containing fields indicating
Information
Information common types of critical situations that lie ahead.
requested/generat
needs Transmission of detailed object information is not
ed
needed. Standard transmission rate of 10 Hz should be
enough.

[ms] 100 Driving with 120 km/h, 300 m (minimum

Service Level communication range) will take just short of 10 s, so
Latency 100 ms for the car to react should be enough.

% 99 The HV could aggregate warnings from several RVs,

Service Level
each individual RVs reliability thus does not have to be
Reliability
too high.

[m/s] 69.4 250 km/h – Max speed on highways, also realistic for
Velocity relative speeds of HV and RV driving in different
directions.

[vehicle/km^ 12000 Maximum assumption on vehicle density.

2] (urban)
Vehicle Density 9000 (rural)

4500
(highway)

[m] 1.5 (3 Typical positioning accuracy to confirm traffic lane.

Positioning

33
 34
5 (1 For non-lane-specific information, less accurate
localization is acceptable.

Interoperability/
[yes/no] Yes / Yes / Inter-OEM-operability must be assured.
Regulatory/
Standardization Yes
Required

User Story #2 ( HV receives information from a backend/cloud )

Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] ~ 30 000 Situations are relevant along a navigation route or
Range along a road if a navigation route is not known.
Depends on the needs for efficient re-routing.

Quality of 300 – 1000 From the backend, the HV will receive information
Information
information / bytes (events, or vector data), not raw data. Some details are
requested/generat
Information needed, but still no need for detailed object
ed
needs descriptions or the like.

[ms] 1–2s Information may need to be aggregated from multiple

RVs before a situation is identified.1-2 s for safety-
/
Service Level related information concerning the vicinity of the HV;
Latency 10 – 200 s 10 – 200 s for general information about route
obstructions or the like further ahead, in order to make
timely rerouting possible.

% 99 For safety-related information, timely and reliable

communication is decisive.
Service Level In the backend, data of several vehicles is aggregated,
Reliability Low
so the single vehicle’s data has to be moderately
reliable. For rerouting information, this should be
enough.

Velocity [m/s] 69.4 250 km/h – Max speed on highways

[vehicle/km^ 12000 Maximum assumption on vehicle density.

2] (urban)
Vehicle Density 9000 (rural)

4500
(highway)

[m] 1.5 (3 Typical positioning accuracy to confirm traffic lane.

Positioning 5 (1 For non-lane-specific information, less accurate
localization is acceptable.

34
 35
Interoperability/
[yes/no] Yes / Yes / Inter-vendor-operability must be assured.
Regulatory/
Standardization Yes
Required

4.8 Speed Harmonization

User Story #1
(In user story#1, we assume human driver drives HV which would then result in taking human reaction time
into account for SLR calculation.)
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] 123/59/26 This value is calculated as concatenation of braking
distance of HV and 𝑑𝑅𝑉𝑓 . 𝑑𝑅𝑉𝑓 . It can be derived from
the typical braking distance formula with velocity of
stationary vehicles (i.e. RV).

Braking distance formula = (Human reaction

time)*velocity + velocity^2/(2μg).

Range where μ represents the coefficient of friction and g

represents gravitational acceleration. In order to
acquire sample values, we used the following
assumptions.

μ = 0.8

g = 9.8 [m/s^2]

Human Reaction Time = 1.0 [s]

Quality of Informatio Information may be processed locally by HV to

information / n about determine harmonized speed (if only dependent on
Information RV(s) RV(s) speed/position).
needs speed/posit
Information may be processed by external entity that
ion
determines recommended speed to advise HV about.
Informatio
Information Assuming 300bytes is enough to carry speed and
n to HV
requested/generat location information.
about
ed
recommen
ded speed

(Maximum
300 bytes
for payload
size)

Service Level [ms] 2500/1800 Latency should be low enough to allow a smooth
Latency /1400 adjustment, collisions could be prevented by on-board

35
 36
sensors or other means. Exact value can be derived
from 𝑑𝑅𝑉𝑓 divided by speed gap between HV and RV.

Service Level % 80 This should be relatively lower than the value for other
Reliability safety critical use cases.

[m/s] Highway: Assuming typical maximum allowed speeds and some

69.4 safety margin.
Velocity
Rural: 33.3

Urban: 19.4

[vehicle/km^ 12000 Max assumed density in urban situation.

Vehicle Density
2]

[m] 1.5 (3 Same as other scenario which requires lane level
Positioning positioning accuracy, assuming different speed limit is
applicable per lane.
Interoperability/
[yes/no] Yes / Yes / Interoperability between manufacturers’
Regulatory/
Standardization Yes implementations to be guaranteed by standardization.
Required

User Story #2
(In user story#2, we assume HV is highly automated, therefore human reaction time does not have to be
considered at all.)
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] 59/23/8 This value is calculated as concatenation of braking
distance of HV and 𝑑𝑅𝑉𝑓 . 𝑑𝑅𝑉𝑓 can be derived by
typical braking distance formula with velocity of
stationary vehicle(i.e. RV).

Braking distance formula = (Human reaction

time)*velocity + velocity^2/(2μg)
Range where μ represents coefficient of friction and g does
gravitational acceleration. In order to acquire sample
values, we used following.

μ = 0.8

g = 9.8 [m/s^2]

Human Reaction Time = 0 [s]

Information Quality of Informatio Information may be processed locally by HV to

requested/generat information / n about determine harmonized speed (if only dependent on
ed RV(s) RV(s) speed/position).

36
 37
Information speed/posit Information may be processed by external entity that
needs ion determines recommended speed to advise HV about.

Informatio Assuming 300bytes is enough to carry speed and

n to HV location information.
about
recommen
ded speed

(Maximum
300 bytes
for payload
size)

[ms] 1500/800/ Latency should be low enough to allow a smooth

400 adjustment, collisions could be prevented by on-board
Service Level
sensors or other means. . The exact value can be
Latency
derived from 𝑑𝑅𝑉𝑓 divided by the speed gap between
HV and RV.

Service Level % 80 This should be relatively lower than the value for other
Reliability safety critical use cases.

[m/s] Highway: Assuming typical maximum allowed speeds and some

69.4 safety margin.
Velocity
Rural: 33.3

Urban: 19.4

[vehicle/km^ 12000 Max assumed density in urban situation.

Vehicle Density
2]

[m] 1.5 (3 Same as other scenarios which require lane level
Positioning positioning accuracy, assuming different speed limits
are applicable per lane.
Interoperability/
[yes/no] Yes / Yes / Interoperability between manufacturers’
Regulatory/
Standardization Yes implementations to be guaranteed by standardization.
Required

4.9 High Definition Sensor Sharing

User Story #1
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
40m is approximately 2s driving time at 160km/h,
[m] Min. 80
Range which should provide enough time for sensor sharing
negotiation.

37
 38

Quality of numerical Processed and unprocessed data may be exchanged

information /
Information Near zero error rate tolerance (after error correction)
Information
requested/generat on transmission link is required.
needs
ed
Max 1000 bytes packet size (processed data). Larger
for un-processed data.

[ms] 10 Lowest possible latency is needed to reduce reaction

Service Level times of HV and RV.
Latency 10ms is considered realistically achievable in 3GPP Rel-
16.

Service Level % 99.9 Very high, the reliability here should be sufficient to
Reliability guarantee QoS (whole system).

Velocity [m/s] 69.4 Max highway speed assumed to be 250km/h.

[vehicle/km^ 12000 Max assumed density in urban situation

Vehicle Density
2]

[m] 0.1 (3) Relative between two vehicles. High accuracy is

Positioning
required to avoid collision.

Interoperability/ [yes/no] Yes / Yes / Interoperability between manufacturers’

Regulatory/ Yes implementations to be guaranteed by standardization.
Standardization Processed sensor data shall be understandable
Required between different manufactures’ implementations.

4.10 See-Through for Pass Maneuver

User Story #1
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] 100 As the two vehicles concerned in the exchange of visual
information are driving in the same lane, the
Range
communication range is: from 50 to 100 meters,
considering a legal headway of 2 seconds.

Quality of 15 Mbps Video Streaming.

information /
Information 15 Mbps are needed to transmit a progressive high
Information
requested/generat definition video signal with resolution 1280x720, frame
needs
ed rate 30 Hz, colour depth 8 bit, 24 bit resolution,
subsampling [Link] and a typical compression of 1:30
(e.g., with H.264).

38
 39

[ms] 50 The latency requirement for a video frame depends on

the vehicle speed and heading as well as pitch angle
changes. Latency of 50 ms should be kept, lower values
would increase the experience of this function.
Additional delays would lead to additional buffering in
the rear vehicle.

50ms is the considered e2e communication layer

latency, without including application layer processing
times e.g., coding, de-coding.

Additional Latency requirements

• The duration of service discovery phase

should be in maximum 500ms (i.e. time
duration for HV to identify if RV supports the
see-through service).Service Discovery
includes the communication establishment
Service Level phase (i.e., receive resources) as well as the
Latency discovery request and discovery response
messages that HV and RV send, respectively.

• The see-through establishment phase (i.e., a)

HV asks for see-through and b) RV provides
the first video frame) should complete in
maximum within 500ms.

Service Discovery and see-through

establishment within 1000ms will help the
driver of the HV to activate the requested see-
through service quickly and take a fast
decision whether to proceed within the
overtake action. This also affects the
engagement of the driver with the see-
through application

• The see-through release phase should be

complete in maximum within 500ms.

% 99 Reliability 99% at the communication layer of for video

frames is needed to avoid massive artefacts that may
Service Level lead to degradation of video quality for assisted driving.
Reliability The video will be used to distinguish objects, front
vehicles etc in order to support driver’s decision to
realize an overtake or not.

[m/s] 33.3 (120 This is the maximum speed limit for non-urban streets
km/h) (i.e. not highways).120 km/h is the maximum speed of
Velocity the HV and RV.

39
 40
Note: The transmitter of the video and the vehicle
receiving the information will be more or less at the
same speed 0 to 30 km/h (relative velocity).

[vehicle/km^ 9000 This type of service is most probable to be used in rural

Vehicle Density 2] road environments.

2 vehicles are involved in this use cases.

[m] 1.5 (3) A positioning accuracy to know HV’s and RV’s location
Positioning
(including direction) and lane.

[yes/no] Yes / Yes / Interoperability is needed between the vehicles that

Interoperability/ Yes participate in the see-through service.
Regulatory/
Standardization Regulatory oversight for safety-related issues is
Required needed. Standardization on the application layer
(message set and flow control).

4.11 Lane Change Warning

User Story #1
(Lane change warning – lagging vehicle{:RV1_v>HV_v}, High Way)
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] 83 The range is derived from the different between HV
Range
(100kmh) and RV1 (120kmh) speeds.

Quality of Approx. Speed, Global Navigation Satellite System (GNSS)

Information information / 300 bytes location, past trajectory, turn sign ON and side, like
requested/generat Information per awareness frame messaging (e.g., BSM).
ed needs message /
high QoS

Service Level [ms] 400 Depend on the number of repetitions and message
Latency cadence.

% 99.9 A service level reliability this high should be enough to

Service Level allow perceived zero-error appearance of the lane
Reliability change. False positives are more problematic than false
negatives.

[m/s] HV (28) Varies between rural, urban and highway. But more
Velocity RV1 (33) important for this UC is the speed different between
the HV and RV

40
 41

[vehicle/km^ 4500 Maximum considered density for a highway road

Vehicle Density
2] environment.

[m] 1.5 (3 In order to perform lane-accurate positioning, a

Positioning positioning accuracy of around 1.5m should be
provided.

[yes/no] Yes / Yes / Interoperability between different OEMs is needed.

Interoperability/ Yes It should be regulated that every vehicle has to make
Regulatory/ its presence known periodically (as a broadcast).
Standardization Standardization is required in the sense that the format
Required for trajectories should be common to all so that they
can be understood by all.

User Story #2
(Lane change warning –leading vehicle {: HV_v>RV2_v}, Urban)
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] 28 The range is derived from the different between the
Range
HV and RV speeds.

Quality of Approx. Speed, GNSS location, past trajectory, turn sign ON and
Information information / 300 bytes side, like awareness frame messaging (e.g., BSM).
requested/generat Information per
ed needs message /
high QoS

Service Level [ms] 400 Depend on the number of repetitions and message
Latency cadence.

% 99.9 A service level reliability this high should be enough to

Service Level allow perceived zero-error appearance of the lane
Reliability change. False positives are more problematic than false
negatives.

[m/s] RV2 (11) Varies between rural, urban and highway. But more
Velocity important for this UC is the speed different between
HV (14)
the HV and RV.

[vehicle/km^ 12000 Maximum considered density for an urban road

Vehicle Density
2] environment.

[m] 1.5 (3 In order to perform lane-accurate positioning, a

Positioning positioning accuracy of around 1.5m should be
provided.

41
 42

[yes/no] Yes / Yes / Interoperability between different OEMs is needed.

Interoperability/ Yes It should be regulated that every vehicle has to make
Regulatory/ its presence known periodically (as a broadcast).
Standardization Standardization is required in the sense that the format
Required for trajectories should be common to all so that they
can be understood by all.

User Story #3
(Lane change warning –Not Permitted {: T_Maneuver>T_safe}, Rural)
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] 51 The range is derived from the different between the
Range
HV and RV speeds,

Quality of Approx. Speed, GNSS location, past trajectory, turn sign ON and
Information information / 300 bytes side, like awareness frame messaging (e.g., BSM).
requested/generat Information per
ed needs message /
high QoS

Service Level [ms] 400 Depend on the number of repetitions and message
Latency cadence.

% 99.9 A service level reliability this high should be enough to

Service Level allow perceived zero-error appearance of the lane
Reliability change. False positives are more problematic than false
negatives.

[m/s] HV (23) Varies between rural, urban and highway. But more
Velocity important for this UC is the speed different between
the HV and RV.

[vehicle/km^ 9000 Maximum considered density for a rural road

Vehicle Density
2] environment.

[m] 1.5 (3 In order to perform lane-accurate positioning, a

Positioning positioning accuracy of around 1.5m should be
provided.

[yes/no] Yes / Yes / Interoperability between different OEMs is needed.

Interoperability/ Yes It should be regulated that every vehicle has to make
Regulatory/ its presence known periodically (as a broadcast).
Standardization Standardization is required in the sense that the format
Required for trajectories should be common to all so that they
can be understood by all.

42
 43
4.12 Vulnerable Road User

User Story Detailed description and specifics

Awareness of This VRU user story describes a scenario in which a presence warning at crossings and
the presence of spots without line-of-sight (LOS), e.g., automatic detection of pedestrians waiting and/or
VRUs near crossing from infrastructure is intended. VRUs are watched via infrastructure support as
potentially surveillance cameras / wireless detection mechanisms and/or are equipped with mobile
dangerous VRU devices (UE). Awareness notifications are shared with drivers e.g., via roadside units /
situations monitoring system attached to a 3GPP system (e.g., potentially using MEC) sending
messages to drivers or drivers C-ITS systems monitor actively VRUs that are equipped with
a device.

The User Story involves one or multiple vehicles and it assumes V2I and/or V2P
connectivity.

In this user story a vehicle has entered an area in which VRUs are present.

- The area could be crossings (incl. cross-walks, zebra crossings) and spots without
line-of-sight (LOS)
- VRUs are watched via infrastructure support as surveillance cameras / wireless
detection mechanisms and/or are equipped with mobile VRU devices (UE).
- Awareness notifications are shared with driver’s e.g.,
o via roadside units or
o via monitoring systems attached to a 3GPP system (extension of user
story e.g., potentially using MEC) sending messages to drivers or
vehicle’s C-ITS systems monitor actively VRUs that are equipped with a
device.

Collision risk This VRU user story describes a scenario in which a collision prevention at crossings and
warning spots without LOS, e.g., automatic detection of pedestrians waiting and/or crossing from
infrastructure is intended.

In this VRU user story the accuracy, performance and functionality of VRU devices incl.
UEs is sufficient for collision risk detection, and vehicles share the information collected by
sensors with each other.

Vehicles have entered an area in which VRUs are present.

- The area could be crossings (incl. cross-walks, zebra crossings) and spots without
line-of-sight (LOS)
- VRUs are watched via infrastructure support as surveillance cameras / wireless
detection mechanisms and/or are equipped with mobile VRU devices (UE).
- VRUs are watched via information collected by vehicles sensors and relevant
information is shared with other vehicles and/or road site units.
- Warning notifications are shared with driver’s e.g.,
o via roadside units or
o via monitoring systems attached to a 3GPP system (e.g., potentially
using MEC) sending messages to drivers
o other vehicle’s C-ITS system based on sensor data
o vehicle’s C-ITS systems monitoring actively VRUs that are equipped with
a device.
43
 44
- Cooperative actions and maneuvers are enabled via cooperative message
exchange in a bi-directional manner.

User Story #1
(Awareness of the presence of VRUs near potentially dangerous situations)
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] Min. 80 1. For long distances we expect local sensors of the
vehicle (electronic horizon) to be able to resolve
a) Urban
VRU protection scenarios.
150
2. We do not foresee that a full stop will be feasible
Range b) Rural
in most VRU protection scenarios. It is rather to
300
trigger an obstacle avoidance maneuver.
Therefore, 40m are roughly 2s driving time when
driving with 80km/h should provide enough time
to trigger an appropriate event.

Quality of Surveillanc Surveillance: The data rate depends strongly on the

information / e: medium capabilities of the different C-ITS systems to process
Information quality received RAW data and generate information data. To
Information needs allow all “sensor detected” data being shared we
requested/generat recommended initially a higher data rate. The end goal
ed Safety: very is to communicate only information/processed data.
high
Safety: Vehicle needs information on the precise
location of the VRUs in its vicinity and its own position
in the near future.

[ms] 100 This is the maximum latency tolerable for allowing for a
reaction due moving VRUs very near the road.

20 ms for VRU communication latency are comparable

Recommen
to that of cooperative maneuvers and sensor sharing
ded
because we see that the VRU situations will occur
communica
Service Level much more unexpected and in close proximity to the
tion
Latency vehicle. Thus, longer communication latencies would
latency: 20
be adversarial to the intended purpose.

Example for justification: For a 50 km/hr drive in dense

urban environments (80m communication radius), the
total time budget until a potential complete stop has to
be initiated is approximately 3.96 sec.

% 99.9 High, the reliability here should be sufficient to

Service Level guarantee QoS. 99.9% should be sufficient, since
Reliability additional vehicle sensors are in place that can help to
avoid collisions.

44
 45

[m/s] Urban: 19.4 In urban areas, considering 70 km/h max speed.

Velocity
Rural: 33.3 In rural areas, considering 120 km/h max speed.

[vehicle/km^ Concerned Figures given only for urban areas, since we consider
2] VRUs: ~300 this one as the more critical case with regards to
total vehicle number/density.
Concerned VRUs are the ones near streets, not
Present
counting workers in offices or the like. However, for
Vehicle Density VRUs per
total network load, etc., all VRUs in the given area have
km^2:
to be considered, that is as many as the network can
~10000
support.
Vehicles:
1500

[m] 1m (3 In order to correct positioning based on GNSS (e.g.,

GPS, Galileo), this accuracy should be enhanced via the
3GPP System.
Positioning
The 3GPP System shall provide a positioning accuracy
of 1 – 2 m, e.g., considering support of GNSS, highly
accurately positioned RSU and CV2X UEs.

[yes/no] Yes / Yes / In order to make it possible to share information and

Interoperability/
Yes data on VRUs between vehicles, inter-OEM-operability
Regulatory/
should be guaranteed. Interoperability of UEs with
Standardization
RSUs, vehicles, and other local entities should be also
Required
guaranteed.

User Story #2
(Collision risk warning)
Service level SLR Unit SLR Value Explanations/Reasoning/Background
Requirement
[m] Min. 80 1. Limited range for calculations = 80m, since this is
the communication range in highly-dense
a) Urban
metropolitan areas.
150
2. For longer-distances we expect other local sensors
b) Rural
of the vehicle (electronic horizon) to be able to
300
assist in VRU protection scenarios.
Range
3. We do not foresee that a full stop will be feasible
in most VRU protection scenarios. It is rather to
trigger an obstacle avoidance maneuver.
Therefore, 40m are roughly 2s driving time when
driving with 80km/h should provide enough time
to trigger an appropriate event.

45
 46

Quality of Surveillanc Surveillance: The data rate depends strongly on the

information / e: medium capabilities of the different C-ITS systems to process
Information quality received RAW data and generate information data. To
Information needs allow all “sensor detected” data being shared we
requested/generat recommended initially a higher data rate.
ed Safety: very
Safety: Vehicle needs information on the precise
high
location of the VRUs in its vicinity and its own position
in the near future.

[ms] 100 This is the maximum latency tolerable for allowing for a
reaction due moving VRUs very near the road.

20 ms for VRU communication latency are comparable

Recommen
to that of cooperative maneuvers and sensor sharing
ded
because we see that the VRU situations will occur
communica
much more unexpected and in close proximity to the
Service Level tion
vehicle. Thus, longer communication latencies would
Latency latency: 20
be adversarial to the intended purpose.

Example for justification: For a 50 km/hr drive in dense

urban environments (80m communication radius), the
total time budget until a potential complete stop has to
be initiated is approximately 3.96 sec.

% 99.9 High, the reliability here should be sufficient to

Service Level guarantee QoS. 99.9% should be sufficient, since
Reliability additional vehicle sensors are in place that can help to
avoid collisions.

[m/s] Urban: 19.4 In urban areas, considering 70 km/h max speed.

Velocity
Rural: 33.3 In rural areas, considering 120 km/h max speed.

[vehicle/km^ Concerned Figures given only for urban areas, since we consider
2] VRUs: ~300 this one as the more critical case with regards to
total vehicle number/density.
Concerned VRUs are the ones near streets, not
Present
counting workers in offices or the like. However, for
Vehicle Density VRUs per
total network load, etc., all VRUs in the given area have
km^2:
to be considered.
~10000

Vehicles:
1500

[m] 0.5m (3 In order to correct positioning based on GNSS (e.g.,

Positioning GPS, Galileo), this accuracy should be enhanced via the
3GPP System.

46
 47
The 3GPP System shall provide a positioning accuracy
of 0.5 m, e.g., considering support of GNSS, highly
accurately positioned RSU and CV2X UEs.

[yes/no] Yes / Yes / In order to make it possible to share information and

Yes data on VRUs between vehicles, inter-OEM-operability
Interoperability/ should be guaranteed. Interoperability of UEs with
Regulatory/ RSUs, vehicles, and other local entities should be also
Standardization guaranteed.
Required Sharing information collected by sensor data form
vehicles passing / approaching the area where VRUs
are present references UC T-170339

5.0 Conclusions and Next Steps

This document presented an example set of C-V2X use case descriptions, the service level requirements and the
corresponding framework developed in WG1 for the description of solution agnostic use cases and service level
requirements.

5GAA WG1 continues to work on more advanced C-V2X use cases with complex interactions and more advanced
protocols. These use cases have challenging requirements for future communication systems, such as 5G, and
are applicable to both driven and autonomous vehicles, some examples are: “Group Start”, “Tele-Operated
Driving”, “Tele-Operated Driving Support”, “Tele-operated Driving for Automated Parking”, “Obstructed View
Assist”, “Cooperative Maneuver of Autonomous Vehicles for Emergency Situations”, “Continuous Traffic Flow
via Green Lights Coordination”, “Remote Automated Driving Cancellation (RADC)”, “High definition map
collecting & sharing”, “Automated Intersection crossing”, “Autonomous vehicles parking by automated Driving”,
“In-Vehicle Entertainment (IVE) – High Definition Content Delivery, On-line Gaming and Virtual Reality”.

47
 48
Annex <A>
A.1 Use Case Description Template
The following table presents the template for detailed description of C-V2X use cases with the
corresponding explanation of the different fields.

Template for Use Case Descriptions

Fields Description
Use Case Name Name and abbreviation of the use case if existing
Many user stories can be defined for a single use case. Additionally, different
User Story/Use Case user stories could lead to the same requirements and the same system
Scenario solution. It is not necessary and likely not practical to define all the user
stories initially and it is expected that more user stories can be added later.
Safety | Vehicle Operations Management | Convenience | Autonomous
Category driving | Platooning | Traffic Efficiency and Environmental friendliness |
Society and Community
Road Environment Intersection | Urban | Rural | Highway | Other
Short Description Short description of the use case
Drivers, vehicles, traffic lights, VRUs, Remote operators, Application Servers,
…. including defining who the sending and receiving actor is (human, vehicle,
Actors or AV – automated vehicle, e.g., SAE Automation levels 1-5 that are
considered for the specific use case and that may affect the performance
requirements).
Vehicle Roles Host Vehicle (HV) | Remote Vehicle (RV)
Road & Roadside Role of the road and traffic infrastructure (e.g., traffic signs, lights, ramps,
Infrastructure Roles etc.). Does not refer to the network infrastructure.
Other Actors’ Roles The Role of other actors that are involved in this use case (e.g., VRU)
Goal Goal of the use case.
Needs The needs to be fulfilled in order to enable the use case.
Constraints /
Basic requirements that all actors need to adhere to.
Presumptions
Geographic Scope Geographic areas where the use case is applicable.
Pictorial information exemplifying the use case and showing the role of the
Illustrations
different actors.
Necessary capability of the different actors to ensure the realization of the
Pre-Conditions
use case.
Flow of events from the moment the use cases is triggered to the moment
Main Event Flow the use case closes. Includes the trigger point to enter and to exit the use
case (i.e., who and what).
Alternative flow of events in case a different possibility exists.
Alternative Event Alternative Event Flows in this document are not intended as replacements
Flow for the Main Event Flow. They are intended to represent different possible
flows.
Post-Conditions Description of the output of flow clarifies which data is provided to the HV.

48
 49
• Note1: This data will trigger implementation specific actions in the HV
• Note 2: This shall also be contained in the field information
requirements
Information High level description of information exchanged among involved actors (e.g.,
Requirements sensor data, kinematic data, …)

A.2 Detailed Description of Example C-V2X Use Cases

Cross-Traffic Left-Turn Assist

Use Case Name Cross-Traffic Left-Turn Assist

Assist HV attempting to turn left across traffic approaching from the
User Story
opposite, left, or right direction.
Category Safety, Autonomous Driving
Intersections, mostly for rural and outer city intersections, big
Road Environment
metropolitan intersections to a lesser extent.
Alerts HV attempting to turn left across traffic of an RV approaching from
Short Description
the opposite direction in the lanes that HV needs to cross.
• Host Vehicle (HV)
• Remote Vehicle 1 (RV1)
Actors
• Remote Vehicle 2 (RV2)
• Remote Vehicle 3 (RV3)
• HV represents the vehicle stopped at intersection.
• RV1 represents cross-traffic vehicle approaching from the right.
Vehicle Roles
• RV2 represents cross-traffic vehicle approaching from the left.
• RV3 represents oncoming-traffic vehicle.
• Roads are defined by their lane designations and geometry.
• Intersections are defined by their crossing designations and
geometry.
Roadside
• Traffic lights and stop signs control right of way traffic flow
Infrastructure Roles
through an intersection (if available).
• Local Traffic laws and rules control right of way through 3-way
stops, 4-way stops and unsigned intersections.
Other Actors’ Roles Not applicable
• Avoid a lateral collision between HV and RV1.
Goal • Avoid a lateral collision between HV and RV2.
• Avoid an oncoming collision between HV and RV3.
• HV needs to know if there is a risk of collision with RV1
approaching from the right.
• HV needs to know if there is a risk of collision with RV2
Needs
approaching from the left.
• HV needs to know if there is a risk of collision with an oncoming
RV3.
• RV1’s intended direction through the intersection is known or can
Constraints / be guessed based on past values.
Presumptions • RV2’s intended direction through the intersection is known or can
be guessed based on past values.

49
 50
• RV3’s intended direction through the intersection is known or can
be guessed based on past values.
Geographic Scope Global
Illustrations

• HV is stopped at or moving towards an intersection.

• HV signals its intention to turn left.
Pre-Conditions • The “Adjacent Traffic from the Right” scenario application zone is
determined from:
o HV’s location

50
 51
o lane designations and geometry
o intersection geometry
o posted speed limits
o Road Conditions (if available)
• The “Adjacent Traffic from the Left” scenario application zone is
determined from:
o HV’s location
o lane designations and geometry
o intersection geometry
o posted speed limits
o Road Conditions (if available)
• The “Oncoming Traffic” scenario application zone is determined
from:
o HV’s location
o lane designations and geometry
o intersection geometry
o posted speed limits
o Road Conditions (if available)
• RV1 is in the “Adjacent Traffic from the Right” scenario
application zone
• If RV1 has the right of way;
o RV1’s trajectory through the intersection is estimated
using;
▪ RV1’s location and dynamics
▪ RV1’s turn signal state
▪ Lane designations and geometry
▪ Intersection geometry
o HV’s trajectory through the intersection is estimated
using;
▪ HV’s location
▪ HV’s estimated acceleration
▪ Lane designations and geometry
Main Event Flow ▪ Intersection geometry
o If there is a risk of collision based on the estimated
trajectories of HV and RV1 then;
▪ HV is warned of a risk of collision with RV1
approaching from the right.
• Otherwise if HV has the right of way;
o RV1’s stopping distance is estimated using;
▪ RV1’s location and dynamics
▪ Lane designations and geometry
▪ Intersection geometry
▪ Road Conditions (if available)
o If there is a risk that RV1 cannot stop before the
intersection;
• HV is warned of a risk of collision with RV1 approaching from the
right.
• RV2 is in the “Adjacent Traffic from the Left” scenario application
Alternative Event
zone
Flow
• If RV2 has the right of way;
51
 52
o RV2’s trajectory through the intersection is estimated
using;
▪ RV2’s location and dynamics
▪ RV2’s turn signal state
▪ Lane designations and geometry
▪ Intersection geometry
o HV’s trajectory through the intersection is estimated
using;
▪ HV’s location
▪ HV’s estimated acceleration
▪ Lane designations and geometry
▪ Intersection geometry
o If there is a risk of collision based on the estimated
trajectories of HV and RV2 then;
▪ HV is warned of a risk of collision with RV2
approaching from the left.
• Otherwise if HV has the right of way;
o RV2’s stopping distance is estimated using;
▪ RV2’s location and dynamics
▪ Lane designations and geometry
▪ Intersection geometry
▪ Road Conditions (if available)
o If there is a risk that RV2 cannot stop before the
intersection;
HV is warned of a risk of collision with RV2 approaching from the left.
• RV3 is in the “Oncoming Traffic” scenario application zone
• If RV3 has the right of way;
o RV3’s trajectory through the intersection is estimated
using;
▪ RV3’s location and dynamics
▪ RV3’s turn signal state
▪ Lane designations and geometry
▪ Intersection geometry
o HV’s trajectory through the intersection is estimated
using;
▪ HV’s location
▪ HV’s estimated acceleration
Post-Conditions ▪ Lane designations and geometry
▪ Intersection geometry
o If there is a risk of collision based on the estimated
trajectories of HV and RV3 then;
▪ HV is warned of a risk of collision with oncoming
RV3.
• Otherwise if HV has the right of way;
o RV3’s trajectory and stopping distance is estimated using;
▪ RV3’s location and dynamics
▪ RV3’s turn signal state
▪ Lane designations and geometry
▪ Intersection geometry
▪ Road Conditions (if available)
52
 53
o If there is a risk that RV3 cannot stop before the
intersection;
• HV is warned of a risk of collision with oncoming RV3.
• HV’s location.
• HV’s turn signal state.
• HV’s estimated acceleration from stopped.
• RV1’s location and dynamics.
• RV1’s turn signal state.
• RV2’s location and dynamics.
• RV2’s turn signal state.
Information • RV3’s location and dynamics.
Requirements • RV3’s turn signal state.
• Lane designations and geometry.
• Intersection geometry.
• Traffic stop signs.
• Traffic light signal phase and timing.
• Traffic rules and laws for 3-way stops, 4-way stops and unsigned
intersections.
• Current Road Conditions (if available)

Intersection Movement Assist

Use Case Name Intersection Movement Assist

User story Stationary HV proceeds straight from stop at an intersection. HV is
alerted if it is unsafe to proceed through the intersection.
Category Safety, Autonomous Driving
Road environment Intersections
Short Description Alerts HV that is stopped and intending to proceed straight through the
intersection of:

• approaching cross-traffic from the left

• approaching cross-traffic from the right
• oncoming traffic intending to turn left
Actors • Host Vehicle (HV)
• Remote Vehicle 1 (RV1)
• Remote Vehicle 2 (RV2)
• Remote Vehicle 3 (RV3)
Vehicle roles • HV represents the vehicle stopped at intersection.
• RV1 represents cross-traffic vehicle approaching from the left.
• RV2 represents cross-traffic vehicle approaching from the right.
• RV3 represents oncoming-traffic vehicle.
Road & Roadside • Roads are defined by their lane designations and geometry.
infrastructure roles • Intersections are defined by their crossing designations and
geometry.
• Traffic lights and stop signs control right of way traffic flow
through an intersection (if available).
• Local Traffic laws and rules control right of way through 3-way
stops, 4-way stops and unsigned intersections.

53
 54
Other Actors’ roles Not applicable
Goal • Avoid a lateral collision between HV and RV1.
• Avoid a lateral collision between HV and RV2.
• Avoid an oncoming collision between HV and RV3.
Needs • HV needs to know if there is a risk of collision with RV1
approaching from the left.
• HV needs to know if there is a risk of collision with RV2
approaching from the right.
• HV needs to know if there is a risk of collision with an oncoming
RV3.
Constraints / • The acceleration of HV from stopped must be assumed.
Presumptions • RV1’s intended direction through the intersection is known.
• RV2’s intended direction through the intersection is known.
• RV3’s intended direction through the intersection is known.
Geographic Scope Global

Illustrations

54
 55

Pre-Conditions • HV is stopped at an intersection.

• The “Adjacent Traffic from the Left” scenario application zone is
determined from:
o HV’s location
o lane designations and geometry
o intersection geometry
o posted speed limits
o Road Conditions (if available)
• The “Adjacent Traffic from the Right” scenario application zone is
determined from:
o HV’s location
o lane designations and geometry
o intersection geometry
o posted speed limits
o Road Conditions (if available)
• The “Oncoming Traffic” scenario application zone is determined
from:
o HV’s location
o lane designations and geometry
o intersection geometry
o posted speed limits
o Road Conditions (if available)
Main Event Flow • RV1 is in the “Adjacent Traffic from the Left” scenario application
zone
• If RV1 has the right of way;
o RV1’s trajectory through the intersection is estimated
using;
▪ RV1’s location and dynamics
▪ RV1’s turn signal state
▪ Lane designations and geometry
▪ Intersection geometry
o HV’s trajectory through the intersection is estimated
using;
▪ HV’s location
▪ HV’s estimated acceleration
▪ Lane designations and geometry
55
 56
▪ Intersection geometry
o If there is a risk of collision based on the estimated
trajectories of HV and RV1 then;
▪ HV is warned of a risk of collision with RV1
approaching from the left.
• Otherwise if HV has the right of way;
o RV1’s stopping distance is estimated using;
▪ RV1’s location and dynamics
▪ Lane designations and geometry
▪ Intersection geometry
▪ Road Conditions (if available)
o If there is a risk that RV1 cannot stop before the
intersection;
▪ HV is warned of a risk of collision with RV1
approaching from the left.
Alternative Event • RV2 is in the “Adjacent Traffic from the Right” scenario
Flow application zone
• If RV2 has the right of way;
o RV2’s trajectory through the intersection is estimated
using;
▪ RV2’s location and dynamics
▪ RV2’s turn signal state
▪ Lane designations and geometry
▪ Intersection geometry
o HV’s trajectory through the intersection is estimated
using;
▪ HV’s location
▪ HV’s estimated acceleration
▪ Lane designations and geometry
▪ Intersection geometry
o If there is a risk of collision based on the estimated
trajectories of HV and RV2 then;
▪ HV is warned of a risk of collision with RV2
approaching from the right.
• Otherwise if HV has the right of way;
o RV2’s stopping distance is estimated using;
▪ RV2’s location and dynamics
▪ Lane designations and geometry
▪ Intersection geometry
▪ Road Conditions (if available)
o If there is a risk that RV2 cannot stop before the
intersection;
▪ HV is warned of a risk of collision with RV2
approaching from the right.
Alternative Event • RV3 is in the “Oncoming Traffic” scenario application zone
Flow • If RV3 has the right of way;
o RV3’s trajectory through the intersection is estimated
using;
▪ RV3’s location and dynamics
▪ RV3’s turn signal state
56
 57
▪ Lane designations and geometry
▪ Intersection geometry
o HV’s trajectory through the intersection is estimated
using;
▪ HV’s location
▪ HV’s estimated acceleration
▪ Lane designations and geometry
▪ Intersection geometry
o If there is a risk of collision based on the estimated
trajectories of HV and RV3 then;
▪ HV is warned of a risk of collision with oncoming
RV3.
• Otherwise if HV has the right of way;
o RV3’s trajectory and stopping distance is estimated using;
▪ RV3’s location and dynamics
▪ RV3’s turn signal state
▪ Lane designations and geometry
▪ Intersection geometry
▪ Road Conditions (if available)
o If there is a risk that RV3 cannot stop before the
intersection;
▪ HV is warned of a risk of collision with oncoming
RV3.
Post-Conditions • HV is aware of a risk of collision with RV1 approaching from the
left.
• HV is aware of a risk of collision with RV2 approaching from the
right.
• HV is aware of a risk of collision with oncoming RV3.
Information • HV’s location.
Requirements • HV’s turn signal state.
• HV’s estimated acceleration from stopped.
• RV1’s location and dynamics.
• RV1’s turn signal state.
• RV2’s location and dynamics.
• RV2’s turn signal state.
• RV3’s location and dynamics.
• RV3’s turn signal state.
• Lane designations and geometry.
• Intersection geometry.
• Traffic stop signs.
• Traffic light signal phase and timing.
• Traffic rules and laws for 3-way stops, 4-way stops and unsigned
intersections.
• Current Road Conditions (if available)

Emergency Break Warning

Use Case Name Emergency Break Warning

User story Alert HV that a lead RV is undergoing an emergency braking event.
57
 58
Category Safety, Autonomous Driving
Road environment Urban, Rural, Highway
Short Description Alert HV if a lead vehicle is braking.

Actors • Host Vehicle (HV)

• Remote Vehicle (RV)
Vehicle roles • HV represents the vehicle approaching the lead vehicle from
behind.
• RV1 represents the lead vehicle that has applied its breaks.
Road & Roadside Not applicable
infrastructure roles
Other Actors’ roles Not applicable
Goal • Avoid a rear end collision between HV and RV.
Needs • HV needs to know if there is an emergency braking event in RV.
Constraints / • Assumptions will be required for the following information:
Presumptions o HV’s safe following distance.
o HV’s safe stopping distance
o RV’s safe stopping distance is same as HV’s
Geographic Scope Global
Illustrations

Illustration of high congestion

58
 59

• 𝑑𝑅𝑉 = distance between HV and RV

• 𝑑𝐻𝑉𝑓 = safe following distance of HV
• 𝑑𝐻𝑉𝑠 = safe stopping distance of HV
Pre-Conditions • HV is following RV
• The “Emergency Break Warning” scenario application zone is
determined from:
o HV’s location and dynamics
o HV’s safe following distance
o HV’s safe stopping distance
o Lane designations and geometry
o Road Conditions (if available)
Main Event Flow • RV applies the breaks.
• If RV is in “Emergency Break Warning” scenario application zone.
a. HV is alerted of the braking event in a leading RV
Post-Conditions • HV is aware of a braking event in a leading RV.
Information • HV’s location and dynamics
Requirements • HV’s safe following distance
• HV’s safe stopping distance
• RV’s location and dynamics
• Lane designations and geometry
• Current Road Conditions (if available)

Traffic Jam Warning

Use Case Name Traffic Jam Warning

User Story Alert HV of an approaching traffic jam.
Category Convenience
Road Environment Urban, Rural, Highway
Short Description • Warn HV of an approaching traffic jam on the road.
• Notify HV of a traffic jam on the navigation route.
Actors • Host Vehicle (HV)
• Remote Vehicle (RV)
Vehicle Roles • HV represents vehicle approaching traffic jam.
• RVs represent remote vehicles caught in traffic jam.

59
 60
Road & Roadside • Roads are defined by their lane designations and geometry.
Infrastructure Roles
Other Actors’ Roles Not Applicable
Goal • Alert HV of approaching traffic jam.
Needs • HV need to be aware of approaching traffic jam and its geometry.
Constraints /
Presumptions
Geographic Scope Global

Illustrations

Pre-Conditions • HV is moving forward

• Known traffic jam is defined by its location and geometry
• The “On Road” scenario application zone is determined from:
o HV’s location and dynamics
o HV’s safe stopping distance
o lane designations and geometry
o road conditions (if available)
• The “On Route” scenario application zone is determined from:
o HV’s location
o HV’s planned navigation route
Main Event Flow • If the traffic jam’s location is in the “On Road” scenario
application zone;
60
 61
o Warn HV of the approaching traffic jam.
Alternate Event Flow • If the traffic jam’s location is in the “On Route” scenario
application zone;
o Notify HV of the traffic jam location and geometry.
Post-Conditions • HV is aware of the approaching traffic jam on the road.
• HV is aware of the traffic jam’s location and geometry on the
navigation route.
Information • HV’s location and dynamics
Requirements • HV’s safe stopping distance
• HV’s planned navigation route (if available)
• Lane designations and geometry
• Traffic jam’s location and geometry.

Software Update

Use Case Name Software Update

User story Vehicle manufacturer updates electronic control module software for
targeted vehicles.
Category Vehicle Operations Management
Road environment Intersection, Urban, Rural, Highway, Other
Short Description • Vehicle Manufacturer or Controlling Authority publishes software
updates for one or more electronic control units (ECUs) on
targeted Host Vehicles (HVs).
Actors • Host Vehicle (HV)
• Vehicle Manufacturer
• Controlling Authority (could be fleet operator, owner / user
onboard, etc.)
• Human Driver
Vehicle roles • HV represents the targeted vehicle for an intended software
update.
Roadside Not applicable
infrastructure roles
Other Actors’ roles • Vehicle Manufacturer publishes software updates
• Vehicle Controlling Authority publishes software updates or
approves installation of software update
Goal Deliver software updates to targeted vehicles.
Needs • Vehicle manufacturer needs to distribute software updates.
• Vehicle manufacturer needs to notify HV in case of urgently-
needed update
• Vehicle manufacturer needs to ensure secure delivery of
authentic software updates to HV
• HV needs to download and install software updates
• HV owner may need to accept or approve application of software
updates
• HV owner needs to accept or reject free optional software
updates
• HV owner needs to purchase or reject optional software updates
with new features
61
 62
Constraints / • Vehicle manufacturer targets an update for a list of vehicles
Presumptions • A software update may depend on minimum ECU hardware
versions, other ECU software versions, or on a chain of previous
software versions.
• Scenarios may differ between conventional and autonomous cars
• HV includes capabilities to download, store, manage, and install
software. In many cases a device (or devices) may provide these
capabilities for a group of ECUs, while other ECUs may provide
these capabilities for themselves.
• A coordinated software update may involve a group of ECUs
• A software update may be routine (non-urgent) or urgent
• A software update may be mandatory or optional
• Software updates may vary in size, depending on target ECU(s).
Sizes from less than 1MB to more than 32GB must be considered.
• Software download must be secure, and the integrity of the
downloaded update must be assured (e.g., image signing, etc.)
• A software update might be rolled back
• Where feasible, HVs will retain one previous software version to
facilitate rollbacks. If this is not feasible, any single SW update
package and process should include the capability to roll back the
updates contained in that package in case the planned update
cannot complete.
• There might need to be multiple, staged updates to move the
vehicle systems to the current, recommended or required
versions. For example, the steps might include: ECU1 updated
from v2.1 to v2.4, then updated from v2.4 to v3.1. ECU2 updated
from v5.0 to v6.0 to v7.0 to v7.1. This can be done in one update
sequence, but could increase update package size and would
affect update timing.
• It may be possible that intermediate update stages (e.g., ECU1 at
v2.4 and ECU2 at v6.0) may not be considered compatible or safe,
so the entire update sequence may need to be completed before
the function or vehicle can be used.
• Downloading software updates must not adversely affect the
performance of safety features.
Geographic Scope Global
Illustrations Not applicable
Pre-Conditions • Vehicle manufacturer or controlling authority publishes a
software update for a target list of HVs
Main Event Flow • Vehicle manufacturer or controlling authority posts a mandatory
software update and notifies targeted HVs of the new software
version on affected ECUs.
• Update can be characterized as routine (non-urgent) or urgent
and could target conventional (human-driven) or autonomous
(self-driving) vehicles.
• In case of “urgent” updates, an “Urgent Update Required”
message is sent to the vehicle, and handled as in the user stories
below.

62
 63
• HV receives notification and starts downloading the software
update
• HV may download segments of the software update at opportune
moments that do not affect the performance of safety features or
other driver-facing features such as voice calls or streaming
content, or to accommodate changing network availability.
• HV may pause and continue downloads as needed; it should not
re-start a large download from the beginning and may receive
parts of the download out of order. Thus the download is
“reliable” even given any gaps in coverage or delays caused by
higher-priority uses of available bandwidth, or switching between
multiple communications mechanisms.
• When HV completes downloading the posted software update
a. HV should either retain a copy of the previously-installed
version of software in case of an issue with the update
that requires reverting to the previous version or have a
mechanism to reverse the changes contained in the SW
update package.
b. HV receives approval from human driver (conventional, if
required) or controlling authority (autonomous) to install
the software update. Such a separate step after package
download is not always mandatory.
c. HV installs the downloaded software update at a safe,
appropriate, driver-approved (where required) time.
d. HV notifies vehicle manufacturer and controlling
authority of update completion and an updated manifest
of ECUs, installed software versions, retained rollback
versions, any relevant download rate and installation
statistics, etc. as appropriate for the SW update process.
Alternative Event • Vehicle manufacturer posts an optional software update and
Flow notifies targeted HVs of the new software version and features on
affected ECUs
• HV owner is notified of the optional software update, its new
features and cost if applicable
• If HV owner accepts or purchases the update;
a. HV starts downloading the software update
b. HV may download segments of the software update at
opportune moments that do not affect the performance
of safety features or other driver-facing features such as
voice calls or streaming content.
c. HV may pause and continue downloads as needed; it
should not re-start a large download from the beginning
and may receive parts of the download out of order. Thus
the download is “reliable” even given any gaps in
coverage or delays caused by higher-priority uses of
available bandwidth, or switching between multiple
communications mechanisms.
d. When HV completes downloading the posted software
update;

63
 64
i. HV should either retain a copy of the
previously-installed version of software in case
of an issue with the update that requires
reverting to the previous version, or else have a
mechanism to reverse the changes contained in
the new SW update package.
ii. HV installs the downloaded software update at
a safe, appropriate, driver-approved (where
required) time
• HV notifies vehicle manufacturer and
controlling party of update completion and an
updated manifest of ECUs, installed software
versions, retained rollback versions, any
relevant download rate and installation
statistics, etc. as appropriate for the SW update
process.
Post-Conditions • Mandatory software updates are deployed on target HVs.
• Optional software updates are either rejected or deployed on
target HVs
Information • Urgency / Criticality of Update
Requirements • HV’s list of ECUs with current software versions
• Vehicle Manufacturers latest software versions per ECU on each
HV
• Any dependencies between ECUs and software versions
• HV’s software update download progress
• HV’s software update installation progress

Remote Vehicle Health Monitoring

Use Case Name Remote Vehicle Health Monitoring

User story Owners, fleet operators and authorized vehicle service providers monitor
the health of HV and are alerted when maintenance or service is required.
Category Vehicle Operations Management
Road environment Intersection, Urban, Rural, Highway, Other
Short Description Owners, operators and vehicle service providers request a report of the
HVs current health including:

• On-board Diagnostic Trouble Codes

• Predicted Maintenance (fluids, breaks, tires, battery, etc…)
Actors • Host Vehicle (HV)
• Vehicle Owner
• Fleet Operator
• Automotive Service Provider
Vehicle roles • HV represents the vehicle that needs maintenance or service.
Roadside Not applicable
infrastructure roles
Application server Not applicable
roles

64
 65
Other Actors’ roles Not applicable
Goal • Provide owners, operators and vehicle service providers of HV
health report on request.
• Alert owners, operators and vehicle service providers of HV
health issues requiring maintenance or service.
Needs • Owners, operators and vehicle service providers need to know
the health of the vehicle including:
o Required and estimated maintenance
o Detected problems that require service and the location
of HV
Constraints / Not applicable
Presumptions
Geographic Scope Global

Illustrations Not applicable

Pre-Conditions Not applicable
Main Event Flow • HV owner, operator or vehicle service provider requests a health
report
• HV provides on-board diagnostic trouble codes
• Required maintenance is determined based on component use
and wear.
• A health report is provide to the requester.
Alternate Event Flow • HV detects a problem using on-board diagnostics
• The HV owner, operator or vehicle service provider is notified of
the detected on-board diagnostic trouble code.
Alternate Event Flow • HV driver detects a problem that requires service.
• The HV owner, operator or vehicle service provider is notified of
the driver reported problem.
Alternate Event Flow • A HV component requires maintenance based on determined use
and ware.
• The HV owner, operator or vehicle service provider is notified of
the required maintenance.
Post-Conditions • Owners, operators and vehicle service providers are aware of the
health of the vehicle including:
o Required and estimated maintenance
o Detected problems that require service and location of
HV
Information • HV health report
Requirements o On-board Diagnostic Trouble Codes
o Predicted Maintenance (fluids, breaks, tires, battery,
etc…)
o Required Maintenance (fluids, breaks, tires, battery,
etc…)
• HV Location

Hazardous Location Warning

Use Case Name Hazardous Location Warning

65
 66
User Story/Use Case An autonomous or semi-autonomous vehicle is driving on a road (route),
Scenario heading towards a road segment, which presents unsafe and unknown
conditions ahead. A host vehicle is made aware of situations detected and
shared by remote vehicles. Situations may include such things as accidents,
weather, traffic, construction.
Category Safety, Autonomous Driving
Road Environment Urban, Rural, Highway
Short Description A host vehicle is made aware of accidents, traffic, adverse weather, road
conditions, construction and other situations detected and shared by
remote vehicles. The shared situations are relevant along the host vehicle’s
navigation route or current road of travel. Some examples include but are
not limited to:
• traffic congestion detected by slowly-moving RVs
• adverse weather conditions detected by temperature changes and
wiper activation
• accidents detected by air bag deployment events
• slippery road conditions detected by traction control events
• disabled vehicles detected by hazard lamps or tire pressure
Actors • Remote Vehicle (RV)
• Host Vehicle (HV)
Vehicle Roles • RV represents the vehicle detecting and sharing situational
information.
• HV represents the vehicle made aware of situational information.
Road & Roadside • Roads are defined by their lane designations and geometry.
Infrastructure Roles
Other Actors’ Roles Traffic Management: An entity that collects accidents, traffic, adverse
weather, road conditions, construction and other situations and reports
them to other vehicles. (For user story 2, not for 1)
Goal Alert HV of a situation that lies ahead along its navigation route or current
road segment.
Needs • HV needs to be aware of a situation that lies ahead along its
navigation route or road segment.

Constraints / The “Navigation Route” scenario includes all roads ahead along HV’s
Presumptions known navigation route.
The “Current Road” scenario includes the length of the road ahead that HV
is currently travelling on.
Geographic Scope Global

66
 67
Illustrations

Pre-Conditions • One or more RV’s have detected conditions that constitute a situation
that HV should be made aware of.
Main Event Flow If the situation’s location is on HV’s navigation route:
One or more RV’s have reported conditions to the Traffic Management
entity that constitute a situation that one or more HVs should be made
aware of

HV is made aware of the situation’s nature and location.

(cf. user story #2)

Alternate Event Flow If the situation‘s location is ahead along HV’s current road of travel:

• One or more RV’s detect a situation that one or more HVs should
be made aware of
• The RV(s) provide the notification to the HV(s)
• HV is made aware of the situation’s nature and location
Post-Conditions • HV is made aware of a detected situation along its navigation
route or current road ahead.
Information • RV’s location and dynamics
Requirements • RV’s wiper, lamps status
• RV’s outside temperature, barometric pressure
• RV’s hazard lamps, tire pressure

67
 68
• RV’s ABS, Stability Control, Traction Control, Airbag events
• Road Map
• HV’s Navigation Route
• Road conditions
• Construction Zone Map

Speed Harmonization

Use Case Name Speed Harmonization

User Story Notify HV of recommended speed to optimize traffic flow, minimize
emissions and to ensure a smooth ride.
Category Traffic Efficiency and Environmental friendliness, Autonomous Driving
Road Environment Urban, Rural, Highway
Short Description Notify HV of recommended speed based on traffic, road conditions and
weather information.
Actors • Host Vehicle (HV)
Vehicle Roles • HV represents the vehicle receiving posted speed limits.
Road & Roadside • Roads are defined by their lane designations and geometry.
Infrastructure Roles • Posted Speed Limits are associated with road & lane segments.
Other Actors’ Roles Not Applicable
Goal • Notify HV of the optimal speed to enable a comfortable ride and
alleviate the need for frequent acceleration and deceleration.
• Promote environmental friendly driving patterns.
• Reduce risks of collisions due to stop and go traffic.
Needs • HV needs to know the recommended speed to optimize traffic
flow, minimize emissions and to ensure a smooth ride.
Constraints / • RVs on the harmonized road segment are aware of the
Presumptions recommended speed.
Geographic Scope Global

Illustrations

𝑑𝐻𝑉𝑓 = safe following distance of HV

𝑑𝑅𝑉𝑓 = safe following distance of RV

68
 69
Pre-Conditions • HV is moving forward.
• The scenario application zone is determined from:
o HV’s location & dynamics
o HV’s safe following distance
o lane designations and geometry
o posted speed limits
• The speed harmonization road segment is determined from:
o RVs’ location & dynamics
o RVs’ safe following distance
o lane designations and geometry
o road conditions (if available)
Main Event Flow • If the “speed harmonization road segment” is in the scenario
application zone;
o Notify HV of the recommended harmonized speed
Post-Conditions • HV is aware of the recommended harmonized speed.
Information • HV’s location and dynamics.
Requirements • HV’s safe following distance
• RVs’ location & dynamics
• RVs’ safe following distance
• Lane designations and geometry
• Posted speed limit associated with lane or road segments.
• Road conditions (if available)

High Definition Sensor Sharing

Use Case Name High Definition Sensor Sharing

User story/Use case The vehicle has automated driving mode and changes lanes.
scenario
Category Autonomous Driving
Road environment Suburban, Urban, Rural, Highway
Short Description Vehicle uses its own sensors (e.g., HD camera, lidar), and sensor
information from other vehicles, to perceive its environment (e.g., come
up with 3D model of world around it) and safely performs an automated
driving lane change.
Actors • Host Vehicle
• Remote Vehicles
Vehicle roles • On-board sensors detect other vehicles and objects.
• On board processors calculate relative distances and trajectories
of other vehicles.
• Processed and/or un-processed information is shared with other
vehicles.
Roadside Not applicable
infrastructure roles
Other Actors’ roles None
Goal Automated driving lane change safely performed.
Needs • Capability of vehicle to calculate accurately, and in real time, its
relative position with other vehicles, road markings and objects.

69
 70
• Capability of the vehicle to use its own sensor information and/or
that of other vehicles, including those not in line of sight.
• System must work during the day and the night, and in all
weather conditions.

Constraints / Not all vehicles will be equipped.

Presumptions
Geographic Scope Global
Illustrations

HV = Host Vehicle
RV = Remote Vehicle
Pre-Conditions • Necessary software available in clients and applications.
Communication means available.
• The Host Vehicle has to understand the sensor data from the
Remote Vehicles, in an agreed format.
Main Event Flow • Host Vehicle captures 360 degree sensory information (e.g., other
vehicles, road markings).
• Host Vehicle calculates in real time its distance from other
vehicles and objects, their relative positions and their trajectories.
• Host Vehicle receives processed and/or un-processed information
(e.g., video) from remote vehicles and uses that information to
improve its perception of the surroundings and add certainty to
its calculations.
• Host Vehicle, taking into account information received from
Remote Vehicles, calculates what the gap between Remote
Vehicle 4 and Remote Vehicle 5 will be for the next n seconds.
Host Vehicle knows from information received from Remote
Vehicle 5 that a junction is near and therefore Remote Vehicle 5
is likely to slow down imminently.
• Host Vehicle determines that it is safe to move from the left lane
to the right lane.
• Host Vehicle notifies remote vehicles of its intention.
• Host Vehicle performs the manoeuvre, adjusting its speed to the
optimum.
Alternative Event As above except in step 3 the HV requests sensor information from
Flow specific RVs.
70
 71
Post-Conditions The vehicle has moved from the left lane to the right lane.
Information • Accurate dynamic relative position and planned trajectory
Requirements • High Definition images.
• LIDAR.
• Dynamic 3D absolute position.
• Accuracy of the data and liability for sharing.
• Agreed formats of data for sharing.

See-Through for Pass Maneuver

Use Case Name See-Through for Pass Maneuver

User story Driver of Host Vehicle that signals an intention to pass a Remote Vehicle
(RV) using the oncoming traffic lane is provided a video stream showing
the view in front of the RV.
Category Safety
Road environment Rural (2-lane highways)
Short Description • HV approaches from behind or follows RV1 with the intention to
pass using the oncoming lane.
• Video stream of the front view of RV1 is shown to the HV driver
during the passing maneuver.
Actors • Host Vehicle (HV)
• Remote Vehicle 1 (RV1)
• Remote Vehicle 2 (RV2)
• Remote Vehicle 3 (RV3)
Vehicle roles • HV represents the vehicle intending to pass RV1.
• RV1 represents the vehicle being passed.
• RV2 represents the vehicle in front of RV1.
• RV3 represents the closest vehicle in the oncoming traffic lane.
Roadside • Roads must define their lanes and direction of traffic flow in each
infrastructure roles lane.
• Road must indicate where passing is not permitted across traffic
lanes.
Other Actors’ roles Not applicable
Goal Provide HV driver a clear, reliable and real-time view of the road situation
in front of the vehicle it is trying to pass and help avoid possible collision.
Needs • Communication capabilities allowing real-time video transfer
High-resolution display in HV
Constraints / • HV and RV meet basic communications capabilities and performance
Presumptions requirements described for sending and receiving messages.
• HV and RV are equipped to send and receive messages as well as
high-bandwidth real-time video content.
Geographic Scope National
Illustrations

• State 1 = HV starts receiving streaming video from RV1

71
 72
• State 2 =
HV has fully moved into the passing lane, continues receving video
streaming from RV1
• State 3 =
HV has reached the position in the passing lane when it is ready to
start the maneuver to return to the starting lane
• State 4 =
HV completes the passing maneuver and can stop receiving the
• streaming video from RV1
Pre-Conditions • HV is approaching from behind or following RV1
• The HV and RV are in communication range.
The RV is capable of collecting front facing visual information.
Main Event Flow • The HV is approaching the RV from behind on the same lane.
• HV is following RV on a two-way road and makes a decision to
initiate a passing maneuver.
• HV requests RV’s visual information of its front view for the
purpose of making a passing decision as well as additional
information during the passing maneuver.
• The RV provides visual information of its front view periodically or
event-based.
• The HV receives the visual information from the RV.
• The HV driver is able to see the RV front facing.
Alternative Event Not applicable
Flow
Post-Conditions Based upon the visual information from the RV, the HV driver is able to
• make an informed decision to overtake the RV when there is no
traffic coming in on the opposite direction
• Complete a successful passing maneuver with the additional
visual information from RV1.
Information • Video streaming capability between vehicles as well as short
Requirements message exchange capability.

Lane Change Warning

Use Case Name Lane Change Warning

User story Host Vehicle (HV) signals an intention to change lanes.
Category Safety, Autonomous Driving
Road environment Urban, Rural, Highway
Short Description • Alert HV intending to change lanes of a lack of space or risk of
collision with a lagging RV1 approaching from behind in the target
lane.
• Alert HV intending to change lanes of a lack of space or risk of
collision with a leading RV2 in the target lane.
• Alert HV intending to change lanes that this maneuver is not
permitted on the current road segment.
Actors • Host Vehicle (HV)
• Remote Vehicle 1 (RV1)
• Remote Vehicle 2 (RV2)

72
 73
Vehicle roles • HV represents the vehicle intending to change lanes.
• RV1 represents the lagging vehicle in the target lane.
• RV2 represents the leading vehicle in the target lane.
Road & Roadside • Roads are defined by their lane designations and geometry.
infrastructure roles • Road segments indicate where changing lanes is not permitted.
Other Actors’ roles Not applicable
Goal Avoid HV encroaching into RV2; avoid HV encroaching into RV1.
Needs • HV needs to know if there is a lack of space or risk of collision
with a lagging RV1 in the target lane.
• HV needs to know if there is a lack of space or risk of collision
with a leading RV2 in the target lane.
• HV needs to know if a lane change is not permitted on the current
road segment.
Constraints / • Assumptions will be required for the following information:
Presumptions o HV’s safe following distance
o RV1’s safe following distance is the same as HV’s.
Geographic Scope Global
Illustrations

73
 74

• 𝑑𝐻𝑉𝑓 = safe following distance of HV

• 𝑙𝐻𝑉 = lenght of HV
Pre-Conditions • HV has signalled its intention to change lanes.
• Known road segments define is passing is not permitted.
• The “Lagging Vehicle” scenario application zone is determined
from:
o HV’s location and dynamics
o HV’s length
o HV’s safe following distance
o lane designations and geometry
o road conditions (if available)
• The “Leading Vehicle” scenario application zone is determined
from:
o HV’s location and dynamics
o HV’s safe following distance
o lane designations and geometry
o road conditions (if available)
Main Event Flow • If RV1 is in the “Lagging Vehicle” scenario application zone;
o If the trajectory of RV1 and HV cross;
▪ Warn HV of the risk of collision with RV1
o Otherwise;
▪ Alert HV of the lack of space to safely complete
the manoeuvre.
Alternative Event • If RV2 is in the “Leading Vehicle” scenario application zone;
Flow o If the trajectory of RV2 and HV cross;
▪ Warn HV of the risk of collision with RV2
o Otherwise;
▪ Alert HV of the lack of space to safely complete
the manoeuvre.
Post-Conditions • HV is aware of a lack of space or of a risk of collision with a
lagging RV1 in the target lane.
• HV is aware of a lack of space or of a risk of collision with a
leading RV2 in the target lane.
• HV is aware of whether a lane change is permitted or not on the
current road segment.

74
 75
Information • HV’s location and dynamics
Requirements • HV’s length
• HV’s safe following distance
• RV1’s location and dynamics
• RV2’s location and dynamics
• Lane designations and geometry
• Road segment lane change rules
• Road conditions (if available).

Vulnerable Road User

Use Case Name Vulnerable Road User

User story Alert HV of approaching VRU in the road or crossing an intersection and
warn of any risk of collision.
Category Society and Community, Safety
Road environment Intersection, Urban, Rural, Highway, Other
Short Description Alert HV of approaching VRU in the road or crossing an intersection and
warn of any risk of collision.
Actors • Vulnerable Road User (VRU)
• Surveillance cameras at traffic lights/crossings
Vehicle roles HV represents the vehicle moving forward Host Vehicle (HV) | Other
Vehicles roles
Road & Roadside • Roads are defined by their lane designations and geometry.
infrastructure roles • Intersections are defined by their crossing designations and
geometry.
• Traffic lights and stop signs control right of way traffic flow
through an intersection (if available).
• Pedestrian crossings are defined by their designations and
geometry.
Other Actors’ roles VRU represents a pedestrians, bike, eBike, motorbike, skateboard etc. …
that is travelling along the road or intends to cross the road.
Goal Avoid collision between HV and VRU.
Needs • HV needs to be aware of VRU on the road and any risk of
collision.
• HV needs to be aware of VRU at an intersection and any risk of
collision.
Constraints / • Assumptions will be required for the following information:
Presumptions o HV’s safe stopping distance
o VRU’s trajectory is constant
o extent of scenario application zones
Geographic Scope Global

75
 76
Illustrations

• 𝑑1 = stopping distance of HV
• 𝑑2 = distance from HV to scenario crash zone
Pre-Conditions • HV is moving forward.
• Before establishment of LoS, if any
• Known VRU is characterized (bike, pedestrian, motorcycle,…)
• The “In Road” scenario application zone is determined from:
o HV’s location and dynamics
o HV’s safe stopping distance
o lane designations and geometry
o road conditions (if available)
• The “Intersection” scenario application zone is determined from:
o HV’s location and dynamics
o HV’s safe stopping distance
o intersection geometry
o road conditions (if available)
Main Event Flow • If VRU is in the “On Road” scenario application zone;
o If HV’s trajectory and VRU’s trajectory are on a collision
course then
▪ Warn HV of the risk of collision with the
approaching VRU

76
 77
o Otherwise
▪ Caution HV of the approaching VRU
Alternate Event Flow • If VRU is in the “Intersection” scenario application zone;
o If HV’s trajectory and VRU’s trajectory are on a collision
course then
▪ Warn HV of the risk of collision with the
approaching VRU
o Otherwise
▪ Caution HV of the approaching VRU
Post-Conditions • HV/Driver is aware of its approach towards the VRU and any risk
of collision (Day 1-1.5)
• HV is aware of its approach towards the VRU and takes the
necessary safety measures to avoid or mitigate collision (Day 3)
Information • HV’s location and dynamics.
Requirements • HV’s safe stopping distance.
• VRU’s location and dynamics.
• VRU’s characterization (bike, pedestrian, motorcycle, …)
• Lane designations and geometry.
• Intersection geometry
• Current Road Conditions (if available)
• Other vehicle sensor data

5GAA is a multi-industry association to develop, test and promote communications

solutions, initiate their standardization and accelerate their commercial availability
and global market penetration to address societal need. For more information such
as a complete mission statement and a list of members please see [Link]

77