The tables we have seen so far provide the basic functions that a network operator needs to make a digital TV service work. It’s possible to do some more advanced things, however, that may be useful in some cases. The most interesting of these from an SI perspective is the ability to force a receiver to change channels, either unconditionally or based on a set of criteria that are specified by the network operator. While this may not seem very useful, it can enable a broadcaster to provide different functions based on language settings in the receiver, geographical location, demographics or any one of a number of other features.
The table that makes this possible is called the Directed Channel Change Table (DCCT). This is an optional table, and not every receiver will support it. This table has the following format:
Syntax | No. of bits | Format |
---|---|---|
directed_channel_change_table_section () { | ||
table_ID | 8 | 0xD3 |
section_syntax_indicator | 1 | ‘1’ |
private_indicator | 1 | ‘1’ |
reserved | 2 | ’11’ |
section_length | 12 | uimsbf |
dcc_subtype | 8 | 0x00 |
dcc_id | 8 | uimsbf |
reserved | 2 | ’11’ |
version_number | 5 | uimsbf |
current_next_indicator | 1 | ‘1’ |
section_number | 8 | 0x00 |
last_section_number | 8 | 0x00 |
protocol_version | 8 | uimsbf |
dcc_test_count | 8 | uimsbf |
for (i = 0; i < dcc_test_count; i++) { | ||
dcc_context | 1 | uimsbf |
reserved | 3 | ‘111’ |
dcc_ from_major_channel_number | 10 | uimsbf |
dcc_from_minor_channel_number | 10 | uimsbf |
reserved | 4 | ‘1111’ |
dcc_to_major_channel_number | 10 | uimsbf |
dcc_to_minor_channel_number | 10 | uimsbf |
dcc_start_time | 32 | uimsbf |
dcc_ end_time | 32 | uimsbf |
dcc_term_count | 8 | uimsbf |
for (j = 0; j < dcc_term_count; j++) { | ||
dcc_selection_type | 8 | uimsbf |
dcc_selection_id | 64 | uimsbf |
reserved | 6 | ‘111111’ |
dcc_term_descriptors_length | 10 | uimsbf |
for (k = 0; k < N; k++) { | ||
dcc_term_descriptor() | uimsbf | |
} | ||
} | ||
reserved | 6 | ‘111111’ |
dcc_test_descriptors_length | 10 | uimsbf |
for (j = 0; j < N; j++) { | ||
dcc_test_descriptor() | ||
} | ||
} | ||
reserved | 6 | ‘111111’ |
dcc_additional_descriptors_length | 10 | uimsbf |
for (i = 0; i < N; i++) { | ||
dcc_additional_descriptor() | ||
} | ||
CRC_32 | 32 | rpchof |
} |
Each entry in the DCCT is a test that decides whether a receiver should change from the source channel to the destination channel.
These tests can be time-limited, so that a channel change is active for a fixed period (e.g. for the length of one event). This allows the network operator to target specific receivers during specific shows, and to show different content in those cases. One example could be a football game – viewers in one area could watch one game featuring their local team, while viewers in another area could be automatically redirected to a different channel showing a game featuring the team local to their area. After the game is over, the redirection is automatically cancelled because it is timed to last the length of the game.
The dcc_context
field tells the receiver how it should handle a channel change, should it need to make one. A value of zero means that the redirect is temporary, and that if the DCCT tells it to return to the original channel at a later time (or if the user changes channel) then the redirection is cancelled – in this case, the new channel has the same channel number as the original (redirected) channel. A value of 1 for this field tells the receiver that the redirection is permanent, and the new channel is a completely different channel (with a completely different channel number) from the original channel.
We won’t look at the tests that can be performed in any detail here, but this list should give you an idea of the kind of tests that can be performed:
- Unconditional redirection
- Unconditional return to original channel
- Inclusion/exclusion based on postal code
- Inclusion/exclusion based on location (not based on postal code)
- Inclusion/exclusion based on genre
- Inclusion/exclusion based on demographic
- Rating blocked
More information about how these tests operate, and a detailed look at how they can be specified, is available in section 6.7 of the ATSC PSIP specification (ATSC document number A/65B).
If the standard values for genres and locations defined in the ATSC PSIP standard aren’t enough, a broadcaster can extend these by broadcasting the DCC Selection Code Table. This carries additional data that can be used by the receiver in conjunction with the DCCT when checking to see whether a particular test condition is met. We won’t look at that table in any detail here – more information can be found in section 6.8 of the ATSC PSIP specification.