Triple-Play Using IPoE for Voice, PPPoE for Data and Bridged Video on a Single PVC

Transcription

1 Triple-Play Using IPoE for Voice, PPPoE for Data and Bridged Video on a Single PVC Date: April 2008 Version: v1.0 Abstract: Applicability: Updates: This Application Note provides technical information on the support of a Triple-Play scenario by Thomson Gateway products. First, a brief introduction to the basic concepts of Triple-Play is presented. Next, a tested and proven scenario shows how the Thomson Gateway can be integrated in a Triple-Play network. The presented scenario uses a single PVC with an IPoE connection for voice traffic, a PPPoE connection for data traffic and a bridged connection for video traffic. RTSP and IGMP are used to support video and SIP is the selected VoIP signalling protocol. This document describes 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. This Application Note is relevant to all Thomson Gateway devices that support video (RTSP and Flexiport) and VoIP (SIP). 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

2 Chapter 1 1 Introduction to Triple-Play Introduction In this chapter, we give some background information on Triple-Play. Today, both telecom operators and cable operators are developing their networks to offer the Triple-Play service to the customer. In this introduction, we mainly focus on the delivery of the Triple-Play service by telecom operators using the DSL broadband access technology. Delivery of multiple services The term Multi-Play is a general term, used to refer to the delivery of multiple telecommunication services. Following more specific terms are also used: Dual-Play: the Dual-Play service refers to the delivery of two services. These services are: Voice and data services in the case of telecom operators. Video and data services in the case of cable operators. Triple-Play: the Triple-Play service refers to the delivery of voice, video and data services over a common network infrastructure, with one subscription. To this end, operators add an additional service to their Dual-Play service: Cable operators already provide video and data services and compete with telecom operators to provide voice services. Telecom operators already provide voice and data services and compete with cable operators to provide video services. Quadruple-Play: the Quadruple-Play service combines the Triple-Play service with the delivery of wireless services. Triple-Play services The term Triple-Play service covers a large collection of voice, video and data services, including: Video telephony IPTV, which is multicast video Video on Demand (VoD), which is unicast video Voice over IP (VoIP) Gaming Internet access (HTTP traffic)

3 Chapter 1 Triple-Play DSL network infrastructure Following illustration shows the typical DSL network infrastructure: Subscriber s Premises Local Loop Telephone Company s Central Office Ethernet or ATM Switches Internet Service Provider s Network PC xdsl Modem DSLAM PC xdsl Modem Access Network Internet PC xdsl Modem BRAS Edge Router DSLAM PC xdsl Modem This DSL network infrastructure consists of the following key elements: DSL modem Digital Subscriber Line Access Multiplexer (DSLAM) Broadband Remote Access Server (BRAS) DSL modem Traffic is sent from the subscriber s device or network through a DSL modem. Next, traffic is sent to the other end of the line, which is located at the telephone company s Central Office (CO). This line consists of the existing copper telephone wires, also called the local loop or last mile. Digital Subscriber Line Access Multiplexer (DSLAM) At the CO, the traffic is received by the DSLAM. The DSLAM aggregates the digital data streams coming from numerous DSL modems onto a single high-capacity uplink (ATM or Gigabit Ethernet) towards the Internet Service Provider (ISP). The DSLAM uses multiplexing techniques. Different DSLAM types exist: ATM DSLAMs: these DSLAMs have an ATM uplink port. The first generation ATM DSLAMs are designed as simple Layer 2 ATM multiplexers. They provide a seamless transition from the last mile ATM Permanent Virtual Circuits (PVCs) to a single PVC in the ATM access network. This single PVC is used for all services. The second generation ATM DSLAMs also have ATM switching capabilities. As a result, they support ATM Switched Virtual Circuits (SVCs) and all of the class of service, traffic shaping and traffic prioritization capabilities inherent with ATM. Different services can use different SVCs. 3

4 Chapter 1 Ethernet or IP DSLAM: these DSLAMs have an Ethernet uplink port. In its simplest implementation, IP DSLAMs function as Layer 2 switches with a limited Layer 3 capability. They support Ethernet VLANs in combination with Ethernet multicast capability (IGMP snooping or proxy support). The industry trend is definitely towards more advanced Layer 3 functionality on the IP DSLAMs. Broadband Remote Access Server (BRAS) The BRAS sits at the core of an ISP s network, which is a business or organization that provides to customers access to the Internet and related services. The specific tasks of a BRAS include: Aggregation point: the BRAS aggregates the output from multiple DSLAMs in the access network. Router: the BRAS routes traffic into an ISP s backbone network. Session termination: the BRAS provides the logical termination of PPP sessions. These may be PPP over Ethernet (PPPoE) or PPP over ATM (PPPoA) encapsulated sessions. Subscriber management functions: the BRAS provides the interface to authentication, authorization and accounting (AAA) systems. The BRAS is also responsible for assigning session parameters such as IP addresses to the clients. The BRAS is the first IP hop from the client to the Internet. Policy management and QoS: at the BRAS, an ISP can insert policy management and IP Quality of Service (QoS). 4

5 2 Triple-Play Scenario 2.1 Scenario Overview Network architecture Following illustration shows the network architecture of the considered Triple-Play scenario: Video Services TR-069 ACS DHCP Server for Video Video Server - Unicast - Multicast Triple-Play - single PVC - IP DSLAM BRAS & Router Video Service Router FTP, HTTP Servers IP DSLAM Fast Ethernet/ Gigabit Ethernet RADIUS Data Service Router Voice Service Router DNS and SNTP Server WWW Data Services Voice Network DHCP Server for Voice SIP Server Voice Services Digital Subscriber Line Access Multiplexer (DSLAM) In the network, an IP DSLAM is used. The IP DSLAM uses MAC Address Classification to classify the different streams (data, voice and video). Next, the streams are routed over different VLANs towards the BRAS, where these VLANs are terminated. 5

6 Broadband Remote Access Server (BRAS) The BRAS also serves as a Router. Three virtual routers have been configured in the BRAS: Video Service Router for video traffic Data Service Router for data traffic Voice Service Router for voice traffic These virtual routers are totally isolated from each other. This isolation provides security and noninterference between the three types of services (data, voice and video). The BRAS and its three virtual routers provide access to the different services via different service VLANs. For example, one VLAN is used between the Video Service Router and the Video Server, another VLAN is used between the Data Service Router and the FTP Server, and so on. Provided services The services that are available in the network are: Data services Voice services Video services Remote CPE management 6

7 2.2 Thomson Gateway Configuration Target configuration scheme In order to set up the scenario, we configure the Thomson Gateway as shown in following illustration. The illustration also explains how the data, voice and video streams are handled by the Thomson Gateway. DHCP Server LAN_private [64-253] DHCP Relay DHCP Client IP Router IP LocalNetwork PPP Internet IP voice- if PPP Relay VoIP Module ETH ETH ethoa_internet OBC ETH Bridge default (vid=1) video (vid=2) Flexiport ethport FXS1 FXS ethif br_intermet Data Voice Video ATM atm_internet PVC pvc_internet Voice Analogue Phone Data PC Video STB 7

8 2.3 Practical Realization Mechanisms To set up this scenario, we use following mechanisms: Label for IP forwarding of voice traffic IP QoS queuing Flexiport mechanism Use of VLANs on the Ethernet bridge DHCP server for the data PC DHCP client on behalf of the analogue phone SNTP and DNS SIP as VoIP signalling protocol CWMP for remote CPE management Configuration overview Following configuration steps have to be performed to configure the Thomson Gateway for this scenario: 1 Configure the ATM interface. 2 Configure IP QoS. 3 Configure the necessary interface architecture on the Thomson Gateway. 4 Configure the IP addresses. 5 Configure the video services. 6 Configure the data services. 7 Configure the voice services. 8 Configure remote CPE management. 9 Save the configuration. These steps are described in following subsections, explaining the used Command Line Interface (CLI) commands. To test this scenario, the Thomson TG716v5 Release was used ATM Interface ATM phone book Only a single PVC (ATM connection) is used. The ATM phone book contains the address of this PVC (the VPI/ VCI value is indicative): =>:atm phonebook add name=pvc_internet addr=8.35 8

9 ATM interface An ATM interface is created on top of the phone book entry. The upper layer protocol for the ATM interface is set to MAC (Ethernet), as this ATM interface will be connected to the bridge: =>:atm ifadd intf=atm_internet =>:atm ifconfig intf=atm_internet dest=pvc_internet ulp=mac =>:atm ifattach intf=atm_internet IP QoS Introduction The classification of IP packets and the use of different IP QoS queues is important as only a single PVC is used for all traffic (data, voice and video). Label for voice traffic A label is used to assign a user-friendly name to classified types of connections. By default, a number of labels are already defined in the Thomson Gateway. In addition, a new label is created for voice traffic: =>:label add name=voice-only This label is configured as follows: the default internal QoS class of packets with this label is set to 14 (high priority). The internal QoS class of the ACK segments of the TCP connection is also set to 14. These internal QoS classes are only assigned if the class value (i.e. 14) is higher than the class value already set by Layer 2. The label will also be copied to all child connection streams in the same direction. =>:label modify name=voice-only classification=increase defclass=14 ackclass=14 inheritance=enabled Classification rules A classification rule determines the criteria that allow to give a specific label to a packet. A number of new classification rules are inserted in the chain rt_user_labels. Labels assigned by these rules can be used in the IP forwarding table. The new rules state that all packets coming from the local IP interface group and with service RTP-VoIP, SIP or MER-DHCP must be labelled with the label voice-only. =>:label rule add chain=rt_user_labels index=1 name=rtp-fwd srcintf=local serv=rtp-voip label=voice-only =>:label rule add chain=rt_user_labels index=2 name=sip-voice srcintf=local serv=sip label=voice-only =>:label rule add chain=rt_user_labels index=3 name=dhcp-voice srcintf=local serv=mer-dhcp label=voice-only 9

10 IP QoS queues IP QoS is enabled for the created ATM PVC. As a result, this ATM PVC has six IP QoS queues. These IP QoS queues are configured as follows: the selected subqueue priority algorithm is Strict Priority Scheduling. This means that Strict Priority scheduling is used between all (six) queues. The higher the queue number, the higher the priority. In case of congestion, the real-time queue (queue 5) will only use 94 percent of the interface bandwidth if there is also traffic on the other queues. =>:ipqos config dest=pvc_internet state=enabled priority=strict realtimerate=94 For the created ATM PVC, the configuration of the queue AF 1 (queue 1) is modified as follows: the filtering of TCP ACK packets is enabled. =>:ipqos queue config dest=pvc_internet queue=1 ackfiltering=enabled Configuring Ethernet Interfaces Ethernet interfaces on the bridge The configuration of the Ethernet bridge and the Ethernet (LAN and WAN) interfaces includes following steps: Configuration of the bridge: the use of a filter on the Ethernet WAN interfaces is disabled. As a result, all broadcasts are allowed to the WAN interfaces. An example of these broadcasts are the DHCP requests sent by the DHCP client on the Thomson Gateway. The use of VLANs on the bridge is enabled. Later on, we will define an additional VLAN on the bridge. =>:eth bridge config filter=none vlan=enabled Ethernet WAN interface on the bridge: only one Ethernet WAN interface is created on the bridge. This interface is connected to the created ATM interface. =>:eth bridge ifadd intf=br_internet =>:eth bridge ifconfig intf=br_internet dest=atm_internet =>:eth bridge ifattach intf=br_internet Ethernet LAN interfaces on the bridge: by default, four Ethernet LAN interfaces already exist on the bridge, namely ethport1, ethport2, ethport3 and ethport4. Each of these interfaces is connected to a physical interface, ethif1, ethif2, ethif3 and ethif4 respectively. Flexiport mechanism on the bridge The data PC and the video STB will be connected to Ethernet LAN interfaces. Thanks to the Flexiport mechanism, it is not important which interfaces are used. To enable the Flexiport mechanism, dynamic VLAN membership checking is enabled for the four Ethernet LAN interfaces on the bridge. =>:eth bridge ifconfig intf=ethport1 dynvlan=enabled =>:eth bridge ifconfig intf=ethport2 dynvlan=enabled =>:eth bridge ifconfig intf=ethport3 dynvlan=enabled =>:eth bridge ifconfig intf=ethport4 dynvlan=enabled 10

11 Virtual Local Area Networks (VLANs) The configuration of VLANs is organized as follows: A new video VLAN is created. The default VLAN learning constraint is added. This means that shared VLAN learning is used between the video VLAN and the default VLAN. =>:eth vlan add name=video vid=2 addrule=enabled The Ethernet WAN interface is added to the video VLAN and explicitly deleted from the default VLAN. The internal OBC interface is added to the video VLAN as tagged member. =>:eth bridge vlan ifadd name=video intf=br_internet =>:eth bridge vlan ifdelete name=default intf=br_internet =>:eth bridge vlan ifadd name=video intf=obc untagged=disabled Logical Ethernet interface A new logical Ethernet interface is created. The interface has the bridge as destination and is assigned to the video VLAN. =>:eth ifadd intf=ethoa_internet =>:eth ifconfig intf=ethoa_internet dest=bridge vlan=video =>:eth ifattach intf=ethoa_internet Configuring IP and PPP Interfaces IP interfaces The default IP configuration options are used, except for the fragmentation limit. This parameter indicates the maximum number of IP fragments waiting for completion. =>:ip config fraglimit=256 Following IP interfaces are created: By default, the IP interface LocalNetwork is already created. A new IP interface voice-if is created and connected to the logical Ethernet interface. An appropriate MAC address is assigned to this interface: =>:ip ifadd intf=voice-if dest=ethoa_internet =>:ip ifconfig intf=voice-if hwaddr=00:0e:50:0f:fe:59 =>:ip ifattach intf=voice-if PPPoE interface The logical Ethernet interface is added to the PPP relay list. An appropriate MAC address, which differs from the MAC address of the IP interface voice-if, is assigned to this interface. =>:ppp relay ifadd intf=ethoa_internet =>:ppp relay ifconfig intf=ethoa_internet hwaddr=00:0e:50:0f:fe:58 11

12 Next, a new PPP interface is created and connected to the PPP relay. The username and the password for PAP/CHAP authentication are also specified. The DNS metric for negotiated DNS servers is set to 10: =>:ppp ifadd intf=internet =>:ppp ifconfig intf=internet dest=relay user=user@inet password=pwdinet dnsmetric=10 A default route to the PPP interface is created by adding a dynamic entry to the IP forwarding table. This entry is added to the IP forwarding table as soon as the PPPoE session is established. =>:ppp rtadd intf=internet dst= /0 src= /0 metric=1 Network Address Translation (NAT) is enabled on the PPP interface. =>:nat ifconfig intf=internet translation=enabled Now, the PPP interface can be attached: =>:ppp ifattach intf=internet Configuring IP Addresses DHCP selection rules In order to distinguish the DHCP requests sent by the data PC from the DHCP requests sent by the STB, two DHCP rules are created: one for the STB and one for all other devices. To identify the devices, the MAC address of the STB is used: =>:dhcp rule add name=stb type=mac mac=00:0d:56:01:32:fa =>:dhcp rule add name=not_stb type=mac mac=!00:0d:56:01:32:fa DHCP server The data PC obtains an IP address from a DHCP pool of the local DHCP server in the Thomson Gateway. The default DHCP pool LAN_private is used, which requires no extra configuration. This DHCP pool only leases IP addresses in response to DHCP requests received on the IP interface LocalNetwork. DHCP relay By default, the DHCP relay is already enabled for the IP interface LocalNetwork. This means that the DHCP relay handles DHCP requests that are received on this interface. When the DHCP relay receives a DHCP request, it looks in its DHCP relay forward list for an appropriate entry. Two entries are created: By default, the entry LocalNetwork_to_ is already created. If this entry is hit, the DHCP request is forwarded to the local DHCP server. This entry is only meant for DHCP requests sent by the data PC. Therefore, the DHCP rule not_stb is assigned to this forwarding entry. =>:dhcp relay ruleadd name=localnetwork_to_ rulename=not_stb 12

13 A new entry video is created. If this entry is hit, the DHCP request is not forwarded to the local DHCP server. The IP address of the DHCP server is set to This entry is only meant for DHCP requests sent by the STB. Therefore, the DHCP rule STB is assigned to this forwarding entry. =>:dhcp relay add name=video =>:dhcp relay modify name=video addr= =>:dhcp relay ruleadd name=video rulename=stb Flexiport script A Flexiport script is created to move the MAC address of the STB to the video VLAN. The name of the script must start with dhcr_ in order to work. =>:script add name=dhcr_video index=0 command="eth bridge dynvlan add hwaddr $1 vlan video" This script must be executed when the forwarding entry video is hit. Therefore, the script is assigned to the forwarding entry video. Here, the name of the script must be entered without the dhcr_ prefix. =>:dhcp relay modify name=video script=video Once the entry is hit and the MAC address of the STB is moved to the video VLAN, new DHCP requests sent by the STB are forwarded over the bridge towards the Video Service Router. DHCP client In order to access the Voice Network, the Thomson Gateway uses a DHCP client to obtain an IP address from the DHCP server in the Voice Service Router. Following configuration steps are necessary: DHCP client: the DHCP client is configured to request an IP address for the IP interface voice-if. When the DHCP client receives an IP address, entries are added to the IP forwarding table. Only packets with label voice-only are allowed to use these entries. =>:dhcp client ifadd intf=voice-if =>:dhcp client ifconfig intf=voice-if label=voice-only metric=10 dnsmetric=20 =>:dhcp client ifattach intf=voice-if Options to be requested: the DHCP client requests following DHCP options: =>:dhcp client rqoptions add intf=localnetwork option=dhcp-lease-time =>:dhcp client rqoptions add intf=localnetwork option=dhcp-renewal-time =>:dhcp client rqoptions add intf=localnetwork option=dhcp-rebinding-time =>:dhcp client rqoptions add intf=localnetwork option=subnet-mask =>:dhcp client rqoptions add intf=localnetwork option=default-routers =>:dhcp client rqoptions add intf=localnetwork option=domain-name-servers 13

14 Options to be transmitted: the DHCP client in its turn can also send DHCP options to the DHCP server, indicating desired configuration values. Following option/value pairs are added: vendor-class-id: the DHCP client indicates that it requests an IP address on behalf of a device with VCI = ispiad. dhcp-requested-address: the DHCP client can be configured to request a specific IP address, which is indicated by this option. =>:dhcp client txoptions add intf=voice-if option=vendor-class-id value=(ascii)ispiad index=1 =>:dhcp client txoptions add intf=voice-if option=dhcp-requested-address value=(addr) index= Configuring Video Services Introduction All video streams (both multicast and unicast) are obtained from the same Video Server. Multicast video: the Internet Group Management Protocol (IGMP) is used to support multicast video. Unicast video: the Real Time Streaming Protocol (RTSP) is used to support unicast video. The support of unicast video requires no extra configuration of the Thomson Gateway. No IGMP configuration The Thomson Gateway uses the bridged scenario for the video services. Hence, the IGMP proxy mechanism is not used in this scenario. Only the Ethernet LAN interface to which the STB is connected is part of the video VLAN. The other Ethernet LAN interfaces are part of the default VLAN. As a result, the use of IGMP snooping is also not required Configuring Data Services Introduction A Point-to-Point Protocol over Ethernet (PPPoE) session is used to access the data services. This PPPoE session is initiated by the PPPoE client in the Thomson Gateway and is terminated in the BRAS. The PPPoE server is located in the BRAS itself. The PPP request is authenticated in the external RADIUS server, by the use of either PAP or CHAP. Once the PPP request is authenticated, the BRAS gives an IP address from its PPPoE pool to the Thomson Gateway. Simple Network Time Protocol (SNTP) The Simple Network Time Protocol (SNTP) is a simplified form of the Network Time Protocol (NTP), used to synchronize computer clocks in the Internet. The internal Thomson Gateway real time clock (SNTP client) will be synchronized with an NTP server. 14

15 Enable the SNTP service: =>:service system modify name=sntp state=enabled NTP server: two NTP servers are added to the NTP server list. To this end, the IP address of each NTP server is specified, as well as the SNTP version of the NTP server. =>:sntp add addr= version=3 =>:sntp add addr= version=3 SNTP client: the SNTP client on the Thomson Gateway is enabled by default. Domain Name System (DNS) The most basic use of the Domain Name System (DNS) is to translate user-friendly domain names and host names to computer-friendly IP addresses. The DNS service is enabled by default DNS client: the DNS client sends DNS requests to the internal DNS server (or DNS resolver). By default, the internal DNS server is defined. DNS server: the internal DNS server either translates a host name to the correct IP address or forwards the DNS request to an external DNS server. The host name isp is added to the list of host names. Three remote DNS server errors are suppressed. =>:dns server host add name=isp addr= ttl=1200 =>:dns server config suppress= Configuring Voice Services Introduction In this scenario, the selected Voice over IP (VoIP) signalling protocol is the Session Initiation Protocol (SIP). SIP is an application-layer signalling protocol that can establish, modify, and terminate multimedia sessions such as Internet telephony calls. Voice over IP (VoIP) An analogue telephone is connected to the Thomson Gateway via an FXS port. In order to use VoIP, the Thomson Gateway must act as a SIP User Agent on behalf of the FXS port. To do so, the VoIP service must be enabled: =>:service system modify name=voip_sip state=enabled SIP user agent In order to support VoIP and SIP, the following parameters must be configured: VoIP: Dual-Tone Multi-Frequency (DTMF) information: DTMF information is sent according to RFC

16 Port range: the port range that can be used by the RTP/RTCP protocol is set from through Interface: the voice application is configured with the voice-if interface as static interface. This means that the IP address of this interface is used as the source IP address of voice messages. =>:voice config digitrelay=rfc2833 rtp_portrange= static_intf=enabled intf=voice-if SIP proxy server and registrar: The primary proxy address identifies the outbound proxy server. In addition, the proxy port defines the outbound proxy port. In a similar way, a primary registrar address and registrar port are configured. =>:voice sip config primproxyaddr= proxyport=sip =>:voice sip config primregaddr= regport=sip Session keep-alive mechanism: SIP does not define a keep-alive mechanism for the sessions it establishes. RFC 4028 defines an extension to SIP. This extension allows a periodic refresh of SIP sessions through session refresh requests. The extension defines two important timers: Session interval: the maximum amount of time that can occur between session refresh requests before the session will be considered timed out. The value of this timer is set to 120 s. Minimum timer: as a lot of session refresh requests results in a lot of processing load, all elements (Proxy, UAC, UAS) can have a configured minimum value for the session interval that they are willing to accept. =>:voice sip config min-se=90 session-expires=120 Voice profile: voice profiles are used to assign specific phone numbers to local voice ports (FXS 1 or FXS 2) or to define a common number. In this scenario, only a common number is configured. The string entered as SIP-URI is used as user name in the Address of Record (AoR). =>:voice profile add SIP_URI=1234 voiceport=common Voice codecs By default, the codec capability of the Thomson Gateway is configured to support codecs G.711 µ-law (North America and Japan) and G.711 A-law (Europe and the rest of the world). The codec G.711 A-law is configured with the highest priority. =>:voice codec config type=g711a priority=1 status=enabled =>:voice codec config type=g711u priority=2 status=enabled Supplementary services Following supplementary services are provisioned in this scenario. A provisioned service can be activated or deactivated: Call hold service Call waiting service CLIP service: this service includes both the Calling Line Identification Presentation (CLIP) and the Calling Name Identification Presentation (CNIP). CLIR service: this service includes both the Calling Line Identification Restriction (CLIR) and the Calling Name Identification Restriction (CNIR). 16

17 Three party service CLIR on call service: the CLIR on call service is automatically provisioned AND activated when the CLIR service is provisioned. It is also assigned the same service code. Call waiting on call service: the Call waiting on call service is automatically provisioned AND activated when the Call waiting service is provisioned. It is also assigned the same service code. =>:voice services provision type=hold =>:voice services deactivate type=hold =>:voice services provision type=waiting =>:voice services deactivate type=waiting =>:voice services provision type=clip =>:voice services activate type=clip =>:voice services provision type=clir =>:voice services deactivate type=clir =>:voice services provision type=3pty =>:voice services deactivate type=3pty The other supplementary services are withdrawn. Withdrawn services are simply not available: =>:voice services withdraw type=transfer =>:voice services withdraw type=mwi =>:voice services withdraw type=forcedfxo =>:voice services withdraw type=cfu =>:voice services withdraw type=cfnr =>:voice services withdraw type=cfbs =>:voice services withdraw type=callreturn =>:voice services withdraw type=ccbs By default, a prefix service code is assigned to an action on a supplementary service. For example, the service code 94 is assigned to the call hold service. Automatically the prefix service code *94/#94 is used to activate/ deactivate the service. Following parameters are configured: CWreply: if the call waiting service is provisioned and activated, the served user is informed of the incoming call. In addition, the calling user receives an 180 response, which indicates the ring tone. The CLIR format is set to non-standard. This means that the following address appears in the From: anonymous<sip:user name@domain name>. This format might be required for billing reasons. =>:voice sip config CWreply=180 =>:voice sip config clirformat=nonstandard FXS port configuration The Foreign exchange Station ports (FXS1 and FXS2) support an analogue line end point. Dialling of a number is considered ended when the interdigit timer (IDT) expires. Two interdigit timers are configured: The interdigit timer, i.e. the maximum allowable time between the dialling of digits, is set to 4 s. The interdigit timer for open numbering is set to 5 s. An entry of the dial plan belongs to an open numbering scheme if the minimum number of digits differs from the maximum number of digits. Once the minimum number of digits has been reached and an open numbering scheme is used, the interdigit timer is set to this value. =>:voice fxsport config interdigit=4000 interdigitopen=

18 Dial plan To obtain an overview of the dial plan on the Thomson Gateway, use following command: =>:voice dialplan list The dial plan is mainly used for outgoing calls. These entries must be explicitly created. An entry is created by configuration of following parameters: The prefix: for example 01. The default outgoing port: this parameter is set to VoIP. The fallback mechanism: as the FXO port is not used in this scenario, the fall-back mechanism is disabled and no fall-back outgoing port is configured. The priority: the main reason to add entries to the dial plan is to give the corresponding calls a high priority. The minimum and maximum number of digits: for example, these parameters are set to 10. As the minimum number of digits equals the maximum number of digits, the entry belongs to a closed numbering scheme. This means that the called number must have the correct prefix and have exactly 10 digits to hit the entry. The action: if the collected digits contain an end-of-number indication (#) and the action is ROUTE_excl_eon, the end-of-number indication is not sent out. Other parameters: when an entry is hit, the outgoing call is set up (routed). It can be configured that the dialled numbers are modified. In this example, the dialled numbers are not modified. For example, following entry is created: =>:voice dialplan add prefix=01 defaultport=voip fallbackport=na priority=high fallback=disabled minimumdigits=10 maximumdigits=10 posofmodify=0 remnumdigits=0 insert="" rescan=no data=no action=route_excl_eon Country settings Several voice related configuration parameters, for example tones for tone generation, are specified for multiple countries in a binary file. A country must be selected from the country list. =>:voice country config country=france Remote CPE Management Introduction TR-069 (Technical Report 069), which is specified by the DSL-Forum, defines the CPE WAN Management Protocol (CWMP). CWMP is used for remote management of the Thomson Gateway. CWMP supports the communication between the following network elements: Customer Premises Equipment (CPE), which is the Thomson Gateway in this scenario Auto Configuration Server(s) (ACS), which is the TR-069 ACS in this scenario The TR-069 ACS can be accessed over PPP. To this end, the PPPoE session that is set up for the data services is reused. The PPPoE session is initiated by the PPPoE client in the Thomson Gateway and is terminated in the BRAS. 18

19 Enabling CWMP In order to allow remote management of the Thomson Gateway by the TR-069 ACS, the use of CWMP on the Thomson Gateway is enabled. =>:cwmp config state=enabled HTTP session set up The Thomson Gateway must be configured with the HTTP URL of the TR-069 ACS. This URL contains an IP address. The username and password can also be configured to enable authentication of the Thomson Gateway by the TR-069 ACS: =>:cwmp server config url= username="" password="" Connection set up The initiative to establish a connection can be taken by the CPE or the ACS. To enable ACS connection initiation, the path to reach the Thomson Gateway can be specified, as well as the username and the password the TR-069 ACS must use to log in: =>:cwmp config connectionrequest=enabled connectionreqpath="" connectionrequsername="" connectionreqpsswd="" connectionreqauth=none Save the Configuration Save the configuration To make your changes permanent, save the configuarion as follows: =>:saveall 19

20 2.4 Expected Results Overview An overview of the scenario is shown in following illustration: 8/35 pvc_internet Video VLAN 13 Data VLAN 11 Voice VLAN 12 Video Service Router Data Service Router Voice Service Router Thomson Gateway ATM IP DSLAM MAC Address Classification Fast Ethernet/ Gigabit Ethernet BRAS & Router VLAN Classification ATM layer All traffic is sent over a single PVC, which is initiated in the Thomson Gateway and terminated in the IP DSLAM. This PVC is used for the following traffic streams: Data (PPP signalling and data traffic) VoIP (DHCP signalling and voice traffic) Video (DHCP signalling, bidirectional unicast traffic, multicast traffic and STB management) MAC addresses The IP DSLAM uses MAC Address Classification to classify the different traffic streams. Next, the IP DSLAM maps each traffic stream to the correct VLAN. The VLANs are terminated in the BRAS. The BRAS uses VLAN Classification to terminate each VLAN in the correct Service Router. In that Service Router, the VLAN is mapped to the different service VLANs in the backbone network. Following MAC addresses are used: Data streams: the packets of the data streams are sent over the PPP relay interface towards the backbone network. As a result, they will use the MAC address of this interface as their MAC address. Voice streams: all voice related traffic uses a local USB MAC address, that is the MAC address of the DHCP client in the Thomson Gateway. Video streams use the MAC address of the STB itself. 20

21

22 Visit us at: 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.