ETSI GS MEC 045 V3.1.1 (2024-03)

Multi-access Edge Computing (MEC); QoS Measurement API

DGS/MEC-0045v311QoSMeasure

General Information

• Status: Not Published
• Technical Committee: MEC - Multi-access Edge Computing
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Due Date: 12-Apr-2024
• Completion Date: 21-Mar-2024

Standards Content (Sample)

GROUP SPECIFICATION
Multi-access Edge Computing (MEC);
QoS Measurement 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 045 V3.1.1 (2024-03)

Reference
DGS/MEC-0045v311QoSMeasure
Keywords
API, measurement, MEC, QoS, service
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
https://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
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
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 2024.
All rights reserved.
ETSI
3 ETSI GS MEC 045 V3.1.1 (2024-03)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Overview . 7
5 Description of the services (informative) . 7
5.1 Reference scenarios . 7
5.1.1 QoS metrics . 7
5.1.2 Synchronization delay. 8
5.1.3 QMS introduction . 9
5.1.4 Use cases . 9
5.1.4.1 Assistance of application deployment and migration . 9
5.1.4.2 Monitoring network performance . 9
5.1.4.3 Measuring QoS by area . 10
5.1.4.4 Measuring QoS for the application undeployed at MEC system . 11
5.2 Sequence diagrams . 12
5.2.1 General . 12
5.2.2 QoS measurement subscription. 12
5.2.3 Subscription cancellation . 13
5.2.4 Getting all QoS measurement subscription . 13
5.2.5 Getting a specific QoS measurement subscription . 13
5.2.6 Updating a specific QoS measurement subscription . 14
6 Data model . 14
6.1 Introduction . 14
6.2 Resource data types . 14
6.3 Subscription data types . 14
6.3.1 Type: NotificationSubscriptionList . 14
6.3.2 Type: QoSMeasureSubscription . 15
6.3.3 Type: QoSEventSubscription. 16
6.4 Notifications data types . 18
6.4.1 Type: TestNotification . 18
6.4.2 Type: QoSMeasureNotification . 18
6.4.3 Type: QoSEventNotification . 19
6.5 Referenced structured data types . 19
6.5.1 Introduction. 19
6.5.2 Type: WebsockNotifConfig . 19
6.5.3 Type: AreaInfo . 20
6.5.4 Type: Point. 20
6.5.5 Type: TimeStamp . 20
6.5.6 Type: ReportingCtrl . 20
6.6 Referenced simple data types and enumerations . 21
6.6.1 Introduction. 21
6.6.2 Type: LinkType . 21
6.6.3 Enumeration: MetricType . 21
6.6.4 Enumeration: QoSEvent . 21
ETSI
4 ETSI GS MEC 045 V3.1.1 (2024-03)
7 API definition . 22
7.1 Introduction . 22
7.2 Global definitions and resource structure . 22
7.3 Resource: a list of subscriptions . 23
7.3.1 Description . 23
7.3.2 Resource definition . 23
7.3.3 Resource methods . 23
7.3.3.1 GET . 23
7.3.3.2 PUT . 24
7.3.3.3 PATCH . 24
7.3.3.4 POST . 24
7.3.3.5 DELETE . 24
7.4 Resource: individual subscription . 25
7.4.1 Description . 25
7.4.2 Resource definition . 25
7.4.3 Resource methods . 25
7.4.3.1 GET . 25
7.4.3.2 PUT . 26
7.4.3.3 PATCH . 26
7.4.3.4 POST . 26
7.4.3.5 DELETE . 26
Annex A (informative): Complementary material for API utilization . 28
History . 29

ETSI
5 ETSI GS MEC 045 V3.1.1 (2024-03)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
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.
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
6 ETSI GS MEC 045 V3.1.1 (2024-03)
1 Scope
The present document focuses on introducing QoS Measurement service to provide network performance related
metrics including predictive QoS provided by AI/ML components if available. It describes the reference scenarios and
sequence diagrams and defines the data model and API. The present document carefully considers the relevant work of
other SDOs (e.g. 3GPP, 5GAA, etc.) and all relevant work done in ETSI.
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-IEG 006: "Mobile Edge Computing; Market Acceleration; MEC Metrics Best
Practice and Guidelines".
[2] ETSI GS MEC 009: "Multi-access Edge Computing (MEC); General principles, patterns and
common aspects of MEC Service APIs".
[3] OMA-TS-REST-NetAPI-ZonalPresence-V1-0-20160308-C: "RESTful Network API for Zonal
Presence".
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] 3GPP TR 22.847: "3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects; Study on supporting tactile and multi-modality communication services;
Stage 1 (Release 18)".
[i.2] 3GPP TS 29.522: "3rd Generation Partnership Project; Technical Specification Group Core
Network and Terminals; 5G System; Network Exposure Function Northbound APIs; Stage 3
(Release 18)".
[i.3] ETSI GR MEC 018: "Mobile Edge Computing (MEC); End to End Mobility Aspects".
[i.4] 3GPP TS 23.501: "3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 18)".
[i.5] ETSI GS MEC 013: "Multi-access Edge Computing (MEC); Location API".
[i.6] ETSI GS MEC 030: "Multi-access Edge Computing (MEC); V2X Information Services API".
ETSI
7 ETSI GS MEC 045 V3.1.1 (2024-03)
[i.7] ETSI GR MEC 001: "Multi-access Edge Computing (MEC); Terminology".
[i.8] OpenAPI™ Specification.
[i.9] ETSI GS MEC 010-2: "Multi-access Edge Computing (MEC); MEC Management;
Part 2: Application lifecycle, rules and requirements management".
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GR MEC 001 [i.7] and the following apply:
QMS QoS Measurement Service
4 Overview
The present document specifies QMS API that enables the collection and provision of the network performance related
metrics for helping the API consumers monitor, predict and/or improve the network performance.
Clause 5 presents the reference scenarios for QoS measurement and also describes the relevant information flows.
Clause 6 describes the data models that can be exchanged over the QoS Measurement APIs, which provide detailed
descriptions of all information elements used for QoS Measurement.
Clause 7 defines the actual QoS Measurement APIs providing detailed information of how information elements are
mapped into a RESTful API design.
5 Description of the services (informative)
5.1 Reference scenarios
5.1.1 QoS metrics
QoS is used to measure and control network service quality. Following the rapid development of the mobile network,
the services are becoming much more diverse, and the network traffic is flooding. Consequently, it becomes more and
more challenging to handle severe network congestion, increasing packet delay, and even packet loss that lead to the
degradation of the quality of experience. From the operation and maintenance cost perspective, it is not feasible to solve
or mitigate the problems only by increasing bandwidth. A set of QoS metrics are defined to describe the differentiated
requirements of the network quality for different network services, and specific QoS policies would be implemented
according to the service characteristics to improve the overall usage of network resources.
ETSI
8 ETSI GS MEC 045 V3.1.1 (2024-03)
The important QoS metrics include but not limited to:
• Network delay: It is defined as the latency for a data packet to travel across the network from one
communication endpoint to another. Some services are sensitive to network delays. For example, Virtual
Reality (VR) games can provide a better experience comparing to traditional games, and most immersive VR
games require the end-to-end delay to be less than 20 ms. The VR game participants may feel inconveniences
if the network delay increases.
• Jitter: Different packets of a service flow delivered in the network have different delay values. The deviation
of delay is called jitter. As one of the most crucial factors to quality of service, jitter is mainly caused by
queueing time. jitter cannot be avoided and has no impact if the value is small enough. Many services, like
eXtended Reality (XR), are sensitive to jitter. Caching packets may be leveraged to overcome the exceeding
jitter.
• Packet loss: If a small number of packets are lost, services are not severely affected. But severe packet loss
could impact transport efficiency. Hence, it is worth focusing on the statistical metric of packet loss - packet
loss ratio, which refers to the percentage of lost packets to the overall transmitted packets during network
transmission.
• Throughput: It refers to the bit numbers delivered from one communication endpoint to another in a fixed
period of time (e.g. 1 second). It can be defined in downlink or uplink. The unit of throughput is e.g. bit/s or
Kbit/s. The throughput's influence on applications is described in ETSI GS MEC-IEG 006 [1].
5.1.2 Synchronization delay
In addition to measuring the QoS metrics for a single flow, the emergence of multi-modal services brings the
requirements of multi-flow QoS guarantee for networks. Multi-modal service refers to the combination of multiple data
flows to provide users with an immersive experience. In a VR game, a user may wear a VR helmet (visual, auditory)
and VR gloves (tactile) to receive game information. Meanwhile, the game server (MEC application) needs to collect
environment information about the user, for instance, collecting sound by using a microphone, collecting user action
information by using a camera, and collecting intensity of user actions by using a sensor.
For multi-modal service, the QoS metrics of a single data flow are not enough to fully reflect the overall quality of
service. It is necessary to provide a manner to simultaneously measure and monitor the synchronization delay, i.e. the
network delay difference between two flows. Sometimes, all the audio, video, and tactile flows work very well, but the
synchronization delays between them may still make users feel inconveniences. For example, an explosion in a
VR game (involving an audio stream, video stream, and tactile stream) can only make the game experience more
realistic when synchronization delays of multiple streams with dependencies are in a reasonable range. In this case, a
synchronization threshold may be provided by the application. If the synchronization threshold is exceeded, a data
asynchronization event will be notified to the application. The synchronization threshold is described in 3GPP
TR 22.847 [i.1].
Figure 5.1.2-1: Downlink example for Multi-modal service
ETSI
9 ETSI GS MEC 045 V3.1.1 (2024-03)
5.1.3 QMS introduction
A QMS is a MEC service used to measure the quality of an edge service by monitoring the data flows associated with
one or more terminal devices accessing the edge service. A consumer of the QMS may be a MEC application or the
MEP. Consumers can invoke QMS APIs through the Mp1 reference point to query QoS information, create QoS
monitoring tasks, or subscribe to QoS monitoring results. Considering the system burden, part of the data flows
associated with a service, rather than all data flows, could be measured to reflect the network performance.
The QMS could leverage the way provided by the MEC access network to get the network performance related to a
MEC application. The technologies of MEC access network are various e.g. 5G, WLAN, Fibre, Cable. Not only the 5G
network, the QMS can work with any MEC access network, as long as they have a method to measure the performance.
The customers of the QMS do not need to understand the detailed network topology or the type of MEC access
network. For example, if 5G UEs are accessing a video service provided by a MEC instance that wants to measure 5G
network performance, the MEC instance can invoke the QMS API to pass the active UE list to QMS and create a
measuring task. After that, the QMS could utilize the "QoS-Monitoring" capability (as described in 3GPP
TS 29.522 [i.2]) exposed by NEF to get the 5G network performance.
NOTE: MEC access network is a terminology in the MEC context, which represents the network working
between a terminal device and the edge network at which a MEC host is located. For 5G, the MEC access
network consists of a radio network, a core network and a transport network connecting them.
5.1.4 Use cases
5.1.4.1 Assistance of application deployment and migration
The edge service running at different MEC hosts may have different performances due to the difference in deployment
locations and access networks. For example, some MEC applications may be deployed at the city level to provide
services for multiple enterprises at the same time. Other MEC applications may be deployed on-premises because of
security or low latency requirements. The various access networks and the heterogeneous infrastructure of edge
computing also bring differentiated network service capabilities.
It is implementation dependent on how to measure or predict the network quality a MEC host can provide. A possible
way is that each MEC host could instantiate an application instance communicating with one or more test UEs. And
each MEP invokes the QMS APIs to create a task for QoS measurement and obtains a result regarding network delay
under the Best-Effort model by monitoring the QoS information of test flows between the test UEs and the test MEC
application instance.
Before an application is deployed at a MEC host, the network QoS of different MEC hosts needs to be evaluated to
determine whether the MEC host can meet its QoS requirements. According to the requirements of ETSI
GS MEC 010-2 [i.9], when deploying an application, the application provider can use the optional "appLatency"
attribute in the AppD to describe the maximum delay that the MEC application can tolerate. QMS can be used to
evaluate the network latency of the target MEC host. Based on that, the MEO can easily select an appropriate MEC host
to deploy the application.
UE's movement may lead to service discontinuity (two scenarios regarding mobility in the MEC system are described in
clause 4.1.2 of ETSI GR MEC 018 [i.3]). If a UE moves out of the coverage area of the source MEC host, the MEC
system may need to migrate the MEC application serving the UE from the source MEC host to the target MEC host. Or
the MEC system may transfer the UE context to the target application instance if the application has been instantiated at
the target MEC host already. If more than one MEC hosts are candidate, QMS can measure network delay values to
assist in selecting the most appropriate target MEC host for delay-sensitive applications.
5.1.4.2 Monitoring network performance
MEC application instances (e.g. server applications) can use QMS to monitor QoS in various forms. When noticing the
service quality for some of its subscribers (e.g. client applications residing in the terminals) deteriorates, the MEC
application as the consumer can provide the subscriber IDs (e.g. MSISDN, other anonymous ID) to enable the QMS to
monitor the network performance for these target subscribers. If the MEC application wants to measure the QoS of
some specific flows, it could provide a set of flow information (e.g. 5-tuple) to QMS.
ETSI
10 ETSI GS MEC 045 V3.1.1 (2024-03)
A MEC application can also enable a QoS monitoring task by providing a flow sampling rate rather than concrete
subscriber information. This method avoids security risks caused by the transmission of private information. Different
sampling rates can help the system flexibly adjust the load of monitoring tasks as required. For example, the consumer
could ask the QMS to monitor "x" percent of flows associated with the target application by providing a sampling rate
as "x". The QMS could identify the target flows by checking 5-tuple or 7-tuple, e.g. the IP address of the target edge
server (target application instance). Then, The QMS selects "x" percent of target flows to monitor and measure the QoS
performance.
Figure 5.1.4.2-1: Monitoring data flows according to sampling rate in 5G network
The service consumer provides a sampling rate for network performance monitoring, as illustrated in Figure 5.1.4.2-1,
which consists of the following steps:
1) A service consumer (an application instance) sends a request carrying a sampling rate and server IP address to
create a monitoring task. Compared to providing subscriber IDs, this method applies to scenarios in which the
consumer does not know the specific UE information.
2) The QMS enables the data plane to filter the data flows by the server IP address which could be source or
destination IP address. After that, the QMS can get a list of UEs who are accessing the target server. It needs to
select part of the UEs as monitoring targets according to the sampling rate received in step 1).
3) The QMS producer triggers 5GS to enable the QoS monitoring process (see 3GPP TS 23.501 [i.4]).
4) After measurement, the UPF reports the results to the QMS producer.
5) The QMS could converge the results and notify the consumer of the final result.
NOTE 1: The N6 delay that is not included in QoS monitoring result normally is very small and could be neglected
when the MEP and UPF are co-deployed.
NOTE 2: If the MEC host locates in the untrusted domain, the QMS as an AF should communicate with 5GS
through NEF.
5.1.4.3 Measuring QoS by area
The QMS can measure the QoS according to the area information provided by the consumer. In that way, the measuring
task will be enabled if the measuring targets stay in a specific area. The consumer could leverage the QMS to monitor
the network performance of some specific areas and get a notification if network degradation happens.
In the autonomous driving scenario, a V2X application deployed at the edge collects environmental information
(e.g. vehicle flow rate, road status) from the cars or the RSUs to make a decision for route planning. Generally, this
service has high requirements on QoS for handling the newest information promptly. The candidate routes may span
multiple areas whose network performances are different. The QMS needs to provide a service enabling the QoS
measuring task when the terminal devices stay in specific areas, but for this use case, the QMS also needs to merge all
the measuring results related to one area to get the network performance of this area.
ETSI
11 ETSI GS MEC 045 V3.1.1 (2024-03)

Figure 5.1.4.3-1: QMS measuring QoS by area
Figure 5.1.4.3-1 depicts a scenario in which the QMS help switch route when some trouble happens in one cell:
1) The V2X application could invoke the QMS API to create several tasks to measure and monitor the QoS of
areas associated with potential routes.
2) The QMS producer receives area information provided in step1 and may leverage Location API described in
ETSI GS MEC 013 [i.5] to get the measuring targets in Cell2.
3) The QMS measures the targets in Cell2 and evaluate the network performance of Cell2.
4) When there is a QoS degradation in Cell2, the QMS could notify the V2X application that the quality of
service cannot satisfy the requirement of V2X service.
5) The V2X application receives the notification from the QMS, and decides to switch the red car to route2.
NOTE: The VIS described in ETSI GS MEC 030 [i.6] provides a similar service to get predicted QoS for a
vehicular UE with potential routes. The QMS function described in this clause focuses on evaluating the
specific area QoS based on currently active users accessing the target service. The QMS could be
regarded as one possible solution to realize the VIS for getting predicted QoS.
5.1.4.4 Measuring QoS for the application undeployed at MEC system
The QMS could help the consumers to measure the QoS regarding to the network on which the application instance
works as a server. After instantiating the application, the consumer could leverage QMS to monitor the traffic related to
the application instance and get the notification if the network performance degrades. But in some scenarios, the
consumer may want to measure or evaluate the network performance before the application instantiation.
For a delay sensitive application, the application provider may want to know if the performance of the edge network
could satisfy the application's requirement. In order to obtain an accurate result, the application provider has to deploy
the application at different MEC hosts (Generally, the candidates are multiple and the application provider need to
compare the performances to make a final decision) to start a series of tests. Unfortunately, application deployment
normally is accompanied by complicated and lengthy business negotiations with the operators. And after the tests, if the
network metrics, such as latency, packet loss ratio, are not qualified for the application, the application provider has to
remove the application instance and application package.
ETSI
12 ETSI GS MEC 045 V3.1.1 (2024-03)
In another scenario, the application server and the application client are still developed in laboratory environment, and
the application provider may need to find a way to generate the data flows that could be used to simulate the network
performance in real world. Leveraging these data flows, the application provider could adjust software parameters
(e.g. minimum buffer, congestion timeout interval etc.) to improve the algorithm for better performance. For example,
different congestion control algorithms adapt to different network models. If the network congestion is severe, the
application may need to endure a longer congestion timeout. Another example is that the application provider may need
to design a larger buffer if the flow data burst, which is related to packet length and packet interval, is common.
NOTE: How to measure the QoS of the edge network when the application is not deployed at MEC system is not
specified in the present document.
5.2 Sequence diagrams
5.2.1 General
The following clauses describe how the service consumers interact with the QoS Measurement Service over QMS API
to obtain the current QoS and/or predictive QoS. The related sequence diagrams are presented.
5.2.2 QoS measurement subscription
The QoS measurement subscription is the procedure for the QMS consumers to request to receive notifications about
QoS measurement. The measurement may be one-off for an immediate query, or periodical for a long time. The QMS
consumers could provide a set of terminal device IDs and/or a set of flow filters as the parameters for the QoS
measurement task. The QMS consumers could also provide area information and/or available time windows to control
the scope of the QoS measurement.
The QMS consumers could leverage the QMS to monitor the quality of specific traffics to get notifications related to
QoS event. In this mode, the QMS consumers could set one or more conditions for reporting QoS events, e.g. reporting
when the network latency is larger than 20 ms.
Figure 5.2.2-1 shows a flow for QoS measurement subscription.

Figure 5.2.2-1: Flow of QoS measurement subscription
1) The QMS consumer (API Client) subscribes to QoS measurement by sending a request to create a resource
containing the subscription details.
2) The QMS returns a response with a resource URI containing the subscriptionId.
3) The QMS reports the up-to-data subscribed information to the QMS consumer by sending a message with the
message body containing QoS measurement notification to the callbackURL, which includes QoS
measurement, e.g. latency, jitter, etc.
4) The QMS consumer returns a response with the code 204.
ETSI
13 ETSI GS MEC 045 V3.1.1 (2024-03)
5.2.3 Subscription cancellation
The Subscribe Cancellation is the procedure for QMS consumers to cancel the subscription, with which the QMS stop
reporting the subscribed information to the QMS consumer.
Figure 5.2.3-1 shows a flow for Subscribe cancellation.

Figure 5.2.3-1: Flow of subscription cancellation
1) The QMS consumer (API Client) unsubscribes to notifications by sending a request to delete the resource URI
containing the subscriptionId.
2) The QMS returns a successful response if the subscription cancellation is accepted.
5.2.4 Getting all QoS measurement subscription
Figure 5.2.4-1 shows a scenario where the API Client (service consumer) sends a request to query all the subscription
information related to QoS measurement.

Figure 5.2.4-1: Flow of Getting QoS measurement subscription
1) API Client (service consumer) sends a request to get all the subscription information related to QoS
measurement.
2) QMS returns a response with "200 OK" with the message body containing the list of subscription information.
5.2.5 Getting a specific QoS measurement subscription
Figure 5.2.5-1 shows a scenario where the API Client (service consumer) sends a request to query specific subscription
information by subscriptionId.
ETSI
14 ETSI GS MEC 045 V3.1.1 (2024-03)

Figure 5.2.5-1: Flow of Getting a specific QoS measurement subscription
1) API Client (service consumer) sends a request to get specific subscription information by subscriptionId.
2) QMS returns a response with "200 OK" with the message body containing the specific subscription
information.
5.2.6 Updating a specific QoS measurement subscription
Figure 5.2.6-1 shows a scenario where the API Client (service consumer) sends a request to update specific subscription
information by subscriptionId. A new subscription structure should be carried in the request message body to replace
the old subscription information.

Figure 5.2.6-1: Flow of Updating a specific QoS measurement subscription
1) API Client (service consumer) sends a request to update specific subscription information by subscriptionId.
2) QMS returns a response with "200 OK" with the message body containing the updated subscription
information.
6 Data model
6.1 Introduction
The following clauses provide the description of the data model.
6.2 Resource data types
Void.
6.3 Subscription data types
6.3.1 Type: NotificationSubscriptionList
This type contains a list of subscriptions.
ETSI
15 ETSI GS MEC 045 V3.1.1 (2024-03)
Table 6.3.1-1: Definition of type NotificationSubscriptionList
Attribute name Data type Cardinality Description
subscription Structure (inlined) 0.N
>href Uri 1 The URI referring to the subscription.
>subscriptionType String 1 Type of the subscription. The string shall
be set according to the
"subscriptionType" attribute of the
associated subscription data type defined
in clauses 6.3.2 and 6.3.3:
• "QoSMeasureSubscription".
• "QoSEventSubscription".
resourceURL LinkType 1 Self-referring URL.

6.3.2 Type: QoSMeasureSubscription
This type represents a subscription to the notifications from QMS about QoS measurement.
The attributes of the QoSMeasureSubscription shall follow the indications provided in table 6.3.2-1.
Table 6.3.2-1: Definition of type QoSMeasureSubscription
Attribute name Data type Cardinality Description
subscriptionType String 1 Shall be set to "QoSMeasureSubscription".
callbackReference Uri 0.1 URI exposed by the client on which to receive
notifications via HTTP. See note 1.
requestTestNotification Boolean 0.1 Set to TRUE by the service consumer to request
a test notification via HTTP on the
callbackReference URI, as specified in ETSI
GS MEC 009 [2], clause 6.12a.
websockNotifConfig WebsockNotifConfig 0.1 Provides details to negotiate and signal the use of
a Websocket connection between the location
server and the service consumer for notifications.
See note 1.
_links Structure (inlined) 0.1 Hyperlink related to the resource. This shall be
only included in the HTTP responses and in
HTTP PUT requests.
>self LinkType 1
...