Design and Implementation of EPON Tester Hardware Platform

Ethernet-based passive optical network (EPON) is an access network technology that combines the advantages of Ethernet and passive optical network (PON). It has the advantages of large capacity, low cost, good support for IP services, mature technology and simple maintenance. It is one of the ideal solutions for realizing FTTx in the future. At present, EPON systems have been widely used in Japan, and many EPON systems have been put into commercial application in my country. In order to successfully apply EPON at low cost and on a large scale, it is not only required that EPON optical line terminals (OLT) and optical network units (ONU) equipment from different manufacturers can communicate with each other, but also that the project acceptance must be completed conveniently and effectively before the EPON network is opened, and convenient maintenance must be performed during the operation of the EPON network. Due to the point-to-multipoint topology of EPON and its corresponding uplink time division multiple access (TDMA) mode, traditional network test equipment cannot directly intervene in the EPON system, and can only perform relevant tests through the EPON user side and network side interfaces. Therefore, it is impossible to monitor the internal operation status of EPON, and it is impossible to test and analyze EPON-related protocols that affect intercommunication. For this purpose, we designed and developed an EPON tester to help operators conduct equipment interoperability testing before EPON networking and project acceptance and network maintenance after networking.

1. System Introduction

EPON uses a single-fiber bidirectional communication method. In order to observe the internal operation of EPON, we accessed the optical fiber between the OLT and the optical distribution network (ODN) backbone fiber.

The X-type optical coupler separates part of the uplink and downlink optical signals to the EPON tester to monitor the uplink and downlink links, as shown in Figure 1.

Figure 1 How the EPON tester intervenes in the network under test

The EPON tester consists of two parts: a hardware platform and a matching software console. The hardware platform is responsible for the collection and processing of EPON protocol frames and related data, as well as communication with the software console. The software console is responsible for EPON related protocol analysis, providing a user interface, and configuration management of the hardware platform. This article focuses on the design and implementation of the EPON tester hardware platform.

2. Hardware platform functional requirements analysis

The EPON tester mainly focuses on the EPON reconciliation (RS) sublayer, multi-point MAC control (MPCP) sublayer and operation management and maintenance (OAM) sublayer that affect EPON intercommunication and operation and maintenance. The RS sublayer defines the preamble format of EPON. It introduces the logical link identifier (LLID) based on the original Ethernet preamble to distinguish the logical connection between OLT and each ONU, and adds an 8-bit cyclic redundancy check (CRC8) to the preamble; the MPCP sublayer is responsible for the registration of ONU to OLT, the operation of the TDMA mechanism in the upstream direction, etc.; the OAM sublayer is responsible for the functions related to EPON network operation and maintenance. The EPON reference model is shown in Figure 2.

Figure 2 EPON reference model

The main functions of the EPON tester are twofold: helping to discover the reasons that affect intercommunication and facilitating the management and maintenance of the EPON network. The former function mainly refers to the fact that it can help analyze whether the ONU registration process complies with the standards, whether there are problems with the interaction of upper-layer OAM messages and service intercommunication after successful registration, etc. The latter function mainly refers to the fact that it can provide network maintenance personnel with basic information of online ONUs and statistical data of link parameters to facilitate operators' management of the network and fault location.

According to the functional requirements of the EPON tester and our functional division of the EPON tester hardware platform and software console, the functional requirements of the EPON tester hardware platform are determined as follows:

(1) Extract the frames involved in the ONU registration process.

(2) Collect non-registration process MPCP frames and OAM frames according to the configured filtering conditions. In view of the characteristics of EPON, the filtering conditions can be LLID, a user-defined 6-byte long keyword in the first 64 bytes of the frame, or an "and/or" combination of the two. Considering factors such as protocol frame traffic, encapsulation overhead before sending to the software console, rate limit of the console interface, and implementation complexity, a maximum of 64 LLID filtering conditions and two groups of user-defined keywords are supported, and the keywords support bit-accurate mask configuration.

(3) Add a local clock tag to the collected EPON protocol frames (MPCP/OAM frames) and indicate whether they are from the EPON uplink or downlink.

(4) EPON preamble check error rate statistics, supporting the configuration of statistics enable and statistical data reporting period.

(5) Based on a maximum of 256 LLIDs, the service flow and frame check sequence (FCS) check results of EPON frames with correct preambles are counted, and the configuration of statistics enable and statistical data reporting period is supported.

(6) The collected EPON protocol frames and statistical information are encapsulated into Ethernet frames and sent to the software console for analysis through the 100M Ethernet interface.

(7) The configuration content of the hardware platform is issued by the software console through the 100M interface. The configuration content includes the filtering conditions of the EPON protocol frame, the enabling and reporting period of the link statistics items, the source address/destination address/type (DA/SA/type) fields when the EPON protocol frame and statistical information are encapsulated into the Ethernet frame, etc. The hardware platform should support returning the configuration confirmation frame to the software console. [page]

3. Design and implementation of hardware platform

3.1 Overall hardware structure

The composition of the EPON tester hardware platform is shown in Figure 3:

Figure 3 EPON tester hardware platform block diagram

The optical receiving module uses an EPON optical transceiver module that complies with the 1000Base-PX optical interface requirements of the IEEE 802.3ah specification, but only the optical receiving part is used. The Gigabit Ethernet transceiver chip uses a commercial chip, which completes the bit synchronization and serial/parallel conversion functions, and then outputs the parallel data through a 10-bit interface (TBI) to the EPON tester core function field programmable gate array (FPGA) for processing.

The core function FPGA completes the core processing functions of the underlying hardware platform, including the collection of EPON protocol frames, EPON link parameter statistics and user configuration. Considering the resource requirements, scalability and low cost requirements of these functions on FPGA, we chose Altera's Stratix series chips.

The 100M physical layer (PHY) chip used is VT6108S, which realizes the interface function between the core function FPGA and the software console. Since the peak rate of the core function FPGA data acquisition can reach a gigabit rate, but the output to the console is only a 100M rate, an external static memory (SRAM) is used to cache the output data.

3.2 FPGA Design of Core Functions

3.2.1 Collection of EPON protocol frames

Figure 4 is a block diagram of the uplink/downlink protocol frame acquisition. The Gigabit transceiver chip sends the EPON uplink/downlink data to the core function FPGA through the TBI interface. The FPGA synchronizes the received data to the 125 MH internal FPGA in an asynchronous first-in first-out (FIFO) manner.

The z clock is then decoded into 8B/10B, converted into data in Gigabit Media Independent Interface (GMII) format, and each frame is restored.

Figure 4 Uplink/downlink protocol frame acquisition block diagram

After the EPON preamble check and FCS check, the wrong frame will be discarded. Since the type field of the MPCP frame is 0x8808 and the type field of the OAM frame is 0x8809, the frame classification module selects the MPCP/OAM frame and sends it to the filtering module.

The filter module includes a registration process extraction module and a user-defined filter module. The registration process extraction module can filter out all registration process frames according to LLID and the type/opcode field in the frame, and send the remaining frames to the user-defined filter module. The user-defined filter module supports filtering by LLID, or filtering by user-defined fields in the frame, or filtering by the "and/or" combination of the two filtering conditions. For specific parameters, see the hardware platform function requirements analysis.

Since the interface between the hardware platform and the software console is a 100M Ethernet port, the collected EPON protocol frames (including EPON preamble) need to be encapsulated into Ethernet frames before being output to the software console. The original information of the EPON protocol frames should be reflected as much as possible during encapsulation, such as the acquisition time, whether it comes from the EPON upstream or downstream direction, etc. These are marked in the timestamp field and the flag field respectively. In addition, considering that the length of the EPON frame after encapsulation into the Ethernet frame may exceed the maximum transmission unit (MTU) of the Ethernet, the EPON protocol frame with a length greater than 1490 bytes will be divided into 2 segments for encapsulation, and the information about the segmentation is also included in the flag field. The encapsulation format is shown in Figure 5. The subtype field indicates that the payload part of the Ethernet frame is the EPON protocol frame. [page]

Figure 5 EPON protocol frame encapsulation

3.2.2 EPON Link Parameter Statistics

We have reported statistics on the three most critical types of information that reflect EPON link performance: the error rate of the EPON preamble CRC8 check, the FCS check error rate of the frames corresponding to each LLID, and the service flow information corresponding to each LLID.

Based on the different levels of attention users pay to several types of statistical data, the underlying layer supports enabling and reporting cycle control of various types of statistics. When the reporting cycle arrives, the statistical information will be packaged and output. In order to still perform statistics when data is output, we use two sets of statistical modules. When one set needs to output statistical information, it switches to the other set for parameter statistics.

In EPON, OAM messages are all carried in the format of TLV (Type Length Value), and then encapsulated into the data field of the OAM frame. This format makes OAM messages highly extensible. Here, we borrowed the encapsulation method of EPON OAM frames. The statistical data will first be encapsulated into a TLV. The type field in the TLV header indicates which type of statistical information the TLV carries, and the length field indicates the length of the TLV. When encapsulating the TLV into the Ethernet frame, the subtype field is still used to identify the payload part of the Ethernet frame as statistical information, and the flag field is reserved. The encapsulation format is shown in Figure 6.

Figure 6 Encapsulation format of statistical information

3.2.3 Configuration parsing

Various configuration messages from the software console are processed by the configuration parsing module and sent to the corresponding module. The user-configurable content includes the filtering conditions of the EPON protocol frame, the enablement and reporting period of each link statistics item, and the DA/SA/type field when the data is encapsulated into the Ethernet frame.

Considering the reliability of the communication line with the software console, when the configuration parsing module receives a configuration message without errors, it will generate a confirmation frame containing the configuration message number and the configuration effective time to inform the console. The format is similar to the statistical frame.

3.2.4 Output Control

It dispatches the collected upstream and downstream EPON protocol frames, statistical information frames, configuration confirmation frames and other data to the external SRAM, and then controls them to be output to the 100M port, which is achieved by reading and writing the external SRAM.

The external memory we use is a pipelined type zero bus change (ZBT) SRAM, which does not require any waiting cycles for switching between read and write operations, so the bus utilization rate can reach 100%. The data interface width of SRAM is 36 bits, and the width of each data channel to be written into SRAM is 9 bits (8 bits of data + 1 bit of frame envelope information). In this way, each data channel can write 36 bits of width data to SRAM once every 4 clocks to achieve line-speed storage. For this purpose, SRAM is divided into 3 independent storage areas, and the read and write time slots are allocated as follows: the first clock cycle can write EPON upstream protocol frames to SRAM storage area 1, the second clock cycle can write EPON downstream protocol frames to SRAM storage area 2, the third clock cycle can write statistical information frames and configuration confirmation frames to SRAM storage area 3, and the fourth clock cycle can read data from SRAM. After reading a complete frame from a certain storage area, it switches to reading another storage area.

3.3 Test Results

We conducted actual tests on the EPON system of Beijing Greenwell Technology Development Co., Ltd. The EPON tester developed by us can extract all frames involved in the ONU registration process; when receiving the filter conditions configured by the console, it will return a confirmation message to the console, and then extract specific MPCP/OAM frames according to the configured filter conditions;

Statistics can be collected for one or all of the link parameters, and the reporting period of each type of statistical data can be independently configured; all data sent to the console are encapsulated into Ethernet frames according to the set format. In addition, we have also tested the parameters supported by the EPON tester hardware platform. The test results show that all functions and performance indicators are in line with the design requirements.

4. Conclusion

This paper explains the significance of researching and developing EPON tester, briefly describes its functional structure, and focuses on the FPGA design and implementation of its hardware platform. EPON tester can effectively help network operators to conduct equipment interoperability testing, project acceptance and network operation and maintenance.