(58)【調査した分野】(Int.Cl.,DB名)
前記タイミング調整部は、前記同期通信が終了した少なくとも1つの装置との同期通信の期間の少なくとも一部において前記第5装置との同期通信を実行するように、前記第5装置の同期通信のタイミングを調整する、請求項2記載の情報処理装置。
前記タイミング調整部は、前記比較部により、前記同期通信が終了した少なくとも1つの装置との同期通信の期間と、前記第5装置との同期通信の期間との比較に基づいて、前記同期通信が終了した少なくとも1つの装置との同期通信の期間の少なくとも一部において前記第5装置と同期通信を実行するように、前記第5装置の同期通信のタイミングを調整する、請求項5記載の情報処理装置。
前記タイミング調整部は、前記第1装置および前記第2装置、前記第4装置のうちの少なくとも1つの装置との同期通信が終了した場合に、前記第1装置および前記第2装置、前記第4装置それぞれとの同期通信のうちの継続中の同期通信が連続的に実行されるように前記継続中の同期通信のタイミングの少なくともいずれか1つを再調整する、請求項1記載の情報処理装置。
前記第1装置、前記第2装置および前記第4装置のそれぞれと前記第1通信部との同期通信のタイミングの基準となる基準タイミングを設定する基準タイミング設定部をさらに備える、請求項1に記載の情報処理装置。
前記タイミング調整部は、前記基準タイミング設定部により設定された基準タイミングに従って前記第1通信部による前記第1装置、前記第2装置および前記第4装置のそれぞれとの同期通信のタイミングを調整する、請求項9記載の情報処理装置。
前記タイミング調整部は、前記第1装置との同期通信が終了した後、第4装置と同期通信を実行する場合に、前記基準タイミングに従って前記第1通信部による前記第2装置との同期通信の終了時点と、前記第4装置との同期通信の開始時点とが実質的に連続となるように、前記第2装置との同期通信のタイミングまたは前記第4装置との同期通信のタイミングの少なくともいずれか一方を調整する、請求項10記載の情報処理装置。
【発明を実施するための形態】
【0047】
実施形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰り返さない。
(実施形態1)
[A.全体システムの構成]
[a1.全体システムの構成]
図1は、実施形態1に基づく全体システム1について説明する図である。
【0048】
図1において、全体システム1は、モニタ2と、モニタ2に接続コードを介して接続する据置型の情報処理システム3と、アクセスポイント9とを含む。
【0049】
モニタ2は、表示手段の一例である家庭用テレビジョン受像機である。モニタ2は、スピーカ2aを備える。
【0050】
情報処理システム3は、光ディスク4と、情報処理装置本体5(以下本体5とも称する)と、コントローラ7a〜7d(以下、特にこれらのコントローラ7a〜7dを区別して説明する必要が無い場合には、単にコントローラ7と記す)とを含む。
【0051】
光ディスク4には、情報処理装置本体5において実行されるための情報処理プログラム(典型的には、ゲームプログラム)が記憶されている。
【0052】
モニタ2は、情報処理装置本体5から出力されるゲーム画像を表示する。モニタ2はスピーカ2aを有しており、スピーカ2aは、情報処理装置本体5から出力されるゲーム音声を出力する。
【0053】
情報処理装置本体5は、光ディスク4に記憶されたゲームプログラム等に基づいてゲーム処理等を実行する。
【0054】
コントローラ7には、複数の操作部(操作ボタン)が設けられている。そして、コントローラ7は、操作部に対する入力状態(各操作ボタンが押下されたか否か)を示す操作データを例えばBluetooth(登録商標)(第1無線通信規格)の技術を用いて情報処理装置本体5に送信する。
【0055】
アクセスポイント9は、例えばIEEE802.11の規格(第2無線通信規格)に準拠した方式により、情報処理装置本体5と無線LANによる通信(Wi−Fi通信)が可能に設けられている。特に、Bluetooth(第1無線通信規格)による通信の周波数帯2.4−2.5GHz帯と、実質的に同じ周波数帯を利用するIEEE802.11b、IEEE802.11g、IEEE802.11n等の規格(第2無線通信規格)において互いに干渉する可能性が生じる。
【0056】
[a2.情報処理装置本体のハードウェア構成]
図2は、実施形態1に基づく情報処理装置本体5のハードウエア構成を説明する図である。
【0057】
図2に示されるように、情報処理装置本体5の内部構成が示されている。
具体的には、情報処理装置本体5は、CPU(Central Processing Unit)10、システムLSI(Large Scale Integration)11、外部メインメモリ12、ROM/RTC(Read Only Memory/Real Time Clock)13、ディスクドライブ14、およびAV−IC(Audio Video−Integrated Circuit)15等を有する。
【0058】
システムLSI11には、CPU10の他、外部メインメモリ12、ROM/RTC13、ディスクドライブ14、およびAV−IC15が接続される。揮発性の外部メインメモリ12は、CPU10のワーク領域やバッファ領域として用いられる。ROM/RTC13は、情報処理装置本体5の起動用のプログラムが組み込まれるROM(いわゆるブートROM)と、時間をカウントするクロック回路(RTC)とを有する。ディスクドライブ14は、光ディスク4からプログラムデータやテクスチャデータ等を読み出し、後述する内部メインメモリ35または外部メインメモリ12に読み出したデータを書き込む。
【0059】
システムLSI11には、入出力プロセッサ(I/Oプロセッサ)31、GPU(Graphics Processor Unit)32、DSP(Digital Signal Processor)33、VRAM(Video RAM)34、および内部メインメモリ35が設けられる。
【0060】
GPU32は、CPU10からのグラフィクスコマンド(作画命令)に従って画像を生成する。なお、実施形態においては、情報処理装置本体5は、モニタ2に表示するゲーム画像を生成することがある。
【0061】
DSP33は、オーディオプロセッサとして機能し、内部メインメモリ35や外部メインメモリ12に記憶されるサウンドデータや音波形(音色)データを用いて、音声データを生成する。
【0062】
上記のように情報処理装置本体5において生成される画像および音声のうち、モニタ2に出力される画像データおよび音声のデータは、AV−IC15によって読み出される。AV−IC15は、AVコネクタ16を介して、読み出した画像データをモニタ2に出力するとともに、読み出した音声データをモニタ2に内蔵されるスピーカ2aに出力する。これによって、モニタ2に画像が表示されるとともにスピーカ2aから音が出力される。
【0063】
入出力プロセッサ31は、それに接続される構成要素との間でデータの送受信を実行したり、外部装置からのデータのダウンロードを実行したりする。入出力プロセッサ31は、フラッシュメモリ17、拡張コネクタ20、メモリカード用コネクタ21、通信モジュール28に接続される。
【0064】
情報処理装置本体5は、アクセスポイント9を介してインターネット等のネットワークに接続して外部情報処理装置(例えば他の情報処理装置や、各種サーバ等)と通信を行うことが可能である。すなわち、入出力プロセッサ31は、通信モジュール28およびアンテナ22を介してアクセスポイント9を経由してネットワークに接続し、ネットワークに接続される外部情報処理装置と通信することができる。フラッシュメモリ17には、情報処理装置本体5と外部情報処理装置との間で送受信されるデータの他、情報処理装置本体5を利用してプレイしたゲームのセーブデータ(処理の結果データまたは途中データ)が記憶されてもよい。また、フラッシュメモリ17には、ゲームプログラム等のプログラムが記憶されてもよい。
【0065】
また、情報処理装置本体5は、コントローラ7との間でのデータを送受信することが可能である。本例においては、情報処理装置本体5は、コントローラ7からの操作データを受信することが可能である。すなわち、入出力プロセッサ31は、アンテナ29および通信モジュール28を介して、コントローラ7から送信される操作データ等を受信し、内部メインメモリ35または外部メインメモリ12のバッファ領域に記憶(一時記憶)する。
【0066】
また、情報処理装置本体5は、拡張コネクタ20やメモリカード用コネクタ21を介して、他の機器や外部記憶媒体に接続することが可能である。
【0067】
情報処理装置本体5(例えば、前部主面)には、電源ボタン24、リセットボタン25、光ディスク4を脱着する投入口、および情報処理装置本体5の投入口から光ディスク4を取り出すイジェクトボタン26等が設けられている。
【0068】
なお、他の実施形態においては、情報処理装置本体5が備える各構成要素のうちでいくつかの構成要素は、情報処理装置本体5とは別体の拡張機器として構成されてもよい。このとき、拡張機器は、例えば拡張コネクタ20を介して情報処理装置本体5と接続されるようにしてもよい。
【0069】
[a3.コントローラ7のハードウェア構成]
図3は、実施形態1に基づくコントローラ7のハードウェア構成について説明する図である。
【0070】
図3に示されるように、コントローラ7は、ユーザインタフェースコントローラ(UIコントローラ)705、コーデックLSI706、スピーカ707、サウンドIC708、マイク709、無線モジュール710、アンテナ711、フラッシュメモリ713、電源IC714、電池715、およびバイブレータ719を備える。これらの電子部品は、電子回路基板上に実装されてハウジング内に収納される。
【0071】
UIコントローラ705は、各種の入出力部に対するデータの入出力を制御するための回路である。
【0072】
UIコントローラ705は、アナログスティック73、操作ボタン74(各操作ボタン)、およびバイブレータ719に接続される。また、UIコントローラ705は、コーデックLSI706と拡張コネクタ77とに接続される。また、UIコントローラ705には電源IC714が接続され、UIコントローラ705を介して各部に電力が供給される。電源IC714には内蔵の電池715が接続され、電力が供給される。また、電源IC714には、コネクタ等を介して外部電源から電力を取得可能な充電器716またはケーブルを接続することが可能であり、コントローラ7は、充電器716またはケーブルを用いて外部電源からの電力供給と充電とを行うことができる。
【0073】
アナログスティック73は、スティック部がスライドした(または傾倒した)方向および量を表すスティックデータをUIコントローラ705へ出力する。また、操作ボタン74は、各操作ボタン74に対する入力状況(押下されたか否か)を表す操作ボタンデータをUIコントローラ605へ出力する。
【0074】
バイブレータ719は、例えば振動モータやソレノイドであり、UIコントローラ705からバイブレータ719へ出力される制御指示に応じて、バイブレータ719が作動することによってコントローラ7に振動が発生する。
【0075】
UIコントローラ705は、上記の各構成要素から受け取ったスティックデータ、操作ボタンデータ、方位データ、加速度データ、および角速度データを含む操作データをコーデックLSI706に出力する。
【0076】
コーデックLSI706は、情報処理装置本体5へ送信するデータに対する圧縮処理、および情報処理装置本体5から送信されたデータに対する伸張処理を行う回路である。コーデックLSI706には、サウンドIC708、無線モジュール710およびフラッシュメモリ713が接続される。また、コーデックLSI706は、CPU717と内部メモリ718とを含む。例えば、コントローラ7は、ゲーム処理自体を行わない構成であるが、コントローラ7の管理や通信のための最小限のプログラムを実行する必要がある。一例として、電源投入時にフラッシュメモリ713に格納されたプログラムを内部メモリ718に読み出してCPU717が実行することで、コントローラ7が起動する。また、内部メモリ718の一部の領域は、CPU717の作業領域として使用される。
【0077】
サウンドIC708は、スピーカ707およびマイク709への音声データの入出力を制御する回路である。
【0078】
コーデックLSI706は、マイク709からの音声データ、およびUIコントローラ705からの操作データを、無線モジュール710を介して情報処理装置本体5へ送信する。実施形態では、コーデックLSI706は、音声データに対して、コーデックLSI27と同様の圧縮処理を行う。圧縮された音声データと、操作データとは、送信データとして無線モジュール710に出力される。無線モジュール710にはアンテナ711が接続されており、無線モジュール710はアンテナ711を介して情報処理装置本体5へ上記送信データを送信する。無線モジュール710は、情報処理装置本体5の通信モジュール28と同様の機能を有している。すなわち、無線モジュール710は、例えばBluetoothの規格を用いて情報処理装置本体5との間でデータの送受信を実行する。
【0079】
以上のように、コントローラ7から情報処理装置本体5へ送信される送信データには、操作データおよび音声データ等が含まれる。なお、拡張コネクタ67を介してコントローラ7に他の装置が接続される場合には、当該他の装置から受け取ったデータが上記送信データにさらに含まれていてもよい。
【0080】
また、上述のように、情報処理装置本体5からコントローラ7へは、圧縮された音声データが送信される。これらのデータは、アンテナ711および無線モジュール710を介してコーデックLSI706で受信される。コーデックLSI706は、受信した音声データを伸張する。伸張された音声データは、サウンドIC708へ出力され、当該音声データに応じた音がスピーカ707から出力される。
【0081】
また、情報処理装置本体5から受信されるデータに制御データが含まれる場合、コーデックLSI706およびUIコントローラ705は、制御データに従った制御指示を各部に行う。上述のように、制御データは、コントローラ7が備える各構成要素(実施形態では、各センサ702〜704およびバイブレータ719)に対する制御指示を表すデータである。実施形態では、制御データが表す制御指示としては、上記各構成要素を動作させたり、動作を休止(停止)させたりする指示が考えられる。すなわち、ゲームで使用しない構成要素については電力消費を抑えるために休止させてもよく、その場合、コントローラ7から情報処理装置本体5へ送信される送信データには、休止した構成要素からのデータが含まれないようにする。
【0082】
なお、コントローラ7には、加速度センサおよびジャイロセンサを設けた構成とすることも可能である。加速度センサによって検出された加速度を示す加速度データと、ジャイロセンサによって検出された角速度を示す角速度データとを情報処理装置本体5に送信するようにしても良い。情報処理装置本体5では、当該加速度データおよび/または角速度データに基づいて、コントローラ7の向きや動きを算出することも可能である。
【0083】
[B.通信処理の概要]
[b1.情報処理装置本体5の機能ブロック構成]
図4は、実施形態1に基づく情報処理装置本体5の通信処理を実行する機能ブロックを説明する図である。
【0084】
図4に示されるように、情報処理装置本体5は、通信制御部300と、アプリケーション実行部200とを含む。各機能ブロックはCPU10がフラッシュメモリ17等に格納された各種プログラムを実行することにより実現する機能である。
【0085】
通信制御部300は、通信モジュール28を介してコントローラ7とのBluetooth通信を制御する。また、通信制御部300は、通信モジュール28を介してアクセスポイント9とのWi−Fi通信を制御する。
【0086】
通信制御部300は、タイミング制御部100と、モード設定部112と、ローカル端末検出部110と、台数管理部108とを含む。
【0087】
タイミング制御部100は、通信モジュール28を介する通信区間のタイミングを制御する。
【0088】
タイミング制御部100は、タイミング調整部102と、比較部103と、基準タイミング設定部104とを含む。
【0089】
タイミング調整部102は、コントローラ7(以下、総括してローカル端末とも称する)との間で通信モジュール28を介して実行するBluetooth通信を実行する通信区間を調整する。
【0090】
基準タイミング設定部104は、通信を開始する基準となる基準タイミングを設定する。
【0091】
比較部103は、通信区間を調整するに際し、通信区間同士を比較し、比較結果をタイミング調整部102に出力する。
【0092】
なお、本例においては、タイミング制御部100の機能として、タイミング調整部102と、比較部103と、基準タイミング設定部104とを含む構成について説明したが、タイミング調整部102が比較部103の機能を含む構成としても良いし、あるいは、タイミング調整部102が基準タイミング設定部104の機能を含む構成としても良いし、タイミング調整部102が比較部103、基準タイミング設定部104の機能を含む構成とすることも可能である。
【0093】
モード設定部112は、Bluetooth通信を実行する場合の各種モード(アクティブモード、スニフモード等)を設定する。
【0094】
Bluetooth通信において接続を確立するためには、送信側(本体側)と受信側(ローカル端末)とは、一般に、時間と周波数の双方において同期しなければならない。
【0095】
この点で、Bluetooth通信におけるアクティブモードでは、ローカル端末は常にウェークアップ状態である。
【0096】
一方、他の装置との間で間欠的に通信を行なうような無線通信方式(例えば、他の装置と通信を行う通信状態と通信を行わない省電力状態とを交互に繰り返すような無線通信方式)も存在する。そのような無線通信方式の一つとして、例えば、スニフモードによる無線通信がある。スニフモードでは、低消費電力を実現するためにローカル端末は、5ms〜15msごとに短い時間区間のあいだウェークアップ状態になる。この時間区間の間に、本体側はポーリング(POLLING)パケットを送信する。
【0097】
ローカル端末はこのパケットを使用して自分のクロックを再同期させることができる。本体側とローカル端末とは、再同期のためのパケットを定期的に交換することにより、時間および周波数における同期を維持することができる。これにより周波数ホッピング通信が可能となる。
【0098】
ローカル端末検出部110は、接続を要求するローカル端末(コントローラ7)を検出する。
【0099】
台数管理部108は、通信処理を実行するローカル端末の台数を管理する。
アプリケーション実行部200は、フラッシュメモリ17に格納されているアプリケーション等に基づく処理を実行する。フラッシュメモリ17に限られず光ディスク4に格納されたアプリケーション等に基づく処理を実行するようにしても良い。
【0100】
[b2.無線通信の概要]
図5は、実施形態1に基づく無線通信の概要を説明する図である。
【0101】
図5に示されるように、本例においては、ある基準タイミングを設定した場合に、一定周期の基準タイミングが設定されて、基準タイミングを基準としてBluetooth通信による第1無線通信を実行する。
【0102】
Bluetooth通信による第1無線通信を調整することにより、空き区間が生じる。
【0103】
空き区間が生じることにより、当該空き区間において他の無線通信規格(例えばWifi)を利用することが可能である。これにより、Bluetooth通信による第1無線通信と他の無線通信規格とが相互に干渉し合うことがなくデータ衝突を回避し、通信品質が良好な情報処理装置を実現することが可能である。
【0104】
[b3.通信設定テーブル]
図6は、実施形態1に基づくスニフモードにおける通信設定情報に関するテーブルを説明する図である。
【0105】
図6には、テーブルには、スニフモードにおけるBluetooth通信を実行する場合の複数の通信設定情報が示されている。本例においては、11個の通信設定情報が設けられており、それぞれに識別子が設けられている。具体的には、識別子TSI0〜TSI10(総括して識別子TSI(Transmission scheme index(table))とも称する)が割り当てられた通信設定情報が示されている。
【0106】
スニフモードでは、本体側からローカル端末に対してポーリング(POLLING)パケットを送信し、ローカル端末は、当該ポーリング(POLLING)パケットを受信後、本体側にデータを送信する。スニフモードでは、識別子TSIに従って本体側からローカル端末に対してポーリング(POLLING)パケットとともに送信するデータ量が規定されている。本例においては、本体側からローカル端末へのダウンリンクのスロット数として規定している。なお、当該スロット数は送信が可能な最大スロット数である。
【0107】
一方で、ローカル端末側については、識別子TSIに従ってローカル端末から本体側に送信するデータ量が規定されている。本例においては、ローカル端末から本体側へのアップリングのスロット数として規定している。なお、当該スロット数は送信が可能な最大スロット数である。
【0108】
識別子TSI0に対応する通信設定情報は、接続可能なローカル端末の数(接続可能最大端末数)が「2」、スロット数に関して、ローカル端末から本体側へのデータのアップリンクのスロット数(通信可能最大スロット数)が「3」、本体側からローカル端末へのデータのダウンリンクのスロット数(通信可能最大スロット数)が「3」、周期的な通信間隔であるスニフインターバルが「10」(ms)のデータを含む。なお、1スロットは、625μsの区間に設定されている。
【0109】
識別子TSI1に対応する通信設定情報は、接続可能最大端末数が「4」、アップリンクのスロット数が「1」、ダウンリンクのスロット数が「1」、スニフインターバルが「5」(ms)のデータを含む。
【0110】
識別子TSI2に対応する通信設定情報は、接続可能最大端末数が「4」、アップリンクのスロット数が「1」、ダウンリンクのスロット数が「3」、スニフインターバルが「10」(ms)のデータを含む。
【0111】
識別子TSI3に対応する通信設定情報は、接続可能最大端末数が「4」、アップリンクのスロット数が「1」、ダウンリンクのスロット数が「5」、スニフインターバルが「15」(ms)のデータを含む。
【0112】
識別子TSI4に対応する通信設定情報は、接続可能最大端末数が「4」、アップリンクのスロット数が「3」、ダウンリンクのスロット数が「1」、スニフインターバルが「10」(ms)のデータを含む。
【0113】
識別子TSI5に対応する通信設定情報は、接続可能最大端末数が「4」、アップリンクのスロット数が「3」、ダウンリンクのスロット数が「3」、スニフインターバルが「15」(ms)のデータを含む。
【0114】
識別子TSI6に対応する通信設定情報は、接続可能最大端末数が「4」、アップリングのスロット数が「5」、ダウンリンクのスロット数が「1」、スニフインターバルが「15」(ms)のデータを含む。
【0115】
識別子TSI7に対応する通信設定情報は、接続可能最大端末数が「6」、アップリンクのスロット数が「1」、ダウンリンクのスロット数が「3」、スニフインターバルが「15」(ms)のデータを含む。
【0116】
識別子TSI8に対応する通信設定情報は、接続可能最大端末数が「6」、アップリンクのスロット数が「3」、ダウンリンクのスロット数が「1」、スニフインターバルが「15」(ms)のデータを含む。
【0117】
識別子TSI9に対応する通信設定情報は、接続可能最大端末数が「8」、アップリンクのスロット数が「1」、ダウンリンクのスロット数が「1」、スニフインターバルが「10」(ms)のデータを含む。
【0118】
識別子TSI10に対応する通信設定情報は、接続可能最大端末数が「8」、アップリンクのスロット数が「1」、ダウンリンクのスロット数が「1」、スニフインターバルが「15」(ms)のデータを含む。
【0119】
当該通信設定情報を指定することにより、スニフモードにおける同期通信方式が設定される。識別子TSIの指定は、アプリケーション実行部200からの指示により実行される。
【0120】
識別子TSIは、アプリケーションの種別およびイベント発生の有無等に基づいて指定される。
【0121】
識別子TSI0〜TSI10の通信設定情報は、接続可能最大端末数、スロット数、スニフインターバルがそれぞれ異なる。
【0122】
なお、テーブルに記載された「最大接続台数」「スロット数」「スニフインターバル」の各値は、基準タイミングを基準としたスロットが、次の基準タイミングによるスロットと重ならないように設定されている。
【0123】
アプリケーションの種別等に従って、接続可能最大端末数を増やしたい場合には、スロット数を少なく、スニフインターバルを長くする識別子TSIに設定することが可能である。一方、スニフインターバルを短く設定したい場合には、スロット数を少なく、接続可能最大端末数が少ない識別子TSIに設定するようにしてもよい。
【0124】
[b4.スロットの設定]
図7は、スニフモードにおけるBluetooth通信のタイミング調整を説明する図である。
【0125】
図7に示されるように、基準タイミングとしてグループアンカーポイントGAPが設定される。本例において、グループアンカーポイントGAPは、本体側と複数のローカル端末とが通信処理する際の基準タイミングである。このグループアンカーポイントGAPを基準タイミングとして、各ローカル端末と通信するタイミングが規定される。
【0126】
本例においては、当該グループアンカーポイントGAPを基準としてコントローラAの通信区間が設定される。本例においては、グループアンカーポイントGAPを基準として1、2スロット目がコントローラAの通信区間に設定される。
【0127】
次に、コントローラBが参加する。グループアンカーポイントGAPに従ってコントローラAの通信区間に隣接する形でコントローラBの通信区間が設定される。本例においては、グループアンカーポイントGAPを基準として3、4スロット目がコントローラBの通信区間に設定される。すなわち、コントローラAの通信区間の終了時点と、コントローラBの通信区間の開始時点とが実質的に連続になるようにタイミング調整される。
【0128】
なお、実質的にとは終了時点と開始時点とが完全に一致している場合のみならず、すこしのタイムラグがある場合も含む。
【0129】
次に、コントローラCが参加する。グループアンカーポイントGAPに従って、コントローラBの通信区間に隣接する形でコントローラCの通信区間が設定される。本例においては、グループアンカーポイントGAPを基準として、5、6スロット目がコントローラCの通信区間に設定される。すなわち、コントローラBの通信区間の終了時点と、コントローラCの通信区間の開始時点とが実質的に連続になるようにタイミング調整される。
【0130】
したがって、コントローラA〜Cは、グループアンカーポイントGAPにしたがって、通信区間がそれぞれ連続的に設定されるように配置されるためスニフモードにおけるBluetooth通信で実行されるローカル端末の通信区間がひとまとまりに設定される。
【0131】
これにより、残りの通信区間を他の通信における通信区間として利用することが可能となる。これにより、Bluetooth通信と他の通信との干渉を容易に回避し、効率的なデータ通信を実行することが可能となる。
【0132】
なお、本例においては、グループアンカーポイントGAPを基準に設定して、当該グループアンカーポイントGAPを基準に各コントローラの通信区間を設定する方式について説明するが、グループアンカーポイントGAPを基準にするのではなく、各コントローラ毎にアンカーポイントを基準として設定して、それぞれの各アンカーポイントに従って通信区間を設定することも可能である。
【0133】
また、本例においては、各コントローラA〜Cについて、タイミング調整により設定された通信区間を用いて本体側と通信する構成について説明するが、設定された通信区間を全て用いてデータ通信する必要はなく、データ通信するデータ量が少ない場合には2スロットの通信区間のうちの一部の通信区間、例えば、1スロットのみを用いて本体側とデータ通信する構成としても良い。他の例についても同様である。
【0134】
[C.フローの説明]
[c1.情報処理装置本体5のメイン通信処理]
情報処理装置本体5(本体側)のメイン通信処理について説明する。
【0135】
図8は、実施形態1に基づく情報処理装置本体5(本体側)のメイン通信処理について説明するフロー図である。
【0136】
図8を参照して、本体側は、探索処理を実行する(ステップS0)。ローカル端末検出部110は、接続を要求するローカル端末を検出する探索処理を実行する。探索処理は、本体側の通信していない区間(空きスロットの区間)で実行する。具体的には、ローカル端末検出部110は、空きスロットの区間でページスキャン(Page scan)を実行する。ローカル端末検出部110は、ページスキャン(Page scan)中にローカル端末からのページ(Page)を受信するか否かを判断する。たとえば、参加するコントローラ7の操作ボタンを押すと本体側にページ(Page)が送信される。
【0137】
ローカル端末検出部110は、ページスキャン(Page scan)中にコントローラ7からのページ(Page)を受信すると、受信確認として応答パケットをコントローラ7に送信する。
【0138】
コントローラ7は、応答パケットを受信した場合、Bluetoothアドレスと、クロック情報とを含むFHS(Frequency Hop Synchronization)パケットを本体側に送信する。
【0139】
次に、本体側は、ローカル端末を発見したか否かを判断する(ステップS1)。ローカル端末検出部110は、FHSパケットを受信することによりコントローラ7を発見したと判断する。ローカル端末検出部110は、発見した旨をモード設定部112に通知する。一方、ステップS1において本体側は、コントローラを発見しないと判断した場合(ステップS1においてNO)には、ステップS0の探索処理を継続する。
【0140】
ステップS1において、本体側は、ローカル端末を発見したと判断した場合(ステップS1においてYES)には、ローカル端末を特定するためのスレーブ識別子を発行する(ステップS2)。具体的には、モード設定部112は、3ビットのスレーブ識別子を発行する。
【0141】
次に、本体側は、スレーブ識別子を発行した後、通信接続を実行する(ステップS3)。具体的には、モード設定部112は、ローカル端末にスレーブ識別子を含むIDパケットを送信する。ローカル端末は、本体側からのIDパケットに対して応答する。
【0142】
次に、本体側は、ローカル端末からの応答があるかどうかを判断する(ステップS5)。モード設定部112は、ローカル端末からの応答を受信したかどうかを判断する。
【0143】
モード設定部112は、ローカル端末からIDパケットに対する応答を受信すると、本体側自身のBluetoothアドレスと、クロック情報とを含むFHSパケットをローカル端末に送信する。これにより、本体側とローカル端末との間での同期通信の準備が完了する。すなわち、周波数ホッピング通信が可能となる。
【0144】
また、必要に応じてこの段階でいわゆるスレーブ・マスタロールスイッチの処理を行い、コントローラ7をスレーブとし、本体(すなわち、情報処理装置本体5)をマスタとして設定する。
【0145】
ステップS5において、本体側は、ローカル端末からの応答があると判断した場合(ステップS5においてYES)には、ローカル端末との間でアクティブモードにおける通信処理を実行する(ステップS7)。
【0146】
モード設定部112は、応答があったローカル端末との関係において初期状態の通信モードとしてアクティブモードに設定し、通信処理を実行する。本例においては、複数のローカル端末と通信する場合においてそれぞれのローカル端末との関係において通信モードを設定することが可能である。したがって、本体側は、あるローカル端末とはアクティブモードにおける通信モードであり、別のローカル端末とは別のモードにおける通信モードとなり得る。
【0147】
アクティブモードにおける通信処理は、ローカル端末が常にウェークアップ状態であり、本体側からのポーリング(POLLING)パケットに対して、ローカル端末がパケットを送信する通信処理である。
【0148】
一方、ステップS5において、本体側は、ローカル端末からの応答がないと判断した場合(ステップS5においてNO)には、処理を終了する(エンド)。
【0149】
次に、本体側は、通信が終了したかどうかを判断する(ステップS8)。
ステップS8において、本体側は、通信が終了したと判断した場合(ステップS8においてYES)には、処理を終了する(エンド)。
【0150】
一方、ステップS8において、本体側は、通信が終了していないと判断した場合(ステップS8においてNO)には、識別子TSIの指示があるかどうかを判断する(ステップS9)。モード設定部112は、アプリケーション実行部200からスニフモードを指定する
図6で説明した識別子TSIの指示があるかどうかを判断する。
【0151】
ステップS9において、本体側は、識別子TSIの指示があると判断した場合(ステップS9においてYES)には、スニフ(Sniff)モードに移行する処理を実行する(ステップS10)。スニフモードに移行する処理の詳細については後述する。
【0152】
一方、ステップS9において、本体側は、識別子TSIの指示がないと判断した場合(ステップS9においてNO)には、ステップS7に戻り、アクティブモードにおける通信処理を継続する。
【0153】
[c2.情報処理装置本体5のスニフモードに移行する処理]
図9は、実施形態1に基づく情報処理装置本体5のスニフモードに移行する処理について説明するフロー図である。
【0154】
図9に示されるように、本体側は、識別子TSIに従って通信設定する(ステップS12)。具体的には、モード設定部112は、識別子TSIに従う通信設定情報に基づいて通信設定する。たとえば、モード設定部112は、識別子TSI0がアプリケーション実行部200から指示された場合には、
図6で説明したように、接続可能なローカル端末の数(接続可能端末数)が「2」、スロット数に関して、ローカル端末から本体側へのデータのアップリンク数が「3」、本体側からローカル端末へのデータのダウンリンク数が「3」、周期的な通信間隔であるスニフインターバルが「10」(ms)となるように通信設定する。モード設定部112は、接続可能なローカル端末の数(接続可能端末数)に関する情報を台数管理部108に通知する。台数管理部108は、当該通知を受けて接続可能端末数を管理する。
【0155】
次に、本体側は、タイミングを設定する(ステップS13)。モード設定部112は、タイミング制御部100に指示し、タイミング制御部100は、ローカル端末との間の通信のタイミングを制御する。タイミング設定の詳細については後述する。
【0156】
次に、本体側は、スニフ要求をローカル端末に送信する(ステップS14)。モード設定部112は、スニフ要求をローカル端末に送信する。スニフ要求のデータの詳細については後述する。スニフ要求に従って、アクティブモードのローカル端末は、スニフモードに設定されて本体側とスニフモードにおける同期通信が可能となる。また、既にスニフモードにおける同期通信を実行しているローカル端末は、スニフ要求に従って識別子TSIデータ、タイミング情報等が更新され、更新されたスニフモードにおける同期通信が可能となる。
【0157】
次に、本体側は、ローカル端末からの応答があるかどうかを判断する(ステップS15)。モード設定部112は、ローカル端末からの応答を受信したかどうかを判断する。
【0158】
ステップS15において、本体側は、ローカル端末からの応答があると判断した場合(ステップS15においてYES)には、スニフモードに設定する(ステップS16)。
【0159】
モード設定部112は、応答があったローカル端末との関係において通信モードをアクティブモードからスニフモードに変更する。本例においては、複数のローカル端末と通信する場合においてそれぞれのローカル端末との関係において通信モードを設定することが可能である。したがって、本体側は、あるローカル端末とはアクティブモードにおける通信モードであり、別のローカル端末とはスニフモードにおける同期通信モードとなり得る。
【0160】
次に、本体側とローカル端末との間でスニフモードにおける同期通信処理を実行する(ステップS17)。スニフモードにおける同期通信処理は、低消費電力を実現する通信処理である。低消費電力を実現するためにローカル端末は、5〜15msごとに短い時間区間のあいだウェークアップ状態になる。この時間区間の間に、本体側はポーリング(POLLING)パケットを送信する。ローカル端末は、指定された通信設定情報に従うスロット数のパケットを送信する。
【0161】
次に、本体側は、スニフ解除要求の指令があるかどうかを判断する(ステップS18)。モード設定部112は、アプリケーション実行部200等からアクティブモードの設定を指示するスニフ解除要求の指令を受けたかどうかを判断する。
【0162】
ステップS18において、本体側は、スニフ解除要求の指令があると判断した場合(ステップS18においてYES)には、スニフ解除要求をローカル端末に送信する(ステップS19A)。モード設定部112は、スニフ解除要求を指定されたローカル端末に送信する。
【0163】
次に、本体側は、ローカル端末からの応答があるかどうかを判断する(ステップS19B)。モード設定部112は、ローカル端末からの応答があるかどうかを判断する。
【0164】
ステップS19Bにおいて、本体側は、ローカル端末の応答が有ると判断した場合(ステップS19BにおいてYES)には、処理「P」に進む。すなわち、
図8のステップS7に戻る。モード設定部112は、ローカル端末の応答が有ると判断した場合には、指定されたローカル端末との関係においてアクティブモードに設定する。全てのローカル端末が指定された場合に、全てのローカル端末の応答が有る場合には、全てのローカル端末との関係において、アクティブモードに設定する。
【0165】
そして、ステップS7で説明したように、本体側は、ローカル端末との間でアクティブモードにおける通信処理を実行する。
【0166】
一方、ステップS19Bにおいて、本体側は、ローカル端末の応答が無いと判断した場合(ステップS19BにおいてNO)には、処理を終了する(エンド)。
【0167】
一方、ステップS18において、本体側は、スニフ解除要求の指令がないと判断した場合(ステップS18においてNO)には、ステップS17に戻り、スニフモードにおける同期通信処理を継続する。
【0168】
一方、ステップS15において、本体側は、ローカル端末からの応答がないと判断した場合(ステップS15においてNO)には、スニフモードに入ることなく、処理「P」に進む。すなわち、
図8のステップS7に戻る。モード設定部112は、スニフモードに移行する処理を終了する。
【0169】
[c3.情報処理装置本体5のタイミング設定]
図10は、実施形態1に基づく情報処理装置本体5のタイミング設定について説明するフロー図である。
【0170】
図10に示されるように、本体側は、通信状態を確認する(ステップS40)。タイミング調整部102は、少なくとも1つのローカル端末と通信している通信状態を確認する。
【0171】
次に、本体側は、スニフモードにおける同期通信処理(スニフ通信)が既に設定されているか否かを判断する(ステップS41)。具体的には、タイミング調整部102は、スニフモードにおける同期通信処理を実行しているローカル端末が既にあるか否かを判断する。
【0172】
ステップS41において、本体側は、スニフモードにおける同期通信処理が設定されていないと判断した場合(ステップS41においてNO)には、スニフモードを実行する場合の基準タイミングとなるグループアンカーポイントを設定する(ステップS42)。基準タイミング設定部104は、グループアンカーポイントを設定する。
【0173】
次に、本体側は、識別子TSIに基づいて通信区間を設定する(ステップS43)。タイミング調整部102は、識別子TSIに基づく通信区間を設定する。たとえば、タイミング調整部102は、アプリケーション実行部200から識別子TSI0が指定されている場合には、アップリンク数「3」、ダウンリンク数「3」の合計6スロット区間を通信区間として設定する。
【0174】
そして、ステップS45に進む。
一方、ステップS41において、本体側は、スニフモードにおける同期通信処理が設定されていると判断した場合(ステップS41においてYES)には、識別子TSIに基づいて既に設定されている最後の通信区間の後に通信区間を設定する(ステップS44)。
【0175】
タイミング調整部102は、スニフモードにおける同期通信処理を実行しているローカル端末が既にあると判断した場合、既に設定されている最後の通信区間の後に通信区間を設定する。たとえば、最後の通信区間と連続するように、例えば、アプリケーション実行部200から識別子TSI0が指定されている場合には、アップリンク数「3」、ダウンリンク数「3」の合計6スロット区間を通信区間として設定する。
【0176】
そして、ステップS45に進む。
ステップS45において、本体側は、スニフモードにおける同期通信処理において、通信区間が未設定の他の装置が有るか否かを判断する。具体的には、タイミング調整部102は、通信区間が未設定の他の装置が有るか否かを判断する。
【0177】
ステップS45において、本体側は、通信区間が未設定の他の装置が有ると判断した場合(ステップS45においてYES)には、ステップS41に戻り、上記と同様の処理を繰り返す。すなわち、通信区間を設定する。なお、通信区間が未設定の他の装置には、アクティブモードの通信処理を実行しているローカル端末、指示された識別子TSIと異なる識別子TSIに基づいてスニフモードでの同期通信処理を実行しているローカル端末の両方が含まれる。
【0178】
一方、ステップS45において、本体側は、通信区間が未設定の他の装置が無いと判断した場合、(ステップS45においてNO)には、処理を終了する(リターン)。
【0179】
当該タイミング設定に基づき、グループアンカーポイントの設定とともに、各ローカル端末の通信区間の通信区間が設定される。
【0180】
図7の例においては、識別子TSI9(アップリンクのスロット数「1」、ダウンリンク数「1」)が指定されている場合が示されている。コントローラAのタイミング設定の際に、グループアンカーポイントGAPが設定される。そして、グループアンカーポイントGAPを基準としてコントローラAについてスロット数「2」の通信区間が設定される。本例においては、グループアンカーポイントGAPを基準として1、2スロット目がコントローラAの通信区間に設定される。
【0181】
次に、コントローラBについて、グループアンカーポイントGAPを基準として、コントローラAの通信区間の後にスロット数「2」の通信区間が設定される。本例においては、グループアンカーポイントGAPを基準として3、4スロット目がコントローラBの通信区間に設定される。
【0182】
次に、コントローラCについて、グループアンカーポイントGAPを基準として、コントローラBの通信区間の後にスロット数「2」の通信区間が設定される。本例においては、グループアンカーポイントGAPを基準として、5、6スロット目がコントローラCの通信区間に設定される。
【0183】
当該処理によりグループアンカーポイントGAPを基準として複数のローカル端末のスニフモードにおける同期通信処理が実行される。具体的には、スニフモードにおけるBluetooth通信で実行されるコントローラA〜Cの通信区間がひとまとまりに設定される。
【0184】
次に、実施形態1に基づく本体側からローカル端末に送信するスニフ要求のデータについて説明する。
【0185】
図11は、実施形態1に基づくスニフ要求のデータについて説明する図である。
図11に示されるように、スニフ要求のデータは、スレーブ識別子データ201と、識別子TSIデータ202と、スニフモードデータ203と、タイミング情報204とを含む。
【0186】
スレーブ識別子データ201は、対象となるローカル端末を指定するためのものである。当該スレーブ識別子データ201を確認することにより自装置に宛てられたパケットデータであるか、他装置に宛てられたパケットデータかを識別することが可能である。
【0187】
識別子TSIデータ202は、
図6で説明した識別子TSIの番号を指定するものである。
【0188】
ローカル端末においても、
図6のテーブルがフラッシュメモリ613あるいは713等に格納されている。したがって、ローカル端末では、識別子TSIデータ202に従って、フラッシュメモリ613あるいは713等に格納されているテーブルから指定された通信設定情報を取得する。ローカル端末は、取得した指定された通信設定情報に基づいて、スロット数、スニフインターバルを設定する。
【0189】
タイミング情報204は、基準タイミングとなるグループアンカーポイントGAPと、グループアンカーポイントGAPからの同期タイミングに関する情報である。このタイミング情報は、上記で説明したタイミング調整部102により設定された通信区間に基づいて設定される。
【0190】
本体側およびローカル端末でともに同じ識別子TSIを用いて通信設定情報を指定することが可能であるため、簡易にスロット数およびスニフインターバル等を設定することが可能である。
【0191】
[c4.ローカル端末のメイン通信処理]
ローカル端末のメイン通信処理について説明する。ローカル端末としては、コントローラ7が含まれる。
【0192】
図12は、実施形態1に基づくローカル端末におけるメイン通信処理ついて説明するフロー図である。
【0193】
図12を参照して、ローカル端末は、探索処理を実行する(ステップS20)。具体的には、ローカル端末は、ページ(Page)を送信する。たとえば、通信に参加するコントローラ7の操作ボタンを押すと本体側にページ(Page)が送信される。
【0194】
次に、ローカル端末は、本体側が発見されたかどうかを判断する(ステップS21)。ローカル端末は、本体側から送信される応答パケットを受信したかどうかを判断し、本体側からの応答パケットを受信したと判断した場合には、本体側を発見したと判断する。
【0195】
ステップS21において、ローカル端末は、本体側が発見されないと判断した場合(ステップS21においてNO)には、ステップS20に戻り、探索処理を継続する。
【0196】
一方、ステップS21において、ローカル端末は、本体側が発見されたと判断した場合(ステップS21においてYES)には、接続要求をする(ステップS22)。具体的には、ローカル端末は、本体側にBluetoothアドレスと、クロック情報とを含むFHS(Frequency Hop Synchronization)パケットを送信する。
【0197】
次に、ローカル端末は、スレーブ識別子を受信したかどうかを判断する(ステップS23)。ローカル端末は、本体側で発行されたスレーブ識別子を含むIDパケットを受信したかどうかを判断する。
【0198】
ステップS23において、ローカル端末は、スレーブ識別子を受信したと判断した場合(ステップS23においてYES)には、通信接続を実行する(ステップS24)。
【0199】
次に、ローカル端末は、スレーブ識別子を含むIDパケットを受信したと判断した場合に応答を送信する(ステップS26)。ローカル端末は、本体側からのIDパケットを受信したと判断した場合には、応答信号を本体側に送信する。
【0200】
ローカル端末は、本体側からのBluetoothアドレスと、クロック情報とを含むFHSパケットを受信する。これにより、本体側とローカル端末との間での同期通信の準備が完了する。すなわち、周波数ホッピング通信が可能となる。
【0201】
また、必要に応じてこの段階でいわゆるスレーブ・マスタロールスイッチの処理を行い、コントローラ7をスレーブとし、本体(すなわち、情報処理装置本体5)をマスタとして設定する。
【0202】
一方、ステップS23において、ローカル端末は、スレーブ識別子を受信しないと判断した場合(ステップS23においてNO)には、処理を終了する(エンド)。
【0203】
次に、ローカル端末は、本体側とアクティブモードにおける通信処理を実行する(ステップS28)。アクティブモードにおける通信処理は、ローカル端末が常にウェークアップ状態である。ローカル端末は、本体側からのポーリング(POLLING)パケットに対して、所定のパケットを送信する。
【0204】
次に、ローカル端末は、通信が終了したかどうかを判断する(ステップS29)。
ステップS29において、ローカル端末は、通信が終了したと判断した場合(ステップS29においてYES)には、処理を終了する(エンド)。
【0205】
一方、ステップS29において、ローカル端末は、通信が終了していないと判断した場合(ステップS29においてNO)には、スニフ要求があるかどうかを判断する(ステップS30)。具体的には、ローカル端末は、本体側から
図11で説明したスニフ要求のデータを受信したか否かを判断する。
【0206】
ステップS30において、ローカル端末は、スニフ要求があると判断した場合(ステップS30においてYES)には、スニフモードに移行する処理を実行する(ステップS31)。ローカル端末は、スニフ要求のデータを受信した場合には、通信モードとしてスニフモードに移行する処理を実行する。スニフモードについては後述する。
【0207】
一方、ステップS30において、ローカル端末は、スニフ要求がないと判断した場合(ステップS30においてNO)には、ステップS28に戻り、アクティブモードにおける通信処理を継続する。ローカル端末は、スニフ要求のデータを受信しない場合には、通信モードとしてアクティブモードにおける通信処理を継続する。
【0208】
[c5.ローカル端末のスニフモードに移行する処理]
図13は、実施形態1に基づくローカル端末のスニフモードに移行する処理について説明するフロー図である。
【0209】
図13に示されるように、ローカル端末は、スニフ要求があった場合には応答する(ステップS32)。ローカル端末は、本体側からのスニフ要求を受信したと判断した場合には、応答信号を本体側に送信する。
【0210】
次に、ローカル端末は、スニフモードに設定する(ステップS33)。ローカル端末は、
図11で説明したスニフ要求に従って通信モードをスニフモードに設定する。
【0211】
また、ローカル端末は、スニフ要求に含まれる識別子TSIデータに基づいて、スロット数、スニフインターバル等を設定する。
【0212】
なお、本体側とローカル端末との間で以降使用されるスロット数が予め共有されている場合、あるいは少なくとも本体側でこれから使用するスロット数が予め把握できている場合は、識別子TSIデータをスニフ要求に含める必要は無く、少なくともスニフインターバルを示す情報をスニフ要求に含めておくようにすることも可能である。
【0213】
また、ローカル端末は、スニフ要求に含まれるグループアンカーポイントGAPからのタイミング情報に基づいてスニフモードにおける通信処理を実行するためのタイミングを設定する。
【0214】
次に、ローカル端末は、スニフモードにおける同期通信処理を実行する(ステップS34)。
【0215】
スニフモードにおける同期通信処理は、低消費電力を実現するためにローカル端末は、5〜15msごとに短い時間区間のあいだウェークアップ状態になる。この時間区間の間に、本体側はポーリング(POLLING)パケットを送信する。ローカル端末は、本体側からの指定された通信設定情報に従うスロット数(あるいは、予め本体側と共有した最大スロット数)のポーリング(POLLING)パケットを受信するとともに、通信設定情報に従うスロット数のパケットを送信する。
【0216】
次に、ローカル端末は、スニフ解除要求があるかどうかを判断する(ステップS35)。具体的には、ローカル端末は、スニフモードを終了してアクティブモードに設定するための本体側から送信されるスニフ解除要求を受信したかどうかを判断する。
【0217】
ステップS35において、ローカル端末はスニフ解除要求があると判断した場合(ステップS35においてYES)には、応答する(ステップS36)。ローカル端末は、本体側からのスニフ解除要求を受信したと判断した場合には、応答信号を本体側に送信する。
【0218】
そして、次に、処理「Q」に進む。すなわち、
図12のステップS28に戻り、ローカル端末は、スニフモードから初期状態であるアクティブモードに変更して、アクティブモードにおける通信処理を実行する。以降の処理は上述したのと同様である。
【0219】
一方、ステップS35において、ローカル端末は、スニフ解除要求がないと判断した場合(ステップS35においてNO)には、ステップS34に戻り、スニフモードにおける同期通信処理を継続する。
(実施形態2)
[D.複数の識別子TSIの組み合わせ]
実施形態2に基づくスニフモードのBluetooth通信における識別子TSIの組み合わせについて説明する。
【0220】
上記の実施形態においては、ローカル端末の一例としてコントローラ7について説明したが、コントローラ7に限られず、他の種別の端末装置をローカル端末としてスニフモードのBluetooth通信を実行することも可能である。
【0221】
その際、コントローラ7と他の種別の端末装置とでは機能が異なるため、スニフモードのBluetooth通信を実行する場合、取り扱うデータ量に応じて識別子TSIを設定することが望ましい。すなわち、コントローラ7と、他の種別の端末装置とで、識別子TSIを別々に設定することが望ましい。
【0222】
図14は、実施形態2に基づく種別が異なる識別子TSIの組み合わせパターンについて説明する図である。
【0223】
図14に示されるにように、組み合わせパターンとして8個の組合せパターンが示されている。2種類のローカル端末にそれぞれ識別子TSIを設定する場合が示されている。
【0224】
一例としてローカル端末「1」は他の種別の端末装置、ローカル端末「2」は、コントローラ7とする場合について説明する。
【0225】
なお、これらの組み合わせパターンは、スニフインターバル[ms]が同一である組み合わせである。これにより同一のグループアンカーポイントGAPを用いた通信処理が可能であり、ローカル端末の通信区間をひとまとまりに設定することが可能である。
【0226】
これにより、通信区間を一まとまりとすることにより、残りの通信区間を他の通信における通信区間として利用することが可能となる。これにより、Bluetooth通信と他の通信との干渉を容易に回避し、効率的なデータ通信を実行することが可能となる。
【0227】
具体的には、第1の組合せパターンは、識別子TSI0と識別子TSI9とがそれぞれ組合されるパターンである。第2の組合せパターンは、識別子TSI2と識別子TSI9とが組合せられるパターンである。第3の組合せパターンは、識別子TSI4と識別子TSI9とが組合せられるパターンである。第4の組合せパターンは、識別子TSI3と識別子TSI10とが組合せられるパターンである。第5の組合せパターンは、識別子TSI5と識別子TSI10とがそれぞれ組合されるパターンである。第6の組合せパターンは、識別子TSI6と識別子TSI10とが組合せられるパターンである。第7の組合せパターンは、識別子TSI7と識別子TSI10とが組合せられるパターンである。第8の組合せパターンは、識別子TSI8と識別子TSI10とが組合せられるパターンである。
【0228】
そして、スニフインターバルを考慮して、それぞれ接続可能端末数が設定されている。
識別子TSIが異なる組み合わせパターンを設定することにより、コントローラ7とにそれぞれに合わせたBluetooth通信を実行することが可能となる。
【0229】
例えば、スニフモードのBluetooth通信を実行するに際し、授受するデータ量が多い他の種別の端末装置については、識別子TSI0〜TSI8を割り当てるとともに、他の種別の端末装置と比較して授受するデータ量が少ないコントローラ7については、識別子TSI9あるいはTSI10を割り当てたスニフモードにおける同期通信処理を実行することが可能である。
【0230】
ローカル端末の種別に応じた効率的なスニフモードのBluetooth通信を実行することが可能である。
(実施形態3)
図15は、実施形態3に基づくスニフモードにおけるBluetooth通信のタイミング調整を説明する図である。
【0231】
図15に示されるように、本例においては3台のローカル端末としてコントローラA〜CにおけるスニフモードにおけるBluetooth通信が実行されている。そして、次にコントローラBが通信を終了する場合が示されている。
【0232】
これにより2台のローカル端末としてコントローラAとコントローラCにおけるスニフモードにおけるBluetooth通信が継続される。また、コントローラAとコントローラCとの間には空区間が存在する。
【0233】
次に、新たなローカル端末としてコントローラDが通信に参加する場合が示されている。
【0234】
本例においては、コントローラDの通信区間は、コントローラBがスニフモードにおける同期通信処理を実行していた区間(空区間)に挿入される。すなわち、コントローラAの通信区間の終了時点と、コントローラDの通信区間の開始時点とが実質的に連続になるようにタイミング調整される。また、コントローラDの通信区間の終了時点と、コントローラCの通信区間の開始時点とが実質的に連続になるようにタイミング調整される。
【0235】
これにより、通信区間を一まとまりとすることにより、残りの通信区間を他の通信における通信区間として利用することが可能となる。これにより、Bluetooth通信と他の通信との干渉を容易に回避し、効率的なデータ通信を実行することが可能となる。
【0236】
図16は、実施形態3に基づくスニフモードにおけるBluetooth通信の別のタイミング調整を説明する図である。
【0237】
図16に示されるように、本例においては3台のローカル端末としてコントローラA〜CにおけるスニフモードにおけるBluetooth通信が実行されている。そして、次にコントローラBが通信を終了する場合が示されている。
【0238】
これにより2台のローカル端末としてコントローラAとコントローラCにおけるスニフモードにおけるBluetooth通信が継続される。また、コントローラAとコントローラCとの間には空区間が存在する。
【0239】
次に、新たなローカル端末として他の種別の端末装置Eが通信に参加する場合が示されている。
【0240】
本例においては、他の種別の端末装置Eの通信区間は、コントローラCがスニフモードにおける同期通信処理を実行していた区間の後に配置される。
【0241】
一例として、端末装置Eは、通信区間のスロット数が「4」である。一方、コントローラBの通信区間のスロット数は「2」である。
【0242】
したがって、コントローラBのスロット数は「2」であったため、スロット数が「4」の端末装置Eの通信区間を空区間に挿入することはできない。したがって、端末装置Eの通信区間は、コントローラCの通信区間の後の区間にタイミング設定される。すなわち、コントローラCの通信区間の終了時点と、端末装置Eの通信区間の開始時点とが実質的に連続になるようにタイミング調整される。
【0243】
これにより、通信区間を一まとまりとすることにより、残りの通信区間を他の通信における通信区間として利用することが可能となる。これにより、Bluetooth通信と他の通信との干渉を容易に回避し、効率的なデータ通信を実行することが可能となる。
【0244】
[c6.情報処理装置本体5のタイミング設定]
本体側のメイン通信処理およびスニフモードに移行する処理については
図9および
図10で説明したのと基本的に同様であるのでその詳細な説明については繰り返さない。一方で、
図9のステップS13のタイミング設定における処理が異なる。
【0245】
図17は、実施形態3に基づく情報処理装置本体5のタイミング設定について説明するフロー図である。
【0246】
図17を参照して、
図10で説明したフロー図と比較して、ステップS50〜S54を追加した点が異なる。その他の点については同様であるのでその詳細な説明については繰り返さない。
【0247】
ステップS41において、本体側は、スニフモードにおける同期通信処理が設定されていると判断した場合(ステップS41においてYES)には、空区間があるかどうかを判断する(ステップS50)。具体的には、タイミング調整部102は、スニフモードにおける同期通信処理を実行している通信区間において、通信していない空区間が有るかどうかを判断する。
【0248】
ステップS50において、本体側は、空区間があると判断した場合(ステップS50においてYES)には、空区間で通信可能かどうかを判断する(ステップS52)。具体的には、タイミング調整部102は、比較部103に対して空区間のスロット数と、識別子TSIに基づくスロット数とを比較するように指示する。
【0249】
比較部103は、空き区間のスロット数と、識別子TSIに基づくスロット数とを比較して、識別子TSIに基づくスロット数が空区間のスロット数以下であるか否かの比較結果をタイミング調整部102に出力する。
【0250】
タイミング調整部102は、当該比較結果に基づいて空区間で通信可能か否かを判断する。
【0251】
ステップS52において、本体側は、空区間で通信可能であると判断した場合(ステップS52においてYES)には、空区間に通信区間を設定する(ステップS54)。タイミング調整部102は、識別子TSIに基づくスロット数が空区間のスロット数以下であると判断した場合には、当該空区間に通信区間を設定する。たとえば、
図15の例に示されるように、空区間のスロット数が「2」であり、識別子TSIに基づくスロット数も「2」である場合に、当該空区間に通信区間が設定される。
【0252】
そして、ステップS45に進む。
一方、ステップS50において、本体側は、空区間がないと判断した場合(ステップS50においてNO)には、識別子TSIに基づいて既に設定されている最後の通信区間の後に通信区間を設定する(ステップS44)。そして、ステップS45に進む。以降の処理は同様である。
【0253】
また、ステップS52において、本体側は、空区間で通信可能でないと判断した場合(ステップS52においてNO)には、ステップS44に進む。タイミング調整部102は、比較部103の比較結果に従って識別子TSIに基づくスロット数が空区間のスロット数以下でないと判断した場合には、ステップS44に進み、識別子TSIに基づいて既に設定されている最後の通信区間の後に通信区間を設定する。
【0254】
たとえば、
図16の例に示されるように、空区間のスロット数が「2」であり、識別子TSIに基づくスロット数が「4」である場合には、最後の通信区間の後に通信区間が設定される。
【0255】
当該処理により、スニフモードにおけるBluetooth通信の全通信区間中の空区間に、他のローカル端末の通信区間を挿入することが可能となり、空区間の無駄を抑制することができる。通信区間を一まとまりとすることにより、残りの通信区間を他の通信における通信区間として利用することが可能となる。これにより、Bluetooth通信と他の通信との干渉を容易に回避し、効率的なデータ通信を実行することが可能となる。
(実施形態3の変形例1)
上記の実施形態3においては、空区間に通信区間を挿入することができないと判断した場合には、最後の通信区間の後に通信区間を設定する場合について説明したが、当該場合には通信区間の設定をリセットして再設定する再調整処理を実行するようにしても良い。
【0256】
[c7.情報処理装置本体5のタイミング設定]
図18は、実施形態3の変形例1に基づく情報処理装置本体5のタイミング設定について説明するフロー図である。
【0257】
図18を参照して、
図17のフロー図と比較して、ステップS56における再調整処理を追加した点が異なる。その他の処理については
図10および
図17で説明したのと同様であるのでその詳細な説明については繰返さない。
【0258】
ステップS52において、本体側は、空区間で通信可能かどうかを判断する。具体的には、タイミング調整部102は、比較部103に対して空区間のスロット数と、識別子TSIに基づくスロット数とを比較するように指示する。
【0259】
比較部103は、空区間のスロット数と、識別子TSIに基づくスロット数とを比較して、識別子TSIに基づくスロット数が空区間のスロット数以下であるか否かの比較結果をタイミング調整部102に出力する。
【0260】
タイミング調整部102は、当該比較結果に基づいて空区間で通信可能か否かを判断する。
【0261】
ステップS52において、本体側は、空区間で通信可能であると判断した場合(ステップS52においてYES)には、空区間に通信区間を設定する(ステップS54)。タイミング調整部102は、識別子TSIに基づくスロット数が空区間のスロット数以下であると判断した場合には、当該空区間に通信区間を設定する。
【0262】
一方、ステップS52において、本体側は、空区間で通信可能でないと判断した場合(ステップS52においてNO)には、再調整処理を実行する(ステップS56)。
【0263】
具体的には、タイミング調整部102は、モード設定部112に再調整処理を実行するように指示する。
【0264】
[c8.情報処理装置本体5の再調整処理]
図19は、実施形態3の変形例1に基づく情報処理装置本体5の再調整処理について説明するフロー図である。
【0265】
図19を参照して、本体側は、空区間の後に設定された通信区間に対応する各ローカル端末にスニフ解除要求を送信する(ステップS60)。モード設定部112は、空区間の後に設定された通信区間に対応する各ローカル端末に対してスニフモードを終了して、アクティブモードに設定するためのスニフ解除要求を送信する。
【0266】
次に、本体側は、各ローカル端末からの応答があるかどうかを判断する(ステップS62)。モード設定部112は、各ローカル端末からの応答を受信したかどうかを判断する。
【0267】
ステップS62において、本体側は、各ローカル端末からの応答があると判断した場合(ステップS62においてYES)には、各ローカル端末についてスニフモードを終了してアクティブモードに設定する(ステップS64)。そして、処理「R」に進む。
【0268】
処理「R」として、
図8のステップS10におけるスニフ(Sniff)モードに移行する処理を実行する。
【0269】
そして、
図9で説明したのと同様の手順に従ってスニフモードにおけるステップS13のタイミング設定において、各ローカル端末における通信区間が再設定される。
【0270】
そして、本体側から各ローカル端末に対してタイミング情報が更新されたスニフ要求が送信される。
【0271】
本体側は、各ローカル端末からの応答があるかどうかを判断し、応答があると判断した場合には、スニフモードにそれぞれ設定する。モード設定部112は、応答があった各ローカル端末との関係においてスニフモードに設定する。
【0272】
次に、本体側と各ローカル端末との間でスニフモードにおける同期通信処理を実行する。
【0273】
図20は、実施形態3の変形例1に基づくスニフモードにおけるBluetooth通信のタイミング調整を説明する図である。
【0274】
図20に示されるように、本例においては3台のローカル端末としてコントローラA〜CにおけるスニフモードにおけるBluetooth通信が実行されている。そして、次にコントローラBが通信を終了する場合が示されている。
【0275】
これにより2台のローカル端末としてコントローラAとコントローラCにおけるスニフモードにおけるBluetooth通信が継続される。また、コントローラAとコントローラCとの間には空区間が存在する。
【0276】
次に、新たなローカル端末として端末装置Eが通信に参加する場合が示されている。
本例においては、端末装置Eの通信区間についてはスロット数が「4」である。一方、コントローラBの通信区間のスロット数は「2」である。
【0277】
したがって、コントローラBのスロット数は「2」であったため、スロット数が「4」の端末装置Eの通信区間を空区間に挿入することはできない。
【0278】
したがって、再調整処理を実行する。具体的には、コントローラCに対してアクティブモードに設定してコントローラAの通信区間に隣接するように通信区間を再設定する。また、端末装置EについてもコントローラCの通信区間に隣接するように通信区間を設定する。
【0279】
これによりスニフモードにおけるBluetooth通信の全通信区間中の空区間において、他のローカル端末の通信区間を挿入できない場合には、再調整処理を実行することによって空区間の無駄を抑制して、連続的に通信処理を継続することが可能となる。
【0280】
すなわち、通信区間を一まとまりとすることにより、残りの通信区間を他の通信における通信区間として利用することが可能となる。これにより、Bluetooth通信と他の通信との干渉を容易に回避し、効率的なデータ通信を実行することが可能となる。
【0281】
なお、本例においては、再調整処理を実行するにあたり、スニフモードのローカル端末をアクティブモードに設定し、そして再びスニフモードに設定する方式について説明したが、アクティブモードに移行することなく、スニフモードを継続しながら再調整処理を実行するようにしても良い。
(実施形態3の変形例2)
上記の変形例1においては、
図18のステップS52において、本体側は、空区間で通信可能でないと判断した場合(ステップS52においてNO)には、再調整処理を実行する場合について説明したが、ステップS50において、本体側は、空区間があると判断した場合(ステップS50においてYES)には、再調整処理(ステップS56)を実行するようにしても良い。
【0282】
再調整処理については、上記の変形例1と同様である。
図21は、実施形態3の変形例2に基づくスニフモードにおけるBluetooth通信のタイミング調整を説明する図である。
【0283】
図21に示されるように、本例においては2台のローカル端末としてコントローラA,BにおけるスニフモードにおけるBluetooth通信が実行されている。そして、次にコントローラAが通信を終了した場合が示されている。
【0284】
これによりグループアンカーポイントGAPとコントローラBとの間に空区間が存在する。
【0285】
次に、新たなローカル端末としてコントローラCが通信に参加する場合に、空区間が存在するため本例においては上記の再調整処理を実行する。
【0286】
これにより、グループアンカーポイントGAPを基準タイミングとしてコントローラB,Cの通信区間である通信区間が連続的に設定される。
【0287】
これによりスニフモードにおけるBluetooth通信の全通信区間中の空区間が有る場合には再調整処理を実行することにより、空区間の無駄を抑制して、連続的に通信処理を継続することが可能となる。
【0288】
すなわち、通信区間を一まとまりとすることにより、残りの通信区間を他の通信における通信区間として利用することが可能となる。これにより、Bluetooth通信と他の通信との干渉を容易に回避し、効率的なデータ通信を実行することが可能となる。
(実施形態3の変形例3)
上記の実施形態3においては、再調整処理を実行するにあたり、関係するローカル端末に関して、一旦、スニフモードからアクティブモードに設定してからタイミング設定(通信区間の再設定)を実行する方式について説明したがスニフモードにおけるBluetooth通信を維持しながら通信区間の再設定を実行するようにしても良い。
【0289】
具体的には、空区間の後に設定された通信区間に対応する各ローカル端末との関係において、スニフモードにおけるBluetooth通信のタイミング情報を変更するようにしても良い。
【0290】
例えば、
図21の例においては、本体側とコントローラBとの間のスニフモード設定において、2つのスロット数の通信区間分についてタイミングを変更(早める)するコマンドをコントローラBに送信することにより、タイミング情報を変更することも可能である。
【0291】
あるいは、
図21の例においては、基準タイミングとなるグループアンカーポイントGAPの設定を変更して、2つのスロット数の通信区間分についてタイミングを変更(遅くする)することにより、タイミング情報を変更することも可能である。
(実施形態4)
上記の実施形態においては、識別子TSIが固定されている場合について説明したが、識別子TSIを変更することも可能である。
【0292】
具体的には、通信するローカル端末の台数が増加した場合に識別子TSIを変更しても良い。
【0293】
[c9.情報処理装置本体5のメイン通信処理]
図22は、実施形態4に基づく情報処理装置本体5(本体側)のメイン通信処理について説明するフロー図である。
【0294】
図22を参照して、
図8のフロー図と比較して、ステップS9A,S9Bを追加した点が異なる。その他の構成については、
図8で説明したのと同様であるのでその詳細な説明については繰り返さない。
【0295】
ステップS9において、本体側は、識別子TSIの指示があると判断した場合(ステップS9においてYES)には、通信可能台数がOKであるか否かを判断する(ステップS9A)。具体的には、台数管理部108は、スニフモードに移行するに際し、指示された識別子TSIに関して接続可能端末数以内であるか否かを判断する。
【0296】
次に、ステップS9Aにおいて、台数がOKであると判断した場合(ステップS9AにおいてYES)には、スニフ(Sniff)モードを移行する処理を実行する(ステップS10)。
【0297】
一方、ステップS9Aにおいて、台数がOKで無いと判断した場合(ステップS9AにおいてNO)には、TSI変更処理を実行する(ステップS9B)。台数管理部108は、スニフモードを移行するに際し、既に接続可能端末数の上限値に到達している場合には、台数がOKで無いと判断する。そして、台数管理部108は、モード設定部112にそれを通知する。TSI変更処理については後述する。
【0298】
[c10.情報処理装置本体5のTSI変更処理]
図23は、実施形態4に基づく情報処理装置本体5のTSI変更処理について説明するフロー図である。
【0299】
図23を参照して、本体側は、TSIの変更が可能であるかどうかを判断する(ステップS80)。モード設定部112は、接続可能台数を変更するにあたり現在の識別子TSIからの変更が可能であるか否かを判断する。具体的には、スロット数を維持しつつ、接続可能台数を変更可能であるか否かを判断する。たとえば、現在の識別子TSI0(アップリンク数3、ダウンリンク数3)から識別子TSI5(アップリンク数3、ダウンリンク数3)への変更が可能である。同様に、識別子TSI1(アップリンク数1、ダウンリンク数1)から識別子TSI9(アップリンク数1、ダウンリンク数1)への変更が可能である。一方、スロット数が維持できない場合には変更可能でないと判断する。
【0300】
ステップS80において、本体側は、TSIの変更が可能であると判断した場合(ステップS80においてYES)には、全ローカル端末にスニフ解除要求を通知する(ステップS82)。モード設定部112は、全ローカル端末に対してスニフ解除要求を送信する。
【0301】
次に、本体側は、各ローカル端末からの応答があるかどうかを判断する(ステップS84)。モード設定部112は、各ローカル端末からの応答を受信したかどうかを判断する。
【0302】
ステップS84において、本体側は、各ローカル端末からの応答があると判断した場合(ステップS84においてYES)には、全ローカル端末についてアクティブモードに設定する(ステップS86)。モード設定部112は、応答があった全ローカル端末についてアクティブモードに設定する。
【0303】
そして、次に、本体側は、TSIを変更設定する(ステップS88)。モード設定部112は、識別子TSIを変更設定する。具体的には、現在の識別子TSI0である場合には、識別子TSI5に変更設定する。また、現在の識別子TSI1である場合には、識別子TSI9に変更設定する。
【0304】
そして、処理「R」に進む。
処理「R」として、
図8のステップS10におけるスニフ(Sniff)モードに移行する処理を実行する。
【0305】
そして、
図9で説明したのと同様の手順に従って、本体側は、識別子TSIに従って通信設定する(ステップS12)。具体的には、モード設定部112は、識別子TSIに従う通信設定情報に基づいて通信設定する。たとえば、モード設定部112は、識別子TSI0から識別子TSI5に変更設定した場合には、接続可能なローカル端末の数(接続可能端末数)が「4」、スロット数に関して、ローカル端末から本体側へのデータのアップリンク数が「3」、本体側からローカル端末へのデータのダウンリンク数が「3」、周期的な通信間隔であるスニフインターバルが「15」(ms)となるように通信設定する。モード設定部112は、接続可能なローカル端末の数(接続可能端末数)に関する情報を台数管理部108に通知する。台数管理部108は、当該通知を受けて接続可能端末数を管理する。
【0306】
そして、ステップS13のタイミング設定において、各ローカル端末における通信区間が再設定される。
【0307】
そして、本体側から各ローカル端末に対して更新されたスニフ要求が送信される。
本体側は、各ローカル端末からの応答があるかどうかを判断し、応答があると判断した場合には、スニフモードにそれぞれ設定する。モード設定部112は、応答があった各ローカル端末との関係においてスニフモードに設定し、更新された識別子TSIに従うスニフモードにおける同期通信処理を実行する。
【0308】
これによりスニフモードにおけるBluetooth通信において、接続台数を変更可能な場合には、識別子TSIを変更設定して再調整することにより、効率的なデータ通信を実行することができる。
(実施形態4の変形例)
上記の実施形態においては、台数の変更により識別子TSIを変更する場合について説明した。一方で、通信するデータ量がアプリケーションの状況により変化する場合が考えられる。たとえば、本体側からローカル端末へのデータに関して、ダウンリンク数を増加させる必要が生じる場合がある。一例として、本体側からコントローラ7に対して、コントローラ7のバイブレータ719等を作動させるためのデータを送信する場合には、ダウンリンク数のスロット数は少なくてもよいが、コントローラ7のスピーカ707から音声データを出力する場合には、ダウンリンク数のスロット数を増加させる必要がある。
【0309】
また、反対にローカル端末から本体側へのデータに関しても、アップリンク数を増加させる必要が生じる場合がある。一例として、コントローラ7から本体側に対してコントローラ7の操作データを送信する場合には、アップリンク数のスロット数は少なくても良いが、コントローラ7のマイク709に入力された音声データを送信する場合には、アップリンク数のスロット数を増加させる必要がある。
【0310】
[c11.情報処理装置本体5のTSI変更設定]
図24は、実施形態4の変形例に基づく情報処理装置本体5のTSI変更設定について説明するフロー図である。
【0311】
図24を参照して、本体側は、アプリケーションを実行する(ステップS90)。アプリケーション実行部200は、所定のアプリケーションプログラムに基づいて所定のアプリケーション処理を実行する。
【0312】
次に、本体側は、TSIを設定指示する(ステップS92)。アプリケーション実行部200は、モード設定部112に対して識別子TSIを指定して通知する。一例として初期状態においては、アプリケーションプログラムに従って所定の識別子TSIが指定されるものとする。
【0313】
次に、本体側は、通信データ量が変更されるかどうかを判断する(ステップS96)。アプリケーション実行部200は、所定のアプリケーション処理に従って通信データ量が変更されるか否かを判断する。たとえば、アプリケーション処理に従ってダウンリンク数を増加させる必要があるか否か、あるいは、アップリンク数を増加させる必要が有るか否か等を判断する。
【0314】
ステップS96において、本体側は、通信データ量が変更されると判断した場合(ステップS96においてYES)には、全ローカル端末にスニフ解除要求を送信するように指示する(ステップS98)。アプリケーション実行部200は、所定のアプリケーション処理に従って通信データ量が変更されると判断した場合には、スニフ解除要求を送信するようにモード設定部112に指示する。モード設定部112は、アプリケーション実行部200からの指示に従って全ローカル端末に対してスニフ解除要求を送信する。これに伴い、全ローカル端末は、アクティブモードに設定される。
【0315】
そして、次に、本体側は、TSI変更設定を実行する(ステップS99)。アプリケーション実行部200は、識別子TSIを変更設定指示する。具体的には、通信データ量に基づいてスロット数が変化する識別子TSIに変更するように指示する。たとえば、アプリケーション実行部200は、ダウンリンク数を増加させる場合に識別子TSI1から識別子TSI2あるいは識別子TSI3に変更するようにモード設定部112に指示する。アプリケーション実行部200は、アップリンク数を増加させる場合に識別子TSI1から識別子TSI4あるいは識別子TSI6に変更するようにモード設定部112に指示する。モード設定部112は、アプリケーション実行部200からの変更された識別子TSIに従って全ローカル端末に対してスニフモードに移行する処理を実行する。具体的には、
図9で説明したフローを実行する。
【0316】
具体的には、
図9で説明したのと同様の手順に従って、本体側は、識別子TSIに従って通信設定する(ステップS12)。モード設定部112は、識別子TSIに従う通信設定情報に基づいて通信設定する。たとえば、モード設定部112は、識別子TSI1から識別子TSI2に変更設定した場合には、接続可能なローカル端末の数(接続可能端末数)が「4」、スロット数に関して、ローカル端末から本体側へのデータのアップリンク数が「1」、本体側からローカル端末へのデータのダウンリンク数が「3」、周期的な通信間隔であるスニフインターバルが「10」(ms)となるように通信設定する。モード設定部112は、接続可能なローカル端末の数(接続可能端末数)に関する情報を台数管理部108に通知する。台数管理部108は、当該通知を受けて接続可能端末数を管理する。
【0317】
そして、ステップS13のタイミング設定において、各ローカル端末における通信区間が再設定される。
【0318】
そして、本体側から各ローカル端末に対して更新されたスニフ要求が送信される。
本体側は、各ローカル端末からの応答があるかどうかを判断し、応答があると判断した場合には、スニフモードにそれぞれ設定する。モード設定部112は、応答があった各ローカル端末との関係においてスニフモードに設定し、更新された識別子TSIに従うスニフモードにおける同期通信処理を実行する。
【0319】
当該処理により、変更された識別子TSIに基づくスニフモードにおける同期通信処理が本体側と各ローカル端末との間で実行される。
【0320】
したがって、通信するデータ量がアプリケーションの状況により変化する場合において、通信するデータ量に応じてスロット数を増加等させる識別子TSIに設定することが可能であり、最適な識別子TSIに変更することにより、効率的なデータ通信を実行することが可能である。
【0321】
なお、本例においては、スロット数を増加させる場合について説明したが、通信するデータ量が変更してスロット数を減少させる場合についても同様に適用可能である。
(実施形態5)
実施形態5は、スニフモードとは異なる別の通信モードであるバーストモードにおける通信処理について説明する。
【0322】
図25は、実施形態5に基づくバーストモードにおける通信処理について説明する概念図である。
【0323】
図25に示されるように、一例として本体側と、ローカル端末LA〜LCとがそれぞれ通信処理を実行する場合が示されている。
【0324】
また、本例においてはローカル端末LCにおいてバーストモードの通信処理が設定されている。一方、ローカル端末LA,LBについては、スニフモードの通信処理が設定されている。
【0325】
ローカル端末LCにおいて、バーストモードが設定されている場合には、ローカル端末LAおよびローカル端末LBと本体側とがスニフモードの通信処理を実行する区間においてもローカル端末LCを優先して通信処理を実行する。
【0326】
したがって、ローカル端末LCにおいて、バーストモードが設定されている場合には、ローカル端末LAおよびローカル端末LBは、ローカル端末LCが本体側と優先して通信処理を実行していることを認識することなくスニフモードによる通信処理を継続する。
【0327】
したがって、本体側とローカル端末LCとの間の通信処理が優先されるため、データ通信回数を増加させることが可能である。これにより、優先的にローカル端末LCと本体側との間でデータの授受を実行することができる。たとえば、ローカル端末LCのカメラ66を利用してデータ量の多い画像データを本体側に送信する場合には、ローカル端末LCについてバーストモードに設定することにより早期にローカル端末LCからのデータの多い画像データを本体側は取得することが可能である。
【0328】
一方で、本体側は、所定周期毎にローカル端末LAおよびLBと通信処理を実行する。これにより、端末側とローカル端末LAおよびLCとの間でのスニフモードによる通信処理も継続することが可能である。
【0329】
なお、バーストモードに設定した場合には、WI−FI通信による通信は制限する。これにより、第1無線通信と第2無線通信とが相互に干渉し合うことがなくデータ衝突を回避し、通信品質が良好な情報処理装置を実現することが可能である。
【0330】
[c11.情報処理装置本体5のアプリケーション実行処理]
図26は、実施形態5に基づく情報処理装置本体5のアプリケーション実行処理について説明するフロー図である。
【0331】
図26に示されるように、本体側は、アプリケーションを実行する(ステップS60)。アプリケーション実行部200は、所定のアプリケーションプログラムに基づいて所定のアプリケーション処理を実行する。
【0332】
次に、本体側は、バーストモードに移行するためのイベントが発生したか否かを判断する(ステップS62)。アプリケーション実行部200は、バーストモードに移行するためのイベントが発生したか否かを判断する。具体的には、イベントとしては、本例においてはローカル端末におけるマイクあるいはカメラ等を利用するイベントが発生したか否かを判断する。
【0333】
ステップS62において、本体側は、バーストモードに移行するためのイベントが発生したと判断した場合(ステップS62においてYES)には、モード変更判定を実行する(ステップS64)。アプリケーション実行部200は、バーストモードに移行するためのイベントが発生したと判断した場合には、モード変更判定を実行する。モード変更判定処理の詳細については後述する。
【0334】
そして、次に、本体側は、処理を終了したか否かを判断する(ステップS66)。
ステップS66において、本体側は、処理を終了したと判断した場合には終了する(エンド)。
【0335】
一方、ステップS66において、本体側は、処理を終了しないと判断した場合(ステップS66においてNO)には、ステップS60に戻り、所定のアプリケーション処理の実行を継続する。
【0336】
[c12.情報処理装置本体5のモード変更判定]
図27は、実施形態5に基づく情報処理装置本体5のモード変更判定について説明するフロー図である。
【0337】
図27に示されるように、通信するデータ量が大きいか否かを判断する(ステップS70)。アプリケーション実行部200は、通信するデータ量が大きいか否かを判断する、利用する。
【0338】
ステップS70において、通信データ量が大きいと判断した場合(ステップS70においてYES)には、バーストモードの設定を指示する(ステップS72)。たとえば、指定するローカル端末におけるマイクあるいはカメラ等を利用するイベントが発生した場合には、通信データ量が大きいと判断する。アプリケーション実行部200は、モード設定部112に対してバーストモードの設定を指示する。モード設定部112は、アプリケーション実行部200からの指示に従ってローカル端末を指定して、バースト指示を送信する。
【0339】
本体側は、バーストモードの処理を終了したか否かを判断する(ステップS74)アプリケーション実行部200は、バーストモードの処理が終了したか否かを判断する。たとえば、指定するローカル端末におけるマイクあるいはカメラ等を利用するイベントが終了した場合には、バーストモードの処理が終了したと判断する。
【0340】
ステップS74において、バーストモードの処理が終了したと判断した場合(ステップS74においてYES)には、バースト解除要求を指示する(ステップS76)。アプリケーション実行部200は、モード設定部112に対してバーストモードの解除要求を送信するように指示する。モード設定部112は、アプリケーション実行部200からの指示に従ってローカル端末を指定して、バースト解除要求を送信する。
【0341】
次に、本体側は、スニフモードの設定を指示する(ステップS78)。アプリケーション実行部200は、モード設定部112に対してスニフモードの設定を指示する。アプリケーション実行部200は、モード設定部112に対して識別子TSIを指示する。
【0342】
そして、処理を終了する(リターン)。
一方、ステップS70において、通信データ量が大きくないと判断した場合(ステップS70においてNO)には、処理をスキップして終了する(リターン)。
【0343】
[c13.情報処理装置本体5のメイン通信処理]
図28は、実施形態5に基づく情報処理装置本体5(本体側)のメイン通信処理について説明するフロー図である。
【0344】
図28を参照して、
図9のフロー図と比較して、ステップS11A,S11Bを追加した点が異なる。その他の処理については上記で説明したのと同様であるのでその詳細な説明については繰り返さない。
【0345】
ステップS9において、本体側は、識別子TSIの指示がないと判断した場合(ステップS9においてNO)には、バースト指示が有るかどうかを判断する(ステップS11A)。モード設定部112は、アプリケーション実行部200から指定されたローカル端末についてバーストモードの指示が有るかどうかを判断する。
【0346】
ステップS11Aにおいて、本体側は、バースト指示が有ると判断した場合(ステップS11AにおいてYES)には、バーストモードに移行する処理を実行する(ステップS11B)。バーストモードに移行する処理の詳細については後述する。
【0347】
一方、ステップS11Aにおいて、本体側は、バースト指示が無いと判断した場合(ステップS11AにおいてNO)には、ステップS7に戻り、アクティブモードにおける通信処理を継続する。
【0348】
[c14.情報処理装置本体5のバーストモードに移行する処理]
図29は、実施形態5に基づく情報処理装置本体5のバーストモードに移行する処理について説明するフロー図である。
【0349】
図29に示されるように、本体側は、バーストモードにおける同期通信の通信設定をする(ステップS102)。具体的には、モード設定部112は、バーストモードにおける通信設定する。具体的には、バーストモードにおける予め規定された通信に用いるスロット数を設定する。
【0350】
次に、本体側は、バースト要求をローカル端末に送信する(ステップS104)。モード設定部112は、通信設定で設定したリンク数等を含むバースト要求を指定したローカル端末に送信する。本例においては、モード設定部112は、一例として全てのローカル端末ではなく、指定したローカル端末に対してのみバースト要求を送信する。
【0351】
なお、全てのローカル端末に対して、バースト要求を送信した指定したローカル端末に関する情報を送信するようにしても良い。
【0352】
次に、本体側は、ローカル端末からの応答があるかどうかを判断する(ステップS105)。モード設定部112は、ローカル端末からの応答を受信したかどうかを判断する。
【0353】
ステップS105において、本体側は、ローカル端末からの応答があると判断した場合(ステップS105においてYES)には、バーストモードに設定する(ステップS106)。
【0354】
モード設定部112は、応答があったローカル端末との関係においてバーストモードに設定する。本例においては、複数のローカル端末と通信する場合においてそれぞれのローカル端末との関係において通信モードを設定することが可能である。したがって、本体側は、あるローカル端末とはスニフモードにおける同期通信モードであり、別のローカル端末とはバーストモードにおける通信モードとなり得る。
【0355】
次に、本体側とローカル端末との間でバーストモードにおけう通信処理を実行する(ステップS107)。バーストモードにおける通信処理は、ある指定したローカル端末との間での優先的な通信処理である。バーストモードにおける通信処理については後述する。
【0356】
次に、本体側は、バースト解除要求の指令があるかどうかを判断する(ステップS108)。モード設定部112は、アプリケーション実行部200等からアクティブモードを指定するアクティブ要求の指令を受けたかどうかを判断する。
【0357】
ステップS108において、本体側は、バースト解除要求の指令があると判断した場合(ステップS108においてYES)には、バースト解除要求をローカル端末に送信する(ステップS109)。モード設定部112は、バースト解除要求を指定されたローカル端末に送信する。
【0358】
次に、本体側は、ローカル端末からの応答があるかどうかを判断する(ステップS110)。モード設定部112は、ローカル端末からの応答があるかどうかを判断する。
【0359】
ステップS110において、本体側は、ローカル端末の応答が有ると判断した場合(ステップS110においてYES)には、処理「P」に進む。すなわち、
図28のステップS6に戻る。モード設定部112は、ローカル端末の応答が有ると判断した場合には、アクティブモードに設定する。
【0360】
一方、ステップS110において、本体側は、ローカル端末の応答が無いと判断した場合(ステップS110においてNO)には、処理を終了する(エンド)。
【0361】
一方、ステップS108において、本体側は、バースト解除要求の指令がないと判断した場合(ステップS108においてNO)には、ステップS107に戻り、バーストモードにおける通信処理を継続する。
【0362】
一方、ステップS105において、本体側は、ローカル端末からの応答がないと判断した場合(ステップS105においてNO)には、バーストモードに入ることなく、処理「P」に進む。すなわち、
図28のステップS6に戻る。モード設定部112は、バーストモードに移行する処理を終了する。
【0363】
[c15.情報処理装置本体5のバーストモードにおける通信処理]
図30は、実施形態5に基づくバーストモードにおける通信処理について説明するフロー図である。
【0364】
図30を参照して、指定した端末との間での優先通信処理を実行する(ステップS112)。本体側からのポーリング(POLLING)パケットを受けて、ローカル端末は、優先的に所定のリンク数のパケットを送信する通信処理を実行する。
【0365】
次に、本体側は、所定期間が経過したかどうかを判断する(ステップS114)。モード設定部112は、所定期間が経過したかどうかを判断する。なお、所定期間は、通信接続を維持する限界期間(Supervision timeout)よりも短い期間である。
【0366】
次に、本体側は、所定期間が経過していないと判断した場合(ステップS114においてNO)には、ステップS112に戻り優先通信処理を継続する。
【0367】
一方、ステップS114において、所定期間が経過したと判断した場合(ステップS1114においてYES)には、スニフ通信が有るかどうかを判断する(ステップS116)。モード設定部112は、スニフモードにおける同期通信処理を他のローカル端末と実行しているか否かを判断する。
【0368】
ステップS116において、スニフ通信があると判断した場合(ステップS116においてYES)には、同期維持通信を実行する(ステップS118)。具体的には、モード設定部112は、スニフモードにおける同期通信処理を他のローカル端末と実行していると判断した場合には、スニフモードにおける同期通信を維持する通信を実行する。具体的には、スニフモードにおける同期通信処理を他のローカル端末と維持するために本体側から所定期間経過毎にポーリング(POLLING)パケットを送信する。これにより、バーストモードで特定のローカル端末と集中的に通信を行っている期間であってもその他のローカル端末との通信接続が維持される。
【0369】
そして、処理を終了する(リターン)。
[c16.ローカル端末のメイン通信処理]
ローカル端末のメイン通信処理について説明する。ローカル端末としては、コントローラ7が含まれる。
【0370】
図31は、実施形態5に基づくローカル端末のメイン通信処理ついて説明するフロー図である。
【0371】
図31を参照して、
図12のフロー図と比較して、ステップS130,S131を追加した点が異なる。その他の処理については
図13と同様であるのでその詳細な説明については繰り返さない。
【0372】
ステップS30において、ローカル端末は、スニフ要求がないと判断した場合(ステップS30においてNO)には、バースト要求が有るかどうかを判断する(ステップS130)。
【0373】
ステップS130において、ローカル端末は、バースト要求が有ると判断した場合(ステップS130においてYES)には、バーストモードに移行する処理を実行する。バーストモードに移行する処理については後述する。
【0374】
一方、ステップS130において、ローカル端末は、バースト要求が無いと判断した場合(ステップS130においてNO)には、ステップS28に戻り、アクティブモードにおける通信処理を継続する。ローカル端末は、バースト要求のデータを受信しない場合には、通信モードとしてアクティブモードにおける通信処理を継続する。
【0375】
[c17.ローカル端末のバーストモードに移行する処理]
図32は、実施形態5に基づくローカル端末のバーストモードに移行する処理について説明するフロー図である。
【0376】
図32に示されるように、ローカル端末は、バースト要求があった場合には応答する(ステップS132)。ローカル端末は、本体側からのバースト要求を受信したと判断した場合には、応答信号を本体側に送信する。
【0377】
次に、ローカル端末は、バーストモードに設定する(ステップS133)。ローカル端末は、バースト要求に従って通信モードをバーストモードに設定する。
【0378】
また、ローカル端末は、バースト要求に含まれる規定されたスロット数を設定する。
次に、ローカル端末は、バーストモードにおける通信処理を実行する(ステップS134)。
【0379】
ローカル端末は、優先的に本体側からのポーリング(POLLING)パケットを受信して、規定のスロット数のパケットを送信する。
【0380】
次に、ローカル端末は、バースト解除要求があるかどうかを判断する(ステップS135)。具体的には、ローカル端末は、本体側から送信されるバーストモードを解除するためのバースト解除要求を受信したかどうかを判断する。
【0381】
ステップS135において、ローカル端末はバースト解除要求があると判断した場合(ステップS135においてYES)には、応答する(ステップS136)。ローカル端末は、本体側からのバースト解除要求を受信したと判断した場合には、応答信号を本体側に送信する。
【0382】
そして、次に、処理「Q」に進む。すなわち、
図31のステップS28に戻り、アクティブモードにおける通信処理を実行する。以降の処理は上述したのと同様である。
【0383】
一方、ステップS135において、ローカル端末は、バースト解除要求がないと判断した場合(ステップS135においてNO)には、ステップS134に戻り、バーストモードにおける通信処理を継続する。
(実施形態5の変形例)
上記の実施形態5においては、スニフモードにおける同期通信を維持する通信を実行するために、本体側から所定期間経過毎にポーリング(POLLING)パケットを送信する構成について説明したが、スニフモードにおける同期通信を維持することが可能であればどのような方式を採用しても良い。
【0384】
たとえば、スニフモードにおける同期通信処理を実行しているローカル端末に対して、バーストモードを実行中であることを示すデータパケットを送信して、スニフモードにおける同期通信を維持するようにしても良い。また、所定時間経過後にスニフモードにおける同期通信処理が実行されることを示すデータパケットを送信して、スニフモードにおける同期通信を維持するようにしてもよい。
【0385】
また、本実施形態におけるプログラムとして、パーソナルコンピュータで実行可能なアプリケーションを提供してもよい。このとき、本実施の形態に係るプログラムは、パーソナルコンピュータ上で実行される各種アプリケーションの一部の機能(モジュール)として組み込まれてもよい。
【0386】
今回開示された実施形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。