Method, apparatus, and computer program for setting encryption keys 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 setting an encryption key in a wireless communication system. According to one embodiment of the present disclosure, a method for setting an encryption key size in a wireless communication system can include the steps of a first controller of a first device receiving a first message from a first host of the first device, the first message containing information on a minimum value of a first encryption key size; and the first controller transmitting a second message indicating an encryption change to the first host. The second message can contain information on the first encryption key size.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to a method, an apparatus, a computer program, and a recording medium thereof for encryption key configuration in a wireless communication system. BACKGROUND

[0002] Bluetooth is a short-range wireless communication standard, and includes BR (Basic Rate) / EDR (Enhanced Data Rate) technology and LE (Low Energy) technology. BR / EDR is also referred to as Bluetooth Classic, and includes BR technology applied by Bluetooth 1.0 and EDR technology applied by Bluetooth 2.0. Bluetooth LE (BLE) applied after Bluetooth 4.0 is a technology supporting transmission and reception of a relatively large amount of data with low power consumption.

[0003] The Bluetooth standard includes various profiles. For example, a hands-free profile (HFP) defines a necessary condition for one device to serve as an audio gateway (AG), such as a smart phone, and another device to serve as a hands-free device, such as a headset. In addition, A2DP (Advanced Audio Distribution Profile) defines a necessary condition for one device to serve as an audio source, such as a music player, and another device to serve as an audio sink, such as a speaker.

[0004] With the recent popularity of wireless devices, there is an increasing demand for transmission and reception of audio data in various topologies of a multiple-to-multiple or M-to-N connection type. For example, streaming services requiring a 5.1 channel environment are emerging, and there is a discussion of using multiple Bluetooth portable speakers to support a 5.1 channel environment, thereby getting rid of the limitations of conventional 5.1 channel dedicated wired speakers. However, since the conventional Bluetooth audio technology is developed mainly considering a use case of one-to-one connection between two devices, it is not suitable for supporting audio data transmission / reception between multiple devices, and latency is a big problem. In addition, as the number of Bluetooth audio devices increases, there is a problem of an increase in power consumption for searching for peripheral devices.

[0005] The encryption key used in the conventional Bluetooth standard supports a size of 8 bits to 128 bits. However, the conventional encryption key size has a problem of weak security due to its short length, and thus needs to be corrected. SUMMARY

[0006]

Technical Problem

[0007] The technical problem of the present disclosure is to provide a method and an apparatus for controlling an encryption key between a host and a controller related to a device in a wireless communication system.

[0008] Another technical problem of the present disclosure is to provide a method and an apparatus for configuring an encryption key size between a host and a controller related to a device in a wireless communication system.

[0009] Still another technical problem of the disclosure is to provide a method and apparatus in which a controller related to a device provides a host with information about a cipher key size in a wireless communication system.

[0010] The technical problems to be achieved in the disclosure are not limited to the above-mentioned technical problems, and other technical problems not mentioned will be clearly understood by those skilled in the art to which the disclosure pertains from the following description.

[0011]

Technical Solution

[0012] A method of configuring a cipher key size in a wireless communication system according to an aspect of the disclosure can include receiving, by a first controller related to a first device, a first message including information about a minimum value of a first cipher key size from a first host related to the first device, and transmitting, by the first controller, a second message indicating a cipher change to the first host, and the second message can include information about the first cipher key size.

[0013] A first device for configuring a cipher key size in a wireless communication system can include a transceiver for performing signal transmission and reception with another device, and a processor for controlling the transceiver and the device. The processor can be configured to cause a first controller related to the first device to receive a first message including information about a minimum value of a first cipher key size from a first host related to the first device, and cause the first controller to transmit a second message indicating a cipher change to the first host. The second message can include information about the first cipher key size.

[0014] The features described above with respect to the disclosure are merely exemplary aspects of the following detailed description of the disclosure, and do not limit the scope of the disclosure.

[0015]

Technical Effects

[0016] According to the disclosure, a method and apparatus for controlling a cipher key between a host and a controller related to a device in a wireless communication system can be provided.

[0017] According to the disclosure, a method and apparatus for configuring a cipher key size between a host and a controller related to a host in a wireless communication system can be provided.

[0018] Still another technical problem of the disclosure is to provide a method and apparatus in which a controller related to a device provides a host with information about a cipher key size in a wireless communication system.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0037] Figure 21 An exemplary HCI grouping format to which this disclosure applies is shown.

[0038] Figure 22 This is a diagram illustrating an example of an encryption configuration method to which this disclosure applies.

[0039] Figure 23 This is a diagram illustrating an additional example of an encryption configuration method to which this disclosure applies.

[0040] Figure 24 An exemplary device related to encryption configuration to which this disclosure applies is shown.

[0041] Figure 25 This is a diagram illustrating an example of a configured encryption key size to which this disclosure applies.

[0042] Figure 26 This is a diagram illustrating an additional example of the configuration encryption key size to which this disclosure applies.

[0043] Figure 27 An example of configuring the minimum encryption key size for each service / configuration file to which this disclosure applies is shown.

[0044] Figure 28 This is a diagram illustrating the configuration of the first and second devices to which this disclosure applies. Detailed Implementation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0081] 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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0110] 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(INCLCH1 interval or ISO interval). One or more sub-events can be included in a streaming event.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0167] Table 1

[0168]

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

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

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

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

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

[0174] Table 2

[0175]

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

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

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

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

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

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

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

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

[0184] Table 3

[0185]

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

[0187] Table 4

[0188]

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

[0190] 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 either call hold or call active mode is terminated, it can transition to audio standby mode.

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

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

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

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

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

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

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

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

[0199] Table 5

[0200]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0220] 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 the CBIS response, CBIS indication, CBIS termination indication, CBIS Service Data Unit (SDU) setup request, and CBISSDU setup response.

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

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

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

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

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

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

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

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

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

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

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

[0232] The encryption key configuration according to this disclosure will be described below.

[0233] In Bluetooth communication systems, when the Link Manager Protocol (LMP) or dual-mode Bluetooth controller used for BR / EDR encrypts the wireless (OTA) channel using E0 or AES (Advanced Encryption Standard) - CCM (Cipher Block Link-Message Authentication Code) block cipher method, a process is defined for selecting the minimum length of the encryption key. This is one of the measures to comply with regulations regarding the strength of encryption algorithms used in user equipment. However, since the introduction of this process into Bluetooth communication systems, these regulations have been modified or updated in various regions.

[0234] Block injection attacks can occur during the negotiation process for encryption key length. For this reason, a MITM (Man-in-the-Middle) device might intentionally reduce the key length used for a specific baseband link, thereby generating a link that can be decrypted in real-time without discrimination. Such attacks can occur if both devices involved in establishing the encrypted link are simultaneously vulnerable.

[0235] For current Bluetooth communication systems, the possibility of such attacks can be considered. For example, the GAP section (e.g., BR / EDR security mode 4) includes the following steps: checking the encryption key size of the link after encryption is established to confirm that a key size sufficient for the specific purpose has been selected. Furthermore, some Bluetooth profiles use this method to require a certain minimum key length.

[0236] There are implementations that are security-vulnerable by allowing negotiated key lengths and do not always check the negotiated key length; and in some implementations, if a reduced key length can be negotiated, the minimum allowed length can be easily and indiscriminately decrypted.

[0237] The Bluetooth communication system has been updated to enforce GAP-level key length checks and recommends or mandates new encryption key lengths in the Bluetooth host implementation. Improvements have also been made to support the minimum encryption key length recommended in the Bluetooth controller hardware. Qualification testing is also required to verify that the implementation meets these requirements.

[0238] Before adopting changes to the Bluetooth standard, implementations must adhere to existing standards with insufficient encryption key sizes. Therefore, it is recommended that the host enforce a 7-byte or more 8-byte key encryption for each encrypted link being established. Hosts using the Host Controller Interface (HCI) and controllers supporting the HCI command "Read Encryption Key Size" are encouraged to use this command to determine the length of the selected encryption key for the encrypted link after an event indicating a successful encryption establishment has been received. Updates are needed to require controllers supporting the HCI interface to support these HCI commands. In controllers that do not support HCI or in architectures where the host and controller are integrated, the GAP layer or higher can perform equivalent operations.

[0239] If backward compatibility requirements permit, Bluetooth devices can operate in secure connection-only mode, using random number generators (RNGs), hashing, and block encryption algorithms compatible with the Federation Information Processing Standard (FIPS). Additionally, improvements are needed to ensure the minimum key length for secure connection mode meets the 16-byte cryptographic key length requirement.

[0240] As mentioned above, security vulnerabilities caused by short encryption key lengths are a problem in existing Bluetooth communication systems, thus requiring a modification to the encryption key length. Below, implementation methods for setting encryption keys, particularly the encryption key size (or length), according to this disclosure will be described.

[0241] For reference Figure 2 As described, a Bluetooth device may include a host layer and a controller layer, and the interface layer between the host layer and the controller layer is called the Host Controller Interface (HCI).

[0242] HCI provides a unified way for hosts to access the functionality of the controller. Communication via the HCI interface is packet-based. Hosts can send HCI command packets to the controller and receive notifications asynchronously from the controller using HCI events. Packets sent / received on the HCI interface can be of one of four types: HCI command packets, HCI asynchronous data packets, HCI synchronous data packets, and HCI event packets.

[0243] Figure 21 An exemplary HCI grouping format to which this disclosure applies is shown.

[0244] Figure 21 (a) shows an example of the HCI command grouping format, and Figure 21 (b) shows an example of the HCI event grouping format.

[0245] As in Figure 21 In example (a), the HCI command packet is used by the host to send commands to the controller.

[0246] Each command is assigned a unique OpCode of 2 bytes (or 8 bits), and the OpCode is divided into two fields: OGF (OpCode Group Field) and OCF (OpCode Command Field). OGF is used to group similar OpCodes, and OCF is used to identify a specific instruction within the OpCode group.

[0247] The 1-byte parameter total length field specifies the total length of all parameters included in the remainder of the HCI command group, in octet units. One or more command parameters may be included after the parameter total length field.

[0248] As in Figure 21 In example (b), the HCI event packets are used by the controller to notify the host when an event is about to occur. HCI events may be generated as a response to an HCI command previously sent from the host, or due to another event (e.g., an error occurs, a connection is lost, a connection request is received, etc.).

[0249] HCI event groups include a 1-byte event code field. The event code may include a value that identifies an event that has occurred.

[0250] The 1-byte parameter total length field specifies the total length of all parameters included in the remainder of the HCI event group, in octet units. One or more event parameters may be included after the parameter total length field.

[0251] Despite Figure 21Although not shown, HCI asynchronous data packets can be used to exchange data between the host and the controller, and can be exchanged after a connection is established. HCI synchronous data packets are used to exchange synchronization data between the host and the controller.

[0252] Table 6 below shows examples of HCI commands or events used for connection encryption.

[0253] Table 6

[0254] Set connection encryption command

[0255]

[0256] Connection_Handle: Size: 2 octets (12 meaningful bits)

[0257]

[0258] Encryption_Enable: Size: 1 octet

[0259] Value Parameter description 0x00 Link level encryption off 0x01 Link level encryption on

[0260] The Set_Connection_Encryption (or HCI_Set_Connection_Encryption) command can be used to enable and disable link-level encryption.

[0261] The Connection_Handle command parameter can be used to identify another controller from which a connection is being established. Connection_Handle can be an asynchronous connection. Encryption configuration can be applied to all Connection_Handle parameters that share the same remote controller. When encryption is being changed, the link manager may stop all asynchronous traffic on the connection.

[0262] When both devices support both the Secure Connection (controller supported) and Secure Connection (host supported) features and encryption is currently enabled on a specific Connection_Handle, the controller can return an error code (e.g., 0x25) indicating that the encryption mode is unacceptable if the Encryption_Enable parameter is configured to a value indicating that link-level encryption is off (makes link-level encryption disabled).

[0263] When the controller receives the HCI_Set_Connection_Encryption command, it can send an HCI_Command_Status event to the host. When the link manager completes enabling / disabling encryption for the connection, the local controller can send an HCI_Encryption_Change event to the host, and controllers on remote devices can also generate HCI_Encryption_Change events.

[0264] When various HCI commands are designed, such as the example above for HCI_Set_Connection_Encryption, they can be implemented in software, such as the hci_map structure. Table 7 shows examples of source code including the hci_map structure (e.g., BlueZ, which is an open-source Bluetooth protocol stack).

[0265] Table 7

[0266]

[0267] Newly designed instructions can be added to the hci_map structure, as shown in the examples in Table 7. For example, as shown in Table 8, commands such as read_encrypt_key_size_cmd and read_encrypt_key_size_rsp can be designed separately and invoked and used via set_bredr_command.

[0268] Table 8

[0269]

[0270] Return to reference Figure 2 This will describe the protocol stack to which this disclosure applies.

[0271] Figure 2 (a) shows the BR / EDR protocol stack. Figure 2 (b) shows the BLE protocol stack.

[0272] Hosts are typically implemented in software, and controllers are typically implemented in hardware, but the scope of this disclosure is not limited thereto. Each host or controller can be configured in the form of software, hardware, a combination of software and hardware, or firmware.

[0273] In the case of BR / EDR, security-related entities may be included in the controller. Similarly, in the case of LE, the functionality of the Security Manager (SM) may be included in either the controller or the host. In the examples of this disclosure, encryption and security-related functions are not limited to being included solely in the controller or host.

[0274] Entities that issue HCI commands to controllers and hosts / configuration files / services can be included in the host. The parts corresponding to configuration files / services can be included in higher layers.

[0275] For example, commands can be passed in the following order: configuration file, security entity (e.g., SM for LE), HCI, controller (e.g., LL for LE).

[0276] Figure 22 This is a diagram illustrating an example of an encryption configuration method to which this disclosure applies.

[0277] Reference Figure 22 The first device includes a controller and a host, and the second device also includes a controller and a host.

[0278] In step S2210, LMP_encryption_mode_req messages and LMP_encryption_key_size_req messages (or PDUs) can be exchanged between the controller of the first device and the controller of the second device.

[0279] The LMP_encryption_mode_req message can be used to enable or disable encryption mode (or secure mode). The LMP_encryption_mode_req message can be sent from a device enabling / disabling an encryption mode set via the HCI_Set_Connection_Encryption command (e.g., the first device) to a corresponding device (e.g., the second device). A device receiving the LMP_encryption_mode_req message can respond using the LMP_accepted message (not shown).

[0280] The LMP_encryption_key_size_req message can include information about the encryption key size suggested by the master device. The LMP_encryption_key_size_req message can be sent from the master device to the slave device. A device receiving the LMP_encryption_key_size_req message can respond using the LMP_accepted message (not shown).

[0281] In addition, although in Figure 22 Not shown, but after exchanging the LMP_encryption_key_size_req message and its response, the LMP_start_encryption_req message and its response (e.g., the LMP_accepted message) can be exchanged to prepare the encryption application according to the configured encryption mode and key size.

[0282] In step S2220, the controller of the first device may send an HCI_Encryption_Change event to the host. The HCI_Encryption_Change event may include information indicating (e.g., sending information using an indication of enabling) that the encryption change of the Connection_Handle specified by the Connection_Handle event parameter has been completed (e.g., the Encryption_Enable parameter).

[0283] After receiving the HCI_Encryption_Change event from the controller, in operation S2230, the host of the first device can send the HCI_Read_Encryption_Key_Size command to the controller. The HCI_Read_Encryption_Key_Size command can be used to read the encryption key size for a given Connection_Handle.

[0284] After receiving the HCI_Read_Encryption_Key_Size command from the host, in step S2240, the controller of the first device may send an HCI_Command_Complete event to the host, including information about the key size. The HCI_Command_Complete event can be used to send the return status of each HCI command or to send other event parameters. For example, the HCI_Command_Complete event can be configured similarly to the HCI_Encryption_Change event and can include, for example, Connection_Handle, encryption enabled, and key size information.

[0285] In this example, the controller can configure link security using an encryption key with a length implemented as a default value. However, as mentioned above, there is a problem: the default key length is short, which is poor in terms of security.

[0286] In addition, there is no command that limits the minimum length of the encryption key that the host can configure for the controller, and the host must obtain the changed key size in the controller using a read command.

[0287] Figure 23 This is a diagram illustrating an additional example of an encryption setup method to which this disclosure applies.

[0288] In operation S2310, the host of the first device can send the HCI_Configure_Minimum_Key_Size command to the controller. The HCI_Configure_Minimum_Key_Size command is limited to the minimum length of the encryption key that the host sets for the controller.

[0289] In response to the HCI_Configure_Minimum_Key_Size command, in step S2320, the controller may send the HCI_Command_Complete event to the host.

[0290] The controller can send a success or error message to the host using the HCI_Command_Complete event. For example, the controller can have a range or candidate values ​​for supported key sizes, and can set a specific key size from among the supported key sizes as the default key size. For instance, success can be indicated when the default key size configured by the controller is equal to or greater than the minimum key size configured by the host, and the minimum key size configured by the host corresponds to a key size supported by the controller. An error can be indicated when the default key size configured by the controller is less than the minimum key size configured by the host, or when the minimum key size configured by the host does not correspond to a key size supported by the controller.

[0291] If the controller supports key sizes larger than the minimum key size configured by the host, then it is similar to Figure 22 As described in the text, in operation S2330, LMP_encryption_mode_req messages and LMP_encryption_key_size_req messages are exchanged between the controller of the first device and the controller of the second device, so that the encryption mode and encryption key size can be configured or changed.

[0292] and Figure 22 The examples are different, in Figure 23 In the example, the command for the host to read the key size from the controller and its response can be omitted. Instead, information indicating that the encryption change for a specific Connection_Handle has been completed (enabled) and information about the key size can be provided from the controller to the host via the HCI_Encryption_Change event in step S2340. That is, the HCI_Encryption_Change event can also include information indicating the key size set / changed in the controller.

[0293] In this example, an error message is sent to the host only if the key size configured as the default in the controller is smaller than the minimum key size configured by the host. In this case, since the host does not know which key sizes the controller supports, the following problem arises: if the minimum key size is configured again, the host cannot clearly determine what value to configure to prevent errors.

[0294] Furthermore, even if the host specifies a command (e.g., the HCI_Configure_Minimum_Key_Size command) and uses that command to configure the minimum key size for the controller, the following issue arises when there are multiple links / connections / services / profiles in a device: it is unclear whether the minimum key size is configured commonly for each link / connection / service / profile or configured individually for each link / connection / service / profile.

[0295] Figure 24 An exemplary device related to encryption configuration to which this disclosure applies is shown.

[0296] Assume that the first device can support various applications or services. For example, the first device can support sensor data services, medical services, audio services, etc. Service information from the first device can be delivered to the second device via advertising packets (e.g., mirroring, control, file transfer services, etc.). The second device can examine the service-related information delivered from the first device.

[0297] Figure 25 This is a diagram illustrating an example of an encryption key size configuration to which this disclosure applies.

[0298] As described in the example above, when the minimum key size configured by the host is less than the controller's default configuration value (that is, the key size value configured as the default value in the controller), the controller can send an error message to the host.

[0299] However, there is ambiguity in the error response actions of the host receiving error information from the controller. Specifically, in Figure 24 In this case, the controller only sends error messages to the host and does not provide the host with information about the extent to which the minimum key size configured by the host is smaller than the default key size in the controller. Therefore, the host wastes unnecessary time and resources as it repeatedly attempts to configure the minimum key size blindly. This ambiguity can be eliminated by having the controller notify the host of information about the key sizes that the controller can support, as well as error messages such as those shown in the following example.

[0300] In the following examples according to this disclosure, information about the encryption key size (e.g., key size information) may include one or more of the following: the key size or length itself; the minimum, maximum, range, or one or more candidate values ​​of the key size or length.

[0301] As a representative example, although it is described that the host can generate a minimum key size and / or provide the minimum key size to the controller via a first message (or command), the scope of this disclosure is not limited thereto, and the key size itself, the maximum key size, the range of key sizes, or one or more of one or more candidate values ​​can be generated and / or provided to the controller.

[0302] Although the controller is described as being able to generate information indicating the key size that the controller can support or is the default key size for the controller and / or provide that information to the host via a second message (or event), the scope of this disclosure is not limited thereto, and a minimum, maximum, range, or one or more candidate key sizes may be generated and / or provided to the host.

[0303] Although the configuration file / service is described as being able to generate a minimum key size and / or provide the minimum key size to the host via a third message, the scope of this disclosure is not limited thereto, and the key size itself, the maximum key size, the range of key sizes, or one or more of one or more candidate values ​​may be generated and / or provided to the host.

[0304] In various examples of this disclosure, key size information can be configured for a predefined unit. A predefined unit can be defined by one or more of a configuration file, service, link, connection, or device (or host).

[0305] As a more specific example, the controller can provide the host with information about the key sizes supported by the controller. The controller can also provide the host with information about the key sizes that are set as the default value in the controller. The controller may include information about the supported (or default-configured in the controller) key sizes in messages responding to commands from the host that configure the minimum value of the encryption key.

[0306] If the minimum key size is successfully configured via a command from the host, the controller can provide the host with information about the key sizes supported by the controller (or configured by default in the controller) in a response (or response event). If the minimum key size configured via a command from the host is greater than or equal to the controller's default configuration value (that is, the key size value supported by the controller or configured by default in the controller), the controller can provide the host with information about the key sizes supported by the controller (or configured by default in the controller).

[0307] If the minimum key size is configured incorrectly via a command from the host, the controller can provide the host with information about the key sizes supported by the controller (or configured by default in the controller) in a response (or response event). The controller can also provide information about the key sizes supported by the controller (or configured by default in the controller) when the minimum key size configured via a command from the host is less than the controller's default setting (i.e., the key size value supported by the controller or configured by default in the controller).

[0308] Therefore, when the host configures the minimum encryption key size for the controller based on information about the key size supported by the controller (or set by default in the controller) further included in the response message from the controller, which includes error information, the minimum encryption key size configuration can be performed again by adjusting / changing the minimum encryption key size to be configured for the controller.

[0309] As another example, when the minimum key size is configured incorrectly via a command from the host, the controller can send a first event to the host including an error message, and a second event including information about the key sizes that can be supported by the controller (or configured as the default value in the controller). When the minimum key size configured via a command from the host is less than the controller's default configuration value (that is, the key size value supported by the controller or configured as the default value in the controller), the controller can send a first event to the host including an error message, and a second event including information about the key sizes that can be supported by the controller (or configured as the default value in the controller).

[0310] Commands used by the host to configure a minimum encryption key size for the controller may also include information about the unit applying the minimum encryption key size. For example, the unit applying the minimum encryption key size configured by the host may consist of one or more of a link, connection, configuration file, service, or device (or host).

[0311] For example, a separate minimum key size can be configured for each link. A single minimum key size can be configured for multiple links. A single minimum key size can be configured for some of the links configured in the device (or host), and a shared minimum key size can be configured for the remaining links. A minimum key size can be configured for all links configured in the device (or host).

[0312] For example, you can configure a separate minimum key size for each configuration file. You can also configure a single minimum key size value shared by multiple configuration files. You can configure a single minimum key size value for some of the configuration files configured on the device (or host), and configure a shared minimum key size value for the remaining configuration files. You can also configure a single minimum key size value shared by all configuration files configured on the device (or host).

[0313] For example, a single minimum key size can be configured for each service. A single minimum key size value can be configured for multiple services. A single minimum key size value can be configured for some of the services set up in the device (or host), and a shared minimum key size value can be configured for the remaining services. A minimum key size can be configured for all services set up in the device (or host).

[0314] For example, the minimum value of a single or shared key size can be configured in a unit of link / connection and profile combination, a unit of link / connection and service combination, a unit of profile and service combination, or a unit of link, connection, profile and service combination.

[0315] In step S2510, a specific configuration file / service of the first device may send a Key_Size_Set message to the host. The Key_Size_Set message may include a configuration file identifier, service identifier, link / connection identifier (or link / connection handler), key size information, etc. This means that the Key_Size_Set message specifies one or more combinations of links / connections, configuration files, or services, and includes information about the minimum encryption key size applied to the specified unit.

[0316] In step S2520, the host may send the HCI_Configure_Minimum_Key_Size command to the controller based on information about the minimum encryption key size provided from the configuration file / service. The HCI_Configure_Minimum_Key_Size command may include a configuration file identifier, service identifier, link / connection identifier (or link / connection handler), key size information, etc. This means that the HCI_Configure_Minimum_Key_Size command specifies one or more combinations of links, connections, configuration files, or services, and includes information about the minimum encryption key size applied to the specified unit.

[0317] In step S2530, the controller can compare the minimum encryption key size configured by commands from the host with an encryption key size that can be supported by the controller (or configured as the default value in the controller).

[0318] As a result of the comparison, if the minimum encryption key size configured via host command is less than the encryption key size that can be supported by the controller (or configured by default in the controller), a response event including an error message (e.g., HCI_Command_Complete) can be sent to the host. Additionally, information about the encryption key size that can be supported by the controller (or configured as the default value in the controller) can also be included in the response event including the error message and sent to the host. Alternatively, after sending the first response event including the error message to the host, the controller can send a second response event to the host including information about the size of the supported encryption keys (or configured as the default value in the controller).

[0319] As a result of the comparison, if the minimum encryption key size set via the host command is equal to or greater than the encryption key size that can be supported by the controller (or is set to the default value in the controller), then a response event including a success message (e.g., HCI_Command_Complete) can be sent to the host. Additionally, information about the encryption key size that can be supported by the controller (or is configured as the default value in the controller) can also be included in the response event including the success message and sent to the host. Alternatively, after sending a first response event including the success message to the host, the controller can send a second response event including information about the supported encryption key sizes (or are configured as the default value in the controller) to the host.

[0320] Figure 26 This is an additional example diagram illustrating the encryption key size configuration to which this disclosure applies.

[0321] For the sake of brevity, inFigure 26 In the example, the pair will be omitted. Figure 25 The description of the same part.

[0322] exist Figure 26 In the example, in step S2610, management key size and link operations can be performed between the configuration file / service of the first device and the host based on the configuration file / service characteristics or features.

[0323] For example, information about the key size for each profile / service can be configured between the profile / service and the host. Table 9 shows an example of a key size table that indicates the mapping between the key size of each profile / service and the link / connection identifier (or link / connection handler).

[0324] Table 9

[0325]

[0326] In the examples in Table 9, for the sensing data profile / service, the minimum key size is configured to 5 octets, and the corresponding link / connection can be ACL#1. For the medical profile / service, the minimum key size is configured to 16 octets, and the corresponding link / connection can be ACL#2. For the audio profile / service, the minimum key size is configured to 8 octets, and the corresponding link / connection can be ISO#31 and SCO#34.

[0327] When determining the minimum encryption key size for a specific configuration file / service / link / connection between a configuration file / service and the host, a Key_Size_Set message containing this information can be delivered from the configuration file / service to the host. The Key_Size_Set message may include a configuration file identifier, service identifier, link / connection identifier (or link / connection handler), key size information, etc. This means that the Key_Size_Set message specifies one or more units of a link, connection, configuration file, or service, and includes information about the minimum encryption key size applied to the specified unit.

[0328] When the minimum encryption key size for a specific profile / service / link / connection is set via a command from the host, the controller can compare the minimum key size indicated for the corresponding profile / service / link / connection with the key size that can be supported by the controller (or set as the default value in the controller) and send a response event (e.g., an event containing success / error and / or key size information) to the host based on the comparison result.

[0329] Figure 27An example of the minimum encryption key size configuration for each service / profile to which this disclosure applies is shown.

[0330] Figure 27 (a) illustrates a scenario where multiple devices with different services / profiles are connected.

[0331] For example, the host and controller of a healthcare device (including cardiac monitoring functionality) can be configured with a minimum encryption key size of 16 octets for the healthcare service / profile (e.g., using...). Figure 25 or Figure 26 The example uses the HCI_Configure_Minimum_Key_Size command and HCI_Command_Complete event between the host and controller of the first device. Therefore, to exchange medical data between a healthcare device and a remote device (e.g., a smartphone), a secure connection can be established using an encryption key with a length of 16 octets or more (e.g., using...). Figure 22 or Figure 23 In the example, the LMP_encryption_mode_req and LMP_encryption_key_size_req are exchanged between the controller of the first device and the controller of the second device, and the LMP_accepted message is received in response to them.

[0332] The host and controller of the audio device can be configured with a minimum encryption key size of 8 octets for the medical service / profile (e.g., using as in...). Figure 25 or Figure 26 The example uses the HCI_Configure_Minimum_Key_Size command and HCI_Command_Complete event between the host and controller of the first device. Therefore, to send and receive audio data between an audio device and a remote device (e.g., a smartphone), a secure connection can be established using an encryption key with a length of 8 octets or more (e.g., using...). Figure 22 or Figure 23 In the example, the LMP_encryption_mode_req and LMP_encryption_key_size_req are exchanged between the controller of the first device and the controller of the second device, and the LMP_accepted message is received in response to them.

[0333] The host and controller of the lighting equipment can be configured with a minimum encryption key size of 5 octets for the lighting service / profile (e.g., using...). Figure 25 or Figure 26The example uses the HCI_Configure_Minimum_Key_Size command and HCI_Command_Complete event between the host and controller of the first device. Therefore, to send and receive audio data between a lighting device and a remote device (e.g., a smartphone), a secure connection can be established using an encryption key with a length of 5 octets or more (e.g., using...). Figure 22 or Figure 23 The example shows the LMP_encryption_mode_req and LMP_encryption_key_size_req communication between the controller of the first device and the controller of the second device, as well as the corresponding LMP_accepted message.

[0334] Figure 27 (b) illustrates a scenario where a single device with multiple services / profiles is connected.

[0335] Wearable devices may include multiple services / profiles. For example, multiple services / profiles may include sensor data services, medical services, and audio services.

[0336] The wearable device's host and controller can be configured with minimum encryption key sizes of 5, 16, and 8 octets respectively for multiple sense data, medical, and audio services / profiles (e.g., using...). Figure 25 or Figure 26 The example shows the HCI_Configure_Minimum_Key_Size command and HCI_Command_Complete event between the host and controller of the first device. Therefore, to exchange sensing, medical, and audio data between a wearable device and a remote device (e.g., a smartphone), a secure connection can be established using an encryption key with a length of 5, 16, or 8 octets or more (e.g., using...). Figure 22 or Figure 23 In the example, the LMP_encryption_mode_req and LMP_encryption_key_size_req are exchanged between the controller of the first device and the controller of the second device, and the LMP_accepted message is received in response to them.

[0337] In the example above, when predetermined conditions are met, the host can perform the operation of configuring the encryption key size information for the controller.

[0338] The predefined conditions can be as follows: The host checks the encryption key size information based on the identifier (e.g., UUID) of the application / configuration file / service / link / connection, which is mapped to the corresponding application / configuration file / service / link / connection. The mapping relationship between the identifier of the application / configuration file / service / link / connection and the key size information can be pre-configured. Therefore, when starting the use of a specific application / configuration file / service / link / connection, the corresponding key size information can be configured.

[0339] The predefined conditions can be as follows: requesting user confirmation via the user interface regarding whether to continue using the encryption key size configuration information for a specific application / configuration file / service / link / connection (or whether to start a specific application / configuration file / service / link / connection), and performing user confirmation via the user interface.

[0340] In the examples of this disclosure described above, a method for configuring a key size supported by a controller is primarily described by defining commands and events related to key size configuration and exchanging commands and events related to key size configuration between the configuration file / service layer, host layer, and controller layer of a first device, particularly between the host and the controller. However, the scope of this disclosure is not limited thereto, and key size configuration can also be performed in a second device.

[0341] For example, key size configuration for predetermined units (e.g., a combination of one or more of configuration files, services, links, and connections) can be performed between the host and controller on the first device and between the host and controller on the second device.

[0342] Additionally, in the examples of this disclosure, the event in which the controller of each device sends information about the key size it can support to the host may also include information about a predefined unit (e.g., a combination of one or more of a configuration file, service, link, and connection) or information about whether encryption is activated.

[0343] In the above example, the exchange and configuration of information regarding the encryption key size between the host and controller may be related to the configuration of link-level encryption. That is, when link-level encryption is applied, information regarding the encryption key size can be exchanged and set. Therefore, if information regarding the encryption key size is applied jointly or independently according to predetermined units (e.g., a combination of one or more of profiles, services, links, and connections), then link-level encryption settings are also predetermined according to the units, and these settings can be included in the information regarding the encryption key size applied jointly or independently. For example, when link-level encryption is applied to a specific link, information regarding the encryption key size for that specific link can be exchanged and configured. As another example, when link-level encryption is applied to all links associated with a specific profile / service, information regarding the encryption key size can be exchanged and configured for all links associated with that specific profile / service. For example, the predetermined units (profile / service / link / connection) may correspond to BR / EDR type or LE type. For example, information regarding link-level encryption configuration and / or encryption key size may be configured separately from BR / EDR type and LE type, or it may be configured jointly between BR / EDR type and LE type.

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

[0345] The first device 2800 may include a processor 2810, an antenna unit 2820, a transceiver 2830, and a memory 2840.

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

[0347] Antenna unit 2820 may include one or more physical antennas. Transceiver 2830 may include an RF (radio frequency) transmitter and an RF receiver. Memory 2840 may store information processed by processor 2810 and software, operating system, and applications related to the operation of first device 2800, and may include components such as buffers.

[0348] The processor 2810 of the first device 2800 can be configured to implement the operation of the first device (or audio source device or encoding device) in the embodiments described in this disclosure.

[0349] For example, the host processor 2811 of the processor 2810 of the first device 2800 can send a first message (command) including information about the minimum value of the encryption key size to the controller processor 2815.

[0350] The controller processor 2815 may send a second message (event) indicating a change in encryption to the host processor 2811. The second message may include information about the size of the first encryption key.

[0351] The second device 2850 may include a processor 2860, an antenna unit 2870, a transceiver 2880, and a memory 2890.

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

[0353] Antenna unit 2870 may include one or more physical antennas. Transceiver 2880 may include an RF transmitter and an RF receiver. Memory 2890 may store information processed by processor 2860 and software, operating system, and applications related to the operation of second device 2850, and may include components such as buffers.

[0354] The processor 2860 of the second device 2850 can be configured to perform the operation of the second device (or audio sink, or server device) in the embodiments described in this disclosure.

[0355] For example, the host processor 2861 of the processor 2860 of the second device 2850 can send a first message (command) including information about the minimum value of the encryption key size to the controller processor 2865.

[0356] The controller processor 2865 may send a second message (event) indicating a change in encryption to the host processor 2861. The second message may include information about the size of the first encryption key.

[0357] In the operation of the first device 2800 and the second device 2850, the descriptions of the source device / encoding device and the sink device / decoding device can be applied in the same way in the examples of this disclosure, and therefore the same descriptions will be omitted.

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

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

[0360] [Industrial Applicability]

[0361] 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 performed by a first device in a wireless communication system, the method comprising: The first controller of the first device receives an HCI setting minimum encryption key size command message from the first host of the first device via the first host controller interface HCI of the first device. The HCI setting minimum encryption key size command message includes information about the minimum value of the encryption key size. as well as The first controller sends an HCI encryption change event message indicating an encryption change to the first host via the first HCI. The HCI encryption change event message includes information about an encryption key size that is greater than or equal to the minimum value, which is used to adjust or change the key size between the first controller and the first host of the first device. The HCI encryption change event message further includes information about the connection identifier to notify the first host when the encryption of the existing connection corresponding to the connection identifier between the first and second devices changes. If the first controller does not support the minimum value included in the command message for setting the minimum encryption key size in the HCI, the first controller returns an error to the first host.

2. The method according to claim 1, wherein, The HCI encryption change event message also includes information about at least one of the following: configuration file identifier, service identifier, link identifier, or device identifier. The encryption key size is applied to at least one of the configuration file identifier, service identifier, link identifier, or device identifier.

3. The method according to claim 1, wherein, The HCI encryption change event message also includes information about whether link-level encryption is enabled or disabled.

4. The method according to claim 3, wherein, When the link-level encryption is enabled, the encryption method is E0 or Advanced Encryption Standard-Cipher Block Link-Message Authentication Code (AES-CCM).

5. The method according to claim 1, wherein, In response to the HCI setting minimum encryption key size command message, an HCI command completion event message indicating whether the minimum value configuration has been completed is sent from the first controller to the first host.

6. The method according to claim 1, further comprising: A second controller of a second device connected to the first device sends another HCI encryption change event message indicating an encryption change to a second host of the second device via a second HCI of the second device. The other HCI encryption change event message includes information about the encryption key size.

7. The method according to claim 1, wherein, At least one of the encryption key size configurations or encryption variations is applied jointly or independently to the Basic Rate (BR) / Enhanced Data Rate (EDR) type and the Low Energy (LE) type.

8. A first device in a wireless communication system, the first device comprising: A transceiver, the transceiver being used to perform signal transmission and reception with another device; as well as A processor, the processor being used to control the transceiver and the first device; The processor is configured as follows: The first controller of the first device receives an HCI setting minimum encryption key size command message from the first host of the first device via the first host controller interface (HCI) of the first device. The HCI setting minimum encryption key size command message includes information about the minimum value of the encryption key size; and The first controller sends an HCI encryption change event message indicating an encryption change to the first host via the first HCI. The HCI encryption change event message includes information about an encryption key size that is greater than or equal to the minimum value, which is used to adjust or change the key size between the first controller and the first host of the first device. The HCI encryption change event message further includes information about the connection identifier to notify the first host when the encryption of the existing connection corresponding to the connection identifier between the first and second devices changes. If the first controller does not support the minimum value included in the command message for setting the minimum encryption key size in the HCI, the first controller returns an error to the first host.

Images