ISO/IEC 23006-1:2018
(Main)Information technology — Multimedia service platform technologies — Part 1: Architecture
Information technology — Multimedia service platform technologies — Part 1: Architecture
This document specifies the MPEG-M architecture that is made accessible through the set of MPEG-M high level APIs, MPEG extensible middleware API, elementary services and service aggregation specified in ISO/IEC 23006-2, ISO/IEC 23006-4 and ISO/IEC 23006-5 and as a software implementation in ISO/IEC 23006-3, respectively. NOTE Annex A provides an informative example of how MPEG-M can be used to create a fully-fledged multimedia platform.
Technologies de l'information — Technologies de la plate-forme de services multimédia — Partie 1: Architecture
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 23006-1
Third edition
2018-05
Information technology — Multimedia
service platform technologies —
Part 1:
Architecture
Technologies de l'information — Technologies de la plate-forme de
services multimédia —
Partie 1: Architecture
Reference number
ISO/IEC 23006-1:2018(E)
©
ISO/IEC 2018
---------------------- Page: 1 ----------------------
ISO/IEC 23006-1:2018(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2018
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: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2018 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 23006-1:2018(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms and elements of the MPEG-M architecture . 2
4.1 Abbreviated terms . 2
4.2 Elements of the MPEG-M architecture . 3
5 Namespace conventions . 3
6 System overview . 4
7 MPEG-M architecture . 8
7.1 General . 8
7.2 High-level API . . 8
7.2.1 General. 8
7.2.2 Network services . 9
7.2.3 Energy management . 9
7.2.4 Security .10
7.3 MPEG-M middleware .10
7.3.1 Protocol engines .10
7.3.2 Technology engines .12
7.4 Orchestration .12
7.5 Aggregated services .15
7.6 Reference software and conformance .15
Annex A (informative) MPEG-M based advanced multimedia platform .16
Bibliography .24
© ISO/IEC 2018 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 23006-1:2018(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
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).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on 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 the following
URL: www .iso .org/iso/foreword .html.
This document was prepared by 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 second edition (ISO/IEC 23006-1:2013), which has been
technically revised.
The main changes compared to the previous edition are as follows:
— A new reference diagram of an MPEG-M device where the middleware is seen as a black box. ISO/
IEC 23006-2 specifies a particular instance of the MPEG-M middleware which is organized in
engines.
— High level API exposed by any MPEG-M middleware.
A list of all parts in the ISO/IEC 23006 series can be found on the ISO website.
iv © ISO/IEC 2018 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC 23006-1:2018(E)
Introduction
The ISO/IEC 23006 series has been developed to enable the easy design and implementation of media-
handling value chains supported by devices that interoperate because they are all based on the same set
of technologies, especially MPEG technologies. The functionalities provided by the MPEG technologies
are accessible via application programming interfaces (API).
The ISO/IEC 23006 series specifies a service-oriented architecture (Part 1), middleware API (Part 2),
conformance and reference software (Part 3), a set of protocols supporting elementary services (Part
4) and the combination of elementary services into aggregated services (Part 5).
MPEG-M supports the service providers’ desire to designed and deploy at reduced cost innovative
multimedia services. This is achieved by identifying a set of elementary services (ES) and defining the
corresponding set of protocols and APIs to enable any user in an MPEG-M value chain to access those
services in an interoperable fashion.
NOTE An MPEG-M value chain is a collection of users, including creators, end users and service providers
that conform to the ISO/IEC 23006 series.
In many real-world MPEG-M value chains, service providers would not be able to exploit the potential of
the series if they were confined to only offer elementary services. Therefore service providers (SP) will
typically offer bundles of ESs, known as aggregated services (AS). In general, there will be a plurality
of SPs offering the same or partially overlapping aggregated services. For example, a SP offering user
description services, may offer content description services as well.
Starting from ISO/IEC 23006-4, an aggregation of services can put together a number of services
generating a complex ISO/IEC 23006 value network, having different topologies and associated services.
Using the ISO/IEC 23006 series, a digital media ecosystem can be established, where:
— developers can offer MPEG-M service components to the professional market because a market will
be enabled by the standard MPEG-M component service API;
— manufacturers can offer MPEG-M devices to the global consumer market because of the global reach
of MPEG-M services;
— service providers can set up and launch new attractive MPEG-M services because innovative
MPEG-M value chains can be easily designed and implemented;
— developers can make available a variety of multimedia applications;
— users can seamlessly create, offer, search, access, pay/cash and consume MPEG-M services.
The ISO/IEC 23006 series extends the devices capabilities with advanced features such as content
generation, processing, and distribution by a large number of users; easy creation of new services
by combining service components of their choice; global, seamless and transparent use of services
regardless of geo-location, service provider, network provider, device manufacturer and provider of
payment and cashing services; diversity of user experience through easy download and installation
of applications produced by a global community of developers since all applications share the same
middleware APIs; and innovative business models because of the ease to design and implement
media-handling value chains whose devices interoperate because they are all based on the same set of
technologies, especially MPEG technologies.
The ISO/IEC 23006 series is subdivided in five parts:
Part 1 — Architecture (the present document): specifies the architecture that can be used as a guide to
an MPEG-M implementation;
Part 2 — MPEG extensible middleware (MXM) API: specifies the middleware APIs;
© ISO/IEC 2018 – All rights reserved v
---------------------- Page: 5 ----------------------
ISO/IEC 23006-1:2018(E)
Part 3 — Conformance and reference software: specifies conformance criteria and a reference software
implementation with a normative value;
Part 4 — Elementary services: specifies elementary service protocols between MPEG-M applications;
Part 5 — Service aggregation: specifies mechanisms enabling the combination of elementary services
and other services to build aggregated services.
vi © ISO/IEC 2018 – All rights reserved
---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO/IEC 23006-1:2018(E)
Information technology — Multimedia service platform
technologies —
Part 1:
Architecture
1 Scope
This document specifies the MPEG-M architecture that is made accessible through the set of MPEG-M
high level APIs, MPEG extensible middleware API, elementary services and service aggregation
specified in ISO/IEC 23006-2, ISO/IEC 23006-4 and ISO/IEC 23006-5 and as a software implementation
in ISO/IEC 23006-3, respectively.
NOTE Annex A provides an informative example of how MPEG-M can be used to create a fully-fledged
multimedia platform.
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 23000-16, Information technology — Multimedia Application Format (MPEG-A) — Part 16: Publish
Subscribe Application Format
ISO/IEC 23006-2, Information technology — Multimedia service platform technologies — Part 2: MPEG
extensible middleware (MXM) APIs
ISO/IEC 23006-3, Information technology — Multimedia service platform technologies — Part 3:
Conformance and reference software
ISO/IEC 23006-4, Information technology — Multimedia service platform technologies — Part 4:
Elementary services
ISO/IEC 23006-5, Information technology — Multimedia service platform technologies — Part 5: Service
aggregation
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http: //www .electropedia .org/
— ISO Online browsing platform: available at http: //www .iso .org/obp
3.1
application
software that runs in the environment and makes calls to the high-level API
© ISO/IEC 2018 – All rights reserved 1
---------------------- Page: 7 ----------------------
ISO/IEC 23006-1:2018(E)
3.2
computing platform
combination of hardware and basic software, such as operating system and drivers, that executes
software
3.3
device
environment that includes software conforming to this specification
3.4
engine
component of the middleware that provides a defined functionality or set of functionalities
accessible via API
3.5
environment
combination of hardware and software that exposes high-level API, and interfaces to devices that
expose low-level API
3.6
high-level API
abstracted API exposed by a device to enable an application to access its functionalities and services
3.7
low-level API
programmatic interfaces exposed by devices, such as security devices, to the middleware
3.8
middleware
software providing functionalities to local and remote applications
3.9
middleware API
combination of the API of all engines in the middleware
3.10
orchestrator engine
special engine capable of creating chains of engines
EXAMPLE To set-up a sequence of connected engines to execute a high-level API call such as play.
3.11
user
any entity making use of a device
4 Abbreviated terms and elements of the MPEG-M architecture
4.1 Abbreviated terms
API application programming interface
BPMN business process model and notation
CEL contract expression language
DASH dynamic adaptive streaming over HTTP
DID digital item declaration
2 © ISO/IEC 2018 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC 23006-1:2018(E)
DIDL digital item declaration language
DII digital item identification
ER event report
ERR event report request
HTTP hypertext transport protocol
IPMP intellectual property management and protection
PSAF publish/subscribe application format
PubSub publish/subscribe messaging model
REL rights expression language
URI uniform resource identifier
4.2 Elements of the MPEG-M architecture
Device device conforming to this specification
Application software component that runs on devices
High-level API abstracted API exposed by a device to enable an application to access its
functionalities and services
Middleware software layer providing functionalities to local and remote applications
Engine bundle of technologies that provide a defined functionality or set of functionalities
Engine API API exposed by an engine to enable another engine/application to access its
functionality
Mid-level API collection of all engine API
Low-level API API exposed by devices such as network, smart card or battery attached to a device
Orchestrator special engine capable of creating chains of engines to execute a high-level application
Engine call such as “play” that typically requires access to multiple engine functionalities
5 Namespace conventions
Throughout this document, qualified names are written with a namespace prefix followed by a colon
followed by the local part of the qualified name.
For clarity, throughout this document, consistent namespace prefixes are used. Table 1 gives these
prefixes and the corresponding namespace.
Table 1 — Namespaces and prefixes
Prefix Corresponding namespace
mpegm urn:mpeg:mpegM:schema:02-service-NS:2011
mpegmb urn:mpeg:mpegM:schema:01-base-NS:2011
dia urn:mpeg:mpeg21:2003:01-DIA-NS
erl urn:mpeg:mpeg21:2005:01-ERL-NS
© ISO/IEC 2018 – All rights reserved 3
---------------------- Page: 9 ----------------------
ISO/IEC 23006-1:2018(E)
Table 1 (continued)
Prefix Corresponding namespace
fru urn:mpeg:mpegB:schema:FragmentRequestUnits:2007
mpeg7 urn:mpeg:mpeg7:schema:2004
mpeg7s urn:mpeg:mpeg7:systems:2001
cel urn:mpeg:mpeg21:cel:contract:2011
bbl urn:mpeg:mpeg21:2007:01-BBL-NS
dii urn:mpeg:mpeg21:2002:01-DII-NS
mpqf urn:mpeg:mpqf:schema:2008
mpeg4ipmp urn:mpeg:mpeg4:IPMPSchema:2002
ipmpdidl urn:mpeg:mpeg21:2004:01-IPMPDIDL-NS
ipmpmsg urn:mpeg:mpeg21:2006:07-IPMPMESSAGES-NS
ipmpinfo urn:mpeg:mpeg21:2004:01-IPMPINFO-NS
didl urn:mpeg:mpeg21:2002:02-DIDL-NS
didl-mpegm urn:mpeg:mpegm:2011:12-DIDL-NS
didmodel urn:mpeg:mpeg21:2002:02-DIDMODEL-NS
didl-msx urn:mpeg:maf:schema:mediastreaming:DIDLextensions
dii urn:mpeg:mpeg21:2002:01-DII-NS
rel-r urn:mpeg:mpeg21:2003:01-REL-R-NS
rel-sx urn:mpeg:mpeg21:2003:01-REL-SX-NS
xsd
http: //www .w3 .org/2001/XMLSchema
xsi
http: //www .w3 .org/2001/XMLSchema -instance
dsig
http: //www .w3 .org/2000/09/xmldsig #
xenc
http: //www .w3 .org/2001/04/xmlenc #
6 System overview
A general architecture of a device is given in Figure 1.
Figure 1 — Generic MPEG-M device architecture
Applications run on the device and perform their expected actions by accessing the middleware
functionalities via the high-level API. In general a plurality of applications run on a device (there may be
other non-MPEG-M applications but these are not relevant for this document). Some may be “resident”,
e.g., they have been loaded by the device manufacturer while some may be temporary, e.g., they have
been downloaded for a specific purpose.
4 © ISO/IEC 2018 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC 23006-1:2018(E)
Examples of applications include:
— Video viewer: an application to view governed videos from a service provider;
— Content creator: an application to create content with audio-visual resources, metadata and rights
information;
— Licence server: an application managing a licence-issuing service.
The high-level APIs are abstracted APIs exposed by a device to enable an application to access its
functionalities and services.
The middleware allows application easy access to platform functionalities.
Low-level APIs provide access to the functionalities of computing platform and external devices.
ISO/IEC 23006-2 specifies a particular middleware organisation, as depicted in Figure 2.
Figure 2 — Engine-based middleware
In this case, the middleware is made up of a number of engines (there may be other non-MPEG-M
engines but these are not relevant for this specification).
Engines are of two types:
a) Protocol engines (specified in ISO/IEC 23006-4) that implement elementary services. Protocol
engines can be combined by aggregation to implement aggregated services.
b) Technology engines (specified in ISO/IEC 23006-2) that implement specific technologies.
Technology engines can be combined by orchestration to implement groups of technologies.
Middleware APIs are the combination of the APIs of all engines in the middleware.
Device is a combination of hardware and software conforming to this document. A device is often
interfaced to other devices, e.g.:
a) local resources that provide computational resources,
b) security device, such as a smart card, that performs cryptographic functions,
c) network that provide connectivity with other devices, and
d) energy device that provides information on battery status.
Two applications running on different networked devices can communicate by executing service
protocols, as depicted in Figure 3.
© ISO/IEC 2018 – All rights reserved 5
---------------------- Page: 11 ----------------------
ISO/IEC 23006-1:2018(E)
Figure 3 — Communication between two devices
When the device on the right-hand side (e.g., a “client”) communicates with the device on the left-hand
side (e.g. a “server”), the following happens:
a) A client application makes a service request (e.g., an elementary service such as create licence)
using a protocol engine.
b) The corresponding server-side protocol engine, upon receiving the request, calls the appropriate
orchestrator engine’s API functionality (e.g., REL orchestration) or chain of engines.
c) The orchestrator engine on the server, if required, sets up a chain of engines: in the REL example,
just one technology engine (the REL engine) creates the requested licence.
d) The server-side protocol engine returns the licence to the client-side protocol engine.
The same happens if the client application makes an aggregated service request. In this case the
orchestrator engine sets up a more complex chain of technology and protocol engines.
When an application is executed, “low-level” calls may be made directly to some engines using the
engine API of each specific engine, and high-level API calls like, say, “Play (GovernedContent)” which
will be handled by the orchestrator engine. This is depicted in Figure 4.
Figure 4 — View inside a device
6 © ISO/IEC 2018 – All rights reserved
---------------------- Page: 12 ----------------------
ISO/IEC 23006-1:2018(E)
Making reference to Figure 1, the following possibilities exist for an application:
a) It calls the middleware API to access a protocol engine which in its turn calls a technology engine.
b) It calls the middleware API to access a protocol engine which in its turn calls a plurality of
technology engines.
c) It calls the middleware API to access a combination of protocol engines which call a single
technology engine.
d) It calls the middleware API to access a protocol engine.
e) It calls the middleware API to access a technology engine.
f) It calls the high-level API to access the orchestrator engine.
The orchestrator engine, by calling the engine APIs of specific engines, is capable of setting up chains of
engines for handling complex operations, orchestrating the intervention and send/receive data to/from
the particular chain of engines that a given high-level call will trigger, thus relieving applications from the
need to carry the logic of handling them. Each engine will contain a specific set of technologies accessible
by an application, the orchestrator engine and any other engine, by means of its own engine API.
For instance, in the case of “Play (GovernedContent)” the orchestrator engine could set-up the
following chain:
a) MP21 file engine (e.g. open the file and extract the digital item);
b) Digital item engine (e.g. extract metadata and rights information);
c) REL engine (e.g. verify if the right to play is granted);
d) IPMP engine (e.g. set up IPMP tools to decrypt protected resources);
e) Security engine (e.g. initialise the IPMP tools with decryption keys);
f) Metadata engine (e.g. for presentation of content metadata to the user);
g) Media framework engine (e.g. demux, decode and render audio-visual resources);
h) and possibly others.
It should be noted that only the APIs of an engine are normative; how each engine handles the operations
needed to carry out a request depends on the specific software or hardware engine implementation.
Figure 5 depicts the general case of an aggregated service implemented by the aggregation of three
protocol engines (PE , PE and PE ), the first calling a single technology engine, the second three TEs
a b c
and the third two TEs.
Figure 5 — Engine aggregation and orchestration
© ISO/IEC 2018 – All rights reserved 7
---------------------- Page: 13 ----------------------
ISO/IEC 23006-1:2018(E)
7 MPEG-M architecture
7.1 General
MPEG-M specifies an architecture containing MPEG-standard multimedia technologies whose purpose
is to enable the easy design and implementation of media-handling value chains whose devices
interoperate because they are all based on the same set of technologies exposed through standard APIs.
The elements of the architecture are:
a) Application, software that makes calls to the high-level API;
b) High-level API, exposed to applications;
c) Middleware;
d) Low-level API, exposed by computing platform and external devices;
e) Device, a combination of hardware and software conforming to ISO/IEC 23006.
In case of engine-based middleware the following elements should be added:
a) Engine API that can be used to access engine functionality;
b) Engines, collections of specific technologies that are bundled together to provide a specific
functionality that is provided to applications;
c) Orchestrator engine, a special engine capable of creating chains of engines to execute a high-level
application call such as “Play”;
d) Middleware API, the collection of all engine APIs.
The engine APIs are divided in three categories.
— Creation API: this includes APIs to create data structures, files, elementary streams, etc. conforming
to the respective standards.
— Access API: this includes APIs to parse data structures, files, decode elementary streams, etc. in
order to retrieve the information contained within.
— Engine-specific APIs: this includes specific APIs of an engine.
The first two categories include those recurring for more than one engine, while the last category
includes those APIs which are specific for one engine.
7.2 High-level API
7.2.1 General
The high-level APIs are abstracted APIs exposed by a device to enable an application to access its
functionalities and services high-level API for publish/subscribe pattern.
The publish/subscribe messaging service can be realized with a topic-based, content-based or
mixed filtering. A publish-subscribe messaging service architecture shall implement the following
methods: device.
8 © ISO/IEC 2018 – All rights reserved
---------------------- Page: 14 ----------------------
ISO/IEC 23006-1:2018(E)
Methods
a) Method: Publish.
Publish content with metadata and/or on a particular topic.
— param: Publication that is the publication type of payload as specified in ISO/IEC 23000-16.
— return: Publication status.
b) Method: Subscribe.
Subscribe an interest for a particular content and/or on a particular topic.
— param: Subscription that is the subscription type of payload as specified in ISO/IEC 23000-16.
— return: Subscription status.
c) Method: Store.
Store content.
— param: Resource that is the resource type of payload as specified in ISO/IEC 23000-16.
— return: digital item identifier of resource.
d) Method: Play.
Play content.
— param: Resource that is the resource type of payload as specified in ISO/IEC 23000-16
— return: Nothing
7.2.2 Network services
These APIs are used to configure network service conditions, such as selection of network service
operator, service quality etc. Table 2 shows a list of Network services API.
Table 2 — Network service API
Service operation Input Response Description
GetNetworkTypeList() Available network Get a list of available network types.
types
SetNetworkType() Network type OK/Fail Choose network type from a list of available
ID network types.
GetServiceProviderList() Available service Get a list of available service providers.
provider IDs
Service provider codes are externally defined.
SetServiceProvider() Service pro- OK/Fail Choose network service operator from a list of
vider ID available service providers.
7.2.3 Energy management
This API enables to obtain energy related information and use of ene
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.