パケット通信方法
【課題】同時に多様な通信状態を許容しつつ、その中でも優先度の高いデータに対して充分な受信帯域を確保することができるパケット通信方法を提供する。
【解決手段】ローカルデバイス（３０）とリモートデバイス（１４）との間でＢｌｕｅｔｏｏｔｈ（登録商標）によるＲＦＣＯＭＭ接続が完了すると（ＳＴ５０）、リモートデバイス（１４）には初期クレジット７が通知される。マルチプロファイル状態の変化を検知すると、カレントクレジットが０になるまでリモートデバイス（１４）からローカルデバイス（３０）パケットを送信し（ＳＴ５１〜ＳＴ６１）、待機時間を待機してパケット数を１に減少させる（ＳＴ６２〜ＳＴ６５）。これにより、相対的に他の通信処理に割り当てられる帯域を確保し、通信を優先させることができる。
【解決手段】ローカルデバイス（３０）とリモートデバイス（１４）との間でＢｌｕｅｔｏｏｔｈ（登録商標）によるＲＦＣＯＭＭ接続が完了すると（ＳＴ５０）、リモートデバイス（１４）には初期クレジット７が通知される。マルチプロファイル状態の変化を検知すると、カレントクレジットが０になるまでリモートデバイス（１４）からローカルデバイス（３０）パケットを送信し（ＳＴ５１〜ＳＴ６１）、待機時間を待機してパケット数を１に減少させる（ＳＴ６２〜ＳＴ６５）。これにより、相対的に他の通信処理に割り当てられる帯域を確保し、通信を優先させることができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のデバイス間でパケットデータを送受信するためのパケット通信方法に関するものである。
【背景技術】
【０００２】
従来、オーディオ信号や映像信号のように連続性があり、かつ、リアルタイム性を確保する必要があるデータの送受信に適した無線通信方法が知られている（例えば、特許文献１参照。）。この先行技術は、通信装置が他のデバイスとの間でデータ通信を行う際、通信対象として複数のデバイスが検出された場合にリアルタイム性が要求されるデバイスとそれ以外のデバイスとを区別して認識しておき、先にリアルタイム性が要求されない方のデバイスとの通信を確立し、その後でリアルタイム性が要求されるデバイスとの間でオーディオ信号の伝送を行うものである。また先行技術では、通信装置においてリアルタイム性が要求されるデバイスとの間でデータ伝送が行われている間、その他のデバイスの検出や既に通信を確立したデバイスとの通信を行わないこととしている。
【０００３】
上記の先行技術によれば、例えばオーディオ機器から通信機器に対してオーディオ信号等の伝送が行われている間、それ以外のデバイスである携帯電話機との通信は原則として行われない。この場合、例えば１曲分のオーディオ信号の伝送が終了するまでの間はオーディオ機器との通信が優先されるため、リアルタイム性を失うことなくオーディオの再生が可能になると考えられる。
【０００４】
さらに先行技術では、オーディオデータの再生及び転送を優先している間であっても、例えば携帯電話機に着信があると、割り込み処理によって携帯電話機との通信を実行することができる。このため、通常はリアルタイム性を優先しつつ、通話等の急を要する状況が発生した場合はそちらに通信を切り替えることができるので、ユーザの要望に応じた態様で通信を実行することができると考えられる。
【特許文献１】特開２００６−３５２７９９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら上記の先行技術は、リアルタイム性が要求されるデバイスを優先するあまり、それ以外のデバイスとの通信を大きく犠牲にしている。このため先行技術の通信方法は、ユーザにとってあまり利便性が高いとはいえない。例えば、複数のデバイスを同時並行してユーザが使用しようとしても、先行技術の手法ではリアルタイム性が要求されるデータの伝送が終了するまで他のデバイスは使用できなくなるという不便さがある。
【０００６】
そうかといって、複数のデバイスから同時並行してデータの伝送を行うことを単純に許可しただけでは、リアルタイム性を要求されるデータの受信帯域が圧迫されてしまい、オーディオ等を再生する際の品質を劣化させてしまうことになる。
【０００７】
また近年、Ｂｌｕｅｔｏｏｔｈ（登録商標）対応製品の多様化により、１つの通信システム内で複数のデバイスが別々のアプリケーションを同時に実行するというケースが増えつつある。例えば、ダイアルアップやシリアルポートを用いたアプリケーションによるデータアクセス中に、これとは別のオーディオアプリケーションによる音楽の再生が開始されたり、さらに別のハンズフリーアプリケーションによる音声通話が開始されたりすることがある。このような場合、いずれの通信も中断させることなく、その中でオーディオ再生の音質を優先したり、音声通話の音質を優先したりすることへの要望が高まってきている。
【０００８】
そこで本発明は上記の事情に鑑み、同時に多様な通信状態を許容しつつ、その中でも優先度の高いデータに対して充分な受信帯域を確保することができるパケット通信方法を提供しようとするものである。
【課題を解決するための手段】
【０００９】
解決手段１：本発明は、複数の通信プロファイルを用いて通信する機能を有したローカルデバイス及びリモートデバイスから構成される通信システム内で使用されるパケット通信方法である。詳細には、ローカルデバイスとリモートデバイスとの通信開始時に予めローカルデバイスが受信可能なパケット数をリモートデバイスに通知し、この通知されたパケット数分のデータをリモートデバイスからローカルデバイスに送信してローカルデバイスで受信する通信処理を繰り返しながら所望量のパケットデータを送受信するパケット通信方法である。その上で本発明のパケット通信方法は、以下の工程に特徴を有するものである。
【００１０】
（１）検出工程
この工程は、ローカルデバイスがいずれかのリモートデバイスとの間で通信処理を実行する際、複数ある通信プロファイルの中でいずれの通信プロファイルを用いて通信処理が実行されているかを検出するものである。
【００１１】
すなわち通信プロファイルは、それ自身が使用する通信プロトコルを特定しているため、通信処理で用いられている通信プロファイルを検出することで、その通信処理がどのような通信状態にあるのかを識別することができる。
【００１２】
（２）減少工程
この工程は、ローカルデバイスが特定のリモートデバイスとの間で通信処理を実行中に、同じ特定のリモートデバイスか、もしくは別のリモートデバイスとの間で現在とは異なる別の通信プロファイルを用いて別の通信処理が実行されたことを検出した場合、現在実行中の通信処理の中でローカルデバイスが特定のリモートデバイスに通知する受信可能なパケット数を減少させることにより、別の通信プロファイルを用いた通信処理の中でローカルデバイスが受信可能なパケット数を相対的に増加させるものである。
【００１３】
これにより、現在実行中の通信処理はパケット数の減少によって相対的に帯域が狭められるが、その一方で別の通信プロファイルを用いた通信処理に割くことができる帯域を相対的に広げることができる。このため、意図的に優先させたい通信処理のスループットをそれだけ多くしつつ、いずれの通信処理も犠牲にすることなく同時並行して通信システム内でのデータ通信を継続することができる。
【００１４】
解決手段２：解決手段１のパケット通信方法において、さらに以下の工程を有してもよい。
【００１５】
（３）待機工程
この工程は、ローカルデバイスが特定のリモートデバイスとの間で通信処理を実行中に、同じ特定のリモートデバイスか、もしくは別のリモートデバイスとの間で現在とは異なる別の通信プロファイルを用いて別の通信処理が実行されたことを検出した場合、現在実行中の通信処理の中に待機時間を挿入するものである。
【００１６】
このような工程を追加することにより、上記（２）の減少工程による帯域の確保と合わせて、より優先させたい通信処理に対して必要な帯域を割り当てることができる。
【００１７】
解決手段３：解決手段２において、待機時間を挿入する工程では、現在実行中の通信処理の中でローカルデバイスが特定のリモートデバイスに受信可能なパケット数を通知する前に待機時間を挿入することが好ましい。
【００１８】
上記のように本パケット通信方法では、ローカルデバイスから受信可能なパケット数を通知するまでは、リモートデバイスからローカルデバイスに対してデータを送信することができない。したがって、ローカルデバイスからリモートデバイスへ受信可能なパケット数を通知する前に待機時間を挿入すれば、それだけ現在の通信処理に遅延が発生するため、相対的に別の通信処理の優先度を高めることができる。
【００１９】
解決手段４：解決手段１から３のパケット通信方法において、パケット数を相対的に増加させる工程では、現在の通信プロファイルに比較して別の通信プロファイルの方がよりリアルタイム性を要求されるものである場合に現在実行中の通信処理の中でパケット数を減少させることが好ましい。
【００２０】
このような態様であれば、単純に後から開始された通信処理を優先するのではなく、通信プロファイルの特性からみて優先度の高い方の通信処理を確実に優先させることができる。
【００２１】
解決手段５：あるいは、解決手段１から３のパケット通信方法において、パケット数を相対的に増加させる工程では、別の通信プロファイルがオーディオデータ又は音声通話データをローカルデバイスで受信する場合に使用されるものであるか、もしくは、所定時間内にリモートデバイスからローカルデバイスへのデータ転送を完了させる必要がある場合に使用されるものであるかのいずれかである場合、現在実行中の通信処理の中でパケット数を減少させることが好ましい。
【００２２】
この場合も同様に、通信プロファイルの特性からみて優先度の高い方の通信処理を確実に優先させることができることに加えて、所定時間内にデータ転送を完了させる必要がある場合のように、後から意図的に優先させたい通信処理が開始されれば、そちらを確実に優先させることができる。
【００２３】
解決手段６：解決手段１から５のパケット通信方法において、ローカルデバイスとリモートデバイスとの間で行われる通信処理は、特定の短距離無線通信規格におけるＲＦＣＯＭＭプロトコルにより定義されたクレジットベースドフローコントロールに則り、ローカルデバイスが受信可能なパケット数をクレジット数としてローカルデバイスからリモートデバイスに通知する手順と、リモートデバイスからパケットデータをローカルデバイスに送信するごとにリモートデバイスにおいてクレジット数を減少させる手順とを含むものである。
【００２４】
この場合、クレジット数がリモートデバイスにおいて残存している間はリモートデバイスからローカルデバイスに対してパケットデータの送信が可能である一方、クレジット数が残存しなくなるとリモートデバイスからローカルデバイスからリモートデバイスへのパケットデータの送信が不可となる。
【００２５】
例えば、特定の短距離無線通信規格としてＢｌｕｅｔｏｏｔｈ（登録商標）を使用した場合、そのＲＦＣＯＭＭプロトコルで定義されたクレジットベースドフローコントロール（Ｃｒｅｄｉｔ Ｂａｓｅｄ Ｆｌｏｗ Ｃｏｎｔｒｏｌ）を必須機能とするため、ローカルデバイスとリモートデバイスとの間での相互接続性の観点からも有利なパケット通信方法を実現することができる。
【発明の効果】
【００２６】
以上のように本発明のパケット通信方法によれば、多様な通信プロファイルを用いた通信処理を同時に実行しつつ、より優先させたい通信処理に対して必要な帯域を確保することができる。これにより、リアルタイム性のあるデータ通信の品質劣化を防止してユーザの利便性を高めたり、意図的に優先させたいデータの転送を早期に完了させたりすることができる。
【発明を実施するための最良の形態】
【００２７】
以下、本発明の実施形態について図面を参照しながら説明する。
【００２８】
〔通信システムの概要〕
図１は、通信システム１０の構成例を概略的に示す図である。この通信システム１０は、例えば自動車に搭載された車載電装ユニット１２をローカルデバイスとし、車内に持ち込まれる各種の携帯機器１４，１６，１８をそれぞれリモートデバイスとして構成されている。これら車載電装ユニット１２や携帯機器１４，１６，１８は、いずれもブルートゥース（Ｂｌｕｅｔｏｏｔｈ：登録商標）規格に準拠した無線通信機能を有している。なお、以下の説明では、Ｂｌｕｅｔｏｏｔｈ（登録商標）を「ＢＴ」と略称する。
【００２９】
〔車載電装ユニット〕
車載電装ユニット１２は、例えば走行経路誘導（ナビゲーション）機能を有するほか、オーディオ再生機能やビデオ再生機能、ラジオ、テレビ等の受信機能等を有する。このため車載電装ユニット１２には、液晶ディプレイ等を用いた表示部２０や、図示しないプッシュスイッチ、キースイッチ、回転つまみ等を有した操作部２２が付属するほか、音響出力用のスピーカ２４、マイク２６等の周辺機器が付属している。
【００３０】
また車載電装ユニット１２は、上記の周辺機器を制御する制御部２８を内蔵するほか、ＢＴによる無線通信機能を発揮するためにＢＴモジュール３０を内蔵している。なお制御部２８は、例えば中央処理装置であるＣＰＵやＲＯＭ、ＲＡＭ等のメモリデバイスを備えたマイクロコンピュータである。またＢＴモジュール３０は、車載電装ユニット１２（制御部２８）をホストとしてＢＴ通信を用いたサービス（例えば無線接続）を提供することができる。
【００３１】
〔携帯機器〕
携帯機器１４，１６，１８は、例えば携帯音楽プレーヤ、携帯情報端末、携帯電話機等のユーザが携帯して使用することができる電子機器である。いずれにしても、携帯機器１４，１６，１８にも図示しないＢＴモジュールが内蔵されており、このＢＴモジュールを用いて携帯機器１４，１６，１８はそれぞれＢＴによる無線通信機能を発揮することができる。
【００３２】
〔通信システムの特性〕
ここで挙げている通信システム１０は、そのローカルデバイスとして単一の車載電装ユニット１２を有しているが、ローカルデバイスが通信の対象とするリモートデバイスとして、複数の携帯機器１４，１６，１８を含むことができる。したがって通信システム１０の動作としては、例えば以下の２つの状態を挙げることができる。
【００３３】
（１）マルチコネクション
この通信状態は、ローカルデバイスである車載ユニット１２が同時に複数のリモートデバイス（携帯機器１４〜１８）を対象として通信（データ受信）を行う場合である。例えば、携帯機器１４〜１８がそれぞれにＢＴ通信を行うアプリケーションを実行した場合、通信システム１０の動作はマルチコネクションとなる。
【００３４】
（２）マルチプロファイル
この通信状態は、車載ユニット１２が１台の携帯機器１４〜１８のいずれかとの間、もしくは複数台の携帯機器１４〜１８との間で複数の通信プロファイルを用いて同時に通信を行う場合である。例えば、携帯機器１８（携帯電話機）には標準の音声通話機能だけでなく、データ通信機能が付属していたり、あるいは音楽再生機能が付属していたりする。この場合、１台の携帯機器１８で複数のアプリケーションを同時並行して利用することができるため、それぞれのアプリケーションごとに通信プロファイルが異なっていれば、通信システム１０の動作はマルチプロファイルになる。
【００３５】
あるいは、携帯機器１４〜１８がそれぞれ単一の通信プロファイルを用いるアプリケーションを実行していても、上記（１）のマルチコネクション状態において、携帯機器１４〜１８ごとに異なる通信プロファイルが使用された場合、通信システム１０の動作はマルチコネクション及びマルチプロファイルとなる。
【００３６】
本実施形態では、上記のように通信システム１０の動作が複数の通信状態（特にマルチプロファイル）に変化することを踏まえ、通信システム１０内で行われる通信処理を動的にコントロールする通信方法を採用している。以下、本実施形態で採用する通信方法の詳細について説明する。
【００３７】
〔ＢＴモジュールの構成例〕
先ず、通信処理を動的にコントロールするために必要なハード構成の例について説明する。図２は、ＢＴモジュール３０のハード構成例を概略的に示すブロック図である。
【００３８】
ＢＴモジュール３０は、例えば内蔵型のＢＴアンテナ３２及びＲＦ回路３４を有しており、これらＢＴアンテナ３２及びＲＦ回路３４により他のＢＴ機器（ここでは携帯機器１４〜１８）との間でＢＴ規格による無線通信を行うことができる。
【００３９】
またＢＴモジュール３０は、ベースバンド部３６及びプロトコルスタック３８を有しており、このうちベースバンド部３６は、ＲＦ回路３４にて受信した信号をＩＦ信号に変換し、復調してパケットデータ（受信パケット）を生成する。プロトコルスタック３８は、例えばある程度の記憶容量を有したスタックレジスタであり、ここにはベースバンド部３６で生成されたパケットデータが順次蓄積（スタック）されるものとなっている。なおプロトコルスタック３８はＦＩＦＯ形式である。
【００４０】
またプロトコルスタック３８には、ＢＴモジュール３０からの送信用パケットデータ（送信フレーム）もまた順次蓄積されており、ここから取り出された送信用パケットデータは、上記のベースバンド部３６で変調され、ＲＦ回路３４及びＢＴアンテナ３２を通じて携帯機器１４〜１８に送信される。
【００４１】
ＢＴモジュール３０はデータ送信処理部４０及びデータ受信処理部４２を有しており、上記の送信用パケットデータは、データ送信処理部４０からプロトコルスタック３８に順次転送される。一方、プロトコルスタック３８に蓄積された受信済みのパケットデータは、データ受信処理部４２にて順次読み出される。
【００４２】
ＢＴモジュール３０は、データ送信処理部４０による送信処理に関して複数の通信プロファイルに対応している。具体的には、ＢＴモジュール３０はＤＵＮ／ＳＰＰデータ送信処理部４６及び他プロファイルデータ送信処理部５０を有しており、これら複数の処理部４６，５０によりマルチプロファイル機能をカバーしている。このうちＤＵＮ／ＳＰＰデータ送信処理部４６は、ダイヤルアップネットワークプロファイル及びシリアルポートプロファイルを用いたデータ送信処理を行う。また他プロファイルデータ送信処理部５０は、上記の以外のプロファイルを用いたデータ送信処理を行うものである。
【００４３】
またデータ受信処理に関して、同じくＢＴモジュール３０はＤＵＮ／ＳＰＰデータ受信処理部５２及び他プロファイルデータ受信処理部５４を有している。このうちＤＵＮ／ＳＰＰデータ受信処理部５２は、ダイヤルアップネットワークプロファイル及びシリアルポートプロファイルを用いたデータ受信処理を行う。また他プロファイルデータ受信処理部５４は、上記の以外のプロファイルを用いたデータ受信処理を行うものである。
【００４４】
〔クレジットベースドフローコントロール〕
上記のマルチプロファイルによるデータ送信処理及びデータ受信処理（通信処理）に関して、ＢＴモジュール３０は、ＲＦＣＯＭＭプロトコルで定義されている必須機能のクレジットベースドフローコントロールを使用する。このためＢＴモジュール３０はクレジット送信処理部４４を有しており、このクレジット送信処理部４４は、ローカルデバイス（車載ユニット１２）からいずれかのリモートデバイス（携帯機器１４〜１８）に対してクレジット（フリークレジット）を送信する。なお、クレジットベースドフローコントロールの例についてはさらに後述する。
【００４５】
またＢＴモジュール３０はマルチプロファイル状態検知部４８を有しており、このマルチプロファイル状態検知部４８は、マルチプロファイル動作中にＢＴモジュール３０による通信処理の状態の変化を検知する。具体的には、上記のダイヤルアップネットワークプロファイルやシリアルポートプロファイルに加えて、他のプロファイルとして例えば高度オーディオ配信プロファイル（Ａ２ＤＰ）、ハンズフリープロファイル（ＨＦＰ）等を用いて通信処理が実行されたことを検知したり、その通信処理が終了したことを検知したりする。
【００４６】
そしてマルチプロファイル状態検知部４８は、上記のようにマルチプロファイル動作中の状態の変化を検知すると、クレジット送信処理部４４が送信するクレジット数を操作し、クレジットベースドフローコントロールによる通信処理を制御するためのトリガを発生する。なお、具体的な制御手法の例についてはさらに後述する。
【００４７】
この他に、ＢＴモジュール３０はＨＯＳＴモジュール間制御部５６を有しており、このＨＯＳＴモジュール間制御部５６は、上記の車載ユニット１２が有する制御部２８をホスト（ＨＯＳＴ）としたとき、このホストとＢＴモジュール３０との間の通信を制御する。
【００４８】
例えば、ユーザが車載ユニット１２の操作部２２を通じてＢＴ通信に関する操作を実行した場合、ホスト側の制御部２８からＨＯＳＴモジュール間制御部５６に動作信号が送信され、これを受けてＨＯＳＴモジュール間制御部５６はＤＵＮ／ＳＰＰデータ送信処理部４６や他プロファイルデータ送信処理部５０の動作を制御する。またＨＯＳＴモジュール間制御部５６は、ＤＵＮ／ＳＰＰデータ受信処理部５２や他プロファイルデータ受信処理部５４により受信されたパケットデータをホスト側の制御部２８に出力する。これにより、例えば携帯機器１８からＢＴ通信で受信したオーディオデータや音声通話データ等を車載ユニット１２のスピーカ２４から出力したり、マイク２６で拾った音声を携帯機器１８に転送したりすることが可能になる。
【００４９】
〔パケット通信方法〕
次に、本実施形態の通信システム１０において使用されているパケット通信方法の一例について説明する。
【００５０】
図３は、ＢＴモジュール３０が実行する通信処理の手順例を示したフローチャートである。この受信処理は、通信システム１０内でローカルデバイスである車載ユニット１２とリモートデバイスである携帯機器１４〜１８との間でＲＦＣＯＭＭ接続が完了した後に開始される。なお、ＢＴ通信におけるＲＦＣＯＭＭ接続のシーケンスについては公知のものを適用できるので、ここではその詳細を省略する。
【００５１】
ＲＦＣＯＭＭ接続が完了すると、ＢＴモジュール３０内で上記のＨＯＳＴモジュール間制御部５６をはじめクレジット送信処理部４４、ＤＵＮ／ＳＰＰデータ送信処理部４６、他プロファイルデータ送信処理部５０、ＤＵＮ／ＳＰＰデータ受信処理部５２、他プロファイルデータ受信処理部５４等の演算処理機能を有した構成要素を用いて通信処理が実行される。
【００５２】
この通信処理は、マルチプロファイル状態検知部４８に予めトリガとなる条件を付与しておき、通信中のトリガ条件に応じてクレジット送信処理部４４によるクレジット送信処理を動的に操作し、ダイアルアップネットワークやシリアルポートを用いたアプリケーションによるデータアクセス中の受信帯域を他のアプリケーションに割り当てるものである。以下、手順例に沿って説明する。
【００５３】
ステップＳ１０：ＲＦＣＯＭＭプロトコルでのクレジットベースドフローコントロールにおいて、ＢＴモジュール３０は最初にクレジット送信処理部４４によるフリークレジットの値を「０」に設定する。
【００５４】
ステップＳ１２：次にＢＴモジュール３０は、リモートデバイスである携帯機器１４〜１８でのカレントクレジットの値をローカルデバイスにおける初期クレジットの値（例えば「７」）に設定する。
【００５５】
ステップＳ１４：ＢＴモジュール３０は、通信処理のモードとして「モード１」を設定する。
【００５６】
ステップＳ１６：次にＢＴモジュール３０は、上記のマルチプロファイル状態検知部４８により通信状態を確認する（検出工程）。
【００５７】
ステップＳ１８：そしてＢＴモジュール３０は、上記の結果からマルチプロファイル状態検知部４８においてトリガとなる条件が満たされたか否か（「コンディションＣ」の条件を満たすか否か）を判断する。例えば、以下に該当する場合を「コンディションＣ」の条件を満たすと判断することができる。
【００５８】
〔コンディションＣのトリガ条件〕
（１）ダイアルアップやシリアルポートを用いたデータアクセスと同時並行してオーディオアプリケーションの動作中に、マルチプロファイル状態検知部４８がオーディオアプリケーションの状態を「停止中」から「再生中」に遷移したことを検知した場合。オーディオアプリケーションの動作中は通信処理にリアルタイム性が要求されるため、これをトリガ条件とする。
【００５９】
（２）ダイアルアップやシリアルポートを用いたデータアクセスと同時並行してハンズフリーアプリケーションの動作中に、マルチプロファイル状態検知部４８がハンズフリーアプリケーションの状態を「ＳＬＣ接続中」から「通話中」に遷移したことを検知した場合。この場合、ＨＦＰ通話の音質やＨＦＰコントロールデータの受信処理を優先する必要があるため、これをトリガ条件とする。
【００６０】
（３）ダイアルアップやシリアルポートを用いたデータアクセスと同時並行してパーソナルインフォメーションマネージャアプリケーション(ＯＰＰ、ＰＢＡＰ)の動作中に、マルチプロファイル状態検知部４８がこれらアプリケーションの状態を「ＳＬＣ接続中」から「データ取得中」に遷移したことを検知した場合。この場合も同様にデータの受信処理を優先する必要があるため、これをトリガ条件とする。なお、パーソナルインフォメーションマネージャアプリケーション(ＯＰＰ、ＰＢＡＰ)の動作中にデータの受信処理を優先する必要があるのは、例えば携帯情報端末や携帯電話機である携帯機器１６，１８からアドレス帳等のデータを受信する際、そのデータ転送を所定時間（例えば数秒〜十数秒間）内で完了させる必要があることを考慮したものである。
【００６１】
特に上記（１）〜（３）のトリガ条件が満たされていなければ（ステップＳ１８：Ｎｏ）、ＢＴモジュール３０は次にステップＳ２０に進む。
【００６２】
ステップＳ２０：現在は「モード１」に設定されているため（Ｙｅｓ）、ＢＴモジュール３０はここでステップＳ２２を実行する。
【００６３】
ステップＳ２２：この場合、ＢＴモジュール３０は「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」を実行する。そして、この処理から復帰すると、ＢＴモジュール３０はステップＳ１６に戻ってマルチプロファイル状態検知部４８による通信状態の確認を継続する（検出工程）。
【００６４】
これに対し、上記（１）〜（３）のいずれかのトリガ条件が満たされると（ステップＳ１８：Ｙｅｓ）、ＢＴモジュール３０は次にステップＳ２４に進む。
【００６５】
ステップＳ２４：この場合、ＢＴモジュール３０は「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」を実行する。
【００６６】
ステップＳ２６：次にＢＴモジュール３０は、通信処理のモードとして「モード２」を設定する。そしてＢＴモジュール３０は、ステップＳ１６に戻り、マルチプロファイル状態検知部４８による通信状態の確認を継続する。
【００６７】
上記（１）〜（３）のいずれかのトリガ条件が満たされなくなるまでの間（ステップＳ１８：Ｙｅｓ）、ＢＴモジュール３０は引き続きステップＳ２４に進み、「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」を実行する（ステップＳ１６〜ステップＳ２６のループ）。
【００６８】
この後、上記（１）〜（３）のいずれかのトリガ条件が満たされなくなると（ステップＳ１８：Ｎｏ）、ＢＴモジュール３０はステップＳ２０に進み、現在のモードを確認する。
【００６９】
ステップＳ２０：そして、この時点では「モード２」に設定されているため（Ｎｏ）、次にステップＳ２８が実行されることになる。
【００７０】
ステップＳ２８：ＢＴモジュール３０は、「ＲＦＣＯＭＭデータ受信及びクレジット送信補正処理」を実行する。
【００７１】
〔ＲＦＣＯＭＭデータ受信及びクレジット送信処理１〕
図４は、上記のステップＳ２２で実行される「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」の手順例を示すフローチャートである。以下、この処理について説明する。
【００７２】
ステップＳ４０：ＢＴモジュール３０は、ＲＦＣＯＭＭデータ受信を開始する。
ステップＳ４２：またＢＴモジュール３０は、フリークレジットの値を「１」インクリメントする。これにより、前回のフリークレジットの値が１つ加算された状態となる。
【００７３】
ステップＳ４４：次にＢＴモジュール３０は、リモートデバイスである携帯機器１４〜１８でのカレントクレジットの値を「１」デクリメントする。これにより、前回のカレントクレジットの値が１つ減算された状態となる。
【００７４】
ステップＳ４６：ここでＢＴモジュール３０は、条件として「コンディションＡ」が満たされるか否かを判断する。なお「コンディションＡ」は、例えば以下の内容とすることができる。
【００７５】
カレントクレジット≦Ｔｈ１ かつ フリークレジット≧Ｔｈ２
ただし、ローカルデバイスの初期クレジット＝Ｔｈ１＋Ｔｈ２である。なお、上記の例では初期クレジットの値を「７」としているので、ここではＴｈ１＝１、Ｔｈ２＝６とする。
【００７６】
特に「コンディションＡ」の条件が満たされない場合（ステップＳ４６：Ｎｏ）、ＢＴモジュール３０はステップＳ４０に戻ってＲＦＣＯＭＭデータ受信を繰り返す。そして、フリークレジットの値をインクリメントし（ステップＳ４２）、代わりにカレントクレジットの値をデクリメントすると（ステップＳ４４）、再びＢＴモジュール３０は「コンディションＡ」の条件を満たすか否かを判断する。
【００７７】
このように、カレントクレジットの値がＴｈ１＝「１」以下になり、かつ、フリークレジットの値がＴｈ２＝「６」以上になるまでの間、ＢＴモジュール３０はＲＦＣＯＭＭデータ受信を繰り返す。したがってリモートデバイスは、初期クレジットの値で与えられたカレントクレジットが残存しなくなるまでの間、ローカルデバイスに対してパケットデータを送信することができる。
【００７８】
この後、カレントクレジットの値がＴｈ１以下になり、かつ、フリークレジットの値がＴｈ２以上になると、「コンディションＡ」の条件が満たされるので（ステップＳ４６：Ｙｅｓ）、ＢＴモジュール３０は次にステップＳ４８を実行する。
【００７９】
ステップＳ４８：ここでＢＴモジュール３０は、クレジットとして「フリークレジットＡ」をリモートデバイスに送信する。このときの「フリークレジットＡ」は、現在の「フリークレジット」に等しい。したがって上記の例では「６」が送信されることになる。
【００８０】
ステップＳ５０：次にＢＴモジュール３０は、フリークレジットの値を「０」にリセットする。
ステップＳ５２：そしてＢＴモジュール３０は、カレントクレジットの値＝「１」に「フリークレジットＡ」＝「６」を加算して、カレントクレジットの値を「７」に更新する。
【００８１】
このように、「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」では、以上の手順を繰り返しながら通信処理が行われる。
【００８２】
〔通信処理シーケンス〕
図５は、「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」による通信処理の流れを示すシーケンス図である。図５中、左側カラムにはローカルデバイス（ＢＴモジュール３０）による処理を示し、右側カラムにはリモートデバイス（例えば携帯機器１８）による処理を示す。なお以下の説明では、それぞれを単にローカルデバイス、リモートデバイスと一般化して呼称する。
【００８３】
ＳＴ１：シーケンス初期において、ローカルデバイスとリモートデバイスとの間でＲＦＣＯＭＭ接続が完了する。
【００８４】
ＳＴ２：ローカルデバイスのフリークレジットの値が「０」に設定される。
ＳＴ３：リモートデバイスにおいて、カレントクレジットの値はローカルデバイスの初期クレジットの値＝「７」に設定される。この値は、これからローカルデバイスが受信可能なパケット数を指定したものである。ＲＦＣＯＭＭプロトコルで規定されたクレジットベースドフローコントロールでは、リモートデバイスにおいてカレントクレジットの値が「０」になるまでの間、フレーム送信（パケットデータの送信）が可能である。
【００８５】
ＳＴ４：このためリモートデバイスは、ローカルデバイスに対してパケットデータを送信する。
【００８６】
ＳＴ５：ＲＦＣＯＭＭデータ受信を行うと、ローカルデバイスはフリークレジットの値を「１」にインクリメントする。
ＳＴ６：一方、リモートデバイスは、カレントクレジットの値を「７」から「６」にデクリメントする。
【００８７】
ＳＴ７：未だカレントクレジットが残存しているので、リモートデバイスはパケットデータをローカルデバイスに対して送信する。
【００８８】
ＳＴ８：ＲＦＣＯＭＭデータ受信を行うと、ローカルデバイスはフリークレジットの値を「２」にインクリメントする。
ＳＴ９：一方、リモートデバイスは、カレントクレジットの値を「５」にデクリメントする。
【００８９】
ＳＴ１０：未だカレントクレジットが残存しているので、リモートデバイスはパケットデータをローカルデバイスに対して送信する。
【００９０】
ＳＴ１１：以上の処理を繰り返し、ローカルデバイスのフリークレジットの値が「６」までインクリメントされる。
ＳＴ１２：このときリモートデバイスは、カレントクレジットの値が「１」までデクリメントされている。
【００９１】
ＳＴ１３：ここで上記の「コンディションＡ」の条件が満たされるので、ローカルデバイスは「フリークレジットＡ」をリモートデバイスに送信する。
ＳＴ１４：そしてローカルデバイスは、フリークレジットの値を「０」にリセットする。
【００９２】
ＳＴ１５：リモートデバイスは、カレントクレジットに「フリークレジットＡ」を加算し、カレントクレジットの値を「７」に更新する。
【００９３】
ＳＴ１６：「コンディションＡ」の条件は満たされなくなり、カレントクレジットが残存しているので、リモートデバイスはパケットデータをローカルデバイスに対して送信することができる。
【００９４】
ＳＴ１７：ＲＦＣＯＭＭデータ受信を行うと、ローカルデバイスはフリークレジットの値を「１」にインクリメントする。
ＳＴ１８：一方、リモートデバイスは、カレントクレジットの値を「７」から「６」にデクリメントする。
【００９５】
ＳＴ１９：未だカレントクレジットが残存しているので、リモートデバイスはパケットデータをローカルデバイスに対して送信する。
【００９６】
ＳＴ２０：ＲＦＣＯＭＭデータ受信を行うと、ローカルデバイスはフリークレジットの値を「２」にインクリメントする。
ＳＴ２１：一方、リモートデバイスは、カレントクレジットの値を「５」にデクリメントする。
【００９７】
ＳＴ２２：未だカレントクレジットが残存しているので、リモートデバイスはパケットデータをローカルデバイスに対して送信する。
【００９８】
ＳＴ２３：ＲＦＣＯＭＭデータ受信を行うと、ローカルデバイスはフリークレジットの値を「３」にインクリメントする。
ＳＴ２４：一方、リモートデバイスは、カレントクレジットの値を「４」にデクリメントする。
【００９９】
以下、所望量のデータ転送が完了するまでの間、同様にして通信処理のシーケンスが実行される。ＢＴモジュール３０は、図４の「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」の実行中、例えばタイマ割り込みを発生させて所望量のデータ転送が完了したか否かを確認している。いずれかの割り込み周期でデータ転送が完了していれば、ＢＴモジュール３０は「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」を抜けて図３の通信処理に復帰する。
【０１００】
以上の通信処理シーケンスは、マルチプロファイル状態検知部４８においてトリガ条件が満たされる前の内容であるが、トリガ条件が満たされた場合は以下の処理が実行される。
【０１０１】
〔ＲＦＣＯＭＭデータ受信及びクレジット送信処理２〕
図６は、上記のステップＳ２４で実行される「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」の手順例を示すフローチャートである。以下、この処理について説明する。
【０１０２】
ステップＳ６０：ＢＴモジュール３０は、ダイヤルアップやシリアルポートのデータアクセスに関する通信処理中に待機時間（例えば５００ｍｓｅｃ）を挿入して待機する（待機工程）。
【０１０３】
ステップＳ６２：待機時間が経過すると、ＢＴモジュール３０はＲＦＣＯＭＭデータ受信を開始する。
ステップＳ６４：またＢＴモジュール３０は、フリークレジットの値を「１」インクリメントする。これにより、前回のフリークレジットの値が１つ加算された状態となる。
【０１０４】
ステップＳ６６：次にＢＴモジュール３０は、リモートデバイスである携帯機器１４〜１８でのカレントクレジットの値を「１」デクリメントする。これにより、前回のカレントクレジットの値が１つ減算された状態となる。
【０１０５】
ステップＳ６８：ここでＢＴモジュール３０は、条件として「コンディションＢ」が満たされるか否かを判断する。ここでいう「コンディションＢ」は、例えば以下の内容とすることができる。
【０１０６】
カレントクレジット≦Ｔｈ３ かつ フリークレジット≧Ｔｈ４
ただし、Ｔｈ３はＴｈ１より小さく、またＴｈ４はＴｈ２より小さい値とする。ここでは例えば、Ｔｈ３＝０、Ｔｈ４＝１とする。
【０１０７】
特に「コンディションＢ」の条件が満たされない場合（ステップＳ６８：Ｎｏ）、ＢＴモジュール３０はステップＳ６０に戻って待機時間だけ待機した後、ステップＳ６２に進んでＲＦＣＯＭＭデータ受信を繰り返す。そして、フリークレジットの値をインクリメントし（ステップＳ６４）、代わりにカレントクレジットの値をデクリメントすると（ステップＳ６６）、再びＢＴモジュール３０は「コンディションＢ」の条件を満たすか否かを判断する。
【０１０８】
このように、カレントクレジットの値がＴｈ３＝「０」以下になり、かつ、フリークレジットの値がＴｈ４＝「１」以上になるまでの間、ＢＴモジュール３０はＲＦＣＯＭＭデータ受信を繰り返す。したがってリモートデバイスは、初期クレジットの値で与えられたカレントクレジットが残存しなくなるまでの間、ローカルデバイスに対してパケットデータを送信することができる。
【０１０９】
この後、カレントクレジットの値がＴｈ３以下（＝０）になり、かつ、フリークレジットの値がＴｈ４以上（＝１）になると、「コンディションＢ」の条件が満たされるので（ステップＳ６８：Ｙｅｓ）、ＢＴモジュール３０は次にステップＳ７０を実行する。
【０１１０】
ステップＳ７０：ここでＢＴモジュール３０は、クレジットとして「フリークレジットＢ」をリモートデバイスに送信する。このときの「フリークレジットＢ」は、Ｔｈ４＝「１」と同値である。したがって上記の例では「１」が送信されることになる。
【０１１１】
ステップＳ７２：次にＢＴモジュール３０は、フリークレジットの値を「０」にリセットする。
ステップＳ７４：そしてＢＴモジュール３０は、カレントクレジットの値＝「０」に「フリークレジットＢ」＝「１」を加算して、カレントクレジットの値を「１」に更新する。
【０１１２】
次にＢＴモジュール３０がステップＳ６２でＲＦＣＯＭＭデータ受信を行うと、ステップＳ６４でフリークレジットの値が「１」となるが、ステップＳ６６でカレントクレジットの値は１度のＲＦＣＯＭＭデータ受信で「０」になる。このためリモートデバイスは、ローカルデバイスに対してパケットデータを送信することができなくなり、ステップＳ７０〜ステップＳ７４を経てステップＳ６０に戻ることになる。そして、ステップＳ６０で待機時間を待機し、次のＲＦＣＯＭＭデータ受信を行う。
【０１１３】
このように、「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」では、以上の手順を繰り返しながら通信処理が行われるが、この間、カレントクレジットの値は最大で「１」にしかならないので、ローカルデバイスが受信可能なパケット数が減少する（減少工程）。また、ＲＦＣＯＭＭデータ受信を１度行うごとに待機時間が挿入されるため、それだけ通信処理にかかる時間が遅延する（待機工程）。
【０１１４】
〔通信処理シーケンス〕
図７は、「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」による通信処理の流れを示すシーケンス図である。
【０１１５】
ＳＴ５０：シーケンス初期において、ローカルデバイスとリモートデバイスとの間でＲＦＣＯＭＭ接続が完了する。
【０１１６】
ＳＴ５１：ローカルデバイスのフリークレジットの値が「０」に設定される。
ＳＴ５２：リモートデバイスにおいて、カレントクレジットの値はローカルデバイスの初期クレジットの値＝「７」に設定される。この値は、上記と同様にこれからローカルデバイスが受信可能なパケット数を指定したものである。
【０１１７】
ＳＴ５３：リモートデバイスは、ローカルデバイスに対してパケットデータを送信する。
【０１１８】
ＳＴ５４：ＲＦＣＯＭＭデータ受信を行うと、ローカルデバイスはフリークレジットの値を「１」にインクリメントする。
ＳＴ５５：一方、リモートデバイスは、カレントクレジットの値を「７」から「６」にデクリメントする。
【０１１９】
ＳＴ５６：未だカレントクレジットが残存しているので、リモートデバイスはパケットデータをローカルデバイスに対して送信する。
【０１２０】
ＳＴ５７：ＲＦＣＯＭＭデータ受信を行うと、ローカルデバイスはフリークレジットの値を「２」にインクリメントする。
ＳＴ５８：一方、リモートデバイスは、カレントクレジットの値を「５」にデクリメントする。
【０１２１】
ＳＴ５９：未だカレントクレジットが残存しているので、リモートデバイスはパケットデータをローカルデバイスに対して送信する。
【０１２２】
ＳＴ６０：以上の処理を繰り返し、ローカルデバイスのフリークレジットの値が「７」までインクリメントされる。
ＳＴ６１：このときリモートデバイスは、カレントクレジットの値が「０」までデクリメントされている。したがって、リモートデバイスはこれ以上、パケットデータを送信することができない。
【０１２３】
ＳＴ６２：ここでローカルデバイスは、設定した待機時間を待機する。
ＳＴ６３：上記の「コンディションＢ」の条件が満たされるので、ローカルデバイスは「フリークレジットＢ」をリモートデバイスに送信する。
ＳＴ６４：そしてローカルデバイスは、フリークレジットの値を「０」にリセットする。
【０１２４】
ＳＴ６５：リモートデバイスは、カレントクレジットに「フリークレジットＢ」を加算し、カレントクレジットの値を「１」に更新する。
【０１２５】
ＳＴ６６：「コンディションＢ」の条件は満たされなくなり、カレントクレジットが残存しているので、リモートデバイスはパケットデータをローカルデバイスに対して送信することができる。
【０１２６】
ＳＴ６７：ＲＦＣＯＭＭデータ受信を行うと、ローカルデバイスはフリークレジットの値を「１」にインクリメントする。
ＳＴ６８：一方、リモートデバイスは、カレントクレジットの値を「１」から「０」にデクリメントする。これにより、リモートデバイスはこれ以上、パケットデータを送信することができなくなる。
【０１２７】
ＳＴ６９：ここでローカルデバイスは、また設定した待機時間を待機する。
ＳＴ７０：上記の「コンディションＢ」の条件が満たされるので、ローカルデバイスは「フリークレジットＢ」をリモートデバイスに送信する。
【０１２８】
ＳＴ７１：そしてローカルデバイスは、フリークレジットの値を「０」にリセットする。
ＳＴ７２：リモートデバイスは、カレントクレジットに「フリークレジットＢ」を加算し、カレントクレジットの値を「１」に更新する。これにより、リモートデバイスは１パケット分だけデータを送信することが可能になる。
【０１２９】
以下、所望量のデータ転送が完了するまでの間、同様にして通信処理のシーケンスが実行される。ＢＴモジュール３０は、図６の「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」の実行中、例えばタイマ割り込みを発生させて所望量のデータ転送が完了したか否かを確認している。いずれかの割り込み周期でデータ転送が完了していれば、ＢＴモジュール３０は「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」を抜けて図３の通信処理に復帰する。
【０１３０】
ただし、「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」の実行中は１回のＲＦＣＯＭＭデータ受信ごとに待機時間が挿入されるので、相対的に別の通信プロファイルを用いた通信処理に割り当てられる時間が長くなる。また、１回のＲＦＣＯＭＭデータ受信が可能なパケット数が減少するため、別の通信プロファイルを用いた通信処理（特に図示していない）について相対的にパケット数が増加し、それだけデータ受信帯域が広げられることとなる。
【０１３１】
〔ＲＦＣＯＭＭデータ受信及びクレジット送信補正処理〕
次に図８は、「ＲＦＣＯＭＭデータ受信及びクレジット送信補正処理」の手順例を示すフローチャートである。この処理は、図３の通信処理において「コンディションＣ」のトリガ条件が満たされた後、この条件が満たされなくなった場合に実行される。
【０１３２】
ステップＳ８０：ここでもＢＴモジュール３０は、ＲＦＣＯＭＭデータ受信を実行する。
ステップＳ８２：またＢＴモジュール３０は、フリークレジットの値を「１」インクリメントする。これにより、前回のフリークレジットの値が１つ加算された状態となる。
【０１３３】
ステップＳ８４：次にＢＴモジュール３０は、リモートデバイスでのカレントクレジットの値を「１」デクリメントする。
【０１３４】
ステップＳ８６：ここでＢＴモジュール３０は、条件として「コンディションＤ」が満たされるか否かを判断する。なお「コンディションＤ」は、例えば以下の内容とすることができる。
【０１３５】
カレントクレジット＝「０」
【０１３６】
特に「コンディションＤ」の条件（つまりカレントクレジット＝０）が満たされない場合（ステップＳ８６：Ｎｏ）、ＢＴモジュール３０はステップＳ８０に戻ってＲＦＣＯＭＭデータ受信を繰り返す。そして、フリークレジットの値をインクリメントし（ステップＳ８２）、代わりにカレントクレジットの値をデクリメントすると（ステップＳ８４）、再びＢＴモジュール３０は「コンディションＤ」の条件を満たすか否かを判断する。
【０１３７】
このように、カレントクレジットの値が「０」になるまでの間、ＢＴモジュール３０はＲＦＣＯＭＭデータ受信を繰り返す。したがってリモートデバイスは、初期クレジットの値で与えられたカレントクレジットが残存しなくなるまでの間、ローカルデバイスに対してパケットデータを送信することができる。
【０１３８】
この後、カレントクレジットの値が「０」になると、「コンディションＤ」の条件が満たされるので（ステップＳ８６：Ｙｅｓ）、ＢＴモジュール３０は次にステップＳ８８を実行する。
【０１３９】
ステップＳ８８：ここでＢＴモジュール３０は、クレジットとして「フリークレジットＤ」をリモートデバイスに送信する。このときの「フリークレジットＤ」は、ローカルデバイスの初期クレジットに等しい。したがって上記の例では「７」が送信されることになる。
【０１４０】
ステップＳ９０：次にＢＴモジュール３０は、フリークレジットの値を「０」にリセットする。
ステップＳ９２：そしてＢＴモジュール３０は、カレントクレジットの値＝「０」に「フリークレジットＤ」＝「７」を加算して、カレントクレジットの値を「７」に更新する。
【０１４１】
ステップＳ９４：ＢＴモジュール３０は「モード１」を設定し、図３の通信処理に復帰する。
【０１４２】
この後、「モード１」が設定されているので、次にトリガ条件が満たされるまでの間（図３のステップＳ１８：Ｎｏ、ステップＳ２０：Ｙｅｓ）、「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」が実行されることになる。
【０１４３】
以上のように本実施形態では、マルチプロファイル状態検知部４８にトリガとなる条件を付与し、通信状態が変化するごとに「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」と「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」とを動的に切り替えることにより、ダイアルアップやシリアルポートを用いたアプリケーションによるデータアクセス中の受信帯域を他のアプリケーションに割り当てることが可能となる。
【０１４４】
また、「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」の実行中にマルチプロファイル状態検知部４８がオーディオアプリケーションの状態を「再生中」から「停止中」に遷移したことを検知した場合、あるいは、「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」の実行中にマルチプロファイル状態検知部４８がハンズフリーアプリケーションの状態を「通話中」から「ＳＬＣ接続中」に遷移したことを検知した場合、図８の「補正処理」を経て「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」に切り替え、できるだけデータ受信のスループットを優先することができる。
【０１４５】
〔製品市場での有用性〕
特に近年のＢＴ通信のユーザーシナリオにおいては、マルチコネクションやマルチプロファイルでの動作及び品質の向上が製品市場から求められている。その中で個々のプロファイル(アプリケーション)によっては、音声通話やオーディオ伝送等、リアルタイム性や音質を厳しく問われる要素と、ダイアルアップ（ＤＵＮ／ＳＰＰ）のように、ベストエフォート型データ通信の要素に大別することができるが、これらを最大限に共存させるため、送信／受信帯域の制御が課題となっている。
【０１４６】
本実施形態の通信方法では、リアルタイム性や品質が求められる要素とベストエフォート型データ通信の要素が同時並行して通信を実行中に、前者が通話中又はオーディオ再生中の状態になったことを検出した場合、後者の要素に関してクレジット数及びその送信条件、送信方法を適応的に変更することができ、それにより受信可能なパケット数を制限し、結果として後者の要素に関して受信帯域を相対的に減少させ、逆に前者のリアルタイム性及び音質を可能な限り改善する効果がある。
【０１４７】
また、前者の通信において終話又はオーディオ停止の状態を検出した場合、本来の通信処理に復帰させることによって受信帯域を可能な限り増加させ、データ受信のスループットを確保することができる。
【０１４８】
本発明は上述した実施形態に制約されることなく、各種の変形を伴って実施することができる。一実施形態で挙げたＢＴモジュール３０の構成はあくまで機能的なブロック要素の例示であり、これらの機能をマイクロコンピュータ（ＣＰＵ）のリソースで全て賄い、それぞれの機能をアプリケーションで実現してもよい。
【０１４９】
また、一実施形態では通信処理を優先するものとしてオーディオデータや音声通話データ等を例に挙げているが、映像データを転送する際にも本発明の通信方法を適用することができる。
【図面の簡単な説明】
【０１５０】
【図１】通信システムの構成例を概略的に示す図である。
【図２】ＢＴモジュールのハード構成例を概略的に示すブロック図である。
【図３】ＢＴモジュール３０が実行する通信処理の手順例を示したフローチャートである。
【図４】「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」の手順例を示すフローチャートである。
【図５】「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」による通信処理の流れを示すシーケンス図である。
【図６】「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」の手順例を示すフローチャートである。
【図７】「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」による通信処理の流れを示すシーケンス図である。
【図８】「ＲＦＣＯＭＭデータ受信及びクレジット送信補正処理」の手順例を示すフローチャートである。
【符号の説明】
【０１５１】
１０ 通信システム
１２ 車載ユニット
１４，１６，１８ 携帯機器
３０ ＢＴモジュール
４４ クレジット送信処理部
４６ ＤＵＮ／ＳＰＰデータ送信処理部
４８ マルチプロファイル状態検知部
５０ 他プロファイルデータ送信処理部
５２ ＤＵＮ／ＳＰＰデータ受信処理部
５４ 他プロファイルデータ受信処理部
【技術分野】
【０００１】
本発明は、複数のデバイス間でパケットデータを送受信するためのパケット通信方法に関するものである。
【背景技術】
【０００２】
従来、オーディオ信号や映像信号のように連続性があり、かつ、リアルタイム性を確保する必要があるデータの送受信に適した無線通信方法が知られている（例えば、特許文献１参照。）。この先行技術は、通信装置が他のデバイスとの間でデータ通信を行う際、通信対象として複数のデバイスが検出された場合にリアルタイム性が要求されるデバイスとそれ以外のデバイスとを区別して認識しておき、先にリアルタイム性が要求されない方のデバイスとの通信を確立し、その後でリアルタイム性が要求されるデバイスとの間でオーディオ信号の伝送を行うものである。また先行技術では、通信装置においてリアルタイム性が要求されるデバイスとの間でデータ伝送が行われている間、その他のデバイスの検出や既に通信を確立したデバイスとの通信を行わないこととしている。
【０００３】
上記の先行技術によれば、例えばオーディオ機器から通信機器に対してオーディオ信号等の伝送が行われている間、それ以外のデバイスである携帯電話機との通信は原則として行われない。この場合、例えば１曲分のオーディオ信号の伝送が終了するまでの間はオーディオ機器との通信が優先されるため、リアルタイム性を失うことなくオーディオの再生が可能になると考えられる。
【０００４】
さらに先行技術では、オーディオデータの再生及び転送を優先している間であっても、例えば携帯電話機に着信があると、割り込み処理によって携帯電話機との通信を実行することができる。このため、通常はリアルタイム性を優先しつつ、通話等の急を要する状況が発生した場合はそちらに通信を切り替えることができるので、ユーザの要望に応じた態様で通信を実行することができると考えられる。
【特許文献１】特開２００６−３５２７９９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら上記の先行技術は、リアルタイム性が要求されるデバイスを優先するあまり、それ以外のデバイスとの通信を大きく犠牲にしている。このため先行技術の通信方法は、ユーザにとってあまり利便性が高いとはいえない。例えば、複数のデバイスを同時並行してユーザが使用しようとしても、先行技術の手法ではリアルタイム性が要求されるデータの伝送が終了するまで他のデバイスは使用できなくなるという不便さがある。
【０００６】
そうかといって、複数のデバイスから同時並行してデータの伝送を行うことを単純に許可しただけでは、リアルタイム性を要求されるデータの受信帯域が圧迫されてしまい、オーディオ等を再生する際の品質を劣化させてしまうことになる。
【０００７】
また近年、Ｂｌｕｅｔｏｏｔｈ（登録商標）対応製品の多様化により、１つの通信システム内で複数のデバイスが別々のアプリケーションを同時に実行するというケースが増えつつある。例えば、ダイアルアップやシリアルポートを用いたアプリケーションによるデータアクセス中に、これとは別のオーディオアプリケーションによる音楽の再生が開始されたり、さらに別のハンズフリーアプリケーションによる音声通話が開始されたりすることがある。このような場合、いずれの通信も中断させることなく、その中でオーディオ再生の音質を優先したり、音声通話の音質を優先したりすることへの要望が高まってきている。
【０００８】
そこで本発明は上記の事情に鑑み、同時に多様な通信状態を許容しつつ、その中でも優先度の高いデータに対して充分な受信帯域を確保することができるパケット通信方法を提供しようとするものである。
【課題を解決するための手段】
【０００９】
解決手段１：本発明は、複数の通信プロファイルを用いて通信する機能を有したローカルデバイス及びリモートデバイスから構成される通信システム内で使用されるパケット通信方法である。詳細には、ローカルデバイスとリモートデバイスとの通信開始時に予めローカルデバイスが受信可能なパケット数をリモートデバイスに通知し、この通知されたパケット数分のデータをリモートデバイスからローカルデバイスに送信してローカルデバイスで受信する通信処理を繰り返しながら所望量のパケットデータを送受信するパケット通信方法である。その上で本発明のパケット通信方法は、以下の工程に特徴を有するものである。
【００１０】
（１）検出工程
この工程は、ローカルデバイスがいずれかのリモートデバイスとの間で通信処理を実行する際、複数ある通信プロファイルの中でいずれの通信プロファイルを用いて通信処理が実行されているかを検出するものである。
【００１１】
すなわち通信プロファイルは、それ自身が使用する通信プロトコルを特定しているため、通信処理で用いられている通信プロファイルを検出することで、その通信処理がどのような通信状態にあるのかを識別することができる。
【００１２】
（２）減少工程
この工程は、ローカルデバイスが特定のリモートデバイスとの間で通信処理を実行中に、同じ特定のリモートデバイスか、もしくは別のリモートデバイスとの間で現在とは異なる別の通信プロファイルを用いて別の通信処理が実行されたことを検出した場合、現在実行中の通信処理の中でローカルデバイスが特定のリモートデバイスに通知する受信可能なパケット数を減少させることにより、別の通信プロファイルを用いた通信処理の中でローカルデバイスが受信可能なパケット数を相対的に増加させるものである。
【００１３】
これにより、現在実行中の通信処理はパケット数の減少によって相対的に帯域が狭められるが、その一方で別の通信プロファイルを用いた通信処理に割くことができる帯域を相対的に広げることができる。このため、意図的に優先させたい通信処理のスループットをそれだけ多くしつつ、いずれの通信処理も犠牲にすることなく同時並行して通信システム内でのデータ通信を継続することができる。
【００１４】
解決手段２：解決手段１のパケット通信方法において、さらに以下の工程を有してもよい。
【００１５】
（３）待機工程
この工程は、ローカルデバイスが特定のリモートデバイスとの間で通信処理を実行中に、同じ特定のリモートデバイスか、もしくは別のリモートデバイスとの間で現在とは異なる別の通信プロファイルを用いて別の通信処理が実行されたことを検出した場合、現在実行中の通信処理の中に待機時間を挿入するものである。
【００１６】
このような工程を追加することにより、上記（２）の減少工程による帯域の確保と合わせて、より優先させたい通信処理に対して必要な帯域を割り当てることができる。
【００１７】
解決手段３：解決手段２において、待機時間を挿入する工程では、現在実行中の通信処理の中でローカルデバイスが特定のリモートデバイスに受信可能なパケット数を通知する前に待機時間を挿入することが好ましい。
【００１８】
上記のように本パケット通信方法では、ローカルデバイスから受信可能なパケット数を通知するまでは、リモートデバイスからローカルデバイスに対してデータを送信することができない。したがって、ローカルデバイスからリモートデバイスへ受信可能なパケット数を通知する前に待機時間を挿入すれば、それだけ現在の通信処理に遅延が発生するため、相対的に別の通信処理の優先度を高めることができる。
【００１９】
解決手段４：解決手段１から３のパケット通信方法において、パケット数を相対的に増加させる工程では、現在の通信プロファイルに比較して別の通信プロファイルの方がよりリアルタイム性を要求されるものである場合に現在実行中の通信処理の中でパケット数を減少させることが好ましい。
【００２０】
このような態様であれば、単純に後から開始された通信処理を優先するのではなく、通信プロファイルの特性からみて優先度の高い方の通信処理を確実に優先させることができる。
【００２１】
解決手段５：あるいは、解決手段１から３のパケット通信方法において、パケット数を相対的に増加させる工程では、別の通信プロファイルがオーディオデータ又は音声通話データをローカルデバイスで受信する場合に使用されるものであるか、もしくは、所定時間内にリモートデバイスからローカルデバイスへのデータ転送を完了させる必要がある場合に使用されるものであるかのいずれかである場合、現在実行中の通信処理の中でパケット数を減少させることが好ましい。
【００２２】
この場合も同様に、通信プロファイルの特性からみて優先度の高い方の通信処理を確実に優先させることができることに加えて、所定時間内にデータ転送を完了させる必要がある場合のように、後から意図的に優先させたい通信処理が開始されれば、そちらを確実に優先させることができる。
【００２３】
解決手段６：解決手段１から５のパケット通信方法において、ローカルデバイスとリモートデバイスとの間で行われる通信処理は、特定の短距離無線通信規格におけるＲＦＣＯＭＭプロトコルにより定義されたクレジットベースドフローコントロールに則り、ローカルデバイスが受信可能なパケット数をクレジット数としてローカルデバイスからリモートデバイスに通知する手順と、リモートデバイスからパケットデータをローカルデバイスに送信するごとにリモートデバイスにおいてクレジット数を減少させる手順とを含むものである。
【００２４】
この場合、クレジット数がリモートデバイスにおいて残存している間はリモートデバイスからローカルデバイスに対してパケットデータの送信が可能である一方、クレジット数が残存しなくなるとリモートデバイスからローカルデバイスからリモートデバイスへのパケットデータの送信が不可となる。
【００２５】
例えば、特定の短距離無線通信規格としてＢｌｕｅｔｏｏｔｈ（登録商標）を使用した場合、そのＲＦＣＯＭＭプロトコルで定義されたクレジットベースドフローコントロール（Ｃｒｅｄｉｔ Ｂａｓｅｄ Ｆｌｏｗ Ｃｏｎｔｒｏｌ）を必須機能とするため、ローカルデバイスとリモートデバイスとの間での相互接続性の観点からも有利なパケット通信方法を実現することができる。
【発明の効果】
【００２６】
以上のように本発明のパケット通信方法によれば、多様な通信プロファイルを用いた通信処理を同時に実行しつつ、より優先させたい通信処理に対して必要な帯域を確保することができる。これにより、リアルタイム性のあるデータ通信の品質劣化を防止してユーザの利便性を高めたり、意図的に優先させたいデータの転送を早期に完了させたりすることができる。
【発明を実施するための最良の形態】
【００２７】
以下、本発明の実施形態について図面を参照しながら説明する。
【００２８】
〔通信システムの概要〕
図１は、通信システム１０の構成例を概略的に示す図である。この通信システム１０は、例えば自動車に搭載された車載電装ユニット１２をローカルデバイスとし、車内に持ち込まれる各種の携帯機器１４，１６，１８をそれぞれリモートデバイスとして構成されている。これら車載電装ユニット１２や携帯機器１４，１６，１８は、いずれもブルートゥース（Ｂｌｕｅｔｏｏｔｈ：登録商標）規格に準拠した無線通信機能を有している。なお、以下の説明では、Ｂｌｕｅｔｏｏｔｈ（登録商標）を「ＢＴ」と略称する。
【００２９】
〔車載電装ユニット〕
車載電装ユニット１２は、例えば走行経路誘導（ナビゲーション）機能を有するほか、オーディオ再生機能やビデオ再生機能、ラジオ、テレビ等の受信機能等を有する。このため車載電装ユニット１２には、液晶ディプレイ等を用いた表示部２０や、図示しないプッシュスイッチ、キースイッチ、回転つまみ等を有した操作部２２が付属するほか、音響出力用のスピーカ２４、マイク２６等の周辺機器が付属している。
【００３０】
また車載電装ユニット１２は、上記の周辺機器を制御する制御部２８を内蔵するほか、ＢＴによる無線通信機能を発揮するためにＢＴモジュール３０を内蔵している。なお制御部２８は、例えば中央処理装置であるＣＰＵやＲＯＭ、ＲＡＭ等のメモリデバイスを備えたマイクロコンピュータである。またＢＴモジュール３０は、車載電装ユニット１２（制御部２８）をホストとしてＢＴ通信を用いたサービス（例えば無線接続）を提供することができる。
【００３１】
〔携帯機器〕
携帯機器１４，１６，１８は、例えば携帯音楽プレーヤ、携帯情報端末、携帯電話機等のユーザが携帯して使用することができる電子機器である。いずれにしても、携帯機器１４，１６，１８にも図示しないＢＴモジュールが内蔵されており、このＢＴモジュールを用いて携帯機器１４，１６，１８はそれぞれＢＴによる無線通信機能を発揮することができる。
【００３２】
〔通信システムの特性〕
ここで挙げている通信システム１０は、そのローカルデバイスとして単一の車載電装ユニット１２を有しているが、ローカルデバイスが通信の対象とするリモートデバイスとして、複数の携帯機器１４，１６，１８を含むことができる。したがって通信システム１０の動作としては、例えば以下の２つの状態を挙げることができる。
【００３３】
（１）マルチコネクション
この通信状態は、ローカルデバイスである車載ユニット１２が同時に複数のリモートデバイス（携帯機器１４〜１８）を対象として通信（データ受信）を行う場合である。例えば、携帯機器１４〜１８がそれぞれにＢＴ通信を行うアプリケーションを実行した場合、通信システム１０の動作はマルチコネクションとなる。
【００３４】
（２）マルチプロファイル
この通信状態は、車載ユニット１２が１台の携帯機器１４〜１８のいずれかとの間、もしくは複数台の携帯機器１４〜１８との間で複数の通信プロファイルを用いて同時に通信を行う場合である。例えば、携帯機器１８（携帯電話機）には標準の音声通話機能だけでなく、データ通信機能が付属していたり、あるいは音楽再生機能が付属していたりする。この場合、１台の携帯機器１８で複数のアプリケーションを同時並行して利用することができるため、それぞれのアプリケーションごとに通信プロファイルが異なっていれば、通信システム１０の動作はマルチプロファイルになる。
【００３５】
あるいは、携帯機器１４〜１８がそれぞれ単一の通信プロファイルを用いるアプリケーションを実行していても、上記（１）のマルチコネクション状態において、携帯機器１４〜１８ごとに異なる通信プロファイルが使用された場合、通信システム１０の動作はマルチコネクション及びマルチプロファイルとなる。
【００３６】
本実施形態では、上記のように通信システム１０の動作が複数の通信状態（特にマルチプロファイル）に変化することを踏まえ、通信システム１０内で行われる通信処理を動的にコントロールする通信方法を採用している。以下、本実施形態で採用する通信方法の詳細について説明する。
【００３７】
〔ＢＴモジュールの構成例〕
先ず、通信処理を動的にコントロールするために必要なハード構成の例について説明する。図２は、ＢＴモジュール３０のハード構成例を概略的に示すブロック図である。
【００３８】
ＢＴモジュール３０は、例えば内蔵型のＢＴアンテナ３２及びＲＦ回路３４を有しており、これらＢＴアンテナ３２及びＲＦ回路３４により他のＢＴ機器（ここでは携帯機器１４〜１８）との間でＢＴ規格による無線通信を行うことができる。
【００３９】
またＢＴモジュール３０は、ベースバンド部３６及びプロトコルスタック３８を有しており、このうちベースバンド部３６は、ＲＦ回路３４にて受信した信号をＩＦ信号に変換し、復調してパケットデータ（受信パケット）を生成する。プロトコルスタック３８は、例えばある程度の記憶容量を有したスタックレジスタであり、ここにはベースバンド部３６で生成されたパケットデータが順次蓄積（スタック）されるものとなっている。なおプロトコルスタック３８はＦＩＦＯ形式である。
【００４０】
またプロトコルスタック３８には、ＢＴモジュール３０からの送信用パケットデータ（送信フレーム）もまた順次蓄積されており、ここから取り出された送信用パケットデータは、上記のベースバンド部３６で変調され、ＲＦ回路３４及びＢＴアンテナ３２を通じて携帯機器１４〜１８に送信される。
【００４１】
ＢＴモジュール３０はデータ送信処理部４０及びデータ受信処理部４２を有しており、上記の送信用パケットデータは、データ送信処理部４０からプロトコルスタック３８に順次転送される。一方、プロトコルスタック３８に蓄積された受信済みのパケットデータは、データ受信処理部４２にて順次読み出される。
【００４２】
ＢＴモジュール３０は、データ送信処理部４０による送信処理に関して複数の通信プロファイルに対応している。具体的には、ＢＴモジュール３０はＤＵＮ／ＳＰＰデータ送信処理部４６及び他プロファイルデータ送信処理部５０を有しており、これら複数の処理部４６，５０によりマルチプロファイル機能をカバーしている。このうちＤＵＮ／ＳＰＰデータ送信処理部４６は、ダイヤルアップネットワークプロファイル及びシリアルポートプロファイルを用いたデータ送信処理を行う。また他プロファイルデータ送信処理部５０は、上記の以外のプロファイルを用いたデータ送信処理を行うものである。
【００４３】
またデータ受信処理に関して、同じくＢＴモジュール３０はＤＵＮ／ＳＰＰデータ受信処理部５２及び他プロファイルデータ受信処理部５４を有している。このうちＤＵＮ／ＳＰＰデータ受信処理部５２は、ダイヤルアップネットワークプロファイル及びシリアルポートプロファイルを用いたデータ受信処理を行う。また他プロファイルデータ受信処理部５４は、上記の以外のプロファイルを用いたデータ受信処理を行うものである。
【００４４】
〔クレジットベースドフローコントロール〕
上記のマルチプロファイルによるデータ送信処理及びデータ受信処理（通信処理）に関して、ＢＴモジュール３０は、ＲＦＣＯＭＭプロトコルで定義されている必須機能のクレジットベースドフローコントロールを使用する。このためＢＴモジュール３０はクレジット送信処理部４４を有しており、このクレジット送信処理部４４は、ローカルデバイス（車載ユニット１２）からいずれかのリモートデバイス（携帯機器１４〜１８）に対してクレジット（フリークレジット）を送信する。なお、クレジットベースドフローコントロールの例についてはさらに後述する。
【００４５】
またＢＴモジュール３０はマルチプロファイル状態検知部４８を有しており、このマルチプロファイル状態検知部４８は、マルチプロファイル動作中にＢＴモジュール３０による通信処理の状態の変化を検知する。具体的には、上記のダイヤルアップネットワークプロファイルやシリアルポートプロファイルに加えて、他のプロファイルとして例えば高度オーディオ配信プロファイル（Ａ２ＤＰ）、ハンズフリープロファイル（ＨＦＰ）等を用いて通信処理が実行されたことを検知したり、その通信処理が終了したことを検知したりする。
【００４６】
そしてマルチプロファイル状態検知部４８は、上記のようにマルチプロファイル動作中の状態の変化を検知すると、クレジット送信処理部４４が送信するクレジット数を操作し、クレジットベースドフローコントロールによる通信処理を制御するためのトリガを発生する。なお、具体的な制御手法の例についてはさらに後述する。
【００４７】
この他に、ＢＴモジュール３０はＨＯＳＴモジュール間制御部５６を有しており、このＨＯＳＴモジュール間制御部５６は、上記の車載ユニット１２が有する制御部２８をホスト（ＨＯＳＴ）としたとき、このホストとＢＴモジュール３０との間の通信を制御する。
【００４８】
例えば、ユーザが車載ユニット１２の操作部２２を通じてＢＴ通信に関する操作を実行した場合、ホスト側の制御部２８からＨＯＳＴモジュール間制御部５６に動作信号が送信され、これを受けてＨＯＳＴモジュール間制御部５６はＤＵＮ／ＳＰＰデータ送信処理部４６や他プロファイルデータ送信処理部５０の動作を制御する。またＨＯＳＴモジュール間制御部５６は、ＤＵＮ／ＳＰＰデータ受信処理部５２や他プロファイルデータ受信処理部５４により受信されたパケットデータをホスト側の制御部２８に出力する。これにより、例えば携帯機器１８からＢＴ通信で受信したオーディオデータや音声通話データ等を車載ユニット１２のスピーカ２４から出力したり、マイク２６で拾った音声を携帯機器１８に転送したりすることが可能になる。
【００４９】
〔パケット通信方法〕
次に、本実施形態の通信システム１０において使用されているパケット通信方法の一例について説明する。
【００５０】
図３は、ＢＴモジュール３０が実行する通信処理の手順例を示したフローチャートである。この受信処理は、通信システム１０内でローカルデバイスである車載ユニット１２とリモートデバイスである携帯機器１４〜１８との間でＲＦＣＯＭＭ接続が完了した後に開始される。なお、ＢＴ通信におけるＲＦＣＯＭＭ接続のシーケンスについては公知のものを適用できるので、ここではその詳細を省略する。
【００５１】
ＲＦＣＯＭＭ接続が完了すると、ＢＴモジュール３０内で上記のＨＯＳＴモジュール間制御部５６をはじめクレジット送信処理部４４、ＤＵＮ／ＳＰＰデータ送信処理部４６、他プロファイルデータ送信処理部５０、ＤＵＮ／ＳＰＰデータ受信処理部５２、他プロファイルデータ受信処理部５４等の演算処理機能を有した構成要素を用いて通信処理が実行される。
【００５２】
この通信処理は、マルチプロファイル状態検知部４８に予めトリガとなる条件を付与しておき、通信中のトリガ条件に応じてクレジット送信処理部４４によるクレジット送信処理を動的に操作し、ダイアルアップネットワークやシリアルポートを用いたアプリケーションによるデータアクセス中の受信帯域を他のアプリケーションに割り当てるものである。以下、手順例に沿って説明する。
【００５３】
ステップＳ１０：ＲＦＣＯＭＭプロトコルでのクレジットベースドフローコントロールにおいて、ＢＴモジュール３０は最初にクレジット送信処理部４４によるフリークレジットの値を「０」に設定する。
【００５４】
ステップＳ１２：次にＢＴモジュール３０は、リモートデバイスである携帯機器１４〜１８でのカレントクレジットの値をローカルデバイスにおける初期クレジットの値（例えば「７」）に設定する。
【００５５】
ステップＳ１４：ＢＴモジュール３０は、通信処理のモードとして「モード１」を設定する。
【００５６】
ステップＳ１６：次にＢＴモジュール３０は、上記のマルチプロファイル状態検知部４８により通信状態を確認する（検出工程）。
【００５７】
ステップＳ１８：そしてＢＴモジュール３０は、上記の結果からマルチプロファイル状態検知部４８においてトリガとなる条件が満たされたか否か（「コンディションＣ」の条件を満たすか否か）を判断する。例えば、以下に該当する場合を「コンディションＣ」の条件を満たすと判断することができる。
【００５８】
〔コンディションＣのトリガ条件〕
（１）ダイアルアップやシリアルポートを用いたデータアクセスと同時並行してオーディオアプリケーションの動作中に、マルチプロファイル状態検知部４８がオーディオアプリケーションの状態を「停止中」から「再生中」に遷移したことを検知した場合。オーディオアプリケーションの動作中は通信処理にリアルタイム性が要求されるため、これをトリガ条件とする。
【００５９】
（２）ダイアルアップやシリアルポートを用いたデータアクセスと同時並行してハンズフリーアプリケーションの動作中に、マルチプロファイル状態検知部４８がハンズフリーアプリケーションの状態を「ＳＬＣ接続中」から「通話中」に遷移したことを検知した場合。この場合、ＨＦＰ通話の音質やＨＦＰコントロールデータの受信処理を優先する必要があるため、これをトリガ条件とする。
【００６０】
（３）ダイアルアップやシリアルポートを用いたデータアクセスと同時並行してパーソナルインフォメーションマネージャアプリケーション(ＯＰＰ、ＰＢＡＰ)の動作中に、マルチプロファイル状態検知部４８がこれらアプリケーションの状態を「ＳＬＣ接続中」から「データ取得中」に遷移したことを検知した場合。この場合も同様にデータの受信処理を優先する必要があるため、これをトリガ条件とする。なお、パーソナルインフォメーションマネージャアプリケーション(ＯＰＰ、ＰＢＡＰ)の動作中にデータの受信処理を優先する必要があるのは、例えば携帯情報端末や携帯電話機である携帯機器１６，１８からアドレス帳等のデータを受信する際、そのデータ転送を所定時間（例えば数秒〜十数秒間）内で完了させる必要があることを考慮したものである。
【００６１】
特に上記（１）〜（３）のトリガ条件が満たされていなければ（ステップＳ１８：Ｎｏ）、ＢＴモジュール３０は次にステップＳ２０に進む。
【００６２】
ステップＳ２０：現在は「モード１」に設定されているため（Ｙｅｓ）、ＢＴモジュール３０はここでステップＳ２２を実行する。
【００６３】
ステップＳ２２：この場合、ＢＴモジュール３０は「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」を実行する。そして、この処理から復帰すると、ＢＴモジュール３０はステップＳ１６に戻ってマルチプロファイル状態検知部４８による通信状態の確認を継続する（検出工程）。
【００６４】
これに対し、上記（１）〜（３）のいずれかのトリガ条件が満たされると（ステップＳ１８：Ｙｅｓ）、ＢＴモジュール３０は次にステップＳ２４に進む。
【００６５】
ステップＳ２４：この場合、ＢＴモジュール３０は「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」を実行する。
【００６６】
ステップＳ２６：次にＢＴモジュール３０は、通信処理のモードとして「モード２」を設定する。そしてＢＴモジュール３０は、ステップＳ１６に戻り、マルチプロファイル状態検知部４８による通信状態の確認を継続する。
【００６７】
上記（１）〜（３）のいずれかのトリガ条件が満たされなくなるまでの間（ステップＳ１８：Ｙｅｓ）、ＢＴモジュール３０は引き続きステップＳ２４に進み、「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」を実行する（ステップＳ１６〜ステップＳ２６のループ）。
【００６８】
この後、上記（１）〜（３）のいずれかのトリガ条件が満たされなくなると（ステップＳ１８：Ｎｏ）、ＢＴモジュール３０はステップＳ２０に進み、現在のモードを確認する。
【００６９】
ステップＳ２０：そして、この時点では「モード２」に設定されているため（Ｎｏ）、次にステップＳ２８が実行されることになる。
【００７０】
ステップＳ２８：ＢＴモジュール３０は、「ＲＦＣＯＭＭデータ受信及びクレジット送信補正処理」を実行する。
【００７１】
〔ＲＦＣＯＭＭデータ受信及びクレジット送信処理１〕
図４は、上記のステップＳ２２で実行される「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」の手順例を示すフローチャートである。以下、この処理について説明する。
【００７２】
ステップＳ４０：ＢＴモジュール３０は、ＲＦＣＯＭＭデータ受信を開始する。
ステップＳ４２：またＢＴモジュール３０は、フリークレジットの値を「１」インクリメントする。これにより、前回のフリークレジットの値が１つ加算された状態となる。
【００７３】
ステップＳ４４：次にＢＴモジュール３０は、リモートデバイスである携帯機器１４〜１８でのカレントクレジットの値を「１」デクリメントする。これにより、前回のカレントクレジットの値が１つ減算された状態となる。
【００７４】
ステップＳ４６：ここでＢＴモジュール３０は、条件として「コンディションＡ」が満たされるか否かを判断する。なお「コンディションＡ」は、例えば以下の内容とすることができる。
【００７５】
カレントクレジット≦Ｔｈ１ かつ フリークレジット≧Ｔｈ２
ただし、ローカルデバイスの初期クレジット＝Ｔｈ１＋Ｔｈ２である。なお、上記の例では初期クレジットの値を「７」としているので、ここではＴｈ１＝１、Ｔｈ２＝６とする。
【００７６】
特に「コンディションＡ」の条件が満たされない場合（ステップＳ４６：Ｎｏ）、ＢＴモジュール３０はステップＳ４０に戻ってＲＦＣＯＭＭデータ受信を繰り返す。そして、フリークレジットの値をインクリメントし（ステップＳ４２）、代わりにカレントクレジットの値をデクリメントすると（ステップＳ４４）、再びＢＴモジュール３０は「コンディションＡ」の条件を満たすか否かを判断する。
【００７７】
このように、カレントクレジットの値がＴｈ１＝「１」以下になり、かつ、フリークレジットの値がＴｈ２＝「６」以上になるまでの間、ＢＴモジュール３０はＲＦＣＯＭＭデータ受信を繰り返す。したがってリモートデバイスは、初期クレジットの値で与えられたカレントクレジットが残存しなくなるまでの間、ローカルデバイスに対してパケットデータを送信することができる。
【００７８】
この後、カレントクレジットの値がＴｈ１以下になり、かつ、フリークレジットの値がＴｈ２以上になると、「コンディションＡ」の条件が満たされるので（ステップＳ４６：Ｙｅｓ）、ＢＴモジュール３０は次にステップＳ４８を実行する。
【００７９】
ステップＳ４８：ここでＢＴモジュール３０は、クレジットとして「フリークレジットＡ」をリモートデバイスに送信する。このときの「フリークレジットＡ」は、現在の「フリークレジット」に等しい。したがって上記の例では「６」が送信されることになる。
【００８０】
ステップＳ５０：次にＢＴモジュール３０は、フリークレジットの値を「０」にリセットする。
ステップＳ５２：そしてＢＴモジュール３０は、カレントクレジットの値＝「１」に「フリークレジットＡ」＝「６」を加算して、カレントクレジットの値を「７」に更新する。
【００８１】
このように、「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」では、以上の手順を繰り返しながら通信処理が行われる。
【００８２】
〔通信処理シーケンス〕
図５は、「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」による通信処理の流れを示すシーケンス図である。図５中、左側カラムにはローカルデバイス（ＢＴモジュール３０）による処理を示し、右側カラムにはリモートデバイス（例えば携帯機器１８）による処理を示す。なお以下の説明では、それぞれを単にローカルデバイス、リモートデバイスと一般化して呼称する。
【００８３】
ＳＴ１：シーケンス初期において、ローカルデバイスとリモートデバイスとの間でＲＦＣＯＭＭ接続が完了する。
【００８４】
ＳＴ２：ローカルデバイスのフリークレジットの値が「０」に設定される。
ＳＴ３：リモートデバイスにおいて、カレントクレジットの値はローカルデバイスの初期クレジットの値＝「７」に設定される。この値は、これからローカルデバイスが受信可能なパケット数を指定したものである。ＲＦＣＯＭＭプロトコルで規定されたクレジットベースドフローコントロールでは、リモートデバイスにおいてカレントクレジットの値が「０」になるまでの間、フレーム送信（パケットデータの送信）が可能である。
【００８５】
ＳＴ４：このためリモートデバイスは、ローカルデバイスに対してパケットデータを送信する。
【００８６】
ＳＴ５：ＲＦＣＯＭＭデータ受信を行うと、ローカルデバイスはフリークレジットの値を「１」にインクリメントする。
ＳＴ６：一方、リモートデバイスは、カレントクレジットの値を「７」から「６」にデクリメントする。
【００８７】
ＳＴ７：未だカレントクレジットが残存しているので、リモートデバイスはパケットデータをローカルデバイスに対して送信する。
【００８８】
ＳＴ８：ＲＦＣＯＭＭデータ受信を行うと、ローカルデバイスはフリークレジットの値を「２」にインクリメントする。
ＳＴ９：一方、リモートデバイスは、カレントクレジットの値を「５」にデクリメントする。
【００８９】
ＳＴ１０：未だカレントクレジットが残存しているので、リモートデバイスはパケットデータをローカルデバイスに対して送信する。
【００９０】
ＳＴ１１：以上の処理を繰り返し、ローカルデバイスのフリークレジットの値が「６」までインクリメントされる。
ＳＴ１２：このときリモートデバイスは、カレントクレジットの値が「１」までデクリメントされている。
【００９１】
ＳＴ１３：ここで上記の「コンディションＡ」の条件が満たされるので、ローカルデバイスは「フリークレジットＡ」をリモートデバイスに送信する。
ＳＴ１４：そしてローカルデバイスは、フリークレジットの値を「０」にリセットする。
【００９２】
ＳＴ１５：リモートデバイスは、カレントクレジットに「フリークレジットＡ」を加算し、カレントクレジットの値を「７」に更新する。
【００９３】
ＳＴ１６：「コンディションＡ」の条件は満たされなくなり、カレントクレジットが残存しているので、リモートデバイスはパケットデータをローカルデバイスに対して送信することができる。
【００９４】
ＳＴ１７：ＲＦＣＯＭＭデータ受信を行うと、ローカルデバイスはフリークレジットの値を「１」にインクリメントする。
ＳＴ１８：一方、リモートデバイスは、カレントクレジットの値を「７」から「６」にデクリメントする。
【００９５】
ＳＴ１９：未だカレントクレジットが残存しているので、リモートデバイスはパケットデータをローカルデバイスに対して送信する。
【００９６】
ＳＴ２０：ＲＦＣＯＭＭデータ受信を行うと、ローカルデバイスはフリークレジットの値を「２」にインクリメントする。
ＳＴ２１：一方、リモートデバイスは、カレントクレジットの値を「５」にデクリメントする。
【００９７】
ＳＴ２２：未だカレントクレジットが残存しているので、リモートデバイスはパケットデータをローカルデバイスに対して送信する。
【００９８】
ＳＴ２３：ＲＦＣＯＭＭデータ受信を行うと、ローカルデバイスはフリークレジットの値を「３」にインクリメントする。
ＳＴ２４：一方、リモートデバイスは、カレントクレジットの値を「４」にデクリメントする。
【００９９】
以下、所望量のデータ転送が完了するまでの間、同様にして通信処理のシーケンスが実行される。ＢＴモジュール３０は、図４の「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」の実行中、例えばタイマ割り込みを発生させて所望量のデータ転送が完了したか否かを確認している。いずれかの割り込み周期でデータ転送が完了していれば、ＢＴモジュール３０は「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」を抜けて図３の通信処理に復帰する。
【０１００】
以上の通信処理シーケンスは、マルチプロファイル状態検知部４８においてトリガ条件が満たされる前の内容であるが、トリガ条件が満たされた場合は以下の処理が実行される。
【０１０１】
〔ＲＦＣＯＭＭデータ受信及びクレジット送信処理２〕
図６は、上記のステップＳ２４で実行される「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」の手順例を示すフローチャートである。以下、この処理について説明する。
【０１０２】
ステップＳ６０：ＢＴモジュール３０は、ダイヤルアップやシリアルポートのデータアクセスに関する通信処理中に待機時間（例えば５００ｍｓｅｃ）を挿入して待機する（待機工程）。
【０１０３】
ステップＳ６２：待機時間が経過すると、ＢＴモジュール３０はＲＦＣＯＭＭデータ受信を開始する。
ステップＳ６４：またＢＴモジュール３０は、フリークレジットの値を「１」インクリメントする。これにより、前回のフリークレジットの値が１つ加算された状態となる。
【０１０４】
ステップＳ６６：次にＢＴモジュール３０は、リモートデバイスである携帯機器１４〜１８でのカレントクレジットの値を「１」デクリメントする。これにより、前回のカレントクレジットの値が１つ減算された状態となる。
【０１０５】
ステップＳ６８：ここでＢＴモジュール３０は、条件として「コンディションＢ」が満たされるか否かを判断する。ここでいう「コンディションＢ」は、例えば以下の内容とすることができる。
【０１０６】
カレントクレジット≦Ｔｈ３ かつ フリークレジット≧Ｔｈ４
ただし、Ｔｈ３はＴｈ１より小さく、またＴｈ４はＴｈ２より小さい値とする。ここでは例えば、Ｔｈ３＝０、Ｔｈ４＝１とする。
【０１０７】
特に「コンディションＢ」の条件が満たされない場合（ステップＳ６８：Ｎｏ）、ＢＴモジュール３０はステップＳ６０に戻って待機時間だけ待機した後、ステップＳ６２に進んでＲＦＣＯＭＭデータ受信を繰り返す。そして、フリークレジットの値をインクリメントし（ステップＳ６４）、代わりにカレントクレジットの値をデクリメントすると（ステップＳ６６）、再びＢＴモジュール３０は「コンディションＢ」の条件を満たすか否かを判断する。
【０１０８】
このように、カレントクレジットの値がＴｈ３＝「０」以下になり、かつ、フリークレジットの値がＴｈ４＝「１」以上になるまでの間、ＢＴモジュール３０はＲＦＣＯＭＭデータ受信を繰り返す。したがってリモートデバイスは、初期クレジットの値で与えられたカレントクレジットが残存しなくなるまでの間、ローカルデバイスに対してパケットデータを送信することができる。
【０１０９】
この後、カレントクレジットの値がＴｈ３以下（＝０）になり、かつ、フリークレジットの値がＴｈ４以上（＝１）になると、「コンディションＢ」の条件が満たされるので（ステップＳ６８：Ｙｅｓ）、ＢＴモジュール３０は次にステップＳ７０を実行する。
【０１１０】
ステップＳ７０：ここでＢＴモジュール３０は、クレジットとして「フリークレジットＢ」をリモートデバイスに送信する。このときの「フリークレジットＢ」は、Ｔｈ４＝「１」と同値である。したがって上記の例では「１」が送信されることになる。
【０１１１】
ステップＳ７２：次にＢＴモジュール３０は、フリークレジットの値を「０」にリセットする。
ステップＳ７４：そしてＢＴモジュール３０は、カレントクレジットの値＝「０」に「フリークレジットＢ」＝「１」を加算して、カレントクレジットの値を「１」に更新する。
【０１１２】
次にＢＴモジュール３０がステップＳ６２でＲＦＣＯＭＭデータ受信を行うと、ステップＳ６４でフリークレジットの値が「１」となるが、ステップＳ６６でカレントクレジットの値は１度のＲＦＣＯＭＭデータ受信で「０」になる。このためリモートデバイスは、ローカルデバイスに対してパケットデータを送信することができなくなり、ステップＳ７０〜ステップＳ７４を経てステップＳ６０に戻ることになる。そして、ステップＳ６０で待機時間を待機し、次のＲＦＣＯＭＭデータ受信を行う。
【０１１３】
このように、「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」では、以上の手順を繰り返しながら通信処理が行われるが、この間、カレントクレジットの値は最大で「１」にしかならないので、ローカルデバイスが受信可能なパケット数が減少する（減少工程）。また、ＲＦＣＯＭＭデータ受信を１度行うごとに待機時間が挿入されるため、それだけ通信処理にかかる時間が遅延する（待機工程）。
【０１１４】
〔通信処理シーケンス〕
図７は、「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」による通信処理の流れを示すシーケンス図である。
【０１１５】
ＳＴ５０：シーケンス初期において、ローカルデバイスとリモートデバイスとの間でＲＦＣＯＭＭ接続が完了する。
【０１１６】
ＳＴ５１：ローカルデバイスのフリークレジットの値が「０」に設定される。
ＳＴ５２：リモートデバイスにおいて、カレントクレジットの値はローカルデバイスの初期クレジットの値＝「７」に設定される。この値は、上記と同様にこれからローカルデバイスが受信可能なパケット数を指定したものである。
【０１１７】
ＳＴ５３：リモートデバイスは、ローカルデバイスに対してパケットデータを送信する。
【０１１８】
ＳＴ５４：ＲＦＣＯＭＭデータ受信を行うと、ローカルデバイスはフリークレジットの値を「１」にインクリメントする。
ＳＴ５５：一方、リモートデバイスは、カレントクレジットの値を「７」から「６」にデクリメントする。
【０１１９】
ＳＴ５６：未だカレントクレジットが残存しているので、リモートデバイスはパケットデータをローカルデバイスに対して送信する。
【０１２０】
ＳＴ５７：ＲＦＣＯＭＭデータ受信を行うと、ローカルデバイスはフリークレジットの値を「２」にインクリメントする。
ＳＴ５８：一方、リモートデバイスは、カレントクレジットの値を「５」にデクリメントする。
【０１２１】
ＳＴ５９：未だカレントクレジットが残存しているので、リモートデバイスはパケットデータをローカルデバイスに対して送信する。
【０１２２】
ＳＴ６０：以上の処理を繰り返し、ローカルデバイスのフリークレジットの値が「７」までインクリメントされる。
ＳＴ６１：このときリモートデバイスは、カレントクレジットの値が「０」までデクリメントされている。したがって、リモートデバイスはこれ以上、パケットデータを送信することができない。
【０１２３】
ＳＴ６２：ここでローカルデバイスは、設定した待機時間を待機する。
ＳＴ６３：上記の「コンディションＢ」の条件が満たされるので、ローカルデバイスは「フリークレジットＢ」をリモートデバイスに送信する。
ＳＴ６４：そしてローカルデバイスは、フリークレジットの値を「０」にリセットする。
【０１２４】
ＳＴ６５：リモートデバイスは、カレントクレジットに「フリークレジットＢ」を加算し、カレントクレジットの値を「１」に更新する。
【０１２５】
ＳＴ６６：「コンディションＢ」の条件は満たされなくなり、カレントクレジットが残存しているので、リモートデバイスはパケットデータをローカルデバイスに対して送信することができる。
【０１２６】
ＳＴ６７：ＲＦＣＯＭＭデータ受信を行うと、ローカルデバイスはフリークレジットの値を「１」にインクリメントする。
ＳＴ６８：一方、リモートデバイスは、カレントクレジットの値を「１」から「０」にデクリメントする。これにより、リモートデバイスはこれ以上、パケットデータを送信することができなくなる。
【０１２７】
ＳＴ６９：ここでローカルデバイスは、また設定した待機時間を待機する。
ＳＴ７０：上記の「コンディションＢ」の条件が満たされるので、ローカルデバイスは「フリークレジットＢ」をリモートデバイスに送信する。
【０１２８】
ＳＴ７１：そしてローカルデバイスは、フリークレジットの値を「０」にリセットする。
ＳＴ７２：リモートデバイスは、カレントクレジットに「フリークレジットＢ」を加算し、カレントクレジットの値を「１」に更新する。これにより、リモートデバイスは１パケット分だけデータを送信することが可能になる。
【０１２９】
以下、所望量のデータ転送が完了するまでの間、同様にして通信処理のシーケンスが実行される。ＢＴモジュール３０は、図６の「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」の実行中、例えばタイマ割り込みを発生させて所望量のデータ転送が完了したか否かを確認している。いずれかの割り込み周期でデータ転送が完了していれば、ＢＴモジュール３０は「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」を抜けて図３の通信処理に復帰する。
【０１３０】
ただし、「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」の実行中は１回のＲＦＣＯＭＭデータ受信ごとに待機時間が挿入されるので、相対的に別の通信プロファイルを用いた通信処理に割り当てられる時間が長くなる。また、１回のＲＦＣＯＭＭデータ受信が可能なパケット数が減少するため、別の通信プロファイルを用いた通信処理（特に図示していない）について相対的にパケット数が増加し、それだけデータ受信帯域が広げられることとなる。
【０１３１】
〔ＲＦＣＯＭＭデータ受信及びクレジット送信補正処理〕
次に図８は、「ＲＦＣＯＭＭデータ受信及びクレジット送信補正処理」の手順例を示すフローチャートである。この処理は、図３の通信処理において「コンディションＣ」のトリガ条件が満たされた後、この条件が満たされなくなった場合に実行される。
【０１３２】
ステップＳ８０：ここでもＢＴモジュール３０は、ＲＦＣＯＭＭデータ受信を実行する。
ステップＳ８２：またＢＴモジュール３０は、フリークレジットの値を「１」インクリメントする。これにより、前回のフリークレジットの値が１つ加算された状態となる。
【０１３３】
ステップＳ８４：次にＢＴモジュール３０は、リモートデバイスでのカレントクレジットの値を「１」デクリメントする。
【０１３４】
ステップＳ８６：ここでＢＴモジュール３０は、条件として「コンディションＤ」が満たされるか否かを判断する。なお「コンディションＤ」は、例えば以下の内容とすることができる。
【０１３５】
カレントクレジット＝「０」
【０１３６】
特に「コンディションＤ」の条件（つまりカレントクレジット＝０）が満たされない場合（ステップＳ８６：Ｎｏ）、ＢＴモジュール３０はステップＳ８０に戻ってＲＦＣＯＭＭデータ受信を繰り返す。そして、フリークレジットの値をインクリメントし（ステップＳ８２）、代わりにカレントクレジットの値をデクリメントすると（ステップＳ８４）、再びＢＴモジュール３０は「コンディションＤ」の条件を満たすか否かを判断する。
【０１３７】
このように、カレントクレジットの値が「０」になるまでの間、ＢＴモジュール３０はＲＦＣＯＭＭデータ受信を繰り返す。したがってリモートデバイスは、初期クレジットの値で与えられたカレントクレジットが残存しなくなるまでの間、ローカルデバイスに対してパケットデータを送信することができる。
【０１３８】
この後、カレントクレジットの値が「０」になると、「コンディションＤ」の条件が満たされるので（ステップＳ８６：Ｙｅｓ）、ＢＴモジュール３０は次にステップＳ８８を実行する。
【０１３９】
ステップＳ８８：ここでＢＴモジュール３０は、クレジットとして「フリークレジットＤ」をリモートデバイスに送信する。このときの「フリークレジットＤ」は、ローカルデバイスの初期クレジットに等しい。したがって上記の例では「７」が送信されることになる。
【０１４０】
ステップＳ９０：次にＢＴモジュール３０は、フリークレジットの値を「０」にリセットする。
ステップＳ９２：そしてＢＴモジュール３０は、カレントクレジットの値＝「０」に「フリークレジットＤ」＝「７」を加算して、カレントクレジットの値を「７」に更新する。
【０１４１】
ステップＳ９４：ＢＴモジュール３０は「モード１」を設定し、図３の通信処理に復帰する。
【０１４２】
この後、「モード１」が設定されているので、次にトリガ条件が満たされるまでの間（図３のステップＳ１８：Ｎｏ、ステップＳ２０：Ｙｅｓ）、「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」が実行されることになる。
【０１４３】
以上のように本実施形態では、マルチプロファイル状態検知部４８にトリガとなる条件を付与し、通信状態が変化するごとに「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」と「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」とを動的に切り替えることにより、ダイアルアップやシリアルポートを用いたアプリケーションによるデータアクセス中の受信帯域を他のアプリケーションに割り当てることが可能となる。
【０１４４】
また、「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」の実行中にマルチプロファイル状態検知部４８がオーディオアプリケーションの状態を「再生中」から「停止中」に遷移したことを検知した場合、あるいは、「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」の実行中にマルチプロファイル状態検知部４８がハンズフリーアプリケーションの状態を「通話中」から「ＳＬＣ接続中」に遷移したことを検知した場合、図８の「補正処理」を経て「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」に切り替え、できるだけデータ受信のスループットを優先することができる。
【０１４５】
〔製品市場での有用性〕
特に近年のＢＴ通信のユーザーシナリオにおいては、マルチコネクションやマルチプロファイルでの動作及び品質の向上が製品市場から求められている。その中で個々のプロファイル(アプリケーション)によっては、音声通話やオーディオ伝送等、リアルタイム性や音質を厳しく問われる要素と、ダイアルアップ（ＤＵＮ／ＳＰＰ）のように、ベストエフォート型データ通信の要素に大別することができるが、これらを最大限に共存させるため、送信／受信帯域の制御が課題となっている。
【０１４６】
本実施形態の通信方法では、リアルタイム性や品質が求められる要素とベストエフォート型データ通信の要素が同時並行して通信を実行中に、前者が通話中又はオーディオ再生中の状態になったことを検出した場合、後者の要素に関してクレジット数及びその送信条件、送信方法を適応的に変更することができ、それにより受信可能なパケット数を制限し、結果として後者の要素に関して受信帯域を相対的に減少させ、逆に前者のリアルタイム性及び音質を可能な限り改善する効果がある。
【０１４７】
また、前者の通信において終話又はオーディオ停止の状態を検出した場合、本来の通信処理に復帰させることによって受信帯域を可能な限り増加させ、データ受信のスループットを確保することができる。
【０１４８】
本発明は上述した実施形態に制約されることなく、各種の変形を伴って実施することができる。一実施形態で挙げたＢＴモジュール３０の構成はあくまで機能的なブロック要素の例示であり、これらの機能をマイクロコンピュータ（ＣＰＵ）のリソースで全て賄い、それぞれの機能をアプリケーションで実現してもよい。
【０１４９】
また、一実施形態では通信処理を優先するものとしてオーディオデータや音声通話データ等を例に挙げているが、映像データを転送する際にも本発明の通信方法を適用することができる。
【図面の簡単な説明】
【０１５０】
【図１】通信システムの構成例を概略的に示す図である。
【図２】ＢＴモジュールのハード構成例を概略的に示すブロック図である。
【図３】ＢＴモジュール３０が実行する通信処理の手順例を示したフローチャートである。
【図４】「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」の手順例を示すフローチャートである。
【図５】「ＲＦＣＯＭＭデータ受信及びクレジット送信処理１」による通信処理の流れを示すシーケンス図である。
【図６】「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」の手順例を示すフローチャートである。
【図７】「ＲＦＣＯＭＭデータ受信及びクレジット送信処理２」による通信処理の流れを示すシーケンス図である。
【図８】「ＲＦＣＯＭＭデータ受信及びクレジット送信補正処理」の手順例を示すフローチャートである。
【符号の説明】
【０１５１】
１０ 通信システム
１２ 車載ユニット
１４，１６，１８ 携帯機器
３０ ＢＴモジュール
４４ クレジット送信処理部
４６ ＤＵＮ／ＳＰＰデータ送信処理部
４８ マルチプロファイル状態検知部
５０ 他プロファイルデータ送信処理部
５２ ＤＵＮ／ＳＰＰデータ受信処理部
５４ 他プロファイルデータ受信処理部
【特許請求の範囲】
【請求項１】
複数の通信プロファイルを用いて通信する機能を有したローカルデバイス及びリモートデバイスから構成される通信システム内で、ローカルデバイスとリモートデバイスとの通信開始時に予めローカルデバイスが受信可能なパケット数をリモートデバイスに通知し、この通知されたパケット数分のデータをリモートデバイスからローカルデバイスに送信してローカルデバイスで受信する通信処理を繰り返しながら所望量のパケットデータを送受信するパケット通信方法において、
ローカルデバイスがいずれかのリモートデバイスとの間で前記通信処理を実行する際、複数ある通信プロファイルの中でいずれの通信プロファイルを用いて前記通信処理が実行されているかを検出する工程と、
ローカルデバイスが特定のリモートデバイスとの間で前記通信処理を実行中に、同じ特定のリモートデバイスか、もしくは別のリモートデバイスとの間で現在とは異なる別の通信プロファイルを用いて別の前記通信処理が実行されたことを検出した場合、現在実行中の前記通信処理の中でローカルデバイスが前記特定のリモートデバイスに通知する受信可能なパケット数を減少させることにより、別の通信プロファイルを用いた前記通信処理の中でローカルデバイスが受信可能なパケット数を相対的に増加させる工程と
を有するパケット通信方法。
【請求項２】
請求項１に記載のパケット通信方法において、
ローカルデバイスが特定のリモートデバイスとの間で前記通信処理を実行中に、同じ特定のリモートデバイスか、もしくは別のリモートデバイスとの間で現在とは異なる別の通信プロファイルを用いて別の前記通信処理が実行されたことを検出した場合、現在実行中の前記通信処理の中に待機時間を挿入する工程をさらに有するパケット通信方法。
【請求項３】
請求項２に記載のパケット通信方法において、
前記待機時間を挿入する工程では、
現在実行中の前記通信処理の中でローカルデバイスが前記特定のリモートデバイスに受信可能なパケット数を通知する前に待機時間を挿入することを特徴とするパケット通信方法。
【請求項４】
請求項１から３のいずれかに記載のパケット通信方法において、
前記パケット数を相対的に増加させる工程では、
現在の通信プロファイルに比較して別の通信プロファイルの方がよりリアルタイム性を要求されるものである場合に現在実行中の前記通信処理の中でパケット数を減少させることを特徴とするパケット通信方法。
【請求項５】
請求項１から３のいずれかに記載のパケット通信方法において、
前記パケット数を相対的に増加させる工程では、
別の通信プロファイルがオーディオデータ又は音声通話データをローカルデバイスで受信する場合に使用されるものであるか、もしくは、所定時間内にリモートデバイスからローカルデバイスへのデータ転送を完了させる必要がある場合に使用されるものであるかのいずれかである場合、現在実行中の前記通信処理の中でパケット数を減少させることを特徴とするパケット通信方法。
【請求項６】
請求項１から５のいずれかに記載のパケット通信方法において、
前記通信処理は、
特定の短距離無線通信規格におけるＲＦＣＯＭＭプロトコルにより定義されたクレジットベースドフローコントロールに則り、ローカルデバイスが受信可能なパケット数をクレジット数としてローカルデバイスからリモートデバイスに通知する手順と、
リモートデバイスからパケットデータをローカルデバイスに送信するごとにリモートデバイスにおいてクレジット数を減少させる手順とを含み、
前記クレジット数がリモートデバイスにおいて残存している間はリモートデバイスからローカルデバイスに対してパケットデータの送信が可能である一方、前記クレジット数が残存しなくなるとリモートデバイスからローカルデバイスからリモートデバイスへのパケットデータの送信が不可となることを特徴とするパケット通信方法。
【請求項１】
複数の通信プロファイルを用いて通信する機能を有したローカルデバイス及びリモートデバイスから構成される通信システム内で、ローカルデバイスとリモートデバイスとの通信開始時に予めローカルデバイスが受信可能なパケット数をリモートデバイスに通知し、この通知されたパケット数分のデータをリモートデバイスからローカルデバイスに送信してローカルデバイスで受信する通信処理を繰り返しながら所望量のパケットデータを送受信するパケット通信方法において、
ローカルデバイスがいずれかのリモートデバイスとの間で前記通信処理を実行する際、複数ある通信プロファイルの中でいずれの通信プロファイルを用いて前記通信処理が実行されているかを検出する工程と、
ローカルデバイスが特定のリモートデバイスとの間で前記通信処理を実行中に、同じ特定のリモートデバイスか、もしくは別のリモートデバイスとの間で現在とは異なる別の通信プロファイルを用いて別の前記通信処理が実行されたことを検出した場合、現在実行中の前記通信処理の中でローカルデバイスが前記特定のリモートデバイスに通知する受信可能なパケット数を減少させることにより、別の通信プロファイルを用いた前記通信処理の中でローカルデバイスが受信可能なパケット数を相対的に増加させる工程と
を有するパケット通信方法。
【請求項２】
請求項１に記載のパケット通信方法において、
ローカルデバイスが特定のリモートデバイスとの間で前記通信処理を実行中に、同じ特定のリモートデバイスか、もしくは別のリモートデバイスとの間で現在とは異なる別の通信プロファイルを用いて別の前記通信処理が実行されたことを検出した場合、現在実行中の前記通信処理の中に待機時間を挿入する工程をさらに有するパケット通信方法。
【請求項３】
請求項２に記載のパケット通信方法において、
前記待機時間を挿入する工程では、
現在実行中の前記通信処理の中でローカルデバイスが前記特定のリモートデバイスに受信可能なパケット数を通知する前に待機時間を挿入することを特徴とするパケット通信方法。
【請求項４】
請求項１から３のいずれかに記載のパケット通信方法において、
前記パケット数を相対的に増加させる工程では、
現在の通信プロファイルに比較して別の通信プロファイルの方がよりリアルタイム性を要求されるものである場合に現在実行中の前記通信処理の中でパケット数を減少させることを特徴とするパケット通信方法。
【請求項５】
請求項１から３のいずれかに記載のパケット通信方法において、
前記パケット数を相対的に増加させる工程では、
別の通信プロファイルがオーディオデータ又は音声通話データをローカルデバイスで受信する場合に使用されるものであるか、もしくは、所定時間内にリモートデバイスからローカルデバイスへのデータ転送を完了させる必要がある場合に使用されるものであるかのいずれかである場合、現在実行中の前記通信処理の中でパケット数を減少させることを特徴とするパケット通信方法。
【請求項６】
請求項１から５のいずれかに記載のパケット通信方法において、
前記通信処理は、
特定の短距離無線通信規格におけるＲＦＣＯＭＭプロトコルにより定義されたクレジットベースドフローコントロールに則り、ローカルデバイスが受信可能なパケット数をクレジット数としてローカルデバイスからリモートデバイスに通知する手順と、
リモートデバイスからパケットデータをローカルデバイスに送信するごとにリモートデバイスにおいてクレジット数を減少させる手順とを含み、
前記クレジット数がリモートデバイスにおいて残存している間はリモートデバイスからローカルデバイスに対してパケットデータの送信が可能である一方、前記クレジット数が残存しなくなるとリモートデバイスからローカルデバイスからリモートデバイスへのパケットデータの送信が不可となることを特徴とするパケット通信方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１０−１５３９９５（Ｐ２０１０−１５３９９５Ａ）
【公開日】平成２２年７月８日（２０１０．７．８）
【国際特許分類】
【出願番号】特願２００８−３２７３４８（Ｐ２００８−３２７３４８）
【出願日】平成２０年１２月２４日（２００８．１２．２４）
【出願人】（００００１００９８）アルプス電気株式会社 (4,263)
【Ｆターム（参考）】
【公開日】平成２２年７月８日（２０１０．７．８）
【国際特許分類】
【出願日】平成２０年１２月２４日（２００８．１２．２４）
【出願人】（００００１００９８）アルプス電気株式会社 (4,263)
【Ｆターム（参考）】
[ Back to top ]