JP2019531669A - Ｂｌｕｅｔｏｏｔｈマルチメディアデバイスの制御 - Google Patents

Ｂｌｕｅｔｏｏｔｈマルチメディアデバイスの制御 Download PDF

Info

Publication number
JP2019531669A
JP2019531669A JP2019524515A JP2019524515A JP2019531669A JP 2019531669 A JP2019531669 A JP 2019531669A JP 2019524515 A JP2019524515 A JP 2019524515A JP 2019524515 A JP2019524515 A JP 2019524515A JP 2019531669 A JP2019531669 A JP 2019531669A
Authority
JP
Japan
Prior art keywords
bluetooth
multimedia
chip
multimedia device
spk
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
JP2019524515A
Other languages
English (en)
Other versions
JP6949956B2 (ja
Inventor
ジュリアン・グピー
トマ・ジラルディエ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tap Sound System SAS
Original Assignee
Tap Sound System SAS
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 Tap Sound System SAS filed Critical Tap Sound System SAS
Publication of JP2019531669A publication Critical patent/JP2019531669A/ja
Application granted granted Critical
Publication of JP6949956B2 publication Critical patent/JP6949956B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1046—Call controllers; Call servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation

Landscapes

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

Abstract

本明細書は、具体的には、Bluetoothマルチメディアデバイスを制御するためのデバイス(DEV)に言及し、制御デバイスは、BluetoothチップからいくつかのBluetoothマルチメディアデバイス(SPK1、SPK2、SPKN)へのポイントツーマルチポイントリンク(LNK)を作成するように、修正されたA2DPプロファイル(A2DP')を実装するように構成されたBluetoothチップ(BC)を備え、制御デバイスのBluetoothチップは、非ブロッキングBluetooth使用に基づいて、前記いくつかのBluetoothマルチメディアデバイスの中からのそれぞれのBluetoothマルチメディアデバイスに各々、いくつかの相互接続されたマルチメディアストリームをストリーミングするように構成される。本明細書は、Bluetoothマルチメディアデバイスを制御するための方法、そのような方法を実施するように構成されたコンピュータプログラム、ならびにそのようなコンピュータプログラムを記憶する記憶媒体にも言及する。

Description

本明細書の目的は、Bluetooth(登録商標)マルチメディアデバイス、特にBluetoothスピーカを制御するためのシステムである(Bluetoothは、Bluetooth SIG, Inc.の登録商標である)。
Bluetoothは、当業者にはよく知られている通信規格であり、1994年から規定されており、連続したバージョンを発行している団体のグループ(Bluetooth SIG)によって管理されている。現在のバージョンは、バージョン4.2であり、バージョン5がちょうど告知されている。Bluetoothは、データの短距離双方向交換を可能にする(これは、個人領域をカバーするネットワークを示すピコネットネットワークである)。したがって、Bluetooth機器の範囲は、数10メートルに制限される。Bluetoothは、UHF帯(300MHzと3GHzとの間)に位置する電波を使用する。Bluetoothは、ケーブル接続を除去することによって電子デバイス間の接続を単純化することを目的とする。したがって、Bluetoothは、ソースマルチメディアデバイス(ハイファイシステム、カーラジオ、コンピュータ、タブレット、携帯電話など)と、受信したマルチメディアストリームを再生するように構成されたスピーカのようなターゲットマルチメディアデバイスとの間のケーブルがワイヤレス接続によって置き換えられることを可能にする。
Bluetoothスピーカは、それらの高い携帯性により一定の成功を収めた。
しかしながら、A2DPプロファイルと呼ばれるオーディオデータ交換プロファイルが使用される場合、Bluetooth規格は、Bluetoothチップが、同期させたいいくつかのマルチメディアデバイスと並行していくつかのオーディオストリームを送信することを許可しない。このA2DPプロファイルは、同期ポイントツーマルチポイント送信が実行されるのを許可しない。実際に、Bluetooth規格は、「以下の制約がこのプロファイルに適用される。1.プロファイルは、同期ポイントツーマルチポイント配信をサポートしない。」と述べている。したがって、理論的に、Bluetoothがこれを許さないので、Bluetoothマルチメディアデバイスの同期制御のためのデバイスを設計することは不可能であり、同期制御デバイスは、いくつかのマルチメディアデバイスを制御するための単一のBluetoothチップを備える。
複数のスピーカのためのポイントツーマルチポイントBluetoothデバイスを作成することがすでに提案されている。たとえば、2007年9月6日に出願され、現在は最終的に失効された出願FR2920930がそのようなデバイスを提案した。しかし、この出願は、そのようなデバイスをどのように製造するのかを説明しておらず、1つのみのBluetoothチップが使用される場合、それは、Bluetooth規格の観点から不可能であると思われる。この出願の不十分な説明は、同期ポイントツーマルチポイントリンクはもちろんのこと、ポイントツーマルチポイントリンクを達成する方法に関して関連する教示が習得されることを妨げる。
Bluetoothは、それを提供しないが、(制御されるべきBluetoothデバイスが存在するのと同じだけの数のBluetoothチップを制御回路内に設ける代わりに)いくつかのBluetoothデバイスを制御するためにBluetoothデバイス内にいくつかのソースSEPを作成することが可能であろう。SEPは、「ストリームエンドポイント」である。Bluetooth通信は、2つのSEP間のポイントツーポイントで実行される。SEPは、デバイスのリソースおよび容量を表す。たとえば、携帯電話のようなデバイスは、3つのSEPを有する場合があり、1つは、そのビデオレシーバ容量を表し、別のものは、SBCコーデックによるそのオーディオレシーバ容量を表し、最後のものは、aptXコーデックによるそのオーディオレシーバ容量を表す。各コーデックは、1つまたは複数のコーデックが関連付けられたものとは異なるSEPに関連付けられなければならないが、同じコーデックは、いくつかのSEPに関連付けられ得る。
しかしながら、BluetoothデバイスがBluetoothマルチメディアデバイスである場合、A2DPにおいてこれらのBluetoothマルチメディアデバイスの各々に送信される信号を同期させるという問題が生じる。
A2DPという頭字語は、「Advanced Audio Distribution Profile(アドバンストオーディオ配信プロトコル)」を意味する。従来のA2DPプロファイルは、ソースデバイスとシンクデバイスとの間でBluetoothプロトコルを介してオーディオデータを交換するためのプロトコルおよび手順のセットを規定し、「シンク」は、ストリームの最終的な目的地、たとえば、Bluetoothスピーカを示す。このA2DPプロファイルは、Bluetooth規格によって規定されるいくつかの基礎的要素から構成される。
具体的には、プロファイルは、当業者によく知られている低レベルの基礎的要素に基づく。これらの基礎的要素は、
「ベースバンド」基礎的要素(ベースバンド基礎的要素は、図1中の参照符BBによって識別される)、
「LMP」(「Link Manager Protocol(リンクマネージャプロトコル)」)基礎的要素、
「L2CAP」(「Logical Link Control and Adaptation Protocol(論理リンク制御および適応プロトコル)」)基礎的要素、
「SDP」(「Service Discovery Protocol(サービス発見プロトコル)」)
を含む。これらの基礎的要素は、Bluetooth規格において規定されるプロトコルである。
A2DPプロファイルは、アプリケーション層と呼ばれる高レベル層にも基づく(「Application Audio Source(アプリケーションオーディオソース)」および「Application Audio Sink(アプリケーションオーディオシンク)」について、それぞれ、図1中のAASoおよびAASiを参照されたい)。これは、デバイスが転送パラメータと様々な利用可能なサービスとを決定する層である。これは、オーディオデータを送信するために使用されるコーデックの選択が行われるレベルでもある(送信されるべきオーディオストリームがすでに符号化されている場合、復号化とそれに続く再符号化を含む場合があり、通常はそうである)。
最後に、A2DPプロファイルは、ストリームを確立し、L2CAPを使用してオーディオストリームおよび/またはビデオストリームをストリーミングするためのBluetoothデバイス間のバイナリトランザクションを規定するAVDTP(「Audio/Video Distribution Transport Protocol(オーディオ/ビデオ配信転送プロトコル)」)基礎的要素に基づく。したがって、これは、オーディオストリームを確立し、オーディオストリームパラメータをネゴシエートし、オーディオストリームデータを送信するための手順をカバーする。AVDTPは、ストリーミングパラメータをネゴシエートするためのシグナリングエンティティと、ストリーム自体を管理するための転送エンティティとを含む。AVDTPは、オーディオおよび/またはビデオデータを転送するためのプロトコルを規定する。より具体的には、AVDTPは、2つのSEP間のオーディオおよび/またはビデオデータの転送に関する。
Bluetooth規格に従ってAVDTPによって課せられる制限は、接続が2つのSEP間でネゴシエートされたとき、これら2つのSEPがストリームを配信するために互いにロックされなければならないということである。デフォルトでは、接続されたSEPは、いかなる新しい接続も拒絶する。最近のBluetooth製品では、「ソーシャルモード」という機能が、ときには、このデフォルトの動作が変更されることを許可する。しかし、新しい接続を可能にするこの「ソーシャルモード」機能は、進行中の接続を切断する。したがって、たとえば、同じBluetoothスピーカに接続された2つの電話機の存在が可能である。しかし、いくつかの同時転送は、確立され得ない。新しい接続への切替えは、典型的には、以前に接続された電話機をメモリ内に保持しながら、以前の接続を終了することによって行われる。その結果、ソースデバイス上に1つのみのオーディオソースSEPを有する場合、Bluetooth規格に従って、所与の時間において所与のシンクデバイスに対して単一のAVDTP転送が確立され得る。
L2CAP層は、Bluetooth仕様のデータを交換するための最小限のプロトコルを規定する。具体的には、L2CAP層は、パケットの分割および再構成、多重化、ならびにサービスの品質を可能にする。(A2DPのような)異なるBluetoothプロファイルの基礎をなす(AVDTPのような)様々な転送プロトコルは、このL2CAPから来る。L2CAPチャネルは、ソースデバイスのCID(「Channel Identifier(チャネル識別子)」)とシンクデバイスのCIDとの間に作成され、これら2つのデバイス間のデータの交換を可能にする。各L2CAPチャネルは、プログラムされ、具体的には、L2CAPが規定するチャネル(L2CAPチャネル)を通過するデータストリームの制御が管理されることを可能にする。これを行うために、各L2CAPチャネルについて独立して異なるパラメータが考慮に入れられ得、具体的には、
・FTOまたは「Flush Timeout(フラッシュタイムアウト)」パラメータは、ソースデバイスのバッファメモリ内のデータパケットに関する有効期間を規定する。この期間は、デフォルト(ブロッキングモード)では無限であり、それは、宛先に到達しない送信パケットが、パケット(最初のパケットまたは再送パケット)がその宛先に到達しない限り再送信されることを意味する。しかし、期間は、(「Flush Timeout」パラメータがBluetooth規格によって規定される適切な値に設定されている場合)再送信が決してないようにもされ得、それは、ヌル期間になる。期間は、有限値をとることもできる。Bluetoothパケット内に存在する「自動的にはフラッシュ可能ではないフラグ」と呼ばれるブール変数が存在し、関連するパケットが自動的にはフラッシュされ得ないことを示す。
・L2CAPチャネルにおいて送信されるべきパケットの包含とその実際の送信との間の最大レイテンシを具体的に規定するQoS(「Quality of Service(サービスの品質)」)パラメータ。
・前述の「Flush Timeout」および「QoS」パラメータの組合せを置き換え、補足する「Extended Flow feature(拡張フロー特性)」と呼ばれるパラメータ。
これらのパラメータは、ソースBluetoothデバイスのBluetoothスタックとシンクBluetoothデバイスのBluetoothスタックとの間でネゴシエートされ、デフォルト値を除いてはまだサポートされていない。
L2CAPは、異なるモードの実装を可能にする。これらのモードは、「Extended Flow feature」パラメータまたは「Flush Timeout」パラメータと同じように、L2CAPチャネルパラメータでもある。これらのパラメータのすべて(モードを含めて)は、ストリームの制御が変更されることを可能にする。各モードは、データストリームを管理するための異なる手順を規定する。古典的なBluetoothコンテキスト(BR/EDRと呼ばれる)内で、L2CAPチャネルに対して5つの動作モードが可能である。これらのモードは、
・「Basic Mode(基本モード)」(基本モードL2CAP)、
・「Flow Control Mode(フロー制御モード)」、
・「Retransmission Mode(再送信モード)」、
・「Enhanced Retransmission Mode(拡張再送信モード)」(「ERTM」と呼ばれる)、および
・「Streaming Mode(ストリーミングモード)」(「SM」と呼ばれる)
である。
「Basic Mode」は、デフォルトのモードであり、Bluetoothスタックによってサポートされる。それは、プログラミングを必要としない。「Flow Control Mode」は、パケットを送信するが、失われたパケットを決して再送信しない。しかしながら、これらのパケット(PDUと呼ばれる)は、それらが失われたときに検出され、「Flow Control Mode」は、失われたパケットをリスト化した報告の通信を可能にする。「Flow Control Mode」および「Retransmission Mode」は、「ERTM」および「SM」が使用可能ではない場合にのみ使用され得る。これらの2つのモード(「Flow Control Mode」および「Retransmission Mode」)は、めったに使用されない。具体的には「ERTM」は、所与の最大数の再送信が考慮されることと、再送信が介在し得る所与の最大持続時間が考慮されることとを可能にし、送信されないまたは不適切に送信されたパケットが識別されることを可能にする。「SM」は、非同期データストリームに適合される。それは、有限の「Flush Timeout」パラメータを考慮に入れる。Bluetoothレシーバでは、バッファメモリがいっぱいである場合、前のデータは上書きされる。
Bluetooth規格では、「Retransmission and flow control option(再送信およびフロー制御オプション)」と呼ばれるパラメータが、モードが選択されることを可能にする。Bluetooth規格は、無限の「Flush Timeout」を有する「Basic Mode」、または、より最近のBluetoothスタックでは任意の「Flush Timeout」を有する「ERTM」を使用することによって、データ損失を制限する信頼できる接続を確立することを推奨する。
実際には、市場のどの製品も、任意のBluetoothマルチメディアデバイスのための同期ポイントツーマルチポイントA2DP制御機能を提供しない。
本発明は、状況を改善することを目的とする。
本発明は、具体的には、Bluetoothマルチメディアデバイスを制御するためのデバイスに関し、この制御デバイスは、BluetoothチップからいくつかのBluetoothマルチメディアデバイスへのポイントツーマルチポイントリンクを作成するように、修正されたA2DPプロファイルを実装するように構成されたBluetoothチップを備え、制御デバイスのBluetoothチップは、非ブロッキングBluetooth使用に基づいて、前記いくつかのBluetoothマルチメディアデバイスの中からのそれぞれのBluetoothマルチメディアデバイスに各々、いくつかの相互接続されたマルチメディアストリームをストリーミングするように構成される。
このデバイスは、Bluetooth規格がそのような可能性を提供しないとしても、単一のBluetoothチップがいくつかのBluetoothマルチメディアデバイスを制御するために使用されることを可能にするという点で有利である。したがって、Bluetooth規格では提供されないポイントツーマルチポイントリンクを可能にすることによって、規格に違反することなくA2DPプロファイルを修正することが可能である。したがって、相互運用性が維持される(Bluetooth機能が正常にサポートされる)。既存の機能を混乱させることなく最初に提供されていない機能をデバイスが追加するだけである限り、Bluetooth規格における違反は存在しない。加えて、非ブロッキングBluetooth使用は、ストリーミングされたマルチメディアストリームが非同期化されるのを防止する。
本発明によるデバイスは、単独でまたは組合せにおいて採用される以下の特徴のうちの1つまたは複数を含んでもよい。
本発明は、具体的には、Bluetoothマルチメディアデバイスを制御するためのデバイスであって、Bluetoothチップは、BluetoothチップがBluetoothマルチメディアデバイスに送信したマルチメディアストリームパケットが失われたとき、前記マルチメディアストリームパケットを前記Bluetoothマルチメディアデバイスに再送信するように構成され、Bluetoothチップが、少なくとも1つのBluetoothマルチメディアデバイスのバッファメモリの充填率を決定し、少なくとも1つのBluetoothマルチメディアデバイスのバッファメモリの充填率に従って、失われたマルチメディアストリームパケットをBluetoothマルチメディアデバイスに再送信することができる最大持続時間を決定するように構成される、デバイスに関する。
本発明は、具体的には、Bluetoothマルチメディアデバイスを制御するためのデバイスであって、BluetoothチップがBluetoothマルチメディアデバイスを制御するためにいくつかのSEPを生成するように構成される、デバイスに関する。
本発明は、具体的には、Bluetoothマルチメディアデバイスを制御するためのデバイスであって、BluetoothチップがSBCコーデックを使用することによって5つまでのBluetoothマルチメディアデバイスを制御するように構成される、デバイスに関する。
本発明は、具体的には、Bluetoothマルチメディアデバイスを制御するための方法であって、Bluetoothチップが、前記BluetoothチップからいくつかのBluetoothマルチメディアデバイスへのポイントツーマルチポイントリンクを作成するように、修正されたA2DPプロファイルを実装し、Bluetoothチップが、非ブロッキングBluetooth使用に基づいて、前記いくつかのBluetoothマルチメディアデバイスの中からのそれぞれのBluetoothマルチメディアデバイスに各々、いくつかの相互接続されたマルチメディアストリームをストリーミングする、方法に関する。
本発明は、具体的には、Bluetoothマルチメディアデバイスを制御するための方法であって、BluetoothチップがBluetoothマルチメディアデバイスに送信したマルチメディアストリームパケットが失われたとき、Bluetoothチップが前記マルチメディアストリームパケットを前記Bluetoothマルチメディアデバイスに再送信し、少なくとも1つのBluetoothマルチメディアデバイスのバッファメモリの充填率に従って、失われたマルチメディアストリームパケットをBluetoothマルチメディアデバイスに再送信することができる最大持続時間を推測するために、少なくとも1つのBluetoothマルチメディアデバイスのバッファメモリの充填率を決定する、方法に関する。
本発明は、具体的には、Bluetoothマルチメディアデバイスを制御するための方法であって、BluetoothチップがBluetoothマルチメディアデバイスを制御するためにいくつかのSEPを生成する、方法に関する。
本発明は、具体的には、Bluetoothマルチメディアデバイスを制御するための方法であって、BluetoothチップがSBCコーデックを使用することによって5つのBluetoothマルチメディアデバイスを制御する、方法に関する。
本発明は、具体的には、プロセッサによって実行されると、本発明の一態様による方法を実施する一連の命令を含むコンピュータプログラムに関する。
本発明は、具体的には、本発明の一態様によるコンピュータプログラムを記憶する非一時的コンピュータ可読記憶媒体に関する。
本発明の他の特性および利点は、以下の説明を読めば明らかになるであろう。説明は、純粋に例示的なものであり、添付図面と併せて呼ばれるべきである。
従来のA2DPプロファイルと、従来のA2DPプロファイルと通信するように構成された本発明の実施形態によるA2DP'プロファイルとを示す図である。 本発明の実施形態によるデバイスと、Bluetoothスピーカのセットとを備えるシステムを示す図である。 図2からのシステムの変形例を示す図である。
以下の実施形態は、例である。説明は、1つまたは複数の実施形態に言及しているが、これは、一実施形態の文脈で言及された各要素がこの同じ実施形態のみに関連すること、または、この実施形態の特性がこの実施形態のみに適用されることを必ずしも意味しない。
図1は、(オーディオストリームを送信するデバイスに対応する)「ソース」デバイスのために使用される本発明の実施形態によるA2DP'と、シンクデバイスのために使用される従来のA2DPとの間の通信を示す。たとえば、シンクデバイスは、Bluetoothスピーカに対応し、Bluetoothスピーカは、いくつかのシンクSEPを備えることができることを認識する(したがって、いくつかのシンクSEPは、同じBluetoothスピーカに対応することができ、各シンクSEPは、次いで、このBluetoothスピーカによってサポートされるすべてのコーデックの中からのそれぞれのコーデックに特に対応することができる)。
実際には、Bluetoothチップ製造業者のBluetoothスタックは、コーデック毎およびBluetoothチップ毎に単一のソースSEPを導入するだけである。したがって、所与のコーデックについて、いくつかのオーディオデバイス(たとえば、スピーカ)を携帯電話に接続することは不可能である。
A2DP'プロファイルは、AVDTP基礎的要素の代わりに使用されるAVDTP'基礎的要素によってA2DPと正確に区別される。AVDTP'基礎的要素は、AVDTP基礎的要素のすべての機能を提供するが、同期ポイントツーマルチポイント接続も可能にする。
図2は、各々がそれぞれのシンクSEP、SEPS1、SEPS2、SEPSNに関連付けられた少なくとも3つのBluetoothスピーカSPK1、SPK2、およびSPKNを備えるシステムを示す(前述のように、各SPKiスピーカは、単一のシンクSEP、SEPSiではなくいくつかのシンクSEPに関連付けられ得るが、簡略化のため、実際に使用されるシンクSEPのみが表されている)。システムは、本発明の可能な実施形態による、Bluetoothスピーカを制御するためのDEV'デバイスも備える。DEV'デバイスは、BluetoothチップBC'を備える。このBluetoothチップBC'は、それを識別する固有のSEP USEPを記憶する。このBluetoothチップBC'は、それぞれのSEP、SEPS1、SEPS2、SEPSNを介して3つのBluetoothスピーカSPK1、SPK2、およびSPKNとのポイントツーマルチポイントリンクLNK'を確立する。
図3は、各々がそれぞれのシンクSEP、SEPS1、SEPS2、SEPSNに関連付けられた少なくとも3つのBluetoothスピーカSPK1、SPK2、およびSPKNを備えるシステムを示す(前述のように、各SPKiスピーカは、単一のシンクSEP、SEPSiではなくいくつかのシンクSEPに関連付けられ得るが、簡略化のため、実際に使用されるシンクSEPのみが表されている)。システムは、本発明の可能な実施形態による、Bluetoothスピーカを制御するためのDEVデバイスも備える。DEVデバイスは、BluetoothチップBCを備える。このBluetoothチップBCは、3つの別個のBluetoothチップをシミュレートする少なくとも3つのSEP、SEP1、SEP2、SEPNを記憶する(しかし、実際には1つのみしか存在しないので、それらは、仮想Bluetoothチップである)。BluetoothチップBCは、少なくとも3つのBluetoothスピーカSPK1、SPK2、およびSPKNとのポイントツーマルチポイントリンクLNKを確立するが、Bluetooth規格の観点からは、このリンクLNKは、3つ(少なくとも)のポイントツーマルチポイントリンクのセットのように見える。実際には、SEP、SEP1は、スピーカSPK1のSEP、SEPS1に接続され、SEP、SEP2は、スピーカSPK2のSEP、SEPS2に接続され、SEP、SEPNは、スピーカSPKNのSEP、SEPSNに接続される。
第1の実施形態は、Bluetoothマルチメディアデバイスを制御するためのデバイス(たとえば、DEVまたはDEV')に関し、この制御デバイスは、Bluetoothチップ(たとえば、BCまたはBC')を備える。
Bluetoothマルチメディアデバイスは、たとえば、Bluetoothスピーカである。Bluetoothスピーカは、数人の人間によって同時に知覚可能な音をストリーミングするように構成された少なくとも1つのスピーカを含む任意のBluetoothデバイスを指す。制御デバイスによって制御されるのがこのスピーカである限り、それは、たとえば、ハイファイシステム用のスピーカ、または、数人の人に聞こえるように設けられたスピーカを備える携帯電話であってもよい。より具体的には、「数人の人間によって同時に知覚可能な音」は、会話のもの、または約40dB SPLに対応する周囲騒音が存在するときにスピーカから少なくとも1メートルの距離に位置する正常な聴覚を有する任意の人によって(その内容が区別され得るという意味で)知覚可能である音を指すと理解される。したがって、ヘッドセット、イヤホン、または電話受話器は、伝達された音を知覚することができるように耳に対してまたは耳の中に適用されなければならないので、本出願の意味におけるスピーカではない。
可能な実装形態によれば、Bluetoothマルチメディアデバイスは、Bluetoothスピーカである。そのようなスピーカは、たとえば、テレビジョンに接続され、テレビジョン上でストリーミングされているビデオストリームと同期されることに加えて、互いに同期される必要がある。
より一般的には、Bluetoothマルチメディアデバイスの各々は、Bluetoothテレビジョン、Bluetoothスクリーン、Bluetooth携帯電話、Bluetoothポータブルもしくはオフィスコンピュータ、Bluetoothタブレット、Bluetoothハイファイシステム、Bluetoothカーラジオ、またはBluetoothデジタル音楽プレーヤであり得る。
DEVまたはDEV'制御デバイスは、たとえば、Bluetoothテレビジョン、Bluetoothスクリーン、Bluetooth携帯電話、Bluetoothポータブルまたはオフィスコンピュータ、Bluetoothタブレット、Bluetoothハイファイシステム、Bluetoothカーラジオ、またはBluetoothデジタル音楽プレーヤである。
Bluetoothチップ(たとえば、図中のBCまたはBC')は、前記BluetoothチップからいくつかのBluetoothマルチメディアデバイスSPK1、SPK2、SPKNへのポイントツーマルチポイントリンク(たとえば、LNKまたはLNK')を作成するように、修正されたA2DPプロファイル(図1においてA2DP'と示される)を実装するように構成される。制御デバイスのBluetoothチップは、Bluetoothの非ブロッキング使用に基づいて、いくつかの相互接続されたマルチメディアストリームを、各々、前記いくつかのBluetoothマルチメディアデバイスの中からのそれぞれのBluetoothマルチメディアデバイスにストリーミングするように構成される。「互いに関連する」マルチメディアストリームは、同じ状況(たとえば、同じシーンまたは同じ音楽)に関するマルチメディアストリームを指すと理解されるが、それにもかかわらず異なり得る。たとえば、マルチメディアストリームは、各々がオーディオ記録の5.1チャネルのうちの1つに対応する6つのオーディオストリームであり得、または、同時に、しかし異なる視点から撮影された同じシーンのいくつかのビデオであり得る。制御デバイスは、たとえば、Bluetoothタイプのワイヤレス接続を介してオーディオストリーム(または、より一般的にはマルチメディアストリーム)を送信するように構成される。たとえば、それは、最低でも1つのオーディオチャネルを含むマルチメディアストリームを記憶または中継する。たとえば、それは、MP3ファイルを記憶し、または、(Youtube(登録商標)サーバのような)サーバに接続し、そこから、Bluetoothを介して複数のBluetoothマルチメディアデバイスに順次もしくは同時に再送信するストリームをダウンロードする。
A2DPにおいてデフォルトで使用されるブロッキング使用の代わりに、Bluetoothの非ブロッキング使用に基づくので、制御デバイスは、同期の損失を防止する。非ブロッキングBluetooth使用は、BluetoothチップがBluetoothマルチメディアデバイスを制御するためのデバイスのBluetoothチップをブロックするのを防止する(Bluetoothモードによるおよび/または他のBluetoothパラメータによる)任意のBluetoothプログラミングを指すと理解される。したがって、非ブロッキングBluetooth使用は、受信されていない限り未受信パケットを再送信することをBluetoothチップに強いることを防ぐBluetooth使用であり、それはまた、たとえば、Bluetooth通信を独占する、パケットを再送信する不成功な試みのために、少なくとも1つのBluetoothマルチメディアデバイスがバッファメモリ内にデータをもはや持たない時点を超えて、そのようなパケットが再送信されることを強いるのを防止する。非ブロッキング使用は、Bluetooth規格の意味における(SMモードのような)モードだけでなく、パラメータのセット(FTO、QoS、モード、拡張フロー特性)に対応する。これは、たとえば、「フロー制御」モード、または、いかなる再送信も防止するためにBluetooth規格に従って「フラッシュタイムアウト」パラメータが設定される任意の他のモードを含む。逆に、ブロッキング使用は、たとえば、データが受信されていない限りデータを再送信することにつながる、または、より高い優先度のBluetoothマルチメディアデバイスもデータを待っていて、前記使用のためにデータを受信していない(次いでブロックされる)間にデータを再送信することにつながる使用である。ブロッキング使用は、偶発的なデータ損失を回避するので、従来技術において使用される(所与の閾値よりも長い間の長い電力カットの場合、ブロッキング使用は、データ損失を防ぐことができない)。Bluetoothがポイントツーマルチポイントストリーミングを可能にするように適合されたと仮定すると、非ブロッキング使用を用いることは、Bluetoothマルチメディアデバイスがアクセス不可能になり、すべてのBluetoothマルチメディアデバイスへのデータのどのような送信も妨げるリスクを防止する。たとえば、Bluetoothマルチメディアデバイスは、DEV制御デバイスのBluetoothチップの範囲外に移動されたので、または消耗したバッテリを含むので、またはなにか他の理由のためにアクセス不可能になる可能性がある。
前置きで述べたデフォルトのBluetooth L2CAPパラメータは、いくつかのシンクBluetoothデバイスへのソースBluetoothデバイスの同期A2DPリンクを確立するのには適していない。実際には、ソースとシンク(たとえば、スピーカ)との間に確立されたリンクのうちの1つが無限の「Flush Timeout」を用いて設定されている場合、および、スピーカがBluetooth範囲を出るか、または消耗したバッテリから給電されている場合、データは、データを受信しないと、他のシンクデバイスへのいかなる他のデータ送信もブロックする(データは、順次に送信される)そのスピーカに継続的に再送信される。加えて、「Flush Timeout」パラメータがデフォルトで定義されている場合、スピーカを介してデータを送信することは、そのスピーカと他のスピーカとの間に時間遅れをもたらすことになる。実際には、ソースBluetoothデバイスのBluetooth範囲外のスピーカがその範囲に戻ったとき、そのスピーカは、この範囲を出ることによって停止された時点からストリームを配信し続ける。
可能な実装形態によれば、Bluetoothマルチメディアデバイスを制御するためのデバイスは、Bluetoothマルチメディアデバイスを制御するためのデバイスと様々なシンクマルチメディアデバイスとの間の同期リンクを維持するように、BluetoothマルチメディアデバイスのBluetoothスタックによってサポートされる様々な構成から、(Bluetoothスピーカを制御するためのデバイスのBluetoothチップとBluetoothマルチメディアデバイスとの間の論理リンクに対応する)各L2CAPに採用するプログラミングを自動的に決定するように構成される。マルチメディアデバイスの各々のL2CAPパラメータは、異なってもよい(それらは、これらのマルチメディアデバイスの特性、特定のプロトコルをサポートするそれらの能力などに依存することができる)。
可能な実装形態によれば、Bluetoothマルチメディアデバイスを制御するためのデバイスは、再送信が実行されないように、異なるL2CAPチャネルに関するすべての「フラッシュタイムアウト」を、Bluetooth規格によって規定される値(すなわち、1、しかしこれは、実装形態に応じて異なり得る)に設定するように構成される。このようにして得られたリンクは、送信エラーまたは損失が捕捉されないという意味では信頼できないが、パケットの起こり得る損失後の同期を保証する。
可能な実装形態によれば、A2DPプロファイルの修正は、たとえば、以下に示す方法のうちの1つにおいて、A2DPプロファイルによって使用されるAVDTP基礎的要素を修正することからなる。修正されたAVDTP基礎的要素に対応するAVDTP'基礎的要素を作り出すために、具体的には、Linuxタイプのオペレーティングシステム上にBluetooth技術を実装するように設計され、GNU GPLライセンスの下で利用可能な(当業者には周知の)BlueZとして知られる実装のような無料の実装を使用することが可能である。BlueZの実装は、Linux用の基準Bluetooth実装になり、Linuxカーネルに統合された。
第2の実施形態によれば、第1の実施形態によるBluetoothマルチメディアデバイスを制御するためのデバイスのBluetoothチップは、Bluetoothマルチメディアデバイスに送信したマルチメディアストリームパケットが失われたときに、前記マルチメディアストリームパケットを前記Bluetoothマルチメディアデバイスに再送信するように構成される。Bluetoothチップは、少なくとも1つのBluetoothマルチメディアデバイスSPK1、SPK2、SPKNのバッファメモリの充填レベルを決定し、少なくとも1つのBluetoothマルチメディアデバイスのバッファメモリの充填レベルに従って、失われたマルチメディアストリームパケットをBluetoothマルチメディアデバイスに再送信することができる最大持続時間を決定するように構成される。
可能な実装形態によれば、この最大持続時間は、すべての他のBluetoothマルチメディアデバイスのバッファメモリの中で最も充填されていないバッファメモリに対応し、そこからマルチメディアストリームの十分な部分を送信するために必要な時間を推測しなければならない。したがって、パケットを失ったBluetoothマルチメディアデバイスのバッファメモリの内容は、考慮されない。
別の実装形態によれば、この最大持続時間は、すべてのBluetoothマルチメディアデバイス(パケットを失ったものを含む)のバッファメモリの中から最も充填されていないバッファメモリに対応し、そこからマルチメディアストリームの十分な部分を送信するために必要とされる時間を推測しなければならない。実際に、パケットを失ったBluetoothマルチメディアデバイスが再生するマルチメディアストリームデータを使い果たすというリスクがある場合、いずれにせよ遅延されたものとして復元され、したがって、他のBluetoothマルチメディアデバイスから非同期化されることになる失われたパケットを再送信する試みを放棄することがより適切であると考えられ得る。
別の実装形態によれば、Bluetoothチップは、バッファメモリの充填率を検証する必要がないBluetoothマルチメディアデバイスを識別するように構成される。たとえば、バッファメモリがより充填されておらず、前述の最大持続時間を決定することになる他のBluetoothマルチメディアデバイスが必然的に存在すると推測できる場合、最後にバッファメモリに給電した数nのBluetoothマルチメディアデバイスを除外することができる。
別の実装形態によれば、Bluetoothチップは、そのバッファメモリに最も長く給電したBluetoothマルチメディアデバイスの識別子を記憶するように構成される。パケットが失われたとき、Bluetoothチップは、次いで、そのバッファメモリに最も長く給電したBluetoothマルチメディアデバイスのバッファメモリを検証するだけである。
可能な実装形態によれば、制御デバイスは、(SBCコーデックによって符号化されたオーディオストリームブロックの持続時間に対応する)約14msのオーディオストリームの部分を送信するように構成される。可能な実装形態によれば、制御デバイスは、4つのBluetoothマルチメディアデバイスを制御し、約14msの部分の送信は、約1.3msかかる。したがって、4つのBluetoothマルチメディアデバイスに約14msのストリームを送信するのに約4*1.3msまたは約5.2msかかり、それは、制御デバイスが、不適切に送信されたか、または送信されていないパケットを識別し、それらを再送信することができる約14ms〜5.2msまたは約8.8msを残す。
可能な実装形態によれば、Bluetoothマルチメディアデバイスを制御するためのデバイスは、たとえば、上述した方法のうちの1つによって事前に推定しなければならないBluetoothマルチメディアデバイスのバッファメモリの充填状態に応じて各L2CAPチャネルの「Flush Timeout」を設定するように構成される。
可能な実装形態によれば、第1の実施形態によるBluetoothマルチメディアデバイスを制御するためのデバイスのBluetoothチップは、すべてのBluetoothマルチメディアデバイスを制御するための固有のSEPを生成するように構成される。より具体的には、ソースSEP(Bluetoothチップ)のA2DPプロファイルは、たとえば、従来のAVDTP基礎的要素を修正されたAVDTP'基礎的要素に置き換えることによって修正される。修正は、ソースSEPが2つ以上のシンクSEPに接続するのを妨げる制限を除去することからなる。その結果、Bluetooth規格は、それが対話するソースSEPが別のシンクSEPとも対話しないことを、シンクSEPのレベルにおいて検証することを含まない。技術的に、マルチメディアストリーム(特にオーディオ)が、同じソースSEPからいくつかのシンクSEPに、同じBluetoothチップからストリーミングされ得ることがわかる。
Bluetooth規格は、ソースSEPがいくつかのシンクSEPと通信されることを許可しないので、本実装形態は、Bluetooth規格がそのような拡張を検出するように提供されていない限り困難を生じないBluetooth規格に対する拡張の一形態を構成する。
もちろん、Bluetoothマルチメディアデバイスを制御するためのデバイス内にいくつかのBluetoothチップを提供することが可能であり、各チップは、それぞれがそれらの各々によって管理されるBluetoothマルチメディアデバイスを制御するための固有のSEPを生成するように構成される。たとえば、Bluetoothチップ番号1は、マルチメディアデバイス番号1〜5を管理することができ、Bluetoothチップ番号2は、マルチメディアデバイス番号6〜10を管理することができ、Bluetoothチップ番号3は、マルチメディアデバイス番号11〜15を管理することができる。実際には、Bluetoothチップの最高速度は、それが制御することができるマルチメディアデバイスの数を制限し、マルチメディアデバイスの数が所与の閾値を超える場合、Bluetoothチップを追加することは、追加のマルチメディアデバイスが同時に制御されることを可能にする。
第3の実施形態によれば、第1または第2の実施形態によるBluetoothマルチメディアデバイスを制御するためのデバイスのBluetoothチップは、Bluetoothマルチメディアデバイスを制御するためにいくつかのSEPを生成するように構成される。
有利な実装形態によれば、Bluetoothチップは、(それが制御しなければならない各Bluetoothマルチメディアデバイスに対応する)各シンクSEPに対して別個のソースSEPを生成する。これは、BluetoothチップがBluetooth規格により密接に準拠する前述の実装形態の代替案である。実際には、それは、表面上はポイントツーポイントリンクを有し、ポイントツーマルチポイントリンクを有さない。しかし、それは、もちろん、実際には1つのみのBluetoothチップが存在する多数のソースデバイスをシミュレートするために同じBluetoothチップ内に多数の仮想SEPを作成することからなるデバイスである。
もちろん、Bluetoothマルチメディアデバイスを制御するためのデバイス内にいくつかのBluetoothチップを設けることが可能であり、各チップは、それらの各々によってそれぞれ管理されるBluetoothマルチメディアデバイスと同じくらい多いソースSEPを生成するように構成される。たとえば、Bluetoothチップ番号1は、それぞれのソースSEP、SEP1〜SEP5を使用して、Bluetoothマルチメディアデバイス番号1〜5を管理することができ、Bluetoothチップ番号2は、それぞれのソースSEP、SEP6〜SEP10を使用して、Bluetoothマルチメディアデバイス番号6〜10を管理することができ、Bluetoothチップ番号3は、それぞれのソースSEP、SEP11〜SEP15を使用して、Bluetoothマルチメディアデバイス番号11〜15を管理することができる。実際に、Bluetoothチップの最高速度は、それが制御することができるマルチメディアデバイスの数を制限し、マルチメディアデバイスの数が所与の閾値を超える場合、Bluetoothチップを追加することは、追加のマルチメディアデバイスが同時に制御されることを可能にする。Bluetoothチップによって生成されるソースSEPの数は、このBluetoothチップにおける利用可能な帯域幅に影響を与えず、それは、同じままであるが、これらの異なるソースSEP間で共有される。可能な実施形態によれば、Bluetoothチップは、ピコネットを使用することによってそれが制御するBluetoothマルチメディアデバイスを管理するために最大7つのソースSEPを作成する。ピコネットは、Bluetooth規格によって指定されるように、単一のソースBluetoothデバイスと、7つまでのシンクBluetoothデバイスとを含む、1〜8のBluetoothデバイスからなるネットワークである。ソースデバイスあたり7つのシンクデバイスに対する制限は、3ビットを使用して各シンクBluetoothデバイスを識別するBluetoothアドレス指定から生じ、000は、「コネクションレスブロードキャスト」と呼ばれる特別なモードのために予約されている。
第4の実施形態によれば、第1〜第3の実施形態のうちの1つによるBluetoothマルチメディアデバイスを制御するためのデバイスのBluetoothチップは、SBCコーデックを使用することによって5つまでのBluetoothマルチメディアデバイスを制御するように構成される。「5つまでのBluetoothマルチメディアデバイスを制御する」は、送信されるSBCオーディオストリームがなんであれ、このストリームを5つのスピーカにストリーミングすることが可能であることを意味するように理解される。5未満のスピーカが存在する場合、これは、なおさら可能である。
CD品質のステレオオーディオストリームは、44.1kHzにおいてサンプリングされ、16ビットにおいてオーディオ信号をサンプリングする。したがって、毎秒44100の16ビットサンプルが左側のために提供され、44100の他の16ビットサンプルが右側のために提供される。したがって、そのようなストリームの生のスループットは、44100*2*16bit/s、または1.4Mbit/sを少し上回る。そのような速度は、非常に高く、したがって、送信、特に、速度がそれほど高くないBluetooth送信の間に必要な帯域幅を低減するために、それを圧縮することが有用である。この圧縮を実行するために、コーデックが使用される。SBCコーデックは、非常に単純で効果的なコーデックである。効果的とは、SBCコーデックが動作するために非常に小さいメモリリソースおよびプロセッサリソースを必要とするだけであることを意味する。これは、しばしば処理能力メモリにおいて制限されたBluetoothチップにとって非常に有益である。SBCコーデックも、無料である。非常に広く普及しており、したがって、高い相互運用性を保証するので、それも有利である。しかしながら、得られる圧縮率およびオーディオ品質の点では、むしろ性能が低下する。SBCコーデックによって符号化されたオーディオストリームのビットレートは、最大で372kbit/sである(場合によっては、SBCは、特に、利用可能な帯域幅に適応するために、より低いビットレートを生成し、したがって、必要に応じて、6つ以上のBluetoothマルチメディアデバイスを制御することを可能にする)。しかし、よりよく機能するコーデックが存在する。たとえば、AACコーデックは、372kbit/sのSBCストリームの品質と実質的に同等の品質を有する約192kbit/sの圧縮オーディオストリームを生成する。AptXコーデックも、改善された性能(同等の品質においてより低いビットレート)を提供するが、無料ではない。
従来のBluetoothスピーカのような互換性のあるEDR(「拡張データレート」)デバイスのためのBluetooth帯域幅は、2.1Mbit/sである。したがって、(最大372kbit/sにおいて)SBCコーデックによって符号化された最少で5つのストリームを利用可能な帯域幅内で送信することが可能である。
可能な実装形態によれば、Bluetoothチップは、AACコーデックを使用し、それは、理論的には、10(ほぼ11)の符号化されたAACストリームが192kbit/sにおいて送信されることを可能にする。それにもかかわらず、可能な実装形態によれば、(スレーブデバイスの数を7に制限する)Bluetooth規格に従ってピコネットを定位置に置くことを可能にするために、AACストリームの数を7に制限することが有利である。他の代替案によれば、他のコーデックが使用され、符号化ストリームのレートが300kbit/sよりも高い場合、7まで、またはそれ未満の符号化ストリームが送信されることを可能にする(この場合、可能な符号化ストリームの数は、bit/sで表される符号化ストリームのレートによって2100000の比率に等しい)。
第5の実施形態は、BluetoothチップによってBluetoothマルチメディアデバイスを制御するための方法に言及する。Bluetoothチップは、前記BluetoothチップからいくつかのBluetoothマルチメディアデバイスへのポイントツーマルチポイントリンクを作成するように、修正されたA2DPプロファイル(A2DP'と示す)を実装し、Bluetoothチップは、Bluetoothの非ブロッキング使用に基づいて、前記いくつかのBluetoothマルチメディアデバイスの中からのそれぞれのBluetoothマルチメディアデバイスに各々、いくつかの相互接続されたマルチメディアストリームをストリーミングする。
可能な実装形態によれば、Bluetoothチップは、プロセッサを備え、前記BluetoothチップからいくつかのBluetoothマルチメディアデバイスへのポイントツーマルチポイントリンクを作成するようにA2DP'プロファイルを実装するように適合されたコンピュータプログラムを実行し、Bluetoothチップは、Bluetoothの非ブロッキング使用に基づいて、前記いくつかのBluetoothマルチメディアデバイスの中からのそれぞれのBluetoothマルチメディアデバイスに各々、いくつかの相互接続されたマルチメディアストリームをストリーミングする。
代替実装形態によれば、これは、同様にプロセッサを備え、前記BluetoothチップからいくつかのBluetoothマルチメディアデバイスへのポイントツーマルチポイントリンクを作成するようにA2DP'プロファイルを実装するように適合されたコンピュータプログラムを実行する前記Bluetoothチップを備える、Bluetoothマルチメディアデバイスを制御するためのデバイスであり、Bluetoothチップは、Bluetoothの非ブロッキング使用に基づいて、前記いくつかのBluetoothマルチメディアデバイスの中からのそれぞれのBluetoothマルチメディアデバイスに各々、いくつかの相互接続されたマルチメディアストリームをストリーミングする。
2つの前述の実装形態では、コンピュータプログラムは、メモリ(たとえば、EEPROM、フラッシュ、または他のROMタイプ)内に記憶される。このメモリは、Bluetoothチップ内に、または、Bluetoothマルチメディアデバイスを制御するためのデバイス内だが、Bluetoothチップ外に埋め込まれ得る。変形例によれば、コンピュータプログラムは、部分的にはBluetoothチップ内に、部分的にはBluetoothマルチメディアデバイスを制御するためのデバイス内に記憶される。変形例によれば、Bluetoothマルチメディアデバイスを制御するためのデバイス、およびBluetoothチップは、各々、少なくとも1つの別個のプロセッサを備え、各々が、単一の場所(単一のメモリチップ)内に、またはいくつかのメモリチップ(たとえば、BluetoothチップのメモリチップおよびBluetoothマルチメディアデバイスを制御するためのデバイスのメモリチップ)内に分散して記憶されたコンピュータプログラムの一部を実行する。
別の実装形態によれば、方法は、コンピュータプログラムによって実施されず、たとえば、FPGAまたはアドホックな回路を含む他の適切な回路である専用電子チップによって実施される。変形例によれば、方法は、部分的には上述した専用チップのような専用電子チップによって、部分的には適切なコンピュータプログラムを実行するプロセッサによって実施される。
第6の実施形態によれば、第5の実施形態によるBluetoothマルチメディアデバイスを制御するための方法のBluetoothチップは、BluetoothチップがBluetoothマルチメディアデバイスに送信したマルチメディアストリームパケットが失われたとき、Bluetoothチップは、前記マルチメディアストリームパケットを前記Bluetoothマルチメディアデバイスに再送信し、Bluetoothマルチメディアデバイスのバッファメモリの充填率に基づいて、失われたマルチメディアストリームパケットをBluetoothマルチメディアデバイスに再送信することができる最大持続時間を推測するために、各BluetoothマルチメディアデバイスSPK1、SPK2、SPKNのバッファメモリの充填率を決定する。
第7の実施形態によれば、第5または第6の実施形態によるBluetoothマルチメディアデバイスを制御するための方法のBluetoothチップは、BluetoothマルチメディアデバイスSPK1、SPK2、...SPKNを制御するためにいくつかのSEPS、SEP1、SEP2、...SEPNを生成する。
第8の実施形態によれば、第5〜第7の実施形態のうちの1つによるBluetoothマルチメディアデバイスを制御するための方法のBluetoothチップは、SBCコーデックを使用することによって5つのBluetoothマルチメディアデバイスを制御する。
第9の実施形態は、プロセッサによって実施されると、第5〜第8の実施形態のうちの1つによる方法を実施する一連の命令を含むコンピュータプログラムに言及する。このコンピュータプログラムは、たとえば、アセンブラ言語のような低レベル言語で、またはC言語のようなより高いレベルでより移植性の高い言語で書かれる。可能な実装形態によれば、コンピュータプログラムは、いくつかのモジュールに分割される。可能な実装形態によれば、様々なモジュールは、すべて同じ言語、例えば、C言語またはアセンブラ言語で書かれる。代替案によれば、特定のモジュールは、異なる言語で書かれ、例えば、特定のモジュールは、C言語で書かれ、他のモジュールは、アセンブラ言語で書かれる。可能な実装形態によれば、すべてのモジュールは、同じメモリ内に記憶される。代替案によれば、特定のモジュールは、別個のメモリ内に記憶される。
第10の実施形態は、第9の実施形態によるコンピュータプログラムを記憶する非一時的コンピュータ可読記憶媒体に言及する。可能な実装形態によれば、記憶媒体は、USBキー、SDカード、またはマイクロSDカードである。変形例では、記憶媒体は、任意のメモリカードである。別の変形例によれば、記憶媒体は、電子回路に搭載されることが意図されたメモリチップである。たとえば、それは、EEPROM、ROM、または他のフラッシュメモリである。可能な変形例によれば、記憶媒体は、(例えば、ハードディスクタイプの)磁気媒体または(たとえば、CDまたはDVDタイプの)光学媒体である。
本発明は、例として上記で説明した実施形態に限定されない。使用可能なメモリは、任意のタイプのメモリをカバーする。
Bluetoothマルチメディアデバイスを制御するためのデバイスに関して説明した実施形態は、Bluetoothマルチメディアデバイスを制御するための方法、ならびに、本発明の実施形態によるコンピュータプログラムおよびコンピュータプログラムの記憶媒体に適用可能であり得、逆もまた同様である。
A2DP アドバンストオーディオ配信プロトコル
A2DP' 修正されたA2DPプロファイル
AASi アプリケーションオーディオシンク
AASo アプリケーションオーディオシンク
AVDTP オーディオ/ビデオ配信転送プロトコル
AVDTP' オーディオ/ビデオ配信転送プロトコル
BB ベースバンド基礎的要素
BC Bluetoothチップ
BC' Bluetoothチップ
DEV デバイス
DEV' デバイス
L2CAP 論理リンク制御および適応プロトコル
LMP リンクマネージャプロトコル
LNK ポイントツーマルチポイントリンク
LNK' ポイントツーマルチポイントリンク
SDP サービス発見プロトコル
SEP1 ストリームエンドポイント
SEP2 ストリームエンドポイント
SEPN ストリームエンドポイント
SEPS1 ストリームエンドポイント
SEPS2 ストリームエンドポイント
SEPSN ストリームエンドポイント
SPK1 Bluetoothスピーカ、Bluetoothマルチメディアデバイス
SPK2 Bluetoothスピーカ、Bluetoothマルチメディアデバイス
SPKN Bluetoothスピーカ、Bluetoothマルチメディアデバイス
USEP 固有のSEP

Claims (10)

  1. Bluetooth(登録商標)マルチメディアデバイスを制御するためのデバイス(DEV、DEV')であって、前記制御デバイスが、Bluetoothチップ(BC、BC')からいくつかのBluetoothマルチメディアデバイス(SPK1、SPK2、SPKN)へのポイントツーマルチポイントリンク(LNK、LNK')を作成するように、修正されたA2DPプロファイル(A2DP')を実装するように構成された前記Bluetoothチップを備え、前記制御デバイスの前記Bluetoothチップが、非ブロッキングBluetooth使用に基づいて、前記いくつかのBluetoothマルチメディアデバイスの中からのそれぞれのBluetoothマルチメディアデバイスに各々、いくつかの相互接続されたマルチメディアストリームをストリーミングするように構成される、デバイス。
  2. 前記Bluetoothチップは、前記BluetoothチップがBluetoothマルチメディアデバイスに送信したマルチメディアストリームパケットが失われたとき、前記マルチメディアストリームパケットを前記Bluetoothマルチメディアデバイスに再送信するように構成され、前記Bluetoothチップが、少なくとも1つのBluetoothマルチメディアデバイス(SPK1、SPK2、SPKN)のバッファメモリの充填率を決定し、前記少なくとも1つのBluetoothマルチメディアデバイスの前記バッファメモリの前記充填率に従って、前記失われたマルチメディアストリームパケットを前記Bluetoothマルチメディアデバイスに再送信することができる最大持続時間を決定するように構成される、請求項1に記載のBluetoothマルチメディアデバイスを制御するためのデバイス。
  3. 前記Bluetoothチップ(BC)が前記Bluetoothマルチメディアデバイスを制御するためにいくつかのSEPを生成するように構成される、請求項1または2に記載のBluetoothマルチメディアデバイスを制御するためのデバイス(DEV)。
  4. 前記BluetoothチップがSBCコーデックを使用することによって5つまでのBluetoothマルチメディアデバイスを制御するように構成される、請求項1から3のいずれか一項に記載のBluetoothマルチメディアデバイスを制御するためのデバイス。
  5. BluetoothチップによってBluetoothマルチメディアデバイスを制御するための方法であって、前記Bluetoothチップが、前記BluetoothチップからいくつかのBluetoothマルチメディアデバイスへのポイントツーマルチポイントリンクを作成するように、修正されたA2DPプロファイル(A2DP')を実装し、前記Bluetoothチップが、非ブロッキングBluetooth使用に基づいて、前記いくつかのBluetoothマルチメディアデバイスの中からのそれぞれのBluetoothマルチメディアデバイスに各々、いくつかの相互接続されたマルチメディアストリームをストリーミングする、方法。
  6. 前記BluetoothチップがBluetoothマルチメディアデバイスに送信したマルチメディアストリームパケットが失われたとき、前記Bluetoothチップが前記マルチメディアストリームパケットを前記Bluetoothマルチメディアデバイスに再送信し、少なくとも1つのBluetoothマルチメディアデバイス(SPK1、SPK2、SPKN)のバッファメモリの充填率に従って、前記失われたマルチメディアストリームパケットを前記Bluetoothマルチメディアデバイスに再送信することができる最大持続時間を推測するために、前記少なくとも1つのBluetoothマルチメディアデバイスの前記バッファメモリの前記充填率を決定する、請求項5に記載のBluetoothマルチメディアデバイスを制御するための方法。
  7. 前記Bluetoothチップが、前記Bluetoothマルチメディアデバイス(SPK1、SPK2、SPKN)を制御するためにいくつかのSEP(SEP1、SEP2、SEPN)を生成する、請求項5または6に記載のBluetoothマルチメディアデバイスを制御するための方法。
  8. 前記Bluetoothチップが、SBCコーデックを使用することによって5つのBluetoothマルチメディアデバイスを制御する、請求項5から7のいずれか一項に記載のBluetoothマルチメディアデバイスを制御するための方法。
  9. プロセッサによって実行されると、請求項5から8のいずれか一項に記載の方法を実施する一連の命令を含むコンピュータプログラム。
  10. 請求項9に記載のコンピュータプログラムを記憶する非一時的コンピュータ可読記憶媒体。
JP2019524515A 2016-07-22 2017-07-19 Ｂｌｕｅｔｏｏｔｈマルチメディアデバイスの制御 Active JP6949956B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR1657050A FR3054399B1 (fr) 2016-07-22 2016-07-22 Pilotage de dispositifs multimedia bluetooth
FR1657050 2016-07-22
PCT/EP2017/068234 WO2018015439A1 (en) 2016-07-22 2017-07-19 Controlling bluetooth multimedia devices

Publications (2)

Publication Number Publication Date
JP2019531669A true JP2019531669A (ja) 2019-10-31
JP6949956B2 JP6949956B2 (ja) 2021-10-13

Family

ID=57750038

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019524515A Active JP6949956B2 (ja) 2016-07-22 2017-07-19 Ｂｌｕｅｔｏｏｔｈマルチメディアデバイスの制御

Country Status (7)

Country Link
US (1) US10244018B2 (ja)
EP (1) EP3273705B1 (ja)
JP (1) JP6949956B2 (ja)
KR (1) KR20190033525A (ja)
CN (1) CN109661828B (ja)
FR (1) FR3054399B1 (ja)
WO (1) WO2018015439A1 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10497191B2 (en) * 2016-08-10 2019-12-03 Elwha Llc Systems and methods for individual identification and authorization utilizing conformable electronics
EP3319331B1 (en) * 2016-11-04 2020-01-29 Nagravision S.A. Transmission of audio streams
US11818185B2 (en) * 2018-03-28 2023-11-14 L&T Technology Services Limited Audio streaming from host Bluetooth device to multiple receiving Bluetooth devices
WO2020239985A1 (en) * 2019-05-31 2020-12-03 Tap Sound System Method for operating a bluetooth device
EP3771238B1 (en) * 2019-07-26 2022-09-21 Google LLC Method for managing a plurality of multimedia communication links in a point-to-multipoint bluetooth network
CN110996305B (zh) * 2019-11-12 2024-01-05 宇龙计算机通信科技(深圳)有限公司 连接蓝牙设备的方法、装置、电子设备及介质
CN111885575B (zh) * 2020-09-28 2021-02-26 深圳市汇顶科技股份有限公司 流端点控制方法、电子设备以及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010004485A (ja) * 2008-06-23 2010-01-07 Toshiba Corp リモコン制御方法、装置及びリモコン制御システム

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0000573D0 (en) * 2000-01-12 2000-03-01 Nokia Mobile Phones Ltd Receiver based isochronous transmissions
GB0102261D0 (en) * 2001-01-29 2001-03-14 Vtech Communications Ltd Enhanced cordless telephone platform using bluetooth technology
US20020159401A1 (en) * 2001-04-25 2002-10-31 Brightcom Technologies Ltd. Masterless slave / master role switch in a bluetooth piconet
WO2004056052A2 (en) * 2002-12-18 2004-07-01 Koninklijke Philips Electronics N.V. Bluetooth broadcast data stream to multiple bluetooth mobile terminals
FR2920930B1 (fr) 2007-09-06 2010-04-16 Parrot Systeme synchronise de distribution et de traitement de signaux,notamment de signaux audio dans un reseau d'enceintes sans fil
WO2009088937A2 (en) * 2008-01-02 2009-07-16 Interdigital Technology Corporation Method and apparatus for cooperative wireless communications
US20090234983A1 (en) * 2008-03-17 2009-09-17 Golden Signals, Inc. Methods and apparatus for sharing a computer display screen
CN101888288A (zh) * 2009-05-13 2010-11-17 艾威梯科技(北京)有限公司 解决全双工数据传输时ack互锁延时的方法和***
CN101917480A (zh) * 2010-08-19 2010-12-15 中兴通讯股份有限公司 多蓝牙设备信息传输的方法及***
US8768252B2 (en) * 2010-09-02 2014-07-01 Apple Inc. Un-tethered wireless audio system
US9088406B2 (en) * 2012-07-29 2015-07-21 Qualcomm Incorporated Frame sync across multiple channels
US9014633B2 (en) * 2013-03-07 2015-04-21 Kin-Man TSE Bluetooth communication system and method for selectively switching modes of operation in between electronic devices
CN103618745A (zh) * 2013-12-11 2014-03-05 天津安普德科技有限公司 一种改进的蓝牙a2dp高保真音频传输协议

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010004485A (ja) * 2008-06-23 2010-01-07 Toshiba Corp リモコン制御方法、装置及びリモコン制御システム

Also Published As

Publication number Publication date
EP3273705B1 (en) 2018-10-17
KR20190033525A (ko) 2019-03-29
CN109661828B (zh) 2022-05-27
FR3054399B1 (fr) 2018-08-03
EP3273705A1 (en) 2018-01-24
FR3054399A1 (fr) 2018-01-26
JP6949956B2 (ja) 2021-10-13
CN109661828A (zh) 2019-04-19
US10244018B2 (en) 2019-03-26
US20180027034A1 (en) 2018-01-25
WO2018015439A1 (en) 2018-01-25

Similar Documents

Publication Publication Date Title
JP6949956B2 (ja) Ｂｌｕｅｔｏｏｔｈマルチメディアデバイスの制御
JP7426448B2 (ja) 接続されたマルチメディアデバイスの制御
US12003934B2 (en) Controlling dual-mode bluetooth low energy multimedia devices
US11800284B2 (en) Bluetooth device and method for controlling a plurality of wireless audio devices with a Bluetooth device
US11889281B2 (en) Method for managing a plurality of multimedia communication links in a point-to-multipoint Bluetooth network
CN114270436A (zh) 无线通信***中的自适应音频处理方法、设备、计算机程序及其记录介质
CN114747176A (zh) 用于在无线通信***中设置加密密钥的方法、装置和计算机程序及其记录介质
CN115669051A (zh) 用于在无线通信***中选择通道的方法、设备和计算机程序及其记录介质

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200603

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210823

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210922

R150 Certificate of patent or registration of utility model

Ref document number: 6949956

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: R3D02