Fault information transmission method, storage medium, electronic device and computer program product

Abstract

The embodiment of the invention provides a fault information transmission method, a storage medium, an electronic device and a computer program product. The method comprises the following steps: detecting a first data frame sent by a source node of a slice packet network; generating second fault information of the current node according to a detection result of the first data frame; and sending the second fault information to the target client equipment, so that the target client equipment determines a fault reason according to the received second fault information. Through the embodiment of the invention, the host node does not directly transmit the fault information to the client equipment of the receiving end, but generates the second fault information capable of identifying different fault causes according to the data frame detection result, so that the client equipment of the receiving end can determine the specific fault cause according to the received second fault information; therefore, the technical problem that the client device of the receiving end cannot acquire the specific reason causing the invalidation of the client service data in the related technology is solved.

Description

Technical Field

[0001] This application relates to the field of communications, and more specifically, to a fault information transmission method, storage medium, electronic device, and computer program product. Background Technology

[0002] The rapid increase in user network traffic has spurred the rapid development of communication network bandwidth, leading to continuous improvements in the interface bandwidth of communication equipment, currently reaching 100G. The Flexible Ethernet (FlexE) protocol standard defines a method for transmitting customer services at speeds of n (n is a positive integer) * 5G (in bits per second, hereinafter the same). The FlexE physical interface can efficiently carry customer services at speeds above 5G. To address the need to carry customer services at speeds below 5G, related technologies have developed a fine-grained frame structure, dividing a 5G-rate FlexE time slot into 480 sub-time slots, each with a bandwidth of 10M, capable of carrying customer services at 10M and above. Therefore, related technologies can use FlexE sub-time slots to transmit STM-1, E1, and other constant bit rate (CBR) services, and apply Slicing Packet Network (SPN) products to replace Synchronous Digital Hierarchy (SDH) products to achieve SDH service transmission.

[0003] In related technologies, if the destination SPN device cannot recover the original customer service data, it will send an all-"1" or all-"0" information stream to the receiving customer device to indicate that the customer service data is invalid. However, in practical applications, there are many reasons why customer service data may be invalid, such as failures between the sending customer device and the source SPN device, between the source SPN device and the destination SPN device, or between the destination SPN device and the receiving customer device. Therefore, the receiving customer device cannot obtain the specific reason for the invalid customer service data.

[0004] In conclusion, there is still no good solution to the above problems. Summary of the Invention

[0005] This application provides a fault information transmission method, storage medium, electronic device, and computer program product to at least solve the technical problem in the related art where the receiving end's customer equipment cannot obtain the specific reasons for invalid customer business data.

[0006] According to one embodiment of this application, a fault information transmission method is provided, applied to a destination node. The method includes: detecting a first data frame sent by a source node of a slice packet network, wherein the first data frame carries first fault information of the source node, and the first fault information indicates the status information of service data; generating second fault information of the current node based on the detection result of the first data frame; and sending the second fault information to a target client device so that the target client device can determine the cause of the fault based on the received second fault information.

[0007] According to another embodiment of this application, a fault information transmission method is also provided, applied to a target client equipment. The method includes: detecting second fault information sent by a destination node of a slice packet network, wherein the second fault information is generated by the destination node based on the detection result of a first data frame sent by a source node of the slice packet network, the first data frame carrying first fault information of the source node, the first fault information being the status information of service data received by the source node from the source client equipment; and determining the cause of the fault based on the detection result of the second fault information.

[0008] According to yet another embodiment of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein the computer program is executed by a processor to perform the steps in any of the above method embodiments.

[0009] According to yet another embodiment of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0010] According to yet another embodiment of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0011] In this embodiment, the destination node does not directly transmit fault information to the receiving client equipment. Instead, it generates second fault information that can identify different fault causes based on the data frame detection results. This allows the receiving client equipment to determine the specific fault cause based on the received second fault information, thereby solving the technical problem in related technologies where the receiving client equipment cannot obtain the specific cause that leads to invalid client business data. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of the structure of the data frame container used to carry STM-1 customer services in an embodiment of this application;

[0013] Figure 2 This is a schematic diagram of the network architecture of the fault information transmission method according to an embodiment of this application;

[0014] Figure 3 This is a hardware structure block diagram of a computer terminal for a fault information transmission method according to an embodiment of this application;

[0015] Figure 4 This is a flowchart illustrating the fault information transmission method for a destination node according to an embodiment of this application.

[0016] Figure 5 This is a flowchart illustrating a method for transmitting fault information of a target customer device according to an embodiment of this application.

[0017] Figure 6 This is a schematic diagram of the structure of STM-1 service data in one embodiment of this application;

[0018] Figure 7 This is a schematic diagram of the structure of the overhead region in a data frame used to carry STM-1 services in one embodiment of this application;

[0019] Figure 8 This is a schematic diagram (a) of the data structure of the second fault information in one embodiment of this application;

[0020] Figure 9 This is a schematic diagram (II) of the data structure for the second fault information in one embodiment of this application;

[0021] Figure 10 This is a schematic diagram (III) of the data structure for the second fault information in one embodiment of this application. Detailed Implementation

[0022] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.

[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0024] In related technologies, communication equipment interface bandwidth speeds have reached 100G, and 100G optical modules are already widely used in the market. Although 400G optical modules have been developed, their high price—exceeding the cost of four 100G optical modules—affects their commercial economic value. To transmit 400G services over 100G optical modules, the international standards organization defined the FlexE protocol. The FlexE protocol combines multiple 100G optical modules to form a high-speed transmission channel. Combining four 100G optical modules into a 400G transmission channel via FlexE is equivalent to the transmission speed of a single 400G optical module, thus solving the 400G service transmission requirement without increasing costs. For example, for a physical layer rate of 100G, the Ethernet protocol defines that 100G data packets must be 64 / 66 encoded before transmission. This involves adding 2 bits before a 64-bit data block to expand it into a 66-bit block. These 2 bits serve as the start marker for the 66-bit block, which is then transmitted from the optical port as a 66-bit block. Upon reception, the optical port identifies the 66-bit block from the received data stream, recovers the original 64-bit data from the 66-bit block, and finally reassembles the data packet. The FlexE protocol, located below the 64-bit to 66-bit block conversion layer, sorts and plans the 66-bit data blocks before transmission. For 100G services, every 20 66-bit data blocks are divided into a block group, with each group containing 20 blocks, representing 20 time slots, each time slot representing a 5G (bit / s) bandwidth service speed. During the transmission of data blocks, overhead blocks are periodically inserted. The interval between two adjacent overhead blocks is 1023 * 20 data blocks. That is, when transmitting 66-bit data blocks, a FlexE overhead block is inserted after every 1023 data block groups (1023 * 20 data blocks). Then, data blocks are transmitted, and after the second 1023 * 20 data blocks are transmitted, an overhead block is inserted again, and so on. For a physical line speed of 100G (bit / s), the FlexE protocol divides the physical port into 20 time slots, so the bandwidth corresponding to each time slot is 5G. The basic characteristics of the FlexE protocol are few time slots and large granularity. The number of time slots and the bandwidth defined by it can meet the transmission needs of customer services such as routers and optical transport networks (OTN). However, in the field of packet transport networks (PTN), there are many customer services and the bandwidth of each service is small. That is, it has the characteristics of many time slots and small granularity of bandwidth of a single time slot, which makes the FlexE protocol unable to meet the application scenarios of PTN services.

[0025] To address the needs of customer services operating at speeds lower than 5G, communication network operators have defined fine-grained slicing technical requirements for Sliced ​​Packet Networks (SPNs) and proposed a fine-grained frame structure. This structure consists of S-blocks, D-blocks, and T-blocks. These blocks are Ethernet-defined coded blocks, following the 64 / 66 encoding rules of the Ethernet 802.3 protocol. Each block consists of 66 bits. The first two bits are the synchronization header, with "01" indicating a D-block. The following eight bytes (64 bits) contain eight bytes of data. The synchronization header bit "10" indicates a control block. The first byte indicates the type of control block, followed by seven bytes of control block content, determined by the block type. Control blocks include S-blocks, T-blocks, O-blocks, and idle blocks (also called IDLE blocks or I-blocks). In Ethernet, the first byte of an S-block is 0x78, indicating that the control block type is an S-block. An S-block is the first block in a data packet block stream. A T-block is the last block in a data packet block stream, serving as the end-of-message block. T-blocks can function as end-of-message blocks or carry client bytes (located in the last 7 bytes of the block). The Ethernet standard classifies T-blocks into eight types: T0, T1, T2, T3, T4, T5, T6, and T7. The T0 block (first byte 0x87) does not carry client information; the T1 block (first byte 0x99) carries one byte of client information; the T2 block (first byte 0x99) carries two bytes of client information; and so on, with the T7 block (first byte 0xFF) carrying seven bytes of client information. An I-block is an idle block or error indicator block, with a control word content of 0x1E. The O code block is the maintenance and management code block, and its control word content is 0x4B.

[0026] Currently, different fine-grained frame (also known as fine-grained data frame, small-grained data frame, or small-grained frame) formats have been established both domestically and internationally. The Chinese telecommunications industry standard defines a fine-grained frame structure consisting of one S-block, 195 D-blocks, and one T-block. The D-block within the fine-grained frame is divided into overhead byte information and 24 sub-time slots. Every 20 fine-grained frames form a multiframe, with 480 sub-time slots in one multiframe period. The International Telecommunication Union (ITU) has defined a fine-grained frame structure in its standard documents, consisting of one S-block, 990 D-blocks, and one T-block. The D-block within a fine-grained frame is divided into overhead byte information and 480 sub-time slots. 480 fine-grained frames form a multiframe, with each frame in the multiframe transmitting the overhead information for one time slot. All the overhead information for the 480 sub-time slots is transmitted through the 480 fine-grained frames in a single multiframe. Fine-grained frames are carried on 5G-speed time slots of the FlexE interface. Each fine-grained frame is divided into 480 sub-time slots, effectively dividing the transport pipeline of a single 5G-speed time slot into 480 sub-time slots. Each sub-time slot has a bandwidth of 10Mbps (slightly higher than 10Mbps). Therefore, one sub-time slot of a fine-grained frame can carry 10Mbps customer services, basically meeting the transport requirements of ordinary Ethernet services (currently, Ethernet service bandwidths are 10Mbps, 100Mbps, 1Gbps and above; services greater than 10Mbps use multiple sub-time slots). When a fine-grained sub-time slot carries a 10Mbps customer service, the 10Mbps customer service is first 64 / 66 encoded. After encoding, it is carried on a selection of sub-time slots, and the fine-grained frame is then mapped to the FlexE protocol time slots for transmission, reaching the remote destination device through the 5G-speed time slots of the FlexE protocol. SPN fine-grained slicing technology is required to support 10M speed services, but in some application scenarios, the equipment needs to replace Synchronous Digital Hierarchy (SDH) equipment and support various customer services in the SDH system.The SDH architecture includes various customer services such as STM-1, E1, and Virtual Container (VC). STM-1 is the basic synchronous transmission module in SDH, with a transmission rate of 155.52 Mbps. Higher-level rates include STM-4 (622.08 Mbps), STM-16 (2488.32 Mbps), STM-64 (9553.28 Mbps), and STM-256 (40 Gbps). E1 service is a digital signal transmission standard used in Europe and China, typically with a rate of 2.048 Mbps. VC service is an important data transmission method that allows data signals of different rates and formats to be encapsulated in a unified container for transmission. SDH defines different VC rate levels, such as VC-3 with a transmission rate of 155.52 Mbps and VC-4 with a transmission rate of 622.08 Mbps, to accommodate different bandwidth requirements.

[0027] Figure 1 This is a schematic diagram of the structure of the data frame container used to carry STM-1 customer services in an embodiment of this application, as shown below. Figure 1 As shown, the data frame container structure includes an overhead area, an adjustment area, and a fixed bearer service area.

[0028] In this embodiment, the data frame container consists of an S-block, n D-blocks, and a T-block, where n is a natural number equal to 0, 1, 2, 3... The S-block, D-block, and T-block are 66-bit blocks as defined by the Ethernet 802.3 international standard. The first block in this data frame container is an S-block, the middle blocks are n D-blocks, and the last block is a T-block. The S-block is the data frame header marker block, the D-blocks are data blocks that can carry client service data (each D-block can carry 8 bytes of client service data), and the T-block is the data frame end marker block. The 8 bytes in the D-block and the subsequent bytes in the T-block can all carry client service data.

[0029] In this embodiment, the data frames carrying E1 services and STM-1 services have similar structures, the only difference being the data in the D code block. The data frame structure carrying STM-1 services can use T7 as the T code block, but other types of T code blocks can also be used in specific applications. The data frames carrying VC services are divided into overhead areas, bearer adjustment areas, and fixed bearer areas, etc.

[0030] The method embodiments in this application can be applied to service scenarios that use FlexE sub-time slots to transmit STM-1, E1 and other constant bit rate (CBR) services, and SPN network equipment can be used to replace SDH network equipment to realize the transmission of SDH services in SPN network.

[0031] Figure 2 This is a network architecture diagram of a fault information transmission method according to an embodiment of this application, used to carry SDH customer services through an SPN network. The network architecture includes: customer equipment and SPN network.

[0032] In this embodiment, the Customer Edge (CE) includes a source customer equipment and a target customer equipment, used to send or receive SDH-based services. The SPN network includes source nodes, intermediate nodes, and destination nodes. The source node is a node in the SPN network connected to the source customer equipment, used to receive service data from the source customer equipment and load the received service data into a data frame container. The data frame container is transmitted via sub-time slots of the SPN node. The bearer is transmitted through sub-time slots on the SPN node, sent to intermediate nodes, and finally forwarded to the destination node. The destination node is a node in the SPN network connected to the target customer equipment, used to extract data frames from sub-time slots, extract and recover the original service data from the data frame container, and then send it to the target customer equipment.

[0033] The methods and embodiments provided in this application can run on client equipment in the above-described network architecture or on SPN nodes in the SPN network. For example, client equipment includes, but is not limited to, mobile terminals, computer terminals, or similar computing devices. Taking running on a computer terminal as an example... Figure 3 This is a hardware structure block diagram of a computer terminal for a fault information transmission method according to an embodiment of this application, such as... Figure 3 As shown, a hardware board may include one or more ( Figure 3 Only one is shown in the diagram. A processor 12 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 14 for storing data are also shown. The computer terminal may further include a transmission device 16 for communication functions and an input / output device 18. Those skilled in the art will understand that... Figure 3 The structure shown is for illustrative purposes only and does not limit the structure of the computer terminal described above. For example, the computer terminal may also include components that are more complex than those described above. Figure 3 The more or fewer components shown, or having the same Figure 3 The different configurations shown.

[0034] The memory 14 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the fault information transmission method in this embodiment. The processor 12 executes various functional applications and the fault information transmission method by running the computer program stored in the memory 14, thus implementing the aforementioned method. The memory 14 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 14 may further include memory remotely located relative to the processor 12, and these remote memories can be connected to a computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0035] The transmission device 16 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a telecommunications provider. In one example, the transmission device 16 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 16 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0036] One embodiment of this application provides a method for transmitting fault information of a destination node operating in an SPN network. Figure 4 This is a flowchart illustrating the fault information transmission method for the destination node according to an embodiment of this application, as shown below. Figure 4 As shown, the process includes the following steps:

[0037] Step S402: Detect the first data frame sent by the source node of the slice packet network;

[0038] Step S404: Generate the second fault information of the current node based on the detection result of the first data frame;

[0039] Step S406: Send the second fault information to the target customer equipment so that the target customer equipment can determine the cause of the fault based on the received second fault information.

[0040] In this embodiment, the source node in the SPN network receives service data from the source client equipment, transmits the service data to the destination node through the SPN network, and then the destination node sends the service data to the target client equipment. If an abnormality occurs during the service data transmission process, the source SPN node or the destination SPN node in the SPN network will generate corresponding fault information.

[0041] In this embodiment, the first data frame carries the first fault information of the source node, and the first fault information indicates the status information of the service data.

[0042] In this embodiment, the status information includes whether the service data is invalid. The first fault information is generated by the source node based on the service data received from the source client equipment. If the service data is abnormal, the source node will generate the corresponding first fault information (such as indicating that the service data is invalid) based on the reception status of the service data, and carry the first fault information in the data frame container to obtain the first data frame. If the service data is not abnormal, the source node will generate the corresponding first fault information (such as indicating that the service data is not invalid) based on the reception status of the service data, and load the first fault information and the service data into the data frame container to obtain the first data frame.

[0043] In this embodiment, the destination node can identify the first fault information generated at the source node. Simultaneously, the destination node can also identify whether a fault has occurred between the source and destination nodes, and then generate second fault information based on the detection results of the first data frame. Based on this, those skilled in the art will understand that the second fault information, compared to the first fault information, adds an indication of SPN network faults.

[0044] In this embodiment, the destination node does not directly transmit the fault information to the receiving client device. Instead, it generates second fault information that can identify different fault causes based on the data frame detection results. This allows the receiving client device to determine the specific fault cause based on the received second fault information, thereby solving the technical problem in the related art where the receiving client device cannot obtain the specific cause that leads to invalid client business data.

[0045] In some embodiments, the first data frame is used to carry SDH service data, including but not limited to E1 service, STM-1 service, and VC service.

[0046] In some embodiments, the structure of the first data frame includes an overhead region, an adjustment region, and a fixed bearer service region, wherein the overhead region is used to carry overhead information (including first fault information), and the fixed bearer service region is used to carry service data. However, this application is not limited thereto.

[0047] In some embodiments, the second fault information in step S406 includes:

[0048] A preset source node fault information stream is used to indicate that there is a fault between the source client equipment and the source node;

[0049] A preset network fault information stream is used to indicate that there is a fault between the source node and the current node.

[0050] In this embodiment, the cause of the fault may include a fault between the source client device and the source node, or a fault between the source node and the current node (i.e., the destination node). The information flow structure of the second fault information has unique characteristics different from the information flow of the service data. Furthermore, the cause of the fault may also include a fault between the destination node and the target client device. If the target client device neither receives service data nor receives the second fault information, it can be determined that the fault occurs between the destination node and the target client device.

[0051] In some embodiments, the first fault information includes a Container Idle Indication (CEI) field and a Customer Signal Failure (CSF) field, wherein the Container Idle Indication field and the Customer Signal Failure field are located in the overhead region of the first data frame.

[0052] In this embodiment, the failure status of service data can be further divided into signal failure or container idleness, which are indicated by the CEI field and the CSF field, respectively.

[0053] In some embodiments, generating the second fault information of the current node based on the detection result of the first data frame in step S404 may include any of the following steps:

[0054] Step S404A: When the first data frame is detected and the container empty indication field or the customer signal failure field in the first data frame is a preset valid value, the preset source node fault information stream is generated.

[0055] Step S404B: If the first data frame is not detected, generate the preset network fault information stream.

[0056] In some embodiments, the preset source node fault information includes: a preset source node idle information stream, used to indicate that the service data received by the source node from the source client equipment is in an idle state; or, a preset source node signal failure information stream, used to indicate that the service data received by the source node from the source client equipment is in a failure state.

[0057] In some embodiments, step S404A, upon detecting the first data frame and finding that the container empty indication field or the customer signal failure field in the first data frame is a preset valid value, generates the preset source node fault information stream, and may further include any of the following steps:

[0058] S404A-A, when the first data frame is detected and the container empty indication field is the preset valid value, the preset source node empty information stream is generated;

[0059] S404A-B, when the first data frame is detected and the customer signal failure field is the preset valid value, the preset source node signal failure information stream is generated.

[0060] For example, the preset valid value can be set to 1. If CEI=1 is detected, the generated second fault information is the preset source node no-load information stream. If CSF=1 is detected, the generated second fault information is the preset source node signal failure information stream.

[0061] In some embodiments, the data structure of the second fault information includes at least one of the following:

[0062] Pseudo-Random Binary Sequence (PRBS);

[0063] The first information stream is a first preset number of alternating 0 and 1 bit streams;

[0064] The combination of the first information stream and the second information stream, wherein the second information stream is a second preset number of all-zero bit streams or all-one bit streams;

[0065] A business data frame, wherein the business data frame is used to carry the business data;

[0066] Bitstream in a special custom format.

[0067] In this embodiment, the structure of the specially customized bitstream differs from the data structure of the business datastream.

[0068] In this embodiment, PRBS is a special type of information stream sequence. On one hand, the content of the stream sequence is a predetermined, regularly occurring, and repetitive information stream generated according to a fixed formula. On the other hand, it also possesses certain random characteristics (i.e., statistical characteristics) of a random sequence; this type of information stream sequence is called a pseudo-random sequence. There are many types of PRBS, each generated by a corresponding PRBS algorithm formula. The highest bit of the PRBS formula represents the interval between repetitions of the information stream. For example, if the highest bit of the PRBS-15 polynomial is 15, it means that the length of each specific content sequence is 2^15 - 1 bits, meaning that the previous information bits are repeated every 2^15 - 1 information bits. Commonly used PRBS algorithm polynomials include, but are not limited to, PRBS-5, PRBS-6, PRBS-7, PRBS-8, PRBS-9, PRBS-10, PRBS-11, PRBS-12, PRBS-13, PRBS-14, PRBS-15, PRBS-17, PRBS-21, PRBS-23, and PRBS-25.

[0069] In some embodiments, any three different types of pseudo-random binary sequences can be set to correspond to different types of second fault information. For example, PRBS-11 can be used as a preset source node idle information stream, PRBS-15 can be used as a preset source node signal failure information stream, and PRBS-23 can be used as a preset network fault information stream.

[0070] In some embodiments, if the data structure of the second fault information is a combination of the first information stream and the second information stream, then the first information stream and the second information stream appear alternately. By adjusting the lengths of the first information stream and the second information stream in the combination, i.e., setting a first preset number M and a second preset number N, different bit streams can be obtained, where M and N are positive integers. For example, the preset source node idle information stream can be set to the information stream combination corresponding to M=16 and N=8, the preset source node signal failure information stream can be set to the information stream combination corresponding to M=24 and N=12, and the preset network fault information stream can be set to the information stream combination corresponding to M=8 and N=12.

[0071] In some embodiments, the data structures of different types of second fault information can be arbitrarily combined. For example, a pseudo-random binary sequence can be used as a preset source node idle information stream, a first information stream can be used as a source node signal failure information stream, and a bit stream with a special custom format can be used as a preset network fault information stream.

[0072] In some embodiments, for situations where some customer equipment can only recognize normal service data formats, it is necessary to set the data structure of the second fault information to a service data frame. For example, some SDH equipment can only recognize devices in the STM-1 frame format, so the second fault information needs to have the structural characteristics of an STM-1 frame. The service data frame may carry a specific field indicating the device name of the source node, and the value of this specific field indicates the cause of the fault. The value of this specific field is set based on the detection result of the first data frame, and the value of the specific field corresponds one-to-one with the aforementioned fault cause.

[0073] In an exemplary embodiment, if the service data frame is an STM-1 service data frame, then this specific field can be the J0 byte. The J0 byte in the STM-1 frame is used to transmit channel tracing information. The client equipment can identify the J0 byte. Typically, the J0 byte is a series of strings (generally, the byte content of the J0 bytes in 16 frames is different, combined to form 16 byte strings, and the byte strings represent device name sequence information) used to represent the name information of the source device. For example, the J0 information can be set to a fixed value "77" (hexadecimal) to represent the Container Idle Indicator (CEI); a fixed value "88" (hexadecimal) to represent the Customer Signal Failure (CSF); and a fixed value "99" (hexadecimal) to represent a fault within the SPN network. However, this application is not limited to this.

[0074] Through the embodiments of this application, since the receiving client equipment can determine the corresponding fault cause that leads to the invalidity of the client business data according to the different data structures of the received fault information, the technical problem that the receiving client equipment cannot obtain the specific cause that leads to the invalidity of the client business data in the related art is solved, and the effect of the receiving client equipment being able to determine the corresponding specific fault cause and the location of the fault cause when receiving the fault information is achieved.

[0075] One embodiment of this application provides a method for transmitting fault information operating on a target customer device. Figure 5 This is a flowchart illustrating a fault information transmission method for a target customer device according to an embodiment of this application, such as... Figure 5 As shown, the process includes the following steps:

[0076] Step S502: Detect the second fault information sent by the destination node of the slice packet network;

[0077] Step S504: Determine the cause of the fault based on the detection results of the second fault information.

[0078] In this embodiment, the second fault information is generated by the destination node based on the detection result of the first data frame sent by the source node of the slice packet network. The first data frame carries the first fault information of the source node, which is the status information of the service data received by the source node from the source client equipment.

[0079] In this embodiment, the source node in the SPN network receives service data from the source client equipment, transmits the service data to the destination node through the SPN network, and then the destination node sends the service data to the target client equipment. If an abnormality occurs during the service data transmission process, the source SPN node or the destination SPN node in the SPN network will generate corresponding fault information.

[0080] In this embodiment, the status information of the service data includes whether the service data is invalid. The first fault information is generated by the source node based on the service data received from the source client equipment. If the service data is abnormal, the source node will generate the corresponding first fault information (such as indicating that the service data is invalid) based on the reception status of the service data, and carry the first fault information in the data frame container to obtain the first data frame. If the service data is not abnormal, the source node will generate the corresponding first fault information (such as indicating that the service data is not invalid) based on the reception status of the service data, and load the first fault information and the service data into the data frame container to obtain the first data frame.

[0081] In this embodiment, the destination node can identify the first fault information generated at the source node. Simultaneously, the destination node can also identify whether a fault has occurred between the source and destination nodes, and then generate second fault information based on the detection results of the first data frame. Those skilled in the art will understand that the second fault information, compared to the first fault information, adds an indication of the SPN network fault. Based on this, the target client equipment can achieve the technical effect of identifying the specific cause of the fault based on the second fault information received from the destination node.

[0082] In this embodiment, the destination node does not directly transmit the fault information to the receiving client device. Instead, it generates second fault information that can identify different fault causes based on the data frame detection results. This allows the target client device at the receiving end to determine the specific fault cause based on the detection results of the second fault information, thereby solving the technical problem in the related art where the receiving client device cannot obtain the specific cause that leads to invalid client business data.

[0083] In some embodiments, the first data frame is used to carry SDH service data, including but not limited to E1 service, STM-1 service, and VC service.

[0084] In some embodiments, the structure of the first data frame includes an overhead region, an adjustment region, and a fixed bearer service region, wherein the overhead region is used to carry overhead information (including first fault information), and the fixed bearer service region is used to carry service data. However, this application is not limited thereto.

[0085] In some embodiments, step S504, which determines the cause of the fault based on the detection result of the second fault information, includes any of the following steps:

[0086] Step S5042: If the second fault information is detected to be a preset source node fault information stream, determine that the cause of the fault is a fault between the source client equipment and the source node.

[0087] Step S5044: If the second fault information is detected to be a preset network fault information stream, determine that the cause of the fault is a fault between the source node and the destination node;

[0088] Step S5046: If the second fault information and the first data frame are not detected, determine that the cause of the fault is a fault between the destination node and the current device.

[0089] In this embodiment, the causes of the fault can be roughly divided into the following three types: there is a fault between the source client device and the source node, there is a fault between the source node and the destination node (i.e., the SPN network), and there is a fault between the destination node and the current device (i.e., the target client device).

[0090] In some embodiments, the first fault information may include a Container Idle Indication (CEI) field and a Client Signal Failure (CSF) field, wherein the CEI field and the CSF field are located in the overhead region of the first data frame. In this case, the preset source node fault information stream may include a preset source node idle information stream and a preset source node signal failure information stream. Correspondingly, the fault cause can be further subdivided into signal failure or data frame idleness.

[0091] In some embodiments, the data structure of the second fault information includes at least one of the following:

[0092] Pseudo-Random Binary Sequence (PRBS);

[0093] The first information stream is a first preset number of alternating 0 and 1 bit streams;

[0094] The combination of the first information stream and the second information stream, wherein the second information stream is a second preset number of all-zero bit streams or all-one bit streams;

[0095] A business data frame, wherein the business data frame is used to carry the business data;

[0096] Bitstream in a special custom format.

[0097] In this embodiment, different types of second fault information can adopt one or more data structures. The customer equipment can identify the above data structures and distinguish them from normal business data, thereby determining the cause of the fault based on the detection results of the second fault information.

[0098] In some embodiments, for situations where some customer equipment can only recognize normal service data formats, it is necessary to set the data structure of the second fault information to a service data frame. For example, some SDH equipment can only recognize STM-1 frame formats, so it is necessary to set the second fault information to have the structural characteristics of an STM-1 frame.

[0099] Through the embodiments of this application, since the receiving client equipment can determine the corresponding fault cause that leads to the invalidity of the client business data based on the information stream content of the received second fault information, the technical problem in the related art that the receiving client equipment cannot obtain the specific cause that leads to the invalidity of the client business data is solved, and the effect of the receiving client equipment being able to determine the corresponding specific fault cause and the location of the fault cause when receiving the fault information is achieved.

[0100] Figure 6 This is a schematic diagram of the structure of STM-1 service data in one embodiment of this application, as shown below. Figure 6 As shown, the STM-1 service data contains 9 rows and 270 columns of bytes. The first 9 rows and 9 columns are the overhead fields, and the remaining area is the content fields. In the overhead fields, the first row and first 6 columns contain 3 A1 frame header definition bytes and 3 A2 frame header definition bytes. The first row and 7th column is the J0 byte, and the first row and first 9 columns are the AU4 pointer value.

[0101] In this embodiment, A1 contains the hexadecimal value F6, and A2 contains the hexadecimal value 28. The frame header bytes A1, A1, A1, A2, A2, A2 are used to determine the start position of the STM-1 frame. When bytes A1, A1, A1, A2, A2, A2 are detected, if bytes A1, A1, A1, A2, A2, A2 are repeatedly detected every 9*270 bytes, then the STM-1 information content is successfully framed, confirming that the received information is STM-1 client information. If the source node device cannot periodically (at 9*270 byte intervals) detect bytes A1, A1, A1, A2, A2, A2, then the STM-1 framing fails, confirming that the currently received information is not STM-1 client information.

[0102] In this embodiment, since the content field in the STM-1 frame is the result of scrambling, it will not contain long strings of 1s or 0s. Similarly, the overhead field in the STM-1 frame will not contain long strings of 1s or 0s. Therefore, normally transmitted STM-1 frames will not contain long strings of 1s or 0s, let alone strings entirely of 1s or 0s. After determining the characteristics of the customer service content, a preset information stream different from the customer service content characteristics can be designed as the second fault information.

[0103] In an exemplary embodiment, three different specific information flows can be designed to represent different fault causes. If the destination node (the last SPN device) in the SPN network detects that the Container Idle Indicator (CEI) is set to 1 or the Customer Signal Failure (CSF) is set to 1, it sends the corresponding first or second specific information flow. If the last SPN device cannot detect the service data frame, it sends the corresponding third specific information flow. When the target customer device cannot detect customer service information, it can determine the fault location and cause based on the characteristics of the received information flow. If the information flow is one of the three pre-defined specific information flows, the fault location and cause can be determined. Furthermore, if the target customer device neither detects these specific information flows nor detects customer service information, it can be inferred that there is a problem with the information flow transmission, i.e., the fault occurs between the SPN network destination node and the target customer device.

[0104] Figure 7 This is a schematic diagram of the structure of the overhead region in a data frame used to carry STM-1 services in one embodiment of this application, as shown below. Figure 7 As shown, the overhead area is 5 bytes long and includes the following overhead fields:

[0105] Container Serial Number (SN): 6 bits in length, used to identify the order in which containers are sent. The SN starts counting from 0, increments by 1 for each container sent, and restarts counting from 0 after reaching 63.

[0106] Container Payload Type (Type): 4 bits long, indicating the type of customer service carried by the container. When the container carries E1 services, Type = 0001. When the container carries STM-1 services, Type = 0010. Other values ​​are reserved.

[0107] Container Empty Load Indicator (CEI): 1 bit long, used to indicate whether the container is loaded with customer business data. When the container is loaded with customer business data, CEI = 0; when CEI = 1, the container payload is not loaded with customer business data (all bits are set to 1, including NJO).

[0108] Customer Signal Failure (CSF): 1 bit long, used to indicate whether the customer-side port status of a customer service is normal. When a container loads a customer service, CSF=0 indicates that the customer-side port status is normal; when CSF=1, the customer-side port status is failed, and all container payloads are set to 1, including NJO.

[0109] Timestamp: 8 bits in length, used to transmit clock frequency information for customer services.

[0110] Negative Adjustment Indicator (NJI): When a container loads STM-1 services, NJI#1 indicates whether the NJO area of ​​the STM-1 service is loaded with STM-1 service data; when NJI#1 = 0, the NJO area of ​​the STM-1 service is loaded with STM-1 service data; when NJI#1 = 1, the NJO area of ​​the STM-1 service is not loaded with STM-1 service data (default is 0); NJI#2, NJI#3, and NJI#4 are reserved fields and are defaulted to 0. When carrying 4 E1 services, NJI#1, NJI#2, NJI#3, and NJI#4 are used for the NJO carrying indication of the 4 E1 services respectively.

[0111] Cyclic Redundancy Check (CRC7): Performs error checking on the bit values ​​[0:32] in the overhead field. The CRC7 polynomial is: x7 + x5 + x4 + x2 + x + 1, with an initial value of 0. The CRC7 result is represented as [x6: x0], where the most significant bit (x6) is sent first.

[0112] Reserved (RES): 9 bits in length, used for future overhead function expansion, defaults to 0.

[0113] In this embodiment, a preset fault information stream can be generated by detecting the data frame and the CEI and CSF of the overhead region in the data frame, thereby determining the cause of the fault.

[0114] In some embodiments, a second fault information with a simpler data structure can be set for specific application scenarios to facilitate detection. For example, it can be an information stream that alternates between 0 and 1.

[0115] Figure 8 This is a schematic diagram (a) of the data structure of the second fault information in one embodiment of this application, as shown below. Figure 8 As shown, the data structure of the second fault information can be a first information stream, that is, a first preset number of alternating 0 and 1 bit streams. This application does not limit the length of the bit stream.

[0116] In one exemplary embodiment, the first information stream may be set as n bits of alternating 0s and 1s, where n is a positive integer (n = 1, 2, 3...).

[0117] Figure 9 This is a schematic diagram (II) of the data structure for the second fault information in one embodiment of this application, as shown below. Figure 9 As shown, the data structure of the second fault information can be a combination of the first information stream and the second information stream. That is, a combination of a first preset number of alternating 0 and 1 bit streams and a second preset number of all 1 or all 0 bits.

[0118] In this embodiment, the second fault information is represented by m bits of all 1s and n bits of alternating 0s and 1s. Here, m and n are positive integers, and all bits of 1s can also be replaced with all bits of 0s.

[0119] In some embodiments, different preset information streams can be formed by setting different m and n, thereby indicating different fault causes. For example, the preset source node idle information stream can be set as a combination of m=16 and n=8, that is, containing 16 all 0 / all 1 bits and 8 0 / 1 alternating bits; the preset source node signal failure information stream can be set as a combination of m=24 and n=12, that is, containing 24 all 0 / all 1 bits and 12 0 / 1 alternating bits; the preset network fault information stream can be set as a combination of m=24 and n=16, that is, containing 24 all 0 / all 1 bits and 16 0 / 1 alternating bits.

[0120] In some embodiments, the target client device can determine the cause of the fault by detecting the received information stream.

[0121] Figure 10 This is a schematic diagram (iii) of the data structure for the second fault information in one embodiment of this application, as shown below. Figure 10 As shown, the data structure of the second fault information can be set as the structure of a service data frame. The second fault information can be indicated by specific fields in the service data frame, and different faults can be represented by the values ​​of the specific fields.

[0122] In this embodiment, taking STM-1 service as an example, the STM-1 data frame contains a total of 9*270 bytes. The first row and first 6 columns A1, A1, A1, A2, A2, A2 bytes are the location information of STM-1 service data, and the content of the A1 position byte is f6 (hexadecimal) and the content of the A2 position byte is 28 (hexadecimal). The content of the J0 byte in the 7th column of the first row is used to indicate the device name of the source node. The content of the J0 byte can be set according to the detection result of the service data frame. Usually, the J0 byte is a series of strings (generally, the content of the J0 bytes in 16 frames is different, and they are combined to form 16 byte strings, which represent the device name of the source node). The first 9 columns of the 4th row are the AU4 pointer value. The position of the AU4 pointer value can be fixed at ff, indicating the AU pointer AU-ais alarm information.

[0123] In this embodiment, apart from the special fields mentioned above, other positions marked with "*" can be information interleaved with 0 and 1 bits. The bit content is continuously reversed to transmit clock information. For example, "*" can be a byte value of 55 or aa (hexadecimal). The hexadecimal value of 55 converted to binary is "01010101", and the hexadecimal value of aa converted to binary is "10101010".

[0124] In this embodiment, after receiving the aforementioned data frame, the target client equipment can perform frame determination processing according to the STM-1 frame information, confirming it as an STM-1 frame. However, the pointer value of AU4 is "ff", indicating an STM-1 AU-ais alarm message, and the AU4 value is invalid. The J0 value is also not the expected client equipment number content, but is fixed as a constant value. For example, a constant value of "77" (hexadecimal) indicates that the container no-load indicator CEI = 1; a constant value of "88" (hexadecimal) indicates that the client signal failure CSF = 1; and a constant value of "99" (hexadecimal) indicates a fault within the SPN network system. However, this application is not limited to this.

[0125] In this embodiment, a special custom bitstream format can be obtained according to the above rules:

[0126] {f6, f6, f6, 28, 28, 28, J0, (263+2*270) 55s, 9 ffs, (261+5*270) 55s}, or,

[0127] {f6, f6, f6, 28, 28, 28, J0, (263+2*270) aa, 9 ff, (261+5*270) aa}.

[0128] In this embodiment, different values ​​of special fields can represent different faults. For example, the J0 byte can be set to a fixed value of "77" (hexadecimal) to indicate that the container is unloaded; the J0 byte can be set to a fixed value of "88" (hexadecimal) to indicate that the customer signal is malfunctioning; and the J0 byte can be set to a fixed value of "99" (hexadecimal) to indicate an internal fault in the SPN network system.

[0129] In an exemplary embodiment, the preset format of the source node's idle information stream is as follows:

[0130] {f6, f6, f6, 28, 28, 28, 77, (263+2*270) 01010101, 9 ff, (261+5*270) 01010101}, or.

[0131] {f6, f6, f6, 28, 28, 28, 77, (263+2*270) 10101010, 9 ff, (261+5*270) 10101010}.

[0132] In an exemplary embodiment, the preset source node signal failure information stream is formatted as follows:

[0133] {f6, f6, f6, 28, 28, 28, 88, (263+2*270) 01010101, 9 ff, (261+5*270) 01010101}, or.

[0134] {f6, f6, f6, 28, 28, 28, 88, (263+2*270) 10101010, 9 ff, (261+5*270) 10101010}.

[0135] In one exemplary embodiment, the format of the preset network fault information stream is as follows:

[0136] {f6, f6, f6, 28, 28, 28, 99, (263+2*270) 01010101, 9 ff, (261+5*270) 01010101}, or.

[0137] {f6, f6, f6, 28, 28, 28, 99, (263+2*270) 10101010, 9 ff, (261+5*270) 10101010}.

[0138] In this embodiment, the determination of the fault cause can be singular or multifaceted. Furthermore, the second fault information can be set as one preset information stream or multiple preset information streams. For example, in some application scenarios, when the target client device cannot receive the original client information, it only needs to determine whether there is a fault between the source client device and the source node or between the destination node and the current device. It is not necessary to distinguish in detail the specific reason for the fault between the source client device and the SPN source node. In this case, it is only necessary to set the source node fault information stream, without needing to subdivide it into the source node idle information stream and the source node signal failure information stream.

[0139] Through the embodiments of this application, since the receiving client equipment can determine the corresponding fault cause that leads to the invalidity of the client business data according to the different data structures of the received fault information, the technical problem that the receiving client equipment cannot obtain the specific cause that leads to the invalidity of the client business data in the related art is solved, and the effect of the receiving client equipment being able to determine the corresponding specific fault cause and the location of the fault cause when receiving the fault information is achieved.

[0140] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is executed by a processor to perform the steps in any of the above method embodiments.

[0141] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0142] Embodiments of this application also provide an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0143] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0144] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the methods described in various embodiments of this application.

[0145] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0146] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0147] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method for transmitting fault information, characterized in that, The method includes: The first data frame sent by the source node of the slice packet network is detected, wherein the first data frame carries the first fault information of the source node, and the first fault information indicates the status information of the service data. The second fault information of the current node is generated based on the detection result of the first data frame; The second fault information is sent to the target customer device so that the target customer device can determine the cause of the fault based on the received second fault information.

2. The method according to claim 1, characterized in that, The second fault information includes: A preset source node fault information stream is used to indicate that there is a fault between the source client equipment and the source node; A preset network fault information stream is used to indicate that there is a fault between the source node and the current node.

3. The method according to claim 2, characterized in that, The first fault information includes a container idle indication field and a customer signal failure field, wherein the container idle indication field and the customer signal failure field are located in the overhead area of ​​the first data frame.

4. The method according to claim 3, characterized in that, The second fault information of the current node is generated based on the detection result of the first data frame, including: If the first data frame is detected, and the container empty indication field or the customer signal failure field in the first data frame is a preset valid value, the preset source node fault information stream is generated; or, If the first data frame is not detected, the preset network fault information stream is generated.

5. The method according to claim 4, characterized in that, The preset source node fault information stream includes: A preset source node idle information stream is used to indicate that the service data received by the source node from the source client equipment is in an idle state; or, A preset source node signal failure information stream is used to indicate that the service data received by the source node from the source client equipment is in a failed state.

6. The method according to claim 5, characterized in that, Upon detecting the first data frame, and if the container empty indication field or the customer signal failure field in the first data frame is a preset valid value, the preset source node fault information stream is generated, including: If the first data frame is detected and the container empty indicator field is the preset valid value, the preset source node empty information stream is generated; or, Upon detecting the first data frame and finding that the customer signal failure field is the preset valid value, the preset source node signal failure information stream is generated.

7. The method according to claim 1, characterized in that, The data structure for the second fault information includes at least one of the following: Pseudo-random binary sequences; The first information stream is a first preset number of alternating 0 and 1 bit streams; The combination of the first information stream and the second information stream, wherein the second information stream is a second preset number of all-zero bit streams or all-one bit streams; A business data frame, wherein the business data frame is used to carry the business data; Bitstream in a special custom format.

8. The method according to claim 7, characterized in that, The service data frame carries a specific field for indicating the device name of the source node. The value of the specific field is set according to the detection result of the first data frame, and the value of the specific field corresponds one-to-one with the cause of the fault.

9. A method for transmitting fault information, characterized in that, The method includes: The second fault information sent by the destination node of the slice packet network is detected. The second fault information is generated by the destination node based on the detection result of the first data frame sent by the source node of the slice packet network. The first data frame carries the first fault information of the source node. The first fault information is the status information of the service data received by the source node from the source client equipment. The cause of the fault is determined based on the detection results of the second fault information.

10. The method according to claim 9, characterized in that, The cause of the fault is determined based on the detection results of the second fault information, including: If the second fault information is detected to be a preset source node fault information stream, the cause of the fault is determined to be a fault between the source client equipment and the source node; If the second fault information is detected to be a preset network fault information stream, the cause of the fault is determined to be a fault between the source node and the destination node; or... If neither the second fault information nor the first data frame is detected, the cause of the fault is determined to be a fault between the destination node and the current device.

11. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is executed by a processor to perform the method described in any one of claims 1 to 10.

12. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method as described in any one of claims 1 to 10.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method described in any one of claims 1 to 10.

Images