ISO/TS 18234-2:2013

TECHNICAL ISO/TS
SPECIFICATION 18234-2
Second edition
2013-10-15
Corrected version
2013-11-01
Intelligent transport systems — Traffic
and travel information via transport
protocol experts group, generation 1
(TPEG1) binary data format —
Part 2:
Syntax, semantics and framing structure
(TPEG1-SSF)
Systèmes intelligents de transport — Informations sur le trafic et le
tourisme via les données de format binaire du groupe d'experts du
protocole de transport, génération 1 (TPEG1)
Partie 2: Structure de syntaxe, de sémantique et de cadrage
(TPEG1-SSF)
Reference number
©
ISO 2013
©  ISO 2013
All rights reserved. Unless otherwise specified, 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
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2013 – All rights reserved

Contents Page
Foreword . v
Introduction . v
1  Scope . 1
2  Normative references . 1
3  Abbreviated terms . 2
4  Design principles . 3
4.1  TPEG transmission . 3
4.2  TPEG layer model . 4
5  Conventions and symbols . 6
5.1  Conventions . 6
5.1.1  Byte ordering . 6
5.1.2  Method of describing the byte-oriented protocol . 6
5.1.3  Reserved data fields . 6
5.2  Symbols . 6
5.2.1  Literal numbers . 6
5.2.2  Variable numbers . 6
5.2.3  Implicit numbers . 7
6  Representation of syntax . 7
6.1  General . 7
6.2  Data type notation . 7
6.2.1  Rules for data type definition representation . 7
6.2.2  Description of data type definition syntax . 9
6.3  Application dependent data types . 10
6.3.1  Data structures . 11
6.3.2  Using templates as interfaces . 12
6.3.3  Components . 13
6.4  Toolkits and external definition . 15
6.5  Application design principles . 15
6.5.1  Variable data structures . 15
6.5.2  Re-usable and extendable structures . 15
6.5.3  Validity of declarative structures . 15
7  TPEG data stream description . 16
7.1  Diagrammatic hierarchy representation of frame structure . 16
7.2  Syntactical Representation of the TPEG Stream . 16
7.2.1  TPEG transport frame structure . 16
7.2.2  TPEG service frame template structure . 17
7.2.3  Service frame of frame type = 0 . 17
7.2.4  Service frame of frame type = 1 . 17
7.2.5  TPEG service component frame multiplex . 18
7.2.6  Interface to application specific frames . 18
7.3  Description of data on Transport level . 21
7.3.1  Syncword . 21
7.3.2  Field length . 21
7.3.3  Header CRC . 21
7.3.4  Frame type . 21
7.3.5  Synchronization method. 22
7.3.6  Error detection . 22
7.4  Description of data on Service level . 22
7.4.1  Encryption indicator .22
7.4.2  Service identification .22
7.5  Description of data on Service component level .23
7.5.1  Service component identifier .23
7.5.2  Field length .23
7.5.3  Service component frame header CRC .23
7.5.4  Service component frame data CRC.23
Annex A (normative) Character tables .24
A.1  Character tables .24
A.2  Reference character table index .24
Annex B (normative) Method for coding quantities of objects .25
B.1  Numag derivation .25
B.2  Numag table .26
Annex C (normative) CRC calculation .27
C.1  CRC calculation .27
C.2  ITU-T (formerly CCITT) CRC calculation in PASCAL .27
C.3  ITU-T (formerly CCITT) CRC calculation in C notation .28
Annex D (normative) Time calculation .29
D.1  Time calculation .29
D.2  Time calculation in C notation .29
Annex E (informative) A description of the TPEG byte-stream using C-type notation .32
E.1  Explanation .32
E.2  Definition of data elements .32
E.3  Definition of conditional expressions.33
E.4  Byte-stream representation of the TPEG hierarchy .33
E.4.1  Definition of nextbyte function .33
E.4.2  Definition of next_start_code function .33
E.4.3  Definition of tpeg_stream function .34

iv © ISO 2013 – All rights reserved

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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of normative document:
— an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
— an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting
a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
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.
ISO/TS 18234-2 was prepared by the European Committee for Standardization (CEN) Technical Committee
CEN/TC 278, Road transport and traffic telematics, in collaboration with ISO Technical Committee
ISO/TC 204, Intelligent transport systems, in accordance with the Agreement on technical cooperation
between ISO and CEN (Vienna Agreement).
This second edition cancels and replaces the first edition (ISO/TS 18234-2:2006). Clauses 5, 6 and 7 have
been technically revised.
ISO/TS 18234 consists of the following parts, under the general title Intelligent transport systems — Traffic
and travel information via transport protocol experts group, generation 1 (TPEG1) binary data format:
 Part 1: Introduction, numbering and versions (TPEG1-INV)
 Part 2: Syntax, semantics and framing structure (TPEG1-SSF)
 Part 3: Service and network information(TPEG1-SNI)
 Part 4: Road Traffic Message application (TPEG1-RTM)
 Part 5: Public Transport Information (PTI) application
 Part 6: Location referencing applications
 Part 7: Parking information (TPEG1-PK1)
 Part 8: Congestion and travel-time application (TPEG1-CTT)
 Part 9: Traffic event compact (TPEG1-TEC)
 Part 10: Conditional access information (TPEG1-CAI)
 Part 11: Location Referencing Container (TPEG1-LRC)
This corrected version of ISO 18234-2:2013 incorporates the following corrections:
 The quality of Figures 4 and 5 has been improved for legibility.
vi © ISO 2013 – All rights reserved

Introduction
TPEG technology uses a byte-oriented data stream format, which may be carried on almost any digital bearer
with an appropriate adaptation layer. TPEG messages are delivered from service providers to end-users, and
are used to transfer application data from the database of a service provider to a user’s equipment.
This Technical Specification describes the Service and Network Information Application, which provides a
means of informing end-users about all possible services and their content which are considered relevant by a
service provider to either provide continuity of his services or inform the end-user about other related services.
As stated in the design criteria, TPEG is a bearer independent system. Therefore some rules are established
for the relation of information contents of the same service on different bearers. Also the mechanisms for
following a certain service on one single bearer have to be defined. For the receiver it is essential to find an
adjacent or similar service if it leaves the current reception area. Nonetheless, basic information describing the
service itself is necessary. For the ease of the user, e.g. the service name, the service provider name, the
operating time and many other hints are delivered by the TPEG-SNI application.
General models for the hand-over and the referencing of services are developed and shown in detail. It is
important to note that this Technical Specification is closely related to ISO/TS 18234-3 and thus they are
dependent upon each other and must be used together.
The brief history of TPEG technology development dates back to the European Broadcasting Union (EBU)
Broadcast Management Committee establishing the B/TPEG project group in autumn 1997 with the mandate
to develop, as soon as possible, a new protocol for broadcasting traffic and travel-related information in the
multimedia environment. TPEG technology, its applications and service features are designed to enable
travel-related messages to be coded, decoded, filtered and understood by humans (visually and/or audibly in
the user’s language) and by agent systems.
One year later in December 1998, the B/TPEG group produced its first EBU specifications. Two Technical
Specifications were released. ISO/TS 18234-2, this document, described the Syntax, Semantics and Framing
Structure, which is used for all TPEG applications. ISO/TS 18234-4 (TPEG-RTM) described the first
application, for Road Traffic Messages.
Subsequently, CEN/TC 278/WG 4, in conjunction with ISO/TC 204, established a project group comprising the
members of B/TPEG and they have continued the work concurrently since March 1999. Since then two further
parts were developed to make the initial complete set of four parts, enabling the implementation of a
consistent service. ISO/TS 18234-3 (TPEG-SNI) describes the Service and Network Information Application,
which should be used by all service implementations to ensure appropriate referencing from one service
source to another. ISO/TS 18234-1 (TPEG-INV), completes the series, by describing the other parts and their
relationship; it also contains the application IDs used within the other parts.
In April 2000, the B/TPEG group released revised Parts 1 to 4, all four parts having been reviewed and
updated in the light of initial implementation results. Thus a consistent suite of specifications, ready for wide
scale implementation, was submitted to the CEN/ISO commenting process.
In November 2001, after extensive response to the comments received and from many internally suggested
improvements, all four parts were completed for the next stage: the Parallel Formal Vote in CEN and ISO. But
a major step forward has been to develop the so-called TPEG-Loc location referencing method, which
enables both map-based TPEG-decoders and non map-based ones to deliver either map-based location
referencing or human readable information. ISO/TS 18234-6 is now a separate specification and is used in
association with the other parts of ISO/TS 18234 to provide comprehensive location referencing. Additionally,
ISO/TS 18234-5, has been developed and been through the commenting process.
This Technical Specification provides a full specification to the primitives used, framing, time calculation,
numbers and to specific rules such as CRC calculation.
During the development of the TPEG technology a number of versions have been documented and various
trials implemented using various versions of the specifications. At the time of the publication of this Technical
Specification, all parts are fully inter-workable and no specific dependencies exist.
This Technical Specification has the technical version number TPEG-SSF_3.0/003.

viii © ISO 2013 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 18234-2:2013(E)

Intelligent transport systems — Traffic and travel information
via transport protocol experts group, generation 1 (TPEG1)
binary data format —
Part 2:
Syntax, semantics and framing structure (TPEG1-SSF)
1 Scope
This Technical Specification establishes the method of referencing used within a TPEG data-stream to allow a
service provider to signal availability of the same service on another bearer channel or similar service data
from another service.
TPEG is a byte-oriented stream format, which may be carried on almost any digital bearer with an appropriate
adaptation layer. TPEG messages are delivered from service providers to end-users, and are used to transfer
application data from the database of a service provider to a user’s equipment.
The protocol is structured in a layered manner and employs a general purpose framing system which is
adaptable and extensible, and which carries frames of variable length. This has been designed with the
capability of explicit frame length identification at nearly all levels, giving greater flexibility and integrity, and
permitting the modification of the protocol and the addition of new features without disturbing the operation of
earlier client decoder models.
2 Normative references
The following referenced documents are indispensable for the application 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 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The
Basic Model
ISO/IEC 8859-1, Information technology — 8-bit single-byte coded graphic character sets — Part 1: Latin
alphabet No. 1
ISO/IEC 8859-2, Information technology — 8-bit single-byte coded graphic character sets — Part 2: Latin
alphabet No. 2
ISO/IEC 8859-3, Information technology — 8-bit single-byte coded graphic character sets — Part 3: Latin
alphabet No. 3
ISO/IEC 8859-4, Information technology — 8-bit single-byte coded graphic character sets — Part 4: Latin
alphabet No. 4
ISO/IEC 8859-5, Information technology — 8-bit single-byte coded graphic character sets — Part 5:
Latin/Cyrillic alphabet
ISO/IEC 8859-6, Information technology — 8-bit single-byte coded graphic character sets — Part 6:
Latin/Arabic alphabet
ISO/IEC 8859-7, Information technology — 8-bit single-byte coded graphic character sets — Part 7:
Latin/Greek alphabet
ISO/IEC 8859-8, Information technology —8-bit single-byte coded graphic character sets — Part 8:
Latin/Hebrew alphabet
ISO/IEC 8859-9, Information technology — 8-bit single-byte coded graphic character sets — Part 9: Latin
alphabet No. 5
ISO/IEC 8859-10, Information technology — 8-bit single-byte coded graphic character sets — Part 10: Latin
alphabet No. 6
ISO/IEC 8859-13, Information technology — 8-bit single-byte coded graphic character sets — Part 13: Latin
alphabet No. 7
ISO/IEC 8859-14, Information technology — 8-bit single-byte coded graphic character sets — Part 14: Latin
alphabet No. 8 (Celtic)
ISO/IEC 8859-15, Information technology — 8-bit single-byte coded graphic character sets — Part 15: Latin
alphabet No. 9
ISO/IEC 10646, Information technology — Universal Coded Character Set (UCS)
3 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply:
AID  Application Identification
BPN Broadcast, Production and Networks (an EBU document publishing number system)
B/TPEG Broadcast/TPEG (the EBU project group name for the specification drafting group)
CEN Comité Européen de Normalisation
DAB Digital Audio Broadcasting
DARC Data Radio Channel - an FM sub-carrier system for data transmission
DVB Digital Video Broadcasting
EBU European Broadcasting Union
INV  Introduction, Numbering and Versions (see ISO/TS 18234-1)
IPR  Intellectual Property Right(s)
ISO  International Organization for Standardization
ITU-T International Telecommunication Union - Telecom
OSI  Open Systems Interconnection
RTM Road Traffic Message application (see ISO/TS 18234-4)
2 © ISO 2013 – All rights reserved

SNI  Service and Network Information application (see ISO/TS 18234-3)
SSF  Syntax, Semantics and Framing Structure (this Technical Specification)
TPEG Transport Protocol Expert Group
TTI  Traffic and Travel Information
UAV unassigned value
UTC Coordinated Universal Time
4 Design principles
The following principles have been assumed in the development of the TPEG protocol, structure and
semantics:
 TPEG is unidirectional;
 TPEG is byte-oriented, where a byte is represented by eight bits;
 TPEG provides a protocol structure, which employs asynchronous framing;
 TPEG includes a CRC error detection capability applicable on a variety of different levels;
 TPEG assumes the use of a transparent data channel;
 TPEG assumes that underlying systems will have an appropriate level of reliability;
 TPEG assumes that underlying systems may employ error correction;
 TPEG has a hierarchical data frame structure;
 TPEG is used to transport information from database to database;
 TPEG provides service provider name, service name and network information;
 TPEG permits the use of encryption mechanisms, if required by an application.
4.1 TPEG transmission
TPEG is intended to operate via almost any simple digital data channel, and it assumes nothing of the channel
other than the ability to convey a stream of bytes. To this end, the concept of transmission via a “piece of wire”
is envisaged, in which the bearer has no additional service features.
In Figure 1, a variety of possible transmission channels are shown. The only requirement of the channel is that
a sequence of bytes may be carried between the TPEG generator and the TPEG decoder. This requirement is
described as “transparency”. However it is recognized that data channels may introduce errors. Bytes may be
omitted from a sequence, bytes may become corrupted or additional and erroneous data could be received.
Therefore TPEG incorporates error detection features at appropriate points and levels. It is assumed that
bearer systems will introduce an appropriate level of error correction.
Figure 1 — TPEG data may be delivered simultaneously via different bearer channels
4.2 TPEG layer model
In Figure 2, the different layers of the TPEG protocol are identified in accordance with the ISO/OSI model
(ISO/IEC 7498-1).
4 © ISO 2013 – All rights reserved

Figure 2 — TPEG in relation to the ISO/OSI Layer Model via different bearer channels
Layer 7 is the top level and referred to in TPEG as the application layer. Initially the following applications
were defined:
 TPEG specifications - Part 3: Service and Network Information Application (Service provider name, logo,
hand-over information, etc.) (CEN ISO/TS 18234-3);
 TPEG specifications - Part 4: Road Traffic Message application (Event description, location description,
etc.) (CEN ISO/TS 18234-4).
Layer 4 is the packetization layer. Components are merged into a single stream and encrypted and/or
compressed.
Layer 3 is the network layer. This layer defines the means for synchronization and routing. This is the lowest
layer of the TPEG protocol.
Layer 2 is the datalink layer. This layer consists of a wide range of different bearers, which are suitable
carriers for the TPEG protocol. An adaptation layer may be required in order to map the TPEG stream onto
that bearer.
Layer 1 is the physical layer. This defines the transmission medium (radio waves, wire, optical, etc.). One
particular bearer can make use of different physical layers.
5 Conventions and symbols
5.1 Conventions
5.1.1 Byte ordering
All numeric values using more than one byte are coded in “Big Endian” format (most significant byte first).
Where a byte is subdivided into bits, the most significant bit (“b7”) is at the left-hand end and the least
significant bit (“b0”) is at the right-hand end of the structure.
5.1.2 Method of describing the byte-oriented protocol
TPEG uses a data-type representation for the many structures that are integrated to form the transmission
protocol. This textual representation is designed to be unambiguous, easy to understand and to modify, and
does not require a detailed knowledge of programming languages.
Data types are built up progressively. Primitive elements, which may be expressed as a series of bytes are
built into compound elements. More and more complex structures are built up with compound elements and
primitives. Some primitives, compounds and structures are specified in this Technical Specification, and apply
to all TPEG Applications. Other primitives, compounds and structures are defined within applications and are
local only to that application.
A resultant byte-stream coded using C-type notation is shown in CEN ISO/TS 18234-2:2006, Annex E.
5.1.3 Reserved data fields
If any part of a TPEG data structure is not completely defined, then it should be assumed to be available for
future use. The notation is UAV (unassigned value). This unassigned value should be encoded by the service
provider as the value 00 hex. This allows newer decoders using a future TPEG Standard to ignore this data
when receiving a service from a provider encoding to this older level of specification. A decoder which is not
aware of the use of any former UAVs can still make use of the remaining data fields of the corresponding
information entity. However, the decoder will not be able to process the newly defined additional information.
5.2 Symbols
5.2.1 Literal numbers
Whenever literal numbers are quoted in TPEG Standards, the following applies:
123 = 123 decimal
123 hex = 123 hexadecimal
5.2.2 Variable numbers
Symbols are used to represent numbers whose values are not predefined within the TPEG Standards. In
these cases, the symbol used is always local to the data type definition. For example, within the definition of a
data type, symbols such as “n” or “m” are often used to represent the number of bytes of data within the
structure, and the symbol “id” is used to designate the occurrence of the identifier of the data type.
6 © ISO 2013 – All rights reserved

5.2.3 Implicit numbers
Within the definition of a data structure it is frequently necessary to describe the inclusion of a component
which is repeated any number of times, zero or more. In many of these cases it is convenient to use a
numerical symbol to show the component structure being repeated a number of times, but the number itself is
not explicitly included within the definition of the data structure. Often, the symbol “m” is used for this purpose.
6 Representation of syntax
6.1 General
This clause introduces the terminology and the syntax that is used to define TPEG data elements and
structures.
6.2 Data type notation
6.2.1 Rules for data type definition representation
The following general rules are used for defining data types:
 a data type is written in upper camel case letters in one single expression. The data type may contain
letters (a-z), number (0-9), underscore "_", round brackets "()" and colon ":"; the first must be a letter;
EXAMPLE 1 IntUnLo stands for Integer Unsigned Long
 a data type is framed by angle brackets “ < > ” ;
 the content of a data type is defined by a colon followed by an equal sign “ := ”;
 the end of a data type is indicated by a semicolon “ ; ”;
 a descriptor written in lower camel case may be added to a data type as one single expression without spaces;
 a descriptor is framed by round brackets “ ( ) ”;
 the descriptor contains either a value or a name of the associated type;
 data types in a definition list of another one are separated by commas “ , ”. The order of definition is defined as the
order of occurrence in a data stream;
 curly brackets (braces) “ { } ” group together a block of data types;
 control statements ( “if”, “infinite”, “unordered” or “external”) are noted in lower case letters. A control statement is
followed by a block statement or only one data type:
1) “if” defines a condition statement. The block’s (or data type’s) occurrence is conditional to the condition
statement being valid. The condition statement is framed with round brackets. This statement applies to any
data type;
2) “infinite” defines endless repetition of the block (or data type). This is only used to mark the main TPEG stream
as not ending stream of data;
Camel case is the description given to the use of compound words wherein each individual word is signalled by a
capital letter inside the compound word. Upper camel case means that the compound word begins with an upper-case
(capital) letter, and lower camel case means the compound word begins with a small letter.
3) “unordered” defines that the following block contains data types which may occur in any order, not only the one
used to specify subsequent data types. This statement applies to components only. (See Clause A2.3.3 -
Components);
4) “external” defines that the content of the data type is being defined external to the scope of given specification.
The control statement “external” must be followed by only one data. A reference to the corresponding
specification should follow in the comment. All types specified in TYP specification are treated as being in scope
of any application
EXAMPLE 2
:= : externally defined component
external ; : id = 1, See Annex B (Message Management
Container)
 the expression “ n * ” indicates multiplicity of occurrence of a data type . The lower and upper bound are
implicitly from 0 to infinite; other bounds are described in square brackets between two points " . " and
behind the data type descriptor. The " * " stands for no limitation at upper bound
EXAMPLE 3
m * (Attribute) [1.*] , : The “Attribute” must occur once at least and up
to infinite.
 a function “ f ( ) ” that is calculated over a data type is indicated by italic lower case letters. The comment
n
behind the definition of the function shall explain which function is used;
 any text after a colon “ : ” is regarded as a comment;
 a data type definition can be a template (i.e. not fully defined declarative structure) having a parameter
inside of round brackets "(x)" at the end of the data type name. Templates define structures, whose
structural definition is included as a basis for other data type definitions. To declare the given template
(making it identifiable) the name of the parameter is repeated as a descriptor in a nested data type of the
subsequent definition list. Templates allow for reading the generalised part of different instances i.e. to
specify data type interfaces. (See Clause A2.3.2 - Using templates as interfaces for further description)
EXAMPLE 4
:= : x defines the template parameter
(x); : descriptor x defines position of setting the
parameter in the list
 a data type can inherit a template by concatenating the data type name of the template including the
square brackets to its own name. The data type itself can again be a template having the "(x)" at its end
of name, or it instantiates the inherited template by defining the value of the parameter in the brackets. In
the latter case the brackets shall contain the decimal number of the identifier and the value shall be set in
the subsequent definition list. The structural definition of the inherited template is repeated as the first part
of the definition list before new data types are specified. (See Clause A2.3.2 - Using templates as
interfaces for further description)
8 © ISO 2013 – All rights reserved

EXAMPLE 5
>:= : second template inherits first
st
(x), : repeated definition from 1 template
(n); : additional structural definition

>:= : instantiation of the second template
(1), : definition of parameter in the stream
(n), : structural definition from template
(value); : some more definition

 in the definition list a specific instance of a template (i.e. declarative structure) is described without the
brackets. Any inherited data type of this template may occur at that position in the data stream
EXAMPLE 6
:=
(anyAnotherTemplate); : Data stream contains e.g.

The following additional guidelines help to improve the readability of data type definitions:
 data type names are written in bold;
 nested data type definitions are defined from top to bottom (i.e. higher levels first, then lower levels);
 a box is drawn around a data type definition;
 for clear graphical presentation, lines in a coding box if they are too long to fit, are broken with a
backslash “\” followed by a carriage return. The broken line restarts with an additional backslash
EXAMPLE 7
:=
: First line
\NameMayBeInSeveralLines>, : Second line
,
;
6.2.2 Description of data type definition syntax
A data type is an interpretation of one or more bytes. Each data type has a structure, which may describe the
data type as a composition of other defined data types. The data type structure shows the composition and
the position of each data element. TPEG defines data structures in the following manner:
:= : Description of data type
(descriptorA), : Description of data A
(descriptorB); : Description of data B

This shows an example data structure, which has just two parts, one of type and the other of
. A descriptor may be assigned to the data type, to relate the element to another part of the
definition. Comments about the data structure are included at the right-hand side delimited by the colon “:”
separator. Each of the constituent data types may be itself composed of other data types, which are defined
separately. Eventually each data type is expressible as one or more bytes.
Where a data structure is repeated a number of times, this may be shown as follows:
:= : Description of data type
, : Description of data A
m * [0.*]; : Description of data B

Often, in such cases it is necessary to explicitly deliver to the decoder the number of times a data type is
repeated; sometimes it is not, because other means like framing or internal length coding allows knowledge of
the end of the list of the repeated data type. In other cases the overall length of a data structure in bytes
needs to be specified. Additionally the constraint on occurrences can be added, which tells how many
instances of the data type must be expected by the decoder. The “*” as upper bound means in this case that
at this place no restriction is given to the upper bound; in other words, infinite elements may follow.
Where the number of repetitions must be signalled, it may be accomplished using another data element as
follows:
:= : Description of data type
(n), : An integer representing the value of "n"
n * [0.255], : Description of data A
; : Description of data B

In the above example a decoder has to have the value of “n” in order to correctly determine the n’th position of
the in the list. Here as consequence of data type IntUnTi not more as 255 instances of the data
type can be coded.
In the following example the decoder uses the value of “n” to determine the overall length of the data
structure, and the value of “m” determines that is repeated m times:
:= : Description of data type
(n), : Length, n, of data structure in bytes
m * ; : Description of data A

This data type definition is used to describe a variable structure switched by the value of x:
:= : Description of data type
(x), : Select parameter, x
if (x=1) then , : Included if x equals 1
if (x=2) then , : Included if x equals 2

6.3 Application dependent data types
This clause describes the methodology and syntax by which application data types may be constructed within
TPEG Applications. Two basic forms are described: data structures (being non-declarative) and components
(being declarative). Components contain an identifier which labels the structure, and which can be used by a
decoder to determine the definition of content of the structure. As such, components are used where options
are required, or where an application needs to build in ‘future proofing’. Data structures do not contain such
information, and are used in all other positions.
10 © ISO 2013 – All rights reserved

This Annex does not specify the structures, which are actually used in TPEG Applications. Such specifications
are made in the respective parts of the Standard. However examples are given to show how such structures
may be built from the primitive elements already described above.
6.3.1 Data structures
Data structures are built up from several (i.e. more than one) elements: primitive, compound or other
structures (both non-declarative and declarative). As such, any application specific data type definition having
no component identifier is per definition a data structure. The term data structure is specifically used for data
type definitions having more than one sub element defined.
Examples of data structure might be:
EXAMPLE 1
:= : Activity
, : Beginning
, : End
; : Text
EXAMPLE 2
:= : Sound sample
(n),
: Length of sam
...