oneM2M support matrix

September 1, 2026 · View on GitHub

Generated — do not edit by hand. Regenerate from the development repository:

npm run --silent -w @mobius4-dev-tool/inventory inventory -- matrix \
  > ../mobius4/features/support-matrix.md

How to read this

Rows are the functional areas of the oneM2M test suite structure (TS-0018 clause 6.2). Each area holds several entries — one per resource type and operation — and the counts below are over those entries.

statusmeaning
✅ fullevery entry in the area is implemented and covered by tests
⚠️ partialsome entries are implemented; others are not, or are implemented without full coverage
❌ nonenothing in the area is implemented

The test purposes column counts the TS-0018 test purposes this repository has written tests for and seen pass. It is not a conformance certification and it is not the number of test purposes that exist for the area — an empty cell means "none demonstrated here", never "the standard defines none".

Two neighbouring files answer different questions, and it is worth knowing which to read:

  • features/capabilities.json — what a running instance answered when asked. Observed, regenerated by npm run probe-capabilities, checked in CI.
  • The OpenAPI document moved. It is no longer published here: it described the standard and this CSE at the same time, and the copy kept going stale because nothing enforced it. The standard-only document now lives in the development repository at features/onem2m-standard.yaml; join it with capabilities.json on operationId to see what this CSE supports.
  • this file — how far the implementation reaches across the standard.

Areas

areastatusentries implementedtest purposes demonstrated
3GPP interworking (3GPP)❌ none0 / 1
Announcement (ANNC)❌ none0 / 23
Device automation (DAU)❌ none0 / 1
Discovery (DIS)⚠️ partial0 / 14
Data management and repository (DMR)⚠️ partial24 / 399
flexContainer (FLXC)⚠️ partial0 / 21
General capability (GEN)⚠️ partial4 / 8
Group management (GMG)⚠️ partial3 / 421
Inter-service provider (ISP)❌ none0 / 1
Location (LOC)⚠️ partial0 / 1
Polling channel (PCH)❌ none0 / 1
Process management (PMG)❌ none0 / 2
Privacy policy (PP)❌ none0 / 1
Registration (REG)✅ full5 / 546
Request tracking (RT)❌ none0 / 1
Service charging and accounting (SCA)❌ none0 / 1
Schedule (SCH)❌ none0 / 1
Security (SEC)❌ none0 / 1
Semantics (SEM)❌ none0 / 4
Software management (SM)❌ none0 / 1
Semantic mashup (SSM)❌ none0 / 1
Service subscription (SSUP)❌ none0 / 1
Subscription and notification (SUB)⚠️ partial2 / 713
Time management (TMG)❌ none0 / 3
Time series (TS)⚠️ partial0 / 12
total38 / 11296

Resource types

The same entries, grouped by the resource type they act on rather than by test-suite area. An area folds several resource types together, so it cannot answer the question most readers arrive with — whether a particular resource type works here.

A type is ✅ only when every operation recorded for it is implemented and tested, so a type whose CRUD works but whose announcement does not reads as ⚠️ with a zero in the ✅ column — read all three counts, not the first one alone. The operations column lists the operations this inventory tracks for the type, not the ones the standard defines.

resource typestatus✅ / ⚠️ / ❌operationstest purposes
<accessControlPolicy> (acp)⚠️ partial4 / 0 / 4CREATE, DELETE, RETRIEVE, UPDATE
<AE> (ae)✅ full4 / 0 / 0CREATE, RETRIEVE, UPDATE11
<container> (cnt)⚠️ partial4 / 0 / 4CREATE, DELETE, RETRIEVE, UPDATE3
<contentInstance> (cin)⚠️ partial4 / 0 / 2CREATE, DELETE, RETRIEVE2
<flexContainer>⚠️ partial0 / 2 / 0CREATE, UPDATE1
<group> (grp)⚠️ partial4 / 0 / 4CREATE, DELETE, RETRIEVE, UPDATE
<node> (nod)❌ none0 / 0 / 3CREATE, RETRIEVE, UPDATE
<remoteCSE> (csr)✅ full6 / 0 / 0CREATE, DELETE, RETRIEVE, UPDATE
<subscription> (sub)✅ full5 / 0 / 0CREATE, DELETE, RETRIEVE, UPDATE
<timeSeries> (ts)⚠️ partial0 / 4 / 4CREATE, DELETE, RETRIEVE, UPDATE3
<timeSeriesInstance> (tsi)⚠️ partial0 / 3 / 3CREATE, DELETE, RETRIEVE, UPDATE1

Known limitations

What a type marked ⚠️ does not do yet. Silence here is not a promise: a type may be ⚠️ for a reason nobody has written down, and this list only shows the reasons that were.

  • <timeSeries> — Missing-data detection records into missingDataList but does not notify: the missingData condition of eventNotificationCriteria and notificationEventType=8 are not implemented.
  • <timeSeriesInstance> — dataGenerationTime accepts only the absolute YYYYMMDDTHHMMSS form; the fractional-second and relative-offset forms that TS-0004 permits for absRelTimestamp are rejected.

Non-normative entries (candidate solutions and project proposals)

These entries are not part of the ratified oneM2M standard. The source column says why: TR-<NNNN> — a candidate solution from a oneM2M Technical Report, still under study and not yet folded into a TS; project — an extension this codebase proposes on its own, with no oneM2M document behind it at all; manual — a standard feature the automated ATS scan cannot find on its own, added by hand. None of these have an official ATS or a TS-0018 test purpose, so none can appear in the Areas table above or count toward its totals — that table would otherwise misread as "the CSE supports part of the standard that does not exist yet" (or supports something the standard never described at all). Where these are verified, it is by this project's own test purposes (TP/<source>/...), not TS-0018's.

areasourcestatusentries implemented
AI/MLproject✅ full1 / 1
AI/MLTR-0071⚠️ partial3 / 7
Data management and repositorymanual✅ full1 / 1
flexContainermanual✅ full2 / 2

Source: features/inventory.yaml (mobius4-dev-tool).