ETSI TS 103 544-6 V1.3.1 (2019-10)

Publicly Available Specification (PAS); Intelligent Transport Systems (ITS); MirrorLink®; Part 6: Service Binary Protocol (SBP)

RTS/ITS-98-6

General Information

• Status: Published
• Publication Date: 08-Oct-2019
• Technical Committee: ITS - Intelligent Transport Systems
• Current Stage: 12 - Completion
• Due Date: 30-Sep-2019
• Completion Date: 09-Oct-2019

Standards Content (Sample)

TECHNICAL SPECIFICATION
Publicly Available Specification (PAS);
Intelligent Transport Systems (ITS); ®
MirrorLink ;
Part 6: Service Binary Protocol (SBP)
CAUTION
The present document has been submitted to ETSI as a PAS produced by CCC and
approved by the ETSI Technical Committee Intelligent Transport Systems (ITS).
CCC is owner of the copyright of the document CCC-TS-018 and/or had all relevant rights and had assigned said rights to
ETSI on an "as is basis". Consequently, to the fullest extent permitted by law, ETSI disclaims all warranties whether express,
implied, statutory or otherwise including but not limited to merchantability, non-infringement of any intellectual property rights of
third parties. No warranty is given about the accuracy and the completeness of the content of the present document.

2 ETSI TS 103 544-6 V1.3.1 (2019-10)

Reference
RTS/ITS-98-6
Keywords
interface, ITS, PAS, smartphone

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
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 at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
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 2019.
© Car Connectivity Consortium 2011-2019.
All rights reserved.
ETSI logo is a Trade Mark of ETSI registered for the benefit of its Members.
MirrorLink® is a registered trademark of Car Connectivity Consortium LLC.
RFB® and VNC® are registered trademarks of RealVNC Ltd.
UPnP® is a registered trademark of Open Connectivity Foundation, Inc.
Other names or abbreviations used in the present document may be trademarks of their respective owners.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ 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.
ETSI
3 ETSI TS 103 544-6 V1.3.1 (2019-10)
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 MirrorLink Data Service Architecture . 7
4.1 Overall Architecture . 7
4.2 Version convention. 8
4.3 Starting Data Service . 9
4.4 Data Service Security with Device Attestation Protocol . 9
5 Service Framework: Service BINARY Protocol (SBP) . 9
5.1 Introduction . 9
5.2 Service Description Example . 10
5.3 Data representation . 11
5.4 Command representation . 13
5.5 Command Sequences . 15
5.5.1 General . 15
5.5.2 Get, [{Response-Continue}], Response . 15
5.5.3 Set, [{Response-Continue}], Response . 17
5.5.4 Subscribe, {Response-OK/NOK}, [{Response}] . 19
5.5.5 Cancel, Response . 21
5.5.6 AuthenticationChallenge, AuthenticationResponse . 23
5.5.7 AliveRequest, AliveResponse. 23
5.6 Hash as UID . 23
5.7 Error handling . 24
5.7.1 General . 24
5.7.2 Irrecoverable error . 24
5.7.2.1 Introduction . 24
5.7.2.2 Unknown data type . 24
5.7.2.3 Wrong END: END check failure for form 4, 5 or command . 24
5.7.3 Recoverable error . 25
5.7.3.1 Introduction . 25
5.7.3.2 Unknown Object UID . 25
5.7.3.3 Unknown command type . 25
5.7.3.4 Unsupported feature . 25
5.7.4 Error to ignore . 25
5.7.4.1 General . 25
5.7.4.2 Unknown UID for member variable . 25
5.7.5 Error code definition . 25
5.8 Authentication mechanism . 26
5.9 Support of optional Objects . 27
5.10 Version listing and selection . 27
5.11 Initialization Sequence . 27
5.12 Other topics . 28
5.12.1 Extending a service . 28
5.12.2 Payload fragmentation . 28
5.12.3 Inheritance . 28
5.12.4 Shutdown clean-up and reconnection . 28
ETSI
4 ETSI TS 103 544-6 V1.3.1 (2019-10)
Annex A (informative): BINARY Representation (data_With_UID) Example. 29
Annex B (informative): Data Service Grammar (EBNF) . 32
B.1 Introduction . 32
B.2 Basic Definitions . 32
B.3 Numbers, Words, Names, and Text . 33
B.4 Properties & Comments . 33
B.5 Data Element Type . 34
B.6 Data Element Instance . 34
B.7 Structure Element . 34
B.8 Object Element . 35
B.9 Enumeration Definition . 35
B.10 Service Definition . 35
Annex C (informative): Authors and Contributors . 37
History . 38

ETSI
5 ETSI TS 103 544-6 V1.3.1 (2019-10)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is 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 Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, 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.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Intelligent Transport Systems
(ITS).
The present document is part 6 of a multi-part deliverable. Full details of the entire series can be found in part 1 [i.1].
Modal verbs terminology
In the present document "shall", "shall not", "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 TS 103 544-6 V1.3.1 (2019-10)
1 Scope ®
The present document is part of the MirrorLink specification which specifies an interface for enabling remote user
interaction of a mobile device via another device. The present document is written having a vehicle head-unit to interact
with the mobile device in mind, but it will similarly apply for other devices, which provide a colour display, audio
input/output and user input mechanisms.
The Service Binary Protocol (SBP) is a simple, low-bandwidth data service framework, enabling a CDB data service
provider and subscriber to utilize common functions like reading, writing or subscribing to objects of a data service.
2 References
2.1 Normative 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.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
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 are necessary for the application of the present document.
[1] Void.
[2] ETSI TS 103 544-5 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 5: Common Data Bus (CDB)".
[3] ETSI TS 103 544-9 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 9: UPnP Application Server Service".
[4] ETSI TS 103 544-4 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 4: Device Attestation Protocol (DAP)".
[5] ETSI TS 103 544-15 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 15: Application Programming Interface (API) Level 1 & 2".
TM
[6] IEEE Std 754-2019 : IEEE Standard for Binary Floating-Point Arithmetic, 22 July 2019.
NOTE: Available at https://standards.ieee.org/standard/754-2019.html.
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 are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TS 103 544-1 (V1.3.1): "Publicly Available Specification (PAS); Intelligent Transport
Systems (ITS); MirrorLink®; Part 1: Connectivity".
ETSI
7 ETSI TS 103 544-6 V1.3.1 (2019-10)
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:
API Application Programming Interface
BOM Byte Order Mark
CDB Common Data Bus
EBNF Extended Backus-Naur Form
INT INTeger
IP Internet Protocol
LSB Least Significant Bit
MSB Most Significant Bit
SBP Service Binary Protocol
TCP Transmission Control Protocol
UID Unique IDentifier
UPnP Universal Plug-and-Play
USB Universal Serial Bus
UTC Coordinated Universal Time
WLAN Wireless Local Area Network
XML eXtensible Markup Language ®
4 MirrorLink Data Service Architecture
4.1 Overall Architecture
MirrorLink Data service is composed of CDB, service framework and service provider/subscriber. CDB is the
underlying multiplexing layer which also provides service discovery feature. On top of it, service framework layer
allows implementing a new service in easier way by providing common abstraction for service provider/subscriber.
ETSI
8 ETSI TS 103 544-6 V1.3.1 (2019-10)
MirrorLink Server MirrorLink Client
Data
Data Data Data Data Data Data Data
Source  Sink
Sink Source Sink Source Sink Source
Service
Service
Framework Framework
CDB CDB
Connectivity Connectivity
Figure 1: Top level architecture of MirrorLink data service
Figure 1 shows the top level architecture of MirrorLink data service. Underlying connectivity can be a TCP/IP session
on top of physical connectivity like USB, WLAN, and Bluetooth. Besides TCP/IP, it will be also possible to run
MirrorLink data service on top of other protocol like Bluetooth RFCOMM, but how to discover and establish
connection for such configuration is outside the scope of the present document.
On top of the connectivity layer, the CDB layer is located. CDB relies on the connectivity layer to provide TCP like
connection oriented session, and all other layers above rely on the CDB to provide communication interface.
Above the CDB can be the service framework layer or data source (service provider)/data sink (service subscriber) layer
depending on the data service used. Service framework layer implements common features for individual data services
to allow creating a new service easier. Some data service may decide not to use the service framework to re-use existing
protocols or to reduce the additional overhead caused by the framework. It is highly recommended for any new data
service to consider using the service framework first. If that approach does not work, accessing directly to CDB layer
can be considered. Some data service may open its own TCP/IP session, but such use case is outside the scope of the
present document.
On top of data service framework can be service provider (data source) or service subscriber (data sink). Each data
source can support up to one data sink: Zero data sink means the service is not used. As there can be only one data sink
for each data source, it is up to each side of MirrorLink connection (MirrorLink Server and MirrorLink Client) to make
sure that the service can be shared across multiple applications if necessary. Depending on the implementation, there
can be one system component which can work as a data sink and can provide received data to all interested applications.
Another implementation may allow only one application to get the data. How such access control is implemented is
outside the scope of the present document, but it is recommended to allow multiple applications to access the data
unless that data is meaningful only for selected applications.
4.2 Version convention
CDB and service framework layers are bound under the same version number provided from CDB. In other words, the
service framework layer does not have separate version number. CDB version number will be updated when there is an
update in CDB or service framework layer. This present document, goes together with the CDB version 1.1
specification, defined in [2].
All version numbers in MirrorLink data service are composed of major version number and minor version number. A
change in the major version number means incompatibility with the previous major version. A change in the minor
version guarantees compatibility with the previous minor version. This policy should be maintained across all the layers
of MirrorLink data service.
ETSI
9 ETSI TS 103 544-6 V1.3.1 (2019-10)
4.3 Starting Data Service
MirrorLink data service requires CDB as underlying layer. And to use data service, CDB should be launched by via
UPnP application launch mechanism [3]. Note that there is no separate application for data service, and launching CDB
is enough. More details on discovering CDB services can be found from clause 5.3 of CDB specification [2]. Note that
MirrorLink Client needs to launch the CDB with right version number.
Once CDB is started, all available services can be discovered by using CDB ServicesRequest and ServicesSupported
messages. Then service client, either from MirrorLink Client or Server side, can ask service server to start the service
via CDB StartService message. For details, check the CDB specification.
4.4 Data Service Security with Device Attestation Protocol
CDB can support payload encryption by using a pre-arranged session key. In the current MirrorLink architecture, the
session key can be acquired after attestation of CDB in MirrorLink Server side by utilizing Device Attestation Protocol
[4]. The application public key generated from the attestation of CDB is the session key used for encrypting CDB
payload in MirrorLink Client side. MirrorLink Server will use matching private key to decrypt CDB payload. Note that
this key can be generated per each MirrorLink connection, and MirrorLink Client shall not re-use the key from the
previous connections.
Future versions of the Common Data Bus may provide, additional mechanisms to exchange session keys for encrypting
both directions, e.g. symmetric keys.
5 Service Framework: Service BINARY Protocol (SBP)
5.1 Introduction
As a basic data representation mechanism in the service framework layer, we have preferred binary version compared to
XML mainly for performance reason. Due to that, a new binary protocol for service framework, SBP (Service Binary
Protocol) was defined. Even if the service framework is based on binary protocol, it is important to allow easy service
definition and future extendibility. To allow future extension, the concept of identifying each member variable by
unique ID is used.
Big-endian is used for all data types. The protocol does not guarantee data alignment for compact data representation,
and in most cases, data should be re-constructed from byte stream. Due to that, there is no big advantage of having
little-endian instead of big-endian.
SBP assumes lossless data delivery through CDB layer. Due to that, there is no separate data integrity check, but still
there can be mal-formed SBP payloads due to implementation error. Such error will be checked inside SBP.
Due to the time constraint for MirrorLink 1.1 specification, decision was made to focus on basic features in this version
of specification. Following features will be addressed in this version:
• Getting and setting data.
• Subscribing to a data.
Following features will be added in later revisions:
• Remote Procedure Call feature.
• Details about authentication. Command is defined, but specific details will be added later.
• Meta-data description.
• Interface Description Language: In this draft, style similar to C++ is used for convenience, but it is not
formally defined.
ETSI
10 ETSI TS 103 544-6 V1.3.1 (2019-10)
5.2 Service Description Example
Service description can be done by defining data objects including member variables. Mechanism for subscribing the
data objects will be explained later. Let's assume an example service with the name of
"com.mirrorlink.sensor_example". The name is used to uniquely identify the service in CDB layer.
Figure 2 shows data objects defined in the service.
/* com.mirrorlink.sensor_example, version 1.0 */
/** @UID: 0xD6804B4A @max_subscription_rate: 50Hz */
Object accelerometer {
STRUCTURE accel_data {
FLOAT x;  /// @unit: m/s^2 @mandatory @UID: 0x150A2CB3
FLOAT y;  /// @unit: m/s^2 @mandatory @UID: 0x150A2CB4
TIME time; /// @mandatory @UID: 0x00A0FDB2
};
STRUCTURE_ARRAY data; /// @UID: 0x144A776F
};
/** @UID: 0xD73DFF88 @writable @control: accelerometer */
Object accelerometer_control {
BOOLEAN filterEnabled; /// @UID: 0x2B230C64 @optional: false
INT samplingRate;   /// @UID: 5F2BF0EC
};
/** @UID: 0x41F75401 @max_subscription_rate: 1Hz
Object thermometer {
INT temperature; /// @UID: 0x9D28234F @unit: Celsius
};
Figure 2: Example Service Description
A service can be composed of one or more Objects. The example service is composed of three Objects: accelerometer,
accelerometer_control and thermometer. Javadoc style is used to document each object. Each object can be individually
accessed by using Get, Set or Subscribe command. Details of these commands will be presented in later clauses.
The accelerometer object has one member variable: data. The "data" is an array of STRUCTURE accel_data which has
three members: acceleration in x direction, acceleration in y direction, and time. Note that
STRUCTURE_ARRAY means an array of STRUCTURE XYZ. Similarly, ARRAY represents an array
of basic type (non-STRUCTURE, non-ARRAY) XYZ. The example subscription also shows that the accelerometer
object allows the maximum subscription rate of 50 Hz with maximum sampling rate of 100Hz. Due to the difference in
rates, one data notification can include multiple samples. Note that /** */ and /// is used for comments and additional
information as in Javadoc. All objects allow reading data, but writing is allowed selectively. The accelerometer_control
object allow writing as @writable tag shows. Member variables can be either mandatory or optional. Member variables
are mandatory by default, and optional member can be specified with @optional tag which can also include the
specification of default value when the member variable is not present. For example, in the accelerometer_control
object, filterEnabled is optional with default value of false.
Note that accelerometer_control object can be used to control the behaviour of accelerometer object.
An Object can inherit other Objects or STRUCTUREs. Then all member variables defined in parents
Objects/STRUCTURREs are available in the child Object. A STRUCTURE can also inherit other Objects or
STRUCTUREs to re-use the already defined data layout. An example, an Object "A" inheriting a STRUCTURE "a" can
be expressed as "Object A inherits STRUCTURE a {};".
ETSI
11 ETSI TS 103 544-6 V1.3.1 (2019-10)
5.3 Data representation
Data in SBP is represented as in Table 1 using Extended Backus-Naur Form (EBNF).
Table 1: Binary representation of data in EBNF
EBNF Form Matching data_type
No
data = data_type, value | 1 BOOLEAN, BYTE,
SHORT, INT, LONG,
FLOAT, DOUBLE
data_type, no_elements, {value} | 2 BYTES, STRING
data_type, element_data_type, no_elements, {value} | 3 ARRAY
data_type, no_elements, { data_with_UID }, END | 4 STRUCTURE
data_type, no_elements, {data}, END; 5 STRUCTURE_ARRAY
data_with_UID = UID, data; - -

Each data within a STRUCTURE_ARRAY shall have the same STRUCTURE type, and thus only data with form 4 can
be placed.
Table 2 describes symbols used in EBNF description of data.
Table 2: Description of symbols
Category Size Description
data_type U8 Tell the type of data.
UID U32 Unique identifier of data. Hash value of
data's name is used as UID.
value 8, 16, 32, Raw data without any addition. Size
64 bits depends on the data_type.
no_elements U32 Number of elements contained in the array,
array of structure, or structure.
data_type of elements contained in the
element_data_type U8
array. This data_type can be only
BOOLEAN, SHORT, INT, LONG, FLOAT, or
DOUBLE. Putting other data_type shall be
treated as irrecoverable error.
END U8 Special character (0x81) used for
terminating STRUCTURE or
STRUCTURE_ARRAY for checking data
integrity.
data_with_UID - UID, data pair binding UID with data.

Table 3 shows all the data types with matching EBNF description to represent the data.
Table 3: List of data_type
Name data_type Form Description
BOOLEAN 0x82 1 U8, true (non-zero) or false (0).
BYTE 0x83 1 8-bit, signed integer.
SHORT 0x84 1 16-bit, signed integer.
INT 0x85 1 32-bit signed integer.
ETSI
12 ETSI TS 103 544-6 V1.3.1 (2019-10)
Name data_type Form Description
LONG 0x86 1 64-bit signed integer.
FLOAT 0x87 1 32-bit value, single-precision [6].
DOUBLE 0x88 1 64-bit value, double-precision [6].
BYTES 0x90 2 Array of BYTE
STRING 0x91 2 Array of UTF16BE characters. Each character takes at
least 2 bytes.
A Byte Order Mark (BOM) shall not be included.
A termination character is not needed. If included, it shall
be counted within the no_elements.
ARRAY 0xA0 3 Array of basic data types (BOOLEAN, SHORT, INT,
LONG, FLOAT, and DOUBLE)
STRUCTURE 0xA1 4 Generic container for heterogeneous data as in structure in
C language. Note that STRUCTURE can nest another
STRUCTURE inside, but creating too many depths can
increase processing over-head.
STRUCTURE0xA2 5 Array for the STRUCTURE of the same type. Note that this
_ARRAY data type is not necessarily efficient in the amount of data
point of view as the same meta-data is repeated for all
child elements. If reducing the amount of data is important,
other data type should be considered.

Form column shows how each data_type can be represented in binary format. For example, ARRAY has form 3, which
corresponds to Form No 3 in Table 1.
Besides what is listed above, in service description, pseudo data_type of TIME can be used. TIME is a 64-bit signed
integer (LONG) with the meaning of time in milliseconds since 1970-01-01-00:00 in UTC or relative time in
milliseconds depending on how it is defined in each service. Note that TIME is only used in service description level,
and in SBP protocol level, TIME is always delivered as LONG.
Usage of data_type not defined in Table 3 shall be treated as irrecoverable error.
The sequence for the placement of child elements shall follow the service description. In the example service
description of Figure 2, STRUCTURE accel_data has three data members: x, y, and time. When this STRUCTURE is
transmitted under SBP, the order of data shall be x, y, and time as defined in the description. Table 4 shows how it will
be in binary representation.
Table 4: Example for the sequence of member variables in binary representation
STRUCTURE accel_data {
High-level
FLOAT x; /// @unit: m/s^2 @mandatory @UID: 0x150A2CB3
FLOAT y; /// @unit: m/s^2 @mandatory @UID: 0x150A2CB4
TIME time; /// @mandatory @UID: 0x00A0FDB2
};
STRUCTURE accel_data data; /** @UID: 0x144A776F */
UID: "data", data_type: 0xA1(STRUCTURE), no_elements: 3,
Binary
UID: "x", data_type: 0x87(FLOAT), value: 0, UID: "y",
Description
data_type: 0x87(FLOAT), value: 0, UID: "time", data_type:
0x86(LONG), value: 0, END
0x144A776F, 0xA1, 0x00000003, 0x150A2CB3, 0x87,
Binary
0x00000000, 0x150A2CB4, 0x87, 0x00000000, 0x00A0FDB2,
(data_with_
0x86, 0x0000000000000000, 0x81
UID)
ETSI
13 ETSI TS 103 544-6 V1.3.1 (2019-10)
If some data members are OPTIONAL, it is allowed to skip that member. But in that case, each service description
should either define the default value or should provide a relevant mechanism for SBP Sink to know if some members
are present or not. The latter can be done by providing an additional member variable or an Object containing such
information.
5.4 Command representation
Compared to data representation, there is only one type of EBNF for command as shown in Table 5.
Table 5: Binary representation of command in EBNF
command = command_type, payload_length, UID, packet_id, value,
no_elements, {data_with_UID}, END_C;

Table 6 describes symbols used in EBNF of command.
Table 6: Description of symbols
Category Size Description
command_type U8 Tell the type of command.
payload_length U32 Total length of command including END_C - 5
(command_type + payload_length).
UID U32 Unique identifier of object. Hash value of object's name is
used as UID.
packet_id U16 Unique identifier for each packet. Value of "0" means do not
care.
value U32 Command specific value.
no_elements U32 Number of child data elements contained in this command.
data_with_UID - UID, data pair as defined in Table 1.
END_C U8 Special character (0xB0) used for terminating a command.

Table 7 shows summary of defined commands.
Table 7: List of commands
Name command_ UID value Description
type
Get 0xB1 Object 0 Reads an object once. Depending on the
object, this operation can take time.
Set 0xB2 Object 0 Write to the Object. Depending on the object,
this operation can take time.
Subscribe 0xB3 Object Subscription Get multiple notifications for the Object.
type and Object data is sent later depending on
interval (ms) subscription type and interval. Subscription
type takes MSB 8 bits, and subscription
interval takes remaining LSB 24 bits from
32bits "value".
Cancel 0xB4 Object command_ty Cancels the currently active command (Get,
pe Set, and Subscribe) with the given
command_type.
AliveRequest 0xB5 0 0 Request the SBP Source to send
AliveResponse.
AliveResponse 0xB6 0 0 Reply for AliveRequest.
ETSI
14 ETSI TS 103 544-6 V1.3.1 (2019-10)
Name command_ UID value Description
type
AuthenticationChal 0xB7 Object authenticatio Authentication challenge when an Object
lenge or n method which requires authentication is accessed.
Function Data passed are defined by each
UID authentication method. In this version, only
service specific authentication is allowed,
and service specific authentication shall use
the authentication method value of
0x80000000.
AuthenticationRes 0xB8 Object Error code Authentication response for the challenge.
ponse or For the current version of the specification,
Function AuthenticationResponse shall return Feature
UID not supported error code except for service
specific authentication.
Response 0xB9 Object/F Error code This is a response for Get, Subscribe,
unction Cancel, and AuthenticationResponse.
Reserved 0xBA to 0xBF - - This range is reserved for next update for
commands Call and other features. For the current
version of specification, SBP Source shall
return a Response with "Feature not
supported" error code when command in
these ranges is received.
Table 8 shows the defined subscription types.
Table 8: subscription_type in Subscribe command
Subscription type Description
0x0, regular interval Send update in regular interval with interval (ms) specified in 24bits
subscription interval. When the interval is smaller than what SBP Source
supports, SBP Source should return error.
0x1, on change Send update when there is a change. When there is too frequent
changes, SBP Source can decide to either drop some updates or
combine multiple updates into single one if data structure allows it.
0x2, automatic It is up to SBP Source to decide either to choose regular interval or on
change. SBP Source can choose the optimal notification mechanism for
the requested Object.
The SBP Source shall support Get, Set, Subscribe, Cancel, and AliveRequest commands. Except for the AliveRequest
command, when the current service does not support these commands for the given object, SBP Source shall return
Response with "Feature not supported" error code.
The SBP Sink shall support Response, and AuthenticationResponse commands.
Note that each command can access one Object as a whole. Each Object can include member variable with different
data types like STRUCTURE, but it cannot include another Object. STRUCTURE can also include member variable,
but unlike Object, STRUCTURE cannot be individually accessed by command. A STRUCTURE can be only accessed
as a member variable of an Object or Objects.
Note that SBP Sink and SBP Source shall recognize all the commands defined. If a specific command is not supported
by a specific Object, SBP Sink and SBP Source shall return proper error code like "Feature not supported" or "Write not
allowed". It is up to each service to decide if specific command is supported for the specific Object, but Get and Cancel
command shall be supported unless specified otherwise in the service specification.
ETSI
15 ETSI TS 103 544-6 V1.3.1 (2019-10)
5.5 Command Sequences
5.5.1 General
This clause shows how commands are related with each other by showing sequences and examples. Note that each
command sequence shall share the same packet_id. Any AuthenticationChallenge-AuthenticationResponse phase,
which is actually a sequence, following a Get/Set/Subscribe command, shall have the same packet_id as the first
command.
A Cancel command sequence for a pending Get/Set/Subscribe command shall have a different packet_id as the pending
command.
A command sequence with wrong packet_id shall be ignored by both SBP Sink and SBP Source.
All command sequences are initiated by the SBP Sink. Upon receiving the initial command, the SBP Source should
send reply within 5 seconds. If the SBP Source fails to send a reply within 5 seconds, the SBP Sink should treat that
request as an error, like notifying the upper layer with time-out error, and following responses from the SBP Source,
which arrive later, can be ignored. Depending on the command, some operation like Get and Set can take more time and
need not be completed within 5 seconds. In that case, SBP Source should send Response message with error code of
"continue" (Response-Continue from now on). Then SBP Source can spend more time. Note that the SBP Source can
send multiple of Response-Continue in some regular interval until the requested operation is completed. For example, if
a Set request for an object takes 11 seconds, SBP Source can send two Response-Continue at 4 seconds and 8 seconds
later. Then at 11 seconds, SBP Source will send the final reply. In this example, SBP Source is sending
Response-Continue earlier than the 5 seconds time-out as it can take time for the message to arrive to the SBP Sink.
SBP Sink should not send the same command to the same object until the currently active command sequence is
completed. SBP Source shall return "Command already pending" error code upon detecting such situation.
As all commands are processed in asynchronous way, SBP Source needs to guarantee that the certain number of
command sequences can be processed at a time. It is up to each service to define the maximum number of active
commands that shall be supported, and SBP Source should guarantee at least that number of active commands. In the
case when SBP Source cannot process a new command due to resource limitation, SBP Source shall return an error
code, "no more session". Note that cancelling existing active command should work always as it is not adding a new
active command.
Note that, in all the examples in this clause, original name is shown as UID, but actual data carried is hash value of the
name rather than the name itself.
5.5.2 Get, [{Response-Continue}], Response
Get is used to fetch an Object data once. For protected object, optionally, authentication can be requested in the middle.
When the authentication stage is included, service SBP Source will send AuthenticationChallenge message and SBP
Sink shall respond with AuthenticationResponse. After the OPTIONAL authentication, Response comes from SBP
Source. There can be multiple Response-Continue message in the middle if it takes time to get the requested data.
Table 9 shows example of the data exchange for the example service.
Table 9: Example of Get command sequences
1. SBP Sink: command_type: Get, payload_length, UID: "accelerometer",
packet_id: 1, 0, 0, END_C
2. SBP Source: command_type: Response, payload_length, UID:
"accelerometer", packet_id: 1, value 0 (OK), …, END_C

Get command can be sent without first subscribing the object. Note that the SBP Sink can send Get, Set, and Subscribe
commands without having dependency on any other commands. For example, SBP Sink can send Set command without
sending Subscribe or Get command beforehand.
ETSI
16 ETSI TS 103 544-6 V1.3.1 (2019-10)
For d
...