ISO/IEC 23093-2:2025

Information technology - Internet of media things - Part 2: Discovery and communication application programming interface (API)

This document specifies the abstract class of a media thing (MThing), a basic component to construct the Internet of media things. The MThing class contains the basic APIs to: - discover other MThing(s) in the network; - connect/disconnect MThing(s); and, - support transactions (e.g. payments) using media tokens between MThings.

Technologies de l'information — Internet des objets media — Partie 2: API pour la decouverte et la communication

General Information

• Status: Published
• Publication Date: 16-Dec-2025
• ICS: 35.040.40 - Coding of audio, video, multimedia and hypermedia information
• Technical Committee: ISO/IEC JTC 1/SC 29 - Coding of audio, picture, multimedia and hypermedia information
• Drafting Committee: ISO/IEC JTC 1/SC 29 - Coding of audio, picture, multimedia and hypermedia information
• Current Stage: 6060 - International Standard published
• Start Date: 17-Dec-2025
• Due Date: 18-Jan-2026
• Completion Date: 17-Dec-2025

Relations

• Revises: ISO/IEC 23093-2:2022 - Information technology - Internet of media things - Part 2: Discovery and communication API
• Effective Date: 28-Jan-2023

Overview

ISO/IEC 23093-2:2025 defines the Discovery and Communication Application Programming Interface (API) for the Internet of Media Things (IoMT). It specifies the abstract class of a media thing (MThing) and the core APIs needed to discover other MThings on a network, establish and release connections, and support transactions (payments) between MThings using media tokens. The standard is part of the ISO/IEC 23093 series that provides an overall architecture and data formats for media sensors, actuators, storages and analysers.

Key topics

• MThing abstract class and APIs: Core operations for discovering MThings, connecting/disconnecting, capability checks and capability reservation. Example operations described include discoverMThingByCapability(), isCapabilityAvailable(), disconnectMThing(), sendBackMThingInfo() and alertDisconnection().
• Discovery and capability-based matching: Locate MThings by supported capabilities or token types and exchange MThingInfo (referenced data format in ISO/IEC 23093-3).
• Communication and resource reservation: Mechanisms to reserve exclusive access to capabilities (e.g., SENSOR_CAPTURE_AUDIO) and to release or alert about capability availability changes.
• Transaction support with media tokens: APIs to query costs (e.g., getVideoURL_CostPerMinute()), request wallet addresses, check transaction completion (checkTransactionCompletion(tid)) and obtain service URLs (getVideoURL(), setVideoURL()).
• Resilient payment models: Guidance and examples for on-chain and off-chain approaches such as state channel methods to support real‑time micropayments and to handle interruptions without complex refunds.
• Return types and capability descriptions: Specified return classes such as MThingInfoType and references to MPEG-21 terminal capability types for hardware/terminal descriptions.

Applications

• Developers and platform architects building interoperable IoMT ecosystems (smart cameras, displays, sensors, actuators).
• IoT device manufacturers implementing discoverable media-capable devices and capability reservation semantics.
• App, DApp and web developers integrating pay-per-use media services (streaming, sensing, actuation) with token-based payments.
• Systems integrators designing resilient media service workflows using blockchain or state-channel payment models.
• Researchers and standards implementers requiring a formal API model for media thing discovery, connection management and transactional interactions.

Related standards

• ISO/IEC 23093-1: Architecture for the Internet of Media Things
• ISO/IEC 23093-3: Media data formats and API (data payloads and MThingInfo)
• ISO/IEC 21000-7 (MPEG‑21 Part 7) for terminal capability descriptions

ISO/IEC 23093-2 is essential for implementing interoperable, secure and token-enabled discovery and communication in IoMT systems, enabling practical use cases such as pay-per-view camera streams, paid sensing services and media-driven device orchestration.

Standards Content (Sample)

International
Standard
ISO/IEC 23093-2
Third edition
Information technology — Internet
2025-12
of media things —
Part 2:
Discovery and communication
application programming interface
(API)
Technologies de l'information — Internet des objets media —
Partie 2: API pour la decouverte et la communication
Reference number
© ISO/IEC 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2025 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 APIs . 1
4.1 General .1
4.2 Abstract Class of MThing .7
4.2.1 General .7
4.2.2 MThing APIs .7
4.3 Return type class.10
4.3.1 MThingInfoType .10
4.3.2 MPEG21TerminalCapabilityType . 12

© ISO/IEC 2025 – All rights reserved
iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialised system for worldwide standardisation. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organisation to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organisations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 29, Coding of audio, picture, multimedia and hypermedia information.
This third edition cancels and replaces the first edition (ISO/IEC 23093-2:2022), which has been technically
revised.
The main changes are as follows:
— modification of the Introduction;
— addition of new APIs for discovery and communication.
A list of all parts in the ISO/IEC 23093 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2025 – All rights reserved
iv
Introduction
The ISO/IEC 23093 series provides an architecture and specifies APIs and compressed representation of
data flowing between media things (MThings).
The APIs for MThings facilitate the discovery of other MThings in the network, as well as the connection and
efficient exchange of data between MThings. The APIs also support transaction tokens to access valuable
functionalities, resources, and data from MThings.
MThing-related information comprises characteristics and discovery data, mission descriptions from system
designers and end-users, raw and processed sensed data and actuation information. The ISO/IEC 23093
series specifies input and output data formats for media sensors, actuators, storages, and analysers. In
addition, media analysers can process sensed data from media sensors to produce analysed data, which can
be cascaded to other media analysers to extract semantic information. Multiple MThings can be gathered
and operated autonomously using mission descriptions given by system designers and end-users.
This document contains the APIs to discover media things in the network, communication between media
things, and the APIs to facilitate transactions between media things.

© ISO/IEC 2025 – All rights reserved
v
International Standard ISO/IEC 23093-2:2025(en)
Information technology — Internet of media things —
Part 2:
Discovery and communication application programming
interface (API)
1 Scope
This document specifies the abstract class of a media thing (MThing), a basic component to construct the
Internet of media things. The MThing class contains the basic APIs to:
— discover other MThing(s) in the network;
— connect/disconnect MThing(s); and,
— support transactions (e.g. payments) using media tokens between MThings.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 23093-1, Information technology — Internet of media things — Part 1: Architecture
ISO/IEC 23093-3, Information technology — Internet of media things — Part 3: Media data formats and API
ISO/IEC 21000-7:2007, Information technology — Multimedia framework (MPEG-21) — Part 7: Digital Item
Adaptation
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 23093-1 apply.
ISO and IEC maintain terminology databases for use in standardisation at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
4 APIs
4.1 General
This clause specifies APIs to discover MThings and connect/disconnect communication between MThings.
Besides, APIs and return class types are specified to provide MThing information and hardware descriptions.
An MThing can be discovered by its capabilities or supported media token types. The discovered MThing(s)
can then relay its (their) information to the requester (i.e. another MThing).

© ISO/IEC 2025 – All rights reserved
Figure 1 shows the process of discovering MThings in the network by a required capability. Each MThing
supports the required capability and can send back its information. In the figure, an MThing broadcasts a
message using discoverMThingByCapability()to look for MSensors capable of capturing audio (Figure 1,
item 1). Each MSensor (e.g. MMicrophone1, MMicrophone2, MCamera1) sends back its information using
sendBackMThingInfo(), which returns the data format MThingInfo specified in ISO/IEC 23093-3 (Figure 1,
item 2).
Figure 2 shows the process of connecting MThings with a capability. First, an MThing (i.e. ReqMThing)
can ask the availability of the specific capability (e.g. SENSOR_CAPTURE_AUDIO) with the function
isCapabilityAvailable() to another MThing (Figure 2, item 1). If the capability “SENSOR_CAPTURE_AUDIO”
is currently unavailable, the MThing (i.e. MMicrophone1) notifies “unavailable” (Figure 2, item 2). Then, the
ReqMThing can ask for the availability of the specific capability again to other MThings (Figure 2, item 3)
with the binary representation of “MSensor” and “SENSOR_CAPTURE_AUDIO”. Because the MCamera1
notifies the ReqMThing that its “SENSOR_CAPTURE_AUDIO” capability is available (Figure 2, item 4), the
ReqMThing can connect to the camera and reserve its “SENSOR_CAPTURE_AUDIO” capability (Figure 2,
item 5). As long as the ReqMThing uses the capability “SENSOR_CAPTURE_AUDIO” of the MCamera1, other
MThings cannot access the corresponding capability.
Figure 1 — Discovering MThings by capabilities
Figure 2 — Connecting MThings based on a capability

© ISO/IEC 2025 – All rights reserved
Figure 3 shows the process of disconnecting (i.e. releasing capabilities of) an MThing. The ReqMThing
can release either all of its reserved capabilities of the MCamera (Figure 3, items 1 and 2) or a designated
capability (e.g. SENSOR_CAPTURE_AUDIO) (Figure 3, items 3 and 4) using disconnectMThing().
Figure 3 — Disconnecting an MThing
Figure 4 shows the process where MThing alerts other MThings that all or some of its capabilities will be
unavailable. The MCamera can warn the MThing_01 that either all of the capabilities reserved by MThing_01
are unavailable (Figure 4, items 1 and 2) or a designated capability (e.g. SENSOR_CAPTURE_AUDIO) is no
longer available to MThing_01 (Figure 4, items 3 and 4) using alertDisconnection().
Figure 4 — Alerting disconnection to an MThing

© ISO/IEC 2025 – All rights reserved
Figure 5 — Transaction process between a user and an MThing
Figure 5 shows a sequence diagram of a transaction process between a user and an MThing. Suppose a user
wants to watch a video captured from a nearby camera (i.e. MCamera). The user asks for a cost per minute
to watch a video taken by the MCamera using getVideoURL_CostPerMinute(). Using the user interface of
Apps, DApps, or Web (Figure 5, item 1), the user can send desired media tokens defined by tokenType (e.g.
cryptocurrency or legal tender) and tokenName (e.g. Bitcoin or US dollar). The MCamera returns the cost per
minute to let the user use the getVideoURL() function (Figure 5, item 2). If the user wants to watch the video
with the responded price, they ask for a wallet address (Figure 5, item 3) of the desired MToken. Again, the
MCamera responds with the proper wallet address (Figure 5, item 4). The user sends some MTokens to the
wallet address through a payment system like a blockchain or a banking system (Figure 5, item 5), which
returns a transaction ID (Figure 5, item 6). With this transaction ID (i.e. tid), the user can confirm (Figure 5,
item 8) whether the token transaction was completed to the designated wallet address or not (Figure 5,
item 7) using checkTransactionCompletion(tid). Once the transaction is confirmed, the user can request
the video stream service to the MCamera using getVideoURL(tid) (Figure 5, item 9). The MCamera checks
for the completion of the token transaction using checkTransactionCompletion(tid) (Figure 5, item 10) and
the amount of MTokens received (Figure 5, item 11). The MCamera returns a video URL and streams the
video as much as the user paid (Figure 5, item 12). The details of APIs getVideoURL_CostPerMinute() and
getVideoURL() are given in ISO/IEC 23093-3.
Figure 6 shows a sequence diagram of a transaction process between MThings. Suppose that a camera (i.e.
MCamera) wants to stream a captured video to a nearby display (i.e. MDisplay) and play it. The MCamera
asks a cost per minute to play a video on the MDisplay using setVideoURL_CostPerMinute()(Figure 6, item 1)
with desired media token defined by tokenType (e.g. cryptocurrency or legal tender) and tokenName (e.g.
Bitcoin or US dollar). The MDisplay returns the cost per minute to use the setVideoURL() function (Figure 6,
item 2). If the MCamera wants to play the video with the responded price, it asks for a wallet address
(Figure 6, item 3) of the desired MToken. Again, the MDisplay responses with the proper wallet address
(Figure 6, item 4). The MCamera sends some MTokens to the wallet address through a payment system like
a blockchain or a banking system (Figure 6, item 5), which returns a transaction ID (Figure 6, item 6). With
this transaction ID (i.e. tid), the MCamera can confirm (Figure 6, item 8) whether the token transaction was
completed to the
...