Low power broadcast control information stream for synchronizing a broadcaster device and one or more peripheral devices

Abstract

The present disclosure provides methods, components, devices, and systems for synchronizing low-energy (LE) broadcast control information streams of a broadcaster device and one or more peripheral devices. More specifically, some aspects relate to how a broadcaster device can indicate whether a control sub-event of a broadcast isochronous group (BIG) event is associated with a vendor-specific communication and a transmission direction associated with the control sub-event. The broadcaster device can provide such indication via a packet transmitted during a broadcast isochronous stream (BIS) event of the BIG event preceding the control sub-event. In some implementations, the broadcaster device can use a control sub-event transmission flag (CSTF) set equal to a certain value to indicate that an upcoming control sub-event is associated with a vendor-specific communication and can use at least a portion of a control sub-event sequence number (CSSN) field to indicate whether the transmission direction is broadcaster-to-peripheral device or peripheral device-to-broadcaster.

Description

[0001] Cross-references

[0002] This patent application claims priority to U.S. Patent Application No. 18 / 594,406, filed March 4, 2024, entitled “LOW ENERGYBROADCAST CONTROL INFORMATION FLOW FOR SYNCHRONIZING ABROADCASTER DEVICE AND ONE OR MORE PERIPHERAL DEVICES”, which is assigned to the assignee of this application and is expressly incorporated herein by reference. Technical Field

[0003] This disclosure relates generally to wireless communication, and more specifically to low-power (LE) broadcast control information streams for synchronizing broadcaster devices and one or more peripheral devices. Background Technology

[0004] Wireless communication networks are widely deployed to provide various types of communication content, such as voice, video, packet data, message sending and receiving, and broadcasting. Some wireless communication networks can support communication with multiple users by sharing available system resources, such as time, frequency, or power. Furthermore, wireless communication networks can employ technologies such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), or Discrete Fourier Transform Extended Orthogonal Frequency Division Multiplexing (DFT-S-OFDM). Wireless communication devices can communicate using any one or more of these technologies and may include radio stations (STAs), radio access points (APs), user equipment (UEs), network entities, or other wireless nodes. Wireless Personal Area Networks (WPANs) (which may include Bluetooth connectivity) can provide short-range wireless connections between two or more paired wireless devices. For example, wireless devices (such as cellular phones) can utilize WPAN communication to exchange information (such as audio signals) with wireless headsets. Summary of the Invention

[0005] The systems, methods, and apparatus disclosed herein each have some innovative aspects, and no single aspect is solely responsible for the desired properties disclosed herein.

[0006] One innovative aspect of the subject matter described in this disclosure can be implemented in a broadcaster device. The broadcaster device may include a processing system comprising processor circuitry and memory circuitry storing code. The processing system may be configured to cause the broadcaster device to: transmit, via a plurality of broadcast isochronous streams (BIS) of a broadcast isochronous group (BIG) and during one or more first sub-events of a first BIG event, one or more first packets indicating that a control sub-event of the first BIG event is associated with vendor-specific communication; and, based on the one or more first packets indicating that the control sub-event is associated with the vendor-specific communication, communicate control information to one or more peripheral devices during the control sub-event.

[0007] Another innovative aspect of the subject matter described in this disclosure can be implemented using a method for wireless communication by or at a broadcaster device. The method may include: transmitting one or more first packets, indicating that a control sub-event of the first BIG event is associated with vendor-specific communication, via a set of multiple BIS of a BIG and during one or more first sub-events of a first BIG event; and communicating control information to one or more peripheral devices during the control sub-event based on the one or more first packets indicating that the control sub-event is associated with the vendor-specific communication.

[0008] Another innovative aspect of the subject matter described in this disclosure can be implemented in a broadcaster device. The broadcaster device may include: components for transmitting one or more first packets indicating that a control sub-event of the first BIG event is associated with vendor-specific communication via a set of multiple BIS of the BIG and during one or more first sub-events of the first BIG event; and components for communicating control information with one or more peripheral devices during the control sub-event based on the one or more first packets indicating that the control sub-event is associated with the vendor-specific communication.

[0009] Another innovative aspect of the subject matter described in this disclosure can be implemented in a non-transitory computer-readable medium storing code for wireless communication by a broadcaster device. This code is capable of including instructions executable by a processing system (including one or more processors) to: transmit one or more first packets indicating that a control sub-event of the first BIG event is associated with vendor-specific communication, via a set of multiple BIS of the BIG and during one or more first sub-events of a first BIG event; and communicate control information to one or more peripheral devices during the control sub-event based on the one or more first packets indicating that the control sub-event is associated with the vendor-specific communication.

[0010] In some specific implementations of the method, broadcaster device, and nontransitory computer-readable medium described herein, the one or more first packets further include a serial number field, and the serial number field indicates the transmission direction of the control information between the broadcaster device and the one or more peripheral devices based on the one or more first packets indicating that the control sub-event can be associated with the vendor-specific communication.

[0011] In some specific implementations of the method, broadcaster device, and nontransitory computer-readable medium described herein, the first bit pattern of the serial number field indicates that the transmission direction may be from the broadcaster to a peripheral device, and the second bit pattern of the serial number field indicates that the transmission direction may be from the peripheral device to the broadcaster.

[0012] In some specific implementations of the method, broadcaster device, and nontransitory computer-readable medium described herein, the serial number field includes three bits, the first of which indicates that the transmission direction may be from the broadcaster to a peripheral device or from the peripheral device to the broadcaster, and the remaining bits of the three bits, excluding the first bit, indicate a serial number that may be valid depending on the first bit indicating that the transmission direction may be from the broadcaster to the peripheral device.

[0013] In some specific implementations of the method, broadcaster device, and nontransitory computer-readable medium described herein, communicating the control information with the one or more peripheral devices may include operations, features, components, or instructions for receiving a packet containing the control information from a first peripheral device among the one or more peripheral devices during the control sub-event, according to the transmission direction and according to the BIG event number corresponding to the first BIG event.

[0014] In some specific implementations of the method, broadcaster device, and nontransitory computer-readable medium described herein, the first peripheral device may be associated with a first BIS corresponding to a first BIS index among a group of multiple BISs, the first BIS index may be associated with the first BIG event, and receiving the packet from the first peripheral device during the control sub-event of the first BIG event may be associated with the first BIG event based on the first BIS index.

[0015] In some specific implementations of the method, broadcaster device, and nontransitory computer-readable medium described herein, the modulo operation between the BIG event number and the number of the group of multiple BISs equals the first BIS index minus one, which can be associated with the first BIG event.

[0016] Another innovative aspect of the subject matter described in this disclosure can be implemented in a peripheral device. The peripheral device may include a processing system comprising processor circuitry and memory circuitry storing code. The processing system may be configured to cause the peripheral device to: receive, via the BIS of the BIG and during one or more first sub-events of a first BIG event, one or more first packets indicating that a control sub-event of the first BIG event is associated with vendor-specific communication; and, based on the one or more first packets indicating that the control sub-event is associated with the vendor-specific communication, communicate control information to a broadcaster device during the control sub-event.

[0017] Another innovative aspect of the subject matter described in this disclosure can be implemented using a method for wireless communication by or at a peripheral device. The method may include: receiving, via a BIS of a BIG and during one or more first sub-events of a first BIG event, one or more first packets indicating that a control sub-event of the first BIG event is associated with vendor-specific communication; and conveying control information to a broadcaster device during the control sub-event based on the one or more first packets indicating that the control sub-event is associated with the vendor-specific communication.

[0018] Another innovative aspect of the subject matter described in this disclosure can be implemented in a peripheral device. This peripheral device may include: components for receiving, via the BIS of the BIG and during one or more first sub-events of the first BIG event, one or more first packets indicating that a control sub-event of the first BIG event is associated with vendor-specific communication; and components for communicating control information to a broadcaster device during the control sub-event based on the one or more first packets indicating that the control sub-event is associated with the vendor-specific communication.

[0019] Another innovative aspect of the subject matter described in this disclosure can be implemented in a non-transitory computer-readable medium storing code for wireless communication by or at a peripheral device. The code may include instructions executable by a processing system (including one or more processors) to: receive one or more first packets indicating that a control sub-event of the first BIG event is associated with vendor-specific communication, via the BIS of the BIG and during one or more first sub-events of the first BIG event; and to communicate control information to a broadcaster device during the control sub-event based on the one or more first packets indicating that the control sub-event is associated with the vendor-specific communication.

[0020] In some specific implementations of the method, peripheral device, and nontransitory computer-readable medium described herein, the one or more first packets further include a serial number field, and the serial number field indicates the transmission direction of the control information between the broadcaster device and the peripheral device based on the one or more first packets indicating that the control sub-event can be associated with the vendor-specific communication.

[0021] In some specific implementations of the method, peripheral device, and nontransitory computer-readable medium described herein, the first bit pattern of the serial number field indicates that the transmission direction may be from a broadcaster to a peripheral device, and the second bit pattern of the serial number field indicates that the transmission direction may be from a peripheral device to a broadcaster.

[0022] In some specific implementations of the method, peripheral device, and nontransitory computer-readable medium described herein, the serial number field includes three bits, the first of which indicates that the transmission direction may be from a broadcaster to a peripheral device or from a peripheral device to a broadcaster, and the remaining bits of the three bits, excluding the first bit, indicate a serial number, which may be valid depending on the first bit indicating that the transmission direction may be from a broadcaster to a peripheral device.

[0023] In some specific implementations of the method, peripheral device, and nontransitory computer-readable medium described herein, communicating the control information with the broadcaster device may include operations, features, components, or instructions for transmitting a packet containing the control information during the control sub-event of the first BIG event, according to the transmission direction and according to the BIG event number corresponding to the first BIG event.

[0024] In some specific implementations of the method, peripheral devices, and nontransitory computer-readable media described herein, the BIS corresponds to a BIS index that can be associated with the first BIG event, and the transmission of the packet during the control sub-event of the first BIG event can be associated with the first BIG event based on the BIS index.

[0025] In some specific implementations of the method, peripheral devices, and nontransitory computer-readable media described herein, a modulo operation between the BIG event number and the number of a set of multiple BISs of the BIG equals the BIS index minus one, which can be associated with the first BIG event.

[0026] Details of one or more specific embodiments of the subject matter described in this disclosure are set forth in the accompanying drawings and the following description. Other features, aspects, and advantages will become apparent from the description, drawings, and claims. Note that the relative dimensions in the following drawings may not be drawn to scale. Attached Figure Description

[0027] Figure 1 A schematic diagram of an example wireless communication network is shown.

[0028] Figure 2 A schematic diagram of another example wireless communication network is shown.

[0029] Figures 3 to 5 An example signaling diagram is shown that supports low-power (LE) broadcast control information flow for synchronizing broadcaster devices and one or more peripheral devices.

[0030] Figure 6 and Figure 7 An example communication timeline is shown that supports the LE broadcast control information flow for synchronizing broadcaster devices and one or more peripheral devices.

[0031] Figure 8 An example process flow is shown that supports the flow of LE broadcast control information for synchronizing broadcaster devices and one or more peripheral devices.

[0032] Figure 9 A block diagram of an example wireless communication device is shown that supports the LE broadcast control information flow for synchronizing broadcaster devices and one or more peripheral devices.

[0033] Figure 10 A block diagram of an example wireless communication device is shown that supports the LE broadcast control information flow for synchronizing broadcaster devices and one or more peripheral devices.

[0034] Figure 11 and Figure 12 A flowchart illustrating an example process performed by or at a broadcaster device that supports the flow of LE broadcast control information for synchronizing broadcaster devices and one or more peripheral devices is shown.

[0035] Figure 13 and Figure 14 A flowchart illustrating an example process performed by or at a peripheral device that supports the flow of LE broadcast control information for synchronizing broadcaster devices and one or more peripheral devices is shown.

[0036] The same reference numerals and names in different figures denote the same elements. Detailed Implementation

[0037] The following description refers to certain specific examples in order to illustrate the innovative aspects of this disclosure. However, those skilled in the art will readily recognize that the teachings herein can be applied in a variety of different ways. Some or all of the examples described can be applied in accordance with the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard, the IEEE 802.15 standard, or Bluetooth as defined by the Bluetooth Special Interest Group (SIG). ® This can be implemented in any device, system, or network that transmits and receives radio frequency (RF) signals according to one or more of the standards or those published by the 3rd Generation Partnership Project (3GPP), such as Long Term Evolution (LTE), 3G, 4G, 5G (New Radio (NR)), or 6G. The described examples can be implemented in any suitable device, component, system, or network capable of transmitting and receiving RF signals according to one or more of the following technologies or techniques: Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Orthogonal Frequency Division Multiplexing (OFDM), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Space Division Multiple Access (SDMA), Rate Split Multiple Access (RSMA), Multi-User Shared Access (MUSA), Single-User (SU) Multiple-Input Multiple-Output (MIMO), and Multi-User (MU)-MIMO (MU-MIMO). The described examples can also be implemented using other wireless communication protocols or RF signals suitable for use in one or more of the following networks: Wireless Personal Area Network (WPAN), Wireless Local Area Network (WLAN), Wireless Wide Area Network (WWAN), Wireless Metropolitan Area Network (WMAN), Non-Terrestrial Network (NTN), or Internet of Things (IoT).

[0038] In some wireless communication networks, such as Bluetooth Low Energy (BLE) networks, a first wireless communication device may broadcast (e.g., transmit) to one or more other wireless communication devices via one or more broadcast isochronous streams (BIS) of a broadcast isochronous group (BIG). The first wireless communication device (which can be understood as a broadcaster device) may broadcast one or more packets to other wireless communication devices (which can be understood as peripheral devices) based on transmission time windows of events and sub-events. For example, within a BIG event (a first transmission time window whose duration is equal to a configured isochronous (ISO) interval), the broadcaster device may transmit one or more packets via one or more BIS events (BIS events corresponding to a second transmission time window whose duration is less than or equal to a configured ISO interval). A BIG event may include control sub-events at or near the end of the BIG event. If a control sub-event exists, the broadcaster device may transmit control information associated with the BIG to peripheral devices via the control sub-event. In some networks, the flow of control information within a BIG may be restricted to from the broadcaster to the peripheral device, preventing the peripheral device from transmitting control information to the broadcaster device. Furthermore, in some networks, control sub-events may lack support for uses beyond those defined by the specification (such as those defined by the Bluetooth Special Interest Group (BT-SIG) standard), which may hinder the extension of LE broadcast to some use cases, such as the communication of vendor-specific information that supports the use of LE broadcast or provides information for the use of LE broadcast.

[0039] Various aspects of this disclosure relate in general to one or more configuration-based or signaling-based mechanisms, according to which two or more wireless communication devices can support the bidirectional transmission of control information between a broadcaster and one or more broadcast receivers. More specifically, some aspects relate to how a broadcaster device can indicate whether a control sub-event of a BIG event is associated with vendor-specific communication and the transmission direction associated with that control sub-event. In some examples, the broadcaster device can provide such indication via one or more packets (such as one or more BIS data protocol data units (PDUs)) transmitted during a BIS event preceding the control sub-event. In some examples, the broadcaster device can use a Control Sub-Event Transmission Flag (CSTF) set to an equal value (such as zero) to indicate that an upcoming control sub-event is associated with vendor-specific communication and can use a portion (such as a bit) of the Control Sub-Event Sequence Number (CSSN) field to indicate whether the transmission direction is broadcaster to peripheral device or peripheral device to broadcaster. In other words, a CSTF set to zero can specify or indicate a vendor-specific purpose, and when the CSTF is set to zero, the CSSN field can specify or indicate the purpose of use. If CSTF is set to zero and CSSN is set to a default value (such as an all-zero bit pattern), then control sub-events may not exist (e.g., not for specification-defined purposes and not for vendor-specific communication). Various other aspects involve conflict avoidance schemes, energy-saving schemes, using opcodes to indicate whether control information includes host-based or controller-based information, and / or periodic notifications (PA), etc.

[0040] Specific aspects of the subject matter described in this disclosure can be implemented to achieve one or more of the following potential advantages. In some examples, by indicating whether an upcoming control sub-event is associated with vendor-specific communication and the transmission direction associated with the control sub-event, the described techniques can be used to dynamically allocate control sub-events for vendor-specific communication in a manner that supports bidirectional transmission of control information between a broadcaster and one or more broadcast receivers. Thus, a broadcaster device or broadcast receiver (such as a peripheral device) can provide vendor-specific information to support suitable use cases with low-latency information flow and relatively low signaling overhead, such as relatively low bandwidth utilization, such as by reusing bits in transmitted packets. Furthermore, according to the described collision avoidance scheme, multiple peripheral devices can provide control information to the broadcaster device without packet collisions (or with a relatively low probability of packet collisions), which improves communication reliability and supports higher data rates and higher spectral efficiency.

[0041] Additionally, according to the described energy-saving scheme, the broadcaster device can optionally monitor control sub-events associated with the peripheral device-to-broadcaster information flow to achieve energy savings or extend battery life while maintaining the reliability (and sufficient chance) of the peripheral device-to-broadcaster device information flow. Furthermore, by using opcodes to indicate whether the control information includes host-based or controller-based information, the controller of the receiving device can use fewer processing resources to parse the control information. Moreover, according to the PA signaling mechanism, the broadcaster device and one or more peripheral devices can support bidirectional transmission of control information with relatively low complexity by limiting the potential number of interpretations of the bits sent for signal notification.

[0042] Figure 1 A schematic diagram of an example wireless communication network 100 is shown. Depending on some aspects, the wireless communication network 100 may include or refer to a wireless personal area network (WPAN), a wireless local area network (WLAN), or a Wi-Fi network. For example, the wireless communication network 100 may be a network implementing at least one of the IEEE 802.11 wireless communication protocol standard families (such as those defined by the IEEE 802.11-2020 specification or its revisions, including but not limited to 802.11ay, 802.11ax, 802.11az, 802.11ba, 802.11bc, 802.11bd, 802.11be, 802.11bf, and 802.11bn). In some other examples, the wireless communication network 100 may be an example of a cellular radio access network (RAN), such as a 5G RAN or 6G RAN implementing one or more cellular protocols (such as those specified in one or more 3GPP standards). In some other examples, the wireless communication network 100 may include a WLAN that operates in a manner interoperable with or converged with one or more cellular RANs to provide greater or enhanced network coverage to wireless communication devices within the wireless communication network 100, or to enable these devices to connect to the core of the cellular network, such as accessing network management capabilities and functionality provided by the cellular network core. In some other examples, the wireless communication network 100 may include a WLAN that operates in a manner interoperable with or converged with one or more personal area networks (PANs), such as networks implementing Bluetooth or other wireless technologies, to provide greater or enhanced network coverage or to provide or implement other capabilities, functionality, applications, or services.

[0043] Wireless communication network 100 may include numerous wireless communication devices, such as at least one wireless access point (AP) 102 and any number of wireless stations (STA) 104. Although Figure 1Only one AP 102 is shown, but the wireless communication network 100 may include multiple APs 102. AP 102 may be or represent various different types of network entities, including but not limited to home networking APs, enterprise APs, single-band APs, dual-band synchronous (DBS) APs, tri-band synchronous (TBS) APs, standalone APs, non-standalone APs, software-enabled APs (software APs), and multi-link APs (also known as AP multi-link devices (MLDs)), as well as cellular (such as 3GPP, 4G LTE, 5G, or 6G) base stations or other cellular network nodes (such as Node B, evolved Node B (eNB), gNB, Transmit Receive Point (TRP)) or another type of equipment or apparatus included in the radio access network (RAN), including open RAN (O-RAN) network entities such as central units (CUs), distributed units (DUs), or radio units (RUs).

[0044] Each STA 104 may also be referred to as a mobile station (MS), mobile device, mobile phone, wireless phone, access terminal (AT), user equipment (UE), subscriber station (SS), or subscriber unit, etc. STA 104 can represent a variety of devices such as mobile phones, other handheld or wearable communication devices, netbooks, laptops, tablets, laptops, Chromebooks, augmented reality (AR), virtual reality (VR), mixed reality (MR), or extended reality (XR) wireless headsets or other peripherals, wireless earbuds, other wearable devices, display devices (such as TVs, computer monitors, or video game consoles), video game controllers, navigation systems, music or other audio or stereo devices, remote control devices, printers, kitchen appliances (including smart refrigerators) or other home appliances, remote keys (such as those for passive keyless entry and start (PKES) systems), Internet of Things (IoT) devices, and vehicles, etc.

[0045] STA 104 can be an example of a central device (such as a source device) or an example of a peripheral device (such as a destination device) that implements WLAN communication (such as Wi-Fi communication) or Bluetooth communication. For example, a central device may include a cellular phone, UE, wireless STA, mobile station, personal digital assistant (PDA), other handheld device, netbook, laptop computer, tablet computer, laptop computer, broadcast device, or some other suitable term. Peripheral devices may include Bluetooth-enabled devices capable of pairing with other Bluetooth-enabled devices (such as the central device) or otherwise receiving unicast or broadcast Bluetooth communication, and may include wireless audio devices (such as headsets, earpieces, speakers, handsets, or headphones), display devices (such as televisions, glasses, or computer monitors), microphones, meters, or valves.

[0046] Bluetooth communication can refer to a short-range communication protocol and can be used to connect and exchange information between a central device and peripheral devices, such as mobile phones, computers, digital cameras, wireless headsets, speakers, keyboards, mice, or other input peripherals and similar devices. Bluetooth systems (such as aspects of wireless communication network 100) can be organized using a central-peripheral relationship employing a time-division duplex protocol with defined time slots of, for example, 625 microseconds, in which transmissions alternate between a central device (such as a source device) and one or more peripheral devices (such as a destination device). Therefore, in some examples, a device may be referred to as a central device or a peripheral device based on its Bluetooth role configuration. That is, designating a device as a central device or a peripheral device does not necessarily indicate a difference in device capabilities, but rather can refer to or indicate the role the device plays in wireless communication network 100. Generally, a central device can refer to a wireless communication device capable of wirelessly exchanging data signals with another device (such as a peripheral device), and a peripheral device can refer to a device operating in a peripheral device role, or a short-range wireless communication device capable of exchanging data signals with a central device (such as using the Bluetooth communication protocol).

[0047] Bluetooth-enabled devices are compatible with certain Bluetooth profiles to use the required services. A Bluetooth profile can refer to a specification about one aspect of Bluetooth-based wireless communication between devices. That is, a profile specification can refer to a set of instructions for using the Bluetooth protocol stack in a certain way and can include information such as a suggested user interface format or specific options and parameters at each layer of the Bluetooth protocol stack. For example, the Bluetooth specification can include various profiles defining the behavior associated with each communication endpoint to implement a specific use case. Therefore, profiles are generally defined according to a protocol stack that facilitates and allows interoperability between endpoint devices from different manufacturers by enabling applications to discover and use services that other nearby Bluetooth-enabled devices may be providing. The Bluetooth specification defines pairs of device roles (such as roles for a central device and peripheral devices) that together form a single use case called a profile (such as for communication between a central device and a peripheral device). An example profile defined in the Bluetooth specification is the Hands-free Profile (HFP) for voice telephony, where one device (such as a central device) implements the Audio Gateway (AG) role, and another device (such as a peripheral device) implements the Hands-free (HF) device role. Another example is the Advanced Audio Distribution Profile (A2DP) for high-quality audio streaming, where one device (such as a central device) implements the Audio Source Device (SRC) role, while another device (such as a peripheral device) implements the Audio Destination Device (SNK) role.

[0048] For a commercially available Bluetooth-enabled device to function correctly in a configuration file that implements a role, another device implementing the corresponding role may be within the radio range of the first device. For example, for an HF device (such as a Bluetooth headset) to function according to a hands-free configuration file, a device implementing the AG role (such as a cellular phone) may need to be within the radio range. Similarly, for a device implementing the SNK role (such as a Bluetooth headset or Bluetooth speaker) to stream high-quality mono or stereo audio according to A2DP, it may need to be within the radio range of a device implementing the SRC role (such as a stereo music player).

[0049] The Bluetooth specification defines a layered data transmission architecture and various protocols and procedures for handling data communicated between two devices implementing specific profile use cases. For example, various logical links can be used to support different application data transmission requirements, with each logical link associated with a logical transport having certain characteristics such as flow control, acknowledgment mechanisms, repetition mechanisms, sequence numbering, or scheduling behavior. The Bluetooth protocol stack can be divided into two parts: a controller stack that includes a timing-critical radio interface, and a host stack that handles high-level data. The controller stack is typically implemented in a low-cost silicon device comprising one or more Bluetooth radios and one or more microprocessors. The controller stack can be responsible for establishing direct wireless communication links¹¹O, such as asynchronous connectionless (ACL) links (or ACL connections), synchronous connection-oriented (SCO) links (or SCO connections), extended synchronous connection-oriented (eSCO) links (or eSCO connections), broadcast isochronous streams (BIS), connected isochronous streams (CIS), or other logical transport channel links.

[0050] In some examples, the controller stack may implement Link Management Protocol (LMP) functionality or Low-Power Link Layer (LELL) functionality. The host stack can typically be implemented as part of the operating system or as an installable package on top of the operating system. The host stack may be responsible for Logical Link Control and Adaptation Protocol (L2CAP) functionality, Bluetooth Network Encapsulation Protocol (BNEP) functionality, or Service Discovery Protocol (SDP) functionality. In some examples, the controller stack and host stack may communicate via a Host Controller Interface (HCI). In other examples (such as for integrated devices like Bluetooth headsets), the host stack and controller stack may run on the same microprocessor to reduce mass production costs. For such hostless systems, the HCI may be optional and may be implemented as an internal software interface.

[0051] A direct wireless communication link 110 can be established between two Bluetooth-enabled devices (such as between a central device and a peripheral device), and this direct wireless communication link can provide communication or services (e.g., according to a Bluetooth profile). For example, the Bluetooth connection could be an eSCO connection for voice calls (such as one that allows retransmissions) or an ACL connection for music streaming (such as A2DP), etc. For example, eSCO packets can be sent in predetermined time slots (such as six Bluetooth time slots each for eSCO). When establishing a Bluetooth link, a rule interval between eSCO packets can be specified. eSCO packets destined for / from a specific peripheral device (such as a peripheral device) are acknowledged and can be retransmitted during a retransmission window if unacknowledged. Furthermore, an ACL connection (A2DP profile) can be used to stream audio between the central device and the peripheral device. In some examples, an ACL connection can occupy one, three, or five Bluetooth time slots used for data or voice. Other Bluetooth profiles supported by Bluetooth-enabled devices may include Bluetooth Low Energy (BLE) (such as providing significantly reduced power consumption and cost while maintaining similar communication range) or Human Interface Device Profiles (HID) (such as providing low-latency links with low power requirements).

[0052] In some examples, the device may be capable of both Bluetooth and WLAN communication. For instance, the WLAN and Bluetooth components may co-located within the device, enabling it to communicate according to both Bluetooth and WLAN communication protocols, as each technology offers different benefits or improves the user experience under different conditions. In some examples, Bluetooth and WLAN communication may share the same medium, such as the same unlicensed frequency medium. In such examples, the central device may support WLAN communication via AP 102 (e.g., via communication link 106). AP 102 and the associated central device may represent a Basic Service Set (BSS) or an Extended Service Set (ESS). Various central devices in the network may be able to communicate with each other via AP 102. In some examples, AP 102 may be associated with a coverage area 108, which may represent a Basic Service Area (BSA).

[0053] In some examples, STA 104 can form a network without AP 102 or any other equipment besides STA 104 itself. An example of such a network is an ad hoc network (or wireless ad hoc network). Ad hoc networks may also be referred to as mesh networks or peer-to-peer (P2P) networks. In some examples, ad hoc networks can be implemented within a larger network, such as wireless communication network 100. In such examples, while STA 104 may be able to communicate with each other via communication link 106 through AP 102, STA 104 can also communicate directly with each other via direct wireless communication link 110. Additionally, two STA 104 can communicate via direct wireless communication link 110, regardless of whether the two STA 104 are associated with and served by the same AP 102. In such ad hoc systems, one or more STAs among STA 104 can assume the role played by AP 102 in the BSS. Such STA 104 can be referred to as the group owner (GO) and can coordinate transmissions within the ad hoc network. Examples of direct wireless communication links 110 include Bluetooth connections (such as CIS or BIS), Wi-Fi direct connections, connections established by using Wi-Fi Tunnel Direct Link Establishment (TDLS) links, and other P2P group connections.

[0054] In some networks, AP 102 or STA 104, or both, can support applications associated with high throughput or low latency requirements, or provide lossless audio to one or more other devices. For example, AP 102 or STA 104 can support applications and use cases associated with ultra-low latency (ULL), such as ULL gaming, or streaming lossless audio and video to one or more personal audio devices (such as peripherals) or AR / VR / MR / XR headsets. In scenarios where a user uses two or more peripherals, AP 102 or STA 104 can support extended personal audio networks that enable communication with these two or more peripherals. Additionally, AP 102 and STA 104 can support additional ULL applications with ULL and high throughput requirements, such as cloud-based applications (such as VR cloud gaming).

[0055] In some examples, the content, media, or audio exchanged between a central device (such as a broadcaster device) and peripheral devices may originate from a WLAN. For instance, in some examples, the central device may receive audio from AP 102 (e.g., via WLAN communication), and the central device may relay or transmit the audio to peripheral devices (e.g., via Bluetooth communication). In some examples, certain types of Bluetooth communication (such as high-quality or high-definition (HD) Bluetooth) may require enhanced Quality of Service (QoS). In some examples, latency-sensitive Bluetooth services may have a higher priority than WLAN services.

[0056] As indicated above, in some implementations, AP 102 and STA 104 may operate and communicate according to one or more of the IEEE 802.11 wireless communication protocol family of standards (via the corresponding communication link 106). These standards define WLAN radio and baseband protocols for the physical (PHY) layer and MAC layer. AP 102 and STA 104 send and receive wireless communications (hereinafter also referred to as “packets” or “wireless packets”) to each other in the form of PHY PDUs (PPDUs).

[0057] Each PPDU is a composite structure comprising a PHY preamble and a payload in the form of a PHY Service Data Unit (PSDU). The information provided in the preamble can be used by the receiving device to decode subsequent data in the PSDU. In Bluetooth communication, the communicating device can use a single-packet format for announcements and data transmission. The packet format may include a set of components, including a preamble (which can be 1 octet in length), an access address (which can be 4 octets in length), a PDU (which can be between 2 and 257 octets in length), and a Cyclic Redundancy Check (CRC) (which can be 3 octets in length).

[0058] AP 102 and STA 104 in wireless communication network 100 can transmit PPDUs on unlicensed spectrum such as 2.4 GHz, 5 GHz, 6 GHz, 45 GHz, and 60 GHz bands. Some examples of AP 102 and STA 104 described herein can also communicate in other frequency bands that can support both licensed and unlicensed communication. For example, AP 102 or STA 104, or both, can also be able to communicate on licensed operating frequency bands, where multiple operators may have corresponding licenses to operate in the same or overlapping frequency ranges. Such licensed operating frequency bands may be mapped to or associated with frequency ranges specified as follows: FR1 (410 MHz to 7.125 GHz), FR2 (24.25 GHz to 52.6 GHz), FR3 (7.125 GHz to 24.25 GHz), FR4a or FR4-1 (52.6 GHz to 71 GHz), FR4 (52.6 GHz to 114.25 GHz), and FR5 (114.25 GHz to 300 GHz). In some networks, Bluetooth communication can use the 2.4 GHz band, which can refer to the band from 2,400 MHz to 2,483.5 MHz.

[0059] Each of these frequency bands may include multiple sub-bands and frequency channels (also referred to as sub-channels). The terms "channel" and "sub-channel" may be used interchangeably herein, as each term may refer to a portion of the spectrum within the frequency band (such as a 20MHz, 40MHz, 80MHz, or 160MHz portion of the spectrum) through which communication between two or more wireless communication devices may occur. For example, a PPDU may be transmitted on one or more of the 2.4GHz, 5GHz, or 6GHz frequency bands, each band being divided into multiple channels (such as a 1MHz channel or a 2MHz channel for Bluetooth communication). AP 102 may determine or select an operational or operational bandwidth for STA 104 and select a series of channels within the frequency band to provide that operational bandwidth. In some aspects, Bluetooth communication may divide the transmitted data into packets and may transmit each packet on a designated Bluetooth channel of one of 79 designated Bluetooth channels. Each channel may have a bandwidth of 1MHz. A Bluetooth device may perform a certain number of frequency hopping per second, which may refer to how the Bluetooth device switches from transmitting via a first channel to transmitting via a second channel. In some respects, with Adaptive Frequency Hopping (AFH) enabled, Bluetooth devices can perform approximately 1,600 frequency hops per second. BLE can use a 2MHz interval, which can accommodate 40 channels.

[0060] Figure 2 A schematic diagram of another example wireless communication network 200 is shown. Depending on some aspects, the wireless communication network 200 may be an example of a Bluetooth network, mesh network, IoT network, or sensor network according to one or more of the IEEE 802.11 wireless communication protocol standard family. The wireless communication network 200 may include multiple wireless communication devices 214, which in some specific implementations may include an AP 202, a STA 204, or both. The wireless communication devices 214 may represent a variety of devices, such as display devices (e.g., televisions, computer monitors, navigation systems, glasses, etc.), music or other audio or stereo devices, remote control devices (“remote control” or “remote controller”), printers, kitchen appliances, or other household appliances, and other examples.

[0061] In some examples, wireless communication device 214 senses, measures, collects, or otherwise acquires and processes data, and transmits such raw or processed data to intermediate device 212 for further processing or distribution. Additionally or alternatively, intermediate device 212 may send control information, digital content (such as audio or video data), configuration information, or other instructions to wireless communication device 214. Intermediate device 212 and wireless communication device 214 may communicate with each other via wireless communication link 216. In some examples, wireless communication link 216 includes a Bluetooth link or other PAN or short-range communication link.

[0062] In some examples, intermediate device 212 may also be configured for wireless communication with other networks, such as WLANs or wireless (e.g., cellular) wide area networks (WWANs), which in turn provide access to external networks, including the Internet. For example, intermediate device 212 may associate and communicate with an AP 102 of wireless communication network 200 via Wi-Fi link 218, which may also serve various STAs 104. In some examples, intermediate device 212 is an example of a network gateway (e.g., an IoT gateway). In this way, intermediate device 212 may act as an edge bridge providing Wi-Fi core backhaul for an IoT network including wireless communication device 214. In some examples, intermediate device 212 may analyze, preprocess, and aggregate data received from the wireless communication device 214 locally at the edge via Wi-Fi link 218 before sending it to other devices or external networks. Intermediate device 212 may also provide additional security for the IoT network and the data it transmits.

[0063] In some respects, each of the various devices (such as one or more STA 104, one or more AP 102, one or more STA 204, one or more AP 202, one or more intermediate devices 212, one or more wireless communication devices 214, or any combination thereof) can communicate according to broadcast Bluetooth communication (such as LE broadcast ISO communication) and may be referred to herein as a broadcaster device (such as a broadcaster wireless communication device) or a peripheral device (such as a peripheral device wireless communication device). Broadcast Bluetooth communication may involve one or more BIS of a BIG. A BIS can be understood as a logical transmission that enables a device (such as an audio or display device) to transmit ISO data (framed or unframed). A BIS may support variable-sized packets and the transmission of one or more packets in each ISO event, which enables LE audio to support a range of data rates. A BIG may include a single BIS, or two or more BIS with the same ISO interval and expected to have a temporal relationship at the application layer. In the example of a broadcaster device providing broadcast data to three peripheral devices, the broadcaster device may use a first BIS to send to a first peripheral device, a second BIS to send to a second peripheral device, and a third BIS to send to a third peripheral device. In such examples, the BIG of a broadcaster device may include a first BIS, a second BIS, and a third BIS. In some networks, the maximum number of BIS within a BIG can be 31.

[0064] For each BIS within a BIG, there may be a scheduling of transmission slots (which may be referred to herein as events and sub-events). Each BIS event begins at the BIS anchor and ends after its last sub-event. Each BIG event begins at the BIG anchor and ends after a control sub-event, if present. If no control sub-event exists, the BIG event ends at the end of the last BIS sub-event (or the last BIS event). BIS sub-events enable the ISO broadcaster to transmit BIS PDUs and enable synchronized receivers (such as peripheral devices) to receive BIS PDUs. The broadcaster device's LL may transmit a BIS data PDU at the start of each sub-event of an ISO broadcast event. For each BIS event, the data source (broadcaster device) may transmit a data burst comprising a certain number of payloads, where such number is indicated by (and equal to) the burst number (BN). In some respects, the sub-events of each BIS event may be divided into groups of BN sub-events. Each BIG event may optionally include a control sub-event. If a control sub-event exists, the broadcaster's LL can send a single BIG control PDU at the start of the control sub-event to transmit control information associated with the BIG.

[0065] An ISO PDU (often referred to as a packet) may include a 16-bit header, a variable-size payload, and an optional Message Integrity Check (MIC) field. The format of the header and payload fields of an ISO PDU may be associated with the type of ISO PDU being used (e.g., transmitted). For example, when an ISO PDU is used on (e.g., transmitted via) a CIS or BIS, the ISO PDU may be a CIS PDU or a BIS PDU and may have a different format depending on whether the ISO PDU is a CIS PDU or a BIS PDU. A BIS PDU (also often referred to as a packet) may be a BIS data PDU or a BIG control PDU. A BIS data PDU may carry ISO data (which may be referred to as broadcast data), while a BIG control PDU may carry control information associated with the BIG (such as control data).

[0066] The header of a BIS PDU may include: a Link Layer (LL) Identifier (LLID) field, which indicates the type of content of the BIS PDU's payload; a CSTF field, which indicates whether a BIG control PDU is planned to be sent in a BIG event; a CSSN field (which may be called a sequence number field), which indicates the start of a BIG event including the first transmission of a new BIG control PDU; and a length field, which indicates the size (in octets) of the payload and MIC (if included). The LLID field may be 2 bits long, the CSSN field may be 3 bits long, the CSTF field may be 1 bit long, and the length field may be 8 bits long. In some networks, the header of a BIS PDU may also include 2 bits reserved for future use (RFU). These bits may be called RFU bits. If the BIS PDU is a BIG control PDU, the payload of the BIS PDU includes an opcode field (with a length of 1 octet) and a control data field (with a length between 0 and 250 octets). In some examples, when CSTF=1, the CSSN field can be associated with standard (such as specification-defined) purposes. If CSTF=1, the CSTF field indicates that a control sub-event exists after the last sub-event within the last BIS (BIG event). In such examples where CSTF=1, the CSSN field can indicate the sequence number of the control information (which may be referred to as BIGInfo) to be transmitted within (such as during) the control sub-event. Therefore, the CSSN number helps the receiver select whether to include the control sub-event. For example, if it is a CSSN belonging to the most recent past control information received by the peripheral device, the peripheral device may ignore the control sub-event (because the control sub-event includes control information that retransmits the same control information already received by the peripheral device).

[0067] For example, a broadcaster device may update a channel mapping (such as a set of frequencies for broadcasting) via a control sub-event, and accordingly, the broadcaster device may transmit control information with the updated channel mapping during the control sub-event. If the broadcaster device transmits the updated channel mapping for the first time, the broadcaster device may set CSSN=0 (in one or more media packets prior to the control sub-event). Peripheral devices may receive one or more media packets containing CSTF=1 and CSSN=0 (indicating that the sequence number of the control information to be transmitted in the upcoming control sub-event is 0). Peripheral devices may accordingly receive control information (such as information indicating the updated channel mapping) via the control sub-event. The broadcaster device may repeat the updated channel mapping multiple times (such as multiple control sub-events across multiple BIG events) to increase the likelihood that all peripheral devices will successfully receive the updated channel mapping. Peripheral devices may receive media packets again in one or more subsequent BIG events and may notice (such as determining, identifying, decoding, or parsing) CSTF=1 and CSSN=0. Therefore, peripheral devices may not turn on their receivers in the control sub-events of subsequent BIG events because the peripheral devices have already received the control information corresponding to CSSN=0.

[0068] If the broadcaster device updates the channel mapping again (such as a second updated channel mapping), the broadcaster device can set the header of the medium packet so that CSTF=1 and, for example, CSSN=1. In other words, the broadcaster device can increment CSSN by 1. If a peripheral device receives, decodes, or parses a medium packet with CSTF=1 and CSSN=1, the peripheral device can choose to listen for control information delivered via an upcoming control sub-event, since the control information will be new to the peripheral device.

[0069] In some LE Broadcast ISO networks, data services can be unidirectional from the broadcaster device (equivalently referred to as the broadcaster) to one or more peripheral devices. Therefore, in such networks, devices may lack feedback or acknowledgment protocols, which can make broadcast ISO services relatively unreliable (at least under certain channel conditions and compared to networks supporting bidirectional services). For example, some Bluetooth networks may lack a mechanism for the flow of control information from a broadcast receiver (such as a peripheral device) to the broadcaster. Furthermore, such Bluetooth networks may lack a mechanism for proprietary (such as manufacturer- or vendor-specific) control information flow from the broadcaster to one or more broadcast receivers. BIS can support multiple retransmissions to increase the reliability of packet communication (e.g., to compensate for the lack of acknowledgment protocols), but using multiple retransmissions may still be insufficient to support use cases where the exchange of control information between the broadcaster and one or more broadcast receivers (such as bidirectional exchange of control information) is expected or relied upon. Such use cases may include private, semi-private, public, or other local broadcasts (such as within home theaters or in-vehicle entertainment and information systems such as cars, tour buses, etc.).

[0070] According to some examples disclosed herein, the broadcaster device and one or more peripheral devices may support a signaling mechanism that coordinates whether a control sub-event is available for a specification-defined purpose or for vendor-specific (such as manufacturer-specific) communication and transmission direction within the control sub-event. For example, the broadcaster device may transmit one or more packets (such as BIS PDUs, such as BIS data PDUs) via one or more sub-events of a BIG event, and at least one of the packets (in some examples, each packet in the packet) may include an indication of whether an upcoming control sub-event of the BIG event is available for a specification-defined purpose or for vendor-specific communication. Such an indication may be delivered via, for example, a CSTF (which may be equivalently referred to as a CNTF). The CSTF (or CNTF) may be a transmission marker field used by the (broadcaster device's) LL to indicate whether a BIG control PDU is planned to be transmitted in a BIG event (such as in a BIG event that transmits a BIS data PDU including a CSTF).

[0071] In some implementations, broadcaster devices may set CSTF to 1 (CSTF=1) to indicate the presence of a control sub-event of a BIG event for specification-defined purposes, and may set CSTF to 0 (CSTF=0) to indicate the presence of a control sub-event for vendor-specific communication (rather than for specification-defined purposes). Packets (such as BIS data PDUs) may also include a sequence number field (such as a CSSN field), which is available for specification-defined purposes when CSTF=1, and may be unused (or in other words, lacking specification-defined purposes) when CSTF=0. Therefore, in some implementations, when CSTF=0, broadcaster devices and peripheral devices may use the sequence number field to transmit or parse (such as providing or obtaining) additional information associated with vendor-specific communication (because when CSTF=0, the device is not limited to using the sequence number field for specification-defined purposes).

[0072] In some examples, the broadcaster device can use a serial number field to indicate the direction of transmission of vendor-specific information between the broadcaster device and a peripheral device. For example, the first pattern of the serial number field can indicate that the transmission direction is from the broadcaster to the peripheral device, and the second pattern can indicate that the transmission direction is from the peripheral device to the broadcaster. (See reference) Figure 6 Illustrate and describe additional details related to this type of use of CSTF and serial number fields.

[0073] Broadcast devices and peripherals may support the interpretation of the CSTF and CSSN fields to indicate vendor-specific communication (e.g., if CSTF=0). In some examples, broadcast devices and peripherals may support such interpretation based on instructions from the manufacturer or vendor associated with the broadcast device (e.g., via PA). In such examples, if the peripheral is associated with the same manufacturer or vendor as the broadcast device, the peripheral may activate and adopt the interpretation. In some implementations, the broadcast device may further indicate its version number (via PA). Thus, the broadcast device may announce the manufacturer or vendor of the broadcast device and its version number. In such implementations, if the peripheral is associated with the same manufacturer or vendor as the broadcast device and if the broadcast device's version number is associated with support for the interpretation (e.g., if the broadcast device has a capability that indicates whether an upcoming control sub-event is associated with vendor-specific communication), the peripheral may activate and adopt the interpretation.

[0074] Broadcast equipment and one or more peripheral devices may utilize (such as adopt) such signaling mechanisms in one or more of the various example use cases. Such example use cases may include enabling one or more peripheral devices to provide control feedback to the broadcast equipment, enabling the broadcast system to synchronize host-based information between peripheral devices (e.g., in an in-vehicle media system, speakers receive media from an in-vehicle kit; in a home or office audio system, a television applies user-inputted volume settings to multiple speakers; or any other similar system), and enabling receivers (peripheral devices) to load with initial settings (such as the desired initial volume setting). Typically, the broadcast equipment and one or more peripheral devices may support LE broadcast control information flows used for synchronizing the ecosystem. Reference Figures 3 to 5 Additional details related to such example use cases are illustrated and described.

[0075] Figure 3 An example signaling diagram 300 is shown to support LE broadcast control information flow for synchronizing broadcaster devices and one or more peripheral devices. Signaling diagram 300 illustrates example use cases of some example embodiments of the example embodiments disclosed herein. For example, signaling diagram 300 illustrates broadcast communication from broadcaster device 302 to peripheral devices 304-a, 304-b, and 304-c via BIS 306-a, BIS 306-b, and BIS 306-c, respectively. The BIG of broadcaster device 302 may include BIS 306-a, BIS 306-b, and BIS 306-c. Although example signaling diagram 300 includes three peripheral devices, the described techniques are applicable to scenarios with any number of peripheral devices.

[0076] The broadcast device 302 may be an example of a STA 104, AP 102, STA 204, AP 202, intermediate device 212, or wireless communication device 214, as shown in the reference. Figure 1 and Figure 2 As illustrated and described. Each of peripheral devices 304-a, 304-b, and 304-c can be as follows: Figure 1 and 2 Examples of STA 104, AP 102, STA 204, AP 202, intermediate device 212, or wireless communication device 214 illustrated and described. Typically, broadcast device 302, peripheral device 304-a, peripheral device 304-b, and peripheral device 304-c can be examples of any Bluetooth-enabled device.

[0077] According to signaling diagram 300, peripheral device 304-a may provide (such as transmit) control information 308 to broadcaster device 302. This control information 308 may include feedback (such as control feedback, such as acknowledgment) or other information associated with a BIG supported by broadcaster device 302. In other words, according to some example implementations disclosed herein, broadcaster device 302 may provide a mechanism under which it can receive control information 308 from peripheral devices. In some examples, control information 308 may include channel assessment information obtained by peripheral device 304-a, such as via channel scanning or a poor channel assessment performed by peripheral device 304-a. In such examples, broadcaster device 302 may use the channel assessment information provided by peripheral device 304-a to select, determine, or identify the final channel mapping for broadcasting to peripheral device 304-a, peripheral device 304-b, peripheral device 304-c, or any combination thereof.

[0078] In some implementations, peripheral device 304-a may transmit control information 308 via packets (such as BIG control PDUs) during a control sub-event of a BIG event, based on an indication that the control sub-event is associated with vendor-specific information (such as information available to that vendor-specific information) and an indication that the transmission direction of the control sub-event is from the peripheral device to the broadcaster. In some aspects, broadcaster device 302 may provide such indication via one or more packets (such as one or more BIS data PDUs) transmitted prior to the control sub-event. For example, broadcaster device 302 may set the CSTF field bit to 0 and may indicate the transmission direction via a sequence number field (such as a CSSN field), as referenced. Figure 6 The examples are illustrated and described in more detail.

[0079] Figure 4 An example signaling diagram 400 is shown to support LE broadcast control information flow for synchronizing broadcaster devices and one or more peripheral devices. Signaling diagram 400 may illustrate example use cases of some example embodiments of the example embodiments disclosed herein. For example, signaling diagram 400 illustrates broadcast communication from broadcaster device 402 to peripheral devices 404-a, 404-b, 404-c, and 404-d via BIS 406-a, BIS 406-b, BIS 406-c, and BIS 406-d, respectively. The BIG of broadcaster device 402 may include BIS 406-a, BIS 406-b, BIS 406-c, and BIS 406-d. Although example signaling diagram 400 includes four peripheral devices, the described techniques are applicable to scenarios with any number of peripheral devices, such as seven.

[0080] The broadcast device 402 may be an example of a STA 104, AP 102, STA 204, AP 202, intermediate device 212, or wireless communication device 214, as shown in the reference. Figure 1 and Figure 2 As illustrated and described. Each of peripheral devices 404-a, 404-b, 404-c, and 404-d can be as follows: Figure 1 and 2 Examples of STA 104, AP 102, STA 204, AP 202, intermediate device 212, or wireless communication device 214 illustrated and described. In some deployment scenarios (such as the deployment scenario illustrated in example signaling diagram 400), peripheral devices 404-a, 404-b, 404-c, and 404-d may be examples of vehicle speakers. Additionally or alternatively, peripheral devices 404-a, 404-b, 404-c, and 404-d may be examples of vehicle displays or any other Bluetooth-enabled devices within a vehicle. In some deployment scenarios, broadcaster device 402 may be an example of an in-vehicle kit (or components thereof) equipped for providing in-vehicle entertainment or information systems, or any other Bluetooth-enabled device within a vehicle.

[0081] According to signaling diagram 400, peripheral device 404-d may provide (such as send) volume increase / decrease / mute indication 408 to broadcast device 402. For example, among multiple peripheral devices (such as speakers) receiving media from an in-vehicle kit within a vehicle, a passenger in the vehicle near peripheral device 404-d may be receiving a call via cellular phone and may wish to pause, mute, or reduce the volume of peripheral device 404-d and all other peripheral devices within the vehicle. In such an example, the passenger may press a volume decrease or pause / mute button on or associated with peripheral device 404-d (such as coupled to the peripheral device). Alternatively, the passenger may wish to increase the volume of all peripheral devices within the vehicle by pressing a volume increase button on or associated with peripheral device 404-d (such as coupled to the peripheral device). In some aspects, the user interface (UI) of peripheral device 404-d may provide the option to change the volume of only peripheral device 404-d (such as a local speaker) or to apply that change to all peripheral devices (or at least a subset thereof) (such as to all speakers within the vehicle). Such a subset of peripheral devices may include the peripheral devices closest to the passenger (and similarly, closest to peripheral device 404-d).

[0082] When a passenger selects to change the volume of all (or at least several) peripheral devices, peripheral device 404-d may send a volume increase / decrease / mute indication 408 to broadcast device 402. In some embodiments, peripheral device 404-d may send the volume increase / decrease / mute indication 408 via packets (such as BIG control PDUs) during a control sub-event. In such embodiments, peripheral device 404-d may send the volume increase / decrease / mute indication 408 via packets based on indications that the control sub-event is associated with vendor-specific information and indications that the control sub-event is associated with the transmission direction from the peripheral device to the broadcaster.

[0083] Upon receiving a volume increase / decrease / mute indication 408 from peripheral device 404-d via a control sub-event or some other signaling mechanism, broadcast device 402 may apply the control settings indicated by the volume increase / decrease / mute indication 408 to one or more other peripheral devices within the vehicle (such as applying to all (other) peripheral devices within the vehicle). In some embodiments, broadcast device 402 may send control information 410 indicating the control settings to peripheral devices during a control sub-event. In such embodiments, broadcast device 402 may send control information 410 via packets (such as BIG control PDUs) during a control sub-event based on indications of the control sub-event being associated with vendor-specific information and indications of the control sub-event being associated with the transmission direction from the broadcaster to the peripheral device.

[0084] In some respects, broadcaster device 402 may provide such indication of how to use an upcoming control sub-event via one or more packets (such as one or more BIS data PDUs) sent prior to the occurrence of the control sub-event. For example, broadcaster device 402 may set the CSTF field bit to 0 and may indicate the transmission direction via a sequence number field (such as a CSSN field), as referenced. Figure 6 As illustrated and described in more detail. According to signaling diagram 400, broadcaster device 402 can synchronize host-based (control) information between peripheral devices.

[0085] Figure 5An example signaling diagram 500 is shown to support LE broadcast control information flow for synchronizing broadcaster devices and one or more peripheral devices. Signaling diagram 500 illustrates some example use cases of specific implementations of the examples disclosed herein. For example, signaling diagram 500 shows broadcast communication from broadcaster device 502 to peripheral devices 504-a, 504-b, and 504-c via BIS 506-a, BIS 506-b, and BIS 506-c, respectively. The BIG of broadcaster device 502 may include BIS 506-a, BIS 506-b, and BIS 506-c. Although example signaling diagram 500 includes three peripheral devices, the described techniques are applicable to scenarios with any number of peripheral devices.

[0086] The broadcast device 502 may be an example of a STA 104, AP 102, STA 204, AP 202, intermediate device 212, or wireless communication device 214, as shown in the reference. Figure 1 and Figure 2 As illustrated and described. Each of peripheral devices 504-a, 504-b, and 504-c can be as follows: Figure 1 and 2 Examples of STA 104, AP 102, STA 204, AP 202, intermediate device 212, or wireless communication device 214 illustrated and described. In some deployment scenarios, broadcaster device 502 may be an example of TV broadcast (LE) ISO data, and peripheral devices 504-a, 504-b, and 504-c may be examples of speakers (such as, for example, room speakers in a home theater). Typically, broadcaster device 502, peripheral devices 504-a, 504-b, and 504-c may be examples of any Bluetooth-enabled device.

[0087] According to signaling diagram 500, broadcaster device 502 can broadcast to peripheral devices 504-a, 504-b, and 504-c, and a user can use remote control 508 (such as a TV remote control) to press volume up, down, or mute buttons. Based on receiving volume up / down / mute indication 510 from remote control 508, broadcaster device 502 can send control information 512 to the peripheral devices to apply the indicated settings to all peripheral devices or at least a subset thereof (e.g., all room speakers). In some embodiments, broadcaster device 502 can send control information 512 via packets (such as BIG control PDUs) during control sub-events. Broadcaster device 502 can send control information 512 via packets during control sub-events based on indications that the control sub-event is associated with vendor-specific information and indications that the control sub-event is associated with the transmission direction from the broadcaster to the peripheral devices.

[0088] Additionally or alternatively, broadcaster device 502 may utilize aspects of signaling diagram 500 to load one or more receivers (one or more of peripheral devices 504-a, peripheral device 504-b, and peripheral device 504-c) with initial settings (such as desired initial settings, such as desired initial volume settings). For example, if a user has changed settings (such as volume), and if peripheral devices 504-a, peripheral devices 504-b, and peripheral devices 504-c operate with a non-default setting (such as a non-default volume) according to the changed settings, and if at least one of peripheral devices 504-a, peripheral devices 504-b, and peripheral devices 504-c loses synchronization with broadcaster device 502 and subsequently resynchronizes, broadcaster device 502 may provide control information 512 to notify the resynchronized peripheral device to begin with the changed settings (such as the volume setting level previously changed by the user).

[0089] In some implementations, broadcaster device 502 may provide such control information 512 via packets (such as BIG control PDUs) during a control sub-event, based on indications that the control sub-event is associated with vendor-specific information and with the transmission direction from the broadcaster to peripheral devices. For example, to prevent resynchronized peripheral devices from starting with default values ​​(when a non-default value is now used according to a user command), which would require the user to press the volume up / down / mute buttons again to set the same (volume) level for a group of peripheral devices (in which case broadcaster device 502 may transmit an indication of the absolute volume level, rather than an indication of increase or decrease, to synchronize the group of peripheral devices to the same level), broadcaster device 502 may periodically send loading information (such as necessary loading information, such as volume level settings) via control sub-events. Therefore, broadcaster device 502 can utilize control sub-events associated with vendor-specific information to avoid user intervention, which improves the user experience. Broadcaster device 502 may periodically send such loading information at any time interval, such as approximately every half second, approximately every 1 second, or approximately every 2 seconds.

[0090] In some respects, broadcaster device 502 may provide such indication of how to use an upcoming control sub-event via one or more packets (such as one or more BIS data PDUs) sent prior to the occurrence of the control sub-event. For example, broadcaster device 502 may set the CSTF field bit to 0 and may indicate the transmission direction via a sequence number field (such as a CSSN field), as referenced. Figure 6 As illustrated and described in more detail. According to signaling diagram 500, broadcaster device 502 can synchronize host-based (control) information between peripheral devices.

[0091] Figure 6 An example communication timeline 600 is shown to support the flow of LE broadcast control information for synchronizing broadcaster devices and one or more peripheral devices. Communication timeline 600 may be implemented or be implemented to realize aspects of wireless communication network 100, wireless communication network 200, signaling diagram 300, signaling diagram 400, or signaling diagram 500. For example, broadcaster devices and one or more peripheral devices may communicate according to communication timeline 600, and such broadcaster devices and such peripheral devices may be those described herein (including references). Figures 1 to 5 Examples of the corresponding devices illustrated and described by ().

[0092] Communication timeline 600 includes BIG event 602 and BIS event 604 within BIG event 602. Typically, although in Figure 6 The example illustrates only a single BIS event 604, but a BIG event 602 may include multiple BIS events 604, with different BIS events 604 corresponding to or otherwise associated with different BIS events of a BIG associated with the BIG event 602. For example, a first BIS event 604 of the BIG event 602 may be associated with a first BIS, and a second BIS event 604 of the BIG event 602 may be associated with a second BIS. The first BIS event 604 and the second BIS event 604 may overlap in time, partially overlap in time, or not overlap in time. The BIG event 602 may be associated with a set of sub-events, each sub-event of the BIG event 602 corresponding to or associated with a BIS event 604. In some examples, both the BIG event 602 and the BIS event 604 may begin from a BIG anchor point. A BIS event 604 may include multiple sub-events, including sub-events 606-a, 606-b, and 606-c. BIG event 602 may optionally and additionally include control sub-event 606-d. In some implementations, control sub-event 606-d may exist regardless of whether the specification-defined BIG control PDU is scheduled for transmission during control sub-event 606-d. Conversely, control sub-event 606-d may exist according to other criteria (such as the absence of a specific default value or mode by the CSSN, or an all-zero mode indicating the absence of control sub-event 606-d), and when it exists, it may be used for specification-defined purposes or for vendor-specific communications, depending on signaling instructions. Control sub-event 606-d may exist after the last BIS event 604 of BIG event 602.

[0093] For example, the broadcaster device may send packet 608-a (first BIS data PDU) during sub-event 606-a, packet 608-b (second BIS data PDU) during sub-event 606-b, and packet 608-c (third BIS data PDU) during sub-event 606-c. At least one of packets 608-a, 608-b, and 608-c (in some examples, each) may indicate whether control sub-event 606-d is associated with vendor-specific communication. In some implementations, the packet may indicate whether control sub-event 606-d is associated with vendor-specific communication based on the setting of the CSTF field 610 of that packet. For example, if the CSTF field 610 is set such that CSTF=1, control sub-event 606-d may be interpreted or otherwise expected to be associated with a specification-defined purpose (through the broadcaster device and peripheral devices). If the CSTF field 610 is set such that CSTF=0, then control sub-event 606-d may be interpreted (via broadcaster devices and peripheral devices) or otherwise expected to be associated with vendor-specific communications, such as proprietary information or communications for proprietary purposes.

[0094] In a specific implementation where the CSTF bit is set to zero (making CSTF=0), the broadcaster device may use the sequence number field 612 (which may be an example of a CSSN field) to indicate or otherwise convey the purpose of control sub-event 606-d (to peripheral devices). In some aspects, to facilitate the use of the sequence number field 612 to indicate the purpose of control sub-event 606-d, the broadcaster device and peripheral devices may divide (e.g., split) the sequence number field 612 into multiple (e.g., two) parts. The first part of the sequence number field 612 may precede the second part of the sequence number field 612, and vice versa. For example, the first part may correspond to an initial set of one or more bits of the sequence number field 612, while the second part may correspond to a subsequent set of one or more bits of the sequence number field 612, and vice versa.

[0095] In some implementations, the first portion of the sequence number field 612 may define (e.g., indicate) the transmission direction 614 (e.g., the direction of information flow). In other words, the first portion may indicate whether the direction of information flow during control sub-event 606-d is broadcaster to peripheral device or peripheral device to broadcaster. Therefore, the transmission direction 614 may correspond to or indicate broadcaster to peripheral device or peripheral device to broadcaster. In some aspects, the size of the first portion of the sequence number field 612 may be 1 bit. In some examples, the first bit value of a single bit (e.g., bit value 0) may indicate that control sub-event 606-d is used for broadcaster to peripheral device information, and the second bit value of a single bit (e.g., bit value 1) may indicate that control sub-event 606-d is used for peripheral device to broadcaster information.

[0096] In some implementations, the second part of the sequence number field 612 may define (e.g., indicate) a sequence number 616. In some examples, the second part may indicate a sequence number 616 that is valid when the information flow (transmission direction 614) is from the broadcaster to the peripheral device, which allows the peripheral device to avoid receiving and decoding duplicate information from the broadcaster device. When the information flow is from the peripheral device to the broadcaster, the peripheral device may ignore the second part of the sequence number field 612. In some aspects, the size of the second part of the sequence number field 612 indicating the sequence number 616 may be 2 bits.

[0097] Additionally or alternatively, the second part may indicate a sequence number 616 that is valid when the information flow (transmission direction 614) is from the peripheral device to the broadcaster. This allows the peripheral device to indicate a sequence number 616 for a specific feedback, enabling the broadcaster device to avoid repeatedly acting on the feedback (ensuring the broadcaster avoids updating one or more communication parameters multiple times based on the same feedback information). For example, the peripheral device may use the sequence number field 612 within the BIG control PDU transmitted during a control sub-event (such as control sub-event 606-d) to indicate the sequence number 616 associated with control information sent by the peripheral device via the BIG control PDU. In other words, the control PDU from the peripheral device to the broadcaster device (BIG control PDU) may be configured with a CSSN, allowing the broadcaster device to identify retransmissions. The peripheral device may send the same control PDU a configurable number of times. In some implementations, the broadcaster device may (e.g., via PA) send configuration information indicating the configurable number of times the peripheral device may send the same control PDU.

[0098] Additionally or alternatively, in addition to other information related to the intended use of control sub-event 606-d, the sequence number field 612 may indicate, based on its bit pattern, whether the transmission direction 614 is broadcaster to peripheral device or peripheral device to broadcaster. For example, the first bit pattern of the sequence number field 612 (such as bit pattern "000") may indicate that control sub-event 606-d will not be used by the broadcaster device or peripheral device. As another example, the second bit pattern of the sequence number field 612 (such as bit pattern "001") may indicate that control sub-event 606-d is associated with the transmission direction 614 from peripheral device to broadcaster. As yet another example, the third bit pattern of the sequence number field 612 (such as bit pattern "010") may indicate that control sub-event 606-d is associated with the transmission direction 614 from broadcaster to peripheral device. Other bit patterns of the sequence number field 612 may be reserved or used to convey additional information related to the intended use of control sub-event 606-d.

[0099] In some examples, reserved values ​​in the CSSN may indicate that the broadcaster device will have more than one control sub-event. In some implementations, all two or more such control sub-events may be available for the broadcaster-to-peripheral transmission direction. In some other implementations, the initial control sub-event of these two or more control sub-events may be available for the broadcaster-to-peripheral transmission direction, and the remainder of these two or more control sub-events may be used by one or more peripheral devices to transmit to the broadcaster device. Typically, various meanings may be associated with specific bit patterns in the CSSN. Such meanings and their association with corresponding bit patterns in the CSSN may be signaled by the broadcaster device via control information associated with the BIG.

[0100] With CSTF field 610 set to make CSTF=0 and according to the indicated transmission direction 614, the broadcaster device or peripheral device may transmit packet 608-d (such as a BIG control PDU) during control sub-event 606-d. For example, if the indicated transmission direction 614 is broadcaster to peripheral device, the broadcaster device may transmit packet 608-d including control information (such as vendor-specific or proprietary information), and the peripheral device may monitor packet 608-d during control sub-event 606-d. Alternatively, if the indicated transmission direction 614 is peripheral device to broadcaster, the peripheral device may transmit packet 608-d including control information (such as feedback information or vendor-specific or proprietary information), and the broadcaster device may monitor packet 608-d during control sub-event 606-d. Reference Figure 7 Additional details relating to which of a potential plurality of peripheral devices may transmit during the control sub-event 606-d of BIG event 602 are illustrated and described.

[0101] The device transmitting packet 608-d may generate control information transmitted via packet 608-d at the host of the transmitting device or at the controller of the transmitting device, and according to the described technology, this control information flows from the receiver (peripheral device) to the broadcaster or from the broadcaster to the receiver. Therefore, the communication timeline 600 indicates the signaling mechanism for the flow of control information between the broadcaster and one or more broadcast receivers in LE ISO. Various different types of information may exist that can be transmitted or received using control sub-event 606-d, and in some implementations, packet 608-d within control sub-event 606-d may utilize a BIG control PDU structure, according to which the type of PDU is given (such as indicated by it) in the opcode field of packet 608-d. In the implementation where CSTF=0, the opcode field of packet 608-d may be a single octet or a double octet. Example BIG control PDU payload structures are illustrated in Table 1, as shown below.

[0102]

[0103] Table 1: Example BIG Control PDU Payload Format

[0104] For example, Table 2 illustrates another example BIG control PDU payload structure, as shown below. Typically, vendor-specific control groups can exist in various formats. As illustrated in the example BIG control PDU payload structure in Table 2, the format may indicate the presence of an initial set of fixed information (such as an opcode, company identifier (ID), or product ID), followed by the actual control information. In the example, the opcode may occupy bits 0 to 7, the company ID may occupy bits 8 to 23, and the product ID may occupy bits 24 to 39. A BIG control PDU may include one or more instances of control information. Each instance of control information may include sub-opcodes (such as codes specifying or indicating the content of the corresponding control information, such as the type, source, or purpose of the control information), an indication of the length of that instance of control information, and control information data. In the example, the first sub-opcode may occupy bits 40 to 47 (or typically a group of 8 bits), the first length indicator may occupy bits 48 to 55 (or typically a group of 8 bits), and the first instance of control information data may occupy a group of bits indicated by the first length indicator (such as a first number of octets).

[0105]

[0106] Table 2: Example BIG Control PDU Payload Format

[0107] Each sub-opcode may correspond to a different use case associated with control data (such as control information), where different sub-opcodes may correspond to different use cases. Furthermore, different sub-opcodes may correspond to different transmission directions. Some example use cases may include ping timeout indication, power control indication, skip indication, device type indication, channel classification indication, RSSI indication, power control request, PA parameter request, receive status indication, ping indication, address indication, pre-transmission offset (PTO) request, PTO indication, or PTO timeout indication, among other examples. In some examples, the sub-opcode or format associated with control information may indicate whether the control information (vendor-specific information) is specific to a particular BIS (or a particular set of BIS) or applicable to all BIS of the BIG.

[0108] The control data of the payload may be equivalently referred to as control information herein. In some specific implementations, the device sending packet 608-d may use (opcode, length, data) format in examples where the length may be variable, or otherwise use (opcode, data) format, to cascade multiple control information (such as multiple control information types) in a single control sub-event (such as control sub-event 606-d).

[0109] Some example information types may include controller-based information and host-based information. Controller-based information may include, for example, channel assessment information (so that controller-based information can be used when a peripheral device intends to transmit its channel assessment information). Host-based information may include information indicating, for example, user settings (such as increase / decrease / mute). In some implementations, the device transmitting packet 608-d may use the opcode of packet 608-d to indicate the information type (so that some (if not all) information types are defined using the opcode). In other words, each permutation of the bits of the opcode of the BIG control PDU (or any other set of bits, such as any other set of 8 bits) may correspond to the corresponding information type (the information type is channel assessment information, power information, volume information, etc.).

[0110] For host-based information, the device can utilize vendor-specific commands (also referred to herein as VS commands) and events (such as HCI VS LE BIS CTRL INFO). The device can also use (opcode, length, data) format in other ways, such as (opcode, data) format, in examples where the length can be variable, to cascade multiple control messages into a single VS command. In some implementations, the source of the host-based information can use vendor-specific commands to provide control information to the controller (of the device sending packet 608-d), and this control information can be passed to the other host using vendor-specific events (such as control sub-event 606-d).

[0111] In some implementations, the device sending packet 608-d may use the most significant bit (MSB) of the opcode or any other bit to distinguish between host-based and controller-based information. In such implementations, the device receiving packet 608-d can more easily distinguish between host-based and controller-based information, saving some processing at the controller level of the receiving device. In some examples, the opcode MSB with the first bit value (such as 0) may indicate controller-based information, and the opcode MSB with the second bit value (such as 1) may indicate host-based information. Table 3 illustrates examples of such use of the opcode MSB, as shown below.

[0112]

[0113] Table 3: Operation Codes (MSBs) Used to Indicate Host-Based and Controller-Based Information

[0114] Table 4 illustrates an example of an opcode table associated with packet 608-d in a specific implementation where packet 608-d carries controller-based information (such as link-related information, channel assessment information, or power information), as shown below. The information provided via such opcodes as illustrated in Table 4 is for illustrative purposes only and may not provide any such information, or may provide other additional information not shown, without exceeding the scope of this disclosure.

[0115]

[0116] Table 4: Operation Code Table for Controller-Based Information

[0117] Table 5 illustrates an example table of opcodes associated with packet 608-d in a specific implementation where packet 608-d carries host-based information, as shown below. The information provided via such opcodes as illustrated in Table 5 is for illustrative purposes only and may not be provided, or may be provided with other additional information not shown, without exceeding the scope of this disclosure.

[0118]

[0119] Table 5: Operation Code Table for Host-Based Information

[0120] Figure 7 An example communication timeline 700 supporting LE broadcast control information flow for synchronizing broadcaster devices and one or more peripheral devices is illustrated. Communication timeline 700 can be implemented or is implemented to realize aspects of wireless communication network 100, wireless communication network 200, signaling diagram 300, signaling diagram 400, signaling diagram 500, or communication timeline 600. For example, broadcaster devices and multiple peripheral devices can communicate according to communication timeline 700, and such broadcaster devices and such peripheral devices can be described herein (including references). Figures 1 to 6 Examples of the corresponding devices illustrated and described by ().

[0121] Communication timeline 700 includes BIG events 702-a, 702-b, and 702-c. BIG event 702-a may include one or more sub-events of BIS event 704-a, BIG event 702-b may include one or more sub-events of BIS event 704-b, and BIG event 702-c may include one or more sub-events of BIS event 704-c. Typically, BIG events 702-a, 702-b, and 702-c may include one or more BIS events, each BIS event corresponding to or associated with a different BIS of the BIG. For example, BIS event 704-a may include sub-events 706-a and 706-b, BIS event 704-b may include sub-events 706-d and 706-e, and BIS event 704-c may include sub-events 706-g and 706-h. BIG event 702-a may also include control sub-event 706-c, BIG event 702-b may also include control sub-event 706-f, and BIG event 702-c may also include control sub-event 706-i.

[0122] As illustrated in the example of communication timeline 700, the broadcaster device can communicate with at least three peripheral devices, including a first peripheral device (in... Figure 7 In the example, it is represented as peripheral device 1) and second peripheral device (in Figure 7 In the example, it is represented as peripheral device 2), and the third peripheral device (in Figure 7 In the example, it is represented as peripheral device 3). However, refer to Figure 7 The described technology is applicable to scenarios involving any number of two or more peripheral devices.

[0123] In some implementations, broadcaster equipment and peripheral devices may support a conflict avoidance scheme, under which multiple peripheral devices can avoid transmitting via the same control sub-event (if the control sub-event is associated with vendor-specific communication and the transmission direction from the peripheral device to the broadcaster). In some examples, peripheral devices can avoid conflicts based on rules or calculations (typically criteria) indicating when a peripheral device is allowed to transmit via a control sub-event. For example, such criteria could be: [the criteria are not specified in the provided text, but can be omitted]. Associated peripheral devices can send data during a BIG event based on the BIG event number associated with that BIG event. For example, if the modulo of "BIG event number" and "total number of BIS" is... Then, the peripheral device may transmit during the control sub-event of the BIG event (if the control sub-event is associated with vendor-specific communication and the transmission direction from the peripheral device to the broadcaster). (As used herein, "mod" can refer to a modulo operation between two values, such that "mod of X and Y" can be equivalently referred to as a modulo operation between X and Y. The mod of "BIG event number" and "total number of BIS" is equal to...) This can be understood as satisfying the requirements for being tuned to the BIS index. The criteria for peripheral devices (such as transmission criteria). As another example, if there are two BIS, a peripheral device tuned to the first BIS can transmit during the control sub-event of the even-numbered BIG event, and a peripheral device tuned to the second BIS can transmit during the control sub-event of the odd-numbered BIG event.

[0124] Therefore, in the example where the first peripheral device is associated with the first BIS, the second peripheral device is associated with a second BIS different from the first BIS, and the third peripheral device is associated with a third BIS different from both the first and second BIS, each of the three peripheral devices can transmit during the control sub-events of different BIS events. (For example, the first peripheral device can transmit packet 708-c (such as a first BIS control PDU) during the control sub-event 706-c of BIS event 702-a, the second peripheral device can transmit packet 708-f (such as a second BIS control PDU) during the control sub-event 706-f of BIS event 702-b, and the third peripheral device can transmit packet 708-i (such as a third BIS control PDU) during the control sub-event 706-i of BIS event 702-c. In other words, if the first peripheral device is tuned to the first BIS index...) If related, then the modulo of "BIG Event Number" and "Total Number of BIS" for BIG event 702 is... Similarly, if the second peripheral device is tuned to the second BIS with the second BIS index... Relatedly, the modulo of "BIG Event Number" and "Total Number of BIS" in BIG event 702-b is... Furthermore, if the third peripheral device is tuned to the third BIS and the third BIS index... If related, then the modulo of "BIG Event Number" and "Total Number of BIS" for BIG event 702-c is... .

[0125] In some aspects, the first peripheral device may send packet 708-c during control sub-event 706-c based on at least one of packet 708-a or packet 708-b (such as at least one BIS data PDU among the BIS data PDUs transmitted during BIG event 702-a) to indicate that control sub-event 706-c is associated with vendor-specific communication from the peripheral device to the broadcaster. Similarly, the second peripheral device may send packet 708-f during control sub-event 706-f based on at least one of packet 708-d or packet 708-e (such as at least one BIS data PDU among the BIS data PDUs transmitted during BIG event 702-b) to indicate that control sub-event 706-f is associated with vendor-specific communication from the peripheral device to the broadcaster. In addition, the third peripheral device may send packet 708-i during control sub-event 706-i based on at least one of packet 708-g or packet 708-h (such as at least one BIS data PDU among the BIS data PDUs transmitted during BIG event 702-c) to indicate that control sub-event 706-i is associated with vendor-specific communication from the peripheral device to the broadcaster.

[0126] In some deployment scenarios, two or more peripheral devices may be tuned to the same BIS and therefore to the same BIS index (same BIS number). In such scenarios, (based on mod= with "BIG event number" and "number of BIS") Two or more peripheral devices (with associated rules or calculations) tuned to the same BIS may attempt to transmit a control PDU (BIG control PDU) during the same BIG event. In some implementations, to address this possibility of conflict, peripheral devices may choose random backoff (RBO) based on the number of BIG events when (re)transmitting the control PDU. In such implementations, the probability that any two or more peripheral devices transmitting control PDUs during the same control sub-event is also retransmitting their respective control PDUs during the same control sub-event is relatively low, which improves the reliability of the peripheral-to-broadcast control information flow. For example, a first peripheral device and a second peripheral device may initially transmit a first control PDU and a second control PDU respectively during the same control sub-event, and based on the individual RBO selection for retransmission of their respective control PDUs (due to the possibility that the two peripheral devices may choose different RBOs), it is possible that second instances of the first control PDU and the second control PDU will be transmitted during different control sub-events.

[0127] In some aspects, the RBO range for peripheral devices can be selected (such as a range of 0 to 10, 0 to 15, or 0 to 20). In other aspects, the available RBO range can be related to the number of peripheral devices (potentially) tuned to the same BIS. For example, if a first number of peripheral devices are tuned to the same BIS, a first range of RBOs (such as 0 to 10) can be obtained, and if a second number of peripheral devices (more than the first number) are tuned to the same BIS, a second range of RBOs (such as 0 to 50) larger than the first range of RBOs can be obtained.

[0128] In some implementations, broadcaster equipment and peripheral audio devices may additionally or alternatively support energy-saving schemes to conserve power, which is particularly useful for broadcaster equipment (such as cellular phones) that is not powered by mains electricity (such as batteries). According to example energy-saving schemes, broadcaster equipment may selectively monitor control sub-events associated with vendor-specific communication (CSTF=0) (and the transmission direction from the peripheral device to the broadcaster). For example, broadcaster equipment may monitor (e.g., listen to) vendor-specific communication during a control sub-event of a BIG event, where the control sub-event is a multiple of a configured number (such as 1, 2, 3, or 4, etc.), or otherwise avoid monitoring the control sub-event. In some implementations, broadcaster equipment may send an indication of the multiple to the peripheral device via configuration information associated with the BIG (e.g., via PA). Such a multiple may be referred to herein as a BIG event number multiple. Accordingly, the peripheral device may mark individual BIG events during which the peripheral device is able (e.g., permitted) to send control information based on (e.g., taking into account or otherwise according to) a configured multiple.

[0129] Typically, a peripheral device can transmit when ("BIG event number" mod=0, "BIG event number multiple" mod=0, direction bit=1 (indicating the information flow from the peripheral device to the broadcaster), and CSTF=0. Satisfying "BIG event number" mod=0 can be interpreted as satisfying the peripheral device's criteria (such as transmission criteria). If the BIG event number multiple is set to, for example, equal to 4, the broadcaster device can listen to (e.g., monitor) control sub-events of BIG events with a multiple of 4, and when the direction bit (the first part of the sequence number field) is set to indicate the transmission direction from the peripheral device to the broadcaster. Otherwise, the broadcaster device can avoid monitoring control sub-events from the peripheral device for vendor-specific information. Similarly, when ("BIG event number" mod=0, "4", direction bit=1, and CSTF=0), the peripheral device can transmit control information via control sub-events. Otherwise, the peripheral device can avoid transmitting control information via control sub-events.

[0130] In examples where broadcast equipment and peripherals support both energy saving and collision avoidance, when "BIG event number" is divided by "BIG event number multiple" = (in When tuned to the BIS index Peripheral devices can send data. This satisfies the condition that "BIG event number" divided by "BIG event number multiple" = (in This can be understood as satisfying the requirements for tuning to the BIS index. The criteria for peripheral devices (such as transmission criteria). For example, if a broadcaster device is broadcasting three channels (including the first BIS, the second BIS, and the third BIS, making the total number of BIS equal to 3), and if the BIG event number multiple is set to equal to 4, then it is tuned to the index in the following cases. The first peripheral device of the first BIS can send control information: "BIG event number" divided by "4" = 1, 4, 7... (which can correspond to BIG event numbers 4, 16, 28, ...). For example, it is tuned to the index in the following cases. The second peripheral device of the second BIS can send control information: "BIG event number" divided by "4" = 2, 5, 8... (which can correspond to BIG event numbers 8, 20, 32...), and is tuned to the index in the following cases. The third peripheral device of the third BIS can send control information: "BIG event number" divided by "4" = 3, 6, 9... (which can correspond to BIG event numbers (12, 24, 36...).

[0131] In some implementations, peripheral devices can use RBO (Retransmission Based on the Number of BIG Events) to (re)transmit (based on the number of BIG events) to improve the reliability of the peripheral-to-broadcast information flow in scenarios where multiple peripheral devices can tune to the same BIS. A peripheral device can start an RBO counter from a BIG event during which it initially transmits control information (based on satisfied transmission criteria), or from a BIG event if the peripheral device satisfies criteria that allow it to transmit control information (if the peripheral device avoids transmission during the BIG event instead of waiting for the RBO counter to reach zero before performing the initial transmission).

[0132] Based on the selected RBO for (re)transmitting control information via a control sub-event, the peripheral device can count the number of BIG events equal to the selected RBO and selectively transmit control information via a control sub-event of the BIG event, where the number of counted BIG events equals the selected RBO. In some embodiments, the peripheral device can count BIG events that include control sub-events associated with the peripheral device-to-broadcaster information flow and avoid counting other BIG events (such that BIG events including control sub-events associated with the broadcaster-to-peripheral device information flow do not decrement the RBO counter or are otherwise not counted in the RBO). In some other embodiments, the peripheral device can count BIG events that include control sub-events associated with the peripheral device-to-broadcaster information flow and meet the peripheral device's criteria and avoid counting other BIG events. In some other embodiments, the peripheral device can count all BIG events, regardless of whether the BIG event is associated with the peripheral device-to-broadcaster information flow or the broadcaster-to-peripheral device information flow. Once the RBO counter reaches zero, the peripheral device can send during the control sub-event of the BIG event where the RBO counter reaches zero, or during the control sub-event of the next BIG event that satisfies the peripheral device's criteria (if the BIG event where the RBO counter reaches zero does not satisfy the criteria).

[0133] Figure 8 An example process flow 800 supporting LE broadcast control information flow for synchronizing broadcaster devices and one or more peripheral devices is illustrated. Process flow 800 may be implemented or be implemented to implement aspects of wireless communication network 100, wireless communication network 200, signaling diagram 300, signaling diagram 400, signaling diagram 500, communication timeline 600, or communication timeline 700. For example, process flow 800 illustrates communication between broadcaster device 802 and peripheral device 804, which may be described herein (including references). Figures 1 to 7 Examples of the corresponding devices illustrated and described by ().

[0134] In the following description of program flow 800, the operations between broadcaster device 802 and peripheral device 804 may be performed in a different order than shown, or additional operations may be added to or removed from program flow 800. For example, some operations may be omitted from process flow 800, or may be performed in a different order or at different times. Furthermore, although some operations or signaling are shown to occur at different times for discussion purposes, these operations may actually occur simultaneously. Although broadcaster device 802 and peripheral device 804 are shown performing operations of program flow 800, some aspects of some operations may also be performed by one or more other wireless communication devices.

[0135] At 806, broadcaster device 802 may send configuration information associated with the BIG to one or more peripheral devices, including peripheral device 804. The configuration information may indicate one or more parameters (and indicate one or more BISs of the BIG) associated with establishing, maintaining, operating, or communicating via the BIG. In some implementations, the configuration information may include an indication of a mapping between BIS indices and BIG events. Such a mapping may indicate the criteria (such as rules or calculations) upon which the BIS indices are mapped to BIG events, or it may indicate a mapping or correspondence table between BIS indices and BIG events. If, according to the mapping, a BIS index is mapped to a first BIG event, a peripheral device tuned to (such as associated with) the first BIS index (such as peripheral device 804) may potentially send control information via a control sub-event of the first BIG event. Additionally or alternatively, the configuration information may include an indication of a multiple of the BIG event number associated with vendor-specific communications. BIG event number multiples can be associated with energy-saving schemes and can help peripheral devices (such as peripheral device 804) to transmit according to criteria (such as limiting or making them more stringent) via control sub-events of a given BIG event. In some examples, broadcaster device 802 may transmit configuration information via PA.

[0136] At 808, the broadcaster device may transmit one or more first packets via one or more BIS of the BIG during one or more sub-events of the first BIG event. In some examples, the one or more first packets may be examples of BIS data packets transmitted via one or more (such as all) BIS events associated with one or more (such as all) BIS of the BIG. In some implementations, at least one of the one or more first packets (and in some examples, each or all of the packets) may indicate that a control sub-event of the first BIG event is associated with vendor-specific communication (such as communication that can be used for vendor-specific communication). For example, the CSTF field of at least one of the one or more first packets may be set to a bit value that indicates to peripheral device 804 that a control sub-event of the first BIG is associated with vendor-specific communication.

[0137] Furthermore, in some implementations, one or more first packets may include a sequence number field (such as a CSSN field) that indicates the direction of transmission for vendor-specific communication during a control sub-event. In some examples, the first bit pattern of the sequence number field indicates a transmission direction from broadcaster to peripheral device, and the second bit pattern of the sequence number field indicates a transmission direction from peripheral device to broadcaster. In some examples, a single bit of the sequence number field (such as an initial bit or a final bit) is set to a first or second bit value to indicate the transmission direction. In such examples, the remainder of the sequence number field (such as the remaining two bits of the sequence number field) may indicate a sequence number associated with control information to be transmitted via the control sub-event, may be used to convey additional information associated with the purpose of use of the control sub-event, or may be reserved (such as unused, such as depending on whether the transmission direction is from peripheral device to broadcaster).

[0138] At 810 or 812, the broadcaster device may communicate (such as send or receive) control information with one or more peripheral devices (including peripheral device 804) during a control sub-event, based on one or more first packets indicating that the control sub-event is associated with vendor-specific communication. In some examples, the control information may be transmitted via packets that include indications that the control information is associated with controller-based information or host-based information. The transmitting device may provide such indications via opcodes of the packets. In some implementations, such communication may be associated with (e.g., depending on) whether the indicated transmission direction associated with the control sub-event is broadcaster to peripheral device or peripheral device to broadcaster. If the indicated transmission direction is broadcaster to peripheral device, at 810, broadcaster device 802 may send control information to one or more peripheral devices (including peripheral device 804), and therefore peripheral device 804 may receive the control information. If the indicated transmission direction is peripheral device to broadcaster, at 812, peripheral device 804 may send control information to broadcaster device 802, and therefore broadcaster device 802 may receive the control information. Therefore, in some specific implementations, broadcaster device 802 and peripheral device 804 may support Bluetooth LE audio (and other use cases such as display, motion, or other data) broadcasting, in which broadcaster device 802 may receive data from one or more broadcast receivers without establishing a point-to-point connection (because the broadcast receivers may communicate with the broadcaster using control sub-events without establishing a point-to-point connection with the broadcaster).

[0139] In a specific implementation of the peripheral device 804 transmitting control information, the peripheral device 804 may determine, select, identify, or otherwise determine, based on the first BIS stream, that it will transmit control information during a control sub-event of the first BIG event. The peripheral device 804 is tuned to the first BIS stream corresponding to the first BIS index associated with the first BIG event. In other words, the peripheral device 804 may be associated with (e.g., tuned to) the first BIS corresponding to the first BIS index and may associate with the first BIG event based on the first BIS index, transmitting during the control sub-event of the first BIG event. In other words, according to the conflict avoidance scheme, the peripheral device 804 may avoid transmitting control information during a control sub-event of the BIG event, where the first BIS index is not associated with that control sub-event.

[0140] The first BIS index can be associated with the first BIG event according to a mapping (such as the mapping indicated in 806), which can take one or more of various forms. In some examples, the mapping can indicate that the first BIS index is associated with the first BIG event, based on the modulo operation between the BIG event number of the first BIG event and the total number of BIS within the BIG, which equals the first BIS index minus one. In other words, the peripheral device 804 can be associated with the first BIS index. Related, and can be calculated based on the mod= of "BIG event number" and "total number of BIS". Sending occurs during the first BIG event. In such examples, the BIS index... The mapping between BIG events and BIS events can be expressed as modulo 1, where BIG event number is the sum of the numbers in the BIS event and the total number of BIS events. Associated. Additionally or alternatively, the mapping may explicitly indicate the correspondence between BIS indices and BIG events (via, for example, a mapping or correspondence table). For example, the mapping may indicate that a first BIS index corresponds to a first BIG event number, a second BIS index corresponds to a second BIG event number, and so on (without requiring broadcaster device 802 or peripheral device 804 to use or perform any further calculations).

[0141] Additionally or alternatively, broadcast device 802 and peripheral device 804 may support energy-saving schemes associated with multiples of BIG event numbers. In such implementations, peripheral device 804 may send control information via a control sub-event of the first BIG event, based on the fact that the modulo operation between the BIG event number and a multiple of the BIG event number is zero. Broadcast device 802 may avoid monitoring control sub-events where the modulo operation between the BIG event number and a multiple of the BIG event number is not zero (e.g., when the modulo operation provides a number or value greater than zero). Reference Figure 7Additional details are described regarding such energy-saving solutions and combinations of energy saving and conflict avoidance.

[0142] At 814, the broadcaster device may transmit one or more second packets (such as one or more BIS data PDUs) via one or more BISs of the BIG and during one or more second sub-events of the second BIG event, based on control information. For example, the control information may include channel assessments performed by peripheral device 804, feedback information from peripheral device 804, indications for volume level settings, indications for mute settings, or any combination thereof, and the broadcaster device 802 may update, adjust, change, (re)configure, or otherwise adjust one or more communication parameters or packet content based on the control information, among other examples. For instance, if peripheral device 804 provides a channel assessment via the control information at 812, the broadcaster device 802 may update the channel mapping and which channels the broadcaster device 802 uses for broadcast communication based on the channel assessment received from peripheral device 804.

[0143] In some respects, the content of the control information and its impact on subsequent grouping may depend on (as associated with) the use cases or deployment scenarios involving broadcaster device 802 and peripheral device 804. Such use cases may include enabling one or more peripheral devices to provide control feedback to broadcaster device 802, enabling the broadcast system to synchronize host-based information among peripheral devices (e.g., in an in-vehicle media system, speakers receive media from an in-vehicle kit; in a home or office audio system, a television applies user-input volume settings to multiple speakers; or any other similar system), and enabling receivers (peripheral devices) to load with initial settings (such as the desired initial volume setting). Reference Figures 3 to 5 Additional details related to such example use cases are illustrated and described.

[0144] At 816, peripheral device 804 may send a second packet (such as a BIG control PDU) and broadcaster device 802 may receive the second packet, which includes a retransmission of control information from peripheral device 804. For example, peripheral device 804 may send control information at 812 during a first control sub-event of a first BIG event and may retransmit the control information at 816 during a second control sub-event of a second BIG event. In some implementations, peripheral device 804 may retransmit control information during a second BIG event based on an RBO selected from the first BIG event. In some examples, the second packet may include a sequence number field (such as a CSSN field) indicating a sequence number associated with the control information. In such examples, broadcaster device 802 may parse the sequence number field and determine, based on the sequence number associated with the control information, whether broadcaster device 802 has (successfully) received a previous version of the same control information, or whether broadcaster device 802 has not (successfully) received a previous version of the same control information. Broadcast device 802 can avoid taking action on any duplicate control information received from peripheral device 804 (such as duplicate control information based on serial number) because broadcast device 802 can expect to have taken relevant action on the first instance of control information.

[0145] Furthermore, although described in the context of exchanging control information via control sub-events of the BIG event, broadcaster device 802 and peripheral device 804 may additionally or alternatively utilize one or more other signaling mechanisms to facilitate bidirectional control information flow between the broadcaster and the broadcast receiver. In some specific implementations, for example, broadcaster device 802 may use PA to broadcast control information to one or more peripheral devices (including peripheral device 804), and peripheral device 804 may use PA responses to send control information from peripheral device 804 to broadcaster device 802. In such specific implementations, peripheral device 804 may send a PA response to an inter-frame interval (IFS) after receiving a PA packet from broadcaster device 802, which may also be referred to as time TIFS (or time T). IFSIn some examples, broadcaster device 802 may use the RFU bit in the PA header to indicate whether vendor-specific information is ready to be sent from broadcaster device 802 to a peripheral device in the TIFS following the PA, or whether the TIFS following the interval is to be used (e.g., available) by a peripheral device (such as peripheral device 804) to be sent to broadcaster device 802. In other words, broadcaster device 802 and peripheral device 804 (potentially other peripheral devices, etc.) may use a PA with a response (PAWR) to broadcast control information and use the PA response to receive control information from a broadcast receiver. If the PAWR indicates that vendor-specific information to be sent from broadcaster device 802 to a peripheral device in the TIFS following the PA is ready, the peripheral device may avoid sending a PA response and instead monitor the vendor-specific information.

[0146] Figure 9 A block diagram of an example wireless communication device 900 supporting LE broadcast control information flow for synchronizing broadcaster devices and one or more peripheral devices is shown. In some examples, the wireless communication device 900 is configured to perform separate references Figure 11 and Figure 12 The processes 1100 and 1200 are described. Wireless communication device 900 may include one or more chips, SoCs, chipsets, packages, components, or devices that individually or collectively constitute or include a processing system. The processing system may interface with other components of wireless communication device 900 and typically processes information (such as inputs or signals) received from and outputs information (such as outputs or signals) to such other components. In some aspects, an example chip may include a processing system, a first interface for outputting or transmitting information, and a second interface for receiving or acquiring information. For example, the first interface may refer to an interface between the chip's processing system and a transmitting component, enabling wireless communication device 900 to transmit information output from the chip. In such examples, the second interface may refer to an interface between the chip's processing system and a receiving component, enabling wireless communication device 900 to receive information passed to the processing system. In some such examples, the first interface may also, for example, acquire information from the transmitting component, and the second interface may also, for example, output information to the receiving component.

[0147] The processing system of the wireless communication device 900 includes processor (or “processing”) circuitry in the form of one or more processors, microprocessors, processing units (such as a central processing unit (CPU), graphics processing unit (GPU), neural processing unit (NPU) (also referred to as a neural network processor or deep learning processor (DLP)) or digital signal processor (DSP)), processing blocks, application-specific integrated circuits (ASICs), programmable logic devices (PLDs) (such as field-programmable gate arrays (FPGAs)), or other discrete gate or transistor logic components or circuits (all of which are generally referred to herein individually as “processors” or collectively as “processors” or “processor circuitry”). One or more of these processors may be individually or collectively configured to perform the various functions or operations described herein. The processing system may also include memory circuitry in the form of one or more memory devices, memory blocks, memory elements, or other discrete gate or transistor logic components or circuitry, each of which may include tangible storage media such as random access memory (RAM) or read-only memory (ROM) or combinations thereof (all of which are generally referred to herein individually as “memory” or collectively as “memory” or “memory circuitry”). One or more of these memories may be coupled to one or more processors and may store, individually or collectively, processor-executable code that, when executed by one or more processors, configures one or more processors to perform the various functions or operations described herein. Additionally or alternatively, in some examples, one or more processors may be pre-configured to perform the various functions or operations described herein without software configuration. The processing system may also include one or more modems (such as a Bluetooth modem, a Wi-Fi (e.g., IEEE compliant) modem, or a cellular (e.g., 3GPP 4G LTE, 5G, or 6G compliant) modem) or coupled to such modems. In some embodiments, one or more processors of the processing system include or implement one or more modems. The processing system may also include or be coupled to multiple radio components (collectively, “radio components”), multiple RF chains, or multiple transceivers, each of which may in turn be coupled to one or more antennas. In some embodiments, one or more processors of the processing system include or implement one or more of the radio components, RF chains, or transceivers.

[0148] In some examples, the wireless communication device 900 may be configurable or configurable to broadcast to a device (such as a reference device). Figures 1 to 8The wireless communication device 900 is used in the described broadcaster device. In some other examples, the wireless communication device 900 may be a broadcaster device including this processing system and other components including multiple antennas. The wireless communication device 900 is capable of transmitting and receiving wireless communications, for example, in the form of wireless packets. For example, the wireless communication device 900 may be configurable or can be configured to transmit and receive packets in the form of PDUs conforming to one or more of the Bluetooth protocol or the IEEE 802.11 wireless communication protocol standard family. In some other examples, the wireless communication device 900 may be configurable or can be configured to transmit and receive signals and communications conforming to one or more 3GPP specifications, including those for 5G NR or 6G. In some examples, the wireless communication device 900 also includes one or more application processors or may be coupled to one or more application processors, which may also be coupled to one or more other memories. In some examples, the wireless communication device 900 also includes at least one external network interface coupled to the processing system, which enables communication with a core network or backhaul network that allows the wireless communication device 900 to access external networks, including the Internet.

[0149] Wireless communication device 900 includes a BIG data component 925, a BIG control component 930, and a BIG configuration component 935. A portion of one or more of the BIG data component 925, BIG control component 930, and BIG configuration component 935 may be implemented at least partially in hardware or firmware. For example, one or more of the BIG data component 925, BIG control component 930, and BIG configuration component 935 may be implemented at least partially by at least a processor or modem. In some examples, a portion of one or more of the BIG data component 925, BIG control component 930, and BIG configuration component 935 may be implemented at least partially by a processor and software in the form of processor-executable code stored in memory.

[0150] According to the examples disclosed herein, wireless communication device 900 may support wireless communication. BIG data component 925 is configurable or configured to transmit one or more first packets indicating that a control sub-event of the first BIG event is associated with vendor-specific communication via a set of multiple BISs of the BIG, and during one or more first sub-events of a first BIG event. BIG control component 930 is configurable or configured to communicate control information with one or more peripheral devices during a control sub-event based on one or more first packets indicating that a control sub-event is associated with vendor-specific communication.

[0151] In some examples, the BIG data component 925 is configurable or configured to transmit one or more second packets via the group of BIG data and according to control information during one or more second sub-events of the second BIG event.

[0152] In some examples, one or more first packets also include a sequence number field. In some examples, the sequence number field indicates the direction of transmission of control information between the broadcaster device and one or more peripheral devices based on one or more first packets that indicate the association of a control sub-event with vendor-specific communication.

[0153] In some examples, the first bit of the sequence number field indicates that the transmission direction is from the broadcaster to the peripheral device, and the second bit of the sequence number field indicates that the transmission direction is from the peripheral device to the broadcaster.

[0154] In some examples, to support the communication of control information with one or more peripheral devices, the BIG control component 930 is configurable or configured to send control information to one or more peripheral devices based on a serial number field including a first bit pattern. In some examples, to support the communication of control information with one or more peripheral devices, the BIG control component 930 is configurable or configured to receive control information from one of the one or more peripheral devices based on a serial number field including a second bit pattern.

[0155] In some examples, the sequence number field consists of three bits. In some examples, the first bit indicates whether the transmission direction is from the broadcaster to the peripheral device or from the peripheral device to the broadcaster. In some examples, the remaining bits indicate a sequence number, which is valid depending on whether the first bit indicates the transmission direction is from the broadcaster to the peripheral device.

[0156] In some examples, to support the communication of control information with one or more peripheral devices, the BIG control component 930 is configurable or configured to receive packets containing control information from a first peripheral device among one or more peripheral devices during a control sub-event, based on the transmission direction and the BIG event number corresponding to the first BIG event.

[0157] In some examples, the first peripheral device is associated with a first BIS corresponding to a first BIS index among a group of multiple BISs. In some examples, the first BIS index is associated with a first BIG event. In some examples, packets received from the first peripheral device during a control sub-event of the first BIG event are associated with the first BIG event based on the first BIS index.

[0158] In some examples, the modulo operation between the BIG event number and the number of BIS in the group equals the first BIS index minus one, and the first BIS index is associated with the first BIG event.

[0159] In some examples, the BIG configuration component 935 is configurable or configured to send an indication of a mapping between BIS indices and BIG events via configuration information associated with the BIG, wherein a first BIS index is associated with a first BIG event according to the mapping.

[0160] In some examples, the BIG control component 930 is configurable or configured to receive a second packet including retransmissions of control information from a first peripheral device during a second control sub-event of a second BIG event, wherein the second BIG event is associated with a random backoff relative to the first BIG event.

[0161] In some examples, the grouping includes a second serial number field that indicates the serial number associated with the control information.

[0162] In some examples, the BIG configuration component 935 is configurable or configured to send an indication of a multiple of the BIG event number associated with a vendor-specific communication via configuration information associated with the BIG, wherein the modulo operation between the BIG event number and the multiple of the BIG event number is equal to zero.

[0163] In some examples, the BIG control component 930 is configurable or can be configured to avoid monitoring vendor-specific communications during a controlled sub-event of a BIG event, wherein the modulo operation between the BIG event number corresponding to the BIG event and a multiple of the BIG event number equals a number greater than zero.

[0164] In some examples, to support the communication of control information with one or more peripheral devices, the BIG control component 930 is configurable or configured to communicate packets including control information, wherein the packets also include indications of the association of the control information with controller-based information or host-based information.

[0165] In some examples, the opcodes for grouping include indications that control information is associated with controller-based information or host-based information.

[0166] In some examples, control information includes channel assessments performed by one or more peripheral devices, feedback information from one or more peripheral devices, indications for volume level settings, indications for mute settings, or any combination thereof.

[0167] Figure 10A block diagram of an example wireless communication device 1000 supporting LE broadcast control information flow for synchronizing broadcaster devices and one or more peripheral devices is shown. In some examples, the wireless communication device 1000 is configured to perform separate references Figure 13 and Figure 14 The processes 1300 and 1400 are described. Wireless communication device 1000 may include one or more chips, SoCs, chipsets, packages, components, or devices that individually or collectively constitute or include a processing system. The processing system may interface with other components of wireless communication device 1000 and typically processes information (such as inputs or signals) received from and outputs information (such as outputs or signals) to such other components. In some aspects, an example chip may include a processing system, a first interface for outputting or transmitting information, and a second interface for receiving or acquiring information. For example, the first interface may refer to an interface between the chip's processing system and a transmitting component, enabling wireless communication device 1000 to transmit information output from the chip. In such examples, the second interface may refer to an interface between the chip's processing system and a receiving component, enabling wireless communication device 1000 to receive information passed to the processing system. In some such examples, the first interface may also, for example, acquire information from the transmitting component, and the second interface may also, for example, output information to the receiving component.

[0168] The processing system of the wireless communication device 1000 includes processor (or “processing”) circuitry in the form of one or more processors, microprocessors, processing units (such as a central processing unit (CPU), graphics processing unit (GPU), neural processing unit (NPU) (also referred to as a neural network processor or deep learning processor (DLP)) or digital signal processor (DSP)), processing blocks, application-specific integrated circuits (ASICs), programmable logic devices (PLDs) (such as field-programmable gate arrays (FPGAs)), or other discrete gate or transistor logic components or circuits (all of which are generally referred to herein individually as “processors” or collectively as “processors” or “processor circuitry”). One or more of these processors may be individually or collectively configured to perform the various functions or operations described herein. The processing system may also include memory circuitry in the form of one or more memory devices, memory blocks, memory elements, or other discrete gate or transistor logic components or circuitry, each of which may include tangible storage media such as random access memory (RAM) or read-only memory (ROM) or combinations thereof (all of which are generally referred to herein individually as “memory” or collectively as “memory” or “memory circuitry”). One or more of these memories may be coupled to one or more processors and may store, individually or collectively, processor-executable code that, when executed by one or more processors, configures one or more processors to perform the various functions or operations described herein. Additionally or alternatively, in some examples, one or more processors may be pre-configured to perform the various functions or operations described herein without software configuration. The processing system may also include one or more modems (such as a Bluetooth modem, a Wi-Fi (e.g., IEEE compliant) modem, or a cellular (e.g., 3GPP 4G LTE, 5G, or 6G compliant) modem) or coupled to such modems. In some embodiments, one or more processors of the processing system include or implement one or more modems. The processing system may also include or be coupled to multiple radio components (collectively, “radio components”), multiple RF chains, or multiple transceivers, each of which may in turn be coupled to one or more antennas. In some embodiments, one or more processors of the processing system include or implement one or more of the radio components, RF chains, or transceivers.

[0169] In some examples, the wireless communication device 1000 may be configurable or configurable for use in peripheral devices such as broadcast receivers, such as references. Figures 1 to 8The described peripheral device. In some other examples, the wireless communication device 1000 may be a peripheral device including this processing system and other components including multiple antennas. The wireless communication device 1000 is capable of transmitting and receiving wireless communications, for example, in the form of wireless packets. For example, the wireless communication device 1000 may be configurable or can be configured to transmit and receive packets in the form of PDUs conforming to one or more of the Bluetooth protocol or the IEEE 802.11 wireless communication protocol standard family. In some other examples, the wireless communication device 1000 may be capable of being configured or can be configured to transmit and receive signals and communications conforming to one or more 3GPP specifications, including those for 5G NR or 6G. In some examples, the wireless communication device 1000 also includes one or more application processors or may be coupled to one or more application processors, which may also be coupled to one or more other memories. In some examples, the wireless communication device 1000 also includes a UI (such as a touchscreen or keypad) and a display, which may be integrated with the UI to form a touchscreen display coupled to the processing system. In some examples, the wireless communication device 1000 may also include one or more sensors, such as one or more inertial sensors, accelerometers, temperature sensors, pressure sensors, or altitude sensors coupled to the processing system.

[0170] The wireless communication device 1000 includes a BIG data component 1025, a BIG control component 1030, and a BIG configuration component 1035. A portion of one or more of the BIG data component 1025, BIG control component 1030, and BIG configuration component 1035 may be implemented at least partially in hardware or firmware. For example, one or more of the BIG data component 1025, BIG control component 1030, and BIG configuration component 1035 may be implemented at least partially by at least a processor or modem. In some examples, a portion of one or more of the BIG data component 1025, BIG control component 1030, and BIG configuration component 1035 may be implemented at least partially by a processor and software in the form of processor-executable code stored in memory.

[0171] According to the examples disclosed herein, wireless communication device 1000 may support wireless communication. BIG data component 1025 is configurable or configured to receive one or more first packets via the BIG's BIS and during one or more first sub-events of a first BIG event, the one or more first packets indicating that a control sub-event of the first BIG event is associated with vendor-specific communication. BIG control component 1030 is configurable or configured to communicate control information to broadcaster devices during a control sub-event based on one or more first packets indicating that a control sub-event is associated with vendor-specific communication.

[0172] In some examples, the BIG data component 1025 is configurable or configured to receive one or more second packets via the BIG's BIS and during one or more second sub-events of the second BIG event, based on control information.

[0173] In some examples, one or more first packets also include a sequence number field. In some examples, the sequence number field indicates the direction of transmission of control information between the broadcaster device and the peripheral device based on one or more first packets that indicate the association of a control sub-event with vendor-specific communication.

[0174] In some examples, the first bit of the sequence number field indicates that the transmission direction is from the broadcaster to the peripheral device, and the second bit of the sequence number field indicates that the transmission direction is from the peripheral device to the broadcaster.

[0175] In some examples, to support the communication of control information with the broadcaster device, the BIG control component 1030 is configurable or configured to receive control information from the broadcaster device based on a serial number field including a first bit pattern. In some examples, to support the communication of control information with the broadcaster device, the BIG control component 1030 is configurable or configured to send control information to the broadcaster device based on a serial number field including a second bit pattern.

[0176] In some examples, the sequence number field consists of three bits. In some examples, the first bit indicates whether the transmission direction is from the broadcaster to the peripheral device or from the peripheral device to the broadcaster. In some examples, the remaining bits indicate a sequence number, which is valid depending on whether the first bit indicates the transmission direction is from the broadcaster to the peripheral device.

[0177] In some examples, in order to support the communication of control information with broadcaster devices, the BIG control component 1030 is configurable or configured to send packets including control information according to the transmission direction and according to the BIG event number corresponding to the first BIG event during a control sub-event of the first BIG event.

[0178] In some examples, the BIS corresponds to the BIS index. In some examples, the BIS index is associated with the first BIG event. In some examples, packets are sent during a control sub-event of the first BIG event, associated with the first BIS index.

[0179] In some examples, the modulo operation between the BIG event number and the number of a set of multiple BISs of the BIG equals the BIS index minus one, and the BIS index is associated with the first BIG event.

[0180] In some examples, the BIG configuration component 1035 is configurable or configured to receive an indication of a mapping between a BIS index and a BIG event via configuration information associated with the BIG, wherein the BIS index is associated with a first BIG event according to the mapping.

[0181] In some examples, the BIG control component 1030 is configurable or configured to send a second packet including control information during a second control sub-event of a second BIG event, wherein the second BIG event is associated with random backoff relative to the first BIG event.

[0182] In some examples, the grouping includes a second serial number field that indicates the serial number associated with the control information.

[0183] In some examples, the BIG configuration component 1035 is configurable or configured to receive an indication of a BIG event number multiple associated with vendor-specific communication via configuration information associated with BIG, wherein the modulo operation between the BIG event number and the BIG event number multiple equals zero.

[0184] In some examples, the BIG control component 1030 is configurable or configured to avoid sending during a control sub-event of a BIG event, wherein the modulo operation between the BIG event number corresponding to the BIG event and a multiple of the BIG event number equals a number greater than zero.

[0185] In some examples, to support the communication of control information with broadcaster devices, the BIG control component 1030 is configurable or configured to communicate packets including control information, wherein the packets also include indications of the association of the control information with controller-based information or host-based information.

[0186] In some examples, the opcodes for grouping include indications that control information is associated with controller-based information or host-based information.

[0187] In some examples, control information includes channel assessments performed by peripheral devices, feedback information from peripheral devices, indications for volume level settings, indications for mute settings, or any combination thereof.

[0188] Figure 11 A flowchart illustrating an example process 1100 that can be executed by or at a broadcaster device supporting the flow of LE broadcast control information for synchronizing broadcaster devices and one or more peripheral devices is shown. As described herein, the operation of process 1100 can be implemented by the broadcaster device or its components. For example, process 1100 can be implemented by a wireless communication device operating as a broadcaster device or operating within a broadcaster device (such as reference _____). Figure 9The described wireless communication device 900) performs this process. In some examples, process 1100 may be performed by a broadcaster device (such as a reference 900). Figures 1 to 8 The broadcaster device described is used to perform this.

[0189] In some examples, at 1105, the broadcaster device may transmit one or more first packets, indicating that a control sub-event of the first BIG event is associated with vendor-specific communication, via a set of multiple BIS of the BIG and during one or more first sub-events of the first BIG event. Operation of 1105 may be performed according to examples as disclosed herein. In some specific implementations, aspects of operation of 1105 may be as described in references... Figure 9 The BIG data component 925 described is executed.

[0190] In some examples, at 1110, the broadcaster device may communicate control information with one or more peripheral devices during a control sub-event based on one or more first packets associated with vendor-specific communications indicating the control sub-event. Operation of 1110 may be performed according to examples as disclosed herein. In some specific implementations, aspects of the operation of 1110 may be as described in references... Figure 9 The BIG control component 930 described is executed.

[0191] Figure 12 A flowchart illustrating an example process 1200 that can be executed by or at a broadcaster device supporting the flow of LE broadcast control information for synchronizing broadcaster devices and one or more peripheral devices is shown. As described herein, the operation of process 1200 can be implemented by the broadcaster device or its components. For example, process 1200 can be implemented by a wireless communication device operating as a broadcaster device or operating within a broadcaster device (such as reference _____). Figure 9 The described wireless communication device 900) performs this process. In some examples, process 1200 may be performed by a broadcaster device (such as a reference 900). Figures 1 to 8 The broadcaster device described is used to perform this.

[0192] In some examples, at 1205, the broadcaster device may transmit one or more first packets, indicating that a control sub-event of the first BIG event is associated with vendor-specific communication, via a set of multiple BIS of the BIG and during one or more first sub-events of the first BIG event. Operation of 1205 may be performed according to examples as disclosed herein. In some specific implementations, aspects of the operation of 1205 may be as described in references... Figure 9 The BIG data component 925 described is executed.

[0193] In some examples, at 1210, the broadcaster device may communicate control information with one or more peripheral devices during a control sub-event based on one or more first packets associated with vendor-specific communications indicating the control sub-event. Operation of 1210 may be performed according to examples as disclosed herein. In some specific implementations, aspects of the operation of 1210 may be as described in references... Figure 9 The BIG control component 930 described is executed.

[0194] In some examples, at 1215, the broadcaster device may transmit one or more second packets via the group of multiple BIS of the BIG and during one or more second sub-events of the second BIG event, based on control information. The operation of 1215 may be performed according to the examples disclosed herein. In some specific implementations, aspects of the operation of 1215 may be as described in the references... Figure 9 The BIG data component 925 described is executed.

[0195] Figure 13 A flowchart illustrating an example process 1300 that can be executed by or at a peripheral device supporting the flow of LE broadcast control information for synchronizing broadcaster devices and one or more peripheral devices is shown. As described herein, the operation of process 1300 can be implemented by a peripheral device or a component thereof. For example, process 1300 can be implemented by a wireless communication device operating as a peripheral device or operating within a peripheral device (such as reference 1300). Figure 10 The described wireless communication device 1000 performs the procedure. In some examples, the procedure 1300 may be performed by a peripheral device (such as a reference device). Figures 1 to 8 The described peripheral devices are used to execute this.

[0196] In some examples, at 1305, a peripheral device may receive, via the BIS of the BIG and during one or more first sub-events of the first BIG event, one or more first packets indicating that a control sub-event of the first BIG event is associated with vendor-specific communication. Operation of 1305 may be performed according to examples as disclosed herein. In some specific implementations, aspects of the operation of 1305 may be as described in references... Figure 10 The BIG data component 1025 described is executed.

[0197] In some examples, at 1310, the peripheral device may communicate control information to the broadcaster device during a control sub-event based on one or more first packets associated with vendor-specific communications indicating the control sub-event. Operation of 1310 may be performed according to examples as disclosed herein. In some specific implementations, aspects of the operation of 1310 may be as described in references... Figure 10 The BIG control component 1030 described is executed.

[0198] Figure 14A flowchart illustrating an example process 1400 that can be executed by or at a peripheral device supporting the flow of LE broadcast control information for synchronizing broadcaster devices and one or more peripheral devices is shown. As described herein, the operation of process 1400 can be implemented by a peripheral device or a component thereof. For example, process 1400 can be implemented by a wireless communication device operating as a peripheral device or operating within a peripheral device (such as reference 1400). Figure 10 The described wireless communication device 1000 performs the procedure. In some examples, the procedure 1400 may be performed by a peripheral device (such as a reference device). Figures 1 to 8 The described peripheral devices are used to execute this.

[0199] In some examples, at 1405, a peripheral device may receive, via the BIS of the BIG and during one or more first sub-events of the first BIG event, one or more first packets indicating that a control sub-event of the first BIG event is associated with vendor-specific communication. Operation of 1405 may be performed according to examples as disclosed herein. In some specific implementations, aspects of the operation of 1405 may be as described in references... Figure 10 The BIG data component 1025 described is executed.

[0200] In some examples, at 1410, the peripheral device may communicate control information to the broadcaster device during a control sub-event based on one or more first packets associated with vendor-specific communications indicating the control sub-event. Operation of 1410 may be performed according to examples as disclosed herein. In some specific implementations, aspects of the operation of 1410 may be as described in references... Figure 10 The BIG control component 1030 described is executed.

[0201] In some examples, at 1415, the peripheral device may receive one or more second packets via the BIS of the BIG and during one or more second sub-events of the second BIG event, based on control information. The operation of 1415 may be performed according to the examples disclosed herein. In some specific implementations, aspects of the operation of 1415 may be as described in the references... Figure 10 The BIG data component 1025 described is executed.

[0202] Specific implementation examples are described in the following numbered clauses: Clause 1: A method for wireless communication by a broadcaster device, the method comprising: transmitting one or more first packets indicating that a control sub-event of the first BIG event is associated with vendor-specific communication via a plurality of BIS of a BIG and during one or more first sub-events of a first BIG event; and communicating control information to one or more peripheral devices during the control sub-event based on the one or more first packets indicating that the control sub-event is associated with the vendor-specific communication.

[0203] Clause 2: The method according to Clause 1 further includes: sending one or more second packets according to the control information via the plurality of BIS of the BIG and during one or more second sub-events of the second BIG event.

[0204] Clause 3: The method according to any one of Clauses 1 to 2, wherein the one or more first packets further include a sequence number field, and the sequence number field indicates the transmission direction of the control information between the broadcaster device and the one or more peripheral devices based on the one or more first packets that indicate the association of the control sub-event with the vendor-specific communication.

[0205] Clause 4: The method according to Clause 3, wherein the first bit pattern of the sequence number field indicates that the transmission direction is from the broadcaster to the peripheral device, and the second bit pattern of the sequence number field indicates that the transmission direction is from the peripheral device to the broadcaster.

[0206] Clause 5: The method according to Clause 4, wherein communicating the control information with the one or more peripheral devices comprises: sending the control information to the one or more peripheral devices according to the serial number field including the first bit pattern; or receiving the control information from a peripheral device among the one or more peripheral devices according to the serial number field including the second bit pattern.

[0207] Clause 6: The method according to any one of Clauses 4 to 5, wherein the sequence number field comprises three bits, the first of the three bits indicating that the transmission direction is from the broadcaster to the peripheral device or the transmission direction is from the peripheral device to the broadcaster, and the remaining bits of the three bits other than the first bit indicating a sequence number that is valid according to the first bit indicating that the transmission direction is from the broadcaster to the peripheral device.

[0208] Clause 7: The method according to any one of Clauses 3 to 6, wherein the sequence number field indicates that the transmission direction is from a peripheral device to a broadcaster, wherein communicating the control information with the one or more peripheral devices comprises: during the control sub-event, receiving a packet including the control information from a first peripheral device among the one or more peripheral devices, based on the transmission direction and based on the BIG event number corresponding to the first BIG event.

[0209] Clause 8: The method according to Clause 7, wherein the first peripheral device is associated with a first BIS corresponding to a first BIS index among the plurality of BIS, the first BIS index being associated with the first BIG event, and receiving the packet from the first peripheral device during the control sub-event of the first BIG event, which is associated with the first BIS index and the first BIG event.

[0210] Clause 9: The method according to Clause 8, wherein the modulo operation between the BIG event number and the number of the plurality of BIS is equal to the first BIS index minus one, the first BIS index being associated with the first BIG event.

[0211] Clause 10: The method according to any one of Clauses 8 to 9, the method further comprising: sending an indication of a mapping between a BIS index and a BIG event via configuration information associated with the BIG, wherein the first BIS index is associated with the first BIG event according to the mapping.

[0212] Clause 11: The method according to any one of Clauses 7 to 10, the method further comprising: during a second control sub-event of the second BIG event, receiving a second packet including a retransmission of the control information from the first peripheral device, wherein the second BIG event is associated with random backoff relative to the first BIG event.

[0213] Clause 12: The method according to any one of Clauses 7 to 11, wherein the grouping includes a second serial number field indicating a serial number associated with the control information.

[0214] Clause 13: The method according to any one of Clauses 7 to 12, the method further comprising: sending an indication of a multiple of a BIG event number associated with the vendor-specific communication via configuration information associated with the BIG, wherein the modulo operation between the BIG event number and the multiple of the BIG event number is equal to zero.

[0215] Clause 14: The method according to Clause 13 further includes: avoiding monitoring of the vendor-specific communications during a control sub-event of the BIG event, wherein the modulo operation between the BIG event number corresponding to the BIG event and a multiple of the BIG event number equals a number greater than zero.

[0216] Clause 15: The method according to any one of Clauses 1 to 14, wherein communicating the control information with the one or more peripheral devices comprises: communicating a packet including the control information, wherein the packet further includes an indication that the control information is associated with controller-based information or host-based information.

[0217] Clause 16: The method according to Clause 15, wherein the opcode of the group includes the indication that the control information is associated with the controller-based information or the host-based information.

[0218] Clause 17: The method according to any one of Clauses 1 to 16, wherein the control information includes channel assessment performed by a peripheral device among the one or more peripheral devices, feedback information from the peripheral device among the one or more peripheral devices, indication of volume level setting, indication of mute setting, or any combination thereof.

[0219] Clause 18: A method for wireless communication by a peripheral device, the method comprising: receiving, via a BIS of a BIG and during one or more first sub-events of a first BIG event, one or more first packets indicating that a control sub-event of the first BIG event is associated with vendor-specific communication; and conveying control information to a broadcaster device during the control sub-event based on the one or more first packets indicating that the control sub-event is associated with the vendor-specific communication.

[0220] Clause 19: The method according to Clause 18 further includes: receiving one or more second packets according to the control information via the BIS of the BIG and during one or more second sub-events of the second BIG event.

[0221] Clause 20: The method according to any one of Clauses 18 to 19, wherein the one or more first packets further include a sequence number field, and the sequence number field indicates the transmission direction of the control information between the broadcaster device and the peripheral device based on the one or more first packets indicating that the control sub-event is associated with the vendor-specific communication.

[0222] Clause 21: The method according to Clause 20, wherein the first bit pattern of the sequence number field indicates that the transmission direction is from the broadcaster to the peripheral device, and the second bit pattern of the sequence number field indicates that the transmission direction is from the peripheral device to the broadcaster.

[0223] Clause 22: The method according to Clause 21, wherein communicating the control information with the broadcaster device comprises: receiving the control information from the broadcaster device according to the serial number field including the first bit pattern; or sending the control information to the broadcaster device according to the serial number field including the second bit pattern.

[0224] Clause 23: The method according to any one of Clauses 21 to 22, wherein the sequence number field comprises three bits, the first of the three bits indicating that the transmission direction is from a broadcaster to a peripheral device or the transmission direction is from a peripheral device to a broadcaster, and the remaining bits of the three bits other than the first bit indicate a sequence number that is valid according to the first bit indicating that the transmission direction is from a broadcaster to a peripheral device.

[0225] Clause 24: The method according to any one of Clauses 20 to 23, wherein the sequence number field indicates that the transmission direction is from a peripheral device to a broadcaster, wherein communicating the control information with the broadcaster device includes: during the control sub-event of the first BIG event, transmitting a packet including the control information according to the transmission direction and according to the BIG event number corresponding to the first BIG event.

[0226] Clause 25: The method according to Clause 24, wherein the BIS corresponds to a BIS index associated with the first BIG event, and the packet is sent during the control sub-event of the first BIG event in accordance with the BIS index associated with the first BIG event.

[0227] Clause 26: The method according to Clause 25, wherein the modulo operation between the BIG event number and the number of multiple BIS of the BIG is equal to the BIS index minus one, the BIS index being associated with the first BIG event.

[0228] Clause 27: The method according to any one of Clauses 25 to 26, the method further comprising: receiving an indication of a mapping between a BIS index and a BIG event via configuration information associated with the BIG, wherein the BIS index is associated with the first BIG event according to the mapping.

[0229] Clause 28: The method according to any one of Clauses 24 to 27, the method further comprising: during a second control sub-event of the second BIG event, sending a second packet including the control information, wherein the second BIG event is associated with random backoff relative to the first BIG event.

[0230] Clause 29: The method according to any one of Clauses 24 to 28, wherein the grouping includes a second serial number field indicating a serial number associated with the control information.

[0231] Clause 30: The method according to any one of Clauses 24 to 29, the method further comprising: receiving, via configuration information associated with the BIG, an indication of a multiple of a BIG event number associated with the vendor-specific communication, wherein the modulo operation between the BIG event number and the multiple of the BIG event number is equal to zero.

[0232] Clause 31: The method according to Clause 30 further includes: avoiding transmission during a control sub-event of the BIG event, wherein the modulo operation between the BIG event number corresponding to the BIG event and a multiple of the BIG event number equals a number greater than zero.

[0233] Clause 32: The method according to any one of Clauses 18 to 31, wherein conveying the control information with the broadcaster device comprises: conveying a packet including the control information, wherein the packet further includes an indication that the control information is associated with controller-based information or host-based information.

[0234] Clause 33: The method according to Clause 32, wherein the opcode of the group includes the indication that the control information is associated with the controller-based information or the host-based information.

[0235] Clause 34: The method according to any one of Clauses 18 to 33, wherein the control information includes channel assessment performed by a peripheral device, feedback information from the peripheral device, indication of volume level setting, indication of mute setting, or any combination thereof.

[0236] Clause 35: A broadcaster device comprising: one or more memories storing processor-executable code; and one or more processors coupled to the one or more memories and capable of operating individually or jointly to execute the code, thereby enabling the broadcaster device to perform the method according to any one of Clauses 1 to 17.

[0237] Clause 35: A broadcaster device comprising a processing system including processor circuitry and memory circuitry storing code, the processing system being configured to cause the broadcaster device to perform a method according to any one of Clauses 1 to 17.

[0238] Clause 36: A broadcasting device comprising at least one component for performing the method according to any one of Clauses 1 to 17.

[0239] Clause 37: A non-transitory computer-readable medium storing code for wireless communication, the code including instructions executable by a processing system (including one or more processors) to perform a method according to any one of Clauses 1 to 17.

[0240] Clause 38: A peripheral device comprising: one or more memories storing processor-executable code; and one or more processors coupled to the one or more memories and capable of operating individually or jointly to execute the code, thereby enabling the peripheral device to perform a method according to any one of Clauses 18 to 34.

[0241] Clause 38: A peripheral device comprising a processing system including processor circuitry and memory circuitry for storing code, the processing system being configured to cause the peripheral device to perform a method according to any one of Clauses 18 to 34.

[0242] Clause 39: A peripheral device comprising at least one component for performing the method according to any one of Clauses 18 to 34.

[0243] Clause 40: A non-transitory computer-readable medium storing code for wireless communication, the code including instructions executable by a processing system (including one or more processors) to perform a method according to any one of Clauses 18 to 34.

[0244] As used herein, the term "determine" encompasses a wide variety of actions, and therefore, "determine" can include calculation, computation, processing, derivation, estimation, investigation, searching (such as by searching in a table, database, or other data structure), reasoning, probing, or measurement, among other possibilities. Furthermore, "determine" can include receiving (such as receiving information), accessing (such as accessing data stored in memory), or sending (such as sending information), among other possibilities. Additionally, "determine" can include parsing, selecting, obtaining, choosing, building, and other similar actions.

[0245] As used herein, the phrase “at least one of” or “one or more of” refers to any combination of these items, including a single member. For example, “at least one of a, b, or c” is intended to cover: a, b, c, ab, ac, bc, and abc. As used herein, “or” is intended to be interpreted in an inclusive sense unless otherwise expressly indicated. For example, “a or b” may include only a, only b, or a combination of a and b. Furthermore, as used herein, the phrase referring to “a” element means one or more of such elements that act individually or collectively to perform the stated function. Additionally, “set” means one or more items, and “subset” means less than the entire set, but not empty.

[0246] As used herein, unless otherwise expressly indicated, “based on” is intended to be interpreted in an inclusive sense. For example, unless otherwise explicitly indicated, “based on” may be used interchangeably with “at least partially based on,” “associated with,” “associated with,” or “according to.” Specifically, unless the phrase in the context means “based on only one” or an equivalent, whether it is “based on one” or “at least partially based on one”, it may be based solely on “one” or based on a combination of “one” and one or more other factors, conditions, or information.

[0247] The various exemplary components, logic units, logic blocks, modules, circuits, operations, and algorithmic processes described in conjunction with the examples disclosed herein can be implemented as electronic hardware, firmware, software, or a combination of hardware, firmware, or software, including the structures disclosed in this specification and their structural equivalents. This interchangeability of hardware, firmware, and software has been generally described in terms of its functionality and exemplified in the various exemplary components, blocks, modules, circuits, and processes described above. Whether this functionality is implemented in hardware, firmware, or software depends on the specific application and the design constraints imposed on the overall system.

[0248] Various modifications to the examples described in this disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other examples without departing from the spirit or scope of this disclosure. Therefore, the claims are not intended to be limited to the examples shown herein, but are to be granted the widest scope consistent with this disclosure, the principles disclosed herein, and the novel features.

[0249] Additionally, the various features described in this specification in the context of individual examples may also be implemented in combination in a single specific embodiment. Conversely, the various features described in the context of a single specific embodiment may also be implemented individually or in any suitable sub-combination in multiple examples. Thus, although features may be described above as functioning in a particular combination, and even initially claimed in this way, one or more features from the claimed combination may be removed from the combination in some cases, and the claimed combination may involve sub-combinations or variations of sub-combinations.

[0250] Similarly, although operations are depicted in a specific order in the diagrams, this should not be construed as requiring such operations to be performed in the specific order shown or in sequential order, or to perform all illustrated operations to achieve the desired result. Furthermore, the accompanying figures may schematically depict one or more example processes in the form of flowcharts or flow diagrams. However, other operations not depicted may be incorporated into the schematically illustrated example processes. For example, one or more additional operations may be performed before, after, simultaneously with, or between any of the illustrated operations. In some environments, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the examples described above should not be construed as requiring such separation in all examples, but rather should be understood as meaning that the described program components and systems can generally be integrated together in a single software product or encapsulated in multiple software products.

Claims

1. A broadcasting device, the broadcasting device comprising: A processing system, comprising processor circuitry and memory circuitry for storing code, is configured to cause the broadcaster device to: One or more first packets are sent via multiple broadcast isochronous streams of a broadcast isochronous group and during one or more first sub-events of a first broadcast isochronous group event, indicating that a control sub-event of the first broadcast isochronous group event is associated with a vendor-specific communication; as well as Control information is communicated to one or more peripheral devices during the control sub-event according to one or more first packets that indicate the control sub-event is associated with the vendor-specific communication.

2. The broadcasting device of claim 1, wherein the processing system is further configured to cause the broadcasting device to: One or more second packets are transmitted according to the control information via the plurality of broadcast isochronous streams of the broadcast isochronous group and during one or more second sub-events of the second broadcast isochronous group event.

3. The broadcaster device of claim 1, wherein the one or more first packets further include a serial number field, and wherein the serial number field indicates the transmission direction of the control information between the broadcaster device and the one or more peripheral devices based on the one or more first packets indicating that the control sub-event is associated with the vendor-specific communication.

4. The broadcaster device of claim 3, wherein the first bit pattern of the serial number field indicates that the transmission direction is from the broadcaster to a peripheral device, and the second bit pattern of the serial number field indicates that the transmission direction is from the peripheral device to the broadcaster.

5. The broadcaster device of claim 4, wherein, in order to communicate the control information with the one or more peripheral devices, the processing system is configured to cause the broadcaster device to: The control information is sent to the one or more peripheral devices according to the serial number field including the first bit pattern; or The control information is received from a peripheral device among the one or more peripheral devices according to the serial number field including the second bit pattern.

6. The broadcaster device of claim 4, wherein the serial number field comprises three bits, wherein the first bit of the three bits indicates that the transmission direction is from the broadcaster to a peripheral device or the transmission direction is from the peripheral device to the broadcaster, and wherein the remaining bits of the three bits other than the first bit indicate a serial number, the serial number being valid according to the first bit indicating that the transmission direction is from the broadcaster to the peripheral device.

7. The broadcaster device of claim 3, wherein, in order to communicate the control information with the one or more peripheral devices, the processing system is configured to cause the broadcaster device to: During the control sub-event, a packet including the control information is received from a first peripheral device among the one or more peripheral devices, according to the transmission direction and the broadcast isochronous group event number corresponding to the first broadcast isochronous group event.

8. The broadcaster device of claim 7, wherein the first peripheral device is associated with a first broadcast isochronous stream corresponding to a first broadcast isochronous stream index among the plurality of broadcast isochronous streams, wherein the first broadcast isochronous stream index is associated with a first broadcast isochronous group event, and wherein the packet is received from the first peripheral device during the control sub-event of the first broadcast isochronous group event and is associated with the first broadcast isochronous group event according to the first broadcast isochronous stream index.

9. The broadcaster device of claim 8, wherein the modulo operation between the broadcast isochronous group event number and the number of the plurality of broadcast isochronous streams is equal to the first broadcast isochronous stream index minus one, the first broadcast isochronous stream index being associated with the first broadcast isochronous group event.

10. The broadcaster device of claim 8, wherein the processing system is further configured to cause the broadcaster device to: An indication of a mapping between a broadcast isochronous stream index and a broadcast isochronous group event is sent via configuration information associated with the broadcast isochronous group, wherein the first broadcast isochronous stream index is associated with the first broadcast isochronous group event according to the mapping.

11. The broadcasting device of claim 7, wherein the processing system is further configured to cause the broadcasting device to: During the second control sub-event of the second broadcast isochronous group event, a second packet including a retransmission of the control information from the first peripheral device is received, wherein the second broadcast isochronous group event is associated with random backoff relative to the first broadcast isochronous group event.

12. The broadcaster device of claim 7, wherein the group includes a second serial number field indicating a serial number associated with the control information.

13. The broadcasting device of claim 7, wherein the processing system is further configured to cause the broadcasting device to: Send an indication of a multiple of the broadcast isochronous group event number associated with the vendor-specific communication via configuration information associated with the broadcast isochronous group, wherein the modulo operation between the broadcast isochronous group event number and the multiple of the broadcast isochronous group event number is equal to zero.

14. The broadcasting device of claim 13, wherein the processing system is further configured to cause the broadcasting device to: During the control sub-event of a broadcast isochronous group event, monitoring of the vendor-specific communication is avoided, wherein the modulo operation between the broadcast isochronous group event number corresponding to the broadcast isochronous group event and a multiple of the broadcast isochronous group event number equals a number greater than zero.

15. The broadcaster device of claim 1, wherein, in order to communicate the control information with the one or more peripheral devices, the processing system is configured to cause the broadcaster device to: The communication includes a group containing the control information, wherein the group also includes an indication that the control information is associated with controller-based information or host-based information.

16. The broadcaster device of claim 15, wherein the opcode of the packet includes the indication that the control information is associated with the controller-based information or the host-based information.

17. The broadcaster device of claim 1, wherein the control information includes channel assessment performed by one or more of the peripheral devices, feedback information from the peripheral devices, an indication of a volume level setting, an indication of a mute setting, or any combination thereof.

18. A peripheral device, the peripheral device comprising: The processing system includes processor circuitry and memory circuitry for storing code, and the processing system is configured to cause the peripheral device to: Receive one or more first packets indicating that a control sub-event of the first broadcast isochronous group event is associated with a vendor-specific communication via a broadcast isochronous stream of a broadcast isochronous group and during one or more first sub-events of a first broadcast isochronous group event; as well as Control information is communicated to the broadcaster device during the control sub-event according to one or more first packets that indicate the control sub-event is associated with the vendor-specific communication.

19. The peripheral device of claim 18, wherein the processing system is further configured to cause the peripheral device to: One or more second packets are received according to the control information via the broadcast isochronous stream of the broadcast isochronous group and during one or more second sub-events of the second broadcast isochronous group event.

20. The peripheral device of claim 18, wherein the one or more first packets further include a serial number field, and wherein the serial number field indicates the transmission direction of the control information between the broadcaster device and the peripheral device based on the one or more first packets indicating that the control sub-event is associated with the vendor-specific communication.

21. The peripheral device of claim 20, wherein the first bit pattern of the serial number field indicates that the transmission direction is from the broadcaster to the peripheral device, and the second bit pattern of the serial number field indicates that the transmission direction is from the peripheral device to the broadcaster.

22. The peripheral device of claim 21, wherein, in order to communicate the control information with the broadcasting device, the processing system is configured to cause the peripheral device to: The control information is received from the broadcaster device according to the serial number field including the first bit pattern; or The control information is sent to the broadcaster device based on the serial number field, which includes the second bit pattern.

23. The peripheral device of claim 21, wherein the serial number field comprises three bits, wherein the first bit of the three bits indicates that the transmission direction is from a broadcaster to a peripheral device or the transmission direction is from a peripheral device to a broadcaster, and wherein the remaining bits of the three bits, excluding the first bit, indicate a serial number, the serial number being valid according to the first bit indicating that the transmission direction is from a broadcaster to a peripheral device.

24. The peripheral device of claim 20, wherein, in order to communicate the control information with the broadcasting device, the processing system is configured to cause the peripheral device to: During the control sub-event of the first broadcast isochronous group event, a packet including the control information is transmitted according to the transmission direction and according to the broadcast isochronous group event number corresponding to the first broadcast isochronous group event.

25. The peripheral device of claim 24, wherein the broadcast isochronous stream corresponds to a broadcast isochronous stream index, wherein the broadcast isochronous stream index is associated with the first broadcast isochronous group event, and wherein the packet is transmitted during the control sub-event of the first broadcast isochronous group event in association with the first broadcast isochronous group event according to the broadcast isochronous stream index.

26. The peripheral device of claim 25, wherein the modulo operation between the broadcast isochronous group event number and the number of multiple broadcast isochronous streams of the broadcast isochronous group is equal to the broadcast isochronous stream index minus one, the broadcast isochronous stream index being associated with the first broadcast isochronous group event.

27. The peripheral device of claim 25, wherein the processing system is further configured to cause the peripheral device to: An indication of a mapping between a broadcast isochronous stream index and a broadcast isochronous group event is received via configuration information associated with the broadcast isochronous group, wherein the broadcast isochronous stream index is associated with the first broadcast isochronous group event according to the mapping.

28. The peripheral device of claim 24, wherein the processing system is further configured to cause the peripheral device to: During the second control sub-event of the second broadcast isochronous group event, a second packet including the control information is transmitted, wherein the second broadcast isochronous group event is associated with random backoff relative to the first broadcast isochronous group event.

29. A method for wireless communication by a broadcasting device, the method comprising: One or more first packets are sent via multiple broadcast isochronous streams of a broadcast isochronous group and during one or more first sub-events of a first broadcast isochronous group event, indicating that a control sub-event of the first broadcast isochronous group event is associated with a vendor-specific communication; as well as Control information is communicated to one or more peripheral devices during the control sub-event according to one or more first packets that indicate the control sub-event is associated with the vendor-specific communication.

30. A method for wireless communication by a peripheral device, the method comprising: Receive one or more first packets indicating that a control sub-event of the first broadcast isochronous group event is associated with a vendor-specific communication via a broadcast isochronous stream of a broadcast isochronous group and during one or more first sub-events of a first broadcast isochronous group event; as well as Control information is communicated to the broadcaster device during the control sub-event according to one or more first packets that indicate the control sub-event is associated with the vendor-specific communication.

Images