WO2015163547A1 - 무선 통신시스템에서 블루투스를 이용하여 http 데이터를 전송하기 위한 방법 및 장치 - Google Patents

무선 통신시스템에서 블루투스를 이용하여 http 데이터를 전송하기 위한 방법 및 장치 Download PDF

Info

Publication number
WO2015163547A1
WO2015163547A1 PCT/KR2014/009694 KR2014009694W WO2015163547A1 WO 2015163547 A1 WO2015163547 A1 WO 2015163547A1 KR 2014009694 W KR2014009694 W KR 2014009694W WO 2015163547 A1 WO2015163547 A1 WO 2015163547A1
Authority
WO
WIPO (PCT)
Prior art keywords
http
client device
request
data
response
Prior art date
Application number
PCT/KR2014/009694
Other languages
English (en)
French (fr)
Inventor
권영환
김도균
이현재
이민수
이재호
Original Assignee
엘지전자(주)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자(주) filed Critical 엘지전자(주)
Priority to KR1020167029187A priority Critical patent/KR101990489B1/ko
Priority to US15/305,964 priority patent/US9961481B2/en
Publication of WO2015163547A1 publication Critical patent/WO2015163547A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0203—Power saving arrangements in the radio access network or backbone network of wireless communication networks

Definitions

  • the present invention relates to a data transmission method, and more particularly, to a method and apparatus for transmitting HTTP data using Bluetooth, a short-range wireless communication technology.
  • Bluetooth is a proposed Radio Frequency (RF) specification for the transmission of short range, point-to-multipoint voice and data.
  • RF Radio Frequency
  • Bluetooth can transmit through solid, nonmetallic materials.
  • the transmission range is 10cm to 10m, but can be extended to 100m by increasing the transmission power. It is based on a low cost, short range wireless link and facilitates ad hoc connectivity in fixed and mobile communication environments.
  • Bluetooth uses the same ISM band, 2.45GHz frequency as 802.11b / g, which is a wireless LAN standard.Bluetooth devices can perform wireless communication by searching, selecting, and authenticating Bluetooth devices in the vicinity. have.
  • Bluetooth can achieve a relatively high speed at a relatively low power, low cost, but the transmission distance is limited to a maximum of 100m, it is suitable for use in a limited space.
  • Bluetooth has begun to become popular with the addition of the Enhanced Data Rate (EDR) standard to the 2.0 version, which has ensured a certain level of communication quality.
  • EDR Enhanced Data Rate
  • Bluetooth is becoming common, for example, listening to music wirelessly through Bluetooth communication with a Bluetooth headset.
  • the frequency of use of the music is increasing, such as playing music through smartphone-car speaker interworking using Bluetooth or playing music through Bluetooth docking speaker-smartphone interlocking.
  • WPAN Wireless Personal Area Network
  • WPAN Wireless Personal Area Network
  • Home Network Small Office
  • Vehicular Network Vehicular Network
  • WPAN is widely used because it provides real-time A / V Streaming service through electronic devices such as a headset within a limited bandwidth and maximizes energy efficiency even when performing a remote control function.
  • An object of the present invention is to provide a method and apparatus for smoothly transmitting HTTP data using Bluetooth low energy technology in a wireless communication system.
  • An object of the present invention is to provide a method and apparatus for distinguishing devices transmitting HTTP data using Bluetooth low energy technology in a wireless communication system.
  • An object of the present invention is to provide a method and apparatus for resolving an error that occurs when transmitting HTTP data using Bluetooth low energy technology in a wireless communication system.
  • An object of the present invention is to provide a method and apparatus for transmitting an error message for solving an error occurring when HTTP data is transmitted using Bluetooth low energy technology in a wireless communication system.
  • An object of the present invention is to provide a method and apparatus for determining a data transmission method when HTTP data is transmitted using Bluetooth low energy technology in a wireless communication system.
  • An object of the present invention is to provide a method and apparatus for providing information of transmitted data when HTTP data is transmitted using Bluetooth low energy technology in a wireless communication system.
  • a method comprising: receiving a first write request including information related to a Hyper Text Transfer Protocol (HTTP) request from a first client device; Transmitting the HTTP request related information generated based on the information included in the received first write request, to a web server; Receiving an HTTP response message in response to the HTTP request related information from the web server; Notifying the first client device of an HTTP status code indicating an status of data included in the received HTTP response message; And receiving a read request for requesting data transmission based on information included in the HTTP status code from the first client device, wherein the first write request is received.
  • HTTP Hyper Text Transfer Protocol
  • the error response indicates that the gateway is performing an operation for generating the HTTP request related information with the first client device, or the gateway generates the HTTP request related information. It is characterized by indicating that the resource is not sufficient because the operation to perform.
  • receiving the first write request may include receiving a Universal Resource Identifier (URI) write request from the first client device; Sending a URI write response to the first client device in response to the received URI write request; Receiving an HTTP Header write request from the first client device; Sending an HTTP header write response to the first client device in response to the received HTTP Header write request; Receiving an HTTP Entity Body write request from the first client device; Sending an HTTP Entity Body response to the first client device in response to the received HTTP Entity Body write request; Receiving an HTTP Control Point request indicative of a specific action associated with the HTTP request message from the first client device; And transmitting an HTTP Control Point response to the first client device in response to the received HTTP Control Point request.
  • URI Universal Resource Identifier
  • receiving the read request may include: receiving an HTTP header read request from the first client device; Transmitting an HTTP header read response to the first client device in response to an HTTP header read request; Receiving an HTTP Entity Body read request from the first client device; And transmitting an HTTP Entity Body read response to the first client device in response to an HTTP Entity Body read request.
  • the data may include at least one of a header or an entity body received from the web server.
  • HTTP Status Code is characterized in that it contains information related to the length of the data.
  • HTTP Status Code is characterized in that the notification (Notify) together with the information related to the data length.
  • the information related to the data length includes a value of 0 or 1, and when the information related to the data length is 0, it indicates that the data exists, and the information related to the data length is 1
  • the length of the data exceeds the maximum data transmission length, characterized in that transmitted by the maximum data transmission length.
  • the information related to the data length includes the data length, and if the length of the data is equal to or smaller than the ATT_MTU-2 value, the data is transmitted to the first client device through a read request procedure.
  • the ATT_MTU-2 value may indicate a maximum data length that can be transmitted at one time through a read request procedure.
  • the information related to the data length includes the data length, and if the length of the data exceeds the ATT_MTU-2 value and is equal to or smaller than the maximum ATT data length, read blob
  • the data is transmitted to the first client device through a request procedure, wherein the maximum ATT data length indicates a maximum size of data that can be transmitted through an attribute protocol.
  • the information related to the data length includes the data length, and if the length of the data exceeds the maximum ATT Data Length, L2CAP Logical Link Control and Adaptation Protocol Connection Oriented And transmitting the data to the first client device through a channel.
  • the present invention also includes receiving a request message requesting a client ID value from the first client device; Sending a response message in response to the request message; And when the client ID value is NULL, receiving a change request message requesting a change from the first client device to the first client device information.
  • the first client device information may include at least one of a user ID and an ID of the first client device.
  • the present invention may further include notifying the changed client ID to other client devices connected to the gateway.
  • the changed client ID is changed to NULL after a request from the first client or a specific time elapses.
  • the present invention includes the steps of receiving from the first client device a request message requesting a protected value indicating whether another client is in use; Sending a response message in response to the request message; And when the protected value is No, receiving a request message for requesting a change of the protected value from the first client device.
  • the present invention may further comprise notifying the changed protected value to other client devices connected to the gateway.
  • the changed protected value is changed to No after a request from the first client or a specific time elapses.
  • the present invention also provides a method comprising: transmitting a read request to the server to request information related to a first object; Receiving a read response including information related to the first object from the server in response to the read request; Sending a message to the server to change the first object to a second object; And receiving an error code related to a second object from the server, wherein the error code indicates that the resource of the server is not sufficient.
  • 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 receives a first write request including information related to a Hyper Text Transfer Protocol (HTTP) request from a first client device, and receives the received request.
  • HTTP Hyper Text Transfer Protocol
  • the HTTP request related information is generated based on the information included in the first write request, the HTTP request related information is transmitted to the web server, and an HTTP response message is received in response to the HTTP request related information from the web server.
  • Receive an HTTP status code indicating a status of data included in the received HTTP response message, and notify the first client device from the first client device to the HTTP status code.
  • HTTP data can be efficiently transmitted using Bluetooth low power energy technology.
  • an error message when there is a request for HTTP data transmission from another device during data transmission using Bluetooth low power energy technology, an error message may be improved by transmitting an error message.
  • 1 is a diagram illustrating an example of transmitting HTTP data using Bluetooth low energy.
  • FIG. 2 is a diagram illustrating an example of an internal block diagram of a server device and a client device to which the present invention is applied.
  • FIG. 3 is a diagram schematically showing a functional configuration of an internal configuration of a device to which the present invention is applied.
  • FIG. 4 is a diagram schematically illustrating a functional configuration for transmitting HTTP data using Bluetooth Low Energy, to which the present invention is applied.
  • FIG. 5 is a diagram illustrating an example of transmitting HTTP data using Bluetooth low energy.
  • 6 and 7 illustrate an example in which a plurality of client devices transmit a write request to the same gateway.
  • FIG. 8 is a diagram illustrating an example of transmitting an error response when a plurality of devices transmit a write request to which the present invention is applied.
  • FIG. 9 is a diagram illustrating an example of transmitting an error response according to a data length to which the present invention is applied.
  • FIG. 10 is a diagram illustrating an example of transmitting HTTP data using a currently used client ID to which the present invention is applied.
  • FIG. 11 is a diagram illustrating an example of transmitting a current client ID to a plurality of devices to which the present invention is applied.
  • FIG. 12 is a diagram illustrating an example of notifying that there is a device that is already transmitting HTTP data when the device transmits HTTP data to which the present invention is applied.
  • FIG. 13 is a diagram illustrating another example of notifying that a plurality of devices are already transmitting HTTP data to a plurality of devices to which the present invention is applied.
  • FIG. 14 is a diagram illustrating an example of enabling / disabling a security function to which the present invention is applied.
  • 15 is a diagram illustrating an example in which a transmission scheme is changed according to a data size to which the present invention is applied.
  • 16 is a diagram illustrating an example of a Bluetooth data transmission method to which the present invention is applied.
  • 17 and 18 are diagrams showing an example of a method of informing a data length in HTTP data transmission to which the present invention is applied.
  • 19 is a flowchart illustrating an example of transmitting an error code in an object transfer service to which the present invention is applied.
  • Electronic devices described herein may include a mobile phone, a smart phone, a laptop computer, a digital broadcasting terminal, a personal digital assistant (PDA), a portable multimedia player (PMP), navigation, and the like.
  • PDA personal digital assistant
  • PMP portable multimedia player
  • 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 frames as well as messages.
  • 1 is a diagram illustrating an example of transmitting HTTP data using Bluetooth low energy.
  • FIG. 1 an example is shown in which a device supporting Bluetooth is connected to the Internet web through a gateway supporting Bluetooth.
  • Bluetooth is one of the representative short-range wireless technologies that transmit and receive information by connecting various devices (smartphones, PCs, earphones, headphones) to each other.
  • Bluetooth Low Energy technology consumes less power and can reliably provide hundreds of kilobytes of information.
  • the Bluetooth low energy energy technology uses an attribute protocol to exchange information between devices.
  • This approach can reduce energy consumption by reducing the overhead of the header and simplifying the operation.
  • Bluetooth low energy energy technology can also connect to and send data from the Internet. This allows Bluetooth-enabled devices to access and provide information on the Internet web so users can access the information they need anywhere, anytime.
  • a gateway that can access Web services must connect the device to the Internet Web.
  • a client device 10 that supports Bluetooth low energy (hereinafter referred to as Bluetooth LE) and the gateway 20 are connected using Bluetooth.
  • Bluetooth LE Bluetooth low energy
  • the client device 100 may transmit data to the gateway 200.
  • the gateway 200 is connected to the web server 400 by using Wi-Fi, Long Term Evolution (LTE), or other technology, through which the data received from the client device 100 is web. You can send it to the server.
  • Wi-Fi Wireless Fidelity
  • LTE Long Term Evolution
  • the present invention provides a method and apparatus for efficiently transmitting HTTP data using Bluetooth.
  • FIG. 2 is a diagram illustrating an example of an internal block diagram of a server device and a client device to which the present invention is applied.
  • the gateway 200 may refer to any electronic device capable of directly communicating with the client device 100.
  • the gateway 200 may be referred to as a server device.
  • the client device 100 may refer to any electronic device capable of supporting a Bluetooth function.
  • the gateway 200 may directly communicate with the client device 100, receive data, and notify the client device 100 of a result of processing the received data.
  • the client device 100 may request data and transmit the requested data back to the client device 100.
  • a notification or indication message is sent to the client device 100. It may be sent, and may receive a confirmation message for this from the client device (100).
  • One server device may be connected to a plurality of client devices, and may be easily reconnected with the client devices by using bonding information.
  • the client device 100 and the gateway 200 may be a communication unit 110 and 210, a user input unit 220 and 120, an output unit 230 and 130, a control unit 140 and 240, and a memory 150 and 250, respectively. And power supplies 160 and 260.
  • the communication unit, user input unit, output unit, control unit, memory, and power supply unit are functionally connected to perform the method proposed by the present invention.
  • FIG. 2 The components illustrated in FIG. 2 are not essential, and thus an electronic device having more or fewer components may be implemented.
  • the communication unit 110 and 210 may include one or more modules that enable wireless communication between a device and a wireless communication system or between a device and a network in which the device is located.
  • the communication units 160 and 260 may include a broadcast receiving module (not shown), a mobile communication module (not shown), a wireless internet module (not shown), and a short range communication module (not shown).
  • the communication unit 110 and 210 may be referred to as a transmission / reception unit.
  • the mobile communication module transmits and receives a radio signal with at least one of a base station, an external terminal, and a server on a mobile communication network.
  • the wireless signal may include various types of data according to transmission and reception of a voice call signal, a video call call signal, or a text / multimedia message.
  • the wireless internet module refers to a module for wireless internet access, and the wireless internet module may be embedded or external to the device.
  • Wireless Internet technologies may include Wireless LAN (WiFi), Wireless Broadband (Wibro), World Interoperability for Microwave Access (Wimax), High Speed Downlink Packet Access (HSDPA), and the like.
  • the device may establish a Wi-Fi peer-to-peer connection with another device through the wireless internet module.
  • a Wi-Fi P2P connection may provide a streaming service between devices, and may provide a printing service by connecting to a data transmission / reception or a printer.
  • the gateway 200 may be connected to the client device 100 through a short range communication module, and may receive data and receive a data request from the client device 100 through this.
  • the gateway 200 may be connected to a web server through the wireless internet module to access the internet network, thereby transmitting data received from the client device 100 to the web server or the client device 100. Can receive the requested data.
  • the user input units 120 and 220 generate input data for controlling the operation of the user.
  • the user input units 120 and 220 may be configured of a key pad dome switch, a touch pad (static pressure / capacitance), a jog wheel, a jog switch, and the like.
  • the output units 130 and 230 are used to generate output related to visual, auditory or tactile senses, and may include display modules 132 and 232 and sound output modules 134 and 234.
  • the display modules 132 and 232 display and output information processed by the device. For example, when the device is in a call mode, the device displays a user interface (UI) or a graphic user interface (GUI) related to the call. When the device is in a video call mode or a photographing mode, a photographed and / or received image, a UI, or a GUI is displayed.
  • UI user interface
  • GUI graphic user interface
  • the display modules 132 and 232 may include a liquid crystal display, a thin film transistor liquid crystal display, an organic light emitting diode, a flexible display, and a 3D display (3D). display).
  • the sound output modules 134 and 234 may output audio data received from the communication unit 110 and 210 or stored in the memory 150 and 250 in a call signal reception, a call mode or a recording mode, a voice recognition mode, and a broadcast reception mode.
  • the sound output modules 134 and 234 output sound signals related to functions (eg, call signal reception sound, message reception sound, etc.) performed in the device.
  • the sound output modules 134 and 234 may include a receiver, a speaker, a buzzer, and the like.
  • the controllers 140 and 240 refer to a module that controls the overall operation of the client device 100 or the gateway 200, and processes a request for transmission of a message and a received message through a Bluetooth interface and another communication interface. Can be controlled.
  • the controllers 140 and 240 may be referred to as a controller, a microcontroller, a microprocessor, and the like.
  • the controllers 140 and 240 may include hardware, firmware, It may be implemented by software, or a combination thereof.
  • the controllers 140 and 240 may include an application-specific integrated circuit (ASIC), another chipset, a logic circuit, and / or a data processing device.
  • ASIC application-specific integrated circuit
  • the memory 150, 250 is a medium for storing various types of information of a terminal.
  • the memory 150, 250 is connected to the controller to store programs, applications, general files, and input / output data for the operation of the controller 160, 260. Can be stored.
  • the memories 130 and 230 may be a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (eg, SD or XD memory, etc.). ), Random Access Memory (RAM), Static Random Access Memory (SRAM), ReadOnly Memory (ROM), Electrically Erasable Programmable ReadOnly Memory (EEPROM), Programmable ReadOnly Memory (PROM), Magnetic Disk, Optical Disk It may include at least one type of storage medium.
  • the device may operate in association with a web storage that performs a storage function of the memories 130 and 230 on the Internet.
  • the power supply units 160 and 260 refer to a module for supplying power required for the operation of each component by receiving external power and internal power under the control of the controllers 140 and 240.
  • Bluetooth LE technology which is applied in the present invention, has a small duty cycle and can greatly reduce power consumption through a low data rate, so that the power supply units 160 and 260 can each have a low output power (100 mW (10 dBm or less). It can supply power for the operation of the components.
  • FIG. 3 is a diagram schematically showing a functional configuration of an internal configuration of a device to which the present invention is applied.
  • the client device and the server device are each composed of a host 320 and a controller 310, and the controller 310 is composed of a physical layer PHY 312 and a link layer layer LL 314.
  • the host 320 is, again, Logical Link Control and Adaptation Protocol (L2CAP, 331), Security Manager (Security Manager, SM, 332), Attribute Protocol (ATT, 333), It consists of a Generic Attribute Profile (GATT, 334), a Generic Access Profile (GAP, 335), and a GATT based profile (336).
  • L2CAP Logical Link Control and Adaptation Protocol
  • SM Security Manager
  • ATT Attribute Protocol
  • GATT Generic Attribute Profile
  • GAP Generic Access Profile
  • GATT Generic Access Profile
  • the controller 310 and the host 320 are connected to a host controller interface (HCI) 316.
  • HCI host controller interface
  • the host 320 may provide a command and data to the controller 310 through the HCI 316, and the controller may provide an event and data to the host through the HCI 316. May be provided to 320.
  • the controller 310 refers to a wireless transceiver module for receiving a Bluetooth signal and hardware for transmitting or receiving a Bluetooth packet.
  • the PHY layer 312 is a layer for transmitting / receiving a radio signal using a Gaussian Frequency Shift Keying (GFSK) modulation and a frequency hopping scheme composed of 40 RF channels.
  • GFSK Gaussian Frequency Shift Keying
  • the link layer layer 314 performs an advertising and scanning function using three advertising channels to create a connection between devices, and generates a data packet through 37 data channels. It can provide the function of sending and receiving.
  • the host 320 may multiplex various protocols, profiles, etc. provided by a higher level of Bluetooth using the logical link control and adaptation protocol (hereinafter referred to as L2CAP, 311). .
  • L2CAP logical link control and adaptation protocol
  • the L2CAP 331 may provide one bidirectional channel for transmitting data to a specific protocol or profile, and uses three fixed channels in Bluetooth low power energy.
  • the fixed channel may be used for the signaling channel, the security manager 332 and the attribute protocol (hereinafter referred to as ATT, 333), respectively.
  • the Bluetooth Basic Rate / Enhanced Data Rate uses a dynamic channel and can support protocol service multiplexers, retransmissions, and streaming modes.
  • the security manager (hereinafter referred to as SM, 332) is a protocol for providing device authentication and key distribution.
  • the ATT 333 is used for communication between the server and the client, and has an attribute handle used by the client to access attributes in the server.
  • Protocol operation commands include 'Request', 'Response', 'Command', 'Notification', 'Indication', and 'Confirmation'.
  • the Request message is a message for requesting specific information from the client device to the server device
  • the Response message is a response message to the response message, which is a message transmitted to 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 A message sent to a server device for notification, such as an event, to a client device.
  • the client device does not transmit a confirmation message for a notification message to the server device.
  • the client device transmits a confirmation message for the Indication message to the server device from the server device to the client device.
  • GATT 334 The general attribute profile (hereinafter referred to as GATT 334) is a newly implemented layer for Bluetooth LE technology, and defines a procedure for obtaining corresponding information with a message defined in the S / W component of the Bluetooth device below and the ATT protocol. . This procedure can define the settings of the discovering, reading, writing, notify, and indicating properties.
  • UUID Universally Unique Identifier
  • the general access profile (hereinafter, referred to as a GAP) 335 may define a method of discovering, connecting to a defined device, and providing information to a user, and may provide privacy.
  • the GATT based profile 336 is mainly applied to low energy devices with profiles that depend on the GATT 334.
  • the GATT-based profile 366 includes a profile related to battery, time, proximity, phone alert, heart rate, and HTTP proxy service (337). This may be included.
  • the HTTP proxy service 337 may perform a function of requesting HTTP message delivery using a GATT (Generic Attribute Profile) function of Bluetooth.
  • the client device 100 and the host device 200 may transmit an HTTP message transfer request and data transmitted from a web server to the client device 100 using the HTTP proxy service 337.
  • GATT Generic Attribute Profile
  • FIG. 4 is a diagram schematically illustrating a functional configuration for transmitting HTTP data using Bluetooth Low Energy, to which the present invention is applied.
  • the gateway 200 receiving data from the client device 100 through Bluetooth may transmit it to the internet web server 400.
  • the client device 100 includes an HTTP proxy client 12.
  • the client device 100 and the gateway 200 may support Bluetooth low energy technology.
  • the HTTP proxy client 12 functions to use the HTTP proxy server 22 of the gateway 200 because the client device 100 cannot access a web server through the Internet using Bluetooth technology. Can provide.
  • the client device 100 may be connected to the gateway 200 through the HTTP proxy client 12, and may transmit a data request message or data to the gateway 200 through the HTTP proxy client 12.
  • the gateway 200 includes an HTTP proxy server 22 and an HTTP client 24.
  • the HTTP proxy server 22 provides an HTTP proxy service function for providing connectivity between the client device 100 and the HTTP server 400.
  • the HTTP client 24 functions as a client to send and receive an HTTP request to an HTTP server in order to provide an HTTP proxy function of the client device 100, and generates an HTTP message with data of an HTTP proxy service. Communicate with an HTTP server.
  • the gateway 200 may receive a message or data to be transmitted from the client device 100 to the web server through the HTTP proxy server 22, and generate an HTTP message through the received data.
  • the gateway 200 may transmit the generated HTTP message to the HTTP server 400 through wireless communication through the HTTP client 24.
  • the wireless communication refers to a communication means capable of connecting with an internet server as wireless communication excluding Bluetooth.
  • wireless communication excluding Bluetooth.
  • the HTTP server refers to a server using the HTTP protocol to provide a web (web) service.
  • the gateway may receive data requested by the client device 100 from the HTTP server 400 through the HTTP client 24.
  • the received data is converted into a form that can be transmitted via Bluetooth again, and then transmitted to the HTTP proxy client 12 of the client device 100 through the HTTP proxy server 220.
  • Characteristic of HTTP proxy service contains information for providing HTTP proxy service.
  • the URI Characteristic is used to construct a URI for subsequent requests.
  • the URI characteristic includes a URI used for an HTTP request and can be used up to a defined maximum length. For example, the maximum length of an HTTP request that contains a current URI is 512 octets.
  • the HTTP Header Characteristic is used to include a header included in a write request or a read request.
  • the HTTP Header Characteristic may be used up to a defined maximum length.
  • the maximum length of the current HTTP Header Characteristic is 512 octec.
  • the HTTP Entity Body includes a body of a message to be transmitted.
  • the HTTP L2CAP Protocol Service Multiplexer represents an identifier indicating which protocol or service the data information is for.
  • the gateway may inform or notify the client device of the changed value.
  • the HTTP Status Code Characteristic may include information representing the status of the received data.
  • the state of the received data refers to the state of data included in the HTTP header and / or HTTP entity body received by the gateway 200 from the web server 400.
  • the HTTP control point serves to instruct the HTTP proxy service to perform a specific operation.
  • Table 2 below shows the commands that can be included in the HTTP control point.
  • the HTTPS Security includes information indicating whether to use a function related to security. If the HTTPS Security function is Yes, the security function may be used by using HTTPS, and when No, the security function may not be used by using HTTP.
  • the HTTP security characteristic may be expressed as a Boolean.
  • FIG. 5 is a diagram illustrating an example of transmitting HTTP data using Bluetooth low energy.
  • the client device 1 100 may transmit information for generating an HTTP request message to the gateway 200 through a write request.
  • the write request may include one characteristic.
  • the client device 1 (100) transmits a Universal Resource Identifier (URI) through a write request (S510).
  • the client device 100 then transmits an HTTP header through a write request (S512), and sequentially through an write request, an HTTP entity body and an HTTP control.
  • a point (HTTP control point) is transmitted (S514 and S516).
  • the gateway 200 may transmit a response message for each write request to the client device 1 (100).
  • the client responds to the write request including the URI, the response to the write request including the HTTP header, the response to the write request including the HTTP entity body, and the response to the write request including the HTTP control point. It may transmit to the device 1 (100).
  • the gateway 200 may generate an HTTP request message based on the information received from the client device 1 100 and transmit the generated HTTP request message to the web server 400 (S518).
  • the HTTP request message may include information related to the HTTP request, that is, information (URI, HTTP header, HTTP entity body) transmitted from the client device 1 (100).
  • information URI, HTTP header, HTTP entity body
  • the client device 1 100 transmits information related to the HTTP request to the gateway 200, and the gateway 200 transmits the information related to the HTTP request in the form of a message or frame to the web server 400. ) Can be sent.
  • the web server 400 transmits an HTTP response message including the requested data and an HTTP status code to the gateway in step S520.
  • the HTTP status code is a code indicating the status of the requested data.
  • the gateway 200 receiving the HTTP response message may convert the information into a form that can be transmitted through Bluetooth.
  • the gateway After receiving the HTTP response message from the web server 400, the gateway transmits an indication message including a status code to the client device 100 (S522). Through this, the client device can know whether the gateway 200 correctly received the requested data, did not receive it, or received it incompletely.
  • the client device 100 may request information received from the web server 400 by the gateway to the gateway 200 through a read request.
  • the client device 100 may receive a URI by transmitting a read request to the gateway 200 (S524), and may receive an HTTP header through the read request (S526). Thereafter, the client device 100 may transmit a read request to the gateway 200 to receive the HTTP entity body and receive the HTTP entity body from the gateway 200 (S528).
  • the client device 1 100 may transmit and receive data from the web server 400.
  • the gateway 200 may be connected to a plurality of client devices at the same time, and in this case, a smooth service may not be provided because it cannot distinguish which device uses the corresponding service.
  • 6 and 7 illustrate an example in which a plurality of client devices transmit a write request to the same gateway.
  • steps S710 to S 718 of FIG. 7 are the same as steps S510 to S 518 of FIG. 5, description thereof will be omitted.
  • the devices 100, 120, and 140 supporting the Bluetooth function transmit a write request including the HTTP request related information to the gateway 200 for HTTP data transmission.
  • the gateway 200 may be connected to a client device to transmit an HTTP message including the HTTP request related information requested by the client device to the web server 300. However, while the client device 100 transmits a write request for generating an HTTP message to the gateway 200, the gateway 200 again transmits the HTTP message from another client device 120 or 140. When receiving a write request for generation, there is a problem in that it is impossible to maintain existing characteristics.
  • the client device 1 (100) when the client device 1 (100) receives a write request from the client device 2 (120) while transmitting information to the gateway 200 through a write request, the client device 1 (100) previously receives information.
  • the client device 1 100 may not maintain information on the characteristic transmitted to the gateway 200.
  • the client 1 may not receive the data requested by the client 1, and may not perform smooth data transmission.
  • FIG. 8 is a diagram illustrating an example of transmitting an error response when a plurality of devices transmit a write request to which the present invention is applied.
  • steps S810 to S816 of FIG. 8 are the same as steps S510 to S516 of FIG. 5, description thereof will be omitted.
  • the client device 1 (100) While the client device 1 (100) is transmitting data to the gateway 200 through a write request, the client device 2 (120) uses URI information through a write request to generate an HTTP request message. It may transmit (S818).
  • the gateway 200 cannot accept the write request of the client device 2 (200).
  • the gateway may reject the request of the client device 2 120 because there is a write request already in progress or the resource of the gateway is insufficient.
  • the gateway 200 since the gateway 200 cannot accept a write request from the client device 2 120, the gateway 200 transmits an error response to the client device 2 120 (S820).
  • Table 3 below shows error codes that may be included in an error response to a write request of a client device.
  • the gateway 200 may transmit 0x80 to an error response to the client 2 120, and the client 2 may stop a write request when the error response message is received.
  • the gateway 200 may transmit the HTTP request related information received from the client device 1 (100) to a web server, and as shown in step S518 You can receive an HTTP response containing HTTP data from a web server.
  • the HTTP response may include a status code indicating a status of the HTTP data.
  • steps S822 to S828 are the same as those of steps S522 to S528 of FIG. 5, description thereof will be omitted.
  • the error codes shown in Table 3 may be used in other services of Bluetooth in addition to the HTTP proxy service of the present invention, for example, in a Bluetooth Object Transfer Service, which will be described in detail with reference to FIG. 19. .
  • FIG. 9 is a diagram illustrating an example of transmitting an error response according to a data length to which the present invention is applied.
  • the gateway 200 transmits an error message to transmit data in another method.
  • steps S910 to S916 are the same as steps S510 to S516 of FIG. 5, description thereof will be omitted.
  • the gateway 200 may transmit the HTTP request related information received from the client device 1 (100) to the web server, and as shown in step S518.
  • An HTTP response including HTTP data may be received from the web server.
  • Steps S918 to S922 are the same as steps S522 to S526 of FIG. 5, and thus descriptions thereof will be omitted.
  • the HTTP response may include a status code indicating a status of the HTTP data.
  • the client device 1 transmits a read request to the gateway 200 to read an HTTP entity body from the gateway 200 (S924).
  • the gateway transmits an error response to the client device 1 (100) (S926).
  • the error response may include 0x81 code of Table 3.
  • the client device 1 may open the L2CAP Connection Oriented Channel (L2CAP Connection Oriented Channel) instead of the ATT protocol to receive the HTTP entity body (S928).
  • L2CAP Connection Oriented Channel L2CAP Connection Oriented Channel
  • FIG. 10 is a diagram illustrating an example of transmitting HTTP data using a currently used client ID to which the present invention is applied.
  • the Client ID Characteristic includes an ID of a Client to use the HTTP proxy function. If the Client ID value is null, the HTTP proxy service (HPS) may be used. However, if the client ID value is null, the HTTP proxy service (HPS) cannot be requested.
  • the Client ID may identify a user or a device by using a user ID or a device ID, and may distinguish a service inside a user or a device by adding a service UUID.
  • the Protected Characteristic may set the corresponding function to yes when a request is made from a client device, and if set to yes, other clients cannot send the request.
  • a client device may read a client ID value from a gateway, and if the client ID value is an ID value of another client device, the client device may not use the HTTP proxy service.
  • the client device 1 (100) transmits a read request (Client Request) of the client ID to the gateway 200 (S1010).
  • the gateway 200 may transmit information of the client device to the client device 1 (100).
  • the gateway 200 transmits a read response including a NULL value to the client device 1 100 (S1012).
  • the client device 1 (100) confirming that there is no client device using the HTTP proxy service through the write request to the gateway 200, the information of the client device 1 (100) to the client ID value In operation S1014, a request may be made to write.
  • the gateway 200 receiving the request may input the information of the client device 1 (100) into the client ID, and may transmit a response message to the request to the client device 1 (100).
  • steps S1016 to 1022 are the same as steps S510 to S516 of FIG. 5, description thereof will be omitted.
  • the client device 2 120 may request a client ID value through a read request in order to use the HTTP proxy service (S1024).
  • the gateway 200 may provide information about the client device 1 (100), for example, a user ID or a device ID, to the client ID value. Can be transmitted.
  • the client device 1 100 may use the HTTP proxy service.
  • the client device 2 120 suspends the HTTP proxy service request until the client ID value becomes NULL.
  • the gateway 200 may transmit the HTTP request related information received from the client device 1 (100) to the web server, and as shown in step S518.
  • An HTTP response including HTTP data may be received from the web server.
  • the HTTP response may include a status code indicating a status of the HTTP data.
  • steps S1028 to S1034 are the same as those of steps S522 to S528 of FIG. 5, description thereof is omitted.
  • Proxy services can be provided.
  • FIG. 11 is a diagram illustrating an example of transmitting a current client ID to a plurality of devices to which the present invention is applied.
  • the HTTP proxy service connection can be smoothly performed by notifying the clients connected to the gateway 200.
  • the client device 1 (100) may request to input the information of the client device 1 (100) to the client ID value through a write request. (S1110).
  • the gateway 200 may input information of the client device 1 100, for example, a user ID or a device ID of the client device 1 100, in response to the client ID value. May be transmitted to the client device 1 (100).
  • the gateway 200 may notify devices connected to the gateway 200 through a notification or an indication that the client ID value has been changed (S1112).
  • the devices receiving the indication transmit a confirmation message to the gateway 200.
  • step S1114 to step S1120 are the same as step S510 to step S516 of FIG. 5, description thereof is omitted.
  • the gateway 200 may transmit the HTTP request related information received from the client device 1 (100) to the web server, and as shown in step S518.
  • An HTTP response including HTTP data may be received from the web server.
  • the HTTP response may include a status code indicating a status of the HTTP data.
  • steps S1122 to S1228 are the same as steps S522 to S528 of FIG. 5, description thereof is omitted.
  • the gateway 200 Since the client device 1 (100), which has received all the requested data from the gateway 200, has ended the use of the HTTP proxy service, the gateway 200 to change the client ID value back to NULL through a write request. Can request (S1130).
  • the gateway 200 may change the value of the client ID to NULL according to the request of the client device 1 100, and may notify or indicate the changed value to the connected devices.
  • the connected devices may transmit a confirmation message to the gateway 200.
  • the request of the HTTP proxy service may come from a plurality of client devices, but if the request comes in at the same time, the data is damaged and the request must be transmitted again.
  • a client device can know whether the HTTP proxy service is used, and even when the use is terminated, it can be known whether or not the HTTP proxy service is available through a notification or an instruction.
  • FIG. 12 is a diagram illustrating an example of notifying that there is a device that is already transmitting HTTP data when the device transmits HTTP data to which the present invention is applied.
  • the client device when the client device is using the HTTP proxy service, the client device may be notified to another client device, thereby preventing a request for using the HTTP proxy service of the other client device.
  • the client device 100 may request a protected value through the read request from the gateway 200 (S1210).
  • the gateway 200 may include a Yes value when providing an HTTP proxy service to another client device and a No value when not providing the HTTP proxy service in the read response.
  • the client device cannot use the HTTP proxy service because another client device is using the HTTP proxy service.
  • the client device 1 may use the HTTP proxy service.
  • steps S1214 to S1220 are the same as steps S510 to S516 of FIG. 5, description thereof will be omitted.
  • the protected value may be changed to Yes.
  • the client device 2 120 may request a protection value from the gateway 200 through a read request in order to use the HTTP proxy service (S1222).
  • the gateway transmits a Yes value as the protected value to the client device 2 (120) (S1224).
  • the client device 2 120 that receives the Yes value as the protection value from the gateway 200 may know that the HTTP proxy service is in use.
  • the client device 2 (120) that finds out that the HTTP proxy service is not available cannot request the gateway 200 to use the HTTP proxy service.
  • the gateway 200 may transmit the HTTP request related information received from the client device 1 (100) to a web server.
  • the web server may receive an HTTP response including HTTP data.
  • the HTTP response may include a status code indicating a status of the HTTP data.
  • steps S1226 to S1232 are the same as those of steps S522 to S528 of FIG. 5, description thereof will be omitted.
  • the protected value may be changed to No when the gateway 200 does not operate with the client device 1 100 for a predetermined time, and the client device 1 100 may request to write the protected value. Can be changed to No.
  • FIG. 13 is a diagram illustrating another example of notifying that a plurality of devices are already transmitting HTTP data to a plurality of devices to which the present invention is applied.
  • the client device 1 may request the gateway 200 to change the protected value to Yes through a write request (S1310).
  • the gateway 200 receiving the write request may change the protected value to Yes and transmit a response message to the write request to the client device 1 (100).
  • the gateway 200 may notify the other connected client device, for example, the client device 2 120, through the notification or the indication of the changed protected value (S1312).
  • a confirmation message may be transmitted to the gateway 200.
  • step S1314 to step S1320 are the same as step S510 to step S516 of FIG. 5, description thereof will be omitted.
  • the gateway 200 may transmit the HTTP request related information received from the client device 1 (100) to a web server. You can receive an HTTP response containing HTTP data from a web server.
  • the HTTP response may include a status code indicating a status of the HTTP data.
  • step S1322 to step 1328 are the same as step S522 to step S528 of FIG. 5, description thereof will be omitted.
  • the client device 100 When the client device 1 (100) receiving the requested data from the gateway 200 no longer uses the HTTP proxy service, the client device 100 changes the protected value to No through a write request. In operation S1330, the user may request 200.
  • the gateway 200 that has been requested to change the protected value may change the protected value to No, and then transmit a response to the client device 1 (100).
  • the protected value may be changed when there is no operation of the client device 1 100 for a predetermined time in addition to the request of the client device 1 100.
  • the gateway 200 may notify other connected client devices through notification or indication (S1332).
  • a request of an HTTP proxy service may be received from a plurality of client devices, but if a request is received at the same time, data may be damaged and the request must be transmitted again.
  • FIG. 14 is a diagram illustrating an example of enabling / disabling a security function to which the present invention is applied.
  • a request for changing an HTTPS security characteristic value may be directly requested by a client device through a write request.
  • Table 5 below shows another example of the characteristic of the HTTP proxy service different from the above [Table 1].
  • [Table 5] shows that [Table 1] and HTTPS Security can be used as well as Read.
  • This not only can inform the gateway that the HTTPS Security value has changed, but also indicates that a client device can directly request the gateway to change the HTTPS Security value.
  • the client device 1 may request the gateway 100 to change the HTTPS security value to Yes through a write request (S1410).
  • the gateway 200 receiving the write request may change the HTTPS security value to Yes, and then transmit a response message to the client device 1 (100).
  • steps S1412 to S1416 are the same as those of steps S510 to S514 of FIG. 5, description thereof will be omitted.
  • the client device 1 (100) may request transmission of an HTTPS PUT Request message to the gateway 200 through an HTTP control point characteristic (S1418), and the gateway 200 sends a response to the client device 1 (100). ) Can be sent.
  • the gateway 200 may transmit an HTTPS PUT request message to the web server 400 (S1420).
  • the HTTPS PUT request message may include information related to an HTTP request, that is, information (URI, HTTP header, HTTP entity body) received from the client device 1 (100).
  • the web server 400 may receive an HTTPS PUT response in response to the HTTPS PUT request message (S1422).
  • the HTTPS PUT response message may include HTTP data requested by the client device 1 (100) and / or a status code indicating a status of the HTTP data.
  • the client device 1 100 may change the value of the HTTPS security characteristic to No.
  • the client device 1 may request the gateway 200 to change the value of the HTTPS security characteristic to No through a write request (S1424).
  • the gateway 200 receiving the write request may transmit a response message to the client device 1 (100).
  • steps S1426 to S1430 are the same as steps S510 to S514 of FIG. 5, description thereof will be omitted.
  • the client device 1 (100) may request the transmission of the HTTP PUT Request to the gateway 200 through the HTTP control point characteristic (S1432), and the gateway 200 sends a response to the client device 1 ( 100).
  • the gateway 200 may transmit an HTTP PUT request message to the web server 400 (S1434).
  • the HTTPS PUT request message may include information related to an HTTP request, that is, information (URI, HTTP header, HTTP entity body) received from the client device 1 (100).
  • the web server 400 may receive an HTTP PUT response message in response to the HTTP PUT request message (S1436).
  • the HTTP PUT response message may include a HTTP code requested by the client device 1 (100) and / or a status code indicating a status of the HTTP data.
  • the client device as well as the gateway 200 may directly request to change the HTTP security characteristic value.
  • Table 6 below shows another example of the characteristic of the HTTP proxy service.
  • Body Length Characteristic of Table 6 may include information related to the length of the HTTP Entity Body or HTTP Header. This informs the gateway of data length information to be written by the client device through a write request, or data length information that the client device reads from the gateway through a read request. It can be seen.
  • the gateway may inform the client device using the HTTP proxy service through a notification or an indication.
  • the client device may know that there is no data to be read from the gateway when the data length characteristic value is 0 or empty. If the data length characteristic value is other than 0, the data to be read is an HTTP header or an HTTP entity. You can see it is in the Body.
  • the data length is less than the length of the data requested by the client to the gateway through a write request
  • the data length is known through a read request, notification, or indication. We can see that only part of the data received from the web server was sent.
  • 15 is a diagram illustrating an example in which a transmission scheme is changed according to a data size to which the present invention is applied.
  • the client device may be provided with data length information to be transmitted from the gateway, and may change the transmission scheme according to the data length information.
  • the client device may obtain information related to the data length to be transmitted from the gateway through a read request, notification, or indication (S1510).
  • the client device may know the data length (or size) to be transmitted from the gateway through the obtained data length information.
  • the client device may know whether the data length is 0 through the data length information (S1512). If the data length is 0, the client device may know that there is no data to be transmitted from the gateway (S1514). . That is, it can be seen that there is no data to be transmitted because the gateway does not receive data from the web server.
  • the client device may compare the obtained data length with an ATT_MTU-2 value (S1516).
  • the ATT_MTU-2 value represents a maximum data length that can be received at one time through a read request sub procedure.
  • the client device may receive data through a read request sub procedure (S1520).
  • the client device may again compare the maximum ATT data length with the data length (S1522).
  • the read blob request refers to a method of dividing and transmitting data when all data cannot be transmitted at once. This will be described with reference to FIG. 16.
  • the client device may receive the data through an L2CAP channel. It may be (S1526).
  • the length of the data to be transmitted for example, the length of the HTTP header or the HTTP entity body, is informed through a read request, notification, or indication. You can receive data.
  • 16 is a diagram illustrating an example of a Bluetooth data transmission method to which the present invention is applied.
  • the client device 1 may request data transmission from the gateway 200 through a read request (S1610).
  • the gateway 200 receiving the read request may transmit data requested by the client through a read response (S1612).
  • the gateway 200 may divide and transmit data.
  • Bluetooth HTTP data transmission method For example, suppose the data to be transmitted is “Bluetooth HTTP data transmission method” and the length that can be transmitted at one time is “Bluetooth HTTP”.
  • the client device 1 100 may receive data called “Bluetooth HTTP” through a read response (S1612).
  • the client device 1 transmits a read blob request to the gateway 200 (S1614).
  • the gateway Upon receiving the read blob request, the gateway transmits “data transmission”, which is next to the transmitted data, to the client device 1 100 through a read response (S1616).
  • the client device 1 (100) transmits a read blob request to the gateway 200 again, and the gateway 200 determines the remaining data portion. ”Is transmitted to the client device 1 (100) through a read response.
  • the client device 1 (100) may be transmitted from the gateway (200).
  • 17 and 18 are diagrams showing an example of a method of informing a data length in HTTP data transmission to which the present invention is applied.
  • the client device may know the transmitted entity body length through a read request.
  • Steps S1710 to S1720 are the same as those of steps S1412 to S1422 of FIG. 14, and thus descriptions thereof will be omitted.
  • the gateway 200 transmits an indication message including a status code to the client device 1 (100) (S1722). Through this, the client device can know whether the gateway 200 correctly received the requested data, did not receive it, or received it incompletely.
  • the client device 1 100 may transmit a confirmation message to the gateway 200 in response to the indication message.
  • the client device 100 may request information received from the web server 400 by the gateway to the gateway 200 through a read request.
  • the client device 100 may receive a URI by transmitting a read request to the gateway 200 (S1724) and may receive an HTTP header through the read request (S1726).
  • the client may request the gateway 200 to read the length information of the HTTP entity body to be transmitted through a read request (S1728).
  • the client device 1 may receive the HTTP entity body using one of a Read Request Sub Procedure, Read Blob Request, or L2CAP channel, which is the method illustrated in FIG. 15, according to the received length information of the HTTP entity body. There is (S1730).
  • the gateway 200 may include a data length value in a status code to notify or indicate.
  • Steps S1810 to S1820 are the same as those of step S1710 to step S1720 of FIG. 17, and thus description thereof is omitted.
  • the gateway 200 receives the data from the web server 400 and informs the client device 1 (100) of the status code and the length information of the received data through an indication or notification. It may be (S1822).
  • the status code may indicate whether the gateway 200 has received data from the web server 400, and the data length information indicates the length (or size) of data received from the web server 400. Can be represented.
  • the data length information may be transmitted to the client device 1 100 through the indication or the notification as the status code.
  • the information may be included in the status code and transmitted to the client device 1 100 through the indication or the notification.
  • the gateway 200 transmits the indication message to the client device 1 100, the client device 1 100 sends a confirmation message in response thereto. It may transmit to the gateway 200.
  • Table 7 below shows an example of the HTTP Status code.
  • the client device 1 (100) obtains data received through the data length information included in or transmitted with the HTTP status code, that is, information about the length of data included in an HTTP header or an HTTP entity body. can do.
  • the client device 1 100 may recognize that there is no data to be read from the gateway 200 when the value for the length is 0 or empty, and the value for the length is other than 0. If you indicate a value, you can see that the data to be read is in the HTTP header or HTTP Entity Body.
  • the data length information may have a value of 1 or 0, and when the data length information is 0, it may indicate that no data exists because the data is not received from the web server 400. When the data length information is 1, it may indicate that data has been received from the web server 400.
  • the size of the data length information may have a size of one octet and may indicate a data state transmitted according to a bit operation of the octet value.
  • the first bit is 1, it can indicate that data exists in the header. If the second bit is 1, it indicates that the data in the transmitted header exceeds the maximum transmission size (for example, 512 bytes). Can be.
  • the maximum transmission size for example, 512 bytes.
  • the third bit is 1, it may indicate that data exists in the transmitted body. If the fourth bit is 1, the data of the transmitted body indicates the maximum transmission size (for example, 512 bytes). It may indicate the excess.
  • step S1726 to step S1730 of FIG. 17, description thereof will be omitted.
  • 19 is a flowchart illustrating an example of transmitting an error code when an error occurs during service provision to which the present invention is applied.
  • the server may inform the client of the Bluetooth object transfer service.
  • the object transfer service may be referred to as an object delivery service.
  • the server 1900 may inform the client 1910 that an object delivery service may be provided through an advertising channel (S1912).
  • a physical channel for transmitting information is divided into an advertising channel and a data channel, and the advertising channel is divided into three channels. In the channel, there may be 37 channels in the data channel.
  • the advertising channel may provide information for pairing to surrounding clients.
  • the server 1900 may inform the surrounding clients that the server 1900 can provide an object delivery service through the advertising channel ( S1912).
  • the client 1910 when the client 1910 is a device to receive the object delivery service, the client 1910 transmits a connection request for pairing to the server 1900 (S1914).
  • the client 1910 reads information on an object name through a read request in order to receive current object information provided by the object delivery service.
  • the server may request it (S1916).
  • the server 1900 may transmit a name of an object currently provided by the object delivery service to the client through a read response (S1918). .
  • the client 1910 having received the object name transmits an object list control point for changing an object to the server 1900 to obtain information on a next object, and transmits the current object to the next object.
  • the change may be requested (S1920).
  • the server 1900 may be notified by transmitting an error code to the client 1910 (S1924).
  • the server 1900 may not generate information on a new object due to a lack of resources of the server 1900, for example, a CPU power, a memory resource, or the like. have.
  • the error codes of Table 8 may be transmitted.
  • the server 1900 may inform the client 1910 why the error occurred.
  • the present specification provides a method and apparatus for transmitting and receiving data using a wireless communication system.
  • the present invention provides a method and apparatus for transmitting and receiving HTTP data with a web server through Bluetooth, which is a short range wireless communication technology.

Landscapes

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

Abstract

본 발명은, 무선 통신시스템에서 블루투스(Bluetooth) 통신을 이용하여 웹 서버와 데이터를 송수신하기 위한 것으로써, 제1 클라이언트 디바이스로부터 HTTP(Hyper Text Transfer Protocol) 요청 관련 정보를 포함하는 제1 쓰기 요청을 수신하는 단계; 상기 수신된 제1 쓰기 요청에 포함된 정보를 기초로 생성된 HTTP 요청 관련 정보를 웹 서버로 전송하는 단계; 상기 웹 서버로부터 상기 HTTP 요청 관련 정보에 대한 응답으로 HTTP 응답 메시지를 수신하는 단계; 상기 수신된 HTTP 응답 메시지에 포함된 데이터의 상태를 나타내는 HTTP 상태 코드를 상기 제1 클라이언트 디바이스에게 통지하는 단계; 및 상기 제1 클라이언트 디바이스로부터 상기 HTTP 상태 코드에 포함된 정보에 기초하여 데이터 전송을 요청하는 읽기 요청을 수신하는 단계를 포함하되, 상기 제1 쓰기 요청을 수신하는 중 다른 클라이언트 디바이스로부터 제2 쓰기 요청을 수신한 경우, 에러 응답를 전송하는 것을 특징으로 한다.

Description

무선 통신시스템에서 블루투스를 이용하여 HTTP 데이터를 전송하기 위한 방법 및 장치
본 발명은 데이터 전송 방법에 관한 것으로써, 특히 근거리 무선 통신 기술인 블루투스를 이용하여 HTTP 데이터를 전송하기 위한 방법 및 장치에 관한 것이다.
블루투스(Bluetooth)는 짧은 범위, 포인트 투 멀티포인트 음성 및 데이터의 전송을 위하여 제안된 무선 주파수(Radio Frequency, RF) 스펙이다.
블루투스는 고체, 비금속 물질을 관통하여 전송할 수 있다. 전송 범위는 10cm에서 10m이지만, 전송 전력을 증가시키면 100m까지 확장될 수 있다. 이는 저비용, 짧은 범위의 무선 링크에 기초하며, 고정 및 이동 통신 환경에서 애드 혹(ad hoc)접속을 용이하게 한다.
블루투스는 무선랜 규격인 802.11b/g와 동일한 ISM 대역인 2.45GHz 주파수를 사용하며, 블루투스 장치들은 주변의 블루투스 장치에 대한 검색/선택/인증(페어링) 등의 과정을 통해 무선 통신을 수행할 수 있다.
또한, 블루투스는 비교적 저전력, 저비용으로 비교적 빠른 속도를 낼 수 있으나, 전송 거리가 최대 100m로 한정적이므로, 한정된 공간에서 사용하기 적합하다.
블루투스는 2.0 버전에 이르러 EDR(Enhanced Data Rate) 규격이 추가되어 일정 수준의 통신 품질이 보장되면서부터 급속히 대중화되기 시작했는데, 블루투스의 사용이 보편화되면서 블루투스 기능이 포함된 휴대단말기의 사용도 보편화되고 있다. 특히, 블루투스를 이용한 근거리 데이터 통신이 보편화되고 있는데, 블루투스 헤드셋과의 블루투스 통신을 통해 무선으로 음악을 청취하는 것을 그 예로 들 수 있다.
또한, 블루투스를 이용하여 스마트폰-자동차 스피커 연동을 통한 음악 재생 또는 블루투스 docking speaker-스마트폰 연동을 통해 음악을 재생하는 등 그 사용 빈도가 많아지고 있다.
또한, WPAN(Wireless Personal Area Network)은 Home Network, Small Office, Vehicular Network 등의 환경에서 장치들 간 소량의 데이터를 전송할 수 있어 에너지 효율을 극대화할 수 있다.
또한, WPAN은 제한된 대역폭(Bandwidth) 내에서 헤드셋 등의 전자기기를 통해 실시간 A/V Streaming 서비스를 제공하고, 이에 종속된 Remote Control 기능을 수행할 때에도 에너지 효율을 극대화할 수 있어 널리 사용되고 있다.
본 발명은 무선 통신시스템에서 블루투스 저전력 에너지 기술(Bluetooth Low Energy)을 이용하여 HTTP 데이터를 원활하게 전송하기 위한 방법 및 장치를 제공함에 그 목적이 있다.
본 발명은 무선 통신 시스템에서 블루투스 저전력 에너지 기술(Bluetooth Low Energy)을 이용하여 HTTP 데이터를 전송하는 디바이스들을 구분하기 위한 방법 및 장치를 제공함에 그 목적이 있다.
본 발명은 무선 통신 시스템에서 블루투스 저전력 에너지 기술(Bluetooth Low Energy)을 이용하여 HTTP 데이터를 전송하는 경우 발생하는 오류를 해결하기 위한 방법 및 장치를 제공함에 그 목적이 있다.
본 발명은 무선 통신 시스템에서 블루투스 저전력 에너지 기술(Bluetooth Low Energy)을 이용하여 HTTP 데이터를 전송하는 경우 발생하는 오류를 해결하기 위한 에러 메시지를 전송하기 위한 방법 및 장치를 제공함에 그 목적이 있다.
본 발명은 무선 통신 시스템에서 블루투스 저전력 에너지 기술(Bluetooth Low Energy)을 이용하여 HTTP 데이터를 전송하는 경우, 데이터 전송 방법을 결정하기 위한 방법 및 장치를 제공함에 그 목적이 있다.
본 발명은 무선 통신 시스템에서 블루투스 저전력 에너지 기술(Bluetooth Low Energy)을 이용하여 HTTP 데이터를 전송하는 경우, 전송되는 데이터의 정보를 제공하기 위한 방법 및 장치를 제공함에 그 목적이 있다.
본 명세서에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
상기한 과제를 실현하기 위한 본 발명은, 제1 클라이언트 디바이스로부터 HTTP(Hyper Text Transfer Protocol) 요청 관련 정보를 포함하는 제1 쓰기 요청(write request)을 수신하는 단계; 상기 수신된 제1 쓰기 요청에 포함된 정보를 기초로 생성된 HTTP 요청 관련 정보를 웹 서버로 전송하는 단계; 상기 웹 서버로부터 상기 HTTP 요청 관련 정보에 대한 응답으로 HTTP 응답 메시지를 수신하는 단계; 상기 수신된 HTTP 응답 메시지에 포함된 데이터의 상태를 나타내는 HTTP 상태 코드(HTTP Status Code)를 상기 제1 클라이언트 디바이스에게 통지(Notifying)하는 단계; 및 상기 제1 클라이언트 디바이스로부터 상기 HTTP 상태 코드(HTTP Status Code)에 포함된 정보에 기초하여 데이터 전송을 요청하는 읽기 요청(read request)을 수신하는 단계를 포함하되, 상기 제1 쓰기 요청(write request)을 수신하는 중 다른 클라이언트 디바이스로부터 제2 쓰기 요청(write request)을 수신한 경우, 상기 다른 클라이언트 디바이스에게 에러 응답(error response)를 전송하는 것을 특징으로 하는 웹 서버와 데이터를 송수신하는 방법을 제공한다.
또한, 본 발명에서, 상기 에러 응답(error response)은 상기 게이트웨이가 상기 제1 클라이언트 디바이스와 상기 HTTP 요청 관련 정보 생성을 위한 동작을 수행하고 있음을 나타내거나, 상기 게이트웨이가 상기 HTTP 요청 관련 정보를 생성하기 위한 동작을 수행하고 있어 자원이 충분하지 못함을 나타내는 것을 특징으로 한다.
또한, 본 발명에서, 상기 제1 쓰기 요청(write request)을 수신하는 단계는, 상기 제1 클라이언트 디바이스로부터 URI(Universal Resource Identifier) 쓰기 요청을 수신하는 단계; 상기 제1 클라이언트 디바이스에게 상기 수신된 URI 쓰기 요청에 대한 응답으로 URI 쓰기 응답(write response)을 전송하는 단계; 상기 제1 클라이언트 디바이스로부터 HTTP 헤더 쓰기 요청(HTTP Header write request)을 수신하는 단계; 상기 제1 클라이언트 디바이스에게 상기 수신된 HTTP 헤더 쓰기 요청(HTTP Header write request)에 대한 응답으로 HTTP 헤더 쓰기 응답(HTTP Header write response)을 전송하는 단계; 상기 제1 클라이언트 디바이스로부터 HTTP 엔터티 바디 쓰기 요청(Entity Body write request)을 수신하는 단계; 상기 제1 클라이언트 디바이스에게 상기 수신된 HTTP 엔터티 바디 쓰기 요청(Entity Body write request)에 대한 응답으로 HTTP 엔터티 바디 쓰기 응답(HTTP Entity Body response)을 전송하는 단계; 상기 제1 클라이언트 디바이스로부터 상기 HTTP 요청 메시지(HTTP request message)와 관련된 특정 동작을 지시하는 HTTP 컨트롤 포인트 요청(HTTP Control Point request)을 수신하는 단계; 및 상기 제1 클라이언트 디바이스에게 상기 수신된 HTTP 컨트롤 포인트 요청(HTTP Control Point request)에 대한 응답으로 HTTP 컨트롤 포인트 응답(HTTP Control Point response)을 전송하는 단계를 더 포함하는 것을 특징으로 한다.
또한, 본 발명에서, 상기 읽기 요청(read request)을 수신하는 단계는, 상기 제1 클라이언트 디바이스로부터 HTTP 헤더 읽기 요청(Header read request)을 수신하는 단계; 상기 제1 클라이언트 디바이스에게 HTTP 헤더 읽기 요청(Header read request)에 대한 응답으로 HTTP 헤더 읽기 응답(HTTP Header read response)을 전송하는 단계; 상기 제1 클라이언트 디바이스로부터 HTTP 엔터티 바디 읽기 요청(HTTP Entity Body read request)을 수신하는 단계; 및 상기 제1 클라이언트 디바이스에게 HTTP 엔터티 바디 읽기 요청(HTTP Entity Body read request)에 대한 응답으로 HTTP 엔터티 바디 읽기 응답(HTTP Entity Body read response)을 전송하는 단계를 더 포함하는 것을 특징으로 한다.
또한, 본 발명에서, 상기 데이터는, 상기 웹 서버로부터 수신된, 헤더 또는 엔터티 바디 중 적어도 하나를 포함하는 것을 특징으로 한다.
또한, 본 발명에서, 상기 HTTP 상태 코드(HTTP Status Code)는, 데이터의 길이와 관련된 정보를 포함하는 것을 특징으로 한다.
또한, 본 발명에서, 상기 HTTP 상태 코드(HTTP Status Code)는, 데이터 길이와 관련된 정보와 함께 통지(Notify) 되는 것을 특징으로 한다.
또한, 본 발명에서, 상기 데이터 길이와 관련된 정보는, 0 또는 1의 값을 포함하며, 상기 데이터 길이와 관련된 정보가 0인 경우, 상기 데이터가 존재함을 나타내고, 상기 데이터 길이와 관련된 정보가 1인 경우, 상기 데이터의 길이가 최대 데이터 전송 길이를 초과하여 상기 최대 데이터 전송 길이만큼 전송되었음을 나타내는 것을 특징으로 한다.
또한, 본 발명에서, 상기 데이터 길이와 관련된 정보는 데이터 길이를 포함하며, 상기 데이터의 길이가 ATT_MTU-2 값과 동일하거나 작은 경우, read request 절차를 통해서 상기 데이터를 상기 제1 클라이언트 디바이스에게 전송하되, 상기 ATT_MTU-2 값은 read request 절차를 통해서 한번에 전송할 수 있는 최대 데이터의 길이를 나타내는 것을 특징으로 한다.
또한, 본 발명에서, 상기 데이터 길이와 관련된 정보는 데이터 길이를 포함하며, 상기 데이터의 길이가 ATT_MTU-2 값을 초과하고, 최대 ATT 데이터 길이(Max ATT Data Length)와 동일하거나 작은 경우, read blob request 절차를 통해서 상기 데이터를 상기 제1 클라이언트 디바이스에게 전송하되, 상기 최대 ATT 데이터 길이는 Attribute Protocol을 통해서 전송할 수 있는 데이터의 최대 크기를 나타내는 것을 특징으로 한다.
또한, 본 발명에서, 상기 데이터 길이와 관련된 정보는 데이터 길이를 포함하며, 상기 데이터의 길이가 최대 ATT 데이터 길이(Max ATT Data Length)를 초과하는 경우, L2CAP CoC(Logical Link Control and Adaptation Protocol Connection Oriented Channel)을 통해서 상기 데이터를 상기 제1 클라이언트 디바이스에게 전송하는 것을 특징으로 한다.
또한, 본 발명은, 상기 제1 클라이언트 디바이스로부터 클라이언트 ID 값을 요청하는 요청 메시지를 수신하는 단계; 상기 요청 메시지에 대한 응답으로 응답 메시지를 전송하는 단계; 및 상기 클라이언트 ID 값이 NULL인 경우, 상기 제1 클라이언트 디바이스로부터 상기 클라이언트 ID 값을 제1 클라이언트 디바이스 정보로 변경을 요청하는 변경 요청 메시지를 수신하는 단계를 더 포함하는 것을 특징으로 한다.
또한, 본 발명에서, 상기 제1 클라이언트 디바이스 정보는, 사용자 ID 또는 상기 제1 클라이언트 디바이스의 ID 중 적어도 어느 하나를 포함하는 것을 특징으로 한다.
또한, 본 발명은, 상기 변경된 클라이언트 ID를 상기 게이트웨이와 연결된 다른 클라이언트 디바이스들에게 통지(Notifying)하는 단계를 더 포함하는 것을 특징으로 한다.
또한, 본 발명에서, 상기 변경된 클라이언트 ID는, 상기 제1 클라이언트의 요청 또는 특정 시간이 경과된 후에 NULL로 변경되는 것을 특징으로 한다.
또한, 본 발명은, 상기 제1 클라이언트 디바이스로부터 다른 클라이언트의 사용여부를 나타내는 프로텍티드(Protected) 값을 요청하는 요청 메시지를 수신하는 단계; 상기 요청 메시지에 대한 응답으로 응답 메시지를 전송하는 단계; 및 상기 프로텍티드 값이 No인 경우, 상기 제1 클라이언트 디바이스로부터 상기 프로텍티드 값의 변경을 요청하는 요청 메시지를 수신하는 단계를 더 포함하는 것을 특징으로 한다.
또한, 본 발명은, 상기 변경된 프로텍티드 값을 상기 게이트웨이와 연결된 다른 클라이언트 디바이스들에게 통지(Notifying)하는 단계를 더 포함하는 것을 특징으로 한다.
또한, 본 발명에서, 상기 변경된 프로텍티드 값은, 상기 제1 클라이언트의 요청 또는 특정 시간이 경과된 후에 No로 변경되는 것을 특징으로 한다.
또한, 본 발명은, 상기 서버에게 제1 오브젝트와 관련된 정보를 요청하기 위해 읽기 요청(Read Request)을 전송하는 단계; 상기 서버로부터 상기 읽기 요청(Read Request)에 대한 응답으로 상기 제1 오브젝트(first Object)와 관련된 정보가 포함된 읽기 응답을 수신하는 단계; 상기 서버에게 상기 제 1오브젝트를 제 2오브젝트로 변경하기 위한 메시지를 전송하는 단계; 및 상기 서버로부터 제 2오브젝트와 관련된 에러 코드를 수신하는 단계를 포함하되, 상기 에러코드는 상기 서버의 자원이 충분하지 않은 것을 나타내는 것을 특징으로 하는 데이터 송수신 방법을 제공한다.
또한, 본 발명은, 외부와 유선 및/또는 무선으로 신호를 송수신하기 위한 통신부; 및 상기 통신부와 기능적으로 연결되는 제어부를 포함하되, 상기 제어부는, 제1 클라이언트 디바이스로부터 HTTP(Hyper Text Transfer Protocol) 요청 관련 정보를 포함하는 제1 쓰기 요청(write request)을 수신하고, 상기 수신된 제1 쓰기 요청에 포함된 정보를 기초로 상기 HTTP 요청 관련 정보를 생성하며, 상기 생성된 HTTP 요청 관련 정보를 웹 서버로 전송하고, 상기 웹 서버로부터 상기 HTTP 요청 관련 정보에 대한 응답으로 HTTP 응답 메시지를 수신하며, 상기 수신된 HTTP 응답 메시지에 포함된 데이터의 상태를 나타내는 HTTP 상태 코드(Status Code)를 상기 제1 클라이언트 디바이스에게 통지하고, 상기 제1 클라이언트 디바이스로부터 상기 HTTP 상태 코드(Status Code)에 포함된 정보에 기초하여 데이터 전송을 요청하는 읽기 요청(read request)을 수신하되, 상기 제1 쓰기 요청(write request)를 수신하는 중 다른 클라이언트 디바이스로부터 제2 쓰기 요청(write request)을 수신한 경우, 상기 다른 클라이언트 디바이스에게 에러 응답(error response)을 전송하는 것을 특징으로 하는 장치를 제공한다.
본 발명에 따른 블루투스 저전력 에너지 기술을 이용하여 HTTP 데이터를 전송하기 위한 방법 및 장치에 의하면 다음과 같은 효과가 있다.
본 발명에 의하면, 블루투스 저전력 에너지 기술을 이용하여 효율적으로 HTTP 데이터를 전송할 수 있다.
또한, 본 발명에 의하면, 블루투스 저전력 에너지 기술을 이용하여 데이터 전송 시, 다른 디바이스의 HTTP 데이터 전송요청이 있는 경우, 에러메시지를 전송하여 서비스 제공시 발생하는 오류를 개선할 수 있다.
또한, 본 발명에 의하면, 블루투스 저전력 에너지 기술을 이용하여 다수의 디바이스가 HTTP 데이터를 전송하고자 할 때, 이미 HTTP 데이터를 전송하고 있는 디바이스가 존재하는 경우 이를 알려주어 HTTP 데이터를 효율적으로 전송할 수 있다.
또한, 본 발명에 의하면, 블루투스 저전력 에너지 기술을 이용하여 HTTP 데이터 전송 시, 클라이언트 ID, 다른 클라이언트 사용 여부, 데이터 길이여부 등의 추가적인 메시지 타입을 정의함으로써, 사용자 편의성을 향상시키는 효과가 있다.
도 1은 블루투스 저전력 에너지(Bluetooth Low Energy)를 이용하여 HTTP 데이터를 전송하는 일 예를 나타낸 도이다.
도 2는 본 발명이 적용되는 서버 디바이스 및 클라이언트 디바이스의 내부 블록도의 일 예를 나타낸 도이다.
도 3은 본 발명이 적용되는, 디바이스의 내부 구성을 기능적인 구성을 개략적으로 도시한 도이다.
도 4는 본 발명이 적용되는, 블루투스 저전력 에너지(Bluetooth Low Energy)를 이용하여 HTTP 데이터를 전송하기 위한 기능적인 구성을 개략적으로 도시한 도이다.
도 5는 블루투스 저전력 에너지(Bluetooth Low Energy)를 이용하여 HTTP 데이터를 전송하는 일 예를 나타낸 도이다.
도 6 및 도 7은 다수의 클라이언트 디바이스가 동일한 게이트 웨이(Gateway)에게 쓰기 요청(write request)을 전송하는 일 예를 나타낸 도이다.
도 8은 본 발명이 적용되는, 다수의 디바이스가 쓰기 요청(write request)전송 시, 에러 응답을 전송하는 일 예를 나타낸 도이다.
도 9은 본 발명이 적용되는, 데이터 길이에 따른 에러응답 전송하는 일 예를 나타낸 도이다.
도 10는 본 발명이 적용되는, 현재 사용중인 클라이언트 ID를 이용하여 HTTP 데이터를 전송하는 일 예를 나타낸 도이다.
도 11은 본 발명이 적용되는, 현재 사용중인 클라이언트 ID를 다수의 디바이스에게 전송하는 일 예를 나타낸 도이다.
도 12은 본 발명이 적용되는, 디바이스가 HTTP 데이터를 전송하는 경우 이미 HTTP 데이터를 전송하고 있는 디바이스가 있음을 알려주는 일 예를 나타낸 도이다.
도 13는 본 발명이 적용되는, 다수의 디바이스에게 이미 HTTP 데이터를 전송하고 있는 디바이스가 있음을 통지하는 또 다른 일 예를 나타낸 도이다.
도 14은 본 발명이 적용되는, 보안 기능을 활성화/비활성화 시키는 일 예를 나타낸 도이다.
도 15는 본 발명이 적용되는, 데이터 크기에 따라서 전송 방식을 달리하는 일 예를 나타낸 도이다.
도 16는 본 발명이 적용되는, 블루투스 데이터 전송 방법의 일 예를 나타낸 도이다.
도 17 및 도 18은 본 발명이 적용되는, HTTP 데이터 전송 시, 데이터 길이를 알려주는 방법의 예를 나타낸 도이다.
도 19는 본 발명이 적용되는, 오브젝트 트랜스퍼 서비스(Object Transfer Service)에서 에러코드를 전송하는 일 예를 나타낸 흐름도이다.
본 발명의 상술한 목적, 특징들 및 장점은 첨부된 도면과 관련된 다음의 상세한 설명을 통해 보다 분명해질 것이다. 다만, 본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예들을 가질 수 있는 바, 이하에서는 특정 실시예들을 도면에 예시하고 이를 상세히 설명하고자 한다. 명세서 전체에 걸쳐서 동일한 참조번호들은 원칙적으로 동일한 구성요소들을 나타낸다. 또한, 본 발명과 관련된 공지 기능 혹은 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다.
이하, 본 발명과 관련된 방법 및 장치에 대하여 도면을 참조하여 보다 상세하게 설명한다. 이하의 설명에서 사용되는 구성요소에 대한 접미사 "모듈" 및 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다.
본 명세서에서 설명되는 전자기기에는 휴대폰, 스마트 폰(smart phone), 노트북 컴퓨터(laptop computer), 디지털방송용 단말기, PDA(Personal Digital Assistants), PMP(Portable Multimedia Player), 네비게이션 등이 포함될 수 있다. 그러나, 본 명세서에 기재된 실시예에 따른 구성은 이동 단말기에만 적용 가능한 경우를 제외하면, 디지털 TV, 데스크탑 컴퓨터 등과 같은 고정 단말기에도 적용될 수도 있음을 본 기술분야의 당업자라면 쉽게 알 수 있을 것이다.
본 명세서에서 설명되는 신호는 메시지형태뿐만 아니라 프레임 형태로도 전송될 수 있다.
도 1은 블루투스 저전력 에너지(Bluetooth Low Energy)를 이용하여 HTTP 데이터를 전송하는 일 예를 나타낸 도이다.
상기 도 1을 참조하면, 블루투스(Bluetooth)를 지원하는 장치가 블루투스(Bluetooth)를 지원하는 게이트웨이(Gateway)를 통하여 인터넷 웹에 연결되는 일 예시를 도시하고 있다.
블루투스(Bluetooth)는 다양한 기기(스마트 폰, PC, 이어폰, 헤드 폰)을 서로 연결하여 정보를 주고 받는 대표적인 근거리 무선 기술 중에 하나이다. 블루투스 저전력 에너지(Bluetooth Low energy)기술은 적은 전력을 소모하여 수백 키로바이트의 정보를 안정적으로 제공할 수 있다. 이러한 블루투스 저전력 에너지 기술은 속성 프로토콜(Attribute Protocol)을 활용해서 디바이스(Device) 간 정보를 교환하게 된다.
이러한 방식은 헤더의 오버헤드(overhead)를 줄이고 동작을 간단하게 해서 에너지 소비를 줄일 수 있다.
블루투스 저전력 에너지 기술을 활용하면 인터넷 웹과 연결하여 데이터를 주고 받을 수도 있다. 이는 블루투스를 활용하는 디바이스가 인터넷 웹상의 정보를 이용 및 제공하여 사용자가 언제 어디에서나 필요한 정보를 이용할 수 있게 해준다.
하지만, 이러한 기능을 활용하기 위해서는 웹 서비스에 접속이 가능한 게이트웨이가 디바이스와 인터넷 웹을 연결해 주어야 한다.
상기 도 1을 참고하여 설명하면, 블루투스 저전력 에너지(이하, 블루투스 LE(Low Energy)라고 한다)를 지원하는 클라이언트 디바이스(10)와 상기 게이트웨이 (20)가 블루투스를 이용하여 연결되어 있다.
이를 통해서 상기 클라이언트 디바이스(100)는 게이트웨이(200)에게 데이터를 전송할 수 있다. 상기 게이트웨이(200)는 와이파이(Wi-Fi), LTE(Long Term Evolution) 또는 그 밖의 기술을 이용하여 웹 서버(400)와 연결되어 있으며, 이를 통해서 상기 클라이언트 디바이스(100)로부터 전송 받은 데이터를 웹 서버로 전송할 수 있다.
본 발명은 이러한 블루투스를 이용하여 HTTP 데이터를 전송하는 경우, 효율적으로 전송하기 위한 방법 및 장치를 제공한다.
도 2는 본 발명이 적용되는 서버 디바이스 및 클라이언트 디바이스의 내부 블록도의 일 예를 나타낸 도이다.
게이트웨이(Gateway, 200)는 클라이언트 디바이스(Client Device, 100)와 직접 통신할 수 있는 모든 전자기기를 말할 수 있다. 본 발명에서 상기 게이트웨이(200)는 서버 디바이스로 호칭될 수 있다.
상기 클라이언트 디바이스(100)는 블루투스(Bluetooth)기능을 지원할 수 있는 모든 전자기기를 말할 수 있다.
상기 게이트웨이(200)는 상기 클라이언트 디바이스(100)와 직접 통신하며 데이터를 제공받고, 제공 받은 데이터의 처리 결과를 상기 클라이언트 디바이스(100)에게 다시 알려 줄 수 있다.
또한, 상기 클라이언트 디바이스(100)로부터 데이터를 요청 받고, 요청 받은 데이터를 다시 상기 클라이언트 디바이스(100)에게 전송할 수 있으며, 이를 위해서 상기 클라이언트 디바이스(100)에게 통지(Notification) 또는 지시(Indication) 메시지를 보낼 수 있으며, 상기 클라이언트 디바이스(100)로부터 이에 대한 컨펌(Confirm) 메시지를 수신 받을 수 있다.
하나의 서버 디바이스는 여러 개의 클라이언트 디바이스들과 연결 가능하며, 본딩(Bonding) 정보를 활용하여 클라이언트 디바이스들과 쉽게 재 연결이 가능할 수 있다.
상기 클라이언트 디바이스(100) 및 상기 게이트웨이(200)는 각각 통신부(110, 210), 사용자 입력부(220, 120), 출력부(230, 130), 제어부(140, 240), 메모리(150, 250) 및 전원 공급부(160, 260)를 포함할 수 있다.
상기 통신부, 사용자 입력부, 출력부, 제어부, 메모리 및 전원 공급부는 본 발명에서 제안하는 방법을 수행하기 위해 기능적으로 연결된다.
상기 도 2에 도시된 구성요소들이 필수적인 것은 아니어서, 그보다 많은 구성요소들을 갖거나 그보다 적은 구성요소들을 갖는 전자 기기를 구현될 수도 있다.
상기 통신부(110, 210)는 디바이스와 무선 통신 시스템 사이 또는 디바이스와 디바이스가 위치한 네트워크 사이의 무선 통신을 가능하게 하는 하나 이상의 모듈을 포함할 수 있다. 예를 들어, 상기 통신부(160, 260)는 방송 수신 모듈(미도시), 이동통신 모듈(미도시), 무선 인터넷 모듈(미도시) 및 근거리 통신 모듈(미도시)을 포함할 수 있다.
상기 통신부(110, 210)는 송/수신부로 호칭될 수 있다.
상기 이동통신 모듈은, 이동 통신망 상에서 기지국, 외부의 단말, 서버 중 적어도 하나와 무선 신호를 송수신한다. 상기 무선 신호는, 음성 호 신호, 화상 통화 호 신호 또는 문자/멀티미디어 메시지 송수신에 따른 다양한 형태의 데이터를 포함할 수 있다.
상기 무선 인터넷 모듈은 무선 인터넷 접속을 위한 모듈을 말하는 것으로, 무선 인터넷 모듈은 디바이스에 내장되거나 외장 될 수 있다. 무선 인터넷 기술로는 WLAN(Wireless LAN)(WiFi), Wibro(Wireless broadband), Wimax(World Interoperability for Microwave Access), HSDPA(High Speed Downlink Packet Access) 등이 이용될 수 있다.
상기 무선 인터넷 모듈을 통해서 상기 디바이스는 다른 디바이스와 와이 파이(Wi-Fi) P2P(Peer to Peer)연결을 할 수 있다. 이러한 와이 파이(Wi-Fi) P2P 연결을 통하여 디바이스간 스트리밍 서비스를 제공할 수 있으며, 데이터 송/수신 또는 프린터와 연결되어 프린팅 서비스를 제공할 수 있다.
본 발명에서 상기 게이트웨이(200)는 근거리 통신 모듈을 통해서 클라이언트 디바이스(100)와 연결될 수 있으며, 이를 통해서 상기 클라이언트 디바이스(100)로부터 데이터를 전송 받거나 및 데이터 요청을 수신할 수 있다.
또한, 상기 게이트웨이(200)는 상기 무선 인터넷 모듈을 통해서 웹 서버와 연결되어 인터넷 망에 접속 할 수 있으며, 이를 통해서 상기 클라이언트 디바이스(100)로부터 수신된 데이터를 웹 서버로 전송 하거나 상기 클라이언트 디바이스(100)로부터 요청된 데이터를 수신할 수 있다.
상기 사용자 입력부(120, 220)는 사용자가 의 동작 제어를 위한 입력 데이터를 발생시킨다. 사용자 입력부(120, 220)는 키 패드(key pad) 돔 스위치 (dome switch), 터치 패드(정압/정전), 조그 휠, 조그 스위치 등으로 구성될 수 있다.
상기 출력부(130, 230)는 시각, 청각 또는 촉각 등과 관련된 출력을 발생시키기 위한 것으로, 이에는 디스플레이 모듈(132, 232), 음향 출력 모듈(134, 234) 등이 포함될 수 있다.
상기 디스플레이 모듈(132, 232)은 디바이스에서 처리되는 정보를 표시 출력한다. 예를 들어, 상기 디바이스가 통화 모드인 경우 통화와 관련된 UI(User Interface) 또는 GUI(Graphic User Interface)를 표시한다. 상기 디바이스가 화상 통화 모드 또는 촬영 모드인 경우에는 촬영 또는/및 수신된 영상 또는 UI, GUI를 표시한다.
상기 디스플레이 모듈(132, 232)는 액정 디스플레이(liquid crystal display), 박막 트랜지스터 액정 디스플레이(thin film transistorliquid crystal display), 유기 발광 다이오드(organic lightemitting diode), 플렉시블 디스플레이(flexible display), 3차원 디스플레이(3D display) 중에서 적어도 하나를 포함할 수 있다.
상기 음향 출력 모듈(134, 234)은 호신호 수신, 통화모드 또는 녹음 모드, 음성인식 모드, 방송수신 모드 등에서 통신부(110,210)로부터 수신되거나 상기 메모리(150,250)에 저장된 오디오 데이터를 출력할 수도 있다. 상기 음향 출력 모듈(134, 234)은 상기 디바이스에서 수행되는 기능(예를 들어, 호신호 수신음, 메시지 수신음 등)과 관련된 음향 신호를 출력한다. 이러한 상기 음향 출력 모듈(134, 234)에는 리시버(Receiver), 스피커(speaker), 버저(Buzzer) 등이 포함될 수 있다.
상기 제어부(140, 240)는 상기 클라이언트 디바이스(100) 또는 상기 게이트웨이(200)의 전반적인 동작을 제어하는 모듈을 말하며, 블루투스(Bluetooth) 인터페이스 및 다른 통신 인터페이스로 메시지를 전송 요청 및 수신 받은 메시지를 처리하도록 제어할 수 있다.
상기 제어부(140, 240)는 컨트롤러(controller), 마이크로 컨트롤러(micro controller), 마이크로프로세서(microprocessor)등으로 호칭 될 수 있으며, 상기 제어부(140, 240)는 하드웨어(hardware), 펌웨어(firmware), 소프트웨어, 또는 이들의 결합에 의해 구현될 수 있다.
상기 제어부(140, 240)는 ASIC(application-specific integrated circuit), 다른 칩셋, 논리 회로 및/또는 데이터 처리 장치를 포함할 수 있다.
상기 메모리(150, 250)는 단말기의 각종 정보를 저장하는 매체로서, 상기 제어부와 연결되어 상기 제어부(160, 260)의 동작을 위한 프로그램, 어플리케이션(application), 일반파일 및 입/출력되는 데이터들을 저장할 수 있다.
상기 메모리(130, 230)는 플래시 메모리 타입(flash memory type), 하드디스크 타입(hard disk type), 멀티미디어 카드 마이크로 타입(multimedia card micro type), 카드 타입의 메모리(예를 들어 SD 또는 XD 메모리 등), 램(Random Access Memory, RAM), SRAM(Static Random Access Memory), 롬(ReadOnly Memory, ROM), EEPROM(Electrically Erasable Programmable ReadOnly Memory), PROM(Programmable ReadOnly Memory) 자기 메모리, 자기 디스크, 광디스크 중 적어도 하나의 타입의 저장매체를 포함할 수 있다. 상기 디바이스는 인터넷(internet)상에서 상기 메모리(130, 230)의 저장 기능을 수행하는 웹 스토리지(web storage)와 관련되어 동작할 수도 있다.
상기 전원 공급부(160,260)는 상기 제어부(140, 240)의 제어 하에 외부의 전원, 내부의 전원을 인가 받아 각 구성요소들의 동작에 필요한 전원을 공급해주는 모듈을 말한다.
본 발명에서 적용되는, 블루투스 LE 기술은 작은 duty cycle을 가지며, 저속의 데이터 전송률을 통해 전력 소모를 크게 줄일 수 있어, 상기 전원 공급부(160,260)는 적은 출력 전력으로도(100mW(10dBm)이하) 각 구성요소들의 동작에 필요한 전원을 공급할 수 있다.
도 3은 본 발명이 적용되는, 디바이스의 내부 구성을 기능적인 구성을 개략적으로 도시한 도이다.
클라이언트 디바이스 및 서버 디바이스는 각각 호스트(320)와 컨트롤러(310)로 구성되어 있으며, 상기 컨트롤러(310)는 다시 물리 계층(PHY, 312), 링크 레이어 계층(LL, 314)로 구성되어 있다.
또한 상기 호스트(320)는 다시, 논리적 링크 제어 및 적응 프로토콜(Logical Link Control and Adaptation Protocol, L2CAP, 331), 보안 매니저(Security Manager, SM, 332), 속성 프로토콜(Attribute Protocol, ATT, 333), 일반 속성 프로파일(Generic Attribute Profile, GATT, 334), 일반 접근 프로파일(Generic Access Profile, GAP, 335) 및 GATT 기반 프로파일(336)로 구성되어 있다.
상기 컨트롤러(310)와 상기 호스트(320)는 호스트 컨트롤러 인터페이스(Host Controller Interface, HCI, 316)로 연결되어 있다.
상기 호스트(320)는 커맨드(Command)와 데이터를 상기 컨트롤러(310)에게 상기 HCI(316)를 통해서 제공할 수 있으며, 상기 컨트롤러는 이벤트(event)와 데이터를 상기 HCI(316)를 통해서 상기 호스트(320)에게 제공할 수 있다.
상기 컨트롤러(310)는 블루투스 신호를 받는 무선 송수신 모듈과 블루투스 패킷을 전송하거나 수신하기 위한 하드웨어를 말한다.
상기 PHY 계층(312)은 무선 신호를 송수신하는 계층으로 GFSK(Gaussian Frequency Shift Keying) 모듈레이션과 40개의 RF 채널(Radio Frequency Channel)로 구성 주파수 호핑 기법을 사용한다.
상기 링크 레이어 계층(314)은 3개의 광고 채널(Advertising Channel)을 이용하여 광고(Advertising), 스캐닝(Scanning) 기능을 수행하여 기기간 연결을 생성하고, 37개의 데이터 채널을 통해 데이터 패킷(Data Packet)을 주고 받는 기능을 제공할 수 있다.
상기 호스트(320)는 상기 논리적 링크 제어 및 적응 프로토콜(이하 L2CAP이라 함, 311)을 사용하여 블루투스 상위에서 제공하는 다양한 프토코로(Protocol), 프로파일(Profile)등을 멀티플렉싱(Multiplexing)할 수 있다.
상기 L2CAP(331)은 특정 프로토콜 또는 프로파일에게 데이터를 전송하기 위한 하나의 양방향 채널을 제공할 수 있으며, 블루투스 저전력 에너지에서는 3개의 고정된 채널을 사용한다.
상기 고정된 채널은 각각 시그널링 채널, 보안 매니저(332) 및 속성 프로토콜(이하 ATT라고 함, 333)을 위해서 사용될 수 있다.
블루투스 BR/EDR(Basic Rate/Enhanced Data Rate)에서는 다이나믹 채널(Dynamic Channel)을 사용하며, 프로토콜 서비스 멀티플렉서(Protocol Service Multiplexer), 재전송(retransmission), 스트리밍 모드(Streaming mode)등을 지원할 수 있다.
상기 보안 매니저(이하 SM이라고 한다, 332)는 디바이스 인증 및 key distribution을 제공하기 위한 프로토콜이다.
상기 ATT(333)는 서버와 클라이언트 간에 통신 시 사용되며, 클라이언트가 서버에 있는 Attribute들에 접근하기 위해서 사용되는 attribute 핸들을 갖고 있다. 프로토콜 동작 명령어로는 ‘Request’, ‘Response’, ‘Command’, ‘Notification’, ‘Indication’, ‘Confirmation’등이 있다.
- Request 및 Response 메시지: Request 메시지는 클라이언트 디바이스에서 서버 디바이스로 특정 정보를 요청하기 위한 메시지이며, Response 메시지는 Response 메시지에 대한 응답 메시지로서, 서버 디바이스에 클라이언트 디바이스로 전송되는 메시지를 말한다.
- Command 메시지: 클라이언트 디바이스에서 서버 디바이스로 특정 통작의 명령을 지시하기 위해 전송하는 메시지로, 서버 디바이스는 Command 메시지에 대한 응답을 클라이언트 디바이스로 전송하지 않는다.
- Notification 메시지: 서버 디바이스에 클라이언트 디바이스로 이벤트등과 같은 통지를 위해 전송하는 메시지로, 클라이언트 디바이스는 Notification 메시지에 대한 확인 메시지를 서버 디바이스로 전송하지 않는다.
- Indication 및 Confirm 메시지: 서버 디바이스에서 클라이언트 디바이스로 이벤트 등과 같은 통지를 위해 전송하는 메시지로, Notification 메시지와는 달리, 클라이언트 디바이스는 Indication 메시지에 대한 확인 메시지(Confirm message)를 서버 디바이스로 전송한다.
상기 일반 속성 프로파일(이하 GATT라고 함, 334)는 블루투스 LE 기술을 위해 새롭게 구현된 계층으로, 아래 블루투스 디바이스의 S/W 구성 요소 및 ATT 프로토콜에서 정의한 메시지를 가지고 해당 정보를 얻기 위한 절차를 정의한다. 이 절차는 검색(discovering), 읽기(reading), 쓰기(writing), 알림(notify), 지시(indicating) 특성의 설정을 정의할 수 있다.
- 서비스(Service): 데이터와 관련된 행동(Behavior)의 조합으로 기기의 기본적인 동작을 정의.
- Include: 서비스 사이의 관계를 정의.
- 특성(Characteristics): 서비스에서 사용되는 데이터 값.
- Behavior: UUID(Universally Unique Identifier)로 정의된 computer readable format.
상기 일반 접근 프로파일(이하 GAP이라 한다, 335)은 정의된 디바이스의 발견, 연결, 사용자에게 정보를 제공하는 방안을 정의하며 privacy를 제공할 수 있다.
상기 GATT 기반 프로파일(336)은 상기 GATT(334)에 의존성을 가지는 프로파일들로 주로 저전력 에너지(Low Energy) 디바이스에 적용된다.
상기 GATT 기반 프로파일(366)에는 배터리(Battery), 시간(Time), 프록시미티(Proximity), 폰 알림(Phone Alert), 심박수(Heart Rate), HTTP 프록시 서비스(HTTP Proxy Service, 337)와 관련된 프로파일이 포함될 수 있다.
상기 HTTP 프록시 서비스(337)는 블루투스의 GATT(Generic Attribute Profile) 기능을 활용해서 HTTP 메시지 전달을 요청하는 기능을 수행할 수 있다. 상기 HTTP 프록시 서비스(337)를 이용하여 상기 클라이언트 디바이스(100)와 상기 호스트 디바이스(200)는 HTTP 메시지 전달 요청 및 웹 서버로부터 전송된 데이터를 상기 클라이언트 디바이스(100)로 전송할 수 있다.
도 4는 본 발명이 적용되는, 블루투스 저전력 에너지(Bluetooth Low Energy)를 이용하여 HTTP 데이터를 전송하기 위한 기능적인 구성을 개략적으로 도시한 도이다.
상기 도 4를 참조하면, 블루투스를 통해서 클라이언트 디바이스(100)로부터 데이터를 전송 받은 게이트웨이(200)는 이를 인터넷 웹 서버(400)로 전송할 수 있다.
상기 클라이언트 디바이스(100)와 상기 게이트웨이(200)의 내부 구성 중 상기 도 3에서 설명한 구성과 동일한 구성은 설명을 생략한다.
이를 구체적으로 살펴보면, 상기 클라이언트 디바이스(100)는 HTTP 프록시 클라이언트(12)를 포함하고 있다. 여기서 상기 클라이언트 디바이스(100)와 상기 게이트웨이(200)는 블루투스 저전력 에너지(Bluetooth Low Energy)기술을 지원할 수 있다.
상기 HTTP 프록시 클라이언트(12)는 상기 클라이언트 디바이스(100)가 블루투스 기술로는 인터넷을 통해 웹(Web) 서버에 접속 할 수 없기 때문에 상기 게이트웨이(200) HTTP 프록시 서버(22)를 이용하기 위한 기능을 제공할 수 있다.
상기 클라이언트 디바이스(100)는 상기 HTTP 프록시 클라이언트(12)를 통해서 상기 게이트웨이(200)와 연결될 수 있으며, 이를 통해서 웹 서버로 전송하기 위한 데이터 요청 메시지 또는 데이터를 게이트웨이(200)로 전송할 수 있다.
게이트웨이는(200) HTTP 프록시 서버(22)와 HTTP 클라이언트(24)를 포함하고 있다. 상기 HTTP 프록시 서버(22)는 상기 클라이언트 디바이스(100)와 상기 HTTP 서버(400)의 연결성을 제공하기 위한 HTTP 프록시 서비스 기능을 제공한다.
상기 HTTP 클라이언트(24)는 상기 클라이언트 디바이스(100)의 HTTP 프록시 기능을 제공하기 위해 HTTP 서버에 HTTP 요청을 보내고 받기 위한 클라이언트 기능을 하는 것으로써, HTTP 프록시 서비스의 데이터를 가지고 HTTP 메시지를 생성한 후 HTTP 서버와 통신을 한다.
상기 게이트웨이(200)는 HTTP 프록시 서버(22)를 통해 상기 클라이언트 디바이스(100)로부터 웹 서버에 전송할 메시지 또는 데이터를 수신하며, 수신된 데이터를 통해 HTTP 메시지를 생성할 수 있다.
상기 HTTP 메시지가 생성된 후, 상기 게이트웨이(200)는 HTTP 클라이언트(24)를 통해서 상기 생성된 HTTP 메시지를 무선 통신을 통해서 상기 HTTP 서버(400)로 전송할 수 있다.
여기서 상기 무선 통신은 블루투스를 제외한 무선통신으로써, 인터넷 서버와 연결할 수 있는 통신 수단을 말한다. 예를 들면, Wi-Fi, LTE등이 있을 수 있다.
상기 HTTP 서버는 웹(web)서비스를 제공하기 위해 HTTP 프로토콜을 사용하는 서버를 의미한다.
또한 상기 게이트웨이는 HTTP 서버(400)로부터 상기 클라이언트 디바이스(100)가 요청한 데이터를 HTTP 클라이언트(24)를 통해 수신할 수 있다.
상기 수신된 데이터는 다시 블루투스를 통해 전송이 가능한 형태로 변환된 후, 상기 HTTP 프록시 서버(220)를 통해서 상기 클라이언트 디바이스(100)의 HTTP 프록시 클라이언트(12)에게 전송된다.
HTTP Proxy Service Characteristic Requirements
HTTP 프록시 서비스(HTTP Proxy Service)의 Characteristic은 아래 표 1에 나타나 있다.
표 1
Characteristic Name Requirement Mandatory Properties Optional Properties Security Permissions
URI M Read, Write Optional
HTTP Header M Read, Write Optional
HTTP Status Code M Notify, Indicate Optional
HTTP Entity Body M Read, Write Optional
HTTP L2CAP M Read Optional
HTTP Control Point M Write, Indicate Optional
HTTPS Sercurity M Read Optional
HTTP 프록시 서비스의 Characteristic은 HTTP 프록시 서비스를 제공하기 위한 정보들을 포함하고 있다.
상기 URI Characteristic은 이후의 요청을 위한 URI를 구성하는데 사용된다. 상기 URI Characteristic은 HTTP 요청에 사용되는 URI를 포함하고 있으며, 정의된 최대 길이까지 사용될 수 있다. 예를 들면, 현재 URI를 포함하고 있는 HTTP 요청의 최대 길이는 512 octet이다.
상기 HTTP Header Characteristic은 쓰기 요청(Write request) 또는 읽기 요청(Read request)에 포함된 Header를 포함하는데 사용된다.
상기 HTTP Header Characteristic은 정의된 최대 길이까지 사용될 수 있다. 예를 들면, 현재 HTTP Header Characteristic의 최대 길이는 512 octec이다.
상기 HTTP 엔터디 바디(HTTP Entity Body)는 전송하고자 하는 메시지의 바디를 포함하고 있다. 상기 HTTP L2CAP PSM(HTTP L2CAP Protocl Service Multiplexer)은 데이터 정보가 어떤 프로토콜 또는 어떤 서비스에 대한 것인가를 표시하는 식별자를 나타낸다.
상기 HTTP L2CAP PSM 값이 변경된 경우 상기 게이트웨이는 변경된 값을 클라이언트 디바이스에게 지시(Indication) 또는 통지(Notification)해줄 수 있다.
상기 HTTP Status Code Characteristic은 수신된 데이터의 상태를 나타내는 정보를 포함할 수 있다. 상기 수신된 데이터의 상태는 웹 서버(400)로부터 상기 게이트웨이(200)가 수신한 HTTP 헤더 및/또는 HTTP 엔터티 바디에 포함된 데이터의 상태를 말한다.
상기 HTTP 컨트롤 포인트(HTTP Control Point)는 HTTP 프록시 서비스가 특정 동작을 하도록 지시하는 기능을 한다. 아래 표 2는 상기 HTTP 컨트롤 포인트에 포함될 수 있는 명령들을 나타낸다.
표 2
Op Code Value Procedure
0x00 Reserved for Future Use
0x01 HTTP GET Request
0x02 HTTP HEAD Request
0x03 HTTP POST Request
0x04 HTTP PUT Request
0x05 HTTP DELETE Request
0x06 HTTPS GET Request
0x07 HTTPS HEAD Request
0x08 HTTPS POST Request
0x09 HTTPS PUT Request
0x0a HTTPS DELETE Request
0x0b HTTPS Request Cancel
0x0c - 0xff Reserved for Future Use
상기 HTTPS Security는 보안과 관련된 기능을 사용할지 여부를 나타내는 정보를 포함한다. 상기 HTTPS Security 기능이 Yes인 경우 HTTPS를 사용해서 보안 기능을 사용하고, No인 경우 HTTP를 사용해서 보안 기능을 사용하지 않을 수 있다.
상기 HTTP Security characteristic은 불리안(Boolean)으로 표현될 수 있다.
쓰기 요청(Write Request)
도 5는 블루투스 저전력 에너지(Bluetooth Low Energy)를 이용하여 HTTP 데이터를 전송하는 일 예를 나타낸 도이다.
상기 도 5를 참조하면 클라이언트 디바이스 1(100)은 게이트웨이(200)에게 쓰기 요청(Write Request)을 통해서 HTTP 요청 메시지 생성을 위한 정보를 전송할 수 있다. 상기 쓰기 요청(Write request)은 하나의 Characteristic을 포함할 수 있다.
구체적으로, 상기 클라이언트 디바이스 1(100)은 쓰기 요청을 통해서 URI(Universal Resource Identifier)를 전송한다(S510). 상기 클라이언트 디바이스(100)는 그 후 다시 쓰기 요청(Write request)을 통해서 HTTP 헤더를 전송하고(S512), 순차 적으로 쓰기 요청(Write request)를 통해, HTTP 엔터티 바디(HTTP entity body) 및 HTTP 컨트롤 포인트(HTTP control point)를 전송한다(S514, S516).
상기 게이트웨이(200)는 상기 각각의 쓰기 요청(write request)에 대한 응답 메시지를 상기 클라이언트 디바이스 1(100)에게 전송할 수 있다.
즉, 상기 URI를 포함한 쓰기 요청에 대한 응답, 상기 HTTP 헤더를 포함한 쓰기 요청에 대한 응답, 상기 HTTP 엔터티 바디를 포함한 쓰기요청에 대한 응답, 상기 HTTP 컨트롤 포인트를 포함한 쓰기 요청에 대한 응답을 각각 상기 클라이언트 디바이스 1(100)에게 전송할 수 있다.
상기 게이트웨이(200)는 상기 클라이언트 디바이스 1(100)로부터 수신된 정보를 기초로 HTTP 요청 메시지를 생성해서 상기 웹 서버(400)로 전송할 수 있다(S518).
상기 HTTP 요청 메시지는 HTTP 요청과 관련된 정보, 즉, 상기 클라이언트 디바이스 1(100)로부터 전송된 정보(URI, HTTP 헤더, HTTP 엔터티 바디)를 포함할 수 있다.
즉, 상기 클라이언트 디바이스 1(100)는 HTTP 요청과 관련된 정보를 상기 게이트웨이(200)로 전송하고, 상기 게이트웨이(200)는 상기 HTTP 요청과 관련된 정보를 하나의 메시지 또는 프레임 형태로 상기 웹 서버(400)에 전송할 수 있다.
상기 HTTP 요청 메시지를 수신한 웹 서버(400)는 이에 대한 응답으로 요청된 데이터 및 HTTP 상태 코드(HTTP Status Code)가 포함된 HTTP 응답 메시지를 상기 게이트웨에게 전송한다(S520). 상기 HTTP 상태 코드(HTTP Status Code)는 요청된 데이터의 상태를 나타내는 코드이다.
상기 HTTP 응답 메시지를 수신한 상기 게이트웨이(200)는 이를 블루투스를 통해서 전송할 수 있는 형태로 변환할 수 있다.
읽기 요청(Read Request)
상기 게이트웨이는 상기 웹 서버(400)로부터 HTTP 응답 메시지를 수신한 뒤, 상기 클라이언트 디바이스(100)로 상태코드를 포함하고 있는 지시(Indication) 메시지를 전송한다(S522). 이를 통해 상기 클라이언트 디바이스는 상기 게이트웨이(200)가 요청한 데이터를 정확히 수신하였는지, 수신하지 못하였는지, 불완전하게 수신하였는지 알 수 있다.
상기 클라이언트 디바이스(100)는 읽기 요청(read request)을 통해 상기 게이트 웨이(200)로 상기 게이트웨이가 상기 웹 서버(400)로부터 수신한 정보를 요청할 수 있다.
즉, 상기 클라이언트 디바이스(100)는 상기 게이트웨이(200)로 읽기 요청(Read Request)를 전송하여 URI를 전송 받을 수 있으며(S524), 다시 읽기 요청을 통하여 HTTP 헤더를 전송 받을 수 있다(S526). 그 후, 상기 클라이언트 디바이스(100)는 HTTP 엔터티 바디를 전송 받기 위해 상기 게이트웨이(200)로 읽기 요청을 전송하고 상기 게이트웨이(200)로부터 HTTP 엔터티 바디를 전송 받을 수 있다(S528).
이러한 방식을 통하여 상기 클라이언트 디바이스 1(100)은 상기 웹 서버(400)로부터 데이터를 전송 및 수신할 수 있다.
하지만, 상기 게이트웨이(200)는 동시에 다수의 클라이언트 디바이스가 접속할 수 있으며, 이 경우, 어떤 디바이스가 해당 서비스를 이용하는지 구별할 수 없기 때문에 원활한 서비스가 제공되지 않을 수 있다.
이하, 이러한 문제점에 대해서 살펴보도록 한다.
도 6 및 도 7은 다수의 클라이언트 디바이스가 동일한 게이트 웨이(Gateway)에게 쓰기 요청(write request)을 전송하는 일 예를 나타낸 도이다.
상기 도 7의 단계 S710 내지 S 718은 상기 도 5의 단계 S510 내지 S 518과 동일하므로 설명을 생략하도록 한다.
상기 도 6 및 상기 도 7을 참조하면 블루투스 기능을 지원하는 디바이스(100, 120, 140)가 HTTP 데이터 전송을 위하여 게이트웨이(200)에게 HTTP요청 관련정보를 포함하는 쓰기 요청(write request)을 전송하고 있다.
상기 게이트웨이(200)는 클라이언트 디바이스와 연결되어 상기 클라이언트 디바이스가 요청한 상기 HTTP 요청 관련정보를 포함하는 HTTP 메시지를 웹 서버(300)에 전달할 수 있다. 하지만, 클라이언트 디바이스(100)가 상기 게이트웨이(200)로 HTTP 메시지 생성을 위한 쓰기 요청(Write request)을 전송하는 중에, 다른 클라이언트 디바이스(120, 140)으로부터 상기 게이트 웨이(200)가 또 다시 HTTP 메시지 생성을 위한 쓰기 요청(write request)을 수신하는 경우, 기존 특성(Characteristic)에 대한 유지를 할 수 없다는 문제점이 존재한다.
즉, 상기 도 7에서, 상기 클라이언트 디바이스 1(100)이 쓰기 요청을 통해서 상기 게이트웨이(200)로 정보를 전송하는 도중, 상기 클라이언트 디바이스 2(120)로부터 쓰기 요청(write request)이 수신되면 기존에 상기 클라이언트 디바이스 1(100)이 상기 게이트웨이(200)에 전송한 Characteristic에 대한 정보를 유지할 수 없다.
따라서, 상기 클라이언트 1은 자신이 요청한 데이터를 수신하지 못하는 문제점이 발생할 수 있으며, 원활한 데이터 전송이 이루어 지지 않을 수 있다.
이러한 문제점을 해결하기 위해서 이미 쓰기 요청을 통해서 상기 게이트웨이(200)에 정보를 전송중인 디바이스가 존재하는 경우, 다른 디바이스가 다시 쓰기 요청을 하는 경우 에러 메시지를 전송하거나, 이미 해당 서비스를 사용하는 클라이언트 디바이스가 있음을 알려줄 수 있다.
이하 이러한 방법에 대해서 구체적으로 살펴본다.
Request에 대한 error 메서지 전송
도 8은 본 발명이 적용되는, 다수의 디바이스가 쓰기 요청(write request)전송 시, 에러 응답을 전송하는 일 예를 나타낸 도이다.
상기 도 8의 단계 S810 내지 S816은 상기 도 5의 S510 내지 S516단계와 동일하므로 설명을 생략하도록 한다.
상기 클라이언트 디바이스 1(100)이 쓰기 요청(Write request)를 통해서 상기 게이트웨이(200)로 데이터를 전송 중 상기 클라이언트 디바이스 2(120)가 HTTP 요청 메시지 생성을 위해서 쓰기 요청(write request)를 통해서 URI 정보를 전송할 수 있다(S818).
하지만, 이미 상기 클라이언트 디바이스 1(100)이 상기 게이트웨이(200)에 쓰기 요청을 하고 있으므로, 상기 게이트웨이(200)는 상기 클라이언트 디바이스 2(200)의 쓰기 요청을 받아들일 수 없다.
이는, 이미 진행된 쓰기 요청이 있거나, 또는 상기 게이트웨이의 자원(Resource)가 충분하지 못한 이유로 인해서 상기 게이트웨이가 상기 클라이언트 디바이스 2(120)의 요청을 거부할 수 있다.
따라서, 상기 게이트웨이(200)는 상기 클라이언트 디바이스 2(120)의 쓰기 요청(write request)을 받아들일 수 없으므로 에러 응답(error response)를 상기 클라이언트 디바이스 2(120)에게 전송한다(S820).
아래 표 3은 클라이언트 디바이스의 쓰기 요청에 대한 에러 응답에 포함될 수 있는 에러코드를 나타낸다.
표 3
Name Error Code Description
Other Client is using 0x80 Can not write a value because of Server is servicing to other client
Long HTTP Entity Body 0x81 L2CAP delivery is needed because of HTTP Entity Body is Long
상기 에러 코드 중에서 상기 게이트웨이(200)는 0x80을 에러 응답에 포함해서 상기 클라이언트 2(120)에게 전송할 수 있으며, 클라이언트 2는 상기 에러 응답 메시지를 수신한 경우 쓰기 요청을 중단할 수 있다.
상기 도면에는 도시되어 있지 않지만, 상기 도 5의 단계 S518과 같이, 상기 게이트웨이(200)는 상기 클라이언트 디바이스 1(100)로부터 수신한 HTTP요청 관련 정보를 웹서버로 전송할 수 있으며, 단계 S518과 같이 상기 웹 서버로부터 HTTP 데이터가 포함된 HTTP 응답을 수신할 수 있다.
상기 HTTP 응답은 상기 HTTP 데이터의 상태를 나타내는 상태 코드(Status Code)를 포함할 수 있다.
이하, 단계 S822 내지 단계 S828은 상기 도 5의 단계 S522 내지 S528과 동일하므로 설명을 생략하도록 한다.
상기 표 3의 에러코드는 본 발명의 HTTP 프록시 서비스 외에도 블루투스의 다른 서비스에 예를 들면, 블루투스 오브젝트 트랜스퍼 서비스(Bluetooth Object Transfer Service)에서 이용될 수 있으며 이에 대한 구체적은 내용은 도 19에서 살펴보도록 한다.
도 9은 본 발명이 적용되는, 데이터 길이에 따른 에러응답 전송하는 일 예를 나타낸 도이다.
상기 도 9를 참고하면 상기 게이트웨이(200)가 상기 클라이언트 디바이스1(100)에게 전송하려는 데이터가 긴 경우 에러메시지를 전송하여 다른 방법으로 데이터를 전송한다.
S910단계 내지 S916 단계는 상기 도 5의 단계 S510 내지 S516 단계와 동일하므로 설명을 생략하기로 한다.
상기 도면에는 도시되어 있지 않지만, 상기 도 5의 단계 S518과 같이, 상기 게이트웨이(200)는 상기 클라이언트 디바이스 1(100)로부터 수신한 HTTP요청 관련 정보를 상기 웹서버로 전송할 수 있으며, 단계 S518과 같이 상기 웹 서버로부터 HTTP 데이터가 포함된 HTTP 응답을 수신할 수 있다.
단계 S918 내지 단계 S922는 상기 도 5의 단계 S522 내지 단계 S526과 동일하므로 설명을 생략하기로 한다.
상기 HTTP 응답은 상기 HTTP 데이터의 상태를 나타내는 상태 코드(Status Code)를 포함할 수 있다.
상기 클라이언트 디바이스 1(100)은 상기 게이트웨이(200)로부터 HTTP 엔터티 바디(HTTP Entity Body)를 읽어오기 위해서 상기 게이트웨이(200)로 읽기 요청을 전송한다(S924).
하지만, 웹 서버로부터 전송된 HTTP 엔터티 바디가 너무 길어서 ATT 프로토콜 메시지로 전송되기 어려운 경우 다른 채널을 열어서 데이터를 수신해야 한다.
따라서, 상기 게이트 웨이는 에러 응답(Error Response)을 상기 클라이언트 디바이스 1(100)에게 전송한다(S926). 상기 에러 응답은 상기 표 3의 0x81코드를 포함할 수 있다.
상기 에러 응답을 수신한 상기 클라이언트 디바이스 1(100)은 ATT 프로토콜 대신 L2CAP 연결형 채널(L2CAP Connection Oriented Channel)을 열어서 상기 HTTP 엔터티 바디를 수신할 수 있다(S928).
이를 통해서, 수신된 데이터의 길이가 긴 경우에도 에러메시지를 통해 다른 채널을 열어 상기 수신된 데이터를 전송 받을 수 있다.
Client ID 전송
도 10는 본 발명이 적용되는, 현재 사용중인 클라이언트 ID를 이용하여 HTTP 데이터를 전송하는 일 예를 나타낸 도이다.
아래 표 4는 Characteristic의 또 다른 예를 나타낸다.
표 4
Characteristic Name Requirement Mandatory Properties Optional Properties Security Permissions
Client ID Read, WriteIndication/Notification
Protected Read, WriteIndication/Notification
URI M Read, Write Optional
HTTP Header M Read, Write Optional
HTTP Status Code M Notify, Indicate Optional
HTTP Entity Body M Read, Write Optional
HTTP L2CAP M Read Optional
HTTP Control Point M Write, Indicate Optional
HTTPS Sercurity M Read Optional
상기 Client ID Characteristic은 HTTP 프록시 기능을 사용하고자 하는 Client의 ID를 포함한다. 상기 Client ID 값이 Null이면 HTTP 프록시 서비스(HPS)를 이용할 수 있지만, 특정 값인 경우에는 상기 HTTP 프록시 서비스(HPS)를 요청할 수 없다.
상기 Client ID는 사용자 ID 또는 Device ID를 사용함으로써, 사용자 또는 디바이스를 구별할 수 있으며, 서비스 UUID등을 추가하여 사용자 또는 디바이스 내부의 서비스를 구별할 수 있다.
상기 Protected Characteristic은 클라이언트 디바이스로부터 request 요청시 해당 기능을 yes로 설정할 수 있으며, yes로 설정된 경우 다른 클라이언트는 요청을 보낼 수 없다.
응답이 완료되면 Protected 기능을 No로 변경할 수 있으며 이 경우에만 다른 클라이언트가 요청할 수 있다.
또한 HTTP Status Code를 지시(Indication)한 후 일정 시간이 지나면 자동으로 No로 변경되도록 할 수 있다.
상기 도 10을 참고하면, 클라이언트 디바이스는 게이트웨이로부터 클라이언트 ID 값을 읽어 올 수 있으며, 상기 클라이언트 ID 값이 다른 클라이언트 디바이스의 ID 값인 경우 상기 클라이언트 디바이스는 HTTP 프록시 서비스를 이용할 수 없다.
이를 구체적으로 살펴보면, 상기 클라이언트 디바이스 1(100)은 상기 게이트 웨이(200)에게 클라이언트 ID의 읽기 요청(Read Request)을 전송한다(S1010). 상기 게이트웨이(200)는 이에 대한 응답으로 이미 HTTP 프록시 서비스를 이용하고 있는 클라이언트 디바이스가 있는 경우, 상기 클라이언트 디바이스의 정보를 상기 클라이언트 디바이스 1(100)에게 전송할 수 있다.
하지만, 상기 HTTP 프록시 서비스를 이용하고 있는 클라이언트 디바이스가 없는 경우, 상기 게이트웨이(200)는 NULL값을 포함한 읽기 응답(Read response) 상기 클라이언트 디바이스 1(100)에게 전송한다(S1012).
상기 HTTP 프록시 서비스를 이용하고 있는 클라이언트 디바이스가 없는 것을 확인한 상기 클라이언트 디바이스 1(100)은 상기 게이트웨이(200)에게 쓰기 요청(write request)을 통해서 상기 클라이언트 ID 값에 상기 클라이언트 디바이스 1(100)의 정보를 입력(Write)할 것을 요청할 수 있다(S1014).
상기 요청을 받은 상기 게이트웨이(200)는 상기 클라이언트 ID에 상기 클라이언트 디바이스 1(100)의 정보를 입력할 수 있으며, 상기 요청에 대한 응답 메시지를 상기 클라이언트 디바이스 1(100)에게 전송할 수 있다.
이하, 단계 S1016 내지 단계 1022는 상기 도 5의 단계 S510 내지 S516과 동일하므로 설명을 생략하도록 한다.
이후, 상기 클라이언트 디바이스 2(120)는 HTTP 프록시 서비스를 이용하기 위해서 읽기 요청을 통해서 클라이언트 ID 값을 요청할 수 있다(S1024).
상기 클라이언트 디바이스 2(120)의 상기 읽기 요청에 대한 응답으로 상기 상기 클라이언트 디바이스 2(120)에게 전송한다(S1026).
이미, 상기 HTTP 프록시 서비스는 상기 클라이언트 디바이스 1(100)이 사용하고 있으므로 상기 게이트웨이(200)는 상기 클라이언트 ID 값에 상기 클라이언트 디바이스 1(100)에 대한 정보, 예를 들면, 사용자 ID 또는 디바이스 ID를 포함하여 전송할 수 있다.
상기 게이트웨이(200)의 클라이언트 ID가 포함된 읽기 응답으로부터 상기 HTTP 프록시 서비스를 상기 클라이언트 디바이스 1(100)가 사용하고 있음을 알 수 있다.
따라서, 상기 클라이언트 디바이스 2(120)는 상기 클라이언트 ID 값이 NULL이 될때까지 HTTP 프록시 서비스 요청을 중단한다.
상기 도면에는 도시되어 있지 않지만, 상기 도 5의 단계 S518과 같이, 상기 게이트웨이(200)는 상기 클라이언트 디바이스 1(100)로부터 수신한 HTTP요청 관련 정보를 상기 웹서버로 전송할 수 있으며, 단계 S518과 같이 상기 웹 서버로부터 HTTP 데이터가 포함된 HTTP 응답을 수신할 수 있다.
상기 HTTP 응답은 상기 HTTP 데이터의 상태를 나타내는 상태 코드(Status Code)를 포함할 수 있다.
이하, 단계 S1028 내지 단계 S1034는 상기 도 5의 단계 S522 내지 S528과 동일하므로 설명을 생략한다.
이와 같은 방법을 통해서 이미 HTTP 프록시 서비스를 이용하고 있는 디바이스가 존재하는 경우, HTTP 프록시 서비스를 이용하지 않음으로써, 게이트웨이에 이미 존재한 Characteristic이 삭제되지도 않고, 현재 사용중인 디바이스를 알 수 있으므로 원활한 HTTP 프록시 서비스를 제공을 할 수 있다.
도 11은 본 발명이 적용되는, 현재 사용중인 클라이언트 ID를 다수의 디바이스에게 전송하는 일 예를 나타낸 도이다.
상기 도 11을 참고하면 클라이언트 ID가 변경된 경우 이를 상기 게이트웨이(200)에 접속된 클라이언트들에게 알림으로써 HTTP 프록시 서비스 접속을 원활히 진행할 수 있다.
이를 구체적으로 살펴보면, 상기 클라이언트 ID 값이 NULL인 경우, 상기 클라이언트 디바이스 1(100)은 쓰기 요청(Write request)을 통해서 상기 클라이언트 ID 값에 상기 클라이언트 디바이스 1(100)의 정보를 입력하도록 요청할 수 있다(S1110).
상기 요청에 따라 상기 게이트웨이(200)는 상기 클라이언트 ID 값에 상기 클라이언트 디바이스 1(100)의 정보, 예를 들면 상기 클라이언트 디바이스 1(100)의 사용자 ID 또는 디바이스 ID를 입력할 수 있으며, 이에 대한 응답을 상기 클라이언트 디바이스 1(100)에게 전송할 수 있다.
이 후, 상기 게이트웨이(200)는 상기 클라이언트 ID 값이 변경되었음을 통지(Notification) 또는 지시(Indication)을 통해서 상기 게이트웨이(200)와 연결된 디바이스들에게 알릴 수 있다(S1112).
상기 게이트웨이(200)가 지시(Indication)을 통해서 상기 클라이언트 ID 값의 변경을 알린 경우, 상기 지시(Indication)을 받은 디바이스들은 컨펌 메시지를 상기 게이트웨이(200)에게 전송한다.
이하, 단계 S1114 내지 단계 S1120은 상기 도 5의 단계 S510 내지 단계 S516와 동일하므로 설명을 생략 한다.
상기 도면에는 도시되어 있지 않지만, 상기 도 5의 단계 S518과 같이, 상기 게이트웨이(200)는 상기 클라이언트 디바이스 1(100)로부터 수신한 HTTP요청 관련 정보를 상기 웹서버로 전송할 수 있으며, 단계 S518과 같이 상기 웹 서버로부터 HTTP 데이터가 포함된 HTTP 응답을 수신할 수 있다.
상기 HTTP 응답은 상기 HTTP 데이터의 상태를 나타내는 상태 코드(Status Code)를 포함할 수 있다.
상기 단계 S1122 내지 단계 S1228은 상기 도 5의 단계 S522 내지 단계 S528과 동일하므로 설명을 생략한다.
상기 게이트웨이(200)로부터 요청된 데이터를 모두 수신한 상기 클라이언트 디바이스 1(100)은 HTTP 프록시 서비스의 사용이 종료되었으므로, 쓰기 요청을 통해서 상기 클라이언트 ID 값을 다시 NULL로 변경할 것을 상기 게이트웨이(200)에게 요청할 수 있다(S1130).
상기 게이트웨이(200)는 상기 클라이언트 디바이스 1(100)의 요청에 따라 상기 클라이언트 ID의 값을 NULL로 변경할 수 있으며, 연결된 디바이스들에게 변경된 값을 통지(Notification) 또는 지시(Indication)할 수 있다.
이 때, 상기 변경된 클라이언트 ID 값을 지시(Indication)한경우, 상기 연결된 디바이스들은 컨펌 메시지를 상기 게이트웨이(200)에게 전송할 수 있다.
또한, 상기 클라이언트 ID가 NULL인 경우 다수의 클라이언트 디바이스로부터 HTTP 프록시 서비스의 요청이 들어올 수 있으나, 동시에 요청이 들어온 경우 데이터가 파손되어 요청을 다시 전송해야 한다.
상기 도 11의 방법을 통해서, 어떤 클라이언트 디바이스가 상기 HTTP 프록시 서비스의 사용여부를 알 수 있으며, 사용이 종료된 경우에도 통지 또는 지시를 통해서 HTTP 프록시 서비스의 사용가능 여부를 알 수 있다.
또한, 중복된 서비스 요청으로 인한 데이터 전송의 혼란 또는 이미 전송된 Characteristic의 손실을 방지함으로써 원활한 서비스 제공이 가능해진다.
도 12은 본 발명이 적용되는, 디바이스가 HTTP 데이터를 전송하는 경우 이미 HTTP 데이터를 전송하고 있는 디바이스가 있음을 알려주는 일 예를 나타낸 도이다.
상기 도 12를 참고하면, 클라이언트 디바이스가 HTTP 프록시 서비스를 이용하고 있는 경우 이를 다른 클라이언트 디바이스에게 알려주어 상기 다른 클라이언트 디바이스의 상기 HTTP 프록시 서비스를 사용하기 위한 요청을 방지할 수 있다.
이를 구체적으로 살펴보면, 상기 클라이언트 디바이스(100)가 상기 게이트웨이(200)에게 읽기 요청을 통해서 프로텍티드(Protected)값을 요청할 수 있다(S1210).
상기 게이트웨이(200)는 다른 클라이언트 디바이스에게 HTTP 프록시 서비스를 제공중인 경우 Yes 값, 제공하고 있지 않는 경우 No 값을 상기 읽기 응답(Read response)에 포함하여 전송할 수 있다.
상기 게이트웨이(200)로부터 전송된 상기 프로텍티드 값이 Yes인 경우 다른 클라이언트 디바이스가 상기 HTTP 프록시 서비스를 이용하고 있는 것이므로 상기 클라이언트 디바이스는 상기 HTTP 프록시 서비스를 이용할 수 없다.
하지만 상기 프로텍티드 값이 No인 경우 상기 HTTP 프록시 서비스를 이용하고 있는 클라이언트 디바이스가 없으므로 상기 클라이언트 디바이스 1(100)은 상기 HTTP 프록시 서비스를 이용할 수 있다.
이하 단계 S1214 내지 단계 S1220은 상기 도 5의 단계 S510 내지 단계 S516과 동일하므로 설명을 생략하도록 한다.
하지만 상기 단계 S1214 내지 단계 S1220 도중 다른 클라이언트 디바이스로부터 쓰기 요청(write request)이 있는 경우 상기 프로텍티드 값을 Yes로 변경할 수 있다.
이 후, 상기 클라이언트 디바이스 2(120)가 상기 HTTP 프록시 서비스를 이용하기 위해서 상기 게이트웨이(200)에게 읽기 요청을 통해서 프로텍티트 값을 요청한 수 있다(S1222).
하지만, 이미 상기 클라이언트 디바이스 1(100)이 HTTP 프록시 서비스를 이용하고 있으므로 상기 게이트웨이는 상기 클라이언트 디바이스 2(120)에게 상기 프로텍티드 값으로 Yes 값을 전송한다(S1224).
상기 게이트웨이(200)로부터 프로텍티트 값으로 Yes 값을 전송 받은 상기 클라이언트 디바이스 2(120)는 상기 HTTP 프록시 서비스가 사용중이란 것을 알 수 있다.
하지만, 상기 프로텍티드 값으로 Yes만 전송 받았으므로, 상기 HTTP 프록시 서비스를 이용하고 있는 디바이스가 상기 클라이언트 디바이스 1(100)이란 것은 알 수 가 없다.
상기 HTTP 프록시 서비스를 이용할 수 없음을 알게 된 상기 클라이언트 디바이스 2(120)는 상기 게이트웨이(200)에게 HTTP 프록시 서비스이용을 위한 요청을 할 수 없다.
이하, 상기 도면에는 도시되어 있지 않지만, 상기 도 5의 단계 S518과 같이, 상기 게이트웨이(200)는 상기 클라이언트 디바이스 1(100)로부터 수신한 HTTP요청 관련 정보를 웹 서버로 전송할 수 있으며, 단계 S518과 같이 상기 웹 서버로부터 HTTP 데이터가 포함된 HTTP 응답을 수신할 수 있다.
상기 HTTP 응답은 상기 HTTP 데이터의 상태를 나타내는 상태 코드(Status Code)를 포함할 수 있다.
이하, 단계 S1226 내지 단계 S1232는 상기 도 5의 단계 S522 내지 단계 S528과 동일하므로 설명을 생략하도록 한다.
상기 프로텍티드 값은 상기 게이트웨이(200)가 상기 클라이언트 디바이스 1(100)과 일정시간 동작이 없는 경우 No로 변경될 수 있으며, 상기 클라이언트 디바이스 1(100)가 해당 프로텍티드 값의 쓰기 요청(write request)을 통해서 No로 변경될 수 있다.
도 13는 본 발명이 적용되는, 다수의 디바이스에게 이미 HTTP 데이터를 전송하고 있는 디바이스가 있음을 통지하는 또 다른 일 예를 나타낸 도이다.
상기 도 13을 참고하면, 상기 프로텍티드 값이 No인 경우, 상기 클라이언트 디바이스 1(100)은 쓰기 요청을 통해서 상기 프로텍티드 값을 Yes로 변경할 것을 상기 게이트웨이(200)에게 요청할 수 있다(S1310).
상기 쓰기 요청을 받은 상기 게이트웨이(200)는 상기 프로텍티드 값을 Yes로 변경할 수 있으며, 상기 클라이언트 디바이스 1(100)에게 상기 쓰기 요청에 대한 응답 메시지를 전송할 수 있다.
그 후, 상기 게이트웨이(200)는 상기 변경된 프로텍티드 값을 연결된 다른 클라이언트 디바이스, 예를 들면 클라이언트 디바이스 2(120)에게 통지(Notification) 또는 지시(Indication)을 통해서 알려 줄 수 있다(S1312).
이 때, 상기 클라이언트 디바이스 2(120)가 지시(Indication)을 통해서 상기 게이트웨이(200)로부터 프로텍티드 값을 전송 받은 경우, 이에 대한 컨펌 메시지를 상기 게이트웨이(200)에게 전송할 수 있다.
이하, 단계 S1314 내지 단계 S1320은 상기 도 5의 단계 S510 내지 단계 S516과 동일하므로 설명을 생략하도록 한다.
상기 도면에는 도시되어 있지 않지만, 상기 도 5의 단계 S518과 같이, 상기 게이트웨이(200)는 상기 클라이언트 디바이스 1(100)로부터 수신한 HTTP요청 관련 정보를 웹 서버로 전송할 수 있으며, 단계 S518과 같이 상기 웹 서버로부터 HTTP 데이터가 포함된 HTTP 응답을 수신할 수 있다.
상기 HTTP 응답은 상기 HTTP 데이터의 상태를 나타내는 상태 코드(Status Code)를 포함할 수 있다.
상기 단계 S1322 내지 단계 1328은 상기 도 5의 단계 S522 내지 단계 S528과 동일하므로 설명을 생략하도록 한다.
상기 게이트웨이(200)로부터 요청한 데이터를 전송 받은 상기 클라이언트 디바이스 1(100)은 HTTP 프록시 서비스의 이용을 더 이상 하지 않는 경우, 쓰기 요청(Write request)을 통해서 상기 프로텍티드 값을 No로 변경할 것을 상기 게이트웨이(200)에게 요청할 수 있다(S1330).
상기 프로텍티드 값의 변경을 요청 받은 상기 게이트웨이(200)는 상기 프로텍티드 값을 No로 변경한 뒤, 이에 대한 응답을 상기 클라이언트 디바이스 1(100)에게 전송할 수 있다.
상기 프로텍티드 값은 상기 클라이언트 디바이스 1(100)의 요청 외에도 일정 시간 동안 상기 클라이언트 디바이스 1(100)의 동작이 없는 경우 변경될 수 있다.
상기 게이트웨이(200)는 상기 프로텍티드 값이 변경된 경우(Yes에서 No로) 이를 통지(Notification) 또는 지시(Indication)을 통해서 연결된 다른 클라이언트 디바이스들에게 알릴 수 있다(S1332).
상기 프로텍티드 값이 No인경우, 다수의 클라이언트 디바이스로부터 HTTP 프록시 서비스의 요청이 들어올 수 있으나, 동시에 요청이 들어온 경우 데이터가 파손되어 요청을 다시 전송해야 한다.
상기 도 12 및 상기 도 13에 제시한 방법을 통해서 상기 HTTP 프록시 서비스를 클라이언트 디바이스가 이용하고 있지 여부를 미리 알 수 있다.
따라서, 서로 다른 클라이언트 디바이스가 HTTP 프록시 서비스를 요청함으로써 발생할 수 있는 문제점, 예를 들어, 이미 전송한 Characteristic을 유지할 수 없거나, 불필요한 절차나 동작을 수행함으로써 발생하는 딜레이, 부정확한 정보의 전달 등을 해결할 수 있다.
또한, 상기 문제점을 해결함으로써 원활하고 효율적인 HTTP 프록시 서비스를 제공할 수 있다.
도 14은 본 발명이 적용되는, 보안 기능을 활성화/비활성화 시키는 일 예를 나타낸 도이다.
상기 도 14를 참고하면 HTTPS 보안(HTTPS Security) characteristic 값을 클라이언트 디바이스에서 쓰기 요청을 통해 직접 변경요청을 할 수 있다.
아래 표 5는 상기 [표 1]과는 다른 HTTP 프록시 서비스(HTTP Proxy Service)의 Characteristic의 또 다른 일 예를 나타내고 있다.
표 5
Characteristic Name Requirement Mandatory Properties Optional Properties Security Permissions
URI M Read, Write Optional
HTTP Header M Read, Write Optional
HTTP Status Code M Notify, Indicate Optional
HTTP Entity Body M Read, Write Optional
HTTP L2CAP M Read Optional
HTTP Control Point M Write, Indicate Optional
HTTPS Sercurity M Read Optional
상기 [표 5]는 상기 [표 1]과 HTTPS Security가 Read 뿐만 아니라 Write도 가능하다는 것을 볼 수 있다.
이는 게이트웨이에서 상기 HTTPS Security 값이 변경된 것을 통지할 수 있을 뿐만 아니라, 클라이언트 디바이스가 직접 상기 게이트웨이에게 상기 HTTPS Security 값의 변경을 요청할 수 있다는 것을 나타낸다.
이를 상기 도 14를 참고해서 구체적으로 살펴보면, 상기 클라이언트 디바이스 1(100)은 쓰기 요청을 통해서 상기 게이트웨이(100)에게 상기 HTTPS 보안(HTTPS Sercurity)값을 Yes로 변경할 것을 요청할 수 있다(S1410).
상기 쓰기 요청을 받은 상기 게이트웨이(200)는 상기 HTTPS 보안(HTTPS Security)값을 Yes로 변경한 뒤, 이에 대한 응답 메시지를 상기 클라이언트 디바이스 1(100)에게 전송할 수 있다.
이하, 단계 S1412 내지 단계 S1416은 상기 도 5의 단계 S510 내지 단계 S514와 동일하므로 설명을 생략하도록 한다.
상기 클라이언트 디바이스 1(100)은 HTTP 컨트롤 포인트 Characteristic을 통해서 상기 게이트웨이(200)에게 HTTPS PUT Request 메시지의 전송을 요청할 수 있으며(S1418), 상기 게이트웨이(200)는 이에 대한 응답을 상기 클라이언트 디바이스 1(100)에게 전송할 수 있다.
상기 클라이언트 디바이스 1(100)의 요청에 따라, 상기 게이트웨이(200)는 HTTPS PUT 요청 메시지를 웹 서버(400)로 전송할 수 있다(S1420). 상기 HTTPS PUT 요청 메시지는 HTTP 요청과 관련된 정보, 즉 상기 클라이언트 디바이스 1(100)로부터 전송 받은 정보(URI, HTTP 헤더, HTTP 엔터티 바디)를 포함할 수 있다.
상기 웹 서버(400)는 상기 HTTPS PUT 요청 메시지에 대한 응답으로 HTTPS PUT 응답을 수신할 수 있다(S1422). 상기 HTTPS PUT 응답 메시지는 상기 클라이언트 디바이스 1(100)이 요청한 HTTP 데이터 및/또는 상기 HTTP 데이터의 상태를 나타내는 상태 코드(Status Code)를 포함할 수 있다.
상기 클라이언트 디바이스 1(100)은 다시 HTTPS 보안(HTTPS Security) 기능을 사용하지 않으려면 상기 HTTPS 보안(HTTPS Security) Characteristic의 값을 No로 변경하면 된다.
즉, 상기 클라이언트 디바이스 1(100)은 쓰기 요청을 통해서 상기 게이트웨이(200)에게 상기 HTTPS 보안(HTTPS Security) Characteristic의 값을 No로 변경할 것을 요청할 수 있다(S1424).
상기 쓰기 요청을 받은 상기 게이트웨이(200)는 이에 대한 응답 메시지를 상기 클라이언트 디바이스 1(100)에게 전송할 수 있다.
이하 S1426 단계 내지 S 1430 단계는 상기 도 5의 단계 S510 내지 단계 S514와 동일하므로 설명을 생략하도록 한다.
이후, 상기 클라이언트 디바이스 1(100)은 HTTP 컨트롤 포인트 Characteristic을 통해서 상기 게이트웨이(200)에게 HTTP PUT Request의 전송을 요청할 수 있으며(S1432), 상기 게이트웨이(200)는 이에 대한 응답을 상기 클라이언트 디바이스 1(100)에게 전송할 수 있다.
상기 클라이언트 디바이스 1(100)의 요청에 따라, 상기 게이트웨이(200)는 HTTP PUT 요청 메시지를 웹 서버(400)로 전송할 수 있다(S1434). 상기 HTTPS PUT 요청 메시지는 HTTP 요청과 관련된 정보, 즉 상기 클라이언트 디바이스 1(100)로부터 전송 받은 정보(URI, HTTP 헤더, HTTP 엔터티 바디)를 포함할 수 있다.
상기 웹 서버(400)는 상기 HTTP PUT 요청 메시지에 대한 응답으로 HTTP PUT 응답 메시지를 수신할 수 있다(S1436). 상기 HTTP PUT 응답 메시지는 상기 클라이언트 디바이스 1(100)이 요청한 HTTP 데이터 및/또는 상기 HTTP 데이터의 상태를 나타내는 상태 코드(Status Code)를 포함할 수 있다.
위와 같은 방법을 통해서 상기 게이트웨이(200)뿐만 아니라 클라이언트 디바이스에서 직접 상기 HTTP 보안(HTTP Security) Characteristic 값의 변경을 요청할 수 있다.
Body Length Characteristic
아래 표 6는 HTTP 프록시 서비스(HTTP Proxy Service)의 Characteristic의 또 다른 일 예를 나타내고 있다.
표 6
Characteristic Name Requirement Mandatory Properties Optional Properties Security Permissions
URI M Read, Write Optional
HTTP Header M Read, Write Optional
HTTP Status Code M Notify, Indicate Optional
HTTP Entity Body M Read, Write Optional
HTTP L2CAP M Read Optional
HTTP Control Point M Write, Indicate Optional
HTTPS Sercurity M Read Optional
Body Length Read, Write,Indication/Notification
상기 표 6의 Body Length Characteristic은 HTTP Entity Body 또는 HTTP Header의 길이와 관련된 정보를 포함할 수 있다. 이는, 쓰기 요청(Write Request)를 통해 클라이언트 디바이스가 쓸 데이터 길이(Data length) 정보를 게이트웨이에게 알려주거나, 읽기 요청(Read request)을 통해서 상기 클라이언트 디바이스가 게이트웨이로부터 읽어올 데이터 길이(Data length) 정보를 알 수 있다.
또는, 상기 게이트웨이가 HTTP 프록시 서비스를 이용하는 클라이언트 디바이스에게 통지(Notification) 또는 지시(Indication)을 통해서 알려줄 수 있다.
상기 클라이언트 디바이스는, 상기 데이터 길이 Characteristic 값이 0이거나, 비어 있는 경우 상기 게이트웨이로부터 읽어올 데이터가 없다는 것을 알 수 있으며, 상기 데이터 길이 Characteristic 값이 0이외의 값인 경우 읽어올 데이터가 HTTP header 또는 HTTP Entity Body에 있다는 것을 알 수 있다.
또한, 상기 클라이언트가 쓰기 요청(Write request)를 통해서 상기 게이트웨이에 요청한 데이터의 길이보다 읽기 요청(Read request), 통지(Notification) 또는 지시(Indication)을 통해서 알게된 데이터 길이(Data length) 가 더 작은 경우, 웹 서버로부터 수신된 데이터의 일부만 전송되었다는 것을 알 수 있다.
도 15는 본 발명이 적용되는, 데이터 크기에 따라서 전송 방식을 달리하는 일 예를 나타낸 도이다.
상기 도 15를 참조하면, 클라이언트 디바이스는 게이트웨이로부터 전송될 데이터 길이 정보를 제공 받을 수 있으며, 상기 데이터 길이 정보에 따라 전송 방식을 달리할 수 있다.
이를 구체적으로 살펴보면, 상기 클라이언트 디바이스는 상기 게이트웨이로부터 전송될 데이터 길이와 관련된 정보를 읽기 요청(read request), 통지(Notification) 또는 지시(Indication)을 통해서 획득할 수 있다(S1510).
상기 클라이언트 디바이스는 상기 획득한 데이터 길이 정보를 통해서 게이트 웨이로부터 전송될 데이터 길이(또는, 크기)를 알 수 있다.
상기 클라이언트 디바이스는 상기 데이터 길이 정보를 통해서 상기 데이터 길이가 0인 여부를 알 수 있으며(S1512), 상기 데이터 길이가 0인 경우, 상기 게이트웨이로부터 전송될 데이터가 존재하지 않음을 알 수 있다(S1514). 즉, 상기 게이트웨이가 웹 서버로부터 데이터를 전송 받지 못하여 전송할 데이터가 존재하지 않음을 알 수 있다.
상기 데이터 길이 정보가 0이 아닌 경우, 상기 클라이언트 디바이스는 상기 획득한 데이터 길이를 ATT_MTU-2 값과 비교할 수 있다(S1516). 상기 ATT_MTU-2 값은 읽기 요청 서브 절차(Read Request Sub Procedure)를 통해서 한번에 수신할 수 있는 최대 데이터 길이를 나타낸다.
상기 비교결과 데이터 길이가 ATT_MTU-2 값과 동일하거나 작은 경우 상기 클라이언트 디바이스는 읽기 요청 서브 절차(Read Request Sub Procedure)를 통해서 데이터를 수신할 수 있다(S1520).
하지만, 상기 데이터 길이 값이 상기 ATT_MTU-2 값보다 큰 경우 상기 클라이언트 디바이스는 다시 최대 ATT 데이터 길이(Max Attribute Protocol Data Length)와 상기 데이터 길이를 비교할 수 있다(S1522).
비교 결과, 상기 데이터 길이가 상기 최대 ATT데이터 길이 값과 동일하거나 작은 경우, 읽기 블럽 요청(Read Blob Request)를 통해서 데이터를 수신할 수 있다(S1524).
상기 읽기 블럽 요청(Read Blob Request)는 한번에 데이터를 전부 전송할 수 없는 경우, 데이터를 나누어 전송하는 방법을 말한다. 이는 도 16에서 설명하도록 한다.
하지만, 상기 데이터 길이 값이 상기 최대 ATT 데이터 길이 값을 초과하는 경우, 예를 들어, 상기 데이터 길이 값이 상기 최대 데이터 길이 값인 512byte를 초과하는 경우 상기 클라이언트 디바이스는 L2CAP 채널을 통해서 상기 데이터를 수신할 수 있다(S1526).
이와 같이, 전송하려는 데이터의 길이, 예를 들면, HTTP header 또는 HTTP Entity Body의 길이를 읽기 요청(read request), 통지(Notification) 또는 지시(Indication)를 통해 알려줌으로써, 미리 전송 방법을 선택해서 효율적으로 데이터를 전송 받을 수 있다.
Read Blob Request
도 16는 본 발명이 적용되는, 블루투스 데이터 전송 방법의 일 예를 나타낸 도이다.
상기 도 16을 참고하면, 데이터 길이가 ATT_MTU-2 값을 초과하는 경우 읽기 요청(Read request)를 통해서 한번에 데이터를 수신할 수 없다. 이 경우, 데이터를 연속적으로 수신함으로써, 전체 데이터를 전송 받을 수 있다.
이를 구체적으로 살펴보면, 상기 클라이언트 디바이스 1(100)은 읽기 요청(Read request)을 통해서 상기 게이트웨이(200)에게 데이터 전송을 요청할 수 있다(S1610).
상기 읽기 요청을 받은 게이트웨이(200)는 상기 클라이언트가 요청한 데이터를 읽기 응답을 통해서 전송할 수 있다(S1612).
하지만, 전송해야 하는 데이터의 길이가 상기 ATT_MTU-2 값을 초과하는 경우 상기 클라이언트 디바이스는 한번에 상기 데이터를 모두 전송할 수 없다. 따라서 상기 게이트 웨이(200)는 데이터를 나누어 전송할 수 있다.
예를 들면, 전송해야 되는 데이터가 “블루투스 HTTP 데이터 전송 방법”이고, 한번에 전송할 수 있는 길이를 “블루투스 HTTP”라고 하자.
이 경우, 상기 클라이언트 디바이스 1(100)은 읽기 응답(Read Response)을 통해서 “블루투스 HTTP”라는 데이터를 수신할 수 있다(S1612).
하지만, 아직 데이터가 전부 전송된 것이 아니므로 상기 클라이언트 디바이스 1(100)은 상기 게이트웨이(200)에게 읽기 블럽 요청(Read Blob Request)를 전송한다(S1614).
상기 읽기 블럽 요청을 수신한 상기 게이트웨이는 전송한 데이터의 다음인 “데이터 전송”을 읽기 응답(Read Response)를 통해서 상기 클라이언트 디바이스 1(100)에게 전송한다(S1616).
하지만, 아직 데이터가 전부 전송된 것은 아니므로 상기 클라이언트 디바이스 1(100)은 다시 상기 게이트웨이(200)에게 읽기 블럽 요청(Read Blob Request)를 전송하게 되고 상기 게이트웨이(200)는 나머지 데이터 부분인 “방법”을 읽기 응답(Read Response)를 통해서 상기 클라이언트 디바이스 1(100)에게 전송한다.
이와 같은 방법을 통해서 길이가 긴 데이터의 경우도 상기 클라이언트 디바이스 1(100)은 상기 게이트웨이(200)로부터 전송 받을 수 있다.
도 17 및 도 18은 본 발명이 적용되는, HTTP 데이터 전송 시, 데이터 길이를 알려주는 방법의 예를 나타낸 도이다.
상기 도 17을 참조하면, 읽기 요청(Read Request)을 통해서 상기 클라이언트 디바이스는 전송되는 엔티디 바디 길이를 알 수 있다.
단계 S1710 내지 단계 S1720 는 상기 도 14의 단계 S1412 내지 단계 S1422와 동일하므로 설명을 생략하도록 한다.
이후, 상기 게이트웨이(200)는 상기 클라이언트 디바이스 1(100)로 상태코드를 포함하고 있는 지시(Indication) 메시지를 전송한다(S1722). 이를 통해 상기 클라이언트 디바이스는 상기 게이트웨이(200)가 요청한 데이터를 정확히 수신하였는지, 수신하지 못하였는지, 불완전하게 수신하였는지 알 수 있다.
상기 클라이언트 디바이스 1(100)은 상기 지시(Indication) 메시지에 대한 응답으로 확인 메시지(Confirm message)를 상기 게이트웨이(200)에게 전송할 수 있다.
상기 클라이언트 디바이스(100)는 읽기 요청(read request)을 통해 상기 게이트 웨이(200)로 상기 게이트웨이가 상기 웹 서버(400)로부터 수신한 정보를 요청할 수 있다.
즉, 상기 클라이언트 디바이스(100)는 상기 게이트웨이(200)로 읽기 요청(Read Request)를 전송하여 URI를 전송 받을 수 있으며(S1724), 다시 읽기 요청을 통하여 HTTP 헤더를 전송 받을 수 있다(S1726).
그 후, 상기 클라이언트는 전송될 HTTP 엔터티 바디(HTTP Entity Body)의 길이 정보를 읽기 요청(Read Request)를 통해서 상기 게이트웨이(200)에게 요청할 수 있다(S1728).
상기 클라이언트 디바이스 1(100)은 수신된 HTTP 엔터티 바디의 길이 정보에 따라 상기 도 15에 도시된 방법인 Read Request Sub Procedure, Read Blob Request 또는 L2CAP 채널 중 하나를 사용해서 상기 HTTP 엔터티 바디를 수신할 수 있다(S1730).
상기 도 18을 참조하면, 상기 게이트웨이(200)는 데이터 길이 값을 상태코드(Status Code)에 포함시켜 통지(Notification) 또는 지시(Indication) 할 수 있다.
단계 S1810 내지 단계 S1820은 상기 도 17의 단계 S1710 내지 단계 S1720과 동일하므로 설명을 생략한다.
상기 게이트웨이(200)는 상기 웹 서버(400)로부터 데이터를 수신한 뒤, 지시(Indication) 또는 통지(Notification)를 통해서 상태코드와 수신된 데이터의 길이 정보를 상기 클라이언트 디바이스 1(100)에게 알려 줄 수 있다(S1822).
상기 상태코드는 상기 게이트웨이(200)가 상기 웹 서버(400)로부터 데이터를 수신하였는지 여부를 나타낼 수 있으며, 상기 데이터 길이정보는 상기 웹 서버(400)로부터 수신된 데이터의 길이(또는, 크기)를 나타낼 수 있다.
상기 데이터 길이정보는 상기 상태코드와 같이 상기 지시(Indication) 또는 상기 통지(Notification)을 통해서 상기 클라이언트 디바이스 1(100)에게 전송될 수 있다.
또는, 상기 상태코드에 포함되어 상기 지시(Indication) 또는 상기 통지(Notification)을 통해서 상기 클라이언트 디바이스 1(100)에게 전송될 수 있다.
이 경우, 만일 상기 게이트웨이(200)가 상기 지시 메시지(Indication message)를 상기 클라이언트 디바이스 1(100)에게 전송한 경우, 상기 클라이언트 디바이스 1(100)은 이에 대한 응답으로 확인 메시지(Confirm message)를 상기 게이트웨이(200)에게 전송할 수 있다.
아래 표 7은 HTTP Status code의 일 예를 나타낸다.
표 7
Status Code Length
Octet Order LSO MSO
Format Type Unsigned Integer Unsigned Integer
Size 2 Octet Over 2 Octets
상기 클라이언트 디바이스 1(100)은 상기 HTTP Status code에 포함되거나 함께 전송된 상기 데이터 길이 정보(data length information)통해서 수신되는 데이터, 즉 HTTP header 또는 HTTP Entity Body에 포함된 데이터의 길이에 대한 정보를 획득할 수 있다.
예를 들면, 상기 클라이언트 디바이스 1(100)은, 상기 길이에 대한 값이 0이거나, 비어 있는 경우 상기 게이트웨이(200)로부터 읽어올 데이터가 없다는 것을 알 수 있으며, 상기 길이에 대한 값이 0이외의 값을 나타내는 경우 읽어올 데이터가 HTTP header 또는 HTTP Entity Body에 있다는 것을 알 수 있다.
또한, 상기 클라이언트가 쓰기 요청(Write request)를 통해서 상기 게이트웨이에 요청한 데이터의 길이보다 통지(Notification) 또는 지시(Indication)에 포함된 Status Code를 통해서 알게 된 길이(length) 값이 더 작은 경우, 웹 서버로부터 수신된 데이터의 일부만 전송되었다는 것을 알 수 있다.
또 다른 예로, 상기 데이터 길이 정보는 1 또는 0의 값을 가질 수 있으며, 상기 데이터 길이 정보가 0일 경우, 상기 웹 서버(400)로부터 데이터를 전송 받지 못하여 데이터가 존재하지 않는다는 것을 나타낼 수 있으며, 상기 데이터 길이 정보가 1인 경우에는 상기 웹 서버(400)로부터 데이터를 전송 받았다는 것을 나타낼 수 있다.
상기 데이터 길이 정보의 크기는 1 옥텟(Octet)의 크기를 가질 수 있으며, 상기 옥텟 값의 비트(bit) 연산에 따라 전송된 데이터 상태를 나타낼 수 있다.
예를 들면, 첫 번째 비트가 1인 경우 헤더에 데이터가 존재함을 나타낼 수 있으며, 두 번째 비트가 1인 경우 전송 된 헤더의 데이터가 최대 전송 크기(예를 들면, 512byte)를 초과한 것을 나타낼 수 있다.
또한, 세 번째 비트가 1인 경우 전송된 바디(body)에 데이터가 존재함을 나타낼 수 있으며, 네 번째 비트가 1인 경우 상기 전송 된 바디의 데이터가 최대 전송 크기(예를 들면, 512byte)를 초과한 것을 나타낼 수 있다.
여기서, 상기 첫 번째 비트와 세 번째 비트의 값이 0인 경우에는 각각 헤더와 바디에 데이터가 존재하지 않는다는 것을 나타낼 수 있다.이하, 단계 S1824 내지 단계 S1830는 상기 도 5의 단계 S524 내지 단계 S528과 동일하거나, 상기 도 17의 단계 S1726 내지 단계 S1730과 동일한바, 설명을 생략하도록 한다.
상기 도 19는 본 발명이 적용되는, 서비스 제공 도중 에러가 발생하는 경우, 에러 코드를 전송하는 일 예를 나타내는 흐름도이다.
상기 도 19를 참조하면, 블루투스 오브젝트 트랜스퍼 서비스(Bluetooth Object Transfer Service)에서 서버(Server)가 클라이언트(Client)에게 서비스 제공 도중 에러가 발생한 경우 이를 상기 클라이언트에게 알려줄 수 있다.
상기 오브젝트 트랜스퍼 서비스(Object Transfer Service)는 오브젝트 딜리버리 서비스(Object Delivery Service)라고 호칭될 수 있다.
이를 구체적으로 살펴보면, 상기 서버(1900)는 애드버타이징 채널(Advertising Channel)을 통해서 상기 클라이언트(1910)에게 오브젝트 딜리버리 서비스를 제공할 수 있음을 알릴 수 있다(S1912).
블루투스(Bluetooth)에서는 정보를 전송하기 위한 물리채널(Physical Channel)로는 애드버타이징 채널(Advertising Channel)과 데이터 채널(Data Channel)로 나누어 지며, 상기 애드버타이징 채널(Advertising Channel)은 3개의 채널이, 상기 데이터 채널(Data Channel)은 37개의 채널이 존재할 수 있다.
상기 애드버타이징 채널(Advertising Channel)은 주변의 클라이언트에게 페어링(Pairing)을 위한 정보를 제공할 수 있다. 예를 들면, 상기 서버(1900)는 상기 애드버타이징 채널(Advertising Channel)을 통해서 상기 서버(1900)가 오브젝트 딜리버리 서비스(Object Delivery Service)를 제공할 수 있음을 주변의 클라이언트들에게 알려줄 있다(S1912).
이때, 클라이언트(1910)는 상기 오브젝트 딜리버리 서비스(Object Delivery Service)를 제공 받으려는 디바이스인 경우, 상기 서버(1900)에게 페어링(Pairing)을 위한 연결 요청을 전송한다(S1914).
그 후, 상기 클라이언트(1910)는 상기 오브젝트 딜리버리 서비스(Object Delivery Service)가 제공하는 현재 오브젝트(Object) 정보를 제공받기 위해 오브젝트 이름(Object Name)에 대한 정보를 읽기 요청(Read Request)를 통해서 상기 서버에게 요청할 수 있다(S1916).
이에 대한 응답으로 상기 서버(1900)는 상기 오브젝트 딜리버리 서비스(Object Delivery Service)가 현재 제공하는 오브젝트(Object)의 이름(Name)을 읽기 응답(Read Response)을 통해서 상기 클라이언트에게 전송할 수 있다(S1918).
상기 오브젝트 이름을 전송 받은 상기 클라이언트(1910)는 다음 오브젝트의 정보를 얻기 위해서 오브젝트 변경을 위한 오브젝트 리스트 컨트롤 포인트(Object list Control Point)를 상기 서버(1900)에게 전송하여, 상기 현재 오브젝트를 상기 다음 오브젝트로 변경을 요청할 수 있다(S1920).
하지만, 상기 서버(1900)가 다음 오브젝트에 대한 정보를 생성할 수 없는 경우(S1922), 상기 클라이언트(1910)에게 에러코드를 전송함으로써 이를 알려줄 수 있다(S1924).
상기 서버(1900)는 상기 서버(1900)의 자원(Resource), 예를 들면 CPU의 파워(CPU Poewr), 메모리 자원(Memory)의 부족 등의 원인으로 인하여 새로운 오브젝트에 대한 정보를 생성하지 못할 수 있다.
상기 에러 코드의 예를 들면 아래 표 8의 에러코드를 전송할 수 있다.
표 8
Name Error code Description
Concurrency Limit Exceeded 0x83 The server is unable to service the Read Request or Write Request because it exceeds the cuncurrency limit of the service
이와 같은 방법을 이용해서, 상기 서버(1900)는 클라이언트(1910)에게 에러가 발생한 이유를 알려 줄 수 있다.
이상에서 설명한 본 발명은, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 있어 본 발명의 기술적 사상을 벗어나지 않는 범위 내에서 여러 가지 치환, 변형 및 변경이 가능하므로 전술한 실시예 및 첨부된 도면에 의해 한정되는 것이 아니다.
본 명세서는 무선 통신 시스템을 이용하여 데이터를 송수신 하는 방법 및 장치를 제공한다. 특히 근거리 무선 통신 기술인 블루투스를 통해서, 웹 서버와 HTTP 데이터를 전송 및 수신하기 위한 방법 및 장치를 제공한다.

Claims (20)

  1. 무선 통신시스템에서 블루투스(Bluetooth) 통신을 이용하여 웹 서버와 데이터를 송수신하기 위한 방법에 있어서, 게이트웨이(Gateway)에 의해 수행되는 방법은,
    제1 클라이언트 디바이스로부터 HTTP(Hyper Text Transfer Protocol) 요청 관련 정보를 포함하는 제1 쓰기 요청(write request)을 수신하는 단계;
    상기 수신된 제1 쓰기 요청에 포함된 정보를 기초로 생성된 HTTP 요청 관련 정보를 웹 서버로 전송하는 단계;
    상기 웹 서버로부터 상기 HTTP 요청 관련 정보에 대한 응답으로 HTTP 응답 메시지를 수신하는 단계;
    상기 수신된 HTTP 응답 메시지에 포함된 데이터의 상태를 나타내는 HTTP 상태 코드(HTTP Status Code)를 상기 제1 클라이언트 디바이스에게 통지(Notifying)하는 단계; 및
    상기 제1 클라이언트 디바이스로부터 상기 HTTP 상태 코드(HTTP Status Code)에 포함된 정보에 기초하여 데이터 전송을 요청하는 읽기 요청(read request)을 수신하는 단계를 포함하되,
    상기 제1 쓰기 요청(write request)을 수신하는 중 다른 클라이언트 디바이스로부터 제2 쓰기 요청(write request)을 수신한 경우, 상기 다른 클라이언트 디바이스에게 에러 응답(error response)를 전송하는 것을 특징으로 하는 방법.
  2. 제 1항에 있어서,
    상기 에러 응답(error response)은 상기 게이트웨이가 상기 제1 클라이언트 디바이스와 상기 HTTP 요청 관련 정보 생성을 위한 동작을 수행하고 있음을 나타내거나, 상기 게이트웨이가 상기 HTTP 요청 관련 정보를 생성하기 위한 동작을 수행하고 있어 자원이 충분하지 못함을 나타내는 것을 특징으로 하는 방법.
  3. 제 1에 있어서, 상기 제1 쓰기 요청(write request)을 수신하는 단계는,
    상기 제1 클라이언트 디바이스로부터 URI(Universal Resource Identifier) 쓰기 요청을 수신하는 단계;
    상기 제1 클라이언트 디바이스에게 상기 수신된 URI 쓰기 요청에 대한 응답으로 URI 쓰기 응답(write response)을 전송하는 단계;
    상기 제1 클라이언트 디바이스로부터 HTTP 헤더 쓰기 요청(HTTP Header write request)을 수신하는 단계;
    상기 제1 클라이언트 디바이스에게 상기 수신된 HTTP 헤더 쓰기 요청(HTTP Header write request)에 대한 응답으로 HTTP 헤더 쓰기 응답(HTTP Header write response)을 전송하는 단계;
    상기 제1 클라이언트 디바이스로부터 HTTP 엔터티 바디 쓰기 요청(Entity Body write request)을 수신하는 단계;
    상기 제1 클라이언트 디바이스에게 상기 수신된 HTTP 엔터티 바디 쓰기 요청(Entity Body write request)에 대한 응답으로 HTTP 엔터티 바디 쓰기 응답(HTTP Entity Body response)을 전송하는 단계;
    상기 제1 클라이언트 디바이스로부터 상기 HTTP 요청 메시지(HTTP request message)와 관련된 특정 동작을 지시하는 HTTP 컨트롤 포인트 요청(HTTP Control Point request)을 수신하는 단계; 및
    상기 제1 클라이언트 디바이스에게 상기 수신된 HTTP 컨트롤 포인트 요청(HTTP Control Point request)에 대한 응답으로 HTTP 컨트롤 포인트 응답(HTTP Control Point response)을 전송하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  4. 제 1항에 있어서, 상기 읽기 요청(read request)을 수신하는 단계는,
    상기 제1 클라이언트 디바이스로부터 HTTP 헤더 읽기 요청(Header read request)을 수신하는 단계;
    상기 제1 클라이언트 디바이스에게 HTTP 헤더 읽기 요청(Header read request)에 대한 응답으로 HTTP 헤더 읽기 응답(HTTP Header read response)을 전송하는 단계;
    상기 제1 클라이언트 디바이스로부터 HTTP 엔터티 바디 읽기 요청(HTTP Entity Body read request)을 수신하는 단계; 및
    상기 제1 클라이언트 디바이스에게 HTTP 엔터티 바디 읽기 요청(HTTP Entity Body read request)에 대한 응답으로 HTTP 엔터티 바디 읽기 응답(HTTP Entity Body read response)을 전송하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  5. 제 1항에 있어서, 상기 데이터는,
    상기 웹 서버로부터 수신된, 헤더 또는 엔터티 바디 중 적어도 하나를 포함하는 것을 특징으로 하는 방법.
  6. 제 1항에 있어서, 상기 HTTP 상태 코드(HTTP Status Code)는,
    데이터 길이와 관련된 정보를 포함하는 것을 특징으로 하는 방법.
  7. 제 1항에 있어서, 상기 HTTP 상태 코드(HTTP Status Code)는,
    데이터 길이와 관련된 정보와 함께 통지(Notify) 되는 것을 특징으로 하는 방법.
  8. 제 6항 또는 제 7항에 있어서,
    상기 데이터 길이와 관련된 정보는, 0 또는 1의 값을 포함하며,
    상기 데이터 길이와 관련된 정보가 1인 경우, 상기 데이터가 수신되었음을 나타내는 것을 특징으로 하는 방법.
  9. 제 6항 또는 제 7항에 있어서, 상기 데이터 길이와 관련된 정보는 데이터 길이를 포함하며,
    상기 데이터의 길이가 ATT_MTU-2 값과 동일하거나 작은 경우, read request 절차를 통해서 상기 데이터를 상기 제1 클라이언트 디바이스에게 전송하되,
    상기 ATT_MTU-2 값은 read request 절차를 통해서 한번에 전송할 수 있는 최대 데이터의 길이를 나타내는 것을 특징으로 하는 방법.
  10. 제 6항 또는 제 7항에 있어서, 상기 데이터 길이와 관련된 정보는 데이터 길이를 포함하며,
    상기 데이터의 길이가 ATT_MTU-2 값을 초과하고, 최대 ATT 데이터 길이(Max ATT Data Length)와 동일하거나 작은 경우, read blob request 절차를 통해서 상기 데이터를 상기 제1 클라이언트 디바이스에게 전송하되,
    상기 최대 ATT 데이터 길이는 Attribute Protocol을 통해서 전송할 수 있는 데이터의 최대 크기를 나타내는 것을 특징으로 하는 방법.
  11. 제 6항 또는 제 7항에 있어서, 상기 데이터 길이와 관련된 정보는 데이터 길이를 포함하며
    상기 데이터의 길이가 최대 ATT 데이터 길이(Max ATT Data Length)를 초과하는 경우, L2CAP CoC(Logical Link Control and Adaptation Protocol Connection Oriented Channel)을 통해서 상기 데이터를 상기 제1 클라이언트 디바이스에게 전송하는 것을 특징으로 하는 방법.
  12. 제 1항에 있어서,
    상기 제1 클라이언트 디바이스로부터 클라이언트 ID 값을 요청하는 요청 메시지를 수신하는 단계;
    상기 요청 메시지에 대한 응답으로 응답 메시지를 전송하는 단계; 및
    상기 클라이언트 ID 값이 NULL인 경우, 상기 제1 클라이언트 디바이스로부터 상기 클라이언트 ID 값을 제1 클라이언트 디바이스 정보로 변경을 요청하는 변경 요청 메시지를 수신하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  13. 제 12항에 있어서,
    상기 제1 클라이언트 디바이스 정보는 사용자 ID 또는 상기 제1 클라이언트 디바이스의 ID 중 적어도 어느 하나를 포함하는 것을 특징으로 하는 방법.
  14. 제 12항에 있어서,
    상기 변경된 클라이언트 ID를 상기 게이트웨이와 연결된 다른 클라이언트 디바이스들에게 통지(Notifying)하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  15. 제 12항에 있어서,
    상기 변경된 클라이언트 ID는 상기 제1 클라이언트의 요청 또는 특정 시간이 경과된 후에 NULL로 변경되는 것을 특징으로 하는 방법.
  16. 제 1항에 있어서,
    상기 제1 클라이언트 디바이스로부터 다른 클라이언트의 사용여부를 나타내는 프로텍티드(Protected) 값을 요청하는 요청 메시지를 수신하는 단계;
    상기 요청 메시지에 대한 응답으로 응답 메시지를 전송하는 단계; 및
    상기 프로텍티드 값이 No인 경우, 상기 제1 클라이언트 디바이스로부터 상기 프로텍티드 값의 변경을 요청하는 요청 메시지를 수신하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  17. 제 16항에 있어서,
    상기 변경된 프로텍티드 값을 상기 게이트웨이와 연결된 다른 클라이언트 디바이스들에게 통지(Notifying)하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  18. 제 16항에 있어서,
    상기 변경된 프로텍티드 값은 상기 제1 클라이언트의 요청 또는 특정 시간이 경과된 후에 No로 변경되는 것을 특징으로 하는 방법.
  19. 무선 통신시스템에서 블루투스(Bluetooth) 통신을 이용하여 데이터를 송수신하기 위한 방법에 있어서, 클라이언트 장치(Client Device)에 의해 수행되는 방법은,
    상기 서버에게 제1 오브젝트와 관련된 정보를 요청하기 위해 읽기 요청(Read Request)을 전송하는 단계;
    상기 서버로부터 상기 읽기 요청(Read Request)에 대한 응답으로 상기 제1 오브젝트(first Object)와 관련된 정보가 포함된 읽기 응답을 수신하는 단계;
    상기 서버에게 상기 제 1오브젝트를 제 2오브젝트로 변경하기 위한 메시지를 전송하는 단계; 및
    상기 서버로부터 제 2오브젝트와 관련된 에러 코드를 수신하는 단계를 포함하되,
    상기 에러코드는 상기 서버의 자원이 충분하지 않은 것을 나타내는 것을 특징으로 하는 방법.
  20. 무선 통신시스템에서 블루투스(Bluetooth) 통신을 이용하여 웹 서버와 데이터를 송수신하기 위한 방법에 있어서, 게이트웨이(Gateway)는,
    외부와 유선 및/또는 무선으로 신호를 송수신하기 위한 통신부; 및
    상기 통신부와 기능적으로 연결되는 제어부를 포함하되, 상기 제어부는,
    제1 클라이언트 디바이스로부터 HTTP(Hyper Text Transfer Protocol) 요청 관련 정보를 포함하는 제1 쓰기 요청(write request)을 수신하고,
    상기 수신된 제1 쓰기 요청에 포함된 정보를 기초로 상기 HTTP 요청 관련 정보를 생성하며,
    상기 생성된 HTTP 요청 관련 정보를 웹 서버로 전송하고,
    상기 웹 서버로부터 상기 HTTP 요청 관련 정보에 대한 응답으로 HTTP 응답 메시지를 수신하며,
    상기 수신된 HTTP 응답 메시지에 포함된 데이터의 상태를 나타내는 HTTP 상태 코드(Status Code)를 상기 제1 클라이언트 디바이스에게 통지하고,
    상기 제1 클라이언트 디바이스로부터 상기 HTTP 상태 코드(Status Code)에 포함된 정보에 기초하여 데이터 전송을 요청하는 읽기 요청(read request)을 수신하되,
    상기 제1 쓰기 요청(write request)를 수신하는 중 다른 클라이언트 디바이스로부터 제2 쓰기 요청(write request)을 수신한 경우, 상기 다른 클라이언트 디바이스에게 에러 응답(error response)을 전송하는 것을 특징으로 하는 장치.
PCT/KR2014/009694 2014-04-21 2014-10-15 무선 통신시스템에서 블루투스를 이용하여 http 데이터를 전송하기 위한 방법 및 장치 WO2015163547A1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR1020167029187A KR101990489B1 (ko) 2014-04-21 2014-10-15 무선 통신시스템에서 블루투스를 이용하여 http 데이터를 전송하기 위한 방법 및 장치
US15/305,964 US9961481B2 (en) 2014-04-21 2014-10-15 Method and apparatus for transmitting a HTTP data using bluetooth in wireless communication system

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201461982292P 2014-04-21 2014-04-21
US61/982,292 2014-04-21
US201462019853P 2014-07-01 2014-07-01
US62/019,853 2014-07-01

Publications (1)

Publication Number Publication Date
WO2015163547A1 true WO2015163547A1 (ko) 2015-10-29

Family

ID=54332687

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2014/009694 WO2015163547A1 (ko) 2014-04-21 2014-10-15 무선 통신시스템에서 블루투스를 이용하여 http 데이터를 전송하기 위한 방법 및 장치

Country Status (3)

Country Link
US (1) US9961481B2 (ko)
KR (1) KR101990489B1 (ko)
WO (1) WO2015163547A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017112120A1 (en) * 2015-12-23 2017-06-29 Intel Corporation Method, system and apparatus for communication through wireless charging network
WO2021215553A1 (ko) * 2020-04-22 2021-10-28 엘지전자 주식회사 자율주행시스템에서 차량의 데이터 전송방법

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11423165B2 (en) * 2017-05-18 2022-08-23 NeuShield, Inc. Computer-implemented methods and system for preventing unauthorized file modification by malicious software and the like
US10326804B1 (en) * 2018-05-03 2019-06-18 T-Mobile Usa, Inc. Reducing network protocol overhead
US11212368B2 (en) * 2019-05-17 2021-12-28 Netflix, Inc. Fire-and-forget offload mechanism for network-based services
US11991537B2 (en) * 2021-06-21 2024-05-21 Blackberry Limited Method and system for cloud extended attribute profile

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20020081183A (ko) * 2002-09-09 2002-10-26 이민수 블루투스 통신을 이용한 이동통신기기의 결제서비스시스템 및 그 방법
KR20030010002A (ko) * 2001-07-25 2003-02-05 주식회사 비즈모델라인 블루투스를 이용한 무선 결제 방법
US20060039348A1 (en) * 2004-08-20 2006-02-23 Nokia Corporation System, device and method for data transfer
US20090327827A1 (en) * 2004-11-23 2009-12-31 Juniper Networks, Inc. Rule-based networking device
US20140032643A1 (en) * 2012-07-30 2014-01-30 Adam D. Dirstine Enhanced http messaging for devices

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6594697B1 (en) * 1999-05-20 2003-07-15 Microsoft Corporation Client system having error page analysis and replacement capabilities
AU5027200A (en) * 1999-05-20 2000-12-12 Intensifi, Inc. Method and apparatus for access to, and delivery of, multimedia information
US20020124100A1 (en) * 1999-05-20 2002-09-05 Jeffrey B Adams Method and apparatus for access to, and delivery of, multimedia information
US20020194498A1 (en) * 2001-05-30 2002-12-19 Palm, Inc. Mobile communication system for location aware services
US20040073811A1 (en) * 2002-10-15 2004-04-15 Aleksey Sanin Web service security filter
US7577964B2 (en) * 2003-02-28 2009-08-18 Hewlett-Packard Development Company, L.P. System and methods for defining a binding for web-services
US7676562B2 (en) * 2004-01-20 2010-03-09 Microsoft Corporation Computer system for accessing instrumentation information
US7925729B2 (en) * 2004-12-07 2011-04-12 Cisco Technology, Inc. Network management
US10057105B2 (en) * 2004-11-23 2018-08-21 Kodiak Networks, Inc. Architecture framework to realize push-to-X services using cloudbased storage services
US8478849B2 (en) * 2004-12-07 2013-07-02 Pure Networks LLC. Network administration tool
US8190773B2 (en) * 2005-06-03 2012-05-29 Nokia Corporation System and method for accessing a web server on a device with a dynamic IP-address residing behind a firewall
KR100748937B1 (ko) * 2006-08-04 2007-08-13 주식회사 이노와이어리스 이동전화번호를 이용한 ｗａｐ데이터 추출방법
US7640460B2 (en) * 2007-02-28 2009-12-29 Microsoft Corporation Detect user-perceived faults using packet traces in enterprise networks
US10067831B2 (en) * 2009-12-29 2018-09-04 International Business Machines Corporation Slice migration in a dispersed storage network
US8346853B2 (en) * 2010-05-27 2013-01-01 Robert Paul Morris Methods, systems, and computer program products for processing an attached command response
US9176638B2 (en) * 2011-08-26 2015-11-03 Citrix Systems, Inc. User interface for large scale system monitoring
US9172807B2 (en) * 2011-09-11 2015-10-27 ZenDesk, Inc. Techniques for customer relationship management
US8924799B2 (en) * 2012-04-16 2014-12-30 Yahoo! Inc. Method and system for providing a predefined content to a user
US9037926B2 (en) * 2012-06-07 2015-05-19 International Business Machines Corporation Background buffering of content updates
US8799360B2 (en) * 2012-08-31 2014-08-05 Tweedle Group, Inc. Systems, methods and articles for a server providing communications and services involving automobile head units
US8869275B2 (en) * 2012-11-28 2014-10-21 Verisign, Inc. Systems and methods to detect and respond to distributed denial of service (DDoS) attacks
US20150033335A1 (en) * 2012-11-28 2015-01-29 Verisign, Inc. SYSTEMS AND METHODS TO DETECT AND RESPOND TO DISTRIBUTED DENIAL OF SERVICE (DDoS) ATTACKS
US9143978B2 (en) * 2012-12-07 2015-09-22 At&T Intellectual Property I, L.P. Network congestion prevention and/or mitigation
CA2904150A1 (en) * 2013-03-15 2014-09-18 Assa Abloy Ab Method, system, and device for generating, storing, using, and validating nfc tags and data
US20150296027A1 (en) * 2014-04-09 2015-10-15 Nokia Corporation Continuous Browsing Across Devices
US10536523B2 (en) * 2014-05-11 2020-01-14 Microsoft Technology Licensing, Llc File service using a shared file access-rest interface
CA2971865A1 (en) * 2014-12-22 2016-06-30 Capital One Services, Llc A system, method, and apparatus for locating a bluetooth enabled transaction card

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20030010002A (ko) * 2001-07-25 2003-02-05 주식회사 비즈모델라인 블루투스를 이용한 무선 결제 방법
KR20020081183A (ko) * 2002-09-09 2002-10-26 이민수 블루투스 통신을 이용한 이동통신기기의 결제서비스시스템 및 그 방법
US20060039348A1 (en) * 2004-08-20 2006-02-23 Nokia Corporation System, device and method for data transfer
US20090327827A1 (en) * 2004-11-23 2009-12-31 Juniper Networks, Inc. Rule-based networking device
US20140032643A1 (en) * 2012-07-30 2014-01-30 Adam D. Dirstine Enhanced http messaging for devices

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017112120A1 (en) * 2015-12-23 2017-06-29 Intel Corporation Method, system and apparatus for communication through wireless charging network
US10123154B2 (en) 2015-12-23 2018-11-06 Intel Corporation Method, system and apparatus for communication through wireless charging network
WO2021215553A1 (ko) * 2020-04-22 2021-10-28 엘지전자 주식회사 자율주행시스템에서 차량의 데이터 전송방법

Also Published As

Publication number Publication date
KR101990489B1 (ko) 2019-09-30
US9961481B2 (en) 2018-05-01
US20170048656A1 (en) 2017-02-16
KR20160141759A (ko) 2016-12-09

Similar Documents

Publication Publication Date Title
WO2018048268A1 (ko) 블루투스 기술을 이용하여 디바이스를 연결하기 위한 방법 및 장치
WO2015137601A1 (ko) 무선통신 시스템에서 데이터 전송률 조절 방법 및 장치
WO2018074892A1 (ko) 블루투스 기술을 이용하여 데이터를 송수신하기 위한 방법 및 장치
WO2015069093A1 (ko) 블루투스 연결 방법 및 장치
WO2014204272A1 (ko) 무선 통신시스템에서 블루투스를 이용하여 멀티미디어 콘텐츠를 재생하기 위한 방법 및 장치
WO2018222024A1 (ko) 블루투스 le 기술을 이용하여 디바이스를 연결하기 위한 방법 및 장치
WO2016182404A1 (ko) 블루투스 저전력 에너지 기술을 이용하여 대체 통신 수단을 연결하기 위한 방법 및 장치
WO2015194854A1 (ko) 블루투스 le(low energy) 기술을 이용하여 디바이스 간 커넥션을 형성하기 위한 방법 및 장치
WO2015163547A1 (ko) 무선 통신시스템에서 블루투스를 이용하여 http 데이터를 전송하기 위한 방법 및 장치
WO2015182896A1 (ko) 블루투스 연결 방법 및 장치
WO2015163680A1 (ko) 무선 통신 시스템에서 블루투스 저전력 에너지 기술을 이용하여 데이터를 송수신하기 위한 방법 및 장치
WO2020096412A1 (ko) 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치
WO2018169380A1 (ko) 블루투스 기술을 이용하여 오디오 신호를 처리하기 위한 방법 및 장치
WO2017030232A1 (ko) 데이터 송수신 방법 및 이를 위한 디바이스
WO2015069031A1 (ko) 블루투스를 이용한 커뮤니케이션 링크 형성 방법 및 장치
WO2018021877A1 (ko) 디바이스의 연결을 형성하기 위한 방법 및 장치
WO2020213959A1 (ko) 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치
WO2015002385A1 (ko) 무선 통신시스템에서 디바이스들 간에 커뮤니케이션을 위한 방법 및 장치
WO2016178542A1 (ko) 블루투스에서 데이터를 송수신하기 위한 방법 및 장치
WO2017018604A1 (ko) 블루투스 le(low energy) 기술을 이용하여 대체 통신 수단을 연결하기 위한 방법 및 장치
WO2016036206A2 (ko) 블루투스 le(low energy) 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2019031822A1 (ko) 블루투스 저전력 에너지 기술을 이용하여 디바이스간 연결을 형성하기 위한 방법 및 장치
WO2020180168A1 (ko) 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치
WO2018009040A1 (ko) 블루투스 기술을 이용하여 데이터를 송수신하기 위한 방법 및 장치
WO2022124870A1 (ko) 근거리 무선 통신 시스템에서 데이터를 송수신하기 위한 방법 및 이에 대한 장치

Legal Events

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

Ref document number: 14890057

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20167029187

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 15305964

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 14890057

Country of ref document: EP

Kind code of ref document: A1