Share this

EPON equipment test analysis

2026-04-06 05:16:57 · · #1

Abstract: EPON equipment represents a new development direction for access networks. This paper, based on the 7342EPON system, tests and analyzes the functional modules of the EPON system from an architectural perspective. Finally, it points out that considering multiple perspectives is crucial to ensure that a product truly meets customer needs.

Keywords: High-speed internet service, robustness, load testing, logical link

With the rapid development of the Internet, network users' demand for network bandwidth is increasing day by day. In order to meet market needs, the backbone of the communication network has undergone tremendous changes, while the traditional access network, which has remained relatively unchanged, has become the bottleneck of the entire network, and various new broadband access technologies have become a hot research topic.

Compared to other broadband technologies, PON not only has advantages in investment and maintenance costs, reliability, quality, and management, but also greater development potential (PONB benefits: CapEx, OpEx, Reliability, QoS, Management, Futureproof). EPON (Ethernet Passive Optical Network) is a new type of fiber optic access network technology. It adopts a point-to-multipoint structure and passive fiber transmission, providing various services over Ethernet. It uses PON technology at the physical layer and Ethernet protocol at the link layer, utilizing the PON topology to achieve Ethernet access. Therefore, it combines the advantages of both PON and Ethernet technologies: low cost; high bandwidth; strong scalability; flexible and rapid service reconfiguration; compatibility with existing Ethernet; and convenient management. All of this makes PON products technically commercially viable.

On the other hand, market forces are also at play. Especially in recent years, with the decline in the cost of related components, commercial deployment of PON has become possible. Currently, in North America and Europe, Alcatel-Lucent already has a considerable GPON user base, making it the market leader. However, in China, EPON, due to its relatively lower price, is more favored by the market. 2009 will be the year PON takes off in the Chinese market, with cost being the most crucial market driver. Guided by the "fiber-to-the-home" strategy, Chinese operators are striving to reduce their investment in DSL equipment. For Alcatel-Lucent's optical access R&D team, the current mission is to optimize GPON products and strive to reduce costs, while simultaneously launching EPON products that meet the needs of the Chinese market as soon as possible. Against this backdrop, Alcatel-Lucent's 7342EPON product emerged.

Figure 1 shows the EPON architecture. The entire EPON system consists of three parts: NT, LT, and ONU. The ONU is connected to the PON port of the OLT, and the NT part consists of two NT boards, forming redundancy protection for the system.

Figure 2 shows the structure of the OLT, and the data path on the OLT is as follows:

Uplink data is transmitted from the ONU to the logical link, then from the logical link to the EPON chip, and finally to the switch. It is then transmitted through the 10G channel via the backplane to the uplink port of the NT board LANX in Figure 1. Downlink user data is transmitted in the reverse direction.

As can be seen from the structural diagram, the EPON system consists of three parts: NT, OLT, and ONU. Its testing primarily involves these three parts. Since the NT board of the EPON system is the same as that of the GPON system, and is a mature product, the number of test points is limited. EPON system testing mainly focuses on two parts: testing the OLT board and the interoperability management between the OLT and ONU. The OLT part is the key focus of the entire testing process.

OLT testing is divided into HIS service components, multicast service components, protocol components, device and software management, robustness testing, and load testing. Among these, the HIS service is the core of the entire system and the foundation for all implementable applications, therefore its testing scope is the broadest. This mainly includes the OLT's forwarding behavior under different VLAN modes (CC, RB, stack-CC, and stack-RB), VLAN traversal, VLAN 1:1 or n:1 translation, application of access control lists and classification lists, QoS, and system configuration capacity. Multicast services should be considered value-added services, and their testing involves the following aspects: multicast parameter management, multicast behavior under different VLAN modes, multicast forwarding parameter statistics, and system multicast performance parameters. The protocol testing primarily focuses on the system behavior of three protocols: DHCP, PPPoE, and ARP. The protocol testing itself is relatively mature; theoretically, as long as the protocol stack functions correctly, protocol testing should not present significant issues. However, because the protocols themselves involve processing modes under different VLAN models, protocol transmission is essentially part of the VLAN forwarding mode. Furthermore, the protocol data channel differs from the general user data channel, resulting in unique characteristics in protocol traffic processing. Protocol testing includes the implementation features of the protocol itself, protocol processing under different VLAN modes, system protocol processing performance, and capacity. Therefore, protocol testing also becomes a primary indicator of the EPON device management data path testing, and a crucial measure of the onboard CPU's load capacity. Equipment testing primarily involves OLT configuration management, including extensive and repeated configuration, deletion, querying, and restarting of boards in all slots of the chassis to check if the equipment can respond normally. Software management mainly involves plugging and unplugging the LT and restarting it during software downloads to test the impact of its behavior on the LT's software download. This also includes OLT software upgrades and remote upgrades of terminal ONU software. Robustness testing mainly includes robustness testing at two levels: PON port and the entire LT board. PON port robustness testing involves connecting all ONUs to a single PON and performing various disruptive operations on some of them—deletion, creation, software updates, and restarts—to consider the impact of a single ONU's behavior on other ONUs under the same PON. LT robustness can be considered from two aspects: firstly, never... The test does not involve interfering with a fully loaded LT (Light Transport Unit) on the same side, such as unplugging or plugging in fiber optic cables, restarting, or powering down the LT board and the entire chassis, nor does it test the recovery of user traffic. Instead, it tests the system based on different types of user traffic. For example, sending ARP, DHCP, PPPoE, or IGMP traffic at line speed to one ONU will not affect the user traffic on other ONUs. Irregular LT board plugging and unplugging, excessively long packets, and variable-length packets will also not affect the system. Load testing mainly consists of two parts: throughput testing and stability testing. Throughput testing mainly includes the uplink and downlink throughput of a single PON under different byte lengths and mixed byte lengths, as well as the throughput of the entire LT board under different byte lengths and mixed byte lengths, and the packet loss rate at line speed. Stability testing mainly focuses on the impact of large-volume, long-term user traffic on the system.

It can be seen that in the HIS test, the VLAN bridge implements the most basic model of customer service functions, while CCL provides different priorities for classifying user services based on different conditions. The OLT, based on LLID and SERVICE rate limiting and traffic scheduling, provides concrete execution guarantees for QoS. EPON places greater emphasis on security protection. VLAN CVLAN conversion between the user side and the network side is the first step in security assurance. Existing protocols provide users with IP and partial security authentication protection mechanisms, and verify and protect the load capacity of the onboard OBC to prevent the system from malfunctioning due to attacks from numerous protocols. Access lists restrict system access control, allowing only qualified customers to access the network. These measures greatly improve network access security. Robustness testing, while maintaining user traffic, considers the impact and interference between different operations and different types of traffic, providing another layer of system security protection.

Interoperability management testing between the OLT and ONU includes testing of OLT board port identification and authorization of the ONU, DBA testing of OLT QoS, ONU management configuration testing, ONU network port management configuration testing, ONU uplink traffic QoS management testing, ONU multicast management testing, and ONU robustness management testing. Among these, OLT PON port identification and authorization of the ONU is the most fundamental prerequisite for OLT-ONU interoperability. From a market operation perspective, wireline operators will procure OLTs and ONUs separately. This will significantly reduce operating costs, accelerate competition among telecom equipment providers, prevent a single company from dominating the market, and avoid market monopolies. Interoperability is a key advantage. From a technical perspective, configuring devices from different brands on the same network provides a secure backup for network services, preventing service interruptions caused by a single product's defect. Therefore, interoperability management testing between the OLT and ONU is crucial in practice, and the OLT board's PON port's identification and authorization of ONUs is a prerequisite for interconnectivity. This includes identifying the accessed ONUs under PON; only configured ONUs can be registered. There are three ONU authorization modes: one is authorization based on the ONU's MAC address, the second is authorization based on serial number plus password, and the third is a hybrid authorization mode combining these two methods. The configuration management of the ONU includes creating, modifying, querying, and deleting ONUs on the OLT via command line; restoring the ONU configuration under different conditions such as restart, plugging/unplugging, and power failure; and creating voice channels on the ONU to achieve basic call functions. The management of the ONU's network ports includes port creation, configuring port auto-negotiation and flow control via TL1, and the forwarding behavior of untag-frame, priority-frame, and tagged-frame packets in transparent, VLAN-tagged, and VLAN-switching modes on the port, as well as achieving the maximum VLAN switching ratio on the ONU port. The DBA test of the OLT's QoS is based on... The system implements fixed bandwidth, guaranteed bandwidth, best-effort bandwidth, and combinations of these three bandwidth modes using LLID. ONU multicast management testing includes verifying that the ONU supports both CTC and Snooping modes, and supports enabling and disabling the fastleave function. It also supports configuring downlink multicast VLAN tag removal and retention, and verifies the ONU's characteristics under different multicast modes: for example, in CTC mode, the maximum number of multicast groups can be configured and effective based on the UNI and control channel, while in Snooping mode, this parameter only takes effect when configured on the UNI. ONT QoS testing mainly includes rate limiting of the ONT and service classification on the ONU. The system supports uplink traffic rate limiting via the OLT on the ONU's UNI port; when uplink congestion occurs, a pause frame can be triggered to rate limit the sending end. Traffic classification on ONU ports can be based on several factors, including ONU UNI port, VLAN, user traffic priority, user IP, user MAC, and user source port of Layer 4 traffic. This allows for the classification and prioritization of user traffic service levels. This enables QoS control of user traffic on the ONU. Additionally, ONU robustness testing is conducted, including determining the range of received optical power fluctuations under stable operating conditions, determining the total throughput of data and voice on the ONU, and verifying that the ONU can maintain 72 hours of error-free performance under sustained user traffic conditions. Under high load, unplugging and plugging fiber optic cables, restarting the ONU, or powering it off should restore the ONU's state and the load traffic. The test also examines whether unplugging and plugging fiber optic cables from multiple ONUs connected to a single PON port will cause mutual interference between ONUs, and tests the robustness of the 32-ONU network. When multiple ONUs simultaneously power off and restart, can the ONUs recover? Or, when upgrading or downgrading ONU software, can the energy of the ONU and its load users be restored? This also includes whether the ONU voice management interface can function via UNI or PON when each ONU has its own IP address and shares the same IP address. It's clear that the most prominent feature of testing the OLT and interconnecting ONUs is consistency. After all, many of our operations on the ONU are performed on the OLT and then distributed to the ONU via the OLT, rather than directly on the ONU. Therefore, consistency testing is the most crucial aspect at this stage.

Different roles within the same product may have different focuses when it comes to system testing.

From a product inspection perspective, the entire EPON testing process needs to focus on three aspects: First, whether the configuration is accurately distributed, i.e., the consistency issue; second, given accurate configuration, whether the functionality is implemented, i.e., the accuracy issue; and third, given functional implementation, whether the system is stable, i.e., the stability issue. If these three aspects can be satisfactorily resolved, the resulting system should be a completely acceptable system.

The consistency discussed here differs slightly from that mentioned in ONU testing. It has a broader scope and is primarily based on system-level considerations. Consistency verification mainly focuses on the consistency of data across three aspects: the management plane, the application plane, and HWwrappers. Management plane data is configuration data issued through TL1, network management systems, etc. The application plane uses this network management data to operate and call applications at the application layer; theoretically, it should be consistent with the management data. HWwrappers is a special data layer located above the HW, allowing for specific register-level HW operations. In EPON testing, we encountered a problem where most inconsistencies occurred between the management plane and HWwrappers, while the application plane and management plane data remained largely consistent. So far, we haven't encountered any discrepancies between the two. For example:

On a fully configured HIS service, uplink and downlink traffic could not be transmitted. After checking all management configurations and finding them to be correct, LTtrace revealed that a piece of data in HWwrappers was inconsistent with the configuration issued by the management.

-------------------------------UserInterfaceInformation:Begin------

-----------------------

PON0-ONU19-LLID0

LLIDMAC:00:1e:40:7a:ff:ab

CVLAN:220

ServiceMode: RawService

ACLActionMode:Pass

MaxService:0x01

MaxStaticACL:0x00

MaxDynamicACL:0x00

MaxCCL:0x00

DestinationID:1063

NumberofServices:0 ------- Problem

Number of StaticACLs: 0

Number of DynamicACLs: 0

CCSVLAN:220

SVLANType:8

NetCVLAN:220

NetPbit:0

We can see from this trace information that the following issue is reflected: no services have been created under the twentieth ONUCVLANINTERFACE220 connected to the first PON port (Number of Services: 0), but related services have been created on the management plane.

rtrv-eoltflow::all*/

"OLTFLOW-1-1-1-1-20-0-220-1::FLOWVAL=\"0000\",CVLAN=220,SVLAN=220,CVLANPBIT=7,

DNBWPORF=1,DNSLALVL=3

This is the so-called consistency problem, which is a major headache in testing and the most common problem to encounter. Locating the issue is relatively difficult and requires test engineers to have a clear understanding of the entire system. This test is very important and is the cornerstone of subsequent testing.

Accuracy is relatively easy to understand. As long as the required functions can be implemented under the premise of data consistency, it can be guaranteed. This problem is relatively easier to identify and locate than consistency problems. As long as the functional behavior is clearly defined in advance, if a discrepancy is found, it can be determined as follows:

With VLAN mode set to STACKRB and DHCPrelay enabled, the system's uplink port is connected to a DHCP server, and the ONU is connected to a PC. Attempts to obtain an IP address via DHCP consistently fail. Packet captures at both ends reveal that while the server receives the user's request, its response is not being sent to the client. Therefore, a downlink protocol packet is manually constructed and sent in burst mode.

Counter before sending: Received Octets: 23980 Unicast Packets: 298 Non Unicast Packets: 1 Discarded Packets: 53 Error Packets: 0 Unknown Protocol: 0 Transmitted Octets: 14969176 Unicast Packets: 308 Non Unicast Packets: 10739 Discarded Packets: 0 Error Packets: 0 Counter after sending: Received Octets: 24044 Unicast Packets: 299 Non Unicast Packets: 1 Discarded Packets: 53 Error Packets: 0 Unknown Protocol: 0 Transmitted Octets: 15005152 Unicast Packets: 409 Non Unicast Packets: 10747 Discarded Packets: 0 Error Packets: 0

It can be seen that the downlink protocol packets have been sent to the LT board, but they are being discarded on the LT. Previously, packets with a single VLAN tag could obtain IP addresses normally. Therefore, the problem was likely caused by the dual VLAN tagging process. After investigation, enabling the STACKVLAN function on the switching chip in Figure 2 resolved the issue. Accuracy problems often stem from bugs in the application itself.

Stability is perhaps the most pressing concern. This includes not only maintaining low packet loss and error rates under prolonged high-traffic conditions, but also the system's robustness under extreme operating conditions. This is a fundamental condition for providing long-term stable service to customers. Stability testing often addresses deeply hidden system issues caused by system bugs or hardware chip bugs. For example:

A fully loaded PON port has 32 ONUs connected to it, transmitting 90% of the traffic. The system's transmission and reception are normal. However, repeated plugging and unplugging of the optical modules on this PON port may disable some logical links, causing some user traffic to be interrupted, as shown below:

3c00 Reserved 0 (0,0) 0 000db6417000 no Comp

OAM: CTC Tek

3c01 SlaDisabled 1 (0,0) 0 001fa3582ccb no TK

OAM: CTC Tek

3c02 InService 2 (0,0) 0 001fa3582c26 no TK

OAM: CTC Tek

3c03 InService 3 (0,0) 0 001fa3582c08 no TK

OAM: CTC Tek

3c04 SlaDisabled 4 (0,0) 0 001fa3582c80 no TK

OAM: CTC Tek

3c05 SlaDisabled 5 (0,0) 0 001fa3582bfe no TK

OAM: CTC Tek

3c06 InService 6 (0,0) 0 001fa3582c8a no TK

OAM: CTC Tek

3c07 InService 7 (0,0) 0 001fa3582c5d no TK

OAM: CTC Tek

3c08 InService 8 (0,0) 0 001fa3582b68 no TK

OAM: CTC Tek

3c09 InService 9 (0,0) 0 001fa3582c99 no TK

OAM: CTC Tek

3c0a InService 10 (0,0) 0 001fa3582b9f no TK

OAM: CTC Tek

3c0b InService 11 (0,0) 0 001fa3582c58 no TK

OAM: CTC Tek

3c0c SlaDisabled 12 (0,0) 0 001fa3582b54 no TK

OAM: CTC Tek

3c0d InService 13 (0,0) 0 001ee3006eeb no TK

OAM: CTC Tek

3c0e InService 14 (0,0) 0 001fa3582b40 no TK

OAM: CTC Tek

3c0f SlaDisabled 15 (0,0) 0 001ee3006f13 no TK

OAM: CTC Tek

3c10 SlaDisabled 16 (0,0) 0 001fa3582c2b no TK

OAM: CTC Tek

3c11 InService 17 (0,0) 0 001fa3582b6d no TK

OAM: CTC Tek

3c12 InService 18 (0,0) 0 001fa3582ba9 no TK

OAM: CTC Tek

3c13 InService 19 (0,0) 0 001fa3582c30 no TK

OAM: CTC Tek

3c14 InService 20 (0,0) 0 001fa3582cee no TK

OAM: CTC Tek

3c15 InService 21 (0,0) 0 001fa3582c21 no TK

OAM: CTC Tek

3c16 InService 22 (0,0) 0 001fa3582c9e no TK

OAM: CTC Tek

3c17 SlaDisabled 23 (0,0) 0 001fa3582b5e no TK

OAM: CTC Tek

3c18 SlaDisabled 24 (0,0) 0 001fa3582bbd no TK

OAM: CTC Tek

3c19 SlaDisabled 25 (0,0) 0 001fa3582c49 no TK

OAM: CTC Tek

3c1a SlaDisabled 26 (0,0) 0 001fa3582c71 no TK

OAM: CTC Tek

3c1b SlaDisabled 27 (0,0) 0 001fa3582be0 no TK

OAM: CTC Tek

3c1c SlaDisabled 28 (0,0) 0 001fa3582b1d no TK

OAM: CTC Tek

3c1d SlaDisabled 29 (0,0) 0 001fa3582bb3 no TK

OAM: CTC Tek

3c1e SlaDisabled 30 (0,0) 0 001fa3582bef no TK

OAM: CTC Tek

3c1f InService 31 (0,0) 0 001fa3582b7c no TK

OAM: CTC Tek

3c20 SlaDisabled 32 (0,0) 0 001fa3582b77 no TK

OAM: CTC Tek

7fff InServiceMcast 255 (0,0) 0 ffffffffffff no Comp

OAM: CTC Tek

3e00 Reserved 0 (1,1) 0 000db6417001 no Comp

OAM: CTC Tek

3e01 SlaDisabled 1 (1,1) 1 001ee3006f59 no TK

OAM: CTC Tek

7fff InServiceMcast 255 (1,1) 1 ffffffffffff no Comp

OAM: CTC Tek

The EPON chip trace showed that some logical links were disabled, but the corresponding ONU status was enabled, thus ruling out the ONU status affecting the logical link operation. Manually plugging and unplugging the optical module shouldn't cause problems, but simulating this action with a script revealed that the logical links not only disabled but also experienced lockouts. This issue was ultimately identified as an internal bug in the EPON chip. This is a very typical stability problem.

From a telecom operator's perspective, the focus might be on functional testing, QoS testing, stability testing, ease of use testing, and interoperability testing. Functional testing refers to the operator's commitment to providing certain functional services to customers to attract them to purchase those services; therefore, they must ensure the feasibility of these services within the existing system. QoS testing is easier to understand; telecom operators differentiate between different types of users, setting different service requirements and pricing standards, as this is where their profits lie, hence their focus. Ease of use testing includes both system operability and maintainability testing. Operability refers to a simple and clear system management interface that enables remote management; after all, command lines are only the interface that professionals are accustomed to, and a simple and user-friendly management interface ensures ease of system management and reduces personnel training costs. Maintainability refers to the system's ability to complete remote online upgrades without damaging existing user data. Interoperability testing is a strategy employed by operators to introduce competition, prevent suppliers from monopolizing the market, and thus reduce their own operating costs. Stability testing, as mentioned earlier, will not be elaborated upon further.

It's clear that different roles lead to different perspectives, and different perspectives result in different testing entry points. If all aspects of attention are considered, the product can be quickly accepted by the market, and the testing will achieve its ultimate goal. The testing of EPON equipment takes all these perspectives into account, so successful network access is an inevitable result.

Read next

CATDOLL 135CM Laura

Crafted with attention to detail, this 135cm doll offers a well-balanced and realistic body shape that feels natural in...

Articles 2026-02-22