CN1149794C - Interface device and method for directly adapting Ethernet to physical channel - Google Patents

Abstract

The present invention discloses an interfacing apparatus and method for adapting Ethernet directly to physical channel, which encapsulates MAC frames into SDH/SONET SPE/VC using LAPS. The LAPS encapsulation consists of the start Flag Sequence, address field (SAPI, Service Access Point Identifier), control field (0x03), Information field (Ipv4, Ipv6, or PPP protocol data unit), FCS (Frame check sequence) and the ending Flag Sequence. The Flag Sequence (0x7E) identifies the beginning/end of a LAPS frame. The present invention can be used to provide Ethernet interface in telecom SDH/SONET transmission device or provide facilities to remote access datacom device, such as core and edge routers, switch devices, IP based network accessing equipment, line cards, and interfacing units used in high speed application, e.g. Gigabit applications. By simplification of SDH/SONET, i.e. using simplified SDH/SONET, Ethernet could be applied to DWDM.

Description

Interface device and method for directly adapting Ethernet to physical channel

technical field

The present invention relates to data network and telecommunication network relevant with Internet/Intranet (Internet/intranet) and LAN, relate in particular to the interface device and method that Ethernet directly adapts to physical channel, it provides Ethernet on telecommunication SDH/SONET transmission equipment network interface, or provide remote access data communication equipment such as core and edge routers, switching equipment, IP-based network access equipment, line cards, and interface units used in high-speed applications, such as directly connecting MAC frames with SDH/SONET Adapted function.

Background technique

There is a need to expand Ethernet applications including Ethernet, Fast Ethernet and Gigabit Ethernet. It is a simple and cheap technology to transmit Ethernet (defined by IEEE 802.3 working group) on a telecommunications-based physical channel to connect LAN and Internet/Intranet in private and public networks.

ITU-T G.707 describes the advantages and multiplexing methods of SDH, and specifies a set of SDH bit rates, the general rules and frame structure of the network interface node (NNI), the overall frame size of 9 rows of N×270 columns, and segment overhead and its byte allocation, the international interconnection arrangement of the Synchronous Transport Module (STM), the multiplexing and mapping of elements to the STM-N format in the NNI unit.

In North America, SDH corresponds to SONET. SONET is an American (ANSI) standard for synchronous data transmission on optical media, referred to as synchronous optical network. People develop standards to enable digital networks to achieve international interconnection, and existing transmission systems can take full advantage of the advantages of optical media through branch devices. SONET defines a basic rate of 51.84Mbps and a set of optical carrier levels at multiples of the basic rate. SONET is an octet synchronous multiplexing scheme that defines a series of standard rates and formats. Despite the name Optical Carrier, it is not limited to optical links, but also defines electrical standards for single-mode fiber, multimode fiber, and CATY 75-ohm coaxial cables. The transmission rate is an integer multiple of 51.84Mbps, and it can be used to carry T3/E3 bit synchronization signals. It also strongly recommends adopting E1/E3/E4/T1/E2/T4 interfaces of G.703 as the physical layer of IP-over-SDH/SONET to facilitate users to access via LAN.

Both SDH and SONET provide standards for a range of wire speeds, with a maximum wire speed of 9.953Gbps and a practical maximum possible wire speed of about 20Gbps.

The existing data communication structure combining Ethernet and SDH/SONET uses PPP (Point-to-Point Protocol) and HDLC (High-level Data Link Control), which is specified as RFC1619 in IETF (Internet Engineering Task Force). However, when applying RFC1619 to the combination of Ethernet/Fast Ethernet/Gigabit Ethernet and SDH/SONET, RFC1619 has the following main defects:

(1) There is no unified international standard support for the entire application solution, which makes it difficult to interconnect devices of different manufacturers in private or public networks;

(2) For the rate of 2.5Gb/s and above, the overhead of hardware forwarding is too large, especially for IP over WDM, because RFC1919 recommends the use of LCP (Link Control Protocol) and Magic Number (MagicNumber), both of which It's all very complicated.

(3) When using RFC1619, the default value of the retransmission timer in PPP is 3 seconds, which is too slow for high-speed links. In specific engineering applications, it is required to support the rate range from 2Mb/s (bit/s) to 10000Mb/s (the difference is 4032 times), so the value of the retransmission timer should be determined according to the round-trip delay of the line. However, these are not stipulated in RFC1619, so there will be uncertainty when devices from different manufacturers are interconnected.

(4) LCP has 10 kinds of configuration packets (Configuration Packet), 16 kinds of events (Event) and 12 kinds of actions (action), and more than 130 kinds of protocol states, which makes it difficult to realize optical packet switching between MII and SDH/SONET, And expensive. In order to illustrate the above situation, Table 1 lists the events and actions on the LCP finite state machine (Finite-State Machine) using the usual PPP over SDH/SONET standard.

(5) In IP over SONET/SDH, there is almost no padding field using PPP, but RFC 2615 still maintains the padding field. In addition, the padding field requires the receiving end to be able to distinguish the information field from the padding field defined by the RFC standard, which increases processing overhead.

The most important features of Ethernet over SDH/SONET (EOS) are:

(a) It can be used in both SDH/SONET telecommunication network and data communication network based on Ethernet.

--End-to-end connection of SDH/SONET equipment with long-distance Ethernet interface;

--Ethernet switch with SDH/SONET interface.

(b) Realize splitting/inserting (add/drop) 10/100M Ethernet signals with multi-chips at SDH/SONET terminals.

(c) Line cards available for precursor routers.

Table 1. Events and actions event response Up＝lower layer is UpDown＝lower layer is DownOpen＝administrative OpenClose＝administrative CloseTO+＝Timeout with counter＞0TO-＝Timeout with counter expiredRCR+＝Receive-Configure-Request(Good)RCR-＝Receive-Configure-Request(Bad)RCA =Receive-Configure-AckRCN=Receive-Configure-Nak/RejRTR=Receive-Terminate-RequestRTA=Receive-Terminate-AckRUC=Receive-Unknown-CodeRXJ+=Receive-Code-Reject(permitted) or Receive-Protocol-RejectRXJ-=Receive -Code-Reject (catastrophic) or Receive-Protocol-RejectRXR＝Receive-Echo-Requestor Receive-Echo-Replyor Receive-Discard-Request tlu=This-Layer-Uptld=This-Layer-Downtls=This-Layer-Startedtlf=This-Layer-Finishedirc=Initialize-Restart-Countzrc=Zero-Restart-Countscr=Send-Configure-Requestsca=Send-Configure-Ackscn= Send-Configure-Nak/Rejstr=Send-Terminate-Requeststa=Send-Terminate-Ackscj=Send-Code-Rejectser=Send-Echo-Reply

To sum up, the existing combination scheme of Ethernet and SDH/SONET is complex, difficult to implement, expensive, slow, unstable, and not suitable for high-speed data transmission, especially for gigabit rate applications.

Contents of the invention

Therefore, the main object of the present invention is to propose an improved method and apparatus for providing point-to-point connections between physical layer equipment and network layer equipment such as Ethernet switches and SDH/SONET networks, full duplex, bidirectional simultaneous operation . The invention proposes a new communication mode between the telecom SDH/SONET transmission equipment and the remote access data communication equipment, and directly adapts the MAC frame to the SDH/SONET.

In order to achieve the above and other objects, the present invention provides a data transmission device for transmitting data packets from upper-level equipment to lower-level equipment, including: a first receiving device for receiving data packets from upper-level equipment, and converting the data packets into The first type of frame; the first processing device is used to encapsulate the field and the information field of the data packet indicated by the SAPI identifier into the first type of frame to form a second type of frame; the second processing device is used to encapsulating the frame of the second type into the payload part, and inserting an appropriate overhead corresponding to the data packet to form a frame of the third type; and a first sending means for outputting the frame of the third type to the lower layer device . Wherein, the first processing device encapsulates the second type frame into a frame format including a start flag, a SAPI field containing a SAPI identifier, a control field, an information field including the data packet, an FCS field, and an end flag .

The present invention also provides a data transmission method for transmitting data packets from an upper-layer device to a lower-layer device, comprising the following steps: receiving and buffering data packets from the upper-layer device, adapting the rate of the upper-layer device and the rate of the lower-layer device, and converting the data The packet is converted into a first-type frame; the field and the information field of the data packet indicated by the SAPI identifier are encapsulated into the first-type frame to form a second-type frame; the second-type frame is encapsulated into a payload part, and insert the appropriate overhead of the data packet to form a third type frame; and output the third type frame to the lower layer device. Wherein, the second type of frame is encapsulated into a frame format including a start flag, a SAPI field containing a SAPI identifier, a control field, an information field including the data packet, an FCS field and an end flag.

The present invention also provides a data transmission device for sending a data packet formed by a first type of frame from a lower layer device to an upper layer device, comprising: a second receiving device for receiving a data packet from the lower layer device; a frame parsing device for To remove the overhead from the first type of frame; the third processing means is used to extract the data and SAPI field contained in the information field from the payload part of the first type of frame to form the second type of frame; determine A device for comparing the value of the SAPI field with a preset value, and when the data value of the SAPI field is equal to the set value, determine to output the actually extracted data; the fourth processing device is used for converting the second type of frame into a third type of frame corresponding to the data packet; and second sending means for sending the extracted data packet to the upper layer device. Wherein, each second-type frame includes: a start flag, an address field, a control field, an information field, an FCS field, and an end flag, and the SAPI field is located in the address field.

The present invention also provides a data transmission method for sending a data packet formed by a first-type frame from a lower-layer device to an upper-layer device, comprising the following steps: receiving a data packet from the lower-layer device; removing the data packet from the first-type frame Overhead; extract the SAPI field and the data contained in the information field from the payload part of the first type frame to form the second type frame; compare the value of the SAPI field with a preset value, when the SAPI field data value is equal to the When the value is set, determine to output the actually extracted data; convert the second type frame into a third type frame corresponding to the data packet; and send the extracted data packet to the upper layer device. Wherein, each second-type frame includes: a start flag, an address field, a control field, an information field, an FCS field, and an end flag, and the SAPI field is located in the address field.

The present invention also provides a data packet interface device for sending data packets between upper-layer equipment and lower-layer equipment, including the above-mentioned data transmission device and the above-mentioned data transmission device. The second type of frame is encapsulated into a frame format including a start flag, a SAPI field containing a SAPI identifier, a control field, an information field including the data packet, an FCS field and an end flag. It also includes: a microprocessor interface device for enabling the data interface device to access all registers therein; a JTAG port for testing; and a GPIO register for temporarily buffering input/output configuration data.

Other aspects and advantages of the present invention will become more apparent through the detailed description of the embodiments of the present invention with reference to the accompanying drawings.

Description of drawings

By referring to the following detailed description of the accompanying drawings, it is not difficult to understand the present invention:

Shown in Fig. 1 is the general schematic diagram of Ethernet over LAPS of the present invention, and it provides point-to-point, full-duplex, two-way operation simultaneously, has adopted the relation between Ethernet frame, LAPS and SDH to represent among the figure.

Figure 2 shows the layer/protocol stack of Ethernet over LAPS in STM-N.

Figure 3 shows the layer/protocol stack of Ethernet over LAPS in sSTM.

Fig. 4 is the LAPS frame format of the present invention.

Figure 5 is an exemplary protocol configuration of Etbernet over LAPS.

Fig. 6 is the relationship between the coordination sublayer/MII and LAPS/SDH in Ethernet over LAPS according to the present invention.

FIG. 7 shows an exemplary configuration of functional units implementing Gigabit Ethernet and SDH adaptation in the present invention.

Figure 8 shows the primitive relationship among MAC, LAPS link layer and physical layer.

FIG. 9 shows a block diagram of an Ethernet over SDH/SONET interface device for directly adapting a MAC frame to SDH/SONET or simplifying SDH/SONET according to an embodiment of the present invention.

Figure 10 is a schematic diagram of the IEEE 802.3 Ethernet MAC frame format, in which the format of the LAPS information field is defined in the shaded part.

Figure 11 shows the LAPS frame format after encapsulating the MAC field.

Figure 12A shows an example of the SPE/VC structure of STM-N.

Figure 12B is a schematic diagram of POH for SONET and SDH.

Figure 12C shows a schematic diagram of the structure of STS-3c SPE or VC-4.

FIG. 13 is a detailed block diagram of converter 19 in FIG. 9 .

Figure 14 shows a schematic diagram of an Ethernet Layer 2 switch with 2 EOS ports.

FIG. 15 is a schematic diagram of SDH private network connecting 10BASE-T and 100BASE-T2 layer switches and 1000BASE-x switches with EOS devices according to an embodiment of the present invention.

FIG. 16 is a schematic diagram of an SDH public network connected to an IEEE 802.3 Ethernet layer 3 switch according to an embodiment of the present invention.

Detailed ways

The preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings. In the following description, well-known functions or constructions are not described in detail so as not to obscure the invention in unnecessary detail.

The present invention adapts Ethernet to SDH/SONET or Simplified SDH/SONET network. Connecting Ethernet switches and SDH/SONET networks is a very attractive way to provide Ethernet over WAN. Connecting one or more Ethernet switch ports is transparent to Ethernet.

For the sake of clarity, the abbreviations used in the description and drawings are given below.

AUI Accessory Unit Interface

FCS frame check sequence

GMII Gigabit Media Independent Interface

IPX Internet Packet Exchange

LAPS SDH link access procedures

LAN Local area network

LLC Logical Link Control

MAC Media Access Control

MAU Media Attachment Unit

MDI Media Dependent Interface

MII Media Independent Interface

SDH Synchronous Digital Hierarchy

STM Synchronous Transport Module

sSTM Synchronous transfer module sub-module

VC virtual container

SAPI Service Access Point Identifier

PLS Physical Layer Signaling

PCS Physical Coding Sublayer

PMA Physical Media Attachment

PHY physical layer device

PMD Physical media related

UITS Negative Acknowledgment Information Transfer Service

HDLC Advanced Data Link Control

SPE synchronous payload envelope (envelope)

TCP Transmission Control Protocol

UDP User Datagram Protocol

Fig. 1 is the Ethernet over LAPS overall scheme schematic diagram of the present invention, and it provides point-to-point, full-duplex, two-way operation simultaneously, and it adopts the relation between Ethernet frame, LAPS and SDH to describe.

As shown in Figure 1, LAPS is used between the 802.3 (802.3u/802.3z represent Ethernet/Fast Ethernet/Gigabit Ethernet) link layer and the MAC sublayer, and the physical layer is defined as including various high-order and For SDH of low-order VC, the second layer consists of three sublayers: LLC/MAC/LAPS. LAPS is a typical HDLC, including data link services and protocol specifications, which have been used for IPover SDH using LAPS.

In this structure, there is only one access point provided by the LAPS link layer to the MAC sublayer for Ethernet/Fast Ethernet/Gigabit Ethernet MAC frames. For example, the SAPI is "28 (decimal)". The entire MAC frame at the MAC sublayer, when transmitted, is mapped to the LAPS link layer as parameters of primitives. At the LAPS sublayer, consider mapped MAC frames as LAPS information fields without changing their size and sequence (it includes destination address, source address, length/type, MAC client data, PAD field (if any) and the FCS field of the complete MAC frame). The LAPS link layer is adapted to the UITS, and uses primitives and parameters to interact with the SDH physical layer through the corresponding service access point.

LAPS is a physical coding sublayer that provides point-to-point transmission through SDH virtual containers and interface rates. The supported UITS is a connectionless mode service. Adopt rate adaptation between LAPS and SDH. It provides a mechanism to adjust the Ethernet MAC MII rate to the SDH VC rate. Since SDH and MAC operate in periodic and bursty modes respectively, it also prevents MAC frames entering SDH VC from being written to SDH overhead. On the other hand, rate adaptation can also be employed between the LAPS sublayer and the coordination sublayer.

SDH transmission is viewed as an octet-oriented synchronous point-to-point full-duplex link. The SDH frame is an octet-oriented synchronous multiplexing mapping structure, which specifies a series of standard rates, formats, and mapping methods. Table 2 shows the bandwidth value of VC, and Table 3 shows the currently specified STM interface rate. No need to use control signals. During the insertion or extraction of information into or from the synchronous payload envelope, a self-synchronous scrambling/descrambling (X ¹¹ +1) function is used.

Table 2. SDH virtual container bandwidth VC type VC bandwidth (kbit/s) VC payload (kbit/s) VC-11 1,664 1,600 VC-12 2,240 2,176 VC-2 6,848 6,784 VC-3 48,960 48,384 VC-4 150,336 149,760 VC-4-4c 601,304 599,040 VC-4-16c 2,405,376 2,396,160 VC-4-64c ^* 9,621,504 9,584,640

Table 3. STM interface rate STM type STM bit rate (kbit/s) SSTM-11 2,880 SSTM-12 5,184 SSTM-14 9,792 SSTM-18 19,792 SSTM-116 37,444 SSTM-21 7,488 SSTM-22 14,400 SSTM-24 28,224 STM-0 51,840 STM-1 155,052 STM-4 622,080 STM-16 2,488,320 STM-64 9,953,280

The SONET transmission rate is an integer multiple of STS-1 (51.840Mbps). The following are the multiples currently used by SONET:

STS-1: 51.840Mbps

STS-3: 155.520Mbps

STS-9: 466.560Mbps

STS-12: 622.080Mbps

STS-18: 933.120Mbps

STS-24: 1244.160Mbps

STS-36: 1866.240Mbps

STS-48: 2488.320Mbps

STS-192: 9953.280Mbps

Figure 2 shows the layer/protocol stack of Ethernet over LAPS in STM-N. Under LAPS, there are two ways to place VCs: (1) Put LAPS frames into low-order VCs, and multiplex low-order VCs to high-order VCs through octet interleaving according to the SDH multiplexing structure to multiplex sections, The regenerative section and the electrical/optical/radio section are transmitted sequentially, and then the LAPS frame is extracted in the reverse order at the receiving end; (2) The LAPS frame is put into the SPE, and the SPE is directly mapped to the high-priced VC, and the multiplex section, the regenerative section, and the electrical The /optical/radio segments are transmitted sequentially, and then, the LAPS frames are extracted in reverse order at the receiving end;

Figure 3 shows the layer/protocol stack of Ethernet over LAPS in sSTM. In this case, the LAPS frame is put into the low-order VCs (VC11, VC12, and VC2), and the low-order VCs are multiplexed into the sub-multiplex section through octet interleaving according to the SDH sub-multiplex structure, and then the regeneration section and Electrical/optical/radio segments transmit them sequentially, and then extract LAPS frames in reverse order at the receiving end;

Fig. 4 is the LAPS frame format of the present invention. As shown in Figure 4, LAPS encapsulation consists of start flag sequence, address field (SAPI, service access point identifier), control field (0x03), information field (IPv4, IPv6 or PPP protocol data unit), FCS (frame check sequence) and frame end flag sequence, the flag sequence (0x7E) determines the start and end of the LAPS frame.

Figure 5 is an exemplary protocol configuration for Ethernet over LAPS. In this case, one Ethernet interface is connected to the input/output gateway of another Ethernet interface through SDH. Two types of SDH and MAC physical interfaces are set on the gateway, and the network layer remains unchanged, still IPv4/IPv6/IPX.

Fig. 6 is the relationship between the coordination sublayer/MII and LAPS/SDH in Ethernet over LAPS according to the present invention. In this case, under the MAC functional sublayer, three types of physical interfaces of Ethernet Fast/Speed Ethernet/Gigabit Ethernet are set, and the adaptation of the MAC sublayer and the SDH physical layer is realized through LAPS at the SDH end.

The LAPS link entity receives frames from the MAC layer through the coordination sublayer and the equivalent MII (Media Independent Interface). There is no address filtering function here. The FCS calculations of LAPS and MAC refer to ITU-T recommendations X.85/Y.1321 and IEEE 802.3 standard. The functional unit of Ethernet over LAPS forwards all incoming LAPS information fields to its peer connected link except the source link port, buffering one or more incoming frames before forwarding.

FIG. 7 shows an exemplary configuration of functional units for realizing the adaptation between Gigabit Ethernet and SDH according to an embodiment of the present invention. As shown in the figure, only full-duplex mode is used. The figure illustrates the functional units of IEEE 802.3 Ethernet together with LAPS/SDH. At the SDH end, the adaptation of the MAC sublayer and the SDH physical layer is realized. Gigabit Ethernet provides dual-cable or 4-cable interfaces, single-mode optical fiber interfaces, multi-mode optical fiber interfaces and unshielded twisted pair interfaces.

Figure 8 shows the primitive relationship among MAC, LAPS link layer and physical layer. In the figure, LAPS provides a SAP, and a SAPI (Service Access Point Identifier) whose value is 28 (decimal) is used for Ethernet/Fast Ethernet/Gigabit Ethernet. The primitive "DL_UNACK_ACK request" is used to send MAC frames from the MAC layer to the LAPS link layer, and the primitive "DL_UNACK_DATA indication" is used to receive data packets from the LAPS link layer to the MAC link layer. Between the LAPS link layer and the physical layer, the primitive "PH_DATA request" is used to establish a link from LAPS to the physical layer, and the primitive "PH_DATAindication" means to send a command for link establishment from the physical layer to the LAPS link ; The primitive "PH_DATA request" is used to send data packets from the LAPS link layer to the physical layer, and the primitive "PH_DATA indication" is used to receive data packets from the physical layer to the LAPS link layer.

FIG. 9 is a block diagram of an interface device for directly adapting MAC frames to SDH/SONET or simplified SDH/SONET in Ethernet over SDH/SONET according to an embodiment of the present invention. The Ethernet over SDH/SONET interface device of the present invention (abbreviated as EOS device hereinafter) can be set in the telecommunication SDH/SONET transmission equipment to provide the Ethernet interface, or be set in the remote access data communication equipment to provide 155M, 622M , 2.5Gbps or 10G Ethernet interface, even connected between telecom SDH/SONET transmission equipment and remote access data communication equipment, to directly adapt MAC frames to SDH/SONET.

EOS devices perform standard STS-3c/STM-1 processing in both transmit and receive directions.

In the sending direction, the Ethernet rate is adapted to the SDH/SONET rate, MII frames are converted into LAPS frames, and the LAPS frames are encapsulated into SDH/SONET SPE/VC. Inserting POH and TOH/SOH, the resulting STS signal is sent octet-wide to a parallel/serial converter and then to a fiber optic transceiver through a line-side interface.

As shown in Figure 9, in sending direction, EOS device 1 comprises: send (TX) FIFO 8, be used for receiving and buffering the data packet (such as IPv4 or IPv6 bag or PPP bag, MPEG bag, voice bag and other data packets), the MII rate is adapted to the rate of LAPS, such as adapting the 100M MII frame of parallel burst to the periodic 155M LAPS frame; TX LAPS processing unit 7, is used for according to the format shown in Figure 4 and data packets are encapsulated into the LAPS frame; the scrambling unit 6 is used to scramble the LAPS frame; the SPE/VC generation unit 5 is used to generate a pointer indicating the position of the SPE/VC; the SDH overhead insertion unit 4 is used to insert Overhead; TX SDH/SONET framer 3, used to encapsulate the scrambled LAPS frame into the SPE/VC of the SDH/SONET frame to form an SDH/SONET frame.

In the receive direction, the process is reversed. Receive octet-wide STS signal, Ethernetover SDH/SONET interface device locates frame and TOH/SOH, interprets pointers, terminates TOH/SOH and POH, extracts SPE/VC4, then extracts LAPS from SPE/VC4 payload frame. The SONET/SDH processor consists of a receive SONET/SDH processor and a transmit SONET/SDH processor.

In Fig. 9, in the receiving direction, EOS device 1 includes: receiving (RX) frame parser (deframer) 9, is used for analyzing the received SDH/SONET frame; SDH overhead extracting unit 16, is used for removing SDH/SONET SONET frame overhead; pointer processing unit 10, used to locate and interpret pointers, extract SPE/VC4, and separate LAPS frames from SPE/VC4; descrambling unit 11, used to descramble the extracted LAPS frames; receiving processing unit 12, for frame parsing of the LAPS frame, extracting SAPI and data packets encapsulated in the LAPS frame; receiving FIFO 13, for buffering data packets, determining the SAPI, adapting the LAPS rate to the rate of the MII, for example, converting the cycle The permanent 155M LAPS frame is adapted to the parallel burst 100M MII frame, and sends data packets such as IP packets and SAPI. The EOS device 1 further includes: an SDH overhead monitoring unit 14 for monitoring error changes of TOH/SOH bytes in various states; and a POH monitoring unit 15 for monitoring error changes of POH bytes in various states.

The determining unit (not shown) provided in the receiving processing unit is used to determine the type of the received data packet, generate a corresponding predetermined SAPI, and check the error occurred in the frame.

In addition, the EOS device 1 also includes: a converter 19, which synchronizes the data packets of the upper-level equipment with the input data packets input to the first receiving means in the sending direction, and synchronizes the data packets extracted from the second sending means with the upper-level equipment. The data packets are synchronized in the receiving direction; the line-side interface 2 is used to send SDH/SONET frames to peripheral SDH/SONET support equipment through the TX line, such as O/E modules (not shown), and receive SDH/SONET frames through the RX line SONET frame; microprocessor I/F (interface) 18, it can make EOS device 1 access all registers wherein; JTAG port 12 for testing; ) register 21.

The main functions of the EOS device are:

● Handle the source and sink of SDH/SONET segment, line and channel layer, and have transmission/segmentation E1, E2, F1 and D1-D12 overhead interfaces in both sending and receiving directions.

● Realize the processing of STS-48c/STM-16 or STS-12c/STM-4 or STS-3c/STM-1 data stream by mapping LAPS frame to SDH/SONET or simplified SDH/SONET payload in full duplex.

• Implement a self-synchronizing scrambler/descrambler with the polynomial (X ⁴³ +1) of LAPS.

●Provide a MII interface.

●Provide 8-bit or 16-bit microprocessor interface for control, configuration and status monitoring.

● LAPS processing is compatible with ITU-T recommendation X.86.

●Compatible with SDH/SONET specifications such as ANSI T1.105, Bellcore GR-253-CORE and ITUG.707.

●Provide IEEE 1149.1 JTAG test port.

●Supports inner loopback channel test for diagnosis.

●Provide an 8-bit general-purpose I/O (GPIO) register.

The following is a detailed description of the reception and transmission processing of the interface device of the present invention. In the following description, related functions or operations and functional blocks or units can be realized in the form of executable programs or hardware. They will be omitted to avoid unnecessarily obscuring the main aspects of the invention.

Receive SDH/SONET processing

The function of the RX frame parser 9 is equivalent to an SDH/SONET receiving processor. The SDH/SONET receive processor is used to implement STS signal framing, descrambling, TOH/SOH monitoring including B1 and B2 monitoring, AIS detection, pointer processing, and POH monitoring. The receiving SDH/SONET processor performs the following functions:

● SDH/SONET framing, detect [A1 A1 A2 A2] bytes, these bytes will be used for framing, provide OOF and LOF indicators (single event and second event, single event and second event).

● Use SDH/SONET frame synchronous scrambler to scramble the payload, and the scrambling polynomial is (X ⁷ +X ⁶ +1).

• Monitor the incoming B1 byte and compare it to the recomputed BIP-8 value. Provide error event information, including single bit error, error frame and error time (Errored Second) count.

• Monitor the incoming B2 byte and compare it to the recomputed BIP-86/24 value. Provides error event information, including counts of single bit errors, error frames, and error time.

●Monitor K1 and K2 bytes, K1 and K2 are used for sending line/MS AIS or RDI, and for APS sending.

• Monitor the 4 LSBs of the received S1 byte for consistent values in subsequent frames.

• Monitor the M1 byte for determining the number of B2 errors detected by the remote terminal in the signal it receives.

- TOH/SOH drop block outputs received E1, F1 and E2 bytes and 2 serial DCC channels, SDCC (D1-D3) and LDCC (D4-D12).

• Pointer status determination includes checking the H1-H2 bytes to establish the status of the received pointer (OK, LOP, AIS). If the pointer status is normal, read the first H1H2 bytes to determine the start of the SPE/VC.

● The POH monitoring module is composed of J1, B3, C2 and G1 monitoring, and these POH bytes are used to monitor errors or changes in status.

• Monitor/capture J1 bytes. In SONET applications, 64 consecutive J1 bytes are captured. In SDH applications, the EOS device looks for repeated patterns of 16 consecutive J1 bytes.

● Monitor the C2 byte to verify the extension type of the cycle. Check the branches to find 5 consecutive frames with the same C2 byte.

• Monitor G1 of REI-P and RDI-P.

• Monitor the incoming B3 byte and compare it to the recalculated BIP-8 value. Provides error event information, including counts of single bit errors, error frames, and error time.

• To determine whether the bit error rate of the received signal is above or below two different preset thresholds, the EOS device sets two B2 error rate threshold blocks. Signal failure (SF) and signal degradation (SD) status are reported by interrupts when thresholds are exceeded.

Send SDH/SONET processing

TX framer 3 realizes the function of sending SDH/SONET processor. The function of sending SDH/SONET processor is to encapsulate LAPS frame into SPE/VC. It then inserts the appropriate POH and TOH/SOH to output the final STS signal to a parallel-to-serial converter followed by a fiber optic transceiver.

●Synchronous Payload Envelope/Virtual Container (SPE/VC) generation block multiplexes LAPS frame from system interface with path overhead (POH) bytes to generate SONET SPE or SDH VC.

● Supports the following POH bytes: Channel Tracking (J1), Channel BIP-8 (B3), Signal Label (C2), Channel Status (G1). The other POH bytes are all set to zero for transmission.

• Perform AIS and unprepared signal insertion.

●TOH/SOH generation, including:

Frame byte A1A2 - for testing the fixed F628 or forced error (Forced Error) through the microprocessor interface, for testing.

Segment Tracking (J0) - Programmable via microprocessor interface.

Section Growth (Section Growth J0) - fixed mode 2~12.

Section BIP-8(B1) - Calculated or Forced Errors via Microprocessor Interface, for testing purposes.

Order wire (Orderwire, E1E2) - external serial interface.

Segment User Channel (F1) - External Serial Interface.

Data Communication Channels (D1-D12) - External Serial Interface.

Pointer bytes (H1H2H3) - fixed at 522, NDF disabled, SS programmable.

Line BIP-96/24(B2) - Errors calculated or forced through the microprocessor interface for testing purposes.

APS/MS AIS (K1K2) - Programmable via microprocessor interface.

Synchronous state (S1) - Programmable via microprocessor interface.

Line/MS REI(M1) - Errors calculated or forced through the microprocessor interface for testing purposes.

●Toh/Soh not defined, all set to zero for transmission. The payload is scrambled with a SONET/SDH frame synchronous scrambler, and the polynomial is X ⁷ +X ⁶ +1.

The LAPS processing process is described in detail below

LAPS processing

The EOS device 1 extracts frames/packets from the SONET Payload Envelope (SpE) via the LAPS processor. The EOS device 1 also supports Flow-thru mode, which allows the SPE to pass directly through the system interface. The LAPS processor does LAPS-like framing for LLC and other packet-based data. The LAPS processor is a single channel engine used to encapsulate data packets into LAPS frames according to ITU-T Recommendation X.86. LAPS processors only operate on byte-aligned data (eg messages whose length is an integer number of bytes). In EOS mode, the LAPS processor is divided into a receiving LAPS processor and a transmitting LAPS processor.

encapsulation

The LAPS link entity receives frames from the MAC layer through the coordination sublayer and the equivalent MII (Media Independent Interface). The address filtering function is not used here.

Figure 10 is a schematic diagram of the IEEE 802.3 Ethernet MAC frame format, and the shaded part in the figure defines the format of the LAPS information field. Figure 11 shows the LAPS frame format after encapsulating the MAC field. The FCS calculations of LAPS and MAC refer to ITU-T recommendation X.85/Y.1321 and IEEE 802.3 standards respectively. The functional unit of Ethernet over LAPS forwards all input LAPS information fields to the peer connection link except the source link port, allowing one or more input frames to be buffered before forwarding. What Figure 4 shows is the relationship between the coordination sublayer/MII and LAPS/SDH.

Receive LAPS Processor

The functions of the receiving LAPS processor 12 are extracting LAPS frames, Transparency Removal, FCS error checking, descrambling of SPE/VC payload, control and address field option deletion, and performance monitoring.

After removing the field flags and start/end of byte stuffing, the remaining payload consists of data and FCS fields, see attached image for more details. Note that only one flag byte is needed between two packets, all flags between packets will be discarded.

The receive LAPS processor performs the following functions:

- Optional self-synchronous descrambling of the received payload (polynomial X ⁴³ +1).

● Detection and termination of LAPS frames, such as frame delimitation marker detection.

● Remove Control Escape padding.

• Compute the optional FCS code (32 bits) and compare with the received FCS value. The performance monitoring registers accumulate errors. If an FCS error is detected, the output data is marked as error data.

• Detect abort sequence in byte stream (0x7D, 0x7E).

• Optionally remove address and control fields.

● Provide optional minimum and maximum packet length detection (SW configuration), determine the RX_ERR signal of the data to mark the error status.

● Generate performance monitoring of octets: FCS error, termination packet, short packet (Short Packet), long packet, packet discarded due to RXFIFO error.

• Optionally remove packet stuffing to handle remote FIFO underflow conditions.

● Generates an interrupt on error conditions.

●Automatically delete the generated package gap flag.

• For rate matching, remove the programmable interframe gap padding byte (0x7E) if possible.

• Synchronize the LAPS information field (MAC/GMAC frame) from the SDH/SONET block with the receive clock (RX_CLK) of the MII/GMII interface through the converter 19 .

LAPS frame synchronization

The flag sequence (0x7E) identifies the start and end of the LAPS frame. The received SPE payload data is searched octet by octet for a marker sequence to locate LAPS frame boundaries. The octet value used to determine the flag sequence is programmable with a default value of 0x7E.

Two consecutive flag sequences constitute an empty frame and are ignored for empty frames. Therefore, N consecutive flag sequences constitute N-1 empty frames. Frames that are too short and invalid are silently discarded. An LAPS frame is considered invalid if it falls into any of the following categories:

a) cannot be completely delimited by two signs;

b) less than 6 octets between frame markers;

c) contain a frame check sequence error;

d) contains a service access point identifier that does not match "4" (IPv4-based service), "6" (IPv6-based service), "255" (PPP-based service) or is not supported by the receiver;

e) contain an unrecognized control field value;

f) ends with a sequence of more than 6 "1" bits;

LAPS octet destuffing process

The LAPS octet destuffing process (sometimes called Escaping Transform) is applied to received LAPS frames before FCS calculations and after LAPS frame synchronization. Octet destuffing is accomplished by detecting the entire LAPS frame between the start and end of the Control Escape Octet flag sequence. Once found, the control-escape octet is removed from the octet stream, and subsequent octets are de-stuffed with an octet to mask the octet (Octet De-Stuffing Masking Octet) to perform an OR operation. The termination sequence should not be considered an escape sequence (Escape Sequence).

The value of the control escape octet is programmable and has a default value of 0x7D. The octet destuffing masking octet is also programmable and has a default value of 0x20. As an example, 0x7E is encoded as 0x7D, 0x5E, and 0x7D is encoded as 0x7D, 0x5D.

LAPS termination sequence

In incoming LAPS frames, detection of a termination sequence (a control escape code followed by a flag sequence) is optional. The termination sequence marks the end of a terminated LAPS frame.

Send LAPS Processor

The transmit LAPS processor 7 inserts packet-based information into the STS SPE, which provides packet encapsulation, FCS field generation, inter-packet stuffing, TXFIFO error recovery, and scrambling. The sending LAPS processor completes the following functions:

●Encapsulate the packet into the LAPS frame, each packet is encapsulated with a start flag (0x7E), an optional FCS field, an optional address and control field, and an end flag (0x7E).

• Optional self-synchronizing transmit payload scrambler (polynomial is X ⁴³ +1).

●Transparent processing according to ITU-T X.85 requirements (octet padding for flags and control escape codes). Byte padding is required between the start and end field markers. Padding replaces any byte matching a flag or control escape byte with a two-byte long sequence of control escape bytes followed by the original byte XORed with 0x20 (hexadecimal).

● Generate start and end field flags (0x7E). Note that a single flag can be shared between two packages.

• Optionally generate a 32-bit CRC for the Frame Check Sequence (FCS).

● Provides FCS error insertion capability for testing under software control.

● TX_PRTY error generates an interrupt.

● Provides optional handling of FIFO underflow. A FIFO underflow condition occurs when the TXFIFO is emptied before the end of the packet. When this happens, an outage is caused. At this point, the packet can end in several ways: by generating an FCS error, by generating a termination sequence, or by SW configurable escape codes to insert "padding" bytes during packet gaps.

● Generates performance monitoring counts, including: number of FIFO error events, number of abnormally terminated packets, number of packets violating minimum and maximum packet length parameters (SW configurable).

- Synchronization of MAC/GMAC frames received from MII/GMII with SDH/SONET block clock via converter 19 .

● If necessary, for rate matching, add programmable rate inter-packet gap filling byte (0x7E).

FCS polynomial

The EOS device 1 supports CRC-32 frame check sequence (FCS) generation and verification.

The FCS transmits the least significant octet (LSB) first, which contains the coefficient of the highest term. There are two FCS calculation methods for EOS devices: according to LAPS's little endian bit order or high endian bit order.

The following polynomials are used to generate and check the FCS value CRC-32: 1+x+x ² +x ⁴ +x ⁵ +x ⁷ +x ⁸ +x ¹⁰ +x ^{11 +x 12} +x ¹⁶ +x ²² + ^{x 23} +x ²⁶ +x ³² . The FCS field is computed from all bits of the Address (SAPI value), Control and Information fields, excluding any octets inserted for transparency. This includes neither the flag sequence nor the FCS field itself. For both FCS methods, the CRC generator and checker are initialized to all logic "1". After the FCS calculation is complete, the FCS value is 1's complement, which inserts this new value into the FCS field.

Next, the process of data processing in the sending direction according to the present invention will be described in detail.

Send direction data processing

In the transmit direction, the EOS device 1 inserts packet-based data into the STS/STM SPE. The device operating modes may be provided through a management control interface. Register value TX_EOS=1 puts the device in EOS mode.

Send FIFO interface

In EOS mode, the sending system interface operates as a compatible MII interface.

1. Send FIFO

TX FIFO 13 converts the MII burst frame (such as 100M) received from the converter 19 into a periodic LAPS frame (such as 155M) through parallel processing by inserting a 0x7E mark or by synchronizing the receiving and transmitting ends of the TX FIFO .

The transmission system interface is controlled by a link layer device located before the EOS device in the transmission direction of the transmission channel. The link layer device provides a clock for synchronizing all interface transfers to the EOS device interface. This agreement requires the EOS device to have a rate matching buffer (eg FIFO). The minimum value for the FIFO size is 512 bytes. The EOS device also transmits the status of the packet (start/end of packet/cell, whether the last word of the packet consists of one or two octets, packet error) via the FIFO.

2. Send FIFO error

In EOS mode, the FIFO status is monitored by the EOS device and a FIFO error status is declared whenever: 1) MII_TX_SOP is received before the end of packet (TX_EOP indication), 2) indeterminate following TX_CLAV signal Activate MII_TX_ENB outside the "transmit window". Report FIFO error events to the management interface by setting MII_TX_FIFOERR_E=1. EOS devices have an 8-bit FIFO error counter that records each packet affected by a FIFO error event.

When the performance monitoring counter is latched, the counter value is latched by the MII_TX_FIFOERR_CNT[7:0] register, and the FIFO error counter is cleared. If at least one FIFO error event has occurred since the last rising edge of LATCH_EVENT, the FIFO error event bit - MII_TX_FIFOERR_SECE is set. In EOS mode (MII_TX_EOS=1), the EOS device terminates erroneous packets.

3. EOS error packet processing

In the EOS operation mode (MII_TX_EOS=1), error packet processing is provided.

4. TX_ERR link layer indication

The Transmitting System Interface provides a method that link layer devices can use to indicate to the EOS device when a particular packet contains an error and should be terminated or discarded (see MII_TX_ERR definition).

The EOS device 1 includes an 8-bit link layer error counter which counts each packet received from the link layer with an error flag. When the performance monitoring counter is latched (LATCH_EVENT transmission is high), the value of the counter is latched by the MII_TX_EOS_LLPKT_ERRCNT[7:0] register, and the link layer packet error counter is cleared. If at least one link layer packet error event has occurred since the last rising edge of LATCH_EVENT, the link layer error packet error event bit, MII_TX_EOS_LLPKT_ERR_SECE, is set.

5. Min/max packet size

EOS has an option that if a packet exceeds the minimum or maximum packet size, the EOS device considers the packet to be in error and does not send or terminate the packet. The packet size refers only to the size of the LAPS packet and does not include bytes inserted by the EOS device (flag sequence, address, control, FIFO underflow, transparent or FCS bytes). These minimum and maximum values are programmable through the supervisory control interface. Register MII_TX_EOS_PMIN[3:0] contains the minimum packet size, whose default value is 6. Register MII_TX_EOS_PMAX[15:0] contains the maximum packet size, and its default value is 0x05E0.

The EOS device 1 disables/allows the minimum and maximum packet size checks by command of the management interface. If MII_TX_EOS_PMIN_ENB or MII_TX_EOS_PMAX_ENB=1, packet termination due to packet size limit violation is allowed. If = 0 (the default setting), the packet size limit function is ignored.

The EOS device 1 contains two 8-bit counters that count each violation of the minimum and maximum packet size constraints. When the performance monitoring counters are latched, the values of these counters are latched by the MII_TX_EOS_PMIN_ERRCNT[7:0] and MIITX_EOS_PMAX_ERRCNT[7:0] registers, clearing the packet size violation counters. If at least one packet size violation error has occurred since the last rising edge of LATCH_EVENT, set the appropriate packet size violation secondary event bit, MII_TX_EOS_PMIN_ERR_SECE or MII_TX_EOS_PMAX_ERR_SECE.

6. Error Packet Termination

After packets start to transmit, the EOS device 1 cannot delete packets if they are received or an error condition is detected, so these packets will be terminated. EOS devices support two options for terminating error packets.

The default option is to terminate a packet by inserting the termination sequence 0x7d7e. The remote receiver discards the packet after receiving this code. Another solution is to terminate error packets by simply inverting the FCS bytes. Termination mode is controlled by the management control interface. MII_TX_EOS_FCSABRT_ENB=1 is the FCS inversion method, and MII_TX_EOS_FCSABRT_ENB=0 (default setting) disables the FCS inversion method.

Line side packet loopback

For testing, EOS device 1 provides user loopback packet function, which puts the packet extracted from SONET/SDH signal into FIFO in the sending direction, and replaces the data received from the system interface here. Then these data enter LAPS processing at the sending end, and finally send back to the SONET/SDH circuit. When MII_R_TO_T_LOOP is set to 1, the loopback function is activated. When MII_R_TO_T_LOOP is set to 0, loopback is disabled and normal processing is performed. This loopback function is mainly used for device testing. In actual operation, if the receiving clock is faster than the sending clock, and the SONET/SDH payload is filled with data packets, periodic errors will occur because the sending end cannot accommodate the full rate of the receiving end.

Send LAPS process

After transmitting the system interface, in the EOS mode (MII_TX_EOS=1), the EOS device 1 performs the following processing:

1. Encapsulate the packet in the LAPS frame

The LAPS frame definition for EOS is shown in Figure 4. In EOS mode (MII_TX_EOS=1), each LAPS packet received from the link layer is described by the flag sequence defined in ITU-T X.85. The flag sequence is used to indicate the start and end of the LAPS frame, and its value is 01111110 (0x7e in hexadecimal).

As an option, EOS devices can insert a single flag to indicate the end of one frame and the start of the next, a function controlled by the management interface. If MII_TX_EOS_EOP_FLAG=1, the EOS device inserts a split flag to indicate the start and end of a frame. If MII_TX_EOS_EOP_FLAG=0 (default setting), only a single flag sequence can be inserted.

In the special case where the generation of the FCS field is prohibited, the EOS device ignores the MII_TX_EOS_EOP_FLAG and always inserts the frame start and end of frame flag sequences. This is a non-standard mode of operation because the FCS field is mandatory according to ITU-T X.85. This characteristic requires ensuring that the receiving end operates correctly during testing. During this period, the use of FCS is disabled, possibly for single-byte packets.

2. Address and control fields

The X.86 standard defines two fields immediately following the frame start flag sequence: an address field, which is set to 0x0c; and a control byte, which is defined as 00000011. In EOS mode (MII_TX_EOS=1), EOS devices may choose to insert these fields if MII_TX_EOS_ADRCTL_INS=1. These fields are not inserted if MII_TX_EOS_ADRCTL_INS=0 (default setting).

3. Transparency processing

In EOS mode (MII_TX_EOS=1), the octet stuffing process takes place at a point called Transparency Processing. A special octet-control escape code (01111101 or hexadecimal 0x7d) is used as an identifier to indicate which bytes require special handling on the receiving end. Control escape codes are used to mark the presence of any special codes in the frame data.

After performing the FCS calculation, the EOS device examines the entire frame between any two marker sequences. Each occurrence of any code marked 0x7e or 0x7d is replaced by a two-octet sequence followed by a control-escape octet consisting of the original octet XORed with the hexadecimal 0x20 code. EOS devices transparently process the following byte sequences, with one exception being the flag sequence inserted by the EOS device to describe the frame. 0x7e in the payload (between flag sequences) is described as follows:

0x7e is encoded as 0x7d, 0x5e;

0x7d is encoded as 0x7d/0x5d.

SPE generation

1. EOS operation (MII_TX_EOS=1)

The EOS stream is then mapped into the payload of the SONET/SDH Synchronous Payload Envelope (SPE). EOS octet boundaries are aligned with SPE octet boundaries. Since EOS frames are variable in length, they are allowed to cross SPE boundaries. During operation, when there are no LAPS frames that can be inserted into the SPE immediately, the flag sequence is sent to fill the time between LAPS frames. This is only done between two full frames. The available information rate of Ethernet over SONET/SDH for STS-3c/STM-1 is 149.760Mbps.

2. FIFO underflow

In EOS mode (MII_TX_EOS=1), it is of course empty between two packets, but it should not be empty when the packet is sent, that is, it cannot be empty after receiving the MII_TX_SOP instruction, but it can be before receiving the MII_TX_SOP instruction empty. If this happens, the EOS device provides two options for handling FIFO underflow: the termination mode can be used, a termination packet; or a special code, MII_TX_EOS_FIFOUNDR_BYTE[7:0], can be sent to fill the SPE until it appears again in the FIFO valid data. The register MII_TX_EOS_FIFOUNDR_MODE controls the response; MII_TX_EOS_FIFOUNDR_MODE=0 means that the packet will be terminated, which is the default value. MII_TX_EOS_FIFOUNDR_MODE=1 means that when underflow occurs, special FIFO underflow code MII_TX_EOS_FIFOUNDR_BYTE[7:0] will be sent. The default value of MII_TX_EOS_FIFOUNDR_BYTE[7:0] is 0x? ? .

SPE/VC generation

The structure of STS-3c SPE or VC-4 is shown in Figure 12A-C. The first column of SPE/VC is POH (Path Overhead). Channel overhead is 9 bytes. The order of these 9 bytes is J1, B3, C2, G1, F2, H4, Z3, Z4 and Z5 for SONET and J1, B3, C2, G1, F2, H4, F3, K3 and N1 for SDH. The first byte of the channel overhead is the channel tracking byte J1, which indicates its position relative to SONET/SDH TOH/SOH through the relevant STS/AU pointer. The following defines the sent value of the POH byte. Here the byte names of SONET and SDH are different, and the names of SONET are listed first.

1. Channel tracking (J1)

In the J1 byte, EOS can send a 16-byte or 64-byte channel tracking message, and the message is stored in MII_TX_J1_[63:0]_[7:0]. If MII_TX_J1_SEL=0, the J1 byte is sent repeatedly in a 16-byte sequence from MII_TX_J1_[15]_[7:0] to MII_TX_J1[0]_[7:0], otherwise it is sent in sequence from MII_TX_J1_[63]_[7 :0] to MII_TX_J1_[0]_[7:0] 64-byte sequence repeated transmission (usually 16-byte sequence for SDH mode, 64-byte for SONET mode).

2. Channel BIP-8 (B3)

If B3_INV=0, Bit Interleaved Parity 8 (BIP-8) is sent as even parity (normal), otherwise odd parity is generated (incorrect). BIP-8 calculates all bits of the previous SPE/VC (including POH), and puts its value into the B3 byte of the current SPE/VC.

By defining BIP-8, the first bit of B3 provides the parity check of the first bit of all bytes of the previous SPE/VC, and the second bit of B3 provides the parity check of the second bit of all bytes of the previous SPE/VC test, and so on.

3. Signal label (C2)

The signal label byte indicates the composition of the SPE/VC. The preset value TX_C2[7:0] is inserted into the generated C2 byte.

4. Channel status (G1)

Channel REI

The receiving end monitors the B3 bit error in the received SPE/VC. The number of B3 errors detected in each frame (0 to 8) is transmitted from the receiving end to the sending end, and inserted into the sending channel status byte G1 as a remote error indication (Remote Error Indication). If FORCE_G1ERR=1, then the 4 MSBs (most significant bits) of G1 are sent continuously as 1000 (for testing). Otherwise if PERI_INH = 0, they are set to a binary value (0000 to 1000, indicating 0 to 8) equal to the number of B3 errors most recently detected by the POH monitoring module at the receiving end. Otherwise, set them all to zero.

Channel RDI

Bit 5 of G1 can be used as channel/snap remote fault indication (RDI-P), or bits 5, 6 and 7 of G1 can be used as enhanced RDI-P indicator. The transmit value in bits 5, 6 and 7 of G1 is either generated from the TX_G1[2:0] register (if PRDI_AUTO=0), or an enhanced RDI signal is automatically generated by the EOS device (if PRDI_AUTO=1, PRDI_ENH=1) , or a one-bit RDI signal (if PRDI_AUTO=1, PRDI_ENH=0). The values sent in bits 5, 6 and 7 of G1 are shown in Table 4.

Table 4 channel RDI bit value PRDI_Auto PRDI_ENH RX_PAISRX_LOP RX_UNEQ RX_PLM 5, 6 and 7 bits of G1 0 x x x x Tx_G1[2,0] 1 0 1 x x 100 0 x x 000 1 1 x x 101 0 1 x 110 0 0 1 010 0 0 0 001

If PRDI_AUTO=1, a minimum of 20 frames is sent for the above stated value. Once 20 frames have been sent with the same value, the fault indication value corresponding to the current state listed in Table 4 is sent. The 8th bit (least significant bit) of G1 is not used and is set to 0.

5. Other POH bytes

EOS device 1 does not support the remaining POH bytes, which are sent with fixed all zero bytes. These bytes include channel user channel (F2), position indicator (H4), channel growth/user channel (Z3/F3), channel growth/channel APS channel (Z4/K3), and front and rear connection monitoring bytes (Z5/N1 ).

SONET/SDH frame generation

The SONET/SDH frame generation module generates transport (segment) overhead (TOH/SOH) bytes, fills the payload with bytes from the SPE/VC, scrambles all bytes except the TOH/SOH bytes of the first row code to create STS-3c/STM-1.

1. Frame Alignment

The position of the generated frame is fixed relative to the input TX_FRAME_IN. The start of frame indication output TX_FRAME_OUT has a fixed but unspecified relationship to the TX_FRAME_IN input. The relationship between the wide pulse of one clock cycle on TX_FRAME_OUT and the output TX_DATA[7:0] data byte of the transmission line is controlled by the MII_TX_FOUT_BYTE_TYPE[1:0] and TX_FOUT_BYTE_NUMBER[3:0] registers.

2. Payload generation

SONET or SDH payloads are normally padded with SPE/VC bytes. In STS-3c/STM-1 mode (MII_TX_SIG_MODE=0), the J1 byte of the SPE/VC is placed in the 10th column and the 1st row.

During the transmission of line (multiplex section, MS) alarm indication signal (AIS) LAIS, or channel (administrative unit, AU) alarm indication signal (PAIS), the normal generation of SONET/SDH payload is suspended. The MII_TX_LAIS and MII_TX_PAIS registers control AIS generation. If MII_TX_LAIS or MII_TX PAIS=1, the entire payload (9396 or 2349 bytes) is filled with 1 byte.

Unless AIS is activated, if TX_UNEQ = 1, an unprepared SPE/VC is generated (all SPE/VC bytes are filled with zeros).

3. TOH/SOH generation

SONET TOH bytes are basically the same as SDH TOH bytes. All TOH/SOH byte values generated are defined below. When SONET and SDH have different byte names, the name used by SONET is listed first. The gaps in the standard are not defined in SONET or SDH non-standard reserved bytes. The EOS device 1 fills these bytes with all zeros.

During the transmission of LAIS or PAIS, the normal generation of TOH/SOH bytes is suspended. If MII_TX_LAIS=1, the first 3 lines of TOH/SOH are normally generated, but the rest of TOH/SOH (and all SPE/VC bytes) are all set to 1 before sending. If MII_TX_PAIS=1, except the pointer byte in the fourth row, all TOH/SOH row bytes are normally generated. H1, H2, and H3 bytes (and all SPE/VC bytes) are transmitted with all set to 1.

Frame bytes are generated normally with the following fixed pattern:

A1: 1111_0110 = F6;

A2: 0010_1000=28.

For testing purposes, A1 and A2 can be generated with errors. If A1A2_ERR=0, no error is inserted. When A1A2_ERR=1, the value of A1A2_ERR_PAT[15:0] is XORed with A1 and A2 to generate m consecutive frames in each group of 8 frames (where m is equivalent to the binary value of A1A2_ERR_NUM[2:0] number), the most significant bit of A1 is XORed with A1A2_ERR_PAT[15], and the least significant bit of A2 is XORed with A1A2_ERR_PAT[0].

During 16 consecutive frames, the EOS device continuously transmits the 16-byte pattern contained in MII_TX_J0_[15:0]_[7:0], starting from the MII_TX_J0[15]_[7:0] byte in descending order send.

The ITU-T G.707 standard stipulates that the 16-bit segment tracking frame containing the segment access point identifier (SAPI) defined in Article 3/G.831 is sent continuously in continuous J0 bytes. Note that only the Start of Frame Indicator byte shall have a 1 in its most significant bit.

Currently, there is no segment tracking function defined for SONET. Unless a similar segment tracking field is defined for SONET, all MII_TX_J0 bytes shall be filled with 0000_0001, so a decimal 1 is sent consecutively in J0. Z0 bytes are sent in binary order 2 to 12 in STS-12c/STM-4 (MII_TX_SIG_MODE=1) mode, 2 to 3 in STS-3c/STM-1 (MII_TX_SIG_MODE=0) mode (this is in GR specified in -253).

If MII_B1_INV=0, B1 8-bit Bit Interleaved Parity (BIP-8) is sent with even parity (correct state), otherwise odd parity is generated (incorrect). BIP-8 calculates all bits of the STS-3c/STM-1 frame after the previous scrambled code, and puts it into the B1 byte of the current frame before the scrambled code. By definition of BIP-8, the first bit of B1 provides the parity of the first bit of all bytes in the previous frame, the second bit of B1 provides the parity of the second bit of all bytes in the previous frame, etc. .

Define the command line byte to carry two 64kb/s digital voice signals. The F1 byte is used by the network provider. The transmit block receives 3 serial inputs: MII_TX_E1_DATA, MII_TX_E2_DATA and TX_F1_DATA for insertion into the transmitted E1, E2 and F1 bytes. A single notched 64kHz clock (MII_TX_E1E2F1_CLK) is output from EOS device 1 to provide the clock reference for the three serial inputs.

The first (most significant bit) of these bytes should be aligned with MII_TX_FRAME_IN in the incoming frame start pulse. After receiving the last bit of E1, E2 and F1 bytes, the received E1, E2 and F1 bytes are inserted into the outgoing SONET/SDH frame.

TOH/SOH defines two kinds of DCC (data communication channel), section/regeneration section DCC uses D1, D2 and D3 bytes to generate a 192kb/s channel with a gap. The line/multiplex section DCC uses bytes D4 to D12 to generate a gapped 576kb/s channel. The transmitter receives DCC data at two serial inputs: MII_TX_SDCC_DATA and MII_TX_LDCC_DATA. To ensure bit synchronization, the transmitter outputs two clocks: MII_TX_SDCC_CLK, 192kHz (notched); and MII_TX_LDCC_CLK, 576kHz (notched). The clock signal enables the MII_TX_SDCC_DATA and MII_TX_LDCC_DATA bits to be relocated to registers for insertion into the TOH/SOH. The MII_TX_SDCC_DATA and MII_TX_LDCC_DATA inputs should change according to the MII_TX_SDCC_CLK and MII_TX_LDCC_CLK falling edges because retiming is done on the rising edge.

The H1 and H2 bytes contain 3 fields. Since SPE/VC is generated synchronously with TOH, there is no need to generate variable pointers. In contrast, valid H1 and H2 bytes are generated with a fixed pointer value 522 (decimal) = 10_0000_1010 (binary), and the H3 bytes are all fixed at 0. In this way, the J1 byte in SPE/VC is placed in row 1, column 10 in STS-3c/STM-1 mode (MII_TX_SIG_MODE=0).

If MII_TX_LAIS or TX_PAIS is active, the H1, H2 and H3 bytes are all set to 1 when transmitted. When MII_TX_LAIS or TX_PAIS transitions to 0, the EOS device 1 sends the first H1 byte in the next frame with a valid New Data Flag (NDF). Subsequent frames are generated with the disabled NDF field in the first H1 byte. The first H1-H2 byte pair is sent as a normal pointer, at this time:

NDF = 0110;

SS = TX_SDG_PG, 0;

● Pointer value = 10_0000_1010;

All other H1-H2 byte pairs are sent in concatenated indication bytes, when:

NDF=1001;

SS = TX_SDG_PG, 0;

● Pointer value = 11_1111_1111;

In the description of the B2 byte below, its value varies slightly depending on the device mode (STS-12c mode and STS-3c). In order to describe the operation of the two modes, the following convention is used to distinguish the requirements of each mode: STS-3c. TOH/SOH has 12[3] B2 bytes which together provide BIP-96[BIP-24] error detection capability.

Each B2 byte provides BIP-8 parity for bytes in 1 of the 12[3] groups of bytes in the previous frame. The B2 byte in the jth column provides BIP-8 parity for the byte at the j+12k (j+3k)th byte in the previous frame (except the first 3 rows of TOH/SOH), where k=0 to 89. If B2_INV=0, BIP-8 is sent with even parity bits (normal state), otherwise, odd parity bits are generated (error state). The BIP-8 value is calculated for the bytes in the previous STS-3c/STM-1 frame before scrambling, and is put into the B2 byte of the current frame before scrambling.

The 5 most significant bits of K1 and K2 are used as Automatic Protection Switching (APS) signals. The 3 least significant bits of K2 are used as AIS or remote fault indication (RDI) at the line/MS layer, and in SONET they are also used as APS signaling. The EOS device 1 inserts MII_TX_K1[7:0] into the transmitted K1 byte, and inserts MII_TX_K2[7:3] into the 5 MSB bytes of the transmitted K2.

The 3 LSB bits of K2 are controlled by 3 sources, in order of priority, they are:

• If TX_LAPS = 1, when transmitting, set them all to 1 (as do all line/MS overhead bytes).

• If LRDI_INH = 0, and if any of (MII_RX_LOS AND NOTRX_LOS_INH), MII_RX_LOF, MII_RX_LOC or MII_RX_LAIS is equal to 1, they are sent in code 110. Whenever this special event is activated, the K2 is set to 110 for a minimum of 20 frames.

• Otherwise send the MII_TX_K2[2:0] code.

RX_LOS can be activated high (MII_RX_LOS_LEVEL=0, default value) or activated low (MII_RX_LOS_LEVEL=1). Internally, if MII_RX_LOS_LEVEL=1, MII_RX_LOS is inserted to generate MII_RX_LOS. GR-253 R6-180 to R-182 requirements specify that RDI detection shall be inserted and removed during 125 μs of received LOS, LOF or LAIS.

The 4 LSBs of this byte convey the synchronization status message. Set the transmitted S1 byte equal to MII_TX_S1_[7:0].

The receiver monitors the B2 bit errors in the received signal. The number of B2 errors detected per frame in STS-12c/STM-4 mode ranges from 0 to 96 B2 bits per frame. In STS-3c/STM-1 mode 0 to 24 B2 bits per frame. Typically, the Line/MS Remote Error Indication (REI) byte, the M1 byte, conveys a count of B2 errors detected in the received signal.

By setting TX_M1_ERR=1, the user can force to send REI error indication. At this time, any one of 24 values is sent in the M1 byte (STS-3c/STM-1 mode). If LREI_INH=0, the M1 byte is set equal to the most recent B2 error count. Otherwise, the M1 bytes are all set to zero.

Since the Z1 and Z2 bytes are not standardized, the EOS device 1 fills these bytes with all zeros.

scramble code

A synchronous scrambling sequence is used to scramble the input data, and the scrambling polynomial is x ⁷ +x ⁶ +1. The scrambler at the beginning of the first byte of SPE/VC (byte i located in row 1 and column 10 in STS-3c/STM-1 mode) is initialized to 1111111, except for the first row of TOH/SOH bytes The entire SONET/SDH signal is scrambled. For testing purposes, the scrambler can be disabled by setting SCRINH to 1.

The scrambled LAPS frame (as 155M) output from the scrambling unit 6 is converted into an SDH frame (as 155M) by a FIFO unit (not shown) connected between the scrambling unit 6 and the SPE/BC generating unit 5, the The FIFO unit works in conjunction with a PLL (Phase Locked Loop).

The processing of data in the receive direction is described below.

1. Send to receive loopback and LOC

If R_LOOP=1, the EOS device 1 receiver can be configured to loop back to generate the transmit signal. Otherwise, the signal received from the SONET/SDH interface is selected. In loopback, the TX_SONETCLK input is used to clock the receiver framer and other receive circuitry. If loopback is not selected, the RX_SONETCLK input is used to clock the circuit.

The RX_SONETCLK input is monitored for loss of clock with the TX_CLK input. If no transition is detected on RX_SONETCLK for 16 TX_CLK cycles, the RX_LOC bit is set. When a transition is detected, it is cleared. If RX_LOC transitions from 0 to 1 or from 1 to 0, the RX_LOC_D delta bit is set.

2. Transmission overhead monitoring

The TOH/SOH monitoring block consists of J0, B2, K1K2, S1 and M1 monitoring bytes. These TOH/SOH bytes monitor for errors or changes in state.

2.1.J0 monitoring

J0 monitoring has two modes of operation, one for SONET applications and one for SDH applications. In MII_RX_J0=0 mode (SONET), J0 monitoring consists of checking the received J0 byte value whose value is consistent with 3 consecutive frames. When a consistent J0 value is received, it is written to MII_RX_J0_[15]_[7:0].

In the MII_RX_J0=1 case (SDH), the J0 byte is expected to contain a repeated 16-byte segment trace frame including the segment access point identifier (SAPI). J0 monitoring consists of tracking the start of the 16-byte segment trace frame, checking the received segment trace frame value for a value that matches 3 consecutive segment trace frames. When a consistent frame value is received, it is written to MII_RX_J0_[15:0]_[7:0]. The first byte of the segment trace frame (which includes the frame start flag) is written to MII_RX_J0_[15]_[7:0].

2.1.1. Framing

The most significant bit of all segment trace frame bytes is 0 except for the most significant bit of the start of frame flag byte. The J0 monitor framer searches for 15 consecutive J0 bytes with a 0 in the most significant bit followed by a 1 in the most significant bit of the following J0 bytes. When this pattern is found, the framer goes into frame, J0_OOF=0 at this time. Once the J0 monitor framer is an intraframe, it stays in the frame until at least 1 most significant bit (MSB) bit error is received in 3 consecutive segment trace frames. If MII_RX_J0=0, the J0 frame indication section is constrained to the intraframe state, MII_J0_OOF=0. The MII_J0_OOF_D delta bit is set when MII_J0_OOF changes state.

2.1.2 Pattern reception and comparison

Once within a frame, the J0 monitoring module looks for 3 consecutive 16-byte (MII_RX_J0=1) or 1-byte segment trace frames (MII_RX_J0=0). When three consecutive identical frames are received, the received frame is stored in MII_RX_J0_[15:0]_[7:0] (or in SONET mode, stored in MII_RX_J0[15][7:0]). The received frame is compared with the previous contents of these registers. The MII_RX_J0_D delta (change) bit is set when a new value is stored.

2.2 BIP-96 (B2) verification

In the description of B2 below, the B2 value changes slightly depending on the device model (STS-3c). To illustrate the operation of both cases, the following conventions will be used to determine the requirements for mode STS-3c. The EOS device 1 checks for the correct BIP-8 value in the received B2 byte. (12[3] B2 bytes combined to form 1 BIP-96[BIP-24]). BIP-96 [BIP-24] even parity bits are calculated for all 12 [3] byte groups of each frame, except the first 3 columns of TOH (SOH in SONET and RSOH in SDH). The received data is calculated after descrambling, and the value is compared with the B2 value of the next frame after descrambling. A mismatch of 0 to 96 [0 to 24] can be obtained by comparison (B2 bit error). The number of B2 bit errors detected per frame can be inserted into the M1 bytes sent.

2.2.1 B2 error count

The ROS device 1 includes a 20-bit B2 error counter which counts each B2 error (when BIT_BLKCNT=0) or counts frames with at least one B2 error (when BIT_BLKCNT=1). When the performance monitoring counter is latched (LATCH_EVENT becomes high level), the value of this counter is latched by the B2_ERRCNT[19:0] register, and the B2 error counter is cleared. If at least one B2 error is caused from the last rising edge of LATCH_EVENT, the B2 error second event bit B2ERR_SECE is set, and the B2 error rate threshold module is used.

In order to determine whether the bit error rate of the received signal is higher or lower than two different predetermined threshold values (signal failure and signal attenuation), the EOS device 1 provides two B2 error rate threshold modules. If the SF module or SD module judges that the error rate is higher than the threshold, set B2_ERR_SF or B2_ERR_SD. The delta bit B2_ERR_SF_D or B2_ERR_SD_D is also set if the corresponding error rate bit has changed value. For each error rate threshold module, users can specify a BLOCK register and 2 pairs of THRESH and GROUP registers. To allow hysteresis for setting and clearing the status bits, each error rate threshold block has 1 pair of THRESH and GROUP registers to set the status, and 1 pair of THRESH and GROUP registers to clear the status. So the registers for the error rate threshold block are

When B2_ERR_SF=0, determine whether it should be set, use: B2_BLOCK_SF[7:0], B2_THRESH_SET_SF[7:0], and B2_GROUP_SET_SF[5:0]

When B2_ERR_SF=1, determine whether it should be cleared, use: B2_BLOCK_SF[7:0], B2_THRESH_CLR_SF[7:0], and B2_GROUP_CLR_SF[5:0]

When B2_ERR_SD=0, determine whether it should be set, use: B2_BLOCK_SD[15:0], B2_THRESH_SET_SD[5:0], and B2_GROUP_SET_SD[5:0]

When B2_ERR_SD=1, determine whether it should be cleared, use: B2_BLOCK_SD[15:0], B2_THRESH_CLR_SD[5:0], and B2_GROUP_CLR_SD[5:0]

3. K1K2 monitoring

K1 and K2 bytes are used to send Line (line)/MS AIS or RDI, and for APS signaling, and determine the status change by monitoring this byte.

3.1 Line/MS AIS monitoring and LRDI generation

The 3 LSBs of the K2 byte can be used as AIS or remote defect indication (RDI) at the line/MS layer. If K2_CONSEC[3:0] continuous frames are received with "111", RX_LAIS is set, and RX_LAIS_OUT output is high; if K2_CONSEC[3:0] continuous frames are received with "111", RX_LAIS and RX_LAIS_OUT are cleared. When the RX_LAIS state changes, the RX_LAIS_D delta bit is set.

3.2 Line/MS RDI monitoring

The 3 LSBs of the K2 byte can also be used to monitor whether K2_CONSEC[3:0] is continuously receiving "110" or not receiving continuously. When this happens, set or clear RX_LRDI, and set RX_LRDI_D when RX_LRDI changes state .

3.3APS monitoring

The 4 MSBs of the K1 byte and the K2 byte are used to send the APS request and the channel number. When the same value is received in 3 consecutive frames, it is written to RX_K1_[7:0] and RX_K2_[7 :4]. The received value is then compared with the previous value of the register, and the RX_K1_D delta bit is set when a new 12-bit value appears.

Check the stability of the K1 byte. If out of 12 consecutive frames, no 3 consecutive frames are received with the same K1 byte, the K1_UNSTAB bit is set. Cleared when 3 consecutive identical K1 bytes are received. If K1_UNSTAB changes state, the K1_UNSTAB_D delta bit is set. Bits 3 to 0 of K2 include APS mode information. Monitor these bits of K2_CONSEC[3:0] to find the continuous same value, and write to RX_K2[3:0] when the above situation occurs, unless the 2 bits and 1 bits of the K2 byte are "11" (indicating Line/ MS AIS or RDI). When writing to RX_K2_[3:0] is a new value, set the RX_K2_D delta bit.

The three delta bits MII_RX_K1_D, RX_K2_D and MII_K1_UNSTAB_D are all related to APS monitoring and can provide an APS interrupt signal APS_INTB. Additionally, these delta bits provide the standard accumulation interrupt signal INTB.

3.4S1 monitoring

Monitor the 4 LSBs of the received S1 byte. In SONET mode, MII_RX_SDH_S1=0, find the consistent value in 8 consecutive frames. In SDH mode, MII_RX_SDH_S1=1, find the consistent value in 3 consecutive frames . When these bits contain the same synchronization status message, the received value is written to RX_S1[3:0], and the received value is compared with the previous value of this register, when a new value is stored, MII_RX_S1_D is set delta bits. The S1 byte is also used for message failure detection. The S1 second event bit S1_FAIL_SECE is set if no message since the last rising edge of LATCH_EVENT satisfies the above validity criterion (whether it is the same or different from the last received value).

3.5 M1 monitoring

The M1 byte specifies the number of B2 errors detected by the remote terminal in the received signal. The EOS device 1 includes a 20-bit M1 error counter. When BIT_BLKCNT=0, it counts every error indicated by M1; when BIT_BLKCNT=1, it counts every frame received with M1 not equal to 0. When MII_RX_SIG_MODE=1, the valid value range of M1 with BIT_BLKCNT=0 is 0 to 96; any other value is interpreted as 0 error. When RX_SIG_MODE=0 and BIT_BLKCNT=0, the valid value range of M1 is 0 to 24; any other value is interpreted as 0 error. When the performance monitoring counter is latched, the value of the counter is latched by the M1_ERRCNT[19:0] register, and the M1 error counter is cleared.

If there has been at least one received M1 error indication since the last rising edge of LATCH_EVENT, the M1 error second event bit M1 ERR SECE is set.

4. Transmission overhead separation (drop)

The TOH/SOH separation module outputs received E1, F1 and E2 bytes, and 2 serial DCC channels.

4.1 Command line (E1 and E2) and segment user channel (F1)

The 3 serial outputs MII_RX_E1_DATA, MII_RX_E2_DATA and MII_RX_F1_DATA contain the values of the received E1, E2 and F1 bytes while providing a single notched 64kHz clock reference output (MII_RX_E1E2F1_CLK), after the rising edge of RX_FRAME_OUT, the E1, E2 and F1 bytes The MSB appears on the first 64kHz clock cycle (notched).

4.2 Data communication channel, DCC, (D1-D12)

Two DCCs are defined in TOH/SOH. Section/regeneration section DCC uses D1, D2 and D3 bytes to establish a 192kb/s channel with gaps, and line/multiplex section DCC uses D4 to D12 bytes to establish a gapped 576kb/s channel. The TOH/SOH separation module outputs DCC data RX_SDCC_DATA and RX_LDCC_DATA through 2 serial channels. These channels are synchronized with the outputs MII_RX_SDCC_CLK and MII_RX_LDCC_CLK, and the DCC data output changes on the falling edge of RX_SDCC_CLK and RX_LDCC_CLK.

5. Pointer status determination

Determine the pointer state by checking the H1-H2 bytes, and establish the STS-3c/AU-4 receiving pointer state.

5.1 State change rules

In the following pointer status determination descriptions, the numbers vary slightly depending on the model (STS-3c) of the device. To illustrate the operation of both cases, the following conventions will be utilized to determine the requirements of the mode (STS-3c):

The first pair of H1-H2 bytes contains the STS-3c/AU-4 pointer, monitor the byte pair, they can be considered as one of the following three states:

· Normal (NORM＝00)

·Alarm indication signal (AIS＝01)

Lost pointer ((LOP=10)

The remaining 11[2] pairs of H1-H2 bytes are used to monitor the correct concatenation indication. They can be considered as 1 of the following 3 states:

Cascading (CONC=11)

·Alarm indication signal (AISC＝01)

Lost pointer (LOPC=10)

The respective states are stored in MII_PTR_STATE_[1:12]_[1:0][MII_PTR_STATE_[1:3]_[1:0]], where MII_PTR_STATE_[i]_[1:0] represents the i-th pair H1-H2 state of the byte. Then, combine the individual pairs of H1-H2 bytes to determine the STS-3c/AU-4 pointer status.

5.2 STS-3c/AU-4 pointer status

EOS device 1 provides register status bits MII_RX_PAIS and MII_RX_LOP to indicate the pointer status of the received STS-3c/AU-4 pointer, which may be one of 3 states:

• Normal (MII_RX_PAIS = 0 and RX_LOP = 0) - MII_PTR_STATE_[1]_[1:0] is NORM (00), all other PTR_STATE_[i]_[1:0] are CONC (11).

Channel/AU AIS (MII_RX_PAIS = 1 and RX_LOP = 0) - all PTR_STATE_[i]_[1:0] are AIS or AISC (01).

Loss of pointer (MII_RX_PAIS = 0 and MII_RX_LOP = 1) - all other cases (PTR_STATE_[i]_[1:0] values do not meet normal or channel/AU AIS criteria).

The MII_RX_PAIS and MII_RX_LOP signals provide channel remote fault indication (PRDI). Changes in status bits are indicated by the MII_RX_PAIS_D and MII_RX_LOP_D delta bits.

6. Pointer explanation

The first H1-H2 byte pair is interpreted as the application's start location for the SPE/VC. The pointer interpretation rules are as follows:

1. During normal operation, the pointer locates the start of the SPE/VC.

2. Ignore any change to the currently received pointer unless a consistent new pointer value is received 3 consecutive times, or it precedes any of rules 3, 4, or 5. Any consistent new pointer value received 3 consecutive times takes precedence over rules 3 or 4.

3. When MII_RX_SDH_PI=0, if at least 3 of the 4 NDF bits match the disable indication (0110) and at least 8 of the 10 pointer value bits match the currently received pointer whose 1 bit is inverted, a positive adjustment is indicated . It is considered that the byte following the H3 byte is a positive filling byte, and the currently received pointer value is increased by 1 (modulo 783).

When MII_RX_SDH_PI=1, if at least 3 of the 4 NDF bits match the disable indication (0110), 3 or more of the I-bits of the pointer value and 2 or less of the D-bits of the pointer value match the currently received A pointer with all its bits inverted and the received SS-bit is 10 or MII_RX_SS_EN=0 indicates a positive alignment. It is considered that the byte following the H3 byte is a positive filling byte, and the currently received pointer value is increased by 1 (modulo 783).

4. When MII_RX_SDH_PI = 0, a negative adjustment is indicated if at least 3 of the 4 NDF bits match the disable indication (0110) and at least 8 of the 10 pointer value bits match the currently received pointer whose D bit is inverted . The H3 byte is considered a negative padding byte (it is part of the SPE) and the currently received pointer value is decremented by 1 (modulo 783).

When MII_RX_SDH_PI=1, if at least 3 of the 4 NDF bits match the disable indication (0110), 3 or more of the pointer value D-bits and 2 or less of the pointer value I-bits match the currently received A pointer with all its bits inverted and the received SS-bit is 10 or MII_RX_SS_EN=0 indicates a negative adjustment. The H3 byte is considered a negative padding byte (it is part of the VC) and the currently received pointer value is decremented by 1 (modulo 783).

5. When MII_RX_SDH_PI=0, if at least 3 of the 4 NDF bits match the prohibition indication (1001), and the pointer value is between 0 and 782, the received pointer replaces the currently received pointer value.

When MII_RX_SDH_PI=1, if at least 3 of the 4 NDF bits match disable indication (1001), the pointer value is between 0 and 782, and the received SS-bit is 10 or MII_RX_SS_EN=0, then the received pointer replaces The currently received pointer value.

Using these pointer interpretation rules, the pointer interpreter module determines the location of the SPE/VC payload and POH bytes.

6.1 Pointer handling

For the implementation of the pointer tracking algorithm in EOS device 1, please refer to the transition definitions in [G.783] and [GR-253]. The pointer tracking state machine is based on the pointer tracking state machine determined by the ITU-T recommendation, which is as valid for Bellcore as the ANSI standard. In Bellcore mode, there is no state machine transition from AIS to LOP (ie by setting the BELLCORE bit to logic 1).

EOS device 1 uses four pointer tracking state machines, one for each AU-4/STS-3c. Pointer tracking takes H11 and H21 bytes, the pointer is extracted from the concatenation of H1n and H2n bytes, explained as follows:

N=new data flag bit, when valid=1001 or 0001/1101/1011/1000, when normal or invalid, it is equal to 0110 or 1110/0010/0100/0111 (that is, single-bit error can be tolerated).

SS = Size bit in pointer tracking state machine interpretation, if valid, by setting the BELLCORE control bit to 0. These bits are ignored when BELLCORE is set to 1, but are 10 when it is set to 0.

I = Incremental bits, defined as bit 7 of H1n and bits 1, 3, 5 and 7 of H2n.

D = Lowered bits, defined as bit 8 of Hln and bits 2, 4, 6 and 8 of H2n.

Negative adjustment: 5 D-bits inverted, receive majority rule. 8 of the 10 objects in O3-92 of [GR-253] can be enabled by setting the Just ITU bit to 0 in OR#Conf3.

Positive justification: Inverted 5 I-bits, receive majority rule. 8 of the 10 objects in O3-92 of [GR-253] can be enabled by setting the Just ITU bit to 0 in OR#Conf3.

For STM-1/STS-3c mode of operation, the pointer is a binary value ranging from 0 to 782 (decimal). It is a 10-bit value derived from the two least significant bits of the H1 byte, which, together with the concatenated H2 byte, form an offset field 3 bytes from the position of the H3 byte. For example, for an STM-1 signal, a pointer value of 0 indicates that VC-4 starts 3 bytes after the H3 byte, and an offset of 87 indicates that VC-4 starts 3 bytes after the K2 byte.

In STM-4/STS-12 mode there are 4 bytes - interleaved AU-4, so there are 4 H1/H2 byte pairs used to determine the start of their respective VC-4 (ie J1 byte position). In this case, running 4 pointer tracking state machines is equivalent to running 4*STM-1/STS-3c.

When processing STS-12c/STM-4c, the pointer tracking state machine of Macro 1 is used to locate the start of VC-4-4c. Use H11 and H21 bytes for pointer tracking, the pointer is extracted from the H11 and H21 byte concatenation, and the pointer interpretation is as described above. But the formed offset is a 12-byte count value whose value is counted from the H3 byte position. For example, for an STM-12c signal, a pointer value of 0 indicates that VC-4 starts 12 bytes after the H3 byte, and an offset of 87 indicates that VC-4 starts 12 bytes after the K2 byte. The concatenation indication byte is also checked in the corresponding macro (macro 2-4), monitored corresponding to LOP and HPAIS per state machine in Annex C of [G.783]. The state diagram below illustrates the state transitions of the cascade indicator. Please refer to [G.783] for conversion definition.

In addition, 8-bit counters are used to record positive and negative adjustment events, as well as NDF events. Status bits are provided to indicate detection of negative justification, positive justification, NDF, invalid pointer, new pointer, and cascade indication. When entering the LOP or LOPC state in the above figure, the LOP interrupt request bit will be set in the relevant OR#IRQ2 register. Similarly, if the AIS or AISC state is entered, the relevant HPAIS interrupt request will be set.

After processing the pointer, the FIFO unit (not shown) connecting the pointer processing unit 10 and the descrambling unit 11 converts the SDH/SONET frame (such as 155.520Mb/s) into a LAPS frame (such as 155.520Mb/s), and uses the PLL to complete the action.

7. Channel overhead monitoring

The POH (path overhead) monitoring module consists of J1, B3, C2 and G1 monitoring. These channel overhead bytes are used to monitor for errors or changes in state.

7.1 Channel Tracking (J1) Capture/Monitoring

By inserting the J1 byte, the EOS device 1 supports two channel trace (J1) capture methods. The first is mainly used in SONET, capturing 64 consecutive J1 bytes in STS-3c/AU-4. The second, for SDH, looks for repeated patterns of 16 consecutive J1 bytes. When a consistent 16-byte pattern is detected in 3 consecutive events, the J1 pattern is stored in the specified register.

7.1.1 SONETJ1 Capture

When MII_RX_SDH_J1 = 0 (SONET mode), the EOS device 1 can provide capture channel trace message samples. When J1_CAP transitions from 0 to 1, EOS device 1 continuously captures 64 J1 bytes from the specified extension and writes them to MII_RX_J1_[63:0]_[7:0].

There is no channel trace frame structure defined in SONET, but GR-253 does suggest a 64-byte sequence consisting of a string of ASCII characters with a null character (00) filling the 62 bytes and ending with <CR> (0D) and <LF> (0A) bytes. If the J1_CRLF bit is set, the EOS device 1 captures the first 64-byte string received in the J1 byte position ending with {OA, 0D}. If J1_CRLF=0, the EOS device 1 captures the next 64 bytes of J1 bytes regardless of their content. Once the capture is complete, the EOS device 1 sets the J1_CAP_E event bit.

7.1.2 16 byte J1 monitoring

If MII_RX_SDH_J1=1 (generally used in SDH mode), the J1 byte is expected to contain a repeated 16-byte channel trace frame including PAPI. In this mode, the J1_CAP, J1_CRLF and J1_CAP_E bits are not used. J1 monitoring includes automatic tracking of the 16-byte channel trace frame start, checking the receive channel trace frame value to find a value that matches 3 consecutive frames. When a consistent frame value is received, it is written to MII_RX_J1_[15:0]_[7:0]. The first byte of the channel trace frame (which includes the frame start flag) is written to MII_RX_J1_[15]_[7:0].

Framing. All channel trace frame bytes have the most significant bit set to 0 except for the MSB of the start-of-frame flag byte. The J1 monitor framer searches for 15 consecutive J1 bytes with a 0 in the most significant bit followed by a J1 byte with a 1 in the most significant bit. Once this pattern is found, the framer enters the frame, J1_OOF=0 at this time. Once the J1 monitor framer is intra-framed, it remains in-frame until it receives 3 consecutive channel trace frames with at least 1 most significant bit (MSB) bit error. (In SONET mode, the J1 frame indication remains in the intraframe state, J1_OOF=0). If the J1_OOF state changes, the J1_OOF_D delta bit is set.

Pattern reception and comparison. Once within the frame, the J1 monitoring module looks for 3 consecutive 16-byte channel trace frames. When 3 consecutive identical frames are received, the received frames are stored in MII_RX_J1_[15:0]_[7:0].

The received frame is compared with the previous contents of these registers, and when a new value is stored, the delta bit of RX_J1_D is set.

7.2.BIP-8(B3) verification

The EOS device 1 checks for the correct BIP-8 value in the received B3 byte. By calculating the even parity bits of BIP-8 for all bits in each frame SPE/VC (including POH). These values are then compared with the B3 value received in the next frame. The result of the comparison may be 0 to 8 mismatches (B3 bit error), this value is inserted into the sender G1 byte.

The EOS device 1 contains a 16-bit B3 error counter which counts every B3 bit error (if BIT_BLKCNT=0) or every frame with at least one B3 bit error (if BIT_BLKCNT=1). When the performance monitoring counter is locked (LATCH_EVENT transitions to a high bit), the value of the counter is locked to the B3ERRCNT_[15:0] register, and the B3 error counter is cleared. If there has been at least one B3 error since the last rising edge of LATCH_EVENT, the B3 Error Secondary Event bit B3ERR_SECE is set.

7.3. Signal tag (C2) monitoring

The received C2 bytes are monitored to confirm that the correct payload type is received. When a consistent C2 value is received over 5 consecutive frames, write the received value into MII_RX_C2[7:0]. When a new C2 value is received, the delta bit of MII_RX_C2D is set.

The received expected value of C2 is left in EXP_C2[7:0]. If the currently received value does not match the expected value, and the received value does not meet the following conditions, set the payload label mismatch register bit MII_RX_PLM to high:

●All 0, unprepared label;

01 (hexadecimal), prepared non-specific label;

● FC (hexadecimal), with a payload defect label;

● FF (hexadecimal), reserved label.

If the currently received value is untagged, all zeros, EXP_C2! = 00 (hexadecimal), then the unequipped register bit (Unequipped register bit) MII_RX_UNEQ is set to high.

MII_RX_PLM and MII_RX_UNEQ signals for channel RDI to insert on the transmit side. The MII_RX_PLM or MII_RX_UNEQ delta bit is set when MII_RX_PLM or MII_RX_UNEQ changes its state.

7.4. Channel status (G1) monitoring

G1 monitoring includes channel REI monitoring and channel RDI monitoring.

7.4.1. Channel REI monitoring

Bits 1 through 4 (the 4 most significant bits) of the Channel Status Byte indicate the number of B3 errors detected by the remote terminal in the signal it received. Only binary values between 0 and 8 are legal. If a value greater than 8 is received, it is interpreted as a 0 error (as specified in GR-253 and ITU-T Recommendation G.707). The EOS device 1 contains a 16-bit G1 error counter which counts every error indicated by G1 (if BIT_BLKCNT=0), or every frame received for which the first 4 G1 bits are not equal to 0 (if BIT_BLKCNT=1). When the performance monitoring counter is locked (LATCH_EVENT transitions to high), the value of the counter is assigned to the G1_ERRCNT[15:0] register, and the G1 error counter is cleared.

The G1 Error Second Event bit G1ERR_SECE is set if there has been at least one received G1 error indication since the last rising edge of LATCH_EVENT.

7.4.2 Channel RDT monitoring

If MII_RX_PRDI5=1, the EOS device 1 can monitor bit 5 of G1 (RDI-P indicator); if MII_RX_PRDI5=0, it can monitor bits 5, 6 and 7 of G1 (enhanced RDI-P indicator). The monitoring process includes checking for identical values in consecutive received values of the G1_CONSEC[3:0] monitoring bits. When the exact same value is received, bits 5, 6 and 7 of G1 are written to MII_RX_G1[2:0]. The received value is compared with the previous value of this register (all 3 bits are written, but if MII_RX_PRDI5=1, only bit 5 of G1 is compared with MUU_RX_G1[2]). When storing a new value, the MII_RX_G1_D delta bit is set.

7.5. Other POH bytes

The EOS device 1 does not monitor the remaining bytes of the POH. These bytes include channel user channel (F2), location indicator (H4), channel growth/user channel (Z3/F3), channel growth/channel APS channel (Z4/K3), and front and rear connection monitoring (Z5/N1) words Festival.

8. Receive payload descrambling

After extracting the payload from the SONET/SDH signal, the payload data is descrambled with a self-synchronous X ⁴³ +1 descrambler. In all modes, the register MII_RX_DSCR_INH controls the operation of the descrambler. When MII_RX_DSCR_INH=0 (default), the descrambler works normally. When MII_RX_DSCR_INH=1, the descrambler is disabled.

The EOS device 1 provides a self-synchronizing descrambler based on the generator polynomial X ⁴³ +1 as follows.

9. Receive LAPS processing

Here the SPE has been extracted from the SONET/SDH frame, and then enters the LAPS processor for further processing. In EOS mode (MII_RX_EOS=1), the LAPS processing process is to extract LAPS packets/frames from the SPE.

9.1 LAPS framer

In EOS mode (MII_RX_EOS=1), the LAPS frame is extracted from the SPE payload by identifying the frame start/end flag sequence (0x7e).

EOS device 1 checks each octet in the payload. When the octet with the bit pattern of 0x7e is detected, EOS device 1 thinks that this is the beginning/end of a packet, and then checks the octet after the flag sequence octet. If they are still 0x7e, they are considered to be flag sequences used to fill gaps between packets and discarded. The first octet following the start flag sequence and not equal to 0x7e is considered to be the first octet of the LAPS frame. After the start of frame flag, the EOS device 1 continues to check each octet of the payload, looking for the flag sequence. If the bit pattern 0x7e position is found and the preceding octet is a control escape code (0x7d), the frame is aborted; otherwise, it is considered to be the normal end of the current frame. In the special case where termination of the FCS field is disabled, a minimum of 2 marker sequences must be detected between frame signals.

9.2 Removal of transparent byte padding

9.3.1 EOS mode

In EOS mode (MII_RX_EOS=1), after the LAPS frame, the EOS device 1 reverses the transparent byte stuffing process to restore the original packet flow. The FIFO underflow byte sequence is inserted by the sender during the FIFO underflow process. If MII_RX_EOS_FIFOUNDR_MODE=1, it needs to be detected and deleted during transparent processing. The default value is disabled: MII_RX_EOS_FIFOUNDR_MODE=0. The special FIFO underflow bytecode can be programmed using register MII_RX_EOS_FIFOUNDR_BYTE[7:0].

9.3.2 Underflow byte deletion

In EOS mode, if MII_RX_EOS_FIFOUNDR_MODE=1, the byte matching the FIFO underflow byte (MII_RX_EOS_FIFOUNDR_BYTE[7:0]) is discarded if it is not followed by the control escape code (0x7d).

9.4 Error frame

In EOS mode (MII_RX_EOS=1), a special byte code (0x7d7e) is used to indicate that the frame has been aborted. If this bytecode is received, the frame containing this bytecode is aborted. No more octets are put into the FIFO; if the packet was sent to a link-layer device, it is marked as an error.

The EOS device 1 includes an 8-bit error counter that counts each packet in which an abort sequence is detected. When the performance monitoring counter is latched (LATCH_EVENT becomes high level), the value of the counter is latched by the register MII_RX_EOS_PABORT_ERRCNT[7:0], and the packet abort error counter is cleared.

If at least 1 packet abort error has been caused from the last rising edge of LATCH_EVENT, the packet abort error second event bit MII_RX EOS_PABORT ERR_SECE needs to be set.

As an alternative, it is also possible to abort 1 packet by inverting the FCS byte. This is only 1 type of FCS error for the EOS device 1 to receive the LAPS processor. Its processing process is described in the following paragraphs.

As an option, the EOS device 1 can also treat packets as error packets and thus flag them according to whether they violate minimum or maximum packet regulations. The size of the packet refers only to the size of the packet coming out of the EOS device 1, excluding the removed flag sequence, address byte, control byte, transparent byte, FIFO underflow byte and FCS byte. These minimum and maximum lengths are programmable through the management interface. The register MII_RX_EOS_PMIN[3:0] contains the minimum packet length, and the default value of this register is 0; the register MII_RX_EOS_PMAX[15:0] contains the maximum length, and the default value of this register is 0x05E0.

When commanded through the management interface, the EOS device 1 can enable/disable the minimum and maximum length check functions. The registers MII_RX_EOS_PMIN_ENB and MII_RX_EOS_PMAX_ENB (both default values are 0) control how to deal with violations of the minimum and maximum packet lengths. When any register is set to 1, any violation of the corresponding packet length will be marked as an error.

The EOS device 1 includes two 8-bit error counters, counting each violation of the minimum and maximum packet length constraints. When the performance monitoring counters are latched (LATCH_EVENT goes high), these counter values are latched by registers MII_RX_EOS_PMIN_ERRCNT[7:0] and MII_RX_EOS_PMAX_ERRCNT[7:0], and the packet violation counters are cleared.

If at least 1 packet size violation error has been caused since the last rising edge of LATCH_EVENT, the appropriate packet size violation second event bit MII_RX_EOS_PMIN_ERR_SECE or MII_RX_EOS_PMAX_ERR_SECE is set.

9.5 Frame Check Sequence (FCS) Field

In EOS mode (MII_RX_EOS=1), the FCS is calculated and the FCS bytes are checked at the end of each frame. This option is controlled by the register MII_RX_EOS_FCS_INH. When the value MII_RX_EOS_FCS_INH=0, the FCS is valid; when the value MII_RX_EOS_FCS_INH=1, the FCS is invalid. Only a 32-bit check sequence (CRC-32) is used. MII_RX_EOS_FCS_MODE=0 makes the device operate in FCS-32 mode.

EOS device 1 provides CRC-32 function, using generator polynomial as: 1+x+x ² +x ⁴ +x ⁵ +x ⁷ +x ⁸ +x ¹⁰ +x ¹¹ +x 12 +x ¹⁶ +x ²² + ^{x 23} +x ²⁶ +x ³² . The FCS field is calculated for all frame code points except the flag sequence and the FCS field itself.

If MII_RX_EOS_FCS_BIT_ORDR=0 (default value), the received signal is read into the shift register in the order of the most significant bit (MSB first); if MII_RX_EOS_FCS_BIT_ORDR=1, the received signal is read in the order of the least significant bit (LSB first) into the shift register. In either case, after the FCS is calculated, the data is stored in the most significant bits for processing.

The obtained FCS result value is compared with the received FCS field value. If an error is detected, the management control interface is notified, the corresponding counter is incremented by 1, and the last word of the packet in the FIFO is marked as an error. EOS device 1 contains a 20-bit FCS error counter that counts each FCS CRC violation. When the performance monitoring counter is latched (LATCH_EVENT becomes high level), the value of the counter is latched by the register MII_RX_EOS_FCS_ERRCNT[19:0], and the FCS error counter is cleared.

If at least 1 FCS error has been caused since the last rising edge of LATCH_EVENT, the FCS Error Second Event bit MII_RX_EOS_FCS_ERR_SECE is set.

After the FCS check, terminate the FCS bytes (they are not stored to the FIFO). The last 2 or 4 bytes are sent to the FIFO if FCS checking is disabled through the management interface. Assuming an FCS error is detected, the packet is marked as errored (RX_ERR) when sent to the link layer device.

9.6 LAPS Frame Termination

In EOS mode (MII_RX_EOS=1), after FCS calculation, the following LAPS bytes are monitored and optionally terminated.

9.6.1 Flag sequence

All flag sequences present for frame delineation and intraframe filling purposes are removed. The start and end flags of the frame information are still reserved by the EOS device 1 and sent to the link layer through the RX_SOP and RX_EOP signals.

9.6.2 Address and Control Bytes

The address and control bytes (the first two bytes in the LAPS frame following the flag sequence) are monitored by the EOS device 1, which includes checking the valid address field and the control field (0xFF03). If a mismatch is detected, the field is considered compressed and not sent. If an invalid value is detected, the two bytes are not separated and passed to the link layer through the MII interface. The management control interface is notified of the detection of an invalid address and control field by setting MII_RX_EOS_ADRCTL_INVALID=1. By setting the corresponding delta bit of MII_RX_EOS_ADRCTL_INVALID_D to 1, it indicates that the state of MII_RX_EOS_ADRCTL_INVALID has changed.

If a valid address and control field is detected, the EOS device 1 terminates these two bytes without passing to the RX FIFO. By setting MII_RX_EOS_ADRCTL_DROP_INH = 1, the effective address and control bytes can be prohibited from being deleted. The default value of this register is 0 (automatic separation is valid).

9.6.3 FCS bytes

As mentioned in the FCS section, EOS device 1 may also terminate with 4 FCS bytes. If the FCS check is prohibited through the management control interface (MII_RX_EOS_FCS_INH=1), the termination function is also prohibited, and the last 4 bytes of the LAPS frame are sent to the link layer.

10 Receive FIFO interface

10.1 System side packet loopback

The EOS device 1 provides the user with the function of loopback receiving packets through the system interface.

When SYS_T_TO_R_LOOP=1, the packet received from the link layer device is directly routed from the sending FIFO to the receiving FIFO, and then output back to the link layer device that originally sent the cell data. When SYS_T_TO_R_LOOP is set to 0, packets received within the SONET/SDH link signal are sent to the receive FIFO and then output to the system interface.

10.2 FIFO processing

The EOS device 1 writes the packet to the FIFO, ready to be output to the link layer device through the interface of the receiving system. The minimum FIFO size is 512 octets. Along with packets, the following applicable identifiers must accompany each word of the FIFO: start of packet, end of packet, whether the packet is over, how many octets are in the word (1 or 2), and whether the packet is in error. Once an error is detected in the packet signal, no further bytes are loaded into the FIFO for the packet.

The FIFO status is monitored by the EOS device 1 . By setting MII_RX_FIFOOVER_E=1, the FIFO overflow event is reported to the management control interface, and the occurrence of FIFO underflow will also increase the corresponding performance monitoring counter.

The EOS device 1 includes an 8-bit FIFO underflow error counter, counting each packet affected by the FIFO underflow event. When the performance monitoring counter is latched (LATCH_EVENT becomes high level), the value of the counter is latched by the register MII_RX_FIFOOVER_ERRCNT[7:0], and the FIFO underflow error counter is cleared.

The FIFO underflow error event bit MII_RX_FIFOOVER_ERR_SECE is set if at least one FIFO underflow event has occurred since the last rising edge of LATCH_EVENT.

Once an underflow error is detected, no more bytes of the packet are sent to the FIFO. In EOS mode (MII_RX_EOS=1), the last word of the packet is marked as an error (RX_ERR).

The FIFO is just before the compatible interface of the receiving system, and its purpose is to complete the rate matching function between the SONET clock domain and the link layer clock domain.

10.3 Error Packet Handling

The RX processing unit 12 provides a determining unit (not shown), which is used to determine the type of the received data packet, generate a corresponding predetermined SAPI, and check errors occurring in the frame.

In EOS mode (MII_RX_EOS=1), for a packet corrupted by a FIFO overflow event, the EOS device 1 marks it as an error packet with RX_ERR.

Invalid frames are:

a) is not correctly bounded by two flag sequences; or

b) fewer than 8 octets between frame marker sequences; or

c) contains a frame check sequence error; or

d) contain a service access point identifier that the receiver does not match or support (see A.3.3 of ITU-T X.85); or

e) contains an unrecognized control field value; or

f) The end flag is a sequence of more than six "1" bits.

Invalid frames will be discarded without notification to the sender and without any action.

10.4. Receive data parity check

As specified by the MAC-PHY, the EOS device 1 provides 1 parity bit following every octet or word of two octets sent to the link layer (MII_RX_SYS_DAT[15:0]). This parity bit is provided at the RX_PRTY pin. By default (MII_RX_PRTY_MODE=0), this bit provides odd parity; when MII_RX_PRTY_MODE=1, even parity is provided.

Rate adaptation from LAPS to MII is performed in RX_FIFO 13. Periodic LAPS frames (such as 155M) output from the RX_LAPS processing unit 12 are converted into burst MII frames (such as 100M). The reverse rate adaptation process is performed in the TX FIFO. After processing, the received SDH/SONET frames are converted into MII frames and transmitted to the Ethernet layer through the converter 19 .

MII interface requirements

The requirements of EOS device 1 for the MII interface are based on the IEEE 802.3 definition of the Coordination Sublayer and the Media Independent Interface.

FIG. 13 is a detailed functional block diagram of the converter 19 in FIG. 9 . The definitions used in the figure are as follows:

TX_ER: Send encoding error; TXD: Send data; TX_EN: Send enable; TX_CLK: Send clock; GTX_CLK: Gigabit send clock; COL: Collision detection; RXD: Receive data; RX_EN: Receive enable; RX_CLK: Receive clock; CRS: carrier sense; RX_DV: received data is valid; MDC: management data clock; MDIO: management data input/output; TSOF: start of frame transmission; TEOF: end of frame transmission; TCLK: transmission clock; TENA: transmission write permission; TFA : Transmit frame available; TxDATA: Transmit data; RSOF: Start of frame reception; REOF: End of frame reception; RCLK: Receive clock; RV: Receive data valid; RFA: Receive frame available; RxDATA: Receive data.

It should be pointed out that the signal items marked with parentheses change, and there are two selection methods here: For Ethernet/Fast (fast) Ethernet over SDH/SONET, TxDATA<7:0> (8×19.44MHZ) is used , RxDATA<7:0>(8×19.44MHZ), TXD<3:0>(4×25MHZ), RXD<3:0>(4×25MHZ) and TX_CLK(25MHZ). For Gigabit (preamble bit) Ethernetover SDH/SONET including GTX_CLK direction, use: TxDATA<31:0>(32×78.76MHZ)/<63:0>(64×38.88MHZ), RxDATA<31:0> (32×78.76MHZ)/<63:0>(64×38.88MHZ), TXD<7:0>(8×125MHZ), RXD<7:0>(8×125MHZ) and GTX_CLK(125MHZ).

As shown in FIG. 13, the converter 19 performs the conversion function between the MII/GMII interface and the WRI interface.

1. Synchronization of conversion modules between input and output

MII and GMII are compatible with IEEE 802.3 standard. TX_CLK (Transmit Clock) or GTX_CLK (Gigabit Transmit Clock) is a continuous clock that provides a timing reference for TX_EN, TXD, and TX_ER transfers. RX_CLK (Transmit Clock or Gigabit Transmit Clock) is a continuous clock that provides the timing reference for TX_DV, RXD, and RX_ER transitions. When the auto-negotiation process selects the full-duplex working mode, the working states of the COL (collision detection) signal and the CRS (carrier sense) are not described in detail.

In the sending direction of the EOS device, the MII/GMII and WRI interfaces are input and output interfaces respectively, and in the receiving direction, the MII/GMII and WRI interfaces are output and input interfaces respectively. The WRI interface provides the following two parallel transmission and reception data transfer methods, both of which use a clock rate independent of the wire speed: 8bits (bits) × 19.44MHz at the STM-1/OC-3c rate; -16/OC-48c rate is 32bits×78.76MHz/64bits×38.88MHz. The EOS chip supports frame rate decoupling through a FIFO between the converter and the LAPS processor.

In order to simplify the interface between MII/GMII layer and EOS, and support multiple physical layer (PHY) interfaces, converter 19 and FIFO are used. Control signals are provided to support both MII/GMII layer and EOS layer devices to allow EOS to perform flow control at the WRI interface. Since the bus interface is based on a point-to-point connection, the receiving interface of the EOS device pushes the data into the MII/GMII layer device through FIFO and converter 19 . The frame state granularity available at the transmit and receive interfaces is based on octets. In the receiving direction, when the EOS layer device has stored the end of a frame (the end of a small LAPS frame or a large LAPS frame) or a predetermined number of bytes in its receive FIFO, the MII/GMII layer is sent to the MII/GMII layer by the converter 19 The device sends the in-band address, followed by the FIFO data. The data on the WRI interface bus is marked with a receive valid signal (RV).

A multi-port EOS device with multiple FIFOs can operate in a round-bin manner for each port when there is enough data in its FIFO. The WRI interface can suspend the data flow according to IEEE 802.3x and the associated switch 19 via the enable-not-maintain signal (RENB). In the sending direction, when the EOS layer device has space to send a predetermined number of bytes in the FIFO, it will notify the MII/GMII layer device through the converter 19 by declaring that a transmit frame is available (transmitframe available, TFA). The MII/GMII layer device can use a enable signal (TENB) on the WRI interface to write the in-band address followed by the frame data to the EOS layer device. Translator 19 monitors TFA for a high to low transition indicating that the transmit FIFO is nearly full (the number of bytes remaining in the FIFO is user-selectable but must be predefined), suspending data transfers to avoid underflow. Converter 19 can suspend data flow by not asserting enable signal (TENB).

In the transmit direction, WRI-PHY defines frame-level transfer control. Since the frame size is variable, it does not provide any guarantee of the number of available bytes. In both directions of sending and receiving signals, a selection of available EOS sending frames is provided on the STFA, and the received data is valid on the signal RV. STFA and RV always reflect the state of the selected EOS from which data is being transferred to and then transferred from. RV indicates whether valid data is available on the receive data bus and is defined such that data transfers can be aligned to frame boundaries. The physical layer port is selected with in-band addressing. In the transmit direction, the MII/GMII device selects the EOS port by sending an address on the TxDATA<7:0> or TxDATA<31:0>/TxDATA<63:0> bus with the TSX signal active, the TENB signal Inactive flag. All subsequent TxDATA<7:0> or TxDATA<31:0>/TxDATA<63:0> bus transactions that mark TENB active are frame data for the specified port. In the receive direction, the MII/GMII device specifies the selected port by sending an address on the RxDATA<7:0> or RxDATA<31:0>/RxDATA<63:0> bus with the RSX signal active and the RV signal Inactive flag. All subsequent RxDATA<7:0> or RxDATA<31:0>/RxDATA<63:0> bus transactions that mark RV active are frame data for the specified port.

In order to support the existing small number of multi-port EOS layer devices and future high-density multi-port devices, when the number of ports of the EOS layer device is limited, the byte-level transfer of the DFTA signal provides a simpler implementation method while reducing the number of required addressing pins. In this case, as the number of ports increases, direct access becomes unreasonable. When the number of ports is large, the number of pins required for frame-level transfer is much smaller by using the TADR bus. In-band addressing guarantees that the protocol remains the same for both methods. However, which method the system designer and physical layer device manufacturer chooses depends on which method is more suitable for the application they want.

2. Data structure of converter 19

A defined data structure should be used to write frames to the transmit FIFO and to read frames from the receive FIFO. Octets are read and written in the same order as they are sent or received on the SDH/SONET line. The most significant bit (bit 7) is sent first in an octet (see Figure 7/ITU-T Draft Recommendation X.86). EOS devices can be used to transfer 1-byte frames. In this case, both the start and end of the frame signal are declared. For frames whose frame length exceeds the FIFO of the EOS device, the frame must be transferred through the WRI interface. The number of bytes of data per frame in each segment can be fixed or variable, depending on the specific application. MII/GMII can be determined by sending fixed size frame segments on the MII/GMII interface through the converter 19, or using the TFA signal on the WRI interface when the FIFO is full. For multiple MII/GMII port applications, TPAS (Transmit Port Address Selection) is used to indicate that the in-band port address selection on the TxDATA bus is valid. When TPAS is high and TENB is also high, the value of TxDATA[7:0] or TxDATA<31:0>/TxDATA<63:0> is the address of the transmit FIFO to be selected. Subsequent data transfers on the TxDATA bus fill the FIFO specified by this in-band address. For single-port EOS devices, the TPAS signal is optional because EOS devices will ignore in-band addresses when TENB is high. TPAS is only valid if no TENB is declared.

In the 32-bit/64-bit bus interface and the 8-bit bus interface, the in-band port address of the multi-port EOS device is not shown. The converter 19 should send the MII/GMII port address on the same bus as the data, and the bus flag TPAS signal is in an active state, and the TENB signal is in an inactive state. Subsequent data transfers on the WRI interface use the transmit FIFO with in-band address selection. On the receiving interface, before transferring the frame data, the EOS device uses the RPAS (Receive Port Address Selection) signal to be active, and the RV signal to be inactive to report the receive FIFO address in-band (the receive FIFO address in-band). For both cases, large frames exceeding the size of the FIFO are diverted via the WRI interface by prefixing each segment with the appropriate in-band address.

The in-band address is specified in a single clock cycle operation marked by the TPAS/RPAS signal. The port address is determined by the TxDATA[7:0] and RxDATA[7:0] signals or the TxDATA[31:0]/TxDATA[63:0] and RxDATA[31:0]/RxDATA[63:0] signals. In the numerical encoding mode, the address is TxDATA[7:0] and RxDATA[7:0] signals or TxDATA[31:0]/TxDATA[63:0] and RxDATA[31:0]/RxDATA[63:0] The value of the signal, where bit 0 is the least significant bit and bit 7 is the most significant bit. Thus, a single interface can support up to 256 ports. For 32-bit interfaces, ignore the upper 24 bits, and for 64-bit interfaces, ignore the upper 56 bits.

According to the draft ITU-T Recommendation, the Frame Check Sequence (FCS) has to be processed in the LAPS processor. If the EOS device does not optionally insert FCS bytes before transmission, these bytes shall be included at the end of the packet. If the EOS device does not strip the FCS field in the receive direction, these bytes shall remain at the end of the packet.

management control interface

The following describes the management control interface corresponding to the EOS device, defining all register addresses that can be read and written by the external microprocessor. A table is used here that contains the common configuration and the Summary Status Map, which holds control and monitoring parameters common to the entire device. On the sending side, the table is a management control interface register map, and on the receiving side, each block is a management control interface register map. The most significant bits ADDR[8:0] of the microprocessor bus address indicate whether the mapping is related to the transmit or receive direction. ADDR[7:0] indicate special mappings, and these values are identified with each mapping detailed later. The common configuration and overall mapping is ADDR[8]=0.

1. Interrupt or polling (polled) operation

The management control interface works in interrupt-driven or polling mode. In both modes, the EOS device register bit SUM INT in the common configuration and overall status map address 0x002 is used to determine whether the monitoring register status in the EOS device has changed.

1.1 Interrupt sources

1.1.1 Sending end

Transmit Side register map (Transmit Side register map) almost determines the SONET/SDH signal composition and provides all provisioning parameters of LAPS, SONET/SDH POH and SONET/SDH TOH/SOH values. In addition to these specified parameters, the transmitter register map includes system interfaces and general I/O monitors. If any of these indications is active, the SUM_INT bit in Register 0x002 is high (logic 1). If SUM_INT_MASK=0, the microprocessor interface interrupt output (INTB) is active (logic 0).

1.1.2 Receiver

This table also contains the overall status bits of the receiver in Register 0x005. These bits feed the SUM_INT bits in Register 0x002. If any of the overall status bits is "1", and the corresponding mask bit is "0", then the SUM_INT bit is set to "1". The overall status bit in register 0x005 (TBD) in the table is "1" if one or more of the corresponding bit groups in the table (TBD) is "1". A single TOH/SOH delta and Second event bit (Table (TBD), e.g. address 0x204-0x206) can be masked.

1.2 Interrupt-driven

In interrupt-driven mode, the SUM_INT_MASK bit of Register 0x006 of the Common Configuration and Overall Status Map should be cleared (set to 0). This allows the INTB output to be an active bit (logic 0). The output is INTB=! (!SUM_INT_MASK && SUM_INT). Additionally, the MII_RX_APS_INT_MASK bit should be cleared (set to logic 0) on the receiver side. This allows the APS_INTB output to be an active bit (logic 0), which output is APS_INTB=! (!MII_RX_APS_INT_MASK &&MII_RX_APS_INT). If an interrupt has occurred, the microprocessor first reads the overall status registers 0x004-0x005 to determine the active interrupt source class, and then reads the special registers within that class to determine the precise cause of the interrupt.

1.3 Polling mode

In polling mode, the SUM INT MASK and MII RX_APS_INT MASK bits should be set (to logic 1) to suppress all hardware interrupts and operate in polling mode. In this mode, the EOS device 1 outputs INTB and APS_INTB remains inactive (logic 1).

It should be noted that the SUM_INT_MASK and MII_RX_APS_INT_MASK bits do not affect the state of register bits SUM_INT and MII_RX_APS_INT. These bits can be polled to determine if the register needs to be interrogated further.

microprocessor interface

The microprocessor interface 18 to the EOS device enables the system to access all registers in the OS device. The microprocessor interface can run in interrupt driven or polled mode. In interrupt mode, EOS devices support multiple interrupt sources. Regardless of the mode, the EOS device can mask any interruption.

Since other segments in the EOS device of the present invention are well known, related descriptions are omitted here.

The invention has been described above with reference to SDH/SONET, however, the invention can also be used in simplified SDH/SONET. Simplified SDH/SONET refers to a simplified SDH/SONET in which the POH is terminated to reduce processor load.

Fig. 14 shows according to the embodiment of the present invention, makes the SDH private network connect with the 2-layer switch (named as S24-2OC-48) of 10BASE-T, 100BASE-T and 1000BASE-x with EOS device.

The definitions used in the figure are as follows: GMAC, Gigabit Media Access Control; GMII, Gigabit Media Independent Interface; MAC, Media Access Control; Switch Control Memory (Switch control Memory): used for reading and writing during switching Data; I ² C interface, used to provide E ² PROM interface; CPU interface unit: used to provide the interface function to the external microcomputer host; frame buffer: used to store high-speed data; frame memory, used to store data in a conventional way ;Gigabit Ethernet over STM-16c/OC-48C, providing two Gigabit Ethernet mapping EOS units.

A single OC-48c/STM-16c shown in the block diagram according to FIG. 9 exhibits a single GMII channel. A 24-port 10/100 MAC is used to provide twenty-four MAC port processing. MAC Frame Engine (MACFrame Engine, MFE) is the main MAC frame buffering and forwarding engine in S24-2GEOC48. The MAC Search Engine (MSE) is used to provide the destination address search function.

The basic features of S24-2GEOC48 are as follows:

● 2 Gigabit Ethernet ports on STM-16c/OC-48c;

●24 10/100Mbps automatic listening and fast Ethernet ports with MII interface;

●Support IEEE 802.1d spanning tree algorithm;

● Layer 2 switching.

--Internal exchange database memory supports up to 2k MAC addresses, up to 64k CPU memory for SNMP network management, Web-based network management console interface or RS-232 local console interface or parallel interface.

--- Support up to 16k MAC addresses in 24+2 (EOS) system.

●Support IP multicast through IGMP snooping;

●High-speed MAC frame forwarding, forwarding rate greater than 3 million MAC frames per second (3Mpps), and full wire-speed filtering;

●Adopt a real non-modular architecture to support a system with a throughput of more than 6Mpps (6 million packets per second).

●Single store-and-forward on ingress port, cut-through switching on destination port

●With single store and forward switching technology, the delay is very low;

●Full-duplex Ethernet IEEE 802.3x flow control minimizes traffic congestion;

●Adopt backpressure flow control (IEEE802.3x) for half-duplex ports;

●Virtual local area network (VLAN) 802.1Q with port and ID flags;

●VLAN ID flag insertion/extraction;

●Support IEEE 802.1p/Q service quality, which has 4 priority sending queues, weighted fair queues, and user mapping priority and weight

●Support Ethernet multicast and broadcast;

●Provide source, destination and protocol filtering;

● Strict electrically erasable read-only memory (EEPROM) provides configuration data protection.

S24-2GEOC48 is a 26-port 10/100/1000Mbps Gigabit Ethernet overover STM-16c/OC-48c non-modular Ethernet switch chip with on-chip address storage space. On-chip address memory supports up to 2K MAC addresses and up to 256 IEEE 802.1Q virtual local area networks (VLANs). The S24-2GEOC48 supports port trunking/load sharing on 10/100Mbps ports. Port trunking/load sharing can be used to group ports between interconnected switches to increase network bandwidth efficiency. The framebuffer memory interface uses cost-effective, high-performance pipelined synchronous burst SRAM to support full line rate on all external ports simultaneously. In half-duplex mode, all ports support backpressure flow control, which minimizes the threat of long-term active bursts of data loss. In full-duplex mode, IEEE 802.3x flow control is provided. At full duplex, ports 0-11 support 200Mbps aggregate bandwidth connections, and port 12 supports 2 Gbps to desktop computers, servers, or other high-performance switches. Collect Ethernet SNMP and Remote Interface Management Information Base (RMONMIB) statistics independently for each of the 26 ports. Access to these statistical counters/registers is provided through the CPU interface. Receive and send SNMP management frames through the CPU interface to form a complete network management solution. S24-2GEOC48 is fabricated with 0.18μm technology. The allowable input voltage is 3.3V, and the output is directly connected to the LVTTL level.

As shown in the figure, the EOS device of the present invention can be built into a 10M/100M/1000M LAN layer 2 switch when communicating between the switch and transmission equipment (such as ADM).

Twenty-four 10/100 media access controllers (MACs) provide protocol interfaces into the S24-2GEOC48. These MACs perform the MAC frame verification requirements to ensure that each MAC frame presented to the MAC frame engine complies with all IEEE 802.3 standards. Discard data MAC frames whose length is greater than 1518 bytes (1522 bytes with VLAN tag) and less than 64 bytes. VHS 108 has been designed to support the minimum interframe gap between incoming MAC frames.

The MAC Frame Engine (MFE) is the main MAC Frame Buffer and Forwarding Engine in the S24-2GEOC48. Thus, the MFE controls the storage of MAC frames to and from the external frame storage buffers, keeps track of frame buffer availability, and schedules outgoing MAC frame transmissions. When the MAC frame data is buffered, the MFE extracts the necessary information from the header of each MAC frame and sends it to the search engine for processing. The search results are sent back to the MFE, which schedules MAC frame transmission and its priority. When selecting a MAC frame to send, MFE reads the MAC frame from the external buffer memory and places it in the output FIFO of the output port.

MFE can manage the output sending queues of all ports of S24-2GEOC48. Once the destination address search is done in the MSE, the switching decision made is sent back to the MFE, which inserts the MAC frame into the appropriate output queue. Whether the frame enters the high-priority queue or the low-priority queue is controlled by the VLAN priority flag information or the service type/non-network service (TOS/DS) field in the IP header. The configuration register determines whether the VLAN priority tag or the TOS/DS field is used for QoS mapping. Once the VLAN priority tag is used for QoS mapping, the user can also map the sending priority through the register VLAN priority mapping method, and specify the order of discarding through the register VLAN drop mapping register. When the system uses the TOS/DS code point field to map QoS, it can use the TOS byte (refer to RFC 791) or bits [3:5] of the TOS byte (refer to RFC 2460 and other RFC documents on the IETF site) to map The priority of the sending queue and the order in which frames are discarded. The user is able to control the selected TOS mapping fields. The mapping of the TOS field to a high-priority queue or a low-priority queue is handled by registers TOS Priority Mapping and TOS Dropping Mapping. S24-2GEOC48 uses Weighted Round R0bin (WRR) and Weighted Random Early Detection/Drop (WeightedRandom Early Detection/Drop, WRED) to arrange frame transmission. In order to make S24-2GEOC48 have QoS capability, an EEPROM (4k bytes) is needed to change the default register configuration and enable QoS.

After turning on the power, S24-2GEOC48 can start address learning and MAC frame forwarding immediately. The MAC Search Engine (MSE) checks its internal switching database storage for each valid MAC frame received on the input port of the S24-2GEOC48. Unknown source and destination MAC addresses are detected when the MSE finds no match within its database. These unknown source MAC addresses are learned by creating a new entry in the exchange database memory while storing the necessary resolution information at that location. After searching for a learned destination MAC address, the new content of the MAC Address Control Table (MACAddress Control Table, MACT) item will be returned. After each source address search, the MACT item aging flag is updated. MACT items that have not been accessed for a user configurable period of time (from 5 to 7200 seconds) will be removed. The change time period can be configured with the low and high 16-bit values stored in register MAC Address Change Time. In each time period, all MACT item changes are checked 1 time. If a MAC entry is not used before the end of the next time period, it is deleted.

S24-2GEOC48 supports isolation mode, at this time each port of port 0~23 is only allowed to communicate directly with the uplink port based on OC-48. Therefore, this mode ensures that data from one of ports 0-23 is not directly seen by other ports. This feature is typically desired in residential access to ISP (Internet Service Provider) applications, to provide privacy of user transmitted data.

S24-2GEOC48 uses a standard strict port interface to allow the external host to access the internal registers, as shown in Figure 14 the management bus. This interface consists of 3 pins: TRANSMIT DATA, RECEIVEDATA and GROUNG. The TRANSMIT DATA and RECEIVE DATA pins provide input to the address and data content of the S24-2GEOC48. A simple 2-wire serial interface is provided allowing configuration of the S24-2GEOC48 from EEPROM. The VHS108 uses a 4K-bit EEPROM with an I ² C interface.

Another example of supporting EOS applications is that system suppliers provide Ethernet interfaces connected to 10/100/1000M Ethernet switches in their equipment, and OC-3/STM-1 or OC-48/ STM-16 interface. At the other end, the opposite transformation is used.

FIG. 15 is a schematic diagram of SDH private network connecting 10BASE-T and 100BASE-T2 layer switches and 1000BASE-x switches with EOS devices according to an embodiment of the present invention. As shown in the figure, when communicating between an Ethernet switch and a transmission device (such as ADM), the EOS device of the present invention is set in a 10M/100M/1000M LAN layer 2 switch.

Fig. 16 shows an example diagram of an SDH public network connected to an IEEE 802.3 Ethernet layer 3 switch according to another embodiment of the present invention. As shown in the figure, the EOS device is set in a 10M/100M/1000M LAN layer 3 switch when communicating at full line speed between an Ethernet switch and a transmission device (such as ADM).

In the examples shown in FIGS. 15 and 16, the EOS device according to the present invention may be additionally provided in a transmission device (such as an ADM). By employing this network architecture, the present invention has the benefit of providing an Ethernet interface in the transmission device. This network structure can expand the transmission distance of Ethernet, broaden the application range of transmission equipment, and perform access and transmission. In the case of simplified SDH/SONET, it can be used for DWDM, so that Ethernet and SDH/SONET can be combined without ATM equipment. .

Furthermore, connecting the EOS device according to the present invention between the transmission equipment and the LAN switch to provide point-to-point full-duplex simultaneous bi-directional operation makes it a practical method for Ethernet to operate over a wide area network.

In addition, through the cascading of SDH/SONET VCs, Ethernet frames can be encapsulated and transmitted in MPEG frames and audio frames. Similarly, by adjusting the pointer in the VC, the sending end and the receiving end that are far away from each other can easily achieve synchronization.

Industrial applicability

As can be seen from the above description with reference to the accompanying drawings, the present invention discloses a new interface device and method for directly adapting Ethernet to physical channels. The present invention provides an Ethernet interface on telecommunication SDH/SONET transmission equipment, or realizes remote access to data communication equipment, such as core and edge routers, switch equipment, network access equipment based on IP, line cards, high-speed interface units, such as direct Adapt MAC frames to SDH/SONET. By simplifying SDH/SONET, such as adopting simplified SDH/SONET, Ethernet can be used for DWDM.

Various aspects of the present invention have been described in detail above, but it should be understood that those skilled in the art can make various modifications to these exemplary embodiments based on the disclosure of the present invention. Such modifications and variations are made within the scope and spirit of the invention as defined by the appended claims.

Claims (86)

1. A data transmission device for transmitting data packets from an upper-level device to a lower-level device, comprising: The first receiving device is used to receive data packets from upper-layer equipment, and convert the data packets into first-type frames; The first processing means is used to encapsulate the field and the information field of the data packet indicated by the SAPI identifier into the first type frame to form a second type frame; The second processing means is used for encapsulating the frame of the second type into the payload part, and inserting an appropriate overhead corresponding to the data packet to form a frame of the third type; and The first sending device is configured to output the third type frame to the lower layer device. 2. The data transmission device as claimed in claim 1, wherein said first processing means encapsulates said second type of frame to include a start flag, a SAPI field containing a SAPI identifier, a control field, including said data The frame format of the packet's information field, FCS field, and end flag. 3. The data transmission device according to claim 2, wherein the first receiving means is a first FIFO for receiving and buffering input data packets and adapting the rate of the upper layer device and the rate of the lower layer device. 4. The data transmission device as claimed in claim 3, further comprising scrambling means for performing scrambling on said second type frame with a frame synchronous scrambling sequence generated from polynomial g(x)= ^x7 +1 operate. 5. The data transmission device according to claim 4, further comprising pointer processing means for inserting a pointer indicating the starting position of the payload into the third type frame. 6. The data transmission device according to claim 5, further comprising framing means for encapsulating the scrambled second-type frames into the third-type frames. 7. The data transmission device according to claim 6, wherein the start flag and the end flag of the second type frame are "0x7E". 8. The data transmission device according to claim 7, wherein the flag "0x7E" is transmitted during time filling between frames. 9. The data transmission device according to claim 8, wherein said framing means implements transparency processing (octet stuffing). 10. The data transmission device according to claim 9, wherein said first processing means utilizes a generator polynomial 1+x+x ² +x ⁴ +x ⁵ +x ⁷ +x ⁸ +x ¹⁰ +x ¹¹ +x ¹² +x ¹⁶ +x ²² +x ²³ +x ²⁶ +x ³² Compute the 32-bit Frame Check Sequence field for all octets of the frame except the Start Flag, End Flag, and the FCS field itself. 11. The data transmission device according to claim 5, wherein the payload part comprises one or more payload subparts for carrying the first type frame. 12. The data transmission device of claim 2, wherein the first processing device obtains the SAPI from the first receiving device. 13. The data transmission device according to claim 2, wherein the end marker of the previous frame of the second type is the start marker of the subsequent frame of the second type. 14. The data transmission device according to claim 2, further comprising a line-side packet loopback device for looping the first type frame extracted from the second type frame back to the first processing device for testing. 15. The data transmission device according to claim 11, wherein the payload part is a virtual container or a concatenation of virtual containers, and the virtual container is a payload sub-part. 16. The data transfer device according to any one of the preceding claims, wherein said overhead comprises lane trace bytes (J1), lane BIP-8 bytes (B3), signal Tag byte (C2), channel status byte (G1). 17. The data transmission device according to any one of claims 2 to 15, wherein the lower layer is a physical layer and is SDH/SONET or simplified SDH/SONET. 18. The data transmission device according to any one of claims 2 to 15, wherein the upper layer is an Ethernet MAC layer, the first type frame is a MAC frame, and the second type frame is a LAPS frame, so The third type of frame mentioned above is SDH/SONET frame. 19. The data transmission device according to any one of claims 2 to 15, wherein said data transmission device is built in SDH/SONET transmission equipment. 20. The data transmission device according to any one of claims 2 to 15, wherein the data transmission device is built in an Ethernet switching device. 21. The data transmission device according to any one of claims 2 to 15, wherein the data transmission device is an Ethernet switching device, or an Ethernet/Fast Ethernet/Gigabit Ethernet layer 2/3 layer switch or associated router. 22. The data transmission device according to claim 20, wherein the Ethernet switching device is an Ethernet/Fast Ethernet/Gigabit Ethernet Layer 2/3 switch or a related router. 23. The data transmission device according to claim 18, wherein, the data transmission device makes the received MAC/GMAC frame synchronously mapped from the MII/GMII to the SDH/SONET module through the converter. 24. The data transmission device according to claim 17, wherein, for rate adaptation, the data transmission device adds programmable rate adaptation padding bytes in the second type frame in the form of {0x7d, 0xdd} (0xdd). 25. A data transmission method for transmitting data packets from an upper layer device to a lower layer device, comprising the following steps: receiving and buffering a data packet from the upper-layer device, adapting the rate of the upper-layer device and the rate of the lower-layer device, and converting the data packet into a first-type frame; Encapsulating the field and the information field of the data packet indicated by the SAPI identifier into the first type of frame to form a second type of frame; encapsulating the second type frame into a payload part, and inserting appropriate overhead of the data packet to form a third type frame; and Output the third type frame to the lower layer device. 26. The data transmission method according to claim 25, wherein the second type frame is encapsulated to include a start flag, a SAPI field containing a SAPI identifier, a control field, an information field including the data packet, an FCS Frame format for fields and end markers. 27. The data transmission method according to claim 26, further comprising a scrambling step for performing a scrambling operation on the frame synchronization scrambling sequence generated by the polynomial g(x)=x ⁷ +1 for the frame of the second type. 28. The data transmission method according to claim 27, further comprising a step of inserting a pointer indicating the starting position of the payload part in the third type frame. 29. The data transmission method according to claim 28, further comprising the step of encapsulating the scrambled second-type frames into third-type frames. 30. The data transmission method according to claim 28, wherein the start flag and the end flag of the second type frame are "0x7E". 31. The data transmission method according to claim 30, further comprising the step of transparency processing (octet stuffing). 32. The data transmission method as claimed in claim 31 , further comprising a calculation step for utilizing the generator polynomial 1+x+x ² +x ⁴ +x ⁵ +x ⁷ +x ⁸ +x ¹⁰ +x ¹¹ +x ¹² +x ¹⁶ +x ²² +x ²³ +x ²⁶ +x ³² Compute the 32-bit frame check sequence for all octets of the frame except the start flag, end flag, and the FCS field itself. 33. The data transmission method according to claim 32, wherein the payload part comprises a plurality of payload subparts for carrying the first type frame. 34. The data transmission method according to claim 26, wherein, for the second type of frame, the end marker of the previous frame is the start marker of the subsequent frame. 35. The data transmission method according to claim 26, wherein the payload part is a virtual container or a concatenation of virtual containers, the virtual container being a payload sub-part. 36. The data transmission method according to any one of claims 26 to 35, wherein said overhead includes channel trace bytes (J1), channel BIP-8 bytes (B3) in a single virtual container or in concatenation , signal label byte (C2), channel status byte (G1). 37. The data transmission method according to any one of claims 26 to 35, wherein said lower layer is a physical layer and is SDH/SONET or simplified SDH/SONET. 38. The data transmission method according to any one of claims 26 to 35, wherein the upper layer is an Ethernet MAC layer, the first type frame is a MAC frame, and the second type frame is a LAPS frame, so The third type of frame mentioned above is SDH/SONET frame. 39. The data transmission method according to claim 38, wherein the Ethernet layer is an Ethernet layer of IEEE802.3/802.3u/802.3z. 40. The data transmission method according to claim 38, further comprising the step of synchronously mapping the received MAC/GMAC frame from the MII/GMII to the SDH/SONET module through the converter. 41. The data transmission method according to claim 37, for rate adaptation, further comprising the step of adding a programmable rate adaptation stuffing byte (0xdd) in the second type frame in the form of {0x7d, 0xdd} . 42. A data transmission device for sending a data packet formed by a first type frame from a lower layer device to an upper layer device, comprising: a second receiving device, configured to receive data packets from the lower layer device; frame parsing means for removing overhead from said first type of frame; The third processing means is used to extract the data contained in the information field and the SAPI field from the payload part of the first type frame to form the second type frame; Determining means for comparing the value of the SAPI field with a preset value, and when the data value of the SAPI field is equal to the set value, it is determined to output the actually extracted data; a fourth processing means for converting the second type frame into a third type frame corresponding to the data packet; and The second sending means is used for sending the extracted data packet to the upper layer device. 43. The data transmission device as claimed in claim 42, wherein each of the second type frames includes: a start flag, an address field, a control field, an information field, an FCS field, and an end flag, and the SAPI field is located in the address field. 44. The data transmission device according to claim 43, wherein said second sending means is a second FIFO for receiving and buffering input data packets, and adapting the rate of the lower layer device and the rate of the upper layer device. 45. The data transmission device according to claim 44, further comprising a descrambling device for performing descrambling on the frame synchronization scrambling sequence generated by the polynomial g(x)=x ⁷ +1 for the first type frame disturbing operation. 46. The data transmission device according to claim 45, further comprising pointer processing means for positioning the starting position of the payload part encapsulated in the first type frame by using the pointer. 47. The data transmission device according to claim 46, wherein the start flag and the end flag of the second type frame are "0x7E". 48. The data transmission device according to claim 47, wherein said frame parsing means removes interframe padding. 49. The data transmission device according to claim 48, wherein said frame parsing means performs transparency processing. 50. The data transmission device according to claim 49, wherein, by using the generator polynomial 1+x+x ² +x ⁴ +x ⁵ +x ⁷ +x ⁸ +x ¹⁰ +x ¹¹ +x ¹² +x ¹⁶ + x ²² +x ²³ +x ²⁶ +x ³² calculates the FCS for all octets between the start flag and the end flag to check the received FCS field. 51. The data transmission device according to claim 50, further comprising an overhead monitoring device, configured to monitor the state error of the overhead in the first type frame during the data receiving process. 52. The data transmission apparatus of claim 51, wherein the payload portion comprises a plurality of payload sub-portions for being carried by the first type frame. 53. The data transmission device according to claim 52, wherein, for the second type of frame, the end marker of the previous frame is the start marker of the immediately following frame after the previous frame. 54. The data transmission device of claim 53, wherein the payload part is a virtual container or a concatenation of virtual containers, the virtual container being a payload sub-part. 55. The data transmission device according to any one of claims 43 to 54, wherein said overhead includes channel trace bytes (J1), channel BIP-8 bytes (B3) in a single virtual container or in concatenation , signal label byte (C2), channel status byte (G1). 56. The data transmission device according to any one of claims 43 to 54, wherein said lower layer is a physical layer and is SDH/SONET or Simplified SDH/SONET. 57. The data transmission device according to any one of claims 43 to 54, wherein the upper layer is an Ethernet MAC layer, the first type frame is an SDH/SONET frame, and the second type frame is a LAPS frame , the third type of frame is a MAC frame. 58. The data transmission device according to any one of claims 43 to 54, wherein said data transmission device is built in SDH/SONET transmission equipment. 59. The data transmission device according to claim 43, wherein the data transmission device is built in an Ethernet switching device. 60. The data transmission device according to claim 43, wherein the data transmission device is an Ethernet switching device, or an Ethernet/Fast Ethernet/Gigabit Ethernet Layer 2/3 switch or a related router. 61. The data transmission device of claim 59, wherein the Ethernet switching device is an Ethernet/Fast Ethernet/Gigabit Ethernet Layer 2/3 switch or a related router. 62. The data transmission device according to any one of claims 56 to 61, wherein, for rate adaptation, the data transmission device uses {0x7d, 0xdd} in the form of {0x7d, 0xdd} in the second type of frame Program rate adaptation stuffing bytes removed. 63. The data transmission device as described in any one of claims 56 to 61, wherein the data transmission device makes the MAC/GMAC frame as the LAPS information field synchronously mapped from the SDH/SONET module through a converter at the MII/GMII interface to the receive clock. 64. A data transmission method for sending a data packet formed by a first-type frame from a lower-level device to a higher-level device, comprising the following steps: receiving a data packet from the lower layer device; removing overhead from said first type of frame; Extracting the SAPI field and the data contained in the information field from the payload part of the first type frame to form a second type frame; Compare the value of the SAPI field with the preset value, and when the data value of the SAPI field is equal to the set value, determine to output the actually extracted data; converting the second type frame into a third type frame corresponding to the data packet; and Send the extracted data packet to the upper layer device. 65. The data transmission method as claimed in claim 64, wherein each said second type frame comprises: a start flag, an address field, a control field, an information field, an FCS field, and an end flag, and the SAPI field is located in the address field. 66. The data transmission method according to claim 65, further comprising the steps of receiving and buffering input data packets, and adapting the rate of the lower layer device and the rate of the upper layer device. 67. The data transmission method as claimed in claim 66, further comprising a scrambling step, which is used to decompose the frame synchronous scrambling sequence generated by the polynomial g(x)=x ⁷ +1 for the first type frame disturbing operation. 68. The data transmission method according to claim 67, further comprising the step of using a pointer to locate the starting position of the payload encapsulated in said first type frame. 69. The data transmission method according to claim 68, wherein the start flag and the end flag of the second type frame are "0x7E". 70. The method of data transmission as claimed in claim 69, further comprising the step of removing interframe padding. 71. The data transmission method as claimed in claim 70, wherein, by using the generator polynomial 1+x+x ² +x ⁴ +x ⁵ +x ⁷ +x ⁸ +x ¹⁰ +x ¹¹ +x ¹² +x ¹⁶ + x ²² +x ²³ +x ²⁶ +x ³² calculate the FCS for all octets between the start flag and the end flag of the second type of frame to check the received FCS field. 72. The data transmission method as claimed in claim 71, further comprising the step of monitoring the state error of said first type frame overhead during the receiving process. 73. The data transmission method according to claim 72, wherein said payload part comprises a plurality of payload subparts carried by said first type frame. 74. The data transmission method according to claim 73, wherein, for the second type of frame, the end marker of the previous frame is the start marker of the subsequent frame. 75. The data transmission method of claim 74, wherein the payload portion is a virtual container or a concatenation of virtual containers, the virtual container being a payload sub-part. 76. The data transmission method according to any one of claims 65 to 75, wherein said overhead includes channel trace bytes (J1), channel BIP-8 bytes (B3) in a single virtual container or in concatenation , signal label byte (C2), channel status byte (G1). 77. The data transmission method according to any one of claims 65 to 75, wherein said lower layer is a physical layer and is SDH/SONET or simplified SDH/SONET. 78. The data transmission method according to any one of claims 65 to 75, wherein said upper layer is an Ethernet MAC layer, said first type frame is an SDH/SONET frame, and said second type frame is a LAPS frame , the third type of frame is a MAC frame. 79. The data transmission method according to claim 78, wherein the Ethernet layer is an IEEE802.3/802.3u/802.3z Ethernet layer. 80. The data transmission method according to claim 77, for rate adaptation, further comprising the step of removing the programmable rate adaptation stuffing bytes existing in the second type frame in the form of {0x7d, 0xdd} . 81. The data transmission method as claimed in claim 78, further comprising the step of synchronizing the LAPS information field (MAC/GMAC frame) from the SDH/SONET module to the RX_CLK through the converter at the MII/GMII interface. 82. A data packet interface device for sending data packets between an upper layer device and a lower layer device, comprising the data transmission device according to claim 1 and the data transmission device according to claim 42. 83. The packet interface device of claim 82, wherein the second type frame is encapsulated to include a start flag, a SAPI field containing a SAPI identifier, a control field, an information field including the packet, an FCS Frame format for fields and end markers. 84. A data packet interface device as claimed in claim 82 or 83, further comprising line-side interface means for sending/receiving data packets from an underlying device. 85. The data packet interface device as claimed in claim 84, further comprising a conversion device, used to synchronize the data packet of the upper layer equipment with the data packet input to the first receiving means process in the sending direction; in the receiving direction, and synchronizing the data packets extracted from the second sending means with the data packets of the upper layer device. 86. The packet interface device of claim 85, further comprising: a microprocessor interface device for enabling said data interface device to access all registers therein; a JTAG port for testing; for temporarily buffering input / Output GPIO register for configuration data.

Images