Multicast communication method and related apparatus

Abstract

The application discloses a multicast communication method applied to a multicast communication system, wherein the multicast communication system comprises a multicast source and at least one client, such as a first client; the method comprises the following steps: the multicast source determines a multicast address and a multicast key; the multicast source sends a first Bluetooth message to the first client, wherein the message comprises the multicast address and the multicast key; the first client sends a second Bluetooth message to the multicast source to indicate that the first client confirms to join a multicast group; the first client configures a source address corresponding to the multicast key as a MAC address of the multicast source; the multicast source sends a first multicast message encrypted by the multicast key through WiFi multicast, wherein a source address in a MAC header of the first multicast message is the MAC address of the multicast source, and a destination address is the multicast address; the first client listens to the first multicast message based on the multicast address; and the first client parses the first multicast message by using the multicast key. Thus, large-scale multicast transmission without WiFi connection can be realized.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to multicast communication methods and related devices. Background Technology

[0002] In daily life, users can share the same file, such as a large file containing audio, video, documents, or games, with multiple other users' devices via terminal devices (e.g., mobile phones, tablets, computers). Users can also share the display screen containing videos, documents, or games to multiple other users' devices via one-to-many screen sharing. For example, in a conference screen sharing scenario, the speaker's device display can be projected onto the devices of multiple participants and the conference room monitor.

[0003] For the aforementioned one-to-many data transmission scenarios, existing technical solutions often use a multicast-to-unicast mechanism, that is, multicast frames are converted into unicast frames and then sent to each user device via WiFi unicast. This solution results in a large number of duplicate packets, leading to a significant waste of air interface resources.

[0004] Currently, how to achieve multicast communication to meet the aforementioned one-to-many data transmission requirements while avoiding the waste of air interface resources remains to be solved. Summary of the Invention

[0005] This application provides a multicast communication method and related apparatus, which can quickly establish multicast groups and realize large-scale multicast transmission without WiFi connection.

[0006] In a first aspect, this application provides a multicast communication method applied to a multicast communication system, the multicast communication system including a multicast source and at least one client, the at least one client including a first client; the method includes: the multicast source determining the multicast address and a first multicast key of the multicast group; the multicast source sending a first Bluetooth message to the first client, the first Bluetooth message being used to invite the first client to join the multicast group, the first Bluetooth message including the multicast address and the first multicast key; the first client sending a second Bluetooth message to the multicast source based on the first Bluetooth message; the second Bluetooth message being used to instruct the first client to confirm joining the multicast group; the first client configuring the source address corresponding to the first multicast key as the Media Access Control (MAC) address of the multicast source; the multicast source communicating via wireless fidelity (Wireless Fidelity)... Using Fidelity (WiFi) communication technology, a first multicast message encrypted with a first multicast key is sent via multicast. The source address in the first MAC header of the first multicast message is the MAC address of the multicast source, and the destination address in the first MAC header is the multicast address. Based on the multicast address, a first client listens to the first multicast message. The first client determines that the key corresponding to the source address in the first MAC header is the first multicast key, and uses the first multicast key to parse the data unit of the first multicast message.

[0007] In implementing the embodiments of this application, after the multicast source determines the relevant information for establishing a multicast group (e.g., multicast address, multicast key), it communicates with the client via Bluetooth to inform the client of the aforementioned information, thereby inviting the client to join the multicast group. In this way, no other third-party devices are required, and multicast group establishment is achieved quickly with Bluetooth assistance. Furthermore, during the subsequent multicast group transmission phase, the multicast source and each client do not need to establish a Wi-Fi connection. The multicast source can also send multicast messages via Wi-Fi communication technology, and each client joining the multicast group can directly listen to the multicast messages sent by the multicast source via Wi-Fi communication technology. Thus, without being limited by the number of associable Wi-Fi unicast links, and without the need for other devices to relay messages, large-scale multicast transmission without a Wi-Fi connection can be achieved, improving multicast transmission efficiency.

[0008] In one implementation, before the multicast source sends the first Bluetooth message to the first client, the method further includes: the multicast source enabling a first Virtual Access Point (VAP); the multicast source multicasting a first multicast message encrypted with a first multicast key via WiFi communication technology, including: the first VAP of the multicast source multicasting the first multicast message encrypted with the first multicast key via WiFi communication technology. Implementing the embodiments of this application, the user's terminal device can also act as a multicast source, enabling the multicast transmission of multicast messages via WiFi communication technology by enabling a VAP (e.g., a WiFi hotspot).

[0009] In one implementation, the method further includes: a multicast source receiving a first operation, the first operation being used to create a multicast group; the multicast source determining the multicast address and a first multicast key of the multicast group, including: in response to the first operation, the multicast source determining the multicast address and the first multicast key of the multicast group. Implementing the embodiments of this application, a user can trigger the multicast source to establish a multicast group through the first operation. For example, the multicast source has a user interface (UI) entry point for multicast services, and the user can trigger the establishment of a multicast group through a first operation applied to this UI entry point.

[0010] In one implementation, before the multicast source sends the first Bluetooth message to the first client, the method further includes: the multicast source scanning for nearby Bluetooth devices that support multicast communication; the multicast source displaying at least one scanned Bluetooth device, including the first client; the multicast source receiving a second operation to invite the first client to join the multicast group; and in response to the second operation, the multicast source establishing a Bluetooth connection with the first client. By implementing this embodiment, when the multicast source establishes a multicast group, it can activate the Bluetooth discovery service to scan for nearby Bluetooth devices that support multicast. After scanning for a Bluetooth device, the multicast source can establish a Bluetooth connection with the user-selected Bluetooth device. Thus, through this Bluetooth connection, the multicast source can directly invite the device to join the multicast group, eliminating the need for other devices to distribute messages between the multicast source and the client, thereby improving the management efficiency of the multicast group.

[0011] In one implementation, before the multicast source displays at least one scanned Bluetooth device, the method further includes: a first client receiving a third operation; in response to the third operation, the first client broadcasts a first discovery signal via Bluetooth, the first discovery signal indicating that the first client supports multicast communication; and the multicast source scans for the first client based on the first discovery signal. By implementing embodiments of this application, a user can trigger the client to start the Bluetooth discovery service through the third operation, broadcast a discovery signal via Bluetooth, and carry a multicast capability identifier in the discovery signal to facilitate discovery by the multicast source, thereby establishing a Bluetooth connection with the multicast source.

[0012] In one implementation, before the multicast source sends a first Bluetooth message to the first client, the method further includes: in response to a first operation, the multicast source broadcasts a second discovery signal via Bluetooth; based on the second discovery signal detected by Bluetooth, the first client establishes a Bluetooth connection with the multicast source; the first client sends a third Bluetooth message to the multicast source, the third Bluetooth message being used to request joining the multicast group; the multicast source sending the first Bluetooth message to the first client includes: in response to the third Bluetooth message, the multicast source sending the first Bluetooth message to the first client. Implementing this embodiment, a user can trigger the multicast source to start the Bluetooth discovery service and broadcast a discovery signal via Bluetooth through a first operation, so that it can be discovered by the client and thus establish a Bluetooth connection with the client. After the multicast source and the client establish a Bluetooth connection, the client can actively request to join the multicast group through this Bluetooth connection.

[0013] In one implementation, after the first client sends the second Bluetooth message to the multicast source, the method further includes: disconnecting the Bluetooth connection between the multicast source and the first client. By implementing this embodiment, after the multicast source invites a client to join the multicast group via Bluetooth, the Bluetooth connection between the multicast source and the client can be disconnected, and the relevant Bluetooth connection information can be deleted, thereby saving Bluetooth resources and reducing device load.

[0014] In one implementation, before the multicast source sends the first Bluetooth message to the first client, the method further includes: the multicast source assigning a first IP address to its first VAP and a second IP address to the client's second VAP; the first Bluetooth message also includes the first IP address and the second IP address; the first IP address and the second IP address are used to encapsulate multicast packets, the source IP address in the multicast packet sent by the multicast source is the first IP address, and the source IP address in the multicast packet sent by the first client is the second IP address. By implementing the embodiments of this application, the multicast source can assign IP addresses for multicast to both the device and the client.

[0015] In one implementation, the method further includes: based on a second Bluetooth message, the first multicast source adds the multicast user information of the first client to the multicast device list; the multicast device list is used to store the multicast user information of each client in the multicast group, and the multicast user information of the first client includes the MAC address and the second IP address of the first client. Implementing the embodiments of this application, after the multicast source invites a client to join the multicast group, it stores the multicast user information of each client to facilitate the management of clients in the multicast group.

[0016] In one implementation, before the multicast source sends the first Bluetooth message to the first client, the method further includes: the multicast source generating a virtual multicast source address; the multicast source configuring the source address corresponding to the first multicast key as the virtual multicast source address; the first Bluetooth message also includes a virtual broadcast source address, and the source address in the MAC header of the multicast message sent by the client in the multicast group is the virtual multicast source address. In implementing this embodiment, each client uses the same virtual multicast source address, so that the multicast source can parse the multicast messages of all clients using the multicast key corresponding to the virtual multicast source address.

[0017] In one implementation, the method further includes: a first client multicasting a second multicast message encrypted with a first multicast key via WiFi communication technology, wherein the source address in the second MAC header of the second multicast message is a virtual multicast source address, and the destination address in the second MAC header is a multicast address; based on the multicast address, the multicast source listens to the second multicast message; the multicast source determines that the key corresponding to the source address in the second MAC header is the first multicast key, and uses the first multicast key to parse the data unit of the second multicast message. In implementing this embodiment, each client uses the same virtual multicast source address, so that the multicast source can parse the multicast messages of all clients using the multicast key corresponding to the virtual multicast source address.

[0018] In one implementation, after the multicast source sends a first Bluetooth message to the first client, the method further includes: the first client activating a second VAP based on the first Bluetooth message; the first client then multicasting a second multicast message encrypted with a first multicast key via WiFi communication technology, which includes: the second VAP of the first client multicasting the second multicast message encrypted with the first multicast key via WiFi communication technology. Implementing this embodiment of the application eliminates the need for other third-party devices, enabling clients in a multicast group to multicast and send multicast messages, with the multicast source listening to these messages, thus achieving efficient multicast transmission.

[0019] In one implementation, the data unit of a multicast message is a MAC Service Data Unit (MSDU).

[0020] In one implementation, the multicast message types include signaling frames and data frames. The multicast types of the signaling frames include control signaling frames and signaling acknowledgment frames. The first multicast message includes a first control signaling frame, and the second multicast message includes a first signaling acknowledgment frame. The first signaling acknowledgment frame is generated by the first client based on the first control signaling frame and is used to indicate the reception status of the control signaling frame sent by the multicast source. Implementing the embodiments of this application provides a feedback mechanism for signaling frame transmission. The multicast source can send control signaling frames to any client in the multicast group, and the client can provide feedback on the reception status of the control signaling frames, so that the multicast source can make further decisions based on the reception status, thereby improving the reliability of signal transmission.

[0021] In one implementation, the multicast message types include signaling frames and data frames. The multicast types of the signaling frames include control signaling frames and signaling acknowledgment frames. The second multicast message includes a first control signaling frame, and the first multicast message includes a first signaling acknowledgment frame. The first signaling acknowledgment frame is generated by the multicast source based on the first control signaling frame and is used to indicate the reception status of the control signaling frame sent by the first client. Implementing the embodiments of this application provides a feedback mechanism for signaling frame transmission. Any client in the multicast group can send a control signaling frame to the multicast source, and the multicast source can provide feedback on the reception status of the control signaling frame, allowing the client to make further decisions based on the reception status, thereby improving the reliability of multicast transmission.

[0022] In one implementation, the data unit of a signaling frame includes the actual destination address corresponding to the receiving end of the signaling frame and the actual source address corresponding to the sending end of the signaling frame; the data unit of a control signaling frame further includes a control identifier and a data payload, the data payload being used to transmit valid control signaling, and the control identifier being used to indicate the number of the control signaling frame; the data unit of a signaling acknowledgment frame further includes acknowledgment information, the acknowledgment information being used to indicate the reception status of the control signaling frames sent by the receiving end of the signaling acknowledgment frame. By implementing the embodiments of this application, the signaling frame can carry the actual destination address corresponding to the receiving end and the actual source address corresponding to the sending end, so that the receiving end can determine whether the signaling frame is sent to its own device and whether the sending end belongs to a multicast group; thus, a one-to-one unicast between the multicast source and the client can be indirectly achieved through multicast transmission.

[0023] In one implementation, a first client sets up a receive window for the multicast source to maintain reception information of control signaling frames from the multicast source; the multicast source sets up a send window for the first client to maintain transmission information of control signaling frames sent to the first client; the method further includes: the first client updating the receive window corresponding to the multicast source based on the first control signaling frame, and determining a first signaling acknowledgment frame based on the updated receive window; the first signaling acknowledgment frame indicating that the second control signaling frame maintained by the send window has not been received; the multicast source updating the send window corresponding to the first client based on the first signaling acknowledgment frame, and determining whether to retransmit the second control signaling frame. Implementing the embodiments of this application provides a feedback mechanism and a retransmission mechanism for signaling frame transmission; based on the reception status reported by the client, the multicast source can determine whether to retransmit the control signaling frame that was not received by the client, thereby improving the reliability of multicast transmission.

[0024] In one implementation, the signaling frame further includes a multicast type; when the multicast type of the signaling frame is a control signaling frame, the signaling frame further includes a subtype of the control signaling frame, which includes a first subtype and a second subtype, and the processing modules corresponding to the first subtype and the second subtype are different; the method further includes: the first client submits the first control signaling frame to the processing module corresponding to the first subtype for processing according to the first subtype in the first control signaling frame. By implementing the embodiments of this application, the control signaling frame can be classified and processed according to its subtype.

[0025] In one implementation, the receiving window comprises M small windows, where M is a positive integer. Each small window within the receiving window sequentially maintains the reception information of control signaling frames according to the control identifiers of the received control signaling frames from the multicast source. The reception information maintained by one small window within the receiving window includes the control identifier and reception identifier of the control signaling frame. The reception identifier indicates whether the control signaling frame has been received. The first upper edge (UE) of the receiving window indicates the maximum value of the control identifiers of the received control signaling frames maintained by the receiving window, and the first lower edge (LE) of the receiving window indicates the minimum value of the control identifiers of the unreceived control signaling frames maintained by the receiving window. The sending window also comprises M small windows. Each small window within the sending window sequentially maintains the transmission information of control signaling frames according to the control identifiers of the control signaling frames sent to the first client. The transmission information maintained by one small window includes the control identifiers of the control signaling frames. The second UE of the sending window indicates the maximum value of the control identifiers of the unreceived control signaling frames maintained by the sending window, and the second LE of the sending window indicates the minimum value of the control identifiers of the unreceived control signaling frames maintained by the sending window. In implementing the embodiments of this application, each client can maintain its sent and received control signaling frames for a multicast source using a sending window and a receiving window; the multicast source can also maintain its sent and received control signaling frames for each client in the multicast group using a sending window and a receiving window; thus, feedback can be performed based on the receiving window and retransmission can be performed based on the sending window to improve the reliability of multicast transmission.

[0026] In one implementation, the confirmation information in the first signaling confirmation frame includes a first UE and a first LE in the receiving window, as well as a bitmap. The bitmap sequentially indicates the reception status of control signaling frames maintained by the small window pointed to by the first LE to the small window pointed to by the first UE in the receiving window. By implementing the embodiments of this application, the client can use the UE, LE, and bitmap in the receiving window to provide feedback on the reception status of control signaling frames, so that the multicast source can make further decisions based on the reception status, thereby improving the reliability of multicast transmission.

[0027] In one implementation, the first client updates the receiving window corresponding to the multicast source based on the first control signaling frame, including: determining, based on the actual destination address in the first control signaling frame, that it is a multicast frame sent to the device; and if, based on the actual source address in the first control signaling frame, the sender of the first control signaling frame belongs to a multicast group, then obtaining the receiving window corresponding to the multicast source based on the actual source address in the first control signaling frame, and updating the receiving window corresponding to the multicast source based on the first control signaling frame. In implementing this embodiment, the signaling frame can carry the actual destination address corresponding to the receiving end and the actual source address corresponding to the sending end, so that the receiving end can determine whether the signaling frame is sent to the device and whether the sending end belongs to a multicast group; thus, a one-to-one unicast between the multicast source and the client can be indirectly achieved through multicast transmission.

[0028] In one implementation, the first client updates the receiving window corresponding to the multicast source based on the first control signaling frame, including: determining a first index for maintaining the small window of the first control signaling frame according to the control identifier of the first control signaling frame, the first index being equal to the remainder after dividing the control identifier of the first control signaling frame by M; when the receiving window is determined to be full according to the first LE and the first UE, clearing the small window pointed to by the first LE up to the small window corresponding to the first index; when the receiving window is determined not to be full, if the receiving identifier of the small window corresponding to the first index is a first value, discarding the first control signaling frame; if the receiving identifier of the small window corresponding to the first index is a second value, updating the receiving identifier of the small window corresponding to the first index to the first value; a receiving identifier of the first value indicates that the control signaling frame has been received; a receiving identifier of the second value indicates that the control signaling frame has not been received; when the control identifier of the first control signaling frame is greater than the first UE, updating the value of the first UE to the control identifier of the first control signaling frame; determining the first small window pointed to by the first LE and the first small window in the subsequent small windows with a receiving identifier of the second value, and updating the value of the first LE to the control identifier of the first small window. By implementing the embodiments of this application, clients in a multicast group can update the receiving window corresponding to the multicast source based on control signaling frames from the multicast source.

[0029] In one implementation, the multicast source updates the sending window corresponding to the first client of the UE based on the first signaling confirmation frame, including: determining whether the multicast frame is to be sent to the device based on the actual destination address in the first signaling confirmation frame, and determining whether the sender of the first control signaling frame belongs to the multicast group based on the actual source address in the first signaling confirmation frame; obtaining the sending window corresponding to the first client based on the actual source address in the first signaling confirmation frame; and updating the sending window corresponding to the first client based on the first signaling confirmation frame. In implementing this embodiment, the signaling frame can carry the actual destination address corresponding to the receiver and the actual source address corresponding to the sender, so that the receiver can determine whether the signaling frame is to be sent to the device and whether the sender belongs to the multicast group; thus, a one-to-one unicast between the multicast source and the client can be indirectly achieved through multicast transmission.

[0030] In one implementation, the multicast source updates the sending window corresponding to the first client based on the first signaling confirmation frame, including: determining, based on the confirmation information in the first signaling confirmation frame, that the first LE is greater than or equal to the second LE of the sending window, and the first UE is less than or equal to the second UE, the multicast source updates the sending window corresponding to the first client based on the first signaling confirmation frame. By implementing the embodiments of this application, the multicast source can filter out outdated or erroneous signaling confirmation frames based on the LE and UE in the signaling confirmation frame.

[0031] In one implementation, the transmission information maintained by a small window within the transmission window also includes a transmission status and a storage address. The transmission status indicates whether a control signaling frame has been received, and the storage address indicates the buffer address of the control signaling frame. The multicast source updates the transmission window corresponding to the first client based on the first signaling acknowledgment frame, including: when the first LE is greater than the second LE, clearing the small window pointed to by the second LE up to the small window preceding the small window pointed to by the first LE, and updating the value of the second LE to the value of the first LE; when the first LE equals the second LE, traversing the small window pointed to by the first LE up to the small window pointed to by the first UE, and releasing the control signaling frame buffered at the storage address of the second small window where the bitmap indicates that the control signaling frame has been received. By implementing this embodiment, the multicast source can update the transmission window corresponding to any client in the multicast group based on a signaling acknowledgment frame from any client in the multicast group.

[0032] In one implementation, the transmission information maintained by a small window of the sending window also includes a retransmission flag and a retransmission count. The retransmission flag indicates whether the control signaling frame has been retransmitted within the current retransmission period, and the retransmission count indicates the number of times the control signaling frame has been retransmitted. The determination of whether to retransmit the second control signaling frame includes: when the first LE equals the second LE, traversing the small windows pointed to by the first LE in the sending window to the small windows pointed to by the first UE, identifying the third small window where the control signaling frame indicated by the bitmap has not been received; if the second control signaling frame maintained by the third small window satisfies the retransmission condition, determining to retransmit the second control signaling frame to the first client, updating the retransmission flag corresponding to the third small window to a first value, and incrementing the retransmission count by 1; the retransmission flag taking the first value indicates that the control signaling frame has been retransmitted within the current retransmission period. Implementing this application embodiment provides a retransmission mechanism for signaling frame transmission; for signaling confirmation frames fed back by the client, the multicast source can determine whether to retransmit the control signaling frame that was not received by the client, thereby improving the reliability of multicast transmission.

[0033] In one implementation, the retransmission conditions include: the retransmission flag of the third small window is a second value, and the number of retransmissions is less than a first preset value; the retransmission flag is a second value, indicating that the control signaling frame has not been retransmitted in this retransmission period.

[0034] In one implementation, the method further includes: the first client periodically timeouting the receiving window corresponding to the multicast source it maintains. By implementing the embodiments of this application, timeout processing can be performed periodically on each receiving window to avoid the receiving window becoming full and unable to continue processing the receiving information of new control signaling frames.

[0035] In one implementation, the reception information maintained by a small window of the receiving window also includes a polling count. The first client performs periodic timeout processing on the receiving window corresponding to the multicast source it maintains, including: determining the fourth small window with a second value among the small windows pointed to by the first LE to the small windows pointed to by the first UE in the receiving window, and incrementing the polling count of the fourth small window by 1; when the polling count of the fourth small window is greater than a second preset value, clearing the small windows pointed to by the first LE to the fourth small window; determining the first fifth small window with a second value after the fourth small window in the receiving window; and updating the control identifier of the fifth small window to the first LE of the receiving window. By implementing the embodiments of this application, timeout processing can be performed on each receiving window periodically to avoid the receiving window being full and unable to continue processing the reception information of new control signaling frames.

[0036] In one implementation, the method further includes: the multicast source periodically times out the transmission window corresponding to the first client it maintains. By implementing the embodiments of this application, timeout processing can be performed periodically on each transmission window to avoid the transmission window becoming full and unable to continue processing the transmission information of new control signaling frames.

[0037] In one implementation, the multicast source periodically times out the transmission window corresponding to the first client it maintains, including: traversing the small windows pointed to by the second LE in the transmission window to the small windows pointed to by the second UE, and the sixth small window with a transmission status of the second value; the transmission status being the second value, indicating that the control signaling frame has not been received; incrementing the polling count corresponding to the sixth small window by 1; when the polling count of the sixth small window is greater than or equal to a third preset value, determining whether the sixth small window meets the retransmission condition; if the retransmission condition is met, determining to retransmit the control signaling frame maintained by the sixth small window, setting the polling count of the sixth small window to 0, setting the retransmission flag to the first value, and incrementing the retransmission count by 1; if the retransmission condition is not met and the retransmission count exceeds a fifth preset value, clearing the sixth small window and releasing the control signaling frame cached in the storage address of the sixth small window; determining that the second LE is equal to the control flag of the small window with the second transmission status and the smallest control flag in the transmission window. By implementing the embodiments of this application, timeout processing can be performed on each transmission window periodically to avoid the transmission window being full and unable to continue processing the transmission information of new control signaling frames.

[0038] In one implementation, the method further includes: a first client establishing a Bluetooth connection with a multicast source and sending a fourth Bluetooth message to the multicast source, the fourth Bluetooth message being used to request leaving the multicast group; the multicast source sending a fifth Bluetooth message to the first client and deleting the multicast user information of the first client, the fifth Bluetooth message being used to indicate confirmation that the first client has left the multicast group; the first client listening to the fifth Bluetooth message and deleting the second multicast group information on the client side based on the fifth Bluetooth message; the second multicast group information including a multicast address and a first multicast key; and the first client and the multicast source disconnecting the Bluetooth connection. By implementing the embodiments of this application, the members in the multicast group are dynamic; any client can actively leave the multicast group and notify the multicast source via Bluetooth connection, so that the multicast source can manage the clients in the multicast group.

[0039] In one implementation, the first client establishes a Bluetooth connection with the multicast source and sends a fourth Bluetooth message to the multicast source, including: the first client receiving a fourth operation; in response to the fourth operation, the first client establishes a Bluetooth connection with the multicast source and sends a fourth Bluetooth message to the multicast source; the method further includes: in response to the fourth operation, the first client closes the multicast application. By implementing the embodiments of this application, a user can trigger the client to actively leave the multicast group and close the multicast application through the fourth operation.

[0040] In one implementation, the multicast source broadcasts a sixth Bluetooth message and deletes the first multicast group information on its side. The sixth Bluetooth message indicates the deletion of the multicast group, and the first multicast group information includes a list of multicast devices, a first multicast key, and a multicast address. A first client listens to the sixth Bluetooth message and deletes the second multicast group information on its side based on the message. The second multicast group information includes the multicast address and the first multicast key. Implementing this embodiment, the members in the multicast group are dynamic; the multicast source can delete the multicast group and notify the clients in the group via Bluetooth broadcast, allowing the clients to delete the relevant information of the multicast group.

[0041] In one implementation, the multicast source broadcasts a sixth Bluetooth message, including: the multicast source receiving a fifth operation; in response to the fifth operation, the multicast source broadcasts a sixth Bluetooth message; the method further includes: in response to the fifth operation, closing the multicast application. By implementing the embodiments of this application, a user can trigger the client to actively leave the multicast group and close the multicast application through the fifth operation.

[0042] Secondly, this application provides a multicast communication method, the method comprising: a multicast source determining a multicast address and a first multicast key for a multicast group; the multicast source sending a first Bluetooth message to a first client, the first Bluetooth message being used to invite the first client to join the multicast group, the first Bluetooth message including the multicast address and the first multicast key; the multicast source receiving a second Bluetooth message sent by the first client; the second Bluetooth message being used to instruct the first client to confirm joining the multicast group, wherein the source address corresponding to the first multicast key on the first client side is the MAC address of the multicast source; the multicast source multicasting a first multicast message encrypted with the first multicast key via WiFi communication technology, wherein the source address in the first MAC header of the first multicast message is the MAC address of the multicast source, and the destination address in the first MAC header is the multicast address.

[0043] In implementing the embodiments of this application, after the multicast source determines the relevant information for establishing a multicast group (e.g., multicast address, multicast key), it communicates with the client via Bluetooth to inform the client of the aforementioned information, thereby inviting the client to join the multicast group. In this way, no other third-party devices are required, and multicast group establishment is achieved quickly with Bluetooth assistance. Furthermore, during the subsequent multicast group transmission phase, the multicast source and each client do not need to establish a Wi-Fi connection. The multicast source can also send multicast messages via Wi-Fi communication technology, and each client joining the multicast group can directly listen to the multicast messages sent by the multicast source via Wi-Fi communication technology. Thus, without being limited by the number of associable Wi-Fi unicast links, and without the need for other devices to relay messages, large-scale multicast transmission without a Wi-Fi connection can be achieved, improving multicast transmission efficiency.

[0044] In one implementation, before the multicast source sends the first Bluetooth message to the first client, the method further includes: the multicast source enabling a first virtual access point (VAP); the multicast source sending a first multicast message encrypted with a first multicast key via WiFi communication technology, including: the first VAP of the multicast source sending the first multicast message encrypted with the first multicast key via WiFi communication technology.

[0045] In one implementation, the method further includes: a multicast source receiving a first operation, the first operation being used to create a multicast group; the multicast source determining the multicast address and a first multicast key of the multicast group, including: in response to the first operation, the multicast source determining the multicast address and the first multicast key of the multicast group.

[0046] In one implementation, before the multicast source sends the first Bluetooth message to the first client, the method further includes: the multicast source scanning for nearby Bluetooth devices that support multicast communication; the multicast source displaying at least one scanned Bluetooth device, the at least one Bluetooth device including the first client; the multicast source receiving a second operation, the second operation being used to invite the first client to join the multicast group; and in response to the second operation, the multicast source establishing a Bluetooth connection with the first client.

[0047] In one implementation, after the multicast source receives the second Bluetooth message sent by the first client, it further includes: disconnecting the Bluetooth connection between the multicast source and the first client.

[0048] In one implementation, before the multicast source sends the first Bluetooth message to the first client, the method further includes: the multicast source assigning a first IP address to its first VAP and assigning a second IP address to the client's second VAP; the first Bluetooth message also includes the first IP address and the second IP address; the first IP address and the second IP address are used to encapsulate the multicast message, the source IP address in the multicast message sent by the multicast source is the first IP address, and the source IP address in the multicast message sent by the first client is the second IP address.

[0049] In one implementation, the method further includes: based on a second Bluetooth message, the first multicast source adds multicast user information of the first client to the multicast device list; the multicast device list is used to store multicast user information of each client in the multicast group, and the multicast user information of the first client includes the MAC address and the second IP address of the first client.

[0050] In one implementation, before the multicast source sends the first Bluetooth message to the first client, the method further includes: the multicast source generating a virtual multicast source address; the multicast source configuring the source address corresponding to the first multicast key as the virtual multicast source address; the first Bluetooth message also includes a virtual anchor source address, and the source address in the MAC header of the multicast message sent by the client in the multicast group is the virtual multicast source address.

[0051] In one implementation, the method further includes: based on the multicast address, the multicast source listens to the second multicast message from the first client via WiFi communication technology; the source address in the second MAC header of the second multicast message is a virtual multicast source address, and the destination address in the second MAC header is a multicast address; the multicast source determines that the key corresponding to the source address in the second MAC header is a first multicast key, and uses the first multicast key to parse the data unit of the second multicast message.

[0052] In one implementation, the data unit of a multicast message is a MAC Service Data Unit (MSDU).

[0053] In one implementation, the multicast message types include signaling frames and data frames. The multicast types of signaling frames include control signaling frames and signaling acknowledgment frames. The first multicast message includes a first control signaling frame, and the second multicast message includes a first signaling acknowledgment frame. The first signaling acknowledgment frame is generated by the first client based on the first control signaling frame and is used to indicate the reception status of the control signaling frame sent by the multicast source.

[0054] In one implementation, the multicast message type includes signaling frames and data frames, and the multicast type of the signaling frames includes control signaling frames and signaling acknowledgment frames; the second multicast message includes a first control signaling frame, and the first multicast message includes a first signaling acknowledgment frame. The first signaling acknowledgment frame is generated by the multicast source based on the first control signaling frame, and the first signaling acknowledgment frame is used to indicate the reception status of the control signaling frame sent by the first client.

[0055] In one implementation, the first client sets up a receive window for the multicast source to maintain the reception information of control signaling frames from the multicast source; the multicast source sets up a send window for the first client to maintain the send information of control signaling frames sent to the first client; a first control signaling frame is used by the first client to update the receive window corresponding to the multicast source, and to determine a first signaling acknowledgment frame based on the updated receive window; the first signaling acknowledgment frame indicates that the second control signaling frame maintained by the send window has not been received; the method further includes: the multicast source updating the send window corresponding to the first client based on the first signaling acknowledgment frame to determine whether to retransmit the second control signaling frame.

[0056] In one implementation, the data unit of the signaling frame includes the actual destination address corresponding to the receiving end of the signaling frame and the actual source address corresponding to the sending end of the signaling frame; the data unit of the control signaling frame also includes a control identifier and a data payload, the data payload being used to transmit valid control signaling, and the control identifier being used to indicate the number of the control signaling frame; the data unit of the signaling acknowledgment frame also includes acknowledgment information, the acknowledgment information being used to indicate the reception status of the control signaling frames sent by the receiving end of the signaling acknowledgment frame.

[0057] In one implementation, the signaling frame also includes a multicast type; when the multicast type of the signaling frame is a control signaling frame, the signaling frame also includes a subtype of control signaling frame, the subtype of control signaling frame includes a first subtype and a second subtype, and the processing modules corresponding to the first subtype and the second subtype are different.

[0058] In one implementation, the receiving window comprises M small windows, where M is a positive integer. Each small window within the receiving window sequentially maintains the reception information of control signaling frames according to the control identifiers of the received control signaling frames from the multicast source. The reception information maintained by one small window within the receiving window includes the control identifier and reception identifier of the control signaling frame. The reception identifier indicates whether the control signaling frame has been received. The first upper edge (UE) of the receiving window indicates the maximum value of the control identifiers of the received control signaling frames maintained by the receiving window, and the first lower edge (LE) of the receiving window indicates the minimum value of the control identifiers of the unreceived control signaling frames maintained by the receiving window. The sending window also comprises M small windows. Each small window within the sending window sequentially maintains the transmission information of control signaling frames according to the control identifiers of the control signaling frames sent to the first client. The transmission information maintained by one small window includes the control identifiers of the control signaling frames. The second UE of the sending window indicates the maximum value of the control identifiers of the unreceived control signaling frames maintained by the sending window, and the second LE of the sending window indicates the minimum value of the control identifiers of the unreceived control signaling frames maintained by the sending window.

[0059] In one implementation, the confirmation information in the first signaling confirmation frame includes a first UE and a first LE in the receiving window, as well as a bitmap, which sequentially indicates the reception status of control signaling frames maintained by the small window pointed to by the first LE to the small window pointed to by the first UE in the receiving window.

[0060] In one implementation, the multicast source updates the sending window corresponding to the first client of the UE based on the first signaling confirmation frame, including: determining, based on the actual destination address in the first signaling confirmation frame, that it is a multicast frame to be sent to this device, and determining, based on the actual source address in the first signaling confirmation frame, whether the sender of the first control signaling frame belongs to the multicast group, obtaining the sending window corresponding to the first client based on the actual source address in the first signaling confirmation frame, and updating the sending window corresponding to the first client based on the first signaling confirmation frame.

[0061] In one implementation, the multicast source updates the sending window corresponding to the first client based on the first signaling confirmation frame, including: determining, based on the confirmation information in the first signaling confirmation frame, that the first LE is greater than or equal to the second LE of the sending window, and the first UE is less than or equal to the second UE, the multicast source updates the sending window corresponding to the first client based on the first signaling confirmation frame.

[0062] In one implementation, the transmission information maintained by a small window within the transmission window also includes a transmission status and a storage address. The transmission status indicates whether a control signaling frame has been received, and the storage address indicates the buffer address of the control signaling frame. The multicast source updates the transmission window corresponding to the first client based on the first signaling acknowledgment frame, including: when the first LE is greater than the second LE, clearing the small window pointed to by the second LE in the transmission window up to the small window before the small window pointed to by the first LE, and updating the value of the second LE to the value of the first LE; when the first LE is equal to the second LE, traversing the small window pointed to by the first LE in the transmission window up to the small window pointed to by the first UE, the second small window indicated by the bitmap where the control signaling frame has been received, and releasing the control signaling frame buffered at the storage address of the second small window.

[0063] In one implementation, the transmission information maintained by a small window of the transmission window also includes a retransmission flag and a retransmission count. The retransmission flag indicates whether the control signaling frame has been retransmitted within the current retransmission period, and the retransmission count indicates the number of times the control signaling frame has been retransmitted. The determination of whether to retransmit the second control signaling frame includes: when the first LE equals the second LE, traversing the small windows pointed to by the first LE in the transmission window to the small windows pointed to by the first UE, and the third small window where the control signaling frame indicated by the bitmap has not been received. If the second control signaling frame maintained by the third small window meets the retransmission condition, it is determined to retransmit the second control signaling frame to the first client, and the retransmission flag corresponding to the third small window is updated to the first value, and the retransmission count is incremented by 1. The retransmission flag being the first value indicates that the control signaling frame has been retransmitted within the current retransmission period.

[0064] In one implementation, the retransmission conditions include: the retransmission flag of the third small window is a second value, and the number of retransmissions is less than a first preset value; the retransmission flag being a second value indicates that the control signaling frame has not been retransmitted in this retransmission period.

[0065] In one implementation, the method further includes: the multicast source periodically times out the sending window corresponding to the first client it maintains.

[0066] In one implementation, the multicast source performs periodic timeout processing on the sending window corresponding to the first client it maintains, including: traversing the small window pointed to by the second LE in the sending window to the small window pointed to by the second UE, and the sixth small window with a sending status of the second value; the sending status being the second value indicates that the control signaling frame has not been received; incrementing the polling count corresponding to the sixth small window by 1; when the polling count of the sixth small window is greater than or equal to a third preset value, determining whether the sixth small window meets the retransmission condition; when the retransmission condition is met, determining to retransmit the control signaling frame maintained by the sixth small window, setting the polling count of the sixth small window to 0, setting the retransmission flag to the first value, and incrementing the retransmission count by 1; when the retransmission condition is not met and the retransmission count exceeds a fifth preset value, clearing the sixth small window and releasing the control signaling frame cached in the storage address of the sixth small window; determining that the second LE is equal to the control flag of the small window with a sending status of the second value and the smallest control flag in the sending window.

[0067] In one implementation, the method further includes: the multicast source and the first client establishing a Bluetooth connection; the multicast source receiving a fourth Bluetooth message sent by the first client, the fourth Bluetooth message being used to request to leave the multicast group; the multicast source sending a fifth Bluetooth message to the first client and deleting the multicast user information of the first client, the fifth Bluetooth message being used to indicate confirmation that the first client has left the multicast group; and the multicast source and the first client disconnecting the Bluetooth connection.

[0068] In one implementation, the method further includes: the multicast source broadcasts a sixth Bluetooth message and deletes the first multicast group information on the multicast source side; the sixth Bluetooth message is used to indicate the deletion of the multicast group, and the first multicast group information includes a list of multicast devices, a first multicast key, and a multicast address.

[0069] In one implementation, the multicast source Bluetooth broadcasts a fifth Bluetooth message, including: the multicast source receiving a fifth operation; in response to the fifth operation, the multicast source Bluetooth broadcasts a sixth Bluetooth message; the method further includes: in response to the fifth operation, closing the multicast application.

[0070] Thirdly, this application provides a multicast communication method, the method comprising: a first client receiving a first Bluetooth message sent by a multicast source, the first Bluetooth message being used to invite the first client to join a multicast group, the first Bluetooth message including the multicast address of the multicast group and a first multicast key; the first client sending a second Bluetooth message to the multicast source based on the first Bluetooth message; the second Bluetooth message being used to instruct the first client to confirm joining the multicast group; the first client configuring the source address corresponding to the first multicast key as the MAC address of the multicast source; based on the multicast address, the first client listening to a first multicast message sent by the multicast source via WiFi communication technology, the source address in the first MAC header of the first multicast message being the MAC address of the multicast source, and the destination address in the first MAC header being the multicast address; the first client determining that the key corresponding to the source address in the first MAC header is the first multicast key, and using the first multicast key to parse the data unit of the first multicast message.

[0071] In implementing the embodiments of this application, the multicast source interacts with the client via Bluetooth to inform the client of relevant multicast group information (such as multicast address and multicast key) to invite the client to join the multicast group. This allows for quick multicast group establishment via Bluetooth assistance without the need for other third-party devices. Furthermore, during subsequent multicast group transmission, the multicast source and clients do not need to establish a Wi-Fi connection. The multicast source can send multicast messages via Wi-Fi communication technology, and clients joining the multicast group can directly listen to the multicast messages sent by the multicast source via Wi-Fi communication technology. Thus, without being limited by the number of associable Wi-Fi unicast links or requiring other devices for message relay, large-scale multicast transmission without a Wi-Fi connection can be achieved, improving multicast transmission efficiency.

[0072] In one implementation, the method further includes: a first client activating a second VAP based on a first Bluetooth message; the first client listening to a first multicast message sent by a multicast source via WiFi communication technology, including: the second VAP of the first client listening to the first multicast message sent by the multicast source via WiFi communication technology.

[0073] In one implementation, before the first client receives the first Bluetooth message sent by the multicast source, the method further includes: the first client receiving a third operation; in response to the third operation, the first client broadcasts a first discovery signal via Bluetooth, the first discovery signal indicating that the first client supports multicast communication, the first discovery signal being used to establish a Bluetooth connection with the multicast source; and the first client establishing a Bluetooth connection with the multicast source.

[0074] In one implementation, before the first client receives the first Bluetooth message sent by the multicast source, the method further includes: the first client Bluetooth listens for a second discovery signal from the multicast source; based on the second discovery signal, the first client establishes a Bluetooth connection with the multicast source; the first client sends a third Bluetooth message to the multicast source, the third Bluetooth message being used to request to join the multicast group, and the first Bluetooth message being sent by the multicast source based on the third Bluetooth message.

[0075] In one implementation, after the first client sends the second Bluetooth message to the multicast source, the method further includes: disconnecting the Bluetooth connection between the multicast source and the first client.

[0076] In one implementation, the first Bluetooth message also includes a virtual multicast source address. The source address in the MAC header of the multicast message sent by the first client is the virtual multicast source address, and the source address corresponding to the first multicast key on the multicast source side is the virtual multicast source address.

[0077] In one implementation, the method further includes: a first client sending a second multicast message encrypted with a first multicast key via WiFi communication technology, wherein the source address in the second MAC header of the second multicast message is a virtual multicast source address, and the destination address in the second MAC header is a multicast address.

[0078] In one implementation, the method further includes: a first client activating a second VAP based on a first Bluetooth message; the first client sending a second multicast message encrypted with a first multicast key via WiFi communication technology, comprising: the second VAP of the first client sending the second multicast message encrypted with the first multicast key via WiFi communication technology.

[0079] In one implementation, the data unit of a multicast message is a MAC Service Data Unit (MSDU).

[0080] In one implementation, the multicast message types include signaling frames and data frames. The multicast types of signaling frames include control signaling frames and signaling acknowledgment frames. The first multicast message includes a first control signaling frame, and the second multicast message includes a first signaling acknowledgment frame. The first signaling acknowledgment frame is generated by the first client based on the first control signaling frame and is used to indicate the reception status of the control signaling frame sent by the multicast source.

[0081] In one implementation, the multicast message type includes signaling frames and data frames, and the multicast type of the signaling frames includes control signaling frames and signaling acknowledgment frames; the second multicast message includes a first control signaling frame, and the first multicast message includes a first signaling acknowledgment frame. The first signaling acknowledgment frame is generated by the multicast source based on the first control signaling frame, and the first signaling acknowledgment frame is used to indicate the reception status of the control signaling frame sent by the first client.

[0082] In one implementation, the first client sets up a receive window for the multicast source to maintain the reception information of control signaling frames from the multicast source; the multicast source sets up a send window for the first client to maintain the send information of control signaling frames sent to the first client; the method further includes: the first client updates the receive window corresponding to the multicast source based on the first control signaling frame, and determines a first signaling acknowledgment frame based on the updated receive window; the first signaling acknowledgment frame indicates that the second control signaling frame maintained by the send window has not been received; the first signaling acknowledgment frame is used to update the send window corresponding to the first client, and to determine whether to retransmit the second control signaling frame.

[0083] In one implementation, the data unit of the signaling frame includes the actual destination address corresponding to the receiving end of the signaling frame and the actual source address corresponding to the sending end of the signaling frame; the data unit of the control signaling frame also includes a control identifier and a data payload, the data payload being used to transmit valid control signaling, and the control identifier being used to indicate the number of the control signaling frame; the data unit of the signaling acknowledgment frame also includes acknowledgment information, the acknowledgment information being used to indicate the reception status of the control signaling frames sent by the receiving end of the signaling acknowledgment frame.

[0084] In one implementation, the signaling frame further includes a multicast type; when the multicast type of the signaling frame is a control signaling frame, the signaling frame further includes a subtype of the control signaling frame, the subtype of the control signaling frame includes a first subtype and a second subtype, and the processing modules corresponding to the first subtype and the second subtype are different; the above method further includes: the first client submits the first control signaling frame to the processing module corresponding to the first subtype for processing according to the first subtype in the first control signaling frame.

[0085] In one implementation, the receiving window comprises M small windows, where M is a positive integer. Each small window within the receiving window sequentially maintains the reception information of control signaling frames according to the control identifiers of the received control signaling frames from the multicast source. The reception information maintained by one small window within the receiving window includes the control identifier and reception identifier of the control signaling frame. The reception identifier indicates whether the control signaling frame has been received. The first upper edge (UE) of the receiving window indicates the maximum value of the control identifiers of the received control signaling frames maintained by the receiving window, and the first lower edge (LE) of the receiving window indicates the minimum value of the control identifiers of the unreceived control signaling frames maintained by the receiving window. The sending window also comprises M small windows. Each small window within the sending window sequentially maintains the transmission information of control signaling frames according to the control identifiers of the control signaling frames sent to the first client. The transmission information maintained by one small window includes the control identifiers of the control signaling frames. The second UE of the sending window indicates the maximum value of the control identifiers of the unreceived control signaling frames maintained by the sending window, and the second LE of the sending window indicates the minimum value of the control identifiers of the unreceived control signaling frames maintained by the sending window.

[0086] In one implementation, the confirmation information in the first signaling confirmation frame includes a first UE and a first LE in the receiving window, as well as a bitmap, which sequentially indicates the reception status of control signaling frames maintained by the small window pointed to by the first LE to the small window pointed to by the first UE in the receiving window.

[0087] In one implementation, the first client updates the receiving window corresponding to the multicast source based on the first control signaling frame, including: determining, based on the actual destination address in the first control signaling frame, that it is a multicast frame sent to this device, and when determining, based on the actual source address in the first control signaling frame, that the sender of the first control signaling frame belongs to a multicast group, obtaining the receiving window corresponding to the multicast source based on the actual source address in the first control signaling frame, and updating the receiving window corresponding to the multicast source based on the first control signaling frame.

[0088] In one implementation, the first client updates the receiving window corresponding to the multicast source based on the first control signaling frame, including: determining a first index for maintaining the small window of the first control signaling frame according to the control identifier of the first control signaling frame, the first index being equal to the remainder after dividing the control identifier of the first control signaling frame by M; when the receiving window is determined to be full according to the first LE and the first UE, clearing the small window pointed to by the first LE up to the small window corresponding to the first index; when the receiving window is determined not to be full, if the receiving identifier of the small window corresponding to the first index is a first value, discarding the first control signaling frame; if the receiving identifier of the small window corresponding to the first index is a second value, updating the receiving identifier of the small window corresponding to the first index to the first value; a receiving identifier of the first value indicates that the control signaling frame has been received; a receiving identifier of the second value indicates that the control signaling frame has not been received; when the control identifier of the first control signaling frame is greater than the first UE, updating the value of the first UE to the control identifier of the first control signaling frame; determining the first small window pointed to by the first LE and the first small window in the subsequent small windows with a receiving identifier of the second value, and updating the value of the first LE to the control identifier of the first small window.

[0089] In one implementation, the method further includes: the first client periodically times out the receiving window corresponding to the multicast source it maintains.

[0090] In one implementation, the reception information maintained by a small window of the receiving window also includes a polling count. The first client performs periodic timeout processing on the receiving window corresponding to the multicast source it maintains, including: determining the fourth small window with a second value among the small windows pointed to by the first LE in the receiving window to the small windows pointed to by the first UE, and incrementing the polling count of the fourth small window by 1; when the polling count of the fourth small window is greater than a second preset value, clearing the small windows pointed to by the first LE to the fourth small window; determining the first fifth small window with a second value after the fourth small window in the receiving window; and updating the control identifier of the fifth small window to the first LE of the receiving window.

[0091] In one implementation, the method further includes: a first client establishing a Bluetooth connection with a multicast source and sending a fourth Bluetooth message to the multicast source, the fourth Bluetooth message being used to request to leave the multicast group; the first client receiving a fifth Bluetooth message sent by the multicast source, the fifth Bluetooth message being used to indicate confirmation that the first client has left the multicast group; the first client deleting the second multicast group information on the client side based on the fifth Bluetooth message; the second multicast group information including a multicast address and a first multicast key; and the first client disconnecting the Bluetooth connection with the multicast source.

[0092] In one implementation, the first client establishes a Bluetooth connection with the multicast source and sends a fourth Bluetooth message to the multicast source, including: the first client receiving a fourth operation; in response to the fourth operation, the first client establishes a Bluetooth connection with the multicast source and sends a fourth Bluetooth message to the multicast source; the method further includes: in response to the fourth operation, the first client closes the multicast application.

[0093] In one implementation, the method further includes: a first client listening to a sixth Bluetooth message from a multicast source; the sixth message indicating the deletion of the multicast group; the first client deleting the second multicast group information on the client side based on the sixth Bluetooth message; the second multicast group information including the multicast address and the first multicast key.

[0094] Fourthly, this application provides a communication device, comprising: one or more processors and one or more memories. The one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer program code, which includes computer instructions. When the one or more processors execute the computer instructions, the communication device performs the multicast communication method in any possible implementation of the second aspect described above.

[0095] Fifthly, this application provides a communication device including one or more processors and one or more memories. The one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer program code, including computer instructions. When the one or more processors execute the computer instructions, the communication device performs the multicast communication method in any possible implementation of the third aspect described above.

[0096] Sixthly, embodiments of this application provide a computer storage medium including computer instructions that, when executed on an electronic device, cause a communication device to perform a multicast communication method in any of the possible implementations of any of the above aspects.

[0097] In a seventh aspect, embodiments of this application provide a computer program product that, when run on a computer, causes the computer to execute the multicast communication method in any possible implementation of any of the above aspects. Attached Figure Description

[0098] Figure 1 A schematic diagram of a multicast system provided in an embodiment of this application;

[0099] Figure 2A This is a schematic diagram of another multicast system provided in an embodiment of this application;

[0100] Figure 2B A schematic diagram illustrating a multicast transmission method provided in an embodiment of this application;

[0101] Figure 2C This application provides a schematic diagram of a process for establishing a WiFi connection.

[0102] Figure 2D This is a schematic diagram of another multicast system provided in an embodiment of this application;

[0103] Figure 2E A software architecture diagram provided for an embodiment of this application;

[0104] Figures 3A to 3G The relevant user interface for establishing multicast groups provided in the embodiments of this application;

[0105] Figures 4A to 4I This application provides an embodiment of the interface for a client to actively join a multicast group.

[0106] Figures 5A to 5D This application provides a user interface related to multicast group deletion in its embodiments.

[0107] Figure 6A A schematic diagram illustrating the stages of the multicast communication method provided in the embodiments of this application;

[0108] Figure 6B A schematic diagram illustrating another multicast transmission method provided in an embodiment of this application;

[0109] Figure 7A A flowchart illustrating a method for the multicast startup phase provided in this application embodiment;

[0110] Figure 7B A flowchart illustrating a method for the multicast source invitation phase provided in this application embodiment;

[0111] Figure 7C A flowchart illustrating a client-initiated joining phase provided in this application embodiment;

[0112] Figure 8 A flowchart illustrating a method for the multicast transmission phase provided in this application embodiment;

[0113] Figure 9A A schematic diagram of a control signaling frame format provided in an embodiment of this application;

[0114] Figure 9B A schematic diagram of the frame format of a signaling confirmation frame provided in an embodiment of this application;

[0115] Figure 9C A flowchart illustrating a method for the signaling frame transmission stage provided in this application embodiment;

[0116] Figure 10A and Figure 10B A schematic diagram of a receiving window provided in an embodiment of this application;

[0117] Figure 10C A flowchart illustrating a method for updating a receiving window, as provided in an embodiment of this application;

[0118] Figure 10D A flowchart illustrating a method for updating a receiving window, as provided in an embodiment of this application;

[0119] Figure 10E A schematic diagram of a receiving window provided in an embodiment of this application;

[0120] Figure 10F A schematic diagram of the timeout handling process for the sending window provided in this application embodiment;

[0121] Figure 10G A schematic diagram of a receiving window provided in an embodiment of this application;

[0122] Figure 11A A schematic diagram of a sending window provided in an embodiment of this application;

[0123] Figure 11BA flowchart illustrating a method for updating a sending window, as provided in this application embodiment;

[0124] Figure 11C A flowchart illustrating a method for updating a sending window, as provided in this application embodiment;

[0125] Figure 11D A schematic diagram of a sending window provided in an embodiment of this application;

[0126] Figure 11E A schematic diagram of the timeout handling process for the sending window provided in this application embodiment;

[0127] Figure 12A A flowchart illustrating a client-initiated exit phase provided in this application embodiment;

[0128] Figure 12B A flowchart illustrating a method for the multicast source deletion phase provided in this application embodiment;

[0129] Figure 13 This is a schematic diagram of the structure of a multicast source provided in an embodiment of this application. Detailed Implementation

[0130] The technical solutions in the embodiments of this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0131] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0132] The term "user interface (UI)" used in the following embodiments of this application refers to the medium interface through which an application or operating system interacts and exchanges information with the user. It realizes the conversion between the internal form of information and the form that the user can accept. The user interface is source code written in a specific computer language such as Java or Extensible Markup Language (XML). The interface source code is parsed and rendered on the electronic device, ultimately presenting content that the user can recognize. A common form of user interface is the graphical user interface (GUI), which refers to a user interface related to computer operation displayed graphically. It can be visible interface elements such as text, icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, and widgets displayed on the screen of an electronic device.

[0133] Unicast refers to a point-to-point network connection between a source host and a destination host. The unicast data packets sent by the source host include the address of the destination host. When there are many destination hosts, unicast can consume a large amount of network bandwidth, leading to heavy load on the source host and network congestion.

[0134] Multicast refers to transmitting a single data packet to a set of hosts within a multicast group, following the principle of maximum delivery. When a source host needs to send the same data to multiple hosts, it doesn't need to send the data to each host individually; instead, it sends a single copy to a specific multicast address, which identifies a multicast group. All hosts joined in the multicast group receive a copy of the data sent by the source host, while hosts outside the multicast group do not receive it. Compared to unicast, multicast saves network bandwidth and reduces network load and the load on the source host. In multicast, the source host can be referred to as the multicast source.

[0135] For example, Figure 1 A conventional multicast system 10 is shown.

[0136] In this multicast system, clients in the multicast group can establish WiFi connections with individual access points (APs), thereby accessing the Wireless Local Area Network (WLAN) through the APs. Multicast data uploaded to the communication network by the multicast source is copied and forwarded by relay devices in the network (such as switches and routers) according to the distribution of the clients joining the multicast group. This multicast data is accurately sent to the wireless access points accessed by each client; then, the APs, through their WiFi connections with the clients, send the multicast data to the clients in the multicast group. Figure 1 The communication networks involved may include WLAN and / or wide area networks (such as the Internet).

[0137] Depend on Figure 1 As can be seen, in the multicast system 10 described above, the multicast data sent by the multicast source needs to be processed and distributed by multiple intermediate devices (such as relay devices and APs) before it can be sent to the clients in the multicast group. This multicast system involves a large number of intermediate devices between the multicast source and the clients, making the multicast management and transmission process very complex.

[0138] Currently, there is a requirement in the following scenario: the multicast source and the clients intending to join the multicast group are relatively close and within WLAN communication range. The goal is to quickly establish a multicast group for the aforementioned multicast source and clients, improving multicast group management and transmission efficiency, and achieving large-scale reliable multicast. However, the multicast system 10 described above involves numerous intermediate devices between the multicast source and clients, making multicast management and transmission processes very complex. Furthermore, each client needs to establish a WiFi connection with an access point (AP), making it unsuitable for environments without an AP. Therefore, multicast system 10 is not suitable for this scenario.

[0139] For example, in response to the above scenario requirements, Figure 2A This application illustrates a multicast system 20 provided in an embodiment of the present application. In the multicast system 20, a multicast source 100 creates a virtual access point (VAP), acts as an access point, and establishes WiFi connections with each client in the multicast group. Then, based on the WiFi connections with each client, it sends multicast messages to each client in the multicast group.

[0140] In multicast system 20, when multicast messages sent by AP to clients are transmitted via WLAN, a typical transmission method that can be adopted to ensure the reliability of multicast transmission is multicast to unicast (defined in the IEEE 802.11v standard). Figure 2B A timing diagram for this multicast transmission method is shown. See also... Figure 2BFor a multicast IP frame, the AP determines the MAC addresses of each client connected to the AP in the multicast group. Based on the MAC addresses of each client, the AP converts the multicast IP frame into a unicast frame for each client. Then, based on the WiFi protocol, the AP sequentially sends the unicast frames corresponding to the multicast IP frame to each client, employing a unicast transmission feedback mechanism. For example, if two clients in the multicast group are connected to the AP, the AP sequentially sends the unicast frame corresponding to a multicast IP frame (e.g., Frame 1) to both clients, and then sequentially sends the unicast frame corresponding to the next multicast IP frame (e.g., Frame 2) to both clients. Furthermore, relying on the unicast transmission feedback mechanism, this transmission method can use a high-order transmission rate. That is, after sending a unicast frame to a client, an acknowledgment character (ACK) can be received from that client. The unicast frame and the ACK are separated by an inter-frame spacing (IFS), and the ACK and the next sent unicast frame are separated by a distributed inter-frame spacing (DIFS) and a random backoff value.

[0141] Clearly, this multicast-to-unicast multicast transmission method loses the original meaning of multicast, leading to a waste of air interface resources when the number of clients joining the multicast group is large. Furthermore, in multicast system 20, multicast source 100 needs to establish a WiFi connection with each client, meaning a WiFi unicast link is maintained between it and each client. See also... Figure 2C "WiFi connection" refers to the process by which two devices establish a WiFi unicast link through some or all of the five stages: service discovery, link authentication (Auth Req / Resp), association process (AssoReq / Resp), key negotiation (i.e., four steps), and IP allocation. Both devices maintain corresponding link information for this WiFi unicast link, such as various link parameters and link optimization algorithms (e.g., rate selection algorithms, aggregation algorithms, etc.). Therefore, when a multicast group includes N clients, the multicast source needs to associate the WiFi unicast links of N clients and maintain the link information for each of the N WiFi unicast links.

[0142] For wireless routers, it is possible to connect WiFi unicast links to 32 or even 64 devices simultaneously; however, when user terminal devices (such as mobile phones, tablets, etc.) are used as multicast sources, they are limited by hardware resources and can generally only connect WiFi unicast links to 4 to 8 devices, which greatly limits the number of clients in a multicast group.

[0143] For example, Figure 2DThis application illustrates another multicast system 30 provided in an embodiment of the present application, which can avoid the problem of a limited number of clients that can be associated when a terminal device acts as a multicast source. For example... Figure 2D As shown, the multicast system 30 may include a multicast source 100 of the multicast group, and multiple clients that have joined the multicast group, such as client 200, client 300, etc. The following explanation uses client 200 as an example.

[0144] Multicast source 100 and client 200 are terminal devices equipped with short-range communication modules, including a WiFi communication module and a Bluetooth (BLE) communication module. After multicast is enabled, multicast source 100 starts a VAP for multicast via the WiFi communication module (e.g., enabling a WiFi hotspot); multicast source 100 and client 200 establish a Bluetooth connection via the Bluetooth communication module; based on this Bluetooth connection, client 200 can join a multicast group and start a VAP for multicast, and multicast source 100 can obtain multicast user information from client 200 (e.g., IP address and MAC address). In some embodiments, the VAP can be understood as a driver network interface card (NIC), that is, a kernel-mode NIC that can be operated in user mode. In this way, after establishing a multicast group with Bluetooth assistance, multicast source 100 and each client do not need to establish a Wi-Fi connection. The VAP of multicast source 100 can also send multicast messages via Wi-Fi communication module based on the multicast user information of each client. The VAP of each client can also listen to the multicast messages sent by multicast source 100 via Wi-Fi communication module. Thus, large-scale Wi-Fi multicast transmission can be achieved without being limited by the number of clients that can be associated.

[0145] In multicast system 30, "no WiFi connection" between multicast source 100 and each client in the multicast group means that there is no WiFi connection between multicast source 100 and each client. Figure 2C The WiFi connection process shown eliminates the need to maintain link information (i.e., various link parameters and link optimization algorithms) for each client. For multicast source 100, it is only necessary to virtualize all clients in the multicast group as a single multicast user and maintain only the link information corresponding to that multicast user, including the multicast address of the multicast group, the multicast key, the virtual multicast source address of the client, and the multicast user information of each client.

[0146] In some embodiments, the multicast source 100 may have a display screen, through which a user can trigger the creation / deletion of a multicast group via a user interface displayed on the screen. In some embodiments, the client 200 may also have a display screen, through which a user can trigger the client 200 to join / leave a multicast group via a user interface displayed on the screen.

[0147] Multicast source 100 and each client 200 can be a user's terminal device. Multicast source 100 and client 200 can be mobile phones, tablets, desktop computers, laptops, handheld computers, ultra-mobile personal computers (UMPCs), netbooks, as well as cellular phones, personal digital assistants (PDAs), augmented reality (AR) devices, virtual reality (VR) devices, artificial intelligence (AI) devices, wearable devices, in-vehicle devices, smart home devices, and / or smart city devices, etc. This application embodiment does not impose special restrictions on the specific types of multicast source 100 and client 200. Multicast source 100 and client 200 can run iOS, Android, Microsoft, or other operating systems, and are not specifically limited here.

[0148] The software architecture of the multicast source 100 and the client involved in the embodiments of this application will be described below.

[0149] The software system of multicast source 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This embodiment of the invention uses a layered Android system as an example to exemplify the software structure of multicast source 100.

[0150] Figure 2E This is a software architecture diagram of the multicast source 100 according to an embodiment of the present invention.

[0151] A layered architecture divides the software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the software architecture of multicast source 100 includes, but is not limited to, an application layer, an application framework layer, and a kernel layer.

[0152] The application (APP) layer can include a series of application packages. For example... Figure 2E As shown, the application package may include user interface (UI) and multicast applications (such as screen mirroring applications), and may also include applications such as WLAN applications, Bluetooth applications, and video applications.

[0153] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0154] like Figure 2E As shown, the system services in the application framework layer can include Bluetooth and WLAN services. Bluetooth applications can call the Bluetooth service to establish wireless communication connections with nearby clients and to transmit data; WLAN applications can call the WLAN service to enable a Virtual Access Point (VAP), which can send multicast messages via the WiFi communication protocol and listen for multicast messages sent by clients in the multicast group.

[0155] In some embodiments, the application framework layer may also include a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, etc. (not shown in the accompanying drawings).

[0156] The kernel layer is an abstraction layer between hardware and software. Android's core system services rely on the kernel layer (i.e., the Linux kernel), such as security, memory management, process management, network protocol stack, and driver model. The kernel layer can respond to functionalities called by the application framework layer and execute corresponding operations.

[0157] The kernel layer can include the TCP / IP multicast stack, the HML multicast stack, and the hardware driver layer.

[0158] In some embodiments, the TCP / IP protocol stack includes, from high to low, the transport layer and the network layer. The TCP / IP protocol stack is used for packet segmentation and reassembly, packet encapsulation, packet verification, congestion control, slow start, out-of-order reordering, timeout reordering, etc.

[0159] When sending data, the TCP / IP stack encapsulates the data to be sent using the corresponding layered protocols in descending order of complexity. In some embodiments, the network layer adds an IP header to the message transmitted from the upper layer to generate an IP packet, and sends it to the data link layer in the WiFi driver. The IP header includes the IP address of the multicast source 100 and the destination IP address (e.g., the multicast IP address or the client's IP address). The data link layer adds a MAC header to the message transmitted from the upper layer to generate a MAC frame, and sends it to the physical layer. The MAC header includes the MAC address of the multicast source 100 and the destination MAC address (e.g., the multicast MAC address or the client's MAC address). This application embodiment does not specifically limit the method of obtaining the multicast IP address.

[0160] When receiving data, the TCP / IP stack parses the received data using the corresponding layered protocols in ascending order. In some embodiments, the data link layer performs MAC frame verification on packets transmitted from the lower layer, such as parsing the MAC header, querying the multicast key based on the source address in the MAC header, and using the multicast key to parse the packet to obtain the parsed data unit (e.g., MAC Service Data Unit (MSDU)). The network layer performs IP packet verification on packets transmitted from the lower layer, such as decapsulating the IP header, determining whether the destination IP address in the IP packet is the IP address of the local device, and if so, uploading the decapsulated packet to the upper layer.

[0161] The HML multicast stack includes a multicast management module and a multicast transmission module. The multicast management module manages multicast group information on the multicast source 100 side, assigning IP addresses to multicast source 100 and clients joining the multicast group. This multicast group information may include multicast user information, multicast addresses, virtual multicast source addresses, multicast keys, etc. The multicast transmission module determines the multicast messages to be sent and when to send them, and also processes multicast messages returned by clients.

[0162] The hardware driver layer includes at least a display driver, a Bluetooth driver, and a WiFi driver. The display driver can drive the screen to display the user interface, which can be configured with controls to trigger multicast group establishment and deletion. The Bluetooth service can send instructions to the Bluetooth driver, instructing it to send probe signals through the Bluetooth communication module to scan for nearby Bluetooth devices, interact with other Bluetooth devices to establish Bluetooth connections, and send and receive signals through the aforementioned Bluetooth connection. The multicast source 100, through the aforementioned Bluetooth connection, can invite clients to join the multicast group or receive requests from clients to join the multicast group, and can also notify clients to delete the multicast group or receive requests from clients to leave the multicast group. The WiFi service can send instructions to the WiFi driver, instructing it to start a VAP through the WiFi communication module, and send multicast messages to the multicast address through the VAP, and listen for multicast messages returned by the client's VAP.

[0163] The client-side software architecture can be referenced. Figure 2E The description of multicast source 100 can be compared to Figure 2E The software architecture shown may include more or fewer modules, which will not be elaborated here.

[0164] Based on the multicast system 30 and software architecture described above, embodiments of this application provide a multicast communication method that can achieve large-scale reliable multicast transmission. The application scenarios of the above multicast communication method are described below by way of example.

[0165] The application scenarios involved in this application include one-to-many information sharing. This information sharing can be file sharing, such as multicast source 100 simultaneously sending a file to multiple clients; it can also be screen mirroring, such as simultaneously projecting the screen of multicast source 100 onto the screens of multiple clients. The following description uses screen mirroring as an example.

[0166] For example, taking video applications as an example, Figures 3A to 3F The diagram shows the interface for a user to trigger the creation of a multicast group via the UI and invite client 200 to join the multicast group in a screen sharing scenario.

[0167] like Figure 3A As shown, when multicast source 100 displays the user interface 11 of a video application, it detects an operation by the user to bring up the control interface 12 (e.g., a downward swipe operation starting from the status bar); in response to this operation, multicast source 100 displays... Figure 3B The control interface 12 is shown. The control interface 12 may include switch icons for various shortcut functions of the multicast source 100, such as a wireless projection switch icon 201, a WiFi switch icon, and a Bluetooth switch icon, etc., wherein the WiFi switch icon and the Bluetooth switch icon are both in the "on" state. This application embodiment does not specifically limit the method by which the user accesses the control interface.

[0168] Users can turn wireless screen mirroring on / off using the switch icon 201. The switch icon has two display states: on and off. Figure 3B The switch icon 201 shown is currently in the off state, indicating that wireless screen mirroring is not currently enabled. Figure 3B and Figure 3C As shown, after detecting that the user clicks the switch icon 201, the multicast source 100 switches the switch icon 201 to the on state, enables wireless screen projection, and executes the screen projection multicast group establishment process.

[0169] In some embodiments, after wireless screen casting is enabled, the multicast source 100 performs the screen casting multicast group establishment process, which includes: detecting nearby devices that can perform wireless screen casting (e.g., nearby devices that have enabled wireless sharing), and displaying... Figure 3D The selection box 202 is shown. Selection box 202 includes device options for detected nearby devices, such as device option 203 for client 200, and may also include a confirmation control 204. The aforementioned device options may include some or all of the device icon, device name, and device model.

[0170] In some embodiments, terminal devices that have enabled wireless sharing periodically broadcast discovery signals via Bluetooth. These discovery signals can indicate the device's identifier and indicate that the device can receive wireless sharing data from other devices, such as screen mirroring data. Multicast source 100 can listen for discovery signals sent by devices that have enabled wireless sharing via Bluetooth driver.

[0171] Selection box 202 is used to select the target projection device. Users can select at least one device from the detected nearby devices as the target projection device. Figure 3E As shown, after the user selects client 200 through device option 203, when multicast source 100 detects the user clicking the OK control 204, multicast source 100 sends a multicast invitation message to client 200 to invite it to join the screen casting multicast group; and after client 200 joins the screen casting multicast group, it sends screen casting data to it via multicast. Optionally, it is not necessary to display the OK control 204; after detecting the operation of selecting client 200 (such as clicking device option 203), a multicast invitation message is sent to client 200.

[0172] In some embodiments, in addition to selecting the target projection device, the selection box 202 can also be used to select the projection content. For example... Figure 3D As shown, the screen projection content can include the following options: screen 205 of multicast source 100 and foreground application (i.e., video application) 206. If the user selects screen 205, the projection data sent by multicast source 100 includes the current display content of the screen of multicast source 100; if the user selects video application 206, the projection data sent by multicast source 100 includes the display content of the video application running on multicast source 100.

[0173] In this embodiment, the client 200 accepts the invitation from the multicast source 100 and joins the screen-casting multicast group before it can receive screen-casting data sent by the multicast source 100. In some embodiments, after receiving the invitation request from the multicast source 100 to join the screen-casting multicast group, the client 200 may first display a prompt box 207. The prompt box 207 is used to prompt the user whether to accept the screen-casting from the multicast source 100. The prompt box 207 may include a confirmation control 208 and a rejection control 209. The confirmation control 208 is used to accept the screen-casting, and the rejection control 209 is used to reject the screen-casting. Figure 3F and Figure 3G As shown, when the user clicks the confirmation control 208, the client 200 accepts the invitation from the multicast source 100 and joins the screen casting multicast group; then, the client 200 displays the screen casting screen 13 based on the received screen casting data from the multicast source 100, and the screen casting screen 13 may include the user interface 11 currently displayed by the multicast source 100.

[0174] Figures 3A to 3FIn the example shown, multicast source 100 actively invites client 200 to join the screen-casting multicast group. In some embodiments, multicast source 100 does not actively invite client 300 to join the screen-casting multicast group, but client 300 may actively request to join the screen-casting multicast group.

[0175] For example, Figures 4A to 4I The interface shows the process of client 300 actively joining the multicast group after multicast source 100 establishes the multicast group.

[0176] In some embodiments, when the multicast source 100 establishes a screen-casting multicast group, it can generate a password for joining the screen-casting multicast group, such as a personal identification number (PIN). Figure 4A As shown, when multicast source 100 casts its screen to a client that has joined the casting multicast group, it can display the PIN 301 for joining the casting multicast group. Nearby devices can use this PIN to actively join the casting multicast group.

[0177] like Figure 4B As shown, when client 300 displays user interface 16 (e.g., main interface), it detects the user's operation of calling up control interface 14; in response to this operation, client 300 displays... Figure 4C The control interface 14 shown. The control interface 14 of the client 300 may include switch icons for controlling various shortcut functions of the client 300, such as a wireless sharing switch icon 302, a WiFi switch icon, and a Bluetooth switch icon, etc.

[0178] like Figure 4C and Figure 4D As shown, after detecting that a user clicks the wireless sharing switch icon 302, the display state of the switch icon 302 can be switched from the off state to the on state, and wireless sharing can be enabled. After enabling wireless sharing, the user can join the screen-casting multicast group established by the multicast source 100 through the multi-device collaboration page 15. This application embodiment does not specifically limit the method of calling up the multi-device collaboration page 15.

[0179] In some embodiments, such as Figure 4D and Figure 4E As shown, when the client 300 detects that the user has long-pressed the wireless sharing switch icon 302, the client 300 displays the multi-device collaboration page 15. The multi-device collaboration page 15 includes the client 300's icon 303, as well as icons of other devices detected by the client 300 that have enabled wireless sharing and / or wireless screen projection, such as the multicast source 100's icon 304. Figure 4EAs shown, in the multi-device collaboration page 15, the icon 303 of the client 300 is located in area 1, and the icons of other devices are located in area 2. Optionally, area 1 can be a central circular area, and area 2 can be a ring-shaped area surrounding area 1. This application embodiment does not specifically limit the shape and position of the aforementioned areas 1 and 2.

[0180] In some embodiments, the multicast source 100 that enables wireless screen projection can periodically broadcast Bluetooth signals to indicate that the device is performing wireless screen projection; devices that enable wireless sharing can also periodically broadcast Bluetooth signals to indicate that the device can perform wireless sharing. The client 300 can display icons of each device in area 2 of the multi-device collaboration page 15 based on the detected Bluetooth signals of each device. In some embodiments, such as Figure 4E As shown, after the client 300 detects the Bluetooth signal broadcast by the multicast source 100, it can also display a prompt message 305 on the multi-device collaboration page 15 to indicate that the multicast source 100 is casting the screen.

[0181] like Figure 4F and Figure 4G As shown, a user can drag the icon 304 of the multicast source 100 close to the icon 303 of the client 300 to trigger the client 300 to join the casting multicast group of the multicast source 100. When the client 300 detects a sliding operation on the icon 304, the client 300 moves the icon 304 towards the icon 303 in the direction of the user's finger sliding. In some embodiments, such as Figure 4H As shown, when icon 304 is detected to be dragged to area 1 where icon 303 is located, in response to the aforementioned sliding operation, multicast source 100 displays a prompt box 306. The prompt box 306 is used to verify the screen casting password of multicast source 100. The prompt box 306 may include a prompt message 307, a password input box 308, and a confirmation control 309. The prompt message 307 is used to prompt the user to enter the screen casting PIN code of multicast source 100.

[0182] like Figure 4H As shown, after the user enters the screen-sharing PIN code of multicast source 100 in the password input box 308, client 300 detects the user's action on the confirmation control 309 (e.g., a click operation). In response to this action, client 300 sends a screen-sharing request to multicast source 100. The screen-sharing request requests to join the screen-sharing multicast group of multicast source 100, and carries the screen-sharing PIN code entered by the user. After multicast source 100 verifies that the PIN code in the screen-sharing request is correct, it adds client 300 to the screen-sharing multicast group; only then can client 300 receive screen-sharing data sent by multicast source 100. Figure 4I As shown, the client can display the screen projection screen 17 based on the received projection data. The screen projection screen 17 may include the user interface 11 currently displayed by the multicast source 100.

[0183] In some embodiments, the prompt box 306 may not be displayed, and the user does not need to enter a PIN code. When it is detected that icon 304 is dragged to area 1 where icon 303 is located, client 300 directly sends a screen casting request to multicast source 100; multicast source 100 may display a prompt box based on the screen casting request to prompt the user whether to allow client 300 to join the screen casting multicast group. The prompt box may include an OK control and a Deny control; multicast source 100 adds client 300 to the screen casting multicast group only when the user's operation on the OK control is detected.

[0184] The client 300 may be triggered to actively join the multicast group established by the multicast source 100 through the multi-device collaboration page 15. Other methods may also be used to trigger the client 300 to actively join the aforementioned multicast group. No specific limitations are made here.

[0185] When multicast source 100 casts to a client in a casting multicast group, the client user in the casting multicast group can leave the casting multicast group and end the casting for that client; multicast source 100 can also end the casting and delete the entire casting multicast group.

[0186] For example, Figure 5A and Figure 5B The interface shown is related to the client's 300 error when actively leaving the screen-sharing multicast group. For example... Figure 5A and Figure 5B As shown, the client 300 can display an exit control 401 on the screen projection screen 17; when the client detects that the user has performed an operation on the exit control 401 (such as a click operation), the client 300 stops displaying the screen projection screen and sends an exit request to the multicast source 100. The exit request is used to instruct the client 300 to exit the screen projection multicast group.

[0187] In some embodiments, the client 300 can also turn off wireless sharing via the aforementioned wireless sharing switch icon 302, thereby triggering the active exit from the screen-sharing multicast group. This application embodiment does not specifically limit the method for triggering the client 300 to actively exit the screen-sharing multicast group.

[0188] For example, Figure 5C and Figure 5D The interface for deleting a multicast group from multicast source 100 is shown. Figure 5C As shown, when multicast source 100 performs multicast screen projection, it can display an end control 402; when a user operation on the end control 402 (e.g., a click operation) is detected, multicast source 100 stops multicasting screen projection data and deletes the screen projection multicast group. Each client in the multicast group also stops displaying the screen projection screen. In some embodiments, such as... Figure 5DAs shown, after multicast source 100 deletes the screen casting multicast group, a prompt message 403 is displayed to inform the user that screen casting has ended.

[0189] In some embodiments, the multicast source 100 can also turn off wireless screen casting via the aforementioned wireless screen casting switch icon 201, thereby triggering the multicast source 100 to delete the screen casting multicast group. This application embodiment does not specifically limit the method of triggering the multicast source 100 to delete the screen casting multicast group.

[0190] The method flow of the multicast communication method provided in the embodiments of this application is described below.

[0191] like Figure 6A As shown, the multicast communication method provided in this application involves the following three stages: multicast group establishment, multicast transmission, and multicast group deletion. Among them,

[0192] During the multicast group establishment phase, multicast source 100 and each client interact via Bluetooth. The multicast group establishment phase can be further divided into three stages: multicast startup, multicast source invitation, and client active joining.

[0193] During multicast preparation, the user can trigger the multicast source 100 to scan for nearby devices that can join the multicast group via Bluetooth through the multicast source 100's user interface, start the VAP for multicast, and determine the startup information required for the multicast group (e.g., multicast address, virtual multicast source address, multicast key). In the multicast source inviting client phase, after the multicast source 100 detects a nearby client that can join the multicast group, it establishes a Bluetooth connection with the client and invites the client to join the multicast group through this Bluetooth connection. In the client actively joining phase, after the client detects the multicast group discovery signal broadcast by the multicast source 100 via Bluetooth, it establishes a Bluetooth connection with the multicast source 100 and actively joins the multicast group through this Bluetooth connection. In both the multicast source inviting and client actively joining phases, after confirming that the client has joined the multicast group, the multicast source 100 can obtain the client's multicast user information and trigger the client to start the VAP for multicast and configure the multicast group information on the client side; furthermore, after confirming that the client has joined the multicast group, either the client or the multicast source 100 can disconnect the aforementioned Bluetooth connection.

[0194] During the multicast transmission phase, multicast source 100 and each client interact via WiFi driver, but no WiFi connection needs to be established. Based on the multicast group's startup information and the client's multicast user information, the VAP of multicast source 100 sends multicast messages via WiFi driver, and the client's VAP can listen to the multicast messages sent by multicast source 100 via WiFi driver. Based on the multicast group information on the client side, each client's VAP can also send multicast messages via WiFi driver, and the VAP of multicast source 100 can also listen to the multicast messages sent by the client via WiFi driver.

[0195] The multicast transmission phase can be further divided into two stages: data frame transmission and signaling frame transmission.

[0196] For WiFi drivers, the multicast transmission in this embodiment can adopt traditional multicast transmission methods (e.g., Figure 6B (As shown in the multicast transmission method), multicast source 100 fills the multicast MAC address of the multicast group in the MAC header of the multicast frame, and then the WiFi driver sends each multicast frame sequentially over the air interface via VAP (e.g., Figure 6B (See Frame 1, Frame 2, and Frame 3). In this transmission method, after sending a multicast frame (e.g., Frame 1), a DIFS and Backoff interval is required before sending the next multicast frame (e.g., Frame 2). Traditional multicast transmission methods have the following problems: due to the lack of a feedback mechanism, transmission reliability is low, and to ensure transmission stability, the lowest order transmission rate is usually used.

[0197] Specifically, this application embodiment, based on the multicast transmission method described above, also designs a retransmission mechanism for control signaling frames. After receiving a control signaling frame from multicast source 100, the VAP of client 200 can send back a signaling acknowledgment frame via WiFi driver, and the VAP of multicast source 100 can listen to the signaling acknowledgment frame sent back by client 200 via WiFi driver; multicast source 100 can retransmit control signaling frames that client 300 has not received based on the signaling acknowledgment frame. In this way, the transmission reliability and transmission rate can be effectively improved.

[0198] During the multicast deletion phase, multicast source 100 and each client interact via Bluetooth. The multicast deletion phase can be further divided into two stages: multicast source deletion and client active exit.

[0199] During the client-initiated exit phase, the user can trigger the client to actively exit the multicast group through the client's user interface; the client establishes a Bluetooth connection with multicast source 100, sends a request to exit the multicast to multicast source 100, and disconnects the Bluetooth connection after exiting. During the multicast source deletion phase, the user can trigger multicast source 100 to delete the multicast group through the multicast source 100's user interface, and multicast source 100 can broadcast the message of deleting the multicast group via Bluetooth.

[0200] The multicast group communication method provided in this application embodiment does not require the participation of other third-party devices (such as routers). The multicast source and client interact via Bluetooth, which can quickly establish multicast groups, improve multicast transmission efficiency and multicast group management efficiency, avoid the problem of the limited number of clients that can be associated with the VAP of multicast source 100, and realize large-scale multicast at close range without WiFi connection. In addition, the retransmission mechanism provided in this application embodiment also effectively improves multicast reliability.

[0201] The following section provides a detailed explanation of the three stages mentioned above: multicast group establishment, multicast deletion, and multicast transmission.

[0202] 1. Multicast Group Establishment

[0203] For example, taking client 200 as an example, Figure 7A The flowchart of a multicast startup phase method provided in an embodiment of this application is shown. The multicast startup phase includes, but is not limited to, steps S101 to S113.

[0204] S101, the UI of multicast source 100 detects user operation 1, which is used to trigger the multicast startup process for multicast group establishment.

[0205] S102. Based on operation 1, the UI of multicast source 100 sends a discovery command to the Bluetooth driver of multicast source 100.

[0206] In some embodiments, based on operation 1, the UI of multicast source 100 sends an instruction to the multicast stack of multicast source 100 to instruct the multicast stack to send a discovery instruction to the Bluetooth driver.

[0207] S103. Based on the discovery command, the Bluetooth driver of multicast source 100 broadcasts discovery signal 1 via Bluetooth. Discovery signal 1 is used to detect HML multicast devices that can join multicast groups.

[0208] In this embodiment, the multicast source 100 is provided with a UI entry point for multicast services. Users can trigger the multicast startup process and start the Bluetooth discovery service by performing operation 1 on this UI entry point. For example, consider... Figures 3A to 3D According to the relevant description, in the screen casting scenario, the multicast service mentioned above can be a wireless screen casting service; Operation 1 can be an operation to enable wireless screen casting, such as clicking the switch icon 201 for wireless screen casting.

[0209] In this embodiment, the device supporting the multicast communication method provided in this embodiment is referred to as an HML multicast device. In response to user operation 1, multicast source 100 will initiate Bluetooth discovery service, broadcast discovery signal 1 via Bluetooth, and enter Bluetooth listening state to detect surrounding HML multicast devices. The discovery signal 1 can be used to indicate that the device supports multicast communication and / or that the device is an HML multicast device; in a screen mirroring scenario, the discovery signal 1 can also be used to indicate that the device is initiating screen mirroring.

[0210] S104, The UI of client 200 detected user operation 2.

[0211] S105. Based on operation 2, the UI of client 200 sends a discovery command to the Bluetooth driver of client 200.

[0212] S106. Based on the discovery command, the Bluetooth driver of client 200 broadcasts discovery signal 2, which is used to indicate that client 200 is an HML multicast device.

[0213] In some embodiments, the client 200 has a preset UI entry point. By performing operation 2 on this UI entry point, the user can trigger the client 200 to start the Bluetooth discovery service and broadcast a discovery signal 2. The discovery signal 2 can be used to indicate that the device supports multicast communication and / or that the device is an HML multicast device. In some embodiments, the client 200 can be configured with a wireless sharing function. After enabling the wireless sharing function, the client 200 can receive data wirelessly shared by other devices. HML multicast devices may also include devices with the wireless sharing function enabled, and operation 2 includes the operation of enabling wireless sharing. For example, refer to... Figures 4C to 4D According to the relevant description, operation 2 can be the click operation of the switch icon 302 for wireless screen projection.

[0214] In some embodiments, the Bluetooth driver of multicast source 100 periodically broadcasts discovery signal 1, for example, at a frequency of 12 times every 5 seconds. In some embodiments, after receiving a discovery command from the UI, the Bluetooth driver of client 200 only starts broadcasting discovery signal 2 when it detects discovery signal 1 sent by multicast source 100; this saves power consumption and air interface resources of client 200. In some embodiments, multicast source 100 does not need to execute step S103. After receiving discovery command 1, the Bluetooth driver of multicast source 100 listens for discovery signals from other devices, such as discovery signal 2 periodically broadcast by client 200; this saves power consumption and air interface resources of multicast source 100.

[0215] In some embodiments, discovery signal 1 may carry device information of multicast source 100, and discovery signal 2 may carry device information of client 200. The device information includes some or all of the following: device identity (ID), device model, device name, and hash value of the account logged in by the device. Optionally, the hash value of the account can be used to verify the legitimacy of the device. Client 200 can verify whether multicast source 100 and client 200 are logged into the same account based on the hash value of the account in discovery signal 1; if they are logged into the same account, client 200 will subsequently agree to join the multicast group. Multicast source 100 can verify whether multicast source 100 and client 200 are logged into the same account based on the hash value of the account in discovery signal 2; if they are logged into the same account, multicast source 100 will subsequently allow client 200 to join the multicast group.

[0216] S107. Based on the detected discovery signal 2, the Bluetooth driver of multicast source 100 sends a device callback command to the UI of multicast source 100.

[0217] S108. Based on the above callback instruction, the UI of multicast source 100 displays the detected HML multicast devices, including client 200.

[0218] S109, the UI of multicast source 100 detects user operation 3, operation 3 is used to select at least one target device from the detected HML multicast devices, and to determine the creation of a multicast group including the at least one target device.

[0219] In this embodiment, after the Bluetooth driver of multicast source 100 detects discovery signal 2 from client 200, it sends a device callback command to the UI. The callback command may carry a list of detected HML multicast devices, which may include device information for each HML multicast device. The UI of multicast source 100 can display device options for each HML multicast device based on the HML multicast device list for user selection. For example, the UI of multicast source 100 can display device options for client 200 based on the device information of client 200. For example, refer to... Figures 3A to 3D According to the relevant description, in the screen projection scenario, the multicast source 100 will display the device options of the detected HML multicast devices that have enabled wireless sharing on the user interface 11 for the user to select the target screen projection device; when the above-mentioned at least one target device includes the client 200, the device option 203 of the client 200 may include the icon and device name of the client 200, and operation 3 includes the operation performed on the device option 203 (e.g., click operation).

[0220] S110, in response to operation 3, the UI of multicast source 100 sends a multicast start command to the multicast stack of multicast source 100.

[0221] S111, the multicast stack of multicast source 100 sends a multicast start command to the WiFi driver of multicast source 100.

[0222] S112. Based on the above multicast startup command, the WiFi driver of multicast source 100 creates VAP 1 to implement multicast services.

[0223] Once multicast is initiated, multicast source 100 will open a virtual local area network (VAP 1) to enable multicast services. VAP 1 can also support other services besides multicast, which are not specifically limited here.

[0224] S113. Based on the above multicast startup instruction, the multicast stack of multicast source 100 also allocates IP address 1 to VAP 1 of multicast source 100, allocates IP addresses to VAPs of at least one target device, and generates multicast MAC address, virtual multicast source address, and multicast key 1 for the multicast group.

[0225] In this embodiment of the application, after determining that multicast has been initiated, multicast source 100 must not only assign an IP address to VAP 1 of its own device, but also assign IP addresses to the VAPs of each target device selected by the user. For example, when the target devices include client 200, multicast source 100 assigns IP address 2 to VAP 1 of client 200; when the target devices include client 300, multicast source 100 assigns IP address 3 to VAP 1 of client 300.

[0226] In addition, after confirming the multicast initiation, multicast source 100 also configures a multicast IP address for the multicast group. When encapsulating multicast packets, multicast source 100 sets the destination IP address to the multicast IP address. Any client that has joined the multicast group indicated by this multicast IP address can receive multicast packets sent by multicast source 100. The multicast IP address uses a dynamically allocated Class D address. The Class D address space ranges from 224.0.0.0 to 239.255.255.255, and all can receive messages from the multicast source multicast group. When the multicast in this multicast group ends, the corresponding Class D address is reclaimed.

[0227] For a data packet to be sent from the source to the destination device, IP layer addressing requires the destination device's IP address, while in an Ethernet environment, Layer 2 addressing also requires the destination device's MAC address. After determining the multicast IP address, multicast source 100 obtains the multicast MAC address mapped from the multicast IP address. The multicast MAC address can also be simply referred to as the multicast address.

[0228] For WiFi unicast links, WPA2 / WPA3 encryption protocols are generally used. When establishing a WiFi connection, the sending and receiving ends of each WiFi unicast link can negotiate the unicast and multicast keys for that link. For most chips, a single device cannot support configuring multiple multicast keys; that is, a device can only have one multicast key. When the receiving chip decrypts multicast packets, it typically obtains the source address from the Address2 field in the MAC header of the multicast packet, looks up the multicast key corresponding to the source address in a table, and then uses that multicast key to decrypt the multicast packet. Therefore, for a VAP configured with multicast key 1 as an HML multicast device, only multicast packets from one device can be successfully decrypted, and that device's MAC address is the source address corresponding to multicast key 1.

[0229] In the multicast transmission without WiFi connection provided in this embodiment, the client will only receive multicast packets from multicast source 100. Therefore, the client only needs to configure the MAC address of multicast source 100 as the source address of multicast key 1. The client can query multicast key 1 based on the source address in the MAC header of the multicast packet (i.e., the MAC address of multicast source 100) and use multicast key 1 to decrypt the multicast packet. Meanwhile, multicast source 100 will receive multicast packets from all clients in the multicast group. To enable multicast source 100 to decrypt multicast messages sent by all clients in the multicast group, all clients in the multicast group use the same virtual multicast source address. Multicast source 100 configures the virtual multicast source address as the source address corresponding to multicast key 1. When sending multicast messages to multicast source 100, all clients in the multicast group set the source address to the virtual multicast source address and carry the client's actual source address in the data unit of the multicast message (e.g., MSDU in the MAC frame).

[0230] In some embodiments, the virtual multicast source address can be generated based on the following preset rules: the first three bytes of the virtual multicast source address are the organization-unique identifier (OUI) of the multicast source 100, and the last three bytes are the last three bytes of the MAC address of the multicast source 100.

[0231] This application does not specifically limit the method of generating the multicast key 1 for the multicast group.

[0232] In some embodiments, the multicast source 100 uses a preset key algorithm (e.g., a hash algorithm) to generate the multicast key 1 for the multicast group.

[0233] In some embodiments, multicast source 100 establishes a WiFi connection with a client (e.g., client 200) in the multicast group. During the WiFi connection process, key negotiation is performed to obtain multicast key 1 corresponding to the WiFi unicast link between multicast source 100 and client 200, and multicast key 1 is used as the multicast key for the entire multicast group. Optionally, the aforementioned client can be one of the clients that joined the multicast group earliest. In the above implementation, multicast source 100 only needs to establish a WiFi connection and perform key negotiation with one client in the multicast group, and can disconnect the WiFi connection after obtaining the multicast key; during the multicast transmission phase, multicast source 100 does not need to establish a WiFi connection with the client.

[0234] After the user selects at least one target device from the detected HML multicast devices, the multicast source 100 will initiate a Bluetooth connection to each target device in turn via Bluetooth driver to invite the target device to join the multicast group. The following explanation uses the client 200 as an example.

[0235] For example, Figure 7B A flowchart illustrating a method for a multicast source invitation phase according to an embodiment of this application is shown. As shown, after step S113 of the multicast startup phase described above, steps S201 to S216 may also be included, but are not limited to.

[0236] S201, the multicast stack of multicast source 100 sends a client add command to the Bluetooth driver of multicast source 100. The client add command is used to instruct the client 200 to join the multicast group.

[0237] The client add command may include the device identifier of client 200 (such as device ID, MAC address, etc.), and may also include the multicast MAC address, virtual multicast source address, IP address 1 of multicast source 100, IP address 2 of client 200, and multicast key 1.

[0238] S202. Based on the device identifier of the client 200, the Bluetooth driver of the multicast source 100 and the Bluetooth driver of the client 200 exchange information to establish a Bluetooth connection.

[0239] In some embodiments, referring to steps S103 to S106 above, after client 200 enables wireless sharing, it periodically broadcasts a discovery signal 2 via Bluetooth. Discovery signal 2 includes the device identifier of client 200. Based on the device identifier of client 200, the Bluetooth driver of multicast source 100 can send a Bluetooth connection request to client 200's Bluetooth driver to request the establishment of a Bluetooth connection with client 200. This application embodiment does not specifically limit the implementation process of establishing a Bluetooth connection between multicast source 100 and client 200, and will not elaborate further here.

[0240] S203, the Bluetooth driver of multicast source 100 sends a multicast invitation message to the Bluetooth driver of client 200. The multicast invitation message is used to invite client 200 to join the multicast group. The multicast invitation message includes some or all of the following: multicast IP address, multicast MAC address, virtual multicast source address, IP address 1 of multicast source 100, IP address 2 of client 200, and multicast key 1.

[0241] S204. Based on the multicast invitation message mentioned above, the Bluetooth driver of client 200 sends an HML creation command to the WiFi driver.

[0242] S205, based on HML creation instructions, the WiFi driver of client 200 creates VAP 2 to implement multicast services.

[0243] S206, The WiFi driver of client 200 sends a creation completion notification to the Bluetooth driver of client 200.

[0244] S207. Based on the above creation completion notification, the Bluetooth driver of client 200 sends a multicast configuration command to the multicast stack. The multicast configuration command includes the multicast MAC address, the virtual multicast source address, the IP address 1 of multicast source 100, the IP address 2 of client 200, and the multicast key 1.

[0245] S208. Based on the above multicast configuration instructions, the multicast stack of client 200 configures multicast group information for the multicast group. The multicast group information includes some or all of the following: multicast MAC address, virtual multicast source address, multicast key 1, IP address 1 of multicast source 100, IP address 2 of client 200, and MAC address of multicast source 100.

[0246] In some embodiments, the multicast invitation message sent by the multicast source 100 may not include the virtual multicast source address; the client 200 may generate the virtual multicast source address itself based on the OUI of the multicast source 100, the MAC address of the multicast source 100, and the preset rules for generating the virtual multicast source address.

[0247] S209, the multicast stack of client 200 sends a multicast key configuration instruction to the WiFi driver. The multicast key configuration instruction includes the multicast key 1 mentioned above and the MAC address of multicast source 100.

[0248] S210. Based on the above multicast key configuration instructions, the WiFi driver of client 200 configures multicast key 1 as the multicast key of the multicast group, and the source address corresponding to multicast key 1 is the MAC address of multicast source 100.

[0249] The hardware module of client 200 maintains a multicast key lookup table, which stores the correspondence between multicast keys and source addresses. Based on the aforementioned multicast key configuration instructions, the WiFi driver of client 200 instructs the hardware module to store the correspondence between multicast key 1 and the MAC address of multicast source 100 in this table. During subsequent multicast transmission, after receiving a multicast message from multicast source 100, client 200 can look up the corresponding multicast key 1 in the table based on the source address (i.e., the MAC address of multicast source 100) in the multicast message; using multicast key 1, the multicast message can be decrypted.

[0250] It is understood that when client 200 interacts with multicast source 100, it can obtain the MAC address of multicast source 100. For example, in steps S202 and S203, the MAC address of multicast source 100 can be obtained through the Bluetooth driver. In some embodiments, in step S207, the Bluetooth driver of client 200 can send the MAC address of multicast source 100 to the multicast stack of client 200 through multicast configuration instructions.

[0251] In some embodiments, after receiving a multicast invitation message, the client 200 may display a prompt message to ask the user whether to join the multicast group of the multicast source 100. The client 200 executes steps S204 to S210 only after its UI detects the user's confirmation. For example, see... Figures 3E to 3G According to the relevant description, in the screen casting scenario, after the client 200 receives the multicast invitation message from the multicast source 100, it can display a prompt box 207. The prompt box 207 can be used to prompt the user whether to join the screen casting multicast group of the multicast source 100. The prompt box 207 can include a confirmation control 208, and the user can confirm joining the screen casting multicast group by clicking the confirmation control 208.

[0252] S211, the multicast stack of client 200 sends an IP address configuration command to the WiFi driver, the IP address configuration command including the aforementioned IP address 2.

[0253] S212. Based on the above IP address configuration instructions, the WiFi driver of client 200 configures the IP address of VAP2 to IP address 2.

[0254] The embodiments of this application do not specifically limit the execution order of the above steps S209 and S211.

[0255] After step S206, that is, after the Bluetooth driver of client 200 receives the creation completion notification, the Bluetooth driver of client 200 also executes step S213.

[0256] S213, the Bluetooth driver of client 200 sends a confirmation message to the Bluetooth driver of multicast source 100 to join the multicast group. The confirmation message may include the device identifier of client 200.

[0257] S214. Based on the above confirmation message, the Bluetooth driver of multicast source 100 sends a confirmation add notification to the multicast stack of multicast source 100. The confirmation add notification is used to instruct client 200 to confirm joining the multicast group.

[0258] S215. Based on the above confirmation and notification, add the multicast user information of client 200 to the multicast stack of multicast source 100.

[0259] In some embodiments, the multicast user information may include some or all of the following: the IP address of client 200, the MAC address of client 200, and the device ID. It is understood that the MAC address of client 200 can also be obtained when multicast source 100 interacts with client 200. For example, in steps S202 and S213, the MAC address of client 200 can be obtained via Bluetooth driver.

[0260] The multicast stack of multicast source 100 is used to manage multicast group information on the multicast source side. In some embodiments, the multicast group information on the multicast source side includes a multicast device list, which stores multicast user information of each client in the multicast group. Based on the aforementioned confirmation notification, the multicast stack adds the multicast user information of client 200 to the multicast device list. In subsequent multicast transmission phases, after receiving packets from other devices, multicast source 100 can determine whether the packets originated from clients in the multicast group based on the MAC addresses and / or IP addresses of each client in the multicast user list.

[0261] S216, The Bluetooth driver of multicast source 100 disconnects from the Bluetooth driver of client 200.

[0262] In this embodiment, the Bluetooth driver of the client 200 may actively disconnect the Bluetooth connection after executing step S213 or S207, or the Bluetooth driver of the multicast source 100 may actively disconnect the Bluetooth connection after step S213 or S214. No specific limitation is made here.

[0263] In this embodiment, after the multicast source 100 creates the multicast VAP1, it sequentially initiates a Bluetooth connection to each target device to invite the target device to join the multicast group. Since there is an upper limit to the number of Bluetooth connection links for terminal devices (e.g., 7), after the multicast source 100 invites a target device to join the multicast group via Bluetooth, it immediately disconnects the Bluetooth connection between the multicast source 100 and the target device and deletes the relevant information of the Bluetooth connection.

[0264] For example, taking client 300 as an example, Figure 7C The figure shows a flowchart of a client-initiated joining phase method provided by an embodiment of this application. As shown in the figure, after step S113 of the multicast startup phase described above, steps S301 to S318 may also be included, but are not limited to.

[0265] S301, the Bluetooth driver of client 200 and the Bluetooth driver of multicast source 100 exchange information to establish a Bluetooth connection.

[0266] In this embodiment, referring to the description of steps S101 to S103 above, after the user triggers the multicast startup process of multicast source 100 through operation 1, multicast source 100 will periodically broadcast a discovery signal 1 via Bluetooth. The discovery signal 1 includes the device identifier of multicast source 100. After receiving the discovery signal 1, the Bluetooth driver of client 300 can send a Bluetooth connection request to the Bluetooth driver of multicast source 100 based on the device identifier of multicast source 100 to request the establishment of a Bluetooth connection with multicast source 100. This embodiment does not specifically limit the implementation process of client 300 establishing a Bluetooth connection with multicast source 100, and will not be described in detail here.

[0267] In some embodiments, after the Bluetooth driver of client 300 receives discovery signal 1, it displays a prompt message, which can be used to indicate that multicast source 100 is performing multicast. Based on the above prompt message, the user performs operation 4 to join the multicast group. After the UI of client 200 detects operation 4, it notifies the Bluetooth driver of client 200 to send a Bluetooth connection request to the Bluetooth driver of multicast source 100 to request to establish a Bluetooth connection with multicast source 100, and then executes the subsequent method flow (i.e., steps S302 to S317).

[0268] For example, refer to Figures 4E to 4H According to the relevant description, in the screen casting scenario, after the Bluetooth driver of the client 300 receives the discovery signal broadcast by the multicast source 100, it displays a prompt message 305 around the icon 304 of the multicast source 100 in the multi-device collaboration page 15. The prompt message 305 is used to indicate that the multicast source 100 is initiating multicast screen casting; the above operation 4 may include dragging the icon 304 of the multicast source 100 closer to the icon 303 of the client 300.

[0269] S302, the Bluetooth driver of client 300 sends a join request message to the Bluetooth driver of multicast source 100. The join request message is used to request to join the multicast group; the join request message may include the device identifier of client 300.

[0270] S303. Based on the above join request message, the Bluetooth driver of multicast source 100 sends a join request instruction to the multicast stack of multicast source 100. The join request instruction is used to instruct client 300 to request to join the multicast group. The join request instruction may include the device identifier of client 300.

[0271] In some embodiments, during the aforementioned multicast startup phase, the multicast source 100 may also generate and display a multicast password for joining the multicast group. After the client 300 establishes a Bluetooth connection with the multicast source 100 in step S301, a password input box may also be displayed. After the user enters a password in the password input box, the client 300's UI can send the entered password to the client 300's Bluetooth driver; after confirming the entered password in step S302, the client 300 sends a join request message to the multicast source 100, and the join request message carries the entered password. Step S303 is executed only when the multicast source 100 verifies that the password carried in the Bluetooth connection request is the same as the aforementioned multicast password.

[0272] For example, refer to Figures 4E to 4H According to the relevant description, after detecting operation 4 (the user drags the icon 304 of the multicast source 100 close to the icon 303 of the client 300), the client 300 can display the password input box 308. After the user enters the PIN code of the screen-casting multicast group, the client 300 sends a join request message to the multicast source 100.

[0273] S304. Based on the above join request instruction, the multicast stack of multicast source 100 assigns IP address 3 to the VAP of client 300 and sends a client add instruction to the Bluetooth driver of multicast source 100. The client add instruction is used to instruct client 300 to join the multicast group.

[0274] S305. Based on the above client addition command, the Bluetooth driver of multicast source 100 sends a multicast invitation message to the Bluetooth driver of client 300. The multicast invitation message includes the multicast MAC address, the virtual multicast source address, the IP address 1 of multicast source 100, the IP address 3 of client 300, and the multicast key 1.

[0275] Compared to Figure 7B The multicast source invitation phase shown in the diagram adds a step to the client actively joining phase, where client 300 actively requests to join the multicast group via a join request message (i.e., step S302), and the Bluetooth driver of multicast source 100 notifies the WiFi driver client 300 to request to join the multicast group via a join request command (i.e., step S303). The specific implementation of the subsequent method flow (i.e., S305 to S317) of the client actively joining phase can be found in the aforementioned multicast source invitation phase (i.e., S203 to S215).

[0276] S306. Based on the multicast invitation message mentioned above, the Bluetooth driver of client 300 sends an HML creation command to the WiFi driver.

[0277] S307, based on HML creation instructions, the WiFi driver of client 300 creates VAP 3 to implement multicast services.

[0278] The WiFi driver of S308 and client 300 send a creation completion notification to the Bluetooth driver of client 300.

[0279] S309. Based on the above creation completion notification, the Bluetooth driver of client 300 sends a multicast configuration command to the multicast stack. The multicast configuration command includes the multicast MAC address, the virtual multicast source address, the IP address 1 of multicast source 100, the IP address 3 of client 300, and the multicast key 1.

[0280] S310. Based on the above multicast configuration instructions, the multicast stack of client 300 configures multicast group information for the multicast group. The multicast group information includes the multicast MAC address, the virtual multicast source address, the multicast key 1, the IP address 1 of multicast source 100, and the IP address 3 of client 300.

[0281] S311, the multicast stack of client 300 sends a multicast key configuration instruction to the WiFi driver. The multicast key configuration instruction includes the multicast key 1 mentioned above and the MAC address of multicast source 100.

[0282] S312. Based on the above multicast key configuration instructions, the WiFi driver of client 300 configures multicast key 1 as the multicast key of the multicast group, and the source address corresponding to multicast key 1 is the MAC address of multicast source 100.

[0283] S313, the multicast stack of client 300 sends an IP address configuration command to the WiFi driver, the IP address configuration command including the aforementioned IP address 3.

[0284] S314. Based on the above IP address configuration instructions, the WiFi driver of client 300 configures the IP address of VAP3 to IP address 3.

[0285] After step S309, that is, after the Bluetooth driver of client 300 receives the creation completion notification, the Bluetooth driver of client 300 also executes step S314.

[0286] The Bluetooth driver of S315 and client 300 sends a confirmation message to the Bluetooth driver of multicast source 100 to join the multicast group.

[0287] S316. Based on the above confirmation message, the Bluetooth driver of multicast source 100 sends a confirmation notification to the multicast stack of multicast source 100. The confirmation notification is used to instruct client 300 to confirm joining the multicast group.

[0288] S317. Based on the above confirmation and addition notification, add multicast user information of client 300 to the multicast stack of multicast source 100. The multicast user information may include the IP address 3, MAC address and device ID of client 300.

[0289] The Bluetooth driver of S318 and multicast source 100 disconnects from the Bluetooth driver of client 300.

[0290] In this embodiment, the Bluetooth driver of the client 200 may actively disconnect the Bluetooth connection after step S315 (i.e., sending an acknowledgment message to the multicast source 100) or step S309, or the Bluetooth driver of the multicast source 100 may actively disconnect the Bluetooth connection after step S315 (i.e., receiving the acknowledgment message sent by the client 200) or step S316. No specific limitation is made here.

[0291] 2. Multicast transmission

[0292] For example, taking client 200 as an example, Figure 8 A flowchart illustrating a method for a multicast transmission phase according to an embodiment of this application is shown. As shown, after step S216 of the multicast initiation phase described above, steps S801 to S804 may also be included, but are not limited to.

[0293] S801, the multicast stack of multicast source 100 sends a multicast transmission instruction to the WiFi driver of multicast source 100. The multicast transmission instruction includes multicast message 1. Multicast message 1 is generated based on the multicast group information on the multicast source side. The multicast group information on the multicast source side may include some or all of the following: multicast device list, multicast IP address, multicast MAC address, and multicast key 1.

[0294] In some embodiments, the data 1 to be multicast is encapsulated by the TCP / IP protocol stack to generate multicast message 1. Specifically, the TCP / IP protocol stack encapsulates data 1 into multicast message 1, including: the network layer adding an IP header to the message corresponding to data 1 transmitted from the upper layer to generate an IP message, and sending it to the WiFi-driven data link layer; the IP header includes the IP address of the multicast source 100 and the destination IP address (i.e., the multicast IP address). The data link layer adds a MAC header to the MSDU corresponding to the IP message transmitted from the upper layer, and encrypts the MSDU using multicast key 1 to generate multicast message 1; the MAC header includes the MAC address of the multicast source 100 and the destination MAC address (i.e., the multicast MAC address). The multicast transmission stage includes data frame transmission and signaling frame transmission, that is, the multicast message 1 can be a data frame or a signaling frame.

[0295] In some embodiments, when data 1 is valid data information from multicast transmission at the application layer (e.g., audio and video data in a screen projection scenario), the encapsulated multicast message 1 is a multicast data frame.

[0296] In some embodiments, when data 1 is control signaling and acknowledgment information transmitted via multicast, the encapsulated multicast message 1 is a multicast signaling frame. In some embodiments, when multicast message 1 is a signaling frame, the MSDU of multicast message 1 may also carry the actual destination address of the target client.

[0297] The control signaling for the multicast transmission mentioned above may include: control information that the application layer needs to transmit, such as video encoding and decoding parameters, screen projection control information, heartbeat packets, etc.; and control information of the HML multicast protocol itself, such as adaptive rate detection feedback, encoding parameters, etc.

[0298] S802, the Wi-Fi driver of multicast source 100 sends multicast message 1 via VAP1 multicast.

[0299] The S803 and client 200's Wi-Fi driver listens for multicast message 1 via VAP2.

[0300] The S804 and client 200 Wi-Fi drivers send multicast message 1, decrypted by multicast key 1, to the multicast stack.

[0301] In some embodiments, after the Wi-Fi driver of client 200 detects multicast message 1, it obtains the destination address in the MAC header of multicast message 1 and determines whether the destination address is the multicast MAC address of the multicast group that the device has joined. If not, the multicast message is discarded; if so, the source address (i.e., the MAC address of multicast source 100) in the MAC header of multicast message 1 is obtained. The Wi-Fi driver of client 200 looks up the table to obtain the key corresponding to the source address as multicast key 1; client 200 uses multicast key 1 to parse the data unit (e.g., MASDU) in multicast message 1.

[0302] In some embodiments, when multicast message 1 is a signaling frame, after being parsed by multicast key 1, client 200 can obtain the actual destination address carried in the data unit (e.g., MSDU) of multicast message 1; client 200 determines whether the above-mentioned actual destination address is the MAC address of this device; if so, it determines that multicast message 1 is sent to this device; if not, it discards multicast message 1.

[0303] For example, in a screen projection scenario, multicast message 1 can be a data frame; multicast message 1 is used to transmit screen projection data, and client 200 sends the screen projection data in multicast message 1 to display driver, and display driver instructs display screen to display the screen projection image based on the above screen projection data.

[0304] Similarly, the multicast stack of client 200 can also send multicast transmission instructions to the WiFi driver of client 200. The multicast transmission instructions include multicast message 2. Multicast message 2 is generated based on the multicast group information on the client side. The WiFi driver of client 200 sends multicast message 2 via VAP2. The WiFi driver of multicast source 100 listens for multicast message 2 via VAP1. The WiFi driver of multicast source 100 sends multicast message 2, decrypted by multicast key 1, to the multicast stack.

[0305] In some embodiments, for data frames in the multicast transmission phase, video encoding and decoding can tolerate a certain degree of packet loss, and multicast transmission can be achieved through redundant coding; however, for the aforementioned signaling frames, it is essential to ensure transmission to the receiving end to guarantee the stability of multicast transmission. Therefore, for the aforementioned signaling frames, embodiments of this application also provide a multicast retransmission mechanism. This retransmission mechanism can greatly improve the transmission reliability of signaling frames, thereby increasing the transmission rate of signaling frames.

[0306] The signaling frames involved in this application embodiment include the following two types: control signaling frames and signaling acknowledgment frames. Control signaling frames are used to transmit the aforementioned control signaling; signaling acknowledgment frames are used to indicate the reception status of control signaling frames. Based on the signaling acknowledgment frames fed back by the client, the multicast source 100 can determine whether to retransmit the control signaling frames.

[0307] The frame structure of the signaling frame provided in the embodiments of this application is described below.

[0308] For example, Figure 9A This illustration shows a frame format diagram of a control signaling frame provided in an embodiment of this application. Figure 9B This diagram illustrates a frame format of a signaling confirmation frame provided in an embodiment of this application. Figure 9A and Figure 9B As shown in the embodiments of this application, the signaling frame may include the following fields: MAC header, MAC service data unit (MSDU), and frame check sequence (FCS). The MAC header indicates relevant information about data transmission, the MSDU carries the valid data to be transmitted, and the FCS is used to perform integrity checks on the frame.

[0309] In some embodiments, the MAC Header includes the following seven parts: Frame Control, Duration / ID, Address1, Address2, Address3, Sequence Control, Address4, QoS Control, and High-Speed ​​Control (HT Control). The Frame Control structure indicates some or all of the following: protocol version, frame type, whether it is a frame sent from the Basic Service Set (BSS) to the Distributed System (DS), whether it is a frame sent from the DS to the BSS, whether there are remaining fragments for the segmented frame, whether it is a retransmission frame, whether it has entered power-saving mode, and whether link authentication is enabled. The frame type may include the following types: Management Frame 00 (for performing management operations), Control Frame 01 (for channel control), and Data Frame 10 (for transmitting valid data). Duration / ID indicates the time that the frame and its acknowledgment frame need to occupy the channel. The address fields (i.e., Address1, Address2, Address3, and Address4) can be used to indicate: TA (transmitter address), SA (source address), RA (receiver address), and DA (destination address), respectively. Sequence control is used to reassemble frame fragments and discard duplicate frames. In some embodiments, the Address2 field is used to store the source address, i.e., the MAC address of the sender.

[0310] In some embodiments, such as Figure 9AAs shown, the MSDU of the control signaling frame may include the following fields in sequence: destination address (Des Addr), source address (Src Addr), type / length (Type / Length), actual destination address (Actual DesAddr), actual source address (Actual Src Addr), HML control identifier (HML Control ID), and data payload (Payload).

[0311] The meanings of each field in the control signaling frame are as follows:

[0312] Destination address: When the receiver is a client in a multicast group, the destination address is the multicast MAC address of the multicast group; when the receiver is multicast source 100, the destination address is also the multicast MAC address.

[0313] Source address: When the sender is multicast source 100, the source address is the MAC address of multicast source 100; when the sender is a client in a multicast group, the source address is the aforementioned virtual multicast source address.

[0314] The Type / Length field includes the following: Multicast Type and Subtype. The Multicast Type represents the HML multicast frame type, which can include data frames, control signaling frames, and signaling acknowledgment frames. For example, when the multicast frame type is a control signaling frame, this field has a value of 0xFE. The Subtype represents the subtype corresponding to the multicast frame type. As shown in Table 1, control signaling frames mainly include the following subtypes:

[0315] Subtype illustrate 0 Control signaling issued by the application layer 1 RaptorQ encoded parameter notification frame 2 Adaptive parameter feedback frame Others reserve

[0316] Table 1

[0317] Actual Destination Address: The actual MAC address of the receiving end. When the receiving end is a client in a multicast group, since the control signaling frame uses multicast transmission, the destination address in both the Ethernet header and the MAC header is the multicast MAC address. This field is used to identify the client's accurate address.

[0318] Actual source address: The actual MAC address of the sender. As mentioned earlier, when the sender is a client in a multicast group, in order to solve the problem of the chip looking up the multicast key according to the source address, the client will fill in a unified virtual multicast source address in the Ethernet header and MAC header, and this field is to identify the accurate address of the client.

[0319] HML control identifier: The number of the control signaling frame (0-255).

[0320] Data payload: The specific control signaling carried by the control signaling frame.

[0321] In some embodiments, such as Figure 9B As shown, the MSDU of a signaling confirmation frame may include the following fields: destination address, source address, type / length, actual destination address, actual source address, and confirmation information (Confirm Info). Type / length may further include: multicast type and subtype. The meanings of each field in the signaling confirmation frame are as follows:

[0322] Multicast Type: Indicates the HML multicast frame type. For example, when the multicast frame type is a signaling acknowledgment frame, this field takes the value 0xFD. Subtype: This field is useless for signaling acknowledgment frames and can be filled with a default value, such as 0.

[0323] The confirmation information may include the following fields: Low Edge (LE), Up Edge (UE), and Bitmap. R-LE represents the low edge of the receive window, R-UE represents the up edge of the receive window, and the bitmap is used to provide feedback on the reception status of each control signaling frame in the current receive window. The low edge, up edge, and bitmap will be further explained in subsequent embodiments when describing the receive window; they will not be elaborated upon here.

[0324] The destination address, source address, actual destination address, and actual source address in the signaling confirmation frame can be found in the relevant descriptions of the corresponding fields in the control signaling frame, which will not be repeated here.

[0325] The following section uses client 200 as an example to provide a detailed introduction to the signaling frame transmission stage.

[0326] For example, taking client 200 as an example, Figure 9C A flowchart illustrating a method for the signaling frame transmission stage according to an embodiment of this application is shown. Figure 9C As shown, when the multicast message 1 is a control signaling frame 1 and the multicast message 2 is a signaling confirmation frame 1, after step S216 in the multicast establishment phase, steps S901 to S911 may also be included, but are not limited to.

[0327] S901, the multicast stack of multicast source 100 sends a multicast transmission instruction to the WiFi driver of multicast source 100; the multicast transmission instruction includes control signaling frame 1.

[0328] S902, the Wi-Fi driver of multicast source 100 sends control signaling frame 1 via VAP1 multicast.

[0329] Control signaling frame 1 can be the first transmitted control signaling frame or a retransmitted control signaling frame; no specific limitation is made here.

[0330] For example, refer to Figure 9AThe source address carried in the MAC header of control signaling frame 1 is the MAC address of multicast source 100; the source address in the MSDU of control signaling frame 1 is the MAC address of multicast source 100, the destination address is the multicast MAC address, the actual source address is the MAC address of multicast source 100, and the actual destination address is the MAC address of client 200.

[0331] The S903 and client 200's Wi-Fi driver listens for control signaling frame 1 via VAP2.

[0332] S904, the Wi-Fi driver of client 200 sends control signaling frame 1, which has been decrypted by multicast key 1, to the multicast stack.

[0333] Upon receiving control signaling frame 1, the Wi-Fi driver of client 200 obtains the source address in the MAC header of control signaling frame 1 and looks up the table to obtain the key corresponding to the source address as multicast key 1; the Wi-Fi driver of client 200 uses multicast key 1 to decrypt the MSDU in control signaling frame 1 and sends the decrypted MSDU to the multicast stack.

[0334] S905 and client 200's multicast stack update the receiving window corresponding to multicast source 100 based on control signaling frame 1, and determine signaling confirmation frame 1 based on the updated receiving window. Signaling confirmation frame 1 includes confirmation information, which is used to indicate the reception status of control signaling frames maintained by the receiving window corresponding to multicast source 100.

[0335] Each client in the multicast group (e.g., client 200) can maintain a receive window for the multicast source 100. The receive window is used to maintain reception information for control signaling frames received from the multicast source 100. When a control signaling frame is received from the multicast source 100, client 200 determines whether the control signaling frame is intended for this device based on the actual destination address carried in the MSDU (MSDU) of the control signaling frame. If so, it updates the receive window corresponding to the multicast source 100 based on the MSDU and determines acknowledgment information based on the updated receive window. The acknowledgment information includes the R-LE, R-UE, and Bitmap currently corresponding to the receive window, and is used to indicate the reception status of control signaling frames maintained by the receive window corresponding to the multicast source 100.

[0336] It is understandable that when multicast source 100 wants to send control signaling to client 200 separately, it can use the actual destination address (i.e., the MAC address of client 200) carried in the MSDU in control signaling frame 1 to let client 200 know that the control signaling frame is sent to this device; in this way, multicast source 100 does not need to establish a WiFi connection with client 200, and sending the above control signaling frame 1 through VAP multicast also indirectly realizes unicast transmission to client 200.

[0337] In some embodiments, a timeout processing mechanism for the receiving window is also provided. The client 200 can periodically update the receiving window corresponding to the multicast source 100 based on the timeout processing mechanism. Then, based on the updated receiving window, the client determines the acknowledgment information and sends the signaling acknowledgment frame corresponding to the acknowledgment information back to the multicast source 100.

[0338] S906, the multicast stack of client 200 sends signaling confirmation frame 1 to the Wi-Fi driver of client 200.

[0339] The S907 and client 200's Wi-Fi driver send signaling confirmation frame 1 via VAP2 multicast.

[0340] The S908 and multicast source 100's Wi-Fi driver listens for signaling confirmation frame 1 via VAP1.

[0341] S909, the Wi-Fi driver of multicast source 100 sends a signaling confirmation frame 1, decrypted by multicast key 1, to the multicast stack.

[0342] For example, refer to Figure 9B The source address carried in the MAC header of signaling confirmation frame 1 is the virtual multicast source address; the source address in the MSDU of signaling confirmation frame 1 is the virtual multicast source address, the destination address is the multicast MAC address, the actual source address is the MAC address of client 200, and the actual destination address is the MAC address of multicast source 100.

[0343] S910: The multicast stack of multicast source 100 updates the corresponding sending window of client 100 based on signaling confirmation frame 1, and determines whether to retransmit control signaling frame 2. If so, S911 is executed.

[0344] In some embodiments, the multicast source 100 can maintain a sending window for each client in the multicast group, such as the sending window corresponding to client 200. This sending window is used to buffer control signaling frames that have been sent but not received by client 200 and to maintain the sending information of the sent control signaling frames. Based on the signaling acknowledgment frame 1 returned by client 200, the multicast source 100 can update the sending window corresponding to client 200. Furthermore, for control signaling frame 2 that client 200 has not received, as indicated by signaling acknowledgment frame 1, the multicast source 100 can determine whether to retransmit control signaling frame 2 based on the sending information of control signaling frame 2 maintained in the sending window.

[0345] In some embodiments, a timeout processing mechanism for the sending window is also provided. The multicast source 100 can periodically update the sending window corresponding to each client (e.g., client 200) based on the timeout processing mechanism, and determine whether to retransmit the control signaling frames that have not yet been received and are buffered in the sending window based on the updated sending window corresponding to client 200.

[0346] S911, the multicast stack of multicast source 100 sends multicast transmission instructions to the Wi-Fi driver. The multicast transmission instructions are used to transmit control signaling frame 2.

[0347] In this embodiment of the application, clients in a multicast group can also send control signaling frames to multicast source 100, and multicast source 100 can also send back signaling confirmation frames to clients based on the received control signaling frames. For example, as shown... Figure 9C As shown, when the multicast message 2 is a control signaling frame 3 and the multicast message 1 is a signaling confirmation frame 2, after step S216 in the multicast establishment phase, steps S1001 to S1011 may also be included, but are not limited to.

[0348] S1001, the multicast stack of client 200 sends a multicast transmission command to the WiFi driver of client 200; the multicast transmission command includes control signaling frame 3.

[0349] For example, refer to Figure 9A The source address carried in the MAC header of control signaling frame 3 is the virtual multicast source address; the source address in the MSDU of control signaling frame 3 is the virtual multicast source address, the destination address is the multicast MAC address, the actual destination address is the MAC address of multicast source 100, and the actual source address is the MAC address of client 200.

[0350] S1002, the Wi-Fi driver of client 200 sends control signaling frame 3 via VAP2 multicast.

[0351] S1003, the Wi-Fi driver of multicast source 100 listens for control signaling frame 3 via VAP1.

[0352] S1004, the Wi-Fi driver of multicast source 100 sends control signaling frame 3, which has been decrypted by multicast key 1, to the multicast stack.

[0353] S1005, the multicast stack of multicast source 100 updates the receiving window corresponding to client 200 based on control signaling frame 3, and determines the acknowledgment information based on the updated receiving window. The acknowledgment information is used to indicate the reception status of control signaling frames maintained by the receiving window corresponding to client 200.

[0354] Multicast source 100 can maintain a separate receive window for each client (e.g., client 200) in the multicast group. The receive window is used to maintain reception information for control signaling frames received from client 200. When a control signaling frame is received from client 200, multicast source 100 determines whether the control signaling frame is intended for this device based on the actual destination address carried in the MSDU within the control signaling frame. If so, it updates the receive window corresponding to client 200 based on the MSDU and determines acknowledgment information based on the updated receive window. The acknowledgment information includes the current R-LE, R-UE, and Bitmap corresponding to the receive window, and is used to indicate the reception status of control signaling frames maintained by the receive window corresponding to client 200.

[0355] S1006, the multicast stack of multicast source 100 sends signaling confirmation frame 2 to the Wi-Fi driver of multicast source 100. Signaling confirmation frame 2 includes the aforementioned confirmation information.

[0356] S1007, the Wi-Fi driver of multicast source 100 sends signaling confirmation frame 2 via VAP1 multicast.

[0357] S1008 and the Wi-Fi driver of client 200 listened to signaling confirmation frame 2 through VAP2.

[0358] S1009, the Wi-Fi driver of client 200 sends a signaling confirmation frame 2, decrypted by multicast key 1, to the multicast stack.

[0359] For example, refer to Figure 9B The source address carried in the MAC header of signaling confirmation frame 2 is the virtual multicast source address; the source address in the MSDU of control signaling frame 1 is the virtual multicast source address, the destination address is the multicast MAC address, the actual source address is the MAC address of client 200, and the actual destination address is the MAC address of multicast source 100.

[0360] S1010: The multicast stack of client 200 updates the sending window corresponding to multicast source 100 based on signaling confirmation frame 2, and determines whether to retransmit control signaling frame 4. If so, S1011 is executed.

[0361] In some embodiments, each client in the multicast group maintains a sending window for the multicast source 100. This sending window is used to buffer control signaling frames that have been sent but not received by the multicast source 100 and to maintain the sending information of the sent control signaling frames. Based on the signaling acknowledgment frame 2 returned by the multicast source 100, the client 200 can update the sending window corresponding to the multicast source 100. Furthermore, for the control signaling frame 4 that the multicast source 100 has not received, as indicated by the signaling acknowledgment frame 2, the multicast source 100 can determine whether to retransmit the control signaling frame 4 based on the reception information of the control signaling frame 4 maintained in the sending window.

[0362] S1011 and the multicast stack of client 200 send multicast transmission instructions to the Wi-Fi driver. The multicast transmission instructions are used to transmit control signaling frame 4.

[0363] The following provides a detailed description of the receiving window and sending window involved in the retransmission mechanism provided in the embodiments of this application, and then describes the specific implementation of the above steps S901, S905, and S910. Similarly, the specific implementation of steps S1001, S1005, and S1010 can be referred to the relevant descriptions of S901, S905, and S910, respectively.

[0364] (1) Receive window

[0365] In this embodiment, the multicast source 100 maintains a receive window for each client in the multicast group, while each client in the multicast group only needs to maintain one receive window for the multicast source 100. A receive window is used to maintain the received information of control signaling frames from a specified sender; a receive window can maintain the received information of up to MAX_WINDOW_LEN control signaling frames. For example, the default value of MAX_WINDOW_LEN is 16.

[0366] For example, the client 200 maintains the receiving window corresponding to the multicast source 100 based on the control signaling frames received from the multicast source 100. Figure 10A A schematic diagram is shown of a receive window maintained by client 200 for multicast source 100. This receive window may include MAX_WINDOW_LEN (e.g., 16) smaller windows, each with an index from 0 to (MAX_WINDOW_LEN-1), for example, from 0 to 15. For each smaller window corresponding to the control signaling frame in the above receive window, the smaller window can maintain the receive information shown in Table 2.

[0367]

[0368] Table 2

[0369] like Figure 10A As shown, based on the HML control identifiers of the control signaling frames received by client 200 from multicast source 100, this receiving window can sequentially maintain the receiving information of each control signaling frame; according to the HML receiving identifiers corresponding to each small window, Figure 10A This indicates whether the control signaling frames corresponding to each small window in the receiving window have been received. For example... Figure 10AAs shown, all signaling frames with an HML control identifier less than or equal to 35 have been received, while signaling frames with an HML control identifier of 36 have not yet been received. This means that the minimum value of the HML control identifier for the unreceived control signaling frames in this receiving window is 36. Control signaling frames with an HML control identifier of 41 have been received, while all control signaling frames with an HML control identifier greater than 41 have not been received. This means that the maximum value of the HML control identifier for the received control signaling frames in this receiving window is 41.

[0370] The lower edge of the receive window (R-LE) refers to the minimum value of the HML control flag of the control signaling frames that have not been received in the receive window; the upper edge of the receive window (R-UE) refers to the maximum value of the HML control flag of the control signaling frames that have been received in the receive window. Figure 10A In the example, the R-LE of the receive window is 36 and the R-UE is 41.

[0371] In this embodiment of the application, the index of the small window corresponding to R-UE of the receiving window can be smaller than the index of the small window corresponding to R-LE. For example, Figure 10B The diagram illustrates another receive window maintained by client 200 for multicast source 100. In this receive window, R-UE is 47, the index of the small window corresponding to R-UE is 0, R-LE is 42, and the index of the small window corresponding to R-LE is 10. It can be understood that when the small window at index 15 has sequentially maintained the receive information of control signaling frames according to the HML control identifier, it then returns to starting from the small window at index 0 to continue sequentially maintaining the receive information of newly received control signaling frames. It can also be understood that the first small window of the receive window can be considered as the next small window after the last small window.

[0372] In this embodiment, the client 200 can reply with a signaling confirmation frame to the multicast source 100 based on the reception information of each small window in the receiving window, so as to provide feedback on the reception status of each control signaling frame. (See reference) Figure 9B The described signaling acknowledgment frame includes acknowledgment information such as the R-LE (Receiving Window), R-UE (Receiving Window User), and a Bitmap. The Bitmap indicates the reception status of control signaling frames corresponding to each small window from the small window pointed to by the R-LE to the small window pointed to by the R-UE. For example, based on... Figure 10A The received window shown has R-LE of 36, R-UE of 41, and Bitmap of 001101. The lowest bit of Bitmap, "0", indicates that the control signaling frame corresponding to the small window pointed to by "36" has not been received, and the highest bit, "1", indicates that the control signaling frame corresponding to the small window pointed to by "41" has been received.

[0373] The following describes in detail how, in step S905, the client 200 updates the receiving window of the multicast source 100 based on the received control signaling frame 1, and sends a signaling confirmation frame back to the multicast source 100 according to the receiving window.

[0374] For example, Figure 10C The diagram illustrates a processing flow for client 200 to update the receiving window of multicast source 100 and to receive feedback signaling confirmation frames. This processing flow includes steps S601 to S605.

[0375] S601. Based on the actual destination address in control signaling frame 1, determine whether it is a multicast frame sent to this device; if yes, proceed to step S602; if no, discard it directly and exit.

[0376] S602. Based on the actual source address in control signaling frame 1, determine whether the sender of control signaling frame 1 belongs to its own multicast group; if yes, proceed to step S603; if no, discard directly and exit.

[0377] Specifically, the multicast stack of client 200 is configured with the MAC address of multicast source 100 of the multicast group. Client 200 determines whether the actual source address in control signaling frame 1 is the MAC address of multicast source 100. If so, it determines that the sender of control signaling frame 1 belongs to its own multicast group, and client 200 executes step S603.

[0378] Similarly, the multicast stack of multicast source 100 is configured with the actual MAC addresses of each client in the multicast group. In step S1005, for the control signaling frame 3 sent by client 200 to multicast source 100, multicast source 100 can determine whether the sender of control signaling frame 3 is a client in the multicast group based on the actual source address field in control signaling frame 3.

[0379] S603. Based on the subtype in control signaling frame 1, submit this control signaling frame 1 to the corresponding module for processing.

[0380] Referring to Table 1, the subtypes of control signaling frames can include 0 (i.e., control signaling issued by the application layer), 1 (RaptorQ encoded parameter notification frame), 2 (i.e., adaptive parameter feedback frame), and others. In the embodiments of this application, different subtypes of control signaling frames can correspond to different processing modules. For example, when the subtype of control signaling frame 1 is 0, control signaling frame 1 is transmitted to the application layer for processing.

[0381] S604. Obtain the receiving window corresponding to multicast source 100 based on the actual source address (actual src addr) in control signaling frame 1.

[0382] S605. Update the receive window according to the HML control identifier in control signaling frame 1.

[0383] In some embodiments, see Figure 10D Step S605 may specifically include steps A1 to A10.

[0384] A1. Determine the index corresponding to the small window Index1 = (HMLControl ID%MAX_WINDOW_LEN) based on the HML control identifier of control signaling frame 1.

[0385] In this embodiment, the small window within the receiving window sequentially maintains the reception information of the received control signaling frames according to the HML control identifier of the received control signaling frames. Therefore, based on the HML control identifier of control signaling frame 1, the Index1 used to maintain the small window of control signaling frame 1 can be determined.

[0386] A2. Determine whether the receiving window is full based on the R-LE and R-UE of the receiving window. If it is full, proceed to step A3; if it is not full, proceed to step A4.

[0387] In some embodiments, reference Figure 10E When the index 1 of the window pointed to by R-LE equals the index 2 plus 1 of the window pointed to by R-UE, meaning the small window pointed to by R-LE is the next to the small window pointed to by R-UE, it is determined that the receiving window is full and there are no free small windows. (Reference) Figure 10A and Figure 10B If the small window pointed to by R-LE is not the next small window pointed to by R-UE, then it is determined that the receiving window is not full and there is an idle small window.

[0388] In some embodiments, an idle window refers to a window that has not yet maintained a specified control signaling frame, and the received information (e.g., HML control identifier) ​​in the idle window is a formatted initial value. In some embodiments, reference Figure 10A When the index of the small window pointed to by R-UE (i.e., In1) is greater than the index of the small window pointed to by R-LE (i.e., In2), there are idle small windows among the small windows with indices greater than In2 and / or smaller windows with indices less than In1. (Reference) Figure 10B When the index 2 of the window pointed to by R-UE is less than the index 1 of the window pointed to by R-LE, there is an idle small window in the small window with an index greater than In2 and less than In1.

[0389] A3. After clearing the small windows corresponding to Index2 to Index1, use the small window corresponding to Index1 to maintain the reception information of control signaling frame 1. Index2 is the index of the small window pointed to by R-LE, and Index2 = (R-LE%MAX_WINDOW_LEN).

[0390] In some embodiments, when the receive window is full, all small windows from R-LE to Index1 are cleared. Clearing the small windows of the receive window includes formatting the received information maintained by the small window and restoring the received information to its initial value. Control signaling frame 1 is maintained using the small window corresponding to Index1, specifically by updating the receive identifier of the small window corresponding to Index1 to 1 and updating the HML control identifier of the small window to the HML control identifier of control signaling frame 1.

[0391] A4. Determine if the receive flag (RecvFlag) of the small window corresponding to Index1 is 1; if yes, proceed to step A5; if no, proceed to step A6.

[0392] A5. Control signaling frame 1 is a duplicate frame. Discard control signaling frame 1 and exit.

[0393] A6. Update the receive flag of this small window to 1.

[0394] In some embodiments, when the receiving window is not full, if the receiving flag of the small window corresponding to Index1 is 1, it indicates that the control signaling frame maintained by the small window corresponding to Index1 is control signaling frame 1, and control signaling frame 1 has been received; the client 200 directly discards control signaling frame 1 and exits the processing flow. If the receiving flag of the small window corresponding to Index1 is 0, then based on the received control signaling frame 1, the receiving flag of the small window is set from 0 to 1.

[0395] In this embodiment of the application, after determining the small window with index 1 corresponding to the control signaling frame 1 and updating the receiving information of the small window, the client 200 can update the R-UE of the receiving window (e.g., execute steps A7 and A8), and / or update the R-LE of the receiving window (e.g., execute steps A7, A9 and A10).

[0396] A7. Determine whether the HML control identifier of control signaling frame 1 is greater than R-UE. If yes, proceed to step A8; otherwise, set j=R-LE and proceed to step A9.

[0397] A8. Update the R-UE to the HML control identifier of control signaling frame 1.

[0398] A9. Check if the RecvFlag of the small window with HML control identifier j is 0; if not, set j = j + 1 and return to step A9; if yes, execute step A10.

[0399] A10. Determine that the R-LE of the receiving window is j.

[0400] In some embodiments, when the HML control identifier of control signaling frame 1 is less than or equal to R-UE, the client determines the window pointed to by R-LE and the first small window with a receive identifier of 0 in the subsequent small windows, and updates R-LE to the HML control identifier of that small window, which may be referred to as the first small window.

[0401] S606, Client 200 can determine the signaling confirmation frame 1 to be fed back to multicast source 100 based on the updated receiving window of multicast source 100.

[0402] In some embodiments, after receiving a control signaling frame from the multicast source 100 and processing the receive window of the multicast source 100, the client 200 sends a signaling acknowledgment frame back to the multicast source 100. This allows for timely feedback to the multicast source 100 regarding the reception status of the control signaling frame.

[0403] In some embodiments, the client 200 may send a signaling acknowledgment frame back to the multicast source 100 only after receiving N control signaling frames from the multicast source 100 and processing the receiving window of the multicast source 100 according to each of the N control signaling frames. Compared to sending a signaling acknowledgment frame after each received control signaling frame, this can reduce signaling loss and increase the signaling transmission rate.

[0404] In some embodiments, the client 200 periodically sends signaling acknowledgment frames to the device based on the latest status of the multicast source 100's receive window. Compared to sending a signaling acknowledgment frame after each received control signaling frame, this reduces signaling loss and increases the signaling transmission rate.

[0405] The timeout handling mechanism for the receiving window is described in detail below.

[0406] In this embodiment, both the multicast source 100 and the clients in the multicast group periodically time out each receiving window they maintain, with a preset duration as one period. For example, the preset duration is 1 second. The timeout processing mechanism for the receiving window is described below using the receiving window corresponding to the multicast source 100 maintained by client 200 as an example.

[0407] In some embodiments, for the transmission window of multicast source 100, client 200 iterates through N small windows from the small window pointed to by R-LE to the small window pointed to by R-UE, searching for each small window with a receive flag of 0, where N is a positive integer greater than 1. For a small window 1 with a receive flag of 0 (this small window can be referred to as the fourth small window), the timeout polling count corresponding to small window 1 is incremented by 1. If the incremented count exceeds a preset value of 1 (i.e., the second preset value), then the small window pointed to by R-LE to small window 1 is forcibly cleared. The preset value of 1 can be referred to as the forced commit period (FORCE_COMMIT_PERIOD), for example, the preset value of 1 equals 5. Then, client 200 performs window shifting processing starting from small window 1, determines the first unreceived small window 2 after small window 1 (this small window can be referred to as the fifth small window); updates the R-LE of the receiving window to the HML control flag corresponding to small window 2, that is, points R-LE to small window 2.

[0408] For example, Figure 10F The diagram illustrates the timeout handling process for the receive window of multicast source 100 by client 200. The initial value of j is set to 1. The above process includes steps B1 to B6. Let the initial value of j be 1.

[0409] B1. Determine whether the receive flag (RecvFlag) of the j-th small window in the N small windows from R-LE to R-UE in the receive window is 0, where N is a positive integer greater than 1; if not, let j = j + 1 and return to execute step B1; if yes, execute step B2.

[0410] B2. Increment the timeout polling count (Tick) corresponding to the j-th small window by 1.

[0411] B3. Determine whether the tick corresponding to the j-th small window is greater than the preset value 1; if not, set j = j + 1 and return to step B1; if yes, proceed to step B4.

[0412] B4. Clear the small window pointed to by R-LE in the above N windows up to the j-th small window, and set j = j + 1.

[0413] B5. Determine if the receive flag of the j-th small window is 0; if not, set j = j + 1 and return to step B5; if yes, proceed to step B6.

[0414] B6. Set the R-LE of the receiving window to the j-th small window, that is, update R-LE to the HML control identifier corresponding to the j-th small window.

[0415] For example, such as Figure 10GAs shown, for the six small windows with HML control identifiers from R-LE (i.e., 36) to R-UE (i.e., 41) in the receiving window, the receiving identifier of small window 1 with HML control identifier 37 is determined to be 0. If the tick of small window 1 is greater than 5 after being incremented by 1, the small windows with HML control identifiers from 36 to 37 are cleared, and R-LE is updated to the HML control identifier of the first unreceived small window after small window 1, i.e., 40.

[0416] Similarly, the timeout handling process for the client's receive window by multicast source 100 includes: multicast source 100 iterates through the receive windows corresponding to each client in the multicast group, performs timeout handling for each client's receive window, and updates the receive window and its R-LE for each client. The specific implementation of the timeout handling for the client's receive window by multicast source 100 can be found in the description of the timeout handling for the client's receive window by multicast source 100 mentioned above, and will not be repeated here.

[0417] (2) Send window

[0418] In this embodiment, the multicast source 100 maintains a sending window for each client in the multicast group, while each client in the multicast group only needs to maintain one sending window for the multicast source 100. The sending window is used to buffer signaling frames that have been sent but not yet successfully received, and to maintain their corresponding transmission information; the sending window can buffer a maximum of MAX_WINDOW_LEN control signaling frames. For example, the default value of MAX_WINDOW_LEN is 16.

[0419] For example, multicast source 100 can send control signaling frames to client 200, and maintain the corresponding sending window for client 200 based on the sent control signaling frames and the signaling acknowledgment frame 1 returned by client 200. The signaling acknowledgment frame 1 returned by client 200 is used to indicate that no control signaling frames have been received. Figure 11A A schematic diagram is shown of the transmission window maintained by multicast source 100 for client 200. This transmission window may include MAX_WINDOW_LEN (e.g., 16) smaller windows, each with an index from 0 to (MAX_WINDOW_LEN-1), for example, from 0 to 15. For each smaller window corresponding to the control signaling frame in the above transmission window, the smaller window can maintain the transmission information shown in Table 3.

[0420]

[0421] Table 3

[0422] like Figure 11AAs shown, according to the HML control identifier of the control signaling frame sent from multicast source 100 to client 200, the sending window can sequentially maintain the sending information of each control signaling frame, based on the sending status corresponding to each small window. Figure 11A This indicates whether the control signaling frames corresponding to each small window in the transmission window have been acknowledged, i.e., whether they have been confirmed as received. For example, the control signaling frame with HML control identifier 35 has been acknowledged, while the signaling frame with HML control identifier 36 has not yet been acknowledged.

[0423] Similar to the receive window, the transmit window also has a lower edge (T-LE) and a upper edge (T-UE). T-LE points to the small window corresponding to the earliest transmitted control signaling frame that has not yet received an acknowledgment; T-LE is equal to the HML control identifier of that control signaling frame. T-UE points to the small window corresponding to the most recently transmitted control signaling frame; T-UE is equal to the HML control identifier of that control signaling frame. When the transmit window is full, subsequent signaling frames to be transmitted are cached in a pre-defined linked list (e.g., the CachedSkb linked list).

[0424] Similar to the receive window, a full transmit window means that the small window pointed to by T-LE is the next to the small window pointed to by T-UE, and there are no idle small windows in the transmit window. A partially full transmit window means that the small window pointed to by T-LE is not the next to the small window pointed to by T-UE, and there are idle small windows in the transmit window. The first small window in the transmit window can be considered as the next small window after the last small window. In some embodiments, an idle small window in the transmit window means that the idle small window does not buffer control signaling frames, nor does it maintain the transmission information for specified control signaling frames; the transmission information of this transmit window is the formatted initial value.

[0425] In this embodiment of the application, when a specific event occurs in the multicast source 100, the multicast source 100 can be triggered to send a control signaling frame to the client 200 and update the sending window. For example, in the aforementioned step S901, the multicast source 100 sends control signaling frame 1 to the client 200, and in the aforementioned step S911, the multicast source 100 sends control signaling frame 2 to the client 200. The aforementioned specific event may include the following events 1 to 3.

[0426] Event 1: Other modules (such as the APP or adaptive parameter adjustment module in the application layer) construct a new control signaling frame for client 200, and multicast source 100 sends the control signaling frame to client 200.

[0427] Event 2: Multicast source 100 receives a signaling acknowledgment frame from client 200, which triggers the retransmission of the specified control signaling frame.

[0428] For example, in the aforementioned step S910, when the signaling confirmation frame 1 from the client 200 is received, the multicast source 100 can update the sending window based on the R-UE, R-LE, and Bitmap in the signaling confirmation frame 1, and trigger a retransmission control signaling frame 2 when the sending window meets the retransmission conditions. In subsequent embodiments, Figure 11B The specific implementation process of step S910 is shown, and will not be elaborated here.

[0429] Event 3: Timeout handling mechanism triggers retransmission.

[0430] In this embodiment, the multicast source 100 or the client in the multicast group periodically times out its maintained receiving window for a preset duration. During the timeout process, when the sending window meets the retransmission conditions, a specific control signaling frame is retransmitted. For example, the preset duration is 1 second. In subsequent embodiments, Figure 11E The implementation flow of the timeout handling mechanism for the sending window is shown, which will not be elaborated here.

[0431] The following details how multicast source 100 updates the corresponding sending window of client 200 and triggers retransmission based on signaling confirmation frame 1 in step S910. The confirmation information in signaling confirmation frame 1 carries the R_LE, R_UE, and Bitmap of the receiving window.

[0432] For example, Figure 11B A processing flow for step S910 is shown, which includes steps S701 to S706.

[0433] S701. Based on the actual destination address in signaling confirmation frame 1, determine whether it is a multicast frame sent to this device; if yes, proceed to step S702; if no, discard the signaling confirmation frame directly and exit.

[0434] S702. Based on the actual source address in signaling confirmation frame 1, determine whether the sender of signaling confirmation frame 1 belongs to its own multicast group; if yes, proceed to step S703; if no, discard the signaling confirmation frame directly and exit.

[0435] The multicast stack of multicast source 100 is configured with the actual MAC addresses of each client in the multicast group. Based on the actual source address in signaling confirmation frame 1, multicast source 100 can determine whether the sender of signaling confirmation frame 1 is a client in the multicast group.

[0436] S703. Based on the actual source address (actual src addr) in signaling confirmation frame 1, multicast source 100 obtains the sending window corresponding to client 200.

[0437] S704. Confirm that R-LE is less than T-LE or R-UE is greater than T-UE; if so, exit the processing flow; if not, proceed to step S705.

[0438] For example, see Figure 11A The current T_LE of the sending window is 36 and T_UE is 42. When R-LE is less than 36 or R-UE is greater than 42, it indicates that the signaling confirmation frame 1 is an outdated frame or an error frame, and the multicast source 100 exits the processing flow. When R-LE is greater than 36 and R-UE is less than 42, the multicast source 100 continues to execute the subsequent process.

[0439] S705. When R-LE is greater than T-LE, clear the small window before the small window pointed to by T-LE in the sending window (i.e., the small window whose HML control identifier is R-LE); then update the value of T-LE to R-LE.

[0440] In some embodiments, clearing a small window in the sending window includes releasing the control signaling frames stored in the PktBuf field of the small window and clearing (e.g., formatting, restoring to initial values) the sending information maintained by the small window.

[0441] Specifically, in one implementation, see [link to implementation details]. Figure 11C Step S705 includes steps C1 to C3.

[0442] C1. Set frameid to T-LE.

[0443] C2. Determine if frameid is equal to R-LE; if not, proceed to step C3; if yes, update the value of T-LE to R-LE and proceed to step S706.

[0444] C3. Clear the small window corresponding to frameid; then, set frameid = frameid + 1, and return to step C2.

[0445] For example, see Figure 11D The current T_LE of the sending window is 36, and T_UE is 42; the R-LE of the receiving window carried by signaling confirmation frame 1 is 38, and R-UE is 41. Multicast source 100 clears the small windows with HML control identifiers of 36 to 37 in the sending window and updates the T-LE value to 38.

[0446] S706. When R-LE equals T-LE, based on Bitmap, determine the small windows that have been received in the small windows pointed to by R-LE to R-UE in the sending window, release the control signaling frames buffered in the storage address of the small windows; and determine the small windows that have not been received, and determine whether to retransmit the control signaling frame 2 maintained by the small windows.

[0447] In some embodiments, the multicast source 100, based on the R-LE, R-UE, and Bitmap carried in the signaling acknowledgment frame 1, determines the small window corresponding to the control signaling frame marked with 1 in the transmission window, and releases the control signaling frame in the storage address buffer corresponding to the small window. This small window can be referred to as the second small window. The source 100 also determines the small window corresponding to the control signaling frame 2 marked with 0 in the transmission window, and retransmits the control signaling frame 2 when the small window meets the retransmission condition. This small window can be referred to as the third small window. In some embodiments, releasing the control signaling frame in the storage address buffer corresponding to the small window includes: deleting the control signaling frame in the storage address buffer of the small window from the PktBuf field, and clearing (e.g., formatting, restoring the initial value) the storage address in the PktBuf field.

[0448] Specifically, in one implementation, the initial value of frameid is set to R-LE; see [link to implementation]. Figure 11C Step S706 includes C4 to C8.

[0449] C4. Determine if frameid is less than R-UE; if yes, proceed to step C5; otherwise, exit the processing flow.

[0450] C5. Based on the Bitmap carried in the signaling confirmation frame 1, determine whether the small window corresponding to frameid is marked as 1 in the Bitmap; if yes, proceed to step C6; if no, proceed to step C7.

[0451] Based on the R-LE, R-UE, and Bitmap carried in signaling confirmation frame 1, it can be determined whether the small window with the HML control identifier frameid is marked as 1 in the Bitmap. A mark of 1 indicates that the control signaling frame corresponding to the small window has been received, while a mark of 0 indicates that the control signaling frame corresponding to the small window has not been received.

[0452] C6. Release the control signaling frame cached in the small window corresponding to frameid, set frameid = frameid + 1, and return to step C4. Then continue processing the next window until all the flag bits in the Bitmap have been traversed.

[0453] C7. Determine if the small window corresponding to frameid meets the retransmission condition; if yes, proceed to step C8; if no, set frameid = frameid + 1 and return to step C4. Then continue processing the next window until all the flag bits in the Bitmap have been traversed.

[0454] If the flag bit of the small window whose HML control identifier is frameid is marked as 0 in the Bitmap, then based on the retransmission identifier and the number of retransmissions of the small window, it is determined whether the control signaling frame buffered by the small window meets the retransmission condition; if it does, then the above control signaling frame is retransmitted.

[0455] In some embodiments, the retransmission conditions include: the small window corresponding to the frameid has not been retransmitted in the current retransmission period (i.e., the retransmission flag RetranFlag is 0); the number of retransmissions (RetranCnt) of the small window corresponding to the frameid is less than a preset maximum value (MAX_RETRAN_CNT), for example, MAX_RETRAN_CNT is 5.

[0456] C8. Retransmit the control signaling frame 2 in the small window buffer corresponding to frameid, update the retransmission flag corresponding to the small window to 1, and the retransmission count RerantCnt is equal to RerantCnt+1.

[0457] For example, see Figure 11D The current T_LE of the sending window is 36, and T_UE is 42; the R-LE of the receiving window carried in the signaling acknowledgment is 38, R-UE is 41, and Bitmap is 0101. Multicast source 100 clears the small windows with HML control identifiers 36 and 37 and updates T-LE to 38. The four flag bits in the Bitmap indicate whether control signaling frames with HML control identifiers 38 to 41 have been received. The Bitmap indicates that control signaling frames with HML control identifiers 39 and 41 have been received. For small windows with HML control identifiers 38 and 40 in the sending window, multicast source 100 releases the control signaling frames cached at the storage address in the small window. The Bitmap indicates that control signaling frames with HML control identifiers 38 and 40 have not been received. Taking the control signaling frame with HML control identifier 38 as an example, multicast source 100 determines whether the small window with HML control identifier 38 in the sending window meets the retransmission condition; if it does, it retransmits the control signaling frame with HML control identifier 39 cached in that small window.

[0458] The timeout handling mechanism for the sending window is described in detail below.

[0459] Similar to the receive window, both multicast source 100 and clients in the multicast group periodically time out each receive window they maintain, with a preset duration of 1 second. The following section uses the send window corresponding to client 200 maintained by multicast source 100 as an example to illustrate the timeout mechanism for the send window.

[0460] In some embodiments, timeout processing for the transmission window is performed in 1-second intervals. For the transmission window corresponding to client 200, multicast source 100 traverses N small windows from the small window pointed to by T-LE to the small window pointed to by T-UE. For any small window 1 with a transmission status (SendStatus) of 0 among the N small windows, the timeout polling (Tick) count corresponding to small window 1 is incremented by 1. This small window can be referred to as the sixth small window. If the incremented Tick is greater than or equal to a preset value 2 (e.g., RETRAN_PEROID), it is determined whether small window 1 meets the retransmission condition. If it does, the control signaling frame maintained by small window 1 is retransmitted, and the Tick of small window 1 is set to 0, the retransmission flag (RetranFlag) is set to 1, and the retransmission count (RetranCnt) is incremented by 1. If the retransmission condition is not met and the retransmission count exceeds a preset value 3 (e.g., MAX_RETRAN_CNT), small window 1 is cleared, and T-LE is set to the first small window with a transmission status of 0 after this small window. In some embodiments, the multicast source 100 may also point T-LE to the small window with a transmission status of 0 and the smallest control identifier after traversing the above N small windows.

[0461] For example, Figure 11E This illustrates a process flow for timeout handling of the sending window corresponding to client 200 by multicast source 100. The initial value of j is set to 1, and the above process includes steps D1 to D6.

[0462] D1. Determine whether the SendStatus of the j-th small window in the N small windows from T-LE to T-UE in the receiving window is 0, where N is a positive integer greater than 1 and j is less than or equal to N; if not, let j = j + 1 and return to execute step D1; if yes, execute step D2.

[0463] D2. Increment the timeout polling count (Tick) corresponding to the j-th small window by 1.

[0464] D3. Determine whether the tick corresponding to the j-th small window is greater than the preset value 2; if not, let j = j + 1 and return to execute step D1; if yes, execute step D4.

[0465] D4. Determine whether the j-th small window meets the retransmission condition; if yes, proceed to step D5; if no, proceed to step D6.

[0466] D5. Retransmit the control signaling frame buffered in the j-th small window, set Tick to 0, set the retransmission flag to 0, and increment the retransmission count by 1. Then, set j = j + 1 and return to execute step D1.

[0467] D6. Determine whether the number of retransmissions for the j-th small window is greater than the preset value of 3; if yes, proceed to step D7; if no, set j = j + 1 and return to step D1.

[0468] D7. Clear the j-th small window by setting j = j + 1.

[0469] D8. Determine if the receive flag of the j-th small window is equal to 0; if yes, proceed to step D9; if no, set j = j + 1 and return to step D1.

[0470] D9. Set T-LE to the j-th window.

[0471] 3. Multicast deletion

[0472] Members in a multicast group are dynamic; hosts can join and leave the multicast group at any time.

[0473] In some embodiments, taking client 200 as an example, client 200 can actively leave the multicast group; when client 200 actively leaves the multicast group, it will delete the multicast group information of the multicast group and notify multicast source 100 via Bluetooth, and multicast source 100 will remove client 200 from the multicast device list of the multicast group.

[0474] For example, taking client 200 as an example, Figure 12A The figure shows a flowchart of a client-initiated exit phase method provided by an embodiment of this application. As shown, after the client 200 joins the multicast group (e.g., after the aforementioned step S216), steps S401 to S412 may also be included, but are not limited to.

[0475] S401, the UI of client 200 detected user operation 5, which is used to exit the multicast group.

[0476] In some embodiments, the client 200 is provided with a UI entry point for leaving the multicast group. By performing operation 5 on this UI entry point, the user can trigger the client 200 to actively leave the multicast group and close the multicast application. For example, refer to... Figures 5A to 5BAccording to the relevant description, in the screen casting scenario, the multicast application mentioned above can be a screen casting application, and operation 5 can be used to exit the screen casting multicast group; based on the screen casting data sent by multicast source 100, client 200 can display screen casting screen 17; screen casting screen 17 is equipped with an exit control 401, and operation 5 includes a click operation on the exit control 401; in response to operation 5, client 200 can stop displaying the screen casting screen and close the screen casting application.

[0477] S402, based on operation 5, the UI of client 200 sends a multicast end command to the Bluetooth driver.

[0478] S403. Based on the multicast end command, the Bluetooth driver of client 200 and the Bluetooth driver of multicast source 100 exchange information to establish a Bluetooth connection.

[0479] For details, please refer to the relevant description of step S202, which will not be repeated here.

[0480] S404, the Bluetooth driver of client 200 sends a multicast disconnect request message to the Bluetooth driver of multicast source 100. The multicast disconnect request message includes the device identifier of client 200.

[0481] S405. Based on the multicast disconnect request message, the Bluetooth driver of multicast source 100 sends a multicast disconnect confirmation message to the Bluetooth driver of client 200.

[0482] S406. Based on the multicast disconnection confirmation message, the Bluetooth driver of client 200 sends a multicast cancellation command to the WiFi driver of client 200.

[0483] S407. Based on the above multicast cancellation instruction, the WiFi driver of client 200 sends a multicast end notification to the multicast stack of client 200.

[0484] S408. Based on the above multicast end notification, the multicast stack of client 200 deletes the multicast group information on the client side.

[0485] In some embodiments, the multicast group information on the client side includes some or all of the following information: multicast MAC address, virtual multicast source address, multicast key 1, IP address 1 of multicast source 100 and IP address 2 of client 200.

[0486] After the Bluetooth driver of multicast source 100 receives the multicast disconnection request message in step S404, steps S409 to S412 are also included.

[0487] S409. Based on the multicast disconnection request message, the Bluetooth driver of multicast source 100 sends a client exit command to the WiFi driver of multicast source 100. The client exit command is used to instruct the client 200 to be deleted from the multicast group.

[0488] S410. Based on the aforementioned client exit instruction, the WiFi driver of multicast source 100 sends a client deletion instruction to the multicast stack of multicast source 100. The client deletion instruction is used to instruct the client 200 in the multicast group to be deleted.

[0489] S411. Based on the above client deletion command, the multicast stack of multicast source 100 deletes the multicast user information of client 200.

[0490] In some embodiments, the multicast group information maintained by the multicast source 100 includes a list of multicast devices for the multicast group, which stores multicast user information for each client in the multicast group. The multicast source 100 deletes the multicast user information of client 200 from the multicast device list.

[0491] S412, the Bluetooth driver of multicast source 100 disconnects from the Bluetooth driver of client 200.

[0492] In this embodiment, the Bluetooth driver of the multicast source 100 may actively disconnect the Bluetooth connection after step S405 (i.e., sending a multicast disconnection confirmation message to the client 200) or S409, or the Bluetooth driver of the client 200 may actively disconnect the Bluetooth connection after step S405 (i.e., receiving the multicast disconnection confirmation message sent by the multicast source 100) or S406. No specific limitation is made here.

[0493] In some embodiments, when multicast source 100 ends multicast sharing of the multicast group, it can delete the multicast group information on the multicast source side and broadcast a multicast deletion message via Bluetooth; after each client receives the multicast deletion message, it exits the multicast application and deletes the multicast group information in its own client.

[0494] For example, taking client 200 as an example, Figure 12B The figure shows a flowchart of a method for multicast source deletion stage provided by an embodiment of this application. As shown in the figure, after the client 200 joins the multicast group (for example, after the aforementioned step S216), steps S501 to S511 may also be included.

[0495] S501, the UI of multicast source 100 detected user operation 6, which is used to delete the multicast group.

[0496] In some embodiments, the multicast source 100 is provided with a UI entry point for deleting a multicast group. Users can trigger the multicast source 100 to delete the multicast group and close the multicast application by performing operation 6 on this UI entry point. For example, see [reference needed]. Figures 5C to 5DAccording to the relevant description, in the screen casting scenario, the multicast application mentioned above can be a screen casting application, and operation 6 can be used to delete the screen casting multicast group; when the multicast source 100 multicasts to the client in the multicast group, the user interface displayed by the multicast source 100 is set with an end control 402, and operation 6 includes a click operation on the end control 402; in response to operation 6, the multicast source 100 stops the multicast screen casting, deletes the screen casting multicast group, and closes the screen casting application.

[0497] S502, based on operation 6, the UI of multicast source 100 sends a multicast end command to the Bluetooth driver of multicast source 100.

[0498] S503. Based on the above multicast end command, the Bluetooth driver of multicast source 100 broadcasts a multicast deletion message.

[0499] In some embodiments, the Bluetooth driver of the multicast source 100 periodically broadcasts a multicast deletion message via Bluetooth within a preset time period after receiving a multicast end command, so that all clients in the multicast group can receive it.

[0500] S504. Based on the above multicast end command, the Bluetooth driver of multicast source 100 sends a multicast cancellation command to the WiFi driver of multicast source 100.

[0501] S505. Based on the above multicast cancellation instruction, the WiFi driver of multicast source 100 sends a multicast end notification to the multicast stack of multicast source 100.

[0502] S506. Based on the above multicast end notification, the multicast stack of multicast source 100 deletes the multicast group information on the multicast source side.

[0503] In some embodiments, the multicast group information on the multicast source side includes some or all of the following information: multicast device list, multicast MAC address, virtual multicast source address, multicast key 1, etc.

[0504] After receiving the multicast deletion message broadcast by multicast source 100 via Bluetooth, the Bluetooth driver of S507 and client 200 sends a multicast cancellation command to the UI of client 200.

[0505] S508. Based on the above multicast cancellation command, the UI of client 200 exits the multicast sharing interface.

[0506] For example, refer to Figure 3F and Figure 3G According to the relevant description, in the screen projection scenario, the multicast sharing interface mentioned above can include the screen projection screen 13.

[0507] After receiving the multicast deletion message broadcast by the multicast source 100, the Bluetooth driver of S509 and client 200 also send a deletion command to the WiFi driver of client 200.

[0508] S510. Based on the above cancellation instruction, the WiFi driver of client 200 sends a multicast end notification to the multicast stack of client 200.

[0509] S511. Based on the above multicast end notification, the multicast stack of client 200 deletes the multicast group information.

[0510] Based on the foregoing embodiments, this application provides a multicast communication method applied to a multicast communication system, which includes a multicast source and at least one client, wherein the at least one client includes a first client. Exemplarily, the multicast communication method includes steps S1101 to S1107.

[0511] S1101. The multicast source determines the multicast address and the first multicast key of the multicast group.

[0512] For example, the first multicast key includes the aforementioned multicast key 1.

[0513] S1102. The multicast source sends a first Bluetooth message to the first client. The first Bluetooth message is used to invite the first client to join the multicast group. The first Bluetooth message includes the multicast address and the first multicast key.

[0514] For example, the first client includes the aforementioned client 200 or client 300, and the first Bluetooth message includes the aforementioned multicast invitation message.

[0515] In some embodiments, the method further includes: a multicast source receiving a first operation, the first operation being used to create a multicast group; the multicast source determining the multicast address and a first multicast key of the multicast group, including: in response to the first operation, the multicast source determining the multicast address and the first multicast key of the multicast group.

[0516] For example, the first operation includes the aforementioned operation 1. (See reference...) Figures 3A to 3D According to the relevant description, in the screen casting scenario, operation 1 can be an operation to enable wireless screen casting, such as clicking the switch icon 201 for wireless screen casting.

[0517] In some embodiments, before the multicast source sends the first Bluetooth message to the first client, the method further includes: the multicast source scanning for nearby Bluetooth devices that support multicast communication; the multicast source displaying at least one scanned Bluetooth device, wherein the at least one Bluetooth device includes the first client; the multicast source receiving a second operation, the second operation being used to invite the first client to join the multicast group; and in response to the second operation, the multicast source establishing a Bluetooth connection with the first client.

[0518] For example, the second operation includes the aforementioned operation 3. For example, refer to Figures 3A to 3DAccording to the relevant description, in a screen mirroring scenario, the multicast source will display the device options of the detected HML multicast devices that have enabled wireless sharing on the user interface 11 for the user to select. For example, operation 3 includes an operation (e.g., a click operation) on the device option 203 of the client 200.

[0519] In some embodiments, before the multicast source displays at least one scanned Bluetooth device, the method further includes: a first client receiving a third operation; in response to the third operation, the first client broadcasts a first discovery signal via Bluetooth, the first discovery signal indicating that the first client supports multicast communication; and the multicast source scanning the first client based on the first discovery signal.

[0520] For example, the third operation includes the aforementioned operation 2, and the first detection signal includes the aforementioned detection signal 2. (See reference...) Figures 4C to 4D According to the relevant description, in the screen projection scenario, the above operation 2 includes the operation of enabling wireless sharing. For example, operation 2 can be the click operation of the switch icon 302 that acts on wireless screen projection.

[0521] In some embodiments, before the multicast source sends a first Bluetooth message to the first client, the method further includes: in response to a first operation, the multicast source broadcasts a second discovery signal via Bluetooth; based on the second discovery signal detected via Bluetooth, the first client establishes a Bluetooth connection with the multicast source; the first client sends a third Bluetooth message to the multicast source, the third Bluetooth message being used to request joining the multicast group; the multicast source sending the first Bluetooth message to the first client includes: in response to the third Bluetooth message, the multicast source sends the first Bluetooth message to the first client.

[0522] For example, the second discovery signal includes the aforementioned discovery signal 1, and the third Bluetooth message includes the aforementioned join request message.

[0523] In some embodiments, before the multicast source sends the first Bluetooth message to the first client, the method further includes: the multicast source assigning a first IP address to its first VAP and assigning a second IP address to the client's second VAP; the first Bluetooth message also includes the first IP address and the second IP address; the first IP address and the second IP address are used to encapsulate multicast packets, the source IP address in the multicast packet sent by the multicast source is the first IP address, and the source IP address in the multicast packet sent by the first client is the second IP address.

[0524] For example, the first VAP includes the aforementioned VAP1, and the first IP address includes the aforementioned IP address 1. The first client includes the aforementioned client 200, the second VAP includes the aforementioned VAP2, and the second IP address includes the aforementioned IP address 2; or, the first client includes the aforementioned client 300, the second VAP includes the aforementioned VAP3, and the second IP address includes the aforementioned IP address 3.

[0525] S1103. The first client sends a second Bluetooth message to the multicast source based on the first Bluetooth message; the second Bluetooth message is used to instruct the first client to confirm joining the multicast group.

[0526] For example, the second Bluetooth message includes the aforementioned confirmation join message.

[0527] In some embodiments, after the first client sends the second Bluetooth message to the multicast source, the method further includes: disconnecting the Bluetooth connection between the multicast source and the first client.

[0528] In some embodiments, the method further includes: based on a second Bluetooth message, the first multicast source adds multicast user information of the first client to the multicast device list; the multicast device list is used to store multicast user information of each client in the multicast group, and the multicast user information of the first client includes the MAC address and the second IP address of the first client.

[0529] S1104. The first client configures the source address corresponding to the first multicast key to be the MAC address of the multicast source.

[0530] S1105. The multicast source sends a first multicast message encrypted with the first multicast key via WiFi communication technology. The source address in the first MAC header of the first multicast message is the MAC address of the multicast source, and the destination address in the first MAC header is the multicast address.

[0531] For example, the first multicast message includes the aforementioned multicast message 1.

[0532] S1106. Based on the multicast address, the first client listens to the first multicast message.

[0533] S1107. The first client determines that the key corresponding to the source address in the first MAC header is the first multicast key, and uses the first multicast key to parse the data unit (e.g., MSDU) of the first multicast message.

[0534] In some embodiments, before the multicast source sends the first Bluetooth message to the first client, the method further includes: the multicast source activating the first VAP; the multicast source sending the first multicast message encrypted with the first multicast key via WiFi communication technology, including: the first VAP of the multicast source sending the first multicast message encrypted with the first multicast key via WiFi communication technology.

[0535] In some embodiments, before the multicast source sends the first Bluetooth message to the first client, the method further includes: the multicast source generating a virtual multicast source address; the multicast source configuring the source address corresponding to the first multicast key as the virtual multicast source address; the first Bluetooth message also includes a virtual anchor source address, and the source address in the MAC header of the multicast message sent by the client in the multicast group is the virtual multicast source address.

[0536] In some embodiments, the method further includes: a first client sending a second multicast message encrypted with a first multicast key via WiFi communication technology, wherein the source address in the second MAC header of the second multicast message is a virtual multicast source address and the destination address in the second MAC header is a multicast address; based on the multicast address, the multicast source listens to the second multicast message; the multicast source determines that the key corresponding to the source address in the second MAC header is the first multicast key, and uses the first multicast key to parse the data unit of the second multicast message.

[0537] For example, the second multicast message includes the aforementioned multicast message 2.

[0538] In some embodiments, after the multicast source sends the first Bluetooth message to the first client, the method further includes: the first client activating the second VAP based on the first Bluetooth message; the first client sending the second multicast message encrypted with the first multicast key via WiFi communication technology includes: the second VAP of the first client sending the second multicast message encrypted with the first multicast key via WiFi communication technology.

[0539] In some embodiments, the multicast message type includes signaling frames and data frames, and the multicast type of the signaling frame includes control signaling frames and signaling acknowledgment frames; the first multicast message includes a first control signaling frame, and the second multicast message includes a first signaling acknowledgment frame. The first signaling acknowledgment frame is generated by the first client based on the first control signaling frame, and the first signaling acknowledgment frame is used to indicate the reception status of the control signaling frame sent by the multicast source.

[0540] For example, the first control signaling frame includes the aforementioned control signaling frame 1, and the first signaling confirmation frame includes the aforementioned signaling confirmation frame 1.

[0541] In some embodiments, the multicast message type includes signaling frames and data frames, and the multicast type of the signaling frame includes control signaling frames and signaling acknowledgment frames; the second multicast message includes a first control signaling frame, and the first multicast message includes a first signaling acknowledgment frame. The first signaling acknowledgment frame is generated by the multicast source based on the first control signaling frame, and the first signaling acknowledgment frame is used to indicate the reception status of the control signaling frame sent by the first client.

[0542] For example, the first control signaling frame includes the aforementioned control signaling frame 3, and the first signaling confirmation frame includes the aforementioned signaling confirmation frame 2.

[0543] In some embodiments, the data unit in a signaling frame includes the actual destination address corresponding to the receiver of the signaling frame and the actual source address corresponding to the sender of the signaling frame; the data unit of a control signaling frame further includes a control identifier and a data payload, wherein the data payload is used to transmit valid control signaling and the control identifier is used to indicate the number of the control signaling frame; the data unit of a signaling acknowledgment frame further includes acknowledgment information, wherein the acknowledgment information is used to indicate the reception status of the control signaling frames sent by the receiver of the signaling acknowledgment frame.

[0544] For example, refer to Figure 9A and Figure 9B The MSDU of a signaling frame carries the actual destination address and the actual source address. The MSDU of a control signaling frame also includes a control identifier and a data payload. The MSDU of a signaling acknowledgment frame also includes acknowledgment information.

[0545] In some embodiments, the first client sets up a receive window for the multicast source to maintain reception information of control signaling frames from the multicast source; the multicast source sets up a send window for the first client to maintain transmission information of control signaling frames sent to the first client; the method further includes: the first client updating the receive window corresponding to the multicast source based on the first control signaling frame, and determining a first signaling acknowledgment frame based on the updated receive window; the first signaling acknowledgment frame indicating that the second control signaling frame maintained by the send window has not been received; the multicast source updating the send window corresponding to the first client based on the first signaling acknowledgment frame, and determining whether to retransmit the second control signaling frame. For example, the second control signaling frame includes the aforementioned control signaling frame 2.

[0546] In some embodiments, the signaling frame further includes a multicast type; when the multicast type of the signaling frame is a control signaling frame, the signaling frame further includes a subtype of the control signaling frame, the subtype of the control signaling frame includes a first subtype and a second subtype, and the processing modules corresponding to the first subtype and the second subtype are different; the above method further includes: the first client submits the first control signaling frame to the processing module corresponding to the first subtype for processing according to the first subtype in the first control signaling frame.

[0547] For example, refer to Figure 9A The MSDU of the signaling frame carries the multicast type and subtype. Table 1 shows several subtypes of control signaling frames provided in the embodiments of this application.

[0548] In some embodiments, the receiving window includes M small windows, where M is a positive integer; each small window in the receiving window sequentially maintains the reception information of control signaling frames according to the control identifiers of the control signaling frames received from the multicast source; the reception information maintained by one small window in the receiving window includes the control identifier and the reception identifier of the control signaling frame; the reception identifier is used to indicate whether the control signaling frame has been received; the first upper edge UE of the receiving window refers to the maximum value of the control identifiers of the received control signaling frames maintained by the receiving window, and the first lower edge LE of the receiving window refers to the minimum value of the control identifiers of the unreceived control signaling frames maintained by the receiving window; the sending window includes M small windows; each small window in the sending window sequentially maintains the transmission information of control signaling frames according to the control identifiers of the control signaling frames sent to the first client; the transmission information maintained by one small window includes the control identifiers of the control signaling frames; the second UE of the sending window refers to the maximum value of the control identifiers of the unreceived control signaling frames maintained by the sending window, and the second LE of the sending window refers to the minimum value of the control identifiers of the unreceived control signaling frames maintained by the sending window.

[0549] For example, Figure 10A , Figure 10B and Figure 10E Table 2 shows several receiving windows provided in the embodiments of this application; Table 2 shows the receiving information of the control signaling frames maintained by the small window in the receiving window provided in the embodiments of this application; the first upper edge of the receiving window includes the aforementioned R-UE, and the first lower edge of the receiving window includes the aforementioned R-LE. Figure 11A Table 3 shows a receiving window provided by an embodiment of this application; Table 3 shows the transmission information of control signaling frames maintained in the small window of the sending window provided by the embodiment of this application; the second UE of the sending window includes the aforementioned T-UE, and the second LE of the sending window includes the aforementioned T-LE.

[0550] In some embodiments, the confirmation information in the first signaling confirmation frame includes a first UE and a first LE in the receiving window, and a bitmap, the bitmap sequentially indicating the reception status of control signaling frames maintained by the small window pointed to by the first LE to the small window pointed to by the first UE in the receiving window. For example, refer to... Figure 9B The confirmation information in the signaling confirmation frame carries LE, UE, and Bitmap.

[0551] In some embodiments, the first client updates the receiving window corresponding to the multicast source based on the first control signaling frame, including: determining, based on the actual destination address in the first control signaling frame, that it is a multicast frame sent to the device, and when determining, based on the actual source address in the first control signaling frame, that the sender of the first control signaling frame belongs to a multicast group, obtaining the receiving window corresponding to the multicast source based on the actual source address in the first control signaling frame, and updating the receiving window corresponding to the multicast source based on the first control signaling frame.

[0552] In some embodiments, the first client updates the receiving window corresponding to the multicast source based on the first control signaling frame, including: determining a first index for maintaining the small window of the first control signaling frame according to the control identifier of the first control signaling frame, wherein the first index is equal to the remainder after dividing the control identifier of the first control signaling frame by M; when the receiving window is determined to be full according to the first LE and the first UE, clearing the small window pointed to by the first LE up to the small window corresponding to the first index; when the receiving window is determined not to be full, if the receiving identifier of the small window corresponding to the first index is a first value, discarding the first control signaling frame; if the receiving identifier of the small window corresponding to the first index is a second value, updating the receiving identifier of the small window corresponding to the first index to the first value; a receiving identifier of the first value indicates that the control signaling frame has been received; a receiving identifier of the second value indicates that the control signaling frame has not been received; when the control identifier of the first control signaling frame is greater than the first UE, updating the value of the first UE to the control identifier of the first control signaling frame; determining the first small window pointed to by the first LE and the first small window in the subsequent small windows with a receiving identifier of the second value, and updating the value of the first LE to the control identifier of the first small window.

[0553] For example, the first index includes the aforementioned Index1. The first value is equal to 1, and the second value is equal to 0; or, the first value is equal to 0, and the second value is equal to 1.

[0554] In some embodiments, the multicast source updates the sending window corresponding to the first client based on the first signaling confirmation frame, including: determining, based on the actual destination address in the first signaling confirmation frame, that it is a multicast frame to be sent to this device, and determining, based on the actual source address in the first signaling confirmation frame, whether the sender of the first control signaling frame belongs to the multicast group, obtaining the sending window corresponding to the first client based on the actual source address in the first signaling confirmation frame, and updating the sending window corresponding to the first client based on the first signaling confirmation frame.

[0555] In some embodiments, the multicast source updates the sending window corresponding to the first client based on the first signaling confirmation frame, including: when it is determined that the first LE is greater than or equal to the second LE of the sending window and the first UE is less than or equal to the second UE based on the confirmation information in the first signaling confirmation frame, the multicast source updates the sending window corresponding to the first client based on the first signaling confirmation frame.

[0556] In some embodiments, the transmission information maintained by a small window in the transmission window further includes a transmission status and a storage address. The transmission status is used to indicate whether a control signaling frame has been received, and the storage address is used to indicate the cache address of the control signaling frame. The multicast source updates the transmission window corresponding to the first client based on the first signaling acknowledgment frame, including: when the first LE is greater than the second LE, clearing the small window pointed to by the second LE in the transmission window up to the small window before the small window pointed to by the first LE, and updating the value of the second LE to the value of the first LE; when the first LE is equal to the second LE, traversing the small window pointed to by the first LE in the transmission window up to the small window pointed to by the first UE, the second small window indicated by the bitmap where the control signaling frame has been received, and releasing the control signaling frame cached at the storage address of the second small window.

[0557] In some embodiments, the transmission information maintained by a small window of the transmission window further includes a retransmission flag and a retransmission count. The retransmission flag indicates whether the control signaling frame has been retransmitted within the current retransmission period, and the retransmission count indicates the number of times the control signaling frame has been retransmitted. The determination of whether to retransmit the second control signaling frame includes: when the first LE equals the second LE, traversing the small windows pointed to by the first LE in the transmission window to the small windows pointed to by the first UE, and the third small window where the control signaling frame indicated by the bitmap has not been received. When the second control signaling frame maintained by the third small window satisfies the retransmission condition, it is determined to retransmit the second control signaling frame to the first client, and the retransmission flag corresponding to the third small window is updated to the first value, and the retransmission count is incremented by 1. The retransmission flag being the first value indicates that the control signaling frame has been retransmitted within the current retransmission period.

[0558] In some embodiments, the retransmission conditions include: the retransmission flag of the third small window is a second value, and the number of retransmissions is less than a first preset value; the retransmission flag being a second value indicates that the control signaling frame has not been retransmitted in the current retransmission period. For example, the first preset value includes the aforementioned MAX_RETRAN_CNT, such as a first preset value equal to 5.

[0559] In some embodiments, the method further includes: the first client performing periodic timeout processing on the receiving window corresponding to the multicast source it maintains.

[0560] In some embodiments, the reception information maintained by a small window of the receiving window also includes a polling count. The first client performs periodic timeout processing on the receiving window corresponding to the multicast source it maintains, including: determining the fourth small window with a second value among the small windows from the first LE to the small windows from the first UE in the receiving window, and incrementing the polling count of the fourth small window by 1; when the polling count of the fourth small window is greater than a second preset value, clearing the small windows from the first LE to the fourth small window; determining the first fifth small window with a second value after the fourth small window in the receiving window; and updating the first LE of the receiving window to the control identifier of the fifth small window.

[0561] For example, the second preset value includes the aforementioned preset value 1.

[0562] In some embodiments, the method further includes: the multicast source periodically times out the sending window corresponding to the first client it maintains.

[0563] In some embodiments, the multicast source performs periodic timeout processing on the transmission window corresponding to the first client it maintains, including: traversing the small window pointed to by the second LE in the transmission window to the small window pointed to by the second UE, and the sixth small window with a transmission status of the second value; the transmission status is set to the second value, indicating that the control signaling frame has not been received; incrementing the polling count corresponding to the sixth small window by 1; when the polling count of the sixth small window is greater than or equal to a third preset value, determining whether the sixth small window meets the retransmission condition; when the retransmission condition is met, determining to retransmit the control signaling frame maintained by the sixth small window, setting the polling count of the sixth small window to 0, setting the retransmission flag to the first value, and incrementing the retransmission count by 1; when the retransmission condition is not met and the retransmission count exceeds a fifth preset value, clearing the sixth small window and releasing the control signaling frame cached in the storage address buffer of the sixth small window; determining that the second LE is equal to the control flag of the small window with a transmission status of the second value and the smallest control flag in the transmission window.

[0564] For example, the third preset value includes the aforementioned preset value 2.

[0565] In some embodiments, the method further includes: a first client establishing a Bluetooth connection with a multicast source and sending a fourth Bluetooth message to the multicast source, the fourth Bluetooth message being used to request to leave the multicast group; the multicast source sending a fifth Bluetooth message to the first client and deleting the multicast user information of the first client, the fifth Bluetooth message being used to indicate confirmation that the first client has left the multicast group; the first client listening to the fifth Bluetooth message via Bluetooth and deleting the second multicast group information on the client side based on the fifth Bluetooth message; the second multicast group information including a multicast address and a first multicast key; and the first client and the multicast source disconnecting the Bluetooth connection.

[0566] For example, the fourth Bluetooth message includes the aforementioned disconnect request message, the fifth Bluetooth message includes the aforementioned disconnect confirmation message, and the second multicast group information includes the aforementioned multicast group information on the client 200 side.

[0567] In some embodiments, the first client establishes a Bluetooth connection with the multicast source and sends a fourth Bluetooth message to the multicast source, including: the first client receiving a fourth operation; in response to the fourth operation, the first client establishes a Bluetooth connection with the multicast source and sends a fourth Bluetooth message to the multicast source; the method further includes: in response to the fourth operation, the first client closes the multicast application.

[0568] For example, the fourth operation includes the aforementioned operation 5. (See reference...) Figures 5A to 5B According to the relevant description, in the screen casting scenario, operation 5 can be used to exit the screen casting multicast group. For example, operation 5 includes the click operation that acts on the exit control 401.

[0569] In some embodiments, the multicast source Bluetooth broadcasts a sixth Bluetooth message and deletes the first multicast group information on the multicast source side; the sixth Bluetooth message is used to indicate the deletion of the multicast group, and the first multicast group information includes a multicast device list, a first multicast key, and a multicast address; the first client Bluetooth listens to the sixth Bluetooth message and deletes the second multicast group information on the client side based on the sixth Bluetooth message; the second multicast group information includes a multicast address and a first multicast key.

[0570] For example, the sixth Bluetooth message includes the aforementioned multicast deletion message, and the first multicast group information includes the multicast group information on the multicast source 100 side.

[0571] In some embodiments, the multicast source Bluetooth broadcasting of the sixth Bluetooth message includes: the multicast source receiving a fifth operation; in response to the fifth operation, the multicast source Bluetooth broadcasting the sixth Bluetooth message; the method further includes: in response to the fifth operation, closing the multicast application.

[0572] For example, the fifth operation includes the aforementioned operation 6. (See reference...) Figures 5A to 5B According to the relevant description, in the screen casting scenario, operation 6 can be used to delete the screen casting multicast group. For example, operation 6 includes a click operation on the end control 402.

[0573] The following is an example of the hardware structure for receiving multicast source 100 and the client.

[0574] The following describes the structure of a multicast source 100 provided in an embodiment of this application. The structure of the client involved in this embodiment can be referred to the relevant description of the multicast source 100, and will not be repeated hereafter.

[0575] Figure 13A schematic diagram of the structure of multicast source 100 is shown. Multicast source 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, antenna 1, antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0576] It is understood that the structure illustrated in the embodiments of the present invention does not constitute a specific limitation on the multicast source 100. In other embodiments of this application, the multicast source 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0577] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0578] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0579] The processor 110 may also include a memory for storing instructions and data.

[0580] In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that processor 110 has just used or that are used repeatedly. If processor 110 needs to use the instruction or data again, it can directly retrieve it from the memory. This avoids repeated accesses, reduces the waiting time of processor 110, and thus improves system efficiency.

[0581] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0582] The I2C interface is a bidirectional synchronous serial bus, including a serial data line (SDA) and a serial clock line (SCL). In some embodiments, the processor 110 may include multiple I2C buses. The processor 110 can couple to the touch sensor 180K, charger, flash, camera 193, etc., through different I2C bus interfaces. For example, the processor 110 can couple to the touch sensor 180K through the I2C interface, enabling the processor 110 and the touch sensor 180K to communicate through the I2C bus interface, thereby realizing the touch function of the multicast source 100.

[0583] The I2S interface can be used for audio communication. In some embodiments, the processor 110 may include multiple I2S buses. The processor 110 can be coupled to the audio module 170 via the I2S bus to enable communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the I2S interface to enable the function of answering phone calls through a Bluetooth headset.

[0584] The PCM interface can also be used for audio communication, sampling, quantizing, and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 can be coupled via the PCM bus interface. In some embodiments, the audio module 170 can also transmit audio signals to the wireless communication module 160 via the PCM interface, enabling the function of answering phone calls through a Bluetooth headset. Both the I2S interface and the PCM interface can be used for audio communication.

[0585] The UART interface is a universal serial data bus used for asynchronous communication. This bus can be a bidirectional communication bus. It converts the data to be transmitted between serial and parallel communication. In some embodiments, the UART interface is typically used to connect the processor 110 and the wireless communication module 160. For example, the processor 110 communicates with the Bluetooth module in the wireless communication module 160 via the UART interface to implement Bluetooth functionality. In some embodiments, the audio module 170 can transmit audio signals to the wireless communication module 160 via the UART interface to enable music playback through Bluetooth headphones.

[0586] The MIPI interface can be used to connect the processor 110 to peripheral devices such as the display screen 194 and the camera 193. The MIPI interface includes a camera serial interface (CSI) and a display serial interface (DSI). In some embodiments, the processor 110 and the camera 193 communicate via the CSI interface to implement the shooting function of the multicast source 100. The processor 110 and the display screen 194 communicate via the DSI interface to implement the display function of the multicast source 100.

[0587] The GPIO interface can be configured via software. It can be configured as a control signal or a data signal. In some embodiments, the GPIO interface can be used to connect the processor 110 to a camera 193, a display screen 194, a wireless communication module 160, an audio module 170, a sensor module 180, etc. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, etc.

[0588] USB port 130 is a USB standard compliant interface, specifically a Mini USB port, Micro USB port, or USB Type-C port. USB port 130 can be used to connect a charger to charge multicast source 100, and can also be used for data transfer between multicast source 100 and peripheral devices. It can also be used to connect headphones for audio playback. This interface can also be used to connect other electronic devices, such as AR devices.

[0589] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a structural limitation on the multicast source 100. In other embodiments of this application, the multicast source 100 may also adopt different interface connection methods or a combination of multiple interface connection methods as described in the above embodiments.

[0590] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 receives wireless charging input via the wireless charging coil of the multicast source 100. While charging the battery 142, the charging management module 140 can also supply power to the electronic device via the power management module 141.

[0591] The power management module 141 connects the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, providing power to the processor 110, internal memory 121, display screen 194, camera 193, and wireless communication module 160, etc. The power management module 141 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module 141 may also be located within the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may be located in the same device.

[0592] The wireless communication function of the multicast source 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor.

[0593] Antennas 1 and 2 are used to transmit and receive electromagnetic wave signals. Each antenna in multicast source 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0594] The mobile communication module 150 can provide solutions for wireless communication applications including 2G / 3G / 4G / 5G on the multicast source 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0595] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through an audio device (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through the display screen 194. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.

[0596] The wireless communication module 160 can provide solutions for wireless communication applications on the multicast source 100, including wireless local area networks (WLAN) (such as WiFi), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR). The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, demodulates and filters the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, frequency modulate and amplify them, and then convert them into electromagnetic waves for radiation via antenna 2.

[0597] In some embodiments, antenna 1 of multicast source 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling multicast source 100 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

[0598] Multicast source 100 implements display functions through a GPU, display screen 194, and application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0599] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a miniature LED, a microLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, multicast source 100 may include one or N displays 194, where N is a positive integer greater than 1.

[0600] Multicast source 100 can achieve shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0601] The ISP (Image Signal Processor) is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, converting it into an image visible to the naked eye. The ISP can also perform algorithmic optimization on image noise and brightness. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In some embodiments, the ISP can be set in the camera 193.

[0602] Camera 193 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In some embodiments, multicast source 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0603] A digital signal processor (DSP) is used to process digital signals. Besides digital image signals, it can also process other digital signals. For example, when multicast source 100 selects a frequency, the DSP can perform Fourier transforms on the frequency energy.

[0604] Video codecs are used to compress or decompress digital video. Multicast source 100 may support one or more video codecs. Thus, multicast source 100 can play or record video in various encoding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG 2, MPEG 3, MPEG 4, etc.

[0605] An NPU (Neural Processing Unit) is a computational processor for neural networks (NNs). By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs can be used to implement applications such as intelligent cognition of multicast sources, including image recognition, facial recognition, speech recognition, and text understanding.

[0606] Internal memory 121 may include one or more random access memory (RAM) and one or more non-volatile memory (NVM).

[0607] Random access memory can include static random-access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), and double data rate synchronous dynamic random access memory (DDR SDRAM, such as fifth-generation DDR SDRAM, which is generally called DDR5 SDRAM). Non-volatile memory can include disk storage devices and flash memory.

[0608] Flash memory can be classified according to its operating principle, including NOR FLASH, NAND FLASH, 3D NAND FLASH, etc.; according to the level of the storage cell, including single-level cell (SLC), multi-level cell (MLC), triple-level cell (TLC), quad-level cell (QLC), etc.; and according to the storage specification, including universal flash storage (UFS) and embedded multimedia card (eMMC), etc.

[0609] The random access memory can be directly read and written by the processor 110. It can be used to store executable programs (such as machine instructions) of the operating system or other running programs, as well as user and application data.

[0610] Non-volatile memory can also store executable programs and user and application data, and can be pre-loaded into random access memory for direct reading and writing by the processor 110.

[0611] The external memory interface 120 can be used to connect to external non-volatile memory to expand the storage capacity of the multicast source 100. The external non-volatile memory communicates with the processor 110 through the external memory interface 120 to perform data storage functions. For example, music, video, and other files can be stored in the external non-volatile memory.

[0612] Multicast source 100 can implement audio functions such as music playback and recording through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0613] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0614] The loudspeaker 170A, also known as a "loudspeaker", is used to convert audio electrical signals into sound signals.

[0615] The receiver 170B, also known as the "earpiece", is used to convert audio electrical signals into sound signals.

[0616] The microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals.

[0617] The 170D headphone jack is used to connect wired headphones.

[0618] The pressure sensor 180A is used to sense pressure signals and can convert the pressure signals into electrical signals. In some embodiments, the pressure sensor 180A can be disposed on the display screen 194. There are many types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, capacitive pressure sensors, etc.

[0619] The gyroscope sensor 180B can be used to determine the motion attitude of the multicast source 100. In some embodiments, the angular velocity of the multicast source 100 about three axes (i.e., the x, y, and z axes) can be determined by the gyroscope sensor 180B.

[0620] The 180C barometric pressure sensor is used to measure barometric pressure.

[0621] The magnetic sensor 180D includes a Hall sensor.

[0622] The accelerometer 180E can detect the magnitude of the acceleration of the multicast source 100 in various directions (typically three axes). When the multicast source 100 is stationary, it can detect the magnitude and direction of gravity. It can also be used to identify the attitude of terminal devices.

[0623] Distance sensor 180F is used to measure distance. Multicast source 100 can measure distance via infrared or laser.

[0624] The proximity light sensor 180G may include, for example, a light-emitting diode (LED) and a light detector, such as a photodiode. The LED may be an infrared LED.

[0625] An ambient light sensor 180L is used to detect ambient light intensity. The multicast source 100 can adaptively adjust the brightness of the display screen 194 based on the detected ambient light intensity.

[0626] The fingerprint sensor 180H is used to collect fingerprints.

[0627] Temperature sensor 180J is used to detect temperature. In some embodiments, multicast source 100 uses the temperature detected by temperature sensor 180J to execute a temperature processing strategy.

[0628] Touch sensor 180K, also known as a "touch device," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touchscreen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of multicast source 100, in a different position than display screen 194.

[0629] The bone conduction sensor 180M can acquire vibration signals.

[0630] Buttons 190 include a power button, volume buttons, etc. Buttons 190 can be mechanical buttons or touch-sensitive buttons. Multicast source 100 can receive button input and generate key signal inputs related to user settings and function control of multicast source 100.

[0631] Motor 191 can generate vibration alerts. Motor 191 can be used for incoming call vibration alerts or for touch vibration feedback.

[0632] Indicator 192 can be an indicator light, used to indicate charging status, power changes, or to indicate messages, missed calls, notifications, etc.

[0633] The SIM card interface 195 is used to connect the SIM card.

[0634] The various embodiments of this application can be combined arbitrarily to achieve different technical effects.

[0635] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0636] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0637] In summary, the above description is merely an embodiment of the technical solution of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made according to the disclosure of the present invention should be included within the scope of protection of the present invention.

Claims

1. A multicast communication method, characterized in that, The method is applied to a multicast communication system, the multicast communication system including a multicast source and at least one client, the at least one client including a first client; the method includes: The multicast source determines the multicast address and the first multicast key of the multicast group; The multicast source sends a first Bluetooth message to the first client. The first Bluetooth message is used to invite the first client to join the multicast group. The first Bluetooth message includes the multicast address and the first multicast key. The first client sends a second Bluetooth message to the multicast source based on the first Bluetooth message; the second Bluetooth message is used to instruct the first client to confirm joining the multicast group. The first client configures the source address corresponding to the first multicast key as the media access control MAC address of the multicast source; The multicast source sends a first multicast message encrypted with the first multicast key via WiFi communication technology. The source address in the first MAC header of the first multicast message is the MAC address of the multicast source, and the destination address in the first MAC header is the multicast address. Based on the multicast address, the first client listens to the first multicast message; The first client determines that the key corresponding to the source address in the first MAC header is the first multicast key, and uses the first multicast key to parse the data unit of the first multicast message.

2. The method according to claim 1, characterized in that, Before the multicast source sends the first Bluetooth message to the first client, the method further includes: The multicast source enables the first virtual access point (VAP); The multicast source transmits a first multicast message encrypted with the first multicast key via WiFi communication technology, including: The first VAP of the multicast source sends a first multicast message encrypted with the first multicast key via WiFi communication technology.

3. The method according to claim 1, characterized in that, The method further includes: The multicast source receives a first operation, the first operation being used to create the multicast group; The multicast source determines the multicast address and the first multicast key of the multicast group, including: In response to the first operation, the multicast source determines the multicast address of the multicast group and the first multicast key.

4. The method according to claim 1, characterized in that, Before the multicast source sends the first Bluetooth message to the first client, the method further includes: The multicast source Bluetooth scans nearby Bluetooth devices that support multicast communication; The multicast source displays at least one scanned Bluetooth device, and the at least one Bluetooth device includes the first client; The multicast source receives a second operation, which is used to invite the first client to join the multicast group. In response to the second operation, the multicast source establishes a Bluetooth connection with the first client.

5. The method according to claim 4, characterized in that, Before the multicast source displays at least one scanned Bluetooth device, the method further includes: The first client receives the third operation; In response to the third operation, the first client broadcasts a first discovery signal via Bluetooth, the first discovery signal indicating that the first client supports multicast communication; The multicast source is scanned to the first client based on the first discovery signal.

6. The method according to claim 3, characterized in that, Before the multicast source sends the first Bluetooth message to the first client, the method further includes: In response to the first operation, the multicast source broadcasts a second discovery signal via Bluetooth; Based on the second discovery signal detected via Bluetooth, the first client establishes a Bluetooth connection with the multicast source; The first client sends a third Bluetooth message to the multicast source, the third Bluetooth message being used to request to join the multicast group; The multicast source sends a first Bluetooth message to the first client, including: In response to the third Bluetooth message, the multicast source sends the first Bluetooth message to the first client.

7. The method according to claim 1, characterized in that, After the first client sends the second Bluetooth message to the multicast source, the process further includes: Disconnect the multicast source from the first client's Bluetooth connection.

8. The method according to claim 2, characterized in that, Before the multicast source sends the first Bluetooth message to the first client, it also includes: The multicast source assigns a first IP address to the first VAP of the multicast source and assigns a second IP address to the second VAP of the client; The first Bluetooth message also includes the first IP address and the second IP address; the first IP address and the second IP address are used to encapsulate multicast messages, the source IP address in the multicast message sent by the multicast source is the first IP address, and the source IP address in the multicast message sent by the first client is the second IP address.

9. The method according to claim 8, characterized in that, The method further includes: Based on the second Bluetooth message, the multicast source adds the multicast user information of the first client to the multicast device list; the multicast device list is used to store the multicast user information of each client in the multicast group, and the multicast user information of the first client includes the MAC address of the first client and the second IP address.

10. The method according to claim 1, characterized in that, Before the multicast source sends the first Bluetooth message to the first client, it also includes: The multicast source generates a virtual multicast source address; The multicast source is configured such that the source address corresponding to the first multicast key is the virtual multicast source address; The first Bluetooth message also includes the virtual multicast source address, wherein the source address in the MAC header of the multicast message sent by the client in the multicast group is the virtual multicast source address.

11. The method according to claim 10, characterized in that, The method further includes: The first client sends a second multicast message encrypted with the first multicast key via WiFi communication technology. The source address in the second MAC header of the second multicast message is the virtual multicast source address, and the destination address in the second MAC header is the multicast address. Based on the multicast address, the multicast source listens to the second multicast message; The multicast source determines that the key corresponding to the source address in the second MAC header is the first multicast key, and uses the first multicast key to parse the data unit of the second multicast message.

12. The method according to claim 11, characterized in that, After the multicast source sends the first Bluetooth message to the first client, it also includes: The first client starts the second VAP based on the first Bluetooth message; The first client transmits a second multicast message encrypted with the first multicast key via WiFi communication technology, including: The second VAP of the first client sends a second multicast message encrypted with the first multicast key via WiFi communication technology.

13. The method according to claim 1, characterized in that, The data unit of a multicast message is the MAC Service Data Unit (MSDU).

14. The method according to claim 11, characterized in that, Multicast message types include signaling frames and data frames. The multicast types of signaling frames include control signaling frames and signaling acknowledgment frames. The first multicast message includes a first control signaling frame, and the second multicast message includes a first signaling acknowledgment frame. The first signaling acknowledgment frame is generated by the first client based on the first control signaling frame, and the first signaling acknowledgment frame is used to indicate the reception status of the control signaling frame sent by the multicast source.

15. The method according to claim 11, characterized in that, Multicast message types include signaling frames and data frames. The multicast types of signaling frames include control signaling frames and signaling acknowledgment frames. The second multicast message includes a first control signaling frame, and the first multicast message includes a first signaling acknowledgment frame. The first signaling acknowledgment frame is generated by the multicast source based on the first control signaling frame. The first signaling acknowledgment frame is used to indicate the reception status of the control signaling frame sent by the first client.

16. The method according to claim 14 or 15, characterized in that, The data unit in the signaling frame includes the actual destination address corresponding to the receiving end of the signaling frame and the actual source address corresponding to the sending end of the signaling frame. The data unit of the control signaling frame further includes a control identifier and a data payload. The data payload is used to transmit valid control signaling, and the control identifier is used to indicate the number of the control signaling frame. The data unit of the signaling confirmation frame further includes confirmation information, which is used to indicate the reception status of the control signaling frames sent by the receiving end of the signaling confirmation frame.

17. The method according to claim 16, characterized in that, The first client sets up a receive window for the multicast source to maintain the received information of control signaling frames from the multicast source; the multicast source sets up a send window for the first client to maintain the send information of control signaling frames sent to the first client; the method further includes; The first client updates the receiving window corresponding to the multicast source based on the first control signaling frame, and determines the first signaling confirmation frame based on the updated receiving window; The first signaling acknowledgment frame indicates that the second control signaling frame maintained by the sending window has not been received; The multicast source updates the sending window corresponding to the first client based on the first signaling confirmation frame to determine whether to retransmit the second control signaling frame.

18. The method according to claim 16, characterized in that, The signaling frame further includes a multicast type; when the multicast type of the signaling frame is a control signaling frame, the signaling frame further includes a subtype of control signaling frame, the subtype of control signaling frame including a first subtype and a second subtype, the processing modules corresponding to the first subtype and the second subtype are different; the method further includes: The first client submits the first control signaling frame to the processing module corresponding to the first subtype for processing, based on the first subtype in the first control signaling frame.

19. The method according to claim 17, characterized in that, The receiving window includes M small windows, where M is a positive integer; each small window in the receiving window maintains the receiving information of the control signaling frames in sequence according to the control identifier of the received control signaling frames of the multicast source; the receiving information maintained by one small window in the receiving window includes the control identifier and the receiving identifier of the control signaling frames. The receiving identifier is used to indicate whether a control signaling frame has been received; the first UE of the receiving window refers to the maximum value of the control identifier of the received control signaling frames maintained by the receiving window, and the first LE of the receiving window refers to the minimum value of the control identifier of the unreceived control signaling frames maintained by the receiving window. The sending window consists of M smaller windows; each smaller window in the sending window sequentially maintains the sending information of control signaling frames according to the control identifier of the control signaling frames sent to the first client; the sending information maintained by each smaller window includes the control identifier of the control signaling frames; the second UE of the sending window refers to the maximum value of the control identifier of the unreceived control signaling frames maintained by the sending window, and the second LE of the sending window refers to the minimum value of the control identifier of the unreceived control signaling frames maintained by the sending window.

20. The method according to claim 19, characterized in that, The confirmation information in the first signaling confirmation frame includes the first UE and the first LE of the receiving window, as well as a bitmap, which sequentially indicates the reception status of control signaling frames maintained by the small window pointed to by the first LE to the small window pointed to by the first UE in the receiving window.

21. The method according to claim 16, characterized in that, The first client updates the receive window corresponding to the multicast source based on the first control signaling frame, including: Based on the actual destination address in the first control signaling frame, it is determined that the frame is a multicast frame sent to this device. Based on the actual source address in the first control signaling frame, it is determined that the sender of the first control signaling frame belongs to the multicast group. The receiving window corresponding to the multicast source is obtained based on the actual source address in the first control signaling frame, and the first client updates the receiving window corresponding to the multicast source based on the first control signaling frame.

22. The method according to claim 19, characterized in that, The first client updates the receive window corresponding to the multicast source based on the first control signaling frame, including: Based on the control identifier of the first control signaling frame, a first index for maintaining the small window of the first control signaling frame is determined, and the first index is equal to the remainder after dividing the control identifier of the first control signaling frame by M. When the receiving window is determined to be full based on the first LE and the first UE, the small window pointed to by the first LE up to the small window corresponding to the first index is cleared; when the receiving window is determined not to be full, if the receiving identifier of the small window corresponding to the first index is a first value, the first control signaling frame is discarded; if the receiving identifier of the small window corresponding to the first index is a second value, the receiving identifier of the small window corresponding to the first index is updated to the first value; the receiving identifier being a first value indicates that the control signaling frame has been received; the receiving identifier being a second value indicates that the control signaling frame has not been received. When the control identifier of the first control signaling frame is greater than that of the first UE, the value of the first UE is updated to the control identifier of the first control signaling frame. The first small window pointed to by the first LE and the first small window in the subsequent small windows that receives the second value are determined, and the value of the first LE is updated to the control identifier of the first small window.

23. The method according to claim 16, characterized in that, The multicast source updates the sending window corresponding to the first client based on the first signaling acknowledgment frame, including: Based on the actual destination address in the first signaling confirmation frame, it is determined that the frame is a multicast frame sent to this device. Based on the actual source address in the first signaling confirmation frame, it is determined whether the sender of the first control signaling frame belongs to the multicast group. Then, the sending window corresponding to the first client is obtained based on the actual source address in the first signaling confirmation frame, and the multicast source updates the sending window corresponding to the first client based on the first signaling confirmation frame.

24. The method according to claim 20, characterized in that, The multicast source updates the sending window corresponding to the first client based on the first signaling acknowledgment frame, including: Based on the confirmation information in the first signaling confirmation frame, when it is determined that the first LE is greater than or equal to the second LE of the sending window, and the first UE is less than or equal to the second UE, the multicast source updates the sending window corresponding to the first client based on the first signaling confirmation frame.

25. The method according to claim 24, characterized in that, The transmission information maintained in a small window within the transmission window also includes transmission status and storage address. The transmission status is used to indicate whether the control signaling frame has been received, and the storage address is used to indicate the buffer address of the control signaling frame. The multicast source updates the sending window corresponding to the first client based on the first signaling acknowledgment frame, including: When the first LE is greater than the second LE, clear the small window pointed to by the second LE in the sending window to the small window before the small window pointed to by the first LE, and update the value of the second LE to the value of the first LE; When the first LE is equal to the second LE, the small window pointed to by the first LE in the transmission window is traversed to the small window pointed to by the first UE. The second small window where the control signaling frame indicated by the bitmap has been received is released, and the control signaling frame in the storage address buffer of the second small window is released.

26. The method according to claim 25, characterized in that, The transmission information maintained in a small window of the transmission window also includes a retransmission flag and a retransmission count. The retransmission flag is used to indicate whether the transmission has been retransmitted in the current retransmission period, and the retransmission count is used to indicate the number of times the control signaling frame has been retransmitted. The step of determining whether to retransmit the second control signaling frame includes: When the first LE equals the second LE, the process iterates through the small windows pointed to by the first LE in the transmission window up to the small window pointed to by the first UE, and then through the third small window indicated by the bitmap where the control signaling frame has not been received. When the second control signaling frame maintained by the third small window meets the retransmission condition, it is determined to retransmit the second control signaling frame to the first client, the retransmission flag corresponding to the third small window is updated to the first value, and the retransmission count is incremented by 1; the retransmission flag taking the first value indicates that the control signaling frame has been retransmitted in this retransmission period.

27. The method according to claim 26, characterized in that, The retransmission conditions include: The retransmission flag of the third small window is a second value, and the number of retransmissions is less than a first preset value; the retransmission flag being a second value indicates that the control signaling frame has not been retransmitted in this retransmission period.

28. The method according to claim 19, characterized in that, The method further includes: The first client performs periodic timeout processing on the receiving window corresponding to the multicast source it maintains.

29. The method according to claim 28, characterized in that, The reception information maintained in a small window of the receiving window also includes the polling count. The first client performs periodic timeout processing on the receiving window corresponding to the multicast source it maintains, including: The small window pointed to by the first LE in the receiving window is determined to be the small window pointed to by the first UE, and the fourth small window with the receiving identifier set to the second value is determined. Increment the polling count of the fourth small window by 1; When the number of polling iterations of the fourth small window exceeds the second preset value, the small window pointed to by the first LE is cleared to the fourth small window; Determine the fifth small window, which is the first receiving identifier after the fourth small window in the receiving window, and set its value to the second value; update the first LE of the receiving window to the control identifier of the fifth small window.

30. The method according to claim 19, characterized in that, The method further includes: The multicast source performs periodic timeout processing on the sending window corresponding to the first client it maintains.

31. The method according to claim 30, characterized in that, The multicast source performs periodic timeout processing on the sending window corresponding to the first client it maintains, including: Traverse the small window pointed to by the second LE in the transmission window to the small window pointed to by the second UE in the transmission window, and transmit the sixth small window with the second value; the transmission status value is the second value, indicating that the control signaling frame has not been received; Increment the polling count corresponding to the sixth small window by 1; When the number of polling times of the sixth small window is greater than or equal to the third preset value, it is determined whether the sixth small window meets the retransmission condition; When the retransmission condition is met, the control signaling frame maintained by the sixth small window is determined to be retransmitted, the polling count of the sixth small window is set to 0, the retransmission flag is set to the first value, and the retransmission count is incremented by 1. If the retransmission condition is not met and the number of retransmissions exceeds the fifth preset value, the sixth small window is cleared and the control signaling frames in the storage address buffer of the sixth small window are released. The second LE is determined to be equal to the control identifier of the small window in the sending window whose sending status is the second value and whose control identifier is the smallest.

32. The method according to claim 9, characterized in that, Also includes: The first client establishes a Bluetooth connection with the multicast source and sends a fourth Bluetooth message to the multicast source. The fourth Bluetooth message is used to request to leave the multicast group. The multicast source sends a fifth Bluetooth message to the first client and deletes the multicast user information of the first client. The fifth Bluetooth message is used to indicate and confirm that the first client has left the multicast group. The first client listens to the fifth Bluetooth message and deletes the second multicast group information on the client side based on the fifth Bluetooth message; the second multicast group information includes the multicast address and the first multicast key. The first client and the multicast source disconnect their Bluetooth connection.

33. The method according to claim 32, characterized in that, The first client establishes a Bluetooth connection with the multicast source and sends a fourth Bluetooth message to the multicast source, including: The first client receives the fourth operation; In response to the fourth operation, the first client establishes a Bluetooth connection with the multicast source and sends a fourth Bluetooth message to the multicast source; The method further includes: In response to the fourth operation, the first client closes the multicast application.

34. The method according to claim 9, characterized in that, Also includes: The multicast source broadcasts a sixth Bluetooth message and deletes the first multicast group information on the multicast source side; The sixth Bluetooth message is used to indicate the deletion of the multicast group, and the first multicast group information includes the multicast device list, the first multicast key, and the multicast address; The first client listens to the sixth Bluetooth message via Bluetooth and deletes the second multicast group information on the client side based on the sixth Bluetooth message; the second multicast group information includes the multicast address and the first multicast key.

35. The method according to claim 34, characterized in that, The multicast source Bluetooth broadcasts a sixth Bluetooth message, including: The multicast source receives the fifth operation; In response to the fifth operation, the multicast source Bluetooth broadcasts a sixth Bluetooth message; The method further includes: in response to the fifth operation, closing the multicast application.

36. The method according to claim 17, characterized in that, The signaling frame further includes a multicast type; when the multicast type of the signaling frame is a control signaling frame, the signaling frame further includes a subtype of control signaling frame, the subtype of control signaling frame including a first subtype and a second subtype, the processing modules corresponding to the first subtype and the second subtype are different; the method further includes: The first client submits the first control signaling frame to the processing module corresponding to the first subtype for processing, based on the first subtype in the first control signaling frame.

37. A multicast communication system, characterized in that, It includes a multicast source and at least one client, wherein the at least one client includes a first client; The multicast source is used to perform the steps performed by the multicast source in the method as described in any one of claims 1-36, and the first client of the group performs the steps performed by the first client in the method as described in any one of claims 1-36.

38. A communication device, characterized in that, The method includes a memory and a processor, the memory and the processor being electrically coupled, the memory being used to store program instructions, and the processor being configured to invoke all or part of the program instructions stored in the memory to perform the steps performed by the multicast source in any one of claims 1-36.

39. A communication device, characterized in that, The method includes a memory and a processor, the memory and the processor being electrically coupled, the memory being used to store program instructions, and the processor being configured to invoke all or part of the program instructions stored in the memory to perform the steps executed by the first client in the method as described in any one of claims 1-36.

Images