Method, apparatus, and computer program for selecting a channel in a wireless communication system and recording medium therefor

Abstract

The present disclosure relates to a method, an apparatus and a computer program and a recording medium thereof for selecting a channel in a wireless communication system. According to one embodiment of the present disclosure, a method for selecting a channel by a first apparatus in a wireless communication system can include the steps of receiving a channel classification report from a second apparatus; and determining a channel map based on at least one of the channel classification report, a channel sensing result of the first apparatus, and information provided by a host of the first apparatus.

Description

Technical Field

[0001] This disclosure relates to methods, apparatus, computer programs, and recording media for selecting channels in a wireless communication system. Background Technology

[0002] Bluetooth is a short-range wireless communication standard that includes BR (Basic Rate) / EDR (Enhanced Data Rate) technology and LE (Low Power) technology. BR / EDR is also known as Bluetooth Classic and includes BR technology used in Bluetooth 1.0 and EDR technology used in Bluetooth 2.0. Bluetooth LE (BLE), used in Bluetooth 4.0 and later, is a technology that supports sending and receiving relatively large amounts of data with low power consumption.

[0003] The Bluetooth standard includes various profiles. For example, the Hands-free Profile (HFP) defines the necessary conditions for one device to act as an audio gateway (AG), such as a smartphone, and for another device to act as a hands-free device, such as a headset. Additionally, the A2DP (Advanced Audio Distribution Profile) defines the necessary conditions for one device to act as an audio source, such as a music player, and for another device to act as an audio sink, such as a speaker.

[0004] With the increasing prevalence of wireless devices, the demand for sending and receiving audio data in various topologies of many-to-many or M-to-N connection types is growing. For example, streaming services requiring a 5.1-channel environment are emerging, and there is discussion about using multiple Bluetooth portable speakers to support 5.1-channel environments, thus overcoming the limitations of conventional dedicated 5.1-channel wired speakers. However, since conventional Bluetooth audio technology was primarily developed for one-to-one connections between two devices, it is unsuitable for supporting audio data transmission / reception between multiple devices, and latency is a significant issue. Furthermore, the increased power consumption for searching peripheral devices arises as the number of Bluetooth audio devices increases.

[0005] In conventional Bluetooth systems, there is no method for selecting a channel based on the sharing and estimation of channel states between different systems.

[0006] On the other hand, in conventional Bluetooth systems, there are no methods to improve the authentication process to address digital key authentication errors. Summary of the Invention

[0007] [Technical Issues]

[0008] The technical problem of this disclosure is to provide methods and apparatus for supporting channel selection in wireless communication systems.

[0009] An additional technical problem of this disclosure is to provide methods and apparatus for resolving key authentication errors in wireless communication systems.

[0010] 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 from the following description.

[0011] [Technical Solution]

[0012] A method for performing channel selection by a first device for a wireless communication system according to aspects of this disclosure may include: receiving a channel classification report from a second device; and determining a channel mapping based on at least one of the channel classification report, channel sensing results of the first device, or information provided from a host of the first device.

[0013] The features briefly outlined above regarding this disclosure are merely exemplary aspects of the detailed description of this disclosure below and do not limit the scope of this disclosure.

[0014] [Technical Effects]

[0015] Based on this disclosure, methods and apparatus for supporting channel selection in wireless communication systems can be provided.

[0016] Based on this disclosure, methods and apparatus for resolving key authentication errors in wireless communication systems can be provided.

[0017] The technical effects of this disclosure are not limited to those described above, and those skilled in the art can understand other effects not mentioned herein from the following description. Attached Figure Description

[0018] Figure 1 This is an illustrative diagram showing the common audio connection types and the audio connection types to which this disclosure applies.

[0019] Figure 2 This is an exemplary diagram illustrating conventional audio-related protocols and the audio-related protocol stack to which this disclosure applies.

[0020] Figure 3 This is a diagram illustrating an example of 5.1-channel surround system hardware to which this disclosure applies.

[0021] Figure 4 This is a diagram illustrating the audio data encoding / decoding process to which this disclosure applies.

[0022] Figure 5 This is a diagram illustrating an example of channel allocation for two devices to which this disclosure applies.

[0023] Figure 6 This is a graph used to describe the synchronization delay of two streams to which this disclosure applies.

[0024] Figure 7 This is a diagram used to describe the broadcast operation of multiple devices to which this disclosure applies.

[0025] Figure 8 and Figure 9 This is a diagram used to describe the operations of the ICL and INCL types to which this disclosure applies.

[0026] Figure 10 This is a diagram illustrating the broadcast audio stream state machine to which this disclosure applies.

[0027] Figure 11 This is a diagram illustrating the audio setup process to which this disclosure applies.

[0028] Figure 12 This is a diagram illustrating the link layer state machine to which this disclosure applies.

[0029] Figure 13 This is a diagram illustrating an example of an audio topology to which this disclosure applies.

[0030] Figures 14 to 16 This is a diagram illustrating the message exchange process between a client and a server to which this disclosure applies.

[0031] Figure 17 This is a diagram illustrating the state machine of the call service to which this disclosure applies.

[0032] Figure 18 This is a diagram illustrating the grouping format for each layer to which this disclosure applies.

[0033] Figure 19 This is a diagram illustrating an example of a data unit format to which this disclosure applies.

[0034] Figure 20 This is a diagram illustrating an example of an advertising unit format to which this disclosure applies.

[0035] Figure 21 This is a flowchart describing an implementation of the channel selection operation according to the present disclosure.

[0036] Figure 22 It is a diagram used to describe channel mapping information to which the contents of this disclosure can be applied.

[0037] Figure 23 It is a diagram used to describe the channel structure of different network systems to which the contents of this disclosure can be applied.

[0038] Figure 24 This is a diagram used to describe the relationship between BLE channels and WLAN channels to which the present disclosure can be applied.

[0039] Figure 25This is a flowchart of an exemplary method for channel mapping reporting that can apply the contents of this disclosure.

[0040] Figure 26 This is a diagram illustrating an example of channel state sharing operations to which the contents of this disclosure can be applied.

[0041] Figure 27 It is a diagram used to describe channel mapping shared timing that can be applied to this disclosure.

[0042] Figure 28 It is a diagram used to describe the activation or deactivation of channel mapping application functions that can be applied to service changes that may be subject to this disclosure.

[0043] Figures 29 to 31 This is a diagram used to describe the operation of the Channel State Sharing Algorithm (CSSA) to which the contents of this disclosure can be applied.

[0044] Figure 32 It is a diagram used to describe digital key operations to which the contents of this disclosure can be applied.

[0045] Figure 33 This is a diagram used to describe an example of user registration and management that can be applied to this disclosure.

[0046] Figure 34 It is a diagram used to describe the digital key security protocols and message formats to which the contents of this disclosure can be applied.

[0047] Figure 35 It is a diagram used to describe the process of establishing a digital key bearer to which the contents of this disclosure can be applied.

[0048] Figure 36 This is a diagram used to describe authentication methods that can be applied to this disclosure.

[0049] Figure 37 This is a diagram illustrating the process of generating authentication questions to which the contents of this disclosure can be applied.

[0050] Figure 38 This is a diagram used to describe authentication error resolution methods to which the contents of this disclosure can be applied.

[0051] Figure 39 This is a diagram illustrating the configuration of a first device and a second device to which the present disclosure can be applied. Detailed Implementation

[0052] In the following, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings, enabling those skilled in the art to readily implement them. However, the present disclosure may be embodied in several different forms and is not limited to the embodiments described herein.

[0053] In describing embodiments of this disclosure, detailed descriptions of well-known configurations or functions will be omitted if it is determined that such descriptions may obscure the main points of this disclosure. Furthermore, in the accompanying drawings, portions unrelated to the description of this disclosure are omitted, and similar reference numerals are used for similar portions.

[0054] In this disclosure, when a component “connects,” “couples,” or “accesses” another component, it can include not only a direct connection but also an indirect connection in which the other component is present in between. Furthermore, in this disclosure, the terms “comprising” or “having” indicate the presence of a described feature, step, operation, element, and / or component, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof.

[0055] In this disclosure, terms such as “first” and “second” are used only to distinguish one component from other components and are not intended to limit the components. Furthermore, unless otherwise stated, the terms do not limit the order or importance of the components. Therefore, within the scope of this disclosure, a first component in one embodiment may be referred to as a second component in another embodiment, and similarly, a second component in one embodiment may be referred to as a first component in another embodiment.

[0056] In this disclosure, the components distinguished from each other are used to clearly describe each feature, but do not necessarily mean that the components are separate. That is, multiple components can be integrated to form a single hardware unit or software unit, or a single component can be allocated to form multiple hardware units or software units. Therefore, such integrated or distributed implementations are included within the scope of this disclosure, even if not specifically mentioned.

[0057] The various embodiments of this disclosure are not intended to list all possible combinations of components, but rather to illustrate representative aspects of this disclosure, and some or all of the components described in the various embodiments may be applied independently or in combination of two or more. That is, the components described in the various embodiments of this disclosure are not necessarily essential components, and some components may be optional. Therefore, embodiments consisting of a subset of the components described in one embodiment are also included within the scope of this disclosure. Furthermore, embodiments that include other components besides those described in the various embodiments are also included within the scope of this disclosure.

[0058] For clarity, the example methods of this disclosure are represented as a series of operations, but this is not intended to limit the order of execution of the steps, and each step may be performed simultaneously or in a different order if necessary. Furthermore, to implement the methods according to this disclosure, additional steps may be included besides those shown, or steps may be included in addition to some steps, or additional steps may be included in addition to some steps.

[0059] The terminology used in this disclosure is for describing particular embodiments and is not intended to limit the claims. Unless the context clearly indicates otherwise, the singular form is intended to include the plural form as used in the description of the embodiments and in the appended claims. Furthermore, the term “and / or” as used in this disclosure may refer to one of the relevant enumerations, or is intended to refer to and include all possible (or random) combinations of two or more of them.

[0060] The terms used in this disclosure are defined as follows.

[0061] An audio sink is an entity that receives audio data from an audio source.

[0062] An audio source is an entity that sends audio data to an audio destination.

[0063] An audio channel is a single stream of encoded or unencoded audio data.

[0064] An audio stream is a unidirectional logical communication channel that carries audio data from an audio source to an audio destination. Audio data can flow over an Audio Streaming Session (ASS). An audio stream can carry audio data from one or more audio channels.

[0065] An audio group can include one or more synchronized audio streams.

[0066] The content type indicates the categorization of the audio group's content. Categorization can include whether the audio was user-initiated. Examples of content types include Uncategorized Audio, Ringtone, System Sound, Satnav, Call Audio, Media, etc.

[0067] Metadata is variable-length data that describes and provides context for audio data. Metadata can be defined at higher levels.

[0068] An Audio Streaming Session (ASS) refers to a one-way or two-way transmission / switching process of an audio stream. The endpoints of an ASS correspond to the audio input and / or audio output of the audio streaming session and can correspond to a single device or a group of devices. The endpoints of an ASS reside on a server and can be configured by either the server or the client. The server can store, modify, and manage the ASS state.

[0069] QoS (Quality of Service) refers to the quality of service of an audio stream and can correspond to the requirements of a specific service.

[0070] An audio position refers to the logical spatial location of an audio channel within the spatial arrangement of a device intended to present audio. For example, the left and right positions of headphones can correspond to audio positions. Audio positions can be assigned to audio channels.

[0071] CBIS (Connection-Based Isochronous Stream) is a term defined in the core layer and is a concept corresponding to audio streams in ASS services. A unidirectional CBIS can have one audio stream, and a bidirectional CBIS can have two audio streams.

[0072] CBISS (Connection-Based Isochronous Stream Set) is a term defined in the core layer and is a concept corresponding to audio groups in ASS services.

[0073] Audio Scene Application (ASA) refers to an audio group that performs a specific content type.

[0074] ASC (Audio Stream Capability) is the set of parameters required to configure audio session capabilities.

[0075] Audio ads are designed to discover the availability of ASA engagement. General audio ads are audio ads without a specific target, while targeted audio ads are audio ads aimed at a specific goal.

[0076] Isochronous data refers to data that is subject to time constraints. For example, isochronous data can be time-dependent audio, such as television audio that needs to be synchronized with video images, or audio that needs to be synchronized and reproduced across multiple devices that constitute a multi-channel system.

[0077] An isochronous channel is a logical transmitting end used to send isochronous data from a transmitting device to one or more receiving devices.

[0078] An isochronous stream refers to a logical link that carries one or more isochronous channels.

[0079] Figure 1 This is an illustrative diagram showing the common audio connection types and the audio connection types to which this disclosure applies.

[0080] Figure 1(a) illustrates an example of the BR / EDR audio connection type. In the case of BR / EDR, a one-to-one connection type is supported. A device (e.g., a smartphone) can act as a central device and can connect one-to-one with each of several other devices. That is, multiple one-to-one connections may exist. Therefore, services such as telephone calls via headsets or music playback via speakers can be supported. The central element of the service in this connection type is the audio source, and audio sinks such as headsets, speakers, and AVNs (Audio Video Navigation) can operate as peripheral devices to the audio source.

[0081] Figure 1 (b) illustrates an example of a BLE audio connection type. In the case of BLE, many-to-many connections can be supported. In this scenario, multiple central devices such as TVs, smartphones, and gateways can exist, and complex M-to-N connections can be configured. Therefore, services such as telephone calls and music playback via headsets can be supported, as well as broadcast audio services such as alarm clocks, doorbells, and advertising voice messages. The central service in this connection type is the audio sink, and audio services can be used by moving multiple audio sources.

[0082] Figure 2 This is an exemplary diagram illustrating a conventional audio-related protocol stack and an audio-related protocol stack to which this disclosure applies.

[0083] Figure 2 (a) illustrates an example of an audio-related protocol stack. The L2CAP (Logical Link Control and Adaptation Protocol) layer acts as an arbitrator and mediator between the upper and lower layers. The upper layers may include protocols such as RFCOMM (Radio Frequency Communication), AVDTP (Audio / Video Distribution Transport Protocol), and AVCTP (Audio / Video Control Transport Protocol), and profiles such as HFP (Hands-Free Profile), A2DP (Advanced Audio Distribution Profile), and AVRCP (Audio / Video Remote Control Profile). The lower layers may include the MAC / PHY layer. The MAC (Media Access Control) layer may include a link manager and a link controller, and the PHY (Physical) layer may include a BR / EDR radio. Additionally, Synchronous Connection Towards (SCO) / Extended SCO (eSCO) can provide a synchronous data communication path for voice. Therefore, in BR / EDR, a protocol stack can be designed for each profile. The L2CAP layer, BR / EDR protocol, Generic Access Profile (GAP), and BR / EDR profile layer can be collectively referred to as the host layer, and the link manager, link controller, and BR / EDR radio layer can be referred to as the controller layer. The interface between the host and the controller can be called HCI (Host Controller Interface).

[0084] Figure 2 (b) illustrates an example of a BLE audio-related protocol stack. Unlike the BR / EDR, which configures protocols for each profile, in BLE, a generic protocol stack can be designed for various profiles. This generic protocol stack can be referred to as middleware. For example, generic protocols can be configured in the form of middleware for various profiles such as hearing aids, high-quality audio / music, speech recognition, and call / media. For example, middleware may include protocols such as device discovery, flow control (or flow management), codecs, and legacy management. Additionally, the core layer may include the Link Layer (LL), LE radio (i.e., the PHY layer), and the LL may include functionality related to multicast support isochronous channels as defined by Bluetooth 5.

[0085] Additionally, configuration files and middleware can be referred to as the host layer, the core layer as the controller layer, and HCI can be defined between the host and the controller.

[0086] Apart from Figure 2 In addition to the host profiles and protocols shown in (b), a host may include an LE profile, a Generic Access Profile (GAP), a Generic Attribute Profile (GATT), an Attribute (ATT) protocol, a Security Manager (SM), etc.

[0087] Messages sent from the host to the controller are called HCI command packets. Messages sent from the controller to the host are called HCI event packets. Additionally, HCI asynchronous data packets or HCI synchronous data packets can be exchanged between the host and the controller.

[0088] In addition, Figure 2 In addition to the middleware configuration files and services shown in (b), middleware may also include various configuration files and / or services such as:

[0089] Audio Session Capability Service (ASCS): Audio Session Capability Service (ASCS) is a service that supports advertising or discovery capabilities related to audio sessions.

[0090] Audio Stream Session Service (ASSS): The Audio Stream Session Service (ASSS) is a service that supports the discovery, setup, establishment, control, and management of audio sessions.

[0091] Audio Input Management Service (AIMS): A service used to manage audio input volume, etc.

[0092] Audio Routing Service (ARS): A service used to select the location of audio input and output;

[0093] Audio Middleware Profile (AMP): A basic profile used to describe the behavior of devices that distribute audio;

[0094] Call Management Profile (CMP): A profile of the roles and procedures that enable interaction between two devices for a call;

[0095] Audio Common Middleware Profile (AGMP): The basic profile that enables content and / or flow control;

[0096] Group Identification Service (GIS): A service used to discover devices that belong to a group. The Group Identification Service (GIS), or Group Identification Profile (GIP), allows devices to be discovered as part of a group. A group is defined as a set of devices that operate together to support a specific scenario, and these devices can be referred to as group members. For example, a group of devices responding together to control commands, such as a pair of hearing aids, a pair of earbuds, or a collection of speakers receiving multi-channel (e.g., 5.1CH) audio, might be such an example.

[0097] Audio Player Management Profile (APMP): A profile that supports control or interaction with the audio player;

[0098] Audio Player Management Service (APMS): A service that supports the control or interaction of audio players;

[0099] Microphone management configuration file: A configuration file used for microphone status management;

[0100] Microphone Management Service: Supports interfaces and status services for microphone status management;

[0101] Quick Service Discovery Service (QSDS): Enables quick discovery of services such as audio playback management and call management;

[0102] Call bearer service: A service that supports the management of call interfaces and call status on the device;

[0103] Volume management profile: A profile that supports audio volume management for the device;

[0104] Volume management service: A service that supports the audio volume interface and status of the device;

[0105] Volume offset management service: A service used for volume management of audio output.

[0106] Figure 3 An example of 5.1-channel surround system hardware to which this disclosure applies is shown.

[0107] exist Figure 3In this context, an LE audio source device can perform the function of an initiator, and an LE audio sink device can perform the function of a receiver. An initiator is the device that initiates an audio session, while a receiver is the device that accepts the initiated audio session. Here, the source is not always the initiator, or the sink is not always the receiver; the source can be the receiver, or the sink can be the initiator.

[0108] For example, the audio source can be a TV device, and the audio sink can be a speaker device. The audio source can send audio data to the audio sink. Additionally, the audio source can receive feedback data from the audio sink. Multiple audio sinks can each receive audio data corresponding to one of the 5.1 channels—FL (front left), FR (front right), RL (rear left), RR (rear right), C (center), and W (woofer)—and output that audio data through the speakers.

[0109] Audio encoders or decoders can support a variety of audio formats. For example, audio formats can include Bluetooth Low Energy Audio Codec (BLEAC), Dolby 5.1CH, Digital Surround Sound (DTS), etc., and the characteristics of each format are as follows: BLEAC is a single-channel codec, and its 96kbps transmission rate can provide the same quality as SBC (subband codec) at 256kbps and MP3 at 200kbps. Dolby 5.1CH can support a 48kHz sampling rate, supports 1 to 5.1 (or 1 to 6) channels, and supports transmission rates up to 448kbps. DTS can support 48kHz or 96kHz sampling rates, supports 2 to 6.1 channels, and supports transmission rates of 768kbps half-rate and 1,536kbps full-rate.

[0110] Figure 4 This is a diagram illustrating the audio data encoding / decoding process to which this disclosure applies.

[0111] Reference Figure 4 (a) A DTS or Dolby 5.1CH format stream can be input to the DTS or Dolby 5.1CH decoder of the transmitting end (Tx), and a PCM (Pulse Code Modulation) format audio signal can be output. The PCM signal can be input to a BLEAC encoder and output as a BLEAC format audio signal. Optional vendor-specific information can be added here. The BLEAC signal can be sent to the BLE interface of the receiving end (Rx) via the BLE interface. The receiving end can process the BLEAC signal using a BLEAC decoder and convert it into a signal that can be output through a speaker.

[0112] Here, multiple streams can be sent from a transmitter to multiple receivers. For example, each of the multiple streams may include an audio signal corresponding to one channel of the 5.1CH. Multiple streams can be received from multiple receivers at different times, but the multiple streams have the isochronous property of needing to be played back or presented simultaneously, and these streams can be called CBIS (Connection-Based Isochronous Streams). That is, six CBIS corresponding to the 5.1CH can be sent from the transmitter to the receiver, and the set of these six CBIS can be called a CBISS (Connection-Based Isochronous Stream Set).

[0113] Figure 4 (b) and Figure 4 (c) A conceptual illustration shows audio streaming over multiple streams. One or more audio streams may correspond to a CBIS, and an audio group may correspond to a CBISS. For example, one audio stream may correspond to one CBIS, while two or more audio streams may correspond to one CBIS. Multiple CBISs may be included in one audio group or CBISS.

[0114] Figure 5 This is a diagram illustrating an example of channel allocation for two devices to which this disclosure applies.

[0115] The receiving end can initiate stream reception based on timing information provided by the sending end. For example, the timing information may represent a time point after a predetermined offset from the time point when the data unit including the timing information is transmitted. The receiving end can receive audio data corresponding to one or more channels included in the stream. For example, multiple channels included in a stream can be assigned to multiple receiving ends. Multiple channels (or multiple audio data) included in a stream can be transmitted using a time-division multiplexing (TDM) method. For example, audio data of a first channel can be transmitted at a first timing point, and audio data of a second channel can be transmitted at a second timing point.

[0116] The broadcast receiver can detect the currently available broadcast audio stream, stream offset value, stream interval value, etc. by using the information included in the data unit of the periodic advertisement from the sender.

[0117] In the case of an isochronous connectionless link (INCL) based on a connectionless isochronous link, isochronous channels can be sent / received (e.g., broadcast) without a connection between the source and destination devices. From information such as the BSG (Broadcast Synchronization Group) included in the AUX_SYNC_IND protocol data unit (PDU) advertised by the sender, the receiver can check the INCL stream offset or BSG offset and determine the anchor timing. INCL stream transmission can start from an anchor point. The timing difference between two consecutive anchor points can be defined as an interval (e.g., Figure 5(INCL CH1 interval or ISO interval). One or more sub-events can be included in a streaming event.

[0118] exist Figure 5 In the example, an audio stream may include audio data from two channels. The first channel (CH1) can be assigned to a first device (device #1), and the second channel (CH2) can be assigned to a second device (device #2). At one or more timing points after the anchor point, CH1, included in the INCL stream, can be sent to device #1, and subsequently, CH2 can be sent to device #2 at one or more timing points. Additionally, INCL stream events may include events for CH1 and CH2. An event for CH1 may include two sub-events. An event for CH2 may include two sub-events. The timing difference between the sub-events can be defined as the sub-event interval.

[0119] Isochronous audio data may have a limited lifespan. That is, the audio data may become invalid after the predetermined time has expired. For example, a predetermined timeout value can be defined in the ICL channel, and isochronous audio data sent to multiple devices can be discarded after the predetermined timeout value expires. For example, the timeout can be expressed as multiple sub-events.

[0120] Figure 6 This is a graph used to describe the synchronization delay of two streams to which this disclosure applies.

[0121] Suppose multiple streams are included in an audio group, and these streams have isochronism, meaning they need to be reproduced simultaneously. Multiple streams can be sent from one device or from different devices. Furthermore, multiple streams can be received by one device or by different devices.

[0122] Because Bluetooth communication methods do not support the simultaneous transmission of multiple streams, multiple streams can be sent using the TDM method on different time resources (or timings) according to a predetermined order. In this case, differences may occur in the transmission timing of the multiple streams, and therefore, differences may also occur in the reception timing of the multiple streams. Furthermore, since multiple streams need to be reproduced simultaneously, the first stream received cannot be reproduced first, but can be reproduced only after the last stream has been received. That is, a synchronization delay may not occur until the timing of receiving all streams is complete.

[0123] exist Figure 6In the example, the first stream (CBIS#1) and the second stream (CBIS#2) may need to be reproduced simultaneously and can be included in a single CBISS. The CBISS anchor point can be the same as the anchor point of CBIS#1, and after CBIS#1 audio data can be sent, CBIS#1 audio data following a time point after the CBIS#1 interval (e.g., T1) can be sent. Next, after CBIS#2 audio data is sent from the anchor point of CBIS#2, CBIS#2 audio data following a time point after the CBIS#2 interval (e.g., T2) can be sent. After all streams included in a CBISS are received, they can be reproduced simultaneously. That is, the audio data of CBIS#1 and CBIS#2 can be processed and reproduced while the reception of the relatively later-sent CBIS#2 is complete.

[0124] Here, the synchronization delay of the CBISS can be defined as the time interval up to the reception completion time (T2) of CBIS#2, which is received relatively later from the CBISS. For example, the later of the reception completion time T1 of CBIS#1 and the reception completion time T2 of CBIS#2 can be determined as the synchronization delay of the CBISS. That is, the later reception completion time among the synchronization delays of multiple streams can be determined as the synchronization delay of the CBISS. Specifically, when CBIS#1 and CBIS#2 are bound to the same single CBISS, the previously received stream CBIS#1 can be reproduced after waiting until the received stream CBIS#2 information is sent.

[0125] The transmitting end (Tx) can notify the receiving end (Rx) of the expected delay value calculated in advance, taking into account the number of CBIS, CBIS events, sub-events, and intervals. For example, the transmitting end can notify the receiving end of the expected delay value when configuring the channel.

[0126] In the case of a connection-based isochronous connection link (ICL), since the sender and receiver are connected, the receiver can notify the sender of the actual delay value.

[0127] In the case of INCL, because the sender and receiver are not connected, the receiver cannot notify the sender of the actual delay value. Even if the receiver could notify the sender of the delay value, the sender could not control the playback time of a specific device to synchronize multiple devices.

[0128] For example, even in the case of INCL, when multiple CBISs are included in a CBISS (e.g., six CBISs corresponding to the six channels of 5.1CH), the transmitter can receive feedback from the receiver to adjust synchronization. Through this feedback, the receiver can inform the transmitter of its delay information.

[0129] Figure 7 This is a diagram used to describe the broadcast operation of multiple devices to which this disclosure applies.

[0130] An audio source device can calculate a synchronization delay value for simultaneous reproduction of an isochronous stream and send this delay value to multiple audio sink devices. Each sink device can determine its playback timing based on the delay value provided by the source device. In other words, since the source device cannot know precisely the amount of time it takes for the sink devices to receive and process the audio data, the sink devices can provide a delay value as basic information for determining the playback timing. The sink devices can then determine the playback timing and reproduce the audio data according to their device characteristics.

[0131] For example, in isochronous broadcasting operations, the source device (e.g., TV) can calculate transmission delay, presentation delay, etc., and send these delays to the destination device (e.g., a speaker). The destination device can adjust the playback or presentation timing of the audio data by reflecting the received delay values. Since the characteristics of each destination device are different for each manufacturer, the actual playback timing can be determined by the destination device.

[0132] If the sink device can send information to the source device, then the sink device can calculate the delay value and send the delay value to the source device. Therefore, the source device can determine the transmission timing based on the delay value provided by the sink device.

[0133] For example, a feedback channel can be formed through which a destination device (e.g., a speaker) transmits information to a source device (e.g., a TV). In this case, unicast operation based on isochronous connections can be performed. The destination device can calculate a presentation delay value and send it to the source device through the feedback channel. Therefore, the source device can adjust the transmission time of the audio data by reflecting the delay value provided from the destination device.

[0134] Reference Figure 7 An isochronous streaming operation is illustrated exemplarily in the case where the transmitting end is a TV and the two receiving ends are a first speaker (speaker #1) and a second speaker (speaker #2). A first stream / channel (e.g., the RR channel in 5.1CH) can be assigned to the first speaker, and a second stream / channel (e.g., the RL channel in 5.1CH) can be assigned to the second speaker.

[0135] The first speaker and the second speaker can respectively send general audio advertisements or targeted audio advertisements. The TV and at least one of the first or second speakers can be connected to each other or not.

[0136] When at least one of the TV and the speaker is connected, the speaker can calculate the rendering delay value and report it to the TV. When the TV and the speaker are not connected, the TV can calculate the transmission delay, rendering delay value, etc., and send it to the speaker.

[0137] Taking into account audio content characteristics, audio / video synchronization, and codec characteristics, TVs can perform synchronization operations and force latency onto specific audio streams. For example, since audio codec encoding / decoding latency differs from BLEAC's 40ms, SBC's 200ms, and APT-X's 100ms, latency values ​​can be determined based on codec characteristics. Furthermore, since the characteristics of A / V content vary depending on games, movies, animations, etc., this can be taken into account when determining latency values. Additionally, the difference between the media clock and the BLE interface clock can be considered when determining latency values. The media clock can be confirmed using A / V timing information.

[0138] In addition, such as Figure 7 As shown on the left, the delay value can be determined by taking into account the audio / video signal processing time defined in various broadcast standards. For example, in the Advanced Television Systems Committee (ATSC), the time interval between audio-video-audio is 15ms and 45ms; in ITU-R BT.1359-1, the time interval between audio-video-audio is 125ms and 45ms; and in SMPTE (Institute of Motion Picture and Television Engineers), the time interval between audio-video-audio is defined as 22ms and 22ms, and these time intervals can be taken into account when determining the delay value.

[0139] The TV can configure a presentation delay value for each stream and notify the speaker of that presentation delay value, or the TV can determine the transmission timing of the stream based on the delay value provided from the speaker.

[0140] The TV can send a stream to the speakers based on a determined delay value. In other words, the source device or TV, as the transmitter, can exchange delay values ​​with the receiver device and speakers, and can perform synchronization operations by reflecting the delay values.

[0141] Figure 8 and Figure 9 This is a diagram used to describe the operations of the ICL and INCL types to which this disclosure applies.

[0142] In BLE, channels used for audio transmission can be classified into ICL and INCL types. Both ICL and INCL channels can use stream IDs and channel IDs to send audio data to multiple devices and / or multiple profiles. The ICL and INCL types determine what operations should be performed on the BLE channels used for audio data transmission.

[0143] ICL channels correspond to connection-based use cases, which support one-way or two-way communication via a point-to-point physical link between a source device and a destination device. Additionally, INCL channels correspond to broadcast use cases, which support one-way communication only via a point-to-multipoint physical link between a source device and one or more destination devices.

[0144] The device's protocol stack can include, from top to bottom, a configuration file layer, a channel manager layer, a host layer, and a controller layer. Data can be transferred between the configuration file layer and the channel manager layer on a channel basis, and between the channel manager layer and the host layer on a stream basis.

[0145] Reference Figure 8 In the case of ICL type, there is a connection between the master device (M) and the first slave device S1, and a connection between the master device M and the second slave device S2. In this case, two channels included in a single stream can be separated by channel identifiers, and these two channels can be sent to the two slave devices. That is, channel ID 1 can be assigned to S1, and channel ID 2 can be assigned to S2. Both channel ID 1 and channel ID 2 can be sent through the same stream ID 1. In addition, since bidirectional communication is possible based on the connection, the slave devices can provide feedback information to the master device M. For example, when S1 is a wireless earphone installed in the right ear and S2 is a wireless earphone installed in the left ear, music sent by the master device M can be listened to in stereo through S1 and S2.

[0146] Reference Figure 9 In the case of INCL type, there is no connection between the master device M and the slave devices (S1, S2), and the slave devices can synchronize with the INCL stream offset, events, and sub-events based on the synchronization information advertised by the master device, and can receive broadcast audio data. Additionally, the master device M can include two profiles (profile #1 and profile #2). The first slave device S1 can include profile #1, and the second slave device S2 can include both profile #1 and profile #2. In profile #1, a stream—stream ID 1—can be used to broadcast channel ID 1 and channel ID 2 from the master device M, and similarly... Figure 8The slave devices S1 and S2 respectively receive channel ID 1 and channel ID from configuration file #1. Additionally, in configuration file #2, channel ID 1 can be broadcast from the master device M via stream ID 2, and the second slave device S2 can receive channel ID 1 from configuration file #2.

[0147] Figure 10 This is a diagram illustrating the broadcast audio stream state machine to which this disclosure applies.

[0148] Control of a broadcast audio stream can be described as the broadcast audio stream state machine and state transitions at the broadcast transmitter.

[0149] The broadcast audio stream state machine allows a broadcast transmitter to communicate unidirectionally with one or more broadcast receivers (or broadcast discovery clients) without a connection, or to not communicate with any broadcast receivers (or broadcast discovery clients). The broadcast transmitter can communicate using broadcast audio advertisements in the form of a Broadcast Audio Source Session (BASS). Broadcast audio streams can be sent by the broadcast transmitter.

[0150] Audio standby mode refers to a state in which no broadcast audio stream is being sent.

[0151] The audio configuration state refers to the state in which a broadcast receiver (or broadcast discovery initiator) begins detecting advertising information for an audio stream through periodic advertising events. Periodic advertising events may include delivering advertising metadata, stream configuration, synchronization information, etc. In this state, no audio data packets are transmitted from the broadcast transmitter.

[0152] The audio streaming state refers to the state in which a broadcast transmitter has broadcast audio streaming enabled and can send audio data packets. The broadcast transmitter can continuously perform metadata advertising through periodic advertising while sending broadcast audio streams. If a stream is configured in the audio standby state, it can transition to the audio configured state; if a stream is released in the audio configured state, it can transition to the audio standby state. If a stream is enabled in the audio configured state, it can transition to the audio streaming state; if a stream is disabled in the audio streaming state, it can transition to the audio configured state. If a stream reconfiguration occurs in the audio configured state, it can transition to the audio configured state. When content reallocation occurs in the audio streaming state, it can transition to the audio streaming state.

[0153] Figure 11 This is a diagram illustrating the audio setup process to which this disclosure applies.

[0154] When no discovery result is found (i.e., zero discovery), the audio standby state can be transitioned, and if a discovery result is found, discovery for the audio streaming capability (ASC) can be performed and the audio standby state can be transitioned.

[0155] When an ASS (Audio Streaming Session) configuration occurs, it can transition to the audio configuration state. If the ASS is released while in the audio configuration state, it can transition to the audio standby state. When a reconfiguration occurs while in the audio configuration state, it can transition back to the audio configuration state via ASS configuration.

[0156] When an ASS is activated, it can transition to audio streaming mode. If an ASS is deactivated while in audio streaming mode, it can transition to audio configuration mode. If content reallocation occurs while in audio streaming mode, it can transition back to audio streaming mode.

[0157] Figure 12 This is a diagram illustrating the link-layer state machine to which this disclosure applies.

[0158] The operations of the link layer LL can be represented as (based on the isochronous channel) standby state, advertising state, scanning state, initiation state, connection state, synchronization state, and streaming (isochronous broadcast) state.

[0159] The standby state corresponds to the standby state before transitioning to another state.

[0160] In advertising mode, LL can operate as an advertiser sending advertising packets. When a connection is established in advertising mode, the device can operate as a slave device.

[0161] In the Initiated state, LL can act as the initiator, listening for packets from other advertisers and initiating connections in response to those packets. When a connection is established in the Initiated state, the device can operate as the master device.

[0162] In scanning mode, LL can act as a scanner, listening for packets from other advertisers and requesting additional information.

[0163] Synchronization state can refer to the state in which an audio stream can be received or received synchronously with another device.

[0164] Streaming status can refer to the state in which an audio stream is sent to another synchronization device.

[0165] Figure 13 This is a diagram illustrating the audio topology to which this disclosure applies.

[0166] In the unicast case, either one-way or two-way audio streaming can be supported. Unicast audio data transmission / reception can be performed based on a connection between a headset and a smartphone, as well as unicast audio data transmission / reception based on connections between a headset and a smartphone and between a headset and a tablet. In this case, the server for the unicast audio service can be a headset, and the client can be a smartphone or a tablet. Furthermore, the headset can correspond to the audio sink, and the smartphone or tablet can correspond to the audio source.

[0167] In a broadcast scenario, notification systems, doorbells, TVs, etc., can transmit audio data via broadcast, and one or more devices can receive the broadcast audio data. In this case, the server for the broadcast audio service can be a notification system, doorbell, TV, etc., and the client can be a headset. Furthermore, the headset can correspond to the audio sink, and the notification system, doorbell, and TV can correspond to the audio source.

[0168] Figures 14 to 16 This is a diagram illustrating the message exchange process between a server and a client to which this disclosure applies.

[0169] exist Figures 14 to 16 In the example, the client can be the audio source and the server can be the audio sink. Alternatively, the client can be the audio sink and the server can be the audio source.

[0170] Figure 14 The Audio Session Capability (ASC) discovery process and the ASC update process are illustrated exemplarily.

[0171] exist Figure 14 (a) During the audio session capability discovery process, the client can request capability discovery by sending an ASC discovery request message to the server, and in response, the server can send the capability details to the client by sending an ASC discovery response message.

[0172] exist Figure 14 (b) During the audio session capability update process, the server can send an ASC update indication message to the client to notify that a capability update has occurred, and the client can notify the server to perform the capability update by sending an ASC update confirmation message. Subsequently, either the audio session capability discovery process or the ASC discovery process can be performed.

[0173] exist Figure 14 The format of the messages used in the examples can be defined as shown in Table 1 below.

[0174] Table 1

[0175]

[0176] ASC update instruction messages and ASC update confirmation messages can each include information indicating what ASC needs to discover and confirmation information for doing so.

[0177] Figure 15 The unicast audio stream configuration process and the unicast audio stream establishment process are illustrated exemplarily.

[0178] exist Figure 15 During the unicast audio stream configuration process in (a), the client can send a codec configuration request message to the server while in audio standby mode to notify the server of the codec configuration request, etc. In response, the server can send a codec configuration response message to the client to notify the server of the QoS and rendering latency values ​​supported by the server. Additionally, the client can send a QoS negotiation request message to the server to specify a particular audio streaming session (ASS), audio group, and audio stream to notify the client of the QoS and rendering latency values ​​supported by the client. In response, the server can send a QoS negotiation response message to the client. Therefore, bandwidth (BW), bit rate, etc., can be determined through negotiation between the client and server, and both the client and server can transition to a configuration state.

[0179] exist Figure 15 During the unicast audio stream establishment process in (b), the client can send an ASS enable request message to the server in audio configuration mode to notify the client of information regarding the ASS activation request. In response, the server can send an ASS enable response message to the client to notify the client of which ASS to activate. Configuration of connection-based isochronous link parameters can be performed at the client, and a CBIS can be established by configuring connection-based isochronous stream connections and related parameters through client and server configuration. If the client is the audio sink and the server is the audio source, the server can prepare to play audio data and send an ASS Rx ready indication message to the client, and the client can prepare to provide audio data after receiving the ASS receive ready indication notification message. Therefore, the client and server can transition to audio streaming mode.

[0180] exist Figure 15 The format of the messages used in the examples can be defined as shown in Table 2 below.

[0181] Table 2

[0182]

[0183] Figure 16 The procedures for disabling an audio stream via a client and for disabling an audio stream via a server are illustrated by way of example.

[0184] exist Figure 16 In the process of disabling the audio stream by the client in (a), if the client is the audio source and the server is the audio sink, the client can send an ASS disable request message to the server when it decides to stop the audio streaming. Therefore, the server can stop streaming the audio data and send an ASS disable response message to the client. Upon receiving this, the client can stop audio data encoding and audio application operations.

[0185] Alternatively, if the client is the audio sink and the server is the audio source, the client can stop audio data streaming and send an ASS disable request message to the client. Therefore, the server can stop audio data encoding and audio application operations and send an ASS disable response message to the client.

[0186] Subsequently, the client and server can perform connection-based isochronous stream release and related parameter setting release. Here, in preparation for reconnection between the client and server, device information along with isochronous stream connection-related parameters can be stored in the client and / or server. Therefore, the client can release connection-based isochronous link-related parameter settings. Thus, the client and server can transition to the audio configuration state.

[0187] exist Figure 16 In the example of (b), during the process of disabling the audio stream via the server, if the server is the audio source and the client is the audio sink, the server can send an ASS disable indication message to the client when it decides to stop the audio streaming. Therefore, the client can stop streaming audio data and may or may not send an ASS disable confirmation message to the server. The server can stop encoding audio data and audio application operations with or without receiving an ASS disable response.

[0188] Alternatively, if the server is the audio sink and the client is the audio source, the server can stop audio data streaming and send an ASS disabled indication message to the client. Therefore, the client can stop audio data encoding and audio application operations, and may or may not send an ASS disabled confirmation message to the server.

[0189] Subsequently, the client and server can perform connection-based isochronous stream release and related parameter configuration release. Here, in preparation for reconnection between the client and server, device information along with isochronous stream connection-related parameters can be stored in the client and / or server. Therefore, the client can release the connection-based isochronous link-related parameter configuration. Thus, the client and server can transition to the audio configuration state.

[0190] exist Figure 16 The format of the messages used in the examples can be defined as shown in Table 3 below.

[0191] Table 3

[0192]

[0193] Table 4 below provides examples of content redistribution request / response, ASS release request / response, general advertising, and targeted advertising message formats.

[0194] Table 4

[0195]

[0196] Figure 17 This is a diagram illustrating the state machine for the call service to which this disclosure applies.

[0197] When a call is received in audio standby mode, it can transition to call accept mode. When a call is accepted in call accept mode, it can transition to call active mode. When a call is rejected in call accept mode, it can transition to audio standby mode. If a call cannot be received while on hold in call accept mode, it can transition to call hold mode, and when the hold is released in call hold mode, it can transition to call active mode. When call hold or call active mode is terminated, it can transition to audio standby mode.

[0198] Furthermore, when a call is made in audio standby mode, it can transition to call initiation mode. When it answers a call from a remote location or other party in call initiation mode, it can transition to call active mode. When it ends in call initiation mode, it can transition to audio standby mode.

[0199] In such a call service state machine, audio data may need to be delivered to the headset during audio standby. For example, audio data can be sent to the headset when responding to a phone call via voice notification.

[0200] Alternatively, information regarding the various wireless access technologies (e.g., 2G, 3G, 4G, 5G, Wi-Fi, GSM, CDMA, WCDMA, etc.) associated with the call service can be explicitly specified. For example, a bearer technology field of one octet can be defined. This may be related to the aforementioned call bearer service.

[0201] In the case of multiple calls, multiple lines can exist, and each line can be maintained as follows: Figure 17The state machine is shown in the diagram. For example, when the first line is in a call active state, and the second line transitions from an audio standby state to a call accept state, either the first line or the second line can transition to a call hold state according to the user's control.

[0202] The logical links and logical transmissions of the Bluetooth system will be described below.

[0203] A wide variety of logical links can be used to support different application data transmission requirements. Each logical link is associated with a logical transport, which may have various characteristics. These characteristics may include flow control, acknowledgment / repeat mechanisms, sequence numbering, and scheduling operations. Logical transports can carry various types of logical links depending on their type. Multiple logical links can be multiplexed into the same single logical transport. Logical transports can be carried by physical links on a specific channel.

[0204] Logical transport identifiers and real-time (link control) signaling can be included in the packet header, and specific logical link identifiers can be included in the payload header.

[0205] Table 5 below provides an example of logical transport types, supported logical link types, supported physical link and physical channel types, and descriptions of logical transports.

[0206] Table 5

[0207]

[0208] Figure 18 This is a diagram illustrating the grouping format for each layer to which this disclosure applies.

[0209] Figure 18 (a) shows an example of a Link Layer (LL) packet format. An LL packet format may include a preamble, access address (or access code), PDU, and Cyclic Redundancy Code (CRC) fields. The preamble can be 1 octet in size and can be used for frequency synchronization at the receiver, symbol timing estimation, automatic gain control (AGC) training, etc., and can be configured with a predetermined bit sequence. The access address can be 4 octets in size and can be used as the associated code for the physical channel. PDUs can be defined in Bluetooth 4.0 with a size of 2 to 39 octets, and in version 4.2, PDUs can be defined as 2 to 257 octets in size. The CRC may include the value of a 24-bit checksum calculated as a PDU.

[0210] Figure 18 (b) shows Figure 18(a) An exemplary format for a PDU. PDUs can be defined in two types: Data channel PDUs and Advertising channel PDUs. (See also...) Figure 19 Describe the data channel PDU in detail, and refer to Figure 20 Describe the advertising channel PDU in detail.

[0211] Figure 18 (c) shows an example of the L2CAP PDU format, which can correspond to Figure 18 (b) An exemplary format for the payload field. An L2CAP PDU may include a length, channel ID, and a message payload field. The length field may indicate the size of the message payload, and the message payload field may include higher-level data. The channel identifier field may indicate which upper-level data the message payload field includes. For example, if the value of the channel identifier field is 0x0004, it may indicate ATT (Attribute Protocol); if the value of the channel identifier field is 0x0004, it may indicate SMP (Security Manager Protocol); or another channel identifier may be defined and used to indicate different types of upper-level or middleware values.

[0212] when Figure 18 (c) The L2CAP packet is sent on the signaling channel when it is an L2CAP PDU (i.e., a control frame). Figure 18 (c) The information payload field can be as follows: Figure 18 The configuration shown in (d) is as follows. The information payload fields may include a Code field, an Identifier field, a Length field, and a Data field. For example, the Code field may indicate the type of L2CAP signaling message. The Identifier field may include values ​​that match requests and responses. The Length field may indicate the size of the Data field. The Data field may contain attributes. Attributes are units of arbitrary data and may include, for example, data at various points in time in various states of the device, such as location, size, weight, temperature, and speed.

[0213] An attribute can have a format that includes the attribute type, attribute handle, attribute value, and attribute permissions.

[0214] The attribute type can include a value indicating the type of attribute data identified by a universally unique identifier (UUID).

[0215] Attribute handles can contain values ​​assigned by the server to identify attribute data.

[0216] Attribute values ​​can include the values ​​of attribute data.

[0217] Attribute permissions can be configured by GATT (General Attribute Profile) and can include values ​​indicating the type of the corresponding attribute data that is allowed to be accessed (e.g., whether it can be read / written, whether encryption is required, whether authentication is required, whether authorization is required, etc.).

[0218] From the perspective of Attribute Protocol (ATT) / Generic Attribute Profile (GATT), a device can be used as a server and / or a client. A server can be used to provide attributes and associated values, while a client can play a role in discovering, reading, or writing attributes on the server.

[0219] In ATT / GATT, it supports the sending and receiving of attribute data between servers and clients. For this purpose, PDUs supported by the ATT protocol can include six method types: request, response, command, notification, instruction, and acknowledgment.

[0220] A request is sent from the client to the server and requires a response from the server. A response is sent from the server to the client and is sent when a request from the client exists. A command is sent from the client to the server and does not require a response. A notification is sent from the server to the client and does not require acknowledgment. An instruction is sent from the server to the client and requires acknowledgment from the client. An acknowledgment is sent from the client to the server and is sent when an instruction from the server exists.

[0221] Furthermore, GATT supports various profiles. The structure of a GATT-based profile can be described as services and characteristics. A device can support one or more profiles. A profile can include zero or more services. Multiple profiles can use the same service. A service can include one or more characteristics. A characteristic is a data value that serves as the subject of reading, writing, indicative, or notification. In other words, a service can be understood as a data structure used to describe a specific function or feature, and services, as combinations of characteristics, can instruct operations performed by the device. All services are implemented by a server and can be accessed by one or more clients.

[0222] Figure 19 This is a diagram illustrating an example of a data unit format to which this disclosure applies.

[0223] Figure 19(a) illustrates an exemplary format of a data physical channel PDU (Protocol Data Unit). A data channel PDU can be used to transmit packets on a data physical channel (e.g., channel numbers 0 to 36). A data physical channel PDU includes a 16-bit or 24-bit length header and a variable-size payload (e.g., 0 to 251 octet sizes), and may also include a Message Integrity Check (MIC) field. For example, the MIC field may be included in the case of an encrypted link-layer connection where the payload field size is not zero.

[0224] like Figure 19 As shown in (b), the header fields may include LLID (Logical Link Identifier), NESN (Next Expected Sequence Number), SN (Sequence Number), MD (More Data), CP (CTEInfo Present), and RFU (Reserved for Future Use). RFU corresponds to the portion reserved for future use if necessary, and its value can typically be padded with 0. Furthermore, depending on the value of the CP field, the header fields may also include a Constant Tone Extension Information (CTEInfo) subfield. Additionally, the length field can indicate the size of the payload, and when a MIC is included, it can indicate the length of both the MIC and the payload.

[0225] Figure 19 (c) shows an exemplary format for an LL control PDU. An LL control PDU may correspond to a data physical channel PDU used to control link layer connections. An LL control PDU may have a fixed value based on an opcode. The opcode field may indicate the type of the LL control PDU. The control data (CtrData) field may have various formats and lengths specified by the opcode.

[0226] For example, the Opcode of the LL control PDU can have a value indicating one of LL_CBIS_REQ, LL_CBIS_RSP, LL_CBIS_IND, LL_CBIS_TERMINATE_IND, LL_CBIS_SDU_CONFIG_REQ, and LL_CBIS_SDU_CONFIG_RSP (e.g., 0x1F, 0x20, 0x21, 0x22, ...).

[0227] When the opcode indicates LL_CBIS_REQ, the CtrData field may include information required for the CBIS request along with CBISS identification information and CBIS identification information. Similarly, in each case where the opcode indicates one of LL_CBIS_RSP, LL_CBIS_IND, LL_CBIS_TERMINATE_IND, LL_CBIS_SDU_CONFIG_REQ, or LL_CBIS_SDU_CONFIG_RSP, CtrData may include information required for a CBIS response, CBIS indication, CBIS termination indication, CBIS Service Data Unit (SDU) setup request, and CBIS SDU setup response.

[0228] Figure 19 (d) shows an example of audio data in PDU format.

[0229] Audio data PDUs can be either CBIS PDUs or broadcast isochronous PDUs. When used in a CBIS stream, an audio data PDU can be defined as a CBIS PDU. When used in a broadcast isochronous PDU, an audio data PDU can be defined as a broadcast isochronous PDU.

[0230] Audio data PDUs may include a 16-bit header field and a variable-length payload field. Additionally, audio data PDUs may include a MIC field.

[0231] In the case of CBIS PDU, the format of the header fields may include 2 bits LLID, 1 bit NESN, 1 bit SN, 1 bit Close Isochronous Event (CIE), 1 bit RFU, 1 bit Empty PDU Indicator (NPI), 1 bit RFU, and 9 bits Length subfield.

[0232] In the case of broadcast isochronous PDUs, the header field format may include a 2-bit LLID, a 3-bit Control Sub-Event Sequence Number (CSSN), a 1-bit Control Sub-Event Transmission Number (CSTF), a 2-bit RFU, and an 8-bit length subfield.

[0233] The payload field of an audio data PDU can include audio data.

[0234] Figure 20 This is a diagram illustrating an example of an advertising unit format to which this disclosure applies.

[0235] Figure 20 (a) An exemplary format of an Advertising Physical Channel PDU (Protocol Data Unit) is shown. An Advertising Channel PDU can be used to transmit packets on an Advertising Physical Channel (e.g., channel numbers 37, 38, 39). An Advertising Channel PDU can consist of a 2-byte header and a payload of 6 to 37 byte bytes.

[0236] Figure 20 (b) shows an exemplary format for the header of an advertising channel PDU. The header may include a PDU type, Reserved for Future Use (RFU), Sending Address (TxAdd), Receiving Address (RxAdd), Length, and an RFU field. The length field of the header may indicate the size of the payload.

[0237] Figure 20 (c) An exemplary format of the payload of an advertising channel PDU is shown. The payload may include an Advertiser Address (AdvA) field of 6 octets and an AdvData field of 0 to 31 octets. The AdvA field may include a public address or a random address of the advertiser. The AdvData field may include zero or more Ad Data (AD) structures, and may include padding if necessary.

[0238] Figure 20 (d) illustrates the format of an AD structure. An AD structure can include three fields. The length field indicates the length of the AD data field. That is, the length of the AD data field is obtained by subtracting 1 from the value indicated by the length field. The AD type field indicates the type of data included in the AD data field. The AD data field can include advertising data provided from the advertiser's host.

[0239] The following will describe examples of channel selection based on this disclosure.

[0240] Figure 21 This is a flowchart describing an implementation of the channel selection operation according to the present disclosure.

[0241] Figure 21 This is a flowchart illustrating an implementation method of the channel selection operation according to this disclosure.

[0242] In step S2110, the first device may instruct the second device whether to enable channel classification reporting. For example, the first device may be a master device, and the second device may be a slave device.

[0243] For example, information about whether channel classification reporting is enabled can be included in the link layer (LL) PDU associated with the channel reporting indication. For instance, the LL of the first device can send the channel reporting indication PDU to the LL of the second device, and the LL of the second device can receive it.

[0244] The channel report indicator can indicate whether channel classification reporting is enabled or disabled.

[0245] In step S2120, the second device may perform channel classification. For example, when the second device's channel classification report is enabled in step S2110, the second device may perform channel classification.

[0246] Channel classification can be performed in the LL of the second device. For example, the LL of the second device can perform channel classification based on one or more of the information provided from the host or channel sensing (or channel evaluation).

[0247] Channel classification can be performed on one or more channels. The results of channel classification can include the good, bad, or other states of each of the one or more channels. In addition, when the state cannot be known because channel sensing is impossible, the state (e.g., unknown) can also be included in the channel classification results.

[0248] Additionally, information related to channel classification within the second device's LL, provided from the host of the second device to the LL of the second device, may include channel mapping information. Specific examples of channel mapping information will be described later.

[0249] In step S2130, the second device may report the channel classification results to the first device.

[0250] For example, information about the channel classification result can be included in the LL PDU associated with the channel status indication. For instance, the LL of the second device can send the channel status indication PDU to the LL of the first device, and the LL of the first device can receive it.

[0251] When channel classification reporting is enabled and the channel classification result is changed, the second device can report additional (or updated) channel classification results to the first device.

[0252] In operation S2140, the first device can determine the channel mapping.

[0253] For example, the LL of the first device can determine the channel mapping based on at least one of the channel sensing (or channel evaluation) results in the first device, information provided by the host of the first device, or a channel classification result report received from the second device.

[0254] Based on the channel mapping determined by the first device, channel transition patterns can be applied. For example, the channel mapping can indicate used or unused channels, and channel transitions can be applied to used channels.

[0255] Although not in Figure 21 As shown, however, the channel mapping determined by the first device can be provided to the second device. Therefore, the second device can also perform transitions based on the channel mapping determined by the first device.

[0256] In addition, although in Figure 11 Although not shown in the diagram, an LL that has received a message / PDU exchanged between the LL of the first device and the LL of the second device can send an ACK message back to the LL that sent it.

[0257] The following text will describe and Figure 21 Various examples of this disclosure related to channel selection operations.

[0258] Interference can occur when a BLE channel partially or completely overlaps with a channel used by another device or network system (e.g., BR / EDR, Zigbee, WLAN (or Wi-Fi)). Since this interference affects BLE audio transmission performance, a method to avoid it is needed. However, conventional BLE systems do not support channel selection methods that consider channel status.

[0259] According to this disclosure, in a BLE system, the slave device reports channel status information or channel mapping to the master device, and the master device applies channel selection or channel mapping algorithms based on the reported information to avoid interfering with the channels.

[0260] Figure 22 It is a diagram used to describe channel mapping information to which the contents of this disclosure can be applied.

[0261] exist Figure 22 In the example, the advertising channel PDU is included in the PDU field of LL packet format, and the connection request (CONNECT_REQ) PDU is included in the payload field of the advertising channel PDU. The LL data field of the connection request PDU may include a channel mapping (ChM) field.

[0262] The channel mapping field can include channel mapping information indicating whether a data channel is used or unused. Each channel can be indicated by a bit located according to the data channel index. For example, the LSB can correspond to data channel index 0, and the 36th bit can correspond to data channel index 36. Furthermore, a bit value of 0 can indicate unused, and a bit value of 1 can indicate used. For example, when a channel is marked as unused, it may mean that there is interference in the corresponding channel or the interference is greater than a predetermined standard. Conversely, when a channel is marked as used, it may mean that the corresponding channel has no interference or the interference is less than a predetermined standard.

[0263] Such channel mapping information can be sent from the host of the master device to the LL, and connection request messages including the channel mapping field can be sent to the LL of the slave device.

[0264] Figure 23It is a diagram used to describe the channel structure of different network systems to which the contents of this disclosure can be applied.

[0265] Table 6 below shows the BLE RF channels. A total of 40 RF channels are defined, from 0 to 39, with a 2MHz interval between the center frequencies of each channel. Three channels are defined as advertising channels, with channel indices 37, 38, and 39. The remaining 37 channels are defined as data channels, with channel indices from 0 to 37.

[0266] Table 6

[0267]

[0268]

[0269] Channels defined by another network system (e.g., Wi-Fi (or WLAN), Zigbee, or BR / EDR) may exist in the 2.4 GHz Industrial Science and Medical (ISM) band, in which BLE channels are defined.

[0270] In the 2.4GHz band, in Wi-Fi, 13 channels with a center frequency spacing of 5MHz are typically defined, and... Figure 21 In the example, channels 1, 6, and 11 are shown as non-overlapping channels. In Zigbee, 16 channels are defined with a 5MHz spacing between center frequencies. In BR / EDR, 79 channels are defined with a 1MHz spacing between center frequencies. Therefore, because channels from other network systems are defined in the same frequency bands where BLE channels are defined, interference from the operation of devices from other network systems can affect BLE devices.

[0271] Figure 24 This is a diagram used to describe the relationship between BLE channels and WLAN channels to which the present disclosure can be applied.

[0272] exist Figure 24 In the diagram, compared to WLAN channels 1, 6, and 11, the frequency positions of channel indices 37, 38, and 39 corresponding to the advertising channels in the BLE channels are shown.

[0273] As mentioned above, BLE and BR / EDR use the 2.400MHz to 2483.5MHz spectrum as the ISM band. In the case of BR / EDR, 79 channels of 1MHz each are used for communication, while in the case of BLE, 20 channels of 2MHz each are used for communication.

[0274] Additionally, in Bluetooth systems, communication occurs by changing channels 1600 times per second to prevent interference. This is called frequency hopping.

[0275] When using frequency hopping for communication, channels with severe interference can be inspected, and frequency hopping can be performed on channels other than those being inspected. This is called adaptive frequency hopping (AFH).

[0276] In the case of BR / EDR, AFH can be performed using unused or used channels, indicated by the channel mapping of 79 channels. For example, in the case of BR / EDR, the hopping mode can be configured using channels without interference based on the channel mapping (e.g., channels indicated as "used" in the channel mapping), and frequency hopping can be performed.

[0277] In BLE, information about whether a channel, indicated by the channel mapping of the 37 data channels, is unused or used can be used in the channel selection algorithm. For example, in the case of BLE, if interference due to wireless communication from other network systems enters data channels 0, 1, and 2, the master device can check channels 0, 1, and 2 to configure the channel mapping as "unused" and the remaining channels as "used".

[0278] If switching to BR / EDR during BLE communication, the channel mapping information of the 37 data channels configured in BLE cannot be directly applied to BR / EDR operation to perform AFH in BR / EDR. Therefore, channel mapping of 79 channels can be configured and frequency hopping can be performed.

[0279] To perform channel selection operations based on channel mapping in a BLE system, the following requirements can be applied.

[0280] BLE slave devices can report channel classification information to the master device.

[0281] BLE channel classification information can include a comparison with BR / EDR channel classification information. For example, BLE channel classification information can classify channels according to the same criteria as BR / EDR channel classification information, or it can apply a new criterion. Additionally, BLE channel classification information can be defined by applying predetermined weights or scaling factors based on BR / EDR channel classification information. Furthermore, compared to BR / EDR channel classification information, BLE channel classification information can be defined as differential information including details about different components.

[0282] BLE channel classification information can include information about channel status. Channel condition indicates whether a channel is good or bad. For example, the channel state of a specific channel can indicate whether the corresponding channel's state is greater than or less than a predetermined threshold (i.e., two-level classification). Alternatively, channel state can be classified into two or more levels. For example, if a particular channel is good, bad, or if channel sensing (or channel evaluation) is insufficient for channel classification, the channel state can be classified as unknown.

[0283] Furthermore, the channel status can be determined based on whether packet errors occur in the corresponding channel. Additionally, the channel status can be determined based on factors such as interference amplitude, received signal strength, SINR, error rate, and energy detection in the corresponding channel.

[0284] Additionally, a protocol for channel selection operations based on channel mapping between BLE master and slave devices can be defined.

[0285] For example, the slave device can classify the channels and report the classification information to the master device.

[0286] Additionally, it can be configured to apply or not apply (on / off) features for channel mapping switching or features for channel selection based on channel mapping. The types / categories of these features can be defined. Furthermore, by subdividing these features, it can be configured to apply some or all of the features or not apply them at all.

[0287] As described above, the exemplary implementation of channel selection taking into account channel mapping according to this disclosure can greatly improve robustness and increase effective throughput.

[0288] Figure 25 This is a flowchart of an exemplary method for applying the channel mapping report of this disclosure.

[0289] exist Figure 25 In step 1, the master device may perform channel sensing. Channel sensing may include determining channel conditions. Additionally, channel sensing may include sensing BLE channels. Furthermore, channel sensing may also include sensing channels of another network system (e.g., Wi-Fi, BR / EDR, other networks (e.g., Zigbee)).

[0290] The master device may execute a Channel State Sharing Algorithm (CSSA) in step 2. CSSA may include determining the channel state in the second network system using channel sensing results from the first network system. Alternatively, CSSA may include determining the channel state in the first network system using channel sensing results from the second network system. The detailed operation of CSSA will be described later.

[0291] Meanwhile, the device can sense the channels of BLE and / or another network system (e.g., Wi-Fi, BR / EDR, other networks (e.g., Zigbee)) in step 1, and can perform CSSA operation in step 2.

[0292] In step 3, the slave device can send a channel status report to the master device. For example, the slave device can send the channel status report to the master device using a connectionless (or broadcast) method or a connection-based method.

[0293] In step 4, the master device can check the service type to be used and the priority of the corresponding service. For example, priorities can be assigned based on the time sensitivity of the service type. Examples of service types can include audio, medical, location, etc. For example, Wi-Fi can be idle, and the BLE audio service can be executed. Alternatively, the BLE heart rate measurement service can be executed while the Wi-Fi video streaming service is being executed. Alternatively, the BLE audio service can be executed while the Wi-Fi internet browsing service is being executed.

[0294] In step 5, taking into account various service types and priorities, the master device's BLE module (or controller) can negotiate with the slave device's BLE module (or controller) to minimize interference with the BLE channel. Such negotiation may include selecting a channel based on one or more of the following: channel status report information, service type, or service priority.

[0295] In step 6, services can be performed on the channel selected through negotiation.

[0296] Figure 26 This is a diagram illustrating an example of channel state sharing operations to which the contents of this disclosure can be applied.

[0297] Assume that the device performing CSSA operations according to this disclosure includes multiple types of network modules. For example, the device may include a first network module and a second network module. The first network module can determine the channel status of a first network channel and send the first network channel status information to the second network module. The second network module can determine the channel status of a second network channel and send the second network channel status information to the first network module. The channel status information of each network module can be exchanged or sent in one direction.

[0298] For example, the device may include a protocol stack containing a BLE host and a BLE controller, as well as a protocol stack containing a Wi-Fi host (or a higher layer above the MAC) and a Wi-Fi controller (or a PHY layer). Furthermore, the device may also include a protocol stack containing one or more other (or third, fourth, ...) network hosts and controllers.

[0299] The BLE controller can perform channel sensing on BLE channels. Channel sensing can include determining the status of BLE channels (e.g., packet error rate, etc.). The BLE host can generate channel mapping information indicating the used / unused status of each channel based on the channel status information sent from the BLE controller. Information exchange between the BLE host and the controller can be performed via HCI commands from the host to the controller and HCI events from the controller to the host. For example, HCI commands can include information about interference channel indications, which channel is used / applied to frequency hopping, etc. HCI events can include interference channel information. Furthermore, channel status information can be exchanged between BLE controllers.

[0300] Such BLE channel state information can be sent from the BLE host to the Wi-Fi host. Therefore, taking the BLE channel state into account, the Wi-Fi host can use channel selection or interference avoidance during Wi-Fi operation.

[0301] Simultaneously, the Wi-Fi controller can perform channel sensing on the Wi-Fi channel. For example, channel sensing can include using power detection methods or free channel assessment (CCA) methods to determine the level of interference. The channel state information of the Wi-Fi channel can be delivered to the BLE host via the Wi-Fi host.

[0302] In this way, the first network (e.g., BLE) channel status information and the second network (e.g., Wi-Fi) channel status information can be exchanged with each other, and the first network module can be used for first network channel selection or interference avoidance based on the second network channel status information, and the second network module can be used for second network channel selection or interference avoidance based on the first network channel status information.

[0303] Meanwhile, BLE hosts can receive channel status information obtained from channel sensing of other network controllers through other network hosts (e.g., BR / EDR, Zigbee, etc.), and BLE hosts can use this additional information to determine BLE channel selection or interference avoidance.

[0304] Figure 27 It is a diagram used to describe channel mapping shared timing that can be applied to this disclosure.

[0305] The Wi-Fi module can perform channel sensing on the Wi-Fi channel before data transmission and can perform data transmission on the Wi-Fi channel determined by channel sensing. When the Wi-Fi module receives channel mapping (or channel state) information of the BLE channel from the BLE module, it also receives channel state information of the BLE channel during channel sensing of the Wi-Fi channel. The channel can be determined through additional considerations.

[0306] With this in mind, when the BLE module receives the channel status information of the Wi-Fi channel from the Wi-Fi module, it can select the BLE channel or perform AFH.

[0307] In addition, the BLE module can share channel status information with the BR / EDR module, and perform BLE channel selection or AFH by taking into account the channel status information of the BR / EDR channel.

[0308] Figure 28 It is a diagram used to describe the activation or deactivation of channel mapping application functions that can be applied to service changes that may be subject to this disclosure.

[0309] Figure 28 Steps 1 to 4 can correspond to Figure 25 Steps 3 through 6. In other words, it can be done... Figure 28 Before step 1, channel sensing and CSSA operations are performed, and based on this, channel status reporting can be performed, and negotiation and services including channel selection can be performed, taking into account channel status information, service type, service priority, etc.

[0310] Here, in the negotiation operation of step 2, it can be determined whether the Channel Mapping (ChM) application function is activated or deactivated. When the Channel Mapping application function is activated, channel selection or AFH can be performed taking into account channel state information. When the Channel Mapping application function is deactivated, the service can be performed without considering channel state information.

[0311] When the channel mapping information of the BLE channel is provided to the Wi-Fi module in step 5, the Wi-Fi module can select a channel during the channel sensing period by taking into account the sensing results of the Wi-Fi channel (e.g., CCA results) and the channel mapping information of the BLE channel.

[0312] In step 6, you can check the service type and service priority of the service to be changed.

[0313] In step 7, a renegotiation can be performed, which includes selecting a BLE channel based on one or more of the following: channel mapping (or channel status) information, service type, or service priority. The renegotiation process may include activating or deactivating channel mapping application functionality.

[0314] In step 8, the service can be performed on the channel selected through renegotiation.

[0315] Figures 29 to 31 This is a diagram used to describe the operation of the Channel State Sharing Algorithm (CSSA) to which the contents of this disclosure can be applied.

[0316] CSSA can include: estimating the channel state in the second network based on the channel state information of the first network, and estimating the channel state in the first network based on the channel state information of the second network.

[0317] For example, using channel information obtained from BLE to estimate BR / EDR channel states can be called a BR / EDR channel estimation algorithm. Similarly, using channel information obtained from BR / EDR, Wi-Fi, and other networks to estimate BLE channel states can be called a BLE channel estimation algorithm. Likewise, using channel information obtained from BLE to estimate Wi-Fi channel states can be called a Wi-Fi channel estimation algorithm.

[0318] exist Figure 29 In the example, assume the first network is BLE and the second network is BR / EDR. n This represents the value (or variable) representing the channel state at BLE channel index n, and C n This represents the value (or variable) representing the channel status of BR / EDR channel index n.

[0319] C or CL is a 1-bit value and can have a value of 0 or 1. In this case, 0 can indicate that it is used and 1 can indicate that it is unused. That is, when the channel state is poor or there is a lot of interference, the channel state value can be 1. If the channel state is divided into two or more levels, C or CL can be defined as a value with a size of two or more bits.

[0320] In the case of BLE, the channel state value of a channel with a center frequency of 2042MHz can be defined as CL1, the channel state value of a channel with a center frequency of 2404MHz can be defined as CL2, ..., and the channel state value of a channel with a center frequency of 2480MHz can be defined as CL... 40 .

[0321] In the case of BR / EDR, the channel state value of a channel with a center frequency of 2401MHz can be defined as C1, the channel state value of a channel with a center frequency of 2402MHz can be defined as C2, ..., and the channel state value of a channel with a center frequency of 2479MHz can be defined as C... 79 .

[0322] The BR / EDR channel mapping estimation algorithm can be expressed as Equation 1 below.

[0323] Equation 1

[0324]

[0325] In Equation 1, when n is even (i.e., n mod 2 = 0), the estimated channel state of BR / EDR channel n can be determined based on the channel state information of BLE channels n / 2 and n / 2+1 (i.e., the estimated channel, EC). n For example, the channel state estimate (EC4) of BR / EDR channel 4 can be determined as the sum of the value obtained by applying a first scaling factor (S1) to the channel state information (CL2) of BLE channel 2 and the value obtained by applying a second scaling factor (S2) to the channel state information (CL3) of BLE channel 3. This is because even-indexed BR / EDR channels in the frequency domain correspond to the frequency positions of each segment of two consecutive BLE channels, which may mean that the channel state estimate of the BR / EDR channel is determined based on the channel state values ​​of these BLE channels.

[0326] Here, each of the scaling factors S1 or S2 can be defined as a value between 0 and 1. S1 and S2 can be defined as the same value or they can be defined independently.

[0327] In Equation 1, when n is odd (i.e., n mod 2 = 1), the channel state estimate of BR / EDR channel n (i.e., EC) is... nThe channel state information of BR / EDR channel n / 2 can be determined to be the same as that of BLE channel n / 2. For example, the channel state estimate EC3 of BR / EDR channel 3 can be determined to be the same as the channel state information CL2 of BLE channel 2. This may mean that, since the odd-indexed BR / EDR channels correspond to the BLE channels at the same position in the frequency domain, the channel state values ​​of the corresponding BLE channels are applied to the BR / EDR channels as is.

[0328] The BLE channel mapping estimation algorithm can be expressed as Equation 2 below.

[0329] Equation 2

[0330] ECL n =C 2n-1 +S1×C 2n +S2×C 2(n-1)

[0331] C0 = 0

[0332] C 80 =0

[0333] In Equation 2, the channel state estimate of BLE channel n can be determined based on the channel state information of BR / EDR channels 2n-1, 2n, and 2(n-1) (i.e., the estimated channel low energy, ECL). n For example, the channel state estimate (ECL2) of BLE channel 2 can be determined as the sum of the channel state information value (C3) of BR / EDR channel 3, the value obtained by applying a first scaling factor (S1) to the channel state information (C4) of BR / EDR channel 4, and the value obtained by applying a second scaling factor (S2) to the channel state information (CL2) of BR / EDR channel 2. This is because a BLE channel in the frequency domain is located at the same center frequency as one of the three BR / EDR channels and corresponds to the frequency position of each part of the other two BR / EDR channels, which may mean that the BLE channel state estimate is determined based on the channel state values ​​of these three BR / EDR channels. In CL1 and CL2 40 In this case, since there are only two corresponding BR / EDR channels, we assume C0 = 0 and C 80 =0.

[0334] exist Figure 30 In the example, assume the first network is BLE and the second network is Wi-Fi. n Indicates the value (or variable) representing the channel state of BLE channel index n, and CQI n Indicates the value (or variable) representing the channel state of Wi-Fi channel index n.

[0335] In the case of Wi-Fi, there are typically 13 channels in the 2.4GHz band, with a 5MHz interval between the center frequencies of the channels, and a channel width of approximately 20MHz. Consecutive Wi-Fi channels can overlap, and one of the following non-overlapping channels (1, 5, 9, 13, with center frequencies of 2412MHz, 2432MHz, 2452MHz, and 2472MHz) is primarily used. The channel status value for each of the 13 channels is defined as CQI. n (n = 1, 2, ..., 13).

[0336] It can be based on the channel status values ​​(C) of multiple BLE channels. L To determine the estimated channel state value of Wi-Fi channel n (i.e., the estimated channel state value of WLAN, WEC) n For example, since Wi-Fi channel 1 (2412MHz center frequency channel) corresponds to the positions of BLE channels 1 to 10, WEC-1 can be determined by CL1, CL2, ..., and CL... 10 The value obtained by multiplying each of the values ​​by the appropriate scaling factor and then adding them together.

[0337] Estimated channel state value (ECL) of BLE channel n n The value can be determined by multiplying the status value (CQI) of the corresponding Wi-Fi channel by a predetermined scaling factor. For example, a higher scaling factor value can be applied when it is close to the center frequency of the Wi-Fi channel, and a lower scaling factor value can be applied when it is far from the center frequency of the Wi-Fi channel.

[0338] Therefore, the estimated channel state value (WEC, ECL, or EC) can be determined based on a conversion table between the CQI as the channel state value of a Wi-Fi channel and the CL or C as the channel state value of BLE or BR / EDR. For example, in the case of frequently used Wi-Fi channels 1, 5, 9, and 13, approximately three times the value becomes the index of CL. However, three times is merely an example, and the scope of this disclosure is not limited thereto, and a correspondence between the CQI index of a Wi-Fi channel and one or more indices of C or CL can be defined.

[0339] For example, one or more channels of another network system (e.g., BLE, BR / EDR, Zigbee, etc.) can be predefined to correspond to the frequency location and bandwidth of a Wi-Fi channel. For instance, the correspondence between channels of different network systems can be defined as a matching table. Such a matching table can be used in the process of converting the channel state values ​​of one or more first channels of a first network system into the channel state values ​​of one or more second channels of a second network system.

[0340] exist Figure 31 In the example, assume that the CQI5 and CQI6 values, which are the channel state values ​​for Wi-Fi channels 5 and 6, are both 1. This means that the energy value detected from the corresponding Wi-Fi channel might indicate that the corresponding channel is being used by another device because it exceeds a predetermined standard. When determining the BLE Channel State Estimate (ECL) based on CQI values, different scaling factors can be applied to each BLE channel.

[0341] For example, scaling factors of 0.1, 0.3, and 0.7 can be applied to BLE channels 2, 3, and 4. If the estimated channel state value after applying the scaling is less than 0.5, the corresponding channel can be identified as used, and if the estimated channel state value after applying the scaling is greater than or equal to 0.5, the corresponding channel can be identified as unused. However, these reference values ​​are merely exemplary, and the scope of this disclosure is not limited thereto. For example, in Figure 29 In the example, when the CQI5 value, which is the channel status value of Wi-Fi channel index 5, is 1, scaling factors of 0, 0.1, 0.3, and 0.7 are applied to BLE channels CL1, CL2, CL3, and CL4, respectively, and ECL1 = 0, ECL1 = 0.1, ECL1 = 0.3, and ECL1 = 0.7 can be estimated. In this case, assuming a reference value of 0.2, BLE channel index 2 with an ECL value less than 0.2 is determined to be used, while BLE channel indices 3 and 4 with an ECL value of 0.2 or greater can be determined to be unused. Furthermore, since the CQI6 value, which is the channel status value of Wi-Fi channel index 6, is 1, the ECL values ​​of the scaling factors applied to the BLE channels are estimated based on this, and it can be determined whether each BLE channel is used based on the estimated ECL values.

[0342] As mentioned above, Bluetooth devices obtain EC or ECL via CSSA and use it to perform AFH. Additionally, when constructing a channel mapping based on estimated channel state values, the decision to use or not use a corresponding channel can be determined based on predetermined reference values.

[0343] In other words, based on the second network channel status values ​​measured for one or more second network channels in a second network system (e.g., BR / EDR, Wi-Fi, Zigbee, etc.), an estimated first network channel status value for a specific first network channel in a first network system (e.g., BLE) can be determined. If the determined first network channel status value is equal to or greater than a predetermined reference value, the first network channel is determined to be unused; if the determined first network channel status value is less than the predetermined reference value, the first network channel can be determined to be used.

[0344] The following sections will describe examples of digital key security protocols and authentication based on this disclosure.

[0345] Figure 32 It is a diagram used to describe digital key operations to which the contents of this disclosure can be applied.

[0346] The key device can discover advertising devices based on advertising information provided by the vehicle (e.g., ADV_EXT_IND messages). Furthermore, the key device can send connection request messages to the discovered advertising devices (e.g., the vehicle). Therefore, encryption, connection establishment, and ranging processes can be performed between the vehicle and the key device. For example, the secure link between the key device and the vehicle can be secured through the connection establishment process, and an L2CAP CoC (Logical Link Control and Adaptation Protocol Connection-Oriented Channel) link for a BR / EDR or BLE network system can be established for high-speed data exchange. Subsequently, it is handed over to the ultra-wideband (UWB) network system, and synchronization can be performed through the UWB ranging process, thus enabling precise positioning.

[0347] In such digital key technology, for a fast authentication process, it is possible to consider segmenting or fragmenting the information or packets exchanged via BLE.

[0348] Additionally, it is advisable to identify characteristics associated with digital keying technology and define key types. (Refer to...) Figure 35 Describe the key type in detail.

[0349] Alternatively, information for digital key connections could be exchanged at the application layer (e.g., GATT) or the middleware layer (e.g., L2CAP CoC).

[0350] Additionally, the data to be exchanged via BLE may include information for handover and / or key-related information.

[0351] In addition, key management includes user, multiple vehicle, ID management, etc., and a protocol needs to be defined for this purpose.

[0352] Additionally, authentication methods are needed to prevent man-in-the-middle (MITM) attacks.

[0353] Additionally, operations can be defined for managing key status (e.g., refreshing, activating keys, etc.).

[0354] Figure 33 This is a diagram used to describe an example of user registration and management that can be applied to this disclosure.

[0355] For example, it can support one user registering in one key device (user A, key device #1), multiple users registering in one key device (users B and C, key device #2), and one user registering in multiple key devices (user D, key devices #3 and #4), etc.

[0356] A digital key profile (DK profile) can be generated for each application, or multiple applications can share a DK profile. For example, a DK profile corresponding to a key device may be common to a first application corresponding to a first vehicle and a second application corresponding to a second vehicle.

[0357] The DK configuration file may include the registration ID (1 byte), registration session number (2 bytes), token (8 bytes or 24 bytes (application message authentication code (MAC) (MACed))), factor type (2 bytes), etc.

[0358] Here, factor types can be distinguished based on the method used to generate the token. For example, the factor type can indicate the basic information used by the key device to generate the token. Additionally, the factor type can be configured as a bitmap indicating which of the various pieces of basic information is available.

[0359] For example, the basic information used to generate a token may include at least one of the following: personal identification number (PIN), password, fingerprint, face, voice, iris, electrocardiogram (ECG), gait, gesture, on-body, activity, device unlock, finger vein, palm vein, distance limit, and customer-defined factors.

[0360] For example, multiple different tokens can be defined and stored for a single ID. Additionally, one or more tokens for each of the multiple IDs can be stored in a token storage device.

[0361] For example, after exchanging keys with the vehicle, the key device can generate a registration ID and exchange it with the vehicle. Additionally, the vehicle can match the key device's registration ID with token information and store and manage the token information in a token storage device.

[0362] Figure 34 It is a diagram used to describe the digital key security protocols and message formats to which the contents of this disclosure can be applied.

[0363] When the key device and the vehicle are in BLE connection mode, the key device can send a write request message to the vehicle, and the vehicle can send a notification or indication message to the key device. The format of the write request message may include a message type field and a parameter field. The format of the notification or indication message may include a request message type field, a result code (or error code) field, and a response parameter field.

[0364] For example, the key device can send a write request message to the vehicle to initiate registration. The registration initiation message can correspond to the key device requesting the vehicle to initiate the registration process. In response, the vehicle can send a registration server hash commit instruction message to the key device. The registration server hash execution message can correspond to a message notifying the server whether message authentication has been successful. If the initiation message is authenticated, the authentication protocol between the key device and the vehicle can be executed.

[0365] For example, the authentication protocol may include: a key device sending a write request message for the registered client's public key to the vehicle, which may correspond to a message conveying the key device's public key to the vehicle. Subsequently, the vehicle may send an instruction message for the registration server's public key to the key device, which may correspond to a message for transmitting the vehicle's public key to the key device. Then, the key device may send a write request message to the vehicle to confirm the registered client, which may indicate whether normal authentication is performed and may correspond to a message confirming the key's validity.

[0366] although Figure 34 The example shows 0x11 as a value of the message type, but this is just an example.

[0367] Figure 35 It is a diagram used to describe the process of establishing a digital key bearer to which the contents of this disclosure can be applied.

[0368] The maximum transmission unit (MTB) can be negotiated before the authentication protocol between the key device and the vehicle is executed.

[0369] When the key device and the vehicle are in a BLE connection state, the key device can send an MTU exchange request message to the vehicle. For example, in the MTU exchange request message, the attribute opcode can be configured as 0x02, and the MTU value can be configured as 300 bytes. In response, the vehicle can send an MTU exchange response message to the key device. For example, in the MTU exchange response message, the attribute command code can be configured as 0x03, and the MTU value can be configured as 300 bytes. However, 300 bytes is merely an exemplary value, and values ​​smaller or larger can be determined through MTU negotiation. For example, when it is necessary to send a message with a larger MTU value than determined, segmentation or fragmentation is applied to the message, and the message can be divided into messages with an allowed MTU size or smaller.

[0370] Additionally, when segmentation or fragmentation is supported, the exchanged information can be divided into segments of a predetermined size (e.g., 20 bytes) or smaller. For example, 89 bytes of information can be divided into four 20-byte segments and one 9-byte segment. A segment header and a message authentication code (MAC) can be added to each segment.

[0371] In addition, depending on the authentication type, it can support various formats or key types based on ECDH (Elliptic Curve Diffie-Hellman) key exchange, AES-GMAC (Advanced Encryption Standard - Galois Message Authentication Code), AES-GCM (Advanced Encryption Standard - Galois / Counter Mode), and out-of-band (OOB) key schemes. Figure 33 The various formats shown can correspond to formats used to support segmentation or fragmentation. A specific key type can be identified by a type ID. The key type to be used for security by two devices can be determined as one of various key types. Various formats, including fields corresponding to the information required for security, can be defined based on the determined key type.

[0372] Figure 36 This is a diagram used to describe authentication methods that can be applied to this disclosure.

[0373] The authentication method may include the step of the key device sending an authentication request message to the vehicle in response to input from the user (e.g., button operation). Thus, an authentication action is performed in the vehicle (e.g., outputting light and / or sound), and the user can identify that authentication is being attempted or performed by checking this. Subsequently, when the authentication process between the key device and the vehicle is completed and an authentication response including information indicating successful authentication (OK) is finally sent from the vehicle to the key device, a secure link is established and secure information can be exchanged.

[0374] Simultaneously, when user A provides input to the key device, the key device can send the authentication request message to user B's vehicle instead of user A's vehicle. In this case, user B's vehicle performs an authentication action indicating that authentication is being attempted or is being performed, thus allowing user A to recognize that authentication was attempted on user B's vehicle. An authentication response containing information indicating failure can then be sent from user B's vehicle to the key device.

[0375] Simultaneously, authentication request messages from third parties (e.g., hacker devices or users) can be sent to user A's vehicle. User A can detect an anomaly by confirming that an authentication attempt or action was performed in user A's vehicle without input being applied to the key device. An authentication response, including information indicating failure, can then be sent to the third party.

[0376] Figure 37 This is a diagram illustrating the process of generating authentication questions to which the contents of this disclosure can be applied.

[0377] User A can input into a key device to send an authentication request message. This message can be delivered to User A's vehicle, which is its intended destination, but it could also be delivered to a third party (e.g., a hacker's device or the user) or intercepted en route by a third party. A third party can generate an authentication request message that is copied in the same manner as User A's normal authentication request and send that message to User A's vehicle.

[0378] In this scenario, user A can identify a normal authentication process as being performed through an authentication action indicating that authentication is being attempted or completed within the vehicle. However, in practice, the vehicle can send a response message, including an indication of success (OK), to both the key device and the third party in response to the same authentication message. Therefore, the vehicle can establish secure links with third parties to exchange security information.

[0379] Figure 38 This is a diagram used to describe authentication error resolution methods to which the contents of this disclosure can be applied.

[0380] The first method may include methods for detecting replication request / response messages or setting timers.

[0381] For example, when the same authentication request message is received from different entities within the vehicle, a duplicate authentication request message can be detected and treated as an error. The vehicle could, for instance, output a signal indicating a duplicate authentication request, or send an authentication response message including information indicating authentication failure to the device that requested authentication.

[0382] Additionally, the key device can process responses received during a predetermined timer operation (or between predetermined time intervals) from the time the authentication request message is sent as valid authentication responses, and the key device can process responses received when the timer is not running (or before or after a certain time interval) as invalid authentication responses.

[0383] Furthermore, even if a normal authentication response message is received, the key device can wait until the set timer value expires. If additional or overlapping authentication response messages are received before the timer expires, this can be considered an error condition.

[0384] Additionally, authentication request messages sent from a third-party key device (hacker) can be generated to replicate authentication request messages from a legitimate key device or identified as originating from a legitimate key device. In this case, the vehicle can start a predetermined timer upon receiving a first authentication request message from the first key device, and if a replicated authentication request message is received from the same first key device during the predetermined timer operation, the vehicle can treat it as an error.

[0385] The second method may include a method for performing mutual ranging checks between the key device and the vehicle.

[0386] For example, when a vehicle receives an authentication request message, it can perform a ranging check on the device that sent the message. Additionally, the key device can perform a ranging check on the vehicle. Furthermore, the key device and the vehicle can perform mutual ranging checks. If an authentication request from a third party is invalid, the third party will not respond to the ranging check from the vehicle or will not perform a ranging check on the vehicle; therefore, it can be considered an invalid authentication request. Furthermore, ranging checks can include performing precise location determination using methods such as High-Precision Distance Measurement (HADM) or Angle of Arrival (AoA).

[0387] Figure 39 This is a diagram illustrating the configuration of the first and second devices to which this disclosure applies.

[0388] The first device 3900 may include a processor 3910, an antenna unit 3920, a transceiver 3930, and a memory 3940.

[0389] Processor 3910 can perform baseband-related signal processing and may include host processor 3911 and controller processor 3915. Host processor 3911 and controller processor 3915 can exchange information via HCI. Host processor 3911 can handle operations such as L2CAP profile layer, ATT profile layer, GATT profile layer, GAP profile layer, and LE profile layer. Controller processor 3915 can handle operations such as LL layer and PHY layer. In addition to performing baseband-related signal processing, processor 3910 can also control the overall operation of first device 3900.

[0390] Antenna unit 3920 may include one or more physical antennas. Transceiver 3930 may include an RF (radio frequency) transmitter and an RF receiver. Memory 3940 may store information processed by processor 3910 and software, operating system, and applications related to the operation of the first device 3900, and memory 3940 may include components such as buffers.

[0391] The processor 3910 of the first device 3900 can be configured to perform the operation of the first device (or master device) in the embodiments described in this disclosure.

[0392] For example, the LL processing unit 3915 of the processor 3910 of the first device 3900 can instruct the LL processing unit 3965 of the second device 3950 whether to enable channel classification reporting.

[0393] The LL processing unit 3915 of the first device can receive channel classification reports from the LL processing unit 3965 of the second device.

[0394] The LL processing unit 3915 of the first device can determine the channel mapping based on at least one of the channel sensing results of the LL processing unit 3915, the channel classification report received from the LL processing unit 3965 of the second device, or the information provided by the host processing unit 3911.

[0395] The LL processing unit 3915 of the first device can provide the determined channel mapping to the LL processing unit 3965 of the second device.

[0396] The second device 3950 may include a processor 3960, an antenna unit 3970, a transceiver 3980, and a memory 3990.

[0397] Processor 3960 can perform baseband-related signal processing and may include host processor 3961 and controller processor 3965. Host processor 3961 and controller processor 3965 can exchange information via HCI. Host processor 3961 can handle operations such as L2CAP profile layer, ATT profile layer, GATT profile layer, GAP profile layer, and LE profile layer. Controller processor 3965 can handle operations of LL layer, PHY layer, etc. In addition to performing baseband-related signal processing, processor 3960 can also control the overall operation of second device 3950.

[0398] Antenna unit 3970 may include one or more physical antennas. Transceiver 3980 may include an RF transmitter and an RF receiver. Memory 3990 may store information processed by processor 3960 and software, operating system, and applications related to the operation of second device 3950, and memory 3990 may include components such as buffers.

[0399] The processor 3960 of the second terminal device 3950 can be configured to perform the operation of the second device (or slave device) in the embodiments described in this disclosure.

[0400] For example, the LL processing unit 3965 of the processor 3960 of the second device 3950 can receive whether a channel classification report is enabled from the LL processing unit 3915 of the first device. When the channel classification report is enabled, the LL processing unit 3965 of the second device can generate a channel classification result based on one or more of the information provided from the host processing unit 3961 or the channel sensing results performed by the LL processing unit 3965. The generated channel classification result can be reported from the LL processing unit 3965 of the second device to the LL processing unit 3915 of the first device.

[0401] The LL processing unit 3965 of the second device can receive channel mapping from the LL processing unit 3915 of the first device.

[0402] In the operation of the first device 3900 and the second device 3950, the descriptions of the first device (or master device) and the second device (or slave device) in the examples of this disclosure are equally applicable, and therefore repeated descriptions are omitted.

[0403] Various embodiments of this disclosure can be implemented by hardware, firmware, software, or a combination thereof. For hardware implementation, various embodiments of this disclosure can be implemented as one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), or general-purpose devices. It can be implemented by processors (general-purpose processors), controllers, microcontrollers, microprocessors, etc.

[0404] The scope of this disclosure includes software or machine-executable instructions (e.g., operating systems, applications, firmware, programs, etc.) and non-transitory computer-readable media that cause operations according to various embodiments to be performed on a device or computer, such software or instructions being stored in the non-transitory computer-readable medium and executed on the device or computer. Instructions that can be used to program a processing system to perform the features described in this disclosure can be stored on / in a storage medium or a computer-readable storage medium, and the features described in this disclosure can be implemented using a computer program product including such a storage medium. The storage medium may include, but is not limited to, high-speed random access memory or other random access solid-state memory devices such as DRAM, SRAM, DDR RAM, one or more disk storage devices, optical disk storage devices, flash memory devices; or the storage medium may include non-volatile memory, such as other non-volatile solid-state memory devices. The memory may optionally include one or more storage devices remotely located from a processor. The non-volatile memory device within the memory or alternatively the memory includes a non-transitory computer-readable storage medium. The features described in this disclosure can be stored on any of a machine-readable medium to control the hardware of a processing system, and can be incorporated into software and / or firmware that allows the processing system to interact with other entities that utilize the results of implementations according to this disclosure. Such software or firmware may include, but is not limited to, application code, device drivers, operating systems, and execution environments / containers.

[0405] [Industrial Applicability]

[0406] The embodiments of this disclosure can be applied to various wireless communication systems to improve the performance of the wireless communication systems.

Claims

1. A method for selecting a first device channel in a wireless communication system, the method comprising: The first LL protocol data unit (PDU) is sent from the link layer LL of the first device to the link layer LL of the second device. The first LL protocol data unit (PDU) includes information indicating whether a report on channel classification information is enabled or disabled. The first LL acknowledgment is received from the link layer LL of the second device via the link layer LL of the first device; The first device receives a second LL protocol data unit (PDU) including a channel classification report from the second device's link layer LL based on information indicating enable, wherein the second device does not send the second LL protocol data unit (PDU) to the first device based on information indicating disable. The second LL acknowledgment is sent from the link layer LL of the controller of the first device to the link layer LL of the second device; and Channel mapping is determined based on the channel classification report and the channel evaluation of the first device. The channel classification report includes the channel status based on the channel assessment in the link layer LL of the second device. Among them, frequency hopping mode is applied based on the channel mapping, and The channel mapping indicates whether each of one or more channels is used.

2. The method according to claim 1, wherein, The channel status includes good, bad, or unknown.

3. The method according to claim 1, wherein, The channel mapping determined by the first device is provided to the second device.

4. The method according to claim 1, wherein, The first device is a master device or a central device, and the second device is a slave device or a peripheral device.

5. An apparatus on a first device side for performing channel selection in a wireless communication system, the apparatus comprising: A transceiver, the transceiver being used to perform signal transmission and reception with a second device; as well as The processor is used to control the transceiver and the device. The processor is configured as follows: The first LL protocol data unit (PDU) is sent from the link layer LL of the first device to the link layer LL of the second device via a transceiver. The first LL protocol data unit (PDU) includes information indicating whether a report on channel classification information is enabled or disabled. The first link layer LL acknowledgment is received from the link layer LL of the second device via the transceiver through the link layer LL of the first device; Based on the information indicating that it is enabled, the second LL protocol data unit (PDU) including a channel classification report is received from the link layer LL of the second device via a transceiver through the link layer LL of the first device, wherein the second device does not send the second LL protocol data unit (PDU) to the first device based on the information indicating that it is disabled. The second link layer LL acknowledgment is sent from the link layer LL of the controller of the first device to the link layer LL of the second device via a transceiver; and Channel mapping is determined based on the channel classification report and the channel assessment of the first device. The channel classification report includes the channel status based on the channel assessment in the link layer LL of the second device. Among them, frequency hopping mode is applied based on the channel mapping, and The channel mapping indicates whether each of one or more channels is used.

Images