I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n

ITU-T J.1211
TELECOMMUNICATION (05/2020)
STANDARDIZATION SECTOR
OF ITU

SERIES J: CABLE NETWORKS AND TRANSMISSION

OF TELEVISION, SOUND PROGRAMME AND OTHER
MULTIMEDIA SIGNALS
IP Video Broadcast

Specifications of IP video broadcast (IPVB) for

cable TV networks

Recommendation ITU-T J.1211

Recommendation ITU-T J.1211

Specifications of IP video broadcast (IPVB) for cable TV networks

Summary
In recent years, IP-based video services have developed rapidly in cable (CATV) networks, especially
the highly asymmetric IP-based services with large bandwidth, such as 4K, 8K and VR, whose single
program bandwidth might easily exceed 35Mbps or even up to 100Mbps. This requires a large
downlink bandwidth of transmission channels and poses challenges to existing CATV technologies.
For this scenario, it is necessary to propose a low cost and low complexity solution to meet the
bandwidth requirements of the current asymmetric IP-based video services.
Recommendation ITU-T J.1211 specifies an IPVB technology, which simply adds a one-way IP-based
video broadcast system to the existing low-cost bidirectional CATV networks. The IPVB can greatly
increase the bandwidth of downlink programs, and at the same time, have the characteristics of being
low cost and low complexity. The IPVB in downlink transmits IP-based video streams through
broadcast channels which are identified by multicast IP addresses and UDP port numbers, and
broadcasts all the IP-based video streams through the CATV networks to all subscribers. By
cooperating with the uplink channel provided by the existing bidirectional access networks, it is
capable of providing varieties of IP-based high bit rate video services in CATV networks.

History
Edition Recommendation Approval Study Group Unique ID*
1.0 ITU-T J.1211 2020-05-29 9 11.1002/1000/14282

* To access the Recommendation, type the URL http://handle.itu.int/ in the address field of your web
browser, followed by the Recommendation's unique ID. For example, http://handle.itu.int/11.1002/1000/11
830-en.

Rec. ITU-T J.1211 (05/2020) i

FOREWORD
The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of
telecommunications, information and communication technologies (ICTs). The ITU Telecommunication
Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical,
operating and tariff questions and issuing Recommendations on them with a view to standardizing
telecommunications on a worldwide basis.
The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes
the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics.
The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1.
In some areas of information technology which fall within ITU-T's purview, the necessary standards are
prepared on a collaborative basis with ISO and IEC.

NOTE
In this Recommendation, the expression "Administration" is used for conciseness to indicate both a
telecommunication administration and a recognized operating agency.
Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain
mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the
Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some other
obligatory language such as "must" and the negative equivalents are used to express requirements. The use of
such words does not suggest that compliance with the Recommendation is required of any party.

INTELLECTUAL PROPERTY RIGHTS

ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve
the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or
applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of
the Recommendation development process.
As of the date of approval of this Recommendation, ITU had not received notice of intellectual property,
protected by patents, which may be required to implement this Recommendation. However, implementers are
cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB
patent database at http://www.itu.int/ITU-T/ipr/.

© ITU 2020
All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior
written permission of ITU.

ii Rec. ITU-T J.1211 (05/2020)

Table of Contents
Page
1 Scope ............................................................................................................................ 1
2 References..................................................................................................................... 1
3 Definitions .................................................................................................................... 1
3.1 Terms defined elsewhere ................................................................................ 1
3.2 Terms defined in this Recommendation ......................................................... 1
4 Abbreviations and acronyms ........................................................................................ 2
5 Conventions .................................................................................................................. 2
6 IPVB system ................................................................................................................. 3
6.1 Introduction .................................................................................................... 3
6.2 IPVB headend ................................................................................................. 3
6.3 IPVB terminal ................................................................................................. 4
6.4 Physical layer.................................................................................................. 5
7 Planning of broadcast channel and format of encapsulation in IPVB system .............. 5
7.1 Broadcast channel planning ............................................................................ 5
7.2 Encapsulation of DTV Audio/Video programmes ......................................... 6
8 Broadcast service information in IPVB system ............................................................ 8
8.1 Introduction .................................................................................................... 8
8.2 BSI tables........................................................................................................ 8
8.3 Multicast information table (MIT) ................................................................. 9
8.4 Service name list table (SNLT) ...................................................................... 10
8.5 Area code table (ACT) ................................................................................... 11
8.6 Descriptors of BSI tables ................................................................................ 12

Rec. ITU-T J.1211 (05/2020) iii

Recommendation ITU-T J.1211

Specifications of IP video broadcast (IPVB) for cable TV networks

1 Scope
This Recommendation describes the technique specifications of IPVB systems, including the system
architecture of IPVB, broadcast channel planning of services, coding schemes and the encapsulation
formation of audio and video data, broadcast service information (BSI) tables and functional modules
of IPVB systems. The Recommendation is applicable to the network construction of IPVB systems,
the development of equipment, and the operation and management of IPVB systems.

2 References
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the currently
valid ITU-T Recommendations is regularly published. The reference to a document within this
Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
[ITU-T H.222.0] Recommendation ITU-T H.222.0 (2018) | ISO/IEC 13818-1:2019, Information
technology – Generic coding of moving pictures and associated audio
information: Systems.
[ITU-T J.83] Recommendation ITU-T J.83 (2007), Digital multi-programme systems for
television, sound and data services for cable distribution.
[IEEE 802.3ae] IEEE 802.3ae-2002, IEEE Standard for Information Technology- Local and
Metropolitan Area Networks – Specific Requirements Part 3: Carrier Sense
Multiple Access With Collision Detection (CSMA/CD) Access Method and
Physical Layer Specifications Amendment: Media Access Control (MAC)
Parameters, Physical Layers, and Management Parameters for 10 Gb/S
Operation.

3 Definitions

3.1 Terms defined elsewhere

None.

3.2 Terms defined in this Recommendation

This Recommendation defines the following terms:
3.2.1 broadcast channel: The broadcast channels in this Recommendation refer to the logical
channels labelled with D-class IP addresses and UDP destination port numbers. Usually one channel
corresponds to a digital TV transmission stream or service stream.
3.2.2 IP broadcast: IP broadcast in this Recommendation refers to the implementation of the
broadcast transmission of the baseband stream of IP on the CATV distribution network.
3.2.3 main channel: The main channel in this Recommendation refers to the broadcast channels
delivering the digital TV service index data of IPVB.

Rec. ITU-T J.1211 (05/2020) 1

3.2.4 section: A section is a syntactic structure used for mapping all service information defined
in this Recommendation into ITU-T H.222.0 | ISO/IEC 13818-1 TS packets.
3.2.5 service: A service is a series of programmes which is broadcast in stages according to a time
schedule under the control of the broadcaster.
3.2.6 service information: Service information in this Recommendation describes the data
information such as delivery systems, contents and plans/schedules of broadcast data streams, etc.,
including PSI information of MPEG-2 and independently defined extensions.

4 Abbreviations and acronyms

This Recommendation uses the following abbreviations and acronyms:
ACT Area Code Table
BSI Broadcast Service Information
bslbf bit string, left bit first
CPE Customer Premises Equipment
DTV Digital TV
EPG Electronic Programme Guide
HTML Hyper Text Markup Language
IPVB IP Video Broadcast
MIT Multicast Information Table
MPTS Multi-Program Transport Stream
OTT Over The Top
PID Packet Identifier
rpchof remainder polynomial coefficient, higher order first
SDT Service Description Table
SI Service Information
SNLT Service Name List Table
SPTS Single Program Transport Stream
STB Set-Top Box
TS Transport Stream
UDP User Datagram Protocol
unisbf undersigned integer, most significant bit first
VOD Video On Demand
XML Extensible Markup Language

5 Conventions
In this Recommendation:
The keywords "is required to" indicate a requirement which must be strictly followed and from which
no deviation is permitted if conformance to this document is to be claimed.
The keywords "is recommended" indicate a requirement which is recommended but which is not
absolutely required. Thus, this requirement need not be present to claim conformance.

2 Rec. ITU-T J.1211 (05/2020)

The keywords "is prohibited from" indicate a requirement which must be strictly followed and from
which no deviation is permitted if conformance to this Recommendation is to be claimed.
The keywords "can optionally" indicate an optional requirement which is permissible, without
implying any sense of being recommended. This term is not intended to imply that the vendor's
implementation must provide the option and the feature can be optionally enabled by the network
operator/service provider. Rather, it means the vendor may optionally provide the feature and still
claim conformance with the Recommendation.
In the body of this Recommendation, the words shall, shall not, should and may sometimes appear,
in which case they are to be interpreted, respectively, as is required to, is prohibited from, is
recommended and can optionally. The appearance of such phrases or keywords in an appendix or in
material explicitly marked as informative are to be interpreted as having no normative intent.

6 IPVB system

6.1 Introduction
An IPVB system mainly consists of an IPVB headend and IPVB terminal. The IPVB headend is used
to broadcast the streams and data in the format of UDP multicast packets to all the subscribers through
CATV networks, where multicast IP addresses and UDP destination port numbers in UDP multicast
packets are used to distinguish different programs. The IPVB terminal is generally embedded in the
user terminals. It receives the UDP multicast packets, and selects the required programs according to
the multicast IP addresses and port numbers.
IPVB can either work as a unidirectional system independently to broadcast IP television services or
realize a broadband access by working in combination with a bidirectional transmission system, to
support high quality digital broadcasting service and interactive video and data services, such as
VOD, OTT TV and VR.
In this Recommendation, the broadcast services are transmitted in assigned broadcast channels. Each
broadcast channel is identified by the IP address and UDP destination port number of packets. All
data, including audio and video data of different programmes and service information are packetized
into UDP packets, and broadcast to all subscribers over CATV networks through different broadcast
channels.

6.2 IPVB headend

The IPVB headend is responsible for broadcasting UDP multicast packets to all subscribers over
CATV network systems. It is located at the entry edge of the CATV distribution network. It
implements the functions of convergence, processing, distribution and transmission of IP-based
services data. It distributes various IP service streams to the IP broadcast channels according to the
service control strategies. It is the last data processing stage before the data enters the distribution
network. The functional diagram of an IPVB headend is illustrated in Figure 1.

Figure 1 – The functional diagram of IPVB headend

Rec. ITU-T J.1211 (05/2020) 3

The logical modules of an IPVB headend are defined as follows:
– The IP convergence module: this module receives the service IP streams from several GE
ports, and sends them to the processing module through an internal data bus at no less than
10 Gbit/s.
– The processing module: This module implements the parsing, filtering and re-encapsulating
of packets complying with different protocols, converting unicast address into multicast
address if the stream has a unicast address (including VOD, OTT and other on-demand
streams). And then, the processing module converges these packets and sends them to the
medium adapter module.
1) The packet header process module: If VOD adopts the VOD system based on IPQAM,
but the down streams need to be transmitted in the IPVB downlink broadcast channel,
the packet header process module in the IPVB headend will replace the unicast address
of the received UDP packets header with the assigned multicast IP address and port
number as the destination IP address and port number. Then it sends the revise packet to
the convergence module: if the VOD systems are like OTT systems, the process of VOD
stream packets will be processed by UDP re-encapsulation module of the IPVB headend.
2) The UDP re-encapsulation module: This module will replace the destination IP and MAC
addresses in the downstream TCP packets with the source IP and MAC addresses of the
first original request packet, add the UDP header on it, and adopt the assigned multicast
IP address and port number as the destination IP address and port number, then it sends
the reconstructed packet to the convergence module.
– The medium adapter module: This module translates the UDP packets into the right format
of packets to the network medium in use, and transmits them to the CATV network.
The parameter configuration for IPVB headend:
– On-demand services enable or disable.
– Select one physical port as "the interactive port" which is used for communication with the
on-demand server and IPVB terminal.
– Configure the IP address, subnet mask and gateway of the interactive port.
– Configure the multicast IP address and port number for the main channel to broadcast the
interactive port information to the IPVB terminal.
– For general on-demand services, configure the server IP address range that are used for the
IPVB terminal to judge which packets and sessions are needed to be processed by the IPVB
headend.
– For VOD services that are based on IPQAM, they need to configure the ACT, Frequency-
To-Address conversion table and forwarding rules.

6.3 IPVB terminal

The IPVB terminal is generally embedded in the user terminal. It receives the broadcast IP-based
stream from CATV networks, selects the program or service data requested by one or more user
CPEs, such as IP STB, smart phone, PAD, PC and intelligent TV, by means of recognizing the IP
addresses and UDP port numbers of the corresponding UDP packets. It forwards the selected data to
the final user CPEs within the home network through FE/GE interface. The functional diagram of the
IPVB terminal is illustrated in Figure 2.

4 Rec. ITU-T J.1211 (05/2020)

Figure 2 – The functional diagram of IPVB terminal

The major logical modules of an IPVB terminal are defined as follows:

– The UDP packet filter module: This module supports parallel-selection operation of more
than 15 broadcast channels. The IPVB terminal supports as many as five user CPEs in the
home network to select data from the same or different broadcast channels simultaneously,
and allows each CPE to select the data from at least three broadcast channels.
– The packet format conversion module: This module supports the conversion from multicast
packet to unicast packet for keeping from bandwidth waste in the home LAN. The conversion
module obtains the IP addresses of the user CPE from the control logic module before
implementing the conversion.
The parameter configuration for IPVB terminal:
The IPVB terminal is configured according to the configuration of the IPVB headend, which needs
to receive interactive port information, server IP address range, ACT, Frequency-To-Address
conversion table, etc.

6.4 Physical layer

Since the IPVB system is typically used in CATV networks, the transport medium is mainly optical
fibre or coaxial cable. The physical layer coding method is not mandatory in this Recommendation.
When the transport medium is optical fibre, the physical layer may comply with 10G Base-R in
[IEEE802.3ae]. When the transport medium is coaxial, the physical layer may comply with
[ITU-T J.83].

7 Planning of broadcast channel and format of encapsulation in IPVB system

7.1 Broadcast channel planning

Based on the carried service contents, the broadcast channels of IPVB are classified into four types:
main channel, authorization channel, DTV SI Channel and program channel, as specified in Table 1.

Rec. ITU-T J.1211 (05/2020) 5

Table 1 – Broadcast channel planning

Channel name Description Requirement Service contents

Main Channel For the essential tables Mandatory MIT, SNLT, and ACT
Authorization For CAT/EMM
Optional CAT/EMM
Channel authorization information
DTV SI Channel For DTV EPG, etc. Optional TS-based EPG information
Audio/Video programmes Broadcasting programs, VOD,
Program Channel Mandatory
and data OTT TV, etc.

7.1.1 Main channel

The main channel is an IP stream channel with specific multicast IP address and UDP destination
port number. The UDP packets transmitted in the main channel describes the broadcast channel
information, service version number, date and other key information of digital TV programmes and
other services in the IPVB system. After the user end (including IP STB, smart phone, smart TV,
PAD, PC, etc) starting up, it first obtains and analyzes the data of the main channel, and then obtains
the data of other service channels based on the main channel information.
The content carried in the main channel shall include the multicast information table (MIT),
optionally the service name list table (SNLT), and the area code table (ACT).
7.1.2 Multicast information table (MIT)
The MIT mainly describes the multicast IP addresses, UDP port numbers and encapsulation format
of all services in the IPVB system.

7.1.3 Service name list table (SNLT)

The SNLT mainly describes the program names, program providers and other program information.

7.1.4 Area code table (ACT)

The ACT describes the area codes of the access location of user terminals.
These tables are periodically broadcast to IPVB terminals through the main channel. The
recommended repeating period is less than 500 ms.
As soon as user terminals are powered on, they will first receive the MIT, SNLT and ACT. Then,
they will obtain the multicast addresses, UDP port numbers and encapsulation formats of the services
by parsing the MIT, obtain service names from the SNLT, and they can select corresponding services
according to the local area code in the ACT.

7.2 Encapsulation of DTV Audio/Video programmes

This part describes the specifications of the encapsulation of DTV audio/video programme data in
IPVB systems.
7.2.1 Introduction
In IPVB systems, audio and video data of digital video broadcast shall be encapsulated into UDP
packets first, and then into IPv4 or IPv6 packets, where the IP destination addresses assigned shall be
assigned with multicast IP addresses. Different broadcast channels are identified with different IP
destination addresses or different UDP destination port numbers. Above the UDP layer, the audio and
video data could be encapsulated into MPEG transport stream (TS) packets in accordance with
[ITU-T H.222.0]. Other formats are allowed too.

6 Rec. ITU-T J.1211 (05/2020)

7.2.2 Encapsulation of TS packets into IP packets
In this Recommendation, the maximum length of Ethernet payload is 1500 bytes, and the mapping of
TS packets shall start from the first byte of the field of UDP payload, so a single UDP payload
accommodates at least one but at most seven complete 188-byte TS packets, and the largest payload
length of a UDP packet is 1887=1316 bytes.
The format for encapsulating TS packets into IP packets is shown in Figure 3.

Figure 3 – The format of encapsulating TS packets into UDP/IP packets

7.2.3 Encapsulation of non-TS into IP packets

In addition to TS packets, the audio and videos data in non-TS packets (such as MP4, AVI, MOV,
and other flow media containers) are also allowed to be encapsulated into the UDP/IP packets
according to the encapsulation format shown in Figure 4. The maximum length of UDP payloads is
1472 bytes in the situation of IPv4, whereas it is1452 bytes in the situation of IPv6.

Rec. ITU-T J.1211 (05/2020) 7

Figure 4 – The format of encapsulating non-TS packets into UDP/IP packets

8 Broadcast service information in IPVB system

8.1 Introduction
The IPVB defines three BSI tables to describe the broadcast channel information and supplement
information. These three BSI tables are encapsulated into TS packets in accordance with
[ITU-T H.222.0] and then broadcast in the main channel in the format of UDP.

8.2 BSI tables

BSI tables include the multicast information table (MIT), service name list table (SNLT), and the area
code table (ACT). The three tables are all delivered through the main channel. The PID allocations
of the BSI tables are given in Table 2.

Table 2 – PID allocation of BSI tables

Table PID value
MIT (multicast information table) 0x000A
SNLT (service name list table) 0x000D
ACT (area code table) 0x000C

The allocations of table_id of BSI tables are presented in Table 3.

Table 3 – Allocation of table_id

Table_id Table Maximum section length (byte)
0xAE MIT 1024
0xAF SNLT 1024
0xED ACT 1024

8 Rec. ITU-T J.1211 (05/2020)

8.3 Multicast information table (MIT)
The MIT describes the IP destination addresses and UDP destination port numbers of each program
or service in broadcast channels, which are used for the user terminals to search for programs. The
MIT shall be segmented into sections in the syntax structure as given in Table 4, and encapsulated
into TS packet(s). The PID value of MIT TS packets shall be 0x000A and the table_id value of MIT
sections shall be 0xAE. The maximum length of MIT section is 1024 bytes.
Sub-table of MIT: A sub-table of MIT is a collection of sections with the same table_id and
version_number.
The syntax of MIT section is given in Table 4.

Table 4 – MIT section

Syntax bit (s) Mnemonic symbol
multicast_information_section
{
table_id 8 uimsbf
section_syntax_indicator 1 bslbf
reserved 1 bslbf
reserved 2 bslbf
section_length 12 uimsbf
reserved 2 bslbf
version_number 5 uimsbf
current_next_indicator 1 bslbf
section_number 8 uimsbf
last_section_number 8 uimsbf
reserved 4 bslbf
descriptors_length 12 uimsbf
for(int i=0;i<N;i++){
descriptor()
}
CRC 32 rpchof
}
The semantics of the fields in the MIT section are defined as follows:
table_id: This 8-bit field specifying the table identification shall be set to 0xAE.
section_syntax_indicator: The 1-bit field shall be set to "1" in this Recommendation.
section_length: This is a 12-bit unsigned integer with the first two bits of "00". It indicates the section
length starting from the byte immediately after the section_length field to the end of MIT section,
including the CRC field. The maximum section length is 1021 bytes, accordingly, the complete length
of MIT section is less than 1024 bytes.
version_number: This is a 5-bit unsigned integer. It indicates the version number of the sub-table of
MIT. The version_number shall be incremented by 1, whenever a change of the information carried
in the sub-table occurs. Until the value reaches 31, it resets to 0. When the current_next_indicator is
set to "1", the version_number represents the version number of the currently used sub-table. When
the current_next_indicator is set to "0", the version_number represents the version number of the next
used sub-table.
current_next_indicator: When current_next_indicator is set to "1", it indicates that the current sub-
table is in use; when current_next_indicator is set to "0", it indicates that the sub-table is not yet
currently used, but shall be the next table to be used.

Rec. ITU-T J.1211 (05/2020) 9

section_number: This is an 8-bit field. It indicates the number of the section. The section number of
the first section in the sub-table shall be set to "0x00". The value of section_number increments by
"1" for each one more added section.
last_section_number: This 8-bit field indicates the section number of the last section in the belonged
sub-table，which is the largest value of section_number.
descriptors_length: The descriptor length is a 12-bit field specifying the total number of bytes of the
data portion of the descriptor following the byte defining the value of this field.
CRC: This 32-bit field contains the CRC value. The calculation of the CRC value shall be in
accordance with [ITU-T H.222.0].

8.4 Service name list table (SNLT)

The SNLT is optional and mainly describes the names of video programes, and other supplementary
information, such as names of service providers. The SNLT shall be segmented into one or more
sections in the syntax structure given in Table 5. Any sections forming part of an SNLT shall be
mapped in TS packets with the PID value of 0x000D. All SNLT sections shall be specified with the
table_id value of 0xAF. The maximum length of an SNLT section is 1024 bytes.
Sub-table of SNLT: A sub-table of SNLT is a collection of sections with the same table_id, list_id
and version_number.
The syntax of an SNLT section is given in Table 5.

Table 5 – SNLT section

Syntax Bit(s) Mnemonic symbol
service_name_list_section
{
table_id 8 uimsbf
section_syntax_indicator 1 bslbf
reserved_future_use 1 bslbf
reserved 2 bslbf
section_length 12 uimsbf
list_id 16 uimsbf
reserved 2 bslbf
version_number 5 uimsbf
current_next_indicator 1 bslbf
section_number 8 uimsbf
last_section_number 8 uimsbf
reserved_future_use 8 bslbf
for(int i=0;i<N;i++){
transport_stream_id 16 uimsbf
service_id 16 uimsbf
reserved 4 bslbf
descriptors_loop_length 12 uimsbf
for(int i=0;i<N;i++){
descriptor()
}
}
CRC 32 rpchof
}
The semantics of the fields in the SNLT section are defined as follows:
table_id: This 8-bit field of the SNLT section shall be set to 0xAF.

10 Rec. ITU-T J.1211 (05/2020)

section_syntax_indicator: The 1-bit field shall be set to "1" in this Recommendation.
section_length: This is a 12-bit unsigned integer with the first two bits set to "00". It indicates the
section length starting from the byte immediately after the section_length field to the end of the SNLT
section, including the CRC field. The maximum section length is 1021 bytes, accordingly, the
complete section length of the SNLT section is less than 1024 bytes.
list_id: This is a 16-bit field for identifying a special group of channels.
version_number: This is a 5-bit unsigned integer, indicating the version number of the sub-table of
the SNLT. The value of version_number increments by "1", in case of any change that occurs to the
sub-table. Until the value reaches 31, it resets to 0. When the current_next_indicator is set to "1", the
version_number represents the version number of the currently used sub-table. When the
current_next_indicator is set to "0", the version_number represents the version number of the next
used sub-table.
current_next_indicator: When current_next_indicator is set to "1", it indicates that the current sub-
table is in use; when it is set to "0", it indicates that the sub-table is not yet currently used, but shall
be the next table to be used.
section_number: This is an 8-bit field. It indicates the number of the section. The section number of
the first section in the sub-table shall be set to "0x00". The value of section_number increments by
"1" for each one more added section.
last_section_number: This 8-bit field indicates the section number of the last section in the belonged
sub-table, and it is the largest section_number.
Layer 1 for-loop: This loop identifies each program globally with transport_stream_id and
service_id.
Layer 2 for-loop: This loop includes the information descriptions of the corresponding program,
including the program name, program provider, etc.
CRC: This 32-bit field contains the CRC value, the calculation of the CRC value shall be in
accordance with [ITU-T H.222.0].

8.5 Area code table (ACT)

The ACT is optional; it mainly describes the area codes of the access location of service clients. The
ACT sections shall be mapped into TS packets with a PID value of 0x000C. The table_id value of
ACT sections shall be set to 0xED, and the maximum section length is 1024 bytes.
The syntax of ACT is given in Table 6.

Table 6 – ACT section

Syntax bit (s) Mnemonic symbol
AreaCode_section
{
table_id 8 uimsbf
section_syntax_indicator 1 bslbf
reserved 3 bslbf
section_length 12 uimsbf
areacode_value 32 uimsbf
}
The semantics of the fields in the ACT section are defined as follows:
table_id: The 8-bit table_id of ACT sections shall be set to 0xED.
section_syntax_indicator: The 1-bit field shall be set to "1" in this Recommendation.

Rec. ITU-T J.1211 (05/2020) 11

section_length: This is a 12-bit unsigned integer with the first two bits set to "00". It indicates the
section length starting from the byte immediately after the section_length field to the end of ACT
section, and the maximum section length is 1021 bytes. Accordingly, the complete ACT section
length is less than 1024 bytes.
areacode_value: This is a 32-bit field. It is recommended that each one-byte field indicates the area
code of one level, for example, each byte of its four bytes from the top to the bottom represent:
Province (State), City, District and Street. The area code of a community of CH-1211 Geneva 20 –
Switzerland shall be defined as 0x00-01-01-02.

8.6 Descriptors of BSI tables

The descriptors of BSI tables defined in this Recommendation are listed in Table 7, where the values
of descriptor_tag are given, and the BSI tables where these descriptors are most possibly applicable
are marked.

Table 7 – The descriptors of BSI tables

descriptor descriptor_tag MIT SNLT
Info_service_descriptor 0x48 - *
udp_service_list_descriptor 0xAE * -
udp_specific_list_descriptor 0xAF * -
udp_ts_list_descriptor 0xAC * -
NOTE – "-" means not applicable, and "*" means applicable.

8.6.1 Info_service_descriptor
The info_service_descriptor contains basic description of services, such as service type, service name,
service provider, etc. The syntax of info_service_descriptor is given in Table 8.

Table 8 – info_service_descriptor
Syntax Bit(s) Mnemonic symbol
Info_service_descriptor ()
{
descriptor_tag 8 uimsbf
descriptor_length 8 uimsbf
service_type 8 uimsbf
service_provider_name_length 8 uimsbf
for (i=0;i<N;i++){
char 8 uimsbf
}
service_name_length 8 uimsbf
for(i=0;i<N;i++){
char 8 uimsbf
}
}
The semantics of the main fields in the info_service_descriptor are defined as follows:
descriptor_tag: The descriptor_tag of info_service_descriptor shall be set to 0x48.
descriptor_length: This is an 8-bit field, indicating the number of bytes from the byte immediately
after the descriptor_length field to the last byte of the descriptor.

12 Rec. ITU-T J.1211 (05/2020)

service_type: This is an 8-bit field indicating the type of the service. It shall be coded according to
Table 9.

Table 9 – service type coding

Service_type Description
0x00 Not defined
0x01 Digital television service
0x02 Digital audio service
0x03 – 0xFF Not defined
service_provider_name_length: This 8-bit field indicates the number of bytes that follow the
service_provider_name_length field for describing characters of the name of the service provider.
char: This is an 8-bit field. A string of char fields indicate the name of the service provider or service.
service_name_length: This 8-bit field indicates the number of bytes that follow the
service_name_length field for describing characters of the name of the service.
8.6.2 udp_service_list_descriptor
This is a UDP descriptor. It is mainly used to describe the multicast IP address and UDP port number
of TS packets where the audio and video programmes are located. The syntax of
udp_service_list_descriptor is given in Table 10.

Table 10 – udp_service_list_descriptor
Syntax Bit(s) Mnemonic symbol
udp_service_list_descriptor ()
{
descriptor_tag 8 uimsbf
descriptor_length 8 uimsbf
for (i=0;i<N;i++){
transport_stream_id 16 uimsbf
service_id 16 uimsbf
udp_ipaddress 32(IPv4) uimsbf
128(IPv6) uimsbf
udp_port 16 uimsbf
}
}
The semantics of the fields in the udp_service_list_descriptor are defined as follows:
descriptor_tag: The descriptor_tag of udp_service_list_descriptor shall be set to 0xAE.
descriptor_length: This is an 8-bit field, indicating the number of bytes from the byte immediately
after the descriptor_length field to the last byte of the descriptor.
transport_stream_id: This 16-bit field uniquely identifies the TS stream where the announcement
resides.
service_id: This 16-bit field uniquely identifies the service where the announcement resides.
udp_ipaddress: In IPv4, it is a 32-bit field that indicates the multicast IP destination address allocated
to the current service; In IPv6, it is a 128-bit field that indicates the multicast IP destination address
allocated to the current service.
udp_port: This 16-bit field indicates the UDP port number allocated to the current service.

Rec. ITU-T J.1211 (05/2020) 13

8.6.3 udp_specific_list_descriptor
This is used for describing the IP address and UDP port number of specific TS packets, such as the
main channels, the upgrading streams, global EPG, etc., as shown in Table 11.

Table 11 – udp_specific_list_descriptor
Syntax bit(s) Mnemonic symbol
udp_specific_list_descriptor ()
{
descriptor_tag 8 uimsbf
descriptor_length 8 uimsbf
for (i=0;i<N;i++){
info_type 8 uimsbf
data_format 8 uimsbf
udp_ipaddress 32(IPv4) uimsbf
128(IPv6) uimsbf
udp_port 16 uimsbf
}
}
The semantics of the fields in the udp_specific_list_descriptor are defined as follows:
descriptor_tag: This 8-bit field of udp_specific_list_descriptor shall be set to 0xAF.
descriptor_length: This 8-bit field, indicates the length of udp_specific_list_descriptor from the byte
immediately after the descriptor_length field to the end of the descriptor.
info_type: This is an 8-bit field. The values of info_type are listed in Table 12.
data_format: This 8-bit field indicates the data format of the service type currently indicated in the
info_type field. The values are listed in Table 13.
udp_ipaddress: In IPv4, it is a 32-bit field that indicates the multicast IP destination address allocated
to the current service; In IPv6, it is a 128-bit field that indicates the multicast IP destination address
allocated to the current service.
udp_port: This 16-bit field indicates the UDP port number allocated to the current service.

Table 12 – Values of info_type of different services

Service Value of info_type Description
0x00～0x0F Reserved
EPG 0x10 Unique identification of EPG
Unified identification of all picture
Advertisement 0x11 advertising, including power on,
handover, main menu, etc.
Government information 0x12 Unique identification of the
government information service.
Stock 0x13 Unique identification of stock service
CAT/EMM 0x14 The EMM information of CA.
Upgrading stream 0x15 Upgrading stream channel
0x16～0xFE Defined by users
0xFF Reserved

14 Rec. ITU-T J.1211 (05/2020)

Table 13 – Values of data_format
Data format Value Description
0x0 Reserved
XML 0x1 The data is in XML format
HTML 0x2 The data is in HTML format
TS 0x3 The data is in TS format

8.6.4 udp_ts_list_descriptor
The udp_ts_list_descriptor describes the multicast IP addresses and port numbers of the audio/video
(such as MPTS or SPTS) broadcast channels, as shown in Table 14.

Table 14 – udp_ts_list descriptor

Syntax Bit(s) Mnemonic symbol
udp_ts_list_descriptor ()
{
descriptor_tag 8 uimsbf
descriptor_length 8 uimsbf
for (i=0;i<N;i++){
transport_stream_id 16 uimsbf
udp_ipaddress 32(IPv4) uimsbf
128(IPv6) uimsbf
udp_port 16 uimsbf
}
}
The semantics of the fields in the udp_ts_list_descriptor are defined as follows:
descriptor_tag: This 8-bit descriptor-tag of udp_ts_list_descriptor shall be set to 0xAC.
descriptor_length: This 8-bit field, indicates the length of udp_ts_list_descriptor from the byte
immediately after the descriptor_length field to the end of the descriptor.
transport_stream_id: This 16-bit field uniquely identifies the TS stream where the announcement
resides.
udp_ipaddress: In IPv4, it is a 32-bit field that indicates the multicast IP destination address allocated
to the current service; in IPv6, it is a 128-bit field that indicates the multicast IP destination address
allocated to the current service.
udp_port: This 16-bit field indicates the UDP port number allocated to the current service.

Rec. ITU-T J.1211 (05/2020) 15

SERIES OF ITU-T RECOMMENDATIONS

Series A Organization of the work of ITU-T

Series D Tariff and accounting principles and international telecommunication/ICT economic and
policy issues

Series E Overall network operation, telephone service, service operation and human factors

Series F Non-telephone telecommunication services

Series G Transmission systems and media, digital systems and networks

Series H Audiovisual and multimedia systems

Series I Integrated services digital network

Series J Cable networks and transmission of television, sound programme and other
multimedia signals

Series K Protection against interference

Series L Environment and ICTs, climate change, e-waste, energy efficiency; construction, installation
and protection of cables and other elements of outside plant

Series M Telecommunication management, including TMN and network maintenance

Series N Maintenance: international sound programme and television transmission circuits

Series O Specifications of measuring equipment

Series P Telephone transmission quality, telephone installations, local line networks

Series Q Switching and signalling, and associated measurements and tests

Series R Telegraph transmission

Series S Telegraph services terminal equipment

Series T Terminals for telematic services

Series U Telegraph switching

Series V Data communication over the telephone network

Series X Data networks, open system communications and security

Series Y Global information infrastructure, Internet protocol aspects, next-generation networks,

Internet of Things and smart cities

Series Z Languages and general software aspects for telecommunication systems

Printed in Switzerland
Geneva, 2020