ETSI GS MEC 015 V3.1.1 (2024-04)

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

RGS/MEC-0015v311TrafMngtAPIs

General Information

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

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 V3.1.1 (2024-04)

Reference
RGS/MEC-0015v311TrafMngtAPIs
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:
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 015 V3.1.1 (2024-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 . 8
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Void . 8
5 Overview . 9
6 Description of the service (informative). 9
6.1 Introduction . 9
6.2 Sequence diagrams . 10
6.2.1 General . 10
6.2.2 Register to Bandwidth Management Service . 10
6.2.3 Unregister from Bandwidth Management Service . 11
6.2.4 Update requested bandwidth requirements on BWM Service . 11
6.2.5 Get configured bandwidth allocation from BWM Service . 12
6.2.6 REST based subscribe-notify model . 12
6.2.6.1 Subscribing to BWM information event notifications . 12
6.2.6.2 Receiving notification of BWM information event subscription . 13
6.2.6.3 Updating subscription for BWM information event notifications . 13
6.2.6.4 Unsubscribing from BWM information event notifications. 14
6.2.7 Get MTS service Info from the MTS Service . 15
6.2.8 Register to the MTS service . 15
6.2.9 Unregister from the MTS service . 16
6.2.10 Update requested requirements on the MTS service . 16
6.2.11 Get configured MTS session from the MTS service . 17
7 Data Model . 17
7.1 Introduction . 17
7.2 Resource data types . 17
7.2.1 Introduction. 17
7.2.2 Type: BwInfo . 18
7.2.3 Type: BwInfoDeltas . 18
7.2.4 Type: MtsCapabilityInfo . 20
7.2.5 Type: MtsSessionInfo . 20
7.3 Subscription data types . 22
7.3.1 Introduction. 22
7.3.2 Type: BwChgEventSubscription . 22
7.3.3 Type: SubscriptionLinkList . 22
7.4 Notification data types . 23
7.4.1 Introduction. 23
7.4.2 Type: BwChgEventNotification . 23
7.5 Referenced structure data types . 23
7.5.1 Introduction. 23
7.5.2 Type: LinkType . 24
7.5.3 Type: WebsockNotifConfig . 24
8 BWM API definition . 24
8.1 Introduction . 24
ETSI
4 ETSI GS MEC 015 V3.1.1 (2024-04)
8.2 Global definitions and resource structure . 24
8.3 Resource: individual bandwidthAllocation . 25
8.3.1 Description . 25
8.3.2 Resource definition . 25
8.3.3 Resource Methods . 26
8.3.3.1 GET . 26
8.3.3.2 PUT . 26
8.3.3.3 PATCH . 27
8.3.3.4 POST . 28
8.3.3.5 DELETE . 28
8.4 Resource: a list of bandwidthAllocations . 29
8.4.1 Description . 29
8.4.2 Resource definition . 29
8.4.3 Resource Methods . 29
8.4.3.1 GET . 29
8.4.3.2 PUT . 30
8.4.3.3 PATCH . 30
8.4.3.4 POST . 30
8.4.3.5 DELETE . 31
8.5 Resource: subscriptions . 31
8.5.1 Description . 31
8.5.2 Resource definition . 31
8.5.3 Resource methods . 32
8.5.3.1 GET . 32
8.5.3.2 PUT . 33
8.5.3.3 PATCH . 33
8.5.3.4 POST . 33
8.5.3.5 DELETE . 34
8.6 Resource: existing subscription . 34
8.6.1 Description . 34
8.6.2 Resource definition . 34
8.6.3 Resource methods . 34
8.6.3.1 GET . 34
8.6.3.2 PUT . 35
8.6.3.3 PATCH . 37
8.6.3.4 POST . 37
8.6.3.5 DELETE . 37
8.7 Resource: Notification callback . 38
8.7.1 Description . 38
8.7.2 Resource definition . 38
8.7.3 Resource methods . 38
8.7.3.1 GET . 38
8.7.3.2 PUT . 38
8.7.3.3 PATCH . 39
8.7.3.4 POST . 39
8.7.3.5 DELETE . 39
9 MTS API definition . 40
9.1 Introduction . 40
9.2 Global definitions and resource structure . 40
9.3 Resource: MTS information . 41
9.3.1 Description . 41
9.3.2 Resource definition . 41
9.3.3 Resource Methods . 41
9.3.3.1 GET . 41
9.4 Resource: individual MTS session . 42
9.4.1 Description . 42
9.4.2 Resource definition . 42
9.4.3 Resource Methods . 42
9.4.3.1 GET . 42
9.4.3.2 PUT . 43
9.4.3.3 DELETE . 44
ETSI
5 ETSI GS MEC 015 V3.1.1 (2024-04)
9.5 Resource: a list of MTS sessions . 45
9.5.1 Description . 45
9.5.2 Resource definition . 45
9.5.3 Resource Methods . 45
9.5.3.1 GET . 45
9.5.3.2 POST . 46
Annex A (informative): Complementary material for API utilization . 48
History . 49

ETSI
6 ETSI GS MEC 015 V3.1.1 (2024-04)
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
7 ETSI GS MEC 015 V3.1.1 (2024-04)
1 Scope
The present document focuses on the Traffic Management (TM) MEC service. It describes the TM related information
including access control, information flows, required information and operations. 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] Void.
[4] Void.
[5] Void.
[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".
[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] Void.
[10] IETF RFC 1166: "Internet numbers".
[11] IETF RFC 5952: "A Recommendation for IPv6 Address Text Representation".
[12] IETF RFC 4632: "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and
Aggregation Plan".
ETSI
8 ETSI GS MEC 015 V3.1.1 (2024-04)
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); Use Cases and Requirements".
[i.2] OpenAPI™ Specification.
[i.3] ETSI GR MEC 001: "Multi-access Edge Computing (MEC); Terminology".
[i.4] ETSI TS 123 288 (V17.9.0): "5G; Architecture enhancements for 5G System (5GS) to support
network data analytics services (3GPP TS 23.288 version 17.9.0 Release 17)".
[i.5] ETSI TS 123 501: "5G; System architecture for the 5G System (5GS) (3GPP TS 23.501
Release 17)".
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:
ATSSS Access Traffic Steering, Switching, Splitting
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
NWDAF NetWork Data Analytical Function
OAI Open API Initiative
RTT Round Trip Time
TM Traffic Management
TMS Traffic Management Service
UTRA Universal Terrestrial Radio Access
4 Void
ETSI
9 ETSI GS MEC 015 V3.1.1 (2024-04)
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
10 ETSI GS MEC 015 V3.1.1 (2024-04)
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
11 ETSI GS MEC 015 V3.1.1 (2024-04)
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
12 ETSI GS MEC 015 V3.1.1 (2024-04)
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 REST based subscribe-notify model
6.2.6.1 Subscribing to BWM information event notifications
To receive notifications on selected BWM information event, the service consumer creates a subscription to certain BW
information change event that is available at BWM service. Figure 6.2.6.1-1 shows a scenario where the service
consumer uses REST based procedures to create a subscription for BWM information event notification.

Figure 6.2.6.1-1: Flow of subscribing to BWM information event notifications
ETSI
13 ETSI GS MEC 015 V3.1.1 (2024-04)
Subscribing to the BWM information event notifications, as illustrated in figure 6.2.6.1-1, consists of the following
steps.
When service consumer wants to receive notification about the BWM information event, it creates a subscription to the
BWM information event notifications:
1) The service consumer sends a POST request with the message body containing the {NotificationSubscription}
data structure to the resource representing BWM information subscription. The variable
{NotificationSubscription} is replaced with the data type specified for different BWM information event
subscriptions, and defines the subscribed event, the filtering criteria and the address where the service
consumer wishes to receive the BWM information event notification.
2) BWM service sends "201 Created" response with the message body containing the data structure specific to
that of BWM information event subscription. The data structure contains the address of the resource created
and the subscribed BWM information event type. The address of the resource created is also contained in the
message header.
6.2.6.2 Receiving notification of BWM information event subscription
Figure 6.2.6.2-1 presents the scenario where BWM service sends BWM information event notification to the service
consumer (MEC application or a MEC platform) about the BW change event information.

Figure 6.2.6.2-1: Flow of BWM information event notification
BWM service sends a notification to the subscribed service consumer as illustrated in figure 6.2.6.2-1, with the
following steps:
1) BWM service sends a POST request with the message body containing the BwChgEventNotification data
structure to the callback reference address included by the service consumer in the BwChgEventSubscription
event subscription.
2) Service consumer sends a "204 No Content" response to BWM service.
6.2.6.3 Updating subscription for BWM information event notifications
Figure 6.2.6.3-1 shows a scenario where the service consumer needs to update an existing subscription for a BWM
information event notification. The subscription update is triggered e.g. by the need to change the existing subscription,
or due to the expiry of the notification.
ETSI
14 ETSI GS MEC 015 V3.1.1 (2024-04)

Figure 6.2.6.3-1: Flow of service consumer updating subscription for
BWM information event notifications
Updating the subscription for BWM information event notification, as illustrated in figure 6.2.6.3-1, consists of the
following steps.
When the service consumer needs to modify an existing subscription for BWM information event notification, it can
update the corresponding subscription as follows:
1) Service consumer updates the subscription resource by sending a PUT request to the resource representing the
BWM information event subscription that was created with the modified data structure of that BWM
information event subscription.
2) BWM service returns "200 OK" with the message body containing the accepted data structure specific to that
BWM information event subscription.
6.2.6.4 Unsubscribing from BWM information event notifications
When the service consumer does not want to receive notifications anymore after subscribing to BWM information
events, the service consumer unsubscribes from the BWM information event notifications. Figure 6.2.6.4-1 shows a
scenario where the service consumer uses REST based procedures to delete the subscription for BWM information
event notifications.
Figure 6.2.6.4-1: Flow of unsubscribing for BWM information event notifications
ETSI
15 ETSI GS MEC 015 V3.1.1 (2024-04)
Unsubscribing from the BWM information event notification, as illustrated in figure 6.2.6.4-1, consists of the following
steps.
When the service consumer does not want to receive the notifications anymore, it can unsubscribe from the BWM
information notification events by deleting the subscription:
1) Service consumer sends a DELETE request to the resource representing the BWM information event
subscription that was created.
2) BWM service sends "204 No Content" response.
6.2.7 Get MTS service Info from the MTS Service
Figure 6.2.7-1 shows a scenario where a MEC Application instance gets the available MTS service information from
the MTS service.
Figure 6.2.7-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.7-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.8 Register to the MTS service
Figure 6.2.8-1 shows a scenario where a MEC Application instance registers to the MTS service.

Figure 6.2.8-1: Flow of MEC Application registration to the MTS service
MEC Application instance registration to the MTS service, as illustrated in figure 6.2.8-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.
ETSI
16 ETSI GS MEC 015 V3.1.1 (2024-04)
6.2.9 Unregister from the MTS service
Figure 6.2.9-1 shows a scenario where a MEC Application instance unregisters from the MTS service.

Figure 6.2.9-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.9-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.
6.2.10 Update requested requirements on the MTS service
Figure 6.2.10-1 shows a scenario where a MEC Application instance updates its requested requirements on the MTS
service.
Figure 6.2.10-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.10-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.
ETSI
17 ETSI GS MEC 015 V3.1.1 (2024-04)
6.2.11 Get configured MTS session from the MTS service
Figure 6.2.11-1 shows a scenario where a MEC Application instance gets its configured MTS session from the MTS
service.
Figure 6.2.11-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.11-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.
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.
ETSI
18 ETSI GS MEC 015 V3.1.1 (2024-04)
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.
...