D5.2 Testbed for the system validation - CORDIS · 2017-05-12 · E3NETWORK Deliverable D5.2 Due...

E3NETWORK Deliverable D5.2 Due date: 31 May 2016

FP7 ICT Contract No. 317957 1 December 2012 – 31 May 2016 Page 1 of 51

DELIVERABLE D5.2

Testbed for the system validation

Contract number : 317957

Project acronym : E3NETWORK

Project title : Energy Efficient E-Band Transceiver for Backhaul of the Future Networks

Deliverable number : D5.2

Nature : D - Demonstrator

Dissemination level : PU (Public)

Report date : 30 June 2016

Author(s): Christos Mizikakis, Kostas Chelidonis, Kelly Georgiadou (OTE)

Mario Giovanni Frecassetti, Alberto Bestetti, Giuseppe De Blasio (ALU)

Ainhoa Rezola, Juan F. Sevillano, Igone Vélez (CEIT)

Thomas Schlichter, Kirsten Schuh (FHG)

Partners contributed : OTE, ALU, CEIT, FHG

Contact : Kelly Georgiadou, Telecommunications Engineer, Ph.D.

Hellenic Telecommunications Organization (OTE S.A.),

1 Pelika & Spartis, Maroussi-Athens, 15122 Athens, Greece

Tel: +30-210-6114695, E-mail: [email protected]

The E3NETWORK project was funded by the European Commission under the 7th Framework Programme (FP7) –ICT

Coordinator: CEIT

E3NETWORK

Energy Efficient E-band transceiver for backhaul of the future networks

Ref. Ares(2016)5750657 - 04/10/2016



VERSION CONTROL

Version Date Contributors Sections Affected

1 2016-06-14 CEIT All

2 2016-06-23 CEIT, FHG, ALU

All

3 2016-06-28 OTE All

4 2016-06-29 CEIT, ALU, OTE

All

5 2016-06-29 FHG All

6 2016-06-30 OTE All

7 2016-06-30 FHG Section 3.4.2

8 2016-06-30 ALU Section 4



INDEX

1. INTRODUCTION ···················································································· 9

2. EQUIPMENT VALIDATION TESTS ·························································· 11

2.1 Overview ·································································································· 11 2.1.1. Transmitter – Transmitter power Level ····························································· 12 2.1.2. Transceiver – Spectral mask ········································································· 15 2.1.3. Transceiver - BER as a function of Receiver input Signal Level (RSL) ···················· 22

3. NETWORK VALIDATION TESTS ···························································· 26

3.1 Assessment process ················································································· 26 3.2 Testbed design ························································································· 26 3.3 Testing related to project objectives ···························································· 30

3.3.1. Throughput testing ······················································································ 30 3.3.2. Latency testing ··························································································· 38

3.4 Testing related to network stability······························································ 40 3.4.1. Capability to transport IPTV traffic ··································································· 40 3.4.2. Capability to support different traffic patterns ····················································· 46 3.4.3. Capability to support QoS and prioritization mechanisms ····································· 48

4. CONCLUSIONS ··················································································· 50

5. REFERENCES ···················································································· 51



ACRONYMS AND ABBREVIATIONS

For the purposes of the present document, the following abbreviations apply:

ADC Analogue to Digital Converter BB Baseband BBER Background BER BER Bit Error Rate BNG Broadband Network Gateway CE Conformité Européenne CN Core Network CoS Class of Service CPE Customer Premises Equipment CPU Central Processing Unit CR Complementary Requirement CS Channel Spacing CT Conformance Test CW Continuous Wave Db decibel dBi decibel isotropic dBm decibel-milliwatts dBW decibel watt DFRS Digital Fixed Radio Systems DIA Dedicated Internet Access DoW Description of Work DSCP Differentiated Services Code Point DSL Digital Subscriber Line DSLAM Digital Subscriber Line Access Multiplexer DSO Digital Sampling Oscilloscope DRRS Digital Radio Relay Systems DTU Data Transmission Unit DUT Device Under Test EMC ElectroMagnetic Compatibility EN European Norm ER Essential Requirement ERC European Radiocommunications Committee ETS European Telecommunication Standard ETSI European Telecommunications Standards Institute Ext. Extreme conditions FCS Frame Check Sequence FDD Frequency Division Duplex FP7 7

th Framework Program

FPGA Field Programmable Gate-Array GbE Giga-bit Ethernet GFP Generic Framing Procedure HDL Hardware Description Language HEN Harmonised European Standard HG Home Gateway Hz Hertz ID Identifier IF Intermediate Frequency IGMP Internet Group Management Protocol iMIX Internet Mix IP Internet Protocol IPTV Internet Protocol Television IUT Implementation Under Test LAN Local Area Network LO Local Oscillator



Max. Maximum Min. Minimum MTU Maximum Transmission Unit Nom. Nominal NSG Net System Gain OR Optional requirement P2P Point-to-Point PC Personal Computer PE Provider Edge PPP Point to Point Protocol PPPoE Point to Point Protocol over Ethernet QoS Quality of Service Ref Reference conditions RF Radio Frequency RFC Radio Frequency Channel RSL Received Signal Level RTPC Remote Transmit Power Control R&TTE Radio & Telecommunication Terminal Equipment Rx Receiver SA Spectrum Analyser SD Supplier Declaration SFP+ Enhanced Small Form-Factor Pluggable STB Set Top Box STC Spirent Test Centre TMN Telecommunications Management Network TR Technical Report TR Test Required TTE Telecommunication Terminal Equipment TV Television Tx Transmitter VLAN Virtual Local Area Network WP Working Package WR World Radiocommunications XPIC Cross-Polar Interference Canceller



LIST OF FIGURES AND TABLES Figures Figure 1-1: Simplified block diagram of the overall transceiver prototype ................................................... 9 Figure 1-2: Photo of the overall transceiver demonstrator ........................................................................... 9 Figure 2-1: Transmitter power and tolerance test bench. .......................................................................... 13 Figure 2-2: RF output power from TX PCB vs. channel number................................................................ 14 Figure 2-3: TX-IF spectrum mask test bench ............................................................................................. 16 Figure 2-4: Tx-IF Spectrum mask ............................................................................................................... 17 Figure 2-5: Spectrum mask and Spectral lines at the symbol rate test bench ........................................... 17 Figure 2-6: RX-IF Spectrum mask and Spectral lines at the symbol rate test bench ................................ 19 Figure 2-7: Rx-IF Spectrum mask .............................................................................................................. 20 Figure 2-8: On-Wafer measured TX spectrum ........................................................................................... 21 Figure 2-9: BER as a function of RSL test bench ...................................................................................... 23 Figure 2-10: BER as a function of RSL ...................................................................................................... 24 Figure 2-11: BER as a function of the estimated Es/No ............................................................................. 25 Figure 3-1: Picture of the E3NETWORK demonstrator used for the network test ..................................... 26 Figure 3-2: OTE network topology ............................................................................................................. 27 Figure 3-3: OTE testbed topology with E3NETWORK transceiver. ........................................................... 27 Figure 3-4: Block diagram of the FPGA loop configuration ........................................................................ 28 Figure 3-5: Device under Test using the FPGA loop configuration ............................................................ 28 Figure 3-6: E3Network Device under Test using the base-band loop configuration .................................. 29 Figure 3-7: Traffic results for 100 % bandwidth utilization, MTU 1500 bytes ............................................. 31 Figure 3-8: Stream results for 100 % bandwidth utilization, MTU 1500 bytes ........................................... 31 Figure 3-9: Received versus transmitted data rate for 100 % bandwidth utilization, MTU 1500 bytes ...... 31 Figure 3-10: Traffic results for 85 % bandwidth utilization, MTU 1500 bytes ............................................. 32 Figure 3-11: Received versus transmitted data rate for 85 % bandwidth utilization, MTU 1500 bytes ...... 32 Figure 3-12: Traffic results for 86 % bandwidth utilization, MTU 1500 bytes ............................................. 32 Figure 3-13: Received versus transmitted data rate for 86 % bandwidth utilization, MTU 1500 bytes ...... 33 Figure 3-14: Tx/Rx L1 rates for 86 % bandwidth utilization, MTU 1500 bytes ........................................... 33 Figure 3-15: Stream results for 86 % bandwidth utilization, MTU 1500 bytes ........................................... 33 Figure 3-16: Traffic results for 86 % bandwidth utilization, MTU 1518 bytes ............................................. 33 Figure 3-17: Received versus transmitted data rate for 86 % bandwidth utilization, MTU 1518 bytes ...... 34 Figure 3-18: Tx/Rx L1 rates for 86 % bandwidth utilization, MTU 1518 bytes ........................................... 34 Figure 3-19: Stream results for 86 % bandwidth utilization, MTU 1518 bytes ........................................... 34 Figure 3-20: Traffic results for 4 % bandwidth utilization, MTU 64 bytes ................................................... 34 Figure 3-21: Received versus transmitted data rate for 4 % bandwidth utilization, MTU 64 bytes ............ 35 Figure 3-22: Tx/Rx L1 rates for 4 % bandwidth utilization, MTU 64 bytes ................................................. 35 Figure 3-23: Stream results for 4 % bandwidth utilization, MTU 64 bytes ................................................. 35 Figure 3-24: Traffic results for 84 % bandwidth utilization, MTU 1500 bytes, BB loop .............................. 36 Figure 3-25: Received versus transmitted data rate for 84 % bandwidth utilization, MTU 1500 bytes, BB loop ............................................................................................................................................................. 37 Figure 3-26: Latency for 4 % bandwidth utilization, MTU 128 bytes .......................................................... 38 Figure 3-27: Latency for 86 % bandwidth utilization, MTU 1518 bytes ...................................................... 39 Figure 3-28: Latency for 100% bandwidth utilization, MTU 1500bytes ...................................................... 39 Figure 3-29: Received versus transmitted data rate for 86 % bandwidth utilization, MTU 1518 bytes, 1 VLAN .......................................................................................................................................................... 41 Figure 3-30: Tx/Rx L1 rates for 86 % bandwidth utilization, MTU 1518 bytes, 1 VLAN............................. 41 Figure 3-31: Stream results for 86 % bandwidth utilization, MTU 1518 bytes, 1 VLAN ............................. 41 Figure 3-32: Trace capture for 86 % bandwidth utilization, MTU 1518 bytes, 1 VLAN .............................. 41 Figure 3-33: Received versus transmitted data rate for 86 % bandwidth utilization, MTU 1518 bytes, 2 VLANs ......................................................................................................................................................... 42 Figure 3-34: Trace capture for 86 % bandwidth utilization, MTU 1518 bytes, 2 VLANS ........................... 42 Figure 3-35: Tx/Rx L1 rates for 86 % bandwidth utilization, MTU 1518 bytes, multicast ........................... 42 Figure 3-36: Stream results for 86 % bandwidth utilization, MTU 1518 bytes, multicast ........................... 43 Figure 3-37: Trace capture for 86 % bandwidth utilization, MTU 1518 bytes, multicast ............................ 43



Figure 3-38: Received versus transmitted data rate for 86 % bandwidth utilization, MTU 128, 256, 512, 1024 bytes, multicast .................................................................................................................................. 43 Figure 3-39: Multicast traffic simulating IPTV service ................................................................................ 44 Figure 3-40: Tx/Rx rates for IPTV service simulation ................................................................................. 44 Figure 3-41: Received versus transmitted data rate for IPTV service simulation ...................................... 44 Figure 3-42: Trace capture for IPTV service simulation ............................................................................. 45 Figure 3-43: iMIX traffic .............................................................................................................................. 46 Figure 3-44: Received versus transmitted data rate for iMIX traffic ........................................................... 46 Figure 3-45: Stream results for iMIX traffic ................................................................................................. 47 Figure 3-46: Trace capture for QoS mechanism ........................................................................................ 48

Tables Table 1: Transmitter power level requirements .......................................................................................... 12 Table 2: RF channels and their corresponding centre frequencies ........................................................... 13 Table 3: Transmitter Power Level .............................................................................................................. 13 Table 4: RF Spectrum mask and spectral lines at the symbol rate requirements ...................................... 15 Table 5: BER as a function of RSL requirements ...................................................................................... 22 Table 6: BER as a function of RSL ............................................................................................................. 23 Table 7: Throughput – requirements .......................................................................................................... 30 Table 8: Throughput results........................................................................................................................ 36 Table 9: Latency - requirements ................................................................................................................. 38 Table 10: Latency results ........................................................................................................................... 39



EXECUTIVE SUMMARY WP5 focuses on the definition of the appropriate testbed architecture and test planning in order to constitute a complete demonstrator of the project and validate it in real network conditions. While D5.1 provided a detailed description of the testing and validation procedure of the designed demonstrator, containing a thorough description of both the specification compliance testing and the architecture of the testbeds, this document contains the final measurements of the transceiver integrated in the network, which have been conducted following the testing plan defined in D5.1. It also contains the description of the two testbeds implemented to conduct these tests. The measurements in this document constitute the final test and validation of the E3Network transceiver. In addition, it provides a comparison with anticipated performances from the system specification, which demonstrates that a commercial system is feasible following the E3NETWORK approach, fulfilling the market requirements for the identified used case and the forthcoming normative that an equipment has to meet to be put on the market. Normative considered includes the new European Directive 1999/5/EC called RED as well.



1. INTRODUCTION

The prototype built in WP4, along with deliverable D5.1 was used in order to build the testbed of WP5. This constituted the demonstrator of the project, which was connected to the network in order to perform the final test and validation. Figure 1-1 shows a block diagram of the transceiver prototype used for these tests. We also indicate in the block diagram how the prototype is connected to the network. Figure 1-2 shows a picture of this prototype.

Figure 1-1: Simplified block diagram of the overall transceiver prototype

Figure 1-2: Photo of the overall transceiver demonstrator



Different testbeds have been considered for the validation of the prototype. Firstly, a subset of the most significant R&TTE compliance tests has been performed for equipment validation. These tests have been performed at CEIT premises and are reported in Section 2.

The second testbed is used to validate the operation of the prototype within a network. Section 3 outlines the results of the network test conducted in OTE, which proves the demonstrator’s capability to transport traffic. Section 4 draws the main conclusions of this deliverable.



2. EQUIPMENT VALIDATION TESTS

2.1 Overview

This section describes the validation tests that have been performed in WP5, where we have considered the subset with the most significant R&TTE compliance tests. The testbed architectures and the technical test plan described in D5.1 were the reference guide in order to carry out these tests.

The prototype obtained as output of WP4 has been integrated in a first testbed. During these validation tests, its compliance with the requirements defined in WP1 has been analysed. This section shows the measurement results and possible deviations are discussed. The tests have been performed for both the transmitter and the receiver and all of them were carried out at room temperature.

All the tests of this document are reported with:

The demonstrator part involved

Its category

A short description

The relevant limits, the references and some considerations

The test bench arrangement for the assessment

Results and discussion



2.1.1. Transmitter – Transmitter power Level

The transmitter power level is an essential parameter that has to be checked under the R&TTE certification. This parameter is essential for the Tx side and consists of at least two parts reported as nominal transmitter output power and its tolerance.

The objective of this test is to verify that the maximum nominal output average power measured at reference point C in Figure 2-1 is within the following limits:

Nominal transmitter output power, subject to the supplier declaration

Tolerance reported into the relevant ETSI EN 302 217-2-2

These limits are reported in D.1.2.3 as mandatory requirements and can be seen in Table 1.

Table 1: Transmitter power level requirements

Requirement ID

Category Parameter Typ Units

Transceiver Element

Prototype applicabilit

y

[ReqEqu044] M Tx maximum power <30 dBm TX Yes

[ReqEqu045] M Tx Power Tolerance ±4 dB TX Yes

[ReqRFT_001]

M Pout mean 9 dBm TX Yes

[ReqRFT_003]

M Power accuracy +/- 1 dB TX Yes

[ReqRFT_004]

M Interconnection to Diplexer loss 2 dB TX Yes

[ReqDup010] M Diplexer Insertion Loss 0.75-1.5 dB TX Yes

Note that the Tx mean Operating power (Pout mean) is not the maximum possible output

average RF power, but rather the maximum RF power that is suitable for 64-QAM transmission including back-off and other impairments.

Test instruments:

1) power meter

2) power sensor

Test configuration:

The following picture depicts the test configuration. The RF signal at point C is a 10 Gbps 64-QAM modulated signal with a bandwidth of 2 GHz, generated in baseband in the Tx FPGA, converted to analogue using the DAC board and then up-converted to the E-Band.



Figure 2-1: Transmitter power and tolerance test bench.

Test procedure:

With the transmitter power level set to maximum operating level, the average power output of the transmitter at point C is measured.

Measurements were performed in the four different RF channels outlined in Table 2.

Table 2: RF channels and their corresponding centre frequencies

F0 RF freq Unit

CH 1 72.125 GHz

CH 2 74.625 GHz

CH 3 82.125 GHz

CH 4 84.625 GHz

Results and discussion:

Table 3 depicts the measured power as well as the specified value from D1.2.3.

Table 3: Transmitter Power Level

It is observed that the transmitter RF output power, measured at the diplexer antenna port, is lower compared to the specification in D1.2.3. The reasons for this mismatch have been identified:

- Higher die-PCB interconnection loss.

- Lower P1dB at PA, which makes it necessary to operate at a lower output power to maintain the back-off.

Spec.

[ReqDup_010]&[ReqRFT_001]& [ReqRFT_004] TX power CH 1 -4.4 dBm TX #1 6 +/-1




F0 Typ Unit

TX #1 - ANTENNA PORT

Req. ID Parameter TX unit



- Using different dies for the I/Q up-converter and the mm-wave Tx, which means higher interconnection losses and thus less Tx gain.

- Inclusion of a 3dB splitter between the I/Q up-converter in order to sense the IF output signal and calibrate the I/Q imbalance.

Nonetheless, the measured power levels for usable transmitter RF output power when using 64-QAM modulated signals aligns well with the evaluation of a standalone Tx up-converter PCB in D2.5 (figure 2-16, p. 17). The stand-alone Tx up-converter demonstrates a typical P1dB figure of [+6, -2, +2, +1 dBm] for CH 1 to 4, respectively. Given the 10 dB back-off required when using 64QAM, the theoretical value of the useable RF output power would be of [-4, -12, -8, -9 dBm] for CH 1 to 4 at the Tx PCB, respectively. Comparing these figures, it is seen that the measured output power is typically higher in D5.2 compared to what was presented in D2.5. This is due to the fact that the measurements of the output power in D5.2 are done on the combined IQ/Tx PCB rather than on the stand-alone Tx board (both described in section 4.3.1 in D4.1). One difference between these boards is the bondwire compensation structure for the RF output of the Tx die. The combined IQ/Tx PCB possess therefore better output match for the Tx die compared to the stand-alone Tx PCB, resulting in higher output RF power on CH 1 to CH 3, but most prominent on CH 2. From these measurements it can be assumed that the optimum frequency of the bondwire compensation circuit has been shifted somewhat down in frequency (ideally it was designed for an optimum at 78.5 GHz), most likely due to longer bondwires than anticipated in simulations.

Figure 2-2 shows the RF output power from the Tx PCB (with the diplexer and WG loss de-embedded) vs. channel number for the two transmitters, as well as the theoretical value derived from D2.5 (=P1dB from D2.5 minus 10 dB back-off required for 64-QAM modulation).

Figure 2-2: RF output power from TX PCB vs. channel number

Based on the presented results and considering the maximum possible tolerance according to the ETSI EN 302 217-2-2 (+/- 3 dB), the transceiver demonstrator is able to be used in CH 1, CH 2 and CH 3 with a typical transmitter RF output power at the diplexer antenna port of −7 dBm.

-14

-12

-10

-8

-6

-4

-2

0

2

1 2 3 4

RF

ou

tpu

t p

ow

er -

PC

B (

dB

m)

Channel number (#)

Transmitter #1

Transmitter #2

Theoretical value from D2.5



From these measurements, we can conclude:

Assembling of the die has a big impact on the transmitter chain performance from the point of view of the RF output power. Proper packaging and interconnection arrangement are critical points for future equipment design.

The results of the project show that a transceiver in E-Band built completely in SiGe can provide up to 10 dBm at the antenna port. The transmitter power level required by the market for the application of 64QAM is in the range from 10 to 15 dBm. In order to provide margin, the SiGe transmitter might need to be complemented by a final stage using a different technology, such as GaAs.

2.1.2. Transceiver – Spectral mask

The spectral mask is an essential parameter that has to be checked under the R&TTE certification. This parameter is essential for the transmitter. The objective of this test is to verify that frequency spectrum is within the specified limits of the relevant standard. These limits are usually divided into the following parameters to be met:

Transmitter Spectrum Mask [class 5L]

Discrete CW components exceeding the spectrum mask limit at symbol rate

Other discrete CW components exceeding the spectrum mask limit

We have reported our limits in D.1.2.3 as mandatory requirement and they are shown in Table 4.

Table 4: RF Spectrum mask and spectral lines at the symbol rate requirements

Test instruments:

1) spectrum analyser

Test configuration:

Three different measurements have been considered. The first measurements have been done at TX-IF level to assess the consistency of the spectrum generated by the base band modulator. The second at RF out power, where the test has to be validated



and the third at the RX-IF level. The measurement is made with a suitable spectrum analyser connected to the relevant points that will be explained in detail in the next paragraphs.

First measurement test bench

The block diagram of first measurements is depicted in the following figure. As mentioned, the scope of these first measurements was to assess the consistency of the spectrum mask generated by the base band modulator.

Figure 2-3: TX-IF spectrum mask test bench

Test procedure:

The TX IF chain was opened and interconnected through a suitable attenuator to the spectrum analyser. The spectrum mask measured at the IF transmission level is captured using the spectrum analyser.


The following figure shows the captured Tx-IF spectrum with the mask it should fulfil. From this figure, it can be concluded that the spectrum mask is well generated, and fulfils the spectrum mask limits.



Figure 2-4: Tx-IF Spectrum mask

Second measurement test bench.

The following figure shows the block diagram of second measurements done. This is the test required by R&TTE procedure and its scope is to assess the Transmitter Spectrum Mask limits, so class 5L, the discrete CW components exceeding the spectrum mask limit at symbol rate and the other discrete CW components exceeding the spectrum mask limit.

Figure 2-5: Spectrum mask and Spectral lines at the symbol rate test bench

Test procedure:

This measurement is usually performed measuring the spectrum directly at the TX output. However, this is not the best option for the selected system. In order to perform spectrum



measurements at mmW frequencies, a harmonic mixer (Keysight M1971E, for instance) needs to be connected at the input of the spectrum analyser in order to down-convert it to a frequency range acceptable for the analyser. These harmonic mixers typically have an input 1-dB compression point of 0 dBm or less, which means that a maximum power in the order of −10 dBm can be measured, applying a 10 dB back-off so that the harmonic mixer itself does not distort the signal. This, together with the fact that this power is divided into a very broad spectrum (2 GHz) and that the noise floor of the equipment is higher at these frequencies, make it unfeasible to measure the differences in the order of 30-40 dB between the signal and the noise floor required by the mask specification.

It should be noted that, this particular point is peculiar of our system, and does not impact current E-Band systems in the market where the channel spacing is lower, and the transmit power level is higher than that in E3NETWORK. This is one of the main points we want to highlight, and it happens when we have a system with huge channel spacing. This point is part of the discussion we will provide to the ETSI, when the profile will be discussed.


The results obtained if we measure directly at the equipment output antenna port are similar to the on-wafer measurements, because the noise floor of the spectrum analyser is not sufficient to show the real equipment limits. In other words, this test bench is limited in sensitivity and then not able to provide a measurement of the equipment spectrum outside the main region, so to assess the IDM3 zone and the noise floor zone.

The measurement is performed at the centre frequency of 82.5 GHz, considered as the worst case. To better investigate on this part of the spectrum, we provide an additional testbed, described below.

Third measurement test bench.

The following picture depicts the block diagram of third measurement we did. Considering that the previous method hasn’t provided a trusted measurement, due to the limitations of the available test equipment, the scope of this test is to assess the Transmitter Spectrum Mask limit and the discrete CW components at symbol rate and the other discrete CW components exceeding the spectrum mask limit, in a more trusted way.

We have decided to use part of our demonstrator as part of the tester equipment. This way, making a comparison between what was obtained at point 2 and at this point, we can reach some ultimate conclusion. Therefore, it is decided that the mask can be measured with more sensitivity exploiting our receiver and, particularly, the down-conversion part of the receiver chain.

The main assumption taken here is that, if the spectrum mask requirement is met after down-conversion, it means that it is also met, for sure, at the output of the TX. In this way, we have tested the linearity of the receiver chain as well. Results obtained are for sure penalised by the receiver performances, but could say to us two important things:

In conjunction with the measurement taken at the second point, this measurement provides a final answer to the question if the transmitter spectrum mask at the equipment port fulfils the limits required.

It provides a good test on receiver performances in terms of linearity and spectrum purity.



Figure 2-6: RX-IF Spectrum mask and Spectral lines at the symbol rate test bench

Test procedure:

The test is done as follows: the mmW TX output is connected to the mmW Rx input over the WR12 waveguide and attenuator, which has been characterized in D4.2. The 30 dB waveguide attenuator is placed to ensure that the mmW Rx works within its linear region. The IF output from the mmW Rx is fed directly to the spectrum analyser as seen in Figure 2-3. Both IF-I and IF-Q signals are examined manually with the spectrum analyser but only one signal at a time. The unused IF output is terminated in a 50 Ohm load. For all measurements, there were no significant differences between the I signal and the Q signal and only one plot per channel is therefore presented. The centre frequency of the IF is chosen to 1.25 GHz in order to allow for a broadband examination of the spectrum.


The next Figure shows the Spectrum at RX-IF level port together with its mask. Additionally, Figure 2-8 shows the output spectrum measured on-wafer directly with a probe, a harmonic mixer (Keysight M1971E) and a spectrum analyser. As shown, the noise floor of the spectrum is very well confined into the mask, proving the compliance of the spectrum with the requirements, not only at this point, but at the antenna port as well. It should be noticed that the spectrum fulfils very well the IDM3 region as well, this means that the linearity of the transceiver, in this condition, should be very good and suited for spectrum mask fulfilment.



Figure 2-7: Rx-IF Spectrum mask



Figure 2-8: On-Wafer measured TX spectrum

From Figure 2-7, it can be concluded that the system works properly from the emissions. At this point we can observe that:

The spectrum mask limits, which we have identified as the limits and should be the candidate in the next ETSI harmonised standard, under RED, is fulfilled by our demonstrator.

Here we need to consider that: Since the Transmit power level is lower that what expected, the fulfilment of the

spectrum mask limits in the region of IDM3 is facilitated. It may be noticed, anyway, that a good level of margin appears, anyway.

We have demonstrated, with the testbed at point 1, that the spectrum mask is fulfilled very well in the central region. This part account for how the signal has been generated and filtered in Base band.

Regarding the limits on the noise floor part of the spectrum, we have demonstrated, through the test bed at point 3, that we fulfilled it. Moreover, we have discovered a possible weak point for future equipment test feasibility, mandatory under ETSI, in testing this part. Special adviser will be provided in ETSI.

Last remark on this point: We need to point out that this test shall be carried out with a signal proved that is working, in a stable manner, under the Bit Error ratio measurements, BER < 10-10 under normal conditions, proving its suitability in transporting a signal with a given level of quality. Unfortunately, this test cannot be performed as described in D4.2. However, the measurements performed in Subsection 2.1.3 address this issue showing that the transmitted E-Band waveform has the appropriate features.



2.1.3. Transceiver - BER as a function of Receiver input Signal Level (RSL)

This parameter is an essential parameter that has to be checked under the R&TTE certification. This parameter is important for the whole transceiver, as it checks the Tx and Rx functionalities. This parameter is usually reported as Bit Error Rate (BER) as a function of receiver input signal level (RSL). The diplexer filter shall be considered part of the Receiver and the relevant losses shall be accounted.

The objective of this test is to verify that received signal level versus BER thresholds is verified. The limit that shall be fulfilled for this parameter is usually reported into the relevant ETSI EN 302 217-2-2, but in our specific case, this limit is derived as explained in D1.2.3 and shown in Table 5, since our profile is not yet foreseen in current ETSI standard.

Table 5: BER as a function of RSL requirements

To be able to measure the Bit Error Rate after the Reed-Solomon Decoder, but before dropping GFP Idle frames in the Network Interface, without modifying the actual DBB-Rx hardware, the DBB-Rx is simulated by a HDL hardware simulation. Therefore, a digital sampling oscilloscope is used to record the transmitted data directly at the input of the DBB-Rx’s ADC.

Test instruments: 1) Spectrum analyser (SA);

2) Attenuator;

3) Digital Sampling Oscilloscope (DSO).

Test configuration:

The following figure shows the configuration employed for this test.



HW-SIM

TESTER

DUT

DBB-Tx TX Diplexer

C‘

Attenuator

LOAD

LOAD

SA

DUT

DSO

Diplexer

C

RX

File

DBB-Rx

Figure 2-9: BER as a function of RSL test bench

Test procedure:

Configure the DBB-Tx to transmit GFP Idle frames. Then, to take record of the BER curve, vary the received signal level using the attenuator. For each attenuator setting, capture data using the digital sampling oscilloscope (DSO). Afterwards, use the DBB-Rx HDL hardware simulation to create files containing the captured data between Decoder and Network Interface. Finally, analyse these generated files using Matlab and calculate Bit Error Rates (BER) for each attenuator setting.

Verify that the RSL, corresponding to the BER thresholds are within the specifications. The RSL is calculated by measuring the signal level at the output of the RX with a spectrum analyser (SA) and then subtracting the gain of the RX and adding the loss of the diplexer.

In the scope of E3NETWORK, we have not defined for the demonstrator the upper limit for the input level, but just the lower limit. This limit has been derived by extrapolating the current ETSI RSL limits and shall be considered the maximum RSL the demonstrator shall require to perform at BER better than 10-6. Fulfilling this limit is mandatory to obtain the R&TTE certification and then the CE mark, enabling the system to become a real commercial product.

Results and discussion: Data for 8 different attenuator settings have been captured, varying the RSL between

-38.3 dBm and -44.4 dBm. For each of the settings, about 400 E3Network PHY frames have been captured using the DSO. This led to about 16.7x106 bits that have been analysed for each setting. The Es/No values have been estimated by a hardware HDL module part of the DBB-Rx. To reduce HDL simulation time, the data with higher RSL than the first error-free data have not been simulated. The results are shown in Table 6.

Table 6: BER as a function of RSL

RSL [dBm]

Relative attenuation [dB]

Estimated Es/No [dB]

BER

-38.3 0

-39.3 1

-40.5 2.2

-41.2 2.9 23.2 0



-42.4 4.1 22.7 8.9x10-7

-43.2 4.9 21.7 1.1x10-4

-43.8 5.5 20.8 2.4x10-3

-44.4 6.1 20.3 6.7x10-3

From the table, it can be seen that the BER is < 10-6 for RSL > -42.4 dBm. So the Requirement ReqEqu083 is met. Due to the limited number of bits captured with the DSO, ReqEqu084 cannot be verified.

Finally, Figure 2-10 shows the BER as a function of the RSL and Figure 2-11 shows the

BER as a function of the estimated Es/No.

1.00E-07

1.00E-06

1.00E-05

1.00E-04

1.00E-03

1.00E-02

1.00E-01

1.00E+00

-45 -44.5 -44 -43.5 -43 -42.5 -42 -41.5 -41

BER over RSL[dBm]

Figure 2-10: BER as a function of RSL



1.00E-07

1.00E-06

1.00E-05

1.00E-04

1.00E-03

1.00E-02

1.00E-01

1.00E+00

20 20.5 21 21.5 22 22.5 23 23.5

BER over Es/No[dB]

Figure 2-11: BER as a function of the estimated Es/No



3. NETWORK VALIDATION TESTS

3.1 Assessment process

After presenting the most relevant results related to the standardization conformance, the demonstrator’s functionality and performance in network traffic conditions is analysed.

The purpose of the test environment is twofold, regarding achievement of project objectives on one hand and examination of possible impact to OTE’s services on the other.

3.2 Testbed design

The test has been conducted in OTE’s lab environment, by adding the demonstrator

transceiver inside the network deployment model that is used to offer a wide range of services to customers, such as IPTV and Internet Feed. The E3Network prototype configuration for the setup is shown in Figure 3-1. Transmitter Tx-DBB receives Ethernet packets from the network and Rx-DBB provides Ethernet packets to the network. Both connections with the network are through SFP+ interface. The network frames to be transmitted are input to the FPGA in Tx-DBB. The FPGA performs framing, coding and generates the samples of the modulated waveform that are fed to the DAC board for digital-to-analogue conversion. The signal goes through a couple of low-pass filters in order to remove the signal images caused by the digital-to-analogue conversion. The signal is then converted back to the digital domain using ADCs. Finally, the samples are processed in the Rx-DBB FPGA.

Figure 3-1: Picture of the E3NETWORK demonstrator used for the network test

Figure 3-2depicts a small picture of OTE’s live network. The CPE (Customer Premise Equipment) represents the triple play service, namely voice (phone), video (Set Top Box) and data (PC). The individual subscriber devices connect to a HG (Home Gateway) over a DSL (Digital Subscriber Line) connection. The HG connects into the nearest DSLAM (Digital Subscriber Line Access Multiplexer), and a switch serves to aggregate traffic from multiple DSLAMs located in different areas. The BNG (Broadband Network Gateway) router is the access point for the subscribers, where PPPoE sessions are terminated. When a connection is established between BNG and CPE, the subscriber can access the broadband services provided by the service provider. BNG connects to OTE's Core network (CN), from where the IPTV platform serves the multicast/unicast content to the subscribers. The PE (Provider Edge) is a router between OTE’s area and areas administered by other network providers.



Figure 3-2: OTE network topology

The transceiver demonstrator is introduced in the path as depicted in Figure 3-3. The Spirent Test Center (STC) can be connected in different points of the path in order to measure performance characteristics. Spirent Test Center is also be used to introduce high and complex traffic to the network and assess the corresponding behaviour of the demonstrator. Spirent Traffic Generator and Analysis Tool can enable the creation of completely customized traffic patterns, constructing raw frames and setting specific values for every single field of a frame, such as QoS values, Time to Live parameters, MTU size and so on. Furthermore, customized representation of traffic results is supported, providing statistics and in-depth analysis of the generated traffic.

Figure 3-3: OTE testbed topology with E3NETWORK transceiver.



For the tests, two configurations of the E3Network transceiver have been employed. Initial tests were conducted considering the setup of Figure 3-4, which consists of the Network Interface for the transmitter, the DBB encoder, the DBB decoder, a mapper to connect the two latter modules, and the Network Interface for the receiver. We will call this configuration FPGA loop. This test design has been connected via a 10 Gbit Ethernet SFP+ connector to the Spirent Test Center, which is used for providing various data streams of configurable size and rate to the test setup, and measuring the received Ethernet data.

Network Interface

DBB(Enc/Dec)

NI-Tx

Mapper

NI + Enc/Dec

FEC Decoder

SFP+

FEC Encoder

NI-Rx

Network Tester(Spirent TestCenter C1)

Figure 3-4: Block diagram of the FPGA loop configuration

Figure 3-5 shows the layout of the testbed using this configuration in the lab. The receiver is

used to implement the FPGA loop. The fibres connected to the FPGA board can be observed (highlighted in red). This configuration is used for initial testing of the network.

Figure 3-5: Device under Test using the FPGA loop configuration



The second configuration used for the tests is a full base-band loop. We will call this configuration base-band loop. This configuration uses the full DBB-Tx, the DAC board and the base-band filtering of the transmitter prototype. In the receiver prototype it uses the ADC board and the full DBB-Rx. Transmitter and receiver are connected using SMA cables. Figure 3-6 shows layout of the testbed using this configuration in the lab. The fibres are connected from the STC to the SFP+ connector of the transmitter prototype for transmission (highlighted in green). For reception, fibres are connected from the SFP+ connector of the receiver prototype to the STC (highlighted in red).

Figure 3-6: E3Network Device under Test using the base-band loop configuration



3.3 Testing related to project objectives

In the tests performed the frame length has been varied between a minimum of 64 bytes and a maximum of 1518 bytes (considering 14 bytes for Ethernet header and 4 bytes for FCS). Bandwidth utilization has also been varied between 4% and 100% (anticipated value is below 86%). Measurements have been collected for received frame rate, throughput and latency values.

Relative to the network testbed are project objectives O1 and O2, concerning respectively throughout and latency.

3.3.1. Throughput testing

“O1. Modern digital multi-level modulation and demodulation methods and novel digital processing methods will be applied. These modern modulation techniques will increase the spectral efficiency of the E-band link providing an augmented backhaul capacity. The project targets a capacity for the wireless link of at least 10 Gbps.”

Table 7: Throughput – requirements

Requirement ID

Category Parameter Min Typ Max Unit Transceiver Element

Prototype applicability

[ReqDoW001]

M

Throughput in each direction (up and down link) 10 Gbps TX/RX Yes

[ReqNet021]

M Ethernet packet rate 710108

Packets/s TX/RX Yes

[ReqEqu026] M

Minimum RIC for class 5L and 2GHz channel

8400 Mbits/s

TX/RX

Yes

In the test planning procedure, the link is charged with variable traffic from the traffic generator, up to its maximum capacity.

The achieved throughput is measured to check whether it reaches the anticipated value of 10 Gbps as per D.1.2.3 ReqDoW001. This throughout shall be achieved over the air and corresponds to a Raw data rate value of 10.435 Gbps and a Net data rate value of 8.669 Gbps, according to Table 23 of D1.2.3. As analyzed in D3.5, the overhead related to GPF framing and Ethernet overhead should also be taken into account in the computation of the net data rate. The requirement for the RIC is 8.4 Gbps as stated in ReqEqu026 of D1.2.3.



Results and discussion: Initial testing has been conducted using the FPGA loop configuration. For the first test,

packets with a fixed frame length of 1500 bytes have been transmitted from the network with data rate 10 Gbps considering 100 % bandwidth utilization. STC is used to measure the traffic and stream results as shown in the figures below. The obtained throughput value for a total Tx rate of 9.868 Gbps is 8.562 Gbps. Tx transmits 822359 frames per second while Rx receives 713462 frames per second.

Figure 3-7: Traffic results for 100 % bandwidth utilization, MTU 1500 bytes

Figure 3-8: Stream results for 100 % bandwidth utilization, MTU 1500 bytes

The graphical representation of the received throughput is shown in Figure 3-9, where the red line corresponds to Tx data rate and the blue line to Rx data rate.

Figure 3-9: Received versus transmitted data rate for 100 % bandwidth utilization, MTU 1500 bytes



While maintaining the same MTU size (1500 bytes), transmitted bandwidth has been set to 8.5 Gbps, which is below the net data rate value anticipated during the design phase of the project but above the RIC value requirement. The results show total Tx rate of 8.385 Gbps against total Rx rate of 8.375 Gbps, and no packet losses according to the figures below.



Next we consider transmission MTU size of 1500 bytes, and 86 % payload bandwidth utilization. Both Tx and Rx throughput are very close to 8.484 Gbps and we have zero dropped frames as depicted in Figure 3-12, Figure 3-13 and Figure 3-14, Figure 3-15 respectively.





Figure 3-14: Tx/Rx L1 rates for 86 % bandwidth utilization, MTU 1500 bytes


When changing the frame length to 1518 bytes with a load of 86 %, Tx data rate and Rx throughput are still very close to one another (around 8.483 Gbps) according to Figure 3-16 and Figure 3-17. Additionally Figure 3-18 and Figure 3-19 depict a zero dropping rate for the transmitted packets.







If the transmitted MTU is reduced to the minimum of 64 bytes and only 4 % bandwidth utilization is considered, Rx throughput closely follows the Tx data rate of 305 Mbps. There are still no dropped packets. Respective results from the network test centre are presented in Figure 3-20, Figure 3-21, Figure 3-22 and Figure 3-23.







Table 8 summarizes the measurements of the achieved throughput. The network interface components are verified when fed with network generated traffic of variable payload size/utilization of the available 10Gbit bandwidth. The test setup achieves a maximum of 8.561 Gbps for packets of fixed frame length 1500 bytes and 10 Gbps transmitted data rate or 8.483 Gbps for a more realistic 1518 MTU size and 8.6 Gbps transmitted net data rate value.



Table 8: Throughput results

Payload size (bytes)

Bandwidth utilization (percentage of 10Gbps)

Tx data rate (bits/s)

Throughput (bits/s)

64 4 304.757.696 304.757.688

1500 85 8.384.737.768 8.375.114.440

1500 86 8.484.052.792 8.484.052.672

1518 86 8.482.762.248 8.482.757.680

1500 100 9.868.293.320 8.561.564.216

The FPGA loop configuration presents satisfactory results from the point of view of throughput. It is able to provide the required RIC and the connection to the STC works properly.

After the extensive throughput testing of the FPGA loop, throughput tests have also been conducted in the base band loop of the demonstrator, with quite similar results. The following figures show an example of the results of some of the tests performed. In this test, the Base-Band transmitter is fed with traffic up to 84 % of the 10 Gbit bandwidth, considering a fixed frame length of 1500 bytes. The achieved Rx data rate is 8.147 Gbps, closely following the Tx data rate of 8.286 Gbps.

Figure 3-24: Traffic results for 84 % bandwidth utilization, MTU 1500 bytes, BB loop



Figure 3-25: Received versus transmitted data rate for 84 % bandwidth utilization,

MTU 1500 bytes, BB loop



3.3.2. Latency testing

“O2. The developed transceiver will be able to meet the timing requirements of both IP backhauling and CPRI interconnect. Therefore, the latency of the E3NETWORK transceiver will be well below one millisecond.”

Table 9: Latency - requirements

Requirement ID

Category Parameter Min Typ Max Unit Transceiver Element

Prototype applicability

[ReqDoW004] M

Latency of the whole system 1 ms TX/RX Yes

[ReqNet004] M

Latency of the whole system 30 us TX/RX Yes

The test planning procedure includes different traffic shapes fed to the experimental setup.

Spirent Test Center is used to provide latency measurements, validate its maximum anticipated value, as per D.1.2.3. ReqDoW004 and ReqNet004 and verify that even the traffic most sensitive to latency is not affected by the demonstrator transceiver.


This test has been performed using the FPGA loop. As the modem and analogue front-end introduce negligible latency, results are the same for the base-band loop. In this test, small packets with fixed frame length of 128 bytes are transmitted from the network considering 4% utilization of the 10 Gbit bandwidth. The average measured latency is 13.55 us.

Figure 3-26: Latency for 4 % bandwidth utilization, MTU 128 bytes

When the payload is increased to 86 % of the available 10 Gbit and an MTU size of 1518 bytes is considered, measured latency increases to 14.68 us.



Figure 3-27: Latency for 86 % bandwidth utilization, MTU 1518 bytes

Finally even when bandwidth utilization reaches the maximum of 100 %, for packets with a fixed frame length of 1500 bytes, average latency increases up to 20 us.

Figure 3-28: Latency for 100% bandwidth utilization, MTU 1500bytes

Table 10 summarizes the latency measurements obtained through Spirent Test Centre, for variable payload size and bandwidth utilization. In all cases, resulting values always remain below the anticipated threshold of 30 us, thus conformant to system requirements.

Table 10: Latency results

Payload size (bytes)

Bandwidth utilization (percentage of 10Gbps)

Average Latency (us)

128 4 13.55

1518 86 14.68

1500 100 20



3.4 Testing related to network stability

Apart from the transceiver requirements’ fulfilment, the implementation of the following test scenarios is of great interest from an operator’s point of view. These tests are not required from the point of view of standardization conformance, but they provide information regarding the usability of the equipment by network operators.

3.4.1. Capability to transport IPTV traffic

In this test scenario we proceed to the verification that multicast traffic coming from the IPTV platform passes correctly through the demonstrator transceiver. This includes the verification that IGMP join - and leave- messages are correctly forwarded back and forth.

Spirent Test Center is used as a traffic generator for testing various types of traffic. The STC can play the role not only of the streamer but also of the CPE. At first it should be tested that the STB can receive correctly the IPTV service of OTE if the E3NETWORK demonstrator is introduced between the DSLAM and the distribution switch. Channel zapping timers can also be measured. OTE services are split in VLANs with each VLAN being a different service. For IPTV VLAN 99 is forwarding Multicast traffic while VLΑΝ 609 is responsible for assigning IP address to the CPE. We test the capability of the E3NETWORK transceiver to create VLANs needed for each service and be able to transport specific traffic in each of them. So for VLAN 609 broadcasts should be allowed to pass in order for the CPE to retrieve its IP address it is going to use.


Initial tests are conducted using the FPGA loop configuration. In order to verify that IPTV service passes correctly through the test setup, we have simulated the multicast traffic. More specifically traffic to multicast address 225.10.11.45 was sent through the device under test in a high bit rate without losing any packets. Additionally the operation of the actual service of IPTV was tested including a multicast stream with a VLAN header and priority value for the VLAN (COS). We have concluded that the stream traffic was not affected and the priority of the packets remains unchanged, for example packets with a value of COS 7 keep this value through the DUT.

Packets with MTU size 1518 bytes are sent utilizing 86 % of the available 10 Gbit bandwidth. One VLAN has been configured with priority 7. Achieved throughput is close to 8.48 Gbps and there are no dropped frames, as seen in Figure 3-29, Figure 3-30 and Figure 3-31.




MTU 1518 bytes, 1 VLAN

Figure 3-30: Tx/Rx L1 rates for 86 % bandwidth utilization, MTU 1518 bytes, 1 VLAN

Figure 3-31: Stream results for 86 % bandwidth utilization, MTU 1518 bytes, 1 VLAN

Additionally, the trace capture from Wireshark network analyser shows that the VLAN priority 7 is maintained.

Figure 3-32: Trace capture for 86 % bandwidth utilization, MTU 1518 bytes, 1 VLAN



The addition of a second VLAN does not practically affect throughput (Figure 3-33), while the trace capture shows that both VLANs and their priorities are maintained as anticipated (Figure 3-34).


MTU 1518 bytes, 2 VLANs

Figure 3-34: Trace capture for 86 % bandwidth utilization, MTU 1518 bytes, 2 VLANS

The transmission of multicast traffic is examined next, for fixed packet frame length of 1518 bytes and 8.6 Gbps data rate as before. No dropped frames are encountered, while the network analyser trace shows that multicast traffic passes correctly through the test design. Respective results are depicted in Figure 3-35, Figure 3-36 and Figure 3-37.

Figure 3-35: Tx/Rx L1 rates for 86 % bandwidth utilization, MTU 1518 bytes, multicast



Figure 3-36: Stream results for 86 % bandwidth utilization, MTU 1518 bytes, multicast

Figure 3-37: Trace capture for 86 % bandwidth utilization, MTU 1518 bytes, multicast

Finally multicast throughput for 86 % bandwidth utilization and for increasing frame length is shown in Figure 3-38. The steps in the diagram correspond to 128, 256, 512 and 1024 bytes respectively. For the specific bandwidth utilization it is observed that higher losses are encountered for smaller packet sizes. This is an expected behavior, as the E3Network Transceiver is limited to a fixed maximum frame rate that is independent of the packet size.


MTU 128, 256, 512, 1024 bytes, multicast

After having completed the tests with the FPGA loop configuration, we proceed with the tests conducted in the base-band loop configuration. Multicast traffic is tested again to verify that the IPTV service can pass correctly through the E3Network demonstrator baseband loop. A maximum of 1 Gbps is considered for the transmission rate relevant to this service. Achieved throughput is 965 Mbps as shown in Figure 3-40, Figure 3-41.



Figure 3-39: Multicast traffic simulating IPTV service

Figure 3-40: Tx/Rx rates for IPTV service simulation

Figure 3-41: Received versus transmitted data rate for IPTV service simulation

The trace capture from Wireshark network analyser of Figure 3-42 shows correct reception of the multicast packet.



Figure 3-42: Trace capture for IPTV service simulation

Considering the results of the conducted tests, we conclude that the E3Network demonstrator under test is suitable for transporting IPTV traffic.



3.4.2. Capability to support different traffic patterns

In this test scenario, we carry out an assessment of the performance regarding various kinds of traffic patterns, such as small packets, large packets or iMIX traffic.

We use the STC to generate many kinds of traffic on a specific rate to measure the performance of the E3NETWORK transceiver. Because OTE is using many services in its network we need to make sure that various types of traffic are correctly forwarded. With the STC in place performance counters can be measured along with E3NETWORK demonstrator CPU’s consumption. One end of the STC sends the traffic while the other end of the STC receives it. Traffic patterns that OTE is using for iMIX traffic are 58.33 % of small packets with Ethernet frame of 64 bytes, 33.33 % of medium packets with frame length of 594 and lastly large packets with frame length of 1518 bytes.


As previous tests do not show degradation between FPGA loop configuration and base-band loop configuration, this test and the remaining ones are carried out using only the base-band loop configuration. In this test various combinations of iMIX traffic summing up to 84 % of the utilized bandwidth have been generated from the STC. Even though the receiver throughput was satisfactory (Figure 3-44), a significant number of dropped packets was captured as shown in Figure 3-45. Testing the transmission of iMIX traffic with altered percentages of the small, medium and large frame packets did not eliminate the resulting packet loss.

Figure 3-43: iMIX traffic

Figure 3-44: Received versus transmitted data rate for iMIX traffic



Figure 3-45: Stream results for iMIX traffic

Considering the results of the conducted optional network usability tests, we conclude that the E3Network demonstrator under test is currently not yet suitable for transporting iMIX traffic. Further investigation after this issue was detected during the final WP5 integration workshop unveiled an incorrect implementation of the GFP encapsulation module, which only leads to problems in this scenario. This error was identified and fixed thereafter. The network interface was validated with respect to this scenario at FHG’s lab using the FPGA loop and an Anritsu network tester. With this fix, the observed misbehaviour using the base-band loop should be resolved, too.



3.4.3. Capability to support QoS and prioritization mechanisms

This test scenario verifies if there is any QoS mechanism that can be implemented on the transceiver. With multiple services existing on OTE’s network it is essential to verify that all those services can coexist together without introducing any problems to the end users. These services like Dedicated Internet Access or DIA, IPTV and voice should be able to pass through E3NETWORK demonstrator transceiver without causing problems to the high demanding ones.

STC is used to send traffic of those services but with different DSCP values or CoS bits that the transceiver should trust. When there is a congestion of the traffic, priority must be given to traffic with higher DSCP or CoS values. If there is no congestion, traffic should be forwarded as expected.


In this test case DiffServ is examined by using DSCP (differentiated services code point) in the IP header of the generated packets. This header allows classification and prioritization of network traffic, thus providing a QoS mechanism on IP networks. The Wireshark network analyser capture shows that the transmitted DSCP value is not affected by the E3Network demonstrator, so QoS can be implemented as expected.

Figure 3-46: Trace capture for QoS mechanism



Considering the results of the conducted test, we conclude that the E3Network demonstrator under test allows the implementation of QoS and prioritization mechanisms for service transmission.



4. CONCLUSIONS

The deliverable contains the final measurements and validation of the prototype integrated in the designed testbed in task 5.1.

The first part of the document is dedicated to the equipment validation testing, R&TTE compliance tests and requirements conformance. Despite the prototype achieves a lower transmitted output power than expected, the output spectrum is free of spurious and meets the transmission mask of the standard. The output power level issue can be addressed by complementing the SiGe transmitter with a final amplifying stage using a different technology, such as GaAs. This way, we benefit from the capability of SiGe technology to integrate the transmitter chain and from the higher performance of GaAs technology just in one component.

Another result derived from the measurements of the project that must be highlighted is that when operating with systems with huge bandwidth and low power transmission levels such as E3Network, it is unfeasible to measure the differences in the order of 30-40 dB between the signal and the noise floor required by the mask specification. This will be an interesting point that will be brought to ETSI to be discussed there and impacts both the back-haul /front-haul equipment manufactures and the measurement equipment manufactures.

The measurements performed show that the prototype is able to achieve the required BER for the RSL specified by the consortium. This requirement was extrapolated from the standard as an ultra-high bandwidth system such as the one developed in the project is not yet foreseen in current ETSI standard.

In the second part of the document the prototype under test has been connected to the network for conducting the network validation tests. The main project objectives regarding throughput and latency requirements have been verified. Furthermore, tests related to network stability under real traffic conditions have been carried out to assess its usability from the network operator point of view. Three different criteria addressed in different kinds of traffic have been evaluated. The tests performed on the E3Network demonstrator were positive in two of the three scenarios analysed, proving that the E3network prototype is capable to support IPTV/multicast traffic and QoS/prioritization mechanisms. Moreover, the issue detected in the tests with different traffic patterns has been corrected in the demonstrator.



5. REFERENCES

[1] E3NETWORK Project, D1.2.3: “Specification of the E3NETWORK Transceiver – 3”.

[2] E3NETWORK Project, D4.1: “Prototype of the integrated E3NETWORK transceiver”.

[3] E3NETWORK Project, D4.2: “Measurement report of the E3NETWORK transceiver”.

[4] E3NETWORK Project, D4.2: “Measurement report of the E3NETWORK transceiver”.

[5] ETSI EN 302 217-1 (V2.1) (07/2013): "Fixed Radio Systems; Characteristics and requirements for point-to-point equipment and antennas; Part 1: Overview and system-independent common characteristics".

[6] ETSI EN 302 217-2-2 V2.1.1 (07/2013): " Fixed Radio Systems; Characteristics and requirements for point-to-point equipment and antennas; Part 2-2: Digital systems operating in frequency bands where frequency co-ordination is applied; Harmonized EN covering the essential requirements of article 3.2 of the R&TTE Directive".

[7] ETSI EN 302 217-3 V2.2.1 (2014-04): “Fixed Radio Systems; Characteristics and requirements for point-to-point equipment and antennas; Part 3: Equipment operating in frequency bands where both frequency coordinated or uncoordinated deployment might be applied; Harmonized EN covering the essential requirements of article 3.2 of the R&TTE Directive”.

[8] ECC/REC(05)07: “Radio Frequency Channel Arrangements For Fixed Service Systems Operating

In The Bands 71-76 GHz And 81-86 GHz”.

[9] ETSI TR 101 506 V1.3.1 (2010-01): “Fixed Radio Systems; Generic definitions, terminology and applicability of essential requirements under the article 3.2 of 1999/05/EC Directive to Fixed Radio Systems”.

[10] ETSI EN 301 126-1 V1.1.2 (1999-09): “Fixed Radio Systems; Conformance testing; Part 1: Point-to-Point equipment - Definitions, general requirements and test procedures”.

[11] ETSI TR 101 036-1 V1.3.1 (2002-08): “Fixed Radio Systems; Generic wordings for standards on DFRS (Digital Fixed Radio Systems) characteristics; Part 1: General aspects and point-to-point equipment parameters”.

Date post:	23-Mar-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

D5.2 Testbed for the system validation - CORDIS · 2017-05-12 · E3NETWORK Deliverable D5.2 Due...

Documents