WO2016080798A1 - Method for performing pairing between devices in wireless communication system supporting bluetooth communication and apparatus therefor - Google Patents

Abstract

The present specification relates to a method for performing pairing between devices in a wireless communication system supporting Bluetooth communication, which is performed by a first device, comprising the steps of: performing device discovery; performing, with a second device having an input and/or output function, a pairing delegation setup procedure for performing authentication with a third device through the second device; exchanging input and/or output capability information with the third device; determining an association model used for the authentication with the third device; and requesting an input and/or an output required for the authentication with the third device, and receiving a response thereto.

Description

Method and apparatus for performing pairing between devices in a wireless communication system supporting Bluetooth communication

The present disclosure relates to a wireless communication system supporting Bluetooth communication, and more particularly, to a method of performing a pairing and connection procedure between devices.

Bluetooth is one of the representative short-range wireless technologies that exchange information by connecting various devices (smartphones, PCs, earphones, headphones, etc.). In addition, the technology applied to most smartphones, PCs, laptops, etc., many people are easy to use, easy pairing process provides a stable connection between devices. Recently developed LE technology can reliably provide hundreds of KB of information while consuming less power.

Bluetooth standard technology is divided into BR / EDR (Basic Rate / Enhanced Data Rate) and LE (Low Energy).

Among them, Bluetooth Low Energy (hereinafter referred to as “BLE”) is a technology released since Bluetooth Specification V4.0, and is designed to achieve higher energy efficiency than Bluetooth.

Currently, Bluetooth connection uses a method of requesting a connection from one device to another to be controlled by a user.

In addition, Secure Simple Pairing, which is performed for security in this process, is performed according to I / O of two devices.

Such a method is a direct control method, and various differences of UX for each user appear according to the UI of the controlled device.

In addition, the various devices of Bluetooth have a limited state of I / O, so even if desired, there is a limitation in providing a secure connection through Secure Simple Pairing.

Therefore, an object of the present specification is to provide a method of performing pairing / connection of another device (no I / O function) through a third device (pairing delegator).

That is, the present specification provides a pairing delegation method in which a third device provides I / O (Input / Output) instead when performing connection control protocol and secure simple pairing between devices using Bluetooth technology.

In addition, an object of the present specification is to provide an authentication method using a soft pattern so that a user can easily authenticate two devices.

It is also an object of the present specification to provide a method for newly defining a pairing delegation protocol, a GATT-based characteristic for pairing delegation, and a pairing delegation packet format.

The technical problems to be achieved in the present specification are not limited to the technical problems mentioned above, and other technical problems not mentioned above will be clearly understood by those skilled in the art from the following description. Could be.

The present disclosure provides a method for performing pairing between devices in a wireless communication system supporting Bluetooth communication, the method performed by a first device comprising: performing device discovery; Performing a pairing delegation setup procedure with the second device to perform authentication with the third device via a second device having an input and / or output function; Exchanging input and / or output capability information with the third device; Determining an association model used for authentication with the third device; Sending a first message to the second device for requesting an input and / or output required for authentication with the third device; And receiving from the second device a second message comprising a result of the requested input and / or output.

In the present specification, the first message is a pairing delegation request message, and the second message is a pairing delegation response message.

Also, in the present specification, performing the pairing delegation setup procedure may include: receiving a request for a pairing delegation status from the second device; And transmitting pairing delegation status information to the second device in response to the request.

In this specification, the pairing delegation state information is a pairing delegation support field indicating whether pairing delegation is supported, a field for enabling or disabling the pairing delegation function, or a pairing indicating whether it is currently connected with another pairing delegator. And at least one of a pairing delegation status field.

The present disclosure may further include receiving input and / or output related information supported by the second device and security information supported when the pairing delegation function is activated from the second device.

In addition, in the present specification, input and / or output related information supported by the second device is characterized in that it is expressed in a bitmask (bitmask) method.

In addition, the security information in the present specification is characterized in that the information indicating whether at least one of the authentication (Authentication), Authorization (Authorization) or encryption (Encryption) function provided.

Also, in the present specification, the security information may include at least one of a security mode or a security level.

In addition, in the present specification, the pairing delegation setup procedure may be performed through RFCOMM Protocol or Link Manager in case of Bluetooth BR / EDR, and may be performed through Attribute Protocol or Link Layer in case of Bluetooth LE. do.

In addition, the association model (association model) in the present specification is characterized in that any one of a numeric comparison (Numeric Comparison), a passkey entry (Passkey Entry) or Out of Band.

The first message may include at least one of code information indicating a type of association model for authentication or timer information serving as a criterion for determining success or failure of pairing delegation.

In addition, in the present specification, the timer is started when the first message is transmitted, and the failure of the pairing delegation is characterized in that when the timer does not receive the second message from the second device until expiration.

Also, in the present specification, the result of the input and / or output is a value converted into a specific value according to a predetermined rule in a specific pattern, and the specific value is a six-digit random number used for a passkey entry. digits random number).

In addition, in the present specification, the specific pattern may be a pattern input by a user in the second device and the third device.

In addition, in the present specification, the first device is characterized in that the device does not have an input and / or output function.

In addition, the present specification provides a first device for performing a pairing (pairing) in a wireless communication system supporting Bluetooth communication, Communication unit for communicating with the outside by wireless or wired; And a processor operatively connected to the communication unit, wherein the processor is configured to perform device discovery; Perform a pairing delegation setup procedure with the second device to perform authentication with the third device via a second device having an Input and / or Output function; Exchange input and / or output capability information with the third device; Determine an association model used for authentication with the third device; Send a first message to the second device to request an input and / or output required for authentication with the third device; And control to receive from the second device a second message comprising a result of the requested input and / or output.

The present disclosure can provide an efficient and secure device-to-device connection using Bluetooth technology that provides low power consumption and stable connectivity.

In addition, the present specification has the effect of providing a high security by using a pairing delegation (pairing delegation) service security weakness problem of the device without the I / O function.

In addition, the present specification has an effect that the user can easily and conveniently perform the Bluetooth authentication procedure by performing the authentication procedure through a soft pattern.

Effects obtained in the present specification are not limited to the above-mentioned effects, and other effects not mentioned will be clearly understood by those skilled in the art from the following description. .

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, included as part of the detailed description in order to provide a thorough understanding of the present invention, provide embodiments of the present invention and together with the description, describe the technical features of the present invention.

1 is a schematic diagram illustrating an example of a wireless communication system using Bluetooth low power energy technology to which the method proposed in the present specification may be applied.

2 shows an example of an internal block diagram of a server device and a client device that can implement the methods proposed herein.

3 shows an example of a Bluetooth low power energy topology.

4 and 5 illustrate examples of a Bluetooth communication architecture to which the methods proposed herein may be applied.

6 is a flowchart illustrating an example of a connection procedure method in a Bluetooth low power energy technology.

7 is a flowchart illustrating an example of a method for providing an object transfer service in a Bluetooth low energy energy technology.

8 is a flowchart illustrating an example of a connection procedure method in a Bluetooth BR / EDR technology.

FIG. 9 is a diagram illustrating an example of architectures of Bluetooth BR / EDR and Bluetooth LE that define a pairing delegation service and a profile proposed in the present specification.

FIG. 10 is a diagram illustrating an example of a method for performing secure simple pairing using a pairing delegator in a Bluetooth architecture proposed in the present specification.

11 is a view comparing the Bluetooth pairing procedure proposed by the present and the present specification.

12 is a flowchart illustrating an example of a pairing delegation protocol using a pairing delegator proposed in the present specification.

13 is a flowchart illustrating an example of a pairing delegation protocol in BLE proposed herein.

14 is a flowchart illustrating an example of a pairing delegation protocol in the Bluetooth BR / EDR proposed in the specification.

FIG. 15 is a diagram illustrating an example of a format of a pairing delegation packet proposed in the present specification.

16 is a diagram illustrating a general authentication method and an authentication method using a soft pattern method proposed in the present specification, respectively.

17 is a diagram illustrating an authentication method using a soft pattern proposed in the present specification.

18 is a diagram illustrating an example of a pairing delegation setup procedure proposed in the present specification.

19 is a flowchart illustrating an example of a method for performing an authentication procedure through a passkey entry association model in BLE proposed in the present specification.

20 is a flowchart illustrating an example of pairing failure between devices due to the expiration of a timer proposed in the present specification.

21 is a flowchart illustrating an example of an authentication method using a soft pattern proposed in the present specification.

22 is a diagram illustrating an example of an authentication method using a number comparison association model in the Bluetooth BR / EDR proposed in the specification.

FIG. 23 is a diagram illustrating an example of an authentication method using a passkey entry in the Bluetooth BR / EDR proposed in the present specification.

Hereinafter, with reference to the drawings will be described the present invention in more detail.

The suffixes "module" and "unit" for components used in the following description are merely given in consideration of ease of preparation of the present specification, and the "module" and "unit" may be used interchangeably with each other.

On the other hand, the device (device) described herein is a device capable of wireless communication, a mobile phone, including a smart phone, a tablet PC, a desktop computer, a notebook, a smart TV, a television including an IPTV and the like.

In addition, although an embodiment of the present invention will be described in detail with reference to the accompanying drawings and the contents described in the accompanying drawings, the present invention is not limited or limited by the embodiments.

The terminology used herein is a general term that has been widely used as far as possible in consideration of functions in the present invention, but may vary according to the intention or custom of a person skilled in the art or the emergence of a new technology.

In addition, in certain cases, there is a term arbitrarily selected by the applicant, and in this case, the meaning will be described in the corresponding description of the invention.

Therefore, it is to be understood that the terminology used herein is to be interpreted based on the actual meaning of the term and the contents throughout the specification, rather than simply on the name of the term.

1 is a schematic diagram illustrating an example of a wireless communication system using the Bluetooth low power energy technology proposed in the present specification.

The wireless communication system 100 includes at least one server device 110 and at least one client device 120.

The server device and the client device perform Bluetooth communication by using Bluetooth Low Energy (BLE) technology.

First, compared to Bluetooth Basic Rate / Enhanced Data Rate (BR / EDR) technology, BLE technology has a relatively small duty cycle, enables low-cost production, and significantly reduces power consumption through low data rates. If you use a coin cell battery, it can operate for more than a year.

In addition, the BLE technology simplifies the connection procedure between devices, and the packet size is smaller than that of the Bluetooth BR / EDR technology.

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

The server device 110 may operate as a client device in a relationship with another device, and the client device may operate as a server device in a relationship with another device. That is, in the BLE communication system, any one device may operate as a server device or a client device, and if necessary, operate as a server device and a client device.

The server device 110 may include a data service device, a master device, a master, a server, a conductor, a host device, an audio source device, The client device may be a slave device, a slave device, a slave device, a client, a member, a sink device, an audio sink device, or a second device. It may be represented by a device or the like.

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

The server device refers to a device that receives data from a client and directly communicates with the client device, thereby providing data to the client device through a response when receiving a data request from the client device.

The server device also sends a notification message and an indication message to the client device to provide data information to the client device. In addition, when the server device transmits an indication message to the client device, the server device receives a confirmation message corresponding to the indication message from the client.

In addition, the server device provides data information to the user through a display unit or receives a request input from the user through a user input interface in the process of transmitting and receiving notification, indication, and confirmation messages with the client device. can do.

In addition, the server device may read data from a memory unit or write new data to a corresponding memory in a process of transmitting and receiving a message with the client device.

In addition, one server device may be connected to a plurality of client devices, and may be easily reconnected (or connected) with the client devices by using bonding information.

The client device 120 refers to an apparatus for requesting data information and data transmission from a server device.

The client device receives data from the server device through a notification message, an instruction message, and the like, and when receiving an instruction message from the server device, sends a confirmation message in response to the instruction message.

Similarly, the client device may provide information to the user through an output unit or receive an input from the user through an input unit in the process of transmitting and receiving messages with the server device.

In addition, the client device may read data from the memory or write new data to the memory in the process of transmitting and receiving a message with the server device.

Hardware components such as an output unit, an input unit, and a memory of the server device and the client device will be described in detail with reference to FIG. 2.

In addition, the wireless communication system may configure Personal Area Networking (PAN) through Bluetooth technology. For example, in the wireless communication system, by establishing a private piconet between devices, files, documents, and the like can be exchanged quickly and securely.

The BLE device (or device) may be operable to support various Bluetooth-related protocols, profiles, processing, and the like.

2 shows an example of an internal block diagram of a server device and a client device that can implement the methods proposed herein.

The server device may be connected with at least one client device.

In addition, if necessary, the internal block diagram of each device may further include other components (modules, blocks, and parts), and some of the components of FIG. 2 may be omitted.

As shown in FIG. 2, the server device includes an output unit 111, a user input interface 112, a power supply unit 113, a processor 114, and a memory unit. 115, a Bluetooth interface 116, another communication interface 117, and a communication unit (or a transceiver unit 118).

The output unit 111, the input unit 112, the power supply unit 113, the processor 114, the memory 115, the Bluetooth interface 116, the other communication interface 117 and the communication unit 118 are proposed herein. It is functionally linked to perform the method.

In addition, the client device may include an output unit 121, a user input interface 122, a power supply unit 123, a processor 124, a memory unit 125, and a Bluetooth interface. (Bluetooth Interface 126) and a communication unit (or a transceiver unit 127).

The output unit 121, the input unit 122, the power supply unit 123, the processor 124, the memory 125, the Bluetooth interface 126, and the communication unit 127 are used to perform the method proposed in this specification. Functionally connected

The Bluetooth interface 116, 126 refers to a unit (or module) capable of transmitting data or request / response, command, notification, indication / confirmation message, etc. between devices using Bluetooth technology.

The memories 115 and 125 are units implemented in various types of devices and refer to units in which various kinds of data are stored.

The processor 114, 124 refers to a module that controls the overall operation of the server device or the client device, and controls to process a message request and a received message through a Bluetooth interface and another communication interface.

The processors 114 and 124 may be represented by a controller, a control unit, a controller, or the like.

The processors 114 and 124 may include application-specific integrated circuits (ASICs), other chipsets, logic circuits, and / or data processing devices.

The memories 115 and 125 may include read-only memory (ROM), random access memory (RAM), flash memory, memory cards, storage media, and / or other storage devices.

The communication unit 118 and 127 may include a baseband circuit for processing a radio signal. When the embodiment is implemented in software, the above-described technique may be implemented as a module (process, function, etc.) for performing the above-described function. The module may be stored in memory and executed by a processor.

The memories 115 and 125 may be inside or outside the processors 114 and 124, and may be connected to the processors 114 and 124 by various well-known means.

The output units 111 and 121 refer to modules for providing device status information and message exchange information to a user through a screen.

The power supply unit (power supply unit 113, 123) refers to a module for supplying power required for the operation of each component by receiving the external power, the internal power under the control of the controller.

As we saw earlier, BLE technology has a small duty cycle, and the low data rate can greatly reduce power consumption, so that the power supply is required for the operation of each component with less output power (10 mW (10 dBm or less)). Can supply power.

The input units 112 and 122 refer to a module that provides a user's input to the controller like a screen button so that the user can control the operation of the device.

3 shows an example of a Bluetooth low power energy topology.

Referring to FIG. 3, device A corresponds to a master in a piconet (piconet A, shaded portion) having device B and device C as slaves.

Here, a piconet means a set of devices occupying a shared physical channel in which any one of a plurality of devices is a master and the remaining devices are connected to the master device.

The BLE slave does not share a common physical channel with the master. Each slave communicates with the master through a separate physical channel. There is another piconet (piconet F) with master device F and slave device G.

Device K is on scatternet K. Here, a scatternet means a group of piconets in which connections between other piconets exist.

Device K is a master of device L and a slave of device M.

Device O is also on scatternet O. Device O is a slave of device P and a slave of device Q.

As shown in FIG. 3, there are five different device groups.

Device D is an advertiser and device A is an initiator (group D).

Device E is a scanner and device C is an advertiser (group C).

Device H is an advertiser and devices I and J are scanners (group H).

Device K is also an advertiser and device N is an initiator (group K).

Device R is an advertiser and device O is an initiator (group R).

Devices A and B use one BLE piconet physical channel.

Devices A and C use another BLE piconet physical channel.

In group D, device D advertises using an advertisement event connectable onto an advertising physical channel, and device A is an initiator. Device A may establish a connection with device D and add the device to piconet A.

In group C, device C advertises on the ad physical channel using some type of advertisement event captured by scanner device E.

Group D and Group C may use different advertising physical channels or use different times to avoid collisions.

Piconet F has one physical channel. Devices F and G use one BLE piconet physical channel. Device F is the master and device G is the slave.

Group H has one physical channel. Devices H, I and J use one BLE advertising physical channel. Device H is an advertiser and devices I and J are scanners.

In scatternet K, devices K and L use one BLE piconet physical channel. Devices K and M use another BLE piconet physical channel.

In group K, device K advertises using an advertisement event connectable onto an advertising physical channel, and device N is an initiator. Device N may form a connection with device K. Here, device K becomes a slave of two devices and simultaneously becomes a master of one device.

In scatternet O, devices O and P use one BLE piconet physical channel. Devices O and Q use another BLE piconet physical channel.

In group R, device R advertises using an advertisement event connectable onto an advertising physical channel, and device O is an initiator. Device O may form a connection with device R. Here, device O becomes a slave of two devices and simultaneously becomes a master of one device.

4 and 5 illustrate examples of a Bluetooth communication architecture to which the methods proposed herein may be applied.

Specifically, FIG. 4 illustrates an example of the architecture of Bluetooth Basic Rate (BR) / Enhanced Data Rate (EDR), and FIG. 5 illustrates an example of the architecture of Bluetooth Low Energy (LE).

First, as shown in FIG. 4, the Bluetooth BR / EDR architecture includes a controller stack (Controller stACK, 410), a host controller interface (420), and a host stack (Host stACK, 430).

The controller stack (or controller module 410) refers to a radio transceiver module receiving a 2.4 GHz Bluetooth signal and hardware for transmitting or receiving a Bluetooth packet, and include a BR / EDR radio layer 411 and a BR / EDR baseband layer 412. ), And may include a BR / EDR Link Manager layer 413.

The BR / EDR radio layer 411 is a layer that transmits and receives a 2.4 GHz radio signal. When using GFSK (Gussian Frequency Shift Keying) modulation, the BR / EDR radio layer 411 may transmit data by hopping 79 RF channels.

The BR / EDR baseband layer 412 plays a role of transmitting a digital signal, selects a channel sequence hopping 1600 times per second, and transmits a 625us length time slot for each channel.

The link manager layer 413 controls the overall operation (link setup, control, security) of the Bluetooth connection by using a link manager protocol (LMP).

The Link Manager layer can perform the following functions.

ACL / SCO logical transport and logical link setup and control

Detach: Stops the connection and tells the other device why.

-Perform power control and role switch.

-Perform Security (authentication, pairing, encryption) function.

The host controller interface layer 420 provides an interface between the host module 430 and the controller module 410 to allow the host to provide commands and data to the controller, and the controller to provide events and data to the host. .

The host stack (or host module 430) includes L2CAP (437), Service Discovery Protocol (433), BR / EDR Protocol (432), BR / EDR Profiles (431), Attribute Protocol (436), and Generic Access Profile. (GAP, 434) and Generic Attribute Profile (GATT, 435).

The Logical Link Control and Adaptation Protocol (L2CAP) 437 provides one bidirectional channel for transmitting data to a specific protocol or profile.

The L2CAP multiplexes various protocols, profiles, etc. provided by the upper layer of Bluetooth.

L2CAP of Bluetooth BR / EDR uses dynamic channel, supports protocol service multiplexer, retransmission, streaming mode, and provides segmentation, reassembly, per-channel flow control, and error control.

The SDP (Service Discovery Protocol) 433 refers to a protocol for searching for a service (Profile and Protocol) supported by a Bluetooth device.

The BR / EDR Protocol and Profiles 432 and 431 define a profile using Bluet BR / EDR and an application protocol for transmitting and receiving these data.

The Attribute Protocol 436 has a Server-Client structure and defines a rule for accessing data of a counterpart device. There are six types of messages (Request message, Response message, Command message, Notification message, Indication message) as shown below.

-Request message from client to server with Response message from server to client

-Command message from client to server without response message

-Notification message from server to client without Confirm message

-Indication message from server to client with Confirm message from client to server

The Generic Attribute Profile (GATT, 435) defines the type of attribute.

The Generic Access Profile (GAP, 434) defines a method for providing device discovery, connection, and providing information to a user, and provides privacy.

As shown in FIG. 5, the BLE structure includes a controller stack operable to handle timing critical radio interface and a host stack operable to process high level data.

The controller stACK may be referred to as a controller. Hereinafter, the controller stACK will be referred to as a controller stACK to avoid confusion with a processor which is a device internal component mentioned in FIG. 2.

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

The host stack may be implemented as part of an OS running on a processor module, or as an instance of a package on the OS.

In some instances, the controller stack and the host stack can be operated or executed on the same processing device in the processor module.

 The host stack includes GAP (Generic Access Profile, 510), GATT based Profiles (520), GATT (Generic Attribute Profile, 530), ATT (Attribute Protocol, 540), SM (Security Manage, 550), L2CAP (Logical Link Control and Adaptation Protocol, 560). However, the host stack is not limited to this and may include various protocols and profiles.

The host stack uses L2CAP to multiplex the various protocols, profiles, etc. provided by Bluetooth.

First, the Logical Link Control and Adaptation Protocol (L2CAP) 560 provides one bidirectional channel for transmitting data to a specific protocol or profile.

L2CAP may be operable to multiplex data among higher layer protocols, segment and reassemble packages, and manage multicast data transmission.

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

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

The SM (Security Manager, 550) is a protocol for authenticating devices and providing key distribution.

ATT (Attribute Protocol, 540) defines a rule for accessing data of a counterpart device in a server-client structure. There are six message types in ATT: Request, Response, Command, Notification, Indication, and Confirmation.

That is, ① Request and Response message: The Request message is a message for requesting specific information from the client device to the server device, and the Response message is a response message to the request message, and refers to a message transmitted from the server device to the client device.

② Command message: A message sent from the client device to the server device to indicate a command of a specific operation. The server device does not transmit a response to the command message to the client device.

③ Notification message: This message is sent from the server device to the client device for notification such as an event. The client device does not transmit a confirmation message for the notification message to the server device.

④ Indication and Confirm message: This message is transmitted from the server device to the client device for notification such as an event. Unlike the notification message, the client device transmits an acknowledgment message for the Indication message to the server device.

Generic Access Profile (GAP) is a newly implemented layer for BLE technology. It is used to select roles for communication between BLE devices and to control how multi-profile operation occurs.

In addition, GAP is mainly used in the device discovery, connection creation and security procedures, and defines the way to provide information to the user, and defines the type of the attribute as follows.

① Service: Defines the basic behavior of the device by combining behaviors related to data.

② Include: Define the relationship between services.

③ Characteristics: Data value used in service

④ Behavior: Computer readable format defined by UUID (Universal Unique Identifier, value type)

GATT-based Profiles are profiles that depend on GATT and are mainly applied to BLE devices. GATT-based Profiles may be Battery, Time, FindMe, Proximity, Time, Object Delivery Service, and the like. Details of GATT-based Profiles are as follows.

Battery: How to exchange battery information

Time: How to exchange time information

FindMe: Provides alarm service according to distance

Proximity: How to exchange battery information

Time: How to exchange time information

GATT may be operable as a protocol describing how ATT is used in the configuration of services. For example, the GATT may be operable to specify how ATT attributes are grouped together into services, and may be operable to describe features associated with the services.

Thus, GATT and ATT may use features to describe the state and services of a device and to describe how features relate to each other and how they are used.

The controller stack includes a physical layer 590, a link layer 580, and a host controller interface 570.

The physical layer (wireless transmit / receive module 590) transmits and receives a 2.4 GHz radio signal and uses Gaussian Frequency Shift Keying (GFSK) modulation and a frequency hopping method consisting of 40 RF channels.

Link layer 580 sends or receives Bluetooth packets.

In addition, the link layer creates a connection between devices after performing advertising and scanning functions using three advertising channels, and provides a function of sending and receiving data packets of up to 42 bytes through 37 data channels.

Host Controller Interface (HCI) provides an interface between the host stack and the controller stack, providing commands and data from the host stack to the controller stack, and providing events and data from the controller stack to the host stack.

In the following, the procedure of the Bluetooth Low Energy (BLE) technology will be briefly described.

The BLE procedure may be classified into a device filtering procedure, an advertising procedure, a scanning procedure, a discovery procedure, a connecting procedure, and the like.

device Filter step (Device Filtering Procedure)

The device filtering procedure is a method for reducing the number of devices performing a response to a request, an indication, a notification, and the like in the controller stack.

When all devices receive a request, it is unnecessary to respond to it, so the controller stack can control the number of requests sent, reducing power consumption in the BLE controller stack.

The advertising device or scanning device may perform the device filtering procedure to limit the device receiving the advertising packet, scan request or connection request.

Here, the advertising device refers to a device that transmits an advertising event, that is, performs an advertisement, and is also referred to as an advertiser.

The scanning device refers to a device that performs scanning and a device that transmits a scan request.

In BLE, when the scanning device receives some advertising packets from the advertising device, the scanning device should send a scan request to the advertising device.

However, if a device filtering procedure is used so that a scan request transmission is unnecessary, the scanning device may ignore the advertisement packets transmitted from the advertisement device.

The device filtering procedure may also be used in the connection request process. If device filtering is used in the connection request process, it is not necessary to transmit a response to the connection request by ignoring the connection request.

Advertising step (Advertising Procedure)

The advertising device performs an advertising procedure to perform a non-directional broadcast to the devices in the area.

Here, non-directional broadcast refers to broadcast in all directions rather than broadcast in a specific direction.

In contrast, directional broadcasts refer to broadcasts in a particular direction. Non-directional broadcasts occur without a connection procedure between an advertising device and a device in a listening (or listening) state (hereinafter referred to as a listening device).

The advertising procedure is used to establish a Bluetooth connection with a nearby initiating device.

Alternatively, the advertising procedure may be used to provide periodic broadcast of user data to the scanning devices that are listening on the advertising channel.

In the advertising process, all advertisements (or advertisement events) are broadcast over an advertising physical channel.

The advertising devices may receive a scan request from listening devices that are listening to obtain additional user data from the advertising device. The advertising device transmits a response to the scan request to the device that sent the scan request through the same advertising physical channel as the received advertising physical channel.

Broadcast user data sent as part of an advertisement packet is dynamic data, while scan response data is generally static data.

The advertising device may receive a connection request from the initiating device on the advertising (broadcast) physical channel. If the advertising device used a connectable advertising event and the initiating device was not filtered by the device filtering procedure, the advertising device stops the advertising and enters the connected mode. The advertising device may start advertising again after the connected mode.

scanning step (Scanning Procedure)

The device performing the scanning, i.e., the scanning device, performs a scanning procedure to listen to the non-directional broadcast of the user data from the advertising devices using the advertising physical channel.

The scanning device sends a scan request to the advertising device via the advertising physical channel to request additional user data from the advertising device. The advertising device transmits a scan response that is a response to the scan request, including additional user data requested by the scanning device over the advertising physical channel.

The scanning procedure can be used while connected to other BLE devices in the BLE piconet.

If the scanning device is in an initiator mode that can receive the broadcasted advertising event and initiate a connection request, the scanning device sends the connection request to the advertising device via the advertising physical channel to the advertising device. You can start a Bluetooth connection with.

When the scanning device sends a connection request to the advertising device, the scanning device stops initiator mode scanning for further broadcast and enters the connected mode.

Discover step (Discovering Procedure)

Devices capable of Bluetooth communication (hereinafter referred to as "Bluetooth devices") perform an advertisement procedure and a scanning procedure to find devices that are nearby or to be found by other devices within a given area.

The discovery procedure is performed asymmetrically. A Bluetooth device that attempts to find other devices around it is called a discovering device and listens for devices that advertise scannable advertising events. Bluetooth devices discovered and available from other devices are referred to as discoverable devices, and actively broadcast advertising events so that other devices can scan through an advertising (broadcast) physical channel.

Both the discovering device and the discoverable device may already be connected with other Bluetooth devices in the piconet.

connect step (Connecting Procedure)

The connection procedure is asymmetric, and the connection procedure requires the other Bluetooth device to perform the scanning procedure while the specific Bluetooth device performs the advertisement procedure.

That is, the advertising procedure can be the goal, so that only one device will respond to the advertising. After receiving the accessible advertising event from the advertising device, the connection may be initiated by sending a connection request to the advertising device via the advertising (broadcast) physical channel.

Next, an operation state of the BLE technology, that is, an advertising state, a scanning state, an initiating state, and a connection state will be briefly described.

Advertising state (Advertising State)

The link layer LL enters the advertisement state by the instruction of the host (stack). If the link layer is in the advertising state, the link layer sends advertisement PDUs (Packet Data Units) in the advertising events.

Each advertising event consists of at least one advertising PDU, which is transmitted via the advertising channel indexes used. The advertisement event may terminate when the advertisement PDU is transmitted through each of the advertisement channel indexes used, or may terminate the advertisement event earlier when the advertisement device needs to make space for performing another function.

scanning state (Scanning State)

The link layer enters the scanning state by the indication of the host (stack). In the scanning state, the link layer listens for advertising channel indices.

There are two types of scanning states: passive scanning and active scanning, each scanning type being determined by the host.

There is no separate time or advertisement channel index for performing scanning.

During the scanning state, the link layer listens for the advertising channel index during the scanWindow duration. ScanInterval is defined as the interval (interval) between the starting points of two consecutive scan windows.

If there is no scheduling conflict, the link layer must listen for completion of all scan intervals in the scan window as instructed by the host. In each scan window, the link layer must scan a different advertising channel index. The link layer uses all available advertising channel indexes.

When passive scanning, the link layer only receives packets and does not transmit any packets.

When active scanning, the link layer performs listening to rely on the advertising PDU type, which may request advertising PDUs and additional information related to the advertising device from the advertising device.

Start state (Initiating State)

The link layer enters the initiation state by the indication of the host (stack).

When the link layer is in the initiating state, the link layer performs listening for the advertising channel indexes.

During the initiation state, the link layer listens for the advertising channel index during the scan window period.

connect state (connection state)

The link layer enters the connected state when the device performing the connection request, i.e., the initiating device, sends the CONNECT_REQ PDU to the advertising device or when the advertising device receives the CONNECT_REQ PDU from the initiating device.

After entering the connected state, the connection is considered to be created. However, it does not need to be considered to be established at the time the connection enters the connected state. The only difference between the newly created connection and the established connection is the link layer connection supervision timeout value.

When two devices are connected, the two devices act in different roles.

The link layer that performs the master role is called a master, and the link layer that performs the slave role is called a slave. The master controls the timing of the connection event, and the connection event is the point in time when the master and the slave are synchronized.

Master (Central) is a device that periodically scans the Connectable Advertising Signal and makes a connection request to an appropriate device to establish a connection with another device (slave, peripheral).

In addition, once the master device is connected to the slave device, it sets timing and drives periodic data exchange.

Here, timing may be a hopping rule that two devices decide to send and receive data on the same channel every time.

A slave (peripheral) device is a device that periodically transmits a connectable advertising signal to establish a connection with another device (master).

Therefore, when the master device that receives this sends a connection request, it accepts it to establish a connection.

After the slave device establishes a connection with the master device, it periodically exchanges data while hopping channels together at the timing specified by the master device.

Hereinafter, the packet defined in the Bluetooth interface will be briefly described. BLE devices use the packets defined below.

packet format ( P ACK et  Format)

The link layer has only one packet format used for both advertisement channel packets and data channel packets.

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

When one packet is sent on an advertising physical channel, the PDU will be an advertising channel PDU, and when one packet is sent on a data physical channel, the PDU will be a data channel PDU.

Advertising channel  Advertising Channel PDU (PDU)

The advertising channel PDU (Packet Data Unit) has a 16-bit header and various payload sizes.

The PDU type field of the advertising channel PDU included in the header indicates a PDU type as defined in Table 1 below.

PDU Type	PACKet Name
0000	ADV-IND
0001	ADV_DIRECT_IND
0010	ADV_NONCONN_IND
0011	SCAN_REQ
0100	SCAN_RSP
0101	CONNECT_REQ
0110	ADV_SCAN_IND
0111-1111	Reserved

Advertising  PDU

The following advertising channel PDU types are called advertising PDUs and are used in specific events.

ADV_IND: Connectable Non-Oriented Ads Event

ADV_DIRECT_IND: Connectable Directional Advertising Event

ADV_NONCONN_IND: Non-Connectable Non-Oriented Ads Event

ADV_SCAN_IND: Scannable Non-Oriented Ads Event

The PDUs are transmitted at the link layer in the advertisement state and received by the link layer in the scanning state or initiating state.

Scanning PDUs

The advertising channel PDU type below is called a scanning PDU and is used in the state described below.

SCAN_REQ: Sent by the link layer in the scanning state and received by the link layer in the advertising state.

SCAN_RSP: Sent by the link layer in the advertising state and received by the link layer in the scanning state.

Initiating PDUs

The advertising channel PDU type below is called the initiating PDU.

CONNECT_REQ: Sent by the link layer in the initiating state and received by the link layer in the advertising state.

data channel  Data Channel PDUs (PDUs)

The data channel PDU has a 16-bit header, payloads of various sizes, and may include a message integrity check (MIC) field.

As described above, the procedure, state, packet format, etc. in the BLE technology may be applied to perform the methods proposed herein.

Hereinafter, a brief description will be made of a connection procedure in a Bluetooth LE, and as an example, a method of providing an object transmission service in a Bluetooth LE will be described.

6 is a flowchart illustrating an example of a connection procedure method in a Bluetooth low power energy technology.

The server transmits an advertisement message to the client through the three advertising channels (S610).

The server may be called an advertiser before the connection, and may be called a master after the connection. As an example of the server, there may be sensors (such as a temperature sensor).

In addition, the client may be called a scanner before the connection, and may be called a slave after the connection. An example of the client is a smartphone.

Like Salpin, Bluetooth communicates over a total of 40 channels over the 2.4 GHz band. Three of the 40 channels are advertising channels, and are used for exchanging packets to form a connection including various advertising packets.

The remaining 37 channels are used for data packet exchange after connection as data channel.

After receiving the advertisement message, the client may transmit a scan request to the server to obtain additional data (eg, a server device name) from the server.

Then, the server transmits a scan response including the remaining data in response to the scan request to the client.

Here, Scan Request and Scan Response are one kind of advertisement packet, and the advertisement packet may include only User Data of 31 bytes or less.

Therefore, if the data size is larger than 31 bytes, but there is a large data overhead for sending data through connection, the data is divided into two times using Scan Request / Scan Response.

Next, the client transmits a connection request for establishing a Bluetooth connection with the server to the server (S620).

Through this, the connection of the link layer LL is established between the server and the client.

Thereafter, the server and the client perform a security establishment procedure.

The security establishment procedure may be interpreted as Secure Simple Pairing or may be performed including the same.

That is, the security establishment procedure may be performed through Phase 1 to Phase 3.

In detail, a pairing procedure (Phase 1) is performed between the server and the client (S630).

In the pairing procedure, the client transmits a pairing request to the server, and the server transmits a pairing response to the client.

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

Next, as SSP Phase 3, a key distribution procedure is performed between the server and the client (S650).

This establishes a secure connection between the server and the client and enables the transmission and reception of encrypted data.

7 is a flowchart illustrating an example of a method for providing an object transfer service in a Bluetooth low energy energy technology.

Object Delivery Service or Object Transfer Service refers to a service supported by BLE for transmitting / receiving an object or data such as bulk data in Bluetooth communication.

In order to establish a Bluetooth connection between the server device and the client device, an advertisement process and a scanning process corresponding to steps S710 to S730 are performed.

First, a server device transmits an advertisement message to a client device to inform the server device related information including an object transfer service (S710).

The advertisement message may be expressed as an advertisement packet data unit (PDU), an advertisement packet, an advertisement, an advertisement frame, an advertisement physical channel PDU, or the like.

The advertisement message may include service information (including a service name) provided by the server device, a name of the server device, manufacturer data, and the like.

In addition, the advertisement message may be transmitted to the client device in a broadcast manner or a unicast manner.

Thereafter, the client device transmits a scan request message to the server device in order to know more detailed information about the server device (S720).

The scan request message may be expressed as a scanning PDU, a scan request PDU, a scan request, a scan request frame, a scan request packet, and the like.

Thereafter, the server device transmits a scan response message to the client device in response to the scan request message received from the client device (S730).

The scan response message includes server device related information requested by the client device. Here, the server device related information may be an object or data that can be transmitted from a server device in connection with providing an object transfer service.

When the advertisement process and the scanning process are finished, the server device and the client device perform an Initiating Connection process and a Data Exchange process corresponding to steps S740 to S770.

In more detail, the client device transmits a connect request message to the server device for the Bluetooth communication connection with the server device (S740).

The connection request message may be expressed as a connection request PDU, an initialization PDU, a connection request frame, a connection request, and the like.

In operation S740, a Bluetooth connection is established between the server device and the client device, and then the server device and the client device exchange data. In the data exchange process, data may be transmitted and received through a data channel PDU.

The client device transmits an object data request to the server device through a data channel PDU (S750). The data channel PDU may be represented by a data request message, a data request frame, or the like.

Thereafter, the server device transmits the object data requested by the client device to the client device through a data channel PDU (S760).

Here, the data channel PDU is used to provide data or request data information to a counterpart device in a manner defined by an attribute protocol.

Subsequently, when a change of data occurs in the server device, the server device transmits data change indication information to the client device through a data channel PDU to notify the change of data or an object (S770). .

Thereafter, the client device requests changed object information to the server device to find changed data or changed objects (S780).

Thereafter, the server device transmits the changed object information from the server device to the client device in response to the changed object information request (S790).

Thereafter, the client device searches for the changed object through comparative analysis with the received changed object information and the object information currently owned by the client device.

However, the client device repeatedly performs steps S780 and S790 until it finds the changed object or data.

Thereafter, when the connection state does not need to be maintained between the host device and the client device, the host device or the client device may disconnect the connection state.

8 is a flowchart illustrating an example of a connection procedure method in a Bluetooth BR / EDR technology.

As shown in FIG. 8, the connection procedure in the Bluetooth BR / EDR may include the following steps.

The connection procedure may also be expressed as a pairing procedure.

The Bluetooth pairing procedure is divided into a standby state and a connected state only.

When the Bluetooth pairing is completed, the device is in the connected state, and the connected device is operated in the standby state.

In addition, the Bluetooth devices may be connected to a specific device through a connection procedure, and then perform a reconnection procedure to reconnect.

The reconnection procedure can be performed through the same procedure as the connection procedure.

Specifically, the master device basically enters the standby state when the power is input.

Thereafter, an Inquiry procedure S811 for discovering peripheral devices in order to connect Bluetooth is performed.

In other words, the master device can be in the Inquiry State in order to discover the devices (slaves) that can be connected to the peripherals. Inquiry scan state may be in order to receive a packet.

The master device, which is in the query state, transmits an inquiry message using an ID packet once or at predetermined time intervals in order to find a device that can be connected nearby.

The ID packet may be a General Inquiry Access Code (GIAC) or a Dedicated Inqury Access Code (DIAC).

After receiving the GIAC or DIAC, which is an ID packet transmitted by the master device, the slave device transmits a frequency hopping sequence (FHS) to perform Bluetooth pairing with the master device.

In addition, when there is data to be transmitted, if necessary, an Extended Inquiry Response (hereinafter referred to as an EIR) may be transmitted to the master device.

When the neighboring Bluetooth device is found through the enquiry procedure, the paging procedure (S812) is performed.

The paging procedure (S812) refers to a step of performing an actual connection by synchronizing a hopping sequence with address and clock information when a peripherally connectable Bluetooth device is found through the inquiring procedure.

Specifically, the paging procedure includes the steps of (1) sending a page to the slave device by the master device, (2) sending a slave page response to the slave device, and (3) master page to the slave device. It may be divided into a step of transmitting a response.

After the enqueue procedure and the paging procedure are completed, the master device and the slave device perform a security establishment step (S814), and then perform an L2CAP connection and a service discovery step (S815).

Before performing the security establishment step, the master device and the slave device exchange I (Input) / O (Output) capability with each other (S813).

This can be done through an I / O capability request and an I / O capability response.

In addition, the security establishment step may include or be interpreted to mean the Secure Simple Pairing procedure to be described later.

The L2CAP (Logical Link Control and Adaption Protocol) is a packet-based protocol similar to the UDP protocol. It has a packet size of maximum 672 bytes, but it can be changed up to 65,535 bytes when communication starts.

After performing the L2CAP connection and service discovery step, the master device may transmit data received from the user to the slave device (S816).

When the master device and the slave device which perform the connection procedure do not exchange data with each other for a predetermined time, the master device and the slave device switch to the sleep state to prevent energy consumption, and the connection state is terminated.

Thereafter, the master device and the slave device perform a reconnection procedure to transmit / receive data again.

The reconnection procedure may be performed through the same steps as the salpin connection procedure.

Secure Simple Pairing ( SSP)

Next, a brief look at Secure Simple Pairing (SSP).

SSPs can be divided into (1) I / O Capabilities exchange, (2) Public Key exchange, Phase 1, (3) Authentication Stage 1, Phase 2, ( 4) authentication stage 2 (Authentication Stage 2, Phase 3), (5) Link key calculation (Phase 4), (6) LMP Authentication and Encryption (Phase 5). .

Steps (2) to (6) may be composed of 13 steps in total.

Also, while steps (2), (4), (5) and (6) are the same in all protocols, step (3), i.e., authentication step 1, is different for each protocol since it depends on the protocol used.

First, devices exchange I / O capabilities to determine the appropriate algorithm to be used in the authentication phase.

Here, the algorithm is called as an association model, and there are (1) Numeric Comparison, (2) Just Works, (3) Out of Band, and (4) Passkey Entry. .

The Just Works may be included in the Numeric Comparison.

Therefore, the association model may be classified into (1) Numeric Comparison, (2) Out of Band, and (3) Passkey Entry.

In addition, the authentication step 1 may differ in the procedure performed according to each association model.

First, the Numeric Comparison association model can be used in scenarios where both devices can display six digits and the user can enter 'yes' or 'no'.

A good example of a numerical comparison association model is the phone / PC scenario.

The user sees a six digit number ('000000 to' 999999 ') on the display of the two devices and is asked if the numbers displayed on the two devices are the same. If 'yes' is input to both devices, pairing between the two devices succeeds.

The Just Works association model can then be used in scenarios where at least one of the devices cannot display six digits and does not have a keyboard to enter six digits.

A good example of the Just Works related model is the Cell phone / mono headset scenario. Most headsets do not have a display.

The Just Works association model uses the Numeric Comparison protocol. However, the user cannot see a certain number and the application can simply recognize that the user has allowed the connection.

Next, the Out of Band association model can be used primarily in scenarios where the Out of Band mechanism is used both in the procedure of exchanging or transmitting cipher numbers used in the pairing procedure, as well as in the procedure of discovering devices.

To be effective from a security point of view, the Out of Band channel must provide different characteristics from a security point of view compared to a Bluetooth wireless channel. The out of band channel must be resistant to man-in-the-middle attack. Otherwise, security may be compromised during authentication.

The user's experience varies slightly depending on the Out of Band mechanism.

As an example, in the NFC solution, the user (s) first touch the two devices together, and are given the option to pair the first device with the other device.

If YES is entered, pairing is successful.

The exchanged information is one touch experience used in two devices.

The exchanged information includes not only cryptographic information, but also discovery information (such as a Bluetooth device address). One of the devices uses the Bluetooth device address to establish a connection with the other device.

The rest of the exchanged information is used during authentication.

Next, the Passkey Entry association model can be used primarily in scenarios where one device has the input capability but does not have the ability to display six digits and the other device has the ability to display.

Good examples of such association models are PC and keyboard scenarios.

The user can see the six digits through the device with the display. The user may be asked to input a six digit number through another device.

If the value entered in the other device is correct, the pairing succeeds.

Table 2 below shows an association model applied according to device (device) attributes in Bluetooth BR / EDR.

Device properties	Display only	Display Yes / No	Keyboard only	No Input No Output
Display only	Numeric comparison with automatic confirmation on both devices, Unauthenticated	Numeric comparison with automatic confirmation on device B only, Unauthenticated	Passkey entry : Responder display, Initiator Input. Authenticated	Numeric comparison with automatic confirmation on both devices -Unauthenticated
Display Yes / No	Numeric comparison with automatic confirmation on device A only, Unauthenticated	Numeric comparison : Both Display, Both Confirm Authenticated	Passkey entry Responder Display, Initiator Input Authenticated	Numeric comparison with automatic confirmation on device A only Unauthenticated
Keyboard only	Passkey entry: Initiator display, responder input Authenticated	Passkey entry: Initiator display, responder input Authenticated	Passkey entry: Initiator and Responder input Authenticated	Numeric comparison with automatic confirmation on both devices Unauthenticated
No Input No Output	Numeric comparison with automatic confirmation on both devices, unauthenticated	Numeric comparison with automatic confirmation on B device only, unauthenticated	Numeric comparison with automatic confirmation on both devices, unauthenticated	Numeric comparison with automatic confirmation on both devices, unauthenticated

Referring to Table 2, Numeric Comparison is used when both devices have a display module that can display six digit numbers, and when there is an input device that can select 'yes' or 'no'. Association model that provides the

Also, the Numeric Comparison may be used when at least one of the two devices does not have a display module that can show six digit numbers or an input device that can input six digit numbers.

In this case, however, provide Unauthenticated.

The Passkey Entry association model is used when either device does not have a display device that can show a six digit number while the input device is on, and the other device has a display device that can show a six digit number. Authenticated To provide.

In addition, the Passkey Entry association model is used even when both devices have an input device, and provides Authenticated.

The Out Of Band Association Model can be used when searching for a remote device and utilizing an Out Of Band mechanism (eg NFC) that supports the exchange of cryptographic numbers to be used in the pairing process.

Table 3 below shows an association model applied according to device attributes in Bluetooth LE.

Device properties	Display only	Display Yes / No	Keyboard only	No Input No Output	Keyboard display
Display only	Just Works, Unauthenticated	Just Works, Unauthenticated	Passkey entry -Authenticated	Just Works, Unauthenticated	Passkey entry -Authenticated
Display Yes / No	Just Works, Unauthenticated	Just Works, Unauthenticated	Passkey entry -Authenticated	Just Works, Unauthenticated	Passkey entry -Authenticated
Keyboard only	Passkey entry -Authenticated	Passkey entry -Authenticated	Passkey entry -Authenticated	Just Works, Unauthenticated	Passkey entry -Authenticated
No Input No Output	Just Works, Unauthenticated	Just Works, Unauthenticated	Just Works, Unauthenticated	Just Works, Unauthenticated	Just Works, Unauthenticated
Keyboard display	Passkey entry -Authenticated	Passkey entry -Authenticated	Passkey entry -Authenticated	Just Works, Unauthenticated	Passkey entry -Authenticated

In Table 3, Just Works proceeds without additional input from the user and does not provide authentication.

In addition, the Passkey Entry association model is used when either device has no display device that can show a six digit number but there is an input device, and the other device has a display device that can show a six digit number. Both devices are used when there is an input device.

In this case, authentication is provided.

Hereinafter, a method of performing Secure Simple Pairing (SSP) in Bluetooth communication using a pairing delegation scheme proposed in the present specification will be described.

The pairing delegation method is a method in which a device having no input or output is provided with an input or output by using a third device (pairing delegator) having an input or output. Say

FIG. 9 is a diagram illustrating an example of architectures of Bluetooth BR / EDR and Bluetooth LE that define a pairing delegation service and a profile proposed in the present specification.

The architecture of FIG. 9 includes a controller (module), a host controller interface (HCI), and a host (module).

First, the controller may have the following components.

That is, the controller includes a wireless transceiver module receiving a 2.4 GHz Bluetooth signal and hardware for transmitting or receiving a Bluetooth packet.

Physical layer: A layer that transmits and receives a 2.4 GHz radio signal. It uses Gaussian Frequency Shift Keying (GFSK) modulation and a frequency hopping scheme consisting of 40 RF channels.

-Link Layer: After connecting Advertising and Scanning functions using 3 Advertising Channels, it creates a connection between devices, and provides a function of sending and receiving data packets of up to 42 bytes through 37 Data Channels. It is responsible for security in BR / EDR.

Next, HCI provides an interface between the Host module and the delegator module.

That is, HCI allows the host to provide commands and data to the controller and the controller to provide events and data to the host.

Next, the Host (module) multiplexes various protocols, profiles, etc., provided by the upper level of Bluetooth using Logical Link Control and Adaptation Protocol.

In addition, the host (module) may have the following components.

Logical Link Control and Adaptation Protocol (L2CAP): Provides one bidirectional channel for transmitting data to a specific protocol or profile.

In LE, three fixed channels are used: one for the signaling CH, one for the Security Manager, and one for the Attribute protocol.

The BR / EDR uses a dynamic channel and supports protocol service multiplexer, retransmission, and streaming mode.

-Security Manager: It is a protocol for providing device authentication and key distribution, and is in charge of Security of LE.

-Attribute Protocol (ATT): It is a Server-Client structure that defines a rule for accessing data of the partner device. There are six message types.

-Generic Attribute Profile (GATT): Defines the procedure to get the information with the S / W component of Bluetooth device such as Service, Include, Characteristic, and Behavior and the message defined in ATT Protocol.

Generic Access Profile (GAP): Defines the method for discovering defined devices, connecting them, and providing information to users, and provides privacy.

GATT-based Profiles: Profiles that depend on GATT and are mainly applied to LE devices.

Pairing delegation service & profile: Provides pairing delegation service of Bluetooth.

The pairing delegation service & profile 910 may be expressed as an easy pairing service & profile or may be included in the easy pairing service & profile.

FIG. 10 is a diagram illustrating an example of a method for performing secure simple pairing using a pairing delegator in a Bluetooth architecture proposed in the present specification.

Referring to FIG. 10, a device 1 having only a Bluetooth BR / EDR function, a device 2 having only a BLE function, and a device 3 having a dual mode having both a Bluetooth BR / EDR and a BLE function communicate.

Here, it is assumed that each device has previously defined a pairing delegation service & profile.

In general, the Bluetooth BR / EDR performs Secure Simple Paring at the Link Manager layer, and the Bluetooth LE performs Secure Simple Pairing at the Security Manager layer.

In the case of FIG. 10, device 1 and device 3 can perform Secure Simple Paring in RFCOMM Protocol and Link Manger, and device 2 and device 3 can perform Secure Simple Paring in Link Layer or Attribute Protocol. .

More specifically, pairing delegation command and data can be exchanged as (1) BR / EDR in LCOM message of RFCOMM Protocol or Link Manager, and (2) in case of LE, message can be transmitted through Attribute Protocol or Link Layer. You can give and receive.

The Secure Simple Paring procedure of FIG. 10 is an example, and Secure Simple Paring through the Pairing Delegator proposed in this specification may be performed in another layer of the BR / EDR or the LE other than FIG. 10.

11 is a view comparing the Bluetooth pairing procedure proposed by the present and the present specification.

FIG. 11A illustrates a conventional Bluetooth pairing procedure, and FIG. 11B illustrates a Bluetooth pairing procedure proposed in the present specification.

In the case of FIG. 11A, it is assumed that device 1 is capable of display only, and device 2 is capable of inputting display and yes / no.

In this case, referring to Table 2 or Table 3, the two devices do not provide authentication because they are connected to Just Works.

In this case, by using a pairing delegate (Pairing Delegator or Pairing Agent) having a display and keyboard function as shown in Figure 11b, it is possible to provide authentication between device 1 and device 2.

Each step illustrated in FIG. 11B will be described in more detail.

The connection is performed between the device 1 and the pairing delegator in a authenticated state through a passkey entry algorithm (S1101).

In the case of FIG. 11B, it is assumed that the device 1 and the pairing delegator perform the Bluetooth connection through the BR / EDR. However, it is not limited to BR / EDR but can also be applied to BLE.

Thereafter, Device 1 and Device 2 determine to perform Secure Simple Pairing by using a Passkey entry algorithm, and in Device 2, outputs 6-digit '345345' on the screen (S1102).

Thereafter, Device 1 requests a keyboard to apply a passkey entry algorithm to the pairing delegation device (S1103).

Thereafter, the user inputs a 6 digit number 345345 floated on Device 2 in the paring delegation device, and the pairing delegator transmits the 6 digit number 345345 to Device 1 (S1104).

Subsequently, the device 1 can guarantee authentication with the device 2 by applying the device 2 and the Passkey entry algorithm to the received 6-digit number 345345 (S1105).

As shown in FIG. 11A, the existing pairing procedure is connected to Just Works between device 1 and device 2, and thus is vulnerable to a man-in-the-middle attack because it cannot provide authentication.

However, through the scheme of FIG. 11B, authentication may be provided through a pairing delegation connection between the device 1 and the pairing delegator, thereby making it safe from the MITM attack.

The scheme of FIG. 11B can equally apply to both Bluetooth BR / EDR and BLE.

12 is a flowchart illustrating an example of a pairing delegation protocol using a pairing delegator proposed in the present specification.

Referring to FIG. 12, the (pairing) device 1, the (pairing) device 2, and the pairing delegator perform a device discovery procedure with each other (S1210).

Here, it is assumed that the pairing device 2 is a device without an input / output function.

Thereafter, the pairing device 2 performs a connection procedure with the pairing delegator (S1220).

Refer to the above for the connection procedure of Bluetooth BR / EDR and Bluetooth LE.

That is, the Bluetooth connection is established between the pairing delegator and the paring device 2 through the connection procedure.

Here, the pairing delegator may or may not know the information of Pairing Device 1.

In order to perform the connection procedure, pairing device 2 must support pairing delegation service and control service.

If the pairing device 2 does not support the corresponding service, the pairing delegation protocol may be immediately terminated.

Thereafter, the pairing delegator transmits a pairing delegation status request to the pairing device 2 (S1230).

Pairing delegation status refers to information indicating whether a corresponding device supports pairing delegation and whether the device is currently in pairing delegation state.

Thereafter, the pairing device 2 transmits a pairing delegation status response to the pairing delegator (S1240).

This is for Pairing Device 2 to provide its Paring delegation Status.

Thereafter, the pairing delegator transmits pairing delegation I / O information and pairing delegation security information to the pairing device 2 (S1250).

This is a procedure for transmitting the paring delegation I / O information provided by the paring delegator and the security information to be supported when the pairing delegation function is activated.

Thereafter, the pairing delegator instructs the pairing device 2 to connect to the pairing device 1 through paring delegation (S1260).

Step S1260 may be omitted. If omitted, the pairing device 2 attempts to connect directly to the pairing device 1 after the step S1250.

13 is a flowchart illustrating an example of a pairing delegation protocol in BLE proposed herein.

In FIG. 13, step S1310 refers to FIG. 12 as the procedure described with reference to FIG. 12.

After operation S1310, a Bluetooth connection may be established (or established) between the pairing device 2 and the pairing delegate.

Thereafter, a connection procedure between the pairing device 2 and the pairing device 1 may be performed.

In detail, the pairing device 2 transmits a connection request to the pairing device 1 (S1320).

Next, the pairing device 2 transmits a pairing request to the pairing device 1 (S1330).

Here, the pairing request includes a pairing feature including I / O capability of pairing device 2.

Next, the pairing device 1 transmits a pairing response to the pairing device 2 (S1340).

The pairing response includes a pairing feature including the I / O capability of the pairing device 1.

A pairing algorithm (or association model) to be performed later is determined according to the parameters exchanged through the pairing request and pairing response process (S1350).

Thereafter, the pairing device 2 transmits a pairing delegation request to the pairing delegation (S1360).

That is, this procedure is a procedure for requesting paring delegator for I / O related information required during Secure Simple Pairing process.

In addition, the procedure may be performed in the ATT protocol and / or Link Layer.

Next, the pairing delegator transmits a pairing delegation response to the pairing device 2 in response to the pairing delegation request (S1370).

This procedure is a procedure for transmitting a result value after input or output to an I / O requested by pairing device 2 to the pairing device 2.

Thereafter, the pairing devices 1 and 2 sequentially perform pairing phase 2 and pairing phase 3 (S1380).

That is, the pairing device 2 proceeds with the pairing device 1 and the Phase 2 (Authenticating and Encrypting) and Phase 3 (Transport Specific Key Distribution) procedures with the values input from the pairing delegate, and ends the paring process with the pairing device 1.

As you can see, the messages sent to and from the Pairing Device 2 and the Pairing Delegator can be sent and received using Link Layer messages and Attribute Protocol. However, the present invention is not limited thereto, and messages of different protocols and layers may be used.

14 is a flowchart illustrating an example of a pairing delegation protocol in the Bluetooth BR / EDR proposed in the specification.

Step S1410 of FIG. 14 illustrates the procedure of FIG. 12, and a detailed description thereof will be described with reference to FIG. 12.

That is, a Bluetooth connection may be established between the pairing device 2 and the pairing delegate through step S1410.

Thereafter, the pairing device 2 and the pairing device 1 perform a pairing procedure (S1420).

For paging procedure in BR / EDR, refer to the above.

Thereafter, the pairing device 1 and the pairing device 2 exchange I / O related information with each other (S1430).

Thereafter, the pairing device 2 transmits a pairing delegation request to the pairing delegation to request for I / O (S1440).

That is, the pairing device 2 requests the paring delegator for I / O required during the Secure Simple Pairing process with the pairing device 1 through the corresponding procedure.

Thereafter, the pairing delegator transmits a pairing delegation response to the pairing device 2 in response to the pairing delegation request (S1450).

That is, the pairing delegator inputs or outputs the I / O requested by the pairing device 2, and then transmits a result value to the pairing device 2.

Here, the message exchanged between the pairing device 2 and the pairing delegator may be exchanged using the RFCOMM protocol and the LMP message of the link manager, but is not limited thereto.

That is, as in the method of FIGS. 12 to 14, a device without an I / O function may perform Bluetooth communication with enhanced security with another device through a pairing delegator having an I / O function.

Next, GATT-based characteristics for performing a pairing delegation service are defined.

Table 4 below is a table showing pairing control characteristics.

Characteristic	Requirement	Mandatory properties
Peer device	M	Read, Write, Indication
Agent device	M	Read, Write, Indication
Group info	O	Read, Write, Indication
Device state	M	Read, Write, Indication
Pairing / Connection Control Point	M	Write, Indication
Connection Status	O	Read, Indication
Whitelist	O	Read, Write, Indication
WhiteList Control Point	O	Read, Write, Indication
Bondable	O	Read, Write
Security	M	Read, Write
Pairing Delegation Status	M	Read, Write
Pairing Delegation Security	M	Read, Write
Connected Tech Type	O	Read, Write
Service type	O	Read, Write
Passkey		Read, Write
Scheduled Time		Read, Write

Referring to Table 4, the peer device characteristic uses a relative device address value and a device name to be paired, and provides an address of a paired device through corresponding value setting.

Agent device or pairing delegator is information of an agent device that can control pairing / connection and includes I / O information of agent device for pairing delegation.

Group Info characteristic represents the name or address of a group to which a specific device belongs, and a plurality of group names or addresses can be used.

You can also identify whether a particular device is a group owner or a member.

Device State Characteristic means Ling Layer State (Scanning, Standby, Advertising, Initiating, Connection) of the controlled device, and can specify one state or several states.

In addition, it is possible to request the performance of the device state through write, and to grasp the current state of the device controlled through the read.

In addition, it is possible to grasp the state change of the device controlled through the indication.

Pairing / Connection Control Point is a control point function that indicates what action the controlled device will perform.

The connection status is characteristic for the controlled device to provide connection information to the delegator.

WhiteList is information of devices to which a controlled device can connect.

WhiteList can also be extended to connect with multiple devices as needed.

WhiteList Control Point is a control function to manage the whitelist managed by the controlled device.

Bondable determines whether the controlled device will or will not provide a bonding function.

Security determines whether to provide authentication, authorization, encryption, and data signing functions.

Pairing delegation Status Characteristic indicates whether the device supports pairing delegation, whether the device is currently connected to another pairing delegation, and the like.

Pairing Delegation Security (Mode) Characteristic determines whether to provide authentication, authorization, and encryption functions provided by using pairing delegation.

Connected Tech Type and Service Type indicate the type of communication technology to connect (WiFi, Ethernet, BR / EDR, BLE, etc.) and the connected service type (services defined by Bluetooth and other services (applications)).

The scheduled time represents a time value for requesting a connection at a specific time.

Table 5 shows an example of a peer device information type.

Here, a peer device represents a device that a specific device actually wants to establish a Bluetooth connection.

Data type	Type	Description
Public Device Address	48 bits integer	Original address of the device
Random Device Address	48 bits integer	Random address selected on device
Resolvable Address	48 bits integer	Address encrypted by LE Privacy
Non-Resolvable Address	48 bits integer	Unencrypted address
Bluetooth Device Name	String	Controlled Device friendly Name that is set by the device user

Table 6 is a table showing an example of an Agent Device information type.

In this case, the Agent Device represents another device to control the connection of the device, and may be referred to as a pairing delegator mentioned in the present specification.

Data type	Type	Description
Public Device Address	48 bits integer	Original address of the device
Random Device Address	48 bits integer	Random address selected on device
Resolvable Address	48 bits integer	Address encrypted by LE Privacy
Non-Resolvable Address	48 bits integer	Unencrypted address
Pairing Delegation I / O	8bits	Displays I / O information supported by Agent and expressed in bitmask method
Pairing Delegation Timer	8bits	Timer's time after paring delegation request expires if no response after no response

Table 7 below shows an example of pairing delegation I / O information of an agent device.

7 th bit	6 th bit	5 th bit	4 th bit	3 rd bit	2 nd bit	1 st bit	0 th bit
Reserved	Reserved	Touchdisplay	Keyboard display	NoInputNoOutput	KeyboardOnly	DisplayYesNo	DisplayOnly

In Table 7, the TouchDisplay values are devices that support SoftPattern, which will be described later.

Next, Table 8 shows an example of a pairing / connection control point.

0X01	0X02	0X03	0X04	0X05	0X06	0X07	0X08
Excute	Advertising	Advertising Stop	Scanning start	Scanning stop	Connecting Request	Connecting stop	Refresh Bonding
0X09	0X10	0X11	0X12	0X13	0X14	0X15	0X16
Refresh security	Pairing Request	Pairing Stop	Authentication	Encryption	Authorization	Connecting Request with Pairing delegation

In Table 8, Execute provides states defined in Device States on the device. It can also provide multiple states.

The advertising start indicates the start of the advertising operation when the advertising operation is not performed.

That is, when the advertisement function is immediately started or the advertisement state is deactivated in the device states, the advertisement state is activated.

The advertising stop indicates the end of the advertising operation when the advertising operation is being performed.

 That is, when the advertisement operation is immediately stopped or when the advertisement state is activated in the device states, the advertisement state may be deactivated.

Scanning Start indicates the start of the scanning operation when the Scanning operation is not performed.

That is, when the scanning operation is immediately started or when the scanning state is deactivated in the device states, the scanning state is activated.

Scanning Stop indicates the end of the scanning operation when performing an advertising operation.

That is, when the scanning operation is immediately stopped or the scanning state is activated in the device states, the scanning state may be deactivated.

Connecting Request indicates setting of Peer Device and Connection.

Connection Stop indicates the termination of connection with Peer Device.

Refresh bonding may update the bonding information newly or delete the bonding information.

Refresh security may indicate the re-execution of security procedures (authentication, authorization, encryption) between two devices and the update of security information (key values for each security procedure).

Pairing Request is a request to perform pairing procedure with peer device.

Pairing Stop indicates the end of pairing with Peer Device.

Authentication indicates that authentication with peer device is performed.

Encryption refers to performing encryption with peer device.

Authorization represents the authorization of Peer Device.

Paring delegation indicates that input / out is used as I / O of paring agent to connect when authentication is performed by the Passkey entry algorithm during Security Simple Pairing.

Next, we look at defining Pairing Control Characteristic in Pairing delegation service.

Table 9 is an example of a pairing delegation status.

Pairing Delegation Statu indicates whether the controlled device is currently connected to another Paring delegator.

7 th bit	6 th bit	5 th bit	4 th bit	3 rd bit	2 nd bit	1 st bit	0 th bit
Reserved for Future Use					Pairing delegation device	Pairing delegation enable	Pairing delegation Support

In Table 9, pairing delegation support indicates whether a device is a device capable of pairing delegation.

Pairing delegation enable (disable) / disable (disable) indicates to enable or disable the pairing delegation function running on the device.

Next, we will look at the security and pairing delegation security characteristic.

Security and pairing delegation security have the same data type.

Table 10 shows an example of security and pairing delegation security characteristic and may be expressed in a bitmask format.

In addition, the security and pairing delegation security characteristic may be separated into a security mode and a security level, or may be expressed in a security information 1 or security information 2 manner including both a security mode and a security level. .

Table 10 shows an example of a security mode format.

7 th bit	6 th bit	5 th bit	4 th bit	3 rd bit	2 nd bit	1 st bit	0 th bit
Security Mode 4	Security Mode 3	Security Mode 2	Security Mode 1

Table 11 is a table showing an example of a security level format.

7 th bit	6 th bit	5 th bit	4 th bit	3 rd bit	2 nd bit	1 st bit	0 th bit
Security Level 3	Security Level 2	Security Level 1

Table 12 shows an example of Security Information 1 format including Security Mode and Security Level. Table 12 is applicable to both BR / EDR and LE.

7 th bit	6 th bit	5 th bit	4 th bit	3 rd bit	2 nd bit	1 st bit	0 th bit
Reserved for Future Use		Security Level 3	Security Level 2	Security Level 1	Security Mode 4	Security Mode 3	Security Mode 2	Security Mode 1

Table 13 shows an example of another security information format including security mode and security level. Table 13 is only applicable to Bluetooth LE.

7 th bit	6 th bit	5 th bit	4 th bit	3 rd bit	2 nd bit	1 st bit	0 th bit
Reserved for Future Use	Reserved for Future Use	Reserved for Future Use		Security Mode 2 Level 2	Security Mode 2 Level 1	Security Mode 1 Level 3	Security Mode 1 Level 2	Security Mode 1 Level 1

Next, the pairing delegation packet used for the pairing delegation service will be described.

FIG. 15 is a diagram illustrating an example of a format of a pairing delegation packet proposed in the present specification.

As shown in FIG. 15, the pairing delegation packet 1500 may include a header 1510, an (operation) code 1520, and data 1530.

Table 14 shows an example of the format of a salping pairing delegation request packet, and shows code and data values when the header field is set to '0x01'.

Code	Data	Description
0x00	Timer, none	Just works
0x01	Timer, 000000 ~ 999999 (String)	Numeric Comparison
0x02	Timer, 000000 ~ 999999 (String)	Passkey entry with display
0x03	Timer, none	Passkey entry with keyboard
0x04	Timer, OOB data	OOB (Out of Band)
0x05	Timer, none	Soft pattern
0x06 to	Reserved	Reserved

In Table 14, a timer transmits a pairing delegation request packet to a pairing delegation and indicates a time until a pairing delegation response packet is received.

Table 15 shows an example of a pairing delegation response packet format, and shows code and data values when the header field is set to '0x02'.

Code	Data	Description
0x00	none	Just works
0x01	Yes (0x01), No (0x02)	Numeric Comparison
0x02	none	Passkey entry with display
0x03	000000 to 999999 (String)	Passkey entry with keyboard
0x04	OOB data	OOB (Out of Band)
0x05	Soft Pattern data	Soft pattern
0x06 to	Reserved	Reserved

Salping The header and code values described in FIG. 15, Table 14, and Table 15 may be changed.

As another embodiment proposed in the present specification, a method of performing authentication using a soft pattern in performing a salping pairing delegation service will be described.

16 is a diagram illustrating a general authentication method and an authentication method using a soft pattern method proposed in the present specification, respectively.

FIG. 16A illustrates an authentication method between two existing devices, and FIG. 16B illustrates an authentication method using a soft pattern method proposed in the present specification.

Method 1 of FIG. 16A illustrates an authentication method of a numeric comparison association model, and method 2 illustrates an authentication method of a passkey entry association model.

In the case of FIG. 16B, when the device B outputs a specific pattern, and the device A receives a specific pattern from the user in advance, the device B is changed back to the specific value by a predefined mapping table (or a conversion algorithm) to display both devices. Indicates how to authenticate.

The specific pattern is previously mapped to a specific value and stored in advance in each device.

As shown in Figure 16a, the advantages and disadvantages of the existing Bluetooth communication authentication method (Authentication) method is shown in Table 16.

Classification	pros and cons
Numeric Comparison	Pros: Simple Use Action (Yes button click)
	Disadvantage: User Action is required for both devices to authenticate
Passkey entry	Pros: Authentication is possible only with one device's Use Action.
	Disadvantages: Use Action entering one device is rather difficult (enter the number shown on the other device)

17 is a diagram illustrating an authentication method using a soft pattern proposed in the present specification.

The authentication method using the soft pattern proposed in this specification corresponds to a new authentication method for effectively utilizing only the advantages of the Numeric Comparison and Passkey entry association model shown in Table 16.

The authentication method using the soft pattern of FIG. 17 may be performed in the following five steps.

First, the device B generates a random number for authentication with the device A, and converts the generated random number into a specific pattern that is easily recognized by the user (S1710).

Next, the device B outputs the converted specific pattern through a display and provides the same to the user (S1720).

Next, the user inputs a specific pattern output to the device B into Device A. That is, device A receives a user input of a specific pattern output to device B (S1730).

Thereafter, the device A converts a specific pattern input by the user into a random number for authentication through a predefined mapping table (or a conversion algorithm) (S1740).

If the converted random number is the same as the random number generated in the device B, authentication between the two devices is completed (S1750).

Here, it is assumed that all Bluetooth devices prestore a mapping table or a conversion algorithm that maps a random number for authentication between devices in a form that can be easily recognized by a user.

Next, the pairing delegation setup procedure between the pairing device and the pairing delegator will be described in more detail.

18 is a diagram illustrating an example of a pairing delegation setup procedure proposed in the present specification.

Since S1810 and S1820 are the same as the first and second steps of FIGS. 12 to 14, detailed descriptions thereof will be omitted.

It is assumed that the current pairing device 2 has a pairing delegation state as follows (S1830).

-Pairing delegation Support = '1'

-Pairing delegation Enable (/ Disable) = '1'

-Pairing delegation Status = '0' (currently not connected to another pairing delegate)

Thereafter, the pairing delegator reads the pairing delegation status of the pairing device 2 to determine the pairing delegation status set in the paring device 2 (S1840).

Thereafter, the pairing device 2 transmits Paring delegation Status Info in step S1830 to the pairing delegator (S1850).

That is, the paring delegation status information includes pairing delegation support, enable / disable, and status status of the pairing device 2.

Thereafter, the pairing delegator sets the peer device information as the address of the pairing device 1, and writes the security info corresponding to the paring delegation I / O and the security level provided by the pairing device 2 to the pairing device 2 (S1860). .

In addition, the pairing delegator writes (or transfers) a pairing control point set to a value of 0x15 to the pairing device 2 (S1870).

That is, the pairing delegator requests a connection request to the pairing device 2 while applying paring delegation to the peer device (pairing device 1).

19 is a flowchart illustrating an example of a method for performing an authentication procedure through a passkey entry association model in BLE proposed in the present specification.

In FIG. 19, the pairing device 1 has a display function, and the pairing device 2 has a display or no I / O function.

No I / O means no I / O function.

First, the pairing device 2 and the pairing delegator perform a pairing delegation setup procedure (S1901).

The pairing delegation setting procedure will be described with reference to FIG. 18.

Thereafter, the pairing device 1 and the pairing device 2 perform a connection procedure and an authentication procedure.

In detail, the pairing device 2 transmits a connection request to the pairing device 1 (S1902).

Next, the pairing device 2 transmits a pairing request to the pairing device 1 (S1903).

The pairing request includes I / O capability information of the pairing delegator, that is, paring delegation I / O.

That is, the pairing device 2 transmits a pairing request including pairing delegation I / O information, not its own I / O information, to the pairing device 1.

Pairing Device 1 may not provide a Pairing Control Service.

Next, the pairing device 1 transmits a pairing response to the pairing device 2 (S1904).

Here, the authentication procedure between the pairing devices 1 and 2 is determined as the Passkey Entry according to the parameters exchanged in the pairing request and the pairing response (S1905).

Thereafter, the pairing device 1 outputs a 6-digit random number 123456 to perform authentication with the pairing device 2 (S1906).

Here, the pairing delegator connects to the device to be connected based on the Advertise information of the other device through the Connect Request.

That is, the pairing delegator may confirm that the pairing device 1 performs the connection with the pairing device 2 through the advertisement message of the pairing device 1, and the pairing delegate may directly transmit the connection request to the pairing device 2 based on this.

To this end, the partner device (pairing device 2) must provide a pairing control service, and in the case of pairing device 1, the pairing control service does not need to be supported.

Next, the pairing device 2 transmits a pairing delegation request to the pairing delegation (S1907).

Here, the packet of the pairing delegation request may include a code value in which '0x03' is set.

The code value for which '0x03' is set may be a Passkey entry having a keyboard.

In addition, the packet of the pairing delegation request may include a timer set to 20s.

That is, the pairing device 2 transmits a pairing delegation request to the pairing delegator in order to perform paring by the Passkey entry method, and requests a 6-digit number input.

Next, the pairing delegator inputs a six digit (random) number '123456' outputted from the pairing device 1 received through the pairing device 2 (S1908).

That is, the user looks at the number displayed on the Display of the Pairing Device 1 and inputs the six-digit number '123456' using the keyboard of the Pairing Delegator.

Next, the pairing delegator transmits a pairing delegation response to the pairing device 2 (S1909).

The packet of the pairing delegation response may include Code = 0x03 and Data = '123456'.

In other words, the pairing delegator delivers the 6-digit number '123456' received through the user to the pairing depth 2.

Thereafter, the pairing device 1 and the pairing device 2 perform a pairing phase 2 (Authentication Stage 1) and a phase 3 (Authentication Stage 2) in sequence (S1910).

That is, the pairing device 1 and the pairing device 2 proceed with Phase 2 (Authenticating and Encrypting) and Phase 3 (Transport Specific Key Distribution) received from the pairing delegator and terminate the paring process.

20 is a flowchart illustrating an example of pairing failure between devices due to the expiration of a timer proposed in the present specification.

Since steps S2001 to S2007 are the same as steps S1901 to S1907 of FIG. 19, detailed descriptions thereof will be omitted.

The pairing device 2 transmits a pairing delegation request to the pairing delegation (S2007), and if it does not receive a pairing delegation response from the pairing delegation until the corresponding timer expires, it expiring a pairing delegation request (S2008).

Therefore, pairing between pairing device 1 and pairing device 2 fails.

21 is a flowchart illustrating an example of an authentication method using a soft pattern proposed in the present specification.

S2101 to S2103 are the same as S2001, S2003, and S2004 in FIG. 20, and thus detailed description thereof will be omitted.

The pairing device 1 outputs a specific pattern changed according to a specific rule (mapping table, conversion algorithm) to the display without outputting a 6-digit random number (S2104).

That is, FIG. 21 relates to a method for performing authentication of a Bluetooth device by converting a Passkey (Random number) into a Pattern that is easily recognized and input by a user in the Passkey Entry method.

Next, the pairing device 2 transmits a pairing delegation request including Code = 0x05 and Timer = 20s to the pairing delegator (S2105).

Next, the pairing delegator receives a specific pattern output to the pairing device 1 from the user (S2106).

Thereafter, the pairing delegator converts a specific pattern input by a specific rule (mapping table, conversion algorithm, etc.) into a six-digit random number 123456 (S2107).

Thereafter, the pairing delegator receives a pairing delegation response including Code = 0x05 and Data = 123456 to the pairing device 2 (S2108).

Thereafter, the pairing devices 1 and 2 sequentially perform pairing phase 2 and phase 3 (S2109).

22 is a diagram illustrating an example of an authentication method using a number comparison association model in the Bluetooth BR / EDR proposed in the specification.

First, the pairing device 2 and the pairing delegator perform a pairing delegation setup procedure (S2201). That is, the pairing device 2 and the pairing delegator transmit and receive pairing delegation state information.

In the case of FIG. 22, the pairing device 1 is Display Yes / No, and the pairing device 2 has a Display Only or No I / O function. And, the pairing delegator corresponds to the client.

Pairing device 1 and pairing device 2 performs a pairing procedure (S2202).

Next, the pairing device 1 and the pairing device 2 exchange I / O capabilities information (S2203).

Specifically, the pairing device 2 transmits a pairing request to the pairing device 1 including pairing delegation I / O information, not its own I / O information.

Here, pairing device 1 may not provide a pairing control service.

Next, pairing device 1 and pairing device 2 perform Secure Simple Pairing (SSP) Phase 1 (S2204).

SSP Phase 1 is a procedure for exchanging a public key.

Thereafter, SSP Phase 2 is performed.

Let's take a closer look at SSP Phase 2.

First, pairing device 1 and pairing device 2 respectively generate a random number, calculate a HMAC algorithm, exchange the calculated values with each other, and calculate a hash algorithm based on the exchanged values to generate a six-digit number. (S2205).

Next, the pairing device 1 outputs a six digit number '123456' for Numeric Comparison on the display (S2206).

Next, the pairing device 2 transmits a pairing delegation request to the pairing delegation (S2207).

The pairing delegation request includes Code = 0x01, Data = '123456', Timer 20s.

That is, the pairing device 2 transmits a 6-digit number to the pairing delegation for the Numeric Comparison method, and requests pairing delegation.

Thereafter, the pairing delegate outputs '123456' to the display and checks Yes or No input from the user (S2208).

Here, the pairing delegator checks the 6-digit number printed on the Pairing Device 1 and the 6-digit number printed on the Pairing Delegator from the user, and if it is the same, the user receives Yes.

Here, the order of the selection input of Yes or No by the user in the pairing device 1 and the selection input of Yes or No in the pairing delegator may be changed.

Here, assume that the user input is Yes.

Thereafter, the pairing delegator transmits a pairing delegation response to the pairing device 2 (S2209).

The pairing delegation response includes Code = 0x01, Data = 'Yes' information.

That is, the pairing delegator transfers the result “Yes” received from the user to the pairing device 2.

Thereafter, the user checks whether the six-digit number output on the pairing device 1 and the six-digit number output on the pairing delegate are the same and select Yes or No.

That is, the pairing device 1 receives a Yes or No input from the user (S2210).

If Yes is received, SSP Phase 2 by Numeric Comparison between the pairing device 1 and the pairing device 2 ends.

Thereafter, the pairing device 1 and the pairing device 2 perform SSP phases 3 to 5 (S2211).

Here, SSP Phase 3 is Authentication Stage 2, SSP Phase 4 is Link key calculation, SSP Phase 5 corresponds to LMP Authentication and Encryption, and corresponding procedures are performed in order.

FIG. 23 illustrates an example of an authentication method using a Passkey Entry in the Bluetooth BR / EDR proposed in the specification.

In FIG. 23, the pairing device 1 may display, have a Yes / No function, and the pairing device 2 may have a Display Only or a No I / O function.

And, the pairing delegator corresponds to the client.

Since steps S2301 to S2304 are the same as steps S2201 to S2204 of FIG. 22, a detailed description thereof will be omitted.

Next, the SSP Phase 2 is performed and this will be described in detail.

The pairing device 1 outputs a passkey 6 digit '123456' on the display (S2305).

Thereafter, the pairing device 2 transmits a pairing delegation request to the pairing delegation (S2306).

The pairing delegation request includes code = 0x03 and Timer = 20s.

Thereafter, the pairing delegator receives a passkey '123456' output from the pairing device 1 from the user (S2307).

Next, the pairing delegator transmits a pairing delegation response (including Code = 0x03 Data = '123456') to the pairing device 2 (S2308).

It is assumed that the pairing delegation response arrives before the timer included in the pairing delegation request expires.

Thereafter, the pairing device 1 and the pairing device 2 generate a random number, calculate the HMAC algorithm, and exchange the calculated values with each other (S2309).

Based on the value exchanged with the existing Passkey value, the authentication value is proved by running the HMAC algorithm again.

Thereafter, the pairing device 1 and the pairing device 2 perform SSP phases 3 to 5 (S2310).

Further, for convenience of description, the drawings are divided and described, but it is also possible to design a new embodiment by merging the embodiments described in each drawing. And, according to the needs of those skilled in the art, it is also within the scope of the present invention to design a computer-readable recording medium having a program recorded thereon for executing the embodiments described above.

The data transmission and reception method using the isochronous channel according to the present disclosure is not limited to the configuration and method of the embodiments described above, the embodiments are all or all of the embodiments so that various modifications can be made Some may be optionally combined.

On the other hand, the data transmission and reception method using the isochronous channel of the present disclosure can be implemented as a processor-readable code on a processor-readable recording medium provided in the network device. The processor-readable recording medium includes all kinds of recording devices that store data that can be read by the processor. Examples of the processor-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, and the like, and may also be implemented in the form of a carrier wave such as transmission over the Internet. . The processor-readable recording medium can also be distributed over network coupled computer systems so that the processor-readable code is stored and executed in a distributed fashion.

In addition, while the above has been shown and described with respect to preferred embodiments of the present specification, the present specification is not limited to the specific embodiments described above, the technical field to which the invention belongs without departing from the spirit of the invention claimed in the claims. Of course, various modifications can be made by those skilled in the art, and these modifications should not be individually understood from the technical spirit or the prospect of the present invention.

In addition, in this specification, both the object invention and the method invention are described, and description of both invention can be supplementally applied as needed.

The present specification uses a method of performing pairing using Bluetooth, which is a short range low power wireless technology.

Claims (16)

1. In a method for performing pairing between devices in a wireless communication system supporting Bluetooth communication, the method performed by the first device,
   Performing device discovery;
   Performing a pairing delegation setup procedure with the second device to perform authentication with the third device via a second device having an input and / or output function;
   Exchanging input and / or output capability information with the third device;
   Determining an association model used for authentication with the third device;
   Sending a first message to the second device for requesting an input and / or output required for authentication with the third device; And
   Receiving from the second device a second message comprising a result of the requested input and / or output.
2. The method of claim 1,
   The first message is a pairing delegation request message.
   The second message is a pairing delegation response message.
3. The method of claim 1,
   The performing of the pairing delegation setup procedure may include:
   Receiving a request for pairing delegation status from the second device; And
   And sending pairing delegation status information to the second device in response to the request.
4. The method of claim 3, wherein
   The pairing delegation state information includes a pairing delegation support field indicating whether pairing delegation is supported, a field for enabling or disabling pairing delegation function, or a pairing delegation state indicating whether it is currently connected with another pairing delegator. and at least one of a status field.
5. The method of claim 1,
   And receiving from the second device input and / or output related information supported by the second device and security information supported when the pairing delegation function is activated.
6. The method of claim 5,
   The input and / or output related information supported by the second device is represented by a bitmask method.
7. The method of claim 5,
   The security information is a method characterized in that the information indicating whether at least one of the authentication (Authentication), Authorization (Authorization) or Encryption (Encryption) function provided.
8. The method of claim 5,
   The security information comprises at least one of a security mode or a security level.
9. The method of claim 1,
   The pairing delegation setup procedure,
   In case of Bluetooth BR / EDR, it is performed through RFCOMM Protocol or Link Manager.
   In the case of Bluetooth LE, the method is performed through an attribute protocol or a link layer.
10. The method of claim 1,
    The association model (association model) is characterized in that any one of numeric comparison (Passkey Entry), Out of Band (Numeric Comparison).
11. The method of claim 1,
    The first message may include at least one of code information indicating a type of association model for authentication or timer information serving as a criterion for determining success or failure of pairing delegation.
12. The method of claim 11,
    The timer is started upon transmission of the first message,
    Failure of the delegation delegation,
    The second message is not received from the second device until the timer expires.
13. The method of claim 1,
    The result of the input and / or output is a value converted into a specific value according to a certain rule in a specific pattern,
    The specific value is a six-digit random number (six digits random number) used for the passkey (Passkey Entry).
14. The method of claim 13,
    The specific pattern is a pattern input by a user in the second device and the third device.
15. The method of claim 1,
    And said first device is a device without input and / or output functionality.
16. A first device for performing pairing in a wireless communication system supporting Bluetooth communication,
    Communication unit for communicating with the outside by wireless or wired; And
    Including a processor that is functionally connected with the communication unit, The processor,
    Perform device discovery;
    Perform a pairing delegation setup procedure with the second device to perform authentication with the third device via a second device having an Input and / or Output function;
    Exchange input and / or output capability information with the third device;
    Determine an association model used for authentication with the third device;
    Send a first message to the second device to request an input and / or output required for authentication with the third device; And
    Control to receive from the second device a second message comprising a result of the requested input and / or output.

Images