R522/D523 Public p.1/90 30/04/03 HARMONICS „H ybrid A ccess R e-configurable M ultiwavelength O ptical N etworks for I P-based C ommunication S ervices“ R522 - Experiments including user services, and system performance evaluation & D523 – Evaluation of field trial experiences -Public version - Project number / name: IST-1999-11719 / HARMONICS Operative Commencement Date: July 23 th , 2001 Document number: R522 & D523 Title of Document: Experiments including user services, and system performance evaluation & Evaluation of field trial experiences Version 2.4 Editors Frank Geilhardt, Jeroen Wellen Authors Mirko Adamy (TSN), Frank Geilhardt (TSN), Konstantinos Oikonomou (ICOM), Jeroen Wellen (LUC), Brecht Vermeulen (IMEC) Abstract: This document describes and evaluates the experiments of the HARMONICS Field trial that includes a Measurement analysis, a service demonstration and a User-trial. Finally it gives an evaluation of the HARMONICS system elements.
Transcript
R522/D523 Public
p.1/90
30/04/03
HARMONICS
„Hybrid Access Re-configurable Multiwavelength Optical Networks for IP-based Communication Services“
R522 - Experiments including user services, and system performance evaluation
& D523 – Evaluation of field trial experiences
-Public version -
Project number / name: IST-1999-11719 / HARMONICS Operative Commencement Date: July 23th , 2001 Document number: R522 & D523 Title of Document: Experiments including user services, and system
performance evaluation & Evaluation of field trial experiences
Version 2.4 Editors Frank Geilhardt, Jeroen Wellen Authors Mirko Adamy (TSN), Frank Geilhardt (TSN),
Abstract: This document describes and evaluates the experiments of the HARMONICS Field trial that includes a Measurement analysis, a service demonstration and a User-trial. Finally it gives an evaluation of the HARMONICS system elements.
R522/D523 Public
p.2/90
30/04/03
Table of Contents LIST OF ABBREVIATIONS................................................................................................................................4
2.4.1 Performance analysis of the HARMONICS System.................................................................... 14 2.4.2 Performance analysis of the Last Mile solutions........................................................................ 19 2.4.3 Performance analysis between Berlin and Darmstadt ............................................................... 35 2.4.4 QoS analysis of HARMONICS System......................................................................................... 39 2.4.5 QoS testing in the loop in interaction of different network levels.............................................. 41
3 SERVICE DEMONSTRATIONS AND USER TRIALS ...................................................................... 47 3.1 INTRODUCTION ....................................................................................................................................... 47 3.2 TEST CONCEPT ........................................................................................................................................ 47 3.3 FIELD TRIAL SERVICES ........................................................................................................................... 47
3.3.1 Video-streaming applications (real time / non real time)........................................................... 48 3.3.2 Interactive applications ................................................................................................................ 49 3.3.3 Best effort applications................................................................................................................. 50
3.4 FIELD TRIAL TESTS ................................................................................................................................. 50 3.4.1 Preparation.................................................................................................................................... 50 3.4.2 ‘Test weeks’ with specific test plan .............................................................................................. 51 3.4.3 Free tests and long time demonstration....................................................................................... 54 3.4.4 Evaluation of the trial experiences............................................................................................... 54
3.5 CONCLUSIONS ......................................................................................................................................... 56 4 SUMMARY OF THE HARMONICS OPTICAL LAB TRIAL........................................................... 57
4.1 SCOPE OF THE OPTICAL LAB TRIAL ........................................................................................................ 57 4.2 THE OLT................................................................................................................................................. 58 4.3 OPTICAL PROTECTION SWITCH ............................................................................................................... 58 4.4 BI-DIRECTIONAL EDFA ......................................................................................................................... 59 4.5 OPTICAL CROSS-CONNECT ..................................................................................................................... 60
4.7.1 Optical fibre (SSMF)..................................................................................................................... 64 4.7.2 The local splitting centre .............................................................................................................. 64
4.8 THE ONU BURST MODE TRANSMITTER ................................................................................................. 65 4.9 OPTICAL SYSTEM EXPERIMENTS AND SPECIFICATIONS ......................................................................... 68
4.10 CONCLUSIONS AND RECOMMENDATIONS FROM THE OPTICAL LAB TRIAL........................................... 72 4.10.1 Conclusions.................................................................................................................................... 72 4.10.2 Recommendations.......................................................................................................................... 72
5 OVERVIEW OF THE HIPERLAN/2 WIRELESS TECHNOLOGY RESULTS ............................ 73
6 EVALUATION OF THE HARMONICS SYSTEM ELEMENTS ...................................................... 77 6.1 LNCS ...................................................................................................................................................... 77
6.2 EDGE AND LEAF ROUTERS..................................................................................................................... 79 6.2.1 Description and goals ................................................................................................................... 79 6.2.2 Improvements and further work ................................................................................................... 79
7.2.1 HiperLAN/2.................................................................................................................................... 89 7.2.2 VDSL and other technologies....................................................................................................... 89
7.3 THE MANAGEMENT ARCHITECTURE ..................................................................................................... 90 7.4 FIELD TRIAL ............................................................................................................................................ 90 7.5 OVERALL CONCLUSIONS AND OUTLOOK............................................................................................... 90
List of abbreviations A/V Audio/Video AF Assured Forwarding AP Access Point ATM Asynchronous Transmission Mode BE Best Effort BER Bit Error Ratio BMR Burst-Mode Receiver BPSK Bit Phase Shift Keying CORBA Common Object Request Broker Architecture CoS Class of Service CPE Customer Premises Equipment CPU Central Processor Unit CR Core Router CRC Cyclic Redundancy Check DivX Digital Video (MPEG4 codec) DLC Data Link Control DS, DiffServ Differentiated Services DSCP DiffServ Code Point DUT Device Under Test DVD Digital Versatile Disk EF Expedited Forwarding EoX Ethernet over X ER Edge Router FE Fast Ethernet FTP File Transfer Protocol G(b)E Gigabit Ethernet GUI Graphical User Interface HEC Header Error Correction HTML Hyper Text Markup Language ICMP Internet Control Message Protocol IDL Interface Definition Language IntServ Integrated Services IP Internet Protocol ISDN Integrated Services Digital Network LAN Local Area Network LMN Last Mile Network LNC Layer Network Coordinator LR Leaf Router MAC Medium Access Control MAN Metropolitan Area Network MIB Management Information Base MM Multi Mode MPEG Motion Pictures Expert Group MT Mobile Terminal OE Optical Ethernet OFN Optical Feeder Network
R522/D523 Public
p.5/90
30/04/03
OLT Optical Line Termination ONU Optical Network Unit ORB Object Request Broker OSI Open Systems Interconnection OXC Optical Cross Connect PBX Private Branch Exchange PC Personal Computer PDU Protocol Data Unit PER Packet Error Rate POF Polymer Optical Fibre PON Passive Optical Network POTS Plain Old Telephony Service PSTN Public Switched Telephony Network QoS Quality of Service RM Resource Manager RSVP Reservation Protocol SLA Service Level Agreement SM Single Mode SNR Signal-to-Noise Ratio (IP)SSCS (IP) Service Specific Convergence Sub layer SVCD Super Video Compact Disc TCP Transmission Control protocol TDMA Time Division Multiple Access TV Television UDP User Datagram Protocol UTP Unshielded Twisted Pair VDSL Very high speed Digital Subscriber Line VoD Video on Demand VoIP Voice over IP VPN Virtual private Network WAN Wide Area Network (C/D)WDM (Coarse/Dense) Wavelength Division Multiplexing
R522/D523 Public
p.6/90
30/04/03
Summary This public document describes and evaluates the experiments undertaken during the HARMONICS Field Trial. Other key results that were originally projected to be part of trial but ended up in separate lab trials, have also been included to obtain a complete view of the project outcome. This involves the lab trial of the optical feeder network and the HiperLAN/2 tests. In the HARMONICS Field Trial a practical end-to-end network was realised that integrates the HARMONICS system with customers in a near-real environment and real services. An interconnection of the HARMONICS Access Network with other test beds and network levels was shown. During the Field trial the HARMONICS network fed four Last-Mile-Network systems based on Ethernet-over-VDSL (EoVDSL), Optical Ethernet, Ethernet-over-Polymer Optical Fibre (EoPOF) and WLAN. Additionally, MAN and WAN test beds that are based on Carrier-Class Optical Switched Ethernet and DWDM could be used in order to demonstrate an end-to-end solution over a distance of about 750 km. The first section of this document describes and evaluates the measuring experiments of the Field trial. Essentially the measuring experiments can be classed into two main groups; Traditional performance testing & QoS testing. The primary analysis determined the performance limits given by the trial equipment, which then led to the foundation of the QoS analysis. The second part of this document describes the users’ experience evaluation under the demonstration of each application delivered under various last mile technologies. In the Field Trial six IP-based services were implemented, Video-on-Demand, Near-Video-on-Demand, TV-Live-Streaming, Gaming, NetMeeting and Internet Access. During an user-trial over a period of five months real users had access to the HARMONICS platform and could use the IP services. The users had to document their experiences regarding service quality and system handling. The third part gives a summary of the technology results of issues that were tested outside the scope of the field trial: The optical lab trial (chapter 4) and the HiperLAN/2 wireless tests (chapter 5). The final part of this document (chapter 6) gives a short overview of the outcome of all the demonstrated HARMONICS elements with respect to the original revised HARMONICS Objectives. It discusses the results of the Measuring analysis and the Field Trial Demonstration and comments possible improvements regarding each system element.
R522/D523 Public
p.7/90
30/04/03
Introduction
OXC
ONU
ONU
ONU
FTTB/H
FTTC/FTTCab
VDSL
UMTS
HFC
ONU
OLT
Optical Feeder Network
WDM PON
λ1
λ1
1
M11
NRA
WG
AW
G
ME
LSC1 LSC2 LSC3
Core Network Last Mile Network
EdgeRouter
LeafRouter
K
λL
λL
1
M
1
N
Protection ring
Figure 0-1: Outline of the Harmonics system
The basis of the HARMONICS concept is a dynamically switched Wavelength Division Multiplex Passive Optical Network (WDM PON), which facilitates a multi-Gigabit capacity to a large number of Optical Network Units (ONUs). The flexibility of the system is realised by an optical cross connect (OXC), which performs fast optical packet switching between the ONUs and a number of receivers at the optical line termination (OLT). This way it is possible to redirect the capacity to different locations, depending on the load. A novel wavelength-and-time medium access control protocol is designed to control the time division multiple access (TDMA) of the ONUs on all wavelength channels as well as actuating the OXC. The concept is depicted in Figure 0-1. The Optical Feeder Network (OFN) provides an optical aggregation and distribution network for various last-mile access technologies. The HARMONICS system allows any IP based technology to be connected. During the project VDSL and HiperLAN/2 systems were studied in more detail, while others were demonstrated in the field trial. One of the main challenges of IP based access systems is a proper way to implement Quality of Service (QoS) management. A key objective of HARMONICS was to provide a network Resource Management (RM) that supports end-to-end QoS using the Differentiated Services (DiffServ) approach. Layer Network Co-ordinator (LNC) entities manage the networks of the different domains (the OFN between Edge and Leaf-Routers, as well as the access technology) at the DiffServ level and the network resources depending on the specific technology. Domain LNCs negotiate Service Level Agreements (SLAs) while at lower levels, reservations can be made directly by applications, or may be picked up by the Leaf Routers from RSVP messages. A CORBA control plane protocol has been devised to perform the communication between the different elements. A Resource Manager (RM) again translates reservations to proper configurations of the OFN wavelength-and-time MAC. This way an end-to-end reservation of capacity for traffic flows will be established to guarantee the QoS. In Figure 0-2 an overview of the management elements is shown.
R522/D523 Public
p.8/90
30/04/03
CoreRouter
Core Network EdgeRouter
LNCOFN
ResourceManager
LNCDSLNCDS
EdgeRouter
WDM PON LeafRouter
MAC
SLA
LNCLMN
AccessPoint
Last Mile NetworkHost
Figure 0-2: The Harmonics control plane architecture, providing flow-based QoS control by
spanning core, edge and access domains
Reservations are made on the basis of flow information like IP source and destination address and TCP/UDP port addresses (5-tupple classification). The management system does a flow admission control within the limits of the Service Level Agreement (SLA) and configures the Leaf Routers to mark and police the reserved flows. In case of traffic congestion (of different service classes) the high priority traffic is being favoured above low priority traffic by an implemented priority schedule scheme. Low priority traffic (e.g. best-effort) is never starved as the admission control limits the high QoS reservations to only a part of the available bandwidth. This document describes and evaluates the experiments of the HARMONICS Lab and Field trials. As shown in Figure 0-3 the Field trial experiments are segmented in the two groups Demonstration and Measurement analysis. Since the Optical Feeder Network was emulated during the field trial, also the results of the Optical Lab trial are included for the sake of completeness of the project results.
Measurement:• of the network performance• of the QoS functionality
Harmonics Field Trialexperiment
Demonstration:• of the HARMONICS system in
cooperation with othertransmission technologies andnetwork levels
• of the IP-Services
Harmonics Lab Trialexperiments
Optical Lab Trial:• Demonstration of optical
switching• Demonstration of modules• Performance measurements
HiperLAN/2:• Radio tests
Figure 0-3: Main segment of the Harmonics Field and Labs trials
The Field Trial Demonstration allows the subjective evaluation of the Harmonics service quality by the user, in the simplest case the quality of a video transmission or Internet session. So, the advantages of the Harmonics system in cooperation with all transmission technologies and network levels can be shown in a easy visual way. The Measurement analysis permits an objective examination and evaluation, whereas the results will be presented for performance facts like Throughput, Frame Loss, Latency and Jitter. A very important part of the Measurement analysis is verification of the QoS feasibility respecting the IP traffic.
R522/D523 Public
p.9/90
30/04/03
1 Field trial set-up The Field trial test bed of the HARMONICS Field trial consists of three locations: one location in Darmstadt and two sites in Berlin, Atrium and Winterfeldstrasse. The Atrium and the Darmstadt location are DT office buildings with several laboratories. On the one hand it offers the possibility to place the HARMONICS techniques and on the other hand “Friendly” users are available to test the system. Figure 1-1 gives a topographic overview of the field trial sites. The distances between the Berlin-Atrium and the Berlin-Winterfeldstrasse of about 6.8 km and the distance between Berlin and Darmstadt is about 750 km.
Berlin (269)
Hamburg
Berlin
Darmstadt
Frankfurt
DD
Hannover
München
Berlin (269)
Hamburg
Berlin
Darmstadt
Frankfurt
DHannover
München
Berlin Winterfeldstr.
Berlin Atrium
~750km
Berlin (269)
Hamburg
Berlin
Darmstadt
Frankfurt
DD
Hannover
München
Berlin (269)
Hamburg
Berlin
Darmstadt
Frankfurt
DHannover
München
Berlin Winterfeldstr.
Berlin Atrium
~750km
Figure 1-1: Field trial locations
Figure 1-2 shows the schematic overview of the Field trial architecture. In order to demonstrate the feasibility of the HARMONICS system in cooperation with other transmission technologies the Field trial integrates:
Additionally, the Field trial emulates the different network levels WAN, MAN, Access and Last Mile. A fundamental part of the HARMONICS Field trial is the Management system that enables the QoS management. There are two MAN environments, one in Berlin and one in Darmstadt, which were designed with Optical Switched Ethernet technique and consist of Ethernet-Carrier-Class-Equipment. Both MANs are connected over a WAN using Ethernet over WDM technology. A Service network provides the users services such as Video and Gaming. The Access network, emulated by the HARMONICS system, feeds four Last-Mile networks using EoVDSL, HiperLAN/WLAN, Optical Ethernet and EoPOF. The Ethernet over VDSL Last Mile Network is based on the commercial networking solution Long-Reach Ethernet (LRE) from Cisco. LRE allows the transmission of Ethernet over the standard telephone-grade wire infrastructure (cat. 1/2/3) at speeds from 5 to 15 Mbit/s and distances up to 1,500 metre. It consists of an EoVDSL switch (Cisco Catalyst 2900 LRE XL) which functions as DSLAM and EoVDSL modems (Cisco 575 LRE) which will be used as CPE devices. The Leaf Router and the DSLAM are separate devices and will be connected over an Ethernet based 100Base-TX link. Two wireless access solutions are used in the trials. The HiperLAN/2 prototype is used for performance measurements and to perform the QoS tests. For mobile service demonstration a 802.11a LAN platform is
R522/D523 Public
p.10/90
30/04/03
used. This platform is a commercial WLAN system from Intel and consists of an Access Point (AP) with two Mobile Terminals (MTs). The Last Mile solution “Optical Ethernet” based on a product of the vendor MICROSENS. It consists of small manageable Ethernet switches and media converters. The switch used as CPE device provides four 10/100 ports and one optical Fast Ethernet uplink (single mode) with a max reach of up to 20 km. The media converter converts electrical Fast Ethernet (FE) to optical FE (single mode, 20 km). The electrical side of the media converter is connected to the Leaf Router, the optical side is able to bridge a distance of up to 20 km using single mode fibres. The Last Mile solution Ethernet over Polymer Optical Fibre “EoPOF” is based on the product “T2P” from the German manufacturer Wiesemann & Theis GmbH (W&T). It consists of media converters which converts one 10Base-T port to a POF port with a max reach of 100 metre using duplex POF fibre cable with a core diameter of 980 µm. Two EoPOF links are provided during the Field trial which are connected to the Leaf Router over a Ethernet switch (see Figure 1-3)
Figure 1-2: Schematic overview of Field trial system set-up
R522/D523 Public
p.11/90
30/04/03
Figure 1-3: Field trial System set-up
Figure 1-3 shows the Field trial System set-up including the Remote administration function in the Field trial locations Darmstadt, Winterfeldstrasse and Atrium. In Darmstadt, the HARMONICS Service network is located. Both MAN environments, in Berlin and in Darmstadt, are connected via a WDM link. The actual HARMONICS system, defined by the HARMONICS project, is distributed over the Berlin locations Atrium and the Winterfeldstrasse. The Last Mile networks based on Opt. Ethernet, EoVDSL, HiperLAN/WLAN and EoPOF are located in the Atrium.
2 Measurement analysis
2.1 Traditional performance testing To describe the performance characteristics of a network or a network device a number of tests can be used. Essentially all performance tests of the Field trial and the used terminology is based on the following Requests for Comments (RFC): RFC 1242: Benchmarking Technology for Network Interconnection Device
• This memorandum discusses and defines a number of terms that are used to describe performance benchmarking tests and its results.
RFC 2544: Benchmarking Methodology for Network Interconnect Device • This memo discusses and defines a number of tests that may be used to describe the
performance characteristics of a network interconnecting device and it describes specific formats for reporting the results of the tests.
RFC 2285: Benchmarking Methodology for LAN Switching Devices • This document defines the terminology for the benchmarking of local area network (LAN)
switching devices. It defines terms like forwarding performance, congestion control, latency, address handling, and filtering.
These RFCs can be seen as the quasi standard for performance tests that were developed of “The Internet Society” and the Internet Engineering Task Force (IETF).
R522/D523 Public
p.12/90
30/04/03
Table 2-1: Definitions of the RFCs 1242, 2544 and 2285
RFC Term Description
1242/2544 Throughput “The maximum rate at which none of the offered frames are dropped by the device.” (RFC-1242)
1242/2544 Latency
Total delay of an device or system. “For store and forward devices: The time interval starting when the last bit of the input frame reaches the input port and ending when the first bit of the output frame is seen on the output port. For bit forwarding devices: The time interval starting when the end of the first bit of the input frame reaches the input port and ending when the start of the first bit of the output frame is seen on the output port.” (RFC-1242)
1242/2544 Frame Loss rate “Percentage of frames that should have been forwarded by a network device under steady state (constant) load that were not forwarded due to lack of resources.” (RFC-1242)
2544 Frame sizes “All of the described tests SHOULD be performed at a number of frame sizes.”…” Frame sizes to be used on Ethernet: 64, 128, 256, 512, 1024, 1280, 1518” (RFC-2544)
2544 Trial duration “The duration of the test portion of each trial SHOULD be at least 60 seconds.” (RFC-2544)
Table 2-1 lists some important definitions of the RFCs 1242, 2544 and 2285 that are part of the Field trial performance tests.
2.2 QoS testing The traditional performance testing focused on a per-port basis, addressing the evaluation of the performance of each port such as the maximum throughput, the packet loss and the average latency of the network device. To test the HARMONICS System the traditional testing is necessary, but it is not enough for evaluating the QoS functionality. In the following, some additional aspects regarding the Field trial QoS testing are described.
2.2.1 Flow-based measuring In the Harmonics network, different applications are multiplexed onto a single device port, combining different CoS traffic. In order to evaluate the QoS feasibility of a network the test must address individual traffic flows. A flow-based measuring is the foundation of the QoS testing. The measuring equipment has to be able to provide flow-based measuring procedures.
2.2.2 QoS metrics The Harmonics concept aims at IP service providing. IP is a “best-effort” protocol that is not able to guarantee particular performance characteristics that are required for multimedia applications. That means that the network does not guarantee how long it will take to send packets, what order packets arrive in, or even if the sent packets will reach its destination. Applications such as voice, video and FTP require different QoS parameters. QoS can be characterized by a set of network performance metrics including:
• Throughput • Latency or Delay • Frame Loss rate • Delay variation or jitter – The Jitter is not described in the RFCs 1242, 2544 and 2285. But the
RFC 2598 (An Expedited Forwarding Per-Hop Behaviour) defines the Jitter as the absolute value of the difference between the arrival times of two adjacent packets minus their departure times. The Jitter allows the evaluation of the variation of the Latency.
• Packet sequence – the ability of the network to deliver packets in proper sequence • Service availability – the ability to gain access to the network • Connection availability – the ability of the network to complete the required connections (i.e.,
TCP ) with the requested performance characteristics
R522/D523 Public
p.13/90
30/04/03
2.2.3 Service classes For the Field trial measurements three Service classes have been defined, one high-priority, one medium-priority and one low-priority. The high- and medium-priority, Expedited Forwarding (EF) and Assured Forwarding (AF) are based on standard per-hop-behaviours which are defined by the DiffServ working group. The low-priority based on Best-Effort forwarding. Applications with high QoS requirements, such as multimedia Video-over-IP, are represented by the high-priority. Services with small requirements at Latency and Jitter are represented by the medium-priority. The Low-priority represents traffic with very low requirements regarding Latency, Frame Loss and Jitter, e.g. a HTML session.
2.2.4 Policy
2.2.4.1 Service Level Agreement (SLA) The Field trial system provides a user SLA management that allows authentication for the flow set-up. A flow set-up procedure requires this authentication that is needed to identify the users. Additionally, the SLA specifies how much bandwidth can be used of the user for a specific Service class. This user profile information (authentication/bandwidth per Service class) can be configured in the SLA database using a developed Web based User Interface.
2.2.4.2 Queuing algorithms The Field trial set-up provides only the Queuing algorithms Strict priority. In contrast to Strict priority where lower prioritised traffic will be dropped in case of congestion, Weighted Fair priority guarantees a minimum bandwidth also for low priority traffic. Therefore, the Strict priority provides an absolute preference of the high-priority data. All low priority packets will be dropped if the high-priority data volume reaches the capacity limit of the system. The Weighted Fair priority mechanism guarantees a minimum bandwidth also for low-priority traffic, in order to avoid an excessive discrimination against the low-priority data. This issue of possible starvation of best-effort traffic is solved in HARMONICS by doing flow admission control for the QoS traffic and as such there is only a limited quantity of bandwidth used for QoS traffic.
2.2.5 Flow set-up The HARMONICS network has to be able to prefer a flow with a higher priority opposite a flow with a lower priority. For this preference, a network resource reservation procedure called flow set-up is needed [1]. The Harmonics management system provides some GUIs that allow a manual flow set-up, see 3.4. During the flow set-up procedure, a flow must be classified to a specific Service class (CoS) and an appropriate resource reservation must be initialised. During the flow set-up the management system establishes a reservation of bandwidth for the specific flow using a CORBA implementation within the limits of the Service Level Agreement (SLA). If the flow starts, then the Leaf router marks the packets of the flow, based on the CoS information fixed during the flow set-up. For the field trial a Layer 3 classification is applied where the Leaf Routers set the DiffServ markers in dependence of destination and source IP addresses. The bandwidth resources remain reserved until the flow reservation will be released again.
2.3 Measurement equipment For all Field trail measurements the modular chassis-based traffic generator and performance analyser SmartBits-6000B from Spirent Communications will be used. The chassis has twelve slots and currently T-Nova has got modules for up to 24 10/100 Mbit/s Ethernet ports, 6 Gigabit Ethernet ports and one 10GbE. Each port can be configured as traffic generator or as analyser. All available modules belong to the product line SmartMetrics that gives the ability to measure QoS on a per-flow metrics. The SMB-6000B supports automated standard performance tests defined in RFC 1242 and RFC 2544 and DiffServ and RSVP at layer 3. The Field trial measurements will be controlled by a PC through a 10/100 Mbit/s Ethernet connection and uses the Windows-based control software „Smartflow” from Spirent Communications.
R522/D523 Public
p.14/90
30/04/03
Figure 2-1: SmartBits 6000B
2.4 Measuring experiments This chapter describes and evaluates the measuring experiments of the Field trial. Essentially the measuring experiments can be classed into two main groups:
1. Traditional performance testing 2. QoS testing.
Traditional performance testing allows the evaluation of the HARMONICS System performance within the Field trial test-bed based on the Traditional performance testing. This analysis is necessary in order to determine the performance limits given by the trial equipment. The knowledge of the performance limits is the foundation of the QoS analysis. It is clear that a system cannot provide more quality as given by its performance limits. The Traditional performance testing is classed into following parts:
- Performance analysis of the HARMONICS System - Performance analysis of the Last Mile solutions - Performance analysis between Berlin and Darmstadt
The QoS testing allows the evaluation of the QoS characteristics of the HARMONICS System within the Field trial test-bed. Within the given system performance limits, the QoS feasibility is investigated. The QoS testing is grouped into following parts:
- QoS analysis of HARMONICS System - QoS testing in the loop in interaction of different network levels
2.4.1 Performance analysis of the HARMONICS System
2.4.1.1 Fast Ethernet Throughput The performance analysis of the HARMONICS System investigates the Throughput, Frame Loss and Latency of the System without looking at QoS and single flows. Figure 2-2 shows the measuring set-up of the Harmonics Fast Ethernet performance analysis. Leaf Router 1 and 2 located in the Berlin Atrium are connected to the Traffic Analyser/ Generator (SmartBits) via one 10/100Base-TX each. Both LRs are connected to the Edge Router 1 (ER1) located in the Berlin Winterfeldstrasse over a distance of 6.8 km. The SmartBits generated a packet stream and sent it to LR2 over LR1 and ER1.
HARMONICS
Monitoring
LR 1
ER 10/100
SmartBits(Traffic
Analyzer/ Generator)
LR 2
Untagged data streams
Winterfeldstr. Atrium
Figure 2-2: Measuring set-up of the Harmonics performance analysis
R522/D523 Public
p.15/90
30/04/03
The Throughput test determines the maximum transmission rate at which the DUT can forward frames with no frame loss. Figure 2-3 shows Throughput vs. Frame Size of the measuring set-up shown in Figure 2-2. The graph shows a horizontal axis with a max Throughput of 100% that based on the theoretically max data rate of the 10/100Base-TX interface at the SmartBits. One can see that the Throughput reaches a max Throughput of 100% for the frame sizes from 512 to 1518 Byte. For the Frame sizes 64, 128 and 256 Byte the max Throughput decreases on 98%. In consideration of the fact that PC-based routers are used in the Field trial, one can say that it is a good result.
Figure 2-3: FE Throughput vs. Frame Size
2.4.1.2 Fast Ethernet Frame Loss Figure 2-4 shows the Frame Loss of the measuring set-up depicted in Figure 2-2 for the Frame Sizes 64 Byte 1518 Byte. For packets with Frame Sizes from 512 to 1518 Byte the Frame Loss is constant zero. But the small packet sizes 64, 128 and 256 byte have a very less Frame Loss rate for 100 % load (0,73% for 64 Byte, 0,38% for 128 Byte and 0,13% for 256 Byte).
Figure 2-4: FE Frame Loss for the Frame Size 64 Byte and 1518 Byte
2.4.1.3 Fast Ethernet Latency and Latency Distribution The Measuring set-up depicted in Figure 2-2 reached following Latency limit values: Min Latency - 493.40 µs for 64 Byte Frame Size and 60% load Max Latency (100%) .- 24,382.60 µs for 256 Byte Frame Size and 100% load SmartFlow only calculates the minimum, maximum, and average latency at different loads. The Latency Distribution can be used for an easier interpretation of the latency. The Latency Distribution test also
R522/D523 Public
p.16/90
30/04/03
determines the latency of each test frame on a frame-by-frame basis and places the latency results into eight time buckets. Figure 2-5 shows the Latency Distribution for Frame sizes 64, 256, 512 and 1518 Byte for a load of 90% that means a data rate of 90 Mbit/s. One can see that all latency values fell between 500 and 3000 microseconds but the majority of the packets have a latency values between 500 and 2000 microseconds.
Figure 2-5: FE Latency Distribution for Frame Sizes 64, 256, 512 and 1518 Byte and 90% load
2.4.1.4 Gigabit Ethernet Throughput/Frame Loss These tests are exactly the same as those in 2.4.1.1 but now a free 1000base SX port is used on Leaf Router 1 and 2 and one flow is defined from LR2 to LR1 for different packet sizes. For Fast Ethernet we saw that the throughput was 100 Mbit/s without packet loss for packetsizes >= 512 bytes. As the processing load of a router increases with the number of packets (a router handles packet headers, mostly independent of the payload size), smaller packets are more difficult to handle. As we saw already a small packet loss percentage at 100Mbit/s for packets < 512, we can expect that we can see the limits of the used PC based routers, and as such we can try to avoid those processing limits in the further measurements to have a clear view on the functionality. Figure 2-6 shows the Frame Loss for packet sizes 64 - 256 – 512 – 1518 bytes. It is obvious that for the 64 byte packets the hardware limits of the PC based routers (also the OFN emulator runs on a PC) are reached. Packet loss starts at speeds of more than 200 Mbit/s (300000 packets/s (pps) ) which is a rather good number for low-end routers but of course not wire speed. For 256 byte packets, hardware limits play the same role, but the loss starts from 500 Mbit/s and more. For 512 byte packets, we see also loss from 600 Mbit/s and more, but this is now related to the OFN functionality. In Figure 2-2, the OFN emulator is not drawn, but can be found between the Leaf routers and the Edge router as can be seen in Figure 1-2. The upstream line rate of a wavelength channel is 625 Mbit/s with 100 byte slots of which 86 bytes can be used for data. As such 86/100 * 625 Mbit/s = 537.5 Mbit/s can
R522/D523 Public
p.17/90
30/04/03
be used upstream for transporting data. The bandwidth reported by the Smartbits software includes Ethernet headers, Ethernet preamble, CRC and interframe gap. So an Ethernet packet of 512 bytes is only 494 bytes IP header + data (14 bytes Ethernet header, 4 bytes CRC). As such, 140000pps are transported at 60% which results in 553 Mbit/s upstream traffic through the OFN emulator. The packet loss is caused by the limit of the upstream OFN line rate. The difference between 537.5 Mbit/s and 553 Mbit/s is caused by timing accuracy of the PC hardware but is good enough for emulation. Downstream the OFN line rate is 1.25 Gbit/s for 200 byte slots of which 152 bytes can be used for data resulting in 950 Mbit/s downstream data bandwidth, which is close to the 1 Gbit/s Ethernet limit. E.g. with 1518 byte packets, the Ethernet payload is 1500 bytes, Ethernet preamble 8 bytes and Ethernet interframe gap 20 bytes and as such 81274 pps can be transported resulting in 975 Mbit/s payload bandwidth which is more than the needed 950 Mbit/s for the OFN emulation. Of course, for smaller packets the overhead increases and the actual data bandwidth decreases. As such, big packets as e.g. 1518 are ideal to show QoS functionality within the field trial network as it stays outside the hardware limits and the gigabit Ethernet links are sufficient enough for the emulation of the OFN line rates (for the ONU setup used in the field trial, this is 2 ONUs on 1 wavelength channel).
Figure 2-6: Gb frame loss for LR2 – LR1 (64 – 256 – 512 – 1518 bytes packets)
2.4.1.5 Gigabit Ethernet Latency and Latency Distribution Min. Latency – 507us for 64 bytes packets at 100 Mbit/s. Max Latency – 40ms for 1518 bytes packets at 1 Gbit/s. (full queues) The Smartbits gigabit Ethernet cards do not show average delay numbers. The latency distribution shows that for loads < 537.5 Mbit/s, the latency is between 500-1000us and for more than 537.5 Mbit/s, when the queues get filled because of the line rate limit, delays of 10-40ms.
R522/D523 Public
p.18/90
30/04/03
2.4.1.6 The OFN emulator in detail Because the OFN (and hence also the OFN emulator) work internally with small slots of 100 bytes upstream and 200 bytes downstream (which results in equal timeslots of 1.28us), one can do some measurements that show some details. We use the ping command to send ping requests (and receive ping replies) from Management Station 5 to Management Station 2 (see Figure 1-3). Experiment 1: Leaf Router marks the packets as QoS class EF so that they become statically allocated upstream in the OFN. The ping packets have only 30 databytes, so that the IP content of the packet = 30 + 8 (ICMP header) + 20 (IP header) = 58 bytes which fits easily in a 86 byte slot. The static allocation was 16kbit/s to demonstrate the block delay. The OFN uses 2 BMRs in the field trial. 38 bytes from 192.168.6.162: icmp_seq=51 ttl=253 time=86.6 ms 38 bytes from 192.168.6.162: icmp_seq=52 ttl=253 time=86.6 ms 38 bytes from 192.168.6.162: icmp_seq=53 ttl=253 time=86.6 ms 38 bytes from 192.168.6.162: icmp_seq=54 ttl=253 time=86.7 ms 38 bytes from 192.168.6.162: icmp_seq=55 ttl=253 time=1.0 ms 38 bytes from 192.168.6.162: icmp_seq=56 ttl=253 time=1.1 ms 38 bytes from 192.168.6.162: icmp_seq=57 ttl=253 time=1.4 ms 38 bytes from 192.168.6.162: icmp_seq=58 ttl=253 time=1.3 ms The block delay = 86 byte / (16kbit/s / 2 BMRs) = 86ms. For static allocated upstream traffic permits come in from the OLT to the ONUs at a fixed rate (2 each 86ms) so the slot of the ping packet has to wait between 0-86ms, and because the sender sends not exactly a ping each second you can see that the first slots have to wait approx. 86 ms, while the last ones can be sent immediately. If we take ping packets which need 2 slots, we see: 64 bytes from 192.168.6.162: icmp_seq=362 ttl=253 time=172.8 ms 64 bytes from 192.168.6.162: icmp_seq=363 ttl=253 time=172.5 ms 64 bytes from 192.168.6.162: icmp_seq=364 ttl=253 time=173.0 ms 64 bytes from 192.168.6.162: icmp_seq=365 ttl=253 time=173.0 ms 64 bytes from 192.168.6.162: icmp_seq=366 ttl=253 time=87.1 ms 64 bytes from 192.168.6.162: icmp_seq=367 ttl=253 time=173.0 ms 64 bytes from 192.168.6.162: icmp_seq=368 ttl=253 time=87.3 ms 64 bytes from 192.168.6.162: icmp_seq=369 ttl=253 time=87.1 ms 64 bytes from 192.168.6.162: icmp_seq=370 ttl=253 time=87.6 ms So, first slot has to wait 0-86ms, but the 2nd slot can be sent 86ms after the first one, resulting in a delay 86-172ms. Another experiment is to send 10 pings at 100 Mbit/s to the Leaf router: 38 bytes from 192.168.6.162: icmp_seq=1 ttl=253 time=43.8 ms 38 bytes from 192.168.6.162: icmp_seq=0 ttl=253 time=43.9 ms 38 bytes from 192.168.6.162: icmp_seq=2 ttl=253 time=129.8 ms 38 bytes from 192.168.6.162: icmp_seq=3 ttl=253 time=129.9 ms 38 bytes from 192.168.6.162: icmp_seq=4 ttl=253 time=215.7 ms 38 bytes from 192.168.6.162: icmp_seq=5 ttl=253 time=215.7 ms 38 bytes from 192.168.6.162: icmp_seq=6 ttl=253 time=301.6 ms 38 bytes from 192.168.6.162: icmp_seq=7 ttl=253 time=301.6 ms 38 bytes from 192.168.6.162: icmp_seq=9 ttl=253 time=387.7 ms 38 bytes from 192.168.6.162: icmp_seq=8 ttl=253 time=387.8 ms 38 bytes from 192.168.6.162: icmp_seq=10 ttl=253 time=474.1 ms 38 bytes from 192.168.6.162: icmp_seq=11 ttl=253 time=52.6 ms 38 bytes from 192.168.6.162: icmp_seq=12 ttl=253 time=53.1 ms What happens: The first two pings are queued for the 2 BMRs and have to wait 0-86ms (here 43.8ms). The other 8 pings which are sent immediately have to be queued (for 2 BMRs in parallel) and so they are sent at +86ms, +172ms, +258ms, +344. You can also see that there is reordering possible, which will be described in a later section. Another tool used for testing and measurements is iPerf (http://dast.nlanr.net/Projects/Iperf/) which exists out of a server and a client and which can be used for UDP and TCP bandwidth measurements. If we e.g. allocate 20 Mbit/s, and try to send 30 Mbit/s of UDP packets upstream from MS 5 to MS 2.
R522/D523 Public
p.19/90
30/04/03
MS2: [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] 0.0-11.0 sec 26.0 MBytes 19.9 Mbits/sec 0.289 ms 6963/25513 (27%) [ 3] 0.0-11.0 sec 4743 datagrams received out-of-order MS5: [ 3] local 192.168.6.226 port 1025 connected with 192.168.6.162 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 35.8 MBytes 30.0 Mbits/sec [ 3] Sent 25513 datagrams We see that only 19.9 Mbit/s is received (26 Mbytes in 11sec). The sender sends 25513 datagrams of 1470 data bytes (+8 UDP header + 20 IP header = 1498 bytes) in 10 sec, while the receiver receives 18550 datagrams in 11 sec = 20.2 Mbit/s data through the OFN emulator. The receiver receives 1 sec extra data because the upstream queues in the OFN are 14534 blocks @ 68us delay/block for 20 Mbit/s = 0.988s delay to empty the queue. We can also learn here that 4743 packets are reordered and that the jitter is 0.289ms. For jitter and packet reordering of the OFN, we have reserved 100 Mbit/s upstream and measured with iPerf:
There was no packet loss in these measurements. The packet reordering is caused by the multiple BMRs to which packets are sent. Packets are queued in the smallest queue and they can be reordered because the queues are emptied round robin. This is a shortcoming of the OFN as packets from the same flow/application can be reordered. This is not a problem for IP as IP doesn’t guarantee packet ordering, but it is suboptimal as most applications/protocols are based on little reordering. E.g. the TCP protocol supposes that if it receives 3 packets in the wrong order that 1 packet has been lost and it retransmits it again (fast retransmit) which cause of course throughput loss in the TCP protocol. UDP applications have to adapt themselves for this and they use proprietary mechanisms, e.g. if packets arrive 1 2 5 3 4, the application can consider packet 3 and 4 as been dropped and as such a lot of bandwidth is spilled. It can be concluded from the field trial measurements that a final OFN should try to avoid packet reordering in one flow.
2.4.2 Performance analysis of the Last Mile solutions
2.4.2.1 Performance analyses of the EoVDSL solution A separate performance analyses of the Cisco Long Reach Ethernet (LRE) system is necessary because the influence of the LRE on the total Field trial system must be evaluated. The LRE switch controls upstream and downstream rates on the LRE links by using configurations called profiles. The LRE switches are offered with predefined profiles categorised as public mode and private mode profiles. By default, all LRE ports on the switch are enabled with the LRE-10 private profile. This profile allows the upstream and downstream transmission rate on the LRE link to be 10 Mbit/s. Cisco recommends using a public profile if the switch is used with equipment directly connected to a Public Switched Telephone Network (PSTN) without a private branch exchange (PBX) between the LRE switch and the public telephone lines. The private profiles can be employed if the LRE switch is not used with equipment connected to a PSTN. The LRE switch supports a variety of private asymmetric and symmetric profiles that offer different link speeds and maximum distances.
R522/D523 Public
p.20/90
30/04/03
Table 2-2 shows all supported LRE profiles.
Table 2-2: LRE profiles
The profiles with the abbreviation “LL” (LRE-5LL, LRE-10LL and LRE-15LL) have the Low-Latency (LL) feature enabled and the interleaver feature turned off. The interleaver feature provides maximum protection against small interruptions on the LRE link but delays data transmissions. The LL feature does not delay data transmission, but it makes data more susceptible to interruptions on the LRE link. Figure 2-7 shows the LRE measurement set-up. There is one 10/100 Ethernet connection between LRE switch and SmartBits. In addition, only one LRE-CPE is used that is also linked to the SmartBits. Regarding the following evaluation there are two definitions: Downstream: Traffic direction from LRE switch to LRE-CPE Upstream: Traffic direction from LRE-CPE to LRE switch
SmartBits(Traffic
Analyzer/ Generator)
Monitoring
CPE
LRE switch
LRE link
10/100 Ethernet
10/100 Ethernet
upstream
downstream
Figure 2-7: EoVDSL measurement set-up
For the LRE One-to-One tests two different LRE link distances (distance between LRE switch and LRE-CPE) were selected, 1 meter and 400 meter. The cable used for the LRE link is a typically phone wire (2x2x0.6mm). The connections between SmartBits and LRE system are based on UTP cat. 5 cable. Throughput During the measuring analysis the LRE system reached partly a higher data rate as documented by Cisco (see Table 2-2). In addition, a falling below the documented data rates could be determined. Table 2-3 gives a
R522/D523 Public
p.21/90
30/04/03
more detailed overview of the Throughput vs. Frame Size for the LRE profiles LRE-10, LRE-15 and LRE-15LL and both traffic directions.
upstream 7 1 m 19.84 18.44 17.73 17.03 17.03 17.03 17.03 *** higher data rate as documented by Cisco *** falling below the data rate documented by Cisco *** Data rate conform to the documentation of Cisco At LRE system a Burst Size limitation for the upstream direction could be determined. That means that the link performance decreases if the Burst Size climbs over the limitation. The Burst Size limitation depends on the Frame Size. E.g., a test using only a Frame Size of 512 Byte allows a Burst Size of 19 (19 Frames per Burst). For the LRE profiles LRE-15 and LRE-15LL the Burst Size optimum is 7, that means that there is a constant high performance for all Frame Sizes (64-1518 Byte). A Burst Size of 24 causes Packet Loss for packets larger than 416 Byte that affects a decrease of the Throughput down to zero. Probably the reason is the too small Buffer Size of the LRE-CPE. For the downstream direction, there is no relationship between performance and Burst Size. The performance is constant high for Burst Sizes from 1 to 1024 (max. value of the SmartFlow). Frame Loss The Frame Loss test measures the percentage of frames lost by the DUT that should have been forwarded. SmartFlow calculates frame loss as: Frame Loss = Number of Frames Transmitted - Number of Frames Received Figure 2-8 depicts the Frames Loss (%) for the LRE profile LRE-15LL with a Frame Size of 512 Byte and a LRE link distance of 400m. The left graph shows the Frames Loss of the Downstream direction and the right graph shows the Upstream direction. On the left side one can see that there was no Frames Loss up to a load of 16 % (16Mbit/s). The Upstream direction had no Packet Loss up to a load of 17%.
Figure 2-8: Frame Loss (%) for LRE profile LRE-15LL and 400 m link distance
R522/D523 Public
p.22/90
30/04/03
There was no Packet Loss for all investigated LRE profiles, Frame Sizes and LRE link distances up to the max Throughput value within the Burst Size limitation. But an Upstream test with a Burst Size set-up of 24 causes a Packet Loss of about 60% for 1518 Byte frames. Latency and Latency Distribution Figure 2-9, Figure 2-10 and Figure 2-11 show the Latency Distribution of the EoVDSL measurement set-up shown in Figure 2-7 with the LRE profile LRE-15LL, a LRE link distance of 1 meter and an Burst Size of one for both traffic directions. The Latency Distribution is shown for a load of 15 Mbit/s and for the Frame Sizes 1518, 512 and 64 Byte. The left graph of Figure 2-9 illustrates the Latency Distribution of the downstream direction for a Frame Size of 1518 Byte. One can see that all latency values fell between 1150 and 1250 microseconds. The latency values of the Upstream direction (graph on the right side) fell between 1050 and 1150 microseconds. You see that the Downstream direction reaches higher Latency values.
Figure 2-9: Latency Distribution for LRE profile LRE-15LL, Frame Size 1518 Byte, 15Mbit/s
load and 1 m link distance
Figure 2-10: Latency Distribution for LRE profile LRE-15LL, Frame Size 512 Byte, 15Mbit/s
load and 1 m link distance
Figure 2-10 shows that for 512 Byte frames with a Burst Size of 1 all Downstream latency values fell between 500 and 550 microseconds and all Upstream latency values fell between 425 and 500 microseconds. The Downstream latency values fell between 190 and 250 microseconds for 64 Byte packets with a Burst Size of 1, shown in Figure 2-11. The Upstream latency values fell between 140 and 250 microseconds.
R522/D523 Public
p.23/90
30/04/03
Figure 2-11: Latency Distribution for LRE profile LRE-15LL, Frame Size 64 Byte, 15Mbit/s
load and 1 m link distance
Table 2-4 and Table 2-5 list some meaningful measured Down- and Upstream Latency values of the EoVDSL solution for a link load of 15 Mbit/s and the Frame Sizes 64, 512 and 1518 Byte. The first line of the tables shows the Latency of an One-to-One set-up with link distance of 1 meter. The second line shows the Latency values of a One-to-One set-up with a link distance of 200 m. The allowed max Latency for Last Mile Networks defined in the Harmonics QoS requirements is 5 ms. One can see that the measured Latency is clearly under the allowed max value. A link distance of 200 m causes a link delay within the nano-second sphere that has no influence on the result.
Table 2-4: EoVDSL max Downstream Latency
Description Max Latency Downstream
(64 Byte)
Max Latency Downstream (512 Byte)
Max Latency Downstream (1518 Byte)
EoVDSL One-to-One, 15 Mbit/s load, link distance: 1 m, Burst Size: 1
0.23 ms 0.54 ms 1.23 ms
EoVDSL One-to-One, 15 Mbit/s load, link distance: 200 m, Burst Size: 1
0.25 ms 0.54 ms 1.23 ms
Table 2-5: EoVDSL max Upstream Latency
Description Max Latency
Upstream (64 Byte)
Max Latency Upstream (512 Byte)
Max Latency Upstream
(1518 Byte)
EoVDSL One-to-One, 15 Mbit/s load, link distance: 1 m, Burst Size: 1
0.21 ms 0.49 1.12 ms
EoVDSL One-to-One, 15 Mbit/s load, link distance: 200 m, Burst Size: 1
0.21 ms 0.49 1.12 ms
Jitter (Delay variation) Table 2-6 shows the measured Jitter values of the EoVDSL solution for the measurement set-up shown in Figure 2-7 with a link distance of 1m on the one hand and 200m on the other hand. The Jitter is shown for an link load of 15 Mbit/s and a Frame Size of 218 Byte. For Last Mile Networks a max Jitter of 2 ms has been defined for the HARMONICS platform. All determined Jitter values fall clearly under this restriction.
Table 2-6: Jitter of the EoVDSL Last Mile
Avg. Jitter Downstream Avg. Jitter Upstream
EoVDSL One-to-One, 15 Mbit/s load, link distance: 1 m, Burst Size: 1, Frame Size: 218
14.0 µs 25.3 µs
EoVDSL One-to-One, 15 Mbit/s load, link distance: 200 m, Burst Size: 1, Frame Size: 218
14.1 µs 24.8 µs
R522/D523 Public
p.24/90
30/04/03
Packet sequence The Packet sequence describes the ability of a network to deliver packets in proper sequence. Table 2-7 shows the number of Out-of-sequence-frames versus Link load for the Frame Sizes 64, 512 and 1518 Byte. One can see that all frames are in sequence up to a Link load of 16 Mbit/s. So the EoVDSL solution fulfilled the Packet sequence requirements for the HARMONICS Basic Service with a sum bitrate of 12.5/12.5 Mbit/s.
Table 2-7: Out of sequence frames versus Link load of the EoVDSL Last Mile
2.4.2.2 HiperLAN/2 Evaluation Experiments and Performance Results The performance results of the developed HiperLAN/2 in HARMONICS consist of two different categories: the first concerns complexity measurements regarding the control plane whereas the second concerns performance results. The development part regarding HiperLAN/2 consisted of the development of the User Plane (UP) and Control Plane (CP) including the development of LNCHiperLAN/2 in order to support QoS. The integration for the CP and LNCHiperLAN/2 with the rest of the HARMONICS control plane (network of LNCs) took place during the lab demo at IMEC’s premises. For the field trial a completed HiperLAN/2 system with the enhanced CP and UP that support QoS was required. The platform developed for the purposes of the HARMONICS project (Linux-based) proved to be unstable and therefore, early enough (December 2001) the platform was changed and a new platform based on an ARM processor was adopted. By the beginning of September 2002 it was foreseen that the final HiperLAN/2 prototype wouldn’t be ready for the Field Trial that was about to start (October 2002). Therefore, in order not to jeopardise the field trial and the work carried out by the rest of the partners, a IEEE 802.11a Wireless LAN was shipped to Berlin. The plan was to replace IEEE 802.11a as soon as the HiperLAN/2 prototype was available. IEEE 802.11a does not incorporate any QoS mechanisms but it is a wireless LAN technology similar to that of HiperLAN/2. At least the behaviour of the wireless medium could be assumed that it is similar for both wireless LANs and effectively the UP. Consequently, despite the limitation that QoS reservation could not take place when using IEEE 802.11a, the fact that data transfers do take place over the wireless medium (of a wireless LAN) was the motivation of replacing HiperLAN/2 with IEEE 802.11a for the needs of the field trial. On the other hand, even if HiperLAN/2 was ready it would be unlikely to be used by common users since it is a prototype platform and would require some extra technical experience for its operation. The development of the HiperLAN/2 prototype continued in parallel for the period of the field trial. Unforeseen hardware problems delayed the finalisation of the implementation phase. Finally, a HiperLAN/2 prototype system consisting of one AP and one MT was shipped to Berlin for the purposes of the field trial. This system, it was decided, not to be integrated with the rest of the field trial due to the lack of time in order not to jeopardise the rest of the demonstration set-up. The control plane was tested on the spot and results of its fine behaviour were also demonstrated to the partners before the review meeting. The performance results presented later (after the complexity measurements) concern (a) a TDMA emulator of HiperLAN/2 that was used before the development of the actual prototype system in order to test the enhancements required by the project and (b) measurements over the final prototype with resource reservation scenarios.
2.4.2.2.1 Complexity Measurements The scope of this section is to show that the implemented enhanced DLC, SSCS and the corresponding communication modules with LNCHiperLAN/2, do not influence the system performance due to increased use of computational power. Note that the implementation part of the particular enhanced protocol stack is not a
R522/D523 Public
p.25/90
30/04/03
trivial task since it has taken place in a Linux Kernel environment and therefore, is tightly close to the CPU idiosyncrasies of the particular system. Figure 2-12 depicts the demo test bed that was used for the particular experiments in order to derive the complexity results. All equipment is PC Pentium (200 MHz CPU clock). All network interfaces are Ethernet 10baseT.
AP
MT1
MT 2
LEAF
Figure 2-12: The test bed used to derive complexity results.
The particular tests as well as the obtained results are presented next. The results presented here correspond to file transfers through the considered test bed. The “physical boundary” is the throughput of the network interfaces. The purpose here is to show that when HiperLAN/2 is uploaded, then the performance of the system does not degrade significantly; the computational power is still enough for the system to operate as normal even for comparatively slow computer machines (operating at 200 MHz CPU clock).
2.4.2.2.1.1 Scenario 1 This scenario refers to plain ftp transfer of two files (10 and 50 Mbytes) between the equipment presented in Figure 2-12 with no HiperLAN/2 modules uploaded.
LEAF←MT1 9 8.9 LEAF← MT2 9.6 9.3 These results will serve as a comparison basis for the results of the following experiments.
R522/D523 Public
p.26/90
30/04/03
2.4.2.2.1.2 Scenario 2 This scenario refers to plain ftp transfer of two files (10 and 50 Mbytes) between the equipments presented in Figure 2-12 with no HiperLAN/2 modules uploaded.
LEAF←MT1 9 8.9 LEAF← MT2 9.6 9.3 These results will serve as a comparison basis for the results of the following experiments.
2.4.2.2.1.3 Scenario 3 This scenario refers to ftp transfer between the equipments presented in Figure 2-12 with HiperLAN/2 IPSSCS modules uploaded. No emulation of DLC (time delays to emulate behaviour of the link) takes place at this point.
Table 2-10: ftp transfer with HiperLAN/2 modules uploaded and no time emulation.
LEAF←MT1 8.5 8.3 LEAF← MT2 9.3 9 From Scenario 1 and Scenario 2 it is obvious that the uploaded HiperLAN/2 IPSSCS does not degrade the throughput of the system.
2.4.2.2.1.4 Scenario 4 This scenario refers to ftp transfer between the equipments presented in Figure 2-12 with HiperLAN/2 IPSSCS modules uploaded. Emulation of DLC through time delays takes place at this point additionally with resource reservations. Therefore, all data traffic is forwarded through the Time Critical (TC) queue.
Table 2-11: ftp transfer with HiperLAN/2 modules uploaded and resource reservations (TC).
This is the important part of the results obtained. Note that when there is resource reservation the achieved throughput is comparable to the Scenario 1 achieved throughput. Therefore, it is evident that the particular implementation of the enhanced HiperLAN/2 protocol stack does not degrade the performance of the system due to unnecessary use of computational resources.
2.4.2.2.1.5 Scenario 5
Table 2-12: ftp transfer with HiperLAN/2 modules uploaded and resource reservations (TC). BE for background traffic.
This scenario refers to ftp transfer between the equipment presented in Figure 2-12 with HiperLAN/2 IPSSCS modules uploaded. Emulation of DLC through time delays takes place at this point additionally with resource reservations. Therefore all data traffic is forwarded through the Time Critical (TC) queue. Additionally, background BE traffic (ftp of the 50MB file) for the complementary pair takes place. Note that the achieved throughput is close to that when the data flow is the only one present (now there is a huge file transfer at the background as BE traffic).
2.4.2.2.1.6 Complexity Measurement Conclusions From the above complexity measurements it is clear that the enhanced HiperLAN/2 protocol stack does not use unnecessarily resources of the system (computational power). The only reason for a bounded performance is the throughput of the network interface, which in our case was limited. Those tests have also proved the stability of the system since the modules were uploaded for days without any impact on the system’s performance. It is also shown that the differentiation between different traffic flows is possible and the need for computational power (checking whether a packet belongs to a particular data flow) is limited.
2.4.2.2.2 Emulator Performance Results It is already shown that the enhanced protocol stack uses a limited fraction of system resources (computational power) for the differentiation among different flows. In this section, the particular system performance behaviour of the HiperLAN/2 protocol stack according to different scenarios is shown. Note that according to the implementation the main difference between the treatment of data flows that belong to different priority queues (except from the change in priorities) is the presence or lack of the error control mechanism. At this particular stage the performance results for the throughput achieved under HiperLAN/2 were based on software TDMA emulator of the hardware platform due to unavailability of the actual hardware platform. This TDMA emulator successfully reflects the TDMA-based nature of HiperLAN/2 and allows traffic to be transmitted according to the HiperLAN/2 standard.
R522/D523 Public
p.28/90
30/04/03
fh1 fh2
ap
mt
Ethernet
HIPERLAN/2
TDMAEmulator
Linux 2.2.19/x86 FreeBSD 3.4/x86
Linux 2.2.19/x86
Linux 2.2.19/x86
TDMAEmulator
Figure 2-13: Experimental test bed for evaluation and demonstration purposes.
Measurements have been collected on the experimental test bed shown in Figure 2-13. Those have been performed over a HiperLAN/2 system operating at 6 Mbit/s (i.e., with a BPSK 1/2 modulation for all transport channels). That is, the HiperLAN/2 device driver has been used which also incorporates software emulated TDMA behaviour. In addition, a DLC PDU error generator has been implemented to test the system under bad link conditions. Using that error generator, the packet error rate or PER (viz., the DLC PDU error rate) varies from 10-6 to 2·10-2 (on average). In addition, when HiperLAN/2 ARQ is used in the experiment PER (Packet Error Rate) varies from 10-6 to 16·10-2 (on average). This PER range is the result of ICOM's extensive simulations and reflects the link conditions faced by a HiperLAN/2 system operating with BPSK 1/2 modulation over a distance that varies from 40 to 50 meters (or even more) in a non line-of-sight case. As a result, the performed measurements mimic the ones of a real system. The main performance metric is throughput as seen at the application level. This is the metric of choice for TCP bulk transfer connections. For this purpose, we have performed numerous TCP measurements with the ttcp-measuring tool. Actually, we have performed 8-MB bulk transfers from host fh1 to host mt, while varying the error recovery mechanism at different layers of the protocol stack (i.e., TCP SACK, HiperLAN/2 ARQ) and PER. As mentioned above, all measurements have been performed under Linux kernel 2.2.19 as shown in Figure 2-13. The involved machines are standard Pentium III based with 128 MB of RAM. Each one measurement has been collected five times and the average has been used for further processing of measuring data. Finally, each one measurement has been collected on TCP receiver (i.e., on host mt).
R522/D523 Public
p.29/90
30/04/03
0
50
100
150
200
250
300
350
400
450
500
1,E-06 1,E-05 1,E-04 1,E-03 1,E-02 1,E-01 1,E+00
PER
TC
P t
hro
ug
hp
ut
(KB
/s)
nosack sack arq_nosack arq_sack
Figure 2-14: Comparison for TCP flows with different characteristics.
In Figure 2-14 the achievable system throughput is presented for various values of PER. The four cases presented correspond to the following scenarios. • nosack: This is the case when no Selective Acknowledgement (SACK) is enabled in TCP and when no
ARQ is enabled inside the HiperLAN/2 protocol stack. For this particular case, when PER is small (close to 10-6), the achievable throughput is 450 KB/s. As the PER increases, the throughput remains the same until PER is close to 10-4. For values of PER larger than 10-4 the throughput is rapidly decreased and for values of PER larger than 10-2 the throughput is close to 0.
• sack: This is the case when the SACK is enabled inside TCP. From Figure 2-14 it is observed that the throughput between 10-4 and 10-3 degrades but not so rapidly as in the nosack case. That means that the acknowledgement of the missed TCP packets saves bandwidth compared to the case were the retransmission of multiple packets (and some of them being successfully transmitted) was required.
• arq_nosack: This is the case were no SACK is enabled but the ARQ mechanism of HiperLAN/2 is enabled (in particular it is a Selective ARQ – S-ARQ - mechanism). The HiperLAN/2 S-ARQ error control mechanism allows the retransmission of erroneously received DLC PDUs. The presence of this mechanism shields the system performance against the PER for values close to 10-1. For values larger than that the throughput rapidly degrades. Note that the maximum value of the throughput is 350 KB/s, which is less than that achieved under the absence of the S-ARQ mechanism.
• arq_sack: Note that the presence or absence of SACK does not affect the system performance when S-ARQ is present. This is expected since the percentage of errors that TCP’s error control has to deal with is limited due to the presence of S-ARQ. Consequently, the amount of data packets that is not acknowledged and that is required to be retransmitted is small.
In conclusion, the performance results, for the given test bed the system performance is affected by the error rate (PER) induced by PHY. For small values of PER, it is obvious that a higher throughput is achievable when no error control is used at DLC. This supports our claims that the high priority queue (that corresponds to EF traffic class) is possible to achieve high throughput values in the absence of the error control mechanism. On the other hand, the second priority queue (that corresponds to the AF traffic class) that is equipped with error control achieves reasonably high throughput values for comparable high PER values.
2.4.2.2.3 Performance Results of the Integrated HiperLAN/2 Prototype The set-up depicted in Figure 2-15 reflects the set-up of the ARM-based prototype HiperLAN/2. Two user PCs are connected directly with the actual HiperLAN/2 board and user data travel between the two user PCs.
Figure 2-16 depicts one of the two prototypes (the MT). Both prototypes have identical appearance and the actual code that is implemented and incorporated into the system is different.
Figure 2-16: HiperLAN/2 prototypes.
Table 2-13 contains the achieved data rates for ftp transfers. Three tests were carried on for two different files (file_1 and file_2). The size of these files is of hundreds of Kbytes. The first column, labelled as “Standard HiperLAN/2 Protocol Stack”, depicts the achieved data rates in Kbps. Note that the fact that ftp is possible to run over the wireless medium validates on the spot the fact that the protocol stack of the HiperLAN/2
R522/D523 Public
p.31/90
30/04/03
prototype is integrated. The second column, labelled as “Enhanced HiperLAN/2 Protocol Stack with No Resource Reservation”, corresponds to the case that the enhanced protocol stack considered in HARMONICS has been uploaded. It has to be mentioned that for this case background traffic has been considered as well1. The reduction of the achievable throughput is obvious and this is due to the existence of background traffic. The third column, labelled as “Enhanced HiperLAN/2 Protocol Stack with Resource Reservation”, corresponds to the case that resource reservations had taken place for the particular data flow. In particular, the MT sends through the dedicated DLC connection an appropriate message to the AP. The latter forwards this message to the LNCHiperLAN/2 that identifies that there is no need for this kind of resource reservation to contact LNCDS. Immediately after resources are reserved at the AP and an appropriate message is sent back to the MT that initiated the task. That way, the file transfer is of higher priority of the background traffic. From Table 2-13 it is obvious that the resource reservation is real since the achieve throughput is similar to that when there is no background traffic.
Table 2-13: Data rates for ftp transfers in Kbps.
Standard HiperLAN/2Protocol Stack
Enhanced HiperLAN/2Protocol Stack with NoResource Reservation
Enhanced HiperLAN/2Protocol Stack with ResourceReservation
Table 2-14 contains measurements for the same scenarios for ping. It is obvious that the resource reservation gives higher priority to ping even when there is background traffic.
Table 2-14: Round-trip time for ping in msec.
Standard HiperLAN/2Protocol Stack
Enhanced HiperLAN/2Protocol Stack with NoResource Reservation
Enhanced HiperLAN/2Protocol Stack with ResourceReservation
23 34 27 267 256 210 23 27 25
2.4.2.3 Performance analysis of the Last Mile solution Optical Ethernet The HARMONICS Field Trial Last Mile solution Optical Ethernet consists of a small manageable Ethernet switch and media converters. Figure 2-17 shows the measurement set-up of the performance analysis of the Last mile solution Optical Ethernet.
SmartBits(Traffic
Analyzer/ Generator)
Monitoring
Mediaconverter
100Base-Fx
10/100 Ethernet
10/100 Ethernet
upstream
downstream
CPEswitch
Single mode fibreUTP cable (cat. 5)
Figure 2-17: Optical Ethernet measurement set-up
1 If there was no background traffic that results would similar to that of the first column since the enhancements has already been shown that do not add any complexity issues to the system.
R522/D523 Public
p.32/90
30/04/03
Media converter and CPE switch are connected by a single mode fibre over a link distance of 5 meter. Additionally, both devices are linked to the SmartBits using an UTP cable. Throughput OE reached a max Throughput of 100 Mbit/s for all defined Frame Sizes and both traffic directions. Latency Distribution Figure 2-18 shows the Latency Distribution of the LMN solution Optical Ethernet for the Frame Size 1518 Byte and both traffic directions. The left graph illustrates the Latency Distribution for a link load of 30 % (30Mbit/s). One can see that all latency values fell between 124 and 125 microseconds. The system reached the same latency values for a link load of 100 % (graph on the right side).
Figure 2-18: Opt. Ethernet Latency Distribution for a Frame Size of 1518 Byte
Figure 2-19 shows that all latency values fell between 7 and 9 microseconds for 64 Byte frames. For 512 Byte Frames the latency values fell between 43 and 44 microseconds.
Figure 2-19: Opt. Ethernet Latency Distribution for the Frame Sizes 64 and 512 Byte
Jitter Table 2-15 shows Jitter values of the OE solution for a Link load of 30Mbit/s on the one hand and 100Mbit/s on the other hand. The Jitter is shown for a Frame Size of 218 Byte. The measured Jitter values fall clearly under the required restriction of 2 ms for HARMONICS Last Mile Networks.
Frame Loss and Packet sequence The Frame Loss of the OE solution was measured based on the Traditional performance testing (see paragraph 2.1.). The system reached a Frame Loss rate of zero for all defined Frame Sizes. Table 2-16 shows the Frame Loss of the OE set-up for the Frame Size 64 Byte and a link load from 10% to 100% in steps of 10% for both traffic directions, Down- and Upstream. Additionally, the Frame Loss of the Frame Sizes 512 and 1518 Byte is listed for a link load of 30% (30Mbit/s) and 100%. Parallel to the determination of the Frame Loss also the Packet sequence of the OE solution was measured. There was no Out Of Sequence Frame for all defined Frame Sizes and different Link load steps.
Table 2-16: Optical Ethernet Frame Loss and Packet sequence
2.4.2.4 Performance analysis of the Last Mile solution Ethernet over POF The Field Trial Polymer Optical Fibre - POF system is based on an Ethernet over POF (EoPOF) solution from W&T. The EoPOF solution consists of media converters shown in Figure 2-20, which convert one Ethernet 10Base-T port to a POF port that allows bridging a distance of 100 meters using duplex POF fibre cable with a core diameter of 980 µm.
Figure 2-20: EoPOF Media converter
Figure 2-21 shows the measurement set-up for the performance analysis of the POF system. Two Media Converters are connected via a Polymer Optical Fibre with a core diameter of 980 µm. There is one 10Base-T connection between each Media converter and the SmartBits using UTP cable.
Media converter
Power supply
UTP UTP
POF(980 µm core diameter)
SmartBits(Traffic
Analyzer/ Generator)
Figure 2-21: POF measurement set-up
Throughput The EoPOF solution reached a max Throughput of 10 Mbit/s for all defined Frame Sizes. Latency Distribution Figure 2-22 shows the Latency Distribution of the EoPOF set-up depicted in Figure 2-21 for the Frame Size 64 Byte and a link load of 100% (10Mbit/s). The EoPOF solution works on the OSI layer 1 only, there is no buffering within the media converters. So the system reached very low Latency values. One can see that all latency values fell between 0.6 and 1.2 microseconds.
R522/D523 Public
p.35/90
30/04/03
Figure 2-22: EoPOF Latency Distribution for the Frame Size 64 Byte and a Link load of 100%
(10Mbit/s)
Frame Loss and Packet sequence The Frame Loss and Packet sequence analysis of the stand-alone POF system also resulted in good performance values. The system reached a Frame Loss rate of zero for all defined Frame Sizes. Table 2-17 shows the Frame Loss of the EoPOF set-up for the Frame Size 64 Byte and a link load from 10% to 100% in steps of 10%. The Packet sequence was also fulfilled of the EoPOF set-up. There was no Out-Of-Sequence Frame for all defined Frame Sizes and different Link load steps.
2.4.3 Performance analysis between Berlin and Darmstadt The measurement setup is shown in Figure 2-23 and we make use of the remote management network (100 Mbit/s used for remote login on all the machines in the field trial) for the return path. 100 Mbit/s traffic is sent from a Fast Ethernet port of LR2 to the Smartbits port connected to the remote management network. Upstream (from LR2 to LR3), there is no packet loss for packet sizes 256, 512 and 1518 bytes. Min. Latency is 10.7ms for 256 byte packets while max latency is approx. 24ms for 512 byte packets at 100 Mbit/s. The latency distribution learns that most packets are between 10 and 12ms delay. Downstream (from LR3 to LR2) the numbers are the same.
R522/D523 Public
p.36/90
30/04/03
Figure 2-23: Measurements one way over network making use of remote management for
return path
Most of the delay comes from the WDM link between Berlin and Darmstadt. This is 700 km fibre with a 1:5 dispersion-compensation so the total link is about 900km, which results in approx. 4.5ms delay oneway, and thus 9-10ms delay in the roundtrip. • If we measure the roundtrip time by using ping from the video server in Darmstadt to a PC connected to
the VDSL last mile network, we get: Packets of 64 bytes 14 packets transmitted, 14 packets received, 0% packet loss round-trip min/avg/max = 11.8/12.2/12.6 ms Packets of 512 bytes 8 packets transmitted, 8 packets received, 0% packet loss round-trip min/avg/max = 13.1/13.2/13.4 ms Packets of 1500 bytes 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 15.1/15.3/15.6 ms • If we ping to a Fast Ethernet port of Leaf Router 2: Packets of 64 bytes 9 packets transmitted, 9 packets received, 0% packet loss round-trip min/avg/max = 11.5/11.7/12.0 ms Packets of 512 bytes 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 12.0/12.3/12.6 ms Packets of 1500 bytes 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 12.8/13.0/13.4 ms • The remote management network alone which is based on connected Ethernet switches has the following
roundtrip delays: Management Station 4 (Atrium) to Management Station 2 (Winterfeldstrasse): Packets of 64 bytes 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 0.1/0.1/0.4 ms Packets of 1500 bytes 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max = 0.9/0.9/0.9 ms Management Station 4 (Atrium) to Management Station 1 (Darmstadt): Packets of 64 bytes
R522/D523 Public
p.37/90
30/04/03
7 packets transmitted, 7 packets received, 0% packet loss round-trip min/avg/max = 10.1/11.5/20.3 ms Packets of 1500 bytes 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max = 10.9/10.9/11.0 ms Management Station 2 (Winterfeldstrasse) to Management Station 1 (Darmstadt): Packets of 64 bytes 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max = 10.2/11.9/20.5 ms Packets of 1500 bytes 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max = 11.2/11.2/11.3 ms If we take a closer look at the packet-reordering problem in the OFN by looking at one upstream flow of 100 Mbit/s, we see the following, for a configuration of the OFN with 2 BMRs and for different packet sizes.
Size Load Tx packets Rx packets Lost packets Lost % Out-of-sequence In-sequence
256 10 45289 45289 0 0.00 841 44,448
256 20 90579 90579 0 0.00 19,455 71,124
256 30 135869 135869 0 0.00 35,690 100,179
256 40 181159 181158 1 0.00 50,874 130,284
256 50 226449 226393 56 0.02 66,016 160,377
256 60 271739 271579 160 0.05 105,403 166,176
256 70 317028 316774 254 0.08 145,029 171,745
256 80 362318 361951 367 0.10 150,297 211,654
256 90 407608 407111 497 0.12 164,858 242,253
256 100 452898 452233 665 0.14 191,390 260,843
512 10 23496 23496 0 0.00 19 23,477
512 20 46992 46992 0 0.00 1,578 45,414
512 30 70488 70488 0 0.00 13,973 56,515
512 40 93984 93984 0 0.00 25,305 68,679
512 50 117481 117480 1 0.00 27,803 89,677
512 60 140977 140977 0 0.00 36,529 104,448
512 70 164473 164473 0 0.00 46,856 117,617
512 80 187969 187947 22 0.01 51,524 136,423
512 90 211466 211435 31 0.01 59,285 152,150
512 100 234962 234848 114 0.04 67,760 167,088
1518 10 8127 8127 0 0.00 0 8,127
1518 20 16254 16254 0 0.00 12 16,242
1518 30 24382 24382 0 0.00 8 24,374
1518 40 32509 32509 0 0.00 7 32,502
1518 50 40637 40637 0 0.00 32 40,605
1518 60 48764 48764 0 0.00 2,545 46,219
1518 70 56892 56892 0 0.00 5,944 50,948
1518 80 65019 65019 0 0.00 9,265 55,754
1518 90 73146 73146 0 0.00 15,109 58,037
1518 100 81274 81274 0 0.00 17,990 63,284
Out-of-sequence packets are defined in the Smartbits software as packets, which don’t have the sequence number of the previous packet plus one. So a lost packet generates per definition also an out-of-sequence packet. We can see that between 0-40% of the packets are reordered and it is worse for small packets.
R522/D523 Public
p.38/90
30/04/03
If we configure the OFN for using only 1 BMR, we see that there is no packet reordering anymore (except for some lost packets):
Size Load Tx packets Rx packets Lost packets Lost % Out-of-sequence In-sequence
256 10 45289 45289 0 0.00 0 45,289
256 20 90579 90579 0 0.00 0 90,579
256 30 135869 135869 0 0.00 0 135,869
256 40 181159 181152 7 0.00 4 181,148
256 50 226449 226391 58 0.02 10 226,381
256 60 271739 271586 153 0.05 15 271,571
256 70 317028 316765 263 0.08 15 316,75
256 80 362318 361944 374 0.10 16 361,928
256 90 407608 407062 546 0.13 17 407,045
256 100 452898 452253 645 0.14 19 452,234
512 10 23496 23496 0 0.00 0 23,496
512 20 46992 46992 0 0.00 0 46,992
512 30 70488 70488 0 0.00 0 70,488
512 40 93984 93984 0 0.00 0 93,984
512 50 117481 117481 0 0.00 0 117,481
512 60 140977 140977 0 0.00 0 140,977
512 70 164473 164473 0 0.00 0 164,473
512 80 187969 187962 7 0.00 3 187,959
512 90 211466 211397 69 0.03 10 211,387
512 100 234962 234883 79 0.03 12 234,871
1518 10 8127 8127 0 0.00 0 8,127
1518 20 16254 16254 0 0.00 0 16,254
1518 30 24382 24382 0 0.00 0 24,382
1518 40 32509 32509 0 0.00 0 32,509
1518 50 40637 40637 0 0.00 0 40,637
1518 60 48764 48764 0 0.00 0 48,764
1518 70 56892 56892 0 0.00 0 56,892
1518 80 65019 65019 0 0.00 0 65,019
1518 90 73146 73146 0 0.00 0 73,146
1518 100 81274 81274 0 0.00 0 81,274
R522/D523 Public
p.39/90
30/04/03
2.4.4 QoS analysis of HARMONICS System At first, only the defined HARMONICS System will be investigated in the Field trial test-bed without influences of other techniques. Figure 2-24 shows the measuring set-up of a QoS analysis using Fast Ethernet ports at the Leaf Routers.
Marked High-priority flow (EF)Unmarked Best Effort flowUnmarked high-priority flow
Marked High-priority flow (EF)Unmarked Best Effort flowUnmarked high-priority flow
Dropped
LR 2
ER
10/100
LR 1
Winterfeldstr. Atrium
SmartBits(Traffic
Analyzer/ Generator)
GbE
Figure 2-24: Measuring set-up for a QoS analysis
In order to test the priority mechanism two flows have been defined for this experiment, one for low priority (Best Effort - BE) and one for high priority (Expedited Forwarding - EF) traffic. For the EF flow a flow set-up was established. 100 Mbit/s have been reserved for the EF flow using the HARMONICS Management. Two Fast Ethernet ports (10/100Base-TX) of the SmartBits were linked to Leaf Router 1. One Smartbits port generated the unmarked EF flow, which means that the priority of the flow is not marked by the Smartbits. The other Smartbits port created the BE flow. Leaf Router 1 has to classify the entering flows and mark the service class within the IP packets of the EF flow. In the case that the HARMONICS system reaches its capacity limit the low-priority data have to be dropped in favour of the high-priority data. In this scenario, there is no traffic congestion within the HARMONICS network because both Leaf Routers are connected to the Edge Router via Gigabit Ethernet (1000 Mbit/s) and the generated flows reach a total data rate of 200 Mbit/s. But there is traffic congestion at the exit of the HARMONICS system (the connection between Leaf Router 2 and Smartbits analyser port), because this link is based on Fast Ethernet with max 100 Mbit/s. Leaf Router 2 has to drop the BE packets in favour of the EF packets if the traffic of both flows overloads the link with more than 100 Mbit/s.
Figure 2-25: Frame Loss without and with QoS for a Frame Size of 512 Byte
But at first the system behaviour was tested without priority marking of the different flows. The left graph of Figure 2-25 shows the frame loss of both flows without QoS flow set-up. The congesting flows (green and blue graph) show an equally increasing frame loss. The flows are handled equally. The right diagram of Figure 2-25 shows the Frame Loss versus Load with enabled QoS. One can see that there is no Frame loss up to a link load of 50% per flow which means a total data rate of 100 Mbit/s. After claming over a link load of 50% per flow the Frame loss of the BE flow increases constantly by increasing load. In contrast to the BE
R522/D523 Public
p.40/90
30/04/03
flow the EF flow has no packet loss up to a link load of 100%. This experiment has a Strict priority characteristic because all BE packets are dropped if the EF flow causes a link load of 100% (100 Mbit/s). This ideally corresponds with the predictions.
Figure 2-26: Latency Distribution for the Frame Sizes 64, 512 and 1518 Byte and a load of
40% and 80%
Table 2-18 shows the Frame Loss versus load for the Frame Sizes 64, 512 and 1518 Byte and all link load steps. One can see a ideal Frame Loss behaviour for the Frame sizes 512 and 1518 Byte. There is no Frame Loss for the EF flow. The limited performance of the PC based routers is the reason of the low Frame Loss ratio for packets with 64 Byte with a link load of 90%.
R522/D523 Public
p.41/90
30/04/03
Table 2-18: Frame Loss (%) versus load (%) with QoS
Frame Loss (%) vs. load Size Name/load 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
In Figure 2-26 the Latency Distribution for the measuring set-up depicted in Figure 2-24 is shown. The left graphs show the Latency Distribution in the case without congestion for the Frame sizes 64, 512 and 1518 Byte with a load of 40 % per flow that means a total data rate of 80 Mbit/s. For the majority of the packets the Latency is smaller than 5ms for both flows in the case without congestion. The graphs on the right side of Figure 2-26 show the Latency Distribution for both flows in a case with congestion. As expected the Latency is nearly constant for the EF flow and the latency increases significantly for the BE in contrast to the case without congestion. Mainly the Latency of the EF flow is smaller than 5 ms. But the Latency is about 3 ms higher than the values of the scenario with disabled QoS management (see Figure 2-5). Probably the QoS management occupies more processor performance of the PC-based routers which causes a higher Latency. In contrast to networks using only DiffServ, the QoS management of HARMONICS does not allow the set up of additional prioritised flow exceeding the SLA limits. This way the management guarantees the end-to-end throughput and enables low latency values.
2.4.5 QoS testing in the loop in interaction of different network levels For these tests, more complex setups are used which can be shown on Figure 1-2 and Figure 2-23, so coming from the remote management going via LR3-CR-ER2 (Darmstadt) to ER-OFN emulator – LR1 and LR2 in Berlin. We use two classes of traffic, Best Effort (BE) and Expedited Forwarding (EF) of which EF is of course the highest QoS. The downstream setup exists out of 10 flows (between brackets the max. load is given based on 100% load in the SmartFlow software) : • 2x Best effort downstream from remote management to LR1 – port 3 (2x 33.33 Mbit/s) • Expedited Forwarding (EF) from remote management to LR1 – port 3 (33.33 Mbit/s) • 2x Best effort from LR2 – port 2 to LR1 – port 3 (2x 33.33 Mbit/s) • EF from LR2 – port 2 to LR1 – port 3 (33.33 Mbit/s) • 3x Best effort from LR2 – port 1 to LR1 – port 3 (3x25 Mbit/s) • EF from LR2 – port 1 to LR1 – port 3 (25 Mbit/s) At max. load we have 33.33+33.33+25 = 91.66 Mbit/s EF which is less than the line rate of LR1 – port 3, so this should work if we reserve 3 flows with these bandwidths. First, we do the test without QoS reservations (Figure 2-27). Because we have 3 sending 100 Mbit/s ports, there is contention for the LR1 -–port 3 from about 33% load which can be seen in the frame loss and delay figure (because the queues get filled). See Figure 2-27 for a packet size of 1518 bytes.
R522/D523 Public
p.42/90
30/04/03
Figure 2-27: Frame loss and average latency for downstream QoS setup without reservation
R522/D523 Public
p.43/90
30/04/03
If we now set up the 3 flows (33.33, 33.33 and 25 Mbit/s), we get the following figures:
Figure 2-28: Frame loss and average latency for downstream QoS setup with reservation
R522/D523 Public
p.44/90
30/04/03
Which don’t need much explanation, except to say that they match ideally the theoretical result. For the upstream setup, a similar quantity of flows is used, with an extra gigabit stream: • 2x BE upstream from LR1 – port 3 to Smartbits connected to remote management (2x 33.33 Mbit/s) • EF upstream from LR1 – port 3 to Smartbits connected to remote management (33.33 Mbit/s) • 2x BE upstream from LR2 – port 2 to Smartbits connected to remote management (2x 33.33 Mbit/s) • EF upstream from LR2 – port 2 to Smartbits connected to remote management (33.33 Mbit/s) • 3x BE upstream from LR2 – port 1 to Smartbits connected to remote management (3x 25 Mbit/s) • EF from LR2 – port 1 to Smartbits connected to remote management (25 Mbit/s) • BE from LR2 – port 6 to LR1 – port 3 (1 Gbit/s) The results for no QoS setup can be found in Figure 2-29. The reason that the delay is low for the BE_from_LR2_to_LR1_1000 Gbit/s flow is 1) Because it is not going to Darmstadt and avoids the propagation delay 2) There are no big queues on its way. When we reserve the 3 flows as QoS, we get Figure 2-30 which is again ideal!
R522/D523 Public
p.45/90
30/04/03
Figure 2-29: Frame loss and average latency for upstream QoS setup without reservation
R522/D523 Public
p.46/90
30/04/03
Figure 2-30: Frame loss and average latency for upstream QoS setup with reservation
R522/D523 Public
p.47/90
30/04/03
3 Service demonstrations and user trials
3.1 Introduction This section consists of the user tests and the service demonstrations respectively and aims at the experiences of friendly users and their subjective assessment of system handling and quality of provided applications. At first the over all concept of tests with friendly users is summarised. Secondly, the conditions and circumstances concerning the offered services as well as restrictions related to the realised last mile connections to the HARMONICS network are described. Then activities of the field trial itself are described containing the course and kinds of events from user briefing over specific tests up to long time demonstrations. The results of the tests are summarised based on the assessment of the interviewed testers. As conclusions an over all evaluation of the trial experiences will be given.
3.2 Test concept In general, the concept is to set up and test the HARMONICS system in a ‘near-real environment’. Therefore, friendly users located on the premises of T-Systems in the city Berlin are connected over different last mile technologies to the HARMONICS network. These users are mainly employees (e.g. technical and scientific staff members). The demonstration aims at the subjective evaluation of the Harmonics service quality by the users, e.g. the user can assess the quality of system by consuming bursty applications like WWW browsing or file transfer as well as QoS-dependent video and audio applications. For QoS test the users have the opportunity to temporary reserve flows via a simple Management GUI dependent on the required service. Although the system is tested by friendly users (users who obey certain rules) violation of these rules might result in degraded performance and should be investigated upon notification. The quality of service performance delivered by the Harmonics system is tested by the users end-to-end, including the optical core and access parts. This allows a fair judgement of the performance of a complete system, loaded with real traffic in an easy visual way. More specifically, the performed user tests and service demonstrations can be divided into three test types. First, a uniform user test with test instructions during a specific, prescribed time frame named ‘test weeks’. This approach aimed to obtain duplicable and therefore comparable results with defined network circumstances. Secondly, the users had free time and no restrictions to make use of the HARMONICS network applications the way they wanted to. By doing so, the testers could gather experiences of the long time network behaviour and find ‘unexpected’ effects. And third, a terminal with connected TV set was installed in a public area accessible for any interested person to broaden the number and variety of users.
3.3 Field trial services The field trial set-up and installation has been described in section 1. With respect to the service requirements as well as QoS characteristics of the connections the principally relevant facts are described here. Different techniques with different restrictions are installed containing of wireline and wireless last meter technologies over various media (glass fibre, plastic fibre, twisted pair copper, radio) providing bit-rates of 10..100 Mbit/s. The available maximum bit-rates of the possible last meter technologies and the bit-rate limit set in the management service level agreement are summarised in Table 3-1. Table 3-1 also gives an overview of the applications provided in the field trial and the required/recommended network capacity.
Table 3-1: Overview of applications and last meter technologies used in the field trial
With respect to the descriptions and assumptions made in the project, these can be classified into the following application categories:
• Interactive real time. This category will need timely, reliable and predictable flow of packets. It is expected that packets will arrive a relatively short time after sending. Packets will arrive at regular timeslots, and losses along the data path will be low. Because of the timely nature of delivery, re-transmissions are unlikely. Exemplary applications in the field trial are online network gaming and A/V conferencing (NetMeeting)
• Non-interactive real time& interactive-non real time. In this case the transmission delay through the network does not allow for real-time communications, but packets do arrive predictably, with low loss rates. Exemplary used in the field trial are video streaming applications. (interactive-non real time: VoD and Non interactive real time: live TV streaming)
• Non-real time applications with no specific QoS requirements like Internet browsing or file downloads. This application data have no quality requirements and will arrive, eventually (Best Effort)
3.3.1 Video-streaming applications (real time / non real time) An essential service within the HARMONICS network is audio/video transmission, which requires high transmission bit-rate and above all the guaranteed provision of this capacity to the users. The available videos for the field demonstration had different characteristics regarding format and compression. Because of that, the subjective video quality as well as the network transmission requirements for HARMONICS feeder and last meter technologies varied accordingly. Video data formats by the file extension:
• *.MPEG / *.MPG: MPEG-1 and MPEG-2 coded videos • *.VOB (DVD Video Object) is basically one of the core files found on DVD discs and contains of a
multiplexed stream of MPEG-2 video stream, audio streams and optionally subtitle streams with total bit-rates of about 11 Mbit/s.
• *.MOV (Apple QuickTime: a video structure format here containing of MPEG-coded videos) • *.AVI (“Audio Video Interleave” a video structure format here containing of DivX-coded videos)
Compression types:
• MPEG-1 is a video standard developed by MPEG group and meant for medium-bandwidth usage up to about 1,5 Mbit/s.
• MPEG-2 is meant for high-bandwidth/broadband usage and commonly used in digital TVs, DVD-Videos and in SVCDs
• DivX (MPEG-4 with more compression and lower bit-rate) The use of this different formats and compression types aims at the valuation of network and QoS management issues dependent on “quality per capacity” and allows the assessment of bit-rate required to please the customers needs. Additional it was checked if the different performance of customer equipment is relevant to subjective evaluated quality. The audio/video data itself have been made available to the customers as the services
• Video-on-Demand • Near-Video-on-Demand • TV Live-Streaming
R522/D523 Public
p.49/90
30/04/03
Figure 3-1: Video server graphical user interface
The users have access to two video servers. An intuitive server user/system interface (a graphical user interface / Figure 3-1) allows the easy starting of the different streams by clicking on movie-icons or program descriptions. Following the services are described in more detail with respect to their characteristics. Video-on-Demand (VoD) Various videos with different qualities and bit-rates in a range of 1 to 10 Mbit/s are available from two different servers, one in Berlin and the second in Darmstadt. By clicking the icon of a movie, the user starts a dedicated video stream from the server to his displaying equipment. Therefore, this stream represents a Unicast point-to-point transmission type. The user can start the service/video at any time he likes.
Near-Video-on-Demand (n-VoD multicast or rather a mix of uni- & broadcast) This is not a “dedicated service” but represents a program (prescribed succession of videos in a fixed time schedule) provided by the server. In difference to the VoD the user can not start the video any time. He has access to running videos, which are constantly streamed by the server. Therefore, normally the same data are distributed to the demanding users in a Multicast point-to-multipoint transmission type. But because the routers are not able to handle multicast a modified method is applied: Instead of multicast the routers establish a Unicast p.-t.-p. to e.g. the EoVDSL switch and the switch itself broadcasts the data to all clients. TV Live-Streaming (multicast or rather a mix of uni- & broadcast) With the same p-t-mp transmission type like n-VoD a live program channel was provided. The video data in this special case are not stored on the hard disk of the server. A television channel is constantly compressed by a MPEG-2 encoder card, which is included in the server and is streamed live-on demand to the user. Quality relevant parameters are
• CODEC / compression format • Bit-rate: asymmetric bit-rate with throughput of1.5 - 11 MBit/s • Response time (of application / codec) should be low for fast zapping / can be longer for VoD • End-to-end delay: <1 – 3 sec • Cell/packet loss: <1 %
3.3.2 Interactive applications Gaming: As an interactive application a network game (name: “Quake II”) have been provided where the users run the game on their PC’s and connect to each other via a game server. This application has specific high requirements regarding the response time / delay is online gaming via the network. Since only few data (control information) are exchanged between user equipment and game server the main requirements are dependant on the performance of the user PC nor for high network capacity.
R522/D523 Public
p.50/90
30/04/03
Gaming requirements:
• Bit-rate: symmetric bit-rate with throughput of 5 kBit/s up to MBit/s • End-to-end delay: very low response time (100 ms) • Delay variation: • Cell/packet loss:
NetMeeting: The second exemplary interactive real-time application is NetMeeting where users communicate using a common application via the data network. Particularly the audio and video communication and minor the exchange of data require especially low delay and low delay variation as well as constantly and guaranteed transmission through the network. Voice (VoIP) requirements:
• Bit-rate: symmetric bit-rate with throughput of 4..64 kBit/s • End-to-end delay Delay: <400 ms • Delay variation: <10 ms • Cell/packet loss: <3%
3.3.3 Best effort applications As services and applications with no specific requirements for QoS guarantees are Internet browsing, file transfer / download … These usually bursty applications work on a best effort basis which means they can also be run with limited bit-rate, longer delay time or packet losses. The network capacity will be used according to the available amount and shared among all other best effort traffic.
3.4 Field trial tests
3.4.1 Preparation Before the start of user trials it was necessary to introduce the people in the test concept itself and the circumstances to have in mind. It was essential to give the users background of the HARMONICS management concept because they had to set-up and release capacity reservations by themselves taking into account the bit-rate restrictions of their last meter connection and the service level agreement (SLA) as well. They also had to be introduced in the various services to apply and the procedure of starting. Therefore, a meeting with the possible users was held where user relevant topics have been presented. Several additional documents have been produced and handed over to the testers:
• A user manual visually describing step-by-step how to set the management reservations, to start the video streams from the video servers, to join a network game and to log in the game server. (The user manual contains of 21pages with short instructions mainly in German. Nevertheless, the screenshots of graphical user interface windows assisting the manual are dominating the instructions of the document. Exemplary one page of the manual, the ‘short guide’ can be seen in Figure 3-2.)
• The ‘test weeks’ instructions are giving a detailed course of actions during the ‘standardised’ tests uniform for all users
• A general questionnaire collecting information related to the users themselves, their attitude towards services and their experiences and habits related to network access so far
• A ‘test weeks’ questionnaire with questions related to the impressions of the standard tests (‘test weeks’ instructions)
• A final questionnaire with general HARMONICS and service related questions after finishing all tests
R522/D523 Public
p.51/90
30/04/03
applications short guidestart test
end test
live-TV-streaming and Video near on Demand (Multicast)
Video On Demand (VoD)
Fast Internet
NetMeeting
Network game
Playback of movies with DivX-codec (*.avi)
start Internet application via
Internet-Explorer
(for this application no reservation is
intended -best effort)
open NetTV
select videofrom server
Berlin or Darmstadt
inspect the bit-rate recommendation
for the movie
reserve appropriate
bit-rate
start video watch video
end video
eventually tear down
old reservation
open QClientCtrl
select *.avi-video
reserve bit-rate
(ca. 1Mbit/s)
start video watch video
end video
eventually tear down
old reservation
open NetTV
select video program from Multicast-Server
inspect the bit-rate recommendation
for the movie
reserve appropriate
bit-rate
start video watch video
end video
eventually tear down
old reservation
join a game on the server
playing finishing game
start gameafter finishing:
tear down reservation
join the service or
reserve bit-rate
eventually tear down
old reservation
join a game on the server
playing finishing game
start gameafter finishing:
tear down reservation
join the service or
reserve bit-rate
eventually tear down
old reservation
NetMeeting conference…
finish NetMeeting
start NetMeeting
establish flowbetween clients &
reserve bit-rate
after finishing: tear down reservation
NetMeeting conference…
finish NetMeeting
start NetMeeting
establish flowbetween clients &
reserve bit-rate
after finishing: tear down reservation
Tear down all reservations
Figure 3-2: Short guide to trial services giving a step-by-step support
3.4.2 ‘Test weeks’ with specific test plan Uniform user tests during a defined time frame named ‘test weeks’ aim to obtain duplicable and therefore comparable results with controlled network circumstances. A specific test schedule, the ‘test weeks’ instructions, prescribes actions to be carried out by the testers step-by-step. The schedule has been composed enabling the testers to get through the guided steps in about half an hour time. In the time of the test-weeks, depending on the day, a background traffic load was fed into the HARMONICS network additional to the testing users data streams. Therefore, it was possible to test the network performance and the services quality depending on the HARMONICS QoS management under day specific conditions. During this ‘test weeks’ the following tasks were carried out:
• Test of the management • Test of video streaming • Test of network gaming • Test of A/V conferencing NetMeeting
3.4.2.1 Test of the management system Principle: This test aimed to evaluate on the one hand the functioning of the HARMONICS management in connection with services. The set-up and release of end-to-end flow reservations have to be made manual for the different applications and capacity requirements. Therefore, on the other hand it should be tested if the operation of the management with graphical user interface (GUI) works well. The operational steps to be made by the users to establish a guaranteed QoS flow are supported by a more or less intuitive GUI. After starting the MS Explorer window one can see the IP Address of the client PC and by pushing a button one starts the Java applet window to enter login and password data. (Figure 3-3)
R522/D523 Public
p.52/90
30/04/03
Figure 3-3: Management Login
Then one has access to the Flow Management for set-up of QoS flows by choosing a service type, select the specific application type and establish it end-to-end by entering the IP addresses of the client PC (destination) in the Addresses window. These three windows are shown in Figure 3-4 clockwise.
Figure 3-4: Management GUI for flow set up
The Flow management window is also needed to Tear Down flow reservations after ending the service (Figure 3-5).
Figure 3-5: Management GUI for tearing down flow
R522/D523 Public
p.53/90
30/04/03
Results: To apply this management system and to make settings was not simple for the users. In spite of the visualisation of the input windows an insight of the concept and working of the flow based management as well as basics in IP networking (e.g. knowing of IP addressees…) is required. The difficulties in operation of the management handling have been minimised by the detailed test-user briefing before the test-weeks, and the user manual offering step-by-step support. With this assistance, the users were in the position to carry out the necessary management settings during the tests. It was said especially from older testers that it was somehow unintelligible and complicated to use. Supplementary it was stated that they would not accept this kind of additional effort as ‘real’ customers (then the applications or equipment has to arrange this of necessity.) During the tests, the functioning of the QoS support itself was noticed by all testers. So they noted that it was possible to make reservations in the range of the 10 Mbit/s SLA only and the network performance as well as the services quality especially the capacity demanding video applications increased with successful set up reservations.
3.4.2.2 Test of video streaming Principle: Different qualities of the movies dependent on videos (format, compression and quality) were available for these tests. It was intended to test the ability of the HARMONICS network to provide compressed video streams with and without QoS settings in the management system. Because of the, compared to the system capacity, relatively few users the movies normally could be received without QoS reservations. Therefore, an background traffic was fed to the network during the tests. This background traffic alone represents an load within the limits of the connection. However, if a user starts the video application the traffic exceeds the connection capacity and due to the congesting data packets, the video transmission will be disturbed. The trial set-up for disturbance of untagged video transmission is shown in Figure 3-6 on the example of EoVDSL as last mile technology. The disturbing data stream is produced by the SmartBits traffic generator. The bottleneck is the 100BaseT connection between LR1 and LRE switch due to the huge bit-rate of the disturbance traffic, which is occupying nearly all capacity.
Figure 3-6: Disturbance of video transmission
The result is that data packets of the two Best effort streams will be dropped at the Leaf Router interface. The packet loss of the video transmission leads to a jerking or even stopping movie playing. The users now are asked (by the test instructions) to stop the movie and to run through the HARMONICS management QoS reservation procedure described in section 3.4.2.1 and to set-up a flow with appropriate capacity within the limits of their SLA allowed maximum of 10 Mbit/s. The effect is that the video packets now will be tagged in the IP header as high priority packets that are preferential, treated before the Best effort traffic of the SmartBits.
R522/D523 Public
p.54/90
30/04/03
Results: Without QoS management (disturbed video), all users assessed the movie quality as “unsatisfactory”. After flow set-up the quality assessment reaches from “very good” down to “satisfactory” but mainly “good”. The response time after selecting a video was stated as “tolerable” only. Nevertheless, this is mainly caused by the decoding process and hardware performance. So the half of the testers had the perception that booth videos (same file) started from the Darmstadt server and the Berlin server had the same response time. The other half believed that the movie started faster from the Berlin server. The quality was assessed as equal.
3.4.2.3 Test of network gaming and A / V Conferencing Principle: To test the ability of the HARMONICS network to support specific requirements of interactive services (section 3.3.2) an network game and an Audio / Video Conferencing: application was made available for testers. Especially the multiplayer action game requires very short response time or delay respectively because the players interactions should not be without any noticeable delay. Ideally the delay must be shorter than human reaction time. The conferencing is not requiring this low delay range but a short delay variation and more bitrate. The tests have been performed again with and without QoS settings and with disturbing background traffic. Therefore the same set-up was used as shown previously in Figure 3-6. Results: The results are equal to the outcomes of the video service tests. The network game was functioning with QoS reservation settings with very short imperceptible response time even with background traffic. The same assessment was given for NetMeeting application, which worked without complaints.
3.4.3 Free tests and long time demonstration In addition, a long-term demonstration of TV streaming in a room frequently used also for breaks has been carried out. This involved access to the system and all services for everybody. The user PC was connected by EoVDSL with bit-rate of max. 17 Mbit/s. Additional a TV set was connected to the PC’s MPEG-2 decoder card with TV output allowing the long time display of a live TV program stream.
Conferencetable
Lab
shel
f
CPEEoVDSL
User-PC
TV
Conferencetable
Lab
shel
f
CPECPEEoVDSL
User-PC
TV
Figure 3-7: Set-up of long-term TV streaming demonstration
Results: As a main problem can be noted, that frequently users forgot to tear down their reservations after finishing the activities. Therefore the unused reservations limited the over all capacity of the routers. As it was set to allow 50 Mbit/s prioritised traffic at maximum at the 100 Mbit/s interface and keep the other half of capacity free for best effort sometimes it was not possible to establish a new flow reservation if some previously made flows are being still active. The experiences regarding the long time stability of the system show that one problem was up to the instable applications that crashed the client PCs or the e.g. video server. Sometimes, also the HARMONICS system crashed due to long term port overload by disturbing traffic.
3.4.4 Evaluation of the trial experiences Impact of last meter technologies: As indicated by Table 3-1 (Overview of applications and last meter technologies used in the field trial) the testers were connected by different last mile technologies. Additional to the HARMONICS system also the
R522/D523 Public
p.55/90
30/04/03
performance of this equipment probably can have noticeable effects on services and applications under test. The gained experiences regarding these effects are related mainly to specific capacity limits but also problems of interoperability and stability. The used technologies provide bit-rates in the range between 10 Mbit/s up to 100 Mbit/s. The users at the 100 Mbit/s Optical Ethernet noted no difficulties at all. In addition, the Wireless LAN providing maximal 52 Mbit/s per mobile client in principle meet the service/bit-rate specifications of 25 Mbit/s if the capacity is not shared among to many clients. In the tests, no problems had arisen with W-LAN. More difficulties were foreseen for the technologies with relatively low transmission capacity. On the one hand, the EoVDSL provides a maximum bit-rate of 15 Mbit/s per VDSL line and on the other hand, EoPOF enables even lower bit-rate of maximum 10 Mbit/s. These characteristics normally do not meet the original HARMONICS specifications. But because only one client PC was available the users they could not exceed the bandwidth limits with one video channel (up to 11 Mbit/s) or with any QoS relevant IP application. Besides this, EoVDSL was tested as a reliable connection. The only problems appeared in connection with the EoPOF equipment long time reliability at demonstration and interoperability during installation. For evaluation of the trial experiences is mainly based on evaluating the answers of the users to referred questions. Some general questions at the beginning of the trials aimed to characterise the users. With a large majority, the testers use IP networks (intranet, extranet, internet) for more than three years at home as well as in their office. As they are mainly employees of T-Systems they stated that their primary location for this is in the office connected with maximal 10 Mbit/s Ethernet. The questions regarding the IP service related habits show the following
• Frequently usage of email and Internet at least once in a day • The streaming of videos varies between once per week and per year • The majority of the testers never use video telephony as well as internet telephony
Additional it was asked about the person’s attitude towards video and TV consumption.
• They very rarely (to never) get videotapes from the video-tape library The way to the shop is stated as reason for this and if in case of easy/comfortable VoD could increase the consumption of video payment
• The users are used to receive their television programs two thirds by cable and one third by satellite and stated as possible reasons to change the receiving technology on the one hand if the alternative would allow enhanced or additional services and on the other hand if it would be cheaper
• Related to the enhanced video services less than the half are interested in VoD if the price is not exceeding 2..3 € per movie, about the same amount of interviewed state to have no fixed opinion about VoD itself but also name a max. price of 2 € per movie. Only a minority refuse the service and are not willing to pay any money for this. Less interesting than VoD is near-video-on demand. Here the majority stated to have no interest to pay for the service with the exception of less of those who are also very interested in VoD. The max. price has to be less than 2 € as well.
• The large majority is refusing to have access to network gaming and is not willing to pay any money. Only one person would pay, but less than 1 €, for access.
• Finally the interviewed persons have been asked which maximal amount the monthly fixed rate they would accept to change to a service platform offering the enhanced bundle including live-TV, VoD, n-VoD, telephony and network gaming. About one third is not interested at all, on third would accept a limited amount of 25 € and the rest stated to agree to a monthly tariff in the range of 35...45 €.
This answers show that the testers are used to IP networks with high capacity. That’s why they can assess the quality and behaviour of HARMONICS in comparison. This comparison is more related to ‘classical’ IP applications. To judge the video/TV quality the users profile shows that they are mainly receive TV by cable and satellite. This refers to the high quality the testers are used to. By the way, they are no promising pay-per-movie customers before the demos. The service trials have shown that the testers assessed the HARMONICS network performance as good. With the influence of disturbing traffic on the network, they noticed a strong impact on performance and service quality. Using flow set-up in the management system they all noticed the assured QoS support of
R522/D523 Public
p.56/90
30/04/03
HARMONICS in spite of network overload. With activated reservations within their limits (SLA), the network performance was rated as very good. After finishing all tests the users have been asked some final questions regarding the HARMONICS network assessment. The question if the users would be interested in a platform realising the HARMONICS concept and offering the tested services show that about the half of them answered with “YES”. This can be explained by the good experiences of the users regarding good performance and additionally supporting QoS. These users are interested in the network because they are mainly interested also in the enhanced service possibilities, especially the video services. Nearly the same amount of testers answered with “DON’T KNOW” meaning they have also found the good features and characteristics of HARMONICS. They are not interested in additional video services or are not satisfied by the quality of the (compressed) videos and will not accept additional expenditures at all. This shows that the acceptance of the innovative network concept depends mainly on service needs of users.
3.5 Conclusions Services quality was assessed different. Gaming performance was generally judged good. Regarding the video services, the assessment varies. This can be explained by the fact that the quality of the video playback, especially picture definition and clearness as well as response time strongly depend on the quality of video files/streams and the performance of the players using hardware or software decoders. In the Field Trial, the video quality depended on the user terminal performance. It can be summarised that movies, which are supported by the user terminal performance and possess good quality from the start can also be provided by the HARMONICS network to the users satisfaction. The operation of the management system had to be made manually. This was difficult for some testers. The graphical user interface, developed for an easier QoS set-up, did not fully simplify the flow set-up procedure. A commercial implementation of the HARMONICS system requires a simplification and automation of the flow reservations. Problems arise when users forgot to tear down their reservations but this could be prevented by automatic QoS set-up. The management system operation was successful proved by inspecting the end-to-end guaranteeing of different QoS characteristics of different services under network overload conditions. The HARMONICS network meets the requirements for interactive and real-time as well as non real-time applications In conclusion, the field trial demonstration and friendly user tests respectively certify the functioning of both the HARMONICS system set-up and especially the HARMONICS management system.
R522/D523 Public
p.57/90
30/04/03
4 Summary of the HARMONICS optical lab trial This chapter gives a short recap of the outcome of the optical lab trial. The original plans included a full optical feeder network to be demonstrated during the field trial. Changes in the project plan prohibited full implementation of the OFN, and key functions were proved during a separate lab trial. For a complete view of the system results, the main issues addressed in this lab trial are presented here.
OFN
ONU
RX
multi-wavelengthX-connect
wavelengthsplit
RX RX RX
powersplit
wavelengthsplit
wavelengthsplit
wavelengthsplit
powersplit
powersplit
powersplit
ONU
ONU
ONUONU
ONU
ONUONU
ONU
ONUONU
ONU
ONUONU
ONU
ONUONU
ONU
ONUONU
ONU
ONUONU
ONU
OLT
LSC
OFN
Figure 4-1: Architecture of the HARMONICS Optical Feeder Network with OLT, protection rings, LSCs, and ONUs. The blue parts were implemented to test the key HARMONICS
functionalities.
4.1 Scope of the optical lab trial The HARMONICS network architecture is depicted in Figure 4-1. This figure depicts the OLT as the central place where all the protection rings originate and terminate. The rings are part of the OFN as well as the fibre connections between the LSCs and the ONUs. In this picture only a limited number of ONUs are depicted. Also the size of the optical cross-connect is not given. This depends strongly on the number of semiconductor optical amplifier arrays that are made available. Also the number of different wavelength is not set in the figure. The number of receivers in the OLT is generally determined by the capacity allocated, the line rate of each wavelength in a fibre ring and the multiplexing gain that is assumed. For the implementation and testing of this physical layer, that means demonstrating the switching of packets and the proper generation and detection of packets only one receiver will be realized. Realization of more receivers will not result in operation of more than one receiver. One fibre ring has been implemented. For each fibre ring a wavelength splitter and power splitter is needed and also a protection switch at the OLT. The number of components that is available is for this function is limited and therefore only one ring will be realized. The number of wavelengths is set to two. This is the minimum that is required to demonstrate the switching functionality. Implementation of more than two wavelengths requires more than one 8-SOA array. These were not available. Not depicted in Figure 4-1 are additional electronics that were needed to interface with measurement equipment like a serial cell generator, to a Manchester codec, and with the different drivers that are connected to the opto-electronic components.
R522/D523 Public
p.58/90
30/04/03
4.2 The OLT Figure 4-2 displays a functional diagram of the interior of the OLT. The optical protection switch has the ability to pass on traffic to the EDFA either from the clockwise or from the counter clockwise direction of the ring depending on where a fibre breach occurred.
payloadextraction
unit
burst-modereceiver
bi-directionalEDFA
X-connectλ-switch
opticalprotection
switch
to/from ring
to/from ring
clock
data
payloadextraction
unit
burst-modereceiver
bi-directionalEDFA
X-connectλ-switch
opticalprotection
switch
to/from ring
to/from ring
clock
data
Figure 4-2: Block diagram of the OLT components
The optical upstream signal is then passed on to the EDFA where the multi wavelength signal is amplified to a level where it can enter the X-connect. It is vital that this signal has a high power level because inside the X-connect attenuation will be high due to passive splitters, combiners and two arrayed waveguide gratings (AWGs). Inside the X-connect one SOA might provide some gain. The output of the X-connect contains a sequence of packets. Each packet might be of different wavelength. The burst-mode receiver (BMR) detects the packets that have different optical powers and random phase. The pay-load extraction unit detects the unique word and extracts a pre-programmable number of bits and forwards these, together with an equal number of clock cycles to the output. The next sections describe each of the blocks in detail. A detailed block diagram is given or a reference to a deliverable where the component is described in detail. Where applicable the electronic circuits are given.
4.3 Optical protection switch This unit consists of a cross-bar switch and electronics to control the thermoelectric pads that control the refractive index of the polymer material to obtain the desired cross or bar switching functionality. A photograph of the protection switch module is shown in Figure 4-3. It can be seen that only one of the two switches that can be mounted is in place. The performance can be summarized by stating that the insertion loss between all different input and output configurations was measured to be below 3 dB and that the cross talk levels were below the 46 dB. The latter specification is much better than the 40 dB that was initially specified to avoid coherent crosstalk. The entire switch operates on 5V rather than the typical 6V that was specified in the datasheets. This has the advantage that a single supply can be used and that less heat is dissipated. No performance degradation of the optical signals was observed. The switching time was measured to be 2.2 ms. For protection purposes of access networks this is fast.
R522/D523 Public
p.59/90
30/04/03
Figure 4-3: Protection board with one protection cross-bar switch
4.4 Bi-directional EDFA The function of the bi-directional EDFA is to provide gain to the CW signals that are transmitted in the downstream direction for remote modulation, the data stream in the downstream direction and the upstream signal. The EDFA is based on previous designs for the TOBASCO and PRISMA projects, the measured performance can be seen in Table 4-1.
bandsplitter
Er doped fiber
Er doped fiber
2x 980nm pump upstream
downstream
downstream
upstream
CW (upstream)
Figure 4-4: Optical schematic of the bi-directional SOA
Table 4-1: Measured performance of the EDFA bi-directional module
Booster-amplifier Wavelength [nm] Input power [dB] Gain [dB] Output power [dBm] Noise figure [dB]
The optical circulator that combines the downstream CW and the upstream bursty signal is implemented externally but in the same shelf of both amplifiers for experimental reasons. This allows us to access all inputs and outputs.
4.5 Optical cross-connect The cross connect that will be realised in this section consists of the components that can be found in Figure 4-5.
α α
αα
soasoasoasoasoasoasoasoa
AWG AWGattenuator
SC/APC fiber connector
Figure 4-5: Optical scheme of the cross connect
Several optical components can be observed here. The two AWGs that are needed to split and combine the different wavelength, the 8 SOAs that are located in the 8-SOA array module. and attenuators. The function of the attenuators is to simulate splitters that can be found in a X-connect with more than one spatial input and or output. The value of the attenuator is equal to the splitting factor that is set by the maximum of the number of rings or the number of receivers. In the case of 8 rings/receivers this would be 9 dB. Because we only use two wavelength only 4 attenuators are used. Also in this configuration all the components will be output to the front panel for easy access to characterise and conduct experiments. In the next two sections the two AWG boards and the 8-SOA board will be described. The attenuators are of the shelf connectorized attenuators.
4.5.1 AWG board This board needs only a temperature controller to set the temperature of the AWG chip to approximately 70 degrees Celsius. This way the temperature will be higher than the environment and therefore stable. In previous projects (PRISMA) a digital circuit was used. Now an analogue version is implemented that requires fewer components and can operate standalone. Because of the absence of element management no monitoring functions are implemented although this can be done similar to the EDFA and protection board before the effort reduction took place. The insertion loss of the AWGs was better than 4.5 dB for all the wavelength channels. This is well below the specification of 5 dB. Polarisation dependency was less than 0.4 dB for all outputs.
R522/D523 Public
p.61/90
30/04/03
Figure 4-6: The AWG board and to the right in the box the second AWG board.
4.5.2 8-SOA Array board This board contains the 8-SOA array that performs the actual switching of the packets in the upstream direction. To be able to switch packets every 1.28 µs the edges of the window must be very steep. The gap between packets will in general be increased with the rising and falling times of these edges. So rather than looking at the length of the packets it is more realistic to look at the line rate as the quantity that determines the rising and falling edge. The bitrate of the signal is 625 Mb/s (half of the Gigabit Ethernet rate) and has therefore a bit time of 1600ps. The intrinsic speed of the SOAs itself is about 1ns. The principle of the driver is illustrated in Figure 4-7.
Vcc
GND
Vcontrol
driver
resistor R
SOA
GND
Figure 4-7: principle of the high speed driver of the SOAs
When the control voltage Vsoa is low then the current will flow through the resistor and the SOA device. The current will be equal to Isoa= (Vcc-Vcontrol)/R. Based on the values of the voltage versus current characteristics of the SOAs (see Table 4-2). A resistor of 35 Ohm and a supply voltage of 7 V would result in a current of 140mA through the SOA when switched on and a current of 0mA through the driver when the SOA is switched off.
R522/D523 Public
p.62/90
30/04/03
Table 4-2: SOA voltage for a supply current of 140 mA
SOA number Voltage at 140mA [V] 2 2.08 3 2.17 4 2.05 5 2.22 7 2.02 8 1.99
Unfortunately the supply voltage is only 5 V and a compromise must be found. A resistor of 23 Ohms gives a current of about 130mA through the SOA when switched on and when switched off a current of 217mA flows through the resistor of which the driver shunt 200mA leaving 17mA of current flowing through the SOA. This current is still low enough to cause no change in the optical attenuation of the switched off SOA. Based on the optical characteristics of the SOA array we use SOA 2 and SOA 4 to switch the 1550.12 and 1550.90 nm wavelengths because they display the best performance in terms of gain and saturation output power.
Figure 4-8: 8-SOA array board with drivers.
Figure 4-8 displays the actual implementation on a standard eurocard board. This board fits between the two AWG boards. The RF switching signals are fed to the card by the front side. Having a RF back plain for this demonstration would only increase the costs. and not result in better performance. The temperature properties of the device were only known when the device was delivered. To this end the temperature was stabilised using an external temperature controller.
4.6 Burst-mode receiver The burst mode receiver that is used in this project has the function of receiving packets of different amplitude and different phase. Its job is to provide a clock signal and data signal of known electrical levels that contains the last few bits of the leader (a sequence of zeros and ones), the unique word, the payload and possibly a few bits of a trailer. The receiver is offered a gap to allow itself to be reset and to adapt to the arrival of the new packet. As stated in previous deliverables the usual implementation is a dc coupled receiver with peak detection to detect and hold the amplitude of the optical signal during the first bits that arrive after the reset of the receiver. The detection threshold will be half this peak value. The second task is to perform synchronisation
R522/D523 Public
p.63/90
30/04/03
to an internal clock which does have the same frequency but in general not the same phase. This is called bit slot synchronisation. In HARMONICS, a novel BMR was developed that uses a AC coupled receiver, a limiter and assumes a manchester coded RZ input signal. This means that the input signal has a symbol rate of twice the bit rate. A 625 Mb/s logical "1" is mapped to a "01" sequence at 1250Mb/s and a logical "0" is mapped to a "10" sequence at 1250 Mb/s. This has the advantage that a clock is available in the data signal e.g. it is always possible to extract the clock signal relatively easily. Also if jitter and wander occurs on the data signal the same jitter and wander will be displayed on the clock signal and the phase relation between clock and data will be maintained. This is an advantage when it comes to a asynchronous implementation up until the resynchronisation in the first FPGA/ASIC of the receiver board. And in addition no information is stored in the DC component and also in the lower frequency spectrum no information is available. This allows the use of a blocking capacitor between the transimpedance and the limiter amplifier. The final implementation of the BMR (Figure 4-9) included a payload extractor to measure the net effect of the transmission and switching characteristics on the user data.
Figure 4-9: realization of the BMR with the payload extractor. The top PCB contains the
BMR. The three yellow blocks in the center of the top PCB are the delays that are responsible for the reconstruction of the data and clock.
R522/D523 Public
p.64/90
30/04/03
4.7 Optical Feeder Network The optical feeder network consists of optical fibre and the local splitting centre. Figure 4-10 displays this optical feeder network.
SSMF
OLTprotection
board1:8splitter
protectioncoupler
SSMF
SSMF
SSMF
AWG
Local splitting centre
ONU
ONU
TERMINALEQUIPMENT
OPTICALFEEDER
NETWORK
protection path
main path
Figure 4-10: Optical feeder network. The OFN consists of the fibre and components that are
to the right of the dashed fat line.
4.7.1 Optical fibre (SSMF) For optical fibre standard single mode fibre is assumed and implemented. This fibre has a typical dispersion of 17 ps/nm/km at 1550nm. The dispersion slope is 0.8 ps/nm/km/nm. The effect of dispersion on the system is given by the bandwidth of the signal (this is approximately 2.5GHz) and the number of channels which was initially designed to be 8. With respect to the dispersion acting on the data signals it is calculated that the actual broadening of the edges is less than 7 ps for a 20km OLT ONU connection. This is a worst case situation. The pulse broadening that occurs is less than 1% of the bit time of the symbol rate (1.25 GHz) of the upstream signal and can therefore never play a role. For the actual testing of the system a ring with a total length of 20km is assumed. The LSC is located just slightly out of the centre of this ring.
4.7.2 The local splitting centre
4.7.2.1 The protection coupler This is a normal 50% coupler. The insertion loss of these couplers is typically lower than 3.5 dB for a low cost type. The coupler does not necessarily be symmetrical as long as enough power is available for the protection path. The type of coupler that is used is broad band covering the C band as a whole.
4.7.2.2 The AWG board This device is to split each different wavelength into its own fibre. This component should be passive because it is located in the field where no power is available. This device is therefore called an a-thermalized AWG. Because it was not made available to the Task 3.4 and 3.5 a conventional AWG was used as described in Section 4.5.1 The device showed similar performance.
R522/D523 Public
p.65/90
30/04/03
4.7.2.3 The 1:8 splitter The power splitter is to connect a group of ONUs to a single wavelength output of the AWG. This is a typical broadband device and is therefore replaced by an attenuator because attenuation is the only system performance limiting effect. A 1 to 8 coupler causes about 10 dB of loss. Therefore a 10 dB attenuator was inserted. The uniformity between these couplers depends strongly on the manufacturing process. A 1 to 8 splitter that is build from seven two-by-two couplers will show a better uniformity than A fused 1 to 8 splitter. In general the uniformity of these commercially available splitters is well below the 0.5 dB. Figure 4-11 shows the OFN. The fibre was not unspoiled but left on the bobbin.
Figure 4-11: Picture of the OFN. The two spools in the box each carry about 10 km of optical fibre. The shelf to the right contains the local splitting center. The two optical connectors to
the right connect to two ONUs under test. The two connectors on the left connect to the protection switch of the OLT.
4.8 The ONU burst mode transmitter In this section two types of ONU transmitters will be described. The initial transmitter was intended to be a reflective modulator. During experiments that will be described in more detail later it turned out that this kind of modulator caused problems in its experimental implementation. Therefore a tunable laser diode would be the preferred source in the ONU. The unavailability of this source at this time resulted in the implementation of a dual source transmitter. This was needed for being able to test the optical cross connect, the packed switching and the error-free detection of the transmitted packets
SOA PBS
90°
driver data
driver TXon/off
TE
TM
to OFN
CW downstreamDATA upstream
Figure 4-12: optical schematic of the reflective modulator
Figure 4-12 displays the optical schematic of the reflective modulator for modulating downstream CW light into upstream data. CW light that is transmitted downstream is passed through the optical fibre network and reaches the ONU. Here it is amplified by the SOA (if the SOA is switched on!) and passed on to the Polarisation Beam Splitter (PBS). where the TM and TE component are split. The TE components passes clockwise through the loop and reached the Mach Zehnder modulator and is being modulated it leaves the
R522/D523 Public
p.66/90
30/04/03
modulator and is rotated to the TM polarisation before it enters the PBS again. The TM component is first rotated to become TE and than passes the Mach Zehnder modulator and enters the PBS as a modulated TE signal. At the output of the modulator the modulated version of the CW input signal is therefore found. Now it is re-amplified by the SOA and send to the OFN in the upstream direction where it eventually will be detected by the OLT burst mode receiver.
Timing issues The timing issues that are described here deal with delays that exist between the on and off switching of the SOA and the modulation of the data. Typically, all components that have been used have a 1.5m of fibre spliced to them. The PBS and MZ have PMF fibre to the TE and TM and the input and output of the modulator. This is a total of about 6m. The SOA and PBS are also connected by a total of about 4m of fibre. The delay between the CW light leaving the SOA and the modulated light re-entering the SOA is therefore about 50ns. At a modulation speed of 615 Mb/s this is about 32 bits of data. The consequence of this delay is that an additional delay of 32 bits needs to be introduced between the data and TX ON/OFF signal. In the case of our demonstration where we have a limited number of line cards in our measurement equipment we cannot provide this delay. In addition as a result the gap between the cells will be extended artificially by 32 bits.
Power issues The loss that is introduced by the PBS, MZ and modulation is measured to be 11.7 dB. This means that the signal that is returned to the SOA will be about 12 dB lower in power. The SOAs that we were able to purchase have a gain of 20 dB and a 3dB-gain saturation power of 5 dBm. These were the only SOAs that were available for purchasing at that time. Other suppliers did not respond to RFIs and RFQs. Some could not deliver while others showed an even worse performance with respect to saturation output power. The art in making SOAs is to have reasonable gain and a saturation output power that is as high as possible with as less gain saturation as possible. The SOAs purchased from Samsung display a high gain and noise figure that results in a saturated device even without an optical input signal. At the fibres an ASE output power was measured 8 dBm. The fact that the power difference between both fibres was less than 0.2 dB suggests that the fibre-chip coupling is of good quality. An SOA that is not already saturated has a typical power input range (and an output range of powers) where the device is not saturated (no pattern effects are imposed on the data signal) and where the noise that is added to the input signal is still low enough not to cause significant ASE power penalties. The consequence for an optical signal amplified by an SOA is dependent on the type of that optical signal, it's power and the characteristics of the SOA. Usually a SOA is used to amplify three kinds of optical signals: 1. An optical signal without noise (or noise with an optical power that lies 40 dB below the carrier e.g. a
signal from a laser diode) is amplified for the first time as is the case when a single SOA is used as an optical preamplifier. In this case the SOA is only saturated by the optical data signal. This saturation will be negligible because the input power will be so low that the noise will be the limiting factor and not pattern effects.
2. An optical data signal with unmodulated ASE noise that is broadband (unfiltered). This is the case when amplifiers are being cascaded . These kind of amplifiers are called in-line amplifiers What happens in this case is that ASE noise is amplified each time and a new portion of noise is added. The optical signal itself is amplified but with increasing amplifier number the signal becomes more sensitive to pattern effects due to the decreasing saturation output power. The ASE noise has consumed most of the available saturation output power On top of this the increasing noise levels cause the minimum optical input power required for noise insensitive amplification to increase. The before mentioned typical optical input range rapidly decreases with increasing amplifier number.
3. An optical data signal with unmodulated ASE noise that is in-band (filtered). To increase the number of maximum amplifiers in the link (See item 2) it is possible to filter out the out of band noise after each in-line amplifier. This results in less saturation of then next amplifiers at the cost of an optical band pass filter. The only limiting factor is the in-band noise.
R522/D523 Public
p.67/90
30/04/03
In the situation of Figure 4-12 an optical CW light signal is amplified (in itself this will not cause pattern effects) regardless of whether the amplifier is driven into saturation. (This depends on the position of the ONU in the network and the optical attenuation between the OLT and ONU!) Let us assume that the SOA is not driven into saturation. In that case the output signal of the SOA consists of the amplified CW signal and a lot of ASE noise which is equal to the measured 8 dBm minus the CW light at he output. If the CW light is not driving the SOA into saturation than the output power should be well below the 5 dBm (3dB gain saturation output power of the SOA). Under these conditions a CW light output power of +1 dBm has been measured and a TOTAL ASE output power of 6 dBm. This signal s being modulated by the PBS and Mach Zehnder modulator structure. In contrast to the previous three situations now the ASE is modulated as well. Now when the signal re-enters the SOA the input power of the modulated CW signal is -11 dBm and the power of the modulated ASE noise is about -6 dBm. When these signals are fed into the SOA the gain saturation will be so huge that eye closure due to pattern effects has become the dominant penalty to an extend where error-free detection is no longer possible. And if that is not enough, a second effect will cause an even greater deterioration. The modulated data signal and modulated ASE noise signal will not only cause pattern effects limited to a single bit but also on the CW light that is amplified in the downstream direction. So the light that is to be modulated is no longer CW but has already pattern effects caused by earlier modulation. So, the pattern effects found on the upstream traffic are caused by the complete history of all the bits transmitted by the ONU. These effects are caused by the delay that was touched upon in Section 0. A near-zero delay (as would be the case when integration was considered) would have suppressed this effect. There are some solutions that may solve this issue: • Use a filter between the SOA and the PBS. This would result in a wavelength sensitive ONU. A directly
modulated DFB laser diode would be a cheaper and preferred choice. • Use an attenuator between the SOA and PBS. This would solve the saturation effect but the output
power of the SOA would also be affected. In addition the attenuator should be adjusted to the position and location of the ONU in the network. Power ranging would be required even with the Manchester coded RZ pulses that ere chosen with the purpose of avoiding power ranging.
• Usage of two SOAs (one for the CW light and one for the modulated light. This will solve the cross saturation issues but the saturation due to the modulated ASE noise remains.
• Use an SOA that has a low gain, high saturation output power and produces no noise. These kind of SOAs would be the preferred ones but none of these are available.
Figure 4-13: Interior of the reflective modulator part of the ONU
Figure 4-13 shows the interior of one of two reflective ONU built for the lab trial. The black rectangle in the bottom of the box is the PBS, slightly above is the modulator and driver circuit and to the right the SOA and driver and cooler can be found. This version uses an external power supply unit.
R522/D523 Public
p.68/90
30/04/03
4.9 Optical system experiments and specifications In this section some overall specifications of the optical layer for the upstream burst mode transmission is given. This is done by measuring on the setup given in Figure 4-14.
OLT Unit
LSC
CP1
CP2
RX
CiIRC1
AWG4
CP3
SOA1
SOA2
PROT1
AWG1
AWG2
serial cell generator and analyzer and digital sampling scope
MC-RZ and auxiliary signal converter
EDFA1
SOA
SOA
Figure 4-14: Full setup of the system with two ONUs and a protection path
Figure 4-15 displays a photograph of how this setup looks like. The monitor displays the control software that is programmed to perform the proper switching and synchronisation between the different network elements.
4.9.1 Measurements
Figure 4-15: Photograph of the full measurement setup
Many experiments have been carried out to test and validate the system. The results were translated to specifications that allow for error free (BER<10-9) operation of this optical layer. In the next sections some of the results are presented into more detail. The detection of packets can be observed from the same outputs that are used for the BER measurements. The header, unique word and trailer are stripped.
R522/D523 Public
p.69/90
30/04/03
Figure 4-16 displays several packets that are detected. Packets arrive in turn from ONU1 and ONU2 on different wavelengths. The X-connect switch makes sure that the packets arrive with a 100% load at the receiver. The large gaps between the packets may appear large compared to the pay load but in general the payload of a frame will be much larger. This way with more packets received more weight is put on the proper detection of a packet.
Figure 4-16: Several detected packets. Only the payload is visible. Header and unique word
have been stripped
Figure 4-17: Begin of a detected packet.
Figure 4-17 and Figure 4-18 display the first and last bits and clock edges of the payload (128 bits) of a packet. It can be seen that no anomalies take place at the beginning and ending of a packet. This is of importance as the entire processing including a deserializer operates asynchronous and relies on the available clock information in the packet.
R522/D523 Public
p.70/90
30/04/03
Figure 4-18: End of a detected packet (only payload visible)
Figure 4-19: Random detection of the unique word due to chattering of the receiver
A very interesting feature exists due to the chattering of the AC-coupled Burst Mode Receiver. In the case where the receiver does not receive any packets the input stage of the limiter becomes noisy after a while and the output stage will generate random sequences of ones and zeros from the amplified receiver noise. This situation also occurs when the PON is in its ranging mode and several time slots (0.2ms) can be empty. Due to the random bits generated by the limiter, random bits are entering the unique word detection circuit and can trigger the extraction of a 128 bit payload by error. This is pictured in Figure 4-19. The bottom trace is the trace of proper packet detection. The upper trace is the clock output. The middle trace is the data output. After the reset pulse has reset the unique word detected data-flip-flop, the absence of an optical signal will cause the receiver to faulty detect the presence of a packet. The change that this happens increases with time as more random bits pass the shift register and are compared with the unique word. This is the reason why the density of the green and yellow traces increases with increasing time. At one point the reset pulse clears the payload extraction circuit and the clock signal will be high and the data signal low. Now no payload extraction is possible. Once the reset pulse has passed the receiver starts looking for the unique word and the story repeats itself. In the case of ranging the unique word can be extended by 8 bit words to be processed by an FPGA or ASIC to determine whether a proper ranging cell has been detected. This procedure can be
R522/D523 Public
p.71/90
30/04/03
started anytime and repeatedly when a unique word is detected. This way chattering can be limited to 8 bits without losing frames.
4.9.2 Penalties The following penalties and transmission impairment have been identified and investigated. 1 Coherent cross-talk penalty: 0 dB (not measurable) due to an excellent protection switch >40 dB
contrast and the use of multiple HDWDMs that result in effective higher order filtering. The two HDWDMs are good for >45 dB of cross talk suppression in combination with low gain SOAs
2 Inter-channel cross talk (non-coherent) in l-switch: 0 dB (not measurable) due to the two HDWDM with a total cross-talk suppression of > 45 dB
3 Inter-channel cross talk (non-coherent) in ONU SOA: 1.5 dB this is due to the cross-gain saturation in the SOA located in ONU when both lasers are switched on
4 SOA uniformity penalty (reduction of receiver sensitivity): 2.4dB. there is a large difference between the SOAs performance (2 SOAs have best performance, 2 SOAs have poor performance, 2 SOAs you do not want to use and the remaining 2 SOAs did not work.
5 Dispersion penalty: 0 dB. 17 ps/nm/km results in < 5ps to ISI contributing pulse broadening for 20km which is negligible compared to the bit time of 800ps.
The introduction of more channels will not complicate the cross talk problem. The reason for this is that cross talk in this system is limited to neighbouring channels. It has already been investigated and confirmed that two neighbouring channels do not influence each others performance significantly. Even in the case a third channel is added the middle channels is not expected to be influenced by it significantly as the cross talk problem can only start in a worst case scenario and a small penalty of a few tenths of dB can be expected. A source that may also cause inter-channel coherent cross talk is the residual power that passes through the SOA when switched off. When switched off the SOAs have a typical attenuation of 43 dB. This is satisfactory to exclude this kind of cross talk contribution for 100 groups of same wavelength ONUs of which one ONU per group is transmitting. Cross gain effects in the EDFA only occur when for a long period of time signals disappear or contain zeros. In the case of MC-RZ the latter will not occur and the MAC algorithm can account for the first condition. The fact that this is possible allows for almost unmanaged EDFAs to be implemented. Only in the case of ranging a problem may exist due to the reception of too much optical power. This problem may be solved by using already known in formation of the position of the LSC or other ONUs to limit the ranging window and as such stabilise the saturated gain of the EDFA.
4.9.3 Specifications Below the latest measured results and specifications are summoned. • Dynamic range between cells : 15.8 dB between 10-9 BER points • Dynamic range of input at protection switch : 20.4 dB • Common mode power range (for aging etc.): 4.6 dB • bandwidth of bitrate 620 to 630 Mb/s using 1240 to 1260 Gb/s MC-coding • length of cell : set to 128 bits payload (PECL technology limited) but arbitrary when integrated in ASIC. • total gap time : 32 bits minimum • BMR reset pulse position : between 1 bit after trailer and 1 bit before unique word arrival • BMR reset pulse duration: 1 rising edge • time of leader for power equalization : 12 bits • time of trailer : < 8 bits (depending on deserializer technology) • bit synchronization : immediately and asynchronous • allowable jitter in cell : 25 ps (peak-peak jitter) • allowable jitter between cells : guaranteed when not in violation with gap, trailer and leader time. • performance dependence on load: full load required • maximum allowable not transmitted cells in a row: estimate 10 (EDFA burst mode violation) • OFN length 10 km tested, 20 km calculated • Splitting ratio of last group of ONUs 1:8 tested 1:16 untested • Number of wavelength 8 provisioned
R522/D523 Public
p.72/90
30/04/03
4.10 Conclusions and Recommendations from the optical lab trial
4.10.1 Conclusions • The optical layer for WDM PON with packet switching has been realized and is promising for future
capacity switched access networks. • Error free operation has been observed with 2 SOAs and 1 EDFA providing gain and noise. • The performance of the system is limited by the properties of the TIA of the receiver • An AC-coupled BMR with asynchronous clock synchronization has been demonstrated to be a good
alternative to classical BMR (with peak power detection and bit-slot synchronization) Synchronization of received packets takes place on a word scale only in the ASIC/FPGA. Timing and ranging however can still be performed on a bit resolution or half a bit if the MC RZ coding is utilized.
• Reflective ONUs will not perform in lambda/packet switched PONs accept perhaps for monolithically integrated SOA-Modulator. It has been demonstrated that the cause of this lies in the gain saturation of the SOA. Proper adaptation of the SOA requires different SOAs for different ONUs in the network.
• Future wavelength supporting ONUs should be equipped with tunable laser sources. The wavelengths of these sources are allowed to be controlled slowly.
• The use of EDFAs in packet switched PON increases dynamic range provided full system load and no missing packets by about 2 dB. This is only valid if the system performance is not limited by ASE noise.
• Cross talk penalties as well as dispersion penalties could not be observed. • SOA-array module decreases power budget and as such dynamic range of SOA due to low saturation
output power. • Manchester line-coding minimizes the impact of pattern effect on the performance of the system and
makes clock recovery and data recovery less difficult to accomplish. • Boundary conditions that set the performance of this optical layer have been determined. This allows for
future improvement.
4.10.2 Recommendations The following recommendations for future research regarding the optical layer are made. • Improvement of MC-BMR and implementation of interface with FPGA (follow-up). This way a higher
functionality can be tested. This FPGA could also contain part of the collision avoiding MAC protocol including ranging and the implementation of an Operation And Maintenance channel.
• Investigation of different SOAs in ONU and wavelength switch (follow-up). The performance of the SOA in the ONUs as well as in the OLT X-connect is still mediocre. More SOAs must be integrated on chip and put in a smaller package. This raises the problem of heat dissipation (This was not a real issue in the currently implemented SOA array) and the control of the RF switching properties.
• Investigation (technically and economically) of different switching matrixes. Electrical switching rather than optical switching. The use of SOAs in the case of optical switching implies that more fibre pigtails are required than in the case of electrical switching where an equal number of photodiodes are used that have halve the number of pigtails and in addition do not require cooling but do require a burst mode receiver. Because electrical switching can take place in the same ASIC or FPGA as the processing part of the BMR an cheaper and easier MAC can be implemented. This is certainly a topic or further investigation.
R522/D523 Public
p.73/90
30/04/03
5 Overview of the HiperLAN/2 wireless technology results The development of HiperLAN/2 prototype was already in progress by the beginning of the HARMONICS project (May 2000). The initial platform was based on Linux. In particular, the protocol stack would be implemented inside the kernel the through a PCI interface it would be connected to the actual modem. The modem would be based on a four-FPGA board designed by Intracom for this purpose. The protocol stack implemented inside the Linux kernel was expected to provide the technical team with knowledge regarding the particular open source system with all consequent advantages for future developments. In December 2001 a performance problem was detected in the hardware (interface between the Linux and the hardware platform) and the particular solution was abandoned. Meanwhile the implementation enhancements as well as DLC and CL have been implemented, tested and validated for HiperLAN/2 using a TDMA emulator that was developed by Intracom and which resembles the behavior of HiperLAN/2. Immediately after December 2001, a new ARM-based platform has been adopted. In this new platform the protocol stack is implemented in Vxworks and incorporated in the ARM processor. The baseband modem is implemented in FGPAs (Logic and Core modules of the ARM platform).
Figure 5-1: Prototype Implementation.
In Figure 5-1 you can see the MT as it was set up for the HARMONICS review. The modem was already in the FPGAs whereas the software regarding the protocol stack was downloaded through the appropriate adapters. The implementation process for this prototype was the source of significant knowledge for Intracom. It was a new platform and since there was no prior experience, certain delays were experienced. On the other hand, the problems that were solved proved a source of valuable knowledge and experience. In particular, regarding the Design Process and Design Flow, the need to apply RMM rules (standard/common design rules) from the early design stages was made obvious, e.g. specify clock domains, global reset signal and interfacing signals. Another lesson learned was the need to automate the “place and route” processes (processes to map the VHDL code to the particular FGPA that will be used) and have significant time gain during the debugging period. The verification process has also been changed. The outcome refers to the necessity to run many more and more complex tests case scenarios in RTL (Register Transfer Level) environment. Experience has shown that even long tests (hundreds of frames) cannot provide any confirmation of the validation of the overall system. As a result, in case there are problems that need to be solved, these remain unnoticed and appear in later steps that both tracking and correctioning are difficult. Another issue is that a preliminary integration between software (protocol stack) and hardware should be done in an early stage. This allows people that work independently sometimes to understand clearer the
R522/D523 Public
p.74/90
30/04/03
dependencies of the work and the system in which their work will be integrated and consequently, they proceed in a more realistic way. Furthermore, an integration at early stages allows the engineers to detect any performance problems and the whole interfacing environment.
Figure 5-2: ARM Motherboard. Core and Logic Modules contain the BB and the Arm
processor the HiperLAN/2 protocol stack.
The effect of the above was the delays that finally appeared to the implementation. An example problem, that delayed a lot the overall process was a hardware misbehavior when the integration with the protocol stack had already been started. In order to solve this problem it was required to verify the command memory, the sequence of the commands, the system configuration, the register initialization required per frame and overflow problems of the receive and transmit data buffer. Those problems would have been avoided if the above procedures would have been followed. Intracom will use this knowledge for future developments. Regarding the system level design, we needed to consider specs for all blocks of the implementation considering demands and limitations from each block that affect other blocks e.g. limitations arising from the frequency accuracy of the transmitted RF center frequency from the front end affect the digital domain specs for the system clock. A second example is the required arithmetic and timing accuracy for the digital blocks simulated with system level tools like MATLAB needs to match the real hardware specs and performance. Knowledge have been gained also for the RF part. Requirements, especially those arising from the control I/F of the National RF front end, like synthesizer lock time, transmit and receive enable and disable times, signals specific to this chipset, had to be taken into account during the software and digital hardware co-design phase, because they affect timing of the whole system and therefore the system performance. Because information like that is not always available at an early stage of the design we had to design generic programmable blocks like the analog front end I/F.
R522/D523 Public
p.75/90
30/04/03
Figure 5-3: RF front end.
After the delay (and the reasons explained previously) it was possible for Intracom to demonstrate HiperLAN/2 at the final review. The association and connection set-up procedures where demonstrated as well as two applications: ping and ftp.
Figure 5-4: Association and Connection Set-up.
R522/D523 Public
p.76/90
30/04/03
Figure 5-5: ping application.
Figure 5-6: Ftp (part 1).
Figure 5-7: Ftp (part 2).
R522/D523 Public
p.77/90
30/04/03
6 Evaluation of the HARMONICS system elements This chapter gives a short overview of the outcome of all the demonstrated HARMONICS elements with respect to the original revised HARMONICS Objectives. It discusses the results of the Measuring analysis and the Field Trial Demonstration. Finally, it comments possible improvements regarding each system element.
6.1 LNCs
6.1.1 LNCDS
6.1.1.1 Description and goals The main goal of Harmonics was to create an access feeder system that was able to guarantee quality-of-service while also supporting a variety of last mile networks. To support QoS with hard guarantees, the project chose the idea of doing flow admission control by a management framework while supporting a variety of last mile networks raised the need for a generic management framework. To support QoS at layer 3, Differentiated and Integrated Services are used of which DiffServ got the most attention and was the only used QoS technique in the field trial. (IntServ and RSVP was also tested during the lab trial). DiffServ is the end-to-end core technology used at layer 3 and has to support a lot of other technologies at layer 2, ao of last mile technologies. This hierarchy is also mirrored in the management plane where entities based on the same technology and in the same provider domain are called Layer Networks, which are managed by a Layer Network Co-ordinator (LNC). Layer Networks can have a peer-to-peer or a client-server relationship to each other. Typically the DiffServ Layer Networks have a peer-to-peer relationship with each other while other technologies then have a client-server relationship with the DiffServ Layer Network. As different technologies (DiffServ, Optical Feeder Network, Hiperlan/2, VDSL, …) are used within Harmonics, all those Layer Networks should have their own LNC but to make the management framework generic, generic interfaces between the components should be created. To support also different platforms, CORBA is used for the communication between all the management components and to specify the generic interfaces (independent of technology but based on DiffServ terminology which is used end-to-end) in IDL. The complete developed management framework is responsible for the configuration of the different routers (e.g. policing bandwidths), for SLA management of the users and for the flow setup of QoS flows. The advantage of DiffServ is that it is fully compatible with the existing IP technology and only adds QoS without removing functionality. As such, it is assumed that the best effort traffic will always remain the biggest in the Internet while some flows/application will use QoS guarantees. The LNCDS in particular is responsible for configuring the DiffServ routers and for interacting with the users and the network administrators and for contacting LNCDS of other domains for end-to-end flow setup. The LNCDS has also a global view on its own provider domain and knows routes to neighbouring domains and contacts layer 2 LNCs as needed. For use in the field trial, several graphical user interfaces were developed to make it easier for the friendly users to configure the network and to set up QoS flows.
6.1.1.2 Reflections, improvements and further work The developed management framework is able to configure end-to-end flows and to configure the necessary router configurations, although as a prototype. The delivered QoS (objectively analysed with Smartbits equipment or subjectively experienced by friendly users) is better than expected on the PC based routers.
R522/D523 Public
p.78/90
30/04/03
Some shortcoming is e.g. the start up of the management framework, which is still not fully mature and which is very complex to let the right components register themselves at other components. The used in-band signalling (with QoS guarantees) for the set up and tear down of flows works, but is weak because if e.g. a router stops working or so, the management components can not talk to each other anymore. Maybe the choice for out-band management communication could improve the stability. It was also pointed by some users that the flow setup and tear down, although made as simple as possible by a user interface, which listed the provided applications, was complex. Future applications should thus be DiffServ enabled which make them almost transparent useable by the users. This is the old debate between management frameworks whether to support QoS, but to our vision, it is impossible to guarantee QoS without admission control, which is easiest with a management framework.
6.1.2 LNCOFN The LNC for the Optical Feeder Network has 2 tasks: first it has to contact the Resource Manager (RM) which does the MAC configuration and apart from that it has to configure also the OFN part of the Harmonics Edge (table with ONU numbers and accompanying IP numbers) and Leaf router (table with DSCP to OFN QoS class mappings). This component is not very complex and could e.g. be integrated with the RM, which could then carry the name LNCOFN.
6.1.3 LNCHiperLAN/2 The role of LNCHiperLAN/2 is to supervise a HiperLAN/2 network in terms of Differentiated Services. In particular, it is responsible to receive messages from LNCDS and forward them to the AP IPSSCS and vice versa. For the communication with LNCDS a CORBA interface has been implemented whereas for the communication with AP IPSSCS a proprietary userspace-to-kernelspace mechanism has been developed2. In case LNCDS applies a request for resources (RR) but there is no such AP registered to the corresponded LNCHiperLAN/2 an appropriate message is sent back to LNCDS. All other messages are forwarded, as well as the replies concerning them, appropriately. It is important to note that LNCHIPERLAN/2 implements a proprietary mechanism to handle multiple requests in a concurrent way. In addition, it is capable of supporting more than one HiperLAN/2 APs and consequently, more than one HiperLAN/2 networks. It has also limited forwarding functionality concerning the destination AP of the received message.
6.1.4 LNCVDSL The LNCVDSL is responsible for managing the VDSL Last Mile Network (LMN) of the HARMONICS architecture, by accepting requests for new prioritized flows from LNCDS. It is mainly capable to perform bookkeeping of the total available capacity on the VDSL link, to store the amount of allocated premium bandwidth on a per-port basis, while communication with the VDSL platform (Cisco LRE) is achieved via SNMP. LNCVDSL performs flow admission control based on information received from the VDSL platform, including the maximum transmission link rate, established Virtual LANs (VLANs), and the port number at which each end host is connected. In addition, it performs basic fault management, through traps received from LRE. Upon receiving a “link down” trap, it releases all connections created for the particular port. During the implementation phase, a switch-hub was used for testing purposes, from the same vendor and with almost the same MIBs as LRE. This enabled a smooth transition from the development environment to the Lab trial, where the functionality of the LNCVDSL was tested, as well as, the interoperability with the other software modules of the HARMONICS control plane architecture. The processing overhead introduced by the LNCVDSL operations and the interactions with the VDSL platform did not affect the overall performance. In the future, LNCVDSL functionality could be adapted to a more open VDSL platform, compared to LRE. In that case, it should be able to answer resource requests from the LNCDS based on the actual state of the hardware and available resources, by having access to the network/resource element management system. The VDSL link rates depend on the quality of the copper loop. This means that LNCVDSL must be able to handle: • A range of link rates for each port, according to the Service Level Agreement (SLA) between network
operator and customer.
2 Note that the enhanced HiperLAN/2 protocol stack is implemented inside the Linux Kernel space.
R522/D523 Public
p.79/90
30/04/03
• Dynamic changes in the link rates, due to changing (noise) conditions in the network. • In addition to bandwidth, other QoS parameters like jitter and delay of the VDSL link could be taken
into account. Hence, LNCVDSL could support: • Collection and processing of the link characteristics (BER, HEC errors, CRC corrected bytes and SNR),
through the VDSL Operating Channel (VOC). • Optimisation of the network resources by taking advantage of the separate paths (fast and interleaved)
supported by the VDSL transport.
6.2 Edge and Leaf Routers
6.2.1 Description and goals Part of the project had as goal the adaptation and fine-tuning of Linux PC based routers for integration with the Optical Feeder Network and for Quality-of-Service prioritization of traffic. PC based routers were chosen because they are very easy to adapt regarding functionality (all software is open source), because there were no DiffServ enabled routers available at the start of the project and because they are cheap. Differentiated Services (DiffServ) for the core and edge networks were chosen while the older Integrated Services (IntServ) based on RSVP is also supported for the edge networks. On top of these DiffServ routers management interfaces had to be foreseen which could be used to configure the routers for the DiffServ tasks. DiffServ Leaf routers, which are situated close to the users, are able to mark, meter and police traffic on a per-flow base while edge routers meter and police traffic based on per-DiffServ-Code Point (DSCP) base. Core routers only forward traffic and give QoS on a DSCP base. For the OFN integration the Harmonics Leaf and Harmonics Edge router are connected through gigabit Ethernet to resp. a ONU and an ER. The Harmonics Leaf router should mark the upstream packets in the Ethernet header with the needed QoS (static or dynamic OFN class) so that the ONUs know-how to queue the packets. The Harmonics edge router should mark the Ethernet header of the downstream packets with the destination ONU so that the OLT knows where to send the packets. For the PC based routers dual processor systems (2x 1.266 GHz CPU) with gigabit and fast Ethernet network cards were used running Linux and the MIT Click modular router package as router software. The needed adaptations for integration with the OFN were done for IPv4 and IPv6 and could be seamless integrated with the OFN. The routers got CORBA management interfaces based on the DiffServ MIB which was converted from SNMP to an IDL interface (following the JIDM standard) and as such all needed QoS things could be configured in the routers in a standard way. The performance of the PC based routers was okay and usable for lab and field trial. The throughput was approx. 1.4 Gbit/s based on big packets where the downstream and upstream data rate of a wavelength channel was 950 Mbit/s and 537.5 Mbit/s. QoS could be clearly demonstrated and analysed on the test bed as can be seen also in this document. The DiffServ functionality was satisfactory for use within the test bed, although based on only 3 classes (Expedited Forwarding EF, Assured Forwarding AF11 and best effort) and a priority-scheduling scheme that worked very good and made some clear results possible.
6.2.2 Improvements and further work During the field trial measurements showed that remarking of streams (e.g. a video stream of 10 Mbit/s for which only 8 Mbit/s is reserved) caused packet reordering which was no good for some applications, e.g. the Video-on-demand application that made the video un-viewable. There should be reserved always enough bandwidth. More complex DiffServ router configurations for QoS prioritization could be researched although it seems that the used configuration is already very useful and that more complexity could be a big problem.
R522/D523 Public
p.80/90
30/04/03
6.3 Resource Manager (RM) Evaluation The RM performs the flow admission control of the HARMONICS OFN (Optical Feeder Network) for the prioritized flows received from the LNC (Layer Network Controller). When the RM accepts a new prioritized flow, it communicates the allocation of the needed resources to the MAC system, which in turn, performs the resource allocation and the scheduling in the underlying optical network. In this section we show the evaluation of the bandwidth calculation and reservation.
6.3.1 Bandwidth Calculation The RM calculates the bandwidth that should be reserved according to the available resources and the DSCP value of the connections that arrive. The two possible prioritized connections from the LNC are AF and EF connections. The calculated bandwidth for the two different connection types is depicted in Figure 6-1.
Figure 6-1: RM Bandwidth Calculation for EF and AF Connections
It can be seen that for small values of reserved bandwidth, there is no differentiation between AF and EF with respect to the RM behaviour. However, the RM will handle EF and AF connections differently when the total reserved static bandwidth reaches a certain threshold, referred to as RESERVED_STATIC_MAR_1. The RM gives bandwidth reservation priority to the EF connection requests. For AF connections, the RM will choose to assign less than the requested bandwidth, after RESERVED_STATIC_MAR_1 has been reached. The RM will keep assigning bandwidth as new connections arrive, until the maximum allowed bandwidth for statically reserved connections has been reached. After that, new incoming connections will be dropped. The approach the RM uses for AF connections is a stepped approach, where connections arriving before RESERVED_STATIC_MAR_1 are given all requested bandwidth, while connections after RESERVED_STATIC_MAR_1 are given bandwidth according to the value of the statically reserved bandwidth at the time instant the connection arrives. Figure 6-2 shows the percentage of the requested bandwidth that is granted for the different states of the RM, for AF connections.
R522/D523 Public
p.81/90
30/04/03
0
0.2
0.4
0.6
0.8
1
1.2
0 10 20 30 40
Req. Bandwidth (kbpsx0.001)
Req
/Res
erve
d B
andw
idth
Figure 6-2: Requested/Assigned Bandwidth
For EF connections, the RM will either reserve bandwidth equal to the requested value or, if unable to do so, it will drop the connection request. In principle, EF connections will be dropped when all available static bandwidth has already been reserved.
6.3.2 Bandwidth Reservation The algorithm that the RM uses in order to reserve the bandwidth that should be assigned to each connection is as follows: • The RM calculates the total number of granules that should be reserved at the MAC. • It then rounds up this number to the closest integer. This integer corresponds to the amount of granules
that will be requested to the MAC layer. When tearing down a connection, the RM follows a somewhat similar approach, by calculating the number of granules that should remain reserved at the MAC layer, after removing the resources associated with the connection that is to be torn down.
0
10
20
30
Exc
ess
Ban
dwid
th
(kbp
s)
Figure 6-3: Excess Bandwidth for connection requests
The necessity of this algorithm comes from the requirement that an integer number of granules should be requested to the MAC. As a consequence, the requested bandwidth might differ from the actual calculated. Figure 6-3 shows the bandwidth difference, after consecutive connection requests. Notice that Figure 6-3 has no semantic value, but is a simple demonstration of the values the excess bandwidth has. In any case, the excess bandwidth will always be less than FRACTION.
R522/D523 Public
p.82/90
30/04/03
The Excess bandwidth that might be generated is not wasted. The RM keeps track of the excess bandwidth. If a connection request results in bandwidth that is less than the current value of the excess bandwidth, the connection is automatically accepted. The MAC needs not be contacted in this case, as necessary resources have already been reserved at the MAC layer. The result is better performance for connections with small bandwidth values. Figure 6-4 shows the rate the MAC needs to be contacted for connections that are randomly generated, with a bandwidth that follows normal distribution (with standard deviation equal to 20% of the mean value). The performance improvement is evident for connections with small bandwidth.
00.10.20.30.40.50.60.70.80.9
1
5 10 15 20 25 30 35 40 45 50 55 60 65
Mean Bandw idth (kbps)
Nor
mal
ized
MA
C c
onta
ct r
ate
Figure 6-4: Normalized MAC Contact Rate
6.3.3 RM Testing Field trials have proved that the RM behaves as expected.
6.4 Optical Feeder Network The optical feeder network that was designed in HARMONICS has been demonstrated in a reduced form in the field trial in Berlin. In chapter 4, the properties of the physical layer were presented showing the optical cross connect, the optical network units and burst mode receivers. For the demonstration of the dynamic properties of the designed OFN under real traffic loads, the emulator for the OFN was developed, characterised and tested in the lab trial. Despite the limitations of an emulation concerning the physical transport of optical packets, it is believed that the emulator has been a very useful tool to proof the concept of the HARMONICS optical feeder network, including the following features:
• A MAC protocol for dynamically switching of optical packets • Aggregation and distribution of Gigabit traffic flows • Up and Downstream transport of IP traffic • Static allocation of Expedited Forwarded traffic • Dynamic allocation of Best Effort traffic • Control Plane Interfaces to Resource Managers • Gigabit Ethernet Data Plane interfaces to Edge and Leaf Routers
Moreover, the OFN emulation has been able to identify issues that would have been shown by the real system. As expected, the time resolution of the emulator (~O[10 µsec]) was good enough to be neglected by the measured end-to-end delays. In addition, the limitations of the emulation platform were similar to that of the Edge and Leaf Routers, so that the throughput was not significantly reduced. The performance effects that stood out, and which could be attributed to the OFN emulator were without exception the result of the OFN design itself. As such, the emulation of the MAC protocol in the HARMONICS demonstrator has shown some interesting characteristics of the Optical Feeder Network that are significant for the evaluation of the system design.
R522/D523 Public
p.83/90
30/04/03
6.4.1 Static Bandwidth Allocation One of the design choices of the HARMONICS MAC protocol was to use static allocations, medium access independent of the momentary load, for traffic such as Expedited Forwarded IP packets, with a high QoS. The reason for this choice was that PON systems that are designed with dynamic allocations, where the momentary load of the client initiates medium access through polling, suffer greatly from performance degradation at higher system load during bursts. Static allocation ensures deterministic resource sharing, and thus predictable delays. Nevertheless, the field trial has shown that enforcing static access has some drawbacks for specific services. By choosing optical packets that are larger than 64 bytes, an optimal granularity was ensured while keeping delays for real time protocols low. Obviously, delays will incur that correspond to the time between packets, which depend on the allocated bandwidth. The presence of multiple receivers at the OLT reduces the effective bandwidth per receiver, increasing the delay even further. This means that sufficient bandwidth must be allocated when delay times are important for a specific service. When only a voice call is set-up over a single ONU, this means that probably higher bandwidths must be allocated than that required (~64 kbps). The field trial showed that dynamically allocated traffic (associated with low QoS Best Effort traffic) suffers in these cases from much less delay than static allocations. This may seem contradictive to the design goals, but one should keep in mind that this is only the case for low system utilisation. For higher loads, especially when traffic is bursty, dynamic allocations will result in much longer delays, which are also by nature unpredictable. Another effect related to this allocation mechanism was observed for streaming video. Here it was apparent that video applications tend to queue their data in order to transmit larger (1500 byte) packets rather than small packets. This may be caused by strategies to optimise transport through LANs, or otherwise due to the fact that video frames are fully assembled before compression fully. Historically, communication networks have adapted their packet sizes to the interaction delay requirements especially for voice. For future videophone and conferencing services, it may be crucial that their compression and encoding algorithms adopt the characteristics of these networks.
6.4.2 Optical Packet Switching In order to maximise the multiplexing gain, the HARMONICS optical feeder network applies fast packet switching. By balancing the load of the optical network to a range of optical transceivers at the OLT on a per packet basis, the blocking probability is reduced to a minimum, resulting in less queuing and delays. By randomly distributing incoming packets among queues associated with a specific OLT receiver, as mentioned in previous section, a reduction of the effective bandwidth per queue is observed. This does not limit the traffic load, but does influence the transmission delay across the OFN. There is one important observation to be made here. A system comprising of N independent PON systems, with single queues at the ONUs would impose delays, which are a factor N lower than the HARMONICS OFN with N receivers. This delay increase is however caused by the synchronisation of the offered load. When these first mentioned N conventional PONs are to be connected to the same (Gigabit) interface, an aggregation function will also require queuing and delaying of packets. In other words: Synchronisation of large amounts of traffic does improve the multiplexing gain but will also affect the delay. Another side effect is that the order of packets of a single flow may be disturbed as demonstrated in the field trial. This effect was considered during the design of the HARMONICS system, but at that time recommendations did not demand sequence conservation, which would leave it to the applications to resolve. As it now appears, these applications indeed cope with out of sequence packets, but this involves retransmissions and results in significant performance degradation. This problem cannot be solved by proper allocation of bandwidth and must be solved fundamentally in the MAC by acknowledging flow entities. One option for this is by tagging incoming packets at the ONU, and after reassembly, reordering of the packet sequence on a per ONU basis. This would significantly extend the functionality of the OLT, but would certainly preserve the dynamic characteristics of the MAC protocol.
6.4.3 Improvements and Recommendations As discussed above, the characteristics of the HARMONICS OFN in a real system comply with the designs. For successful deployment however, packet order must be maintained and for this the OLT designs must be updated. The field trial has also demonstrated that the features of the OFN may cause high delays especially for low bandwidth allocations. In order to avoid this there are several options possible. One option, that is already available in the designs, is to limit the aggregation scope by assigning ONUs to a reduced set of OLT
R522/D523 Public
p.84/90
30/04/03
receivers. This requires specific administration by the resource manager to balance the system load, which is no longer dynamic. Another option is to introduce a special QoS class for low bandwidth/low latency/high priority services that could be dynamically allocated. Again, dynamically allocated traffic may suffer from high momentary system loads but proper flow admission control and sufficient buffering through reserved Best Effort capacity can avoid this. This additional service class would involve a minor extension of the OLT and ONU designs. Furthermore, it should be noted that there is always bandwidth reserved for management information from the ONUs to the OLT. This allocation could easily include one voice channel (64kbps).
6.5 HiperLAN/2 One of the adopted Last Mile Network solutions in HARMONICS is HiperLAN/2; the other being VDSL. The aim of the effort concerning HiperLAN/2 was the support of Differentiated Services. For this reason the standard HiperLAN/2 protocol stack (defined by ETSI) needed to be enhanced, which was one of the objectives within the HARMONICS project. The particular enhancements involved both planes of the HiperLAN/2 protocol stack: the Control Plane as well as the User Plane for the SSCS (Service Specific Convergence Sublayer) (called IPSSCS under the HARMONICS framework) and the DLC (Data Link Control). Within the project the requirements, the specification as well as all necessary functionality was specified regarding the modules that needed to be developed for the successful support of Differentiated Services under HiperLAN/2. Two publications [2, 3] have supported the claims that the particular approach is a concrete way to support Differentiated Services in a WLAN and that the proposed mechanism can equally be used for multitudes of access networks (such as UMTS). The implementation was based on a Linux Kernel platform. Performance and complexity results that support the claims that the implemented mechanism efficiently supports Differentiated Services can be found in the present document. Next, for both the Control Plane and the User Plane a description of the achievements, towards the goal (support of Differentiated Service in HiperLAN/2) is presented. Note that all the presented functionality is implemented inside the Linux Kernel space.
6.5.1 Control Plane In order to support Differentiated Service a request of resources (RR) should be handled by the enhanced HiperLAN/2 system. HiperLAN/2 should be able to receive such a request, to interpret it, and to reply accordingly. In particular, if the system has enough resource to satisfy the RR then the reply is positive whereas in the case of lack of resources the reply is negative. Furthermore, the HiperLAN/2 system should be able to receive requests for the release of already reserved resources or requests for modifications of already reserved resources. Messages that correspond to cases were a Mobile Terminal (MT) is not present inside the network of a particular Access Point (AP) or that a particular host is not present in the network (outside the AP’s network). In order to achieve the aforementioned functionality the standard SSCS as well as the standard DLC of HiperLAN/2 were enhanced and the particular features and functionalities added are described next.
6.5.1.1 IPSSCS (a) Registration of the MT (MAC ID, DLCC ID, IP Address) at the AP IPSSCS using specific messages; (b) a mechanism that operates in a concurrent mode is developed, that is responsible for the communication
with LNCHiperLAN/2. This mechanism is responsible to receive/send messages form/to LNCHiperLAN/2; (c) a mechanism to handle RRs from the user application at the MT’s side; (d) a proprietary queue of messages was developed for the storage of messages while other messages are
served. This helps to safely serve messages that correspond to “critical regions” (for example access to the same table entry);
(e) a mechanism was developed for the appropriate decoding and interpretation of the received messages; (f) update of tables that concern the reserved resources as well as the registered MTs inside the particular
AP’s network; (g) reply appropriately when the MT (for which a RR is applied for) is not present inside AP’s network; (h) request the DLC whether the requested resources are possible to be satisfied. Reply appropriately; (i) reply appropriately in the case when a message originates from a MT; (j) create new messages at the MT side and forward them peer-to-peer to AP IPSSCS through a dedicated
DLC connection.
R522/D523 Public
p.85/90
30/04/03
6.5.1.2 DLC (a) A mechanism to receive RRs from IPSSCS and forward them to the Admission Control module; (b) forward the replies of the Admission Control Entity to IPSSCS; (c) a table for the maintenance of the information regarding the already reserved resources; (d) an Admission Control module that accepts/rejects RRs. The algorithm that the Admission Control is
based on is bookkeeping of the already reserved resources.
6.5.2 User Plane The enhancements in the User Plane, even though less than those required for the Control Plane, are the most important since they allow the exploitation of the particular information provided by the Control Plane, in order to successfully support Differentiated Services.
6.5.2.1 IPSSCS The enhancements done at the IPSSCS include: • New table storing the MTs that are registered inside the particular AP’s range. • New table where the data sessions (source and destination IP addresses, source and destination port
numbers and protocol number) for which there exist reserved resources, are mapped to certain priority queues.
• Procedure that checks each incoming IP datagram and forwards the priority to the DLC. • Forwarding of IP datagrams (for which there exist no reserved resources) to the Best Effort queue. • Forwarding of IPSSCS specific messages through a dedicated connection. • Procedure to check whether the packets assembled by the DLC correspond to the peer-to-peer messages
exchanged between IPSSCS at the AP side and at the MT side.
6.5.2.2 DLC The enhancements done at the DLC include: • Implementation of four different queues with different priorities and characteristics. • The highest priority is dedicated for control information and the error control mechanism is enabled. • The second highest priority queue is dedicated to delay sensitive traffic (and thus mapped to the EF
traffic class) and the error control mechanism is disabled. • The third priority queue is dedicated to error sensitive traffic (and thus mapped to the AF traffic class)
and the error control mechanism is enabled. • The fourth (and lowest) priority queue is dedicated to Best Effort traffic (and thus mapped to the BE
traffic class) and the error control mechanism is enabled. • Capability of checking the packets received from CPCS in order to be forwarded to the appropriate
queue. • Capability of forwarding the packets received from the wireless medium to CPCS appropriately3.
6.5.3 Conclusions The aim of supporting Differentiated Services by enhancing the standard protocol stack of HiperLAN/2 is achieved as it is presented at this chapter. The work within the HARMONICS project included a requirements and specification phase. Afterwards, the specified system architecture was developed inside the Linux Kernel space. The integration, as well as the refinement process of the particular implementation was followed successfully. Allowing the system to operate for days the stability of the control plane we were able to test the stability of the system. No system crash was reported. Another important element for the fine operation of the described enhanced protocol stack is LNCHiperLAN/2, which is presented inside another chapter of this document. The particular enhancements have been shown not to be computational power consuming (which is a valuable resource since the implementation is tightly close to the CPU of the system). Consequently, this mechanism can be used along with any scheduling policy scheme, without any restriction. The adopted scheduling policy (four priorities) is a policy compatible with the idea behind the Differentiated Services 3 In order to distinguish among packets which are control packets for the particular peer-to-peer communication between AP IPSSCS and MT IPSSCS.
R522/D523 Public
p.86/90
30/04/03
model (different treatment of flows in a per hop basis) but it also allows the efficient exchange of peer-to-peer control messages. Performance results have supported the claims that the particular scheduling policy can provide error critical applications with a high throughput environment whereas as error critical applications are also supported even for high values of the error rate. In any case, improved scheduling policies can be used at will and the flexibility of the mechanism/enhancements allows that without any major modifications. It should be noted that considering the problem of the implementation of the actual prototype, a TDMA emulator of HiperLAN/2 was used in order to test/validate the modifications required in this project. By the time the prototype was ready the integration took place and a demo scenario with ftp and ping applications was presented in Berlin for the review purposes.
6.6 Ethernet over VDSL The goal of the VDSL Last Mile Network is to provide an inexpensive connection between the user locations and the optical part of the network. During the project ATM and Ethernet solutions were discussed. Ethernet is very well understood, suitable for an efficiently IP transport, simplifies the leaf router design, and it offers a low cost potential. Additionally, there are standardisation activities in IEEE group Ethernet in the Fist Mile. For these reasons the Ethernet protocol (not ATM) was chosen for the VDSL part. The VDSL technology allows eliminating the Ethernet disadvantage of the limited distance for copper wired transmission. The HARMONICS Field trail integrates the commercial indoor Ethernet over VDSL networking solution from Cisco called Long-Reach Ethernet (LRE) as described in section 1. To evaluate the QoS feasibility of the EoVDSL Last Mile solution measurement analyses of the LRE system have been carried out. The essential results are summarised below. Throughput The used EoVDSL system is not able to support both HARMONICS bandwidth services. Due to the bandwidth limitation of max 15.62 Mbit/s – 19.84 Mbit/s this EoVDSL system with its capability only provides the Basic Service with a sum bitrate of 12.5/12.5 Mbit/s. But the LRE solutions based on the 10BaseS chip set from Infineon Technologies that supports a bit rate of up to 25 Mbit/s in a special implementation. Table 6-1 shows the LRE Throughput vs. Frame Size of an One-to-One set-up.
Table 6-1: EoVDSL Throughput One-to-One (% of 100Mbit/s)
Latency (Delay) Table 6-2 lists some meaningful measured Latency values of the EoVDSL solution for a link load of 15 Mbit/s and the Frame Sizes 64 Byte and 1518 Byte. The allowed max Latency for Last Mile Networks defined in the Harmonics QoS requirements is 5 ms. The second line of the table shows the Latency of an One-to-One set-up with an uncritical link distance of 1 meter. One can see that the measured Latency is clearly under the allowed max value. The same applies also to an One-to-One set-up with a link distance of 200 m shown in line 3. 200-meter link distance causes a link delay within the nano-second sphere that has no influence on the result.
Table 6-2: Latency of the EoVDSL Last Mile
No. Description Max Latency Downstream
(64 Byte – 1518 Byte)
Max Latency Upstream (64 Byte – 1518 Byte)
1. Required Last-mile max Latency < 5 ms < 5 ms 2. EoVDSL One-to-One, 15 Mbit/s load,
link distance: 1 m, Burst Size: 1 0.23 ms – 1.23 ms 0.21 ms – 1.12 ms
3. EoVDSL One-to-One, 15 Mbit/s load, link distance: 200 m, Burst Size: 1 0.25 ms – 1.23 ms 0.21 ms – 1.12 ms
R522/D523 Public
p.87/90
30/04/03
Jitter (Delay variation) The measured Jitter values of the EoVDSL solution shown in Table 2-6 for an One-to-One scenario fall clearly under the required Jitter restriction of 2 ms that has been defined for Last Mile Networks connected to the HARMONICS platform. Frame Loss The Frame Loss was measured based on the Traditional performance testing (see paragraph 2.1.) that determines the number of lost frames by a network device under constant load during a test duration of 60 seconds at least for different Frame sizes. The system reached a Frame Loss rate of zero for all defined Frame Sizes. Packet sequence The ability of the network to deliver packets in proper sequence is an additional QoS parameter. The EoVDSL solution fulfilled the Packet sequence requirements up to a Link load of 16 Mbit/s (see Table 2-7). So the Packet sequence behaviour of EoVDSL system allows the HARMONICS Basic Service with a sum bitrate of 12.5/12.5 Mbit/s. Because of the measuring analysis and the Friendly user experience of the Field Trial Demonstration, one can say that the EoVDSL solution fulfilled the Harmonics QoS requirements essentially. During the Demonstration, the EoVDSL system ran reliably and stably. Due to the simple CPN set-up of the Field trial (there was only one terminal per EoVDSL connection) the Friendly users did not miss any performance. There was no problem to implement the commercial EoVDSL solution from Cisco into the HARMONICS Network level emulation. But integration into the HARMONICS Field Trial Management using the Layer Network Coordinator LNCVDSL was not successfully. The LNCVDSL should coordinate and set-up reservations within the EoVDSL Last Mile Network. In the HARMONICS SLA the max data rate was fixed to 12.5 Mbit/s for each EoVDSL link, so it was not possible that an user orders more network resources as supported by the EoVDSL solution. But it could be a problem if the total data rate of the LMN climbs over the max capacity of the EoVDSL uplink interface. In the Field Trial only four EoVDSL CPE devices were used which generate a max data traffic of about 60 Mbit/s in a worst case. So during the Field Trial, traffic prioritization was not needed within the EoVDSL LMN because the uplink interface had a capacity of 100 Mbit/s. Of course, in a commercial implementation of the HARMONICS concept a traffic prioritization is very imported also within the LMNs. Such an implementation probably integrates ONU, Leaf Router and EoVDSL DSLAM in one box with a full management integration, High speed Layer-3 switching, Traffic priority using DiffServ, outdoor suitability for FTTCab scenarios, and Low powering concepts. This box could be a modular chassis-based device with small dimensions that allows a migration with gradual system upgrades. Finally, the Demonstration of the EoVDSL system shows that a system combining VDSL and packet switching technology could be able to provide a multimedia Last Mile Network.
6.7 Optical Ethernet The Optical Ethernet (OE) links consist of MICROSENS’ media converters and small manageable Ethernet switch as CPE. The system supports traffic priority using DiffServ or IEEE-802.3 Q/p but in Field Trial the traffic priority feasibility was not integrated into the HARMONICS management. Throughput OE reached a max Throughput of 100 Mbit/s for all defined Frame Sizes and both traffic directions. OE is an optimal LMN solution for the HARMONICS concept. It offers the user a max bandwidth of 100 Mbit/s that allows providing both HARMONICS bandwidth services with a max data rate of 25Mbit/s/25Mbit/s. Latency (Delay) Some meaningful measured Latency values of the OE solution are listed in Table 6-3 for the Link loads 30Mbit/s and 100Mbit/s and the Frame Sizes 64 Byte and 1518 Byte. One can see that the Latency is clearly under the allowed max value for both traffic directions. Also there a no relation between Latency and Link load because the system causes the same Latency for a Link load of 30% and 100%.
R522/D523 Public
p.88/90
30/04/03
Table 6-3: Latency of the Optical Ethernet Last Mile solution
No. Description Max Latency Downstream (64 Byte – 1518 Byte)
Jitter (Delay variation) Table 2-15 lists some Jitter values of the OE solution for a Link load of 30Mbit/s on the one hand and 100Mbit/s on the other hand. The system reaches a avg. Jitter of 0.1 µs for a Frame Size of 218 Byte, which fall clearly under the required restriction of 2 ms for HARMONICS Last Mile Networks. Frame Loss and Packet sequence Table 2-16 shows the Frame Loss of the OE solution versus Frame Size for both traffic directions, Down- and Upstream. The Frame Loss was tested for a link load from 10% to 100% in steps of 10%. The system reached a Frame Loss rate of zero for all defined Frame Sizes. Parallel to the determination of the Frame Loss also the Packet sequence of the OE solution was measured. There was no Out Of Sequence Frame for all defined Frame Sizes and different Link load steps. OE seems to be an optimal LMN solution for the HARMONICS concept. It allows providing both HARMONICS bandwidth services with a max data rate of 25Mbit/s/25Mbit/s but in addition, it offers the users a theoretical bandwidth upgrade of up to 100 Mbit/s. During the measuring analysis, the system reached excellent QoS performance values and fulfilled the HARMONICS LMN requirements completely. During the Field Trial Demonstration, the OE solution worked reliably and stably. In the HARMONICS SLA a max data rate of 25 Mbit/s was fixed for the OE link, so that the quality of the offered services portfolio only depended on the terminal PC performance essentially. In the Field Trial, there was a problem with the interoperability between OE media converter and Leaf Router, which required an additional adaptation using an Ethernet switch. For the Field Trial set-up an integration of the OE system into the HARMONICS Field Trial Resource Management was not necessary because the OE-CPE device was connected to the Leaf Router without any traffic aggregation levels. For the case of traffic aggregation in the LMN Traffic Priority and Resource Management also will be needed for the OE solution. There are two possibilities for a commercial implementation of OE into the HARMONICS concept. On the one hand, the interfaces of the Leaf Router can be extended by optical transceivers, which are able to bridge the distances of the LMN in a dedicated PtP architecture that corresponds to an integration of the Field Trial OE media converter into the Leaf Router. On the other hand, the Leaf Router can be connected to one or more Optical Aggregation Switches, which have to be integrated into the HARMONICS Resource Management to provide end-to-end QoS. Today's Optical-Switched-Ethernet vendors offer a large product portfolio of Carrier-Class solutions, which can be integrated into the HARMONICS concept.
6.8 Ethernet over Polymer Optical Fibre Polymer Optical Fibre (POF) offers cost advantages by deploying a large core diameter (about 1 mm) that considerably eases coupling and splicing and simplifies the installation in subscriber locations. The goal of the HARMONICS POF solution is to provide an inexpensive in-house network to terminate the Last Mile network. The measuring analysis of the stand-alone POF system resulted in good performance values. But the interoperability behaviour of POF media converters is not satisfactory. In cooperation with other Ethernet based techniques, e.g. PC network cards or switches, the POF system did not work reliably and stable. A future EoPOF in-house system must support full compatibility to the Ethernet standard (IEEE 802.3). It has to be embedded into the HARMONICS resource management to provide end-to-end QoS.
R522/D523 Public
p.89/90
30/04/03
7 Conclusions
7.1 The Optical Feeder Network Despite the reduced scope of the system demonstration, it was possible to prove the concept of dynamic optical packet switching in a WDM PON as proposed by HARMONICS. In a laboratory trial, the physical layer of the Optical Feeder Network was tested through a key subset of a full-fletched system including OLT, Cross-connect, a protection switch, a local splitting station and two ONUs. It has been demonstrated that AC-coupled Burst Mode Receivers are not only capable of efficiently receiving optical bursts at higher line rates, but it also proved to compensate for saturation effects in the Semiconductor Optical Amplifiers (SOA) switches of the cross-connect. It was shown that certainly with high quality integrated switch arrays, the system would perform well in a full-scale system. The principle of reflective modulation, allowing wavelength independent operation of ONUs in a WDM PON was not entirely successful. The implementation of the ONUs with discrete components suffered from cross-gain modulation, which is a direct result of saturation effects of the SOA applied, combined with loop traversing times in the order of the bit time. It is believed that this problem may be avoided either by using linear optical amplifiers, or by integration of the different components. Solutions that may be applied on a shorter term include reflective optical modulators, which is the most elegant option. In addition, tuneable lasers, which are configured during ONU initialisation, are obviously a viable solution for wavelength independent ONUs.
7.2 Access Technologies
7.2.1 HiperLAN/2 The enhanced HiperLAN/2 protocol stack was implemented and demonstration of resource reservations was possible at early stages. The enhancements were tested over a TDMA emulator that resembles the behavior of HiperLAN/2. Integration of the HiperLAN/2 control plane and the control plane of the rest of the HARMONICS project successfully took place. Due to the fact that the hardware platform (Linux-based) that the HiperLAN/2 prototype was initially based on was changed, and a ARM-based platform was adopted, certain delays were experienced and therefore, the solution of a IEEE 802.11a wireless LAN was adopted in order not to support the field trial. IEEE 802.11a does not incorporate any QoS mechanisms but it resembles the behavior of the wireless medium. For all period of the field trial Intracom’s team was focusing on the actual hardware development. Consequently, experience regarding hardware implementation is the major gain of this task. Intracom will use this experience (as well as the knowledge taken from the successful implementation of the enhancements) in future development processes.
7.2.2 VDSL and other technologies The main goal of HARMONICS feeder system and IP QoS management was to enable convergence of access networks. Therefore various access technologies using the different transmission media like glass fibre, polymer fibre, twisted pair copper and radio have been included in the trials to prove the result. Commercial available products for Optical Switched Ethernet, EoVDSL,, EoPOF, and WLAN have been installed during the field trial to connect the users to the HARMONICS OFN. Measurements of the performance parameters, QoS tests and user service demonstrations have been carried out for each of the technologies. The measuring analyses and the friendly user experience of the Field Trial demonstration, have shown that the last mile networks fulfilled the performance requirements for QoS support. During the trial SLAs were limited to 10 Mbit/s for each user and the total data rate of the connected CPEs could not exceed the capacity limits of the respective last mile networks for priorised data. If the traffic is able to exceed the upstream limit (like in real deployment with fully equipped system), the Last Mile Networks must also be controlled by specific the LNCs to guarantee end-to-end QoS. For instance a commercial HARMONICS system with VDSL drops probably would integrate ONU, Leaf Router and EoVDSL DSLAM in one box controlled by a fully implemented Layer Network Coordinator LNCVDSL.
R522/D523 Public
p.90/90
30/04/03
7.3 The Management Architecture One point has become clear during the project and the field trial on the need of QoS from the network. In the core network, bandwidth over-dimensioning can indeed be a solution, but in the access networks (e.g. the HARMONICS optical access feeder and last mile networks) where the bandwidth is typically limited, QoS with resource reservation is certainly needed to avoid interaction of different traffic. This brings extra complexity in e.g. a network management system and, as discussed earlier, a better match must be found between the service classes and QoS parameters provided by the network and the service requirements of applications. The latter issue covers a scope much larger than the HARMONICS project, and is already one of the most important issues to be solved for broadband access network systems.
7.4 Field trial The Field Trial has proven the feasibility of the HARMONICS hybrid access architecture for carrying high quality IP services. The service management system developed in HARMONICS has also proven to be an essential part of the developed concept in providing the QoS Management. In contrast to networks using only best-effort traffic without priority differentiation or priority on the basis of Per-hop Behaviour, the HARMONICS QoS management allows an end-to-end reservation of the network resources, guaranteeing the throughput and enables low Latency and Jitter values independent of other traffic. The end-to-end QoS guarantees have been demonstrated quantitatively based on the Measurement analysis and on the other hand qualitatively by the experiences from the users taking part in the trial. The field trial has however revealed the unsolved service quality issues between communication networks and the applications that use them.
7.5 Overall conclusions and Outlook As it can be stated in general, the original goal of a dynamically reconfigurable fibre-based feeder network infrastructure, supporting a wide variety of last-mile customer access networks with end-to-end QoS guarantees, was successfully implemented and demonstrated during the project and in the field trial by using a prototype. The HARMONICS concept is able to provide a convergence of different Access Networks shown by the successful interconnection. The field trial showed also where improvements to the future (packet reordering, QoS reservations) could be done. In contrast with the assumptions at the start of the project, when broadband access was expected to gain momentum by the Internet boom, the market has not progressed such that large-scale hybrid aggregation systems such as HARMONICS will be deployed in the near future. Despite the downturn of the market however, most issues that were addressed by the project are still there, and HARMONICS remains valuable research. It has demonstrated that it provides a strong platform for future development that will be required when the market picks up again. Overall, HARMONICS has combined success in the research, development, and management, which has led to a successful field trial. The high level of cooperation among partners is the key factor to the success of the project resulting in delivering the target of the project on time and according to the initial plan. The last three years, HARMONICS has contributed valuable information to all aspects of telecommunication networks, which in no doubt will be required in the near future.
8 References [1] B. Vermeulen, S. Vanhastel, J. Wellen, C. Mas, F. Scholaert, B. Dhoedt, P. Demeester, "A Generic End-to-end Distributed QoS Management Architecture and its application to IP-DiffServ over a WDM Access Feeder Network", NOMS 2002, April 14-19, 2002, Florence, Italy [2] K. Oikonomou, I. Tenidis and I. Stavrakakis, "A Mechanism to Enable Differentiated Services QoS in HIPERLAN/2" , 8th IEEE International Conference on Telecommunications, June 2001, Bucharest, Romania [3] K. Oikonomou, C. Mas, I. Tenidis, "On QoS Management of H/2 Bearer Service for 3G Telecommunication Systems", Eurescom Summit 2001 : 3G Technologies and Applications, November 12-15, 2001, Heidelberg, Germany
