Each FTTH network operator provides its service based on a slightly different model. Regardless of the specific model in use, each relies on the parameters of p-bit fields and VLAN numbers as the fundamental criteria for the classification and prioritization of traffic sent to and from the end user.
The validation of a new device in the network or the confirmation of functionality during firmware changes should follow a systematic process. This approach needs to be reiterated multiple times throughout the product and service lifecycle.
Not surprisingly, operators seeking to introduce a new product to the marketplace need support to complete the validation process, as they are overwhelmed by the rules and validation requirements.
In VECTOR TECHNOLOGIES laboratory, we conducted a multicast pass-through test on XGS-PON ONT. During this testing process, we identified a problem that required reporting to the manufacturer for resolution.
The OMCI test yielded success, affirming the accuracy of the entered values in the Manage Entity (ME), what suggested that ONT should operate according to the G.9807.1 ITU-T recommendation. However, despite these positive results, operational issues persisted.
The next step involved the ONT supplier addressing and identifying the specific misconfiguration causing the discrepancy.
The highlighted problem is just one of many that may become apparent throughout the process, each carrying equal or even greater significance from the operator’s perspective.
In this case study, you’ll find a detailed test scenario and the analysis of results conducted in our laboratory. Let’s dive in!
The test aims to check whether the ONT transparently passes traffic without changing key fields such as the p-bit value and VLAN number. For this purpose, we’ve set the basic test environment consisting of the following configuration:
We started the test procedure by configuring ONT over OMCI, to provide a transparent pass-through of Ethernet frames through the terminal ONT. Next, we’ve generated a multicast frame on the ‘V’ interface. Similarly, the ‘join message’ has been generated on the ‘U’ interface, with the following parameters:
At this stage, we have verified the correct transmission of Ethernet frames for downstream and upstream and ensured that the received data aligns with our expectations.
It is crucial that the ONT does not alter any information within these frames. The join message on the ‘U’ interface should be exactly the same as on the ‘R/S’ interface, both in the upstream and downstream, as outlined in the tables below:
Pass/fail criteria
To assess the multicast pass-through test results, we’ve established the criteria. First of all, we checked the ONT configuration over OMCI to ensure the success of all commands sent, as any failure at this stage would render further testing pointless in this case. The next criteria concern the comparison of two frames: ‘join message’ and ‘multicast traffic’.
For this multicast pass-through test, we’ve established 3 Pass/Fail criteria:
As the test required the GEM ports to be configured to support multicast traffic, OLT used the OMCI protocol to create a bidirectional GEM port (ID 1210) for IGMP messages and unidirectional multicast GEM port (ID 1220) for multicast Ethernet frames.
The internal MAC bridge on the ONT was configured to pass frames transparently in both downstream and upstream directions, allowing pass-through transmission without any modification or translation.
OMCI messages and ONT logical configuration
As an introduction to the first evaluation criterion, ‘No OMCI Command processing error – all sent OMCI commands are correctly processed by ONT’ we presented the OMCI messages designed to configure the ONT for seamless traffic passthrough. The figure below presents the chosen key OMCI messages flow between the tested devices.
Each of these messages concludes with the status ‘Success,’ indicating flawless ONT configuration and error-free communication via OMCI. At this testing stage, there are no errors to report.
The device configuration via the OMCI protocol is fully correct, resulting in a logical ONT configuration, presented in a simplified form, with its essential elements in the figure below:
This seemingly straightforward 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 posistive result (pass) of the first two tests. However, an error was encountered during the last criterion: ‘Multicast traffic is received on the U interface, with the correct p-bit (1) and VLAN value.
Breaking down the Fail result
To examine the reasons for the test failure, we conducted an analysis revealing the duplication of Ethernet frames on the ‘U’ interface. These frames were initially transmitted from the Traffic Generator in the downstream direction.
For each Ethernet frame sent from the traffic generator, the ONT transmitted two frames to the user – one valid, with p-bit set correctly (value 1), and one invalid, with p-bit set to 0.
Analysis of the configuration sent to the ONT allowed us to find the Manage Entity (ME) that COULD be responsible for this behaviour: ‘Extended VLAN tagging operation configuration data’.
According to the ONU Management and Control Interface (OMCI) specification (ITU-T G.988 11/2022), this ME organizes data associated with VLAN classification and tagging operation on the Ethernet Port of the ONT. A key attribute of this element is ‘Received frame VLAN tagging operation table’ that filters, tags, and changes the p-bit of frames. This attribute is presented in the original specification as ‘N/A’ (Not Applicated).
The test outcome summary
The identified key field, ‘Received frame VLAN tagging operation table,’ adheres to standard specifications. However, the tested ONT exhibits anomalous behaviour in downstream traffic.
The issue has been promptly communicated to the ONT manufacturer and the operator. Ongoing works and discussions with all involved parties are in progress.
From the operator’s standpoint, the potential risk involves data overloading the end-user’s network due to the introduction of duplicate frames into the user’s space. This could lead to misinterpretations by network devices, emphasizing the urgency of addressing and resolving the observed discrepancy.
