EIT, Barker Channels and EPG

Content
1 Basics ............................................................................................................................................... 2
1.1 Difference between EIT other and EIT actual.......................................................................... 2
1.2 Difference between EIT p/f and EIT schedule ......................................................................... 2
1.3 Usage of EIT actual vs. EIT other ............................................................................................. 2
1.4 Barker channel usage .............................................................................................................. 3
1.5 Barker Channel and “EPG generator” ..................................................................................... 4
2 EIT handling in Chameleon, and in systems of Chameleons ........................................................... 4
2.1 Chameleon EIT handling basics ............................................................................................... 4
2.2 Pre-requisites for correct EIT handling in Chameleon ............................................................ 4
2.2.1 PSI/SI sharing pre-requisites ........................................................................................... 4
2.2.2 Requirements for the output DVB network .................................................................... 5
2.3 Selection of output EIT structure in the Chameleon ............................................................... 5
2.3.1 Default EIT settings in Chameleon .................................................................................. 5
2.4 How to configure EIT output in Chameleon ............................................................................ 7
2.4.1 EIT actual p/f settings ...................................................................................................... 8
2.4.2 EIT other p/f settings ....................................................................................................... 8
2.4.3 EIT actual schedule settings ............................................................................................ 8
2.4.4 EIT other schedule settings ............................................................................................. 9
3 What about EIT input? .................................................................................................................. 10
3.1 Identifiers for EIT information ............................................................................................... 10
4 Description of EIT management in Chameleon ............................................................................. 10
4.1 Finding the correct EIT event information from the inputs, and add it to the output ......... 10
4.2 Handling of output EIT, and output repetition rates ............................................................ 11
5 EIT management in Tangram ........................................................................................................ 11
5.1 Pre-requisites for correct EIT handling in Tangram............................................................... 11
5.1.1 PSI/SI sharing pre-requisites ......................................................................................... 11
5.1.2 Requirements for the output DVB network .................................................................. 12
1 Basics
There are 4 main EIT parts: EIT actual p/f, EIT other p/f, EIT actual schedule and EIT other schedule.
For the 2 EIT schedule, there are sub-tables for different “lengths”, ranging from 0-3 days to 60-63
days.

All these EIT tables can contribute with information for an EPG.

1.1 Difference between EIT other and EIT actual

EIT actual (both p/f (present/following, or now/next), and schedule) shall contain information about
events for the services in the own transport stream (TS). They should never contain event
information for services in other TS in the same DVB network.

1.2 Difference between EIT p/f and EIT schedule

EIT p/f shall contain event information for the currently running event (program), and for the next
event.

EIT schedule can contain event information for events “coming later” (with the sub tables ranging
from 0-3 day up to 60-63 days.

EIT p/f actual is mandatory for any transmission, and EIT p/f actual information must be transmitted
according to DVB.

EIT p/f other is optional (see more below).

EIT schedule (both p/f and schedule) is optional.

1.3 Usage of EIT actual vs. EIT other

Since EIT actual is “only” carrying event information from the services in the own TS, a receiver that is
tuned to this TS (or transponder, or mux) will only be able to show EPG information for the services
that are present in this TS.

This can be regarded as a draw-back, since a user will have to zap to another channel to be able to
see the EPG for other services. Moreover, it is not the zapping to another channel that will give this
additional EPG information, since you have to zap to a channel coming from another TS (and
normally a user does not really know, or care, from which TS a channel is coming).

A first step to solve this problem is to let the receiver (STB or TV) cache the EPG information, so that
“sooner or later” when you have zapped around and watched channels from all TS in the network,
you will have a complete EPG.
As you can understand, even with this “improvement” by cashing information, the “user experience”
is not optimal.

If you select to transmit both EIT actual and EIT other, you can solve this problem. What you do is
that for each TS out, you transmit event information about all services in the DVB network. Hence,
whichever channel you are looking at (i.e. whichever TS your receiver is tuned to), you have all the
event information for creating the complete EPG.

Solved!

Problem: As your DVB network gets larger, the bit rate needed for the complete set of event
information goes higher. And, you are actually transmitting the same data in all TS out (kind of a
waste of bandwidth…).

This leads us to the next chapter; Barker Channels

Before going into the details of Barker Channels, let’s look at what you can do to reduce the
bandwidth usage without using a Barker Channel.

As per §1.2 above, you can control “how much” EIT information you transmit in an output TS by
enabling/disabling different “lengths”, and by deciding “how often” you are transmitting the
information:
• The enabling/disabling of the EIT schedule (both for actual and other) sub-tables (from 0-3
day and in in “4-days steps” up to 60-63 days) will directly affect the bit rate needed
• For a given set of the sub-tables enabled, by configuring the repetition rates (for each
individual sub-table) you also directly affect the bit rate needed

Here, it is interesting to note that caching event information in a receiver is adequate again.
Normally, event information for events “further away” in time will not change very often. Changes
will appear at date shifts, and possibly if the scheduling is changed (replacing an event etc.). So, if the
receiver can cache the event information, you really do not need to transmit event information for
events “far off in the future” very often, and you can increase the repetition time (reduce the
repetition frequency) for these sub-tables.

1.4 Barker channel usage

As you by now are aware, transmitting all event information for all services in your DVB network in
each TS out (by enabling EIT other p/f and EIT other schedule) is putting bandwidth limitations on
your network.

One way to solve this problem is to use a Barker Channel. A Barker Channel is a transponder/mux
that will carry event information about all services in the DVB network. Hence, if you can “program”
your receiver to always tune to this Barker Channel (e.g. at start-up), you will get the complete set of
EPG information from a single transponder/mux/TS in. And you do not have to transmit all event
information from all services in the DVB network in all outputs!

Some small additional comments about this:

• You still have to transmit the mandatory EIT actual p/f in each output (but the bit rate for this
is small)
• The transponder with the Barker Channel might have some services as well as the complete
“EPG data”. If the Barker Channel is set up correctly, there should be EIT actual (p/f as
mandatory, and EIT actual schedule if this option is selected) for all services carried in the
Barker Channel.
• The event information about services not carried by the Barker Channel transponder/mux/TS
shall be tagged as EIT other (EIT other p/f and the different EIT other schedule). If this is not
the case, the EIT structure does not comply to the DVB specifications, and probably the EPG
will not work.

1.5 Barker Channel and “EPG generator”

All that is stated above for a Barker Channel also applies to an “EPG generator”. If the event
information for your DVB network is coming from an EPG generator (as a TS input, via e.g. IP or ASI),
you have to set up the EIT structure accordingly.

A possible difference will be that the TS from an EPG generator normally does not contain any
services, and hence you would expect that there should be no EIT actual present.

2 EIT handling in Chameleon, and in systems of

Chameleons

2.1 Chameleon EIT handling basics

Generally, all EIT handling in Chameleon remultiplexing, and in Chameleon system remultiplexing for
interconnected Chameleons, is automatic.

EIT, as being part of the PSI/SI structure, will be shared between outputs and between Chameleons.
EIT configuration is handled in Service Management, in the PSI/SI tables menu for the outputs.

2.2 Pre-requisites for correct EIT handling in Chameleon

2.2.1 PSI/SI sharing pre-requisites

If there are several Chameleons with outputs that shall share PSI/SI, these Chameleon has to be
interconnected and “enabled for PSI/SI sharing”:
 • Interconnection via IP, in GN50 via the internal GT11 switch, in GN40 etc. via an external
switch
• Enabled for PSI/SI sharing between Chameleons by the GNSYMUX SW option (system
remultiplexing)
• All Chameleons that shall share PSI/SI must be in the same Headend Group (managed in
HEADEND SYSTEM MANAGEMENT under Settings in the UI)

For a single Chameleon with several outputs:

• Enabled PSI/SI sharing between outputs by the GNMUX (or GNSYMUX) SW option

2.2.2 Requirements for the output DVB network

All outputs to your external access network should have:

• Same Network ID (NID) (see also note below)
• (Same Network name, if used)
• Unique transport stream ID (TSID) for all output TS in the DVB Network
• (Unique Service ID within a transport stream)

Note: If you are using internal transport streams, i.e. an output from a Chameleon that is going to
another Chameleon in the system for sharing services (or that is not used for output to the external
access network), these TS should NOT have the same NID.

2.3 Selection of output EIT structure in the Chameleon

You have to decide what you would like to transmit in terms of EIT data in your outputs, see more in
§1.3.

Different options (for each TS out):

• Only EIT actual p/f out
• EIT actual p/f + EIT actual schedule (different lengths) out (will give event info only for the
“own” services in the TS out)
• Add on EIT other p/f (to get “now and next” for all services in the output DVB Network in the
output TS).
• Add on EIT other schedule (different lengths), will give EIT event for all services in the output
DVB Network in the TS out

And another option:

• Create a Barker Channel output (a single TS out that carries all event information for all
services in the DVB Network). Preferably this should imply that you enable only EIT actual p/f
in all other TS out.

2.3.1 Default EIT settings in Chameleon

The default settings for EIT in Chameleon (in the PSI/SI tables menu in the Outputs part of Service
Management) are:

• EIT actual p/f enabled, repetition rate 2000 ms

• EIT other p/f disabled
• EIT actual schedule 0-3 days enabled, repetition rate 10000 ms
• EIT actual schedule 4-7 days to 60-63 days disabled
• EIT other schedule: all disabled

These default settings will give present/following, and event information for 0 to 3 days for the
services contained in the own TS.
There will be no event information from services in other TS outputs (in the same DVB Network, see
requirements in §2.2.2) in this TS out.
2.4 How to configure EIT output in Chameleon

All output EIT handling is done in the output side of Service Management, in the PSI/SI tables menu.

Here, a screen-shot of the PSI/SI tables menu, with EIT PF actual, EIT PF other, EIT actual schedule,
EIT other schedule. All settings here are the Chameleon default settings.

EIT actual p/f settings

EIT other p/f settings

EIT actual schedule settings

EIT other schedule settings

2.4.1 EIT actual p/f settings

Default: Enabled ON, repetition rate 2000 ms

Disabling EIT actual p/f will remove present/following event information for the services in the own
TS (to comply to DVB specifications, EIT actual p/f should (mandatorily) be enabled.

2.4.2 EIT other p/f settings

Default: Enabled OFF, (repetition rate 10000 ms)

Enabling EIT other p/f will add present/following event information for all the services in the DVB
Network to the own TS (not mandatory).

2.4.3 EIT actual schedule settings

Default: EIT actual schedule 0-3 days enabled, repetition rate 10000 ms. All other (4-7 days to 60-63
days) disabled.
This default setting will enable transmission of event information up to 3 days ahead in time, for the
services contained in the “own” TS.
By enabling more sub-tables, more event information will be transmitted.

2.4.4 EIT other schedule settings

Default: All EIT other schedule disabled.

By enabling EIT other schedule (different sub-tables, depending on the “lengths” needed), event
information from all services in the output DVB network will be added to the own TS.
3 What about EIT input?
Generally for Chameleon, as long as the pre-requisites in §2.2.1 and §2.2.2 are met, all the EIT input
handling is automatic. But, this is still assuming that the EIT from the input sources are correct.

The requirement for the incoming EIT is that everything is signalled correctly, in essence that event
information for services in the own TS are signalled as EIT actual, and EIT event information for
services in other TS are signalled as EIT other.

3.1 Identifiers for EIT information

DVB specifies identifiers for EIT information, to enable correct referencing and handling.
These identifiers are the “DVB triplet”; ONID (Original Network ID), the TSID (Transport Stream ID),
and the SID (Service ID)

IMPORTANT NOTE:
When discussing the EIT identifiers ONID, TSID and SID, all of these refer to the values of these IDs in
the incoming TS, from the source. It has nothing to do with these IDs for the output TS from the
Chameleon.

The consequences of this, for checking EIT for and in Chameleon, are:
• When checking if the incoming EIT is correct, always check the ONID, TSID and SID for the
incoming TS and services (e.g. check the SID in the left, Inputs side of Service Management)
• For the correct EIT output, it does not matter if you change any of the DVB triplet IDs (ONID,
TSID, SID). The handling of the EIT in the Chameleon is still based only on the DVB triplet
information from the incoming TS and services.
• Do NOT use the same DVB triplet for internal transport streams between Chameleons (ASI or
IP)

4 Description of EIT management in Chameleon

4.1 Finding the correct EIT event information from the inputs, and add it to the
output

Given some settings for EIT in Service Management, and given that the pre-requisites are met (see
§2.2.1 and §2.2.2), a Chameleon will:
• For any service in an output, check if there is any EIT event information available in some
input TS
o in any Chameleon that is interconnected in the system, and where the GNSYMUX is
enabled,
o or from some of the inputs in the own Chameleon, given that GNMUX or GNSYMUX
is enabled
 • If it is possible to find EIT event information from some/any input (identified by the DVB
triplet for the incoming services), the Chameleon will parse the EIT event information from
the incoming EIT, and add the EIT event information relevant to the specific service in the
output

4.2 Handling of output EIT, and output repetition rates

The Chameleon will start transmitting EIT whenever all sections of an EIT that should be output are
received.
Once all sections are received, the Chameleon will store the EIT information, and transmit the
different parts according to the repetition rate settings.

The consequences of this functionality are:

• Depending on the repetition rates (and availability) of the EIT event information in the
incoming TS, it might take a while before the Chameleon starts transmitting the (configured)
EITs. Unfortunately this timing is mostly depending on the sources, and it is not really
possible to state any limits for “a while”. Different operators set up their transmissions in
different ways.
• Even if the incoming TS do not carry all EIT event information all the time, the Chameleon
should still be able to store and transmit correct EIT, as long as the relevant EIT has been
received at some instance. (There might be a problem if the EIT p/f is not sent correctly from
the sources, since this information is “the most volatile”. However, this is rather unlikely…)

5 EIT management in Tangram

All information in the previous chapters is valid also for Tangram systems and Tangram modules. The
setting up of correct handling of EIT might be slightly more complicated, but the same principles
apply.

The most important part is to make sure that the pre-requisites are met

5.1 Pre-requisites for correct EIT handling in Tangram

5.1.1 PSI/SI sharing pre-requisites

If there are several Tangram modules with outputs that shall share PSI/SI, these modules have to be
interconnected and “enabled for PSI/SI sharing”:

• IP Interconnection via the internal GT11 switch in GT01

• Enabled for PSI/SI sharing between modules by the GTSYMUX SW option (system
remultiplexing)
 • All modules that shall share PSI/SI must be in the same Headend Group (managed in
HEADEND SYSTEM MANAGEMENT under Settings in the UI)

Note: for systems with several GT01 Tangram chassis, you have to make sure that these Tangrams
and their modules comply to the same pre-requisites; IP interconnection, GTSYMUX and Headend
Group membership

If a single output module is used:

• Enabled PSI/SI sharing between outputs by the GTMUX (or GTSYMUX) SW option

5.1.2 Requirements for the output DVB network

All outputs to your external access network should have:

• Same Network ID (NID) (see also note below)
• (Same Network name, if used)
• Unique transport stream ID (TSID) for all output TS in the DVB Network
• (Unique Service ID within a transport stream)

Note: If you are using internal transport streams, i.e. an output from a Chameleon that is going to
another Chameleon in the system for sharing services (or that is not used for output to the external
access network), these TS should NOT have the same NID.