Broadcast two-way communication method and system, storage medium and electronic equipment

Abstract

The invention discloses a broadcast two-way communication method and system, a storage medium and electronic equipment, the broadcast two-way communication method executed by a broadcaster comprises the steps that at least one broadcast synchronization stream data packet is sent in a broadcast synchronization group event, and the packet header of each broadcast synchronization stream data packet is provided with a control sub-event flag bit; when the broadcaster has to-be-issued control information, setting a control sub-event flag bit as a first value, keeping a sending mode in a control sub-event time slot corresponding to the broadcast synchronization group event, and sending the control information to at least one receiver; and when the broadcaster has no to-be-issued control information, setting the control sub-event flag bit as a second value, and switching to a receiving mode in the control sub-event time slot corresponding to the broadcast synchronization group event so as to monitor and receive uplink data sent by at least one receiver. According to the invention, bidirectional communication between the broadcaster and the receiver can be realized.

Description

Technical Field

[0001] This application relates to the field of wireless communication technology, specifically to a broadcast two-way communication method, system, storage medium, and electronic device. Background Technology

[0002] With the popularization of Bluetooth Low Energy Audio (LE Audio) technology, the Broadcast Isochronous Group (BIG) mechanism has been widely used in one-to-many communication scenarios such as audio sharing, public broadcasting, and multi-device media playback because it supports one-to-many unidirectional broadcast communication.

[0003] Most current BIG mechanisms are based on a one-way broadcast design. The broadcaster periodically transmits data through events containing multiple Broadcast Isochronous Streams (BIS), which is suitable for downlink transmission scenarios such as audio distribution and information push.

[0004] However, in most practical application scenarios (such as smart home device interaction, speaking requests in conference systems, device status feedback, etc.), the receiver needs to send control signals, device status or interaction data back to the broadcaster. The existing BIG mechanism cannot support the reverse communication requirement, which limits its application potential in interactive broadcast scenarios. Summary of the Invention

[0005] This application provides a broadcast two-way communication method, system, storage medium, and electronic device that can realize two-way communication between a broadcaster and a receiver.

[0006] In a first aspect, embodiments of this application provide a broadcast two-way communication method, which is executed by a broadcaster, and includes: At least one broadcast synchronization stream data packet is sent in the broadcast synchronization group event, wherein the header of each broadcast synchronization stream data packet is set with a control sub-event flag bit; When the broadcaster has control information to be sent, it sets the control sub-event flag to a first value and maintains the sending mode in the control sub-event time slot corresponding to the broadcast synchronization group event, and sends the control information to at least one receiver. When the broadcaster has no control information to be sent, it sets the control sub-event flag to the second value and switches to receive mode in the control sub-event time slot corresponding to the broadcast synchronization group event to listen for and receive uplink data sent by at least one receiver.

[0007] In the broadcast two-way communication method provided in this application embodiment, before sending at least one broadcast synchronization stream data packet in the broadcast synchronization group event, it further includes: Send an extended broadcast, the extended broadcast carrying parameter information for periodic broadcasts; Synchronization information of the broadcast synchronization group is sent to the at least one receiver via the periodic broadcast.

[0008] In the broadcast two-way communication method provided in the embodiments of this application, when the broadcaster is listening to and receiving uplink data from at least one receiver, it fully reuses the preset timing and frequency hopping sequence of the control sub-event time slot.

[0009] Secondly, embodiments of this application provide a broadcast two-way communication method, which is executed by a receiver, and the broadcast two-way communication method includes: Scan the broadcast channel to synchronize with the broadcast synchronization group established by the broadcaster; In a broadcast synchronization group event, at least one broadcast synchronization stream data packet is received, and the control sub-event flag bit in the header of the broadcast synchronization stream data packet is parsed. When the control sub-event flag is at the first value, the receiving mode is maintained in the control sub-event time slot corresponding to the broadcast synchronization group event to receive control information from the broadcaster; When the control sub-event flag is at the second value, the system switches to transmit mode in the control sub-event time slot and transmits uplink data to the broadcaster.

[0010] In the broadcast two-way communication method provided in this application embodiment, the step of scanning the broadcast channel to synchronize with the broadcast synchronization group established by the broadcaster includes: Scan broadcast channels; When an extended broadcast is detected, extract the parameter information of the periodic broadcast from the extended broadcast; Obtain the corresponding periodic broadcast based on the parameter information; The system synchronizes with the broadcast synchronization group established by the broadcaster based on the synchronization information of the periodic broadcast.

[0011] In the broadcast two-way communication method provided in the embodiments of this application, when the receiver transmits uplink data in the control sub-event time slot, it fully reuses the preset timing and frequency hopping sequence of the control sub-event time slot.

[0012] In the broadcast two-way communication method provided in this application embodiment, when it is necessary to switch to transmission mode in the control sub-event time slot to transmit uplink data to the broadcaster, the receiver executes a backoff transmission mechanism, which includes: When determining the transmission of uplink data, the event counter value N of the broadcast synchronization group event corresponding to the control sub-event time slot; The data transmission is then repeated sequentially in the control sub-event time slots corresponding to the subsequent M consecutive event counter values ​​N+1 to N+M. After a total of M+1 transmissions are completed, the data transmission is determined to be complete, where M is the preset number of retransmissions. The event counter value for the next retransmission event is set to N+M+R, where R is a random integer greater than or equal to the preset backoff interval.

[0013] Thirdly, embodiments of this application provide a broadcast two-way communication system, including: A broadcaster for performing a two-way broadcast communication method performed in the broadcaster; A receiver for performing a broadcast bidirectional communication method executed within the receiver.

[0014] Fourthly, this application provides a storage medium storing a plurality of instructions adapted for loading by a processor to execute the broadcast bidirectional communication method described in any of the preceding claims.

[0015] Fifthly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the broadcast two-way communication method described in any of the preceding claims.

[0016] In summary, the broadcast two-way communication method performed by a broadcaster provided in this application includes: sending at least one broadcast synchronization stream data packet in a broadcast synchronization group event, wherein each broadcast synchronization stream data packet has a control sub-event flag bit in its header; when the broadcaster has control information to be sent, setting the control sub-event flag bit to a first value, and maintaining the sending mode in the control sub-event time slot corresponding to the broadcast synchronization group event to send the control information to at least one receiver; when the broadcaster has no control information to be sent, setting the control sub-event flag bit to a second value, and switching to receiving mode in the control sub-event time slot corresponding to the broadcast synchronization group event to listen for and receive uplink data sent by at least one receiver. This application embodiment can realize two-way communication between the broadcaster and the receiver. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1This is a flowchart illustrating the broadcast two-way communication method provided in the embodiments of this application.

[0019] Figure 2 This is another flowchart illustrating the broadcast two-way communication method provided in the embodiments of this application.

[0020] Figure 3 This is a schematic diagram of the structure of the broadcast two-way communication system provided in the embodiments of this application.

[0021] Figure 4 This is a schematic diagram of the structure of the broadcaster provided in the embodiment of this application.

[0022] Figure 5 This is a schematic diagram of the receiver provided in an embodiment of this application.

[0023] Figure 6 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0024] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of systems and methods consistent with some aspects of this application as detailed in the appended claims.

[0025] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element. Furthermore, components, features, and elements with the same names in different embodiments of this application may have the same meaning or different meanings, the specific meaning of which must be determined by its interpretation in that specific embodiment or further in conjunction with the context of that specific embodiment.

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

[0027] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustrative purposes and has no specific meaning in itself. Therefore, "module," "part," or "unit" may be used interchangeably.

[0028] In the description of this application, it should be noted that the terms "upper," "lower," "left," "right," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this application and for simplifying the description, and do not indicate or imply that the system or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application. In addition, terms such as "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0029] Most current BIG mechanisms are based on a one-way broadcast design. The broadcaster periodically transmits data through events containing multiple Broadcast Isochronous Streams (BIS), which is suitable for downlink transmission scenarios such as audio distribution and information push.

[0030] However, in most practical application scenarios (such as smart home device interaction, speaking requests in conference systems, device status feedback, etc.), the receiver needs to send control signals, device status or interaction data back to the broadcaster. The existing BIG mechanism cannot support the reverse communication requirement, which limits its application potential in interactive broadcast scenarios.

[0031] Based on this, embodiments of this application provide a broadcast two-way communication method, system, storage medium, and electronic device. The core of these embodiments lies in semantically reconstructing and reusing the existing Control Sub-Event Flag (CSTF) bits in the LE Audio BIG architecture, thereby achieving reverse data communication from the broadcaster to the receiver without altering its underlying framework, such as timing and frequency hopping. The technical solutions shown in this application will be described in detail below through specific embodiments. It should be noted that the order of description of the following embodiments is not intended to limit the priority of the embodiments.

[0032] Please see Figure 1 , Figure 1 This is a flowchart illustrating the broadcast two-way communication method provided in an embodiment of this application. The broadcast two-way communication method is executed by a broadcaster, and its specific flow can be as follows: 101. In a broadcast synchronization group event, send at least one broadcast synchronization stream data packet, wherein the header of each broadcast synchronization stream data packet is set with a control sub-event flag.

[0033] When a broadcaster is operating normally, it periodically organizes broadcast synchronization group events. During each broadcast synchronization group event, the broadcaster sends one or more broadcast synchronization stream packets to transmit audio or data streams.

[0034] In this embodiment, the broadcaster sets an existing, standard-compliant control sub-event flag (e.g., CSTF) in the header of each broadcast synchronization stream data packet. The key to this embodiment is that it does not make any structural modifications to the broadcast synchronization stream data packet format or add new independent instruction fields; instead, it semantically reconstructs and dynamically reuses this bit already defined in the existing standard. This control sub-event flag is a single bit whose core function is to indicate whether the control sub-event slot in the current broadcast synchronization group event is used for downlink control information transmission by the broadcaster or authorized for uplink data transmission by the receiver. This allows for bidirectional communication between the broadcaster and receiver without the need for additional reverse communication enable instructions and reverse control periods.

[0035] Understandably, a synchronization connection with the receiver must be established before the broadcaster can send these broadcast synchronization stream data packets.

[0036] Specifically, the broadcaster first sends an extended broadcast carrying parameter information describing subsequent periodic broadcasts, such as the access code, spectrogram, and the time of the next periodic broadcast. Receivers can then receive the periodic broadcasts based on this parameter information. The broadcaster then sends synchronization information for the broadcast synchronization group to at least one receiver via periodic broadcasts, including the access code, event interval, and frequency hopping sequence of the broadcast synchronization group. This ensures that the receiver is time-synchronized with the broadcast synchronization group established by the broadcaster, thereby correctly receiving broadcast synchronization stream data packets in the broadcast synchronization group events.

[0037] That is, before step 101, the method further includes: sending an extended broadcast, the extended broadcast carrying parameter information of the periodic broadcast; and sending synchronization information of the broadcast synchronization group to at least one receiver through the periodic broadcast.

[0038] 102. When the broadcaster has control information to be sent, it sets the control sub-event flag to the first value and maintains the sending mode in the control sub-event time slot corresponding to the broadcast synchronization group event, sending the control information to at least one receiver.

[0039] In practice, the broadcaster first needs to determine whether there is any control information that needs to be actively sent to the receiver in the current broadcast synchronization group event. This control information may include volume adjustment commands, playback control commands, stream encryption key update information, etc.

[0040] When control information is available to be sent, the broadcaster can set the control sub-event flag in the broadcast synchronization stream packet header to a first value (e.g., logic "1"). This first value indicates to the receiver that the current broadcast synchronization group event contains a valid control sub-event initiated by the broadcaster. At this time, the function of the control sub-event slot is fully consistent with the traditional Bluetooth one-way broadcast specification, ensuring backward compatibility. Subsequently, within the dedicated control sub-event slot reserved for control interaction during the current broadcast synchronization group event period, the broadcaster continues to keep its wireless transmitter in transmit mode.

[0041] Finally, the broadcaster encapsulates the control information into data packets according to the preset timing and frequency hopping sequence of the control sub-event time slot and sends them to all synchronized receivers. At this point, the entire communication process fully complies with the physical layer and link layer rules of the standard Bluetooth broadcast synchronization group, without introducing any new time slot definitions or channel structures.

[0042] 103. When the broadcaster has no control information to be sent, set the control sub-event flag to the second value, and switch to receive mode in the control sub-event time slot corresponding to the broadcast synchronization group event to listen for and receive uplink data sent by at least one receiver.

[0043] In practice, when the broadcaster does not have any control information to actively send in the current broadcast synchronization group event, the broadcaster performs a reverse communication authorization operation.

[0044] Specifically, the broadcaster can broadcast the control sub-event flag bit in the synchronization stream packet header as a second value (e.g., logic "0"). In this embodiment, this second value is not a simple "no control information" indication, but rather carries a new semantic meaning of granting reverse communication authorization. This means that this application does not add any dedicated reverse enable instruction bits to the data packet, but implicitly and dynamically authorizes the receiver to use the immediately following control sub-event slot for uplink transmission without changing any broadcast synchronization stream packet header structure, by reusing the second state of the existing CSTF flag. This second value is used to indicate that although the current broadcast synchronization group event does not contain control information sent by the broadcaster, the corresponding control sub-event slot is authorized for the receiver to send uplink data to the broadcaster.

[0045] After setting the control sub-event flag to the second value, the broadcaster can switch its wireless transmitter from transmit mode to receive mode before the control sub-event slot arrives. When listening to and receiving uplink data from at least one receiver, the broadcaster fully reuses the original preset timing and frequency hopping sequence of the control sub-event slot, without requiring the receiver to follow any new timing or frequency hopping rules different from the standard control sub-event. At this point, the broadcaster's role changes from sender to listener.

[0046] The uplink data may include receiver status feedback, control requests, channel quality reports, or any application-layer defined specific data. In this way, this application achieves efficient dynamic multiplexing of potentially idle radio resources (control sub-event slots without downlink control information) under the existing protocol framework, constructing a lightweight, low-overhead, and fully backward-compatible reverse communication channel without the need for pre-allocating or defining independent dedicated uplink time slots.

[0047] In summary, the broadcast two-way communication method performed by a broadcaster provided in this application includes: sending at least one broadcast synchronization stream data packet in a broadcast synchronization group event, wherein each broadcast synchronization stream data packet has a control sub-event flag bit in its header; when the broadcaster has control information to be sent, setting the control sub-event flag bit to a first value, and maintaining the sending mode in the control sub-event time slot corresponding to the broadcast synchronization group event to send the control information to at least one receiver; when the broadcaster has no control information to be sent, setting the control sub-event flag bit to a second value, and switching to the receiving mode in the control sub-event time slot corresponding to the broadcast synchronization group event to listen for and receive uplink data sent by at least one receiver. This application embodiment can realize two-way communication between the broadcaster and the receiver. This application embodiment, through semantic reconstruction of a single flag bit and dynamic time-division multiplexing, intelligently allocates the existing control sub-event time slots in the standard to downlink control channels or uplink feedback channels according to the real-time needs of the broadcaster, without changing the timing, frequency hopping, frame structure, or data packet format of the existing Bluetooth Broadcast Synchronization Group (BIG). This approach not only achieves complete backward compatibility, avoiding protocol complexity and compatibility issues caused by adding new instructions, extending packet headers, or fixing new time slots, but also provides a more flexible and efficient way to utilize resources. Compared to technologies that require the introduction of independent reverse enable instructions and dedicated time slots, this solution achieves bidirectional communication while maximizing system simplicity and seamless coexistence with existing unidirectional broadcast equipment. Furthermore, this embodiment constructs a lightweight, low-overhead reverse communication channel, enabling the broadcaster to receive uplink data within a standard unidirectional broadcast architecture. This solves the technical bottleneck of lacking a reverse feedback channel in broadcast scenarios, achieving bidirectional communication between the broadcaster and receiver, and significantly enhancing the system's interactivity and manageability.

[0048] Please see Figure 2 , Figure 2 This is a flowchart illustrating the broadcast two-way communication method provided in an embodiment of this application. The broadcast two-way communication method is executed by a receiver, and the specific flow of the broadcast two-way communication method is as follows: 201. Scan the broadcast channel to synchronize with the broadcast synchronization group established by the broadcaster.

[0049] In some embodiments, the receiver may scan the broadcast channel; when an extended broadcast is detected, it may extract parameter information of the periodic broadcast from the extended broadcast; obtain the corresponding periodic broadcast based on the parameter information; and synchronize with the broadcast synchronization group established by the broadcaster based on the synchronization information of the periodic broadcast.

[0050] In practice, after the receiver is started, it will activate its wireless receiving unit to scan the broadcast channel in order to discover and synchronize with the broadcast synchronization group established by the broadcaster.

[0051] Specifically, the receiver can first scan the broadcast channel. When it detects an extended broadcast from the broadcaster, the receiver parses it to extract parameter information about the periodic broadcast, such as the access code and synchronization time. Based on this parameter information, the receiver switches to the designated channel at the correct time to wait for and receive the periodic broadcast from the broadcaster.

[0052] Upon receiving a periodic broadcast, the receiver can further parse the synchronization information of the broadcast synchronization group from the broadcast. This synchronization information may include the broadcast synchronization group identifier, event counter anchor point, event interval, frequency hopping sequence, etc. Using this synchronization information, the receiver adjusts its own timing and frequency hopping pattern to achieve precise synchronization with the broadcast synchronization group established by the broadcaster in both time and frequency, preparing for subsequent reception of broadcast synchronization stream data packets.

[0053] 202. In a broadcast synchronization group event, receive at least one broadcast synchronization stream data packet and parse the control sub-event flag bit in the header of the broadcast synchronization stream data packet.

[0054] Understandably, after successfully synchronizing with the broadcast synchronization group, the receiver can begin receiving each broadcast synchronization group event.

[0055] In each broadcast synchronization group event, the receiver can receive one or more broadcast synchronization stream packets sent by the broadcaster. The receiver then parses the header of each received broadcast synchronization stream packet. It should be noted that the receiver parses the existing Control Sub-Event Flag (CSTF) bit in the standard format header, without recognizing any newly added, independent reverse communication enable command bits. This allows the receiver to extract the CSTF bit carried in the header. The value of this CSTF bit determines the behavior pattern the receiver should adopt in the following control sub-event time slot.

[0056] 203. When the control sub-event flag is at the first value, the receiving mode is maintained in the control sub-event time slot corresponding to the broadcast synchronization group event in order to receive control information from the broadcaster.

[0057] Specifically, when the receiver parses the control sub-event flag in the broadcast synchronization stream data packet to a first value (e.g., logic "1"), the receiver can determine that the current broadcast synchronization group event contains a control sub-event initiated by the broadcaster.

[0058] Therefore, during the control sub-event time slot corresponding to the broadcast synchronization group event, the receiver continues to keep its wireless transceiver unit in receive mode. The receiver listens to the wireless channel according to the preset timing and frequency hopping sequence of that control sub-event time slot, preparing to receive and decode the control information transmitted by the broadcaster during that control sub-event time slot. The received control information will be passed to the upper-layer application for processing. It should be noted that this receiving mode is completely consistent with traditional one-way broadcast reception behavior, thus ensuring backward compatibility.

[0059] 204. When the control sub-event flag is at the second value, switch to transmit mode in the control sub-event time slot and transmit uplink data to the broadcaster.

[0060] When the receiver parses the control sub-event flag as a second value (e.g., logic "0"), it interprets it as an "uplink transmission grant" instruction, rather than a simple indication of no control information, based on the new semantics assigned in this application. The receiver can then determine that the current control sub-event slot has been granted uplink transmission by the broadcaster.

[0061] At this point, the receiver can first check if it has uplink data to send to the broadcaster. If so, before the control sub-event slot arrives, the receiver switches its radio transceiver unit from receive mode to transmit mode. Subsequently, the receiver fully reuses the preset timing and frequency hopping sequence of the control sub-event slot (this sequence is exactly the same as the sequence used by the broadcaster when sending downlink control information), encapsulates its uplink data into data packets, and sends them to the broadcaster within the control sub-event slot.

[0062] It should be noted that the transmission of uplink data fully complies with the original physical layer and link layer rules of the control sub-event, without the need to introduce new communication protocols or change the timing structure, thus achieving efficient and compatible reverse communication.

[0063] Furthermore, when multiple receivers need to send uplink data to the broadcaster within the same authorized control sub-event time slot, the receivers can implement a backoff transmission mechanism to reduce data collisions.

[0064] In some embodiments, the backoff transmission mechanism may be as follows: when determining the transmission of uplink data, control the event counter value N of the broadcast synchronization group event corresponding to the sub-event time slot; and sequentially repeat the data transmission in the control sub-event time slots corresponding to the subsequent M consecutive event counter values ​​N+1 to N+M, and determine that the data transmission is completed after a total of M+1 transmissions, where M is the preset number of retransmissions; and set the event counter value of the next retransmission event to N+M+R, where R is a random integer greater than or equal to the preset backoff interval.

[0065] Specifically, the receiver can first determine the event counter value N of the broadcast synchronization group event corresponding to the current uplink data transmission. The receiver can then initiate a retransmission event for the same uplink data in the control sub-event time slots corresponding to M consecutive broadcast synchronization group events, where M is a preset number of retransmissions, such as 3. This instant retransmission mechanism based on consecutive event intervals aims for rapid recovery and adapts to scenarios sensitive to latency.

[0066] Specifically, the receiver generates a random integer R, where R is greater than or equal to a preset backoff interval (e.g., 4). The receiver sets the start event counter value for the next attempt to initiate uplink data transmission to N+M+R, thereby delaying the transmission timing by R event intervals. This disperses the transmission attempts of multiple receivers in time, significantly reducing the probability of subsequent collisions and improving the overall communication reliability of the system in multi-receiver scenarios. The backoff mechanism in this embodiment is a structured backoff algorithm based on event counters. This mechanism allows for rapid retries within several consecutive event intervals, and only performs random backoff with a larger step size after multiple failures. This achieves a better balance between conflict resolution efficiency and uplink response latency, improving the overall communication reliability and real-time performance of the system in multi-receiver contention scenarios.

[0067] Additionally, if the broadcaster has control information to send during the subsequent H data transmission processes, the data transmission will proceed only after the broadcaster has finished sending the information. For example, if H > 4, and the broadcaster needs to send control information at time N+2, with H retransmissions, then the data transmission will proceed at time N+2+H.

[0068] In summary, the broadcast two-way communication method performed by the receiver provided in this application includes scanning the broadcast channel to synchronize with the broadcast synchronization group established by the broadcaster; receiving at least one broadcast synchronization stream data packet during a broadcast synchronization group event, and parsing the control sub-event flag bit in the header of the broadcast synchronization stream data packet; when the control sub-event flag bit is a first value, maintaining the receiving mode in the control sub-event time slot corresponding to the broadcast synchronization group event to receive control information from the broadcaster; when the control sub-event flag bit is a second value, switching to the transmitting mode in the control sub-event time slot to transmit uplink data to the broadcaster. This application embodiment enables the receiver to identify whether the broadcaster has authorized reverse transmission by parsing the control sub-event flag bit in the broadcast synchronization stream data packet. When the control sub-event flag bit is a first value, maintaining the receiving mode ensures compatibility with traditional control information delivery; when the control sub-event flag bit is a second value, switching to the transmitting mode enables uplink data transmission to the broadcaster while strictly reusing the original timing and frequency hopping sequence of the control sub-event time slot. The bidirectional communication capability of this application embodiment does not rely on adding any reverse enable command bits to the data packets, nor does it rely on predefining independent shared reverse control periods in the communication timing. Instead, this application embodiment reconstructs the semantics of CSTF in existing standard protocols and, in conjunction with dynamic transmit / receive mode switching, achieves intelligent and dynamic multiplexing of standard control sub-event time slots. This ensures full compatibility with existing unidirectional broadcast systems at the protocol stack level, provides the receiver with reliable and low-latency reverse communication capability, and minimizes system complexity and power consumption increments. Furthermore, by combining a structured backoff transmission mechanism based on event counters, data collisions in multi-receiver scenarios are effectively avoided. Therefore, this solution successfully solves the problem of the lack of an uplink feedback channel in broadcast architectures and realizes a highly compatible, flexible, and efficient bidirectional communication mechanism.

[0069] To facilitate better implementation of the broadcast two-way communication method provided in the embodiments of this application, the embodiments of this application also provide a broadcast two-way communication system. The meanings of the terms used are the same as in the above-described broadcast two-way communication method, and specific implementation details can be found in the descriptions in the method embodiments.

[0070] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of a broadcast two-way communication system provided in an embodiment of this application. The broadcast two-way communication system may include a broadcaster 301 and a receiver 302. Broadcaster 301 is used to execute the aforementioned two-way broadcast communication method performed by the broadcaster. Specifically, as shown... Figure 4 As shown, the broadcaster 301 may include: The data sending module 3011 is used to send at least one broadcast synchronization stream data packet in a broadcast synchronization group event, wherein the header of each broadcast synchronization stream data packet is set with a control sub-event flag bit; The first communication module 3012 is used to set the control sub-event flag to a first value when the broadcaster has control information to be sent, and maintain the sending mode in the control sub-event time slot corresponding to the broadcast synchronization group event to send control information to at least one receiver; when the broadcaster has no control information to be sent, it sets the control sub-event flag to a second value, and switches to the receiving mode in the control sub-event time slot corresponding to the broadcast synchronization group event to listen for and receive uplink data sent by at least one receiver.

[0071] Receiver 302 is used to perform the aforementioned broadcast two-way communication method performed by the receiver. Specifically, as shown... Figure 5 As shown, the receiver 302 may include: The broadcast synchronization module 3021 is used to scan the broadcast channel to synchronize with the broadcast synchronization group established by the broadcaster; The flag determination module 3022 is used to receive at least one broadcast synchronization stream data packet in a broadcast synchronization group event and parse the control sub-event flag bit in the header of the broadcast synchronization stream data packet; The second communication module 3023 is used to maintain the receiving mode in the control sub-event time slot corresponding to the broadcast synchronization group event when the control sub-event flag bit is the first value, so as to receive control information from the broadcaster; and to switch to the transmitting mode in the control sub-event time slot when the control sub-event flag bit is the second value, so as to transmit uplink data to the broadcaster.

[0072] For specific implementation methods of each of the above units, please refer to the embodiments of the above-described broadcast two-way communication method, which will not be repeated here.

[0073] In summary, the broadcast two-way communication system provided in this application integrates the broadcaster and receiver, which execute the two-way communication method, into a complete system working collaboratively, realizing two-way data interaction under the standard broadcast architecture. The broadcast two-way communication system strictly adheres to the existing physical layer and link layer specifications of the Bluetooth Broadcast Synchronization Group. The broadcaster dynamically manages the use of control sub-event time slots by parsing and setting control sub-event flags, while the receiver switches transmit and receive modes according to these flags. Both parties successfully construct a reverse channel without additional protocol overhead, fully reusing the preset timing and frequency hopping sequences. This system architecture maintains backward compatibility with unidirectional broadcast devices while converting potentially idle wireless resources into usable reverse communication resources, effectively solving the inherent problem of missing uplink feedback in broadcast scenarios. It provides an efficient and reliable complete communication solution for audio and IoT applications requiring two-way interaction.

[0074] This application also provides an electronic device that may integrate the broadcast two-way communication system of this application, such as... Figure 6 As shown, it illustrates a structural schematic diagram of the electronic device involved in the embodiments of this application, specifically: The electronic device may include components such as a processor 401 with one or more processing cores and a memory 402 with one or more computer-readable storage media. Those skilled in the art will understand that... Figure 6 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 401 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs stored in the memory 402 and / or this application, and by calling data stored in the memory 402, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. Optionally, the processor 401 may include one or more processing cores; preferably, the processor 401 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operation of the storage medium, user interface, and application programs, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 401.

[0075] The memory 402 can be used to store software programs and this application. The processor 401 executes various functional applications and data processing by running the software programs and this application stored in the memory 402. The memory 402 may mainly include a program storage area and a data storage area. The program storage area may store applications required for operating the storage medium and at least one function; the data storage area may store data created based on the use of the electronic device. In addition, the memory 402 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 402 may also include a memory controller to provide the processor 401 with access to the memory 402.

[0076] Although not shown, the electronic device may also include a display unit, an input unit, and a power supply, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 401 in the electronic device loads the executable files corresponding to the processes of one or more application programs into the memory 402 according to the following instructions, and the processor 401 runs the application programs stored in the memory 402 to realize various functions, as follows: In a broadcast synchronization group event, at least one broadcast synchronization stream data packet is sent, wherein the header of each broadcast synchronization stream data packet is set with a control sub-event flag. When the broadcaster has control information to be sent, it sets the control sub-event flag to the first value and maintains the sending mode in the control sub-event time slot corresponding to the broadcast synchronization group event, sending the control information to at least one receiver. When the broadcaster has no control information to send, it sets the control sub-event flag to the second value and switches to receive mode in the control sub-event time slot corresponding to the broadcast synchronization group event to listen for and receive uplink data sent by at least one receiver.

[0077] Or as follows: Scan the broadcast channel to synchronize with the broadcast synchronization group established by the broadcaster; In a broadcast synchronization group event, at least one broadcast synchronization stream data packet is received, and the control sub-event flag bits in the header of the broadcast synchronization stream data packet are parsed. When the control sub-event flag is set to the first value, the receiving mode is maintained in the control sub-event time slot corresponding to the broadcast synchronization group event in order to receive control information from the broadcaster; When the control sub-event flag is at the second value, the system switches to transmit mode in the control sub-event time slot and transmits uplink data to the broadcaster.

[0078] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0079] Therefore, embodiments of this application provide a storage medium storing a plurality of instructions that can be loaded by a processor to execute steps in any of the methods provided in embodiments of this application. For example, the instructions can execute the following steps: In a broadcast synchronization group event, at least one broadcast synchronization stream data packet is sent, wherein the header of each broadcast synchronization stream data packet is set with a control sub-event flag. When the broadcaster has control information to be sent, it sets the control sub-event flag to the first value and maintains the sending mode in the control sub-event time slot corresponding to the broadcast synchronization group event, sending the control information to at least one receiver. When the broadcaster has no control information to send, it sets the control sub-event flag to the second value and switches to receive mode in the control sub-event time slot corresponding to the broadcast synchronization group event to listen for and receive uplink data sent by at least one receiver.

[0080] Or perform the following steps: Scan the broadcast channel to synchronize with the broadcast synchronization group established by the broadcaster; In a broadcast synchronization group event, at least one broadcast synchronization stream data packet is received, and the control sub-event flag bits in the header of the broadcast synchronization stream data packet are parsed. When the control sub-event flag is set to the first value, the receiving mode is maintained in the control sub-event time slot corresponding to the broadcast synchronization group event in order to receive control information from the broadcaster; When the control sub-event flag is at the second value, the system switches to transmit mode in the control sub-event time slot and transmits uplink data to the broadcaster.

[0081] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0082] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0083] Since the instructions stored in the storage medium can execute the steps of any method provided in the embodiments of this application, the beneficial effects that any method provided in the embodiments of this application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0084] The above provides a detailed description of the broadcast two-way communication method, system, storage medium, and electronic device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the core ideas of this application. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A broadcast two-way communication method, characterized in that, The broadcast two-way communication method is executed by the broadcaster, and the broadcast two-way communication method includes: At least one broadcast synchronization stream data packet is sent in the broadcast synchronization group event, wherein the header of each broadcast synchronization stream data packet is set with a control sub-event flag bit; When the broadcaster has control information to be sent, it sets the control sub-event flag to a first value and maintains the sending mode in the control sub-event time slot corresponding to the broadcast synchronization group event, and sends the control information to at least one receiver. When the broadcaster has no control information to be sent, it sets the control sub-event flag to the second value and switches to receive mode in the control sub-event time slot corresponding to the broadcast synchronization group event to listen for and receive uplink data sent by at least one receiver.

2. The broadcast two-way communication method as described in claim 1, characterized in that, Prior to sending at least one broadcast synchronization stream packet in the broadcast synchronization group event, the method further includes: Send an extended broadcast, the extended broadcast carrying parameter information for periodic broadcasts; Synchronization information of the broadcast synchronization group is sent to the at least one receiver via the periodic broadcast.

3. The broadcast two-way communication method as described in claim 1, characterized in that, When the broadcaster listens for and receives uplink data from at least one receiver, it fully reuses the preset timing and frequency hopping sequence of the control sub-event slot.

4. A broadcast two-way communication method, characterized in that, The broadcast two-way communication method is executed by a receiver, and the broadcast two-way communication method includes: Scan the broadcast channel to synchronize with the broadcast synchronization group established by the broadcaster; In a broadcast synchronization group event, at least one broadcast synchronization stream data packet is received, and the control sub-event flag bit in the header of the broadcast synchronization stream data packet is parsed. When the control sub-event flag is at the first value, the receiving mode is maintained in the control sub-event time slot corresponding to the broadcast synchronization group event to receive control information from the broadcaster; When the control sub-event flag is at the second value, the system switches to transmit mode in the control sub-event time slot and transmits uplink data to the broadcaster.

5. The broadcast two-way communication method as described in claim 4, characterized in that, The scanning of the broadcast channel for synchronization with the broadcast synchronization group established by the broadcaster includes: Scan broadcast channels; When an extended broadcast is detected, extract the parameter information of the periodic broadcast from the extended broadcast; Obtain the corresponding periodic broadcast based on the parameter information; The system synchronizes with the broadcast synchronization group established by the broadcaster based on the synchronization information of the periodic broadcast.

6. The broadcast two-way communication method as described in claim 4, characterized in that, When the receiver transmits uplink data in the control sub-event time slot, it fully reuses the preset timing and frequency hopping sequence of the control sub-event time slot.

7. The broadcast two-way communication method as described in claim 4, characterized in that, When it is necessary to switch to transmit mode in the control sub-event slot to transmit uplink data to the broadcaster, the receiver executes a backoff transmission mechanism, which includes: When determining the transmission of uplink data, the event counter value N of the broadcast synchronization group event corresponding to the control sub-event time slot; The data transmission is then repeated sequentially in the control sub-event time slots corresponding to the subsequent M consecutive event counter values ​​N+1 to N+M. After a total of M+1 transmissions are completed, the data transmission is determined to be complete, where M is the preset number of retransmissions. The event counter value for the next retransmission event is set to N+M+R, where R is a random integer greater than or equal to the preset backoff interval.

8. A broadcast two-way communication system, characterized in that, include: A broadcaster, the broadcaster being used to perform the broadcast two-way communication method as described in any one of claims 1-3; A receiver, the receiver being configured to perform the broadcast two-way communication method as described in any one of claims 4-7.

9. A storage medium, characterized in that, The storage medium stores a plurality of instructions adapted for loading by a processor to execute the broadcast bidirectional communication method of any one of claims 1-3 or 4-7.

10. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the broadcast two-way communication method as described in any one of claims 1-3 or 4-7.

Images