Mapping and de-mapping method from multipath VC-n service to fgOPUflex

Abstract

The invention belongs to the technical field of optical transport networks (OTN), and particularly provides a method for mapping multi-channel VC services to fgOPUflex, which adopts a mode of directly mapping VC-n services into fgOPUflex, and indicates frame header positions, port information, alarm information and the like of VC-n service data frames by inserting fixed bytes. Multiple paths of service signals are not required to be aligned in the mapping process; meanwhile, multiple paths of TU-12 / TUG-3 are not required to be from the same AU-4, so that the application is more flexible; besides, a GMP mapping mode is not adopted in the mapping process, and data rate adaptation is performed through frame structure coding adjustment and data rate adaptation during data encapsulation and packaging, so that rate adaptation processing is further simplified. Therefore, the mapping / de-mapping processing is simplified and the mapping execution efficiency is improved while the integrity of the mapping / de-mapping function from the multi-channel VC service to the fgOPUflex is ensured, and the problems that the mapping process from the multi-channel VC service to the fgOPUflex is tedious in processing and the mapping execution efficiency is influenced in the prior art are effectively solved.

Description

Technical Field

[0001] The present invention relates to the technical field of optical transport network (OTN), and in particular to a method for mapping and demapping multi-channel VC-n services to fgOPUflex. Background Art

[0002] Optical Transport Network (OTN) technology combines the advantages of SDH / SONET and WDM technologies, providing high-capacity transmission and flexible scheduling capabilities. Traditional OTN technology has excessively large service granularity. The minimum hard pipe granularity of ODUflex is 1.25G, primarily used to carry services exceeding 1Gbit / s. To meet operators' demand for flexible bandwidth transport for government and enterprise dedicated line services, fgOTN and OSU emerged. fgOTN uses a fixed timeslot allocation scheme, with each fgODUflex channel multiplexed into an OPUk in a fixed timeslot position. This offers the advantage of relatively stable service latency and better transport for CBR services such as E1 / VC. The OSU uses a non-fixed timeslot payload method to divide services. Services are granularized according to payload blocks, allowing for more flexible multiplexing into OPUk timeslots within each channel. This offers the advantage of flexible service transport and better transport for Ethernet services.

[0003] In March 2023, ITU-T officially released the standard for the overall, interface, and core architecture of fgOTN. fgOTN is an extension of existing OTN technology. The fgOTN standard introduces a specific path layer, fgODUflex, which can be directly mapped and multiplexed onto ODUk or mapped onto ODUj before being multiplexed onto ODUk / Cn.

[0004] fgOTN can be applied in various communications fields and scenarios such as government and enterprise private lines, meeting the need for carrying small-granular services below 1G. The fgODUflex container can provide service carrying capacity of 10Mbit / s to 1Gbit / s (other rates are to be determined). It uses 10M timeslots for hard isolation and provides P*10M flexible containers, providing hard isolation, secure, reliable, and TDM-based transmission capabilities. It is compatible with existing OTN networks, effectively protecting existing OTN equipment investments and promoting the development of the OTN industry. Typical service rates include 2Mbit / s, 10Mbit / s, 50Mbit / s, 100Mbit / s, 155Mbit / s, 622Mbit / s, and 1000Mbit / s.

[0005] In existing technology, mapping multiple VC services (VC-n services) to fgOPUflex is based on the VC-n service's source and sink nodes sharing a common clock source. Using the same clock at both the source and sink nodes, the VC-n signals are encapsulated within the TU[G] / AU, or the VC-n carries packet services. Jitter and wander performance during the mapping process and end-to-end transmission are not strictly constrained.

[0006] fgOTN supports one or more VC-n channels, where one or more VC-n channels are marked as v1 VC-12, v2 VC-3, and one VC-4, where v1 = 1, 5, 10, 15, 25, 30, 35, 40, 45, 50, 55, or 60, and v2 = 1 or 2.

[0007] On the mapping side, v1 TU-12, v2 TUG-3, or 1 AU-4 is extracted from an STM-N input interface on the client side (without parsing to VC-n). Multiple TU-12 or TUG-3 signals are combined into a single signal using byte interleaving. GMP mapping is then used to map the single signal, or multiple byte-interleaved TU-12 / TUG-3 signals, or the single AU-4 signal, into the fgOPUflex payload area. No CnD is required during mapping.

[0008] At the demapping end, v1 TU-12, v2 TUG-3, or 1 AU-4 is extracted from the fgOPUflex. After demapping the v1 TU-12, v2 TUG-3, or 1 AU-4 from the fgOPUflex payload area, the corresponding v1 VC-12, v2 VC-3, or VC-4 signal is further extracted. This v1 VC-12, v2 VC-3, or VC-4 signal is then mapped to a new v1 TU-12, v2 TUG-3, or 1 AU-4. These new v1 TU-12, v2 TUG-3, or 1 AU-4 signals are multiplexed onto the new client-side STM-N output interface. These new v1 TU-12, v2 TUG-3, or 1 AU-4, as well as the client-side STM-N output interface, are generated based on a local clock that is synchronized with the source-side STM-N interface clock. Here,

[0009] 1 TU-12, which is a TU-12 frame, and its client frame is a VC-12 frame, which is mapped into the 16-byte payload block of fgODUflex(1);

[0010] v1 TU-12, which is a TU-12 frame after byte interleaving on v1, and its client frame is a v1 VC-12 frame, which is mapped to the 16-byte payload block of fgODUflex(p). The specific p value is shown in Table 3;

[0011] 1 TUG-3, which is a multiframe composed of 8 consecutive TUG-3 frames, and its client frame is 1 VC-3, which is mapped into the 16-byte payload block of fgODUflex(5);

[0012] 2-way TUG-3, which is a 2-way TUG-3 frame after four consecutive bytes are interleaved, and its client frame is 2-way vc-3, which is mapped into the 16-byte payload block of fgODUflex(10);

[0013] 1 AU-4, which is a multiframe composed of 8 consecutive AU-4 frames, and its client frame is 1 VC4, which is mapped into the 16-byte payload block of fgODUflex(16).

[0014] fgOPUflex (VC-n) mapping overhead includes: payload type (PT = 0x05, 0x07 or 0x08); client signal failure (CSF). Figure 1 As shown, two groups of JC1-JC6 bytes are used for Cm and CnD, with each group carrying one Cm and one CnD. JC1, JC2, and JC3 are used for Cm overhead information, while bits 4-8 of JC4, JC5, and JC6 are reserved. Each two-row subcontainer corresponds to a 9-bit Client Frame Start Overhead (CFS), located in bits 3 to 8 of row 1, column 14, and bits 1 to 3 of column 15, and in bits 3 to 8 of row 3, column 14, and bits 1 to 3 of column 15, respectively. The CFS in row 1 indicates the number of valid data blocks between the starting payload block #1 and the start of the next service frame in the two-row subcontainer. The CFS in row 3 indicates the number of valid data blocks between the starting payload block #1 and the start of the next service frame in the two-row subcontainer. As shown in the example, the CFS indicates the number of valid data blocks between payload block #1 and payload block #M. CFS is a binary value ranging from 0 to Cm-1. CFS = 0 indicates that there are no valid data blocks before the start of the next new service frame in the current 2-line sub-container payload area. The start of this new service frame will be at the first data block position. CFS = Cm-1 indicates that the start of the next service frame will be at the last data block position in the current 2-line sub-container payload area. If the current 2-line sub-container payload area does not contain a service frame start, CFS is set to 0x1FF.

[0015] The client service frame is a TU-12 frame, a v1×TU-12 byte interleaved frame, a multiframe of eight consecutive TUG-3 frames, a multiframe of four consecutive 2×TUG-3 byte interleaved frames, or a multiframe of eight consecutive AU-4 frames. The client service frame starts at the first H1 byte of a TUG-3 or AU-4 frame, or the first V1 byte of a TU-12 frame.

[0016] Table 1 specifies the parameters M and n in the GMP Cm:CnD overhead for SDH virtual container (VC) clients VC-12, VC-3, and VC-4. Other SDH VC clients may be defined in the future. In all cases, the granularity (m) of the GMP padding data bytes will be 128 bits (16 bytes). Table 2 specifies the alternative signals for SDH VC clients. Table 3 specifies the fgOPUflex(p) payload capacity and its C128,min and C128,max values ​​for these service signals.

[0017] During a signal failure state of an input SDH VC client signal (eg, in the event of a loss of input signal), the failed input signal is replaced with a substitute signal defined in Table 3.

[0018] During the signal failure state of the input fgODUflex signal (in the case of fgODUflex-AIS, fgODUflex-LCK, fgODUflex-OCI states), the affected SDH VC client signal is replaced with the substitute signal defined in Table 2.

[0019] Table 1: Mapping of m, n and CnD for SDH VC-n to fgOPUflex

[0020] User Signal Nominal bit rate (kbit / s) Bit rate tolerance (ppm) m n CnD TU-12 (VC-12 / E1) 2 304 ±20 128 N / A unnecessary TUG-3 (VC-3) 49 536 ±20 128 N / A unnecessary AU-4 (VC-4) 150 912 ±20 128 N / A unnecessary

[0021] Table 2 SDH Vc-n service replacement signal

[0022] Business Signal Alternative signal Bit rate tolerance (ppm) VC-12 (TU-12) TU-AIS ±20 VC-3 (TUG-3) TU-AIS ±20 VC-4 (AU-4) AU-AIS ±20 E1(VC-12 / TU-12) TU-AIS ±20

[0023] Table 3 C128,min and C128,max for SDH VC-n mapping fgOPUflex(p)

[0024]

[0025]

[0026] However, the main technical defects of the existing technical solutions are:

[0027] 1. Existing technology uses a CFS pointer to indicate the starting position of a service frame, requiring that multiple TU-12 / TUG-3 channels be aligned before mapping into fgOPUflex. Existing technology directly maps multiple TU-12 / TUG-3 channels extracted from the STM-N interface into fgOPUflex. This requires that the multiple TU-12 / TUG-3 channels come from the same AU-4. Otherwise, the VC-12 / VC-3 must be parsed from the TU-12 / TUG-3 and then repacked into TU-12 / TUG-3 channels to align them before mapping into fgOPUflex. This increases processing latency and is cumbersome.

[0028] 2. Use GMP mapping (adapt the rate of v1 TU-12, v2 TUG-3 or 1 AU-4 to fgOPUflex) to map it into fgOPUflex, which is complex to process.

[0029] These factors affect the latency performance and mapping efficiency of VC-n services into fgOPUflex. Summary of the Invention

[0030] In response to the deficiencies of existing technologies, the present invention provides a mapping method for multiple VC-n services to fgOPUflex, which is used to simplify the mapping process while ensuring the functional integrity of the mapping of multiple VC-n services to fgOPUflex, thereby solving the problem in the prior art that the mapping process of multiple VC-n services to fgOPUflex is cumbersome and affects the efficiency of mapping execution.

[0031] In order to solve the above technical problems, the present invention adopts the following technical solutions:

[0032] In a first aspect, the present invention provides a method for mapping multiple VC-n services to fgOPUflex, comprising the following steps:

[0033] Decode the TU-n / AU-n coded signal and parse and extract the VC-n service code stream; the VC-n service code stream is composed of several VC-n service data frames;

[0034] Inserting a preset overhead byte for indicating positioning mapping information into the VC-n service data frame; the preset overhead byte is used to indicate the frame header position and data feature information of the VC-n service data frame;

[0035] Performing frame structure coding adjustment on the VC-n service data frame filled with preset overhead bytes so that the rate of the coded data signal composed of the adjusted coded data frame can be adapted to the fgODUflex(p) payload bit rate;

[0036] The adjusted coded data signal is mapped to fgOPUflex for transmission.

[0037] As a preferred solution, the specific method of decoding the TU-n / AU-n encoded signal is: first, obtain the TU-n / AU-n encoded signal in the tributary unit TU-n / management unit AU-n from the STM-N interface, remove the unit pointer in each TU-n / AU-n data frame therein, extract the VC-n service data frame contained in the TU-n / AU-n data frame, and thus obtain the VC-n service code stream.

[0038] As a preferred solution, the preset overhead bytes used to indicate the positioning mapping information include a frame header position indication byte X1, an alarm information byte X2, and a port identifier byte X3; the frame header position indication byte X1 is used to indicate the frame header position of the formed service filling data frame; the alarm information byte X2 is used to indicate the alarm information of the VC-n service data; and the port identifier byte X3 is used to indicate the path number information corresponding to the VC-n service data contained in the formed service filling data frame.

[0039] As a preferred solution, the specific method of inserting the preset overhead byte for indicating the positioning mapping information into the VC-n service data frame is: inserting the preset overhead byte before the frame header of the VC-n service data to form a service filling data frame, and the frame header position indication byte X1 serves as the starting byte of the service filling data frame to indicate the frame header byte position of the service filling data frame.

[0040] As a preferred solution, the specific method of performing frame structure coding adjustment on the VC-n service data frame filled with preset overhead bytes is: based on the difference between the nominal bit rate of the VC-n service data and the nominal bit rate of the fgODUflex(p) payload, calculating and determining the number of bytes required to fill the service filling data frame to adapt it to the nominal bit rate of the fgODUflex(p) payload, and then filling the service filling data frame with a corresponding number of idle bytes, so that the rate of the coded data signal composed of the adjusted coded data frame after filling can be adapted to the fgODUflex(p) payload bit rate.

[0041] As a preferred solution, the number of bytes B required to fill the service filling data frame to adapt to the fgODUflex(p) payload bit rate is idle Calculated as follows:

[0042] B idle =B bytes -B frame ;

[0043] Among them, B idleIndicates the number of bytes to be filled; B frame Indicates the total number of bytes of the service filling data frame; B bytes Indicates the number of bytes that need to be transmitted in one frame / multiframe time at the nominal bit rate of the fgODUflex(p) payload;

[0044] The number of bytes that need to be transmitted per frame / multiframe time B bytes The value of is determined by the read and write address difference of the FIFO for reading and writing VC-n data frames / multiframes at that time: If the read and write address difference of the FIFO is greater than half of the FIFO depth, then B is taken. bytes =B min ; If the read and write address difference of the FIFO is less than or equal to half of the FIFO depth, then take B bytes =B max Among them, B min 、B max The value of is calculated as follows:

[0045]

[0046] Among them, B num Estimated number of bytes transmitted for a single frame per channel; Indicates rounding down; R ODUflex Indicates the payload nominal bit rate of fgODUflex(p) data; N VC Indicates the maximum number of VC-n data transmission paths when the P value in fgODUflex(p) data is minimum; R1 indicates the nominal bit rate of one VC-n data transmission path in fgODUflex(p) data; T frame Indicates the transmission period of VC-n data frame / multiframe; B payload Indicates the number of bytes in the payload of the VC-n data frame / multiframe; R pos and R neg are the positive tolerance transmission rate and negative tolerance transmission rate of the VC-n data frame respectively, and R pos =R VC ·(1+Tol ppm ), R neg =R VC ·(1-Tol ppm ), R VC is the nominal transmission rate of VC-n data, Tol ppm The deviation tolerance value of the transmission rate of VC-n data.

[0047] As a preferred solution, the specific method of filling the idle bytes in the service filling data frame is: inserting an idle byte every M bytes in the VC-n data frame included in the service filling data frame, inserting Y idle bytes at the end of the service filling data frame, and M and Y are calculated as follows:

[0048]

[0049] Among them, B frame Indicates the total number of bytes of the service filling data frame; Indicates rounding up; idle max Indicates the upper limit of the number of idle bytes that can be inserted into the service filling data frame, and has Indicates rounding down.

[0050] As a preferred solution, the specific method of mapping the adjusted coded data signal to fgOPUflex for transmission is: filling the service filling data frame after rate adaptation into the fgOPUflex payload in a byte interleaving manner to form an fgOPUflex coded signal for transmission.

[0051] In a second aspect, corresponding to the above-mentioned method for mapping multiple VC-n services to fgOPUflex, the present invention further provides a method for demapping multiple VC-n services to fgOPUflex, characterized in that it includes the following steps:

[0052] Obtaining an fgOPUflex payload data signal from a received fgOPUflex data signal;

[0053] Locating the synchronization frame header position from the fgOPUflex payload data signal, thereby determining the position of each encoded data frame header;

[0054] Locate the port identifier of the coded data frame according to the frame header position, thereby determining the port number of each coded data;

[0055] De-mapping the coded data frame according to the mapping coding rule, deleting the inserted preset overhead bytes, parsing out the VC-n service data frame therein, and obtaining the VC-n service code stream;

[0056] The parsed VC-n service code stream is then TU-n / AU-n encoded frame by frame to form a TU-n / AU-n encoded signal.

[0057] As a preferred solution, the preset overhead byte in the coded data frame is inserted at the frame header position, and the preset overhead byte includes a frame header position indication byte X1 and is located at the first byte in the coded data frame;

[0058] The specific method of locating the synchronization frame header position from the coded data signal is as follows: searching for the frame header position indication byte X1 in the same time slot of the coded data signal, confirming that the bytes following the found frame header position indication byte X1 meet the format requirements of the preset overhead bytes in the mapping coding rule, and the number of bytes between each two adjacent frame header position indication bytes X1 is equal to B bytes If the number of byte X1 is found, it is determined that the correct frame header position indication byte X1 is found.

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

[0060] 1. The present invention directly maps VC-n services into fgOPUflex and inserts preset overhead bytes to indicate the synchronization frame header position and port identifier in the mapped code stream. This facilitates finding the frame header position for subsequent demapping synchronization. This eliminates the need for complex alignment between multiple service signals during the mapping process and eliminates the need to indicate the starting position of the service frame in the fgOPUflex overhead, reducing mapping overhead and processing latency. It also eliminates the requirement for multiple TU-12 / TUG-3 channels to originate from the same AU-4, significantly improving networking flexibility and mapping efficiency.

[0061] 2. The solution of the present invention can also use the inserted preset overhead bytes to simultaneously record other additional information such as TU-12 / TUG-3 / AU-4 alarm indication information, thereby preserving the integrity of the alarm information in the TU-12 / TUG-3 / AU-4 data.

[0062] 3. The solution of the present invention abandons the traditional GMP mapping method, and instead adapts the data rate by adjusting the frame structure encoding during data encapsulation and packaging, which greatly reduces the processing complexity, further simplifies the rate adaptation process, and optimizes the mapping and demapping process.

[0063] Under the premise of the completeness of the mapping / demapping functions of multiple VC-n services to fgOPUflex, the solution of the present invention simplifies the mapping / demapping process, reduces the mapping overhead and processing delay, and improves the mapping execution efficiency, effectively solving the problem in the prior art that the mapping process of multiple VC-n services to fgOPUflex is cumbersome and affects the mapping execution efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] In order to make the purpose, technical solutions and advantages of the present invention more clear, the present invention will be described in detail below with reference to the accompanying drawings, in which:

[0065] Figure 1 It is a flowchart of a method for mapping VC-n to fgOPUflex in the prior art.

[0066] Figure 2 This is a flow chart of the mapping method of multiple VC-n services to fgOPUflex according to the present invention.

[0067] Figure 3 It is a flow chart of the demapping method of multiple VC-n services to fgOPUflex according to the present invention.

[0068] Figure 4 This is a schematic diagram of the frame formats of the TU-12 multiframe and the VC-12 multiframe in the first embodiment.

[0069] Figure 5 This is a schematic diagram of a service filling data frame obtained after inserting the preset overhead bytes in Example 1.

[0070] Figure 6 This is a schematic diagram of the frame formats of TUG-3 and VC-3 in the second embodiment.

[0071] Figure 7 This is a schematic diagram of a service filling data frame obtained after inserting the preset overhead bytes in Example 2.

[0072] Figure 8 This is a schematic diagram of the frame formats of AU-4 and VC-4 in Example 3.

[0073] Figure 9 This is a schematic diagram of a service filling data frame obtained after inserting the preset overhead bytes in Example 3. DETAILED DESCRIPTION

[0074] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. The components of the embodiments of the present invention generally described and shown in the drawings herein can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the invention claimed for protection, but only represents selected embodiments of the present invention. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0075] 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.

[0076] First, technical terms involved in the present invention are explained.

[0077] OTN: Optical Transport Network;

[0078] SDH: Synchronous Digital Hierarchy;

[0079] SONET: Synchronous Optical Networking;

[0080] WDM: Wavelength Division Multiplexing;

[0081] ODUflex: Flexible Optical Data Unit;

[0082] fgOTN: fine grain OTN;

[0083] OSU: Optical Service Unit;

[0084] fgODUflex: fine grain flexible Optical Data Unit;

[0085] OPUk: Optical Payload Unit-k (k=0, 1, 2, 2e, 3, 4, flex);

[0086] E1: European 30-channel pulse coding modulation;

[0087] VC: Virtual Container;

[0088] CBR: Constant Bit Rate;

[0089] ITU-T: International Telecommunication Union Telecommunication Standardization Bureau (International Telecommunication Union);

[0090] ODUj: Optical Channel Data Unit (j=0, 1, 2, 2e, 3, flex);

[0091] ODUk / Cn: K is used to indicate different bit rates and is used to indicate ODUs with k > j. Cn indicates the bit rate of n*100 Gbit / s.

[0092] VC-n: Virtual Container-n;

[0093] TU[G] / AU: TU: tributary unit; TUG: tributary unit group; AU: administrative unit;

[0094] STM-N: Synchronous Transport Module Level N;

[0095] AU-4: Administrative Unit-4;

[0096] TU-12: tributary unit-12;

[0097] Cm: number of m-bit client data entities per server frame period;

[0098] Cn: number of client n-bit dataentities per server frame period;

[0099] CnD: difference between Cn and (m / nx Cm);

[0100] JC: Justification Control;

[0101] GMP: Generic Mapping Procedure;

[0102] TDM: Time Division Multiplexing;

[0103] The present invention will be further described below with reference to specific implementation methods.

[0104] The present invention belongs to the field of optical transport network technology, and specifically provides a method for mapping multiple VC-n services to fgOPUflex. The method adopts a new mapping method, does not use TU-12 / TUG-3 / AU-4 format data to map to fgOPUflex, adopts a method of directly mapping VC-n services into fgOPUflex, and inserts preset overhead bytes to indicate the synchronization frame header position and port identifier in the mapped code stream, so as to facilitate finding the frame header position for subsequent demapping synchronization, so that the multiple service signals do not require alignment during the mapping process, and do not need to be aligned in fgOPUflex. The overhead indicates the starting position of the service frame, simplifying the mapping process; it does not require multiple TU-12 / TUG-3 to come from the same AU-4, making the application more flexible; at the same time, the inserted preset overhead bytes can be used to simultaneously record the alarm indication information of the TU-12 / TUG-3 / AU-4 of the multiple service signals and other additional information, thus preserving the integrity of the alarm information in the TU-12 / TUG-3 / AU-4 data; in addition, the mapping process does not adopt the GMP mapping method, but adapts the data rate through frame structure coding adjustment during data encapsulation and packaging, further simplifying the rate adaptation process. Therefore, while ensuring the integrity of the mapping / demapping function of multiple VC-n services to fgOPUflex, the mapping / demapping process is simplified and the mapping execution efficiency is improved, effectively solving the problem of cumbersome processing and affecting the mapping execution efficiency of the mapping process of multiple VC-n services to fgOPUflex in the prior art.

[0105] Based on the above design ideas, such as Figure 2 As shown, the method for mapping multiple VC-n services to fgOPUflex provided by the present invention includes the following steps:

[0106] Step S001: Decode the TU-n / AU-n coded signal and parse and extract a VC-n service code stream; the VC-n service code stream is composed of several VC-n service data frames.

[0107] In OTN, the coded frame structure and nominal bit rate of the TU-n / AU-n coded signal are known. Therefore, the coded frame protocol of the TU-n / AU-n coded signal can be directly decoded and parsed to extract the VC-n service stream. Specifically, the TU-n / AU-n coded signal from the tributary unit TU-n / administrative unit AU-n is first obtained from the STM-N interface. For each TU-n / AU-n data frame, the unit pointer is removed from the frame to extract the VC-n service data frame contained in the TU-n / AU-n data frame, thereby obtaining the VC-n service stream. The VC-n service stream is composed of VC-n service data frames. If the TU-n coded signal is multi-channel (for example, a TU-12 with a v1 channel or a TUG-3 coded signal with two channels), the VC-n service data frames of different channels need to be parsed and the channel number information is recorded, corresponding to the VC-n service streams of different channels.

[0108] Step S002: inserting a preset overhead byte for indicating positioning mapping information into the VC-n service data frame; the preset overhead byte is used to indicate the frame header position and data feature information of the VC-n service data frame.

[0109] The purpose of inserting the preset overhead bytes here is primarily to provide frame header position indication information, indicating the synchronization frame header position and port identifier in the mapped code stream. This facilitates finding the frame header position for subsequent demapping synchronization. This eliminates the need for alignment between multiple service signals during the mapping process, eliminates the need to indicate the service frame start position in the fgOPUflex overhead, simplifies the mapping process, and eliminates the requirement that multiple TU-12 / TUG-3s come from the same AU-4, making applications more flexible. Furthermore, the insertion of the preset overhead bytes can also serve other purposes. For example, the inserted preset overhead bytes can be used to simultaneously record additional information such as alarm indication information for the TU-12 / TUG-3 / AU-4 of multiple service signals, thereby preserving the integrity of the alarm information in the TU-12 / TUG-3 / AU-4 data. Therefore, in a specific implementation, the inserted preset overhead bytes can be designed to include the frame header position indication byte X1, the alarm information byte X2, and the port identifier byte X3. The frame header position indication byte X1 indicates the frame header position of the service filler data frame; the alarm information byte X2 indicates the alarm information of the VC-n service data; and the port identifier byte X3 indicates the path number information corresponding to the VC-n service data contained in the service filler data frame. Of course, other types of bytes can be designed within the inserted preset overhead bytes. For example, a reserved byte X4 can be added as a preset overhead byte to reserve other information to be transmitted later. This can be defined as needed.

[0110] In practice, the preset overhead bytes can theoretically be inserted anywhere within the VC-n service data frame. However, when using a virtual container VC-n to carry client signals, if the preset overhead bytes are scattered and embedded in the VC-n payload area, the demapping end must achieve frame synchronization through the frame header position indicator byte X1. If the frame header position indicator byte X1 is not placed in the frame alignment signal (FAS) area of ​​the OTUk frame in accordance with the G.709 standard, but is instead configured within the VC-n payload area, this will cause frame synchronization timing offset. That is, after the first detection of the frame header position indicator byte X1, the demapping end can only correctly decode subsequent VC-n frames, while the VC-n frames preceding this byte X1 will lose data due to the loss of synchronization reference.

[0111] To mitigate this technical risk, we recommend a prioritized design for inserting pre-set overhead bytes: These pre-set overhead bytes (including the header position indicator byte X1, the alarm information byte X2, and the port identifier byte X3) are inserted before the header of the VC-n service data to form a service filler data frame. The header position indicator byte X1 serves as the starting byte of the service filler data frame, indicating the header byte position of the service filler data frame. This ensures that the demapping process adheres to the following timing:

[0112] 1. When the demapping end detects the frame header position indication byte X1 for the first time, it establishes the frame synchronization reference point;

[0113] 2. Sequentially read the subsequent alarm information byte X2 and port identifier byte X3 to confirm the mapping encoding rule;

[0114] 3. Ability to extract complete VC-n payload data based on a fixed offset.

[0115] This prioritized preset overhead byte insertion design not only complies with the OTN frame structure layered model, but also ensures that the mapping end can continuously parse all subsequent service frames after a single frame synchronization, effectively avoiding payload loss due to frame alignment deviation, and more in line with the ITU-T G.709 standard requirements for OTN frame synchronization accuracy and payload extraction timing.

[0116] Step S003: performing frame structure coding adjustment on the VC-n service data frame filled with the preset overhead bytes, so that the rate of the coded data signal composed of the adjusted coded data frame can be adapted to the fgODUflex(p) payload bit rate.

[0117] There are many options for adjusting the signal rate through frame structure encoding. To simplify implementation in specific applications, the present invention adopts a relatively simple method: padding with idle bytes. Specifically, the method calculates the number of bytes required to adapt the service padding data frame to the nominal bit rate of the fgODUflex(p) payload based on the difference between the nominal bit rate of the VC-n service data and the nominal bit rate of the fgODUflex(p) payload. The service padding data frame is then padded with the corresponding number of idle bytes, so that the rate of the coded data signal formed by the padded, adjusted coded data frame is compatible with the fgODUflex(p) payload bit rate.

[0118] Specifically, the number of bytes B required to fill the service filling data frame to adapt it to the fgODUflex(p) payload bit rate is idle Calculated as follows:

[0119] B idle =B bytes -B frame ;

[0120] Among them, B idle Indicates the number of bytes to be filled; B frame Indicates the total number of bytes of the service filling data frame; B bytes Indicates the number of bytes that need to be transmitted in one frame / multiframe time at the nominal bit rate of the fgODUflex(p) payload.

[0121] And there are:

[0122] The number of bytes that need to be transmitted per frame / multiframe time B bytes The value of is determined by the read and write address difference of the FIFO for reading and writing VC-n data frames / multiframes at that time: If the read and write address difference of the FIFO is greater than half of the FIFO depth, then B is taken. bytes =B min ; If the read and write address difference of the FIFO is less than or equal to half of the FIFO depth, then take B bytes =B max Among them, B min 、B max The value of is calculated as follows:

[0123]

[0124] Among them, B num Estimated number of bytes transmitted for a single frame per channel; Indicates rounding down; R ODUflex Indicates the payload nominal bit rate of fgODUflex(p) data; NVC Indicates the maximum number of VC-n data transmission paths when the P value in fgODUflex(p) data is the smallest. For example, VC12 corresponds to N VC Take 4, VC3 corresponds to N VC Set to 1, VC4 corresponds to N VC Take 1; R1 represents the nominal bit rate of VC-n data transmitted in fgODUflex(p) data; T frame Indicates the transmission period of VC-n data frame / multiframe; B payload Indicates the number of bytes in the payload of the VC-n data frame / multiframe; R pos and R neg are the positive tolerance transmission rate and negative tolerance transmission rate of the VC-n data frame respectively, and R pos =R VC ·(1+Tol ppm ), R neg =R VC ·(1-Tol ppm ), R VC is the nominal transmission rate of VC-n data, Tol ppm The deviation tolerance value of the transmission rate of VC-n data.

[0125] After determining the number of bytes required to fill in order to adapt the signal rate, the specific method for filling the idle bytes in the service filling data frame can be various. For example, all the bytes required for filling can be directly stacked after the service filling data frame to perform frame structure encoding. However, in order to insert the inserted idle bytes into the service as evenly as possible, as a preferred embodiment of the present invention, the specific method for filling the idle bytes in the service filling data frame can be as follows:

[0126] An idle byte is inserted every M bytes in the VC-n data frame included in the service filling data frame, and Y idle bytes are inserted at the end of the service filling data frame, and M and Y are calculated as follows:

[0127]

[0128] Among them, B frame Indicates the total number of bytes of the service filling data frame; Indicates rounding up; idle max Indicates the upper limit of the number of idle bytes that can be inserted into the service filling data frame, and has Indicates rounding down.

[0129] In this way, by periodically inserting padding bytes evenly distributed between the VC-n data frames in the service padding data frames, the valid payload VC-n data frames contained in the service padding data frames are divided into multiple data blocks of equal length (each data block contains an M-byte payload). This frame structure design makes the data stream after encoding and mapping present a regular interval characteristic: when the receiving end completes the parsing of the M-byte payload, it will trigger a predefined idle byte interval. This interval mechanism provides a configurable scheduling window for the demapping process, allowing operations such as buffering, checksum calculation, or protocol header parsing to be inserted between consecutive payload parsing cycles. Through this segmented processing architecture, the timing complexity of a single VC-n data payload parsing is significantly reduced, effectively alleviating the resource competition pressure of the real-time processing link, thereby optimizing the timing convergence characteristics of the OTN demapping process and helping to improve the throughput efficiency of data code stream processing.

[0130] Step S004: Map the adjusted coded data signal to fgOPUflex for transmission.

[0131] In a specific implementation, the coded data signal obtained after adjustment is mapped to fgOPUflex, and the service filling data frame after rate adaptation is filled into the fgOPUflex payload in a byte-interleaved manner to form an fgOPUflex coded signal for transmission.

[0132] The mapped OPUflex signal needs to be further encapsulated into ODUflex (Optical Channel Data Unit flexible) and finally realized optical layer transmission through the OTUk (Optical Channel Transport Unit-k) frame structure, supporting broadband service carrying from 100Mbps to 100Gbps, making it suitable for scenarios that require dynamic bandwidth adjustment such as 5G fronthaul and data center interconnection.

[0133] Correspondingly, the present invention also provides a method for demapping multiple VC-n services to fgOPUflex, such as Figure 3 As shown, the following steps are included:

[0134] Step S011: Obtain the fgOPUflex payload data signal from the received fgOPUflex data signal.

[0135] Step S012: Locate the synchronization frame header position from the fgOPUflex payload data signal, thereby determining the position of each coded data frame header. Here, the specific method of locating the synchronization frame header position is: search for the frame header position indication byte X1 from the same time slot of the coded data signal, confirm that the bytes subsequent to the found frame header position indication byte X1 meet the format requirements of the preset overhead bytes in the mapping coding rule, and the number of bytes between each two adjacent frame header position indication bytes X1 is equal to B bytes If the number of byte X1 is found, it is determined that the correct frame header position indication byte X1 is found.

[0136] Step S013: Locate the port identifier of the coded data frame according to the frame header position, thereby determining the port number of each coded data. This step obtains the port number of each coded data so that the data of each channel can be mapped according to the port number of each coded data during demapping.

[0137] Step S014: Demap the coded data frame according to the mapping coding rule, delete the inserted preset overhead bytes, parse out the VC-n service data frame, and obtain the VC-n service code stream.

[0138] Step S015: The parsed VC-n service code stream is TU-n / AU-n encoded frame by frame to form a TU-n / AU-n encoded signal.

[0139] The demapping process, i.e., performing the reverse parsing process according to the mapping process rules, recovers the TU-n / AU-n coded signal. Of course, the advantages of the mapping process in terms of simplicity of execution are also inherited in the demapping process.

[0140] In order to facilitate understanding of the mapping and demapping process of the present invention, the present invention is further described below through examples.

[0141] Example 1: Mapping and demapping methods for VC-12 service code streams

[0142] 1.1 Mapping of VC-12 Service Streams

[0143] S101: Decode the TU-12 coded signal and parse and extract the VC-12 service code stream.

[0144] First, TU-12 signals are obtained from the STM-N interface and then further parsed into VC-12. A TU-12 multiframe consists of 144 bytes (a TU-12 frame is 36 bytes, and four base frames form a multiframe), which consists of four bytes of TU-12PTR (tributary unit pointer, Figure 4The frame format of TU-12 multiframe and VC-12 multiframe is as follows: Figure 4 As shown, the first byte V5 of the VC-12 multiframe can be located at any position in TU-12 multiframes 0 to 139.

[0145] S102: Insert a preset overhead byte for indicating positioning mapping information into the VC-12 service data frame.

[0146] In this embodiment, the preset overhead bytes sequentially inserted before the VC-12 multiframe header include, in addition to the header position indication byte X1, the alarm information byte X2, and the port identifier byte X3, a reserved idle byte X4. In the service filling data frame formed after insertion, the insertion positions of the preset overhead bytes are as follows: Figure 5 shown.

[0147] In this embodiment, the frame header position indication byte X1 is fixedly set to 0XF6.

[0148] The upper four bits of the alarm information byte X2 are fixed to 4'b1010, and the lower four bits transmit the alarm information. The meanings of the lower four bits are as follows:

[0149] 4'b0001, indicating signal failure, indicating that this frame is wrong;

[0150] 4'b0010, indicating path failure;

[0151] 4'b0011, indicating AIS alarm;

[0152] Others, reserved.

[0153] The port identifier byte X3 is used to indicate the number of channels. When transmitting multiple VC-12 services, it indicates the port number of the current frame. When the current frame is an invalid frame, its value is 0XFF.

[0154] The idle byte X4 is reserved.

[0155] As a result, the total number of bytes of the service filling data frame obtained after inserting the preset overhead bytes is consistent with the total number of bytes of a TU-12 multiframe, a total of 144 bytes. This processing is also to facilitate demapping and recovery of TU-12 data in the later stage.

[0156] S103: Perform frame structure coding adjustment on the VC-12 service data frame filled with preset overhead bytes, so that the rate of the coded data signal composed of the adjusted coded data frame can adapt to the fgODUflex(p) payload bit rate.

[0157] First, according to the difference between the nominal bit rate of the VC-12 service data and the nominal bit rate of fgODUflex(p), the number of bytes required to fill the service filling data frame to adapt to the nominal bit rate of fgODUflex(p) is calculated and determined; then, Figure 5 In the VC-12 data frame included in the service filling data frame structure shown, an idle byte is inserted every M bytes, and Y idle bytes are inserted at the end of the service filling data frame to adapt the service rate to fgODUflex(p).

[0158] M and Y are calculated as follows:

[0159] Case 1: When P = 1 and four VC-12 packets are transmitted, M and Y are calculated as follows:

[0160] The nominal payload bit rate of fgODUflex(1) is 10.322097 Mbit / s, and it can transmit up to four VC-12s. The multiframe period of a VC-12 is 500 µs. The nominal bit rate of a VC-12 is 2.240 Mbit / s. VC-n services support a bit tolerance of ±20 pmm. The statistically relevant parameters are as follows:

[0161] fgODUflex(1) payload nominal bit rate R ODUflex =10.322097Mbit / s=10.322097×10 6 bit / s;

[0162] The maximum number of channels N for transmitting VC-12 data in fgODUflex(1) data VC =4;

[0163] Nominal bit rate of each VC-12 data channel transmitted in fgODUflex(1) data

[0164] Transmission period of a single VC-12 multiframe T frame =500μs=500×10 -6 s;

[0165] Nominal bit rate R of VC-12 data frame VC =2.240Mbit / s;

[0166] The deviation tolerance value Tol of the transmission rate of VC-12 data ppm = ±20ppm = ±20×10 -6 ;

[0167] Number of bytes of payload in the VC-12 multiframe B payload =140;

[0168] The total number of bytes of the service filling data frame B frame =144;

[0169] The upper limit of the number of idle bytes that can be inserted in the service filling data frame is recorded as idle max ;

[0170] The number of bytes required to fill the service filling data frame to adapt to the fgODUflex(p) payload bit rate is recorded as B idle .

[0171] First calculate the nominal bit rate of each VC-12 data transmitted in the fgODUflex(1) data =2.58052425m bit / s;

[0172] Therefore, the estimated number of bytes transmitted per channel per frame is

[0173] The positive and negative tolerance transmission rates of VC-12 data frames are:

[0174] R pos =R VC ·(1+Tol ppm )=2.24*(1+20 / 1000000)Mbit / s=2.2400448Mbit / s;

[0175] R neg =R VC ·(1-Tol ppm )=2.24*(1-20 / 1000000)Mbit / s=2.2399552Mbit / s;

[0176] Therefore, the number of bytes of the data frame after rate adaptation filling is B bytes Determined as:

[0177] The rate of VC-12 data that can be transmitted when 161 bytes are transmitted is: (140 / 161)*R1=2.243913Mbit / s, which is greater than R pos =2.2400448Mbit / s;

[0178] The rate of VC-12 data that can be transmitted when 162 bytes are transmitted is: (140 / 162)*R1=2.223008Mbit / s, which is less than R neg =2.2399552Mbit / s.

[0179] That is, the bytes transmitted in one multiframe period are 161 or 162 bytes, which meets the bit tolerance of ±20pmm. Therefore, the number of bytes required to fill the service filling data frame to adapt to the nominal bit rate of fgODUflex(1) is B. idle for:

[0180] B idle =B bytes -B frame =(161 or 162)-144=17 or 18 bytes;

[0181] Then, M and Y are calculated as follows:

[0182]

[0183] Y=B idle -idle max =(17 or 18)-15=2 or 3;

[0184] That is, to adapt the service filling data frame to the fgODUflex(1) nominal bit rate, one idle byte must be inserted every M=9 bytes in the VC-12 data frame contained in the service filling data frame. 15 idle bytes can be inserted in the middle of the VC-12 data frame, and the number of bytes inserted at the end of the frame is Y. min =2 or Y max =3.

[0185] Case 2: When p = 1, there is only one VC-12 data channel. To simplify the mapping method, the concept of invalid frames is introduced. It can be considered that 4 VC-12s are transmitted, of which 3 VC-12s transmit invalid frames. The VC-12 data frames are padded to 161 / 162 bytes according to the above method. The calculation result is also M = 9, Y min =2 or Y max = 3. For VC12, as long as p value*4≥the maximum number of user signals that can be mapped under the current p value, invalid frames can be introduced.

[0186] Case 3: When p=1, when two VC-12 data are transmitted, it can be considered that four VC-12 frames are transmitted, of which two VC-12 frames transmit invalid frames. The VC-12 data frames are padded to 161 / 162 bytes according to the above method. The calculation result is also M=9, Y min =2 or Y max =3.

[0187] Case 4: When p=1, when three VC-12 data are transmitted, it can be considered that four VC-12 frames are transmitted, one of which transmits an invalid frame. The VC-12 data frame is padded to 161 / 162 bytes according to the above method. The calculation result is also M=9, Y min =2 or Ymax =3.

[0188] Case 5: When P=2 and five VC-12 data channels are transmitted, it can be considered that eight VC-12 channels are transmitted, of which three VC-12 channels transmit invalid frames. In this case, rate adaptation is performed according to the calculation when P=1. The VC-12 data frames are padded to 161 / 162 bytes in the above manner. The calculated result is also M=9, Y min =2 or Y max =3.

[0189] The M and Y corresponding to other p values ​​are shown in the following table:

[0190] <![CDATA[R ODUflex (kbit / s)]]> User Signal <![CDATA[B bytes ]]> <![CDATA[B idle ]]> M <![CDATA[Y min ]]> <![CDATA[Y max ]]> 10 322.097(p＝1) 1 × VC-12 161 / 162 17 / 18 9 2 3 10 322.097(p＝1) 2×VC-12 161 / 162 17 / 18 9 2 3 10 322.097(p＝1) 3×VC-12 161 / 162 17 / 18 9 2 3 10 322.097(p＝1) 4×VC-12 161 / 162 17 / 18 9 2 3 20 644.194(p＝2) 5×VC-12 161 / 162 17 / 18 9 2 3 30 966.29(p＝3) 10×VC-12 161 / 162 17 / 18 9 2 3 41 288.387(p＝4) 15×VC-12 161 / 162 17 / 18 9 2 3 51 610.484(p＝5) 20×VC-12 161 / 162 17 / 18 9 2 3 61 932.581(p＝6) 25×VC-12 154 / 155 10 / 11 15 1 2 72 254.678(p＝7) 30×VC-12 150 / 151 6 / 7 24 1 2 82 576.774(p＝8) 35×VC-12 147 / 148 3 / 4 48 1 2 92 898.871(p＝9) 40×VC-12 145 / 146 1 / 2 144 1 2 113 543.065(p＝11) 45×VC-12 157 / 158 13 / 14 12 2 3 123 865.162(p＝12) 50×VC-12 154 / 155 10 / 11 15 1 2 134 187.258(p＝13) 55×VC-12 152 / 153 8 / 9 18 1 2 144 509.355(p＝14) 60×VC-12 150 / 151 6 / 7 24 1 2

[0191] S104: Map the adjusted coded data signal to fgOPUflex for transmission.

[0192] The service filling data frame after rate adaptation is directly filled into the fgOPUflex payload in a byte-interleaved manner to form an fgOPUflex encoded signal for transmission.

[0193] 1.2 Demapping of VC-12 Service Streams

[0194] S111. Obtain the fgOPUflex payload data signal from the received fgOPUflex data signal.

[0195] S112: Locate the synchronization frame header position from the fgOPUflex payload data signal, thereby determining the position of each coded data frame header.

[0196] The specific method of locating the synchronous frame header position is: search for the frame header position indication byte X1 in the same time slot of the fgOPUflex payload (the number of time slots is the same as the number of services). When a byte X1 is found, confirm that the bytes subsequent to the byte X1 found meet the format requirements of the preset overhead bytes in the mapping encoding rule (that is, the next three bytes are X2, X3, and X4 respectively), and the number of bytes between each two adjacent frame header position indication bytes X1 is equal to B bytes The number of bytes (taking P=1 as an example, the distance between one byte X1 and the next byte X1 is 160 or 161 bytes) determines that the correct position of the frame header position indication byte X1 is found.

[0197] S113: Locate the port identifier of the coded data frame according to the frame header position, thereby determining the port number of each coded data. This step is to obtain the port number of each coded data so that the port number of each coded data can be matched with each data channel during demapping.

[0198] S114: Demap the encoded data frame according to the mapping coding rules, remove the inserted preset overhead bytes, parse out the VC-12 service data frame, and combine to obtain the VC-12 service code stream. If there are multiple channels, the multiple VC-12 service code stream data are restored according to the port identifier.

[0199] S115: Perform TU-12 encoding on the parsed VC-12 service code stream frame by frame to form a TU-12 encoded signal.

[0200] Example 2: Mapping and demapping methods for VC-13 service code streams

[0201] 2.1 Mapping of VC-13 Service Streams

[0202] S201: Decode the TU-3 coded signal and parse and extract the VC-3 service code stream.

[0203] First, the TUG-3 signal is parsed from the STM-N interface and further parsed into VC-3. The TUG-3 consists of 774 bytes (9 rows and 86 columns), which are composed of 3 bytes of TU-3 pointer, 6 fixed bytes and 765 bytes of VC-3. The frame format of TUG-3 and VC-3 is as follows: Figure 6 As shown, the VC-3 frame header is located at any position from 0 to 764.

[0204] S202: Insert a preset overhead byte for indicating positioning mapping information into the VC-3 service data frame.

[0205] In this embodiment, the preset overhead bytes sequentially inserted before the VC-3 data frame header include, in addition to the frame header position indication byte X1, the alarm information byte X2, and the port identifier byte X3, 6 bytes of fixed insertion bytes, the default value of which is 0. X1 is inserted before the J1 byte, X2 is inserted 85 bytes after X1, X3 is inserted 85 bytes after X2, and a fixed insertion byte is inserted every 85 bytes after X3, as shown in FIG. Figure 7 shown.

[0206] In this embodiment, the meanings of the frame header position indication byte X1, the alarm information byte X2, and the port identifier byte X3 are consistent with those in the first embodiment.

[0207] As a result, the total number of bytes of the service filling data frame obtained after inserting the preset overhead bytes is consistent with the total number of bytes of a TU-3 signal frame, a total of 774 bytes. This processing is also to facilitate demapping and recovery of TU-3 data in the later stage.

[0208] S203 : Perform frame structure coding adjustment on the VC-3 service data frame filled with preset overhead bytes, so that the rate of the coded data signal composed of the adjusted coded data frame can adapt to the fgODUflex(p) payload bit rate.

[0209] First, according to the difference between the nominal bit rate of the VC-3 service data and the nominal bit rate of fgODUflex(p), the number of bytes required to fill the service filling data frame to adapt it to the nominal bit rate of fgODUflex(p) is calculated and determined; then, Figure 7 In the VC-3 data frame included in the service filling data frame structure shown, an idle byte is inserted every M bytes, and Y idle bytes are inserted at the end of the service filling data frame to adapt the service rate to fgODUflex(p).

[0210] M and Y are calculated as follows:

[0211] The nominal payload bit rate of fgODUflex(5) is 51.610484 Mbit / s; the frame period of a VC-3 is 125 μs; the nominal bit rate of a VC-3 is 48.960 Mbit / s; and the bit tolerance is ±20 pmm. The statistically relevant parameters are as follows:

[0212] fgODUflex(5) data payload nominal bit rate R ODUflex =51.610484Mbit / s=51.610484×10 6 bit / s;

[0213] The maximum number of VC-3 data transmission paths N in fgODUflex(5) data VC =1;

[0214] Nominal bit rate of VC-3 data transmitted in fgODUflex(5) data

[0215] VC-3 data frame transmission period T frame =125μs=125×10 -6 s;

[0216] Nominal bit rate R of VC-3 data frame VC =48.960Mbit / s;

[0217] The deviation tolerance value Tol of the transmission rate of VC-3 data ppm = ±20ppm = ±20×10 -6 ;

[0218] Number of bytes of payload of VC-3 data frame B payload =765;

[0219] The total number of bytes of the service filling data frame B frame =774;

[0220] The upper limit of the number of idle bytes that can be inserted in the service filling data frame is recorded as idle max ;

[0221] The number of bytes required to fill the service filling data frame to adapt to the fgODUflex(p) payload bit rate is recorded as B idle .

[0222] Since the nominal bit rate of VC-3 data transmitted in fgODUflex(5) data is R1=R ODUflex =51.610484Mbit / s;

[0223] Therefore, the estimated number of bytes transmitted in a single frame is

[0224] The positive and negative tolerance transmission rates of VC-3 data frames are:

[0225] R pos =R VC ·(1+Tol ppm )=48.960*(1+20 / 1000000)Mbit / s=48.960972Mbit / s;

[0226] R neg =R VC ·(1-Tol ppm )=48.960*(1-20 / 1000000)Mbit / s=48.9590208Mbit / s;

[0227] Therefore, the number of bytes of the data frame after rate adaptation filling is B bytes Determined as:

[0228] The transmission rate of VC-3 data when 806 bytes are transmitted is: (765 / 806)*51.610484=48.985136Mbit / s, which is greater than R pos =48.960972Mbit / s;

[0229] The transmission rate of VC-3 data when 807 bytes are transmitted is: (765 / 807)*51.610484=48.924436Mbit / s, which is less than R neg =48.9590208M bit / s.

[0230] That is, the bytes transmitted in one frame period are 806 or 807 bytes, which meets the bit tolerance of ±20pmm. Therefore, the number of bytes B required to fill the service filling data frame to adapt it to the nominal bit rate of fgODUflex(5) is idle for:

[0231] B idle =B bytes -B frame =(806 or 807)-774=32 or 33 bytes;

[0232] Then, M and Y are calculated as follows:

[0233]

[0234] Y=B idle -idle max =(32 or 33)-30=2 or 3;

[0235] That is, to adapt the service filling data frame to the fgODUflex(5) nominal bit rate, one idle byte needs to be inserted every M=25 bytes in the VC-3 data frame contained in the service filling data frame. 30 idle bytes can be inserted in the middle of the VC-3 data frame, and the number of bytes inserted at the end of the frame is Y. min =2 or Y max =3.

[0236] The M and Y corresponding to other p values ​​are shown in the following table:

[0237] <![CDATA[R ODUflex (kbit / s)]]> User Signal M <![CDATA[Y min ]]> <![CDATA[Y max ]]> 51 610.484(p＝5) VC-3 (TUG-3) 25 2 3 103 220.968(p＝10) 2×VC-3 (2xTUG-3) 25 2 3

[0238] S204: Map the adjusted coded data signal to fgOPUflex for transmission.

[0239] When transmitting one VC-3 packet, the rate-adapted data is directly inserted into the fgOPUflex payload. When transmitting two VC-3 packets, the rate-adapted data is inserted into the fgOPUflex payload using byte interleaving.

[0240] 2.2 Demapping of VC-3 Service Streams

[0241] S211. Obtain the fgOPUflex payload data signal from the received fgOPUflex data signal.

[0242] S212: Locate the synchronization frame header position from the fgOPUflex payload data signal, thereby determining the position of each coded data frame header.

[0243] The specific method of locating the synchronous frame header position is as follows: search for the frame header position indication byte X1 in the same time slot of the fgOPUflex payload. When a byte X1 is found, confirm that the bytes following the byte X1 meet the format requirements of the preset overhead bytes in the mapping encoding rule (that is, the next byte is X2), and the number of bytes between each two adjacent frame header position indication bytes X1 is equal to B bytes If the number of bytes is 806 or 807, it is determined that the correct position of the frame header position indication byte X1 is found.

[0244] S213: Locate the port identifier of the coded data frame according to the frame header position, thereby determining the port number of each coded data. This embodiment only includes one channel of coded data, so there is only one port number.

[0245] S214: Demap the encoded data frame according to the mapping coding rules, delete the inserted preset overhead bytes, parse out the VC-3 service data frame, and combine to obtain the VC-3 service code stream. If there are multiple channels, the multiple VC-3 service code stream data are restored according to the port identifier.

[0246] S215: Perform TU-3 encoding on the parsed VC-3 service code stream frame by frame to form a TU-3 encoded signal.

[0247] Example 3: Mapping and demapping methods for VC-4 service code streams

[0248] 3.1 Mapping of VC-4 Service Streams

[0249] S301: Decode the AU-4 coded signal and parse and extract the VC-4 service code stream.

[0250] First, parse the AU-4 signal from the STM-N interface and further parse it into VC-4. AU-4 has a total of 2358 bytes, consisting of a 9-byte AU pointer and a 2349-byte VC-12 (9 rows and 261 columns). The frame formats of AU-4 and VC-4 are as follows: Figure 8 shown.

[0251] S302: Insert a preset overhead byte for indicating positioning mapping information into the VC-4 service data frame.

[0252] In this embodiment, the preset overhead bytes sequentially inserted before the VC-4 data frame header include, in addition to the frame header position indication byte X1, the alarm information byte X2, and the port identifier byte X3, 6 bytes of fixed insertion bytes. The default value of the fixed insertion bytes is 0. X1 is inserted before the frame header, X2 is inserted 261 bytes after X1, X3 is inserted 261 bytes after X2, and fixed insertion bytes are inserted every 261 bytes after X3, as shown in FIG. Figure 9 shown.

[0253] In this embodiment, the meanings of the frame header position indication byte X1, the alarm information byte X2, and the port identifier byte X3 are consistent with those in the first embodiment.

[0254] As a result, the total number of bytes of the service filling data frame obtained after inserting the preset overhead bytes is consistent with the total number of bytes of an AU-4 signal frame, totaling 2358 bytes. This processing is also to facilitate demapping and recovery of AU-4 data in the later stage.

[0255] S303 : Perform frame structure coding adjustment on the VC-3 service data frame filled with preset overhead bytes, so that the rate of the coded data signal composed of the adjusted coded data frame can adapt to the fgODUflex(p) payload bit rate.

[0256] First, according to the difference between the nominal bit rate of the VC-4 service data and the nominal bit rate of fgODUflex(p), the number of bytes required to fill the service filling data frame to adapt it to the nominal bit rate of fgODUflex(p) is calculated; then, Figure 9 The service filling data frame structure shown includes a VC-4 data frame in which one idle byte is inserted every M bytes and Y individual idle bytes are inserted at the end of the frame to adapt the service rate to fgODUflex(p).

[0257] M and Y are calculated as follows:

[0258] The nominal payload bit rate of fgODUflex(15) is 154.831452 Mbit / s, the frame period of a VC-4 is 125 μs, the nominal bit rate of a VC-4 is 150.336 Mbit / s, and the bit tolerance is ±20 pmm. The statistical parameters are as follows:

[0259] fgODUflex(15) data payload nominal bit rate R ODUflex =154.831452Mbit / s=154.831452×10 6 bit / s;

[0260] The maximum number of VC-4 data transmission paths N in fgODUflex(15) data VC =1;

[0261] Nominal bit rate of VC-4 data transmitted in fgODUflex(15) data

[0262] VC-4 data frame transmission period T frame =125μs=125×10-6 s;

[0263] Nominal bit rate R of VC-4 data frame VC =150.336Mbit / s;

[0264] The deviation tolerance value Tol of the transmission rate of VC-4 data ppm = ±20ppm = ±20×10 -6 ;

[0265] Number of bytes of payload of VC-4 data frame B payload =2349;

[0266] The total number of bytes of the service filling data frame B frame =2358;

[0267] The upper limit of the number of idle bytes that can be inserted in the service filling data frame is recorded as idle max ;

[0268] The number of bytes required to fill the service filling data frame to adapt to the fgODUflex(p) payload bit rate is recorded as B idle .

[0269] Since the nominal bit rate of VC-4 data transmitted in fgODUflex(15) data is R1=R ODUflex =154.831452Mbit / s;

[0270] Therefore, the estimated number of bytes transmitted in a single frame is

[0271] The positive and negative tolerance transmission rates of VC-4 data frames are:

[0272] R pos =R VC ·(1+Tol ppm )=150.336*(1+20 / 1000000)Mbit / s=150.33900672Mbit / s;

[0273] R neg =R VC ·(1-Tol ppm )=150.336*(1-20 / 1000000)Mbit / s=150.33299328Mbit / s;

[0274] Therefore, the number of bytes of the data frame after rate adaptation filling is B bytes Determined as:

[0275] The transmission rate of VC-4 data when transmitting 2419 bytes is: 2349 / 2419*154.831452=150.351004Mbit / s, which is greater than R pos =150.33900672Mbit / s;

[0276] The transmission rate of VC-4 data when transmitting 2420 bytes is: 2349 / 2420*154.831452=150.288876Mbit / s, which is less than R neg =150.33299328Mbit / s.

[0277] That is, the bytes transmitted in one frame period are 2419 or 2420 bytes, which meets the bit tolerance of ±20pmm. Therefore, the number of bytes B required to fill the service filling data frame to adapt it to the nominal bit rate of fgODUflex(15) is idle for:

[0278] B idle =B bytes -B frame =(2419 or 2420)-2358=61 or 62 bytes;

[0279] Then, M and Y are calculated as follows:

[0280]

[0281] Y=B idle -idle max =(61 or 62)-60=1 or 2;

[0282] That is, to adapt the service filling data frame to the fgODUflex (15) nominal bit rate, one idle byte needs to be inserted every M=39 bytes in the VC-4 data frame contained in the service filling data frame. 60 idle bytes can be inserted in the middle of the VC-4 data frame, and the number of bytes inserted at the end of the frame is Y. min =1 or Y max =2.

[0283] Right now:

[0284] <![CDATA[R ODUflex (kbit / s)]]> User Signal M <![CDATA[Y min ]]> <![CDATA[Y max ]]> 154831.452(p＝15) VC-4 39 1 2

[0285] S304: Map the adjusted coded data signal to fgOPUflex for transmission.

[0286] When transmitting VC-4 data, the rate-adapted data is directly filled into the fgOPUflex payload.

[0287] 3.2 Demapping of VC-4 Service Streams

[0288] S311. Obtain the fgOPUflex payload data signal from the received fgOPUflex data signal.

[0289] S312: Locate the synchronization frame header position from the fgOPUflex payload data signal, thereby determining the position of each coded data frame header.

[0290] The specific method of locating the synchronous frame header position is as follows: search for the frame header position indication byte X1 in the same time slot of the fgOPUflex payload. When a byte X1 is found, confirm that the bytes following the byte X1 meet the format requirements of the preset overhead bytes in the mapping encoding rule (that is, the next byte is X2), and the number of bytes between each two adjacent frame header position indication bytes X1 is equal to B bytes If the number of bytes is 2419 or 2420, it is determined that the correct position of the frame header position indication byte X1 is found.

[0291] S313: Locate the port identifier of the coded data frame according to the frame header position, thereby determining the port number of each coded data. This embodiment only includes one channel of coded data, so there is only one port number.

[0292] S314: Demap the encoded data frame according to the mapping coding rules, delete the inserted preset overhead bytes, parse out the VC-4 service data frame, and combine to obtain the VC-4 service code stream. If there are multiple channels, the multiple VC-4 service code stream data are restored according to the port identifier.

[0293] S315: Perform AU-4 encoding on the parsed VC-4 service code stream frame by frame to form an AU-4 encoded signal.

[0294] It can be seen from the mapping and demapping processes of the above different embodiments that the present invention adopts a new mapping method, which does not use TU-12 / TUG-3 / AU-4 format data to map to fgOPUflex, but directly maps the VC-n service into fgOPUflex, and inserts a preset overhead byte to indicate the synchronization frame header position in the mapped code stream, so as to facilitate finding the frame header position for later demapping synchronization, so that the multi-channel service signals do not require alignment during the mapping process, and there is no need to indicate the starting position of the service frame in the fgOPUflex overhead, thereby simplifying the mapping process and eliminating the need for Multiple TU-12 / TUG-3 signals are required to come from the same AU-4, making the application more flexible. At the same time, the inserted preset overhead bytes can be used to simultaneously record the port identifiers of multiple service signals, as well as other additional information such as the alarm indication information of TU-12 / TUG-3 / AU-4, thereby preserving the integrity of the alarm information in the TU-12 / TUG-3 / AU-4 data. In addition, the mapping process does not adopt the GMP mapping method, but adapts the data rate through frame structure coding adjustment during data encapsulation and packaging, further simplifying the rate adaptation process and optimizing the mapping and demapping processes.

[0295] In summary, the mapping and demapping method of multiple VC-n services to fgOPUflex of the present invention, while ensuring the integrity of the mapping / demapping functions of multiple VC-n services to fgOPUflex, simplifies the mapping / demapping process and improves the mapping execution efficiency, effectively solving the problem in the prior art that the mapping process of multiple VC-n services to fgOPUflex is cumbersome and affects the mapping execution efficiency.

[0296] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit the technical solutions. Those skilled in the art should understand that modifications or equivalent replacements of the technical solutions of the present invention that do not depart from the purpose and scope of the technical solutions of the present invention should be included in the scope of the claims of the present invention.

Claims

1. A method for mapping multiple VC-n services to fgOPUflex, characterized in that: The steps include: Decode the TU-n / AU-n coded signal and parse and extract the VC-n service code stream; the VC-n service code stream is composed of several VC-n service data frames; Inserting a preset overhead byte for indicating positioning mapping information into the VC-n service data frame; the preset overhead byte is used to indicate the frame header position and data feature information of the VC-n service data frame; Performing frame structure coding adjustment on the VC-n service data frame filled with preset overhead bytes so that the rate of the coded data signal composed of the adjusted coded data frame can be adapted to the fgODUflex(p) payload bit rate; The adjusted coded data signal is mapped to fgOPUflex for transmission.

2. The method for mapping multiple VC-n services to fgOPUflex according to claim 1, characterized in that: The specific method of decoding the TU-n / AU-n coded signal is: First, obtain the TU-n / AU-n coded signal in the tributary unit TU-n / administrative unit AU-n from the STM-N interface. For each TU-n / AU-n data frame, remove the unit pointer in the frame and extract the VC-n service data frame contained in the TU-n / AU-n data frame, thereby obtaining the VC-n service code stream.

3. The method for mapping multiple VC-n services to fgOPUflex according to claim 1, characterized in that: The preset overhead bytes for indicating the positioning mapping information include a frame header position indication byte X1, an alarm information byte X2, and a port identifier byte X3; The frame header position indication byte X1 is used to indicate the frame header position of the formed service filling data frame; The alarm information byte X2 is used to indicate the alarm information of the VC-n service data; The port identifier byte X3 is used to indicate the path number information corresponding to the VC-n service data contained in the formed service filling data frame.

4. The method for mapping multiple VC-n services to fgOPUflex according to claim 3, characterized in that: The specific method of inserting the preset overhead byte for indicating the positioning mapping information into the VC-n service data frame is: The preset overhead byte is inserted before the frame header of the VC-n service data to form a service filling data frame, and the frame header position indication byte X1 is used as the starting byte of the service filling data frame to indicate the frame header byte position of the service filling data frame.

5. The method for mapping multiple VC-n services to fgOPUflex according to claim 3, characterized in that: The specific method of performing frame structure coding adjustment on the VC-n service data frame filled with the preset overhead bytes is as follows: Based on the difference between the nominal bit rate of the VC-n service data and the nominal bit rate of the fgODUflex(p) payload, the number of bytes required to be filled in order to adapt the service filling data frame to the nominal bit rate of the fgODUflex(p) payload is calculated and determined. Then, a corresponding number of idle bytes are filled in the service filling data frame so that the rate of the coded data signal composed of the adjusted coded data frame after filling can be adapted to the fgODUflex(p) payload bit rate.

6. The method for mapping multiple VC-n services to fgOPUflex according to claim 5, characterized in that: The number of bytes B required to fill the service filling data frame to adapt it to the fgODUflex(p) payload bit rate idle Calculated as follows: B idle =B bytes -B frame ; Among them, B idle Indicates the number of bytes to be filled; B frame Indicates the total number of bytes of the service filling data frame; B bytes Indicates the number of bytes that need to be transmitted in one frame / multiframe time at the nominal bit rate of the fgODUflex(p) payload; The number of bytes that need to be transmitted per frame / multiframe time B bytes The value of is determined by the read and write address difference of the FIFO for reading and writing VC-n data frames / multiframes at that time: If the read and write address difference of the FIFO is greater than half of the FIFO depth, then B is taken. bytes =B min ; If the read and write address difference of the FIFO is less than or equal to half of the FIFO depth, then take B bytes =B max Among them, B min 、B max The value of is calculated as follows: Among them, B num Estimated number of bytes transmitted for a single frame per channel; Indicates rounding down; R ODUflex Indicates the payload nominal bit rate of fgODUflex(p) data; N VC Indicates the maximum number of VC-n data transmission paths when the P value in fgODUflex(p) data is minimum; R1 indicates the nominal bit rate of one VC-n data transmission path in fgODUflex(p) data; T frame Indicates the transmission period of VC-n data frame / multiframe; B payload Indicates the number of bytes in the payload of the VC-n data frame / multiframe; R pos and R neg are the positive tolerance transmission rate and negative tolerance transmission rate of the VC-n data frame respectively, and R pos =R VC ·(1+Tol ppm ), R neg =R VC ·(1-Tol ppm ), R VC is the nominal transmission rate of VC-n data, Tol ppm The deviation tolerance value of the transmission rate of VC-n data.

7. The method for mapping multiple VC-n services to fgOPUflex according to claim 6, characterized in that: The specific method of filling the idle bytes in the service filling data frame is: An idle byte is inserted every M bytes in the VC-n data frame included in the service filling data frame, and Y idle bytes are inserted at the end of the service filling data frame, and M and Y are calculated as follows: Among them, B frame Indicates the total number of bytes of the service filling data frame; Indicates rounding up; idle max Indicates the upper limit of the number of idle bytes that can be inserted into the service filling data frame, and has Indicates rounding down.

8. The method for mapping multiple VC-n services to fgOPUflex according to claim 1, characterized in that: The specific method of mapping the adjusted coded data signal to fgOPUflex for transmission is: The service filling data frame after rate adaptation is filled into the fgOPUflex payload in a byte-interleaved manner to form an fgOPUflex encoded signal for transmission.

9. A method for demapping multiple VC-n services to fgOPUflex, characterized in that: The steps include: Obtaining an fgOPUflex payload data signal from a received fgOPUflex data signal; Locating the synchronization frame header position from the fgOPUflex payload data signal, thereby determining the position of each encoded data frame header; Locate the port identifier of the coded data frame according to the frame header position, thereby determining the port number of each coded data; De-mapping the coded data frame according to the mapping coding rule, deleting the inserted preset overhead bytes, parsing out the VC-n service data frame therein, and obtaining the VC-n service code stream; The parsed VC-n service code stream is then TU-n / AU-n encoded frame by frame to form a TU-n / AU-n encoded signal.

10. The method for demapping multiple VC-n services to fgOPUflex according to claim 9, characterized in that: The preset overhead byte in the coded data frame is inserted at the frame header position, and the preset overhead byte includes the frame header position indication byte X1 and is located at the first byte in the coded data frame; The specific method of locating the synchronization frame header position from the coded data signal is: Search the frame header position indication byte X1 from the same time slot of the coded data signal, confirm that the bytes following the found frame header position indication byte X1 meet the format requirements of the preset overhead bytes in the mapping coding rule, and the number of bytes between each two adjacent frame header position indication bytes X1 is equal to B bytes If the number of byte X1 is found, it is determined that the correct frame header position indication byte X1 is found.

Images