ETSI GS MEC 015 V2.1.1 (2020-06)

Multi-Access Edge Computing (MEC); Traffic Management APIs

RGS/MEC-0015v211TrafMngtAPIs

General Information

• Status: Not Published
• Technical Committee: MEC - Multi-access Edge Computing
• Current Stage: 12 - Completion
• Due Date: 07-Jul-2020
• Completion Date: 24-Jun-2020

Standards Content (Sample)

ETSI GS MEC 015 V2.1.1 (2020-06)






GROUP SPECIFICATION
Multi-Access Edge Computing (MEC);
Traffic Management APIs
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.

---------------------- Page: 1 ----------------------
2 ETSI GS MEC 015 V2.1.1 (2020-06)



Reference
RGS/MEC-0015v211TrafMngtAPIs
Keywords
API, management, MEC, QoS, traffic
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

---------------------- Page: 2 ----------------------
3 ETSI GS MEC 015 V2.1.1 (2020-06)
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 Void . 8
5 Overview . 8
6 Description of the service (informative). 8
6.1 Introduction . 8
6.2 Sequence diagrams . 9
6.2.1 General . 9
6.2.2 Register to Bandwidth Management Service . 9
6.2.3 Unregister from Bandwidth Management Service . 9
6.2.4 Update requested bandwidth requirements on BWM Service . 10
6.2.5 Get configured bandwidth allocation from BWM Service . 10
6.2.6 Get MTS service Info from the MTS Service . 11
6.2.7 Register to the MTS service . 11
6.2.8 Unregister from the MTS service . 12
6.2.9 Update requested requirements on the MTS service . 12
6.2.10 Get configured MTS session from the MTS service . 13
7 Data Model . 14
7.1 Introduction . 14
7.2 Resource data types . 14
7.2.1 Introduction. 14
7.2.2 Type: BwInfo . 14
7.2.3 Type: BwInfoDeltas . 14
7.2.4 Type: MtsCapabilityInfo . 16
7.2.5 Type: MtsSessionInfo . 17
8 BWM API definition . 18
8.1 Introduction . 18
8.2 Global definitions and resource structure . 18
8.3 Resource: individual bandwidthAllocation . 19
8.3.1 Description . 19
8.3.2 Resource definition . 19
8.3.3 Resource Methods . 19
8.3.3.1 GET . 19
8.3.3.2 PUT . 20
8.3.3.3 PATCH . 20
8.3.3.4 POST . 21
8.3.3.5 DELETE . 21
8.4 Resource: a list of bandwidthAllocations . 22
8.4.1 Description . 22
8.4.2 Resource definition . 22
8.4.3 Resource Methods . 22
8.4.3.1 GET . 22
8.4.3.2 PUT . 23
ETSI

---------------------- Page: 3 ----------------------
4 ETSI GS MEC 015 V2.1.1 (2020-06)
8.4.3.3 PATCH . 23
8.4.3.4 POST . 23
8.4.3.5 DELETE . 24
9 MTS API definition . 24
9.1 Introduction . 24
9.2 Global definitions and resource structure . 24
9.3 Resource: MTS information . 25
9.3.1 Description . 25
9.3.2 Resource definition . 25
9.3.3 Resource Methods . 25
9.3.3.1 GET . 25
9.4 Resource: individual MTS session . 26
9.4.1 Description . 26
9.4.2 Resource definition . 26
9.4.3 Resource Methods . 27
9.4.3.1 GET . 27
9.4.3.2 PUT . 27
9.4.3.3 DELETE . 28
9.5 Resource: a list of MTS sessions . 29
9.5.1 Description . 29
9.5.2 Resource definition . 29
9.5.3 Resource Methods . 29
9.5.3.1 GET . 29
9.5.3.2 POST . 30
Annex A (informative): Complementary material for API utilization . 32
History . 33

ETSI

---------------------- Page: 4 ----------------------
5 ETSI GS MEC 015 V2.1.1 (2020-06)
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

---------------------- Page: 5 ----------------------
6 ETSI GS MEC 015 V2.1.1 (2020-06)
1 Scope
The present document focuses on the Traffic Management multi-access edge service. It describes the related application
policy information including authorization and access control, information flows, required information and service
aggregation patterns. The present document 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 GS MEC 009: "Multi-access Edge Computing (MEC); General principles for MEC Service
APIs".
[7] IETF RFC 7396: "JSON Merge Patch".
NOTE: Available at https://tools.ietf.org/html/rfc7396.
[8] IEEE 802.11™: "802.11-2016 - IEEE Standard for Information technology-Telecommunications
and information exchange between systems Local and metropolitan area networks-Specific
requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications".
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.
ETSI

---------------------- Page: 6 ----------------------
7 ETSI GS MEC 015 V2.1.1 (2020-06)
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 002: "Mobile Edge Computing (MEC); Technical Requirements".
[i.2] 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.
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.
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
BW BandWidth
BWM BandWidth Management
BWMS BandWidth Management Service
CDN Content Delivery Network
DSCP Differentiated Services Code Point
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IETF Internet Engineering Task Force
JSON Javascript Object Notation
MEC Multi-access Edge Computing
MTS Multi-access Traffic Steering
NR New Radio
OAI Open API Initiative
RAN Radio Access Network
REST REpresentational State Transfer
RFC REquest For Comments
RTT Round Trip Time
TLS Transport Layer Security
TM Traffic Management
TMS Traffic Management Service
URI Uniform Resource Indicator
UTC Coordinated Universal Time
UTRA Universal Terrestrial Radio Access
WLAN Wireless Local Area Network
ETSI

---------------------- Page: 7 ----------------------
8 ETSI GS MEC 015 V2.1.1 (2020-06)
4 Void
5 Overview
The present document specifies the Traffic Management (TM) APIs to support the requirements defined for
Multi-Access Edge Computing in ETSI GS MEC 002 [i.1]. There are two TM services: BandWidth Management
(BWM) service and Multi-access Traffic Steering (MTS) service. Clause 6 introduces how TM services can be used by
the multi-access edge applications and by the multi-access edge platform. It describes the information flows used for
TM services.
The information that can be exchanged over the TM APIs is described in clause 7 which provides detailed description
on all information elements that are used for TM services.
Clause 8 and 9 describe the actual TM APIs (BWM API and MTS API) providing detailed information how
information elements are mapped into a RESTful API design.
Figure 5-1 illustrates the mission of the TM services, which may optionally run as part of the platform or as an
application. Different applications, whether managing a single instance or several sessions (for example CDN), may
request specific Bandwidth Management (BWM) or/and Multi-access Traffic Steering (MTS) requirements for the
whole application instance or different requirements per session. The TM services can aggregate all the requests and act
in a manner that will help optimize the BW usage and improve Quality of user Experience for applications.
CDN Gaming Other
Session #1
Session #1
No
Session #2
Session #2
... Sessions
Session #n
TM APIs TM APIs
TM APIs
Traffic to/from
Internet or
Traffic to/
MEC
Traffic Management services (BWM, MTS)
from Devices
applications
MEC Platform

Figure 5-1: Traffic Management services description
6 Description of the service (informative)
6.1 Introduction
Different MEC applications running in parallel on the same MEC host may require specific static/dynamic up/down
bandwidth resources, including bandwidth size and bandwidth priority. In some cases different sessions running in
parallel on the same application may each have specific bandwidth requirements. In addition, sessions driven by
applications running from closer to end user (shorter RTT) may receive unfair advantage over session driven by
application running from distant locations (outside the RAN). To resolve potential resource conflicts between such
competing applications, the following optional traffic management services may be used:
• BandWidth Management (BWM) service; and
• Multi-access Traffic Steering (MTS) service.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI GS MEC 015 V2.1.1 (2020-06)
The BWM service is for allocating/adjusting bandwidth resources, including bandwidth size and bandwidth priority, for
MEC applications, and allows MEC applications to provide bandwidth requirements.
The MTS service is for seamlessly steering/splitting/duplicating application data traffic across multiple access network
connections. The MTS allows:
1) MEC applications to get informed of various MTS capabilities and multi-access network connection info.
2) MEC applications to provide requirements, e.g. delay, throughput, loss, for influencing traffic management
operations.
The specific session or MEC application will be identified using a set of filters within the resource request.
6.2 Sequence diagrams
6.2.1 General
The following clauses describe how multi-access edge applications can use TMS to update/receive Bandwidth
Management (BWM) or/and Multi-access Traffic Steering (MTS) information to/from the MEC platform. The sequence
diagrams that are relevant for TMS are presented.
The TM APIs enable the MEC applications to register or unregister for specific bandwidth allocation or/and multi-
access traffic steering requirement. The "Registration" flow is used to create a bandwidthAllocation as shown in
clause 6.2.2 or a mtsSession as shown in clause 6.2.7. It is operated on per-allocation/session basis, and can be used
multiple times by the application to create multiple bandwidthAllocations or mtsSessions. The "Unregistration" flow is
used to delete a bandwidthAllocation as shown in clause 6.2.3 or a mtsSession as shown in clause 6.2.8.
The present document of TM APIs contains the HTTP protocol bindings for traffic management functionality using the
REST architectural style.
6.2.2 Register to Bandwidth Management Service
Figure 6.2.2-1 shows a scenario where a MEC Application instance registers to BWMS.

Figure 6.2.2-1: Flow of MEC Application registration to BWMS
MEC Application instance registration to BWMS, as illustrated in figure 6.2.2-1, consists of the following steps:
1) MEC application instance sends a request to register to the BWMS with the requested bandwidth requirements
(bandwidth size/priority).
2) BWMS responds with a registration and initialization approval.
6.2.3 Unregister from Bandwidth Management Service
Figure 6.2.3-1 shows a scenario where a MEC Application Instance unregisters from BWMS.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI GS MEC 015 V2.1.1 (2020-06)

Figure 6.2.3-1: Flow of MEC Application unregistering BW allocation from BWMS
MEC Application Instance unregistering from BWMS , as illustrated in figure 6.2.3-1, consists of the following steps:
1) MEC Application instance sends an unregister request to BWMS.
2) BWMS responds with an unregistration approval.
6.2.4 Update requested bandwidth requirements on BWM Service
Figure 6.2.4-1 shows a scenario where a MEC Application instance updates its requested bandwidth requirements on
the BWMS.

Figure 6.2.4-1: Flow of MEC application updating its requested
bandwidth requirements on BWMS
MEC application instance updating its requested bandwidth requirements on BWMS, as illustrated in figure 6.2.4-1,
consists of the following steps:
1) MEC Application instance sends a request to update a specific bandwidth allocation on the BWMS.
2) BWMS responds with an update approval.
6.2.5 Get configured bandwidth allocation from BWM Service
Figure 6.2.5-1 shows a scenario where a MEC Application instance gets its configured bandwidth allocation from the
BWMS.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI GS MEC 015 V2.1.1 (2020-06)

Figure 6.2.5-1: Flow of MEC Application getting its configured
bandwidth allocation from BWMS
MEC Application instance gets its configured bandwidth from BWMS, as illustrated in figure 6.2.5-1, consists of the
following steps:
1) MEC Application instance sends a request to get its configured bandwidth allocation on the BWMS.
2) BWMS responds with the BW allocation details.
6.2.6 Get MTS service Info from the MTS Service
Figure 6.2.6-1 shows a scenario where a MEC Application instance gets the available MTS service information from
the MTS service.

Figure 6.2.6-1: Flow of MEC Application getting the MTS service info
MEC Application instance gets the available MTS service info from the MTS service, as illustrated in figure 6.2.6-1,
consists of the following steps:
1) MEC Application instance sends a request to get the available MTS service information.
2) The MTS service responds with the available MTS service information details.
6.2.7 Register to the MTS service
Figure 6.2.7-1 shows a scenario where a MEC Application instance registers to the MTS service.
ETSI

---------------------- Page: 11 ----------------------
12 ETSI GS MEC 015 V2.1.1 (2020-06)

Figure 6.2.7-1: Flow of MEC Application registration to the MTS service
MEC Application instance registration to the MTS service, as illustrated in figure 6.2.7-1, consists of the following
steps:
1) MEC Application instance sends a request to register to the MTS service with the requested requirements.
2) The MTS service responds with a registration and initialization approval.
6.2.8 Unregister from the MTS service
Figure 6.2.8-1 shows a scenario where a MEC Application instance unregisters from the MTS service.

Figure 6.2.8-1: Flow of MEC Application unregistering MTS session from the MTS service
MEC Application instance unregistering from the MTS se
...