ABSTRACT 1. INTRODUCTION

Transcription

1 DESIGN OF A FAMILY OF VLSI CIRCUIT FOR PROCESSING RSOH OVERHEAD OF THE STS-1/STM-0 and STS-3/STM-1 SONET/SDH SIGNALS J. Aguirre, D. Torres and M. Guzmán sonet@gdl.cinvestav.mx, dtorres@gdl.cinvestav.mx Centro de Investigación y de Estudios Avanzados de IPN, Unidad Guadalajara Prol. López Mateos Sur # 590 Guadalajara, Jalisco, México. ABSTRACT SONET, Synchronous Optical Network, in the United States, and SDH, Synchronous Digital Hierarchy, in Europe and the rest of the world, are two standards created to allow the interconnection of high-speed optical links. These two standards are very similar and interwork each other. The family of circuits, in which we are interested, carries out the RSOH overhead byte processing for the STS-1/STM-0 and STS-3/STM-1 SONET/SDH signals. In particular the following overhead bytes are processed: B1 and J0, moreover alarm processing is performed. There is a sub-module associated with each of the above mentioned processing. Besides, there is a sub-module extracting the J0 and B1 bytes. In this paper we discuss the requirements, the architecture and verification of the family of RSOH overhead byte processors. 1. INTRODUCTION The advances of new bandwidth applications have made demands to transport huge amounts of traffic on an expedient and reliable way. Advances in optical fiber and network processors have been key factors to satisfy the traffic transport demands. In order to bring multiple vendors to bear upon the satisfaction of the demands standards are required. The SONET standard was formulated by the Exchange Carrier Standard Association (ECSA) for the American National Standard Institute (ANSI), which establishes the standards for the industry of the telecommunications in the United States. The International Union of the Telecommunications (ITU) formulated the SDH standard. The rates of SONET/SDH are defined in the range from the 51 Mbps to the 40 Gbps. To denote the SONET/SDH signals of level N in their electric form we use the notation STS-N, which stands for Synchronous Transport Signal of level N. The equivalent notation, in SDH, is called Synchronous Transport Module of level N, STM-N. After these signals are converted to optic pulses they are known as optic carrier of level N (OC-N). The Table 1.1 describes the transmission rates for the standard SONET/SDH and the relation between STS-N and STM-N signals. Signals Bit Rate SONET Optical SDH (Mbps) STS-1 OC-1 STM STS-3 OC-3 STM STS-12 OC-12 STM STS-48 OC-48 STM STS-192 OC-192 STM STS-768 OC-768 STM Table 1.1 SONET/SDH transmission rates Main objectives of this paper are:?? The specification of requirements according to international standards for a RSOH processor?? The creation of a flexible architecture, which can be reused at higher level of hierarchy?? The processing of the RSOH bytes for the transport overhead (TOH) of a SONET/SDH data stream The component presented in this work is part of a basic library of SONET/SDH components, which is been designed at CINVESTAV of I.P.N, Guadalajara. This library is composed of several components, such as: frame alignment [9], MSOH processor [11], POH processor [7], pointer tracker processor [8] and Multiplex Section Adaptation [10]. 2. SPECIFICATION OF THE DESIGN The design should include the following functionality: J0 and B1 byte extractor J0 byte processor Alarm processor

2 B1 byte processor 3. ARCHITECTURE OF THE DESIGN Figure 3.1 shows a block diagram of the design for RSOH byte processing for the STS-1/STM-0/STS-3/STM-1 SONET/SDH signals. P_RSOH In P_RSOH_Clk_In P_RSOH_Config_In[2:0] P_RSOH_STSN_In P_RSOH_J0Detected_In P_RSOH_Data_In[7:0] RSOH Byte Extractor Byte Extractors P_J0Mismatch_Out Section Trace (J0) Processor P_J0ExpectFUll_Out P_J0ReceiveStable_Out P_J0CRC7_Mismatch_Out P_J0Process_Off_Out P_J0MAcept_to_J0MExpect_Out P_AlarmLOF_In P_AlarmLOS_In Alarm processor B1 Processor Figure 3.1 RSOH processor P_B1_MpRead_In P_Enable_Alarm_In P_Enable_AIS_Out P_RSOH_J0Detected_Out P_Data_Out[7:0] P_B1_BitError_C_Out[16:0] P_B1_BlockError_C_Out[13:0] P_B1_SES_Out P_B1_RollOverBit_Out P_B1_RollOverBlock_Out This sub-module is used to extract the J0 and B1 bytes providing them to the corresponding sub-module. This sub-module receives a signal that indicates the start of a frame. It uses this indication and an internal counter to determine the position of the J0 and B1 bytes in the SONET/SDH frames, in the following diagram we could see a byte extractor sub-module. P_BE_Clk_In P_BE In P_BE_Enable_In P_BE_J0Detected_In P_BE_STSN_In P_BE_J0Config_In P_BE_Data_In Byte Extractor Figure 3.2 Byte extractor Section Trace (J0) processor P_BE_Data_Out P_BE_DataSubmodulo_Out P_BE_J0Detected_Out P_BE_Active_J0_STS1_Out P_BE_Active_Z0_STS2_Out P_BE_Active_Z0_STS3_Out P_BE_Active_B1_Out P_BE_Counter_Out One byte is allocated to be used for a section trace function. This byte is defined only for the first STS-1 signal in an STS-N/Nc signal. J0 (formerly C1 of STS-1 number one) is used to repetitively transmit a fixed length string so that a receiving terminal can verify it is continued connection to the intended transmitter. in the following diagram we could see a J0 processor. P_J0_Clk_In P_J0 In P_J0_New_Config_In P_J0_Consecutive_In P_J0_Config_In P_J0_STS1_Enable_In P_J0_STS2_Enable_in P_J0_STS3_Enable_In P_J0_Yes_T_Expected_In P_J0_Mp_Write_In P_J0_T_Expected_In P_J0_Data_In J0_Processor JO_ID_STSN J0_ID_STS1 J0_ID_STS2 J0_ID_STS3 J0_4_Config Un byte 16 bytes con CRC-7 64 bytes con formato 64 bytes sin formato Figure 3.3 J0 processor P_J0_ID_STS1_Stable_Out P_J0_ID_STS1_Mismatch_Out P_J0_ID_STS2_Stable_Out P_J0_ID_STS2_Mismatch_out P_J0_ID_STS3_Stable_Out P_J0_ID_STS3_Mismatch_Out P_J0_Trace_Mismatch_Out P_J0_Trace_Stable_Out P_J0_Trace_CRC7_Mismatch_out P_J0_Trace_Expected_Full_out P_J0_Trace_Acepted_to_Expected_out This sub-module performs the processing of section trace J0. The following configurations for the J0 trace are defined: 1. C1 convention [1]. 2. One byte [6] bytes with CRC-7 [1] bytes with format [5] bytes without format [5]. This sub-module has one memory that is divided in two parts. One is designed to capture incoming traces and the other contains the expected trace. The J0 section trace data bytes from the receive stream are written into the capture memory. The expected J0 section trace is downloaded by the microprocessor into the expected memory. On receipt of a J0 section trace byte, it is written into next location in the capture memory. The J0 section trace is compared with the previous section trace J0 in the capture memory. A J0 section trace is accepted if it is received unchanged three times, or optionally, five times. The J0 section trace accepted is then compared with the expected J0 section trace. An interruption is generated when the J0 section trace accepted changes from matching to mismatching and vice versa. If the current J0 section trace differs from the previous trace for eight consecutive frames, the received J0 section trace is declared unstable. The received J0 section trace is declared stable when the trace passes the persistency criteria (three or five identical receptions) for being accepted. This is shown in the following diagram. We will briefly describe the different configuration for the J0 processor.

3 stability Unstable 8 section trace (J0) differs consecutive Stable unstability NOTES 1 C 1 C 2 C 3 C 4 C 5 C 6 C 7 is the result of the CRC-7 calculation over the previous frame. C 1 is the MSB. 2 0XXXXXXX represents a T.50 character. 3 o 5 section trace (J0) identical consecutive Figure 3.4 Stable and unstable criteria C1 convention and J0 one byte. For this configuration we only use a little part of our capture and expected memory because the J0 section trace is only one byte long. The processing for both configurations are described in the state machine in Figure 3.5. First we store the J0 section trace in store state and after in the validate state we determined if the section trace was stable or unstable (see Figure 3.4), the change of the state depends on the stable and unstable criterion. StoreJ0 ValidateJ0 in in Figure 3.5 State machine for configuration 1 and 2 16 bytes with CRC-7 When we use this configuration, the J0 section trace should being synchronizes to the byte with the most significant bit set to high and places the byte at the first location in the capture memory. The J0 section trace structure is the following: Byte # Value (bit 1, 2,,8) 1 1 C 1 C 2 C 3 C 4 C 5 C 6 C X X X X X X X 3 0 X X X X X X X : : : 16 0 X X X X X X X Table 3.1 Message structure for J0 section trace J0 configured as 16 bytes long with CRC-7 The first byte of the string is a frame start marker and includes the result of a CRC-7 calculation over the previous frame. The following 15 bytes are used for the transport of 15 T.50 characters (International Reference Version) required for the Section Access Point Identifier. The processing for this configuration is described in the state machine (see Figure 3.6). When the J0 section trace is synchronized, the state machine change to store16 state, the J0 section trace is stored in the capture memory, if the section trace is not, it waits there until that section trace is. The validate16 state determines if the section trace was stable or unstable. The change of the state depends on the stable and unstable criterion. in Validate16 Synchronize with CRC7 synchronization Store16 Figure 3.6 State machine for configuration 3 64 bytes with format There is synchronization in When we use this configuration, the J0 section trace buffer synchronizes with the trailing carriage return (CR=0DH) and line feed (LF=0AH). The next bytes after this sequence are places at the head of the capture memory. The J0 section trace structure is the following CR LF Figure 3.7 Message structure for the J0 section trace configured with 64 bytes with format

4 The processing for this configuration is described in the state machine shown in Figure 3.8. It is similar to the state machine described before, but in this case we use the full capture and expected memory and the synchronization is carried out differently. StoreJ0 in ValidateJ0 in Validate64CF SynchronizeCR Store64CF LF in CR Figure 3.8 State machine for configuration 4 Section trace J0 64 bytes without format There is CR SynchronizeLF There is LF For this configuration we, use the full capture and expected memory to store the J0 section trace. The J0 section trace structure is shown in Figure Figure 3.9 Message structure for J0 section trace configured with 64 bytes without format For the processing of this configuration there is not a byte synchronizer as in the previous one. For this reason, we said that the capture memory acts as a circular buffer. The circuit receives the first J0 section trace (string of 64 bytes) and does the filtering process, if the J0 section trace passes the stable and unstable criterion it is accepted. And this J0 section trace turns into J0 section trace expected. After this first processing, the new incoming J0 section trace is captured and we do the same processing, as described in the first two configurations. The finite state machine for this behavior is shown in Figure 3.10 in Figure 3.10 State machine for configuration 5 Alarm Processor This sub-module carries out the function of generating alarm indicators; it detects and indicates if some alarm occurred. The Figure 3.11 shows the inputs and outputs to this sub-module. P_Alarm_Clk_In P_Alarm In P_Alarm_LOS_In P_Alarm_LOF_In P_Alarm_Another_In Alarm processor Figure 3.11 Alarm processor P_Alarm_AIS_Out The functions of this sub-module are:?? To detect the existence of a LOS signal.?? To detect the existence of a LOF signal.?? To detect the existence of a signal provided by the microprocessor in the case that it wants to activate the alarm indication for some other reason.?? To provide an external pulse that indicates AIS, when some of the signals mentioned are detected. B1 Processor One byte is allocated for section error monitoring function. This function is a bit interleaved parity 8 code using even parity. The section BIP-8 is calculated over all bits of the previous STS-N/Nc frame after scrambling. The computed BIP-8 is placed in the B1 byte before scrambling. This byte is defined only for STS-1 number one of STS-N/Nc signal, see Figure P_B1_Clk_In P_B1 In P_B1_Enable_In P_B1_MpRead_In P_B1_STSN_In P_B1_Cal_Enable_In P_B1_Data_In P_B1_Cal_In B1 Processor P_B1_BitError_C_Out P_B1_BlockError_C_Out P_B1_SES_Out P_B1_RollOverBit_Out P_B1_RollOverBlock_Out Figure 3.12 B1 processor

5 It is important to describe the two kinds of counters that are used in this sub-module. 1. Bit error counter The function of this counter is to store the number of errors occurred when comparing the incoming B1 byte with the B1 calculated before the descrambling of the previous frame, being able to have up to eight errors per frame. 2. Block error counter The function of this counter is to store the number of errors occurred when comparing the incoming B1 byte with the calculated B1. In this case a single error is accumulated when one o more bit errors are present in the comparison of the B1 bytes. This sub-module performs the calculation and comparison of the B1 byte. The functions of this submodule are:?? Counting-up of bit error in one second.?? Counting-up of block error in one second.?? Indicate the rollover existence in the bit and block error counter.?? Establish a signal SES (Severity Error Second) if K errors existed BIP8 in the section layer, where K is equal to 52 for a STS-1 and 155 for a STS SIMULATION AND VERIFICATION For the simulation and verification, we used the VHDL language to write test benches for each sub-module. The term test bench usually refers to the code used to create a pre-determined input sequence to test a code, and observe the response. It is commonly implemented using VHDL or Verilog, but also include external data files or C routines. A VHDL test bench consists of an architecture body containing an instance of component to be tested and processes that generate sequences of values on signals connected to the component instance. The architecture body may also contain processes to test the component instance, watching the values on its output signals. External file Test bench Design under verification External file Figure 4.1 Generic structure of a test bench and design under test Each sub-module has its own test bench. Inputs are read from an external file and the outputs are written in other file. Figure 4.1 shows a generic structure of a test bench and the design under test. Acknowledgement The authors wish to express their gratitude to Semiconductor Technology Center for the technical support given to this work. 5. CONCLUSION In this paper, we can summarize the conclusions as follows:?? The requirements for each sub-module were specified in agreement with the ITU standards.?? Five kinds of processing for J0 section trace were implemented.?? The architecture for each sub-module was created.?? Each sub-module was designed using the VHDL language.?? Each sub-module was synthesized and its functionality verified. 6. REFERENCES [1] ITU-T: Recommendation G.707, Network node interfaces for the synchronous digital hierarchy (SDH) [2] W. Goralski, SONET A Guide to Synchronous Optical Network, McGraw Hill, New York, 1997 [3] M. Chwan Chow, Understanding SONET/SDH: Standars and applications, Holmdel, New Jersey, 1995 [4] V. Stamatios, SONET/SDH and ATM, IEEE Press Marketing, Piscataway, NJ 1999 [5] PMC-Sierra, data sheet SONET/SDH Transport Overhead Transceiver [6] TranSwitch, data sheet SONET STS-1 Overhead Terminator [7] L. Aburto, POH Processor, Master s thesis in development at CINVESTAV Unidad Guadalajara. [8] J. Maldonado, Pointer Tracking Processor, Master s thesis in development at CINVESTAV Unidad Guadalajara [9] S. Medina, Frame Alignment, Master s thesis in development at CINVESTAV Unidad Guadalajara [10] H. Nanni, Multiplex Section Adaptation, Master s thesis in development at CINVESTAV Unidad Guadalajara [11] A. Redondo, MSOH Processor, Master s thesis development in CINVESTAV Unidad Guadalajara