Communication method and communication system

CN122932905APending Publication Date: 2026-10-16GEER TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510424057.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-04-03
Publication Date
2026-10-16

AI Technical Summary

Technical Problem

[0004]本申请的主要目的在于提供一种通信方法及通信系统,旨在解决传统ACK机制会降低通信性能的技术问题

Benefits of technology

[0041]在本实施例中,主机端生成待发送的各数据包,向所述从机端发送所述各数据包的包数以及所述各数据包;在所述各数据包发送完成后,向所述从机端发送传输结束指令,其中,所述传输结束指令用于指示所述从机端基于所述包数对已接收的数据包进行检查;接收到所述从机端发送的重传数据包列表,在所述重传数据包列表中记录有数据包的情况下,将所述重传数据包列表中记录的数据包重新发送至所述从机端,其中,所述检查出的异常结果用于构建所述重传数据包列表。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122932905A_ABST
    Figure CN122932905A_ABST
Patent Text Reader

Abstract

The application discloses a communication method and a communication system, and relates to the technical field of communication. The method comprises the following steps: a host end generates each data packet to be sent, sends the number of each data packet and each data packet to a slave end; after the sending of each data packet is completed, a transmission end instruction is sent to the slave end, wherein the transmission end instruction is used for instructing the slave end to check the received data packet based on the number; a retransmission data packet list sent by the slave end is received, and the data packet recorded in the retransmission data packet list is re-sent to the slave end in the case that the data packet is recorded in the retransmission data packet list, wherein the checked abnormal result is used for constructing the retransmission data packet list. The application greatly reduces the confirmation times of the slave end, improves the communication efficiency, reduces the communication cost, and improves the communication efficiency and communication performance.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication method and communication system. Background Technology

[0002] Currently, in industrial communication scenarios, such as the Industrial Internet of Things (IIoT), most communication protocols use the traditional ACK (Acknowledgment) mechanism when communicating between devices, such as TCP (Transmission Control Protocol) and SCTP (Stream Control Transmission Protocol). However, because the traditional ACK mechanism acknowledges each received data packet individually, it increases communication latency and reduces communication efficiency to some extent, especially in scenarios with high packet loss rates, where communication performance degrades significantly.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a communication method and system that aims to solve the technical problem that the traditional ACK mechanism reduces communication performance.

[0005] To achieve the above objectives, this application proposes a communication method, which includes the following steps:

[0006] Generate each data packet to be sent, and send the number of packets and each data packet to the slave device;

[0007] After each data packet is sent, a transmission end command is sent to the slave device, wherein the transmission end command is used to instruct the slave device to check the received data packets based on the number of packets;

[0008] Upon receiving the retransmission data packet list sent by the slave device, if a data packet is recorded in the retransmission data packet list, the data packet recorded in the retransmission data packet list is retransmitted to the slave device, wherein the detected abnormal results are used to construct the retransmission data packet list.

[0009] Optionally, the communication method further includes:

[0010] Send master communication parameters to the slave device;

[0011] Receive the negotiated communication parameters determined by the slave device based on the master device communication parameters and the slave device communication parameters;

[0012] The steps for generating the data packets to be sent include:

[0013] Based on the negotiated communication parameters, the data block to be sent is divided into data segments, and data packets are generated according to each data segment.

[0014] Optionally, the communication method further includes:

[0015] If the first available device resource used by the host to communicate with the slave is updated, new host communication parameters are generated based on the new first available device resource, wherein the parameter value of the host communication parameter increases as the first available device resource increases;

[0016] Based on the new host communication parameters, return to the step of sending host communication parameters to the slave.

[0017] Furthermore, to achieve the above objectives, this application also proposes a communication method applied to a slave device, wherein the slave device communicates with a master device, and the communication method includes the following steps:

[0018] Receive the number of packets and each data packet sent by the host, and store the received data packets in the buffer area;

[0019] After receiving the transmission end instruction sent by the host, the received data packets in the buffer are checked based on the number of packets;

[0020] If an abnormal result is found during the check, a list of retransmission data packets constructed based on the abnormal result is sent to the host, and the data packets recorded in the list of retransmission data packets sent by the host are received.

[0021] Optionally, the communication method further includes:

[0022] Receive host communication parameters sent by the host terminal;

[0023] The negotiated communication parameters are determined based on the host communication parameters and the slave communication parameters, wherein the parameter value of the negotiated communication parameters is less than or equal to the minimum parameter value among the host communication parameters and the slave communication parameters;

[0024] The negotiated communication parameters are sent to the host.

[0025] Optionally, the communication method further includes:

[0026] If the second available device resource used by the slave device to communicate with the master device is updated, new slave communication parameters are generated based on the new second available device resource;

[0027] Based on the new slave communication parameters, return to the step of determining the negotiated communication parameters based on the master communication parameters and the slave communication parameters of the slave end.

[0028] Optionally, the step of checking the received data packets in the buffer based on the number of packets includes:

[0029] An anomaly result is generated based on the difference between the number of packets and the maximum index sequence number of the received data packets in the buffer.

[0030] Based on the abnormal results and the detection results of the received data packets in the buffer, the lost data packets are determined and recorded in the retransmission data packet list. The detection results are obtained by performing a continuous detection on the index sequence number of each received data packet.

[0031] Optionally, the data packet types in the retransmission data packet list may also include erroneous data packets, and the communication method may further include:

[0032] For any received data packet in the buffer, perform an integrity check on the received data packet based on the checksum in the received data packet;

[0033] If a received data packet that failed integrity verification exists in the buffer, the received data packet that failed integrity verification is treated as an erroneous data packet and recorded in the retransmission data packet list.

[0034] Furthermore, to achieve the above objectives, this application also proposes a communication system, which includes:

[0035] On the host side, it generates each data packet to be sent, sends the number of packets of each data packet and each data packet to the slave side; after each data packet is sent, it sends a transmission end command to the slave side; and receives the retransmission data packet list of each data packet sent by the slave side.

[0036] The slave device receives the packet count and the data packets of each data packet, and stores the received data packets in a buffer. After receiving a transmission end command, it checks the received data packets in the buffer based on the packet count. If there is an abnormal result, it sends a retransmission data packet list based on the abnormal result to the host device, and receives the data packets recorded in the retransmission data packet list sent by the host device.

[0037] In addition, to achieve the above objectives, this application also proposes an electronic device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the communication method described above.

[0038] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the communication method described above.

[0039] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the communication method described above.

[0040] One or more technical solutions proposed in this application have at least the following technical effects:

[0041] In this embodiment, the host generates data packets to be sent and sends the packet count and the data packets to the slave. After the data packets are sent, a transmission end command is sent to the slave, wherein the transmission end command is used to instruct the slave to check the received data packets based on the packet count. Upon receiving a retransmission data packet list sent by the slave, if data packets are recorded in the retransmission data packet list, the data packets recorded in the retransmission data packet list are retransmitted to the slave. The detected anomalies are used to construct the retransmission data packet list.

[0042] In other words, during data communication between the host and slave, the host sends multiple data packets to the slave. The slave can then uniformly check the received data packets before sending a list of retransmitted data packets back to the host. Compared to the traditional method of acknowledging each data packet individually, this application can uniformly confirm the reception status of multiple data packets, greatly reducing the number of acknowledgments required by the slave (receiver) and improving communication efficiency. Furthermore, if any anomalies are found during the check, the host only needs to send the data packets recorded in the retransmitted data packet list to the slave, thus avoiding retransmitting all data packets, reducing communication overhead, and improving communication efficiency and performance. Attached Figure Description

[0043] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0044] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 This is a flowchart illustrating the first embodiment of the communication method in this application;

[0046] Figure 2 This is a flowchart illustrating the second embodiment of the communication method in this application;

[0047] Figure 3 This is a flowchart illustrating the third embodiment of the communication method in this application;

[0048] Figure 4 This is a flowchart illustrating the fourth embodiment of the communication method in this application;

[0049] Figure 5 This is a schematic diagram of the communication system in the communication method of this application;

[0050] Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the communication method in the embodiments of this application.

[0051] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0052] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0053] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0054] Currently, in industrial communication scenarios, such as the Industrial Internet of Things (IIoT), most communication protocols use the traditional ACK (Acknowledgment) mechanism when communicating between devices, such as TCP (Transmission Control Protocol) and SCTP (Stream Control Transmission Protocol). However, because the traditional ACK mechanism acknowledges each received data packet individually, it increases communication latency to some extent, especially in scenarios with high packet loss rates, resulting in a significant degrade in communication performance.

[0055] The main solution of this application embodiment is as follows: the host generates each data packet to be sent, and sends the number of packets and each data packet to the slave; after each data packet is sent, a transmission end command is sent to the slave, wherein the transmission end command is used to instruct the slave to check the received data packets based on the number of packets; the retransmission data packet list sent by the slave is received, and if there are data packets recorded in the retransmission data packet list, the data packets recorded in the retransmission data packet list are retransmitted to the slave, wherein the abnormal results detected are used to construct the retransmission data packet list.

[0056] In other words, during data communication between the host and slave, the host sends multiple data packets to the slave. The slave can then uniformly check the received data packets before sending a list of retransmitted data packets back to the host. Compared to the traditional method of acknowledging each data packet individually, this application can uniformly confirm the reception status of multiple data packets, greatly reducing the number of acknowledgments required by the slave (receiver) and improving communication efficiency. Furthermore, if any anomalies are found during the check, the host only needs to send the data packets recorded in the retransmitted data packet list to the slave, thus avoiding retransmitting all data packets, reducing communication overhead, and improving communication efficiency and performance.

[0057] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication and program execution functions, such as sensors, gateways, computers and other electronic devices.

[0058] Based on this, embodiments of this application provide a communication method, referring to... Figure 1 This is a flowchart illustrating the first embodiment of the communication method of this application. It is applied to the host end, where communication is performed between the host end and the slave end. It should be noted that in this embodiment, the implementing entity of the above communication method can be the host end. The host end and slave end are mainly distinguished as the data sender and the data receiver. For example, in an industrial IoT application scenario, when an industrial sensor uploads collected data to a gateway, the industrial sensor is the host end, and the gateway is the slave end. When the gateway sends data to another device, the gateway can act as the host end, and the other device can act as the slave end. That is, for a given device, based on the different data transmission paths, it can act as either the host end or the slave end. The communication method includes the following steps S10 to S30:

[0059] Step S10: Generate each data packet to be sent, and send the number of packets and each data packet to the slave device.

[0060] For example, during communication, the host can first divide the data block to be sent into smaller data segments, and then generate data packets to be sent based on these segments. For instance, frame headers and trailers can be added to both ends of the data segments to form data packets. Additionally, to facilitate packet location, index numbers can be inserted into the data packets. The specific content of the data packets can be set by technical personnel according to actual needs, and will not be elaborated here. After generating each data packet, the host sends the number of data packets to be sent to the slave, i.e., the packet count mentioned above. In one feasible implementation, the host can send each data packet to the slave sequentially according to the index number in each data packet. It should be noted that the slave stores the received data packets in a buffer. Therefore, the number of packets sent by the host can be used as a basis for the slave to determine the required buffer size; the more packets, the larger the buffer. Furthermore, the packet count can also be used by the slave to check for packet loss.

[0061] Step S20: After each data packet is sent, a transmission end command is sent to the slave device. The transmission end command is used to instruct the slave device to check the received data packets based on the number of packets.

[0062] For example, after the host sends all the data packets, it can send a transmission end command to the slave to indicate that all data packets of the current or upcoming data block have been sent. Simultaneously, the transmission end command will also instruct the slave to check the received data packets based on the number of packets received. For instance, if the number of data packets actually received by the slave is less than the total number of packets, it can be determined that some data packets have been lost, indicating an abnormal result in the check.

[0063] Step S30: Receive the retransmission data packet list sent by the slave device. If the retransmission data packet list contains data packets, retransmit the data packets recorded in the retransmission data packet list to the slave device. The detected anomaly results are used to construct the retransmission data packet list.

[0064] For example, the host can receive a list of retransmitted data packets from the slave. It's important to note that an empty retransmitted data packet list indicates that the data packets received by the slave are all correct. Conversely, if the retransmitted data packet list is not empty, it means that the data packets received by the slave have problems. Accordingly, the host needs to retransmit the data packets recorded in the list. The retransmitted data packet list can record any lost or erroneous data packets detected. After receiving the retransmitted data packet list, the host only needs to send the data packets recorded in the list to the slave, thus avoiding the host sending all data packets and improving communication efficiency.

[0065] Understandably, in this embodiment, the host generates data packets to be sent, sends the packet count and the data packets themselves to the slave. After the data packets are sent, a transmission end command is sent to the slave, instructing the slave to check the received data packets based on the packet count. Upon receiving a retransmission data packet list from the slave, if data packets are recorded in the retransmission data packet list, the data packets recorded in the retransmission data packet list are retransmitted to the slave. The detected anomalies are used to construct the retransmission data packet list. That is, during data communication between the host and slave, the host sends multiple data packets to the slave, and the slave can uniformly check the received data packets before sending the retransmission data packet list back to the host. Compared to the traditional method of confirming each data packet individually, this application can uniformly confirm the reception status of multiple data packets, greatly reducing the number of confirmations required from the slave (receiver) and improving communication efficiency. Meanwhile, if an anomaly is detected, the host only needs to send the data packets recorded in the retransmission data packet list to the slave, thereby avoiding retransmitting all data packets, reducing communication overhead, and improving communication efficiency and performance.

[0066] Alternatively, in one feasible approach, each data packet includes an index number, with different index numbers for different data packets. Correspondingly, the retransmission data packet list can record the index numbers of lost or erroneous data packets, allowing the host to retransmit the data packets based on the index numbers.

[0067] Reference Figure 2 This is a flowchart illustrating the second embodiment based on the first embodiment of this application. In this embodiment, content that is the same as or identical to that in the above embodiments can be referred to the above embodiments, and will not be repeated here. The communication method further includes steps S01 to S02:

[0068] Step S01: Send the master communication parameters to the slave device;

[0069] Step S02: Receive the negotiated communication parameters determined by the slave device based on the master communication parameters and the slave communication parameters;

[0070] The step of generating each data packet to be sent includes step S11:

[0071] Step S11: Divide the data block to be sent into data segments based on the negotiated communication parameters, and generate data packets according to each data segment.

[0072] It should be noted that in traditional communication schemes, the communication parameters between devices are mostly static (i.e., fixed). This strategy can lead to resource waste or transmission failures to some extent. Therefore, in this embodiment, a negotiation approach will be adopted, with the host and slave devices jointly deciding on appropriate communication parameters to ensure transmission stability and avoid resource waste.

[0073] For example, the host sends host communication parameters to the slave. Similarly, host communication parameters can include various parameters, such as MTU (Maximum Transmission Unit), maximum transmission rate, and buffer capacity. After receiving the host communication parameters, the slave can combine them with its own communication parameters (i.e., slave communication parameters) to determine the negotiated communication parameters. The value of any parameter in the negotiated communication parameters can be equal to or less than the host communication parameters or the smallest value of that parameter among the host communication parameters. For example, if the parameter is MTU, and the MTU in the host communication parameters is 1500B, while the MTU in the slave communication parameters is 800B, the slave communication parameters have the smallest MTU. Therefore, the MTU in the negotiated communication parameters can be selected as 800B or less. Similarly, the parameters for other items can be referenced in the above example and will not be elaborated upon here.

[0074] The host then receives the negotiation communication parameters sent by the slave. When generating the data packets to be sent, the host can generate the data packets according to the negotiation communication parameters. For example, the host can determine the size of the data segments into which the data block is divided based on the MTU in the negotiation communication parameters; generally, the larger the MTU, the larger the data segment. Finally, corresponding frame headers and trailers are added to both ends of the data segment, and index sequence numbers, checksums, etc., are inserted to form the data packet. In one feasible implementation, the frame structure of a data packet is as follows:

[0075] |Frame header (2B)|Index (4B)|Data (variable length)|CRC (2B)|MoreData (1B)|Frame tail (2B)|

[0076] In the above structure, Index represents the index number, Data represents the data (such as a data segment), and CRC (Cyclic Redundancy Check) represents the checksum. MoreData is a flag bit (an optional field that can be omitted from the data packet). A value of 1 for MoreData indicates that the current data packet and the next data packet belong to the same data block, while a value of 0 indicates that the current data packet and the next data packet belong to different data blocks. It should be noted that the frame structure described above does not restrict the data packets. In practical applications, technicians can adjust the field content in the data packets according to actual needs.

[0077] In one feasible implementation, the communication method further includes steps S1 to S2:

[0078] Step S1: If the first available device resource used by the host to communicate with the slave is updated, new host communication parameters are generated based on the new first available device resource, wherein the parameter value of the host communication parameter increases as the first available device resource increases;

[0079] Step S2: Based on the new host communication parameters, return to the step of sending host communication parameters to the slave.

[0080] It should be noted that during the communication process, the host and slave can also negotiate communication parameters in real time.

[0081] For example, in practical applications, the host device, in addition to communication functions, also undertakes other non-communication functions, such as data acquisition by sensors. When performing these non-communication functions, the host device also requires its own resources. When the application scenario on the host device changes, the resource allocation rules configured on the host device may reallocate available resources for communication with the slave device, i.e., the aforementioned first available device resources. Correspondingly, if the first available device resources are updated, it indicates that the host device may need to configure new host communication parameters. Accordingly, new host communication parameters are generated based on the updated first available device resources, i.e., the new first available device resources. The generation of new host communication parameters can be achieved by calculating the host communication parameters using a preset formula or by determining the new host communication parameters according to a preset mapping table. The specific generation process is not detailed here, but it is sufficient to ensure that the parameter values ​​of the host communication parameters increase with the increase of the first available device resources. For example, the first available device resources may include channel bandwidth; if the channel bandwidth increases, the parameter values ​​of the maximum transmission unit and the maximum transmission rate in the host communication parameters can also increase. After obtaining the new host communication parameters, the step of sending the host communication parameters to the slave is returned to be executed based on the new host communication parameters, thereby re-determining the new negotiated communication parameters and ensuring the real-time nature of the negotiated communication parameters.

[0082] Referring to Figure 3, it is a flowchart illustrating a third embodiment based on the first and second embodiments of this application. In this embodiment, content that is the same as or identical to that in the above embodiments can be referred to the above embodiments, and will not be repeated here. The communication method is applied to the slave device, which communicates with the master device. The communication method includes the following steps A10 to A30:

[0083] Step A10: Receive the number of packets and each packet from the host, and store the received packets in the buffer.

[0084] Step A20: After receiving the transmission end instruction sent by the host, check the received data packets in the buffer based on the packet count;

[0085] Step A30: If abnormal results are found, send a list of retransmission data packets constructed based on the abnormal results to the host, and receive the data packets recorded in the list of retransmission data packets sent by the host.

[0086] It should be noted that, in this embodiment, the entity executing the above communication method can be a slave device.

[0087] For example, the slave device receives the packet count and each data packet from the master device. The packet count represents the theoretically expected number of data packets to be received. Since the slave device needs to buffer the data packets, it can estimate the required buffer size based on the packet count to allocate buffer space. After allocating buffer space, the slave device then stores the received data packets in the buffer.

[0088] Furthermore, after receiving the transmission end command from the master, the slave can uniformly check the received data packets in the buffer based on the packet count. For example, if the number of received data packets in the buffer is less than the packet count, it indicates that data packets have been lost. It is worth noting that each data packet carries an index sequence number; therefore, the lost data packets can be identified by the continuity of the index sequence numbers, facilitating the construction of a retransmission data packet list (it should be noted that if there are no lost or erroneous data packets, the slave can construct an empty retransmission data packet list). Correspondingly, if an anomaly is found, the slave can send a retransmission data packet list constructed based on the anomaly (if the anomaly includes lost data packets, the index sequence numbers of the lost data packets are added to the list), so that the master can selectively retransmit the data packets that need to be retransmitted, and the slave can then receive the data packets.

[0089] In this embodiment, when the host and slave communicate, the host sends multiple data packets to the slave. After all data packets are sent, the slave checks the received data packets and sends a list of retransmitted data packets to the host. Compared to the traditional method of confirming each data packet individually, this application can confirm the reception status of multiple data packets uniformly, greatly reducing the number of confirmations required by the slave (receiver) and improving communication efficiency. Furthermore, if abnormal results are found, the slave also sends a list of retransmitted data packets based on the abnormal results to the host. This allows the host to send only the data packets recorded in the retransmitted data packet list to the slave, avoiding retransmitting all data packets, reducing communication overhead, and improving communication efficiency and performance.

[0090] In one feasible implementation, the step of checking the received data packets in the buffer based on the number of packets includes steps A21 to A22:

[0091] Step A21: Generate an anomaly result based on the difference between the number of packets and the maximum index sequence number of the received data packets in the buffer.

[0092] Step A22: Based on the abnormal results and the detection results of the received data packets in the buffer, the lost data packets are determined and recorded in the retransmission data packet list. The detection results are obtained by performing a continuity check on the index sequence numbers of each received data packet.

[0093] For example, the types of data packets in the retransmission data packet list can include lost data packets. The above checks can include confirming lost data packets. For the number of packets, the maximum index sequence number in the received data packets can be compared with the number of packets. If a difference is found, the lost tail data packets, i.e., the abnormal result, can be determined through the difference. Alternatively, the index sequence numbers in each received data packet can be counted, and the continuity of the index sequence numbers can be checked. The missing positions are the lost data packets, i.e., the detection result. Combining the abnormal result and the detection result, all lost data packets can be obtained, and then the lost data packets can be recorded in the retransmission data packet list.

[0094] In one feasible implementation, the data packet types in the data packet list also include erroneous data packets, and the communication method further includes steps A201 to A202:

[0095] Step A201: For any received data packet in the buffer, perform an integrity check on the received data packet based on the checksum in the received data packet;

[0096] Step A202: If there are received data packets in the buffer that have failed integrity verification, the received data packets that have failed integrity verification are recorded as erroneous data packets and recorded in the retransmission data packet list.

[0097] For example, the data packet types in the data packet list also include error data packets. That is, each data packet can carry a CRC checksum for data packet integrity verification. For any received data packet in the buffer, the checksum, such as the CRC in the frame structure mentioned above, is extracted from the received data packet. Then, the integrity of the received data packet is verified based on the extracted checksum. Specifically, the verification process can refer to existing solutions, which will not be elaborated here. This step is repeated to verify the integrity of each received data packet in the buffer. If there are received data packets in the buffer that fail integrity verification, these failed data packets can be treated as error data packets and added to the retransmission data packet list to construct the retransmission data packet list. Furthermore, if it is determined that there are no lost data packets and the integrity verification of each data packet is successful, a blank retransmission data packet list is constructed. Alternatively, a comprehensive integrity verification is performed based on the combined data packets, and a blank retransmission data packet list is constructed only after the comprehensive integrity verification is successful.

[0098] It is understood that the embodiments of this application use a complete verification method to identify lost data packets and erroneous data packets, and generate a retransmission data packet list (the retransmission data packet list can record the index sequence number of lost data packets and erroneous data packets), so that the host can retransmit data packets in a targeted manner and improve communication efficiency.

[0099] Reference Figure 4 This is a flowchart illustrating the fourth embodiment proposed based on the first, second, and third embodiments of this application. Content that is the same as or identical to the above embodiments can be referred to in the above embodiments, and will not be repeated here. The communication method further includes steps A01 to A03:

[0100] Step A01: Receive host communication parameters sent by the host terminal;

[0101] Step A02: Determine the negotiated communication parameters based on the host communication parameters and the slave communication parameters, wherein the parameter value of the negotiated communication parameters is less than or equal to the minimum parameter value among the host communication parameters and the slave communication parameters;

[0102] Step A03: Send the negotiated communication parameters to the host.

[0103] For example, the slave device receives the host communication parameters sent by the master device. It then combines these with its own slave communication parameters to determine negotiated communication parameters. The determination rule is that the negotiated communication parameters can simultaneously satisfy the parameter restrictions of both the master and slave devices. Therefore, the determined negotiated communication parameter values ​​are less than or equal to the minimum value among the host communication parameters and the slave communication parameters. For example, the value of any parameter in the negotiated communication parameters can be equal to or less than the minimum value among the host communication parameters and the minimum value of that parameter. After determining the negotiated communication parameters, the slave device can then send them to the master device.

[0104] In one feasible implementation, the communication method further includes steps A1 to A2:

[0105] Step A1: If the second available device resource used by the slave device to communicate with the master device is updated, new slave communication parameters are generated based on the new second available device resource.

[0106] Step A2: Based on the new slave communication parameters, return to the step of determining the negotiated communication parameters based on the master communication parameters and the slave communication parameters of the slave end.

[0107] For example, the host and slave devices can negotiate communication parameters in real time. Besides communication functions, the slave device also undertakes other non-communication functions. When performing these non-communication functions, the slave device also needs to utilize its own device resources. When the application scenario of the slave device changes, according to the resource allocation rules configured on the slave device, available resources for communication with the host device may be reallocated, i.e., the aforementioned second available device resources. Correspondingly, if the second available device resources are updated, it indicates that the slave device may need to configure new slave communication parameters. Accordingly, new slave communication parameters are generated based on the updated second available device resources, i.e., the new second available device resources. The generation of new slave communication parameters can be achieved using a preset calculation formula or by determining slave communication parameters according to a preset mapping table. The specific generation process is not detailed here, but it is sufficient to ensure that the parameter values ​​of the slave communication parameters increase with the increase of the second available device resources. For example, the second available device resource may include channel bandwidth. If the channel bandwidth increases, the parameter values ​​of the maximum transmission unit and the maximum transmission rate in the slave communication parameters can also increase. After obtaining the new slave communication parameters, the step of sending the master communication parameters to the slave is executed again based on the new master communication parameters, thereby re-determining the negotiated communication parameters and ensuring the real-time nature of the negotiated communication parameters.

[0108] Reference Figure 5The diagram below is a structural schematic of a communication system in an embodiment of this application. The communication system includes:

[0109] The host terminal 10 is used to generate each data packet to be sent, send the number of packets of each data packet and each data packet to the slave terminal; after the data packets are sent, send a transmission end command to the slave terminal; and receive the retransmission data packet list of each data packet sent by the slave terminal.

[0110] Slave terminal 20 is used to receive the number of packets and the data packets of each data packet, and store the received data packets in a buffer area; after receiving a transmission end instruction, it checks the received data packets in the buffer area based on the number of packets; if there is an abnormal result in the check, it sends a retransmission data packet list constructed based on the abnormal result to the host terminal, and receives the data packets recorded in the retransmission data packet list sent by the host terminal.

[0111] Optionally, the host terminal 10 is further configured to:

[0112] Send master communication parameters to the slave device;

[0113] Receive the negotiated communication parameters determined by the slave device based on the master device communication parameters and the slave device communication parameters;

[0114] The generation of each data packet to be sent includes:

[0115] Based on the negotiated communication parameters, the data block to be sent is divided into data segments, and data packets are generated according to each data segment.

[0116] Optionally, the host terminal 10 is further configured to:

[0117] If the first available device resource used by the host to communicate with the slave is updated, new host communication parameters are generated based on the new first available device resource, wherein the parameter value of the host communication parameter increases as the first available device resource increases;

[0118] Based on the new host communication parameters, return to the step of sending host communication parameters to the slave.

[0119] Optionally, the slave device 20 is further configured to:

[0120] Receive host communication parameters sent by the host terminal;

[0121] The negotiated communication parameters are determined based on the host communication parameters and the slave communication parameters, wherein the parameter value of the negotiated communication parameters is less than or equal to the minimum parameter value among the host communication parameters and the slave communication parameters;

[0122] The negotiated communication parameters are sent to the host.

[0123] Optionally, the slave device 20 is further configured to:

[0124] If the second available device resource used by the slave device to communicate with the master device is updated, new slave communication parameters are generated based on the new second available device resource;

[0125] Based on the new slave communication parameters, return to the step of determining the negotiated communication parameters based on the master communication parameters and the slave communication parameters of the slave end.

[0126] Optionally, the slave device 20 is further configured to:

[0127] An anomaly result is generated based on the difference between the number of packets and the maximum index sequence number of the received data packets in the buffer.

[0128] Based on the abnormal results and the detection results of the received data packets in the buffer, the lost data packets are determined and recorded in the retransmission data packet list. The detection results are obtained by performing a continuous detection on the index sequence number of each received data packet.

[0129] Optionally, the data packet types in the retransmission data packet list also include erroneous data packets. Optionally, the slave device 20 is also used for:

[0130] For any received data packet in the buffer, perform an integrity check on the received data packet based on the checksum in the received data packet;

[0131] If a received data packet that failed integrity verification exists in the buffer, the received data packet that failed integrity verification is treated as an erroneous data packet and recorded in the retransmission data packet list.

[0132] The communication system provided by this invention, employing the communication method described in the above embodiments, solves the technical problem that the traditional ACK mechanism reduces communication performance. Compared with the prior art, the beneficial effects of the communication system provided by the embodiments of this invention are the same as those of the communication method provided in the above embodiments, and other technical features of this communication system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0133] This application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the communication method in Embodiment 1 above.

[0134] The following is for reference. Figure 6 The diagram illustrates a structural schematic suitable for implementing the electronic device in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, mobile terminals such as computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as computers. Figure 6 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0135] like Figure 6 As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processor, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory ROM 1002 or a program loaded from a storage device 1003 into a random access memory RAM 1004. The RAM 1004 also stores various programs and data required for vehicle operation. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication systems 1009. Communication system 1009 allows the vehicle to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows a vehicle with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0136] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication system, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0137] The vehicle provided in this application, employing the communication method described in the above embodiments, can solve the technical problem that the traditional ACK mechanism reduces communication performance. Compared with the prior art, the beneficial effects of the vehicle provided in this application are the same as those of the communication method provided in the above embodiments, and other technical features of the vehicle are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0138] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0139] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0140] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the communication method in the above embodiments.

[0141] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0142] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0143] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by an electronic device, cause the electronic device to:

[0144] Generate each data packet to be sent, and send the packet count and each data packet to the slave device; after each data packet is sent, send a transmission end command to the slave device, wherein the transmission end command is used to instruct the slave device to check the received data packets based on the packet count; receive the retransmission data packet list sent by the slave device, and if there are data packets recorded in the retransmission data packet list, retransmit the data packets recorded in the retransmission data packet list to the slave device, wherein the abnormal results detected are used to construct the retransmission data packet list.

[0145] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0146] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0147] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0148] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described communication method, thereby solving the technical problem that traditional ACK mechanisms reduce communication performance. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the communication method provided in the above embodiments, and will not be repeated here.

[0149] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the communication method described above.

[0150] The computer program product provided in this application can solve the technical problem of communication. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the communication method provided in the above embodiments, and will not be repeated here.

[0151] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A communication method, characterized in that, Applied to the host side, the host side communicates with the slave side, and the communication method includes the following steps: Generate each data packet to be sent, and send the number of packets and each data packet to the slave device; After each data packet is sent, a transmission end command is sent to the slave device, wherein the transmission end command is used to instruct the slave device to check the received data packets based on the number of packets; Upon receiving the retransmission data packet list sent by the slave device, if a data packet is recorded in the retransmission data packet list, the data packet recorded in the retransmission data packet list is retransmitted to the slave device, wherein the detected abnormal results are used to construct the retransmission data packet list.

2. The communication method as described in claim 1, characterized in that, The communication method further includes: Send master communication parameters to the slave device; Receive the negotiated communication parameters determined by the slave device based on the master device communication parameters and the slave device communication parameters; The steps for generating the data packets to be sent include: Based on the negotiated communication parameters, the data block to be sent is divided into data segments, and data packets are generated according to each data segment.

3. The communication method as described in claim 2, characterized in that, The communication method further includes: If the first available device resource used by the host to communicate with the slave is updated, new host communication parameters are generated based on the new first available device resource, wherein the parameter value of the host communication parameter increases as the first available device resource increases; Based on the new host communication parameters, return to the step of sending host communication parameters to the slave.

4. A communication method, characterized in that, Applied to the slave device, the slave device communicates with the master device, and the communication method includes the following steps: Receive the number of packets and each data packet sent by the host, and store the received data packets in the buffer area; After receiving the transmission end instruction sent by the host, the received data packets in the buffer are checked based on the number of packets; If an abnormal result is found during the check, a list of retransmission data packets constructed based on the abnormal result is sent to the host, and the data packets recorded in the list of retransmission data packets sent by the host are received.

5. The communication method as described in claim 4, characterized in that, The communication method further includes: Receive host communication parameters sent by the host terminal; The negotiated communication parameters are determined based on the host communication parameters and the slave communication parameters, wherein the parameter value of the negotiated communication parameters is less than or equal to the minimum parameter value among the host communication parameters and the slave communication parameters; The negotiated communication parameters are sent to the host.

6. The communication method as described in claim 5, characterized in that, The communication method further includes: If the second available device resource used by the slave device to communicate with the master device is updated, new machine communication parameters are generated based on the new second available device resource; Based on the new slave communication parameters, return to the step of determining the negotiated communication parameters based on the master communication parameters and the slave communication parameters of the slave end.

7. The communication method as described in claim 4, characterized in that, The step of checking the received data packets in the buffer based on the number of packets includes: An anomaly result is generated based on the difference between the number of packets and the maximum index sequence number of the received data packets in the buffer. Based on the abnormal results and the detection results of the received data packets in the buffer, the lost data packets are determined and recorded in the retransmission data packet list. The detection results are obtained by performing a continuous detection on the index sequence number of each received data packet.

8. The communication method as described in claim 7, characterized in that, The communication method further includes: For any received data packet in the buffer, perform an integrity check on the received data packet based on the checksum in the received data packet; If a received data packet that failed integrity verification exists in the buffer, the received data packet that failed integrity verification is treated as an erroneous data packet and recorded in the retransmission data packet list.

9. A communication system, characterized in that, The communication system includes: The host end is used to generate each data packet to be sent, send the number of packets of each data packet and each data packet to the slave end; after the data packets are sent, send a transmission end command to the slave end; receive the retransmission data packet list sent by the slave end, and if the data packets are recorded in the retransmission data packet list, retransmit the data packets recorded in the retransmission data packet list to the slave end. The slave device receives the packet count and the packet count of each data packet, and stores the received data packets in a buffer. After receiving a transmission end command, it checks the received data packets in the buffer based on the packet count. If there is an abnormal result, it sends a retransmission data packet list based on the abnormal result to the host device, and receives the data packets recorded in the retransmission data packet list sent by the host device.

10. An electronic device, the electronic device comprising: A memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the communication method as described in claims 1 to 3 or 4 to 8.