WO2015068988A1 - 무선 통신 시스템에서 데이터를 송수신하는 방법 및 이를 수행하기 위한 장치 - Google Patents

무선 통신 시스템에서 데이터를 송수신하는 방법 및 이를 수행하기 위한 장치 Download PDF

Info

Publication number
WO2015068988A1
WO2015068988A1 PCT/KR2014/010417 KR2014010417W WO2015068988A1 WO 2015068988 A1 WO2015068988 A1 WO 2015068988A1 KR 2014010417 W KR2014010417 W KR 2014010417W WO 2015068988 A1 WO2015068988 A1 WO 2015068988A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
advertising
information
network
uri
Prior art date
Application number
PCT/KR2014/010417
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 US15/035,082 priority Critical patent/US9936448B2/en
Publication of WO2015068988A1 publication Critical patent/WO2015068988A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/18—Selecting a network or a communication service
    • 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/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/12—Wireless traffic scheduling
    • H04W72/1215—Wireless traffic scheduling for collaboration of different radio technologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/40—Security arrangements using identity modules
    • H04W12/43—Security arrangements using identity modules using shared identity modules, e.g. SIM sharing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/005—Discovery of network devices, e.g. terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]

Definitions

  • the present disclosure relates to a method for transmitting and receiving data in a wireless communication system and an apparatus for performing the same.
  • 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.
  • connection between devices has been performed through various steps such as searching, connecting, and setting security information for each network interface supported by the device.
  • a device that transmits an advertisement since a device that transmits an advertisement unilaterally transmits a beacon including advertisement data to a device that receives the advertisement, it is possible to distinguish whether the advertising URI transmitted from the advertisement device from the receiving device is a safe URI or spam URIs. There was a problem that was vulnerable to security.
  • the present specification uses Bluetooth in a wireless communication system (eg, WPAN) to quickly search for service information, user information, network information, content information, etc. between devices and perform connection between devices.
  • a wireless communication system eg, WPAN
  • the purpose is to provide a method for sharing data through other networks.
  • the present specification is to provide a method for securely sharing a service by sharing a URI or a URL indicating the advertisement, promotion, status information, and the like and security information associated with the device using Bluetooth in a wireless communication system. .
  • the present disclosure provides a method for transmitting and receiving data in a wireless communication system, wherein the method performed by a first device transmits a first message including connection information between devices to at least one second device through a first network. Doing; Receiving a response to the first message from the at least one second devices via the first network; Sending a connection request message to the at least one second devices via the first network to request a wireless connection of a second network based on the response, wherein the connection request message is a network representing the second network.
  • connection information Includes connection information; Receiving a connection response message corresponding to the response of the connection request message from the at least one second devices through the first network; And transmitting and receiving data with a second device through the second network, wherein the connection information between the devices includes network information indicating a network supported by the first device, service information indicating a service to be shared, and the sharing. And at least one of content type information representing a content type of a desired service or user information representing information related to a user.
  • the first network is Bluetooth
  • the second network is another wireless network except Bluetooth
  • the first message may be an inquiry message of a Bluetooth Basic Rate (BR) / Enhanced Data Rate (EDR) or an advertisement channel PDU (Packet Data Unit) of BLE (Bluetooth Low Energy). do.
  • BR Bluetooth Basic Rate
  • EDR Enhanced Data Rate
  • PDU Packet Data Unit
  • the present specification is characterized in that the first device transmits and receives a message with the at least one second devices through tethering, and transmits and receives data with the second device.
  • the first message may further include at least one of at least one Uniform Resource Identifier (URI) or security information associated with the at least one Advertising URI.
  • URI Uniform Resource Identifier
  • the present disclosure may also include receiving a second message requesting security additional information associated with the at least one advertisement URIs from the at least one second device; And transmitting a third message including the requested security side information to the at least one second devices.
  • the second message may include an advertising security request type field.
  • the third message may include an advertising security flag field and an advertising security type field.
  • the third message is transmitted as many as the number of key distribution fields, and one key distribution for each third message.
  • the field is included and transmitted.
  • the first message is transmitted when a Connectable and Undirected advertisement event occurs or when a Non-connectable and Undirected advertisement event occurs.
  • the present specification is characterized in that when the first message is transmitted when a Connectable and Undirected advertisement event occurs, security information associated with at least one advertisement URI is exchanged after establishing connection with the second device.
  • the security information related to the at least one advertising URI may include an advertising URI type field, an advertising security type field, a valid time stamp field, and an advertiser name. And at least one of an Advertiser Name field or an Advertiser Security Flag field.
  • the Advertiser Security Flag field may include an Advertiser Encryption Key Distribution field, an Advertiser ID Key Distribution field, an Advertiser Signature Key Distribution field. And at least one of a Key Distribution field and a Target Server Certificate Distribution field.
  • the first message further includes an extended PDU and an extended CRC
  • the extended PDU further includes at least one key distribution URI.
  • the first device is an advertiser
  • the second device is a scanner
  • the present specification provides a method for transmitting and receiving data in a wireless communication system
  • the first device includes a communication unit for transmitting and receiving signals to and from the outside and wired and wirelessly; And a controller operatively connected to the communication unit, wherein the controller transmits a first message including connection information between devices to at least one second device through a first network; Receive a response to the first message from the at least one second devices via the first network; Send a connection request message to the at least one second devices via the first network to request a wireless connection of a second network based on the response; Receive a connection response message corresponding to the response of the connection request message from the at least one second devices via the first network; Control to transmit and receive data to and from a second device through the second network, wherein the connection information between the devices includes network information indicating a network supported by the first device, service information indicating a service to be shared, and the service to be shared. And at least one of content type information indicating a content type of a user or user information indicating information related to
  • control unit may receive a second message requesting security additional information associated with the at least one advertisement URIs from the at least one second devices; And control to transmit a third message including the requested security additional information to the at least one second devices.
  • the present specification provides an effect of quickly connecting to another network between devices by sharing user information, service information, and network information between devices using Bluetooth.
  • the present specification provides an effect of safely sharing services between devices by sharing a URI and security information related thereto that represents advertisements, promotions, status information, etc. using Bluetooth.
  • the present specification provides an effect that can increase the user experience (UX) by providing the user with ease in an environment using a plurality of devices that want to play multimedia content.
  • FIG. 1 is a diagram illustrating an example of a Bluetooth low power energy architecture (Architecture) to which the methods proposed herein may be applied.
  • Architecture Bluetooth low power energy architecture
  • FIG. 2 is a diagram illustrating an example of an internal block diagram of devices to which the methods proposed herein may be applied.
  • FIG. 3 is a flowchart illustrating an example of a method for sharing content between devices.
  • FIG. 4 is a flowchart illustrating an example of a method of exchanging device search and connection information using Bluetooth proposed in the present specification.
  • FIG. 5 is a flowchart illustrating still another example of a method for exchanging device discovery and connection information using Bluetooth proposed in the present specification.
  • FIG. 6 is a flowchart illustrating still another example of a method for exchanging device discovery and connection information using Bluetooth proposed in the present specification.
  • FIG. 7 is a diagram illustrating an example of a new extended query response data format proposed in the present specification.
  • FIG. 8 is a diagram illustrating an example of an advertisement message format proposed in the present specification.
  • FIG. 9 illustrates an example of an advertisement data and a scan response data format proposed in the present specification.
  • FIG. 10 is a diagram illustrating an example of a packet structure including device connection information proposed in the present specification.
  • FIG. 11 is a diagram illustrating another example of a packet structure including device connection information proposed in the present specification.
  • FIG. 12 is a flowchart illustrating an example of a method for exchanging device connection information using the packet structure of FIG. 11.
  • FIG. 13 is a flowchart illustrating an example of a method for exchanging device discovery and connection information using tethering proposed in the present specification.
  • FIG. 14 is a diagram illustrating an example of a user interface output from devices proposed in the present specification.
  • FIG. 15 is a flowchart illustrating an example of a method for exchanging Wi-Fi Direct connection information, transmitting / receiving data via Wi-Fi Direct, and device-to-device streaming using Bluetooth proposed in the present specification.
  • 16 is a flowchart illustrating an example of an advertisement URI security enhancement method using Bluetooth proposed in the present specification.
  • 17 is a diagram illustrating an example of an advertisement message structure proposed in the specification.
  • FIG. 18 is a flowchart illustrating an example of a method for obtaining information of an advertisement URI using the advertisement message of FIG. 17.
  • FIG 19 illustrates another example of an advertisement message structure proposed in the specification.
  • FIG. 20 is a flowchart illustrating an example of a method for obtaining advertisement URI information through the advertisement message structure of FIG. 19.
  • 21 shows another example of an advertisement message structure proposed in the specification.
  • FIG. 22 is a flowchart illustrating an example of a method for obtaining advertisement URI information through the advertisement message structure of FIG. 21.
  • FIG. 23 is a diagram illustrating another example of an advertisement message structure proposed in the specification.
  • FIG. 23 is a diagram illustrating another example of an advertisement message structure proposed in the specification.
  • FIG. 24 is a flowchart illustrating an example of a method for obtaining advertisement URI information through the advertisement message structure of FIG. 23.
  • 25 is a flowchart illustrating still another example of a method for obtaining advertisement URI information proposed in the specification.
  • FIG. 26 is a diagram illustrating another example of an advertisement message structure proposed in the specification.
  • FIG. 26 is a diagram illustrating another example of an advertisement message structure proposed in the specification.
  • FIG. 27 is a flowchart illustrating an example of an advertisement URI access method of a scanner proposed in the present specification.
  • FIG. 28 is a flowchart illustrating an example of a method of transmitting an advertisement URI by a request of a scanner proposed in the specification.
  • FIG. 29 illustrates an example of a scan request message structure of FIG. 28.
  • FIG. 30 illustrates an example of a scan response message structure of FIG. 28.
  • module and “unit” for components used in the following description are merely given in consideration of ease of preparation of the present specification, and the “module” and “unit” may be used interchangeably with each other.
  • the device (device) described herein is a device capable of wireless communication, a mobile phone, including a smart phone, a tablet PC, a desktop computer, a notebook, a smart TV, a television including an IPTV, and the like.
  • FIG. 1 is a diagram illustrating an example of a Bluetooth low power energy architecture (Architecture) to which the methods proposed herein may be applied.
  • Architecture Bluetooth low power energy architecture
  • the BLE structure includes a controller stack operable to handle timing critical radio interface and a host stack operable to process high level data.
  • the controller stack may be referred to as a controller.
  • the controller stack will be referred to as a controller stack to avoid confusion with a processor which is an internal component of the device mentioned in FIG. 2.
  • the controller stack may be implemented using a communication module that may include a Bluetooth radio and a processor module that may include a processing device such as, for example, a microprocessor.
  • the host stack may be implemented as part of an OS running on a processor module, or as an instance of a package on the OS.
  • controller stack and the host stack can be operated or executed on the same processing device in the processor module.
  • the host stack includes GAP (Generic Access Profile, 410), GATT based Profiles (420), GATT (Generic Attribute Profile, 430), ATT (Attribute Protocol, 440), SM (Security Manage, 450), L2CAP (Logical Link Control and Adaptation Protocol, 460).
  • GAP Generic Access Profile
  • GATT Generic Attribute Profile
  • ATT Generic Attribute Protocol
  • SM Storage Manage
  • L2CAP Logical Link Control and Adaptation Protocol
  • the host stack uses L2CAP to multiplex the various protocols, profiles, etc. provided by Bluetooth.
  • the Logical Link Control and Adaptation Protocol (L2CAP) 460 provides one bidirectional channel for transmitting data to a specific protocol or profile.
  • L2CAP may be operable to multiplex data between higher layer protocols, segment and reassemble packages, and manage multicast data transmission.
  • BLE uses three fixed channels (one for the signaling CH, one for the Security Manager, and one for the Attribute protocol).
  • BR / EDR Base Rate / Enhanced Data Rate
  • SM Security Manager
  • ATT Attribute Protocol, 440
  • ATT Application Protocol
  • 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 request message, and refers to a message transmitted from the server device to the client device.
  • Command message A message sent from the client device to the server device to indicate a command of a specific operation.
  • the server device does not transmit a response to the command message to the client device.
  • Notification message This message is sent from the server device to the client device for notification such as an event.
  • the client device does not transmit a confirmation message for the notification message to the server device.
  • Indication and Confirm message This message is transmitted from the server device to the client device for notification such as an event. Unlike the notification message, the client device transmits an acknowledgment message for the Indication message to the server device.
  • GAP Generic Access Profile
  • GAP is mainly used in the device discovery, connection creation and security procedures, and defines the way to provide information to the user, and defines the type of the attribute as follows.
  • GATT-based Profiles are profiles that depend on GATT and are mainly applied to BLE devices.
  • GATT-based Profiles may be Battery, Time, FindMe, Proximity, Time, Object Delivery Service, and the like. Details of GATT-based Profiles are as follows.
  • GATT may be operable as a protocol describing how ATT is used in the configuration of services.
  • the GATT may be operable to specify how ATT attributes are grouped together into services, and may be operable to describe features associated with the services.
  • GATT and ATT may use features to describe the state and services of a device and to describe how features relate to each other and how they are used.
  • the controller stack includes a physical layer 490, a link layer 480, and a host controller interface 470.
  • the physical layer (wireless transceiver module 490) transmits and receives a 2.4 GHz radio signal and uses Gaussian Frequency Shift Keying (GFSK) modulation and a frequency hopping technique consisting of 40 RF channels.
  • GFSK Gaussian Frequency Shift Keying
  • Link layer 480 sends or receives Bluetooth packets.
  • the link layer creates a connection between devices after performing advertising and scanning functions using three advertising channels, and provides a function of sending and receiving data packets of up to 42 bytes through 37 data channels.
  • HCI Host Controller Interface
  • the BLE procedure includes a device filtering procedure, an advertising procedure, a scanning procedure, a discovery procedure, and a connecting procedure.
  • the device filtering procedure is a method for reducing the number of devices performing a response to a request, an indication, a notification, and the like in the controller stack.
  • the controller stack can control the number of requests sent, thus reducing power consumption in the BLE controller stack.
  • the advertising device or scanning device may perform the device filtering procedure to limit the device receiving the advertising packet, scan request or connection request.
  • the advertising device refers to a device that transmits an advertising event, that is, performs an advertisement, and is also referred to as an advertiser.
  • the scanning device refers to a device that performs scanning and a device that transmits a scan request.
  • the scanning device when the scanning device receives some advertising packets received by the advertising device, the scanning device needs to send a scan request to the advertising device. If the device filtering procedure is used to filter the advertising device to which the scan request is to be sent in advance, the scanning device may ignore the advertising packets sent by the advertising device.
  • the device filtering procedure may also be used in the connection request process. If the device making the connection request does not use the pre-device filtering procedure for the device responding to the connection request, the device that receives the connection request (for example, the advertisement device that performed the advertisement) is connected to the connection request. Must respond.
  • the device making the connection request may be represented as an initiating device or an initiator.
  • the advertising device may use a device filtering procedure to limit devices to send a scan request or a connection request to the advertising device.
  • the advertising device performs the advertising procedure to perform the non-directional broadcast to the devices in the area.
  • the non-directional broadcast refers to broadcast in all directions rather than broadcast in a specific direction.
  • directional broadcasts refer to broadcasts in a particular direction.
  • Non-directional broadcasts occur without a connection procedure between an advertising device and a device in a listening (or listening) state (hereinafter referred to as a listening device).
  • the advertising procedure is used to establish a Bluetooth connection with a nearby initiating device.
  • the advertising procedure may be used to provide periodic broadcast of user data to scanning devices that are listening on the advertising channel. In the advertising process, all advertisements (or advertisement events) are broadcast over an advertising physical channel.
  • a BLE device connected to the BLE piconet may advertise using a particular type of advertisement event.
  • the advertising devices may receive a scan request from listening devices that are listening to obtain additional user data from the advertising device.
  • the advertising device transmits a response to the scan request to the device that sent the scan request through the same advertising physical channel as the received advertising physical channel.
  • Broadcast user data sent as part of an advertisement packet is dynamic data, while scan response data is generally static data.
  • the advertising device may receive a connection request from the initiating device on the advertising (broadcast) physical channel. If the advertising device used a connectable advertising event and the initiating device was not filtered by the device filtering procedure, the advertising device stops the advertising and enters the connected mode. The advertising device may start advertising again after the connected mode.
  • the device performing the scanning i.e., the scanning device, performs a scanning procedure to listen to the non-directional broadcast of the user data from the advertising devices using the advertising physical channel.
  • the scanning device sends a scan request to the advertising device via the advertising physical channel to request additional user data from the advertising device.
  • the advertising device transmits a scan response that is a response to the scan request, including additional user data requested by the scanning device over the advertising physical channel.
  • the scanning procedure can be used while connected to other BLE devices in the BLE piconet.
  • the scanning device If the scanning device is in an initiator mode that can receive the broadcasted advertising event and initiate a connection request, the scanning device sends the connection request to the advertising device via the advertising physical channel to the advertising device. You can start a Bluetooth connection with.
  • the scanning device When the scanning device sends a connection request to the advertising device, the scanning device stops initiator mode scanning for further broadcast and enters the connected mode.
  • Bluetooth devices Devices capable of Bluetooth communication (hereinafter referred to as Bluetooth devices) perform an advertisement procedure and a scanning procedure in order to find nearby devices or to be discovered by other devices within a given area.
  • the discovery procedure is performed asymmetrically.
  • a Bluetooth device that attempts to find other devices around it is called a discovering device and listens for devices that advertise scannable advertising events.
  • Bluetooth devices discovered and available from other devices are referred to as discoverable devices, and actively broadcast advertising events so that other devices can scan through an advertising (broadcast) physical channel.
  • Both the discovering device and the discoverable device may already be connected with other Bluetooth devices in the piconet.
  • connection procedure is asymmetric, and the connection procedure requires the other Bluetooth device to perform the scanning procedure while the specific Bluetooth device performs the advertisement procedure.
  • the advertising procedure can be the goal, so that only one device will respond to the advertising.
  • the connection may be initiated by sending a connection request to the advertising device via the advertising (broadcast) physical channel.
  • an operation state of the BLE technology that is, an advertising state, a scanning state, an initiating state, and a connection state will be briefly described.
  • the link layer LL enters the advertisement state by the instruction of the host (stack). If the link layer is in the advertisement state, the link layer sends advertisement packet data units (PDUs) in the advertisement events.
  • PDUs advertisement packet data units
  • Each advertising event consists of at least one advertising PDU, which is transmitted via the advertising channel indexes used.
  • the advertisement event may terminate when the advertisement PDU is transmitted through each of the advertisement channel indexes used, or may terminate the advertisement event earlier when the advertisement device needs to make space for performing another function.
  • the link layer enters the scanning state by the indication of the host (stack). In the scanning state, the link layer listens for advertising channel indices.
  • scanning states There are two types of scanning states: passive scanning and active scanning, each scanning type being determined by the host.
  • ScanInterval is defined as the interval (interval) between the starting points of two consecutive scan windows.
  • the link layer must listen for completion of all scan intervals in the scan window as instructed by the host. In each scan window, the link layer must scan a different advertising channel index. The link layer uses all available advertising channel indexes.
  • the link layer When passive scanning, the link layer only receives packets and does not transmit any packets.
  • the link layer When active scanning, the link layer performs listening to rely on the advertising PDU type, which may request advertising PDUs and additional information related to the advertising device from the advertising device.
  • the link layer enters the initiation state by the indication of the host (stack).
  • the link layer performs listening for the advertising channel indexes.
  • the link layer listens for the advertising channel index during the scan window period.
  • the link layer enters the connected state when the device performing the connection request, i.e., the initiating device, sends the CONNECT_REQ PDU to the advertising device or when the advertising device receives the CONNECT_REQ PDU from the initiating device.
  • connection After entering the connected state, the connection is considered to be created. However, it does not need to be considered to be established at the time the connection enters the connected state. The only difference between the newly created connection and the established connection is the link layer connection supervision timeout value.
  • the link layer that performs the master role is called a master, and the link layer that performs the slave role is called a slave.
  • the master controls the timing of the connection event, and the connection event is the point in time when the master and the slave are synchronized.
  • BLE devices use the packets defined below.
  • the link layer has only one packet format used for both advertisement channel packets and data channel packets.
  • Each packet consists of four fields: Preamble, Access Address, PDU, and CRC.
  • the PDU When one packet is sent on an advertising physical channel, the PDU will be an advertising channel PDU, and when one packet is sent on a data physical channel, the PDU will be a data channel PDU.
  • the advertising channel PDU Packet Data Unit
  • PDU Packet Data Unit
  • the PDU type field of the advertising channel PDU included in the header indicates a PDU type as defined in Table 1 below.
  • advertising channel PDU types are called advertising PDUs and are used in specific events.
  • ADV_IND Connectable Non-Oriented Ads Event
  • ADV_DIRECT_IND Connectable Directional Advertising Event
  • ADV_NONCONN_IND Non-connectable non-directional advertising event
  • ADV_SCAN_IND Scannable Non-Oriented Advertising Event
  • the PDUs are transmitted at the link layer in the advertisement state and received by the link layer in the scanning state or initiating state.
  • the advertising channel PDU type below is called a scanning PDU and is used in the state described below.
  • SCAN_REQ Sent by the link layer in the scanning state and received by the link layer in the advertising state.
  • SCAN_RSP Sent by the link layer in the advertising state and received by the link layer in the scanning state.
  • the advertising channel PDU type below is called the initiating PDU.
  • CONNECT_REQ Sent by the link layer in the initiating state and received by the link layer in the advertising state.
  • the data channel PDU has a 16-bit header, payloads of various sizes, and may include a message integrity check (MIC) field.
  • MIC message integrity check
  • the procedure, state, packet format, etc. in the BLE technology may be applied to perform the methods proposed herein.
  • FIG. 2 is a diagram illustrating an example of an internal block diagram of devices to which the methods proposed herein may be applied.
  • a device for initiating a connection (Initiating Device, 100) transmits a request message for giving a command to the connection target device 200 or receives and processes a request message requested by the connection target device 200.
  • connection initiation device 100 After the connection initiation device 100 transmits a request message to the connection target device 200, the connection initiation device 100 processes a response message transmitted from the connection target device to provide a UI to the user.
  • connection initiation device 100 receives a request message requested from a connection target device, processes it, and provides a UI to a user.
  • the connection target device 200 refers to a device that transmits a request message for giving a command to a connection initiation device or receives and processes a request message requested by the connection initiation device.
  • connection target device 200 may be represented as a remote device or an initiated device.
  • connection target device 200 transmits a request message to the connection initiation device, receives a response message transmitted from the connection initiation device, processes it, and provides a UI to the user.
  • connection initiation device 100 and the connection target device 200 may be a personal computer, a PDA, a mobile phone, a remote controller, a TV, a headphone or an AV device (Car System, headphone, player / recorder, timer, tuner, monitor, etc.). Can be.
  • connection initiation device 100 and the connection target device 200 are output units 110 and 210, user interface units 120 and 220, memory 130 and 230, power supply units 140 and 240, communication units 150 and 250, and a controller (processor, 160, 260 and data processing devices 170, 270.
  • the output unit, the user interface unit, the memory, the power supply unit, the communication unit and the control 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 output units 110 and 210 are used to generate an output related to visual, auditory or tactile senses, and may include display modules 112 and 212 and sound output modules 114 and 214.
  • the display modules 112 and 212 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 112 and 212 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 114 and 214 may output audio data received from the communication unit 150 or 250 or stored in the memory 130 and 230 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 114 and 214 output sound signals related to functions (eg, call signal reception sound, message reception sound, etc.) performed in the device.
  • the sound output modules 114 and 214 may include a receiver, a speaker, a buzzer, a microphone, and the like.
  • the microphone may receive a tone transmitted from the counterpart device, and the speaker may transmit a tone to the counterpart device.
  • Tone means a signal in which binary data, which will be described below, is converted into sound through a conversion matrix.
  • the user input units 120 and 220 generate input data for the user to control the operation of the terminal.
  • 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 memories 130 and 230 may store a program for the operations of the controllers 160 and 260, and may temporarily store input / output data.
  • the memories 130 and 230 may store data relating to various patterns of vibration and sound output when a touch is input on the touch screen.
  • the memory 130, 230 is a medium for storing various types of information of a terminal.
  • the memory 130, 230 is connected to the control unit to store programs, applications, general files, and input / output data for the operation of the control unit 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.
  • RAM Random Access Memory
  • SRAM Static Random Access Memory
  • ROM ReadOnly Memory
  • EEPROM Electrically Erasable Programmable ReadOnly Memory
  • PROM Programmable ReadOnly Memory
  • Magnetic Disk Optical Disk It may include at least one type of storage medium.
  • the power supply units 140 and 240 refer to a module that supplies power required for the operation of each component by receiving external power and internal power under the control of the controllers 160 and 260.
  • the communication units 160 and 260 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 160 and 260 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 short range communication module refers to a module for short range communication.
  • Bluetooth Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wideband (UWB), ZigBee, and the like may be used.
  • RFID Radio Frequency Identification
  • IrDA Infrared Data Association
  • UWB Ultra Wideband
  • ZigBee ZigBee
  • the communication unit 150, 250 enables the transmission of a message or data, such as an initiating device-initiated device command, request, action, response.
  • the controllers 160 and 260 refer to a module for controlling overall operations of the connection initiation device and the connection target device, and control to process a message request and a received message through a Bluetooth interface and another communication interface. can do.
  • the controllers 160 and 260 may be referred to as a controller, a micro controller, a microprocessor, and the like.
  • the controllers 160 and 260 may include hardware, firmware, It may be implemented by software, or a combination thereof.
  • the controllers 160 and 260 may include an application-specific integrated circuit (ASIC), another chipset, a logic circuit, and / or a data processing device.
  • ASIC application-specific integrated circuit
  • FIG. 3 is a flowchart illustrating an example of a method for sharing content between devices.
  • the content (or data) sharing process between devices first searches a network, performs a network connection process, and checks whether content for sharing is supported.
  • the above process is repeatedly performed until the device can share the content or find a device that can share the content.
  • the device 1 activates or turns on a specific network (eg, network # 1) through a reception input from a user (S301).
  • a specific network eg, network # 1
  • S301 a reception input from a user
  • the network may be represented by a wireless communication, a radio access technology (RAT), a wireless (connection) function, or the like.
  • RAT radio access technology
  • connection wireless
  • the plurality of remote devices (devices 2 to N) that the device 1 can connect to that is, the connection target, currently activate or turn on all network interfaces or wireless functions.
  • the network interface or wireless function may be Bluetooth, Wi-Fi, Zigbee, 3G, 4G, or the like.
  • the device 1 performs network discovery through an activated network (network # 1).
  • the device 1 transmits a message for network search to a plurality of remote devices (S302).
  • the device 1 receives a response to the message transmitted in step S302 from one or more remote devices (S303).
  • the device 1 performs a connection procedure to establish a connection with one of the remote devices having transmitted the response of step S303.
  • the device 1 transmits a connection request message for network connection to the remote devices that transmit the response of step S303 (S304).
  • the remote devices receiving the Connection Request message output a UI through which the user can select 'accept connection' or 'connection rejection' to receive the user's confirmation of the network connection request (S305).
  • the remote device receiving the confirmation of 'connection acceptance' from the user transmits a connection response message including the result of the network connection request to the device 1 (S306).
  • the device 1 establishes a network connection with any one remote device, and then checks whether the application to be shared is supported by the devices (device 1 and device connected with device 1) (S307).
  • the device 1 exchanges data associated with the application with the connected remote device (S308).
  • the data related to the application may be a file, a message, control information, audio / video (A / V), and the like.
  • the device 1 repeats steps S302 to S307 to find a remote device that can share the application.
  • a service for device-to-device, user information, and content information may be quickly searched for using a Bluetooth device, and other network communication (Wi-Fi) in addition to Bluetooth communication , Zigbee, 3G, 4G, 5G, NFC, RFID, etc.) to learn how to share content between devices (Protocol, Data Format, UI / UX, etc.).
  • Wi-Fi Wi-Fi
  • Bluetooth Basic Rate / Enhanced Data Rate (BR / EDR) technology may be applicable.
  • FIG. 4 is a flowchart illustrating an example of a method of exchanging device search and connection information using Bluetooth proposed in the present specification.
  • a plurality of devices may exist and the plurality of devices may be divided into a first device and a second device.
  • the first device may be a device requesting device connection for sharing content with other devices
  • the second device may be a remote device corresponding to a connection request object.
  • the first device performs a service discovery procedure using Bluetooth communication.
  • BLE technology or Bluetooth BR / EDR technology may be used for the Bluetooth communication.
  • the BLE technology will be described as an example.
  • the first device transmits a BLE advertising message including at least one of network (type) information, user information, content type information, or service information (S401).
  • type network
  • S401 service information
  • the BLE Advertising message may be transmitted in a broadcast or unicast manner.
  • the BLE advertising message may be represented by an advertising channel PDU (Packet Data Unit), an advertising packet, or the like.
  • PDU Packet Data Unit
  • the network information is information representing a network interface supported by the device and may be W-Fi (eg, SSID, Channel Information), Wi-Fi Direct (Group ID), NFC, Bluetooth, Ethernet, or the like.
  • W-Fi eg, SSID, Channel Information
  • Wi-Fi Direct Group ID
  • NFC Wireless Fidelity
  • Bluetooth Wireless Fidelity
  • Ethernet Ethernet
  • the user information is information related to a user who uses the device, and may be a user ID, a user name, a user preference, an account information, and the like.
  • the service information refers to information representing a service that can be used in a device or to be shared with another device, and can be service ID, application ID, cloud service provider information, and the like.
  • the content type information indicates a content type of a service that can be used or shared, and the content type may include video, picture, music, documents, and the like.
  • the at least one second device receiving the BLE advertisement message transmits a response including its network information, user information, service information, etc. to the first device (S402).
  • the first device selects a user (or device) and a service for sharing based on the response received from the at least one second device (S403).
  • the service may be Facebook, Dropbox, Web Services, Picture, File Sharing, Message, etc.
  • FIG. 4 it can be seen that the Picture service is selected.
  • the first device transmits a network connection request message to a second device selected in step S403 in order to perform a wireless communication connection for content sharing (S404).
  • the wireless communication used for device discovery and connection information exchange may be different from the wireless communication used for data transmission and reception.
  • the first device establishes a new network connection with the second device and exchanges data (or transmits and receives) with each other through the connected network (S405).
  • FIG. 5 is a flowchart illustrating still another example of a method for exchanging device discovery and connection information using Bluetooth proposed in the present specification.
  • FIG. 5 illustrates a method of exchanging device search and connection information using BLE.
  • the device 1 activates or turns on the BLE function through a user input (S501).
  • the BLE functions of the devices 2 to N corresponding to the remote devices are active and other wireless functions are inactive.
  • the device 1 performs an application discovery procedure using BLE technology.
  • the application discovery procedure may be expressed as a service discovery procedure.
  • the device 1 transmits a BLE Service Search having an Extended Inquiry Response (EIR) request to remote devices (S502).
  • EIR Extended Inquiry Response
  • the device 1 may transmit a BLE service search to receive an extended query response (EIR) from remote devices, and the BLE service search may be represented by an Inquiry message.
  • EIR extended query response
  • the device 1 receives a response to the BLE service search from one or more remote devices (S503).
  • the response to the BLE Service Search includes EIR data
  • the EIR data includes device connection information such as application information, user information, network information, and content type information of a remote device.
  • the device 1 selects an application based on the response to the BLE service search and performs a network interface connection process to form a group with a specific remote device (S504).
  • the device 1 uses Bluetooth for the network interface used for device discovery and connection information exchange, and uses a network other than Bluetooth for the network interface used for data sharing.
  • the device 1 transmits a connection request message to the remote devices to request a connection through another network interface based on the information received in step S503 (S505).
  • the remote devices output a UI for selecting connection acceptance or connection rejection in order to receive a user confirmation for a connection request of another network interface (S506).
  • the remote device receiving the user input for 'connection acceptance' inactivates the activated BLE function (inactive), and activates another wireless function or another network interface for use in content sharing (S507).
  • device 2 has received a connection acceptance for another network connection from a user.
  • the device 2 transmits a connection response message to the device 1 in response to the connection request message (S508).
  • the device 1 and the device 2 exchange application data through another newly connected network interface (S509).
  • FIG. 6 is a flowchart illustrating still another example of a method for exchanging device discovery and connection information using Bluetooth proposed in the present specification.
  • FIG. 6 illustrates a method of exchanging device discovery and connection information using Bluetooth Basic Rate / Enhanced Data Rate (BR / EDR).
  • device 1 prepares to perform application discovery by turning on Bluetooth communication.
  • Bluetooth wireless functions of the devices 2 to N corresponding to the remote devices are in an active state, and other wireless functions are in an inactive state.
  • the device 1 receives a selection input for an item to be transmitted from a user and activates a Bluetooth wireless function (S601).
  • the device 1 performs an application discovery procedure using Bluetooth BR / EDR with the remote devices.
  • the device 1 transmits an Inquiry message to determine whether there are remote devices to be connected to the peripheral (S602).
  • the device 1 broadcasts application information, user information, network interface information, contents type information, etc. selected by the user in the Inquiry message or through a separate message.
  • the Inquiry message or a separate message may further include advertising URI Type, Valid Time Stamp, Advertiser Name, Advertise Security Flag, and Advertising URI Type information.
  • Advertising URI Type Valid Time Stamp
  • Advertiser Name Advertiser Name
  • Advertise Security Flag Advertising URI Type information
  • the device 1 receives a response message including application information, user information, network interface information, contents type information, etc. supported by the remote device from the remote devices receiving the Inquiry message (S603).
  • Salping application information, user information, other network interface information, contents type information, etc. may be included in the EIR data and transmitted in S602 and S603.
  • the device 1 determines whether there is a remote device supporting a plurality of applications in the vicinity based on the response message received in step S603 (S604).
  • the device 1 may output device connection information received from the remote devices, that is, application information, network interface information, and the like through an output unit.
  • the user of the device 1 may select an application and a network interface to be connected among the results output through the output of the device 1.
  • the device 1 performs a connection procedure with the remote devices to connect another network interface to be used for content sharing.
  • the device 1 transmits a Connection Request message including User Confirmation triggering information to the remote devices identified in step S603 (S605).
  • the Connection Request message may include user information selected from the device 1, network information, service confirmation information, and the like.
  • Connection Request message may further include connection information required when connecting to the remote device and the alternative carrier.
  • the remote devices receiving the Connection Request message output a UI to the output unit to select whether to accept or reject the connection to another network interface through the User Confirmation triggering information (S606).
  • Each remote device then activates a wireless connection function to use for content sharing upon receipt of user input for connection acceptance or connection rejection.
  • the Bluetooth wireless function activated for device discovery and connection information exchange may be kept activated, but it may be desirable to be deactivated for power consumption.
  • device 2 may activate the wireless connection function selected by the device 1 (S607).
  • the device N receives an input for 'connection rejection' from the user, it can be seen that the wireless connection function selected by the device 1 is not activated.
  • the device 2 transmits a connection response message corresponding to the response of the connection request message to the device 1 (S608).
  • the Connection Response message may include information related to the device 2.
  • the device 1 and the device 2 exchange additional information necessary for establishing a connection of another network interface, and then transmit and receive application data through another newly established network (S609).
  • FIG. 7 is a diagram illustrating an example of a new extended query response data format proposed in the present specification.
  • the EIR data format has a size of 240 octets, and may include a critical part and a non-significant part.
  • the critical portion contains a sequence of EIR data structures, each EIR data structure comprising a Length field of size 1 octet and a Data field of length octets.
  • the Data field includes an EIR Data Type field of size n octets and an EIR Data field of length n octets.
  • the non-critical portion can extend the EIR size to 240 octets and all octets can be set to zero.
  • Messages used in Application Discovery described in FIG. 6 may be determined by a value set by the EIR Data Type.
  • the device connection information that is, the application information, the user information, the network information, and the content type information described with reference to FIG. 6 may be included in a data field, particularly, an EIR data field in the EIR data structure.
  • EIR Data field may further include advertising URI Type, Valid Time Stamp, Advertiser Name, Advertise Security Flag, Advertising URI Type information.
  • the user information is information related to a user and may be a user ID, a name, a user preference, an account information, and the like.
  • the service information is information related to a service, and may be a service ID, an app ID, cloud service provider information, and the like.
  • the network information may be Wi-Fi (e.g. SSID, Channel Information), Wi-Fi Direct (Group ID), NFC, Bluetooth, Ethernet, and the like.
  • Wi-Fi e.g. SSID, Channel Information
  • Wi-Fi Direct Group ID
  • NFC Wireless Fidelity
  • Bluetooth Wireless Fidelity
  • Ethernet Ethernet
  • the content information may be a content type (Video, Picture, Music, Documents).
  • Table 2 is a table illustrating an example of the EIR Data Type field of FIG. 7.
  • Table 3 shows an example of an Application Inquiry message format included in the EIR Data field
  • Table 4 shows an example of an Application Response message format included in the EIR Data field.
  • the application exchanged between devices represents the LG Gallery
  • the user of the remote device to be connected is User2
  • the other network interface represents Wi-Fi Direct
  • the content types to be shared Represents a photograph.
  • FIG. 8 is a diagram illustrating an example of an advertisement message format proposed in the present specification.
  • the link layer has only one packet format.
  • the format of the advertising channel packet and the data channel packet are the same.
  • the advertisement channel packet may be represented as an advertisement channel PDU, an advertisement message, advertisement data, or the like.
  • the link layer packet format includes a preamble, an access address, a PDU, and a CRC, as shown in FIG.
  • the preamble has a size of 1 octet and a connection address of 4 octets.
  • PDU sizes range from 2 octets up to 39 octets.
  • CRC is 3 octets in size.
  • the preamble is a part transmitted first in the advertisement channel packet, and the access address, PDU, and CRC are sequentially transmitted after the preamble.
  • All link layer packets have a preamble of 8 bits.
  • the preamble is used in a receiver to perform frequency synchronization, symbol timing estimation, and automatic gain control (AGC) training.
  • AGC automatic gain control
  • the advertising channel packets have a preamble set to 10101010b.
  • the preamble of the data channel packet has a value of 10101010b or 01010101b depending on the LSB of the access address. If the LSB of the access address is '1', the preamble is 01010101b, otherwise 10101010b.
  • the access address may be set to 10001110100010011011111011010110b (0x8E89BED6) as an access address for all advertisement channel packets.
  • connection address can be any 32-bit value, generated by the initiating state, that is, the device requesting the connection, and sent via a connection request message.
  • the PDU may have a different name depending on a channel to be transmitted.
  • the PDU when a particular packet is transmitted in the advertising physical channel, the PDU becomes an advertising channel PDU, and when a particular packet is transmitted in the data physical channel, the PDU may be a data channel PDU.
  • the CRC has a 24-bit CRC at the end of every link layer packet.
  • CRC is calculated for the PDU.
  • the advertising channel PDU has a 16-bit header and various payloads.
  • the header includes a PDU Type field, an RFU field, a TxAdd field, an RxAdd field, and a Length field.
  • the PDU Type field indicates the type of the advertising channel PDU.
  • the TxAdd field and the RxAdd field include information specific to a PDU type defined individually for each advertising channel PDU.
  • TxAdd field or the RxAdd fields are not defined as used in a given PDU, the TxAdd field or RxAdd fields are reserved for future use.
  • the TxAdd field is a field indicating whether an advertiser's address is public or random. For example, when the TxAdd field is set to '0', it indicates that the advertiser's address is public and the TxAdd field is '1'. When set to ', it may represent that the address of the advertiser is random.
  • the RxAdd field is a field indicating whether an initiator address is public or random. For example, when the RxAdd field is set to '0', it indicates that the initiator address is public and the RxAdd field is' 1. When set to ', it may represent that the initiator address is random.
  • the Length field indicates the length of the payload.
  • the payload is specific to the PDU Type.
  • the payload of the advertising channel PDUs includes advertising data, the payload is specific to the PDU Type.
  • the payload included in the PDU consists of an AdvA field and an AdvData field, and the size of each payload depends on the PDU type.
  • the payloads of the advertising channel PDUs may be ADV_IND PDU, ADV_NONCONN_IND PDU, ADV_SCAN_IND PDU, etc. according to the PDU Type.
  • each ADV_IND PDU, ADV_NONCONN_IND PDU, and ADV_SCAN_IND PDU each include an AdvA field and an AdvData field.
  • the AdvA field is constant with a size of 6 octets, but the AdvData field varies in size depending on the PDU type.
  • the AdvA field includes the public or any device address of the advertiser indicated by TxAdd, and the AdvData field includes advertisement data.
  • the AdvData field includes at least one Length field and Data field.
  • the Length field of the AdvData field represents the length of the advertisement data
  • the Data field represents the advertisement data
  • the device connection information is included in the payload of the advertisement channel PDU, in particular, the AdvData field.
  • FIG. 9 illustrates an example of an advertisement data and a scan response data format proposed in the present specification.
  • the advertisement data and scan response data formats are composed of an important part and a non-critical part.
  • An important part contains a sequence of AD structures and includes at least one AD structure.
  • the non-critical portion extends the advertisement data and the scan response data up to 31 octets in size, with all octets set to zero.
  • One AD (Advertising Data) structure includes a Length field of 1 octet size and a Data field of Length octets size.
  • the Length field indicates the size of the AD structure.
  • the Data field includes an AD Type field having a size of n octets and an AD Data field having a length of n octets.
  • the AD Type field uses a value determined from an 'assigned numbers document' and may include the following information.
  • Manufacturer Specific Data Represents a company identifier code and manufacturer specific data.
  • TX Power level This indicates the transmit power level of the packet.
  • the TX Power level value is determined according to the distance.
  • OOB Security Manager Out of Band
  • the Security Manager is a software security management module of the host device and represents a security key value of the Security Manger.
  • Service Solicitation Represents a value used to request a connection from another device.
  • Service Data indicates service UUID and associated data.
  • the values of the AD Type field and the AD Data field included in the BLE advertisement data and scan response data format may be identically used in Table 2.
  • the device connection information may be included in the data field of the BLE advertisement data and scan response data format, in particular, the AD Data field.
  • FIG. 10 is a diagram illustrating an example of a packet structure including device connection information proposed in the present specification.
  • the packet structure including the device connection information may be a BLE or a Bluetooth BR / EDR packet structure.
  • FIG. 10A illustrates an example of an ADV_IND PDU Packet structure in a broadcasting mode
  • FIG. 10B illustrates an example of an ADV_IND PDU Packet structure in a unicasting mode.
  • the Advertising Packet (ADV_IND PDU) in Broadcasting Mode includes device connection information (Application, User, Network, Content) in the Data field in the AdvA Data field.
  • Each information of the device connection information may be represented by an application inquiry type value.
  • the advertising packet (ADV_IND PDU) in the unicasting mode may include device connection information (Application, User, Network, Content) in the Application Inquiry field in the PDU.
  • device connection information Application, User, Network, Content
  • the header field of FIGS. 10A and 10B may include a Mode field indicating whether the broadcast mode or the Uincasting mode.
  • FIG. 11 is a diagram illustrating another example of a packet structure including device connection information proposed in the present specification.
  • FIG. 11A illustrates an example of BCST_REQ structure, which is one of request packets used in Bluetooth communication
  • FIG. 11B illustrates an example of BCST_RSP structure, which is one of response packets used in Bluetooth communication.
  • BCST_REQ includes an Advertising Channel Packet Header, a Requester Address, an Application Inquiry, a Control, a Control Data, and a Requesting Data Type.
  • the salping device connection information may be included in the Requesting Data Type field.
  • the BCST_RSP includes an Advertising Channel Packet Header, Response Address, Application Response, Control, and BroadCast Data.
  • the BroadCast Data field includes a Length field and a Data field and has a structure in which one Length field and one Data field are repeated.
  • the data field includes salping device connection information in FIGS. 4 to 6 and may include one device connection information per one data field.
  • the data field may include an application type field, an application data field, a network interface field, a network interface data field, a user field, a user data field, a content type field, and a content type value field.
  • FIG. 12 is a flowchart illustrating an example of a method for exchanging device connection information using the packet structure of FIG. 11.
  • device 1 performs an application discovery procedure with a plurality of remote devices using BLE.
  • device 1 is in a broadcasting mode capable of transmitting a broadcast advertisement message, and a plurality of remote devices are in a scanning mode (or scanning state) capable of scanning an advertising packet.
  • the device 1 transmits an ADV_IND message to the remote devices (device 2 to device N) (S1210).
  • the remote devices transmit a BCST_RSP message including their application information to the device 1 (S1220).
  • the BCST_RSP message transmitted by the device 2 may include, for example, a value in which application information is set to 'LG SNS', user information is set to 'User 2', and network I / F information is set to 'Wi-Fi'.
  • the BCST_RSP message transmitted by the device N may include, for example, a value in which Application information is set to 'LG SNS', User information is set to 'User N', and Network I / F information is set to 'Wi-Fi'.
  • the device 1 selects a remote device to be connected based on the received BCST_RSP message, and transmits a BCST_RSP message including the device 1 information to the selected remote device (device 2) (S1230).
  • the BCST_RSP message transmitted by the device 1 is one example, the application information is 'LG SNS', the user information is 'User 1', the Network I / F information is 'Wi-Fi', Network Data, that is, SSID (Service) Set Identifier) may include a value set to 'LG SNS'.
  • the SSID may be a value representing a name of a network.
  • the device 2 turns on or activates a Bluetooth communication and another network interface (Wi-Fi Direct) to start exchanging Application (LG SNS) data with the device 1 (S1240).
  • Wi-Fi Direct Wi-Fi Direct
  • the remote devices that do not receive the BCST_RSP message from the device 1 cannot turn on the network interface turned on in the device 2 because they do not acquire the network interface information transmitted from the device 1.
  • the device 1 transmits and receives Application Data through another network communication (Wi-Fi) with the device 2 (S1250).
  • Wi-Fi Wi-Fi
  • FIG. 13 is a flowchart illustrating an example of a method for exchanging device discovery and connection information using tethering proposed in the present specification.
  • the device 1 and the device T have a wireless communication connection established through tethering (S1301).
  • the tethering refers to a method of connecting an IT device and a device that can access the Internet using a Bluetooth wireless technology or a USB cable.
  • it may refer to connecting an IT device such as a laptop to the Internet by using a smartphone capable of connecting to the Internet as a modem.
  • FIG. 13 illustrates a method in which a device T, which cannot access the Internet, searches for remote devices (devices 2 to N) and exchanges connection information with the corresponding remote devices by using the device 1 that can access the Internet.
  • the device 1 is a device capable of accessing the Internet.
  • the device 1 is a host device, and the device T is a tethered device connected to the device 1 through tethering.
  • the remote devices are in a scanning state capable of scanning Advertising Packets.
  • the device T transmits the BCST_REQ message described with reference to FIG. 12 to the device 1 through a tethered network interface (eg, Wi-Fi) (S1302).
  • a tethered network interface eg, Wi-Fi
  • the BCST_REQ message may include a value set as application information 'LG SNS', User information 'User N', and network interface information 'Wi-Fi'.
  • the device 1 transmits an ADV_IND message including the information received in step S1302 to the remote devices (S1303).
  • the device 1 transforms the information included in the received BCST_REQ message to the ADV_IND message format and transmits the information to the remote devices.
  • each remote device transmits a BCST_RSP message including its information to the device 1 (S1304).
  • the BCST_RSP message may include application information, user information, network I / F information, and the like.
  • the device 1 transmits the BCST_RSP message received in step S1304 to the device T through tethering (S1305).
  • the device T selects a remote device to share the content and turns on another network interface (Wi-Fi Direct) for sharing the content (S1306).
  • Wi-Fi Direct another network interface
  • the device T exchanges application data through the device 1 by using a different network interface with the selected remote device (device 2) (S1307).
  • the device 1 relays data transmission and reception between the device T and the device 2.
  • FIG. 14 is a diagram illustrating an example of a user interface output from devices proposed in the present specification.
  • FIG. 14A illustrates a UI corresponding to step S503 of FIG. 5, and shows a list of a plurality of remote devices displayed on the screen of device 1 and a user action for selecting a specific remote device.
  • FIG. 14B illustrates a UI corresponding to step S505 of FIG. 5, and shows device 1 information displayed on a screen of each remote device, and a selection screen for accepting a connection or rejecting a connection request of the device 1.
  • the content that device 1 wants to share with the remote device may be a photo, a file, SNS information, or the like.
  • Wi-Fi Direct connection information e.g., SSID, Group ID
  • WFDN Wi-Fi Direct Network
  • FIG. 15 is a flowchart illustrating an example of a method for exchanging Wi-Fi Direct connection information, handing over data transmission, and streaming between devices through Wi-Fi Direct using Bluetooth proposed in the present specification.
  • the source device 1 transmits a media stream to the sink device to reproduce media through the sink device (S1501).
  • the source device may refer to a portable device such as a smartphone that holds the content
  • the sink device refers to a device capable of receiving and playing content from the source device. And speaker.
  • the source device 2 broadcasts a BLE advertisement message including its network information and service information (eg, service IDs) for connection with a remote device, that is, a sink device, located nearby (S1502).
  • service information eg, service IDs
  • the BLE advertisement message including the network information and service information may be implemented as follows.
  • P2PGroupID “WFDP2P”
  • the Network Application Advertisement may include a device information (device / interface address) (DDI), a device type, a friendly name, a manufacturer, a model description, a model name, a UDN (UUID), a service list, and the like.
  • DCI device information
  • UUID UDN
  • the remote devices (source device 1, sink device, etc.) receiving the BLE advertisement message transmit a BLE response message including their information to the source device 2 (S1503).
  • the remote devices that transmit the BLE response message activate a network interface (Wi-Fi Direct) requested from the source device 2.
  • Wi-Fi Direct a network interface
  • the own information transmitted by each remote device may be network information, user information, service information, and the like.
  • the source device 2 selects a remote device to be connected based on the received BLE response message, and performs a Wi-Fi Direct Device Discovery procedure with the selected remote device (sink device) using Wi-Fi Direct communication. (S1504).
  • a procedure related to granting permission to use from the source device 1 currently using the sink device may be added before performing step S1504.
  • step S1504 is a case where the permission for use from the source device 1 is received.
  • the source device 2 selects a media to be output to the sink device and transmits a stream of the selected media to the sink device (S1505).
  • the source device 2 may transmit a Stream End Point Identifier (SEID) together with the selected media stream.
  • SEID Stream End Point Identifier
  • the advertiser used below represents a device that broadcasts an advertisement packet and may be represented as an advertising device, a first device, or the like.
  • An example of the advertiser may be various kinds of sensors.
  • the scanner represents a device having a central role, and may be represented by a second device.
  • the scanner may be a smartphone.
  • an advertiser unilaterally transmits an advertisement message (Beacon, advertisement packet, advertisement channel PDU) including an advertising URI.
  • Beacon advertisement message
  • advertisement channel PDU advertisement channel
  • the present specification provides a new security protocol, that is, a method of strengthening security related to an advertising URI through a method of exchanging request and response messages between devices.
  • a scanner when a scanner receives an advertising URI from an advertiser, the scanner does not directly access the received advertising URI, requests a security requirement related to the advertising URI as an advertiser, verifies the validity of the advertising URI, and then the advertising. Connect by URI
  • Advertise Security Flag field to the advertising message format used in Bluetooth, it is possible to support authentication of the server of the advertising URI, encryption of the advertising URI, and the like.
  • the scanner when the scanner receives an Advertising URI from an advertiser, the scanner requests security additional information related to validation of the Advertising URI from the advertiser.
  • the security additional information may be an encryption key, a signature key, an authentication certificate, or the like.
  • the advertiser transmits an advertisement packet including security information about the advertiser or the access server of the Advertising URI to the scanner according to the security additional information request of the scanner.
  • the advertising packet may include a secure URL, a certificate URL, or an HTTPS server URL.
  • the scanner checks the security information included in the advertising packet and validates the security information, that is, an encryption key, a signature key, and certificates (Authentication Certificates). Only when the validity is verified, a specific server URI is obtained to connect (or connect) to the specific server.
  • 16 is a flowchart illustrating an example of an advertisement URI security enhancement method using Bluetooth proposed in the present specification.
  • the advertiser transmits an advertisement message including service information such as Service Types and Service URIs and security features supported by each Service URI to the scanner using Bluetooth (S1601).
  • service information such as Service Types and Service URIs and security features supported by each Service URI to the scanner using Bluetooth (S1601).
  • a “message” may be expressed in various ways, such as a packet and a channel packet data unit (PDU).
  • PDU packet data unit
  • the advertiser may include various types of advertising profiles in the advertisement message and transmit the same.
  • the advertising profile may include an advertising service, an alert service, and a connection service.
  • the advertising service may include notification URIs, reservation URIs, control web URIs, and A / V streaming URIs.
  • the Alert Service may include an Alert Level (No, Mild, High).
  • the connection service may represent a wireless connection function or a network interface such as LTE, BLE, Wi-Fi, and BT BR / EDR.
  • the advertiser may perform a GAP Peripheral Role, Connectable mode, and an Advertise Link Loss Service.
  • the scanner selects a specific Service URI to be accessed among Service URIs based on the received advertisement message (S1602).
  • Examples of the service URIs may include a bus stop URI, a menu URI, a rental car URI, an exhibition URI, a shopping URI, a coupon URI, a web service URI, an alert message URI, and the like.
  • the scanner requests the advertiser for a Security Requirment associated with the selected Service URI to enhance security for the connection to the selected Service URI, i.e. to confirm that the connection to the selected Service URI is secure.
  • the scanner sends a Scan Request message to the advertiser for requesting security features of the selected Service URI.
  • the Scan Request message may include a Connection Signature required to sign data and verify signatures of Broadcaster, Link Encryption required, Authentication of Broadcaster required, and the like.
  • the advertiser transmits a Scan Response message including the security features requested to the scanner (S1603).
  • the scan response message may include a Signature Key, Authentication Key, Encryption Key, Certificates for the advertiser's keys, Secure URIs (e.g. https%), and the like.
  • the scanner verifies the safety of the Advertising URI received from the advertiser by using the Keys and Certificate of the advertiser included in the received Scan Response message, and if secured, accesses the Service Provider's Server through the Advertising URI.
  • service specific data related to the advertising URI is transmitted and received.
  • Servers of the service provider may have various servers according to services supported, and the various servers may be configured as one server or a plurality of individual servers.
  • Bus Stop info. Server As an example of the server, Bus Stop info. Server, Shopping Retail Server, Exhibition Server, Car Control Server, Weather Server, Location Server, Light Control Server, Fire Alert Server, File Alarm Server, Meeting Room Reservation Server.
  • the scanner and the advertiser may establish a security key exchange and security related setting through a message exchange in a connection state.
  • the scanner must trust the advertiser to verify that the advertiser's certificates are valid on the web server.
  • the advertiser must have a list of valid certificates by frequently updating the URIs of certificates or certificates that can be sent to the scanner so that the scanner can verify the validity of the advertiser's certificates.
  • Table 5 shows an example of the Advertising URI Data Type included in the advertisement message proposed herein.
  • Table 5 may also be used for Advertise URIs Request Type, GATT Service, GATT characteristics, GATT characteristic descriptors, and the like, which will be described later.
  • the advertising security mode defined in the advertising process using Bluetooth, the advertising security types supported in each mode, and a new advertisement message format (or structure) for supporting the same will be described.
  • Table 6 shows an example of Advertising security features (Advertising security mode, Advertising security type supported in each mode) included in the advertisement message, Scan Response message and the like.
  • LE Advertising Procedure Advertise Security Type Authorization required Advertiser Authentication required Service Provider URIs Authentication Required Encryption required LE Advertising Security Mode 1 1 No security 0XA1 X X X X 2 Unauthenticated Advertising with encryption 0XA2 X X X O 3 Authenticated Advertising with AdvertisingURI encryption 0XA3 X O X O 4 Authenticated Advertising with Advertising URI encryption and Server Authentication 0XA4 X O O O O LE Advertising Security Mode 2 1 Unauthenticated Advertising with data signing 0XB1 X X O 2 Authenticated Advertising with data signing 0XB2 X X O
  • Ad Security Mode includes two modes: Advertise Security Mode 1 and Advertise Security Mode 2.
  • the Advertise Security Mode 1 has four types of Advertise Security Types, and the Advertise Security Mode 2 has two types of Advertise Security Types.
  • the Advertising URI is encrypted with the Advertiser Encryption Key and transmitted.
  • the Advertise Security Type may be set to 0xA2, 0xA3 or 0xA4 as shown in Table 6.
  • the Advertiser Encryption Key Distribution field of the Advertising Security Flag is set to 'enable', and the Advertiser Encryption Key Distribution URI may be included in the Key Distribution URIs field.
  • the Advertising URI includes an Advertising URI Signature signed with an Advertiser Signature Key.
  • the Advertise Security Type may be set to 0xA3, 0xA4, or 0xB2.
  • Advertiser Signature Key Distribution field of the Advertising Security Flag may be set to 'enable', and the Advertiser Signature Key Distribution URI may be included in the Key Distribution URIs field.
  • the scanner may request to change the Advertising Security Type by sending a SCAN_REQ message to the advertiser.
  • the advertiser may enhance the security associated with the Advertising URI by adding an Advertise Security Flag in the advertisement message.
  • the advertiser transmits the advertising packet to the scanner according to the security change request (Secure URL, Certificate URL, HTTPS Server URL, etc.) of the scanner.
  • the security change request Secure URL, Certificate URL, HTTPS Server URL, etc.
  • the advertiser broadcasts an encrypted signal that can only be decrypted by the paired scanner.
  • Encrypted information transmitted from the advertiser cannot be decrypted by a device that is not paired with the advertiser.
  • the scanner checks the encrypted security information received from the advertiser, obtains a specific server URI only when valid through validation of the advertiser's security key, certificate, etc., and establishes a secure connection to the specific server. Perform.
  • a dedicated PDU type for transmitting the advertising URI may be additionally defined in the PDU Type field of the advertising channel PDU.
  • Table 7 is a table showing an example of the PDU Type field of the advertisement message proposed herein.
  • the information for the advertising URI and the application discovery described above may be included in the payload of the advertisement message, in particular, the AdvData field.
  • -User Information User ID, Name, User Preference, Account Information
  • Service Information Service ID, App ID, Cloud Service Provider Information
  • W-Fi e.g. SSID, Channel Information
  • Wi-Fi Direct Group ID
  • NFC NFC
  • Bluetooth Ethernet
  • Content Content Type (Video, Picture, Music, Documents)
  • the advertising URI may be the following information.
  • -Restaurant information and URIs menus, apps, payment information, coupons, etc.
  • Bus information and URIs Bus management server URIs, Bus Stop, number of buses at stops, arriving bus information.
  • -Payment Information Server URIs User ID, Name, User Preference, Account Information, Payment Server URIs
  • Asset location and URI room information (location, reservation schedule, subscriber, number of users, reservation server URIs)
  • URIs Public information, security, fire alert notifications and URIs: alert type, URIs, alert level (“No Alert,” “Mild Alert,” “High Alert,”), alert server URIs
  • Conference Information URIs Artifact Name, Position Number, Route Number, Floor Number
  • 17 is a diagram illustrating an example of an advertisement message structure proposed in the specification.
  • FIG. 17 illustrates an example of an ADV_NONCONN_IND message structure transmitted in the case of a non-connectable and undirected advertisement event among BLE advertisement messages.
  • a device for transmitting a connectable advertisement message refers to a device capable of receiving a connection request message from a receiving device (scanner, a device having a central role, for example, a phone) to connect with the receiving device.
  • a device for transmitting a non-connectable advertisement message refers to a device that cannot connect with the receiving device even when a connection request is received from the receiving device.
  • the ADV_NONCONN_IND message of FIG. 17 illustrates a structure of a message that an advertiser broadcasts to inform a scanner of an advertising URI.
  • the advertiser may generally support the advertisement URI and the advertisement security of the advertiser, but may support the Advertise Security Flag.
  • the AdvA Data field of the ADV_NONCONN_IND message may include at least one Advertising URI.
  • the at least one Advertising URIs may be Server URIs, App Download URIs, User / Network / Content information URIs, and the like.
  • the at least one Advertising URIs is included in a data field of the AdvA Data field.
  • the data field of the AdvA Data field includes an Advertise URI Type field, an Advertise security type field, a valid time stamp field, an Advertiser Name field, an Advertising URI field, an Advertise Security Flag field, and a Reserved field.
  • the Advertise URI Type field indicates the type of the Advertise URI, and may further include an Encoding method (UTF-8, etc.) of the Advertise URI, a protocol (http, ftp, ldap, urn, etc.) of the Advertise URI.
  • the Advertise security type field indicates a security technology (Encryption, Advertiser Authentication, Service Provider URI Authentication, Encryption) required when accessing an advertising URI.
  • the valid time stamp field indicates a valid period of security information defined in an advertisement message and an Advertise Security Flag field of the advertisement message.
  • the Advertise Security Flag field has a size of 1 octet and may include an Advertiser Encryption Key Distribution field, an Advertiser Id Key Distribution field, an Advertiser Signature Key Distribution field, an Advertiser Certificate Distribution field, and a Target Server Certificate Distribution field.
  • Each Distribution field has a size of 1 bit.
  • Each Distribution field indicates whether a URI for distributing an encryption key, an id key, a signature key, a certificate, and a certificate of a target server is set when the advertisement URI is accessed.
  • the Advertiser Encryption Key Distribution field, the Advertiser Id Key Distribution field, the Advertiser Signature Key Distribution field, the Advertiser Certificate Distribution field, and the Target Server Certificate Distribution field are sequentially located in bit values of the Advertise Security Flag field.
  • the Advertise Security Flag field indicates whether the advertiser supports security and the type of security supported.
  • the Advertise Security Flag field may display a security function for each bit in one octet.
  • the first bit (bit 1) of the Advertise Security Flag field is located in the Advertiser Encryption Key Distribution field.
  • the advertiser or scanner can generate an encryption key and deliver it to the other party.
  • the Advertiser Id Key Distribution field is located in the second bit (bit 2) of the Advertise Security Flag field.
  • the third bit (bit 3) of the Advertise Security Flag field is located in the Advertiser Signature Key Distribution field.
  • the fourth bit (bit 4) of the Advertise Security Flag field is located in the Advertiser Certificate Distribution field.
  • the fifth bit (bit 5) of the Advertise Security Flag field is located in the Target Server Certificate Distribution field.
  • the Advertise security type can be set to '0xA4', as shown in Table 6, and the second bit (bit 2), yes of the Advertise Security Flag field.
  • the fourth bit (bit 4) and the fifth (bit 5) are set respectively.
  • FIG. 18 is a flowchart illustrating an example of a method for obtaining information of an advertisement URI using the advertisement message of FIG. 17.
  • device 1 corresponds to an advertiser
  • device 2 corresponds to a scanner
  • device 3 corresponds to an application server / cloud.
  • the devices 1 to 3 perform a procedure for discovering an application and an advertising URI using BLE (S1801).
  • the device 1 is in a broadcasting mode, the device 2 is in a scanning state, and the device 3 is in a state capable of accommodating a device connecting through a URI.
  • the device 3 has a specific network interface (eg, Wi-Fi) enabled or activated to exchange data with a device connecting to the device 3 in addition to the Bluetooth communication.
  • a specific network interface eg, Wi-Fi
  • the device 1 transmits an ADV_NONCONN_IND message including an advertising URI and security information.
  • the device 2 Since the Advertise Security Flag is not set in the ADV_NONCONN_IND message, the device 2 does not perform a security information exchange procedure for strengthening the security of the advertising URI received from the device 1.
  • the device 2 selects an advertising URI based on the received ADV_NONCONN_IND message, and activates a network interface (eg, Wi-Fi) for accessing the selected advertising URI (S1802).
  • a network interface eg, Wi-Fi
  • the device 2 activates a Wi-Fi radio function (S1803), starts an application on a web browser, and accesses the selected advertising URI (S1804).
  • the device 2 exchanges application data with the device 3 through Wi-Fi communication (S1805).
  • Examples of the application data may include restaurant name, restaurant menu and its description language selection / change, coupon code, payment information, and the like.
  • the Advertise Security Flag when the Advertise Security Flag is set in the ADV_NONCONN_IND message of FIG. 18, the Advertise Security Flag includes an Advertiser Encryption Key Distribution field, an Advertiser ID Key Distribution field, an Advertiser Signature Key Distribution field, an Advertiser Certificate Distribution field, and a Target.
  • the device 2 connects each Key Distribution URI value corresponding to each Key Distribution field set in the Advertise Security Flag field to the received Advertising URI, that is, the device 3. It can be obtained by connecting.
  • FIG 19 illustrates another example of an advertisement message structure proposed in the specification.
  • FIG. 19 illustrates an example of an advertisement message structure in which URI values of respective key distributions included in the Advertise Security Flag field described in FIG. 18 are included in an extended PDU.
  • the advertisement message further includes an Extended PDU and Extended CRC field.
  • the Extended PDU may have a size of 0 to 256 octets, and the Extended CRC field may have a size of 0 to 3 octets.
  • the advertisement message may be represented by an ADV_NONCONN_IND_EXT message.
  • the ADV_NONCONN_IND_EXT message is sent when a non-connectable undirected advertisement event occurs.
  • the extended PDU is composed of a header extended length field and a data field.
  • the length of the Header Extended Length field is 8 bits.
  • the data field of the extended PDU includes respective key distribution URIs when each distribution field value is set in an Adverise Security Flag field.
  • the data field of the extended PDU includes URIs of the server distributing the advertiser's security key and certificate.
  • key distribution URIs are also sequentially set according to the data field of the extended PDU according to the number and order of enabled key distribution bits.
  • Advertiser Encryption Key For example, if the value set in the Advertise Security Flag in the data field of the PDU is Advertiser Encryption Key, Advertiser Id Key, Advertiser Signature Key, the Key Distribution URIs included in the data field of the Extended PDU are sequentially selected as Advertiser Encryption Key Distribution URI, Advertiser Id Key Distribution URI and Advertiser Signature Key Distribution URI may be included.
  • FIG. 20 is a flowchart illustrating an example of a method for obtaining advertisement URI information through the advertisement message structure of FIG. 19.
  • Steps S2002, S2003, S2005, and S2006 are the same as steps S1802 to S1085 of FIG. 18, and thus, detailed descriptions thereof will be omitted.
  • Device 1 transmits an ADV_NONCONN_IND_EXT message to device 2 (S2001).
  • the device 2 After operation S2003, the device 2 obtains the advertiser's keys and certificates for key distribution URIs included in the Extended Data field of the ADV_NONCONN_IND_EXT message from the device 3 (S2004).
  • the advertiser's keys may be an Advertiser Encryption Key, an Advertiser Id Key, an Advertiser Signature Key, and Certificates may be an Advertiser Certificate or a Secure Server Certificate.
  • the device 2 verifies the keys and certificates received from the device 1, Secure Server Certificates, and Server URIs based on the information received in step S2004. By doing so, the device 3 and the application data are exchanged (S2005).
  • 21 shows another example of an advertisement message structure proposed in the specification.
  • the ADV_IND message is almost the same as the structure of the ADV_NONCONN_IND message of FIG. 19, and differs only in the information included in the Advertising Security field.
  • the ADV_IND message includes an Advertiser Encryption Key Distribution field, an Advertiser Id Key Distribution field, an Advertiser Signature Key Distribution field, an Advertiser Certificate Distribution field, and a Secure Server Connection by Advertising URI field in the Advertising Security field.
  • the Secure Server Connection by Advertising URI field indicates whether a server connected through an Advertising URI is secure.
  • FIG. 22 is a flowchart illustrating an example of a method for obtaining advertisement URI information through the advertisement message structure of FIG. 21.
  • the advertisement message (ADV_IND message) of FIG. 22 is transmitted when the Connectable and undirected advertisement event occurs.
  • FIG. 22 illustrates that when an advertiser receives a security requirement request from a scanner because a Connectable advertisement message is used, the advertiser establishes a connection with the scanner and exchanges a security requirement (security key, certificate, server information, etc.) by exchanging a Request / Response message. Information can be exchanged.
  • S2201 and S2205 are the same as the steps S2001 and S2005 of FIG. 20, so a detailed description thereof will be omitted and only the differences will be described.
  • device 1 and device 2 After operation S2201, device 1 and device 2 perform a connection using BLE.
  • the device 2 transmits a Connect_REQ message to the device 1 (S2202).
  • the device 1 and the device 2 perform a data channel establishment procedure (S2203).
  • the device 1 transmits a data channel PDU to the device 2 (S2204).
  • the Data Channel PDU includes an Encryption Key / Signature Key / Identification Key / Certificate of Device 1, a Certificate of Device 3, a Secure URI of App Server (e.g. HTTPS), and the like.
  • the device 2 checks validity of keys / certificates and secure server URIs of the device 1 based on the received Data Channel PDU.
  • the device 2 selects an advertising URI and accesses the selected advertising URI through the other network interface, that is, the device 3, thereby exchanging application data with the device 3 (S2205).
  • FIG. 23 is a diagram illustrating another example of an advertisement message structure proposed in the specification.
  • FIG. 23 is a diagram illustrating another example of an advertisement message structure proposed in the specification.
  • the ADV_IND_EXT message is the same as the ADV_NONCONN_IND_EXT message structure of FIG.
  • the ADV_IND_EXT message includes key distribution URIs fields in the data field of the extended PDU.
  • FIG. 24 is a flowchart illustrating an example of a method for obtaining advertisement URI information through the advertisement message structure of FIG. 23.
  • device 1 transmits an ADV_IND_EXT message to device 2 (S2401).
  • the device 2 verifies the security of the advertising URIs through network communication other than the BLE used in steps S2401 to S2404.
  • step S2401 the device 2 turns on another network interface (Wi-FI) (S2402), starts an application through a web browser, and connects to a server corresponding to the selected advertising URI, that is, device 3 (S2402). S2403).
  • Wi-FI Wi-FI
  • the device 2 obtains advertiser keys and certificates from the device 3 in order to verify validity of Distribution URIs included in the Extended PDU Data field (S2404).
  • the advertiser keys may be an Advertiser Encryption Key, an Advertiser IdKey, an Advertiser Signature Key, and the Certificates may be an Advertiser Certificate or a Secure Server Certificate.
  • the device 2 verifies the keys and certificates of the device 1, and verifies the Secure Server Certificates and the Server URIs.
  • the device 2 selects an advertising URI and accesses the selected advertising URI through a Wi-Fi network interface. That is, the device 2 connects to the server corresponding to the selected advertising URI, that is, the device 3.
  • the device 2 exchanges application data with the device 3 (S2405).
  • An example of the application data may be restaurant name, restaurant menu and its description language selection / change, coupon code, payment information, and the like.
  • 25 is a flowchart illustrating still another example of a method for obtaining advertisement URI information proposed in the specification.
  • steps S2501 to S2503 and S2505 are the same as steps S2201 to S2203 and S2205 of FIG. 22, detailed descriptions thereof will be omitted.
  • FIG. 25 illustrates a method in which the device 1 transmits respective key distribution URIs through respective data channels after the secure connection is generated between the device 1 and the device 2 by BLE.
  • the device 1 performs a first data channel including the Advertiser's Encryption Key Distribution, a second data channel including the Advertiser's Identification Key Distribution, and a Device 3 Server Encryption Key Distribution.
  • the fourth data channel including the third data channel, the certificate distribution of the device 3, or the server certificate URI is transmitted to the device 2 (S2504).
  • the device 2 obtains the certificate of the device 3 by using the Server Certificate URI, thereby proving the certificate of the server, and exchanges application data through a different network interface with the device 3 (S2505).
  • FIG. 26 is a diagram illustrating another example of an advertisement message structure proposed in the specification.
  • FIG. 26 is a diagram illustrating another example of an advertisement message structure proposed in the specification.
  • ADV_URI_IND message structure wherein the ADV_URI_IND message refers to a dedicated advertisement message of an advertising URI.
  • the PDU Type value of the ADV_URI_IND message may be set to '1010'.
  • the data field of the ADV_URI_IND message may include a key distribution URIs field.
  • a key distribution URI corresponding to a distribution value set in the Advertise Security Flag field is included.
  • the Key Distribution URIs field includes Advertiser Encryption Key Distribution URI, Advertiser IdKey Distribution URI, Advertiser Signature Key Distribution URI in that order. .
  • FIG. 27 is a flowchart illustrating an example of a method of accessing an advertising URI of a scanner proposed in the present specification.
  • the scanner starts scanning (S2701) and performs scanning for receiving an advertisement message (S2702).
  • the scanner determines the validity of the Advertising URI included in the advertisement message (S2704).
  • the scanner determines whether an Advertiser Security Flag included in the advertisement message is set or enabled (S2705).
  • the scanner sends a Connection REQ message to the advertiser, thereby establishing a new connection with the advertiser (S2706).
  • step S2704 the scanner scans the advertisement message again.
  • the scanner receives the advertiser's keys and certificates set in the Advertiser Security Flag (S2707).
  • the advertiser's keys and certificates may be Encryption Key, IdKey, Certificates.
  • the scanner verifies the received advertiser's keys, certificates, Secure Server URIs (S2708).
  • the scanner checks whether the Advertising URI is encrypted (S2709).
  • the scanner decodes the Advertising URI using an encryption key of an advertiser (S2710).
  • the scanner checks whether the decoded Advertising URI is valid (S2711).
  • step S2709 if the Advertising URI is not encrypted, the scanner performs step S2711.
  • the scanner checks whether the Advertising URI is signed by an advertiser (S2712).
  • the scanner verifies the Signature of the Advertising URI using an Advertiser Signature Key (S2713).
  • the scanner checks whether the signature of the Advertising URI is valid (S2714).
  • the scanner turns on or activates a network interface (eg, Wi-Fi) for accessing the Internet (S2715).
  • a network interface eg, Wi-Fi
  • the scanner turns on the network interface at step S2715.
  • step S2715 if the Advertising URI is not signed by the advertiser, the scanner performs step S2715.
  • the scanner starts the application through a web browser and accesses the advertising URI (S2716).
  • the scanner verifies the server's Certificates (S2717). If the server's Certificates are verified, the scanner terminates the scanning of the advertisement message (S2718).
  • the scanner again performs the procedure of scanning an advertising message or validating the Advertising URI.
  • the advertiser may transmit the Advertising URI through the ADV_SCAN_IND message.
  • the ADV_SCAN_IND message is scanable and corresponds to an advertisement message used when a broadcasted advertisement event occurs.
  • the scanner may request the advertiser additional information related to the Advertising URI through the SCAN_REQ_ADV_URI message.
  • the advertiser may indicate that additional information (advertiser security key, certificate, server information, etc.) may be provided by transmitting a SCAN_RSP_ADV_URI message to the scanner in response to the SCAN_REQ_ADV_URI message.
  • the advertiser may transmit the Advertising URI through the ADV_SCAN_IND_EXT message.
  • the Extended PDU of the ADV_SCAN_IND_EXT message may include Key Distribution URIs.
  • the Key Distribution URIs are sequentially set in the data field of the Extended PDU according to the set number of the Key Distribution bits.
  • the Key Distribution URIs may include Advertiser Encryption Key Distribution URI, Advertiser Id Key Distribution URI, Advertiser Signature Key Distribution URI in that order. have.
  • FIG. 28 is a flowchart illustrating an example of a method of transmitting an advertising URI by a request of a scanner proposed in the present specification.
  • steps S2801 and S2804 to S2807 are the same as those of steps S2001 to S2005 in FIG. 20, a detailed description thereof will be omitted, and only differences will be described.
  • Device 1 transmits an ADV_SCAN_IND message (or ADV_SCAN_IND Channel PDU) to device 2 using BLE to discover an application and a URI (S2801).
  • the device 1 is an advertiser and the device 2 is a scanner.
  • the device 2 transmits a SCAN_REQ_ADV_URI message to the device 1 to request additional information related to the advertising URI (S2802).
  • the device 1 transmits a SCAN_RSP_ADV_URI message to the device 2 in response to the SCAN_REQ_ADV_URI message (S2803).
  • the additional information related to the advertising URI may be a security key, a certificate, server information, etc. associated with the device 1 and / or device 3.
  • FIG. 29 illustrates an example of a scan request message structure of FIG. 28.
  • FIG. 29 shows the structure of a SCAN_REQ_ADV_URI message.
  • the SCAN_REQ_ADV_URI message represents a message that the scanner sends to the advertiser to request the advertising URI and the additional information related to the advertising URI.
  • the scanner is in Scanning State and the advertiser is in Advertising State.
  • the SCAN_REQ_ADV_URI message includes a preamble, an access code, a PDU, and a cyclic redundancy check (CRC).
  • the PDU includes a Header field, a ScanA field (6 octets), an AdvA field (6 octets), an Advertise Security Request Type field (10 octets), and an Advertiser Setting field.
  • the PDU Type value of the SCAN_REQ_ADV_URI message may be set to '1100'.
  • the ScanA field represents an address of a scanner
  • the AdvA field represents an address of an advertiser
  • the Advertise URIs Request Type (1octet) field represents type information of an advertising URI that a scanner requests as an advertiser.
  • the advertiser when the advertiser receives the Advertise URIs Request Type value, the advertiser sets the Advertising Security Type in the SCAN_RSP_ADV_URI message and transmits the Advertising Security Type to the scanner.
  • the scanner may change the Advertise Security Type by transmitting SCAN_REQ_ADV_URI to the advertiser.
  • the scanner sets the Advertise Security Type Set (1bit) value of the Advertiser Setting of SCAN_REQ_ADV_URI and sends it to the advertiser
  • the advertiser enters the Advertising Security Mode according to the received Advertise Security Request Type when it supports the Advertise Security Type requested by the scanner. You can change it.
  • the advertiser may support the enhanced security of the advertising URI by adding the Advertise Security Flag requested from the scanner in the advertisement message when the Scanner requests.
  • the advertiser includes the information on the authentication of the advertiser, the authentication of the access server (Service Provider) of the Advertising URI, the encryption support of the Advertising URI, the Signature authentication of the Advertising URI in the Advertise Security Flag and transmits the information to the scanner.
  • the security strengthening of the advertising URI can be performed.
  • the scanner interprets the security information related to the advertising URI received from the advertiser, verifies the validity of the security key, certificate, etc., obtains a specific server URI if it is valid, and performs a secure connection to the corresponding server.
  • FIG. 30 illustrates an example of a scan response message structure of FIG. 28.
  • FIG. 30 shows an example of a SCAN_RSP_ADV_URI message structure.
  • the SCAN_RSP_ADV_URI message indicates a response message transmitted by the advertiser including the advertising URI information in response to the SCAN_REQ_ADV_URI transmitted by the scanner.
  • the SCAN_RSP_ADV_URI message includes a preamble, an access code, a PDU, and a CRC.
  • the PDU includes a Header field, an AdvA field, and a ScanRspData field.
  • the PDU Type of the SCAN_RSP_ADV_URI message may be set to '1101'.
  • the Data field of the ScanRspData field may include Advertise URI Type (1 octet), Advertise Security Type, Valid Time Stamp, Advertiser Name, Advertising URI, Advertise Security Flag (1 octet), and Key Distribution URIs (optional) fields.
  • the method of transmitting and receiving data according to the present specification is not limited to the configuration and method of the embodiments described as described above, but the embodiments are all or part of each embodiment is optional so that various modifications can be made. It may be configured in combination.
  • the method of transmitting and receiving data of the present disclosure can be implemented as a processor-readable code on a processor-readable recording medium provided in the network device.
  • the processor-readable recording medium includes all kinds of recording devices that store data that can be read by the processor. Examples of the processor-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, and the like, and may also be implemented in the form of a carrier wave such as transmission over the Internet. .
  • the processor-readable recording medium can also be distributed over network coupled computer systems so that the processor-readable code is stored and executed in a distributed fashion.
  • the present specification relates to a method for transmitting and receiving data in a wireless communication system and an apparatus for performing the same.

Landscapes

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

Abstract

본 명세서는 무선 통신 시스템에서 데이터를 송수신하는 방법에 있어서, 제 1 디바이스에 의해 수행되는 상기 방법은 디바이스 간 연결 정보를 포함하는 제 1 메시지를 제 1 네트워크를 통해 적어도 하나의 제 2 디바이스들로 전송하는 단계; 상기 제 1 메시지에 대한 응답을 상기 제 1 네트워크를 통해 상기 적어도 하나의 제 2 디바이스들로부터 수신하는 단계; 상기 응답에 기초하여 제 2 네트워크의 무선 연결을 요청하기 위한 연결 요청 메시지를 상기 제 1 네트워크를 통해 상기 적어도 하나의 제 2 디바이스들로 전송하는 단계; 상기 연결 요청 메시지의 응답에 해당하는 연결 응답 메시지를 상기 제 1 네트워크를 통해 상기 적어도 하나의 제 2 디바이스들로부터 수신하는 단계; 및 상기 제 2 네트워크를 통해 제 2 디바이스와 데이터를 송수신하는 단계를 포함하는 것을 특징으로 한다.

Description

무선 통신 시스템에서 데이터를 송수신하는 방법 및 이를 수행하기 위한 장치
본 명세서는 무선 통신 시스템에서 데이터를 송수신하는 방법 및 이를 수행하기 위한 장치에 관한 것이다.
최근 들어 블루투스(Bluetooth)의 사용이 일반화되고 있다. 블루투스는 고체, 비금속 물질을 관통하여 전송할 수 있다. 전송 범위는 10cm에서 10m이지만, 전송 전력을 증가시키면 100m까지 확장될 수 있다. 이는 저비용, 짧은 범위의 무선 링크에 기초하며, 고정 및 이동 통신 환경에서 애드 혹(ad hoc)접속을 용이하게 한다.
블루투스는 무선랜 규격인 802.11b/g와 동일한 ISM 대역인 2.45GHz 주파수를 사용하며, 블루투스 장치들은 주변의 블루투스 장치에 대한 검색/선택/인증(페어링) 등의 과정을 통해 무선 통신을 수행할 수 있다.
또한, 블루투스는 비교적 저전력, 저비용으로 비교적 빠른 속도를 낼 수 있으나, 전송 거리가 최대 100m로 한정적이므로, 한정된 공간에서 사용하기 적합하다.
스마트폰 보급의 확산에 따라 무선 통신 기술을 이용하여 디바이스들 간 멀티미디어 콘텐츠 공유, 화면 공유, 및 비 콘텐츠 공유 등이 다양하게 발생하고 있다.
종래에는 네트워크 연결 정보가 없는 다수의 디바이스 간에 정보를 공유하는 서비스를 제공하기 위해서, 디바이스에서 지원하는 네트워크 인터페이스 별로 검색, 연결, 보안 정보 설정 등의 여러 단계를 거쳐 디바이스 간 연결이 되었다.
따라서, 디바이스 간 연결 절차 수행 시, 많은 시간이 걸리고, 디바이스 및 서비스 검색을 위해 소요되는 네트워크의 전력 소모가 큰 문제가 있었다.
또한, 디바이스들이 서로 연결되었다고 하더라도 연결된 디바이스에서 공유하고자 하는 서비스를 지원하지 않는 경우, 또 다른 디바이스를 처음부터 다시 검색해야 되기 때문에 많은 시간과 디바이스의 리소스를 불필요하게 낭비하게 된다.
또한, 종래에는 광고를 전송하는 디바이스가 이를 수신하는 디바이스로 광고 데이터를 포함하는 비콘 등을 일방적으로 전송하였기 때문에, 수신 디바이스에서 광고 디바이스에서 전송하는 Advertising URI가 안전한 URI인지 또는 spam URIs인지를 구분하기가 어려워 보안에 취약한 문제가 있었다.
따라서, 상기와 같은 문제를 해결하기 위해, 본 명세서는 무선 통신 시스템(예: WPAN)에서 블루투스를 활용하여 디바이스 간 서비스 정보, 사용자 정보, 네트워크 정보, 콘텐츠 정보 등을 빠르게 검색 및 디바이스 간 연결을 수행하고, 다른 네트워크를 통해 데이터를 공유하기 위한 방법을 제공함에 목적이 있다.
또한, 본 명세서는 무선 통신 시스템에서 블루투스를 활용하여 광고, 홍보, 상태 정보 등을 나타내는URI 또는 URL와 이와 관련된 보안 정보를 디바이스 간에 공유함으로써, 안전하게 서비스를 공유하도록 하기 위한 방법을 제공함에 목적이 있다.
본 명세서에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 명세서는 무선 통신 시스템에서 데이터를 송수신하는 방법에 있어서, 제 1 디바이스에 의해 수행되는 상기 방법은 디바이스 간 연결 정보를 포함하는 제 1 메시지를 제 1 네트워크를 통해 적어도 하나의 제 2 디바이스들로 전송하는 단계; 상기 제 1 메시지에 대한 응답을 상기 제 1 네트워크를 통해 상기 적어도 하나의 제 2 디바이스들로부터 수신하는 단계; 상기 응답에 기초하여 제 2 네트워크의 무선 연결을 요청하기 위한 연결 요청 메시지를 상기 제 1 네트워크를 통해 상기 적어도 하나의 제 2 디바이스들로 전송하는 단계, 상기 연결 요청 메시지는 상기 제 2 네트워크를 나타내는 네트워크 연결 정보를 포함하며; 상기 연결 요청 메시지의 응답에 해당하는 연결 응답 메시지를 상기 제 1 네트워크를 통해 상기 적어도 하나의 제 2 디바이스들로부터 수신하는 단계; 및 상기 제 2 네트워크를 통해 제 2 디바이스와 데이터를 송수신하는 단계를 포함하되, 상기 디바이스 간 연결 정보는 상기 제 1 디바이스에서 지원하는 네트워크를 나타내는 네트워크 정보, 공유하고자 하는 서비스를 나타내는 서비스 정보, 상기 공유하고자 하는 서비스의 콘텐츠 타입을 나타내는 콘텐츠 타입 정보 또는 사용자와 관련된 정보를 나타내는 사용자 정보 중 적어도 하나를 포함하는 것을 특징으로 한다.
또한, 본 명세서에서 상기 제 1 네트워크는 블루투스이며, 상기 제 2 네트워크는 블루투스를 제외한 다른 무선 네트워크인 것을 특징으로 한다.
또한, 본 명세서에서 상기 제 1 메시지는 블루투스 BR(Basic Rate)/EDR(Enhanced Data Rate)의 질의(Inquiry) 메시지이거나 또는 BLE(Bluetooth Low Energy)의 광고 채널 PDU(Packet Data Unit)인 것을 특징으로 한다.
또한, 본 명세서는 상기 제 1 디바이스는 테더링(Tethering)을 통해 상기 적어도 하나의 제 2 디바이스들과 메시지를 송수신하며, 상기 제 2 디바이스와 데이터를 송수신하는 것을 특징으로 한다.
또한, 본 명세서에서 상기 제 1 메시지는 적어도 하나의 광고 URI(Uniform Resource Identifier)들 또는 상기 적어도 하나의 광고 URI들과 관련된 보안 정보 중 적어도 하나를 더 포함하는 것을 특징으로 한다.
또한, 본 명세서는 상기 적어도 하나의 제 2 디바이스들로부터 상기 적어도 하나의 광고 URI들과 관련된 보안 부가 정보를 요청하는 제 2 메시지를 수신하는 단계; 및 상기 적어도 하나의 제 2 디바이스들로 상기 요청된 보안 부가 정보를 포함하는 제 3 메시지를 전송하는 단계를 더 포함하는 것을 특징으로 한다.
또한, 본 명세서에서 상기 제 2 메시지는 광고 보안 요청 타입(Advertising Security Request Type) 필드를 포함하는 것을 특징으로 한다.
또한, 본 명세서에서 상기 제 3 메시지는 광고 보안 플래그(Advertising Security Flag) 필드 및 광고 보안 타입(Advertising Security Type) 필드를 포함하는 것을 특징으로 한다.
또한, 본 명세서는 상기 광고 보안 플래그(Advertising Security Flag) 필드에 다수의 Key Distribution 필드가 포함되는 경우, 상기 제 3 메시지는 상기 Key Distribution 필드 개수만큼 전송되며, 하나의 제 3 메시지마다 하나의 Key Distribution 필드가 포함되어 전송되는 것을 특징으로 한다.
또한, 본 명세서에서 상기 제 1 메시지는 Connectable 및 Undirected 광고 이벤트 발생 시 전송되거나 또는 Non-connectable 및 Undirected 광고 이벤트 발생 시 전송되는 것을 특징으로 한다.
또한, 본 명세서는 상기 제 1 메시지가 Connectable 및 Undirected 광고 이벤트 발생 시 전송되는 경우, 적어도 하나의 광고 URI들과 관련된 보안 정보는 상기 제 2 디바이스와 연결 확립된 후 교환되는 것을 특징으로 한다.
또한, 본 명세서에서 상기 적어도 하나의 광고 URI들과 관련된 보안 정보는 광고 URI 타입(Advertising URI Type) 필드, 광고 보안 타입(Advertising Security Type) 필드, 유효 타임 스탬프(Valid Time Stamp) 필드, 광고자 이름(Advertiser Name) 필드 또는 광고 보안 플래그(Advertiser Security Flag) 필드 중 적어도 하나를 포함하는 것을 특징으로 한다.
또한, 본 명세서에서 상기 광고 보안 플래그(Advertiser Security Flag) 필드는 광고자 암호화 키 분배(Advertiser Encryption Key Distribution) 필드, 광고자 ID 키 분배(Advertiser ID Key Distribution) 필드, 광고자 서명 키 분배(Advertiser Signature Key Distribution) 필드 또는 타겟 서버 증명서 분배(Target Server Certificate Distribution) 필드 중 적어도 하나를 포함하는 것을 특징으로 한다.
또한, 본 명세서에서 상기 제 1 메시지는 확장된 PDU 및 확장된 CRC를 더 포함하고, 상기 확장된 PDU는 적어도 하나의 Key Distribution URI를 더 포함하는 것을 특징으로 한다.
또한, 본 명세서에서 상기 제 1 디바이스는 광고자(Advertiser)이고, 상기 제 2 디바이스는 스캐너(Scanner)인 것을 특징으로 한다.
또한, 본 명세서는 무선 통신 시스템에서 데이터를 송수신하는 방법에 있어서, 제 1 디바이스는 외부와 유선 및/또는 무선으로 신호를 송수신하기 위한 통신부; 및 상기 통신부와 기능적으로 연결되는 제어부를 포함하되, 상기 제어부는 디바이스 간 연결 정보를 포함하는 제 1 메시지를 제 1 네트워크를 통해 적어도 하나의 제 2 디바이스들로 전송하고; 상기 제 1 메시지에 대한 응답을 상기 제 1 네트워크를 통해 상기 적어도 하나의 제 2 디바이스들로부터 수신하고; 상기 응답에 기초하여 제 2 네트워크의 무선 연결을 요청하기 위한 연결 요청 메시지를 상기 제 1 네트워크를 통해 상기 적어도 하나의 제 2 디바이스들로 전송하고; 상기 연결 요청 메시지의 응답에 해당하는 연결 응답 메시지를 상기 제 1 네트워크를 통해 상기 적어도 하나의 제 2 디바이스들로부터 수신하고; 상기 제 2 네트워크를 통해 제 2 디바이스와 데이터를 송수신하도록 제어하되, 상기 디바이스 간 연결 정보는 상기 제 1 디바이스에서 지원하는 네트워크를 나타내는 네트워크 정보, 공유하고자 하는 서비스를 나타내는 서비스 정보, 상기 공유하고자 하는 서비스의 콘텐츠 타입을 나타내는 콘텐츠 타입 정보 또는 사용자와 관련된 정보를 나타내는 사용자 정보 중 적어도 하나를 포함하며, 상기 연결 요청 메시지는 상기 제 2 네트워크를 나타내는 네트워크 연결 정보를 포함하는 것을 특징으로 한다.
또한, 본 명세서에서 상기 제어부는 상기 적어도 하나의 제 2 디바이스들로부터 상기 적어도 하나의 광고 URI들과 관련된 보안 부가 정보를 요청하는 제 2 메시지를 수신하고; 및 상기 적어도 하나의 제 2 디바이스들로 상기 요청된 보안 부가 정보를 포함하는 제 3 메시지를 전송하도록 제어하는 것을 특징으로 한다.
본 명세서는 블루투스를 활용하여 디바이스 간 사용자 정보, 서비스 정보, 네트워크 정보 등을 공유함으로써, 디바이스 간 다른 네트워크에 대한 연결을 빠르게 수행할 수 있도록 하는 효과를 제공한다.
또한, 본 명세서는 블루투스를 활용하여 광고, 홍보, 상태 정보 등을 나타내는URI 및 이와 관련된 보안 정보를 디바이스 간에 공유함으로써, 디바이스 간 안전하게 서비스를 공유할 수 있도록 하는 효과를 제공한다.
또한, 본 명세서는 멀티미디어 콘텐츠 재생을 원하는 다수의 디바이스를 사용하는 환경에서 사용자에게 용이성을 제공함으로써 UX(user experience)를 증대시킬 수 있는 효과를 제공한다.
본 명세서에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 명세서에서 제안하는 방법들이 적용될 수 있는 블루투스 저전력 에너지 아키텍처(Architecture)의 일 예를 나타낸 도이다.
도 2는 본 명세서에서 제안하는 방법들이 적용될 수 있는 디바이스들의 내부 블록도의 일 예를 나타낸 도이다.
도 3은 디바이스 간 콘텐츠를 공유하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 4는 본 명세서에서 제안하는 블루투스를 이용하여 디바이스 검색 및 연결 정보를 교환하는 방법의 일 예를 나타낸 흐름도이다.
도 5는 본 명세서에서 제안하는 블루투스를 이용하여 디바이스 검색 및 연결 정보를 교환하는 방법의 또 다른 일 예를 나타낸 흐름도이다.
도 6은 본 명세서에서 제안하는 블루투스를 이용하여 디바이스 검색 및 연결 정보를 교환하는 방법의 또 다른 일 예를 나타낸 흐름도이다.
도 7은 본 명세서에서 제안하는 새로운 확장 질의 응답 데이터 포맷의 일 예를 나타낸 도이다.
도 8은 본 명세서에서 제안하는 광고 메시지 포맷의 일 예를 나타낸 도이다.
도 9는 본 명세서에서 제안하는 광고 데이터 및 스캔 응답 데이터 포맷의 일 예를 나타낸다.
도 10은 본 명세서에서 제안하는 디바이스 연결 정보를 포함하는 패킷 구조의 일 예를 나타낸 도이다.
도 11은 본 명세서에서 제안하는 디바이스 연결 정보를 포함하는 패킷 구조의 또 다른 일 예를 나타낸 도이다.
도 12는 도 11의 패킷 구조를 이용한 디바이스 연결 정보 교환 방법의 일 예를 나타낸 흐름도이다.
도 13은 본 명세서에서 제안하는 테더링을 이용하여 디바이스 검색 및 연결 정보를 교환하는 방법의 일 예를 나타낸 흐름도이다.
도 14는 본 명세서에서 제안하는 디바이스들에서 출력되는 유저 인터페이스의 일 예를 나타낸 도이다.
도 15는 본 명세서에서 제안하는 블루투스를 이용하여 와이파이 다이렉트 연결 정보 교환, 와이파이 다이렉트를 통해 데이터 송수신 및 디바이스 간 스트리밍을 핸드오버하는 방법의 일 예를 나타낸 흐름도이다.
도 16은 본 명세서에서 제안하는 블루투스를 이용한 광고 URI 보안 강화 방법의 일 예를 나타낸 흐름도이다.
도 17은 본 명세서에서 제안하는 광고 메시지 구조의 일 예를 나타낸 도이다.
도 18은 도 17의 광고 메시지를 이용하여 광고 URI의 정보를 획득하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 19는 본 명세서에서 제안하는 광고 메시지 구조의 또 다른 일 예를 나타낸 도이다.
도 20은 도 19의 광고 메시지 구조를 통해 광고 URI 정보를 획득하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 21은 본 명세서에서 제안하는 광고 메시지 구조의 또 다른 일 예를 나타낸다.
도 22는 도 21의 광고 메시지 구조를 통해 광고 URI 정보를 획득하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 23은 본 명세서에서 제안하는 광고 메시지 구조의 또 다른 일 예를 나타낸 도이다.
도 24는 도 23의 광고 메시지 구조를 통해 광고 URI 정보를 획득하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 25는 본 명세서에서 제안하는 광고 URI 정보를 획득하기 위한 방법의 또 다른 일 예를 나타낸 흐름도이다.
도 26은 본 명세서에서 제안하는 광고 메시지 구조의 또 다른 일 예를 나타낸 도이다.
도 27은 본 명세서에서 제안하는 스캐너의 광고 URI 접속 방법의 일 예를 나타낸 순서도이다.
도 28은 본 명세서에서 제안하는 스캐너의 요청에 의해 광고 URI를 전송하는 방법의 일 예를 나타낸 흐름도이다.
도 29는 도 28의 스캔 요청 메시지 구조의 일 예를 나타낸다.
도 30은 도 28의 스캔 응답 메시지 구조의 일 예를 나타낸다.
이하에서는 도면을 참조하여 본 발명을 더욱 상세하게 설명한다.
이하의 설명에서 사용되는 구성요소에 대한 접미사 "모듈" 및 "부"는 단순히 본 명세서 작성의 용이함을 고려하여 부여되는 것으로서, 상기 "모듈" 및 "부"는 서로 혼용되어 사용될 수도 있다.
한편, 본 명세서에서 기술되는 디바이스(device)는 무선 통신이 가능한 디바이스로서, 스마트 폰을 포함한 휴대폰, 태블릿 PC, 데스크탑 컴퓨터, 노트북, 스마트 TV, IPTV 등을 포함한 텔레비전 등이 가능하다.
또한, 이하 첨부 도면들 및 첨부 도면들에 기재된 내용들을 참조하여 본 발명의 실시 예를 상세하게 설명하지만, 본 발명이 실시 예들에 의해 제한되거나 한정되는 것은 아니다.
본 명세서에서 사용되는 용어는 본 발명에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어를 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도 또는 관례 또는 새로운 기술의 출현 등에 따라 달라질 수 있다.
또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 발명의 설명 부분에서 그 의미를 기재할 것이다.
따라서 본 명세서에서 사용되는 용어는, 단순한 용어의 명칭이 아닌 그 용어가 가지는 실질적인 의미와 본 명세서의 전반에 걸친 내용을 토대로 해석되어야 함을 밝혀두고자 한다.

도 1은 본 명세서에서 제안하는 방법들이 적용될 수 있는 블루투스 저전력 에너지 아키텍처(Architecture)의 일 예를 나타낸 도이다.
도 1에 도시된 바와 같이, BLE 구조는 타이밍이 중요한 무선장치 인터페이스를 처리하도록 동작가능한 컨트롤러 스택(Controller stack)과 고레벨(high level) 데이터를 처리하도록 동작가능한 호스트 스택(Host stack)을 포함한다.
상기 Controller stack은 Controller로 호칭될 수도 있으나, 앞서 도 2에서 언급한 디바이스 내부 구성요소인 프로세서와의 혼동을 피하기 위해 이하에서는 Controller stack으로 표현하기로 한다.
먼저, 컨트롤러 스택은 블루투스 무선장치를 포함할 수 있는 통신 모듈과, 예를 들어, 마이크로프로세서와 같은 프로세싱 디바이스를 포함할 수 있는 프로세서 모듈을 이용하여 구현될 수 있다.
호스트 스택은 프로세서 모듈 상에서 작동되는 OS의 일부로서, 또는 OS 위의 패키지(package)의 인스턴스 생성(instantiation)으로서 구현될 수 있다.
일부 사례들에서, 컨트롤러 스택 및 호스트 스택은 프로세서 모듈 내의 동일한 프로세싱 디바이스 상에서 작동 또는 실행될 수 있다.
호스트 스택은 GAP(Generic Access Profile,410), GATT based Profiles(420), GATT(Generic Attribute Profile,430), ATT(Attribute Protocol,440), SM(Security Manage,450), L2CAP(Logical Link Control and Adaptation Protocol,460)을 포함한다. 다만, 호스트 스택은 이것으로 한정되지는 않고 다양한 프로토콜들 및 프로파일들을 포함할 수 있다.
호스트 스택은 L2CAP을 사용하여 블루투스 상위에서 제공하는 다양한 프로토콜, 프로파일 등을 다중화(multiplexing)한다.
먼저, L2CAP(Logical Link Control and Adaptation Protocol,460)은 특정 프로토콜 또는 프로파일에게 데이터를 전송하기 위한 하나의 양방향 채널을 제공한다.
L2CAP은 상위 계층 프로토콜들 사이에서 데이터를 다중화(multiplex)하고, 패키지(package)들을 분할(segment) 및 재조립(reassemble)하고, 멀티캐스트 데이터 송신을 관리하도록 동작 가능할 수 있다.
BLE 에서는 3개의 고정 채널(signaling CH을 위해 1개, Security Manager를 위해 1개, Attribute protocol을 위해 1개)을 사용한다.
반면, BR/EDR(Basic Rate/Enhanced Data Rate)에서는 동적인 채널을 사용하며, protocol service multiplexer, retransmission, streaming mode 등을 지원한다.
SM(Security Manager,450)은 디바이스를 인증하며, 키 분배(key distribution)를 제공하기 위한 프로토콜이다.
ATT(Attribute Protocol,440)는 서버-클라이언트(Server-Client) 구조로 상대 디바이스의 데이터를 접근하기 위한 규칙을 정의한다. ATT에는 6가지의 메시지 유형(Request, Response, Command, Notification, Indication, Confirmation)이 있다.
즉, ① Request 및 Response 메시지: Request 메시지는 클라이언트 디바이스에서 서버 디바이스로 특정 정보를 요청하기 위한 메시지이며, Response 메시지는 Request 메시지에 대한 응답 메시지로서, 서버 디바이스에서 클라이언트 디바이스로 전송되는 메시지를 말한다.
② Command 메시지: 클라이언트 디바이스에서 서버 디바이스로 특정 동작의 명령을 지시하기 위해 전송하는 메시지로, 서버 디바이스는 Command 메시지에 대한 응답을 클라이언트 디바이스로 전송하지 않는다.
③ Notification 메시지: 서버 디바이스에서 클라이언트 디바이스로 이벤트 등과 같은 통지를 위해 전송하는 메시지로, 클라이언트 디바이스는 Notification 메시지에 대한 확인 메시지를 서버 디바이스로 전송하지 않는다.
④ Indication 및 Confirm 메시지: 서버 디바이스에서 클라이언트 디바이스로 이벤트 등과 같은 통지를 위해 전송하는 메시지로, Notification 메시지와는 달리, 클라이언트 디바이스는 Indication 메시지에 대한 확인 메시지를 서버 디바이스로 전송한다.
GAP(Generic Access Profile)는 BLE 기술을 위해 새롭게 구현된 계층으로, BLE 디바이스들 간의 통신을 위한 역할 선택, 멀티 프로파일 작동이 어떻게 일어나는지를 제어하는데 사용된다.
또한, GAP는 디바이스 발견, 연결 생성 및 보안 절차 부분에 주로 사용되며, 사용자에게 정보를 제공하는 방안을 정의하며, 하기와 같은 attribute의 type을 정의한다.
① Service : 데이터와 관련된 behavior의 조합으로 디바이스의 기본적인 동작을 정의
② Include : 서비스 사이의 관계를 정의
③ Characteristics : 서비스에서 사용되는 data 값
④ Behavior : UUID(Universal Unique Identifier, value type)로 정의된 컴퓨터가 읽을 수 있는 포맷

GATT-based Profiles은 GATT에 의존성을 가지는 profile 들로 주로 BLE 디바이스에 적용된다. GATT-based Profiles은 Battery, Time, FindMe, Proximity, Time, Object Delivery Service 등일 수 있다. GATT-based Profiles의 구체적인 내용은 하기와 같다.
Battery : 배터리 정보 교환 방법
Time : 시간 정보 교환 방법
FindMe : 거리에 따른 알람 서비스 제공
Proximity : 배터리 정보 교환 방법
Time : 시간 정보 교환 방법
GATT는 서비스들의 구성 시에 ATT가 어떻게 이용되는지를 설명하는 프로토콜로서 동작가능할 수 있다. 예를 들어, GATT는 ATT 속성들이 어떻게 서비스들로 함께 그룹화되는지를 규정하도록 동작가능할 수 있고, 서비스들과 연계된 특징들을 설명하도록 동작가능할 수 있다.
따라서, GATT 및 ATT는 디바이스의 상태와 서비스들을 설명하고, 특징들이 서로 어떻게 관련되며 이들이 어떻게 이용되는지를 설명하기 위하여, 특징들을 사용할 수 있다.
컨트롤러(Controller) 스택은 물리 계층(Physical Layer,490), 링크 계층(Link Layer,480) 및 호스트 컨트롤러 인터페이스(Host Controller Interface,470)를 포함한다.
물리 계층(무선 송수신 모듈,490)은 2.4 GHz 무선 신호를 송수신하는 계층으로 GFSK (Gaussian Frequency Shift Keying) modulation과 40 개의 RF 채널로 구성된 frequency hopping 기법을 사용한다.
링크 계층(480)은 블루투스 패킷을 전송하거나 수신한다.
또한, 링크 계층은 3개의 Advertising 채널을 이용하여 Advertising, Scanning 기능을 수행한 후에 디바이스 간 연결을 생성하고, 37개 Data 채널을 통해 최대 42bytes 의 데이터 패킷을 주고 받는 기능을 제공한다.
HCI(Host Controller Interface)는 Host 스택과 Controller 스택 사이의 인터페이스를 제공하여, Host 스택에서 command와 Data를 Controller 스택으로 제공하게 하며, Controller 스택에서 event와 Data를 Host 스택으로 제공하게 해준다.

이하에서, 블루투스 저전력 에너지(Bluetooth Low Energy:BLE) 기술의 절차(Procedure)들에 대해 간략히 살펴보기로 한다.
BLE 절차는 디바이스 필터링 절차(Device Filtering Procedure), 광고 절차(Advertising Procedure), 스캐닝 절차(Scanning Procedure), 디스커버링 절차(Discovering Procedure), 연결 절차(Connecting Procedure) 등이 있다.
디바이스 필터링 절차(Device Filtering Procedure)
디바이스 필터링 절차는 컨트롤러 스택에서 요청, 지시, 알림 등에 대한 응답을 수행하는 디바이스들의 수를 줄이기 위한 방법이다. 모든 디바이스에서 요청 수신 시, 이에 대해 응답하는 것이 필요하지 않기 때문에, 컨트롤러 스택은 요청을 전송하는 개수를 줄여서, BLE 컨트롤러 스택에서 전력 소비가 줄어들도록 제어할 수 있다.
광고 디바이스 또는 스캐닝 디바이스는 광고 패킷, 스캔 요청 또는 연결 요청을 수신하는 디바이스를 제한하기 위해 상기 디바이스 필터링 절차를 수행할 수 있다.
여기서, 광고 디바이스는 광고 이벤트를 전송하는 즉, 광고를 수행하는 디바이스를 말하며, 광고자(Advertiser)라고도 표현된다.
스캐닝 디바이스는 스캐닝을 수행하는 디바이스, 스캔 요청을 전송하는 디바이스를 말한다.
BLE에서는, 스캐닝 디바이스가 의해 수신되는 일부 광고 패킷들을 광고 디바이스로부터 수신하는 경우, 스캐닝 디바이스는 광고 디바이스로 스캔 요청을 보낼 것을 필요로 한다. 만약, 디바이스 필터링 절차가 사용되어 스캔 요청이 전송되어야 할 광고 디바이스가 사전에 필터링되는 경우, 스캐닝 디바이스는 광고 디바이스에서 전송하는 광고 패킷들을 무시할 수 있다.
연결 요청 과정에서도 디바이스 필터링 절차가 사용될 수 있다. 만약, 연결 요청을 하는 디바이스에서 연결 요청에 대한 응답을 하는 디바이스에 대한 사전 디바이스 필터링 절차를 사용하지 않는 경우, 연결 요청을 수신한 디바이스(일 예로, 광고를 수행한 광고 디바이스)는 상기 연결 요청에 대해 응답하여야 한다.
연결 요청을 하는 디바이스는 개시 디바이스 또는 개시자(initiator)로 표현될 수 있다.
광고 디바이스는 스캔 요청 또는 연결 요청을 상기 광고 디바이스로 전송할 디바이스들을 제한하기 위해 디바이스 필터링 절차를 사용할 수 있다.
광고 절차(Advertising Procedure)
광고 디바이스는 영역 내 디바이스들로 비지향성 브로드캐스트를 수행하기 위해 광고 절차를 수행한다. 여기서, 비지향성 브로드캐스트는 특정 방향으로의 브로드캐스트가 아닌 전(모든) 방향으로의 브로드캐스트를 말한다. 이와 달리, 지향성 브로드 캐스트는 특정 방향으로의 브로드캐스트를 말한다. 비지향성 브로드캐스트는 광고 디바이스와 리스닝(또는 청취) 상태에 있는 디바이스(이하, 리스닝 디바이스라 한다.) 간에 연결 절차 없이 발생한다. 광고 절차는 근처의 개시 디바이스와 블루투스 연결을 확립하기 위해 사용된다. 또는 광고 절차는 광고 채널에서 리스닝을 수행하고 있는 스캐닝 디바이스들에게 사용자 데이터의 주기적인 브로드캐스트를 제공하기 위해 사용될 수 있다. 광고 절차에서 모든 광고(또는 광고 이벤트)는 광고 물리 채널을 통해 브로드캐스트된다.
BLE 피코넷에 연결되어 있는 BLE 디바이스는 광고 이벤트의 특정 타입을 사용하여 광고할 수 있다.
광고 디바이스들은 광고 디바이스로부터 추가적인 사용자 데이터를 얻기 위해 리스닝을 수행하고 있는 리스닝 디바이스들로부터 스캔 요청을 수신할 수 있다. 광고 디바이스는 스캔 요청을 수신한 광고 물리 채널과 동일한 광고 물리 채널을 통해, 스캔 요청을 전송한 디바이스로 스캔 요청에 대한 응답을 전송한다.
광고 패킷들의 일 부분으로서 보내지는 브로드캐스트 사용자 데이터는 동적인 데이터인 반면에, 스캔 응답 데이터는 일반적으로 정적인 데이터이다.
광고 디바이스는 광고 (브로드캐스트) 물리 채널 상에서 개시 디바이스로부터 연결 요청을 수신할 수 있다. 만약, 광고 디바이스가 연결 가능한 광고 이벤트를 사용하였고, 개시 디바이스가 디바이스 필터링 절차에 의해 필터링 되지 않았다면, 광고 디바이스는 광고를 멈추고 연결 모드(connected mode)로 진입한다. 광고 디바이스는 연결 모드 이후에 다시 광고를 시작할 수 있다.
스캐닝 절차(Scanning Procedure)
스캐닝을 수행하는 디바이스 즉, 스캐닝 디바이스는 광고 물리 채널을 사용하는 광고 디바이스들로부터 사용자 데이터의 비지향성 브로드캐스트를 청취하기 위해 스캐닝 절차를 수행한다.
스캐닝 디바이스는 광고 디바이스로부터 추가적인 사용자 데이터를 요청 하기 위해, 광고 물리 채널을 통해 스캔 요청을 광고 디바이스로 전송한다. 광고 디바이스는 광고 물리 채널을 통해 스캐닝 디바이스에서 요청한 추가적인 사용자 데이터를 포함하여 상기 스캔 요청에 대한 응답인 스캔 응답을 전송한다.
상기 스캐닝 절차는 BLE 피코넷에서 다른 BLE 디바이스와 연결되는 동안 사용될 수 있다.
만약, 스캐닝 디바이스가 브로드캐스트되는 광고 이벤트를 수신하고, 연결 요청을 개시할 수 있는 개시자 모드(initiator mode)에 있는 경우, 스캐닝 디바이스는 광고 물리 채널을 통해 광고 디바이스로 연결 요청을 전송함으로써 광고 디바이스와 블루투스 연결을 시작할 수 있다.
스캐닝 디바이스가 광고 디바이스로 연결 요청을 전송하는 경우, 스캐닝 디바이스는 추가적인 브로드캐스트를 위한 개시자 모드 스캐닝을 중지하고, 연결 모드로 진입한다.
디스커버링 절차(Discovering Procedure)
블루투스 통신이 가능한 디바이스(이하, 블루투스 디바이스라 한다.)들은 근처에 존재하는 디바이스들을 발견하기 위해 또는 주어진 영역 내에서 다른 디바이스들에 의해 발견되기 위해 광고 절차와 스캐닝 절차를 수행한다.
디스커버링 절차는 비대칭적으로 수행된다. 주위의 다른 디바이스를 찾으려고 하는 블루투스 디바이스를 디스커버링 디바이스(discovering device)라 하며, 스캔 가능한 광고 이벤트를 광고하는 디바이스들을 위해 찾기 위해 리스닝한다. 다른 디바이스로부터 발견되어 이용 가능한 블루투스 디바이스를 디스커버러블 디바이스(discoverable device)라 하며, 적극적으로 광고 (브로드캐스트) 물리 채널을 통해 다른 디바이스가 스캔 가능하도록 광고 이벤트를 브로드캐스트한다.
디스커버링 디바이스와 디스커버러블 디바이스 모두 피코넷에서 다른 블루투스 디바이스들과 이미 연결되어 있을 수 있다.
연결 절차(Connecting Procedure)
연결 절차는 비대칭적이며, 연결 절차는 특정 블루투스 디바이스가 광고 절차를 수행하는 동안 다른 블루투스 디바이스는 스캐닝 절차를 수행할 것을 요구한다.
즉, 광고 절차가 목적이 될 수 있으며, 그 결과 단지 하나의 디바이스만 광고에 응답할 것이다. 광고 디바이스로부터 접속 가능한 광고 이벤트를 수신한 이후, 광고 (브로트캐스트) 물리 채널을 통해 광고 디바이스로 연결 요청을 전송함으로써 연결을 개시할 수 있다.

이하에서, BLE 기술에서의 동작 상태 즉, 광고 상태(Advertising State), 스캐닝 상태(Scanning State), 개시 상태(Initiating State), 연결 상태(connection state)에 대해 간략히 살펴보기로 한다.
광고 상태(Advertising State)
링크 계층(LL)은 호스트 (스택)의 지시에 의해, 광고 상태로 들어간다. 링크 계층이 광고 상태에 있을 경우, 링크 계층은 광고 이벤트들에서 광고 PDU(Packet Data Unit)들을 전송한다.
각각의 광고 이벤트는 적어도 하나의 광고 PDU들로 구성되며, 광고 PDU들은 사용되는 광고 채널 인덱스들을 통해 전송된다. 광고 이벤트는 광고 PDU가 사용되는 광고 채널 인덱스들을 통해 각각 전송되었을 경우, 종료되거나 광고 디바이스가 다른 기능 수행을 위해 공간을 확보할 필요가 있을 경우 좀 더 일찍 광고 이벤트를 종료할 수 있다.
스캐닝 상태(Scanning State)
링크 계층은 호스트 (스택)의 지시에 의해 스캐닝 상태로 들어간다. 스캐닝 상태에서, 링크 계층은 광고 채널 인덱스들을 리스닝한다.
스캐닝 상태에는 수동적 스캐닝(passive scanning), 적극적 스캐닝(active scanning)의 두 타입이 있으며, 각 스캐닝 타입은 호스트에 의해 결정된다.
스캐닝을 수행하기 위한 별도의 시간이나 광고 채널 인덱스가 정의되지는 않는다.
스캐닝 상태 동안, 링크 계층은 스캔윈도우(scanWindow) 구간(duration) 동안 광고 채널 인덱스를 리스닝한다. 스캔인터벌(scanInterval)은 두 개의 연속적인 스캔 윈도우의 시작점 사이의 간격(인터벌)으로서 정의된다.
링크 계층은 스케쥴링의 충돌이 없는 경우, 호스트에 의해 지시되는 바와 같이 스캔윈도우의 모든 스캔인터벌 완성을 위해 리스닝해야한다. 각 스캔윈도우에서, 링크 계층은 다른 광고 채널 인덱스를 스캔해야한다. 링크 계층은 사용 가능한 모든 광고 채널 인덱스들을 사용한다.
수동적인 스캐닝일 때, 링크 계층은 단지 패킷들만 수신하고, 어떤 패킷들도 전송하지 못한다.
능동적인 스캐닝일 때, 링크 계층은 광고 디바이스로 광고 PDU들과 광고 디바이스 관련 추가적인 정보를 요청할 수 있는 광고 PDU 타입에 의존하기 위해 리스닝을 수행한다.
개시 상태(Initiating State)
링크 계층은 호스트 (스택)의 지시에 의해 개시 상태로 들어간다. 링크 계층이 개시 상태에 있을 때, 링크 계층은 광고 채널 인덱스들에 대한 리스닝을 수행한다.
개시 상태 동안, 링크 계층은 스캔윈도우 구간 동안 광고 채널 인덱스를 리스닝한다.
연결 상태(connection state)
링크 계층은 연결 요청을 수행하는 디바이스 즉, 개시 디바이스가 CONNECT_REQ PDU를 광고 디바이스로 전송할 때 또는 광고 디바이스가 개시 디바이스로부터 CONNECT_REQ PDU를 수신할 때 연결 상태로 들어간다.
연결 상태로 들어간 이후, 연결이 생성되는 것으로 고려된다. 다만, 연결이 연결 상태로 들어간 시점에서 확립되도록 고려될 필요는 없다. 새로 생성된 연결과 기 확립된 연결 간의 유일한 차이는 링크 계층 연결 감독 타임아웃(supervision timeout) 값뿐이다.
두 디바이스가 연결되어 있을 때, 두 디바이스들은 다른 역할로 활동한다.
마스터 역할을 수행하는 링크 계층은 마스터로 불리며, 슬레이브 역할을 수행하는 링크 계층은 슬레이브로 불린다. 마스터는 연결 이벤트의 타이밍을 조절하고, 연결 이벤트는 마스터와 슬레이브 간 동기화되는 시점을 말한다.

이하에서, 블루투스 인터페이스에서 정의되는 패킷에 대해 간략히 살펴보기로 한다. BLE 디바이스들은 하기에서 정의되는 패킷들을 사용한다.
패킷 포맷
링크 계층(Link Layer)은 광고 채널 패킷과 데이터 채널 패킷 둘 다를 위해 사용되는 단지 하나의 패킷 포맷만을 가진다.
각 패킷은 프리앰블(Preamble), 접속 주소(Access Address), PDU 및 CRC 4개의 필드로 구성된다.
하나의 패킷이 광고 물리 채널에서 송신될 때, PDU는 광고 채널 PDU가 될 것이며, 하나의 패킷이 데이터 물리 채널에서 전송될 때, PDU는 데이터 채널 PDU가 될 것이다.
광고 채널 PDU(Advertising Channel PDU)
광고 채널 PDU(Packet Data Unit)는 16비트 헤더와 다양한 크기의 페이로드를 가진다.
헤더에 포함되는 광고 채널 PDU의 PDU 타입 필드는 하기 표 1에서 정의된 바와 같은 PDU 타입을 나타낸다.
PDU Type Packet Name
0000 ADV-IND
0001 ADV_DIRECT_IND
0010 ADV_NONCONN_IND
0011 SCAN_REQ
0100 SCAN_RSP
0101 CONNECT_REQ
0110 ADV_SCAN_IND
0111-1111 Reserved
광고 PDU
아래 광고 채널 PDU 타입들은 광고 PDU로 불리고 구체적인 이벤트에서 사용된다.
ADV_IND: 연결가능한 비지향성 광고 이벤트
ADV_DIRECT_IND: 연결가능한 지향성 광고 이벤트
ADV_NONCONN_IND: 연결가능하지 않은 비지향성 광고 이벤트
ADV_SCAN_IND: 스캔가능한 비지향성 광고 이벤트
상기 PDU들은 광고 상태에서 링크 계층(Link Layer)에서 전송되고, 스캐닝 상태 또는 개시 상태(Initiating State)에서 링크 계층에 의해 수신된다.
Scanning PDUs
아래 광고 채널 PDU 타입은 스캐닝 PDU로 불리며, 하기에서 설명되는 상태에서 사용된다.
SCAN_REQ: 스캐닝 상태에서 링크 계층에 의해 전송되며, 광고 상태에서 링크 계층에 의해 수신된다.
SCAN_RSP: 광고 상태에서 링크 계층에 의해 전송되며, 스캐닝 상태에서 링크 계층에 의해 수신된다.
Initiating PDUs
아래 광고 채널 PDU 타입은 개시 PDU로 불린다.
CONNECT_REQ: 개시 상태에서 링크 계층에 의해 전송되며, 광고 상태에서 링크 계층에 의해 수신된다.
데이터 채널 PDU(Data Channel PDU)
데이터 채널 PDU는 16 비트 헤더, 다양한 크기의 페이로드를 가지고, 메시지 무결점 체크(Message Integrity Check:MIC) 필드를 포함할 수 있다.
앞에서 살펴본, BLE 기술에서의 절차, 상태, 패킷 포맷 등은 본 명세서에서 제안하는 방법들을 수행하기 위해 적용될 수 있다.

디바이스 내부 블록도
도 2는 본 명세서에서 제안하는 방법들이 적용될 수 있는 디바이스들의 내부 블록도의 일 예를 나타낸 도이다.
연결 개시 디바이스(Initiating Device,100)는 연결 대상 디바이스(200)에 명령을 내리는 요청 메시지(request message)를 전송하거나 연결 대상 디바이스(200)에서 요청되는 요청 메시지(request message)를 수신하여 처리하는 디바이스를 말한다.
연결 개시 디바이스(100)는 연결 대상 디바이스(200)로 요청 메시지를 전송한 후, 상기 연결 대상 디바이스로부터 전송되는 응답 메시지(response message)를 처리하여 사용자에게 UI를 제공한다.
또한, 연결 개시 디바이스(100)는 연결 대상 디바이스로부터 요청되는 request message를 수신하고, 이를 처리하여 사용자에게 UI를 제공한다.
연결 대상 디바이스(200)는 연결 개시 디바이스에 명령을 내리는 요청 메시지(request message)를 전송하거나 상기 연결 개시 디바이스에서 요청되는 요청 메시지(request message)를 수신하여 처리하는 디바이스를 말한다.
상기 연결 대상 디바이스(200)는 리모트 디바이스 또는 Initiated Device로 표현될 수 있다.
또한, 상기 연결 대상 디바이스(200)는 상기 연결 개시 디바이스로 request message를 전송하고, 상기 연결 개시 디바이스로부터 전송되는 response message를 수신하고, 이를 처리하여 사용자에게 UI를 제공한다.
상기 연결 개시 디바이스(100) 및 상기 연결 대상 디바이스(200)는 personal computer, PDA, mobile phone, remote controller, TV, headphone 또는 AV 장치(Car System, headphone, player/recorder, timer, tuner, monitor 등)일 수 있다.
상기 연결 개시 디바이스(100) 및 상기 연결 대상 디바이스(200)는 각각 출력부(110,210), 사용자 인터페이스 부(120,220), 메모리(130,230), 전원 공급부(140,240), 통신부(150,250), 제어부(프로세서,160,260) 및 데이터 처리 장치(170,270)를 포함할 수 있다.
상기 출력부, 사용자 인터페이스 부, 메모리, 전원 공급부, 통신부 및 제어부는 본 발명에서 제안하는 방법을 수행하기 위해 기능적으로 연결된다.
상기 도 2에 도시된 구성요소들이 필수적인 것은 아니어서, 그보다 많은 구성요소들을 갖거나 그보다 적은 구성요소들을 갖는 전자 기기를 구현될 수도 있다.
상기 출력부(110, 210)는 시각, 청각 또는 촉각 등과 관련된 출력을 발생시키기 위한 것으로, 이에는 디스플레이 모듈(112, 212), 음향 출력 모듈(114, 214) 등이 포함될 수 있다.
상기 디스플레이 모듈(112, 212)은 디바이스에서 처리되는 정보를 표시 출력한다. 예를 들어, 상기 디바이스가 통화 모드인 경우 통화와 관련된 UI(User Interface) 또는 GUI(Graphic User Interface)를 표시한다. 상기 디바이스가 화상 통화 모드 또는 촬영 모드인 경우에는 촬영 또는/및 수신된 영상 또는 UI, GUI를 표시한다.
상기 디스플레이 모듈(112, 212)는 액정 디스플레이(liquid crystal display), 박막 트랜지스터 액정 디스플레이(thin film transistorliquid crystal display), 유기 발광 다이오드(organic lightemitting diode), 플렉시블 디스플레이(flexible display), 3차원 디스플레이(3D display) 중에서 적어도 하나를 포함할 수 있다.
상기 음향 출력 모듈(114, 214)은 호신호 수신, 통화모드 또는 녹음 모드, 음성인식 모드, 방송수신 모드 등에서 통신부(150,250)로부터 수신되거나 메모리(130,230)에 저장된 오디오 데이터를 출력할 수도 있다. 상기 음향 출력 모듈(114, 214)은 상기 디바이스에서 수행되는 기능(예를 들어, 호신호 수신음, 메시지 수신음 등)과 관련된 음향 신호를 출력한다. 이러한 상기 음향 출력 모듈(114, 214)에는 리시버(Receiver), 스피커(speaker), 버저(Buzzer), 마이크(Mic) 등이 포함될 수 있다.
상기 마이크는 상대 디바이스에서 전송하는 Tone을 수신할 수 있으며, 상기 스피커는 상대 디바이스로 Tone을 송신할 수 있다.
여기서, Tone은 이하에서 살펴볼 Binary Data가 전환 행렬을 통해 소리로 변환된 신호를 의미한다.
상기 사용자 입력부(120, 220)는 사용자가 단말기의 동작 제어를 위한 입력 데이터를 발생시킨다. 사용자 입력부(120, 220)는 키 패드(key pad) 돔 스위치 (dome switch), 터치 패드(정압/정전), 조그 휠, 조그 스위치 등으로 구성될 수 있다.
상기 메모리(130, 230)는 제어부(160, 260)의 동작을 위한 프로그램을 저장할 수 있고, 입/출력되는 데이터들을 임시 저장할 수도 있다. 상기 메모리(130, 230)는 상기 터치스크린 상의 터치 입력시 출력되는 다양한 패턴의 진동 및 음향에 관한 데이터를 저장할 수 있다.
상기 메모리(130, 230)는 단말기의 각종 정보를 저장하는 매체로서, 상기 제어부와 연결되어 상기 제어부(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) 자기 메모리, 자기 디스크, 광디스크 중 적어도 하나의 타입의 저장매체를 포함할 수 있다.
상기 전원 공급부(140, 240)는 상기 제어부(160, 260)의 제어 하에 외부의 전원, 내부의 전원을 인가 받아 각 구성요소들의 동작에 필요한 전원을 공급해주는 모듈을 말한다.
상기 통신부(160, 260)는 디바이스와 무선 통신 시스템 사이 또는 디바이스와 디바이스가 위치한 네트워크 사이의 무선 통신을 가능하게 하는 하나 이상의 모듈을 포함할 수 있다. 예를 들어, 상기 통신부(160, 260)는 방송 수신 모듈(미도시), 이동통신 모듈(미도시), 무선 인터넷 모듈(미도시) 및 근거리 통신 모듈(미도시)을 포함할 수 있다.
상기 통신부(160, 260)는 송/수신부로 호칭될 수 있다.
상기 이동통신 모듈은, 이동 통신망 상에서 기지국, 외부의 단말, 서버 중 적어도 하나와 무선 신호를 송수신한다. 상기 무선 신호는, 음성 호 신호, 화상 통화 호 신호 또는 문자/멀티미디어 메시지 송수신에 따른 다양한 형태의 데이터를 포함할 수 있다.
상기 무선 인터넷 모듈은 무선 인터넷 접속을 위한 모듈을 말하는 것으로, 무선 인터넷 모듈은 디바이스에 내장되거나 외장 될 수 있다. 무선 인터넷 기술로는 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 연결을 통하여 디바이스간 스트리밍 서비스를 제공할 수 있으며, 데이터 송/수신 또는 프린터와 연결되어 프린팅 서비스를 제공할 수 있다.
상기 근거리 통신 모듈은 근거리 통신을 위한 모듈을 말한다. 근거리 통신 기술로 블루투스(Bluetooth), RFID(Radio Frequency Identification), 적외선 통신(IrDA, infrared Data Association), UWB(Ultra Wideband), ZigBee 등이 이용될 수 있다.
또한, 상기 통신부(150,250)는 디바이스 간(initiating device-initiated device) Command, request, action, response등의 message나 데이터 전송을 가능하게 해준다.
상기 제어부(160, 260)은 상기 상기 연결 개시 디바이스 및 상기 연결 대상 디바이스의 전반적인 동작을 제어하는 모듈을 말하며, 블루투스(Bluetooth) 인터페이스 및 다른 통신 인터페이스로 메시지를 전송 요청 및 수신받은 메시지를 처리하도록 제어할 수 있다.
상기 제어부(160, 260)는 컨트롤러(controller), 마이크로 컨트롤러(micro controller), 마이크로프로세서(microprocessor)등으로 호칭 될 수 있으며, 상기 제어부(160, 260)는 하드웨어(hardware), 펌웨어(firmware), 소프트웨어, 또는 이들의 결합에 의해 구현될 수 있다.
상기 제어부(160, 260)는 ASIC(application-specific integrated circuit), 다른 칩셋, 논리 회로 및/또는 데이터 처리 장치를 포함할 수 있다.

도 3은 디바이스 간 콘텐츠를 공유하기 위한 방법의 일 예를 나타낸 흐름도이다.
일반적으로 디바이스 간 콘텐츠(또는 데이터) 공유 과정은 먼저 네트워크를 탐색하고, 네트워크 접속 과정을 수행하고, 공유를 위한 콘텐츠의 지원 여부를 확인한다.
상기 콘텐츠 지원 여부 확인 결과에 따라, 디바이스 간 콘텐츠를 공유 또는 콘텐츠 공유가 가능한 디바이스를 찾을 때까지 앞의 과정을 반복적으로 수행한다.
구체적으로 도 3을 참조하여 살펴보면, 디바이스 1은 사용자로부터 수신 입력을 통해 특정 네트워크(예:network #1)를 활성화시키거나(activation) 턴온(turn-on)한다(S301).
여기서, 네트워크는 무선 통신, RAT(Radio Access Technology), 무선 (연결) 기능 등으로 표현될 수도 있다.
상기 디바이스 1이 연결할 수 있는 즉, 연결 대상에 해당하는 다수의 리모트 디바이스들(디바이스 2 내지 디바이스 N)은 현재 모든 네트워크 인터페이스 또는 무선 기능(wireless function)을 활성화 또는 턴온시켰다고 가정한다.
상기 네트워크 인터페이스 또는 무선 기능은 Bluetooth, Wi-Fi, Zigbee, 3G, 4G 등일 수 있다.
이후, 상기 디바이스 1은 활성화된 네트워크(network #1)를 통해 네트워크 디스커버리(network discovery)를 수행한다.
구체적으로, 상기 디바이스 1은 다수의 리모트 디바이스들로 네트워크 서치(network search)를 위한 메시지를 전송한다(S302).
이후, 상기 디바이스 1은 하나 또는 하나 이상의 리모트 디바이스들로부터 S302 단계에서 전송한 메시지에 대한 응답을 수신한다(S303).
이후, 상기 디바이스 1은 S303 단계의 응답을 전송한 리모트 디바이스들 중 하나의 리모트 디바이스와 연결을 확립하기 위해 연결 절차를 수행한다.
구체적으로, 상기 디바이스 1은 S303 단계의 응답을 전송한 리모트 디바이스들로 네트워크 접속을 위한 Connection Request 메시지를 전송한다(S304).
이후, 상기 Connection Request 메시지를 수신한 리모트 디바이스들은 네트워크 접속 요청에 대한 사용자의 확인을 수신하기 위해 ‘연결 수락’ 또는 ‘연결 거절’을 선택할 수 있는 UI를 출력부를 통해 출력한다(S305).
이후, 사용자로부터 ‘연결 수락’의 확인을 수신한 리모트 디바이스는 상기 디바이스 1로 네트워크 접속 요청에 대한 결과를 포함하는 Connection Response 메시지를 전송한다(S306).
이를 통해, 상기 디바이스 1은 어느 하나의 리모트 디바이스와 네트워크 접속을 확립한 후, 공유하고자 하는 Application이 디바이스들(디바이스 1 및 디바이스 1과 접속된 디바이스)에서 지원되는지를 확인한다(S307).
여기서, 상기 Application이 디바이스들에서 지원되는 경우, 상기 디바이스 1은 접속된 리모트 디바이스와 상기 Application과 관련된 데이터를 교환한다(S308).
여기서, 상기 Application과 관련된 데이터는 파일, 메시지, 제어 정보, A/V(Audio/Video) 등일 수 있다.
다만, 상기 Application이 디바이스들에서 지원되지 않는 경우, 상기 디바이스 1은 상기 Application을 공유할 수 있는 리모트 디바이스를 찾기 위해 S302 내지 S307 단계를 반복한다.
살핀 것처럼, 도 3의 방법을 통해 디바이스 간 콘텐츠 공유를 수행하는 경우, 디바이스에서 지원하는 네트워크 인터페이스 별로 검색, 연결, 보안 설정 등 여러 단계를 거쳐야 하기 때문에 디바이스 간 연결 및 정보 공유에 많은 시간과 많은 전력이 소요된다.
즉, 디바이스 간 네트워크 연결이 되었다고 하더라도 디바이스 또는 해당 네트워크에서 특정 서비스를 지원할 수 없는 경우, 처음부터 다시 다른 디바이스를 검색, 연결 등의 절차를 수행해야 하는 문제가 발생한다.

이하에서, 본 명세서에서 제안하는 WPAN(Wireless Personal Area Network)에서 블루투스(Bluetooth)를 이용하여 디바이스 간 서비스, 사용자 정보, 콘텐츠 정보에 대한 검색을 빠르게 수행하고, 블루투스 통신 외에 다른 네트워크 통신(Wi-Fi, Zigbee, 3G, 4G, 5G, NFC, RFID 등)을 통해 디바이스 간 콘텐츠를 공유하기 위한 방법(Protocol, Data Format, UI/UX 등)에 대해 살펴보기로 한다.
블루투스 통신에서는 블루투스 BR/EDR(Basic Rate/Enhanced Data Rate) 기술 및 블루투스 저전력 에너지(Low Energy) 기술 모두 적용 가능할 수 있다.

도 4는 본 명세서에서 제안하는 블루투스를 이용하여 디바이스 검색 및 연결 정보를 교환하는 방법의 일 예를 나타낸 흐름도이다.
WPAN 환경에서는 다수의 디바이스들이 존재할 수 있고, 상기 다수의 디바이스들은 제 1 디바이스 및 제 2 디바이스로 구분될 수 있다.
상기 제 1 디바이스는 다른 디바이스들과 콘텐츠 공유를 위해 디바이스 연결을 요청하는 디바이스일 수 있으며, 상기 제 2 디바이스는 연결 요청 대상에 해당하는 리모트 디바이스일 수 있다.
도 4에 도시된 바와 같이, 제 1 디바이스는 블루투스 통신을 이용하여 서비스 디스커버리(Service Discovery) 절차를 수행한다.
상기 블루투스 통신에는 BLE 기술 또는 Bluetooth BR/EDR 기술이 활용될 수 있으나, 이하에서는 BLE 기술을 일 예로 들어 설명하기로 한다.
상기 서비스 디스커버리 과정에 대해 구체적으로 살펴보면, 상기 제 1 디바이스는 네트워크 (타입) 정보, 사용자 정보, 콘텐트 타입 정보 또는 서비스 정보 중 적어도 하나를 포함하는 BLE Advertising 메시지를 전송한다(S401).
상기 BLE Advertising 메시지는 브로드캐스트 또는 유니캐스트 방식으로 전송될 수 있다.
상기 BLE Advertising 메시지는 Advertising Channel PDU(Packet Data Unit), Advertising Packet 등으로 표현될 수 있다.
상기 네트워크 정보는 디바이스에서 지원하는 네트워크 인터페이스를 나타내는 정보로, W-Fi(예: SSID, Channel Information), Wi-Fi Direct (Group ID), NFC, Bluetooth, Ethernet 등일 수 있다.
상기 사용자 정보는 디바이스를 사용하는 사용자와 관련된 정보로, User ID, 사용자 이름, 사용자 선호도(User Preference), 계좌 정보(Account Information) 등일 수 있다.
상기 서비스 정보는 디바이스에서 사용할 수 있는 또는 다른 디바이스와 공유하고자 하는 서비스를 나타내는 정보를 말하는 것으로, 서비스 ID, Application ID, Cloud Service Provider 정보 등일 수 있다.
상기 콘텐츠 타입(Contents Type) 정보는 사용할 수 있는 또는 공유하고자 하는 서비스의 콘텐츠 타입을 나타내는 것으로, 상기 콘텐츠 타입으로는 Video, Picture, Music, Documents 등이 있을 수 있다.
이후, 상기 BLE 광고 메시지를 수신한 적어도 하나의 제 2 디바이스들은 자신의 네트워크 정보, 사용자 정보, 서비스 정보 등을 포함하는 응답을 상기 제 1 디바이스로 전송한다.(S402)
이후, 상기 제 1 디바이스는 상기 적어도 하나의 제 2 디바이스들로부터 수신된 응답에 기초하여 공유하기 위한 사용자(또는 디바이스) 및 서비스를 선택한다(S403).
상기 서비스는 Facebook, Dropbox, Web Services, Picture, File Sharing, Message 등일 수 있으며, 도 4에서는 Picture 서비스가 선택되었음을 볼 수 있다.
이후, 상기 제 1 디바이스는 콘텐츠 공유를 위한 무선 통신 연결을 수행하기 위해 S403 단계에서 선택되는 제 2 디바이스로 네트워크 연결 요청(Network Connection Request) 메시지를 전송한다(S404).
여기서, 디바이스 검색 및 연결 정보 교환에 사용되는 무선 통신과 데이터 송수신에 사용되는 무선 통신은 다를 수 있다.
이후, 상기 제 1 디바이스는 상기 제 2 디바이스와 새로운 네트워크 연결을 확립하고, 상기 연결된 네트워크를 통해 서로 데이터를 교환한다(또는 송수신한다)(S405).

도 5는 본 명세서에서 제안하는 블루투스를 이용하여 디바이스 검색 및 연결 정보를 교환하는 방법의 또 다른 일 예를 나타낸 흐름도이다.
즉, 도 5는 BLE를 이용하여 디바이스 검색 및 연결 정보를 교환하는 방법을 나타낸다.
먼저, 디바이스 1은 사용자 입력 등을 통해 BLE 기능을 활성화 또는 턴온한다(S501).
여기서, 리모트 디바이스들에 해당하는 디바이스 2 내지 디바이스 N의 BLE 기능은 활성화된 상태(active)이고, 다른 무선 기능은 비활성화되어 있는 상태(inactive)라고 가정한다.
이후, 상기 디바이스 1은 BLE 기술을 이용하여 Application Discovery 절차를 수행한다.
상기 Application Discovery 절차는 Service Discovery 절차로 표현될 수도 있다.
구체적으로, 상기 디바이스 1은 리모트 디바이스들로 확장 질의 응답 (Extended Inquiry Response:EIR) 요청을 가지는 BLE Service Search를 전송한다(S502).
즉, 상기 디바이스 1은 리모트 디바이스들로부터 확장 질의 응답(EIR)을 수신하기 위해 BLE Service Search를 전송할 수 있으며, 상기 BLE Service Search는 Inquiry 메시지로 표현될 수도 있다.
이후, 상기 디바이스 1은 하나 또는 하나 이상의 리모트 디바이스들로부터 상기 BLE Service Search에 대한 응답을 수신한다(S503).
상기 BLE Service Search에 대한 응답은 EIR Data를 포함하고, 상기 EIR Data는 리모트 디바이스의 Application 정보, 사용자 정보, 네트워크 정보, 콘텐츠 타입 정보 등의 디바이스 연결 정보를 포함한다.
이후, 상기 디바이스 1은 상기 BLE Service Search에 대한 응답에 기초하여 Application을 선택하고, 특정 리모트 디바이스와 하나의 그룹을 형성하기 위해 네트워크 인터페이스 연결 과정을 수행한다(S504).
즉, 상기 디바이스 1은 디바이스 검색 및 연결 정보 교환에 사용하는 네트워크 인터페이스에 대해서는 블루투스를 이용하고, 데이터 공유 시 사용하는 네트워크 인터페이스에 대해서는 블루투스 이외 다른 네트워크를 이용한다.
구체적으로, 상기 디바이스 1은 S503 단계에서 수신된 정보에 기초하여 리모트 디바이스들로 다른 네트워크 인터페이스를 통한 연결을 요청하기 위해 Connection Request 메시지를 전송한다(S505).
이후, 리모트 디바이스들은 다른 네트워크 인터페이스의 연결 요청에 대해 사용자 확인을 수신하기 위해 연결 수락 또는 연결 거절을 선택할 수 있는 UI를 출력한다(S506).
여기서, ‘연결 수락’에 대한 사용자 입력을 수신한 리모트 디바이스는 활성화된 BLE 기능을 비활성화시키고(inactive), 콘텐츠 공유 시 사용하기 위한 다른 무선 기능 또는 다른 네트워크 인터페이스를 활성화시킨다(S507).
도 5에서, 디바이스 2는 사용자로부터 다른 네트워크 연결에 대한 연결 수락을 수신하였음을 볼 수 있다.
상기 디바이스 2는 상기 Connection Request 메시지에 대한 응답으로 Connection Response 메시지를 상기 디바이스 1로 전송한다(S508).
이후, 상기 디바이스 1과 상기 디바이스 2는 새롭게 연결된 다른 네트워크 인터페이스를 통해 Application Data를 교환한다(S509).

도 6은 본 명세서에서 제안하는 블루투스를 이용하여 디바이스 검색 및 연결 정보를 교환하는 방법의 또 다른 일 예를 나타낸 흐름도이다.
즉, 도 6은 Bluetooth BR/EDR(Basic Rate/Enhanced Data Rate)을 이용하여 디바이스 검색 및 연결 정보를 교환하는 방법을 나타낸다.
도 6을 참조하면, 디바이스 1은 블루투스 통신을 턴온하여 Application Discovery를 수행할 준비를 한다.
리모트 디바이스들에 해당하는 디바이스 2 내지 디바이스 N의 블루투스 무선 기능은 active 상태이며, 다른 무선 기능은 inactive 상태에 있다.
상기 디바이스 1은 사용자로부터 전송하고자 하는 item에 대한 선택 입력을 수신하고, 블루투스 무선 기능을 활성화시킨다(S601).
이후, 상기 디바이스 1은 리모트 디바이스들과 Bluetooth BR/EDR을 이용하여 Application Discovery 절차를 수행한다.
상기 Application Discovery 절차에 대해 구체적으로 살펴보면, 상기 디바이스 1은 주변에 연결할 리모트 디바이스들이 존재하는지를 확인하기 위해 Inquiry message를 전송한다(S602).
상기 디바이스 1은 상기 Inquiry message 에 포함하여 또는 별도의 메시지를 통해 사용자로부터 선택되는 Application 정보, 사용자 정보, Network Interface 정보, 콘텐츠 타입(contents type) 정보 등을 브로드캐스트한다.
여기서, 상기 Inquiry message 또는 별도의 메시지는 Advertising URI Type, Valid Time Stamp, Advertiser Name, Advertise Security Flag, Advertising URI Type 정보를 더 포함할 수 있다.
상기 Advertising URI Type, Valid Time Stamp, Advertiser Name, Advertise Security Flag, Advertising URI Type 정보에 대한 구체적인 설명은 도 17에서 살펴보기로 한다.
이후, 상기 디바이스 1은 상기 Inquiry 메시지를 수신한 리모트 디바이스들로부터 상기 리모트 디바이스에서 지원하는 Application 정보, User 정보, Network 인터페이스 정보, Contents Type 정보 등을 포함하는 응답 메시지를 수신한다(S603).
상기 S602 및 S603에서 살핀 Application 정보, User 정보, 다른 Network 인터페이스 정보, Contents Type 정보 등은 EIR Data에 포함되어 전송될 수 있다.
이후, 상기 디바이스 1은 S603 단계에서 수신한 응답 메시지에 기초하여 주변에 다수의 Application을 지원하는 리모트 디바이스가 존재하는지를 판단한다(S604).
여기서, 상기 디바이스 1은 상기 리모트 디바이스들로부터 수신된 디바이스 연결 정보 즉, Application 정보, Network Interface 정보 등을 출력부를 통해 출력할 수 있다.
따라서, 상기 디바이스 1의 사용자는 상기 디바이스 1의 출력부를 통해 출력된 결과 중 연결하고자 하는 Application 및 Network Interface를 선택할 수 있다.
이후, 상기 디바이스 1은 콘텐츠 공유 시 사용할 다른 네트워크 인터페이스를 연결하기 위해 리모트 디바이스들과 연결 절차를 수행한다.
구체적으로, 상기 디바이스 1은 S603 단계에서 확인된 리모트 디바이스들로 User Confirmation triggering 정보를 포함하는 Connection Request 메시지를 전송한다(S605).
상기 Connection Request 메시지는 상기 디바이스 1 로부터 선택되는 사용자 정보, 네트워크 정보, 서비스 확인 정보 등을 포함할 수 있다.
또한, 상기 Connection Request 메시지는 리모트 디바이스와 alternative carrier로 연결하는 경우 필요한 연결 정보들을 더 포함할 수 있다.
이후, 상기 Connection Request 메시지를 수신한 리모트 디바이스들은 User Confirmation triggering 정보를 통해 다른 네트워크 인터페이스에 대한 연결을 수락할 것인지 또는 거절할 것인지를 선택할 수 있도록 하는 UI를 출력부로 출력한다(S606).
이후, 각 리모트 디바이스들은 연결 수락 또는 연결 거절에 대한 사용자 입력의 수신에 따라 콘텐츠 공유를 위해 사용할 무선 연결 기능을 활성화시킨다. 이 때, 디바이스 검색 및 연결 정보 교환을 위해 활성화된 블루투스 무선 기능은 활성화 상태로 유지될 수 있으나, 전력 소모를 위해 비활성화되는 것이 바람직할 수 있다.
도 6의 경우, 디바이스 2는 사용자로부터 ‘연결 수락’에 대한 입력 수신 후, 상기 디바이스 1에 의해 선택되는 무선 연결 기능을 활성화시킨 것을 볼 수 있다(S607).
여기서, 디바이스 N은 사용자로부터 ‘연결 거절’에 대한 입력을 수신하였기 때문에, 상기 디바이스 1에 의해 선택되는 무선 연결 기능이 활성화되지 않는 것을 볼 수 있다.
이후, 상기 디바이스 2는 상기 디바이스 1로 Connection Request 메시지의 응답에 해당하는 Connection Response 메시지를 전송한다(S608).
상기 Connection Response 메시지는 상기 디바이스 2와 관련된 정보를 포함할 수 있다.
이후, 상기 디바이스 1과 상기 디바이스 2는 다른 네트워크 인터페이스의 연결 확립을 위해 필요한 추가적인 정보를 교환한 후, 새롭게 연결 확립된 다른 네트워크를 통해 application data를 송수신한다(S609).

이하에서, 도 7을 참조하여 도 6의 EIR Data 포맷에 대해 구체적으로 살펴보기로 한다.
도 7은 본 명세서에서 제안하는 새로운 확장 질의 응답 데이터 포맷의 일 예를 나타낸 도이다.
도 7을 참조하면, EIR Data 포맷은 240 octets의 크기를 가지며, 중요 부분(Significant part)과 비중요 부분(Non-significant part)으로 구성될 수 있다.
상기 중요 부분은 EIR 데이터 구조의 시퀀스를 포함하며, 각 EIR 데이터 구조는 1 octet 크기의 Length 필드 및 Length octets 크기의 Data 필드를 포함한다.
상기 Data 필드는 n octets 크기의 EIR Data Type 필드 및 Length–n octets 크기의 EIR Data 필드를 포함한다.
상기 비중요 부분은 EIR 크기를 240 octets까지 확장할 수 있으며, 모든 octets이 0으로 설정될 수 있다.
도 6에서 살펴본 Application Discovery에 사용되는 메시지들(Application Inquiry, Application Response, Application Connection Request, Application Connection Response)은 EIR Data Type에 의해 설정된 값에 의해 결정될 수 있다.
또한, 도 6에서 살펴본 디바이스 연결 정보 즉, Application 정보, 사용자 정보, 네트워크 정보, 콘텐츠 타입 정보는 EIR Data Structure 내 Data 필드 특히, EIR Data 필드에 포함될 수 있다.
또한, 상기 EIR Data 필드는 Advertising URI Type, Valid Time Stamp, Advertiser Name, Advertise Security Flag, Advertising URI Type 정보를 더 포함할 수 있다.
상기 User Information는 사용자와 관련된 정보로서, User ID, Name, User Preference, Account Information 등일 수 있다.
상기 Service Information는 서비스와 관련된 정보로, Service ID, App ID, Cloud Service Provider Information 등일 수 있다.
상기 Network Information는 Wi-Fi (e.g. SSID, Channel Information), Wi-Fi Direct (Group ID), NFC, Bluetooth, Ethernet 등일 수 있다.
상기 Content 정보는Content Type (Video, Picture, Music, Documents)일 수 있다.
표 2는 도 7의 EIR Data Type 필드의 일 예를 나타낸 표이다.
EIR Data Type Value Category Data Type Name EIR Data Value Description
0XA0 Application Inquiry Used for indentifying EIR Data as for Application Inquiry
0XA1 Application Response Used for indentifying EIR Data as for Application Response
0XA2 Application Connection Request Used for indentifying EIR Data as for Application Connection Response
0XA3 Application Connection Response Used for indentifying EIR Data as for Application Connection Request
0XA4 Inquiry Type
0XA5 Application
0XA6 User
0XA7 Network Interface
0XA8 Content Type
Application
0XB0 Application Name Name (e.g. Facebook, Dropbox, 카카오톡
0XB1 Application ID App/service developer name (e.g. Google, Apple, LG)
0XB2 Application Provider
User
0XC0 User Name User name
0XC1 AccountID accountid
0XC2 UserID Userid
0XC3 ProfileID Application defined profileid
Network
0XD0 Interface Name Wi-Fi, Wi-Fi Direct, 3G, LTE, LTE-A
0XD1 Connection Info Interface Specific Information
e.g. Wi-Fi SSID, Channel No., P2P Group ID
Content Type
0XE0 Message Text Message
0XE1 Picture Picture File
0XE2 Audio Audio File
0XE3 Video Video File
0XE4 Control Control Data (Request/Response)
0XE5 General Binary Data Calendar, Tasks, Notes

표 3은 EIR Data 필드에 포함되는 Application Inquiry 메시지 포맷의 일 예를 나타내며, 표 4는 EIR Data 필드에 포함되는 Application Response 메시지 포맷의 일 예를 나타낸다.
Value Note
0X01 Length of this Data
0XA0 Application Inquiry
0X04 Length of this Data
0XA4 Application
0XA5 User
0XA6 Network Interface
0XA7 Content Type
0XE5 End of Data(Not Transmitted over the air)
Value Note
0X01 Length of this Data
0XA1 Application Response
0X0A Length of this Data
0XB0 <<Application Name>>
0X4C ‘L’
0X47 ‘G’
0X47 ‘G’
0X61 ‘a’
0X6C ‘I’
0X6C ‘I’
0X65 ‘e’
0X72 ‘r’
0X79 ‘Y’
0X06 Length of this Data
0XC0 <<User Name>>
0X55 ‘U’
0X73 ‘s’
0X65 ‘e’
0X72 ‘r’
0X23 ‘2’
0X04 Length of this Data
0XD0 <<Interface Name>>
0X57 ‘W’
0X46 ‘F’
0X44 ‘D’
0X01 Length of this Data
0XE1 <<Picture>>
0XE5 End of Data(Not Transmitted over the air)
표 3 및 표 4를 참조하면, 디바이스 간 교환되는 Application은 LG Gallery를 나타내며, 연결하고자 하는 리모트 디바이스의 User는 User2이며, 다른 네트워크 인터페이스는 Wi-Fi Direct를 나타내며, 공유하고자 하는 콘텐츠 타입(Contents Type)은 사진을 나타낸다.

도 8은 본 명세서에서 제안하는 광고 메시지 포맷의 일 예를 나타낸 도이다.
링크 계층(Link Layer)에서는 하나의 패킷 포맷만을 가진다.
따라서, 광고 채널 패킷(advertising channel packet)과 데이터 채널 패킷(data channel packet)의 포맷은 동일하다.
상기 광고 채널 패킷은 광고 채널 PDU, 광고 메시지, 광고 데이터 등으로 표현될 수 있다.
상기 링크 계층 패킷 포맷은 도 8에 도시된 바와 같이, Preamble, Access Address, PDU 및 CRC를 포함한다.
먼저, 프리앰블은 1 octet, 접속 주소는 4 octets의 크기를 가진다. PDU 크기는 2 octets에서 최대 39 octets 크기를 가진다. CRC는 3 octets 크기이다.
상기 프리앰블은 상기 광고 채널 패킷에서 첫 번째로 전송되는 부분이고, 상기 프리앰블 이후부터 순차적으로 접속 주소, PDU 및 CRC가 전송된다.
이하에서, Preamble, Access Address, PDU 및 CRC에 대해 좀 더 구체적으로 설명한다.
모든 링크 계층 패킷들은 8 bit의 프리앰블을 가진다.
프리앰블은 주파수 동기(frequency synchronization), 심볼 타이밍 추정(symbol timing estimation) 및 자동 이득 제어(Automatic Gain Control:AGC) 트레이닝(training)을 수행하기 위해 리시버(receiver)에서 사용된다.
광고 채널 패킷들은 10101010b로 설정되는 프리앰블을 가진다.
데이터 채널 패킷의 프리앰블은 접속 주소의 LSB에 의존하는 10101010b 또는 01010101b 중 하나의 값을 가진다. 만약, 접속 주소의 LSB가 ‘1’인 경우, 상기 프리앰블은 01010101b이며, 그렇지 않은 경우에는 10101010b가 된다.
다음으로, 접속 주소(Access Address)는 모든 광고 채널 패킷들을 위한 접속 주소로 10001110100010011011111011010110b(0x8E89BED6)로 설정될 수 있다.
접속 주소는 임의의 32-bit 값이 될 수 있으며, initiating state 즉, 연결을 요청하는 디바이스에 의해 생성되고, connection request 메시지를 통해 전송된다.
다음으로, PDU는 전송되는 채널에 따라 그 명칭이 달라질 수 있다.
즉, 특정 패킷이 광고 물리 채널에서 전송될 때, PDU는 광고 채널 PDU가 되며, 특정 패킷이 데이터 물리 채널에서 전송될 때, PDU는 데이터 채널 PDU가 될 수 있다.
다음으로, CRC는 모든 링크 계층 패킷의 마지막에 24-bit CRC가 존재한다. CRC는 PDU에 대해 계산된다.
도 8에 도시된 바와 같이, 광고 채널 PDU는 16-bit 크기의 헤더(Header)와 다양한 크기의 페이로드(Payload)를 가진다.
상기 헤더는 PDU Type 필드, RFU 필드, TxAdd 필드, RxAdd 필드, Length 필드를 포함한다.
PDU Type 필드는 광고 채널 PDU의 타입을 나타낸다.
상기 TxAdd 필드 및 RxAdd 필드는 각각의 광고 채널 PDU에 개별적으로 정의된 PDU Type에 특정한 정보를 포함한다.
만약, TxAdd 필드 또는 RxAdd 필드들이 주어진 PDU에서 사용되는 것과 같이 정의되지 않는 경우, 상기 TxAdd 필드 또는 RxAdd 필드들은 future use를 위해 reserved된다.
상기 TxAdd 필드는 광고자(advertiser)의 주소가 public 인지 또는 random인지를 나타내는 필드로서, 일 예로, 상기 TxAdd 필드가 ‘0’으로 설정된 경우, 광고자의 주소는 public임을 나타내고, 상기 TxAdd 필드가 ‘1’로 설정된 경우, 광고자의 주소는 random임을 나타낼 수 있다.
상기 RxAdd 필드는 개시자(initiator)의 주소가 public 인지 또는 random인지를 나타내는 필드로서, 일 예로, 상기 RxAdd 필드가 ‘0’으로 설정된 경우, 개시자의 주소는 public임을 나타내고, 상기 RxAdd 필드가 ‘1’로 설정된 경우, 개시자의 주소는 random임을 나타낼 수 있다.
상기 Length 필드는 페이로드의 길이를 나타낸다.
광고 채널 PDU들에서 페이로드는 PDU Type에 특정하다.
또한, 광고 채널 PDU들의 페이로드는 광고 데이터를 포함하며, 상기 페이로드는 PDU Type에 특정하다.
PDU에 포함되는 페이로드는 AdvA 필드와 AdvData 필드로 구성되어 있으며, 각 페이로드의 크기는 PDU Type에 따라 다르다.
즉, 상기 광고 채널 PDU들의 페이로드는 PDU Type에 따라 ADV_IND PDU, ADV_NONCONN_IND PDU, ADV_SCAN_IND PDU 등일 수 있다.
또한, 각 ADV_IND PDU, ADV_NONCONN_IND PDU, ADV_SCAN_IND PDU는 각각 AdvA 필드 및 AdvData 필드를 포함한다.
구체적으로, AdvA 필드는 6 octets의 크기로 일정하나, AdvData 필드는 PDU Type에 따라 크기가 달라진다.
상기 AdvA 필드는 TxAdd에 의해 지시되는 광고자의 공개 또는 임의의 디바이스 주소를 포함하며, 상기 AdvData 필드는 광고 데이터를 포함한다.상기 AdvData 필드는 적어도 하나의 Length 필드 및 Data 필드를 포함한다.
상기 AdvData 필드의 Length 필드는 광고 데이터의 길이를 나타내며, Data 필드는 광고 데이터를 나타낸다.
도 4 내지 도 6에서 살핀, 디바이스 연결 정보는 광고 Channel PDU의 페이로드 특히, AdvData 필드에 포함된다.

도 9는 본 명세서에서 제안하는 광고 데이터 및 스캔 응답 데이터 포맷의 일 예를 나타낸다.
도 9에 도시된 바와 같이, 광고 데이터 및 스캔 응답 데이터 포맷은 중요 부분과 비중요 부분으로 구성된다.
중요 부분은 AD structure의 시퀀스를 포함하며, 적어도 하나의 AD Structure를 포함한다.
비중요 부분은 광고 데이터 및 스캔 응답 데이터를 31 octets 크기까지 확장하며, 모든 octets의 값이 0으로 설정된다.
하나의 AD(Advertising Data) structure는 1 octet 크기의 Length 필드 및 Length octets 크기의 Data 필드를 포함한다.
상기 Length 필드는 AD structure의 크기를 나타낸다.
상기 Data 필드는 n octets 크기의 AD Type 필드 및 Length-n octets 크기의 AD Data 필드를 포함한다.
상기 AD Type 필드는 ‘assigned numbers document’에서 정해진 값을 사용하며, 아래와 같은 정보들을 포함할 수 있다.
- Service UUID(Universal Uinque Identifier): bit 별로 다른 값을 가질 수 있음
- Local Name: 하나만 포함될 수 있음
- Flags
- Manufacturer Specific Data: 회사 식별 코드(company identifier code) 및 제조사 특정 데이터(manufacture specific data)를 나타낸다.
- TX Power level: 패킷의 송신 전력 레벨을 나타내는 것으로, 거리에 따라 TX Power level 값이 결정된다.
- Security Manager Out of Band (OOB): 디바이스 pairing 과정 중에 보안 관련 정보를 나타낸다.
- Security Manager TK(Temperal Key) Value: Security Manager는 Host 디바이스의 소프트웨어 보안 관리 모듈로서, 상기 Security Manger의 보안 키 값을 나타낸다.
- Slave Connection Interval Range: 슬레이브 디바이스의 연결 요청 전송 간격을 나타낸다.
- Service Solicitation: 다른 디바이스에게 connection을 요청하기 위해서 사용되는 값을 나타낸다.
- Service Data: service UUID 및 associated data를 나타낸다.
Application pairing 정보 교환을 위해 BLE 광고 데이터 및 스캔 응답 데이터 포맷에 포함되는 AD Type 필드와 AD Data 필드 값은 앞의 표 2의 값을 동일하게 사용할 수 있다.
즉, 도 4 내지 도 6에서 살핀, 디바이스 연결 정보는 BLE 광고 데이터 및 스캔 응답 데이터 포맷의 데이터 필드 특히, AD Data 필드에 포함될 수 있다.

도 10은 본 명세서에서 제안하는 디바이스 연결 정보를 포함하는 패킷 구조의 일 예를 나타낸 도이다.
상기 디바이스 연결 정보를 포함하는 Packet Structure는 BLE 또는 Bluetooth BR/EDR Packet Structure일 수 있다.
도 10a는 Broadcasting Mode의 ADV_IND PDU Packet 구조의 일 예를 나타내며, 도 10b는 Unicasting Mode의 ADV_IND PDU Packet 구조의 일 예를 나타낸다.
도 10a에 도시된 바와 같이, Broadcasting Mode의 Advertising Packet(ADV_IND PDU)은 디바이스 연결 정보(Application, User, Network, Content)를 AdvA Data 필드 내 Data 필드에 포함한다.
상기 디바이스 연결 정보의 각 정보는 Application inquiry type value으로 표현될 수 있다.
도 10b에 도시된 바와 같이, Unicasting Mode의 Advertising Packet(ADV_IND PDU)은 디바이스 연결 정보(Application, User, Network, Content)를 PDU 내 Application Inquiry 필드에 포함할 수 있다.
도 10a 및 도 10b의 Header 필드는 Broadcasting mode인지 또는 Uincasting mode인지를 나타내는 Mode 필드를 포함할 수 있다.

도 11은 본 명세서에서 제안하는 디바이스 연결 정보를 포함하는 패킷 구조의 또 다른 일 예를 나타낸 도이다.
도 11a는 블루투스 통신에서 사용되는 Request Packet의 하나인 BCST_REQ구조의 일 예를 나타내며, 도 11b는 블루투스 통신에서 사용되는 Response Packet의 하나인 BCST_RSP 구조의 일 예를 나타낸다.
도 11a에 도시된 바와 같이, BCST_REQ는 Advertising Channel Packet Header, Requester Address, Application Inquiry, Control, Control Data 및 Requesting Data Type을 포함한다.
도 4 내지 도 6에서 살핀 디바이스 연결 정보는 상기 Requesting Data Type 필드에 포함될 수 있다.
도 11b에 도시된 바와 같이, BCST_RSP는 Advertising Channel Packet Header, Response Address, Application Response, Control 및 BroadCast Data를 포함한다.
상기 BroadCast Data 필드는 Length 필드 및 Data 필드를 포함하며, 하나의 Length 필드와 하나의 Data 필드가 반복되는 구조이다.
상기 Data 필드는 도 4 내지 도 6에서 살핀 디바이스 연결 정보를 포함하며, 하나의 Data 필드 당 하나의 디바이스 연결 정보를 포함할 수 있다.
즉, Data 필드별로 Application Type 필드 및 Application Data 필드, Network Interface 필드 및 Network Interface Data 필드, User 필드 및 User Data 필드, Content Type 필드 및 Content Type Value 필드를 포함할 수 있다.

도 12는 도 11의 패킷 구조를 이용한 디바이스 연결 정보 교환 방법의 일 예를 나타낸 흐름도이다.
도 12를 참조하면, 디바이스 1은 BLE를 이용하여 다수의 리모트 디바이스들과 Application Discovery 절차를 수행한다.
여기서, 디바이스 1은 브로드 캐스팅 광고 메시지를 전송할 수 있는 브로드캐스팅 모드에 있으며, 다수의 리모트 디바이스들은 Advertising Packet을 스캐닝할 수 있는 스캐닝 모드(또는 스캐닝 상태)에 있다.
즉, 상기 디바이스 1은 리모트 디바이스들(디바이스 2 내지 디바이스 N)로 ADV_IND 메시지를 전송한다(S1210).
상기 ADV_IND 메시지는 Mode=Broadcasting, Inquiry type=Application, User, Network I/F 정보를 포함할 수 있다.
이후, 상기 리모트 디바이스들은 각각 상기 디바이스 1로 자신의 Application 정보를 포함하는 BCST_RSP 메시지를 전송한다(S1220).
즉, 상기 디바이스 2가 전송하는 BCST_RSP 메시지는 일 예로, Application 정보가 ‘LG SNS’, User 정보가 ‘User 2’, Network I/F 정보가 ‘Wi-Fi’로 설정된 값을 포함할 수 있다.
또한, 상기 디바이스 N이 전송하는 BCST_RSP 메시지는 일 예로, Application 정보가 ‘LG SNS’, User 정보가 ‘User N’, Network I/F 정보가 ‘Wi-Fi’로 설정된 값을 포함할 수 있다.
이후, 상기 디바이스 1은 상기 수신된 BCST_RSP 메시지에 기초하여 연결을 하고자 하는 리모트 디바이스를 선택하고, 상기 선택된 리모트 디바이스(디바이스 2)로 상기 디바이스 1의 정보를 포함하는 BCST_RSP 메시지를 전송한다(S1230).
상기 디바이스 1이 전송하는 BCST_RSP 메시지는 일 예로, Application 정보가 ‘LG SNS’로, 사용자 정보는 ‘User 1’로, Network I/F 정보는 ‘Wi-Fi’로, Network Data 즉, SSID(Service Set Identifier)는 ‘LG SNS’로 설정된 값을 포함할 수 있다. 상기 SSID는 네트워크의 이름을 나타내는 값일 수 있다.
이후, 상기 디바이스 2는 상기 디바이스 1과 Application(LG SNS) 데이터 교환을 시작하기 위해 블루투스 통신과 다른 네트워크 인터페이스(Wi-Fi Direct)를 턴온 또는 활성화시킨다(S1240).
여기서, 상기 디바이스 1로부터 BCST_RSP 메시지를 수신하지 못한 리모트 디바이스들은 상기 디바이스 1에서 전송하는 네트워크 인터페이스 정보를 획득하지 못하기 때문에 상기 디바이스 2에서 턴온한 네트워크 인터페이스를 턴온할 수 없다.
이후, 상기 디바이스 1은 상기 디바이스 2와 다른 네트워크 통신(Wi-Fi) 을 통해 Application Data를 송수신한다(S1250).

도 13은 본 명세서에서 제안하는 테더링을 이용하여 디바이스 검색 및 연결 정보를 교환하는 방법의 일 예를 나타낸 흐름도이다.
도 13에 도시된 바와 같이, 디바이스 1과 디바이스 T는 테더링(Tethering)을 통해 무선 통신 연결이 확립되어 있다(S1301).
상기 테더링이란 블루투스(Bluetooth) 무선 기술, USB케이블 등을 이용해 인터넷 접속이 가능한 디바이스와 IT디바이스를 연결하는 방법을 말한다.
일 예로, 인터넷 접속을 할 수 있는 스마트폰을 모뎀(modem)처럼 이용하여 노트북 등과 같은 IT 디바이스를 인터넷에 접속하는 것을 말할 수 있다.
즉, 도 13은 인터넷 접속이 불가능한 디바이스 T가 인터넷 접속이 가능한 디바이스 1을 이용하여 리모트 디바이스들(디바이스 2 내지 N) 검색 및 해당 리모트 디바이스들과 연결 정보를 교환하는 방법을 나타낸다.
상기 디바이스 1은 인터넷 접속이 가능한 디바이스로서, 호스트 디바이스(Host Device)이며, 상기 디바이스 T는 상기 디바이스 1에 테더링을 통해 연결되어 있는 Tethered Device이다.
또한, 리모트 디바이스들(디바이스 2 내지 디바이스 N)은 광고 패킷(Advertising Packet)들을 스캐닝할 수 있는 스캐닝 상태에 있다.
먼저, 상기 디바이스 T는 Tethered 네트워크 인터페이스(예: Wi-Fi)를 통해 도 12에서 살펴본 BCST_REQ 메시지를 상기 디바이스 1로 전송한다(S1302).
상기 BCST_REQ 메시지는 Application 정보 ‘LG SNS’, User 정보 ‘User N’, 네트워크 인터페이스 정보 ‘Wi-Fi’로 설정된 값을 포함할 수 있다.
이후, 상기 디바이스 1은 S1302 단계에서 수신된 정보를 포함하는 ADV_IND 메시지를 리모트 디바이스들로 전송한다(S1303).
상기 ADV_IND 메시지는 Mode = Broadcasting, Inquiry type= Application, User, Network I/F 정보를 포함한다.
즉, 상기 디바이스 1은 상기 수신된 BCST_REQ 메시지 내 포함된 정보를 ADV_IND 메시지 포맷에 맞도록 변형하여 상기 리모트 디바이스들로 전송한다.
이후, 각 리모트 디바이스들은 자신의 정보를 포함하는 BCST_RSP 메시지를 상기 디바이스 1로 전송한다(S1304).
상기 BCST_RSP 메시지는 Application 정보, User 정보, Network I/F 정보 등을 포함할 수 있다.
이후, 상기 디바이스 1은 S1304 단계에서 수신된 BCST_RSP 메시지를 상기 디바이스 T로 테더링을 통해 전송한다(S1305).
일 예로, 상기 디바이스 T로 전송되는 BCST_RSP 메시지는 Response= Application=LG SNS, User=User 1, Network I/F= Wi-Fi, Network Data = SSID= LG_SNS로 설정된 값을 포함할 수 있다.
이후, 상기 디바이스 T은 콘텐츠를 공유할 리모트 디바이스를 선택 및 콘텐츠를 공유하기 위한 다른 네트워크 인터페이스(Wi-Fi Direct)를 턴온한다(S1306).
이후, 상기 디바이스 T는 상기 디바이스 1을 통해 상기 선택된 리모트 디바이스(디바이스 2)와 다른 네트워크 인터페이스를 이용하여 Application 데이터를 교환한다(S1307).
여기서, 상기 디바이스 1은 상기 디바이스 T와 상기 디바이스 2 간의 데이터 송수신을 중계하는 역할을 한다.

도 14는 본 명세서에서 제안하는 디바이스들에서 출력되는 유저 인터페이스의 일 예를 나타낸 도이다.
도 14a는 도 5의 S503 단계에 해당하는 UI를 나타내는 것으로, 디바이스 1의 화면에 출력된 다수의 리모트 디바이스들 리스트 및 특정 리모트 디바이스를 선택하기 위한 User action을 나타낸다.
도 14b는 도 5의 S505 단계에 해당하는 UI를 나타내는 것으로, 각 리모트 디바이스들의 화면에 출력되는 디바이스 1의 정보, 상기 디바이스 1의 연결 요청에 대한 연결 수락 또는 연결 거절의 선택 화면을 나타낸다.
도 14에서, 상기 디바이스 1이 리모트 디바이스와 공유하고자 하는 콘텐츠는 사진, 파일, SNS 정보 등일 수 있다.

이하에서는, BLE를 이용하여 Wi-Fi Direct 연결 정보(예: SSID, Group ID)를 디바이스 간 교환하고, Wi-Fi Direct Network(WFDN)에서 싱크 디바이스 발견 및 자동으로 스트리밍을 다른 디바이스로 핸드오버하는 방법에 대해 살펴보기로 한다.
도 15는 본 명세서에서 제안하는 블루투스를 이용하여 Wi-Fi Direct 연결 정보 교환, Wi-Fi Direct를 통해 데이터 송수신 및 디바이스 간 스트리밍을 핸드오버하는 방법의 일 예를 나타낸 흐름도이다.
도 15를 참조하면, 소스 디바이스 1은 싱크 디바이스로 media stream을 전송하여 media를 상기 싱크 디바이스를 통해 재생하고 있다(S1501).
여기서, 소스 디바이스(Source Device:SRC)는 콘텐츠를 보유하고 있는 스마트폰 등의 휴대장치를 말할 수 있으며, 싱크 디바이스(Sink Device:SNK)는 상기 소스 디바이스로부터 콘텐츠를 수신받아 재생할 수 있는 디바이스를 말하는 것으로, 스피커 등일 수 있다.
이후, 소스 디바이스 2는 주변에 존재하는 리모트 디바이스 즉, 싱크 디바이스와 연결을 위해 자신의 네트워크 정보, 서비스 정보(예: 서비스 IDs)를 포함하는 BLE 광고 메시지를 브로드 캐스팅한다(S1502).
상기 네트워크 정보, 서비스 정보를 포함하는 BLE 광고 메시지는 아래와 같이 구현될 수 있다.
<?xml>
<NetworkApplicationAdvertisement>
<BSSID>802.11 Wi-Fi Direct BSSID</BSSID> // Mandatory <P2PGroupID>802.11 Wi-Fi Direct GroupID</P2PGroupID> // Mandatory <DeviceID> Device Unique ID</DeviceID> // Optional <RequestID> Number of Request</RequestID> // Optional <SEID>Stream End Point ID</SEID> // Optional
< MediaPlayerID > Media Player ID </ MediaPlayerID> // Optional <SecurityType>WEP</SecurityType> // Optional <SecurityKey>WEPKey</SecurityKey> // Optional
</ NetworkApplicationAdvertisement >

[Example NetworkApplicationAdvertisement of Wi-Fi Direct through Bluetooth]
<?xml version="1.0" encoding="UTF-8"?>
< NetworkApplicationAdvertisement name=“WFDNetworkApplicationAdvertisement ">
< NetworkApplicationAdvertisement
BSSID = “WFDBSS”
P2PGroupID = “WFDP2P”
DeviceID = “00:02:72:00:d4:1a”
RequestID =“002“
SEID = “012345”
MediaPlayerID =“02:01:06:03:02:F0:FF” >
< NetworkApplicationAdvertisementCondition
AutoPairing =“true“
AutoStreamingHanodver =“true”
StreamingStatusNotification = “true”
NetworkConnection =“NFC|WLAN|Bluetooth “>
</ NetworkApplicationAdvertisement >

즉, Network Application Advertisement는 DDI(Device Information (device/interface address)), Device type, friendly name, manufacturer, model description, model name, UDN (UUID), service list 등을 포함할 수 있다.
여기서, 상기 소스 디바이스 2와 주변 리모트 디바이스들(소스 디바이스 1 및 싱크 디바이스)의 Bluetooth 무선 기능은 활성화되어 있다고 가정한다.
이후, 상기 BLE 광고 메시지를 수신한 리모트 디바이스들(소스 디바이스 1, 싱크 디바이스 등)은 자신의 정보를 포함하는 BLE 응답 메시지를 상기 소스 디바이스 2로 전송한다(S1503).
상기 BLE 응답 메시지를 전송한 리모트 디바이스들은 상기 소스 디바이스 2로부터 요청된 네트워크 인터페이스(Wi-Fi Direct)를 활성화시킨다.
여기서, 각 리모트 디바이스들이 전송하는 자신의 정보는 Network 정보, User 정보, Service 정보 등일 수 있다.
이후, 상기 소스 디바이스 2는 상기 수신된 BLE 응답 메시지에 기초하여 연결할 리모트 디바이스를 선택하고, Wi-Fi Direct 통신을 이용하여 상기 선택된 리모트 디바이스(싱크 디바이스)와 Wi-Fi Direct Device Discovery 절차를 수행한다(S1504).
여기서, S1504 단계 수행 전에 현재 싱크 디바이스를 사용 중인 상기 소스 디바이스 1로부터 사용 권한 허락과 관련된 절차가 추가될 수 있다.
S1504 단계는 상기 소스 디바이스 1로부터 사용에 대한 허락을 받은 경우라고 가정한다.
즉, 디바이스의 제어권 이전과 관련된 절차가 도 15에 추가될 수 있다.
소스 디바이스 2와 싱크 디바이스 간 Wi-Fi Direct 연결이 확립된 후, 상기 소스 디바이스 2는 상기 싱크 디바이스로 출력할 media를 선택하고, 상기 선택된 media의 stream을 상기 싱크 디바이스로 전송한다(S1505).
여기서, 상기 소스장치 2는 상기 선택된 media stream과 함께 SEID(Stream End Point Identifier)를 전송할 수 있다.

이하에서, 본 명세서에서 제안하는 블루투스를 이용하여 Advertising URI(Uniform Resource Identifier)의 전송 방법 및 URI 접속 시 보안을 강화하기 위한 방법에 대해 구체적으로 살펴보기로 한다.
즉, Bluetooth BR/EDR 또는 BLE 기술을 통해 디바이스 간 Advertising URI를 빠르게 교환하고, 이를 위해 새로운 광고 메시지 포맷을 정의하고, Advertising URI로 접속 시 보안을 강화하기 위해 보안 프로토콜을 새롭게 정의하기로 한다.
이하에서 사용되는 광고자(Advertiser)는 광고 Packet을 브로드캐스트하는 디바이스를 나타내는 것으로, 광고 디바이스(Advertising Device), 제 1 디바이스 등으로 표현될 수 있다.
상기 광고자의 일 예로는 다양한 종류의 센서 등일 수 있다.
스캐너는 센트럴 역할(Central Role)을 하는 디바이스를 나타내는 것으로, 제 2 디바이스 등으로 표현될 수 있으며, 일 예로는 스마트폰 등일 수 있다.
종래에는 광고자가 Advertising URI를 포함하는 광고 메시지(Beacon, 광고 패킷, 광고 채널 PDU)를 일방적으로 전송하였다.
이에 따라, Advertising URI를 수신하는 스캐너는 수신된 Advertising URI가 안전한 URI인지 아니면 안전하지 않은 스팸(Spam) URIs인지에 대해 구별하기 어려워, 상기 Advertising URI로 접속 시 보안에 취약한 문제가 있었다.
따라서, 본 명세서에서는 새로운 보안 프로토콜 즉, 디바이스 간 Request 및 Response 메시지 교환 방법을 통해 Advertising URI와 관련된 보안을 강화하는 방법을 제공한다.
즉, 스캐너는 광고자로부터 Advertising URI를 수신하는 경우, 상기 수신된 Advertising URI에 바로 접속하지 않고, 상기 Advertising URI와 관련된 Security Requirement를 광고자로 요청한 후, 상기 Advertising URI의 유효성을 검증한 후, 상기 Advertising URI로 접속한다.
구체적으로, 블루투스에서 사용되는 Advertising 메시지 포맷에 Advertise Security Flag 필드를 추가함으로써, Advertising URI의 Server에 대한 인증, Advertising URI의 암호화(Encryption) 등을 지원할 수 있도록 한다.
먼저, 스캐너가 광고자로부터 Advertising URI를 수신하는 경우, 상기 스캐너는 상기 광고자로 상기 Advertising URI의 유효성 검증과 관련된 보안 부가 정보를 요청한다.
상기 보안 부가 정보는 암호화 키(Encryption Key), 서명 키(Signature Key), 인증서(Authentication Certificate) 등일 수 있다.
다음, 상기 광고자는 상기 스캐너의 보안 부가 정보 요청에 따라 상기 광고자 또는 상기 Advertising URI의 접속 서버에 대한 보안 정보를 포함하는 광고 Packet을 상기 스캐너로 전송한다.
상기 Advertising Packet은 Secure URL, Certificate URL 또는 HTTPS Server URL 등을 포함할 수 있다.
다음, 상기 스캐너는 상기 advertising packet에 포함되는 보안 정보를 확인 및 상기 보안 정보 즉, 암호화 키(Encryption Key), 서명 키(Signature Key), 인증서(Authentication Certificates) 등의 유효성을 검증하여, 상기 Advertising URI의 유효성이 증명된 경우에 한해 특정 server URI를 획득함으로써, 상기 특정 server로 접속(또는 연결)을 한다.

도 16은 본 명세서에서 제안하는 블루투스를 이용한 광고 URI 보안 강화 방법의 일 예를 나타낸 흐름도이다.
도 16을 참조하면, 광고자는 스캐너로 Service Types, Service URIs 등의 서비스 정보 및 각 Service URIs에서 지원되는 보안 특징(security feature)을 포함하는 광고 메시지를 블루투스를 이용하여 전송한다(S1601).
본 명세서에서 사용되는 ‘메시지’는 패킷(Packet), 채널 PDU(Channel Packet Data Unit) 등 다양하게 표현될 수 있다.
상기 광고자는 다양한 종류의 Advertising Profile을 상기 광고 메시지에 포함시켜 전송할 수 있다.
상기 Advertising Profile은 Advertising Service, Alert Service, Connection Service 등이 있을 수 있다.
상기 Advertising Service은 Notification URIs, Reservation URIs, Control Web URIs, A/V Streaming URIs 등이 있을 수 있다.
상기 Alert Service는 Alert Level(No, Mild, High)을 포함할 수 있다.
상기 Connection Service는 LTE, BLE, Wi-Fi, BT BR/EDR 등 무선 연결 기능 또는 네트워크 인터페이스를 나타낼 수 있다.
여기서, BLE 무선 기능만 지원하는 광고자의 경우, 상기 광고자는 GAP Peripheral Role, Connectable mode, Advertise Link Loss Service를 수행할 수 있다.
이후, 상기 스캐너는 상기 수신된 광고 메시지에 기초하여 Service URIs 중 접속하고자 하는 특정 Service URI를 선택한다(S1602).
상기 Service URIs의 예로는 Bus Stop URI, Menu URI, Rental Car URI, Exhibition URI, Shopping URI, Coupon URI, Web service URI, Alert Message URI 등이 있을 수 있다.
상기 스캐너는 상기 선택된 Service URI로의 접속에 대한 보안을 강화하기 위해 즉, 상기 선택된 Service URI로의 접속이 안전한지를 확인하기 위해 상기 선택된 Service URI와 관련된 Security Requirment를 상기 광고자로 요청한다.
즉, 상기 스캐너는 상기 선택된 Service URI의 보안 특징들을 요청하기 위한 Scan Request 메시지를 상기 광고자로 전송한다.
상기 Scan Request 메시지는 Connection Signature required to sign data and verify signatures of Broadcaster, Link Encryption required, Authentication of Broadcaster required 등을 포함할 수 있다.
이후, 상기 광고자는 상기 스캐너로 요청된 보안 특징들을 포함하는 Scan Response 메시지를 전송한다(S1603).
즉, 상기 Scan Response 메시지는 Signature Key, Authentication Key, Encryption Key, 광고자의 key들을 위한 Certificates, Secure URIs (e.g. https…) 등을 포함할 수 있다.
이후, 상기 스캐너는 상기 수신된 Scan Response 메시지에 포함된 광고자의 Keys 및 Certificate를 이용하여 광고자로부터 수신되는 Advertising URI의 안전성 여부를 증명하고, 안전한 경우 상기 Advertising URI를 통해 Service Provider의 Server로 접속함으로써, 상기 Advertising URI와 관련된 Service Specific Data를 송수신하게 된다(S1604).
상기 Service Provider의 Server는 지원하는 Service들에 따라 다양한 서버가 존재할 수 있으며, 상기 다양한 서버는 하나의 서버로 구성될 수도 있고, 다수의 개별적인 서버로 구성될 수도 있다.
상기 서버의 일 예로, Bus Stop info. Server, Shopping Retail Server, Exhibition Server, Car Control Server, Weather Server, Location Server, Light Control Server, Fire Alert Server, File Alarm Server, Meeting Room Reservation Server 등이 있을 수 있다.
S1601 단계에서, 상기 광고자가 Connectable Advertising 메시지를 전송하는 경우에는 상기 스캐너와 상기 광고자는 Connection 을 맺은 상태에서 메시지 교환을 통해 보안 키 교환 및 보안 관련 설정이 가능할 수 있다.
여기서, 스캐너는 광고자의 certificates이 web server에서 유효함을 확인하기 위해 상기 광고자를 신뢰해야 한다.
또한, 상기 스캐너가 상기 광고자의 certificates의 유효성을 확인할 수 있도록, 상기 광고자는 상기 스캐너로 전송될 수 있는 certificates 또는 certificates의 URIs에 대해 자주 업데이트를 함으로써, 유효한 certificate 리스트들을 가지고 있어야 한다.
표 5는 본 명세서에서 제안하는 광고 메시지에 포함되는 Advertising URI Data Type의 일 예를 나타낸다.
표 5는 후술할 Advertise URIs Request Type, GATT Service, GATT characteristics, GATT characteristic descriptors 등에도 사용될 수 있다.
Advertising URI Type Value Category Data Type Name Data Value Description
Shopping
0XA0 Shopping Mall 쇼핑몰 이름, 위치, 주소…
0XA1 Retail Shop Information 상점 위치, 이름, 소유주…
0XA2 Retail Coupon codes 쿠폰 정보, 할인 정보…
0XA3 Payment Service Provider 결제 정보, 결제 서비스 제공자 정보…
0XA4 Restaurant Menu 음식점 메뉴 정보, 다국어 선택/지원 정보…
Vehicle
0XB0 Bus Stop 버스 정보 및 URI: Bus 관리 서버 URIs,버스 정류장정보, 도착예정 버스 정보, 다국어 별 버스 정류장 안내 선택 URI , 연계 버스 노선안내 URI, Taxi URI…
0XB1 Car Control 자동차 관리 서버, 셔틀 버스 관리 서버 URI, 원격관리 서버 URI…
0XB2 Rental Car Information Rental Car Web, Call, Event, Location (Parking Lot)
Environmental
0XC0 Weather Server URIs
0XC1 Temperature Server URIs
0XC2 Air Pollution Server URIs
0XC3 Fire Alarm
Location
0XD0 Meeting Room Asset 위치 및 URI: 회의실 정보 (위치, 예약 스케쥴, 예약자, 사용 인원, 예약 서버 URIs)
0XD1 Location Tracker
Device Control
0XE0 LED Lighting 전등 제어 서버 URI
0XE1 Wireless Power Charger 무선 충전 패드설정 URI
Exhibition
0XF2 Exhibition Web Server 박물관, 컨퍼런스 안내 서비스 URIs
0XF3 Artifacts Number Artifact Name, Position Number, Route Number, Floor Number
0XF4 Artifacts Description Artifact Voice/Video Guide URI
0XF5 Artifacts Multimedia Guide Artifact Multimedia (Voice/Video) Guide URI

블루투스를 이용한 Advertising 과정에서 정의되는 Advertising security mode와 각각의 mode에서 지원되는 Advertising security type들, 그리고 이를 지원하기 위한 새로운 광고 메시지 포맷(또는 구조)에 대해 살펴보기로 한다.
표 6은 광고 메시지, Scan Response 메시지 등에 포함되는 Advertising security feature들(Advertising security mode, 각각의 mode에서 지원되는 Advertising security type)의 일 예를 나타낸다.
LE Advertising Procedure Advertise
Security
Type		 Authorization required Advertiser Authentication required Service Provider URIs Authentication Required Encryption required
LE Advertising Security Mode 1 1 No security 0XA1 X X X X
2 Unauthenticated Advertising with encryption 0XA2 X X X O
3 Authenticated Advertising with AdvertisingURI encryption 0XA3 X O X O
4 Authenticated Advertising with AdvertisingURI encryption and Server Authentication 0XA4 X O O O
LE Advertising Security Mode 2 1 Unauthenticated Advertising with data signing 0XB1 X X O
2 Authenticated Advertising with data signing 0XB2 X X O
표 6을 참고하면, 광고 보안 모드(Advertise Security Mode)는 두 가지 mode(Advertise Security Mode 1 및 Advertise Security Mode 2)가 존재한다.
상기 Advertise Security Mode 1은 4종류의 Advertise Security Type이 존재하며, Advertise Security Mode 2는 2 종류의 Advertise Security Type이 존재한다.
상기 Advertise Security Type을 포함하는 Advertising 메시지 포맷에 대해 살펴보기로 한다.
먼저, Advertise Security Type이 암호화(Encryption)를 지원하고, Advertising URI에 대해 Encryption이 요구되는 경우, Advertising URI는 Advertiser Encryption Key 로 암호화되어 전송된다.
이 때, 상기 Advertise Security Type는 표 6에 나타난 바와 같이 0xA2, 0xA3 또는 0xA4로 설정될 수 있다.
이 때, Advertising Security Flag의 Advertiser Encryption Key Distribution 필드는 ‘enable’로 설정되며, Key Distribution URIs 필드에 Advertiser Encryption Key Distribution URI가 포함될 수 있다.
다음으로, Advertise Security Type이 Authenticated Advertising을 지원하고, Advertising URI에 대해 Advertiser Authentication이 요구되는 경우, 상기 Advertising URI는 Advertiser Signature Key로 서명된 Advertising URI Signature를 포함한다.
이 때, 표 6에 나타난 바와 같이 상기 Advertise Security Type는 0xA3, 0xA4 또는 0xB2로 설정될 수 있다.
또한, Advertising Security Flag의 Advertiser Signature Key Distribution 필드는 ‘enable’로 설정되며, Key Distribution URIs 필드에 Advertiser Signature Key Distribution URI 가 포함될 수 있다.

다음으로, 광고 메시지에 포함되는 Advertising Security Type의 변경 및 관리 방법에 대해 살펴보기로 한다.
스캐너는 SCAN_REQ 메시지를 광고자로 전송함으로써 Advertising Security Type의 변경을 요청할 수 있다.
여기서, 상기 광고자가 상기 Advertising Security Type의 변경을 요청하는 SCAN_REQ 메시지를 상기 스캐너로부터 수신하는 경우, 상기 광고자는 광고 메시지 내 Advertise Security Flag를 추가함으로써, Advertising URI와 관련된 보안을 강화할 수 있다.
즉, 광고자는 스캐너의 보안 변경 요청(Secure URL, Certificate URL, HTTPS Server URL 등)에 따라 상기 스캐너로 advertising packet을 전송한다.
여기서, 상기 광고자는 페어링된 스캐너에 의해서만 복호할 수 있는 암호화된 신호(encrypted signal)를 브로드캐스트한다.
상기 광고자로부터 전송되는 암호화된 정보는 상기 광고자와 페어링되지 않는 디바이스에 의해서는 복호가 불가능하다.
따라서, 상기 스캐너는 상기 광고자로부터 수신되는 암호화된 보안 정보를 확인하고, 상기 광고자의 보안키, 인증서 등의 유효성 검증을 통해 유효한 경우에 한해 특정 server URI를 획득하고, 상기 특정 server로 보안 연결을 수행한다.

이하에서, Advertising URI와 관련된 보안 정보를 포함하는 광고 메시지 포맷에 대해 구체적으로 살펴보기로 한다.
Advertising Channel PDU의 PDU Type 필드에 Advertising URI를 전송하는 전용 PDU Type을 추가적으로 정의할 수 있다.
표 7은 본 명세서에서 제안하는 광고 메시지의 PDU Type 필드의 일 예를 나타낸 표이다.
PDU Type b3b2b1b0 Note
0000 ADV_IND
0001 ADV_DIRECT_IND
0010 ADV_NONCONN_IND
0011 SCAN_REQ
0100 SCAN_RSP
0101 CONNECT_REQ
0110 ADV_SCAN_IND
1000 ADV_IND_EXT
1001 ADV_NONCONN_IND_EXT
1010 ADV_URI_IND
1100 SCAN_REQ_ADV_URI
1101 SCAN_RSP_ADV_URI

광고 메시지 포맷에 대한 구체적인 설명은 도 8을 참고하기로 한다.
앞서 살펴본 Advertising URI 및 Application Discovery를 위한 정보는 광고 메시지의 페이로드 특히, AdvData 필드에 포함될 수 있다.
상기 Application Discovery를 위한 정보는 아래와 같다.
- User Information: User ID, Name, User Preference, Account Information
- Service Information: Service ID, App ID, Cloud Service Provider Information
- Network Information: W-Fi(e.g. SSID, Channel Information), Wi-Fi Direct (Group ID), NFC, Bluetooth, Ethernet
- Content: Content Type (Video, Picture, Music, Documents)
또한, Advertising URI은 아래와 같은 정보들일 수 있다.
- 음식점 정보 및 URI: 메뉴, App, 결제 정보, 쿠폰 등
- 버스 정보 및 URI: Bus 관리 서버 URIs, Bus Stop, number of buses at stops, arriving bus information.
- 결제 정보 Server URIs: User ID, Name, User Preference, Account Information, Payment Server URIs
- Asset 위치 및 URI: 회의실 정보 (위치, 예약 스케쥴, 예약자, 사용 인원, 예약 서버 URIs)
- 공공정보, 보안, 화재 경보 알림 및 URIs: 경보 type, URIs, alert level (“No Alert,” “Mild Alert,” “High Alert,”), 경보 서버 URIs
- 박물관, 컨퍼런스 안내 서비스 URIs: Artifact Name, Position Number, Route Number, Floor Number

도 17은 본 명세서에서 제안하는 광고 메시지 구조의 일 예를 나타낸 도이다.
도 17은 BLE의 광고 메시지 중 Non-connectable and undirected 광고 이벤트의 경우 전송되는 ADV_NONCONN_IND 메시지 구조의 일 예를 나타낸다.
Connectable 광고 메시지를 전송하는 디바이스(Peripheral Role 을 가진 기기)는 수신 디바이스(Scanner, Central Role을 가진 기기, 예: Phone)로부터 Connection Request 메시지를 수신하여 상기 수신 디바이스와 연결을 할 수 있는 디바이스를 말한다.
Non-connectable 광고 메시지를 전송하는 디바이스는 수신 디바이스로부터 Connection Request를 수신하더라도 상기 수신 디바이스와 연결을 할 수 없는 디바이스를 말한다.
도 17의 ADV_NONCONN_IND 메시지는 광고자가 스캐너에게 일방적으로 Advertising URI를 알려주기 위해 브로드캐스팅하는 메시지의 구조를 나타낸다.
광고자는 브로드캐스트하는 Advertising URI의 인증 및 상기 광고자의 인증을 지원하지는 않는 것이 일반적이나 경우에 따라서 Advertise Security Flag를 지원할 수 있다.
도 17에 도시된 바와 같이, ADV_NONCONN_IND메시지의 AdvA Data 필드는 적어도 하나의 Advertising URIs을 포함할 수 있다.
상기 적어도 하나의 Advertising URIs은 Server URIs, App Download URIs, User/Network/ Content information URIs 등일 수 있다.
상기 적어도 하나의 Advertising URIs은 상기 AdvA Data 필드의 데이터 필드에 포함된다.
상기 AdvA Data 필드의 데이터 필드는 Advertise URI Type 필드, Advertise security type 필드, valid time stamp 필드, Advertiser Name 필드, Advertising URI 필드, Advertise Security Flag 필드 및 Reserved 필드를 포함한다.
상기 Advertise URI Type 필드는 Advertise URI 의 타입을 나타내며, 추가적으로 Advertise URI의 Encoding 방식 (UTF-8 등), Advertise URI 의 protocol (http, ftp, ldap, urn 등)등을 포함할 수 있다.
상기 Advertise security type 필드는 Advertising URI 에 접속할 때 필요한 보안 기술(Encryption, Advertiser Authentication, Service Provider URI Authentication, Encryption)을 나타낸다.
상기 valid time stamp 필드는 광고 메시지 및 상기 광고 메시지의 Advertise Security Flag 필드에서 정의되는 보안 정보의 유효기간을 나타낸다.
상기 Advertise Security Flag 필드는 1 octet의 크기를 가지며, Advertiser Encryption Key Distribution 필드, Advertiser Id Key Distribution 필드, Advertiser Signature Key Distribution 필드, Advertiser Certificate Distribution 필드 및 Target Server Certificate Distribution 필드를 포함할 수 있다.
상기 각각의 Distribution 필드는 1 비트의 크기를 가진다.
상기 각각의 Distribution 필드는 Advertising URI로 접속할 때, 광고자의 Encryption Key, Id Key, Signature Key, Certificate과 Target Server의 Certificate를 분배하기 위한 URI 가 설정되어 있는지를 나타낸다.
또한, 상기 Advertiser Encryption Key Distribution 필드, Advertiser Id Key Distribution 필드, Advertiser Signature Key Distribution 필드, Advertiser Certificate Distribution 필드, Target Server Certificate Distribution 필드들은 상기 Advertise Security Flag 필드의 비트 값에 순차적으로 위치한다.
상기 Advertise Security Flag 필드는 광고자의 security 지원 여부 및 지원하는 Security 의 종류를 나타내는 것으로, 1 octet 에 bit 별로 보안 기능을 표시할 수 있다.
상기 Advertise Security Flag 필드의 첫 번째 비트(bit 1)에는 상기 Advertiser Encryption Key Distribution 필드가 위치한다.
블루투스를 통해 디바이스 간 Pairing 이 끝나고, Link Key로 Link가 암호화된 경우, 광고자 또는 스캐너는 Encryption Key 를 생성하여 상대방으로 전달할 수 있다.
상기 Advertise Security Flag 필드의 두 번째 비트(bit 2)에는 상기 Advertiser Id Key Distribution 필드가 위치한다.
상기 Advertise Security Flag 필드의 세 번째 비트(bit 3)에는 상기 Advertiser Signature Key Distribution 필드가 위치한다.
상기 Advertise Security Flag 필드의 네 번째 비트(bit 4)에는 상기 Advertiser Certificate Distribution 필드가 위치한다.
상기 Advertise Security Flag 필드의 다섯 번째 비트(bit 5)에는 상기 Target Server Certificate Distribution 필드가 위치한다.
예를 들면, 광고자의 Authentication, Service Provider의 URI Authentication 이 요구되는 경우, 표 6에서와 같이 Advertise security type은 ‘0xA4’로 설정될 수 있고, Advertise Security Flag 필드의 두 번째 비트(bit 2), 네 번째 비트(bit 4) 및 다섯 번째(bit 5)가 각각 설정된다.

도 18은 도 17의 광고 메시지를 이용하여 광고 URI의 정보를 획득하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 18에서, 디바이스 1은 광고자, 디바이스 2는 스캐너, 디바이스 3은 Application Server/Cloud에 해당한다.
먼저, 상기 디바이스 1 내지 디바이스 3은 BLE를 이용하여 Application 및 Advertising URI를 발견하기 위한 절차를 수행한다(S1801).
상기 디바이스 1은 브로드캐스팅 모드, 상기 디바이스 2는 스캐닝 상태, 상기 디바이스 3은 URI를 통해 접속하는 디바이스를 수용할 수 있는 상태에 있다.
또한, 상기 디바이스 3은 블루투스 통신 이외에 상기 디바이스 3으로 접속하는 디바이스와 데이터를 교환하기 위해 특정 네트워크 인터페이스(예:Wi-Fi)가 이네이블(enable) 또는 활성화되어 있다.
구체적으로, 상기 디바이스 1은 Advertising URI 및 보안 정보를 포함하는 ADV_NONCONN_IND 메시지를 전송한다.
상기 ADV_NONCONN_IND 메시지는 일 예로, Mode=Broadcasting, Advertising URI Type=Restaurant Menu, Valid Time=thursday 2014.06.30, Advertiser Name=Korean Table, Advertise Security Flag=None으로 설정된 값들을 포함할 수 있다.
상기 ADV_NONCONN_IND 메시지에는 Advertise Security Flag가 설정되어 있지 않기 때문에, 상기 디바이스 2는 상기 디바이스 1로부터 수신되는 Advertising URI의 보안 강화를 위한 보안 정보 교환 절차는 수행되지 않는다.
따라서, 상기 디바이스 2는 상기 수신된 ADV_NONCONN_IND 메시지에 기초하여 Advertising URI를 선택하고, 상기 선택된 Advertising URI로 접속하기 위한 네트워크 인터페이스(예:Wi-Fi)를 활성화시킨다(S1802).
즉, 상기 디바이스 2는 Wi-Fi 무선 기능을 활성화시키고(S1803), Web Browser 상에서 Application을 시작하고, 상기 선택된 Advertising URI로 접속한다(S1804).
이후, 상기 디바이스 2는 Wi-Fi 통신을 통해 상기 디바이스 3과 Application 데이터를 교환한다(S1805).
상기 Application 데이터의 일 예로는, restaurant name, restaurant menu and its description language selection/change, coupon code, payment information 등이 있을 수 있다.
또 다른 일 예로서, 도 18의 ADV_NONCONN_IND 메시지에 Advertise Security Flag가 설정되어 있는 경우, 상기 Advertise Security Flag는 Advertiser Encryption Key Distribution 필드, Advertiser ID Key Distribution 필드, Advertiser Signature Key Distribution 필드, Advertiser Certificate Distribution 필드, Target Server Certificate Distribution 필드를 포함할 수 있다.이 경우, 상기 디바이스 2는 상기 Advertise Security Flag 필드에 설정된 각 Key Distribution 필드에 해당하는 각 Key Distribution URI 값을 상기 수신된 Advertising URI에 접속하여 즉, 상기 디바이스 3으로 접속함으로써 획득할 수 있다.

도 19는 본 명세서에서 제안하는 광고 메시지 구조의 또 다른 일 예를 나타낸 도이다.
도 19는 도 18에서 살펴본 Advertise Security Flag 필드에 포함되는 각 Key Distribution들의 URI 값들이 Extended PDU에 포함되는 광고 메시지 구조의 일 예를 나타낸다.
도 19에 도시된 바와 같이, 광고 메시지는 Extended PDU 및 Extended CRC 필드를 더 포함한다.
상기 Extended PDU는 0에서 256 octets의 크기를 가질 수 있으며, Extended CRC 필드는 0에서 3 octets의 크기를 가질 수 있다.
상기 광고 메시지는 ADV_NONCONN_IND_EXT 메시지로 표현될 수 있다.
ADV_NONCONN_IND 메시지와 마찬가지로, 상기 ADV_NONCONN_IND_EXT 메시지는 Non-connectable undirected 광고 이벤트의 발생 시 전송된다.
상기 Extended PDU는 Header Extended Length 필드 및 데이터 필드로 구성된다. 상기 Header Extended Length 필드의 길이는 8bit이다.
상기 Extended PDU의 데이터 필드는 Adverise Security Flag 필드에서 각 Distribution 필드 값이 설정된 경우, 각 Key Distribution URIs을 포함한다.
즉, 상기 Extended PDU의 데이터 필드는 광고자의 보안 키 및 인증서를 분배하는 서버의 URIs 가 포함된다.
PDU의 데이터 필드에 Advertise Security Flag가 설정된 경우, 설정된 (enabled) Key Distribution bit 의 개수 및 순서에 따라 Key Distribution URIs도 Extended PDU의 데이터 필드에 맞춰서 순차적으로 설정된다.
예를 들어, PDU의 데이터 필드에 Advertise Security Flag 에서 설정된 값이 Advertiser Encryption Key, Advertiser Id Key, Advertiser Signature Key일 경우, Extended PDU의 데이터 필드에 포함되는 Key Distribution URIs은 순차적으로 Advertiser Encryption Key Distribution URI, Advertiser Id Key Distribution URI, Advertiser Signature Key Distribution URI 가 포함될 수 있다.

도 20은 도 19의 광고 메시지 구조를 통해 광고 URI 정보를 획득하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 20의 경우, Extended PDU를 포함하는 광고 메시지를 이용하는 경우를 나타낸다.
S2002, S2003, S2005 및 S2006 단계는 도 18의 S1802 내지 S1085 단계와 동일하므로 구체적인 설명은 생략하기로 한다.
디바이스 1은 디바이스 2로 ADV_NONCONN_IND_EXT 메시지를 전송한다(S2001).
상기 ADV_NONCONN_IND_EXT 메시지는 일 예로, Mode=Broadcasting, Advertise URI Type=Restaurant Menu, Valid Time=thru 2014.6.30, Advertiser Name=Korean Table, Advertising URI=www.koreanTable.com, Advertise Security Flag= enabled, Advertiser Encryption Key Distribution=set, Advertiser IdKey Distribution=set, Advertiser Signature Key Distribution=set, Advertiser Certificate Distribution=set, Secure Server Connection by Advertising URI=set 으로 설정된 값을 포함할 수 있다.
S2003 단계 이후, 상기 디바이스 2는 상기 디바이스 3으로부터 상기 ADV_NONCONN_IND_EXT 메시지의 Extended Data 필드에 포함되는 key Distribution URIs에 대한 광고자의 Key들 및 certificates를 획득한다(S2004).
상기 광고자의 Key들은 Advertiser Encryption Key, Advertiser Id Key, Advertiser Signature Key이고, Certificates는 Advertiser Certificate, Secure Server Certificate일 수 있다.
이후, 상기 디바이스 2는 S2004단계에서 수신된 정보에 기초하여 디바이스 1로부터 수신된 keys 및 certificates들과 Secure Server Certificates, Server URIs을 증명하고, 유효성이 증명된 경우, Wi-Fi를 통해 선택된 URI로 접속함으로써, 상기 디바이스 3과 Application 데이터를 교환한다(S2005).

도 21은 본 명세서에서 제안하는 광고 메시지 구조의 또 다른 일 예를 나타낸다.
도 21은 ADV_IND 메시지 구조의 일 예를 나타낸다.
ADV_IND 메시지는 도 19의 ADV_NONCONN_IND 메시지의 구조와 거의 동일하며, Advertising Security field 내 포함되는 정보들만 다르다.
즉, 상기 ADV_IND 메시지는 상기 Advertising Security field 내 Advertiser Encryption Key Distribution 필드, Advertiser Id Key Distribution 필드, Advertiser Signature Key Distribution 필드, Advertiser Certificate Distribution 필드, Secure Server Connection by Advertising URI 필드를 포함한다.
상기 Secure Server Connection by Advertising URI 필드는 Advertising URI을 통해 접속하는 서버가 안전한지를 나타낸다.

도 22는 도 21의 광고 메시지 구조를 통해 광고 URI 정보를 획득하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 22의 광고 메시지(ADV_IND 메시지)는 Connectable and undirected 광고 이벤트의 발생 시 전송된다.
도 22는 Connectable 광고 메시지를 사용하기 때문에 광고자가 스캐너로부터 security requirement의 요청을 수신하는 경우, 상기 스캐너와 connection을 맺고, Request/Response 메시지의 교환을 통해 security requirement(보안키, 인증서, 서버 정보 등) 정보를 교환할 수 있다.
S2201 및 S2205는 도 20의 S2001 및 S2005 단계와 동일하므로 구체적인 설명은 생략하고 차이가 있는 부분에 대해서만 살펴보기로 한다.
S2201 단계 이후, 디바이스 1과 디바이스 2는 BLE를 이용하여 connection을 수행한다.
구체적으로, 상기 디바이스 2는 상기 디바이스 1로 Connect_REQ 메시지를 전송한다(S2202).
이후, 상기 디바이스 1과 상기 디바이스 2는 Data Channel 확립 절차를 수행한다(S2203).
이후, 상기 디바이스 1은 상기 디바이스 2로 Data Channel PDU를 전송한다(S2204).
상기 Data Channel PDU는 상기 디바이스 1의 Encryption Key/Signature Key/Identification Key/Certificate와 디바이스 3의 Certificate, Secure URI of App Server(e.g. HTTPS) 등을 포함한다.
이후, 상기 디바이스 2는 상기 수신된 Data Channel PDU에 기초하여 상기 디바이스 1의 keys/certificates, secure server URI들에 대한 유효성을 확인한다.
상기 확인 결과, 유효한 것으로 증명되면 상기 디바이스 2는 Advertising URI를 선택하고 다른 네트워크 인터페이스를 통해 상기 선택된 Advertising URI로 즉, 상기 디바이스 3으로 접속함으로써, 상기 디바이스 3과 Application Data를 교환한다(S2205).

도 23은 본 명세서에서 제안하는 광고 메시지 구조의 또 다른 일 예를 나타낸 도이다.
ADV_IND_EXT 메시지는 도 19의 ADV_NONCONN_IND_EXT 메시지 구조와 동일하다.
따라서, 상기 ADV_IND_EXT 메시지는 Extended PDU의 데이터 필드에 key distribution URIs 필드들을 포함한다.

도 24는 도 23의 광고 메시지 구조를 통해 광고 URI 정보를 획득하기 위한 방법의 일 예를 나타낸 흐름도이다.
도 24의 경우, Extended PDU 필드를 포함하는 ADV_IND_EXT 메시지를 이용하는 경우를 나타낸다.
도 24의 단계들은 도 20의 단계와 거의 동일하므로 차이가 있는 부분에 대해서만 설명하기로 한다.
도 24에 도시된 바와 같이, 디바이스 1은 디바이스 2로 ADV_IND_EXT 메시지를 전송한다(S2401).
상기 ADV_IND_EXT 메시지는 일 예로, Mode=Broadcasting, Advertise URI Type= Restaurant Menu, Valid Time=thru 2014.6.30, Advertiser Name=Korean Table, Advertising URI= www.koreanTable.com, Advertise Security Flag= enabled, Advertiser Encryption Key Distribution=set, Advertiser IdKey Distribution=set, Advertiser Signature Key Distribution=set, Advertiser Certificate Distribution=set, Secure Server Connection by Advertising URI=set, Extended PDU = Advertiser Keys, Certificates Distribution URIs로 설정된 값을 포함할 수 있다.
이후, 상기 디바이스 2는 S2401 내지 S2404 단계에서 사용한 BLE가 아닌 다른 네트워크 통신을 통해 Advertising URIs의 security를 증명한다.
구체적으로, 상기 디바이스 2는 S2401 단계 이후, 다른 네트워크 인터페이스(Wi-FI)를 턴온하고(S2402), 웹 브라우저를 통해 어플리케이션을 시작하고 선택되는 Advertising URI에 해당하는 서버 즉, 디바이스 3으로 접속한다(S2403).
이후, 상기 디바이스 2는 Extended PDU Data 필드에 포함된 Distribution URI들에 대한 유효성 증명을 위해 상기 디바이스 3으로부터 광고자 key들 및 Certificates을 획득한다(S2404).
상기 광고자 key들은 Advertiser Encryption Key, Advertiser IdKey, Advertiser Signature Key일 수 있으며, 상기 Certificates은 Advertiser Certificate, Secure Server Certificate일 수 있다.
이후, 상기 디바이스 2는 상기 디바이스 1의 keys과 Certificates을 증명하고, Secure Server Certificates, Server URIs 을 증명한다.
이후, 유효성이 증명된 경우, 상기 디바이스 2는 Advertising URI를 선택하고, Wi-Fi 네트워크 인터페이스를 통해 상기 선택된 Advertising URI에 접속한다. 즉, 상기 디바이스 2는 상기 선택된 Advertising URI에 해당하는 서버 즉, 상기 디바이스 3과 연결한다.
이후, 상기 디바이스 2는 상기 디바이스 3과 Application Data를 교환한다(S2405).
상기 Application Data의 일 예로는, restaurant name, restaurant menu and its description language selection/change, coupon code, payment information 등일 수 있다.

도 25는 본 명세서에서 제안하는 광고 URI 정보를 획득하기 위한 방법의 또 다른 일 예를 나타낸 흐름도이다.
S2501 내지 S2503 및 S2505 단계는 도 22의 S2201 내지 S2203 및 S2205 단계와 동일하므로 구체적인 설명은 생략하기로 한다.
즉, 도 25는 디바이스 1과 디바이스 2 간에 BLE에 의해 Secure Connection이 생성된 후, 상기 디바이스 1이 각각의 데이터 채널을 통해 각각의 key distribution URIs을 전송하는 방법을 나타낸다.
도 25에 도시된 바와 같이, 디바이스 1은 디바이스 2와 connection이 완료된 후, Advertiser’s Encryption Key Distribution을 포함하는 제 1 데이터 채널, Advertiser’s Identification Key Distribution을 포함하는 제 2 데이터 채널, Device 3 Server Encryption Key Distribution을 포함하는 제 3 데이터 채널, 디바이스 3의 Certificate Distribution 또는 Server Certificate URI를 포함하는 제 4 데이터 채널을 각각 상기 디바이스 2로 전송한다(S2504).
이후, 상기 디바이스 2는 Server Certificate URI에 의해 디바이스 3의 Certificate를 획득하고, 이를 통해 서버의 certificate를 증명하고, 상기 디바이스 3과 다른 네트워크 인터페이스를 통해 Application Data를 교환한다(S2505).

도 26은 본 명세서에서 제안하는 광고 메시지 구조의 또 다른 일 예를 나타낸 도이다.
도 26은 ADV_URI_IND 메시지 구조의 일 예를 나타내며, 상기 ADV_URI_IND 메시지는 Advertising URI의 전용 광고 메시지를 말한다.
상기 ADV_URI_IND 메시지의 PDU Type 값은 ‘1010’으로 설정될 수 있다.
도 26에 도시된 바와 같이, 상기 ADV_URI_IND 메시지의 데이터 필드는 key distribution URIs 필드를 포함할 수 있다.
즉, Advertise Security Flag 필드 내에 설정되는 distribution 값에 해당하는 key distribution URI가 포함된다.
상기 ADV_URI_IND 메시지의 데이터 필드에 Advertise Security Flag가 설정되었을 경우, 각각 설정된(enabled) Key Distribution bit 의 개수에 따라 Key Distribution URIs도 그에 맞춰서 순차적으로 설정된다.
예를 들어, Advertise Security Flag 에서 설정된 값이 Advertiser Encryption Key, Advertiser IdKey, Advertiser Signature Key일 경우, Key Distribution URIs 필드에는 Advertiser Encryption Key Distribution URI, Advertiser IdKey Distribution URI, Advertiser Signature Key Distribution URI 가 순차적으로 포함된다.

도 27은 본 명세서에서 제안하는 스캐너의 Advertising URI 접속 방법의 일 예를 나타낸 순서도이다.
도 27a 및 도 27b를 참조하면, 스캐너는 스캐닝을 시작하고(S2701), 광고 메시지 수신을 위한 스캐닝을 수행한다(S2702).
이후, 상기 스캐너는 광고자로부터 전송되는 광고 메시지를 수신한 경우(S2703), 상기 광고 메시지에 포함된 Advertising URI의 유효성을 판단한다(S2704).
상기 Advertising URI가 유효하다고 판단한 경우, 상기 스캐너는 상기 광고 메시지에 포함된 Advertiser Security Flag가 설정 또는 이네이블되었는지를 판단한다(S2705).
상기 Advertiser Security Flag가 설정된 경우, 상기 스캐너는 상기 광고자로 Connection REQ 메시지를 전송함으로써, 상기 광고자와 새로운 연결을 형성한다(S2706).
S2704 단계에서 Advertising URI가 유효하지 않는 경우, 상기 스캐너는 다시 광고 메시지를 스캐닝한다.
이후, 상기 스캐너는 상기 Advertiser Security Flag에 설정된 광고자의 keys 및 certificates를 수신한다(S2707). 상기 광고자의 keys 및 certificates은 Encryption Key, IdKey, Certificates일 수 있다.
이후, 상기 스캐너는 상기 수신된 광고자의 keys, certificates, Secure Server URIs를 증명한다(S2708).
상기 수신된 광고자의 keys, certificates, Secure Server URIs증명되지 않은 경우, 상기 스캐너는 S2702 단계를 수행한다.
상기 수신된 광고자의 keys, certificates, Secure Server URIs가 증명된 경우, 상기 스캐너는 Advertising URI가 암호화되었는지를 확인한다(S2709).
상기 Advertising URI가 암호화된 경우, 상기 스캐너는 광고자의 Encryption Key를 이용하여 상기 Advertising URI를 복호한다(S2710).
이후, 상기 스캐너는 상기 복호된 Advertising URI가 유효한지를 확인한다(S2711).
S2709 단계에서, 상기 Advertising URI가 암호화되지 않은 경우, 상기 스캐너는 S2711 단계를 수행한다.
여기서, 상기 복호된 Advertising URI가 유효한 경우, 상기 스캐너는 상기 Advertising URI가 광고자에 의해 서명(sign)되었는지를 확인한다(S2712).
상기 복호된 Advertising URI가 유효하지 않은 경우, 상기 스캐너는 S2702 단계를 수행한다.
상기 Advertising URI가 광고자에 의해 서명된 경우, 상기 스캐너는 Advertiser Signature Key를 이용하여 상기 Advertising URI의 Signature를 증명한다(S2713).
이후, 상기 스캐너는 상기 Advertising URI의 서명(Signature)이 유효한지를 확인한다(S2714).
상기 확인 결과, 상기 Advertising URI의 서명이 유효한 경우, 상기 스캐너는 인터넷 접속을 위해 네트워크 인터페이스(예: Wi-Fi)를 턴온 또는 활성화시킨다(S2715).
상기 S2705 단계에서 Advertiser Security Flag가 설정되지 않은 경우, 상기 스캐너는 S2715 단계 즉, 네트워크 인터페이스를 턴온한다.
여기서, 상기 Advertising URI가 광고자에 의해 서명되지 않은 경우, 상기 스캐너는 S2715 단계를 수행한다.
이후, 상기 스캐너는 웹 브라우저를 통해 어플리케이션을 시작하고 상기 Advertising URI에 접속한다(S2716).
이후, 상기 스캐너는 서버가 SSL TLS를 지원하는 경우, 서버의 Certificates를 증명하고(S2717), 상기 서버의 Certificates가 증명된 경우, 상기 스캐너는 광고 메시지의 스캐닝을 종료한다(S2718).
하지만, 상기 서버의 Certificates이 증명되지 않은 경우, 상기 스캐너는 광고 메시지를 스캐닝하거나 상기 Advertising URI의 유효성을 확인하는 절차를 다시 수행한다.

또 다른 실시 예로서, 광고자는 Advertising URI를 ADV_SCAN_IND 메시지를 통해 전송할 수도 있다.
상기 ADV_SCAN_IND 메시지는 스캐닝 가능하고, 브로드캐스트되는 광고 이벤트 발생 시 사용되는 광고 메시지에 해당한다.
이 때, 스캐너는 SCAN_REQ_ADV_URI 메시지를 통해 Advertising URI 관련 부가 정보를 광고자에게 요청할 수 있다.
이후, 상기 광고자는 상기 SCAN_REQ_ADV_URI 메시지에 대한 응답으로 SCAN_RSP_ADV_URI 메시지를 상기 스캐너로 전송함으로써 부가 정보(advertiser 보안키, 인증서, 서버 정보 등)가 제공 가능함을 알려줄 수 있다.
상기 ADV_SCAN_IND 메시지의 구조는 ADV_NONCONN_IND 메시지 구조와 동일하므로 구체적인 설명은 도 17을 참조하기로 한다.

또 다른 실시 예로서, 광고자는 Advertising URI를 ADV_SCAN_IND_EXT 메시지를 통해 전송할 수도 있다.
앞서 살핀 바와 같이, 상기 ADV_SCAN_IND_EXT 메시지의 Extended PDU에는 Key Distribution URIs을 포함할 수 있다.
만약, 상기 ADV_SCAN_IND_EXT 메시지의 PDU에 Advertise Security Flag가 설정되었을 경우, 각각 설정된 Key Distribution bit 의 개수에 따라 Key Distribution URIs도 그에 따라 Extended PDU의 데이터 필드에 순차적으로 설정된다.
예를 들어, Advertise Security Flag 에서 설정된 값이 Advertiser Encryption Key, Advertiser Id Key, Advertiser Signature Key일 경우 Key Distribution URIs에는 Advertiser Encryption Key Distribution URI, Advertiser Id Key Distribution URI, Advertiser Signature Key Distribution URI 가 순차적으로 포함될 수 있다.
상기 ADV_SCAN_IND_EXT 메시지의 구조는 도 17의 ADV_NONCONN_IND_EXT 메시지 구조와 동일하므로 구체적인 설명은 도 17을 참조하기로 한다.

도 28은 본 명세서에서 제안하는 스캐너의 요청에 의해 Advertising URI를 전송하는 방법의 일 예를 나타낸 흐름도이다.
S2801, S2804 내지 S2807 단계는 도 20의 S2001 내지 S2005 단계와 동일하므로 구체적인 설명은 생략하고, 차이가 나는 부분에 대해서만 살펴보기로 한다.
디바이스 1은 Application 및 URI를 발견하도록 하기 위해 ADV_SCAN_IND 메시지(또는 ADV_SCAN_IND Channel PDU)를 BLE를 이용하여 디바이스 2로 전송한다(S2801).
상기 디바이스 1은 광고자이며, 상기 디바이스 2는 스캐너이다.
상기 ADV_SCAN_IND 메시지는 일 예로, Mode=Broadcasting, Advertise URI Type=Restaurant Menu, Valid Time=thru 2014.6.30, Advertiser Name=Korean Table, Advertising URI=www.koreanTable.com, Advertise Security Flag=enabled, Advertiser Encryption Key Distribution=set, Advertiser IdKey Distribution=set, Advertiser Signature Key Distribution=set, Advertiser Certificate Distribution=set, Secure Server Connection by Advertising URI=set으로 설정된 값을 포함할 수 있다.
이후, 상기 디바이스 2는 Advertising URI 관련 부가 정보를 요청하기 위해 상기 디바이스 1로 SCAN_REQ_ADV_URI 메시지를 전송한다(S2802).
이후, 상기 디바이스 1은 상기 SCAN_REQ_ADV_URI 메시지에 대한 응답으로 SCAN_RSP_ADV_URI 메시지를 상기 디바이스 2로 전송한다(S2803).
상기 Advertising URI 관련 부가 정보는 상기 디바이스 1 및/또는 디바이스 3과 관련된 보안키, 인증서, 서버 정보 등일 수 있다.
상기 SCAN_REQ_ADV_URI 및 SCAN_RSP_ADV_URI 메시지의 구조에 대해서는 후술하는 도 29 및 도 30을 참조하여 구체적으로 살펴보기로 한다.

도 29는 도 28의 스캔 요청 메시지 구조의 일 예를 나타낸다.
구체적으로, 도 29는 SCAN_REQ_ADV_URI 메시지의 구조를 나타낸다.
상기 SCAN_REQ_ADV_URI 메시지는 스캐너가 광고자로 Advertising URI 및 Advertising URI 와 관련된 부가 정보를 요청하기 위해 전송하는 메시지를 나타낸다.
여기서, 스캐너는 Scanning State에 있으며, 광고자는 Advertising State에 있게 된다.
도 29에 도시된 바와 같이, SCAN_REQ_ADV_URI 메시지는 Preamble, Access Code, PDU 및 CRC(Cyclic Redundancy Check)를 포함한다.
상기 PDU는 Header 필드, ScanA 필드(6 octets), AdvA 필드(6 octets), Advertise Security Request Type 필드(10 octets) 및 Advertiser Setting 필드를 포함한다.
표 7을 참고하면, 상기 SCAN_REQ_ADV_URI 메시지의 PDU Type 값은 ‘1100’으로 설정될 수 있다.
상기 ScanA 필드는 스캐너의 주소를 나타내며, 상기 AdvA 필드는 광고자의 Address를 나타낸다.
TxAdd(1 bit) 필드 값이 일 예로, ‘0’으로 설정된 경우, ScanA == public임을 나타내며, ‘1’로 설정된 경우, ScanA == Random임을 나타낸다.
또한, RxAdd(1 bit) 필드 값이 일 예로, ‘0’으로 설정된 경우, AdvA == public임을 나타내며, ‘1’로 설정된 경우, AdvA == Random임을 나타낸다.
상기 Advertise URIs Request Type(1octet) 필드는 스캐너가 광고자로 요청하는 Advertising URI의 Type 정보를 나타낸다.
따라서, 상기 Advertise URIs Request Type 값을 수신한 광고자는 Advertising Security Type을 지원하는 경우, SCAN_RSP_ADV_URI 메시지에 Advertising Security Type를 설정하여 상기 스캐너로 전송한다.

또 다른 실시 예로서, SCAN_REQ_ADV_URI 메시지의 Advertise Security Request Type을 이용한 Advertising URI Security Mode의 변경 및 관리 방법에 대해서 살펴본다.
즉, 스캐너는 SCAN_REQ_ADV_URI 를 광고자로 전송함으로써, Advertise Security Type을 변경하도록 할 수 있다.
상기 Scanner가 SCAN_REQ_ADV_URI의 Advertiser Setting 의 Advertise Security Type Set(1bit) 값을 설정하여 광고자로 전송하는 경우, 상기 광고자는 상기 스캐너에서 요청한 Advertise Security Type을 지원할 경우 수신된 Advertise Security Request Type에 따라 Advertising Security Mode를 변경할 수 있다.
즉, 광고자는 상기 Scanner의 요청이 있을 경우 광고 메시지 내 상기 스캐너로부터 요청된 Advertise Security Flag을 추가하여 Advertising URI의 보안 강화를 지원할 수 있다.
즉, 광고자는 상기 Advertise Security Flag 내에 광고자에 대한 인증, Advertising URI의 접속 서버(Service Provider)에 대한 인증, Advertising URI의 Encryption 지원, Advertising URI의 Signature 인증에 대한 정보를 포함시켜 상기 스캐너로 전송함으로써 Advertising URI에 대한 보안 강화를 수행할 수 있게 된다.
상기 스캐너는 상기 광고자로부터 수신되는 Advertising URI관련 보안 정보를 해석한 후, 보안키, 인증서 등의 유효성을 검증하고, 유효한 경우 특정 server URI를 얻어내고 해당 server에 보안 연결을 수행한다.

도 30은 도 28의 스캔 응답 메시지 구조의 일 예를 나타낸다.
구체적으로, 도 30은 SCAN_RSP_ADV_URI 메시지 구조의 일 예를 나타낸다.
상기 SCAN_RSP_ADV_URI 메시지는 광고자가 스캐너가 전송하는 SCAN_REQ_ADV_URI에 대한 응답으로 Advertising URI 관련 정보를 포함하여 전송하는 응답 메시지를 나타낸다.
도 30에 도시된 바와 같이, 상기 SCAN_RSP_ADV_URI 메시지는 Preamble, Access Code, PDU 및 CRC를 포함한다.
상기 PDU는 Header 필드, AdvA 필드 및 ScanRspData 필드를 포함한다.
상기 SCAN_RSP_ADV_URI 메시지의 PDU Type은 ‘1101’로 설정될 수 있다.
AdvA 필드, TxAdd 필드 및 RxAdd 필드에 대한 설명은 도 8을 참조하기로 한다.
상기 ScanRspData 필드의 Data 필드는 Advertise URI Type(1 octet), Advertise Security Type, Valid Time Stamp, Advertiser Name, Advertising URI, Advertise Security Flag(1 octet), Key Distribution URIs(optional) 필드들을 포함할 수 있다.

나아가, 설명의 편의를 위하여 각 도면을 나누어 설명하였으나, 각 도면에 서술되어 있는 실시 예들을 병합하여 새로운 실시 예를 구현하도록 설계하는 것도 가능하다. 그리고, 당업자의 필요에 따라, 이전에 설명된 실시 예들을 실행하기 위한 프로그램이 기록되어 있는 컴퓨터에서 판독 가능한 기록 매체를 설계하는 것도 본 발명의 권리범위에 속한다.
본 명세서에 따른 데이터를 송수신하는 방법은 상기한 바와 같이 설명된 실시 예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 상기 실시 예들은 다양한 변형이 이루어질 수 있도록 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다.
한편, 본 명세서의 데이터를 송수신하는 방법은 네트워크 디바이스에 구비된 프로세서가 읽을 수 있는 기록매체에 프로세서가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 프로세서가 읽을 수 있는 기록매체는 프로세서에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 프로세서가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
또한, 이상에서는 본 명세서의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 명세서는 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.
그리고, 당해 명세서에서는 물건 발명과 방법 발명이 모두 설명되고 있으며, 필요에 따라 양 발명의 설명은 보충적으로 적용될 수가 있다.
본 명세서는 무선 통신 시스템에서 데이터를 송수신하는 방법 및 이를 수행하기 위한 장치를 이용하는 것에 있다.

Claims (18)

  1. 무선 통신 시스템에서 데이터를 송수신하는 방법에 있어서, 제 1 디바이스에 의해 수행되는 상기 방법은,
    디바이스 연결 정보를 포함하는 제 1 메시지를 제 1 네트워크를 통해 적어도 하나의 제 2 디바이스들로 전송하는 단계;
    상기 제 1 메시지에 대한 응답을 상기 제 1 네트워크를 통해 상기 적어도 하나의 제 2 디바이스들로부터 수신하는 단계;
    상기 응답에 기초하여 제 2 네트워크의 무선 연결을 요청하기 위한 연결 요청 메시지를 상기 제 1 네트워크를 통해 상기 적어도 하나의 제 2 디바이스들로 전송하는 단계,
    상기 연결 요청 메시지는 상기 제 2 네트워크를 나타내는 네트워크 연결 정보를 포함하며;
    상기 연결 요청 메시지의 응답에 해당하는 연결 응답 메시지를 상기 제 1 네트워크를 통해 상기 적어도 하나의 제 2 디바이스들로부터 수신하는 단계; 및
    상기 제 2 네트워크를 통해 제 2 디바이스와 데이터를 송수신하는 단계를 포함하되,
    상기 디바이스 연결 정보는 상기 제 1 디바이스에서 지원하는 네트워크를 나타내는 네트워크 정보, 공유하고자 하는 서비스를 나타내는 서비스 정보, 상기 공유하고자 하는 서비스의 콘텐츠 타입을 나타내는 콘텐츠 타입 정보 또는 사용자와 관련된 정보를 나타내는 사용자 정보 중 적어도 하나를 포함하는 것을 특징으로 하는 방법.
  2. 제 1항에 있어서,
    상기 제 1 네트워크는 블루투스이며, 상기 제 2 네트워크는 블루투스를 제외한 다른 무선 네트워크인 것을 특징으로 하는 방법.
  3. 제 1항에 있어서, 상기 제 1 메시지는,
    블루투스 BR(Basic Rate)/EDR(Enhanced Data Rate)의 질의(Inquiry) 메시지이거나 또는 BLE(Bluetooth Low Energy)의 광고 채널 PDU(Packet Data Unit)인 것을 특징으로 하는 방법.
  4. 제 1항에 있어서,
    상기 제 1 디바이스는 테더링(Tethering)을 통해 상기 적어도 하나의 제 2 디바이스들과 메시지를 송수신하며, 상기 제 2 디바이스와 데이터를 송수신하는 것을 특징으로 하는 방법.
  5. 제 1항에 있어서, 상기 제 1 메시지는,
    적어도 하나의 광고 URI(Uniform Resource Identifier)들 또는 상기 적어도 하나의 광고 URI들과 관련된 보안 정보 중 적어도 하나를 더 포함하는 것을 특징으로 하는 방법.
  6. 제 5항에 있어서,
    상기 적어도 하나의 제 2 디바이스들로부터 상기 적어도 하나의 광고 URI들과 관련된 보안 부가 정보를 요청하는 제 2 메시지를 수신하는 단계; 및
    상기 적어도 하나의 제 2 디바이스들로 상기 요청된 보안 부가 정보를 포함하는 제 3 메시지를 전송하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  7. 제 6항에 있어서,
    상기 제 2 메시지는 광고 보안 요청 타입(Advertising Security Request Type) 필드를 포함하는 것을 특징으로 하는 방법.
  8. 제 6항에 있어서,
    상기 제 3 메시지는 광고 보안 플래그(Advertising Security Flag) 필드 및 광고 보안 타입(Advertising Security Type) 필드를 포함하는 것을 특징으로 하는 방법.
  9. 제 8항에 있어서,
    상기 광고 보안 플래그(Advertising Security Flag) 필드에 다수의 Key Distribution 필드가 포함되는 경우, 상기 제 3 메시지는 상기 Key Distribution 필드 개수만큼 전송되며,
    하나의 제 3 메시지마다 하나의 Key Distribution 필드가 포함되어 전송되는 것을 특징으로 하는 방법.
  10. 제 5항에 있어서, 상기 제 1 메시지는,
    Connectable 및 Undirected 광고 이벤트 발생 시 전송되거나 또는 Non-connectable 및 Undirected 광고 이벤트 발생 시 전송되는 것을 특징으로 하는 방법.
  11. 제 10항에 있어서,
    상기 제 1 메시지가 Connectable 및 Undirected 광고 이벤트 발생 시 전송되는 경우, 적어도 하나의 광고 URI들과 관련된 보안 정보는 상기 제 2 디바이스와 연결 확립된 후 교환되는 것을 특징으로 하는 방법.
  12. 제 5항에 있어서,
    상기 적어도 하나의 광고 URI들과 관련된 보안 정보는,
    광고 URI 타입(Advertising URI Type) 필드, 광고 보안 타입(Advertising Security Type) 필드, 유효 타임 스탬프(Valid Time Stamp) 필드, 광고자 이름(Advertiser Name) 필드 또는 광고 보안 플래그(Advertiser Security Flag) 필드 중 적어도 하나를 포함하는 것을 특징으로 하는 방법.
  13. 제 12항에 있어서,
    상기 광고 보안 플래그(Advertiser Security Flag) 필드는 광고자 암호화 키 분배(Advertiser Encryption Key Distribution) 필드, 광고자 ID 키 분배(Advertiser ID Key Distribution) 필드, 광고자 서명 키 분배(Advertiser Signature Key Distribution) 필드 또는 타겟 서버 증명서 분배(Target Server Certificate Distribution) 필드 중 적어도 하나를 포함하는 것을 특징으로 하는 방법.
  14. 제 13항에 있어서,
    상기 제 1 메시지는 확장된 PDU 및 확장된 CRC를 더 포함하고,
    상기 확장된 PDU는 적어도 하나의 Key Distribution URI를 더 포함하는 것을 특징으로 하는 방법.
  15. 제 1항에 있어서,
    상기 제 1 디바이스는 광고자(Advertiser)이고,
    상기 제 2 디바이스는 스캐너(Scanner)인 것을 특징으로 하는 방법.
  16. 무선 통신 시스템에서 데이터를 송수신하는 방법에 있어서, 제 1 디바이스는,
    외부와 유선 및/또는 무선으로 신호를 송수신하기 위한 통신부; 및
    상기 통신부와 기능적으로 연결되는 제어부를 포함하되, 상기 제어부는,
    디바이스 연결 정보를 포함하는 제 1 메시지를 제 1 네트워크를 통해 적어도 하나의 제 2 디바이스들로 전송하고;
    상기 제 1 메시지에 대한 응답을 상기 제 1 네트워크를 통해 상기 적어도 하나의 제 2 디바이스들로부터 수신하고;
    상기 응답에 기초하여 제 2 네트워크의 무선 연결을 요청하기 위한 연결 요청 메시지를 상기 제 1 네트워크를 통해 상기 적어도 하나의 제 2 디바이스들로 전송하고;
    상기 연결 요청 메시지의 응답에 해당하는 연결 응답 메시지를 상기 제 1 네트워크를 통해 상기 적어도 하나의 제 2 디바이스들로부터 수신하고;
    상기 제 2 네트워크를 통해 제 2 디바이스와 데이터를 송수신하도록 제어하되,
    상기 디바이스 연결 정보는 상기 제 1 디바이스에서 지원하는 네트워크를 나타내는 네트워크 정보, 공유하고자 하는 서비스를 나타내는 서비스 정보, 상기 공유하고자 하는 서비스의 콘텐츠 타입을 나타내는 콘텐츠 타입 정보 또는 사용자와 관련된 정보를 나타내는 사용자 정보 중 적어도 하나를 포함하며,
    상기 연결 요청 메시지는 상기 제 2 네트워크를 나타내는 네트워크 연결 정보를 포함하는 것을 특징으로 하는 디바이스.
  17. 제 16항에 있어서, 상기 제 1 메시지는,
    적어도 하나의 광고 URI(Uniform Resource Identifier)들 또는 상기 적어도 하나의 광고 URI들과 관련된 보안 정보 중 적어도 하나를 더 포함하는 것을 특징으로 하는 디바이스.
  18. 제 17항에 있어서, 상기 제어부는,
    상기 적어도 하나의 제 2 디바이스들로부터 상기 적어도 하나의 광고 URI들과 관련된 보안 부가 정보를 요청하는 제 2 메시지를 수신하고; 및
    상기 적어도 하나의 제 2 디바이스들로 상기 요청된 보안 부가 정보를 포함하는 제 3 메시지를 전송하도록 제어하는 것을 특징으로 하는 디바이스.
PCT/KR2014/010417 2013-11-06 2014-11-03 무선 통신 시스템에서 데이터를 송수신하는 방법 및 이를 수행하기 위한 장치 WO2015068988A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/035,082 US9936448B2 (en) 2013-11-06 2014-11-03 Method for transmitting and receiving data in wireless communication system and apparatus for performing the same

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201361900948P 2013-11-06 2013-11-06
US61/900,948 2013-11-06
US201461992875P 2014-05-13 2014-05-13
US61/992,875 2014-05-13

Publications (1)

Publication Number Publication Date
WO2015068988A1 true WO2015068988A1 (ko) 2015-05-14

Family

ID=53041703

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2014/010417 WO2015068988A1 (ko) 2013-11-06 2014-11-03 무선 통신 시스템에서 데이터를 송수신하는 방법 및 이를 수행하기 위한 장치

Country Status (2)

Country Link
US (1) US9936448B2 (ko)
WO (1) WO2015068988A1 (ko)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017018604A1 (ko) * 2015-07-26 2017-02-02 엘지전자(주) 블루투스 le(low energy) 기술을 이용하여 대체 통신 수단을 연결하기 위한 방법 및 장치
EP3182765A1 (en) * 2015-12-18 2017-06-21 EM Microelectronic-Marin SA Method and device for bluetooth low power communication
CN109690959A (zh) * 2016-09-09 2019-04-26 华为技术有限公司 一种文件的发送方法、接收方法及终端
US11191115B2 (en) * 2017-01-23 2021-11-30 Lg Electronics Inc. Bluetooth communication method and apparatus
US11452151B2 (en) 2018-05-31 2022-09-20 Huawei Technologies Co., Ltd. Application function implementation method and electronic device

Families Citing this family (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102122025B1 (ko) * 2013-11-25 2020-06-11 삼성전자주식회사 호스트 및 클라이언트의 타겟 디바이스에 대한 제어방법 및 장치
WO2015076640A1 (ko) 2013-11-25 2015-05-28 삼성전자주식회사 호스트 및 클라이언트의 타겟 디바이스에 대한 제어방법 및 장치
JP2017507549A (ja) 2013-12-30 2017-03-16 バスコ データ セキュリティー インターナショナル ゲゼルシャフト ミット ベシュレンクテル ハフツング ブルートゥースインタフェースを備える認証装置
JP6360316B2 (ja) * 2014-02-06 2018-07-18 キヤノン株式会社 通信装置、その制御方法、及びプログラム
US9680702B1 (en) * 2014-06-02 2017-06-13 Hrl Laboratories, Llc Network of networks diffusion control
JP2016012910A (ja) * 2014-06-06 2016-01-21 キヤノン株式会社 通信装置および制御方法およびプログラム
US10284524B2 (en) * 2014-08-21 2019-05-07 James Armand Baldwin Secure auto-provisioning device network
EP3026942B1 (en) * 2014-11-28 2017-09-27 Nokia Technologies OY Discovery of neighbour peers and connection establisment for a peer to peer communication
TWI581648B (zh) * 2015-01-12 2017-05-01 拓連科技股份有限公司 電子裝置間之訊號傳輸方法及系統
JP6463163B2 (ja) * 2015-02-16 2019-01-30 キヤノン株式会社 通信装置及びその制御方法、並びにプログラム
JP6566669B2 (ja) * 2015-03-12 2019-08-28 キヤノン株式会社 情報処理装置及びその制御方法、通信方法、並びにプログラム
JP6406092B2 (ja) * 2015-03-27 2018-10-17 ブラザー工業株式会社 通信機器
JP6533085B2 (ja) 2015-03-31 2019-06-19 Ｌｉｎｅ株式会社 端末、情報処理方法、及びプログラム
US10798171B2 (en) * 2015-07-01 2020-10-06 Dell Products, L.P. Sensor data advertisement via network identifier in shared spaces
US11140724B2 (en) * 2015-11-03 2021-10-05 At&T Mobility Ii Llc Systems and methods for enabling sharing between devices
JP6300855B2 (ja) * 2016-03-24 2018-03-28 キヤノン株式会社 印刷装置、印刷装置の制御方法及びプログラム
US10070247B2 (en) * 2016-04-14 2018-09-04 Qualcomm Incorporated Systems and methods for connection creation
FR3056865A1 (fr) * 2016-09-27 2018-03-30 Orange Activation perfectionnee d'interfaces de communication d'un terminal
US10165041B2 (en) * 2016-10-13 2018-12-25 Equalearning Corp. System and method for uninterrupted learning
US11889580B2 (en) * 2016-12-08 2024-01-30 Veea Inc. Wireless communication units and wireless communication system and methods to support beacon technology
US20180167867A1 (en) * 2016-12-08 2018-06-14 Virtuosys Limited Wireless Communication Units and Wireless Communication System and Methods to Support Beacon Technology
KR102607647B1 (ko) * 2017-01-24 2023-11-30 삼성전자주식회사 전자 장치 및 전자 장치의 테더링 연결 방법
US10912027B2 (en) * 2017-03-14 2021-02-02 Huawei Technologies Co., Ltd. Scanning method and device
AU2017411918A1 (en) * 2017-04-24 2019-12-05 Huawei Technologies Co., Ltd. Image sharing method and electronic device
JP7087314B2 (ja) * 2017-09-26 2022-06-21 カシオ計算機株式会社 無線通信装置、電子時計、無線通信方法、及びプログラム
US10820375B2 (en) * 2017-11-07 2020-10-27 Lg Electronics Inc. Method and apparatus for turning on Wi-Fi infrastructure using BLE interface in wireless communication system
WO2019098917A1 (en) * 2017-11-15 2019-05-23 Telefonaktiebolaget Lm Ericsson (Publ) End node, relay node, and methods performed therein for handling transmission of information
US10579098B2 (en) * 2017-12-14 2020-03-03 Disney Enterprises, Inc. Inferring the transfer of a physical object associated with a wearable device
US11416852B1 (en) * 2017-12-15 2022-08-16 Worldpay, Llc Systems and methods for generating and transmitting electronic transaction account information messages
JP2019135808A (ja) * 2018-02-05 2019-08-15 キヤノン株式会社 通信装置、情報端末、システム、通信装置の制御方法、情報端末の制御方法、システムの制御方法、及び、プログラム
US11057951B2 (en) * 2018-03-12 2021-07-06 Canon Kabushiki Kaisha Communication apparatus, method of controlling communication apparatus, and non-transitory computer-readable storage medium
EP3541150B1 (en) * 2018-03-16 2020-11-25 Helvar Oy Ab Luminaire detection
US11330431B2 (en) * 2018-03-28 2022-05-10 Denso International America, Inc. Targeted advertising with privacy and anti-replay protection
JP7246860B2 (ja) * 2018-03-30 2023-03-28 キヤノン株式会社 通信装置およびプログラム
AU2019373730B2 (en) 2018-11-02 2023-01-12 Assa Abloy Ab Systems, methods, and devices for access control
US11770708B2 (en) 2019-03-25 2023-09-26 Assa Abloy Ab Physical access control systems with localization-based intent detection
KR102592842B1 (ko) 2019-03-25 2023-10-20 아싸 아브로이 에이비 액세스 제어 판독기 시스템을 위한 초광대역 디바이스
US10757561B2 (en) * 2019-03-29 2020-08-25 Intel Corporation Wi-Fi docking in dense environment
US11973542B2 (en) * 2019-04-17 2024-04-30 Lg Electronics Inc. Method for controlling communication connection in wireless power transmission system, and apparatus therefor
WO2020251091A1 (ko) * 2019-06-14 2020-12-17 엘지전자 주식회사 자율주행시스템에서 다른 자율주행차량을 이용한 원격주행 방법
CA3152337A1 (en) 2019-09-26 2021-04-01 Assa Abloy Ab Ultra-wide band antenna configuration for physical access control system
KR102464259B1 (ko) 2019-10-01 2022-11-09 아싸 아브로이 에이비 정밀 거리측정 애플리케이션들을 위한 접속 및 서비스 발견
WO2021080364A1 (en) 2019-10-25 2021-04-29 Samsung Electronics Co., Ltd. Method for communicating with external electronic apparatus and electronic apparatus thereof
CN114651289A (zh) 2019-11-07 2022-06-21 亚萨合莱有限公司 用于启用超宽带的装置的上层装置架构
US10911923B1 (en) * 2020-01-15 2021-02-02 Schlage Lock Company Llc Technologies for implementing unified mode bluetooth advertisements
CN111629366B (zh) * 2020-04-27 2023-06-09 Oppo（重庆）智能科技有限公司 蓝牙设备间的交互方法及装置、存储介质和电子设备
CN111615090B (zh) * 2020-04-27 2023-07-14 Oppo（重庆）智能科技有限公司 蓝牙设备间的交互方法及装置、存储介质和电子设备
US11601792B1 (en) * 2020-11-30 2023-03-07 Dialog Semiconductor B.V. BLE system with multiple topologies and slave to slave communication
US11553407B2 (en) 2020-12-14 2023-01-10 Capital One Services, Llc Methods and systems for signal interpretation via image analysis
CN112654020B (zh) * 2020-12-15 2023-03-28 阿波罗智联(北京)科技有限公司 建立无线连接的方法、装置、设备及存储介质
CN112788579A (zh) * 2020-12-31 2021-05-11 厦门亿联网络技术股份有限公司 一种快速配对双模蓝牙设备的方法及装置
US11847519B2 (en) 2022-05-16 2023-12-19 Bluicity Inc. System and method for tracking tags over bluetooth low energy

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070037517A1 (en) * 2003-03-03 2007-02-15 Andrea Camuffo Method for establishing a wireless communication link
KR20120024065A (ko) * 2010-09-03 2012-03-14 엘지전자 주식회사 통신 연결 장치 및 그 방법
KR20120052549A (ko) * 2010-11-16 2012-05-24 한국전자통신연구원 저속 네트워크 통신을 이용한 단말 간 접속 제어 방법 및 이를 이용한 장치
KR20120117910A (ko) * 2005-06-23 2012-10-24 마이크로소프트 코포레이션 Ｎｆｃ를 이용한 장치들의 무선 접속 권한 설정
KR20130027876A (ko) * 2011-09-08 2013-03-18 유용 근거리 무선 통신 모듈을 사용한 거래 중개 시스템 및 그 방법

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6909721B2 (en) * 2002-10-31 2005-06-21 Nokia Corporation Device detection and service discovery system and method for a mobile ad hoc communications network
JP5100854B2 (ja) * 2011-01-31 2012-12-19 株式会社東芝 通信装置、及び通信方法
US9294903B2 (en) * 2013-04-04 2016-03-22 Nokia Technologies Oy Method and apparatus for facilitating handover utilizing a predefined attribute protocol
US9319828B2 (en) * 2013-06-24 2016-04-19 Csr Technology Inc. Wireless communication methods and devices

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070037517A1 (en) * 2003-03-03 2007-02-15 Andrea Camuffo Method for establishing a wireless communication link
KR20120117910A (ko) * 2005-06-23 2012-10-24 마이크로소프트 코포레이션 Ｎｆｃ를 이용한 장치들의 무선 접속 권한 설정
KR20120024065A (ko) * 2010-09-03 2012-03-14 엘지전자 주식회사 통신 연결 장치 및 그 방법
KR20120052549A (ko) * 2010-11-16 2012-05-24 한국전자통신연구원 저속 네트워크 통신을 이용한 단말 간 접속 제어 방법 및 이를 이용한 장치
KR20130027876A (ko) * 2011-09-08 2013-03-18 유용 근거리 무선 통신 모듈을 사용한 거래 중개 시스템 및 그 방법

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017018604A1 (ko) * 2015-07-26 2017-02-02 엘지전자(주) 블루투스 le(low energy) 기술을 이용하여 대체 통신 수단을 연결하기 위한 방법 및 장치
US10827391B2 (en) 2015-07-26 2020-11-03 Lg Electronics Inc. Method and device for connecting substitute communication means by using bluetooth low energy (LE) technique
EP3182765A1 (en) * 2015-12-18 2017-06-21 EM Microelectronic-Marin SA Method and device for bluetooth low power communication
US9918186B2 (en) 2015-12-18 2018-03-13 Em Microelectronic-Marin Sa Method and device for bluetooth low power communication
CN109690959A (zh) * 2016-09-09 2019-04-26 华为技术有限公司 一种文件的发送方法、接收方法及终端
US10701545B2 (en) 2016-09-09 2020-06-30 Huawei Technologies Co., Ltd. File sending method and terminal, and file receiving method and terminal
CN109690959B (zh) * 2016-09-09 2021-02-26 华为技术有限公司 一种文件的发送方法、接收方法及终端
US11191115B2 (en) * 2017-01-23 2021-11-30 Lg Electronics Inc. Bluetooth communication method and apparatus
US11452151B2 (en) 2018-05-31 2022-09-20 Huawei Technologies Co., Ltd. Application function implementation method and electronic device
US11864248B2 (en) 2018-05-31 2024-01-02 Huawei Technologies Co., Ltd. Application function implementation method and electronic device

Also Published As

Publication number Publication date
US20160278006A1 (en) 2016-09-22
US9936448B2 (en) 2018-04-03

Similar Documents

Publication Publication Date Title
WO2015068988A1 (ko) 무선 통신 시스템에서 데이터를 송수신하는 방법 및 이를 수행하기 위한 장치
US9730257B2 (en) Method and apparatus for establishing device-to-device connection in wireless communication system
US10827334B2 (en) Method and apparatus for connecting devices using Bluetooth LE technology
US10798548B2 (en) Method for controlling device by using Bluetooth technology, and apparatus
US10863321B2 (en) Method and device for transmitting and receiving data using Bluetooth technology
US10560974B2 (en) Method and apparatus for connecting device by using Bluetooth technology
US20170208639A1 (en) Method and apparatus for controlling a device using bluetooth technology
US10111025B2 (en) Service providing terminal connection method and apparatus
EP2387205B1 (en) Method and System for Providing Wi-Fi Service by Wi-Fi Device
US9794323B2 (en) Method and apparatus for performing object transfer service using bluetooth low energy in wireless communication system
CN103298068A (zh) 用于发现在无线通信网络中的装置的方法和设备
US10887762B2 (en) Method and apparatus for transmitting and receiving data using Bluetooth technology
KR20110125695A (ko) 와이파이 디바이스의 와이파이 서비스 제공 방법 및 시스템
US20160299739A1 (en) Method for controlling data streaming using bluetooth communication
US10721611B2 (en) Method and device for controlling device by using Bluetooth technology
US11622196B2 (en) Method for transmitting audio data by using short-range wireless communication in wireless communication system, and apparatus for same
US10924904B2 (en) Method and apparatus for performing object transfer service by using bluetooth communication in wireless communication system
US10492060B2 (en) Method and device for transmitting/receiving data in wireless communication system
US10194477B2 (en) Method and apparatus for controlling a device using bluetooth technology
KR102074760B1 (ko) 기기 간 자동 무선 통신 연결되는 영상 표시장치 및 이에 따른 영상표시 방법
US11367449B2 (en) Method and apparatus for calling voice recognition service by using Bluetooth low energy technology
US20220391165A1 (en) Method for transmitting audio data using short-range communication in wireless communication system, and device for same
WO2016117926A1 (ko) 무선 통신 시스템에서 디스커버리를 수행하기 위한 방법 및 이를 위한 장치
US20210243599A1 (en) User authentication method through bluetooth device and device therefor
US11252553B2 (en) Method and device for establishing connection using Bluetooth low energy

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: 14860346

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 15035082

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 14860346

Country of ref document: EP

Kind code of ref document: A1