Embed Size (px)
Citation preview
5GAA A-200094
Version: 1.0
Date of publication: 16.06.2020
Document type: Technical Report
External publication: Yes
Date of approval by 5GAA Board: 03.06.2020
5GAA
5GAA address
______________________
5GAA c/o MCI Munich
Neumarkter Str. 21
81673 München – Germany
Internet
____________
www.5gaa.org
5GAA A-200094
Contents ............................................................................................................................. 2
Foreword ............................................................................................................................ 3
Introduction ....................................................................................................................... 4
1 Scope ......................................................................................................................... 4
2 References ................................................................................................................ 4
3 Abbreviations ........................................................................................................... 5
3.1 Abbreviations ........................................................................................................................5
4 Overview ................................................................................................................... 6
5 Requirement of interoperability ............................................................................. 6
5.1 Introduction to interoperability .........................................................................................6 5.2 Reference architecture and interoperability ....................................................................6
6 Application Layer Reference Architecture .............................................................. 6
6.1 Introduction ..........................................................................................................................6 6.2 Stakeholders and their relationships ................................................................................6 6.3 Reference architecture ........................................................................................................7 6.3.1 Functional view................................................................................................................8 6.3.2 Deployment views ..........................................................................................................9 6.3.3 Implementation views ................................................................................................. 12 6.3.3.1 3GPP V2X Application Enabler (VAE) functional model ..................................... 13 6.3.3.1.1 VAE server deployment models ...................................................................... 15 6.3.3.1.1.1 Centralised deployments ............................................................................ 15 6.3.3.1.1.2 Distributed deployment .............................................................................. 17 6.4 Description of components of the architecture ............................................................ 20 6.4.1 Functional components .............................................................................................. 20 6.4.2 Stakeholders for functional components ................................................................. 21 6.5 Description of reference points of the architecture ..................................................... 22 6.5.1 Vehicle-to-anything (V2X) Reference Points ............................................................. 24 6.5.2 Road Traffic Authority (RTA) Reference Points ........................................................ 24 6.5.3 Original Equipment Manufacturer (OEM) Reference Points .................................. 25 6.5.4 Service Provider (SP) Reference Points ..................................................................... 26 6.5.5 Interchange Function (IF) Reference Points ............................................................. 26
7 Conclusion .............................................................................................................. 27
Annex A: Change history.......................................................................................... 28
5GAA A-200094
This Technical Report has been produced by 5GAA.
The contents of the present document are subject to continuing work within the Working Groups
(WG) and may change following formal WG approval. Should the WG modify the contents of the
present document, it will be re-released by the WG with an identifying change of the consistent
numbering that all WG meeting documents and files should follow (according to 5GAA Rules of
Procedure):
x-nnzzzz
(1) This numbering system has six logical elements:
(a) x: a single letter corresponding to the working group:
where x =
T (Use cases and Technical Requirements)
A (System Architecture and Solution Development)
P (Evaluation, Testbed and Pilots)
S (Standards and Spectrum)
B (Business Models and Go-To-Market Strategies)
(b) nn: two digits to indicate the year. i.e. 17, 18, 19, etc.
(c) zzzz: unique number of the document
(2) No provision is made for the use of revision numbers. Documents which are a revision of
a previous version should indicate the document number of that previous version
(3) The file name of documents shall be the document number. For example, document S-
160357 will be contained in file S-160357.doc
5GAA A-200094
This document addresses the 5GAA WG2 work item ‘V2X Application Layer Reference
Architecture (V2XSRA)’.
The scope of this document covers the deliverable ‘WG2-00XX’ as described in [5GAA V2XSRA]
under ‘Expected output and Time Scale’.
The following documents contain provisions which, through reference in this text, constitute
provisions of the present document.
- References are either specific (identified by date of publication, edition number, version
number, etc.) or non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies.
[5GAA V2XSRA] 5GAA Work Item Description A-180236: ‘V2X System Application Layer Reference
Architecture’
[3GPP TS 23.285] 3GPP TS 23.285: ‘Architecture Enhancements for V2X Services’
[3GPP TS 23.286] 3GPP TS 23.286: ‘Application Layer Support for V2X Services’
[3GPP TS 23.434] 3GPP TS 23.434: ‘Service Enabler Architecture Layer for Verticals (SEAL)’
[CAM] ETSI EN 302 637-2: ‘ETSI ITS: Specification of Cooperative Awareness Basic Service’
[DENM] ETSI EN 302 637-3: ‘ETSI ITS: Specifications of Decentralised Environmental Notification
Basic Service’
[IVIM] ETSI TS 103 301: ‘ETSI ITS: Facilities Layer and Communication Requirements for
Infrastructure Services’
[SREM] ETSI ITS 103 301: ‘ETSI ITS: Facilities Layer and Communication Requirements for
Infrastructure Services’
[SSEM] ETSI ITS 103 301: ‘ETSI ITS: Facilities Layer and Communication Requirements for
Infrastructure Services’
[SPATEM] ETSI ITS 103 301: ‘ETSI ITS: Facilities Layer and Communication Requirements for
Infrastructure Services’
[MAPEM] ETSI ITS 103 301: ‘ETSI ITS: Facilities Layer and Communication Requirements for
Infrastructure Services’
[BSM] SAE J2735: ‘Dedicated Short Range Communications (DSRC) Message Set Dictionary’
[PSM] SAE J2735: ‘Dedicated Short Range Communications (DSRC) Message Set Dictionary’
5GAA A-200094
[DATEX II] DATEX II: ‘DATEX II Downloads’
[SENSORIS] SENSORIS: ‘SENSORIS Specification’
[HTTP] IETF: ‘IETF RFC 7230’
[MQTT] ISO/IEC: ‘ISO/IEC PRF 20922’
[AMQP] OASIS: ‘OASIS Advanced Message Queuing Protocol (AMQP) Version 1.0’ or ‘ISO/IEC
19464:2014 Advanced Message Queuing Protocol (AMQP) v1.0 Specification’
[C-Roads Platform] C-Roads Platform: ‘Harmonised C-ITS Specifications for Europe – Release 1.5’
3.1 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AMQP Advanced Message Queuing Protocol
App Application
AS Application Server
BSM Basic Safety Messages
HMI Human-Machine-Interface
CAM Cooperative Awareness Message
C-ITS Cooperative Intelligent Transport System
DATEX II Data Exchange II
DENM Decentralised Environmental Notification Message
HMI Human Machine Interface
HTTP Hypertext Transfer Protocol
IF Interchange Function
IOO Infrastructure Owner Operator
IVIM In-Vehicle Information Message
OEM Original Equipment Manufacturer
MAPEM Map (topology) Extended Message
MBMS Multimedia Broadcast Multicast Service
MNO Mobile Network Operator
MQTT Message Queue Telemetry Transport
PSM Personal Safety Message
RTA Road Traffic Authority
RTO Road Traffic Operator
SDO Standards Development Organisation
SENSORIS SENSOR Interface Specification
SP Service Provider
SPATEM Signal Phase and Timing Extended Message
SREM Signal Request Extended Message
SSEM Signal request Status Extended Message
V2X Vehicle-to-Everything
VRU Vulnerable Road User
5GAA A-200094
4
This technical report begins with an introduction to interoperability in chapter 5. In chapter 6, the
application layer reference architecture is specified, including description of functional
components and reference points.
5.1 Introduction to interoperability
Interoperability is a characteristic of a product or system to work with other products or systems,
present or future, without any restrictions.
This technical report is about interoperability between functions on the application layer. Given
the large ecosystem and extensive amount of services for connected vehicles, many diverse
application layer protocols are needed. The requirements for interoperability vary depending on
the endpoints of the application layer protocols.
5.2 Reference architecture and interoperability
The reference architecture facilitates identification of application layer protocols and
understanding of the need for new standardisation. One example is that if the two endpoints of
the application layer protocol are governed by different stakeholders, the need for
standardisation of the application layer protocol is higher.
6.1 Introduction
This section comprises the application layer reference architecture, description of all functional
components and finally description of all reference points between the functional components in
the architecture.
The objective of defining this application layer reference architecture is to identify application
layer protocols in the automotive ecosystem, and to identify the lack of suitable application layer
protocols and the need for new standardisation.
6.2 Stakeholders and their relationships
The automotive ecosystem has several stakeholders. The major stakeholders in the operational
part of the automotive ecosystem are:
• Vehicle owners
• Vehicle Original Equipment Manufacturers (OEMs)
• Mobile Network Operators (MNOs)
5GAA A-200094
• Road Traffic Authorities (RTAs)1
• Service Providers (SPs), e.g. navigation service providers and infotainment service
providers
Beyond the operational part of the automotive ecosystem, many other stakeholders contribute
to the entire automotive ecosystem, e.g. suppliers to Vehicle OEMs, MNOs, RTAs and SPs. These
stakeholders are not included in this report.
The high-level business relationships between the major stakeholders are illustrated in Figure 1
below.
Figure 1: Business relationships between stakeholders
Vehicle owners are the primary source of revenue for the automotive ecosystem. They pay
Vehicle Original Equipment Manufacturers for products and services and Service Providers for
various services. Furthermore, they pay Road Traffic Authorities in their capacity as taxpayers.
Vehicle Original Equipment Manufacturers also pay Service Providers for various services.
Furthermore, they have business relationships with a limited number of different Mobile
Network Operators that provide connectivity to the vehicles.
Some Service Providers have business relationships with Mobile Network Operators for content
distribution.
In order to offer global connectivity, Home Mobile Network Operators have roaming agreements
with many Visited Mobile Network Operators.
6.3 Reference architecture
The application layer reference architecture is described from three different viewpoints:
• Functional view
• Deployment view
1 Other terms are used in some regions, e.g. Road Traffic Operator (RTO) or Infrastructure Owner
Operator (IOO)
5GAA A-200094
• Implementation view
The functional view is described in section 6.3.1 and includes all automotive services. Several
deployment views are described in section 6.3.2. Although several deployment views are
provided, the views are only examples and the list of views is not exhaustive. The
implementation view is described in section 6.3.3. The implementation view is only an example
and many other implementations views are possible.
6.3.1 Functional view
The generic functional view is described in Figure 2 below. It consists of several functions (boxes)
that are connected via different reference points (dotted lines). The generic functional view
consists of pairs of Applications (Apps) and Application Servers (ASs). There are two ways to
connect Application Servers, either directly (AS to AS) or indirectly via the Interchange Function
(IF). The reference points are indicated by a capital letter G, followed by the two endpoints.
The generic functional view serves as a pattern to introduce functions in the functional view.
Figure 2: Generic functional view
The functional view of the V2X Application Layer Reference Architecture is described in Figure 3
below. It is based on the pattern of the generic functional view described above. Every reference
point represents an application layer connection between the two functions. The transport,
network and access layers are not part of this reference architecture.
The circular dotted lines indicate reference points between different instances of the same
function. For example, the V0 is the reference point between two instances of V2X AS.
5GAA A-200094
Figure 3: Functional view with functional components and reference points based on the
generic functional view
Every AS may provide several services to the App.
The functions are described in section 6.4 and the reference points are described in section 6.5
below.
6.3.2 Deployment views
The functional components in the functional view may be deployed in many ways. In some
deployment views all functional components are used, in other deployment views only a part of
the functional components is used. In some deployment views, the geographical deployment is
relevant, whereas in other deployment views the deployment according to different stakeholders
is of interest. The content in the deployment view depends on what is being described.
In this document, the deployment views describe the different stakeholders’ roles. The
Application Servers and the Interchange Function are deployed in cloud systems, selected by
different stakeholders, see section 6.4.2. The Apps are deployed in vehicles, in roadside
infrastructure and in devices for Vulnerable Road Users (VRUs).
In the deployment view in Figure 4 below, the RTA is the stakeholder for RTA AS and the RTA AS
is deployed in an RTA Cloud, i.e. a cloud system selected by the RTA. In the same way, the OEM is
the stakeholder for OEM AS and the OEM AS is deployed in an OEM Cloud. Finally, the SP is the
stakeholder for SP AS and the SP AS is deployed in an SP Cloud.
The V2X AS may have different stakeholders, in this case the MNO is the stakeholder for V2X AS
and the V2X AS is deployed in an MNO Cloud.
In this deployment view, no Interchange Function is deployed. A deployment without
Interchange Function can apply to deployments with a limited number of stakeholders.
The applications are deployed in different devices that make use of the services. The device for
Vulnerable Road Users (VRUs) has a deployment of a V2X App and RTA App. The roadside
5GAA A-200094
infrastructure has a deployment of an RTA App. Finally, the vehicle has a deployment of an OEM
App, SP App, RTA App and V2X App.
Figure 4: Deployment view with MNO stakeholder for V2X AS, no Interchange Function
The deployment view in Figure 5 below is similar to the deployment in Figure 4. The difference is
that the IF is deployed. In this case, the MNO is the stakeholder for IF which is deployed in an
MNO Cloud.
There is a large number of different RTAs in the world, in the order of thousands. The number of
different OEMs in the world is in the order of tens. The RTAs are local, but the OEMs are global
actors. It is a major challenge for OEMs to negotiate contract and setup communication for every
RTA. The Interchange Function is needed to scale up traffic information message exchanges,
primarily between RTA ASs and OEM ASs, but also SP ASs. The Interchange Function acts a
message broker between the Application Servers. RTAs publish road traffic information to the
Interchange Function, e.g. in DATEX II format, and OEMs subscribe to road traffic information
from the Interchange Function, for all geographical areas where the OEMs’ vehicles are located.
5GAA A-200094
Figure 5: Deployment view with MNO stakeholder for V2X AS and Interchange Function
The deployment view in Figure 6 below is similar to the deployment in Figure 5. The difference is
that the Interchange Function is deployed by a Service Provider who provides navigation
services, for example. In this case the SP is the stakeholder for Interchange Function and the IF is
deployed in an SP Cloud.
Figure 6: Deployment view with MNO stakeholder for V2X AS, SP stakeholder for
Interchange Function
The deployment view in Figure 7 below is similar to the deployment in Figure 6. The difference is
that the Interchange Function is deployed by a Road Traffic Authority (RTA). In this case the RTA
is the stakeholder for Interchange Function and the IF is deployed in an RTA Cloud.
5GAA A-200094
Figure 7: Deployment view with MNO stakeholder for V2X AS, RTA stakeholder for
Interchange Function
The deployment view in Figure 8 below is similar to the deployment in Figure 7. The difference is
that the Vehicle-to-anything Application Server (V2X AS) is deployed by a Road Traffic Authority.
In this case the RTA is the stakeholder for V2X AS and the V2X AS is deployed in an RTA Cloud.
Figure 8: Deployment view with RTA stakeholder for V2X AS and Interchange Function
NOTE: Many more deployment views are possible.
6.3.3 Implementation views
The functional components in the V2X Application Layer Reference Architecture may be
implemented in various ways. There are several platforms that can be used as a base for
implementing the various functions. Platforms are available for both ASs and Apps. There are
platforms based on both open source software and commercial software.
5GAA A-200094
6.3.3.1 3GPP V2X Application Enabler (VAE) functional model
3GPP has specified a V2X application enabler in [3GPP TS 23.286]. The V2X application enabler
can be common to all stakeholder functions. The V2X application enabler is specified in order to
overcome the following limitations:
• High cost for the OEM, SP, RTA to understand and utilise the network capabilities, e.g.
how to establish connections with Quality of Service, MBMS capability, network
information/notification, network status and events.
• High cost and long lead-time for V2X application development and commercial
deployment, as each V2X application has to implement the common basic functionalities,
e.g. network situation, QoS monitoring, communication parameters provisioning (e.g.
PC5 communication parameters), and network resource management.
• High cost and poor scalability for interworking, interoperation, and interchange among
different AS stakeholders that may be using proprietary interfaces between different
stakeholders.
To overcome the above limitations, the V2X application enabler layer provides the following
enhancements and benefits:
• The underlying network capabilities are abstracted such that the OEM, SP, RTA can easily
utilise them (e.g. easy to establish connections with Quality of Service, use MBMS
capability, receive network notifications, network status and events).
• Common functionalities can be utilised by different V2X applications including the
network situation and QoS monitoring, communication parameter (e.g. PC5), and
network resource management.
• Interworking, interoperation, and interchange among different stakeholders is simplified
via a unified enabler layer.
• Time to market for the V2X applications may be reduced.
The relationship between the 3GPP V2X application enabler (VAE), and the functional
components V2X App and V2X AS in this Technical Report are described in Figure 9 below.
5GAA A-200094
Figure 9: Relationship between 3GPP V2X Application Enabler [3GPP TS 23.286], Figure 6.2-2
and V2X AS and V2X App2
The V2X application enabler (VAE) is further composed of the following parts:
• VAE client: The VAE client provides client-side application support functions like
messaging support, file transfer support, network monitoring events abstraction,
communication mode switching of the underlying network, location augmentation,
dynamic group management, etc. A more detailed list of such functionalities is specified
for VAE client and SEAL client entities in [3GPP TS 23.286].
• VAE server: The VAE server provides server-side application support functions like
abstracting the underlying network interactions for network resource management,
tracking of location, message distribution, file transfer, network monitoring, group
management, configuration management, identity management, etc. A more detailed list
of such functionalities is specified for VAE server and SEAL server entities in
[3GPP TS 23.286].
SEAL is a Service Enabler Architecture Layer operating over 3GPP networks which supports many
vertical applications (e.g. V2X applications). SEAL services are specified in [3GPP TS 23.434].
The VAE may be provided by any of the stakeholders including MNOs, SPs, OEMs and RTAs.
The V2X application enabler also specifies the following reference points:
2 The following reference points are defined in 3GPP TS 23.286: V2 (V2X AS - V2X control
function), T8 (V2X AS - SCEF), MB2 (V2X AS - BM-SC), xMB (V2X AS - BM-SC) and Rx (V2X AS - PCRF).
5GAA A-200094
• V1-AE: Interactions related to V2X application layer support functions between VAE client
and VAE server are supported by the V1-AE reference point.
• VAE-E: Interactions related to V2X application layer support functions between one VAE
server and another VAE server, supporting the same kind of V2X application specific
server or different kinds of V2X application specific servers.
• V5-AE: Interactions related to V2X application layer support functions between the VAE
clients are supported by the V5-AE reference point.
6.3.3.1.1 VAE server deployment models
The VAE server deployments can be centralised or distributed.
6.3.3.1.1.1 Centralised deployments
Centralised deployment is where a single VAE server is in place and offers its capabilities to one
or more V2X application specific servers.
Among the different possibilities, the VAE server and the V2X application specific server may be
co-located in a single physical entity, for instance in the V2X service provider domain. In this case,
the Vs reference point between the VAE server and the V2X application enabler server may not
be used.
Figure 10 illustrates such deployment options with only one MNO interacting with the VAE server
located in the V2X service provider domain.
VAE server
V2X application specific server
xMB
Rx
3GPP network system (EPS)
V2 T8MB
2 PLMN operator domain
V2X service provider domain
Figure 10: Centralised VAE server co-located with V2X application specific server with a
single MNO, [3GPP TS 23.286], Figure 7.2.1-1
Similarly, multiple MNOs could be connected to the same centralised VAE server co-located with
a V2X application specific server.
5GAA A-200094
Figure 11 illustrates the VAE server and the V2X application specific server, co-located in a single
entity and deployed in the V2X service provider domain and connected to the systems of
multiple mobile network operators.
Figure 11: Centralised VAE server co-located with V2X application specific server with
multiple MNOs, [3GPP TS 23.286], Figure 7.2.1-3
If necessary, the Vs reference point is used for communication between the VAE server and a
V2X application specific server. The VAE server could eventually handle and support multiple V2X
application specific servers.
This possibility offers two options:
• The VAE sever could be located in the PLMN operator domain while interacting with the
V2X application specific server in the V2X service provider domain.
• The VAE server could provide VAE capabilities to multiple V2X application specific servers
over the Vs reference points.
Figure 12 illustrates a deployment of the VAE server in the PLMN operator domain and the V2X
application specific server in the V2X service provider domain.
VAE server
V2X application specific server
PLMN operator domain 1
V2X service provider domain
xMBRx
3GPP netw
ork system
(EP
S)
V2
T8
MB2
xMBRx
3GPP netw
ork system
(EPS)
V2
T8
MB2
PLMN operator domain 2
5GAA A-200094
PLMN operator domain
V2X service provider domain
Vs
V2X application specific server
VAE server
xMB
Rx
3GPP network system (EPS)
V2 T8MB
2
Figure 12: VAE server deployed in the PLMN operator domain,
[3GPP TS 23.286], Figure 7.2.1-2
Figure 13 illustrates a deployment of the VAE server which provides VAE capabilities to multiple
V2X application specific servers over Vs reference point.
VAE server
V2X application specific server 1
PLMN operator domain 1 V2X service provider domain
xMB
Rx
3G
PP
ne
two
rk system (E
PS)
V2
T8
MB2
xMB
Rx
3G
PP
ne
two
rk system (E
PS)
V2
T8
MB2
PLMN operator domain 2
V2X application specific server 2 V2X application specific server 3
VsVs Vs
Figure 13: Centralised VAE server with multiple V2X application specific servers and
multiple MNOs, [3GPP TS 23.286], Figure 7.2.1-4
6.3.3.1.1.2 Distributed deployment
Distributed deployment is where multiple instances of VAE servers are deployed either in the
V2X service provider domain or in the mobile network operator domain. The distributed
deployment of the V2X servers provide geographical coverage or support multiple PLMN
operator domains in a geographical location.
5GAA A-200094
The VAE servers interconnect via VAE-E and the Vs reference point is still used for interaction
between V2X application specific server and the VAE server.
Figure 14 illustrates the deployment of mutliple VAE servers in different PLMN operator
domains, all providing their VAE capabilities to a single V2X application specific server deployed
in the V2X service provider domain. The V2X application specific server connects via Vs to the
different VAE servers as usual.
V2X application specific server
PLMN operator domain 1
V2X service provider domain
Vs VsPLMN operator domain 2
VAE server
xMB
Rx
3GPP network system (EPS)
V2 T8MB
2
VAE server
xMB
Rx
3GPP network system (EPS)
V2 T8MB
2
Figure 14: Distributed deployment of VAE servers in multiple PLMN operator domain
without interconnection between VAE servers, [3GPP TS 23.286], Figure 7.2.2-1
Figure 15 illustrates the deployment of multiple VAE servers deployed in multiple PLMN operator
domains. The V2X application specific server connects via Vs to the VAE server. The
interconnection between VAE servers is via VAE-E and supports the V2X applications for the V2X
UEs connected to the VAE servers in multiple PLMN operator domains.
5GAA A-200094
VAE server
V2X application specific server
xMB
Rx
3GPP network system (EPS)
V2 T8MB
2
PLMN operator domain 1
VAE server
xMB
Rx
V2 T8MB
2
Vs
VAE-E
3GPP network system (EPS)
PLMN operator domain 2
Figure 15: Distributed deployment of VAE servers in multiple PLMN operator domains with
interconnection between VAE servers, [3GPP TS 23.286], Figure 7.2.2-2
Figure 16 illustrates the deployment of multiple VAE servers in PLMN operator domains based
on geographical coverage. The V2X application specific server connects via Vs to the VAE server
1. The VAE servers interconnect via VAE-E and support the V2X communications to the V2X UEs
connected to the VAE servers.
VAE server 1
V2X application specific server
xMB
Rx
3GPP network system (EPS)
V2
T8
MB
2
PLMN operator domain
V2X service provider domain
VAE server 2
xMB
Rx
V2
T8
MB
2
Vs
VAE-E
Figure 16: Distributed deployment of VAE servers in the PLMN operator domain, [3GPP TS
23.286], Figure 7.2.2-3
Figure 17 illustrates another deployment option of multiple VAE servers based on geographical
coverage but in the V2X service provider domain.
5GAA A-200094
Figure 17: Distributed deployment of VAE servers in the V2X service provider domain,
[3GPP TS 23.286], Figure 7.2.2-4
6.4 Description of components of the architecture
6.4.1 Functional components
The following functional components are included in the V2X Application Layer Reference
Architecture:
Vehicle-to-anything Application Server (V2X AS)
The V2X AS routes C-ITS messages between V2X Apps (using cellular communication) and
disseminates C-ITS messages within a geographical area.
Vehicle-to-anything Application (V2X App)
The V2X App sends and receives C-ITS messages to and from the V2X AS (using cellular
communication). Furthermore, the V2X App sends and receives C-ITS messages to and from
other V2X Apps (using short-range communication).
Original Equipment Manufacturer Application Server (OEM AS)
The OEM AS offers services to vehicles manufactured by the OEM and to its drivers and
passengers. The services could be telematics, infotainment, navigation, security certificate and
safety services, to name a few.
Original Equipment Manufacturer Application (OEM App)
The OEM App integrates the services offered by OEM AS into vehicles. Moreover, the OEM App
delivers services to drivers and passengers via the vehicles’ human-machine-interface (HMI).
VAE server 1
V2X application specific server 1
xMB
Rx
3GPP network system (EPS)
V2 T8
MB
2
PLMN operator domain 1
V2X service provider domain
VAE server 2
xMB
Rx
V2 T8MB
2
Vs
VAE-E
3GPP network system (EPS)
PLMN operator domain 2
5GAA A-200094
Road Traffic Authority3 Application Server (RTA AS)
The RTA AS offers traffic efficiency and traffic safety services to the vehicles. These types of
services are partly driven by legislation. Furthermore, RTA AS manages Road Side Infrastructure,
such as variable road signs, traffic lights and video surveillance cameras.
Road Traffic Authority Application (RTA App)
The RTA App integrates the services offered by RTA AS into vehicles or into Road Side
Infrastructure. Furthermore, RTA App may exchange traffic efficiency and traffic safety
information with other RTA Apps.
Service Provider Application Server (SP AS)
Various professional services are offered to vehicles, VRUs and other recipients. These include
fleet management or personal services such as infotainment. Although these services are
delivered by Service Provider application servers to the vehicles, the services may still be
authorised and controlled by the OEM AS.
Service Provider Application (SP App)
The SP App integrates the services offered by SP AS into vehicles and VRUs. Moreover, the SP
App exposes services to driver and passenger via the vehicles’ human-machine-interface (HMI)
and to VRUs.
Interchange Function (IF)
Given the large number of different Road Traffic Authorities in the world, Interchange Functions
are needed to scale up and secure the message exchanges between RTA ASs, OEM ASs and SP
ASs.
6.4.2 Stakeholders for functional components
Various stakeholders may take responsibility for different functional components in this
Application Layer Reference Architecture. Possible stakeholders for functional components are
listed in Table 1 below.
3 Other terms are used in some regions, e.g. Road Traffic Operator (RTO) or Infrastructure Owner
Operator (IOO)
5GAA A-200094
Functional component Possible stakeholders
V2X AS • Mobile Network Operator
• Road Traffic Authority
V2X App • Vehicle owner
• Vulnerable Road User
OEM AS • Original Equipment Manufacturer
OEM App • Vehicle owner
RTA AS • Road Traffic Authority
RTA App • Road Traffic Authority
• Vehicle owner
• Vulnerable Road User
SP AS • Service Provider
SP App • Vehicle owner
IF • Mobile Network Operator
• Road Traffic Authority
• Service Provider
Table 1: Possible stakeholders for functional components
6.5 Description of reference points of the architecture
In this chapter, all reference points in the functional view of the Application Layer Reference
Architecture are described. The following aspects are described for the reference points:
• The two functions that are connected via the reference point
• The type of services provided over the reference point
• The corresponding message formats and message exchange protocols
A number of different message formats are standardised in various Standards Development
Organisations (SDOs), see examples in Table 2 below.
5GAA A-200094
Abbreviation Name Reference
CAM Cooperative Awareness Message [CAM]
DENM Decentralised Environmental Notification
Message
[DENM]
IVIM In-Vehicle Information Message [IVIM]
SREM Signal Request Extended Message [SREM]
SSEM Signal request Status Extended Message [SSEM]
SPATEM Signal Phase and Timing Extended
Message
[SPATEM]
MAPEM Map (topology) Extended Message [MAPEM]
BSM Basic Safety Messages [BSM]
PSM Personal Safety Message [PSM]
DATEX II Data Exchange II [DATEX II]
SENSORIS SENSOR Interface Specification [SENSORIS]
Table 2: Message Formats
Messages in formats specified by ETSI and SAE may be transmitted directly between different
functional components via short-range communication (using 3GPP PC5 interface).
Messages in all these formats may also be exchanged between different functional components
by message exchange protocols over IP based networks. The IP based networks may be both
wired and wireless (using 3GPP Uu interface). Examples of message exchange protocols are
provided in Table 3 below.
Abbreviation Name Reference
HTTP Hypertext Transfer Protocol [HTTP]
MQTT Message Queue Telemetry Transport [MQTT]
AMQP Advanced Message Queuing Protocol [AMQP]
Table 3: Message Exchange Protocols
5GAA A-200094
NOTE: The services, message formats and message exchange protocols described below are just
examples (it is not meant to be an exhaustive list).
6.5.1 Vehicle-to-anything (V2X) Reference Points
The V2X Reference Points are described in Table 4 below. The reference points V1 and V5 have
already been introduced by 3GPP in [3GPP TS 23.285].
Reference
Point
Function
1
Function 2 Services Message
Exchange
Protocols
Message Formats
V1
(Gas-app)
V2X AS V2X App C-ITS HTTP, MQTT DENM, IVIM, SREM, SSEM,
SPATEM, MAPEM
V5
(Gapp-
app)
V2X App V2X App C-ITS
CAM, DENM, BSM, PSM
V0
(Gas-as)
V2X AS V2X AS C-ITS HTTP, MQTT DENM, IVIM, SREM, SSEM,
SPATEM, MAPEM
Table 4: V2X Reference Points
6.5.2 Road Traffic Authority (RTA) Reference Points
Reference
Point
Function
1
Function
2
Services Message
Exchange
Protocols
Message Formats
R1
(Gas-app)
RTA AS RTA App C-ITS HTTP, MQTT DATEX II, DENM, IVIM,
SREM, SSEM, SPATEM,
MAPEM
R2
(Gapp-
app)
RTA App RTA App C-ITS
DENM, IVIM, SREM, SSEM,
SPATEM, MAPEM
R3
(Gas-as)
RTA AS V2X AS C-ITS HTTP, MQTT DATEX II, DENM, IVIM,
SREM, SSEM, SPATEM,
MAPEM
R4
(Gas-as)
RTA AS RTA AS C-ITS HTTP, MQTT DATEX II, DENM, IVIM,
SREM, SSEM, SPATEM,
MAPEM
R5
(Gas-as)
RTA AS SP AS C-ITS HTTP, MQTT DATEX II, DENM, IVIM,
SREM, SSEM, SPATEM,
MAPEM
Table 5: RTA Reference Points
5GAA A-200094
6.5.3 Original Equipment Manufacturer (OEM) Reference Points
Reference
Point
Function
1
Function
2
Services Message
Exchange
Protocols
Message Formats
O1
(Gas-app)
OEM AS OEM App Telematics,
infotainment,
navigation,
sensor sharing
HTTP,
MQTT
SENSORIS, Proprietary
ADAS HTTP,
MQTT
DENM, IVIM, SREM, SSEM,
SPATEM, MAPEM
O2
(Gas-as)
OEM AS SP AS Infotainment,
navigation,
fleet
management…
HTTP Proprietary
O3
(Gas-as)
OEM AS RTA AS ADAS HTTP,
AMQP,
MQTT
DATEX II, DENM, IVIM,
SREM, SSEM, SPATEM,
MAPEM
O4
(Gas-as)
OEM AS OEM AS Sensor sharing HTTP,
AMQP,
MQTT
SENSORIS, Proprietary
O5
(Gas-as)
OEM AS V2X AS C-ITS HTTP,
MQTT
DENM, IVIM, SREM, SSEM,
SPATEM, MAPEM
Table 6: OEM Reference Points
Reference Point O3 may be used instead of the combination of reference points I2 and I3 in
markets where no Interchange Function is deployed.
5GAA A-200094
6.5.4 Service Provider (SP) Reference Points
Reference
Point
Function
1
Function 2 Services Message
Exchange
Protocols
Message
Formats
P1
(Gas-app)
SP AS SP App Infotainment,
navigation, fleet
management…
HTTP Proprietary
P2
(Gas-as)
SP AS SP AS Infotainment,
navigation, fleet
management…
HTTP Proprietary
P3
(Gas-as)
SP AS V2X AS C-ITS HTTP, MQTT DENM, IVIM,
SREM, SSEM,
SPATEM,
MAPEM
Table 7: SP Reference Points
6.5.5 Interchange Function (IF) Reference Points
Reference
Point
Function 1 Function 2 Services Message
Exchange
Protocols
Message Formats
I1
(Gas-if)
Interchange
Function
V2X AS Message
exchange
AMQP4 DATEX II, DENM, IVIM,
SREM, SSEM, SPATEM,
MAPEM
I2
(Gas-if)
Interchange
Function
RTA AS Message
exchange
AMQP DATEX II, DENM, IVIM,
SREM, SSEM, SPATEM,
MAPEM
I3
(Gas-if)
Interchange
Function
OEM AS Message
exchange
AMQP DATEX II, DENM, IVIM,
SREM, SSEM, SPATEM,
MAPEM
I4
(Gas-if)
Interchange
Function
SP AS Message
exchange
AMQP DATEX II, DENM, IVIM,
SREM, SSEM, SPATEM,
MAPEM
I5
(Gif-if)
Interchange
Function
Interchange
Function
Federation
of
Interchange
Functions
AMQP DATEX II, DENM, IVIM,
SREM, SSEM, SPATEM,
MAPEM
Table 8: IF Reference Points
Federation of Interchange Functions means that several Interchange Functions can exchange
messages between each other.
4 AMQP is selected by the European C-Roads Platform [C-Roads Platform].
5GAA A-200094
This technical report introduces an Application Layer Reference Architecture for the automotive
ecosystem, taking the following stakeholders into account:
• Vehicle Original Equipment Manufacturers (OEMs)
• Mobile Network Operators (MNOs)
• Road Traffic Authorities (RTAs)
• Service Providers (SPs), e.g. navigation service providers and infotainment service
providers
The Application Layer Reference Architecture is described from three different viewpoints:
• Functional view, with functional components and Reference Points between them
• Deployment views, with the functions deployed in different cloud systems and devices
• Implementation views, with different implementation options
It is recommended that this Application Layer Reference Architecture be used as a baseline in
other 5GAA WG work items as well as 5GAA Cross-WG items, to describe use cases involving
multiple stakeholders in the automotive ecosystem.
5GAA A-200094
Date Meeting TDoc Subject/Comment
2020-02 F2F Brussels A-200045 First version
2020-04 Call # 30 A-200064 Second version
2020-05 VF2F A-200094 Version for approval
