Method, apparatus, and computer program for setting encryption key in wireless communication system, and recording medium for same

Abstract

The present disclosure relates to a method for setting an encryption key in a wireless communication system, an apparatus, a computer program, and a recording medium thereof. A method for setting an encryption key size in a wireless communication system according to one embodiment of the present disclosure may include: a first controller on the side of a first device receiving a first message containing information about a minimum value of a first encryption key size from a first host on the side of the first device; and a step in which the first controller transmits a second message indicating an encryption change to the first host. The second message may include information about the first encryption key size.

Description

Technology Field

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

[0002] Bluetooth is a short-range wireless communication standard that includes BR (Basic Rate) / EDR (Enhanced Data Rate) technology and LE (Low Energy) technology. BR / EDR, also known as Bluetooth Classic, includes BR technology applied since Bluetooth 1.0 and EDR technology applied since Bluetooth 2.0. Bluetooth LE (BLE), applied since Bluetooth 4.0, is a technology that supports the transmission and reception of relatively large amounts of data with low power consumption.

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

[0004] With the recent increase in the adoption of wireless devices, there is a growing demand for audio data transmission and reception across various topologies, such as many-to-many or M-to-N connections. For example, streaming services requiring 5.1 channel environments are emerging, and discussions are underway to support 5.1 channel environments using multiple portable Bluetooth speakers, moving beyond the limitations of conventional dedicated 5.1 channel wired speakers. However, conventional Bluetooth audio technology was developed primarily considering use cases involving one-to-one connections between two devices; consequently, it is not suitable for supporting audio data transmission and reception between multiple devices and suffers from significant latency issues. Additionally, as the number of Bluetooth audio devices increases, problems such as increased power consumption for searching for nearby devices arise.

[0005] The encryption key used in conventional Bluetooth standards supports sizes ranging from 8 to 128 bits. However, conventional encryption key sizes have security vulnerabilities due to their short length, so modifications are required. The problem to be solved

[0006] The technical problem of the present disclosure is to provide a method and apparatus for controlling encryption keys between a host and a controller on the device side in a wireless communication system.

[0007] An additional technical objective of the present disclosure is to provide a method and apparatus for setting an encryption key size between a host and a controller on the device side in a wireless communication system.

[0008] An additional technical objective of the present disclosure is to provide a method and apparatus in which a controller on the device side of a wireless communication system provides information about the encryption key size to a host.

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

[0010] A method for setting an encryption key size in a wireless communication system according to one aspect of the present disclosure may include: a first controller on the side of a first device receiving a first message containing information about a minimum value of a first encryption key size from a first host on the side of the first device; and a step in which the first controller transmits a second message indicating an encryption change to the first host. The second message may include information about the first encryption key size.

[0011] A wireless communication system according to a further aspect of the present disclosure may include: a transceiver for performing signal transmission and reception with another device, wherein the transceiver is in a first device for setting an encryption key size; and a processor for controlling the transceiver and the device. The processor may be configured such that a first controller on the side of the first device receives a first message containing information about a minimum value of a first encryption key size from a first host on the side of the first device; and the first controller transmits a second message indicating an encryption change to the first host. The second message may include information about the first encryption key size.

[0012] The features briefly summarized above regarding the present disclosure are merely exemplary aspects of the detailed description of the present disclosure that follows and do not limit the scope of the present disclosure. Effects of the invention

[0013] According to the present disclosure, the technical problem of the present disclosure in a wireless communication system can be addressed by providing a method and device for controlling encryption keys between a host and a controller on the device side in a wireless communication system.

[0014] According to the present disclosure, a method and apparatus for setting an encryption key size between a host and a controller on the device side in a wireless communication system may be provided.

[0015] According to the present disclosure, a method and apparatus may be provided in which a controller on the device side of a wireless communication system provides information about the encryption key size to a host.

[0016] The effects obtainable from the present disclosure are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art to which the present disclosure pertains from the description below. Brief explanation of the drawing

[0017] FIG. 1 is a drawing illustrating, exemplarily, a conventional audio connection type and an audio connection type to which the present disclosure is applicable. FIG. 2 is a diagram illustrating, by way of example, a conventional audio-related protocol stack and an audio-related protocol stack to which the present disclosure is applicable. FIG. 3 shows examples of 5.1 channel surround system hardware to which the present disclosure is applicable. FIG. 4 is a diagram illustrating an audio data encoding / decoding process to which the present disclosure is applicable. FIG. 5 is a diagram showing an example of channel allocation for two devices to which the present disclosure is applicable. FIG. 6 is a diagram illustrating the synchronization delay of two streams to which the present disclosure is applicable. FIG. 7 is a diagram illustrating a broadcast operation for a plurality of devices to which the present disclosure is applicable. FIGS. 8 and 9 are drawings for explaining the operation of ICL type and INCL type to which the present disclosure is applicable. FIG. 10 is a diagram showing a broadcast audio stream state machine to which the present disclosure is applicable. FIG. 11 is a diagram illustrating an audio setup procedure to which the present disclosure is applicable. FIG. 12 is a diagram showing a link hierarchy state machine to which the present disclosure is applicable. FIG. 13 is a drawing showing an example of an audio topology to which the present disclosure is applicable. FIGS. 14 to 16 are drawings illustrating the process of message exchange between a server and a client to which the present disclosure can be applied. FIG. 17 is a diagram showing a state machine for a call service to which the present disclosure is applicable. FIG. 18 is a diagram showing a layered packet format to which the present disclosure is applicable. FIG. 19 is a drawing showing examples of data unit formats to which the present disclosure is applicable. FIG. 20 is a drawing showing examples of advertising unit formats to which the present disclosure is applicable. FIG. 21 shows an exemplary HCI packet format to which the present disclosure is applicable. FIG. 22 is a drawing illustrating an example of an encryption setting method to which the present disclosure is applicable. FIG. 23 is a drawing showing an additional example of an encryption setting method to which the present disclosure is applicable. FIG. 24 illustrates an exemplary device related to an encryption setting to which the present disclosure is applicable. FIG. 25 is a drawing illustrating an example of an encryption key size setting to which the present disclosure is applicable. FIG. 26 is a diagram showing additional examples of encryption key size settings to which the present disclosure is applicable. FIG. 27 shows an example of setting the minimum encryption key size per service / profile to which the present disclosure is applicable. FIG. 28 is a drawing showing the configuration of a first device and a second device to which the present disclosure can be applied. Specific details for implementing the invention

[0018] Hereinafter, embodiments of the present disclosure are described in detail with reference to the attached drawings so that those skilled in the art can easily implement them. However, the present disclosure may be embodied in various different forms and is not limited to the embodiments described herein.

[0019] In describing the embodiments of the present disclosure, if it is determined that a detailed description of known configurations or functions may obscure the essence of the present disclosure, such detailed description is omitted. Furthermore, parts of the drawings unrelated to the description of the present disclosure have been omitted, and similar parts are denoted by similar reference numerals.

[0020] In the present disclosure, when a component is described as being “connected,” “combined,” or “joined” with another component, this may include not only a direct connection but also an indirect connection in which another component exists in between. Furthermore, in the present disclosure, the terms “comprising” or “having” specify the presence of the mentioned features, steps, actions, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, actions, elements, components, and / or groups thereof.

[0021] In the present disclosure, terms such as "first," "second," etc. are used solely for the purpose of distinguishing one component from another and are not used to limit the components, nor do they limit the order or importance of the components unless specifically stated otherwise. Accordingly, within the scope of the present disclosure, a first component in one embodiment may be referred to as a second component in another embodiment, and likewise, a second component in one embodiment may be referred to as a first component in another embodiment.

[0022] In this disclosure, distinct components are intended to clearly describe their respective features and do not imply that the components are separate. That is, multiple components may be integrated to form a single hardware or software unit, or a single component may be distributed to form multiple hardware or software units. Accordingly, such integrated or distributed embodiments are included within the scope of this disclosure, unless otherwise noted.

[0023] The various embodiments of the present disclosure are intended to describe representative aspects of the present disclosure, rather than to list all possible combinations of components. 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 the present disclosure are not necessarily essential components, and some may be optional components. Accordingly, embodiments consisting of a subset of the components described in one embodiment are also included within the scope of the present disclosure. Furthermore, embodiments including other components in addition to the components described in the various embodiments are also included within the scope of the present disclosure.

[0024] The exemplary methods of the present disclosure are described as a series of operations for clarity of description, but this is not intended to limit the order in which the steps are performed, and if necessary, each step may be performed simultaneously or in a different order. Additionally, to implement the method according to the present disclosure, other steps may be included in addition to the steps exemplified, the remaining steps may be included excluding some steps, or additional steps may be included excluding some steps.

[0025] The terms used in this disclosure are for the description of specific embodiments and are not intended to limit the claims. As used in the description of embodiments and in the appended claims, the singular form is intended to include the plural form unless the context clearly indicates otherwise. Additionally, the term "and / or" as used in this disclosure may refer to one of the related enumerated items, or refers to and includes any and all possible combinations of two or more of them.

[0026] The definitions of terms used in this disclosure are as follows.

[0027] An audio sink is an object that receives audio data from an audio source.

[0028] An audio source is an object that transmits audio data to an audio sink.

[0029] An audio channel is a single flow of encoded or unencoded audio data.

[0030] An audio stream is a unidirectional logical communication channel that carries audio data flowing from an audio source to an audio sink. Audio data can flow over an audio stream session (ASS). An audio stream can carry audio data for one or more audio channels.

[0031] An audio group may contain one or more synchronized audio streams.

[0032] The content type indicates the classification of the content in the audio group. The classification may include whether the audio was initiated by a user. Examples of content types may include Uncategorized Audio, Ringtone, System Sound, Satnav, Call Audio, Media, etc.

[0033] Metadata is variable-length data that provides and describes the context of audio data. Metadata can be defined for higher layers.

[0034] An audio stream session (ASS) refers to the unidirectional or bidirectional transmission / exchange process of an audio stream. An endpoint of an ASS corresponds to the audio input and / or audio output of an audio stream session and can correspond to a single device or a group of devices. An endpoint of an ASS exists on a server and can be configured by the server or by a client. The server can store, modify, and manage the state of the ASS.

[0035] QoS (Quality of Service) refers to the quality of service for audio streams and can meet the requirements for specific services.

[0036] An audio location refers to the intended logical spatial rendering position for an audio channel within the spatial arrangement of the device rendering the audio. For example, the left and right positions of a headset may correspond to audio locations. An audio location may be assigned to an audio channel.

[0037] CBIS (Connection Based Isochronous Stream) is a term defined at the core layer and is a concept corresponding to audio streams in ASS services. Unidirectional CBIS has one audio stream, while bidirectional CBIS can have two audio streams.

[0038] CBISS (Connection Based Isochronous Stream Set) is a term defined at the core layer and is a concept corresponding to an audio group in an ASS service.

[0039] An audio scene application (ASA) refers to a group of audio that performs a specific type of content.

[0040] ASC (Audio Steam Capability) is a set of parameters required to configure audio session capability.

[0041] Audio advertisements are intended to discover the availability of ASA participation. Audio general advertisements are audio notifications that are not targeted at any audience, while audio directed advertisements are audio notifications directed at a specific audience.

[0042] Isochronous data refers to data that is limited by time. For example, isochronous data may be time-dependent audio, such as television audio that needs to be synchronized with video images, or audio that needs to be played back in synchronization across multiple devices constituting a multi-channel system.

[0043] An isochronous channel refers to a logical transmission unit used to transmit isochronous data from a transmitting device to one or more receiving devices.

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

[0045] FIG. 1 is a drawing illustrating, exemplarily, a conventional audio connection type and an audio connection type to which the present disclosure is applicable.

[0046] FIG. 1(a) shows an example of a BR / EDR audio connection type. In the case of BR / EDR, one-to-one connections are supported. One device (e.g., a smartphone) functions as a central device and can be connected one-to-one with each of multiple devices. That is, multiple one-to-one connections may exist. Accordingly, services such as phone calls through a headset or music playback through speakers can be supported. In this type of connection, the center of the service is the audio source, and audio sinks such as headsets, speakers, and AVN (Audio Video Navigation) can operate as peripheral devices of the audio source.

[0047] Figure 1(b) illustrates an example of a BLE audio connection type. BLE can support many-to-many connections. In this case, multiple central devices such as TVs, smartphones, and gateways may exist, and complex M-to-N connections may be configured. Accordingly, services such as phone calls and music playback via a headset can be supported, and broadcast audio services such as alarms, doorbells, and advertising voices can be supported. The center of the service in this connection type is an audio sink, and audio services can be used by moving multiple audio sources.

[0048] FIG. 2 is a diagram illustrating, by way of example, a conventional audio-related protocol stack and an audio-related protocol stack to which the present disclosure is applicable.

[0049] Figure 2(a) shows an example of a BR / EDR audio-related protocol stack. The L2CAP (Logical Link Control & Adaptation Protocol) layer performs the function of mediation and coordination between the upper and lower layers. The upper layer may include protocols such as RFCOMM (Radio Frequency Communication), AVDTP (Audio / Video Distribution Transport Protocol), and AVCTP (Audio / Video Control Transport Protocol), as well as profiles such as HFP (Hands Free Profile), A2DP (Advanced Audio Distribution Profile), and AVRCP (Audio / Video Remote Control Profile). The lower layer may include MAC / PHY layers. The MAC (Medium Access Control) layer may include a Link Manager and a Link Controller, and the PHY (Physical) layer may include BR / EDR radio. Additionally, SCO (Synchronous Connection Oriented) / eSCO (extended SCO) may provide a synchronous data communication path for voice. As such, in BR / EDR, protocol stacks 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, while 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 is called the Host Controller Interface (HCI).

[0050] Figure 2(b) shows an example of a BLE audio-related protocol stack. Unlike BR / EDR, where protocols are configured per profile, a common protocol stack for various profiles can be designed in BLE. This common protocol stack can be referred to as middleware. For example, common protocols can be configured in the form of middleware for various profiles such as hearing aids, high quality audio / music, voice recognition, and call / media. For example, the middleware may include protocols such as device discovery, stream control (or stream management), codec, and legacy management. Additionally, the core layer may include a Link Layer (LL) and LE Radio (i.e., the PHY layer), and the LL may include multicast-supported isochronous channel-related functions defined since Bluetooth 5.

[0051] In addition, profiles and middleware are referred to as the host layer, the core layer as the controller layer, and HCI can be defined between the host and the controller.

[0052] In addition to the host profile and protocols exemplified in FIG. 2(b), the 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.

[0053] Information transmitted from the host to the controller can be referred to as an HCI command packet. Information transmitted from the controller to the host can be referred to as an HCI event packet. Additionally, HCI asynchronous data packets or HCI synchronous data packets may be exchanged between the host and the controller.

[0054] In addition, in addition to the middleware profile and services exemplified in FIG. 2(b), the middleware may include various profiles and / or services such as the following:

[0055] Audio Session Capability Service (ASCS): The Audio Session Capability Service (ASCS) is a service that supports announcing or discovering capabilities related to an audio session;

[0056] Audio Stream Session Service (ASSS): An Audio Stream Session Service (ASSS) is a service that supports discovery, setup, establishment, control, and management related to audio sessions;

[0057] Audio Input Management Service (AIMS): A service for managing audio input volume, etc.;

[0058] Audio Routing Service (ARS): A service for selecting the locations of audio inputs and outputs;

[0059] Audio Middleware Profile (AMP): A basic profile for how a device distributes audio;

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

[0061] Audio General Middleware Profile (AGMP): A basic profile that enables content and / or stream control;

[0062] Group Identification Service (GIS): A service for the discovery of devices belonging to a group. The Group Identification Service (GIS) or Group Identification Profile (GIP) can enable devices to be discovered as part of a group. A group is defined as a group of devices that operate together to support a specific scenario, and these devices may be referred to as Group Members. For example, a group of devices that respond together to control commands may fall under this category, such as a pair of hearing aids, a pair of earbuds, or a set of speakers receiving multi-channel (e.g., 5.1CH) audio;

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

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

[0065] Microphone Management Profile: A profile for microphone status management;

[0066] Microphone Management Service: A service that supports an interface and status for microphone status management;

[0067] Quick Service Discovery Service (QSDS): A service that supports quick discovery for services such as audio player management and call management;

[0068] Call Bearer Service: A service that supports the management of call interfaces and call statuses for bearers on a device;

[0069] Volume Management Profile: A profile that supports audio volume management for the device;

[0070] Volume Management Service: A service that supports the device's audio volume interface and status;

[0071] Volume Offset Management Service: A service for managing the volume of audio output.

[0072] FIG. 3 shows examples of 5.1 channel surround system hardware to which the present disclosure is applicable.

[0073] In FIG. 3, the LE audio source device can perform the function of an initiator, and the LE audio sink device can perform the function of an acceptor. An initiator refers to a device that initiates an audio session, and an acceptor refers to a device that accepts the initiation of an audio session. Here, the source is not always the initiator and the sink is not always the acceptor; the source may become the acceptor or the sink may become the initiator.

[0074] For example, the audio source may be a TV device and the audio sink may be a speaker device. The audio source can transmit 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, namely FL (Front Left), FR (Front Right), RL (Rear Left), RR (Rear Right), C (Center), and W (Woofer), and output it through the speakers.

[0075] An audio encoder or decoder can support various audio formats. For example, audio formats may include BLEAC (Bluetooth Low Energy Audio Codec), Dolby 5.1CH, DTS (Digital Surround Sound), etc., and the characteristics of each format are as follows. BLEAC is a mono codec, and its 96kbps transmission rate can provide quality equivalent to the 256kbps transmission rate of SBC (Sub-Band Codec) and the 200kbps transmission rate of MP3. Dolby 5.1CH supports a 48 kHz sampling rate, supports 1 to 5.1 (or 1 to 6) channels, and can support a transmission rate of up to 448 kbps. DTS supports a sampling rate of 48 kHz or 96 kHz, supports 2 to 6.1 channels, and can support a transmission rate of 768 kbps half rate and 1,536 kbps full rate.

[0076] FIG. 4 is a diagram illustrating an audio data encoding / decoding process to which the present disclosure is applicable.

[0077] Referring to FIG. 4(a), a stream in DTS format or a stream in Dolby 5.1CH format can be input to a DTS decoder or a Dolby 5.1CH decoder at the transmitter (Tx) and output as an audio signal in PCM (Pulse-Code Modulation) format. The PCM signal can be input to a BLEAC encoder and output as an audio signal in BLEAC format. Optional vendor-specific information may be added here. The BLEAC signal can be transmitted to the BLE interface of the receiver (Rx) via the BLE interface. At the receiver, the BLEAC signal can be processed through a BLEAC decoder and converted into a signal that can be output through a speaker.

[0078] Here, multiple streams may be transmitted from a transmitting end to multiple receiving ends. For example, each of the multiple streams may contain an audio signal corresponding to one channel of 5.1CH. Although the timing of reception at the multiple receiving ends may differ, these multiple streams have isochronous characteristics in that playback or rendering is required at the same time, and such streams can be referred to as CBIS (Connection Based Isochronous Stream). That is, six CBISs corresponding to 5.1CH may be transmitted from the transmitting end to the receiving end, and a set of these six CBISs can be referred to as a CBISS (Connection Based Isochronous Stream Set).

[0079] FIGS. 4(b) and FIG. 4(c) conceptually illustrate audio streaming through multiple streams. One or more audio streams may correspond to CBIS, and audio groups may correspond to CBISS. For example, one audio stream may correspond to one CBIS, or two or more audio streams may correspond to one CBIS. Multiple CBIS may be included in one audio group or CBISS.

[0080] FIG. 5 is a diagram showing an example of channel allocation for two devices to which the present disclosure is applicable.

[0081] The receiving end may begin receiving the stream according to timing information provided by the transmitting end. For example, the timing information may indicate a time point after a predetermined offset from the time when a data unit containing the timing information is transmitted. The receiving end may receive audio data corresponding to one or more channels included in the stream. For example, multiple channels included in a stream may each be assigned to multiple receiving ends. Multiple channels (or multiple audio data) included in a stream may be transmitted using a time division multiplexing (TDM) method. For example, audio data of the first channel may be transmitted at a first timing, and audio data of the second channel may be transmitted at a second timing.

[0082] The broadcast receiver can detect the currently available broadcast audio stream, stream offset value, stream interval value, etc. by using information included in data units periodically advertised from the transmitter.

[0083] In the case of an Isochronous Non-Connection Link (INCL), which is a connectionless isochronous link, an isochronous channel can be transmitted and received without a connection between the source device and the sink device (e.g., via broadcast). From information such as a Broadcast Synch Group (BSG) included in the Protocol Data Unit (PDU) advertised by the transmitter, the receiver can identify the INCL stream offset or BSG offset and determine the anchor point timing. The transmission of the INCL stream can be initiated from the anchor point. The timing difference between two consecutive anchor points can be defined as an interval (e.g., the INCL CH1 interval or ISO interval in FIG. 5). One or more sub-events may be included within the stream transmission event.

[0084] In the example of FIG. 5, a single audio stream may contain audio data for two channels. The first channel (CH1) may be assigned to the first device (Device #1), and the second channel (CH2) may be assigned to the second device (Device #2). CH1 included in the INCL stream may be transmitted to Device #1 at one or more timings after the anchor point, and then CH2 may be transmitted to Device #2 at one or more timings. Additionally, the INCL stream events may include events for CH1 and events for CH2. The events for CH1 may include two sub-events. The events for CH2 may include two sub-events. The timing difference between sub-events may be defined as the sub-event interval.

[0085] Isochronous audio data may have a limited lifetime. That is, the audio data may be invalidated after a predetermined time has expired. For example, a predetermined timeout value may be defined in an ICL channel, and isochronous audio data transmitted to multiple devices may be discarded after the predetermined timeout value has expired. For example, the timeout may be expressed as the number of sub-events.

[0086] FIG. 6 is a diagram illustrating the synchronization delay of two streams to which the present disclosure is applicable.

[0087] It is assumed that a single audio group contains multiple streams, and these multiple streams have isochronism, requiring simultaneous playback. The multiple streams may be transmitted from a single device or from different devices. Additionally, the multiple streams may be received from a single device or from different devices.

[0088] Since Bluetooth communication does not support the simultaneous transmission of multiple streams, multiple streams may be transmitted in a TDM manner on different time resources (or timings) according to a predetermined order. In this case, a difference in the transmission timing of multiple streams may occur, and consequently, a difference in the reception timing of multiple streams may also occur. Furthermore, since multiple streams are required to be played simultaneously, the stream received first cannot be played first and may only be played after waiting for the last stream to be received. In other words, a synchronization delay may occur until the timing at which all streams are fully received.

[0089] In the example of FIG. 6, the first stream (CBIS#1) and the second stream (CBIS#2) are required to be played simultaneously and may be included in a single CBISS. The CBISS anchor point is the same as the anchor point of CBIS#1, and subsequent CBIS#1 audio data may be transmitted at a point in time after the CBIS#1 interval (e.g., T1) after the CBIS#1 audio data is transmitted. Next, at the anchor point of CBIS#2, subsequent CBIS#2 audio data may be transmitted at a point in time after the CBIS#2 interval (e.g., T2) after the CBIS#2 audio data is transmitted. All streams included in a single CBISS may be played simultaneously after being received. That is, the audio data of CBIS#1 and CBIS#2 may be processed and played at the time when the reception of CBIS#2, which is transmitted relatively later, is completed.

[0090] Here, the synchronization delay of CBISS can be defined as the time interval until the time of completion of reception (T2) of CBIS#2, which is received relatively late in CBISS. For example, the later time between the time of completion of reception of CBIS#1 (T1) and the time of completion of reception of CBIS#2 (T2) can be determined as the synchronization delay of CBISS. That is, among the synchronization delays of multiple streams, the later time of completion of reception can be determined as the synchronization delay of CBISS. Specifically, if CBIS#1 and CBIS#2 are grouped into the same CBISS, the stream CBIS#1, which is received first, can be played back after waiting until the information of the stream CBIS#2, which is received later, is transmitted.

[0091] The transmitter (Tx) can inform the receiver (Rx) in advance of an estimated delay value calculated by considering the number of CBIS, CBIS events, sub-events, intervals, etc. For example, the transmitter can inform the receiver of the estimated delay value when establishing the channel.

[0092] In the case of an Isochronous Connection Link (ICL), since the transmitter and receiver are connected, the receiver can inform the transmitter of the actual delay value that occurred.

[0093] In the case of INCL, since the transmitting end and the receiving end are not connected, the receiving end cannot inform the transmitting end of the actual delay value. Even if the receiving end could inform the transmitting end of the delay value, the transmitting end cannot control the playback time of a specific device in order to synchronize multiple devices.

[0094] For example, even in the case of INCL, if multiple CBIS (e.g., 6 CBIS corresponding to 6 channels of 5.1CH) are included in a single CBIS, the transmitter may receive feedback from the receiver to adjust the synchronization. Through the feedback, the receiver can inform the transmitter of its delay information.

[0095] FIG. 7 is a diagram illustrating a broadcast operation for a plurality of devices to which the present disclosure is applicable.

[0096] An audio source device can calculate a synchronization delay value for the simultaneous playback of isochronous streams and transmit it to multiple audio sink devices. Each sink device can determine playback timing based on the delay value provided by the source device. In other words, since the source device cannot accurately know the time required for the sink devices to receive and process audio data, it can provide the delay value as basic information for the sink devices to determine playback timing. The sink devices can determine playback timing and play audio data according to their own device characteristics.

[0097] For example, in an isochronous broadcast operation, a source device (e.g., a TV) can calculate transport delay, rendering delay, etc., and transmit them to a sink device (e.g., a speaker). The sink device can adjust the playback or rendering timing of audio data by reflecting the received delay values. Since device characteristics vary by manufacturer, the actual playback timing can be determined by the sink device.

[0098] If the sink device is capable of transmitting information to the source device, the sink device can calculate a delay value and transmit it to the source device. Accordingly, the source device can determine the transmission timing based on the delay value provided by the sink device.

[0099] For example, a feedback channel can be formed to allow a sink device (e.g., a speaker) to transmit information to a source device (e.g., a TV). In this case, unicast operation based on an isochronous connection can be performed. The sink device can calculate a rendering delay value and transmit it to the source device through the feedback channel. Accordingly, the source device can adjust the transmission time of audio data by reflecting the delay value provided by the sink device.

[0100] Referring to FIG. 7, isochronous stream operation is illustrated exemplarily when the transmitting end is a TV and the two receiving ends are a first speaker (Speaker #1) and a second speaker (Speaker #2). The first speaker may be assigned a first stream / channel (e.g., the RR channel in 5.1CH), and the second speaker may be assigned a second stream / channel (e.g., the RL channel in 5.1CH).

[0101] The first and second speakers can each transmit an audio general advertisement or an audio directed advertisement. The TV and one or more of the first speaker or the second speaker may or may not be connected to each other.

[0102] If one or more of the TV and speakers are connected, the speakers can calculate the rendering delay value and report it to the TV. If the TV and speakers are not connected, the TV can calculate the transmission delay, rendering delay value, etc., and transmit it to the speakers.

[0103] TVs perform synchronization by considering audio content characteristics, audio / video sync (A / V synch), and codec characteristics, and can forcibly apply delays to specific audio streams. For example, since audio codec encoding / decoding delays vary—such as 40ms for BLEAC, 200ms for SBC, and 100ms for APT-X—the delay value can be determined based on codec characteristics. Furthermore, as A / V content characteristics differ depending on whether the content is a game, movie, or animation, the delay value can be determined by taking these factors into account. Additionally, the delay value can be determined by considering the difference between the media clock and the BLE interface clock. The media clock can be verified through A / V time scale information.

[0104] In addition, as shown on the left side of Fig. 7, the delay value can be determined by considering the audio / video signal processing times defined in various broadcasting standards. For example, the time intervals between audio-video-audio are defined as 15ms and 45ms by ATSC (Advanced Television Systems Committee), 125ms and 45ms by ITU-R BT.1359-1, and 22ms and 22ms by SMPTE (Society of Motion Picture and Television Engineers), and the delay value can be determined by considering these time intervals.

[0105] The TV can set a rendering delay value for each stream and inform the speaker, or determine the transmission timing of the stream based on the delay value provided by the speaker.

[0106] Based on a determined delay value, the TV can transmit a stream to the speaker. That is, the TV, acting as the source device or transmitter, can exchange delay values ​​with the speaker(s), acting as the sink device or receiver, and perform the task of synchronizing by reflecting the delay values.

[0107] FIGS. 8 and 9 are drawings for explaining the operation of ICL type and INCL type to which the present disclosure is applicable.

[0108] In BLE, channels for audio transmission can be classified into ICL and INCL types. Both ICL and INCL channels can transmit audio data to multiple devices and / or multiple profiles using a Stream ID and a Channel ID. Depending on the ICL and INCL types, it can be determined what operations must be performed on the BLE channel to transmit audio data.

[0109] ICL channels correspond to connection-based use cases that support unidirectional or bidirectional communication over a point-to-point physical link between a single source device and a single sink device. Additionally, INCL channels correspond to broadcast use cases that support only unidirectional communication over a point-to-multipoint physical link between a single source device and one or more sink devices.

[0110] The device's protocol stack may include a profile layer, a channel manager layer, a host layer, and a controller layer in order from the upper layer to the lower layer. Data may be transmitted on a channel basis between the profile layer and the channel manager layer, and data may be transmitted on a stream basis between the channel manager layer and the host layer.

[0111] Referring to FIG. 8, in the case of the ICL type, there may be a connection between the master (M) and the first slave 1 (S1), and a connection between the master (M) and the second slave (S2). In this case, it is possible to transmit two channels included in one stream to the two slaves by distinguishing them using channel identifiers. That is, Channel ID 1 is assigned to S1 and Channel ID 2 is assigned to S2, and both Channel ID 1 and Channel ID 2 can be transmitted through the same Stream ID 1. Additionally, since bidirectional communication is possible based on the connection, the slaves may provide feedback information to the master (M). For example, if S1 is a wireless earphone worn on the right ear and S2 is a wireless earphone worn on the left ear, it is possible to listen to music transmitted by the master (M) in stereo through S1 and S2.

[0112] Referring to FIG. 9, in the case of the INCL type, there is no connection between the master (M) and the slaves (S1, S2), and the slaves can receive broadcast audio data by synchronizing with the timing of the INCL stream offset, event, and sub-event based on the synchronization information advertised by the master. Additionally, the master (M) may include two profiles (Profile #1 and Profile #2). The first slave (S1) may include Profile #1, and the second slave (S2) may include Profile #1 and Profile #2. In Profile #1, Channel ID 1 and Channel ID 2 are broadcast from the master (M) through a single stream, Stream ID 1, and the slaves (S1, S2) each receive Channel ID 1 and Channel ID 2 in Profile #1, similar to FIG. 8. Additionally, Channel ID 1 in Profile #2 is broadcast from the master (M) via Stream ID 2, and the second slave (S2) can receive Channel ID 1 in Profile #2.

[0113] FIG. 10 is a diagram showing a broadcast audio stream state machine to which the present disclosure is applicable.

[0114] Control over a broadcast audio stream can be described by the broadcast audio stream state machine and state transitions at the broadcast transmitter.

[0115] The broadcast audio stream state machine allows a broadcast transmitter to communicate with one or more broadcast receivers (or broadcast discovery clients) in a unidirectional manner without a connection, or without communicating with broadcast receivers (or broadcast discovery clients). The broadcast transmitter may communicate using audio advertisements in the form of a Broadcast Audio Source Session (BASS). A broadcast audio stream may be transmitted by the broadcast transmitter.

[0116] The AUDIO STANDBY state means that the broadcast audio stream is not transmitted.

[0117] The AUDIO CONFIGURED state refers to a state in which information is started to be advertised to allow the broadcast receiver (or broadcast discovery initiator) to detect the audio stream through periodic advertising events. Periodic advertising events may include the transmission of advertisement metadata, stream configuration, synchronization information, etc. In this state, audio data packets are not transmitted from the broadcast transmitter.

[0118] The AUDIO STREAMING state refers to the state where the broadcast audio stream is enabled by the broadcast transmitter, allowing audio data packets to be transmitted. While transmitting the broadcast audio stream, the broadcast transmitter can continuously perform metadata advertising through periodic advertising. In the AUDIO STANDBY state, if the stream is configured, it transitions to the AUDIO CONFIGURED state; conversely, if the stream is released from the AUDIO CONFIGURED state, it can transition back to the AUDIO STANDBY state. In the AUDIO CONFIGURED state, if the stream is enabled, it transitions to the AUDIO STREAMING state; conversely, if the stream is disabled from the AUDIO STREAMING state, it can transition back to the AUDIO CONFIGURED state. If a reconfigure occurs in the AUDIO CONFIGURED state, it can transition back to the AUDIO CONFIGURED state. If content reassignment occurs in the AUDIO Streaming state, it can transition to the AUDIO Streaming state.

[0119] FIG. 11 is a diagram illustrating an audio setup procedure to which the present disclosure is applicable.

[0120] If there is no discovery result (i.e., zero discovery), transition to the AUDIO STANDBY state, and if there is a discovery result, perform discovery for ASC (Audio Stream Capability) and transition to the AUDIO STANDBY state.

[0121] When ASS (Audio Stream Session) configuration occurs, the system can transition to the AUDIO CONFIGURED state. When ASS is released from the AUDIO CONFIGURED state, the system can transition to the AUDIO STANDBY state. When reconfiguration occurs in the AUDIO CONFIGURED state, the system can transition to the AUDIO CONFIGURED state through ASS configuration.

[0122] When ASS is enabled, the system can transition to the AUDIO Streaming state. When ASS is disabled in the AUDIO Streaming state, the system can transition to the AUDIO CONFIGURED state. When content reallocation occurs in the AUDIO Streaming state, the system can transition to the AUDIO Streaming state.

[0123] FIG. 12 is a diagram showing a link hierarchy state machine to which the present disclosure is applicable.

[0124] The operation of the link layer (LL) can be expressed as Standby, Advertising, Scanning, Initiating, Connection, Synchronized (synchronization), and Streaming (Isochronous Broadcasting) states (in terms of isochronous channels).

[0125] The Standby state corresponds to a waiting state before transitioning to another state.

[0126] In the Advertising state, LL can operate as an advertiser that transmits advertising packets. When a connection is established in the Advertising state, the device can operate as a slave.

[0127] In the initiating state, LL can act as an initiator that listens for packets from other advertisers and initiates a connection in response to such packets. When establishing a connection in the initiating state, the device can act as a master.

[0128] In the scanning state, LL can operate as a scanner that listens for packets from other advertisers and may request additional information.

[0129] The Synchronized state may refer to a state in which an audio stream is received or can be received by being synchronized with another device.

[0130] The Streaming state may refer to the state of transmitting an audio stream to another synchronized device.

[0131] FIG. 13 is a drawing showing an example of an audio topology to which the present disclosure is applicable.

[0132] In the case of unicast, unidirectional or bidirectional audio streams can be supported. Unicast audio data transmission and reception can be performed based on the connection between the headset and the smartphone, or based on the connection between the headset and the smartphone, or between the headset and the tablet. In this case, the server of the unicast audio service can be the headphones, and the clients can be smartphones, tablets, etc. Additionally, the headphones correspond to the audio sink, and the smartphones and tablets correspond to the audio sources.

[0133] In the case of broadcasting, an announcement system, doorbell, TV, etc., transmit audio data via a broadcast method, and the broadcasted audio data can be received by one or more devices. In this case, the server of the broadcast audio service can be an announcement system, doorbell, TV, etc., and the client can be headphones. Additionally, headphones correspond to the audio sink, and the announcement system, doorbell, TV can correspond to the audio source.

[0134] FIGS. 14 to 16 are drawings illustrating the process of message exchange between a server and a client to which the present disclosure can be applied.

[0135] In the examples of FIGS. 14 to 16, the client may be the audio source and the server may be the audio sink. Alternatively, the client may be the audio sink and the server may be the audio source.

[0136] Figure 14 illustrates the audio session capability (ASC) discovery procedure and the audio session capability update procedure.

[0137] In the audio session capability discovery procedure of FIG. 14(a), the client requests capability discovery by sending an ASC discovery request message from the server, and in response, the server can transmit detailed information about the capability by sending an ASC discovery response message to the client.

[0139] In the audio session capability update procedure of Fig. 14(b), the server may notify the client that a capability update has occurred by sending an ASC update indication message, and the client may notify the server to perform a capability update by sending an ASC update confirmation message. Subsequently, an audio session capability discovery procedure or an ASC discovery procedure may be performed.

[0140] The format of the message used in the example of Fig. 14 can be defined as shown in Table 1 below.

[0141]

[0142] The ASC update instruction message and the ASC update confirmation message may each include information indicating that ASC discovery is required and confirmation information regarding this.

[0143] Figure 15 illustrates the procedure for setting up a unicast audio stream and the procedure for establishing a unicast audio stream as examples.

[0144] In the unicast audio stream configuration procedure of FIG. 15(a), the client can send a Codec Configuration Request message to the server while in the AUDIO STANDBY state to indicate which codec is being requested for configuration. In response, the server can send a Codec Configuration Response message to the client to indicate 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 Stream Session (ASS), audio group, and audio stream, and indicate the QoS and rendering latency values ​​supported by the client. In response, the server can send a QoS Negotiation Response message to the client. Accordingly, bandwidth (BW), bitrate, etc., can be determined by negotiation between the client and the server, and the client and the server can transition to the CONFIGURED state.

[0145] In the unicast audio stream establishment procedure of FIG. 15(b), the client can notify the server of information regarding the ASS requesting activation by sending an enable request message to the server while in the AUDIO CONFIGURED state. In response, the server can notify the client of which ASS to enable by sending an enable response message. Connection-based isochronous link parameters are configured on the client, and the CBIS can be established by the client and the server configuring the connection-based isochronous stream connection and related parameters. When the client is the audio sink and the server is the audio source, the client prepares to play audio data (e.g., checks buffer / memory, codec, audio application data readiness, etc.) and can notify the server by sending an ASS Rx ready command message. Accordingly, the server prepares to provide audio data (e.g., buffer / memory, codec, checking audio application data readiness, etc.) and can notify the client by sending an ASS Rx ready notification message. If the client is the audio source and the server is the audio sink, the server prepares to play audio data and sends an ASS Rx ready indication message to the client, and the client can prepare to provide audio data after receiving the ASS Rx ready indication message. Accordingly, the client and the server can transition to the AUDIO Streaming state.

[0146] The format of the message used in the example of Fig. 15 can be defined as shown in Table 2 below.

[0147]

[0148] Figure 16 illustrates, for example, the procedure for a client to disable an audio stream and the procedure for a server to disable an audio stream.

[0149] In the procedure for a client to disable audio streams in FIG. 16(a), where the client is the audio source and the server is the audio sink, if the client decides to stop audio while in the AUDIO STREAMING state, it may send an ASS disable request message to the server. Accordingly, the server may stop streaming audio data and send an ASS disable response message to the client. Upon receiving this, the client may stop audio data encoding and audio application operations.

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

[0151] Subsequently, the client and server can release the connection-based isochronous stream and disable the related parameter settings. Here, device information may be stored on the client and / or server along with parameters related to the isochronous stream connection in preparation for reconnection between the client and the server. Accordingly, the client can disable the parameters related to the connection-based isochronous link. Consequently, the client and the server can transition to the AUDIO CONFIGURED state.

[0152] In the example of FIG. 16(b), in the procedure for the server to disable audio streams, where the server is the audio source and the client is the audio sink, if the server decides to stop audio in the AUDIO STREAMING state, it may send an ASS disable indication message to the client. Accordingly, the client may stop streaming audio data and send or not send an ASS disable confirmation message to the server. Whether or not the ASS disable response is received, the server may stop audio data encoding and audio application operations.

[0153] Alternatively, if the server is the audio sink and the client is the audio source, the server may stop streaming audio data and send an ASS disable instruction message to the client. Accordingly, the client may stop audio data encoding and audio application operations, and may or may not send an ASS disable confirmation message to the server.

[0154] Subsequently, the client and server can release the connection-based isochronous stream and disable the related parameter settings. Here, device information may be stored on the client and / or server along with parameters related to the isochronous stream connection in preparation for reconnection between the client and the server. Accordingly, the client can disable the parameters related to the connection-based isochronous link. Consequently, the client and the server can transition to the AUDIO CONFIGURED state.

[0155] The format of the message used in the example of Fig. 16 can be defined as shown in Table 3 below.

[0156]

[0157] Table 4 below shows exemplary message formats for content reallocation request / response, ASS release request / response, general advertisement, and directed advertisement.

[0158]

[0159] FIG. 17 is a diagram showing a state machine for a call service to which the present disclosure is applicable.

[0160] When a call is incoming while in the AUDIO STANDBY state, the system can transition to the CALL ACCEPTING state. When a call is accepted while in the CALL ACCEPTING state, the system can transition to the CALL ACTIVE state. When a call is rejected while in the CALL ACCEPTING state, the system can transition to the AUDIO STANDBY state. When a call is held while in the CALL ACCEPTING state and cannot be received, the system can transition to the CALL HELD state, and when the hold is released while in the CALL HELD state, the system can transition to the CALL ACTIVE state. When the system terminates while in the CALL HELD state or CALL ACTIVE state, it can transition to the AUDIO STANDBY state.

[0161] Additionally, when a call is outgoing from the AUDIO STANDBY state, it can transition to the CALL INITIATING state. When a remote location or counterparty responds to a call from the CALL INITIATING state, it can transition to the CALL ACTIVE state. When the call ends from the CALL INITIATING state, it can transition to the AUDIO STANDBY state.

[0162] In such a call service state machine, audio data that needs to be transmitted to the headset may occur during the AUDIO STANDBY state. For example, audio data may be transmitted to the headset when an audible notification is provided for the response when dialing a phone number.

[0163] In addition, information explicitly indicating various wireless access technologies related to call services (e.g., 2G, 3G, 4G, 5G, Wi-Fi, GSM, CDMA, WCDMA, etc.) may be defined, and, for example, a bearer technology field of one octet size may be defined. This may be related to the aforementioned Call Bearer Service.

[0164] In the case of multiway calling, multiple lines may exist, and a state machine as shown in FIG. 17 may be maintained for each line. For example, if the first line is in the CALL ACTIVE state and the second line transitions from the AUDIO STANDBY state to the CALL ACCEPTING state, the first or second line may be transitioned to the CALL HELD state according to the user's control.

[0165] The logical links and logical transports of the Bluetooth system are described below.

[0166] Various logical links may be used to support diverse application data transmission requirements. Each logical link is associated with a logical transport and may possess various characteristics. These characteristics may include flow control, acknowledgment / repeat mechanisms, sequence numbering, and scheduling operations. Depending on its type, a logical transport can carry various types of logical links. Multiple logical links may also be multiplexed onto a single logical transport. Logical transports may be transmitted via physical links on a specific channel.

[0167] Logical transport identification information and real-time (link control) signaling may be included in the packet header, and specific logical link identification information may be included in the payload header.

[0168] Table 5 below provides exemplary descriptions of logical transport types, supported logical link types, supported physical link and physical channel types, and logical transports.

[0169]

[0170] FIG. 18 is a diagram showing a layered packet format to which the present disclosure is applicable.

[0171] FIG. 18(a) illustrates an example of a link layer (LL) packet format. The LL packet format may include a preamble, an access address (or access code), a PDU, and a Cyclic Redundancy Code (CRC) field. The preamble has a size of 1 octet and may be used at the receiving end for frequency synchronization, symbol timing estimation, Automatic Gain Control (AGC) training, etc., and may consist of a predetermined sequence of bits. The access address has a size of 4 octets and may be used as a correlation code for the physical channel. The PDU is defined as having a size of 2 to 39 octets in Bluetooth version 4.0 and may be defined as having a size of 2 to 257 octets in version 4.2. The CRC may include a value calculated as a 24-bit checksum for the PDU.

[0172] FIG. 18(b) shows an exemplary format of the PDU of FIG. 18(a). The PDU can be defined in two types: one is a data channel PDU, and the other is an advertising channel PDU. The data channel PDU is described in detail with reference to FIG. 19, and the advertising channel PDU is described in detail with reference to FIG. 20.

[0173] FIG. 18(c) shows an example of an L2CAP PDU format, which may correspond to an exemplary format of the payload field in FIG. 18(b). An L2CAP PDU may include Length, Channel ID, and Information Payload fields. The Length field may indicate the size of the Information Payload, and the Information Payload field may contain upper-layer data. The Channel ID field may indicate which upper-layer data the Information Payload field contains. For example, if the value of the Channel ID field is 0x0004, it may indicate ATT (ATTribute Protocol), and if it is 0x0006, it may indicate SMP (Security Manager Protocol), or other Channel ID values ​​indicating other types of upper-layer or middleware may be defined and used.

[0174] When the L2CAP packet of FIG. 18(c) is an L2CAP PDU (i.e., a control frame) transmitted over a signaling channel, the information payload field of FIG. 18(c) may be configured as in FIG. 18(d). The information payload field may include Code, Identifier, Length, and Data fields. For example, the Code field may indicate the type of the L2CAP signaling message. The Identifier field may include a value that matches the request and the response. The Length field may indicate the size of the Data field. The Data field may include attributes. The attributes are arbitrary units of data and may include data at various points in time of various states of the device, such as position, size, weight, temperature, speed, etc.

[0175] An attribute may have a format including an attribute type, an attribute handle, an attribute value, and an attribute permission.

[0176] The attribute type may include a value indicating the type of attribute data identified by a Universally Unique Identifier (UUID).

[0177] An attribute handle may contain a value assigned by the server to identify attribute data.

[0178] The attribute value can contain the value of the attribute data.

[0179] Attribute permissions can be set by a GATT (Generic Attribute Profile) and may include values ​​indicating the types of allowed access to the attribute data (e.g., whether read / write is possible, whether encryption is required, whether authentication is required, whether authorization is required, etc.).

[0180] From the perspective of ATT (Attribute protocol) / GATT (Generic Attribute Profile), a device can act as a server and / or a client. The server acts as a provider of attributes and related values, while the client acts as a provider of attributes on the server, or reads and writes to them.

[0181] ATT / GATT can support the exchange of attribute data between a server and a client. To this end, the PDUs supported by the ATT protocol can include six method types: request, response, command, notification, instruction, and acknowledgment.

[0182] A request is transmitted from the client to the server, and a response from the server is required. A response is transmitted from the server to the client, and is sent when there is a request from the client. A command is transmitted from the client to the server, and no response is required. A notification is transmitted from the server to the client, and acknowledgment is not required. An indication is transmitted from the server to the client, and client acknowledgment is required. A confirmation is transmitted from the client to the server, and is sent when there is an instruction from the server.

[0183] Additionally, GATT can support various profiles. The structure of a GATT-based profile can be described by services and characteristics. A device may support one or more profiles. A single profile may include zero or one or more services. Multiple profiles may utilize the same service. A single service may include one or more characteristics. Characteristics refer to data values ​​that are subject to reading, writing, indicating, or notifying. In other words, a service can be understood as a data structure used to describe a specific function or feature, and a service, as a combination of characteristics, can represent an action performed by the device. All services are implemented by a server and can be accessed by one or more clients.

[0184] FIG. 19 is a drawing showing examples of data unit formats to which the present disclosure is applicable.

[0185] FIG. 19(a) illustrates an exemplary format of a Data Physical Channel (Protocol Data Unit PDU). A Data Physical Channel PDU can be used to transmit packets over a Data Physical Channel (e.g., channel numbers 0 through 36). A Data Physical Channel PDU includes a header of length 16 or 24 bits, a payload of variable size (e.g., 0 through 251 octets), and may additionally 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.

[0186] As illustrated in FIG. 19(b), the header field may include LLID (Logical Link Identifier), NESN (Next Expected Sequence Number), SN (Sequence Number), MD (More Data), CP (CTEInfo Present), RFU (Reserved for Future Use), and Length fields. RFU corresponds to a reserved portion that may be used if needed in the future, and its value can usually be filled with 0. Additionally, depending on the value of the CP field, the header field may further include a CTEInfo (Constant Tone Extension Information) subfield. Furthermore, the Length field may indicate the size of the payload, and if MIC is included, it may indicate the length of the payload and MIC.

[0187] FIG. 19(c) shows an exemplary format of 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 according to an operation code (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.

[0188] For example, the Opcode of the LL Control PDU may have a value representing one of LL_CBIS_REQ, LL_CBIS_RSP, LL_CBIS_IND, LL_CBIS_TERMINATE_IND, LL_CBIS_SDU_CONFIG_REQ, LL_CBIS_SDU_CONFIG_RSP (e.g., 0x1F, 0x20, 0x21, 0x22, ...).

[0189] If the Opcode indicates LL_CBIS_REQ, the CtrData field may contain CBIS identification information, CBIS identification information, and information required for a CBIS request. Similarly, in each case where the Opcode indicates LL_CBIS_RSP, LL_CBIS_IND, LL_CBIS_TERMINATE_IND, LL_CBIS_SDU_CONFIG_REQ, or LL_CBIS_SDU_CONFIG_RSP, CtrData may contain information required for a CBIS response, CBIS indication, CBIS termination indication, CBIS SDU (Service Data Unit) configuration request, or CBIS SDU configuration response.

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

[0191] An audio data PDU can be a CBIS PDU or a broadcast isochronous PDU. When used in a CBIS stream, the audio data PDU can be defined as a CBIS PDU. When used in a broadcast isochronous stream, the audio data PDU can be defined as a broadcast isochronous PDU.

[0192] The audio data PDU may include a header field of 16 bits in length and a payload field of variable length. Additionally, the audio data PDU may further include a MIC field.

[0193] In the case of a CBIS PDU, the header field format may include a 2-bit LLID, a 1-bit NESN, a 1-bit SN, a 1-bit CIE (Close Isochronous Event), a 1-bit RFU, a 1-bit NPI (Null PDU Indicator), a 1-bit RFU, and a 9-bit Length subfield.

[0194] In the case of a broadcast isochronous PDU, the format of the header field may include a 2-bit LLID, a 3-bit CSSN (Control Subevent Sequence Number), a 1-bit CSTF (Control Subevent Transmission Number), a 2-bit RFU, and an 8-bit Length subfield.

[0195] The payload field of an audio data PDU may contain audio data.

[0196] FIG. 20 is a drawing showing examples of advertising unit formats to which the present disclosure is applicable.

[0197] FIG. 20(a) shows an exemplary format of an Advertising Physical Channel (Protocol Data Unit) PDU. An Advertising Channel PDU can be used to transmit packets over an Advertising Physical Channel (e.g., channel numbers 37, 38, 39). An Advertising Channel PDU may consist of a header of 2 octets and a payload of 6 to 37 octets.

[0198] FIG. 20(b) shows an exemplary format of a header for an advertising channel PDU. The header may include PDU Type, RFU (Reserved for Future Use), TxAdd, RxAdd, Length, and RFU fields. The Length field of the header may indicate the size of the payload.

[0199] FIG. 20(c) illustrates an exemplary format of the payload of an advertising channel PDU. The payload may include an AdvA (Advertiser Address) field of 6 octets in length and an AdvData field of 0 to 31 octets in length. The AdvA field may include the public address or random address of the advertiser. The AdvData field may include zero or more Advertising Data (AD) structures and padding if necessary.

[0200] FIG. 20(d) shows the format of a single AD structure. The AD structure may include three fields. The Length field may indicate the length of the AD Data field. That is, the value indicated by the Length field minus 1 may correspond to the length of the AD Data field. The AD Type field may indicate the type of data included in the AD Data field. The AD Data field may include advertising data provided by the advertiser's host.

[0201] The encryption key configuration according to the present disclosure is described below.

[0202] Bluetooth communication systems define a procedure for selecting the minimum length of an encryption key when the Link Manager Protocol (LMP) for BR / EDR or a dual-mode Bluetooth controller encrypts an over-the-air (OTA) channel using E0 or AES (Advanced Encryption Standard)-CCM (Cipher Block Chaining-Message Authentication Code) block ciphers. This is one of the measures to comply with regulations regarding the strength of encryption algorithms used in user devices. However, since the introduction of this procedure into Bluetooth communication systems, these regulations have been changed or updated in various regions.

[0203] Packet-injection attacks may be possible during the negotiation process for encryption key length, which could allow a man-in-the-middle (MITM) device to intentionally reduce the key length used for a specific baseband link, thereby creating a link that can be brute-force-decrypted in real time. Such an attack may be possible if both devices involved in establishing the encrypted link are simultaneously vulnerable.

[0204] The possibility of such attacks can be considered for current Bluetooth communication systems, for example, in the Generic Access Profile (GAP) section (e.g., BR / EDR security mode 4), there is a step to check the encryption key size of the link after encryption is established to verify whether a key size sufficient for a specific purpose has been selected. Additionally, some Bluetooth profiles use this method to require a specific minimum key length.

[0205] There are implementations that are vulnerable to security breaches by allowing negotiation of the key length, and since the negotiated key length is not always checked, if a reduced key length can be negotiated, the minimum length allowed in some implementations can be easily brute-forced to decrypt.

[0206] Improvements are being made to the Bluetooth communication system through updates that enforce GAP-level key length checks, recommend or mandate new encryption key lengths for Bluetooth host implementations, and require Bluetooth controller hardware to support the recommended minimum encryption key length. Additionally, qualification tests are required to verify that implementations meet these requirements.

[0207] Until changes to the Bluetooth standard are adopted, implementations must follow the existing standard, which lacks sufficient encryption key sizes. Therefore, it is recommended that the host enforce a key encryption key of at least 7 octets for each encrypted link established. Hosts using a controller that supports the Host Controller Interface (HCI) and the HCI command 'Read Encryption Key Size' may use this command to determine the length of the selected encryption key for the encrypted link after receiving an event indicating a successful encryption establishment. An update is required for controllers supporting the HCI interface to support this HCI command. For controllers that do not support HCI, or for host-controller integrated architectures, equivalent operations may be performed at the GAP layer or higher.

[0208] If permitted by backward compatibility requirements, Bluetooth devices may operate in secure-connection-only mode and use Random Number Generator (RNG), hash, and block cipher algorithms compliant with Federal Information Processing Standards (FIPS). Additionally, improvements are required to ensure that the minimum key length for the cryptographic connection mode complies with the 16-octet encryption key length requirement.

[0209] As such, since security vulnerabilities caused by short encryption key lengths are a problem in existing Bluetooth communication systems, modifications to the encryption key length are required. Below, embodiments regarding encryption key settings according to the present disclosure, particularly settings for encryption key size (or length), will be described.

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

[0211] HCI provides a uniform method for a host to access the capabilities of a controller. Communication through the HCI interface takes the form of packets. A host can send HCI command packets to the controller and receive asynchronous notifications from the controller using HCI events. Packets transmitted and received over the HCI interface can have one of four types. The four types are defined as HCI command packets, HCI asynchronous data packets, HCI synchronous data packets, and HCI event packets.

[0212] FIG. 21 shows an exemplary HCI packet format to which the present disclosure is applicable.

[0213] Figure 21(a) shows an example of an HCI command packet format, and Figure 21(b) shows an example of an HCI event packet format.

[0214] An HCI command packet, such as the example in Fig. 21(a), is used by the host to send a command to the controller.

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

[0216] The 1-byte parameter total length field specifies the total length in octets of all parameters included in the remaining part of the HCI command packet. One or more command parameters may be included following the parameter total length field.

[0217] An HCI event packet, such as the example in FIG. 21(b), is used by the controller to notify the host when an event will occur. An HCI event may be generated as a response to an HCI command previously sent from the host, or due to other events (e.g., an error, a disconnection, or the reception of a connection request).

[0218] An HCI event packet includes a 1-byte Event Code field. The Event Code may contain a value that identifies the event that occurred.

[0219] The 1-byte parameter total length field specifies the total length in octets of all parameters included in the remaining part of the HCI event packet. One or more event parameters may be included following the parameter total length field.

[0220] Although not illustrated in FIG. 21, HCI asynchronous data packets are used to exchange data between a host and a controller and can be exchanged after a connection is established. HCI synchronous data packets are used to exchange synchronous data between a host and a controller.

[0221] Table 6 below shows an example of an HCI command or event for connection encryption.

[0222]

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

[0224] The Connection_Handle command parameter can be used to identify other controllers forming a connection. The Connection_Handle can be a Connection_Handle for asynchronous connections. Encryption settings can be applied to all Connection_Handle parameters that have the same remote controller. While encryption is being changed, the Link Manager may interrupt all asynchronous traffic on the connection.

[0225] If 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, and the Encryption_Enable parameter is set to a value indicating Turn Link Level Encryption OFF, the controller may return an error code (e.g., 0x25) indicating Encryption Mode Not Acceptable.

[0226] When the controller receives the HCI_Set_Connection_Encryption command, the controller may send an HCI_Command_Status event to the host. When the link manager completes enabling / disabling encryption for the connection, the local controller may send an HCI_Encryption_Change event to the host, and the controller on the remote device may also generate an HCI_Encryption_Change event.

[0227] When various HCI commands are designed, such as the example of HCI_Set_Connection_Encryption mentioned above, they can be implemented in software, such as in the hci_map structure. Table 7 shows an example of source code containing the hci_map structure (e.g., BlueZ, an open source Bluetooth stack).

[0228]

[0229] Newly designed commands may be added to the hci_map structure, such as the example in Table 7. For example, as shown in Table 8, additional commands such as read_encrypt_key_size_cmd and read_encrypt_key_size_rsp may be designed and can be called and used through set_bredr_command.

[0230]

[0231] Referring again to FIG. 2, a protocol stack to which the present disclosure is applicable will be described.

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

[0233] The host is generally implemented in software and the controller is generally implemented in hardware, but is not limited thereto within the scope of this disclosure, and the host or the controller may each be configured in the form of software, hardware, a combination of software and hardware, or firmware.

[0234] In the case of BR / EDR, security-related entities may be included in the controller. Meanwhile, in the case of LE, the functions of the security manager (SM) may be included in the controller or in the host. In the examples of this disclosure, encryption and security-related functions are not limited to being included only in the controller or the host.

[0235] The entity issuing HCI commands to the controller, as well as the host, profile, and service, can all be included in the host. The parts corresponding to the profile or service can be included in a higher layer.

[0236] For example, commands can be passed in the order of profile, security object (e.g., SM in the case of LE), HCI, and controller (e.g., LL in the case of LE).

[0237] FIG. 22 is a drawing illustrating an example of an encryption setting method to which the present disclosure is applicable.

[0238] Referring to FIG. 22, the first device includes a controller and a host, and the second device also includes a controller and a host.

[0239] In step S2210, LMP_encryption_mode_req and LMP_encryption_key_size_req messages (or PDUs) may be exchanged between the controllers of the first and second devices.

[0240] The LMP_encryption_mode_req message can be used to initiate or terminate an encryption mode (or security mode). The LMP_encryption_mode_req message can be transmitted from a device (e.g., a first device) that initiates / terminates encryption mode settings via the HCI_Set_Connection_Encryption command to a counterpart device (e.g., a second device). A device that receives the LMP_encryption_mode_req message can respond using an LMP_accepted message (not shown).

[0241] The LMP_encryption_key_size_req message may contain information regarding the encryption key size suggested by the master device. The LMP_encryption_key_size_req message may be transmitted from the master device to the slave device. A device that receives the LMP_encryption_key_size_req message may respond using an LMP_accepted message (not shown).

[0242] Additionally, although not shown in FIG. 22, after the LMP_encryption_key_size_req message and the response thereto are exchanged, the LMP_start_encryption_req message and the response thereto (e.g., LMP_accepted message) are exchanged, and encryption according to the set encryption mode and key size can be prepared.

[0243] In step S2220, the controller of the first device may transmit an HCI_Encryption_Change event to the host. The HCI_Encryption_Change event may include information (e.g., an Encryption_Enable parameter) indicating that a change to encryption for the Connection_Handle specified by the Connection_Handle event parameter has been completed (e.g., transmitted including information indicating ON).

[0244] The host of the first device that receives the HCI_Encryption_Change event from the controller may send the HCI_Read_Encryption_Key_Size command to the controller in step S2230. The HCI_Read_Encryption_Key_Size command may be used to read the encryption key size for a given Connection_Handle.

[0245] The controller of the first device, upon receiving the HCI_Read_Encryption_Key_Size command from the host, may send an HCI_Command_Complete event containing information about the key size to the host in step S2240. The HCI_Command_Complete event may be used to convey the return status for each HCI command or to convey other event parameters. For example, the HCI_Command_Complete event may be configured similarly to the HCI_Encryption_Change event and may include, for example, Connection_Handle, Encryption Enable, and key size information.

[0246] In this example, the controller can establish link security using an encryption key with a length implemented as a default value. However, as mentioned above, there is a problem of vulnerability to security due to the short default key length.

[0247] Additionally, there is no command defined for the host to set the minimum length of the encryption key to the controller, and the host must obtain the key size changed by the controller using a read command.

[0248] FIG. 23 is a drawing showing an additional example of an encryption setting method to which the present disclosure is applicable.

[0249] In step S2310, the host of the first device may send the HCI_Configure_Minimum_Key_Size command to the controller. The HCI_Configure_Minimum_Key_Size command is defined as a command in which the host sets the minimum length for the encryption key to the controller.

[0250] In response to the HCI_Configure_Minimum_Key_Size command, in step S2320, the controller can send an HCI_Command_Complete event to the host.

[0251] The controller can use the HCI_Command_Complete event to transmit information indicating success or error to the host. For example, the controller may have a range or candidate values ​​for supported key sizes, and a specific key size among the supported key sizes may be set as the default key size. For example, success may be indicated if the key size set as default by the controller is greater than or equal to the minimum key size set by the host, and the minimum key size set by the host corresponds to a key size supported by the controller. An error may be indicated if the key size set as default by the controller is less than the minimum key size set by the host, or if the minimum key size set by the host does not correspond to a key size supported by the controller.

[0252] If the controller supports a key size greater than the minimum key size set by the host, LMP_encryption_mode_req and LMP_encryption_key_size_req messages are exchanged between the controllers of the first and second devices in step S2330, similar to what is described in FIG. 22, so that the encryption mode and encryption key size can be set or changed.

[0253] Unlike the example in FIG. 22, in the example in FIG. 23, the command for the host to read the key size from the controller and the response thereto may be omitted. Instead, at step S2340, through the HCI_Encryption_Change event, information regarding the key size may be provided to the host from the controller, along with information (ON) that the encryption change for a specific Connection_Handle has been completed. That is, the HCI_Encryption_Change event may further include information indicating the key size set / changed by the controller.

[0254] In this example, if the key size set as the default value in the controller is smaller than the minimum key size set by the host, only error information is transmitted to the host. In this case, since the host does not know what key size the controller supports, there is a problem in that it cannot clearly determine what value should be set to avoid errors, even if the minimum key size is reconfigured.

[0255] Furthermore, even if the host defines and uses a command to set the minimum key size to the controller (e.g., the HCI_Configure_Minimum_Key_Size command), there is a problem in that it is unclear whether to set the minimum key size commonly or individually for each link, connection, service, or profile when multiple links, connections, services, or profiles exist on a single device.

[0256] FIG. 24 illustrates an exemplary device related to an encryption setting to which the present disclosure is applicable.

[0257] It is assumed that an exemplary first device can support various applications or services. For example, the first device can support sensing data services, medical services, audio services, etc. Service information of the first device can be transmitted to a second device through an advertising packet (e.g., mirroring, control, file transfer services, etc.). The second device can check service-related information transmitted from the first device.

[0258] FIG. 25 is a drawing illustrating an example of an encryption key size setting to which the present disclosure is applicable.

[0259] As explained in the examples above, when the minimum key size set by the host is smaller than the controller's default setting value (i.e., the key size value set by default in the controller), the controller can transmit error information to the host.

[0260] However, there is ambiguity in the error response behavior of a host that receives error information from a controller. Specifically, in the case of the example in FIG. 24, the controller transmits only error information to the host, but does not provide the host with information such as how much smaller the minimum key size set by the host is compared to the key size set by default in the controller. Consequently, the host repeatedly attempts to set the minimum key size in a blind manner, resulting in the consumption of unnecessary time and resources. Therefore, as shown in the following examples, this ambiguity can be eliminated by the controller informing the host of the key sizes that the controller can support, along with the error information.

[0261] In the following examples according to the present disclosure, information regarding the encryption key size (i.e., key size information) may include one or more of the key size or length itself, a minimum value, a maximum value, a range for the key size or length, or one or more candidate values ​​for these.

[0262] As a representative example, the host is described as being able to generate and / or provide a minimum value for the key size to the controller via a first message (or command), but the scope of the present disclosure is not limited thereto, and may generate and / or provide to the controller one or more of the key size itself, a maximum value, a range, or one or more candidate values ​​for these.

[0263] The controller is described as being able to generate and / or provide to the host via a second message (or event) information indicating the key size itself that the controller supports or is set as default for the controller, but the scope of the present disclosure is not limited thereto, and may generate and / or provide to the host one or more of a minimum value, maximum value, range, or one or more candidate values ​​for the key size.

[0264] Although the profile / service is described as being able to generate a minimum value for the key size and / or provide it to the host via a third message, the scope of the present disclosure is not limited thereto, and may generate and / or provide to the host one or more of the key size itself, a maximum value, a range, or one or more candidate values ​​for these.

[0265] In various examples of the present disclosure, key size information may be set for a predetermined unit. The predetermined unit may be defined by one or more combinations of a profile, service, link, connection, or device (or host).

[0266] As a more specific example, the controller may provide the host with information regarding the key sizes supported by the controller. The controller may provide the host with information regarding the key size set as default in the controller. The controller may include information regarding the supported (or default set in the controller) key sizes in a message responding to a command from the host to set the minimum encryption key value.

[0267] If the setting of the minimum key size value by a command from the host is successful, the controller may provide the host with information regarding the key size supported by the controller (or set as default by the controller) in the response (or response event). If the minimum key size value set by a command from the host is greater than or equal to the controller's default setting value (i.e., the key size value supported by the controller or set as default by the controller), the controller may provide the host with information regarding the key size supported by the controller (or set as default by the controller).

[0268] If the setting of the minimum key size value by a command from the host is an error, the controller may provide the host with information regarding the key size supported by the controller (or set as default by the controller) in the response (or response event). If the minimum key size value set by a command from the host is smaller than the controller's default setting value (i.e., the key size value supported by the controller or set as default by the controller), the controller may provide the host with information regarding the key size supported by the controller (or set as default by the controller).

[0269] Accordingly, when the host sets the minimum encryption key size for the controller, it can adjust / change the minimum encryption key size to be set for the controller based on information regarding the key size supported by the controller (or set as default for the controller) included in the response message containing error information from the controller, and then perform the setting of the minimum encryption key size again.

[0270] As an additional example, if the setting of the minimum key size by a command from the host is an error, the controller may transmit a first event containing error information to the host and additionally transmit a second event containing information about the key size supported by the controller (or set as default by the controller) to the host. If the minimum key size set by a command from the host is smaller than the controller's default setting value (i.e., the key size value supported by the controller or set as default by the controller), the controller may transmit a first event containing error information to the host and additionally transmit a second event containing information about the key size supported by the controller (or set as default by the controller) to the host.

[0271] The command used by the host to set a minimum value for the encryption key size for the controller may further include information regarding the unit to which the minimum value for the encryption key size applies. For example, the unit to which the minimum value for the encryption key size set by the host applies may consist of one or more combinations of links, connections, profiles, services, or devices (or hosts).

[0272] For example, an individual minimum key size value may be set for each link. A single minimum key size value common to multiple links may be set. For some link(s) among all links configured on the device (or host), an individual minimum key size value may be set, and a single minimum key size value common to the remaining link(s) may be set. A single minimum key size value common to all links configured on the device (or host) may be set.

[0273] For example, an individual minimum key size value may be set for each profile. A single minimum key size value common to multiple profiles may be set. For some profile(s) among all profiles configured on the device (or host), an individual minimum key size value may be set, and a single minimum key size value common to the remaining profile(s) may be set. A single minimum key size value common to all profiles configured on the device (or host) may be set.

[0274] For example, an individual minimum key size value may be set for each service. A single minimum key size value common to multiple services may be set. For some service(s) among all services configured on the device (or host), an individual minimum key size value may be set, and for the remaining service(s), a single minimum key size value common to all services configured on the device (or host) may be set.

[0275] For example, individual or common key size minimum values ​​may be set for combinations of links / connections and profiles, combinations of links / connections and services, combinations of profiles and services, or combinations of links, connections, profiles, and services, which are configured on a device (or host).

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

[0277] In step S2520, the host may transmit the HCI_Configure_Minimum_Key_Size command to the controller based on information regarding the minimum encryption key size provided by the profile / service. The HCI_Configure_Minimum_Key_Size command may include a profile identifier, a service identifier, a link / connection identifier (or a link / connection handler), key size information, etc. This means that the HCI_Configure_Minimum_Key_Size command specifies a unit of one or more combinations of links, connections, profiles, or services, and includes information regarding the minimum encryption key size applicable to the specified unit.

[0278] In step S2530, the controller can compare the minimum value for the encryption key size set by the host command with the encryption key size that the controller supports (or is set as default in the controller).

[0279] As a result of comparison, if the minimum value for the encryption key size set by the host command is smaller than the encryption key size supported by the controller (or set as default in the controller), a response event containing error information (e.g., HCI_Command_Complete) may be sent to the host. Additionally, the response event containing error information may be sent to the host with additional information regarding the encryption key size supported by the controller (or set as default in the controller). Alternatively, after sending the first response event containing error information to the host, a second response event containing information regarding the encryption key size supported by the controller (or set as default in the controller) may be sent to the host.

[0280] As a result of comparison, if the minimum value for the encryption key size set by the host command is greater than or equal to the encryption key size supported by the controller (or set as default by the controller), a response event containing success information (e.g., HCI_Command_Complete) may be sent to the host. Additionally, information regarding the encryption key size supported by the controller (or set as default by the controller) may be further included in the response event containing success information and sent to the host. Alternatively, after sending a first response event containing success information to the host, a second response event containing information regarding the encryption key size supported by the controller (or set as default by the controller) may be sent to the host.

[0281] FIG. 26 is a diagram showing additional examples of encryption key size settings to which the present disclosure is applicable.

[0282] For the sake of simplicity, the parts of the example in Fig. 26 that overlap with Fig. 25 are omitted from the explanation.

[0283] In the example of FIG. 26, in step S2610, an operation to manage key size and links between the profile / service of the first device and the host based on the profile / service nature or characteristics may be performed.

[0284] For example, between a profile / service and a host, information regarding key sizes per profile / service can be configured. Table 9 shows an example of a key size table that illustrates the mapping relationship between key sizes and link / connection identifiers (or link / connection handlers) per profile / service.

[0285]

[0286] In the example of Table 9, for the sensing data profile / service, the minimum key size is set to 5 octets, and the corresponding link / connection may be ACL #1. For the medical profile / service, the minimum key size is set to 16 octets, and the corresponding link / connection may be ACL #2. For the audio profile / service, the minimum key size is set to 8 octets, and the corresponding links / connections may be ISO #31 and SCO #34.

[0287] When the minimum encryption key size for a specific profile / service / link / connection is determined between the profile / service and the host, a Key_Size_Set message containing such information may be transmitted from the profile / service to the host. The Key_Size_Set message may include a profile identifier, a service identifier, a link / connection identifier (or a link / connection handler), key size information, etc. This means that the Key_Size_Set message specifies a unit of one or more combinations of links, connections, profiles, or services, and includes information regarding the minimum encryption key size applicable to the specified unit.

[0288] If a minimum encryption key size is set by a command from the host for a specific profile / service / link / connection, the controller may compare the specified minimum key size for the said profile / service / link / connection with a key size supported by the controller (or set as default in the controller) and send a response event based on the comparison result (e.g., an event including success / error and / or key size information) to the host.

[0289] FIG. 27 shows an example of setting the minimum encryption key size per service / profile to which the present disclosure is applicable.

[0290] FIG. 27(a) illustrates a case where multiple devices with different services / profiles are connected.

[0291] For example, the host and controller of a healthcare device (including a heart monitoring function) may set the minimum encryption key size for a medical service / profile to 16 octets (e.g., using the HCI_Configure_Minimum_Key_Size command and HCI_Command_Complete event between the host and controller of the first device, as in the example of FIG. 25 or 26). Accordingly, a secure connection using an encryption key with a length of 16 octets or more may be established to exchange medical data between the healthcare device and a remote device (e.g., a smartphone) (e.g., using the LMP_encryption_mode_req and LMP_encryption_key_size_req between the controller of the first device and the controller of the second device, as in the example of FIG. 22 or 23, and the LMP_accepted message as a response thereto).

[0292] The host and controller of the audio device may set the minimum encryption key size for the medical service / profile to 8 octets (e.g., using the HCI_Configure_Minimum_Key_Size command and HCI_Command_Complete event between the host and controller of the first device, as in the example of FIG. 25 or 26). Accordingly, a secure connection using an encryption key having a length of 8 octets or more may be established to exchange audio data between the audio device and a remote device (e.g., a smartphone) (e.g., using the LMP_encryption_mode_req and LMP_encryption_key_size_req between the controller of the first device and the controller of the second device, as in the example of FIG. 22 or 23, and the LMP_accepted message as a response thereto).

[0293] The host and controller of the lighting device may set the minimum encryption key size for the lighting service / profile to 5 octets (e.g., using the HCI_Configure_Minimum_Key_Size command and HCI_Command_Complete event between the host and controller of the first device, as in the example of FIG. 25 or 26). Accordingly, a secure connection using an encryption key having a length of 5 octets or more may be established to exchange audio data between the lighting device and a remote device (e.g., a smartphone) (e.g., using the LMP_encryption_mode_req and LMP_encryption_key_size_req between the controller of the first device and the controller of the second device, as in the example of FIG. 22 or 23, and the LMP_accepted message as a response thereto).

[0294] FIG. 27(b) illustrates a case where a single device with multiple services / profiles is connected.

[0295] A wearable device may include multiple services / profiles. For example, the multiple services / profiles may include sensing data services, medical services, and audio services.

[0296] The host and controller of the wearable device may set the minimum encryption key size for multiple sensing data, medical, and audio services / profiles to 5, 16, and 8 octets, respectively (e.g., using the HCI_Configure_Minimum_Key_Size command and HCI_Command_Complete event between the host and controller of the first device as exemplified in FIG. 25 or 26). Accordingly, a secure connection may be established using an encryption key having a length of 5, 16, or 8 octets or more, respectively, to exchange sensing, medical, and audio data between the wearable device and a remote device (e.g., a smartphone) (e.g., using the LMP_encryption_mode_req and LMP_encryption_key_size_req between the controller of the first device and the controller of the second device as exemplified in FIG. 22 or 23, and the LMP_accepted message as a response thereto).

[0297] In the examples described above, the operation of the host performing the setting of encryption key size information to the controller can be performed when a predetermined condition is satisfied.

[0298] A specified condition may be when the host verifies encryption key size information mapped to a corresponding application / profile / service / link / connection based on an identifier (e.g., UUID, etc.) of the application / profile / service / link / connection. The mapping relationship between the identifier of the application / profile / service / link / connection and the key size information may be pre-established. Accordingly, the corresponding key size information may be set at the time when the use of a specific application / profile / service / link / connection is initiated.

[0299] A specified condition may be a case where confirmation is requested from the user through a user interface regarding whether to proceed with setting encryption key size information for a specific application / profile / service / link / connection (or whether to execute a specific application / profile / service / link / connection), and the user's confirmation is performed through the user interface.

[0300] In the examples of the present disclosure described above, a method for setting a key size that a controller can support was explained by defining and exchanging commands and events related to key size setting primarily between the profile / service layer, host layer, and controller layer of a first device, in particular between the host and the controller. However, the scope of the present disclosure is not limited thereto, and key size setting may also be performed in a second device.

[0301] For example, a key size setting for a predetermined unit (e.g., one or more combinations of profiles, services, links, and connections) between the first and second devices can be performed between the host and controller on the first device side, and also between the host and controller on the second device side.

[0302] Additionally, in the examples of the present disclosure, the event in which the controller of each device transmits information about the key size it supports to the host may further include information about a predetermined unit (e.g., a combination of one or more of a profile, service, link, and connection) or information about whether encryption is enabled.

[0303] In the examples described above, the exchange and setting of information regarding the encryption key size between the host and the controller may be linked to the link-level encryption settings. That is, information regarding the encryption key size may be exchanged and set when link-level encryption is applied. Therefore, the application of information regarding the encryption key size commonly or independently according to a predetermined unit (e.g., one or a combination of profiles, services, links, and connections) may be included in the application of link-level encryption settings commonly or independently according to the said predetermined unit. For example, if link-level encryption is applied to a specific link, information regarding the encryption key size for that specific link may be exchanged and set. As an additional example, if link-level encryption is applied to all links associated with a specific profile / service, information regarding the encryption key size may be exchanged and set for all links associated with that specific profile / service. For example, the predetermined unit (profile / service / link / connection) may correspond to the BR / EDR method or the LE method. For example, information regarding link-level encryption settings and / or encryption key sizes may be set separately for BR / EDR and LE methods, or may be set commonly for both BR / EDR and LE methods.

[0304] FIG. 28 is a drawing showing the configuration of a first device and a second device to which the present disclosure can be applied.

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

[0306] The processor (2810) performs baseband-related signal processing and may include a host processing unit (2811) and a controller processing unit (2815). The host processing unit (2811) and the controller processing unit (2815) may exchange information through HCI. The host processing unit (2811) may process operations such as L2CAP, ATT, GATT, GAP, and LE profile layers. The controller processing unit (2815) may process operations such as LL and PHY layers. In addition to performing baseband-related signal processing, the processor (2810) may also control the overall operation of the first device (2800).

[0307] The antenna section (2820) may include one or more physical antennas. The transceiver (2830) may include an RF (Radio Frequency) transmitter and an RF receiver. The memory (2840) may store information processed by the processor (2810) and software, operating systems, applications, etc. related to the operation of the first device (2800), and may include components such as a buffer.

[0308] The processor (2810) of the first device (2800) may be configured to implement the operation of the first device (or audio source, or client device) in the embodiments described in the present invention.

[0309] For example, the host processing unit (2811) of the processor (2810) of the first device (2800) can transmit a first message (command) containing information about the minimum value of the encryption key size to the controller processing unit (2815).

[0310] The controller processing unit (2815) can transmit a second message (event) indicating an encryption change to the host processing unit (2811). The second message may include information about the first encryption key size.

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

[0312] The processor (2860) performs baseband-related signal processing and may include a host processing unit (2861) and a controller processing unit (2865). The host processing unit (2861) and the controller processing unit (2865) may exchange information through HCI. The host processing unit (2861) may process operations such as L2CAP, ATT, GATT, GAP, and LE profile layers. The controller processing unit (2865) may process operations such as LL and PHY layers. In addition to performing baseband-related signal processing, the processor (2860) may also control the overall operation of the second device (2860).

[0313] The antenna section (2870) may include one or more physical antennas. The transceiver (2880) may include an RF transmitter and an RF receiver. The memory (2890) may store information processed by the processor (2860) and software, operating systems, applications, etc. related to the operation of the second device (2850), and may include components such as a buffer.

[0314] The processor (2860) of the second terminal device (2850) may be configured to implement the operation of the second device (or audio sink, or server device) in the embodiments described in the present invention.

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

[0316] The controller processing unit (2865) can transmit a second message (event) indicating an encryption change to the host processing unit (2861). The second message may include information about the first encryption key size.

[0317] In the operation of the first device (2800) and the second device (2850), the details described for the first device and the second device in the examples of the present invention may be applied in the same way, and redundant descriptions are omitted.

[0318] Various embodiments of the present disclosure may be implemented by hardware, firmware, software, or a combination thereof. In the case of implementation by hardware, it may be implemented by one or more ASICs (Application Specific Integrated Circuits), DSPs (Digital Signal Processors), DSPDs (Digital Signal Processing Devices), PLDs (Programmable Logic Devices), FPGAs (Field Programmable Gate Arrays), general processors, controllers, microcontrollers, microprocessors, etc.

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

[0320] The embodiments of the present disclosure can be applied to various wireless communication systems to improve the performance of the wireless communication system.

Claims

Claim 1 A method performed by a first host in a wireless communication system, wherein the first host transmits an HCI configure minimum key size command message, which includes information regarding a minimum value of an encryption key size, to a first controller through a first HCI (host controller interface); A method comprising the step of the first host receiving an HCI encryption change event message indicating an encryption change from the first controller through the first HCI, wherein the HCI encryption change event message includes information regarding an encryption key size greater than or equal to the minimum value for key size adjustment or change between the first controller and the first host, and the HCI encryption change event message further includes information regarding a connection identifier for notifying the first host when the encryption for a pre-established connection corresponding to a connection identifier between a first device associated with the first controller and a second device associated with the second controller is changed, and an error is returned from the first controller to the first host based on the fact that the first controller does not support the minimum value included in the HCI setting minimum key size command message, and the first host includes a first L2CAP (logical link control and adaptation protocol) layer that constitutes a protocol stack with the physical (PHY) layer included in the first controller. Claim 2 A method according to claim 1, wherein the HCI encryption change event message further includes information on one or more of a profile identifier, a service identifier, a link identifier, or a device identifier to which the encryption key size is applied. Claim 3 A method according to claim 1, wherein the HCI encryption change event message further includes information on whether link-level encryption is enabled or disabled. Claim 4 In claim 3, when the link-level encryption is enabled, the encryption method is one of E0 or AES-CCM. Claim 5 A method according to claim 1, wherein, in response to the HCI setting minimum key size command message, an HCI command complete event message indicating whether the setting of the minimum value is completed is transmitted from the first controller to the first host. Claim 6 A device comprising a first host in a wireless communication system comprises: a transceiver; and a processor, wherein the processor is Transmitting an HCI configure minimum key size command message containing information on the minimum value of the encryption key size to the first controller through the first HCI (host controller interface); and A device configured to receive an HCI encryption change event message indicating an encryption change from a first controller through the first HCI, wherein the HCI encryption change event message includes information regarding an encryption key size greater than or equal to a minimum value for key size adjustment or change between the first controller and the first host, and the HCI encryption change event message further includes information regarding a connection identifier to notify the first host when the encryption for a pre-established connection corresponding to a connection identifier between a first device associated with the first controller and a second device associated with the second controller is changed, and an error is returned from the first controller to the first host based on the fact that the first controller does not support the minimum value included in the HCI setting minimum key size command message, and the first host includes a first L2CAP (logical link control and adaptation protocol) layer that constitutes a protocol stack with a physical (PHY) layer included in the first controller. Claim 7 A first device comprising a first host and a first controller in a wireless communication system comprises at least one transceiver; and at least one processor, wherein the at least one processor is Transmitting an HCI configure minimum key size command message containing information on the minimum value of the encryption key size from the first host to the first controller through the first HCI (host controller interface); A first device configured to receive an HCI encryption change event message from a first controller to a first host indicating an encryption change through the first HCI, wherein the HCI encryption change event message includes information regarding an encryption key size greater than or equal to a minimum value for key size adjustment or change between the first controller and the first host, and the HCI encryption change event message further includes information regarding a connection identifier to notify the first host when the encryption for a pre-established connection corresponding to a connection identifier between the first device and a second device associated with the second controller is changed, and an error is returned from the first controller to the first host based on the first controller not supporting the minimum value included in the HCI setting minimum key size command message, and the first host includes a first L2CAP (logical link control and adaptation protocol) layer that constitutes a protocol stack with the physical (PHY) layer included in the first controller.

Images