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

Multi-access Edge Computing (MEC); Enablement API for Customer Self-Service

DGS/MEC-0048v311SelfServEnabl

General Information

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

Standards Content (Sample)

GROUP SPECIFICATION
Multi-access Edge Computing (MEC);
Enablement API for Customer Self-Service
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 048 V3.1.1 (2024-04)

Reference
DGS/MEC-0048v311SelfServEnabl
Keywords
API, MEC
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 048 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 . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Overview . 8
5 Description of the services (informative) . 8
5.1 Introduction . 8
5.2 Sequence diagrams . 9
5.2.1 General . 9
5.2.2 Tenant management . 9
5.2.2.1 Introduction . 9
5.2.2.2 Tenant resource creation . 9
5.2.2.3 Tenant resource deletion . 10
5.2.2.4 Tenant resource update . 10
5.2.2.5 Tenant resource query . 10
5.2.3 Computing resource management . 11
5.2.3.1 Introduction . 11
5.2.3.2 Computing resource request (per-tenant) . 12
5.2.3.3 Computing resource request update (per-tenant) . 12
5.2.3.4 Computing resource quota query (per tenant) . 13
5.2.4 REST based subscribe-notify model . 14
5.2.4.1 Subscribing to CSE event notifications . 14
5.2.4.2 Receiving notification on expiry of CSE event subscription . 14
5.2.4.3 Updating subscription for CSE event notifications . 15
5.2.4.4 Unsubscribing from CSE event notifications . 15
5.2.5 Receiving CSE event notifications about resource usage in a MEC system . 16
5.2.6 Receiving CSE event notifications about resource usage in edge sites. 16
6 Data model . 17
6.1 Introduction . 17
6.2 Resource data types . 17
6.2.1 Overview . 17
6.2.2 Type: TenantInfo . 17
6.2.3 Type: ResourceQuotaInfo . 18
6.2.4 Type: SiteResourceQuotaInfo . 18
6.3 Subscription data types . 19
6.3.1 Introduction. 19
6.3.2 Type: ResourceUsageSubscription . 19
6.3.3 Type: SiteResourceUsageSubscription . 19
6.3.4 Type: SubscriptionLinkList . 20
6.4 Notifications data types . 21
6.4.1 Introduction. 21
6.4.2 Type: ResourceUsageNotification . 21
6.4.3 Type: SiteResourceUsageNotification . 21
6.5 Referenced structured data types . 22
6.5.1 Introduction. 22
6.5.2 Type: SiteInfo . 22
ETSI
4 ETSI GS MEC 048 V3.1.1 (2024-04)
6.5.3 Type: ResourceInfo. 22
7 API definitions . 23
7.1 Introduction . 23
7.2 Global definitions and resource structure . 23
7.3 Resource: a list of tenants . 24
7.3.1 Description . 24
7.3.2 Resource definition . 24
7.3.3 Resource methods . 25
7.3.3.1 GET . 25
7.3.3.2 PUT . 25
7.3.3.3 PATCH . 25
7.3.3.4 POST . 25
7.3.3.5 DELETE . 26
7.4 Resource: individual tenant . 26
7.4.1 Description . 26
7.4.2 Resource definition . 26
7.4.3 Resource methods . 27
7.4.3.1 GET . 27
7.4.3.2 PUT . 27
7.4.3.3 PATCH . 28
7.4.3.4 POST . 28
7.4.3.5 DELETE . 28
7.5 Resource: per system resource quota. 29
7.5.1 Description . 29
7.5.2 Resource definition . 29
7.5.3 Resource methods . 29
7.5.3.1 GET . 29
7.5.3.2 PUT . 30
7.5.3.3 PATCH . 31
7.5.3.4 POST . 31
7.5.3.5 DELETE . 32
7.6 Resource: a list of per site resource quota . 32
7.6.1 Description . 32
7.6.2 Resource definition . 32
7.6.3 Resource methods . 32
7.6.3.1 GET . 32
7.6.3.2 PUT . 33
7.6.3.3 PATCH . 33
7.6.3.4 POST . 33
7.6.3.5 DELETE . 34
7.7 Resource: individual per site resource quota . 34
7.7.1 Description . 34
7.7.2 Resource definition . 34
7.7.3 Resource methods . 34
7.7.3.1 GET . 34
7.7.3.2 PUT . 35
7.7.3.3 PATCH . 36
7.7.3.4 POST . 36
7.7.3.5 DELETE . 36
7.8 Resource: subscriptions . 36
7.8.1 Description . 36
7.8.2 Resource definition . 36
7.8.3 Resource methods . 37
7.8.3.1 GET . 37
7.8.3.2 PUT . 38
7.8.3.3 PATCH . 38
7.8.3.4 POST . 38
7.8.3.5 DELETE . 39
7.9 Resource: existing subscription . 39
7.9.1 Description . 39
7.9.2 Resource definition . 39
ETSI
5 ETSI GS MEC 048 V3.1.1 (2024-04)
7.9.3 Resource methods . 40
7.9.3.1 GET . 40
7.9.3.2 PUT . 41
7.9.3.3 PATCH . 42
7.9.3.4 POST . 42
7.9.3.5 DELETE . 42
8 OpenAPI definitions (informative) . 43
8.1 Introduction . 43
8.2 Definition and operation on Resources . 43
Annex A (informative): Complementary material for API utilization . 58
Annex B (informative): Change History . 59
History . 60

ETSI
6 ETSI GS MEC 048 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 048 V3.1.1 (2024-04)
1 Scope
The present document specifies the enablement APIs produced by MEO over Mm1 reference point to support customer
self-service portal. This includes the related aspects on tenant management, per tenant application management, per
tenant resource management, basic monitoring per tenant, per tenant accounting capabilities. It describes the
information flows, required information, and specifies the necessary operations, data models and API definitions with
example codes.
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 009: "Multi-access Edge Computing (MEC); General principles, patterns and
common aspects of MEC Service APIs".
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 GR MEC 001: "Multi-access Edge Computing (MEC); Terminology".
[i.2] IETF RFC 4122: "A Universally Unique IDentifier (UUID) URN Namespace".
[i.3] OpenAPI™ Specification.
[i.4] IETF RFC 7807: "Problem Details for HTTP APIs".
[i.5] IETF RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax".
ETSI
8 ETSI GS MEC 048 V3.1.1 (2024-04)
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.1] and the following apply:
tenant: user who shares the access to the resources (e.g. a set of physical, virtual or service resources) in a private or
public environment that is isolated from other users
NOTE: A tenant in MEC can be associated with an enterprise customer who has an account with the MEC system
provider. Such enterprise customer may be associated with one or multiple tenants in a MEC system.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GR MEC 001 [i.1] and the following apply:
CSE Customer Self-service Enablement
4 Overview
The present document specifies the Customer Self-service Enablement (CSE) APIs over Mm1 reference point in order
to support customer self-service portal.
Clause 5 introduces the functionalities enabled by CSE APIs and how the CSE services may be used by a service
consumer. It provides the high-level information flows and describes the necessary operations.
The information that can be exchanged over the CSE APIs is described in clause 6 which defines detailed data models
with description on all information elements.
Clause 7 specifies the CSE APIs providing detailed information how information elements are mapped into a RESTful
API design.
The informative OpenAPI definitions are provided in clause 8 to illustrate the usage of the defined data model.
5 Description of the services (informative)
5.1 Introduction
A self-service portal is the customer facing part of the IT service management tool. In the context of MEC, self-service
portals provide customers quick and easy access to the various services and resources offered by the MEC system. The
CSE services are intended to support customer self-service portal, enabling simple application management and basic
tenant, resource management capabilities.
Via Mm1 reference point the CSE APIs enable the basic functions, including:
• Tenant management:
- creation of tenant resource;
- deletion of tenant resource;
ETSI
9 ETSI GS MEC 048 V3.1.1 (2024-04)
- updating tenant resource; and
- querying tenant resource.
• Computing resource management:
- per tenant resource request in an edge site or in a MEC system;
- per tenant resource request update in an edge site or in a MEC system; and
- per tenant resource quota query in an edge site or in a MEC system.
• REST based subscribe-notify model:
- subscribing to CSE event notifications;
- receiving notifications on subscribed CSE events;
- updating subscription for CSE event notifications; and
- unsubscribing from CSE event notifications.
5.2 Sequence diagrams
5.2.1 General
The following clauses describe how the CSE services can be used by a service consumer via Mm1 reference point. The
related sequence diagrams are presented.
5.2.2 Tenant management
5.2.2.1 Introduction
In the context of the present document, a tenant typically is associated with an enterprise customer who has an account
with the MEC system provider. The basic functionalities for tenant management include:
• tenant resource creation;
• tenant resource deletion;
• tenant resource update; and
• tenant resource query.
5.2.2.2 Tenant resource creation
Figure 5.2.2.2-1 shows a scenario where a service consumer requests to create a tenant resource.

Figure 5.2.2.2-1: Flow of tenant resource creation
ETSI
10 ETSI GS MEC 048 V3.1.1 (2024-04)
Tenant resource creation, as illustrated in Figure 5.2.2.2-1, consists of the following steps:
1) Service consumer sends a request to the CSE to create a tenant resource with the associated information.
2) CSE returns "201 Created" with the message body including the accepted TenantInfo structure.
5.2.2.3 Tenant resource deletion
Figure 5.2.2.3-1 shows a scenario where a service consumer requests to delete a tenant resource.

Figure 5.2.2.3-1: Flow of tenant resource deletion
Tenant resource deletion, as illustrated in Figure 5.2.2.3-1, consists of the following steps:
1) Service consumer sends a request to the CSE to delete a tenant resource.
2) CSE responds with "204 No content".
5.2.2.4 Tenant resource update
Figure 5.2.2.4-1 shows a scenario where a service consumer requests to update the information of a tenant resource.

Figure 5.2.2.4-1: Flow of tenant resource update
Tenant resource update, as illustrated in Figure 5.2.2.4-1, consists of the following steps:
1) Service consumer requests the CSE to update the information of a tenant resource by sending a PUT request
with the modified data structure specific to that tenant resource.
2) CSE responds with "200 OK" with the message body containing the accepted data structure specific to that
tenant resource.
5.2.2.5 Tenant resource query
Figure 5.2.2.5-1 shows a scenario where a service consumer requests to query the information of a specific tenant
resource.
ETSI
11 ETSI GS MEC 048 V3.1.1 (2024-04)

Figure 5.2.2.5-1: Flow of querying a specific tenant resource
Querying a specific tenant resource, as illustrated in Figure 5.2.2.5-1, consists of the following steps:
1) Service consumer requests the CSE to query the information of a specific tenant resource.
2) CSE responds with "200 OK" with the message body containing the information of that tenant resource.
Figure 5.2.2.5-2 shows a scenario where a service consumer requests to query the information of all tenant resources.

Figure 5.2.2.5-2: Flow of querying all tenant resources
Querying all tenant resources, as illustrated in Figure 5.2.2.5-2, consists of the following steps:
1) Service consumer requests the CSE to query the information of all tenant resources.
2) CSE responds with "200 OK" with the message body containing the information of a list of tenant resources.
5.2.3 Computing resource management
5.2.3.1 Introduction
The computing resource management is about the resource information in an edge site or a MEC system that is
associated with a tenant, and the basic functionalities include:
• per tenant resource request in an edge site;
• per tenant resource request update in an edge site;
• per tenant resource quota query in an edge site;
• per tenant resource request in a MEC system;
• per tenant resource request update in a MEC system; and
• per tenant resource quota query in a MEC system.
ETSI
12 ETSI GS MEC 048 V3.1.1 (2024-04)
5.2.3.2 Computing resource request (per-tenant)
Figure 5.2.3.2-1 shows a scenario where a service consumer requests computing resource for a tenant. It is used to
request the computing resource in a MEC system or an edge site that can be used for a tenant.

Figure 5.2.3.2-1: Flow of computing resource request
Per-tenant computing resource request, as illustrated in Figure 5.2.3.2-1, consists of the following steps:
1) Service consumer sends a message to the CSE requesting the computing resource quota for a tenant:
- Case 1: requesting computing resource in a MEC system.
- Case 2: requesting computing resource in an edge site.
2) CSE returns "201 Created" with the message body including the granted computing resource quota:
- Case 1: the data structure resourceQuotaInfo is returned.
- Case 2: the data structure siteResourceQuotaInfo is returned.
5.2.3.3 Computing resource request update (per-tenant)
Figure 5.2.3.3-1 shows a scenario where a service consumer requests to update the computing resource request for a
tenant. It is used to update the request of the computing resource in a MEC system or an edge site that can be used for a
tenant.
Figure 5.2.3.3-1: Flow of updating the computing resource request
ETSI
13 ETSI GS MEC 048 V3.1.1 (2024-04)
Computing resource request update, as illustrated in Figure 5.2.3.3-1, consists of the following steps:
1) Service consumer requests the CSE to update the computing resource request for a tenant by sending a PUT
request with the modified data structure specific to that computing resource request for a tenant:
- Case 1: updating the request of computing resource in a MEC system.
- Case 2: updating the request of computing resource in an edge site.
2) CSE responds with "200 OK" with the message body containing the accepted data structure:
- Case 1: the data structure resourceQuotaInfo is returned.
- Case 2: the data structure siteResourceQuotaInfo is returned.
5.2.3.4 Computing resource quota query (per tenant)
Figure 5.2.3.4-1 shows a scenario where a service consumer requests to query the computing resource quota for a
specific tenant. It is used to query the per-tenant quota of the computing resource in a MEC system or an edge site.

Figure 5.2.3.4-1: Flow of querying the computing resource quota
Querying the per-tenant quota of the computing resource, as illustrated in Figure 5.2.3.4-1, consists of the following
steps:
1) Service consumer requests the CSE to query the computing resource quota for a specific tenant:
- Case 1: query the per-tenant quota of the computing resource in a MEC system.
- Case 2: query the per-tenant quota of the computing resource in an edge site.
2) CSE responds with "200 OK" with the message body containing the requested information:
- Case 1: the data structure resourceQuotaInfo is returned.
- Case 2: the data structure siteResourceQuotaInfo is returned.
ETSI
14 ETSI GS MEC 048 V3.1.1 (2024-04)
5.2.4 REST based subscribe-notify model
5.2.4.1 Subscribing to CSE event notifications
To receive notifications on selected events, the service consumer creates a subscription to certain specific event that is
available. Figure 5.2.4.1-1 shows a scenario where the service consumer uses REST based procedures to create a
subscription for CSE event notifications.

Figure 5.2.4.1-1: Flow of subscribing to CSE event notifications
Subscribing to the CSE event notifications, as illustrated in Figure 5.2.4.1-1, consists of the following steps.
When the service consumer wants to receive CSE event notifications, it creates a subscription:
1) The service consumer sends a POST request with the message body containing the {NotificationSubscription}
data structure.
2) CSE sends "201 Created" response with the message body containing the data structure specific to that CSE
event subscription.
5.2.4.2 Receiving notification on expiry of CSE event subscription
CSE may define an expiry time for the CSE event subscription. In case expiry time is used, the time will be included in
the {NotificationSubscription} data structure that is included in the response message to the subscription. Prior the
expiry, CSE will also send a notification to the service consumer that owns the subscription.
Figure 5.2.4.2-1 shows a scenario where the service consumer receives a subscription expiry notification for the existing
subscription.
Figure 5.2.4.2-1: Flow of CSE sending a notification on expiry of the subscription
ETSI
15 ETSI GS MEC 048 V3.1.1 (2024-04)
Sending a notification on expiry of the subscription, as illustrated in Figure 5.2.4.2-1 consists of the following steps. If
CSE has defined an expiry time for the subscription, CSE will send a notification prior the expiry:
1) CSE sends a POST request to the callback reference address included by the service consumer in the
subscription request. The POST request contains a data structure ExpiryNotification.
2) Service consumer sends a "204 No Content" response.
5.2.4.3 Updating subscription for CSE event notifications
Figure 5.2.4.3-1 shows a scenario where the service consumer needs to update an existing subscription for a CSE event
notification. The subscription update is triggered e.g. by the need to change the existing subscription, or due to the
expiry of the subscription.
Figure 5.2.4.3-1: Flow of service consumer updating subscription for CSE event notifications
Updating subscription for CSE event notifications, as illustrated in Figure 5.2.4.3-1, consists of the following steps.
When the service consumer needs to modify an existing subscription for CSE event notifications, it can update the
corresponding subscription as follows:
1) Service consumer updates the subscription resource by sending a PUT request to the resource containing all
the subscription information with the modified data structure specific to that CSE event subscription.
2) CSE returns "200 OK" with the message body containing the accepted data structure specific to that CSE event
subscription.
5.2.4.4 Unsubscribing from CSE event notifications
When the service consumer does not want to receive notifications anymore after subscribing to CSE events, the service
consumer unsubscribes from the CSE event notifications. Figure 5.2.4.4-1 shows a scenario where the service consumer
uses REST based procedures to delete the subscription for CSE event notifications.

Figure 5.2.4.4-1: Flow of unsubscribing from the CSE event notifications
Unsubscribing from the CSE event notifications, as illustrated in Figure 5.2.4.4-1, consists of the following steps.
ETSI
16 ETSI GS MEC 048 V3.1.1 (2024-04)
When the service consumer does not want to receive the notifications anymore, it can unsubscribe from the CSE
notification events by deleting the subscription:
1) Service consumer sends a DELETE request to the resource representing the CSE event subscription that was
created.
2) CSE sends "204 No content" response.
5.2.5 Receiving CSE event notifications about resource usage in a MEC
system
Figure 5.2.5-1 presents the scenario where the CSE sends to the service consumer CSE event notifications about the
computing resource usage of a tenant in a MEC system.

Figure 5.2.5-1: Flow of receiving CSE event notifications on resource usage in a MEC system
Receiving CSE event notifications on resource usage in a MEC system, as illustrated in Figure 5.2.5-1, consists of the
following steps:
1) CSE sends a POST request with the message body containing the ResourceUsageNotification data structure to
the callback reference address included by the service consumer in the CSE event subscription.
2) Service consumer sends a "204 No Content" response to the CSE.
5.2.6 Receiving CSE event notifications about resource usage in edge
sites
Figure 5.2.6-1 presents the scenario where the CSE sends to the service consumer CSE event notifications about the
computing resource usage of a tenant in one or multiple edge sites.
ETSI
17 ETSI GS MEC 048 V3.1.1 (2024-04)

Figure 5.2.6-1: Flow of receiving CSE event notifications on resource usage in edge sites
Receiving CSE event notifications on resource usage in edge sites, as illustrated in Figure 5.2.6-1, consists of the
following steps:
1) CSE sends a POST request with the message body containing the SiteResourceUsageNotification data
structure to the callback reference address included by the service consumer in the CSE event subscription.
2) Service consumer sends a "204 No Content" response
...