WO2015163680A1 - Method and apparatus for transmitting and receiving data using bluetooth low-power energy technique in wireless communication system - Google Patents

Abstract

The present invention relates to a method for transmitting and receiving data through a Bluetooth LE, and comprises: a step of transmitting a first request message for a data request to a second device; a step of receiving a first response message including data as a response to the first request message; a step of transmitting a second request message for an additional data request if said data has the same data size of the maximum data transmission size; and a step of receiving a second response message including said additional data as a response to the second request message, wherein the first request message or the second request message respectively includes information related to said data, and wherein the first request message or the second request message respectively includes at least one of a length information or an ID information.

Description

Method and apparatus for transmitting and receiving data using Bluetooth low energy technology in wireless communication system

The present invention relates to a method and apparatus for transmitting and receiving data through Bluetooth low energy (BLE) technology, which is a near field low power technology in a wireless communication system.

Bluetooth is a short-range wireless technology standard that can transmit and receive data by wirelessly connecting various devices in a short distance. 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. In the present invention, the device may mean an apparatus and an apparatus.

In this case, 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.

In addition, 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.

It is an object of the present invention to provide a method for transmitting and receiving data via Bluetooth communication.

Another object of the present invention is to provide a method for transmitting and receiving large data through Bluetooth LE communication.

In addition, an object of the present invention is to define an error message for an error (Error) that may occur when data is transmitted and received through the Bluetooth LE communication.

Another object of the present invention is to provide a method for finding a characteristic value through a specific characteristic or universally unique identifiers (UUIDs) stored in a server through Bluetooth LE communication.

In addition, an object of the present invention is to provide a method that can provide the size or length of data when transmitting and receiving data through Bluetooth LE communication.

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

The present invention provides a method and apparatus for transmitting and receiving data through Bluetooth Low Energy (LE) technology in order to solve the above problems.

Specifically, the method for transmitting and receiving data through Bluetooth Low Energy (LE) according to an embodiment of the present invention, transmitting the first request message for the data request to the second device; Receiving a first response message including data in response to the first request message; If the data is equal to a maximum data transmission size, transmitting a second request message for an additional data request; And receiving a second response message including the additional data in response to the second request message, wherein each of the first request message or the second request message includes ID information of the data and an index. And at least one of information or index range information, and each of the first response message and the second response message includes at least one of length information and ID information.

In the present invention, the data is characterized in that the length information.

Further, in the present invention, each of the first request message or the second request message may include an offset value, and the offset value may indicate a data transmission start position.

The present invention may also include receiving an error message from the second device when the data is plural;

Transmitting a third request message including an attribute value of the data; And receiving a third response message including the data in response to the third request message.

In addition, the present invention includes the steps of transmitting a request message for a data request to the second device; Receiving an error message in response to the request message from the second device; Transmitting a first split transfer request message for split transfer request of data to the second device; And receiving a first split transmission response message including a part of the data in response to the split transmission request message. And when a part of the received data is equal to a maximum data transmission size, transmitting a second split transmission request message for an additional data request; And receiving a second split transfer response message including the additional data in response to the second split transfer request message, wherein each of the first split transfer request message or the second request message is an ID of the data. Information, index information, or at least one of index range information, and each of the first split transmission response message and the second split transmission response message includes at least one of length information and ID information. Characterized in that.

In the present invention, each of the first split transfer request message or the second split transfer request message includes an offset value, and the offset value indicates a data transmission start position. .

In addition, the present invention includes the steps of transmitting a request message for requesting the storage of specific data to the second device; And receiving an error message in response to the request message, wherein the error message indicates that the specific data does not conform to a data format, type, or range, and the request message indicates index information of a storage location. It is characterized by including.

In addition, the present invention, the communication unit for transmitting and receiving a signal to the outside by wire and / or wireless; And a controller operatively connected to the communication unit, wherein the controller transmits a first request message for data request to a second device, and sends a first response message including data in response to the first request message. And if the data is equal to the maximum data transmission size, send a second request message for further data request, and receive a second response message including the additional data in response to the second request message. The first request message or the second request message may include at least one of ID information, index information, and index range information of the data, and control the first response message or the first request message. Each of the two response messages includes at least one of length information and ID information. Provide value.

In the present invention, the data is characterized in that the length information.

Further, in the present invention, each of the first request message or the second request message may include an offset value, and the offset value may indicate a data transmission start position.

In addition, in the present invention, when there is a plurality of data, the controller receives an error message from the second device, transmits a third request message including an attribute value of the data, And receiving a third response message including the data in response to the third request message.

In addition, the present invention, the communication unit for transmitting and receiving a signal to the outside by wire and / or wireless; And a controller operatively connected to the communication unit, wherein the controller transmits a request message for data transmission to a second device, receives an error message in response to the request message from the second device, and Transmitting a first split transfer request message for split transfer request of data to a second device, and receiving a first split transfer response message including a part of the data in response to the split transfer request message; If part of the data is equal to the maximum data transmission size, the second split transmission request message for the additional data request is transmitted, and the second split transmission response message including the additional data is sent in response to the second split transmission request message. Control to receive the first divided transmission request message or the first message. Each of the two request messages includes at least one of ID information, index information, and index range information of the data, and each of the first split transmission response message or the second split transmission response message includes length information. Or it provides an apparatus comprising at least one of the ID information.

In the present invention, each of the first split transmission request message or the second split transmission request message includes an offset value, and the offset value indicates a data transmission start position. do.

In addition, the present invention, the communication unit for transmitting and receiving a signal to the outside by wire and / or wireless; And a controller operatively connected to the communication unit, wherein the controller is configured to transmit a request message requesting storage of specific data to the second device and to receive an error message in response to the request message. The error message indicates that the specific data does not fit the data format, type, or range, and the request message provides index information of a storage location.

According to the method for transmitting and receiving data using the Bluetooth low power energy technology according to an embodiment of the present invention, the size of data transmitted from the server can be clearly known.

In addition, according to the method for transmitting and receiving data using the Bluetooth low power energy technology according to an embodiment of the present invention, when inputting data that does not match the data type and size, an error message may be transmitted. .

In addition, according to the method for transmitting and receiving data using the Bluetooth low power energy technology according to an embodiment of the present invention, the data is obtained from a server through a specific attribute value or Universal Unique Identifier (UUID) value It can work.

In addition, according to the method for transmitting and receiving data using the Bluetooth low power energy technology according to an embodiment of the present invention, the data is accurately transmitted from the server through a specific characteristic value or a universal unique identifier (UUID) value. There is an effect to receive.

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

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.

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

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

4 is a diagram illustrating an example of a Bluetooth communication architecture to which the methods proposed herein may be applied.

FIG. 5 is a diagram illustrating an example of a PDU structure for providing an attribute structure and an attribute value of Bluetooth low power energy.

6 is a flowchart illustrating an example of a method for acquiring large data (data larger than ATT_MTU-1) stored in a server using a Bluetooth low power energy technology.

7 is a flowchart illustrating still another example of a method for acquiring data stored in a server (data smaller than ATT_MTU-1) using a Bluetooth low power energy technology.

8 is a flowchart illustrating an example of a method for receiving data from a server by transmitting an error message according to the size of data proposed in the present specification.

9 is a diagram illustrating an example of a method for transmitting data through another response message according to the size of data requested as proposed herein.

FIG. 10 is a diagram illustrating another example of a method for transmitting data through another response message according to the size of data requested according to the present specification.

11 is a flowchart illustrating still another example of a method for acquiring data stored in a server, proposed in the present specification.

12 is a flowchart illustrating an example of a method for receiving a feature or UUID stored in a server proposed in the present specification.

FIG. 13 is a flowchart illustrating an example of a method for transmitting an error message when the requested data does not exist.

14 and 15 are diagrams illustrating a structure of a method and an attribute for receiving size or length information of data stored in a server proposed in the present specification.

FIG. 16 is a flowchart illustrating an example of a method for notifying a client of data stored in a server, as proposed herein.

FIG. 17 is a flowchart illustrating another example of a method for notifying a client of data stored in a server proposed in the present specification.

FIG. 18 is a flowchart illustrating an example of a method for instructing a client of data stored in a server, proposed in the present specification.

FIG. 19 is a flowchart illustrating still another example of a method for instructing a client of data stored in a server, proposed in the present specification.

20 to 23 are flowcharts illustrating an example of an error that occurs when data is stored in a server proposed in the present specification.

The above objects, features and advantages of the present invention will become more apparent from the following detailed description taken in conjunction with the accompanying drawings. However, the present invention may be modified in various ways and may have various embodiments. Hereinafter, specific embodiments will be illustrated in the drawings and described in detail. Like numbers refer to like elements throughout. In addition, when it is determined that the detailed description of the known function or configuration related to the present invention may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted.

Hereinafter, a method and apparatus related to the present invention will be described in more detail with reference to the accompanying drawings. The suffixes "module" and "unit" for components used in the following description are given or used in consideration of ease of specification, and do not have distinct meanings or roles from each other.

Electronic devices described herein include mobile phones, smart phones, laptop computers, digital broadcasting terminals, PDAs (Personal Digital Assistants), PMPs (Portable Multimedia Players), navigation, temperature / barometric pressure / body data. Sensors and the like may be included. However, it will be readily apparent to those skilled in the art that the configuration according to the embodiments described herein may also be applied to fixed terminals such as digital TVs, desktop computers, etc., except when applicable only to mobile terminals.

The signals described herein may be transmitted in the form of a message as well as a frame, and the wireless communication interface and the wireless communication means are given or used in consideration of the ease of specification, meaning that they are distinguished from each other or It does not have a role.

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

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

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

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

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

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

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

The server device 110 may include a data service device, a master device, a master, a server, a conductor, a host device, an audio source device, The client device may be represented as a gateway, a first device, or the like, and the client device may be a slave device, a slave, a client, a member, a sensor device, a sink device, or an audio sink device. (Audio Sink Device), a second device, or the like.

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

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

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

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

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

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

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

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

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

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

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

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

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

The electronic device including the BLE technology includes a plurality of wireless communication interfaces such as Wi-Fi, Bluetooth BR / EDR, and NFC in addition to the BLE.

Since these various wireless communication interfaces are difficult to predict when a connection with an external device will occur, most electronic devices always use and keep a plurality of wireless communication interfaces in a wake-up state.

These communication interfaces have a technical solution for minimizing standby power in idle time and have good energy efficient performance, but with the advancement of technology, all new wireless communication interfaces to be created in the future always wake up. There are certain limitations to maintaining, and this problem can be even worse in devices with battery limitations.

In order to overcome this problem, the present invention proposes a method in which BLE is used as a wake-up interface, and the other wireless communication interface wakes up only upon request.

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

As illustrated in FIG. 2, 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.

In addition, 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).

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

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

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

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

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

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

The 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. 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.

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

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

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

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

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

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

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

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

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

4 is a diagram illustrating an example of a Bluetooth communication architecture to which the methods proposed herein may be applied.

Referring to FIG. 4, (a) of 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.

Specifically, as shown in FIG. 4A, the Bluetooth BR / EDR protocol stack has an upper controller stack 10 and a lower controller stack based on a host controller interface (HCI) 18. It may include a host stack (20) of.

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. The host stack (or host module) 20 is connected to a Bluetooth module which is the controller stack 10 to connect a Bluetooth module. Control and perform actions.

The host stack 20 may include a BR / EDR PHY layer 12, a BR / EDR baseband layer 14, and a link manager layer 16.

The BR / EDR PHY layer 12 is a layer for transmitting / receiving a 2.4 GHz radio signal and may transmit data by hopping 79 RF channels when using Gaussian Frequency Shift Keying (GFSK) modulation.

The BR / EDR baseband layer 14 plays a role of 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).

The link manager layer 16 may perform the following functions.

ACL / SCO logical transport, logical link setup and control

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

-Perform power control and role switch.

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

The host controller interface layer 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), a security manager (SM, 22), an attribute protocol (Protocol, 23), a generic attribute profile, GATT 24), Generic Access Profile (GAP) 25, BR / EDR Profile 26.

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 Security Manager (SM) 22 is a protocol for authenticating a device and providing key distribution.

The generic attribute profile GATT 24 may be operable as a protocol describing how the attribute protocol 23 is used in the construction of services. For example, the general attribute profile 24 may be operable to define how ATT attributes are grouped together into services, and may be operable to describe features associated with the services.

Thus, the generic attribute profile 24 and the attribute protocol (ATT, 23) 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 properties Protocol (23) and Profiles (26) define the definition of a service (profile) using Bluetooth BR / EDR and an application protocol for sending and receiving these data, and the Generic Access Profile (GAP) 25 ) Defines how devices are discovered, connected, and presented to users, and provides privacy.

As shown in FIG. 4B, 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).

First, 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.

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

The controller stack 30 includes a physical layer (PHY) 32, a link layer 34, and a host controller interface 36.

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.

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 42 bytes of data packets through 37 data channels. Provides the ability to send and receive.

The host stack includes a generic access profile (GAP) 40, a logical link control and adaptation protocol (L2CAP, 41), a security manager (SM, 42), an attribute protocol (ATT, 440), and a general attribute profile. (Generic Attribute Profile, GATT, 44), Generic Access Profile (25), LT profile 46 may be included. 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.

First, 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 uses three fixed channels (one for the signaling channel, one for the Security Manager, and one for the Attribute protocol).

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

The SM (Security Manager) 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).

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

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

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

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

The present invention transmits a value for the data length when a long data request is made in the GATT profile using the attribute protocol (ATT, 43) so that the client can know the data length clearly, and from the server using the UUID (Characteristic) Can receive the value.

The General Access Profile (GAP) 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.

In addition, 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.

① Service: Defines the basic behavior of the device with a combination of behaviors related to data.

② Include: Define the relationship between services

③ Characteristics: data value used in service

Behavior: A computer readable format defined by 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 be, for example, Battery, Time, FindMe, Proximity, Time, Object Delivery Service, and the like. Details of GATT-based Profiles are as follows.

① Battery: How to exchange battery information

② Time: How to exchange time information

③ FindMe: Provides alarm service according to distance

④ Proximity: How to exchange battery information

⑤ Time: How to exchange time information

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. For example, 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.

Thus, the generic attribute profile 44 and the attribute protocol (ATT, 43) may use features to describe the state and services of a device, and how features relate to each other and how they are used.

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

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

Device Filtering Procedure

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

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

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

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

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

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

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

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

Advertising Procedure

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

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

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

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

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

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

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

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

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

Scanning Procedure

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

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

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

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

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

Discovery Procedure

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

The discovery procedure is performed asymmetrically. A Bluetooth device that attempts to find 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.

Connecting Procedure

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

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

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

Advertising State

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.

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

Scanning State

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

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

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

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

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

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

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

Initiating State

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

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

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

Connection state

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

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

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

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

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

Packet Format

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

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

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

Advertising Channel PDUs

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

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

Table 1

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

Advertising PDU

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

ADV_IND: Connectable Non-Oriented Ads Event

ADV_DIRECT_IND: Connectable Directional Advertising Event

ADV_NONCONN_IND: Non-Connectable Non-Oriented Ads Event

ADV_SCAN_IND: Scannable Non-Oriented Advertising Event

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

Scanning PDU

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

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

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

Initiating PDU

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

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

Data Channel PDUs

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

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

FIG. 5 is a diagram illustrating an example of a PDU structure for providing an attribute structure and an attribute value of Bluetooth low power energy.

FIG. 5A illustrates an example of the elements of the attribute described above. One attribute includes four elements and has the following meaning.

Attribute Handle: address of the attribute

Attribute Type: the type of attribute

Attribute Value: the value of the attribute

Attribute Permissions: access to attributes

The server provides a service using an attribute of the above type, and transmits data in the form of an attribute protocol PDU (Attribute Protocol PDU) as shown in FIG.

Table 2 below shows an example of the attribute protocol PDU of FIG. 5 (b).

TABLE 2

Name	Size (Octets)	Description
Attribute Opcode	One	The Attribute PDU operation codebit 7: Authentication Signature Flagbit 6: Command Flagbit 5-0: Method
Attribute Parameter	0 to (ATT_MTU-X)	The Attribute PDU parameters X = 1 if Authentication Signature Flag of the Attribute Opcode is 0X = 13 if Authentication Signature Flag of the Attribute Opcode is 1
Authentication Signature	0 or 12	Optional authentication signature for the Attribute Opcode and Attribute Parameters

As shown in Table 2 and FIG. 5B, the attribute protocol PDU may include an opcode field, an attribute parameters field, and / or an authentication signature field.

The attribute opcode is octet data and includes information indicating which PDU is the corresponding attribute protocol PDU.

Table 3 below shows an example of the attribute opcode.

TABLE 3

Attribute PDU Name	Attribute Opcode	Parameters
Error Response	0x01	Request Opcode in Error, Attribute Handle In Error, Error Code
Exchange MTU Request	0x02	Client Rx MTU
Exchange MTU Response	0x03	Server Rx MTU
Find Information Request	0x04	Starting Handle, Ending Handle, UUID
Find Information Response	0x05	Format, Information Data
Find by Type Value Request	0x06	Starting Handle, Ending Handle, Attribute Type, Attribute Value
Find by Type Value Response	0x07	Handles Information List
Read By Type Request	0x08	Starting Handle, Ending Handle, UUID
Read By Type Response	0x09	Length, Attribute Data List
Read Request	0x0A	Attribute Handle
Read response	0x0B	Attribute Value
Read by Blob Request	0x0C	Attribute Handle, Value Offset
Read by Blob Response	0x0D	Part Attribute Value, Handle Set
Read Multiple Request	0x0E	Value set
Read Multiple Response	0x0F	Starting Handle, Ending Handle, UUID
Read by Group Type Request	0x10	Length, Attribute Data List
Read by Group Type Response	0x11	Attribute Handle, Attribute Value
Write Request	0x12	-
Write Response	0x13	Attribute Handle, Attribute Value
Write Command	0x52	Attribute Handle, Attribute Value
Prepare Write Request	0x16	Attribute Handle, Value Offset, Part Attribute Value
Prepare Write Response	0x17	Attribute Handle, Value Offset, Part Attribute Value
Execute Write Request	0x18	Flags
Execute Write Response	0x19	-
Handle Value Notification	0x1B	Attribute Handle, Attribute Value
Handle Value Indication	0x1D	Attribute Handle, Attribute Value
Handle Value Confirmation	0x1E
Signed Write Command	0xD2	Attribute Handle, Attribute Value, Authentication Signature

The Attribute Parameters include information to be delivered in an actual message and may have the following values.

Handle: Index where the data is located

Value: the value of the data

Data List: List of multiple data values

Length: the length of the data

The Authentication Signature may optionally exist or not exist as an Optional field, and may include Signature information of 12 octets in the case of a Signed Write Command.

Through the Attribute Protocol PDU, the client can read the Attribute Handle value, Attribute Value, Data List, or Length value stored in the server or store the above values in the server.

The present invention thus proposes an error code used when loading or storing data in a server and a method for accurately reading a specific value.

6 is a flowchart illustrating an example of a method for acquiring large data (data larger than ATT_MTU-1) stored in a server using a Bluetooth low power energy technology.

Referring to FIG. 6, when data is transmitted / received through Bluetooth Low Energy (LE), a message type may be transmitted according to the size or length of data.

In detail, the client 120 and the server 110 have a Bluetooth LE link formed through a Bluetooth LE connection procedure.

Thereafter, the client 120 reads a read request to the server 110 to read data (for example, an attribute value) stored in the server 110 through the attribute protocol described above. Request (S610).

At this time, the client 120 requests the server 110 to include data by including a handle value of a characteristic value to be read in the read request.

The maximum data transmission size of the attribute protocol is ATT_MTU-1. If the data is larger than this, only the size of ATT_MTU-1 can be read.

The server 100 receiving the read request finds data stored based on a Handle value included in the read request and transmits the data to the client through a read response. (S620).

In this case, the maximum size of data that can be transmitted through the read response is ATT_MTU-1. If the size is larger than this, only the size of ATT_MTU-1 can be transmitted.

The client, which has received data through the read response, has a variable length of the data (for example, characteristic), and thus, if all data has not been transmitted at once through the read response, whether the additional data exists. I can not know.

If the client 120 reads data having a size larger than ATT_MTU-1, the client 120 may partially read the data, and for this purpose, the client 120 may request a read blob from the server 110. Request (S630).

The read blob request includes not only a Handle value of a characteristic to be read, but also a characteristic offset to read partially divided data, so that data can be read from the characteristic offset.

Upon receiving the read blob request, the server 110 includes data corresponding to a size up to ATT_MTU-3 based on the Handle value and the property offset value in a read blob response, and the client 120. It transmits to (S630).

Thereafter, if data to be transmitted remains, data may be received through an additional request and response (S630).

However, when the value of the characteristic offset is greater than the data size or the size of the data received through the read blob response is smaller than the ATT_MTU-3, the additional request may not be transmitted. have.

Alternatively, when the client 120 receives an invalid offset response, the additional request may not be transmitted.

In such a method, the client 120 needs to know the size of the data to be transmitted in advance to receive the split transmission through the read blob request. Otherwise, the client 120 cannot receive the data through the read request. The problem is that it is not known whether the data is part of the overall data or whether there is additional data.

In order to solve such a problem, the present invention proposes a method of transmitting information such as whether additional data is present in the read response and the length of the data.

7 is a flowchart illustrating still another example of a method for acquiring data stored in a server (data smaller than ATT_MTU-1) using a Bluetooth low power energy technology.

Referring to FIG. 7, a characteristic value stored in a server may be read using a UUID of a characteristic.

In detail, when the client 120 knows the UUID of a specific characteristic, the client 120 transmits a read by type request to the server 110 to read data from the server 110 using the same (S710). .

In this case, the read by type request may include a UUID value, a starting handle value, and an ending handle value of a specific characteristic.

Here, generally, the starting handle value and the ending handle value are starting handle value and ending handle value of a specific service.

The server 110 receiving the read by type request transmits the requested value to the client 120 through the read by type response (S720).

In this case, a number of characteristic values having the UUID may exist between the Starting Handle value and the Ending Handle value, and since the server 110 may not know the Handle value of the characteristic, the same UUID may be obtained. The branch may transmit a plurality of characteristic values to the client 120.

Thereafter, if there is additional data to be transmitted from the server 110, the client 120 may receive the data through an additional request and response (S730).

In this manner, since the Read By Type Response can transmit only a maximum size of ATT_MTU-1, the Read By Type Response may not include the characteristic value desired by the client 120.

In addition, since the client 120 does not have the handle information of the characteristic, there is a problem that it is difficult to determine which characteristic (Characteristic) value with the received value.

Therefore, the present invention proposes a method of receiving a Handle value of the characteristic from the server.

8 is a flowchart illustrating an example of a method for receiving data from a server by transmitting an error message according to the size of data proposed in the present specification.

Referring to FIG. 8, when the data size to be read from the server is larger than the maximum transmission size of the read response, the split message may be transmitted by transmitting an error message.

In detail, when the client 120 wants to read data stored in the server 110, the client 120 transmits a read request to the server 110 (S810). .

In this case, the read request includes a handle value of the corresponding attribute. For example, if you want to read an attribute value as shown in Table 4 below, the client 120 transmits a handle value of “0x0123” in the read request.

Table 4

Attribute Handle	Attribute Type	Attribute Value	Attribute Permission
0x0123	Name	A very long device name using a long attribute

The server 110 receiving the read request may find the requested data based on the Handle value. At this time, if the size of the requested data is larger than the maximum transmission size of the read response (Read Response), the server 110 transmits an error response (Error Response) to the client 120 (S820).

Table 5 below shows an example of the data format of the error response.

Table 5

Parameter	Size (octets)	Description
Attribute Opcode	One	0x01 = Error Response
Request Opcode In Error	One	The Request that generated this error response
Attribute Handle In Error	2	The attribute Handle that generated this error response
Error Code	One	The reason why the request has generated an error response

The error response may be composed of an attribute opcode, a request opcode in error, an attribute handle in error, and / or an error code.

The attribute opcode indicates an error response with a value of “0x01”. The Request Opcode In Error indicates an Opcode of a request in which an Error occurs, and the Attribute Handle in Error indicates an attribute handle value of a Request in which an Error occurs.

The error code indicates a cause of an error and may have one of values shown in Table 5 below.

Table 6 below shows an example of the error code value.

Table 6

Name	Error Code	Description
Invalid Handle	0x01	The Attribute Handle given was not valid on this server
Read Not Permitted	0x02	The attribute cannot be read
Write Not Permitted	0x03	The attribute cannot be written
Invalid PDU	0x04	The attribute PDU was invalid
Insufficient Authentication	0x05	The attribute requires authentication before it can be read or written
Request Not Supported	0x06	Attribute server does not support the request received from the client
Invalid Offset	0x07	Offset specified was past the end of the attribute
Insufficient Authorization	0x08	The attribute requires authorization before it can be read or write
Prepare Queue Full	0x09	Too many prepare writes have been queued
Attribute Not Found	0x0A	No attribute found within the given attribute handle range
Attribute Not Long	0x0B	The attribute cannot be read or written using the Read Blob Request
Insufficient Encryption Key Size	0x0C	The Encryption Key Size Used for encryption this link is insufficient
Invalid Attribute Value Length	0x0D	The attribute value length is invalid for the operation
Unlikely Error	0x0E	The attribute request that was requested has encountered an error that was unlikely, and therefore could not be completed as requested
Insufficient Encryption	0x0F	The attribute requires Encryption before it can be read or written
Unsupported Group Type	0x10	The attribute type is not a supported grouping attribute as defined by a higher layer specification
Insufficient Resources	0x11	In sufficient Resources to complete the request
Attribute Too Long	0x12	The attribute cannot be read or written using the Read Request
Attribute Too many	0x13	The attribute cannot be read or written due to more than one attribute
Invalid Attribute Value Type	0x14	The Type of Attribute value is invalid
Reserved	0x15-0x7F	The attribute requires authorization before it can be read or write
Application Error	0x80-0x9F	Too many prepare writes have been queued
Reserved	0xA0-0xDF	No attribute found within the given attribute handle range
Common Profile and Service Error Codes	0xE0-0xFF

In this case, since the size of the requested data is larger than the maximum transmission size of the read response, the server 110 sets the error code value of the error response to “0x12” so that the information of the read request is read. Along with the client 120.

The read request information may include an Opcode and / or request Handle value of the read request.

Upon receiving the error response, the client 120 may know that the size of the requested characteristic value is larger than the maximum transmission size that can be transmitted through a read response.

Therefore, the client 120 transmits a read blob request to the server 110 in order to receive the divided value of the characteristic (S830). The read blob request includes a handle value of an attribute to be transmitted, and an offset value indicating a start point of data to be transmitted.

The read blob request may include an attribute handle value "0x0123" and an offset value (0x0000).

The server receiving the request has a property value having a Handle value corresponding to “0x0123” and a value corresponding to a size of “0x0000” to ATT_MTU-1 (“0x0016”) (“A very Long Device Nam in this embodiment”). ”) Is transmitted to the client 120 through a read blob response (S840).

Thereafter, the client transmits a read blob request including a handle value “0x0123” and an offset value “0x0016” to the server 110 in order to receive a subsequent value (S850).

The server 110 receiving the request reads a value (“e Using A Long Attribu” in this embodiment) corresponding to a value from the requested offset value to ATT_MTU-1 through the client blob response. It transmits to (S860).

Since the client 120 does not receive data smaller than the size of ATT_MTU-1 or a response having an Invalid Offset Error Code, the client 120 may recognize that there is additional data.

Accordingly, the client 120 transmits a read blob request including a handle value “0x0123” and an offset value “0x002C” to the server 110 (S870).

The server 110 receiving the request transmits the remaining value (“te” in this embodiment) from the requested offset value to the client 120 (S880), and the client 120 is larger than ATT_MTU-1. Since a small amount of data has been transmitted, it is recognized that there is no additional data.

Through this method, the client can know the size or length of the data to be transmitted, and can receive all of the length data even when the read response is transmitted.

9 is a diagram illustrating an example of a method for transmitting data through another response message according to the size of data requested as proposed herein.

Referring to FIG. 9, unlike the FIG. 8, the server transmits data using a different response message according to the size of the requested data, without using an error message.

In detail, when the server 110 receives a data transmission request from the client 120 (S910), the server 110 may find data to be transmitted through a handle value included in the request message.

The server 110 that finds the requested data determines whether the data is larger than a maximum transmission size ATT_MTU-1 that can be transmitted through a read response (S920).

As a result of the determination, when the data is larger than the ATT_MTU-1, the server 110 transmits the data through a read blob response in order to divide and transmit the data (S930).

However, when the data is smaller than the ATT_MTU-1, the server 110 transmits the data to the client 120 through a read response (S940).

FIG. 10 is a diagram illustrating another example of a method for transmitting data through another response message according to the size of data requested according to the present specification.

Referring to FIG. 10, the method described with reference to FIG. 9 will be described with reference to specific examples. The client 120 may transmit a read request to the server 110 to request the characteristic values as shown in Table 3 stored in the server 110 (S1010).

At this time, the read request has a handle value of "0x0123".

The server 100 may find a value of “A Very Long Device Name Using a Long Attribute” which is a requested characteristic value by using the handle value, and determine whether the characteristic value is larger than the maximum transmission size (ATT_MTU-1). can do.

At this time, when the characteristic value is larger than the ATT_MTU-1, the server 110 reads the data “A Very Long Device Nam” corresponding to the size of the ATT_MTU-1 through a read blob response. It transmits to the client 120 (S1020).

The client sees that a read blob response has been sent in response to the read request and can see that there is additional data.

Accordingly, the client transmits a read blob request to the server 110 to receive additional data (S1030). In this case, the read blob request may include “0x0123”, which is a handle value of a corresponding attribute, and “0x0016”, which is an offset value of a value to be transmitted.

Upon receiving the read blob request, the server 110 selects, from the offset value “0x0016” based on the handle value, the value “e Using a Long Attribu” corresponding to the maximum transmission size together with the offset value. The client 120 transmits the data to the client 120 (S1040).

Since the client 120 does not receive data smaller than the size of ATT_MTU-1 or a response having an Invalid Offset Error Code, the client 120 may recognize that there is additional data.

Accordingly, the client 120 transmits a read blob request including a handle value “0x0123” and an offset value “0x002C” to the server 110 (S1050).

The server 110 receiving the request transmits a “te” value corresponding to the remaining value from the requested offset value to the client 120 (S1060), and the client 120 has a smaller size than ATT_MTU-1. It is recognized that there is no additional data as the data of is transmitted.

Thus, the client no longer requests data to the server 110.

11 is a flowchart illustrating still another example of a method for acquiring data stored in a server, proposed in the present specification.

Referring to FIG. 11, when a feature value to be read from a server is requested as the UUID of the feature value, an error message is transmitted when there are a plurality of feature values having the same UUID to receive the feature value through another UUID. Can be.

In detail, the client may request data having a Handle value between “0x100” and “0x150” and a characteristic UUID of “<< Temperature >>” to the server 110 through a read by type request (S1110). ).

In this case, when the server 110 stores a value as shown in Table 7 below, a plurality of pieces of data having a UUID of “<< Temperature >>” exist between “0x100” and “0x150”.

TABLE 7

Attribute Handle	Attribute Type	Attribute Value	Attribute Permissions
0x0122	<< Characteristic >>	0x02, 0x0123, << Temperature >>
0x0123	<< Temperature >>	10 ℃
0x0124	<< Characteristic >>	0x02, 0x0125, << Temperature >>
0x0125	<< Temperature >>	25 ℃

Therefore, the server 110 transmits an error response to the client 120 because there are a plurality of identical UUIDs (S1120).

The error code value of the error response indicates “0x13” in Table 5 and includes information of the read by type request.

The read request information may include an Opcode and / or a requested Handle value of the Read By Type Request.

The client may know that a plurality of data having the same UUID exists through the error response, and may change the UUID to “<< Characteristic >>” and transmit a Read By Type Request again (S1130).

Based on the information, the server 110 finds data having a Handle value between “0x100” and “0x150” as shown in Table 6 above, and the characteristic UUID is “<< characteristic >>”.

As shown in Table 6, the values that can be found based on the above information are the values corresponding to the handle values of “0x0122” and “0x0124”.

Thereafter, the server 110 transmits the data found based on the information to the client 120 through a read by type response (S1140).

12 is a flowchart illustrating an example of a method for receiving data stored in a server proposed in the present specification.

Referring to FIG. 12, data stored in a server may be transmitted through an attribute value as well as a handle value and an attribute type.

Specifically, the client 120 transmits a Read By Type Value Request to the server to read the data stored in the server 110 (S1210).

The Read By Type Value Request is for requesting data using not only the UUID and Handle of the value stored in the server but also the value of the attribute and may have a data format as shown in Table 8 below.

Table 8

Parameter	Size	Description
Attribute Opcode	One	0x21 = Read Value By Type Reqeust
Starting Handle	2	First Requested handle number
Ending handle	2	Last Requested handle number
Attribute Type	2	2 octet UUID of Finding Attribute Type
Attribute Value	0 to (ATT_MTU-7)	Attribute value to find

The attribute opcode has a value of "0x21" shown in Table 9 below.

Table 9

Attribute PDU Name	Attribute Opcode	Parameters
Read By Type Value Request	0x21	Starting Handle, Ending Handle, Attribute Type, Attribute Value
Read By Type Value Response	0x22	Length, Attribute Data

The Starting handle represents a starting handle of a range including an attribute to be found, and the Ending Handle represents a last handle including an attribute to be found.

The Attribute Type indicates the type of attribute to be searched (which can be specified by UUID) and has the following characteristics.

-Can be specified in UUID form

-Characteristic information is found when defined as << Characteristic >>.

-When defined as << Characteristic Format >>, finds specific type of characteristic information.

-When defined as << Characteristic User Description >>, specific type of characteristic information is found.

-Characteristic information to find depends on the type of attribute value.

The attribute value indicates a value of data to be searched for and has a format as shown in Table 10 below.

Table 10

Data	Size (octet)	Description
Value type	One	Type of Value0x01
Value	2 (if Value Type = 0x01) 4 (if Value Type = 0x02) 16 (if Value Type = 0x03) 1-(ATT_MTU-8) (if Value Type = 0x03) 1 (if Value Type = 0x04)

The value shown in Table 6 is stored in the server 110. The Read By Type Value Request has a Starting Handle of “0x100”, an Ending Handle of “0x150”, and an Attribute Type of “<< Characteristic >>”. It may include “<< Temperature >>” whose Value Type is “0x01” and the Value of Attribute Value is 16 bit UUID.

The server 110 may find a corresponding value based on the above value, and transmit the corresponding value to the client 120 through a read by type value response (S1220).

Table 11 below shows an example of the Read By Type Value Response format.

Table 11

Parameter	Size (octets)	Description
Attribute Opcode	One	0x22 = Read Value By Type Response
Length	One	The size of each attribute handle value paire
Attribute Data List	2 to (ATT_MTU-2)	A list of Attribute Data

The opcode may have a value of '0x22' of Table 8. The Length indicates the length of attribute data provided by the Read By Type Value Response and is determined by the attribute type and the UUID value of the request message.

Since the attribute type included in the read by type value is 16 bit UUID, the length may use a value of 7 bytes.

The attribute data list represents a structure of attribute data provided through the read by type value response.

Table 12 below shows an example of the format of the Attribute Data List.

Table 12

Parameter	Size (octets)	Description
Property	One	Characteristic Property
Handle	2	Characteristic Value Handle
Characteristic UUID	2 or 16 (or 4)	Characteristic UUID

The property represents a property value of a corresponding characteristic, and the handle represents a handle value in which a characteristic value is stored.

In this embodiment, the Property may indicate “0x02” and the Handle may indicate “0x0123”.

The Characteristic UUDI may return a UUID value according to a Length value, and in the present embodiment, may return “<< Temperature >>”.

The client 120 that has received the read by type value response has a handle received from the server 110 as “0x0123”, and thereafter, reads the read by type value request to check whether there is a characteristic having the same characteristic uuid. S110 and transmits to (110).

At this time, the Starting Handle of the Read By Type Value Request is “0x124”, the Ending Handle is “0x150”, the Attribute Type is “<< Characteristic >>”, the Value Type of the Attribute Value is “0x01”, and the Value of the Attribute Value is 16bit It contains the UUID “<< Temperature >>”.

If there is no additional characteristic UUID, the server 110 transmits an error response to the client 120 (S1240), and the client 120 that has received the error response does not need to search any more. .

According to another embodiment of the present invention, when the client wants to find data by the characteristic value, the read type value request of the attribute value is “0x04” and the attribute value is the characteristic value “10 ° C.”. Can be.

In this case, the server 110 may find a stored value based on the value included in the read by type value request, and transmit the found value to the client 120 through the read by type value response.

In this case, the value included in the Read By Type Value Response has a length of “0x07”, a property of “0x02”, a handle of “0x0123”, and a characteristic UUDI of “<< Temperature >>”.

Thereafter, since the received handle is “0x0123”, the client transmits a Read By Type Value Request to check whether there is a Characteristic having the same Characteristic UUID.

If there is no additional characteristic UUID, the server 110 transmits an error response to the client 120, and the client recognizes that no further search is required.

FIG. 13 is a flowchart illustrating an example of a method for transmitting an error message when the requested data does not exist.

Referring to FIG. 13, when there is no data corresponding to the value requested from the client, the server may inform the client by transmitting an error message.

In detail, the client may request data having a Starting Handle of “0x100”, an Ending Handle of “0x150”, and an Attribute Type of “0x06” through the Read By Type Value Request described in FIG. 12 (S1310).

The server 110 receiving the request may find a stored value based on a value included in the Read By Type Value Request. However, as shown in Table 6, data having an attribute type of “0x06” is not stored.

Therefore, the server 110 transmits an error response including information (Read By Type Request, 0x0123) included in the Read By Type Value Request to the client because the requested data does not exist (S1320). At this time, the Opcode of the Error Response includes “0x14” indicating an Invalid Attribute Value Type Error Code of Table 5.

14 and 15 are diagrams illustrating a structure of a method and an attribute for receiving size or length information of data stored in a server proposed in the present specification.

Referring to FIG. 14, the client 120 may transmit a read attribute length request to the server 110 to request size or length information of data stored in the server 110 (S1410). .

Table 13 below shows an example of the data format of the Read Attribute Length Request.

Table 13

Parameter	Size (octets)	Description
Attribute Opcode	One	0x21 = Read Attribute Length Request
Attribute Handle	2	Handle Number of Attribute

The attribute opcode may have a value of “0x21” shown in Table 13 below, and the attribute handle indicates a handle value where the corresponding attribute is located.

Table 14 below shows an example of Opcodes of Read Attribute Length Request and Read Attribute Length Response.

Table 14

Attribute PDU Name	Attribute Opcode	Parameters
Read Attribute Length Request	0x21	Attribute Handle
Read Attribute Length Response	0x22	Attribute Length

The server 110 may find a corresponding attribute by a handle value included in the request from the client 120, and transmits the length value of the corresponding attribute to the client by including the read attribute length response in operation S1420.

Table 15 below shows an example of a format of the Read Attribute Length Response.

Table 15

Parameter	Size (octets)	Description
Attribute Opcode	One	0x22 = read Attribute Length Response
Length	2	The size of each attribute value

The attribute opcode includes a “0x22” value indicating a read attribute length response in Table 14, and the length indicates the length of the corresponding attribute.

For example, if the server 110 stores a value as shown in Table 16 below, and the client requests the length of an attribute whose Handle value is “0x0123”, the server 110 reads the value of “0x05”. May transmit to the client 120.

Table 16

Attribute Handle	Attribute Type	Attribute Value	Attribute Permissions
0x0122	<< Characteristic >>	0x02, 0x0123, << Name >>
0x0123	<< Name >>	Jingu

Through this method, the client can request length information of a specific attribute value from the server, and can determine what type of request to send to the server based on the length information of each attribute value.

That is, on the basis of the length information of the attribute value, if the length is smaller than the maximum transmission size, the read value or write request may be transmitted to the server 110 to receive the corresponding value. .

However, when the length is larger than the maximum transmission size, since the data must be transmitted by dividing the data from the server 110, a read blob request may be transmitted to the server 110 to receive a corresponding value.

In addition, since the client 120 knows the exact length of the attribute value, the presence of additional data can also be accurately determined.

FIG. 15 shows that the server 110 stores length information of an attribute. That is, the server 110 may store the length value of the attribute value in the attribute value length as shown in FIG. 15.

Accordingly, when the server 110 requests the client 120, the server 110 may provide a length value of a corresponding attribute value, and the client 120 may read the server 110 based on this. A request (Read Request) or a Read Blob Request can be clearly transmitted.

Table 17 below shows an example of the Logical Attribute Representation illustrated in FIG. 15.

Table 17

Attribute Handle	Attribute Type	Attribute Value	Attribute Value Length	Attribute Permissions
0x0122	<< Characteristic >>	0x02,0x0123, << Name >>	0x05 (for 16-bit UUID) 0x13 (for 128-bit UUID)
0x0123	<< Name >>	Jingu	0x05

As such, the server 110 may manage the length of the corresponding value by adding an attribute value length field to the attribute representation.

In addition, when there is a request from the client 120, the length information of the corresponding value may be transmitted to the client 120 through a response.

FIG. 16 is a flowchart illustrating an example of a method for notifying a client of data stored in a server, as proposed herein.

Referring to FIG. 16, when the server has a large amount of data to notify the client, the data may be transmitted through multiple notifications.

Specifically, when the size of the attribute value that the server 110 intends to transmit to the client is larger than the size of ATT_MTU-3, which is the maximum transmission size, the server 110 may transmit data through a Blob Handle Value Notification.

Table 18 below shows an example of a format of the Blob Handle Value Notification.

Table 18

Parameter	Size (octet)	Description
Attribute Opcode	One
Attribute Handle	2	Handle Number of Attribute
Part Attribute Value	0-ATT_MTU-5	Part of the value of the attribute
offset	2	Offset of the attribute value to be read

The opcode may have a value of “0x22” indicating a blob handle value notification of Table 19 below, and the attribute handle indicates a handle value where a corresponding attribute is located.

The part attribute value represents a partial attribute value transmitted in the notification.

The off set represents the off set value of the first value of the attribute value actually provided.

Table 19

Attribute PDU Name	Attribute Opcode	Parameter
Blob Handle Value Notification	0x22	Attribute Handle, Part Attribute Value, Offset
Blob Handle Value Indication	0x23	Attribute Handle, Part Attribute Value, Offset
Blob Handle Value Confirmation	0x24	Attribute Handle, Offset

For example, when the server 110 transmits the data of Table 4 to the client 120, the value of “A very Long Device Name Using a Long Attribute” of Table 3 is longer than ATT_MTU-3. Therefore, it cannot be transmitted to the client 120 at one time.

Therefore, the server 110 transmits data up to ATT_MTU-3 to the client 120 through the Blob Handle Value Notification (S1610).

At this time, the Attribute Handle may have a value of “0x0123”, a part attribute value of “A Very Long Device Nam”, and an OFFSet of “0x00” value.

Thereafter, the server 110 transmits a Blob Handle Value Notification to the client 120 again in order to additionally transmit the data that has not been sent in step S1610 to the client 120 (S1620).

At this time, the Attribute Handle may have a value of “0x0123”, a part attribute value of “e Using a Long Attribu”, and an OFFSet of “0x0016”.

In step S1520, the server 110 that fails to transmit all the data transmits a Blob Handle Value Notification to the client 120 again in order to transmit the remaining data to the client 120 (S1630).

At this time, the attribute handle may have a value of “0x0123”, a part attribute value of “te”, and an OFFSet of “0x002C”.

The client 120 receiving the Blob Handle Value Notification transmits data of the attribute when the amount of transmitted data is not the maximum transmission size that the message can transmit or when there is no further transmission for a predetermined time. It can be determined that this is completed.

FIG. 17 is a flowchart illustrating another example of a method for notifying a client of data stored in a server proposed in the present specification.

Referring to FIG. 17, if it is determined that additional data exists through the notification, the client may request the server to transmit additional data and receive the additional data.

In detail, when the server 110 transmits data through the Blob Handle Value Notification described with reference to FIG. 16, the client 120 may recognize that the attribute value is long and cannot be transmitted at once. .

Thereafter, the client 120 may transmit the Read Blob Request described above to the server 110 to make an additional data request, and the server 110 transmits a Read Blod Response to the client 120 in response thereto. To transmit additional data.

For example, if the server 110 wants to transmit “A very Long Device Name Using a Long Attribute” of Table 4, it cannot transmit it through one PDU.

Therefore, the server 110 transmits data up to ATT_MTU-3 to the client 120 through the Blob Handle Value Notification (S1710).

At this time, the Attribute Handle may have a value of “0x0123”, a part attribute value of “A Very Long Device Nam”, and an OFFSet of “0x00” value.

The client 120 may determine whether additional data exists in the server 110 based on whether the data is transmitted through the blob handle value notification or based on data length information transmitted or known.

If additional data exists, the client 120 transmits a read blob request to the server 110 (S1720).

Since step S1730 to step S1750 is the same as step S860 to step S880 of FIG. 8 or step S1040 to step S1060 of FIG. 10, description thereof will be omitted.

FIG. 18 is a flowchart illustrating an example of a method for instructing a client of data stored in a server, proposed in the present specification.

Unlike FIG. 16, FIG. 18 may transmit data stored in the server 110 to the client 120 through an indication, and the client 120 receiving the data may transmit the data to the server 110. ) Can be notified that data has been sent via Confirmation.

Specifically, when the size of the attribute value that the server 110 intends to transmit to the client is larger than the size of ATT_MTU-3, which is the maximum transmission size, the server 110 may transmit data through a Blob Handle Value Indication.

The format of the Blob Handle Value Indication is the same as the format of the Blob Handle Value Notification. At this point, the attribute opcode has a value of “0x23” indicating the blob handle value indication.

The client 120 that has received data from the server 110 through the blob handle value indication may transmit a blob handle value confirmation to the server 110 in response.

Table 20 below shows an example of a format of the Blob Handle Value Confirmation.

Table 20

Parameter	Size (octet)	Description
Attribute Opcode	One
Attribute Handle	2	Handle Number of Attribute
Offset	2	Offset of the attribute value to be read

The attribute opcode may include “0x24” which is a value representing Blob Handle Value Confirmation in Table 19.

For example, when the server 110 transmits the data of Table 4 to the client 120, the value of “A very Long Device Name Using a Long Attribute” of Table 3 is longer than ATT_MTU-3. Therefore, it cannot be transmitted to the client 120 at one time.

Therefore, the server 110 transmits data up to ATT_MTU-3 to the client 120 through the Blob Handle Value Indication (S1810).

At this time, the Attribute Handle may have a value of “0x0123”, a part attribute value of “A Very Long Device Nam”, and an OFFSet of “0x00” value.

The client 120 receiving data from the server 110 transmits a blob handle value confirmation to the server 110 in response (S1820).

At this time, the Attribute Handle may have a value of “0x0123” and an OFFSet may have a value of “0x0016” indicating information on the received data amount.

Thereafter, the server 110 transmits a Blob Handle Value Indication to the client 120 again in order to additionally transmit the data that has not been sent in step S1710 to the client 120 (S1830).

At this time, the Attribute Handle may have a value of “0x0123”, a part attribute value of “e Using a Long Attribu”, and an OFFSet of “0x0016”.

The client 120 transmits the Blob Handle Value Confirmation to the server 110 again in response (S1840).

At this time, the Attribute Handle may have a value of “0x0123” and an OFFSet may have a value of “0x002C” indicating information on the received data amount.

In step S1730, the server 110 that fails to transmit all the data transmits a Blob Handle Value Indication to the client 120 again in order to transmit the remaining data to the client 120 (S1850).

At this time, the attribute handle may have a value of “0x0123”, a part attribute value of “te”, and an OFFSet of “0x002C”.

The client 120 again transmits the Blob Handle Value Confirmation to the server 110 in response (S1860).

At this time, the Attribute Handle may have a value of “0x0123” and an OFFSet may have a value of “0x002E” indicating information of the received data amount.

The client 120 that has received the Blob Handle Value Indication transmits data of the attribute when the amount of transmitted data is not the maximum transmission size that the message can transmit or when there is no further transmission for a predetermined time. It can be determined that this is completed.

FIG. 19 is a flowchart illustrating still another example of a method for instructing a client of data stored in a server, proposed in the present specification.

Referring to FIG. 19, if it is determined that additional data exists, the client that has received data through the indication may request the server to transmit additional data and receive the additional data.

In detail, when the server 110 transmits data through the Blob Handle Value Indication described with reference to FIG. 18, the client 120 may recognize that the attribute value is long and cannot be transmitted at once. .

Thereafter, the client 120 may transmit the Read Blob Request described above to the server 110 to make an additional data request, and the server 110 transmits a Read Blod Response to the client 120 in response thereto. To transmit additional data.

For example, if the server 110 wants to transmit “A very Long Device Name Using a Long Attribute” of Table 4, it cannot transmit it through one message.

Accordingly, the server 110 transmits data up to ATT_MTU-3 to the client 120 through the Blob Handle Value Indication (S1910).

At this time, the Attribute Handle may have a value of “0x0123”, a part attribute value of “A Very Long Device Nam”, and an OFFSet of “0x00” value.

The client 120 receiving data from the server 110 transmits a blob handle value confirmation to the server 110 in response (S1820).

At this time, the Attribute Handle may have a value of “0x0123” and an OFFSet may have a value of “0x0016” indicating information on the received data amount.

The client 120 may determine whether additional data exists in the server 110 based on the data transmitted through the Blob Handle Value Indication or based on data length information transmitted or known. .

If additional data exists, the client 120 transmits a read blob request to the server 110 (S1920).

Since step S1940 to step S1960 are the same as step S860 to step S880 of FIG. 8 or step S1040 to step S1060 of FIG. 10, description thereof is omitted.

20 to 23 are flowcharts illustrating an example of an error that occurs when data is stored in a server proposed in the present specification.

20 to 23, when the client 120 stores data in the server 110, an error may occur by incorrectly specifying the size and type of the data.

In detail, when the client 120 wants to store data in the server 110, the client 120 may transmit a write request to the server 110 and store the data.

In this case, the write request includes a data value to be stored and a handle value corresponding thereto.

However, if the type, shape, size, and range of values to be stored through the write request do not match, the server 110 transmits an error response to the client.

The error response has the same format as Table 5 above.

Table 21 below shows an example of an error code value of the error response.

Table 21

Name	Error Code	Description
Invalid Handle	0x01	The Attribute Handle given was not valid on this server
Read Not Permitted	0x02	The attribute cannot be read
Write Not Permitted	0x03	The attribute cannot be written
Invalid PDU	0x04	The attribute PDU was invalid
Insufficient Authentication	0x05	The attribute requires authentication before it can be read or written
Request Not Supported	0x06	Attribute server does not support the request received from the client
Invalid Offset	0x07	Offset specified was past the end of the attribute
Insufficient Authorization	0x08	The attribute requires authorization before it can be read or write
Prepare Queue Full	0x09	Too many prepare writes have been queued
Attribute Not Found	0x0A	No attribute found within the given attribute handle range
Attribute Not Long	0x0B	The attribute cannot be read or written using the Read Blob Request
Insufficient Encryption Key Size	0x0C	The Encryption Key Size Used for encryption this link is insufficient
Invalid Attribute Value Length	0x0D	The attribute value length is invalid for the operation
Unlikely Error	0x0E	The attribute request that was requested has encountered an error that was unlikely, and therefore could not be completed as requested
Insufficient Encryption	0x0F	The attribute requires Encryption before it can be read or written
Unsupported Group Type	0x10	The attribute type is not a supported grouping attribute as defined by a higher layer specification
Insufficient Resources	0x11	In sufficient Resources to complete the request
Invalid Format (Data Type)	0x12	The format (type) of attribute value is incorrect.
Invalid Value	0x13	The value of attribute is incorrect
Invalid Value due to more than Maximum	0x14	The value of attribute is incorrect because it exceeds the maximum value
Invalid Value due to more than Minimum	0x15	The value of attribute is incorrect because it is less or fewer than the minimum value
Reserved	0x16-0x7F	The attribute requires authorization before it can be read or write
Application Error	0x80-0x9F	Too many prepare writes have been queued
Reserved	0xA0-0xDF	No attribute found within the given attribute handle range
Common Profile and Service Error Codes	0xE0-0xFF

20 illustrates a case in which a value or type of a value does not match, the client 120 requests to store an “0x033” value at a position where a handle value is “0x0123” through the write request. (S2010).

However, when storing the data of “string” in the value of the attribute located in the handle value, the server 110 transmits an error response to the client 120 because the type or form of the value to be stored does not match. (S2020).

In this case, the error response may include the error code “0x12” and / or information of the read request.

The read request information may include an Opcode and / or request Handle value of the read request.

21 is a case where the value range is not correct, the client 120 requests the storage of the value “0x033” (integer) at the position where the handle value is “0x0123” through the write request ( S2110).

However, when storing the data of "string" in the value of the attribute located in the handle value, the server 110 transmits an error response to the client 120 because the range of the value to be stored is not correct ( S2120).

In this case, the error response may include the error code “0x13” and / or information of the read request.

The read request information may include an Opcode and / or request Handle value of the read request.

FIG. 22 illustrates a case in which a maximum value that can be stored is exceeded. The client 120 transmits a value of “0x78” (integer, decimal) to a position where a handle value is “0x0123” through the write request. In step S2210, a request is made to store the information.

However, if the value of the attribute located in the handle value stores the water temperature as shown in Table 22 below, the range value is 0 ℃-100 ℃.

Therefore, the request value exceeds the maximum value that can be stored. For this reason, an error response is transmitted to the client 120 (S2220).

Table 22

Attribute Handle	Attribute Type	Attribute Value	Attribute Permission
0x0122	<< Characteristic >>	0x02, 0x0123, << Temperature >>
0x0123	<< Temperature >>	10 ℃

In this case, the error response may include the error code “0x14” and / or information of the read request.

The read request information may include an Opcode and / or request Handle value of the read request.

FIG. 23 illustrates a case where a minimum value that can be stored is exceeded, and the client 120 transmits a value of "-0x20" (integer, decimal) to a position where a handle value is "0x0123" through the write request. Request storage of -32) (S2310).

However, if the value of the attribute located in the handle value stores the water temperature as shown in Table 22, the range value is 0 ℃-100 ℃.

Therefore, since the request value exceeds 0, which is the minimum value that can be stored, an error response is transmitted to the client 120 (S2320).

In this case, the error response may include the error code “0x15” and / or information of the read request.

The read request information may include an Opcode and / or request Handle value of the read request.

The present invention described above is capable of various substitutions, modifications, and changes without departing from the technical spirit of the present invention for those skilled in the art to which the present invention pertains. It is not limited by the drawings.

The present specification relates to Bluetooth data transmission and reception, and more particularly, to a method and apparatus for transmitting and receiving data using Bluetooth Low Energy (LE) technology.

Claims (14)

1. In the method for transmitting and receiving data via Bluetooth Low Energy (LE) in a wireless communication system, the method performed by the first device,

   Sending a first request message for a data request to a second device;

   Receiving a first response message including data in response to the first request message;

   If the data is equal to a maximum data transmission size, transmitting a second request message for an additional data request; And

   Receiving a second response message including the additional data in response to the second request message,

   Each of the first request message or the second request message includes at least one of ID information, index information, and index range information of the data.

   Wherein each of the first response message or the second response message includes at least one of length information and ID information.
2. The method of claim 1,

   And the data is length information.
3. The method of claim 1,

   Each of the first request message or the second request message includes an offset value,

   And the offset value indicates a data transmission start position.
4. The method of claim 1,

   If the data is plural, receiving an error message from the second device;

   Transmitting a third request message including an attribute value of the data; And

   Receiving a third response message including the data in response to the third request message.
5. In the method for transmitting and receiving data via Bluetooth Low Energy (LE) in a wireless communication system, the method performed by the first device,

   Sending a request message for data transmission to a second device;

   Receiving an error message in response to the request message from the second device;

   Transmitting a first split transfer request message for split transfer request of data to the second device;

   Receiving a first split transmission response message including a part of the data in response to the split transmission request message;

   If a part of the received data is equal to a maximum data transmission size, transmitting a second split transmission request message for an additional data request; And

   Receiving a second split transmission response message including the additional data in response to the second split transmission request message;

   Each of the first split transmission request message or the second request message includes at least one of ID information, index information, and index range information of the data.

   Wherein each of the first split transmission response message or the second split transmission response message includes at least one of length information and ID information.
6. The method of claim 5,

   Each of the first divided transmission request message or the second divided transmission request message includes an offset value,

   And the offset value indicates a data transmission start position.
7. In the method for transmitting and receiving data via Bluetooth Low Energy (LE) in a wireless communication system, the method performed by the first device,

   Transmitting a request message requesting storage of specific data to the second device; And

   Receiving an error message in response to the request message;

   The error message indicates that the specific data does not fit the data format, type, or range,

   And the request message includes index information of a storage location.
8. In the method for transmitting and receiving data through Bluetooth Low Energy (LE) in a wireless communication system, the first device,

   Communication unit for transmitting and receiving a signal to the outside wired and / or wireless; And

   A control unit that is functionally connected to the communication unit, wherein the control unit includes:

   Send a first request message for a data request to a second device,

   Receiving a first response message including data in response to the first request message,

   If the data is equal to the maximum data transmission size, send a second request message for additional data request,

   Control to receive a second response message including the additional data in response to the second request message;

   Each of the first request message or the second request message includes at least one of ID information, index information, and index range information of the data.

   Each of the first response message or the second response message includes at least one of length information and ID information.
9. The method of claim 8,

   And said data is length information.
10. The method of claim 8,

    Each of the first request message or the second request message includes an offset value,

    And the offset value indicates a data transmission start position.
11. The method of claim 8, wherein the control unit,

    Receiving an error message from the second device when the data is large,

    Transmit a third request message including an attribute value of the data,

    And control to receive a third response message including the data in response to the third request message.
12. In the method for transmitting and receiving data through Bluetooth Low Energy (LE) in a wireless communication system, the first device,

    Communication unit for transmitting and receiving a signal to the outside wired and / or wireless; And

    A control unit that is functionally connected to the communication unit, wherein the control unit includes:

    Send a request message for data transmission to the second device,

    Receive an error message in response to the request message from the second device,

    Send a first split transfer request message for split transfer request of data to the second device;

    Receiving a first split transmission response message including a part of the data in response to the split transmission request message,

    If part of the received data is equal to the maximum data transmission size, send a second split transmission request message for an additional data request,

    Control to receive a second split transmission response message including the additional data in response to the second split transmission request message;

    Each of the first split transmission request message or the second request message includes at least one of ID information, index information, and index range information of the data.

    Each of the first split transmission response message or the second split transmission response message includes at least one of length information and ID information.
13. The method of claim 12,

    Each of the first split transfer request message or the second split transfer request message includes an offset value,

    And the offset value indicates a data transmission start position.
14. In the method for transmitting and receiving data through Bluetooth Low Energy (LE) in a wireless communication system, the first device,

    Communication unit for transmitting and receiving a signal to the outside wired and / or wireless; And

    A control unit that is functionally connected to the communication unit, wherein the control unit includes:

    Send a request message requesting storage of specific data to the second device,

    Control to receive an error message in response to the request message,

    The error message indicates that the specific data does not fit the data format, type, or range,

    And wherein the request message includes index information of a storage location.

Images