ISO 21219-5:2019

Intelligent transport systems - Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) - Part 5: Service framework (TPEG2-SFW)

This document establishes a method of conveying data for a wide range of applications that require the efficient transmission of point to multi-point data over potentially unreliable broadcast channels. It is also suitable for point-to-point and multicast applications and may easily be encapsulated in Internet Protocol. This document describes the basic capabilities of the generation 2 TPEG (TPEG2) for providing a multiplex of TPEG Services and applications. Together with the definitions of the general TPEG UML modelling rules and the particular physical TPEG representations for TPEG-binary streams (TISA: TPEG UML Conversion Rules) and tpegML files (TISA Specification: TPEG UML Conversion Rules), it replaces the former documents TPEG-INV and TPEG-SSF.

Systèmes intelligents de transport — Informations sur le trafic et le tourisme via le groupe expert du protocole de transport, génération 2 (TPEG2) — Partie 5: Cadre de service (TPEG2-SFW)

General Information

• Status: Published
• Publication Date: 23-Jul-2019
• ICS: 03.220.01 - Transport in general
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 10 - Traveller information systems
• Current Stage: 9093 - International Standard confirmed
• Start Date: 06-Jun-2025
• Completion Date: 13-Dec-2025

Relations

• Revises: ISO/TS 21219-5:2015 - Intelligent transport systems - Traffic and travel information (TTI) via transport protocol experts group, generation 2 (TPEG2) - Part 5: Service framework (TPEG2-SFW)
• Effective Date: 23-Apr-2020

Overview

ISO 21219-5:2019 - TPEG2 Service Framework (TPEG2‑SFW) specifies the service framework for Traffic and Travel Information delivered using the Transport Protocol Experts Group Generation 2 (TPEG2). The standard defines how a multiplex of TPEG Services and Service Components is structured and signalled so that traffic, travel and related data can be efficiently transmitted over potentially unreliable broadcast channels (and equally over point‑to‑point or multicast/IP transport). ISO 21219‑5:2019 replaces earlier TPEG1/TPEG documents (TPEG‑INV and TPEG‑SSF) and ties the UML modelling approach to the two physical representations: TPEG‑binary and tpegML.

Key topics and technical requirements

• Service multiplexing and structure
  • Definition of a TPEG Service (multiplex of Service Components) and TPEG Service Component (virtual channel for a specific TPEG application).
  • Rules for the TPEG Stream Directory to signal services present in a stream or file.
• Layered model
  • Description of Transport, Service, and Service Component levels and how they interact.
• Modelling and physical representations
  • UML‑based modelling rules for TPEG2 and conversion rules to:
    • TPEG‑binary (annex A - normative) and
    • tpegML (annex B - normative).
• Operational attributes and administration
  • Service Identification (SID) administration procedures (annex C - normative).
  • CRC calculation rules for integrity checking (annex D - normative).
• Design principles
  • Efficient point‑to‑multi‑point delivery over byte‑oriented channels; easy encapsulation in IP; backward compatibility considerations with TPEG1.
• Normative references and terminology
  • Terms/definitions for TPEG roles (Server, Client), frames, streams and structures; references to related TPEG parts.

Applications and who uses it

ISO 21219‑5:2019 is intended for organizations and professionals implementing traffic and travel information systems:

• Broadcast service operators (DAB/DVB) delivering TTI over broadcast channels.
• Traffic and travel data providers and aggregators designing multiplexed TPEG services.
• Navigation system and OEM suppliers integrating TPEG2 decoders and filter logic.
• Software developers producing TPEG‑aware servers, clients and middleware (binary and XML/tpegML tools).
• ITS integrators and public transport authorities using TPEG2 for dynamic content (real‑time incidents, parking, PTI) and static content. Practical use cases include broadcast traffic bulletins, multicast updates to fleet vehicles, encapsulation in IP for internet delivery, and hybrid broadcast/broadband TTI services.

Related standards

• ISO 21219 series (TPEG2 toolkit, transport and application parts), e.g. ISO 21219‑2/3/4 (UML and conversion rules), ISO 21219‑6 (message management), ISO/TS 21219‑7 (location referencing).
• Legacy reference: ISO/TS 18234‑3 (TPEG1 SNI).

Keywords: ISO 21219-5:2019, TPEG2, TPEG2‑SFW, Traffic and Travel Information, intelligent transport systems, tpegML, TPEG binary, service framework.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 21219-5
First edition
2019-07
Intelligent transport systems —
Traffic and travel information (TTI)
via transport protocol experts group,
generation 2 (TPEG2) —
Part 5:
Service framework (TPEG2-SFW)
Systèmes intelligents de transport — Informations sur le trafic et le
tourisme via le groupe expert du protocole de transport, génération 2
(TPEG2) —
Partie 5: Cadre de service (TPEG2-SFW)
Reference number
©
ISO 2019
© ISO 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Fax: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii © ISO 2019 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 General — TPEG . 3
5.1 TPEG transmission . 3
5.2 TPEG roles . 4
5.3 TPEG layer model . 4
5.4 Design principles . 6
6 Description of TPEG Multiplex and TPEG Structures . 6
6.1 Overview . 6
6.2 TPEG Transport level . 8
6.3 TPEG Service level . 8
6.3.1 General. 8
6.3.2 TPEG Service structure. 8
6.3.3 Service level attributes description . 8
6.4 TPEG Service Component level . 9
6.4.1 Service Component structure . 9
Annex A (normative) TPEG-Binary Representation of Framework Structures .11
Annex B (normative) tpegML Representation of Framework Structures .18
Annex C (normative) SID administrative procedures .39
Annex D (normative) CRC calculation .40
Bibliography .42
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 204, Intelligent transport systems.
This first edition cancels and replaces ISO/TS 21219-5:2015, which has been technically revised.
A list of all parts in the ISO 21219 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.
iv © ISO 2019 – All rights reserved

Introduction
History
TPEG technology was originally proposed by the European Broadcasting Union (EBU) Broadcast
Management Committee, who established the B/TPEG project group in the autumn of 1997 with a brief
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 were 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. Originally, a byte-oriented data stream
format, which may be carried on almost any digital bearer with an appropriate adaptation layer,
was developed. Hierarchically structured TPEG messages from service providers to end-users were
designed to transfer information from the service provider database to an end-user’s equipment.
One year later, in December 1998, the B/TPEG group produced its first EBU specifications. Two
documents were released. Part 2 (TPEG-SSF, which became ISO/TS 18234-2) described the syntax,
semantics and framing structure, which was used for all TPEG applications. Meanwhile, Part 4 (TPEG-
RTM, which became ISO/TS 18234-4) described the first application for road traffic messages.
Subsequently, in March 1999, CEN/TC 278, in conjunction with ISO/TC 204, established a group
comprising members of the former EBU B/TPEG and this working group continued development work.
Further parts were developed to make the initial set of four parts, enabling the implementation of a
consistent service. Part 3 (TPEG-SNI, ISO/TS 18234-3) described the service and network information
application used by all service implementations to ensure appropriate referencing from one service
source to another.
Part 1 (TPEG-INV, ISO/TS 18234-1) completed the series by describing the other parts and their
relationship; it also contained the application IDs used within the other parts. Additionally, Part 5, the
public transport information application (TPEG-PTI, ISO/TS 18234-5), was developed. The so-called
TPEG-LOC location referencing method, which enabled both map-based TPEG-decoders and non-map-
based ones to deliver either map-based location referencing or human readable text information,
was issued as ISO/TS 18234-6 to be used in association with the other applications of parts of the
ISO/TS 18234 series to provide location referencing.
The ISO/TS 18234 series has become known as TPEG Generation 1.
TPEG Generation 2
When the Traveller Information Services Association (TISA), derived from former forums, was
inaugurated in December 2007, TPEG development was taken over by TISA and continued in the TPEG
applications working group.
It was about this time that the (then) new Unified Modelling Language (UML) was seen as having major
advantages for the development of new TPEG applications in communities who would not necessarily
have binary physical format skills required to extend the original TPEG TS work. It was also realized
that the XML format for TPEG described within the ISO/TS 24530 series (now superseded) had a greater
significance than previously foreseen, especially in the content-generation segment and that keeping
two physical formats in synchronism, in different standards series, would be rather difficult.
As a result, TISA set about the development of a new TPEG structure that would be UML-based. This has
subsequently become known as TPEG Generation 2.
TPEG2 is embodied in the ISO/TS 21219 series and it comprises many parts that cover introduction,
rules, toolkit and application components. TPEG2 is built around UML modelling and has a core of
rules that contain the modelling strategy covered in ISO 21219-2, ISO 21219-3 and ISO 21219-4 and
the conversion to two current physical formats: binary and XML; others could be added in the future.
TISA uses an automated tool to convert from the agreed UML model XMI file directly into an MS Word
document file, to minimize drafting errors, that forms the annex for each physical format.
TPEG2 has a three-container conceptual structure: message management (ISO 21219-6), application
(several parts) and location referencing (ISO/TS 21219-7). This structure has flexible capability and
can accommodate many differing use cases that have been proposed within the TTI sector and wider
for hierarchical message content.
TPEG2 also has many location referencing options as required by the service provider community, any
of which may be delivered by vectoring data included in the location referencing container.
The following classification provides a helpful grouping of the different TPEG2 parts according to their
intended purpose. Note that the list below may be incomplete, e.g. new TPEG2 parts may be introduced
after publication of this document.
— Toolkit parts: TPEG2-INV (ISO/TS 21219-1), TPEG2-UML (ISO 21219-2), TPEG2-UBCR (ISO 21219-3),
TPEG2-UXCR (ISO 21219-4), TPEG2-SFW (ISO 21219-5), TPEG2-MMC (ISO 21219-6), TPEG2-LRC
(ISO/TS 21219-7).
— Special applications: TPEG2-SNI (ISO/TS 21219-9), TPEG2-CAI (ISO/TS 21219-10), TPEG2-LTE
(ISO/TS 21219-24).
— Location referencing: TPEG2-OLR (ISO/TS 21219-22), TPEG2-GLR (ISO/TS 21219-21), TPEG2-TLR
(ISO 17572-2), TPEG2-DLR (ISO 17572-3).
— Applications: TPEG2-PKI (ISO/TS 21219-14), TPEG2-TEC (ISO/TS 21219-15), TPEG2-FPI
(ISO/TS 21219-16), TPEG2-TFP (ISO 21219-18), TPEG2-WEA (ISO/TS 21219-19), TPEG2-RMR
(ISO/TS 21219-23), TPEG2-EMI (ISO/TS 21219-25), TPEG2-VLI (ISO/TS 21219-26).
TPEG2 has been developed to be broadly (but not totally) backward compatible with TPEG1 to assist
in transitions from earlier implementations, while not hindering the TPEG2 innovative approach and
being able to support many new features, such as dealing with applications having both long-term,
unchanging content and highly dynamic content, such as parking information.
vi © ISO 2019 – All rights reserved

INTERNATIONAL STANDARD ISO 21219-5:2019(E)
Intelligent transport systems — Traffic and travel
information (TTI) via transport protocol experts group,
generation 2 (TPEG2) —
Part 5:
Service framework (TPEG2-SFW)
1 Scope
This document establishes a method of conveying data for a wide range of applications that require the
efficient transmission of point to multi-point data over potentially unreliable broadcast channels. It is
also suitable for point-to-point and multicast applications and may easily be encapsulated in Internet
Protocol.
This document describes the basic capabilities of the generation 2 TPEG (TPEG2) for providing a
multiplex of TPEG Services and applications. Together with the definitions of the general TPEG UML
modelling rules and the particular physical TPEG representations for TPEG-binary streams (TISA:
TPEG UML Conversion Rules) and tpegML files (TISA Specification: TPEG UML Conversion Rules), it
replaces the former documents TPEG-INV and TPEG-SSF.
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/TS 18234-3, Intelligent transport systems — Traffic and travel information via transport protocol
experts group, generation 1 (TPEG1) binary data format — Part 3: Service and network information
(TPEG1-SNI)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
3.1
TPEG Application
application layer protocol fulfilling the general TPEG requirements at the highest layer of the ISO OSI
model and standardized by TISA/ISO
Note 1 to entry: A TPEG Application consists of a set of classes and rules for encoding information required for a
traffic information service.
3.2
TPEG Client
device or entity on the receiving side of the TPEG transmission chain
Note 1 to entry: See 5.2.
3.3
TPEG Server
device or entity on the sending side of the TPEG transmission chain
Note 1 to entry: See 5.2.
3.4
TPEG Service
multiplex of TPEG Service Components with a dedicated Service ID
Note 1 to entry: See 6.1.
3.5
TPEG Service Component
virtual channel for messages of a dedicated TPEG Application
Note 1 to entry: See 6.1.
3.6
Service Frame
data-structure implementing the TPEG Service in the TPEG binary representation
3.7
Service Component Frame
data-structure implementing the TPEG Service Component stream in the TPEG binary representation
3.8
TPEG Service Multiplex
multiplex of TPEG Services within one data stream or file
3.9
TPEG Stream Directory
TPEG Structure used for signalling the TPEG Services within a Service Multiplex
3.10
TPEG Structure
data structure used by TPEG on the particular protocol layers of the service transmission
4 Abbreviated terms
AID Application Identification
BPN Broadcast, Production and Networks (an EBU document publishing number system)
CEN Comité Européen de Normalisation
CRC Cyclic Redundancy Check
DAB Digital Audio Broadcasting
DVB Digital Video Broadcasting
EBU European Broadcasting Union
INV Introduction, Numbering and Versions (see EBU BPN 027-1)
IPR Intellectual Property Right(s)
ISO International Organization for Standardization
2 © ISO 2019 – All rights reserved

ITU-T International Telecommunication Union — Telecom
OSI Open Systems Interconnection
PTI Public Transport Information
RTM Road Traffic Message Application
SFW Service Framework (this Technical Specification)
SID Service Identification
SNI Service and Network Information Application (see EBU BPN 027-3)
SSF Syntax, Semantics and Framing Structure
TPEG Transport Protocol Experts Group
TTI Traffic and Travel Information
UTC Universal Coordinated Time
UML Unified Modelling Language
XML Extensible Markup Language
XSD XML Schema Definition
5 General — TPEG
5.1 TPEG transmission
TPEG is intended to operate via almost any simple digital data channel, where it is primarily targeted
at broadcast media using byte oriented transparent data channels. Other physical formats may pose
different constraints on a transmission layer. Thus, TPEG 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
5.2 TPEG roles
The following roles are defined for TPEG devices:
— TPEG Server — is the device, group of devices or entity that provides the capabilities to encode
TPEG objects, e.g. TPEG messages, TPEG Service Frames or TPEG Service Component Frames and
which transmits it via a suitable digital bearer to the TPEG Client side.
— TPEG Client — is the device or entity that provides the capabilities to decode TPEG objects received
from one or several TPEG Servers.
These terms are used in the rest of this document to designate these roles.
5.3 TPEG layer model
In Figure 2, the different layers of the TPEG protocol are identified in accordance with the ISO/OSI model.
4 © ISO 2019 – All rights reserved

Figure 2 — TPEG in relation to the ISO/OSI Layer Model
Layer 7 is the top level and referred to in TPEG as the application layer. The following TPEG Applications
are defined at the date of publication of this document:
— Service and Network Information (SNI) Application;
— Road Traffic Message (RTM) Application;
— Public Transport Information (PTI) Application;
— Location Referencing Container (LRC);
— Parking Information (PKI) Application;
— Traffic Event Compact (TEC) Application;
— Conditional Access Information (CAI) Application.
An up-to-date list of TPEG Applications can be found on the TISA webpage.
Layers 6 and 5 are the presentation and session layers. TPEG Service Components are merged into a
single stream and encrypted and/or compressed.
Layers 3 and 4 are the transport and network layers. These layers define the means for synchronisation
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 for that TPEG may also define requirements to the 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.4 Design principles
The following general principles have been assumed in the development of the TPEG protocol, structure
and semantics:
— TPEG is platform independent and bearer independent;
— TPEG is designed for but not restricted to unidirectional transmission;
— TPEG provides a protocol structure, which employs asynchronous framing;
— TPEG assumes that underlying systems may employ error correction;
— TPEG has a hierarchical data frame structure enabling a multiplex of TPEG Services and TPEG
Applications within one data stream;
— TPEG provides worldwide unique identification of TPEG Services;
— TPEG permits the use of encryption mechanisms, if required by an application;
— TPEG Applications can be extended in a backwards compatible way;
— TPEG Applications are modelled using UML. Specific physical transmission formats are derived
from these models.
6 Description of TPEG Multiplex and TPEG Structures
6.1 Overview
TPEG provides multiplexing functionality on several TPEG levels (see also Figure 3 below):
— TPEG Service Components and TPEG Applications: A TPEG Service Component is used to provide
a virtual channel for streams of messages of one and only one TPEG Application type. Accordingly,
the content of a TPEG Service Component is encoded following the definitions of the corresponding
TPEG Application.
— TPEG Service Component Multiplex and TPEG Services: A TPEG Service consists of one or several
TPEG Service Components, thus combining several application specific message streams. Each TPEG
Service has a worldwide unique Service Identification (SID).
— TPEG Service Multiplex: One or several TPEG Service streams can be multiplexed to one bearer-
related data-stream. Each of the TPEG Service data objects within this data stream can be
unambiguously assigned to a TPEG Service by its unique SID. The Service multiplex enables the
realization of several TPEG Services within one data stream.
Figure 3 — TPEG multiplex hierarchy
6 © ISO 2019 – All rights reserved

The multiplex hierarchy described above requires corresponding data structures (TPEG Structures) for
the particular protocol layers, i.e.:
— a TPEG Service Component structure for the messages multiplex on Service Component or TPEG
Application layer;
— a TPEG Service structure for the Service Component Multiplex on the TPEG Service layer;
— TPEG Transport structures for the multiplex of several TPEG Services within a physical data stream,
in particular for the bearer abstraction and the signalling of TPEG Services.
An overview of the structures is given in Figure 4. The hierarchy includes data structures for TPEG
Service Components, TPEG Services and TPEG Transport, where the latter ensures the abstraction from
the particular transmission bearer. A further structure is the TPEG Stream Directory, which may be
used to signal the TPEG Services transmitted in a TPEG Service Multiplex.
Figure 4 — Transport hierarchy of TPEG Stream Directory and Service Frame Structures
Further transport structures may be defined in the future, e.g. for TPEG multiplex information.
The TPEG Structures shown in the figures above are described on an abstract level in the following
clauses. These UML definitions shall not be used for automatic generation of physical format
descriptions as defined in TISA Specification: TPEG UML Modelling Rules, TISA: TPEG UML Conversion
Rules and TISA Specification: TPEG UML Conversion Rules. In particular, the UML classes above shall
not be considered as TPEG Service Components. For definitions of its physical data representations see
Annex A for TPEG-binary and Annex B for tpegML.
6.2 TPEG Transport level
The TPEG Transport level is dependent on the physical representation used. The information provided
on this level may include meta information for data structure identification, synchronization and error
detection. For details see Annex A for TPEG-binary and Annex B for tpegML.
6.3 TPEG Service level
6.3.1 General
The following sub-clauses describe in an abstract way the data objects used by the TPEG Service Multiplex
and Service Component Multiplex. The physical representations of these data objects in TPEG-binary and
tpegML are defined in Annex A and Annex B. The attributes of these data objects have dedicated types,
which are defined in this document or in TISA Specification: TPEG UML Modelling Rules.
6.3.2 TPEG Service structure
The TPEG Service Structure contains the Service Component Multiplex of a dedicated TPEG Service.
Each instance of this structure includes the SID of the corresponding TPEG Service and a different
range and number of Service Component Structures as required by the service provider.
The attributes of the TPEG Service structure are listed hereunder:
Table 1 — Attributes of the TPEG Service structure
Name Type Multiplicity Description
SID ServiceIdentifier 1 Service Identifier (SID A/B/C) of the TPEG Service cor-
responding to the including Service Structure instance.
For details see 6.3.3.2.
ServEncID IntUnTi 1 The Service Encryption Indicator signals the encryp-
tion method used for the Service Component Multiplex
contained in the Service Structure object. For details
see 6.3.3.1.
Service ServiceComponent 1.* One or several instances of type Service Component
Component Structure (see also 5.4). The resultant data object
Multiplex is transformed according to the encryption method
required (if the Encryption Indicator is not 0) or is left
unchanged (if the Encryption Indicator = 0).
This structure is solely used to transport the TPEG Stream Directory information, i.e. the SIDs of the
TPEG Services transmitted in this data stream. The attributes of the TPEG Stream Directory Structure
are listed hereunder:
Table 2 — Attributes of the TPEG Stream Directory structure
Multiplic-
Name Type Description
ity
SID ServiceIdentifier 1.* A vector of Service Identifiers (SID A/B/C) of the TPEG
Services transmitted in the corresponding data stream.
6.3.3 Service level attributes description
6.3.3.1 Service Encryption Indicator
The Service Encryption Indicator is an unsigned integer value with range 0-255. If the indicator has
value 0 all data in the Service Component Multiplex are non-encrypted. Every other value of the Service
Encryption Indicator indicates that one of several mechanisms for data encryption or compression has
8 © ISO 2019 – All rights reserved

been utilized for all data in the following multiplex data. The encryption/compression technique and
algorithms may be freely chosen by the service provider.
0 = no encryption/compression;
1 to 127 = reserved for standardised methods, for the current list of already allocated
Encryption Indicators, see http: //www .tisa .org;
128 to 255 = may be freely used by each service provider, may indicate the use
of proprietary methods.
6.3.3.2 Service identification
The Service IDs are structured in a similar way to Internet IP addresses as follows:
SID-A . SID-B . SID-C
The range of each SID element is 0-255 (type IntUnTi). The combination of these three SID elements
shall be uniquely allocated on a worldwide basis. The following address allocation system applies:
SID range for TPEG technical test     SIDs = 000.000.000 – 000.127.255
Any SID may be used within this range for up to a maximum of 12 months, on a self allocation basis.
Services with such an SID shall not be shown in any end-user client device
(allows for approximately 32,000 possibilities)
SID range for TPEG public test      SIDs = 000.128.000 – 000.255.255
Any SID may be used within this range for up to a maximum of 12 months, on a self allocation basis.
Services with such an SID may be shown in end-user client devices and shall be clearly marked as trials
that may contain invalid data
(allows for approximately 32,000 possibilities)
SID range for TPEG regular public services   SIDs = 001.000.000 – 100.255.255
SIDs within this range will be allocated by the TISA, for a small fee and may then be used on a long-term
basis, subject to renewal
(allows for approximately 6 million possibilities)
SID range: reserved for future use     SIDs = 101.000.000 – 255.255.255
SIDs within this range will be allocated by the TISA, at some time in the future
(allows for approximately 10 million possibilities)
A SID in the ‘TPEG technical test range’ may be used by a tester or service provider, self organized,
making the assumption that NO client device will respond to such a SID. All SIDs in the ‘TPEG public
test' and 'TPEG regular public services' ranges are assumed to cause a response in any client device.
Specialist test client devices may be able to access any range of SIDs. For the current list of already
allocated SID's, see http: //www .tisa .org.
6.4 TPEG Service Component level
6.4.1 Service Component structure
The TPEG Service Component Multiplex is realized by a collection of one or more instances of TPEG
Service Component Structures, the type and order of which are freely determined by the service
provider.
The composition of the Service Component Multiplex of a TPEG Service is signalled by the tables in
the related SNI as defined in ISO/TS 18234-3. Within a Service Component Multiplex stream one and
only one SNI Service Component shall be present. This SNI Service Component shall have the Service
Component ID (SCID) = 0. Note that the SNI Service Component may not be included in every TPEG
Service Structure instance but shall be present in the Service Component stream. The service provider
is free to determine the transmission frequency of the SNI though it should be sent in each Service
Structure instance, if possible.
According to the Service Component Encryption Indicator (EncID) value in the SNI (ISO/TS 18234-3)
the Service Component Data included in a Service Component may be encrypted (see also 6.3.3.1) while
the other attributes of the Service Component Structure shall be unencrypted in this case.
The attributes of the TPEG Service Component Structure are listed hereunder.
Table 3 — Attributes of the TPEG Service Component structure
Multiplic-
Name Type Description
ity
Meta Dependent on physical 0.1 Meta information for data structure identifica-
Information representation tion and error detection (CRC), as required by
the physical representation applied
SCID IntUnTi 1 Service Component Identifier (SCID) as defined
in the related SNI component. For the SNI the
value shall always be SCID = 0.
Service ServiceComponentData 1.* The Service Component Data contains the TPEG
Component messages encoded according the specification
Data of the related TPEG Application. The Service
Component Data maybe encrypted if encryption
on the Service Component level is applied.
10 © ISO 2019 – All rights reserved

Annex A
(normative)
TPEG-Binary Representation of Framework Structures
A.1 General definitions
For general definitions concerning TPEG data types refer to TISA Specification: TPEG UML Modelling
Rules. The notation is defined in the UML to TPEG-Binary conversion rules specification. However, the
notation is used in this document without having the UML equivalent.
A.2 TPEG data stream description
A.2.1 Diagrammatic hierarchy representation of frame structure
In the TPEG-binary representation the TPEG Structures on the Transport, Service and Service
Component level are realized by data frames. The following diagram shows the hierarchical structure
of the TPEG frames:
Figure A.1 — TPEG Frame Structure, Frame Type = 1 (i.e. conventional data)
Figure A.2 — TPEG Frame Structure, Frame Type = 0 (i.e. Stream Directory)
A.2.2 Syntactical representation of the TPEG stream
A.2.2.1 TPEG Transport Frame
A.2.2.1.1 Structure
The following boxes are the syntactical representation of the TPEG frame structure shown in A.2.1.
The byte stream consists of consecutive TPEG Transport Frames. The Transport Frames in a TPEG data
stream may belong to one service provider only or may build a multiplex of TPEG Services of different
service providers.
Each Transport Frame shall include exactly one TPEG Service Frame whose length is restricted to max.
65535 Bytes.
The byte stream shall be built according to the above-mentioned repetitive structure of Transport
Frames. If possible, one Transport Frame should follow another directly, however if any spacing bytes
are required these should be set to 0 hex (padding bytes).
< TpegStream > : = : The data stream
infinite { : Control element, (loop continues infinitely)
n * < IntUnTi > (0), : Any number of padding bytes (0 hex)
< TransportFrame > : Transport Frame
};
< TransportFrame(0) > : =
< IntUnLi > (FF0F hex), : Synchronization word (FF0F hex), see A.2.2.1.2
< IntUnLi > (m), : Field length, number of bytes in Service Frame (max. 65535 Bytes),
see A.2.2.1.2
< CRC > (tFrameHeaderCRC), : Transport Frame Header CRC, see A.2.2.1.2
< IntUnTi > (x), : Frame type of Service Frame, see A.2.2.1.2
< ServiceFrame(x) > ; : Any Service Frame follows
A.2.2.1.2 TPEG Transport Frame attributes
Syncword
The Syncword shall be 2 bytes long and shall have the value of FF0F hex.
The nibbles F hex and 0 hex have been chosen for simplicity of processing in decoders. The patterns
0000 hex and FFFF hex were deprecated to avoid the probability of false triggering in the cases of some
commonly used transmission channels. The byte sequence FF0F may also occur as regular TPEG data
in the transport frame payload. As a consequence, additional verification of synchronization status is
required. This may for instance be performed by checking the transport frame header CRC.
Field Length
12 © ISO 2019 – All rights reserved

The value of the Field Length attribute shall be equal to the number of bytes in the Service Frame, i.e. all
bytes following the Frame Type attribute. This derives from the need of variable length frames.
Frame Type
The Value of the Frame Type attribute indicates the content of the Service Frame The following table
gives the meaning of the Frame Type:
Frame Type value (dec): Kind of information in Service Frame:
0 Stream Directory information included in the Transport Frame
(see A.2.2.3)
1 Service Component Multiplex data included in the Transport Frame
(see A.2.2.4)
Transport Frame Header CRC
The Transport Frame Header CRC enables an error detection of the header of Service Component Frames:
16 12 5
The CRC shall be two bytes long, and shall be based on the ITU-T polynomial x + x + x + 1.
The CRC shall be calculated on 16 bytes including the Syncword, the Field Length, the Frame Type and
the first 11 bytes of the Service Frame. In the case that a Service Frame is shorter than 11 bytes, the
Syncword, the Field Length, the Frame Type and the whole Service Frame shall be taken into account. In
this case the Header CRC calculation does not run into the next Transport Frame.
The calculation of the CRC is described in Annex D.
A.2.2.1.3 Synchronization method
On the TPEG Service Level a three-step synchronization algorithm can be implemented to synchronize
the TPEG Client:
a) Search for an FF0F hex value (Syncword).
b) Calculate and check the header CRC, which follows.
c) Check the two bytes which follow the end of the Service Frame as defined by the field length.
The two bytes following the end of the Service Frame should either be a sync word or 00 hex, when
spaces are inserted for padding.
A.2.2.2 TPEG Service Frame template structure
A Service Frame comprises:
< ServiceFrame(x) > : = : Template for Service Frame
n * < byte > ; : Content of service frame
A.2.2.3 Service Frame of frame type = 0 (Stream Directory Frame)
A.2.2.3.1 Structure
This Service Frame is solely used to transport the Stream Directory information.
< StreamDirectory < ServiceFrame(0) > > : = : Stream Directory frame
< IntUnTi > (n), : Number of services
n * < ServiceIdentifier > , : Any number of Service IDs
< CRC > (streamDirCRC); : Stream Directory CRC for the number (n) of Service IDs
and the SID-list, see A.2.2.3.2
A.2.2.3.2 Attributes
Stream Directory CRC
The Stream Directory CRC enables an error detection of the Stream Directory Frame data.
For the Stream Directory Frame (Frame Type = 0) an extra CRC calculation is done over the whole
Stream Directory data, i.e. starting with the attribute n encoding the number of SIDs in the Stream
Directory and ending with SID-C of the last SID.
The calculation of the CRC is described in Annex D.
A.2.2.4 Service Frame of frame type = 1 (Service Data Frame)
A TPEG Service Frame may contain a different range and number of Service Component Frames
as required by the service provider. Furthermore, each Service Data Frame shall include service
information that comprises the service identification elements and the encryption indicator.
< ServiceData < ServiceFrame(1) > > : = : Service data frame
< ServiceIdentifier > (SID), : Service identification (SID-A, SID-B, SID-C)
< IntUnTi > (ServEncID), : Service encryption indicator, 0 = no encryption
f ( ); : Function f (…) is utilized according to the chosen encryption
n n
algorithm
A.2.2.5 TPEG Service Component Multiplex
The Service Component Multiplex is a collection of one or more Service Component Frames, whose
type and order are freely determined by the service provider. The resultant multiplex is transformed
according to the encryption method required (if the encryption indicator of the Service Frame is not 0)
or is left unchanged (if the encryption indicator = 0). The length of the resultant data shall be less than
or equal to 65531 bytes.
< ServCompMultiplex > : =
n * < ServCompFrame > (data);         : Any number of any Service Component Frames
A.2.2.6 Interface to application specific Service Component Frames
The TPEG Service Component Frame introduces the application specific code. This means further
details of the data stream are specified by the application specification. In the history for different
needs slightly different Service Component Frames have been defined in the existing application
specifications. To harmonize this kind of frame, especially for new developments of specifications, this
section specifies not only a basic Service Component Frame which is required for any application but
also a selection of possible other Service Component Frames, whereof an application can just choose
one without the need to specify its own Service Component Frame.
An application specification, however, can specify its own Service Component Frame, which shall at
minimum include the following base Service Component Frame as first sub type.
A.2.2.6.1 TPEG Base Service Component Frame structure
In a TPEG data stream it is possible to transmit a variety of TPEG message types. For that, the Service
and Network Information (SNI) Application provides a variable directory-like information of the TPEG
Service structure. This includes also the definition which the TPEG Application can be expected in a
specific Service Component Frame.
14 © ISO 2019 – All rights reserved

Thus, the Service Component Frame starts not with a typical interface template, but with a header,
defining the three first frame attributes being in common for all Service Component Frames. Therefore,
any Service Component Frame is built as shown below:
< ServCompFrame > : = : Service Component Frame
< ServCompFrameHeader > (header), : Common Service Component header
< ApplicationData > (data); : Component data
Where the Service Component header is specified as:
< ServCompFrameHeader > : = : Common Service Component Frame header
< IntUnTi > (SCID), : Service Component identifier (SCID is defined by SNI Service Component,
which is amongst others designating the application in this Service
Component Frame)
< IntUnLi > (fieldLength), : Length of the component data in bytes, starting with the first byte after
the scHeaderCRC attribute
< CRC > (scHeaderCRC); : Service Component Header CRC (see A.2.3.3)
At the Service Component level data are carried in Service Component Frames which have a limited
length. If applications require greater capacity then the application shall be designed to distribute data
between Service Component Frames and to recombine this information in the decoder.
The inclusion of the field length enables the decoder to skip a component.
The maximum field length of the Service Component data (assuming that there is no transformation,
and only one component is included in the Service Frame) = 65526.
A.2.2.6.2 TPEG specialized Service Component data schemata
For reasons of consistency, Service Component Frames should be defined as similar as possible for the
different applications. Specifically, three further header attributes of general nature may be used in the
application specific Service Component Frames for the following purposes:
— The application data of a Service Component Frame with dataCRC is error-free.
— Data CRC on this level makes it possible, that in case of erro
...