JP4888286B2 - 無線通信ドライバプログラム、無線通信端末及び無線通信インタフェース制御方法 - Google Patents

Description

本発明は、無線通信端末における複数の動作状態を持つ無線通信インタフェースの制御技術に関するものである。

当初、無線通信は音声通話を中心に利用されてきた。近年、無線通信技術の進歩に伴い携帯機器における無線通信の利用が拡大し、ＰＤＡ（Personal Digital Assistants）等の携帯情報端末によるデータ通信においての利用も急速に広まっている。

このような携帯無線機器においては、消費電力を抑えることが課題となっている。これに伴い、携帯無線機器には、通信が行われていない動作状態において積極的に送受信動作を止め動作していない回路への電力供給を停止するといった省電力モードを持つものがある。

ところで、現在、データ通信で利用されるネットワークプロトコルはＩＰ(Internet Protocol)が主流である。ＩＰは、パケット（データグラム）単位の自律的配送を原則とするプロトコルであり、通信開始及び通信終了のシグナリングを行う仕組みを備えていない。必要に応じて、上位層となるトランスポート層又はセッション層のプロトコルにおいてエンドツーエンドシグナリングが行われる。

従って、ＩＰデータ通信を行う携帯無線端末では、無通信状態にあるか否かを確実に判断することが困難である。一般的には、無通信状態の継続時間により、無通信状態にあるか否かが判断される。一方、ＩＰデータ通信を開始する際には何の予告もなく新たなパケットを送受信する必要がある。

高速無線通信サービスを提供するために規格化が進められているＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）（IEEE802.16ｅ）では、このような消費電力モードに対応するアイドル（Idle）モードという動作状態が定義されている。ＷｉＭＡＸにおけるアイドルモードは、無線基地局（以降、ＢＳと表記する）と無線端末局（以降、ＭＳと表記する）との間のネゴシエーションにより通信を行わない時間を決定する仕組みを持つ。ＷｉＭＡＸには、ＢＳ主導でＭＳをアイドルモードへ移行する場合とＭＳ主導で自己をアイドルモードへ移行する場合とが用意されている。

一方、ＭＳにおけるアイドルモードから通常モードへの復帰処理は、ＢＳ側でＭＳへ送信するデータが生じた場合にはＢＳ主導となり、ＭＳでＢＳ側へ送信するデータが生じた場合にはＭＳ主導となる。具体的には、ＢＳ側からアイドルモードのＭＳへ送信するデータが発生した場合には、ＢＳが定期的にブロードキャスト送信しているページングメッセージ中に送信先ＭＳについて受信すべきデータがあることを示す信号を送信し、これを受信したＭＳがアイドルモードから通常モードに移行する手続きを行う。この手続完了後、ＢＳからＭＳに当該データが送信される。アイドルモードのＭＳからＢＳ側へ送信するデータが生じた場合には、ＭＳがアイドルモードから通常モードに移行する手続きを行い、その後、ＭＳが通常モードに復帰し次第、当該データを送信する。

ＷｉＭＡＸにおけるＭＳのようなＩＰデータ通信を行う携帯無線端末は、概略、無線通信インタフェース部（以降、インタフェース部と表記する）とそれ以外の機能部（以降、ホスト部と表記する）とから構成される。インタフェース部は、無線信号処理回路等を含
み、ホスト部から送られる送信データを無線信号へ変換し無線基地局へ送信し、無線基地局から受信された無線信号を受信データに変換しホスト部へ送る。ホスト部では、ＯＳ（Operating System）により上記インタフェース部等の各種インタフェースが管理され、ドライバと呼ばれるソフトウェアモジュールがＯＳからの指示により上記インタフェース部との間のデータの送受信制御を行う。

なお、本願発明に関連する先行技術文献には、以下の開示された文献がある。
特開平１０−３２０３２７号公報 特開２００４−３２８２２１号公報 特開平１０−１７８４５０号公報

上述のような携帯無線機器において、省電力モード（アイドルモード）から通常モードへ復帰する際に、電力供給を再開してから送受信処理が完全に動作するようになるまで遅延時間が生ずる。これは、無線信号の送受信処理を実行する無線信号処理回路を構成するＰＬＤ（Programmable Logic Device）、ＡＦＣ（Auto Frequency Control）、ＡＧＣ（Auto Gain Control）等のフィードバック動作等の処理遅延に基づくものである。また、上述のように無線リンクを利用するネットワーク層プロトコルがＩＰの場合、予告なくデータ送受信機会が発生する。

このような携帯無線機器において、アイドルモードから復帰しようとするインタフェース部が、上記遅延時間の間無線基地局へ送信すべきデータを抑制するように直接的にホスト部を制御するには、新たな仕組みを追加する必要がある。例えば、インタフェース部からホスト部に対しデータ送信抑制を指示できるような仕組み、或いは上記遅延時間の間、インタフェース部又はドライバにおいて送信データを保持する仕組み等が考えられる。

前者の仕組みでは、インタフェース部がホスト部に動作状態を認識させるようにし、インタフェース部がアイドルモードの場合にはホスト部にデータ送信を抑制させるという手順を導入する必要がある。しかしながら、この手法では、実装の難易度が増すうえに、ホスト部におけるインタフェース部の状態管理が複雑化するという問題点がある。

一方、後者の仕組みでは、ドライバ又はインタフェース部に十分な容量のバッファメモリを備える必要があり、余分なリソースを消費することになる。インタフェース部にバッファメモリを多く備えるように構成すれば、部品点数が増大し、インタフェース部のコストが増すという問題点がある。更に、ＯＳの外部でデータを保持することは、無線通信インタフェースの切断手順や電波状態の悪化による一時的な通信途絶等の異常シーケンスからの回復手順が難しくなるという問題点もある。また、ＯＳの管理外で保持されるデータの喪失に対する処理をＯＳは実行することができないため、データの紛失が起こりやすい。

本発明の目的は、このような問題点に鑑みてなされたものであり、簡易かつ効率的な構成で、無線通信インタフェースの複数の動作状態を適切に制御する技術を提供することにある。

本発明は、上述した課題を解決するために以下の構成を採用する。即ち、本発明の第一の態様は、複数の動作状態として少なくとも待機モードと通常モードとを有する無線通信インタフェースと、アドレス解決プロトコルを含むデータリンク層で伝送されるフレーム（例えばＭＡＣ（Media Access Control）フレーム）を処理するフレーム処理手段と、の
間の仲介処理を無線通信端末に実行させる無線通信ドライバプログラムに関し、この無線通信ドライバプログラムが、無線通信端末に、上記無線通信インタフェースの動作状態を管理し、上記フレーム処理手段からアドレス解決要求フレームを受けた場合で上記無線通信インタフェースの動作状態が待機モードである場合に、上記無線通信インタフェースに待機モードから通常モードへ復帰するように指示し、上記無線通信インタフェースの動作状態が通常モードへ復帰したことを確認する状態管理ステップと、この状態管理ステップにより上記無線通信インタフェースの動作状態が通常モードへ復帰したことが確認された後に、上記フレーム処理手段から送られたアドレス解決要求フレームに対するアドレス解決応答フレームを生成し、このアドレス解決応答フレームを上記フレーム処理手段に送る模擬応答ステップと、を実行させるというものである。

ここで、無線通信インタフェースの動作状態に関し、通常モードとは通常時の無線通信を行う動作状態であり、待機モードとはその通常モード以外の動作状態であればよい。例を挙げれば、待機モードは、消費電力を削減するために無線信号処理回路への電力供給を停止する状態であってもよい。以降、本発明の第一の態様における無線通信ドライバプログラムが無線通信端末上で実行されることにより実現される機能を本発明の第一態様に対応するドライバ手段と表記することとする。

上記無線通信端末のフレーム処理手段では、送信すべきフレーム（例えばＭＡＣ（Media Access Control）フレーム）が生じた場合、このＭＡＣフレームに関しアドレス解決処理が実行され、アドレス解決要求フレームが本ドライバ手段に送られる。以降、このフレーム処理手段では、このアドレス解決要求フレームの応答としてアドレス解決応答フレームを受けるまでアドレス解決処理が完了しないため、当該送信すべきフレーム（例えばＭＡＣ（Media Access Control）フレーム）の送信が抑制される。

一方、本発明の第一態様に対応するドライバ手段では、無線通信インタフェースの動作状態が管理され、必要に応じて、この無線通信インタフェースに動作状態の変更指示が出される。ここで、上記アドレス解決要求フレームが本ドライバ手段に送られた場合、本ドライバ手段では、無線通信インタフェースに通常モードへの復帰指示が出され、無線通信インタフェースが通常モードへ復帰したことが確認された後、上記アドレス解決要求フレームに対するアドレス解決応答フレームが生成され、上記フレーム処理手段に送られる。すなわち、フレーム処理手段にアドレス解決応答フレームが返されるのは、無線通信インタフェースにおける無線通信回路の復帰動作により生じる遅延を含めて、当該無線通信インタフェースが通常モードへ移行されたことが確認された後となる。

すなわち、本発明の第一態様によれば、無線通信インタフェースの復帰処理に必要な遅延時間が、本ドライバ手段がアドレス解決応答フレームをフレーム処理手段に返さないことで吸収され、この間、フレーム処理手段によるフレーム送信処理を抑制することができる。従って、本発明の第一の態様によれば、予告なく送信機会の生ずるフレーム（例えばＭＡＣ（Media Access Control）フレーム）の送信時においても、無線通信インタフェースの状態制御を適切に行うことができる。

更に、このような効果を得るにあたり、フレーム処理手段は一般的なデータリンク層の処理手段であればよく、この本発明の第一の態様に対応するドライバ手段のみで当該効果を得ることができる。

また、好ましくは、本発明の第一の態様に対応するドライバ手段が、上記状態管理ステップにより無線通信インタフェースが通常モードから待機モードへ移行したことが確認された場合に、上記フレーム処理手段で利用されるアドレス解決テーブルのエントリを無効化するテーブル更新ステップを更に実行するようにする。フレーム処理手段により実行さ
れるアドレス解決処理は、一般的に、宛先アドレスに対応する物理アドレス（例えばＭＡＣアドレス）がアドレス解決テーブルに登録されていない場合に実行される。

これによれば、再度、フレーム処理手段において送信すべきデータが生じ、無線通信インタフェースを待機モードから通常モードへ復帰させる必要がある場合においても、その送信すべきデータの宛先アドレスに対応する物理アドレスが登録されたエントリは無効化されているために、確実に、フレーム処理手段にアドレス解決処理を実行させることができる。

また、好ましくは、本発明の第一の態様に対応するドライバ手段が、無線通信インタフェースにおける通信状況を調査し、時間閾値としての無通信判断時間より長く通信がされていない状況が継続されている場合に、無線通信インタフェースが無通信状態にあると判断する通信状況判断ステップと、上記フレーム処理手段で利用されるアドレス解決テーブルのエントリの有効期間をこの無通信判断時間相当若しくは無通信判断時間よりも短い期間に設定するテーブル更新ステップとを更に実行するようにする。

また、上記テーブル更新ステップに替え、上記無通信判断時間を上記フレーム処理手段で利用されるアドレス解決テーブルのエントリの有効期間相当若しくは当該アドレス解決テーブルのエントリの有効期間よりも長い期間に設定する閾値更新ステップを実行するようにする。

これによれば、上記模擬応答ステップで生成されフレーム処理手段に送られるアドレス解決応答フレームにより登録されるアドレス解決テーブルのエントリに関し、無通信状態と判断され無線通信インタフェースが待機モードへ移行されるときには、そのエントリの有効期間が満了し、そのエントリが無効にされる。

従って、再度、フレーム処理手段において送信すべきデータが生じ、無線通信インタフェースを待機モードから通常モードへ復帰させる必要がある場合においても、確実に、フレーム処理手段にアドレス解決処理を実行させることができる。

また、好ましくは、本発明の第一の態様に対応するドライバ手段が、上記フレーム処理手段から送られるフレーム（例えばＭＡＣ（Media Access Control）フレーム）を無線通信インタフェースで利用される通信データに変換し、無線通信インタフェースから送られる通信データを上記フレーム処理手段で処理されるフレーム（例えばＭＡＣ（Media Access Control）フレーム）に変換する変換ステップと、無線通信インタフェースを利用した通信に関し、上記フレーム処理手段が、無線通信インタフェースを利用した通信には不必要なアドレス解決プロトコルを含むデータリンク層プロトコルを実行するように制御する制御ステップと、を更に実行するようにする。

本来、無線通信インタフェースを制御する無線通信ドライバであれば、一般的には、この無線通信インタフェースを利用した通信において、フレーム（例えばＭＡＣ（Media Access Control）フレーム）を処理するフレーム処理手段から処理要求が送られてくることはない。しかしながら、本発明の第一態様は、無線通信インタフェースの通常モードへの復帰にかかる遅延時間をフレーム処理手段によるアドレス解決処理を本ドライバ手段により模擬応答することにより吸収するものである。従って、本発明の第一の態様に対応するドライバ手段は、無線通信インタフェースを利用した通信に関し、本来不必要なアドレス解決プロトコルを含むデータリンク層プロトコルをフレーム処理手段が実行するように制御する。

また、好ましくは、本発明の第一の態様に対応するドライバ手段が、無線通信インタフ
ェースから送信されるべきデータを格納するバッファを生成させる生成ステップを更に実行し、上記変換ステップが、無線通信インタフェースの動作状態が待機モードにある場合で上記フレーム処理手段からアドレス解決要求フレーム以外のフレーム（例えばＭＡＣ（Media Access Control）フレーム）を受けた場合に、このフレーム（例えばＭＡＣ（Media Access Control）フレーム）若しくはこのフレームから変換された通信データを上記バッファに格納し、上記状態管理ステップにより無線通信インタフェースが通常モードへ復帰したことが確認された後に、上記バッファに格納された通信データを無線通信インタフェースへ送るようにする。

これによれば、ブロードキャストのようなアドレス解決処理が不要なフレーム（例えばＭＡＣ（Media Access Control）フレーム）がフレーム処理手段から送られてきた場合や、その他の設定によりアドレス解決処理が不要となったフレーム（例えばＭＡＣ（Media Access Control）フレーム）がフレーム処理手段から送られてきた場合にも、無線通信インタフェースの通常モードへ復帰する際の遅延時間を当該バッファで吸収することができる。

また、本発明の他の態様は、上記フレーム処理手段及び無線通信インタフェースと共に、上記第一の態様に係る無線通信ドライバプログラムにより実現されるドライバ手段を備える無線通信端末であってもよい。また、本発明の他の態様は、上記第一の態様に係る無線通信ドライバプログラムにより実現される無線通信インタフェース制御方法であってもよいし、上記第一の態様に係る無線通信ドライバプログラムがコンピュータに読み取り可能な記録媒体に記録されたものであってもよい。

本発明によれば、簡易かつ効率的な構成で、無線通信インタフェースの複数の動作状態を適切に制御する技術を提供することができる。

以下、図面を参照して、本発明の各実施形態における無線情報端末装置（以降、単に無線端末又はＭＳと表記する）についてそれぞれ説明する。なお、以下に述べる各実施形態の構成はそれぞれ例示であり、本発明は以下の各実施形態の構成に限定されない。

［第一実施形態］
以下、本発明の第一実施形態における無線端末について説明する。

〔接続形態〕
まず、第一実施形態における無線端末と無線通信システムとの接続形態について図１を用いて説明する。図１は、第一実施形態における無線端末と無線通信システムとの接続形態を示す概念図である。

第一実施形態における無線端末１０は、その位置を通信可能エリアとする無線基地局（以降、ＢＳと表記する）４０と無線通信を行うことにより、図１に示される無線通信システムと接続する。図１に示される無線通信システムは、ＡＳＮ（Access Service Network）４３とＩＰネットワーク４８等のその他のネットワークとから構成される。

ＡＳＮ４３は、複数のＢＳ４０とＡＳＮゲートウェイ（以降、ＡＳＮ−ＧＷと表記する）とがそれぞれ接続されることで形成される。ＡＳＮ４３は、ＡＳＮ−ＧＷ４５を介してＩＰネットワーク４８に接続される。ＩＰネットワーク４８は例えばインターネットである。ＡＳＮ−ＧＷ４５は、複数のＢＳ４０に接続されこれらＢＳ４０を管理する。例えば、ＡＳＮ−ＧＷ４５は、管理配下のＢＳ４０間のハンドオーバ等を制御する。ＡＳＮ−Ｇ
Ｗ４５は、このように複数のＢＳ４０を管理し、その他のゲートウェイ等とデータをやりとりすることにより、無線端末１０に対しＩＰネットワーク４８へのアクセスサービスを提供する。

ＢＳ４０は、通信エリア内の無線端末１０をＡＳＮ４３に無線通信により接続する。ＢＳ４０は、ＡＳＮ４３を介してＡＳＮ−ＧＷ４５と接続されており、無線端末１０から送信された信号（ＩＰパケット）をＡＳＮ−ＧＷ４５へ転送し、ＡＳＮ−ＧＷ４５から送信されたＩＰパケットを無線端末１０へ無線送信する。無線端末１０とＢＳ４０との間の無線通信プロトコルとしてＷｉＭＡＸ（IEEE802.16e等）が利用される。なお、本発明は、無線端末１０とＢＳ４０との間の無線通信プロトコルを限定するものではないため、ＧＳＭ（Global System for Mobile Communications）、ＷＣＤＭＡ（Wideband Code Division Multiple Access）等が利用されてもよい。ＢＳ４０と無線端末１０との間の無線リンク確立及び解放、ＩＰアドレス割り当て等の処理については、周知技術を用いればよいため、説明を省略する。

ＢＳ４０は、一般的に、共通制御チャネル（例えばＰＩＣＨ（Page Indication Channel））を使って、ページングメッセージ中に無線端末１０（又は無線端末１０の属するグループのうちのいずれかの無線端末）の受信すべきデータがあることを示す信号（例えばＰＩ（Paging Indicator）であり、以降、ＰＩ信号と表記する）を送信している。このＰＩ信号を受信した無線端末１０は、このＰＩ信号を判定することにより自身（又は自身が属するグループのうちのいずれかの無線端末）宛てのデータがあることを示していると認識すると、ページングメッセージを受信しこれに含まれるデータが自身宛か否かを判断する。もちろん、ＢＳ４０はＰＩＣＨを使ったＰＩ信号の送信をサポートせず、無線端末１０が自身に割り当てられているページングメッセージを常に受信して自身宛か否かを判定するようにしてもよい。

本実施形態では、このＰＩ信号を用いず、無線端末１０がページングメッセージを直接判定する場合を例に挙げることとする。本実施形態で例に挙げるＷｉＭＡＸでは、ページングメッセージは、ＭＡＣ Ｍａｎａｇｅｍｅｎｔ Ｍｅｓｓａｇｅ(以降、ＭＭＭと表記する)によりブロードキャストでＢＳ４０から無線端末１０に配信される。ＭＭＭは、無線インタフェースを介して送受信されるユーザデータと同様に、ＭＡＣ層のＰＤＵ（Protocol Data Unit）に収められる。ＭＭＭは、ＷｉＭＡＸのＭＡＣ層におけるデータリンク識別子に相当する、専用に割り当てられたＣｏｎｎｅｃｔｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ（以降、ＣＩＤと表記する）で識別される。上記ページングメッセージは、ブロードキャスト用のＣＩＤが用いられ送信される。

また、ＢＳ４０は、背景技術の項で説明したような省電力モード又はアイドルモードに移行している無線端末１０に対して、待機状態移行要求を示す信号を送信する。また、ＢＳ４０は、待機状態移行の要求を受け入れることを決定すると、無線端末１０に対し待機状態移行応答を送信する。これら待機状態移行要求及び待機状態移行応答を示す各信号は、ＷｉＭＡＸでは、ＭＭＭによりＢＳ４０と無線端末１０との間で授受される。より具体的には、これら信号は、ＢＳ４０から無線端末１０方向への通信においては、ＭＭＭの「ＤＲＥＧ−ＲＥＱ」メッセージが利用され、無線端末１０からＢＳ４０方向への通信においては、ＭＭＭの「ＤＲＥＧ−ＣＭＤ」メッセージが利用される。以降の説明では、単に、これら信号を待機状態移行要求又は待機状態移行応答と表記する場合もある。

本実施形態における無線端末１０は、このような無線通信システムと接続することにより、ＩＰネットワーク４８上のサーバ５０、ユーザ端末装置５０等とＩＰプロトコルを用いて通信を行う。以降、無線端末１０の通信相手となる端末装置を通信先端末５０と総称する。

〔装置構成〕
次に、第一実施形態における無線端末の装置構成について図１及び２を用いて説明する。なお、以下に説明するのは、あくまで本願発明に関連する構成についてのものであるため、当該無線端末にその他の構成若しくは機能部が含まれていても何ら問題ない。

本実施形態における無線端末１０は、ＣＰＵ（Central Processing Unit）、メモリ、入出力インタフェース等を備える端末装置であり、例えば、携帯電話、ＰＤＡ（Personal
Digital Assistant）、パーソナルコンピュータ等である。無線端末１０は、ＲＯＭ（Read Only Memory）、ハードディスク等に記憶されている各種ソフトウェアがＣＰＵにより実行されることにより実現されるホスト部１５と、上記入出力インタフェースの１つである無線通信インタフェース部（以降、Ｉ／Ｆ部と表記する）３０とを少なくとも備える。

以下、第一実施形態における無線端末１０の機能構成について図２を用いて説明する。図２は、第一実施形態における無線端末１０の機能構成を示すブロック図である。

〈無線通信インタフェース部（Ｉ／Ｆ部）〉
Ｉ／Ｆ部３０は、ＷｉＭＡＸをサポートする無線通信インタフェースカード（インタフェースボード或いは専用チップセット）である。Ｉ／Ｆ部３０は、送受信処理を実行する機能部として、無線ＭＡＣ（Media Access Control）部３１、ＲＦ（Radio Frequency）部３２等を備える。以下、Ｉ／Ｆ部３０を構成する各機能部について簡単に概略を説明する。

ＲＦ部３２は、アンテナ１１で受信された高周波アナログ信号を処理し、ＷｉＭＡＸの所定チャネルについて増幅され変換されたベースバンド信号を無線ＭＡＣ部３１へ送る。無線ＭＡＣ部３１は、ＲＦ部３２から送られるベースバンド信号をデジタルベースバンド信号に変換し、このデジタルベースバンド信号を復調及び復号する。無線ＭＡＣ部３１は、このような処理により出力されるデータストリーム信号からＩＰパケットを構成し、ホスト部１５へ送る。

また、無線ＭＡＣ部３１は、ホスト部１５から送信されるべきＩＰパケットを受けると、これをデータストリーム信号に変換し、この変換された信号を符号化及び変調する。無線ＭＡＣ部３１は、このような処理により出力されるデジタルベースバンド信号をアナログ信号に変換し、ＲＦ部３２へ送る。ＲＦ部３２は、無線ＭＡＣ部３１から送られたアナログ信号を高周波アナログ信号に変換し、アンテナ１１からこの高周波アナログ信号を送出する。

Ｉ／Ｆ部３０は、無通信状態となる場合に不要となる回路への電力供給を停止する待機モード（上述の省電力モード若しくはアイドルモードと同様）を持つ。Ｉ／Ｆ部３０の待機モードと通常モードとの間の状態遷移については、ＢＳ４０主導で実行される場合と本無線端末１０主導で実行される場合とがある。なお、本発明は、Ｉ／Ｆ部３０の有する動作モードを限定するものではないため、通常の通信を行う動作状態としての通常モードとその通常モード以外の動作状態として待機モードがあればよい。

無線端末１０主導で待機モードへ移行する場合とは、Ｉ／Ｆ部３０が、後述するホスト部１５のドライバ２５から待機状態移行指示を受けた場合である。ＢＳ４０主導で待機モードへ移行する場合とは、Ｉ／Ｆ部３０が、ＢＳ４０から待機状態移行要求を示す信号を受信した場合である。Ｉ／Ｆ部３０は、待機モードへ移行すると、無線ＭＡＣ部３１及びＲＦ部３２等の所定の回路への電力供給を停止し、ホスト部１５のドライバ２５へ待機モード移行完了を通知する。なお、本発明は、このＩ／Ｆ部３０の待機モード時に実際に行
われる省電力制御を限定するものではないため、無線ＭＡＣ部３１及びＲＦ部３２の送受信処理に関わる全ての回路への電力供給が停止されてもよいし、これらのうちの一部の回路への電力供給が停止されるようにしてもよい。

一方、無線端末１０主導で通常モードへ復帰する場合とは、Ｉ／Ｆ部３０が、ホスト部１５のドライバ２５から復帰指示を受けた場合である。ＢＳ４０主導で通常モードへ復帰する場合とは、Ｉ／Ｆ部３０が、ＢＳ４０から送信されるページングメッセージを判定することにより自身宛のデータが存在することを認識した場合である。通常モードへ復帰すると、Ｉ／Ｆ部３０は、待機モード移行時に電力供給を停止した回路に対し電力供給を再開し、ＢＳ４０との間で送受信動作再開手続き（無線リンク確立等）を実施する。Ｉ／Ｆ部３０は、当該手続きが完了すると、ホスト部１５のドライバ２５へ通常モードへの復帰完了を通知する。

ところで、無線端末１０のための当該ページングメッセージは、ＢＳ４０から定期的にブロードキャスト送信されている。従って、Ｉ／Ｆ部３０は、待機モードであってもこのページングメッセージを受信すべきタイミングで必要な回路に対し電力供給を行い、このページングメッセージを受信する。以降、Ｉ／Ｆ部３０におけるこのページングメッセージを受信し得る動作モードを一時復帰モードと表記する。ここで、Ｉ／Ｆ部３０におけるこの一時復帰モードは、通常モードと同じ動作状態であってもよいし、ページングメッセージを受信するために必要な回路のみに対し電力供給が行われるモードとし、通常モードよりも省電力化を図れる動作状態であってもよい。

Ｉ／Ｆ部３０は、このページングメッセージにおいて自身宛のデータがないことを検知した場合には、次の受信タイミングまで待機モードとなる。なお、ページングメッセージの判定処理は、Ｉ／Ｆ部３０の無線ＭＡＣ部３０内の回路で実行するようにしてもよいし、ホスト部１５のドライバ２５により実行されるようにしてもよい。また、Ｉ／Ｆ部３０の一時復帰モードへの移行指示は、ページングメッセージの判定処理を実行する機能部から出されるようにすればよい。

〈ホスト部〉
ホスト部１５は、ＯＳ（Operating System）２０、ドライバ２５、アプリケーション１６等から構成される。

〈〈ドライバ〉〉
ドライバ２５は、ＯＳ２０と連携することにより上述のＩ／Ｆ部３０を制御する。ドライバ２５は、ＯＳ２０からの指示に応じて、Ｉ／Ｆ部３０に対して必要な送受信処理の指示を出す。ここで、ドライバ２５は、ＷｉＭＡＸを実現するＩ／Ｆ部３０をＥｔｈｅｒｎｅｔ（登録商標）（以降、Ｌ２と表記する）デバイスとしてＯＳ２０に認識させるように動作する。

無線端末１０とＢＳ４０との間の無線リンクは、ＢＳ４０がＨＵＢとなり複数の無線端末を収容するネットワークトポロジを前提とした無線プロトコルで実現される。本実施形態の例によれば、無線端末１０のＩ／Ｆ部３０は、ＢＳ４０のみとポイントツーポイントで接続される。このため、無線端末１０とＢＳ４０との間の無線リンクにおいて利用されるＭＡＣアドレスはあくまで個体の識別が目的であり、Ｌ２プロトコルのようにフレームの送信先（受け手）を指定するためのものではない。従って、本来、ＷｉＭＡＸを通信インタフェースとして利用するＯＳ２０では、Ｌ２通信で利用されるようなＡＲＰ（Address Resolution Protocol）手順、及びＬ２フレームの生成を必要としない。

本実施形態では、ドライバ２５がＩ／Ｆ部３０をＬ２デバイスとしてＯＳ２０に認識さ
せるすなわちＬ２ドライバとして動作するため、ＯＳ２０は、通信時にはこのドライバ２５を利用してＬ２通信を実行する。すなわち、ＯＳ２０は、Ｌ２フレームの送受信をドライバ２５に依頼し、必要に応じてＡＲＰ手順を実行する。ドライバ２５は、このＯＳ２０により実行されるＬ２通信があたかも正常に動作しているかのように見せかけるＬ２模擬処理を実行する。本実施形態における無線端末１０は、このようなＬ２模擬処理のうちのＡＲＰ模擬手順を利用することにより、Ｉ／Ｆ部３０が待機モードから通常モードへ復帰する際のタイムラグ（遅延時間）を吸収するべく、ＯＳ２０からドライバ２５に対して送信データを送ることを一時的に停止させる。

また、ドライバ２５は、Ｉ／Ｆ部３０の待機モードと通常モードとの間の状態遷移を管理する。無線端末１０主導で通常モードに復帰する場合、すなわちＩ／Ｆ部３０が待機モード時にＯＳ２０から送信すべきＬ２フレームを受けた場合には、ドライバ２５は、Ｉ／Ｆ部３０へ復帰指示を出す。逆に、無線端末１０主導で待機モードに移行する場合、すなわちＩ／Ｆ部３０が通常モード時に所定時間無通信状態が継続したと判断された場合に、ドライバ２５はＩ／Ｆ部３０へ待機状態移行指示を出す。

Ｌ２模擬処理を実行するドライバ２５の詳細機能部については後述する。

〈〈ＯＳ〉〉
ＯＳ２０は、ハードウェア管理、プロセス管理、メモリ管理等を行い、これら管理リソースをアプリケーション１６に提供する。ＯＳ２０としては、例えば、Ｗｉｎｄｏｗｓ（登録商標）やＬｉｎｕｘ（登録商標）等が利用される。ＯＳ２０は、標準的なＬ２及びＩＰのプロトコルスタックを備える。なお、Ｉ／Ｆ部３０の種類に応じて必要となる特殊処理についてはドライバ２５が吸収する。ＯＳ２０は、上述のようにドライバ２５がＬ２ドライバとして動作するため、通信を行う場合には上記プロトコルスタックを実行する。ＯＳ２０のプロトコルスタックは、バッファ２１、Ｌ２通信制御部２２、ＡＲＰテーブル２３等を備える。

Ｌ２通信制御部２２は、Ｌ２通信を実現するための処理を実行する。具体的には、Ｌ２通信制御部２２は、アプリケーション１６から送られバッファ２１に格納される送信データを取り出し、この送信データに所定のＬ２ヘッダを付与することでＬ２フレームを生成し、ドライバ２５へ送る。また、Ｌ２通信制御部２２は、ドライバ２５から送られるＬ２フレームから受信データを抽出し、アプリケーション１６へ渡すためにその受信データをバッファ２１に格納する。バッファ２１は、アプリケーション１６へ渡すための受信データ及びドライバ２５へ送るための送信データを一時格納する。

Ｌ２通信制御部２２は、Ｌ２ヘッダを付与する際に、アドレス解決処理を実行する。具体的には、Ｌ２通信制御部２２は、Ｌ２ヘッダを付与する際に、ＩＰパケットの送信先ＩＰアドレスに対応する送信先ＭＡＣアドレスを取得するため、ＡＲＰテーブル２３を参照する。Ｌ２通信制御部２２は、ＡＲＰテーブル２３に送信先ＩＰアドレスに対応するＭＡＣアドレスが登録されていないと判断すると、ＡＲＰ手順を実行する。Ｌ２通信制御部２２は、このＡＲＰ手順により当該送信先ＩＰアドレスに対応する宛先ＭＡＣアドレスを取得すると、これに対応するエントリをＡＲＰテーブル２３に登録すると共に、送信すべきＩＰパケットにこの取得された宛先ＭＡＣアドレスの設定されたＬ２ヘッダを付与しＬ２フレームを構築する。Ｌ２通信制御部２２は、このＬ２フレームを送出するようにドライバ２５に指示する。

このように、アドレス解決処理には、ＡＲＰテーブル２３が利用される。ＡＲＰテーブル２３には、宛先ＩＰアドレスと宛先ＭＡＣアドレスとのリンク情報が格納される。Ｌ２通信制御部２２は、このＡＲＰテーブル２３への新たなエントリの追加及び登録されてい
るエントリの削除を行う。

なお、上述のようなプロトコルスタックを含むＯＳ２０の機能は一般的な周知技術であり、本発明は、このようなＯＳ２０の機能を改造することなく利用することができる。また、図２では、説明の便宜のため、ＯＳ２０とドライバ２５とを区別して示したが、ドライバ２５はＯＳ２０の機能の一部として動作する。

〈〈アプリケーション〉〉
アプリケーション１６は、ＯＳ２０の管理下において実行され、本実施形態ではＩＰ通信を伴うアプリケーションを対象とする。アプリケーション１６は、例えば、ＷＥＢブラウザ、ＪＡＶＡ（登録商標）等である。なお、本発明は、ＩＰ通信を伴うアプリケーションであればこのアプリケーション１６の機能を限定するものではないため、アプリケーション１６はどのようなアプリケーションであってもよい。

〈〈ドライバのＬ２模擬処理〉〉
ドライバ２５は、Ｌ２模擬処理を実行するために、Ｌ２フレーム処理部２６、ＡＲＰ模擬処理部２７、待機状態制御部２８、通信状態検出部２９等を備える。

Ｌ２フレーム処理部２６は、ＯＳ２０から送られるＬ２フレームを受け、このＬ２フレームからＩＰパケットを抽出する。Ｌ２フレーム処理部２６は、抽出されたＩＰパケットをＩ／Ｆ部３０に送り、Ｉ／Ｆ部３０がこのＩＰパケットを送出するように制御する。Ｌ２フレーム処理部２６は、この抽出されたＩＰパケットがＡＲＰリクエストパケットであると判断した場合には、このＡＲＰリクエストパケットをＡＲＰ模擬処理部２７に送る。

一方、Ｌ２フレーム処理部２６は、Ｉ／Ｆ部３０から受信ＩＰパケットを受けると、その受信ＩＰパケットに所定のＬ２ヘッダが付与されたＬ２フレームを生成する。Ｌ２フレーム処理部２６は、このように生成されたＬ２フレームをＯＳ２０に送る。ここで、Ｌ２フレーム処理部２６は、ＯＳ２０から送られるＬ２フレームを受けた場合及びＩ／Ｆ部３０から受信ＩＰパケットを受けた場合に、それぞれ送受信処理が行われている旨の通知（以降、この通知を通信継続通知と表記する）を通信状態検出部２９に送る。

ＡＲＰ模擬処理部２７は、Ｌ２フレーム処理部２６からＡＲＰリクエストパケットを受けると、このＡＲＰリクエストパケットの応答としてのＡＲＰリプライパケットを生成する。ＡＲＰ模擬処理部２７は、このＡＲＰリプライパケットをＬ２フレーム処理部２６に送る。これにより、Ｌ２フレーム処理部２６は、このＡＲＰリプライパケットに所定のＬ２ヘッダを付与することによりＬ２フレームを生成し、ＯＳ２０へこのＬ２フレームを送る。これにより。ＯＳ２０のＬ２通信制御部２２は、先に送信したＡＲＰリクエストに対して正常にＡＲＰリプライを受けたと認識し、このＡＲＰリプライパケットに設定されているデータに基づいて、ＡＲＰテーブル２３を更新する。なお、ＡＲＰ模擬処理部２７は、ＡＲＰリプライパケットに設定される応答元ＭＡＣアドレスとしては、任意に決定したダミーのＭＡＣアドレスを使うようにすればよい。例えば、このダミーのＭＡＣアドレスとして、予め保持された固定のＭＡＣアドレスを使うようにしてもよいし、その都度乱数によりＭＡＣアドレスを生成するようにしてもよい。

ＡＲＰ模擬処理部２７は、待機状態制御部２８からの通知により、Ｉ／Ｆ部３０の動作状態を認識する。ＡＲＰ模擬処理部２７は、Ｉ／Ｆ部３０が待機モードである際に、Ｌ２フレーム処理部２６からＡＲＰリクエストパケットを受けた場合には、ダミーとして生成したＡＲＰリプライパケットをＬ２フレーム処理部２６へ送らず保持する。ＡＲＰ模擬処理部２７は、待機状態制御部２８からＩ／Ｆ部３０が通常モードへ復帰したことを通知された後、保持しているＡＲＰリプライパケットをＬ２フレーム処理部２６へ送る。これに
より、ＯＳ２０は、ＡＲＰ手続実行中においては、同じ宛先への新たなパケット送信を行わないため、結果としてＩ／Ｆ部３０が待機モードから通常モードへ復帰するまでパケット送信が抑制される。

通信状態検出部２９は、Ｌ２フレーム処理部２６から送られる通信継続通知に基づき、Ｉ／Ｆ部３０の通信状態を検出する。基本的には、通信状態検出部２９は、当該通信継続通知を受けた場合には、通信が継続されている若しくは通信が始まったことを通知するために、その通信継続通知をそのまま待機状態制御部２８に送る。一方、通信状態検出部２９は、予め調整可能に保持される時間閾値の間、Ｌ２フレーム処理部２６から当該通信継続通知が送られてこない場合に、Ｉ／Ｆ部３０が無通信状態にあると判断する。通信状態検出部２９は、Ｉ／Ｆ部３０が無通信状態にあると判断すると、このことを待機状態制御部２８に通知する（以降、この通知のことを無通信通知と表記する）。

待機状態制御部２８は、Ｉ／Ｆ部３０の動作モードを管理する。待機状態制御部２８は、通信状態検出部２９から上記無通信通知を受けると、Ｉ／Ｆ部３０に対して待機状態移行指示を出す。この指示の応答としてＩ／Ｆ部３０から待機状態移行完了通知を受けると、待機状態制御部２８は、Ｉ／Ｆ部３０が待機状態に移行したことを認識すると共に、ＡＲＰ模擬処理部２７にこの認識を通知する。待機状態制御部２８は、Ｉ／Ｆ部３０がＢＳ主導で待機モードへ移行した場合には、待機状態移行完了通知をＩ／Ｆ部３０から受信する。

待機状態制御部２８は、Ｉ／Ｆ部３０が待機モードであるときに、通信状態検出部２９から通信継続通知を受けると、Ｉ／Ｆ部３０に対して復帰指示を出す。この指示の応答としてＩ／Ｆ部３０から復帰完了通知を受けると、待機状態制御部２８は、Ｉ／Ｆ部３０が通常モードに復帰したことを認識すると共に、その認識をＡＲＰ模擬処理部２７に通知する。待機状態制御部２８は、Ｉ／Ｆ部３０がＢＳ主導で通常モードへ復帰した場合には、復帰完了通知をＩ／Ｆ部３０から受信する。

更に、待機状態制御部２８は、Ｉ／Ｆ部３０から待機状態移行完了通知を受けると、ＡＲＰテーブル２３のエントリを削除する（無効にする）。ＡＲＰ手順では、ＡＲＰリクエストによって得られた回答は一定期間有効であるため、実際にはデータ送信のたびにＡＲＰリクエストが送信されるわけではい。そこで、Ｉ／Ｆ部３０が通常モードへ復帰する際には、ＯＳ２０にＡＲＰ手順を確実に実行させるために、ＡＲＰテーブル２３の対象エントリを削除しておく必要がある。従って、待機状態制御部２８は、Ｉ／Ｆ部３０に復帰指示を出す場合には、それと共にＡＲＰテーブル２３の所定エントリを削除する処理を実行する。このドライバ２５によるＡＲＰテーブル２３の削除処理は、例えば、ＯＳ２０により提供されるＡＰＩ（Application Program Interface）を使って実行される。また、待機状態制御部２８は、ＡＲＰテーブル２３のエントリを全て削除するようにしてもよいし、ダミーＭＡＣアドレスが設定されたエントリのみを削除するようにしてもよい。

なお、ページングメッセージの判定処理をドライバ２５で担う場合には、この待機状態制御部２８が、このページングメッセージを受信すべきタイミングでＩ／Ｆ部３０に対して一時復帰モードへの移行指示を出し、ページングメッセージの内容を確認するようにすればよい。

〔動作例〕
以下に、本実施形態における無線端末１０の動作例について図３から６を用いて説明する。

図３は、第一実施形態における無線端末１０主導でＩ／Ｆ部３０が待機モードへ移行す
る場合の動作シーケンスを示す図である。本実施形態の無線端末１０のドライバ２５では、Ｌ２フレーム処理部２６がＯＳ２０から送られてくるＬ２フレームからＩＰパケットを抽出する処理、及びＩ／Ｆ部３０から送られてくるＩＰパケットにＬ２ヘッダを付与してＬ２フレームを生成する処理を実行している。Ｌ２フレーム処理部２６によりこのような処理が実行されている間は、同ドライバ２５の通信状態検出部２９は通信状態が継続していると判断する。

ここで、図３に示すように、この通信状態検出部２９が予め調整可能に保持される時間閾値よりも長い間、Ｌ２フレーム処理部２６から通信継続通知が送られてこないことを検知すると、Ｉ／Ｆ部３０が無通信状態にあると判断する（Ｓ３１）。ドライバ２５の待機状態制御部２８は、通信状態検出部２９から上記判断に伴う無通信通知を受けると、Ｉ／Ｆ部３０に対して待機状態移行指示を出す（Ｓ３２）。

Ｉ／Ｆ部３０は、ドライバ２５から送られるこの待機状態移行指示を受けると、待機モードへ移行するための処理を実行する。具体的には、Ｉ／Ｆ部３０は、ＢＳ４０に対し、待機状態移行を要求する（Ｓ３３）。ＢＳ４０は、無線端末１０から待機状態移行を要求されると、この要求を受け入れるか否かを決定する。ＢＳ４０は、この要求を受け入れることを決定すると、無線端末１０に対し待機状態移行応答を送信する（Ｓ３４）。

Ｉ／Ｆ部３０は、ＢＳ４０から待機状態移行応答を受けると、待機モードへ移行する（Ｓ３５）。Ｉ／Ｆ部３０は、この後、待機状態移行完了通知をドライバ２５に送る（Ｓ３６）。これにより、ホスト部１５では、ドライバ２５の待機状態制御部２８がＩ／Ｆ部３０が待機モードへ移行したことを認知する。

ドライバ２５の待機状態制御部２８は、Ｉ／Ｆ部３０が待機モードへ移行したことを確認すると、ＡＲＰテーブル２３の所定エントリを削除する（Ｓ３７）。これにより、無線端末１０によりデータ送信が発生しＩ／Ｆ部３０を通常モードへ復帰させる場合に、確実にＯＳ２０によるＡＲＰ手順が実行されるようにする。

図４は、ＢＳ４０主導でＩ／Ｆ部３０が待機モードへ移行する場合の動作シーケンスを示す図である。図４に示すように、ＢＳ４０から無線端末１０へ待機状態移行要求が送られてくる場合もある。

無線端末１０のＩ／Ｆ部３０は、この待機状態移行要求を受信すると（Ｓ４１）、ＢＳ４０へ待機状態移行応答を送信する（Ｓ４２）。続いて、Ｉ／Ｆ部３０は、待機モードへ移行するための処理を実行する（Ｓ４３）。すなわち、Ｉ／Ｆ部３０は、無通信状態となる場合に不要となる回路への電力供給を停止する。Ｉ／Ｆ部３０は、この後、待機状態移行完了通知をドライバ２５に送る（Ｓ４４）。これにより、ホスト部１５では、ドライバ２５の待機状態制御部２８がＩ／Ｆ部３０が待機モードへ移行したことを認知する。

ドライバ２５の待機状態制御部２８は、Ｉ／Ｆ部３０が待機モードへ移行したことを確認すると、ＡＲＰテーブル２３の所定エントリを削除する（Ｓ４４）。これにより、無線端末１０によりデータ送信が発生しＩ／Ｆ部３０を通常モードへ復帰させる場合に、確実にＯＳ２０によるＡＲＰ手順が実行されるようにする。

図５は、ＢＳ４０主導でＩ／Ｆ部３０が通常モードへ復帰する場合の動作シーケンスを示す図である。図５の例では、無線端末１０のＩ／Ｆ部３０は待機モードとなっている。これは、図３に示したような無線端末１０主導で移行された場合であっても、図４に示したようなＢＳ４０主導で移行された場合であってもよい。

一方で、ＢＳ４０は、無線端末１０のためのページングメッセージを定周期でブロードキャスト送信している。ＢＳ４０は、その無線端末１０へ送信すべきデータを受けている場合には、このページングメッセージ内にその旨（着信情報）を設定する（Ｓ５１）。

本実施形態における無線端末１０のＩ／Ｆ部３０は、待機モードであってもＢＳ４０からブロードキャスト送信されるページングメッセージを受信すべきタイミングで一時復帰モードへ移行する（Ｓ５０）。すなわち、Ｉ／Ｆ部３０は、ページングメッセージを受信すべきタイミングにおいて、ページングメッセージを受信することができるように必要な回路に対し電力供給を行う。

Ｉ／Ｆ部３０は、このページングメッセージを受信すると、それに自身宛のデータがある旨の情報が設定されているか否かを判定する（Ｓ５２）。この判定は、無線端末１０のドライバ２５が実行するようにしてもよい。

Ｉ／Ｆ部３０は、この判定により、自身宛のデータがある旨の情報が設定されていると判断すると、通常モードへ移行するための処理を実行する（Ｓ５３）。すなわち、Ｉ／Ｆ部３０は、電力供給が停止されている回路に対して電力供給を再開する。一方、Ｉ／Ｆ部３０は、ページングメッセージに基づいて自分宛のデータがないと判断すると、再度、待機モードへ移行する。

Ｉ／Ｆ部３０は、通常モードへ移行することにより回路が送受信処理可能となると、ＢＳ４０に対して接続要求を送信する（Ｓ５４）。ＢＳ４０は、この要求に対して所定の登録処理等を実行し、接続完了応答を送信する（Ｓ５５）。これにより、ＢＳ４０と無線端末１０との間には無線リンクが再確立される。Ｉ／Ｆ部３０は、この接続完了応答を受信すると、ホスト部１５のドライバ２５に対して復帰完了通知を出す（Ｓ５６）。

以降、ＢＳ４０から無線端末１０に対して送信データパケットが送信される（Ｓ５７）。このとき、無線端末１０のＩ／Ｆ部３０は既に通常モードへの移行が完了しているため（Ｓ５３）、その送信データパケットを正常に受信することができ、それをドライバ２５へ送る（Ｓ５８）。ドライバ２５は、ＯＳ２０がＬ２通信を実行しているつもりとなっていることから、この送信データパケットを受けると、それに所定のＬ２ヘッダを付与してＬ２フレームを生成する。ドライバ２５は、生成された送信データフレームをＯＳ２０へ送る（Ｓ５９）。

このように、ＢＳ４０主導で通常モードへ復帰する場合には、ＢＳ４０とＩ／Ｆ部３０との間で接続要求信号及び接続完了応答信号がやりとりされた後に、送信データパケットがＢＳ４０から無線端末１０へ送られる。従って、無線端末１０がデータパケットを受信する際には既にＩ／Ｆ部３０の回路が完全に送受信可能状態となっている。

図６は、第一実施形態における無線端末１０主導でＩ／Ｆ部３０が通常モードへ復帰する場合の動作シーケンスを示す図である。まず、無線端末１０のＩ／Ｆ部３０は待機モードとなっており、ＡＲＰテーブル２３からは所定のエントリが削除されている。これは、図３に示したような無線端末１０主導で移行された場合であっても、図４に示したようなＢＳ４０主導で移行された場合であってもよい。図６の例では、無線端末１０のＩ／Ｆ部３０が待機モードとなっている状況において、無線端末１０のアプリケーション１６の処理により送信データが発生した場合が示されている。

ＯＳ２０は、送信データを受けると、これをＩ／Ｆ部３０から送信するために、プロトコルスタックとしてのＬ２通信制御部２２にこの送信データを処理させる。このとき、ＯＳ２０は、Ｉ／Ｆ部３０用のドライバ２５がＬ２ドライバとして動作しているため、この
送信データをＬ２通信により送信するべく、Ｌ２通信制御部２２を起動する。Ｌ２通信制御部２２は、この送信データに付与するＬ２ヘッダを生成するために、アドレス解決処理を実行する（Ｓ６０）。具体的には、Ｌ２通信制御部２２は、ＡＲＰテーブル２３から、この送信データに設定されているＩＰアドレスに対応するエントリを抽出しようとする。このとき、Ｌ２通信制御部２２は、このＡＲＰテーブル２３に該当するエントリが登録されていないと判断し、ＡＲＰ手順を実行する。Ｌ２通信制御部２２は、ＡＲＰリクエストフレームを生成し、ドライバ２５へこのフレームの送信を指示する（Ｓ６１）。以降、ＯＳ２０は、このＡＲＰリクエストフレームに対する応答であるＡＲＰリプライフレームが返信されるまで同一宛先への送信データの送信要求を抑制する（アドレス解決処理の待ち時間）。

ＯＳ２０がＡＲＰリプライフレームの返信を待っている間、ドライバ２５では、以下のような処理が実行される。

Ｌ２フレーム処理部２６がこのＡＲＰリクエストフレームを受け、そのフレームから抽出されるＡＲＰリクエストパケットをＡＲＰ模擬処理部２７へ送る。これと共に、Ｌ２フレーム処理部２６から通信状態検出部２９を経由して待機状態制御部２８へ通信継続通知が送られる（Ｓ６２）。このとき、待機状態制御部２８は、Ｉ／Ｆ部３０が待機モードであることを認識している。待機状態制御部２８は、Ｉ／Ｆ部３０が待機モードであると認識している状況で当該通信継続通知を受けると、Ｉ／Ｆ部３０に対して復帰指示を出す（Ｓ６３）。一方で、ＡＲＰ模擬処理部２７は、先に送られたＡＲＰリクエストパケットの応答として、ダミーのＭＡＣアドレスを応答元ＭＡＣアドレスとして設定されたＡＲＰリプライパケットを生成する。

Ｉ／Ｆ部３０は、ドライバ２５から復帰指示を受けると、待機モードから通常モードへ復帰するための処理を実行する。すなわち、Ｉ／Ｆ部３０は、待機モードにおいて電力供給が停止されている回路に対して電力供給を再開する。Ｉ／Ｆ部３０は、通常モードへ移行することにより回路が送受信処理可能となると、ＢＳ４０に対して接続要求を送信する（Ｓ６６）。ＢＳ４０は、この要求に対して所定の登録処理等を実行し、接続完了応答を送信する（Ｓ６７）。これにより、ＢＳ４０と無線端末１０との間には無線リンクが再確立される。Ｉ／Ｆ部３０は、この接続完了応答を受信すると、ホスト部１５のドライバ２５に対して復帰完了通知を出す（Ｓ６８）。

ドライバ２５では、Ｉ／Ｆ部３０から復帰完了通知が受信されると、ＡＲＰ模擬処理部２７により先に生成されたＡＲＰリプライパケットに基づいて、Ｌ２フレーム処理部２６によりＬ２ヘッダが付与されることによりＡＲＰリプライフレームが生成される（Ｓ６５）。ドライバ２５は、このように生成されたＡＲＰリプライフレームをＯＳ２０へ送信する（Ｓ６９）。

ＯＳ２０は、このＡＲＰリプライフレームを受けると、これに設定されているダミーＭＡＣアドレスを対象となるＩＰアドレスと対応付けたエントリをＡＲＰテーブル２３に登録する。ＯＳ２０は、このダミーＭＡＣアドレスを設定したＬ２ヘッダを当該送信データに付与することにより送信データフレームを生成する（Ｓ７０）。ＯＳ２０は、この送信データフレームをドライバ２５に送る（Ｓ７１）。

ドライバ２５では、Ｌ２フレーム処理部２６がこの送信データフレームを受け、これから送信データパケットを抽出する。Ｌ２フレーム処理部２６は、抽出された送信データパケットをＩ／Ｆ部３０に対して送信するように要求する（Ｓ７２）。Ｉ／Ｆ部３０は、この送信データパケットをＢＳ４０へ無線送信する（Ｓ７３）。

このように、無線端末１０主導で通常モードへ復帰する場合には、無線端末１０のドライバ２５が、Ｉ／Ｆ部３０の通常モードへの復帰にかかる遅延時間を吸収するようにＡＲＰ手順を模擬し、無線端末１０のＯＳ２０が、このＡＲＰ手順の待ち時間の間、データの送信を抑制する。これにより、本実施形態における無線端末１０によれば、ＯＳ２０やＩ／Ｆ部３０に特別な新たな機能を追加することなく、ドライバ２５によりＬ２模擬処理を実行させるだけで、Ｉ／Ｆ部３０の通常モードへの復帰にかかる遅延時間の間、データ送信を抑制することができる。

〈第一実施形態における作用及び効果〉
ここで、上述した第一実施形態における無線端末１０の作用及び効果について述べる。

本実施形態における無線端末１０では、無線通信のためのＩ／Ｆ部３０を制御するドライバ２５がＬ２ドライバとして動作し、データ通信が必要になるとＯＳ２０がこのドライバ２５を用いてＬ２通信を実行する。更に、このドライバ２５では、ＯＳ２０及びＩ／Ｆ部３０から送られるデータの処理状況が管理されることにより、Ｉ／Ｆ部３０の通常モードから待機モードへの移行指示及び待機モードから通常モードへの復帰指示が出される。

ここで、無線端末１０において送信データが発生した場合には、ＯＳ２０のアドレス解決処理においてＡＲＰ手順が実行される。ドライバ２５は、このＡＲＰ手順において、ＯＳ２０から送られるＡＲＰリクエストフレームに対し、その応答となるＡＲＰリプライフレームを生成する。ドライバ２５は、Ｉ／Ｆ部３０が通常モードへ復帰し完全に送受信可能となったことを確認すると（復帰完了通知を受けると）、この模擬生成されたＡＲＰリプライフレームをＯＳ２０へ返す。

これにより、本実施形態によれば、無線端末１０が主導となり自身を通常モードへ復帰させる場合において、Ｉ／Ｆ部３０の待機モードから通常モードへの復帰時の遅延時間をＯＳ２０によるＡＲＰ手順により吸収し、このＡＲＰ手順の待ち時間の間、ＯＳ２０からＩ／Ｆ部３０へのデータ送信指示を抑制させることができる。

更に、本実施形態では、Ｉ／Ｆ部３０が待機モードになったことをドライバ２５が確認すると、ＡＲＰテーブル２３の所定エントリが削除される。これにより、無線端末１０により送信データが発生しＩ／Ｆ部３０を通常モードへ復帰させる場合に、ＯＳ２０に確実にＡＲＰ手順を実行させることができる。

また、本実施形態によれば、このような無線端末１０が主導となり自身を通常モードへ復帰させる場合だけでなく、無線端末１０が主導となり自身を待機モードへ移行させる場合、ＢＳ４０が主導となり無線端末１０を通常モードへ復帰させる場合、ＢＳ４０が主導となり無線端末１０を待機モードへ移行させる場合においても対応可能である。

本実施形態によれば、このような機能を、ＯＳ２０やＩ／Ｆ部３０に特別な仕組み（機能）を付加することなく、ドライバ２５の動作のみで実現することができる。従って、本実施形態によれば、装置規模の増大や装置内部回路の複雑化等を招くことなく、簡易な構成により安いコストで当該機能を実現することができる。

［第二実施形態］
以下、本発明の第二実施形態における無線端末について説明する。上述の第一実施形態では、無線端末１０で送信データが発生しＩ／Ｆ部３０を通常モードへ復帰させる際にＯＳ２０に確実にＡＲＰ手順を実行させるために、Ｉ／Ｆ部３０が待機モードになるとＡＲＰテーブル２３の所定エントリを削除していた。第二実施形態における無線端末１０では、ＡＲＰテーブル２３のエントリの有効期間を使って、所定のエントリを確実に無効にす
るようにする。なお、接続形態については、第一実施形態と同様であるため、ここでは説明を省略する。以下、第二実施形態における無線端末１０について、第一実施形態と異なる機能部及びその動作について説明する。

図７に示されるように、ＡＲＰテーブル２３には、各エントリについて有効期間がそれぞれ設けられている。図７は、ＡＲＰテーブル２３の例を示す図である。

各エントリは、それに設定された有効期間が満了すると、当該ＡＲＰテーブル２３から削除される（若しくは無効化される）。待機状態制御部２８は、ＡＲＰ模擬処理により追加されるエントリの有効期間を通信状態検出部２９により無通信状態を判断する際に使われる時間閾値相当若しくはこの時間閾値より短い時間に設定する。この場合には、待機状態制御部２８は、ＡＲＰテーブル２３のエントリ削除を実行する必要はない。なお、待機状態制御部２８は、ＡＲＰテーブル２３の有効期間を更新するのではなく、通信状態検出部２９により無通信状態を判断する際に使われる時間閾値をＡＲＰテーブル２３の有効期間と同じ値若しくはそれよりも長い時間に設定するようにしてもよい。

Ｉ／Ｆ部３０が待機モードへ移行したときには最後の通信時から少なくともこの時間閾値以上経過していることになる。これにより、待機モードから通常モードへ復帰する際に、前回ＡＲＰ模擬処理により追加されたエントリは有効期間を過ぎていることから、ＡＲＰテーブル２３から削除されている。これにより、Ｉ／Ｆ部３０が待機モードから通常モードへ復帰する際には、ＯＳ２０により確実にＡＲＰ手順を実行させることができる。

〔動作例〕
以下に、第二実施形態における無線端末１０の動作例について図８を用いて説明する。図８は、第二実施形態における無線端末１０主導でＩ／Ｆ部３０が通常モードへ復帰する場合の動作シーケンスを示す図である。無線端末１０のＩ／Ｆ部３０が待機モードから通常モードへ復帰し、ドライバ２５からＡＲＰリプライフレームを受けたＯＳ２０が、送信データフレームをドライバ２５に送信する（Ｓ７１）までは、第一実施形態と同様である（図６参照）。このとき、ＡＲＰテーブル２３には、ダミーのＡＲＰリプライフレームに設定されているＭＡＣアドレスの設定されたエントリが登録されている。従って、以降、同一ＩＰアドレスに対して送信データが発生した場合には、ＡＲＰ手順は実行されず、ＡＲＰテーブル２３に登録されるＭＡＣアドレスによりアドレス解決される。

第二実施形態では、ドライバ２５のＬ２フレーム処理部２６が送信データフレームを受けると（Ｓ７１）、通信継続通知が通信状態検出部２９を介して待機状態制御部２８に送られる。待機状態制御部２８は、ＡＲＰ模擬処理の実行後通信継続通知を受けた場合に、先に実行されたＡＲＰ模擬処理により追加されたＡＲＰテーブル２３のエントリの有効期間を無通信状態の判断に利用される時間閾値相当又はそれより短い値に更新する（Ｓ７５）。

図７に示されるようにその後通信が行われなかった場合には、当該時間閾値経過後、通信状態検出部２９により無通信状態が検出される（Ｓ７７）。この無通信状態の検出と略同時若しくはそれよりも早く、ＯＳ２０では、先に更新されたエントリの有効期間が満了し、ＡＲＰテーブル２３からこのエントリが削除される（Ｓ７８）。

これにより、Ｉ／Ｆ部３０が待機モードへ移行され、その後、更に送信データが無線端末１０で発生した場合には、既にＡＲＰテーブル２３の先のエントリは削除されていることから、ＯＳ２０によりＡＲＰ手順が実行される。

〈第二実施形態における作用及び効果〉
ここで、上述した第二実施形態における無線端末１０の作用及び効果について述べる。

第二実施形態における無線端末１０では、ドライバ２５が、ＡＲＰ模擬処理により登録されるＡＲＰテーブル２３のエントリに関し、その有効期間を無通信状態の判断に用いる時間閾値相当又はそれより短い期間に設定されるか、或いは、無通信状態の判断に用いる時間閾値がＡＲＰテーブル２３のエントリの有効期間相当又はそれより長い期間に設定される。

これにより、無線端末１０において無通信状態と判断され、Ｉ／Ｆ部３０が待機モードへ移行されるときには、既に上記エントリの有効期間が満了し、そのエントリがＡＲＰテーブル２３から削除されている。

従って、次に、無線端末１０に送信データが生じてＩ／Ｆ部３０を通常モードへ復帰させる場合には、ＯＳ２０により確実にＡＲＰ手順が実行されるため、Ｉ／Ｆ部３０の待機モードから通常モードへの復帰時の遅延時間をＯＳ２０によるＡＲＰ手順により吸収し、このＡＲＰ手順の待ち時間の間、ＯＳ２０からＩ／Ｆ部３０へのデータ送信指示を確実に抑制させることができる。

［第一実施形態及び第二実施形態の変形例］
上述の第一実施形態及び第二実施形態における無線端末では、ＡＲＰ手順を伴うＬ２フレームを対象としていたが、ＡＲＰ手順を伴わず送信されるＬ２フレームに対応するための構成を備えるようにしてもよい。ＡＲＰ手順を伴わない通信とは、ブロードキャストフレームを送信する場合や、ＡＲＰテーブル２３のエントリを静的な（スタティックな）設定（有効期間を持たない設定）とする場合等がある。

図９は、第一実施形態及び第二実施形態における無線端末の変形例を示す図である。本変形例では、第一実施形態及び第二実施形態における無線端末１０のドライバ２５に保留バッファ９０を新たに備える。

Ｉ／Ｆ部３０が待機モードの状態にあり、無線端末１０で生じた送信データがＡＲＰ手順を伴わないものであった場合には、ＯＳ２０によりＡＲＰ手順が実行されない。Ｌ２フレーム処理部２６は、Ｉ／Ｆ部３０が待機モードの場合にＡＲＰリクエストフレーム以外の送信データフレームを受けた場合には、そのフレームから抽出されるパケットを保留バッファ９０に保持する。

待機状態制御部２８は、復帰指示後、Ｉ／Ｆ部３０から復帰完了通知を受けると、それをそのままＬ２フレーム処理部２６に送る。Ｌ２フレーム処理部２６は、待機状態制御部２８から復帰完了通知を受けると、保留バッファ９０に保持されているパケットを順次Ｉ／Ｆ部３０に送る。

これにより、本変形例によれば、保留バッファ９０を備えることからメモリ削減効果は薄れるものの、上述の第一実施形態及び第二実施形態で記載したＡＲＰ模擬処理に加え、ＡＲＰ手順を伴わない通信についてもこの保留バッファ９０によりＩ／Ｆ部３０の通常モードへの復帰時の遅延時間を吸収することができる。

[その他]
本実施形態は次の発明を開示する。各項に開示される発明は、必要に応じて可能な限り組み合わせることができる。

（付記１）
複数の動作状態として少なくとも待機モードと通常モードとを有する無線通信インタフェースと、アドレス解決プロトコルを含むデータリンク層で伝送されるフレームを処理するフレーム処理手段と、の間の仲介処理を無線通信端末に実行させる無線通信ドライバプログラムにおいて、
前記無線通信端末に、
前記無線通信インタフェースの動作状態を管理し、前記フレーム処理手段からアドレス解決要求フレームを受けた場合で前記無線通信インタフェースの動作状態が待機モードである場合に、前記無線通信インタフェースに待機モードから通常モードへ復帰するように指示し、前記無線通信インタフェースの動作状態が通常モードへ復帰したことを確認する状態管理ステップと、
前記状態管理ステップにより前記無線通信インタフェースの動作状態が通常モードへ復帰したことが確認された後に、前記フレーム処理手段から送られたアドレス解決要求フレームに対するアドレス解決応答フレームを生成し、このアドレス解決応答フレームを前記フレーム処理手段に送る模擬応答ステップと、
を実行させる無線通信ドライバプログラム。（１）
（付記２）
前記無線通信端末に、
前記状態管理ステップにより前記無線通信インタフェースが通常モードから待機モードへ移行したことが確認された場合に、前記フレーム処理手段で利用されるアドレス解決テーブルのエントリを無効化するテーブル更新ステップ、
を更に実行させる付記１に記載の無線通信ドライバプログラム。（２）
（付記３）
前記無線通信端末に、
前記無線通信インタフェースにおける通信状況を調査し、時間閾値としての無通信判断時間より長く通信がされていない状況が継続されている場合に、前記無線通信インタフェースが無通信状態にあると判断する通信状況判断ステップと、
前記フレーム処理手段で利用されるアドレス解決テーブルのエントリの有効期間を前記無通信判断時間相当若しくは前記無通信判断時間よりも短い期間に設定するテーブル更新ステップと、
を更に実行させる付記１に記載の無線通信ドライバプログラム。（３）
（付記４）
前記無線通信端末に、
前記無線通信インタフェースにおける通信状況を調査し、時間閾値としての無通信判断時間より長く通信がされていない状況が継続されている場合に、前記無線通信インタフェースが無通信状態にあると判断する通信状況判断ステップと、
前記無通信判断時間を前記フレーム処理手段で利用されるアドレス解決テーブルのエントリの有効期間相当若しくは該アドレス解決テーブルのエントリの有効期間よりも長い期間に設定する閾値更新ステップと、
を更に実行させる付記１に記載の無線通信ドライバプログラム。（４）
（付記５）
前記無線通信端末に、
前記フレーム処理手段から送られるフレームを前記無線通信インタフェースで利用される通信データに変換し、前記無線通信インタフェースから送られる通信データを前記フレーム処理手段で処理されるフレームに変換する変換ステップと、
前記無線通信インタフェースを利用した通信に関し、前記フレーム処理手段が、前記無線通信インタフェースを利用した通信には不必要な前記アドレス解決プロトコルを含むデータリンク層プロトコルを実行するように制御する制御ステップと、
を更に実行させる付記１に記載の無線通信ドライバプログラム。（５）
（付記６）
前記無線通信端末に、
前記無線通信インタフェースから送信されるべきデータを格納するバッファを、
更に有し、
前記変換ステップが、前記無線通信インタフェースの動作状態が待機モードにある場合で前記フレーム処理手段からアドレス解決要求フレーム以外のフレームを受けた場合に、このフレーム若しくはこのフレームから変換された通信データを前記バッファに格納し、前記状態管理ステップにより前記無線通信インタフェースが通常モードへ復帰したことが確認された後に、前記バッファに格納された通信データを前記無線通信インタフェースへ送る、
付記５に記載の無線通信ドライバプログラム。（６）
（付記７）
複数の動作状態として少なくとも待機モードと通常モードとを有する無線通信インタフェースと、
アドレス解決プロトコルを含むデータリンク層で伝送されるフレームを処理するフレーム処理手段と、
前記フレーム処理手段と前記無線通信インタフェースとの間を仲介するドライバ手段と、を備える無線通信端末において、
前記ドライバ手段が、
前記無線通信インタフェースの動作状態を管理する状態管理手段であって、前記フレーム処理手段からアドレス解決要求フレームを受けた場合で前記無線通信インタフェースの動作状態が待機モードである場合に、前記無線通信インタフェースに待機モードから通常モードへ復帰するように指示し、前記無線通信インタフェースの動作状態が通常モードへ復帰したことを確認する状態管理手段と、
前記状態管理手段により前記無線通信インタフェースの動作状態が通常モードへ復帰したことが確認された後に、前記フレーム処理手段から送られたアドレス解決要求フレームに対するアドレス解決応答フレームを生成し、このアドレス解決応答フレームを前記フレーム処理手段に送る模擬応答手段と、
を有する無線通信端末。（７）
（付記８）
前記ドライバ手段は、
前記状態管理手段により前記無線通信インタフェースが通常モードから待機モードへ移行したことが確認された場合に、前記フレーム処理手段で利用されるアドレス解決テーブルのエントリを無効化するテーブル更新手段、
を更に有する付記７に記載の無線通信端末。
（付記９）
前記ドライバ手段は、
前記無線通信インタフェースにおける通信状況を調査し、時間閾値としての無通信判断時間より長く通信がされていない状況が継続されている場合に、前記無線通信インタフェースが無通信状態にあると判断する通信状況判断手段と、
前記フレーム処理手段で利用されるアドレス解決テーブルのエントリの有効期間を前記無通信判断時間相当若しくは前記無通信判断時間よりも短い期間に設定するテーブル更新手段と、
を更に有する付記７に記載の無線通信端末。
（付記１０）
前記ドライバ手段は、
前記無線通信インタフェースにおける通信状況を調査し、時間閾値としての無通信判断時間より長く通信がされていない状況が継続されている場合に、前記無線通信インタフェースが無通信状態にあると判断する通信状況判断手段と、
前記無通信判断時間を前記フレーム処理手段で利用されるアドレス解決テーブルのエントリの有効期間相当若しくは該アドレス解決テーブルのエントリの有効期間よりも長い期間に設定する閾値更新手段と、
を更に有する付記７に記載の無線通信端末。
（付記１１）
前記ドライバ手段は、
前記フレーム処理手段から送られるフレームを前記無線通信インタフェースで利用される通信データに変換し、前記無線通信インタフェースから送られる通信データを前記フレーム処理手段で処理されるフレームに変換する変換手段を、
更に有し、
前記無線通信インタフェースを利用した通信に関し、前記フレーム処理手段が、前記無線通信インタフェースを利用した通信には不必要な前記アドレス解決プロトコルを含むデータリンク層プロトコルを実行するように制御する、
付記７に記載の無線通信端末。
（付記１２）
前記ドライバ手段は、
前記無線通信インタフェースから送信されるべきデータを格納するバッファ、
を更に有し、
前記変換手段が、前記無線通信インタフェースの動作状態が待機モードにある場合で前記フレーム処理手段からアドレス解決要求フレーム以外のフレームを受けた場合に、このフレーム若しくはこのフレームから変換された通信データを前記バッファに格納し、前記状態管理手段により前記無線通信インタフェースが通常モードへ復帰したことが確認された後に、前記バッファに格納された通信データを前記無線通信インタフェースへ送る、
付記１１に記載の無線通信端末。
（付記１３）
無線通信端末が実行し、複数の動作状態として少なくとも待機モードと通常モードとを有する無線通信インタフェースと、アドレス解決プロトコルを含むデータリンク層で伝送されるフレームを処理するフレーム処理手段と、の間の仲介処理である無線通信インタフェース制御方法において、
前記無線通信端末が、
前記無線通信インタフェースの動作状態を管理し、前記フレーム処理手段からアドレス解決要求フレームを受けた場合で前記無線通信インタフェースの動作状態が待機モードである場合に、前記無線通信インタフェースに待機モードから通常モードへ復帰するように指示し、前記無線通信インタフェースの動作状態が通常モードへ復帰したことを確認する状態管理ステップと、
前記状態管理ステップにより前記無線通信インタフェースの動作状態が通常モードへ復帰したことが確認された後に、前記フレーム処理手段から送られたアドレス解決要求フレームに対するアドレス解決応答フレームを生成し、このアドレス解決応答フレームを前記フレーム処理手段に送る模擬応答ステップと、
を実行する無線通信インタフェース制御方法。（８）

第一実施形態における無線端末と無線通信システムとの接続形態を示す概念図である。 第一実施形態における無線端末の機能構成を示すブロック図である。 第一実施形態における無線端末主導でＩ／Ｆ部が待機モードへ移行する場合の動作シーケンスを示す図である。 ＢＳ主導でＩ／Ｆ部が待機モードへ移行する場合の動作シーケンスを示す図である。 ＢＳ主導でＩ／Ｆ部が通常モードへ復帰する場合の動作シーケンスを示す図である。 第一実施形態における無線端末主導でＩ／Ｆ部が通常モードへ復帰する場合の動作シーケンスを示す図である。 ＡＲＰテーブルの例を示す図である。 第二実施形態における無線端末１０主導でＩ／Ｆ部３０が通常モードへ復帰する場合の動作シーケンスを示す図である。 第一実施形態及び第二実施形態における無線端末の変形例を示す図である。

符号の説明

１０ 無線情報端末装置（無線端末）
４０ 無線基地局（ＢＳ）
４３ ＡＳＮ（Access Service Network）
４８ ＩＰネットワーク
４５ ＡＳＮゲートウェイ（ＡＳＮ−ＧＷ）
５０ 通信先端末
１１ アンテナ
１５ ホスト部
１６ アプリケーション
２０ ＯＳ（Operating System）
２１ バッファ
２２ Ｌ２通信制御部
２３ ＡＲＰテーブル
２５ ドライバ
２６ Ｌ２フレーム処理部
２７ ＡＲＰ模擬処理部
２８ 待機状態制御部
２９ 通信状態検出部
３０ 無線通信インタフェース部（Ｉ／Ｆ部）
３１ 無線ＭＡＣ（Media Access Control）部
３２ ＲＦ（Radio Frequency）部
９０ 保留バッファ

Claims (8)

1. 複数の動作状態として少なくとも待機モードと通常モードとを有する無線通信インタフェースと、アドレス解決プロトコルを含むデータリンク層で伝送されるフレームを処理するフレーム処理手段と、の間の仲介処理を無線通信端末に実行させる無線通信ドライバプログラムにおいて、
   前記無線通信端末に、
   前記無線通信インタフェースの動作状態を管理し、前記フレーム処理手段からアドレス解決要求フレームを受けた場合で前記無線通信インタフェースの動作状態が待機モードである場合に、前記無線通信インタフェースに待機モードから通常モードへ復帰するように指示し、前記無線通信インタフェースの動作状態が通常モードへ復帰したことを確認する状態管理ステップと、
   前記状態管理ステップにより前記無線通信インタフェースの動作状態が通常モードへ復帰したことが確認された後に、前記フレーム処理手段から送られたアドレス解決要求フレームに対するアドレス解決応答フレームを生成し、このアドレス解決応答フレームを前記フレーム処理手段に送る模擬応答ステップと、
   を実行させる無線通信ドライバプログラム。
2. 前記無線通信端末に、
   前記状態管理ステップにより前記無線通信インタフェースが通常モードから待機モードへ移行したことが確認された場合に、前記フレーム処理手段で利用されるアドレス解決テーブルのエントリを無効化するテーブル更新ステップ、
   を更に実行させる請求項１に記載の無線通信ドライバプログラム。
3. 前記無線通信端末に、
   前記無線通信インタフェースにおける通信状況を調査し、時間閾値としての無通信判断時間より長く通信がされていない状況が継続されている場合に、前記無線通信インタフェースが無通信状態にあると判断する通信状況判断ステップと、
   前記フレーム処理手段で利用されるアドレス解決テーブルのエントリの有効期間を前記無通信判断時間相当若しくは前記無通信判断時間よりも短い期間に設定するテーブル更新ステップと、
   を更に実行させる請求項１に記載の無線通信ドライバプログラム。
4. 前記無線通信端末に、
   前記無線通信インタフェースにおける通信状況を調査し、時間閾値としての無通信判断時間より長く通信がされていない状況が継続されている場合に、前記無線通信インタフェースが無通信状態にあると判断する通信状況判断ステップと、
   前記無通信判断時間を前記フレーム処理手段で利用されるアドレス解決テーブルのエントリの有効期間相当若しくは該アドレス解決テーブルのエントリの有効期間よりも長い期間に設定する閾値更新ステップと、
   を更に実行させる請求項１に記載の無線通信ドライバプログラム。
5. 前記無線通信端末に、
   前記フレーム処理手段から送られるフレームを前記無線通信インタフェースで利用される通信データに変換し、前記無線通信インタフェースから送られる通信データを前記フレーム処理手段で処理されるフレームに変換する変換ステップと、
   前記無線通信インタフェースを利用した通信に関し、前記フレーム処理手段が、前記無線通信インタフェースを利用した通信には不必要な前記アドレス解決プロトコルを含むデータリンク層プロトコルを実行するように制御する制御ステップと、
   を更に実行させる請求項１に記載の無線通信ドライバプログラム。
6. 前記無線通信端末に、
   前記無線通信インタフェースから送信されるべきデータを格納するバッファを、
   更に有し、
   前記変換ステップが、前記無線通信インタフェースの動作状態が待機モードにある場合で前記フレーム処理手段からアドレス解決要求フレーム以外のフレームを受けた場合に、このフレーム若しくはこのフレームから変換された通信データを前記バッファに格納し、前記状態管理ステップにより前記無線通信インタフェースが通常モードへ復帰したことが確認された後に、前記バッファに格納された通信データを前記無線通信インタフェースへ送る、
   請求項５に記載の無線通信ドライバプログラム。
7. 複数の動作状態として少なくとも待機モードと通常モードとを有する無線通信インタフェースと、
   アドレス解決プロトコルを含むデータリンク層で伝送されるフレームを処理するフレーム処理手段と、
   前記フレーム処理手段と前記無線通信インタフェースとの間を仲介するドライバ手段と、を備える無線通信端末において、
   前記ドライバ手段が、
   前記無線通信インタフェースの動作状態を管理する状態管理手段であって、前記フレーム処理手段からアドレス解決要求フレームを受けた場合で前記無線通信インタフェースの動作状態が待機モードである場合に、前記無線通信インタフェースに待機モードから通常モードへ復帰するように指示し、前記無線通信インタフェースの動作状態が通常モードへ復帰したことを確認する状態管理手段と、
   前記状態管理手段により前記無線通信インタフェースの動作状態が通常モードへ復帰したことが確認された後に、前記フレーム処理手段から送られたアドレス解決要求フレームに対するアドレス解決応答フレームを生成し、このアドレス解決応答フレームを前記フレーム処理手段に送る模擬応答手段と、
   を有する無線通信端末。
8. 無線通信端末が実行し、複数の動作状態として少なくとも待機モードと通常モードとを有する無線通信インタフェースと、アドレス解決プロトコルを含むデータリンク層で伝送されるフレームを処理するフレーム処理手段と、の間の仲介処理である無線通信インタフェース制御方法において、
   前記無線通信端末が、
   前記無線通信インタフェースの動作状態を管理し、前記フレーム処理手段からアドレス解決要求フレームを受けた場合で前記無線通信インタフェースの動作状態が待機モードである場合に、前記無線通信インタフェースに待機モードから通常モードへ復帰するように指示し、前記無線通信インタフェースの動作状態が通常モードへ復帰したことを確認する状態管理ステップと、
   前記状態管理ステップにより前記無線通信インタフェースの動作状態が通常モードへ復帰したことが確認された後に、前記フレーム処理手段から送られたアドレス解決要求フレームに対するアドレス解決応答フレームを生成し、このアドレス解決応答フレームを前記フレーム処理手段に送る模擬応答ステップと、
   を実行する無線通信インタフェース制御方法。
   
   
   

Images