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

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

Info

Publication number
WO2020180168A1
WO2020180168A1 PCT/KR2020/003270 KR2020003270W WO2020180168A1 WO 2020180168 A1 WO2020180168 A1 WO 2020180168A1 KR 2020003270 W KR2020003270 W KR 2020003270W WO 2020180168 A1 WO2020180168 A1 WO 2020180168A1
Authority
WO
WIPO (PCT)
Prior art keywords
audio data
information
server device
audio
advertisement
Prior art date
Application number
PCT/KR2020/003270
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/436,373 priority Critical patent/US11736919B2/en
Publication of WO2020180168A1 publication Critical patent/WO2020180168A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B5/00—Near-field transmission systems, e.g. inductive or capacitive transmission systems
    • H04B5/70—Near-field transmission systems, e.g. inductive or capacitive transmission systems specially adapted for specific purposes
    • H04B5/77—Near-field transmission systems, e.g. inductive or capacitive transmission systems specially adapted for specific purposes for interrogation
    • 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
    • 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

Definitions

  • the present invention relates to a method for receiving audio data using Bluetooth technology, which is a short-range technology in a wireless communication system, and an apparatus therefor, and more particularly, to an audio data based on information on audio data using Bluetooth low power technology. It relates to a method and apparatus for receiving.
  • Bluetooth is a short-range wireless technology standard that can wirelessly connect various devices in a short distance to exchange data.
  • the user When performing wireless communication between two devices using Bluetooth communication, the user performs a procedure to search for Bluetooth devices to communicate with and request a connection. do.
  • a device may mean a device or a device.
  • the user may perform a connection after searching for a Bluetooth device based on the Bluetooth communication method to be used using the Bluetooth device.
  • Bluetooth communication methods include BR/EDR (Basic Rate/Enhanced Data Rate) method and LE (Low Energy) method, which is a low power method.
  • the BR/EDR method may be referred to as Bluetooth Classic.
  • the Bluetooth classic method includes Bluetooth technology that has been inherited since Bluetooth 1.0 using Basic Rate and Bluetooth technology that uses Enhanced Data Rate supported from Bluetooth 2.0.
  • Bluetooth Low energy (hereinafter referred to as Bluetooth LE) technology has been applied since Bluetooth 4.0 and consumes little power and can stably provide hundreds of kilobytes (KB) of information.
  • This Bluetooth low power energy technology exchanges information between devices using an attribute protocol.
  • This 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.
  • Bluetooth can achieve relatively high speed with 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 an apparatus for receiving audio data using Bluetooth technology.
  • an object of the present specification is to provide a method and an apparatus for receiving audio data information on audio data received from server devices.
  • an object of the present specification is to provide a method and an apparatus for determining whether to receive audio data based on audio data information.
  • the present specification provides a method of receiving audio data using a Bluetooth low energy technology.
  • a method performed by a client device includes information for providing an audio streaming service.
  • decoding the audio data when the specific information indicates permission to provide the audio data is obtained from the server device.
  • the present specification further includes decoding the audio data information, wherein only the audio data information is decoded from among the audio data and the audio data information before obtaining the specific information from the user.
  • the present specification is characterized in that it further comprises the step of outputting the decoded audio data information.
  • the synchronization information is characterized in that it includes timing information of the broadcast audio data and frequency hopping information for reception of the audio data.
  • a grouping ID (identifier) for identifying the broadcast audio data is assigned to the broadcast audio data
  • an audio data ID for identifying the audio data is assigned to the audio data
  • the audio An audio data ID for identifying data information is assigned to the audio data information.
  • the present specification is characterized in that the audio data and the audio data information are interleaved and grouped.
  • the present specification forming a connection with the server device; Transmitting a read request message to the server device requesting to read state information of the audio data information stored in a first characteristic of the server device, wherein the state information includes 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; And receiving a read response message including the status information from the server device.
  • the present specification provides a write request message for requesting to write a characteristic value related to the changed audio data information in a second specific characteristic of the server device in order to change the audio data information based on the state information. Transmitting to the server device, wherein the write request message includes some data of data constituting the changed audio data information; And receiving a write response message from the server device in response to the write request message.
  • each of the write request message is characterized in that it includes sequence number information for the part of the data.
  • the present specification further includes the step of receiving total synchronization information related to synchronization between the plurality of server devices and the client device from a management server that manages a plurality of server devices including the server device, wherein the entire
  • the synchronization information is characterized in that it includes synchronization information for each of the plurality of server devices.
  • the present specification is characterized in that synchronization information for each of the plurality of server devices is previously stored in the management server.
  • the audio data is audio data related to a specific program provided by the server device, and the audio data information indicates a title of the specific program.
  • the present specification further includes the step of measuring the received signal strength of the first advertisement message, wherein when the received signal strength of the first advertisement message is greater than or equal to a specific threshold, decoding the first advertisement message It is characterized.
  • the transmitter for transmitting a wireless signal
  • a receiver for receiving a radio signal
  • a processor functionally connected to the transmitter and the receiver, wherein the processor controls the receiver to receive a first advertisement message including information for providing an audio streaming service from a server device, and And controlling the receiver to receive a second advertisement message including synchronization information for synchronization between the client device and the server device from the server device, and audio data of the audio streaming service includes audio data information for the audio data
  • the audio data is
  • the present specification has an effect of receiving audio data using Bluetooth technology.
  • the present specification has an effect of receiving audio data information on audio data received from server devices.
  • the present specification has an effect of determining whether to receive audio data based on audio data information.
  • 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 in the present specification.
  • FIG 3 shows an example of a Bluetooth communication architecture to which the methods proposed in the present specification can be applied.
  • GATT Bluetooth low power energy Generic Attribute Profile
  • FIG. 5 is a flowchart illustrating an example of a connection procedure method in 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 can be used.
  • 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 in a case where a plurality of server devices exist around a client device.
  • 11 is a diagram showing an example of a method of transmitting a periodic advertisement message using Bluetooth low power.
  • FIG. 12A shows examples of a PDU format of an advertisement message transmitted by a server device.
  • 12B is a diagram illustrating an example of 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
  • 16 shows an example of a method of transmitting audio data using Bluetooth low power.
  • 17 is a diagram illustrating an example of a method of transmitting audio data using Bluetooth low power.
  • FIG. 18 is a diagram illustrating an example of fields (octets) included in BIGINFO.
  • 19 is a diagram illustrating an example of a ⁇ BIG parameter field and an SDU_Config field showing an example of a specific field included in BIG synchronization information.
  • 20 is a diagram showing an example in which the method proposed in the present specification is performed.
  • 21 is a diagram showing an example in which the method proposed in the present specification is performed.
  • 22 is a diagram illustrating an example in which a method for transmitting audio data based on audio data information proposed in the present specification is performed.
  • 23 is a diagram illustrating an example of a method of transmitting audio data and audio data information by a server device.
  • 24 is a diagram illustrating an example of a method for a server device to transmit audio data and audio data information.
  • 25 is a diagram illustrating an example in which a method for transmitting audio data based on audio data information proposed in the present specification is performed.
  • 26 and 27 are diagrams illustrating an example of a method for a client device to set audio data information in a server device.
  • 28 and 29 are diagrams illustrating an example of a method for a management server device to provide synchronization information of server devices to a client device.
  • FIG. 30 shows examples in which a method of receiving audio data is performed using the Bluetooth technology proposed in the present specification.
  • 31 shows an example in which a method of receiving audio data is performed using the Bluetooth technology proposed in the present specification.
  • 32 is a diagram showing an example of an operation implemented in a client device for receiving audio data using the Bluetooth technology proposed in the present specification.
  • 33 is a diagram showing a hierarchical structure of a broadcast profile.
  • 35 shows an example of a scenario to which a broadcast TV audio profile can be applied.
  • 36 shows an example in which an initiator informs a user of information on a program being broadcast based on program information.
  • FIG. 37 shows another example of a scenario to which a broadcast TV audio profile can be applied.
  • 39 shows an example of a configuration of a data field included in an extended advertisement PDU.
  • 40 shows an example of a configuration of a data field included in AUX_SYN_IND_PDU.
  • 41 shows an example of a BLE broadcast audio operation.
  • 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) technology.
  • BLE Bluetooth Low Energy
  • BLE technology Compared to Bluetooth BR/EDR (Basic Rate/Enhanced Data Rate) technology, BLE technology has a relatively small duty cycle and can be produced at a low price, and power consumption can be significantly reduced through a low data rate. When using a coin cell battery, it can operate for more than 1 year.
  • BR/EDR Basic Rate/Enhanced Data Rate
  • the connection procedure between devices is simplified, and the packet size is 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
  • the latency is 3ms
  • the output power is less than 10mW (10dBm)
  • (7) is mainly used for applications such as mobile phones, watches, sports, healthcare, sensors, and device control.
  • the server device 120 may operate as a client device in a relationship with another device, and the client device may operate as a server device in a relationship with another device. That is, in the BLE communication system, any one device may operate as a server device or a client device, and, if necessary, may operate as a server device and a client device simultaneously.
  • the server device 120 is a data service device, a slave device device, a slave device, a server, a conductor, a host device, a gateway, and a sensing device. It may be expressed as a (Sensing Device), a monitoring device, a first device, a second device, and the like.
  • the client device 110 is a master device, a master, a client, a member, a sensor device, a sink device, a collector, a third device, a fourth device, etc. Can be expressed.
  • the server device and the client device correspond to major 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 the 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 in order to provide data information to the client device. Further, when the server device transmits an indication message to the client device, it 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 an input unit (User Input Interface) in the process of transmitting and receiving notification, instruction, and confirmation messages with the client device. can do.
  • an input unit User Input Interface
  • the server device may read data from a memory unit or write new data to the memory unit in the process of transmitting and receiving messages 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 the client devices by using 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, and the like, and when receiving an instruction message from the server device, sends a confirmation message in response to the instruction message.
  • the client device may provide information to a user through an output unit or receive an input from a user through an input unit in a process of transmitting and receiving messages with the server device.
  • the client device may read data from a memory or write new data to the memory in a process of transmitting and receiving a message with the server device.
  • Hardware components such as an output unit, an input unit, and a memory of the server device and the client device will be described in detail with reference to FIG. 2.
  • the wireless communication system may configure Personal Area Networking (PAN) through Bluetooth technology.
  • PAN Personal Area Networking
  • files, documents, and the like 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 in the present specification.
  • the server device 110 includes an output unit 111, a user input interface 112, a power supply unit 113, a processor 114, and a memory. (Memory Unit, 115), a Bluetooth interface (Bluetooth Interface, 116), another communication interface (Other Interface, 117) and a communication unit (or transceiver, 118).
  • the output unit 111, the input unit 112, the power supply unit 113, the processor 114, the memory 115, the Bluetooth interface 116, the other communication interface 117 and the communication unit 118 are proposed in this specification. To do how to do it is functionally linked.
  • the client device 120 includes an output unit (Display Unit, 121), an input unit (User Input Interface, 122), a power supply unit (Power Supply Unit, 123), a processor (Processor, 124), a memory (Memory Unit) 125 , Bluetooth interface (Bluetooth Interface, 126) and a communication unit (or transceiver, 127).
  • Display Unit 121
  • input unit User Input Interface, 122
  • power supply unit Power Supply Unit
  • processor Processor
  • Memory Unit Memory
  • Bluetooth interface Bluetooth Interface
  • communication unit or transceiver, 127.
  • the output unit 121, the input unit 122, the power supply unit 123, the processor 124, the memory 125, the Bluetooth interface 126, and the communication unit 127 are used to perform the method proposed in this specification. Functionally connected.
  • the Bluetooth interfaces 116 and 126 refer to a unit (or module) capable of transmitting request/response, command, notification, instruction/confirmation message, etc. or data between devices using Bluetooth technology.
  • the memories 115 and 125 are units implemented in various types of devices, and refer to units in which various types of data are stored.
  • the processors 114 and 124 refer to a module that controls the overall operation of the server device 110 or the client device 120, and controls to process a message transmission request and received message through a Bluetooth interface and other communication interfaces.
  • the processors 114 and 124 may be expressed as a control unit, a control unit, and a controller.
  • the processors 114 and 124 may include an application-specific integrated circuit (ASIC), another chipset, a logic circuit, and/or a data processing device.
  • ASIC application-specific integrated circuit
  • the processor (114, 124) controls the communication unit to receive an advertising message from the server device (110), transmits a scan request message to the server device (110), and the server device (110) Controls the communication unit to receive a scan response message in response to the scan request from, and a Connect Request message to the server device 110 to establish a Bluetooth connection with the server device 110 Controls the communication unit to transmit.
  • the memories 115 and 125 may include read-only memory (ROM), random access memory (RAM), flash memory, memory card, storage medium, and/or other storage device.
  • the communication units 118 and 127 may include a baseband circuit for processing a radio signal.
  • the above-described technique may be implemented as a module (process, function, etc.) that performs the above-described functions.
  • the modules are stored in memory and can be executed by the processor.
  • the memories 115 and 125 may be inside or outside the processors 114 and 124, and may be connected to the processors 114 and 124 by various well-known means.
  • the output units 111 and 121 refer to modules for providing device status information and message exchange information to a user through a screen.
  • the power supply unit refers to a module that receives external power and internal power under the control of a control unit and supplies power necessary for the operation of each component.
  • BLE technology has a small duty cycle, and power consumption can be greatly reduced through a low data rate.
  • FIG 3 shows an example of a Bluetooth communication architecture to which the methods proposed in the present specification can be applied.
  • FIG. 3 shows an example of an 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, hereinafter, it will be expressed as a controller stACK.
  • the controller stack may be implemented using a communication module that may include a Bluetooth wireless device, and a processor module that may include a processing device such as a microprocessor, for example.
  • the host stack can be implemented as part of an OS running on a processor module, or as an instantiation of a package on the OS.
  • controller stack and the host stack may operate or run on the same processing device within a processor module.
  • the host stack includes Generic Access Profile (GAP) 310, GATT based Profiles (320), Generic Attribute Profile (GATT) 330, Attribute Protocol (ATT) 340, Security Manage (SM) 350, L2CAP (Logical Link Control and Adaptation Protocol, 360).
  • GAP Generic Access Profile
  • GATT Generic Attribute Profile
  • ATT Attribute Protocol
  • SM Security Manage
  • L2CAP Logical Link Control and Adaptation Protocol
  • the host stack uses L2CAP to multiplex various protocols and profiles provided by the upper level of Bluetooth.
  • L2CAP Logical Link Control and Adaptation Protocol, 360
  • L2CAP provides one bidirectional channel for transmitting data to a specific protocol or profile.
  • the L2CAP may be operable to multiplex data between higher layer protocols, segment and reassemble packages, and manage multicast data transmission.
  • BLE uses 3 fixed channels (1 for signaling CH, 1 for Security Manager, 1 for Attribute protocol).
  • BR/EDR Base Rate/Enhanced Data Rate
  • SM Security Manager
  • ATT Attribute Protocol, 340
  • ATT Application Protocol
  • ATT defines rules for accessing data of counterpart devices in a server-client structure.
  • ATT has 6 message types (Request, Response, Command, Notification, Indication, Confirmation).
  • Request message is a message for requesting specific information from the client device to the server device
  • Response message is a response message to the Request message, from the server device to the client device. Refers to the message sent to.
  • Command message This message is sent from the client device to the server device to instruct a command for a specific operation.
  • the server device does not transmit a response to the command message to the client device.
  • Notification message This message is 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.
  • GAP Generic Access Profile
  • GAP is mainly used for device discovery, connection creation, and security procedures, defines a method of providing information to users, and defines the following attribute types.
  • UUID Universal Unique Identifier, value type
  • GATT-based Profiles are profiles that depend on GATT and are mainly applied to BLE devices.
  • GATT-based Profiles may be Battery, Time, FindMe, Proximity, Time, Object Delivery Service, and the like.
  • the specific contents of GATT-based Profiles are as follows.
  • GATT may be operable as a protocol describing how ATT is used when 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 may use features to describe the state and services of a device, and how features relate to each other and how they are used.
  • the controller stack includes a physical layer 390, a link layer 380, and a host controller interface 370.
  • the physical layer (wireless transmission/reception module, 390) is a layer that transmits and receives 2.4 GHz radio signals, and uses GFSK (Gaussian Frequency Shift Keying) modulation and a frequency hopping technique composed of 40 RF channels.
  • GFSK Gausian Frequency Shift Keying
  • the link layer 380 transmits or receives Bluetooth packets.
  • the link layer creates a connection between devices after performing the advertising and scanning functions using 3 advertising channels, and provides a function to send and receive data packets of up to 42 bytes through 37 data channels.
  • HCI Host Controller Interface
  • HCI provides an interface between the host stack and the controller stack, providing commands and data from the host stack to the controller stack, and providing events and data from the controller stack to the host stack.
  • the BLE procedure can be classified 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 in 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 an advertisement packet, a scan request, or a connection request.
  • the advertisement device refers to a device that transmits an advertisement event, that is, performs advertisement, and is also referred to as an advertiser.
  • the scanning device refers to a device that performs scanning and a device that transmits a scan request.
  • a scanning device when a scanning device receives some advertisement packets from an advertisement device, the scanning device must transmit a scan request to the advertisement device.
  • the scanning device may ignore advertisement packets transmitted from the advertisement device.
  • the device filtering procedure can also be used in the connection request process. If device filtering is used in the connection request process, it is not necessary to transmit a response to the connection request by disregarding the connection request.
  • the advertisement device performs an advertisement procedure to perform non-directional broadcast to devices in the area.
  • non-directional broadcast refers to broadcast in all (all) directions, not broadcast in a specific direction.
  • Non-directional broadcast refers to broadcast in a specific direction.
  • Non-directional broadcast occurs without a connection procedure between an advertisement 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 advertisement procedure may be used to provide periodic broadcast of user data to scanning devices that are listening on the advertisement channel.
  • the advertisement devices may receive scan requests from listening devices that are listening to obtain additional user data from the advertisement 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 receiving the scan request.
  • Broadcast user data sent as part of advertisement 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 advertisement and enters a connected mode. The advertising device may start advertising again after the connected mode.
  • a device performing scanning that is, a scanning device, performs a scanning procedure to listen to a non-directional broadcast of user data from advertisement devices using an advertisement physical channel.
  • the scanning device transmits a scan request to the advertisement device through an advertisement physical channel in order to request additional data from the advertisement device.
  • the advertisement device transmits a scan response, which is a response to the scan request, including additional data requested by the scanning device through the advertisement physical channel.
  • the scanning procedure may be used while the BLE piconet is connected to another BLE device.
  • 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 transmits a connection request to the advertisement device through the advertisement physical channel. And you can start a Bluetooth connection.
  • the scanning device When the scanning device transmits a connection request to the advertisement device, the scanning device stops scanning the initiator mode for additional broadcast and enters the connection mode.
  • Bluetooth devices capable of Bluetooth communication (hereinafter, referred to as'Bluetooth devices') perform an advertisement procedure and a scanning procedure to discover nearby devices or to be discovered by other devices within a given area.
  • the discovery procedure is performed asymmetrically.
  • a Bluetooth device that tries to find other devices around it is called a discovery device, and listens to find devices that advertise scannable advertising events.
  • a Bluetooth device that is discovered and available from another device is called a discoverable device, and actively broadcasts an advertisement event so that other devices can scan through an advertisement (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 a specific Bluetooth device perform an advertisement procedure while another Bluetooth device performs a scanning procedure.
  • the advertising procedure may be the goal, and as a result, only one device will respond to the advertisement.
  • the connection After receiving an advertisement event accessible from the advertisement device, the connection may be initiated by sending a connection request to the advertisement device through an advertisement (broadcast) physical channel.
  • the link layer 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 consists of at least one advertisement PDU, and advertisement PDUs are transmitted through used advertisement channel indexes.
  • the advertisement event may be terminated when each transmitted through advertisement channel indexes in which the advertisement PDU is used, or when the advertisement device needs to reserve space for performing other functions, the advertisement event may be terminated earlier.
  • the link layer enters the scanning state by the instruction of the host (stack). In the scanning state, the link layer listens for advertisement channel indexes.
  • scanning states There are two types of scanning states: passive scanning and active scanning, and each scanning type is determined by the host.
  • a separate time or advertisement channel index for performing scanning is not defined.
  • the link layer listens for the advertisement channel index during the scanWindow duration.
  • the scanInterval is defined as the interval (interval) between the starting points of two consecutive scan windows.
  • the link layer must 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 advertising 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 advertisement PDU type 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 listens for advertisement channel indexes.
  • the link layer listens for the advertisement channel index during the scan window period.
  • the link layer enters the connected state when the device performing the connection request, that is, when the initiating device transmits a CONNECT_REQ PDU to the advertisement device or when the advertisement device receives a CONNECT_REQ PDU from the initiating device.
  • connection After entering the connected state, the connection is considered to be created. However, it does not need to be considered to be established when the connection enters the connected state. The only difference between a newly created connection and an established connection is the link layer connection supervision timeout value.
  • the link layer that plays the role of a master is called a master
  • the link layer that plays the role of a slave is called a slave.
  • the master controls the timing of the connection event, and the connection event refers to the timing of synchronization between the master and the slave.
  • BLE devices use packets defined below.
  • the Link Layer has only one packet format used for both advertising channel packets and data channel packets.
  • Each packet is composed of four fields: Preamble, Access Address, PDU and CRC.
  • the PDU When one packet is transmitted on an advertisement physical channel, the PDU will be an advertisement channel PDU, and when one packet is transmitted on a data physical channel, the PDU will be a data channel PDU.
  • the advertisement channel PDU Packet Data Unit
  • PDU Packet Data Unit
  • the PDU type field of the advertisement channel PDU included in the header indicates the PDU type as defined in Table 1 below.
  • advertisement channel PDU types below are called advertisement PDUs and are used in specific events.
  • ADV_IND Connectable non-directional advertising event
  • ADV_DIRECT_IND Connectable directional ad event
  • ADV_SCAN_IND scannable non-directional advertising event
  • the PDUs are transmitted in a link layer in an advertisement state, and received by a link layer in a scanning state or an initiating state.
  • the advertisement channel PDU type below is called a scanning PDU and is used in the state described below.
  • SCAN_REQ Sent by the link layer in the scanning state, and received by the link layer in the advertisement state.
  • SCAN_RSP transmitted by the link layer in the advertisement state, and received by the link layer in the scanning state.
  • the advertisement channel PDU type below is called an initiating PDU.
  • CONNECT_REQ transmitted by the link layer in the initiating state, and received by the link layer in the advertisement state.
  • the data channel PDU has a 16-bit header, payloads of various sizes, and may include a Message Integrity Check (MIC) field.
  • MIC Message Integrity Check
  • GATT Bluetooth low power energy Generic Attribute Profile
  • GATT Generic Attribute Profile
  • a peripheral device eg, a sensor device
  • GATT server acts as a GATT server, and has definitions of services 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 by the GATT client and 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 form 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 characteristics or other services.
  • Each service has a 16bit or 128bit identifier called UUID (Universal Unique Identifier).
  • the characteristic is the lowest unit in the GATT-based operation structure.
  • the feature contains only one piece of data, and similarly to the service, it has a 16-bit or 128-bit UUID.
  • the characteristic is defined as a value of various types of information, and one attribute is required to contain each information. Several consecutive properties can be used.
  • the attribute is composed of four components and has the following meanings.
  • FIG. 5 is a flowchart illustrating an example of a connection procedure method in 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 referred to as an advertiser before connection, and may be referred to as a master after connection.
  • a sensor such as a temperature sensor
  • the client may be referred to as a scanner before connection, and may be referred to as a slave after connection.
  • An example of a client may be a smart phone.
  • Bluetooth communicates by being divided into a total of 40 channels through the 2.4GHz band.
  • Three of the 40 channels are advertisement channels, and are used for exchange of packets exchanged for establishing a connection, including various advertisement packets.
  • the remaining 37 channels are used for data exchange after connection to the data channel.
  • the client may transmit a scan request message to the server to obtain additional data (eg, server device name) to the server.
  • additional data eg, server device name
  • the server transmits a scan response message including additional data to the client in response to a scan request message.
  • the scan request message and the scan response message are one end of the advertisement packet, and the advertisement packet may include only user data of 31 bytes or less.
  • the data is divided and sent 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).
  • LL Link Layer
  • the server and the client perform a security establishment procedure.
  • the security establishment procedure may be interpreted as or performed by including secure simple pairing.
  • 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 transmits a pairing request message to the server, and the server transmits 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-bits temporary key and a short term key (STK) for performing legacy pairing are generated.
  • STK Short Term Key
  • LTK Long Term Key
  • LTK Long Term Key
  • phase 3 a key distribution procedure between the server and the client is performed (S5050).
  • audio streaming data or audio data is periodically generated at an idle event interval.
  • Audio data occurs periodically (or at specific time intervals) depending on its characteristics.
  • a specific time interval in which audio data is periodically generated 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 the entire period or a partial period of the Idle Event Interval.
  • an advertisement and scanning procedure, a communication procedure, a disconnection procedure, and the like must be performed whenever the generated audio data is transmitted/received.
  • audio data is generally generated periodically, and a latency guarantee for audio data transmission is essential regardless of the amount of data.
  • Audio data transmission through Hearing Aids (HA) or headsets, etc. has a relatively small amount of data, so if BLE technology is used than Bluetooth BR/EDR technology, higher energy efficiency can be obtained. Since the Data Channel Process of the data transmission has to perform advertising, connection, etc. for each data transmission, it has a large overhead in data transmission, and in particular, it is impossible to guarantee an absolutely necessary Latency Guarantee for audio data transmission. .
  • the Data Channel Process of BLE technology transmits data that is generated only when it is necessary, and in other time domains, it has the purpose of inducing Deep Sleep of BLE devices to increase energy efficiency. It may be difficult to apply the Data Channel Process of BLE technology for the transmission of
  • BLE was difficult to transmit an audio signal because the link layer operation for transmitting an audio signal was not defined. Even if an audio signal is transmitted, a user device (for example, a headset, a phone, etc.) receives the audio signal. A procedure for finding a device capable of processing and transmitting it to a target device needs to be defined.
  • the present invention provides a procedure for the user device to recognize devices capable of recognizing and processing the user's audio signal and to transmit the processed audio signal to the target device in order to control devices with the user's voice.
  • audio data will be unified and used.
  • a new channel that is, an isochronous channel.
  • Isochronous Channel is a channel used to transmit isochronous data between devices using an isochronous stream (eg, Conductor-Member).
  • an isochronous stream eg, Conductor-Member
  • Isochronous data refers to data that is transmitted periodically or regularly at specific time intervals.
  • an isochronous channel may represent a channel through which periodically generated data such as audio data or voice data is transmitted and received in BLE technology.
  • the isochronous channel may be used to transmit/receive audio data to a single member, a set of one or more coordinated members, or a plurality of 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.
  • Methods using an isochronous channel to be described below operate independently from the Advertising Channel and Data Channel used in the existing (v4.2 or less) BLE technology.
  • a new frequency channel and a frequency hopping interval for an isochronous channel may be additionally defined.
  • the isochronous channel enables transmission of an isochronous stream, such as flushable data (e.g. time-bound audio data), from a conductor to one or more members using BLE.
  • flushable data e.g. time-bound audio data
  • conductor can be expressed as master and member can be expressed as slave.
  • the isochronous channel may be secured or may not be secured.
  • isochronous channels can be synchronized between a single conductor and members, a single conductor and a coordinated pair of members that make stereo audio, such as hearing aids or stereo headsets, a single conductor and multiple synchronized stream(s) of the same isochronous stream. It can be set up in various topologies to allow the transmission of an isochronous stream between members of.
  • the member may transmit data to the conductor through the same isochronous channel.
  • the isochronous channel may support personal audio as well as transmission and reception of shared audio, public audio, and broadcast audio.
  • the setup procedure of the isochronous channel requires that the hierarchy of profile level security and reliability requirements satisfy different use cases.
  • the isochronous channel can be used for various applications, whereby a number of source devices and sinks can be configured, and complex topologies to allow users to regularly change or share different audio streams can be configured. have.
  • FIG. 7 shows an example of a home ecosystem for applications in which an isochronous channel can 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 the present specification can be applied can move in/out of each other's area.
  • the presence of various conductors and members may mean that an isochronous channel is required as a method for notifying the existence of a member so that the member can obtain necessary information to set the isochronous channel. have.
  • the isochronous channel can also be used for transmission and reception of non audio data.
  • a member may use isochronous channels to determine whether there are notification messages that may include information obtained from conductors within BLE communication range.
  • a member may use isochronous channels to receive requests for control information or service data from one or more devices acting like a remote controller.
  • 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 more advanced user cases can be developed.
  • GAM can provide a smooth audio service to users even in dynamic and multi-profile environments. Because middleware can handle audio mixing of various user cases and switching between user cases, each profile can focus on a specific function.
  • GAM can support multiple profiles, users can choose between a range of audio content and an application that can seamlessly move between voice-activated devices.
  • GAM defines announcements for audio streaming, signal transmission for audio control and data transmission.
  • the application layer defines application signaling and necessary transport parameters.
  • a user wants to receive audio data broadcast from a nearby device through a Bluetooth low energy (BLE) audio streaming service
  • the user's device receives synchronization information (sync information) from nearby devices.
  • audio data is received without a separate filtering process.
  • a specific device that transmits audio data desired to be received by a user from among a plurality of devices searched using the UI must be directly selected. Therefore, when audio data is immediately listened to without filtering, there is an inconvenience of receiving audio data that the user does not want.
  • a user uses a UI mounted on a device, there is an inconvenience in that the user must perform a separate operation to receive audio data.
  • a device that transmits audio data may be expressed as a server, a server device, or an initiator.
  • the user's device receiving audio data may be represented by 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.
  • FIG. 9(a) shows a flowchart of an operation performed in a server device.
  • the server device transmits synchronization information to a peripheral device (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.
  • the server device may periodically repeatedly perform the operations S911 to S912.
  • FIG. 9(b) shows a flowchart of an operation performed in a client device without a UI.
  • the client device receives synchronization information from a device transmitting 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.
  • FIG. 9(c) shows a flowchart of an operation performed in a client device equipped with a UI.
  • 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 around the client device a plurality of devices that transmit audio data may be searched on the display of the client device.
  • the client device receives audio data from the server device (S933).
  • FIG. 10 is a diagram illustrating a problem in a case where a plurality of server devices exist around a client device.
  • 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.
  • 11 is a diagram showing an example of a method of transmitting a periodic advertisement message using Bluetooth low power.
  • the server device transmits an extended advertising message including an Aux_Ext_indication type advertisement PDU through a primary physical advertising channel (1101).
  • the primary physical advertisement channel may be channels 37 to 39, and the advertisement message may include channel information through which an extended advertisement message is transmitted.
  • the extended advertisement message may include at least one of AdvA, ADI, Aux Ptr, ADId, Ch#_Aux_Adv, and Offset fields based on an event type related to transmission of the extended advertisement message.
  • the server device transmits an extended advertisement message including an advertisement PDU of the Aux_Adv_indication type through a secondary physical advertisement channel (1102).
  • the secondary physical advertisement channel may be channels 0 to 36.
  • the client device may receive the extended advertisement message based on the channel information.
  • the extended advertisement message transmitted over the secondary physical advertisement channel may include synchronization information (syncinfo) and the like.
  • the server device periodically transmits the extended advertisement message (1103).
  • the extended advertisement message may include an advertisement PDU of an Aux_Sync_indication type or an advertisement PDU of an Aux_Chain_Indication type, and advertisement data may be included in each of the PDUs.
  • FIG. 12A is a diagram illustrating examples of a PDU format of an advertisement message transmitted from a server device
  • FIG. 12B is a diagram illustrating an example of a transmission timing of an advertisement message.
  • 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.
  • 1202 shows an example of a payload field included in an extended advertisement message.
  • the field includes an extended header length field having a size of 6 bits, an AdvMode field having a size of 2 bits 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.
  • An AdvData field having a size of 0-254 octet including audio data provided through may be included.
  • 1203 denotes an extended header field included in a Payload field of an extended advertisement message.
  • the field includes an extended header flag of 1 octet size, an AdvA field of 6 octet size indicating the address of a device transmitting an advertisement message, a Target A field of 6 octet size, and 2 including data-related information. It includes an octet-sized AdvDataInfo (ADI) field, an 18-octet-sized Syncinfo field including synchronization information, a 1 octet-sized TxPower field indicating transmission power, and an ACAD field having various sizes including audio data.
  • ADI octet-sized AdvDataInfo
  • 1204 indicates an Aux Ptr field included in an extended header field of an extended advertisement message.
  • the field may include a 6-bit channel index field, a 1-bit CA field, a 1-bit Offset Units field, a 13-bit AUX Offset field, and a 3-bit AUX PHY field.
  • 1205 indicates a Syncinfo field included in the extended header field of an extended advertisement message.
  • the field includes a 13-bit Sync Packet Offset field, a 1-bit Offset Unit field, a 2-Octet size Interval field, a 37-bit ChM field, a 3-bit SCA field, a 4-bit AA field, and 3 octet.
  • a CRCInit field of size and an Event Counter field of 2 octet size may be included.
  • the server device periodically transmits an advertisement message including an ADV_EXT_IND type advertisement PDU with an offset of a predetermined value.
  • the server device periodically transmits an advertisement message including an advertisement PDU of the AUX_SYNC_IND type for synchronization between the server device and the client device at an interval of a predetermined value.
  • the server device transmits a periodic advertisement message. More specifically, (1) the server device first transmits an advertisement message including an advertisement PDU of the ADV_EXT_IND type.
  • the server device transmits an extended advertisement message including an advertisement PDU of the AUX_ADV_IND type.
  • the server device sequentially transmits one extended advertisement message including an AUX_SYNC_IND type advertisement PDU and two extended advertisement messages including an AUX_CHAIN_IND type advertisement PDU.
  • the advertisement messages sequentially transmitted by the server device may be referred to as a periodic advertisement message train.
  • the server device repeats the processes (1) to (3).
  • the interval corresponds to the periodic advertisement interval.
  • transmitting a specific type of PDU may mean transmitting an advertisement message including a specific type of advertisement PDU.
  • transmitting an AUX_SYNC_IND PDU may mean transmitting an extended advertisement message including an AUX_SYNC_IND type advertisement PDU.
  • FIG. 13 is a diagram illustrating an example in which audio data transmission using Bluetooth low power (BLE) is performed.
  • BLE Bluetooth low power
  • a server device 1310 for transmitting broadcast audio and a client device 1320 for receiving broadcast audio are illustrated.
  • the client device may also be referred to as an acceptor.
  • the server device 1310 is an AUX_ADV_IND type of AUX_ADV_IND type including an advertisement PDU of ADV_EXT_IND type including channel information of an advertisement message expanded through periodic advertising, synchronization information, etc.
  • An extended advertisement message including an advertisement PDU, an extended advertisement message including an advertisement PDU of AUX_SYNC_IND type including audio data, etc. are sequentially transmitted, and the server device 1310 performs the sequential transmission periodically.
  • the client device 1320 may scan extended advertisement messages transmitted from the server device to obtain information related to synchronization.
  • the client device 1320 which has obtained the synchronization information, transmits a report that a synchronization signal has been received from the link layer of the client 1320 device to the host, and the host is a periodic advertisement message transmitted by the server device 1310.
  • the synchronization between the and the client device is enabled (S1303).
  • the client device 1320 receives audio data from the server device 1310 based on Broadcast Isochronous Group (BIG) INFO information included in the AUX_SYNC_IND type advertisement PDU (S1305-S1310).
  • BIG Broadcast Isochronous Group
  • a user of the client device 1320 may listen to audio based on the received audio data.
  • the client device 1320 may output an audible signal related to the received audio data.
  • the client device 1320 is a device such as a smart phone equipped with a UI
  • the client device 1320 obtains synchronization information and then receives audio data without performing a separate procedure such as filtering.
  • the client device 1320 outputs a list of devices that have transmitted the audio data to the user, and allows the user to select the audio data. This may cause inconvenience, such as causing a device user to unnecessarily listen to an auditory signal.
  • FIG. 14 shows a configuration procedure performed by a client device and a server device to transmit and receive Bluetooth audio data.
  • Initiator may mean a server device, and Acceptor may mean a client device.
  • the server device starts setting for the broadcast mode in an idle state (S1411).
  • the server device sets a periodic advertisement mode (S1421). In this mode, the server device can transmit an advertisement message on the primary advertisement physical channel.
  • the server device sets a periodic synchronization mode (S1431). In this mode, the server device may periodically transmit synchronization information over the secondary advertisement physical channel.
  • the server device completes the setting for transmitting audio data by performing steps S1411 to S1431 (S1441).
  • the client device starts an observation procedure in an idle state (S1412).
  • the client device receives the extended advertisement message from the server device, and the link layer of the client transmits the extended advertisement report event to the ASCP (S1422).
  • the client device sets a periodic advertisement synchronization mode (S1431).
  • the client device receives synchronization information included in the periodic advertisement message and transmitted from the server device in the periodic advertisement synchronization mode, and the link layer of the client device transmits the periodic advertisement report event to the ASCP (S1441).
  • the client device completes the setting for receiving audio data by performing steps S1412 to S1442 (S1452).
  • FIG. 15 shows an enable procedure performed by a client device and a server device to transmit and receive Bluetooth audio data.
  • Initiator may mean a server device, and Acceptor may mean a client device.
  • the server device starts setting for a broadcast isochronous broadcasting mode (S1511).
  • the server device can transmit BIS (Broadcast Isochronous Stream) data of BIG (Broadcast Isochronous Group).
  • the server device sets the broadcast isochronous synchronization mode (S1521).
  • the server device may periodically transmit broadcast isochronous synchronization information.
  • Enabling audio may mean enabling the transmission of audio data.
  • the server device starts streaming audio data (S1541).
  • the client device sets the broadcast isochronous synchronization mode (S1512).
  • the client device starts streaming audio data (S1522).
  • 16 shows an example of a method of transmitting audio data using Bluetooth low power.
  • the server device transmits an extended advertising message including an Aux_Ext_indication type advertisement PDU through a primary physical advertising channel (1601).
  • the primary physical advertisement channel may be channels 37 to 39, and the advertisement message may include channel information through which an extended advertisement message is transmitted.
  • the extended advertisement message may include at least one of AdvA, ADI, Aux Ptr, ADId, Ch#_Aux_Adv, and Offset fields based on an event type related to transmission of the extended advertisement message.
  • the server device transmits an extended advertisement message including an advertisement PDU of the Aux_Adv_indication type through a secondary physical advertisement channel (1602).
  • the secondary physical advertisement channel may be channels 0 to 36.
  • the client device may receive the extended advertisement message based on the channel information.
  • the extended advertisement message transmitted over the secondary physical advertisement channel may include synchronization information (syncinfo) and the like.
  • the server device periodically transmits the extended advertisement message (1603).
  • the extended advertisement message may include an advertisement PDU of the Aux_Sync_indication type.
  • the advertisement PDU may include at least one of Aux Ptr, ACAD, ADATA Ch#_Aux_chain, offset BIGInfo (ACAD), and Metadata (ADATA) fields, and may include advertisement data (Advdata).
  • the server device may transmit a BIS data packet 1604 including audio data and a control packet 1606 including control information for providing an audio streaming service.
  • the BIS data packet and control packet may be periodically transmitted through an isochronous channel.
  • a periodic advertising sync transfer (PAST) method may be used.
  • the PAST method is a method that can be applied to a periodic advertisement transmission method. Through this method, when the server device provides synchronization information (SyncInfo) to the client device, advertisement data can be obtained while performing frequency hopping on the secondary channel without receiving the client device Adv_Ext_Indication PDU and Aux_Adv_Indication PDU.
  • Synchronization information Synchronization information
  • the PAST method can also be applied to a method of transmitting audio data using Bluetooth low power (broadcast audio).
  • SyncInfo in the periodic advertisement transmission method may correspond to BIGInfo in broadcast audio.
  • the client device may receive audio data while performing frequency hopping in the secondary channel without receiving the Adv_Ext_Indication PDU, Aux_Adv_Indication PDU, and Aux_sync_Indication PDU.
  • the server device delivers a general announcement to the client device.
  • the general announcement may be an advertisement message.
  • the client device parses BIGINFO in the general announcement. Thereafter, the client device may receive broadcast audio data from the server device based on the parsed BIGINFO.
  • the client device may be a headphone or the like, and the server device may be a TV or the like.
  • the client device may receive BIG INFO related to audio data transmitted by the server device from a third device (commander).
  • a third device commander
  • an operation in which the client device receives BIG INFO from the third device may be expressed as a scan of floaing.
  • the third device receives a general Announcement from the client device.
  • the general announcement may be an advertisement message.
  • the third device establishes a connection with the client device.
  • the third device transmits BIGINFO of the server device to the client device.
  • the client device may be a headphone or the like
  • the server device may be a TV or the like
  • the third device may be a smartphone or the like.
  • the client device may establish a connection with the server device, and receive BIG INFO related to audio data transmitted by the server device directly from the server device.
  • the client device delivers a general announcement to the server device.
  • the general announcement may be an advertisement message.
  • the client device and the server device establish a connection.
  • the server device transmits BIGINFO of the server device to the client device.
  • 17 is a diagram illustrating an example of a method of transmitting audio data using Bluetooth low power.
  • the server device 1410 broadcasts broadcast synchronization information to nearby devices (1420). More specifically, the server device may sequentially transmit Adv_Ext_Indication PDU, Aux_Adv_Indication PDU, and Aux_Sync_Indication PDU.
  • the Aux_Sync_Indication PDU may include BIGINFO and Metadata.
  • the BIGINFO may be the synchronization information for the client device to receive audio data.
  • the server device periodically transmits broadcast audio data (1430).
  • the broadcast audio data may be included in BIS_Data_Packet and transmitted.
  • the client device may acquire the audio data based on timing information and frequency hopping algorithm information included in BIGINFO.
  • FIG. 18 is a diagram illustrating an example of fields (octets) included in BIGINFO.
  • octet of BIGINFO corresponds to BIG offset
  • 3-14 octet corresponds to BIG parameter
  • 15-18 octet corresponds to SeedAccessAddress.
  • octet 19-20 corresponds to BaseCRCInit
  • octet 21-25 corresponds to SDU_config
  • octet 26-30 corresponds to bisPayloadCounter. Fields included in 1-30 octet can be included in BIGINFO.
  • 31-54 Octet corresponds to BIG_Encryption, but the field is not necessarily included.
  • 19 is a diagram illustrating an example of a ⁇ BIG parameter field and an SDU_Config field showing an example of a specific field included in BIG synchronization information.
  • the BIG parameter field is
  • the BIG parameter (Cont) field is a BIS_Spacing (20 bits) field indicating a BIS anchor spacing, an NSE (5 bits) field, a BN (3 bits) field, a PTO (pretransmission offset) (4 bits) field, an IRC (ImmediateRepetitionCoun) (4 bits). ) Field and a PHYPHY (8 bits) field.
  • the SDU_Config parameter field may include an ISOAL_PDU_Type (1 bit) field indicating one of frame/unframed, an RFU (7 bits) field, a Max_SDU_Size (12 bits) SDU_Interval (20 bits) field indicating an SDU interval (1msec ⁇ 1.048575sec). have.
  • 20 is a diagram showing 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 mainly be a transmission device, a smartphone, or a TV.
  • the client device may be an audio transmission setting target device, and may mainly be a receiving device, a speaker, or an earphone (Earbud).
  • the server device periodically transmits BLE audio broadcast packets 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, the client device receives information on audio data related to a specific program provided by the server device. Next, the client device outputs the audio data to the user, and when receiving an input to listen to the broadcasting from the user, receives and decodes the audio data broadcast stream. In this case, the user's input may be pressing a button mounted on the client device or nodding his head.
  • 21 is a diagram showing an example in which the method proposed in the present specification is performed.
  • an advertisement packet may be scanned in a user assistance device.
  • the user assistance device may be a smartphone or the like.
  • the user auxiliary device receives synchronization information from the server device and transmits the synchronization information to the client device so that the client device can receive broadcasting data sent from the server device.
  • the client device Upon receiving the synchronization information from the user auxiliary device, the client device directly receives and decodes the audio data broadcast information from the server device.
  • the client device and the user auxiliary device are connected in the same way as the existing wireless connection method, and 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.
  • the present method relates to a method of providing information on audio data of a specific program provided by a server device. It goes without saying that the information on the audio data of the specific program may be expressed as audio data information or program information, and may be referred to as various expressions that can be interpreted similarly.
  • Audio data of a specific program may be included in an extended advertisement message including an advertisement PDU of the Aux_Sync_Indication type and transmitted. More specifically.
  • the audio data of the specific program may be included in the meta data field of the advertisement PDU of the Aux_Sync_Indication type.
  • audio data of a specific program may be expressed as broadcast audio, and information on audio data may be expressed in terms that can be interpreted similarly to audio data information or program information. .
  • the present proposal relates to a method of including audio data information in the form of a TV program (or channel) title in the metadata field.
  • Meta data for the BIG stream including audio data is included in the meta data field of the Aux_Sync_Indication PDU.
  • the meta data field may be defined in an upper layer profile.
  • the meta data field is located in the AdvData field of the Aux_Sync_Indication PDU and may have a size of 0 to 254 octet.
  • the user may determine whether to listen to audio data related to a specific program provided by the server device based on the metadata field included in the Aux_Sync_Indication PDU.
  • the client device may output audio data information included in the meta data field included in the synchronization information to the user.
  • the user may determine whether to listen to audio data for a specific program provided by the server device based on the output audio data information.
  • the user can perform a specific input to the client device.
  • the input may be a push of a button on a smartphone or headphones, or moving the headphones up and down.
  • Aux_Sync_Indication is a unit corresponding to BIG (Broadcast Isochronous Group), so the BIG range can be regarded as a program.
  • the server device transmits a specific program (broadcast) through BT Broadcast
  • the client device may obtain audio data information from Program Specific Information Protocol (PSIP) information.
  • PSIP Program Specific Information Protocol
  • the server device may directly set the program title.
  • This proposal relates to a method of including audio data information in the meta data field in the form of a multi-language stream.
  • a multi-language stream may be included in one Broadcast Isochronous Group (BIG).
  • BIG Broadcast Isochronous Group
  • a language code of each stream may be notified so that only a stream of a specific language can be received and decoded.
  • Multi_Language_Information may be added to BIG_Description.
  • the metadata field may include a UUID_Multi_Language_Information (16bit) field, a length (8bit) field, and a value (254-BIG_Description) field in order.
  • BISs included in the Value field may be included in language-codes in order from BIS 0 stream.
  • BIS stream 0 may be English
  • BIS stream 1 may be Korean
  • BIS stream 2 may be French.
  • the Length field may be input as 9 bytes (3x3 bytes)
  • the Value field may be input as ENG, KOR, or FRE.
  • the multi-language stream may be transmitted on a multi-channel (Multi-Channel).
  • Language and channel values may be included in order from BIS stream 0.
  • Channel (location) may be of an enumeration type. That is, 0: mono, 1: left, 2: right, 3: center, 4: rear left, 5: rear right, 6: base woofer.
  • BIS No. 0 stream English-Left stereo
  • BIS No. 1 stream English-Right stereo
  • BIS No. 2 stream Korean mono
  • BIS No. 3 stream French mono
  • the Length field is 12 bytes (4x3 byte) It is a size
  • ENG1, ENG2, KOR0, and FRE0 may be input in the Value field.
  • the present proposal relates to a method of including audio data information in the form of an audio stream in a meta data field rather than including audio data information in the form of text.
  • the audio data information may be a program title of a specific program provided by the server device.
  • the user When the audio data information is included in the metadata in the form of text, the user must perform a procedure for selecting audio data by using a device equipped with a UI.
  • the client device can check the audio data information and immediately output it to the user, so that the user can easily determine whether to receive the audio data.
  • the BIS stream in which audio data information in the form of an audio stream is transmitted may be limited to the BIS 0 stream.
  • PTA Program Title Audio
  • PTA Program Title Audio
  • Audio data information in the form of text may be converted into audio data information in the form of an audio stream by a third device such as a server device or a smart phone through a text to speech (TTS) technique.
  • the converted audio data information may be provided to the client device.
  • audio data information in the form of an audio stream may be generated by uploading an arbitrary audio. Audio data information in the form of the generated audio stream may be a short audio stream of about 2 to 3 seconds. Background music/effects as well as voices may be added to the audio data information.
  • the metadata field may include a UUID_Multi_Language_Information (16bit) field, a length (8bit) field, and a value (254-BIG_Description) field in order.
  • BISs included in the Value field may be included in language-codes in order from BIS 0 stream.
  • BIS 0 stream Program title audio
  • BIS 1 stream English
  • BIS 2 stream Korean
  • BIS 3 stream French
  • the Length field may have a size of 12 bytes
  • PTA, ENG, KOR, and FRE may be input in the Value field.
  • 22 is a diagram illustrating an example in which a method for transmitting audio data based on audio data information proposed in the present specification is performed.
  • FIG. 22 illustrates a process in which a client device receives audio data transmitted from a server device.
  • the server device broadcasts synchronization information (2210).
  • the synchronization information may be included in the extended advertisement message and transmitted. More specifically, in order to transmit synchronization information, the server device may sequentially transmit an Aux_Ext_Indication PDU and an Aux_Adv_Indication PDU. “The server device sequentially transmits the Aux_Ext_Indication PDU and the Aux_Adv_Indication PDU” may mean “the server device transmits synchronization information”.
  • the server device may transmit indication information indicating that the audio data information is included with the audio data in the broadcast audio data together to the client device.
  • the indication information indicating that the audio data information is included in the broadcast audio data together with the audio data may be included in the BIG INFO field included in the advertisement PDU of the Aux_Sync_Indication type.
  • the audio data information is information on audio data of a specific program provided by the server device.
  • the client device receives the audio data information (2220). Thereafter, the client device may decode and output the audio data information in order to allow the user to know which program the server device provides (2231 to 2233).
  • the audio data information may be output in the form of (i) voice or (ii) a mixture of voice and additional sound effects.
  • the client device Before 2233 of FIG. 22, since the user did not input information indicating that the audio data is received, the client device only receives audio data information from among audio data information and audio data included in broadcast audio data to the host of the client device. Deliver. That is, audio data is not delivered to the host.
  • the user inputs information indicating that audio data is received based on the output audio data information (2240).
  • the client device When the client device obtains an input from the user, when the user's input indicates that the audio data is received, the client device receives the audio data transmitted from the server device and transmits the audio data to the host (2250). At this time, audio data information may not be delivered to the host after the time when an input indicating that audio data is received from the user is acquired.
  • the initial state may mean an operating state of the client device before the client device receives an extended advertisement message for providing an audio streaming service from the server device.
  • the client device may scan whether the signal strength of the server device is measured to be more than a specific threshold.
  • the measurement of the signal strength may be performed through measurement of the Aux_Ext packet signal strength of the minimum primary channel.
  • the client device parses the Aux_Ext packet in an observation procedure and transmits a determined extended advertising report event to the host.
  • the BIG may be an identifier assigned to the broadcast audio data.
  • 23 is a diagram illustrating an example of a method of transmitting audio data and audio data information by a server device.
  • FIG. 23 shows examples of multiplexing methods when the server device bundles and transmits audio data information and audio data in BIG.
  • audio data information and audio data are transmitted by one server device, they may be included in the same audio group. Accordingly, audio data and audio data information may be included in one BIG, but audio data and audio data information may be included in different BISs included in the BIG and transmitted. Broadcast audio data that is grouped and transmitted in one data group may be transmitted over an isochronous channel. Grouping different data into a group can be expressed as grouping different data.
  • the client device may decode only BIS1 including audio data information among BIS1 and BIS2 included in the received BIG. That is, since the client device does not acquire input information indicating that the server device receives audio data transmitted from the user, unnecessary resource waste and power consumption are caused when the client device decodes even audio data included in BIS2.
  • the client device when the client device obtains input information indicating that audio data transmitted by the server device is received from the user, the state of the client device is changed from Broadcast Stream-Configure procedure to Broadcast Stream-Enable procedure. Thereafter, the client device may decode both BIS1 and BIS2 included in the received BIG.
  • an indicator flag indicating whether BIS1 includes audio data information may be included in the synchronization information.
  • the indicator flag may also be expressed as indication information.
  • the client device may selectively decode audio data information and audio data included in broadcast audio data transmitted by the server device based on the indicator flag.
  • the server device may sequentially include audio data information and audio data in the BIG (2310). That is, data may be included in the BIG in the order of BIS 1->BIS1->BIS2->BIS2.
  • the server device may alternately include audio data information and audio data in the BIG (2320). That is, data may be included in the BIG in the order of BIS1->BIS2->BIS3->BIS4.
  • 24 is a diagram illustrating an example of a method for a server device to transmit audio data and audio data information.
  • FIG. 24 shows an example in which a server device includes audio data information in Aux_adv_indication and transmits it to a client device. That is, the server device includes audio data information in the Aux_adv_indication PDU, and the audio data is included in the Aux_Sync_indication PDU or Aux_Chain_indication PDU.
  • the server device may sequentially transmit the (i) Aux_adv_indication PDU and (ii) Aux_Sync_indication PDU or Aux_Chain_indication PDU.
  • the Aux_adv_indication PDU may be transmitted on the primary physical advertisement channel
  • the Aux_Sync_indication PDU or Aux_Chain_indication PDU may be transmitted on the secondary physical advertisement channel.
  • Audio data information may be included in the ADATA field included in the Aux_Adv_Indication packet. If the storage space of the ADATA field is insufficient to include audio data information, the remaining data of the audio data information will be included in the next transmitted Aux_Chain_indication packet. I can.
  • the server device may include an indicator flag indicating that the Aux_Adv_Indication PDU contains audio data information in the Aux_Adv_Indication PDU.
  • the client device may recognize that audio data information is included in the Aux_Adv_Indication PDU based on the indicator flag.
  • the client device may decode and play the audio data information included in the ADATA field of the Aux_Adv_Indication packet.
  • the output audio data information may be set to a short time length of several seconds.
  • the user may listen to voice data information output from the client device and input information indicating that audio data is received.
  • the state of the client device is changed from Broadcast Streaming-Configuration procedure state to Broadcast Streaming-Enable procedure state.
  • the client device receives and decodes the audio data included in Aux_Sync_indication (and Aux_Chain_Indication after that).
  • 25 is a diagram illustrating an example in which a method for transmitting audio data based on audio data information proposed in the present specification is performed.
  • FIG. 25 is an example of a process in which a client device receives audio data transmitted from a plurality of server devices.
  • the client device searches for multiple broadcast audio data transmitted by multiple server devices.
  • the client device when a user selects only one audio data among audio data transmitted from a plurality of server devices, the client device outputs audio data information corresponding to the plurality of received audio data at different times. can do.
  • the user inputs information indicating that specific audio data will be received among audio data information output at different times. Thereafter, the user can listen to the selected audio data.
  • the user may not select any audio data among audio data transmitted by the plurality of server devices.
  • the client device may limit the number of times the audio data information related to each audio data is repeatedly output. The number of repetitions may be limited to approximately 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
  • 26 and 27 are diagrams illustrating an example of a method for a client device to set audio data information in a server device.
  • this method proposes a method of configuring the upload GATT service and changing the audio feedback information stored in the server device using the GATT service.
  • the GATT client receives an advertisement packet from the GATT server (server device) (S2610), and the GATT client establishes a connection with the GATT server (S2620).
  • the GATT client transmits to the server device a read request message requesting to read the status information of the audio data 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 (S2630).
  • the state information may include at least one of name information of the audio data, date information in which the audio data information is stored in the first specific characteristic, or version information of the audio data information. I can.
  • the GATT client requests the GATT server to write a characteristic value related to the changed audio feedback information in the second specific characteristic of the server device in order to change the audio feedback information based on the status information.
  • the message is transmitted (S2640).
  • the write request message may include some data of 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.
  • Characteristic MTU size is about 21 ⁇ 255 bytes, and it may be difficult to transmit a file with one characteristic write. Accordingly, the characteristic write may be transmitted multiple times, and for this purpose, a sequence number is applied to the header of each of a plurality of data constituting the audio feedback information and transmitted.
  • 28 and 29 are diagrams illustrating an example of a method for a management server device to provide synchronization information of server devices to a client device.
  • the management server device may each receive synchronization information from neighboring server devices (Broadcast Advertisers).
  • the management server device may transmit the received broadcast synchronization information of neighboring server devices to another broadcast scanner device (client device). In this way, the burden of the client device performing multiple scans to synchronize with multiple server devices can be reduced. This method can be expressed as “Scan Offloading”.
  • the client device may receive audio data information from each server 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.
  • total synchronization information including synchronization information of all server devices transmitted from the management server device to the client device may be transmitted through a separate broadcast channel for voice data transmission.
  • the client device receives all synchronization information from the management server through a separate broadcast channel (S2910).
  • the client device receives audio data from nearby server devices based on the total synchronization information (S2920).
  • Bluetooth bonding refers to a method of storing (caching) the encryption key used for pairing between the Central (master) device and the Peripheral (slave) device, which is convenient when connecting later.
  • the audio feedback information may be considered as data to be frequently used in the BLE Audio Broadcasting environment and stored in advance. Even if there is only one server device, audio feedback information can be stored (cached) for later use in a frequently received environment.
  • FIG. 30 shows examples in which a method of receiving audio data is performed using the Bluetooth technology proposed in the present specification.
  • FIG. 30A corresponds to an example in which a plurality of client devices receive broadcast audio data transmitted by one server device. This method can be applied even when a plurality of client devices receive broadcast audio data transmitted by one server device.
  • FIG. 30B corresponds to an example in which a plurality of client devices receive broadcast audio data transmitted from a plurality of server devices. This method can be applied even when a plurality of client devices receive broadcast audio data transmitted by a plurality of server devices as described above.
  • 31 shows an example in which a method of receiving audio data is performed using the Bluetooth technology proposed in the present specification.
  • FIG. 31 relates to a case where a server device receives broadcast audio data being broadcasted by a TV (server device) installed at an airport.
  • audio data information which is information on audio data being broadcast by the server device, may be transmitted in various languages.
  • a desired language may be preset in the client device, and in this case, the client device may receive only audio data information generated in the same language as the set language.
  • 32 is a diagram showing an example of an operation implemented in a client device for receiving audio data using the Bluetooth technology proposed in the present specification.
  • the method performed by a client device includes information for the client device to provide an audio streaming service.
  • a first advertisement message including a is received from the server device (S3210).
  • the client device receives a second advertisement message including synchronization information for synchronization between the client device and the server device from the server device (S3220).
  • the synchronization information may include timing information of the broadcast audio data and frequency hopping information for reception of the audio data.
  • the client device receives, from the server device, a third advertisement message including an indicator indicating that audio data of the audio streaming service is grouped and transmitted with audio data information about the audio data (S3230).
  • the client device receives the audio data grouped through an isochronous channel based on the indicator and broadcast audio data including the audio data information from the server device (S3240).
  • a grouping ID (identifier) for identifying the broadcast audio data is assigned to the broadcast audio data
  • an audio data ID for identifying the audio data is assigned to the audio data
  • the audio data information is identified.
  • An audio data ID to be used may be assigned to the audio data information.
  • the audio data and the audio data information may be interleaved and grouped.
  • the audio data may be audio data related to a specific program provided by the server device, and the audio data information may indicate a title of the specific program.
  • 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 data information (S3250).
  • the client device decodes the audio data (S3260).
  • the client device may decode the audio data information.
  • the client device may decode the audio data information.
  • only the audio data information among the audio data and the audio data information may be decoded.
  • the client device may output the decoded audio data information.
  • the client device establishes a connection with the server device, and sends a read request message to the server device for requesting to read status information of the audio data information stored in a first characteristic of the server device. Can be transmitted.
  • the state 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 client device may receive a read response message including the status information from the server device.
  • the client device sends a write request message requesting to write a characteristic value related to the changed audio data information in a second specific characteristic of the server device in order to change the audio data information based on the state information. It can be transmitted to the server device.
  • the write request message may include some data of data constituting the changed audio data information.
  • the client device 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 on the partial data.
  • the client device may receive total synchronization information related to synchronization between the plurality of server devices and the client device from a management server that manages a plurality of server devices including the server device.
  • the total synchronization information may include synchronization information for each of the plurality of server devices.
  • synchronization information for each of the plurality of server devices may be previously stored in the management server.
  • the client device may measure the received signal strength of the first advertisement message.
  • the client device may decode the first advertisement message when the received signal strength of the first advertisement message is greater than or equal to a specific threshold value.
  • the broadcast TV profile provides metadata and procedures for broadcast TV initiators and acceptors. This profile is based on ASCP, and defines broadcast metadata when an initiator announcing itself to nearby acceptors. Initiator may be a server device, and Acceptor may be a client device.
  • 33 is a diagram showing a hierarchical structure of a broadcast profile.
  • broadcast TV as an initiator can transmit data and the like in a broadcast manner.
  • Acceptors which are external devices, can receive this and communicate with the initiator in a unicast manner.
  • the broadcast TV profile is compatible with the Milan version of the Bluetooth standard, which supports isochronous channels.
  • the field value is set to 0, not otherwise specified.
  • the field may not be ignored or interpreted by the device that has received the field unless otherwise described.
  • the unassigned value may be displayed as "Prohibited". These values are not used by the implementation, and received messages containing a value indicating Prohibited are ignored and not processed, and the device receiving them MUST NOT respond to them.
  • a field, parameter, or other variable object can have a range of values and some values indicate "forbidden", then the device MUST NOT set the object to prohibited values. Devices that receive an object with such a value reject it, and all data structures containing it must be considered invalid.
  • FIG. 34 two roles of a broadcast TV initiator and a broadcast TV acceptor are defined.
  • Broadcast TV initiator refers to a device that broadcasts program information metadata.
  • Broadcast TV Acceptor refers to a device that scans program information metadata through periodic advertising and uses it to receive broadcast streams.
  • the broadcast TV initiator is a broadcaster (core specification Vol3, Part C, GAP, 2.2.2.1), and the broadcast TV Acceptor may be an observer. (core specification Vol3, Part C, GAP, 2.2.2.2)
  • the topology of the broadcast TV profile can be applied only to LE audio broadcast. In addition, there are no concurrency restrictions or restrictions on the broadcast TV initiator or broadcast TV acceptor imposed by the profile.
  • TVs are available in many public areas, including gyms, buses, shops, airports and cafeterias. TVs that exist in public places are generally provided muted. Accordingly, the user can listen to audio data related to a pro program to be viewed through LE audio broadcast provided in this profile.
  • the LE audio broadcast scenario is outlined in HA and HQA FRD.
  • information on a broadcast program for identifying a program being broadcast on the TV may be required. That is, audio data information related to audio of a broadcast program may be required.
  • the user can identify the broadcast program by an Acceptor such as a smartphone, headphones or speaker.
  • the Acceptor can consequently inform the user of the program available in LE audio broadcast.
  • the scenario to which the broadcast TV audio profile is applied may be applied to a public scenario in which a user can only receive a notification about a TV program. That is, in a scenario in which the broadcast TV audio profile is applied, the user cannot generally change the channel. Therefore, in a scenario in which a user can remotely change a channel provided on a TV, it may be difficult to apply a broadcast TV audio profile.
  • 35 shows an example of a scenario to which a broadcast TV audio profile can be applied.
  • the initiator 3510 broadcasts signals and data.
  • the initiator may be a TV or the like.
  • the signal may be periodic information (BigInfo) and program description (Program Info) for tuning a program.
  • the data may be actual audio data carrying audio related to a TV program.
  • the acceptor 3520 an interaction between the acceptor and the user occurs. That is, the user can search for a TV program by looking at the Acceptor's display.
  • the Acceptor may be a smartphone.
  • the user can listen to the audio data received by the acceptor through the headset 3530 connected to the acceptor by wire.
  • the existing acceptor only displays a list of searched initiators, but does not display information on programs being broadcast by each initiator. That is, the existing Acceptor displays only the name of the searched initiator (eg, LG-TV or Sony-TV) to the user. If there is only one initiator, it does not cause inconvenience to the user. However, if there are multiple initiators, it may be difficult for the user to listen to the audio data he or she wishes to listen to.
  • the existing acceptor only displays a list of searched initiators, but does not display information on programs being broadcast by each initiator. That is, the existing Acceptor displays only the name of the searched initiator (eg, LG-TV or Sony-TV) to the user. If there is only one initiator, it does not cause inconvenience to the user. However, if there are multiple initiators, it may be difficult for the user to listen to the audio data he or she wishes to listen to.
  • the Acceptor may inform the user of the information on the program being broadcast by the initiator to the user based on the program information metadata. For example, if the Acceptor is a smart phone, it is possible to display a program currently being broadcast to the user through the UI of the smart phone. If the device does not have a UI, program information may be notified to the user through a method of outputting a voice. Accordingly, the user can easily find a TV that is broadcasting a program he or she wants to watch. In addition, even if only one TV, which is an initiator, exists, it is natural that TV program information can be usefully used by the user. In addition, after the acceptor finishes synchronizing with the initiator, if audio data is immediately output without the user's choice of whether to receive program-related audio data, the user may experience inconvenience by listening to unwanted audio data.
  • 36 shows an example in which an initiator informs a user of information on a program being broadcast based on program information.
  • FIG. 37 shows another example of a scenario to which a broadcast TV audio profile can be applied.
  • the initiator 3710 broadcasts signals and data.
  • the initiator may be a TV or the like.
  • a user has to find a TV app or navigate a menu and select a TV program through a smart phone.
  • the smartphone may be equipped with an existing display and touch UI interface.
  • the headphones Users can hear the voice (or sound) through the headphones.
  • the user can listen to main audio data for a program by clicking program information displayed on the display of the smart phone or clicking a button mounted on the headphones.
  • the headphones may include a click button or a motion sensor for detecting an operation of turning off audio data for a specific program by the user.
  • Headphones can be conceptually identical to one or two earphones, neckbands or earbuds.
  • the smart phone is connected to the headphones by wire.
  • LE broadcast can be applied between an initiator, a TV and a smart phone.
  • the TV can transmit BigInfo and Program Info and actual audio data carrying audio related to the TV program being broadcast to the headphones.
  • the smart phone is wirelessly connected to the headphones through BR/EDR or LE unicast.
  • LE broadcast can be applied between an initiator, a TV and a smart phone.
  • the TV can transmit BigInfo and Program Info and actual audio data carrying audio related to the TV program being broadcast to the headphones.
  • the smartphone receives BigInfo and Program Info from the TV, and transmits synchronization information to the headphones through periodic advertising sync transfer (PAST). This method can be called scan offloading.
  • the headphones can use the synchronization information to receive data from the TV.
  • the headphones can directly receive LE broadcast data from the TV.
  • 39 shows an example of a configuration of a data field included in an extended advertisement PDU.
  • 39(a) shows an example of an extended header field included in a payload field of an extended advertisement PDU.
  • the field includes an extended header flag of 1 octet size, an AdvA field of 6 octet size indicating the address of a device transmitting an advertisement message, a Target A field of 6 octet size, and 2 including data-related information. It includes an octet-sized AdvDataInfo (ADI) field, an 18-octet-sized Syncinfo field including synchronization information, a 1 octet-sized TxPower field indicating transmission power, and an ACAD field having various sizes including audio data.
  • ADI octet-sized AdvDataInfo
  • the field includes an extended header length field having a size of 6 bits, an AdvMode field having a size of 2 bits 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.
  • An AdvData field having a size of 0-254 octet including audio data provided through may be included.
  • 40 shows an example of a configuration of a data field included in AUX_SYN_IND_PDU.
  • AUX_SYN_IND_PDU includes AdvA, Tartget A, and CTE info fields.
  • O indicates that it can be optionally included
  • X indicates that it is reserved for future use.
  • Broadcast TV Initiator periodically performs broadcast audio announcement.
  • broadcast audio announcement there is metadata for acquiring timing information for tuning a channel, and also there is metadata for program information for describing a TV program itself.
  • Timing information is located in the ACAD field of BIGINFO, and program information is located in the AdvData field like ProgramInfo in the AUX_SYNC_IND packet.
  • the program information may be information that can be recognized by a person who is currently broadcasting the TV.
  • the program information when the TV plays a conventional program such as sports broadcast, weather forecast or news, the program information may be the title of the broadcast program.
  • the program information When the TV is playing a commercial message in a department store, the program information may be a commercial message notification. If the TV plays the arrival/departure information of an airplane at the airport, the information may be for airport notification.
  • ACAD holds BIGInfo, which is defined as a core specification and is used for timing of broadcast streams
  • AdvData holds ProgramInfo, defined here and used to describe broadcast streams.
  • the length of BIGInfo is 33 octets for unencrypted BIG and 57 octets for encrypted BIG. Since the AUX_SYNC_IND packet size is 254, AdvData's ProgramInfo can occupy 254-(33 + 4) for unencrypted BIG.
  • 41 shows an example of a BLE broadcast audio operation.
  • the server device transmits an extended advertising message including an Aux_Ext_indication type advertisement PDU through a primary physical advertising channel.
  • the primary physical advertisement channel may be channels 37 to 39, and the advertisement message may include channel information through which an extended advertisement message is transmitted.
  • the extended advertisement message may include at least one of AdvA, ADI, Aux Ptr, ADId, Ch#_Aux_Adv, and Offset fields based on an event type related to transmission of the extended advertisement message.
  • the server device transmits an extended advertisement message including an advertisement PDU of an Aux_Adv_indication type through a secondary physical advertisement channel.
  • the secondary physical advertisement channel may be channels 0 to 36.
  • the extended advertisement message transmitted over the secondary physical advertisement channel may include synchronization information (syncinfo) and the like.
  • the server device periodically transmits the extended advertisement message.
  • the extended advertisement message may include an advertisement PDU of the Aux_Sync_indication type.
  • the advertisement PDU may include at least one of Aux Ptr, ACAD, ADATA Ch#_Aux_chain, offset BIGInfo (ACAD), and Metadata (ADATA) fields, and may include an advertisement data (Advdata) field.
  • the advertisement data field may include program information.
  • the server device may transmit a BIS data packet including audio data and a control packet including control information for providing an audio streaming service.
  • the BIS data packet and control packet may be periodically transmitted through an isochronous channel.
  • the user may determine whether to receive audio data included in the BIS data packet based on the program information.
  • EPG Electronic Program Guide
  • ProgramInfo metadata used in the TV broadcast profile may be current program information extracted from EPG data.
  • ProgramInfo may be changed accordingly.
  • Text metadata can mainly be decoded on a smart phone that can use the on-screen UI.
  • ISO_639_language_code is repeated as ProgramInfo Text according to the Laguge count.
  • Option2> Use the entire string such as "ISO-8859-1". This option takes up a lot of space.
  • Option3> only 2 sets are allowed. Use ISO-8859-1 for Western languages and other languages for UTF-8.
  • scenario B where the smartphone and headphones are connected by wire, the user can listen to the audio (or sound) program information on the headphones, and can select a TV program directly by clicking a button or turning off the head.
  • All UI actions take place on headphones that cannot use the on-screen UI.
  • the headphone UI for selecting multiple languages is limited, so only one of the most preferred language program information is recommended.
  • Two approaches can be used to provide audio program information to the user.
  • audio information may be prepared in an Acceptor by using text information and by TTS (Text to Speech).
  • TTS Text to Speech
  • ProgramInfo text can be done on a smartphone, or it can generate TTS audio sound on its own if the headphones have enough performance to make TTS.
  • audio information is prepared in the initiator by the TTS using text information or its own audio generation mechanism.
  • the ProgramInfo audio metadata BIS may be the BIG's first BIS (BIS number 1) for easy decoding on headphones.
  • each BIS may be advantageous for one BIS to carry the left and right channels in the Broadcast TV Initiator for simple implementation.
  • Each earbud tuned by BIS can extract individual channels.
  • TV audio output is simple mono, and the right channel may be a copy of the left channel audio.
  • the Broadcast TV Initiator can send only one left channel, while the Broadcast TV Acceptor (for two-piece earbuds) copies the left channel to create the right channel.
  • TV program audio provided together with the TV program video may be in multiple languages.
  • the order of BIS of BIG should follow the order of repetition of ProgramInfo Text metadata.
  • the order of text in ProgramInfo in the multilingual part may be as follows.
  • the Broadcast TV Acceptor may stop scanning after a certain time or always perform a scan.
  • an embodiment of the present invention may be implemented by various means, for example, hardware, firmware, software, or a combination thereof.
  • an embodiment of the present invention is one or more 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, etc.
  • 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, etc.
  • an embodiment of the present invention may be implemented in the form of a module, procedure, or function that performs the functions or operations described above.
  • the software code can be stored in a memory and driven by a processor.
  • the memory may be located inside or outside the processor, and may exchange data with the processor through various known means.

Landscapes

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

Abstract

블루투스 저전력(Bluetooth Low Energy) 기술을 이용하여 오디오 데이터를 수신하는 방법을 제공한다. 블루투스 저전력 기술을 이용하여 오디오 데이터를 수신하는 방법은, 오디오 스트리밍 서비스의 제공을 위한 정보를 포함하는 제 1 광고 메시지를 서버 디바이스로부터 수신하고, 상기 클라이언트 디바이스와 상기 서버 디바이스 간의 동기화를 위한 동기화 정보를 포함하는 제 2 광고 메시지를 상기 서버 디바이스로부터 수신하고, 상기 오디오 스트리밍 서비스의 오디오 데이터가 오디오 데이터 정보와 그룹핑되어 전송됨을 나타내는 지시자를 포함하는 제 3 광고 메시지를 상기 서버 디바이스로부터 수신하고, 상기 오디오 데이터 및 상기 오디오 데이터 정보를 포함하는 브로드캐스트 오디오 데이터를 상기 서버 디바이스로부터 수신하고, 상기 오디오 데이터 정보에 기초하여 사용자로부터 상기 오디오 스트리밍 서비스의 제공의 허용 여부와 관련된 특정 정보를 획득하고, 상기 특정 정보가 상기 오디오 데이터의 제공의 허용을 나타내는 경우, 상기 오디오 데이터를 디코딩 하는 것을 특징으로 한다.

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) 기술을 이용하여 오디오 데이터를 수신하는 방법에 있어서, 클라이언트 디바이스에 의해 수행되는 방법은, 오디오 스트리밍 서비스(Audio Streaming Service)의 제공을 위한 정보를 포함하는 제 1 광고 메시지를 서버 디바이스로부터 수신하는 단계; 상기 클라이언트 디바이스와 상기 서버 디바이스 간의 동기화를 위한 동기화 정보를 포함하는 제 2 광고 메시지를 상기 서버 디바이스로부터 수신하는 단계; 상기 오디오 스트리밍 서비스의 오디오 데이터가 상기 오디오 데이터 대한 오디오 데이터 정보와 그룹핑되어 전송됨을 나타내는 지시자를 포함하는 제 3 광고 메시지를 상기 서버 디바이스로부터 수신하는 단계; 상기 지시자에 기초하여 등시 채널(isochronous channel)을 통해 그룹핑된 상기 오디오 데이터 및 상기 오디오 데이터 정보를 포함하는 브로드캐스트 오디오 데이터를 상기 서버 디바이스로부터 수신하는 단계; 상기 오디오 데이터 정보에 기초하여 사용자로부터 상기 오디오 스트리밍 서비스의 제공의 허용 여부와 관련된 특정 정보를 획득하는 단계; 및 상기 특정 정보가 상기 오디오 데이터의 제공의 허용을 나타내는 경우, 상기 오디오 데이터를 디코딩 하는 단계를 포함하는 것을 특징으로 한다.
또한,본 명세서는, 상기 오디오 데이터 정보를 디코딩하는 단계를 더 포함하되, 상기 사용자로부터 상기 특정 정보의 획득 전에는 상기 오디오 데이터 및 상기 오디오 데이터 정보 중에서 상기 오디오 데이터 정보만이 디코딩 되는 것을 특징으로 한다.
또한, 본 명세서는, 상기 디코딩된 오디오 데이터 정보를 출력하는 단계를 더 포함하는 것을 특징으로 한다.
또한, 본 명세서는, 상기 동기화 정보는 상기 브로드캐스트 오디오 데이터의 타이밍 정보 및 상기 오디오 데이터의 수신을 위한 주파수 호핑(frequency hopping) 정보를 포함하는 것을 특징으로 한다.
또한, 본 명세서는, 상기 브로드캐스트 오디오 데이터를 식별하기 위한 그룹핑 ID(identifier)가 상기 브로드캐스트 오디오 데이터에 할당되고, 상기 오디오 데이터를 식별하기 위한 오디오 데이터 ID가 상기 오디오 데이터에 할당되고, 상기 오디오 데이터 정보를 식별하기 위한 오디오 데이터 ID가 상기 오디오 데이터 정보에 할당되는 것을 특징으로 한다.
또한, 본 명세서는, 상기 오디오 데이터 및 상기 오디오 데이터 정보는 인터리빙(interleaving)되어 그룹핑 되는 것을 특징으로 한다.
또한, 본 명세서는, 상기 서버 디바이스와 연결을 형성하는 단계; 상기 서버 디바이스의 제 1 특정 특성(Characteristic)에 저장되어 있는 상기 오디오 데이터 정보의 상태 정보의 판독을 요청하는 판독 요청 메시지를 상기 서버 디바이스로 전송하는 단계, 상기 상태 정보는 상기 오디오 데이터의 이름 정보, 상기 오디오 데이터가 상기 제 1 특정 특성에 저장된 날짜 정보 또는 상기 오디오 데이터의 버전(Version) 정보 중 적어도 하나를 포함하고; 및 상기 서버 디바이스로부터 상기 상태 정보를 포함하는 판독 응답 메시지를 수신하는 단계를 더 포함하는 것을 특징으로 한다.
또한, 본 명세서는, 상기 상태 정보에 기초하여 상기 오디오 데이터 정보의 변경을 위해서 상기 서버 디바이스의 제 2 특정 특성에 변경된 오디오 데이터 정보와 관련된 특성 값(Characteristic value)의 기입을 요청하는 기입 요청 메시지를 상기 서버 디바이스로 전송하는 단계, 상기 기입 요청 메시지는 상기 변경된 오디오 데이터 정보를 구성하는 데이터 중 일부의 데이터를 포함하고; 및 상기 기입 요청 메시지에 대한 응답으로 기입 응답 메시지를 상기 서버 디바이스로부터 수신하는 단계를 더 포함하는 것을 특징으로 한다.
또한, 본 명세서는, 상기 기입 요청 메시지는 각각은 상기 일부의 데이터들에 대한 시퀀스 번호 정보를 포함하는 것을 특징으로 한다.
또한, 본 명세서는, 상기 서버 디바이스를 포함하는 복수의 서버 디바이스들을 관리 하는 관리 서버로부터 상기 복수의 서버 디바이스들과 상기 클라이언트 디바이스 간의 동기화와 관련된 전체 동기화 정보를 수신하는 단계를 더 포함하되, 상기 전체 동기화 정보는 상기 복수의 서버 디바이스들 각각에 대한 동기화 정보를 포함하는 것을 특징으로 한다.
또한, 본 명세서는, 상기 복수의 서버 디바이스들 각각에 대한 동기화 정보는 상기 관리 서버에 사전에(previously) 저장되는 것을 특징으로 한다.
또한, 본 명세서는, 상기 오디오 데이터는 상기 서버 디바이스가 제공하는 특정한 프로그램과 관련된 오디오 데이터이고, 상기 오디오 데이터 정보는 상기 특정한 프로그램의 제목을 나타내는 것을 특징으로 한다.
또한, 본 명세서는, 상기 제 1 광고 메시지의 수신 신호 세기를 측정하는 단계를 더 포함하되, 상기 제 1 광고 메시지의 상기 수신 신호 세기가 특정한 임계 값 이상인 경우, 상기 제 1 광고 메시지를 디코딩 하는 것을 특징으로 한다.
또한, 본 명세서는, 블루투스 저전력(Bluetooth Low Energy) 기술을 이용하여 오디오 데이터를 수신하는 클라이언트 디바이스에 있어서, 무선 신호를 송신하기 위한 전송기(transmitter); 무선 신호를 수신하기 위한 수신기(receiver); 및 상기 전송기 및 수신기와 기능적으로 연결되는 프로세서를 포함하고, 상기 프로세서는, 오디오 스트리밍 서비스(Audio Streaming Service)의 제공을 위한 정보를 포함하는 제 1 광고 메시지를 서버 디바이스로부터 수신하도록 상기 수신기를 제어하고, 상기 클라이언트 디바이스와 상기 서버 디바이스 간의 동기화를 위한 동기화 정보를 포함하는 제 2 광고 메시지를 상기 서버 디바이스로부터 수신하도록 상기 수신기를 제어하고, 상기 오디오 스트리밍 서비스의 오디오 데이터가 상기 오디오 데이터 대한 오디오 데이터 정보와 그룹핑되어 전송됨을 나타내는 지시자를 포함하는 제 3 광고 메시지를 상기 서버 디바이스로부터 수신하도록 상기 수신기를 제어하고, 상기 지시자에 기초하여 등시 채널(isochronous channel)을 통해 그룹핑된 상기 오디오 데이터 및 상기 오디오 데이터 정보를 포함하는 브로드캐스트 오디오 데이터를 상기 서버 디바이스로부터 수신하도록 상기 수신기를 제어하고, 상기 오디오 데이터 정보에 기초하여 사용자로부터 상기 오디오 스트리밍 서비스의 제공의 허용 여부와 관련된 특정 정보를 획득하고, 상기 특정 정보가 상기 오디오 데이터의 제공의 허용을 나타내는 경우, 상기 오디오 데이터를 디코딩 하는 것을 특징으로 한다.
본 명세서는 블루투스 기술을 이용하여 오디오 데이터를 수신할 수 있는 효과가 있다.
또한, 본 명세서는 서버 디바이스들로부터 수신된 오디오 데이터에 대한 오디오 데이터 정보를 수신할 수 있는 효과가 있다.
또한, 본 명세서는 오디오 데이터 정보에 기초하여 오디오 데이터 수신 여부를 결정 할 수 있는 효과가 있다.
본 명세서에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 명세서에서 제안하는 블루투스 저전력 에너지 기술을 이용하는 무선 통신 시스템의 일 예를 나타낸 개략도이다.
도 2는 본 명세서에서 제안하는 방법들을 구현할 수 있는 디바이스의 내부 블록도의 일 예를 나타낸다.
도 3은 본 명세서에서 제안하는 방법들이 적용될 수 있는 블루투스 통신 아키텍처(Architecture)의 일 예를 나타낸다.
도 4는 블루투스 저전력 에너지의 GATT(Generic Attribute Profile)의 구조의 일 예를 나타낸다.
도 5는 본 발명이 적용될 수 있는 블루투스 저전력 에너지 기술에서 연결 절차 방법의 일 예를 나타내는 흐름도이다.
도 6은 오디오 신호의 특성을 나타낸다.
도 7은 등시 채널이 이용될 수 있는 어플리케이션들에 대한 홈에코시스템(Home ecosystem)의 일 예를 나타낸다.
도 8은 본 발명이 적용될 수 있는 GAM(Generic Audio Middleware) 프로토콜 스택의 일 예를 나타낸다.
도 9는 클라이언트 디바이스가 필터링 없이 디바이스를 탐색하는 일 예를 나타낸 도이다.
도 10은 클라이언트 디바이스 주변에 서버 디바이스가 복수가 존재하는 경우의 문제점을 보여주는 도이다.
도 11은 블루투스 저전력을 이용한 주기적인 광고 메시지 전송 방법의 일 예를 나타낸 도이다.
도 12a는 서버 디바이스가 전송하는 광고 메시지의 PDU 포맷의 예시들을 나타낸다.
도 12b는 광고 메시지 전송 타이밍의 일 예를 나타낸 도이다.
도 13은 블루투스 저전력(BLE)를 사용한 오디오 데이터 전송이 수행되는 일 예를 나타낸 도이다.
도 14는 블루투스 저전력을 이용한 오디오 데이터 전송 방법의 일 예를 나타낸다.
도 15는 블루투스 저전력을 이용한 오디오 데이터 전송 방법의 일 예를 나타낸다.
도 16은 블루투스 저전력을 이용하여 오디오 데이터를 전송하는 방법의 일 예를 나타낸다.
도 17은 블루투스 저전력을 이용하여 오디오 데이터를 전송하는 방법의 일 예를 나타낸 도이다.
도 18은 BIGINFO에 포함되는 필드(octets)들의 일 예를 나타낸 도이다.
도 19는 BIG 동기화 정보에 포함되는 특정 필드의 일 예를 나타낸 \BIG 파라미터 필드와 SDU_Config 필드의 일 예를 나타낸 도이다.
도 20은 본 명세서에서 제안하는 방법이 수행되는 일 예를 나타낸 도이다.
도 21은 본 명세서에서 제안하는 방법이 수행되는 일 예를 나타낸 도이다.
도 22는 본 명세서에서 제안하는 오디오 데이터 정보에 기초한 오디오 데이터 전송 방법이 수행되는 일 예를 나타낸 도이다.
도 23은 서버 디바이스가 오디오 데이터와 오디오 데이터 정보를 전송하는 방식의 일 예를 나타낸 도이다.
도 24는 서버 디바이스가 오디오 데이터와 오디오 데이터 정보를 전송하는 방법의 일 예를 나타낸 도이다.
도 25는 본 명세서에서 제안하는 오디오 데이터 정보에 기초한 오디오 데이터 전송 방법이 수행되는 일 예를 나타낸 도이다.
도 26 및 27은 클라이언트 디바이스가 서버 디바이스에 오디오 데이터 정보를 설정하는 방법의 일 예를 나타낸 도이다.
도 28 및 도 29는 관리 서버 디바이스가 클라이언트 디바이스에게 서버 디바이스들의 동기화 정보를 제공하는 방법의 일 예를 나타낸 도면이다.
도 30은 본 명세서에서 제안하는 블루투스 기술을 이용하여 오디오 데이터를 수신하는 방법이 수행되는 예시들을 나타낸다.
도 31은 본 명세서에서 제안하는 블루투스 기술을 이용하여 오디오 데이터를 수신하는 방법이 수행되는 예시를 나타낸다.
도 32는 본 명세서에서 제안하는 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 클라이언트 디바이스에서 구현되는 동작의 일례를 나타낸 도이다.
도 33은 브로드캐스트 프로파일의 계층적 구조를 나타낸 도이다.
도 34는 브로드캐스트 TV initiator와 브로드캐스트 TV Acceptor의 관계를 예시한다.
도 35는 브로드캐스트 TV 오디오 프로파일이 적용될 수 있는 시나리오의 일 예를 나타낸다.
도 36은 프로그램 정보에 기초하여 사용자에게 Initiator가 방송 중인 프로그램에 대한 정보를 알려주는 일 예를 나타낸다.
도 37은 브로드캐스트 TV 오디오 프로파일이 적용될 수 있는 시나리오의 또 다른 일 예를 나타낸다.
도 38은 브로드 캐스트 TV 시나리오 장치 설정 방식의 다양한 예시들을 나타낸다.
도 39는 확장된 광고 PDU에 포함되는 데이터 필드 구성의 일 예를 나타낸다.
도 40은 AUX_SYN_IND_PDU에 포함되는 데이터 필드 구성의 일 예를 나타낸다.
도 41은 BLE 브로드캐스트 오디오 동작의 일 예를 나타낸다.
본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는 첨부 도면은 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 특징을 설명한다. 명세서 전체에 걸쳐서 동일한 참조번호들은 원칙적으로 동일한 구성요소들을 나타낸다. 또한, 본 발명과 관련된 공지 기능 혹은 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 첨부된 도면은 본 발명의 사상을 쉽게 이해할 수 있도록 하기 위한 것일 뿐, 첨부된 도면에 의해 본 발명의 사상이 제한되는 것으로 해석되어서는 아니 됨을 유의해야 한다.
이하, 본 발명과 관련된 방법 및 장치에 대하여 도면을 참조하여 보다 상세하게 설명한다. 또한, 본 발명에서 사용되는 일반적인 용어는 사전에 정의되어 있는 바에 따라, 또는 전후 문맥상에 따라 해석되어야 하며, 과도하게 축소된 의미로 해석되지 않아야 한다. 또한, 본 명세서에서 사용되는 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "구성된다" 또는 "포함한다" 등의 용어는 명세서 상에 기재된 여러 구성 요소들, 또는 여러 단계들을 반드시 모두 포함하는 것으로 해석되지 않아야 하며, 그 중 일부 구성 요소들 또는 일부 단계들은 포함되지 않을 수도 있고, 또는 추가적인 구성 요소 또는 단계들을 더 포함할 수 있는 것으로 해석되어야 한다. 이하의 설명에서 사용되는 구성요소에 대한 접미사 "유닛", "모듈" 및 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다. "제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 PCTKR2020003270-appb-T000001
아래 광고 채널 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), 오디오 제어 및 데이터 전송을 위한 신호 전송을 정의한다. 응용 계층은 응용 시그널링과 필요한 전송 매개 변수를 정의한다.
본 명세서는 사용자의 주변에 오디오 데이터를 브로드 캐스트하는 다수의 서버 디바이스들이 존재하는 경우, 사용자에게 필요 이상으로 많은 서버 디바이스들이 검색 되고, 사용자는 검색된 서버 디바이스가 브로드 캐스트하는 오디오 데이터가 어떤 데이터인지 파악할 수 없는 문제점을 해결하기 위한 방법 및 이에 대한 장치를 제안한다. 구체적으로, 사용자가 사용자 주변의 서버 디바이스들을 탐색 할 때, 각 서버 디바이스가 제공하는 오디오 데이터와 관련된 정보를 사용자에게 제공하도록 하는 방법 및 이에 대한 장치를 제안한다.
본 명세서에서 제공되는 방법을 통해 사용자가 사용자 주변에 오디오 스트리밍 서비스를 제공하는 다수의 서버 디바이스가 존재하는 경우, 사용자의 주변 디바이스 검색이 효율적으로 수행될 수 있는 효과가 있다.
사용자가 블루투스 저전력(Bluetooth low energy: BLE) 오디오 스트리밍 서비스(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) 물리 광고 채널(physical advertising channel)을 통하여 Aux_Ext_indication 타입의 광고 PDU를 포함하는 확장된 광고 메시지(extended advertising message)를 전송한다(1101). 상기 프라이머리 물리 광고 채널은 37 내지 39 번 채널일 수 있고, 상기 광고 메시지에는 확장된 광고 메시지(Extended Advertising message)가 전송되는 채널 정보가 포함될 수 있다. 상기 확장된 광고 메시지는 확장된 광고 메시지의 전송과 관련된 이벤트 타입에 기초하여 AdvA, ADI, Aux Ptr, ADId, Ch#_Aux_Adv, Offset 필드 중 적어도 하나를 포함할 수 있다.
서버 디바이스는 세컨더리(Secondary) 물리 광고 채널을 통하여 Aux_Adv_indication 타입의 광고 PDU를 포함하는 확장된 광고 메시지를 전송한다(1102). 상기 세컨더리 물리 광고 채널은 0 내지 36번 채널일 수 있다.
클라이언트 디바이스는 상기 채널 정보에 기초하여 상기 확장된 광고 메시지를 수신할 수 있다. 도 11에 도시된 바와 같이 세컨더리 물리 광고 채널 상으로 전송되는 확장된 광고 메시지는 동기화 정보(syncinfo) 등을 포함할 수 있다.
다음, 서버 디바이스는 확장된 광고 메시지를 주기적으로 전송한다(1103). 상기 확장된 광고 메시지는 Aux_Sync_indication 타입의 광고 PDU 또는 Aux_Chain_Indication 타입의 광고 PDU를 포함하고, 상기 각각의 PDU에는 광고 데이터가 포함될 수 있다.
도 12a는 서버 디바이스가 전송하는 광고 메시지의 PDU 포맷의 예시들을 나타내고, 도 12b는 광고 메시지의 전송 타이밍의 일 예를 나타낸 도이다.
도 12a에 도시된 바와 같이, 광고 채널 PDU(1201)는 16 비트(bits)크기의 헤더(Header) 필드와 1-255 octets 크기만큼의 페이로드(Payload) 필드를 포함할 수 있다.
도 12a에서, 1202는 확장된 광고 메시지에 포함된 페이로드 필드의 일 예를 나타낸다. 상기 필드는 6 비트 크기의 확장된 헤더 길이 필드(Extended Header Length), 광고메시지가 전송되는 모드(Mode)를 나타내는 2 비트 크기의 AdvMode 필드, 0-63 octet크기를 갖는 Extended header 필드 및 오디오 스트리밍 서비스를 통하여 제공되는 오디오 데이터가 포함되는 0-254 octet 크기를 갖는 AdvData 필드를 포함할 수 있다.
도 12a에서, 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 필드를 포함한다.
도 12a에서, 1204는 확장된 광고 메시지의 extended header 필드에 포함된 Aux Ptr 필드를 나타낸다. 상기 필드는 6비트 크기의 채널 인덱스 필드, 1비트 크기의 CA 필드, 1비트 크기의 Offset Units 필드, 13비트 크기의 AUX Offset 필드 및 3비트 크기의 AUX PHY 필드를 포함할 수 있다.
도 12a에서, 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필드를 포함할 수 있다.
도 12b의 1206을 참조하면, 서버 디바이스는 ADV_EXT_IND 타입의 광고 PDU를 포함하는 광고 메시지를 주기적으로 일정 값의 오프셋을 두어 전송하는 것을 알 수 있다.
도 12b의 1207을 참조하면, 서버 디바이스는 서버 디바이스와 클라이언트 디바이스 간의 동기화를 위한 AUX_SYNC_IND 타입의 광고 PDU를 포함하는 광고 메시지를 주기적으로 일정 값의 간격(Interval)을 두어 전송하는 것을 알 수 있다.
도 12b의 1208을 참조하면, 서버 디바이스는 주기적인 광고 메시지를 전송하고 있다. 보다 구체적으로, (1) 서버 디바이스는 먼저 ADV_EXT_IND 타입의 광고 PDU를 포함하는 광고 메시지를 전송한다.
다음, (2) 서버 디바이스는 AUX_ADV_IND 타입의 광고 PDU를 포함하는 확장된 광고 메시지를 전송한다.
다음, (3) 서버 디바이스는 AUX_SYNC_IND 타입의 광고 PDU를 포함하는 하나의 확장된 광고 메시지, AUX_CHAIN_IND 타입의 광고 PDU를 포함하는 두 개의 확장된 광고 메시지들을 순차적으로 전송한다. 상기 서버 디바이스가 순차적으로 전송하는 광고 메시지들은 주기적인 광고 메시지 train으로 호칭될 수 있다. 다음, 서버 디바이스는 상기 (1) 내지 (3) 과정을 반복하여 수행한다. 여기서, 상기 서버 디바이스가 상기 (3) 단계에서 처음으로 확장된 광고 메시지를 전송한 시점과, 상기 서버 디바이스가 반복하여 수행하는 (3) 단계에서 처음으로 확장된 광고 메시지를 전송한 시점 사이의 시간적 간격이 주기적인 광고 간격(interval)에 해당한다. 이하에서, 설명의 편의를 위해 특정 타입의 PDU를 전송한다는 것은 특정 타입의 광고 PDU를 포함하는 광고메시지를 전송한다는 것을 의미할 수 있다. 예를 들어, AUX_SYNC_IND PDU를 전송하는 것은 AUX_SYNC_IND 타입의 광고 PDU를 포함하는 확장된 광고 메시지를 전송한다는 것을 의미할 수 있다.
도 13은 블루투스 저전력(BLE)를 사용한 오디오 데이터 전송이 수행되는 일 예를 나타낸 도이다.
도 13에서 브로드캐스트 오디오를 전송하는 서버 디바이스(1310)와, 브로드캐스트 오디오를 수신하는 클라이언트 디바이스(1320)가 도시되어 있다. 클라이언트 디바이스는 Acceptor라고도 호칭될 수 있다.
서버 디바이스(1310)는 주기적인 광고메시지 전송(Periodic Advertising)을 통해 확장된 광고메시지의 채널 정보 등을 포함하는 ADV_EXT_IND 타입의 광고 PDU를 포함하는 확장된 광고 메시지, 동기화 정보 등을 포함하는 AUX_ADV_IND 타입의 광고 PDU를 포함하는 확장된 광고 메시지, 오디오 데이터 등을 포함하는 AUX_SYNC_IND 타입의 광고 PDU를 포함하는 확장된 광고 메시지를 순차적으로 전송하고, 상기 서버 디바이스(1310)는 상기 순차적인 전송을 주기적으로 수행할 수 있다(S1301, S1302).
클라이언트 디바이스(1320)는 서버 디바이스가 전송하는 확장된 광고 메시지들을 스캔(Scan)하여 동기화와 관련된 정보를 획득 할 수 있다.
동기화 정보를 획득한 클라이언트 디바이스(1320)는 상기 클라이언트(1320) 디바이스의 Link layer에서 동기화 신호를 수신했다는 보고(report)를 Host에 전달하고, Host는 서버 디바이스(1310)가 전송하는 주기적인 광고 메시지와 클라이언트 디바이스간의 동기화를 인에이블(enable) 시킨다(S1303).
이후, 클라이언트 디바이스(1320)는 AUX_SYNC_IND 타입의 광고 PDU에 포함된 BIG(Broadcast Isochronous Group) INFO 정보에 기초하여 오디오 데이터를 서버 디바이스(1310)로부터 수신한다(S1305-S1310). 클라이언트 디바이스(1320)의 사용자는 수신된 오디오 데이터에 기초하여 오디오를 청취할 수 있다.
도 13에서는, 클라이언트 디바이스(1320)가 동기화 정보를 획득한 후, 별도의 필터링 등의 절차를 수행하지 않고 오디오 데이터를 수신한다. 따라서, 클라이언트 디바이스(1320)는 오디오 데이터를 수신하자 마자 수신된 오디오 데이터와 관련된 청각적 신호가 출력할 수 있다. 또는, 클라이언트 디바이스(1320)가 UI를 탑재한 스마트폰 등의 디바이스인 경우, 클라이언트 디바이스(1320)는 동기화 정보를 획득한 후, 별도의 필터링 등의 절차를 수행하지 않고 오디오 데이터를 수신한다. 따라서, 클라이언트 디바이스(1320)는 오디오 데이터를 수신하자 마자 오디오 데이터를 전송한 디바이스의 리스트를 사용자에게 출력하고, 사용자가 오디오 데이터를 선택하도록 할 수 있다. 이는 디바이스 사용자로 하여금 불필요하게 청각적 신호를 청취하게 하는 등의 불편함을 초래할 수 있다.
도 14는 블루투스 저전력을 이용한 오디오 데이터 전송 방법의 일 예를 나타낸다.
보다 구체적으로, 도 14는 클라이언트 디바이스와 서버 디바이스가 블루투스 오디오 데이터 송수신을 위해 수행하는 설정 절차(configuration procedure)를 나타낸다. Initiator는 서버 디바이스를 의미하고, Acceptor는 클라이언트 디바이스를 의미할 수 있다.
도 14(a)에서 서버 디바이스는 유휴상태에서 브로드캐스트 모드를 위한 설정을 시작한다(S1411).
다음, 서버 디바이스는 주기적인 광고 모드를 설정한다(S1421). 이 모드에서, 서버 디바이스는 프라이머리 광고 물리 채널 상으로 광고 메시지를 전송할 수 있다.
다음, 서버 디바이스는 주기적인 동기화 모드를 설정한다(S1431). 이 모드에서, 서버 디바이스는 주기적으로 동기화 정보를 세컨더리 광고 물리 채널 상으로 전송할 수 있다.
서버 디바이스는 상기 S1411 내지 S1431단계를 수행함으로써 오디오 데이터를 전송하기 위한 설정을 완료한다(S1441).
도 14(b)에서 클라이언트 디바이스는 유휴상태에서 Observation 절차를 시작한다(S1412).
다음, 클라이언트 디바이스는 서버 디바이스로부터 확장된 광고 메시지를 수신하고, 클라이언트의 링크 계층은 ASCP로 확장된 광고 리포트 이벤트를 전달한다(S1422).
다음, 클라이언트 디바이스는 주기적인 광고 동기화 모드를 설정한다(S1431).
다음, 클라이언트 디바이스는 주기적인 광고 동기화 모드에서 서버 디바이스로부터 주기적인 광고 메시지에 포함되어 전송되는 동기화 정보를 수신하고, 클라이언트 디바이스의 링크 계층은 주기적인 광고 리포트 이벤트를 ASCP로 전달한다(S1441).
클라이언트 디바이스는 상기 S1412 내지 S1442단계를 수행함으로써 오디오 데이터를 수신하기 위한 설정을 완료한다(S1452).
도 15는 블루투스 저전력을 이용한 오디오 데이터 전송 방법의 일 예를 나타낸다.
보다 구체적으로, 도 15는 클라이언트 디바이스와 서버 디바이스가 블루투스 오디오 데이터를 송수신하기 위해 수행하는 enable procedure를 나타낸다. Initiator는 서버 디바이스를 의미하고, Acceptor는 클라이언트 디바이스를 의미할 수 있다.
도 15(a)에서 서버 디바이스는 브로드캐스트 등시 브로드캐스팅 모드를 위한 설정을 시작한다(S1511). 이 단계에서 서버 디바이스는 BIG(Broadcast Isochronous Group)의 BIS(Broadcast Isochronous Stream) 데이터를 전송할 수 있다.
다음, 서버 디바이스는 브로드캐스트 등시 동기화 모드를 설정한다 (S1521). 이 단계에서, 서버 디바이스는 브로드캐스트 등시 동기화 정보를 주기적으로 전송할 수 있다.
이후, 서버 디바이스의 ASCP는 Audio를 enable한다(S1531). Audio를 enable 한다는 것은 오디오 데이터의 전송을 활성화 하는 것을 의미할 수 있다.
다음, 서버 디바이스는 오디오 데이터 스트리밍을 시작한다(S1541).
도 15(b)에서 클라이언트 디바이스는 브로드캐스트 등시 동기화 모드를 설정한다(S1512).
다음, 클라이언트 디바이스는 오디오 데이터 스트리밍을 시작한다(S1522).
도 16은 블루투스 저전력을 이용하여 오디오 데이터를 전송하는 방법의 일 예를 나타낸다.
서버 디바이스는 프라이머리(Primary) 물리 광고 채널(physical advertising channel)을 통하여 Aux_Ext_indication 타입의 광고 PDU를 포함하는 확장된 광고 메시지(extended advertising message)를 전송한다(1601). 상기 프라이머리 물리 광고 채널은 37 내지 39 번 채널일 수 있고, 상기 광고 메시지에는 확장된 광고 메시지(Extended Advertising message)가 전송되는 채널 정보가 포함될 수 있다. 상기 확장된 광고 메시지는 확장된 광고 메시지의 전송과 관련된 이벤트 타입에 기초하여 AdvA, ADI, Aux Ptr, ADId, Ch#_Aux_Adv, Offset 필드 중 적어도 하나를 포함할 수 있다.
서버 디바이스는 세컨더리(Secondary) 물리 광고 채널을 통하여 Aux_Adv_indication 타입의 광고 PDU를 포함하는 확장된 광고 메시지를 전송한다(1602). 상기 세컨더리 물리 광고 채널은 0 내지 36번 채널일 수 있다.
클라이언트 디바이스는 상기 채널 정보에 기초하여 상기 확장된 광고 메시지를 수신할 수 있다. 도 16에 도시된 바와 같이 세컨더리 물리 광고 채널 상으로 전송되는 확장된 광고 메시지는 동기화 정보(syncinfo) 등을 포함할 수 있다.
다음, 서버 디바이스는 확장된 광고 메시지를 주기적으로 전송한다(1603). 상기 확장된 광고 메시지는 Aux_Sync_indication 타입의 광고 PDU를 포함할 수 있다. 상기 광고 PDU는 Aux Ptr, ACAD, ADATA Ch#_Aux_chain, offset BIGInfo(ACAD), Metadata(ADATA) 필드 중 적어도 하나를 포함할 수 있고, 광고 데이터(Advdata)를 포함할 수 있다.
이후, 서버 디바이스는 오디오 데이터를 포함하는 BIS data Packet(1604)과 오디오 스트리밍 서비스를 제공하기 위한 제어 정보를 포함하는 control packet(1606)를 전송할 수 있다. 상기 BIS data packet과 control packet은 등시 채널을 통하여 주기적으로 전송될 수 있다.
블루투스 저전력을 이용하여 오디오 데이터 전송하기 위해서 PAST(Periodic Advertising Sync Transfer) 방식이 사용될 수 있다.
상기 PAST 방식은 주기적인 광고 전송 방법에 적용될 수 있는 방식이다. 이 방식을 통하여, 서버 디바이스가 클라이언트 디바이스에 동기화 정보(SyncInfo)를 제공하면, 클라이언트 디바이스 Adv_Ext_Indication PDU 및 Aux_Adv_Indication PDU를 수신하지 않고도 세컨더리 채널 상에서 주파수 호핑을 수행하면서 광고 데이터를 획득할 수 있다.
상기 PAST 방식은 블루투스 저전력을 이용하여 오디오 데이터를 전송하는 방법(브로드캐스트 오디오)에도 적용될 수 있다. 주기적인 광고 전송 방법에서의 SyncInfo는 브로드 캐스트 오디오에서의 BIGInfo에 대응될 수 있다. 클라이언트 디바이스가 서버 디바이스로부터 상기 BIGInfo가 정보를 제공받으면, 상기 클라리언트 디바이스는 Adv_Ext_Indication PDU, Aux_Adv_Indication PDU 및 Aux_sync_Indication PDU를 수신하지 않고도 세컨더리 채널에서 주파수 호핑을 수행하면서 오디오 데이터를 수신할 수 있다.
상기 PAST 방식이 적용되지 않는 경우, 서버 디바이스는 일반적인 Announcement를 클라이언트 디바이스로 전달한다. 상기 일반적인 Announcement는 광고 메시지일 수 있다. 다음, 클라이언트 디바이스는 상기 일반적인 Announcement에서 BIGINFO를 파싱(parsing)한다. 이후, 클라이언트 디바이스는 파싱한 BIGINFO에 기초하여 서버 디바이스로부터 브로드캐스트 오디오 데이터를 수신할 수 있다. 여기서, 클라이언트 디바이스는 헤드폰 등일 수 있고, 서버 디바이스는 TV등일 수 있다.
상기 PAST 방식이 적용되는 경우, 일 예로, 클라이언트 디바이스는 제 3 의 디바이스(commander)로부터 서버 디바이스가 전송하는 오디오 데이터와 관련된 BIG INFO를 전달받을 수 있다. 여기서, 클라이언트 디바이스가 제 3 의 디바이스로부터 BIG INFO를 전달받는 동작은 Scan offloaing으로 표현될 수 있다.
보다 구체적으로, 제 3 의 디바이스는 클라이언트 디바이스로부터 일반적인 Announcement를 수신한다. 상기 일반적인 Announcement는 광고 메시지일 수 있다. 다음, 상기 제 3의 디바이스는 상기 클라이언트 디바이스와 연결을 형성한다. 이후, 상기 제 3의 디바이스는 상기 클라이언트 디바이스로 서버 디바이스의 BIGINFO를 전달한다. 여기서, 클라이언트 디바이스는 헤드폰 등일 수 있고, 서버 디바이스는 TV 등일 수 있으며, 제 3의 디바이스는 스마트폰 등일 수 있다.
또 다른 일 예로, 클라이언트 디바이스는 서버 디바이스와 연결을 형성하고, 서버 디바이스로부터 직접적으로 서버 디바이스가 전송하는 오디오 데이터와 관련된 BIG INFO를 전달 받을 수 있다.
보다 구체적으로, 상기 클라이언트 디바이스는 일반적인 Announcement를 서버 디바이스로 전달한다. 상기 일반적인 Announcement는 광고 메시지일 수 있다. 다음, 상기 클라이언트 디바이스와 상기 서버 디바이스는 연결을 형성한다. 이후, 상기 서버 디바이스는 상기 클라이언트 디바이스로 상기 서버 디바이스의 BIGINFO를 전달한다.
도 17은 블루투스 저전력을 이용하여 오디오 데이터를 전송하는 방법의 일 예를 나타낸 도이다.
서버 디바이스(1410)는 브로드 캐스트 동기화 정보를 주변의 디바이스들에게 브로드캐스트 한다(1420). 보다 구체적으로, 상기 서버 디바이스는 Adv_Ext_Indication PDU, Aux_Adv_Indication PDU 및 Aux_Sync_Indication PDU를 순차적으로 전송할 수 있다. 상기Aux_Sync_Indication PDU는 BIGINFO 및 Metadata를 포함할 수 있다. 상기 BIGINFO는 클라이언트 디바스가 오디오 데이터를 수신하기 위한 상기 동기화 정보일 수 있다.
다음, 상기 서버 디바이스는 주기적으로 브로드캐스트 오디오 데이터를 전송한다(1430). 상기 브로드캐스트 오디오 데이터는 BIS_Data_Packet에 포함되어 전송될 수 있다. 클라이언트 디바이스는 BIGINFO에 포함된 타이밍 정보와 주파수 호핑 알고리즘 정보에 기초하여 상기 오디오 데이터를 획득할 수 있다.
도 18은 BIGINFO에 포함되는 필드(octets)들의 일 예를 나타낸 도이다.
BIGINFO의 1-2 octet은 BIG offset에 해당하고, 3-14 octet은 BIG 파라미터에 해당하며, 15-18 octet은 SeedAccessAddress에 해당한다. 또한, 19-20 octet은 BaseCRCInit에 해당하고, 21-25 octet은 SDU_config에 해당하며, 26-30 octet은 bisPayloadCounter에 해당한다. 1-30 octet에 포함되는 필드들은 필수적으로 BIGINFO에 포함될 수 있다. 마지막으로, 31-54 Octet은 BIG_Encryption에 해당하는데, 상기 필드는 필수적으로 포함되는 것은 아니다.
도 19는 BIG 동기화 정보에 포함되는 특정 필드의 일 예를 나타낸 \BIG 파라미터 필드와 SDU_Config 필드의 일 예를 나타낸 도이다.
도 19(a)는 BIG 파라미터 필드의 일 예를 나타낸다. BIG 파라미터 필드는
Encryption (1 bit) 필드, 2개의 RFU(reserved for future use) (3 bits) 필드, ISO_Interval (12 bits) 필드, NumBIS (5 bits) 필드, Max_Payload_Size (1 octet) 필드 및 Sub_Interval (20 bits)를 포함할 수 있다.
도 19(b)는 BIG 파라미터(Cont) 필드의 일 예를 나타낸다. BIG 파라미터(Cont) 필드는 BIS 앵커 간격을 나타내는 BIS_Spacing (20 bits) 필드, NSE (5 bits) 필드, BN (3 bits) 필드, PTO(pretransmissionoffset) (4 bits) 필드, IRC(ImmediateRepetitionCoun)(4 bits) 필드, PHYPHY(8 bits) 필드를 포함할 수 있다.
도 19(c)는 SDU_Config 파라미터 필드의 일 예를 나타낸다. SDU_Config 파라미터 필드는 frame/unframed 중 하나를 나타내는 ISOAL_PDU_Type (1 bit)필드, RFU (7 bits) 필드, Max_SDU_Size (12 bits) SDU간격(1msec ~ 1.048575sec)을 나타내는 SDU_Interval (20 bits) 필드를 포함할 수 있다.
서버 디바이스와 클라이언트 디바이스에서의 음성 피드백에 기초한 디바이스 검색을 위한 구조
도 20은 본 명세서에서 제안하는 방법이 수행되는 일 예를 나타낸 도이다.
구체적으로, 본 명세서에서 제안하는 방법이 한 대의 서버 디바이스와 클라이언트 디바이스 사이에서 수행되는 일 예를 도시한다. 서버 디바이스는 오디오 전송 설정을 담당하는 디바이스이며, 주로 전송 디바이스, 스마트폰, TV 등일 수 있다. 클라이언트 디바이스는 오디오 전송 설정 대상 디바이스 일 수 있으며, 주로 수신 디바이스, 스피커, 또는 이어폰(Earbud)일 수 있다.
서버 디바이스는 BLE Tx 인터페이스를 통해 BLE 오디오 브로드캐스트 패킷을 주기적으로 전송한다. 클라이언트 디바이스는 서버 디바이스에서 보내는 동기화 정보를 수신한다.
다음, 클라이언트 디바이스는 오디오 데이터 브로드캐스팅을 수신할 수 있는 방법을 결정한다. 이후, 클라이언트 디바이스는 서버 디바이스가 제공하는 특정 프로그램과 관련된 오디오 데이터의 정보를 수신한다. 다음, 클라이언트 디바이스는 상기 오디오 데이터를 사용자에게 출력하고, 사용자로부터 브로드캐스팅을 청취하겠다는 입력을 획득하게 되면 하면, 오디오 데이터 브로드캐스트 스트림을 수신하여 디코딩한다. 이 때, 사용자의 입력은 클라이언트 디바이스에 탑재된 버튼을 누르거나, 고개를 끄덕이는 것 등일 수 있다.
도 21은 본 명세서에서 제안하는 방법이 수행되는 일 예를 나타낸 도이다.
구체적으로, 본 명세서에서 제안하는 방법이 한 대의 (i)서버 디바이스와 (ii)클라이언트 디바이스 및 클라이언트 디바이스 사이에서 본 방법이 수행되도록 보조하는 사용자 보조 디바이스 사이에서 수행되는 일 예를 도시한다.
도 21에 따르면, 클라이언트 디바이스의 시그널링 오버헤드를 감소시키기 위해서, 광고 패킷의 스캐닝을 사용자 보조 디바이스에서 할 수 있다. 사용자 보조 디바이스는 스마트폰 등일 수 있다.
사용자 보조 디바이스는 동기화 정보를 서버 디바이스로부터 수신하고, 서버 디바이스에서 보내는 브로드캐스팅 데이터를 클라이언트 디바이스에서 수신할 수 있도록 동기화 정보를 클라이언트 디바이스로 전송한다.
사용자 보조 디바이스로부터 동기화 정보를 수신한 클라이언트 디바이스는, 서버 디바이스로부터 오디오 데이터 브로드캐스드 정보를 직접 수신하고, 디코딩한다.
또 다른 일 예로, 클라이언트 디바이스와 사용자 보조 디바이스는 기존 무선 연결방식과 동일하게 연결하여, 디코딩을 사용자 보조 디바이스에서 하고, 디바이스로 사용자 보조 디바이스는 클라이언트 디바이스와 유니캐스트(Unicast)로 연결하여 클라이언트 디바이스로 데이터를 보낼 수 있다.
오디오 데이터 정보 제공 방법
본 방법은 서버 디바이스가 제공하는 특정 프로그램의 오디오 데이터에 대한 정보를 제공하는 방법에 관한 것이다. 상기 특정 프로그램의 오디오 데이터에 대한 정보는 오디오 데이터 정보 또는 프로그램 정보 등으로 표현될 수 있으며, 이와 동일 유사하게 해석될 수 있는 다양한 표현으로 호칭될 수 있음은 물론이다.
특정 프로그램의 오디오 데이터에 대한 정보는 Aux_Sync_Indication 타입의 광고 PDU를 포함하는 확장된 광고 메시지에 포함되어 전송될 수 있다. 보다 구체적으로. 상기 특정 프로그램의 오디오 데이터는 Aux_Sync_Indication 타입의 광고 PDU의 메타 데이터(meta data)필드에 포함될 수 있다. 설명의 편의를 위해, 이하에서 특정 프로그램의 오디오 데이터는 브로드캐스트 오디오라고 표현될 수 있으며, 오디오 데이터에 대한 정보는 오디오 데이터 정보 또는 프로그램 정보 등 이와 동일 유사하게 해석될 수 있는 용어로 표현될 수 있다.
이하에서, 상기 오디오 데이터 정보를 메타 데이터에 포함시키는 방식에 대해서 살펴본다.
(제안 1) 텍스트 형식의 프로그램 제목을 메타 데이터에 포함시키는 방법
본 제안은 상기 메타 데이터 필드에 TV 프로그램(또는 채널) 제목 형태의 오디오 데이터 정보를 포함 시키는 방법에 관한 것이다.
오디오 데이터를 포함하는 BIG stream에 대한 메타 데이터는 Aux_Sync_Indication PDU의 메타 데이터 필드에 포함된다. 상기 메타 데이터 필드는 상위계층 profile에서 정의될 수 있다. 메타 데이터 필드는 Aux_Sync_Indication PDU의 AdvData 필드에 위치하며, 0~254 octet의 크기를 가질 수 있다.
사용자는 Aux_Sync_Indication PDU에 포함된 메타 데이터 필드에 기초하여 서버 디바이스가 제공하는 특정한 프로그램과 관련된 오디오 데이터 청취 여부를 결정할 수 있다.
즉, 클라이언트 디바이스가 BT 브로드캐스트 동기화 정보(Broadcast Sync information)를 수신하면, 상기 클라이언트 디바이스는 동기화 정보에 포함된 메타 데이터 필드에 포함된 오디오 데이터 정보를 사용자에게 출력할 수 있다. 상기 사용자는 출력된 오디오 데이터 정보에 기초하여 상기 서버 디바이스가 제공하는 특정 프로그램에 대한 오디오 데이터의 청취 여부를 결정할 수 있다. 상기 오디오 데이터의 청취 여부를 결정하기 위해 사용자는 클라이언트 디바이스로 특정한 입력을 수행할 수 있다. 예를 들어, 상기 입력은 스마트폰, 또는 헤드폰의 버튼을 누른다거나, 헤드폰을 위아래로 움직이는 등일 수 있다.
Aux_Sync_Indication는 BIG(Broadcast Isochronous Group)에 해당하는 단위이므로, BIG 범위는 프로그램으로 간주 될 수 있다. 예를 들어, 서버 디바이스가 BT Broadcast로 특정 프로그램(방송)을 전송하는 경우, 클라이언트 디바이스는 PSIP(Program Specific Information Protocol) 정보에서 오디오 데이터 정보를 얻을 수 있다. 이 때, 서버 디바이스가 제공하는 특정한 프로그램에 PSIP 정보가 없는 경우, 서버 디바이스가 직접 프로그램 제목을 설정할 수 있다.
(제안 2) 다중-언어 스트림(Multi-Language Stream)을 메타 데이터에 포함시키는 방법
본 제안은 상기 메타 데이터 필드에 오디오 데이터 정보를 다중-언어 스트림 형태로 포함 시키는 방법에 관한 것이다.
보다 구체적으로, 하나의 BIG(Broadcast Isochronous Group)에 다중-언어 스트림이 포함되어 있을 수 있다. 이 경우에는 클라이언트 디바이스가 오디오 데이터 정보를 수신할 때, 특정한 언어의 스트림만을 수신하여 디코딩 할 수 있도록 각 스트림의 언어 코드(language code)를 알려 줄 수 있다. 다중-언어 스트림이 포함되는 경우, BIG_Description에 Multi_Language_Information 이 추가될 수 있다.
메타 데이터 필드는 UUID_Multi_Language_Information(16bit) 필드, length(8bit) 필드 및 value(254 - BIG_Description) 필드를 순서대로 포함할 수 있다. 상기 Value 필드에 포함된 BIS 들은 BIS 0번 스트림부터, 순서대로 언어-코드가 포함할 수 있다. 예를 들어, BIS 0번 스트림은 영어(English), BIS 1번 스트림은 한국어(Korean), BIS 2번 스트림은 프랑스어(French) 일 수 있다. 이 때, Length 필드는 9byte(3x3 byte), Value 필드는 ENG, KOR, FRE 로 입력될 수 있다.
또한, 상기 다중-언어 스트림은 다중-채널(Multi-Channel)상으로 전송될 수 있다. Value 필드에는 BIS 0번 스트림부터 순서대로 language와 channel 값이 포함될 수 있다. 예를 들어, Channel(location)은 enumeration type일 수 있다. 즉, 0: mono, 1: left, 2 : right, 3 : center, 4 : rear left, 5 : rear right, 6 : base woofer 일 수 있다. 이 때, BIS 0번 stream : English-Left stereo, BIS 1번 stream : English-Right stereo ,BIS 2번 stream : Korean mono , BIS 3번 stream : French mono 일 수 있고, Length 필드는 12byte(4x3 byte) 크기 이고, Value 필드에는 ENG1, ENG2, KOR0, FRE0 가 입력될 수 있다.
(제안 3) 오디오 데이터 정보를 오디오 스트림 형태로 메타 데이터에 포함시키는 방법
본 제안은 텍스트 형태의 오디오 데이터 정보를 포함시키는 것이 아닌 오디오 스트림 형태의 오디오 데이터 정보를 메타 데이터 필드에 포함시키는 방법에 관한 것이다. 여기서 오디오 데이터 정보는 서버 디바이스가 제공하는 특정 프로그램의 프로그램 제목일 수 있다. 오디오 데이터 정보를 텍스트 형태로 메타 데이터에 포함시키게 되면, 사용자는 UI가 탑재된 디바이스를 사용하여 오디오 데이터를 선택하기 위한 절차를 수행해야 한다. 반면, 오디오 데이터 정보를 오디오 스트림 형태로 메타 데이터에 포함시키게 되면, 클라이언트 디바이스는 오디오 데이터 정보를 확인하여 사용자에게 곧바로 출력해줄 수 있으므로, 사용자는 오디오 데이터 수신 여부를 간이하게 결정할 수 있다.
구현의 편의를 위해, 오디오 스트림 형태의 오디오 데이터 정보가 전송되는 BIS 스트림은 BIS 0번 스트림으로 제한될 수 있다. 다중-언어 코드에는 사용되지 않는 PTA(Program Title Audio)가 3 byte character로 사용될 수 있다.
텍스트 형태의 오디오 데이터 정보는 TTS(Text to Speech) 기법을 통하여 서버 디바이스나 스마트폰 등의 제 3 디바이스에 의하여 오디오 스트림 형태의 오디오 데이터 정보로 변환될 수 있다. 변환된 오디오 데이터 정보는 클라이언트 디바이스에게 제공될 수 있다. 또한, 서버 디바이스가 제공하는 특정한 프로그램이 프로그램 제목을 제공하지 않는 경우, 임의의 오디오를 업로드하여 오디오 스트림 형태의 오디오 데이터 정보를 생성할 수 있다. 상기 생성된 오디오 스트림 형태의 오디오 데이터 정보는 2~3초 내외의 짧은 오디오 스트림일 수 있다. 상기 오디오 데이터 정보에는 음성(voice)뿐만 아니라 배경 음악/효과(background music/effect)가 첨가 될 수 있다.
메타 데이터 필드는 UUID_Multi_Language_Information(16bit) 필드, length(8bit) 필드 및 value(254 - BIG_Description) 필드를 순서대로 포함할 수 있다.
상기 Value 필드에 포함된 BIS 들은 BIS 0번 스트림부터, 순서대로 언어-코드가 포함할 수 있다. 일 예로, BIS 0번 stream : Program title audio, BIS 1번 stream : English, BIS 2번 stream : Korean 및 BIS 3번 stream : French 일 수 있다. 이 때, Length 필드는 12byte 크기일 수 있고, Value 필드에는 PTA, ENG, KOR, FRE 가 입력될 수 있다.
오디오 데이터 정보에 기초한 서버 디바이스 검색
도 22는 본 명세서에서 제안하는 오디오 데이터 정보에 기초한 오디오 데이터 전송 방법이 수행되는 일 예를 나타낸 도이다.
구체적으로, 도 22는 서버 디바이스가 전송하는 오디오 데이터를 클라이언트 디바이스가 수신하는 과정을 예시한다.
서버 디바이스는 동기화 정보를 브로드 캐스트한다(2210). 상기 동기화 정보는 확장된 광고메시지에 포함되어 전송될 수 있다. 보다 구체적으로, 동기화 정보를 전송하기 위해, 서버 디바이스는 Aux_Ext_Indication PDU 및 Aux_Adv_Indication PDU를 순차적으로 전송할 수 있다. ‘서버 디바이스가 Aux_Ext_Indication PDU 및 Aux_Adv_Indication PDU를 순차적으로 전송’ 하는 것은 ‘서버 디바이스가 동기화 정보를 전송’하는 것을 의미할 수 있다.
서버 디바이스가 동기화 정보를 브로드캐스트 할 때, 서버 디바이스는 브로드캐스트 오디오 데이터에 오디오 데이터 정보가 오디오 데이터와 함께 포함되는 것을 나타내는 지시 정보를 클라이언트 디바이스에게 함께 전달할 수 있다. 상기 브로드캐스트 오디오 데이터에 오디오 데이터 정보가 오디오 데이터와 함께 포함되는 것을 나타내는 지시 정보는 Aux_Sync_Indication 타입의 광고 PDU에 포함된 BIG INFO 필드에 포함될 수 있다.
오디오 데이터 정보는 서버 디바이스가 제공하는 특정 프로그램의 오디오 데이터에 대한 정보이다. 클라이언트 디바이스는 상기 오디오 데이터 정보를 수신한다(2220). 이후, 클라이언트 디바이스는 사용자가 서버 디바이스에서 제공되는 프로그램이 어떤 프로그램인지 알 수 있도록 하기 위해, 상기 오디오 데이터 정보를 디코딩하여 출력할 수 있다(2231 내지 2233). 또한, 상기 오디오 데이터 정보는 (i) 음성 또는 (ii) 음성과 추가적인 음향 효과가 혼합된 형태로 출력될 수 있다. 도 22의 2233 이전에는 사용자가 오디오 데이터를 수신함을 나타내는 정보를 입력을 하지 않았으므로, 상기 클라이언트 디바이스는 브로드캐스트 오디오 데이터에 포함된 오디오 데이터 정보 및 오디오 데이터 중 오디오 데이터 정보만을 상기 클라이언트 디바이스의 호스트로 전달한다. 즉, 오디오 데이터는 호스트에게 전달되지 않는다.
도 22의 2233에서, 사용자는 출력된 오디오 데이터 정보에 기초하여, 오디오 데이터를 수신함을 나타내는 정보를 입력한다(2240).
클라이언트 디바이스가 사용자로부터 입력을 획득한 경우, 사용자의 입력이 상기 오디오 데이터를 수신함을 나타내면, 클라이언트 디바이스는 서버 디바이스가 전송하는 오디오 데이터를 수신하고, 호스트에 상기 오디오 데이터를 전달한다(2250). 이 때, 사용자로부터 오디오 데이터를 수신함을 나타내는 입력을 획득한 시점 이후로는, 오디오 데이터 정보가 호스트에게 전달되지 않을 수 있다.
반대로, 특정 Timeout 시간 내에 사용자가 입력을 수행하지 않는 경우, 클라이언트 디바이스는 초기상태로 돌아간다. 초기 상태란, 클라이언트 디바이스가 서버 디바이스로부터 오디오 스트리밍 서비스를 제공하기 위한 확장된 광고 메시지를 수신하기 전의 클라이언트 디바이스의 동작 상태를 의미할 수 있다.
또한, 클라이언트 디바이스가 사용자로부터 서버 디바이스가 전송하는 오디오 데이터를 수신하지 않는다는 입력을 획득하였지만, 이후 사용자가 다시 상기 오디오 데이터를 수신하고자 할 수 있다. 이 경우, 클라이언트 디바이스는 서버 디바이스의 신호세기가 특정 임계값 이상의 세기로 측정되는지 스캔할 수 있다. 상기 신호세기의 측정은 최소 Primary channel의 Aux_Ext 패킷 신호세기는 측정을 통하여 수행될 수 있다. 신호세기가 특정 임계값 이상인 경우, 클라이언트 디바이스는 관찰 절차(Observation Procedure)에서 Aux_Ext 패킷을 파싱(parsing)하여, 확정된 광고 리포트 이벤트(Extended Advertising Report Event)를 호스트로 전달한다.
오디오 데이터와 오디오 데이터 정보를 포함하는 BIG는 브로드캐스트 오디오 데이터라고 호칭될 수 있다. 상기 오디오 데이터와 오디오 데이터 정보는 동일한 서버 디바이스가 전송하는 데이터이므로 하나의 group ID(Broadcast Isochronous Group: BIG)가 할당될 수 있다. 또한, 상기 각각의 데이터는 sub ID(Broadcast Isochronous Stream: BIS)로 표시할 수 있다. 즉, BIG = TV program description, BIS1 = 오디오 데이터 정보, BIS2 = 오디오 데이터일 수 있다. 상기 BIG는 상기 브로드 캐스트 오디오 데이터에 할당되는 식별자일 수 있다.
도 23은 서버 디바이스가 오디오 데이터와 오디오 데이터 정보를 전송하는 방식의 일 예를 나타낸 도이다.
구체적으로, 도 23은 서버 디바이스가 오디오 데이터 정보 및 오디오 데이터를 BIG로 묶어서 전송하는 경우, 멀티플렉싱하는 방법들의 예시를 나타낸다.
오디오 데이터 정보와 오디오 데이터는 하나의 서버 디바이스에서 전송되므로, 같은 오디오 그룹(Audio Group)에 포함될 수 있다. 따라서, 오디오 데이터 및 오디오 데이터 정보를 하나의 BIG에 포함시키되, 오디오 데이터 및 오디오 데이터 정보는 BIG에 포함된 서로 다른 BIS에 각각 포함되어 전송될 수 있다. 하나의 데이터 그룹으로 묶어져서 전송되는 브로드캐스트 오디오 데이터는 등시 채널 상으로 전송될 수 있다. 서로 다른 데이터들을 하나의 그룹으로 묶는다는 것은 서로 다른 데이터들을 그룹핑 한다고 표현될 수 있다.
보다 구체적으로, 클라이언트 디바이스의 상태가 Broadcast Stream - Configure procedure인 경우, 클라이언트 디바이스는 수신된 BIG에 포함된 BIS1 및 BIS2 중 오디오 데이터 정보가 포함된 BIS1만을 디코딩 할 수 있다. 즉, 클라이언트 디바이스가 사용자로부터 서버 디바이스가 전송하는 오디오 데이터를 수신함을 나타내는 입력 정보를 획득하지 않았으므로, 클라이언트 디바이스가 BIS2에 포함된 오디오 데이터까지 디코딩하게 되면 불필요한 자원 낭비 및 전력 소모가 유발된다.
반면, 클라이언트 디바이스가 사용자로부터 서버 디바이스가 전송하는 오디오 데이터를 수신함을 나타내는 입력 정보를 획득하면, 클라이언트 디바이스의 상태는 Broadcast Stream - Configure procedure에서 Broadcast Stream - Enable procedure로 변경 된다. 이후, 클라이언트 디바이스는 수신된 BIG에 포함된 BIS1 및 BIS2를 모두 디코딩할 수 있다.
위와 같은 동작이 수행되기 위해서, BIS1이 오디오 데이터 정보가 포함되어있는지 여부를 나타내는 지시자 플래그(flag)가 동기화 정보에 포함될 수 있다. 상기 지시자 플래그는 지시 정보로도 표현될 수 있다. 클라이언트 디바이스는 상기 지시자 플래그에 기초하여, 서버 디바이스가 전송하는 브로드캐스트 오디오 데이터에 포함된 오디오 데이터 정보 및 오디오 데이터를 선택적으로 디코딩할 수 있다.
다시 도 23으로 돌아와서, 서버 디바이스는 BIG에 오디오 데이터 정보 및 오디어 데이터를 순차적으로 포함시킬 수 있다(2310). 즉, BIG에 BIS 1->BIS1->BIS2->BIS2 순서로 데이터가 포함될 수 있다.
두 번째로, 서버 디바이스는 BIG에 오디오 데이터 정보 및 오디오 데이터를 번갈아 가며(interleave) 포함시킬 수 있다(2320). 즉, BIG에 BIS1->BIS2->BIS3->BIS4 순서로 데이터가 포함될 수 있다.
도 24는 서버 디바이스가 오디오 데이터와 오디오 데이터 정보를 전송하는 방법의 일 예를 나타낸 도이다.
구체적으로, 도 24는 서버 디바이스가 오디오 데이터 정보를 Aux_adv_indication에 포함시켜 클라이언트 디바이스로 전송하는 예시를 나타낸다. 즉, 서버 디바이스는 오디오 데이터 정보를 Aux_adv_indication PDU에 포함시키고, 오디오 데이터는 Aux_Sync_indication PDU 또는 Aux_Chain_indication PDU에 포함시킨다. 다음, 서버 디바이스는 상기 (i) Aux_adv_indication PDU 및 (ii) Aux_Sync_indication PDU 또는 Aux_Chain_indication PDU를 순차적으로 전송할 수 있다. 여기서, Aux_adv_indication PDU는 프라이머리 물리 광고 채널 상으로 전송될 수 있고, Aux_Sync_indication PDU 또는 Aux_Chain_indication PDU는 세컨더리 물리 광고 채널 상으로 전송될 수 있다.
오디오 데이터 정보는 Aux_Adv_Indication 패킷에 포함된 ADATA 필드에 포함될 수 있는데, 상기 ADATA 필드의 저장 공간이 오디오 데이터 정보를 포함시키기에 충분하지 않은 경우, 다음 번 전송되는 Aux_Chain_indication 패킷에 오디오 데이터 정보의 나머지 데이터가 포함될 수 있다.
또한, 클라이언트 디바이스가 오디오 피드백 정보를 정확하게 디코딩할 수 있도록 하기 위하여, 서버 디바이스는 Aux_Adv_Indication PDU가 오디오 데이터 정보를 포함하고 있음을 나타내는 지시자 플래그를 Aux_Adv_Indication PDU에 포함시킬 수 있다. 클라이언트 디바이스는 상기 지시자 플래그에 기초하여, 오디오 데이터 정보가 Aux_Adv_Indication PDU에 포함됨을 인지할 수 있다.
이후, 클라이언트 디바이스는 Aux_Adv_Indication 패킷의 ADATA 필드에 포함되어 있는 오디오 데이터 정보를 디코딩하여, 출력(play)할 수 있다.
클라이언트 디바이스는 이후에 Aux_Sync_Indication PDU 프로세싱을 수행해야 한다. 따라서, 클라이언트 디바이스의 Aux_Sync_Indication PDU 프로세싱에 미치는 영향을 최소화하기 위해, 출력되는 오디오 데이터 정보는 수초 정도의 짧은 시간 길이로 설정될 수 있다.
사용자는 클라이언트 디바이스가 출력한 음성 데이터 정보를 청취하고, 오디오 데이터를 수신함을 나타내는 정보를 입력할 수 있다. 이 경우, 클라이언트 디바이스의 상태는 Broadcast Streaming - Configuration procedure 상태에서 Broadcast Streaming - Enable procedure 상태로 변경된다.
이후, 클라이언트 디바이스는 Aux_Sync_indication(및 그 이후의 Aux_Chain_Indication)에 포함되어 있는 Audio 데이터를 수신하여, 디코딩한다.
도 25는 본 명세서에서 제안하는 오디오 데이터 정보에 기초한 오디오 데이터 전송 방법이 수행되는 일 예를 나타낸 도이다.
구체적으로, 도 25는 복수의 서버 디바이스가 전송하는 오디오 데이터를 클라이언트 디바이스가 수신하는 과정에 대한 예시이다.
여러 대의 서버 디바이스가 브로드캐스트 오디오 데이터를 전송하는 경우, 클라이언트 디바이스는 여러 대의 서버 디바이스가 전송한 복수의 브로드캐스팅 오디오 데이터를 검색하게 된다.
이러한 경우, 먼저, 사용자가 복수 개의 서버 디바이스가 전송하는 오디오 데이터들 중 하나의 오디오 데이터만을 선택하는 경우, 클라이언트 디바이스는 수신한 복수의 오디오 데이터들에 대응하는 오디오 데이터 정보들을 각각 서로 다른 시점에 출력할 수 있다.
사용자는 서로 다른 시점에 출력된 오디오 데이터 정보들 중 특정한 오디오 데이터를 수신하겠음을 지시하는 정보를 입력한다. 이후 사용자는 선택된 오디오 데이터를 청취할 수 있다.
두 번째로, 사용자는 복수 개의 서버 디바이스가 전송하는 오디오 데이터들 중 어떠한 오디오 데이터도 선택하지 않을 수 있다. 이 때, 클라이언트 디바이스는 각 오디오 데이터와 관련된 오디오 데이터 정보의 반복 출력 횟수를 제한할 수 있다. 반복 출력 횟수는 대략 3~5회 정도로 제한될 수 있으며, 음성 피드백이 반복되는 동안 어떠한 정보도 입력하지 않으면 더 이상 음성 피드백을 출력하지 않을 수 있다.
마지막으로, 사용자는 청취를 희망하지 않았던 서버 디바이스의 오디오 데이터를 재청취하기를 희망할 수 있다. 이러한 경우, 클라이언트 디바이스는 프라이머리 채널의 광고 패킷(Advertising packet)(AUX_EXT)의 신호세기를 계속하여 모니터링할 수 있다. 클라이언트 디바이스가 서버 디바이스가 클라이언트 디바이스로부터 가까운 거리에 위치하는 것으로 판단한 경우, 클라이언트 디바이스는 동기화 정보를 수신하여, 오디오 데이터 정보를 출력한다.
서버 디바이스에 고유한 음성 피드백 설정 방법
도 26 및 27은 클라이언트 디바이스가 서버 디바이스에 오디오 데이터 정보를 설정하는 방법의 일 예를 나타낸 도이다.
서버 디바이스가 제공 중인 특정 프로그램이 실시간으로 변화하는 경우, 프로그램의 변화가 반영되지 않은 오디오 데이터 정보가 반복하여 출력된다면 사용자는 서버 디바이스가 전송하는 오디오 데이터가 변화했음을 파악하기 어려울 수 있다.
따라서, 서버 디바이스가 제공하는 프로그램이 변경된 경우, 프로그램의 오디오 데이터에 대한 오디오 데이터 정보를 변경해야 할 필요가 있다. 서버 디바이스에 설정된 오디오 데이터 정보를 변경하기 위해서, 본 방법은 upload GATT Service를 구성하여, GATT Service를 이용하여 서버 디바이스에 저장된 오디오 피드백 정보를 을 변경하는 방법을 제안한다.
구체적으로, GATT client(클라이언트 디바이스)는 GATT server(서버 디바이스)로부터 광고 패킷을 수신하고(S2610), GATT client는 GATT server 와 연결을 형성한다(S2620).
다음, GATT client는 GATT server로 GATT Server의 상태 특성(Status characteristic)에 저장되어 있는 상기 오디오 데이터 정보의 상태 정보의 판독을 요청하는 판독 요청 메시지를 상기 서버 디바이스로 전송하고, 다음, 상기 GATT client는 상기 서버 디바이스로부터 상기 상태 정보를 포함하는 판독 응답 메시지를 수신한다(S2630).
도 27에 도시된 바와 같이, 상기 상태 정보는 상기 오디오 데이터의 이름 정보, 상기 오디오 데이터 정보가 상기 제 1 특정 특성에 저장된 날짜 정보 또는 상기 오디오 데이터 정보의 버전(Version) 정보 중 적어도 하나를 포함할 수 있다.
다음, GATT client는 GATT server로 상기 상태 정보에 기초하여 상기 오디오 피드백 정보의 변경을 위해서 상기 서버 디바이스의 제 2 특정 특성에 변경된 오디오 피드백 정보와 관련된 특성 값(Characteristic value)의 기입을 요청하는 기입 요청 메시지를 전송한다(S2640).
상기 기입 요청 메시지는 상기 변경된 오디오 피드백 정보를 구성하는 데이터 중 일부의 데이터를 포함할 수 있다.
도 26에 도시되어 있지는 않지만, 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)를 적용하여 전송한다.
도 28 및 도 29는 관리 서버 디바이스가 클라이언트 디바이스에게 서버 디바이스들의 동기화 정보를 제공하는 방법의 일 예를 나타낸 도면이다.
관리 서버 디바이스는 주변의 서버 디바이스(Broadcast Advertiser)들로부터 각각 동기화 정보를 수신할 수 있다. 관리 서버 디바이스는 수신한 주변의 서버 디바이스의 브로드캐스트 동기화 정보를 다른 브로드캐스트 스캐너 디바이스(클라이언트 디바이스)에 전송할 수 있다. 이와 같은 방식으로, 클라이언트 디바이스가 다수의 서버 디바이스들과 동기를 맞추기 위해 여러 번 scan을 수행해야 하는 부담이 감소될 수 있다. 이러한 방식은 “Scan Offloading” 으로 표현될 수 있다.
복수의 서버 디바이스가 BLE 오디오 브로드캐스팅을 하고 있는 경우, 클라이언트 디바이스는 각각의 서버 디바이스로부터 오디오 데이터 정보를 수신 할 수 있다. 하지만, 이러한 방식보다는 관리 서버 디바이스가 한번에 모든 서버 디바이스의 오디오 피드백 정보를 클라이언트 디바이스에게 전송하는 것이 클라이언트 디바이스의 사용성을 향상시킬 수 있다. 관리 서버 디바이스는 클라이언트 디바이스에게 모든 서버 디바이스들의 동기화 정보를 전달하기 위해서 BLE PAST(PAST(Periodic Advertising Sync Transfer)기술을 사용할 수 있다.
도 28과 같이, 관리 서버 디바이스가 클라이언트 디바이스에게 전송하는 모든 서버 디바이스들의 동기화 정보를 포함하는 전체 동기화 정보는 음성 데이터 전송을 위한 별도의 브로드캐스트 채널을 통하여 전송될 수 있다.
도 29에서, 클라이언트 디바이스는 관리 서버로부터 별도의 브로드캐스트 채널을 통하여 전체 동기화 정보를 수신한다(S2910).
다음, 클라이언트 디바이스는 전체 동기화 정보에 기초하여 주변의 서버 디바이스들로부터 오디오 데이터를 수신한다(S2920).
추가적으로, 블루투스 bonding은 Central(master)기기와 Peripheral(slave)기기간 페어링(pairing)을 위해 사용된 encrypt key를 양쪽에 저장(캐싱)해 두어, 나중에 연결할 때 편리하게 하는 방식을 의미한다.
오디오 피드백 정보는 BLE Audio Broadcasting 환경에서 빈번하게 사용될 데이터로 간주하여, 미리 저장해 둘 수 있다. 서버 디바이스가 한 대만 있더라도, 빈번하게 수신되는 환경이라면 오디오 피드백 정보를 나중에 사용하기 위해 저장(캐싱)할 수 있다.
도 30은 본 명세서에서 제안하는 블루투스 기술을 이용하여 오디오 데이터를 수신하는 방법이 수행되는 예시들을 나타낸다.
도 30(a)는 하나의 서버 디바이스가 전송하는 브로드캐스트 오디오 데이터를 복수의 클라이언트 디바이스가 수신하는 예시에 해당한다. 본 방법은 이와 같이 하나의 서버 디바이스가 전송하는 브로드캐스트 오디오 데이터를 복수의 클라이언트 디바이스가 수신하는 경우에도 적용될 수 있다.
도 30(b)는 복수의 서버 디바이스가 전송하는 브로드캐스트 오디오 데이터를 복수의 클라이언트 디바이스가 수신하는 예시에 해당한다. 본 방법은 이와 같이 복수의 서버 디바이스가 전송하는 브로드캐스트 오디오 데이터를 복수의 클라이언트 디바이스가 수신하는 경우에도 적용될 수 있다.
도 31은 본 명세서에서 제안하는 블루투스 기술을 이용하여 오디오 데이터를 수신하는 방법이 수행되는 예시를 나타낸다.
보다 구체적으로 도 31은 공항에 설치된 TV(서버 디바이스)가 방송 중인 브로드캐스트 오디오 데이터를 서버 디바이스가 수신하는 경우에 관한 것이다.
여기서, 서버 디바이스가 방송 중인 오디오 데이터에 대한 정보인 오디오 데이터 정보는 다양한 언어로 전송될 수 있다.
추가적으로, 클라이언트 디바이스에 희망하는 언어가 미리 설정될 수 있고, 이 경우, 클라이언트 디바이스는 설정된 언어와 동일한 언어로 생성된 오디오 데이터 정보만을 수신할 수 있다.
도 32는 본 명세서에서 제안하는 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 클라이언트 디바이스에서 구현되는 동작의 일례를 나타낸 도이다.
보다 구체적으로, 블루투스 저전력(Bluetooth Low Energy) 기술을 이용하여 오디오 데이터를 수신하는 방법에 있어서, 클라이언트 디바이스에 의해 수행되는 방법은, 상기 클라이언트 디바이스가 오디오 스트리밍 서비스(Audio Streaming Service)의 제공을 위한 정보를 포함하는 제 1 광고 메시지를 서버 디바이스로부터 수신한다(S3210).
다음, 상기 클라이언트 디바이스는 상기 클라이언트 디바이스와 상기 서버 디바이스 간의 동기화를 위한 동기화 정보를 포함하는 제 2 광고 메시지를 상기 서버 디바이스로부터 수신한다(S3220).
여기서, 상기 동기화 정보는 상기 브로드캐스트 오디오 데이터의 타이밍 정보 및 상기 오디오 데이터의 수신을 위한 주파수 호핑(frequency hopping) 정보를 포함할 수 있다.
이후. 상기 클라이언트 디바이스는 상기 오디오 스트리밍 서비스의 오디오 데이터가 상기 오디오 데이터 대한 오디오 데이터 정보와 그룹핑되어 전송됨을 나타내는 지시자를 포함하는 제 3 광고 메시지를 상기 서버 디바이스로부터 수신한다(S3230).
다음, 상기 클라이언트 디바이스는 상기 지시자에 기초하여 등시 채널(isochronous channel)을 통해 그룹핑된 상기 오디오 데이터 및 상기 오디오 데이터 정보를 포함하는 브로드캐스트 오디오 데이터를 상기 서버 디바이스로부터 수신한다(S3240).
여기서, 상기 브로드캐스트 오디오 데이터를 식별하기 위한 그룹핑 ID(identifier)가 상기 브로드캐스트 오디오 데이터에 할당되고, 상기 오디오 데이터를 식별하기 위한 오디오 데이터 ID가 상기 오디오 데이터에 할당되고, 상기 오디오 데이터 정보를 식별하기 위한 오디오 데이터 ID가 상기 오디오 데이터 정보에 할당될 수 있다.
또한, 상기 오디오 데이터 및 상기 오디오 데이터 정보는 인터리빙(interleaving)되어 그룹핑 될 수 있다.
또한, 또한, 상기 오디오 데이터는 상기 서버 디바이스가 제공하는 특정한 프로그램과 관련된 오디오 데이터이고, 상기 오디오 데이터 정보는 상기 특정한 프로그램의 제목을 나타낼 수 있다.
이후, 상기 클라이언트 디바이스는 상기 오디오 데이터 정보에 기초하여 사용자로부터 상기 오디오 스트리밍 서비스의 제공의 허용 여부와 관련된 특정 정보를 획득한다(S3250).
마지막으로, 상기 클라이언트 디바이스는 상기 특정 정보가 상기 오디오 데이터의 제공의 허용을 나타내는 경우, 상기 오디오 데이터를 디코딩 한다(S3260).
추가적으로, 상기 클라이언트 디바이스는 상기 오디오 데이터 정보를 디코딩할 수 있다. 여기서, 상기 사용자로부터 상기 특정 정보의 획득 전에는 상기 오디오 데이터 및 상기 오디오 데이터 정보 중에서 상기 오디오 데이터 정보만이 디코딩 될 수 있다.
또한, 상기 클라이언트 디바이스는 상기 디코딩된 오디오 데이터 정보를 출력할 수 있다.
추가적으로, 상기 클라이언트 디바이스는 상기 서버 디바이스와 연결을 형성하고, 상기 서버 디바이스의 제 1 특정 특성(Characteristic)에 저장되어 있는 상기 오디오 데이터 정보의 상태 정보의 판독을 요청하는 판독 요청 메시지를 상기 서버 디바이스로 전송할 수 있다.
여기서, 상기 상태 정보는 상기 오디오 데이터의 이름 정보, 상기 오디오 데이터가 상기 제 1 특정 특성에 저장된 날짜 정보 또는 상기 오디오 데이터의 버전(Version) 정보 중 적어도 하나를 포함할 수 있다.
이후, 상기 클라이언트 디바이스는 상기 서버 디바이스로부터 상기 상태 정보를 포함하는 판독 응답 메시지를 수신할 수 있다.
추가적으로, 상기 클라이언트 디바이스는 상기 상태 정보에 기초하여 상기 오디오 데이터 정보의 변경을 위해서 상기 서버 디바이스의 제 2 특정 특성에 변경된 오디오 데이터 정보와 관련된 특성 값(Characteristic value)의 기입을 요청하는 기입 요청 메시지를 상기 서버 디바이스로 전송할 수 있다. 여기서, 상기 기입 요청 메시지는 상기 변경된 오디오 데이터 정보를 구성하는 데이터 중 일부의 데이터를 포함할 수 있다.
이후, 상기 클라이언트 디바이스는 상기 기입 요청 메시지에 대한 응답으로 기입 응답 메시지를 상기 서버 디바이스로부터 수신할 수 있다.
여기서, 상기 기입 요청 메시지는 각각은 상기 일부의 데이터들에 대한 시퀀스 번호 정보를 포함할 수 있다.
추가적으로, 상기 클라이언트 디바이스는 상기 서버 디바이스를 포함하는 복수의 서버 디바이스들을 관리하는 관리 서버로부터 상기 복수의 서버 디바이스들과 상기 클라이언트 디바이스 간의 동기화와 관련된 전체 동기화 정보를 수신할 수 있다.
여기서, 상기 전체 동기화 정보는 상기 복수의 서버 디바이스들 각각에 대한 동기화 정보를 포함할 수 있다.
여기서, 상기 복수의 서버 디바이스들 각각에 대한 동기화 정보는 상기 관리 서버에 사전에(previously) 저장될 수 있다.
추가적으로, 상기 클라이언트 디바이스는 상기 제 1 광고 메시지의 수신 신호 세기를 측정할 수 있다.
이 때, 상기 클라이언트 디바이스는 상기 제 1 광고 메시지의 상기 수신 신호 세기가 특정한 임계 값 이상인 경우, 상기 제 1 광고 메시지를 디코딩 할 수 있다.
브로드캐스트 TV 프로파일(Broadcast TV profile)
브로드캐스트 TV 프로파일은 브로드캐스트 TV initiator 및 Acceptor에 대한 메타 데이터 및 절차를 제공한다. 이 프로파일은 ASCP를 기반으로하며, initiator가 주변의 acceptor에게 자신을 announcing 할 때의 브로드 캐스트 메타 데이터를 정의한다. Initiator는 서버 디바이스일 수 있고, Acceptor는 클라이언트 디바이스일 수 있다.
도 33은 브로드캐스트 프로파일의 계층적 구조를 나타낸 도이다.
ASCP을 기반으로하여, initiator인 브로드캐스트 TV는 브로드캐스트 방식으로 데이터 등을 전송할 수 있다. 외부 디바이스들인 Acceptor들은 이를 수신할 수 있고, 유니캐스트 방식으로 상기 initiator와 통신할 수 있다.
블루투스 표준과의 호환성(Bluetooth specification release compatibility)
브로드캐스트 TV 프로파일은 등시채널을 지원하는 Milan 버전의 블루투스 표준과 호환된다.
브로드 캐스트 TV 프로파일에서, PDU (Protocol Data Unit) 또는 기타 데이터 구조의 필드가 'Reserved for Future Use' 로 표시된 경우, 달리 명시하지 해당 필드 값은 0으로 설정된다. 또한, 해당 필드와 관련한 별도의 설명이 없는한 해당 필드를 수신한 디바이스에 의해 무시되거나 해석되지 아니할 수 있다.
필드 값이 enumeration이면 할당되지 않은 값은 "금지됨(Prohibited)"으로 표시 될 수 있다. 이러한 값은 implementation에 의해 사용되지 않으며, Prohibited을 나타내는 값(value)을 포함하는 수신 된 메시지는 무시되고 처리되지 않으며, 이를 수신한 디바이스는 이에 대하여 응답하지 않아야 한다.
필드, 매개 변수 또는 기타 변수 개체가 값의 범위를 가질 수 있고 일부 값이 "금지됨"을 나타내는 경우, 디바이스는 개체를 prohibited 값들로 설정해서는 안된다. 그러한 값을 가진 객체를 수신한 디바이스는 이를 거부(reject)하고, 이를 포함하는 모든 데이터 구조는 잘못된 것으로 간주해야 한다.
도 34는 브로드캐스트 TV initiator와 브로드캐스트 TV Acceptor의 관계를 예시한다.
도 34에서, 브로드캐스트 TV Initiator와 브로드캐스트 TV Acceptor의 두 가지 역할이 정의된다.
브로드캐스트 TV Initiator는 프로그램 정보 메타 데이터를 브로드 캐스트하는 디바이스를 의미한다.
브로드캐스트 TV Acceptor는 주기적 광고(periodic advertising) 를 통해 프로그램 정보 메타 데이터를 스캔하고 이를 브로드캐스트 스트림 수신에 사용하는 디바이스를 의미한다.
브로드캐스트 TV Initiator는 broadcaster이고, (core specification Vol3, 파트 C, GAP, 2.2.2.1), 브로드캐스트 TV Acceptor는 observer일 수 있다. (core specification Vol3, 파트 C, GAP, 2.2.2.2)
브로드캐스트 TV 프로파일의 토폴로지는 LE 오디오 브로드캐스트에만 적용될 수 있다. 또한, 상기 프로파일에 의해 부과 된 브로드캐스트 TV Initiator 또는 브로드캐스트 TV Acceptor에 대한 동시성 제한이나 제한은 없다.
유저 시나리오(User Scenarios)
체육관, 버스, 상점, 공항 및 카페테리아 등 많은 공공 장소에서 TV가 이용 가능하다. 공공장소에 존재하는 TV는 일반적으로 음소거된 상태로 제공된다. 따라서, 사용자는 본 프로파일에서 제공되는 LE 오디오 브로드캐스트를 통하여 시청하고자 하는 프로프로그램과 관련된 오디오 데이터를 청취할 수 있다.
LE 오디오 브로드캐스트 시나리오는 HA 및 HQA FRD에 대략적으로 설명되어 있다.
사용자가 관심있는 TV를 손쉽게 검색하기 위해서는, TV에서 방송 중인 프로그램을 식별하기 위한 방송 프로그램에 대한 정보가 필요할 수 있다. 즉, 방송 프로그램의 오디오와 관련된 오디오 데이터 정보가 필요할 수 있다.
이 정보를 사용하면 사용자는 스마트 폰, 헤드폰 또는 스피커등과 같은 Acceptor가 브로드캐스트 프로그램을 식별할 수 있다. 따라서, Acceptor는 결과적으로 LE 오디오 브로드 캐스트에서 사용 가능한 프로그램을 사용자에게 알려줄 수 있다. 브로드캐스트 TV 오디오 프로파일이 적용되는 시나리오는 사용자가 TV 프로그램에 대한 알림만을 받을 수 있는 공개 시나리오에 적용될 수 있다. 즉, 브로드캐스트 TV 오디오 프로파일이 적용되는 시나리오에서는, 사용자가 일반적으로 채널을 변경할 수 없다. 따라서, 사용자가 원격으로 TV에서 제공되고 있는 채널을 변경할 수 시나리오에서는, 브로드캐스트 TV 오디오 프로파일이 적용되기 어려울 수 있다.
도 35는 브로드캐스트 TV 오디오 프로파일이 적용될 수 있는 시나리오의 일 예를 나타낸다.
LE 오디오 브로드캐스트의 경우 Initiator(3510)는 신호(signal)와 데이터를 브로드캐스트 한다. 여기서 Initiator는 TV 등 일 수 있다.
상기 신호는 프로그램을 조정(tune)하기 위한 주기적인 정보(BigInfo) 및 프로그램 설명 (Program Info)일 수 있다. 데이터는 TV 프로그램과 관련된 오디오를 운반하는 실제 오디오 데이터일 수 있다.
도 35(a)에서, Acceptor(3520)에서는 Acceptor와 사용자 간의 상호 작용이 발생한다. 즉, 사용자는 Acceptor의 디스플레이를 보고 TV 프로그램을 탐색할 수 있다. 상기 Acceptor는 스마트폰 일 수 있다. 사용자는 Acceptor와 유선으로 연결된 헤드셋(3530)을 통하여 Acceptor가 수신한 오디오 데이터를 청취할 수 있다.
도 35(b)에서와 같이, 기존의 Acceptor는 검색된 Initiator들의 목록만을 표시할 뿐, 각각의 Initiator들이 방송중인 프로그램에 대한 정보를 표시해주지 않는다. 즉, 기존의 Acceptor는 검색된 Initiator의 이름(예를 들어, LG-TV 또는 Sony-TV 등)만을 사용자에게 표시하여 준다. Initiator가 한 대만 있는 경우는 사용자에게 불편함을 초래하지 않지만, 복수대의 Initiator가 존재하는 경우, 사용자는 본인이 청취하기를 희망하는 오디오 데이터를 청취하기 어려울 수 있다.
LE 오디오 브로드캐스트 프로파일을 적용함으로써, Acceptor는 프로그램 정보 메타 데이터에 기초하여, 사용자에게 Initiator가 방송 중인 프로그램에 대한 정보를 사용자에게 알려줄 수 있다. 예를 들어, Acceptor가 스마트 폰인 경우, 스마트 폰의 UI를 통하여 사용자에게 현재 방송중인 프로그램을 표시 할 수 있다. 만약 UI가 없는 디바이스인 경우라면, 음성을 출력하는 방식 등을 통하여 사용자에게 프로그램 정보를 알려줄 수 있다. 따라서, 사용자는 본인이 시청하고자 하는 프로그램을 방송 중인 TV를 용이하게 찾을 수 있다. 또한, 만약 Initiator인 TV가 한 대만 존재하는 경우에도, TV의 프로그램 정보는 사용자에게 유용하게 사용될 수 있는 것은 당연하다. 또한, Acceptor가 Initiator와 동기화를 마친 후, 프로그램 관련 오디오 데이터 수신 여부에 대한 사용자의 선택기회 없이, 곧바로 오디오 데이터를 출력하게 되면, 사용자는 원하지 않는 오디오 데이터를 청취하게 됨으로써 불편함을 겪을 수도 있다.
도 36은 프로그램 정보에 기초하여 사용자에게 Initiator가 방송 중인 프로그램에 대한 정보를 알려주는 일 예를 나타낸다.
도 36에서, 현재 Initiator에서 "ESPN Sports-Baseball LA dodgers vs. New-York Yankees" 프로그램을 방송하고 있는 경우, Initiator로부터 상기 프로그램에 대한 정보를 제공 받을 수 있다. 프로그램에 대한 정보는 기존 TV 서비스 제공 업체의 EPG 데이터에서 자동으로 추출 될 수 있다. 또한, Initiator가 프로그램 정보가 설정되어 있지 않은 프로그램을 재생하고 있는 경우, 프로그램 정보는 TV 사용자에 의해서 수동으로 설정 될 수 있다.
도 37은 브로드캐스트 TV 오디오 프로파일이 적용될 수 있는 시나리오의 또 다른 일 예를 나타낸다.
LE 오디오 브로드캐스트의 경우 Initiator(3710)는 신호(signal)와 데이터를 브로드캐스트 한다. 여기서 Initiator는 TV 등일 수 있다.
도 37에서, 헤드폰(3720)에서는 헤드폰과 사용자 간의 상호 작용이 발생한다. 사용자는 된 헤드폰(3730)을 통하여 프로그램 정보를 청취할 수 있다.
브로드 캐스트 TV 시나리오 장치 설정
도 38은 브로드 캐스트 TV 시나리오 장치 설정 방식의 다양한 예시들을 나타낸다.
도 38에서, 사용자는 스마트 폰을 통하여 TV 앱(App)을 찾거나 메뉴를 탐색하고 TV 프로그램을 선택해야한다. 스마트 폰에는 기존의 디스플레이 및 터치 UI 인터페이스가 탑재되어 있을 수 있다.
사용자는 헤드폰을 통해서 음성 (또는 소리)을 들을 수 있다. 사용자는 스마트 폰의 디스플레이 상에 표시된 프로그램 정보를 클릭하거나, 헤드폰에 탑재된 버튼을 클릭하여 프로그램에 대한 메인 오디오 데이터를 청취할 수 있다. 여기서, 헤드폰에는 사용자가 특정 프로그램에 대한 오디오 데이터를 OFF하는 동작을 감지하기 위한 클릭 버튼이나 모션 센서가 있을 수 있다. 헤드폰은 개념적으로 하나 또는 두 개의 이어폰, 넥 밴드 또는 이어 버드와 동일할 수 있다.
도 38(a)에서, 스마트 폰은 헤드폰과 유선으로 연결되어 있다. LE 브로드캐스트는 Initiator인 TV와 스마트 폰 사이에 적용될 수 있다. TV는 BigInfo 및 Program Info와, TV가 방송 중인 TV 프로그램과 관련된 오디오를 운반하는 실제 오디오 데이터를 헤드폰으로 전송할 수 있다.
도 38(b)에서, 스마트 폰은 헤드폰과 BR/EDR 또는 LE 유니캐스트를 통하여 무선으로 연결된다. LE 브로드캐스트는 Initiator인 TV와 스마트 폰 사이에 적용될 수 있다. TV는 BigInfo 및 Program Info와, TV가 방송 중인 TV 프로그램과 관련된 오디오를 운반하는 실제 오디오 데이터를 헤드폰으로 전송할 수 있다.
도 38(c)에서, 스마트폰은 TV로부터 BigInfo 및 Program Info를 수신하고, PAST(periodic advertising sync transfer)를 통하여 동기화 정보를 헤드폰으로 전달한다. 이러한 방식을 scan offloading으로 호칭할 수 있다. 헤드폰은 상기 동기화 정보를 사용하여 데이터를 TV로부터 수신할 수 있다.
도 38(d)에서, 헤드폰은 LE 브로드캐스트 데이터를 TV로부터 직접 수신할 수 있다.
도 39는 확장된 광고 PDU에 포함되는 데이터 필드 구성의 일 예를 나타낸다.
도 39(a)는 확장된 광고 PDU의 페이로드 필드에 포함되는 확장된 헤더 필드의 일 예를 나타낸다. 상기 필드는 1 octet 크기의 확장된 헤드 플래그(Extended Header Flag), 광고 메시지를 전송하는 디바이스의 주소를 나타내는 6 octet 크기의 AdvA 필드, 6 octet 크기의 Target A 필드, 데이터와 관련된 정보를 포함하는 2 octet 크기의 AdvDataInfo(ADI) 필드, 동기화 정보를 포함하는 18 octet 크기의 Syncinfo 필드, 전송 전력을 나타내는 1 octet 크기의 TxPower 필드 및 오디오 데이터를 포함하는 다양한 크기를 갖는 ACAD 필드를 포함한다.
도 39(b)는 확장된 광고 메시지에 포함된 페이로드 필드의 일 예를 나타낸다. 상기 필드는 6 비트 크기의 확장된 헤더 길이 필드(Extended Header Length), 광고메시지가 전송되는 모드(Mode)를 나타내는 2 비트 크기의 AdvMode 필드, 0-63 octet크기를 갖는 Extended header 필드 및 오디오 스트리밍 서비스를 통하여 제공되는 오디오 데이터가 포함되는 0-254 octet 크기를 갖는 AdvData 필드를 포함할 수 있다.
도 40은 AUX_SYN_IND_PDU에 포함되는 데이터 필드 구성의 일 예를 나타낸다.
AUX_SYN_IND_PDU는 AdvA, Tartget A, CTE info 필드 등을 포함하는데, 도 40에서 O는 선택적으로 포함될 수 있음을 나타내고, X는 향후 사용을 위해 남겨둠을 의미한다.
브로드캐스트 TV Initiator 역할 요구사항
브로드캐스트 TV Initiator는 브로드캐스트 오디오 announcement를 주기적으로 수행한다. 브로드캐스트 오디오 announcement에는, 채널을 튜닝하기 위한 타이밍 정보 획득을 위한 메타 데이터가 있고, 또한 TV 프로그램 자체를 설명하기 위한 프로그램 정보 메타 데이터가 있다.
타이밍 정보는 BIGINFO의 ACAD 필드에 위치하고, 프로그램 정보는 AUX_SYNC_IND packet에 있는 ProgramInfo와 같이 AdvData 필드에 위치한다.
프로그램 정보는 현재 TV가 방송 중인 사람이 인지 가능한 정보일 수 있다.
예를 들어, TV가 스포츠 중계, 일기 예보 또는 뉴스 등 전통적인(conventional) 프로그램을 재생하는 경우, 프로그램 정보는 방송 프로그램의 제목일 수 있다. TV가 백화점에서 상업적 메시지를 재생하고 있는 경우, 상기 프로그램 정보는 상업적 메시지 알림일 수 있다. 만약 티비가 공항에서 비행기의 도착/출발 정보를 재생한다면 상기 정보는 공항 알림에 대한 것일 수 있다.
도 39 및 40은 프로그램 정보 메타 데이터의 위치를 설명한다.
AUX_SYNC_IND 패킷에는 2 개의 별도 메타 데이터 필드가 있다. ACAD는 핵심 사양으로 정의되고 방송 스트림의 타이밍에 사용되는 BIGInfo를 보유하고, AdvData는 여기에서 정의되고 방송 스트림을 설명하는 데 사용되는 ProgramInfo를 보유한다.
BIGInfo의 길이는 암호화되지 않은 BIG의 경우 33 옥텟이고 암호화된 BIG의 경우 57 옥텟이다. AUX_SYNC_IND 패킷 크기가 254이므로 AdvData의 ProgramInfo는 암호화되지 않은 BIG에 대해 254 - (33 + 4)를 차지할 수 있다.
도 41은 BLE 브로드캐스트 오디오 동작의 일 예를 나타낸다.
서버 디바이스는 프라이머리(Primary) 물리 광고 채널(physical advertising channel)을 통하여 Aux_Ext_indication 타입의 광고 PDU를 포함하는 확장된 광고 메시지(extended advertising message)를 전송한다. 상기 프라이머리 물리 광고 채널은 37 내지 39 번 채널일 수 있고, 상기 광고 메시지에는 확장된 광고 메시지(Extended Advertising message)가 전송되는 채널 정보가 포함될 수 있다. 상기 확장된 광고 메시지는 확장된 광고 메시지의 전송과 관련된 이벤트 타입에 기초하여 AdvA, ADI, Aux Ptr, ADId, Ch#_Aux_Adv, Offset 필드 중 적어도 하나를 포함할 수 있다.
서버 디바이스는 세컨더리(Secondary) 물리 광고 채널을 통하여 Aux_Adv_indication 타입의 광고 PDU를 포함하는 확장된 광고 메시지를 전송한다. 상기 세컨더리 물리 광고 채널은 0 내지 36번 채널일 수 있다.
도 41에 도시된 바와 같이 세컨더리 물리 광고 채널 상으로 전송되는 확장된 광고 메시지는 동기화 정보(syncinfo) 등을 포함할 수 있다.
다음, 서버 디바이스는 확장된 광고 메시지를 주기적으로 전송한다. 상기 확장된 광고 메시지는 Aux_Sync_indication 타입의 광고 PDU를 포함할 수 있다. 상기 광고 PDU는 Aux Ptr, ACAD, ADATA Ch#_Aux_chain, offset BIGInfo(ACAD), Metadata(ADATA) 필드 중 적어도 하나를 포함할 수 있고, 광고 데이터(Advdata) 필드를 포함할 수 있다. 상기 광고 데이터 필드는 프로그램 정보(programinfo)를 포함할 수 있다.
이후, 서버 디바이스는 오디오 데이터를 포함하는 BIS data Packet과 오디오 스트리밍 서비스를 제공하기 위한 제어 정보를 포함하는 control packet를 전송할 수 있다. 상기 BIS data packet과 control packet은 등시 채널을 통하여 주기적으로 전송될 수 있다. 사용자는 상기 프로그램 정보에 기초하여 BIS data Packet에 포함된 오디오 데이터를 수신할 지 여부를 결정할 수 있다.
Programinfo 텍스트 메타 데이터
대부분의 TV는 EPG UI를 draw하기 위해 지상파, 케이블, 위성 또는 IP 방송으로부터 EPG (Electronic Program Guide) 데이터를 수신한다(ATSC A / 65, DVB SI (ETSI EN 300 468) 참조).
여기서, TV 방송 프로필에 사용된 ProgramInfo 메타 데이터는 EPG 데이터에서 발췌 한 현재 프로그램 정보일 수 있다. 현재 프로그램이 변경되면 이에 따라 ProgramInfo가 변경될 수 있다. 텍스트 메타 데이터는 주로 화면 UI를 사용할 수 있는 스마트 폰에서 디코딩 될 수 있다.
아래의 표는 Programinfo 메타 데이터의 일 예를 나타낸다.
Figure PCTKR2020003270-appb-T000002
다국어를 지원하는 경우 Laguge count에 따라 ISO_639_language_code에서 ProgramInfo Text로 반복된다.
여기서 문자 세트를 설정하는 옵션은 아래와 같다.
Option1>BT 할당 번호 열거 5 비트를 사용하지만 UTF-8이 존재하지 않으면 확장한다.
Option2> "ISO-8859-1"과 같은 전체 문자열을 사용한다. 본 옵션은 많은 공간을 차지한다.
Option3> 2 세트 만 허용한다. 서양 언어의 경우 ISO-8859-1, UTF-8의 경우 다른 언어를 사용.
ProgramInfo 오디오 메타데이터(Audio Metadata)
스마트폰과 헤드폰이 유선으로 연결된 시나리오 B에서, 사용자는 헤드폰에서 음성 (또는 소리) 프로그램 정보를 들을 수 있으며, 버튼을 클릭하거나 헤드를 끄면 TV 프로그램을 직접 선택할 수 있다.
모든 UI 동작은 화면 UI를 사용할 수 없는 헤드폰에서 발생한다. 여러 언어를 선택하기위한 헤드폰 UI가 제한되어 있으므로 가장 선호하는 언어 프로그램 정보는 하나만 권장된다.
오디오 프로그램 정보를 사용자에게 제공하기 위해 두 가지 접근 방식이 사용될 수 있다.
먼저, 오디오 정보는 텍스트 정보를 사용하여 TTS (Text to Speech)에 의해 Acceptor에서 준비될 수 있다. ProgramInfo 텍스트를 사용한 TTS (Text to Speech) 변환은 스마트 폰에서 수행 할 수 있거나 헤드폰이 TTS를 만들기에 충분한 성능을 가진 경우 자체적으로 TTS 오디오 사운드를 생성 할 수 있다.
둘째, 오디오 정보는 텍스트 정보 또는 자체 오디오 생성 메커니즘을 사용하여 TTS에 의해 Initiator 에서 준비된다.
TV는 ProgramInfo Text를 사용하여 TTS를 수행하고 오디오를 전송할 수 있다. TTS 사운드와 함께 배경 사운드 / 효과가 혼합 될 수도 있다. 또는, 자체 프로그램 정보 오디오가 만들어 질 수 있다. 헤드폰에서 쉽게 디코딩 할 수 있도록 ProgramInfo 오디오 메타 데이터 BIS는 BIG의 첫 번째 BIS (BIS 번호 1)일 수 있다.
2 피스 (왼쪽 및 오른쪽) ear bud의 경우, 간단한 구현을 위해 Broadcast TV Initiator에서 하나의 BIS가 왼쪽 및 오른쪽 채널을 운반하는 것이 유리할 수 있다. BIS가 튜닝 한 각 이어 버드는 개별 채널을 추출할 수 있다.
일반적으로 TV 오디오 출력은 단순 Mono이며 오른쪽 채널은 왼쪽 채널의 오디오를 카피한 것일 수 있다. 이를 고려하여 Broadcast TV Initiator는 하나의 왼쪽 채널만 보낼 수 있는 반면 Broadcast TV Acceptor (2 피스 이어 버드의 경우)는 왼쪽 채널을 카피하여 오른쪽 채널을 만들 수 있다.
BIG = TV Program Audio with ProgramInfo Metadata Audio
BIS number 1 = ProgramInfo Metadata Audio
BIS number 2 = TV Program Audio
다중 언어 오디오 스트림
TV 프로그램 비디오와 함께 제공되는 TV 프로그램 오디오는 다국어 일 수 있다. 이 경우 BIG의 BIS 순서는 ProgramInfo Text 메타 데이터의 반복 순서를 따라야한다.
예를 들어, 다국어 부분의 ProgramInfo 텍스트 순서는 다음과 같을 수 있다.
ENG(Iso_639_languagecode) + ProgramInfo Length + ProgramInfo
KOR(Iso_639_languagecode) + ProgramInfo Length + ProgramInfo
FRE(Iso_639_languagecode) + ProgramInfo Length + ProgramInfo
ProgramInfo 메타 데이터 오디오가 있는 경우 오디오는 첫 번째 BIS 번호에 삽입 된다. BIG의 BIS 순서는 ProgramInfo Text 순서를 따를 수 있다.
- BIS number 1 = ProgramInfo Metadata Audio
- BIS number 2 = TV Program Audio ENG
- BIS number 3 = TV Program Audio KOR
- BIS number 4 = TV Program Audio FRE
브로드 캐스트 TV Acceptor 역할 요구사항
브로드 캐스트 TV Initiator와 달리, 브로드 캐스트 TV Acceptor는 일정 시간 이후 스캔을 중단하거나, 또는 항상 스캔을 수행할 수 있다.
이상에서 설명된 실시예들은 본 발명의 구성요소들과 특징들이 소정 형태로 결합된 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려되어야 한다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성요소들 및/또는 특징들을 결합하여 본 발명의 실시예를 구성하는 것도 가능하다. 본 발명의 실시예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시예에 포함될 수 있고, 또는 다른 실시예의 대응하는 구성 또는 특징과 교체될 수 있다. 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함시킬 수 있음은 자명하다.
본 발명에 따른 실시예는 다양한 수단, 예를 들어, 하드웨어, 펌웨어(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 (15)

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/436,373 US11736919B2 (en) 2019-03-07 2020-03-09 Method for receiving audio data by using bluetooth technology, and device therefor

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR20190026512 2019-03-07
KR10-2019-0026512 2019-03-07

Publications (1)

Publication Number Publication Date
WO2020180168A1 true WO2020180168A1 (ko) 2020-09-10

Family

ID=72338032

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2020/003270 WO2020180168A1 (ko) 2019-03-07 2020-03-09 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치

Country Status (2)

Country Link
US (1) US11736919B2 (ko)
WO (1) WO2020180168A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022161403A1 (zh) * 2021-01-26 2022-08-04 展讯通信（上海）有限公司 报站方法、系统、电子设备和广播设备

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12120582B2 (en) * 2019-06-03 2024-10-15 Intellectual Discovery Co., Ltd. Method, apparatus and computer program for broadcast discovery service in wireless communication system, and recording medium therefor
CN114915948A (zh) * 2021-02-09 2022-08-16 瑞昱半导体股份有限公司 蓝牙通信系统与蓝牙设备群
US20240251363A1 (en) * 2023-01-20 2024-07-25 Qualcomm Incorporated Angle of arrival-based location determination using periodic advertising synchronization

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013003753A2 (en) * 2011-06-29 2013-01-03 Texax Instruments Incorporated Improving connection setup for low energy wireless networks based on scan window and scan interval estimation
US20140348327A1 (en) * 2013-05-21 2014-11-27 Apple Inc. Synchronization of Multi-Channel Audio Communicated over Bluetooth Low Energy
KR101543193B1 (ko) * 2011-08-19 2015-08-07 애플 인크. 블루투스 저에너지 표준을 사용한 오디오 전달
US20150312858A1 (en) * 2012-11-19 2015-10-29 Nokia Corporation Oy Method and apparatus for generating a bluetooth low energy data packet comprising audio payload data
KR20170016883A (ko) * 2014-07-03 2017-02-14 엘지전자 주식회사 블루투스 통신을 지원하는 무선 통신 시스템에서 오디오 데이터를 송수신하기 위한 방법 및 이를 위한 장치

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160359925A1 (en) * 2015-06-08 2016-12-08 Lg Electronics Inc. Method and apparatus for transmitting and receiving data in wireless communication system
US9900827B2 (en) * 2015-12-10 2018-02-20 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
WO2020096412A1 (ko) * 2018-11-08 2020-05-14 엘지전자 주식회사 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013003753A2 (en) * 2011-06-29 2013-01-03 Texax Instruments Incorporated Improving connection setup for low energy wireless networks based on scan window and scan interval estimation
KR101543193B1 (ko) * 2011-08-19 2015-08-07 애플 인크. 블루투스 저에너지 표준을 사용한 오디오 전달
US20150312858A1 (en) * 2012-11-19 2015-10-29 Nokia Corporation Oy Method and apparatus for generating a bluetooth low energy data packet comprising audio payload data
US20140348327A1 (en) * 2013-05-21 2014-11-27 Apple Inc. Synchronization of Multi-Channel Audio Communicated over Bluetooth Low Energy
KR20170016883A (ko) * 2014-07-03 2017-02-14 엘지전자 주식회사 블루투스 통신을 지원하는 무선 통신 시스템에서 오디오 데이터를 송수신하기 위한 방법 및 이를 위한 장치

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022161403A1 (zh) * 2021-01-26 2022-08-04 展讯通信（上海）有限公司 报站方法、系统、电子设备和广播设备

Also Published As

Publication number Publication date
US20220159436A1 (en) 2022-05-19
US11736919B2 (en) 2023-08-22

Similar Documents

Publication Publication Date Title
WO2020213959A1 (ko) 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치
WO2020096412A1 (ko) 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치
WO2020180168A1 (ko) 블루투스 기술을 이용하여 오디오 데이터를 수신하기 위한 방법 및 이에 대한 장치
WO2018048268A1 (ko) 블루투스 기술을 이용하여 디바이스를 연결하기 위한 방법 및 장치
WO2018074892A1 (ko) 블루투스 기술을 이용하여 데이터를 송수신하기 위한 방법 및 장치
WO2018038459A1 (ko) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2018169380A1 (ko) 블루투스 기술을 이용하여 오디오 신호를 처리하기 위한 방법 및 장치
WO2018222024A1 (ko) 블루투스 le 기술을 이용하여 디바이스를 연결하기 위한 방법 및 장치
WO2016017909A1 (ko) 블루투스 통신을 지원하는 무선 통신 시스템에서 전자기기를 제어하기 위한 방법 및 장치
WO2016039598A1 (ko) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2016182404A1 (ko) 블루투스 저전력 에너지 기술을 이용하여 대체 통신 수단을 연결하기 위한 방법 및 장치
WO2015194854A1 (ko) 블루투스 le(low energy) 기술을 이용하여 디바이스 간 커넥션을 형성하기 위한 방법 및 장치
WO2016017907A1 (ko) 블루투스 통신을 지원하는 무선 통신 시스템에서 전자기기를 제어하기 위한 방법 및 장치
WO2017030232A1 (ko) 데이터 송수신 방법 및 이를 위한 디바이스
WO2020149708A1 (ko) 블루투스 기술을 이용하여 오디오 서비스를 제공하기 위한 방법 및 장치
WO2015163680A1 (ko) 무선 통신 시스템에서 블루투스 저전력 에너지 기술을 이용하여 데이터를 송수신하기 위한 방법 및 장치
WO2016036139A2 (ko) 블루투스 le(low energy) 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2016178542A1 (ko) 블루투스에서 데이터를 송수신하기 위한 방법 및 장치
WO2021040457A1 (ko) 무선 통신 시스템에서 오디오 처리 방법, 장치, 컴퓨터 프로그램 및 그 기록 매체
WO2018124852A1 (ko) 블루투스 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2018021877A1 (ko) 디바이스의 연결을 형성하기 위한 방법 및 장치
WO2016036206A2 (ko) 블루투스 le(low energy) 기술을 이용하여 디바이스를 제어하기 위한 방법 및 장치
WO2018194428A1 (ko) 블루투스 저전력 에너지 기술을 이용하여 연결을 형성하기 위한 방법 및 장치
WO2021096257A1 (ko) 무선 통신 시스템에서 근거리 무선 통신을 이용한 오디오 데이터 전송 방법 및 이에 대한 장치
WO2017018604A1 (ko) 블루투스 le(low energy) 기술을 이용하여 대체 통신 수단을 연결하기 위한 방법 및 장치

Legal Events

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

Ref document number: 20766018

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

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 20766018

Country of ref document: EP

Kind code of ref document: A1