Data packet processing method, communication device, and communication system

Abstract

An embodiment of this application provides a data packet processing method, a communication device, and a communication system. The method includes the steps of receiving a data packet from a first device, checking the data packet based on a first CRC in the data packet, checking a packet header of the data packet based on a second CRC in the data packet, and discarding the data packet if the data packet check fails and the packet header check fails, or processing the data packet based on a type of the data packet if the data packet check fails but the packet header check succeeds. In this solution, the data packet carries a first CRC used to check the data packet and a second CRC used to check the packet header of the data packet. If the data packet check fails but the packet header check succeeds, it indicates that the packet header is correctly transmitted but the data is erroneously transmitted. In this case, the second device can process the data packet based on the type of the data packet instead of directly discarding the data packet. In this way, the amount of packet loss can be reduced, thereby improving data transmission efficiency and increasing system capacity.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to Chinese Patent Application No. 202111450373.5, entitled "Data Packet Processing Method, Communication Device, and Communication System," filed with the State Intellectual Property Administration of China on November 30, 2021, which is incorporated herein by reference in its entirety.

[0002] This application relates to the field of communication technology, and in particular to a data packet processing method, a communication device, and a communication system. [Background technology]

[0003] When devices communicate with each other, data needs to be received and transmitted between them, for example, a first device sending data to a second device, or a second device sending data to a first device.

[0004] In order to increase the data transmission rate, one service packet is generally divided into multiple data packets for transmission, and then the receiver assembles the received multiple data packets to obtain a complete service packet. Figure 1 is an example of a service packet diagram. One service packet is divided into n data packets and transmitted sequentially, where n is an integer greater than 1.

[0005] To ensure the accuracy of data reception, the receiver needs to check each data packet after receiving it. If the check of one data packet fails, it indicates that an error occurs in the data packet transmission process. Generally, the data packet that fails the check is directly discarded. Summary of the Invention

[0006] SUMMARY OF THE INVENTION The embodiments of this application provide a data packet processing method, a communication device, and a communication system for improving data transmission efficiency and increasing system capacity. [Means for solving the problem]

[0007] According to a first aspect, an embodiment of the present application provides a data packet processing method. The method can be performed by a second device or a module (e.g., a chip) used in the second device. The method includes the steps of receiving a data packet from a first device, the data packet including a packet header, data, a first Cyclic Redundancy Check (CRC), and a second CRC; checking the data packet based on the first CRC in the data packet; checking a packet header of the data packet based on the second CRC in the data packet; and processing the data packet based on a result of checking the data packet and / or a result of checking the packet header.

[0008] In possible embodiments, the step of processing the data packet based on the data packet check result and / or the packet header check result includes the step of skipping discarding the data packet if the data packet check is successful, or if the data packet check is successful and the packet header check is successful, the step of discarding the data packet if the data packet check fails and the packet header check fails, or the step of processing the data packet based on the type of the data packet if the data packet check fails but the packet header check is successful.

[0009] In this solution, a data packet carries a first CRC used to check the data packet and a second CRC used to check the packet header of the data packet. If the check of the data packet fails but the check of the packet header is successful, it indicates that the packet header is transmitted correctly but the data is transmitted incorrectly. In this case, the second device can process the data packet based on the type of the data packet instead of directly discarding the data packet. In this way, the amount of packet loss can be reduced, thereby improving data transmission efficiency and increasing system capacity.

[0010] In one possible embodiment, the step of checking the packet header of the data packet based on the second CRC in the data packet may be a step of checking the packet header of the data packet based on the second CRC in the data packet if the check of the data packet fails. If the check of the data packet fails, it indicates that an error occurs during the transmission of the data packet. In this way, the packet header of the data packet is further checked based on the second CRC in the data packet to determine whether an error occurs in the packet header. If the check of the data packet is successful, it indicates that no error occurs during the transmission of the data packet. In this case, it is not necessary to check the packet header of the data packet based on the second CRC in order to reduce the number of checks and improve the check speed.

[0011] In a possible embodiment, if the check of a data packet fails, the data packet is marked. In other words, if the check of a data packet fails, the data packet is not discarded. Instead, the data packet is marked. For example, the data packet may be marked using a special character or a specific bit (or bit position) to indicate that the data packet is a data packet that needs further determination. Subsequently, the packet header of the data packet is checked again using a second CRC, and based on the check result of the second CRC, it is determined whether to discard the data packet or not to discard the data packet. The marking may also indicate or prompt a module or device that performs subsequent processing on the data packet that there is an error in the data in the data packet.

[0012] In possible embodiments, the step of processing the data packet based on the type of the data packet may be a step of skipping discarding the data packet if the type of the data packet is user plane data, or a step of discarding the data packet if the type of the data packet is control plane data.

[0013] According to the above solution, if the type of data packet is user plane data, it means that the packet header of the data packet was transmitted correctly, but a transmission error occurred in the data within the data packet, and the data is user plane data. In this case, some errors occur in the transmitted user plane data, but because the packet header was transmitted correctly, the user plane data can be processed correctly. In addition, the error in the user plane data may only slightly affect the user experience and does not actually cause other more serious effects. Therefore, the second device does not need to discard the data packet. In this way, data transmission efficiency can be improved and system capacity can be increased. If the type of data packet is control plane data, it means that the packet header of the data packet was transmitted correctly, but a transmission error occurred in the data within the data packet, and the data is control plane data. In this case, the packet header was transmitted correctly, but an error occurred in the transmitted control plane data. Because the consequences caused by an error in the control plane data are relatively serious, the second device discards the data packet.

[0014] In a possible implementation, the type of the data packet is first determined based on the packet header before the data packet is processed based on the type of the data packet.

[0015] In a possible implementation, if the second device decides not to discard the data packet, it may further remove the second CRC from the data packet.

[0016] According to the aforementioned aspect, removing the second CRC from the data packet can simplify or reduce the complexity of subsequent processing procedures, reduce processing module modifications, and reduce the amount of data that needs to be transmitted within the second device or transmitted by the second device to other devices or modules.

[0017] In a possible implementation, the first CRC is located at the end of the data packet and the second CRC is located after the packet header of the data packet.

[0018] In possible embodiments, the first CRC is generated based on the packet header of the data packet, the data in the data packet, and the second CRC, or the first CRC is generated based on the packet header of the data packet and the data in the data packet.

[0019] In a possible embodiment, the second CRC is generated based on the packet header of the data packet.

[0020] In this solution, a second CRC is generated based on the packet header, so that the second CRC can be used to check the accuracy of the transmission of the packet header, thereby ensuring correct transmission of the packet header.

[0021] In a possible embodiment, the second CRC is generated based on the packet header of the data packet and a portion of the data within the data packet.

[0022] In this solution, the second CRC may be inserted at a fixed position after the start of the data packet. Therefore, the second CRC can divide the original data into a first data portion located before the second CRC and a second data portion located after the second CRC. In this case, the second CRC may be generated based on the packet header and the first data portion located before the second CRC. In one aspect, since the second CRC is generated based on the packet header and a portion of the data, the second CRC can be used to check the accuracy of the transmission of the packet header, thereby ensuring the correct transmission of the data packet. In another aspect, since the second CRC is inserted at a fixed position after the start of the data packet, the manner of generating and inserting the second CRC can be simplified, thereby improving the data packet generation speed.

[0023] In one possible implementation, the data packets are enhanced common public radio interface (eCPRI) data packets, and the data in the data packets includes eCPRI data.

[0024] According to a second aspect, an embodiment of the present application provides a data packet processing method, which can be performed by a first device or a module (e.g., a chip) used in the first device, and includes the steps of: generating a data packet, the data packet including a packet header, data, a first cyclic redundancy check (CRC), and a second CRC, the first CRC being used to check the data packet and the second CRC being used to check the packet header; and transmitting the data packet to a second device.

[0025] In this solution, the data packet carries a first CRC used to check the data packet and a second CRC used to check the packet header of the data packet. Thus, after receiving the data packet, the second device can determine how to process the data packet based on the first CRC and the second CRC.

[0026] In a possible implementation, a second CRC is generated based on the packet header.

[0027] In this solution, a second CRC is generated based on the packet header, so that the second CRC can be used to check the accuracy of the transmission of the packet header, thereby ensuring correct transmission of the packet header.

[0028] In a possible embodiment, the step of generating the second CRC based on the packet header may specifically be a step of generating the second CRC based on the packet header and a portion of the data.

[0029] In this solution, the second CRC may be inserted at a fixed position after the start of the data packet. Therefore, the second CRC can divide the original data into a first data portion located before the second CRC and a second data portion located after the second CRC. In this case, the second CRC may be generated based on the packet header and the first data portion located before the second CRC. In one aspect, since the second CRC is generated based on the packet header and a portion of the data, the second CRC can be used to check the accuracy of the transmission of the packet header, thereby ensuring correct transmission of the packet header. In another aspect, since the second CRC is inserted at a fixed position after the start of the data packet, the manner of generating and inserting the second CRC can be simplified, thereby improving the data packet generation speed.

[0030] In a possible implementation, a first CRC is generated based on the packet header and the data.

[0031] In a possible embodiment, the first CRC is generated based on the packet header, the data, and the second CRC.

[0032] In this solution, a second CRC is generated based on the packet header, so that the data, the second CRC, and the first CRC can be used to check the accuracy of the transmission of the data packet, thereby ensuring correct transmission of the packet header.

[0033] In a possible implementation, the first CRC is located at the end of the data packet and the second CRC is located after the packet header of the data packet.

[0034] In one possible implementation, the data packets are eCPRI data packets, and the data in the data packets includes eCPRI data.

[0035] In a possible implementation, the packet header indicates the type of data packet, which is either user plane data or control plane data.

[0036] According to a third aspect, an embodiment of the present application provides a communication device. The device may be a second device or a module (e.g., a chip) used in the second device. The device has a function for performing any of the embodiments of the first aspect. The function may be implemented using hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the aforementioned functions.

[0037] According to a fourth aspect, an embodiment of the present application provides a communication device. The device may be a first device or a module (e.g., a chip) used in the first device. The device has a function for performing any of the embodiments of the second aspect. The function may be implemented using hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the aforementioned functions.

[0038] According to a fifth aspect, an embodiment of the present application provides a communications device including at least one processor, the at least one processor being coupled to a memory and configured to read and execute instructions in the memory to implement any implementation of the first and second aspects, the memory may be located internal or external to the device.

[0039] According to a sixth aspect, an embodiment of the present application provides a communications device including a processor and a memory. The memory is configured to store computer instructions. When the device is executed, the processor executes the computer instructions stored in the memory, thereby causing the device to perform any implementation of the first and second aspects.

[0040] According to a seventh aspect, an embodiment of the present application provides a communication device comprising a unit or means configured to perform the steps of any implementation of the first and second aspects.

[0041] According to an eighth aspect, an embodiment of the present application provides a communication device including a processor and an interface circuit, wherein the processor is configured to communicate with another device via the interface circuit and to perform any of the implementations in the first and second aspects, and there may be one or more processors.

[0042] According to a ninth aspect, an embodiment of the present application further provides a computer program product, the computer program product including computer programs or instructions, which, when executed by a communication device, perform any of the implementations of the first and second aspects.

[0043] According to a tenth aspect, an embodiment of the present application further provides a computer-readable storage medium, the computer-readable storage medium storing instructions, which, when executed on a communication device, perform any implementation of the first and second aspects.

[0044] According to an eleventh aspect, an embodiment of the present application further provides a chip system including a processor configured to execute any of the implementations in the first and second aspects.

[0045] According to a twelfth aspect, an embodiment of the present application further provides a communication system including a second device configured to perform any implementation of the first aspect, and a first device configured to perform any implementation of the second aspect. [Brief explanation of the drawings]

[0046] [Figure 1] 1 is an example of a diagram of a service packet. [Figure 2]1 is a schematic flowchart of a data packet processing method according to an embodiment of the present application; [Figure 3a] FIG. 2 is a schematic diagram of a data packet format according to an embodiment of the present application. [Figure 3b] FIG. 2 is another schematic diagram of a data packet format according to an embodiment of the present application. [Figure 4a] 1 is a diagram of an example of an existing eCPRI-based service packet. [Figure 4b] FIG. 2 is a schematic diagram of inserting a CRC into a service data packet according to an embodiment of the present application; [Figure 5] 1 is a schematic diagram of the structure of a first device and a second device according to an embodiment of the present application; [Figure 6] 1 is a schematic diagram of a communication device according to an embodiment of the present application; [Figure 7] 1 is a schematic diagram of a communication device according to an embodiment of the present application; DETAILED DESCRIPTION OF THE INVENTION

[0047] 2 is a schematic flowchart of a data packet processing method according to an embodiment of the present application. In this embodiment, a first device functions as a transmitter and a second device functions as a receiver. Of course, this method is also applicable when a second device functions as a transmitter and a first device functions as a receiver. For example, the first device may be a communication device or functional module, such as a baseband unit (BBU), a central unit (CU), or a distributed unit (DU), having a baseband signal processing function. The second device may be a radio unit (RU), where the RU may be a communication device or functional module, such as a radio remote unit (RRU) or an adaptive antenna unit (AAU), having a function of processing an intermediate frequency signal, a radio frequency signal, or an intermediate radio frequency signal. Alternatively, the first device is an RU, and the second device is a BBU. The interface between the first device and the second device may be an eCPRI or other type of interface. This is not a limitation in this embodiment of this application.

[0048] The method includes the following steps.

[0049] Step 201: A first device generates a data packet, where the data packet includes a packet header, data, a first CRC, and a second CRC.

[0050] The first CRC is used to check the data packet. Optionally, the first device may generate the first CRC based on the packet header and the data, or the first device generates the first CRC based on the packet header, the data, and the second CRC.

[0051] The second CRC is used to check the packet header. Optionally, the first device generates the second CRC based on the packet header, or the first device generates the second CRC based on the packet header and a portion of the data.

[0052] The packet header of a data packet indicates the type of the data packet, and the type of the data packet is user plane data or control plane data. The type of a data packet being user plane data means that all data in the data packet is user plane data, or that it contains user plane data and other data. The type of a data packet being control plane data means that all data in the data packet is control plane data, or that it contains control plane data and other data. Optionally, if the data packet contains control plane data, the type of the data packet is control plane data. The type of a data packet may also be understood as the type of data in the data packet.

[0053] User plane data refers to actual service data, such as voice data or packet service data. Control plane data refers to control messages or signaling, such as cell setup messages, cell release messages, or messages related to operation and maintenance.

[0054] The packet assembly form of the data packet is not limited in this embodiment of the present application. Specifically, the positional relationship between the packet header, data, first CRC, and second CRC in the data packet is not limited. For example, the first CRC is located at the end of the data packet, and the second CRC is located after the packet header of the data packet. In another example, the first CRC is located at the end of the data packet, and the second CRC is located between the packet header and the data.

[0055] Optionally, the data in the data packet includes important information (e.g., information that affects a data packet processing method) and service data that need to be protected. The important information here includes, for example, an eCPRI type. In this case, the second CRC may be inserted after the packet header and the important information and is generated based on the packet header and the important information, thereby ensuring correct transmission of the important information by using the second CRC. For example, the data in the data packet includes an eCPRI type and eCPRI data. In this case, the second CRC may be inserted after the eCPRI type.

[0056] The assembly form of a data packet will now be described by way of an example with reference to the accompanying drawings.

[0057] 3a is a schematic diagram of a data packet format. The second CRC is located between the packet header and the data. Specifically, the second CRC is located after the packet header and before the data. The first CRC is located at the end of the data packet. The second CRC is generated based on the packet header. The first CRC is generated based on the packet header and the data, or based on the packet header, the second CRC, and the data. It should be noted that packet header sizes may be different for different data packets. Therefore, the distance between the start position of the second CRC and the start position of the packet header in different data packets may be different. Based on this embodiment, the packet header size can be learned in advance, and the second CRC can be inserted after the packet header based on the packet header size.

[0058] FIG. 3b is another schematic diagram of a data packet format. The second CRC is located within the data. After the second CRC is inserted, the original data is divided into two by the second CRC. The data portion before the second CRC is referred to as data_1, and the data portion after the second CRC is referred to as data_2. The combination of data_1 and data_2 is the original data. The first CRC is located at the end of the data packet. The second CRC is generated based on the packet header and data_1. The first CRC is generated based on the packet header and data, or based on the packet header, the second CRC, and data. In this embodiment, the length (hereinafter referred to as the preset length) may be preset, and the insertion position of the second CRC (i.e., the starting position of the second CRC, hereinafter referred to as the first position) is the starting position of the packet header plus the preset length. For example, the preset length is equal to or greater than the first length, and the first length may be the maximum length of various known packet header lengths. In this way, the second CRC can be inserted after the packet header, and the second CRC can be not inserted into the packet header, thereby ensuring the integrity of the packet header. It should be noted that the packet header lengths of different data packets may be different, so the bit size of data_1 before the second CRC may be different for different data packets. For example, if the preset length is 100 bits and the packet header of data packet x is 60 bits, the bit size of data_1 in data packet x is 40 bits. If the packet header of data packet y is 70 bits, the bit size of data_1 in data packet y is 30 bits.

[0059] Step 202: The first device transmits a data packet to the second device, and in response, the second device receives the data packet.

[0060] The first device can transmit the data packet to the second device via an interface between the first device and the second device, or the first device transmits the data packet to the second device via a forwarding performed by one or more third-party devices.

[0061] Step 203: The second device checks the data packet based on the first CRC in the data packet.

[0062] For example, after receiving a data packet, the second device obtains the first CRC in the data packet and generates a third CRC based on the portions of the data packet other than the first CRC (e.g., the packet header, the second CRC, and the data).

[0063] If the first CRC is the same as the third CRC, the check of the data packet is successful, which indicates that no error occurs during the transmission of the data packet.

[0064] If the first CRC is different from the third CRC, the check of the data packet fails, which indicates that an error occurs during the transmission of the data packet, and the location where the error occurs may be the packet header, the second CRC, the data, or the first CRC.

[0065] Step 204: The second device checks the packet header of the data packet based on the second CRC in the data packet.

[0066] The second device obtains the second CRC in the data packet and generates a fourth CRC based on a portion of the data packet located before the second CRC. The portion located before the second CRC may be the packet header. See the example of Figure 3a for example. Alternatively, the portion located before the second CRC may be the packet header and data_1. See the example of Figure 3b for example.

[0067] If the second CRC is the same as the fourth CRC, the packet header of the data packet is checked successfully, which indicates that no error occurs during the transmission of the packet header of the data packet.

[0068] If the second CRC is different from the fourth CRC, the packet header check of the data packet fails, indicating that an error occurs during transmission of the packet header of the data packet. In the example of FIG. 3a, if the second CRC is different from the fourth CRC, it indicates that the packet header check of the data packet fails, i.e., there is an erroneous bit in the packet header. In the example of FIG. 3b, if the second CRC is different from the fourth CRC, there may be an erroneous bit in the packet header, or there may be an erroneous bit in data_1. However, in actual application, the proportion of data_1 in the data is generally very small. Therefore, in the example of FIG. 3b, if the second CRC is different from the fourth CRC, it indicates that there is an error in the packet header or data_1. Alternatively, no distinction is necessary, and it is generally considered that the packet header check of the data packet fails, i.e., there is an erroneous bit in the packet header.

[0069] Step 205: The second device processes the data packet based on the check result of the data packet and / or the check result of the packet header.

[0070] Two different specific implementations of steps 203 to 205 are described below.

[0071] Embodiment 1: The second device not only performs step 203 to obtain a check result of the data packet, but also performs step 204 to obtain a check result of the packet header, and processes the data packet based on the check result of the data packet and / or the check result of the packet header.

[0072] The order of execution of step 203 and step 204 is not limited. For example, step 203 may be executed before step 204, step 204 may be executed before step 203, or the two steps may be executed simultaneously in no particular order.

[0073] In embodiment 1, the second device processes the data packet based on the check result of the data packet and / or the check result of the packet header, which can be specifically divided into the following case 1 and case 2.

[0074] Case 1: If the check of the data packet is successful, it indicates that no error occurs during the transmission of the data packet. In this case, the second device does not discard the data packet. "Do not discard" in this embodiment of the present application may, for example, store, reserve, continue processing, or send the data packet to a next-level data processing module for subsequent processing. "Discard" in this embodiment of the present application may include deleting the data packet, overwriting it with other data, not further processing it, or not sending it to a next-level data processing module. The description here is provided uniformly, and the details will not be described again below. Optionally, if a second CRC is located in the data, the second device may obtain the data in the data packet after deleting the second CRC. For example, see FIG. 3b. After deleting the second CRC, the second device may obtain the data in the data packet based on data_1 and data_2.

[0075] If the data packet check is successful, it means that there is no transmission error in the packet header and data. Therefore, it can be considered that the packet header check is also successful. Therefore, if the data packet check is successful, it can indicate that the data packet check is successful and the packet header check is successful.

[0076] Case 2: If the check of the data packet fails, it indicates that an error occurs during the transmission of the data packet. The location where the error occurs may be the packet header, the second CRC, the data, or the first CRC. In this case, the second device may alternatively not discard the data packet. Instead, the second device may determine how to process the data packet based on the check result of the packet header. Therefore, Case 2 may be further divided into Case 2.1 and Case 2.2 below.

[0077] Case 2.1: If the check of the data packet fails but the check of the packet header of the data packet is successful, it indicates that a transmission error occurs in the data packet, but the error does not occur in the packet header, i.e., the transmission error does not occur in the packet header. In this case, it can be understood that the transmission error occurs in the data within the data packet. In this case, the second device can process the data packet based on the type of the data packet. The example in Figure 3a means that a transmission error occurs in the data and / or the first CRC. The example in Figure 3b means that a transmission error occurs in data_2 in the data and / or the first CRC.

[0078] The second device can determine the type of the data packet based on the packet header. For example, the packet header can include the type of the data packet, or can include indication information indicating the type of the data packet, or the packet header can correspond to the type of the data packet.

[0079] In one embodiment, the second device processing the data packet based on the type of the data packet includes, for example, skipping discarding the data packet if the type of the data packet is user plane data, or discarding the data packet if the type of the data packet is control plane data.

[0080] Specifically, if the type of data packet is user plane data, it means that the packet header of the data packet is transmitted correctly, a transmission error occurs in the data in the data packet, and the data contains or is entirely user plane data. In this case, although some errors occur in the transmitted user plane data, the user plane data can be processed correctly because the packet header is transmitted correctly. In addition, the error in the user plane data may only slightly affect the user experience and does not actually cause other more serious effects. Therefore, the second device does not need to discard the data packet. In this way, data transmission efficiency can be improved and system capacity can be increased. Optionally, if a second CRC is located in the data, the second device may obtain the data in the data packet after removing the second CRC. For example, see FIG. 3b. After removing the second CRC, the second device may obtain the data in the data packet based on data_1 and data_2. Optionally, after removing the second CRC to obtain the data, the second device may perform the next processing on the data or send the data to a next-level data processing module for subsequent processing.

[0081] If the type of the data packet is control plane data, it means that the packet header of the data packet is transmitted correctly, but a transmission error occurs in the data within the data packet, and the data is control plane data. In this case, the packet header is transmitted correctly, but an error occurs in the transmitted control plane data. Because the consequences caused by the error in the control plane data are relatively serious, the second device discards the data packet.

[0082] Case 2.2: If the check of the data packet fails and the check of the packet header of the data packet fails, it indicates that a transmission error occurs in the data packet, and the location where the error occurs includes at least the packet header, that is, the transmission error occurs in the packet header. In this case, the second device can discard the data packet.

[0083] The packet header has a significant impact on how the data packet is correctly processed by the second device because the packet header includes one or more of a source address, a destination address, a source port number, a destination port number, protocol information, etc. Therefore, if the packet header check fails, the data packet is discarded.

[0084] Embodiment 2: The second device first performs step 203 to obtain a check result of the data packet. If the check result of the data packet is that the check of the data packet is successful, the data packet is not discarded. For details, please refer to the description of Case 1 in the above Embodiment 1, and step 204 and step 205 are not performed later. If the check result of the data packet is that the check of the data packet is unsuccessful, step 204 is performed again to obtain a check result of the packet header, and the data packet is processed according to the check result of the packet header. Processing the data packet according to the check result of the packet header includes two cases, which are respectively described as Case 2.1 and Case 2.2 in the above Embodiment 1.

[0085] According to the second embodiment, if the check of the data packet is successful, the packet header is not checked any more, so that the number of checks can be reduced, thereby improving the check efficiency.

[0086] Based on embodiment 2, optionally, if the check of the data packet fails, the data packet may be marked. In other words, if the check of the data packet fails, the data packet is not discarded. Instead, the data packet is marked. For example, the data packet may be marked using a special character or a specific bit to indicate that the data packet is a data packet that needs to be further determined. Subsequently, the packet header of the data packet is checked again using the second CRC, and based on the check result of the packet header, it is determined whether to discard the data packet or not to discard the data packet.

[0087] In one embodiment, in any one of the above-mentioned embodiments, if the second device discards a received data packet, after discarding the data packet, the second device can further notify the first device to retransmit the data packet to ensure that the data packet is received correctly and improve the user experience.

[0088] According to the above solution, the second device includes in the data packet a first CRC used to check the data packet and a second CRC used to check the packet header of the data packet. If the check of the data packet fails but the check of the packet header is successful, it indicates that the packet header is transmitted correctly but the data is transmitted incorrectly. In this case, instead of directly discarding the data packet, the second device can process the data packet based on the type of the data packet. In this way, the amount of packet loss can be reduced, thereby improving data transmission efficiency and increasing system capacity.

[0089] The aforementioned solutions provided in this embodiment of this application can be applied to various scenarios, which are not limited in this application, and will be described below with reference to specific application scenarios.

[0090] In the following example, the interface between the first device and the second device is eCPRI as an illustrative example, in which a data packet sent by the first device to the second device may be referred to as an eCPRI data packet, and the data in the data packet may be referred to as eCPRI data.

[0091] Currently, with traditional CPRI, the transmitted data is actually a digital sample of the air interface data. Some bit errors only affect the numerical accuracy of the sampled data and not other samples. This makes the CPRI link highly tolerant to optical fiber bit errors. After the wireless fronthaul is switched from CPRI to eCPRI, if there is a bit error in the fronthaul link, the current processing mechanism allows one bit error to cause a CRC check failure in one data packet. Therefore, the data packet is discarded. However, discarding one data packet does not guarantee that all data packets can be received, so the entire service packet is discarded. This greatly increases data loss due to bit errors. As a result, after the wireless fronthaul is switched from CPRI to eCPRI, service performance is relatively degraded, which affects the user experience.

[0092] 4a is a schematic diagram of the format of an existing eCPRI-based service packet. One service packet includes one or more data packets, and each data packet includes a medium access control (MAC) header, MAC data, and a CRC.

[0093] The MAC header includes information such as the source MAC address and the destination MAC address.

[0094] The MAC data includes the eCPRI type and the eCPRI data, which includes the user plane data or control plane data to be transmitted.

[0095] The CRC is used to check the accuracy of the MAC header and MAC data. If the CRC check performed by the receiver is successful, it indicates that both the MAC header and MAC data are transmitted correctly and there are no error bits. If the CRC check fails, it indicates that there are erroneous bits in the MAC header and MAC data.

[0096] FIG. 4a is used as an example. Suppose a transmission error occurs in a bit or several bits in data packet 3, the CRC check of service data packet 3 performed by the receiving side will fail. In this case, the receiving side will discard data packet 3 according to the current processing mechanism. In addition, since the receiving side cannot correctly receive data packet 3, the entire service packet will also be discarded. This is because not all data packets can be received. This means that even if the receiving side correctly receives n-1 data packets other than data packet 3, the receiving side will discard n-1 data packets. As a result, service performance will be relatively degraded, and user experience will be affected.

[0097] The existing eCPRI data packet is improved below with reference to the method shown in Figure 2. Specifically, an eCPRI data packet generated by a first device includes two CRCs, a first CRC and a second CRC. Then, the first device transmits the eCPRI data packet to a second device. The second device can determine a manner for processing the eCPRI data packet based on the first CRC and the second CRC in the eCPRI data packet.

[0098] The eCPRI data packet transmission and processing process includes the following steps:

[0099] Step 1: A first device obtains a data packet a, which includes a MAC header, an eCPRI type, and eCPRI data.

[0100] The MAC header here is a specific example of the packet header in the embodiment of FIG.

[0101] The combination of eCPRI type and eCPRI data here is a specific example of data in the embodiment of FIG.

[0102] Step 2: The first device inserts CRC1 into the data packet a to obtain the data packet b.

[0103] Here, CRC1 is a specific example of the second CRC in the embodiment of FIG.

[0104] 4b is a schematic diagram of inserting a CRC into a service data packet. In this example, CRC1 is inserted in the first position. After CRC1 is inserted, the eCPRI data is divided into eCPRI data_1 and eCPRI data_2. CRC1 is generated based on the MAC header, eCPRI type, and eCPRI data_1. The combination of eCPRI type and eCPRI data_1 here is a specific example of data_1 in the embodiment of FIG. 2.

[0105] Step 3: The first device inserts CRC2 at the end of data packet b to obtain data packet c.

[0106] The CRC2 header here is a specific example of the first CRC in the embodiment of FIG.

[0107] CRC2 is generated based on the MAC header, eCPRI type, CRC1, eCPRIdata_1, and eCPRI data_2.

[0108] Step 4: The first device sends a data packet c to the second device.

[0109] Here, data packet c is a specific example of a data packet transmitted by a first device to a second device in the embodiment of FIG.

[0110] Step 5: The second device checks CRC2 in the data packet c, and optionally checks CRC1 as well, which can be divided into the following case 1 and case 2:

[0111] Case 1: If the check of CRC2 is successful, it indicates that the MAC header, eCPRI type, and eCPRI data are all transmitted correctly. In this case, the second device does not discard the data packet c. Optionally, the second device further removes CRC1 to obtain the eCPRI data, and stores the eCPRI data.

[0112] Case 2: If the check of CRC2 fails, then CRC1 is checked further, which can be divided into Case 2.1 and Case 2.2 below.

[0113] Case 2.1: If the CRC1 check fails, the data packet c is discarded.

[0114] Case 2.2: If the CRC1 check is successful, the following cases 2.2.1 and 2.2.2 can be separated.

[0115] Case 2.2.1: If the type of the eCPRI data is user plane data, the data packet c is not discarded. Optionally, the second device further removes CRC1 to obtain the eCPRI data.

[0116] Case 2.2.2: If the type of the eCPRI data is control plane data, the data packet c is discarded.

[0117] The second device may determine the type of eCPRI data based on the MAC header and / or the eCPRI type.

[0118] According to the above method, the transmission and processing of eCPRI data packets is implemented, which can improve data transmission efficiency and increase system capacity, thereby helping to improve user experience.

[0119] For example, the following provides an embodiment of a first device and a second device. Figure 5 is a schematic diagram of the structure of a first device and a second device according to an embodiment of this application. The following describes an example in which the first device and the second device shown in Figure 5 are applied to the aforementioned eCPRI data packet transmission and processing process.

[0120] The first device includes a baseband processing unit, a header check encoding unit, and an Ethernet MAC layer packet sending unit.

[0121] (1) The baseband processing unit generates a data packet a, where the data packet a includes a MAC header, an eCPRI type, and eCPRI data.

[0122] (2) The header check processing unit generates CRC1 based on the MAC header, eCPRI type, and eCPRI data_1, and inserts the CRC1 into the first position to obtain the data packet b.

[0123] (3) The Ethernet MAC layer packet transmitting unit generates a CRC2 based on the MAC header, the eCPRI type, the CRC1, and the eCPRI data, appends the CRC2 to the end of the data packet b to obtain a data packet c, and transmits the data packet c to the second device via the eCPRI interface between the first device and the second device.

[0124] The second device includes an Ethernet MAC layer packet receiving unit, a header check decoding unit, and a baseband processing unit.

[0125] (1) The Ethernet MAC layer packet receiving unit receives data packet c and checks CRC2 in data packet c. If the CRC2 check is successful, the Ethernet MAC layer packet receiving unit deletes CRC2 in data packet c to obtain data packet b and generates mark information 1. The mark information 1 indicates that the data packet check is successful. The Ethernet MAC layer packet receiving unit then sends data packet b and mark information 1 to the header check unit. If the CRC2 check is unsuccessful, the Ethernet MAC layer packet receiving unit deletes CRC2 to obtain data packet b and generates mark information 2. The mark information 2 indicates that the data packet check is unsuccessful. The Ethernet MAC layer packet receiving unit then sends data packet b and mark information 2 to the header check unit.

[0126] (2) The header check processing unit receives data packet b, as well as mark information 1 or mark information 2. When the header check processing unit receives data packet b and mark information 1, it removes CRC1 to obtain data packet a and generates mark information 3. The mark information 3 indicates that the data packet has been checked successfully. The header check processing unit then sends data packet a and mark information 3 to the baseband processing unit. When the header check processing unit receives data packet b and mark information 2, it checks CRC1 in data packet b. If the CRC1 check is successful and the type of data packet b is user plane data, the header check processing unit removes CRC1 to obtain data packet a and generates mark information 3. The mark information 3 indicates that the data packet has been checked successfully. The header check processing unit then sends data packet a and mark information 3 to the baseband processing unit. If the check of CRC1 is successful and the type of data packet b is control plane data, or if the check of CRC1 fails, the header check processing unit deletes CRC1 to obtain data packet a and generates mark information 4. The mark information 4 indicates that the check of the data packet fails. Then, the header check processing unit sends data packet a and mark information 4 to the baseband processing unit.

[0127] (3) The baseband processing unit receives data packet a and also receives mark information 3 or mark information 4. When the baseband processing unit receives data packet a and mark information 3, it does not discard data packet a. For example, the baseband processing unit can process data packet a or send data packet a to the next level data processing model for processing. When the baseband processing unit receives data packet a and mark information 4, it discards data packet a.

[0128] In the above-described embodiment, mark information 1, mark information 2, mark information 3, and mark information 4 may not exist simultaneously. In the embodiment provided above, the Ethernet MAC layer packet receiving unit of the second device uses mark information 1 to notify the header check unit that the check of the data packet is successful, and uses mark information 2 to notify the header check unit that the check of the data packet is unsuccessful. In another embodiment, when determining that the check of data packet c is successful, the Ethernet MAC layer packet receiving unit sends data packet b and one piece of mark information to the header check unit. When determining that the check of data packet c is unsuccessful, the Ethernet MAC layer packet receiving unit sends data packet b to the header check unit. Thus, when the header check unit receives data packet b and one piece of mark information, it determines that the check of data packet b is successful, i.e., no transmission error occurs in data packet b. When the header check unit receives data packet b, it determines that the check of data packet b is unsuccessful, i.e., a transmission error occurs in data packet b. Alternatively, if the Ethernet MAC layer packet receiving unit determines that the check of data packet c is successful, it sends data packet b to the header check unit. If the Ethernet MAC layer packet receiving unit determines that the check of data packet c is unsuccessful, it sends data packet b and one piece of mark information to the header check unit.

[0129] In one embodiment, the header check unit and the baseband processing unit can alternatively process data packets in the following processing manner: The header check unit receives data packet b, and also receives mark information 1 or mark information 2. When the header check processing unit receives data packet b and mark information 1, it deletes CRC1 from data packet b to obtain data packet a, and sends data packet a to the baseband processing unit. When the header check processing unit receives data packet b and mark information 2, it checks CRC1 from data packet b. If the check of CRC1 is successful and the type of data packet b is user plane data, the header check processing unit deletes CRC1 to obtain data packet a, and sends data packet a to the baseband processing unit. If the check of CRC1 is successful and the type of data packet b is control plane data, or if the check of CRC1 fails, the header check processing unit discards data packet b. Correspondingly, the baseband processing unit receives data packet a, and the baseband processing unit does not discard data packet a. For example, the baseband processing unit can process data packet a or send data packet a to the next level data processing model for processing.

[0130] It can be understood that the division and names of the functional units described above are merely examples, and the functions implemented in the same unit in the above examples may alternatively be implemented by different functional modules or functional units. Similarly, the functions implemented in different units in the above examples may alternatively be implemented by the same functional module or unit according to requirements, which is not limited in this application.

[0131] The above solution can extract most of the data packets carrying user plane data and having error bits, thereby improving system performance in bit error conditions on the fronthaul link.

[0132] It can be understood that to implement the functions of the above-mentioned embodiments, the first device or the second device includes a corresponding hardware structure and / or a corresponding software module for performing each function. As can be easily recognized by those skilled in the art, based on the example units and method steps described in the embodiments disclosed in this application, this application can be implemented by hardware or a combination of hardware and computer software. Whether the functions are performed by hardware or by hardware driven by computer software depends on the specific application scenario and the design constraints of the technical solution.

[0133] 6 and 7 are schematic diagrams of possible communication device structures according to embodiments of the present application. The communication device 600 may be configured to implement the functions of the first device or the second device in the aforementioned method embodiments. Therefore, the communication device can also achieve the beneficial effects of the aforementioned method embodiments. In the embodiments of the present application, the communication device may be the first device or the second device, or may be a module (e.g., a chip) used in the first device or the second device. As shown in FIG. 6, the communication device 600 includes a processing unit 610 and a transceiver unit 620. The communication device 600 is configured to implement the functions of the first device or the second device in the aforementioned method embodiments. For example, when the communication device 600 is configured to implement the functions of the first device in FIG. 5, the processing unit 610 may be configured to implement the functions of the baseband processing unit and the header check processing unit of the first device, and the transceiver unit 620 may be configured to implement the functions of the Ethernet MAC layer packet transmission unit of the first device. When the communication apparatus 600 is configured to implement the functionality of the second device of FIG. 5, the processing unit 610 may be configured to implement the functionality of a baseband processing unit and a header check processing unit of the second device, and the transceiver unit 620 may be configured to implement the functionality of an Ethernet MAC layer packet receiving unit of the second device.

[0134] In a first embodiment, the communication apparatus is configured to perform the operations of the second device in the embodiment of the method shown in Fig. 2. The transceiver unit 620 is configured to receive a data packet from the first device, where the data packet includes a packet header, data, a first CRC, and a second CRC. The processing unit 610 is configured to check the data packet based on the first CRC in the data packet, check a packet header of the data packet based on the second CRC in the data packet, and process the data packet based on a check result of the data packet and / or a check result of the packet header.

[0135] In possible embodiments, the processing unit 610 is specifically configured to: skip discarding the data packet if the data packet check is successful, or if the data packet check is successful and the packet header check is successful; discard the data packet if the data packet check fails and the packet header check fails; or process the data packet based on the type of the data packet if the data packet check fails but the packet header check is successful.

[0136] In a possible embodiment, the processing unit 610 is specifically configured to check the packet header of the data packet based on a second CRC in the data packet if the check of the data packet fails.

[0137] In a possible embodiment, the processing unit 610 is specifically configured to mark a data packet if the check of the data packet fails.

[0138] In a possible embodiment, the processing unit 610 is specifically configured to skip discarding the data packet if the type of the data packet is user plane data, and to discard the data packet if the type of the data packet is control plane data.

[0139] In a possible embodiment, the processing unit 610 is further configured to determine the type of the data packet based on the packet header.

[0140] In a possible embodiment, the processing unit 610 is further configured to remove the second CRC from the data packet.

[0141] In a possible implementation, the first CRC is located at the end of the data packet and the second CRC is located after the packet header of the data packet.

[0142] In a possible embodiment, the first CRC is generated based on the packet header of the data packet and the data within the data packet.

[0143] In a possible embodiment, the first CRC is generated based on the packet header of the data packet, the data within the data packet, and the second CRC.

[0144] In a possible embodiment, the second CRC is generated based on the packet header of the data packet.

[0145] In a possible embodiment, the second CRC is generated based on the packet header of the data packet and a portion of the data within the data packet.

[0146] In one possible implementation, the data packets are eCPRI data packets, and the data in the data packets includes eCPRI data.

[0147] In a second embodiment, the communication apparatus is configured to perform the operations of the first device in the embodiment of the method shown in Fig. 2. The processing unit 610 is configured to generate a data packet, the data packet including a packet header, data, a first CRC, and a second CRC, the first CRC being used to check the data packet and the second CRC being used to check the packet header. The transceiver unit 620 is configured to transmit the data packet to the second device.

[0148] In a possible embodiment, the processing unit 610 is further configured to generate a second CRC based on the packet header.

[0149] In a possible embodiment, the processing unit 610 is specifically configured to generate a second CRC based on the packet header and part of the data.

[0150] In a possible embodiment, the processing unit 610 is further configured to generate a first CRC based on the packet header, the data, and the second CRC.

[0151] In a possible implementation, the first CRC is located at the end of the data packet and the second CRC is located after the packet header of the data packet.

[0152] In one possible implementation, the data packets are eCPRI data packets, and the data in the data packets includes eCPRI data.

[0153] In a possible implementation, the packet header indicates the type of data packet, which is either user plane data or control plane data.

[0154] For details about the processing unit 610 and the transceiver unit 620, please directly refer to the relevant descriptions of the above method embodiments, and the details will not be repeated here.

[0155] 7, the communication device 700 includes at least one processor 710 and may further include an interface circuit 720. The processor 710 and the interface circuit 720 may be coupled to each other. It may be understood that the interface circuit 720 may be a transceiver or an input / output interface. Optionally, the communication device 700 may further include a memory 730 configured to store instructions to be executed by the processor 710, to store input data required by the processor 710 to execute the instructions, or to store data generated after the processor 710 executes the instructions.

[0156] When the communications device 700 is configured to perform embodiments of the aforementioned methods, the processor 710 may be configured to implement the functionality of the aforementioned processing unit 610, and the interface circuit 720 may be configured to implement the functionality of the aforementioned transceiver unit 620.

[0157] It may be understood that the processor in the embodiments of this application may be a central processing unit (CPU), or may be another general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a transistor logic device, a hardware component, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0158] The method steps in the embodiments of this application may be implemented in a hardware manner or by a processor executing software instructions. The software instructions may include corresponding software modules. The software modules may be stored in a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an erasable programmable read-only memory, an electrically erasable programmable read-only memory, a register, a hard disk, a removable hard disk, a CD-ROM, or any other form of storage medium well known in the art. For example, the storage medium is coupled to the processor such that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium may alternatively be components of the processor. The processor and the storage medium may be located in an ASIC. In addition, the ASIC may be located in a base station or a terminal. Indeed, the processor and the storage medium may alternatively reside as separate components in the base station or the terminal.

[0159] All or part of the above-described embodiments may be implemented by software, hardware, firmware, or any combination thereof. When software is used to implement the above-described embodiments, all or part of the above-described embodiments may be realized in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer programs or instructions are loaded into a computer and executed, all or part of the procedures or functions in the embodiments of this application are performed. The computer may be a general-purpose computer, a special-purpose computer, a computer network, a base station, user equipment, or other programmable device. The computer program or instructions may be stored in a computer-readable storage medium or transmitted from a computer-readable storage medium to another computer-readable storage medium. For example, the computer program or instructions may be transmitted from a website, computer, server, or data center to another website, computer, server, or data center via a wired or wireless manner. The computer-readable storage medium may be any available medium accessible by a computer, or a data storage device, such as a server or data center, incorporating one or more available media. The available media may be magnetic media such as floppy disks, hard disks, or magnetic tape, optical media such as digital video disks, or semiconductor media such as solid state drives. The computer readable storage media may be volatile or nonvolatile storage media, or may include both volatile and nonvolatile storage media types.

[0160] In various embodiments of this application, unless otherwise specified or there is no logical contradiction, the terms and / or descriptions between different embodiments are consistent and can be cross-referenced, and the technical features of different embodiments can be combined based on their internal logical relationships to form new embodiments.

[0161] In this application, "at least one" means one or more, and "plurality" means two or more. The term "and / or" describes an association relationship between associated objects and indicates that three relationships may exist. For example, A and / or B may represent the following cases: only A is present, both A and B are present, and only B is present, where A and B may be singular or plural. In the text descriptions of this application, the character " / " generally represents an "or" relationship between associated objects. In the formulas of this application, the character " / " represents a "divide" relationship between associated objects.

[0162] It can be understood that various numbers in the embodiments of this application are only used for distinction to facilitate description, and are not used to limit the scope of the embodiments of this application. The order numbers of the above processes do not mean the execution order, and the execution order of the processes should be determined based on the functions and internal logic of the processes. [Explanation of symbols]

[0163] 600 Communication Equipment 610 Processing Unit 620 Transceiver Unit 700 Communication Equipment 710 processor 720 Interface Circuit 730 memory

Claims

1. A method of processing data packets performed by a second device, comprising: receiving a data packet from a first device; checking the data packet based on a first cyclic redundancy check (CRC) in the data packet; checking a packet header of the data packet based on a second CRC in the data packet; If the check of the data packet fails and the packet header check fails, discarding the data packet; or if the data packet check fails but the packet header check succeeds, processing the data packet based on the type of the data packet; Including, the second CRC is generated based on a preset length of bits consisting of the packet header of the data packet and a portion of the data in the data packet, and the second CRC is inserted from the start position of the packet header to the preset length. Data packet processing method.

2. the step of checking a packet header of the data packet based on a second CRC in the data packet includes: if checking the data packet fails, checking the packet header of the data packet based on the second CRC in the data packet; 2. The method of claim 1, comprising:

3. marking said data packet if checking of said data packet fails. The method of claim 1 further comprising:

4. The step of processing the data packet based on the type of the data packet comprises: skipping discarding the data packet if the type of the data packet is user plane data; or Discarding the data packet if the type of the data packet is control plane data; 2. The method of claim 1, comprising:

5. determining a type of the data packet based on the packet header; The method of claim 4, further comprising:

6. removing the second CRC from the data packet; The method of claim 1 further comprising:

7. A method of processing data packets performed by a first device, comprising: generating a data packet, the data packet including a packet header, data, a first cyclic redundancy check (CRC), and a second CRC, the first CRC being used to check the data packet and the second CRC being used to check the packet header; transmitting the data packet to a second device; Including, A data packet processing method, wherein the second CRC is generated based on a preset length of bits consisting of the packet header of the data packet and a portion of the data in the data packet, and the second CRC is inserted from the start position of the packet header to a position of the preset length.

8. generating the second CRC based on the packet header; The method of claim 7, further comprising:

9. generating the second CRC based on the packet header, generating the second CRC based on the packet header and a portion of the data; 9. The method of claim 8, comprising:

10. generating the first CRC based on the packet header, the data, and the second CRC; The method of claim 7, further comprising:

11. A communication device comprising modules configured to perform the method of any one of claims 1 to 6.

12. A communication device comprising a module configured to perform the method of any one of claims 7 to 10.

13. A computer program product comprising a computer program, the computer program performing the method of any one of claims 1 to 6 when said computer program is executed by a communication device.

14. A computer program product comprising a computer program, the computer program performing the method of any one of claims 7 to 10 when the computer program is executed by a communications device.

15. A communication system comprising a second device configured to perform the method of any one of claims 1 to 6 and a first device configured to perform the method of any one of claims 7 to 10.

Images