Method and device for assisting in forward error correction for bluetooth broadcast

Abstract

The present disclosure relates to a device and method for reliably transmitting audio data to a plurality of sinks in a broadcast transmission environment of Bluetooth low energy (LE) audio. Specifically, the present disclosure is based on a broadcast isochronous stream (BIS) transmission structure of Bluetooth LE audio. A forward error correction (FEC) technique is applied to solve a problem of a retransmission technique of the prior art in which a time occupancy rate increases in proportion to the number of channels and inefficiency in which original data and parity data need to be distinguished as separate BISs and separately transmitted.

Description

Method and device for supporting Bluetooth broadcast forward error correction

[0001] The present disclosure relates to an apparatus and method for reliably transmitting audio data to multiple receiving devices (sinks) in a broadcast transmission environment of Bluetooth Low Energy (LE) audio. Specifically, the present disclosure is based on a Broadcast Isochronous Stream (BIS) transmission structure of Bluetooth LE audio. To resolve the problem of time occupancy increasing in proportion to the number of channels in conventional retransmission techniques, and the inefficiency of having to transmit original data and parity data separately via BIS, Forward Error Correction (FEC) technology is applied. The present disclosure relates to an apparatus and method for optimizing transmission efficiency and time occupancy and realizing stable multi-channel audio transmission by simultaneously transmitting original audio data and parity data through a single BIS and variably adjusting the amount of parity data according to the wireless channel environment.

[0002]

[0003] With the recent advancement of wireless communication technologies, particularly Bluetooth, the number of applications transmitting audio data wirelessly is increasing explosively. In particular, the Bluetooth Low Energy (BLE) audio standard aims to transmit high-quality audio with low power consumption and is expanding its scope beyond personal audio devices to public broadcast systems.

[0004] In such BLE audio environments, particularly in broadcast settings where multiple sinks receive audio from a single source, the reliability of data transmission is critical. Wireless channels are inherently unstable due to various factors such as interference, signal attenuation, and multipath fading, which can lead to the loss or corruption of audio data packets.

[0005] Data loss severely degrades the user experience by causing 'ticking' noise, interruptions, or complete muting during audio playback. Therefore, BLE audio systems require a robust error control mechanism capable of effectively responding to such packet loss.

[0006] Traditionally, one of the techniques for ensuring data transmission reliability is 'retransmission.' This is a method in which the receiver requests retransmission from the transmitter when it fails to successfully receive the data. However, this technique causes serious inefficiencies when applied to BLE audio transmission, particularly multi-channel transmission.

[0007] When using existing retransmission techniques, a fundamental problem arises in which the time occupied by the wireless medium (time occupancy) increases in multiples of the number of channels as the number of audio channels increases. For example, if the number of channels increases from 2-channel audio to 5-channel audio, the time occupancy does not simply increase but increases rapidly in multiples, resulting in the inefficient use of limited wireless resources.

[0008] Forward Error Correction (FEC) is attracting attention as an alternative to overcome the inefficiency of such retransmission techniques. FEC is a technology that allows the receiving end to correct errors and recover the original data on its own without a retransmission request, even if some data is lost, by adding parity data to the original data and transmitting it.

[0009] However, a specific FEC technique proposed by the Bluetooth SIG (Special Interest Group) also has clear limitations. This proposed technique requires that when transmitting original data and parity data, they be transmitted as separate Broadcast Isochronous Streams (BIS). This complicates stream management and can cause additional synchronization burdens.

[0010] Furthermore, certain FEC techniques proposed by the Bluetooth SIG have a rigid constraint that the number of source data and the number of parity data must be set to be equal. This means that even in situations where the wireless channel environment is good and only a small amount of parity is required, an unnecessarily large amount of parity must be transmitted, resulting in a waste of wireless resources, similar to retransmission techniques. Therefore, there is an urgent need for a new FEC application method that can efficiently transmit data through a single stream while flexibly adapting to the channel environment.

[0011]

[0012] To solve the aforementioned problems, the present disclosure provides a technique for efficiently applying a Forward Error Correction (FEC) algorithm in Bluetooth broadcast transmission.

[0013] The present disclosure provides a technique for varying parity data according to the wireless environment during Bluetooth Low Energy (LE) audio transmission, and a technique for simultaneously transmitting original data and parity data into a single Broadcast Isochronous Stream (BIS) without separating them into separate BISs. Through this, time occupancy can be effectively utilized even if the number of audio channels increases, and the device and method provide a receiver that receives only one BIS, like conventional LE Audio, to support the transmission of up to five audio channels in a Bluetooth 2M PHY environment.

[0014] 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.

[0015]

[0016] 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 audio data and parity data based on RS-FEC (Reed-Solomon Forward Error Correction) coding; variably setting a second number of parity symbols associated with the parity data based on a wireless channel environment; generating RS-FEC setting information including a first number of original symbols associated with the audio data and a second number of parity symbols; broadcasting the RS-FEC setting information through periodic advertising; and transmitting the audio data and parity data simultaneously to a sink device through a single BIS (Broadcast Isochronous Stream) based on the RS-FEC setting information.

[0017] According to various embodiments of the present disclosure, a method of operating a sink device in a short-range wireless communication system is provided, comprising the steps of: receiving RS-FEC (Reed-Solomon Forward Error Correction) setting information broadcast via periodic advertising from a source device; wherein the RS-FEC setting information includes a first number of original symbols associated with audio data and a second number of parity symbols associated with parity data, wherein the second number of parity symbols is variably set based on a wireless channel environment, and wherein the audio data and parity data are based on RS-FEC coding; and, based on the RS-FEC setting information, receiving audio data and parity data simultaneously from the source device through a single BIS (Broadcast Isochronous Stream).

[0018] 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, wherein the operations include: generating audio data and parity data based on Reed-Solomon Forward Error Correction (RS-FEC) coding; variably setting a second number of parity symbols associated with the parity data based on a wireless channel environment; generating RS-FEC setting information including a first number of original symbols associated with the audio data and a second number of parity symbols; and broadcasting the RS-FEC setting information through periodic advertising. A source device is provided that includes the step of simultaneously transmitting audio data and parity data to a sink device through a single BIS (Broadcast Isochronous Stream) based on the above RS-FEC setting information.

[0019]

[0020] To solve the aforementioned problems, the present disclosure can provide a technique for efficiently applying a Forward Error Correction (FEC) algorithm in Bluetooth broadcast transmission.

[0021] The present disclosure provides a technique for varying parity data according to the wireless environment during Bluetooth Low Energy (LE) audio transmission, and a technique for simultaneously transmitting original data and parity data into a single Broadcast Isochronous Stream (BIS) without separating them into separate BISs. Through this, time occupancy can be effectively utilized even if the number of audio channels increases, and a device and method can be provided that support transmission of up to 5 audio channels in a Bluetooth 2M PHY environment by receiving only one BIS, as in conventional LE Audio.

[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] 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.

[0031] 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.

[0032] FIG. 9 illustrates an example of a graph comparing packet error rate (Coded PER) performance according to the wireless channel environment (PHY PER) when RS coding (RS(4,2), RS(5,2), RS(6,2)) is applied.

[0033] FIG. 10 illustrates an example of a flow for transmitting audio data and parity data to a single BIS when 2-channel audio and RS (4,2) coding (good wireless environment) is set as an embodiment of the present disclosure.

[0034] FIG. 11 illustrates an example of a link layer transmission parameter table corresponding to the RS (4,2) coding settings of the present disclosure.

[0035] FIG. 12 illustrates an example of a flow for transmitting audio data and parity data to a single BIS when 2-channel audio and RS (5,2) coding (usually in a wireless environment) is set as an embodiment of the present disclosure.

[0036] FIG. 13 illustrates an example of a link layer transmission parameter table corresponding to the RS (5,2) coding settings of the present disclosure.

[0037] FIG. 14 illustrates an example of a flow for transmitting audio data and parity data to a single BIS when 2-channel audio and RS (6,2) coding (bad wireless environment) is set as an embodiment of the present disclosure.

[0038] FIG. 15 illustrates an example of a link layer transmission parameter table corresponding to the RS (6,2) coding settings of the present disclosure.

[0039] FIG. 16 illustrates an example of a message sequence chart illustrating the advertising, speaker discovery, and capability exchange steps (1 / 2) of the Surround Service Audio Service (SSAP) connection procedure proposed in the present disclosure.

[0040] FIG. 17 illustrates an example of a message sequence chart illustrating the multichannel and RS-FEC setup and broadcast stream transmission steps (2 / 2) of the SSAP connection procedure proposed in the present disclosure.

[0041] FIG. 18 is an Appendix to the present disclosure and illustrates an example of packet allocation and a single BIS transmission structure for 4.1 channel audio (RS(10,5)).

[0042] FIG. 19 illustrates an example of a link layer transmission parameter table corresponding to a 4.1 channel audio (RS(10,5)) setting of the present disclosure.

[0043] FIG. 20 illustrates an example of a Link Layer transmission timing corresponding to a 4.1 channel audio (RS(10,5)) setting of the present disclosure.

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

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

[0046]

[0047] 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."

[0048] 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."

[0049] 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."

[0050] 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.”

[0051]

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

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

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

[0055] 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.

[0056] 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.

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

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

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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.

[0072] 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.

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

[0074] 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).

[0075] 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.

[0076] 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).

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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.

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

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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.

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

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

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

[0089] 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.

[0090] 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.

[0091] 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.

[0092] 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.

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

[0094] 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.

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

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

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

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

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

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

[0101] 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).

[0102] 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.

[0103] ② 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.

[0104] ③ 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.

[0105] ④ 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.

[0106] 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.

[0107] 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.

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

[0109] ② Include: Defines the relationships between services

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

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

[0112] 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.

[0113] Battery: How to exchange battery information

[0114] Time: Method of exchanging time information

[0115] FindMe: Provides distance-based alarm service

[0116] Proximity: Battery Information Exchange Method

[0117] Time: Method of exchanging time information

[0118] 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.

[0119] 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.

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

[0121] 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.

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

[0123] 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.

[0124] 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.

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

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

[0127] Device Filtering Procedure

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

[0129] 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.

[0130] 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.

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

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

[0133] 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.

[0134] 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.

[0135] 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.

[0136] Advertising Procedure

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

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

[0139] 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 the listening device).

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

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

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

[0143] 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.

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

[0145] 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.

[0146] Scanning Procedure

[0147] 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.

[0148] 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.

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

[0150] 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.

[0151] 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.

[0152] Discovery Procedure

[0153] 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.

[0154] 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.

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

[0156] Connecting Procedure

[0157] 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.

[0158] 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.

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

[0160] Advertising State

[0161] 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.

[0162] 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.

[0163] Scanning State

[0164] 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.

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

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

[0167] 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.

[0168] 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.

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

[0170] 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.

[0171] Initiating State

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

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

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

[0175] connection state

[0176] 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.

[0177] 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.

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

[0179] 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 the master and the slave are synchronized.

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

[0181] Packet Format

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

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

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

[0185] Advertising Channel PDU

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

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

[0188] 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

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

[0190] ADV_IND: Connectable non-directional ad event

[0191] ADV_DIRECT_IND: Connectable directional ad events

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

[0193] ADV_SCAN_IND: Scannable non-directional ad event

[0194] 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.

[0195] Scanning PDU

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

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

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

[0199] Initiating PDU

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

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

[0202] Data Channel PDU

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

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

[0205]

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

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

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

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

[0210] 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.

[0211] 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.

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

[0213] 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).

[0214] 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.

[0215] 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.

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

[0217] - handle: address of the attribute

[0218] - Type: Type of the attribute

[0219] - Value: The value of the attribute

[0220] - Permission: Access rights to the property

[0221]

[0222] 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.

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

[0224] 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).

[0225] 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.

[0226] 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.

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

[0228] 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.

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

[0230] 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.

[0231] 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.

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

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

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

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

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

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

[0238] 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.

[0239] 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.

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

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

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

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

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

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

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

[0247] 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.

[0248] Isochronous Channel General

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

[0250] 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.

[0251] 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.

[0252] 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.

[0253] 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.

[0254] Definition of Isochronous Channels and Related Mechanisms

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

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

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

[0258] 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.

[0259]

[0260] Composition of various embodiments of the present disclosure

[0261] Problems with conventional technology

[0262] When transmitting audio using Bluetooth's BLE transmission technology, if conventional retransmission techniques are used, a problem occurs where the time occupancy increases in multiples of the number of channels as the number of channels increases.

[0263] The FEC technique proposed to the Bluetooth SIG in 2023 is a technique that separates and transmits Original Data and Parity Data using BIS, but it has the problem that the number of Original Data and Parity Data must be the same.

[0264]

[0265] Summary of various embodiments of the present disclosure

[0266] The present disclosure provides a technique for applying an FEC algorithm in Bluetooth broadcast transmission.

[0267] The present disclosure provides a technique for varying Parity Data to suit the wireless environment when the number of audio channels increases by applying a Forward Error Correction (FEC) algorithm in Bluetooth.

[0268] The present disclosure provides a technique for simultaneously transmitting Original Data and Parity Data to a single BIS without distinguishing between Original Data and Parity Data in the BIS.

[0269] The present disclosure provides a method for transmitting RS-FEC parameters between a central device and a peripheral device.

[0270]

[0271] Effects of various embodiments of the present disclosure

[0272] Through various embodiments of the present disclosure, up to 5 audio channels can be transmitted in a Bluetooth 2M PHY by using the Broadcast FEC technique.

[0273] Through various embodiments of the present disclosure, the Parity Data can be varied to suit the wireless environment even as the number of audio channels increases, so the time occupancy can be used effectively.

[0274] Through the various embodiments of the present disclosure, since transmission is not separated by BIS, there is no need to match the number of Original Data and Parity Data.

[0275] Through various embodiments of the present disclosure, the Source device can perform other services to the extent of the time share saved.

[0276] Through various embodiments of the present disclosure, the receiver only needs to receive one BIS, like conventional LE Audio.

[0277]

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

[0279] 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.

[0280] 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.

[0281] 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.

[0282] 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.

[0283]

[0284] 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.

[0285] 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.

[0286] 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).

[0287] The key feature of Fig. 7 is that the four generated 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.

[0288] 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'.

[0289]

[0290] 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.

[0291] 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.

[0292] 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).

[0293] 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%.

[0294] 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.

[0295]

[0296] FIG. 9 illustrates an example of a graph comparing packet error rate (Coded PER) performance according to the wireless channel environment (PHY PER) when RS coding (RS(4,2), RS(5,2), RS(6,2)) is applied.

[0297] FIG. 9 is a graph comparing the packet error rate (Coded PER) performance according to the wireless channel environment (PHY PER) when applying the RS (Reed-Solomon) coding proposed in the present disclosure. This graph presents the performance basis of the variable FEC technique proposed in the present invention.

[0298] The X-axis of the graph represents the physical layer packet error rate (PHY PER), which indicates how poor the wireless channel environment is. The Y-axis represents the final packet error rate (Coded PER) after RS ​​coding is applied on a logarithmic scale, and this graph shows the performance when only FEC is applied without retransmission (No ReTx) in a 2-channel audio environment.

[0299] The graph compares three variable FEC settings according to the present invention: RS(4,2), RS(5,2), and RS(6,2). RS(4,2) means 2 originals and 2 parities, and RS(6,2) means 2 originals and 4 parities.

[0300] As can be clearly seen from the graph, as parity data increases (e.g., from RS(4,2) to RS(6,2)), the Coded PER decreases significantly even in the same PHY PER environment. This means that error recovery performance becomes stronger as parity increases, and provides the technical basis for the present invention to variably adjust the amount of parity according to the channel environment.

[0301]

[0302] FIG. 10 illustrates an example of a flow for transmitting audio data and parity data to a single BIS when 2-channel audio and RS (4,2) coding (good wireless environment) is set as an embodiment of the present disclosure.

[0303] FIG. 10 illustrates a flow for transmitting audio data and parity data to a single BIS when 2-channel audio and RS (4,2) coding is configured as a key embodiment of the present disclosure. This configuration corresponds to a 'good' wireless channel environment.

[0304] In this configuration, data from two original audio channels (Audio Ch1, Ch2) (120 bytes each) is input to the RS(4,2) encoder. The encoder generates two original SDUs and two parity SDUs (Parity 1, Parity 2).

[0305] As a key feature of the present invention, the four encoded SDUs (two originals and two parities) are not separated into separate streams, unlike the prior art (Fig. 8). Instead, they are all transmitted together as 'To BIS 1', that is, as one BIS.

[0306] This configuration has a total of four sub-events (SE 1-4) and has a low time occupancy of approximately 26% during a 10ms BIG event ISO interval. This demonstrates the effect of the present invention, which effectively utilizes wireless resources (time occupancy) by minimizing parity when the channel environment is good.

[0307]

[0308] FIG. 11 illustrates an example of a link layer transmission parameter table corresponding to the RS (4,2) coding settings of the present disclosure.

[0309] FIG. 11 illustrates an example of a detailed link layer transmission parameter table corresponding to the RS (4,2) coding settings of FIG. 10. By referring to the 'RS FEC' setting section, it can be clearly seen that for 2-channel audio (ch1, ch2), 'Original Data [Symbol]' is set to 2 and 'Parity [Symbol]' is set to 2.

[0310] Accordingly, referring to the 'Link Layer Transport' setting section, there are a total of 4 'Code_word[Symbol]'s. Also, according to the features of the present invention, the number of BIS ('Num_BIS') is set to 1, and the number of sub-events ('NSE') is set to 4, which is the same as the total number of codewords.

[0311] Based on these parameter settings (Num_BIS=1, NSE=4, Sub_Interval=690us, MPT=540us), the finally calculated 'Calculated BIG_Sync_delay' is 2610us (approx. 2.61ms). This is a specific transmission timing value corresponding to a 26% time share shown in Fig. 10.

[0312]

[0313] FIG. 12 illustrates an example of a flow for transmitting audio data and parity data to a single BIS when 2-channel audio and RS (5,2) coding (usually in a wireless environment) is set as an embodiment of the present disclosure.

[0314] FIG. 12 illustrates an RS (5,2) coding setting and transmission flow applied when the wireless channel environment is 'normal' as another embodiment of the present disclosure. This is an example showing the application of 'variable parity' of the present invention, contrasting with the RS (4,2) setting of FIG. 10.

[0315] This setting generates three parities (Parity 1, 2, 3) for two original audio channels (Audio Ch1, Ch2) by increasing the amount of parity to respond to channel environment deterioration. This demonstrates the core feature of the present invention of varying parity data to suit the channel environment.

[0316] As in the case of Fig. 10, a total of 5 SDUs (2 originals and 3 parities) generated through RS(5,2) encoding are all transmitted simultaneously through 'To BIS 1', that is, one BIS.

[0317] This configuration has a total of 5 sub-events (SE 1-5), and the time share increases to approximately 33% as the parity increases by 1. This is the result of adaptively trading off the time share to increase transmission reliability.

[0318]

[0319] FIG. 13 illustrates an example of a link layer transmission parameter table corresponding to the RS (5,2) coding settings of the present disclosure.

[0320] FIG. 13 illustrates an example of a detailed link layer transmission parameter table corresponding to the RS (5,2) coding settings of FIG. 12. By referring to the 'RS FEC' setting section of the table, it can be seen that for 2-channel audio (ch1, ch2), 'Original Data [Symbol]' remains the same at 2, but 'Parity [Symbol]' has been increased to 3.

[0321] Accordingly, referring to the 'Link Layer Transport' settings, the total number of 'Code_word[Symbol]' is 5. The number of BIS ('Num_BIS') is still 1, and the number of sub-events ('NSE') is set to 5.

[0322] Due to these parameter setting changes, 'Calculated BIG_Sync_delay' is calculated to be 3300us (approx. 3.3ms). This is a specific transmission timing value corresponding to a 33% time share shown in Fig. 12.

[0323]

[0324] FIG. 14 illustrates an example of a flow for transmitting audio data and parity data to a single BIS when 2-channel audio and RS (6,2) coding (bad wireless environment) is set as an embodiment of the present disclosure.

[0325] FIG. 14 illustrates an RS (6,2) coding setting and transmission flow applied in a wireless channel environment 'bad' as another embodiment of the present disclosure. This setting represents a case where the highest level of error correction performance among the variable FEC levels of the present invention is provided.

[0326] This setting is generated for two original audio channels (Audio Ch1, Ch2) by maximizing the amount of parity to four (Parity 1, 2, 3, 4) for the strongest error recovery. This matches the setting that showed the best error recovery performance in the graph of Fig. 9.

[0327] A total of 6 SDUs (2 originals and 4 parities) generated through RS(6,2) encoding are also transmitted simultaneously through 'To BIS 1', that is, one BIS, according to the features of the present invention.

[0328] This configuration has a total of 6 sub-events (SE 1-6), and the time share is set highest at approximately 40%. This clearly demonstrates the adaptive feature of the present invention, which ensures transmission reliability by dynamically increasing parity (4) as the channel environment deteriorates.

[0329]

[0330] FIG. 15 illustrates an example of a link layer transmission parameter table corresponding to the RS (6,2) coding settings of the present disclosure.

[0331] FIG. 15 illustrates an example of a detailed link layer transmission parameter table corresponding to the RS (6,2) coding settings of FIG. 14. By referring to the ‘RS FEC’ setting section of the table, it can be seen that for 2-channel audio (ch1, ch2), ‘Original Data [Symbol]’ is set to 2 and ‘Parity [Symbol]’ is set to 4.

[0332] Accordingly, referring to the 'Link Layer Transport' settings, there are a total of 6 'Code_word[Symbol]'s. The number of BIS ('Num_BIS') is 1, and the number of sub-events ('NSE') is set to 6.

[0333] With these parameter settings, 'Calculated BIG_Sync_delay' is calculated to be 3990us (approx. 3.99ms). This is a specific transmission timing value corresponding to a 40% time share shown in Fig. 14.

[0334]

[0335] FIG. 16 illustrates an example of a message sequence chart illustrating the advertising, speaker discovery, and capability exchange steps (1 / 2) of the Surround Service Audio Service (SSAP) connection procedure proposed in the present disclosure.

[0336] FIG. 16 is a message sequence chart (MSC) illustrating the first half (1 / 2) of the Surround Service Audio Service (SSAP) connection procedure proposed in the present disclosure. This chart shows the interaction between a smartphone (controller), an LG soundbar (SSAP source / Broadcast Assistance), and a plurality of LG speakers (SSAP sink / Broadcast Sink).

[0337] The first step of the process is device discovery. When the controller requests a speaker scan, the sink devices perform advertising, including an SSAP UUID (0x18AA), etc. The controller sends the list of scanned speakers to the soundbar (source).

[0338] The second step of the procedure is service discovery. When the user selects a speaker and commands a connection, the soundbar establishes a BLE connection and performs GATT discovery with each speaker. Subsequently, the soundbar transmits the speaker's capabilities (SSAP capabilities, e.g., audio role, codec, location, Max SPL, etc.) to the controller to display to the user.

[0339]

[0340] FIG. 17 illustrates an example of a message sequence chart illustrating the multichannel and RS-FEC setup and broadcast stream transmission steps (2 / 2) of the SSAP connection procedure proposed in the present disclosure.

[0341] FIG. 17 is a message sequence chart (MSC) illustrating the latter part (2 / 2) of the SSAP connection procedure following FIG. 16. This chart shows in detail how the RS-FEC settings, which are the core of the present invention, are exchanged and how the stream is initiated.

[0342] The third step of the procedure is multichannel audio configuration. When the user sets the configuration on the controller, the soundbar (source) sets up an SSAP configuration containing multichannel allocation information for the selected sink devices.

[0343] The fourth step of the procedure is the setup and transmission of a broadcast stream. When the user commands audio start, the soundbar sets up a broadcast configuration (BASE) containing RS-FEC configuration information according to the present invention. This configuration information is broadcast to the sinks via periodic advertising.

[0344] Subsequently, the soundbar starts the RS-FEC encoder, and the sink devices receive the advertisement and start the RS-FEC decoder. Finally, the soundbar broadcasts multi-channel audio encoded in RS-FEC through 'BIS 1', i.e., a single BIS, and the sink devices receive this and play the synchronized audio.

[0345]

[0346] FIGS. 16 and 17 are flowcharts and related configuration diagrams for illustrating a Surround Service Audio Service (SSAP) connection procedure according to one embodiment of the present disclosure. This procedure details the process of establishing a multi-channel audio stream between a source device (e.g., a soundbar) and one or more sink devices (e.g., a speaker). The entire procedure can be broadly divided into four steps: device discovery, service discovery, LE audio configuration, and LE audio stream transmission.

[0347] 1. Device discovery

[0348] The first step of the procedure corresponding to the first part of FIG. 16 is the device discovery step. In this step, the sink device performs LE advertising to announce its presence. The advertisement may include a Surround Service Audio Service (SSAS) UUID to identify that it is a surround audio service according to the present disclosure, for example, a temporary UUID 0x18AA.

[0349] Additionally, the advertisement may include device information necessary for a controller (e.g., a smartphone) or source device to identify a sink device. This information includes manufacturer information (e.g., LGE) and a device name indicating the role or type of the device (e.g., High / Mid / Low / Full_Mono / Stereo).

[0350] 2. Service discovery

[0351] The second step is the Service discovery step, which is performed based on the GATT (Generic Attribute Profile) sub-procedure. After the source device establishes an LE connection with the sink device, the source device discovers the SSAP services and related characteristics provided by the sink device.

[0352] The key SSAP characteristics being searched may include 'Sink Feature characteristic' and 'Control point characteristic'. The 'Sink Feature characteristic' has a read attribute and can use the temporary UUID 0x2CF0. The value of this characteristic may include Max-SPL characteristics related to the audio performance of the sink device or presentation delay information for synchronization. The 'Control point characteristic' has a write attribute and can use the temporary UUID 0x2CF1, and is used for the source device to write logical audio channel allocation values ​​to the sink device.

[0353] In the service discovery phase, in addition to SSAP-related characteristics, standard LE Audio profiles may also be discovered. These include the Published Audio Capabilities Service (PACS), which contains codec capabilities and location information of the sink device; the Broadcast Audio Scan Service (BASS), which indicates the broadcast reception status; and the Volume Control Profile (VCP) for volume control.

[0354] 3. LE Audio (Broadcast) Configuration

[0355] The third step of the procedure corresponding to the latter part of Fig. 17 is the LE audio (broadcast) configuration step for multichannel audio using RS-FEC. This step is further divided into multichannel configuration and broadcast audio stream configuration. Multichannel configuration is performed using the previously identified 'Audio_Channel_Allocation Value', and the source device allocates an audio channel to each SSAP sink device through this value (e.g., bitmap 0B00000001).

[0356] Next, a Broadcast Audio Stream configuration is performed. The source device enters Broadcast mode and Periodic Advertising mode. As a key feature of the present invention, at this stage, the source device uses a modified BASE (Broadcast Audio Stream Establishment) structure and adds RS-FEC configuration information according to the present invention within the LTV (Length-Type-Value) structure of the metadata included in the periodic advertisement.

[0357] This RS-FEC configuration information defines Reed-Solomon encoding and decoding parameters and can have, for example, a size of 1 octet. Specifically, the 4 bits of the LSB of this 1 octet represent the 'number of original symbols', and the 4 bits of the MSB represent the 'number of parity symbols'. This information can be efficiently transmitted to sink devices using a vendor-specific LTV structure within the standard.

[0358] 4. LE Audio (Broadcast) Stream

[0359] The final fourth step is the LE audio (broadcast) stream transmission step. The source device performs the broadcast audio stream establishment procedure.

[0360] Afterwards, the source device enters Broadcast Isochronous Broadcasting mode. Finally, the source device activates the audio data path and transmits the encoded audio stream to the sink device according to the RS-FEC configuration (number of source symbols and number of parity symbols) set and advertised in Step 3.

[0361]

[0362] FIG. 18 is an Appendix to the present disclosure and illustrates an example of packet allocation and a single BIS transmission structure for 4.1 channel audio (RS(10,5)).

[0363] FIG. 18 illustrates a packet allocation and single BIS transmission structure for 4.1 channels (i.e., 5 audio channels) as an embodiment shown in the Appendix of the present disclosure. This example demonstrates that the technique of the present invention can be extended beyond 2 channels to a multi-channel environment.

[0364] This example demonstrates the scalability of the present invention and shows that five original audio channels (Audio Ch1 to Ch5) are LC3 encoded from PCM data. Subsequently, RS(10,5) coding is applied to generate five original SDUs and five parity data (Parity 1 to Parity 5).

[0365] The core features of the present invention are applied identically, so that the encoded 5 original SDUs (green) and 5 parity SDUs (red) are all combined to form a total of 10 SDUs. All of these 10 SDUs are transmitted through 'To BIS 1', that is, through a single BIS.

[0366] This configuration is transmitted as a total of 10 sub-events (SE 1 to SE 10) within a 10ms BIG event ISO interval. This is a specific example demonstrating that up to 5 audio channels can be transmitted in a Bluetooth 2M PHY environment by using the FEC technique of the present invention.

[0367]

[0368] FIG. 19 illustrates an example of a link layer transmission parameter table corresponding to a 4.1 channel audio (RS(10,5)) setting of the present disclosure.

[0369] Specifically, FIG. 19 illustrates an example of a detailed link layer transmission parameter table corresponding to the 4.1 channel audio (RS(10,5)) setting of FIG. 18. This table defines specific link layer values ​​for transmitting 5-channel audio and 5-channel parity.

[0370] If you refer to the 'Audio Sinks' item in the table, you can see that 'Audio_Ch Count' is set to 5 channels (4.1ch). If you refer to the 'RS FEC Configuration' section, 'Original Data [Symbol]' is set to 5 and 'Parity [Symbol]' is set to 5, so there are a total of 10 'Code word [Symbol]'.

[0371] Accordingly, referring to the 'Link Layer Configuration' section, 'ISO Interval' is set to 10ms, 'Num_BIS' (number of BIS) to 1, 'BN' (Burst Number) to 10, and 'NSE' (number of sub-events) to 10. This means that 10 SDUs are transmitted as 10 sub-events through 1 BIS.

[0372] Based on these 4.1 channel parameter settings (NSE=10, Sub_Interval=690us, MPT=540us), the calculated 'BIG_Sync_delay (Airtime)' is 6750us (approx. 6.75ms). This demonstrates that 5-channel source and 5-channel parity transmission are sufficiently possible within an ISO interval of 10ms.

[0373]

[0374] FIG. 20 illustrates an example of a Link Layer transmission timing corresponding to a 4.1 channel audio (RS(10,5)) setting of the present disclosure.

[0375] Specifically, FIG. 20 illustrates in detail an example of link layer timing for a 4.1 channel Surround Service Audio Service (SSAP) as an embodiment of the present disclosure. FIG. 20 shows the process of a source device establishing and transmitting a broadcast stream in chronological order in terms of primary, secondary, periodic advertising channels, and actual data transmission channels (BIG).

[0376] The upper part of FIG. 20 shows the sequential operation of primary, secondary, and periodic advertising channels. In the primary advertising channel, an ADV_EXT_IND packet is transmitted with an advertising interval of 80ms. This points to the AUX_ADV_IND of the secondary advertising channel, and the AUX_ADV_IND again points to the AUX_SYNC_IND packet of the periodic advertising channel with a periodic interval of 80ms.

[0377] As a core component of the present invention, AUX_SYNC_IND transmitted through a periodic advertising channel includes BIG Info and AdvData. In particular, this advertisement includes a BASE (Broadcast Audio Stream Establishment) structure in which RS-FEC configuration information (Add RS-FEC configuration) is explicitly added according to the present invention. Additionally, this advertisement includes a 'Basic Audio Announcement Service UUID' to enable a sync device to identify the corresponding broadcast stream as an audio service according to the present invention.

[0378] The bottom part of Fig. 20 illustrates a Broadcast Isochronous Stream (BIS) event in which actual audio data is transmitted according to the BIG Parameter set by the periodic advertisement. In this 4.1 channel example, the 'BIG Parameter' indicates that Num_BIS is set to 1, meaning all original data and parity data are transmitted through a single BIS. Additionally, the ISO Interval is set to 10ms, and both the Burst Number and NSE (Number of Sub-events) are set to 10; a 2M PHY mode with no retransmission (RTN=0) is used sequentially.

[0379] Within an ISO interval of 10ms, a total of 10 bursts are transmitted as shown in the legend. This corresponds to the RS (10,5) setting in FIGS. 18 and 19, which visually clearly shows that 5 original data (green) and 5 parity data (red) are sequentially included and transmitted within a single BIS stream.

[0380]

[0381] [Explanation regarding source device claim]

[0382] The embodiments described above will be explained in detail below with reference to FIG. 21 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.

[0383] FIG. 21 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.

[0384] 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.

[0385] 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).

[0386] In step S2101, the source device generates audio data and parity data based on RS-FEC (Reed-Solomon Forward Error Correction) coding.

[0387] In step S2102, the source device variably sets a second number of parity symbols associated with the parity data based on the wireless channel environment.

[0388] In step S2103, the source device generates RS-FEC setting information including a first number of original symbols associated with the audio data and a second number of parity symbols.

[0389] In step S2104, the source device broadcasts the RS-FEC setting information via periodic advertising.

[0390] In step S2105, the source device transmits audio data and parity data simultaneously to the sink device through a single BIS (Broadcast Isochronous Stream) based on the RS-FEC setting information.

[0391]

[0392] According to various embodiments of the present disclosure, the RS-FEC setting information may include a plurality of first bits corresponding to the least significant bit (LSB) and a plurality of second bits corresponding to the most significant bit (MSB). The first bits may include the first number of the original symbols. The second bits may include the second number of the parity symbols.

[0393] According to various embodiments of the present disclosure, the wireless channel environment may be determined based on the Received Signal Strength Indicator (RSSI) or the Packet Error Rate (PER). The Reed-Solomon Forward Error Correction (RS-FEC) coding may be performed according to the determined wireless channel environment.

[0394] According to various embodiments of the present disclosure, the transmission interval (ISO interval) of the BIS can be adjusted based on the time share that changes according to the RS-FEC setting information.

[0395] According to various embodiments of the present disclosure, the RS-FEC setting information may be inserted into the Length-Type-Value (LTV) field of a metadata structure and broadcast through the Periodic Advertising.

[0396] According to various embodiments of the present disclosure, the RS-FEC (Reed-Solomon Forward Error Correction) setting information may be expressed in the form RS(n, k) based on a first number (n) of original symbols and a second number (k) of parity symbols. Each bit field of the RS-FEC setting information may be encoded in a Length-Type-Value (LTV) format and configured to be identifiable within the metadata structure of the broadcast data.

[0397] According to various embodiments of the present disclosure, the RS-FEC setting information may be updated according to changes in the wireless channel environment and broadcast through the periodic advertisement.

[0398]

[0399] 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. 21 based on execution by the first processor and the second processor.

[0400]

[0401] 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. 21 based on execution by the at least one processor.

[0402]

[0403] 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. 21.

[0404]

[0405] [Explanation regarding sink device claim]

[0406] The embodiments described above will be explained in detail below with reference to FIG. 22 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 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.

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

[0408] 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.

[0409] 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).

[0410] In step S2201, the sink device receives RS-FEC (Reed-Solomon Forward Error Correction) configuration information broadcast via periodic advertising from the source device. The RS-FEC configuration information includes a first number of original symbols associated with audio data and a second number of parity symbols associated with parity data. The second number of parity symbols is variably set based on the wireless channel environment. The audio data and parity data are based on RS-FEC coding.

[0411] In step S2202, the sink device receives audio data and parity data simultaneously from the source device through a single BIS (Broadcast Isochronous Stream) based on the RS-FEC setting information.

[0412]

[0413] According to various embodiments of the present disclosure, the RS-FEC setting information may include a plurality of first bits corresponding to the least significant bit (LSB) and a plurality of second bits corresponding to the most significant bit (MSB). The first bits may include the first number of the original symbols. The second bits may include the second number of the parity symbols.

[0414] According to various embodiments of the present disclosure, the wireless channel environment may be determined based on the Received Signal Strength Indicator (RSSI) or the Packet Error Rate (PER). The Reed-Solomon Forward Error Correction (RS-FEC) coding may be performed based on the wireless channel environment. According to various embodiments of the present disclosure, the transmission interval (ISO interval) of the BIS may be adjusted based on the time share that changes according to the RS-FEC setting information.

[0415] According to various embodiments of the present disclosure, the RS-FEC setting information may be inserted into the Length-Type-Value (LTV) field of a metadata structure and broadcast through the Periodic Advertising.

[0416] According to various embodiments of the present disclosure, the RS-FEC (Reed-Solomon Forward Error Correction) setting information may be expressed in the form RS(n, k) based on a first number (n) of original symbols and a second number (k) of parity symbols. Each bit field of the RS-FEC setting information may be encoded in a Length-Type-Value (LTV) format and configured to be identifiable within the metadata structure of the broadcast data.

[0417] According to various embodiments of the present disclosure, the RS-FEC setting information may be updated according to changes in the wireless channel environment and broadcast through the periodic advertisement.

[0418]

[0419] 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. 22 based on execution by the third processor and the fourth processor.

[0420]

[0421] According to various embodiments of the present disclosure, a control device for controlling a sink 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 a sink device according to FIG. 22 based on execution by the at least one processor.

[0422]

[0423] 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. 22.

[0424]

[0425] 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 audio data and parity data based on RS-FEC (Reed-Solomon Forward Error Correction) coding; A step of variably setting a second number of parity symbols associated with the parity data based on a wireless channel environment; A step of generating RS-FEC setting information including a first number of original symbols associated with the above audio data and a second number of the above parity symbols; A step of broadcasting the above RS-FEC setting information through periodic advertising; Based on the above RS-FEC setting information, the method includes the step of simultaneously transmitting audio data and parity data to a sink device through a single BIS (Broadcast Isochronous Stream). method.

2. In Paragraph 1, The above RS-FEC setting information includes a plurality of first bits corresponding to the LSB (least significant bit) and a plurality of second bits corresponding to the MSB (most significant bit), and The first bits above include the first number of the original symbols, and The second bits include the second number of the parity symbols, method.

3. In Paragraph 1, The above wireless channel environment is determined based on the Received Signal Strength Indicator (RSSI) or the Packet Error Rate (PER), and The above RS-FEC (Reed-Solomon Forward Error Correction) coding is performed according to the determined wireless channel environment, method.

4. In Paragraph 1, The transmission interval (ISO interval) of the above BIS is adjusted based on the time share that changes according to the above RS-FEC setting information, method.

5. In Paragraph 1, The above RS-FEC configuration information is inserted into the Length-Type-Value (LTV) field of the metadata structure and broadcast through the above Periodic Advertising, method.

6. In Paragraph 1, The above RS-FEC (Reed-Solomon Forward Error Correction) setting information is expressed in the form RS(n, k) based on a first number (n) of original symbols and a second number (k) of parity symbols, and Each bit field of the above RS-FEC configuration information is encoded in a Length-Type-Value (LTV) format and configured to be identifiable within the metadata structure of the broadcast data, method.

7. In Paragraph 1, The above RS-FEC setting information is updated according to changes in the wireless channel environment and broadcast through the above periodic advertisement, method.

8. A method of operating a sink device in a short-range wireless communication system, A step of receiving RS-FEC (Reed-Solomon Forward Error Correction) setting information broadcast via periodic advertising from a source device, The above RS-FEC setting information includes a first number of original symbols related to audio data and a second number of parity symbols related to parity data, and The second number of the above parity symbols is variably set based on the wireless channel environment, and The above audio data and parity data are based on RS-FEC coding; Based on the above RS-FEC setting information, the method includes the step of simultaneously receiving audio data and parity data from the source device through a single BIS (Broadcast Isochronous Stream). method.

9. In Paragraph 8, The above RS-FEC setting information includes a plurality of first bits corresponding to the LSB (least significant bit) and a plurality of second bits corresponding to the MSB (most significant bit), and The first bits above include the first number of the original symbols, and The second bits include the second number of the parity symbols, method.

10. In Paragraph 8, The above wireless channel environment is determined based on the Received Signal Strength Indicator (RSSI) or the Packet Error Rate (PER), and The above RS-FEC (Reed-Solomon Forward Error Correction) coding is performed based on the above wireless channel environment, method.

11. In Paragraph 8, The transmission interval (ISO interval) of the above BIS is adjusted based on the time share that changes according to the above RS-FEC setting information, method.

12. In Paragraph 8, The above RS-FEC configuration information is inserted into the Length-Type-Value (LTV) field of the metadata structure and broadcast through the above Periodic Advertising, method.

13. In Paragraph 8, The above RS-FEC (Reed-Solomon Forward Error Correction) setting information is expressed in the form RS(n, k) based on a first number (n) of original symbols and a second number (k) of parity symbols, and Each bit field of the above RS-FEC configuration information is encoded in a Length-Type-Value (LTV) format and configured to be identifiable within the metadata structure of the broadcast data, method.

14. In Paragraph 8, The above RS-FEC setting information is updated according to changes in the wireless channel environment and broadcast through the above periodic advertisement, 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 audio data and parity data based on RS-FEC (Reed-Solomon Forward Error Correction) coding; A step of variably setting a second number of parity symbols associated with the parity data based on a wireless channel environment; A step of generating RS-FEC setting information including a first number of original symbols associated with the above audio data and a second number of the above parity symbols; A step of broadcasting the above RS-FEC setting information through periodic advertising; Based on the above RS-FEC setting information, the method includes the step of simultaneously transmitting audio data and parity data to a sink device through a single BIS (Broadcast Isochronous Stream). Source device.

16. In Paragraph 15, The above RS-FEC setting information includes a plurality of first bits corresponding to the LSB (least significant bit) and a plurality of second bits corresponding to the MSB (most significant bit), and The first bits above include the first number of the original symbols, and The second bits include the second number of the parity symbols, Source device.

17. In Paragraph 15, The above wireless channel environment is determined based on the Received Signal Strength Indicator (RSSI) or the Packet Error Rate (PER), and The above RS-FEC (Reed-Solomon Forward Error Correction) coding is performed according to the determined wireless channel environment, Source device.

18. In Paragraph 17, The transmission interval (ISO interval) of the above BIS is adjusted based on the time share that changes according to the above RS-FEC setting information, Source device.

19. In Paragraph 15, The above RS-FEC configuration information is inserted into the Length-Type-Value (LTV) field of the metadata structure and broadcast through the above Periodic Advertising, Source device.

20. In Paragraph 15, The above RS-FEC (Reed-Solomon Forward Error Correction) setting information is expressed in the form RS(n, k) based on a first number (n) of original symbols and a second number (k) of parity symbols, and Each bit field of the above RS-FEC configuration information is encoded in a Length-Type-Value (LTV) format and configured to be identifiable within the metadata structure of the broadcast data, Source device.

Images