Method for eliminating line side OTUk frame interruption caused by cross protection switching

Abstract

The invention discloses a method for eliminating line side OTUk frame interruption caused by cross protection switching. The core idea of the method is that when the ODUk after cross protection is adapted to the OTUk, phase differences of ODUk frames of different paths caused by switching of main and standby cross boards or subnet connection protection (SNCP) are absorbed through a preset adaptation buffer and a special adaptation processing mode, so that even if the ODUk frames are discontinuous due to switching, the ODUk frames are not continuous through special mapping processing from the ODUk frames to the OTUk frames. The discontinuity of the OTUk frame is not caused; in this way, the far-end device does not judge that the OTUk frame is out of step so as to avoid frame synchronization again, data recovery time is shortened, and possible switching of a line side path is eliminated.

Description

Technical Field

[0001] The present invention belongs to the technical field of OTN transmission equipment, and in particular relates to a method for eliminating line-side OTUk frame interruption caused by cross protection switching. Background Art

[0002] In current OTN transmission equipment implementations, ODUk (k = 0, 1, 2, flex) signals sent from the line or user side are primarily processed for ODUk-level data cross-connection and protection on the central cross-connect board. Furthermore, to ensure equipment reliability, the central cross-connect board in each network element's OTN equipment typically employs 1+1 redundancy. Line cards and tributary cards utilize a concurrent selection strategy. At the same time, both the active and standby cross-connect boards receive the same ODUk services from the line and tributary cards and perform the same cross-connection processing. At this time, the line and tributary cards select the ODUk services from the active cross-connect board for transmission. If the active cross-connect board experiences a problem or needs to be removed for maintenance, the standby cross-connect board takes over the active role, minimizing service cross-connection and transmission.

[0003] Although both the active and standby cross-connect boards receive the same ODUk services and perform the same cross-connect processing, and the standby cross-connect board's operating clock is locked to the active cross-connect board, the ODUk frames output from the two cross-connect boards to the line cards are not fully aligned due to different internal processing delays. When the ODUk (k=1, 2) sent to the line cards is ultimately mapped to OTUk (k=1, 2) and transmitted as line frames, under existing OTN equipment, the switchover between the active and standby cross-connect boards causes discontinuity in the ODUk frames received after the switchover, ultimately leading to discontinuity in the transmitted OTUk frames. When receiving OTUk frames, remote devices will detect frame loss and resynchronize, assuming an error has occurred on the line side. In severe cases, this may result in a line-side path switchover. In addition to the aforementioned active and standby cross-connect board equipment protection (EPS), a single cross-connect board also implements subnetwork connection protection (SNCP) to protect ODUk services using the same services from different paths. During subnet connection protection, since the same ODUk service comes from different paths with different delays, the ODUk frames are not aligned. When protection switching occurs, the output ODUk frames will be discontinuous, and ultimately the transmission of OTUk frames will be discontinuous, which will be identified as a line error by the remote device.

[0004] To this end, the present invention designs a method for eliminating line-side OTUk frame interruption caused by cross protection switching. Summary of the Invention

[0005] The object of the present invention is to provide a method for eliminating line-side OTUk frame interruption caused by cross protection switching, so as to solve the problems raised in the above background technology.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a method for eliminating line-side OTUk frame interruption caused by cross protection switching, wherein the specific processing steps are as follows:

[0007] S1: The input ODUk frame data is written into the adaptation buffer in the ODUk clock cycle under the control of the ODUk write control module. The write address at the ODUk_FS byte of the ODUk frame header is set to 0 each time. Then, when the ODUk data is valid, the write address is incremented by 1. When the address reaches 239*2n-1, that is, the end of the buffer, the write address returns to 0.

[0008] S2: The ODUk adaptation buffer module caches 239*2n clock cycle data and, under the control of the read / write control module, increases the distance between the ODUk write frame header and the OTUk read frame header by 239*n.

[0009] S3: The frame header synchronization state machine is responsible for synchronizing the writing of the ODUk frame header and the reading of the OTUk frame header under a special frame header synchronization mechanism. That is, when adaptation is started, the ODUk frame header and the OTUk frame header are artificially separated by about 239*n clock cycles in the adaptation buffer to ensure that a deviation of about ±239*n clock cycles can be tolerated between reading and writing the frame header.

[0010] S4: The OTUk read control module generates an OTUk frame structure based on the OTUk frame header indication generated by the frame header synchronization state machine and reads the ODUk data. The data reading is performed under the OTUk clock. The read address of the OTUk frame is set to 0 at the frame header byte OTUk_FS. When reading ODUk data, the read address continues to increase by 1. When the address reaches 239*2n-1, that is, the end of the buffer, the read address returns to 0.

[0011] Preferably, in S1, the write clock of ODUk may be a smooth clock or a high-speed clock+ODUk data enable.

[0012] Preferably, the buffer depth is selected as a multiple of 239 because the ODUk frame length is 3824x4 bytes. To ensure that the ODUk frame length and the buffer depth are in a multiple relationship, OTUk / ODUk frame header synchronization processing is facilitated. Since the ODUk frame and the OTUk frame clock strictly meet the 239 / 255 synchronization relationship, and the OTUk FEC byte position does not carry ODUk data (that is, the OTUk frame position 16 / 255 does not read ODUk data), under normal conditions, the buffer will not be read empty or overflow.

[0013] Preferably, in said S3, the detailed frame header synchronization mechanism of ODUk adaptation to OTUk is as follows: there are two states, IN_IAE and IN_NORM. The initial state is IN_IAE. In this state, when the ODUk frame header is written and the written data in the buffer is greater than or equal to 239*n, the OTUk / ODUk frame header synchronization is started, an OTUk frame header indication is generated, and the ODUk data is read from address 0 according to the indication. At this time, the data read from address 0 of the buffer should contain the ODUk frame header indication. Then, the reading side reads the buffer data at the data position according to the OTUk frame timing, and the address is incremented by 1. The buffer data is not read at the FEC position. When the ODUk frame header indication is read again at the OTUk frame header position, it indicates that the two have been perfectly adapted and the state enters the IN_NORM state. Otherwise, the synchronization process is restarted. In the IN_NORM state, the read OTUk frame header position is always detected. Under normal circumstances, the ODUk frame header indication is only read at the OTUk frame header position. If the ODUk frame header indication is read at a non-OTUk frame header position or the ODUk frame header indication is not read at the OTUk frame header position, it means that the ODUk frame header has undergone a serious jump and the distance from the original OTUk frame header has exceeded ±239*n clock cycles. It is necessary to re-synchronize the OTUk / ODUk frame header and enter the IN_IAE state.

[0014] Preferably, in said S4, the data reading clock may be an OTUk smooth clock or a high-speed clock + OTUk data enable, but data is not read out at the FEC position.

[0015] Compared with the prior art, the present invention has the following beneficial effects:

[0016] This design proposes a new ODUk-to-OTUk adaptation method that absorbs ODUk frame phase differences caused by active / standby cross-connect board switching or subnetwork connection protection (SNCP). Even if ODUk frames are discontinuous, this is prevented through special ODUk-to-OTUk frame mapping. This prevents remote devices from detecting OTUk frame loss, avoiding frame resynchronization. This reduces data recovery time and eliminates potential line-side path switching. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is a schematic diagram of the principle flow of the present invention;

[0018] Figure 2 This is a schematic diagram of a situation where ODUk is ahead after ODUk active / standby switching occurs due to protection in Embodiment 1 of the present invention;

[0019] Figure 3 This is a schematic diagram of a situation where the ODUk frame header is delayed after the ODUk active / standby switching occurs due to protection in Embodiment 1 of the present invention; DETAILED DESCRIPTION

[0020] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0021] See also Figure 1 The present invention provides a technical solution: a method for eliminating line-side OTUk frame interruption caused by cross protection switching, wherein the special processing steps are as follows:

[0022] S1: The input ODUk frame data is written into the adaptation buffer in the ODUk clock cycle under the control of the ODUk write control module. The write address at the ODUk_FS byte of the ODUk frame header is set to 0 each time. Then, when the ODUk data is valid, the write address is incremented by 1. When the address reaches 239*2n-1, that is, the end of the buffer, the write address returns to 0.

[0023] S2: The ODUk adaptation buffer module caches 239*2n clock cycle data and, under the control of the read / write control module, increases the distance between the ODUk write frame header and the OTUk read frame header by 239*n.

[0024] S3: The frame header synchronization state machine is responsible for synchronizing the ODUk frame header and the OTUk frame header. That is, when adaptation is started, the ODUk frame header and the OTUk frame header are artificially separated by about 239*n clock cycles in the adaptation buffer to ensure that a deviation of about ±239*n clock cycles can be tolerated between reading and writing the frame header.

[0025] S4: The OTUk read control module generates an OTUk frame structure based on the OTUk frame header indication generated by the frame header synchronization state machine and reads the ODUk data. The data reading is performed under the OTUk clock. The read address of the OTUk frame is set to 0 at the frame header byte OTUk_FS. When reading ODUk data, the read address continues to increase by 1. When the address reaches 239*2n-1, that is, the end of the buffer, the read address returns to 0.

[0026] In this embodiment, preferably, in S1 , the write clock of the ODUk may be a smooth clock or a high-speed clock+ODUk data enable.

[0027] In this embodiment, the buffer depth is preferably selected as a multiple of 239 because the ODUk frame length is 3824x4 bytes. To ensure that the ODUk frame length and the buffer depth are in a multiple relationship, OTUk / ODUk frame header synchronization processing is facilitated. Since the ODUk frame and the OTUk frame clock strictly meet the 239 / 255 synchronization relationship, and the OTUk FEC byte position does not carry ODUk data (that is, ODUk data is not read at the 16 / 255 OTUk frame position), under normal conditions, the buffer will not be read empty or overflow.

[0028] In this embodiment, preferably, in S3, the detailed frame header synchronization mechanism of ODUk adaptation to OTUk is as follows: there are two states: IN_IAE and IN_NORM. The initial state is IN_IAE. In this state, when the ODUk frame header is written and the written data in the buffer is greater than or equal to 239*n, the OTUk / ODUk frame header synchronization is started, an OTUk frame header indication is generated, and the ODUk data is read from address 0 according to the indication. At this time, the data read from address 0 of the buffer should include the ODUk frame header indication. Then, the reading side reads the buffer data at the data position according to the OTUk frame timing, and the address is incremented by 1. The buffer data is not read at the FEC position. According to the data, when the ODUk frame header indication is read again at the OTUk frame header position, it means that the two have been perfectly adapted and enter the IN_NORM state. Otherwise, the synchronization process is restarted. In the IN_NORM state, the read OTUk frame header position is always detected. Under normal circumstances, the ODUk frame header indication is only read at the OTUk frame header position. When the ODUk frame header indication is read at a non-OTUk frame header position or the ODUk frame header indication is not read at the OTUk frame header position, it means that the ODUk frame header has a serious jump and the distance from the original OTUk frame header has exceeded ±239*n clock cycles. It is necessary to re-synchronize the OTUk / ODUk frame header and enter the IN_IAE state.

[0029] In this embodiment, preferably, in S4, the data reading clock may be an OTUk smooth clock or a high-speed clock + OTUk data enable, but data is not read out at the FEC position.

[0030] Example 1

[0031] The following example illustrates the working mechanism of special adaptation from ODUk frames to OTUk frames:

[0032] When ODUk master / slave switch occurs due to protection, the ODUk advance situation is as follows: Figure 2 As shown in the figure, the writing and reading distance in the buffer increases, but as long as it does not exceed 239*2n and the buffer is not full, the OTUk reading side remains continuous;

[0033] The situation where the ODUk frame header is delayed after the ODUk active / standby switch occurs due to protection is as follows: Figure 3 As shown in the figure, the distance between writing and reading in the buffer becomes smaller, but as long as it is not less than 0 and the buffer is not read empty, the OTUk reading side remains continuous.

[0034] As previously mentioned, when a master / slave cross-connect switchover or subnetwork connection protection (SNCP) occurs, even if the protection switch causes discontinuity in ODUk frames, the OTUk frame reader continues to read data periodically without any discontinuous jumps. The discontinuous jumps in the ODUk frame header are absorbed by the preset buffer; the only change is the delay between writing and reading the ODUk frame header in the buffer. As a result, the OTUk frames seen on the line are error-free, and of course, this does not require resynchronization or cause subsequent transmission path switching.

[0035] Although the embodiments of the present invention have been shown and described, as detailed above, it will be understood by those skilled in the art that various changes, modifications, substitutions and variations may be made to these embodiments without departing from the principles and spirit of the invention, and the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. A method for eliminating line-side OTUk frame interruption caused by cross protection switching, characterized by: A special processing method, different from the previous one, is used to handle the ODUk to OTUk adaptation after cross protection. The steps of this special processing method are as follows: S1: The input ODUk frame data is written into the adaptation buffer in the ODUk clock cycle under the control of the ODUk write control module. The write address at the ODUk_FS byte of the ODUk frame header is set to 0 each time. Then, when the ODUk data is valid, the write address is incremented by 1. When the address reaches 239*2n-1, that is, the end of the buffer, the write address returns to 0. S2: The ODUk adaptation buffer module caches 239*2n clock cycle data and, under the control of the read / write control module, increases the distance between the ODUk write frame header and the OTUk read frame header by 239*n. S3: The frame header synchronization state machine is responsible for synchronizing the writing of the ODUk frame header and the reading of the OTUk frame header under a special frame header synchronization mechanism. That is, when adaptation is started, the ODUk frame header and the OTUk frame header are artificially separated by about 239*n clock cycles in the adaptation buffer to ensure that a deviation of about ±239*n clock cycles can be tolerated between reading and writing the frame header. S4: The OTUk read control module generates an OTUk frame structure according to the OTUk frame header indication generated by the frame header synchronization state machine and reads the ODUk data. The read address of the OTUk frame is set to 0 at the frame header byte OTUk_FS. When reading the ODUk data, the read address continues to increase by 1. When the address reaches 239*2n-1, that is, the end of the buffer, the read address returns to 0.

2. The method for eliminating line-side OTUk frame interruption caused by cross protection switching according to claim 1, characterized in that: In S1, the tail address of the write address of the ODUk adaptation buffer must be a multiple of 2n (n is a natural number) of 239 to ensure that the ODUk frame header always appears periodically at the fixed address 0 of the adaptation buffer, facilitating subsequent synchronization and inspection of the ODUk frame header. At the same time, the ODUk write clock can be a smooth ODUk clock or a high-speed clock + ODUk data enable.

3. The method for eliminating line-side OTUk frame interruption caused by cross protection switching according to claim 1, characterized in that: The buffer depth is selected as a multiple of 2n (n is a natural number) of 239 because the ODUk frame length is 3824x4 bytes. To ensure that the ODUk frame length and the buffer depth are multiples, the ODUk frame header always appears periodically at the fixed address 0 of the adaptation buffer, facilitating OTUk / ODUk frame header synchronization processing.

4. The method for eliminating line-side OTUk frame interruption caused by cross protection switching according to claim 1, characterized in that: In S3, in the special synchronization mechanism of the ODUk and OTUk frame headers, the behavior of the frame header entering synchronization is: the state machine has two states, IN_IAE and IN_NORM. The initial state is IN_IAE. In this state, when the ODUk frame header is written and the written data in the buffer is greater than or equal to 239*n, the OTUk / ODUk frame header synchronization is started, an OTUk frame header indication is generated, and the ODUk data is read from address 0 according to the indication. At this time, the data read from address 0 of the buffer should contain the ODUk frame header indication. Then, the reading side reads the buffer data at the data position according to the OTUk frame timing, increments the address by 1, and does not read the buffer data at the FEC position. When the ODUk frame header indication is read again at the OTUk frame header position, it indicates that the two are perfectly adapted and enter the IN_NORM state. Otherwise, the synchronization process is restarted.

5. The method for eliminating line-side OTUk frame interruption caused by cross protection switching according to claim 1, characterized in that: In the special synchronization mechanism of the ODUk and OTUk frame headers in S3, the behavior of the frame header desynchronization is as follows: in the IN_NORM state, the position of the read OTUk frame header is always detected. Under normal circumstances, the ODUk frame header indication is only read at the OTUk frame header position. When the ODUk frame header indication is read at a non-OTUk frame header position or the ODUk frame header indication is not read at the OTUk frame header position, it means that the ODUk frame header has undergone a serious jump and the distance from the original OTUk frame header has exceeded ±239*n clock cycles. It is necessary to re-perform OTUk / ODUk frame header synchronization and enter the IN_IAE state.

6. The method for eliminating line-side OTUk frame interruption caused by cross protection switching according to claim 1, characterized in that: In S4, the tail address of the ODUk adaptation buffer's read address must be a multiple of 2n (n is a natural number) of 2³⁹ to ensure that the ODUk frame header is always periodically read at a fixed address of 0 to adapt to the OTUk frame header, facilitating subsequent synchronization and inspection of the ODUk frame header. The OTUk read clock can be a smoothed OTUk clock or a high-speed clock + OTUk data enable. However, data is not read from the FEC position.

Images