Alcatel-Lucent IP Telephony R9

Expert Presales

REFERENCE DURATION

PS00TE901US METHODS

hours days

DELIVERY LANGUAGE

English (course material in English)
Virtual self-paced training on the computer. 12 hours before c-learning Traditional classroom or practical sessions with tutorials (TAP LAB) Tutored virtual training sessions accessible via an internet connection
MAXIMUM NUMBER OF PARTICIPANTS 12 PUBLIC
Presales Engineers, Solution Designers

OBJECTIVES

At the end of the course, the participant will be able to: Address a RFP (Request For Proposal) based on a Complex OmniPCX Enterprise Solution and an advanced OmniVista A4760. Design an Architecture with Distributed Call Control and VoIP Solution Use Traffic calculation tools for dimensioning Generate a complex offer using ACTIS Quote an OmniVista Suite using ACTIS Find appropriate SD specific Documentation & Tools The participant will learn how to design and quote a standard Solution from end-to-end. A Global Case Study using traffic calculation, recommendations and rules, dimensioning tools and all Presales documents available will be done at the end of the session.

PREREQUISITES

To have attended the Alcatel-Lucent IP Telephony Essential Presales training course (Ref: PS00TE900US) To have attended the 2h Enterprise Security Overview (Free I-learning course 3EY0SA050) 3 months minimum on-site practice after the IP Telephony Essential Solution Designer course The participant will bring is own laptop for hands-on, with the latest ACTIS version.
REQUIRED TECHNICAL CONFIGURATION

For i-learning

Access to the Business Partner Web Site. Internet Explorer version 5.5 or better, Macromedia Flash 7 and Acrobat Reader version 6 or better. Virtual Microsoft Java Machine (MSJVM).
All Rights Reserved 2008, Alcatel-Lucent

PROGRAM DESCRIPTION

Phase 1: i-learning 12 hours
Mandatory to seat the c-learning Session. This I-Learning session aims to provide enough comprehensive technical knowledge on an advanced OmniPCX Enterprise Solution, Networking, VoIP and Industry Specific Solutions to make the most of the C-Learning session. Architecture with Distributed Call Control Corporate ABC Networking Infrastructure o Private Network Configurations and Scalability o Private ABC Networks using TDM Leased Lines o ABC Virtual Private Network on ISDN Networks o VoIP Networking ABC Network Features o Private Numbering Plan (Moving a User in an ABC Network) o Network-Wide Telephone Features (Conferences, DISA, Callback, Forwarding ) o User Group (Associate, Forwarding, Manager-Assistant, Supervision, Hunt Groups, Twin Set) o Mobility (DECT Roaming, Remote Forwarding, Substitution, Ubiquity) o Centralized or Distributed Attendants o Centralized, Distributed or Shared Voice Messaging Systems (A4645, A4645) o Adaptive Routing o Alternate Route Selection ARS (Force On-Net, Break Out, Multiple Carrier Selection) o Partial Rerouting for External Call forwarding o Management ( Centralized management, Voice Mail, Alarms; Audit; Broadcast) Heterogeneous Networking (QSIG, DPNSS, ISVPN, H323, SIP) H323 Architecture Peer-to-peer networking Communication with H323 devices Direct RTP Integrated GateKeeper
Session Initiation Protocol (SIP) Environment Alcatel-Lucent and SIP o Marketing SIP o SIP and OmniPCX Enterprise o Supported SIP Standards Integration of SIP End-points o Low Cost Compatible SIP End Points (Thomson ST 2030, FCI IP Ranger) o Registration o Basic SIP Call via the OXE SIP proxy (SIP to SIP, Other to SIP, SIP to Other, Fax Machines) o RTP Flow o Call made to TDM Trunks o Supplementary Services o Voice Mail Account o Authentication/Verification
SIP Trunking o Public SIP Trunking o Private SIP Trunking Supported Telephony features & limitations o User o SIP Public Trunk o SIP Private Trunk Additional IP Services (TFTP, DHCP, AVA, NTP, SNMP, QOS ) VoIP Network Compliance Assessment Process Security Available Security Levels(SSH, SSL, 802.1x) Phone Protection against Toll Fraud Encryption & Security Modules OmniVista 4760 Full Pack Performance & Traffic Analysis VoIP Performance Audit SIP Device Management Network Maintenance Topology Directory OmniVista 4760 MCS Edition Industry Specific Solutions Finance Healthcare Hospitality Local Authorities & Government Agencies Comprehensive Call Routing Call Restriction for Alarms & Emergencies Priority Calls Multi Level Precedence and Pre-emption Multi-Tenants Users Profiles Overview of the Out-of-the-box solutions from Professional Services
Phase 2: c-learning 4 days
The c-learning Session aims to address a RFP (Request For Proposal) based on a complex OmniPCX Enterprise Solution using all Solution Designers tools available. The participant will learn how to design a distributed Architecture with distributed Call Control, a VoIP Solution and an and how to quote the solution using ACTIS. List of topics covered Architecture with Distributed Call Control Corporate ABC Networking Infrastructure o Private Network Configurations and Scalability o Private ABC Networks using TDM Leased Lines o ABC Virtual Private Network on ISDN Networks o VoIP Networking ABC Network Features o Private Numbering Plan (Moving a User in an ABC Network) o Network-Wide Telephone Features (Conferences, DISA, Callback, Forwarding ) o User Group (Associate, Forwarding, Manager-Assistant, Supervision, Hunt Groups, Twin Set) o Mobility (DECT Roaming, Remote Forwarding, Substitution, Ubiquity) o Centralized or Distributed Attendants o Centralized, Distributed or Shared Voice Messaging Systems (A4645, A4645) o Adaptive Routing o Alternate Route Selection ARS (Force On-Net, Break Out, Multiple Carrier Selection) o Partial Rerouting for External Call forwarding o Management ( Centralized management, Voice Mail, Alarms; Audit; Broadcast) Heterogeneous Networking (QSIG, DPNSS, ISVPN, H323, SIP) Architecture with Distributed Call Control VERSUS Architecture with Centralized Call Control H323 Architecture Peer-to-peer networking Communication with H323 devices Direct RTP Integrated GateKeeper

SIP Trunking o Public SIP Trunking o Private SIP Trunking Supported Telephony features & limitations o User o SIP Public Trunk o SIP Private Trunk Additional IP Services (TFTP, DHCP, AVA, NTP, SNMP, QOS ) VoIP Network Compliance Assessment Process Security Available Security Levels(SSH, SSL, 802.1x) Phone Protection against Toll Fraud Encryption & Security Modules OmniVista 4760 Full Pack Performance & Traffic Analysis VoIP Performance Audit SIP Device Management Network Maintenance Topology Directory OmniVista 4760 MCS Edition Industry Specific Solutions Finance Healthcare Hospitality Local Authorities & Government Agencies Comprehensive Call Routing Call Restriction for Alarms & Emergencies Priority Calls Multi Level Precedence and Pre-emption Multi-Tenants Users Profiles Overview of the Out-of-the-box solutions from Professional Services Global Case Study using traffic calculation recommendations and rules, dimensioning tools and all SD documents available.

Project Deliverable

IST - 6th FP Contract N 026442
D B4.4 MMBB integrated lab trial evaluation report
alcega@tid.es Cristina Pea Angela Pueyo pueyo@tid.es Telefnica I+D, S.A. Unipersonal Parque Tecnolgico Walqa, Ctra Zaragoza N330-A, Km 566, 22197 Cuarte (Huesca), Spain Bjoern.Nagel@t-systems.com Bjoern Nagel T-Systems Enterprise Services Goslarer Ufer 35, 10589 Berlin, Germany edith.gilon@alcatel-lucent.be Edith Gilon Jeroen Hoet Jeroen.hoet@alcatel-lucent.be Raf Huysegems rafael.huysgems@alcatel-lucent.be Nico Verzijp nico.verzijp@alcatel-lucent.be Alcatel-Lucent Bell Copernicuslaan 50, 2018 Antwerpen, Belgium Karsten.Oberle@alcatel-lucent.de Karsten Oberle Alcatel-Lucent Deutschland Lorenzstrasse 10, 70435 Stuttgart, Germany arnaud.maillet@thomson.net Arnaud Maillet Thomson Grass Valley France Rue du Clos Courtel, 35517 Cesson-Svign, France Bart.DeVleeschauwer@intec.ugent.be Bart De Vleeschauwer Steven Latre Steven.Latre@intec.ugent.be Pieter Simoens Pieter.Simoens@intec.ugent.be Wim Van de Meerssche Wim.VandeMeerssche@intec.ugent.be IBBT IBCN: Gaston Crommenlaan 8 (Bus 201), 9050 Gent Belgium Identifier: Class: Version: Version Date: Distribution: Responsible Partner: Filename: Deliverable D B4.4 Report V08 26/03/2008 Public ALCB, ALCS, THON, TID, DT MUSE_DB4.4p_v08.doc
DB4.4 Multimedia Broadband 1/97 integrated lab trial evaluation report

Public

DOCUMENT INFORMATION
Project ref. No. Project acronym Project full title Security (distribution level) Contractual delivery date Actual delivery date Deliverable number Deliverable name Type Status & version Number of pages WP / TF contributing WP / TF responsible Main contributors Editor(s) IST-6thFP-026442 MUSE Multi-Service Access Everywhere Public 31/03/2008 26/03/2008 D B4.4 MMBB Integrated Lab Trial Evaluation Report Report VWPB4 Cristina Pea ALCB, TID, DT, THON, THOB, ALCS Cristina Pea, Angela Pueyo, Bjoern Nagel, Edith Gilon, Jeroen Hoet, Raf Huysegems, Nico Verzijp, Bart De Vleeschauwer, Steven Latre, Pieter Simoens, Wim Van de Meerssche, Karsten Oberle, Arnaud Maillet Pertti Jauhiainen Lab trial, access multiplexer, multi-service edge router, TV over IP gateway, Residential Gateway, service gateway, multimedia enhancements, service enablers. The deliverable D B4.4 MMBB integrated lab trial evaluation report reports the operation and test results of the SPB lab trials built with the different network elements developed in WPB1 and WPB3 during the second phase of MUSE. The offered services improve the basic triple-play offer for data, voice and video with a special attention to the broadband multimedia applications.
EU Project Officer Keywords
Abstract (for dissemination)
DB4.4 Multimedia Broadband 2/97 integrated lab trial evaluation report

DOCUMENT HISTORY

Version V01 V02 VQR1 V04 V05 Date 21/01/2008 06/02/2008 08/02/2008 12/02/2008 21/02/2008 Comments and actions Template based on MB4.3 Update of sections 2.1, 2.2, 3.4.Added chapter 4 & annexes Status Draft 2.4, Draft
Version without test suite for quality Semi-final review Final (for internal quality review) Draft

DB4.4 Multimedia Broadband 6/97 integrated lab trial evaluation report
Table 8: D-SBC voice quality results (Berlin)...76 Table 9: D-SBC performance for voice tests...77 Table 10: Perceived QoS with SIP B2BUA between an analogue phone and a softphone.87 Table 11: Cross SP lab trials...95
DB4.4 Multimedia Broadband 7/97 integrated lab trial evaluation report

ABBREVIATIONS

ACNM ACS ADSL AM ANTMA API APlane ASI ATM B2BUA BBE BER BRAS BSCP CAPEX CP(E) CSCF CWDM CWMP DHCP DPI DSBC DSL DSLAM DSLF EFM FARPP FEC FTP GigE GRE GSB GSM GUI HD HDTV HSI HW ICMP IEEE IETF IGMP IMS IMX IP IPTV IPv4, IPv6 KPlane LAN LT Autonomic Communications and Management Auto Configuration Server Asymmetric Digital Subscriber Line Access Multiplexer Access Network TCP Monitoring Algorithm Application Programming Interface Action Plane Asynchronous Serial Interface (in context of DVB) Asynchronous Transfer Mode Back-to-Back User Agent BroadBand Europe (conference) Bit Error Rate Broadband Remote Access Server Base Station Control Protocol Capital Expenditure Customer Premises (Equipment) Call Session Control Function (P-CSCF = Proxy CSCF, S-CSCF = Serving CSCF, I-CSCF= Interrogating CSCF) Coarse Wavelength Division Multiplexing CPE WAN Management Protocol Dynamic Host Configuration Protocol Deep Packet Inspection Distributed Session Border Controller Digital Subscriber Line Digital Subscriber Line Access Multiplexer DSL Forum Ethernet in the First Mile Fast Access Ring Protection Protocol Forward Error Coding File Transfer Protocol Gigabit Ethernet Generic Routing Encapsulation Global System for Broadband communications Global System for Mobile communications Graphical User Interface High Definition High Definition TeleVision High Speed Internet Hardware Internet Control Message Protocol Institute of Electrical and Electronics Engineers Internet Engineering Task Force Internet Group Management Protocol IP Multimedia Subsystem IP Multimedia Exchange Internet Protocol IP TeleVision IP version 4, IP version 6 Knowledge Plane Local Area Network Line Termination
DB4.4 Multimedia Broadband 8/97 integrated lab trial evaluation report
MMBB MOS MPEG MPlane MSER NA(P)T NGN NOC NSP NT OBR OPEX OSGi PBX PC PDA PESQ PPPoE QoE QoS RGW RTCP RTP RTT SBC SD SEPIA SER SIP SP SP STB TCP TFTP TR (e.g. TR69) TS TVoIP UDP UMA UNC UPnP VDSL VLAN VLC VoD VoIP VPN VQT VRF WAC WBS WiFi

DB4.4 Multimedia Broadband 21/97 integrated lab trial evaluation report
Towards the network the Residential Gateway comes with an ADSL2+ interface in the first and second versions. For usage in higher bit rate network environment a version with VDSL2 interface is provided. All these RGWs support Ethernet QoS, IP acceleration for routed mode and some more features. The VDSL2 based version can be used to demonstrate bit rate consuming use cases, such as: Support of multiple HD broadcast streams per home at the same time or High-speed Internet access for faster down- and uploads. Another new feature - local dialling is based on support of a SIP B2BUA within the Residential Gateway and can be demonstrated as well. A further interesting feature from operators point of view is the remote management of LAN devices via TR-069.
Broadband Europe lab trial
Figure 5 shows an overview of the SPB network set-up for Broadband Europe. The network is composed of four homes: Alice, Bob, Carla and David. Alice and Bob host the use cases related to TV and video with the TVoIP gateway prototype and related to seamlessly switched over communications with the MSER prototype. Carla and David host the use cases related to the service plane, D-SBC and RTP/RTCP monitoring. Not shown on the figure, the SPB booth also hosts a parallel set-up related to Quality of Experience improvement.
TV + STB 1 GSM SIP phone SIP phone RGW VDSL2
D-SBC Service Video RTP Monitoring
DHCP NSP 1 SIP server DHCP NSP 2 Edge server

TV + STB 2

RGW Phase1

Alice Bob

Aggregation switch Client user1 Click router Slideset PC SIP phone IMX P2P

VOD server Click router

Service Plane
Management station: - Access Mux - Service Plane - Switch - 7750 - TFTP server - Impairment nodes Graphics display: - RTP monitoring - Action plane

7750SR

Maestream server
Client user2 RGW Phase2 Click router
Figure 5: Broadband Europe 2007 network overview
DB4.4 Multimedia Broadband 22/97 integrated lab trial evaluation report
The reader can notice that in fact there are only three Residential Gateways. By lack of prototypes, the same Residential Gateway was used for the Bob and Davids homes. We decided to have four homes to ease the participants understanding. More information can be found in sections 3.2 and 3.3 for Alice and Bobs use cases and in sections 3.4 for Carla and David. There are as such no tests carried out on this set-up. Section 4.6 gives more info on the demos shown and a picture of the SPB booth.

Seamless session mobility with MSER and with GSM gateway Service offered or use case Compared to the seamless session mobility with MSER without GSM gateway, this service enhances the seamless session mobility across different access technologies. A voice session can be seamlessly transferred between a SIP device and a circuit switched GSM device and vice versa. Also it is possible to transfer a session between devices attached to different packet switched access network types possibly operated by different operators. Network elements involved Off the shelf voice/video capable SIP based end user devices or soft clients: one for the communication partner and two for the session mobility user GSM end device Off the shelf voice/video capable SIP based end user devices or soft clients: one for the communication partner and two for the session mobility user Multi-Service Edge Router MUSE prototype, which is an evolution of the (Phase I) Packet-to-Packet gateway and includes the following component and network functionalities: o Processing HW supporting seamless media session transfer o IMS compliant Control and Application Server function including the seamless DB4.4 Multimedia Broadband 31/97 integrated lab trial evaluation report Public
session mobility logic module o Presence/Preference server integrated within the Application Server. o HSS. Access Multiplexer. Two Residential Gateways with ADSL2 interfaces. DHCP servers. SIP to GSM media and signalling gateway Innovation The across device and across technology (different on the signalling layer and media layer) seamless session mobility is achieved in a homogeneous way without any special end user terminal or terminal adaptations. None of the Mobile IP solutions can provide a cross device mobility feature. And the re-INVITE or REFER methods of the SIP standard can not achieve a seamless mobility. Advantages Homogeneous seamless session solution across devices and technologies. The user may have different private IDs for his physical devices/clients but he is always reachable with his single public ID. Communication devices do not require any modifications. Mobile IP stack is not required.

GSM network

BSCP WSS WSS WSS GRE IP/802.16 WBS1 BSCP WSS WSS WSS GRE IP/802.16 WBS2 BSCP WSS WSS GRE IP/802.16 WAC WBS3 AM+WAC VLAN NSP1

VLAN NSP2 Edge Router

Figure 19: WiMAX Access Controller
DB4.4 Multimedia Broadband 41/97 integrated lab trial evaluation report
3.4.7 RTP retransmissions
RTP retransmissions Service offered or use case The user is watching at home some video content. The packets lost will be retransmitted to the user from the access multiplexer and thereby improves its experience. The implementation is based on the RTP/RTCP protocol. Network elements involved Video head-end (VHE) generating video content with sender reports and containing a retransmission proxy for the packets lost between the AM and the VHE. Access multiplexer (AM) with the service plane, and the RTP retransmission proxy as service/application running on top of it. Home network composed of TV screens and PCs emulating the set-top box generating the RTCP receiver reports. Impairment nodes before and after the AM to show and test the impact of the local RTP retransmission. Innovation The AM sees all the video packets passing. Keeping them a few tens of seconds allows the AM implementing retransmissions. An RTP proxy on an access multiplexer for video packet retransmission was never demonstrated before. It is the first time that RTP retransmission is used for broadcast video. Advantages This solution is scalable compared to centralised retransmissions. The memory capacity is limited and the bandwidth is reasonable. The RTP retransmission implemented in Sub-Project B was added as use case because of its importance to achieve an improved QoE of IPTV in DSL networks, as shown by the studies in TF1.7 on service enablers.

STB+TV imp air

RET impa ir
Figure 20: RTP/RTCP retransmission proxy in the access multiplexer
DB4.4 Multimedia Broadband 42/97 integrated lab trial evaluation report

Home network use cases

This section presents use cases related to the Residential Gateway only: SIP communication features | User services Fixed mobile convergence features | Remote management through TR-069 | TR-069 / UPnP proxy | Management services NetConf / TR-069 proxy | Secure OSGi Deployment (in home service GW) | UPnP/AV management (in home service GW) | The first use case high-speed Internet access of chapter 3 also demonstrates the Residential Gateway enhancements achieved in Phase II.
3.5.1 SIP comunication RGW features

TR69 ACS Edge router

Figure 23: TR-069 Remote Management
DB4.4 Multimedia Broadband 45/97 integrated lab trial evaluation report
3.5.4 Secure OSGi Deployment
Secure OSGi Deployment Service offered or use case An OSGi-based Residential Gateway only installs bundles whose origin is proven. A Service Provider digitally signs an OSGi bundle and hosts it in a Service Repository. When this bundle must be deployed, the RGW downloads it from the Service Repository, then checks if the signature is valid. If not, the deployment fails with a notification to the management console. Network elements involved A management console with JarSigner enabled, for each Service Provider; A Service Repository (OBR, OSGi Bundle Repository); Residential Gateways with SFelix installed (Secure version of Felix OSGi). Innovation OSGi deployment is secured using bundle signatures. Signature verification complies with the OSGi specifications, which is not the case with existing tools (e.g. with SFelix, signed bundles cannot be modified once deployed). Advantages Increased security.
Figure 24: Secure OSGi Deployment
DB4.4 Multimedia Broadband 46/97 integrated lab trial evaluation report
3.5.5 UPnP/AV Management Inside the Home
UPnP/AV Management Inside the Home Service offered or use case UPnP/AV Media Servers and Renderers inside the Home Network are automatically discovered. They appear on the home user's management console, for instance on his PDA. The Residential Gateway acts as the central coordinator (UPnP and UPnP/AV Control Point). Network elements involved A small device for the home user (e.g. PDA); Media Servers and Renderers; A Control Point in a Virtual Gateway. Innovation The home user's management console (JMX Console) separates presentation layer and control layer (CPU-intensive tasks). The presentation layer works on a PDA, and the control layer can be hosted in a Virtual Gateway. The two layers communicate through remote calls and notifications. The Residential Gateway automatically discovers the PDA with the monitoring console (through UPnP). It also discovers all UPnP/AV-related devices in the Home Network. The UPnP/AV Media Server works on small devices such as a SLUG. Advantages Code works on small devices. Discovery in the home user's management console is automated. See Figure 24 above.

DB4.4 Multimedia Broadband 47/97 integrated lab trial evaluation report
3.5.6 NetConf / TR-069 proxy
Service offered or use case Netconf integrated remote management enables an IETF-based standard Netconf-based management framework to manage remote TR-069 based devices. Network elements involved Netconf remote manager TR-069 /Netconf proxy (can be a netconf enabled ACS) Access multiplexer TR-069 enabled Residential Home gateway Innovation To support this use case, a TR-069/Netconf proxy has to be developed and a data model mapping was fully specified. Advantages Integrated configuration management of both core network elements (routers, switches) and home network elements through the standardized Netconf protocol.
Figure 25: NetConf / TR-069 proxy
DB4.4 Multimedia Broadband 48/97 integrated lab trial evaluation report
3.5.7 TR-069 / UPnP proxy
TR-069 / UPnP Proxy Service offered or use case The user has subscribed to a service offering a news feed. The user expects to review the latest news as soon as he opens his media render (TV). Upon the power-up of the users media renderer (TV), the ACS configures (if needed) the involved elements (renderer, media server, RGW) and alerts the media server to get the latest news file. Then the ACS informs the renderer to play the file from the media server. Network elements involved ACS: The ACS needs to be UPnP enabled it has to understand UPnP messages in order to be able to manage UPnP devices through the Proxy UPnP/TR-069 Proxy: This is a separate program (or it could be incorporated in the TR-069 client of the RGW) that can be run from the RGW or from a device inside the LAN UPnP Media Server UPnP Media Renderer Innovation UPnP devices on the local network are managed remotely from ACS. Without the Proxy UPnP were inaccessible outside the local network. Advantages The ACS now has access to the UPnP devices of the home network. Traffic going in the public network is very little due to filtering functions of Proxy. No changes to the UPnP or TR-069 protocols. New services can be defined.

Home network

Public network

Media Renderer

Media Server
TR69 ACS Southbound RGW TR69/UPnP I/F Proxy
Figure 26: UPnP / TR-069 network topology
This use case was demonstrated during the Broadband Europe conference in Geneva in December 2006.
DB4.4 Multimedia Broadband 49/97 integrated lab trial evaluation report

4 TEST RESULTS

This chapter presents the results of the testing activities carried out in the different lab trials.
Measurement of Layer 2 network parameters
Objective: The objective of this test is to validate the possibilities of multicast transport within the demonstrator network including ADSL2+ and VDSL2 line. Because the demonstrator part of DT in Berlin is mainly focused on TVoIP services the most interesting network parameters, like throughput, latency and latency distribution are related to treatment of multicast traffic. Procedure: To measure the network parameters described above a packet generator / analyzer was connected at the one hand to the edge router instead of the TVoIP head-end and to the other hand to the RGW instead of the STB. Then a packet stream of 1280 Byte packets was send in downstream direction and analyzed. Results: The results in the following table and figures illustrate a large potential of VDSL2 in context of providing bit rate consuming HD content. In the table the maximum throughput and average latency are depicted. Figure 27 shows for ADSL2+ that more than 95% of all packets have latency between 3 and 5 ms - measured at 95% load of maximum throughput. For VDSL2 it shows that 99.9% of all packets are below 3 ms and more than 75% are between 2 and 3 ms - measured at 80% load. In overload conditions the total average latency increase but the distribution doesn't spread much more. ADSL2+ Throughput Ave. Latency (overload) 11.6 Mbps 4.1 ms (ms) VDSLMbps 2 ms (12.7 ms)

Objective: The objective is to evaluate the capabilities of transrating functionality which is implemented in the TVoIP headend. Procedure: The transrating function was enabled for different available streams / channels and a specific maximum bandwidth was adjusted over the management application (see Figure 30). In the meantime the FEC functionality was enabled and disabled. On the TV sets the quality of the different channels was observed. DB4.4 Multimedia Broadband 53/97 integrated lab trial evaluation report Public
Figure 30: Transrate configuration
Results: During the evaluation phase a decreasing by 30% bandwidth for MPEG2 and MPEG4 SD streams could be obtained - with and without FEC. On low bit rate MPEG2 streams the video quality is not sufficient anymore, but this is not due to the transrating algorithm but rather to the final rate after transrating (see also Figure 31). The bandwidth decreasing for high bit rate streams doesn't leads to a decreasing of experienced video quality.
Figure 31: transrating of low bit rate MPEG2 stream
4.2.3 Forward Error Correction
Objective: The objective is to evaluate the capabilities of Forward Error Correction functionality which is implemented in the TVoIP headend.
DB4.4 Multimedia Broadband 54/97 integrated lab trial evaluation report
Procedure: Two different kinds of packet loss were inserted into the network at the one hand bursty packet loss (5s no loss followed by 1s loss) and to the other hand random packet loss. The disturbed streams were displayed over two STBs - one with FEC capabilities and another without - and the experienced quality was compared. The amount of packet loss was increased over test duration. Results: The implemented FEC algorithm is able to correct up to 5% random packet loss in aggregation and/or home network. In Figure 32 two different results of network packet loss are displayed which were completely recovered by the implemented algorithm. For random packet loss the recovering algorithm works very stable.
Figure 32: TV screen shots with 1% and 4% random packet loss and no FEC
The bursty packet loss (see also Figure 33) can not be completely recovered by the algorithm. The reason is the current configuration of FEC algorithm which allows a recovering capacity of 10 consecutive packets loss each 100 packets (maximum configurable capacity being 20 consecutive packets loss each 100 packets ) and the injected bursty packet loss leads to a burst of 285 packets loss each 1425 packets. The result is a frozen screen for a short time. Unfortunately it was not possible to change the setting for bursty packet loss during test period.

DB4.4 Multimedia Broadband 65/97 integrated lab trial evaluation report
Figure 46 shows the first response time obtained in 10 different samples:

Synchronization time

time (seconds) home1 home2
Figure 46: Service Plane "First Response Time" sync measurements
Summarizing: The minimum time response of the SP is 3,87 seconds. The average time response of the SP is 31,45 seconds (discarding the last sample). The maximum time response of the SP is 325 seconds. Approximately 10% of SIP phone synchronizations take 3 minutes to register. It can be accelerated by rebooting the SIP phones thus forcing them to send a REGISTER, instead of waiting for its standard behavior which is to delay the registers when the service has been inactive for a while. Figure 47 shows the delay between the moment when the stop button is clicked on the Monit web page and the user desynchronizes with the service, i.e. the red light on the SIP phone starts flickering.
DB4.4 Multimedia Broadband 66/97 integrated lab trial evaluation report

Desynchronization time

Figure 47: Service Plane "First Response Time" desync measurements
Summarizing: The minimum time response of the SP is 4,75 seconds. The average time response of the SP is 15,578 seconds. The maximum time response of the SP is 30,86 seconds. These tests are very important as they shows the big difference between the way of provisioning new services in current access networks and the innovative solution proposed by MUSE. In current networks, the installation of a new service requires rebooting several network equipments. The reboot can take half an hour in the best case but, as each reboot needs to be carefully programmed, the user may have to wait several hours until the service is available and ready to be used. Moreover, during the reboot the user will loose other services such as broadband access or TVoIP. By using the Service Plane, the AM does not need to be rebooted and the maximum time the user has to wait since a new service is requested and this service is ready to use may be about 30 seconds. That is, the configured time in the SIP phone to retry the REGISTER. This time can be kept to the minimum by asking the user to reboot the phone. The perception from the end user side will be that new services are deployed/upgraded almost in real time. Besides, the user will not notice any interruption in the availability of other services. As a reference, the total download time that a service upgrade (and downgrade) takes in the Service Plane has been measured: The mean delay of the upgrade of a service is 94,08 seconds. The mean delay of the downgrade of a service is 54,12 seconds.

4.4.4 Evaluation of service plane bandwidth requirements
Objective: to measure the throughput required for the service set-up.
DB4.4 Multimedia Broadband 67/97 integrated lab trial evaluation report
Procedure: Firstly start the tcpdump software on the management PC to capture data transfer between the Service plane and the management PC. Simultaneously start another tcpdump sniffer on the user side. High load of background traffic is also introduced in the system to measure with the same program the network availability and blocking probability. Results: According to TF4 Test Suite, the minimum performance requirements for web browsing and downloads are: Network availability >99%. Blocking probability <0.1%). Application set-up time < 1s). Connection set-up time (<3s). The signalling throughput was measured in two segments: The signalling throughput between the management PC and the Service Plane, when a service is started for one NSP is 114 Kbps. The signalling throughput between the Service Plane and the SIP phone, when a service is stopped and is started again for one NSP is 0,7 Kbps.
Figure 48: Signalling throughput when a SIP phone syncs with the service
The network availability and blocking probability requirements are logically fulfilled because these measurements were taken without any other kind of traffic overloading the links and access nodes. During the measured time no packet drop occurred. The Refresh time of the Monit Service Manager is approximately 5,5 seconds and could be configured to another value. The connection set-up time in this case is the delay between the manager types on a web browser the IP address of the Sepia Board, and the Monit page of Service Plane appears on the screen. This delay, measured with a stopwatch, is approximately 500ms, less than 1 second. The required throughput for signalling is almost irrelevant, and the results are compliant toTF4 specifications.
DB4.4 Multimedia Broadband 68/97 integrated lab trial evaluation report
4.4.5 Analysis of Service Plane security risks
Objective: The objective of these tests was to verify the access control mechanisms of the Service Plane, and whether the Sepia Board assures data confidentially and data integrity. Procedure: For that purpose, Nmap and Nessus tools were installed on the management PC. It must be noticed that the attacks were performed within the management VLAN which will not be available in any case to end users. Some of the results identified by the security tools as risks are not real threats but a necessary path to manage the SP. Results: Nmap ("Network Mapper") is a free and open source utility for network exploration and security auditing. Nmap uses raw IP packets in novel ways to determine what hosts are available on the network, what services (application name and version) those hosts are offering, what operating systems (and OS versions) they are running, what type of packet filters/firewalls are in use, etc. Figure 49 shows the result of the scan.

Call NSP1<->NSP2 (without upgrade) Call NSP1<->NSP2 (upgraded) Call NSP1<->NSP1 (upgraded)
96.9 ms 81.4 ms not measured (expected below NSP1<->NSP2)
Table 8: D-SBC voice quality results (Berlin)
All results with latest update file are good. The reason for results below 4.2 is the fluctuations over time (see also Figure 57). A difference between different directions could not be observed.
DB4.4 Multimedia Broadband 76/97 integrated lab trial evaluation report
Figure 57: MOS and Delay for call NSP1<->NSP2 (upgraded) 4.4.6.5 Performance
Performance tests were carried out on the first version 2 in ALCB as part of MB1.8. We report here the voice results. These results were also reported in the Broadband Europe paper [16]. The D-SBC functionality requires intensive packet manipulations like NAT-pinholing and rate limiting. Table 9 shows that the implemented D-SBC supports 1800 simultaneous VoIP sessions, when only NAT is performed on the voice traffic. This translates to 7200 VoIP terminals with a traffic of 0,25 Erlang per terminal aggregated on the access node. When also rate limiting is applied per session, the number of simultaneous sessions is reduced to 300 simultaneous voice sessions. This means that 1200 VoIP terminals with a traffic of 0,25 Erlang per terminal can be aggregated on the access node.
Type NAT-pinholing only NAT-pinholing + Rate Limiting Bitrate

[KBPS]

Max Number Sessions 1800 300
Simultaneous Setups 256 256
Table 9: D-SBC performance for voice tests
It can be concluded for the NAT-pinholing case, that the capacity is sufficient to handle all terminals of an access multiplexer and there is enough room to run additional services in parallel. However in the case where rate-limiting is enabled, the performance drops, and less headroom is available for running other services. Headroom could be created either by optimizing the software algorithms or by using hardware acceleration. An alternative solution with the current SW implementation could be to perform NAT for all sessions, but to perform rate limiting to only a subset of the sessions. This subset could be selected statistically and by evaluating how much headroom is still available to perform the rate-limiting.
4.4.7 Evaluation of TCP monitoring
Objective: Objective is the evaluation of TCP monitoring capabilities for transparent statistics monitoring. DB4.4 Multimedia Broadband 77/97 integrated lab trial evaluation report Public
Procedure: This NSP related service has to be started on the service plane and afterwards the monitoring application displays statistics which have to be analyzed. Results: The statistics delivered by the new implemented ANTMA algorithm can compared simultaneously with the results of two other calculation algorithms. Furthermore impairments were injected which offer the possibility to compare the statistics with the visual distortion of the streamed video (TCP based VoD streaming) and the actual injected impairments. All these correlation possibilities show the proper work of ANTMA algorithm. The streaming is still possible if TCP monitoring is switched off on Service Plane. The screenshot below shows a few seconds without packet loss and afterwards 3% random packet loss.

Call blocking: it is possible to disallow or to allow a list of particular phones. For example, when the phone number 100 is disallowed in the internal SIP phone (222222), it does not accept incoming calls from the analog phone (100). Call waiting: RGW is able to maintain the state of a hold call, while one of the parties establishes a call with another phone in the network. Auto-answer: The phone, connected to the RGW, can answer automatically the calls without the user has to pick up the phone.
Local dialling within the home network does not need any interaction with the other parts of the SIP network. And thanks to the B2BUA dial plan the user can make calls to the SIP VoIP interface or to the PSTN FXO interface.
4.5.1.3 Path followed by the RTP flow
Objective: Notice the path followed by RTP flow. Procedure: Establish an internal call between two phones connected to the same RGW with B2BUA. Monitor the network using wireshark to see the traffic and establish the path followed. The same mechanism will be followed for an external call, between a SIP phone linked to the B2BUA and another remote SIP phone. Results: RTP flow goes through the RGW when the SIP phones belong to the same RGW. Nevertheless, RTP traffic has to reach the external SIP server when phones belong to different RGWs. (See Figure 65).
DB4.4 Multimedia Broadband 83/97 integrated lab trial evaluation report
External SIP phone (333333) DHCP pool 1 11.1.2.1/16
Sip phone X-lite (500) RGW with B2BUA
Analog phone (100) SIP phone (222222)

HOME 1, NSP1

Figure 65: Path followed by RTP flow in an internal call and an external call
It means that the RGW with B2BUA acts as SIP Server, and there is no need of other network equipment when making internal calls.

4.5.1.4 NAT and firewall

Objective: Check the support for NAT and firewalls. Procedure: Link the phones behind RGWs with the following implementation for NAT and firewall:
{Administrator}[nat]=>iflist Interface NAT loop disabled ipInternet enabled LocalNetwork transparent
Figure 66: Interfaces that implement NAT on the RGW
{Administrator}=>firewall {Administrator}[firewall]=>list Config ====== State Keep TcpChecks TcpWindow UdpChecks IcmpChecks LogDefault LogThreshold Modules ======= Module

: : : : : : : :

enabled disabled none 65536 enabled enabled disabled enabled
DB4.4 Multimedia Broadband 84/97 integrated lab trial evaluation report
---------------------------------------------------------------------------------------------------------fire enabled Firewall Administration Module sink, forward, source system_service enabled System Service Module sink, source level enabled Level Module forward host_service enabled Host Service Module forward multicast enabled Multicast Forwarding Module forward Hooks ===== Hook Prio Module -------------------------------------sink 100 fire 40 system_service forward 100 fire 80 host_service 60 level 20 multicast source 100 fire 40 system_service

DB4.4 Multimedia Broadband 88/97 integrated lab trial evaluation report
The following ports were open at the beginning of the scan but are now closed: Port Port Port Port 1723 was 443 was 23 was 80 was detected as being open but is detected as being open but detected as being open but detected as being open but now unresponsive. is now closed. is now closed. is now closed. the following administrator detected the may need to
This might be an availability problem related which might be due to reason: This Vulnerability Scanner has been blacklisted by the system or by automatic intrusion detection/prevention systems which have vulnerability assessment. This is a very good thing. In any case, the audit of the remote host might be incomplete and be done again. Risk Factor: none.
8. domain (53/udp): A DNS server is running on this port. If you do not use it, disable it. Risk Factor: low. 9. domain (53/tcp): A DNS server is running on this port but it only answers to UDP requests. This means that TCP requests are blocked by a firewall. This configuration is not RFC-compliant. Contrary to common belief, TCP transport is not restricted to zone transfers (AXFR): Answers bigger than 512 bytes are always transmitted over TCP. For all other requests, UDP is only 'preferred' for performance reasons, i.e. RFC1035 (STD0013) does not forbid a DNS client from issuing its queries directly over TCP. Whether the DNS server will never return answers bigger than 512 bytes and that the client software prefers UDP (which is nearly certain), you may disregard this message. Read RFC1035 (STD0013) for more information. Risk Factor: none. These results must be compared with the output obtained for RGW without B2BUA, in order to conclude whether these vulnerabilities have been caused by the added B2BUA functionalities or not. NESSUS results for RGW without B2BUA informed the following differences with respect of the previous case: o o FTP port (21) is also open, but there is not any hole. The service closed the connection after 0 seconds without sending any data. It might be protected by some TCP wrapper. The only port which is closed after scanning with NESSUS is the port 443.
We have monitored the web interface of RGW during the scan with NESSUS, to verify security mechanisms implemented by the RGW with B2BUA. Intrusion detection mechanisms are supposed to protect against:
DB4.4 Multimedia Broadband 89/97 integrated lab trial evaluation report
fragment_sweep, zero-length_fragment_size, small_fragment_size, fragment_size_overrun, fragment_overlap, fragment_out-of-order, ip_protocol_scan, tcp_port_scan, tcp_syn_scan, stealth_tcp_null_scan, stealth_tcp_fin_scan, stealth_tcp_xmas_scan, stealth_tcp_full_xmas_scan, stealth_tcp_vecna_scan, stealth_tcp_syn-fin_scan, udp_port_scan, ping_sweep_scan, tcp_syn_flood, udp_flood, ping_flood, icmp_unreachable_storm, smurf_broadcast_attack, smurf_storm_attack, fraggle_broadcast_attack, fraggle_storm_attack, land_attack, tcp_null_port, tcp_data_on_syn_segment, tcp_invalid_urgent_offset, udp_null_port, icmp_type_unknown, icmp_code_unknown, ip_zero_payload, tcp_rate_limiting, udp_rate_limiting, icmp_rate_limiting, ip_rate_limiting. During the scan with NESSUS the counters of some intrusions are increasing in real time, till: tcp_syn_scan = 1. udp_port_scan = 1. udp_flood = 3. tcp_null_port = 3. icmp_code_unknown = 3. tcp_rate_limiting = 6809. It means that RGW is detecting these attacks in its system. However, in the final part of the scan, the web interface freezes and does not function in a normal way. Finally, when the scan with Nessus software is finished, all counters suddenly reset and are equals to zero, without any interaction of users or the administrator. A user, that monitors the counters after the scanning, may think that no intrusion has attacked the system. This is because the automatic intrusion detection of the RGW has detected the vulnerability assessment and has closed some ports temporarily to protect the system. This results are very good since they mean that the security mechanisms of RGW with B2BUA are protecting properly against this attempt of intrusion.