JP2014027421A - 通信端末および通信方法 - Google Patents

Abstract

【課題】通信端末における省電力とユーザの利便性を両立させる。
【解決手段】本発明の一態様としての通信端末は、通信デバイスと、通信管理部と、デバイス電源管理部と、を備える。前記通信デバイスは、通信機器とアソシエーションを形成し、前記通信機器と通信する。前記通信管理部は、前記通信デバイスの動作モードを決定する。前記デバイス電源管理部は、前記動作モードに応じて、前記通信デバイスへの給電を制御する。前記デバイス電源管理部は、前記第1の動作モードが決定されたときに、前記通信デバイスを送受信不能な第1の電源状態に設定し、前記第1の電源状態に設定した後、第1の周期ごとに、前記通信デバイスを送信可能な第2の電源状態に設定する。前記通信デバイスは、前記第2の電源状態に設定されたときに、存在通知フレームを送信する。
【選択図】図５

Description

本発明の実施形態は、通信端末および通信方法に関する。

通信技術の発展に伴い、スマートフォンのような通信機能を有する端末が普及してきている。一方で、地球温暖化への懸念から、端末の消費電力削減に対する社会的な要請が高まっている。さらに、スマートフォンのようなバッテリにより駆動される端末においては、その駆動時間を長くするという利便性の観点からも、端末の消費電力削減に対するニーズがある。

この消費電力削減への要求に対して、ACPI（Advanced Configuration and Power Interface）という電源制御の枠組みが提案されている。これによれば、S3という状態が定義されている。S3は、“Suspend to RAM”と呼ばれる状態である。S3状態では、CPUのレジスタの値をメインメモリに書き出し、メインメモリを通電状態にしつつ、CPUやバスやバスデバイスの給電を絶つ。S3状態の端末は動作を行うことはできないが、S0状態（動作状態）よりも消費電力は少ない。さらにS3状態からS0状態に復帰した際には、S3状態に遷移する前の端末状態に復帰できる。このため、コールドブートよりも利便性が高い。

さらに他の従来技術として、特許文献1がある。ここでは、無線LAN端末において、送受信パケットが一定時間無い場合に、接続中のアクセスポイントにデータを送信するために必要な情報を端末内部に保存し、通信回路の電源供給を停止する。送信パケット発生時には、通信回路に電源を供給し、保存していた情報を用いて接続手順を行わずに、以前接続していたアクセスポイントへパケットを送信する。このように、アクセスポイントとの接続手順を省くことで、通信部の電源供給後のパケット送信に要する遅延を削減している。

特開2006-5577号公報

近年、Webサービスあるいはクラウドサービスと呼ばれるサービスが普及してきている。例えば、Google社のGmailのようなものを挙げることができる。Gmailでは、メールデータはサーバ上に存在し、これにWebブラウザからアクセスすることで、専用のメールアプリケーションを用いることなく、受信メールの一覧や、選択メールの内容を表示する。このようなサービスを想定した場合、ローカル端末は、必要なデータを受信する度に無線LAN通信部の給電を停止し、通信が必要となった場合にのみ無線LAN通信部の給電を行うことが、消費電力の観点では望ましい。しかしながら、無線LAN通信部の給電を開始してからパケットを送信可能となるまでの遅延が大きく、ユーザの利便性を損なう。

これに対して、特許文献1で述べられているように、接続中のアクセスポイント情報を保持したまま、無線LAN通信部の給電を停止する方法がある。パケット送信が必要となった際には、無線LAN通信部の給電を行うとともに、保持したアクセスポイント情報を用いてパケットをアクセスポイントに向けて送信する。

しかしながら、無線LAN通信部の給電を停止している状態が長いと、アクセスポイントはその端末がいなくなったと判断し、アソシエーション情報を破棄する可能性がある。このとき、通信端末は無線LANインタフェースの給電を開始してパケットを送信すると、アクセスポイントで送信パケットが破棄される。そして、一定時間後に通信端末はそのパケットの再送を一定回数行うことになる。このように、通信端末は、アクセスポイントがアソシエーションを破棄していることに気付けず、パケットが送信できない時間が増加するという問題がある。

このように、省電力状態のため無線LAN通信部の給電を停止すると、パケット送信可能となるまでの遅延が大きく、ユーザの利便性を損なうという課題があった。

本発明の一側面は、通信端末における省電力とユーザの利便性を両立させることを目的とする。

本発明の一態様としての通信端末は、通信デバイスと、通信管理部と、デバイス電源管理部と、を備える。

前記通信デバイスは、通信機器とアソシエーションを形成し、前記通信機器と通信する。

前記通信管理部は、前記通信デバイスの動作モードを決定する。

前記デバイス電源管理部は、前記通信管理部により決定された動作モードに応じて、前記通信デバイスへの給電を制御する。

前記デバイス電源管理部は、前記通信管理部により第1の動作モードが決定されたとき、前記通信デバイスを送受信不能な第1の電源状態に設定し、前記第1の電源状態に設定した後、第1の周期ごとに、前記通信デバイスを送信可能な第2の電源状態に設定する。

前記通信デバイスは、前記第2の電源状態に設定されたときに、存在通知フレームを送信する。

本実施形態における全体構成を示す。 パワー制限モードでの動作タイミングを示す。 パワー制限モードでの外部インタフェース部の動作を示す。 本実施形態に係る通信端末のハードウエア構成例を示す。 本実施形態に係る通信端末のソフトウエア構成を示す。 外部インタフェース部の構成を示す。 本実施形態に係る通信端末と、ネットワーク上の通信端末間の通信シーケンス例を示す。 HTTPレベルの通信シーケンスを示す。 受信メールの一覧画面の例を示す。 HTMLデータにより表示する画面の表示例を示す。 通信デバイスのハードウエア構成例を示す。 HTTP処理部の動作を示す。 周辺アクセスポイント表示と接続状態表示とモード表示を含む表示画面の例を示す。

以下、図面を参照しながら、本実施形態を説明する。

図1に本実施形態における全体構成を示す。

通信端末1と通信端末2が、ネットワーク3を介して接続されている。通信端末1は、無線LAN(例えばIEEE 802.11)にて、通信機器である無線LANアクセスポイント4を介してネットワーク3に接続されている。通信端末2は10GBイーサーネットにて、ネットワーク3に接続されている。無線LANアクセスポイント4は、通信を中継する中継機器として機能する。

通信端末1ではWebブラウザが実行されており、通信端末2ではHTTPサーバが動作している。通信端末2では、HTTPを用いたメールサービスが提供されており、通信端末1からこのメールサービスを利用している。

図7に通信端末1と通信端末2間の通信シーケンス例を記す。図7ではTCPパケットのシーケンスを記している。

まず初めに、通信端末1は、通信端末2に、宛先ポート番号80にて、TCPコネクションを設定する（S101）。この時のTCPコネクション設定手順は、次のとおりである。(1)TCPのSYNパケットを通信端末1から通信端末2に送信し、(2)これを受信した通信端末2がSYN ACKパケットを通信端末1に送信し、(3)このSYN ACKパケットを受信した通信端末1がACKパケットを通信端末2に送信する。

次に、通信端末1は、HTTPリクエストを通信端末2に送信する（S102）。このときHTTPリクエストは、複数のTCPパケットに分割されることがある。HTTPリクエストを受信した送信端末2は、HTTPレスポンスを送信端末1に送信する（S103）。HTTPレスポンスは、複数のTCPパケットに分割されることがある。図7中のACKはDATAを受信したことを示す送達確認パケットであり、受信済みデータを識別するセグメントサイズの情報（確認応答番号）を有する。

図8にHTTPレベルの通信シーケンスを記す。図8において、実線矢印はTCPパケットの送受信を示し、点線矢印はHTTPレベルの情報の送受信を示す。

先に述べたように、それぞれのHTTPリクエストとHTTPレスポンスは、一つ以上のTCPパケットにて運ばれる。典型的には一つ目のHTTPセッション1のHTTPレスポンスでは、通信端末1はユーザ認証画面に対応するHTMLデータを受信する。通信端末1上で動作するWebブラウザにて受信したHTMLデータは、ユーザIDとパスワード入力画面として、ユーザに提示される。

ユーザがこの画面にてユーザIDとパスワードを入力し、送信ボタンを押下することで、HTTPセッション2が開始される。HTTPセッション2のHTTPリクエストには、ユーザID・パスワード・リクエストURL（HTTPリクエストが要求するURL）を含む。これを受信した通信端末2は、対応するユーザの受信メールの一覧を表示するためのHTMLデータと、ユーザを識別するユーザ識別情報とを含むHTTPレスポンスを、通信端末1に送信する。

さらに、ユーザが受信メール一覧画面上であるメールを選択することで、HTTPセッション3が開始される。HTTPセッション3のHTTPリクエストには、ユーザを識別するユーザ識別情報と、ユーザが選択したメールに対応するメール識別情報と、リクエストURLとを含む。これを受信した通信端末2は、ユーザ識別情報と、メール識別情報に対応するメールを表示するためのHTMLデータとを含むHTTPレスポンスを、通信端末1に送信する。

図9に、受信メールの一覧画面の例を示す。

通信端末1は、HTTPセッション2のHTTPレスポンスに含まれるHTMLデータを受信すると、これをWebブラウザを使って画面に表示する。図9はその表示例である。

この表示例では、画面は二つのフレームからなっている。左のフレーム51には受信ボタン61・作成ボタン62・受信箱ボタン63・送信済ボタン64が表示されている。右のフレーム52には、受信したそれぞれのメールに対する（件名、受信日時、送信者）のエントリが表示されている。右フレームのスクロールバー65を用いて画面スクロールすることで、画面に入りきれないエントリも表示することができる。

さて、図9のように2つのフレームの画面を表示するには、図8で説明したように一つのHTTPセッションではなく、複数のHTTPセッションでHTMLデータを取得することが一般的である。しかしながら、図8では説明を簡易に行うため、受信メール一覧画面のHTMLデータが、一つのHTTPセッションで受信できる場合の例を元に説明を行っている。

たとえば図9の画面の場合は、まず一つ目のHTMLデータを取得し、このHTMLデータには、二つのフレームと、夫々に対応する埋め込みオブジェクトのURLとが記されている。Webブラウザは埋め込みオブジェクトのURLに対して、2つのHTTPセッションにて、図9の右画面と左画面のHTMLデータ（埋め込みオブジェクト）を受信することになる。もちろん、埋め込みオブジェクトはHTMLデータ以外に、画像データなど様々なものが可能である。

図9の受信メール一覧画面にて、ユーザが一番上のエントリを選択すると、通信端末1が、HTTPセッション3によりHTMLデータを受信する。このHTMLデータにより表示する画面の表示例を図10に示す。

図10の表示例では、画面は二つのフレームからなっている。左のフレーム71には、次のメールボタン81・前のメールボタン82・返信ボタン83・受信箱ボタン84・送信済ボタン85が表示されている。右のフレーム72には、ユーザが選択したメールに対応するメールの詳細が記されている。メール本文が長く画面に収まりきらない場合には、右フレームのスクロールバー86を用いて画面をスクロールすることで、画面外の部分を表示できる。

ユーザが図10のメール本文を読んでいる間は、通信端末1と通信端末2との間の通信は発生しない。画面データは全て取得済であるため、例えば、スクロールバーを操作しても通信が不要である。このため、ユーザがメールを読んでいる間（例えば3分）は、通信端末1の通信部の給電を停止することが可能である（図8のHTTPセッション3の後のPLM状態）。PLM状態は、通信部の給電を停止した状態である。このように通信の発生しない間、PLM状態とすることで、通信回路における動作電力およびリーク電力を減らすことができ、通信端末1の消費電力を削減することができる。さらに、ユーザがメールを読んでいる間だけでなく、認証画面にユーザIDとパスワードを入力している間（HTTPセッション1とHTTPセッション2の間）と、受信メール一覧画面にて読むメールを探している間（HTTPセッション2とHTTPセッション3の間）も、通信端末1がPLM状態となることが可能である。この様子が図8に示されている。

図4に通信端末1のハードウエア構成例を示す。

通信端末1は、CPU11と画面表示デバイス12とワーキングメモリ13と外部入力デバイス14と通信デバイス15とフラッシュメモリ16とバッテリ17とバッテリ管理部18とを備える。

CPU11は、例えばインテル社Core i5のようなプロセッサである。

画面表示デバイス12は、例えばLCDディスプレイのように、画面表示信号を人間の見える形式で画面表示するものである。

ワーキングメモリ13は、DRAMのようなメモリであり、例えばLPDDRインタフェースにてCPU11と接続される。

外部入力デバイス14は、ボタンやタッチパネルやキーボードやマウスなどのような入力デバイスであり、例えばUSBインタフェースにてCPU11に接続される。

通信デバイス15は、例えば無線LAN（IEEE 802.11）規格に従って動作し、ネットワークとのパケット送受信を行うものである。通信デバイス15は、例えばPCI expressバスにてCPU11と接続される。

フラッシュメモリ16は、例えばNANDフラッシュメモリ16であり、OSやWebブラウザなどのプログラムや、ユーザデータを保持するものである。フラッシュメモリ16は、例えばSATAインタフェースにてCPU11と接続される。フラッシュメモリ16は、データの保持ができれば、ハードディスクなどの他の媒体でも代替可能である。

バッテリ17は、リチウムイオン電池などの電気エネルギーを通信端末1に供給するものである。

バッテリ管理部18は、CPU11に対してバッテリ残量などのようなバッテリ状態を提供する。

図11に通信デバイス15のハードウエア構成例を示す。通信デバイス15は、内部インタフェース部81と状態保持部82と電源状態制御部83とパケット保持部84と外部インタフェース部85とを備える。

内部インタフェース部81は、例えばPCI-expressインタフェースであり、PCI-express規格に従ってCPU11との情報送受信を行う。また、通信デバイス15への給電は、内部インタフェース部81を介して行われる。

外部インタフェース部85は、通信路と信号を送受信する通信部を含む。外部インタフェース部85は、パケット保持部84に送信フレームが存在する場合に、これを通信路に電気信号あるいは電波信号として送信する。また、通信路から電気信号あるいは電波信号を受信して、これを受信フレームとしてパケット保持部84に送る。

外部インタフェース部85は、無線LANの場合には、IEEE802.11のMAC処理部と物理層処理部とを備える。MAC処理部は、物理層処理部を介して、プローブ要求を送信し、アクセスポイントからのプローブ応答を受信することでアクセスポイントを発見する。MAC処理部は、物理処理部に指定する無線チャンネルを変えながらプローブ要求送信とプローブ応答受信を繰り返すことで、様々な無線チャンネルにわたってアクセスポイントを発見することができる。

MAC処理部は、発見したアクセスポイントを、CPU11に内部インタフェース部81を介して伝える。CPU11からアクセスポイントのSSIDとBSSIDと無線チャンネルを含む接続要求を、内部インタフェースを介してMAC処理部は受信する。MAC処理部は、指定されたSSIDとBSSIDと無線チャンネルを用いて、物理層処理部と状態保持部82を介して、アクセスポイントへアソシエーション要求を送信し、アソシエーション応答を受信する。このアソシエーション要求とアソシエーション応答の送受信により、通信デバイス15とアクセスポイントとの間に、アソシエーションが設定される。アソシエーションが設定されると、MAC処理部は、そのSSIDとBSSIDと無線チャンネルを、状態保持部82に送る。状態保持部82は、MAC処理部から受けたこれらのデータを内部に保持する。

MAC処理部は、パケット保持部84に送信イーサーフレームがあると、これにMACヘッダを付与して、IEEE802.11フレームを生成する。MAC処理部は、このフレームを、物理層処理部を介してアクセスポイントに送信する。また、MAC処理部は、物理層処理部を介してアクセスポイントからIEEE802.11フレームを受信すると、そのMACヘッダを外して、イーサーフレームを抽出する。MAC処理部は、このイーサーフレームをパケット保持部84に送る。パケット保持部84は、MAC処理部から受けたイーサーフレームを一時保持する。

パケット保持部84は、ワーキングメモリ13から、CPU11と内部インタフェース部81を介して、送信パケット（無線LANの場合はイーサーフレーム）を受信および保持する。外部インタフェース部85はこれをパケット保持部84から取り出し、通信路に送信する。また、通信路から外部インタフェース部85を介してパケットを受信すると、これを保持し、内部インタフェース部81とCPU11を介して、ワーキングメモリ13に送る。このようにパケット保持部84は、ワーキングメモリ13と通信路との間でのパケットのやり取りの際に、パケットの一時保管を行うものであり、主として内部プロトコルと外部プロトコルのタイミングをとるために使われる。

状態保持部82は、CPU11からアクセスできるメモリ領域であり、例えば複数のレジスタ変数を保持する。通信デバイス15の設定情報を、CPU11からこの状態保持部82に設定することで、通信デバイス15の設定を変更することが可能である。また、通信状態に関わる情報を外部インタフェース部85に問い合わせるためにも使用する。以下に、レジスタ変数の例を示す。

電源状態制御部83は、状態保持部82のAレジスタの値に従い、通信デバイス15の電源状態を設定する。Aレジスタの値が0の場合はD0状態にし、1の場合はD1状態に、2の場合はD2状態に、3の場合はD3状態に設定する。

D0状態とは通信デバイス15が動作している状態であり、送受信可能である。

D3状態とはD0状態に復帰するのに最低必要な機能を除いて、全ての給電を停止した状態である。D3状態では、送受信とも不可である。具体例としては、外部インタフェース部85とパケット保持部84の給電を止める。状態保持部82は、Aレジスタ以外の読み書きを停止しつつ、すべてのレジスタの保持内容を保持する状態にする。内部インタフェース部81はAレジスタの読み書き以外の機能を停止する。

D1とD2は、D0とD3の中間の状態であり、P(Di)を各状態の消費電力とすると、P(D0)>P(D1)>P(D2)>P(D3)である。また、各状態からD0に復帰するのに要する時間をT(Di)で表すと、T(D1)<T(D2)<T(D3)である。

また、Eレジスタは、通信デバイスとアクセスポイントとのアソシエーションの有無を示す。例えば値が0であればアソシエーションなし、値が1であればアソシエーションありを意味する。

また、Fレジスタは、アクセスポイントとのアソシエーションがある場合に、そのアクセスポイントのBSSIDを保持する。

また、Gレジスタは、アクセスポイントとのアソシエーションがある場合に、そのアクセスポイントのSSIDを保持する。

また、Hレジスタは、アクセスポイントとのアソシエーションがある場合に、そのアクセスポイントのビーコン周期を保持する。

また、Iレジスタは、アクセスポイントとのアソシエーションがある場合に、そのアクセスポイントのDTIM周期を保持する。

図6に外部インタフェース部85の構成を示す。外部インタフェース部85は、アンテナ200とRF(Radio Frequency)処理部210とベースバンド処理部250とを備える。

アンテナ200は、電波信号の送受信を行うものである。図6ではアンテナ200は1本であり、この1本のアンテナが、アンテナ切り替えスイッチ260を用いて、送受信で共有される。これ以外の構成として、MIMOと呼ばれる手法のように複数のアンテナを用いることも可能である。あるいは、送受信で異なるアンテナを用いることも可能である。

RF処理部210は、デジタル信号と電波として送受信する電気信号との変換を行うものである。RF処理部210は、受信回路220と送信回路230と周波数シンセサイザ240を備える。

周波数シンセサイザ240は、PLL回路242とVCO241を備えた発信機であり、周波数変換を行う。

受信回路220は、アンテナから受信した信号を復調処理し、復調信号をベースバンド処理部250に送る。受信回路220は、低雑音アンプ221とミクサ222と高利得アンプ223と復調回路224とを備える。アンテナ200から受信した電気信号は、低雑音アンプ221により増幅され、次にミクサ222により中間周波数に変換され、高利得アンプ223で増幅された後、復調処理が行われる。

送信回路230は、ベースバンド処理部250から受信したデジタル信号を、電気信号に変換し、アンテナ200に送る。送信回路230は、変調回路231とパワーアンプ232とを備える。ベースバンド処理部250から受信したデジタル信号は、変調回路231にて処理されることで変調信号とされる。この変調信号は、パワーアンプ232にて増幅された後、アンテナ200に送信される。

ベースバンド処理部250は、IEEE802.11 MAC処理を行うものであり、BB受信処理部251とBB送信処理部253とBB制御処理部252とを備える。

BB受信処理部251は、フレームの受信処理を行うものである。BB受信処理部251は、フレームを受信した際の、フレームフォーマットをチェックし、受信したフレームがデータフレームである場合には、これに含まれるイーサーフレームを抽出しパケット保持部（図11）へ送る。受信したフレームが制御フレームである場合には、BB制御処理部252へ送る。

BB送信処理部253は、フレームの送信処理を行うものである。BB送信処理部253は、パケット保持部84から送信イーサーフレームを受信すると、MACフレームを生成し、RF処理部210に送る。MACフレームの再送処理もここで行う。

BB制御処理部252は、IEEE802.11の制御フレームの処理を行うものであり、受信したビーコンの処理や、アソシエーション要求の生成や、受信したアソシエーション応答の処理などを行う。存在通知メッセージとしてNULLフレームを送信する場合には、このフレームの生成をBB制御処理部252が行う。

後述するよう、PLMと呼ぶ状態では、外部インタフェース部85は、送受信不可状態と、受信可能状態と、送受信可能状態の3つのPLM動作状態を有する。

送受信不可能状態とは、外部インタフェース85のRF処理部210とベースバンド処理部の給電を停止した状態である。ここで給電の停止とは、（図示しない）タイマなどを除きすべての回路の給電を停止することが望ましいが、PLM動作状態の遷移を高速に行うため、給電後に動作可能になるのに要する時間の長い回路（例えばPLL回路242など）への給電を行っていても構わない。また、電圧を完全にゼロにするのではなく、一部の回路に低い電圧を印加し続けていてもよい。

受信可能状態とは、受信に必要な回路のみ給電を行っている状態であり、例えばRF処理部210の送信回路230と、ベースバンド処理部250のBB送信処理部253以外の処理部への給電を行っている状態である。この状態では電波信号の受信処理は可能だが、送信処理はできない。

送受信可能状態とは、送受信可能な状態であり、通常の動作状態である。つまり、外部インタフェース部85のすべてのブロックに電源が供給される。ただし、消費電力を下げるため、一部の機能への電源供給を停止し、当該機能を使用不可にしても構わない。消費電力を下げるため、通信速度を下げてもよい。

なお、上記以外にも、受信処理はできないが、送信処理が可能な送信可能状態が定義されてもよい。

一般に、RF処理部のパワーアンプの消費電力は大きい。また、すべての回路は送受信を行っていない場合でも給電を行っていると、電力を消費する。したがって、上述のように一部の回路の給電を停止することで、消費電力を削減することが可能となる。

（スキャン動作）
内部インタフェース81を介して、Oレジスタにスキャン要求（スキャン種別、チャンネル、SSID）が書き込まれると、外部インタフェース部85はスキャン動作を行う。スキャン種別とは、アクティブスキャンあるいはパッシブスキャンのどちらかを示す。チャンネルはスキャンを実行すべき無線チャンネルを示す。SSIDはアクティブスキャンの場合にのみ有効である。

アクティブスキャンでは、指定されたSSIDを記したプローブ要求フレームを外部インタフェース85が通信路に送信し、指定されたSSIDを有するアクセスポイントがこのプローブ要求フレームに対してプローブ応答フレームを送信する。このプローブ応答フレームを外部インタフェース部85が受信すると、これに含まれる（BSSID,SSID,ビーコン周期、サポートしている送信伝送レート、暗号情報(Capability Information)）と、プローブ応答フレームの受信電界強度を抽出し、Pレジスタに書き込む。ここで、複数のアクセスポイントからプローブ応答を受信した場合には、各アクセスポイントに対して上述の情報をPレジスタに書き込む。また、Oレジスタに書き込まれたSSIDがNULLの場合には、SSID=0の値のプローブ要求フレームを外部インタフェース部85は送信する。これを受信したアクセスポイントは、アクセスポイントが有するSSIDの値に関わらずプローブ応答フレームを送信する。

パッシブスキャンでは、Oレジスタに指定されたチャンネルに対して定められた時間に受信したビーコンの中から上述の値を抽出し、Pレジスタに書き込む。パッシブスキャンの場合も複数のアクセスポイントからビーコンを受信した場合には、複数のアクセスポイントの情報をPレジスタに書き込む。

（アソシエーション動作）
内部インタフェース81を介してRレジスタにアソシエーション要求(CH,SSID,BSSID)が設定されると、外部インタフェース85は、この値を使ってアソシエーション要求フレームを伝送路に送信する。そのSSIDとBSSIDを有するアクセスポイントからアソシエーション応答フレームを受信すると、通信デバイスとアクセスポイントの間にアソシエーションが設定される。また、必要に応じて認証要求フレームと認証応答フレームを交換することで、アクセスポイントとの間の通信の暗号化を行うことも可能である。

アソシエーションが設定された後、アクセスポイントは、該外部インタフェース85のMACアドレスを宛先アドレスとして有するフレームを有線通信路から受信すると、これを無線伝送路に送信する。また外部インタフェース85のMACアドレスをソースアドレスとして有するフレームを受信すると、その受信処理を行い、有線インタフェースに転送する。

もし、アソシエーションが設定されていない場合には、アクセスポイントは、外部インタフェース85のMACアドレスを宛先アドレスとして有するパケットを有線通信路から受信しても、このパケットを破棄する。また外部インタフェース85のMACアドレスをソースアドレスとして有するパケットを無線通信路から受信しても、このパケットを破棄する。

（省電力状態）
通信デバイスがD0状態のときは、アクセスポイントとのフレームの送受信ができるが、D3状態の時にはフレームの送受信はできない。通信デバイスはD0状態である場合には、Kレジスタの値によって外部インタフェース部85は異なる動作を行う。

Kレジスタの値が0のとき、外部インタフェース部85は、常にフレームの送受信が可能な状態(Normal)である。

Kレジスタの値が1のとき、外部インタフェース部85は、IEEE 802.11仕様の定めるパワーセーブモード(PSM)を行う。このPSMでは、送信パケットが内部インタフェース81を介してパケット保持部に受信すると、外部インタフェース部85は、直ちにこのパケットを無線通信路に送信する。受信動作に関しては、アソシエーション応答フレームにより受信したビーコン周期を用いて、アクセスポイントのビーコン送信タイミングで、受信可能状態に遷移する。ビーコンを受信するとこれに含まれるTIM(Traffic Indication Map)を参照し、自身宛てのフレームの有無を確認する。もし自身宛てのフレームをアクセスポイントが有している場合には、アクセスポイントへそのフレームの送信を要求するPS-Pollフレームを送信し、アクセスポイントから自身宛てのフレームを受信する。また、マルチキャストやブロードキャストフレームは、DTIM周期に対応するビーコンの送信直後にアクセスポイントから送信されるため、外部インタフェース部85は、このタイミングでは受信可能状態でいる。もし、TIMを参照して、自身宛てのフレームをアクセスポイントが有していないことが分かったら、外部インタフェース部85は受信不可の状態に移行することで、消費電力を削減する。

Kレジスタの値が2のとき（提案方式）は、外部インタフェース部85は、本実施形態の第1の動作モードに対応するパワー制限モード(PLM)に移行する。PLMでの動作タイミングを図2に示す。図2ではビーコン周期毎にアクセスポイントはビーコンを送信している。

外部インタフェース部85は予め定められた覗き見周期（第2の周期）毎に、送受信可能状態に遷移し、予め定められた覗き見期間（第2の期間）が終了後は、送受信不可能状態に遷移する。

また、存在通知周期（第1の周期）毎に外部インタフェース部85は送受信可能状態に遷移し、存在通知期間（第1の期間）の終了後は、送受信不可状態に移行する。

送受信不可能状態は、外部インタフェース部85の電子回路の給電を停止し、消費電力を抑える。このとき、全てのPLL(Phased Lock Loop)回路も停止することで、回路へのクロック配送も停止しておくことが望ましい。ただし、次の覗き見期間に受信可能状態となるようタイマ回路は動作させておくことは言うまでもない。この例では、覗き見期間で送受信可能状態に遷移したが、そうではなく受信可能状態（送信は不可）に遷移することも可能である。すなわち、覗き見期間には、アクティブスキャンを行う場合には送受信可能状態に遷移し、そうではなくパッシブスキャンに遷移する場合には受信可能状態あるいは送受信可能状態に遷移する。以下では受信可能状態に遷移するとして説明する。

図3にPLMでの外部インタフェース部85の動作を示す。外部インタフェース部85はPLMに移行すると、送受信不可状態に遷移する（S11）。あらかじめ定められた覗き見周期の長さにタイマを設定する。このタイマにより覗き見期間の開始を知ると（S12）、受信可能状態に遷移し（S13）、Eレジスタを参照してアソシエーションが設定されているか検査する（S14）。アソシエーションが設定されている場合には、Jレジスタを参照し、アクセスポイントとの通信に使用している無線チャネル（周波数）に対して、パッシブスキャンを実行する（S15）。そして、スキャン結果をPレジスタに出力する（S16）。

アソシエーションが無い場合には、覗き見期間の度に異なる周波数でパッシブスキャンを実行する（S17）。例えば、前回の覗き見期間でCH1をスキャンした場合には、今回はCH2をスキャンし、次回はCH3をスキャンするといった具合である。このチャンネルの変更は様々な方法によって実現することができる。例えば、覗き見期間が開始する毎に、乱数にてスキャンするチャンネルを決めることができる。あるいは、CH1, CH4, CH7, CH10, CH13, CH2, CH5, …のようにチャンネルの変更幅を1以上に大きくすることもできる。ここで、ステップS17（ニコちゃんマーク）で、アソシエーションを設定できるアクセスポイントからのビーコンを受信した場合には、あらかじめ設定されている接続情報（SSID，WEPキー、接続優先度）を元に、そのアクセスポイントとのアソシエーション設定を行ってもよい。

さらに、アソシエーションがある場合には（S18のYES）、存在通知周期の長さに設定したタイマによって、存在通知期間の開始が到来したか検査する（S19）。到来すると、送受信可能状態に遷移し（S20）、自身（通信端末1）の存在を通知する存在通知を送信する（S21）。存在通知に対する応答（IEEE802.11 ACK）を当該期間内に受信したか判定し（S22）、受信しなかった場合には、Eレジスタの値を、アソシエーション無しの状態に変更する（S23）。すなわち、アソシエーションを破棄する。一方、存在通知に対する応答を受信した場合には、送受信不可状態に遷移する（S11）。存在通知に対する応答を受信した場合には、存在通知期間中であっても、直ちに送受信不可状態に遷移してもよい。存在通知を送信することで、通信端末1が送受信不可能状態に遷移しても、アクセスポイントとのアソシエーション維持することが可能となる。

ここで、存在通知に対する応答がない場合には、あらかじめ定められた回数の存在通知の再送を行い、一つも存在通知の応答を受信しない場合にアソシエーション破棄することが望ましい。また、存在通知メッセージは、IEEE802.11のNULL Frameであることが望ましいが、様々なメッセージを存在通知メッセージとして使用可能であり、NULL Frameの後にICMP ECHO Requestを送信するように存在通知期間毎に異なるメッセージを存在通知メッセージとして使用しても構わない。

あるいは、ARP Announcementメッセージ(RFC 3972)の送信することで、自身の存在通知とすることも可能である。この場合は、自身の存在をアクセスポイントに通知するだけでなく、（図1で図示しない）同一サブネットの端末あるいはルータのARPキャッシュテーブルを更新することが可能である。また、L2スイッチが存在する場合には、そのイーサーフレームフォワードテーブルを更新することが可能である。ARP Announcementメッセージを送信する場合には、これに対するARP応答を通信端末1は受信しなくても構わない。

なお、上記では覗き見期間と、存在通知期間の2つの期間が存在したが、覗き見期間を設けない形態も可能である。また存在通知期間では送受信可能状態に遷移したが、存在通知フレームに対する応答フレームを受け取らない形態の場合は、受信不可で送信可能状態に遷移することも可能である。

図5に通信端末1のソフトウエア構成を示す。通信端末1は、図4のハードウエア上で、図5のソフトウエアが動作することで実現される。図3に示す各ブロックは、プログラムモジュールとして実現されることができる。プログラムは、コンピュータ読取可能記録媒体に格納されてもよい。当該記録媒体からプログラムがコンピュータによって読み出され、メモリに展開され、実行される。ただし、図5のソフトウエアの一部が、ハードウエアで実現されることも可能である。図5のソフトウエアは、大きくOSとアプリケーションソフトウエアに分けることができる。

OSは、TCP処理部31（コネクション処理部）とIP処理部32とデバイスドライバ33と通信管理部34とデバイス電源管理部35と端末電源状態管理部36とを備える。

TCP処理部31は、アプリケーションソフトウエアの要請によりTCPコネクションの設定・解放を行う。また、TCP処理部31は、アプリケーションソフトウエアから渡されたデータをTCPパケットの形式に変換して、IP処理部32とデバイスドライバ33を介して、通信端末2に送信する。通信端末2からACKパケットを受信しない場合には、TCPパケットの再送処理を行う。さらに、TCP処理部31は、通信端末2から受信したTCPパケットに対して、ACKパケットを通信端末2に送信する。また、TCP処理部31は、受信TCPパケットからデータを抽出し、アプリケーションソフトウエアに送る。なお、本実施形態では通信端末2とコネクションを設定するが、アクセスポイント（通信機器）4がTCP/IPおよびアプリケーションを備えるとき、アクセスポイント4とコネクションを設定および解放することも可能である。

IP処理部32は、TCP処理部31から受信したTCPパケットをIPパケットに変換して、デバイスドライバ33を介して通信端末2に送信する。さらに、IP処理部32は、通信端末2から受信したIPパケットからTCPパケットを抽出し、TCP処理部31に送る。なお、図示しないがイーサー処理部が、IP処理部32とデバイスドライバ33との間に存在する。イーサー処理部は、IP処理部32から受信したIPパケットをイーサーフレームに変換して、デバイスドライバ33に送る。またイーサー処理部は、デバイスドライバ33から受信したイーサーフレームからIPパケットを抽出し、IP処理部32に渡す。

デバイスドライバ33は、図4の通信デバイス15を制御するためのソフトウエアである。デバイスドライバ33は、指定されたメモリ番地にデータを読み書きすることで、通信デバイス15のレジスタにアクセスし、これにより通信デバイス15を制御する。さらに、イーサー処理部から受信したイーサーフレームを、通信デバイス15に送る。また通信デバイス15により通信路からイーサーフレームが受信された場合、通信デバイス15からCPU11に割り込みがかかることで、デバイスドライバ33が実行され、通信デバイス15からイーサーフレームをデバイスドライバ33が受信する。この通信デバイス15とデバイスドライバ33とのイーサーフレームのやり取りは、あらかじめ定められたメモリ番地にアクセスすることで行われる。本実施形態において通信端末1のCPU11は、メモリマップドIOを用いて、通信デバイス15やワーキングメモリ13などの周辺デバイスにアクセスすることを想定している。ただし、ポートマップドIOなど他のアクセス方法を用いることも可能である。

通信管理部34は、アプリケーションソフトウエアのHTTP処理部4141から、通信アクティビティ情報（HTTPセッションを開始通知、HTTPセッション終了通知）を受信する。HTTPセッション終了通知を受信すると、デバイス電源管理部35に、通信デバイス15の電源状態設定要求（PLM）を送る。また、通信管理部34がHTTPセッション開始通知を受信すると、デバイス電源管理部35に通信デバイス15の電源状態設定要求(PSM)あるいは電源状態設定要求（Normal）を送る。なお、“電源状態設定要求（X）”とは、通信デバイスをXモードにすることを要求するものである。このように通信管理部34は、通信デバイスの動作モードを決定する。ユーザからの指示に基づいて動作モードを決定することも可能である。またTCP処理部31のコネクションの設定・解放に応じて動作モードを決定することも可能である。たとえばコネクションが解放されたとき、第1の動作モード（PLMモード）にすることを決定する。またコネクション上でのセッションの開始および終了に応じて動作モードを決定することも可能である。たとえば終了を検出したとき、第1の動作モード（PLM）にすることを決定する。なおセッションはHTTPセッションだけでなく、コネクション上で形成される任意のプロトコルのセッションが可能である。

デバイス電源管理部35は、受信した電源状態設定要求に従ってKレジスタにアクセスすることで、通信デバイス15の電源状態を制御する。なお、本実施形態では、通信デバイス15に対してのみ対応したデバイス電源管理部35が設けられるが、外部入力デバイス14やワーキングメモリ13やCPU11やそれらの接続インタフェース（PCI-Expressなど）など、すべてのコンポーネントに対応した電源状態管理部を設けることも可能である。この場合は、コンポーネント毎に、電源状態の管理を行うことができる。

端末電源状態管理部36は、デバイス電源管理部35を含むすべてのコンポーネントの電源状態を管理している。端末電源状態管理部36は、例えば通信端末1全体をスリープ状態に移行させ、スリープ状態から動作状態に復帰させる。

アプリケーションソフトウエアは、HTTP処理部41とアプリケーションデータ処理部42と外部入出力データ処理部43とを備える。

アプリケーションデータ処理部42は、HTTP処理部41から受信したアプリケーションデータを、そのアプリケーションソフトウエア固有の処理を行うものである。Webブラウザの場合には、アプリケーションデータとしてHTMLデータを受信し、それを用いてレンダリング処理（画面の画素の色や輝度値を生成する処理）を行う。レンダリング処理で生成した画素データは、外部入出力データ処理部43に送る。ここで、アプリケーションデータはHTMLデータの他に、画像データや、動画データや、音データなど様々なものが考えられる。レンダリング処理を行うデータであれば、その種類は問わない。また、レンダリング処理とは画素データを生成するだけではなく、外部に対して情報を出力するためにその出力デバイスに応じた形式のデータを生成するあらゆる処理を含んでいる。たとえば、レンダリング処理部は、音データを生成する場合や、LEDなどを制御する場合も含む。

さらに、アプリケーションデータは、JavaScript（登録商標）で書かれたプログラムであってもよい。その際には、アプリケーションデータ処理部42はそのプログラムを実行し、その結果に応じてレンダリング処理を行ったり、HTTP処理部41に新たなHTTP通信要求を行う。例えば、Google社のGoogle docsは、JavaScriptで書かれたプログラムで実現されており、アプリケーションデータ処理部42にてそのプログラムを実行することで、動作が行われる。アプリケーションデータ処理部42で処理するプログラムは、JavaScriptでの記述に限定される必要はなく、様々なプログラム言語で記述することが可能である。

アプリケーションデータ処理部42は、新たなアプリケーションデータを取得する必要が生じた場合には、そのURLを含むHTTP通信要求を送信する。たとえば、受信したアプリケーションデータに、埋め込みURLが記述されている場合や、プログラムを実行する過程で必要になった場合などがある。

さらに、外部入出力データ処理部43から外部イベントを受信すると、それに応じて新たに画素データ生成や、HTTP通信要求のHTTP処理部41への送信を行う。例えば、図10のスクロールバー位置のマウスドラッグイベントを、外部入出力データ処理部43を介して、アプリケーションデータ処理部42が受信すると、画面スクロールに対応する画素データを生成し、外部入出力データ処理部43へ送る。あるいは、図10の受信箱ボタン84のマウスクリックイベントを外部入出力データ処理部43を介して、アプリケーションデータ処理部42が受信すると、図9の受信メール一覧画面を取得するためのURLを含むHTTP通信要求を、HTTP処理部41へ送る。

外部入出力データ処理部43は、アプリケーションデータ処理部42から、画素データを受信すると、これを用いて画面表示を行う。例えば、図10のような画面表示を行う。また、マウスクリックなどの外部からのイベントを外部インタフェース部85が受信すると、これをアプリケーションデータ処理部42へ送る。

図12にHTTP処理部41の動作を示す。HTTP処理部41は、アプリケーションデータ処理部42からのHTTP通信要求を受信すると、通信管理部34へ、HTTPセッション開始通知（セッション識別情報、プロセス識別情報、コネクション識別情報）を送る（S301）。

セッション識別情報とは、アプリケーションソフトの中でHTTPセッションを一意に識別する情報であり、この情報があることにより一つのアプリケーションソフトで複数のHTTPセッションを利用することも可能となる。プロセス識別情報は、アプリケーションソフトのプロセスを識別する情報である（UNIX（登録商標）の場合）。このようにHTTPセッション開始通知が（セッション識別情報、プロセス識別情報）の組を有することで、通信端末1内でHTTPセッションを一意に識別することが可能となる。

さらに、コネクション識別情報は、HTTPセッションが使用するTCPコネクションを識別するための情報であり、例えばsocket()システムコールでOSが返すソケット番号を用いることができる。ただし、そのHTTPセッションが使用するTCPコネクションが未設定の場合は、無効な値例えば0を設定する。

次に、HTTP通信要求に含まれるURL内の宛先アドレスと、ポート番号に対するTCPコネクションの設定有無とを確認し（S302）、設定されていない場合にはTCPコネクションの設定を行う（S303）。

次に、TCPコネクションを用いてHTTPリクエストを送信し（S304）、それに対するHTTP応答を受信する（S305）。HTTP応答を受信すると、HTTPセッション終了通知（セッション識別情報、プロセス識別情報、コネクション識別情報）を、通信管理部34へ送る（S306）。この時、HTTPセッション終了通知のコネクション識別情報には、HTTPセッションに使用したTCPコネクションを識別する情報、例えばソケット番号を記す。

（画面の表示）
上述したように、本実施形態では、消費電力の少ないPLM状態においても、アソシーエションンを維持することが可能であり、さらにアソシエーションの切断を検出可能である。さらに、アソシエーションのない状態において全てのCHをスキャンすることが可能である。そのため、これらの状態に応じて、画面表示を行うことで、ユーザに通信が可能か否かを知らしめることができる。

図13にその表示例を示す。図13の画面例では、周辺アクセスポイント表示91と接続状態表示92が含まれ、また、パワーセーブモード設定ボタン93が表示されている。

接続状態表示92は、アソシエーションの有無に応じて「切断」と「接続」のどちらかを表示する。また、「接続」表示の場合には、その接続先のアクセスポイントのSSIDが表示されていることが望ましい。また、接続先のアクセスポイントのBSSIDも同時に表示されていても構わない。

パワーセーブモード設定ボタン93は、「PLM」「PSM」「NORAMAL」のいずれかの設定を行うことができる。ボタンを押下することで、ドロップダウンリストが表示され、そのリストからこれらの設定のうちのいずれかを選択する。さらに、選択されている設定が、ボタンの表面に表示される。

周辺アクセスポイント表示91は、Pレジスタに格納された情報を元に表示が行われる。PLMの場合、全チャンネルをスキャンするわけではないが、あらかじめ定められた期間、Pレジスタの内容をワーキングメモリ（図4）に保持することで、全チャネルのアクセスポイントの情報を表示することが望ましい。図13では、アクセスポイント「FREE」と
「MYHOME」と「TSB」がスキャンにより発見しており、このうち「FREE」と「MYHOME」の接続情報（SSIDやWEPキーのような認証情報）は既に通信端末１に設定済（YES）であることを表示している。図3のステップS17（ニコちゃんマーク）で、接続情報が設定済のアクセスポイントには自動で接続する場合には、「FREE」と「MYHOME」のうちあらかじめ設定された優先度の高いアクセスポイントに自動接続を行う。

また、別の表示例として、例えば、図10の例において、PLMの状態で、アソシエーションが無い場合には、次のメールボタンをグレイアウトすることで、新たに通信が発生する画面表示はできない状態であることをユーザに通知することが可能である。アソシエーションが無い場合においても、例えば、既にメール本文を取得済である場合は、前のメールボタンあるいは次のメールボタンをグレイアウトする必要はない。

以上、本実施形態によれば、アプリケーションソフトウエアが通信を行っていない場合において、通信デバイス15の電源状態を動作状態（PSMあるいはNormal）よりも低消費電力な状態（PLM）にすることにより、通信端末の消費電力を低減することが可能となる。さらに、通信が必要な際にも、アクセスポイントとのアソシエーションは維持できているため、直ちに通信を開始することが可能になり、ユーザの利便性を損なわない。

（HTTP以外のプロトコルへの適用）
これまでは、アプリケーションソフトとしてWebブラウザを想定していたが、他のアプリケーションソフトウエアや、HTTP以外のプロトコルを用いることも可能である。

例えば、アプリケーションソフトウエアがWebブラウザではなくメールソフトである場合には、プロトコルとしてPOP3（メール受信）とSMTP（メール送信）を使用する。どちらのプロトコルもそれぞれTCPコネクションを使用する。POP3は、宛先ポート番号110のTCPコネクションを設定し、このTCPコネクション上で、以下のコマンドを利用してメールの受信を行う（<>はコマンドの引数である）。

USER <ユーザ名> ： ユーザ名
PASS <パスワード>： パスワード
LIST ： 受信メール一覧要求
TOP <メッセージ番号> <行数>： 後に続く数のメール内容要求
RETR<メッセージ番号>:メッセージ取得要求
DELE <メッセージ番号>：メール削除マーキング要求
QUIT ： アップデート（更新を反映）もしくはセッションクローズ要求の送信

具体的には、メールソフトは、TCPコネクション設定後、USERコマンドとPASSコマンドでユーザ認証を行う。認証後、LISTコマンドで受信メールの一覧（メッセージ番号とデータサイズ）を取得する。TOPコマンドでは、メッセージ番号でメールを指定し、さらに指定した行数だけデータを取得する。TOPコマンドを、LISTコマンドで取得したメール一覧で指定した段数分実行することで、図9と同様の受信メール一覧画面を表示することができる。ユーザが読むメールを探している間、TCPコネクションを設定したまま通信デバイス15の電源状態をD3にすることにより、通信端末の消費電力を削減することができる。ユーザが読むメールを選択すると、通信デバイス15の電源状態をD0にし、RETRコマンドをTCPコネクションを用いて送信することで、ユーザが選択したメールメッセージ全体を取得する。取得後、通信デバイス15の電源状態をD3に変更し、図10の画面を表示する。

この動作を図5を用いて説明する。HTTP処理部41の代わりに、SMTP処理部とPOP処理部が設けられる。SMTP処理部とPOP処理部のそれぞれが、通信管理部34に通信アクティビティ情報（（SMTPセッション開始通知、SMTPセッション終了通知）、（POPセッション開始通知、POPセッション終了通知））を送る。

通信管理部34は、アプリケーションソフトウエアからセッション開始要求を受信すると、デバイス電源管理部35に通信デバイス15の電源状態設定要求(PSM)あるいは電源状態設定要求（Normal）を送る。

また、通信管理部34は、受信済みのすべてのセッション開始要求に対するセッション終了要求を受信すると、デバイス電源管理部35に通信デバイス15の電源状態設定要求(PLM)を送る。

（複数アプリケーション）
図5では、アプリケーションソフトウエアは一つのみ記しているが、複数のアプリケーションソフトウエアが実行されていてもかまわない。例えばアプリケーションソフトウエアとして、Webブラウザとメールソフトの二つが実行されている場合を考える。

この場合、通信管理部34は、通信アクティビティ情報として(Web/POP/SMTP)セッション開始通知を受信し、通信デバイス15の電源状態がPLM以外の場合に、電源状態設定要求(PSM)あるいは電源状態設定要求（Normal）を送る。通信アクティビティ情報として(Web/POP/SMTP)セッション終了通知を受信した際には、終了していないセッションが存在しない場合には（すなわちすべてのセッションが終了している場合は）、電源状態設定要求(PLM)を送る。この終了していないセッションの有無は、通信アクティビティ情報に含まれる（セッション識別情報、プロセス識別情報）を用いて、セッション開始通知とセッション終了通知の対応をとることで、判断できる。

（PSM・NORMAL状態への移行タイミング制御）
通信管理部34は、アプリケーションソフトウエアからセッション開始通知を受信した際に、別のセッション開始通知を受信するまで電源状態設定要求(PSM) あるいは電源状態設定要求(Noramal)の送信を遅らせることも可能である。これにより、複数の通信セッションの開始タイミングを合わせることができ、通信デバイス15がD0状態である時間を減らすことができる。よって消費電力を削減することができる。

ここで、通信管理部34は、常に二つ目のセッション開始要求を待つのではなく、一つ目のセッション開始要求を受信後、あらかじめ定められた時間だけ電源状態設定要求(PSM) あるいは電源状態設定要求(Noramal)の送信を待つようにすることも可能である。

あるいは、セッション開始要求に許容遅延時間をアプリケーションソフトウエアが設定し、通信管理部34は、この許容遅延時間だけ電源状態設定要求(PSM) あるいは電源状態設定要求(Noramal)の送信を遅らせることも可能である。

さらに、この許容遅延時間を通信端末1が保持するバッテリ17の電気残量が少ないほど、大きな値にしてもよい。これにより、バッテリ残量の少ない時ほど消費電力を削減することが可能となる。

（タイマでPSM・NORMALにする）
通信管理部34は、電源状態設定要求(PLM)を送信後、ある一定時間を経過した場合に、セッション開始要求の受信が無くても、電源状態設定要求(PSM) あるいは電源状態設定要求(Noramal)を送ることが望ましい。これにより、TCP以外のパケット、たとえばUDPやDHCP renewパケットなどの送信を、通信端末1が可能となる。PSMまたはNormalへの移行後、あらかじめ定められた時間が経過したら、PLMに戻ることが望ましい。

さらに、Websocketを用いている場合には、通信デバイス15がPSMあるいはNormal状態になった際に、受信可能状態である旨を相手通信端末に通知し、相手端末からのパケットを受信することも可能となる。

また、通信デバイス15がD3状態である時に、UDPやDHCP renewパケットなどTCP以外のパケットの送信要求が発生した場合は、次のようにすることが望ましい。すなわち、そのパケット送信要求の発生後、あらかじめ定められた時間を経過後には、セッション開始要求の受信が無くても通信管理部34は、電源状態設定要求(PSM) あるいは電源状態設定要求(Noramal)にすることが望ましい。

このとき、これらのTCP以外のパケットの夫々に、異なる待ち時間が予め設定されていてもよい。この場合、パケット送信要求発生後、そのパケットに対応する待ち時間が経過したら、電源状態設定要求(PSM) あるいは電源状態設定要求(Noramal)を送ることもできる。この場合、あらかじめ定められた時間がさらに経過したのちに、通信管理部34は、電源状態設定要求(PLM)を送ることが望ましい。

（通信アクティビティの把握の仕方）
これまでは、通信管理部34は、アプリケーションソフトウエアから通信アクティビティ情報を受信していたが、この通信アクティビティ情報を、デバイスドライバ33あるいはIP処理部32あるいはTCP処理部31から受信するようにすることも可能である。この場合は、セッションリクエストとセッションレスポンスを解析する機能をデバイスドライバ33あるいはIP処理部32あるいはTCP処理部31に搭載することで、通信管理部34はこれまでと同様の処理を行うことが可能となる。

あるいは、設定中のTCPコネクションが無い場合にPLM状態とし、設定中のTCPコネクションがある場合には、PSMあるいはNORMAL状態とすることも可能である。この場合は、通信アクティビティ情報をTCP処理部31が通信管理部に送ることが望ましい。

あるいは、通信管理部34は、パケットの送受信の有無に基づき通信アクティビティ情報を推測してもよい。これによって通信管理部34は、これまでと同様の処理を行うことも可能である。

（TCPコネクション以外のコネクション）
これまでは、TCPコネクションを例に説明を行ってきたが、TCPコネクション以外のコネクションを対象とすることも可能である。例えば、IPSEC通信のIPSECコネクションを対象とすることも可能である。IPSEC通信においては、送受信端末間で、セキュリティアソシエーションと呼ぶ状態を保持する。これは、IPSEC通信がTCPと同様にコネクション型の通信を行っていることを意味する。このセキュリティアソシエーションの設定には、通常IKE(Internet Key Exchange)プロトコルを用いる。このプロトコルは、処理すべきメッセージ数が多く、また処理に公開鍵暗号処理を含む場合があるなど、処理負荷が高い。それゆえ、IPSECコネクション(セキュリティアソシエーション)の再設定には、設定処理遅延が大きく、また処理負荷による消費電力が大きい。

そこで、送受信パケットのない時にIPSECコネクション（セキュリティアソシエーション）を維持したまま、通信デバイス15をPLM状態に移行し、通信時にのみPSMあるいはNormal状態に復帰させる。これにより、利便性維持と消費電力削減の両立を実現できる。

また、通信デバイス15がPLM状態の際に、通信が無くてもセキュリティアソシエーションのソフト有効期限になった際には、通信デバイスをPSMあるいはNormalに復帰し、セキュリティアソシエーションの再交渉を相手端末と行ってコネクションを維持してもよい。その後、PLMに遷移することが望ましい。

なお、上述したIPSECトンネルは一例であり、他のトンネルを対象とすることも可能である。具体的には、GRE( Generic Routing Encapsulation)トンネルや、L2TPトンネル、あるいはPPTPなど、他にも様々なトンネルプロトコルが可能である。

（ユーザ操作アクティビティとの連携）
本実施形態にかかる状態制御を、ユーザによる操作情報と連携させることも可能である。例えば、図5においてOSが外部からのユーザイベントを受信した際には、通信デバイス15をPLM状態から、PSMあるいはNormal状態に移行することも可能である。

例えば、ユーザがある一定時間、通信端末1を操作しない場合には、バックライトを消すなどにより、通信端末1に具備する液晶ディスプレイを低消費電力状態に移行する。このとき、通信デバイス15をD3状態とする。そして、その後ユーザがタッチパネルにタッチするなどして液晶ディスプレイのバックライトを点灯し、画面をユーザに提示する際に、通信デバイス15をD0状態にする。

これにより、UDPやDHCPパケットなどを送受信することが可能となり、周囲のプリンタやUPnPデバイスの有無を、液晶ディスプレイに表示することが可能となる。ユーザに画面表示が行われていない時には、このようなデバイスやサービス発見の動作は不要である。このため、画面表示が行われていないときは、通信デバイス15をPSMあるいはNormal状態とすることで、消費電力の低減を実現できる。また、ユーザに画面表示を行うタイミングで通信デバイス15をPLM状態にすることで、ユーザに通信サービスを提供する待ち時間を減らすことができる。よって、ユーザ利便性と低消費電力の両立を実現できる。

上述の例では、タッチパネルの操作を外部イベントとして扱ったが、これ以外にも、通信デバイスとは別のセンサーで得られるセンシング情報を用いることが可能である。たとえば、ボタンの押下頻度や、照度センサーにより検出する周囲の明るさの変化や、マイクにより検出する音の大きさや、バッテリ残量などを用いることが可能である。

（その他）
本実施形態では、IPv4通信を行う場合を例に説明を行っているが、これに限らず、IPv6やX.25など様々なパケット通信にも、本実施形態は適用可能である。

また、本実施形態では、IEEE802.11のインフラストラクチャモードと呼ばれる端末は、アクセスポイントとフレームの送受信を行った。これ以外にも、アドホックモードやWiFi Directと呼ばれる端末同士がフレームを送受信する形態においても、本実施形態は適用可能である。アドホックモードにおいては、認証が終了して暗号化パケットを送信可能な状態を、セッションが設定されている状態と考える。

また、本実施形態では、IEEE802.11を例に説明を行ったが、アソシエーションのように接続関係を相手通信機器との間で設定し、接続関係を設定している間のみフレーム送受信を行う他の通信方式にも、本実施形態を適用することが可能である。具体的には、Bluetooth（登録商標）やZigBee（登録商標）などを挙げることができる。Bluetooth（登録商標）では、ページ要求と応答を交換後の接続状態をアソシエーションを設定した状態と考えることができる。Zigbeeではアソシエーション/ディスアソシエーション動作によって設定解放されるものをアソシエーションと考えることができる。さらに、有線のイーサネット（登録商標）のように明示的な接続状態をMACレベルで有しない通信方式においても、例えば、RFC5191のように認証情報を通信機器とやりとりし、認証が終わった状態でのみフレームの転送を行う網においては、認証状態を接続状態の設定すなわちアソシエーション設定と考えて、本発明を同様に適用することが可能である。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

Claims (9)

1. 通信機器とアソシエーションを形成し、前記通信機器と通信する通信デバイスと、
   前記通信デバイスの動作モードを決定する通信管理部と、
   前記通信管理部により決定された動作モードに応じて、前記通信デバイスへの給電を制御するデバイス電源管理部と、を備え、
   前記デバイス電源管理部は、前記通信管理部により第1の動作モードが決定されたとき、前記通信デバイスを送受信不能な第1の電源状態に設定し、前記第1の電源状態に設定した後、第1の周期ごとに、前記通信デバイスを送信可能な第2の電源状態に設定し、
   前記通信デバイスは、前記第2の電源状態に設定されたときに、存在通知フレームを送信する
   通信端末。
2. 前記デバイス電源管理部は、前記第2の電源状態が設定されてから第1期間が経過した後、または、前記存在通知フレームを送信した後、前記通信デバイスを前記第1の電源状態に戻す
   請求項1に記載の通信端末。
3. 前記第2の電源状態は、前記通信デバイスが送受信可能な状態であり、
   前記通信デバイスは、前記存在通知フレームに対応する応答フレームを受信した後、前記通信デバイスを前記第1の電源状態に戻す
   請求項2に記載の通信端末。
4. 前記第2の電源状態は、前記通信デバイスが送受信可能な状態であり、
   前記通信デバイスは、前記存在通知フレームに対応する応答フレームを受信しなかった場合は、前記アソシエーションを破棄する
   請求項1ないし3のいずれか一項に記載の通信端末。
5. 前記デバイス電源管理部は、前記第1の動作モードが決定されたとき、第2の周期ごとに、前記通信デバイスを第2の期間の間、受信可能な第3の電源状態に設定し、
   前記通信デバイスは、前記第2の期間の間、あらかじめ定められたチャネルで、通信機器の存在通知を含むビーコンの受信を試みる、
   請求項1ないし4のいずれか一項に記載の通信端末。
6. 前記通信機器とコネクションを設定する、またはリレーを行う前記通信機器を介して第1の通信端末とコネクションを設定する、コネクション処理部をさらに備え、
   前記通信管理部は、前記コネクションが解放されたとき、前記通信デバイスを前記第1の動作モードにすることを決定する
   請求項1ないし5のいずれか一項に記載の通信端末。
7. 前記通信機器とコネクションを設定する、またはリレーを行う前記通信機器を介して第1の通信端末とコネクションを設定する、コネクション処理部をさらに備え、
   前記通信アクティティ管理部は、前記コネクション上でのセッションの終了を検出したとき、前記通信デバイスを前記第1の動作モードにすることを決定する
   請求項1ないし6のいずれか一項に記載の通信端末。
8. 前記通信デバイスが前記第2の電源状態に設定されているときに、前記アソシエーションが形成されているか否かを表示する表示部
   をさらに備えた請求項1ないし7のいずれか一項に記載の通信端末。
9. 通信デバイスを用いた通信方法であって、
   前記通信デバイスと通信機器との間にアソシエーションを形成し、前記通信機器と通信する通信ステップと、
   前記通信デバイスの動作モードを決定する通信アクティビティ管理ステップと、
   前記通信アクティビティ管理ステップにより決定された動作モードに応じて、前記通信デバイスへの給電を制御するデバイス電源状態管理ステップと、
   前記デバイス電源状態管理ステップは、前記動作モードとして第1の動作モードが決定されたとき、前記通信デバイスを送受信不能な第1の電源状態に設定し、前記第1の電源状態に設定された後、第1の周期ごとに、前記通信デバイスを送信可能な第2の電源状態に設定し、
   前記通信ステップは、前記第2の電源状態が設定されたときに、存在通知フレームを送信する、
   通信方法。

Images