ETSI GS MEC 015 V2.2.1 (2022-12)

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

RGS/MEC-0015v221TrafMngtAPIs

General Information

• Status: Not Published
• Technical Committee: MEC - Multi-access Edge Computing
• Current Stage: 12 - Completion
• Due Date: 20-Dec-2022
• Completion Date: 15-Dec-2022

Standards Content (Sample)

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.

2 ETSI GS MEC 015 V2.2.1 (2022-12)

Reference
RGS/MEC-0015v221TrafMngtAPIs
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 - 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:
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
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
arranty is made of merchantability or fitness
and/or governmental rule and/or regulation and further, no representation or w
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 2022.
All rights reserved.
ETSI
3 ETSI GS MEC 015 V2.2.1 (2022-12)
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 . 7
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Void . 7
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 . 10
6.2.4 Update requested bandwidth requirements on BWM Service . 10
6.2.5 Get configured bandwidth allocation from BWM Service . 11
6.2.6 Get MTS service Info from the MTS Service . 11
6.2.7 Register to the MTS service . 12
6.2.8 Unregister from the MTS service . 12
6.2.9 Update requested requirements on the MTS service . 13
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 . 15
7.2.4 Type: MtsCapabilityInfo . 15
7.2.5 Type: MtsSessionInfo . 16
8 BWM API definition . 17
8.1 Introduction . 17
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
4 ETSI GS MEC 015 V2.2.1 (2022-12)
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 . 26
9.3.3.1 GET . 26
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
5 ETSI GS MEC 015 V2.2.1 (2022-12)
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 015 V2.2.1 (2022-12)
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] Void.
[2] Void.
[3] IETF RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".
NOTE: Available at https://www.rfc-editor.org/info/rfc5246.
[4] IETF RFC 6749: "The OAuth 2.0 Authorization Framework".
NOTE: Available at https://www.rfc-editor.org/info/rfc6749.
[5] IETF RFC 6750: "The OAuth 2.0 Authorization Framework: Bearer Token Usage".
NOTE: Available at https://www.rfc-editor.org/info/rfc6750.
[6] ETSI GS MEC 009: "Multi-access Edge Computing (MEC); General principles, patterns and
common aspects of MEC Service APIs".
[7] IETF RFC 7396: "JSON Merge Patch".
NOTE: Available at https://www.rfc-editor.org/info/rfc7396.
[8] IEEE 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".
[9] IETF RFC 8446: "The Transport Layer Security (TLS) Protocol Version 1.3".
NOTE: Available at https://www.rfc-editor.org/info/rfc8446.
[10] IETF RFC 1166: "Internet Numbers".
NOTE: Available at https://www.rfc-editor.org/info/rfc1166.
[11] IETF RFC 5952: "A recommendation for IPv6 Address Text Representation".
NOTE: Available at https://www.rfc-editor.org/info/rfc5952.
ETSI
7 ETSI GS MEC 015 V2.2.1 (2022-12)
[12] IETF RFC 4632: "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and
Aggregation Plan".
NOTE: Available at https://www.rfc-editor.org/info/rfc4632.
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 002: "Multi-access Edge Computing (MEC); Phase 2: Use Cases and
Requirements".
[i.2] OpenAPI™ Specification.
NOTE: Available at https://github.com/OAI/OpenAPI-Specification.
[i.3] ETSI GR MEC 001: "Multi-access Edge Computing (MEC); Terminology".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GR MEC 001 [i.3] apply.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GR MEC 001 [i.3] and the following apply:
BW BandWidth
BWM BandWidth Management
BWMS BandWidth Management Service
CDN Content Delivery Network
DSCP Differentiated Services Code Point
MTS Multi-access Traffic Steering
NR New Radio
OAI Open API Initiative
RTT Round Trip Time
TM Traffic Management
TMS Traffic Management Service
UTRA Universal Terrestrial Radio Access
4 Void
ETSI
8 ETSI GS MEC 015 V2.2.1 (2022-12)
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.
Clauses 8 and 9 describe the actual TM APIs (BWM API and MTS API) providing detailed information on 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 sessions driven by
applications 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.
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.
ETSI
9 ETSI GS MEC 015 V2.2.1 (2022-12)
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.
ETSI
10 ETSI GS MEC 015 V2.2.1 (2022-12)
6.2.3 Unregister from Bandwidth Management Service
Figure 6.2.3-1 shows a scenario where a MEC Application Instance unregisters from BWMS.

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.
ETSI
11 ETSI GS MEC 015 V2.2.1 (2022-12)
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.
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.
ETSI
12 ETSI GS MEC 015 V2.2.1 (2022-12)
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.

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 service, as illustrated in figure 6.2.8-1, consists of the following
steps:
1) MEC Application instance sends an unregister request to the MTS service.
2) MTS responds with an unregistration approval.
ETSI
13 ETSI GS MEC 015 V2.2.1 (2022-12)
6.2.9 Update requested requirements on the MTS service
Figure 6.2.9-1 shows a scenario where a MEC Application instance updates its requested requirements on the MTS
service.
Figure 6.2.9-1: Flow of MEC application updating its requested
requirements on the MTS service
MEC Application instance updating its requested requirements on the MTS service, as illustrated in figure 6.2.9-1,
consists of the following steps:
1) MEC Application instance sends a request to update a specific MTS session on the MTS service.
2) The MTS service responds with an update approval.
6.2.10 Get configured MTS session from the MTS service
Figure 6.2.10-1 shows a scenario where a MEC Application instance gets its configured MTS session from the MTS
service.
Figure 6.2.10-1: Flow of MEC Application getting its configured
MTS session info from the MTS service
MEC Application instance gets its configured MTS session information from the MTS service, as illustrated in
figure 6.2.10-1, consists of the following steps:
1) MEC Application instance sends a request to get its configured MTS session information on the MTS service.
2) The MTS service responds with the MTS session details.
ETSI
14 ETSI GS MEC 015 V2.2.1 (2022-12)
7 Data Model
7.1 Introduction
The following clauses provide the description of the Data Model.
7.2 Resource data types
7.2.1 Introduction
This clause defines data structures to be used in resource representations.
7.2.2 Type: BwInfo
Table 7.2.2-1: Elements of BwInfo
Element Type Cardinality Description
allocationId String 0.1 Bandwidth allocation instance identifier
timeStamp Structure (inlined) 0.1 Time stamp to indicate when the corresponding
information elements are sent
>seconds Uint32 1 The seconds part of the Time. Time is defined as
Unix-time since January 1, 1970, 00:00:00 UTC
>nanoSeconds Uint32 1 The nanoseconds part of the Time. Time is defined as
Unix-time since January 1, 1970, 00:00:00 UTC
appInsId String 1 Application instance identifier
appName String 0.1 Name of the application
requestType Enum (inlined) 1 Numeric value (0 - 255) corresponding to specific type of
consumer as following:
0 = APPLICATION_SPECIFIC_BW_ALLOCATION
1 = SESSION_SPECIFIC_BW_ALLOCATION
sessionFilter Structure (inlined) 0.N Session filtering criteria, applicable when requestType is
set as SESSION_SPECIFIC_BW_ALLOCATION. Any
filtering criteria shall define a single session only. In case
multiple sessions match sessionFilter, the request shall
be rejected
>sourceIp String 0.1 Source address identity of session. The string for an IPv4
address shall be formatted in the "dotted decimal"
notation as defined in IETF RFC 1166 [10]. The string for
an IPv6 address shall be formatted according to clause 4
of IETF RFC 5952 [11], with in CIDR notation [12] used
to provide the routing prefix
>sourcePort String 0.1 Source port identity of session
>dstAddress String 0.1 Destination address identity of session. The string for an
IPv4 address shall be formatted in the "dotted decimal"
notation as defined in IETF RFC 1166 [10]. The string for
an IPv6 address shall be formatted according to clause 4
of IETF RFC 5952 [11], with in CIDR notation [12] used
to provide the routing prefix
>dstPort String 0.1 Destination port identity of session
>protocol String 0.1 Protocol number
fixedBWPriority Enum 0.1 Indicates the allocation priority when dealing with several
applications or sessions in parallel. Values are not
defined in the present document
fixedAllocation String 1 Size of requested fixed BW allocation in [bps]
allocationDirection String 1 The direction of the requested BW allocation:
00 = Downlink (towards the UE)
01 = Uplink (towards the application/session)
10 = Symmetrical
ETSI
15 ETSI GS MEC 015 V2.2.1 (2022-12)
7.2.3 Type: BwInfoDeltas
Conforming to JSON merge patch format and processing rules specified IETF RFC 7396 [7], this type represents the
attributes whose value are allowed to be updated with HTTP PATCH method in content format JSON. It shall follow
the indications provided in table 7.2.3-1.
Table 7.2.3-1: Elements of BwInfoDeltas
Attribute name Data type Cardinality Description
allocationId String 1 Bandwidth allocation instance identifier
appInsId String 1 Application instance identifier
requestType Enum (inlined) 1 Numeric value (0 - 255) corresponding to specific type of
consumer as following:
0 = APPLICATION_SPECIFIC_BW_ALLOCATION
1 = SESSION_SPECIFIC_BW_ALLOCATION
sessionFilter Structure (inlined) 0.N Session filtering criteria, applicable when requestType is
set as SESSION_SPECIFIC_BW_ALLOCATION. Any
filtering criteria shall define a single session only. In case
multiple sessions match sessionFilter, the request shall
be rejected
>sourceIp String 0.1 Source address identity of session. The string for an
IPv4 address shall be formatted in the "dotted decimal"
notation as defined in IETF RFC 1166 [10]. The string for
an IPv6 address shall be formatted according to clause 4
of IETF RFC 5952 [11], with in CIDR notation [12] used
to provide the routing prefix
>sourcePort String 0.1 Source port identity of session
>dstAddress String 0.1 Destination address identity of session. The string for an
IPv4 address shall be formatted in the "dotted decimal"
notation as defined in IETF RFC 1166 [10]. The string for
an IPv6 address shall be formatted according to clause 4
of IETF RFC 5952 [11], with in CIDR notation [12] used
to provide the routing prefix
>dstPort String 0.1 Destination port identity of session
>protocol String 0.1 Protocol number
fixedBWPriority Enum (inlined) 0.1 Indicates the allocation priority when dealing with several
applications or sessions in parallel. Values are not
defined in the present document
fixedAllocation String 0.1 Size of requested fixed BW allocation in [bps]
allocationDirection String 0.1 The direction of the requested BW allocation:
00 = Downlink (towards the UE)
01 = Uplink (towards the application/session)
10 = Symmetrical
7.2.4 Type: MtsCapabilityInfo
Table 7.2.4-1: Attributes of the MtsCapabilityInfo
Attribute name Data type Cardinality Description
timeStamp Structure (inlined) 0.1 Time stamp to indicate when the corresponding
information elements are sent
>seconds Uint32 1 Time in seconds in Unix-time since January 1, 1970,
00:00:00 UTC
>nanoSeconds Uint32 1 Time in nanoseconds in Unix-time since January 1, 1970,
00:00:00 UTC
mtsAccessInfo Structure (inlined) 1.N The information on access network connection as defined
below
>accessId Uint32 1 Unique identifier for the access network connection
ETSI
16 ETSI GS MEC 015 V2.2.1 (2022-12)
Attribute name Data type Cardinality Description
>accessType Uint32 1 Numeric value (0-255) corresponding to specific type of
access network as following:
0 = Unknown
1 = Any IEEE802.11-based WLAN technology
2 = Any 3GPP-based Cellular technology
3 = Any Fixed Access
11 = IEEE802.11 a/b/g WLAN
12 = IEEE 802.11 a/b/g/n WLAN
13 = IEEE 802.11 a/b/g/n/ac WLAN
14 = IEEE 802.11 a/b/g/n/ac/ax WLAN (Wi-Fi 6)
15 = IEEE 802.11 b/g/n WLAN
31 = 3GPP GERAN/UTRA (2G/3G)
32 = 3GPP E-UTRA (4G/LTE)
33 = 3GPP NR (5G)
>metered Uint32 1 Numeric value (0-255) corresponding to the following:
0: the connection is not metered (see note)
1: the connection is metered
2: unknown
mtsMode Uint32 1.N Numeric value corresponding to a specific MTS operation
supported by the TMS
0 = low cost, i.e. using the unmetered access network
connection whenever it is available
1 = low latency, i.e. using the access network connection
with lower latency
2 = high throughput, i.e. using the access network
connection with higher throughput, or/and multiple access
network connection simultaneously if supported
3 = redundancy, i.e. sending duplicated (redundancy)
packets over multiple access network connections for
high-reliability and low-latency applications
4 = QoS, i.e. performing MTS based on the specific QoS
requirements from the app
NOTE: A metered connection is a network connection that has a maximum data usage in a specific period,
e.g. per hour/day/week/month. The user may get billed extra charges if they go over the allotted
amount.
7.2.5 Type: MtsSessionInfo
Table 7.2.5-1: Elements of MtsSessionInfo
Element Type Cardinality Description
sessionId String 0.1 MTS session instance identifier
timeStamp Structure 0.1 Time stamp to indicate when the corresponding information
(inlined) elements are sent
>seconds Uint32 1 The seconds part of the Time. Time is defined as Unix-time
since January 1, 1970, 00:00:00 UTC
>nanoSeconds Uint32 1 The nanoseconds part of the Time. Time is defined as Unix-time
since January 1, 1970, 00:00:00 UTC
appInsId String 1 Application instance identifier
appName String 0.1 Name of the application
requestType Enum (inlined) 1 Numeric value (0 - 255) corresponding to specific type of
consumer as following:
0 = APPLICATION_SPECIFIC_MTS_SESSION
1 = FLOW_SPECIFIC_MTS_SESSION
flowFilter Structure 1.N Traffic flow filtering criteria, applicable only if when requestType
(inlined) is set as FLOW_SPECIFIC_MTS_SESSION. Any filtering
criteria shall define a single session only. In case multiple
sessions match flowFilter, the request shall be rejected. If the
flowFilter field is included, at least one of its subfields shall be
included. Any flowFilter subfield that is not included shall be
ignored in traffic flow filtering
ETSI
17 ETSI GS MEC 015 V2.2.1 (2022-12)
Element Type Cardinality Description
>sourceIp String 0.1 Source address identity of session. The string for an IPv4
address shall be formatted in the "dotted decimal" notation as
defined in IETF RFC 1166 [10]. The string for an IPv6 address
shall be formatted according to clause 4 of IETF RFC 5952 [11],
with in CIDR notation [12] used to provide the routing prefix
>sourcePort Uint32 0.1 Source port identity of session
>dstIp String 0.1 Destination address identity of session. The string for an IPv4
address shall be formatted in the "dotted decimal" notation as
defined in IETF RFC 1166 [10]. The string for an IPv6 address
shall be formatted according to clause 4 of IETF RFC 5952 [11],
with in CIDR notation [12] used to provide the routing prefix
>dstPort Uint32 0.1 Destination port identity of session
>protocol Uint32 0.1 Protocol number
>dscp Uint32 0.1 DSCP in the IPv4 header or Traffic Class in the IPv6 header
>flowlabel Uint32 0.1 Flow Label in the IPv6 header, applicable only if the flow is IPv6
qosD Structure 1 QoS requirement description of the MTS session, applicable
only if mtsMode = 4 (QoS). If the qosD field is included, at least
one of its subfields shall be included. Any qosD subfield that is
not included shall be ignored in Multi-access Traffic Steering
(MTS)
>minTpt Unit32 0.1 minimal throughput in [kbps]
>maxLatency Unit32 0.1 tolerable (one-way) delay in [10 nanoseconds]
>maxLoss Unit32 0.1 tolerable packet loss rate in [1/10^x]
>maxJitter Unit32 0.1 tolerable jitter in [10 nanoseconds]
>priority Unit32 0.1 numeric value (0 - 255) corresponding to the traffic priority:
0: low;
1: medium;
2: high;
3: critical
mtsMode Uint32 1 Numeric value (0 - 255) corresponding to a specific MTS mode
of the MTS session:
0 = low cost, i.e. using the unmetered access network
connection whenever it is available
1 = low latency, i.e. using the access network connection
with lower latency
2 = high throughput, i.e. using the access network
connection with higher throughput, or multiple access
network connection simultaneously
3 = redundancy, i.e. sending duplicated (redundancy)
packets over multiple access network connections for
high-reliability and low-latency applications
4 = QoS, i.e. performing MTS based on the QoS
requirement (qosD)
trafficDirection String 1 The direction of the requested MTS session:
00 = Downlink (towards the UE)
01 = Uplink (towards the application/session)
10 = Symmetrical (see note)
NOTE: For the downlink direction of a symmetrical flow, "sourceIp" and "sourcePort" in the "flowFilter" structure
are used for source address and port, respectively; "dstIp" and "dstPort" are used for destination address
and port, respectively. For the uplink direction of a symmetrical flow, "sourceIp" and "sourcePort" are
used for destination address and port, respectively; "dstIp" and "dstPort" are used for source address and
port, respectively.
8 BWM API definition
8.1 Introduction
This clause defines the resources and operations of the Bandwidth Management API (BWM API).
ETSI
18 ETSI GS MEC 015 V2.2.1 (2022-12)
8.2 Global definition
...