Bluetooth multichannel audio allocation apparatus and method using broadcast fec

Abstract

The present disclosure relates to an apparatus and a method for transmitting a multichannel audio signal in a short-range wireless communication system, particularly, a Bluetooth environment. Specifically, the present disclosure relates to an apparatus and a method for: applying a forward error correction (Broadcast FEC) technique in a Bluetooth broadcast audio environment; defining a metadata structure capable of exchanging FEC configuration information such as the number of audio blocks and the number of parity blocks between a transmission device (source) and a reception device (sink); and efficiently allocating and transmitting audio data and parity data through a plurality of broadcast isochronous streams (BISs) on the basis of the FEC configuration information, thereby ensuring compatibility between devices even within a limited bandwidth and stably providing high-quality multichannel audio.

Description

Bluetooth multi-channel audio allocation device and method using broadcast FEC

[0001] The present disclosure relates to an apparatus and method for transmitting multi-channel audio signals in a short-range wireless communication system, particularly in a Bluetooth environment. Specifically, the present disclosure relates to an apparatus and method for applying a Broadcast Forward Error Correction (Broadcast FEC) technique in a Bluetooth broadcast audio environment, defining a metadata structure capable of exchanging FEC configuration information such as the number of audio blocks and the number of parity blocks between a transmitting device (Source) and a receiving device (Sink), and efficiently allocating and transmitting audio data and parity data through a plurality of Broadcast Isochronous Streams (BIS) based on the FEC configuration information, thereby ensuring compatibility between devices even within a limited bandwidth and stably providing high-quality multi-channel audio.

[0002]

[0003] Short-range wireless communication technologies such as Bluetooth are widely used in personal audio streaming devices. With the recent expansion of immersive audio and spatial audio services, there is an increasing demand for technology to reliably transmit high-quality multi-channel audio wirelessly, going beyond 2-channel stereo.

[0004] A traditional approach to ensuring the transmission quality of high-quality audio in existing Bluetooth environments involves a technique of performing retransmission in the event of packet loss. However, high-quality multi-channel transmission via Bluetooth through retransmission results in inefficient use of wireless resources due to high bandwidth occupancy. Particularly in environments with limited bandwidth, such as 2Mbps transmission technology, this method causes excessive time occupancy, which limits the stable implementation of multi-channel audio.

[0005] To overcome the limitations of such retransmission techniques, there have been attempts to introduce Forward Error Correction (FEC), specifically RS-FEC (Reed-Solomon FEC), which allows the receiver to correct errors autonomously without retransmission. However, various prototypes of existing multi-channel transmission technologies using Bluetooth were released based on the assumption that the Source and Sink devices mutually know the multi-channel audio transmission method and RS-FEC parameters.

[0006] This is limited to a proprietary implementation where communication is possible only between devices of a specific manufacturer. Consequently, this leads to compatibility issues between different Source and Sink devices, posing a serious problem that undermines interoperability, which is an essential advantage of Bluetooth technology. Therefore, there is a need to develop a standardized technology that can clearly exchange RS-FEC parameters between devices without pre-assuming them, and efficiently transmit multi-channel audio within a limited bandwidth.

[0007]

[0008] To solve the aforementioned problems, the present disclosure provides a device and method that solve the problem of high bandwidth occupancy caused by the retransmission method and can stably transmit high-quality multi-channel audio even in a limited wireless environment such as Bluetooth 2M PHY.

[0009] The present disclosure aims to resolve compatibility issues between devices arising from the assumption that the Source device and the Sink device know the RS-FEC (Reed-Solomon FEC) parameters in advance. To this end, the present disclosure provides a device and method utilizing a standardized metadata structure within the Bluetooth standard in which a Broadcast Source transmits Broadcast FEC (Forward Error Correction) parameters to a Broadcast Sink device.

[0010] Furthermore, the present disclosure aims to provide an efficient LC3 (Low Complexity Communication Codec) media packet format for multi-channel audio transmission when the Broadcast FEC is applied. Moreover, the present disclosure provides an additional audio configuration with Broadcast FEC applied in the Bluetooth BAP (Basic Audio Profile) standard.

[0011] In addition, the present disclosure provides an apparatus and method that can effectively utilize time occupancy by variably allocating parity data according to the wireless channel environment even when the number of audio channels increases (e.g., up to 5 channels).

[0012] The technical problems to be solved in this disclosure are not limited to those mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art to which this disclosure belongs from the description below.

[0013]

[0014] According to various embodiments of the present disclosure, a method of operation of a source device in a short-range wireless communication system is provided, comprising: generating a plurality of audio blocks encoded with a Low Complexity Communication Codec (LC3); performing Broadcast Forward Error Correction (Broadcast FEC) coding to generate parity blocks based on the plurality of audio blocks; generating Broadcast FEC configuration information related to a first number (n) of the audio blocks and a second number (k) of the parity blocks; broadcasting metadata containing the Broadcast FEC configuration information to a sink device; and transmitting an LC3 media packet containing the plurality of audio blocks and the parity blocks to the sink device through a plurality of Broadcast Isochronous Streams (BISs).

[0015] According to various embodiments of the present disclosure, a method of operation of a sink device included in a plurality of speaker devices in a short-range wireless communication system is provided, comprising the steps of: receiving metadata from a source device; parsing broadcast FEC configuration information included in the metadata, wherein the broadcast FEC configuration information is related to a first number (n) of audio blocks and a second number (k) of parity blocks; receiving a Low Complexity Communication Codec (LC3) media packet from the source device through a plurality of broadcast isochronous streams (BISs), wherein the LC3 media packet includes the audio blocks and the parity blocks; and performing RS-FEC decoding (Reed-Solomon Forward Error Correction decoding) based on the broadcast FEC configuration information and recovering lost data from the audio blocks.

[0016] According to various embodiments of the present disclosure, a source device in a short-range wireless communication system comprises: a first processor corresponding to a host stack; a second processor corresponding to a controller stack; memory; an input device corresponding to a user interface (UI); an output device corresponding to the UI; and a transceiver, wherein the host stack and the controller stack are connected by a Host Controller Interface (HCI), and the memory stores instructions for performing operations based on execution by the first processor and the second processor, said operations include: generating a plurality of audio blocks encoded in a Low Complexity Communication Codec (LC3); and performing Broadcast Forward Error Correction (Broadcast FEC) coding to generate parity blocks based on the plurality of audio blocks. A source device is provided comprising the steps of: generating broadcast FEC configuration information related to a first number (n) of the audio blocks and a second number (k) of the parity blocks; and transmitting an LC3 media packet with the broadcast FEC configuration information inserted therein to a sink device through a plurality of broadcast isochronous streams (BISs).

[0017]

[0018] To solve the aforementioned problems, the present disclosure can solve the problem of high bandwidth occupancy caused by the retransmission method and provide a device and method capable of stably transmitting high-quality multi-channel audio even in a limited wireless environment such as Bluetooth 2M PHY.

[0019] The present disclosure aims to resolve compatibility issues between devices arising from the assumption that the Source device and the Sink device know the RS-FEC (Reed-Solomon FEC) parameters in advance. To this end, the present disclosure may provide a device and method that utilize a standardized metadata structure within the Bluetooth standard in which a Broadcast Source transmits Broadcast FEC (Forward Error Correction) parameters to a Broadcast Sink device.

[0020] In addition, the present disclosure aims to provide an efficient LC3 (Low Complexity Communication Codec) media packet format for multi-channel audio transmission when the Broadcast FEC is applied. Furthermore, the present disclosure can provide an additional audio configuration with Broadcast FEC applied in the Bluetooth BAP (Basic Audio Profile) standard.

[0021] In addition, the present disclosure can provide an apparatus and method that can effectively utilize time occupancy by variably allocating parity data according to the wireless channel environment even when the number of audio channels increases (e.g., up to 5 channels).

[0022]

[0023] The drawings attached below are intended to aid in understanding the present disclosure and may provide embodiments of the present disclosure together with the detailed description. However, the technical features of the present disclosure are not limited to specific drawings, and the features disclosed in each drawing may be combined with one another to form new embodiments. Reference numerals in each drawing may denote structural elements.

[0024] FIG. 1 is a schematic diagram showing an example of a wireless communication system using Bluetooth Low Energy technology proposed in the present disclosure.

[0025] FIG. 2 shows an example of an internal block diagram of a device capable of implementing the methods proposed in the present disclosure.

[0026] FIG. 3 shows an example of a Bluetooth communication architecture to which the methods proposed in the present disclosure can be applied.

[0027] Figure 4 shows an example of the structure of the Generic Attribute Profile (GATT) of Bluetooth Low Energy.

[0028] FIG. 5 is a flowchart illustrating an example of a connection procedure method in Bluetooth Low Energy technology to which various embodiments of the present disclosure can be applied.

[0029] Figure 6 illustrates an example of a payload allocation and retransmission structure within a BIS (Broadcast Isochronous Stream) event.

[0030] Figure 7 shows the RS-FEC (Reed-Solomon Forward Error Correction) encoding and transport stream allocation structure.

[0031] FIG. 8 illustrates an example of an RS (Reed-Solomon) FEC structure and transmission timing in which original data and parity data are separated into separate BIS (BIS 1, BIS 2) and transmitted.

[0032] FIG. 9 illustrates a new 'LC3 (Low Complexity Communication Codec) Media Packet format' structure for multi-channel audio transmission with Broadcast FEC applied as proposed in the present disclosure.

[0033] FIG. 10 illustrates an example of a metadata LTV (Length-Type-Value) structure for defining Broadcast FEC (Broadcast FEC) setting information (e.g., number of audio data, number of parity data) proposed in the present disclosure, and a configuration in which said metadata is included within a BASE (Broadcast Audio Stream Announcement) structure.

[0034] FIG. 11 illustrates an example of a table defining detailed requirements for each profile, such as SSAP 2-channel, 2.1-channel, 4-channel, and 4.1-channel, for a multi-channel LC3 audio configuration with broadcast FEC applied as proposed in the present disclosure.

[0035] FIG. 12 illustrates detailed audio stream configuration settings for each SSAP (Stream Service Access Point) profile proposed in the present disclosure, and shows an example of a table defining specific parameters (e.g., RTN=0, number of Original Data / Parity symbols, Num_BIS, etc.) of the Host Layer, RS-FEC, and Link Layer for each profile.

[0036] FIG. 13 illustrates an example of the operation process of a source device according to various embodiments of the present disclosure.

[0037] FIG. 14 illustrates an example of the operation process of a sink device according to various embodiments of the present disclosure.

[0038]

[0039] In various embodiments of the present disclosure, "A or B" may mean "only A," "only B," or "both A and B." Alternatively, in various embodiments of the present disclosure, "A or B" may be interpreted as "A and / or B." For example, in various embodiments of the present disclosure, "A, B or C" may mean "only A," "only B," "only C," or "any combination of A, B and C."

[0040] In various embodiments of the present disclosure, a slash ( / ) or a comma used may mean "and / or." For example, "A / B" may mean "A and / or B." Accordingly, "A / B" may mean "only A," "only B," or "both A and B." For example, "A, B, C" may mean "A, B or C."

[0041] In various embodiments of the present disclosure, "at least one of A and B" may mean "only A," "only B," or "both A and B." Additionally, in various embodiments of the present disclosure, the expressions "at least one of A or B" or "at least one of A and / or B" may be interpreted as synonymous with "at least one of A and B."

[0042] Additionally, in various embodiments of the present disclosure, “at least one of A, B and C” may mean “only A,” “only B,” “only C,” or “any combination of A, B and C.” Also, “at least one of A, B or C” or “at least one of A, B and / or C” may mean “at least one of A, B and C.”

[0043]

[0044] FIG. 1 is a schematic diagram showing an example of a wireless communication system using Bluetooth Low Energy technology proposed in this specification.

[0045] The wireless communication system (100) includes at least one server device (Server Device, 120) and at least one client device (Client Device, 110).

[0046] The server device and the client device perform Bluetooth communication using Bluetooth Low Energy (BLE, hereinafter referred to as 'BLE' for convenience) technology.

[0047] First, compared to Bluetooth BR / EDR (Basic Rate / Enhanced Data Rate) technology, BLE technology has a relatively small duty cycle and can be produced at a low cost. It can also significantly reduce power consumption through low data transfer rates, allowing it to operate for more than one year when using a coin cell battery.

[0048] In addition, BLE technology simplifies the connection process between devices and is designed to have a smaller packet size compared to Bluetooth BR / EDR technology.

[0049] In BLE technology, (1) the number of RF channels is 40, (2) the data transmission speed is 1 Mbps, (3) the topology is a scatternet structure, (4) the latency is 3 ms, (5) the maximum current is 15 mA or less, (6) the output power is 10 mW (10 dBm) or less, and (7) it is mainly used in applications such as mobile phones, watches, sports, healthcare, sensors, and device control.

[0050] The above server device (120) can operate as a client device in relation to other devices, and the above client device can operate as a server device in relation to other devices. That is, in a BLE communication system, any one device can operate as a server device or a client device, and if necessary, it is also possible to operate as both a server device and a client device simultaneously.

[0051] The above server device (120) may be represented as a data service device, a client device (slave device), a slave, a server, a conductor, a host device, a gateway, a sensing device, a monitoring device, a first device, a second device, etc.

[0052] The above client device (110) may be represented as a server device (master device), master, client, member, sensor device, sink device, collector, third device, fourth device, etc.

[0053] The server device and the client device correspond to the main components of the wireless communication system, and the wireless communication system may include other components in addition to the server device and the client device.

[0054] The above server device refers to a device that receives data from a client device and performs direct communication with the client device, thereby providing data to the client device through a response when receiving a data request from the client device.

[0055] In addition, the server device sends notification messages and indication messages to the client device to provide data information to the client device. Furthermore, when the server device transmits an indication message to the client device, it receives a confirmation message corresponding to the indication message from the client.

[0056] In addition, the server device can provide data information to the user through an output unit (Display Unit) or receive requests input from the user through an input unit (User Input Interface) during the process of transmitting and receiving notifications, instructions, and confirmation messages with the client device.

[0057] In addition, the server device can read data from a memory unit or write new data to the memory unit during the process of sending and receiving messages with the client device.

[0058] In addition, a single server device can be connected to multiple client devices, and can easily reconnect (or link) with client devices by utilizing bonding information.

[0059] The above client device (120) refers to a device that requests data information and data transmission from the server device.

[0060] The client device receives data from the server device through notification messages, instruction messages, etc., and when it receives an instruction message from the server device, it sends a confirmation message in response to the instruction message.

[0061] Likewise, the above client device can provide information to the user through an output unit or receive input from the user through an input unit during the process of transmitting and receiving messages with the above server device.

[0062] In addition, the client device can read data from memory or write new data to the memory during the process of sending and receiving messages with the server device.

[0063] Hardware components such as the output, input, and memory of the above-mentioned server device and client device will be examined in detail in FIG. 2.

[0064] In addition, the above wireless communication system can configure Personal Area Networking (PAN) through Bluetooth technology. For example, the above wireless communication system can quickly and securely exchange files, documents, etc. by establishing a private piconet between devices.

[0065] FIG. 2 shows an example of an internal block diagram of a device capable of implementing the methods proposed in this specification.

[0066] As illustrated in FIG. 2, the server device (110) includes a User Input Interface (112), a Power Supply Unit (113), a Control Unit (114), a Memory Unit (115), a Network Interface (116) including a Bluetooth Interface, Storage (117), a Display Unit (118), and a Multi Media Module (119).

[0067] The above input unit (User Input Interface, 112), power supply unit (Power Supply Unit, 113), control unit (Control Unit, 114), memory unit (Memory Unit, 115), network interface (Network Interface, 116) including a Bluetooth interface, storage (Storage, 117), output unit (Display Unit, 118), and multimedia module (Multi media Module, 119) are functionally connected to each other to perform the method proposed in this specification.

[0068] Additionally, as illustrated in FIG. 2, client devices (#1 and #2) (120) include a User Input Interface (122), a Power Supply Unit (123), a Control Unit (124), a Memory Unit (125), a Network Interface (126) including a Bluetooth Interface, Storage (127), a Display Unit (128), and a Multi Media Module (129).

[0069] The above input unit (User Input Interface, 122), power supply unit (Power Supply Unit, 123), control unit (Control Unit, 124), memory unit (Memory Unit, 125), network interface (Network Interface, 126) including a Bluetooth interface, storage (Storage, 127), output unit (Display Unit, 128), and multimedia module (Multi media Module, 129) are functionally connected to each other to perform the method proposed in this specification.

[0070] The above network interface (116, 126) refers to a unit (or module) capable of transmitting requests / responses, commands, notifications, instructions / confirmation messages, or data between devices using Bluetooth technology.

[0071] The above memory (115, 125) refers to a unit implemented in various types of devices, in which various types of data are stored. Additionally, the above storage (117, 127) refers to a unit that performs a function similar to memory.

[0072] The above control unit (114, 124) refers to a module that controls the overall operation of a server device (110) or a client device (120), and controls the transmission of a message to a network interface or the processing of a received message.

[0073] The above control unit (114, 124) may include an application-specific integrated circuit (ASIC), other chipsets, logic circuits and / or data processing devices.

[0074] The memory (115, 125) may include ROM (read-only memory), RAM (random access memory), flash memory, memory card, storage medium and / or other storage device.

[0075] The memory (115, 125) may be located inside or outside the processor (114, 124) and may be connected to the processor (114, 124) by various well-known means.

[0076] The above output unit (118, 128) refers to a module for providing device status information and message exchange information, etc., to the user through a screen.

[0077] The above power supply unit (power supply unit, 113, 123) refers to a module that receives external power and internal power under the control of the control unit and supplies power necessary for the operation of each component.

[0078] As discussed earlier, BLE technology features a small duty cycle and can significantly reduce power consumption through low data transmission rates.

[0079] FIG. 3 shows an example of a Bluetooth communication architecture to which the methods proposed in this specification can be applied.

[0080] Specifically, Figure 3 shows an example of the architecture of Bluetooth LE (Low Energy).

[0081] As shown in Fig. 3, the BLE structure includes a controller stack operable to handle timing-sensitive wireless device interfaces and a host stack operable to handle high-level data.

[0082] The above Controller stack may be referred to as a Controller, but to avoid confusion with the processor, which is an internal component of the device mentioned in Figure 2, it will be referred to as a Controller stack below.

[0083] First, the controller stack can be implemented using a communication module that may include a Bluetooth wireless device and a processor module that may include a processing device, such as a microprocessor, for example.

[0084] The host stack can be implemented as part of an OS running on a processor module, or as an instance of a package on top of the OS.

[0085] In some cases, the controller stack and the host stack may operate or run on the same processing device within the processor module.

[0086] The host stack includes GAP (Generic Access Profile, 310), GATT-based Profiles (320), GATT (Generic Attribute Profile, 330), ATT (Attribute Protocol, 340), SM (Security Manage, 350), and L2CAP (Logical Link Control and Adaptation Protocol, 360). However, the host stack is not limited to these and may include various protocols and profiles.

[0087] The host stack uses L2CAP to multiplex various protocols, profiles, etc. provided by Bluetooth overlay.

[0088] First, L2CAP (Logical Link Control and Adaptation Protocol, 360) provides a single bidirectional channel for transmitting data to a specific protocol or profile.

[0089] L2CAP can operate to multiplex data between upper-layer protocols, segment and reassemble packages, and manage multicast data transmission.

[0090] BLE uses three fixed channels (one for the signaling CH, one for the Security Manager, and one for the Attribute protocol).

[0091] On the other hand, BR / EDR (Basic Rate / Enhanced Data Rate) uses dynamic channels and supports protocol service multiplexer, retransmission, streaming mode, etc.

[0092] SM (Security Manager, 350) is a protocol for authenticating devices and providing key distribution.

[0093] ATT (Attribute Protocol, 340) defines rules for accessing data from a counterpart device in a server-client structure. ATT has six message types (Request, Response, Command, Notification, Indication, Confirmation).

[0094] In other words, ① Request and Response messages: A Request message is a message used to request specific information from a client device to a server device, and a Response message refers to a message sent from the server device to the client device as a response to the Request message.

[0095] ② Command Message: A message transmitted from a client device to a server device to instruct a specific action; the server device does not send a response to the Command message back to the client device.

[0096] ③ Notification Message: A message sent from a server device to a client device for notification, such as events; the client device does not send an acknowledgment message for the notification message to the server device.

[0097] ④ Indication and Confirm messages: Messages sent from a server device to a client device for notification, such as events. Unlike notification messages, the client device sends a confirmation message for the indication message to the server device.

[0098] GAP (Generic Access Profile) is a newly implemented layer for BLE technology used to control role selection for communication between BLE devices and how multi-profile operation occurs.

[0099] In addition, GAP is primarily used for device discovery, connection creation, and security procedures, defines methods for providing information to users, and defines the types of attributes as follows.

[0100] ① Service: Defines the basic operation of a device as a combination of data-related behaviors.

[0101] ② Include: Defines the relationships between services

[0102] ③ Characteristics: Data values ​​used in the service

[0103] ④ Behavior: A computer-readable format defined by a UUID (Universal Unique Identifier, value type).

[0104] GATT-based Profiles are profiles that depend on GATT and are primarily applied to BLE devices. GATT-based Profiles may include Battery, Time, FindMe, Proximity, Time, Object Delivery Service, etc. The specific details of GATT-based Profiles are as follows.

[0105] Battery: How to exchange battery information

[0106] Time: Method of exchanging time information

[0107] FindMe: Provides distance-based alarm service

[0108] Proximity: Battery Information Exchange Method

[0109] Time: Method of exchanging time information

[0110] GATT can operate as a protocol that describes how ATT is used when configuring services. For example, GATT can operate to define how ATT attributes are grouped together into services and to describe features associated with services.

[0111] Therefore, GATT and ATT may use features to describe the state and services of the device, and to explain how features relate to each other and how they are used.

[0112] The controller stack includes the physical layer (390), the link layer (380), and the host controller interface (370).

[0113] The physical layer (wireless transceiver module, 390) is a layer that transmits and receives 2.4 GHz wireless signals and uses GFSK (Gaussian Frequency Shift Keying) modulation and a frequency hopping technique consisting of 40 RF channels.

[0114] The link layer (380) transmits or receives Bluetooth packets.

[0115] In addition, the link layer performs advertising and scanning functions using three advertising channels, establishes a connection between devices, and provides the function of exchanging data packets of up to 42 bytes through 37 data channels.

[0116] HCI (Host Controller Interface) provides an interface between the Host stack and the Controller stack, enabling the Host stack to provide commands and data to the Controller stack, and the Controller stack to provide events and data to the Host stack.

[0117] Below, we will briefly examine the procedures of Bluetooth Low Energy (BLE) technology.

[0118] BLE procedures can be divided into device filtering procedures, advertising procedures, scanning procedures, discovering procedures, and connecting procedures.

[0119] Device Filtering Procedure

[0120] The device filtering procedure is a method to reduce the number of devices performing responses to requests, instructions, notifications, etc., in the controller stack.

[0121] Since it is unnecessary to respond to requests received from all devices, the controller stack can reduce the number of requests sent, thereby controlling the BLE controller stack to reduce power consumption.

[0122] An advertising device or a scanning device may perform the device filtering procedure to restrict the device receiving the advertising packet, scan request, or connection request.

[0123] Here, an advertising device refers to a device that transmits advertising events, that is, performs advertising, and is also referred to as an advertiser.

[0124] A scanning device refers to a device that performs scanning or transmits a scan request.

[0125] In BLE, when a scanning device receives some advertisement packets from an advertisement device, the scanning device must send a scan request to the advertisement device.

[0126] However, if a device filtering procedure is used and the transmission of a scan request is unnecessary, the scanning device may ignore advertising packets transmitted from the advertising device.

[0127] Device filtering procedures may also be used during the connection request process. If device filtering is used during the connection request process, the connection request is ignored, thereby eliminating the need to transmit a response to the connection request.

[0128] Advertising Procedure

[0129] The advertising device performs an advertising procedure to carry out non-directional broadcasts to devices within the area.

[0130] Here, non-directional broadcasting refers to broadcasting in all directions, rather than in a specific direction.

[0131] In contrast, a directional broadcast refers to a broadcast in a specific direction. A non-directional broadcast occurs without a connection procedure between an advertising device and a device in a listening (or listening) state (hereinafter referred to as a listening device).

[0132] The advertising process is used to establish a Bluetooth connection with a nearby initiation device.

[0133] Alternatively, the advertising process may be used to provide periodic broadcasts of user data to scanning devices that are listening on the advertising channel.

[0134] In the advertising process, all advertisements (or advertising events) are broadcast through physical advertising channels.

[0135] Ad devices may receive scan requests from listening devices that are listening to obtain additional user data from the ad devices. The ad device sends a response to the scan request to the device that sent the scan request through the same ad physical channel that received the scan request.

[0136] Broadcast user data sent as part of advertisement packets is dynamic data, whereas scan response data is generally static data.

[0137] An ad device can receive a connection request from a starter device on an ad (broadcast) physical channel. If the ad device has used a connectable ad event and the starter device has not been filtered by the device filtering procedure, the ad device stops the ad and enters connected mode. The ad device can start the ad again after entering connected mode.

[0138] Scanning Procedure

[0139] A device performing scanning, that is, a scanning device, performs a scanning procedure to listen for non-directional broadcasts of user data from advertising devices using advertising physical channels.

[0140] The scanning device transmits a scan request to the advertising device via an advertising physical channel to request additional data from the advertising device. The advertising device transmits a scan response, which is a response to the scan request, via the advertising physical channel, including the additional data requested by the scanning device.

[0141] The above scanning procedure can be used while connecting with other BLE devices in a BLE piconet.

[0142] If the scanning device receives a broadcasted advertisement event and is in an initiator mode capable of initiating a connection request, the scanning device can initiate a Bluetooth connection with the advertisement device by transmitting a connection request to the advertisement device through the advertisement physical channel.

[0143] When the scanning device sends a connection request to the advertising device, the scanning device stops initiator mode scanning for additional broadcasts and enters connection mode.

[0144] Discovery Procedure

[0145] Bluetooth-enabled devices (hereinafter referred to as "Bluetooth devices") perform advertising and scanning procedures to discover nearby devices or to be discovered by other devices within a given area.

[0146] The discovery process is performed asymmetrically. A Bluetooth device that seeks to find other nearby devices is called a discovering device, and it listens to find devices that advertise scannable ad events. A Bluetooth device that is discovered and available by other devices is called a discoverable device, and it actively broadcasts ad events through an advertising (broadcast) physical channel so that other devices can scan them.

[0147] Both the discovering device and the discoverable device may already be connected to other Bluetooth devices in the piconet.

[0148] Connecting Procedure

[0149] The connection procedure is asymmetric, and it requires that while a specific Bluetooth device performs the advertising procedure, another Bluetooth device performs the scanning procedure.

[0150] In other words, the advertising process can be the objective, and as a result, only one device will respond to the advertisement. After receiving an accessible advertisement event from the advertising device, a connection can be initiated by sending a connection request to the advertising device through the advertisement (broadcast) physical channel.

[0151] Next, we will briefly examine the operational states in BLE technology, namely the Advertising State, Scanning State, Initiating State, and Connection State.

[0152] Advertising State

[0153] The Link Layer (LL) enters the advertisement state at the direction of the host (stack). When the Link Layer is in the advertisement state, it transmits advertisement PDUs (Packet Data Units) in advertisement events.

[0154] Each ad event consists of at least one ad PDU, and the ad PDUs are transmitted through the ad channel indices used. The ad event may be terminated earlier if the ad event ends when the ad PDUs are transmitted through the ad channel indices used, or if the ad device needs to free up space to perform other functions.

[0155] Scanning State

[0156] The link layer enters the scanning state at the direction of the host (stack). In the scanning state, the link layer listens for ad channel indices.

[0157] There are two types of scanning states: passive scanning and active scanning, and each scanning type is determined by the host.

[0158] No separate time or ad channel index is defined for performing scanning.

[0159] During the scanning state, the link layer listens for ad channel indices for a scan window duration. The scan interval is defined as the interval between the start points of two consecutive scan windows.

[0160] The link layer must listen for the completion of all scan intervals in the scan window as directed by the host, provided there are no scheduling conflicts. In each scan window, the link layer must scan different ad channel indexes. The link layer uses all available ad channel indexes.

[0161] In passive scanning, the link layer only receives packets and cannot transmit any packets.

[0162] When active scanning, the link layer performs listening to rely on ad PDU types that can request ad PDUs and additional information related to the ad device from the ad device.

[0163] Initiating State

[0164] The link layer enters the initiation state at the direction of the host (stack).

[0165] When the link layer is in the initiation state, the link layer performs listening for ad channel indices.

[0166] During the initiation state, the link layer listens for the ad channel index during the scan window period.

[0167] connection state

[0168] The link layer enters a connection state when the device performing the connection request—that is, the initiator device—transmits a CONNECT_REQ PDU to the advertiser device, or when the advertiser device receives a CONNECT_REQ PDU from the initiator device.

[0169] A connection is considered to be created after entering the connected state. However, it is not necessary to consider the connection established at the moment it enters the connected state. The only difference between a newly created connection and an established connection is the link layer supervision timeout value.

[0170] When two devices are connected, they act in different roles.

[0171] The link layer performing the master role is called the master, and the link layer performing the slave role is called the slave. The master controls the timing of connection events, and a connection event refers to the point in time when synchronization occurs between the master and the slave.

[0172] Below, we will briefly examine the packets defined in the Bluetooth interface. BLE devices use the packets defined below.

[0173] Packet Format

[0174] The Link Layer has only one packet format used for both ad channel packets and data channel packets.

[0175] Each packet consists of four fields: Preamble, Access Address, PDU, and CRC.

[0176] When a packet is transmitted on the advertisement physical channel, the PDU will be an advertisement channel PDU, and when a packet is transmitted on the data physical channel, the PDU will be a data channel PDU.

[0177] Advertising Channel PDU

[0178] An ad channel PDU (Packet Data Unit) has a 16-bit header and payloads of various sizes.

[0179] The PDU type field of the ad channel PDU included in the header represents the PDU type as defined in Table 1 below.

[0180] PDU TypePDU NameChannelPermitted PHYsLE 1MLE 2MLE Coded0000bADV_INDPrimary AdvertisingO0001bADV_DIRECT_INDPrimary AdvertisingO0010bADV_NONCONN_INDPrimary AdvertisingO0011bSCAN_REQPrimary AdvertisingOAUX_SCAN_REQSecondary AdvertisingOOO0100bSCAN_RSPPrimary AdvertisingO0101bCONNECT_INDPrimary AdvertisingOAUX_CONNECT_REQSecondary AdvertisingOOO0110bADV_SCAN_INDPrimary AdvertisingO

[0181] The advertising channel PDU types below are referred to as advertising PDUs and are used in specific events.

[0182] ADV_IND: Connectable non-directional ad event

[0183] ADV_DIRECT_IND: Connectable directional ad events

[0184] ADV_NONCONN_IND: Non-connectable non-directional ad event

[0185] ADV_SCAN_IND: Scannable non-directional ad event

[0186] The above PDUs are transmitted at the Link Layer in the advertising state and received by the Link Layer in the scanning state or initiating state.

[0187] Scanning PDU

[0188] The advertising channel PDU type below is called a scanning PDU and is used in the conditions described below.

[0189] SCAN_REQ: Transmitted by the link layer in the scanning state and received by the link layer in the advertising state.

[0190] SCAN_RSP: Transmitted by the link layer in the ad state and received by the link layer in the scanning state.

[0191] Initiating PDU

[0192] The advertising channel PDU type below is called a launch PDU.

[0193] CONNECT_REQ: Transmitted by the link layer in the initiation state and received by the link layer in the advertisement state.

[0194] Data Channel PDU

[0195] A data channel PDU has a 16-bit header, payloads of various sizes, and may include a Message Integrity Check (MIC) field.

[0196] The procedures, states, packet formats, etc. in BLE technology discussed above can be applied to perform the methods proposed in this specification.

[0197]

[0198] Figure 4 shows an example of the structure of the Generic Attribute Profile (GATT) of Bluetooth Low Energy.

[0199] Referring to Figure 4, one can see the structure for exchanging profile data of Bluetooth Low Energy.

[0200] Specifically, GATT (Generic Attribute Profile) defines a method for exchanging data using services and characteristics between Bluetooth LE devices.

[0201] Generally, peripheral devices (e.g., sensor devices) act as GATT servers and have definitions for services and characteristics.

[0202] To read or write data, the GATT client sends a data request to the GATT server, and all transactions are initiated by the GATT client and receive a response from the GATT server.

[0203] The GATT-based operation structure used in Bluetooth LE is based on Profile, Service, and Characteristic, and can form a vertical structure as shown in Fig. 5 above.

[0204] The above profile is composed of one or more services, and the service may be composed of one or more characteristics or other services.

[0205] The above service serves to divide data into logical units and may include one or more characteristics or other services. Each service has a 16-bit or 128-bit identifier called a Universal Unique Identifier (UUID).

[0206] The above characteristic is the lowest unit in the GATT-based operation structure. The above characteristic contains only one piece of data and, similar to the above service, has a 16-bit or 128-bit UUID.

[0207] The above characteristic is defined by the values ​​of various pieces of information, and requires one attribute to contain each piece of information. Multiple consecutive attributes can be used for the above characteristic.

[0208] The above attribute consists of four components and has the following meanings.

[0209] - handle: address of the attribute

[0210] - Type: Type of the attribute

[0211] - Value: The value of the attribute

[0212] - Permission: Access rights to the property

[0213]

[0214] FIG. 5 is a flowchart illustrating an example of a connection procedure method in Bluetooth Low Energy technology to which the present invention can be applied.

[0215] The server sends an advertising message to the client through three advertising channels (S5010).

[0216] The server may be referred to as an Advertiser before the connection and as a Master after the connection. An example of the above server may be a sensor (such as a temperature sensor).

[0217] Additionally, the client may be referred to as a Scanner before connection and as a Slave after connection. An example of a client could be a smartphone.

[0218] As seen above, Bluetooth communicates through a total of 40 channels via the 2.4GHz band. Of the 40 channels, 3 are advertising channels, which are used for exchanging various advertising packets as well as packets exchanged to establish a connection.

[0219] The remaining 37 channels are used for data exchange after connection as data channels.

[0220] After receiving the advertisement message, the client may send a scan request message to the server to obtain additional data (e.g., server device name, etc.) to the server.

[0221] In this case, the server sends a scan response message containing additional data to the client in response to a scan request message.

[0222] Here, the Scan Request message and Scan Response message are terminations of the advertisement packet, and the advertisement packet may contain only User Data of 31 bytes or less.

[0223] Therefore, if there is data that is larger than 3 bytes but has a large overhead for establishing a connection to send, the data is divided and sent in two steps using a scan request message / scan response message.

[0224] Next, the client sends a Connection Request message to the server to establish a Bluetooth connection with the server (S5020).

[0225] Through this, a Link Layer (LL) connection is established between the server and the client.

[0226] Afterwards, the server and client perform the security establishment procedure.

[0227] The security establishment procedure can be interpreted as Secure Simple Pairing or performed including it.

[0228] That is, the security establishment procedure can be carried out through Phase 1 to Phase 3.

[0229] Specifically, a pairing procedure (Phase 1) is performed between the server and the client (S5030).

[0230] In the pairing procedure, the client sends a Pairing Request message to the server, and the server sends a Pairing Response message to the client.

[0231] Through the pairing process, authentication requirements, input / output capabilities, and key size information are exchanged between devices. Based on this information, it is determined which key generation method to use in Phase 2.

[0232] Next, as Phase 2, legacy pairing or secure connections are performed between the server and the client (S5040).

[0233] In Phase 2, a 128-bit Temporary Key and Short Term Key (STK) are generated to perform legacy pairing.

[0234] - Temporary Key: A key created to generate the STK

[0235] - Short Term Key (STK): A key value used to establish an encrypted connection between devices

[0236] If a secure connection is established in Phase 2, a 128-bit Long Term Key (LTK) is generated.

[0237] - Long Term Key (LTK): A key value used not only for encrypted connections between devices but also for future connections.

[0238] Next, as Phase 3, a Key Distribution procedure is performed between the server and the client (S5050).

[0239] Through this, a secure connection is established between the server and the client, and data can be transmitted and received by forming an encrypted link.

[0240] Isochronous Channel General

[0241] In the case of an audio signal, audio streaming data or audio data can be seen occurring periodically at Idle Event Interval intervals.

[0242] Audio data occurs periodically (or at specific time intervals) depending on its characteristics. Here, the specific time interval during which audio data occurs periodically can be represented as the Idle Event Interval. Each piece of audio data is transmitted during each Idle Event Interval. Additionally, each piece of audio data may be transmitted over the entire Idle Event Interval or a portion thereof. When transmitting periodic or regular audio streaming data using a BLE mechanism, procedures such as advertising and scanning, communication, and disconnection must be performed whenever audio data is transmitted or received. However, since audio data generally occurs periodically, a latency guarantee for audio data transmission is essential regardless of the data volume.

[0243] However, if advertising and scanning procedures, communication procedures, and disconnection procedures must be performed every time new audio data is transmitted, there is a problem of latency occurring during audio data transmission.

[0244] Since the amount of data generated for audio data transmission via hearing aids (HA) or headsets is relatively small, using BLE technology instead of Bluetooth BR / EDR technology can achieve high energy efficiency. However, as previously discussed, the Data Channel Process of BLE technology requires Advertising and Connection to be performed for every data transmission, resulting in large overhead in data transmission. In particular, it cannot guarantee the Latency Guarantee that is absolutely necessary for audio data transmission.

[0245] Furthermore, since the Data Channel Process of BLE technology aims to increase energy efficiency by transmitting sporadically generated data only when necessary and inducing Deep Sleep in BLE devices during other time domains, it may be difficult to apply the Data Channel Process of BLE technology to the transmission of periodically occurring audio data.

[0246] Definition of Isochronous Channels and Related Mechanisms

[0247] To transmit periodically occurring data using BLE technology, a new channel, namely an isochronous channel, is defined.

[0248] An isochronous channel is a channel used to transmit isochronous data between devices (e.g., conductor-member) that use isochronous streams.

[0249] Isochronous data refers to data transmitted at specific time intervals, that is, periodically or regularly.

[0250] That is, an isochronous channel can represent a channel in BLE technology where periodically occurring data, such as audio data or voice data, is transmitted and received. Additionally, in a gaming scenario, the isochronous channel can represent a channel where data generated based on user input from a game user's controller device is transmitted and received. The isochronous channel can be used to transmit and receive data to a single member, a set of one or more coordinated members, or multiple members. Furthermore, the isochronous channel corresponds to a flushing channel that can be used to transmit and receive isochronous streams, such as audio streaming, or important data in other time domains.

[0251]

[0252] Composition of various embodiments of the present disclosure

[0253] Problems with conventional technology

[0254] High-quality multi-channel transmission of Bluetooth through retransmission had limitations in 2Mbps transmission technology because of the high bandwidth usage.

[0255] Various prototypes of existing multi-channel transmission technologies using Bluetooth have been released based on the assumption that the Source and Sink devices mutually know the methods for transmitting multi-channel audio and the RS-FEC parameters. This leads to compatibility issues between different Source and Sink devices.

[0256]

[0257] Summary of various embodiments of the present disclosure

[0258] The present disclosure provides an LC3 media packet format for multi-channel audio transmission when Broadcast Forward Error Correction (FEC) is applied in the Bluetooth standard.

[0259] The present disclosure provides a method for using a metadata structure to transmit parameters of a Broadcast FEC from a Broadcast Source to a Broadcast Sink device in the Bluetooth standard.

[0260] The present disclosure provides an additional audio configuration that applies Broadcast FEC to the Bluetooth Basic Audio Profile (BAP) standard.

[0261]

[0262] Effects of various embodiments of the present disclosure

[0263] Various embodiments of the present disclosure can ensure compatibility with other devices by reflecting Bluetooth standard technology.

[0264] Various embodiments of the present disclosure enable the transmission of up to 5 audio channels in a Bluetooth 2M PHY by using the Broadcast FEC technique.

[0265] Various embodiments of the present disclosure allow for the effective use of time occupancy because the Parity Data can be varied to suit the wireless environment even as the number of audio channels increases.

[0266]

[0267] Figure 6 illustrates an example of a payload allocation and retransmission structure within a BIS (Broadcast Isochronous Stream) event.

[0268] FIG. 6 illustrates an example of a payload allocation and retransmission structure within a Broadcast Isochronous Stream (BIS) event according to the prior art. This figure is intended to explain the retransmission technique of the Bluetooth standard technology and shows a situation in which a BIS event occurs within a single ISO interval.

[0269] The example illustrated in the drawing is the case where BN (Burst Number) is set to 2, IRC (Immediate Retransmission Count) to 2, PTO (Presentation Time Offset) to 0, and NSE (Number of Sub-events) to 4. Here, BN may refer to the number of audio channels, such as 2-channel audio.

[0270] Looking at the operation in detail, the original packets P0 and P1 are transmitted via their respective sub-events within the first BIS event (x). Subsequently, depending on the IRC configuration, it can be seen that P0 and P1 are immediately retransmitted (retransmission of burst) within the same event.

[0271] These conventional retransmission techniques are designed so that retransmission is performed in multiples of the number of audio channels (BN). As a result, as the number of audio channels increases, the time required for retransmission increases rapidly in multiples of the number of channels, causing serious inefficiency.

[0272]

[0273] FIG. 7 illustrates an example of a conventional RS-FEC (Reed-Solomon Forward Error Correction) encoder structure that separates original data and parity data into separate BIS (Broadcast Isochronous Stream) for transmission.

[0274] Specifically, FIG. 7 is a block diagram illustrating an example of the prior art that the present invention aims to solve. It represents a Forward Error Correction (FEC) technique proposed to the Bluetooth SIG in 2023, showing a method of separating original data and parity data into separate streams for transmission.

[0275] If we look at the operation process in detail, first, Pulse-Code Modulation (PCM) data passes through four LC3 encoders ('LC3 Encoder x4') to generate four original audio channels (Ch 1, Ch 2, Ch 3, Ch 4).

[0276] The key feature of Fig. 7 is that the generated four original audio channels (Ch 1-4) are directed to 'To BIS 1' and transmitted through the first broadcast isochronous stream (BIS). At the same time, these four original channels are input into the 'RS FEC Encoder' to generate four parity data (P1, P2, P3, P4), and this parity data is directed to 'To BIS 2' and transmitted through the second BIS, which is completely separated from the original data.

[0277] These conventional technologies have two clear problems. First, since the source data and parity data must be transmitted as separate BISs, complexity arises in that the receiving end (Sink) must receive and manage two streams. Second, as illustrated in the drawing, there is a rigid constraint that four parity data sets must be generated for four source data sets, meaning the number of source and parity sets must be matched. This results in inefficiency where unnecessary parity must be transmitted even when the wireless environment is good, which is the core problem that the present disclosure aims to solve through 'one BIS' and 'variable parity'.

[0278]

[0279] FIG. 8 illustrates an example of a transmission timing structure of the prior art in which original data (BIS 1) and parity data (BIS 2) are assigned to separate BISs.

[0280] Specifically, FIG. 8 is a diagram illustrating in detail the link layer transmission timing structure of the prior art proposed to the Bluetooth SIG in 2023. FIG. 8 shows how the block diagram of FIG. 7 (a structure separating the source and parity into 'To BIS 1' and 'To BIS 2') is transmitted within an actual BIG (Broadcast Isochronous Group) event.

[0281] The most important feature of Fig. 8 is that the original data and parity data are separated and transmitted as two separate BISs (BIS 1, BIS 2). As shown in Fig. 8, BIS 1 transmits the original audio channels (Ch 1-4) over four sub-events (SE 1-4). Separated from this, BIS 2 transmits the parity data (P1-P4) over four sub-events (SE 1-4).

[0282] The example in Fig. 8 is based on the RS(8,4) code using 4 originals and 4 parities, illustrating the limitations of the conventional technology that requires matching the number of original data and parity data equally (1:1). According to the PPT materials, this 2-BIS method has a BIG_Sync_Delay of 5370us within an ISO interval of 10ms, which accounts for a high time share (BW) of approximately 54%.

[0283] FIG. 8 clearly defines the problem that the present disclosure seeks to solve, namely, an inefficient 2-BIS structure and a fixed parity ratio. This stands in stark contrast to the technical configuration of the present invention, which optimizes the time occupancy rate to 26% to 40% by variably adjusting parity according to the wireless environment and transmitting all this data through a single BIS.

[0284]

[0285] FIG. 9 illustrates a new 'LC3 (Low Complexity Communication Codec) Media Packet format' structure for multi-channel audio transmission with Broadcast FEC applied as proposed in the present disclosure.

[0286] Specifically, FIG. 9 illustrates the technology of the present disclosure “How to send multiple audio data with Broadcast FEC” through a ‘data generation process’ (top) and the resulting ‘payload structure’ (bottom).

[0287] The top of FIG. 9 illustrates the multichannel audio and FEC processing process of the present disclosure.

[0288] 1. First, five audio channels (Front Left, Front Right, etc.) each pass through an LC3 encoder and are multiplexed into five codec frames (CF_1 ~ CF_5) to form a 'Media Packet'.

[0289] 2. Next, this media packet is used as an input to the 'Broadcast FEC' encoder as an 'Audio Stream'.

[0290] 3. The FEC encoder generates parity blocks (P_1 ~ P_5) for error correction based on this audio stream (CF_1 ~ CF_5).

[0291] 4. Finally, an audio stream containing both the original codec frame (CF) and the generated parity block (P) is output.

[0292] The bottom of FIG. 9 illustrates a comparison between the 'Legacy Payload' of the prior art and the 'New Payload' of the present disclosure to implement this configuration.

[0293] 1. The bottom left (conventional technology) shows the 'Legacy Payload' structure, in which the payload consists only of LC3 codec frames (CF). According to the PPT text, in this legacy structure, the number (m) and order of LC3 codec frames within the blocks are defined by the 'Audio_Channel_Allocation LTV' structure, and the number of blocks (n) within the payload is defined by the 'Codec_Frame_Blocks_Per_SDU LTV' structure.

[0294] 2. On the other hand, the bottom right (an embodiment of the present disclosure) discloses a 'New Payload' (or 'LC3 Media Packet format with RS-FEC'), which is a core component of the present disclosure. This new payload structure is characterized by including a plurality of audio codec frames (CF) and 'Parity block, P' (a block generated by a broadcast FEC encoder) together within a single payload. According to the PPT text, this 'Broadcast FEC' function can be selected by the Metadata LTV structure of SSAP or BASE, and the number of parity blocks (k) within the payload is defined by the 'Broadcast FEC configuration of the Metadata LTV structure within BASE'.

[0295] In conclusion, FIG. 9 illustrates the core technical concept of the present invention, which overcomes the limitations of conventional technology (Figs. 7 and 8) that transmits original data and parity data separately as Broadcast Isochronous Streams (BIS) and maximizes efficiency by integrating and transmitting audio and parity data as a single payload and a single stream.

[0296]

[0297] FIG. 10 illustrates an example of a metadata LTV (Length-Type-Value) structure for defining Broadcast FEC (Broadcast FEC) setting information (e.g., number of audio data, number of parity data) proposed in the present disclosure, and a configuration in which said metadata is included within a BASE (Broadcast Audio Stream Announcement) structure.

[0298] Specifically, FIG. 10 is a key component of the present disclosure and provides a solution to "How to communicate with Source and Sink" (a method of communication between a Source device and a Sink device). This involves communicating Broadcast FEC parameters through a 'Metadata LTV structure' newly defined in the Bluetooth SIG 'Assigned Number'. This resolves the compatibility issues that arose from the prior art assuming RS-FEC parameters.

[0299] The table at the top left of Fig. 10 defines a new LTV structure corresponding to "Add Broadcast FEC Configuration in Metadata LTV structure." This LTV is characterized by "It shall be present if supports the Broadcast FEC feature." The 'Value' field of this structure includes a bit field that explicitly defines 'Number of audio data' (n) and 'Number of parity data' (k). Through this, unlike the prior art (Fig. 7), the number of original data and parity data can be set variably according to the wireless environment without being fixed at a 1:1 ratio.

[0300] The table at the bottom left of Fig. 10 defines the "Add Audio or parity data" LTV structure. This LTV is characterized by "It may be present if supports the Broadcast FEC feature" and serves to specify whether a particular BIS transmits 'Only Audio data', 'Only Parity data', or 'Audio and Parity data'.

[0301] The 'Example BASE Structure' on the right side of Fig. 10 shows an example where this metadata is applied to an actual BASE (Broadcast Audio Stream Announcement). 'RS-FEC_configuration' is included within the metadata of the Level 2 Subgroup, and variable FEC parameters such as 'Num_audio 2, Num of parity 6' are specifically set. Based on this setting, each BIS of Level 3 is configured to transmit either 'Audio and Parity' or 'Parity only'.

[0302]

[0303] FIG. 11 illustrates an example of a table defining detailed requirements for each profile, such as SSAP 2-channel, 2.1-channel, 4-channel, and 4.1-channel, for a multi-channel LC3 audio configuration with broadcast FEC applied as proposed in the present disclosure.

[0304] Specifically, FIG. 11 illustrates an example of a new multi-channel LC3 broadcast audio configuration table for the Bluetooth Basic Audio Profile (BAP) standard proposed in the present disclosure.

[0305] This drawing newly defines multi-channel audio profiles such as SSAP 2.1ch (3 channels), SSAP 4ch (4 channels), and SSAP 4.1ch (5 channels) in addition to the existing SSAP 2ch by applying the Broadcast FEC technique of the present disclosure.

[0306] The table specifies the number of audio channels required per audio configuration (Audio Channels per BIS), the number of BISes, the number of audio streams, and the support requirements (M: Mandatory, O: Optional) for SSAP Source and SSAP Sink. For example, the 4.1-channel configuration (5 audio channels) proposed in this disclosure uses 2 BISes and shows that both the Source and Sink can be defined as 'M' (mandatory).

[0307]

[0308] FIG. 12 illustrates detailed audio stream configuration settings for each SSAP (Stream Service Access Point) profile proposed in the present disclosure, and shows an example of a table defining specific parameters (e.g., RTN=0, number of Original Data / Parity symbols, Num_BIS, etc.) of the Host Layer, RS-FEC, and Link Layer for each profile.

[0309] Specifically, FIG. 12 illustrates a table defining detailed audio stream configuration settings for each SSAP (Stream Service Access Point) profile defined in FIG. 11. This table shows how the technology of the present disclosure operates at the actual link layer through specific parameters. The table defines parameters for the profile, host layer, RS-FEC, and link layer for each of the SSAP 2ch, 2.1ch, 4ch, and 4.1ch.

[0310] Profile configurations: The codec configuration is fixed to '48_4', which means a Max SDU Size of 120 bytes and an LC3 Encoding Interval of 10ms.

[0311] Host layer configurations: The SDU Interval is set to 10ms, and the core feature of the present invention is no need for retransmission, i.e., RTN (number of retransmissions) = 0 and IRC = 1. This clarifies that the conventional retransmission technique (Fig. 6) that relied on retransmission is not used.

[0312] RS-FEC configurations: This most important section shows an example where the variable parameters proposed in Fig. 10 are actually applied. The key point is that "Number of parity symbols could be different from original data on RS-FEC." For example, SSAP 2.1ch uses 3 'Original Data' symbols and 5 'Parity' symbols, and SSAP 4.1ch uses 5 'Original Data' symbols and 5 'Parity' symbols. This demonstrates that the limitations of the conventional technology (Fig. 7), which enforced only a 1:1 ratio, have been overcome.

[0313] Link layer configurations: The ISO interval is set to 10ms by Max_Transport_Latency. NSE (Number of Sub-events) is calculated by multiplying BN (Burst Number) and IRC, and BIG_Sync_delay is calculated using the formula (Num_BIS - 1) x BIS_Spacing + (NSE - 1) x Sub_Interval + MPT.

[0314]

[0315] [Explanation regarding source device claim]

[0316] The embodiments described above will be explained in detail below with reference to FIG. 13 in terms of the operation of a source device (TV, soundbar, etc.). The methods described below are distinguished only for the convenience of explanation, and it is understood that, as long as they are not mutually excluded, a part of one method may be substituted with a part of another method or combined with one another and applied.

[0317] FIG. 13 illustrates an example of the operation process of a source device, such as a TV or soundbar, according to various embodiments of the present disclosure.

[0318] According to various embodiments of the present disclosure, a method is provided that is performed by a source device such as a TV or soundbar that supports a short-range communication system such as Bluetooth.

[0319] The source device includes a first processor corresponding to a host stack; a second processor corresponding to a first controller stack; memory; and a transceiver. The host stack and the controller stack are connected via a Host Controller Interface (HCI).

[0320] In step S1301, the source device generates multiple audio blocks encoded with a Low Complexity Communication Codec (LC3).

[0321] In step S1302, the source device performs Broadcast Forward Error Correction (Broadcast FEC) coding to generate parity blocks based on the plurality of audio blocks.

[0322] In step S1303, the source device generates broadcast FEC configuration information related to the first number (n) of the audio blocks and the second number (k) of the parity blocks.

[0323] In step S1304, the source device broadcasts metadata containing the broadcast FEC setting information to the sink device.

[0324] In step S1305, the source device transmits an LC3 media packet containing the plurality of audio blocks and the parity blocks to the sink device through a plurality of broadcast isochronous streams (BISs).

[0325]

[0326] According to various embodiments of the present disclosure, the broadcast FEC setting information may be based on RS-FEC (Reed-Solomon Forward Error Correction).

[0327] According to various embodiments of the present disclosure, the broadcast FEC setting information may include a first bit of the least significant bit (LSB) and a second bit of the most significant bit (MSB). The first bit may include a first number of original symbols associated with the audio block. The second bit may include a second number of parity symbols associated with the parity block.

[0328] According to various embodiments of the present disclosure, some of the audio blocks may contain only audio data, and others may contain only parity data. Meta information specifying the existence of audio blocks and parity blocks for each BIS may be provided.

[0329] According to various embodiments of the present disclosure, based on the broadcast FC setting information, each of the plurality of BISs may be composed of only an audio block, or only a parity block, or a combination of an audio block and a parity block.

[0330] According to various embodiments of the present disclosure, the broadcast FEC setting information may be updated in real time according to the wireless channel environment. The updated broadcast FEC setting information may be broadcast within a periodic advertising interval after the update of the broadcast FEC setting information.

[0331] According to various embodiments of the present disclosure, the broadcast FEC configuration information may be included in a Length-Type-Value (LTV) field within the structure of the metadata. The metadata may be included in a Broadcast Audio Stream Announcement (BASE) and broadcast.

[0332]

[0333] According to various embodiments of the present disclosure, a source device is provided. The source device includes a first processor corresponding to a host stack; a second processor corresponding to a first controller stack; memory; and a transceiver. The host stack and the controller stack are connected by a Host Controller Interface (HCI). The memory may be configured to store instructions for performing a method of operation of the source device according to FIG. 13, based on execution by the first processor and the second processor.

[0334]

[0335] According to various embodiments of the present disclosure, a control device for controlling a source device is provided. The control device comprises at least one processor and at least one memory operably connected to the at least one processor. The at least one memory may be configured to store instructions for performing a method of operating the source device according to FIG. 13 based on execution by the at least one processor.

[0336]

[0337] According to various embodiments of the present disclosure, one or more non-transitory computer-readable media (CRMs) storing one or more instructions are provided. The one or more instructions perform operations based on execution by one or more processors, and the operations may include a method of operation of a source device according to FIG. 13.

[0338]

[0339] [Explanation regarding sink device claim]

[0340] The embodiments described above will be explained in detail below with reference to FIG. 14 regarding the operation of a sink device such as a speaker. The methods described below are distinguished only for the convenience of explanation, and it is obvious that as long as they are not mutually excluded, a part of one method may be substituted with a part of another method or combined with one another and applied.

[0341] FIG. 14 illustrates an example of the operation process of a sink device according to various embodiments of the present disclosure.

[0342] According to various embodiments of the present disclosure, a method is provided that is performed by a sink device that supports a short-range communication system such as Bluetooth.

[0343] The sink device includes a third processor corresponding to a host stack; a fourth processor corresponding to a third controller stack; memory; and a transceiver. The host stack and the controller stack are connected via a Host Controller Interface (HCI).

[0344] In step S1401, the sink device receives metadata from the source device.

[0345] In step S1402, the sink device parses the broadcast FEC configuration information included in the metadata. The broadcast FEC configuration information relates to a first number (n) of audio blocks and a second number (k) of parity blocks.

[0346] In step S1403, the sink device receives a Low Complexity Communication Codec (LC3) media packet from the source device via a plurality of Broadcast Isochronous Streams (BISs). The LC3 media packet includes the audio blocks and the parity blocks.

[0347] In step S1404, the sink device performs RS-FEC decoding (Reed-Solomon Forward Error Correction decoding) based on the broadcast FEC setting information and recovers lost data from the audio blocks.

[0348]

[0349] According to various embodiments of the present disclosure, the broadcast FEC setting information may be based on RS-FEC (Reed-Solomon Forward Error Correction).

[0350] According to various embodiments of the present disclosure, the broadcast FEC setting information may include a first bit of the least significant bit (LSB) and a second bit of the most significant bit (MSB). The first bit may include a first number of original symbols associated with the audio block. The second bit may include a second number of parity symbols associated with the parity block.

[0351] According to various embodiments of the present disclosure, some of the audio blocks may contain only audio data, and others may contain only parity data. Meta information specifying the existence of audio blocks and parity blocks for each BIS may be provided.

[0352] According to various embodiments of the present disclosure, based on the broadcast FC setting information, each of the plurality of BISs may be composed of only an audio block, or only a parity block, or a combination of an audio block and a parity block.

[0353] According to various embodiments of the present disclosure, the broadcast FEC setting information may be updated in real time according to the wireless channel environment. The updated broadcast FEC setting information may be broadcast within a periodic advertising interval after the update of the broadcast FEC setting information.

[0354] According to various embodiments of the present disclosure, the broadcast FEC configuration information may be included in a Length-Type-Value (LTV) field within the structure of the metadata. The metadata may be received by being included in a Broadcast Audio Stream Announcement (BASE).

[0355]

[0356] According to various embodiments of the present disclosure, a sink device is provided. The sink device includes a third processor corresponding to a host stack; a fourth processor corresponding to a third controller stack; memory; a transceiver; and a speaker device. The host stack and the controller stack are connected by a Host Controller Interface (HCI). The memory may be configured to store instructions for performing a method of operation of the sink device according to FIG. 14, based on execution by the third processor and the fourth processor.

[0357]

[0358] According to various embodiments of the present disclosure, a control device for controlling a sink device is provided. The control device includes at least one processor and at least one memory operably connected to the at least one processor. The at least one memory may be configured to store instructions for performing a method of operating a sink device according to FIG. 14 based on execution by the at least one processor.

[0359]

[0360] According to various embodiments of the present disclosure, one or more non-transitory computer-readable media (CRMs) storing one or more instructions are provided. The one or more instructions perform operations based on execution by one or more processors, and the operations may include a method of operation of a sink device according to FIG. 14.

[0361]

[0362] The claims described in various embodiments of the present disclosure may be combined in various ways. For example, the technical features of the method claims of various embodiments of the present disclosure may be combined to be implemented as a device, and the technical features of the device claims of various embodiments of the present disclosure may be combined to be implemented as a method. Furthermore, the technical features of the method claims and the technical features of the device claims of various embodiments of the present disclosure may be combined to be implemented as a device, and the technical features of the method claims and the technical features of the device claims of various embodiments of the present disclosure may be combined to be implemented as a method.

Claims

1. In a method of operating a source device in a short-range wireless communication system, A step of generating multiple audio blocks encoded with a Low Complexity Communication Codec (LC3); A step of performing Broadcast Forward Error Correction (Broadcast FEC) coding to generate parity blocks based on the plurality of audio blocks above; A step of generating broadcast FEC configuration information related to the first number (n) of the audio blocks and the second number (k) of the parity blocks; A step of broadcasting metadata containing the above broadcast FEC setting information to a sink device; A method comprising the step of transmitting an LC3 media packet including the plurality of audio blocks and the parity blocks to a sink device via a plurality of broadcast isochronous streams (BISs). method.

2. In Paragraph 1, The above broadcast FEC configuration information is based on RS-FEC (Reed-Solomon Forward Error Correction), method.

3. In Paragraph 1, The above broadcast FEC setting information includes first bits of the LSB (Least Significant Bit) and second bits of the MSB (Most Significant Bits), and The first bits above include a first number of original symbols associated with the audio block, and The second bits include a second number of parity symbols associated with the parity block, method.

4. In Paragraph 1, Some of the above audio blocks contain only audio data, and others contain only parity data, and Meta information specifying the existence of audio blocks and parity blocks for each BIS is provided, method.

5. In Paragraph 1, Based on the broadcast FC setting information above, each of the plurality of BISs is composed of only an audio block, or only a parity block, or a combination of an audio block and a parity block. method.

6. In Paragraph 1, The above broadcast FEC setting information is updated in real time according to the wireless channel environment, and The above-mentioned updated broadcast FEC setting information is broadcast within a periodic advertising interval after the update of the above-mentioned broadcast FEC setting information, method.

7. In Paragraph 1, The above broadcast FEC configuration information is included in the Length-Type-Value (LTV) field within the metadata structure, and The above metadata is included in the Broadcast Audio Stream Announcement (BASE) and broadcast, method.

8. A method of operating a sink device included in a plurality of speaker devices in a short-range wireless communication system, A step of receiving metadata from a source device; A step of parsing broadcast FEC configuration information included in the above metadata, The above broadcast FEC setting information is related to a first number (n) of audio blocks and a second number (k) of parity blocks; A step of receiving Low Complexity Communication Codec (LC3) media packets through a plurality of Broadcast Isochronous Streams (BISs) from the source device, The above LC3 media packet includes the audio blocks and the parity blocks; A method comprising the step of performing RS-FEC decoding (Reed-Solomon Forward Error Correction decoding) based on the above broadcast FEC setting information and recovering lost data from audio blocks, method.

9. In Paragraph 8, The above broadcast FEC configuration information is based on RS-FEC (Reed-Solomon Forward Error Correction), method.

10. In Paragraph 8, The above broadcast FEC setting information includes first bits of the LSB (Least Significant Bit) and second bits of the MSB (Most Significant Bits), and The first bits above include a first number of original symbols associated with the audio block, and The second bits include a second number of parity symbols associated with the parity block, method.

11. In Paragraph 8, Some of the above audio blocks contain only audio data, and others contain only parity data, and Meta information specifying the existence of audio blocks and parity blocks for each BIS is provided, method.

12. In Paragraph 8, Based on the broadcast FC setting information above, each of the plurality of BISs is composed of only an audio block, or only a parity block, or a combination of an audio block and a parity block. method.

13. In Paragraph 8, The above broadcast FEC setting information is updated in real time according to the wireless channel environment, and The above-mentioned updated broadcast FEC setting information is broadcast within a periodic advertising interval after the update of the above-mentioned broadcast FEC setting information, method.

14. In Paragraph 8, The above broadcast FEC configuration information is included in the Length-Type-Value (LTV) field within the metadata structure, and The above metadata is received included in a Broadcast Audio Stream Announcement (BASE), method.

15. In a source device of a short-range wireless communication system, A first processor corresponding to a host stack; a second processor corresponding to a controller stack; memory; an input device corresponding to a user interface (UI); an output device corresponding to the UI; and a transceiver, comprising The above host stack and the above controller stack are connected via HCI (Host Controller Interface), and The above memory stores instructions for performing operations based on execution by the first processor and the second processor, and The above operations are, A step of generating multiple audio blocks encoded with a Low Complexity Communication Codec (LC3); A step of performing Broadcast Forward Error Correction (Broadcast FEC) coding to generate parity blocks based on the plurality of audio blocks above; A step of generating broadcast FEC configuration information related to the first number (n) of the audio blocks and the second number (k) of the parity blocks; A step of broadcasting metadata containing the above broadcast FEC setting information to a sink device; A method comprising the step of transmitting an LC3 media packet including the plurality of audio blocks and the parity blocks to a sink device via a plurality of broadcast isochronous streams (BISs). Source device.

16. In Paragraph 15, The above broadcast FEC configuration information is based on RS-FEC (Reed-Solomon Forward Error Correction), Source device.

17. In Paragraph 15, The above broadcast FEC setting information includes first bits of the LSB (Least Significant Bit) and second bits of the MSB (Most Significant Bits), and The first bits above include a first number of original symbols associated with the audio block, and The second bits include a second number of parity symbols associated with the parity block, Source device.

18. In Paragraph 15, Some of the above audio blocks contain only audio data, and others contain only parity data, and Meta information specifying the existence of audio blocks and parity blocks for each BIS is provided, Source device.

19. In Paragraph 15, Based on the broadcast FC setting information above, each of the plurality of BISs is composed of only an audio block, or only a parity block, or a combination of an audio block and a parity block. Source device.

20. In Paragraph 15, The above broadcast FEC setting information is updated in real time according to the wireless channel environment, and The above-mentioned updated broadcast FEC setting information is broadcast within a periodic advertising interval after the update of the above-mentioned broadcast FEC setting information, Source device.

Images