The need for comprehensive device testing in XGS-PON

In the VECTOR TECHNOLOGIES test laboratory, we tested an upstream Drop Precedence with DEI bit in XGS-PON ONT. During this testing process, we identified a phenomenon that required reporting to the ONT manufacturer for resolution.

See also our previous case study

Prioritizing certain types of traffic helps ensure that critical data gets preferential treatment, maintaining a more consistent and reliable user experience even in times of network congestion. It allows the OLT to intelligently allocate resources based on the importance of different types of data, mitigating the impact of congestion on essential services.

XGS-PON test description

In this XGS-PON test of ONT, we investigated priority mechanisms in the network congestion scenario arising from duplicated frames.

The network faced an exceeding surge in traffic, leading to the activation of a packet-dropping mechanism designed for prioritization.

However, despite setting priorities, the prioritization mechanism did not behave as anticipated. Rather than selectively discarding lower-priority packets, the device treated all packets uniformly during congestion. This uniform treatment jeopardized the quality of higher-priority services, potentially causing service failures.

In this case study, you’ll find a detailed test scenario and the analysis of results conducted in our laboratory. Let’s get started!

Setting the XGS-PON test environment

The test aimed to verify that only frames marked with Drop Precedence were dropped on the R/S interface when the link was overloaded. The test was performed for the upstream traffic, and the value of the DEI field in the VLAN header determined the Drop Precedence.

For this purpose, we’ve set the test environment consisting of the following configuration:

We started the test procedure by configuring ONT over OMCI, which configured an upstream queue and associated T-CONT.

We configured output settings for the ONT queues as follows:

  • Drop priority indication = DEI (see the table below),
  • yellow thresholds set to half queue size,
  • green thresholds set to queue size.

The available bandwidth was 1Gb/s, with Stream A and Stream B being sent at 700Mb/s throughput. Generated unicast frames on the U interface had the following parameters:

We checked the transmission of Ethernet frames for the upstream, according to the table below, showing the expected values on the R/S interface:

Pass/fail criteria for XGS-PON testing

To assess the upstream Drop Precedence for XGS-PON test results, we’ve established two Pass/Fail criteria:

  1. No OMCI Command processing error – all sent OMCI commands are correctly processed by ONT,
  2. Verify on the R/S interface that the achieved throughput equals 300 Mb/s for Stream A and 700Mb/s for Stream B.

Primarily, we scrutinized the ONT setup using OMCI to confirm the flawless execution of all dispatched commands since any malfunction at this phase would make any subsequent testing futile.

The pass/fail criteria allowed us to verify the visibility of the two streams, namely A and B. We generated unicast frames from streams A and B with specified DEI and designated throughput. We expected to receive two streams of 700Mb/s each on the U interface and, respectively, 300 and 700 Mb/s on interface R/S for streams A and B.

XGS-PON ONT’s testing setup

We set the configuration of the internal MAC bridge on the ONT to allow transparent pass-through transmission of frames in the upstream direction. Priority management, crucial for efficient traffic handling, was orchestrated based on the DEI value.

The Priority Queue system came into play, managing priorities by assessing the DEI values assigned to frames. Using predefined thresholds that describe the minimum and maximum values of queue/link load, the Priority Queue effectively controls the dropping of frames marked as drop eligible (DE) in the event of network overload.

During our test, Stream A, characterized by a VLAN header with a DEI value of 1, was marked as drop eligible (DE). This designation implies that it can be subjected to dropping when the network load surpasses the defined thresholds.

Below we presented the chosen OMCI messages flow between the tested devices:

Each of these messages concluded with the status ‘Success,’ indicating flawless ONT configuration and error-free communication via OMCI. At this testing stage, there were no errors to report.

The device configuration via the OMCI protocol was fully correct, resulting in a logical ONT configuration, presented in a simplified form, with its essential elements in the figure below:

The XGS-PON test outcome

This seemingly straightforward XGS-PON test, aimed at assessing the fundamental functionality of the ONT, presented results significantly divergent from our expectations.

The results, evaluated based on the adopted criteria, indicate the success of the first test. We encountered an error during the second criterion: ‘Verify on the R/S interface that the achieved throughput equals 300 Mb/s for Stream A and 700Mb/s for Stream B’.

Breaking down the Fail result

Despite seeing Stream A and Stream B on the R/S interface proving the correct device configuration via OMCI, we couldn’t observe drop precedence according to the DEI field. Both streams, A and B were partially dropped and as a result, the throughput on the R/S interface was 500 Mbps per stream.

Analysis of the configuration sent to the ONT allowed us to find the Manage Entity (ME) that COULD be responsible for this behavior: Priority Queue.

According to the ONU Management and Control Interface (OMCI) specification (ITU-T G.988 11/2022), this ME manages frame priorities in PON networks in both US and DS directions. This ME contains several key attributes responsible for, among other things, setting the appropriate thresholds or maximum queue size. However, the key attribute in our case is ‘Drop precedence colour marking,’ which determines how incoming frames are dropped.

This attribute is presented in the table below presenting ME field:

The test outcome summary

The crux of the issue lies in the Drop Precedence mechanism, where lower-priority packets should be dropped to prioritize higher-priority ones. The identified value of the ‘Drop Precedence Colour Marking’ in the key field aligned with standard specifications. However, the ONT under test deviated from this specified value, and we observed a lack of drop precedence following the DEI field.

Fortunately, we identified the issue at the testing stage in our laboratory. Neglecting to resolve this problem could overload the end-user’s network with frames lacking priority, consequently displacing those with higher priority. Such a scenario could significantly impact the Quality of Service for the end-user.

Addressing this discrepancy, we promptly communicated the issue to both the ONT manufacturer and the operator. Ongoing efforts and discussions with all involved parties are currently underway.