ISO 21806-2:2020

INTERNATIONAL ISO
STANDARD 21806-2
First edition
2020-09
Road vehicles — Media Oriented
Systems Transport (MOST) —
Part 2:
Application layer
Véhicules routiers — Système de transport axé sur les médias —
Partie 2: Couche d’application
Reference number
©
ISO 2020
© ISO 2020
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
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2020 – All rights reserved

Contents Page
Foreword .vi
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 3
4.1 Symbols . 3
4.2 Abbreviated terms . 3
5 Conventions . 4
6 APP — Application . 4
6.1 APP — Device model . 4
6.2 APP — Node kinds . 5
6.2.1 APP — MOST nodes . 5
6.2.2 APP — Remote-controlled nodes . 6
6.2.3 APP — Listen-only nodes . 6
6.3 APP — Function block . 6
6.3.1 APP — General . 6
6.3.2 APP — FBlock library . 7
6.3.3 APP — Controller and FBlock . 7
6.4 APP — Functions. 8
6.4.1 APP — Overview . 8
6.4.2 APP — Methods . 9
6.4.3 APP — Properties .11
6.5 APP — Events and notification .12
6.5.1 APP — Events .12
6.5.2 APP — Notification .12
6.6 APP — Notification mechanisms.13
6.6.1 APP — General .13
6.6.2 APP — Notification function.14
6.6.3 APP — Implicit notification .15
6.6.4 APP — Automatic notification .15
6.6.5 APP — Errors in the context of the notification function .15
6.6.6 APP — No valid values or property failure .15
6.6.7 APP — Reactions on Configuration.Status events .16
6.7 APP — Requesting FBlock information .16
6.7.1 APP — Function FBlockIDs .16
6.7.2 APP — Function FktIDs.17
6.7.3 APP — Extended FBlock identification .17
6.8 APP — Registry management .18
6.8.1 APP — General .18
6.8.2 APP — Central registry state .19
6.8.3 APP — NetworkMaster .22
6.8.4 APP — NetworkSlave .33
6.9 APP — Network wake-up, startup, and shutdown .40
6.9.1 APP — General .40
6.9.2 APP — Network wake-up and startup .41
6.9.3 APP — Network shutdown .41
6.9.4 APP — Device shutdown .43
6.10 APP — Connection management for streaming data .45
6.10.1 APP — Service for streaming data.45
6.10.2 APP — Source and sink information .46
6.10.3 APP — Streaming connections .48
6.10.4 APP — Compensating MOST network delay .54
6.11 APP — Diagnosis .54
6.11.1 APP — FBlock configuration status information .54
6.11.2 APP — Shutdown reason .56
6.11.3 APP — Shutdown reason analysis .56
6.11.4 APP — Ring break diagnosis .57
6.11.5 APP — Network diagnosis .57
6.12 APP — Error handling .58
6.12.1 APP — General .58
6.12.2 APP — Handling overload in a message receiver .58
6.12.3 APP — Over-temperature management .59
6.13 APP — Timing definitions .62
6.13.1 APP — Definitions .62
6.13.2 APP — NetworkMaster communication .62
6.13.3 APP — PowerMaster communication .66
7 AL — Application layer .68
7.1 AL — Structure of MOST messages .68
7.2 AL — Addressing .68
7.2.1 AL — Overview .68
7.2.2 AL — 16-bit addressing .69
7.2.3 AL — 48-bit addressing (Ethernet MAC address) .70
7.3 AL — Function block identifier (FBlockID) .70
7.4 AL — Instance identifier (InstID) .73
7.4.1 AL — Distinction of FBlock instances .73
7.4.2 AL — Uniqueness of functional addresses .73
7.4.3 AL — Assigning InstID .73
7.4.4 AL — InstID of NetBlock FBlock.73
7.4.5 AL — InstID of NetworkMaster FBlock .73
7.4.6 AL — InstID of FBlock EnhancedTestability .73
7.4.7 AL — Wildcard values for InstID .74
7.5 AL — Function identifier (FktID) .75
7.6 AL — Operation type (OPType) .76
7.6.1 AL — Overview .76
7.6.2 AL — Set, Get and SetGet .77
7.6.3 AL — Increment and Decrement .77
7.6.4 AL — Status .78
7.6.5 AL — Start and StartAck .78
7.6.6 AL — StartResult and StartResultAck .78
7.6.7 AL — Result and ResultAck .79
7.6.8 AL — Processing and ProcessingAck .79
7.6.9 AL — Abort and AbortAck .80
7.6.10 AL — Error and ErrorAck .80
7.6.11 AL — Parameters .86
7.7 AL — Timing definitions .87
7.7.1 AL — Definitions .87
7.7.2 AL — General communication .87
8 PL — Presentation layer .90
8.1 PL — Data and basic data types .90
8.1.1 PL — General .90
8.1.2 PL — Boolean .91
8.1.3 PL — Enum .91
8.1.4 PL — Numeric data types .92
8.1.5 PL — Length-coded String .97
8.1.6 PL — Array Type .98
8.1.7 PL — Record Type .99
8.1.8 PL — Stream .100
8.1.9 PL — BitField .103
iv © ISO 2020 – All rights reserved

8.1.10 PL — String .104
8.1.11 PL — Short Stream .106
8.1.12 PL — Classified Stream .106
8.2 PL — Function classes .107
8.2.1 PL — Purpose .107
8.2.2 PL — Properties with a single parameter .107
8.2.3 PL — Properties with multiple parameters .110
8.2.4 PL — Function classes for methods .134
9 Service interface definition to transport layer and network layer .135
Bibliography .136
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
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 ISO documents 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 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 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.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31,
Data communication.
A list of all parts in the ISO 21806 series can be found on the ISO website.
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.
vi © ISO 2020 – All rights reserved

Introduction
The Media Oriented Systems Transport (MOST) communication technology was initially developed at
the end of the 1990s in order to support complex audio applications in cars. The MOST Cooperation was
founded in 1998 with the goal to develop and enable the technology for the automotive industry. Today,
1)
MOST enables the transport of high quality of service (QoS) audio and video together with packet data
and real-time control to support modern automotive multimedia and similar applications. MOST is a
function-oriented communication technology to network a variety of multimedia devices comprising
one or more MOST nodes.
Figure 1 shows a MOST network example.
Figure 1 — MOST network example
The MOST communication technology provides:
— synchronous and isochronous streaming,
— small overhead for administrative communication control,
— a functional and hierarchical system model,
— API standardization through a function block (FBlock) framework,
— free partitioning of functionality to real devices,
— service discovery and notification, and
[7]
— flexibly scalable automotive-ready Ethernet communication according to ISO/IEC/IEEE 8802-3 .
MOST is a synchronous time-division-multiplexing (TDM) network that transports different data types
on separate channels at low latency. MOST supports different bit rates and physical layers. The network
clock is provided with a continuous data signal.
1)  MOST® is the registered trademark of Microchip Technology Inc. This information is given for the convenience
of users of this document and does not constitute an endorsement by ISO.
Within the synchronous base data signal, the content of multiple streaming connections and control
data is transported. For streaming data connections, bandwidth is reserved to avoid interruptions,
collisions, or delays in the transport of the data stream.
MOST specifies mechanisms for sending anisochronous, packet-based data in addition to control data
and streaming data. The transmission of packet-based data is separated from the transmission of
control data and streaming data. None of them interfere with each other.
A MOST network consists of devices that are connected to one common control channel and packet
channel.
In summary, MOST is a network that has mechanisms to transport the various signals and data streams
that occur in multimedia and infotainment systems.
The ISO standards maintenance portal (https:// standards .iso .org/ iso/ ) provides references to MOST
specifications implemented in today's road vehicles because easy access via hyperlinks to these
specifications is necessary. It references documents that are normative or informative for the MOST
versions 4V0, 3V1, 3V0, and 2V5.
The ISO 21806 series has been established in order to specify requirements and recommendations
for implementing the MOST communication technology into multimedia devices and to provide
conformance test plans for implementing related test tools and test procedures.
To achieve this, the ISO 21806 series is based on the open systems interconnection (OSI) basic reference
[3] [5]
model in accordance with ISO/IEC 7498-1 and ISO/IEC 10731 , which structures communication
systems into seven layers as shown in Figure 2. Stream transmission applications use a direct stream
data interface (transparent) to the data link layer.
viii © ISO 2020 – All rights reserved

Figure 2 — The ISO 21806 series reference according to the OSI model
The International Organization for Standardization (ISO) draws attention to the fact that it is claimed
that compliance with this document may involve the use of a patent.
ISO takes no position concerning the evidence, validity and scope of this patent right.
The holder of this patent right has assured ISO that he/she is willing to negotiate licences under
reasonable and non-discriminatory terms and conditions with applicants throughout the world. In
this respect, the statement of the holder of this patent right is registered with ISO. Information may be
obtained from the patent database available at www .iso .org/ patents.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights other than those in the patent database. ISO shall not be held responsible for identifying
any or all such patent rights.
INTERNATIONAL STANDARD ISO 21806-2:2020(E)
Road vehicles — Media Oriented Systems Transport
(MOST) —
Part 2:
Application layer
1 Scope
This document specifies a part of the application, the application layer, and the presentation layer.
The application covers the
— device model,
— registry management,
— connection management for streaming data,
— diagnosis, and
— error handling.
The application layer covers the structure of MOST messages consisting of
— addressing,
— function block identifiers,
— instance identifiers,
— function identifiers,
— operation types, and
— timing definitions.
The presentation layer covers the definition of data, basic data types and function classes.
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 21806-1, Road vehicles — Media Oriented Systems Transport (MOST) — Part 1: General information
and definitions
IEEE 754-2008, IEEE Standard for Floating-Point Arithmetic
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 21806-1 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
3.1
administrative FBlock
FBlock (3.10) that has an administrative purpose, which is specific to the MOST network
3.2
central registry
lookup table in the NetworkMaster (3.13) FBlock (3.10) for cross-referencing logical node addresses and
functional addresses
3.3
central registry state
indicator for the availability of the central registry (3.2)
3.4
connection manager
entity that manages streaming connections
3.5
ConnectionMaster
FBlock (3.10) that provides the interface to the connection manager (3.4)
3.6
controller
client that uses the services of an FBlock (3.10) instance
3.7
decentral registry
lookup table in a NetworkSlave (3.14) for determining available FBlocks (3.10) and cross-referencing
logical node addresses and functional addresses
3.8
FBlock scan
process of collecting information from the NetworkSlaves (3.14), performed by the NetworkMaster (3.13)
3.9
function
access to a feature of a service in an FBlock (3.10)
3.10
function block
FBlock
group of functions (3.9) that are particular to a specific application
3.11
method
function (3.9) that can be started and which leads to a result after a certain period of time
3.12
MOST message
message sent with functional address (FBlockID, InstID) as part of the payload
3.13
NetworkMaster
node that controls the central registry state (3.3) and administrates the central registry (3.2)
2 © ISO 2020 – All rights reserved

3.14
NetworkSlave
node that reports its FBlocks (3.10) to the NetworkMaster (3.13)
3.15
notification
mechanism for informing controllers (3.6) about changes in a property (3.19)
3.16
notification matrix
table that contains the logical node addresses of controllers (3.6) that require status updates when a
property (3.19) changes
3.17
PowerMaster
node that controls MOST network startup and shutdown
3.18
PowerSlave
node that provides functions (3.9) for MOST network startup and shutdown
3.19
property
function (3.9) for reading or writing a value or status within an FBlock (3.10)
4 Symbols and abbreviated terms
4.1 Symbols
--- empty cell/undefined
4.2 Abbreviated terms
AL application layer
APP application
CDC compact disc changer
CRC cyclic redundancy check
DAB digital audio broadcasting
DiagID diagnosis identifier
DSP digital signal processor
DTCP digital transmission content protection
DVD digital video disc
ECL electrical control line
ESDR ETSI satellite digital radio
ETSI European Telecommunications Standards Institute
FBlock function block
FBlockID function block identifier
FktID function identifier
GSM global system for mobile communications
HDCP high-bandwidth digital content protection
HMI human machine interface
InstID instance identifier
JIS Japanese Industrial Standard
LSb least significant bit
MNC MOST network controller
MOST Media Oriented System Transport
MSb most significant bit
NCE network change event
OPType operation type
QoS Quality of Service
PL presentation layer
RCC remote control communication
RDS radio data system
ROM read-only memory
SMS short message service
TMC traffic message channel
TPEG Transport Protocol Experts Group
TV television
UTF Unicode transformation format
5 Conventions
[4]
This document is based on OSI service conventions as specified in ISO/IEC 10731 .
6 APP — Application
6.1 APP — Device model
The following subclauses describe the logical model of a MOST device. A MOST device is a physical unit
that can be connected to a MOST network via a MOST network controller (MNC).
A MOST device contains at least one MOST node, remote-controlled node, or listen-only node. A MOST
device implements at least one MNC and MOST transceiver. A device that does not contain a MOST node
or a remote-controlled node is beyond the scope of this document.
4 © ISO 2020 – All rights reserved

Between the FBlocks and the MNC, the MOST network service forms an intermediate layer providing
routines to simplify the handling of the MNC. A MOST port is the MNC’s connection point to the MOST
transceiver.
Figure 3 shows a model of a MOST device with one MOST node and one MOST transceiver. In this
example, the MOST node contains two application FBlocks, X and Y, and a controller for FBlock Z.
Application FBlocks are used to group functions that are particular to a specific application, for example
radio or telephone. Administrative FBlocks group functions that have an administrative purpose, for
example NetworkMaster or NetBlock.
Key
1 multiple instances are possible
2 MOST network
Figure 3 — Example of a MOST device
6.2 APP — Node kinds
6.2.1 APP — MOST nodes
The requirements in this subclause refer to distinctive characteristics of MOST nodes.
REQ 8.1 APP – MOST nodes – Structure
A MOST node shall implement the MOST network service and the MNC.

REQ 8.2 APP – MOST nodes – Implement NetBlock
A MOST node shall implement the FBlock NetBlock.
REQ 8.3 APP – MOST nodes – Implement EnhancedTestability
A MOST node shall implement the FBlock EnhancedTestability.

REQ 8.4 APP – MOST nodes – One TimingMaster in the network
In a MOST network, there shall be exactly one designated TimingMaster.

REQ 8.5 APP – MOST nodes – TimingMaster in MOST node
The designated TimingMaster shall reside in a MOST node.
6.2.2 APP — Remote-controlled nodes
For certain use cases that do not require FBlock communication outside the administrative range
(FBlockID 00 to 0F ), a node kind exists which is called remote-controlled node.
16 16
REQ 8.6 APP – Remote-controlled nodes – Structure
A remote-controlled node shall implement the MNC and the FBlock NetBlock.
REQ 8.7 APP – Remote-controlled nodes – No EnhancedTestability
A remote-controlled node shall not implement the FBlock EnhancedTestability.
NOTE  Because the FBlock EnhancedTestability is not implemented a remote-controlled node is treated
differently during conformance testing.
REQ 8.8 APP – Remote-controlled nodes – FBlocks in administrative range
A remote-controlled node shall not implement any FBlock outside the administrative range.
REQ 8.9 APP – Remote-controlled nodes – Messages in administrative range
A remote-controlled node shall not send MOST messages to any FBlock outside the administrative range.
6.2.3 APP — Listen-only nodes
For network analysis purposes, a certain node kind can be configured to operate in listen-only mode.
Listen-only nodes do not change the content of network frames.
REQ 8.10 APP – Listen-only nodes – Behaviour
A listen-only node shall behave like a MOST node with its bypass closed.
NOTE  Listen-only nodes are typically not part of MOST networks; they are only included during system
design and for failure diagnosis.
6.3 APP — Function block
6.3.1 APP — General
On the application level, a MOST device contains multiple function blocks (FBlocks), for example, tuner,
amplifier, or CD player.
Each FBlock contains a number of single functions. For example, a CD player possesses functions such
as play, stop, eject, and time played.
6 © ISO 2020 – All rights reserved

6.3.2 APP — FBlock library
The MOST function catalogue (see ISO 21806-1) contains a set of standard FBlocks, which build the
MOST FBlock library. The FBlock library can be used by network owners as a foundation for modelling
the architecture of their MOST components and systems. Based on the FBlock library, a network owner
creates the specific MOST function catalogue, which contains the set of FBlocks that is used by the
network owner.
6.3.3 APP — Controller and FBlock
Application related communication over the MOST network occurs between a controller and an FBlock.
Controllers and FBlocks provide interfaces to applications. The controller sends commands to the
FBlock. The FBlock executes these commands and returns reports. The controller processes the reports.
A node which contains controllers can also contain FBlocks and, therefore, be controlled by other nodes.
An FBlock may be associated with more than one controller.
A controller interacts with one FBlock instance. Within a node, only one controller exists for one FBlock
instance.
Figure 4 illustrates application interaction on the controller and FBlock side, as well as MOST message
transport.
Figure 4 — Application, controller, and FBlock interaction example
6.4 APP — Functions
6.4.1 APP — Overview
A function is a specified attribute of an FBlock. Functions, as shown in Figure 5, are subdivided into two
categories:
— Functions that are started and do not lead to a result immediately. These functions are called
methods.
— Functions for determining or changing the status of a node, which refer to the current properties of
a node. These functions are called properties.
Figure 5 — Structure of an FBlock consisting of functions classifiable as methods and
properties
To communicate with a function, a controller needs information about the available parameters, their
limits, and the allowed operations.
On the application level, a function is addressed independently of the node it is implemented in.
Functions are grouped into FBlocks.
Different FBlocks and functions of a node are distinguished by their identifiers:
FBlockID.InstID.FktID
— The FBlockID identifies the FBlock according to Table 20 in 7.3.
— The InstID identifies the instance of an FBlock so that multiple instances of the same FBlock
type can be addressed uniquely. One example is the NetBlock FBlock (FBlockID 01 ), which is
implemented by every MOST node.
— The FktID identifies the function.
Functions provide operations. The type of operation is specified by the OPType. The parameters of the
operation follow the OPType, resulting in this structure:
FBlockID.InstID.FktID.OPType(Parameter1, Parameter2,…)
REQ 8.11 and 8.12 specify naming conventions for functions.
REQ 8.11 APP – Functions – Name without leading number
Function names shall not start with a number.

REQ 8.12 APP – Functions – Permissible name characters
Function names shall contain no characters other than letters, numbers, and underscores.
8 © ISO 2020 – All rights reserved

6.4.2 APP — Methods
6.4.2.1 APP — Execution of methods
In general, a method is started and does not immediately lead to a result. An example is the auto-
scanning of a tuner.
In the device model, to each method there is an associated process which is executed when an FBlock
receives a corresponding command for this method.
Methods can be specified without parameters. For example, a method to perform auto-scanning is
designed without parameters or with a parameter that specifies the direction of the auto-scan.
Execution of a method fails, for example, if the addressed FBlock has no method of that kind, if a wrong
parameter is found, or if the current status of the FBlock prevents execution. Methods may be designed
to not be reentrant, that is, subsequent attempts to start a method are rejected as long as the method is
processing the initial request.
REQ 8.13 APP – Methods – Reaction on execution failure
If execution of a method is not possible, the FBlock shall send the respective error message to the initiating
controller.
When finishing a process that is running due to StartResult or StartResultAck, the FBlock reports
execution to the controller. This report may contain results of the process, for example, a frequency
found by the tuner.
If a process runs for a long time, it may return intermediate results before finishing, such as informing
the controller about the successful start of the process.
The controller may abort execution of a method with the OPType Abort or AbortAck.
For methods, Table 1 in the column "Controller" shows the OPTypes that are used by the controller and
in the column "FBlock" the OPTypes that are used by the FBlock.
Table 1 — OPTypes for methods
Controller FBlock
Start execution of a method (Start, StartAck, Error with cause for error (Error, ErrorAck)
StartResult, StartResultAck)
Execution report with results (Result, ResultAck)
Abort a method (Abort, AbortAck)
Intermediate result (Processing, ProcessingAck)
6.4.2.2 APP — Using methods with SenderHandle
As several tasks within a node may access one method at the same time, a mechanism is provided to
route the answer back to the respective task. This mechanism relies on the SenderHandle parameter.
REQ 8.14 APP – Methods – SenderHandle data type
The SenderHandle parameter shall be of data type Unsigned Word.
NOTE 1  On the FBlock side, the SenderHandle in combination with the source address (of the originator) and
FBlockID.InstID is used to identify a method under execution. On the controller side, the SenderHandle is
used to dispatch the responses of the FBlock.
REQ 8.15 APP – Methods – SenderHandle value
A controller shall choose a unique value for SenderHandle.
REQ 8.16 APP – Methods – SenderHandle relevance
The SenderHandle shall not contain information beyond what is necessary to identify the corresponding
method.
NOTE 2  The SenderHandle is present when one of the OPTypes StartResultAck, AbortAck, StartAck,
ErrorAck, ProcessingAck, and ResultAck is used, see 7.6.
EXAMPLE 1
Controller → FBlock: FBlockID.InstID.StartResultAck(SenderHandle, Data)
FBlock → Controller: FBlockID.InstID.ResultAck(SenderHandle, Data)
FBlock → Controller: FBlockID.InstID.ErrorAck(SenderHandle, ErrorCode, ErrorInfo)
EXAMPLE 2
One example for the use of SenderHandles is the SMS service in a GSM module of a telephone device: In the HMI,
three tasks are attempting to send SMS text messages independent of each other via the function SMSSend. The
message of task 1
...