Ethernet WAN Port for Routed Multicast

Date: April 2008

Version: v1.0

Abstract: This Application Note provides technical information on multicast video and how this relates to
the various devices in the Thomson Gateway family. First, we provide some background
information on multicast video. Next, a tested and proven scenario shows how to integrate the
Thomson Gateway in a multicast network. In the described scenario, the Thomson Gateway
supports a routed Internet connection using a PVC and routed multicast traffic using an Ethernet
WAN port. We present the mechanisms that are used to set up the scenario, the configuration of
the Thomson Gateway using CLI commands and an illustration of the resulting configuration.

Applicability: This Application Note is relevant to all Thomson Gateway devices that support Flexiport with a
single PVC and IGMP proxying:
 Flexiport with a single PVC is supported since R5.3.2.
 IGMP proxying is supported since R5.4.
The scenario presented has been tested on:
 The THOMSON ST780 (Wireless) R6.2.16.3.

Updates: THOMSON continuously develops new solutions, but is also committed to improving its
existing products.
For more information on THOMSON's latest technological innovations, documents and
software releases, visit us at http://www.thomson-broadband.com
Chapter 1

1 Introduction to Multicast Video

Multicast video
From an end user’s point of view, multicast video over IP is similar to broadcast TV:
 The video server sends a number of continuous digitized and packetized video streams into the network.
Each video stream has its own multicast group address. The various multicast group addresses can be
compared to the channel frequencies for broadcast TV. A video display application can become a
member of a multicast group, and thus receives a particular video stream. This is just like tuning to the
frequency of the channel you would like to watch for broadcast TV.
Differences between multicast video over IP and broadcast TV exist in network and traffic features:
 While broadcast TV channels are broadcast at all times to all subscribers, a multicast video stream is only
forwarded on the links that lead to the multicast group members.
 While broadcast TV sets tune in locally to a particular channel, a multicast client announces its
membership to a particular multicast group by means of IGMP signalling.
Differences between multicast video and unicast video are:
 While a unicast video stream is dedicated to a single client, a multicast video stream is shared by many
clients. A multicast stream is only put once on a logical link that leads to the multicast group members.
As a result, a multicast video stream only uses a fraction of the bandwidth used by a large number of
duplicated unicast video streams.
 While unicast video streams can use both TCP and UDP as transport protocol, multicast streams can only
use UDP.
 While a unicast video stream starts on request of the video client, multicast video streams are always on.
The multicast video clients join the group at a certain moment in time.

Multicast group
A multicast group consists of a number of devices that share a multicast group address for communication.
The information is sent no more than once on each link.
The devices are:
 Server(s): a multicast server sends multicast streams, each with a “pre-defined” multicast group
address.
 Routers: a multicast router receives the multicast streams. The router forwards each multicast stream to
its multicast peers that are member of the corresponding multicast group. This requires that the multicast
peers have announced to which multicast groups they belong by means of IGMP.
 Clients: multicast clients receive multicast streams to which they subscribed themselves and decode the
data to display them to the end users.

1 E-DOC-CTC-20080401-0010 v1.0
 Chapter 2

2 Mechanisms to Support Multicast Video

Introduction
Several mechanisms can be used by Thomson Gateway devices to support multicast video:
 Port-to-PVC mapping.
 Flexiport mechanism.
 Internet Group Management Protocol (IGMP) proxying and IGMP snooping.
The mechanisms that are used to set up the scenario described in this document are the Flexiport mechanism
and IGMP proxying. These mechanisms are shortly described in following subsections.

2.1 Flexiport Mechanism

2.1.1 Why Do We Need Flexiport?

What was missing?

Before the introduction of Flexiport, port-to-PVC mapping was the solution for triple play configurations.
Using port-to-PVC mapping, the Thomson Gateway classifies Ethernet frames based on the receiving local
interface. Per local interface, it is configured to which Permanent Virtual Circuit (PVC) the frames must be
forwarded. This implies that:
 The configuration can not be altered without having to restart the device.
 It is important that the correct devices are connected to the correct local interfaces. The chance of errors
is big, resulting in help desk calls and so on.
 Once a port-to-PVC map is created, forwarding is limited to bridging in all groups except the default
group. Routing and bridging in the default group is not feasible since routing with NAPT requires
multiple physical interfaces.

Advantages of Flexiport
The Flexiport mechanism has following advantages:
 Pre-defined LAN devices can be recognized on-the-fly and be mapped to the PVC offering the services
that are needed. For example, a certain type of STB can be recognized and automatically linked with the
PVC towards the video network - no matter which Ethernet port they are plugged in to. This is done by
placing the MAC address of the device in a VLAN which has the proper PVC mapped to it. Other devices
that are not recognized are still routed over the same default PVC.
 Multicast traffic is sent to the STB port only, which is similar to IGMP snooping. When connecting another
device to the STB port, it will be routed again.
 Wireless ports and WDS ports can also be configured as Flexiport. This can be used to overcome larger
distances without the hassle of cables. When running voice or video services over wireless it is
recommended to use WMM (WiFi MultiMedia). This feature ensures some kind of Quality of Service.

E-DOC-CTC-20080401-0010 v1.0
2
Chapter 2

2.1.2 Flexiport Concept

Introduction
Following illustration shows the concept of the Flexiport mechanism:

Ethernet port1

Internet

Ethernet port 2
BRAS

NATed data traffic

Ethernet port 3

Bridged video traffic

Ethernet port 4

DHCP Server
Video Server

Video Network

Concept
The STB is recognized as soon as it is plugged into the Thomson Gateway. This is done in seven steps:
1 The Thomson Gateway is up and running, PCs are surfing the Internet through one PVC.
2 The STB is added to one of the ports of the Thomson Gateway and sends out a DHCP discover message.
3 The DHCP relay identifies the STB by its Vendor Class Identifier or MAC address and moves the STB’s
MAC address into a second VLAN.
4 The STB re-sends the DHCP discover message, but now as member of the second VLAN.
5 The STB now receives an IP address from the video DHCP server and can start receiving video.
6 The STB’s MAC address is saved, and the next time the Thomson Gateway reboots, it remembers to
which VLAN the STB belongs.
7 When the STB reboots, it re-sends a DHCP discover message and restarts the procedure from step 4.
The Flexiport mechanism can also be used for wired and wireless IP phones. This way, the data
from the IP phone is bridged to the Voice PVC while other wireless devices can still surf the web
over the default PVC.

3 E-DOC-CTC-20080401-0010 v1.0
 Chapter 2

2.1.3 Configuration of Flexiport

Introduction
The Flexiport mechanism combines several features of the Thomson Gateway, such as VLANs, DHCP,
dynamic VLANs and scripts. In this section, we shortly describe the configuration of some Flexiport-related
features. For the complete configuration of the Flexiport mechanism, we refer to the description of the
scenario.

DHCP rules
A device can be identified based on its MAC address or Vendor Class Identifier (VCI), which are sent out with
the DHCP request of the device. The DHCP relay handles received DHCP requests and recognizes devices by
the use of DHCP rules.
Configure DHCP rules as follows:
 MAC address:

=>:dhcp rule add name=STB type=mac mac=00:0d:56:01:32:fa

=>:dhcp rule add name=notSTB type=mac mac=!00:0d:56:01:32:fa

 VCI code:

=>:dhcp rule add name=VOIP type=vci vci=ST2030

=>:dhcp rule add name=notVOIP type=vci vci=!ST2030

An exclamation mark (“!”) is used to indicate that the device’s MAC address or VCI must differ from
the specified value.

Partial string match

Since Release 6.1, it is possible to use a partial string match in the DHCP rules. This can be done for both MAC
address and VCI code. Each of them uses a specific notation.
Configure DHCP rules with partial string match as follows:
 MAC address: here, we use an asterisk (“*”) as wild card. Following rule recognizes any device with a
MAC address starting with 00:0f:1f as a STB:

=>:dhcp rule add name=STB type=mac mac=00:0f:1f:*:*:*

 VCI code: here, we only put part of the VCI code in the rule and add the option match=as_substring.
Following rule recognizes any device with ST20 in its VCI as a VoIP device, e.g. devices with VCI ST2030
or ST2020:

=>:dhcp rule add name=VOIP type=vci vci=ST20 match=as_substring

E-DOC-CTC-20080401-0010 v1.0
4
Chapter 2

Assigning DHCP rules

The DHCP relay checks a DHCP rule, if it is assigned to a DHCP relay forwarding entry as follows:

=>:dhcp relay ruleadd name=video_to_DHCP rulename=STB

To assign more than one DHCP rule to a single forwarding entry, keys are used:
 AND key: the AND key indicates that a rule applies if all conditions are fulfilled.

=>:dhcp relay ruleadd name=LocalNetwork_to_127.0.0.1 rulename=notSTB

=>:dhcp relay ruleadd name=LocalNetwork_to_127.0.0.1 rulename=notVOIP key=and

 OR key: the OR key indicates that a rule applies as soon as one of the conditions if fulfilled.

=>:dhcp relay ruleadd name=video_to_DHCP rulename=STB

=>:dhcp relay ruleadd name=video_to_DHCP rulename=VOIP key=or

Flexiport script
A Flexiport script makes use of dynamic VLANs, moving the MAC address of the recognized device to a
specified VLAN.
Create a Flexiport script as follows:

=>:script add name=dhcr_video index=0 command=“eth bridge dynvlan add hwaddr $1

vlan video”

The script must start with dhcr_ in order to work.

The DHCP relay can trigger a Flexiport script, if it is assigned to a DHCP relay forwarding entry as follows:

=>:dhcp relay modify name=video_to_DHCP script=video

Here, the name of the script must be entered without the dhcr_ prefix.

If a DHCP relay forwarding entry applies, the corresponding Flexiport script is triggered. The script stores the
MAC address of the recognized device in the dynVLAN membership table.

=>:eth bridge dynvlan list

ID MAC Address VLAN RemVLAN (* = dynamic)
-- ----------- ---------- ----------
0 00:0f:1f:00:00:11 video (none)

Dynamic MAC addresses

Maximum four MAC addresses can be stored in the dynVLAN membership table. As a result, a maximum of
four devices can simultaneously make use of dynamic VLANs (and thus of Flexiport). If a fifth device needs to
be connected, the dynVLAN membership table should not store the MAC addresses. Since release R6.1, there
is a parameter dynamic in the Flexiport script to enable dynamic MAC addresses.
 If the parameter is disabled, the MAC address is stored in the dynVLAN membership table. By default, the
parameter is disabled.

5 E-DOC-CTC-20080401-0010 v1.0
 Chapter 2

 If the parameter is enabled, the MAC address is not stored in the dynVLAN membership table. This
allows that more than four devices make use of the Flexiport mechanism. In addition, if the Thomson
Gateway reboots, the entries are removed from the dynVLAN membership table.
For example, following Flexiport script enables the use of dynamic MAC addresses:

=>:script add name=dhcr_video index=0 command=“eth bridge dynvlan add hwaddr $1

vlan video dynamic enabled”

If this script is triggered, an entry is added to the dynVLAN membership table. The asterisk indicates that a
dynamic MAC address is used:

=>:eth bridge dynvlan list

ID MAC Address VLAN RemVLAN (* = dynamic)
-- ----------- ---------- ----------
0 00:0f:1f:00:00:55 video (none) *

Parameter remVLAN
In most scenarios, the Flexiport script moves the MAC address of a STB to a separate VLAN. However, it is
also possible that the MAC address of a data PC (e.g. connected to LAN port ethport3) is moved to a separate
VLAN and the STB (e.g. connected to LAN port ethport1) remains in the default VLAN. In this case, the
dynVLAN membership table and the resulting VLAN membership information look as follows:

=>:eth bridge dynvlan list

ID MAC Address VLAN RemVLAN (* = dynamic)
-- ----------- ---------- ----------
50 00:19:b9:2d:0f:c1 data (none)
=>:eth bridge vlan iflist
Vid Name Bridge interfaces (* = untagged)
--- ---- --------------------------------
1 default OBC*, ethport1*, ethport2*, ethport3*, ethport4*, WLAN*, wan_video
2 data ethport3*

Following behaviour can be expected: when the STB requests a multicast video stream, these video packets
are also sent out on ethport3 and thus are received by the data PC. This is unwanted behaviour. To obtain the
desired behaviour, there is a parameter remvlan in the Flexiport script to explicitly remove the MAC address
from a specific VLAN. If the data PC is removed from the default VLAN, it does not receive any multicast
packets. For example, following Flexiport script uses the remvlan parameter:

=>:script add name=dhcr_video index=0 command=“eth bridge dynvlan add hwaddr $1

vlan data remvlan default”

In this case, the dynVLAN membership table and the resulting VLAN membership information look as
follows:

=>:eth bridge dynvlan list

ID MAC Address VLAN RemVLAN (* = dynamic)
-- ----------- ---------- ----------
50 00:19:b9:2d:0f:c1 data default
=>:eth bridge vlan iflist
Vid Name Bridge interfaces (* = untagged)
--- ---- --------------------------------
1 default OBC*, ethport1*, ethport2*, ethport4*, WLAN*, wan_video
2 data ethport3*

E-DOC-CTC-20080401-0010 v1.0
6
Chapter 2

2.2 IGMP Proxying

Introduction
When a multicast client wants to receive a specific multicast stream, it must join the corresponding multicast
group. IGMP is the protocol used by IPv4 systems, i.e. clients and routers, to report their multicast group
memberships to neighbouring multicast routers.

Use of IGMP proxying

IGMP proxying can be seen as a lightweight multicast routing mechanism. A device that supports IGMP
proxying is called an IGMP proxy. The IGMP proxy will learn and proxy group membership information.
In order to use IGMP proxying on the Thomson Gateway, you must specify the upstream IP interfaces
(typically these are WAN interfaces) and the downstream IP interfaces (typically these are LAN interfaces).
When the Thomson Gateway receives an IGMP report message on a downstream IP interface, it checks if it
already has a subscription to this multicast group address. If it does not have a subscription present in its
membership database, it replicates this report and forwards it on the upstream IP interfaces. Once the stream
is received, the Thomson Gateway forwards and/or replicates the stream to the appropriate device(s) on its
downstream IP interfaces.

7 E-DOC-CTC-20080401-0010 v1.0
 Chapter 3

3 Ethernet WAN Port for Routed Multicast

3.1 Scenario Overview

Introduction
In this scenario, we configure the Thomson Gateway with a single PVC and an Ethernet WAN port:
 The PVC is used for data traffic via a routed PPPoE Internet connection.
 The Ethernet WAN port is used for routed multicast traffic.
Following illustration shows the scenario “Ethernet WAN port for routed multicast“:

Internet

Private IP
from DHCP Pool 1
BRAS

Thomson Gateway
PPPoE
NATed IP Connection

NATed IP Routed
Ethernet DSLAM
Connection

Private IP
from DHCP Pool 2

Video Server

Video Network

Mechanisms
To set up this scenario, we use following mechanisms:
 VLANs: the Ethernet bridge of the Thomson Gateway uses a separate video VLAN for multicast video
traffic. This results in a Layer 2 isolation of the STB and the other LAN devices.
 Flexiport: this mechanism assigns the MAC address of the STB to the video VLAN. When the STB
connects to a bridge port, that bridge port is automatically added to the video VLAN.
 IGMP proxying: this mechanism enables the Thomson Gateway to work as multicast router.

E-DOC-CTC-20080401-0010 v1.0
8
Chapter 3

3.2 Practical Realization

Configuration overview
Following configuration steps have to be performed to configure the Thomson Gateway for this scenario:
1 Configure the WAN interfaces for the routed PPPoE Internet connection.
2 Create the necessary VLANs.
3 Configure the WAN interfaces for the routed multicast video connection.
4 Configure video LAN interfaces.
5 Configure the Flexiport mechanism.
6 Configure IGMP proxying.
7 Save the configuration.

Before you start

Before you start to configure the Thomson Gateway, make following preparations:
 Reset the Thomson Gateway to the factory defaults and reboot the device.
 Make sure the telnet session with the Thomson Gateway never times out.
 Remove the factory default interfaces and settings that you do not need for the configuration.
 Make these changes permanent. Now, you can start from a clean situation.

=>:system reset factory=yes proceed=yes

=>:env set var=SESSIONTIMEOUT value=0

=>:ppp relay flush

=>:ppp flush
=>:eth flush
=>:atm flush
=>:atm phonebook flush
=>:ip ipdelete addr=10.0.0.138

=>:saveall

Data PVC and ATM interface

Proceed as follows:
 Create a phonebook entry for the data PVC (the VPI/VCI value is indicative):

=>:atm phonebook add name=pvc_data addr=8.35

 Create the data ATM interface on top of the phonebook entry:

=>:atm ifadd intf=atm_data

=>:atm ifconfig intf=atm_data dest=pvc_data encaps=llc ulp=mac
=>:atm ifattach intf=atm_data

9 E-DOC-CTC-20080401-0010 v1.0
 Chapter 3

Data Ethernet interface

Proceed as follows:
 Create a logical Ethernet interface and connect it to the data ATM interface:

=>:eth ifadd intf=eth_data

=>:eth ifconfig intf=eth_data dest=atm_data
=>:eth ifattach intf=eth_data

Data PPPoE interface

Proceed as follows:
 Create the PPPoE interface and connect it to the logical Ethernet interface:

=>:ppp ifadd intf=pppoe_data

=>:ppp ifconfig intf=pppoe_data dest=eth_data user=user@inet password=pwdinet

 Add a default route for Internet traffic:

=>:ppp rtadd dst=0.0.0.0 dstmsk=0.0.0.0 intf=pppoe_data

 Enable NAT on the PPPoE interface:

=>:nat ifconfig intf=pppoe_data translation=enabled

 Attach the PPPoE interface:

=>:ppp ifattach intf=pppoe_data

Video VLANs
Proceed as follows:
 Make the Ethernet bridge VLAN aware:

=>:eth bridge config vlan=enabled

 Create a video WAN VLAN:

=>:eth vlan add name=video_wan vid=9

The video WAN VLAN must only be created if the video server is directly connected to the
Ethernet WAN port and uses VLAN tags. In this case, the VID of the created video WAN VLAN
must be the same as the VID of the multicast video streams.
 Create a video VLAN:

=>:eth vlan add name=video vid=2

E-DOC-CTC-20080401-0010 v1.0
10
Chapter 3

Video Ethernet WAN port

Proceed as follows:
 Detach and delete an Ethernet bridge port. As a result, we can use the corresponding physical Ethernet
interface as an Ethernet WAN port for multicast video:

=>:eth bridge ifdetach intf ethport4

=>:eth bridge ifdelete intf ethport4

Video Ethernet WAN interfaces

Proceed as follows:
 Create a logical Ethernet interface and connect it to the Ethernet WAN port:

=>:eth ifadd intf=eth_wan

=>:eth ifconfig intf=eth_wan dest=ethif4
=>:eth ifattach intf=eth_wan

 Create another logical Ethernet interface. Connect it to the first one and place it in the video WAN VLAN:

=>:eth ifadd intf=eth_video

=>:eth ifconfig intf=eth_video dest=eth_wan vlan=video_wan
=>:eth ifattach intf=eth_video

Video IP WAN interface

Proceed as follows:
 Create the video IP interface and connect it to the logical video Ethernet interface:

=>:ip ifadd intf=ip_video dest=eth_video

 Enable NAT on the IP interface:

=>:nat ifconfig intf=ip_video translation=enabled

 Attach the IP interface:

=>:ip ifattach intf=ip_video

DHCP client
Proceed as follows:
 Configure the DHCP client for the video IP WAN interface:

=>:dhcp client ifadd intf=ip_video

=>:dhcp client ifconfig intf=ip_video metric=10 dnsmetric=10
=>:dhcp client ifattach intf=ip_video

11 E-DOC-CTC-20080401-0010 v1.0
 Chapter 3

Video Ethernet LAN interface

Proceed as follows:
 Create a logical Ethernet LAN interface and place it in the video VLAN:

=>:eth ifadd intf=ethVideoLan

=>:eth ifconfig intf=ethVideoLan dest=bridge vlan=video
=>:eth ifattach intf=ethVideoLan

Video IP LAN interface

Proceed as follows:
 Create the video IP LAN interface and connect it to the logical Ethernet LAN interface:

=>:ip ifadd intf=ipVideoLan dest=ethVideoLan

=>:ip ifconfig intf=ipVideoLan group=lan
=>:ip ifattach intf=ipVideoLan

 Assign an IP address to the IP LAN interface:

=>:ip ipadd intf=ipVideoLan addr=192.168.2.254

DHCP pool
Proceed as follows:
 Create a DHCP server pool for the video network:

=>:dhcp server pool add name=LAN_video

=>:dhcp server pool config name=LAN_video intf=ipVideoLan poolstart=192.168.2.64
poolend=192.168.2.253 netmask=24 gateway=192.168.2.254 server=192.168.2.254
primdns=192.168.2.254 leasetime=7200

Dynamic VLAN membership checking

Proceed as follows:
 Enable dynVLAN membership checking on the three Ethernet bridge ports:

=>:eth bridge ifconfig intf=ethport1 dynvlan=enabled

=>:eth bridge ifconfig intf=ethport2 dynvlan=enabled
=>:eth bridge ifconfig intf=ethport3 dynvlan=enabled

E-DOC-CTC-20080401-0010 v1.0
12
Chapter 3

DHCP relay forwarding entries

Proceed as follows:
 Place the OBC in the video VLAN. This way, the DHCP relay can handle incoming DHCP requests.

=>:eth bridge vlan ifadd intf=OBC name=video

 Enable configuration of the DHCP relay interfaces:

=>:dhcp relay ifconfig intf=ipVideoLan relay=enabled

 Create a first DHCP relay forwarding entry that will check the MAC address of the device in the DHCP
request. If the MAC address of the device matches the MAC address in the rule, the Flexiport script will be
triggered. If the MAC address does not match the MAC address in the rule, the DHCP request will be
forwarded to the default internal DHCP server:

=>:dhcp relay add name=LocalNetwork_to_video

=>:dhcp relay modify name=LocalNetwork_to_video addr=127.0.0.1 intf=LocalNetwork

 Create a second DHCP relay forwarding entry that will forward a new DHCP request towards the internal
video DHCP server:

=>:dhcp relay add name=video_to_127.0.0.1

=>:dhcp relay modify name=video_to_127.0.0.1 addr=127.0.0.1 intf=ipVideoLan
giaddr=192.168.2.254

DHCP rules
Proceed as follows:
 Create DHCP rules to recognize the STB based on its MAC address:

=>:dhcp rule add name=STB type=mac mac=00:0f:1f:83:d7:5b

=>:dhcp rule add name=notSTB type=mac mac=!00:0f:1f:83:d7:5b

 Assign the DHCP rules to the DHCP relay forwarding entries:

=>:dhcp relay ruleadd name=LocalNetwork_to_video rulename=STB

=>:dhcp relay ruleadd name=LocalNetwork_to_127.0.0.1 rulename=notSTB
=>:dhcp relay ruleadd name=video_to_127.0.0.1 rulename=STB

Flexiport script
Proceed as follows:
 Create a Flexiport script to move the MAC address of the STB to the video VLAN:

=>:script add name=dhcr_video index=0 command="eth bridge dynvlan add hwaddr $1

vlan video"

The script must start with dhcr_ in order to work.

13 E-DOC-CTC-20080401-0010 v1.0
 Chapter 3

 Assign the script to a DHCP relay forwarding entry:

=>:dhcp relay modify name=LocalNetwork_to_video script=video

Here, the name of the script must be entered without the dhcr_ prefix.

These CLI commands apply to a residential device (500 or 700 series). In case you have a
business device (600 series), use lan1 instead of LocalNetwork.

IGMP proxy
Proceed as follows:
 Enable the IGMP proxy to forward all multicast traffic from the WAN side to the video VLAN:

=>:igmp proxy config state=enabled

 Configure each IP interface as an upstream or downstream IP interface:

=>:igmp proxy ifconfig intf=ipVideoLan state=downstream

=>:igmp proxy ifconfig intf=ip_video state=upstream
=>:igmp proxy ifconfig intf=LocalNetwork state=inactive

Save the configuration

Proceed as follows:
 To make your changes permanent, save the configuration:

=>:saveall

E-DOC-CTC-20080401-0010 v1.0
14
Chapter 3

3.3 Result
Following illustration shows the resulting configuration of the Thomson Gateway:

DHCP Server DHCP Server

LAN_private LAN_video
192.168.1.[64-253] 192.168.2.[64-253]

DHCP Relay DHCP Client

Router
IGMP Proxy
DOWN UP

192.168.1.254 192.168.2.254 public IP address public IP address

IP LocalNetwork IP ipVideoLan IP ip_video PPP pppoe_data

ETH ETH ethVideoLan ETH eth_video ETH eth_data

OBC
Bridge
default (vid=1) video (vid=2)

Flexiport
1 2 3 ethport ...

ETH eth_wan ATM atm_data

PHY ethif4 PVC pvc_data

8.35

PC STB

15 E-DOC-CTC-20080401-0010 v1.0
Visit us at:

www.thomson-broadband.com

Coordinates:

THOMSON Telecom
Prins Boudewijnlaan 47
B-2650 Edegem
Belgium

Copyright

©2008 THOMSON. All rights reserved.

The content of this document is furnished for informational use only, may be subject to change without notice, and should not be
construed as a commitment by THOMSON. THOMSON assumes no responsibility or liability for any errors or inaccuracies that may
appear in this document. The information contained in this document represents the current view of THOMSON on the issues discussed
as of the date of publication. Because THOMSON must respond to changing market conditions, it should not be interpreted to be a
commitment on the part of THOMSON, and THOMSON cannot guarantee the accuracy of any information presented after the date of
publication. This document is for informational purposes only. THOMSON MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO
THE INFORMATION IN THIS DOCUMENT.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.