JP2011055028A - 無線通信端末、その制御方法、プログラム、及び情報記憶媒体 - Google Patents

Abstract

【課題】通信接続の継続を前提とするアプリケーションプログラムを実行中であっても、無線通信接続を切断することのできる無線通信端末を提供する。
【解決手段】アプリケーションプログラムを実行するアプリケーション実行手段からの送信処理要求に応じて通信相手に対してデータを送信する無線通信端末であって、通信相手との間で無線通信接続を確立し、所与の条件に基づいて、通信相手との間の無線通信接続を切断して通信中断状態に移行し、通信中断状態においてアプリケーション実行手段から送信処理要求を受け付けた際に通信相手との間の無線通信接続を再確立し、無線通信接続の再確立を待ってから、送信処理要求に係るデータを通信相手に送信する無線通信端末である。
【選択図】図２

Description

本発明は、無線にて他の通信機器と通信を行う無線通信端末、その制御方法、プログラム、及び情報記憶媒体に関する。

他の通信機器と無線通信を行う各種の無線通信端末が広く利用されている。このような無線通信端末においては、電力消費を低減したいという要請がある。そこで、データ通信を行わない期間中、無線通信端末をスリープ状態に移行させて電力消費を抑える技術が提案されている（例えば特許文献１参照）。

米国特許出願公開第２００５／０２３３７０４号明細書

上述した例では、無線通信端末がスリープ状態に移行している間も通信インタフェースの一部は動作し、無線通信接続を維持している。このような制御を行わないと、スリープ状態移行時に一旦通信接続が切断されてしまい、通信接続の継続を前提とするアプリケーションプログラムが正常に動作しなくなるおそれがあるからである。しかしながら、無線通信接続が維持されていると、アプリケーションプログラム側ではデータの送受信を必要としていない場合であっても、例えばビーコン等の制御パケットの送信により電力が消費されることがある。

本発明は上記実情を考慮してなされたものであって、その目的の一つは、通信接続の継続を前提とするアプリケーションプログラムを実行中であっても、無線通信接続を切断することのできる無線通信端末、その制御方法、プログラム、及び情報記憶媒体を提供することにある。

本発明に係る無線通信端末は、アプリケーションプログラムを実行するアプリケーション実行手段と、前記アプリケーション実行手段からの送信処理要求に応じて、通信相手に対してデータを送信する通信制御手段と、を含み、前記通信制御手段は、前記通信相手との間で無線通信接続を確立する接続手段と、所与の条件に基づいて、前記通信相手との間の無線通信接続を切断し、通信中断状態に移行する通信中断手段と、前記通信中断状態において前記送信処理要求を受け付けた際に、前記通信相手との間の無線通信接続を再確立する再接続手段と、前記無線通信接続の再確立を待ってから、前記送信処理要求に係るデータを前記通信相手に送信するデータ送信手段と、を含むことを特徴とする。

また、本発明に係る無線通信端末の制御方法は、アプリケーションプログラムを実行するアプリケーション実行手段からの送信処理要求に応じて、通信相手に対してデータを送信する無線通信端末の制御方法であって、前記通信相手との間で無線通信接続を確立するステップと、所与の条件に基づいて、前記通信相手との間の無線通信接続を切断し、通信中断状態に移行するステップと、前記通信中断状態において前記送信処理要求を受け付けた際に、前記通信相手との間の無線通信接続を再確立するステップと、前記無線通信接続の再確立を待ってから、前記送信処理要求に係るデータを前記通信相手に送信するステップと、を含むことを特徴とする。

また、本発明に係るプログラムは、アプリケーションプログラムを実行するアプリケーション実行手段からの送信処理要求に応じて、通信相手に対してデータを送信する無線通信端末を制御するためのプログラムであって、前記通信相手との間で無線通信接続を確立する接続手段、所与の条件に基づいて、前記通信相手との間の無線通信接続を切断し、通信中断状態に移行する通信中断手段、前記通信中断状態において前記送信処理要求を受け付けた際に、前記通信相手との間の無線通信接続を再確立する再接続手段、及び前記無線通信接続の再確立を待ってから、前記送信処理要求に係るデータを前記通信相手に送信するデータ送信手段、として前記無線通信端末を機能させるためのプログラムである。このプログラムは、コンピュータ読み取り可能な情報記憶媒体に記憶されてよい。

本発明の実施の形態に係る無線通信端末の構成図である。 本発明の実施の形態に係る無線通信端末の機能を示す機能ブロック図である。 本発明の実施の形態に係る無線通信端末の状態遷移図である。 本発明の実施の形態に係る無線通信端末が実行する通信中断状態からの復帰処理の一例を示すフロー図である。 本発明の実施の形態に係る無線通信端末が実行する通信中断状態からの復帰処理の別の例を示すフロー図である。

以下、本発明の実施の形態について、図面に基づき詳細に説明する。

図１は、本発明の一実施形態に係る無線通信端末１の構成図である。無線通信端末１は、ユーザが携帯して利用し、他の通信機器と無線によりデータの送受信を行う通信端末であって、携帯型ゲーム機や携帯情報端末等であってよい。無線通信端末１の通信相手は、無線通信端末１と同種の携帯機器であってもよいし、アクセスポイントなどであってもよい。以下では、図１に示すように、無線通信端末１の通信相手がアクセスポイント２である場合を例として、説明する。図１に示すように、無線通信端末１は、制御部１１と、記憶部１２と、通信部１３と、操作部１４と、表示部１５と、電源制御部１６と、を含んで構成される。

制御部１１は、ＣＰＵ等を含んで構成され、記憶部１２に記憶されたプログラムに従って各種の情報処理を実行する。制御部１１が実行する処理の内容については、後述する。

記憶部１２は、ＲＡＭやＲＯＭ等のメモリ素子を含んで構成され、制御部１１によって実行されるプログラムや各種のデータを記憶する。また、記憶部１２は制御部１１のワークメモリとしても機能する。

通信部１３は、無線によりデータ送受信を行うための通信インタフェースであって、本実施形態では、ＩＥＥＥ８０２．１１規格に従ってアクセスポイント２との間で無線ＬＡＮ通信を行う無線通信モジュールである。

操作部１４は、ボタン等の操作部材であって、ユーザの操作入力を受け付けて、その内容を示す信号を制御部１１に出力する。表示部１５は、液晶ディスプレイ等であって、制御部１１の指示に従って各種の画像を表示する。

電源制御部１６は、電源制御回路等であって、無線通信端末１に内蔵された充電池から供給される電力を無線通信端末１の各部に供給する。また、電源制御部１６は、電源状態等に関する情報を制御部１１に対して出力する。

図２は、無線通信端末１が実現する機能を示す機能ブロック図である。同図に示されるように、無線通信端末１は、機能的に、アプリケーション実行部２１と、通信制御部２２と、ネットワークドライバ部２３と、を含んで構成される。また、通信制御部２２は、アプリケーションインタフェース部２２ａと、プロトコル処理部２２ｂと、ドライバ制御部２２ｃと、ドライバインタフェース部２２ｄと、接続管理部２２ｅと、を含んで構成される。これらの機能は、制御部１１が記憶部１２に記憶された各機能に対応するプログラムを実行することにより、実現される。すなわち、アプリケーション実行部２１は制御部１１がアプリケーションプログラムを実行することにより、通信制御部２２の各機能は制御部１１が通信制御用のプログラムを実行することにより、ネットワークドライバ部２３は制御部１１がネットワークドライバプログラムを実行することにより、それぞれ実現される。これらのプログラムは、光ディスク媒体等の各種のコンピュータ読み取り可能な情報記憶媒体に格納されて提供されてもよいし、インターネット等の通信ネットワーク経由で提供されてもよい。

アプリケーション実行部２１は、アプリケーションプログラムによって規定される処理を実行する。ここで、アプリケーション実行部２１は、アクセスポイント２へのデータ送信を伴う処理を実行する。具体例として、アプリケーション実行部２１は、ＷＷＷブラウザプログラムを実行してユーザにＷｅｂページの閲覧機能を提供してもよい。この場合、アプリケーション実行部２１は、ユーザの指定するＷＷＷサーバに対するＷｅｂページ取得要求を発行する。この要求は、通信制御部２２によって処理され、通信パケットとしてアクセスポイント２に送信される。

通信制御部２２は、データ通信の制御に関する各種の処理を実行する。具体的に、通信制御部２２は、アプリケーション実行部２１が発行する送信処理要求に応じた他の通信機器へのデータ送信処理、他の通信機器からネットワークドライバ部２３を介して到来するデータの受信処理、またデータ送受信のために必要な各種の制御を行う。

ネットワークドライバ部２３は、物理層の通信インタフェースを直接に制御して、信号の送受信を行う。本実施形態では、ネットワークドライバ部２３は、通信部１３を制御して無線ＬＡＮ通信を行う。なお、無線通信端末１が無線ＬＡＮだけでなく、ＵＳＢ接続によるＬＡＮ通信など複数の通信インタフェースを備えている場合、これらの通信インタフェースのそれぞれについて独立に用意されたデバイスドライバプログラムを制御部１１が実行することで、各通信インタフェースに対応する複数のネットワークドライバ部２３が機能する。

以下、通信制御部２２内で実現される機能について説明する。

アプリケーションインタフェース部２２ａは、例えばソケットＡＰＩ（Application Program Interface）であって、アプリケーション実行部２１から見た通信処理のインタフェースとして機能する。すなわち、アプリケーション実行部２１は、ソケットを指定してアプリケーションインタフェース部２２ａに対して通信要求を発行することにより、外部とのデータ通信を行う。この場合において、ソケットは、アプリケーション実行部２１から見た抽象的な通信ポートに対応し、このソケットに対して通信要求を発行することにより、アプリケーションプログラムは下層の通信インタフェースや通信経路等を意識することなく、上位層のコネクション接続の相手先となるサーバとの間で、データの授受を行うことができる。

アプリケーション実行部２１がアプリケーションインタフェース部２２ａに対して発行する通信要求としては各種のものがあるが、このうちアクセスポイント２へのデータ送信が必要となる通信要求（送信処理要求）としては、アプリケーション接続要求（ｃｏｎｎｅｃｔ関数）やアプリケーションデータ送信要求（ｓｅｎｄ関数）などが挙げられる。なお、ここでのアプリケーション接続要求によって実現される接続は、物理層における無線通信端末１とアクセスポイント２との間の通信接続とは異なり、アプリケーション実行部２１と最終的なデータ送信先のサーバが実行するアプリケーションプログラムとの間における上位層（アプリケーション層）のコネクションである。アプリケーションインタフェース部２２ａは、アプリケーション実行部２１から受け付けた通信要求の内容に応じて、プロトコル処理部２２ｂに対して通信処理の指示を行う。

プロトコル処理部２２ｂは、プロトコルスタックを構成する各種のプロトコルモジュールによって実現され、特定の通信プロトコルに従って送信パケットの生成やデータ通信のフロー制御等を行う。本実施形態では、プロトコル処理部２２ｂは、ＴＣＰ／ＩＰプロトコルスイートを構成する各種のプロトコルに従ってデータ送受信の処理を行うものとする。

ドライバ制御部２２ｃは、プロトコル処理部２２ｂの処理内容とは別に、物理層の通信インタフェース（本実施形態では通信部１３）を制御する各種の制御命令を出力する。この制御命令は、ドライバインタフェース部２２ｄを介して対応するネットワークドライバ部２３に対して出力される。

ドライバインタフェース部２２ｄは、プロトコル処理部２２ｂやドライバ制御部２２ｃとネットワークドライバ部２３との間のデータ中継を行う。複数のネットワークドライバ部２３が動作している場合には、ドライバインタフェース部２２ｄは、プロトコル処理部２２ｂやドライバ制御部２２ｃからの処理要求に応じて、当該要求に対応するネットワークドライバ部２３に対して処理要求を転送する。また、各ネットワークドライバ部２３からの通知に応じて、他の通信機器から受信したデータ内容をプロトコル処理部２２ｂに対して出力する。

接続管理部２２ｅは、他の通信機器との間で物理層の通信接続を確立及び切断する制御を行う。具体的に、接続管理部２２ｅは、ユーザの要求等に応じて、アクセスポイント２との間での通信接続確立をドライバ制御部２２ｃに指示する。これに応じて、ドライバ制御部２２ｃはドライバインタフェース部２２ｄを介して通信部１３とアクセスポイント２との間の通信接続を確立させる。アクセスポイント２との間で通信接続が確立されると、アクセスポイント２からネットワークアドレス（ここではＩＰアドレス）が割り当てられる。なお、本実施形態ではアクセスポイント２がネットワークアドレスの割り当てを行うこととしているが、無線通信端末１は、固有のネットワークアドレス情報を予め保持していることとしてもよい。この場合には、無線通信端末１及びアクセスポイント２がお互いのネットワークアドレスを交換することで、通信接続を確立することができる。

また、接続管理部２２ｅは、無線通信端末１の通信接続状態の管理を行う。具体的には、通信部１３によって他の通信機器との間で通信接続が確立されているか否かを管理するとともに、通信接続が確立されている場合には当該通信接続に関する各種の情報を取得、管理する。管理対象となる情報としては、例えば無線通信端末１自身に割り当てられたネットワークアドレスやネットマスク等の設定情報、無線通信における電波強度等の通信状態に関する情報が挙げられる。

次に、本実施形態における無線通信端末１の状態遷移について、図３の状態遷移図を用いて説明する。初期状態Ｓｔ１では、アクセスポイント２との間で通信接続は確立されておらず、無線通信端末１は通信を行えない状態にある。ここで、ユーザの操作部１４に対する指示操作等によって、接続管理部２２ｅはアクセスポイント２との間で通信接続を確立する。これにより、ネットワークアドレスが取得され、無線通信端末１は準備状態Ｓｔ２に移行する（遷移Ｔ１）。

準備状態Ｓｔ２においては、通信制御部２２は、後述する未処理データのキューに未処理データがないか判定し、未処理データが存在する場合にはその処理を実行する。処理が完了して未処理データのキューが空になると、無線通信端末１は接続状態Ｓｔ３に移行する（遷移Ｔ２）。この接続状態Ｓｔ３においてユーザから通信接続を終了する指示操作があったりした場合、接続管理部２２ｅはアクセスポイント２との間の通信接続を切断する処理を行う。これによって、アクセスポイント２から割り当てられていたネットワークアドレスは解放されて、無線通信端末１は初期状態Ｓｔ１に戻る（遷移Ｔ３）。

一方、接続状態Ｓｔ３において所定の条件を満たした場合、接続管理部２２ｅはアクセスポイント２との間の通信接続を切断し、無線通信端末１は通信中断状態Ｓｔ４に移行する（遷移Ｔ４）。この場合も、アクセスポイント２から割り当てられていたネットワークアドレスは解放される。ただし、遷移Ｔ３の場合とは異なり、遷移Ｔ４の場合においてはアプリケーション実行部２１が利用するソケット及び上位層のコネクションは維持されるか、またはソケットの再取得が行われる場合も、アプリケーション実行部２１の動作は継続可能である。すなわち、接続状態Ｓｔ３から通信中断状態Ｓｔ４への移行があっても、アプリケーション実行部２１が実行中の処理には影響しないことになる。

ここで、接続状態Ｓｔ３から通信中断状態Ｓｔ４への移行が生じる条件は、例えばアクセスポイント２との間の通信間隔や、充電池の充電状態に関する条件であってよい。具体的な条件の例としては、所定の時間（例えば６０秒）にわたってアクセスポイント２との間でデータの送受信が行われないことや、充電池の充電容量が一定値以下まで低下することなどが挙げられる。具体的に、ここではドライバインタフェース部２２ｄが、通信中断状態Ｓｔ４への移行を行うか否かの判定を行う。無線通信端末１がアクセスポイント２との間でデータの送受信を行う場合、必ずドライバインタフェース部２２ｄを経由してデータを授受するので、ドライバインタフェース部２２ｄがこのような判定を行うこととすれば、所定の時間にわたってアクセスポイント２との間のデータ送受信が存在しないことを正確に検知できる。また、ドライバインタフェース部２２ｄは、電源制御部１６から充電池の状態に関する情報を取得し、当該取得した情報を用いて状態移行の判定を行ってもよい。

通信中断状態Ｓｔ４への移行を行うと判定した場合、ドライバインタフェース部２２ｄは、通信接続の中断を要求するイベントを発行する。接続管理部２２ｅは、このイベントを検知して、アクセスポイント２との間の通信接続の切断、及びネットワークアドレスの解放を行う。具体的には、接続管理部２２ｅからの要求に応じて、ドライバ制御部２２ｃがネットワークドライバ部２３に対して通信切断を指示する制御命令を出力することにより、通信の切断が行われる。これにより、通信中断状態Ｓｔ４においては通信部１３による不要なビーコンの発信等が行われなくなり、無線通信端末１の消費電力を抑えることができる。

通信中断状態Ｓｔ４において、アプリケーション実行部２１から送信処理要求があった場合、無線通信端末１は通信中断状態Ｓｔ４から復帰状態Ｓｔ５に移行する（遷移Ｔ５）。具体的には、アプリケーション実行部２１から送信処理要求を受け付けたアプリケーションインタフェース部２２ａからの要求に応じて、接続管理部２２ｅがアクセスポイント２との間の通信接続の再確立を実行する。この再接続の手順は、初期状態Ｓｔ１から準備状態Ｓｔ２に移行する際に接続管理部２２ｅが実行する最初の通信接続確立手順と同様のものであってよく、ネットワークアドレスの割り当てや認証等の処理を含んでもよい。この再接続処理が完了すると、ネットワークアドレスが取得され、無線通信端末１は復帰状態Ｓｔ５から準備状態Ｓｔ２に移行する（遷移Ｔ６）。なお、このとき取得されるネットワークアドレスは、通信中断状態Ｓｔ４に移行する前に割り当てられていたネットワークアドレスと同一である保証はない。しかしながら、前述したように通信中断状態Ｓｔ４でもアプリケーション実行部２１の動作は維持されるので、このようなネットワーク設定の変更はアプリケーション実行部２１が実行する処理には影響しない。

準備状態Ｓｔ２に移行すると、通信制御部２２は遷移Ｔ５を引き起こす要因となった送信処理要求に係るデータの送信処理を実行する。この処理が完了すれば、無線通信端末１は再び接続状態Ｓｔ３に戻る。

なお、通信中断状態Ｓｔ４及び復帰状態Ｓｔ５のいずれの状態においても、接続状態Ｓｔ３の場合と同様に、ユーザからの指示等によって、アクセスポイント２との間の通信接続が完全に切断され、初期状態Ｓｔ１に移行することがある（遷移Ｔ７及びＴ８）。ただし、この場合には遷移Ｔ４でネットワークアドレスは既に解放済みなので、遷移Ｔ３の場合と異なり改めてネットワークアドレスの解放が行われることはない。

次に、通信中断状態Ｓｔ４から復帰状態Ｓｔ５及び準備状態Ｓｔ２を経て接続状態Ｓｔ３に移行する場合に通信制御部２２が実行する処理（通信中断状態Ｓｔ４からの復帰処理）の具体例について、説明する。

本実施形態では、アプリケーション実行部２１は、ブロック型又はノンブロック型のいずれかを指定して通信制御部２２に対する送信処理要求を行う。ブロック型の要求があった場合、通信制御部２２は、当該要求に応じたデータ送信に対するアクセスポイント２からの応答があるまでの間、新たな通信要求を受け付けないようブロックする制御を行う。一方、ノンブロック型の要求の場合、通信制御部２２は、当該要求に応じたデータ送信処理の後、ブロック制御を行わない。そのため、データ送信処理の後、これに対する応答がなくとも、直ちに別の通信要求を受け付けることが可能となる。以下では、ブロック型の場合とノンブロック型の場合とに分けて、復帰処理の流れについて説明する。

まず、ブロック型の通信要求があった場合における通信中断状態Ｓｔ４からの復帰処理の流れの例について、図４のフロー図を用いて説明する。

まず、アプリケーション実行部２１からの送信処理要求（Ｓ１）を受領したアプリケーションインタフェース部２２ａは、当該要求に応じたデータ送信処理の実行をプロトコル処理部２２ｂに指示することにより、要求されるデータの送信を試みる（Ｓ２）。ここで、もし無線通信端末１が接続状態Ｓｔ３にあれば、プロトコル処理部２２ｂは問題なくデータ送信処理を実行して、その結果をアプリケーション実行部２１に返すことができる。また、仮にアプリケーション実行部２１からの通信要求がループバックアドレス宛ての送信処理要求であった場合や内部制御に関する要求であった場合、アクセスポイント２との間の通信は不要なため、通信中断状態Ｓｔ４であっても、プロトコル処理部２２ｂは正常に処理を完了して、その結果をアプリケーション実行部２１に返す。

しかし、ここではＳ１における要求はアクセスポイント２宛ての送信処理要求であって、しかも無線通信端末１は通信中断状態Ｓｔ４であることとしている。すなわち、ネットワークアドレスの割り当ては行われておらず、プロトコル処理部２２ｂはアクセスポイント２へのデータ送信を行うことができない。そこでプロトコル処理部２２ｂは、通信エラーの発生を示す返り値（ここではＥＮＥＴＤＯＷＮとする）をアプリケーションインタフェース部２２ａに返す（Ｓ３）。

データ送信処理が失敗した旨のＳ３の通知を受けたアプリケーションインタフェース部２２ａは、無線通信端末１の状態を参照して、通信中断状態Ｓｔ４にあるか否かを判定する（Ｓ４）。もし現在の状態が通信中断状態Ｓｔ４ではなく初期状態Ｓｔ１などであれば、アプリケーションインタフェース部２２ａは、単なる通信エラーが発生したものとして、その結果（すなわち返り値ＥＮＥＴＤＯＷＮ）をそのままアプリケーション実行部２１に返す。ここでは通信中断状態Ｓｔ４を仮定しているので、アプリケーションインタフェース部２２ａはＳ４の判定結果を受けて、接続管理部２２ｅに対して通信接続の再確立を要求する（Ｓ５）。以上説明したように、通信接続が確立されているとの仮定のもとにまずはデータ送信処理を試み、失敗した場合にのみ通信中断状態Ｓｔ４にあるか否かを判定することで、正常に接続されている場合やアクセスポイント２へのデータ送信が不要な場合には判定処理を行わないようにすることができる。

再接続要求を行うと、アプリケーションインタフェース部２２ａは、アプリケーション実行部２１からの通信処理要求の受付をブロックするブロック制御を行う（Ｓ６）。ここでのブロック制御は、データ送信処理が正常に実行されてその返信を待つ場合のブロック制御とは異なり、通信接続の完了のイベント通知を待つためのブロック制御である。一方、Ｓ５の要求を受けた接続管理部２２ｅは、ドライバ制御部２２ｃ経由でネットワークドライバ部２３に対して物理層の通信接確立を指示し、これに応じて通信接続の再確立（再接続処理）が実行され、ネットワークアドレスが再び割り当てられる（Ｓ７）。ネットワークアドレスの再割り当てが完了すると、接続管理部２２ｅは、その旨をドライバ制御部２２ｃ経由でアプリケーションインタフェース部２２ａに通知する（Ｓ８）。

Ｓ８の通知を受けたアプリケーションインタフェース部２２ａは、Ｓ６で実行したブロック制御を解除し、当該ブロック制御に関連づけられたデータ送信処理（すなわち、Ｓ１で受け付けた送信処理要求に係るデータ送信処理）を再度プロトコル処理部２２ｂに対して指示する（Ｓ９）。この処理は、Ｓ２の処理と同様のものである。

今度は通信接続の再確立が完了しているため、プロトコル処理部２２ｂは、Ｓ９の要求に対してパケット生成、データ送信の処理を正常に実行できる。ここで、Ｓ１の送信処理要求はブロック型の要求だったので、プロトコル処理部２２ｂは、必要に応じてブロック制御（例えば送信パケットバッファの空きを待つためのブロック制御など）を行ったうえで、データ送信処理を実行する（Ｓ１０）。これにより、ドライバインタフェース部２２ｄ、ネットワークドライバ部２３を経由して通信部１３によるパケット送信が実行される（Ｓ１１）。プロトコル処理部２２ｂは、データ送信処理を正常に実行してドライバインタフェース部２２ｄにパケット送信を指示すると、当該処理結果をアプリケーションインタフェース部２２ａに通知する（Ｓ１２）。この通知を受けて、アプリケーションインタフェース部２２ａは、データ送信処理の完了をアプリケーション実行部２１に対して通知する（Ｓ１３）。この図４に示すような処理を実行することで、アプリケーション実行部２１は、無線通信端末１が通信中断状態Ｓｔ４にあるか接続状態Ｓｔ３にあるかに関わらず、通常通り通信処理要求を行い、その結果を取得することができる。

次に、ノンブロック型の通信要求があった場合における通信中断状態Ｓｔ４からの復帰処理の流れの例について、図５のフロー図を用いて説明する。

まず、図４のフローの場合と同様に、アプリケーション実行部２１からの送信処理要求（Ｓ２１）を受領したアプリケーションインタフェース部２２ａは、当該要求に応じたデータ送信処理をプロトコル処理部２２ｂに指示する（Ｓ２２）。そして、図４のフローの場合と同様に、プロトコル処理部２２ｂはアクセスポイント２へのデータ送信を行うことができないので、通信エラーの発生を示す返り値（ＥＮＥＴＤＯＷＮ）をアプリケーションインタフェース部２２ａに返す（Ｓ２３）。

Ｓ２３の通知を受けたアプリケーションインタフェース部２２ａは、無線通信端末１の状態を参照して、通信中断状態Ｓｔ４にあるか否かを判定する（Ｓ２４）。もし現在の状態が通信中断状態Ｓｔ４ではなく初期状態Ｓｔ１などであれば、アプリケーションインタフェース部２２ａは、単なる通信エラーが発生したものとして、その結果（返り値ＥＮＥＴＤＯＷＮ）をアプリケーション実行部２１に返す。ここでは通信中断状態Ｓｔ４を仮定しているので、アプリケーションインタフェース部２２ａはＳ２４の判定結果を受けて、接続管理部２２ｅに対して通信接続の再確立を要求する（Ｓ２５）。この図５のフローにおいては、図４のフローの場合と異なり、通信接続の完了待ちのブロック制御は実行されない。そのため、再接続のための処理が実行されている間にも、アプリケーション実行部２１から新たな通信処理要求が発行される場合がある。そこで、アプリケーションインタフェース部２２ａは、Ｓ２１で受け付けた送信処理要求の内容を示す情報（ｃｏｎｎｅｃｔ関数やｓｅｎｄ関数に対して指定された引数など）を、記憶部１２内に用意された未処理データのキューにキューイングしておく（Ｓ２６）。こうすれば、連続してノンブロック型の通信処理要求が発行された場合であっても、これらの通信処理要求をキューイングしておくことで、通信接続が再確立されて準備状態Ｓｔ２に移行した後、当該キュー内の未処理データを順次処理することができる。

ここで、もし無線通信端末１が接続状態Ｓｔ３にあって、Ｓ２２の指示に対するデータ送信処理が正常に実行された場合、プロトコル処理部２２ｂは当該処理結果の通知をアプリケーションインタフェース部２２ａに対して行い、アプリケーションインタフェース部２２ａはこの通知に応じて、データ送信処理が正常に完了したことを示す結果（例えばＴＣＰ通信であれば返り値ＥＩＮＰＲＯＧＲＥＳＳ、ＵＤＰ通信であれば送信バイト数など）をアプリケーション実行部２１に通知したはずである。そこで、Ｓ２４で無線通信端末１が通信中断状態Ｓｔ４にあると判定された場合も、アプリケーションインタフェース部２２ａはデータ送信処理が正常に実行された場合と同様の返り値をアプリケーション実行部２１に返すこととする（Ｓ２７）。すなわち、アプリケーションインタフェース部２２ａは、プロトコル処理部２２ｂにおいてデータ送信処理の試行に失敗しているにも関わらず、アプリケーション実行部２１からの送信処理要求が正常に処理された旨の応答を返すことになる。こうすれば、アプリケーション実行部２１は、通信中断状態Ｓｔ４であっても接続状態Ｓｔ３とあまり変わらないタイミングで、送信処理要求が正常に受け付けられたことを示す応答を得られることになる。

Ｓ２５の再接続要求を受けた接続管理部２２ｅは、図４におけるＳ７の場合と同様に通信接続を再確立し、ネットワークアドレスの再割り当てを受ける（Ｓ２８）。ネットワークアドレスの再割り当てが完了すると、接続管理部２２ｅは、その旨をドライバ制御部２２ｃ経由でプロトコル処理部２２ｂに通知する（Ｓ２９）。なお、図４の場合にはブロック制御を実行中のアプリケーションインタフェース部２２ａに対して再接続完了の通知（Ｓ８）を行うこととしている。しかしながら、この図５の例ではＳ２１の送信処理要求に対するアプリケーションインタフェース部２２ａの処理はＳ２７の処理結果通知で完了しているため、再接続完了通知はプロトコル処理部２２ｂに対してなされる。

Ｓ２９の通知を受けたプロトコル処理部２２ｂは、Ｓ２６でキューイングされた未処理データの実行スケジュールを決定し（Ｓ３０）、決定されたスケジュールに従ってキュー内のデータに応じたデータ送信処理を順次実行する（Ｓ３１）。これに応じて、ドライバインタフェース部２２ｄは、ネットワークドライバ部２３を介して通信部１３にパケット送信を実行させる（Ｓ３２）。

ここで、プロトコル処理部２２ｂは、キュー内の全ての未処理データを直ちに処理してもよいが、そうするとアプリケーション実行部２１が時間的に離れて要求した複数のデータ送信処理が、時間的に近接して連続的に実行される場合があり得る。例えばアプリケーション実行部２１がゲームアプリケーションを実行している場合などにおいては、このようにキュー内の全ての未処理データを直ちに実行してしまうと、一定間隔で実行された処理の内容がまとめて反映されてしまうなどの結果が生じ、ユーザに違和感を感じさせる場合もあり得る。そこで、アプリケーション実行部２１が実行中のアプリケーションプログラムによっては、複数の未処理データがキューに格納された際の時間間隔に対応する時間間隔で各未処理データが処理されるよう、スケジューリングを実行してもよい。

具体的に、アプリケーション実行部２１からこのような制御を行う旨の指定があった場合、アプリケーションインタフェース部２２ａは、キューに未処理データを格納する際に、当該格納の時点を示すタイミング情報を含めて未処理データをキューイングしておく。このタイミング情報は、先行する未処理データの格納時点に対する相対的なタイミングを示す情報であってよい。そして、プロトコル処理部２２ｂは、準備状態Ｓｔ２に移行した際には、このタイミング情報を参照して各未処理データを実行するタイミングを決定する。例えば１番目の未処理データが時刻ｔ１、２番目の未処理データが時刻ｔ２、３番目の未処理データが時刻ｔ３にそれぞれキューイングされた場合、プロトコル処理部２２ｂは、再接続完了後、まず１番目の未処理データを直ちに実行し、その後、時間（ｔ２−ｔ１）の経過を待って２番目の未処理データを、さらにその後時間（ｔ３−ｔ２）の経過を待って３番目の未処理データを、それぞれ実行する。こうすれば、通信接続の再確立後、アプリケーション実行部２１が要求した時間間隔と対応する時間間隔で各データ送信処理が実行されることになり、ユーザから見て、通信接続の再確立に要する時間だけネットワークの遅延が生じているに過ぎないように感じさせることができる。

また、一般に、通信接続の再確立が行われた後は、ＡＲＰ（Address Resolution Protocol）パケットを送信してアドレス解決を行わなければデータ送信処理を実行できない。ところが、プロトコル処理部２２ｂの実装によっては、アドレス解決が完了する前に送信処理の対象となったパケットは廃棄されてしまう場合がある。そこで、１番目の未処理データを送信するためにアドレス解決を行っている間に、２番目以降の未処理データが処理対象とならないよう、アドレス解決までに要する標準的な時間分だけ遅延させたスケジュール設定を行ってもよい。あるいは、アドレス解決が行われるまでの間、未処理データをキューイングしておくための別途のキューを設けてもよい。

ここで、接続状態Ｓｔ３から通信中断状態Ｓｔ４への移行を行うか否か判定するための判定条件の変形例について、説明する。

前述の説明では、所定時間（以下では判定基準時間Ｔｍ１という）にわたってデータ通信が発生しない場合に、通信中断状態Ｓｔ４への移行を実行することとした。しかしながら、この判定基準時間Ｔｍ１は通信状況によって変更されてもよい。例えば通信制御部２２は、通信中断状態Ｓｔ４へ移行した際に、タイマを起動させ、復帰状態Ｓｔ５へ移行するまでの時間（通信中断時間）を計測する。そして、この計測の結果、通信中断時間が所定時間Ｔｍ２（例えば２０秒）未満だった場合には、判定基準時間Ｔｍ１を、所定時間Ｔｍ２を加えた値に変更する。これにより、通信中断状態Ｓｔ４へ移行したものの、比較的短時間で再接続が行われてしまう状況においては、通信中断状態Ｓｔ４へ移行しにくくなるように判定条件を変更することができ、電力消費の節減に比較的寄与しないような通信中断制御を避けることができる。なお、このような判定基準時間Ｔｍ１の変更を行った後も、通信制御部２２は通信中断時間の計測を行い、通信中断時間が所定時間Ｔｍ２以上だった場合には、判定基準時間Ｔｍ１を元の値に戻すこととしてもよい。

また、キープアライブのように一定の時間間隔でのデータ送信が特定のソケット経由で実行される場合、通信制御部２２は、このような通信を考慮して通信中断状態Ｓｔ４への移行判定を行ってもよい。具体例として、アプリケーション実行部２１がアプリケーションインタフェース部２２ａに対してソケットの設定要求（ｓｅｔｓｏｃｋｏｐｔ関数）を発行する場合に、キープアライブ用ソケットであることを指定する。ドライバインタフェース部２２ｄは、このキープアライブ用ソケット経由のデータ通信（キープアライブ通信）のタイミングを監視しておく。そして、判定基準時間Ｔｍ１にわたってデータ通信が発生していないと判定された場合には、キープアライブ通信が次に実行されるタイミングを特定する。この特定の結果、次回のキープアライブ通信が所定時間以内に実行されると判断される場合には、ドライバインタフェース部２２ｄは、通信中断状態Ｓｔ４への移行を直ちには行わずに延期するよう決定する。さらにこの場合、延期の決定から次回のキープアライブ通信が実行されるまでの間に他のソケット経由のデータ通信が発生しなかった場合には、このキープアライブ通信が実行された後、直ちに通信中断状態Ｓｔ４への移行を決定する。こうすれば、短時間でキープアライブ通信のために通信中断状態Ｓｔ４からの復帰を行わなければならない場合には通信中断状態Ｓｔ４への移行を避けることができる。

以上説明した本実施形態に係る無線通信端末１によれば、アプリケーションプログラムの実行状態に関わらず、不要な制御パケットの送信を避けるために通信部１３による通信接続を一時的に切断することができ、アプリケーションプログラムがデータ通信を実行しない間の電力消費を節減することができる。このような制御を実行したとしても、アプリケーション実行部２１の動作は維持されるので、このような通信接続の切断を考慮してアプリケーションプログラムを設計する必要はなくなる。

なお、本発明の実施の形態は、以上説明したものに限られず、各種の変形実施が可能である。例えば通信部１３は無線ＬＡＮの通信インタフェースに限らず、各種の無線通信インタフェースであってよい。具体例として、通信部１３がＢｌｕｅｔｏｏｔｈ（登録商標）インタフェースであって、Ｂｌｕｅｔｏｏｔｈパーソナルエリアネットワークに参加するなどして無線通信端末１が他のＢｌｕｅｔｏｏｔｈ機器と接続される場合にも、上述した方法で通信接続の切断／再開制御が実行されてよい。

１ 無線通信端末、２ アクセスポイント、１１ 制御部、１２ 記憶部、１３ 通信部、１４ 操作部、１５ 表示部、１６ 電源制御部、２１ アプリケーション実行部、２２ 通信制御部、２２ａ アプリケーションインタフェース部、２２ｂ プロトコル処理部、２２ｃ ドライバ制御部、２２ｄ ドライバインタフェース部、２２ｅ 接続管理部、２３ ネットワークドライバ部。

Claims (9)

1. アプリケーションプログラムを実行するアプリケーション実行手段と、
   前記アプリケーション実行手段からの送信処理要求に応じて、通信相手に対してデータを送信する通信制御手段と、
   を含み、
   前記通信制御手段は、
   前記通信相手との間で無線通信接続を確立する接続手段と、
   所与の条件に基づいて、前記通信相手との間の無線通信接続を切断し、通信中断状態に移行する通信中断手段と、
   前記通信中断状態において前記送信処理要求を受け付けた際に、前記通信相手との間の無線通信接続を再確立する再接続手段と、
   前記無線通信接続の再確立を待ってから、前記送信処理要求に係るデータを前記通信相手に送信するデータ送信手段と、
   を含むことを特徴とする無線通信端末。
2. 請求項１記載の無線通信端末において、
   前記データ送信手段は、前記送信処理要求を受け付けた際に、当該送信処理要求に係るデータ送信処理の実行を試み、
   前記再接続手段は、前記試みられたデータ送信処理が失敗した場合に、前記通信相手との間の無線通信接続を再確立する
   ことを特徴とする無線通信端末。
3. 請求項１又は２記載の無線通信端末において、
   前記データ送信手段は、前記再接続手段が前記無線通信接続の再確立を実行している間、前記送信処理要求の受け付けをブロックするブロック制御を実行し、前記無線通信接続の再確立が完了後、当該ブロック制御を解除して、前記送信処理要求に係るデータの送信を行う
   ことを特徴とする無線通信端末。
4. 請求項２記載の無線通信端末において、
   前記データ送信手段は、前記試みられたデータ送信処理が失敗し、かつ、前記再接続手段による前記無線通信接続の再確立が実行される場合に、前記アプリケーション実行手段に対して前記送信処理要求が正常に処理された旨の応答を返す
   ことを特徴とする無線通信端末。
5. 請求項２又は４記載の無線通信端末において、
   前記試みられたデータ送信処理が失敗した場合に、前記アプリケーション実行手段から受け付けた送信処理要求の内容を示す情報をキューに格納する格納手段をさらに含み、
   前記データ送信手段は、前記無線通信接続の再確立が完了した後、前記キューに記憶された情報に応じて、前記送信処理要求に係るデータを前記通信相手に送信する
   ことを特徴とする無線通信端末。
6. 請求項５記載の無線通信端末において、
   前記格納手段は、前記送信処理要求の内容を示す情報を、前記キューへの格納時点を示すタイミング情報とともに前記キューに格納し、
   前記データ送信手段は、前記無線通信接続の再確立が完了した後、前記タイミング情報に応じて決定されるタイミングで、前記送信要求に係るデータを前記通信相手に送信する
   ことを特徴とする無線通信端末。
7. アプリケーションプログラムを実行するアプリケーション実行手段からの送信処理要求に応じて、通信相手に対してデータを送信する無線通信端末の制御方法であって、
   前記通信相手との間で無線通信接続を確立するステップと、
   所与の条件に基づいて、前記通信相手との間の無線通信接続を切断し、通信中断状態に移行するステップと、
   前記通信中断状態において前記送信処理要求を受け付けた際に、前記通信相手との間の無線通信接続を再確立するステップと、
   前記無線通信接続の再確立を待ってから、前記送信処理要求に係るデータを前記通信相手に送信するステップと、
   を含むことを特徴とする無線通信端末の制御方法。
8. アプリケーションプログラムを実行するアプリケーション実行手段からの送信処理要求に応じて、通信相手に対してデータを送信する無線通信端末を制御するためのプログラムであって、
   前記通信相手との間で無線通信接続を確立する接続手段、
   所与の条件に基づいて、前記通信相手との間の無線通信接続を切断し、通信中断状態に移行する通信中断手段、
   前記通信中断状態において前記送信処理要求を受け付けた際に、前記通信相手との間の無線通信接続を再確立する再接続手段、及び
   前記無線通信接続の再確立を待ってから、前記送信処理要求に係るデータを前記通信相手に送信するデータ送信手段、
   として前記無線通信端末を機能させるためのプログラム。
9. 請求項８記載のプログラムを記憶したコンピュータ読み取り可能な情報記憶媒体。

Images