IEC 62298-2:2005

INTERNATIONAL IEC
STANDARD 62298-2
First edition
2005-05
TeleWeb application –
Part 2:
Delivery methods
Reference number
Publication numbering
As from 1 January 1997 all IEC publications are issued with a designation in the
60000 series. For example, IEC 34-1 is now referred to as IEC 60034-1.
Consolidated editions
The IEC is now publishing consolidated versions of its publications. For example,
edition numbers 1.0, 1.1 and 1.2 refer, respectively, to the base publication, the
base publication incorporating amendment 1 and the base publication incorporating
amendments 1 and 2.
Further information on IEC publications
The technical content of IEC publications is kept under constant review by the IEC,
thus ensuring that the content reflects current technology. Information relating to
this publication, including its validity, is available in the IEC Catalogue of
publications (see below) in addition to new editions, amendments and corrigenda.
Information on the subjects under consideration and work in progress undertaken
by the technical committee which has prepared this publication, as well as the list
of publications issued, is also available from the following:
• IEC Web Site (www.iec.ch)
• Catalogue of IEC publications
The on-line catalogue on the IEC web site (www.iec.ch/searchpub) enables you to
search by a variety of criteria including text searches, technical committees
and date of publication. On-line information is also available on recently issued
publications, withdrawn and replaced publications, as well as corrigenda.
• IEC Just Published
This summary of recently issued publications (www.iec.ch/online_news/ justpub)
is also available by email. Please contact the Customer Service Centre (see
below) for further information.
• Customer Service Centre
If you have any questions regarding this publication or need further assistance,
please contact the Customer Service Centre:

Email: custserv@iec.ch
Tel: +41 22 919 02 11
Fax: +41 22 919 03 00
INTERNATIONAL IEC
STANDARD 62298-2
First edition
2005-05
TeleWeb application –
Part 2:
Delivery methods
 IEC 2005  Copyright - all rights reserved
No part of this publication may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying and microfilm, without permission in writing from the publisher.
International Electrotechnical Commission, 3, rue de Varembé, PO Box 131, CH-1211 Geneva 20, Switzerland
Telephone: +41 22 919 02 11 Telefax: +41 22 919 03 00 E-mail: inmail@iec.ch Web: www.iec.ch
PRICE CODE
Commission Electrotechnique Internationale W
International Electrotechnical Commission
МеждународнаяЭлектротехническаяКомиссия
For price, see current catalogue

– 2 – 62298-2  IEC:2005(E)
CONTENTS
FOREWORD.3
INTRODUCTION.5

1 Scope.6
2 Normative references .6
3 Terms, definitions and abbreviations .7
3.1 Terms and definitions .7
3.2 Abbreviations .8
4 Delivery profiles .8
4.1 TeleWeb delivered via Teletext packets in VBI lines .8
4.2 TeleWeb delivered via PES packets in an MPEG-2 TS .9
4.3 TeleWeb delivered via DSM-CC sections in an MPEG-2 TS .10
4.4 TeleWeb delivered via other methods.10
5 Transport layer protocols.10
5.1 DSM-CC data carousel.10
5.2 Interaction channel.25
6 TeleWeb DSM-CC transmission via Teletext.29
6.1 Transmission of data carousels .29
6.2 Transmission protocol .29
6.3 Teletext packet format.30
7 Signalling TeleWeb in DVB.31
7.1 Signalling in the program map table (PMT).31
7.2 Signalling in the service description table (SDT).33
7.3 Service detection time .35
7.4 Multiple TeleWeb services.35
8 Transport in DVB.35
8.1 Transport in PES packets.35
8.2 Transport in DSM-CC sections .35

Annex A (informative)  CCITT CRC-16.36

Bibliography.37

Figure 1 – Delivery method for TeleWeb using Teletext packets in VBI lines.9
Figure 2 – Delivery method for TeleWeb using PES packets in an MPEG-2 TS .9
Figure 3 – Delivery method for TeleWeb using DSM-CC sections in an MPEG-2 TS .10
Figure 4 – Structure of one-layer and two-layer data carousels.11
Figure 5 – Format of transactionId field.13
Figure 6 – Format of the profile_flags byte.24
Figure 7 – Message transmission sequence.29

62298-2  IEC:2005(E) – 3 –
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
TELEWEB APPLICATION –
Part 2: Delivery methods
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62298-2 has been prepared by IEC technical committee 100:
Audio, video and multimedia systems and equipment.
This standard cancels and replaces IEC/PAS 62298 published in 2002.
This first edition constitutes a technical revision.
The text of this standard is based on the following documents:
FDIS Report on voting
100/923/FDIS 100/961/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.

– 4 – 62298-2  IEC:2005(E)
IEC 62298 consists of the following parts, under the general title TeleWeb application:
Part 1: General description
Part 2: Delivery methods
Part 3: Superteletext profile
Part 4: Hyperteletext profile
The committee has decided that the contents of this publication will remain unchanged until
the maintenance result date indicated on the IEC web site under http://webstore.iec.ch in the
data related to the specific publication. At this date, the publication will be
• reconfirmed;
• withdrawn;
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

62298-2  IEC:2005(E) – 5 –
INTRODUCTION
The aim of TeleWeb is to deliver World Wide Web-style content to the living-room TV to give
the viewer an enhanced television experience. A TeleWeb service broadcasts data files
containing text and high-definition graphics to suitable decoders. The data transmitted can be
closely linked to events within the accompanying TV programmes or can be more general in
nature to emulate a traditional, but higher definition, superteletext service. Different profiles
are defined.
It is intended that TV-based decoders be implemented in a cost-effective manner without
recourse to the technology normally associated with personal computers. In part, this is
achieved by limiting the number of different types of multimedia data that can be used within a
service. By careful design of the user interface, decoder manufacturers will be able to offer
easy-to-use equipment for accessing TeleWeb services without requiring the consumer to be
computer-literate. In addition, they will be able to customize their products to differentiate
them from those of their competitors.
This standard focuses on the transmission layer.

– 6 – 62298-2  IEC:2005(E)
TELEWEB APPLICATION –
Part 2: Delivery methods
1 Scope
This part of IEC 62298 specifies the transmission layer of TeleWeb.
TeleWeb services can be broadcast in a number of different ways, for example, VBI, DVB,
DAB, etc., and to a variety of decoder types, for example, TVs, portable decoders, PCs, etc.
This standard specifies the transmission layer for VBI and DVB broadcasts.
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.
IEC 62298-1: TeleWeb application – Part 1: General description
IEC 62298-3: TeleWeb application – Part 3: Superteletext profile
IEC 62298-4: TeleWeb application – Part 4: Hyperteletext profile
ISO/IEC 13818-1, Information technology − Generic coding of moving pictures and associated
audio information: Systems
ISO/IEC 13818-6, Information technology − Generic coding of moving pictures and associated
audio information − Part 6: Extension for DSM-CC
ISO 639-2, Codes for the representation of names of languages – Part 2: Alpha-3 code
ISO 8859-1, Information technology − 8-bit single-byte coded graphic character sets − Part 1:
Latin alphabet No. 1
ETSI TR 101 154: V1.4.1, Digital Video Broadcasting (DVB); Implementation guidelines for
the use of MPEG-2 Systems, Video and Audio in satellite, cable and terrestrial broadcasting
applications
ETSI TR 101 202, Implementation guidelines for data broadcasting, V1.1.1
ETSI EN 300 421, Digital Video Broadcasting (DVB); Framing structure, channel coding and
modulation for 11/12 GHz satellite services
ETSI EN 300 429, Digital Video Broadcasting (DVB); Framing structure, channel coding and
modulation for cable systems
———————
To be published.
62298-2  IEC:2005(E) – 7 –
ETSI EN 300 706, Enhanced Teletext Specification
ETSI EN 300 708, Television Systems; Data Transmission within Teletext
ETSI EN 300 744, Digital Video Broadcasting (DVB); Framing structure, channel coding and
modulation for digital terrestrial television
ETSI EN 301 192, Digital Video Broadcasting (DVB); DVB specification for data broadcasting,
V1.2.1
ETSI ETS 300 472, Digital Video Broadcasting (DVB); Specification for conveying ITU-R
System B Teletext in DVB bit streams
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of the present document, the following terms and definitions apply.
3.1.1
bit ordering
in all schematics, numeric values ordered with the most significant bit at the left-hand side
and the least significant bit at the right-hand side
3.1.2
conditional access (CA)
mechanism by which user access to service components can be restricted
3.1.3
Independent Data Line (IDL)
stand-alone Teletext packet containing both control and application data. It does not form part
of a Teletext page. The packet address is either 30 or 31
3.1.4
module
when broadcast within a DSM-CC data carousel, the contents of a file and its attributes (for
example, file type, creation date, etc.) are transmitted separately. The file itself is carried by a
number of DDB messages and its attributes appear as descriptors within its module loop
within a DII control message
3.1.5
signed integer
positive or negative integer value, in decimal notation. The first digit is preceded by a
mandatory plus (+) or minus (–) symbol with no white space between the symbol and the first
digit
3.1.6
text string
sequence of displayable Latin-1 characters
3.1.7
unsigned integer
integer value, in decimal notation, not preceded by a plus (+) or minus (–) symbol

– 8 – 62298-2  IEC:2005(E)
3.2 Abbreviations
BSLBF Bit String, Left Bit First
CA Conditional Access
CRC Cyclic Redundancy Check
DAB Digital Audio Broadcasting
DDB Download Data Block message
DII Download Info Indication message
DSI Download Server Initiate message
DSM-CC Digital Storage Media Command and Control
DVB Digital Video Broadcasting
ETS European Telecommunication Standard
HTML Hyper Text Mark-up Language
IDL Independent Data Line
IEC International Electrotechnical Commission
ISO International Organisation for Standardization
LSB Least Significant Bit
MJD Modified Julian Date
MPEG Moving Picture Experts Group
MSB Most Significant Bit
OSI Open Systems Interconnection
PES Packetized Elementary Stream
PID Packet Identifier
PMT Program Map Table
RFC Internet Requests for Comments
RPCHOF Remainder Polynomial Coefficient, Higher Order First
SDT Service Description Table
TS Transport Stream
UIMSBF Unsigned Integer Most Significant Bit First
URL Uniform Resource Locator
UTC Universal Time Coordinated
VBI Vertical Blanking Interval
4 Delivery profiles
There are several ways in which a TeleWeb application can be delivered (see Figure 1 in
IEC 62298-1). For the purposes of this document, a delivery profile specifies layers 1 to 4 of
the OSI seven-layer model.
4.1 TeleWeb delivered via Teletext packets in VBI lines
Figure 1 shows layers 1 to 4 of the OSI seven-layer model for delivering a TeleWeb service
via Teletext packets. The application files are formed into a DSM-CC data carousel at the
transport layer, as defined in 5.1. The components of the carousel are then encapsulated in
independent Teletext data packets (see 6.3). These are transmitted in the VBI lines of an
analog TV signal as described in ETSI EN 300 708.

62298-2  IEC:2005(E) – 9 –
Layer  Generic content  TeleWeb specific content
Layer 4: Arranging the data in a suitable way for transport DSM-CC data carousel:
Transport Blocks and modules
Descriptors
Groups and supergroups
Delimiting between messages
Forward error correction
Layer 3: Logical functions related to the multiplexing and Format B independent data line as defined in
Network demultiplexing of data packets belonging to ETSI EN 300 708 (“Packet 31”)
different communications flows:
Data channel addressing
Data packet sequencing
Layer 2: Logical functions related to data transmission: Normal Teletext packet format as defined in ETSI
Link EN 300 706
Byte synchronization
Error control (framing, misdirection and
false detection)
Data formatting
Layer 1: Electrical transmission of the data signal Normal Teletext parameters as defined in ETSI
Physical EN 300 706
IEC  679/05
Figure 1 – Delivery method for TeleWeb using Teletext packets in VBI lines
4.2 TeleWeb delivered via PES packets in an MPEG-2 TS
Figure 2 shows layers 1 to 4 of the OSI seven-layer model for delivering a TeleWeb service
via Teletext packets. The application files are formed into a DSM-CC data carousel at the
transport layer, as defined in 5.1. The components of the carousel are then encapsulated in
independent Teletext data packets (see 6.3). These are transmitted in an MPEG-2 transport
stream using PES packets as described in ETSI ETS 300 472.
NOTE The data is prepared as it would be for transmitting in 4.1, added to a transport stream and treated as an
analog Teletext service.
Layer  Generic content  TeleWeb specific content
Layer 4: Arranging the data in a suitable way for transport Embedding in DSM-CC data carousel as specified
Transport in this standard
Layer 3: Logical functions related to the multiplexing and Embedding in Format B independent data line as
Network demultiplexing of data packets belonging to defined in ETSI EN 300 708 (“Packet 31”)
different communications flows:
Data channel addressing
Data packet sequencing
Layer 2: Logical functions related to the data transmission: Embedding in an MPEG-2 transport stream using
Link PES packets ETSI ETS 300 472
Byte synchronization
Error control (framing, misdirection and
false detection)
Data formatting
Layer 1: Electrical transmission of the data signal Multiplexing and transmission according to DVB-T
Physical ETSI EN 300 744, DVB-C ETSI EN 300 429 or
DVB-S ETSI EN 300 421
IEC  680/05
Figure 2 – Delivery method for TeleWeb using PES packets in an MPEG-2 TS

– 10 – 62298-2  IEC:2005(E)
4.3 TeleWeb delivered via DSM-CC sections in an MPEG-2 TS
Figure 3 shows layers 1 to 4 of the OSI seven-layer model for delivering a TeleWeb service
via DSM-CC sections. The application files are formed into a DSM-CC data carousel at the
transport layer, as defined in 5.1. The components of the carousel are then encapsulated in
DSM-CC sections in an MPEG-2 transport stream as described in ISO/IEC 13818-6.

Layer  Generic content  TeleWeb specific content
Layer 4: Arranging the data in a suitable way for transport Embedding in DSM-CC data carousel as specified
Transport in this standard
Layer 3: Logical functions related to the multiplexing and Embedding in DSM-CC sections as specified
Network demultiplexing of data packets belonging to in this standard
different communications flows:
Data channel addressing
Data packet sequencing
Layer 2: Logical functions related to the data transmission: Embedding in TS packets as specified in ISO/IEC
Link 13818-6
Byte synchronization
Error control (framing, misdirection and
false detection)
Data formatting
Layer 1: Electrical transmission of the data signal Multiplexing and transmission according to DVB-T
Physical ETSI EN 300 744, DVB-C ETSI EN 300 429 or
DVB-S ETSI EN 300 421
IEC  681/05
Figure 3 – Delivery method for TeleWeb using DSM-CC sections in an MPEG-2 TS
4.4 TeleWeb delivered via other methods
This standard will be amended when necessary with other transport methods.
5 Transport layer protocols
This clause defines protocols for implementing the transport layer.
5.1 DSM-CC data carousel
5.1.1 Overview
The files of a TeleWeb service are organized in DSM-CC data carousels according to the
general principles defined in ISO/IEC 13818-6 and adapted for DVB applications as described
in ETSI EN 301 192 and ETSI TR 101 202. The DSM-CC data carousel specification
embodies the cyclic transmission of data to receivers. The data transmitted within a carousel
is first organized into “modules”, which are then subdivided into “blocks”. All the blocks of all
modules within the data carousel are of the same size, except for the last block of each
module, which may be of a smaller size. Each individual file in a TeleWeb service is treated
as a module. Modules can be clustered together to form a “group”. Likewise, groups can be
clustered to form “supergroups”.
The data carousel specification defined here uses three messages from the full data carousel
specification defined in ISO/IEC 13818-6. The data blocks are carried in DownloadDataBlock
(DDB) messages, while control over the modules is provided by DownloadInfoIndication (DII)
and DownloadServerInitiate (DSI) messages. Other DSM-CC messages listed in ISO/IEC
13818-6 are not used in the TeleWeb application and should be ignored by receivers
designed to this edition. All messages begin with the generic DSM-CC Message Header.
———————
ISO/IEC 13818-6, Clause 2.
62298-2  IEC:2005(E) – 11 –
This header contains information about the type and size of the message. The maximum size
of any DII, DSI or DDB message shall be 4 084 bytes (including the message header).
A receiver shall ignore message fields marked “reserved” (ISO-designated) or “reserved for
future use” (ETSI-designated), noting that such fields may be variable in size.
A data carousel can have one or two layers of control information as shown in Figure 4. The
service provider is free to choose the most appropriate type. A receiver shall be able to work
with both types.
One-layer data carousel Two-layer data carousel
DSI TransactionId
gi gi
DII TransactionId DII TransactionId DII TransactionId
mi mi mi mi mi mi mi mi mi
DDB DDB DDB DDB DDB DDB DDB DDB DDB
DDB DDB DDB DDB DDB DDB DDB DDB DDB
DDB DDB DDB DDB
DDB
DDB
Block
DDB DDB DDB
Block
Module
Module
Group
Group
SuperGroup
DSI: DownloadServerInitiate message
DII: DownloadInfoIndication message
DDB: DownloadDataBlock message
gi: Group Information bytes
mi: Module Information bytes
IEC  682/05
Figure 4 – Structure of one-layer and two-layer data carousels
A one-layer carousel defines a single group. The top-level control message is a DII message.
This describes all the modules in the carousel. The module description includes a descriptor
loop that carries the attributes (for example, type, theme) of each module.
A two-layer carousel comprises a number of one-layer carousels. The top-level control
message is a DownloadServerInitiate message (DSI), 5.1.2.2. This describes the different
groups in the supergroup. Each group is described by a DII message as for a one-layer
carousel.
A TeleWeb service may be implemented across a number of carousels. The need for multiple
carousels arises because of the significant overhead associated with updating the contents of
control messages when transmitting real-time information. This can be minimized by limiting
the amount of data in a carousel that contains information that changes very frequently. The
maximum number of carousels may be limited by the transmission method.

– 12 – 62298-2  IEC:2005(E)
5.1.2 DSM-CC messages
5.1.2.1 DownloadInfoIndication message
A DownloadInfoIndication message contains the description of the modules within a group as
well as some general parameters of the data carousel such as block size. Each module within
the group can be described by a number of descriptors. These carry the TeleWeb-specific
attributes.
The syntax of a DII message is shown in Table 1. The final column indicates if a field has a
fixed or variable value in the TeleWeb application.
Table 1 – Syntax of the DownloadInfoIndication message
Syntax No. of bytes TeleWeb use
DownloadInfoIndication() {
protocolDiscriminator 1
Fixed at 0× 11
dsmccType 1
Fixed at 0× 03
messageId 2 Fixed at 0× 1002
transactionId 4 Variable
reserved 1 Fixed at 0× FF
adaptationLength 1 Variable
messageLength 2 Variable
dsmccAdaptationHeader() adaptationLength Reserved for future use
downloadId 4 Variable
blockSize 2 Variable
windowSize 1 Fixed at 0× 00
ackPeriod 1
Fixed at 0× 00
tCDownloadWindow 4
Fixed at 0× 00 throughout
tCDownloadScenario 4 Variable
compatibilityDescriptorLength 2
Fixed at 0× 0000 (no
compatibilityDescriptor)
numberOfModules 2 Variable
for(i=0; i< numberOfModules; i++) {
moduleId 2 Variable
moduleSize 4 Variable
moduleVersion 1 Variable
moduleInfoLength 1 Variable
for(j=0; j< moduleInfoLength; j++) {
moduleInfoByte 1 Variable
}
}
privateDataLength 2 Variable
for(i=0; i< privateDataLength; i++) {
privateDataByte 1 Reserved for future use
}
}
62298-2  IEC:2005(E) – 13 –
The protocolDiscriminator field is used to indicate that the message is a DSM-CC message
within a particular environment. This field has the fixed value of 0× 11.
The dsmccType field is used to indicate the type of DSM-CC message. The “user-to-network”
download messages of which data carousels are a part have been allocated the value 0× 03.
The messageId field is fixed at 0× 1002 to identify the message as a DownloadInfoIndication
message.
The transactionId field provides both the unique identification of a control message and
version information. The version component is changed whenever any field of the
message is modified. Reference ISO/IEC 13818-6 defines the transactionId as consisting
of a 2-bit transactionId_originator field (2 MSBs) and a 30-bit transaction_number field.
The TeleWeb application adopts the DVB interpretation as described in ETSI TR 101 202
and divides the field into the four subfields shown in
Figure 5.
In the case of a two-layer carousel, each DII message is referenced from within the group
loop of the DSI message. The transactionId field in a DII message and the corresponding
groupId field in the DSI message are coded identically.

Bit: 31 30 29   16 15    1 0
Update
Sub-
Originator Version Identification
flag
field:
State: 1 0 Variable Variable Toggles

IEC  683/05
Figure 5 – Format of transactionId field
The Update Flag (bit 0) shall be toggled every time the message is updated.
The Identification subfield (bits 1 to 15) shall be set to 0× 0000 for the top-level control
message in the data carousel. All other control messages shall have one or more non-zero
bits as described in ETSI EN 301 192. This coding scheme enables a receiver to determine
whether a carousel is one- or two-layered having acquired any DII message.
− For the one-layer carousel, the identification field in the DII message will be 0× 0000.
– For the two-layer carousel, the identification field in a DII message will be in the range
0× 0001 to 0× 7FFF.
– The identification field in the DSI message will be 0× 0000.
NOTE If multiple carousels are used, a receiver is likely to detect DII messages with identification values from
0× 0000 to 0× 7FFF.
The Version subfield (bits 16 to 29) conveys a version number for the message. This value
shall be incremented modulo 0× 4000 every time the control message is updated.
NOTE A receiver should not expect to see linearly incrementing version numbers. There may be missing values.
For example, the encoder might have prepared a new DII message (and incremented the version number) following
a change, but before it can be transmitted another change is detected, causing the version number to be
incremented yet again before transmission. The updating actions required on a change of data are described in
5.1.3.
———————
ISO/IEC 13818-6, Clause 2, Table 2-2.
ISO/IEC 13818-6, 7.3, Table 7-4.
ISO/IEC 13818-6, Clause 2, Figure 2-1.

– 14 – 62298-2  IEC:2005(E)
In order to be strictly DSM-CC compliant, the value used in originator subfield (bits 31 to 32)
shall be fixed at 0× 02 to indicate that the transactionId has been assigned by the network.
The reserved field shall be set to 0× FF as required by ISO/IEC 13818-6.
The adaptationLength field indicates the total length in bytes of the DSM-CC adaptation
header (dsmccAdaptationHeader).
NOTE The adaptation header is not used to carry TeleWeb-specific information. Receiver designers should note
that data carousels may use the adaptation header for other purposes. Receivers should be able to accept an
adaptationLength of any value and should ignore any data in the dsmccAdaptationHeader field.
The messageLength field is used to indicate the total length in bytes of the remainder of the
message following this field. This value includes any adaptation headers and compatibility
descriptors that may be present.
The downloadId field is used as an identifier for the messages of a particular TeleWeb
carousel. All DII and DDB messages within the same carousel shall use the same value in
their downloadId fields.
The blockSize field defines the number of blockDataBytes carried in the DDB messages
described by this DII.
NOTE The last block of each module may contain fewer blockDataBytes than the value indicated by blockSize.
The windowSize, ackPeriod, and tCDownloadWindow fields are not used by data carousels
and all bytes shall be fixed at 0× 00.
The tCDownloadScenario field indicates a time period in microseconds for the entire
download scenario. If the value is unknown, or is considered to be unimportant, a value of
0× FFFFFFFF shall be inserted in this field.
The compatibilityDescriptorLength field indicates the total length in bytes of the following
DSM-CC Compatibility Descriptor.
NOTE 1 According to ISO/IEC 13818-6, the compatibilityDescriptorLength is the first field in the DSM-CC
compatibilityDescriptor. It is shown here as a separate field to aid understanding.
NOTE 2 The compatibilityDescriptor is not used by TeleWeb and the compatibilityDescriptorLength field should be
set to 0× 0000.
The numberOfModules field indicates the number of modules described in the loop following
the field. In a one-layer carousel, this loop will describe all the modules associated with the
carousel.
The moduleId field is an identifier for the module that is described by the following
moduleSize, moduleVersion, and moduleInfoByte fields. The value must be unique within the
scope of the message sharing the same downloadId value, i.e. within the same data carousel.
Values in the range 0× 0000 to 0× FFEF shall be used.
NOTE ModuleId values in the range 0× FFF0 to 0× FFFF are reserved for DAVIC compliant applications and
shall not be used in TeleWeb applications.
———————
ISO/IEC 13818-6, Clause 2, Table 2-3.
ISO/IEC 13818-6, Clause 2.
ISO/IEC 13818-6, 2.1.
ISO/IEC 13818-6, 6.1.
ETSI EN 301 192, 8.1.3.
62298-2  IEC:2005(E) – 15 –
The moduleSize field defines the number of blockDataBytes that make up the described
module. This equates to the size of the TeleWeb file carried by this module.
The moduleVersion field provides a version number for the described module. The value
inserted here shall match the current value of the moduleVersion field carried in the DDB
messages of the described module. The moduleVersion field is used for the version attribute
defined in IEC 62298-3.
The moduleInfoLength field defines the number of moduleInfoBytes that follow.
The moduleInfoBytes describe the module. These bytes shall contain the descriptors defined
in 5.1.4.
The privateDataLength field defines the length in bytes of the following privateDataByte field.
The function of the data in the privateDataByte field is specific to the TeleWeb application and
is reserved for future use.
5.1.2.2 DownloadServerInitiate message
The DownloadServerInitiate message is used to build a supergroup within a two-layer data
carousel.
The syntax of a DSI message is shown in Table 2. The final column indicates if a field has a
fixed or variable value in the TeleWeb application. The private data fields of the generic DSI
message according to ISO/IEC 13818-6 are used here to carry information relating to each
group according to the interpretation in ETSI EN 301 192 and ETSI TR 101 202. To allow
future enhancements, provision is made to carry additional private data.
Data fields not described in this clause have the same function and coding as their
equivalents in the DII message (5.1.2.1).
Table 2 – Syntax of the DownloadServerInitiate message
Syntax No. of bytes TeleWeb use
DownloadServerInitiate() {
protocolDiscriminator 1
Fixed at 0× 11
dsmccType 1
Fixed at 0× 03
messageId 2
Fixed at 0× 1006
transactionId 4 Variable
reserved 1 Fixed at 0× FF
adaptationLength 1 Variable
messageLength 2 Variable
dsmccAdaptationHeader() adaptationLength Reserved for future use
serverId 20
Fixed at 0× FF
throughout
compatibilityDescriptorLength 2 Fixed at 0× 0000 (no
compatibilityDescriptor)
privateDataLength 2 Variable
GroupInfoIndication() {
numberOfGroups 2 Variable
for(i=0; i< numberOfGroups; i++) {
groupId 4 Variable
– 16 – 62298-2  IEC:2005(E)
Syntax No. of bytes TeleWeb use
groupSize 4 Variable
groupCompatibilityDescriptorLength 2 Fixed at 0× 0000 (no
GroupCompatibility)
groupInfoLength 2
Fixed at 0× 0000 (no
groupInfoBytes)
}
}
futureUseLength 2 Variable
serviceInfoLength 2 Variable
for(k=0; k serviceInfoByte 1 Variable
}
for(k=0; k futureUseByte 1 Variable
}
}
The messageId field is fixed at 0× 1006 to identify the message as a DSI message.
The transactionId field has the same four subfields as its equivalent in the DII message. By
definition, the identification subfield shall always be set to 0× 0000.
The serverId field is unused and shall be set to 0× FF throughout.
The privateDataLength field defines the length in bytes of the remaining part of the message.
This consists of group-related data (GroupInfoIndication structure) and bytes reserved for
future use (futureUseLength and futureUseByte).
The GroupInfoIndication structure follows the DVB assignment of the private data bytes of the
generic DSM-CC DSI message, see ETSI EN 301 192 and ETSI TR 101 202. The bytes are
used to convey information about the structure of each group.
The numberOfGroups field indicates the number of groups described in the following loop.
The groupId field enables a particular group to be identified. The field shall contain the same
value as is used in the transactionId field of the DII control message that describes the group.
This value will change when an update is made to the DII control message, as described in
5.1.3. All groupIds should be unique within the service.
The groupSize field indicates the total number of blockDataBytes that make up the modules in
the group.
The groupCompatibilityDescriptorLength field indicates the total length in bytes of the
following Group Compatibility structure.
———————
ISO/IEC 13818-6, 7.3, Table 7-4.
ETSI EN 301 192, 8.1.2.
ISO/IEC 13818-6, 6.1.
62298-2  IEC:2005(E) – 17 –
NOTE 1 According to ISO/IEC 13818-6, the compatibilityDescriptorLength is the first field in the DSM-CC
compatibilityDescriptor. The groupCompatibilityDescriptorLength is shown here as a separate field outside of the
GroupCompatibility structure to aid understanding.
NOTE 2 The GroupCompatibility structure is not used by TeleWeb. Transmissions shall set the group
CompatibilityDescriptorLength field to 0× 0000.
The groupInfoLength field defines the number of groupInfoBytes that follow. TeleWeb data
carousels do not support descriptors on the group level. Therefore, the value of the
groupInfoLength must be set to 0× 0000 and there are no groupInfoBytes allowed.
The futureUseLength field defines the length in bytes of the following service info and the
bytes reserved for future use.
The futureUseBytes are reserved for future enhancements.
The serviceInfoLength field defines the number of serviceInfoBytes that follow.
The serviceInfoByte conveys a list of descriptors defining attributes and characteristics of the
service. The coding is given in 5.1.4.
5.1.2.3 DownloadDataBlock message
In a data carousel, the DownloadDataBlock messages contain the blocks of the fragmented
modules (i.e. the files of the TeleWeb service). A DDB message contains a single data block
of a module. The syntax of the message is shown in Table 3. The final column indicates if a
field has a fixed or variable value in the TeleWeb application.
Data fields not described in this section have the same function and coding as their
equivalents in the DII message (5.1.2.1). The first part of the message, the header, is similar
to that of DII and DSI messages. The main difference concerns the transactionId field which
here becomes the downloadId field.
Table 3 – Syntax of the DownloadDataBlock message
Syntax No. of bytes TeleWeb use
DownloadDataMessage() {
protocolDiscriminator 1 Fixed at 0× 11
dsmccType 1
Fixed at 0× 03
messageId 2
Fixed at 0× 1003
downloadId 4 Variable
reserved_1 1
Fixed at 0× FF
adaptationLength 1 Variable
messageLength 2 Variable
dsmccAdaptationHeader() adaptationLength Reserved for future use
moduleId 2 Variable
moduleVersion 1 Variable
reserved_2 1
Fixed at 0× FF
blockNumber 2 Variable
for(i=0; i< blockSize; i++) {
blockDataByte 1 Variable
}
}
– 18 – 62298-2  IEC:2005(E)
The messageId field is fixed at 0× 1003 to identify the message as a DownloadDataBlock
message.
The downloadId field identifies the particular carousel to which the block belongs. It maps to
the downloadId field in the parent DII message.
The reserved_1 and reserved_2 fields shall be set to 0× FF as required by ISO/IEC 13818-6.
The moduleId field identifies the unique module to which this block belongs.
The moduleVersion field identifies the version of the module to which this block belongs.
When a module is updated, the current value shall be incremented modulo 0× 100.
The blockNumber field identifies the position of the block within the module. Block number
zero (0) shall be the first block of a module.
The blockDataBytes convey the data of the block. The blockSize variable is conveyed in the
parent DII message. However, the last block of a module may be smaller in size. A receiver
can calculate the blockNumber value and the size of the last block of a module from the
moduleSize and blockSize information carried in the parent DII message.
5.1.3 Handling updates
The transactionId field located in both DII and DSI messages provides unique identification
and versioning information. The coding of the subfields is described in 5.1.2.1.
As the transactionId functions as a versioning mechanism, ANY change to ANY file, attribute,
module, moduleId or descriptor in the data carousel shall cause the version subfield of the
transactionId in the top-level control message to be incremented and the Update Flag sub-
field to be toggled. The change propagates up through the structure of the carousel as follows.
1) Any change to the contents of a file, but not the attributes of that file , shall cause the
moduleVersion field to be incremented in each DDB message required to transmit the
module containing the file. This change must be reflected in the moduleVersion field in
the module loop of the DII message that includes this module.
2) A field in a DII message can change either as a result of an update to the contents of a
module (in which case its moduleVersion field will have altered according to 1) or
because of a change in the descriptors of a module (leading to modifications to its
moduleInfoBytes). When a field in a DII message changes the version subfield of its
transactionId must be incremented to indicate a new version of the message, and the
Update Flag must be toggled.
3) In the case of a two-layer carousel, a change to a DII message must be reflected in the
corresponding groupId field in the group loop of the DSI message.
4) In the case of a two-layer carousel, since a field in the DSI message has changed the
version subfield of its transactionId must also be incremented, and the Update Flag must
be toggled.
———————
ISO/IEC 13818-6, 7.3, Table 7-4.
ISO/IEC 13818-6, Clause 2.
It is allowed to change the descriptors without changing the module's moduleVersion value. The transactionId
value is, of course, changed as a result. When a revised DII arrives, the receiver can detect whether the
changes affect modules or descriptors by comparing the current moduleVersion values with those received last
time. If a particular moduleVersion value has not altered, all the descriptors for that module have to be
processed in order to establish the changes. If the value has altered, both the contents of the m
...