【課題を解決するための手段】
【0004】
データ・セットをワイヤレス通信する新規な方法であって、以下を含む方法が提供される。
a) 第1のデータ・カテゴリの第1のデータ・セットを、送信装置から受信装置に受信させるために送信するステップ。
b) 受信装置からの受信の肯定応答がない場合、第1のデータ・セットを再送信するステップ。
c) 受信装置からの受信の肯定応答がある場合、肯定応答がなければ送信装置と受信装置が再送信のために接続される時に、例えば、第1のデータ・カテゴリの第1のデータ・セットが送信されたのと同じ接続イベント内で、第1のデータ・カテゴリとは異なる第2のデータ・カテゴリの第2のデータ・セットを、送信装置から受信装置に送信するステップ。
【0005】
さらに、異なる優先度を有するデータをワイヤレス通信する新規な方法であって、以下を含む方法が提供される。
a) 第1の優先度の第1のデータ・セットを、送信装置から受信装置に受信させるために送信するステップ。
b) 受信装置からの受信の肯定応答がない場合、第1の優先度の第1のデータ・セットを再送信するステップ。
c) 受信装置からの受信の肯定応答がある場合、肯定応答がなければ送信装置と受信装置が再送信のために接続される時に、第1の優先度よりも低い第2の優先度を有する第2のデータ・セットを、送信装置から受信装置に送信するステップ。
【0006】
第1のデータ・カテゴリは、オーディオ・データ・セットを含んでよい。
【0007】
第2のデータ・カテゴリは、ブルートゥース・コア仕様4.1またはそれ以前のバージョンで定義されるようなブルートゥースLE標準プロトコルに準拠した、開始、停止、コーデック・ネゴシエーションなどのさまざまな制御データ、および/または他の装置、例えば、温度センサのような環境センサなどのセンサを備えた装置からのデータを含んでよい。
【0008】
第1のデータ・セットは、オーディオ・データ・セットであってもよい。オーディオ・データ・セットは、一連の離散時間および離散振幅のデジタル・オーディオ信号値などのデジタル・オーディオ信号値を含み、一連の離散時間および離散振幅のデジタル・オーディオ信号値は、アナログ・オーディオ信号の連続時間および連続振幅値を表しており、そのアナログ・オーディオ信号を、音響に変換することができる。換言すれば、ストリーミング・オーディオの技術分野で周知のように、オーディオ・データ・セットは、ある時点で音に変換するためのものであるデジタル・データを含む。
【0009】
好ましくは、送信されるオーディオ・データ・セットに基づいて生成される音の高忠実度または少なくとも許容可能な質を確保するために、オーディオ・データ・セットは高優先度を有し、より低い優先度を有する他のタイプのデータ・セットを送信する前にそのオーディオ・データ・セットの送信を確実にする。
【0010】
オーディオ・データ・セットを含めて、データ・セットは、2種類のデータ、すなわち制御情報およびデータ、を有するデータ・パケットとすることができる。データは、ペイロードまたはペイロード・データとしても知られる。制御情報は、データすなわちペイロードを目当ての受信装置に送達するためにネットワークが必要とする情報データ、例えば、送信元装置アドレスおよび宛先装置アドレス、エラー検出コード、ならびに順序制御情報をもたらす。典型的には、制御情報は、パケットのヘッダおよびトレーラ内に見られ、ペイロード・データがその間にある。
【0011】
本方法はさらに、以下を含んでいてもよい。
d) 第2の優先度を有するデータ・セットが受信装置への送信を待っているか否かについて、送信装置から受信装置に信号送信するステップ。
e) 受信装置への送信を待っている第2の優先度を有するデータ・セットがない場合、第2の優先度を有する第2のデータ・セットの送信のための送信装置と受信装置の間の接続を確立するのを停止するステップ。
【0012】
第2の優先度を有するデータ・セットが受信装置への送信を待っているか否かに関する情報は、単一データ・ビットなどの単一データ・バイトに符号化してもよい。
【0013】
本方法は、ブルートゥース・コア仕様4.1またはそれ以前のバージョンなどのブルートゥース・ロー・エナジー標準規格に準拠してもよく、好ましくは、オーディオ・データ・セットの送信が、連続する接続イベント内で実施される。
【0014】
本方法は、ブルートゥース・コア仕様4.1またはそれ以前のバージョンなどのブルートゥース・ロー・エナジー標準規格に準拠した形で、例えば音声および音楽のオーディオ・ストリーミングに利用してもよい。
【0015】
本方法はさらに、L2CAPチャネルをオーディオ・データ・セットの送信に割り当てることを含んでいてもよく、例えば、1つのL2CAPチャネルをオーディオ・データ・セットに関連する制御データに割り当て、かつ/または、1つのL2CAPチャネルを第1のオーディオ・データ・セットに割り当て、可能であれば別のL2CAPチャネルを第2のオーディオ・データ・セットに割り当ててもよい。
【0016】
次の3つの固定L2CAPチャネルをオーディオ伝送に割り当ててもよい。
1) 制御データ(開始、停止、コーデック・ネゴシエーションなど)
2) 左オーディオ・データ
3) 右オーディオ・データ
【0017】
1つのオーディオ・ストリーム(左または右)を受信することのできる装置、例えば補聴器では、チャネル1)および2)、またはチャネル1)および3)だけがその装置に使用されていることになる。ステレオ機能が統合された装置、例えばステレオ・ヘッドセットでは、これら3つのチャネルが全て使用される。オーディオ・データ・セットは、適用分野に応じて単方向でも双方向でもよく、制御データ・チャネルが、その点に関するネゴシエーションを可能にするべきである。
【0018】
接続コンフィギュレーション(Connection Configuration)は、例えば、以下の手順によって実施してもよい。
1.受信装置が、優先度の付いたフラッシュ可能なL2CAP(PFL2CAP:prioritized and flushable L2CAP)データを受信できることを、一意のUUIDを通じて知らせる。
2.送信装置が受信装置を発見し、受信装置に接続し、PFL2CAPサービスにその機能について問い合わせる。
3.受信装置はPFL2CAPコンフィギュレーションで応答する。例えばオーディオ向けでは、これには、受信装置がどのコーデックを提供するか、また受信装置がどのL2CAPチャネル上でどのコンテンツをどの優先度で受信するつもりか、例えば(チャネル127、高優先度、左側オーディオ)、(チャネル128、高優先度、右側オーディオ)、および(チャネル129、低優先度、オーディオ制御情報)が含まれ得る。
4.送信装置が、データについての追加情報、例えばコンテンツ、コーデックおよびフレームのサイズ、フラッシュ・タイムアウトなどに関する情報を送信することによって、受信に対し肯定応答する。
5.送信装置と受信装置がどちらも、新たなL2CAPチャネルをセットアップし、オーディオ・ストリームの準備をし、接続率を、指定されたフレーム率に再送信回数を掛けた積に合致するように調整する。
【0019】
例えばオーディオをストリーミングしている間の送信装置の動作は、以下の内容を含んでいてもよい。
1.送信装置コントローラのホストが、オーディオ・ストリームの処理を開始し、第1のオーディオ・フレームを符号化し、指定されたL2CAPチャネル(複数可)上で即時に送信するためにキューに入れるように処理する。次いでホストは、次のオーディオ・フレームの処理に移る。
2.それと同時に、コントロール層が、パケットを優先度順に送信しようと試みる。送信が成功するとすぐに、コントロール層は、成功を通知して、ホストからの次のパケットを要求する。パケットがタイムアウトのためフラッシュされた場合、コントロール層は、失敗を通知した上で、やはり次のパケットを要求する。
3.ホストからのオーディオ制御情報、例えば音量変更が、指定されたL2CAPチャネル内でキューに入れられる。コントローラはそのパケットを、より高い優先度を有する待ち状態にある送信パケットがないときに送信する。
【0020】
本方法はさらに、オーディオ・データ・セットの受信装置から受信の肯定応答がない場合に、同じオーディオ・データ・セットの再送信の試行回数が、例えば2に等しい所定の最大値未満であることを条件として、オーディオ・データ・セットの再送信を含んでいてもよい。
【0021】
1つまたは複数のタイプのデータの再送信の試行回数は、限定されていなくてもよく、すなわち、1つまたは複数のタイプのデータに最大値が割り当てられない、または、換言すれば、1つまたは複数のタイプのデータに割り当てられた最大値が無限、例えば0xFFFFである、ということである。
【0022】
データのタイプが異なれば、再送信の試行に関する所定の最大値も異なってよく、例えば、オーディオ・データ・セットは最大値2を有することができ、一方オーディオ・データ・セットの優先度よりも低い優先度を有するデータ・セットの最大値。
【0023】
例えば、新規な方法は、ブルートゥース・ベーシック・レート(BR)L2CAPチャネルにも定義されている、L2CAPフラッシュ・タイムアウトを実装することができる。好ましくは、このタイムアウトは、HCIを経由してデータがポストされた後の、オーディオ・データを運ぶチャネルに関する2つの接続イベントに対応し(すなわち、L2CAPオーディオに対し第1の再試行イベントが可能になる)、一方、他のチャネルについては0xFFFFに留まる。
【0024】
典型的なリンク上では、パケットは、オーディオに適していない割合で損失され得る。したがって、好ましくは再送信が可能であり、好ましくは異なるチャネルで行われる。よって、ブルートゥースLEのMD機能を、再送信に使用することはできない。したがって、フラッシュ・タイムアウトが設定されたオーディオ・データ・セットをただ単に、接続間隔内で1度試行すべきである。再送信を可能にするために、接続間隔は、オーディオ・フレーム・サイズの半分にしなければならず、したがって、オーディオ・フレームが10msである場合、接続間隔は5msとすべきである。これは、既存のリンク層制御パケットを用いて促進される。
【0025】
MD機能は、同じ接続イベント内で低優先度データを送信するのに使用してもよいが、受信装置はMDビットを受け入れないことがあり、例えば、補聴器はMDビットを受け入れないだろう。
【0026】
受信装置の電力消費を低下させるために、送信装置は、高優先度データの後に同じ接続イベント内でデータを送信するか否かに関係なく、待ち状態にある低優先度データがあることを示すために高優先度パケット内にMDビットをセットするように構成してもよい。待ち状態にある低優先度データがない場合、MDビットはリセットされる。これにより、受信装置が、受信したMDビットの値に応答して、高優先度オーディオ・データ・セットの成功した送信同士の間にある、データのない接続イベントをスキップすることが可能になる。同様に、送信装置も、電力を節減するためおよび/または他のワイヤレス・サービスとの相互運用性を高めるために、オーディオ・ストリーミング中に、待ち状態にあるデータのない接続イベントをスキップすることが可能である。
【0027】
非オーディオ・データ・セットを送信する際、L2CAPフラッシュ・タイムアウトがないと、データに対し肯定応答されるまでリンクが占有されることになることに留意されたい。これにより、まれにオーディオにドロップアウトが生じ、これは、例えばEP2605547A1に開示されるように、受信側のパケット損失隠蔽によって対処しなければならない。
【0028】
本方法はさらに、送信装置から、オーディオ・データ・セットを受信するように構成された少なくとも1つの受信装置に、異なるオーディオ・データ・セットを受信するように接続された少なくとも2つの異なる受信装置間の送信遅延差に関連するタイミング情報を含んだ、同期データを送信することを含んでいてもよい。
【0029】
同期データの決定は、送信装置から少なくとも2つの異なる受信装置へのping送信、例えばL2CAP制御チャネルを利用したping送信に基づいてよい。
【0030】
好ましくは、ステレオ・オーディオ・ストリーミングの間、送信装置は、リンク間の時間オフセットをリンク内の先行する受信装置に伝達し、それにより、受信したオーディオをそれに応じて遅延させて、2つのステレオ・チャネルを適切に同期させることができる。時間オフセットは、制御チャネル経由でpingを実施するネットワーク・レイテンシ測定を用いて決定することができる。このpingにより、送信ホストは時間オフセットを計算することができる。
【0031】
ステレオ・オーディオ・ストリーミングは、1つのリンクを用いて実施することもできる。例えば、ヘッドホンに対してステレオ・オーディオ・ストリーミングする間、左L2CAPチャネルと右L2CAPチャネルをどちらも、同じリンクを用いて送信してもよく、それにより、受信装置と送信装置が両方ともシンプルに維持される。ヘッドホンは、より高い無線デューティ・サイクルに耐えることができるので、ブルートゥースLEのMD機能をこの目的に利用してもよい。このようにして、同一の接続イベントが、左チャネルと右チャネルの両方に関する情報を伝えることができ、パケット構造をモノまたはデュアル・シンクの場合と同じままに維持することができる。これにより、両側に対する実装を簡素にする。というのも、デュアル・シンクの場合と比較して、送信ホストの側でオーディオ用のコネクション・ハンドルだけを変更する必要があるためである。
【0032】
以下の表は、ms単位のある特定のオーディオ・フレーム・サイズが与えられた場合に、オーディオ・データ・セットを保持するのに要求される要求バイト数を概略的に示す。これらの値は、48kビット/sで流れるオーディオ・ストリーム用である。32kビット/sのオーディオ・ストリームの場合は、この要求の2/3となる。
【0033】
【表1】
【0034】
オーバーヘッドを最小限に抑えるためには、L2CAPオーディオを実施する方法またはコントローラが好ましくは長いパケットに対応するように、LLのMTUサイズを、L2CAPのMTUにヘッダおよびMICを加えた和に合致させ、かつ要求されるペイロード・サイズに等しくすることが好ましい。
【0035】
有利なことには、新規な方法は、ブルートゥースLEを利用したオーディオ・データ・セットの送信を、ブルートゥースLEのコントロールおよびリンク層の拡張機能を限定された形で利用することによって容易にし、例えば、セキュリティおよびリンク・セットアップに関連する動作は、ブルートゥース・コア仕様に規定された通りに実施される。
【0036】
添付の特許請求の範囲のいずれかに記載の新規な方法による動作に適するように構成された通信コントローラを有する聴覚装置も提供される。
【0037】
聴覚装置は、BTE、RIE、ITE、ITC、CICなどの補聴器、バイノーラル補聴器、イヤ・フック型、イン・イヤ型、オン・イヤ型、オーバー・イヤ型、ビハインド・ネック型、ヘルメット型、ヘッドガード型などのヘッドセット、ヘッドホン、イヤホン、イヤ・ディフェンダ、イヤマフなどでよい。
【0038】
好ましくは、通信コントローラは、ブルートゥースLEのL2CAPを用いたオーディオ送信および/またはオーディオの受信に適するように構成され、好ましくは、通信コントローラは、
−L2CAPフラッシュ・タイムアウト=2に対応する
−優先度の付いたL2CAPトラフィックに対応する
−ビットレートおよびオーディオ・フレーム・サイズの選択に応じて、120バイトまでのLLパケット・サイズに対応する
ように構成される。
【0039】
したがって、ブルートゥースLE標準プロトコルに準拠してワイヤレス通信を実施することのできる、新規な補聴器が提供される。
【0040】
新規な補聴器は、
そこに与えられた、音を表す信号に基づいて、オーディオ信号を出力するように構成された入力トランスデューサ、および
補聴器の利用者の聴力損失を補償し、聴力損失補償されたオーディオ信号を出力するように構成された聴力損失プロセッサを備え、例えば、この補聴器は、健聴者であれば知覚するような与えられた信号の音の大きさが、利用者が知覚する聴力損失補償された信号の音の大きさにほぼ合致するように、音の大きさを取り戻すことを目的とすることができ、さらに
聴力損失補償されたオーディオ信号に基づく聴覚出力信号を出力するように構成された、受話器、埋込み型トランスデューサなどの出力トランスデューサであって、人間の聴覚系がその聴覚出力信号を受信することができ、それにより利用者に音が聞こえる、出力トランスデューサ、および
通信コントローラ
を備えていてもよい。
【0041】
トランスデューサは、あるエネルギーの形態でトランスデューサに与えられた信号を、それに対応する別のエネルギーの形態をとる出力信号に変換する装置である。
【0042】
入力トランスデューサは、マイクロホンを備えることができ、マイクロホンは、マイクロホンに与えられた音響信号を、それに対応する、音響信号の音圧に伴ってその瞬時電圧が連続的に変動するアナログ・オーディオ信号に変換する。
【0043】
入力トランスデューサは、テレコイルを備えていてもよい。テレコイルは、テレコイルにおいて変動する磁界を、対応するアナログ・オーディオ信号であって、テレコイルにおいて変動する磁界強度に伴って瞬時電圧が連続的に変動する、変動するアナログ・オーディオ信号に変換する。テレコイルは、例えば、教会、公会堂、劇場、映画館内などの公共の場において、または駅、空港、ショッピング・モール内などの拡声装置を通じて、複数の人々に向けて話している話者からの音声の信号対雑音比を上げるために使用することができる。話者からの音声は、誘導ループ・システム(「ヒアリング・ループ」とも呼ばれる)を用いて磁界に変換され、テレコイルを使用して、磁気的に送信された音声信号を磁気的に拾い上げる。
【0044】
入力トランスデューサはさらに、少なくとも2つの離隔されたマイクロホンと、少なくとも2つの離隔されたマイクロホンのマイクロホン出力信号を組み合わせて、指向性マイクロホン信号にするように構成されたビームフォーマとを備えていてもよい。
【0045】
入力トランスデューサは、1つまたは複数のマイクロホンと、テレコイルと、例えば無指向性マイクロホン信号、または指向性マイクロホン信号、またはテレコイル信号を、単独でまたは任意の組合せで、オーディオ信号として選択するためのスイッチとを備えていてもよい。
【0046】
典型的には、アナログ・オーディオ信号は、アナログ・デジタル変換器において対応するデジタル・オーディオ信号に変換し、それにより、アナログ・オーディオ信号の振幅が2進数で表されることによって、デジタル信号処理に適したものになる。このようにして、一連のデジタル値の形態をとる離散時間および離散振幅のデジタル・オーディオ信号が、連続時間および連続振幅のアナログ・オーディオ信号を表す。
【0047】
本開示全体を通じて、「オーディオ信号」は、入力トランスデューサの出力から聴力損失プロセッサの入力に至る信号経路の一部を成す任意のアナログまたはデジタル信号を特定するために使用してもよい。
【0048】
本開示全体を通じて、「聴力損失補償されたオーディオ信号」とは、聴力損失プロセッサの出力から、場合によってはデジタル・アナログ変換器を介して、出力トランスデューサの入力に至る信号経路の一部を成す任意のアナログまたはデジタル信号を特定するために使用され得る。
【0049】
補聴器は、ワイヤレス送信機とワイヤレス受信機を両方備えた送受信機を備えることができる。送信機および受信機は、共通回路および/または単一のハウジングを共有してもよい。あるいは、送信機および受信機は回路を共有しなくてもよく、ワイヤレス通信ユニットが、それぞれ送信機および受信機を備えた別々の装置を備えていてもよい。
【0050】
補聴器は、有利なことには、例えば2つの補聴器が、オーディオ信号などのデータ、信号処理パラメータ、信号処理プログラムの識別子などの制御データなどをデジタル交換するために、ブルートゥースLE標準プロトコルを利用して相互接続され、オプションとして、タブレット型コンピュータ、スマートフォン(例えばIPhone、Androidフォン、Windowsフォンなど)、リモート・コントロールなどの手持ち型装置など、他の装置と相互接続される、バイノーラル補聴器システムに組み込んでもよい。
【0051】
典型的には、補聴器の電源からは限られた量の電力しか利用できない。例えば、電力は、典型的には、補聴器内の従来型のZnO
2電池から供給される。
【0052】
補聴器の設計に際しては、サイズおよび電力消費が考慮すべき重要な事項である。
【0053】
新規な補聴器での信号処理は、専用のハードウェアによって実施してもよく、あるいは1つまたは複数の信号プロセッサにおいて実施してもよく、あるいは、専用のハードウェアと1つまたは複数の信号プロセッサとの組合せにおいて実施してもよい。
【0054】
同様に、通信コントローラの動作は、専用のハードウェアによって実施してもよく、あるいは1つまたは複数のプロセッサにおいて実施してもよく、あるいは専用のハードウェアと1つまたは複数のプロセッサとの組合せにおいて実施してもよい。
【0055】
本明細書では、「プロセッサ」、「信号プロセッサ」、「コントローラ」、「システム」などという用語は、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかの、CPU関連のエンティティを指すものとする。
【0056】
例えば、「プロセッサ」、「信号プロセッサ」、「コントローラ」、「システム」などは、そうであることに限定されないが、プロセッサ上で実行される処理、プロセッサ、オブジェクト、実行可能ファイル、実行のスレッド、および/またはプログラムであってよい。
【0057】
例として、「プロセッサ」、「信号プロセッサ」、「コントローラ」、「システム」などという用語は、プロセッサ上で実行するアプリケーションとハードウェア・プロセッサの両者を指す。1つまたは複数の「プロセッサ」、「信号プロセッサ」、「コントローラ」、「システム」など、またはこれらの任意の組合せは、プロセスおよび/または実行のスレッド内に存在していてもよく、1つまたは複数の「プロセッサ」、「信号プロセッサ」、「コントローラ」、「システム」など、またはこれらのいずれかの組合せは、場合によっては他のハードウェア回路と組み合わせて、1つのハードウェア・プロセッサ上に集中させ、かつ/または、場合によっては他のハードウェア回路と組み合わせて、2つ以上のハードウェア・プロセッサの間で分散させていてもよい。
【0058】
また、プロセッサ(または類似の用語)は、信号処理を実施することができる任意の構成要素であってもよく、そのような構成要素の任意の組合せであってもよい。例えば、信号プロセッサは、ASICプロセッサ、FPGAプロセッサ、汎用プロセッサ、マイクロプロセッサ、回路構成要素、または集積回路であってよい。
【0059】
以下では、新規な方法および補聴器について、図面を参照してより詳細に説明する。