ETSI GR MEC-DEC 063 V4.1.1 (2025-08)

Multi-access Edge Computing (MEC); ESTIMED Analysis and selection for oneM2M and MEC implementations

DGR/MEC-DEC063EstimedImp

General Information

• Status: Not Published
• Technical Committee: MEC DECODE - Deployment and ECOsystem DEvelopment
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Due Date: 30-Aug-2025
• Completion Date: 28-Aug-2025

Standards Content (Sample)

GROUP REPORT
Multi-access Edge Computing (MEC);
ESTIMED Analysis and selection for oneM2M
and MEC implementations
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 GR MEC-DEC 063 V4.1.1 (2025-08)

Reference
DGR/MEC-DEC063EstimedImp
Keywords
M2M, MEC, oneM2M
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 the
ETSI Search & Browse Standards application.
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 on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
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
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
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 2025.
All rights reserved.
ETSI
3 ETSI GR MEC-DEC 063 V4.1.1 (2025-08)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Overview . 8
4.1 Introduction . 8
5 MEC Implementations . 8
5.1 Introduction . 8
5.2 MEC Implementation #1 – ETSI MEC Sandbox . 9
5.2.1 Overview . 9
5.2.2 Services exposure . 10
5.2.3 How It Works . 10
5.2.4 Benefits for Developers and Industry . 11
5.2.5 License . 11
6 oneM2M Implementations . 11
6.1 Introduction . 11
6.2 oneM2M Implementation #1 – ACME oneM2M CSE . 12
6.2.1 Overview . 12
6.2.2 Supported oneM2M Feature . 12
6.2.2.1 oneM2M Specification Conformance . 12
6.2.2.2 Release Versions . 13
6.2.2.3 CSE Types. 13
6.2.2.4 Resource Types . 13
6.2.2.5 Service Functionalities . 15
6.2.2.6 Bindings . 16
6.2.2.7 Types . 17
6.2.3 CSE Runtime Features . 17
6.2.3.0 Overview . 17
6.2.3.1 Database Bindings . 17
6.2.3.2 Additional Runtime Features . 17
6.2.4 System Requirements . 18
6.2.5 Installation, Setup and Running . 18
6.2.5.0 Overview . 18
6.2.5.1 PIP Installation . 18
6.2.5.2 Manual Installation. 19
6.2.5.3 Additional Components . 19
6.2.5.4 Configuration and Onboarding. 19
6.2.5.5 Running the ACME CSE . 19
6.2.6 Test Suite . 20
6.3 oneM2M Implementation #2 – tinyIoT . 20
6.3.1 Overview . 20
6.3.2 Supported oneM2M Features . 20
6.3.2.1 oneM2M Specification Conformance . 20
6.3.2.2 CSE Types. 20
6.3.2.3 Resource Types . 21
6.3.3 Functional Capabilities . 21
ETSI
4 ETSI GR MEC-DEC 063 V4.1.1 (2025-08)
6.3.4 Protocol Bindings . 21
6.3.5 Serialization Formats . 22
6.3.6 Runtime Architecture . 22
6.3.7 MEC Integration . 22
6.3.8 Installation, Configuration, and Execution . 22
6.3.8.1 Installation . 22
6.3.8.2 Configuration . 23
6.3.8.3 Running the CSE . 23
6.3.8.4 Docker Support . 23
6.3.9 Version and Repository Information. 24
6.4 oneM2M Implementation #3 – Mobius . 24
6.4.1 Overview . 24
6.4.2 Supported Resource Type . 24
6.4.3 Functional Capabilities . 25
6.4.4 Protocol Bindings . 25
6.4.5 Serialization Formats . 25
6.4.6 Installation and Configuration . 25
6.4.7 Repository and Version Information. 26
7 Required Features for MEC and oneM2M . 26
7.1 Features for MEC . 26
7.1.0 Overview . 26
7.1.1 IoT Device and Platform Management . 26
7.1.2 Real-Time Sensor Data Access . 27
7.1.3 Service Discovery and Consumption . 27
7.1.4 Network Resource Optimization . 27
7.1.5 Application Lifecycle Management . 27
7.1.6 Required Features Summary . 27
7.2 Features for oneM2M . 28
7.2.0 Data and Resource Management . 28
7.2.1 Data and Resource Management . 28
7.2.2 Real-Time Data Exchange . 28
7.2.3 Data Retrieval and Search Capability . 29
7.2.4 Registration Feature . 29
7.2.5 Protocol Bindings . 30
7.2.6 Required Features Summary . 30
7.3 Use Case Selection Criteria . 31
7.4 Assessment Criteria for Implementations . 32
8 Recommendations and Conclusions . 33
Annex A: Change history . 34
History . 35

ETSI
5 ETSI GR MEC-DEC 063 V4.1.1 (2025-08)
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 IPR online database.
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™, LTE™ and 5G™ logo 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 Report (GR) has been produced by ETSI Industry Specification Group (ISG) Multi-access Edge Computing
(MEC).
Modal verbs terminology
In the present document "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 GR MEC-DEC 063 V4.1.1 (2025-08)
1 Scope
The present document provides a summary of the oneM2M and MEC implementations to support standardized IoT
deployments in MEC environments. It will include a list of the use case selection criteria and assessment of
implementations for use in the PoCs. It will include an evaluation of the existing features that are needed as well as an
assessment of development effort required to implement any identified potential new features. Finally, it will indicate
the selected implementations and the reasons for their selection.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
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 may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] ETSI MEC Overview Standardization update on Multi-access Edge Computing.
[i.2] ETSI MECwiki - MEC Sandbox.
[i.3] ETSI TS 129 222: "LTE; 5G; Common API Framework for 3GPP Northbound APIs (3GPP
TS 29.222)".
[i.4] ETSI GS MEC 010-2: "Multi-access Edge Computing (MEC); MEC Management; Part 2:
Application lifecycle, rules and requirements management".
[i.5] ETSI GS MEC 011: "Multi-access Edge Computing (MEC); Edge Platform Application
Enablement".
[i.6] ETSI GS MEC 012: "Multi-access Edge Computing (MEC); Radio Network Information API".
[i.7] ETSI GS MEC 013: "Multi-access Edge Computing (MEC); Location API".
[i.8] ETSI GS MEC 015: "Multi-Access Edge Computing (MEC); Traffic Management APIs".
[i.9] ETSI GS MEC 021: "Multi-access Edge Computing (MEC); Application Mobility Service API".
[i.10] ETSI GS MEC 028: "Multi-access Edge Computing (MEC); WLAN Access Information API".
[i.11] ETSI GS MEC 029: "Multi-access Edge Computing (MEC); Fixed Access Information API".
[i.12] ETSI GS MEC 033: "Multi-access Edge Computing (MEC); IoT API".
[i.13] ETSI GS MEC 030: "Multi-access Edge Computing (MEC); V2X Information Services API".
[i.14] ETSI GS MEC 040: "Multi-access Edge Computing (MEC); Federation enablement APIs".
[i.15] ETSI GS MEC 046: "Multi-access Edge Computing (MEC); Sensor-sharing API".
[i.16] ETSI White Paper No. #59: "Enabling Multi-access Edge Computing in Internet-of-Things: how
to deploy ETSI MEC and oneM2M".
ETSI
7 ETSI GR MEC-DEC 063 V4.1.1 (2025-08)
[i.17] ETSI TS 118 123: "oneM2M; SDT based Information Model and Mapping for Vertical Industries
(oneM2M TS-0023)".
[i.18] ETSI TS 118 119: "oneM2M; Abstract Test Suite and Implementation eXtra Information for Test
(oneM2M TS-0019).
[i.19] ETSI GS MEC 003: "Multi-access Edge Computing (MEC); Framework and Reference
Architecture".
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACP Access Control Policy
AE Application Entity
AI Artificial Intelligence
API Application Programming Interface
ARM Advanced RISC machine
ASN-CSE Application Services Node - Common Services Entity
BSD Berkley Software Distribution
CAPIF Common API Framework
CBOR Concise Binary Object Representation
CoAP Constrained Application Protocol
CORS Cross-Origin Resource Sharing
CRUD Create Retrieve Update and Delete
CSE Common Services Entity
CSF Common Service Function
CSR Certificate Signing Request
DTLS Datagram Transport Layer Security
HTTP Hypertext Transfer Protocol
ID IDentifier
IMEI International Mobile Equipment Identification
IN-CSE Infrastructure Node - Common Services Entity
IoT Internet of Thing
IT Information Technology
JSON JavaScript Object Notation
JSON-LD JavaScript Object Notation for Linked Data
MEC Multi-access Edge Computing
MN-CSE Middle Node - Common Services Entity
MQTT Message Queuing Telemetry Transport
NAT Network Address Translation
PIP Policy Information Point
PoA Point-of-Access
PoC Proof of Concept
QoS Quality of Service
RDF Resource Description Framework
RNI Radio Network Information
ETSI
8 ETSI GR MEC-DEC 063 V4.1.1 (2025-08)
SAREF Smart Application REFerence ontology
SP Service Provider
SUPI Subscriber Permanent Identifier
TLS Transport Layer Security
UDP User Datagram Protocol
UE User Equipment
UI User Interface
WLAN Wireless LAN
WSGI Web Server Gateway Interface
XML Extensible Markup Language
4 Overview
4.1 Introduction
The present document addresses the pivotal integration of oneM2M and Multi-access Edge Computing (MEC), a
convergence deemed critical for enabling advanced Internet of Things (IoT) applications at the network edge. As the
scale of IoT deployments expands and the demand for low-latency, real-time data processing intensifies, the seamless
interworking of these two standardized frameworks becomes imperative. This clause establishes the foundational
context for a detailed examination of how the oneM2M IoT service layer can effectively leverage the capabilities
inherent in MEC for localized data processing and optimized operational efficiency.
The present document is structured to provide a comprehensive analysis of the integrated environment.
Clause 5 provides an overview of available the MEC Sandbox implementation, detailing its architectural characteristics
and the specific functionalities offered for MEC application development and deployment at the edge. This includes an
examination of how these platforms align with ETSI MEC specifications to enable localized computing and networking
services.
Clause 6 subsequently delves into the landscape of available oneM2M implementations, specifically focusing on
prominent open-source solutions such as ACME, Mobius and tinyIoT. This clause describes their adherence to
oneM2M standards, their respective capabilities in managing IoT resources and services, and their suitability for various
deployment models, including those relevant to edge environments.
Clause 7 is dedicated to the systematic analysis of key feature requirements for both MEC and oneM2M platforms (as
elaborated in clauses 7.1 and 7.2), the proposed deployment options and associated use case selection (as defined in
clause 7.3), and the establishment of assessment criteria pertinent to various implementations (as presented in
clause 7.4). Following this comprehensive technical evaluation.
Clause 8 sets forth the principal recommendations and conclusions derived from the entirety of the analysis, with a
particular emphasis on identifying suitable open-source implementations for Proof of Concept (PoC) development that
effectively demonstrate the capabilities of edge-centric IoT use cases.
5 MEC Implementations
5.1 Introduction
Multi-access Edge Computing (MEC), standardized by the ETSI, is a transformative technology that brings cloud-
computing capabilities and IT service environments to the edge of mobile networks. By moving computation and
storage closer to end users, MEC enables ultra-low latency, high bandwidth, and real-time access to radio network
information, unlocking new business opportunities and use cases across multiple sectors [i.1].
ETSI MEC is designed as an open standard, ensuring interoperability and supporting multiple implementations. It is
access-agnostic, supporting 4G, 5G, Wi-Fi, and other network technologies, and aligns closely with the ETSI NFV
(Network Functions Virtualisation) framework and 3GPP standards for seamless integration into modern telecom
environments.
ETSI
9 ETSI GR MEC-DEC 063 V4.1.1 (2025-08)
The MEC architecture consists of the following key elements [i.1]:
• MEC Platform: The software layer that provides the environment for MEC applications to run, offering APIs
for service discovery, event notifications, and management.
• MEC Host: The physical or virtualized infrastructure at the edge that runs the MEC platform and applications.
• MEC Applications: Software components deployed at the edge to provide services such as video analytics, IoT
data processing, or location-based services.
• RESTful APIs: Standardized interfaces that allow applications to interact with MEC services, such as location,
radio network information, and application mobility.
The MEC architecture consists of the following key features [i.1]:
• Open APIs: Developer-friendly, standardized APIs to foster rapid application development and ensure
consistency.
• Service Exposure: Real-time access to network and context information, including user location, network
status, and device mobility. ®
• Multi-access Support: Operates across different access networks (cellular, Wi-Fi , etc.).
• Ecosystem Enablement: Supports a wide range of verticals, including automotive, IoT, and smart cities, and
encourages collaboration with open-source communities.
5.2 MEC Implementation #1 – ETSI MEC Sandbox
5.2.1 Overview
The ETSI MEC Sandbox is an interactive, cloud-based environment that enables developers, researchers, and solution
architects to learn, experiment, and validate applications using ETSI MEC standardized service APIs. It is designed to
bridge the gap between standards and real-world deployment by providing hands-on access to MEC APIs in a simulated
but realistic network environment [i.2].
The ETSI MEC Sandbox key capabilities are [i.2]:
• API Experimentation: Developers can interact directly with live MEC Service APIs (RESTful,
OpenAPI-compliant), including those for location (ETSI GS MEC 013 [i.7]), radio network information (ETSI
GS MEC 012 [i.6]), WLAN information (ETSI GS MEC 028 [i.10]), application enablement (ETSI
GS MEC 011 [i.5]), application mobility (ETSI GS MEC 021 [i.9]), V2X information (ETSI
GS MEC 030 [i.13]), and federation (ETSI GS MEC 040 [i.14]).
• Scenario Simulation: Users can deploy pre-defined network scenarios combining 4G, 5G, and Wi-Fi
technologies, configure terminal devices, and observe their behaviour on a geolocated map of Monaco.
• Dashboard Interface: The Sandbox provides a user-specific dashboard for managing network scenarios,
terminal devices, MEC application instances, and service lifecycles. It includes tools for API testing
(SwaggerUI), scenario configuration, and real-time visualization of assets and connectivity.
• External Integration: Developers can connect their own or third-party applications to the Sandbox, using
provided API endpoints to test real-world interactions and notification subscriptions.
• Developer Resources: The MEC Sandbox is complemented by a comprehensive Wiki, offering documentation,
ecosystem information, API conformance test suites, and proof-of-concept activities.
• Supported APIs and Services.
ETSI
10 ETSI GR MEC-DEC 063 V4.1.1 (2025-08)
5.2.2 Services exposure
The ETSI MEC Sandbox exposes the following services:
• ETSI GS MEC 011 [i.5] (App Enablement): Application registration, service discovery, event notifications,
traffic/DNS rules;
• ETSI GS MEC 011 [i.5] (MEC service management realized by CAPIF APIs): Common API Framework for
3GPP Northbound APIs [i.3];
• ETSI GS MEC 012 [i.6] (Radio Information): Radio network conditions, user plane measurements, UE
context and events;
• ETSI GS MEC 013 [i.7] (Location Information): Geospatial and network location information, user tracking,
zonal status;
• ETSI GS MEC 015 [i.8] (Traffic Management APIs): Bandwidth Management and Multi-access Traffic
Steering;
• ETSI GS MEC 021 [i.9] (App Mobility): Support for application/user context relocation between MEC hosts;
• ETSI GS MEC 028 [i.10] (WLAN Information): WLAN access point and terminal information, connectivity
events;
• ETSI GS MEC 029 [i.11] (Fixed network): Service access on Fixed Access Information for Fibre;
• ETSI GS MEC 030 [i.13] (V2X Information): Vehicle-to-everything information, predicted QoS, secure
communication with 3GPP functions;
• ETSI GS MEC 033 [i.12] (IoT Information): Communication between the IoT devices and the IoT
applications;
• ETSI GS MEC 040 [i.14] (Federation): MEC system/service/app instance discovery across federated
edge/cloud systems.
5.2.3 How It Works
Upon signing in, users can:
• Deploy and configure network scenarios and terminal devices.
• Manage MEC application instance IDs.
• Enable or disable MEC services.
• Experiment with APIs via browser-based tools or external applications.
• Observe real-time changes and responses based on scenario state.
• The Sandbox emulates MEC platforms and orchestrates applications externally, requiring manual provisioning
of application instance IDs for testing.
Here an example of the possible use cases that can be develop:
• Location-based services and analytics.
• Real-time video processing and content delivery.
• IoT data aggregation and processing at the edge.
• Connected vehicle and V2X applications.
• Smart city and industrial automation solutions.
ETSI
11 ETSI GR MEC-DEC 063 V4.1.1 (2025-08)
5.2.4 Benefits for Developers and Industry
The key benefits the ETSI MEC Sandbox offers are:
• Rapid Prototyping: Accelerates the development and validation of edge applications by providing a ready-to-
use, standards-compliant testbed.
• Interoperability Testing: Ensures applications are compatible with ETSI MEC APIs, reducing integration risks.
• Ecosystem Growth: Fosters innovation by lowering entry barriers for new developers and supporting
collaboration across industry verticals.
• Realistic Scenarios: Enables testing in simulated environments that closely mimic real-world network
conditions and user mobility.
5.2.5 License ®
• ETSI MEC Sandbox: Apache license.
• MEC conformance test suites: BSD-3.
6 oneM2M Implementations
6.1 Introduction
The oneM2M standard provides a globally harmonized framework for Machine-to-Machine (M2M) and Internet of
Things (IoT) service platforms, defining a Common Services Entity (CSE) architecture that supports interoperability
across heterogeneous devices and networks. A variety of oneM2M-compliant implementations have emerged to support
research, prototyping, deployment, and validation of real-world IoT solutions.
Open-source implementations play a crucial role in accelerating the adoption of the oneM2M standard by providing
accessible platforms for experimentation, integration with vertical applications, and demonstration of conformance.
These implementations vary in terms of target environment, supported features, technology stack, and extensibility.
This clause introduces three representative open-source oneM2M CSE implementations that are actively maintained and
widely adopted in the community: ®
• ACME: A Python -based CSE implementation that prioritizes developer experience, extensibility, and
testability.
• tinyIoT: A lightweight C-language implementation optimized for edge computing scenarios and resource-
constrained devices. ®
• Mobius™: A scalable Java Node.js-based platform developed under the OCEAN project, suited for smart
city IoT deployments.
Each implementation is analysed in terms of specification conformance, supported resource types, protocol bindings,
runtime features, installation procedures, and relevance to MEC integration. The goal is to assist developers and system
integrators in selecting the most appropriate implementation for their PoCs, research projects, or commercial
deployments.
ETSI
12 ETSI GR MEC-DEC 063 V4.1.1 (2025-08)
6.2 oneM2M Implementation #1 – ACME oneM2M CSE
6.2.1 Overview
The ACME oneM2M CSE (ACME CSE for short) is an implementation of a oneM2M Common Service Entity that
supports a rich subset of the oneM2M IoT standard. Its purpose is to provide an easy to install and run oneM2M CSE.
The ACME CSE is written in Python, and can be installed and run with a few commands almost everywhere where the
Python runtime environment is available. By default, the implementation uses a simple file-based document database
for data storage that is suitable for small installations. For more sophisticated deployments, the ACME CSE can connect
to and use a PostgreSQL database installation.
In addition to a Web-based UI, the ACME CSE also offers a rich text-based user interface that runs directly inside a
terminal console. It provides a convenient way to inspect and work with resources, requests, and status information.
This UI is especially useful when running the CSE on a remote server. The ACME CSE is designed to be extensible. It
is possible to add new resource types, and new service and runtime functions.

Figure 6.2.1-1: ACME CSE: Text UI
A more basic console UI is also available. It is the default UI when running the ACME CSE in a terminal console, and
which is better suited to show the extensive log and debug output. The ACME CSE is under active development to
include further functionalities as well as to trial new and experimental functions that are currently under discussion for
the oneM2M specification.
It is available on GitHub under the BSD 3-Clause License:
• Homepage and Documentation: https://acmecse.net
• GitHub Repository: https://github.com/ankraft/ACME-oneM2M-CSE
6.2.2 Supported oneM2M Feature
6.2.2.1 oneM2M Specification Conformance
The ACME CSE successfully passes all the relevant oneM2M test cases for the supported resource types, attributes and
behaviours.
ETSI
13 ETSI GR MEC-DEC 063 V4.1.1 (2025-08)
6.2.2.2 Release Versions
The ACME CSE supports oneM2M release 1 - 4 and the upcoming release 5 for the supported resource types and
functionalities listed below.
6.2.2.3 CSE Types
The ACME CSE supports the following CSE types:
• IN-CSE - Infrastructure Node CSE
• MN-CSE - Middle Node CSE
• ASN-CSE - Application Service Node
6.2.2.4 Resource Types
The ACME CSE supports the oneM2M resource types listed in table 6.2.2.4-1. Some resource types are not yet fully
implemented, and some features are experimental.
Table 6.2.2.4-1: ACME CSE: Supported resource types
Resource Type Remark
Entities
CSEBase (CB) The CSEBase resource type is fully supported.
Application Entity (AE) The Application Entity resource type is supported, except for some of the "S" registration
related functionalities.
RemoteCSE (CSR) The ACME CSE supports CSE registrations via the Mcc reference point. In addition
announced resources, synchronization, and transit requests that target resources on
remote CSE's are supported, as well.
Security
Access Control Policy In addition to the basic ACP functionality, the ACME CSE supports the following advanced
(ACP) ACP features:
- Attribute-based access control
- AccessControlWindow
Data Management
Container (CNT) The Container resource type is fully supported.
ContentInstance (CIN) The ContentInstance resource type is fully supported.
Values with the following data types are supported for the content attribute:
- string
- integer
- float
- boolean
- list
- dictionary / JSON object
FlexContainer (FCNT)
The ACME CSE fully supports the FlexContainer resource type.
It is possible to use the predefined FlexContainer Specializations of ETSI
TS 118 123 [i.17], AllJoin, oneM2M's GenericInterworking, or to define custom
FlexContainerSpecializations.
FlexContainerInstance
This is an experimental implementation of the draft FlexContainerInstance specification.
(FCI)
TimeSeries (TS) The ACME CSE supports missing data detection and the respective notifications.
TimeSeriesInstance
The TimeSeriesInstance resource type is fully supported, except for the
(TSI) dataGenerationTime attribute, which is only supported with absolute timestamps.
Values with the following data types are supported for the content attribute:
- string
- integer
- float
- boolean
- list
- dictionary / JSON object
ETSI
14 ETSI GR MEC-DEC 063 V4.1.1 (2025-08)
Subscription and Notification
CrossResourceSubscri
Besides the standard CrossResourceSubscription functionality the ACME CSE implements
ption (CRS) an experimental feature to support an eventEvaluationMode to react on missing events.
Subscription (SUB) The ACME CSE supports notifications via direct url or an AE's Point-of-Access (POA).
Further, BatchNotifications, attributes, notification statistics, and operation monitoring are
supported.
Device Management
Node (NOD) The Node resource type is fully supported.
Management Objects The ACME CSE supports the following management objects:
- AreaNwkDeviceInfo (ANDI)
- AreaNwkInfo (ANI)
- Battery (BAT)
- Credentials (CRDS)
- DataCollect (DATC)
- DeviceCapability (DVC)
- DeviceInfo (DVI)
- EventLog (EVL)
- Firmware (FWR)
- Memory (MEM)
- MobileNetwork (MNWK)
- MyCertFileCred (NYCFC)
- Reboot (REB)
- SIM (SIM)
- Software (SWR)
- WifiClient (WIFIC)
Communication
PollingChannel (PCH) Request and notification long-polling via the pcu(pollingChannelURI) virtual child resource
are supported.
requestAggregation functionality to retrieve multiple requests in one polling request is
supported as well.
Request (REQ) The ACME CSE supports blocking, and synchronous and asynchronous non-blocking
requests, which are managed through resources.
Group Management
Group (GRP) The ACME CSE supports requests via the fopt (fanOutPoint) virtual resource.
Remote resources may be members of a group.
Automation
Action (ACTR) The input attribute of the resource type is not supported yet.
Dependency (DEPR) The Dependency resource type is fully supported.
Semantics
SemanticDescriptor
The ACME CSE supports semantic queries and discovery for resources with semantic
(SMD) descriptors.
currently, the following presentation formats are supported:
- RDF/XML
- JSON-LD
- Turtle
Location Management
LocationPolicy (LCP) Only device-based location policy is supported. The LCP's resource stores
geo-coordinates and geo-fencing results.
Time Management
Schedule (SCH) The ACME CSE supports scheduling for various of its functions, such as CSE
communication windows, and resource types, such as the , and
resource types.
TimeSyncBeacon (TSB) The ACME CSE supports the TimeSyncBeacon resource type. The functionality is
currently only experimental and might change according to specification changes.

Figure 6.2.2.4-1 shows the class hierarchy of the supported resource types.
ETSI
15 ETSI GR MEC-DEC 063 V4.1.1 (2025-08)

Figure 6.2.2.4-1: ACME: Hierarchy of the supported oneM2M resource types
6.2.2.5 Service Functionalities
Table 6.2.2.5-1 list the supported oneM2M service functionalities.
Table 6.2.2.5-1: ACME CSE: Supported oneM2M service functionalities
Service Functionality Remark
AE Registration
The ACME CSE supports AE registration and de-registrations via the
Mca reference point.
Blocking and N
...