WO2020096412A1 - 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치 - Google Patents

블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치 Download PDF

Info

Publication number
WO2020096412A1
WO2020096412A1 PCT/KR2019/015163 KR2019015163W WO2020096412A1 WO 2020096412 A1 WO2020096412 A1 WO 2020096412A1 KR 2019015163 W KR2019015163 W KR 2019015163W WO 2020096412 A1 WO2020096412 A1 WO 2020096412A1
Authority
WO
WIPO (PCT)
Prior art keywords
audio
information
audio data
server device
data
Prior art date
Application number
PCT/KR2019/015163
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 US17/292,329 priority Critical patent/US11665214B2/en
Publication of WO2020096412A1 publication Critical patent/WO2020096412A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1059—End-user terminal functionalities specially adapted for real-time communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1094—Inter-user-equipment sessions transfer or sharing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363—Adapting the video stream to a specific local network, e.g. a Bluetooth® network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/485—End-user interface for client configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/08—User group management
    • 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
    • H04W56/00—Synchronisation arrangements
    • H04W56/001—Synchronization between nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup

Definitions

  • the present invention relates to a method and apparatus for receiving audio data using a Bluetooth technology that is a short-range technology in a wireless communication system, and more specifically, to receive audio data based on an audio feedback type using Bluetooth technology It relates to a method and apparatus for.
  • Bluetooth is a short-range wireless technology standard that can wirelessly connect various devices in a short distance to send and receive data.
  • a user When performing wireless communication between two devices using Bluetooth communication, a user performs a procedure of discovering and discovering Bluetooth devices to be communicated. do.
  • a device may mean an apparatus and an apparatus.
  • the user may perform a connection after searching for the Bluetooth device based on the Bluetooth communication method to be used using the Bluetooth device.
  • Bluetooth communication methods include a BR / EDR (Basic Rate / Enhanced Data Rate) method and a low-power LE (Low Energy) method.
  • the BR / EDR method may be referred to as Bluetooth Classic.
  • the Bluetooth classic method includes Bluetooth technology that has been continued since Bluetooth 1.0 using a basic rate, and Bluetooth technology that uses an enhanced data rate supported since Bluetooth 2.0.
  • Bluetooth Low Energy Bluetooth Low Energy
  • Bluetooth LE Bluetooth Low Energy
  • the Bluetooth low power energy technology uses Attribute Protocol to exchange information between devices.
  • the Bluetooth LE method can reduce energy consumption by reducing header overhead and simplifying operation.
  • Some Bluetooth devices do not have a display or user interface.
  • the complexity of connection / management / control / disconnection between various types of Bluetooth devices and Bluetooth devices with similar technology is increasing.
  • Bluetooth can be relatively fast at a relatively low power and low cost, but since the transmission distance is generally limited to a maximum of 100 m, it is suitable for use in a limited space.
  • An object of the present specification is to provide a method and apparatus for receiving audio data using Bluetooth technology.
  • an object of the present invention is to provide a method and apparatus for acquiring information related to a type of audio data by listening to a voice feedback based on the audio feedback information.
  • an object of the present invention is to provide a method and apparatus for receiving only audio data that a user desires to hear by listening to voice feedback based on the audio feedback information.
  • the present specification provides a method of receiving audio data using Bluetooth Low Energy technology.
  • a method performed by a client device provides an audio streaming service
  • Receiving, from a server device, an advertisement message including channel information for receiving an expanded advertisement message to perform
  • Receiving, from the server device, the extended advertisement message including an indicator related to audio data of the audio streaming service based on the channel information, wherein the indicator is audio feedback information for identifying the audio data and the audio data Indicates grouped and transmitted
  • decoding the audio feedback information And characterized in that it further comprises the step of outputting the decoded audio feedback information.
  • the present specification is characterized in that the channel information includes an index of a channel through which the extended advertisement message is transmitted and / or synchronization channel information for synchronization of the client device and the server device.
  • the synchronization information is a grouping ID associated with the audio data and the audio feedback information grouped, an audio data ID for identifying the audio data, or an audio feedback ID for identifying the audio feedback information. It characterized in that it comprises at least one of.
  • the present specification forming a connection with the server device; Transmitting a read request message to the server device requesting to read the status information of the audio feedback information stored in the first characteristic of the server device, the status information is the name information of the audio data,
  • the audio data includes at least one of date information stored in the first specific characteristic or version information of the audio data;
  • a write request message requesting to write a characteristic value associated with the changed audio feedback information in the second specific characteristic of the server device for changing the audio feedback information based on the status information Transmitting to the server device, the write request message includes data of some of the data constituting the changed audio feedback information; And receiving a write response message from the server device in response to the write request message.
  • each of the write request messages includes sequence number information for some of the data.
  • the present specification further includes receiving all synchronization information related to synchronization between the plurality of server devices and the client device from a management server managing a plurality of servers including the server device, wherein the entire synchronization
  • the information is characterized by including synchronization information for each of the plurality of devices.
  • the present specification is characterized in that the management server includes receiving and storing synchronization information for each of the plurality of server devices in advance.
  • a client device for receiving audio data using Bluetooth Low Energy (Bluetooth Low Energy) technology, Transmitter (transmitter) for transmitting a wireless signal;
  • a receiver for receiving a radio signal;
  • a processor functionally connected to the transmitter and receiver, wherein the processor includes an advertising message including channel information for receiving an extended advertisement message for providing an audio streaming service (Server).
  • the processor includes an advertising message including channel information for receiving an extended advertisement message for providing an audio streaming service (Server).
  • Control the receiver to receive from the device, control the receiver to receive from the server device the extended advertisement message including an indicator related to audio data of the audio streaming service based on the channel information, and control the receiver.
  • Indicates that the audio data and audio feedback information for identifying the audio data are grouped and transmitted, and is configured to receive the audio data and the audio feedback information from the server device through an isochronous channel.
  • Control the existing receiver obtain specific information related to whether or not to allow the provision of the audio streaming service from the user based on the audio feedback information, and when the specific information indicates
  • This specification has an effect of receiving audio data using Bluetooth technology.
  • the present specification has an effect of receiving audio feedback information related to audio data received from a plurality of devices.
  • FIG. 1 is a schematic diagram showing an example of a wireless communication system using the Bluetooth low power energy technology proposed in the present specification.
  • FIG. 2 shows an example of an internal block diagram of a device capable of implementing the methods proposed herein.
  • FIG 3 shows an example of a Bluetooth communication architecture to which the methods proposed in this specification can be applied.
  • FIG 4 shows an example of the structure of the Bluetooth low power energy GATT (Generic Attribute Profile).
  • FIG. 5 is a flowchart illustrating an example of a connection procedure method in a Bluetooth low power energy technology to which the present invention can be applied.
  • FIG. 7 shows an example of a home ecosystem for applications in which an isochronous channel may be used.
  • FIG. 8 shows an example of a GAM (Generic Audio Middleware) protocol stack to which the present invention can be applied.
  • GAM Generic Audio Middleware
  • FIG. 9 is a diagram illustrating an example in which a client device searches for a device without filtering.
  • FIG. 10 is a diagram illustrating a problem when a plurality of server devices exist around a client device.
  • FIG. 11 is a diagram illustrating an example in which an advertisement message of a server device is transmitted.
  • 12A and 12B are diagrams illustrating an example of a data format of an advertisement message transmitted by a server device and an advertisement message transmission timing.
  • FIG. 13 is a diagram illustrating an example in which audio data transmission using Bluetooth low power (BLE) is performed.
  • BLE Bluetooth low power
  • BLE 14 is a diagram illustrating another example in which audio data transmission using Bluetooth low power (BLE) is performed.
  • 15 is a diagram illustrating an example in which the method proposed in the present specification is performed.
  • 16 is a diagram illustrating an example in which the method proposed in the present specification is performed.
  • 17 is a diagram illustrating an example in which the method proposed in the present specification is performed.
  • FIG. 18 is a diagram illustrating an example of transmitting a BIS included in the BIG proposed in this specification.
  • 19 is a diagram illustrating an example in which the method proposed in the present specification is performed.
  • 20 is a diagram illustrating an example in which the method proposed in the present specification is performed.
  • 21 and 22 are diagrams illustrating an example in which the method proposed in the present specification is performed.
  • 23 and 24 are views showing another example in which the method proposed in the present specification is performed.
  • 25 is a diagram illustrating an example of an operation implemented in a terminal for receiving audio data using the Bluetooth technology proposed in this specification.
  • FIG. 1 is a schematic diagram showing an example of a wireless communication system using the Bluetooth low power energy technology proposed in the present specification.
  • the wireless communication system 100 includes at least one server device 120 and at least one client device 110.
  • the server device and the client device perform Bluetooth communication using Bluetooth Low Energy (BLE, hereinafter referred to as 'BLE' for convenience).
  • BLE Bluetooth Low Energy
  • BLE technology has a relatively small duty cycle and low cost production compared to Bluetooth BR / EDR (Basic Rate / Enhanced Data Rate) technology, and it is possible to significantly reduce power consumption through low-speed data transfer rates.
  • Bluetooth BR / EDR Basic Rate / Enhanced Data Rate
  • BLE technology simplifies the connection process between devices, and the packet size is also designed to be smaller than that of Bluetooth BR / EDR technology.
  • the number of RF channels is 40
  • the data transmission rate supports 1Mbps
  • the topology is a scatternet structure
  • latency is 3ms
  • the output power is less than 10mW (10dBm)
  • the server device 120 may operate as a client device in a relationship with other devices, and the client device may operate as a server device in a relationship with other devices. That is, in the BLE communication system, any one device can operate as a server device or a client device, and if necessary, it is also possible to operate simultaneously as a server device and a client device.
  • the server device 120 includes a data service device, a slave device device, a slave, a server, a conductor, a host device, a gateway, and a sensing device.
  • a sensing device a monitoring device (monitoring device), the first device, may be represented as a second device.
  • the client device 110 is a master device (master device), a master (master), a client, a member (Member), a sensor device, a sink device (Sink Device), a collector (Collector), a third device, a fourth device, etc. Can be expressed.
  • the server device and the client device correspond to main components of the wireless communication system, and the wireless communication system may include other components in addition to the server device and the client device.
  • the server device refers to a device that provides data to a client device through a response when receiving a data request from the client device by receiving data from the client device and performing direct communication with the client device.
  • the server device sends a notification / notification message and an indication message to the client device to provide data information to the client device.
  • the server device receives a confirmation message corresponding to the indication message from the client.
  • the server device provides data information to a user through a display unit or receives a request input from a user through a user input interface in a process of transmitting and receiving notifications, instructions, and confirmation messages to and from a client device. can do.
  • the server device may read data from a memory unit or write new data to the memory in the process of transmitting and receiving a message with the client device.
  • one server device may be connected to a plurality of client devices, and it is possible to easily reconnect (or connect) with client devices by utilizing bonding information.
  • the client device 120 refers to a device that requests data information and data transmission from a server device.
  • the client device receives data from the server device through a notification message, an instruction message, or the like, and when receiving an instruction message from the server device, sends a confirmation message in response to the instruction message.
  • the client device may similarly provide information to the user through the output unit or receive input from the user through the input unit in the process of transmitting and receiving messages with the server device.
  • the client device may read data from memory or write new data to the memory in the process of transmitting and receiving messages with the server device.
  • Hardware components such as the output unit, the input unit, and the memory of the server device and the client device will be described in detail in FIG. 2.
  • the wireless communication system may configure Personal Area Networking (PAN) through Bluetooth technology.
  • PAN Personal Area Networking
  • files and documents can be exchanged quickly and safely by establishing a private piconet between devices.
  • FIG. 2 shows an example of an internal block diagram of a device capable of implementing the methods proposed herein.
  • the server device 110 includes an output unit (Display Unit, 111), an input unit (User Input Interface, 112), a power supply unit (Power Supply Unit, 113), a processor (Processor, 114), and memory (Memory Unit, 115), a Bluetooth interface (Bluetooth Interface, 116), another communication interface (Other Interface, 117) and a communication unit (or transmitting and receiving unit, 118).
  • the output unit 111, the input unit 112, the power supply unit 113, the processor 114, the memory 115, the Bluetooth interface 116, other communication interface 117 and the communication unit 118 is proposed herein Functionally connected to perform the method.
  • the output unit 121, the input unit 122, the power supply unit 123, the processor 124, the memory 125, the Bluetooth interface 126, and the communication unit 127 to perform the method proposed herein Functionally connected.
  • the Bluetooth interfaces 116 and 126 refer to units (or modules) capable of transmitting / requesting requests, responses, commands, notifications, instructions / confirmation messages, etc. between devices using Bluetooth technology.
  • the processor 114, 124 refers to a module that controls the overall operation of the server device 110 or the client device 120, and controls to process a request to transmit a message and a received message through a Bluetooth interface and other communication interfaces.
  • the processors 114 and 124 may include application-specific integrated circuits (ASICs), other chipsets, logic circuits, and / or data processing devices.
  • ASICs application-specific integrated circuits
  • the processors 114 and 124 control the communication unit to receive an advertising message from the server device 110, transmit a scan request message to the server device 110, and the server device 110 Control the communication unit to receive a scan response message in response to the scan request, and connect request message to the server device 110 to establish a Bluetooth connection with the server device 110 It controls the communication unit to transmit.
  • the processors 114 and 124 can read or write data using the attribute protocol from the server device 110. Control the communication unit.
  • the memories 115 and 125 may include read-only memory (ROM), random access memory (RAM), flash memory, memory cards, storage media, and / or other storage devices.
  • ROM read-only memory
  • RAM random access memory
  • flash memory memory cards, storage media, and / or other storage devices.
  • the communication units 118 and 127 may include a baseband circuit for processing wireless signals.
  • the above-described technique may be implemented as a module (process, function, etc.) performing the above-described function. Modules are stored in memory and can be executed by a processor.
  • the memories 115 and 125 may be inside or outside the processors 114 and 124, and may be connected to the processors 114 and 124 by various well-known means.
  • the output units 111 and 121 refer to a module for providing device status information and message exchange information to a user through a screen.
  • the power supply unit (power supply unit 113, 123) refers to a module that receives external power and internal power under control of a control unit and supplies power required for the operation of each component.
  • BLE technology has a small duty cycle and can significantly reduce power consumption through low data rates.
  • Figure 3 shows an example of the architecture of Bluetooth Low Energy (LE).
  • LE Bluetooth Low Energy
  • the BLE structure includes a controller stack operable to process a timing-critical wireless device interface and a host stack operable to process high level data.
  • the controller stack may be referred to as a controller, but in order to avoid confusion with the processor, which is an internal component of the device mentioned in FIG. 2, is referred to as a controller stACK below.
  • the controller stack may be implemented using a communication module that may include a Bluetooth wireless device, and a processor module that may include, for example, a processing device such as a microprocessor.
  • the host stack can be implemented as part of the OS running on the processor module, or as an instantiation of a package on top of the OS.
  • controller stack and host stack can be run or executed on the same processing device in the processor module.
  • the host stack includes GAP (Generic Access Profile, 310), GATT based Profiles (320), GATT (Generic Attribute Profile, 330), ATT (Attribute Protocol, 340), SM (Security Manage, 350), L2CAP (Logical Link Control and Adaptation Protocol, 360).
  • GAP Generic Access Profile
  • GATT Generic Attribute Profile
  • ATT Generic Attribute Profile
  • ATT Attribute Protocol
  • SM Simple Adaptation Protocol
  • L2CAP Logical Link Control and Adaptation Protocol, 360.
  • the host stack is not limited to this, and may include various protocols and profiles.
  • the host stack uses L2CAP to multiplex various protocols, profiles, etc. provided by Bluetooth.
  • Logical Link Control and Adaptation Protocol (L2CAP) 360 provides one bidirectional channel for transmitting data to a specific protocol or profile.
  • BLE uses three fixed channels (one for signaling CH, one for Security Manager, and one for Attribute protocol).
  • BR / EDR Base Rate / Enhanced Data Rate
  • SM Security Manager, 350
  • SM Secure Manager
  • ATT Attribute Protocol, 340
  • ATT is a server-client (Server-Client) structure to define the rules for accessing the data of the other device.
  • ATT has six message types (Request, Response, Command, Notification, Indication, Confirmation).
  • the Request message is a message for requesting specific information from the client device to the server device
  • the Response message is a response message to the Request message, from the server device to the client device Refers to the message being sent to.
  • Command message a message sent to indicate a command of a specific operation from a client device to a server device, and the server device does not transmit a response to the command message to the client device.
  • Notification message This is a message transmitted from the server device to the client device for notification, such as an event, and the client device does not transmit a confirmation message for the Notification message to the server device.
  • Indication and Confirm message A message sent for notification, such as an event, from the server device to the client device. Unlike the Notification message, the client device sends a confirmation message for the Indication message to the server device.
  • GAP Generic Access Profile
  • GAP is mainly used for device discovery, connection creation, and security procedures, and defines a method for providing information to users, and defines the following attribute types.
  • 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, etc.
  • the details of GATT-based Profiles are as follows.
  • GATT may be operable as a protocol that describes how ATT is used in configuring services. For example, GATT may be operable to specify how ATT attributes are grouped together into services, and may be operable to describe features associated with services.
  • GATT and ATT can use features to describe the device's state and services, and how features are related to each other and how they are used.
  • the controller stack includes a physical layer (390), a link layer (Link Layer 380), and a host controller interface (Host Controller Interface, 370).
  • the physical layer (wireless transmit / receive module, 390) is a layer that transmits and receives a 2.4 GHz wireless signal and uses GFSK (Gaussian Frequency Shift Keying) modulation and a frequency hopping technique consisting of 40 RF channels.
  • GFSK Gausian Frequency Shift Keying
  • the link layer 380 transmits or receives Bluetooth packets.
  • the link layer provides a function to create a connection between devices after performing Advertising and Scanning functions using 3 Advertising channels, and provides a function to exchange data packets of up to 42 bytes through 37 Data channels.
  • HCI Host Controller Interface
  • the host stack provides commands and data to the controller stack, and the controller stack provides events and data to the host stack.
  • the BLE procedure may be divided into 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 that respond to requests, instructions, and notifications from the controller stack.
  • the controller stack can control the BLE controller stack to reduce power consumption by reducing the number of transmitting requests.
  • the advertising device or scanning device may perform the device filtering procedure to limit devices that receive advertising packets, scan requests, or connection requests.
  • the advertisement device refers to a device that transmits an advertisement event, that is, performs an advertisement, and is also expressed 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 advertisement packets from the advertisement device, the scanning device must send a scan request to the advertisement device.
  • the scanning device may ignore advertisement packets transmitted from the advertisement device.
  • the device filtering procedure may be used in the connection request process. If device filtering is used in the connection request process, it is not necessary to transmit a response to the connection request by ignoring the connection request.
  • the advertising device performs an advertising procedure to perform non-directional broadcasting to devices in the area.
  • non-directional broadcast refers to broadcast in all (all) directions, not broadcast in a specific direction.
  • directional broadcast refers to broadcast in a specific direction.
  • a non-directional broadcast occurs 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 can be used to provide periodic broadcasts of user data to scanning devices that are listening on the advertising channel.
  • all advertisements are broadcast through the advertisement physical channel.
  • Advertising devices may receive a scan request from listening devices that are performing listening to obtain additional user data from the advertising device.
  • the advertisement device transmits a response to the scan request to the device that transmitted the scan request through the same advertisement physical channel as the advertisement physical channel that received the scan request.
  • Broadcast user data sent as part of advertising packets 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 advertisement device uses a connectable advertisement event, and the initiating device is not filtered by the device filtering procedure, the advertisement device stops the advertisement and enters the connected mode. The advertising device may start advertising again after the connected mode.
  • a device that performs scanning that is, a scanning device, performs a scanning procedure to listen to non-directional broadcasts of user data from advertising devices using an advertising physical channel.
  • the scanning device sends a scan request through the advertising physical channel to the advertising device to request additional data from the advertising device.
  • the advertisement device transmits a scan response that is a response to the scan request, including additional data requested by the scanning device through the advertisement physical channel.
  • the scanning procedure can be used while connecting to other BLE devices in the BLE piconet.
  • the scanning device If the scanning device receives a broadcast advertisement event and is in an initiator mode capable of initiating a connection request, the scanning device sends the connection request to the advertisement device through the advertisement physical channel, thereby advertising device And Bluetooth connection can be started.
  • the scanning device When the scanning device sends a connection request to the advertising device, the scanning device stops the 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 advertisement and scanning procedures to discover nearby devices or to be discovered by other devices within a given area.
  • the discovery process is performed asymmetrically.
  • a Bluetooth device that seeks to find other devices around it is called a discovering device and listens to devices that advertise a scannable advertising event.
  • a Bluetooth device found and available from another device is called a discoverable device, and actively broadcasts an advertising event to allow other devices to scan through the advertising (broadcast) physical channel.
  • Both the discovering device and the discoverable device may already be connected to other Bluetooth devices in the piconet.
  • connection procedure is asymmetric, and the connection procedure requires that another Bluetooth device perform the scanning procedure while the specific Bluetooth device performs the advertisement procedure.
  • the advertising process can be an objective, and as a result, only one device will respond to the advertisement.
  • the connection After receiving a connectable advertisement event from the advertisement device, the connection can be initiated by sending a connection request to the advertisement device through the advertisement (broadcast) physical channel.
  • the link layer LL enters the advertisement state by the instruction of the host (stack).
  • the link layer transmits advertisement packet data units (PDUs) in advertisement events.
  • PDUs advertisement packet data units
  • Each advertisement event is composed of at least one advertisement PDU, and advertisement PDUs are transmitted through advertisement channel indexes used.
  • the advertisement event may be terminated when the advertisement PDU is transmitted through the advertisement channel indexes used, respectively, or the advertisement event may be terminated earlier if the advertisement device needs to make space for performing other functions.
  • the link layer enters the scanning state at the instruction of the host (stack). In the scanning state, the link layer listens to the advertisement channel indices.
  • scanning states There are two types of scanning states: passive scanning and active scanning, and each scanning type is determined by the host.
  • No separate time or advertisement channel index is defined to perform scanning.
  • the scan interval is defined as the interval (interval) between the start points of two consecutive scan windows.
  • the link layer should listen to complete all scan intervals of the scan window as indicated by the host. In each scan window, the link layer must scan a different advertisement channel index. The link layer uses all available advertising channel indices.
  • the link layer In passive scanning, the link layer only receives packets, and cannot transmit any packets.
  • the link layer performs listening to rely on the type of advertisement PDUs that can request advertisement PDUs and additional information related to the advertisement device to the advertisement device.
  • the link layer enters the start state by the instruction of the host (stack).
  • the link layer When the link layer is in the initiating state, the link layer performs listening on advertisement channel indexes.
  • the link layer listens to the advertisement channel index during the scan window period.
  • the link layer enters a connection state when a device performing a connection request, that is, when 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 state After entering the connection state, it is considered that a connection is created. However, it is not necessary to be considered to be established when the connection enters the connection state. The only difference between a newly created connection and an established connection is the link layer connection supervision timeout value.
  • the link layer performing a master role is called a master, and the link layer performing a slave role is called a slave.
  • the master adjusts the timing of the connection event, and the connection event refers to the point in time between synchronization between the master and the slave.
  • BLE devices use the packets defined below.
  • the link layer has only one packet format used for both advertising channel packets and data channel packets.
  • Each packet consists of four fields: Preamble, Access Address, PDU and CRC.
  • the PDU When one packet is transmitted on the advertisement physical channel, the PDU will be the advertisement channel PDU, and when one packet is transmitted on the data physical channel, the PDU will be the data channel PDU.
  • the advertising channel PDU Packet Data Unit
  • PDU Packet Data Unit
  • the PDU type field of the advertisement 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-directional advertising event
  • ADV_DIRECT_IND Connectable directional advertising event
  • ADV_SCAN_IND scannable non-directional advertising event
  • the PDUs are transmitted in the link layer in an advertisement state and received by the link layer in a scanning state or an initiating state.
  • the advertising channel PDU type below is called a scanning PDU and is used in the state described below.
  • SCAN_REQ transmitted by the link layer in the scanning state, and received by the link layer in the advertising state.
  • SCAN_RSP transmitted by the link layer in the advertisement state, and received by the link layer in the scanning state.
  • the advertising channel PDU type below is called a starting PDU.
  • CONNECT_REQ transmitted by the link layer in the initiation state, and received by the link layer in the advertising state.
  • the data channel PDU has a 16-bit header, a payload of various sizes, and may include a message integrity check (MIC) field.
  • MIC message integrity check
  • FIG 4 shows an example of the structure of the Bluetooth low power energy GATT (Generic Attribute Profile).
  • GATT Generic Attribute Profile
  • Service Service
  • Characteristic Characteristic
  • a peripheral device eg, a sensor device
  • GATT server acts as a GATT server and has definitions for service and characteristics.
  • the GATT client In order to read or write data, the GATT client sends a data request to the GATT server, and all transactions are initiated from the GATT client to receive a response from the GATT server.
  • the GATT-based operation structure used in Bluetooth LE is based on a profile, a service, and a characteristic, and may achieve a vertical structure as shown in FIG. 5.
  • the profile is composed of one or more services, and the service may be composed of one or more characteristics or other services.
  • the service serves to divide data into logical units, and may include one or more characteristic or other services.
  • Each service has a 16-bit or 128-bit identifier called UUID (Universal Unique Identifier).
  • the characteristic is the lowest unit in the GATT-based operation structure.
  • the characteristic includes only one data, and has a UUID of 16 bits or 128 bits similar to the service.
  • the above characteristics are defined as values of various pieces of information, and one attribute is required to contain each piece of information. Multiple consecutive properties of the above properties can be used.
  • the attribute consists of four components and has the following meaning.
  • FIG. 5 is a flowchart illustrating an example of a connection procedure method in a Bluetooth low power energy technology to which the present invention can be applied.
  • the server transmits an advertisement message to the client through three advertisement channels (S5010).
  • the server may be called an advertiser before connection, and may be called a master after connection.
  • a sensor such as a temperature sensor.
  • the client may be called a scanner before connection, and may be called a slave after connection.
  • An example of a client may be a smart phone.
  • Bluetooth is divided into a total of 40 channels and communicates through the 2.4GHz band.
  • Three of the 40 channels are advertisement channels, which are used for exchanging packets exchanged to establish a connection, including various advertising packets.
  • the remaining 37 channels are used as data channels for data exchange after connection.
  • the client may transmit a scan request message to the server to obtain additional data (eg, a server device name) to the server.
  • additional data eg, a server device name
  • the server transmits a scan response message including additional data to the client in response to a scan request message.
  • the scan request message (Scan Request message) and the scan response message (Scan Response message) is one end of the advertisement packet
  • the advertisement packet may include only user data (User Data) of 31 bytes or less.
  • the data is divided and transmitted twice using a scan request message / scan response message.
  • the client transmits a connection request message for establishing a Bluetooth connection with the server to the server (S5020).
  • the security establishment procedure may be interpreted as Secure Simple Pairing or performed by including the same.
  • the security establishment procedure may be performed through Phase 1 to Phase 3 steps.
  • phase 1 a pairing procedure (phase 1) is performed between the server and the client (S5030).
  • the client sends a pairing request message to the server, and the server sends a pairing response message to the client.
  • phase 2 legacy pairing or secure connections are performed between the server and the client (S5040).
  • Phase 2 a 128-bit temporary key and a short term key (STK) that perform legacy pairing are generated.
  • STK short term key
  • STK Short Term Key
  • LTK long term key
  • LTK Long Term Key
  • phase 3 a key distribution procedure is performed between the server and the client (S5050).
  • Audio data occurs periodically (or at specific time intervals) depending on its characteristics.
  • a specific time period in which audio data periodically occurs may be expressed as an Idle Event Interval.
  • Each audio data is transmitted at each Idle Event Interval.
  • each audio data may be transmitted through all or part of the Idle Event Interval.
  • audio data generally occurs periodically, and a latency guarantee for audio data transmission is essential regardless of the amount of data.
  • Audio data transmission through hearing aids (Hearing Aids) or headsets is relatively low, so high energy efficiency can be obtained when using BLE technology rather than Bluetooth BR / EDR technology. Since the Data Channel Process of Advertising has to perform advertising, connection, etc. for each data transmission, it has a large overhead in data transmission, and in particular, it cannot guarantee the absolutely necessary latency guarantee in audio data transmission. .
  • the BLE technology's Data Channel Process transmits data that is generated only when necessary, and in other time domains, it aims to increase energy efficiency by inducing deep sleep of BLE devices. It may be difficult to apply the BLE technology's Data Channel Process for the transmission of data.
  • Mechanism for transmitting and receiving periodically generated data, such as audio streaming using BLE technology.
  • the present invention provides a procedure for a user device to recognize devices capable of recognizing and processing a user's audio signal, and to deliver a processed audio signal to a target device in order to control devices with the user's voice.
  • Audio streaming data (Audio Streaming Data), audio data (Audio Data), audio streaming (Audio Streaming), audio stream (Audio Stream) may be interpreted in the same meaning.
  • a new channel i.e., an isochronous channel.
  • Isochronous Channel is a channel used to transmit isochronous data between devices using isochronous streams (eg Conductor-Member).
  • Isochronous data refers to data transmitted at specific time intervals, that is, periodically or regularly.
  • an isochronous channel may represent a channel through which data periodically generated, such as audio data or voice data, is transmitted and received in BLE technology.
  • the isochronous channel can be used to transmit and receive audio data to a single member, a set of one or more coordinated members, or multiple members.
  • the isochronous channel corresponds to an isochronous stream such as audio streaming or a flushing channel that can be used to transmit and receive important data in another time domain.
  • the methods using isochronous channels are operated independently from the Advertising Channel and Data Channel used in the existing (v4.2 or lower) BLE technology.
  • a new frequency channel and a frequency hopping interval for isochronous channels may be additionally defined.
  • the isochronous channel enables transmission of an isochronous stream, such as flushable data (e.g. time-bound audio data), using BLE from a conductor to one or more members.
  • flushable data e.g. time-bound audio data
  • the conductor can be expressed as a master and the member as a slave.
  • the isochronous channel may or may not be secured.
  • isochronous channels are synchronized between a single conductor and a member, between a single conductor and coordinated pair of members making stereo audio, such as hearing aids or stereo headsets, in the same isochronous stream (s) as a single conductor. It can be set up in various topologies to allow transmission of isochronous streams between members of.
  • the member can transmit data to the conductor through the same isochronous channel.
  • the isochronous channel may support not only personal audio but also transmission and reception of shared audio, public audio, and broadcast audio.
  • the isochronous channel setup procedure requires that the hierarchy of profile level security and reliability requirements satisfy different use cases.
  • isochronous channel can be used for a variety of applications, whereby multiple source devices and sinks can be configured, and complex topologies can be configured to allow users to regularly change or share different audio streams. have.
  • FIG. 7 shows an example of a home ecosystem for applications in which an isochronous channel may be used.
  • FIG. 7 shows an example of a space in which a plurality of audio conductors and members to which the methods proposed in this specification can be applied can move inside / outside each other.
  • the existence of various conductors and members may mean that an isochronous channel is required as a method for informing the existence of a member so that a member can obtain information necessary to establish an isochronous channel. have.
  • Isochronous channels can also be used for the transmission and reception of non-audio data.
  • the member may use isochronous channels to determine whether there are notification messages that may include acquisition information from conductors within BLE communication range.
  • the member may also use isochronous channels to receive requests for control information or service data from one or more devices acting like a remote controller.
  • FIG. 8 shows an example of a GAM (Generic Audio Middleware) protocol stack to which the present invention can be applied.
  • GAM Generic Audio Middleware
  • An audio architecture including an audio middleware layer can support unicast and broadcast audio using BLE.
  • the audio middleware layer facilitates transitions between connections of audio applications, and can develop more advanced user cases.
  • GAM can provide a smooth audio service to users even in dynamic and multi-profile environments. Since middleware can handle audio mixing of various user cases and switching between user cases, each profile can focus on a specific function.
  • GAM defines announcements for audio streaming, signal transmission for audio control and data transmission.
  • the application layer defines application signaling and necessary transport parameters.
  • the user device When a plurality of devices exist around a user, when the user wants to receive specific audio data transmitted by a specific device using the device through an audio streaming service, the user device is After receiving the synchronization information (sync information), the audio data is listened without a separate filtering process.
  • a specific device that transmits audio data desired to be received by the user must be directly selected from among a plurality of devices searched using the UI. Therefore, when listening to audio data immediately without filtering, it is inconvenient for the user to listen to audio data that the user does not want.
  • the user uses a device-mounted UI, there is a inconvenience in that the user has to perform a separate operation to listen to audio data.
  • the above discomfort may not be great when there is only one device that transmits audio data around the client device, but when a device that transmits a plurality of audio data exists in the vicinity, the user's device may have multiple devices. It is difficult to check which device is synchronized with which device.
  • a device that transmits audio data may be represented by a server, a server device, or an initiator.
  • a device of a user receiving audio data may be represented as a client, a client device, and an acceptor.
  • FIG. 9 is a diagram illustrating an example in which a client device searches for a device without filtering.
  • the server device transmits synchronization information to the peripheral devices (S911).
  • the server device transmits the audio data to the peripheral device (S912).
  • the server device may transmit synchronization information and audio data to a peripheral device through a broadcast method. Further, the server device may periodically perform the operations S911 to S912.
  • the client device receives synchronization information from a device that transmits a server device (S921).
  • the client device receives audio data from the server device (S922).
  • the client device receives the received audio data without filtering.
  • the client device receives synchronization information from the server device (S931).
  • the user may select whether to receive the received audio data without filtering through the user UI (S932).
  • a plurality of server devices exist around the client device, a plurality of devices transmitting audio data on the display of the client device may be searched.
  • the client device receives audio data from the server device (S933).
  • FIG. 10 is a diagram illustrating a problem when a plurality of server devices exist around a client device.
  • the client device when searching for nearby devices through a client device such as a smartphone, the number of devices that can be displayed on the display of the client device may be exceeded.
  • the client device shows the name of the searched device to the user, which makes it difficult to accurately find a specific device that transmits audio data that the user wants to receive.
  • FIG. 11 is a diagram illustrating an example in which an advertisement message of a server device is transmitted.
  • the server device transmits an advertisement message including an Aux_Ext_indication packet through a primary channel (1101).
  • the advertisement message may include channel information through which an extended advertising message is transmitted.
  • the server device transmits an extended advertisement message through a secondary channel (1102).
  • the client device can receive the expanded advertisement message based on the channel information.
  • the expanded advertisement message may include synchronization information.
  • the server device transmits audio data for providing an audio data streaming service through an isochronous channel (1103).
  • Audio data may be transmitted in an Aux_Sync_indication packet or an Aux_Chain_Indication packet.
  • 12A and 12B are diagrams illustrating an example of a data format of an advertisement message transmitted by a server device and an advertisement message transmission timing.
  • the advertisement channel PDU 1201 may include a header field having a size of 16 bits and a payload field having a size of 1-255 octets.
  • the 1202 indicates a payload field included in the extended advertisement message.
  • the field is a 6-bit extended header length field (Extended Header Length), a 2-bit AdvMode field indicating a mode in which an advertisement message is transmitted, an extended header field having a size of 0-63 octet, and an audio streaming service. It may include an AdvData field having a size of 0-254 octet containing the audio data provided through.
  • the field 1203 represents the extended header field included in the Payload field of the extended advertisement message.
  • the field includes an extended header flag of 1 octet size, an AdvA field of 6 octet size, a Target A field of 6 octet size, and an AdvDataInfo (ADI) field of 2 octet size containing data and synchronization information.
  • ADI AdvDataInfo
  • the 1204 represents an Aux Ptr field included in the extended header field of the extended advertisement message.
  • the field may include a 6-bit size channel index field, a 1-bit size CA field, a 1-bit size Offset Units field, a 13-bit size AUX Offset field, and a 3-bit size AUX PHY field.
  • the 1205 represents a Syncinfo field included in the extended header field of the extended advertisement message.
  • the field includes a 13-bit size Sync Packet Offset field, a 1-bit size Offset Unit field, a 2 Octet size Interval field, a 37-bit size ChM field, a 3-bit size SCA field, a 4-bit size AA field, and 3 octets.
  • a CRCInit field of size and an Event Counter field of 2octet size may be included.
  • the server device periodically transmits the advertisement message including the ADV_EXT_IND packet with an offset of a certain value.
  • the server device periodically transmits an advertisement message including an AUX_SYNC_IND packet for synchronization between the server device and the client device at regular intervals.
  • the server device may first transmit an advertisement message including the ADV_EXT_IND packet to inform the client device of the AUX_ADV_IND packet included in the extended advertisement message transmitted from the secondary channel.
  • the server device may transmit AUX_SYNC_IND packets and AUX_CHAIN_IND packets on the isochronous channel, and the client device may receive AUX_SYNC_IND packets and AUX_CHAIN_IND packets through which audio data related to an audio streaming service is transmitted based on the AUX_ADV_IND packets.
  • the above processes can be performed repeatedly at specific intervals.
  • FIG. 13 is a diagram illustrating an example in which audio data transmission using Bluetooth low power (BLE) is performed.
  • BLE Bluetooth low power
  • FIG. 13 describes a problem caused by not applying the method proposed herein.
  • a server device 1310 transmitting broadcast audio and a client device 1320 receiving broadcast audio are illustrated. Acceptor can be expressed as "client device.”
  • the server device may periodically transmit ADV_EXT_IND including channel information of the extended advertisement message, AUX_ADV_IND including synchronization information, and AUX_SYNC_IND packet including audio data through periodic advertising message transmission (Periodic Advertising) ( S1301, S1302).
  • the client device receives this synchronization signal while scanning advertisement messages transmitted by the server device.
  • the client device receiving the synchronization signal transmits a report that the synchronization signal has been received to the host in the link layer of the client device, and the host enables synchronization between the client device and the periodic advertisement message transmitted by the server device. ) (S1303).
  • the client device receives audio data through AUX_SYNC_IND and AUX_CHAIN_IND (S1305-S1310).
  • the client device after receiving the synchronization signal, the client device does not perform a separate filtering or the like procedure, and immediately after audible signals related to audio data are output or a device having a UI, such as a smart phone, launches the App. It is likely that the user is prompted to select audio data through a menu.
  • BLE 14 is a diagram illustrating another example in which audio data transmission using Bluetooth low power (BLE) is performed.
  • FIG. 14 describes a problem caused by not applying the method proposed in this specification.
  • the time point 1420 when the broadcast synchronization information is received by the client device is as follows.
  • the client device Since the time point at which the client device receives the synchronization information is the same as above, the client device is in a state of not receiving audio data at the time point when the synchronization information is received. Therefore, the client device only grasps information included in the synchronization information. Specifically, the client device can know the offset between the used channel map information of the secondary chaanel and Aux_sync_Indication.
  • the audio data transmitted by the server device may include Aux_sync_Indication and Aux_Chain_Indication transmitted thereafter, and may be transmitted to the client device (1430).
  • the user listens to audio data transmitted by the server device regardless of the user's will.
  • the user in order to select audio data, in the case of a device equipped with a UI such as a smartphone, the user must use the App menu. This may cause inconvenience to the user from a user eXperience (UX) perspective.
  • UX user eXperience
  • the present specification provides a method for solving a problem in which server devices are searched for more than necessary when a user discovers or connects to server servers in the vicinity when a plurality of server devices exist in the vicinity of the user, and Suggest a device for. Specifically, when a user searches for server devices around a user, a method and an apparatus for outputting a unique voice feedback set for each server device to the user are proposed.
  • broadcast audio refers to audio data transmitted through a broadcast method, which is a method in which all peripheral devices can receive audio data transmitted by a server device.
  • unique voice feedback set for each server device is output to the user, so that the user can conveniently select audio data desired to be received.
  • the user can listen to the outputted audio feedback, and select a specific device to transmit audio data desired to be received from among the plurality of devices found.
  • a user may transmit audio data that the user wants to receive through only a device that does not have a UI, such as an earphone, without manipulating a device having a user interface (UI) such as a smartphone.
  • the audio data can be received (listened) by selecting a device.
  • the server device may use a periodic advertising broadcasting method to transmit Bluetooth low power audio data to the client device.
  • the server device may periodically transmit synchronization information to synchronize the client device with the server device based on a broadcasting method.
  • Synchronization information may be broadcast through a primary advertising channel (# 37 ⁇ 39) and a secondary advertising channel (# 0 ⁇ 36).
  • the 23-byte size Aux_Ext_Indication packet can be transmitted through the primary advertisement channel.
  • the Aux_Ext_Indication packet is an Advertising ID (ADId), a channel index (number) of a secondary advertisement channel, channel map information for synchronization (Ch # _Aux_Adv), a time interval between a primary advertisement packet and a secondary channel packet (Aux_Ext_Indication) Difference offset information may be included. Packets transmitted in the primary channel may be randomly transmitted with a slight deviation to prevent collisions on the basis of advertising interval.
  • the secondary advertisement channel uses channels 0 to 36 and sends information for periodically sending isochronous audio information to a data packet of size 255 bytes.
  • the information includes an Aux_Adv_Indication packet.
  • the Aux_Adv_Indication packet may include Advertising ID (adID) and SyncInfo.
  • SyncInfo may include information for sending periodic data, channel map information for frequency hopping, and offset information with an Aux_Sync_Indication packet.
  • the actual audio data transmitted periodically may be transmitted by being included in the AdvData field of the Aux_Sync_indication packet or Aux_Chain_indication packet.
  • Method 1 A structure for searching a server device based on voice feedback from a server device and a client device (Method 1)
  • Method 2 Server device search based on voice feedback of the client device (method 2)
  • method 3 It will also be described as a method (method 3) for setting voice feedback unique to the server device.
  • 15 is a diagram illustrating an example in which the method proposed in the present specification is performed.
  • the server device is a device in charge of setting audio transmission, and may be mainly a transmission device, a smartphone, a TV, and the like.
  • the client device may be an audio transmission setting target device, and may mainly be a receiving device, a speaker, or an earphone.
  • the server device periodically transmits a BLE audio broadcast packet through the BLE Tx interface.
  • the client device receives synchronization information sent from the server device.
  • the client device determines how it can receive the audio data broadcasting. Thereafter, when the client device gives a voice feedback to the user device and acquires an input to listen to the broadcast from the user, the client device receives and decodes the audio data broadcast stream. At this time, the user's input may be pressing a button mounted on the client device, nodding his head, or the like.
  • 16 is a diagram illustrating an example in which the method proposed in the present specification is performed.
  • an example of the method proposed in the present specification is performed between one (i) server device and (ii) a user auxiliary device that assists the method to be performed between a client device and a client device.
  • scanning of the advertisement packet may be performed in the user assistance device.
  • the user assistance device may be a smartphone or the like.
  • the user assistance device receives the synchronization information from the server device, and transmits the synchronization information to the client device so that the client device can receive the broadcasting data sent from the server device.
  • the client device receiving the synchronization information from the user assistance device directly receives and decodes audio data broadcast information from the server device.
  • the client device and the user auxiliary device are connected in the same manner as the existing wireless connection method, decoding is performed on the user auxiliary device, and the user auxiliary device is connected to the client device by unicast to the client device. You can send data.
  • 17 is a diagram illustrating an example in which the method proposed in the present specification is performed.
  • FIG. 17 specifically shows a process in which the client device receives audio data transmitted by the server device.
  • the server device broadcasts an advertisement message including synchronization information (1710).
  • a server device broadcasts an advertisement message including synchronization information, information indicating that broadcasting is performed by including audio feedback information together, not only audio data in a broadcast isochronous group information (BIGInfo) containing synchronization information. And audio feedback information.
  • BIGInfo broadcast isochronous group information
  • the above information may be included in Aux_Ext_Indication or Aux_Adv_Indication.
  • the voice may include all types of audible signals that the user can hear using the hearing, such as a beep.
  • the audio feedback information is information about the type of audio data transmitted by the server device, and the client device receives the audio feedback information and voice feedback corresponding to the audio feedback information for a short interval so that a user can know the type of audio data Can output
  • the output audio feedback information may be mixed with the voice to clearly inform the user of the audio data.
  • the client device After receiving the synchronization information (1720), the client device delivers only voice feedback data to the host from among the audio data and audio feedback information. That is, since the user has not input information indicating that the audio data is received, the audio data is not transmitted to the host.
  • the client device decodes the audio feedback information and repeatedly hears it from the user (1731, 1732, 1733).
  • the user inputs information related to whether to receive the audio data when the voice feedback corresponding to the audio feedback information repeatedly sounds (1740).
  • the client device After the user performs input, if the user's input indicates that the audio data is received, the client device receives the audio data transmitted by the server device and delivers the audio data to the host (1750). Conversely, if the user does not perform a specific timeout time, the client device returns to the initial state. At this time, audio data and audio feedback information are not output.
  • the client device in order to receive the audio data, the client device must scan whether the signal strength of the server device is measured at an intensity above a certain threshold do. Measurement of the signal strength may be performed through the measurement of the Aux_Ext packet signal strength of the minimum primary channel. If the signal strength is greater than or equal to a certain threshold, the Aux_Ext packet is parsed in the Observation Procedure, and an Extended Advertising Report Event is transmitted to the host.
  • two audio data i.e., audio data and audio feedback information
  • BIG Initiatolr
  • BIS1 audio feedback information
  • BIS2 audio data.
  • audio feedback information and audio data are transmitted from one server device, they may be included in the same audio group. Accordingly, audio data and audio feedback information may be included in one BIG, but audio data and voice feedback may be included in different BISs included in the BIG, respectively, and then transmitted. More specifically, the audio feedback information included in BIS 1 can be decoded and output to the user as soon as the client device is received, but the audio data contained in BIS 2 is changed to the client after the status of the client device is changed to Broadcast Stream-Enable procedure. When the device receives the BIG, it may be output by receiving the BIS 2 included in the BIG.
  • BIS1 may include an indicator flag indicating whether audio feedback information is included in synchronization information.
  • a flag indicating whether the audio feedback information is included may be a “chime bell” flag. Based on the chime bell flag, the client device can selectively receive and decode audio data transmitted by the server device.
  • FIG. 18 is a diagram illustrating an example of transmitting a BIS included in the BIG proposed in this specification.
  • FIG. 18 shows an example of multiplexing methods when a server device includes audio feedback information and audio data in a BIG and transmits it using an advertisement message.
  • the server device may sequentially transmit BIS including audio feedback information and BIS including audio data (1810).
  • the server device may alternately transmit (1820) the BIS including the audio feedback information and the BIS including the audio data.
  • 19 is a diagram illustrating an example in which the method proposed in the present specification is performed.
  • FIG. 19 shows an example in which the server device includes audio feedback information in Aux_adv_indication and transmits it to the client device.
  • audio feedback information is included in an Aux_Adv_Indication packet in which synchronization information is used for transmission.
  • Audio feedback information is included in ADATA included in the Aux_Adv_Indication packet.
  • the remaining data of the audio feedback information may be included in the next transmitted Aux_Chain_indication packet.
  • a flag indicating that the audio feedback information is included in the Aux_Adv_Indication packet may be included in order for the client device to accurately decode the audio feedback information. Based on the flag, the client device determines that the audio feedback information is included in the Aux_Adv_Indication packet, and decodes and outputs audio feedback information included in the ADATA field of the Aux_Adv_Indication packet.
  • the received audio feedback information is for voice feedback for transmitting the type of audio data to the user in a short time
  • the time for decoding and outputting is a length of several seconds. Accordingly, voice feedback can be given to the user without a great burden on the client device for processing the Aux_Sync_Indication packet received later.
  • the status of the client device is Broadcast Streaming-Configuration procedure
  • the status is changed to Broadcast Streaming-Enable procedure status. Thereafter, audio data included in Aux_Sync_indication (and Aux_Chain_Indication thereafter) is received and decoded.
  • 20 is a diagram illustrating an example in which the method proposed in the present specification is performed.
  • FIG. 20 specifically illustrates a process in which a client device receives audio data transmitted by a plurality of server devices.
  • one client device searches for a plurality of broadcasting audio signals transmitted by multiple server devices.
  • the client device sets the audio feedback information corresponding to the received multiple audio signals to each other at different times. Intersect and tell the user.
  • the user When the user hears the voice feedback related to the audio feedback information related to the audio data desired to be listened to, the user inputs information indicating that the audio data will be listened to for the voice feedback related to the audio data desired to be listened to. Thereafter, the user can listen to the corresponding audio data.
  • the number of times the client device repeatedly outputs audio feedback information related to each audio data may be limited.
  • the number of repetitions may be limited to about 3 to 5 times, and if no information is input while the voice feedback is repeated, the voice feedback may no longer be output.
  • the client device may continuously monitor the signal strength of the advertising packet (AUX_EXT) of the primary channel.
  • AUX_EXT advertising packet
  • 21 and 22 are diagrams illustrating an example in which the method proposed in the present specification is performed.
  • the GATT client receives an advertisement packet from the GATT server (server device) (S2110), and the GATT client establishes a connection with the GATT server (S2120).
  • the GATT client sends a read request message to the server device requesting to read the status information of the audio feedback information stored in the status characteristic of the GATT server to the GATT server, and then, the GATT client A read response message including the status information is received from the server device (S2130).
  • the status information may include at least one of name information of the audio data, date information in which the audio data is stored in the first specific characteristic, or version information of the audio data.
  • the GATT client requests a write request to the GATT server to write the characteristic value associated with the changed audio feedback information to the second specific characteristic of the server device in order to change the audio feedback information based on the status information.
  • Send a message (S2140).
  • the write request message may include some of the data constituting the changed audio feedback information.
  • the GATT client may receive a write response message from the GATT server in response to the write request message.
  • the GATT client transmits the new audio feedback information to the GATT server through the data characteristic as a binary file encoded with the Bluetooth recommended codec.
  • the size of the Characteristic MTU is about 21 to 255 bytes, and the file can be difficult to transmit in one characteristic write. Therefore, it can be transmitted in a characteristic write multiple times, and for this purpose, it is transmitted by applying a sequence number to a header of each of the plurality of data constituting the audio feedback information.
  • 23 and 24 are views showing another example in which the method proposed in the present specification is performed.
  • the management server device may receive synchronization information from neighboring server devices (Broadcast Advertisers).
  • the management server device may transmit broadcast synchronization information of the neighboring server devices to other broadcast scanner devices (client devices). In this way, the burden of performing multiple scans for the client device to synchronize with multiple devices is reduced. This method can be expressed as "Scan Offloading".
  • the management server device transmits audio feedback information of all server devices at a time to the client device in advance, rather than each server device transmitting audio feedback information to the client device. , It can improve the usability of the client device.
  • the management server device may use BLE PAST (Periodic Advertising Sync Transfer) technology to deliver synchronization information of all server devices to the client device.
  • the entire synchronization information including synchronization information of all server devices that the management server device transmits to the client device may be transmitted through a separate broadcast channel for voice feedback transmission.
  • the client device receives the entire synchronization information through a separate broadcast channel from the management server (S2410).
  • the client device receives audio data from neighboring server devices based on the entire synchronization information (S2420).
  • Bluetooth bonding means a method of storing (caching) the encrypt key used for pairing between the Central (master) device and the Peripheral (slave) device, making it convenient for later connection.
  • the audio feedback information is regarded as data to be frequently used in the BLE Audio Broadcasting environment, and can be stored in advance. Even if there is only one server device, if the environment is frequently received, audio feedback information may be stored (cached) for later use.
  • 25 is a diagram illustrating an example of an operation implemented in a terminal for receiving audio data using the Bluetooth technology proposed in this specification.
  • the client device receives an advertisement message including channel information for receiving an extended advertisement message for providing an audio streaming service from a server device (S2510).
  • the client device receives the extended advertisement message from the server device including an indicator related to audio data of the audio streaming service based on the channel information (S2520).
  • the indicator indicates that the audio data and audio feedback information for identifying the audio data are grouped and transmitted.
  • the channel information may include an index of a channel through which the extended advertisement message is transmitted and / or synchronization channel information for synchronizing the client device and the server device.
  • the synchronization information may include at least one of the grouped audio data, a grouping ID associated with the audio feedback information, an audio data ID for identifying the audio data, or an audio feedback ID for identifying the audio feedback information. It can contain.
  • the client device receives the audio data and the audio feedback information from the server device through an isochronous channel (S2530).
  • the client device obtains specific information related to whether to allow the provision of the audio streaming service from the user based on the audio feedback information (S2540).
  • the audio data is decoded (S2550).
  • the client device may decode the audio feedback information and output the decoded audio feedback information.
  • the client device establishes a connection with the server device, and the server device issues a read request message requesting to read status information of the audio feedback information stored in a first characteristic of the server device.
  • the status information includes at least one of name information of the audio data, date information in which the audio data is stored in the first specific characteristic, or version information of the audio data.
  • a read response message including status information may be received.
  • the client device sends a write request message requesting to write a characteristic value associated with the changed audio feedback information to the second specific characteristic of the server device in order to change the audio feedback information based on the status information.
  • the write request message includes data of some of the data constituting the changed audio feedback information, and may receive a write response message from the server device in response to the write request message.
  • each of the write request messages may include sequence number information for some of the data.
  • the client device receives overall synchronization information related to synchronization between the plurality of server devices and the client device from a management server that manages a plurality of servers including the server device, and the total synchronization information is the plurality of servers. It may include synchronization information for each of the devices.
  • the management server may receive and store synchronization information for each of the plurality of server devices in advance.
  • Embodiments according to the present invention may be implemented by various means, for example, hardware, firmware, software, or a combination thereof.
  • one embodiment of the present invention includes one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs ( field programmable gate arrays), processors, controllers, microcontrollers, microprocessors, and the like.
  • ASICs application specific integrated circuits
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGAs field programmable gate arrays
  • processors controllers, microcontrollers, microprocessors, and the like.
  • an embodiment of the present invention may be implemented in the form of a module, procedure, function, etc. that performs the functions or operations described above.
  • the software code can be stored in memory and driven by a processor.
  • the memory is located inside or outside the processor, and can exchange data with the processor by various means already known.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Human Computer Interaction (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)

Abstract

블루투스 저전력 에너지(Bluetooth Low Energy) 기술을 이용하여 오디오 데이터를 수신하는 방법을 제공한다. 구체적으로, 블루투스 저전력 에너지(Bluetooth Low Energy) 기술을 이용하여 오디오 데이터를 수신하는 방법에 있어서, 클라이언트(Client) 디바이스에 의해 수행되는 방법은, 오디오 스트리밍 서비스(Audio Streaming Service)를 제공하기 위한 확장된 광고 메시지를 수신하기 위한 채널 정보를 포함하는 광고 메시지를 서버(Server) 디바이스로부터 수신하는 단계; 상기 채널 정보에 기초하여 상기 오디오 스트리밍 서비스의 오디오 데이터와 관련된 지시자를 포함하는 상기 확장된 광고 메시지를 상기 서버 디바이스로부터 수신하는 단계, 상기 지시자는 상기 오디오 데이터 및 상기 오디오 데이터를 식별하기 위한 오디오 피드백 정보가 그룹핑되어 전송되는 것을 나타내고; 등시 채널(isochronous channel)을 통해 상기 오디오 데이터 및 상기 오디오 피드백 정보를 상기 서버 디바이스로부터 수신하는 단계; 상기 오디오 피드백 정보에 기초하여 사용자로부터 상기 오디오 스트리밍 서비스의 제공의 허용 여부와 관련된 특정 정보를 획득하는 단계; 및 상기 특정 정보가 상기 오디오 스트리밍 서비스의 제공의 허용을 나타내는 경우, 상기 오디오 데이터를 디코딩하는 단계를 포함하는 것을 특징으로 한다.

Description

블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치
본 발명은 무선 통신시스템에서 근거리 기술인 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치에 관한 것으로써, 보다 상세하게는 블루투스 기술을 이용하여 오디오 피드백 종류에 기초하여 오디오 데이터를 수신하기 위한 방법 및 장치에 관한 것이다.
블루투스는 근거리에서 각종 디바이스들을 무선으로 연결하여 데이터를 주고 받을 수 있는 근거리 무선 기술 규격이다. 블루투스(Bluetooth) 통신을 이용하여 두 기기간 무선 통신을 수행하고자 하는 경우, 사용자(User)는 통신하고자 하는 블루투스(Bluetooth) 디바이스(Device)들을 검색(Discovery)하고 연결(Connection)을 요청하는 절차를 수행한다. 본 발명에서 디바이스는 기기, 장치를 의미할 수 있다.
이때, 사용자는 블루투스 디바이스를 이용하여 사용하고자 하는 블루투스 통신방법에 기초하여 블루투스 디바이스를 검색한 후 연결을 수행할 수 있다.
블루투스 통신방법에는 BR/EDR (Basic Rate/Enhanced Data Rate)방식과 저전력 방식인 LE (Low Energy)방식이 있다. BR/EDR 방식은 블루투스 클래식 (Bluetooth Classic)라고 호칭될 수 있다. 블루투스 클래식 방식은 베이직 레이트(Basic Rate)를 이용하는 블루투스 1.0부터 이어져온 블루투스 기술과 블루투스 2.0에서부터 지원되는 인핸스드 데이터 레이트(Enhanced Data Rate)를 이용하는 블루투스 기술을 포함한다.
블루투스 저전력 에너지(Bluetooth Low energy, 이하 블루투스 LE라고 한다.)기술은 블루투스 4.0부터 적용되어 적은 전력을 소모하여 수백 키로바이트(KB)의 정보를 안정적으로 제공할 수 있다. 이러한 블루투스 저전력 에너지 기술은 속성 프로토콜(Attribute Protocol)을 활용해서 디바이스(Device) 간 정보를 교환하게 된다. 이러한 블루투스 LE 방식은 헤더의 오버헤드(overhead)를 줄이고 동작을 간단하게 해서 에너지 소비를 줄일 수 있다.
블루투스 기기들 중에는 디스플레이(Display)나 유저인터페이스(User Interface)가 없는 제품들도 있다. 다양한 종류의 블루투스 기기들과 그 중에서도 유사기술이 적용된 블루투스 기기들 간의 연결 / 관리 / 제어 / 분리 (Connection / Management / Control / Disconnection)의 복잡도가 증가하고 있다.
또한, 블루투스는 비교적 저전력, 저비용으로 비교적 빠른 속도를 낼 수 있으나, 전송 거리가 일반적으로 최대 100m로 한정적이므로, 한정된 공간에서 사용하기 적합하다.
본 명세서는 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치를 제공함에 그 목적이 있다.
또한, 본 명세서는 복수의 디바이스들로부터 수신된 오디오 데이터와 관련된 대한 오디오 피드백 정보를 수신하기 위한 방법 및 이에 대한 장치를 제공함에 그 목적이 있다.
또한, 사용자가 오디오 피드백 정보에 기초한 음성 피드백을 청취함으로써, 오디오 데이터의 종류와 관련된 정보를 획득 하기 위한 방법 및 이에 대한 장치를 제공함에 그 목적이 있다.
또한, 사용자가 오디오 피드백 정보에 기초한 음성 피드백을 청취함으로써, 사용자가 청취하기를 희망하는 오디오 데이터만을 수신 하기 위한 방법 및 이에 대한 장치를 제공함에 그 목적이 있다.
본 명세서에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 명세서는, 블루투스 저전력 에너지(Bluetooth Low Energy) 기술을 이용하여 오디오 데이터를 수신하는 방법을 제공한다.
구체적으로, 본 명세서는, 블루투스 저전력 에너지(Bluetooth Low Energy) 기술을 이용하여 오디오 데이터를 수신하는 방법에 있어서, 클라이언트(Client) 디바이스에 의해 수행되는 방법은, 오디오 스트리밍 서비스(Audio Streaming Service)를 제공하기 위한 확장된 광고 메시지를 수신하기 위한 채널 정보를 포함하는 광고 메시지를 서버(Server) 디바이스로부터 수신하는 단계; 상기 채널 정보에 기초하여 상기 오디오 스트리밍 서비스의 오디오 데이터와 관련된 지시자를 포함하는 상기 확장된 광고 메시지를 상기 서버 디바이스로부터 수신하는 단계, 상기 지시자는 상기 오디오 데이터 및 상기 오디오 데이터를 식별하기 위한 오디오 피드백 정보가 그룹핑되어 전송되는 것을 나타내고; 등시 채널(isochronous channel)을 통해 상기 오디오 데이터 및 상기 오디오 피드백 정보를 상기 서버 디바이스로부터 수신하는 단계; 상기 오디오 피드백 정보에 기초하여 사용자로부터 상기 오디오 스트리밍 서비스의 제공의 허용 여부와 관련된 특정 정보를 획득하는 단계; 및 상기 특정 정보가 상기 오디오 스트리밍 서비스의 제공의 허용을 나타내는 경우, 상기 오디오 데이터를 디코딩하는 단계를 포함하는 것을 특징으로 한다.
또한, 본 명세서는, 상기 오디오 피드백 정보를 디코딩하는 단계; 및 상기 디코딩된 오디오 피드백 정보를 출력하는 단계를 더 포함하는 것을 특징으로 하는 단계를 더 포함하는 것을 특징으로 한다.
또한, 본 명세서는, 상기 채널 정보는 확장된 광고 메시지가 전송되는 채널의 인덱스(Index) 및/또는 상기 클라이언트 디바이스와 상기 서버 디바이스의 동기화를 위한 동기화 채널 정보를 포함하는 것을 특징으로 한다.
또한, 본 명세서는, 상기 동기화 정보는 그룹핑된 상기 오디오 데이터와 상기 오디오 피드백 정보와 관련된 그룹핑 ID(dentifier), 상기 오디오 데이터를 식별하기 위한 오디오 데이터 ID 또는 상기 오디오 피드백 정보를 식별하기 위한 오디오 피드백 ID 중 적어도 하나를 포함하는 것을 특징으로 한다.
또한, 본 명세서는, 상기 서버 디바이스와 연결을 형성하는 단계; 상기 서버 디바이스의 제 1 특정 특성(Characteristic)에 저장되어 있는 상기 오디오 피드백 정보의 상태 정보의 판독을 요청하는 판독 요청 메시지를 상기 서버 디바이스로 전송하는 단계, 상기 상태 정보는 상기 오디오 데이터의 이름 정보, 상기 오디오 데이터가 상기 제 1 특정 특성에 저장된 날짜 정보 또는 상기 오디오 데이터의 버전(Version) 정보 중 적어도 하나를 포함하고; 및 상기 서버 디바이스로부터 상기 상태 정보를 포함하는 판독 응답 메시지를 수신하는 단계를 더 포함하는 것을 특징으로 한다.
또한, 본 명세서는, 상기 상태 정보에 기초하여 상기 오디오 피드백 정보의 변경을 위해서 상기 서버 디바이스의 제 2 특정 특성에 변경된 오디오 피드백 정보와 관련된 특성 값(Characteristic value)의 기입을 요청하는 기입 요청 메시지를 상기 서버 디바이스로 전송하는 단계, 상기 기입 요청 메시지는 상기 변경된 오디오 피드백 정보를 구성하는 데이터 중 일부의 데이터를 포함하고; 및 상기 기입 요청 메시지에 대한 응답으로 기입 응답 메시지를 상기 서버 디바이스로부터 수신하는 단계를 더 포함하는 것을 특징으로 한다.
또한, 본 명세서는, 상기 기입 요청 메시지는 각각은 상기 일부의 데이터들 대한 시퀀스 번호 정보를 포함하는 것을 특징으로 한다.
또한, 본 명세서는, 상기 서버 디바이스를 포함하는 복수의 서버들을 관리 하는 관리 서버로부터 상기 복수의 서버 디바이스들과 상기 클라이언트 디바이스 간의 동기화와 관련된 전체 동기화 정보를 수신하는 단계를 더 포함하되, 상기 전체 동기화 정보는 상기 복수의 디바이스들 각각에 대한 동기화 정보를 포함하는 것을 특징으로 한다.
또한, 본 명세서는, 상기 관리 서버는 상기 복수의 서버 디바이스들 각각에 대한 동기화 정보를 미리 수신하여 저장하는 것을 포함하는 것을 특징으로 한다.
또한, 본 명세서는, 블루투스 저전력 에너지(Bluetooth Low Energy) 기술을 이용하여 오디오 데이터를 수신하는 클라이언트 디바이스에 있어서, 무선 신호를 송신하기 위한 전송기(transmitter); 무선 신호를 수신하기 위한 수신기(receiver); 및 상기 전송기 및 수신기와 기능적으로 연결되는 프로세서를 포함하고, 상기 프로세서는, 오디오 스트리밍 서비스(Audio Streaming Service)를 제공하기 위한 확장된 광고 메시지를 수신하기 위한 채널 정보를 포함하는 광고 메시지를 서버(Server) 디바이스로부터 수신하도록 상기 수신기를 제어하고, 상기 채널 정보에 기초하여 상기 오디오 스트리밍 서비스의 오디오 데이터와 관련된 지시자를 포함하는 상기 확장된 광고 메시지를 상기 서버 디바이스로부터 수신하도록 상기 수신기를 제어하고, 상기 지시자는 상기 오디오 데이터 및 상기 오디오 데이터를 식별하기 위한 오디오 피드백 정보가 그룹핑되어 전송되는 것을 나타내고, 등시 채널(isochronous channel)을 통해 상기 오디오 데이터 및 상기 오디오 피드백 정보를 상기 서버 디바이스로부터 수신하도록 상기 수신기를 제어하고, 상기 오디오 피드백 정보에 기초하여 사용자로부터 상기 오디오 스트리밍 서비스의 제공의 허용 여부와 관련된 특정 정보를 획득하고, 상기 특정 정보가 상기 오디오 스트리밍 서비스의 제공의 허용을 나타내는 경우, 상기 오디오 데이터를 디코딩하는 것을 특징으로 한다.
본 명세서는 블루투스 기술을 이용하여 오디오 데이터를 수신할 수 있는 효과가 있다.
또한, 본 명세서는 복수의 디바이스들로부터 수신된 오디오 데이터와 관련된 대한 오디오 피드백 정보를 수신 할 수 있는 효과가 있다.
또한, 사용자가 오디오 피드백 정보에 기초한 음성 피드백을 청취함으로써, 오디오 데이터의 종류와 관련된 정보를 획득 할 수 있는 효과가 있다.
또한, 사용자가 오디오 피드백 정보에 기초한 음성 피드백을 청취함으로써, 사용자가 청취하기를 희망하는 오디오 데이터만을 수신할 수 있는 효과가 있다.
본 명세서에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 명세서에서 제안하는 블루투스 저전력 에너지 기술을 이용하는 무선 통신 시스템의 일 예를 나타낸 개략도이다.
도 2는 본 명세서에서 제안하는 방법들을 구현할 수 있는 디바이스의 내부 블록도의 일 예를 나타낸다.
도 3은 본 명세서에서 제안하는 방법들이 적용될 수 있는 블루투스 통신 아키텍처(Architecture)의 일 예를 나타낸다.
도 4는 블루투스 저전력 에너지의 GATT(Generic Attribute Profile)의 구조의 일 예를 나타낸다.
도 5는 본 발명이 적용될 수 있는 블루투스 저전력 에너지 기술에서 연결 절차 방법의 일 예를 나타내는 흐름도이다.
도 6은 오디오 신호의 특성을 나타낸다.
도 7은 등시 채널이 이용될 수 있는 어플리케이션들에 대한 홈에코시스템(Home ecosystem)의 일 예를 나타낸다.
도 8은 본 발명이 적용될 수 있는 GAM(Generic Audio Middleware) 프로토콜 스택의 일 예를 나타낸다.
도 9는 클라이언트 디바이스가 필터링 없이 디바이스를 탐색하는 일 예를 나타낸 도이다.
도 10은 클라이언트 디바이스 주변에 서버 디바이스가 복수가 존재하는 경우의 문제점을 보여주는 도이다.
도 11은 서버 디바이스의 광고 메시지가 전송되는 일 예를 나타낸 도이다.
도 12 a 및 12 b는 서버 디바이스가 전송하는 광고메시지의 데이터 포맷과 광고 메시지의 전송 타이밍의 일 예를 나타낸 도이다.
도 13은 블루투스 저전력(BLE)를 사용한 오디오 데이터 전송이 수행되는 일 예를 나타낸 도이다.
도 14는 블루투스 저전력(BLE)를 사용한 오디오 데이터 전송이 수행되는 또 다른 일 예를 나타낸 도이다.
도 15는 본 명세서에서 제안하는 방법이 수행되는 일 예를 나타낸 도이다.
도 16은 본 명세서에서 제안하는 방법이 수행되는 일 예를 나타낸 도이다.
도 17은 본 명세서에서 제안하는 방법이 수행되는 일 예를 나타낸 도이다.
도 18은 본 명세서에서 제안하는 BIG에 포함되는 BIS를 전송하는 일 예를 나타낸 도이다.
도 19는 본 명세서에서 제안하는 방법이 수행되는 일 예를 나타낸 도이다.
도 20은 본 명세서에서 제안하는 방법이 수행되는 일 예를 나타낸 도이다.
도 21 및 22는 본 명세서에서 제안하는 방법이 수행되는 일 예를 나타낸 도이다.
도 23 및 도 24는 본 명세서에서 제안하는 방법이 수행되는 또 다른 일 예를 나타낸 도면이다.
도 25는 본 명세서에서 제안하는 블루투스 기술을 이용하여 오디오 데이터를 수신 위한 단말에서 구현되는 동작의 일례를 나타낸 도이다.
본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는 첨부 도면은 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 특징을 설명한다. 명세서 전체에 걸쳐서 동일한 참조번호들은 원칙적으로 동일한 구성요소들을 나타낸다. 또한, 본 발명과 관련된 공지 기능 혹은 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 첨부된 도면은 본 발명의 사상을 쉽게 이해할 수 있도록 하기 위한 것일 뿐, 첨부된 도면에 의해 본 발명의 사상이 제한되는 것으로 해석되어서는 아니 됨을 유의해야 한다.
이하, 본 발명과 관련된 방법 및 장치에 대하여 도면을 참조하여 보다 상세하게 설명한다. 또한, 본 발명에서 사용되는 일반적인 용어는 사전에 정의되어 있는 바에 따라, 또는 전후 문맥상에 따라 해석되어야 하며, 과도하게 축소된 의미로 해석되지 않아야 한다. 또한, 본 명세서에서 사용되는 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "구성된다" 또는 "포함한다" 등의 용어는 명세서 상에 기재된 여러 구성 요소들, 또는 여러 단계들을 반드시 모두 포함하는 것으로 해석되지 않아야 하며, 그 중 일부 구성 요소들 또는 일부 단계들은 포함되지 않을 수도 있고, 또는 추가적인 구성 요소 또는 단계들을 더 포함할 수 있는 것으로 해석되어야 한다. 이하의 설명에서 사용되는 구성요소에 대한 접미사 "유닛", "모듈" 및 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다. "제1", "제2" 등의 용어는 하나의 구성요소를 다른 구성요소로부터 구별하기 위한 것으로 이들 용어들에 의해 권리범위가 한정되어서는 아니 된다.
도 1은 본 명세서에서 제안하는 블루투스 저전력 에너지 기술을 이용하는 무선 통신 시스템의 일 예를 나타낸 개략도이다.
무선 통신 시스템(100)은 적어도 하나의 서버 디바이스(Server Device, 120) 및 적어도 하나의 클라이언트 디바이스(Client Device, 110)를 포함한다.
서버 장치와 클라이언트 장치는 블루투스 저전력 에너지(Bluetooth Low Energy:BLE, 이하 편의상 'BLE'로 표현한다.) 기술을 이용하여 블루투스 통신을 수행한다.
먼저, BLE 기술은 블루투스 BR/EDR(Basic Rate/Enhanced Data Rate) 기술과 비교하여, 상대적으로 작은 duty cycle을 가지며 저 가격 생산이 가능하고, 저속의 데이터 전송률을 통해 전력 소모를 크게 줄일 수 있어 코인 셀(coin cell) 배터리를 이용할 경우 1년 이상 동작이 가능하다.
또한, BLE 기술에서는 디바이스 간 연결 절차를 간소화하였으며, 패킷 사이즈도 블루투스 BR/EDR 기술에 비해 작게 설계되어 있다.
BLE 기술에서, (1) RF 채널수는 40개이며, (2) 데이터 전송 속도는 1Mbps를 지원하며, (3) 토폴로지는 스캐터넷 구조이며, (4) latency는 3ms이며, (5) 최대 전류는 15mA 이하이며, (6) 출력 전력은 10mW(10dBm) 이하이며, (7) 휴대폰, 시계, 스포츠, 헬스케어, 센서, 기기제어 등의 어플리케이션에 주로 사용된다.
상기 서버 장치(120)는 다른 장치와의 관계에서 클라이언트 장치로 동작할 수 있고, 상기 클라이언트 장치는 다른 장치와의 관계에서 서버 장치로 동작할 수 있다. 즉, BLE 통신 시스템에서 어느 하나의 장치는 서버 장치 또는 클라이언트 장치로 동작하는 것이 가능하며, 필요한 경우, 서버 장치 및 클라이언트 장치로 동시에 동작하는 것도 가능하다.
상기 서버 장치(120)는 데이터 서비스 장치(Data Service Device), 슬레이브 디바이스(slave device) 디바이스, 슬레이브(slave), 서버, 컨덕터(Conductor), 호스트 디바이스(Host Device), 게이트웨이(Gateway), 센싱 장치(Sensing Device), 모니터링 장치(monitoring device), 제 1 디바이스, 제 2 디바이스 등으로 표현될 수 있다.
상기 클라이언트 디바이스(110)는 마스터 디바이스(master device), 마스터(master), 클라이언트, 멤버(Member), 센서 디바이스, 싱크 디바이스(Sink Device), 콜렉터(Collector), 제 3 디바이스, 제 4 디바이스 등으로 표현될 수 있다.
서버 장치와 클라이언트 장치는 상기 무선 통신 시스템의 주요 구성요소에 해당하며, 상기 무선 통신 시스템은 서버 장치 및 클라이언트 장치 이외에도 다른 구성요소를 포함할 수 있다.
상기 서버 장치는 클라이언트 장치로부터 데이터를 제공 받고, 클라이언트 장치와 직접 통신을 수행함으로써, 클라이언트 장치부터 데이터 요청을 수신하는 경우, 응답을 통해 클라이언트 장치로 데이터를 제공하는 장치를 말한다.
또한, 상기 서버 장치는 클라이언트 장치로 데이터 정보를 제공하기 위해 클라이언트 장치에게 알림/통지(Notification) 메시지, 지시(Indication) 메시지를 보낸다. 또한, 상기 서버 장치는 상기 클라이언트 장치로 지시 메시지를 전송하는 경우, 상기 클라이언트로부터 상기 지시 메시지에 대응하는 확인(Confirm) 메시지를 수신한다.
또한, 상기 서버 장치는 알림, 지시, 확인 메시지들을 클라이언트 디바이스와 송수신하는 과정에서 출력부(Display Unit)을 통해서 사용자에게 데이터 정보를 제공하거나 입력부(User Input Interface)를 통해 사용자로부터 입력되는 요청을 수신할 수 있다.
또한, 상기 서버 장치는 상기 클라이언트 장치와 메시지를 송수신하는 과정에서 메모리(memory unit)로부터 데이터를 읽어 오거나 새로운 데이터를 해당 메모리에 쓸 수 있다.
또한, 하나의 서버 장치는 다수의 클라이언트 장치들과 연결될 수 있으며, 본딩(Bonding) 정보를 활용하여 클라이언트 장치들과 쉽게 재 연결(또는 접속)이 가능하다.
상기 클라이언트 장치 (120)는 서버 장치에게 데이터 정보 및 데이터 전송을 요청하는 장치를 말한다.
클라이언트 장치는 상기 서버 장치로부터 알림 메시지, 지시 메시지 등을 통해 데이터를 수신하고, 지시 메시지를 상기 서버 디바이스로부터 수신하는 경우, 상기 지시 메시지에 대한 응답으로 확인 메시지를 보낸다.
상기 클라이언트 장치도 마찬가지로 상기 서버 장치와 메시지들을 송수신하는 과정에서 출력부를 통해 사용자에게 정보를 제공하거나 입력부를 통해 사용자로부터의 입력을 수신할 수 있다.
또한, 상기 클라이언트 장치는 상기 서버 장치와 메시지를 송수신하는 과정에서 메모리로부터 데이터를 읽어 오거나 새로운 데이터를 해당 메모리에 쓸 수 있다.
상기 서버 장치 및 클라이언트 장치의 출력부, 입력부 및 메모리 등과 같은 하드웨어 구성요소에 대해서는 도 2에서 구체적으로 살펴보기로 한다.
또한, 상기 무선 통신 시스템은 블루투스 기술을 통해 개인 영역 네트워킹(Personal Area Networking:PAN)을 구성할 수 있다. 일 예로, 상기 무선 통신 시스템에서는 디바이스 간 개인적인 피코넷(private piconet)을 확립함으로써 파일, 서류 등을 신속하고 안전하게 교환할 수 있다.
도 2는 본 명세서에서 제안하는 방법들을 구현할 수 있는 디바이스의 내부 블록도의 일 예를 나타낸다.
도 2에 도시된 바와 같이, 서버 디바이스(110)는 출력부(Display Unit, 111), 입력부(User Input Interface, 112), 전력 공급부(Power Supply Unit, 113), 프로세서(Processor, 114), 메모리(Memory Unit, 115), 블루투스 인터페이스(Bluetooth Interface, 116), 다른 통신 인터페이스(Other Interface, 117) 및 통신부(또는 송수신부, 118)를 포함한다.
상기 출력부(111), 입력부(112), 전력 공급부(113), 프로세서(114), 메모리(115), 블루투스 인터페이스(116), 다른 통신 인터페이스(117) 및 통신부(118)는 본 명세서에서 제안하는 방법을 수행하기 위해 기능적으로 연결되어 있다.
또한, 클라이언트 디바이스(120)는 출력부(Display Unit, 121), 입력부(User Input Interface, 122), 전력 공급부(Power Supply Unit, 123), 프로세서(Processor, 124), 메모리(Memory Unit, 125), 블루투스 인터페이스(Bluetooth Interface, 126) 및 통신부(또는 송수신부, 127)를 포함한다.
상기 출력부(121), 입력부(122), 전력 공급부(123), 프로세서(124), 메모리(125), 블루투스 인터페이스(126), 및 통신부(127)는 본 명세서에서 제안하는 방법을 수행하기 위해 기능적으로 연결되어 있다.
상기 블루투스 인터페이스(116,126)는 블루투스 기술을 이용하여 디바이스들 간의 요청/응답, 명령, 알림, 지시/확인 메시지 등 또는 데이터 전송이 가능한 유닛(또는 모듈)을 말한다.
상기 메모리(115,125)는 다양한 종류의 디바이스에 구현되는 유닛으로서, 다양한 종류의 데이터가 저장되는 유닛을 말한다.
상기 프로세서(114,124)는 서버 디바이스(110) 또는 클라이언트 디바이스(120)의 전반적인 동작을 제어하는 모듈을 말하며, 블루투스 인터페이스 및 다른 통신 인터페이스로 메시지를 전송 요청 및 수신받은 메시지를 처리하도록 제어한다.
상기 프로세서(114,124)는 제어부, 제어 유닛(Control Unit), 컨트롤러 등으로 표현될 수 있다.
상기 프로세서(114,124)는 ASIC(application-specific integrated circuit), 다른 칩셋, 논리 회로 및/또는 데이터 처리 장치를 포함할 수 있다.
상기 프로세서(114,124)는 서버 디바이스(110)로부터 광고(Advertising) 메시지를 수신하도록 상기 통신부를 제어하며, 상기 서버 디바이스(110)로 스캔 요청(Scan Request) 메시지를 전송하고, 상기 서버 디바이스(110)로부터 상기 스캔 요청에 대한 응답으로 스캔 응답(Scan Response) 메시지를 수신하도록 상기 통신부를 제어하며, 상기 서버 디바이스(110)와 블루투스 연결 설정을 위해 상기 서버 디바이스(110)로 연결 요청(Connect Request) 메시지를 전송하도록 상기 통신부를 제어한다.
또한, 상기 프로세서(114,124)는 상기 연결 절차를 통해 블루투스 LE 커넥션(Connection)이 형성된 이후, 상기 서버 디바이스(110)로부터 속성 프로토콜을 이용하여 데이터를 읽어오거나(Read), 기록(Write)할 수 있도록 상기 통신부를 제어한다.
상기 메모리(115,125)는 ROM(read-only memory), RAM(random access memory), 플래쉬 메모리, 메모리 카드, 저장 매체 및/또는 다른 저장 장치를 포함할 수 있다.
상기 통신부(118,127)는 무선 신호를 처리하기 위한 베이스밴드 회로를 포함할 수 있다. 실시 예가 소프트웨어로 구현될 때, 상술한 기법은 상술한 기능을 수행하는 모듈(과정, 기능 등)로 구현될 수 있다. 모듈은 메모리에 저장되고, 프로세서에 의해 실행될 수 있다.
상기 메모리(115,125)는 프로세서(114,124) 내부 또는 외부에 있을 수 있고, 잘 알려진 다양한 수단으로 프로세서(114,124)와 연결될 수 있다.
상기 출력부(111,121)는 디바이스의 상태 정보 및 메시지 교환 정보 등을 화면을 통해서 사용자에게 제공하기 위한 모듈을 말한다.
상기 전력 공급부(전원 공급부, 113, 123)는 제어부의 제어 하에 외부의 전원, 내부의 전원을 인가 받아 각 구성요소들의 동작에 필요한 전원을 공급해주는 모듈을 말한다.
앞에서 살핀 것처럼, BLE 기술에서는 작은 duty cycle을 가지며, 저속의 데이터 전송률을 통해 전력 소모를 크게 줄일 수 있다.
도 3은 본 명세서에서 제안하는 방법들이 적용될 수 있는 블루투스 통신 아키텍처(Architecture)의 일 예를 나타낸다.
구체적으로, 도 3은 블루투스 LE(Low Energy)의 아키텍처의 일 예를 나타낸다.
도 3에 도시된 바와 같이, BLE 구조는 타이밍이 중요한 무선장치 인터페이스를 처리하도록 동작가능한 컨트롤러 스택(Controller stACK)과 고레벨(high level) 데이터를 처리하도록 동작가능한 호스트 스택(Host stACK)을 포함한다.
상기 Controller stack은 Controller로 호칭될 수도 있으나, 앞서 도 2에서 언급한 디바이스 내부 구성요소인 프로세서와의 혼동을 피하기 위해 이하에서는 Controller stACK으로 표현하기로 한다.
먼저, 컨트롤러 스택은 블루투스 무선장치를 포함할 수 있는 통신 모듈과, 예를 들어, 마이크로프로세서와 같은 프로세싱 디바이스를 포함할 수 있는 프로세서 모듈을 이용하여 구현될 수 있다.
호스트 스택은 프로세서 모듈 상에서 작동되는 OS의 일부로서, 또는 OS 위의 패키지(package)의 인스턴스 생성(instantiation)으로서 구현될 수 있다.
일부 사례들에서, 컨트롤러 스택 및 호스트 스택은 프로세서 모듈 내의 동일한 프로세싱 디바이스 상에서 작동 또는 실행될 수 있다.
호스트 스택은 GAP(Generic Access Profile,310), GATT based Profiles(320), GATT(Generic Attribute Profile,330), ATT(Attribute Protocol,340), SM(Security Manage,350), L2CAP(Logical Link Control and Adaptation Protocol,360)을 포함한다. 다만, 호스트 스택은 이것으로 한정되지는 않고 다양한 프로토콜들 및 프로파일들을 포함할 수 있다.
호스트 스택은 L2CAP을 사용하여 블루투스 상위에서 제공하는 다양한 프로토콜, 프로파일 등을 다중화(multiplexing)한다.
먼저, L2CAP(Logical Link Control and Adaptation Protocol,360)은 특정 프로토콜 또는 프로파일에게 데이터를 전송하기 위한 하나의 양방향 채널을 제공한다.
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,350)은 디바이스를 인증하며, 키 분배(key distribution)를 제공하기 위한 프로토콜이다.
ATT(Attribute Protocol,340)는 서버-클라이언트(Server-Client) 구조로 상대 디바이스의 데이터를 접근하기 위한 규칙을 정의한다. ATT에는 6가지의 메시지 유형(Request, Response, Command, Notification, Indication, Confirmation)이 있다.
즉, (1) 요청(Request) 및 응답(Response) 메시지: Request 메시지는 클라이언트 디바이스에서 서버 디바이스로 특정 정보를 요청하기 위한 메시지이며, Response 메시지는 Request 메시지에 대한 응답 메시지로서, 서버 디바이스에서 클라이언트 디바이스로 전송되는 메시지를 말한다.
(2)Command 메시지: 클라이언트 디바이스에서 서버 디바이스로 특정 동작의 명령을 지시하기 위해 전송하는 메시지로, 서버 디바이스는 Command 메시지에 대한 응답을 클라이언트 디바이스로 전송하지 않는다.
(3)Notification 메시지: 서버 디바이스에서 클라이언트 디바이스로 이벤트 등과 같은 통지를 위해 전송하는 메시지로, 클라이언트 디바이스는 Notification 메시지에 대한 확인 메시지를 서버 디바이스로 전송하지 않는다.
(4)Indication 및 Confirm 메시지: 서버 디바이스에서 클라이언트 디바이스로 이벤트 등과 같은 통지를 위해 전송하는 메시지로, Notification 메시지와는 달리, 클라이언트 디바이스는 Indication 메시지에 대한 확인 메시지를 서버 디바이스로 전송한다.
GAP(Generic Access Profile)는 BLE 기술을 위해 새롭게 구현된 계층으로, BLE 디바이스들 간의 통신을 위한 역할 선택, 멀티 프로파일 작동이 어떻게 일어나는지를 제어하는데 사용된다.
또한, GAP는 디바이스 발견, 연결 생성 및 보안 절차 부분에 주로 사용되며, 사용자에게 정보를 제공하는 방안을 정의하며, 하기와 같은 attribute의 type을 정의한다.
(1)Service : 데이터와 관련된 behavior의 조합으로 디바이스의 기본적인 동작을 정의
(2)Include : 서비스 사이의 관계를 정의
(3)Characteristics : 서비스에서 사용되는 data 값
(4)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,390), 링크 계층(Link Layer,380) 및 호스트 컨트롤러 인터페이스(Host Controller Interface,370)를 포함한다.
물리 계층(무선 송수신 모듈,390)은 2.4 GHz 무선 신호를 송수신하는 계층으로 GFSK (Gaussian Frequency Shift Keying) modulation과 40 개의 RF 채널로 구성된 frequency hopping 기법을 사용한다.
링크 계층(380)은 블루투스 패킷을 전송하거나 수신한다.
또한, 링크 계층은 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에서는, 스캐닝 디바이스가 일부 광고 패킷들을 광고 디바이스로부터 수신하는 경우, 상기 스캐닝 디바이스는 상기 광고 디바이스로 스캔 요청을 전송해야 한다.
하지만, 디바이스 필터링 절차가 사용되어 스캔 요청 전송이 불필요한 경우, 상기 스캐닝 디바이스는 광고 디바이스로부터 전송되는 광고 패킷들을 무시할 수 있다.
연결 요청 과정에서도 디바이스 필터링 절차가 사용될 수 있다. 만약, 연결 요청 과정에서 디바이스 필터링이 사용되는 경우, 연결 요청을 무시함으로써 상기 연결 요청에 대한 응답을 전송할 필요가 없게 된다.
광고 절차(Advertising Procedure)
광고 디바이스는 영역 내 디바이스들로 비지향성의 브로드캐스트를 수행하기 위해 광고 절차를 수행한다.
여기서, 비지향성의 브로드캐스트는 특정 방향으로의 브로드캐스트가 아닌 전(모든) 방향으로의 브로드캐스트를 말한다.
이와 달리, 지향성 브로드 캐스트는 특정 방향으로의 브로드캐스트를 말한다. 비지향성 브로드캐스트는 광고 디바이스와 리스닝(또는 청취) 상태에 있는 디바이스(이하, 리스닝 디바이스라 한다.) 간에 연결 절차 없이 발생한다.
광고 절차는 근처의 개시 디바이스와 블루투스 연결을 확립하기 위해 사용된다.
또는, 광고 절차는 광고 채널에서 리스닝을 수행하고 있는 스캐닝 디바이스들에게 사용자 데이터의 주기적인 브로드캐스트를 제공하기 위해 사용될 수 있다.
광고 절차에서 모든 광고(또는 광고 이벤트)는 광고 물리 채널을 통해 브로드캐스트된다.
광고 디바이스들은 광고 디바이스로부터 추가적인 사용자 데이터를 얻기 위해 리스닝을 수행하고 있는 리스닝 디바이스들로부터 스캔 요청을 수신할 수 있다. 광고 디바이스는 스캔 요청을 수신한 광고 물리 채널과 동일한 광고 물리 채널을 통해, 스캔 요청을 전송한 디바이스로 스캔 요청에 대한 응답을 전송한다.
광고 패킷들의 일 부분으로서 보내지는 브로드캐스트 사용자 데이터는 동적인 데이터인 반면에, 스캔 응답 데이터는 일반적으로 정적인 데이터이다.
광고 디바이스는 광고 (브로드캐스트) 물리 채널 상에서 개시 디바이스로부터 연결 요청을 수신할 수 있다. 만약, 광고 디바이스가 연결 가능한 광고 이벤트를 사용하였고, 개시 디바이스가 디바이스 필터링 절차에 의해 필터링 되지 않았다면, 광고 디바이스는 광고를 멈추고 연결 모드(connected mode)로 진입한다. 광고 디바이스는 연결 모드 이후에 다시 광고를 시작할 수 있다.
스캐닝 절차(Scanning Procedure)
스캐닝을 수행하는 디바이스 즉, 스캐닝 디바이스는 광고 물리 채널을 사용하는 광고 디바이스들로부터 사용자 데이터의 비지향성 브로드캐스트를 청취하기 위해 스캐닝 절차를 수행한다.
스캐닝 디바이스는 광고 디바이스로부터 추가적인 데이터를 요청 하기 위해, 광고 물리 채널을 통해 스캔 요청을 광고 디바이스로 전송한다. 광고 디바이스는 광고 물리 채널을 통해 스캐닝 디바이스에서 요청한 추가적인 데이터를 포함하여 상기 스캔 요청에 대한 응답인 스캔 응답을 전송한다.
상기 스캐닝 절차는 BLE 피코넷에서 다른 BLE 디바이스와 연결되는 동안 사용될 수 있다.
만약, 스캐닝 디바이스가 브로드캐스트되는 광고 이벤트를 수신하고, 연결 요청을 개시할 수 있는 개시자 모드(initiator mode)에 있는 경우, 스캐닝 디바이스는 광고 물리 채널을 통해 광고 디바이스로 연결 요청을 전송함으로써 광고 디바이스와 블루투스 연결을 시작할 수 있다.
스캐닝 디바이스가 광고 디바이스로 연결 요청을 전송하는 경우, 스캐닝 디바이스는 추가적인 브로드캐스트를 위한 개시자 모드 스캐닝을 중지하고, 연결 모드로 진입한다.
디스커버링 절차(Discovering Procedure)
블루투스 통신이 가능한 디바이스(이하, '블루투스 디바이스'라 한다.)들은 근처에 존재하는 디바이스들을 발견하기 위해 또는 주어진 영역 내에서 다른 디바이스들에 의해 발견되기 위해 광고 절차와 스캐닝 절차를 수행한다.
디스커버링 절차는 비대칭적으로 수행된다. 주위의 다른 디바이스를 찾으려고 하는 블루투스 디바이스를 디스커버링 디바이스(discovering device)라 하며, 스캔 가능한 광고 이벤트를 광고하는 디바이스들을 찾기 위해 리스닝한다. 다른 디바이스로부터 발견되어 이용 가능한 블루투스 디바이스를 디스커버러블 디바이스(discoverable device)라 하며, 적극적으로 광고 (브로드캐스트) 물리 채널을 통해 다른 디바이스가 스캔 가능하도록 광고 이벤트를 브로드캐스트한다.
디스커버링 디바이스와 디스커버러블 디바이스 모두 피코넷에서 다른 블루투스 디바이스들과 이미 연결되어 있을 수 있다.
연결 절차(Connecting Procedure)
연결 절차는 비대칭적이며, 연결 절차는 특정 블루투스 디바이스가 광고 절차를 수행하는 동안 다른 블루투스 디바이스는 스캐닝 절차를 수행할 것을 요구한다.
즉, 광고 절차가 목적이 될 수 있으며, 그 결과 단지 하나의 디바이스만 광고에 응답할 것이다. 광고 디바이스로부터 접속 가능한 광고 이벤트를 수신한 이후, 광고 (브로트캐스트) 물리 채널을 통해 광고 디바이스로 연결 요청을 전송함으로써 연결을 개시할 수 있다.
다음으로, BLE 기술에서의 동작 상태 즉, 광고 상태(Advertising State), 스캐닝 상태(Scanning State), 개시 상태(Initiating State), 연결 상태(connection state)에 대해 간략히 살펴보기로 한다.
광고 상태(Advertising State)
링크 계층(LL)은 호스트 (스택)의 지시에 의해, 광고 상태로 들어간다. 링크 계층이 광고 상태에 있을 경우, 링크 계층은 광고 이벤트들에서 광고 PDU(Packet Data Unit)들을 전송한다.
각각의 광고 이벤트는 적어도 하나의 광고 PDU들로 구성되며, 광고 PDU들은 사용되는 광고 채널 인덱스들을 통해 전송된다. 광고 이벤트는 광고 PDU가 사용되는 광고 채널 인덱스들을 통해 각각 전송되었을 경우, 종료되거나 광고 디바이스가 다른 기능 수행을 위해 공간을 확보할 필요가 있을 경우 좀 더 일찍 광고 이벤트를 종료할 수 있다.
스캐닝 상태(Scanning State)
링크 계층은 호스트 (스택)의 지시에 의해 스캐닝 상태로 들어간다. 스캐닝 상태에서, 링크 계층은 광고 채널 인덱스들을 리스닝한다.
스캐닝 상태에는 수동적 스캐닝(passive scanning), 적극적 스캐닝(active scanning)의 두 타입이 있으며, 각 스캐닝 타입은 호스트에 의해 결정된다.
스캐닝을 수행하기 위한 별도의 시간이나 광고 채널 인덱스가 정의되지는 않는다.
스캐닝 상태 동안, 링크 계층은 스캔윈도우(scanWindow) 구간(duration) 동안 광고 채널 인덱스를 리스닝한다. 스캔인터벌(scanInterval)은 두 개의 연속적인 스캔 윈도우의 시작점 사이의 간격(인터벌)으로서 정의된다.
링크 계층은 스케쥴링의 충돌이 없는 경우, 호스트에 의해 지시되는 바와 같이 스캔윈도우의 모든 스캔인터벌 완성을 위해 리스닝해야한다. 각 스캔윈도우에서, 링크 계층은 다른 광고 채널 인덱스를 스캔해야한다. 링크 계층은 사용 가능한 모든 광고 채널 인덱스들을 사용한다.
수동적인 스캐닝일 때, 링크 계층은 단지 패킷들만 수신하고, 어떤 패킷들도 전송하지 못한다.
능동적인 스캐닝일 때, 링크 계층은 광고 디바이스로 광고 PDU들과 광고 디바이스 관련 추가적인 정보를 요청할 수 있는 광고 PDU 타입에 의존하기 위해 리스닝을 수행한다.
개시 상태(Initiating State)
링크 계층은 호스트(스택)의 지시에 의해 개시 상태로 들어간다.
링크 계층이 개시 상태에 있을 때, 링크 계층은 광고 채널 인덱스들에 대한 리스닝을 수행한다.
개시 상태 동안, 링크 계층은 스캔윈도우 구간 동안 광고 채널 인덱스를 리스닝한다.
연결 상태(connection state)
링크 계층은 연결 요청을 수행하는 디바이스 즉, 개시 디바이스가 CONNECT_REQ PDU를 광고 디바이스로 전송할 때 또는 광고 디바이스가 개시 디바이스로부터 CONNECT_REQ PDU를 수신할 때 연결 상태로 들어간다.
연결 상태로 들어간 이후, 연결이 생성되는 것으로 고려된다. 다만, 연결이 연결 상태로 들어간 시점에서 확립되도록 고려될 필요는 없다. 새로 생성된 연결과 기 확립된 연결 간의 유일한 차이는 링크 계층 연결 감독 타임아웃(supervision timeout) 값뿐이다.
두 디바이스가 연결되어 있을 때, 두 디바이스들은 다른 역할로 활동한다.
마스터 역할을 수행하는 링크 계층은 마스터로 불리며, 슬레이브 역할을 수행하는 링크 계층은 슬레이브로 불린다. 마스터는 연결 이벤트의 타이밍을 조절하고, 연결 이벤트는 마스터와 슬레이브 간 동기화되는 시점을 말한다.
이하에서, 블루투스 인터페이스에서 정의되는 패킷에 대해 간략히 살펴보기로 한다. BLE 디바이스들은 하기에서 정의되는 패킷들을 사용한다.
패킷 포맷(Packet Format)
링크 계층(Link Layer)은 광고 채널 패킷과 데이터 채널 패킷 둘 다를 위해 사용되는 단지 하나의 패킷 포맷만을 가진다.
각 패킷은 프리앰블(Preamble), 접속 주소(Access Address), PDU 및 CRC 4개의 필드로 구성된다.
하나의 패킷이 광고 물리 채널에서 송신될 때, PDU는 광고 채널 PDU가 될 것이며, 하나의 패킷이 데이터 물리 채널에서 전송될 때, PDU는 데이터 채널 PDU가 될 것이다.
광고 채널 PDU(Advertising Channel PDU)
광고 채널 PDU(Packet Data Unit)는 16비트 헤더와 다양한 크기의 페이로드를 가진다.
헤더에 포함되는 광고 채널 PDU의 PDU 타입 필드는 하기 표 1에서 정의된 바와 같은 PDU 타입을 나타낸다.
Figure PCTKR2019015163-appb-img-000001
아래 광고 채널 PDU 타입들은 광고 PDU로 불리고 구체적인 이벤트에서 사용된다.
ADV_IND: 연결 가능한 비지향성 광고 이벤트
ADV_DIRECT_IND: 연결 가능한 지향성 광고 이벤트
*ADV_NONCONN_IND: 연결 가능하지 않은 비지향성 광고 이벤트
ADV_SCAN_IND: 스캔 가능한 비지향성 광고 이벤트
상기 PDU들은 광고 상태에서 링크 계층(Link Layer)에서 전송되고, 스캐닝 상태 또는 개시 상태(Initiating State)에서 링크 계층에 의해 수신된다.
스캐닝 PDU(Scanning PDU)
아래 광고 채널 PDU 타입은 스캐닝 PDU로 불리며, 하기에서 설명되는 상태에서 사용된다.
SCAN_REQ: 스캐닝 상태에서 링크 계층에 의해 전송되며, 광고 상태에서 링크 계층에 의해 수신된다.
SCAN_RSP: 광고 상태에서 링크 계층에 의해 전송되며, 스캐닝 상태에서 링크 계층에 의해 수신된다.
개시 PDU(Initiating PDU)
아래 광고 채널 PDU 타입은 개시 PDU로 불린다.
CONNECT_REQ: 개시 상태에서 링크 계층에 의해 전송되며, 광고 상태에서 링크 계층에 의해 수신된다.
데이터 채널 PDU(Data Channel PDU)
데이터 채널 PDU는 16 비트 헤더, 다양한 크기의 페이로드를 가지고, 메시지 무결점 체크(Message Integrity Check:MIC) 필드를 포함할 수 있다.
앞에서 살펴본, BLE 기술에서의 절차, 상태, 패킷 포맷 등은 본 명세서에서 제안하는 방법들을 수행하기 위해 적용될 수 있다.
도 4는 블루투스 저전력 에너지의 GATT(Generic Attribute Profile)의 구조의 일 예를 나타낸다.
도 4를 참조하면 블루투스 저전력 에너지의 프로파일 데이터(Profile Data) 교환을 위한 구조를 살펴볼 수 있다.
구체적으로, GATT(Generic Attribute Profile)는 블루투스 LE 장치 간의 서비스(Service), 특성(Characteristic)을 이용해서 데이터를 주고받는 방법을 정의한 것이다.
일반적으로, 페리페럴(Peripheral) 장치(예를 들면, 센서 장치)가 GATT 서버(Server)역할을 하며, 서비스(Service), 특성(Characteristic)에 대한 정의를 가지고 있다.
데이터를 읽거나 쓰기 위해서 GATT 클라이언트는 GATT 서버로 데이터 요청을 보내게 되며, 모든 동작(Transaction)은 GATT client에서 시작되어 GATT 서버로부터 응답을 받게 된다.
블루투스 LE에서 사용하는 GATT 기반 동작구조는 프로파일(Profile), 서비스(Service), 특성(Characteristic)에 기초하며, 상기 도 5와 같은 수직 구조를 이룰 수 있다.
상기 프로파일(Profile) 하나 또는 그 이상의 서비스들로 구성되어 있으며, 상기 서비스는 하나 이상의 특성 또는 다른 서비스들로 구성되어 있을 수 있다.
상기 서비스(Service)는 데이터를 논리적인 단위로 나누는 역할을 하며 하나 이상의 특성(Characteristic) 또는 다른 서비스들을 포함하고 있을 수 있다. 각 서비스는 UUID(Universal Unique Identifier)라 불리는 16bit 또는 128bit의 구분자를 가지고 있다.
상기 특성(Characteristic)은 GATT 기반 동작 구조에서 가장 하위 단위이다. 상기 특성은 단 하나의 데이터를 포함하며, 상기 서비스와 유사하게 16 bit 또는 128 bit의 UUID를 가지고 있다.
상기 특성은 여러 가지 정보들의 값으로 정의되고, 각각의 정보를 담기 위해서 속성(Attribute)을 하나씩 필요로 한다. 상기 특성 여러 개의 연속된 속성을 사용할 수 있다.
상기 속성(Attribute)은 네 개의 구성 요소로 이루어지며, 아래와 같은 의미를 갖는다.
- handle: 속성의 주소
- Type: 속성의 유형
- Value: 속성의 값
- Permission: 속성에 대한 접근 권한
도 5는 본 발명이 적용될 수 있는 블루투스 저전력 에너지 기술에서 연결 절차 방법의 일 예를 나타내는 흐름도이다.
서버는 클라이언트로 3개의 광고 채널을 통해 광고 메시지를 전송한다(S5010).
서버는 연결 전에는 광고자(Advertiser)로 호칭될 수 있고, 연결 이후에는 마스터(Master)로 호칭될 수 있다. 상기 서버의 일 예로, 센서(온도 센서 등)이 있을 수 있다.
또한, 클라이언트는 연결 전에는 스캐너(Scanner)로 호칭될 수 있고, 연결 이후에는 슬레이브(Slave)로 호칭될 수 있다. 클라이언트의 일 예로 스마트 폰 등이 있을 수 있다.
앞에서 살펴본 것처럼, 블루투스는 2.4GHz 밴드를 통해 총 40개의 채널로 나뉘어 통신을 한다. 40개의 채널 중 3개의 채널은 광고 채널로써, 각종 광고 패킷(Advertising Packet)을 비롯하여 연결을 맺기 위해 주고 받는 패킷들의 교환에 이용된다.
나머지 37개의 채널들은 데이터 채널로 연결 이후의 데이터 교환에 이용된다.
상기 클라이언트는 상기 광고 메시지를 수신한 후, 상기 서버로 추가적인 데이터(예: 서버 디바이스 이름 등)을 획득하기 위해 서버로 스캔 요청 메시지(Scan Request message)를 전송할 수 있다.
이 경우, 상기 서버는 상기 클라이언트로 스캔 요청 메시지(Scan Request message)에 대한 응답으로 추가적인 데이터를 포함하는 스캔 응답 메시지(Scan Response message)를 전송한다.
여기서, 스캔 요청 메시지(Scan Request message) 및 스캔 응답 메시지(Scan Response message)는 광고 패킷의 한 종료로써, 광고 패킷은 31 bytes 이하의 사용자 데이터(User Data)만을 포함할 수 있다.
따라서, 데이터의 크기가 3 bytes보다 크지만, 연결까지 맺어서 데이터를 보내기에는 오버헤드가 큰 데이터가 존재하는 경우, 스캔 요청 메시지/스캔 응답 메시지를 이용하여 두번에 걸쳐서 데이터를 나눠 보낸다.
다음, 클라이언트는 서버와 블루투스 연결 설정을 위한 연결 요청 메시지(Connection Request message)를 서버로 전송한다(S5020).
이를 통해, 서버와 클라이언트 간에 Link Layer(LL) 연결이 형성(establish)된다.
이후, 서버와 클라이언트는 보안 설립 절차를 수행한다.
보안 설립 절차는 보안 심플 페어링(Secure Simple Pairing)으로 해석되거나 이를 포함하여 수행될 수 있다.
즉, 보안 설립 절차는 페이즈(Phase) 1 단계 내지 페이즈 3 단계를 거쳐 수행될 수 있다.
구체적으로, 서버와 클라이언트 간에 페어링 절차(페이즈 1)를 수행한다(S5030).
페어링 절차는 클라이언트가 서버로 페어링 요청 메시지(Pairing Request message)를 전송하고, 서버가 클라이언트로 페어링 응답 메시지(Pairing Response message)를 전송한다.
페어링 절차를 통해서 장치간 인증 요건(authentication requirements)과 인풋/아웃풋 능력(I(Input)/O(Output) capabilities)과 키 사이즈(Key Size)정보를 주고 받는다. 이 정보를 통해 페이즈 2에서 어떤 키(Key) 생성 방법을 사용할지 결정하게 된다.
다음, 페이즈 2로서, 서버와 클라이언트 간에 레거시 페어링(Legacy pairing) 또는 보안 연결(Secure Connections)을 수행한다(S5040).
페이즈 2에서 레거시 페어링을 수행하는 128bits의 임시 키(Temporary Key) 및 쇼트 텀 키(Short Term Key(STK))를 생성한다.
- 임시 키(Temporary Key): STK를 생성하기 위해 만들어진 Key
- 쇼트 텀 키(Short Term Key(STK)): 기기간 암호화된 연결(Encrypted connection)을 만드는데 사용되는 Key 값
만약, 페이즈 2에서 보안 연결을 수행하는 경우, 128 bit의 롱 텀 키(Long Term Key(LTK))를 생성한다.
- 롱 텀 키(Long Term Key(LTK)): 기기간 암호화된 연결뿐만 아니라 추후의 연결에서도 사용되는 Key 값
다음, 페이즈 3으로서, 서버와 클라이언트 간에 키 분배(Key Distribution) 절차를 수행한다(S5050).
이를 통해, 서버와 클라이언트간에 보안 연결이 확립되고, 암호화된 링크를 형성하여 데이터를 송수신할 수 있게 된다.
등시채널(Isochronous Channel) 일반
도 6은 오디오 신호의 특성을 나타낸다.
도 6에 도시된 바와 같이, 오디오 신호(Audio Signal)의 경우, 오디오 스트리밍 데이터(Audio Streaming Data) 또는 오디오 데이터(Audio Data)가 Idle Event Interval 간격으로 주기적으로 발생하는 것을 볼 수 있다.
오디오 데이터는 그 특성에 따라 주기적으로(또는 특정 시간 간격으로) 발생한다.
여기서, 오디오 데이터가 주기적으로 발생하는 특정 시간 구간은 Idle Event Interval로 표현될 수 있다.
각 Idle Event Interval에서 각각의 오디오 데이터가 전송된다.
또한, 각 오디오 데이터는 Idle Event Interval의 전체 구간 또는 일부 구간을 통해 전송될 수 있다.
도 6과 같이, 주기적 또는 규칙적으로 발생하는 오디오 스트리밍 데이터를 BLE 메커니즘을 이용하여 전송하는 경우, 발생되는 오디오 데이터를 송수신할 때마다 광고 및 스캐닝 절차, communication 절차, Disconnection 절차 등을 수행해야 한다.
하지만, 도 6에서 살핀 것처럼, 오디오 데이터는 일반적으로 주기적으로 발생하고, 그 데이터 량에 상관없이 오디오 데이터 전송에 대한 지연 보장(Latency Guarantee)가 필수적이다.
하지만, 새롭게 발생하는 오디오 데이터를 전송할 때마다 매번 광고 및 스캐닝 절차, communication 절차, Disconnection 절차 등을 수행해야 하는 경우, 오디오 데이터 전송에 있어 지연이 발생하게 되는 문제가 있다.
보청기(Hearing Aids:HA)나 헤드셋(Headset) 등을 통한 오디오 데이터 전송은 데이터 발생량이 비교적 적기 때문에 Bluetooth BR/EDR 기술보다 BLE 기술을 활용하는 경우 높은 에너지 효율을 얻을 수 있으나, 앞서 살핀 것처럼 BLE 기술의 Data Channel Process는 매 데이터 전송마다 Advertising, Connection 등을 수행해야 하기 때문에 데이터 전송에 있어 큰 오버헤드(Large overhead)를 가지게 되며 특히, 오디오 데이터 전송에 있어 절대적으로 필요한 Latency Guarantee를 보장할 수 없게 된다.
또한, BLE 기술의 Data Channel Process는 단발적으로 발생된 데이터를 필요한 경우에만 전송하고, 다른 시간 영역에서는 BLE 디바이스의 Deep Sleep을 유도하여 에너지 효율을 높이는 데 목적이 있기 때문에, 주기적으로 발생하는 오디오 데이터의 전송에 대해 BLE 기술의 Data Channel Process를 적용하는 것은 어려울 수 있다.
이러한 이유들로 인해, 오디오 스트리밍과 같이 주기적으로 발생하는 데이터를 BLE 기술을 이용하여 송수신하기 위한 새로운 메커니즘(Mechanism)이 정의될 필요가 있다.
또한, BLE는 오디오 신호의 전송을 위한 링크 계층의 동작이 정의되어 있지 않아 오디오 신호를 전송하기 어려웠으며, 오디오 신호가 전송되더라도 사용자 디바이스(예를 들면, 헤드셋, 폰 등)가 오디오 신호를 수신하여 처리할 수 있는 장치를 찾아 타겟 디바이스까지 전송하기 위한 절차가 정의될 필요가 있다.
따라서 본 발명은 사용자의 음성으로 디바이스들을 제어하기 위해서 사용자 디바이스가 사용자의 오디오 신호를 인식하고 처리할 수 있는 디바이스들을 파악하고, 처리된 오디오 신호를 타겟 디바이스까지 전달할 수 있는 절차를 제공한다.
이하에서는, 주기적으로 발생하는 데이터(예: 오디오 데이터 또는 음성 데이터 등)를 BLE 기술을 이용하여 송수신하기 위한 방법들에 대해 구체적으로 살펴보기로 한다.
즉, BLE 기술에서 주기적으로 발생하는 데이터를 송수신하기 위한 채널을 새롭게 정의하고, 이와 관련된 메커니즘을 추가로 정의함으로써 BLE의 에너지 성능을 저해하지 않는 범위 내에서 주기적으로 발생하는 데이터를 전송하기 위한 방법을 제공한다.
본 명세서에서 사용되는 오디오 스트리밍 데이터(Audio Streaming Data), 오디오 데이터(Audio Data), 오디오 스트리밍(Audio Streaming), 오디오 스트림(Audio Stream) 등의 용어는 동일한 의미로 해석될 수 있다.
이하에서는, 이해의 편의를 위해 오디오 데이터로 통일하여 사용하기로 한다.
등시 채널(Isochronous Channel) 및 이와 관련된 메커니즘 정의
주기적으로 발생하는 데이터를 BLE 기술을 활용하여 전송하기 위해 새로운 채널 즉, 등시 채널(Isochronous Channel)을 정의한다.
등시 채널(Isochronous Channel)은 등시 스트림을 사용하는 디바이스들 간(예: Conductor-Member)에 등시 데이터(Isochronous Data)를 전송하기 위해 사용되는 채널이다.
등시 데이터(Isochronous Data)는 특정 시간 간격으로 즉, 주기적 또는 규칙적으로 전송되는 데이터를 말한다.
즉, 등시 채널(Isochronous Channel)은 BLE 기술에서 오디오 데이터 또는 음성 데이터와 같이 주기적으로 발생하는 데이터가 송수신되는 채널을 나타낼 수 있다.
상기 등시 채널은 단일의 멤버, 하나 이상의 협력된(coordinated) 멤버들의 셋 또는 다수의 멤버들로 오디오 데이터를 송수신하기 위해 사용될 수 있다.
또한, 상기 등시 채널은 오디오 스트리밍과 같은 등시 스트림(Isochronous Stream) 또는 다른 시간 영역에서 중요 데이터를 송수신하기 위해 사용될 수 있는 플러싱(flushing) 채널에 해당한다.
이하에서 살펴볼 등시 채널을 이용한 방법들은 기존 (v4.2 이하) BLE 기술에서 사용되는 Advertising Channel 및 Data Channel과 독립적으로 운영된다.
또한, 본 명세서에서는 등시 채널(Isochronous Channel)을 위한 새로운 주파수 채널(Frequency Channel) 및 주파수 호핑 간격(Frequency Hopping Interval)이 추가적으로 정의될 수 있다.
상기 등시 채널은 flushable data(e.g. time-bound audio data)와 같은 등시 스트림의 전송이 컨덕터(conductor)에서 하나 또는 하나 이상의 멤버(member)들로 BLE를 사용하여 전송되는 것을 가능하게 한다.
여기서, conductor는 master로, member는 slave로도 표현될 수 있다.
또한, 등시 채널은 보안이 설정되거나 또는 보안이 설정되지 않을 수 있다.
또한, 등시 채널은 단일의 컨덕터와 멤버 사이, 단일의 컨덕터와 hearing aids 또는 stereo headsets과 같이 스테레오 오디오를 만드는 coordinated pair of members 사이, 단일의 컨덕터와 동일한 등시 스트림(들)로 동기화되어 있는 다수의 멤버들 사이에서 등시 스트림의 전송을 허락하기 위해 다양한 토폴로지들에서 셋업(set up)될 수 있다.
여기서, 멤버는 동일한 등시 채널을 통해 컨덕터로 데이터를 전송할 수 있다.
또한, 등시 채널은 personal audio를 지원할 뿐만 아니라 shared audio, public audio 및 broadcast audio의 송수신을 지원할 수도 있다.
등시 채널의 셋업(setup) 절차는 hierarchy of profile level security와 reliability requirements이 서로 다른 use cases들을 만족시킬 것을 요구한다.
또한, 등시 채널은 다양한 어플리케이션들을 위해 사용될 수 있으며, 그로 인해 다수의 소스 디바이스들 및 싱크들이 구성될 수 있으며, 사용자들이 규칙적으로 서로 다른 오디오 스트림들을 변경 또는 공유하도록 하기 위한 복잡한 토폴로지들이 구성될 수도 있다.
도 7은 등시 채널이 이용될 수 있는 어플리케이션들에 대한 홈에코시스템(Home ecosystem)의 일 예를 나타낸다.
즉, 도 7은 본 명세서에서 제안하는 방법들이 적용될 수 있는 다수의 오디오 컨덕터들 및 멤버들이 서로의 영역 안/밖에서 움직일 수 있는 공간의 일 예를 나타낸다.
도 7에 도시된 바와 같이, 다양한 컨덕터들과 멤버들의 존재는 멤버가 등시 채널을 설정하기 위해 필요한 정보를 획득할 수 있도록 멤버의 존재를 알리기 위한 방법으로서 등시 채널이 필요하다는 것을 의미할 수 있다.
등시 채널은 또한 비 오디오 데이터(non audio data)의 송수신을 위해서도 사용될 수 있다.
멤버는 BLE 통신 범위 내에 있는 컨덕터들로부터 획득 정보를 포함할 수 있는 통지 메시지들이 존재하는지 여부를 결정하기 위해 등시 채널들을 사용할 수도 있다.
또한, 멤버는 리모트 컨트롤러처럼 행동하는 하나 또는 하나 이상의 디바이스들로부터 제어 정보 또는 서비스 데이터에 대한 요청을 수신하기 위해 등시 채널들을 사용할 수도 있다.
도 8은 본 발명이 적용될 수 있는 GAM(Generic Audio Middleware) 프로토콜 스택의 일 예를 나타낸다.
오디오 미들웨어 계층(Audio Middleware Layer)을 포함하고 있는 오디오 아키텍쳐는 BLE를 이용하여 유니 캐스트 및 브로드 캐스트 오디오를 지원할 수 있다.
오디오 미들웨어 계층은 오디오 응용 프로그램의 연결 간의 전이(transition)를 쉽게 해주며, 더욱 발전된 사용자 케이스를 개발할 수 있다.
도 8에 도시된 바와 같이, 모든 오디오 프로파일에 액세스 할 수 있는 오디오 미들웨어 계층을 추가함으로써, GAM은 동적 및 다중 프로필 환경에서도 원활한 오디오 서비스를 사용자에게 제공할 수 있다. 미들웨어는 다양한 사용자 케이스의 오디오 믹싱과 사용자 케이스간의 전환을 처리할 수 있기 때문에 각 프로파일은 특정 기능에 집중할 수 있다.
GAM은 여러 개의 프로파일을 지원할 수 있기 때문에 사용자는 오디오 콘텐츠 범위와 음성 작동 디바이스들 간에 원활이 이동할 수 있는 응용 프로그램을 선택할 수 있다.
GAM은 오디오 스트리밍을 위한 공고(Announcements), 오디오 제어 및 데이터 전송을 위한 신호 전송을 정의한다. 응용 계층은 응용 시그널링과 필요한 전송 매개 변수를 정의한다.
사용자 주변에 다수의 디바이스가 존재하는 경우에서, 사용자가 디바이스를 사용하여 특정 디바이스가 전송하는 특정 오디오 데이터를 오디오 스트리밍 서비스(Audio streaming service)를 통하여 수신하고자 하는 경우, 사용자의 디바이스는 주변의 디바이스로부터 동기화 정보(sync정보)를 수신한 후, 별도의 필터링(filtering) 과정 없이 오디오 데이터를 청취한다. 또는, 스마트폰 등 UI가 존재하는 디바이스의 경우, UI를 사용하여 검색된 다수의 디바이스들 중 사용자가 수신하기를 희망하는 오디오 데이터를 전송하는 특정 디바이스를 직접 선택해야 한다. 따라서, 필터링 없이 즉각적으로 오디오 데이터를 청취하는 경우, 사용자가 희망하지 않는 오디오 데이터를 청취하게 되는 불편함 있다. 또한, 사용자가 디바이스테 탑재된 UI를 사용하는 경우는, 사용자가 오디오 데이터 청취를 위해 별도의 조작을 수행해야 하는 불편함이 있다.
특히, 클라이언트 디바이스 주변에 오디오 데이터를 전송하는 디바이스가 한 대만 있는 경우에서는 위와 같은 불편함이 크지 않을 수 있으나, 주변에 복수의 오디오 데이터를 전송하는 디바이스가 존재하는 경우에는, 사용자의 디바이스가 복수의 디바이스 중 어떤 디바이스와 동기화 되었는지 확인하기 어렵다.
즉, 사용자의 주변에 다수의 디바이스들이 존재하는 경우, 무선 통신 기술들을 사용하여 사용자 주변의 디바이스들을 탐색(Discovery)하거나 연결을 형성할 때, 필요 이상의 디바이스들이 검색 될 수 있다.
이하에서, 오디오 데이터를 전송하는 디바이스는 서버(Server), 서버 디바이스 또는 개시자(Initiator) 등으로 표현될 수 있다.
또한, 오디오 데이터를 수신하는 사용자의 디바이스는 클라이언트(Client), 클라이언트 디바이스 및 억셉터(Acceptor) 등으로 표현될 수 있다.
도 9는 클라이언트 디바이스가 필터링 없이 디바이스를 탐색하는 일 예를 나타낸 도이다.
도 9(a)는 서버 디바이스에서 수행되는 동작의 흐름도를 도시한다.
먼저, 서버 디바이스는 주변 디바이스로 동기화 정보를 전송한다(S911).
다음, 서버 디바이스는 오디오 데이터를 주변 디바이스로 전송한다(S912).
여기서, 서버 디바이스는 브로드캐스트 방식을 통하여 주변 디바이스로 동기화 정보 및 오디오 데이터를 전송할 수 있다. 또한, 서버 디바이스는 상기 S911 내지 S912 동작을 주기적으로 반복하여 수행할 수 있다.
도 9(b)는 UI가 없는 클라이언트 디바이스에서 수행되는 동작의 흐름도를 도시한다.
먼저, 클라이언트 디바이스는 서버 디바이스를 전송하는 디바이스로부터 동기화 정보를 수신한다(S921).
다음, 클라이언트 디바이스는 서버 디바이스로부터 오디오 데이터를 수신한다(S922).
이 때, 클라이언트 디바이스는 수신한 오디오 데이터를 필터링 없이 수신하게 된다.
도 9(c)는 UI를 탑재한 클라이언트 디바이스에서 수행되는 동작의 흐름도를 도시한다.
먼저, 클라이언트 디바이스는 서버 디바이스로부터 동기화 정보를 수신한다(S931).
다음, 사용자는 사용자 UI를 통하여 필터링 없이 수신된 오디오 데이터의 수신 여부를 선택할 수 있다(S932). 이 때, 클라이언트 디바이스의 주변에 서버 디바이스가 복수 개가 존재한다면, 클라이언트 디바이스의 디스플레이 상에 오디오 데이터를 전송하는 복수의 디바이스가 검색될 수 있다.
다음, 클라이언트 디바이스는 서버 디바이스로부터 오디오 데이터를 수신한다(S933).
도 10은 클라이언트 디바이스 주변에 서버 디바이스가 복수가 존재하는 경우의 문제점을 보여주는 도이다.
도 10과 같이, 클라이언트 디바이스 주변에 서버 디바이스가 복수 개 존재하는 경우, 사용자 주변의 모든 디바이스들이 검색된다.
특히, 스마트폰 등의 클라이언트 디바이스를 통하여 주변의 디바이스들을 검색하는 경우, 클라이언트 디바이스의 디스플레이 상에 나타낼 수 있는 디바이스의 개수를 초과할 수 있다. 또한, 클라이언트 디바이스는 검색된 디바이스의 이름을 사용자에게 보여주게 되는데, 이러한 방식을 통해서는 사용자가 수신하기를 희망하는 오디오 데이터를 전송하는 특정한 디바이스를 정확하게 찾아내기 어렵게 한다.
도 11은 서버 디바이스의 광고 메시지가 전송되는 일 예를 나타낸 도이다.
서버 디바이스는 프라이머리(Primary) 채널을 통하여 Aux_Ext_indication 패킷을 포함하는 광고 메시지를 전송한다(1101). 상기 광고 메시지에는 확장된 광고 메시지(Extended Advertising message)가 전송되는 채널 정보가 포함될 수 있다.
서버 디바이스는 세컨더리(Secondary) 채널을 통하여 확장된 광고 메시지를 전송한다(1102). 클라이언트 디바이스는 상기 채널 정보에 기초하여 확장된 광고 메시지를 수신할 수 있다. 확장된 광고 메시지는 동기화 정보 등을 포함할 수 있다.
다음, 서버 디바이스는 등시 채널을 통하여 오디오 데이터 스트리밍 서비스를 제공하기 위한 오디오 데이터를 전송한다(1103). 오디오 데이터는 Aux_Sync_indication 패킷 또는 Aux_Chain_Indication 패킷에 포함되어 전송될 수 있다.
도 12a 및 12b는 서버 디바이스가 전송하는 광고메시지의 데이터 포맷과 광고 메시지의 전송 타이밍의 일 예를 나타낸 도이다.
도 12 a 및 b에 도시된 바와 같이, 광고 채널 PDU(1201)는 16 비트(bits)크기의 헤더 필드와 1-255 octets 크기만큼의 페이로드(Payload) 필드를 포함할 수 있다.
1202는 확장된 광고 메시지에 포함된 페이로드 필드를 나타낸다. 상기 필드는 6 비트 크기의 확장된 헤더 길이 필드(Extended Header Length), 광고메시지가 전송되는 모드(Mode)를 나타내는 2 비트 크기의 AdvMode 필드, 0-63 octet크기를 갖는 Extended header 필드 및 오디오 스트리밍 서비스를 통하여 제공되는 오디오 데이터가 포함되는 0-254 octet 크기를 갖는 AdvData 필드를 포함할 수 있다.
1203은 확장된 광고 메시지의 Payload 필드에 포함된 extended header 필드를 나타낸다. 상기 필드는 1 octet 크기의 확장된 헤드 플래그(Extended Header Flag), 6 octet 크기의 AdvA 필드, 6 octet 크기의 Target A 필드, 데이터와 관련된 정보를 포함하는 2 octet 크기의 AdvDataInfo(ADI) 필드, 동기화 정보를 포함하는 18 octet 크기의 Syncinfo 필드, 전송 전력을 나타내는 1 octet 크기의 TxPower 필드 및 오디오 데이터를 포함하는 다양한 크기를 갖는 ACAD 필드를 포함한다,
1204는 확장된 광고 메시지의 extended header 필드에 포함된 Aux Ptr 필드를 나타낸다. 상기 필드는 6비트 크기의 채널 인덱스 필드, 1비트 크기의 CA 필드, 1비트 크기의 Offset Units 필드, 13비트 크기의 AUX Offset 필드 및 3비트 크기의 AUX PHY 필드를 포함할 수 있다.
1205는 확장된 광고 메시지의 extended header 필드에 포함된 Syncinfo필드를 나타낸다. 상기 필드는 13비트 크기의 Sync Packet Offset 필드, 1비트 크기의 Offset Unit 필드, 2 Octet 크기의 Interval 필드, 37비트 크기의 ChM 필드, 3비트 크기의 SCA 필드, 4비트 크기의 AA필드, 3 octet 크기의 CRCInit 필드 및 2octet 크기의 Event Counter필드를 포함할 수 있다.
도 12 a 및 12 b의 1206을 참조하면, 서버 디바이스는 ADV_EXT_IND 패킷을 포함하는 광고 메시지를 주기적으로 일정 값의 오프셋을 두어 전송하는 것을 알 수 있다.
1207을 참조하면, 서버 디바이스는 서버 디바이스와 클라이언트 디바이스 간의 동기화를 위한 AUX_SYNC_IND 패킷을 포함하는 광고 메시지를 주기적으로 일정 값의 간격(Interval)을 두어 전송하는 것을 알 수 있다.
1208을 참조하면, 서버 디바이스는 가장 먼저 ADV_EXT_IND 패킷을 포함하는 광고 메시지를 전송하여, 세컨더리 채널에서 전송되는 확장된 광고 메시지에 포함되는 AUX_ADV_IND 패킷에 대한 정보를 클라이언트 디바이스에게 알릴 수 있다. 또한, 서버 디바이스는 등시 채널 상으로 AUX_SYNC_IND 패킷, AUX_CHAIN_IND 패킷들을 전송하고, 클라이언트 디바이스는 AUX_ADV_IND 패킷에 기초하여 오디오 스트리밍 서비스와 관련된 오디오 데이터가 전송되는 AUX_SYNC_IND 패킷, AUX_CHAIN_IND 패킷들을 수신할 수 있다. 위의 과정들은 특정한 간격을 두고 주기적으로 반복되어 수행될 수 있다.
도 13은 블루투스 저전력(BLE)를 사용한 오디오 데이터 전송이 수행되는 일 예를 나타낸 도이다.
구체적으로, 도 13은 본 명세서에서 제안하는 방법이 적용되지 않음으로써 발생하는 문제점을 설명한다.
도 13에서 브로드캐스트 오디오를 전송하는 서버 디바이스(1310)와, 브로드캐스트 오디오를 수신하는 클라이언트 디바이스(1320)이 도시되어 있다. Acceptor는 "클라이언트 디바이스"로 표현될 수 있다.
서버 디바이스는 주기적인 광고메시지 전송(Periodic Advertising)을 통해 확장된 광고메시지의 채널 정보 등을 포함하는 ADV_EXT_IND, 동기화 정보 등을 포함하는 AUX_ADV_IND, 오디오 데이터 등을 포함하는 AUX_SYNC_IND 패킷을 주기적으로 전송할 수 있다(S1301, S1302).
클라이언트 디바이스는 서버 디바이스가 전송하는 광고 메시지들을 스캔(Scan) 하면서 이 동기화 신호를 수신한다.
동기화 신호를 수신한 클라이언트 디바이스는 클라이언트 디바이스의 Link layer에서 동기화 신호를 수신했다는 보고(report)를 Host에 전달하고, Host는 서버 디바이스가 전송하는 주기적인 광고 메시지와 클라이언트 디바이스간의 동기화를 인에이블(enable) 시킨다(S1303).
이후 클라이언트 디바이스는 오디오 데이터를 AUX_SYNC_IND, AUX_CHAIN_IND를 통해 수신한다(S1305-S1310).
도 13에서는, 클라이언트 디바이스는 동기화 신호를 수신한 후, 별도의 필터링 등의 절차를 수행하지 않고, 곧바로 오디오 데이터와 관련된 청각적 신호가 출력되거나 스마트 폰 등과 같이 UI가 있는 디바이스에는, App을 띄운 후 메뉴를 통해 사용자에게 오디오 데이터를 선택하도록 할 가능성이 높다.
도 14는 블루투스 저전력(BLE)를 사용한 오디오 데이터 전송이 수행되는 또 다른 일 예를 나타낸 도이다.
구체적으로, 도 14는 본 명세서에서 제안하는 방법이 적용되지 않음으로써 발생하는 문제점을 설명한다.
서버 디바이스(1410)에서 BLE 오디오 데이터를 브로드캐스팅하는 경우, 브로드캐스팅 동기화 정보가 클라이언트 디바이스에 수신된 시점(1420)은 다음과 같다.
1. Primary channel의 Aux_Ext_Indication 수신
2. Secondary channel의 Aux_Adv_Indication 수신
클라이언트 디바이스가 동기화 정보를 수신한 시점이 위와 같기 때문에, 동기화 정보를 수신한 시점에서 클라이언트 디바이스는 오디오 데이터는 수신하지 않는 상태가 된다. 그러므로, 클라이언트 디바이스는 동기화 정보에 포함된 정보들만 파악하게 된다. 구체적으로, 클라이언트 디바이스는 Secondary chaanel의 used channel map 정보와 Aux_sync_Indication과의 오프셋(offset)을 알 수 있다.
서버 디바이스가 전송하는 오디오 데이터는 Aux_sync_Indication과 그 뒤에 전송되는 Aux_Chain_Indication포함되어 클라이언트 디바이스에게 전송될 수 있다(1430). 이 경우, 사용자는 서버 디바이스가 전송하는 오디오 데이터를 사용자 의지와 무관하게 듣게 된다. 또는, 오디오 데이터를 선택하기 위해, 스마트폰 등의 UI가 탑재된 디바이스의 경우, 사용자는 App 메뉴를 사용해야 한다. 이는 UX(User eXperience)관점에서 사용자에게 불편을 초래할 수 있다.
본 명세서는 사용자의 주변에 다수의 서버 디바이스들이 존재하는 상황에서, 사용자가 주변의 서버 디바이스들을 탐색(Discovery)하거나 연결을 형성할 때, 필요 이상의 서버 디바이스들이 검색 되는 문제점을 해결하기 위한 방법 및 이에 대한 장치를 제안한다. 구체적으로, 사용자가 사용자 주변의 서버 디바이스들을 탐색 할 때, 각 서버 디바이스 별로 설정되는 고유한 음성 피드백을 사용자에게 출력하도록 하는 방법 및 이에 대한 장치를 제안한다.
본 명세서에서 제공되는 방법을 통해 사용자가 사용자 주변에 오디오 스트리밍 서비스를 제공하는 다수의 서버 디바이스가 존재하는 경우, 사용자의 주변 디바이스 검색이 효율적으로 수행될 수 있는 효과가 있다.
또한, 블루투스 저전력(Bluetooth Low Energy: BLE) 기술을 사용하는 서버 디바이스가 브로드캐스트 오디오(Broadcast audio)를 전송 할 때 오디오 데이터를 송신하는 디바이스(서버 디바이스)가 한 대 설치되어 있는 경우, 서버 디바이스에 동기화 된 후, 음성 피드백 정보에 기초하여 음성 피드백(또는 chime bell)을 사용자에게 출력하여 사용자의 UX(User eXperience)를 향상할 수 있는 효과가 있다. 여기서, 브로드캐스트 오디오는 서버 디바이스가 전송한 오디오 데이터를 주변 디바이스들이 모두 수신할 수 있는 방식인 브로드캐스트 방식을 통하여 전송되는 오디오 데이터를 의미한다.
또한, 서버 디바이스가 복수 대 존재하는 경우, 서버 디바이스 별로 설정된 고유의 음성 피드백이 사용자에게 각각 출력되어, 사용자가 편리하게 수신을 희망하는 오디오 데이터를 선택할 수 있다. 특히, 사용자는 출력된 오디오 피드백을 청취하여, 검색된 다수의 디바이스 중 수신을 희망하는 오디오 데이터를 송신하는 특정 디바이스를 선택할 수 있다. 구체적으로, 사용자는 스마트폰 등의 사용자 인터페이스(User Interface: UI)가 존재하는 디바이스를 조작하지 않고도, 이어폰 등의 UI가 존재하지 않는 디바이스만을 통하여 사용자가 수신하기를 희망하는 오디오 데이터를 송신하는 특정 디바이스를 선택하여 오디오 데이터를 수신(청취)할 수 있다.
본 명세서에서, 서버 디바이스는 클라이언트 디바이스로 블루투스 저전력 오디오 데이터를 전송하기 위해서 주기적인 광고 브로드캐스팅(Periodic Advertising Broadcasting) 방법을 사용할 수 있다.
서버 디바이스는 클라이언트 디바이스를 서버 디바이스와 동기화 시키기 위한 동기화 정보를 주변으로 브로드캐스팅 방법에 기초하여 주기적으로 전송할 수 있다.
동기화 정보는 프라이머리 광고(Primary Advertising) 채널(37~39번)과 세컨더리 광고(Secondary Advertising) 채널(0~36번)을 통하여 브로드캐스팅 될 수 있다. 이 때, 23byte 크기의 Aux_Ext_Indication 패킷은 프라이머리 광고 채널을 통하여 전송될 수 있다. 상기 Aux_Ext_Indication 패킷은 Advertising ID(ADId), 세컨더리 광고 채널의 채널 인덱스(번호)(channel number), 동기화를 위한 채널 맵 정보(Ch#_Aux_Adv), 프라이머리 광고 패킷과 세컨더리 채널 패킷(Aux_Ext_Indication)간의 시간간격 차이인 오프셋 정보를 포함할 수 있다. 프라이머리 채널에서 전송되는 패킷은 광고 간격(Advertising Interval)기준으로 충돌방지를 위해 약간의 편차를 두어 랜덤(random)하게 전송될 수 있다.
세컨더리 광고 채널은 0~36번 채널을 이용하고, 255byte 크기의 데이터 패킷에 등시 오디오(isochronous audio) 정보를 주기적으로 보내기 위한 정보를 보낸다. 상기 정보에는 Aux_Adv_Indication 패킷이 포함된다. Aux_Adv_Indication 패킷에는 Advertising ID(adID), SyncInfo가 포함될 수 있다. SyncInfo는 주기적인 데이터를 보내기 위한 정보, 주파수 호핑(Frequency Hopping)을 위한 채널맵 정보, Aux_Sync_Indication 패킷과의 Offset 정보가 포함될 수 있다. 주기적으로 전송되는 실제 오디오 데이터는 Aux_Sync_indication 패킷 또는 Aux_Chain_indication 패킷의 AdvData 필드에 포함시켜 전송될 수 있다.
이하에서, 본 명세서에서 제안하는 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치에 대하여 (1) 서버 디바이스와 클라이언트 디바이스에서의 음성 피드백에 기초한 서버 디바이스 검색을 위한 구조(방법 1) (2) 클라이언트 디바이스의 음성 피드백에 기초한 서버 디바이스 검색(방법 2) (3)서버 디바이스에 고유한 음성 피드백을 설정하는 방법(방법 3)로 설명하기도 한다.
서버 디바이스와 클라이언트 디바이스에서의 음성 피드백에 기초한 디바이스 검색을 위한 구조
도 15는 본 명세서에서 제안하는 방법이 수행되는 일 예를 나타낸 도이다.
구체적으로, 본 명세서에서 제안하는 방법이 한 대의 서버 디바이스와 클라이언트 디바이스 사이에서 수행되는 일 예를 도시한다. 서버 디바이스는 오디오 전송 설정을 담당하는 디바이스이며, 주로 전송 디바이스, 스마트폰, TV 등일 수 있다. 클라이언트 디바이스는 오디오 전송 설정 대상 디바이스 일 수 있으며, 주로 수신 디바이스, 스피커, 또는 이어폰(Earbud)일 수 있다.
서버 디바이스는 BLE Tx 인터페이스를 통해 BLE 오디오 브로드캐스트 패킷을 주기적으로 전송한다. 클라이언트 디바이스는 서버 디바이스에서 보내는 동기화 정보를 수신한다.
다음, 클라이언트 디바이스는 오디오 데이터 브로드캐스팅을 수신할 수 있는 방법을 결정한다. 이후, 클라이언트 디바이스는 사용자 디비아스에게 음성 피드백을 들려주고, 사용자로부터 브로드캐스팅을 청취하겠다는 입력을 획득하게 되면 하면, 오디오 데이터 브로드캐스트 스트림을 수신하여 디코딩한다. 이 때, 사용자의 입력은 클라이언트 디바이스에 탑재된 버튼을 누르거나, 고개를 끄덕이는 것 등일 수 있다.
도 16는 본 명세서에서 제안하는 방법이 수행되는 일 예를 나타낸 도이다.
구체적으로, 본 명세서에서 제안하는 방법이 한 대의 (i)서버 디바이스와 (ii)클라이언트 디바이스 및 클라이언트 디바이스 사이에서 본 방법이 수행되도록 보조하는 사용자 보조 디바이스 사이에서 수행되는 일 예를 도시한다.
도 16에 따르면, 클라이언트 디바이스의 시그널링 오버헤드를 감소시키기 위해서, 광고 패킷의 스캐닝을 사용자 보조 디바이스에서 할 수 있다. 사용자 보조 디바이스는 스마트폰 등일 수 있다.
사용자 보조 디바이스는 동기화 정보를 서버 디바이스로부터 수신하고, 서버 디바이스에서 보내는 브로드캐스팅 데이터를 클라이언트 디바이스에서 수신할 수 있도록 동기화 정보를 클라이언트 디바이스로 전송한다.
사용자 보조 디바이스로부터 동기화 정보를 수신한 클라이언트 디바이스는, 서버 디바이스로부터 오디오 데이터 브로드캐스드 정보를 직접 수신하고, 디코딩한다.
또 다른 일 예로, 클라이언트 디바이스와 사용자 보조 디바이스는 기존 무선 연결방식과 동일하게 연결하여, 디코딩을 사용자 보조 디바이스에서 하고, 디바이스로 사용자 보조 디바이스는 클라이언트 디바이스와 유니캐스트(Unicast)로 연결하여 클라이언트 디바이스로 데이터를 보낼 수 있다.
클라이언트 디바이스의 음성 피드백에 기초한 서버 디바이스 검색
도 17은 본 명세서에서 제안하는 방법이 수행되는 일 예를 나타낸 도이다.
구체적으로, 도 17은 서버 디바이스가 전송하는 오디오 데이터를 클라이언트 디바이스가 수신하는 과정을 구체적으로 나타낸다.
서버 디바이스는 동기화 정보를 포함하는 광고메시지를 브로드캐스트 한다(1710). 서버 디바이스는 동기화 정보를 포함하는 광고메시지를 브로드캐스트 할 때, 동기화 정보가 포함되는 BIGInfo(Broadcast Isochronous Group Information)에 오디오 데이터만을 포함시키는 것이 아니라, 오디오 피드백 정보를 함께 포함시켜 브로드캐스팅 함을 나타내는 정보를 및 오디오 피드백 정보를 포함시킬 수 있다. 위의 정보들은 Aux_Ext_Indication 또는 Aux_Adv_Indication 에 포함될 수 있다. 여기서 음성은 신호음 등 사용자가 청각을 이용해서 들을 수 있는 모든 형태의 청각적 신호를 포함할 수 있다.
오디오 피드백 정보는 서버 디바이스가 전송하는 오디오 데이터의 종류에 관한 정보이며, 클라이언트 디바이스는 상기 오디오 피드백 정보를 수신하여 사용자가 오디오 데이터의 종류를 알 수 있도록 짧은 간격 동안 상기 오디오 피드백 정보에 대응하는 음성 피드백을 출력할 수 있다. 또한, 출력되는 오디오 피드백 정보는 사용자에게 오디오 데이터의 정보를 명확히 알려주기 위해 음성이 믹스(mix)될 수 있다.
클라이언트 디바이스는 동기화 정보를 수신한 후(1720), 오디오 데이터 및 오디오 피드백 정보 중에서 음성 피드백 데이터만 호스트(Host)로 전달한다. 즉, 사용자가 오디오 데이터를 수신함을 나타내는 정보를 입력을 하지 않았으므로, 오디오 데이터는 호스트로 전달되지 않는다.
클라이언트 디바이스는 오디오 피드백 정보를 디코딩하여 사용자에게 반복적으로 들려준다(1731, 1732, 1733). 사용자는 오디오 피드백 정보에 대응하는 음성 피드백이 반복해서 울릴 때 상기 오디오 데이터를 수신할 지 여부와 관련된 정보를 입력한다(1740).
사용자가 입력을 수행한 후, 사용자의 입력이 상기 오디오 데이터를 수신함을 나타내는 경우, 클라이언트 디바이스는 서버 디바이스가 전송하는 오디오 데이터를 수신하고, 호스트에 상기 오디오 데이터를 전달한다(1750). 반대로, 만일 특정 Timeout 시간 사용자가 입력을 수행하지 않는 경우, 클라이언트 디바이스는 초기상태로 돌아간다. 이 때, 오디오 데이터 및 오디오 피드백 정보는 출력되지 않는다.
또한, 사용자가 서버 디바이스가 전송하는 오디오 데이터를 수신하지 않는다는 입력을 수행하였지만, 상기 오디오 데이터를 수신하고자 하는 경우를 위해서, 클라이언트 디바이스는 서버 디바이스의 신호세기가 특정 임계값 이상의 세기로 측정되는지 스캔해야 한다. 상기 신호세기의 측정은 최소 Primary channel의 Aux_Ext 패킷 신호세기는 측정을 통하여 수행될 수 있다. 신호세기가 특정 임계값 이상이면, 관찰 절차(Observation Procedure)에서 Aux_Ext 패킷을 파싱(parsing)하여, 확정된 광고 리포트 이벤트(Extended Advertising Report Event)를 호스트로 전달한다.
정리하면, 두 개의 오디오 데이터 즉, 오디오 데이터와 오디오 피드백 정보는는 같은 서버 디바이스가 전송하는 것이므로 하나의 group ID(Broadcast Isochronous Group: BIG)로 묶고, 각각의 데이터는 sub ID(Broadcast Isochronous Stream: BIS)로 표시할 수 있다. 즉, BIG = Initiatolr, BIS1 = 오디오 피드백 정보, BIS2 = 오디오 데이터일 수 있다.
오디오 피드백 정보와 오디오 데이터는 하나의 서버 디바이스에서 전송되므로, 같은 오디오 그룹(Audio Group)에 포함될 수 있다. 따라서, 오디오 데이터 및 오디오 피드백 정보를 하나의 BIG에 포함시키되, BIG에 포함된 서로 다른 BIS에 오디오 데이터 및 음성 피드백을 각각 포함시켜 전송될 수 있다. 보다 구체적으로, BIS 1에 포함된 오디오 피드백 정보는 클라이언트 디바이스가 수신하자마자 디코딩되어 사용자에게 출력될 수 있으나, BIS 2에 담겨있는 오디오 데이터는 클라이언트 디바이스의 상태가 Broadcast Stream - Enable procedure로 변경 된 후에 클라이언트 디바이스가 BIG를 수신한 경우, BIG에 포함된 BIS 2를 수신하여 출력될 수 있다.
위와 같은 동작이 수행되기 위해서, BIS1이 오디오 피드백 정보가 포함되어있는지 여부를 나타내는 지시자 플래그(flag)를 동기화 정보에 포함시킬 수 있다. 이 때, 상기 오디오 피드백 정보가 포함되어있는지 여부를 나타내는 플래그는 "chime bell" 플래그일 수 있다. 상기 chime bell 플래그에 기초하여, 클라이언트 디바이스는 서버 디바이스가 전송하는 오디오 데이터를 선택적으로 수신하고 디코딩할 수 있다.
도 18은 본 명세서에서 제안하는 BIG에 포함되는 BIS를 전송하는 일 예를 나타낸 도이다.
구체적으로, 도 18은 서버 디바이스가 오디오 피드백 정보 및 오디오 데이터를 BIG에 포함시켜 광고메시지를 사용하여 전송하는 경우, 멀티플렉싱하는 방법들의 예시를 나타낸다.
첫 번째로, 서버 디바이스는 오디오 피드백 정보가 포함된 BIS와 오디오 데이터가 포함된 BIS를 순차적으로 전송할 수 있다(1810).
두 번째로, 서버 디바이스는 오디오 피드백 정보가 포함된 BIS와 오디오 데이터가 포함된 BIS를 번갈아 가며 전송(interleave)할 수 있다(1820).
도 19는 본 명세서에서 제안하는 방법이 수행되는 일 예를 나타낸 도이다.
구체적으로, 도 19는 서버 디바이스가 오디오 피드백 정보를 Aux_adv_indication에 포함시켜 클라이언트 디바이스로 전송하는 예시를 나타낸다.
이 방법에서는 오디오 피드백 정보가 동기화 정보가 전송에 사용되는 Aux_Adv_Indication 패킷에 포함된다.
Aux_Adv_Indication 패킷에 포함된 ADATA에 오디오 피드백 정보가 포함된다. 상기 ADATA 필드의 공간이 오디오 피드백 정보를 포함시키기에 충분하지 않은 경우, 다음 번 전송되는 Aux_Chain_indication 패킷에 오디오 피드백 정보의 나머지 데이터가 포함될 수 있다.
또한, 클라이언트 디바이스가 오디오 피드백 정보를 정확하게 디코딩하기 위하여 Aux_Adv_Indication 패킷에 오디오 피드백 정보가 포함된다는 것을 나타내는 플래그를 포함시킬 수 있다. 클라이언트 디바이스는 상기 플래그에 기초하여, 오디오 피드백 정보가 Aux_Adv_Indication 패킷에 포함됨을 판단하고, Aux_Adv_Indication 패킷의 ADATA 필드에 포함되어 있는 오디오 피드백 정보를 디코딩하여, 출력(play)할 수 있다. 여기서, 수신한 오디오 피드백 정보는 사용자에게 오디오 데이터의 종류를 짧은 시간에 전달하기 위한 음성 피드백 용도이므로 디코딩하여 출력하는 시간은 수초 정도의 길이가 된다. 따라서, 이후에 수신하는 Aux_Sync_Indication패킷을 처리하기 위한 클라이언트 디바이스에 큰 부담이 없이 음성 피드백을 사용자에게 들려줄 수 있다.
사용자는 클라이언트 디바이스가 출력한 음성 피드백을 청취하고, 오디오 데이터를 청취하겠다는 정보를 입력하면, 클라이언트 디바이스의 상태는 Broadcast Streaming - Configuration procedure
상태에서 Broadcast Streaming - Enable procedure 상태로 변경된다. 이후, Aux_Sync_indication(및 그 이후의 Aux_Chain_Indication) 에 포함되어 있는 Audio 데이터를 수신하여, 디코딩한다.
도 20은 본 명세서에서 제안하는 방법이 수행되는 일 예를 나타낸 도이다.
구체적으로, 도 20은 복수의 서버 디바이스가 전송하는 오디오 데이터를 클라이언트 디바이스가 수신하는 과정을 구체적으로 나타낸다.
여러 대의 서버 디바이스가 오디오 데이터 및 오디오 피드백 정보를 포함한 오디오 신호(광고 메시지)를 브로드캐스팅하는 경우, 하나의 클라이언트 디바이스는 여러 대의 서버 디바이스가 전송한 복수의 브로드캐스팅 오디오 신호를 검색하게 된다.
이러한 경우, 먼저, 사용자가 복수 개의 서버 디바이스가 전송하는 오디오 데이터들 중 하나의 오디오 데이터만을 선택하는 경우, 클라이언트 디바이스는 수신한 복수의 오디오 신호들에 대응하는 오디오 피드백 정보들을 각각 서로 다른 시점에 서로 엇갈려 사용자에게 들려 준다. 사용자가 청취하기를 희망하는 오디오 데이터와 관련된 오디오 피드백 정보와 관련된 음성 피드백을 듣게 되면 사용자는 청취를 희망하는 오디오 데이터와 관련된 음성 피드백에 대하여 오디오 데이터를 청취하겠음을 나타내는 정보를 입력한다. 이후 사용자는 해당 오디오 데이터를 청취할 수 있다.
두 번째로, 사용자가 복수 개의 서버 디바이스가 전송하는 오디오 데이터들 중 어떠한 오디오 데이터도 선택하지 않는 경우, 클라이언트 디바이스에서 각 오디오 데이터와 관련된 오디오 피드백 정보를 반복하여 출력하는 횟수를 제한할 수 있다. 반복 횟수는 대략 3~5회 정도로 제한될 수 있으며, 음성 피드백이 반복되는 동안 어떠한 정보도 입력하지 않으면 더 이상 음성 피드백을 출력하지 않을 수 있다.
마지막으로, 사용자가 청취를 희망하지 않았던 서버 디바이스의 오디오 데이터를 재청취하기를 희망할 수 있다. 이러한 경우, 클라이언트 디바이스는 프라이머리 채널의 광고 패킷(Advertising packet)(AUX_EXT)의 신호세기를 계속하여 모니터링할 수 있다. 클라이언트 디바이스가 서버 디바이스가 클라이언트 디바이스로부터 가까운 거리에 위치하는 것으로 판단한 경우, 클라이언트 디바이스는 동기화 정보를 수신하여, 오디오 피드백 정보에 기초하여 음성 피드백을 출력한다.
서버 디바이스에 고유한 음성 피드백 설정 방법
도 21 및 22는 본 명세서에서 제안하는 방법이 수행되는 일 예를 나타낸 도이다.
구체적으로, 오디오 피드백 정보를 서버 디바이스에 설정하는 방법의 일 예를 나타낸다.
서버 디바이스가 전송하는 오디오 데이터가 실시간으로 변화하는 특정한 공간에서, 클라이언트 디바이스가 서버 디바이스에 동기화 될 때마다 동일한 음성 피드백(chime bell)이 출력될 수 있다. 이 경우, 사용자는 서버 디바이스가 전송하는 오디오 데이터가 변화했음을 파악하기 어렵게 된다. 따라서, 서버 디바이스가 전송하는 오디오 데이터가 변경된 경우, 오디오 피드백 정보 upload GATT Service를 구성하여, GATT Service를 이용하여 서버 디바이스에 저장된 오디오 피드백 정보를 을 변경할 수 있다.
구체적으로, GATT client(클라이언트 디바이스)는 GATT server(서버 디바이스)로부터 광고 패킷을 수신하고(S2110), GATT client는 GATT server 와 연결을 형성한다(S2120).
다음, GATT client는 GATT server로 GATT Server의 상태 특성(Status characteristic)에 저장되어 있는 상기 오디오 피드백 정보의 상태 정보의 판독을 요청하는 판독 요청 메시지를 상기 서버 디바이스로 전송하고, 다음, 상기 GATT client는 상기 서버 디바이스로부터 상기 상태 정보를 포함하는 판독 응답 메시지를 수신한다(S2130).
상기 상태 정보는 상기 오디오 데이터의 이름 정보, 상기 오디오 데이터가 상기 제 1 특정 특성에 저장된 날짜 정보 또는 상기 오디오 데이터의 버전(Version) 정보 중 적어도 하나를 포함할 수 있다.
다음, GATT client는 GATT server로 상기 상태 정보에 기초하여 상기 오디오 피드백 정보의 변경을 위해서 상기 서버 디바이스의 제 2 특정 특성에 변경된 오디오 피드백 정보와 관련된 특성 값(Characteristic value)의 기입을 요청하는 기입 요청 메시지를 전송한다(S2140).
상기 기입 요청 메시지는 상기 변경된 오디오 피드백 정보를 구성하는 데이터 중 일부의 데이터를 포함할 수 있다.
도 21에 도시되어 있지는 않지만, GATT client는 상기 기입 요청 메시지에 대한 응답으로 기입 응답 메시지를 GATT server로부터 수신할 수 있다.
이 때, GATT client는 새로운 오디오 피드백 정보를 Bluetooth 권장 코덱으로 인코딩된 Binary File로 Data characteristic을 통해 GATT server에게 전송한다.
Characteristic MTU의 크기는 21~255byte 정도이고, File은 한 번의 characteristic write로 전송되기는 어려울 수 있다. 따라서, 복수 회에 걸쳐 characteristic write로 전송될 수 있고, 이를 위해 오디오 피드백 정보를 구성하는 복수의 데이터들 각각의 헤더(Header)에 시퀀스 번호(sequence number)를 적용하여 전송한다.
도 23 및 도 24는 본 명세서에서 제안하는 방법이 수행되는 또 다른 일 예를 나타낸 도면이다.
관리 서버 디바이스는 주변의 서버 디바이스(Broadcast Advertiser)들로부터 각각 동기화 정보를 수신할 수 있다. 관리 서버 디바이스는 수신한 주변의 서버 디바이스의 브로드캐스트 동기화 정보를 다른 브로드 캐스트 스캐너 디바이스(클라이언트 디바이스)에 전송할 수 있다. 이와 같은 방식으로, 클라이언트 디바이스는 다수의 디바이스들과 동기를 맞추기 위해 여러 번 scan을 수행해야 하는 부담이 감소된다. 이러한 방식은 "Scan Offloading" 으로 표현될 수 있다.
복수의 서버 디바이스가 BLE 오디오 브로드캐스팅을 하고 있는 경우, 클라이언트 디바이스에게 각각의 서버 디바이스가 오디오 피드백 정보를 전송하는 것보다, 관리 서버 디바이스에서 한번에 모든 서버 디바이스의 오디오 피드백 정보를 클라이언트 디바이스에게 미리 전송하여, 클라이언트 디바이스의 사용성을 향상시킬 수 있다. 관리 서버 디바이스는 클라이언트 디바이스에게 모든 서버 디바이스들의 동기화 정보를 전달하기 위해서 BLE PAST(PAST(Periodic Advertising Sync Transfer)기술을 사용할 수 있다.
도 23과 같이, 관리 서버 디바이스가 클라이언트 디바이스에게 전송하는 모든 서버 디바이스들의 동기화 정보를 포함하는 전체 동기화 정보는 음성 피드백 전송을 위한 별도의 브로드캐스트 채널을 통하여 전송될 수 있다.
도 24에서, 클라이언트 디바이스는 관리 서버로부터 별도의 브로드캐스트 채널을 통하여 전체 동기화 정보를 수신한다(S2410).
다음, 클라이언트 디바이스는 전체 동기화 정보에 기초하여 주변의 서버 디바이스들로부터 오디오 데이터를 수신한다(S2420).
추가적으로, 블루투스 bonding은 Central(master)기기와 Peripheral(slave)기기간 페어링(pairing)을 위해 사용된 encrypt key를 양쪽에 저장(캐싱)해 두어, 나중에 연결할 때 편리하게 하는 방식을 의미한다.
오디오 피드백 정보는 BLE Audio Broadcasting 환경에서 빈번하게 사용될 데이터로 간주하여, 미리 저장해 둘 수 있다. 서버 디바이스가 한 대만 있더라도, 빈번하게 수신되는 환경이라면 오디오 피드백 정보를 나중에 사용하기 위해 저장(캐싱)할 수 있다.
도 25는 본 명세서에서 제안하는 블루투스 기술을 이용하여 오디오 데이터를 수신 위한 단말에서 구현되는 동작의 일례를 나타낸 도이다.
먼저, 클라이언트 디바이스는, 오디오 스트리밍 서비스(Audio Streaming Service)를 제공하기 위한 확장된 광고 메시지를 수신하기 위한 채널 정보를 포함하는 광고 메시지를 서버(Server) 디바이스로부터 수신한다(S2510).
다음, 상기 클라이언트 디바이스는 상기 채널 정보에 기초하여 상기 오디오 스트리밍 서비스의 오디오 데이터와 관련된 지시자를 포함하는 상기 확장된 광고 메시지를 상기 서버 디바이스로부터 수신한다(S2520).
여기서, 상기 지시자는 상기 오디오 데이터 및 상기 오디오 데이터를 식별하기 위한 오디오 피드백 정보가 그룹핑되어 전송되는 것을 나타낸다.
또한, 여기서, 상기 채널 정보는 확장된 광고 메시지가 전송되는 채널의 인덱스(Index) 및/또는 상기 클라이언트 디바이스와 상기 서버 디바이스의 동기화를 위한 동기화 채널 정보를 포함할 수 있다.
추가적으로, 상기 동기화 정보는 그룹핑된 상기 오디오 데이터와 상기 오디오 피드백 정보와 관련된 그룹핑 ID(dentifier), 상기 오디오 데이터를 식별하기 위한 오디오 데이터 ID 또는 상기 오디오 피드백 정보를 식별하기 위한 오디오 피드백 ID 중 적어도 하나를 포함할 수 있다.
다음, 상기 클라이언트 디바이스는 등시 채널(isochronous channel)을 통해 상기 오디오 데이터 및 상기 오디오 피드백 정보를 상기 서버 디바이스로부터 수신한다(S2530).
다음, 상기 클라이언트 디바이스는 상기 오디오 피드백 정보에 기초하여 사용자로부터 상기 오디오 스트리밍 서비스의 제공의 허용 여부와 관련된 특정 정보를 획득한다(S2540).
이 때, 상기 특정 정보가 상기 오디오 스트리밍 서비스의 제공의 허용을 나타내는 경우, 상기 오디오 데이터를 디코딩한다(S2550).
추가적으로, 상기 클라이언트 디바이스는 상기 오디오 피드백 정보를 디코딩하고, 상기 디코딩된 오디오 피드백 정보를 출력할 수 있다.
또한, 상기 클라이언트 디바이스는 상기 서버 디바이스와 연결을 형성하하고, 상기 서버 디바이스의 제 1 특정 특성(Characteristic)에 저장되어 있는 상기 오디오 피드백 정보의 상태 정보의 판독을 요청하는 판독 요청 메시지를 상기 서버 디바이스로 전송하며, 상기 상태 정보는 상기 오디오 데이터의 이름 정보, 상기 오디오 데이터가 상기 제 1 특정 특성에 저장된 날짜 정보 또는 상기 오디오 데이터의 버전(Version) 정보 중 적어도 하나를 포함하고, 상기 서버 디바이스로부터 상기 상태 정보를 포함하는 판독 응답 메시지를 수신할 수 있다.
여기서, 상기 클라이언트 디바이스는 상기 상태 정보에 기초하여 상기 오디오 피드백 정보의 변경을 위해서 상기 서버 디바이스의 제 2 특정 특성에 변경된 오디오 피드백 정보와 관련된 특성 값(Characteristic value)의 기입을 요청하는 기입 요청 메시지를 상기 서버 디바이스로 전송하고, 상기 기입 요청 메시지는 상기 변경된 오디오 피드백 정보를 구성하는 데이터 중 일부의 데이터를 포함하고, 상기 기입 요청 메시지에 대한 응답으로 기입 응답 메시지를 상기 서버 디바이스로부터 수신할 수 있다.
또한, 상기 기입 요청 메시지는 각각은 상기 일부의 데이터들 대한 시퀀스 번호 정보를 포함할 수 있다.
추가적으로, 상기 클라이언트 디바이스는 상기 서버 디바이스를 포함하는 복수의 서버들을 관리 하는 관리 서버로부터 상기 복수의 서버 디바이스들과 상기 클라이언트 디바이스 간의 동기화와 관련된 전체 동기화 정보를 수신하고, 상기 전체 동기화 정보는 상기 복수의 디바이스들 각각에 대한 동기화 정보를 포함할 수 있다.
여기서, 상기 관리 서버는 상기 복수의 서버 디바이스들 각각에 대한 동기화 정보를 미리 수신하여 저장할 수 있다.
이상에서 설명된 실시예들은 본 발명의 구성요소들과 특징들이 소정 형태로 결합된 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려되어야 한다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성요소들 및/또는 특징들을 결합하여 본 발명의 실시예를 구성하는 것도 가능하다. 본 발명의 실시예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시예에 포함될 수 있고, 또는 다른 실시예의 대응하는 구성 또는 특징과 교체될 수 있다. 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함시킬 수 있음은 자명하다.
본 발명에 따른 실시예는 다양한 수단, 예를 들어, 하드웨어, 펌웨어(firmware), 소프트웨어 또는 그것들의 결합 등에 의해 구현될 수 있다. 하드웨어에 의한 구현의 경우, 본 발명의 일 실시예는 하나 또는 그 이상의 ASICs(application specific integrated circuits), DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays), 프로세서, 콘트롤러, 마이크로 콘트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다.
펌웨어나 소프트웨어에 의한 구현의 경우, 본 발명의 일 실시예는 이상에서 설명된 기능 또는 동작들을 수행하는 모듈, 절차, 함수 등의 형태로 구현될 수 있다. 소프트웨어 코드는 메모리에 저장되어 프로세서에 의해 구동될 수 있다. 상기 메모리는 상기 프로세서 내부 또는 외부에 위치하여, 이미 공지된 다양한 수단에 의해 상기 프로세서와 데이터를 주고 받을 수 있다.
본 발명은 본 발명의 필수적 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있음은 당업자에게 자명하다. 따라서, 상술한 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니 되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다. 그리고, 당해 명세서에서는 물건 발명과 방법 발명이 모두 설명되고 있으며, 필요에 따라 양 발명의 설명은 보충적으로 적용될 수 있다.
이상, 전술한 본 발명의 바람직한 실시예는, 예시의 목적을 위해 개시된 것으로, 당업자라면 이하 첨부된 특허청구범위에 개시된 본 발명의 기술적 사상과 그 기술적 범위 내에서, 다양한 다른 실시예들을 개량, 변경, 대체 또는 부가 등이 가능할 것이다.

Claims (10)

  1. 블루투스 저전력 에너지(Bluetooth Low Energy) 기술을 이용하여 오디오 데이터를 수신하는 방법에 있어서, 클라이언트(Client) 디바이스에 의해 수행되는 방법은,
    오디오 스트리밍 서비스(Audio Streaming Service)를 제공하기 위한 확장된 광고 메시지를 수신하기 위한 채널 정보를 포함하는 광고 메시지를 서버(Server) 디바이스로부터 수신하는 단계;
    상기 채널 정보에 기초하여 상기 오디오 스트리밍 서비스의 오디오 데이터와 관련된 지시자를 포함하는 상기 확장된 광고 메시지를 상기 서버 디바이스로부터 수신하는 단계,
    상기 지시자는 상기 오디오 데이터 및 상기 오디오 데이터를 식별하기 위한 오디오 피드백 정보가 그룹핑되어 전송되는 것을 나타내고;
    등시 채널(isochronous channel)을 통해 상기 오디오 데이터 및 상기 오디오 피드백 정보를 상기 서버 디바이스로부터 수신하는 단계;
    상기 오디오 피드백 정보에 기초하여 사용자로부터 상기 오디오 스트리밍 서비스의 제공의 허용 여부와 관련된 특정 정보를 획득하는 단계; 및
    상기 특정 정보가 상기 오디오 스트리밍 서비스의 제공의 허용을 나타내는 경우, 상기 오디오 데이터를 디코딩하는 단계를 포함하는 것을 특징으로 하는 방법.
  2. 제 1 항에 있어서,
    상기 오디오 피드백 정보를 디코딩하는 단계; 및
    상기 디코딩된 오디오 피드백 정보를 출력하는 단계를 더 포함하는 것을 특징으로 하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  3. 제 1 항에 있어서,
    상기 채널 정보는 확장된 광고 메시지가 전송되는 채널의 인덱스(Index) 및/또는 상기 클라이언트 디바이스와 상기 서버 디바이스의 동기화를 위한 동기화 채널 정보를 포함하는 것을 특징으로 하는 방법.
  4. 제 3 항에 있어서,
    상기 동기화 정보는 그룹핑된 상기 오디오 데이터와 상기 오디오 피드백 정보와 관련된 그룹핑 ID(dentifier), 상기 오디오 데이터를 식별하기 위한 오디오 데이터 ID 또는 상기 오디오 피드백 정보를 식별하기 위한 오디오 피드백 ID 중 적어도 하나를 포함하는 것을 특징으로 하는 방법.
  5. 제 1 항에 있어서,
    상기 서버 디바이스와 연결을 형성하는 단계;
    상기 서버 디바이스의 제 1 특정 특성(Characteristic)에 저장되어 있는 상기 오디오 피드백 정보의 상태 정보의 판독을 요청하는 판독 요청 메시지를 상기 서버 디바이스로 전송하는 단계,
    상기 상태 정보는 상기 오디오 데이터의 이름 정보, 상기 오디오 데이터가 상기 제 1 특정 특성에 저장된 날짜 정보 또는 상기 오디오 데이터의 버전(Version) 정보 중 적어도 하나를 포함하고; 및
    상기 서버 디바이스로부터 상기 상태 정보를 포함하는 판독 응답 메시지를 수신하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  6. 제 5 항에 있어서,
    상기 상태 정보에 기초하여 상기 오디오 피드백 정보의 변경을 위해서 상기 서버 디바이스의 제 2 특정 특성에 변경된 오디오 피드백 정보와 관련된 특성 값(Characteristic value)의 기입을 요청하는 기입 요청 메시지를 상기 서버 디바이스로 전송하는 단계,
    상기 기입 요청 메시지는 상기 변경된 오디오 피드백 정보를 구성하는 데이터 중 일부의 데이터를 포함하고; 및
    상기 기입 요청 메시지에 대한 응답으로 기입 응답 메시지를 상기 서버 디바이스로부터 수신하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  7. 제 6 항에 있어서,
    상기 기입 요청 메시지는 각각은 상기 일부의 데이터들 대한 시퀀스 번호 정보를 포함하는 것을 특징으로 하는 방법.
  8. 제 1 항에 있어서,
    상기 서버 디바이스를 포함하는 복수의 서버들을 관리 하는 관리 서버로부터 상기 복수의 서버 디바이스들과 상기 클라이언트 디바이스 간의 동기화와 관련된 전체 동기화 정보를 수신하는 단계를 더 포함하되,
    상기 전체 동기화 정보는 상기 복수의 디바이스들 각각에 대한 동기화 정보를 포함하는 것을 특징으로 하는 방법.
  9. 제 8 항에 있어서,
    상기 관리 서버는 상기 복수의 서버 디바이스들 각각에 대한 동기화 정보를 미리 수신하여 저장하는 것을 포함하는 것을 특징으로 하는 방법.
  10. 블루투스 저전력 에너지(Bluetooth Low Energy) 기술을 이용하여 오디오 데이터를 수신하는 클라이언트 디바이스에 있어서,
    무선 신호를 송신하기 위한 전송기(transmitter);
    무선 신호를 수신하기 위한 수신기(receiver); 및
    상기 전송기 및 수신기와 기능적으로 연결되는 프로세서를 포함하고, 상기 프로세서는,
    오디오 스트리밍 서비스(Audio Streaming Service)를 제공하기 위한 확장된 광고 메시지를 수신하기 위한 채널 정보를 포함하는 광고 메시지를 서버(Server) 디바이스로부터 수신하도록 상기 수신기를 제어하고,
    상기 채널 정보에 기초하여 상기 오디오 스트리밍 서비스의 오디오 데이터와 관련된 지시자를 포함하는 상기 확장된 광고 메시지를 상기 서버 디바이스로부터 수신하도록 상기 수신기를 제어하고,
    상기 지시자는 상기 오디오 데이터 및 상기 오디오 데이터를 식별하기 위한 오디오 피드백 정보가 그룹핑되어 전송되는 것을 나타내고,
    등시 채널(isochronous channel)을 통해 상기 오디오 데이터 및 상기 오디오 피드백 정보를 상기 서버 디바이스로부터 수신하도록 상기 수신기를 제어하고,
    상기 오디오 피드백 정보에 기초하여 사용자로부터 상기 오디오 스트리밍 서비스의 제공의 허용 여부와 관련된 특정 정보를 획득하고,
    상기 특정 정보가 상기 오디오 스트리밍 서비스의 제공의 허용을 나타내는 경우, 상기 오디오 데이터를 디코딩하는 것을 특징으로 하는 클라이언트 디바이스.
PCT/KR2019/015163 2018-11-08 2019-11-08 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치 WO2020096412A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/292,329 US11665214B2 (en) 2018-11-08 2019-11-08 Method and apparatus for receiving audio data by using Bluetooth technology

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR20180136900 2018-11-08
KR10-2018-0136900 2018-11-08

Publications (1)

Publication Number Publication Date
WO2020096412A1 true WO2020096412A1 (ko) 2020-05-14

Family

ID=70612141

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2019/015163 WO2020096412A1 (ko) 2018-11-08 2019-11-08 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치

Country Status (2)

Country Link
US (1) US11665214B2 (ko)
WO (1) WO2020096412A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114648864A (zh) * 2020-12-18 2022-06-21 瑞昱半导体股份有限公司 蓝牙音频广播系统及多成员蓝牙装置
CN114666741A (zh) * 2020-12-22 2022-06-24 Oppo广东移动通信有限公司 无线通讯方法及系统

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11736919B2 (en) * 2019-03-07 2023-08-22 Lg Electronics Inc. Method for receiving audio data by using bluetooth technology, and device therefor
CN118264987A (zh) * 2019-06-03 2024-06-28 英迪股份有限公司 用于无线通信系统中的广播发现服务的方法、装置和计算机程序及其记录介质
WO2021006710A1 (ko) * 2019-07-10 2021-01-14 엘지전자 주식회사 무선 통신 시스템에서 근거리 무선 통신을 이용한 오디오 데이터 전송 방법 및 이에 대한 장치
US20220321368A1 (en) * 2019-08-29 2022-10-06 Intellectual Discovery Co., Ltd. Method, device, computer program, and recording medium for audio processing in wireless communication system
CN115278332A (zh) * 2022-06-30 2022-11-01 海信视像科技股份有限公司 一种显示设备、播放设备和数据传输方法
WO2024001362A1 (zh) * 2022-06-30 2024-01-04 海信视像科技股份有限公司 显示设备、蓝牙设备和数据处理方法
CN115278324A (zh) * 2022-06-30 2022-11-01 海信视像科技股份有限公司 一种显示设备、蓝牙设备和bis音频传输方法
CN115665672B (zh) * 2022-11-21 2023-02-28 成都市安比科技有限公司 基于蓝牙的低功耗多人实时语音传输方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101551720B1 (ko) * 2014-01-13 2015-09-10 경북대학교 산학협력단 단말 간 서비스 제공 시스템 및 방법
KR20160148646A (ko) * 2014-05-30 2016-12-26 애플 인크. 전자 디바이스들 사이의 액티비티 계속
US20170171798A1 (en) * 2015-12-10 2017-06-15 Lg Electronics Inc. Method and apparatus for transmitting and receiving data in wireless communication system
KR101783311B1 (ko) * 2014-02-12 2017-09-29 엘지전자 주식회사 무선 통신 시스템에서 블루투스 저전력 에너지를 이용하여 객체 전송 서비스를 수행하기 위한 방법 및 장치
KR101910067B1 (ko) * 2014-07-03 2018-10-22 엘지전자 주식회사 블루투스 통신을 지원하는 무선 통신 시스템에서 오디오 데이터를 송수신하기 위한 방법 및 이를 위한 장치

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20120074059A (ko) * 2010-12-27 2012-07-05 삼성전자주식회사 오디오 데이터 출력 방법 및 장치
US10142767B2 (en) * 2014-04-21 2018-11-27 Lg Electronics Inc. Method and apparatus for transmitting data using Bluetooth low energy in wireless communication system
WO2015166680A1 (ja) * 2014-04-30 2015-11-05 ソニー株式会社 クライアント装置、サーバ、記録媒体および情報処理方法
US20160359925A1 (en) * 2015-06-08 2016-12-08 Lg Electronics Inc. Method and apparatus for transmitting and receiving data in wireless communication system
US10306072B2 (en) * 2016-04-12 2019-05-28 Lg Electronics Inc. Method and device for controlling further device in wireless communication system
US10244307B1 (en) * 2018-02-09 2019-03-26 Bestechnic (Shanghai) Co., Ltd. Communication of wireless headphones

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101551720B1 (ko) * 2014-01-13 2015-09-10 경북대학교 산학협력단 단말 간 서비스 제공 시스템 및 방법
KR101783311B1 (ko) * 2014-02-12 2017-09-29 엘지전자 주식회사 무선 통신 시스템에서 블루투스 저전력 에너지를 이용하여 객체 전송 서비스를 수행하기 위한 방법 및 장치
KR20160148646A (ko) * 2014-05-30 2016-12-26 애플 인크. 전자 디바이스들 사이의 액티비티 계속
KR101910067B1 (ko) * 2014-07-03 2018-10-22 엘지전자 주식회사 블루투스 통신을 지원하는 무선 통신 시스템에서 오디오 데이터를 송수신하기 위한 방법 및 이를 위한 장치
US20170171798A1 (en) * 2015-12-10 2017-06-15 Lg Electronics Inc. Method and apparatus for transmitting and receiving data in wireless communication system

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114648864A (zh) * 2020-12-18 2022-06-21 瑞昱半导体股份有限公司 蓝牙音频广播系统及多成员蓝牙装置
CN114666741A (zh) * 2020-12-22 2022-06-24 Oppo广东移动通信有限公司 无线通讯方法及系统

Also Published As

Publication number Publication date
US20210400096A1 (en) 2021-12-23
US11665214B2 (en) 2023-05-30

Similar Documents

Publication Publication Date Title
WO2020096412A1 (ko) 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치
WO2016182404A1 (ko) 블루투스 저전력 에너지 기술을 이용하여 대체 통신 수단을 연결하기 위한 방법 및 장치
WO2020213959A1 (ko) 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치
WO2016039598A1 (ko) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2018048268A1 (ko) 블루투스 기술을 이용하여 디바이스를 연결하기 위한 방법 및 장치
WO2018074892A1 (ko) 블루투스 기술을 이용하여 데이터를 송수신하기 위한 방법 및 장치
WO2018169380A1 (ko) 블루투스 기술을 이용하여 오디오 신호를 처리하기 위한 방법 및 장치
WO2018222024A1 (ko) 블루투스 le 기술을 이용하여 디바이스를 연결하기 위한 방법 및 장치
WO2015194854A1 (ko) 블루투스 le(low energy) 기술을 이용하여 디바이스 간 커넥션을 형성하기 위한 방법 및 장치
WO2016167541A1 (ko) 블루투스 저전력 기술을 이용하여 디바이스를 연결하기 위한 방법 및 장치
WO2015137601A1 (ko) 무선통신 시스템에서 데이터 전송률 조절 방법 및 장치
WO2016175638A1 (ko) 블루투스 메쉬 네트워크에서 디바이스의 주소를 할당하기 위한 방법 및 장치
WO2016017909A1 (ko) 블루투스 통신을 지원하는 무선 통신 시스템에서 전자기기를 제어하기 위한 방법 및 장치
WO2016017907A1 (ko) 블루투스 통신을 지원하는 무선 통신 시스템에서 전자기기를 제어하기 위한 방법 및 장치
WO2016178542A1 (ko) 블루투스에서 데이터를 송수신하기 위한 방법 및 장치
WO2015163680A1 (ko) 무선 통신 시스템에서 블루투스 저전력 에너지 기술을 이용하여 데이터를 송수신하기 위한 방법 및 장치
WO2016036139A2 (ko) 블루투스 le(low energy) 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2020180168A1 (ko) 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치
WO2016175640A1 (ko) 블루투스를 이용한 메쉬 네트워크에서 데이터를 송수신하기 위한 방법 및 장치
WO2016036206A2 (ko) 블루투스 le(low energy) 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2018021877A1 (ko) 디바이스의 연결을 형성하기 위한 방법 및 장치
WO2016175575A1 (ko) 블루투스 메쉬 네트워크를 이용하여 데이터를 송수신하기 위한 방법 및 장치
WO2017018604A1 (ko) 블루투스 le(low energy) 기술을 이용하여 대체 통신 수단을 연결하기 위한 방법 및 장치
WO2016153278A1 (ko) 블루투스를 이용한 메쉬 네트워크에서 데이터를 송수신하기 위한 방법 및 장치
WO2018124852A1 (ko) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치

Legal Events

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

Ref document number: 19881743

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19881743

Country of ref document: EP

Kind code of ref document: A1