Communication method and related device

Abstract

The invention discloses a communication method and a related device. The method and the device are applied to wireless networks supporting broadcast communication and / or multicast communication, such as a star flash network, an Internet of Vehicles and the like. The method comprises the steps that a first message is generated, a first field in the first message indicates that the type of the first message is a first type or a second type, the first type corresponds to non-reliability broadcast, the second type corresponds to reliability broadcast, or the first type corresponds to non-reliability multicast, and the second type corresponds to reliability broadcast; the second type corresponds to reliable multicast; and sending the first message to a first device. In the embodiment of the invention, the type of the first message is the first type or the second type, the first message can meet different reliability requirements, and the resource overhead is reduced.

Description

Communication method and related device Technical Field

[0001] The present application relates to the field of wireless communications, and in particular to communication methods and related devices. Background Art

[0002] Networks utilize various communication methods, including broadcast, unicast, and multicast. Broadcast can efficiently deliver messages to all devices on a given network. Numerous protocols utilize broadcast, primarily for the following purposes: initializing network configuration when no connection is established; performing on-demand routing searches before forwarding messages; and rapidly updating neighbors or the entire network when node information changes. Some network protocols also utilize broadcast to improve forwarding reliability.

[0003] Currently, broadcasts are used in many scenarios, such as network initialization and wireless mesh network construction. For example, in dynamic network topology configuration protocols, nodes use broadcasts to announce node information after powering on, ultimately establishing wireless neighbors. Another example is network address conflict detection protocols, which use broadcasts to declare the use of addresses. Different scenarios or services have different reliability requirements for broadcast communications. For example, some scenarios require guaranteed broadcast message reliability, while others do not. Therefore, a broadcast communication solution that can meet different reliability requirements is needed.

[0004] Summary of the Invention

[0005] The embodiments of the present application disclose a communication method and related devices that can meet the reliability requirements of different broadcast messages (or multicast messages).

[0006] In a first aspect, an embodiment of the present application provides a communication method, the method comprising: generating a first message, wherein a first field in the first message indicates whether the type of the first message is a first type or a second type, the first type corresponding to an unreliable broadcast, the second type corresponding to a reliable broadcast, or the first type corresponding to an unreliable multicast, and the second type corresponding to a reliable multicast; and sending the first message to a first device. The first type corresponding to an unreliable broadcast may be replaced by: the first type represents (or indicates) an unreliable broadcast. The second type corresponding to a reliable broadcast may be replaced by: the second type represents (or indicates) a reliable broadcast. The first type corresponding to an unreliable multicast may be replaced by: the first type represents (or indicates) an unreliable multicast. The second type corresponding to a reliable multicast may be replaced by: the second type represents (or indicates) a reliable multicast. The first type corresponds to an unreliable broadcast, the second type corresponds to a reliable broadcast, or the first type corresponds to an unreliable multicast, and the second type corresponds to a reliable multicast; and sending the first message to the first device may be replaced by: the reliability requirement corresponding to the first type is lower than the reliability requirement corresponding to the second type. Or it can be replaced by: a broadcast message of the first type requires (or needs) the device to perform a first operation for the received broadcast message of the first type, and a broadcast message of the second type requires (or needs) the device to perform a second operation for the received broadcast message of the second type, and the first operation is different from the second operation. The first operation and the second operation can be understood as operations to ensure the reliability of broadcast messages or multicast messages. For example, the second operation includes an operation in which the device responds to the device that sent the broadcast message (for example, replies with a response message) for the received broadcast message, and the first operation does not include an operation in which the device responds to the device that sent the broadcast message for the received broadcast message. In this application, the destination address of the broadcast message is an address that represents the broadcast within the range of the wireless network, and the destination address of the multicast message is a multicast address. The multicast address can be a multicast address divided according to any address allocation rule. In other words, the broadcast message needs to be transmitted to each node in the wireless network, and the multicast message only needs to be transmitted to specific nodes in the wireless network, such as nodes that monitor the same multicast address.

[0007] The first type and the second type correspond to different reliability requirements. If the type of the first message is the first type, the reliability of transmitting the first message by broadcasting or multicasting is low and the resource overhead is low. If the type of the first message is the second type, the reliability of transmitting the first message by broadcasting or multicasting is high and the resource overhead is high. It can be understood that the first type of message has the advantage of less resource overhead during transmission compared with the second type of message, and the second type of message has the advantage of greater reliability during transmission compared with the first type of message. The message is more reliable during transmission, and a fault in the message during transmission can be discovered more quickly. In an embodiment of the present application, the type of the first message is the first type or the second type, and the first message can meet different reliability requirements and reduce resource overhead.

[0008] In one possible implementation, the reliability broadcast is used to instruct the device to respond to the received broadcast message, the unreliability broadcast is used to instruct the device not to respond to the received broadcast message, the reliability multicast is used to instruct the device to respond to the received multicast message, and the unreliability multicast is used to instruct the device not to respond to the received multicast message.

[0009] In this implementation, reliable broadcast instructs a device to respond to a received broadcast message to confirm whether the first message was successfully received, thereby enhancing reliability. Unreliable broadcast instructs a device not to respond to a received broadcast message, thereby reducing message transmission and saving resource overhead. Reliable multicast instructs a device to respond to a received multicast message to confirm whether the first message was successfully received, thereby enhancing reliability. Unreliable multicast instructs a device not to respond to a received multicast message, thereby reducing message transmission and saving resource overhead.

[0010] In one possible implementation, the reliability broadcast requires the device to respond to the device that sent the broadcast message for the received broadcast message, the unreliability broadcast does not require the device to respond to the device that sent the broadcast message for the received broadcast message, the reliability multicast requires the device to respond to the device that sent the multicast message for the received multicast message, and the unreliability multicast does not require the device to respond to the device that sent the multicast message for the received multicast message. For example, device 1 sends a first message to device 2; if the type of the first message is the second type, then after receiving the first message, device 2 responds to device 1 for the first message (corresponding to the reliability broadcast requirement); if the type of the first message is the first type, then after receiving the first message, device 2 does not need to respond to device 1 for the first message (corresponding to the unreliability broadcast requirement).

[0011] In this implementation, reliability broadcast requires the device to respond to the device that sent the broadcast message for the received broadcast message, so as to confirm whether the first message was successfully received, which can enhance reliability. Unreliability broadcast does not require the device to respond to the device that sent the broadcast message for the received broadcast message, which can reduce the sending of messages and save resource overhead. Reliability multicast requires the device to respond to the device that sent the multicast message for the received multicast message, so as to confirm whether the first message was successfully received, which can enhance reliability. Unreliability multicast does not require the device to respond to the device that sent the multicast message for the received multicast message, which can reduce the sending of messages and save resource overhead.

[0012] In a possible implementation, the reliability requirement of the reliable broadcast on the broadcast message is higher than the reliability requirement of the unreliable broadcast on the broadcast message.

[0013] In this implementation, the type of the first message is the first type or the second type, and the first message can meet different reliability requirements.

[0014] In one possible implementation, the reliability broadcast requires the device (or node) to reply a response message to the device that sent the broadcast message for the received broadcast message, and the non-reliability broadcast does not require the device to reply a response message to the device that sent the broadcast message for the received broadcast message. It should be noted that the device that receives the broadcast message and the device that sends the broadcast message are neighboring nodes to each other, that is, the broadcast message received by the device that receives the broadcast message comes from the device that sends the broadcast message. For example, device 1 receives a first message sent by device 2. If the type of the first message is the second type (corresponding to reliability broadcast), then after receiving the first message, device 2 sends a response message to device 1 for the first message; if the type of the first message is the first type, then after receiving the first message, device 2 does not need to send a response message to device 1 for the first message.

[0015] In this implementation, reliability broadcasting requires that a device (or node) sends a response message to the device that sent the broadcast message in response to the received broadcast message, which can enhance reliability.

[0016] In one possible implementation, the first message further includes a second field. If the first field in the first message indicates that the type of the first message is the second type, the second field in the first message is used by the first device to respond. The second field in the first message being used by the first device to respond can be replaced by the second field in the first message being used by the first device to respond to the first message. Optionally, the second field in the first message is used to instruct the first device to send a response message to the first message.

[0017] In this implementation, the second field in the first message is used for the first device to respond, so as to confirm whether the first message is successfully received through the response of the first device.

[0018] In a possible implementation, the first message further includes a third field, and the third field in the first message indicates a first survival time of the first message in the network. The first survival time can be understood as the longest survival time of the first message in the network.

[0019] In this implementation, the third field in the first message indicates the first survival time of the first message in the network, so that the first messages transmitted in the network disappear at approximately the same time point, which can reduce the number of failed messages.

[0020] In a possible implementation, the first message further includes a sequence number, where the sequence number is used to indicate a sequence number of the first message.

[0021] In this implementation, the sequence number is used to indicate the sequence number of the first message, so that the device receiving the first message can use the sequence number to determine whether the first message is a duplicate message.

[0022] In one possible implementation, the first field, the second field, and the third field are included in a broadcast header. Optionally, the broadcast header also includes a reserved field and a fourth field, and the fourth field is used to indicate the type of the next header. The reserved field (or reserved field) is a field reserved for subsequent extension use, for example, initialized to 0. The fourth field is the nextheader field. Optionally, the first message also includes a basic header of the network layer. The first message may also include other extended message headers and upper layer message headers.

[0023] In this implementation, the first field, the second field, and the third field are included in the broadcast message header, which can more conveniently generate messages that meet different reliability requirements.

[0024] In one possible implementation, generating the first message includes: constructing a basic message header at the network layer, the basic message header including a source address, a destination address, and a fifth field (nextheader) pointing to a broadcast message header, the source address being the unicast address of the local node, the destination address being an address indicating broadcast within the wireless network range, such as 255.255, or the destination address being a multicast address, or the destination address being the unicast address of the node replying to the broadcast message (or multicast message); constructing the broadcast message header, the broadcast message header including the first field, the second field, and the third field; adding data (payload) after the broadcast message header to obtain the first message. Adding data (payload) after the broadcast message header to obtain the first message can be replaced by: adding one or more message headers and data (payload) after the broadcast message header to obtain the first message. Constructing the broadcast message header can be adding the broadcast message header after the basic message header.

[0025] In this implementation, messages that meet different reliability requirements can be constructed.

[0026] In one possible implementation, the method further includes: receiving a second message in response to the first message, wherein a first field in the second message indicates that the type of the second message is the second type, and a second field in the second message indicates that the first device successfully received the first message. Optionally, after receiving the second message in response to the first message, deleting the first message from a transmit queue of the first device to avoid repeatedly sending the first message to the first device.

[0027] In this implementation, the second field in the second message is used to indicate that the first device has successfully received the first message. Based on the second message, it can be accurately and quickly determined that the first device has successfully received the first message.

[0028] In one possible implementation, before receiving a second message in response to the first message, the method further includes: sending a third message as a retransmission message of the first message to the first device if no response message in response to the first message is received within a first waiting time after sending the first message.

[0029] In this implementation, a third message that is a retransmission message of the first message is sent to the first device, so as to improve the reliability of the first message.

[0030] In one possible implementation, the third field in the first message indicates a first survival time of the first message within the network, and the third field in the third message indicates a second survival time of the first message within the network, where the second survival time is shorter than or equal to the first survival time. Optionally, the second survival time is equal to the first survival time minus the first waiting time.

[0031] In this implementation, the second survival time is shorter than or equal to the first survival time, so that the first messages transmitted in the network disappear at approximately the same time point, thereby reducing the transmission of invalid messages in the network.

[0032] In one possible implementation, the third field in the first message indicates a first survival time of the first message within the network; the method further includes: if no response message to the first message is received within a first waiting time after sending the first message, determining a fifth survival time, the fifth survival time being equal to the first survival time minus the first waiting time; and if the fifth survival time is less than 0, stopping retransmission of the first message. Optionally, the first message is deleted from a transmission queue of the first device to avoid retransmission of the first message to the first device.

[0033] When retransmitting a message, note that the first alivetime must be deducted from the local waiting time (e.g., the first waiting time) accordingly; if the deduction is insufficient, that is, the fifth alivetime is less than 0, then retransmission is stopped and the first message is deleted from the sending queue of the first device.

[0034] In this implementation, the number of messages with failed retransmissions can be reduced.

[0035] In one possible implementation, the first waiting time is determined using an exponential backoff method. The first waiting time can be understood as a retransmission interval. The retransmission interval needs to take into account the backoff time. To reduce excessive transmission by the sender, an exponential backoff method can be used.

[0036] In one possible implementation, the third field in the first message indicates a first survival time of the first message within the network; the method further includes: caching the first message in local storage; and deleting the first message after the time the first message is cached in the local storage exceeds the first survival time.

[0037] In this implementation, after the time the first message is cached and stored locally exceeds the first survival time, the first message is deleted; thus, occupied cache resources can be released in a timely manner.

[0038] In one possible implementation, the method is applied to network services and applications such as network initialization, mesh network construction, address conflict detection, and service query. The method provided in the embodiment of the present application is applicable to any scenario where messages are transmitted via broadcast or multicast.

[0039] In this implementation, the first message is transmitted in a broadcast or multicast manner, which can meet the reliability requirements of different scenarios or services.

[0040] In the second aspect, an embodiment of the present application provides another communication method, which is applied to a first device, and the method includes: receiving a first message from a second device, wherein the first field in the first message indicates that the type of the first message is the first type or the second type, the first type corresponds to a non-reliability broadcast, and the second type corresponds to a reliability broadcast, or the first type corresponds to a non-reliability multicast, and the second type corresponds to a reliability multicast; processing the first message according to the type of the first message. For the description of the first type, the second type, the non-reliability broadcast, the non-reliability broadcast, the non-reliability multicast, and the reliability multicast in the second aspect, please refer to the relevant description in the first aspect, which will not be repeated here.

[0041] The first type and the second type correspond to different reliability requirements. If the type of the first message is the first type, the reliability of transmitting the first message by broadcasting or multicasting is low and the resource overhead is low. If the type of the first message is the second type, the reliability of transmitting the first message by broadcasting or multicasting is high and the resource overhead is high. It can be understood that the first type of message has the advantage of less resource overhead during transmission compared with the second type of message, and the second type of message has the advantage of greater reliability during transmission compared with the first type of message. The message is more reliable during transmission, and faults in the message during transmission can be discovered more quickly. In an embodiment of the present application, the first field in the first message indicates whether the type of the first message is the first type or the second type. The first message is processed according to the type of the first message; the reliability requirements of different types of messages can be met and resource overhead can be reduced.

[0042] In one possible implementation, the reliability broadcast is used to instruct the device to respond to the received broadcast message, the unreliability broadcast is used to instruct the device not to respond to the received broadcast message, the reliability multicast is used to instruct the device to respond to the received multicast message, and the unreliability multicast is used to instruct the device not to respond to the received multicast message.

[0043] In this implementation, reliable broadcast instructs a device to respond to a received broadcast message to confirm whether the first message was successfully received, thereby enhancing reliability. Unreliable broadcast instructs a device not to respond to a received broadcast message, thereby reducing message transmission and saving resource overhead. Reliable multicast instructs a device to respond to a received multicast message to confirm whether the first message was successfully received, thereby enhancing reliability. Unreliable multicast instructs a device not to respond to a received multicast message, thereby reducing message transmission and saving resource overhead.

[0044] In one possible implementation, the reliability broadcast requires the device to respond to the device that sends the broadcast message for the received broadcast message, the unreliability broadcast does not require the device to respond to the device that sends the broadcast message for the received broadcast message, the reliability multicast requires the device to respond to the device that sends the multicast message for the received multicast message, and the unreliability multicast does not require the device to respond to the device that sends the multicast message for the received multicast message.

[0045] In this implementation, reliability broadcast requires the device to respond to the device that sent the broadcast message for the received broadcast message, so as to confirm whether the first message was successfully received, which can enhance reliability. Unreliability broadcast does not require the device to respond to the device that sent the broadcast message for the received broadcast message, which can reduce the sending of messages and save resource overhead. Reliability multicast requires the device to respond to the device that sent the multicast message for the received multicast message, so as to confirm whether the first message was successfully received, which can enhance reliability. Unreliability multicast does not require the device to respond to the device that sent the multicast message for the received multicast message, which can reduce the sending of messages and save resource overhead.

[0046] In a possible implementation, the reliability requirement of the reliable broadcast on the broadcast message is higher than the reliability requirement of the unreliable broadcast on the broadcast message.

[0047] In this implementation, the type of the first message is the first type or the second type, and the first message can meet different reliability requirements.

[0048] In one possible implementation, the reliability broadcast requires the device (or node) to reply with a response message to the device that sent the broadcast message for the received broadcast message, and the unreliability broadcast does not require the device to reply with a response message to the device that sent the broadcast message for the received broadcast message.

[0049] In this implementation, reliability broadcasting requires that a device (or node) sends a response message to the device that sent the broadcast message in response to the received broadcast message, which can enhance the reliability of the broadcast message.

[0050] In one possible implementation, the first message further includes a second field. If the first field in the first message indicates that the type of the first message is the second type, the second field in the first message is used by the first device to respond. The second field in the first message being used by the first device to respond can be replaced by the second field in the first message being used by the first device to respond to the first message. Optionally, the second field in the first message is used to instruct the first device to send a response message to the first message.

[0051] In this implementation, the second field in the first message is used for the first device to respond, so as to confirm whether the first message is successfully received through the response of the first device.

[0052] In a possible implementation, the first message further includes a third field, and the third field in the first message indicates a first survival time of the first message in the network.

[0053] In this implementation, the third field in the first message indicates the first survival time of the first message in the network, so that the first messages transmitted in the network die at approximately the same time point, which can reduce the number of failed messages transmitted in the network.

[0054] In a possible implementation, the first message further includes a sequence number, where the sequence number is used to indicate a sequence number of the first message.

[0055] In this implementation, the sequence number is used to indicate the sequence number of the first message, so that the device receiving the first message can use the sequence number to determine whether the first message is a repeated message.

[0056] In one possible implementation, the first field, the second field, and the third field are included in a broadcast header. Optionally, the broadcast header also includes a reserved field and a fourth field, and the fourth field is used to indicate the type of the next header. The reserved field (or reserved field) is a field reserved for subsequent extension use, for example, initialized to 0. The fourth field is the nextheader field. Optionally, the first message also includes a basic header of the network layer. The first message may also include other extended message headers and upper layer message headers.

[0057] In this implementation, the first field, the second field, and the third field are included in the broadcast message header, which can more conveniently generate messages that meet different reliability requirements.

[0058] In one possible implementation, the processing of the first message according to the type of the first message includes: when the type of the first message is the second type, sending a second message in response to the first message to the second device, and adding the first message to the message sending queue of the first neighbor node, the first field in the second message indicates that the type of the second message is the second type, and the second field in the second message is used to indicate that the first device has successfully received the first message.

[0059] In this implementation, when the type of the first message is the second type, a second message in response to the first message is sent to the second device, thereby improving the reliability of the first message by indicating that the first device has successfully received the first message.

[0060] In one possible implementation, after adding the first message to the message sending queue of the first neighbor node, the method further includes: sending the first message to the first neighbor node; after receiving a fourth message in response to the first message from the first neighbor node, deleting the first message from the message sending queue of the first neighbor node, the first field in the fourth message indicates that the type of the fourth message is the second type, and the second field in the fourth message is used to indicate that the first neighbor node successfully received the first message.

[0061] In this implementation, after receiving the fourth message in response to the first message from the first neighbor node, the first message is deleted from the message sending queue of the first neighbor node; this can avoid repeatedly sending the second message to the first neighbor node that successfully received the first message.

[0062] In one possible implementation, a third field in the first message sent to the first neighboring node indicates a third survival time of the first message within the network, and a third field in the first message from the second device indicates a first survival time of the first message within the network, where the third survival time is shorter than or equal to the first survival time. Optionally, the third survival time is equal to the first survival time minus a local processing time, where the local processing time is the time taken by the first device to process the first message.

[0063] In this implementation, the third survival time is shorter than or equal to the first survival time, so that the first messages transmitted in the network disappear at approximately the same time point, thereby reducing the transmission of invalid messages in the network.

[0064] In one possible implementation, before receiving a fourth message in response to the first message from the first neighboring node, the method further includes: in a case where no response message in response to the first message from the first neighboring node is received within a first waiting time after sending the first message to the first neighboring node, sending a fifth message as a retransmission message of the first message to the first neighboring node. Optionally, the survival time of the fifth message in the network indicated by the third field in the fifth message is shorter than or equal to the survival time of the first message in the network indicated by the third field in the first message sent by the first device to the first neighboring node. For example, the survival time of the fifth message in the network indicated by the third field in the fifth message is equal to the survival time of the first message in the network indicated by the third field in the first message sent by the first device to the first neighboring node minus the first waiting time.

[0065] In this implementation, the fifth message, which is a retransmission message of the first message, is sent to the first neighbor node, so as to improve the reliability of the first message.

[0066] In one possible implementation, the second type corresponds to reliability multicast, and the destination address in the first message is a multicast address; the method also includes: when monitoring the multicast address in the first message, sending the first message to the control plane program or application for processing, and forwarding the first message to the first neighbor node; when not monitoring the multicast address in the first message, forwarding the first message to the first neighbor node.

[0067] In this implementation, corresponding processing is performed according to whether the multicast address in the first message is monitored, and the monitored multicast message can be sent to the control plane program or application for processing, and the multicast message that the user does not care about can be forwarded.

[0068] In one possible implementation, the processing of the first message according to the type of the first message includes: when the type of the first message is the first type, adding the first message to the message sending queue of the first neighbor node; sending the first message to the first neighbor node, wherein the third field in the first message sent to the first neighbor node indicates the third survival time of the first message in the network, and the third field in the first message from the second device indicates the first survival time of the first message in the network, and the third survival time is shorter than or equal to the first survival time.

[0069] In this implementation, the third survival time is shorter than or equal to the first survival time, so that the first messages transmitted in the network disappear at approximately the same time point, thereby reducing the transmission of invalid messages in the network.

[0070] In one possible implementation, the processing of the first message according to the type of the first message includes: when the type of the first message is the first type, adding the first message to the message sending queue of the first neighbor node; before sending the first message to the first neighbor node, determining a sixth survival time, the sixth survival time being equal to the first survival time minus the local processing time, the local processing time being the time taken by the first device to process the first message; when the sixth survival time is less than 0, canceling sending the first message to the first neighbor node.

[0071] In this implementation, when the sixth survival time is less than 0, the sending of the first message to the first neighbor node is canceled; the sending of failed first messages can be reduced.

[0072] In one possible implementation, the third field in the first message from the second device indicates the first survival time of the first message within the network; the method also includes: caching the first message in local storage; and deleting the first message after the time the first message is cached in the local storage exceeds the first survival time.

[0073] In this implementation, after the time the first message is cached and stored locally exceeds the first survival time, the first message is deleted; thus, occupied cache resources can be released in a timely manner.

[0074] In a possible implementation, the method further includes: in the process of caching the first message in the local storage, if a new neighbor node is found, adding the first message to a sending queue of the new neighbor node.

[0075] In this implementation, the first message may be forwarded to the new neighbor node.

[0076] In a possible implementation, the method further includes: locally caching the summary information of the first message for a fourth survival time, where the fourth survival time is longer than the first survival time.

[0077] Taking into account that the clocks of various devices in the network may not be synchronized, the timing of aging of the first message on different devices is uncontrollable. The purpose of locally caching the summary information of the first message longer than the local cache time of the first message is to avoid the problem that after the first message ages, when the first message is received from other neighbors, it is impossible to determine whether the first message is a duplicate. The extraction of the summary information of the message is a local behavior, for example, using the index representation of the message (source address + sequence number), that is, the source address + sequence number. In this implementation method, the fourth survival time is longer than the first survival time, which can avoid the problem that after the first message ages, when the first message is received from other neighbors, it is impossible to determine whether the first message is a duplicate.

[0078] In one possible implementation, before processing the first message according to the type of the first message, the method further includes: determining whether the first message is a duplicate message based on the source address and sequence number in the first message; the processing of the first message according to the type of the first message includes: in the case where the first message is a new message (i.e., a non-duplicate message), processing the first message according to the type of the first message. Optionally, the combination of the source address and sequence number in the first message is used as the index of the first message; whether the first message is a duplicate message is determined by searching whether the combination of the source address and sequence number in the first message is cached locally. After receiving an arbitrary message, the first device may cache the arbitrary message and the index of the arbitrary message, i.e., the combination of the source address and sequence number in the arbitrary message.

[0079] In this implementation, when the first message is a new message (ie, a non-duplicate message), the first message is processed according to the type of the first message; by avoiding repeated processing of the first message, resource overhead can be reduced.

[0080] In a third aspect, an embodiment of the present application provides a communication device, which has the function of implementing the behavior in the method embodiment of the first aspect above. The communication device can be a communication device, or a component of a communication device (such as a processor, a chip, or a chip system, etc.), or a logic module or software that can implement all or part of the functions of the communication device. The functions of the communication device can be implemented by hardware, or can be implemented by hardware executing corresponding software, and the hardware or software includes one or more modules or units corresponding to the above functions. In one possible implementation, the communication device includes a processing module and a transceiver module, wherein: the processing module is used to generate a first message, the first field in the first message indicates that the type of the first message is the first type or the second type, the first type corresponds to non-reliability broadcast, the second type corresponds to reliability broadcast, or the first type corresponds to non-reliability multicast, and the second type corresponds to reliability multicast; the transceiver module is used to send the first message to the first device.

[0081] In one possible implementation, the processing module is specifically configured to construct a basic message header at the network layer, the basic message header including a source address, a destination address, and a fifth field (nextheader) pointing to a broadcast message header, the source address being the unicast address of the local node, the destination address being an address indicating broadcast within the wireless network range, such as 255.255, or the destination address being a multicast address; constructing the broadcast message header, the broadcast message header including the first field, the second field, and the third field; and adding data (payload) after the broadcast message header to obtain the first message. Adding data (payload) after the broadcast message header to obtain the first message can be replaced by adding one or more message headers and data (payload) after the broadcast message header to obtain the first message.

[0082] In one possible implementation, the transceiver module is further configured to receive a second message in response to the first message, wherein the first field in the second message indicates that the type of the second message is the second type, and the second field in the second message indicates that the first device successfully received the first message. Optionally, the processing module is further configured to delete the first message from the transmit queue of the first device after receiving the second message in response to the first message.

[0083] In a possible implementation, the transceiver module is further configured to send a third message as a retransmission message of the first message to the first device if no response message in response to the first message is received within a first waiting time after sending the first message.

[0084] In one possible implementation, the processing module is also used to determine a fifth survival time when no response message in response to the first message is received within a first waiting time after sending the first message, and the fifth survival time is equal to the first survival time minus the first waiting time; and stop retransmitting the first message when the fifth survival time is less than 0.

[0085] In one possible implementation, the third field in the first message indicates the first survival time of the first message in the network; the processing module is also used to cache the first message in local storage; after the time the first message is cached in the local storage exceeds the first survival time, the first message is deleted.

[0086] For possible implementations of the communication device of the third aspect, reference may be made to various possible implementations of the first aspect.

[0087] For the technical effects brought about by various possible implementations of the third aspect, reference may be made to the introduction to the technical effects of the first aspect or various possible implementations of the first aspect.

[0088] In a fourth aspect, an embodiment of the present application provides a communication device having the function of implementing the behavior in the method embodiment of the second aspect above. The communication device (first device) can be a communication device, or a component of a communication device (such as a processor, a chip, or a chip system, etc.), or a logic module or software that can implement all or part of the functions of the communication device. The functions of the communication device can be implemented by hardware, or by hardware executing corresponding software implementations, and the hardware or software includes one or more modules or units corresponding to the above functions. In one possible implementation, the communication device includes a processing module and a transceiver module, wherein: the transceiver module is used to receive a first message from a second device, the first field in the first message indicates that the type of the first message is the first type or the second type, the first type corresponds to non-reliability broadcast, the second type corresponds to reliability broadcast, or the first type corresponds to non-reliability multicast, and the second type corresponds to reliability multicast; the processing module is used to process the first message according to the type of the first message.

[0089] In one possible implementation, the processing module is specifically used to send a second message in response to the first message to the second device through the transceiver module when the type of the first message is the second type, and to add the first message to the message sending queue of the first neighbor node. The first field in the second message indicates that the type of the second message is the second type, and the second field in the second message is used to indicate that the first device has successfully received the first message.

[0090] In one possible implementation, the transceiver module is further used to send the first message to the first neighbor node; the processing module is further used to delete the first message from the message sending queue of the first neighbor node after receiving a fourth message in response to the first message from the first neighbor node, the first field in the fourth message indicates that the type of the fourth message is the second type, and the second field in the fourth message is used to indicate that the first neighbor node successfully received the first message.

[0091] In one possible implementation, the transceiver module is also used to send a fifth message as a retransmission message of the first message to the first neighbor node if no response message in response to the first message is received from the first neighbor node within a first waiting time after sending the first message to the first neighbor node.

[0092] In one possible implementation, the second type corresponds to reliability multicast, and the destination address in the first message is a multicast address; the processing module is also used to send the first message to the control plane program or application for processing when monitoring the multicast address in the first message, and forward the first message to the first neighbor node; when not monitoring the multicast address in the first message, forward the first message to the first neighbor node.

[0093] In one possible implementation, the processing module is specifically used to add the first message to the message sending queue of the first neighbor node when the type of the first message is the first type; the transceiver module is also used to send the first message to the first neighbor node, wherein the third field in the first message sent to the first neighbor node indicates the third survival time of the first message in the network, and the third field in the first message from the second device indicates the first survival time of the first message in the network, and the third survival time is shorter than or equal to the first survival time.

[0094] In one possible implementation, the processing module is specifically used to add the first message to the message sending queue of the first neighbor node when the type of the first message is the first type; before sending the first message to the first neighbor node, determine a sixth survival time, and the sixth survival time is equal to the first survival time minus the local processing time, and the local processing time is the time taken by the first device to process the first message; when the sixth survival time is less than 0, cancel sending the first message to the first neighbor node.

[0095] In a possible implementation, the processing module is further configured to cache the first message in local storage; and delete the first message after the time the first message is cached in the local storage exceeds the first survival time.

[0096] In a possible implementation, the processing module is further configured to, during the process of caching the first message in the local storage, if a new neighbor node is found, add the first message to a sending queue of the new neighbor node.

[0097] In one possible implementation, the processing module is also used to determine whether the first message is a duplicate message based on the source address and serial number in the first message; the processing module is specifically used to process the first message according to the type of the first message when the first message is a new message (i.e., a non-duplicate message).

[0098] Possible implementations of the communication device of the fourth aspect may refer to the various possible implementations of the second aspect.

[0099] For the technical effects brought about by various possible implementation methods of the fourth aspect, reference may be made to the introduction to the technical effects of the second aspect or various possible implementation methods of the second aspect.

[0100] In a fifth aspect, an embodiment of the present application provides another communication device, which includes a processor, which is coupled to a memory, and the memory is used to store programs or instructions. When the program or instructions are executed by the processor, the communication device executes the method shown in the above-mentioned first aspect or any possible implementation of the first aspect, or the communication device executes the method shown in the above-mentioned second aspect or any possible implementation of the second aspect.

[0101] In the embodiment of the present application, during the execution of the above method, the process of sending information (or signals) in the above method can be understood as the process of outputting information based on the instructions of the processor. When outputting information, the processor outputs the information to the transceiver so that it can be transmitted by the transceiver. After being output by the processor, the information may also need to undergo other processing before reaching the transceiver. Similarly, when the processor receives input information, the transceiver receives the information and inputs it into the processor. Furthermore, after the transceiver receives the information, the information may need to undergo other processing before being input into the processor.

[0102] For operations such as sending and / or receiving involved in the processor, unless otherwise specified, or unless they conflict with their actual functions or internal logic in the relevant descriptions, they can be generally understood as instructions output based on the processor.

[0103] During implementation, the processor may be a processor specifically configured to execute these methods, or may be a processor that executes computer instructions in a memory to execute these methods, such as a general-purpose processor. For example, the processor may also be configured to execute a program stored in a memory. When the program is executed, the communication device performs the method described in the first aspect or any possible implementation of the first aspect.

[0104] In a possible implementation, the memory is located outside the communication device. In a possible implementation, the memory is located inside the communication device.

[0105] In a possible implementation, the processor and the memory may also be integrated into one device, that is, the processor and the memory may also be integrated together.

[0106] In a possible implementation, the communication device further includes a transceiver, and the transceiver is used to receive signals or send signals.

[0107] In a sixth aspect, the present application provides another communication device, which includes a processing circuit and an interface circuit, wherein the interface circuit is used to obtain or output data; the processing circuit is used to execute the method shown in the first aspect or any possible implementation of the first aspect, or to execute the method shown in the second aspect or any possible implementation of the second aspect.

[0108] In the seventh aspect, the present application provides a computer-readable storage medium, which stores a computer program, and the computer program includes program instructions, which, when executed, enable the computer to execute the method as shown in the first aspect or any possible implementation of the first aspect, or execute the method as shown in the second aspect or any possible implementation of the second aspect.

[0109] In an eighth aspect, the present application provides a computer program product, which includes a computer program, and the computer program includes program instructions, which, when executed, enable the computer to execute the method as shown in the first aspect or any possible implementation of the first aspect, or execute the method as shown in the second aspect or any possible implementation of the second aspect.

[0110] In a ninth aspect, the present application provides a communication system, comprising the communication device described in the third aspect or any possible implementation of the third aspect, and the communication device described in the fourth aspect or any possible implementation of the fourth aspect.

[0111] In the tenth aspect, the present application provides a chip comprising a processor and a communication interface, wherein the processor reads instructions stored in a memory through the communication interface and executes a method as shown in any one of the first to sixth aspects above, or executes a method as shown in the second aspect or any possible implementation of the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0112] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the background technology, the drawings required for use in the embodiments of the present application or the background technology will be described below.

[0113] FIG1 exemplarily shows a schematic diagram of the architecture of a wireless network applicable to an embodiment of the present application;

[0114] FIG2 is an interactive flow chart of a communication method provided in an embodiment of the present application;

[0115] FIG3 is an interactive diagram of another broadcast communication method provided in an embodiment of the present application;

[0116] FIG4 is an interactive diagram of a multicast communication method provided in an embodiment of the present application;

[0117] FIG5 is an interactive diagram of another broadcast communication method provided in an embodiment of the present application;

[0118] FIG6 is an interactive diagram of another multicast communication method provided in an embodiment of the present application;

[0119] FIG7 is an example of a transmission process of a reliability broadcast provided in an embodiment of the present application;

[0120] FIG8 is an example of a reliable multicast transmission process provided in an embodiment of the present application;

[0121] FIG9 is an example of a transmission process of an unreliable broadcast provided in an embodiment of the present application;

[0122] FIG10 is an example of a non-reliable multicast transmission process provided in an embodiment of the present application;

[0123] FIG11 is a schematic structural diagram of a communication device 1100 provided in an embodiment of the present application;

[0124] FIG12 is a schematic structural diagram of another communication device 120 provided in an embodiment of the present application;

[0125] FIG13 is a schematic structural diagram of another communication device 130 provided in an embodiment of the present application. DETAILED DESCRIPTION

[0126] The terms "first" and "second," etc., in the specification, claims, and drawings of this application are used solely to distinguish between different objects and are not intended to describe a specific order. Furthermore, the terms "including," "having," and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not limited to the listed steps or elements but may optionally include steps or elements not listed, or may optionally include other steps or elements inherent to such process, method, product, or apparatus.

[0127] References to "embodiments" herein mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it refer to independent or alternative embodiments that are mutually exclusive of other embodiments. It will be understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0128] The terms used in the following embodiments of the present application are only for the purpose of describing specific embodiments and are not intended to limit the present application. As used in the specification and appended claims of the present application, the singular expressions "one", "a kind of", "said", "above", "the" and "this" are intended to also include plural expressions, unless there is a clear contrary indication in the context. It should be understood that the term "and / or" used in the present application refers to and includes any or all possible combinations of one or more listed items. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The term "multiple" used in the present application refers to two or more.

[0129] It is understood that in each embodiment of the present application, "A corresponds to B" means that there is a corresponding relationship between A and B, and B can be determined according to A. However, it should also be understood that determining (or generating) B according to (or based on) A does not mean that B is determined (or generated) only according to (or based on) A, and B can also be determined (or generated) according to (or based on) A and / or other information.

[0130] As described in the background technology section, different scenarios or services have different reliability requirements for broadcast communications. For example, some scenarios require higher reliability for broadcast messages, while other scenarios require lower reliability for broadcast messages. Therefore, it is necessary to research broadcast communication solutions that can meet different reliability requirements. The embodiments of the present application provide broadcast communication solutions and multicast communication solutions that can meet different reliability requirements.

[0131] The technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings.

[0132] Figure 1 exemplarily shows a schematic diagram of the architecture of a wireless network to which an embodiment of the present application is applicable. As shown in Figure 1, node A, node B, node C, node D, node H, node J, and node K are nodes in the same wireless network, wherein the direction of the arrow indicates the direction of the broadcast message (or multicast communication), and the dotted line between two nodes represents the communication link between the two nodes. Taking the transmission of broadcast message 1 by node A (source node) in Figure 1 as an example, the transmission process of the broadcast message 1 is as follows: node A sends broadcast message 1 to node B; node B forwards broadcast message 1 to node C, node D, and node H respectively; node H forwards broadcast message 1 to node C and node J respectively; node C forwards broadcast message 1 to node D; node D forwards broadcast message 1 to node K. During the transmission of broadcast message 1, node A is the source node, node B, node C, node D, and node H are forwarding nodes (or intermediate nodes), and node J and node K are destination nodes. A source node can be understood as a node that only sends broadcast messages (or multicast messages) to other nodes in a broadcast communication (or multicast communication), a forwarding node can be understood as a node that forwards received broadcast messages (or multicast messages) to other nodes in a broadcast communication (or multicast communication), and a destination node can be understood as a node that only receives broadcast messages (or multicast messages) sent by other nodes in a broadcast communication (or multicast communication). In other words, a source node only sends broadcast messages (or multicast messages) to other nodes, a forwarding node both receives broadcast messages (or multicast messages) and forwards them to other nodes, and a destination node only receives broadcast messages (or multicast messages). It should be noted that the source node, forwarding node, and destination node in a wireless network can be dynamic and not fixed. In a wireless network, if there is a communication link between two nodes, the two nodes are neighbor nodes. For example, in Figure 1 , the neighbor nodes of node A include node B, the neighbor nodes of node B include node A, node H, node C, and node D, the neighbor nodes of node C include node B, node D, and node H, and the neighbor nodes of node H include node B, node C, and node J. It should be understood that the wireless network shown in Figure 1 is only an example, and the wireless network may include more or fewer nodes.

[0133] It should be noted that Figure 1 is only an exemplary architecture diagram and can also be an architecture diagram in other forms. For example, the wireless network can also be a tree-like multi-hop topology structure or a tree-like three-layer (or more-layer) multi-hop topology structure. Although not shown in Figure 1, in addition to the functional entities shown in Figure 1, Figure 1 can also include other functional entities. The method provided in the embodiment of the present application can be applied to the wireless network shown in Figure 1. Of course, the method provided in the embodiment of the present application can also be applied to other wireless networks, and the embodiment of the present application is not limited to this. For example, the method in the embodiment of the present application can be applied to any wireless network that can be transmitted by broadcast or multicast, such as a flat (fabric) network, a mesh network, a mobile ad hoc network (MANET), a low-power and lossy (LLN) network, etc. For another example, the wireless network shown in Figure 1 is a star flash network, and the wireless network shown in Figure 1 includes at least one management node (grant node) and at least one terminal node (terminal node). The management node (abbreviated as G node) is used to send data scheduling information at the access layer of the communication system (for example, the Star Flash communication system), and the terminal node (abbreviated as T node) is used to receive data scheduling information at the access layer of the communication system and send corresponding data according to the received data scheduling information.

[0134] In order to meet the reliability requirements of broadcast communication (or multicast communication) in different scenarios or different services, the embodiment of the present application provides (or defines) a message header (broadcast header) for broadcast communication in a wireless network and its assembly method in a wireless network message. The wireless network message header can be composed of a basic message header (basicheader) followed by several extended message headers. The broadcastheader provided in the embodiment of the present application is an extended message header of a wireless network message. It should be noted that the broadcast message header (broadcastheader) defined in the embodiment of the present application can be replaced with other names, and this application is not limited. Table 1 is an example of a broadcastheader provided in the embodiment of the present application.

[0135] Table 1

[0136]

[0137] Referring to Table 1, the broadcastheader includes the following fields: next header, type, ACK, reserved, alive time, sequence number; among them, next header occupies 8 bits (bits), type occupies 2 bits, ACK occupies 1 bit, reserved occupies 13 bits, alive time occupies 8 bits, and sequence number occupies 32 bits. It should be noted that type and ACK in the broadcastheader are indispensable (or necessary), and next header, reserved, alive time, and sequence number are optional. The number of bits occupied by each field in the broadcastheader can be flexibly configured as needed, and this application does not limit it. In other words, any field in the broadcastheader can occupy more or fewer fields. For example, type occupies 1 bit, reserved occupies 14 bits. For another example, alive time occupies 9 bits, and reserved occupies 12 bits. For another example, alive time occupies 7 bits, and reserved occupies 14 bits.

[0138] The meaning of each field in the broadcastheader is as follows:

[0139] next header: specifies (or indicates) the type of the next message header.

[0140] type: The type of broadcast message (or multicast message), that is, type is the type of broadcast message (or multicast message). In other words, type represents the type of broadcast message (or multicast message). For example, type occupies 2 bits. When the value of type is 0 (that is, the 2 bits occupied by type are 00), the type of broadcast message corresponds to (or represents) non-reliable broadcast; when the value of type is 1 (that is, the 2 bits occupied by type are 01), the type of broadcast message corresponds to (or represents) reliable broadcast; when the value of type is 2 (that is, the 2 bits occupied by type are 10), the meaning of type is undefined; when the value of type is 3 (that is, the 2 bits occupied by type are 11), the meaning of type is undefined. In this example, the meanings of type values ​​2 and 3 are retained. For example, type occupies 1 bit. When the value of type is 0 (i.e., the 1 bit occupied by type is 0), the type of the broadcast message corresponds to (or represents) non-reliability broadcast; when the value of type is 1 (i.e., the 1 bit occupied by type is 1), the type of the broadcast message corresponds to (or represents) reliability broadcast.

[0141] ACK: used for the receiving end to respond to the received broadcast message (or multicast message), and the type in the broadcast message corresponds to reliability broadcast. The receiving end refers to any node in the wireless network that receives the broadcast message (or multicast message). Optionally, when the type in the broadcast message (or multicast message) sent by the sending end to the receiving end corresponds to reliability broadcast, the receiving end replies with a response (acknowledgement, ACK) message to the sending end, and the ACK in the response message can be set to 1, and is set to 0 in other cases. Exemplarily, the sending end (such as node A in Figure 1) sends a broadcast message to the receiving end (such as node B in Figure 1), and the type in the broadcast message corresponds to reliability broadcast, and the ACK in the broadcast message is set to 0, that is, the value of ACK is 0; after receiving the broadcast message, the receiving end replies with a response message to the sending end, and the ACK in the response message is set to 1, that is, the value of ACK is 1. Optionally, the receiving end replies with a response message to the sending end in unicast mode, which can reduce the sending of messages. It should be understood that if the value of ACK in the broadcast header is 1, it indicates that the message including the broadcast header is a response message to the broadcast message (or multicast message).

[0142] reserved: Reserved for subsequent expansion. The value of each bit in reserved can be initialized to 0.

[0143] Alive time: The maximum lifetime of a broadcast message within the network, in seconds (s), for example, the default is 30s. The alive time in the broadcast header is configurable. Optionally, the initial alive time, i.e., the alive time in the message sent by the source node, is specified by the source node on demand. Before a message (broadcast or multicast) is forwarded by an intermediate node, the alive time needs to be deducted from the corresponding local processing time, i.e., the time it takes the intermediate node to process the message. For example, an intermediate node receives broadcast message 2, and the alive time in broadcast message 2 is 20s, i.e., the alive time is 20s. The time it takes the intermediate node to process broadcast message 2 is 2s, i.e., the local processing time is 2s. After deducting the local processing time of 2s from the alive time in broadcast message 2, the intermediate node forwards broadcast message 2 to its neighboring nodes. In this example, the alive time in broadcast message 2 forwarded by the intermediate node is 18s, i.e., the alive time is 18s. When the local processing time that needs to be deducted from the alivetime in the message is greater than the alivetime, the survival time of the message expires and the intermediate node should not continue to forward the message. For example, an intermediate node receives broadcast message 2, and the alivetime in broadcast message 2 is 1s, that is, the alivetime is 1s. The time taken by the intermediate node to process broadcast message 2 is 2s, that is, the local processing time is 2s; the intermediate node does not forward broadcast message 2. In the response message, the alivetime can be calculated according to the actual situation, that is, the alivetime deducts the corresponding local processing time, or it can be directly filled with 0, which is not limited in this application.

[0144] Sequence number: The sequence number of a broadcast message (or multicast message). Optional. The sequence number is incremented by 1 each time the broadcast message generator (or source node) sends a message. This sequence number is used to distinguish broadcast messages and is not used to compare old and new messages.

[0145] The broadcast header provided by the embodiment of the present application has been introduced above. The following describes how the broadcast header is assembled in a wireless network message. The assembly method can be called a generation method.

[0146] Assume that node A is the source node generating the message. An example of node A generating a broadcast message (or multicast message) is as follows: constructing the basic message header at the network layer; adding the broadcast header after the basic message header; adding other extended message headers and upper-layer message headers after the broadcast header, and then adding the payload.

[0147] The basic header of the network layer may include the following fields: nextheader, source address, and destination address. The nextheader points to the broadcastheader. The source address is the unicast address of the current node (i.e., node A), such as 100.1. The destination address can be a broadcast address broadcast within the wireless network range, or a multicast address. For example, a destination address of 255.255 indicates a broadcast within the wireless network range. For another example, a destination address of 128.1 indicates a multicast address.

[0148] The broadcastheader may include the following fields: nextheader, type, ACK, and alivetime. The nextheader points to the other extended headers following the broadcastheader. If type=0, i.e., type is set to 0, this indicates that the broadcast message corresponds to unreliable broadcast. If type=1, i.e., type is set to 1, this indicates that the broadcast message corresponds to reliable broadcast. Only when type=1 is ACK used, and in a broadcast message, ACK=0, i.e., ACK is set to 0. In a response message to a broadcast message, ACK=1, i.e., ACK is set to 1. Alternatively, if type=0, i.e., type is set to 0, this indicates that the multicast message corresponds to unreliable multicast. If type=1, i.e., type is set to 1, this indicates that the multicast message corresponds to reliable multicast. Only when type=1 is ACK used, and in a multicast message, ACK=0, i.e., ACK is set to 0. In a response message to a multicast message, ACK=1, i.e., ACK is set to 1. The meaning of each field in the broadcastheader can be found in the previous description and will not be repeated here. Node A maintains a local sequence number (e.g., initially 0). Each time a broadcast message is sent, its sequence number increments by 1. This sequence number is used only to distinguish different messages and is not related to the new or old version of the message. Optionally, the sequence number occupies 4 bytes. When the sequence number reaches its maximum value, it can be reset to 0.

[0149] In one possible implementation, the broadcast message (or multicast message) generated by node A is not fragmented, but managed by upper-layer applications. This reduces the burden on nodes to reassemble messages. Optionally, the broadcast message (or multicast message) is not fragmented at the source, intermediate, or destination nodes. When the amount of information being carried is too large, the application-layer protocol can use multiple broadcast messages to carry the information. This is done because message reassembly is time-consuming, and not fragmenting reduces the burden on network nodes.

[0150] The broadcast header provided by the embodiment of the present application and the method of assembling the broadcast header in a wireless network message are described above. The communication solution provided by the embodiment of the present application is described below with reference to the accompanying drawings.

[0151] FIG2 is an interactive flow chart of a communication method provided in an embodiment of the present application. As shown in FIG2 , the method includes:

[0152] 201. The second device generates a first message.

[0153] The first field in the first message indicates whether the type of the first message is the first type or the second type, the first type corresponding to unreliable broadcast, and the second type corresponding to reliable broadcast. Alternatively, the first type corresponds to unreliable multicast, and the second type corresponds to reliable multicast. The first field may be the type in Table 1. The second device may be a source node in a wireless network, such as node A in Figure 1. In other words, the second device is any node in the wireless network that generates and sends a broadcast message (or multicast message). Optionally, the first message also includes a second field. If the first field in the first message indicates that the type of the first message is the second type, the second field in the first message is used by the first device to respond. The second field may be the ACK in Table 1. The second device may generate a broadcast message or multicast message of the first type or the second type based on the reliability requirement of the message to be sent. For example, when the reliability requirement of the message to be sent is low, the second device generates a broadcast message or multicast message of the first type; when the reliability requirement of the message to be sent is high, the second device generates a broadcast message or multicast message of the second type.

[0154] In one possible implementation, the reliability requirement for broadcast messages for the reliability broadcast is higher than the reliability requirement for broadcast messages for the unreliable broadcast, or the reliability requirement for multicast messages for the reliability multicast is higher than the reliability requirement for multicast messages for the unreliable multicast. In this implementation, the first message is of the first type or the second type, and the first message can meet different reliability requirements.

[0155] In one possible implementation, the reliability broadcast requires the device to respond to the device that sent the broadcast message for the received broadcast message, such as replying a response message, and the unreliability broadcast does not require the device to respond to the device that sent the broadcast message for the received broadcast message. Alternatively, the reliability multicast requires the device to respond to the device that sent the multicast message for the received multicast message, and the unreliability multicast does not require the device to respond to the device that sent the multicast message for the received multicast message. Taking the second device as node A in Figure 1 as an example, node A generates and sends a first message to node B; if the type of the first message is the first type, the unreliability broadcast corresponding to the first type does not require node B to respond to node A for the first message; if the type of the first message is the second type, the reliability broadcast corresponding to the second type requires node B to respond to node A for the first message. It is understood that if the first field in the first message indicates that the type of the first message is the first type, the node receiving the first message does not need to respond to the second device for the first message; if the first field in the first message indicates that the type of the first message is the first type, the node receiving the first message does not need to respond to the second device for the first message; if the first field in the first message indicates that the type of the first message is the second type, the node receiving the first message needs to respond to the second device for the first message. In this implementation, reliability broadcast requires a device to respond to the device that sent the broadcast message for a received broadcast message to confirm whether the first message was successfully received, which can enhance reliability. Unreliable broadcast does not require a device to respond to the device that sent the broadcast message for a received broadcast message, which can reduce message transmission and save resource overhead. Reliability multicast requires a device to respond to the device that sent the multicast message for a received multicast message to confirm whether the first message was successfully received, which can enhance reliability. Unreliable multicast does not require a device to respond to a received multicast message to the device that sent it. This reduces the number of messages sent and saves resources.

[0156] In one possible implementation, the first message further includes a third field, and the third field in the first message indicates a first survival time of the first message within the network. The third field may be the "alive time" in Table 1. In this implementation, the third field in the first message indicates the first survival time of the first message within the network, so that first messages transmitted within the network disappear at approximately the same time, thereby reducing the number of failed messages transmitted within the network.

[0157] In one possible implementation, the first message further includes a sequence number, which is used to indicate the sequence number of the first message. The sequence number may be a sequence number in Table 1. In this implementation, the sequence number is used to indicate the sequence number of the first message, so that a device receiving the first message can use the sequence number to determine whether the first message is a duplicate message.

[0158] In one possible implementation, the first field, the second field, the third field, and the sequence number are included in a broadcast header. Optionally, the broadcast header also includes a reserved field and a fourth field, and the fourth field is used to indicate the type of the next header. The fourth field can be the next header in Table 1. Table 1 is an example of a broadcast header in the first message. Optionally, the first message also includes a basic message header of the network layer. The first message may also include other extended message headers and upper layer message headers. In this implementation, the first field, the second field, and the third field are included in the broadcast message header, which can more conveniently generate messages that meet different reliability requirements.

[0159] In one possible implementation, the third field in the first message indicates a first survival time of the first message within the network; the method further includes: caching the first message locally; and deleting the first message after the time the first message has been cached locally exceeds the first survival time. In this implementation, deleting the first message after the time the first message has been cached locally exceeds the first survival time allows for timely release of occupied cache resources.

[0160] 202. The second device sends a first message to the first device.

[0161] Correspondingly, the second device receives the first message from the first device. The first device can be understood as a neighbor node of the second device. The second device sending the first message to the first device can be: the second device sends the first message to one or more neighbor nodes of the second device, and the one or more neighbor nodes include the first device. The interaction process in Figure 2 is described using the first device and the second device as an example. It should be understood that the operations performed by each neighbor node of the second device are similar and will not be described in detail here. The first device can be regarded as the source node in a broadcast communication (or multicast communication), and the second device can be regarded as the forwarding node in the broadcast communication (or multicast communication). It should be understood that the operations performed by each forwarding node in the wireless network are similar, so the operation of the forwarding node is described here using the second device as an example. It should be noted that the difference between the destination node and the forwarding node in the wireless network is only that the destination node does not forward the received message, and the operations performed by the destination node will not be described separately here.

[0162] 203. The first device processes the first message according to the type of the first message.

[0163] In one possible implementation, the third field in the first message indicates the first message's first time to live in the network. After receiving the first message, the first device locally caches the first message for the first time to live. Locally caching the first message for the first time to live can be understood as: locally caching the first message; and after the time the first message remains cached for longer than the first time to live, deleting the first message. Optionally, the first device locally caches summary information of the first message for a fourth time to live, where the fourth time to live is longer than the first time to live. The summary information of the first message may include a combination of the source address and sequence number in the first message. Optionally, after receiving the first message from the second device, the first device first determines whether the first message is a duplicate; if so, discards the first message; if not, locally caches the first message for the first time to live. In this implementation, locally caching the first message for the first time to live allows for the timely release of occupied cache resources.

[0164] A possible implementation of step 203 is as follows: when the type of the first message is the second type, send a second message in response to the first message to the second device, and add the first message to the message sending queue of the first neighbor node. The first neighbor node refers to one or more neighbor nodes of the first device. The first field in the second message indicates that the type of the second message is the second type, and the second field in the second message is used to indicate that the first device has successfully received the first message. For example, the first field (type) in the first message indicates the second type, and the second field (ACK) in the first message is 0; the first field (type) in the second message indicates the second type, and the second field (ACK) in the second message is 1, and the second field in the second message is used to indicate that the first device has successfully received the first message.

[0165] After adding the first message to the first neighbor node's message transmission queue, the first device may further perform the following operations: send the first message to the first neighbor node; and after receiving a fourth message from the first neighbor node in response to the first message, remove the first message from the first neighbor node's message transmission queue. The first field in the fourth message indicates that the fourth message type is the second type, and the second field in the fourth message indicates that the first neighbor node successfully received the first message. The fourth message is similar to the second message and will not be described in detail here. The third field in the first message sent by the first device to the first neighbor node indicates a third time to live of the first message within the network. The third field in the first message from the second device indicates the first time to live of the first message within the network. The third time to live is shorter than or equal to the first time to live. For example, the third time to live is equal to the first time to live minus the time the first device takes to process the first message. Due to the limited precision of the time to live that can be represented by the third field, the third time to live may be equal to the first time to live. In one possible implementation, if the first device does not receive a response message from the first neighbor node to the first message within a first waiting time after sending the first message to the first neighbor node, the first device retransmits the first message to the first neighbor node. If the first device still does not receive a response message from the first neighbor node to the first message, it may try to retransmit multiple times, for example, retransmit once every first waiting time, until a response message from the first neighbor node to the first message is received or the local cache lifecycle of the first message ends. The end of the local cache lifecycle of the first message means that the length of time the first device caches the first message reaches the above-mentioned first survival time. The survival time indicated by the third field (alive time) in the first message sent by the first device to the first neighbor node for the first time is shorter than the survival time indicated by the third field in the first message retransmitted by the first device to the first neighbor node. For example, the survival time indicated by the third field in the first message sent by the first device to the first neighbor node for the first time is 10s, the survival time indicated by the third field in the first message retransmitted by the first device to the first neighbor node for the first time is (10-t)s, and the survival time indicated by the third field in the first message retransmitted by the first device to the first neighbor node for the second time is (10-2t)s, and so on, until a response message to the first message is received from the first neighbor node or the local cache lifecycle of the first message ends. t represents the first waiting time, which can be flexibly configured and is not limited in this application.

[0166] In one possible implementation, the second type corresponds to reliability multicast, and the destination address in the first message is a multicast address. The first device may also perform the following operations: when monitoring the multicast address in the first message, sending the first message to a control plane program or application for processing, and forwarding the first message to the first neighboring node; when not monitoring the multicast address in the first message, forwarding the first message to the first neighboring node. In this implementation, the device performs corresponding processing based on whether it monitors the multicast address in the first message, and can send the monitored multicast message to the control plane program or application for processing, and forward multicast messages that the device is not interested in.

[0167] A possible implementation of step 203 is as follows: if the type of the first message is the first type, add the first message to the message sending queue of the first neighboring node; and send the first message to the first neighboring node, wherein the third field in the first message sent to the first neighboring node indicates the third survival time of the first message within the network, and the third field in the first message from the second device indicates the first survival time of the first message within the network, and the third survival time is shorter than or equal to the first survival time. In this implementation, the third survival time is shorter than or equal to the first survival time, so that the first messages transmitted in the network disappear at approximately the same time point, thereby reducing the transmission of invalid messages in the network.

[0168] A possible implementation of step 203 is as follows: if the type of the first message is the first type, add the first message to the message sending queue of the first neighboring node; before sending the first message to the first neighboring node, determine a sixth survival time, where the sixth survival time is equal to the first survival time minus the local processing time, where the local processing time is the time taken by the first device to process the first message; if the sixth survival time is less than 0, cancel sending the first message to the first neighboring node. In this implementation, if the sixth survival time is less than 0, cancel sending the first message to the first neighboring node; thus, reducing the number of failed first messages.

[0169] In the embodiment of the present application, the type of the first message is the first type or the second type, and the first message can meet different reliability requirements and reduce resource overhead.

[0170] FIG3 is an interactive diagram of another broadcast communication method provided by an embodiment of the present application. The method flow in FIG3 is a possible implementation of the method described in FIG2. In this implementation, after receiving a first message (broadcast message) from a second device, the first device sends a response message to the second device in response to the first message, which can improve the reliability of the message. As shown in FIG3, the method includes:

[0171] 301. The second device generates a first message.

[0172] The way in which the second device generates the first message can refer to the example of node A generating a broadcast message above. The first field in the first message indicates that the type of the first message is the second type. The second type corresponds to reliability broadcast. Figure 3 takes node A, node B and node C in Figure 1 as an example to describe the transmission process of the broadcast message; wherein, node A represents the second device, node B represents the first device, and node C represents the third device. It can be understood that node A is an example of a source node, and node B and node C are examples of intermediate nodes. Since the operations performed by each intermediate node are similar, only the operation of node B (i.e., the first device) is described here.

[0173] The first message further includes a second field. If the first field in the first message indicates that the type of the first message is the second type, the second field in the first message is used by the first device to respond. The first message further includes a third field. The third field in the first message indicates a first survival time of the first message within the network.

[0174] 302. The second device locally caches the first message for a first survival time.

[0175] 303. The second device sends a first message to the first device.

[0176] Correspondingly, the first device receives the first message from the second device. The order of step 303 and step 302 is not limited.

[0177] 304. The first device determines whether the first message from the second device is a duplicate message.

[0178] If not, execute step 305; if so, execute step 313. The first device has three possible processing methods based on whether the first message from the second device is a duplicate message: Method 1, if the first message is a new message, cache the first message locally for a first survival time, and add the first message to the message sending queue of the third device; Method 2, if the first message is a new message, but the local cache is insufficient, a different processing strategy can be adopted. Two options are provided here: 1) discard directly and wait for retransmission from the second device; 2) first age a message that has been forwarded and has been cached locally for the longest time, and then cache the first message; Method 3, if the first message is a duplicate message, discard it directly. Method 1 and Method 2 here are two possible implementation methods of step 305 below. Method 3 is step 313 below.

[0179] A possible implementation of step 304 is as follows: the first device determines whether the first message is a duplicate message based on the source address and serial number in the first message. Optionally, the first device uses the combination of the source address and serial number in the first message as the index of the first message; and determines whether the first message is a duplicate message by looking up whether the combination of the source address and serial number in the first message is cached locally. If the combination of the source address and serial number in the first message is cached locally, that is, the index of the first message, the first message is determined to be a duplicate message; otherwise, the first message is determined to be a new message, that is, a non-duplicate message. After receiving any message, the first device can cache the arbitrary message and the index of the arbitrary message, that is, the combination of the source address and serial number in the arbitrary message.

[0180] 305. The first device locally caches the first message for a first survival time, and adds the first message to a message sending queue of the third device.

[0181] The third device is a neighbor node of the first device. It should be understood that the first device can add the first message to the message sending queue of each of its neighbor nodes (except the second device), and only the third device is used as an example here.

[0182] In one possible implementation, the first device locally caches the summary information of the first message for a fourth survival time, and the fourth survival time is longer than the first survival time. Optionally, the fourth survival time is the first survival time plus a preset duration, such as 20s, 10s, etc. The extraction of the summary information of the message is a local behavior, for example, using the index representation of the message (source address+sequence number), that is, the source address+sequence number. In this implementation, the fourth survival time is longer than the first survival time, which can avoid the problem of being unable to determine whether the first message is a duplicate when the first message is received from other neighbors after aging.

[0183] In one possible implementation, when the first device locally caches the first message and discovers a new neighbor node, the first device adds the first message to a transmission queue of the new neighbor node. In this implementation, the first message may be forwarded to the new neighbor node.

[0184] 306. The first device sends the first message to a control plane program or application for processing.

[0185] 307. The first device sends a second message in response to the first message to the second device.

[0186] Accordingly, the second device receives a second message sent by the second device in response to the first message. The first field in the second message indicates that the type of the second message is the second type, and the second field in the second message indicates that the first device successfully received the first message. The order of steps 305, 306, and 307 is not limited.

[0187] Step 307 may be replaced by: when the second device does not receive a response from the first device to the first message, determining that a failure occurs in the communication link between the second device and the first device; this allows for faster detection of the link failure.

[0188] 308. The first device forwards the first message to the third device.

[0189] The third field in the first message forwarded by the first device to the third device indicates the third survival time of the first message in the network, and the third field in the first message from the second device indicates the first survival time of the above-mentioned first message in the network, and the above-mentioned third survival time is shorter than or equal to the above-mentioned first survival time.

[0190] In one possible implementation, before forwarding the first message to the third device, the first device performs the following operations: determining a sixth keepalive time, where the sixth keepalive time is equal to the first keepalive time minus the local processing time, where the local processing time is the time taken by the first device to process the first message; and if the sixth keepalive time is less than 0, canceling forwarding the first message to the third device. In this implementation, if the sixth keepalive time is less than 0, canceling sending the first message to the first neighbor node, thereby reducing the number of failed first messages sent.

[0191] In one possible implementation, if the first device does not receive a response message from the third device to the first message within a first waiting time after forwarding the first message to the third device, the first device retransmits the first message to the third device. If the first device still does not receive a response message from the third device to the first message, the first device may attempt to retransmit the message multiple times, for example, once every first waiting time, until a response message from the third device to the first message is received or the local cache lifecycle of the first message expires.

[0192] 309. The third device sends a fourth message in response to the first message to the first device.

[0193] Accordingly, the first device receives a fourth message from the third device in response to the first message. The first field in the fourth message indicates that the type of the fourth message is the second type, and the second field in the fourth message indicates that the third device successfully receives the first message.

[0194] 310. The first device deletes the first message from the message sending queue of the third device.

[0195] Steps 309 to 310 may be replaced by the following: If the first device does not receive a response message from the third device to the first message at the end of the local cache lifecycle of the first message, then the cached first message is deleted and the unsuccessfully sent first message is cleared from the message transmission queue of the third device, i.e., retransmission of the first message is stopped. Optionally, if the first device does not receive a response message from the third device to the first message at the end of the local cache lifecycle of the first message, the first device determines that the communication link between the first device and the third device has failed.

[0196] 311. After the time the first message is cached and stored locally exceeds a first survival time, the first device deletes the first message.

[0197] Optionally, after the time for which the summary information of the first message is cached in the local storage exceeds a fourth survival time, the summary information of the first message is deleted.

[0198] 312. After the time the first message is cached and stored locally exceeds a first survival time, the second device deletes the first message.

[0199] 313. The first device discards the first message.

[0200] The first message is of the second type, corresponding to reliability broadcast. After any node sends the first message to its neighboring node, it can determine whether a communication link between the node and the neighboring node has failed based on whether the neighboring node responds to the first message. This allows for faster detection of failed communication links, thereby improving message reliability.

[0201] In an embodiment of the present application, after receiving a first message (broadcast message) from a second device, the first device sends a response message to the second device in response to the first message, which can improve the reliability of the broadcast message.

[0202] FIG4 is an interactive diagram of a multicast communication method provided in an embodiment of the present application. The method flow in FIG4 is a possible implementation of the method described in FIG2. In this implementation, after receiving a first message (multicast message) from a second device, a first device sends a response message to the second device in response to the first message, which can improve the reliability of the message. As shown in FIG4, the method includes:

[0203] 401. The second device generates a first message.

[0204] The way in which the second device generates the first message can refer to the example of node A generating a broadcast message above. The first field in the first message indicates that the type of the first message is the second type. The second type corresponds to reliability multicast. The destination address in the above-mentioned first message is a multicast address. Figure 4 describes the transmission process of the multicast message using node A, node B and node C in Figure 1 as an example; wherein node A represents the second device, node B represents the first device, and node C represents the third device. It can be understood that node A is an example of a source node, and node B and node C are examples of intermediate nodes. Since the operations performed by each intermediate node are similar, only the operation of node B (i.e., the first device) is described here.

[0205] The first message further includes a second field. If the first field in the first message indicates that the type of the first message is the second type, the second field in the first message is used by the first device to respond. The first message further includes a third field. The third field in the first message indicates a first survival time of the first message within the network.

[0206] 402. The second device locally caches the first message for a first survival time.

[0207] 403. The second device sends a first message to the first device.

[0208] Correspondingly, the first device receives the first message from the second device.

[0209] 404. The first device determines whether the first message from the second device is a duplicate message.

[0210] If not, go to step 405; if so, go to step 414. Step 404 can refer to step 304.

[0211] 405. The first device locally caches the first message for a first survival time, and adds the first message to a message sending queue of the third device.

[0212] The third device is a neighbor node of the first device. It should be understood that the first device can add the first message to the message sending queue of each of its neighbor nodes (except the second device), and only the third device is used as an example here.

[0213] In one possible implementation, the first device locally caches the summary information of the first message for a fourth survival time, and the fourth survival time is longer than the first survival time. Optionally, the fourth survival time is the first survival time plus a preset duration, such as 20s, 10s, etc. The extraction of the summary information of the message is a local behavior, for example, using the index representation of the message (source address+sequence number), that is, the source address+sequence number. In this implementation, the fourth survival time is longer than the first survival time, which can avoid the problem of being unable to determine whether the first message is a duplicate when the first message is received from other neighbors after aging.

[0214] In one possible implementation, when the first device locally caches the first message and discovers a new neighbor node, the first device adds the first message to a transmission queue of the new neighbor node. In this implementation, the first message may be forwarded to the new neighbor node.

[0215] 406. The first device sends a second message in response to the first message to the second device.

[0216] Accordingly, the second device receives a second message sent by the second device in response to the first message. The first field in the second message indicates that the type of the second message is the second type, and the second field in the second message indicates that the first device successfully received the first message. The order of steps 405 and 406 is not limited.

[0217] Step 406 may be replaced by: when the second device does not receive a response from the first device to the first message, determining that a failure occurs in the communication link between the second device and the first device; this allows for faster detection of the link failure.

[0218] 407. The first device determines whether to monitor the multicast address in the first message.

[0219] If so, proceed to step 408; if not, proceed to step 409. For multicast messages, only nodes that monitor the multicast address in the multicast message will send the multicast message to the control plane program or application. If the first device does not monitor the multicast address in the first message, the first device does not process the first message, that is, does not send the first message to the control plane program or application for processing, and only forwards the first message to its neighboring nodes. The order of steps 407 and 406 is not limited.

[0220] 408. The first device sends the first message to a control plane program or application for processing.

[0221] 409. The first device forwards the first message to the third device.

[0222] The third field in the first message forwarded by the first device to the third device indicates the third survival time of the first message within the network. The third field in the first message from the second device indicates the first survival time of the first message within the network. The third survival time is shorter than or equal to the first survival time. Step 409 may refer to step 308.

[0223] 410. The third device sends a fourth message in response to the first message to the first device.

[0224] Accordingly, the first device receives a fourth message from the third device in response to the first message. The first field in the fourth message indicates that the type of the fourth message is the second type, and the second field in the fourth message indicates that the third device successfully receives the first message.

[0225] 411. The first device deletes the first message from the message sending queue of the third device.

[0226] Steps 410 to 411 may be replaced by the following: If the first device does not receive a response message from the third device to the first message at the end of the local cache lifecycle of the first message, then the cached first message is deleted and the unsuccessfully sent first message is cleared from the message sending queue of the third device, i.e., retransmission of the first message is stopped. Optionally, if the first device does not receive a response message from the third device to the first message at the end of the local cache lifecycle of the first message, the first device determines that a communication link failure has occurred between the first device and the third device.

[0227] 412. After the time the first message is cached and stored locally exceeds a first survival time, the first device deletes the first message.

[0228] Optionally, after the time for which the summary information of the first message is cached in the local storage exceeds a fourth survival time, the summary information of the first message is deleted.

[0229] 413. After the time the first message is cached and stored locally exceeds a first survival time, the second device deletes the first message.

[0230] 414. The first device discards the first message.

[0231] In an embodiment of the present application, after receiving a first message (multicast message) from a second device, the first device sends a response message to the second device in response to the first message, which can improve the reliability of the broadcast message.

[0232] FIG5 is an interactive diagram of another broadcast communication method provided by an embodiment of the present application. The method flow in FIG5 is a possible implementation of the method described in FIG2. In this implementation, after receiving a first message (broadcast message) from a second device, the first device does not need to respond to the second device regarding the first message, which can reduce the transmission of messages and reduce the number of invalid messages in the network. As shown in FIG5, the method includes:

[0233] 501. The second device generates a first message.

[0234] The way in which the second device generates the first message can refer to the example of node A generating a broadcast message above. The first field in the first message indicates that the type of the first message is the first type. The first type corresponds to non-reliable broadcast. Figure 3 takes node A, node B and node C in Figure 1 as an example to describe the transmission process of the broadcast message; wherein, node A represents the second device, node B represents the first device, and node C represents the third device. It can be understood that node A is an example of a source node, and node B and node C are examples of intermediate nodes. Since the operations performed by each intermediate node are similar, only the operation of node B (i.e., the first device) is described here.

[0235] 502. The second device locally caches the first message for a first survival time.

[0236] The first message further includes a third field, and the third field in the first message indicates a first survival time of the first message in the network.

[0237] 503. The second device sends a first message to the first device.

[0238] Correspondingly, the first device receives the first message from the second device.

[0239] 504. The first device determines whether the first message from the second device is a duplicate message.

[0240] If not, go to step 505; if so, go to step 510. Step 504 can refer to step 304.

[0241] 505. The first device locally caches the first message for a first survival time, and adds the first message to a message sending queue of the third device.

[0242] Step 505 may refer to step 305 .

[0243] 506. The first device sends the first message to a control plane program or application for processing.

[0244] The order of step 306 and step 307 is not limited.

[0245] 507. The first device forwards the first message to the third device.

[0246] Optionally, the first device deletes the first message from the message sending queue of the third device. The third field in the first message forwarded by the first device to the third device indicates the third survival time of the first message within the network, and the third field in the first message from the second device indicates the first survival time of the first message within the network, where the third survival time is shorter than or equal to the first survival time. Step 507 may refer to step 308. Optionally, the first device forwards the first message to the third device and immediately (e.g., within 1 second) deletes the first message from the message sending queue of the third device.

[0247] 508. After the time the first message is cached and stored locally exceeds a first survival time, the first device deletes the first message.

[0248] Optionally, after the time for which the summary information of the first message is cached in the local storage exceeds a fourth survival time, the summary information of the first message is deleted.

[0249] 509. After the time the first message is cached and stored locally exceeds a first survival time, the second device deletes the first message.

[0250] 510. The first device discards the first message.

[0251] In an embodiment of the present application, after receiving a first message (broadcast message) from a second device, the first device does not need to respond to the second device regarding the first message, which can reduce message transmission and reduce invalid messages in the network.

[0252] FIG6 is an interactive diagram of another multicast communication method provided by an embodiment of the present application. The method flow in FIG6 is a possible implementation of the method described in FIG2. In this implementation, after receiving a first message (multicast message) from a second device, the first device does not need to respond to the second device regarding the first message, which can reduce the transmission of messages and reduce the number of invalid messages in the network. As shown in FIG6, the method includes:

[0253] 601. The second device generates a first message.

[0254] The way in which the second device generates the first message can refer to the example of node A generating a broadcast message above. The first field in the first message indicates that the type of the first message is the first type. The first type corresponds to non-reliability multicast. The destination address in the above-mentioned first message is a multicast address. Figure 4 describes the transmission process of the multicast message using node A, node B and node C in Figure 1 as an example; wherein node A represents the second device, node B represents the first device, and node C represents the third device. It can be understood that node A is an example of a source node, and node B and node C are examples of intermediate nodes. Since the operations performed by each intermediate node are similar, only the operation of node B (i.e., the first device) is described here.

[0255] 602. The second device locally caches the first message for a first survival time.

[0256] The first message further includes a third field, and the third field in the first message indicates a first survival time of the first message in the network.

[0257] 603. The second device sends a first message to the first device.

[0258] Correspondingly, the first device receives the first message from the second device.

[0259] 604. The first device determines whether the first message from the second device is a duplicate message.

[0260] If not, go to step 605; if so, go to step 612. Step 604 can refer to step 404.

[0261] 605. The first device locally caches the first message for a first survival time, and adds the first message to a message sending queue of the third device.

[0262] The third device is a neighbor node of the first device. It should be understood that the first device can add the first message to the message sending queue of each of its neighbor nodes (except the second device). Here, only the third device is used as an example. Step 605 can refer to step 405.

[0263] 606. The first device determines whether to monitor the multicast address in the first message.

[0264] If yes, go to step 607; if no, go to step 608. Step 606 can refer to step 407.

[0265] 607. The first device sends the first message to a control plane program or application for processing.

[0266] 608. The first device forwards the first message to the third device.

[0267] Step 608 may refer to step 308. Accordingly, the third device receives the first message from the first device. The third device may perform operations similar to those of the first device, which will not be described in detail here.

[0268] 609. The first device deletes the first message from the message sending queue of the third device.

[0269] 610. After the time the first message is cached and stored locally exceeds a first survival time, the first device deletes the first message.

[0270] Optionally, after the time for which the summary information of the first message is cached in the local storage exceeds a fourth survival time, the summary information of the first message is deleted.

[0271] 611. After the time the first message is cached and stored locally exceeds a first survival time, the second device deletes the first message.

[0272] 612. The first device discards the first message.

[0273] In an embodiment of the present application, after receiving the first message (multicast message) from the second device, the first device does not need to respond to the second device regarding the first message, which can reduce the transmission of messages and reduce invalid messages in the network.

[0274] The following describes, in conjunction with the accompanying drawings, an example of a reliability broadcast process (corresponding to the process in Figure 3), an example of a reliability multicast process (corresponding to the process in Figure 4), an example of a non-reliability broadcast process (corresponding to the process in Figure 5), and an example of a non-reliability multicast process (corresponding to the process in Figure 6).

[0275] Figure 7 illustrates an example of a reliable broadcast transmission process provided by an embodiment of the present application. In Figure 7, node A is the source node, nodes B, C, D, and H are intermediate nodes, and nodes J and K are destination nodes. A dotted line between two nodes represents the communication link between them. An arrow between the two nodes represents the flow of a broadcast message, and another arrow represents the flow of response messages to the broadcast message.

[0276] The operations performed by each node during the transmission process of the reliability broadcast shown in Figure 7 are as follows:

[0277] 1) Node A sends a broadcast message P.

[0278] The broadcast message P can be understood as the first message mentioned above. The first field (type) in the broadcast message P indicates the second type, which corresponds to reliability broadcast. Table 2 shows an example of the broadcast message P. In other words, Table 2 shows an example of a reliability broadcast message. Referring to Table 2, the first two columns are basicheader, the third to fifth columns represent broadcastheader, and the sixth column represents payload. The number in the brackets corresponding to each field represents the number of bits occupied by the field, for example, version occupies 3 bits and type occupies 2 bits. The number of bits occupied by payload is a variable. Among them, version is the version of the broadcast message P, ToS (type of service) is the service type, topo ID is the topology ID, flowlabel is the flow label, payload length represents the length of all extended message headers + message payload length, hop limit represents the maximum number of message hops, the next header in the basicheader points to the broadcastheader, and the next header in the broadcastheader points to XXX, where XXX represents the next extended message header type or upper layer protocol header type of the broadcastheader. A flow label indicates the traffic generated by a mobile application (APP) or traffic required by a certain quality of service (QoS). It is assigned by the source node and ensures local uniqueness. Type = 1 indicates that the broadcast message P is of type 2. Source address = 100.1 indicates that the source address is 100.1, and destination address = 255.255 indicates that the broadcast is within the wireless network range. Alive time = 20 indicates that the maximum lifetime of the broadcast message P is 20 seconds, and sequence number = 1000 indicates that the sequence number of the broadcast message P is 1000. The meaning of each field in the broadcast header can be found in the previous description and will not be repeated here. It should be noted that Table 2 is only an example of a broadcast message P. The number of bits occupied by each field in the broadcast message P is not limited, and the broadcast message P may include more or fewer fields. Type and ACK in the broadcast header are required. It should be noted that the basic header can be replaced with other message headers, and the basic header may include more or fewer fields.

[0279] Table 2

[0280]

[0281] 2) Node A caches the broadcast message P locally for an alive time of 20 seconds.

[0282] 3) Node B receives broadcast message P and caches it for an alive time of 20 seconds and its summary for 50 seconds. After local processing, it sends a response message to node A. Node B deducts 2 seconds from the local processing time from the alive time (alive time = 18 seconds). Using the split horizon method, node B sends broadcast message P to its other neighboring nodes: nodes C, D, and H. Table 3 shows an example of a response message to broadcast message P. The meaning of the fields in Table 3 can be found in Table 2. Refer to Table 3. Hop limit = 1 indicates that the maximum number of hops for the message is 1; source address = 100.2 indicates that the source address is 100.2, which is the address of node B; destination address = 100.1 indicates that the destination address is 100.1, which is the address of node A; type = 1, ACK = 1 indicates that this message is a response message; alivetime = 0 indicates that the maximum survival time of the response message is 0s; payload is an optional field. It should be noted that regardless of whether the alivetime in the response message is filled in, the node that receives the response message will not cache the response message. In this application, the response message can be called an acknowledgment message.

[0283] Table 3

[0284]

[0285]

[0286] 4) Node H (or C or D) receives broadcast message P and caches it for an alive time of 18 seconds and a summary of P for 50 seconds. After local processing, it sends a response message to node B. Node H deducts 3 seconds from the local processing time from the alive time (alive time = 15 seconds) and then uses the split horizon method to forward broadcast message P to all its neighboring nodes. Node H forwards the message to nodes C and J. Node D forwards the message to nodes C and K. Node C forwards the message to nodes H and D.

[0287] 5) Node H (or node C or node D) may receive broadcast messages P from multiple neighboring nodes, and compares them through local cache; if it is identified as a duplicate message (see step 304), it discards the duplicate message and does not forward it.

[0288] In this example, after any node sends a broadcast message to its neighboring node, it can determine whether its neighboring node successfully receives the broadcast message based on whether its neighboring node responds to the broadcast message, which can improve the reliability of the message.

[0289] Figure 8 illustrates an example of a reliable multicast transmission process provided by an embodiment of the present application. In Figure 7, node A is the source node, nodes B, C, D, and H are intermediate nodes, and nodes J and K are destination nodes. A dotted line between two nodes represents the communication link between them. An arrow between the two nodes represents the flow of a broadcast message, and another arrow represents the flow of response messages to the broadcast message. Nodes H and D monitor multicast address 128.1, while other nodes do not monitor multicast address 128.1.

[0290] The operations performed by each node during the reliability multicast transmission process shown in Figure 8 are as follows:

[0291] 1) Node A sends multicast message P.

[0292] Multicast message P can be understood as the first message mentioned above. The first field (type) in multicast message P indicates the second type, which corresponds to reliability multicast. Table 4 shows an example of multicast message P. In other words, Table 4 shows an example of reliability multicast message. Referring to Table 4, the first two columns are the basic header, the third to fifth columns represent the broadcast header, and the sixth column represents the payload. The number in the brackets corresponding to each field indicates the number of bits occupied by the field, for example, version occupies 3 bits and type occupies 2 bits. The meaning of each field in multicast message P can be found in Table 2 and will not be repeated here. Source address = 100.1 indicates that the source address is 100.1, and destination address = 128.1 indicates that the destination address is the multicast address 128.1. It should be noted that Table 4 is only an example of multicast message P. The number of bits occupied by each field in multicast message P is not limited, and multicast message P may include more or fewer fields. Among them, type and ACK in the broadcast header are required. It should be noted that the basicheader can be replaced by other message headers, and the basicheader can have more or fewer fields.

[0293] Table 4

[0294]

[0295] 2) Node A caches the multicast message P locally for an alive time of 20 seconds.

[0296] 3) Node B receives multicast message P and caches it for an alive time of 20 seconds and its summary for 50 seconds. Node B then sends a response message to node A. Node B is not monitoring multicast address 128.1. After deducting 2 seconds from its local processing time from the alive time (alive time = 18 seconds), it uses the split horizon method to send multicast message P to its other neighboring nodes: nodes C, D, and H. Table 5 shows an example of a response message to multicast message P. For the meaning of the fields in Table 5, refer to Table 2. Refer to Table 5. Hop limit = 1 indicates that the maximum number of hops for the message is 1; source address = 100.2 indicates that the source address is 100.2, which is the address of node B; destination address = 100.1 indicates that the destination address is 100.1, which is the address of node A; type = 1 and ACK = 1 indicate that this message is a response message; alivetime = 0 indicates that the maximum survival time of the response message is 0 seconds, that is, the response message does not need to be cached; payload is an optional field.

[0297] Table 5

[0298]

[0299] 4) Node H (or C or D) receives multicast message P, caches it for an alive time of 18 seconds and its summary for 50 seconds, and then sends a response message to node B. After deducting 3 seconds from the local processing time (alive time = 15 seconds), node H uses the split horizon method to forward multicast message P to all its neighboring nodes. Node H forwards it to nodes C and J. Node D forwards it to nodes C and K. Node C forwards it to nodes H and D. Because node H monitors multicast address 128.1, it sends the multicast message to the control plane for processing. Similarly, node D sends the multicast message to the control plane for processing.

[0300] 5) Node H (or node C or node D) may receive multicast messages P from multiple neighboring nodes, and compares them through local cache; if it is identified as a duplicate message (see step 404), it discards the duplicate message and does not forward it.

[0301] In this example, after any node sends a multicast message to its neighboring node, it can determine whether its neighboring node successfully receives the broadcast message based on whether its neighboring node responds to the multicast message, thereby improving message reliability.

[0302] Figure 9 illustrates an example of a non-reliable broadcast transmission process provided by an embodiment of the present application. In Figure 9, node A is the source node, nodes B, C, D, and H are intermediate nodes, and nodes J and K are destination nodes. The dotted line between two nodes represents the communication link between them, and the arrows between two nodes represent the direction of the broadcast message.

[0303] The operations performed by each node during the transmission process of the unreliable broadcast shown in Figure 9 are as follows:

[0304] 1) Node A sends a broadcast message P.

[0305] The broadcast message P can be understood as the first message mentioned above. The first field (type) in the broadcast message P indicates the first type, which corresponds to unreliable broadcast. Table 6 shows an example of the broadcast message P. In other words, Table 6 shows an example of an unreliable broadcast message. Referring to Table 6, the first two columns are basicheader, the third to fifth columns represent broadcastheader, and the sixth column represents payload. The numbers in the brackets corresponding to each field represent the number of bits occupied by the field, for example, version occupies 3 bits and type occupies 2 bits. In Table 6, the meaning of each field in the basicheader and the meaning of each field in the broadcastheader can be found in Table 2. Type=0 in the broadcastheader indicates that the type of the broadcast message P is the first type. It should be noted that Table 6 is only an example of the broadcast message P. The number of bits occupied by each field in the broadcast message P is not limited, and the broadcast message P may include more or fewer fields. Among them, type and ACK in the broadcastheader are necessary. It should be noted that the basicheader can be replaced by other message headers, and the basicheader can have more or fewer fields.

[0306] Table 6

[0307]

[0308] 2) Node A caches the broadcast message P locally for an alive time of 20 seconds.

[0309] 3) Node B receives broadcast message P and caches it for an alive time of 20 seconds. After deducting 2 seconds from the local processing time (alive time = 18 seconds), node B uses the horizontal split method to send broadcast message P to other neighboring nodes, namely node C, node D, and node H.

[0310] 4) Node H (or C or D) receives broadcast message P and caches it for an alive time of 18 seconds. After deducting 3 seconds from the local processing time (alive time = 15 seconds), node H uses the split horizon method to forward broadcast message P to all other neighboring nodes. Node H forwards the message to nodes C and J. Node D forwards the message to nodes C and K. Node C forwards the message to nodes H and D.

[0311] 5) Node H (or node C or node D) may receive broadcast messages P from multiple neighboring nodes, and compares them through local cache; if it is identified as a duplicate message (see step 304), it discards the duplicate message and does not forward it.

[0312] In this example, any node only forwards broadcast messages to its neighboring nodes and does not need to respond to received broadcast messages, which can reduce message transmission.

[0313] Figure 10 illustrates an example of a non-reliable multicast transmission process provided by an embodiment of the present application. In Figure 10, node A is the source node; nodes B, C, D, and H are intermediate nodes; and nodes J and K are destination nodes. The dotted line between two nodes represents the communication link between them; the arrows between the two nodes represent the direction of multicast message flow; nodes H and D monitor multicast address 128.1, while other nodes do not monitor multicast address 128.1.

[0314] The operations performed by each node during the unreliable multicast transmission process shown in Figure 10 are as follows:

[0315] 1) Node A sends multicast message P.

[0316] The multicast message P can be understood as the first message mentioned above. The first field (type) in the multicast message P indicates the first type, which corresponds to non-reliable multicast. Table 7 shows an example of the multicast message P. In other words, Table 7 shows an example of a non-reliable multicast message. Referring to Table 7, the first two columns are basicheader, the third to fifth columns represent broadcastheader, and the sixth column represents payload. In Table 7, the meaning of each field in the basicheader and the meaning of each field in the broadcastheader can be found in Table 2. Type=0 in the broadcastheader indicates that the type of the multicast message P is the first type; destination address=128.1 indicates that the destination address is the multicast address 128.1. It should be noted that Table 7 is only an example of the multicast message P. The number of bits occupied by each field in the multicast message P is not limited, and the multicast message P may include more or fewer fields. Among them, type and ACK in the broadcastheader are necessary. It should be noted that basicheader can be replaced by other message headers, and basicheader can have more or fewer fields.

[0317] Table 7

[0318]

[0319] 2) Node A caches the multicast message P locally for an alive time of 20 seconds.

[0320] 3) Node B receives multicast message P and caches it for an alive time of 20 seconds. After deducting 2 seconds from the local processing time (alive time = 18 seconds), node B uses the horizontal split method to send multicast message P to other neighboring nodes, namely node C, node D, and node H.

[0321] 4) Node H (or C or D) receives multicast message P and caches it for an alive time of 18 seconds. After deducting 3 seconds from the local processing time (alive time = 15 seconds), node H uses the split horizon method to forward multicast message P to all its neighboring nodes. Node H forwards the message to nodes C and J. Node D forwards the message to nodes C and K. Node C forwards the message to nodes H and D. Because node H monitors multicast address 128.1, node H sends the multicast message to the control plane for processing. Similarly, node D sends the multicast message to the control plane for processing.

[0322] 5) Node H (or node C or node D) may receive multicast messages P from multiple neighboring nodes, and compares them through local cache; if it is identified as a duplicate message (see step 304), it discards the duplicate message and does not forward it.

[0323] In this example, any node only forwards multicast messages to its neighboring nodes and does not need to respond to received multicast messages, which can reduce message transmission.

[0324] The broadcast communication method and multicast communication method provided by the embodiments of the present application are described above. The following describes the structure of a communication device that can implement the broadcast communication method and / or multicast communication method provided by the embodiments of the present application in conjunction with the accompanying drawings.

[0325] Figure 11 is a schematic diagram of the structure of a communication device 1100 provided in an embodiment of the present application. The communication device 1100 can implement the functions or steps implemented by the first device in each of the above-mentioned method embodiments, the functions or steps implemented by the second device in each of the above-mentioned method embodiments, and the functions or steps implemented by the third device in each of the above-mentioned method embodiments. The communication device may include a processing module 1110 and a transceiver module 1120. Optionally, it may also include a storage unit, which can be used to store instructions (code or program) and / or data. The processing module 1110 and the transceiver module 1120 can be coupled to the storage unit. For example, the processing module 1110 can read the instructions (code or program) and / or data in the storage unit to implement the corresponding method. The above-mentioned units can be provided independently or partially or fully integrated. For example, the transceiver module 1120 may include a transmitting module and a receiving module. The transmitting module may be a transmitter, and the receiving module may be a receiver. The entity corresponding to the transceiver module 1120 may be a transceiver or a communication interface.

[0326] In some possible implementations, the communication device 1100 can implement the behaviors and functions of the second device in the above-mentioned method embodiments. For example, the communication device 1100 can be a second device, or a component (such as a chip or circuit) applied to the second device. The transceiver module 1120 can be used to perform all receiving or sending operations performed by the second device in the embodiments of Figures 2 to 6, such as step 202 in the embodiment shown in Figure 2, step 303 and step 307 in the embodiment shown in Figure 3, step 403 and step 406 in the embodiment shown in Figure 4, step 503 in the embodiment shown in Figure 5, step 603 in the embodiment shown in Figure 6, and / or other processes for supporting the technology described herein. The processing module 1110 is used to execute all operations except the sending and receiving operations performed by the second device in the embodiments of Figures 2 to 6, such as step 201 in the embodiment shown in Figure 2, steps 301, 302, and 312 in the embodiment shown in Figure 3, steps 401, 402, and 413 in the embodiment shown in Figure 4, steps 501, 502, and 509 in the embodiment shown in Figure 5, and steps 601, 602, and 611 in the embodiment shown in Figure 6.

[0327] In one possible implementation, the processing module 1110 is used to generate a first message, the first field in the first message indicates that the type of the first message is the first type or the second type, the first type corresponds to non-reliability broadcast, the second type corresponds to reliability broadcast, or the first type corresponds to non-reliability multicast, the second type corresponds to reliability multicast; the transceiver module 1120 is used to send the first message to the first device.

[0328] In one possible implementation, processing module 1110 is specifically configured to construct a basic message header at the network layer, the basic message header including a source address, a destination address, and a fifth field (nextheader) pointing to a broadcast message header, the source address being the unicast address of the local node, the destination address being an address indicating broadcast within the wireless network range, or the destination address being a multicast address; construct the broadcast message header, the broadcast message header including the first field, the second field, and the third field; and add data (payload) after the broadcast message header to obtain the first message. Adding data (payload) after the broadcast message header to obtain the first message can be replaced by adding one or more message headers and data (payload) after the broadcast message header to obtain the first message.

[0329] In one possible implementation, the transceiver module 1120 is further configured to receive a second message in response to the first message, wherein the first field in the second message indicates that the type of the second message is the second type, and the second field in the second message indicates that the first device successfully received the first message. Optionally, the processing module 1110 is further configured to, after receiving the second message in response to the first message, delete the first message from the transmit queue of the first device.

[0330] In one possible implementation, the transceiver module 1120 is further configured to send a third message as a retransmission message of the first message to the first device if no response message in response to the first message is received within a first waiting time after sending the first message.

[0331] In one possible implementation, the processing module 1110 is also used to determine a fifth survival time when no response message in response to the above-mentioned first message is received within a first waiting time after sending the above-mentioned first message, and the above-mentioned fifth survival time is equal to the above-mentioned first survival time minus the above-mentioned first waiting time; when the above-mentioned fifth survival time is less than 0, stop retransmitting the above-mentioned first message.

[0332] In one possible implementation, the third field in the first message indicates the first survival time of the first message in the network; the processing module 1110 is also used to cache the first message in local storage; after the time the first message is cached in the local storage exceeds the first survival time, the first message is deleted.

[0333] In some possible implementations, the communication device 1100 can correspond to the behavior and function of the first device in the above-mentioned method embodiment. For example, the communication device 1100 can be a first device, or it can be a component (such as a chip or circuit) applied to the first device. The transceiver module 1120 can be used to perform all receiving or sending operations performed by the first device in the embodiments of Figures 2 to 6, such as step 202 in the embodiment shown in Figure 2, steps 303, 307, 308, and 309 in the embodiment shown in Figure 3, steps 403, 406, 409, and 410 in the embodiment shown in Figure 4, steps 503 and 507 in the embodiment shown in Figure 5, steps 603 and 608 in the embodiment shown in Figure 6, and / or other processes for supporting the technology described herein. The processing module 1110 is used to execute all operations performed by the receiving end except for the sending and receiving operations, such as step 203 in the embodiment shown in Figure 2, steps 304, step 305, step 306, step 310, step 311, and step 313 in the embodiment shown in Figure 3, steps 404, step 405, step 407, step 408, step 411, step 412, and step 414 in the embodiment shown in Figure 4, steps 504, step 505, step 506, step 508, and step 510 in the embodiment shown in Figure 5, and steps 604, step 605, step 606, step 607, step 609, step 610, and step 612 in the embodiment shown in Figure 6.

[0334] In one possible implementation, the transceiver module 1120 is used to receive a first message from a second device, and the first field in the first message indicates that the type of the first message is the first type or the second type, the first type corresponds to non-reliability broadcast, and the second type corresponds to reliability broadcast, or the first type corresponds to non-reliability multicast, and the second type corresponds to reliability multicast; the processing module 1110 is used to process the first message according to the type of the first message.

[0335] In one possible implementation, the processing module 1110 is specifically used to send a second message in response to the first message to the second device through the transceiver module 1120 when the type of the first message is the second type, and to add the first message to the message sending queue of the first neighbor node (for example, the third device). The first field in the second message indicates that the type of the second message is the second type, and the second field in the second message is used to indicate that the first device has successfully received the first message.

[0336] In one possible implementation, the transceiver module 1120 is further used to send the above-mentioned first message to the above-mentioned first neighbor node; the processing module 1110 is further used to delete the above-mentioned first message from the message sending queue of the above-mentioned first neighbor node after receiving the fourth message in response to the above-mentioned first message from the above-mentioned first neighbor node, the first field in the above-mentioned fourth message indicates that the type of the above-mentioned fourth message is the above-mentioned second type, and the second field in the above-mentioned fourth message is used to indicate that the above-mentioned first neighbor node has successfully received the above-mentioned first message.

[0337] In one possible implementation, the transceiver module 1120 is also used to send a fifth message as a retransmission message of the above-mentioned first message to the above-mentioned first neighbor node if no response message in response to the above-mentioned first message is received from the above-mentioned first neighbor node within a first waiting time after sending the above-mentioned first message to the above-mentioned first neighbor node.

[0338] In one possible implementation, the second type corresponds to reliability multicast, and the destination address in the first message is a multicast address; the processing module 1110 is also used to send the first message to the control plane program or application for processing when monitoring the multicast address in the first message, and forward the first message to the first neighbor node; when not monitoring the multicast address in the first message, forward the first message to the first neighbor node.

[0339] In one possible implementation, the processing module 1110 is specifically used to add the above-mentioned first message to the message sending queue of the first neighbor node when the type of the above-mentioned first message is the above-mentioned first type; the transceiver module 1120 is also used to send the above-mentioned first message to the above-mentioned first neighbor node, wherein the third field in the above-mentioned first message sent to the above-mentioned first neighbor node indicates the third survival time of the above-mentioned first message in the network, and the third field in the first message from the above-mentioned second device indicates the first survival time of the above-mentioned first message in the network, and the above-mentioned third survival time is shorter than or equal to the above-mentioned first survival time.

[0340] In one possible implementation, the processing module 1110 is specifically used to add the above-mentioned first message to the message sending queue of the first neighbor node when the type of the above-mentioned first message is the above-mentioned first type; before sending the above-mentioned first message to the above-mentioned first neighbor node, determine the sixth survival time, the above-mentioned sixth survival time is equal to the above-mentioned first survival time minus the local processing time, and the above-mentioned local processing time is the time used by the above-mentioned first device to process the above-mentioned first message; when the above-mentioned sixth survival time is less than 0, cancel sending the above-mentioned first message to the above-mentioned first neighbor node.

[0341] In a possible implementation, the processing module 1110 is further configured to cache the first message in local storage; and delete the first message after the time for which the first message is cached in the local storage exceeds the first survival time.

[0342] In a possible implementation, the processing module 1110 is further configured to, during the process of caching the first message in the local storage, if a new neighbor node is found, add the first message to a sending queue of the new neighbor node.

[0343] In one possible implementation, the processing module 1110 is also used to determine whether the above-mentioned first message is a duplicate message based on the source address and serial number in the above-mentioned first message; the processing module 1110 is specifically used to process the above-mentioned first message according to the type of the above-mentioned first message when the above-mentioned first message is a new message (i.e., a non-duplicate message).

[0344] In some possible implementations, the communication device 1100 can correspond to the behavior and function of the third device in the above-mentioned method embodiment. For example, the communication device 1100 can be a third device, or it can be a component (such as a chip or circuit) used in a third device. The transceiver module 1120 can be used to perform all receiving or sending operations performed by the second device in the embodiments of Figures 3 to 6, such as steps 308 and 309 in the embodiment shown in Figure 3, steps 409 and 410 in the embodiment shown in Figure 4, step 507 in the embodiment shown in Figure 5, step 608 in the embodiment shown in Figure 6, and / or other processes for supporting the technology described herein. The processing module 1110 is used to perform all operations except the transceiver operations performed by the second device in the embodiments of Figures 3 to 6, such as caching the first message.

[0345] Figure 12 is a schematic diagram of the structure of another communication device 120 provided in an embodiment of the present application. The communication device in Figure 12 can be the second device, the first device, or the third device.

[0346] As shown in FIG. 12 , the communication device 120 includes at least one processor 1210 and a transceiver 1220 .

[0347] In some embodiments of the present application, the processor 1210 and the transceiver 1220 may be configured to execute functions or operations performed by the second device. For example, the transceiver 1220 executes all receiving or transmitting operations performed by the second device in the embodiments of Figures 2 to 6. The processor 1210, for example, executes all operations performed by the second device in the embodiments of Figures 2 to 6 except for the transmitting and receiving operations.

[0348] In some embodiments of the present application, the processor 1210 and the transceiver 1220 may be configured to execute functions or operations performed by the first device. For example, the transceiver 1220 executes all receiving or transmitting operations performed by the first device in the embodiments of Figures 2 to 6. The processor 1210 is configured to execute all operations performed by the first device in the embodiments of Figures 2 to 6 except for the transmitting and receiving operations.

[0349] In some embodiments of the present application, the processor 1210 and the transceiver 1220 may be configured to execute functions or operations performed by a third device. For example, the transceiver 1220 executes all receiving or transmitting operations performed by the third device in the embodiments of Figures 3 to 6. The processor 1210, for example, executes all operations performed by the third device in the embodiments of Figures 3 to 6 except for the transmitting and receiving operations.

[0350] Transceiver 1220 is used to communicate with other devices / apparatuses via a transmission medium. Processor 1210 utilizes transceiver 1220 to transmit and receive data and / or signaling, and is used to implement the methods described in the above method embodiments. Processor 1210 can implement the functions of processing module 1110, and transceiver 1220 can implement the functions of transceiver module 1120.

[0351] Optionally, transceiver 1220 may include a radio frequency circuit and an antenna. The radio frequency circuit is primarily used for converting baseband signals into radio frequency signals and processing radio frequency signals. The antenna is primarily used for transmitting and receiving radio frequency signals in the form of electromagnetic waves. Input and output devices, such as a touch screen, display, and keyboard, are primarily used for receiving user input and outputting data to the user.

[0352] Optionally, the communication device 120 may further include at least one memory 1230 for storing program instructions and / or data. The memory 1230 is coupled to the processor 1210. The coupling in the embodiments of the present application is an indirect coupling or communication connection between devices, units, or modules, which may be electrical, mechanical, or other forms, and is used for information exchange between devices, units, or modules. The processor 1210 may operate in conjunction with the memory 1230. The processor 1210 may execute program instructions stored in the memory 1230. At least one of the at least one memory may be included in the processor.

[0353] When the communication device 120 is turned on, the processor 1210 can read the software program in the memory 1230, interpret and execute the instructions of the software program, and process the data of the software program. When data needs to be sent wirelessly, the processor 1210 performs baseband processing on the data to be sent and outputs the baseband signal to the radio frequency circuit. The radio frequency circuit performs radio frequency processing on the baseband signal and then transmits the radio frequency signal to the outside in the form of electromagnetic waves through the antenna. When data is sent to the communication device, the radio frequency circuit receives the radio frequency signal through the antenna, converts the radio frequency signal into a baseband signal, and outputs the baseband signal to the processor 1210. The processor 1210 converts the baseband signal into data and processes the data.

[0354] In another implementation, the above-mentioned RF circuit and antenna can be set independently of the processor performing baseband processing. For example, in a distributed scenario, the RF circuit and antenna can be arranged remotely from the communication device.

[0355] The specific connection medium between the transceiver 1220, processor 1210, and memory 1230 is not limited in the embodiments of the present application. In FIG12 , the memory 1230, processor 1210, and transceiver 1220 are connected via a bus 1240. The bus is represented by a bold line in FIG12 . The connection methods between other components are merely illustrative and are not intended to be limiting. Such buses can be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG12 uses only one bold line, but this does not imply that there is only one bus or only one type of bus.

[0356] In the embodiments of the present application, the processor may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, and may implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present application. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of the present application may be directly implemented as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor.

[0357] Figure 13 is a schematic diagram of the structure of another communication device 130 provided in an embodiment of the present application. As shown in Figure 13, the communication device shown in Figure 13 includes a logic circuit 1301 and an interface 1302. The processing module 1110 in Figure 11 can be implemented with a logic circuit 1301, and the transceiver module 1120 in Figure 11 can be implemented with an interface 1302. Among them, the logic circuit 1301 can be a chip, a processing circuit, an integrated circuit or a system on chip (SoC) chip, etc., and the interface 1302 can be a communication interface, an input and output interface, etc. In the embodiment of the present application, the logic circuit and the interface can also be coupled to each other. The embodiment of the present application does not limit the specific connection method of the logic circuit and the interface.

[0358] In some embodiments of the present application, the logic circuit and interface may be used to execute the functions or operations performed by the aforementioned second device.

[0359] In some embodiments of the present application, the logic circuit and interface may be used to execute the functions or operations performed by the aforementioned first device.

[0360] The present application also provides a computer-readable storage medium having a computer program or instruction stored therein, and when the computer program or instruction is run on a computer, the computer executes the method of the above embodiment. The computer-readable storage medium can be any available medium that can be accessed by the computer or a data storage device such as a server or a data center that includes one or more available media integrations. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state drive (SSD)). The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.

[0361] It should be noted that those skilled in the art will appreciate that all or part of the steps in the various methods of the above embodiments can be performed by instructing relevant hardware through a program, and the program can be stored in a computer-readable storage medium. Computer-readable storage media include read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, magnetic disk storage, magnetic tape storage, or any other computer-readable medium capable of carrying or storing data.

[0362] The present application also provides a computer program product comprising instructions or a computer program that, when executed on a computer, causes the methods of the above embodiments to be performed. The computer program product comprises one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are fully or partially generated.

[0363] The above embodiments may be implemented in whole or in part through software, hardware, firmware, or any combination thereof. When implemented using software, they may be implemented in whole or in part in the form of a computer program product.

[0364] The present application also provides a communication system, comprising the second device and the first device. Optionally, the communication system further comprises the third device.

[0365] The technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer program product is stored in a storage medium and includes a number of instructions for enabling a device (which can be a terminal device, a network device, a vehicle-mounted device, a router, a server, a robot, a chip, a robot, etc.) to execute all or part of the steps of the method described in each embodiment of the present application.

Claims

1. A communication method, characterized in that: include: Generate a first message, where a first field in the first message indicates that a type of the first message is a first type or a second type, where the first type corresponds to unreliable broadcast and the second type corresponds to reliable broadcast, or where the first type corresponds to unreliable multicast and the second type corresponds to reliable multicast; Send the first message to the first device.

2. The method according to claim 1, characterized in that The reliability broadcast is used to instruct the device to respond to the received broadcast message, the unreliability broadcast is used to instruct the device not to respond to the received broadcast message, the reliability multicast is used to instruct the device to respond to the received multicast message, and the unreliability multicast is used to instruct the device not to respond to the received multicast message.

3. The method according to claim 1 or 2, characterized in that The first message further includes a second field. If the first field in the first message indicates that the type of the first message is the second type, the second field in the first message is used for the first device to respond.

4. The method according to any one of claims 1 to 3, characterized in that The first message also includes a third field, and the third field in the first message indicates a first survival time of the first message in the network.

5. The method according to any one of claims 1 to 4, characterized in that The first message also includes a sequence number, and the sequence number is used to indicate the sequence number of the first message.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: A second message is received in response to the first message, wherein the first field in the second message indicates that the type of the second message is the second type, and the second field in the second message is used to indicate that the first device has successfully received the first message.

7. The method according to claim 6, characterized in that Before receiving a second message in response to the first message, the method further includes: In a case where no response message in response to the first message is received within a first waiting time after sending the first message, a third message that is a retransmission message of the first message is sent to the first device.

8. The method according to claim 7, characterized in that The third field in the first message indicates a first survival time of the first message in the network, and the third field in the third message indicates a second survival time of the first message in the network, where the second survival time is shorter than or equal to the first survival time.

9. The method according to any one of claims 1 to 8, characterized in that The third field in the first message indicates a first survival time of the first message in the network; the method further includes: caching the first message in local storage; After the time for which the first message is cached and stored locally exceeds the first survival time, the first message is deleted.

10. A communication method, characterized in that: The method is applied to a first device, and includes: receiving a first message from a second device, where a first field in the first message indicates that a type of the first message is a first type or a second type, where the first type corresponds to a non-reliable broadcast and the second type corresponds to a reliable broadcast, or where the first type corresponds to a non-reliable multicast and the second type corresponds to a reliable multicast; The first message is processed according to the type of the first message.

11. The method according to claim 10, characterized in that The reliability broadcast is used to instruct the device to respond to the received broadcast message, the unreliability broadcast is used to instruct the device not to respond to the received broadcast message, the reliability multicast is used to instruct the device to respond to the received multicast message, and the unreliability multicast is used to instruct the device not to respond to the received multicast message.

12. The method according to claim 10 or 11, characterized in that The first message further includes a second field. If the first field in the first message indicates that the type of the first message is the second type, the second field in the first message is used for the first device to respond.

13. The method according to any one of claims 10 to 12, characterized in that The first message also includes a third field, and the third field in the first message indicates a first survival time of the first message in the network.

14. The method according to any one of claims 10 to 13, characterized in that The first message also includes a sequence number, and the sequence number is used to indicate the sequence number of the first message.

15. The method according to any one of claims 10 to 14, characterized in that The processing of the first message according to the type of the first message includes: In the case where the type of the first message is the second type, a second message in response to the first message is sent to the second device, and the first message is added to the message sending queue of the first neighbor node, the first field in the second message indicates that the type of the second message is the second type, and the second field in the second message is used to indicate that the first device has successfully received the first message.

16. The method according to claim 15, characterized in that After adding the first message to the message sending queue of the first neighbor node, the method further includes: Sending the first message to the first neighbor node; After receiving a fourth message in response to the first message from the first neighbor node, the first message is deleted from the message sending queue of the first neighbor node, the first field in the fourth message indicates that the type of the fourth message is the second type, and the second field in the fourth message is used to indicate that the first neighbor node has successfully received the first message.

17. The method according to claim 16, characterized in that The third field in the first message sent to the first neighboring node indicates the third survival time of the first message in the network, and the third field in the first message from the second device indicates the first survival time of the first message in the network, and the third survival time is shorter than or equal to the first survival time.

18. The method according to claim 15, characterized in that The second type corresponds to reliability multicast, and the destination address in the first message is a multicast address; the method further includes: In the case of monitoring the multicast address in the first message, sending the first message to a control plane program or application for processing, and forwarding the first message to the first neighboring node; In a case where the multicast address in the first message is not monitored, the first message is forwarded to the first neighbor node.

19. The method according to any one of claims 10 to 14, characterized in that The processing of the first message according to the type of the first message includes: If the type of the first message is the first type, add the first message to the message sending queue of the first neighbor node; The first message is sent to the first neighboring node, wherein the third field in the first message sent to the first neighboring node indicates a third survival time of the first message in the network, and the third field in the first message from the second device indicates the first survival time of the first message in the network, and the third survival time is shorter than or equal to the first survival time.

20. The method according to any one of claims 10 to 19, characterized in that The third field in the first message from the second device indicates a first survival time of the first message in the network; the method further includes: caching the first message in local storage; After the time for which the first message is cached and stored locally exceeds the first survival time, the first message is deleted.

21. The method according to claim 20, characterized in that The method further comprises: The summary information of the first message is locally cached for a fourth survival time, where the fourth survival time is longer than the first survival time.

22. A communication device, characterized in that: The method comprises modules or units for implementing the method according to any one of claims 1 to 9.

23. A communication device, characterized in that: The method comprises modules or units for implementing the method according to any one of claims 10 to 21.

24. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which includes program instructions. When the program instructions are executed, the computer executes the method according to any one of claims 1 to 9, or when the program instructions are executed, the computer executes the method according to any one of claims 10 to 21.

25. A communication device, characterized in that: The device comprises a processor, wherein the processor is configured to, when executing an instruction, cause the communication device to perform the method according to any one of claims 1 to 9, or cause the communication device to perform the method according to any one of claims 10 to 21.

26. The device according to claim 25, characterized in that The apparatus further comprises a memory for storing the instructions.

27. A chip, characterized in that: The chip includes a processor and a communication interface. The processor reads instructions stored in a memory through the communication interface to execute the method according to any one of claims 1 to 9, or executes the method according to any one of claims 10 to 21.

Images