WO2018124852A1 - 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치 - Google Patents

블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치 Download PDF

Info

Publication number
WO2018124852A1
WO2018124852A1 PCT/KR2018/000058 KR2018000058W WO2018124852A1 WO 2018124852 A1 WO2018124852 A1 WO 2018124852A1 KR 2018000058 W KR2018000058 W KR 2018000058W WO 2018124852 A1 WO2018124852 A1 WO 2018124852A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
characteristic
value
information
changed
Prior art date
Application number
PCT/KR2018/000058
Other languages
English (en)
French (fr)
Inventor
권영환
Original Assignee
엘지전자(주)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자(주) filed Critical 엘지전자(주)
Priority to US16/475,598 priority Critical patent/US10721611B2/en
Publication of WO2018124852A1 publication Critical patent/WO2018124852A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/005—Discovery of network devices, e.g. terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0215—Traffic management, e.g. flow control or congestion control based on user or device properties, e.g. MTC-capable devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/14—Direct-mode setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/20—Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/18—Interfaces between hierarchically similar devices between terminal devices

Definitions

  • the present invention relates to a method and apparatus for controlling a device using Bluetooth, which is a short-range technology in a wireless communication system, and more particularly, to a method and apparatus for controlling the formation of a device-to-device connection through a Bluetooth technology.
  • Bluetooth is a short-range wireless technology standard that can transmit and receive data by wirelessly connecting various devices in a short distance.
  • a user When performing wireless communication between two devices using Bluetooth communication, a user performs a procedure of searching for a Bluetooth device and requesting a connection. do.
  • the device may mean an apparatus and an apparatus.
  • the user may perform a connection after searching for the Bluetooth device according to the Bluetooth communication method to use using the Bluetooth device.
  • the Bluetooth communication method includes a basic rate / enhanced data rate (BR / EDR) method and a low energy (LE) method, which is a low power method.
  • the BR / EDR scheme may be referred to as Bluetooth Classic.
  • the Bluetooth classic includes Bluetooth technology that has been adopted since Bluetooth 1.0 using Basic Rate and Bluetooth technology that has used Enhanced Data Rate supported since Bluetooth 2.0.
  • Bluetooth Low Energy (hereinafter referred to as Bluetooth LE) technology has been applied since Bluetooth 4.0, and can consume hundreds of kilobytes (KB) of information stably with low power consumption.
  • the Bluetooth low energy energy technology uses an attribute protocol to exchange information between devices. This Bluetooth LE method can reduce energy overhead by reducing the header overhead and simplifying the operation.
  • Some Bluetooth devices do not have a display or a user interface.
  • the complexity of connection / management / control / disconnection between various kinds of Bluetooth devices and similarly applied Bluetooth devices is increasing.
  • Bluetooth can achieve a relatively high speed at a relatively low power, low cost, but the transmission distance is generally limited to a maximum of 100m, it is suitable for use in a limited space.
  • Another object of the present invention is to provide a method and apparatus for notifying a control device of a change in characteristic information when the controlled device has changed characteristic information.
  • Another object of the present invention is to provide a method and apparatus for acquiring changed characteristic information when the characteristic information of devices controlled by the control device is changed.
  • Another object of the present invention is to provide a method and apparatus for acquiring the remaining characteristic information through an additional message when the characteristic information of devices controlled by the control device is greater than or equal to a predetermined size.
  • the present invention provides a method for a first device to search for a service using Bluetooth in a wireless communication system to solve the above problem.
  • a method for a first device to search for a service includes: establishing a Bluetooth LE connection with a second device; Receiving a first message indicating whether to change a service supported by the second device from the second device; And searching for at least one of a service or a characteristic of the service based on the first message, wherein the first message is a first value related to a change of a service supported by the second device and a characteristic of the service. A second value associated with the change of the value.
  • the searching may include determining whether the service has been changed based on the first value; Searching for the changed service when the first value indicates a change of the service; Determining whether the characteristic value has changed based on the second value; And if the second value indicates a change in the property value, searching for the changed property value.
  • the first value is a first hash value representing the service
  • the second value is a second hash value representing the property value
  • the present invention may further include determining whether the first hash value or the second hash value has changed.
  • the present invention searches for a service indicated by the first hash value.
  • the characteristic value represented by the second hash value is searched for.
  • the present invention includes the steps of searching for a primary service supported by the second device; And searching for a characteristic value of the discovered primary service.
  • the present invention also provides a method comprising: transmitting a read request message to the second device requesting reading of a characteristic value of a first characteristic for compatibility with the second device; And receiving a read response message including a first characteristic value of the first characteristic in response to the read request message, wherein the first characteristic value is at least one function supported by the second device. Indicates.
  • the read request message includes a second characteristic value of a second characteristic for compatibility with the first device, and the second characteristic value includes at least one function supported by the first device. Indicates.
  • the step of transmitting a write request message requesting the writing of the first characteristic value of the first characteristic for compatibility with the first device to the second device the first characteristic value is the first characteristic value; Indicate at least one function supported by the device; And receiving a write response message comprising a second characteristic value of a second characteristic for compatibility with the second device in response to the write request message, wherein the second characteristic value is the second characteristic value. Indicates at least one function supported by the device.
  • the 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 form a Bluetooth LE connection with a second device and to indicate whether to change a service supported by the second device from the second device.
  • a device is provided that includes a second value associated with a change in value.
  • the size of the characteristic information is greater than or equal to a certain size, by notifying the control device that the characteristic information remains, there is an effect that the remaining information can be obtained through an additional message.
  • the control device when the service information of the controlled devices is changed, there is an effect that the control device can obtain only the changed service information by transmitting to the control device which service information the changed information is.
  • the controlling device may obtain only the changed characteristic information by transmitting which characteristic information is the changed characteristic information to the control device.
  • control device has the effect of being able to recognize a change in the service and the characteristic value of the controlled devices.
  • the control device when the service and feature values of the controlled devices are changed, the control device can recognize the changed service and feature through the discovery procedure.
  • the present invention has the effect of improving the compatibility of the control device and the controlled device by exchanging information related to the function supported between the control device and the controlled device.
  • FIG. 1 is a schematic diagram illustrating an example of a wireless communication system using a Bluetooth low power energy technology to which the present invention can be applied.
  • FIG. 2 shows an example of an internal block diagram of a device to which the present invention can be applied.
  • FIG 3 shows an example of a Bluetooth low power energy topology to which the present invention can be applied.
  • FIG. 4 is a diagram illustrating an example of a Bluetooth communication architecture to which the present invention can be applied.
  • FIG. 5 is a diagram illustrating an example of a structure of a GATT (Generic Attribute Profile) of Bluetooth low power energy to which the present invention can be applied.
  • GATT Generic Attribute Profile
  • FIG. 6 is a flowchart illustrating an example of a connection procedure method in a Bluetooth low energy technology to which the present invention can be applied.
  • FIG. 7 is a diagram briefly illustrating a method for controlling another device through a control device to which the present invention can be applied.
  • FIGS. 8 and 9 are diagrams illustrating an example of a profile structure for providing a service for controlling a device to which the present invention can be applied.
  • FIG. 10 is a diagram illustrating an example of a structure of service information indicating a service for controlling a device to which the present invention can be applied.
  • 11 and 12 are flowcharts illustrating an example of a method for searching for information of a primary service to which the present invention can be applied.
  • FIG. 13 is a flowchart illustrating an example of a method for searching for information of an included service related to a primary service.
  • FIG. 14 is a flowchart illustrating an example of a method for obtaining service information of devices by a controller proposed by the present invention.
  • 15 to 17 are diagrams showing examples of characteristics related to a service in which a device proposed by the present invention operates as a client.
  • FIG. 18 is a diagram illustrating an example of characteristics related to a service in which a device proposed by the present invention operates in a server role.
  • 19 is a flowchart illustrating an example of a method for transmitting and receiving characteristic information through a plurality of messages when the characteristic information proposed by the present invention has a predetermined size or more.
  • 20 and 21 are diagrams showing examples of characteristics related to the structure of a service proposed by the present invention.
  • 22 is a flowchart illustrating an example of a method for transmitting and receiving changed service information when information related to a service proposed by the present invention is changed.
  • 23 is a flowchart illustrating an example of a method for transmitting and receiving additional information through a plurality of messages when the characteristic information proposed in the present invention may provide additional information.
  • 24 is a flowchart illustrating an example of a method for transmitting and receiving changed characteristic information when characteristic information proposed by the present invention is changed.
  • 25 and 26 are diagrams showing examples of characteristics related to whether the characteristic information proposed by the present invention is changed.
  • 27 and 28 are diagrams illustrating an example of a method and a data format for recognizing whether a service and a characteristic proposed by the present invention are changed.
  • 29 to 31 are diagrams showing an example of an attribute for recognizing whether a service and a characteristic proposed by the present invention are changed.
  • 32 to 34 are flowcharts illustrating an example of a method for recognizing whether a service and a property are changed through an attribute proposed by the present invention.
  • 35 to 37 are diagrams showing an example of function information for improving compatibility between devices proposed by the present invention.
  • 38 and 39 are flowcharts illustrating an example of a method for improving compatibility between devices proposed by the present invention.
  • 40 and 41 are flowcharts illustrating still another example of a method for improving compatibility between devices proposed by the present invention.
  • 43 is a flowchart illustrating an example of a method for recognizing whether a service and a characteristic proposed by the present invention are changed.
  • FIG. 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 120 and at least one client device 110.
  • the server device and the client device perform Bluetooth communication using Bluetooth Low Energy (BLE) technology.
  • BLE Bluetooth Low Energy
  • BLE technology 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.
  • BR / EDR Bluetooth Basic Rate / Enhanced Data Rate
  • the BLE technology simplifies the connection procedure between devices, and the packet size is smaller than that of the Bluetooth BR / EDR technology.
  • the number of RF channels is 40
  • the data rate supports 1Mbps
  • the topology is a scatternet structure
  • latency is 3ms
  • (6) output power is less than 10mW (10dBm)
  • (7) is mainly used in applications such as mobile phones, watches, sports, healthcare, sensors, device control.
  • the server device 120 may operate as a client device in relation to other devices, and the client device may operate as a server device in relation to other devices. 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 120 may include a data service device, a slave device device, a slave, a server, a conductor, a host device, a gateway, and a sensing device. (Sensing Device), a monitoring device (monitoring device), the first device, the second device and the like.
  • the client device 110 may be a master device, a master, a client, a member, a sensor device, a sink device, a collector, a third device, a fourth device, or the like. Can be expressed.
  • 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 When the server device receives data from the client device and directly communicates with the client device, and receives a data request from the client device, the server device provides the data to the client device through a response.
  • the server device sends a notification message and an indication message to the client device to provide data information to the client device.
  • the server apparatus transmits an instruction message to the client apparatus, the server apparatus receives a confirmation message corresponding to the instruction message from the client.
  • 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, instruction, and confirmation messages with the client device. can do.
  • 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.
  • one server device may be connected to a plurality of client devices, and may be easily reconnected (or connected) with client devices by using bonding information.
  • the client device 120 refers to a device 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.
  • 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.
  • the client device may read data from a memory or write new data to a corresponding memory in a 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.
  • the wireless communication system may configure Personal Area Networking (PAN) through Bluetooth technology.
  • PAN Personal Area Networking
  • the wireless communication system by establishing a private piconet between devices, files, documents, and the like can be exchanged quickly and securely.
  • FIG. 2 shows an example of an internal block diagram of a device that can implement the methods proposed herein.
  • the server device may include 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.
  • the client device may include a display 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).
  • Bluetooth Interface Bluetooth Interface
  • 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.
  • ASICs application-specific integrated circuits
  • the processor 114, 124 controls the communication unit to receive an advertising message from a server device, transmits a scan request message to the server device, and scans in response to the scan request from the server device.
  • the communication unit controls the communication unit to receive a scan response message, and controls the communication unit to transmit a connect request message to the server device for establishing a Bluetooth connection with the server device.
  • the processor 114 and 124 may also read or write data from the server device using a property protocol after a Bluetooth LE connection is formed through the connection procedure. To control.
  • 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.
  • ROM read-only memory
  • RAM random access memory
  • 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.
  • 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 refers to a module for supplying power required for the operation of the components by receiving the external power, the internal power under the control of the controller.
  • BLE technology has a small duty cycle, and the low data rate can significantly reduce power consumption.
  • 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.
  • FIG. 3 shows an example of a Bluetooth low power energy topology.
  • device A corresponds to a master in a piconet (piconet A, shaded portion) having device B and device C as slaves.
  • 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.
  • 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.
  • 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 the advertiser and device O is the initiator (group R).
  • Devices A and B use one BLE piconet physical channel.
  • Devices A and C use another BLE piconet physical channel.
  • 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.
  • 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.
  • devices K and L use one BLE piconet physical channel.
  • Devices K and M use another BLE piconet physical channel.
  • device K advertises using an advertisement event connectable onto an advertising physical channel
  • device N is an initiator.
  • Device N may form a connection with device K.
  • device K becomes a slave of two devices and simultaneously becomes a master of one device.
  • devices O and P use one BLE piconet physical channel.
  • Devices O and Q use another BLE piconet physical channel.
  • 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.
  • device O becomes a slave of two devices and simultaneously becomes a master of one device.
  • FIG. 4 is a diagram illustrating an example of a Bluetooth communication architecture to which the methods proposed herein may be applied.
  • FIG. 4 shows an example of a protocol stack of Bluetooth Basic Rate (BR) / Enhanced Data Rate (EDR), and (b) shows a protocol stack of Bluetooth Low Energy (LE). An example is shown.
  • BR Basic Rate
  • EDR Enhanced Data Rate
  • LE Bluetooth Low Energy
  • the Bluetooth BR / EDR protocol stack may be configured based on a host controller interface (HCI) 18. It may include a host stack (20).
  • HCI host controller interface
  • the host stack (or host module) 20 refers to a wireless transceiver module for receiving a 2.4 GHz Bluetooth signal and hardware for transmitting or receiving a Bluetooth packet. Control and perform actions.
  • the controller stack 10 may include a PHY layer 12, a link controller layer 14, and a link manager layer 16.
  • the PHY layer 12 is a layer that transmits and receives a 2.4 GHz radio signal.
  • PFS layer Global System for Mobile Communications
  • the PHY layer 12 may transmit data by hopping 79 RF channels.
  • the link controller layer 14 is responsible for transmitting a digital signal, selects a channel sequence hopping 1400 times per second, and transmits a 625us length time slot for each channel.
  • the link manager layer 16 controls the overall operation (link setup, control, security) of the Bluetooth connection by using a link manager protocol (LMP).
  • LMP link manager protocol
  • the link manager layer 16 may perform the following functions.
  • the host controller interface layer 18 provides an interface between the host module and the controller module so that the host can provide commands and data to the controller, and the controller can provide events and data to the host.
  • the host stack (or host module) 20 may include a logical link control and adaptation protocol (L2CAP, 21), an attribute protocol (Protocol, 22), a generic attribute profile (GATT, 23), and a generic access profile. Profile, GAP, 24), BR / EDR profile 25.
  • L2CAP logical link control and adaptation protocol
  • Protocol 22
  • GATT generic attribute profile
  • GAP BR / EDR profile
  • the logical link control and adaptation protocol (L2CAP) 21 may provide one bidirectional channel for transmitting data to a specific protocol or profile.
  • the L2CAP 21 may multiplex various protocols, profiles, etc. provided by a higher 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 generic attribute profile (GATT) 23 may be operable as a protocol describing how the attribute protocol 22 is used in the construction of services.
  • the general attribute profile 23 may be operable to specify how ATT attributes are grouped together into services, and may be operable to describe features associated with the services.
  • the generic attribute profile 23 and the attribute protocol ATT 22 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 attribute protocol 22 and the BR / EDR profile 25 define a service profile using Bluet BR / EDR and an application protocol for sending and receiving these data, and the Generic Access Profile. , GAP, 24) defines device discovery, connectivity, and security levels.
  • the Bluetooth LE protocol stack is a controller stack 30 operable to handle timing-critical radio interface and a host operable to process high level data. It contains a stack (Host stack, 40).
  • the controller stack 30 may be implemented using a communication module that may include a Bluetooth radio, for example, a processor module that may include a processing device such as 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.
  • controller stack and the host stack can be operated or executed on the same processing device in the processor module.
  • the controller stack 30 includes a physical layer (PHY) 32, a link layer 34, and a host controller interface 36.
  • PHY physical layer
  • link layer 34 link layer
  • host controller interface 36 host controller interface
  • the physical layer (PHY) 32 is a layer that transmits and receives a 2.4 GHz radio signal and uses GFSK (Gaussian Frequency Shift Keying) modulation and a frequency hopping technique composed of 40 RF channels.
  • GFSK Gausian Frequency Shift Keying
  • the link layer 34 which transmits or receives a Bluetooth packet, creates a connection between devices after performing advertising and scanning functions using three advertising channels, and generates up to 257 bytes of data packets through 37 data channels. Provides the ability to send and receive.
  • the host stack includes a logical link control and adaptation protocol (L2CAP, 41), a security manager (SM, 42), an attribute protocol (Attribute Protocol, ATT, 43), a generic attribute profile (GATT, 44). It may include a Generic Access Profile (45), LE Profile (46). However, the host stack 40 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.
  • L2CAP Logical Link Control and Adaptation Protocol 41 may provide one bidirectional channel for transmitting data to a specific protocol or profile.
  • the L2CAP 41 may be operable to multiplex data among higher layer protocols, segment and reassemble packages, and manage multicast data transmission.
  • Bluetooth LE In Bluetooth LE, three fixed channels (one for the signaling channel, one for the Security Manager, and one for the Attribute protocol) are used by default. And, if necessary, the dynamic channel may be used.
  • BR / EDR Base Rate / Enhanced Data Rate
  • the SM (Security Manager) 42 is a protocol for authenticating a device and providing key distribution.
  • Attribute Protocol (ATT) 43 defines a rule for accessing data of a counterpart device in a server-client structure. ATT has six message types (Request, Response, Command, Notification, Indication, Confirmation).
  • the Request message is a message for requesting and delivering specific information from the client device to the server device
  • the Response message is a response message for the request message, which can be used for transmission from the server device to the client device.
  • Command message A message sent mainly 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 a confirmation message for the Indication message to the server device.
  • the generic access profile 45 is a newly implemented layer for Bluetooth LE technology and is used to control role selection and multi-profile operation for communication between Bluetooth LE devices.
  • the general access profile 45 is mainly used for device discovery, connection creation, and security procedures, and defines a method of providing information to a user, and defines the type of an attribute as follows.
  • UUID Universal Unique Identifier, value type
  • the LE profile 46 is mainly applied to a Bluetooth LE device as profiles having a dependency on GATT.
  • the LE profile 46 may include, for example, Battery, Time, FindMe, Proximity, Time, and the like. Details of GATT-based Profiles are as follows.
  • the generic attribute profile GATT 44 may be operable as a protocol describing how the attribute protocol 43 is used in the construction of services.
  • the generic attribute profile 44 may be operable to specify how ATT attributes are grouped together into services, and may be operable to describe features associated with the services.
  • the generic attribute profile 44 and the attribute protocol may use features to describe the state and services of a device, and how features relate to each other and how they are used.
  • 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.
  • 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.
  • 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.
  • 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.
  • the scanning device when the scanning device receives some advertising packets from the advertising device, the scanning device should send a scan request to the advertising device.
  • 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.
  • the advertising device performs an advertising procedure to perform a non-directional broadcast to the devices in the area.
  • non-directional broadcast refers to broadcast in all directions rather than broadcast in a specific direction.
  • Non-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.
  • the advertising procedure may be used to provide periodic broadcast of user data to the scanning devices that are listening on the advertising 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.
  • 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 data from the advertising device.
  • the advertising device transmits a scan response that is a response to the scan request, including additional 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.
  • the scanning device 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.
  • the scanning device 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.
  • Bluetooth devices 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 another device around it is called a discovering device and listens for devices that advertise a scannable advertisement event.
  • 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.
  • 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.
  • the advertising procedure can be the goal, so that only one device will respond to the advertising.
  • the connection may be initiated by sending a connection request to the advertising device via the advertising (broadcast) physical channel.
  • the link layer LL enters the advertisement state by the instruction of the host (stack). If the link layer is in the advertisement state, the link layer sends advertisement packet data units (PDUs) in the advertisement events.
  • PDUs advertisement packet data units
  • 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.
  • 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.
  • scanning states There are two types of scanning states: passive scanning and active scanning, each scanning type being determined by the host.
  • ScanInterval is defined as the interval (interval) between the starting points of two consecutive scan windows.
  • 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.
  • the link layer When passive scanning, the link layer only receives packets and does not transmit any packets.
  • the link layer 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.
  • the link layer enters the initiation state by the indication of the host (stack).
  • the link layer When the link layer is in the initiating state, the link layer performs listening for the advertising channel indexes.
  • the link layer listens for the advertising channel index during the scan window period.
  • 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.
  • connection 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.
  • 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.
  • BLE devices use the packets defined below.
  • 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.
  • the PDU 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 PDU (Advertising Channel PDU )
  • the advertising channel PDU Packet Data Unit
  • PDU Packet Data Unit
  • the PDU type field of the advertising channel PDU included in the header indicates a PDU type as defined in Table 1 below.
  • Advertising PDU (Advertising PDU )
  • 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.
  • 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.
  • 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.
  • the data channel PDU has a 16-bit header, payloads of various sizes, and may include a message integrity check (MIC) field.
  • MIC message integrity check
  • the procedure, state, packet format, etc. in the BLE technology may be applied to perform the methods proposed herein.
  • FIG. 5 is a diagram illustrating an example of a structure of a GATT (Generic Attribute Profile) of Bluetooth low power energy.
  • GATT Generic Attribute Profile
  • the GATT Generic Attribute Profile
  • a peripheral device for example, a sensor device serves as a GATT server, and has a definition of a service and a characteristic.
  • the GATT client sends a data request to the GATT server, and all transactions begin at the GATT client and receive a response from the GATT server.
  • the GATT based operation structure used in the Bluetooth LE is based on a profile, a service, and a characteristic, and may form a vertical structure as shown in FIG. 5.
  • the profile consists of one or more services, and the service may consist of one or more features or other services.
  • the service divides data into logical units and may include one or more characteristics or other services.
  • Each service has a 16-bit or 128-bit identifier called the Universal Unique Identifier (UUID).
  • UUID Universal Unique Identifier
  • the characteristic is the lowest unit in the GATT based operation structure.
  • the property contains only one data and has a UUID of 16 bits or 128 bits similar to the service.
  • the property is defined as a value of various pieces of information and requires one attribute to contain each piece of information. Multiple properties of the above properties can be used.
  • the attribute consists of four components and has the following meaning.
  • Type the type of attribute
  • the present invention proposes a method for controlling a device by acquiring information related to controllable operation and combination information of a device to be controlled by a control device through the GATT.
  • FIG. 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 (S6010).
  • the server may be called an advertiser before connection, and may be called a master after connection.
  • An example of the server may be a sensor (temperature sensor, etc.).
  • the client may be called a scanner before the connection, and may be called a slave after the connection.
  • An example of the client may be a smartphone.
  • Bluetooth communicates over 40 channels across the 2.4 GHz band.
  • Three of the 40 channels are advertising channels, and are used for exchanging packets, including various advertising packets, to establish a connection.
  • the remaining 37 channels are used for data exchange after connection to the data channel.
  • the client may transmit a scan request message to the server to obtain additional data (eg, a server device name) to the server.
  • additional data eg, a server device name
  • the server transmits a scan response message including additional data to the client in response to a scan request message.
  • the Scan Request message and the Scan Response message are one end of the advertisement packet, and the advertisement packet may include only User Data of 31 bytes or less.
  • the data size is larger than 3 bytes, but there is a large data overhead for sending data through connection, the data is divided twice using Scan Request message / Scan Response message.
  • the client transmits a Connection Request message for establishing a Bluetooth connection with the server to the server (S6020).
  • the server and client then perform a security establishment procedure.
  • the security establishment procedure may be interpreted as or included in Secure Simple Pairing.
  • the security establishment procedure may be performed through Phase 1 to Phase 3 steps.
  • a pairing procedure (Phase 1) is performed between the server and the client (S6030).
  • the client transmits a pairing request message to the server, and the server transmits a pairing response message to the client.
  • the pairing procedure exchanges authentication requirements, I (Input) / O (output) capabilities, and Key Size information between devices. This information determines which key generation method to use in Phase 2.
  • Phase 2 a legacy pairing or a secure connection is performed between the server and the client (S6040).
  • STK Temporary Key and Short Term Key
  • STK Short Term Key
  • LTK long term key
  • LTK Long Term Key
  • SSP Phase 3 a key distribution procedure is performed between the server and the client (S6050).
  • FIG. 7 is a diagram briefly illustrating a method for controlling another device through a control device to which the present invention can be applied.
  • a controller 500 is required, and the third device 500 is connected to the first device ( A new control protocol is needed to control the association of 300 and the second device 400.
  • the controller 500 needs to know information (eg, interface information, service information, etc.) of the devices in order to control the operation of the devices.
  • information e.g, interface information, service information, etc.
  • Bluetooth establishes a connection between devices and then searches for a service (application) provided by the actual device.
  • Bluetooth SIG standardizes various applications differently from other connection technologies. Therefore, even if the same Bluetooth product is provided, if the applications provided are different, the device cannot interpret the received data. Can't.
  • devices must establish a Bluetooth connection and then identify the services they provide.
  • the current service discovery method of Bluetooth only provides server-based information, so a controller that is a third device cannot find a device that performs a client role in a specific service. There is a problem that can not determine whether it is provided.
  • the present invention provides a method for discovering an apparatus in which a controller performs a client role and a method for a client to check and receive only changed data when data of a server is changed to solve the problem.
  • FIGS. 8 and 9 are diagrams illustrating an example of a profile structure for providing a service for controlling a device to which the present invention can be applied.
  • a service for controlling another device by the control device may be included in a profile of other services or may be defined as a separate profile.
  • an easy pairing service a service for controlling other devices by the control device.
  • the controller 500 that controls the devices may control other devices through the easy pairing service.
  • the controller 500 may control operations related to coupling (eg, connection, pairing, or bonding) between the first device 300 and the second device 400 through an easy pairing service.
  • the easy pairing service may be included in a profile of another service as shown in FIG. 8 or may be defined as a separate profile as shown in FIG. 9.
  • the easy pairing service is not defined as a separate profile as shown in FIG. 8 and is included in a profile of a specific service (for example, the easy pairing service is a secondary service (or included service) related to another primary service).
  • the easy pairing service is a secondary service (or included service) related to another primary service.
  • the easy pairing service cannot be applied to a service of a profile not including the easy pairing service, and roles between devices must be clearly defined.
  • the easy pairing service when defined as a separate profile (for example, the easy pairing service is not associated with another primary service, and may be an independent primary service or secondary service (or, server / client structure is compatible at the profile level, and the easy pairing service can be extended to another profile.
  • the easy pairing service when defined as a separate profile (for example, the easy pairing service is not associated with another primary service, and may be an independent primary service or secondary service (or, server / client structure is compatible at the profile level, and the easy pairing service can be extended to another profile.
  • FIG. 10 is a diagram illustrating an example of a structure of service information indicating a service for controlling a device to which the present invention can be applied.
  • the easy pairing service may be defined as a primary service or an included service.
  • the easy pairing service When the easy pairing service is defined as a primary service, it may have the following characteristics.
  • the UUID of the base service supported by the server must be included as a client function.
  • the supported client list is used by the connection manager to match common service functions between targets.
  • the easy pairing service is defined as an included service of a specific service defined as a primary service
  • the specific service related to the easy pairing service may be searched through the characteristics shown in FIG. 10.
  • the characteristic illustrated in FIG. 10 is a characteristic for recognizing the information of the primary service of the easy pairing service, and may be configured with a service type field, a service type UUID, and a security requirements filed.
  • Service Type indicates the type (or length) of the followed primary service UUID.
  • primary service UUID indicates the primary service UUID including the Easy Pairing service. The length may vary depending on the UUID value of the service.
  • Security Requirements Represents the security requirements for the primary service.
  • 0x02 Not authenticated with encryption, pairing by Just Works Pairing method without Connection Manager.
  • 0x03 Secure connection through connection manager authenticated with encryption.
  • 11 and 12 are flowcharts illustrating an example of a method for searching for information of a primary service to which the present invention can be applied.
  • a client may discover a primary service of a server.
  • 11 is a flowchart illustrating an example of a method for a client to discover all primary services of a server.
  • a client may search for all primary services of a server through a primary service discovery procedure.
  • An attribute type group type request read by an attribute may be used with the attribute type parameter set to the UUID for the primary service.
  • the Starting Handle is set to 0x0001 and the Ending Handle is set to 0xFFFF.
  • Read By Group Type Request Two possible responses can be sent from the server: Read By Group Type Response and Error Response.
  • Read By Group Type Response returns a list of attribute handles, end group handles, and attribute value tuples corresponding to services supported by the server.
  • Each property value included in the response is a service UUID of the service supported by the server, and the property handle is the handle of the service declaration.
  • End Group Handle is the handle of the last attribute in the service definition, and the end group handle of the last service on the device can be 0xFFFF.
  • the Read By Group Type Request must be called again with the Start Handle set to one greater than the last End Group Handle of the Read By Group Type Response.
  • This subprocedure is completed when an error response is received and the error code is set to ⁇ no attributes found '' or the final group handle of the type-specific read group response is 0xFFFF.
  • FIG. 12 is a flowchart illustrating an example of a method for discovering specific primary services of a server when the client knows a universal unique identifier (UUID) of the service.
  • UUID universal unique identifier
  • a plurality of specific basic services may exist in duplicate in the server, and the found basic services are identified by the service UUID.
  • An Attribute Protocol Find By Type Value Request is made if the Attribute Service Type parameter is set to UUID for ⁇ primary service >> and the attribute value is set to 16-bit Bluetooth UUID or 128-bit UUID of a specific base service.
  • the Starting Handle is set to 0x0001 and the Ending Handle is set to 0xFFFF.
  • the server can send two possible responses: Find By Type Value Response and Error Response. If an error occurs in the server, an error response is returned.
  • the attribute handle range is the start handle and the end handle of the service definition, and the end group handle of the last service on the device can be 0xFFFF.
  • Find By Type Value Reques can be called again by setting the start handle to one greater than the last property handle range in the Find By Type Value Response. .
  • This sub-procedure is completed when an error response is received and the error code is set to «attribute not found» or the final group handle is 0xFFFF in the type-specific value lookup.
  • FIG. 13 is a flowchart illustrating an example of a method for searching for information of an included service related to a primary service.
  • an Attribute Protocol Read By Type request may be used together with an Attribute Type parameter set to UUID for «Include».
  • Start Handle is set to the starting handle of the specified service
  • Ending Handle is set to the ending handle of the specified service. If a desired included service is found before searching for all included services included in the specified service supported by the server, the procedure may be terminated early.
  • Read By Type Response returns a set of attribute handles and attribute value pairs that correspond to the contained services in the service definition.
  • Each attribute value included in the response may consist of an attribute handle and an end group handle of the included service declaration. If the service UUID is a 16-bit Bluetooth UUID, it is also returned in the response.
  • the Read By Type Request is called again with the Start Handle set to one greater than the last Attribute Handle in the Read By Type Response.
  • the subprocess completes when an error response is received with an error code set to no attribute or when the attribute handle of the service declaration included in the type-specific read response is the same as the end handle of the request.
  • a read request is used to get the included service UUID.
  • the property handle of the read request is the property handle of the included service.
  • the service discovery takes a long time due to the stepped service discovery, and due to the different UUID lengths (eg, 16 bit, 32 bit, 128 bit, etc.) between services. There is a problem that the service cannot be searched continuously.
  • the service changed indication function may be indicated without changing the client characteristic configuration.
  • the present invention provides a method for transmitting and receiving a service and a method for directly searching for a specific service when the length of service information is long to solve such a problem.
  • the service can be continuously searched, and if the data of the service is changed, a method for immediately recognizing this is proposed.
  • FIG. 14 is a flowchart illustrating an example of a method for obtaining service information of devices by a controller proposed by the present invention.
  • the controller acquires information of services in which each device operates as a client role or a server role, and controls a device performing a client role and a device performing a server role in a specific service to form a connection. have.
  • the first device 300 transmits an advertising message in the advertising channel so that neighboring devices can search for the first device 300 (S14010).
  • the advertising message may include information of services supported by the first device 300.
  • the first device 300 may continue to transmit the advertising message.
  • the controller 500 may discover the first device 300.
  • the controller 500 discovers the first device 300.
  • a connection request message is transmitted to the first device 300 to establish a Bluetooth LE connection.
  • the controller 500 may search for a device for forming a Bluetooth LE connection with the first device 300.
  • the controller 500 may receive an advertising message transmitted through advertising channels to search for a device supporting Bluetooth LE.
  • the controller 500 may discover a second device 400 (S14030).
  • the controller 500 connects to the second device 400 when the second device 400 is a device to which the second device 400 is connected, for example, when the second device provides easy pairing service.
  • the request message is transmitted to form a Bluetooth LE connection with the second device 400 (S14040).
  • the controller 500 needs to determine what role each device performs in a specific service in order to connect the first device 300 and the second device 400.
  • the controller 500 transmits a read request message or a read by type request message to the first device 300 requesting information on characteristics of at least one service in which the first device 300 operates as a client (S14050). ).
  • client list characteristic information information included in the client list characteristic
  • controller 500 If the controller 500 does not know the handle value of the property in step S14050, it sends a Read By Type Request message including the UUID of the property to the first device 300, and if it knows the handle value of the property, the handle value is sent. Send a Read Request message that contains.
  • the Read By Type Request message when the Read By Type Request message is transmitted, the Read By Type Request message may include a UUID of the characteristic, a Starting Handle number to start reading, and an Ending Handle number to end reading.
  • the first device 300 receiving the read by type request message or the read request message from the controller 500 transmits a read by type response message or read response message including client list characteristic information to the controller 500 (S14060). .
  • the read by type response message may include a data list of a characteristic and a length of data.
  • the controller 500 which has obtained information of at least one service capable of serving as a client from the first device 300, checks whether there are services in which the second device 400 can operate as a server.
  • the Read Request message or the Read By Type Request message is transmitted (S14070).
  • the controller 500 transmits a read request message or a read by type request message to the second device 400 requesting information on characteristics of at least one service in which the second device 400 operates as a role.
  • Server List Characteristic a characteristic related to at least one service acting as a server role
  • Server List Characteristic Information information included in the Server List Characteristic
  • controller 500 If the controller 500 does not know the handle value of the characteristic in step S14070, it sends a Read By Type Request message including the UUID of the characteristic to the first device 300, and if the handle value of the characteristic is known, the handle value is sent. Send a Read Request message that contains.
  • the Read By Type Request message when the Read By Type Request message is transmitted, the Read By Type Request message may include a UUID of the characteristic, a Starting Handle number to start reading, and an Ending Handle number to end reading.
  • the Second Device 400 Upon receiving the Read By Type Request message or the Read Request message from the Controller 500, the Second Device 400 transmits a Read By Type Response message or Read Response message including Server List Characteristic Information to the Controller 500 (S14080). .
  • the read by type response message may include a data list of a characteristic and a length of data.
  • the controller 500 obtains information of the services in which the first device 300 operates as a client through steps S14050 and S14060, and the services of the second device 400 acting as a server through steps S14070 and S14080. Information can be obtained.
  • the controller 500 may connect the first device 300 and the second device 400 through Bluetooth LE, and the first device.
  • the 300 and the second device 400 may provide a specific service after the connection of the Bluetooth LE is formed.
  • the controller 500 may obtain information of services for which the device may perform a specific role, and control the connection to be formed according to the role of each device based on the obtained service information.
  • 15 to 17 are diagrams showing examples of characteristics related to a service in which a device proposed by the present invention operates as a client.
  • the Client List Characteristic described in FIG. 14 includes information of each service according to bits of the UUID.
  • Client List Characteristic may provide list information of all client functions provided by a device.
  • Client List Characteristic may provide information about a function defined as a primary service and information about a function defined as an included service.
  • the controller 500 can check the client function that can be provided by the device by reading the Client List Characteristic through a Read Request message.
  • the Client List Characteristic should be written by the Device System, and an external device (for example, an unauthorized device, etc.) cannot write the Client List Characteristic value.
  • the 16-bit UUID List field, 32-bit UUID List field, and 128-bit UUID List field of Client List Characteristic can provide 16bit / 32bit / 128bit information, which is the basic unit, continuously.
  • Client List Characteristic may be provided as Characteristic of Easy Pairing service or as basic Characteristic of GATT Profile.
  • Controller 500 uses the Read Request By UUID Procedure, it is possible to immediately request data without Characteristic Discovery.
  • Client List Characteristic may include the following fields.
  • Client List Information UUID information of the service acting as the Client role included in the property.
  • 16bit UUID List List of 16bit UUID information.
  • 128bit UUID List List of 128bit UUID information.
  • the Client List Characteristic illustrated in FIG. 15 includes all the information of the services in which the device may perform a client function according to bits.
  • FIG. 16 illustrates an example of Client List Characteristic different from FIG. 15.
  • Client List Characteristic may be configured with different characteristics according to each bit.
  • information of services having a 16-bit UUID value consists of one characteristic
  • information of services having a 32-bit UUID value consists of another characteristic
  • information of services having a 128-bit UUID value is another characteristic. It may consist of one characteristic.
  • the size of the message can be reduced because a separate characteristic value is read out for each bit.
  • the structure of the characteristic illustrated in FIG. 16 may be used as the structure of the Server List Characteristic described with reference to FIG. 14.
  • FIG. 17 illustrates an example of Client List Information included in the Client List Characteristic illustrated in FIG. 15.
  • Client List Information provides UUID information of a service acting as a Client included in the property.
  • Client List Information indicates whether a UUID of each bit exists.
  • a 0th bit indicates whether a 16 bit UUID exists
  • a 1th bit indicates whether a 32 bit UUID exists
  • a 2th bit indicates whether a 128 bit UUID exists.
  • 16bit UUID information exists, and Num of 16bit UUID List fields and 16bit UUID List fields exist.
  • 0th bit is 0, 16bit UUID information does not exist, and Client List Characteristic does not include a Num of 16bit UUID List field and a 16bit UUID List field.
  • 1th bit when 1th bit is 1, 32 bit UUID information exists, and there are Num of 32 bit UUID List fields and 32 bit UUID List fields. However, if 1th bit is 0, 32bit UUID information does not exist, and Client List Characteristic does not include a Num of 32bit UUID List field and a 32bit UUID List field.
  • 128 bit UUID information exists, and there are Num of 128 bit UUID List fields and 128 bit UUID List fields.
  • 2th bit is 0, 128bit UUID information does not exist, and Client List Characteristic does not include a Num of 128bit UUID List field and a 128bit UUID List field.
  • 17B illustrates another structure of the Client List Information field.
  • each bit is defined as follows.
  • -5th bit: 1 indicates that 16bit UUID exists, but it is not possible to provide list information of all services. Thus, by requesting the additional information, it is possible to obtain information of services allocated with the 16-bit UUID.
  • 6th bit: 1 indicates that there is a 32bit UUID, but cannot provide list information of all services. Thus, by requesting the additional information, it is possible to obtain information of services allocated with the 32-bit UUID.
  • 7th bit: 1 indicates that there is a 128bit UUID, but it cannot provide list information of all services. Therefore, by requesting the additional information it is possible to obtain the information of the services assigned the 128-bit UUID.
  • FIG. 17C illustrates another structure of the Client List Information field.
  • each field is defined as follows according to bits.
  • 0b00 No information for 16bit UUID.
  • 0b01 Provides complete 16bit UUID information
  • 0b10 Provides incomplete 16bit UUID information. If additional information is requested, additional information may be provided.
  • 0b11 Provides incomplete 16-bit UUID information but cannot provide additional information.
  • 0b01 Provides full 32bit UUID information
  • 0b10 Provides incomplete 32bit UUID information and can provide additional information if requested.
  • 0b11 Provides incomplete 32-bit UUID information but cannot provide additional information.
  • 0b01 Provides complete 128bit UUID information
  • 0b10 Provides incomplete 128bit UUID information and can provide additional information if requested.
  • 0b11 Provides incomplete 128bit UUID information but cannot provide additional information.
  • FIG. 18 is a diagram illustrating an example of characteristics related to a service in which a device proposed by the present invention operates in a server role.
  • FIG. 18A illustrates an example of Server List Characteristic, which is a characteristic related to at least one service in which the device described with reference to FIG. 14 operates in a server role
  • FIG. 18B illustrates a field included in Server List Characteristic. An example of this is shown.
  • the Server List Characteristic described in FIG. 14 includes information of each service according to bits of the UUID.
  • Server List Characteristic may provide list information of all Server functions provided by a device.
  • Server List Characteristic may provide information about a function defined as a primary service and information about a function defined as an included service.
  • the controller 500 may check the server function that can be provided by the device by reading the server list characteristic through a read request message.
  • Server List Characteristic should be written by Device System, and external device (for example, unauthorized device, etc.) cannot write Server List Characteristic value.
  • the 16-bit UUID List field, the 32-bit UUID List field, and the 128-bit UUID List field of the Server List Characteristic can provide 16bit / 32bit / 128bit information, each basic unit, continuously.
  • Server List Characteristic can be provided as Characteristic of Easy Pairing service or as basic Characteristic of GATT Profile.
  • Controller 500 uses the Read Request By UUID Procedure, it is possible to immediately request data without Characteristic Discovery.
  • Server List Characteristic may include the following fields.
  • -Server List Information UUID information of service acting as Server role included in the property.
  • 16bit UUID List List of 16bit UUID information.
  • 128bit UUID List List of 128bit UUID information.
  • the Server List Characteristic illustrated in FIG. 18A includes all the information of services for which a device can perform a client function according to bits.
  • the Server List Characteristic may be configured with separate characteristics according to bits of each UUID as shown in FIG. 16.
  • FIG. 18B illustrates an example of Server List Information included in Server List Characteristic illustrated in FIG. 18A.
  • Server List Information provides the UUID information of the service acting as the Server role included in the property as described above. That is, Server List Information indicates whether a UUID of each bit exists.
  • a 0th bit indicates whether a 16 bit UUID exists
  • a 1th bit indicates whether a 32 bit UUID exists
  • a 2th bit indicates whether a 128 bit UUID exists.
  • 16bit UUID information exists, and Num of 16bit UUID List fields and 16bit UUID List fields exist.
  • 0th bit is 0, 16bit UUID information does not exist, and Client List Characteristic does not include a Num of 16bit UUID List field and a 16bit UUID List field.
  • 1th bit when 1th bit is 1, 32 bit UUID information exists, and there are Num of 32 bit UUID List fields and 32 bit UUID List fields. However, if 1th bit is 0, 32bit UUID information does not exist, and Client List Characteristic does not include a Num of 32bit UUID List field and a 32bit UUID List field.
  • 128 bit UUID information exists, and there are Num of 128 bit UUID List fields and 128 bit UUID List fields.
  • 2th bit is 0, 128bit UUID information does not exist, and Client List Characteristic does not include a Num of 128bit UUID List field and a 128bit UUID List field.
  • the server list information may have a structure as shown in FIG. 17 (b) or (c).
  • 19 is a flowchart illustrating an example of a method for transmitting and receiving characteristic information through a plurality of messages when the characteristic information proposed by the present invention has a predetermined size or more.
  • the characteristic information when the length of the characteristic information is greater than or equal to a certain length, the characteristic information may be divided into a predetermined length and received.
  • step S19010 and step S19020 are the same as step S14010 and step S14020 of Figure 14 will be omitted.
  • the controller 500 which forms a connection through the first device 300 and the Bluetooth LE, is a first device 300, and the information of the client list characteristic, which is a characteristic related to at least one service in which the first device 300 acts as a client, is displayed.
  • the request Read by Type Request message or Read Request Message is transmitted (S19030).
  • the Read by Type Request message may include a UUID of Client List Characteristic.
  • the first device 300 includes the client list characteristic characteristic information in a read by type response message when the length of the characteristic information of the client list characteristic is greater than or equal to a predetermined length (for example, longer than the length that can be included in the message). Cannot transmit to the Controller 500.
  • a predetermined length for example, longer than the length that can be included in the message.
  • the first device 300 transmits an error response message including error information indicating why the characteristic information cannot be transmitted to the controller 500 and handle information of the client list characteristic to the controller 500 (S19040).
  • the error information may indicate that the length of the characteristic information cannot be transmitted through a Read by Type Response message because the length of the characteristic information is longer than a predetermined length.
  • the controller 500 transmits the read blob request message including the handle information and the offset included in the error message to receive and transmit the characteristic information of the client list characteristic to the first device 300 (S19050).
  • the offset included in the first Read Blob Request message is zero.
  • the first device 300 transmits the data of the requested handle value through the read blob request message to the controller 500 by including it in the read blob response message from the offset position (S19060).
  • the length of information that can be transmitted through the Read Blob Response message is equal to the value of ATT_MTU.
  • the controller 500 transmits a read blob request message to the first device 300 for additionally requesting information that has not been transmitted (S19070).
  • the offset included in the read blob request message transmitted in step S19070 indicates the position of data to be transmitted in consideration of the length of the information received by the controller 500 (for example, the controller 500 indicates 50 bytes). If received, the offset represents the value 51).
  • the first device 300 transmits a read blob response message including information of a length greater than that indicated by ATT_MTU from the position indicated by the offset to the controller 500 (S19080).
  • feature information having a size greater than or equal to a certain size may also be transmitted over multiple transmissions.
  • 20 and 21 are diagrams showing examples of characteristics related to the structure of a service proposed by the present invention.
  • the device may obtain information on a primary service of the counterpart device and information on an included service related to the primary service by acquiring information on a characteristic indicating a structure of services that may be provided by the counterpart device. have.
  • Structure Information Characteristic a characteristic indicating the structure of services.
  • Structure Information Characteristic may include structure information of all services that can be provided by a device.
  • the controller 500 transmits the read request message to the first device 300 or the second device 400, and the characteristic information of the structure information characteristic included in the read response message transmitted from the first device 300 or the second device 400. (Second characteristic information) can be obtained.
  • the controller 500 provides the client function or the server function that can be provided by the first device 300 or the second device 400 at a time through the characteristic information of the structure information characteristic obtained from the first device 300 or the second device 400. You can check it.
  • Structure Information Characteristic should be written by Device System, and external device (eg, unauthorized device, etc.) cannot write Structure Information Characteristic value.
  • the Structure Information Characteristic may include the following fields.
  • # of primary service Number of primary services.
  • Length of primary service This is a field indicating the length of the primary service and indicates the length from the primary service1 type to the information of the plurality of included services as shown below.
  • primary service information (primary service1 Type, primary service1 UUID, Start handle, End Handle)
  • primary service Type UUID type of the primary service.
  • UUID UUID (16bit / 32bit / 128bits) of the primary service.
  • Start Handle of primary service1 Start handle of primary service.
  • End Handle of primary service1 End handle of primary service.
  • -Length of included service1 This indicates the length of the included service and means the length from the included service type to the end handle.
  • included service1 Type UUID type of included service 1.
  • UUID UUID (16bit / 32bit / 128bits) of included service.
  • Start Handle of included service Start handle of included service.
  • End Handle of included service1 End handle of included service1.
  • the End Handle of included service field may be repeated by the value of the # of primary service from the Length of primary service field of FIG. 19.
  • FIG. 21 illustrates an example of Structure Information Characteristic when two primary services are provided when the value of # of primary service is 2.
  • FIG. 20B illustrates an example of a primary service type field or an included service type field of structure information characteristic.
  • each bit is defined as follows.
  • 7th bit a bit indicating whether a primary service or an included service. For example, 0b0 may indicate a primary service, and 0b1 may indicate an included service.
  • 6th bit A bit that indicates whether there is a change in the information of a service known through the 7th bit. For example, 0b0 may indicate that there is no change, and 0b1 may indicate that there is a change.
  • 1st bit and 0th bit A bit that indicates the number of UUID bits of the service that can be known through the 7th bit. For example, in case of 0b10, it may represent a 128 bit UUID list, in case of 0b01, it may indicate a 32 bit UUID list, and in case of 0b00, it may indicate a 16bit UUID list.
  • the controller or the client can know which service information has changed, and can read only the information of the service having changed.
  • the controller 500 or the client may know that the information of the primary service has changed, and from the start handle to the end handle of the corresponding service. By reading again, the changed information can be obtained.
  • the controller 500 or the client may be notified that the characteristic value is changed by changing the hash value of each characteristic.
  • the controller 500 or the client may recognize that the information of the specific characteristic is changed, and by reading the information of the characteristic again, the changed information may be obtained. Can be.
  • 22 is a flowchart illustrating an example of a method for transmitting and receiving changed service information when information related to a service proposed by the present invention is changed.
  • the device may recognize that the information of the specific service has changed by reading a characteristic indicating the same, and may request and receive the information of the changed service.
  • step S22010 and step S22020 are the same as step S14010 and step S14020 of FIG. 14, description thereof will be omitted.
  • the Controller 500 establishes the Bluetooth LE connection with the First Device 300, and then uses the First Device 300 to understand the structure of all services that the First Device 300 operates as a Client.
  • a Read by Type Request message requesting the reading of Structure Information Characteristic, which is a characteristic represented, is transmitted.
  • the Read by Type Request message may include a UUID of Structure Information Characteristic.
  • the first device 300 transmits a read by type response message including the characteristic information of the structure information characteristic to the controller 500 when the characteristic information of the structure information characteristic can be transmitted through the read by type response message (S22040). ).
  • the characteristic information of the Structure Information Characteristic may be transmitted to the Controller 500 through the method described with reference to FIG. 19.
  • the controller 500 that has received the characteristic information from the first device 300 may recognize whether the information of the primary service or the included service of the first device 300 is changed through the service type field described in FIG. 20 (b). There is (S22050).
  • the controller 500 transmits a read blob request message to the first device 300 to request the changed service information (S22060).
  • the read blob request message may include a handle value of the changed characteristic and an offset indicating the position of the changed data.
  • the first device 300 transmits the data of the changed characteristic to the controller 500 through the read blob response message by the length of ATT_MTU from the offset position (S22070).
  • the controller 500 may recognize whether information of any service is changed and may receive only the changed data.
  • 23 is a flowchart illustrating an example of a method for transmitting and receiving additional information through an additional request when the characteristic information proposed in the present invention can provide additional information.
  • the controller 500 or the client may transmit the request message for requesting the additional information to obtain the additional information.
  • step S23010 and step S23020 are the same as step S14010 and step S14020 of FIG. 14, description thereof will be omitted.
  • the controller 500 that forms the connection through the first device 300 and the Bluetooth LE is the first device 300 and the client list characteristic, which is a characteristic related to at least one service in which the first device 300 functions as a client.
  • a Read by Type Request message or a Read Request Message requesting information is transmitted (S23030).
  • the first device 300 transmits a read by type response message including the characteristic information of the client list characteristic to the controller 500 (S23040).
  • the controller 500 may recognize whether additional information exists through the client list information field.
  • each UUID list is 0b01 or 0b11
  • the controller 500 recognizes that the first device 300 cannot provide additional information, and the procedure ends.
  • the controller 500 recognizes that the first device 300 has transmitted incomplete information.
  • the controller 500 recognizes that the first device 300 transmits only some information of the client list characteristic and may transmit additional characteristic information of the client list characteristic (S23050).
  • the controller 500 transmits a Read by Type Request message requesting additional information to the first device 300, and sends a Read by Type Response message including additional information to the First Device ( 300) (S23060, S23070).
  • the additional information may be requested by transmitting the UUID value of the corresponding property in a Read by Type Request message.
  • the read by type response message may include the length and data of the attribute having the UUID included in the read by type request message.
  • additional information may be received by recognizing whether additional information exists in a specific characteristic and whether additional information may be provided.
  • 24 is a flowchart illustrating an example of a method for transmitting and receiving changed characteristic information when characteristic information proposed by the present invention is changed.
  • the device may read a specific characteristic to recognize whether the characteristic information has changed and acquire the changed characteristic information.
  • step S24010 and step S24020 are the same as step S14010 and step S14020 of Figure 14 will be omitted.
  • the controller 500 which has established the Bluetooth LE connection with the first device 300, checks whether the characteristic value of the first device 300 has been changed. It sends a Read by Type Request message requesting (S24030).
  • changed characteristic list characteristic a characteristic related to whether or not the characteristic value is changed
  • changed characteristic list characteristic information information included in the changed characteristic list characteristic
  • the Read by Type Request message may include the UUID of the Changed Characteristic list Characteristic.
  • the first device 300 transmits a read by type response message including the length and data of the attribute to which the UUID of the changed characteristic list characteristic is allocated (S24040).
  • the controller 500 may determine whether there is a characteristic whose value is changed among the characteristics of the first device 300 through the value of the changed characteristic list characteristic (S24050).
  • the controller 500 transmits a read request message requesting the changed characteristic value to the first device 300 (S24060).
  • the Read Request message may include Handle information of the changed characteristic.
  • the first device 300 transmits a read response message including the value of the property to which the UUID requested from the controller 500 is assigned to the controller 500 (S24070).
  • the controller 500 may recognize that the characteristic value of the first device 300 has been changed, and may receive the changed characteristic value.
  • the controller 500 may repeatedly receive steps S24060 and S24070 to receive a plurality of changed characteristic values.
  • the characteristics may use a specific handle value as the common characteristic.
  • 25 and 26 are diagrams showing examples of characteristics related to whether the characteristic information proposed by the present invention is changed.
  • the changed characteristic list characteristic described with reference to FIG. 24 may include information related to a changed characteristic in a device.
  • the device may include only one changed characteristic list characteristic.
  • the changed characteristic list characteristic provides a characteristic change of a service for each specific service
  • the changed characteristic list characteristic may exist for each service.
  • the changed characteristic information can be known from the server, and the changed characteristic information can be selectively read.
  • the client reconnecting to the server can reduce the connection time and data transmission time by reading the changes without performing characteristic discovery again.
  • the information of the property should be written for each Devic or each service, and the external device (for example, unauthorized device, etc.) cannot write the value of Structure Information Characteristic.
  • FIG. 25A illustrates an example of a structure of a changed characteristic list characteristic.
  • the changed characteristic list characteristic may include the following fields.
  • Handle of Characteristic The handle value (position value) of the characteristic whose information has changed.
  • Changed Contents Changes that indicate characteristic changes.
  • the Handle of Characteristic field and the Changed Contents field are repeated by the value of the Number Of Changed Characteristic field.
  • FIG. 25B illustrates an example of the Changed Contents field in FIG. 25A.
  • the 1th bit is '1', it indicates that the declaration part of the characteristic has been changed. If it is '0', it means that it has not been changed.
  • the Changed Method field indicates whether to add, delete, or change the characteristic.
  • each bit value of the Changed Method can be defined as follows.
  • -0b00 Added (Indicates that a new characteristic has been created, and both the 0th and 1st bits must have a value of '0'. Also, the client must read the value from the server anew).
  • Deleted Indicates that the existing characteristic has been deleted. Both 0th and 1st bits must have a value of '0'. Also, the client must delete the stored characteristic value.
  • -0b10 Modified (Indicates that the existing characteristic has been changed, and indicates that the value or declaration part has been changed according to the values of 0th and 1st bit. The client should read the changed part newly from the server.
  • FIG. 26A illustrates another example of a structure of a changed characteristic list characteristic.
  • the changed characteristic list characteristic may include the following fields.
  • -UUID type This indicates the characteristic UUID type and can define the characteristic UUID type included in the following fields (for example, 01 is 16 bit UUID, 02 is 32 bit UUID, 03 is 128 bit UUID). Can be displayed).
  • Changed Contents Changes that indicate characteristic changes.
  • the UUID type field, the UUID of Characteristic field, and the Changed Contents field are repeated as many as the value of the Number Of Changed Characteristic field.
  • FIG. 26B illustrates an example of a Changed Contents field in FIG. 26A, and is the same as FIG. 25B, and thus description thereof will be omitted.
  • 27 and 28 are diagrams illustrating an example of a method and a data format for recognizing whether a service and a characteristic proposed by the present invention are changed.
  • the client which is a control device controlling the devices, may recognize and search for this.
  • the client searches for all services through the service search and property search procedure.
  • the client may receive information indicating the change of the service and the change of the data from the server, respectively, and search only for the changed service and / or data according to the received information.
  • the specific characteristic of the server may include a characteristic value indicating that the service of the server and the data of the service are changed.
  • the characteristics indicating the service of the server and the data of the service are referred to as the changed information characteristic.
  • the changed information property may include a service modification field and a characteristic value modification field as shown in FIG. 28.
  • the service modification field is a field indicating whether a service of a server is changed.
  • the service modification field represents addition of a new service, deletion of an existing service, and addition and deletion of new characteristics of a service.
  • the client can recognize that the service of the server has changed.
  • the characteristic value modification field is a field indicating whether data of a service is changed, and indicates a change of a characteristic value related to the service without changing the service.
  • the client may recognize that the value of the characteristic related to the specific service has changed.
  • the client may receive a message including the property value of the Changed information property from the server (S27010).
  • the client may transmit a read request message requesting the characteristic value of the Changed information characteristic to the server, and receive a read response message including the characteristic value of the Changed information characteristic in response thereto.
  • the server may send an indication message including the characteristic value of the Changed information characteristic to the client.
  • the client that has received the property value of the Changed information property from the server determines whether the service of the server has been changed based on the received property value (S27020).
  • the client may perform a service search procedure and a property search procedure to search for a service of the changed server, and if there is a property whose property value is changed, the client may acquire a changed property value by performing a read procedure. (S 27030).
  • the client determines whether the value of the characteristic related to the service of the server has been changed (S27040).
  • the client may obtain the property value by reading the changed property value (S27050). If the property value is not changed, the client does not perform the search procedure and the read procedure.
  • the message transmitted in step S27010 may include a hash value indicating a service and a characteristic.
  • the client may receive a message including a first hash value indicating a service of a server and a second hash value indicating a characteristic related to the service.
  • the client may determine whether the service and the characteristic of the server have changed based on the first hash value and the second hash value, and if the service and the characteristic have changed, perform a procedure for searching for the changed service and / or the changed characteristic. Can be.
  • the client may recognize that the service of the server indicated by the first hash value has changed. In this case, the client may search for whether the service indicated by the first hash value has been added, deleted or changed by performing a procedure for searching for a service of the changed server.
  • the client may recognize that the characteristic represented by the second hash value has changed. In this case, the client may perform a feature search procedure to search for the changed feature, and obtain the value of the changed feature through the reading procedure.
  • the client may acquire the changed property value without having to search the entire service again, thereby reducing the delay of the discovery procedure.
  • 29 to 31 are diagrams showing an example of an attribute for recognizing whether a service and a characteristic proposed by the present invention are changed.
  • a field indicating whether to change a property may be added to determine whether a value of a service and a property has changed.
  • a service is a collection of data and related operations for performing a specific function or function.
  • services are defined by service definitions, which can include referenced services, required properties, and optional properties.
  • the primary service is a service that provides a function basically available on the device, and may be included in other services.
  • the primary service may be discovered through a primary service discovery procedure.
  • a secondary service is a service that is referenced by the primary service or another secondary service.
  • Included service is a way to reference other services defined in the server to the defined services.
  • An include definition can be used at the beginning of a service definition to include other services.
  • a service definition refers to an included service by using an include definition
  • the entire included service definition may be part of the new service definition.
  • Included services can exist as independent services, and services included in other services are not changed by included or included services.
  • the value of a characteristic is the value used in a service with attribute and configuration information along with information about how it is accessed and how the value is displayed or represented.
  • properties are defined as property definitions, which may include property declarations, property properties and values, and may include descriptors that describe the server's values or allowed configurations with respect to the property.
  • FIG. 29A illustrates a service definition representing a service of a server.
  • the service definition must include a service declaration, and include an included definition indicating an included service (or secondary service), which is a service included in the primary service, and a characteristic definition indicating a characteristic including data related to the service. Can be.
  • the Service Definition terminates before the next service declaration or after reaching the maximum attribute handle value.
  • Service definitions are represented on the server based on attribute handles.
  • All include definitions and characteristic definitions included in a Service Definition may be considered part of the service, and all included definitions shall be placed before the property definition immediately after the service declaration.
  • a service definition can have zero or more characteristic definitions, and there is no upper limit to include or characteristic definitions.
  • a service declaration is an attribute whose attribute type is set to the UUID of the ⁇ primary service> or ⁇ secondary service >>.
  • the attribute value is the 16-bit Bluetooth UUID or 128-bit UUID of the service known as the service UUID.
  • the client must support both 16-bit and 128-bit UUIDs. Clients can ignore service definitions with unknown service UUIDs. Unknown service UUID is the UUID of the unsupported service. Attribute permissions must be read-only and do not require authentication or authorization.
  • the service definition may include a specific field for instructing the client when the service is changed.
  • the value of the modified field is '0', it may indicate that there is no change of service. If the value of the modified field is '1' or changed value (1 is added or changed to any value), the service is changed. Can indicate that there is.
  • FIG. 30 shows an example of an include definition
  • (b) shows an example of an include definition to which a modified filed is added to indicate when an included service is changed.
  • the client may recognize that the secondary service or the included service of the server is changed.
  • FIG. 31 shows an example of a characteristic definition
  • (b) shows an example of a characteristic definition in which a modified filed is added to indicate when a characteristic service is changed.
  • the client may recognize that the characteristic value of the characteristic related to the service of the server has changed.
  • 32 to 34 are flowcharts illustrating an example of a method for recognizing whether a service and a property are changed through an attribute proposed by the present invention.
  • a client may recognize whether a service of a server is changed through a service definition, an include definition, and a characteristic definition of the server.
  • FIG. 32 illustrates a method for searching whether a service definition indicating a service of a server has been changed.
  • the client may start a service search procedure to search for a service of a server (S32010).
  • the client may recognize whether the service of the server has changed through whether the service definition of the server has changed (S32020).
  • the client may recognize whether the service has been changed through the modified field of the service definition.
  • the client may recognize that the service of the server has been changed.
  • the client may perform step S33010 of FIG. 33 to determine whether the include definition is changed (S32030).
  • the client determines that the current service has not been changed, and determines whether a service definition indicating another service exists (S32040).
  • the client may perform step S32020 again to confirm whether another service definition has changed.
  • the client determines that another service no longer exists in the server and terminates the service discovery procedure (S32050).
  • 33 illustrates a method for searching whether an include definition indicating an included service of a server has been changed.
  • the client determines whether the include definition is changed (S33010).
  • the client may recognize whether the included service is changed through the modified field of the include definition.
  • the client may recognize that the included service of the server has changed.
  • the client may perform step S34010 of FIG. 34 to check whether the characteristic value of the service has been changed (S33020).
  • the client determines that the currently included service has not been changed, and determines whether an include definition indicating another included service exists (S33030).
  • the client may perform step S33010 again to check whether the other include definition is changed.
  • the client determines that no other included service exists in the server anymore, and performs step S32040 of FIG. 32 to check whether the other service definition exists (S33040). ).
  • 34 illustrates a method for searching whether a characteristic definition indicating a value of a characteristic associated with a specific service of a server has changed.
  • the client determines whether the characteristic definition has changed in order to check whether the value of the characteristic related to the service has changed (S34010).
  • the client may recognize whether the value of the characteristic related to the specific service is changed through the modified field of the characteristic definition.
  • the client may recognize that the value of the characteristic related to the specific service has changed.
  • the client may acquire a value of the changed characteristic by performing a service and a read procedure (S34020).
  • the client may send a read request message to the server requesting the value of the changed characteristic, and in response, the server may send a read response message containing the changed characteristic value to the client.
  • the client determines whether there is a characteristic definition representing another characteristic related to the specific service (S34030).
  • the client may perform step S34010 again to confirm whether the other characteristic definition has changed.
  • the client determines that the characteristic related to the specific service no longer exists in the server and performs step S33030 of FIG. 33 to confirm whether or not another include definition exists. (S34040).
  • the client may recognize whether the service and the data related to the service of the server have been changed, and obtain the changed service and data.
  • 35 to 37 are diagrams showing an example of function information for improving compatibility between devices proposed by the present invention.
  • the client and the server may improve compatibility with each other by exchanging information related to functions that may be provided to each other.
  • the client may perform Discover All Primary Services, which is a procedure for searching all services to discover services of a server, and Discover Primary Service by Service UUID, which is a procedure for discovering a primary service through a UUID of a service.
  • Discover All Primary Services which is a procedure for searching all services to discover services of a server
  • Discover Primary Service by Service UUID which is a procedure for discovering a primary service through a UUID of a service.
  • a compatibility problem may occur between the client and the server, and due to such compatibility problem, the client may request a function not implemented in the server, and then request a function to support the time, causing a time delay.
  • a compatibility problem may occur because the counterpart device does not recognize whether or not the counterpart device supports various procedures implemented for each service in Bluetooth.
  • the client and the server may define the mutually supporting functions as at least one of the ATT function information or the GATT function information, and may improve compatibility by transmitting the defined function information to the counterpart.
  • the client and the server may each define a function supported by at least one of ATT feature information or GATT feature information, as shown in FIG. 35.
  • the ATT feature may be provided in the form of an ATT PDU, and the GATT feature may be provided in the form of a GAT procedure.
  • Each bit in the ATT Feature and GATT Feature may indicate whether the client and the server each support a specific function.
  • the server or the client may indicate that it supports the function indicated by a particular bit.
  • FIG. 36 is a diagram illustrating an example of a function indicated by each bit of an ATT Feature
  • FIG. 37 is a diagram illustrating an example of a function represented by each bit of a GATT Feature.
  • 38 and 39 are flowcharts illustrating an example of a method for improving compatibility between devices proposed by the present invention.
  • 38 illustrates an example of a method for a server and a client to recognize a function implemented in a counterpart device through a read procedure.
  • the server and client may support a function supported by the counterpart device by reading a value of the specific characteristic. Can be recognized.
  • step S38010 and step S38020 are the same as step S14010 and step S14020 of FIG. 14, description thereof will be omitted.
  • the Controller 500 which forms a GATT connection with the first device 300, reads by type request requesting the value of the GATT Feature characteristic to the first device 300 in order to recognize a function implemented in the first device 300.
  • the message is transmitted (S38030).
  • the Read by type Request message may include a UUID for requesting a value of the GATT Feature characteristic.
  • the controller knows the handle value of the GATT feature, the value of the GATT feature may be requested through the Read Request message instead of the Read by type Request message.
  • a fixed handle value may be required to request the value of the GATT feature characteristic through a read request message without performing the characteristic discovery procedure.
  • the Read by Type Request message or the Read Request message may include at least one of a GATT Feature or an ATT Feature representing a function implemented in the Controller 500 described with reference to FIGS. 35 to 37.
  • the first device 300 transmits a read by type response message including a value of a GATT feature characteristic to the controller 500 in response to the read by type request message (S38040).
  • the first device 300 may provide the controller 500 with the length and data value of the attribute having the UUID included in the read by type request message.
  • the controller 500 may search for a primary service of the server by performing a primary service discovery procedure based on a function implemented in the first device 300 recognized through the value of the GATT feature property (S38050).
  • the controller 500 requests the primary service list implemented in the first device 300 through the primary service discovery procedure, and the first device 300 may transmit the primary service list to the controller 500.
  • the controller 500 that discovers the primary service of the first device 300 through the primary service discovery procedure may perform a characteristic discovery procedure to search for characteristics related to the discovered services (S38060).
  • the controller 500 requests the characteristic information related to the service of the first device 300 discovered through the characteristic discovery procedure, and the first device 300 may transmit specific information to the controller 500.
  • 39 illustrates an example of a method for a server and a client to recognize a function implemented in a counterpart device through a writing procedure.
  • the server and client may support a function supported by the counterpart device by writing a value of the specific characteristic. Can be recognized.
  • step S39010 and step S39020 are the same as step S14010 and step S14020 of FIG. 14, description thereof will be omitted.
  • the controller 500 that forms the GATT connection with the first device 300 transmits a write request message requesting the writing of the GATT feature characteristic to the first device 300 (S39030).
  • the write request message includes the function information (GATT Feature of FIG. 35) indicating the function implemented in the controller 500, and the first device writes the function information included in the write request message in the GATT Feature characteristic. Recognize the functionality implemented in.
  • the controller 500 may perform a characteristic discovery procedure or require a fixed handle value in advance in order to request writing to the GATT feature.
  • the first device 300 writes the function information in the GATT feature characteristic and transmits a write response message to the controller 500 in response to the write request message (39040).
  • the first device 300 may transmit an error message indicating the failure of the writing to the controller 500.
  • the write response message may include function information (GATT Feature of FIG. 35) indicating a function supported by the first device 300, and the controller 500 may use the first device (eg, the function information included in the write response message).
  • the function implemented in 300 may be recognized.
  • step S39050 and step S39060 are the same as step S38050 and step S38060 of FIG. 38, and thus description thereof will be omitted.
  • 40 and 41 are flowcharts illustrating still another example of a method for improving compatibility between devices proposed by the present invention.
  • the server and the client may perform a GATT Feature through a discovery procedure of a service and a characteristic. The feature can be found, and the client can request the value of the server's GATT Feature property to recognize the feature available to the particular service implemented in the server.
  • FIG. 40 illustrates an example of a method for recognizing a function implemented in a server by a client acquiring a feature value of a discovered server through a reading procedure.
  • step S40010 and step S40020 are the same as step S14010 and step S14020 of FIG. 14, description thereof will be omitted.
  • the controller 500 that forms the GATT connection with the first device 300 may search the primary service of the server by performing a primary service discovery procedure (S40030).
  • the controller 500 requests the primary service list implemented in the first device 300 through the primary service discovery procedure, and the first device 300 may transmit the primary service list to the controller 500.
  • the controller 500 that discovers the primary service of the first device 300 through the primary service discovery procedure may perform a characteristic discovery procedure to search for characteristics related to the discovered services (S40040).
  • the controller 500 requests the characteristic information related to the service of the first device 300 discovered through the characteristic discovery procedure, and the first device 300 may transmit specific information to the controller 500.
  • the controller 500 may search for a GATT feature, which is a characteristic representing a function implemented for a specific service in the first device 300 through a discovery procedure.
  • the controller 500 discovering the GATT Feature characteristic transmits a Read by type Request message requesting the value of the GATT Feature characteristic to the first device 300 in order to recognize a function implemented in the first device 300 (S40050). ).
  • the Read by type Request message may include a UUID for requesting a value of the GATT Feature characteristic.
  • the controller knows the handle value of the GATT feature, the value of the GATT feature may be requested through the Read Request message instead of the Read by type Request message.
  • a fixed handle value may be required to request the value of the GATT feature characteristic through a read request message without performing the characteristic discovery procedure.
  • the Read by Type Request message or the Read Request message may include at least one of a GATT Feature or an ATT Feature representing a function implemented in the controller described with reference to FIGS. 35 to 37.
  • the first device 300 transmits a read by type response message including a value of a GATT feature characteristic to the controller 500 in response to the read by type request message (S40060).
  • the first device 300 may provide the controller 500 with the length and data value of the attribute having the UUID included in the read by type request message.
  • controller 500 and the first device 300 may provide a specific service through the recognized function.
  • 41 illustrates an example of a method for recognizing a function implemented in a counterpart device by a server and a client through a procedure of writing a found feature value of a server.
  • step S41010 to step S41040 is the same as step S40010 to step S40040 of Figure 40 will be omitted.
  • the controller 500 discovering the GATT feature characteristic transmits a write request message requesting the writing of the GATT feature characteristic to the first device 300 (S41050).
  • the write request message includes the function information (GATT Feature of FIG. 35) indicating the function implemented in the controller 500, and the first device 300 writes the function information included in the write request message in the GATT Feature characteristic. By writing, the function implemented in the controller 500 can be recognized.
  • the controller 500 may perform a characteristic discovery procedure or require a fixed handle value in advance in order to request writing to the GATT feature.
  • the first device 300 writes the function information in the GATT feature characteristic, and transmits a write response message to the controller 500 in response to the write request message (41060).
  • the first device 300 may transmit an error message indicating the failure of the writing to the controller 500.
  • the write response message may include function information (GATT Feature of FIG. 35) indicating a function supported by the first device 300, and the controller 500 may use the first device (eg, the function information included in the write response message).
  • the function implemented in 300 may be recognized.
  • the server and the client may recognize a function implemented in the counterpart device by exchanging a value of a GATT feature representing the supportable function described with reference to FIGS. 34 and 35.
  • step S42010 and step S42020 are the same as step S14010 and step S14020 of FIG. 14, description thereof will be omitted.
  • the controller 500 which forms a GATT connection with the first device 300, transmits a function information request message to the first device 300 to request a value of a GATT feature, which is function information indicating a function implemented in a server ( S42030).
  • a specific ATT opcode may be defined to request a value of a GATT feature through a function information request message.
  • the controller 500 obtains the value of the GATT feature of the first device 300 by transmitting a function information request message including a specific ATT opcode indicating the transmission of the value of the GATT feature to the first device 300. can do.
  • the function information request message may include at least one of a GATT feature or an ATT feature indicating a function implemented in the controller 500 described with reference to FIGS. 35 to 37.
  • the first device 300 may recognize a function supported by the controller 500 through the data value of the GATT feature or the data value of the ATT feature included in the function information request message.
  • the first device 300 transmits a function information response message including the value of the GATT feature of the first device to the controller 500 in response to the function information request message (S42040).
  • a specific ATT opcode may be defined to transmit a value of a GATT feature through a function information response message.
  • the first device 300 may transmit a function information response message including a specific ATT opcode to the first device 300 to inform the controller 500 that the value of the GATT feature is transmitted.
  • 43 is a flowchart illustrating an example of a method for recognizing whether a service and a characteristic proposed by the present invention are changed.
  • the first device forms a Bluetooth LE connection with the second device through the method described with reference to FIG. 14 (S43010).
  • the first device which has established a GATT connection through the Bluetooth LE connection with the second device, receives a first message indicating whether to change a service supported by the second device from the second device (S43020).
  • the first message may be a read response message or an indication message including the characteristic value of the Changed information characteristic described with reference to FIG. 27.
  • the first device searches for at least one of a service or a characteristic of the service based on the first message (S43030).
  • the first device may recognize whether the service and the characteristic of the second device have changed through the method described with reference to FIGS. 26 to 34, and may search for the changed service and the characteristic.
  • the first device when the service of the second device does not change and only a characteristic value of a specific service is changed, the first device does not search for all devices of the second device again. Only the characteristic can be searched to read the changed characteristic value.
  • the method for controlling a device using Bluetooth is not limited to the configuration and method of the embodiments described above, but the embodiments are all of the embodiments so that various modifications can be made. Or some may be selectively combined.
  • the method of controlling a device using Bluetooth of the present disclosure can be implemented as a processor-readable code in 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)

Abstract

무선 통신 시스템에서 제 1 디바이스가 서비스를 탐색하기 위한 방법 및 장치에 관한 것이다. 본 발명에 의하면, 제 1 디바이스는 제 2 디바이스와 블루투스 LE 연결을 형성하고, 상기 제 2 디바이스로부터 상기 제 2 디바이스가 지원하는 서비스의 변경 여부를 지시하는 제 1 메시지를 수신하며, 상기 제 1 메시지에 기초하여 서비스 또는 상기 서비스의 특성 중 적어도 하나를 탐색하되, 상기 제 1 메시지는 상기 제 2 디바이스가 지원하는 서비스의 변경과 관련된 제 1 값 및 상기 서비스의 특성 값의 변경과 관련된 제 2 값을 포함할 수 있다.

Description

블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
본 발명은 무선 통신시스템에서 근거리 기술인 블루투스를 이용하여 디바이스를 제어하기 위한 방법 및 장치에 관한 것으로써, 특히 블루투스 기술을 통해서 디바이스간 연결의 형성을 제어하기 위한 방법 및 장치에 관한 것이다.
블루투스는 근거리에서 각종 디바이스들을 무선으로 연결하여 데이터를 주고 받을 수 있는 근거리 무선 기술 규격이다. 블루투스(Bluetooth) 통신을 이용하여 두 기기간 무선 통신을 수행하고자 하는 경우, 사용자(User)는 통신하고자 하는 블루투스(Bluetooth) 디바이스(Device)들을 검색(Discovery)하고 연결(Connection)을 요청하는 절차를 수행한다. 본 발명에서 디바이스는 기기, 장치를 의미할 수 있다.
이때, 사용자는 블루투스 디바이스를 이용하여 사용하고자 하는 블루투스 통신방법에 따라 블루투스 디바이스를 검색한 후 연결을 수행할 수 있다.
블루투스 통신방법에는 BR/EDR (Basic Rate/Enhanced Data Rate)방식과 저전력 방식인 LE (Low Energy)방식이 있다. BR/EDR 방식은 블루투스 클래식 (Bluetooth Classic)라고 호칭될 수 있다. 블루투스 클래식 방식은 베이직 레이트(Basic Rate)를 이용하는 블루투스 1.0부터 이어져온 블루투스 기술과 블루투스 2.0에서부터 지원되는 인핸스드 데이터 레이트(Enhanced Data Rate)를 이용하는 블루투스 기술을 포함한다.
블루투스 저전력 에너지(Bluetooth Low energy, 이하 블루투스 LE라고 한다.)기술은 블루투스 4.0부터 적용되어 적은 전력을 소모하여 수백 키로바이트(KB)의 정보를 안정적으로 제공할 수 있다. 이러한 블루투스 저전력 에너지 기술은 속성 프로토콜(Attribute Protocol)을 활용해서 디바이스(Device) 간 정보를 교환하게 된다. 이러한 블루투스 LE 방식은 헤더의 오버헤드(overhead)를 줄이고 동작을 간단하게 해서 에너지 소비를 줄일 수 있다.
블루투스 기기들 중에는 디스플레이(Display)나 유저인터페이스(User Interface)가 없는 제품들도 있다. 다양한 종류의 블루투스 기기들과 그 중에서도 유사기술이 적용된 블루투스 기기들 간의 연결 / 관리 / 제어 / 분리 (Connection / Management / Control / Disconnection)의 복잡도가 증가하고 있다.
또한, 블루투스는 비교적 저전력, 저비용으로 비교적 빠른 속도를 낼 수 있으나, 전송 거리가 일반적으로 최대 100m로 한정적이므로, 한정된 공간에서 사용하기 적합하다.
본 발명은, 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치를 제공함에 그 목적이 있다.
또한, 본 발명은 제어 디바이스가 블루투스 기술을 이용하여 디바이스로부터 클라이언트 역할로 동작하는 서비스들의 정보를 획득하여 디바이스의 연결 형성을 제어하기 위한 방법 및 장치를 제공함에 그 목적이 있다.
또한, 본 발명은 제어 디바이스가 블루투스 기술을 이용하여 디바이스로부터 서버 역할로 동작하는 서비스들의 정보를 획득하여 디바이스의 연결 형성을 제어하기 위한 방법 및 장치를 제공함에 그 목적이 있다.
또한, 본 발명은 제어되는 디바이스가 특성 정보가 변경된 경우, 특성 정보의 변경을 제어 디바이스에게 알리기 위한 방법 및 장치를 제공함에 그 목적이 있다.
또한, 본 발명은 제어 디바이스가 제어하는 디바이스들의 특성 정보가 변경된 경우, 변경된 특성 정보를 획득하기 위한 방법 및 장치를 제공함에 그 목적이 있다.
또한, 본 발명은 제어 디바이스가 제어하는 디바이스들의 특성 정보가 일정 크기 이상인 경우, 추가적인 메시지를 통해서 나머지 특성 정보를 획득하기 위한 방법 및 장치를 제공함에 그 목적이 있다.
또한, 본 발명은 제어 디바이스가 제어하는 디바이스들의 서비스 및 서비스와 관련된 특성의 특성 값의 변경을 인식하기 위한 방법 및 장치를 제공함에 그 목적이 있다.
또한, 본 발명은 제어 디바이스가 제어하는 디바이스들의 변경된 서비스 및 특성의 특성 값을 탐색하기 위한 방법 및 장치를 제공함에 그 목적이 있다.
또한, 본 발명은 제어 디바이스와 제어되는 디바이스들 간의 호환성을 위해 디바이스들 간에 지원하는 기능들을 인식하기 위한 방법 및 장치를 제공함에 그 목적이 있다.
본 명세서에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명은 상술한 문제점을 해결하기 위해서 무선 통신 시스템에서 블루투스를 이용하여 제 1 디바이스가 서비스를 탐색하기 위한 방법을 제공한다.
구체적으로, 본 발명의 일 실시예에 따른 무선 통신 시스템에서 제 1 디바이스가 서비스를 탐색하기 위한 방법은, 제 2 디바이스와 블루투스 LE 연결을 형성하는 단계; 상기 제 2 디바이스로부터 상기 제 2 디바이스가 지원하는 서비스의 변경 여부를 지시하는 제 1 메시지를 수신하는 단계; 및 상기 제 1 메시지에 기초하여 서비스 또는 상기 서비스의 특성 중 적어도 하나를 탐색하는 단계를 포함하되, 상기 제 1 메시지는 상기 제 2 디바이스가 지원하는 서비스의 변경과 관련된 제 1 값 및 상기 서비스의 특성 값의 변경과 관련된 제 2 값을 포함한다.
또한, 본 발명에서, 상기 탐색하는 단계는, 상기 제 1 값에 기초하여 상기 서비스가 변경되었는지 여부를 판단하는 단계; 상기 제 1 값이 상기 서비스의 변경을 나타내는 경우, 상기 변경된 서비스를 탐색하는 단계; 상기 제 2 값에 기초하여 상기 특성 값이 변경되었는지 여부를 판단하는 단계; 및 상기 제 2 값이 상기 특성 값의 변경을 나타내는 경우, 상기 변경된 특성 값을 탐색하는 단계를 포함한다.
또한, 본 발명에서, 상기 제 1 값은 상기 서비스를 나타내는 제 1 해쉬 값이고, 상기 제 2 값은 상기 특성 값을 나타내는 제 2 해쉬 값이다.
또한, 본 발명은, 상기 제 1 해쉬 값 또는 상기 제 2 해쉬 값이 변경되었는지 여부를 판단하는 단계를 더 포함하되, 상기 제 1 해쉬 값이 변경된 경우, 상기 제 1 해쉬 값이 나타내는 서비스를 탐색하고, 상기 제 2 해쉬 값이 변경된 경우, 상기 제 2 해쉬 값이 나타내는 특성 값을 탐색한다.
또한, 본 발명은, 상기 제 2 디바이스가 지원하는 프라이머리(primary) 서비스를 탐색하는 단계; 및 상기 탐색된 프라이머리 서비스의 특성 값을 탐색하는 단계를 더 포함한다.
또한, 본 발명은, 상기 제 2 디바이스로 상기 제 2 디바이스와의 호환성을 위한 제 1 특성의 특성 값의 판독을 요청하는 판독 요청 메시지를 전송하는 단계; 및 상기 판독 요청 메시지에 대한 응답으로 상기 제 1 특성의 제 1 특성 값을 포함하는 판독 응답 메시지를 수신하는 단계를 더 포함하되, 상기 제 1 특성 값은 상기 제 2 디바이스가 지원하는 적어도 하나의 기능을 나타낸다.
또한, 본 발명에서, 상기 판독 요청 메시지는 상기 제 1 디바이스와의 호환성을 위한 제 2 특성의 제 2 특성 값을 포함하고, 상기 제 2 특성 값은 상기 제 1 디바이스가 지원하는 적어도 하나의 기능을 나타낸다.
또한, 본 발명은, 상기 제 2 디바이스로 상기 제 1 디바이스와의 호환성을 위한 제 1 특성의 제 1 특성 값의 기입을 요청하는 기입 요청 메시지를 전송하는 단계, 상기 제 1 특성 값은 상기 제 1 디바이스가 지원하는 적어도 하나의 기능을 나타내고; 및 상기 기입 요청 메시지에 대한 응답으로 상기 제 2 디바이스와의 호환성을 위한 제 2 특성의 제 2 특성 값을 포함하는 기입 응답 메시지를 수신하는 단계를 더 포함하되, 상기 제 2 특성 값은 상기 제 2 디바이스가 지원하는 적어도 하나의 기능을 나타낸다.
또한, 본 발명은, 외부와 무선 또는 유선으로 통신하기 위한 통신부; 및 상기 통신부와 기능적으로 연결되는 프로세서를 포함하되, 상기 프로세서는, 제 2 디바이스와 블루투스 LE 연결을 형성하고, 상기 제 2 디바이스로부터 상기 제 2 디바이스가 지원하는 서비스의 변경 여부를 지시하는 위한 제 1 메시지를 수신하며, 상기 제 1 메시지에 기초하여 서비스 또는 상기 서비스의 특성 중 적어도 하나를 탐색하되, 상기 제 1 메시지는 상기 제 2 디바이스가 지원하는 서비스의 변경과 관련된 제 1 값 및 상기 서비스의 특성 값의 변경과 관련된 제 2 값을 포함하는 디바이스를 제공한다.
본 발명의 일 실시 예에 따른 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법에 따르면, 제어 디바이스를 통해서 다른 디바이스의 연결 형성을 제어할 수 있는 효과가 있다.
또한, 본 발명에 따르면, 디바이스가 클라이언트로 동작하는 서비스들의 정보 및/또는 서버로 동작하는 서비스들의 정보를 획득함으로써, 서비스에서의 역할에 따라 디바이스들의 연결 형성을 제어할 수 있는 효과가 있다.
또한, 본 발명에 따르면, 특성 정보의 크기가 일정 크기 이상인 경우, 특성 정보가 남아있다는 것을 제어 디바이스에게 알림으로써, 추가적인 메시지를 통해서 나머지 정보를 획득할 수 있는 효과가 있다.
또한, 본 발명에 따르면, 제어되는 디바이스들의 서비스 정보가 변경되는 경우, 변경된 정보가 어느 서비스의 정보인지를 제어 디바이스로 전송함으로써 제어 디바이스가 변경된 서비스 정보만을 획득할 수 있는 효과가 있다.
또한, 본 발명에 따르면, 제어되는 디바이스들의 서비스와 관련된 특성 정보가 변경되는 경우, 변경된 특성 정보가 어느 특성 정보인지를 제어 디바이스로 전송함으로써 제어 디바이스가 변경된 특성 정보만을 획득할 수 있는 효과가 있다.
또한, 본 발명에 따르면, 제어 디바이스는 제어되는 디바이스들의 서비스 및 특성 값의 변경을 인식할 수 있는 효과가 있다.
또한, 본 발명에 따르면, 제어 디바이스는 제어되는 디바이스들의 서비스 및 특성 값이 변경된 경우, 탐색 절차를 통해서 변경된 서비스 및 특성을 인식할 수 있는 효과가 있다.
또한, 본 발명은 제어 디바이스와 제어되는 디바이스들 간에 지원하는 기능과 관련된 정보를 교환함으로써, 제어 디바이스와 제어되는 디바이스들의 호환성을 향상 시킬 수 있는 효과가 있다.
본 명세서에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는 첨부 도면은 본 발명에 대한 실시 예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 특징을 설명한다.
도 1은 본 발명이 적용될 수 있는 블루투스 저전력 에너지 기술을 이용하는 무선 통신 시스템의 일 예를 나타낸 개략도이다.
도 2는 본 발명이 적용될 수 있는 디바이스의 내부 블록도의 일 예를 나타낸다.
도 3은 본 발명이 적용될 수 있는 블루투스 저전력 에너지 토폴로지(Topology)의 일 예를 나타낸다.
도 4는 본 발명이 적용될 수 있는 블루투스 통신 아키텍처(Architecture)의 일 예를 나타낸 도이다.
도 5는 본 발명이 적용될 수 있는 블루투스 저전력 에너지의 GATT(Generic Attribute Profile)의 구조의 일 예를 나타낸 도이다.
도 6는 본 발명이 적용될 수 있는 블루투스 저전력 에너지 기술에서 연결 절차 방법의 일 예를 나타내는 흐름도이다.
도 7은 본 발명이 적용될 수 있는 제어 디바이스를 통해서 다른 디바이스를 제어하기 위한 방법을 간략히 나타낸 도이다.
도 8 및 도 9은 본 발명이 적용될 수 있는 디바이스를 제어하기 위한 서비스를 제공하기 위한 프로파일 구조의 일 예를 나타낸 도이다.
도 10은 본 발명이 적용될 수 있는 디바이스를 제어하기 위한 서비스를 나타내는 서비스 정보의 구조의 일 예를 나타낸 도이다.
도 11 및 12는 본 발명이 적용될 수 있는 Primary Service의 정보를 탐색하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 13은 Primary Service와 관련된 Included Service의 정보를 탐색하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 14는 본 발명에서 제안하는 Controller가 디바이스들의 서비스 정보를 획득하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 15 내지 도 17은 본 발명에서 제안하는 디바이스가 클라이언트 역할로 동작하는 서비스와 관련된 특성의 일 예를 나타낸 도이다.
도 18은 본 발명에서 제안하는 디바이스가 서버 역할로 동작하는 서비스와 관련된 특성의 일 예를 나타낸 도이다.
도 19는 본 발명에서 제안하는 특성 정보가 일정 크기 이상인 경우, 복수의 메시지를 통해 특성 정보를 송수신하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 20 및 도 21은 본 발명에서 제안하는 서비스의 구조와 관련된 특성의 일 예를 나타낸 도이다.
도 22는 본 발명에서 제안하는 서비스와 관련된 정보가 변경된 경우, 변경된 서비스의 정보를 송수신하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 23은 본 발명에서 제안하는 특성 정보가 추가 정보를 제공할 수 있는 경우, 복수의 메시지를 통해 추가 정보를 송수신하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 24는 본 발명에서 제안하는 특성 정보가 변경된 경우, 변경된 특성 정보를 송수신하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 25 및 도 26은 본 발명에서 제안하는 특성 정보의 변경 여부와 관련된 특성의 일 예를 나타낸 도이다.
도 27 및 도 28은 본 발명에서 제안하는 서비스 및 특성의 변경 여부를 인식하기 위한 방법 및 데이터 포맷의 일 예를 나타내는 도면이다.
도 29 내지 도 31은 본 발명에서 제안하는 서비스 및 특성의 변경 여부를 인식하기 위한 속성의 일 예를 나타내는 도면이다.
도 32 내지 도 34은 본 발명에서 제안하는 속성을 통해서 서비스 및 특성의 변경 여부를 인식하기 위한 방법의 일 예를 나타내는 흐름도이다.
도 35 내지 도 37은 본 발명에서 제안하는 디바이스간의 호환성을 향상시키기 위한 기능 정보의 일 예를 나타내는 도면이다.
도 38 및 도 39은 본 발명에서 제안하는 디바이스간의 호환성을 향상시키기 위한 방법의 일 예를 나타내는 흐름도이다.
도 40 및 도 41은 본 발명에서 제안하는 디바이스간의 호환성을 향상시키기 위한 방법의 또 다른 일 예를 나타내는 흐름도이다.
도 42은 본 발명에서 제안하는 디바이스간의 호환성을 향상시키기 위한 방법의 또 다른 일 예를 나타내는 흐름도이다.
도 43는 본 발명에서 제안하는 서비스 및 특성의 변경 여부를 인식하기 위한 방법의 일 예를 나타내는 순서도이다.
본 발명의 상술한 목적, 특징들 및 장점은 첨부된 도면과 관련된 다음의 상세한 설명을 통해 보다 분명해질 것이다. 다만, 본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시 예들을 가질 수 있는 바, 이하에서는 특정 실시 예들을 도면에 예시하고 이를 상세히 설명하고자 한다. 명세서 전체에 걸쳐서 동일한 참조번호들은 원칙적으로 동일한 구성요소들을 나타낸다. 또한, 본 발명과 관련된 공지 기능 혹은 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다.
이하, 본 발명과 관련된 방법 및 장치에 대하여 도면을 참조하여 보다 상세하게 설명한다. 이하의 설명에서 사용되는 구성요소에 대한 접미사 "모듈" 및 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다.
도 1은 본 명세서에서 제안하는 블루투스 저전력 에너지 기술을 이용하는 무선 통신 시스템의 일 예를 나타낸 개략도이다.
무선 통신 시스템(100)은 적어도 하나의 서버 디바이스(Server Device, 120) 및 적어도 하나의 클라이언트 디바이스(Client Device, 110)를 포함한다.
서버 장치와 클라이언트 장치는 블루투스 저전력 에너지(Bluetooth Low Energy:BLE, 이하 편의상 ‘BLE’로 표현한다.) 기술을 이용하여 블루투스 통신을 수행한다.
먼저, BLE 기술은 블루투스 BR/EDR(Basic Rate/Enhanced Data Rate) 기술과 비교하여, 상대적으로 작은 duty cycle을 가지며 저 가격 생산이 가능하고, 저속의 데이터 전송률을 통해 전력 소모를 크게 줄일 수 있어 코인 셀(coin cell) 배터리를 이용할 경우 1년 이상 동작이 가능하다.
또한, BLE 기술에서는 디바이스 간 연결 절차를 간소화하였으며, 패킷 사이즈도 블루투스 BR/EDR 기술에 비해 작게 설계되어 있다.
BLE 기술에서, (1) RF 채널수는 40개이며, (2) 데이터 전송 속도는 1Mbps를 지원하며, (3) 토폴로지는 스캐터넷 구조이며, (4) latency는 3ms 이며, (5) 최대 전류는 15mA이하이며, (6) 출력 전력은 10mW(10dBm)이하이며, (7) 휴대폰, 시계, 스포츠, 헬스케어, 센서, 기기제어 등의 어플리케이션에 주로 사용된다.
상기 서버 장치(120)는 다른 장치와의 관계에서 클라이언트 장치로 동작할 수 있고, 상기 클라이언트 장치는 다른 장치와의 관계에서 서버 장치로 동작할 수 있다. 즉, BLE 통신 시스템에서 어느 하나의 장치는 서버 장치 또는 클라이언트 장치로 동작하는 것이 가능하며, 필요한 경우, 서버 장치 및 클라이언트 장치로 동시에 동작하는 것도 가능하다.
상기 서버 장치(120)는 데이터 서비스 장치(Data service Device), 슬레이브 디바이스(slave device) 디바이스, 슬레이브(slave), 서버, 컨덕터(Conductor), 호스트 디바이스(Host Device), 게이트웨이(Gateway), 센싱 장치(Sensing Device), 모니터링 장치(monitoring device), 제 1 디바이스, 제 2 디바이스 등으로 표현될 수 있다.
상기 클라이언트 디바이스(110)는 마스터 디바이스(master device), 마스터(master), 클라이언트, 멤버(Member), 센서 디바이스, 싱크 디바이스(Sink Device), 콜렉터(Collector), 제 3 디바이스, 제 4 디바이스 등으로 표현될 수 있다.
서버 장치와 클라이언트 장치는 상기 무선 통신 시스템의 주요 구성요소에 해당하며, 상기 무선 통신 시스템은 서버 장치 및 클라이언트 장치 이외에도 다른 구성요소를 포함할 수 있다.
상기 서버 장치는 클라이언트 장치로부터 데이터를 제공 받고, 클라이언트 장치와 직접 통신을 수행함으로써, 클라이언트 장치부터 데이터 요청을 수신하는 경우, 응답을 통해 클라이언트 장치로 데이터를 제공하는 장치를 말한다.
또한, 상기 서버 장치는 클라이언트 장치로 데이터 정보를 제공하기 위해 클라이언트 장치에게 알림(Notification) 메시지, 지시(Indication) 메시지를 보낸다. 또한, 상기 서버 장치는 상기 클라이언트 장치로 지시 메시지를 전송하는 경우, 상기 클라이언트로부터 상기 지시 메시지에 대응하는 확인(Confirm) 메시지를 수신한다.
또한, 상기 서버 장치는 알림, 지시, 확인 메시지들을 클라이언트 디바이스와 송수신하는 과정에서 출력부(Display Unit)을 통해서 사용자에게 데이터 정보를 제공하거나 입력부(User Input Interface)를 통해 사용자로부터 입력되는 요청을 수신할 수 있다.
또한, 상기 서버 장치는 상기 클라이언트 장치와 메시지를 송수신하는 과정에서 메모리(memory unit)로부터 데이터를 읽어 오거나 새로운 데이터를 해당 메모리에 쓸 수 있다.
또한, 하나의 서버 장치는 다수의 클라이언트 장치들과 연결될 수 있으며, 본딩(Bonding) 정보를 활용하여 클라이언트 장치들과 쉽게 재 연결(또는 접속)이 가능하다.
상기 클라이언트 장치 (120)는 서버 장치에게 데이터 정보 및 데이터 전송을 요청하는 장치를 말한다.
클라이언트 장치는 상기 서버 장치로부터 알림 메시지, 지시 메시지 등을 통해 데이터를 수신하고, 지시 메시지를 상기 서버 디바이스로부터 수신하는 경우, 상기 지시 메시지에 대한 응답으로 확인 메시지를 보낸다.
상기 클라이언트 장치도 마찬가지로 상기 서버 장치와 메시지들을 송수신하는 과정에서 출력부를 통해 사용자에게 정보를 제공하거나 입력부를 통해 사용자로부터의 입력을 수신할 수 있다.
또한, 상기 클라이언트 장치는 상기 서버 장치와 메시지를 송수신하는 과정에서 메모리로부터 데이터를 읽어 오거나 새로운 데이터를 해당 메모리에 쓸 수 있다.
상기 서버 장치 및 클라이언트 장치의 출력부, 입력부 및 메모리 등과 같은 하드웨어 구성요소에 대해서는 도 2에서 구체적으로 살펴보기로 한다.
또한, 상기 무선 통신 시스템은 블루투스 기술을 통해 개인 영역 네트워킹(Personal Area Networking:PAN)을 구성할 수 있다. 일 예로, 상기 무선 통신 시스템에서는 디바이스 간 개인적인 피코넷(private piconet)을 확립함으로써 파일, 서류 등을 신속하고 안전하게 교환할 수 있다.
도 2는 본 명세서에서 제안하는 방법들을 구현할 수 있는 디바이스의 내부 블록도의 일 예를 나타낸다.
도 2에 도시된 바와 같이, 서버 디바이스는 출력부(Display Unit, 111), 입력부(User Input Interface, 112), 전력 공급부(Power Supply Unit, 113), 프로세서(Processor, 114), 메모리(Memory Unit, 115), 블루투스 인터페이스(Bluetooth Interface, 116), 다른 통신 인터페이스(Other Interface, 117) 및 통신부(또는 송수신부, 118)를 포함한다.
상기 출력부(111), 입력부(112), 전력 공급부(113), 프로세서(114), 메모리(115), 블루투스 인터페이스(116), 다른 통신 인터페이스(117) 및 통신부(118)는 본 명세서에서 제안하는 방법을 수행하기 위해 기능적으로 연결되어 있다.
또한, 클라이언트 디바이스는 출력부(Display Unit, 121), 입력부(User Input Interface, 122), 전력 공급부(Power Supply Unit, 123), 프로세서(Processor, 124), 메모리(Memory Unit, 125), 블루투스 인터페이스(Bluetooth Interface, 126) 및 통신부(또는 송수신부, 127)를 포함한다.
상기 출력부(121), 입력부(122), 전력 공급부(123), 프로세서(124), 메모리(125), 블루투스 인터페이스(126), 및 통신부(127)는 본 명세서에서 제안하는 방법을 수행하기 위해 기능적으로 연결되어 있다.
상기 블루투스 인터페이스(116,126)는 블루투스 기술을 이용하여 디바이스들 간의 요청/응답, 명령, 알림, 지시/확인 메시지 등 또는 데이터 전송이 가능한 유닛(또는 모듈)을 말한다.
상기 메모리(115,125)는 다양한 종류의 디바이스에 구현되는 유닛으로서, 다양한 종류의 데이터가 저장되는 유닛을 말한다.
상기 프로세서(114,124)는 서버 디바이스 또는 클라이언트 디바이스의 전반적인 동작을 제어하는 모듈을 말하며, 블루투스 인터페이스 및 다른 통신 인터페이스로 메시지를 전송 요청 및 수신받은 메시지를 처리하도록 제어한다.
상기 프로세서(114,124)는 제어부, 제어 유닛(Control Unit), 컨트롤러 등으로 표현될 수 있다.
상기 프로세서(114,124)는 ASIC(application-specific integrated circuit), 다른 칩셋, 논리 회로 및/또는 데이터 처리 장치를 포함할 수 있다.
상기 프로세서(114,124)는 서버 디바이스로부터 광고(Advertising) 메시지를 수신하도록 상기 통신부를 제어하며, 상기 서버 디바이스로 스캔 요청(Scan Request) 메시지를 전송하고, 상기 서버 디바이스로부터 상기 스캔 요청에 대한 응답으로 스캔 응답(Scan Response) 메시지를 수신하도록 상기 통신부를 제어하며, 상기 서버 디바이스와 블루투스 연결 설정을 위해 상기 서버 디바이스로 연결 요청(Connect Request) 메시지를 전송하도록 상기 통신부를 제어한다.
또한, 상기 프로세서(114,124)는 상기 연결 절차를 통해 블루투스 LE 커넥션(Connection)이 형성된 이후, 상기 서버 디바이스로부터 속성 프로토콜을 이용하여 데이터를 읽어오거나(Read), 기록(Write)할 수 있도록 상기 통신부를 제어한다.
상기 메모리(115,125)는 ROM(read-only memory), RAM(random access memory), 플래쉬 메모리, 메모리 카드, 저장 매체 및/또는 다른 저장 장치를 포함할 수 있다.
상기 통신부(118,127)는 무선 신호를 처리하기 위한 베이스밴드 회로를 포함할 수 있다. 실시 예가 소프트웨어로 구현될 때, 상술한 기법은 상술한 기능을 수행하는 모듈(과정, 기능 등)로 구현될 수 있다. 모듈은 메모리에 저장되고, 프로세서에 의해 실행될 수 있다.
상기 메모리(115,125)는 프로세서(114,124) 내부 또는 외부에 있을 수 있고, 잘 알려진 다양한 수단으로 프로세서(114,124)와 연결될 수 있다.
상기 출력부(111,121)는 디바이스의 상태 정보 및 메시지 교환 정보 등을 화면을 통해서 사용자에게 제공하기 위한 모듈을 말한다.
상기 전력 공급부(전원 공급부, 113, 123)는 제어부의 제어 하에 외부의 전원, 내부의 전원을 인가 받아 각 구성요소들의 동작에 필요한 전원을 공급해주는 모듈을 말한다.
앞에서 살핀 것처럼, BLE 기술에서는 작은 duty cycle을 가지며, 저속의 데이터 전송률을 통해 전력 소모를 크게 줄일 수 있다.
상기 입력부(112,122)는 화면 버튼과 같이 사용자의 입력을 제어부에게 제공하여 디바이스의 동작을 사용자가 제어할 수 있게 하는 모듈을 말한다.
도 3은 블루투스 저전력 에너지 토폴로지(Topology)의 일 예를 나타낸다.
도 3을 참조하면, 디바이스 A는 디바이스 B와 디바이스 C를 슬레이브(slave)로 가지는 피코넷(피코넷 A, 음영부분)에서 마스터(master)에 해당한다.
여기서, 피코넷(Piconet)이란, 다수의 디바이스들 중 어느 하나가 마스터이고, 나머지 디바이스들이 마스터 디바이스에 연결되어 있는 공유된 물리 채널을 점유하고 있는 디바이스들의 집합을 의미한다.
BLE 슬레이브는 마스터와 공통 물리 채널을 공유하지 않는다. 각각의 슬레이브는 별개의 물리 채널을 통해 마스터와 통신한다. 마스터 디바이스 F와 슬레이브 디바이스 G를 가지는 또 다른 피코넷(피코넷 F)이 있다.
디바이스 K는 스캐터넷(scatternet K)에 있다. 여기서, 스캐터넷(scatternet)은 다른 피코넷들 간 연결이 존재하는 피코넷의 그룹을 의미한다.
디바이스 K는 디바이스 L의 마스터이면서, 디바이스 M의 슬레이브이다.
디바이스 O 역시 스캐터넷(scatternet O)에 있다. 디바이스 O는 디바이스 P의 슬레이브이면서, 디바이스 Q의 슬레이브이다.
도 3에 도시된 바와 같이, 5개의 다른 디바이스 그룹들이 존재한다.
디바이스 D는 광고자(advertiser)이고, 디바이스 A는 개시자(initiator)이다(그룹 D).
디바이스 E는 스캐너(scanner)이며, 디바이스 C는 광고자이다(그룹 C).
디바이스 H는 광고자이며, 디바이스 I 및 J는 스캐너들이다(그룹 H).
디바이스 K 또한 광고자이며, 디바이스 N은 개시자이다(그룹 K).
디바이스 R은 광고자이며, 디바이스 O는 개시자이다(그룹 R).
디바이스 A와 B는 하나의 BLE 피코넷 물리 채널을 사용한다.
디바이스 A와 C는 또 다른 BLE 피코넷 물리 채널을 사용한다.
그룹 D에서, 디바이스 D는 광고 물리 채널 상으로 연결 가능한 광고 이벤트를 사용하여 광고하며, 디바이스 A는 개시자이다. 디바이스 A는 디바이스 D와 연결을 형성할 수 있고, 피코넷 A로 디바이스를 추가할 수 있다.
그룹 C에서, 디바이스 C는 스캐너 디바이스 E에 의해 캡쳐되는 광고 이벤트의 어떤 타입을 사용하여 광고 물리 채널 상으로 광고를 한다.
그룹 D와 그룹 C는 충돌을 피하기 위해 서로 다른 광고 물리 채널을 사용하거나 다른 시간을 사용할 수 있다.
피코넷 F에는 하나의 물리 채널이 있다. 디바이스 F와 G는 하나의 BLE 피코넷 물리 채널을 사용한다. 디바이스 F는 마스터이고, 디바이스 G는 슬레이브이다.
그룹 H에는 하나의 물리 채널이 있다. 디바이스 H, I 및 J는 하나의 BLE 광고 물리 채널을 사용한다. 디바이스 H는 광고자이며, 디바이스 I 및 J는 스캐너이다.
스캐터넷 K에서, 디바이스 K와 L은 하나의 BLE 피코넷 물리 채널을 사용한다. 디바이스 K와 M은 또 다른 BLE 피코넷 물리 채널을 사용한다.
그룹 K에서, 디바이스 K는 광고 물리 채널 상으로 연결 가능한 광고 이벤트를 사용하여 광고를 하며, 디바이스 N은 개시자이다. 디바이스 N은 디바이스 K와 연결을 형성할 수 있다. 여기서, 디바이스 K는 두 디바이스들의 슬레이브가 되면서 동시에 한 디바이스의 마스터가 된다.
스캐터넷 O에서, 디바이스 O와 P는 하나의 BLE 피코넷 물리 채널을 사용한다. 디바이스 O와 Q는 또 다른 BLE 피코넷 물리채널을 사용한다.
그룹 R에서, 디바이스 R은 광고 물리 채널 상으로 연결 가능한 광고 이벤트를 사용하여 광고를 하며, 디바이스 O는 개시자이다. 디바이스 O는 디바이스 R과 연결을 형성할 수 있다. 여기서, 디바이스 O는 두 디바이스들의 슬레이브가 되면서 동시에 한 디바이스의 마스터가 된다.
도 4는 본 명세서에서 제안하는 방법들이 적용될 수 있는 블루투스 통신 아키텍처(Architecture)의 일 예를 나타낸 도이다.
상기 도 4을 참고하면, 상기 도 4의 (a)는 블루투스 BR(Basic Rate)/EDR(Enhanced Data Rate)의 프로토콜 스택의 일 예를 나타내며, (b)는 블루투스 LE(Low Energy)의 프로토콜 스택의 일 예를 나타낸다.
구체적으로, 도 4의 (a)에 도시된 바와 같이, 블루투스 BR/EDR 프로토콜 스택은 호스트 컨트롤러 인터페이스(Host Controller Interface, HCI, 18)를 기준으로 상부의 컨트롤러 스택(Controller stack, 10)과 하부의 호스트 스택(Host Stack, 20)을 포함할 수 있다.
상기 호스트 스택(또는 호스트 모듈)(20)은 2.4GHz의 블루투스 신호를 받는 무선 송수신 모듈과 블루투스 패킷을 전송하거나 수신하기 위한 하드웨어를 말하며, 상기 컨트롤러 스택(10)인 블루투스 모듈과 연결되어 블루투스 모듈을 제어하고 동작을 수행한다.
상기 컨트롤러 스택(10)은 PHY 계층(12), 링크 컨트롤러 계층(Link Controller, 14), 링크 매니저 계층(Link Manager, 16)을 포함할 수 있다.
상기 PHY 계층(12)은 2.4GHz 무선 신호를 송수신하는 계층으로, GFSK (Gaussian Frequency Shift Keying) modulation을 사용하는 경우 79 개의 RF 채널을 hopping 하여 데이터를 전송할 수 있다.
상기 링크 컨트롤러 계층(14)은 Digital Signal을 전송하는 역할을 담당하며, 초당 1400번 hopping 하는 채널 시퀀스를 선택하며, 각 채널 별 625us 길이의 time slot을 전송한다.
상기 링크 매니저 계층(16)은 LMP(Link Manager Protocol)을 활용하여 Bluetooth Connection의 전반적인 동작(link setup, control, security)을 제어한다.
상기 링크 매니저 계층(16)은 아래와 같은 기능을 수행할 수 있다.
- ACL/SCO logical transport, logical link setup 및 control을 한다.
- Detach: connection을 중단하고, 중단 이유를 상대 디바이스에게 알려준다.
- Power control 및 Role switch를 한다.
- Security(authentication, pairing, encryption) 기능을 수행한다.
상기 호스트 컨트롤러 인터페이스 계층(18)은 Host 모듈과 Controller 모듈 사이의 인터페이스 제공하여 Host 가 command와 Data를 Controller에게 제공하게 하며, Controller가 event와 Data를 Host에게 제공할 수 있도록 해준다.
상기 호스트 스택(또는 호스트 모듈, 20)은 논리적 링크 제어 및 적응 프로토콜(L2CAP, 21), 속성 프로토콜(Protocol, 22), 일반 속성 프로파일(Generic Attribute Profile, GATT, 23), 일반 접근 프로파일(Generic Access Profile, GAP, 24), BR/EDR 프로파일(25)을 포함한다.
상기 논리적 링크 제어 및 적응 프로토콜(L2CAP, 21)은 특정 프로토콜 또는 포로파일에게 데이터를 전송하기 위한 하나의 양방향 채널을 제공할 수 있다.
상기 L2CAP(21)은 블루투스 상위에서 제공하는 다양한 프로토콜, 프로파일 등을 멀티플렉싱(multiplexing)할 수 있다.
블루투스 BR/EDR의 L2CAP에서는 dynamic 채널 사용하며, protocol service multiplexer, retransmission, streaming mode를 지원하고, Segmentation 및 reassembly, per-channel flow control, error control을 제공한다.
상기 일반 속성 프로파일(GATT, 23)은 서비스들의 구성 시에 상기 속성 프로토콜(22)이 어떻게 이용되는지를 설명하는 프로토콜로서 동작 가능할 수 있다. 예를 들어, 상기 일반 속성 프로파일(23)은 ATT 속성들이 어떻게 서비스들로 함께 그룹화되는지를 규정하도록 동작 가능할 수 있고, 서비스들과 연계된 특징들을 설명하도록 동작 가능할 수 있다.
따라서, 상기 일반 속성 프로파일(23) 및 상기 속성 프로토콜(ATT, 22)은 디바이스의 상태와 서비스들을 설명하고, 특징들이 서로 어떻게 관련되며 이들이 어떻게 이용되는지를 설명하기 위하여, 특징들을 사용할 수 있다.
상기 속성 프로토콜(22) 및 상기 BR/EDR 프로파일(25)은 블루트스 BR/EDR를 이용하는 서비스 (profile)의 정의 및 이들 데이터를 주고 받기 위한 application 프로토콜을 정의하며, 상기 일반 접근 프로파일(Generic Access Profile, GAP, 24)은 디바이스 발견, 연결, 및 보안 수준을 정의한다.
상기 도 4의 (b)에 도시된 바와 같이, 블루투스 LE 프로토콜 스택은 타이밍이 중요한 무선장치 인터페이스를 처리하도록 동작 가능한 컨트롤러 스택(Controller stack, 30)과 고레벨(high level) 데이터를 처리하도록 동작 가능한 호스트 스택(Host stack, 40)을 포함한다.
먼저, 컨트롤러 스택(30)은 블루투스 무선장치를 포함할 수 있는 통신 모듈, 예를 들어, 마이크로프로세서와 같은 프로세싱 디바이스를 포함할 수 있는 프로세서 모듈을 이용하여 구현될 수 있다.
호스트 스택은 프로세서 모듈 상에서 작동되는 OS의 일부로서, 또는 OS 위의 패키지(package)의 인스턴스 생성(instantiation)으로서 구현될 수 있다.
일부 사례들에서, 컨트롤러 스택 및 호스트 스택은 프로세서 모듈 내의 동일한 프로세싱 디바이스 상에서 작동 또는 실행될 수 있다.
상기 컨트롤러 스택(30)은 물리 계층(Physical Layer, PHY, 32), 링크 레이어(Link Layer, 34) 및 호스트 컨트롤러 인터페이스(Host Controller Interface, 36)를 포함한다.
상기 물리 계층(PHY, 무선 송수신 모듈, 32)은 2.4 GHz 무선 신호를 송수신하는 계층으로 GFSK (Gaussian Frequency Shift Keying) modulation과 40 개의 RF 채널로 구성된 frequency hopping 기법을 사용한다.
블루투스 패킷을 전송하거나 수신하는 역할을 하는 상기 링크 레이어(34)는 3개의 Advertising 채널을 이용하여 Advertising, Scanning 기능을 수행한 후에 디바이스 간 연결을 생성하고, 37개 Data 채널을 통해 최대 257bytes 의 데이터 패킷을 주고 받는 기능을 제공한다.
상기 호스트 스택은 논리적 링크 제어 및 적응 프로토콜(L2CAP, 41), 보안 매니저(Security Manager, SM, 42), 속성 프로토콜(Attribute Protocol, ATT, 43), 일반 속성 프로파일(Generic Attribute Profile, GATT, 44), 일반 접근 프로파일(Generic Access Profile, 45), LE 프로파일(46)을 포함할 수 있다. 다만, 상기 호스트 스택(40)은 이것으로 한정되지는 않고 다양한 프로토콜들 및 프로파일들을 포함할 수 있다.
호스트 스택은 L2CAP을 사용하여 블루투스 상위에서 제공하는 다양한 프로토콜, 프로파일 등을 다중화(multiplexing)한다.
먼저, L2CAP(Logical Link Control and Adaptation Protocol, 41)은 특정 프로토콜 또는 프로파일에게 데이터를 전송하기 위한 하나의 양방향 채널을 제공할 수 있다.
상기 L2CAP(41)은 상위 계층 프로토콜들 사이에서 데이터를 다중화(multiplex)하고, 패키지(package)들을 분할(segment) 및 재조립(reassemble)하고, 멀티캐스트 데이터 송신을 관리하도록 동작 가능할 수 있다.
블루투스 LE 에서는 3개의 고정 채널(signaling CH을 위해 1개, Security Manager를 위해 1개, Attribute protocol을 위해 1개)을 기본적으로 사용한다. 그리고, 필요에 따라 동적 채널을 사용할 수도 있다.
반면, BR/EDR(Basic Rate/Enhanced Data Rate)에서는 동적인 채널을 기본적으로 사용하며, protocol service multiplexer, retransmission, streaming mode 등을 지원한다.
SM(Security Manager, 42)은 디바이스를 인증하며, 키 분배(key distribution)를 제공하기 위한 프로토콜이다.
ATT(Attribute Protocol, 43)는 서버-클라이언트(Server-Client) 구조로 상대 디바이스의 데이터를 접근하기 위한 규칙을 정의한다. ATT에는 아래의 6가지의 메시지 유형(Request, Response, Command, Notification, Indication, Confirmation)이 있다.
① Request 및 Response 메시지: Request 메시지는 클라이언트 디바이스에서 서버 디바이스로 특정 정보 요청 및 전달하기 위한 메시지이며, Response 메시지는 Request 메시지에 대한 응답 메시지로서, 서버 디바이스에서 클라이언트 디바이스로 전송하는 용도로 사용할 수 있는 메시지를 말한다.
② Command 메시지: 클라이언트 디바이스에서 서버 디바이스로 주로 특정 동작의 명령을 지시하기 위해 전송하는 메시지로, 서버 디바이스는 Command 메시지에 대한 응답을 클라이언트 디바이스로 전송하지 않는다.
③ Notification 메시지: 서버 디바이스에서 클라이언트 디바이스로 이벤트 등과 같은 통지를 위해 전송하는 메시지로, 클라이언트 디바이스는 Notification 메시지에 대한 확인 메시지를 서버 디바이스로 전송하지 않는다.
④ Indication 및 Confirm 메시지: 서버 디바이스에서 클라이언트 디바이스로 이벤트 등과 같은 통지를 위해 전송하는 메시지로, Notification 메시지와는 달리, 클라이언트 디바이스는 Indication 메시지에 대한 확인 메시지(Confirm message)를 서버 디바이스로 전송한다.
상기 일반 접근 프로파일(45)은 블루투스 LE 기술을 위해 새롭게 구현된 계층으로, 블루투스 LE 디바이스들 간의 통신을 위한 역할 선택, 멀티 프로파일 작동이 어떻게 일어나는지를 제어하는데 사용된다.
또한, 상기 일반 접근 프로파일(45)은 디바이스 발견, 연결 생성 및 보안 절차 부분에 주로 사용되며, 사용자에게 정보를 제공하는 방안을 정의하며, 하기와 같은 attribute의 type을 정의한다.
① service: 데이터와 관련된 behavior의 조합으로 디바이스의 기본적인 동작을 정의
② Include: 서비스 사이의 관계를 정의
③ Characteristics: 서비스에서 사용되는 data 값
④ Behavior: UUID(Universal Unique Identifier, value type)로 정의된 컴퓨터가 읽을 수 있는 포맷
상기 LE 프로파일(46)은 GATT에 의존성을 가지는 profile 들로 주로 블루투스 LE 디바이스에 적용된다. LE 프로파일(46)은 예를 들면, Battery, Time, FindMe, Proximity, Time 등이 있을 수 있으며, GATT-based Profiles의 구체적인 내용은 하기와 같다.
① Battery: 배터리 정보 교환 방법
② Time: 시간 정보 교환 방법
③ FindMe: 거리에 따른 알람 서비스 제공
④ Proximity: 배터리 정보 교환 방법
⑤ Time: 시간 정보 교환 방법
상기 일반 속성 프로파일(GATT, 44)은 서비스들의 구성 시에 상기 속성 프로토콜(43)이 어떻게 이용되는지를 설명하는 프로토콜로서 동작 가능할 수 있다. 예를 들어, 상기 일반 속성 프로파일(44)은 ATT 속성들이 어떻게 서비스들로 함께 그룹화되는지를 규정하도록 동작 가능할 수 있고, 서비스들과 연계된 특징들을 설명하도록 동작 가능할 수 있다.
따라서, 상기 일반 속성 프로파일(44) 및 상기 속성 프로토콜(ATT, 43)은 디바이스의 상태와 서비스들을 설명하고, 특징들이 서로 어떻게 관련되며 이들이 어떻게 이용되는지를 설명하기 위하여, 특징들을 사용할 수 있다.
이하에서, 블루투스 저전력 에너지(Bluetooth Low Energy:BLE) 기술의 절차(Procedure)들에 대해 간략히 살펴보기로 한다.
BLE 절차는 디바이스 필터링 절차(Device Filtering Procedure), 광고 절차(Advertising Procedure), 스캐닝 절차(Scanning Procedure), 디스커버링 절차(Discovering Procedure), 연결 절차(Connecting Procedure) 등으로 구분될 수 있다.
디바이스 필터링 절차(Device Filtering Procedure)
디바이스 필터링 절차는 컨트롤러 스택에서 요청, 지시, 알림 등에 대한 응답을 수행하는 디바이스들의 수를 줄이기 위한 방법이다.
모든 디바이스에서 요청 수신 시, 이에 대해 응답하는 것이 불필요하기 때문에, 컨트롤러 스택은 요청을 전송하는 개수를 줄여서, BLE 컨트롤러 스택에서 전력 소비가 줄 수 있도록 제어할 수 있다.
광고 디바이스 또는 스캐닝 디바이스는 광고 패킷, 스캔 요청 또는 연결 요청을 수신하는 디바이스를 제한하기 위해 상기 디바이스 필터링 절차를 수행할 수 있다.
여기서, 광고 디바이스는 광고 이벤트를 전송하는 즉, 광고를 수행하는 디바이스를 말하며, 광고자(Advertiser)라고도 표현된다.
스캐닝 디바이스는 스캐닝을 수행하는 디바이스, 스캔 요청을 전송하는 디바이스를 말한다.
BLE에서는, 스캐닝 디바이스가 일부 광고 패킷들을 광고 디바이스로부터 수신하는 경우, 상기 스캐닝 디바이스는 상기 광고 디바이스로 스캔 요청을 전송해야 한다.
하지만, 디바이스 필터링 절차가 사용되어 스캔 요청 전송이 불필요한 경우, 상기 스캐닝 디바이스는 광고 디바이스로부터 전송되는 광고 패킷들을 무시할 수 있다.
연결 요청 과정에서도 디바이스 필터링 절차가 사용될 수 있다. 만약, 연결 요청 과정에서 디바이스 필터링이 사용되는 경우, 연결 요청을 무시함으로써 상기 연결 요청에 대한 응답을 전송할 필요가 없게 된다.
광고 절차(Advertising Procedure)
광고 디바이스는 영역 내 디바이스들로 비지향성의 브로드캐스트를 수행하기 위해 광고 절차를 수행한다.
여기서, 비지향성의 브로드캐스트는 특정 방향으로의 브로드캐스트가 아닌 전(모든) 방향으로의 브로드캐스트를 말한다.
이와 달리, 지향성 브로드 캐스트는 특정 방향으로의 브로드캐스트를 말한다. 비지향성 브로드캐스트는 광고 디바이스와 리스닝(또는 청취) 상태에 있는 디바이스(이하, 리스닝 디바이스라 한다.) 간에 연결 절차 없이 발생한다.
광고 절차는 근처의 개시 디바이스와 블루투스 연결을 확립하기 위해 사용된다.
또는, 광고 절차는 광고 채널에서 리스닝을 수행하고 있는 스캐닝 디바이스들에게 사용자 데이터의 주기적인 브로드캐스트를 제공하기 위해 사용될 수 있다.
광고 절차에서 모든 광고(또는 광고 이벤트)는 광고 물리 채널을 통해 브로드캐스트된다.
광고 디바이스들은 광고 디바이스로부터 추가적인 사용자 데이터를 얻기 위해 리스닝을 수행하고 있는 리스닝 디바이스들로부터 스캔 요청을 수신할 수 있다. 광고 디바이스는 스캔 요청을 수신한 광고 물리 채널과 동일한 광고 물리 채널을 통해, 스캔 요청을 전송한 디바이스로 스캔 요청에 대한 응답을 전송한다.
광고 패킷들의 일 부분으로서 보내지는 브로드캐스트 사용자 데이터는 동적인 데이터인 반면에, 스캔 응답 데이터는 일반적으로 정적인 데이터이다.
광고 디바이스는 광고 (브로드캐스트) 물리 채널 상에서 개시 디바이스로부터 연결 요청을 수신할 수 있다. 만약, 광고 디바이스가 연결 가능한 광고 이벤트를 사용하였고, 개시 디바이스가 디바이스 필터링 절차에 의해 필터링 되지 않았다면, 광고 디바이스는 광고를 멈추고 연결 모드(connected mode)로 진입한다. 광고 디바이스는 연결 모드 이후에 다시 광고를 시작할 수 있다.
스캐닝 절차(Scanning Procedure)
스캐닝을 수행하는 디바이스 즉, 스캐닝 디바이스는 광고 물리 채널을 사용하는 광고 디바이스들로부터 사용자 데이터의 비지향성 브로드캐스트를 청취하기 위해 스캐닝 절차를 수행한다.
스캐닝 디바이스는 광고 디바이스로부터 추가적인 데이터를 요청 하기 위해, 광고 물리 채널을 통해 스캔 요청을 광고 디바이스로 전송한다. 광고 디바이스는 광고 물리 채널을 통해 스캐닝 디바이스에서 요청한 추가적인 데이터를 포함하여 상기 스캔 요청에 대한 응답인 스캔 응답을 전송한다.
상기 스캐닝 절차는 BLE 피코넷에서 다른 BLE 디바이스와 연결되는 동안 사용될 수 있다.
만약, 스캐닝 디바이스가 브로드캐스트되는 광고 이벤트를 수신하고, 연결 요청을 개시할 수 있는 개시자 모드(initiator mode)에 있는 경우, 스캐닝 디바이스는 광고 물리 채널을 통해 광고 디바이스로 연결 요청을 전송함으로써 광고 디바이스와 블루투스 연결을 시작할 수 있다.
스캐닝 디바이스가 광고 디바이스로 연결 요청을 전송하는 경우, 스캐닝 디바이스는 추가적인 브로드캐스트를 위한 개시자 모드 스캐닝을 중지하고, 연결 모드로 진입한다.
디스커버링 절차(Discovering Procedure)
블루투스 통신이 가능한 디바이스(이하, ‘블루투스 디바이스’라 한다.)들은 근처에 존재하는 디바이스들을 발견하기 위해 또는 주어진 영역 내에서 다른 디바이스들에 의해 발견되기 위해 광고 절차와 스캐닝 절차를 수행한다.
디스커버링 절차는 비대칭적으로 수행된다. 주위의 다른 디바이스를 찾으려고 하는 블루투스 디바이스를 디스커버링 디바이스(discovering device)라 하며, 스캔 가능한 광고 이벤트를 광고하는 디바이스들을 찾기 위해 리스닝한다. 다른 디바이스로부터 발견되어 이용 가능한 블루투스 디바이스를 디스커버러블 디바이스(discoverable device)라 하며, 적극적으로 광고 (브로드캐스트) 물리 채널을 통해 다른 디바이스가 스캔 가능하도록 광고 이벤트를 브로드캐스트한다.
디스커버링 디바이스와 디스커버러블 디바이스 모두 피코넷에서 다른 블루투스 디바이스들과 이미 연결되어 있을 수 있다.
연결 절차(Connecting Procedure)
연결 절차는 비대칭적이며, 연결 절차는 특정 블루투스 디바이스가 광고 절차를 수행하는 동안 다른 블루투스 디바이스는 스캐닝 절차를 수행할 것을 요구한다.
즉, 광고 절차가 목적이 될 수 있으며, 그 결과 단지 하나의 디바이스만 광고에 응답할 것이다. 광고 디바이스로부터 접속 가능한 광고 이벤트를 수신한 이후, 광고 (브로트캐스트) 물리 채널을 통해 광고 디바이스로 연결 요청을 전송함으로써 연결을 개시할 수 있다.
다음으로, BLE 기술에서의 동작 상태 즉, 광고 상태(Advertising State), 스캐닝 상태(Scanning State), 개시 상태(Initiating State), 연결 상태(connection state)에 대해 간략히 살펴보기로 한다.
광고 상태(Advertising State)
링크 계층(LL)은 호스트 (스택)의 지시에 의해, 광고 상태로 들어간다. 링크 계층이 광고 상태에 있을 경우, 링크 계층은 광고 이벤트들에서 광고 PDU(Packet Data Unit)들을 전송한다.
각각의 광고 이벤트는 적어도 하나의 광고 PDU들로 구성되며, 광고 PDU들은 사용되는 광고 채널 인덱스들을 통해 전송된다. 광고 이벤트는 광고 PDU가 사용되는 광고 채널 인덱스들을 통해 각각 전송되었을 경우, 종료되거나 광고 디바이스가 다른 기능 수행을 위해 공간을 확보할 필요가 있을 경우 좀 더 일찍 광고 이벤트를 종료할 수 있다.
스캐닝 상태(Scanning State)
링크 계층은 호스트 (스택)의 지시에 의해 스캐닝 상태로 들어간다. 스캐닝 상태에서, 링크 계층은 광고 채널 인덱스들을 리스닝한다.
스캐닝 상태에는 수동적 스캐닝(passive scanning), 적극적 스캐닝(active scanning)의 두 타입이 있으며, 각 스캐닝 타입은 호스트에 의해 결정된다.
스캐닝을 수행하기 위한 별도의 시간이나 광고 채널 인덱스가 정의되지는 않는다.
스캐닝 상태 동안, 링크 계층은 스캔윈도우(scanWindow) 구간(duration) 동안 광고 채널 인덱스를 리스닝한다. 스캔인터벌(scanInterval)은 두 개의 연속적인 스캔 윈도우의 시작점 사이의 간격(인터벌)으로서 정의된다.
링크 계층은 스케쥴링의 충돌이 없는 경우, 호스트에 의해 지시되는 바와 같이 스캔윈도우의 모든 스캔인터벌 완성을 위해 리스닝해야한다. 각 스캔윈도우에서, 링크 계층은 다른 광고 채널 인덱스를 스캔해야한다. 링크 계층은 사용 가능한 모든 광고 채널 인덱스들을 사용한다.
수동적인 스캐닝일 때, 링크 계층은 단지 패킷들만 수신하고, 어떤 패킷들도 전송하지 못한다.
능동적인 스캐닝일 때, 링크 계층은 광고 디바이스로 광고 PDU들과 광고 디바이스 관련 추가적인 정보를 요청할 수 있는 광고 PDU 타입에 의존하기 위해 리스닝을 수행한다.
개시 상태(Initiating State)
링크 계층은 호스트 (스택)의 지시에 의해 개시 상태로 들어간다.
링크 계층이 개시 상태에 있을 때, 링크 계층은 광고 채널 인덱스들에 대한 리스닝을 수행한다.
개시 상태 동안, 링크 계층은 스캔윈도우 구간 동안 광고 채널 인덱스를 리스닝한다.
연결 상태(connection state)
링크 계층은 연결 요청을 수행하는 디바이스 즉, 개시 디바이스가 CONNECT_REQ PDU를 광고 디바이스로 전송할 때 또는 광고 디바이스가 개시 디바이스로부터 CONNECT_REQ PDU를 수신할 때 연결 상태로 들어간다.
연결 상태로 들어간 이후, 연결이 생성되는 것으로 고려된다. 다만, 연결이 연결 상태로 들어간 시점에서 확립되도록 고려될 필요는 없다. 새로 생성된 연결과 기 확립된 연결 간의 유일한 차이는 링크 계층 연결 감독 타임아웃(supervision timeout) 값뿐이다.
두 디바이스가 연결되어 있을 때, 두 디바이스들은 다른 역할로 활동한다.
마스터 역할을 수행하는 링크 계층은 마스터로 불리며, 슬레이브 역할을 수행하는 링크 계층은 슬레이브로 불린다. 마스터는 연결 이벤트의 타이밍을 조절하고, 연결 이벤트는 마스터와 슬레이브 간 동기화되는 시점을 말한다.
이하에서, 블루투스 인터페이스에서 정의되는 패킷에 대해 간략히 살펴보기로 한다. BLE 디바이스들은 하기에서 정의되는 패킷들을 사용한다.
패킷 포맷(Packet Format)
링크 계층(Link Layer)은 광고 채널 패킷과 데이터 채널 패킷 둘 다를 위해 사용되는 단지 하나의 패킷 포맷만을 가진다.
각 패킷은 프리앰블(Preamble), 접속 주소(Access Address), PDU 및 CRC 4개의 필드로 구성된다.
하나의 패킷이 광고 물리 채널에서 송신될 때, PDU는 광고 채널 PDU가 될 것이며, 하나의 패킷이 데이터 물리 채널에서 전송될 때, PDU는 데이터 채널 PDU가 될 것이다.
광고 채널 PDU (Advertising Channel PDU )
광고 채널 PDU(Packet Data Unit)는 16비트 헤더와 다양한 크기의 페이로드를 가진다.
헤더에 포함되는 광고 채널 PDU의 PDU 타입 필드는 하기 표 1에서 정의된 바와 같은 PDU 타입을 나타낸다.
Figure PCTKR2018000058-appb-T000001
광고 PDU (Advertising PDU )
아래 광고 채널 PDU 타입들은 광고 PDU로 불리고 구체적인 이벤트에서 사용된다.
ADV_IND: 연결 가능한 비지향성 광고 이벤트
ADV_DIRECT_IND: 연결 가능한 지향성 광고 이벤트
ADV_NONCONN_IND: 연결 가능하지 않은 비지향성 광고 이벤트
ADV_SCAN_IND: 스캔 가능한 비지향성 광고 이벤트
상기 PDU들은 광고 상태에서 링크 계층(Link Layer)에서 전송되고, 스캐닝 상태 또는 개시 상태(Initiating State)에서 링크 계층에 의해 수신된다.
스캐닝 PDU (Scanning PDU )
아래 광고 채널 PDU 타입은 스캐닝 PDU로 불리며, 하기에서 설명되는 상태에서 사용된다.
SCAN_REQ: 스캐닝 상태에서 링크 계층에 의해 전송되며, 광고 상태에서 링크 계층에 의해 수신된다.
SCAN_RSP: 광고 상태에서 링크 계층에 의해 전송되며, 스캐닝 상태에서 링크 계층에 의해 수신된다.
개시 PDU (Initiating PDU )
아래 광고 채널 PDU 타입은 개시 PDU로 불린다.
CONNECT_REQ: 개시 상태에서 링크 계층에 의해 전송되며, 광고 상태에서 링크 계층에 의해 수신된다.
데이터 채널 PDU (Data Channel PDU )
데이터 채널 PDU는 16 비트 헤더, 다양한 크기의 페이로드를 가지고, 메시지 무결점 체크(Message Integrity Check:MIC) 필드를 포함할 수 있다.
앞에서 살펴본, BLE 기술에서의 절차, 상태, 패킷 포맷 등은 본 명세서에서 제안하는 방법들을 수행하기 위해 적용될 수 있다.
도 5는 블루투스 저전력 에너지의 GATT(Generic Attribute Profile)의 구조의 일 예를 나타낸 도이다.
도 5를 참조하면 블루투스 저전력 에너지의 프로파일 데이터(Profile Data) 교환을 위한 구조를 살펴볼 수 있다.
구체적으로, GATT(Generic Attribute Profile)는 블루투스 LE 장치간의 서비스(service), 특성(Characteristic)을 이용해서 데이터를 주고 받는 방법을 정의한 것이다.
일반적으로, 페리페럴(Peripheral) 장치(예를 들면, 센서 장치)가 GATT 서버(Server)역할을 하며, 서비스(service), 특성(Characteristic)에 대한 정의를 가지고 있다.
데이터를 읽거나 쓰기 위해서 GATT 클라이언트는 GATT 서버로 데이터 요청을 보내게 되며, 모든 동작(Transaction)은 GATT client에서 시작되어 GATT 서버로부터 응답을 받게 된다.
블루투스 LE에서 사용하는 GATT 기반 동작구조는 프로파일(Profile), 서비스(service), 특성(Characteristic)에 기초하며, 상기 도 5와 같은 수직 구조를 이룰 수 있다.
상기 프로파일(Profile) 하나 또는 그 이상의 서비스들로 구성되어 있으며, 상기 서비스는 하나 이상의 특성 또는 다른 서비스들로 구성되어 있을 수 있다.
상기 서비스(service)는 데이터를 논리적인 단위로 나누는 역할을 하며 하나 이상의 특성(Characteristic) 또는 다른 서비스들을 포함하고 있을 수 있다. 각 서비스는 UUID(Universal Unique Identifier)라 불리는 16bit 또는 128bit의 구분자를 가지고 있다.
상기 특성(Characteristic)은 GATT 기반 동작 구조에서 가장 하위 단위이다. 상기 특성은 단 하나의 데이터를 포함하며, 상기 서비스와 유사하게 16 bit 또는 128 bit의 UUID를 가지고 있다.
상기 특성은 여러 가지 정보들의 값으로 정의되고, 각각의 정보를 담기 위해서 속성(Attribute) 하나씩을 필요로 한다. 상기 특성 여러 개의 연속된 속성을 사용할 수 있다.
상기 속성(Attribute)는 네 개의 구성 요소로 이루어지며, 아래와 같은 의미를 가진다.
- handle: 속성의 주소
- Type: 속성의 유형
- Value: 속성의 값
- Permission: 속성에 대한 접근 권한
본 발명은 상기 GATT를 통해서 제어 디바이스가 제어하고자 하는 디바이스의 결합 정보 및 제어 가능한 동작과 관련된 정보를 획득하여 디바이스를 제어하는 방법을 제안한다.
도 6는 블루투스 저전력 에너지 기술에서 연결 절차 방법의 일 예를 나타내는 흐름도이다.
서버는 클라이언트로 3개의 광고 채널을 통해 광고 메시지를 전송한다(S6010).
서버는 연결 전에는 광고자(Advertiser)로 호칭될 수 있고, 연결 이후에는 마스터(Master)로 호칭될 수 있다. 상기 서버의 일 예로, 센서(온도 센서 등)이 있을 수 있다.
또한, 클라이언트는 연결 전에는 스캐너(Scanner)로 호칭될 수 있고, 연결 이후에는 슬레이브(Slave)로 호칭될 수 있다. 클라이언트의 일 예로 스마트 폰 등이 있을 수 있다.
앞에서 살펴본 것처럼, 블루투스는 2.4GHz 밴드를 통해 총 40개의 채널로 나뉘어 통신을 한다. 40개의 채널 중 3개의 채널은 광고 채널로써, 각종 광고 패킷(Advertising Packet)을 비롯하여 연결을 맺기 위해 주고 받는 패킷들의 교환에 이용된다.
나머지 37개의 채널들은 데이터 채널로 연결 이후의 데이터 교환에 이용된다.
상기 클라이언트는 상기 광고 메시지를 수신한 후, 상기 서버로 추가적인 데이터(예: 서버 디바이스 이름 등)을 획득하기 위해 서버로 Scan Request message를 전송할 수 있다.
이 경우, 상기 서버는 상기 클라이언트로 Scan Request message에 대한 응답으로 추가적인 데이터를 포함하는 Scan Response message를 전송한다.
여기서, Scan Request message 및 Scan Response message는 광고 패킷의 한 종료로써, 광고 패킷은 31 bytes 이하의 User Data만을 포함할 수 있다.
따라서, 데이터의 크기가 3 bytes보다 크지만, 연결까지 맺어서 데이터를 보내기에는 오버헤드가 큰 데이터가 존재하는 경우, Scan Request message/Scan Response message를 이용하여 두번에 걸쳐서 데이터를 나눠 보낸다.
다음, 클라이언트는 서버와 블루투스 연결 설정을 위한 Connection Request message를 서버로 전송한다(S6020).
이를 통해, 서버와 클라이언트 간에 Link Layer(LL) 연결이 형성(establish)된다.
이후, 서버와 클라이언트는 보안 설립 절차를 수행한다.
보안 설립 절차는 Secure Simple Pairing으로 해석되거나 이를 포함하여 수행될 수 있다.
즉, 보안 설립 절차는 Phase 1 단계 내지 Phase 3 단계를 거쳐 수행될 수 있다.
구체적으로, 서버와 클라이언트 간에 페어링 절차(Phase 1)를 수행한다(S6030).
페어링 절차는 클라이언트가 서버로 Pairing Request message)를 전송하고, 서버가 클라이언트로 Pairing Response message를 전송한다.
페어링 절차를 통해서 장치간 authentication requirements와 I(Input)/O(Output) capabilities와 Key Size정보를 주고 받는다. 이 정보를 통해 Phase 2에서 어떤 Key 생성 방법을 사용할지 결정하게 된다.
다음, Phase 2로서, 서버와 클라이언트 간에 레거시 페어링 또는 보안 연결을 수행한다(S6040).
Phase 2에서 레거시 페어링을 수행하는 128bits의 Temporary Key 및 Short Term Key(STK)를 생성한다.
- Temporary Key: STK를 생성하기 위해 만들어진 Key
- Short Term Key(STK): 기기간 암호화된 연결(Encrypted connection)을 만드는데 사용되는 Key 값
만약, Phase 2에서 보안 연결을 수행하는 경우, 128 bit의 Long Term Key(LTK)를 생성한다.
- Long Term Key(LTK): 기기간 암호화된 연결뿐만 아니라 추후의 연결에서도 사용되는 Key 값
다음, SSP Phase 3으로서, 서버와 클라이언트 간에 키 분배(Key Distribution) 절차를 수행한다(S6050).
이를 통해, 서버와 클라이언트 간에 보안 연결이 확립되고, 암호화된 링크를 형성하여 데이터를 송수신할 수 있게 된다.
도 7은 본 발명이 적용될 수 있는 제어 디바이스를 통해서 다른 디바이스를 제어하기 위한 방법을 간략히 나타낸 도이다.
상기 도 7에 도시된 바와 같이, 제 1 디바이스(300)와 제 2 디바이스(400)간의 동작을 제어 하기 위해, Controller(500)가 필요하며, 상기 제 3 디바이스(500)는 상기 제 1 디바이스(300) 및 상기 제 2 디바이스(400)의 결합(Association)을 제어하기 위해서 새로운 제어 프로토콜이 필요하다.
이때, 상기 Controller(500)는 디바이스들의 동작을 제어하기 위해서는 상기 디바이스들의 정보(예를 들면, 인터페이스 정보, 서비스 정보 등)를 알고 있어야 한다.
또한, 블루투스는 장치간 연결을 하고 나서 실제 기기에서 제공되는 서비스 (애플케이션)이 무엇인지 검색을 실행한다.
그 이유는, 블루투스 SIG 에서는 다른 연결 기술 들과 다르게 다양한 애플리케이션의 표준화를 진행하기 때문에 같은 블루투스 제품이어도 제공되는 에플리케이션이 다르면 장치가 수신되는 데이터를 해석할 수 없기 때문에 데이터를 송수신하여도 서비스를 제공할 수 없다.
따라서, 장치들은 블루투스 연결을 형성한 뒤, 제공하는 서비스를 파악해야 한다.
하지만, 현재 블루투스의 서비스 검색 방법은 서버 기반의 정보만 제공하기 때문에 제 3의 장치인 컨트롤러에서는 특정 서비스에서 클라이언트 역할을 수행하는 장치를 발견할 수 없기 때문에 컨트롤러가 블루투스 장치들을 연결 시킬 경우 어떤 서비스가 제공되는지 파악을 할 수 없는 문제점이 존재한다.
또한, 일대일 연결에서 클라이언트가 서버에 연결 할 경우 서버의 데이터가 변경되었는지 알 수 있는 방법이 없기 때문에 변경된 데이터를 확인하기 위해서 초기 Characteristic 및 서비스 발견 절차를 다시 수행해야 한다는 문제점이 있다.
따라서, 본 발명은 이러한 문제점을 해결 하기 위해서 컨트롤러가 클라이언트 역할을 수행하는 장치를 발견하는 방법 및 서버의 데이터가 변경된 경우, 클라이언트가 변경된 데이터만을 확인하고 수신하기 위한 방법을 제공한다.
도 8 및 도 9은 본 발명이 적용될 수 있는 디바이스를 제어하기 위한 서비스를 제공하기 위한 프로파일 구조의 일 예를 나타낸 도이다.
도 8 및 도 9를 참조하면, 제어 디바이스가 다른 디바이스들을 제어하기 위한 서비스가 다른 서비스들의 프로파일에 함께 포함되어 있거나, 별도의 프로파일로 정의되어 있을 수 있다.
이하, 본 발명에서 상기 제어 디바이스가 다른 디바이스들을 제어하기 위한 서비스를 이지 페어링 서비스(Easy Pairing service)라 호칭하도록 한다.
장치들을 제어하는 Controller(500)는 상기 이지 페어링 서비스를 통해서 다른 장치들을 제어할 수 있다. 예를 들면, Controller(500)는 Easy Pairing service를 통해서 First Device(300)와 Second Device(400)간의 결합(예를 들면, 연결, 페어링 또는 본딩)과 관련된 동작들을 제어할 수 있다.
이때, 상기 이지 페어링 서비스는 도 8에 도시된 바와 같이 다른 서비스의 프로파일에 함께 포함되어 있거나, 도 9에 도시된 바와 같이 별도의 프로파일로 정의될 수 있다.
도 8과 같이 상기 이지 페어링 서비스가 별도의 프로파일로 정의되지 않고 특정 서비스의 프로파일에 포함되어 있는 경우(예를 들면, 즉, 이지 페어링 서비스가 다른 primary service와 관련된 Secondary service(또는, included service)로 정의되는 경우 등), 하나의 어플리케이션의 동작을 설명하기 편하다는 장점이 있다.
하지만, 상기 이지 페어링 서비스를 포함하지 않는 프로파일의 서비스까지 상기 이지 페어링 서비스를 적용할 수 없으며, 디바이스간의 역할이 명확하게 정의되어 있어야 한다.
또는, 도 9에 도시된 바와 같이, 이지 페어링 서비스가 별도의 프로파일로 정의되어 있는 경우(예를 들면, 즉, 이지 페어링 서비스가 다른 primary service와 관련되지 않고, 독자적인 primary service 또는 Secondary service(또는, included service)로 정의되는 경우 등), 프로파일 레벨에서 서버/클라이언트 구조가 호환 가능하며, 다른 프로파일까지 상기 이지 페어링 서비스를 확대 적용할 수 있다는 장점이 있다.
도 10은 본 발명이 적용될 수 있는 디바이스를 제어하기 위한 서비스를 나타내는 서비스 정보의 구조의 일 예를 나타낸 도이다.
도 10을 참조하면, 도 9에서 설명한 바와 같이 이지 페어링 서비스는 primary service 또는 included service로 정의될 수 있다.
이지 페어링 서비스가 primary service로 정의되는 경우, 아래와 같은 특징을 가질 수 있다.
- 지원되는 클라이언트 목록에 서버에서 지원되는 기본 서비스의 UUID를 클라이언트 기능으로 포함해야 한다.
- 지원되는 클라이언트 목록은 연결 관리자가 대상 간의 공통 서비스 기능을 일치시키는 데 사용된다.
만약, 이지 페어링 서비스가 primary service로 정의된 특정 서비스의 included service로 정의되는 경우, 이지 페어링 서비스가 관련된 특정 서비스는 도 10에 도시된 특성을 통해서 검색될 수 있다.
도 10에 도시된 특성은 이지 페어링 서비스의 primary service의 정보를 인식하기 위한 특성으로, 서비스 타입 필드(service Type Filed), primary service UUID 및 보안 요구사항 필드(Security Requirements Filed)로 구성될 수 있다.
이때, 도 10에 도시된 특성의 속성(Property) 및 각 필드는 아래와 같다.
- 속성(Properties): 판독 특성 값(Read Characteristic Value)
- 서비스 타입: 팔로우된 primary service UUID의 타입(또는 길이)을 나타낸다.
0x01: 16bits UUID
0x02: 32bits UUID
0x03: 128bits UUID
primary service UUID: Easy Pairing service를 포함한 primary service UUID를 표시한다. 길이는 서비스의 UUID 값에 따라 달라질 수 있다.
Security Requirements: primary service에 대한 보안 요구사항을 나타낸다.
0x01: 암호화로인증되지 않음, 페어링되지 않음.
0x02: 암호화로 인증되지 않음, 연결 관리자 없이 Just Works Pairing 방식으로 페어링.
0x03: 암호화로 인증 된 연결 관리자를 통한 보안 연결.
도 11 및 12는 본 발명이 적용될 수 있는 primary service의 정보를 탐색하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 11 및 도 12를 참조하면, 클라이언트는 서버의 primary service를 발견할 수 있다.
Primary service가 검색되면, 다른 관련된 primary service 및 secondary service들을 발견하기 위한 특성 탐색(characteristic discovery) 및 관계 탐색(relationship discovery)을 포함하는 다른 절차들을 이용하여 primary service에 대한 추가 정보가 액세스될 수 있다.
도 11은 클라이언트가 서버의 모든 primary services을 발견하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 11을 참조하면, 클라이언트는 primary service Discovery 절차를 통해서 서버의 모든 primary service를 검색할 수 있다.
속성에 의해 읽혀지는 속성 형 그룹 유형 요청은 속성 유형 매개 변수가≪primary service≫에 대한 UUID로 설정되어 사용될 수 있다.
Starting Handle은 0x0001로 설정되고 Ending Handle은 0xFFFF로 설정된다.
Read By Group Type Request: Read By Group Type Response 및 Error Response의 두 가지 가능한 응답을 서버에서 보낼 수 있다.
서버에서 오류가 발생하면 오류 응답이 리턴된다.
Read By Group Type Response는 서버에서 지원하는 서비스에 해당하는 속성 핸들(Attribute Handle), 끝 그룹 핸들(End Group Handle) 및 속성 값 튜플(Attribute Value tuples)의 목록을 리턴한다.
응답에 포함 된 각 속성 값은 서버가 지원하는 서비스의 서비스 UUID이고, 속성 핸들은 서비스 선언의 핸들이다.
End Group Handle은 서비스 정의 내의 마지막 속성의 핸들이며, 장치에서 마지막 서비스의 끝 그룹 핸들은 0xFFFF가 될 수 있다.
Read By Group Type Request는 Start Handle을 Read By Group Type Response의 마지막 End Group Handle보다 큰 하나로 설정하여 다시 호출해야 한다.
이 서브 절차는 오류 응답이 수신되고 오류 코드가≪속성을 찾을 수 없음≫으로 설정되거나 유형별 읽기 그룹 응답의 최종 그룹 핸들이 0xFFFF 일 때 완료된다.
서버의 모든 기본 서비스를 발견하기 전에 원하는 기본 서비스가 발견되면 서브 절차를 조기에 종료 할 수 있다.
도 12는 클라이언트가 서비스의 UUID(universal unique identifier)를 알고 있는 경우, 서버의 특정 primary service들을 발견하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 12를 참조하면, 특정 기본 서비스는 서버에 중복하여 복수개가 존재할 수 있으며, 발견 된 기본 서비스는 서비스 UUID로 식별됩니다.
Attribute Protocol Find By Type Value Request는 속성 서비스 유형 매개 변수가 <<primary service>>의 경우 UUID로 설정되고 특성 값이 특정 기본 서비스의 16 비트 Bluetooth UUID 또는 128 비트 UUID로 설정된 경우에 된다.
Starting Handle은 0x0001로 설정되고 Ending Handle은 0xFFFF로 설정됩니다.
Find By Type Value Request에 대해서 서버는 Find By Type Value Response 및 Error Response와 같은 두 가지 가능한 응답을 전송할 수 있으며, 서버에서 오류가 발생하면 오류 응답이 리턴된다.
Find By Type Value Response는 속성 핸들(Attribute Handle) 범위 목록을 리턴한다. 속성 핸들 범위는 시작 핸들과 서비스 정의의 끝 핸들이며, 장치에서 마지막 서비스의 끝 그룹 핸들은 0xFFFF가 될 수 있다.
검색중인 서비스 UUID에 대한 속성 핸들 범위가 리턴되고 끝 찾음 핸들이 0xFFFF가 아닌 경우, Find By Type Value Reques은 시작 핸들을 Find By Type Value Response에서 마지막 속성 핸들 범위보다 큰 하나로 설정하여 다시 호출 할 수 있다.
오류 응답이 수신되고 오류 코드가≪속성을 찾을 수 없음≫으로 설정되거나 유형별 값 검색에서 최종 그룹 핸들이 0xFFFF 일 때이 하위 절차가 완료된다.
원하는 기본 서비스가 서버에서 지원되는 지정된 서비스 UUID의 모든 기본 서비스를 검색하기 전에 발견되면 서브 프로 시저를 조기에 종료 할 수 있다.
도 13은 primary service와 관련된 included service의 정보를 탐색하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 13을 참조하면, Attribute Protocol Read By Type 요청은≪Include≫에 대한 UUID로 설정된 Attribute Type 매개 변수와 함께 사용될 수 있다.
Start Handle은 지정된 서비스의 시작 핸들로 설정되고, Ending Handle은 지정된 서비스의 종료 핸들로 설정된다. 서버에서 지원되는 지정된 서비스에 포함된 모든 included service를 검색하기 전에 원하는 included 서비스가 발견되면 조기에 절차를 종료 할 수 있다.
Read By Type Request에 대해 서버 Read By Type Response 또는 Error Response와 같이 두 가지 가능한 응답을 전송할 수 있다. 이때, 서버에서 오류가 발생하면 Error Response이 리턴된다.
Read By Type Response은 서비스 정의의 포함 된 서비스에 해당하는 속성 핸들 및 속성 값 쌍의 세트를 반환한다. 응답에 포함 된 각 속성 값은 포함 된 서비스 선언의 속성 핸들과 끝 그룹 핸들로 구성될 수 있다. 서비스 UUID가 16 비트 Bluetooth UUID인 경우 응답에도 반환된다. Read By Type Request는 Start Handle이 Read By Type Response의 마지막 Attribute Handle보다 큰 하나로 설정되어 다시 호출된다.
서브 프로세스는 오류 응답이 속성 없음으로 설정된 오류 코드와 함께 수신되거나 유형별 읽기 응답에 포함 된 서비스 선언의 속성 핸들이 요청의 종료 핸들과 동일할 때 완료된다.
Included service가 128 비트 UUID를 사용할 때 included service UUID를 가져 오려면 read request가 사용되며, read request에 대한 속성 핸들은 included service의 속성 핸들이다.
하지만, Bluetooth LE에서는 하나의 메시지를 통해서 전송할 수 있는 데이터의 길이가 제한적이기 때문에, service 정보의 길이가 긴 경우, 한번의 메시지 전송으로 모든 서비스 정보를 전송할 수 없다는 문제점이 존재한다.
또한, 도 11 내지 도 13에서 설명한 바와 같이 단계 적인 service Discovery로 인하여 service를 탐색하는 시간이 오래 걸리며, 서비스들 간의 서로 다른 UUID 길이(예를 들면, 16 bit, 32 bit, 128 bit 등)로 인하여 연속적으로 서비스를 탐색할 수 없다는 문제점이 존재한다.
또한, 서비스의 데이터 추가, 삭제, 서비스의 삭제 및/또는 새로운 서비스의 추가와 같은 서비스의 변경 사항이 존재하는 경우, Client characteristic Configuration을 하지 않으면 service Changed indication 기능을 통해서 서비스의 변경 사항을 indication 받을 수 없다.
또한, 클라이언트는 실제 프로파일에서 서버가 어떠한 기능을 수행할 수 있는지 알 수 없기 때문에 호환성으로 인하여 클라이언트와 서버간에 특정 기능을 수행할 수 없는 경우, 수행 가능한 기능으로 전환하여 서비스를 제공함에 따른 지연이 발생하게 된다는 문제점이 있다.
또한, 서비스 별로 구현된 다양한 절차들에 대한 정보를 클라이언트가 획득할 수 있는 방법이 없어서 호환성에 문제가 발생한다.
따라서, 본 발명은 이와 같은 문제점을 해결 하기 위해 서비스 정보의 길이가 긴 경우, 이를 송수신하기 위한 방법 및 특정 서비스를 바로 탐색할 수 있는 방법을 제공한다.
또한, 서비스들 간에 서로 다른 UUID 길이를 가진 경우에도 연속적으로 서비스를 탐색할 수 있으며, 서비스의 데이터가 변경된 경우, 이를 바로 인식할 수 있는 방법을 제안한다.
또한, 서비스 및 특성을 탐색하기 위해서 클라이언트와 서버간에 구현된 기능을 인식하기 위한 방법을 제안한다.
도 14는 본 발명에서 제안하는 Controller가 디바이스들의 서비스 정보를 획득하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 14를 참조하면, Controller는 각 디바이스들이 Client 역할 또는 Server 역할로 동작하는 서비스들의 정보를 획득하여, 특정 서비스에서 Client 역할을 수행하는 디바이스와 Server 역할을 수행하는 디바이스들이 연결을 형성하도록 제어할 수 있다.
구체적으로, First Device(300)은 주변 디바이스들이 First Device(300)를 탐색할 수 있도록 Advertising Channel에서 Advertising message를 전송한다(S14010).
이때, Advertising message는 First Device(300)가 지원하는 서비스들의 정보를 포함할 수 있다.
만약, Advertising 시간이 기존에 설정된 값에 맞춰서 제공되거나, 설정되지 않은 경우, First Device(300)는 Advertising Message를 계속해서 전송할 수 있다.
Controller(500)는 Advertising Channel에서 First Device(300)가 전송하는 Advertising message를 수신하는 경우, First Device(300)를 발견할 수 있다.
First Device(300)를 발견한 Controller(500)는 First Device(300)가 자신이 연결하고자 하는 디바이스인 경우, 예를 들면, First Device(300)가 이지 페어링 서비스를 제공하는 경우, First Device(300)로 연결 요청 메시지를 전송하여 First Device(300)와 블루투스 LE 연결을 형성한다(S14020).
이후, Controller(500)는 First Device(300)와 Bluetooth LE 연결을 형성 시키기 위한 디바이스를 탐색할 수 있다.
Controller(500)는 블루투스 LE를 지원하는 Device를 탐색하기 위해 Advertising Channel들을 통해 전송되는 Advertising Message를 수신할 수 있으며, Second Device(400)로부터 Advertising Channel을 통해 전송되는 Advertising message를 수신한 경우, Controller(500)는 Second Device(400)를 발견할 수 있다(S14030).
Second Device(400)를 발견한 Controller(500)는 Second Device(400)가 자신이 연결하고자 하는 디바이스인 경우, 예를 들면, Seconde Device가 이지 페어링 서비스를 제공하는 경우, Second Device(400)로 연결 요청 메시지를 전송하여 Second Device(400)와 블루투스 LE 연결을 형성한다(S14040).
이후, Controller(500)는 First Device(300)와 Second Device(400)를 연결 시키기 위해서 각 Device가 특정 서비스에서 어떤 역할을 수행하는지를 파악해야 된다.
즉, 특정 서비스에서 First Device(300)와 Second Device(400)가 모두 Client 역할 또는 Sever 역할을 수행할 수 없다면, Controller(500)가 First Device(300)와 Second Device(400)를 연결시키더라도 특정 서비스를 제공할 수 없게 된다.
따라서, Controller(500)는 First Device(300)로 First Device(300)가 클라이언트 역할로 동작하는 적어도 하나의 서비스와 관련된 특성의 정보를 요청하는 Read Request message 또는 Read By Type Request message를 전송한다(S14050).
이하, 본 발명에서 클라이언트 역할로 동작하는 적어도 하나의 서비스와 관련된 특성을 Client List Characteristic이라 호칭하고, Client List Characteristic에 포함되어 있는 정보를 Client List Characteristic Information(또는 제 1 특성 정보)라 한다.
단계 S14050에서 Controller(500)가 특성의 Handle Value를 알지 못하는 경우, 특성의 UUID를 포함하는 Read By Type Request message를 First Device(300)로 전송하고, 특성의 Handle Value를 알고 있는 경우, Handle Value를 포함하는 Read Request message를 전송한다.
이때, Read By Type Request message를 전송하는 경우, Read By Type Request message는 특성의 UUID, 판독을 시작할 Starting Handle number 및 판독을 종료할 Ending Handle number를 포함할 수 있다.
Controller(500)로부터 Read By Type Request message 또는 Read Request message를 수신한 First Device(300)는 Client List Characteristic Information을 포함하는 Read By Type Response message 또는 Read Response message를 Controller(500)로 전송한다(S14060).
이때, Read By Type Response message는 특성의 데이터 리스트 및 데이터의 길이를 포함할 수 있다.
First Device(300)로부터 Client 역할을 수행할 수 있는 적어도 하나의 서비스들의 정보를 획득한 Controller(500)는 Second Device(400)가 서버로 동작할 수 있는 서비스들이 존재하는지 알기 위해 Second Device(400)로 Read Request message 또는 Read By Type Request message를 전송한다(S14070).
즉, Controller(500)는 Second Device(400)로 Second Device(400)가 Sever 역할로 동작하는 적어도 하나의 서비스와 관련된 특성의 정보를 요청하는 Read Request message 또는 Read By Type Request message를 전송한다.
이하, 본 발명에서 서버 역할로 동작하는 적어도 하나의 서비스와 관련된 특성을 Server List Characteristic이라 호칭하고, Server List Characteristic에 포함되어 있는 정보를 Server List Characteristic Information(또는 제 2 특성 정보)라 한다.
단계 S14070에서 Controller(500)가 특성의 Handle Value를 알지 못하는 경우, 특성의 UUID를 포함하는 Read By Type Request message를 First Device(300)로 전송하고, 특성의 Handle Value를 알고 있는 경우, Handle Value를 포함하는 Read Request message를 전송한다.
이때, Read By Type Request message를 전송하는 경우, Read By Type Request message는 특성의 UUID, 판독을 시작할 Starting Handle number 및 판독을 종료할 Ending Handle number를 포함할 수 있다.
Controller(500)로부터 Read By Type Request message 또는 Read Request message를 수신한 Second Device(400)는 Server List Characteristic Information을 포함하는 Read By Type Response message 또는 Read Response message를 Controller(500)로 전송한다(S14080).
이때, Read By Type Response message는 특성의 데이터 리스트 및 데이터의 길이를 포함할 수 있다.
Controller(500)는 단계 S14050 및 단계 S14060을 통해서 First Device(300)가 Client 역할로 동작하는 서비스들의 정보를 획득하고, 단계 S14070 및 단계 S14080을 통해서 Second Device(400)가 Server 역할로 동작하는 서비스들의 정보를 획득할 수 있다.
Controller(500)는 특정 서비스에서 First Device(300)가 Client로 동작하고, Secon Device가 Server로 동작하는 경우, First Device(300)와 Second Device(400)를 Bluetooth LE 통해 연결 시킬 수 있으며, First Device(300)와 Second Device(400)는 블루투스 LE의 연결이 형성된 뒤, 특정 서비스를 제공할 수 있다.
이와 같은 방법을 통해서 Controller(500)는 디바이스가 특정 역할을 수행할 수 있는 서비스들의 정보를 획득할 수 있으며, 획득된 서비스 정보에 기초하여 각 디바이스들의 역할에 맞게 연결이 형성되도록 제어할 수 있다.
도 15 내지 도 17은 본 발명에서 제안하는 디바이스가 클라이언트 역할로 동작하는 서비스와 관련된 특성의 일 예를 나타낸 도이다.
도 15 내지 도 17을 참조하면, 도 14에서 설명한 Client List Characteristic은 UUID의 비트에 따른 각 서비스의 정보를 포함하고 있다.
구체적으로, Client List Characteristic은 Device에서 제공되는 모든 Client 기능의 리스트 정보를 제공할 수 있다. 예를 들면, Client List Characteristic은 primary service로 정의된 기능에 대한 정보 및 included service로 정의된 기능에 대한 정보를 제공할 수 있다.
Controller(500)는 Client List Characteristic를 Read Request message를 통해서 판독함으로써, 디바이스에서 제공할 수 있는 client 기능을 확인할 수 있다.
또한, Client List Characteristic는 Device System에 의해서 Write 되어야 하며, 외부 장치(예를 들면, 인증되지 않은 장치 등)는 Client List Characteristic의 값을 write 할 수 없다.
Client List Characteristic의 16bit UUID List 필드, 32bit UUID List 필드 및 128 bit UUID List 필드는 각각의 기본 단위인 16bit/32bit/128bit 의 정보를 연속적으로 제공 할 수 있다.
Client List Characteristic은 Easy Pairing service의 Characteristic 으로 제공되거나 GATT Profile의 기본 Characteristic 으로 제공될 수 있다.
만약, Controller(500)가 Read Request By UUID Procedure를 사용하게 되면 Characteristic Discovery 없이 바로 데이터 요청이 가능하다.
도 15에 도시된 바와 같이 Client List Characteristic은 아래와 같은 필드를 포함할 수 있다.
- Client List Information: 특성에 포함된 Client 역할로 동작하는 service의 UUID 정보.
- Num Of 16bit UUID List: 16 bit UUID 정보의 개수
- 16bit UUID List: 16 bit UUID 정보의 목록
- Num Of 32bit UUID List: 32 bit UUID 정보의 개수
- 32bit UUID List: 32 bit UUID 정보의 목록
- Num Of 128bit UUID List: 128 bit UUID 정보의 개수
- 128bit UUID List: 128 bit UUID 정보의 목록
도 15에 도시된 Client List Characteristic은 디바이스가 Client 기능을 수행할 수 있는 서비스들의 정보를 비트에 따라 모두 포함하고 있다.
도 16은 도 15와는 다른 Client List Characteristic의 일 예를 도시한다.
도 16에 도시된 바와 같이, Client List Characteristic은 각 bit에 따라 서로 다른 특성으로 구성될 수 있다.
즉, 16bit의 UUID 값을 가지는 서비스들의 정보들이 하나의 특성으로 구성되고, 32bit의 UUID 값을 가지는 서비스들의 정보들이 또 다른 하나의 특성으로 구성되며, 128bit의 UUID 값을 가지는 서비스들의 정보들이 또 다른 하나의 특성으로 구성될 수 있다.
도 16에 도시된 특성을 사용하면, 각 bit에 따라 별도의 특성의 값을 판독하면 되기 때문에, 메시지의 크기를 감소시킬 수 있다.
도 16에 도시된 특성의 구조는 도 14에서 설명한 Server List Characteristic의 구조로 사용될 수 있다.
도 17은 도 15에 도시된 Client List Characteristic에 포함된 Client List Information의 일 예를 도시한다.
Client List Information은 앞에서 살펴본 바와 같이 특성에 포함된 Client 역할로 동작하는 service의 UUID 정보를 제공한다. 즉, Client List Information는 각 bit의 UUID가 존재하는지 여부를 나타낸다.
도 17의 (a)에서 0th bit는 16 bit UUID가 존재하는지 여부를 나타내고, 1th bit는 32 bit UUID가 존재하는지 여부를 나타내며, 2th bit는 128bit UUID가 존재하는지 여부를 나타낸다.
예를 들어, 도 17의 (a)에서 0th bit가 1인 경우, 16bit UUID 정보가 존재하며, Num of 16 bit UUID List 필드 및 16 bit UUID List 필드들이 존재한다. 하지만, 0th bit가 0이면 16bit UUID 정보가 존재하지 않으며, Client List Characteristic이 Num of 16bit UUID List 필드 및 16bit UUID List 필드를 포함하지 않는다.
또한, 1th bit가 1인 경우, 32 bit UUID 정보가 존재하며, Num of 32 bit UUID List 필드 및 32 bit UUID List 필드들이 존재한다. 하지만, 1th bit가 0이면 32bit UUID 정보가 존재하지 않으며, Client List Characteristic이 Num of 32bit UUID List 필드 및 32bit UUID List 필드를 포함하지 않는다.
또한, 2th bit가 1인 경우, 128 bit UUID 정보가 존재하며, Num of 128 bit UUID List 필드 및 128 bit UUID List 필드들이 존재한다. 하지만, 2th bit가 0이면 128bit UUID 정보가 존재하지 않으며, Client List Characteristic이 Num of 128bit UUID List 필드 및 128bit UUID List 필드를 포함하지 않는다.
도 17의 (b)는 Client List Information 필드의 또 다른 구조를 나타내는 도이다.
도 17의 (b)에서 각 bit는 아래와 같이 정의된다.
- 0th bit: 1인 경우, 16bit UUID 정보가 존재하고, Num of 16bit UUID List 필드 및 16bit UUID List 필드가 Client List Characteristic에 포함된다. 하지만, 0이면 16bit UUID 정보가 존재하지 않고, Num of 16bit UUID List 필드 및 16bit UUID List 필드가 Client List Characteristic에 포함되지 않는다
- 1st bit: 1인 경우, 32bit UUID 정보가 존재하고, Num of 32bit UUID List 필드 및 32bit UUID List 필드가 Client List Characteristic에 포함된다. 하지만, 0이면 32bit UUID 정보가 존재하지 않고, Num of 32bit UUID List 필드 및 32bit UUID List 필드가 Client List Characteristic에 포함되지 않는다
- 2nd bit: 1인 경우, 128bit UUID 정보가 존재하고, Num of 128bit UUID List 필드 및 128bit UUID List 필드가 Client List Characteristic에 포함된다. 하지만, 0이면 128bit UUID 정보가 존재하지 않고, Num of 128bit UUID List 필드 및 128bit UUID List 필드가 Client List Characteristic에 포함되지 않는다
- 5th bit: 1인 경우, 16bit UUID 가 존재하지만, 전체 서비스들의 리스트 정보를 제공할 수 없다는 것을 나타낸다. 따라서, 추가 정보를 요청하여 16bit UUID가 할당된 서비스들의 정보를 획득할 수 있다.
- 6th bit: 1인 경우, 32bit UUID 가 존재하지만, 전체 서비스들의 리스트 정보를 제공할 수 없다는 것을 나타낸다. 따라서, 추가 정보를 요청하여 32bit UUID가 할당된 서비스들의 정보를 획득할 수 있다.
7th bit: 1인 경우, 128bit UUID 가 존재하지만, 전체 서비스들의 리스트 정보를 제공할 수 없다는 것을 나타낸다. 따라서, 추가 정보를 요청하여 128bit UUID가 할당된 서비스들의 정보를 획득할 수 있다.
도 17의 (c)는 Client List Information 필드의 또 다른 구조를 나타내는 도이다.
도 17의 (c)에서 각 필드는 bit에 따라 아래와 같이 정의된다.
- 16bit UUID List:
0b00: 16bit UUID 를 정보가 없음.
0b01: 완전한 16bit UUID 정보를 제공하고 있음
0b10: 불완전한 16bit UUID 정보를 제공하고 있으며, 추가 정보를 요청하는 경우, 추가 정보를 제공 할 수 있음.
0b11: 불완전한 16bit UUID 정보를 제공하고 있지만, 추가 정보를 제공할 수 없음.
- 32bit UUID List:
0b00: 32bit UUID 를 정보가 없음.
0b01: 완전한 32bit UUID 정보를 제공하고 있음
0b10: 불완전한 32bit UUID 정보를 제공하고 있으며, 추가 정보를 요청하는 경우, 추가 정보를 제공 할 수 있음.
0b11: 불완전한 32bit UUID 정보를 제공하고 있지만, 추가 정보를 제공할 수 없음.
- 128bit UUID List:
0b00: 128bit UUID 를 정보가 없음.
0b01: 완전한 128bit UUID 정보를 제공하고 있음
0b10: 불완전한 128bit UUID 정보를 제공하고 있으며, 추가 정보를 요청하는 경우, 추가 정보를 제공 할 수 있음.
0b11: 불완전한 128bit UUID 정보를 제공하고 있지만, 추가 정보를 제공할 수 없음.
도 18은 본 발명에서 제안하는 디바이스가 서버 역할로 동작하는 서비스와 관련된 특성의 일 예를 나타낸 도이다.
도 18의 (a)는 도 14에서 설명한 디바이스가 서버 역할로 동작하는 적어도 하나의 서비스와 관련된 특성인 Server List Characteristic의 일 예를 도시하고, 도 18의 (b)는 Server List Characteristic에 포함된 필드의 일 예를 도시한다.
도 18의 (a)를 참조하면, 도 14에서 설명한 Server List Characteristic은 UUID의 비트에 따른 각 서비스의 정보를 포함하고 있다.
구체적으로, Server List Characteristic은 Device에서 제공되는 모든 Server 기능의 리스트 정보를 제공할 수 있다. 예를 들면, Server List Characteristic은 primary service로 정의된 기능에 대한 정보 및 included service로 정의된 기능에 대한 정보를 제공할 수 있다.
Controller(500)는 Server List Characteristic를 Read Request message를 통해서 판독함으로써, 디바이스에서 제공할 수 있는 Server 기능을 확인할 수 있다.
또한, Server List Characteristic는 Device System에 의해서 Write 되어야 하며, 외부 장치(예를 들면, 인증되지 않은 장치 등)는 Server List Characteristic의 값을 write 할 수 없다.
Server List Characteristic의 16bit UUID List 필드, 32bit UUID List 필드 및 128 bit UUID List 필드는 각각의 기본 단위인 16bit/32bit/128bit 의 정보를 연속적으로 제공 할 수 있다.
Server List Characteristic은 Easy Pairing service의 Characteristic 으로 제공되거나 GATT Profile의 기본 Characteristic 으로 제공될 수 있다.
만약, Controller(500)가 Read Request By UUID Procedure를 사용하게 되면 Characteristic Discovery 없이 바로 데이터 요청이 가능하다.
도 18의 (a)에 도시된 바와 같이 Server List Characteristic은 아래와 같은 필드를 포함할 수 있다.
- Server List Information: 특성에 포함된 Server 역할로 동작하는 service의 UUID 정보.
- Num Of 16bit UUID List: 16 bit UUID 정보의 개수
- 16bit UUID List: 16 bit UUID 정보의 목록
- Num Of 32bit UUID List: 32 bit UUID 정보의 개수
- 32bit UUID List: 32 bit UUID 정보의 목록
- Num Of 128bit UUID List: 128 bit UUID 정보의 개수
- 128bit UUID List: 128 bit UUID 정보의 목록
도 18의 (a)에 도시된 Server List Characteristic은 디바이스가 Client 기능을 수행할 수 있는 서비스들의 정보를 비트에 따라 모두 포함하고 있다.
본 발명의 또 다른 실시 예로 Server List Characteristic은 도 18의 (a)에 도시된 구조 외에, 도 16에 도시된 것과 같이 각 UUID의 bit에 따라 별도의 특성으로 구성될 수 있다.
도 18의 (b)는 도 18의 (a)에 도시된 Server List Characteristic에 포함된 Server List Information의 일 예를 도시한다.
Server List Information은 앞에서 살펴본 바와 같이 특성에 포함된 Server 역할로 동작하는 service의 UUID 정보를 제공한다. 즉, Server List Information는 각 bit의 UUID가 존재하는지 여부를 나타낸다.
도 18의 (b)에서 0th bit는 16 bit UUID가 존재하는지 여부를 나타내고, 1th bit는 32 bit UUID가 존재하는지 여부를 나타내며, 2th bit는 128bit UUID가 존재하는지 여부를 나타낸다.
예를 들어, 도 18의 (b)에서 0th bit가 1인 경우, 16bit UUID 정보가 존재하며, Num of 16 bit UUID List 필드 및 16 bit UUID List 필드들이 존재한다. 하지만, 0th bit가 0이면 16bit UUID 정보가 존재하지 않으며, Client List Characteristic이 Num of 16bit UUID List 필드 및 16bit UUID List 필드를 포함하지 않는다.
또한, 1th bit가 1인 경우, 32 bit UUID 정보가 존재하며, Num of 32 bit UUID List 필드 및 32 bit UUID List 필드들이 존재한다. 하지만, 1th bit가 0이면 32bit UUID 정보가 존재하지 않으며, Client List Characteristic이 Num of 32bit UUID List 필드 및 32bit UUID List 필드를 포함하지 않는다.
또한, 2th bit가 1인 경우, 128 bit UUID 정보가 존재하며, Num of 128 bit UUID List 필드 및 128 bit UUID List 필드들이 존재한다. 하지만, 2th bit가 0이면 128bit UUID 정보가 존재하지 않으며, Client List Characteristic이 Num of 128bit UUID List 필드 및 128bit UUID List 필드를 포함하지 않는다.
또한, 본 발명의 또 다른 실시 예로, Server List Information은 도 17의 (b) 또는 (c)와 같은 구조를 가질 수 있다.
도 19는 본 발명에서 제안하는 특성 정보가 일정 크기 이상인 경우, 복수의 메시지를 통해 특성 정보를 송수신하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 19를 참조하면, 특성 정보의 길이가 일정 길이 이상인 경우, 특성 정보를 일정 길이로 나누어서 전송 받을 수 있다.
먼저, 단계 S19010 및 단계 S19020은 도 14의 단계 S14010 및 단계 S14020과 동일하므로 설명을 생략하도록 한다.
First Device(300)와 Bluetooth LE를 통한 연결을 형성한 Controller(500)는 First Device(300)로 First Device(300)가 클라이언트 역할로 동작하는 적어도 하나의 서비스와 관련된 특성인 Client List Characteristic의 정보를 요청하는 Read by Type Request message 또는 Read Request Message를 전송한다(S19030).
만약, Controller(500)가 Read by Type Request message를 전송한 경우, Read by Type Request message는 Client List Characteristic의 UUID를 포함할 수 있다.
First Device(300)는 Client List Characteristic의 특성 정보의 길이가 일정 길이 이상인 경우(예를 들면, 메시지에 포함될 수 있는 길이 보다 긴 경우 등), Read by Type Response message에 Client List Characteristic의 특성 정보를 포함하여 Controller(500)로 전송할 수 없다.
따라서, First Device(300)는 Controller(500)로 특성 정보를 전송할 수 없는 이유를 나타내는 에러 정보 및 Client List Characteristic의 Handle 정보를 포함하는 에러 응답 메시지를 Controller(500)로 전송한다(S19040).
이때, 상기 에러 정보는 특성 정보의 길이가 일정 길이 이상이기 때문에 Read by Type Response message를 통해서 전송될 수 없다는 것을 나타낼 수 있다.
Controller(500)는 First Device(300)로 Client List Characteristic의 특성 정보를 나눠서 전송 받기 위해 에러 메시지에 포함된 핸들 정보 및 Offset을 포함하는 Read Blob Request message를 전송한다(S19050).
이때, 최초의 Read Blob Request message에 포함된 Offset은 0이다.
First Device(300)는 Read Blob Request message를 통해서 요청된 Handle 값의 데이터를 Offset 위치부터 Read Blob Response message에 포함시켜 Controller(500)로 전송한다(S19060).
이때, Read Blob Response message를 통해서 전송할 수 있는 정보의 길이는 ATT_MTU의 값과 동일하다.
이후, Controller(500)는 전송되지 못한 정보를 추가적으로 요청하기 위한 Read Blob Request message를 First Device(300)로 전송한다(S19070).
이때, 단계 S19070에서 전송되는 Read Blob Request message에 포함된 Offset은 실제로 Controller(500)가 전송 받은 정보의 길이를 고려하여 전송 받고자 하는 데이터의 위치를 나타낸다(예를 들면, Controller(500)가 50bytes를 전송 받은 경우, Offset은 51이라는 값을 나타낸다).
First Device(300)는 Offset이 나타내는 위치부터 ATT_MTU가 나타내는 길이 큼의 정보를 포함하는 Read Blob Response message를 Controller(500)로 전송한다(S19080).
이와 같은 방법을 통해서 크기가 일정 크기 이상인 특성 정보들도 여러 번의 전송을 걸쳐서 전송 받을 수 있다.
도 20 및 도 21은 본 발명에서 제안하는 서비스의 구조와 관련된 특성의 일 예를 나타낸 도이다.
도 20 및 도 21을 참조하면, 디바이스는 상대방 디바이스에서 제공할 수 있는 서비스들의 구조를 나타내는 특성의 정보를 획득함으로써, 상대방 디바이스의 primary service의 정보와 primary service와 관련된 included service의 정보를 획득할 수 있다.
이하, 서비스들의 구조를 나타내는 특성을 Structure Information Characteristic이라 한다.
구체적으로, Structure Information Characteristic은 디바이스에서 제공할 수 있는 모든 서비스들의 구조정보를 포함할 수 있다.
Controller(500)는 Read Request Message를 First Device(300) 또는 Second Device(400)로 전송하고, First Device(300) 또는 Second Device(400)로부터 전송되는 Read Response Message에 포함된 Structure Information Characteristic의 특성 정보(제 2 특성 정보)를 획득할 수 있다.
Controller(500)는 First Device(300) 또는 Second Device(400)로부터 획득한 Structure Information Characteristic의 특성 정보를 통해서 First Device(300) 또는 Second Device(400)에서 제공할 수 있는 Client 기능 또는 Server 기능을 한번에 확인할 수 있다.
Structure Information Characteristic는 Device System에 의해서 Write 되어야 하며, 외부 장치(예를 들면, 인증되지 않은 장치 등)는 Structure Information Characteristic의 값을 write 할 수 없다.
도 20의 (a)에 도시된 바와 같이 Structure Information Characteristic은 아래와 같은 필드를 포함할 수 있다.
- # of primary service: primary service 의 개수.
- Length of primary service: primary service의 길이를 나타내는 필드로 아래와 같이 primary service1 Type 부터 복수의 included service 의 정보까지의 길이를 나타낸다.
1개의 primary service 정보 (primary service1 Type, primary service1 UUID, Start handle, End Handle)
복수 개의 included service 의 정보 (Length of included service, included service1 type, included service UUID, Start Handle, End Handle)
Included service 의 정보가 복수 개 이면 해당 정보가 반복됨.
- primary service Type: primary service의 UUID type.
- primary service UUID: primary service의 UUID (16bit/32bit/128bits).
- Start Handle of primary service1: primary service 의 시작 핸들.
- End Handle of primary service1: primary service 의 끝 핸들.
- Length of included service1: included service의 길이를 나타내며, included service Type 부터 End handle까지의 길이를 의미한다.
- included service1 Type: included service 1의 UUID type.
- included service UUID: included service의 UUID (16bit/32bit/128bits).
- Start Handle of included service: included service 의 시작 핸들.
- End Handle of included service1: included service1 의 끝 핸들.
# of primary service의 값이 1보다 큰 값인 경우, 도 19의 Length of primary service 필드부터 End Handle of included service 필드가 # of primary service의 값만큼 반복될 수 있다.
도 21은 # of primary service의 값이 2인 경우, primary service가 2개인 경우의 Structure Information Characteristic의 일 예를 도시한다.
도 20의 (b)는 Structure Information Characteristic의 primary service Type 필드 또는 included service Type 필드의 일 예를 나타낸 도이다.
도 20의 (b)에서 각 bit들은 아래와 같이 정의된다.
7th bit: primary service인지 included service인지 여부를 나타내는 bit. 예를 들면, 0b0인 경우, primary service를 나타내고, 0b1인 경우, included service를 나타낼 수 있다.
6th bit: 7th bit를 통해 알 수 있는 서비스의 정보에 변경 사항이 있는지 여부를 나타내는 bit. 예를 들면, 0b0인 경우, 변경 사항이 없다는 것을 나타내고, 0b1인 경우, 변경 사항이 존재한다는 것을 나타낼 수 있다.
1st bit 및 0th bit: 7th bit를 통해 알 수 있는 서비스의 UUID bit 수를 나타내는 bit. 예를 들면, 0b10인 경우, 128 bit UUID List를 나타내고, 0b01인 경우, 32 bit UUID List를 나타내며, 0b00인 경우, 16bit UUID List를 나타낼 수 있다.
컨트롤러 또는 Client는 7th bit 및 6th bit의 값을 판독함으로써, 어느 서비스의 정보에 변동이 생겼는지 여부를 알 수 있으며, 변동이 생긴 서비스의 정보만을 다시 판독할 수 있다.
예를 들면, 7th bit의 값이 0b0이고, 6th bit의 값이 0b1인 경우, Controller(500) 또는 Client는 primary service의 정보에 변동이 생겼다는 것을 알 수 있으며, 해당 서비스의 Start Handle 부터 End Handle을 다시 판독함으로써 변동된 정보를 획득할 수 있다.
본 발명의 또 다른 실시 예로 각 특성의 Hash 값의 변경을 통해서 Controller(500) 또는 client에게 특성 값이 변동되었다는 것을 알릴 수 있다.
예를 들면, 특정 특성의 Hash 값이 증가하거나 감소된 경우, 특정 특성의 정보가 변동되었다는 것을 Controller(500) 또는 Client가 인식할 수 있으며, 해당 특성의 정보를 다시 판독함으로써 변동된 정보를 획득할 수 있다.
이와 같은 방법을 통해서 특정 서비스의 정보만 변동된 경우, 다시 처음부터 서비스 탐색 절차를 거치지 않고서도 변동된 서비스의 정보만을 알 수 있어 불필요한 절차를 다시 수행하지 않을 수 있다.
도 22는 본 발명에서 제안하는 서비스와 관련된 정보가 변경된 경우, 변경된 서비스의 정보를 송수신하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 22을 참조하면, 특정 서비스의 정보가 변경된 경우, 디바이스는 이를 나타내는 특성을 판독함으로써, 특정 서비스의 정보가 변경되었다는 것을 인식할 수 있으며, 변경된 서비스의 정보를 요청하여 전송 받을 수 있다.
먼저, 단계 S22010 및 단계 S22020은 도 14의 단계 S14010 및 단계 S14020과 동일하므로 설명을 생략하도록 한다.
Controller(500)는 First Device(300)와 Bluetooth LE 연결을 형성한 뒤, First Device(300)가 Client로 동작하는 모든 서비스들의 구조를 알기 위해 First Device(300)로 도 20에서 설명한 서비스들의 구조를 나타내는 특성인 Structure Information Characteristic의 판독을 요청하는 Read by Type Request message를 전송한다(S22030).
이때, Read by Type Request message는 Structure Information Characteristic의 UUID를 포함할 수 있다.
First Device(300)는 Structure Information Characteristic의 특성 정보가 Read by Type Response message를 통해서 전송될 수 있는 경우, Controller(500)로 Structure Information Characteristic의 특성 정보를 포함하는 Read by Type Response message를 전송한다(S22040).
하지만, Structure Information Characteristic의 특성 정보가 Read by Type Response message를 통해서 전송될 수 없는 경우, Structure Information Characteristic의 특성 정보는 도 19에서 설명한 방법을 통해서 Controller(500)로 전송될 수 있다.
First Device(300)로부터 특성 정보를 전달 받은 Controller(500)는 도 20의 (b)에서 설명한 service Type 필드를 통해 First Device(300)의 primary 서비스 또는 included service의 정보가 변동되었는지 여부를 인식할 수 있다(S22050).
만약, service Type 필드가 특정 서비스의 정보가 변동되었다는 것을 나타내는 경우, Controller(500)는 변동된 서비스의 정보를 요청하기 위해 First Device(300)로 Read Blob Request message를 전송한다(S22060).
이때, Read Blob Request message는 변동된 특성의 Handle 값 및 변동된 데이터의 위치를 나타내는 Offset을 포함할 수 있다.
First Device(300)는 변동된 특성의 데이터를 Offset 위치부터 ATT_MTU 길이만큼 Read Blob Response message를 통해서 Controller(500)로 전송한다(S22070).
이와 같은 방법을 통해서 Controller(500)는 어떤 서비스의 정보가 변동되었는지 여부를 인식할 수 있으며, 변동된 데이터만 전송 받을 수 있다.
도 23은 본 발명에서 제안하는 특성 정보가 추가 정보를 제공할 수 있는 경우, 추가적인 요청을 통해 추가 정보를 송수신하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 23을 참조하면, Controller(500) 또는 Client는 Server의 특성 정보에 추가적인 추가 정보가 존재하는 경우, 추가 정보를 요청하는 요청 메시지를 전송하여 추가 정보를 획득할 수 있다.
먼저, 단계 S23010 및 단계 S23020은 도 14의 단계 S14010 및 단계 S14020과 동일하므로 설명을 생략하도록 한다.
이후, First Device(300)와 Bluetooth LE를 통한 연결을 형성한 Controller(500)는 First Device(300)로 First Device(300)가 클라이언트 역할로 동작하는 적어도 하나의 서비스와 관련된 특성인 Client List Characteristic의 정보를 요청하는 Read by Type Request message 또는 Read Request Message를 전송한다(S23030).
First Device(300)는 Client List Characteristic의 특성 정보를 포함하는 Read by Type Response message를 Controller(500)로 전송한다(S23040).
이때, Client List Characteristic의 client List Information의 구조가 도 17의 (C)와 같은 경우, Controller(500)는 Client List Information 필드를 통해서 추가 정보가 존재하는지 여부를 인식할 수 있다.
만약, 각 UUID List의 bit가 0b01 또는 0b11인 경우, Controller(500)는 First Device(300) 추가 정보를 제공할 수 없다고 인식하고, 절차는 종료되게 된다.
하지만, 각 UUID List의 bit가 0b11 인 경우, Controller(500)는 First Device(300)가 불완전한 정보를 전송하였다고 인식한다.
즉, Controller(500)는 First Device(300)가 Client List Characteristic의 정보 중 일부 정보만을 전송하였으며, Client List Characteristic의 추가적인 특성 정보를 전송할 수 있다고 인식한다(S23050).
추가 정보의 존재 및 전송 가능여부를 인식한 Controller(500)는 First Device(300)로 추가 정보를 요청하는 Read by Type Request message를 전송하고, 추가 정보를 포함하는 Read by Type Response message를 First Device(300)로부터 수신할 수 있다(S23060, S23070).
이때, 추가 정보는 해당 특성의 UUID 값을 Read by Type Request message에 포함시켜 전송함으로써, 요청할 수 있다.
또한, Read by Type Response message는 Read by Type Request message에 포함된 UUID를 가지는 Attribute의 길이와 데이터를 포함할 수 있다.
이와 같은 방법을 통해서 특정 특성에 추가적인 정보가 존재하는지 여부 및 추가 정보를 제공할 수 있는지 여부를 인식하여 추가 정보를 전송 받을 수 있다.
도 24는 본 발명에서 제안하는 특성 정보가 변경된 경우, 변경된 특성 정보를 송수신하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 24를 참조하면, 디바이스의 특성 정보가 변경된 경우, 디바이스는 특정 특성을 판독하여 특성 정보가 변동되었는지 여부를 인식할 수 있으며, 변경된 특성 정보를 획득할 수 있다.
먼저, 단계 S24010 및 단계 S24020은 도 14의 단계 S14010 및 단계 S14020과 동일하므로 설명을 생략하도록 한다.
First Device(300)와 Bluetooth LE 연결을 형성한 Controller(500)는 First Device(300)의 특성 값이 변경되었는지 여부를 확인하기 위해서, First Device(300)로 특성 값의 변경 여부와 관련된 특성의 정보를 요청하는 Read by Type Request message를 전송한다(S24030).
이하, 본 발명에서 특성 값의 변경 여부와 관련된 특성을 Changed Characteristic list Characteristic이라 호칭하고, Changed Characteristic list Characteristic에 포함되어 있는 정보를 Changed Characteristic list Characteristic Information이라 한다.
이때, Read by Type Request message는 Changed Characteristic list Characteristic의 UUID를 포함할 수 있다.
First Device(300)는 Changed Characteristic list Characteristic의 UUID가 할당된 Attribute의 길이와 데이터를 포함하는 Read by Type Response message를 Controller(500)로 전송한다(S24040).
Changed Characteristic list Characteristic의 값을 통해 Controller(500)는 First Device(300)의 특성들 중에 값이 변경된 특성이 있는지 여부를 판단할 수 있다(S24050).
만약, 특성의 값이 변경된 특성이 존재하는 경우, Controller(500)는 First Device(300)로 변경된 특성의 값을 요청하는 Read Request message를 전송한다(S24060).
이때, Read Request message는 변경된 특성의 Handle 정보를 포함할 수 있다.
First Device(300)는 Controller(500)로부터 요청 받은 UUID가 할당된 특성의 값을 포함하는 Read Response Message를 Controller(500)로 전송한다(S24070).
이와 같은 방법을 통해서 Controller(500)는 First Device(300)의 특성 값이 변경되었다는 것을 인식할 수 있으며, 변경된 특성 값을 전송 받을 수 있다.
만약, 변경된 특성 값이 복수 개인 경우, Controller(500)는 단계 S24060 및 단계 S24070을 반복적으로 수행하여 변경된 복수의 특성 값을 전송 받을 수 있다.
본 실시 예에서 characteristic들은 공용 characteristic으로 특정 handle 값을 사용할 수 있다.
또한, 공용 Characteristic인 경우, Read Long Characteristic Value 절차를 characteristic 발견 절차 없이 실시함으로써, 손쉽게 정보를 요청할 수 있다.
도 25 및 도 26은 본 발명에서 제안하는 특성 정보의 변경 여부와 관련된 특성의 일 예를 나타낸 도이다.
도 25 및 도 26을 참조하면, 도 24에서 설명한 Changed Characteristic list Characteristic은 디바이스에서 변경된 특성과 관련된 정보를 포함할 수 있다.
구체적으로, Changed Characteristic list Characteristic이 특정 디바이스 내의 변경된 모든 서비스들의 characteristic 변경 사항을 포함하는 경우, 디바이스는 하나의 Changed Characteristic list Characteristic 만을 포함할 수 있다.
하지만, Changed Characteristic list Characteristic가 특정 서비스 별로 서비스의 characteristic 변경 사항을 제공하는 경우, Changed Characteristic list Characteristic는 각 서비스별로 존재할 수 있다.
Changed Characteristic list Characteristic을 client가 판독하면, 서버에서 변경된 characteristic 정보를 알 수 있고, 변경된 characteristic의 정보를 선택적으로 읽어올 수 있다.
따라서, 서버에 재 연결하는 client 는 다시 characteristic discovery 를 하지 않고도 변경 사항을 읽어 와서 연결 시간 및 데이터 전송 시간을 단축 시킬 수 있다.
해당 특성의 정보는 Devic 또는 각 서비스 별로 write 되어야 하며, 외부 장치(예를 들면, 인증되지 않은 장치 등)는 Structure Information Characteristic의 값을 write 할 수 없다.
도 25의 (a)는 Changed Characteristic list Characteristic의 구조의 일 예를 도시한다.
도 25의 (a)에 도시된 바와 같이, Changed Characteristic list Characteristic은 아래와 같은 필드를 포함할 수 있다.
- Number Of Changed Characteristic: 변경된 Characteristic의 개수
- Handle of Characteristic: 정보가 변경된 characteristic의 핸들 값(위치 값).
- Changed Contents: 변경된 내용으로써, Characteristic의 변경 사항을 나타낸다.
만약, Number Of Changed Characteristic 필드의 값이 복수이면, Handle of Characteristic 필드 및 Changed Contents 필드가 Number Of Changed Characteristic 필드의 값만큼 반복되어 존재한다.
도 25의 (b)는 도 25의 (a)에서 Changed Contents 필드의 일 예를 도시한다.
Changed Contents 필드에서 0th bit가 ‘1’이면, Characteristic의 값이 변경되었다는 것을 나타내고 ‘0’이면 변경되지 않았다는 것을 나타낸다.
1th bit가 ‘1’이면 Characteristic의 선언 부분이 변경되었다는 것을 나타내고, ‘0’이면 변경되지 않았다는 것을 나타낸다.
Changed Method 필드는 Characteristic의 추가, 삭제 또는 변경 여부를 나타낸다. 예를 들면, Changed Method의 각 비트 값은 따라 아래와 같이 정의 될 수 있다.
-0b00: Added(새로운 Characteristic이 생성되었다는 것을 나타내며, 0th 및 1st bit 모두 ‘0’의 값을 가져야 한다. 또한, 클라이언트는 서버로부터 해당 값을 새롭게 판독해야 한다).
-0b01: Deleted(기존 Characteristic이 삭제되었다는 것을 나타내며, 0th 및 1st bit 모두 ‘0’의 값을 가져야 한다. 또한, Client는 저장된 Characteristic의 값을 삭제해야 한다).
-0b10: Modified(기존 Characteristic이 변경되었다는 것을 나타내며, 0th 및 1st bit의 값에 따라 value 또는 Declaration 부분이 변경되었다는 것을 나타냄. Client는 변경된 부분을 Server로부터 새롭게 판독해야 한다.
도 26의 (a)는 Changed Characteristic list Characteristic의 구조의 또 다른 일 예를 도시한다.
도 26의 (a)에 도시된 바와 같이, Changed Characteristic list Characteristic은 아래와 같은 필드를 포함할 수 있다.
- Number Of Changed Characteristic: 변경된 Characteristic의 개수
- UUID type: Characteristic 의 UUID 유형을 나타내며, 다음필드에 포함되는 Characteristic의 UUID 종류를 정의할 수 있다(예를 들면, 01은 16 bit UUID를, 02는 32 bit UUID를, 03은 128 bit UUID를 나타낼 수 있다).
- UUID of Characteristic: 변경된 Characteristic의 UUID
- Changed Contents: 변경된 내용으로써, Characteristic의 변경 사항을 나타낸다.
만약, Number Of Changed Characteristic 필드의 값이 복수이면, UUID type 필드, UUID of Characteristic 필드 및 Changed Contents 필드가 Number Of Changed Characteristic 필드의 값만큼 반복되어 존재한다.
도 26의 (b)는 도 26의 (a)에서 Changed Contents 필드의 일 예를 도시하며, 도 25의 (b)와 동일하므로 설명을 생략하도록 한다.
도 19 내지 도 26에서 설명한 방법은 Controller(500)와 Client 역할을 수행하는 First Device(300)간의 실시 예들로 설명하였지만, Controller(500)와 Server 역할을 수행하는 Second Device(400)간에도 적용될 수 있음은 물론이다.
도 27 및 도 28은 본 발명에서 제안하는 서비스 및 특성의 변경 여부를 인식하기 위한 방법 및 데이터 포맷의 일 예를 나타내는 도면이다.
도 27 및 도 28을 참조하면, 디바이스들을 제어하는 제어 디바이스인 클라이언트는 제어되는 디바이스인 서버의 서비스 및 특성이 변경된 경우, 이를 인식하여 탐색할 수 있다.
구체적으로, 서버의 서비스 정보가 변경되거나 서비스의 데이터들이 변경되는 경우, 클라이언트는 서비스 탐색 및 특성 탐색 절차를 통해서 모든 서비스를 탐색한다.
하지만, 서비스는 변경되지 않고, 서비스의 데이터만 변경되는 경우에도 모든 서비스를 다시 탐색하는 것은 비효율적이다. 따라서, 클라이언트는 서버로부터 서비스의 변경 및 데이터의 변경을 각각 나타내는 정보를 수신하고, 수신된 정보에 따라 변경된 서비스 및/또는 데이터만을 탐색할 수 있다.
구체적으로, 서버의 특정 특성은 서버의 서비스 및 서비스의 데이터가 변경되는 경우, 이를 나타내는 특성 값을 포함할 수 있다.
이하, 이러한 서버의 서비스 및 서비스의 데이터 변경 여부를 나타내는 특성을 Changed information 특성이라 한다.
Changed information 특성은 도 28에 도시된 바와 같이 service modification 필드 및 characteristic value modification 필드를 포함할 수 있다.
Service modification 필드는 서버의 서비스 변경 여부를 나타내는 필드로써, 새로운 서비스의 추가, 기존 서비스 삭제 및 서비스의 새로운 특성 추가 및 삭제 등을 나타낸다.
즉, Service modification 필드의 값이 변경되는 경우, 클라이언트는 서버의 서비스가 변경되었다는 것을 인식할 수 있다.
characteristic value modification 필드는 서비스의 데이터 변경 여부를 나타내는 필드로써, 서비스의 변경 없이 서비스와 관련된 특성 값의 변경을 나타낸다.
즉, characteristic value modification 필드의 값이 변경되는 경우, 클라이언트는 특정 서비스와 관련된 특성의 값이 변경되었다는 것을 인식할 수 있다.
클라이언트는 서버의 서비스 및/또는 서비스와 관련된 특성의 값이 변경된 경우, 서버로부터 Changed information 특성의 특성 값을 포함하는 메시지를 수신할 수 있다(S27010).
이때, 클라이언트는 서버로 Changed information 특성의 특성 값을 요청하는 판독 요청 메시지를 전송하여, 이에 대한 응답으로 Changed information 특성의 특성 값을 포함하는 판독 응답 메시지를 수신할 수 있다.
또는, 서버는 서비스 및/또는 특성의 값이 변경되는 경우, Changed information 특성의 특성 값을 포함하는 지시 메시지를 클라이언트에게 전송할 수 있다.
서버로부터 Changed information 특성의 특성 값을 수신한 클라이언트는 수신된 특성 값에 기초하여 서버의 서비스가 변경되었는지 여부를 판단한다(S27020).
만약, 서비스가 변경된 경우, 클라이언트는 변경된 서버의 서비스를 탐색하기 위해서 서비스 탐색 절차 및 특성 탐색 절차를 수행하고, 특성 값이 변경된 특성이 존재하는 경우, 판독 절차를 수행하여 변경된 특성 값을 획득할 수 있다(S 27030).
하지만, 서비스가 변경되지 않은 경우, 클라이언트는 서버의 서비스와 관련된 특성의 값이 변경되었는지 여부를 판단한다(S27040).
만약, 특성의 값이 변경된 경우, 클라이언트는 변경된 특성의 값을 판독하여 특성 값을 획득할 수 있으며(S27050), 특성의 값이 변경되지 않은 경우, 클라이언트는 탐색 절차 및 판독 절차를 수행하지 않는다.
본 발명의 또 다른 실시 예로 단계 S27010에서 전송되는 메시지는 서비스 및 특성을 나타내는 해쉬 값을 포함할 수 있다.
구체적으로, 클라이언트는 서버의 서비스를 나타내는 제 1 해쉬 값 및 서비스와 관련된 특성을 나타내는 제 2 해쉬 값을 포함하는 메시지를 수신할 수 있다.
클라이언트는 제 1 해쉬 값 및 제 2 해쉬 값에 기초하여 서버의 서비스 및 특성이 변경되었는지 여부를 판단할 수 있으며, 서비스 및 특성이 변경된 경우, 변경된 서비스 및/또는 변경된 특성을 탐색하는 절차를 수행할 수 있다.
예를 들면, 클라이언트는 제 1 해쉬 값이 기존의 값과 다른 경우, 제 1 해쉬 값이 나타내는 서버의 서비스가 변경되었다고 인식할 수 있다. 이 경우, 클라이언트는 변경된 서버의 서비스를 탐색하기 위한 절차를 수행하여 제 1 해쉬 값이 나타내는 서비스가 추가, 삭제 또는 변경되었는지 여부를 탐색할 수 있다.
또한, 클라이언트는 제 2 해쉬 값이 기존의 값과 다른 경우, 제 2 해쉬 값이 나타내는 특성이 변경되었다고 인식할 수 있다. 이 경우, 클라이언트는 변경된 특성을 탐색하기 위해 특성 탐색 절차를 수행할 수 있으며, 변경된 특성의 값을 판독 절차를 통해서 획득할 수 있다.
이와 같은 방법을 이용하여 클라이언트는 서버의 서비스는 변경되지 않고 특성의 값만 변경된 경우, 서비스 전체를 다시 탐색하지 않아도 변경된 특성의 값을 획득할 수 있으며, 이로 인하며 탐색 절차의 지연이 감소할 수 있다.
도 29 내지 도 31은 본 발명에서 제안하는 서비스 및 특성의 변경 여부를 인식하기 위한 속성의 일 예를 나타내는 도면이다.
도 29 내지 도 31을 참조하면, 서비스 및 특성의 값이 변경되었는지 여부를 판단하기 위해서 속성에 변경 여부를 나타내는 필드가 추가될 수 있다.
블루투스에서 서비스는 특정 기능 또는 기능을 수행하기 위한 데이터 및 관련 동작의 집합이다. GATT에서 서비스는 서비스 정의에 의해 정의되며, 서비스 정의는 참조된 서비스, 필수 특성 및 선택적 특성을 포함 할 수 있다.
Service는 primary service와 secondary service와 같이 두 가지 유형의 서비스가 존재한다. primary service는 디바이스에서 기본적으로 사용할 수 있는 기능을 제공하는 서비스이며, 다른 서비스에 포함될 수 있다.
primary service는 primary service discovery 절차를 통해서 발견될 수 있다. secondary service는 primary service 또는 다른 secondary 서비스에서 참조되는 서비스이다.
Included service는 정의된 서비스에 서버에 정의된 다른 서비스를 참조하기 위한 방법이다.
다른 서비스를 포함시키기 위해 include definition이 서비스 정의의 시작 부분에서 사용될 수 있다. Service definition이 include definition을 이용하여 included service를 참조하면 included service definition 전체가 새 서비스 정의의 일부가 될 수 있다.
여기에는 모든 included service 및 included service의 특성이 포함된다.
Included service는 독립적인 서비스로 존재할 수 있으며 다른 서비스에 포함된 서비스는 포함 또는 포함된 서비스에 의해 변경되지 않는다.
특성(Characteristic)의 값은 액세스되는 방법과 값이 표시되거나 표현되는 방법에 대한 정보와 함께 속성 및 구성 정보와 함께 서비스에서 사용되는 값이다.
GATT에서 특성은 특성 정의로 정의되며, 특성 정의는 특성 선언, 특성 특성 및 값을 포함하며 특성과 관련하여 서버의 값 또는 허용 구성을 설명하는 설명자를 포함 할 수 있다.
도 29의 (a)는 서버의 서비스를 나타내는 서비스 정의(Service Definition)을 도시한다.
Service Definition은 서비스 선언(service declaration)이 포함되어야 하며, primary service에 포함되어 있는 서비스인 included service(또는, secondary service)를 나타내는 included definition 및 서비스와 관련된 데이터를 포함하는 특성을 나타내는 characteristic definition을 포함할 수 있다.
Service Definition은 다음 서비스 선언 전 또는 최대 속성 핸들 값에 도달한 이후에 종료된다.
Service Definition은 속성 핸들에 기초하여 서버에 표시된다.
Service Definition에 포함 된 모든 include definition 및 characteristic definition은 서비스의 일부로 간주될 수 있으며 모든 included definition은 서비스 선언 직후에 특성 정의 앞에 위치하여야 한다.
서비스 정의에는 0 개 이상의 include definition이 있을 수 있다. 모든 characteristic definition은 service declaration 다음의 마지막 include definition 바로 뒤에 위치하거나, included service가 존재하지 않을 수 있다. 서비스 정의는 0 개 이상의 특성 정의를 가질 수 있으며 include definition 또는 characteristic definition에는 상한이 없다.
서비스 선언은 속성 유형이≪기본 서비스≫또는≪보조 서비스≫의 UUID로 설정된 속성이다. 속성 값은 서비스 UUID라고 알려진 서비스의 16 비트 Bluetooth UUID 또는 128 비트 UUID이다.
클라이언트는 16 비트 및 128 비트 UUID를 모두 지원해야 한다. 클라이언트는 알 수 없는 서비스 UUID가있는 서비스 정의를 무시할 수 있습니다. 알 수없는 서비스 UUID는 지원되지 않는 서비스의 UUID입니다. 속성 권한은 읽기 전용이어야 하며 인증이나 권한 부여가 필요하지 않습니다.
이때, 도 29의 (b)에 도시된 바와 같이 Service Definition은 서비스가 변경된 경우, 이를 클라이언트에게 지시하기 위한 특정 필드를 포함할 수 있다.
이하, 이러한 필드를 modified field라 한다.
예를 들면, modified field의 값이 ‘0’이면 서비스의 변경이 없는 것을 나타낼 수 있으며, modified field의 값이 ‘1’ 또는 변경된 값(1이 더해지거나, 임의의 값으로 변경)이면 서비스의 변경이 있는 것을 나타낼 수 있다.
도 30의 (a)는 include definition의 일 예를 나태고, (b)는 included service가 변경된 경우, 이를 나타내기 위한 modified filed가 추가된 include definition의 일 예를 나타낸다.
도 29의 (b)와 같이 도 30의 (b)에서 modified filed의 값이 변경된 경우, 클라이언트는 서버의 secondary service 또는 included service가 변경된 것을 인식할 수 있다.
도 31의 (a)는 characteristic definition의 일 예를 나태고, (b)는 characteristic service가 변경된 경우, 이를 나타내기 위한 modified filed가 추가된 characteristic definition의 일 예를 나타낸다.
도 29의 (b)와 같이 도 31의 (b)에서 modified filed의 값이 변경된 경우, 클라이언트는 서버의 서비스와 관련된 characteristic의 특성 값이 변경된 것을 인식할 수 있다.
도 32 내지 도 34은 본 발명에서 제안하는 속성을 통해서 서비스 및 특성의 변경 여부를 인식하기 위한 방법의 일 예를 나타내는 흐름도이다.
도 32 내지 도 34를 참조하면, 클라이언트는 서버의 service definition, include definition 및 characteristic definition을 통해서 서버의 서비스가 변경되었는지 여부를 인식할 수 있다.
도 32는 서버의 서비스를 나타내는 service definition이 변경되었는지 여부를 탐색하기 위한 방법을 도시하고 있다.
도 32에 도시된 바와 같이 클라이언트는 서버의 서비스를 탐색하기 위해 서비스 탐색 절차를 시작할 수 있다(S32010).
클라이언트는 서비스 탐색 절차의 개시 이후, 서버의 service definition이 변경되었는지 여부를 통해 서버의 서비스가 변경되었는지 여부를 인식할 수 있다(S32020).
예를 들면, 서버의 service definition이 도 29의 (b)와 같이 정의되는 경우, 클라이언트는 service definition의 modified field를 통해 서비스가 변경되었는지 여부를 인식할 수 있다.
즉, modified field의 값이 변경된 경우, 클라이언트는 서버의 서비스가 변경되었다고 인식할 수 있다.
service definition이 변경된 경우, 클라이언트는 include definition이 변경되었는지 여부를 판단하기 위해 도 33의 단계 S33010를 수행할 수 있다(S32030).
Service definition이 변경되지 않은 경우, 클라이언트는 현재 서비스가 변경되지 않았다고 판단하고, 또 다른 서비스를 나타내는 Service definition이 존재하는지 여부를 판단한다(S32040).
만약, 또 다른 service definition이 존재하는 경우, 클라이언트는 또 다른 service definition의 변경 여부를 확인하기 위해 단계 S32020를 다시 수행할 수 있다.
하지만, 더 이상 다른 Service definition이 존재하지 않는 경우, 클라이언트는 더 이상 서버에 다른 서비스가 존재하지 않는다고 판단하고 서비스 탐색 절차를 종료하게 된다(S32050).
도 33은 서버의 included service를 나타내는 include definition이 변경되었는지 여부를 탐색하기 위한 방법을 도시하고 있다.
도 33에 도시된 바와 같이 클라이언트는 도 32에서 service definition이 변경되었다고 판단한 경우, include definition이 변경되었는지 여부를 판단한다(S33010).
예를 들면, 서버의 include definition이 도 30의 (b)와 같이 정의되는 경우, 클라이언트는 include definition의 modified field를 통해 included service가 변경되었는지 여부를 인식할 수 있다.
즉, modified field의 값이 변경된 경우, 클라이언트는 서버의 included service가 변경되었다고 인식할 수 있다.
include definition이 변경된 경우, 클라이언트는 서비스의 특성 값이 변경되었는지 여부를 확인하기 위해서 도 34의 단계 S34010를 수행할 수 있다(S33020).
include definition이 변경되지 않은 경우, 클라이언트는 현재 included service가 변경되지 않았다고 판단하고, 또 다른 included service를 나타내는 include definition이 존재하는지 여부를 판단한다(S33030).
만약, 또 다른 include definition이 존재하는 경우, 클라이언트는 또 다른 include definition의 변경 여부를 확인하기 위해 단계 S33010를 다시 수행할 수 있다.
하지만, 더 이상 다른 include definition이 존재하지 않는 경우, 클라이언트는 더 이상 서버에 다른 included service가 존재하지 않는다고 판단하고 다른 service definition이 존재하는지 여부를 확인하기 위해 도 32의 단계 S32040을 수행하게 된다(S33040).
도 34는 서버의 특정 서비스와 관련된 특성의 값을 나타내는 characteristic definition이 변경되었는지 여부를 탐색하기 위한 방법을 도시하고 있다.
도 34에 도시된 바와 같이 클라이언트는 도 33에서 include definition이 변경되었다고 판단한 경우, 서비스와 관련된 특성의 값이 변경되었는지 여부를 확인하기 위해 characteristic definition이 변경되었는지 여부를 판단한다(S34010).
예를 들면, 서버의 characteristic definition이 도 31의 (b)와 같이 정의되는 경우, 클라이언트는 characteristic definition의 modified field를 통해 특정 서비스와 관련된 특성의 값이 변경되었는지 여부를 인식할 수 있다.
즉, modified field의 값이 변경된 경우, 클라이언트는 특정 서비스와 관련된 특성의 값이 변경되었다고 인식할 수 있다.
characteristic definition이 변경된 경우, 클라이언트는 서비스와 판독 절차를 수행하여 변경된 특성의 값을 획득할 수 있다(S34020).
예를 들면, 클라이언트는 서버로 변경된 특성의 값을 요청하는 판독 요청 메시지를 전송하고, 서버는 이에 대한 응답으로 변경된 특성의 값을 포함하는 판독 응답 메시지를 클라이언트로 전송할 수 있다.
characteristic definition이 변경되지 않거나, 클라이언트가 변경된 특성의 값을 서버로부터 획득한 경우, 클라이언트는 특정 서비스와 관련된 또 다른 특성을 나타내는 characteristic definition이 존재하는지 여부를 판단한다(S34030).
만약, 또 다른 characteristic definition이 존재하는 경우, 클라이언트는 또 다른 characteristic definition의 변경 여부를 확인하기 위해 단계 S34010를 다시 수행할 수 있다.
하지만, 더 이상 다른 characteristic definition이 존재하지 않는 경우, 클라이언트는 더 이상 서버에 특정 서비스와 관련된 특성이 존재하지 않는다고 판단하고 다른 include definition이 존재하는지 여부를 확인하기 위해 도 33의 단계 S33030을 수행하게 된다(S34040).
이와 같은 방법을 통해서, 클라이언트는 서버의 서비스 및 서비스와 관련된 데이터가 변경되었는지 여부를 인식할 수 있으며, 변경된 서비스 및 데이터를 획득할 수 있다.
도 35 내지 도 37은 본 발명에서 제안하는 디바이스간의 호환성을 향상시키기 위한 기능 정보의 일 예를 나타내는 도면이다.
도 35 내지 도 37을 참조하면, 클라이언트와 서버는 서로 제공할 수 있는 기능과 관련된 정보를 교환함으로써 상호간에 호환성을 향상시킬 수 있다.
구체적으로, 클라이언트는 서버의 서비스들을 탐색하기 위해서 모든 서비스를 탐색하기 위한 절차인 Discover All Primary Services와 서비스의 UUID를 통해서 Primary Service를 탐색하기 위한 절차인 Discover Primary Service by Service UUID를 수행할 수 있다.
하지만, 실제 이러한 탐색 절차를 수행하기 위한 프로파일에서는 conditional한 조건으로 실제 서버에서 어떠한 기능을 지원할 수 있는지 클라이언트는 인식할 수 없다.
따라서, 클라이언트와 서버간 호환성 문제가 발생할 수 있으며, 이러한 호환성 문제로 인하여 클라이언트는 서버에 구현되지 않는 기능을 요청한 뒤, 다시 지원하는 기능으로 요청을 함으로써 시간지연이 발생할 수 있다.
또한, 블루투스에서 서비스 별로 구현된 다양한 절차들을 상대방 기기가 지원하는지 여부를 인식하지 못하여 호환성 문제가 발생할 수 있다.
따라서, 클라이언트와 서버는 상호간 지원하는 기능을 ATT 기능 정보 또는 GATT 기능 정보 중 적어도 하나로 정의하고, 정의된 기능 정보를 상대방에게 전송함으로써 호환성을 향상시킬 수 있다.
예를 들면, 클라이언트와 서버는 각각 자신이 지원하는 기능을 도 35에 도시된 바와 같이 ATT 기능 정보(ATT Feature) 또는 GATT 기능 정보(GATT Feature) 중 적어도 하나로 정의할 수 있다.
이때, 도 35에서 ATT Feature는 ATT PDU 형태로 제공될 수 있으며, GATT Feature는 GAT Procedure 형태로 제공될 수 있다.
ATT Feature 및 GATT Feature에서 각 bit는 클라이언트와 서버가 각각 특정 기능을 지원하는지 여부를 나타낼 수 있다.
예를 들면, ATT Feature 및 GATT Feature에서 특정 bit의 값이 ‘0’인 경우, 서버 또는 클라이언트는 특정 bit가 나타내는 기능을 지원하지 않는다는 것을 나타낼 수 있으며, 특정 bit의 값이 ‘1’인 경우, 서버 또는 클라이언트는 특정 bit가 나타내는 기능을 지원한다는 것을 나타낼 수 있다.
도 36은 ATT Feature의 각 bit가 나타내는 기능의 일 예를 나타내는 도면이고, 도 37은 GATT Feature의 각 bit가 나타내는 기능의 일 예를 나타내는 도면이다.
도 36 및 도 37의 각 bit가 나타내는 기능은 일 예일 뿐이며, 각 bit가 나타내는 기능은 변경될 수 있다.
도 38 및 도 39은 본 발명에서 제안하는 디바이스간의 호환성을 향상시키기 위한 방법의 일 예를 나타내는 흐름도이다.
도 38은 판독 절차를 통해서 서버와 클라이언트가 상대방 기기에 구현된 기능을 인식하기 위한 방법의 일 예를 나타낸다.
도 38을 참조하면, 서버 및 클라이언트는 도 34 및 도 35에서 살펴본 지원가능 기능을 나타내는 GATT Feature를 특정 특성으로 정의하여 최초로 GATT 연결이 형성된 경우, 특정 특성의 값을 판독함으로써 상대방 기기가 지원하는 기능을 인식할 수 있다.
먼저, 단계 S38010 및 단계 S38020은 도 14의 단계 S14010 및 단계 S14020과 동일하므로 설명을 생략하도록 한다.
제 1 디바이스(300)와 GATT 연결을 형성한 Controller(500)는 제 1 디바이스(300)에 구현된 기능을 인식하기 위해 제 1 디바이스(300)로 GATT Feature 특성의 값을 요청하는 Read by type Request message를 전송한다(S38030).
이때, Read by type Request message는 GATT Feature 특성의 값을 요청하기 위한 UUID를 포함할 수 있다.
만약, Controller가 GATT Feature 특성의 핸들 값을 알고 있는 경우, Read by type Request message 대신에 Read Request message를 통해서 GATT Feature 특성의 값을 요청할 수 있다.
이 경우, Characteristic Discovery 절차를 수행하지 않고 Read Request message를 통해서 GATT Feature 특성의 값을 요청하기 위해서는 고정 핸들 값이 필요할 수 있다.
Read by Type Request message 또는 Read Request message는 도 35 내지 도 37에서 살펴본 Controller(500)에 구현된 기능을 나타내는 GATT Feature 또는 ATT Feature 중 적어도 하나를 포함할 수 있다.
제 1 디바이스(300)는 Read by type Request message에 대한 응답으로 GATT Feature 특성의 값을 포함하는 Read by type Response message를 controller(500)로 전송한다(S38040).
즉, 제 1 디바이스(300)는 Read by type Request message에 포함된 UUID를 갖는 속성의 길이와 데이터 값을 Controller(500)에게 제공할 수 있다.
이후, Controller(500)는 GATT Feature 특성의 값을 통해 인식한 제 1 디바이스(300)에 구현된 기능에 기초하여 Primary Service 탐색 절차를 수행하여 서버의 Primary Service를 탐색할 수 있다(S38050).
즉, Controller(500)는 Primary Service 탐색 절차를 통해 제 1 디바이스(300)에 구현된 Primary Service 목록을 요청하며, 제 1 디바이스(300)는 Primary Service 목록을 Controller(500)에게 전송할 수 있다.
Primary Service 탐색 절차를 통해서 제 1 디바이스(300)의 primary service를 탐색한 controller(500)는 탐색된 서비스들과 관련된 특성을 탐색하기 위해 Characteristic 탐색 절차를 수행할 수 있다(S38060).
즉, Controller(500)는 Characteristic 탐색 절차 절차를 통해 탐색된 제 1 디바이스(300)의 서비스와 관련된 특성 정보를 요청하며, 제 1 디바이스(300)는 특정 정보를 Controller(500)에게 전송할 수 있다.
도 39는 기입 절차를 통해서 서버와 클라이언트가 상대방 기기에 구현된 기능을 인식하기 위한 방법의 일 예를 나타낸다.
도 39를 참조하면, 서버 및 클라이언트는 도 34 및 도 35에서 살펴본 지원가능 기능을 나타내는 GATT Feature를 특정 특성으로 정의하여 최초로 GATT 연결이 형성된 경우, 특정 특성의 값을 기입함으로써 상대방 기기가 지원하는 기능을 인식할 수 있다.
먼저, 단계 S39010 및 단계 S39020은 도 14의 단계 S14010 및 단계 S14020과 동일하므로 설명을 생략하도록 한다.
제 1 디바이스(300)와 GATT 연결을 형성한 Controller(500)는 제 1 디바이스(300)로 GATT Feature 특성의 기입을 요청하는 Write request message를 전송한다(S39030).
이때, Write request message는 Controller(500)에 구현된 기능을 나타내는 기능정보(도 35의 GATT Feature)를 포함하고 있으며, 제 1 디바이스는 GATT Feature 특성에 Write request message에 포함된 기능 정보를 기입함으로써 Controller에 구현된 기능을 인식할 수 있다.
Controller(500)가 GATT Feature 특성에 기입을 요청하기 위해서는 사전에 Characteristic Discovery 절차를 수행하거나 고정 핸들 값이 필요할 수 있다.
제 1 디바이스(300)는 GATT Feature 특성에 기능 정보를 기입하고, Write request message에 대한 응답으로 Write response message를 Controller(500)에게 전송한다(39040).
하지만, 제 1 디바이스(300)가 GATT Feature 특성에 기능 정보의 기입을 실패한 경우, Controller(500)로 기입의 실패를 나타내는 에러 메시지를 전송할 수 있다.
Write response message는 제 1 디바이스(300)가 지원하는 기능을 나타내는 기능 정보(도 35의 GATT Feature)를 포함할 수 있으며, Controller(500)는 Write response message에 포함된 기능 정보를 통해서 제 1 디바이스(300)에 구현된 기능을 인식할 수 있다.
이후, 단계 S39050 및 단계 S39060은 도 38의 단계 S38050 및 단계 S38060과 동일하므로 설명을 생략하도록 한다.
도 40 및 도 41은 본 발명에서 제안하는 디바이스간의 호환성을 향상시키기 위한 방법의 또 다른 일 예를 나타내는 흐름도이다.
도 40 및 도 41을 참조하면, 서버 및 클라이언트는 도 34 및 도 35에서 살펴본 지원가능 기능을 나타내는 GATT Feature를 특정 특성으로 정의하여 최초로 GATT 연결이 형성된 경우, 서비스 및 특성의 탐색 절차를 통해서 GATT Feature 특성을 발견할 수 있으며, 클라이언트는 서버의 GATT Feature 특성의 값을 요청하여 서버에 구현된 특정 서비스에서 사용할 수 있는 기능을 인식할 수 있다.
도 40은 클라이언트가 탐색된 서버의 특성 값을 판독 절차를 통해서 획득하여 서버에 구현된 기능을 인식하기 위한 방법의 일 예를 나타낸다.
먼저, 단계 S40010 및 단계 S40020은 도 14의 단계 S14010 및 단계 S14020과 동일하므로 설명을 생략하도록 한다.
제 1 디바이스(300)와 GATT 연결을 형성한 Controller(500)는 Primary Service 탐색 절차를 수행하여 서버의 Primary Service를 탐색할 수 있다(S40030).
즉, Controller(500)는 Primary Service 탐색 절차를 통해 제 1 디바이스(300)에 구현된 Primary Service 목록을 요청하며, 제 1 디바이스(300)는 Primary Service 목록을 Controller(500)에게 전송할 수 있다.
Primary Service 탐색 절차를 통해서 제 1 디바이스(300)의 primary service를 탐색한 controller(500)는 탐색된 서비스들과 관련된 특성을 탐색하기 위해 Characteristic 탐색 절차를 수행할 수 있다(S40040).
즉, Controller(500)는 Characteristic 탐색 절차 절차를 통해 탐색된 제 1 디바이스(300)의 서비스와 관련된 특성 정보를 요청하며, 제 1 디바이스(300)는 특정 정보를 Controller(500)에게 전송할 수 있다.
이때, Controller(500)는 탐색 절차를 통해 제 1 디바이스(300)에서 특정 서비스를 위해 구현된 기능을 나타내는 특성인 GATT Feature 특성을 탐색할 수 있다.
GATT Feature 특성을 탐색한 Controller(500)는 제 1 디바이스(300)에 구현된 기능을 인식하기 위해 제 1 디바이스(300)로 GATT Feature 특성의 값을 요청하는 Read by type Request message를 전송한다(S40050).
이때, Read by type Request message는 GATT Feature 특성의 값을 요청하기 위한 UUID를 포함할 수 있다.
만약, Controller가 GATT Feature 특성의 핸들 값을 알고 있는 경우, Read by type Request message 대신에 Read Request message를 통해서 GATT Feature 특성의 값을 요청할 수 있다.
이 경우, Characteristic Discovery 절차를 수행하지 않고 Read Request message를 통해서 GATT Feature 특성의 값을 요청하기 위해서는 고정 핸들 값이 필요할 수 있다.
Read by Type Request message 또는 Read Request message는 도 35 내지 도 37에서 살펴본 Controller에 구현된 기능을 나타내는 GATT Feature 또는 ATT Feature 중 적어도 하나를 포함할 수 있다.
제 1 디바이스(300)는 Read by type Request message에 대한 응답으로 GATT Feature 특성의 값을 포함하는 Read by type Response message를 controller(500)로 전송한다(S40060).
즉, 제 1 디바이스(300)는 Read by type Request message에 포함된 UUID를 갖는 속성의 길이와 데이터 값을 Controller(500)에게 제공할 수 있다.
이후, Controller(500)와 제 1 디바이스(300)는 인식한 기능을 통해서 특정 서비스를 제공할 수 있다.
도 41은 탐색된 서버의 특성 값의 기입 절차를 통해서 서버와 클라이언트가 상대방 기기에 구현된 기능을 인식하기 위한 방법의 일 예를 나타낸다.
먼저, 단계 S41010 내지 단계 S41040은 도 40의 단계 S40010 내지 단계 S40040과 동일하므로 설명을 생략하도록 한다.
GATT Feature 특성을 탐색한 Controller(500)는 제 1 디바이스(300)로 GATT Feature 특성의 기입을 요청하는 Write request message를 전송한다(S41050).
이때, Write request message는 Controller(500)에 구현된 기능을 나타내는 기능정보(도 35의 GATT Feature)를 포함하고 있으며, 제 1 디바이스(300)는 GATT Feature 특성에 Write request message에 포함된 기능 정보를 기입함으로써 Controller(500)에 구현된 기능을 인식할 수 있다.
Controller(500)가 GATT Feature 특성에 기입을 요청하기 위해서는 사전에 Characteristic Discovery 절차를 수행하거나 고정 핸들 값이 필요할 수 있다.
제 1 디바이스(300)는 GATT Feature 특성에 기능 정보를 기입하고, Write request message에 대한 응답으로 Write response message를 Controller(500)에게 전송한다(41060).
하지만, 제 1 디바이스(300)가 GATT Feature 특성에 기능 정보의 기입을 실패한 경우, Controller(500)로 기입의 실패를 나타내는 에러 메시지를 전송할 수 있다.
Write response message는 제 1 디바이스(300)가 지원하는 기능을 나타내는 기능 정보(도 35의 GATT Feature)를 포함할 수 있으며, Controller(500)는 Write response message에 포함된 기능 정보를 통해서 제 1 디바이스(300)에 구현된 기능을 인식할 수 있다.
도 42은 본 발명에서 제안하는 디바이스간의 호환성을 향상시키기 위한 방법의 또 다른 일 예를 나타내는 흐름도이다.
도 42를 참조하면, 서버 및 클라이언트는 도 34 및 도 35에서 살펴본 지원가능 기능을 나타내는 GATT Feature의 값을 교환하여 상대방 기기에 구현된 기능을 인식할 수 있다.
먼저, 단계 S42010 및 단계 S42020은 도 14의 단계 S14010 및 단계 S14020과 동일하므로 설명을 생략하도록 한다.
제 1 디바이스(300)와 GATT 연결을 형성한 Controller(500)는 서버에 구현된 기능을 나타내는 기능 정보인 GATT Feature의 값을 요청하기 위해 제 1 디바이스(300)로 기능 정보 요청 메시지를 전송한다(S42030).
이때, 기능 정보 요청 메시지를 통해 GATT Feature의 값을 요청하기 위해 특정 ATT opcode가 정의될 수 있다.
즉, Controller(500)는 GATT Feature의 값의 전송을 지시하는 특정 ATT opcode를 포함하는 기능 정보 요청 메시지를 제 1 디바이스(300)에게 전송함으로써, 제 1 디바이스(300)의 GATT Feature의 값을 획득할 수 있다.
기능 정보 요청 메시지는 도 35 내지 도 37에서 살펴본 Controller(500)에 구현된 기능을 나타내는 GATT Feature 또는 ATT Feature 중 적어도 하나를 포함할 수 있다.
제 1 디바이스(300)는 기능 정보 요청 메시지에 포함된 Controller(500)의 GATT Feature의 데이터 값 또는 ATT Feature의 데이터 값을 통해 Controller(500)가 지원하는 기능을 인식할 수 있다.
제 1 디바이스(300)는 기능 정보 요청 메시지에 대한 응답으로 Controller(500)로 제 1 디바이스의 GATT Feature의 값을 포함하는 기능 정보 응답 메시지를 전송한다(S42040).
이때, 기능 정보 응답 메시지를 통해 GATT Feature의 값을 전송하기 위해 특정 ATT opcode가 정의될 수 있다.
즉, 제 1 디바이스(300)는 GATT Feature의 값의 전송되는 것을 Controller(500)에게 알리기 위해 특정 ATT opcode를 포함하는 기능 정보 응답 메시지를 제 1 디바이스(300)에게 전송할 수 있다.
도 43는 본 발명에서 제안하는 서비스 및 특성의 변경 여부를 인식하기 위한 방법의 일 예를 나타내는 순서도이다.
구체적으로, 제 1 디바이스는 도 14에서 설명한 방법을 통해 제 2 디바이스와 블루투스 LE 연결을 형성한다(S43010).
제 2 디바이스와 블루투스 LE 연결을 통해 GATT 연결을 형성한 제 1 디바이스는 제 2 디바이스로부터 상기 제 2 디바이스가 지원하는 서비스의 변경 여부를 지시하는 제 1 메시지를 수신한다(S43020).
이때, 제 1 메시지는 도 27에서 살펴본 Changed information 특성의 특성 값을 포함하는 판독 응답 메시지 또는 지시 메시지일 수 있다.
이후, 제 1 디바이스는 제 1 메시지에 기초하여 서비스 또는 서비스의 특성 중 적어도 하나를 탐색한다(S43030).
예를 들면, 제 1 디바이스는 도 26 내지 도 34에서 설명한 방법을 통해서 제 2 디바이스의 서비스 및 특성이 변경되었는지 여부를 인식할 수 있으며, 변경된 서비스 및 특성을 탐색할 수 있다.
이때, 도 26 내지 도 34에서 살펴본 바와 같이 제 1 디바이스는 제 2 디바이스의 서비스는 변경되지 않고, 특정 서비스의 특성 값만 변경된 경우, 제 1 디바이스는 제 2 디바이스의 모든 디바이스를 다시 탐색하지 않고, 변경된 특성만을 탐색하여 변경된 특성 값을 판독할 수 있다.
본 명세서에서 제안하는 발명은 블루투스 LE를 기준으로 설명하였지만, 블루투스 BR/EDR에도 적용이 가능하다.
나아가, 설명의 편의를 위하여 각 도면을 나누어 설명하였으나, 각 도면에 서술되어 있는 실시 예들을 병합하여 새로운 실시 예를 구현하도록 설계하는 것도 가능하다. 그리고, 당업자의 필요에 따라, 이전에 설명된 실시 예들을 실행하기 위한 프로그램이 기록되어 있는 컴퓨터에서 판독 가능한 기록 매체를 설계하는 것도 본 발명의 권리범위에 속한다.
본 명세서에 따른 블루투스를 이용하여 디바이스를 제어하는 방법은 상기한 바와 같이 설명된 실시 예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 상기 실시 예들은 다양한 변형이 이루어질 수 있도록 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다.
한편, 본 명세서의 블루투스를 이용하여 디바이스를 제어하는 방법은 네트워크 디바이스에 구비된 프로세서가 읽을 수 있는 기록매체에 프로세서가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 프로세서가 읽을 수 있는 기록매체는 프로세서에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 프로세서가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
또한, 이상에서는 본 명세서의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 명세서는 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.
그리고, 당해 명세서에서는 물건 발명과 방법 발명이 모두 설명되고 있으며, 필요에 따라 양 발명의 설명은 보충적으로 적용될 수가 있다.
본 발명의 데이터 송수신 방법은 블루투스 LE에 적용되는 예를 중심으로 설명하였으나, 블루투스 LE 시스템 외에도 다양한 무선 통신 시스템에 적용하는 것이 가능하다.

Claims (16)

  1. 무선 통신 시스템에서 제 1 디바이스가 서비스를 탐색하기 위한 방법에 있어서,
    제 2 디바이스와 블루투스 LE 연결을 형성하는 단계;
    상기 제 2 디바이스로부터 상기 제 2 디바이스가 지원하는 서비스의 변경 여부를 지시하는 제 1 메시지를 수신하는 단계; 및
    상기 제 1 메시지에 기초하여 서비스 또는 상기 서비스의 특성 중 적어도 하나를 탐색하는 단계를 포함하되,
    상기 제 1 메시지는 상기 제 2 디바이스가 지원하는 서비스의 변경과 관련된 제 1 값 및 상기 서비스의 특성 값의 변경과 관련된 제 2 값을 포함하는 방법.
  2. 제 1 항에 있어서, 상기 탐색하는 단계는,
    상기 제 1 값에 기초하여 상기 서비스가 변경되었는지 여부를 판단하는 단계;
    상기 제 1 값이 상기 서비스의 변경을 나타내는 경우, 상기 변경된 서비스를 탐색하는 단계;
    상기 제 2 값에 기초하여 상기 특성 값이 변경되었는지 여부를 판단하는 단계; 및
    상기 제 2 값이 상기 특성 값의 변경을 나타내는 경우, 상기 변경된 특성 값을 탐색하는 단계를 포함하는 방법.
  3. 제 1 항에 있어서,
    상기 제 1 값은 상기 서비스를 나타내는 제 1 해쉬 값이고,
    상기 제 2 값은 상기 특성 값을 나타내는 제 2 해쉬 값인 방법.
  4. 제 3 항에 있어서,
    상기 제 1 해쉬 값 또는 상기 제 2 해쉬 값이 변경되었는지 여부를 판단하는 단계를 더 포함하되,
    상기 제 1 해쉬 값이 변경된 경우, 상기 제 1 해쉬 값이 나타내는 서비스를 탐색하고,
    상기 제 2 해쉬 값이 변경된 경우, 상기 제 2 해쉬 값이 나타내는 특성 값을 탐색하는 방법.
  5. 제 1 항에 있어서,
    상기 제 2 디바이스가 지원하는 프라이머리(primary) 서비스를 탐색하는 단계; 및
    상기 탐색된 프라이머리 서비스의 특성 값을 탐색하는 단계를 더 포함하는 방법.
  6. 제 1 항에 있어서,
    상기 제 2 디바이스로 상기 제 2 디바이스와의 호환성을 위한 제 1 특성의 특성 값의 판독을 요청하는 판독 요청 메시지를 전송하는 단계; 및
    상기 판독 요청 메시지에 대한 응답으로 상기 제 1 특성의 제 1 특성 값을 포함하는 판독 응답 메시지를 수신하는 단계를 더 포함하되,
    상기 제 1 특성 값은 상기 제 2 디바이스가 지원하는 적어도 하나의 기능을 나타내는 방법.
  7. 제 6 항에 있어서,
    상기 판독 요청 메시지는 상기 제 1 디바이스와의 호환성을 위한 제 2 특성의 제 2 특성 값을 포함하고,
    상기 제 2 특성 값은 상기 제 1 디바이스가 지원하는 적어도 하나의 기능을 나타내는 방법.
  8. 제 1 항에 있어서,
    상기 제 2 디바이스로 상기 제 1 디바이스와의 호환성을 위한 제 1 특성의 제 1 특성 값의 기입을 요청하는 기입 요청 메시지를 전송하는 단계,
    상기 제 1 특성 값은 상기 제 1 디바이스가 지원하는 적어도 하나의 기능을 나타내고; 및
    상기 기입 요청 메시지에 대한 응답으로 상기 제 2 디바이스와의 호환성을 위한 제 2 특성의 제 2 특성 값을 포함하는 기입 응답 메시지를 수신하는 단계를 더 포함하되,
    상기 제 2 특성 값은 상기 제 2 디바이스가 지원하는 적어도 하나의 기능을 나타내는 방법.
  9. 무선 통신 시스템에서 서비스를 탐색하기 위한 제 1 디바이스에 있어서,
    외부와 무선 또는 유선으로 통신하기 위한 통신부; 및
    상기 통신부와 기능적으로 연결되는 프로세서를 포함하되, 상기 프로세서는,
    제 2 디바이스와 블루투스 LE 연결을 형성하고,
    상기 제 2 디바이스로부터 상기 제 2 디바이스가 지원하는 서비스의 변경 여부를 지시하는 위한 제 1 메시지를 수신하며,
    상기 제 1 메시지에 기초하여 서비스 또는 상기 서비스의 특성 중 적어도 하나를 탐색하되,
    상기 제 1 메시지는 상기 제 2 디바이스가 지원하는 서비스의 변경과 관련된 제 1 값 및 상기 서비스의 특성 값의 변경과 관련된 제 2 값을 포함하는 디바이스.
  10. 제 9 항에 있어서, 상기 프로세서는,
    상기 제 1 값에 기초하여 상기 서비스가 변경되었는지 여부를 판단하고,
    상기 제 1 값이 상기 서비스의 변경을 나타내는 경우, 상기 변경된 서비스를 탐색하며,
    상기 제 2 값에 기초하여 상기 특성 값이 변경되었는지 여부를 판단하되,
    상기 제 2 값이 상기 특성 값의 변경을 나타내는 경우, 상기 변경된 특성 값을 탐색하는 단계를 더 포함하는 디바이스.
  11. 제 9 항에 있어서,
    상기 제 1 값은 상기 서비스를 나타내는 제 1 해쉬 값이고,
    상기 제 2 값은 상기 특성 값을 나타내는 제 2 해쉬 값인 디바이스.
  12. 제 11 항에 있어서, 상기 프로세서는,
    상기 제 1 해쉬 값 또는 상기 제 2 해쉬 값이 변경되었는지 여부를 판단하고
    상기 제 1 해쉬 값이 변경된 경우, 상기 제 1 해쉬 값이 나타내는 서비스를 탐색하며,
    상기 제 2 해쉬 값이 변경된 경우, 상기 제 2 해쉬 값이 나타내는 특성 값을 탐색하는 디바이스.
  13. 제 9 항에 있어서, 상기 프로세서는,
    상기 제 2 디바이스가 지원하는 프라이머리(primary) 서비스를 탐색하고,
    상기 탐색된 프라이머리 서비스의 특성 값을 탐색하는 디바이스.
  14. 제 9 항에 있어서, 상기 프로세서는,
    상기 제 2 디바이스로 상기 제 2 디바이스와의 호환성을 위한 제 1 특성의 특성 값의 판독을 요청하는 판독 요청 메시지를 전송하고,
    상기 판독 요청 메시지에 대한 응답으로 상기 제 1 특성의 제 1 특성 값을 포함하는 판독 응답 메시지를 수신하되,
    상기 제 1 특성 값은 상기 제 2 디바이스가 지원하는 적어도 하나의 기능을 나타내는 디바이스.
  15. 제 14 항에 있어서,
    상기 판독 요청 메시지는 상기 제 1 디바이스와의 호환성을 위한 제 2 특성의 제 2 특성 값을 포함하고,
    상기 제 2 특성 값은 상기 제 1 디바이스가 지원하는 적어도 하나의 기능을 나타내는 디바이스.
  16. 제 9 항에 있어서, 상기 프로세서는,
    상기 제 2 디바이스로 상기 제 1 디바이스와의 호환성을 위한 제 1 특성의 제 1 특성 값의 기입을 요청하는 기입 요청 메시지를 전송하되,
    상기 제 1 특성 값은 상기 제 1 디바이스가 지원하는 적어도 하나의 기능을 나타내고,
    상기 기입 요청 메시지에 대한 응답으로 상기 제 2 디바이스와의 호환성을 위한 제 2 특성의 제 2 특성 값을 포함하는 기입 응답 메시지를 수신하되,
    상기 제 2 특성 값은 상기 제 2 디바이스가 지원하는 적어도 하나의 기능을 나내는 디바이스.
PCT/KR2018/000058 2017-01-02 2018-01-02 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치 WO2018124852A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/475,598 US10721611B2 (en) 2017-01-02 2018-01-02 Method and device for controlling device by using Bluetooth technology

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201762441555P 2017-01-02 2017-01-02
US62/441,555 2017-01-02
US201762457741P 2017-02-10 2017-02-10
US62/457,741 2017-02-10

Publications (1)

Publication Number Publication Date
WO2018124852A1 true WO2018124852A1 (ko) 2018-07-05

Family

ID=62709624

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/000058 WO2018124852A1 (ko) 2017-01-02 2018-01-02 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치

Country Status (2)

Country Link
US (1) US10721611B2 (ko)
WO (1) WO2018124852A1 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114009141A (zh) * 2019-06-19 2022-02-01 谷歌有限责任公司 用于在蓝牙网络中路由音频数据的方法和***
US20220200973A1 (en) * 2019-04-15 2022-06-23 Bear System, LLC Blockchain schema for secure data transmission
US11483143B2 (en) * 2019-04-15 2022-10-25 Smart Security Systems, Llc Enhanced monitoring and protection of enterprise data

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018124852A1 (ko) * 2017-01-02 2018-07-05 엘지전자(주) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2019031822A1 (ko) * 2017-08-07 2019-02-14 엘지전자 주식회사 블루투스 저전력 에너지 기술을 이용하여 디바이스간 연결을 형성하기 위한 방법 및 장치
US20210367706A1 (en) * 2018-05-21 2021-11-25 Hewlett-Packard Development Company, L.P. Device communication interpretation based on process state
US20210352764A1 (en) * 2020-05-06 2021-11-11 Abl Ip Holding, Llc Provisioning a smart device in an existing secure network without using a cloud service

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130029596A1 (en) * 2011-07-29 2013-01-31 Motorola Solutions, Inc. Pairing devices using data exchanged in an out-of-band channel
US20140052862A1 (en) * 2009-03-16 2014-02-20 Apple Inc. Efficient service discovery for peer-to-peer networking devices
US20150304843A1 (en) * 2014-04-21 2015-10-22 Jason Edward Robert Hillyard Systems and methods for short range wireless data transfer
WO2015194854A1 (ko) * 2014-06-17 2015-12-23 엘지전자(주) 블루투스 le(low energy) 기술을 이용하여 디바이스 간 커넥션을 형성하기 위한 방법 및 장치
KR20160115048A (ko) * 2015-03-25 2016-10-06 삼성전자주식회사 이동통신시스템에서 단말을 변경하여 이동 통신 서비스를 이용하는 방법 및 장치

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016167541A1 (ko) * 2015-04-13 2016-10-20 엘지전자(주) 블루투스 저전력 기술을 이용하여 디바이스를 연결하기 위한 방법 및 장치
KR20170022001A (ko) * 2015-08-19 2017-03-02 엘지전자 주식회사 데이터 송수신 방법 및 이를 위한 디바이스
WO2018124852A1 (ko) * 2017-01-02 2018-07-05 엘지전자(주) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140052862A1 (en) * 2009-03-16 2014-02-20 Apple Inc. Efficient service discovery for peer-to-peer networking devices
US20130029596A1 (en) * 2011-07-29 2013-01-31 Motorola Solutions, Inc. Pairing devices using data exchanged in an out-of-band channel
US20150304843A1 (en) * 2014-04-21 2015-10-22 Jason Edward Robert Hillyard Systems and methods for short range wireless data transfer
WO2015194854A1 (ko) * 2014-06-17 2015-12-23 엘지전자(주) 블루투스 le(low energy) 기술을 이용하여 디바이스 간 커넥션을 형성하기 위한 방법 및 장치
KR20160115048A (ko) * 2015-03-25 2016-10-06 삼성전자주식회사 이동통신시스템에서 단말을 변경하여 이동 통신 서비스를 이용하는 방법 및 장치

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220200973A1 (en) * 2019-04-15 2022-06-23 Bear System, LLC Blockchain schema for secure data transmission
US11483143B2 (en) * 2019-04-15 2022-10-25 Smart Security Systems, Llc Enhanced monitoring and protection of enterprise data
CN114009141A (zh) * 2019-06-19 2022-02-01 谷歌有限责任公司 用于在蓝牙网络中路由音频数据的方法和***

Also Published As

Publication number Publication date
US10721611B2 (en) 2020-07-21
US20190327601A1 (en) 2019-10-24

Similar Documents

Publication Publication Date Title
WO2018074892A1 (ko) 블루투스 기술을 이용하여 데이터를 송수신하기 위한 방법 및 장치
WO2016167541A1 (ko) 블루투스 저전력 기술을 이용하여 디바이스를 연결하기 위한 방법 및 장치
WO2016122186A1 (ko) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2016182404A1 (ko) 블루투스 저전력 에너지 기술을 이용하여 대체 통신 수단을 연결하기 위한 방법 및 장치
WO2016039598A1 (ko) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2018038459A1 (ko) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2015194854A1 (ko) 블루투스 le(low energy) 기술을 이용하여 디바이스 간 커넥션을 형성하기 위한 방법 및 장치
WO2018124852A1 (ko) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2017043869A1 (ko) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2016175454A1 (ko) 블루투스 메쉬 네트워크를 이용하여 데이터를 송수신하기 위한 방법 및 장치
WO2018135926A1 (ko) 블루투스 통신 방법 및 장치
WO2016017909A1 (ko) 블루투스 통신을 지원하는 무선 통신 시스템에서 전자기기를 제어하기 위한 방법 및 장치
WO2016017908A1 (ko) 블루투스 통신을 지원하는 무선 통신 시스템에서 전자기기를 제어하기 위한 방법 및 장치
WO2016178542A1 (ko) 블루투스에서 데이터를 송수신하기 위한 방법 및 장치
WO2016036139A2 (ko) 블루투스 le(low energy) 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2016010347A1 (ko) 블루투스 le(low energy) 기술을 이용하여 디바이스의 위치를 측정하기 위한 방법 및 장치
WO2018048268A1 (ko) 블루투스 기술을 이용하여 디바이스를 연결하기 위한 방법 및 장치
WO2018097687A1 (ko) 블루투스를 이용한 메쉬 네트워크에서 데이터를 송수신하기 위한 방법 및 장치
WO2018169380A1 (ko) 블루투스 기술을 이용하여 오디오 신호를 처리하기 위한 방법 및 장치
WO2016017907A1 (ko) 블루투스 통신을 지원하는 무선 통신 시스템에서 전자기기를 제어하기 위한 방법 및 장치
WO2016175638A1 (ko) 블루투스 메쉬 네트워크에서 디바이스의 주소를 할당하기 위한 방법 및 장치
WO2016159678A1 (ko) 블루투스 저 전력 에너지 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2015163680A1 (ko) 무선 통신 시스템에서 블루투스 저전력 에너지 기술을 이용하여 데이터를 송수신하기 위한 방법 및 장치
WO2016108646A1 (ko) 블루투스 le 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2018021877A1 (ko) 디바이스의 연결을 형성하기 위한 방법 및 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18734065

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18734065

Country of ref document: EP

Kind code of ref document: A1