ETSI GS MEC 030 V2.1.1 (2020-04)

Multi-access Edge Computing (MEC); V2X Information Service API

DGS/MEC-0030V2XAPI

General Information

• Status: Not Published
• Technical Committee: MEC - Multi-access Edge Computing
• Current Stage: 12 - Completion
• Due Date: 18-May-2020
• Completion Date: 30-Apr-2020

Standards Content (Sample)

GROUP SPECIFICATION
Multi-access Edge Computing (MEC);
V2X Information Service API
Disclaimer
The present document has been produced and approved by the Multi-access Edge Computing (MEC) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GS MEC 030 V2.1.1 (2020-04)

Reference
DGS/MEC-0030V2XAPI
Keywords
API, MEC, service, V2X
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2020.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI GS MEC 030 V2.1.1 (2020-04)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 9
4 Overview . 9
5 Description of the service (informative). 10
5.1 Reference scenarios for the VIS service . 10
5.2 Multi-operator scenarios and V2X services . 10
5.3 V2X service continuity in multi-operator operation scenarios . 11
5.3.1 Introduction. 11
5.4 VIS functionalitie s . 12
5.4.1 Overview . 12
5.4.2 Communication between V2X Control Function (3GPP) and VIS (MEC) . 13
5.4.3 Inter-MEC system V2X application communication . 14
5.4.4 Inter-MEC system service exposure . 14
5.4.5 The VIS and its role in producing journey-specific QoS notifications . 14
5.5 Sequence diagrams . 15
5.5.1 Sending a request for provisioning information for V2X communication over Uu unicast . 15
5.5.2 Sending a request for provisioning information for V2X communication over Uu MBMS . 16
5.5.3 Sending a request for provisioning information for V2X communication over PC5 . 16
5.5.4 Sending a request for journey-specific QoS predictions . 17
5.5.5 REST based subscribe-notify model . 17
5.5.5.1 Subscribing to event notifications . 17
5.5.5.2 Receiving notification on expiry of V2X information event subscription . 18
5.5.5.3 Updating subscription for V2X information event notifications . 19
5.5.5.4 Unsubscribing from V2X information event notifications . 19
5.5.6 Receiving V2X information event notifications about the provisioning information changes for V2X
communication over Uu unicast . 20
5.5.7 Receiving V2X information event notifications about the provisioning information changes for V2X
communication over Uu MBMS . 21
5.5.8 Receiving V2X information event notifications about the provisioning information changes for V2X
communication over PC5 . 21
5.5.9 V2X message interoperability. 22
5.5.9.1 V2X message subscribe . 22
5.5.9.2 V2X message publication . 22
5.5.9.3 V2X message notification . 23
5.6 Conclusions on VIS . 23
6 Data model . 23
6.1 Introduction . 23
6.2 Resource data types . 24
6.2.1 Introduction. 24
6.2.2 Type: UuUnicastProvisioningInfo . 24
6.2.3 Type: UuMbmsProvisioningInfo . 24
6.2.4 Type: Pc5ProvisioningInfo . 25
6.2.5 Type: PredictedQos. 25
6.2.6 Type: V2xMsgPublication . 26
ETSI
4 ETSI GS MEC 030 V2.1.1 (2020-04)
6.3 Subscription data types . 26
6.3.1 Introduction. 26
6.3.2 Type: ProvChgUuUniSubscription . 26
6.3.3 Type: ProvChgUuMbmsSubscription . 27
6.3.4 Type: ProvChgPc5Subscription . 27
6.3.5 Type: V2xMsgSubscription . 28
6.3.6 Type: SubscriptionLinkList . 29
6.4 Notifications data types . 29
6.4.1 Introduction. 29
6.4.2 Type: ProvChgUuUniNotification . 29
6.4.3 Type: ProvChgUuMbmsNotification . 29
6.4.4 Type: ProvChgPc5Notification . 30
6.4.5 Type: V2xMsgNotification . 30
6.5 Referenced structured data types . 31
6.5.1 Introduction. 31
6.5.2 Type: TimeStamp . 31
6.5.3 Type: LocationInfo . 31
6.5.4 Type: Plmn. 32
6.5.5 Type: Ecgi . 32
6.5.6 Type: FddInfo . 32
6.5.7 Type: TddInfo . 32
6.5.8 Type: V2xApplicationServer . 33
6.5.9 Type: UuUniNeighbourCellInfo . 33
6.5.10 Type: V2xServerUsd . 33
6.5.11 Type: UuMbmsNeighbourCellInfo . 33
6.5.12 Type: Pc5NeighbourCellInfo . 34
6.6 Referenced simple data types and enumerations . 34
6.6.1 Introduction. 34
6.6.2 Type: CellId . 34
6.6.3 Type: Earfcn . 34
6.6.4 Type: TransmissionBandwidth . 35
7 API definition . 35
7.1 Introduction . 35
7.2 Global definitions and resource structure . 35
7.3 Resource: uu_unicast_provisioning_info . 37
7.3.1 Description . 37
7.3.2 Resource definition . 37
7.3.3 Resource methods . 37
7.3.3.1 GET . 37
7.3.3.2 PUT . 38
7.3.3.3 PATCH . 38
7.3.3.4 POST . 38
7.3.3.5 DELETE . 38
7.4 Resource: uu_mbms_provisioning_info . 39
7.4.1 Description . 39
7.4.2 Resource definition . 39
7.4.3 Resource methods . 39
7.4.3.1 GET . 39
7.4.3.2 PUT . 40
7.4.3.3 PATCH . 40
7.4.3.4 POST . 40
7.4.3.5 DELETE . 40
7.5 Resource: pc5_provisioning_info . 41
7.5.1 Description . 41
7.5.2 Resource definition . 41
7.5.3 Resource methods . 41
7.5.3.1 GET . 41
7.5.3.2 PUT . 42
7.5.3.3 PATCH . 42
7.5.3.4 POST . 42
7.5.3.5 DELETE . 42
ETSI
5 ETSI GS MEC 030 V2.1.1 (2020-04)
7.6 Resource: provide_predicted_qos . 43
7.6.1 Description . 43
7.6.2 Resource definition . 43
7.6.3 Resource methods . 43
7.6.3.1 GET . 43
7.6.3.2 PUT . 43
7.6.3.3 PATCH . 43
7.6.3.4 POST . 43
7.6.3.5 DELETE . 44
7.7 Resource: publish_v2x_message . 44
7.7.1 Description . 44
7.7.2 Resource definition . 44
7.7.3 Resource methods . 45
7.7.3.1 GET . 45
7.7.3.2 PUT . 45
7.7.3.3 PATCH . 45
7.7.3.4 POST . 45
7.7.3.5 DELETE . 46
7.8 Resource: subscriptions . 46
7.8.1 Description . 46
7.8.2 Resource definition . 46
7.8.3 Resource methods . 47
7.8.3.1 GET . 47
7.8.3.2 PUT . 48
7.8.3.3 PATCH . 48
7.8.3.4 POST . 48
7.8.3.5 DELETE . 50
7.9 Resource: existing subscription . 50
7.9.1 Description . 50
7.9.2 Resource definition . 50
7.9.3 Resource methods . 50
7.9.3.1 GET . 50
7.9.3.2 PUT . 51
7.9.3.3 PATCH . 53
7.9.3.4 POST . 53
7.9.3.5 DELETE . 53
Annex A (informative): Mapping of permissions for RESTful API and topic based alternative
transport . 55
A.1 Overview . 55
A.2 Mapping of permissions - RESTful and topic based alternative transport . 55
Annex B (informative): Complementary material for API utilization . 57
Annex C (informative): Radio access network scenario options for V2X communication . 58
History . 59

ETSI
6 ETSI GS MEC 030 V2.1.1 (2020-04)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Multi-access Edge
Computing (MEC).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
7 ETSI GS MEC 030 V2.1.1 (2020-04)
1 Scope
The present document focuses on a MEC Vehicular-to-Everything (V2X) Information Service (VIS), in order to
facilitate V2X interoperability in a multi-vendor, multi-network and multi-access environment. It describes the V2X-
related information flows, required information and operations. The present document also specifies the necessary API
with the data model and data format.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI GS MEC 001: "Multi-access Edge Computing (MEC); Terminology".
[2] IETF RFC 2818: "HTTP Over TLS".
NOTE: Available at https://tools.ietf.org/html/rfc2818.
[3] IETF RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".
NOTE: Available at https://tools.ietf.org/html/rfc5246.
[4] IETF RFC 6749: "The OAuth 2.0 Authorization Framework".
NOTE: Available at https://tools.ietf.org/html/rfc6749.
[5] IETF RFC 6750: "The OAuth 2.0 Authorization Framework: Bearer Token Usage".
NOTE: Available at https://tools.ietf.org/html/rfc6750.
[6] ETSI TS 102 894-2: "Intelligent Transport Systems (ITS); Users and applications requirements;
Part 2: Applications and facilities layer common data dictionary".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI GS MEC 009: "Multi-access Edge Computing (MEC); General principles for MEC Service
APIs".
ETSI
8 ETSI GS MEC 030 V2.1.1 (2020-04)
[i.2] ETSI GS MEC 011: "Multi-access Edge Computing (MEC); Edge Platform Application
Enablement".
[i.3] OpenAPI™ Specification.
NOTE 1: Available at https://github.com/OAI/OpenAPI-Specification.
NOTE 2: OpenAPI Specification and OpenAPI Initiative and their respective logos, are trademarks of the Linux
Foundation.
[i.4] ETSI GR MEC 022: "Multi-access Edge Computing (MEC); Study on MEC Support for V2X Use
Cases".
[i.5] ETSI TS 123 285: "Universal Mobile Telecommunications System (UMTS); LTE; Architecture
enhancements for V2X services (3GPP TS 23.285)".
[i.6] ETSI TS 129 388: "LTE; V2X Control Function to Home Subscriber Server (HSS) aspects (V4);
Stage 3 (3GPP TS 29.388)".
[i.7] ETSI TS 129 389: "LTE; Inter-V2X Control Function Signalling aspects (V6); Stage 3 (3GPP
TS 29.389)".
[i.8] ETSI TS 136 300: "LTE; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (3GPP
TS 36.300)".
[i.9] ETSI TS 136 423: "LTE; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2
Application Protocol (X2AP) (3GPP TS 36.423)".
[i.10] ETSI TS 136 413: "LTE; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1
Application Protocol (S1AP) (3GPP TS 36.413)".
[i.11] ETSI TS 136 331: "LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource
Control (RRC); Protocol specification (3GPP TS 36.331)".
[i.12] ETSI TS 136 321: "LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access
Control (MAC) protocol specification (3GPP TS 36.321)".
[i.13] ETSI TS 136 214: "LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer;
Measurements (3GPP TS 36 214)".
[i.14] ETSI GS MEC 003: "Multi-access Edge Computing (MEC); Framework and Reference
Architecture".
[i.15] ETSI GS MEC 012: "Multi-access Edge Computing (MEC); Radio Network Information API".
[i.16] ETSI GS MEC 013: "Multi-access Edge Computing (MEC); Location API".
[i.17] ETSI GS MEC 028: "Multi-access Edge Computing (MEC); WLAN Information API".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS MEC 001 [1] apply.
3.2 Symbols
Void.
ETSI
9 ETSI GS MEC 030 V2.1.1 (2020-04)
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS MEC 001 [1] and the following apply:
API Application Programming Interface
CN Core Network
C-V2X Cellular V2X
DL Downlink
E2E End-to-End
eNB evolved Node B
E-UTRAN Evolved UMTS Terrestrial Radio Access Network
FDD Frequency Division Duplex
FOTA Firmware Over The Air
gNB 5G Node B
HSS Home Subscriber Server
HTTP HyperText Transfer Protocol
HTTPS HTTP over TLS
ITS Intelligent Transport Systems
JSON Javascript Object Notation
MBMS Multimedia Broadcast Multicast Services
MNO Mobile Network Operator
NF Network Function
OEM Original Equipment Manufacturer
PLMN Public Land Mobile Network
QoS Quality of Service
RNI Radio Network Information
RSU Road Side Unit
SDP Session Description Protocol
SOTA Software Over The Air
TDD Time Division Duplex
TLS Transport Layer Security
UDP User Datagram Protocol
UL UpLink
UMTS Universal Mobile Telecommunications System
URI Uniform Resource Identifier
V2X Vehicle-to-everything
VIS V2X Information Service
4 Overview
The present document specifies the VIS API to facilitate V2X interoperability in a multi-vendor, multi-network and
multi-access environment.
Clause 5 presents reference scenarios for the VIS service and lists the functionalities of the service. It also describes the
information flows used for VIS.
The information that can be exchanged over the VIS API is described in clause 6 which provides detailed descriptions
of all information elements that are used for VIS.
Clause 7 describes the actual VIS API providing detailed information of how information elements are mapped into a
RESTful API design.
ETSI
10 ETSI GS MEC 030 V2.1.1 (2020-04)
5 Description of the service (informative)
5.1 Reference scenarios for the VIS service
According to requirements in ETSI GR MEC 022 [i.4], multi-access, multi-network and multi-operator scenarios are
the reference assumptions motivating the need for MEC normative work on this area. Figure 5.1-1 shows all the
scenarios applicable to V2X services. In particular:
• Some V2X services can be managed by OEMs (the so called "Vehicle OEMs scenario"), and, thus, it is
reasonable to consider both single and multi-operator scenarios for such services. Note that V2X services are
expected to be provided by different network operators in the same country and/or in different countries.
• Similarly, the same applies when the "ITS Operator scenario" is considered, that may additionally provide
services for different vehicle OEMs. An ITS operator may need to provide a country-wide V2X service, by
exploiting different operators' networks (deploying different MEC systems), and offering this service to
vehicles belonging to different OEMs. Note that also in this case, V2X services are expected to be provided by
different network operators in the same country and/or in different countries.
Vehicle OEM scenario,
ITS operator, ITS operator,
single MNO
single MNO single OEM, single MNO
Vehicle OEM scenario,
ITS operator, ITS operator,
multiple MNO
multiple MNO multiple OEM, multiple MNO

Figure 5.1-1: Reference scenarios relevant to the VIS service
As a consequence, in order to enable all use cases, the MEC V2X Information Service (VIS) should support C-V2X
systems implemented in the most general scenarios. In particular, these scenarios should assume the presence of
multiple MEC vendors and the need to enable interoperable data exchange between them. Moreover, multi-operator
interoperability is a key aspect for ensuring service continuity, and it is described in clause 5.2.
5.2 Multi-operator scenarios and V2X services
The left hand side of figure 5.2-1 shows a typical multi-operator scenario, highlighting the case of temporary absence of
radio coverage, e.g. in roaming situations. As showed in the right-hand side of figure 5.2-1, in a traditional V2X system
(without the VIS service) the interconnection between MNOs is terminated at the remote side, with clear disadvantages
in terms of high E2E latency; on the other hand, thanks to the exploitation of the VIS service (enabling also a
"horizontal communication" between MEC systems), the interconnection between MNOs can be realized with low E2E
latency.
ETSI
11 ETSI GS MEC 030 V2.1.1 (2020-04)

Figure 5.2-1: (left): Example of a multi-operator scenario for V2X services;
(right): Example of path for data exchange without the VIS service (in red) and
with the VIS service (in green)
V2X service needs to be provided across all the territory including both operators' coverage areas, as well as when
leaving the coverage area of one operator and entering the coverage area of the other operator without any service
disruption and guaranteeing E2E performance. For that purpose, VIS exposes information on PC5 configuration
parameters and manages the multi-operator environment, especially when a UE is out of coverage.
5.3 V2X service continuity in multi-operator operation scenarios
5.3.1 Introduction
Wireless communication is a key enabling technology of co-operative intelligent transportation systems. Road users
(including vehicles, cyclists, pedestrians) involved in the communication may use services provided by different
operators.
A mobile operator network is typically region specific or country specific, which provides services directly to its own
customers (subscribers), while providing communications to other operators' customers via the core network level
interworking between two operators' networks. To maintain the V2X service continuity (often with low latency
requirement) for road users becomes very challenging especially when such road users (e.g. vehicular UEs) move from
one PLMN to another.
Figure 5.3.1-1: Example V2X use case: inter-PLMN service continuity
ETSI
12 ETSI GS MEC 030 V2.1.1 (2020-04)
To enable service continuity in such use cases, mobile network level interworking among different PLMNs is necessary
as specified in 3GPP specifications ETSI TS 123 285 [i.5], ETSI TS 129 388 [i.6] and ETSI TS 129 389 [i.7].
Furthermore, inter-MEC system coordination is also required to prepare in advance the UEs in transit (based on the
agreements among operators, roam or handover to a new PLMN) and reduce the interruption time.
The service consumers communicate with VIS over the VIS API to get the necessary V2X service provisioning
information for the visiting PLMN in support of inter-PLMN service continuity. Both the MEC applications and the
MEC platform may consume the VIS; and both the MEC platform and the MEC applications may be the providers of
the V2X information.
The VIS API supports both queries and subscriptions (pub/sub mechanism) that are used over the RESTful API or over
alternative transports such as message bus. Alternative transports are not specified in detail in the present document. For
RESTful architectural style, the present document defines the HTTP protocol bindings.
5.4 VIS functionalities
5.4.1 Overview
The MEC standards have been designed to facilitate V2X interoperability in a multi-vendor, multi-network and
multi-access environment. The introduction of the VIS API is aimed at helping the ecosystem adopt MEC for
automotive use cases. These use cases may involve different car makers, OEM suppliers, network infrastructure
vendors, MEC vendors, application/content providers and other stakeholders. Therefore, it is critical that all MEC
related interoperability reference points involving the potential stakeholders are fully specified.
In particular, the VIS defined in the present document will permit information exposure, pertinent to the support of
automotive use cases, to MEC application instances. It will also permit a single ITS operator to offer a V2X service
over a region that may span different countries and involve multiple network operators, MEC systems and MEC
application providers.
For that purpose, the MEC VIS includes the following functionalities:
1) Gathering of PC5 V2X relevant information from the 3GPP network (e.g. the list of authorized UEs, the
relevant information about the authorization based on the UE subscription and the relevant PC5 configuration
parameters).
2) Exposure of this information to MEC apps (also potentially belonging to different MEC systems).
3) Enablement of MEC apps to communicate securely with the V2X-related 3GPP core network logical functions
(e.g. V2X control function).
4) Enablement of MEC apps in different MEC systems to communicate securely with each other.
5) Possibly gathering and processing information available in other MEC APIs (e.g. RNI API, see ETSI
GS MEC 012 [i.15], Location API, see ETSI GS MEC 013 [i.16], WLAN API, see ETSI GS MEC 028, [i.17],
etc.) in order to predict radio network congestion and provide suitable notifications to the UE.
From that perspective, the VIS service is relevant to Mp1 and Mp3 reference points in the MEC architecture. In
particular, the relevant information is exposed to MEC apps via the Mp1 reference point. Potential impacts on Mp3
reference point (e.g. enabling the possibility to transfer this information between different MEC platforms) are
introduced in ETSI GS MEC 003 [i.14] and are out of the scope of the present document.
NOTE 1: The VIS API provides information to MEC applications in a standardized way; this is essential for
interoperability in multi-vendor scenarios; nevertheless, it is acknowledged that MEC applications may
communicate in a direct way (i.e. without the use of MEC platform).
NOTE 2: Inter-system communication may be realized between MEOs. As an alternative, or, in addition to that,
possible Mp3 enhancements (or new reference points between MEC systems) may be defined. This is out
of the scope of the present document.
ETSI
13 ETSI GS MEC 030 V2.1.1 (2020-04)

Figure 5.4.1-1: Example of application instances in a V2X service
...