特許5938831 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ サイレックス・テクノロジー株式会社の特許一覧

特許5938831無線アクセスポイント

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5938831

(24)【登録日】2016年5月27日

(45)【発行日】2016年6月22日

(54)【発明の名称】無線アクセスポイント

(51)【国際特許分類】

H04W 52/02 20090101AFI20160609BHJP

H04W 84/12 20090101ALI20160609BHJP

H04W 72/04 20090101ALI20160609BHJP

H04W 48/10 20090101ALI20160609BHJP

【ＦＩ】

H04W52/02 111

H04W84/12

H04W72/04 136

H04W48/10

【請求項の数】5

【全頁数】12

(21)【出願番号】特願2012-189388(P2012-189388)

(22)【出願日】2012年8月30日

(65)【公開番号】特開2014-49834(P2014-49834A)

(43)【公開日】2014年3月17日

【審査請求日】2015年8月28日

【早期審査対象出願】

(73)【特許権者】

【識別番号】500112146

【氏名又は名称】サイレックス・テクノロジー株式会社

(72)【発明者】

【氏名】稲井友美

【審査官】小林正明

(56)【参考文献】

【文献】特開２００７−２８８７２８（ＪＰ，Ａ）

【文献】特開２０１１−２２３１６２（ＪＰ，Ａ）

【文献】特開２００５−２７８１６３（ＪＰ，Ａ）

【文献】特開２０１１−２１７０２６（ＪＰ，Ａ）

【文献】特開２０１０−０４５５３６（ＪＰ，Ａ）

【文献】特開２００７−２８８６３９（ＪＰ，Ａ）

【文献】特開２００８−１３１３１２（ＪＰ，Ａ）

【文献】特開２０１０−２６３５４９（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ７／２４−７／２６

Ｈ０４Ｗ４／００−９９／００

(57)【特許請求の範囲】

【請求項1】

無線ステーションに対するデータ通信が存在する旨のビーコンを，所定の時間間隔にて，無線ステーションに向けて送信するビーコン送信手段と，
前記所定の時間間隔を変更する変更手段と，
前記変更手段による所定の時間間隔の変更を指示する，指示手段と，を備え，
前記指示手段は，
自身に接続している無線ステーションから送信されたＡＲＰリクエストに対する応答（ＡＲＰレスポンス）を当該無線ステーションに応答後，データ通信の存在の有無にかかわらず，データ発生を擬制して報知し，かつ前記所定の時間間隔を，当該応答前の時間間隔（ｔ４）よりも短い時間間隔（ｔ５）に変更し，
その後，所定時間経過後，前記所定の時間間隔を，当該所定時間経過前の時間間隔（ｔ５）よりも長い時間間隔（ｔ６）に変更する，
旨の指示をする，無線アクセスポイント。

【請求項2】

前記無線アクセスポイントは，さらに，ＡＲＰリクエストによってＭＡＣアドレスが解決される無線ステーションを特定する無線ステーション特定手段を備え，
前記無線ステーション特定手段が，任意の通信端末から送信された前記ＡＲＰリクエストに基づきＭＡＣアドレスの解決が必要な無線ステーションを特定し，特定された当該無線ステーションにのみ，前記ＡＲＰリクエストを送信する，請求項１に記載の無線アクセスポイント。

【請求項3】

無線ステーションに対するデータ通信が存在する旨のビーコンを，所定の時間間隔にて，無線ステーションに向けて送信するビーコン送信手段と，
前記所定の時間間隔を変更する変更手段と，
前記変更手段による所定の時間間隔の変更を指示する，指示手段と，を備え，
前記指示手段は，
自身に接続している無線ステーションに対するＴＣＰセッションが確立されると，データ通信の存在の有無にかかわらず，データ発生を擬制して報知し，かつ前記所定の時間間隔を，当該ＴＣＰセッション確立前の時間間隔（ｔ１０）よりも短い時間間隔（ｔ１１）に変更し，
その後，前記ＴＣＰセッションが解放されると，前記ＴＣＰセッションが解放される前の時間間隔（ｔ１１）よりも長い時間間隔（ｔ１２）に変更する，
旨の指示をする，無線アクセスポイント。

【請求項4】

ＴＣＰセッション確立前の時間間隔（ｔ１０）よりも短い前記時間間隔（ｔ１１）は，ＴＣＰセッション上のアプリケーションにて行われる通信のレスポンス重要度に応じて変更され得る，請求項３項記載の無線アクセスポイント。

【請求項5】

さらにＭｏｒｅＤａｔａビットをＴｒｕｅとしたフレームを送信する手段を備える請求項１乃至４のいずれかに記載の無線アクセスポイント。

【発明の詳細な説明】

【技術分野】

【0001】

本願発明は無線通信装置に関し，特に，無線ＬＡＮ通信における無線アクセスポイントに関するものである。

【背景技術】

【0002】

インフラストラクチャ型の無線ＬＡＮネットワークでは，親機として動作する無線アクセスポイント（以下，アクセスポイント）が，無線子機（以下，ステーション）を管理している。

【0003】

アクセスポイントはステーションに対して定期的にビーコンと呼ばれる無線通信に必要な情報を報知している。このビーコンを通じて，アクセスポイントは，所定のステーションに対する通信データが存在する旨を通知することができる。ユニキャストデータが存在する場合には，ＴＩＭ（Traffic Indication Message）ビーコンを使用し，ブロードキャストおよびマルチキャストデータ（以下，総称してブロードキャストデータ等）が存在する場合にはＤＴＩＭ（Delivery Traffic Indication Message）ビーコンを使用する。

【0004】

ＤＴＩＭビーコンは，通常ビーコンにおいて所定数に１回の頻度で含まれており，この頻度（間隔）をＤＴＩＭ間隔と呼ぶ。たとえば，ＤＴＩＭ間隔が３の場合は，通常のビーコン３個間隔で１つのＤＴＩＭビーコンが発信されている。アクセスポイントは，ステーション宛のブロードキャストデータ等を受信すると，すぐには送信せずに，次のＤＴＩＭビーコンを送信するタイミングまで自身に当該ブロードキャストデータ等をバッファしておく。その後，ＤＴＩＭビーコンを送信し，それに後続して当該ブロードキャストデータ等の送信を行う。なお，ＤＴＩＭビーコンは，主にステーションの省電力状態を管理する目的でアクセスポイントから発信されているものである。

【0005】

一方，ステーションは，自身の消費電力を低減するため，定期的に自身の動作モードとして，省電力状態と非省電力状態（稼働状態）を切り替えて動作している。省電力状態の場合，ステーションは無線通信を行うことができず，非省電力状態のときにのみ無線通信が可能である。このように間欠的に非省電力状態となることで，ステーションは自身の消費電力を低減させている。動作モードの切り替えタイミングは，ステーションに設定されているパラメータであるListen IntervalおよびReceive DTIMによって決まる。

【0006】

Listen Intervalは，アクセスポイントからのビーコンを受信するタイミングを意味し，たとえばListen Intervalが２であった場合は，アクセスポイントからのビーコンを２個間隔で受信するよう，自身を非省電力状態とする。

【0007】

Receive DTIMは，設定値としてTrueまたはFalseが存在し，Trueの場合は，アクセスポイントからのＤＴＩＭビーコンをすべて受信するよう，自身を非省電力状態とする。一方，Falseの場合には，ＤＴＩＭビーコンとは連動せず，上述のListen Intervalにのみ従って自身を非省電力状態とする。

【0008】

なお，ステーションは，自身が非省電力状態のときに，アクセスポイントからＤＴＩＭビーコンを受信すると，それに後続するブロードキャストデータ等も受信する。こうすることで，消費電力を低減しつつも，データの送受信を行うことができる。

【0009】

以下，ステーションがアクセスポイントから通信データを受信する動作について説明する。なお，省電力状態と非省電力状態を切り替えて動作するステーションを省電力ステーションと呼ぶことにする。

【0010】

図１は無線通信システムの全体図である。ステーション１０２はアクセスポイント１０１と接続しており，相互に無線通信が可能である。また，アクセスポイント１０１は，通信端末１０３と有線にて接続している。したがって，本図において，ステーション１０２はアクセスポイント１０１を経由して通信端末１０３と通信が可能である。

【0011】

図２はアクセスポイント１０１からステーション１０２へのデータ通信の様子である。アクセスポイント１０１からステーション１０２に向けて発信されているビーコンは，本図において数字１〜１１までの数字が付された矢印である。ビーコンの中でも，太い矢印（ビーコン３，６，９）は，ＤＴＩＭビーコンである。なお，本図の場合，ＤＴＩＭ間隔は３である。したがって，ビーコン３個につき１つのＤＴＩＭビーコンが含まれる。

【0012】

一方，ステーション１０２は，Listen Intervalが２なので，ビーコン２個間隔で自身を非省電力状態としている。なお，Receive DTIMがFalseなので，すべてのＤＴＩＭビーコンを受信するわけではなく，Listen Intervalに基づいてのみ非省電力状態となっている。

【0013】

また，本図では，ビーコン４のタイミングにてブロードキャスト等の通信データが発生している（実際にはデータ発生とビーコンタイミングとは独立したものである）。たとえば，通信端末１０３からステーション１０２に向けて送信された通信データである。

【0014】

この時点で，アクセスポイント１０１は，ステーション１０２に対して当該データの存在を通知することはない。その理由は，ＤＴＩＭビーコンを発信するタイミングではないためである。

【0015】

その後のＤＴＩＭビーコンの発信タイミング（ビーコン６）にて，データの存在をステーション１０２に通知しようとするが，このタイミングでは，ステーション１０２は省電力状態のため，当該ＤＴＩＭビーコンを受信できない。つまり，自身に対するデータの存在を認識することができない。その間，アクセスポイント１０１は，ステーション１０２に対するデータを自身にバッファしておく。

【0016】

ステーション１０２がデータの存在を認識することができるのは，ビーコン９のＤＴＩＭビーコン受信時となる。この時に初めてステーション１０２は，データの存在を認識し，アクセスポイント１０１からデータを受信することができる。

【0017】

このように，省電力機能を有するステーション１０２は，常に稼働しているわけではない（非省電力状態ではない）ことから，必要なタイミングですぐに通信を開始できない場合がある。このため，ある程度の遅延発生が避けられない。たとえば，常に非省電力状態（稼働状態）にあるステーションならば，ＤＴＩＭビーコン６を受信した時点でデータ受信を開始することが可能である。つまり，ビーコン間隔が１００ミリ秒ならば，３００ミリ秒の遅延が発生するわけである。

【0018】

このような遅延を低減する手段として，ＤＴＩＭ間隔を動的に変更する技術が知られている（非特許文献１）。たとえば，ステーション１０２に対するブロードキャスト等の通信データが存在する場合には，ＤＴＩＭ間隔を短くして，迅速にステーション１０２にその旨を通知しようとするものである。

【先行技術文献】

【特許文献】

【0019】

【非特許文献1】日経ＢＰ社ホームページ＜http://itpro.nikkeibp.co.jp/article/COLUMN/20060929/249406/＞

【0020】

非特許文献１に開示の技術は，ある程度の遅延低減に貢献すると期待されるが，当該非特許文献１ではＤＴＩＭ間隔の変更契機（トリガ）が明確に記載されていない。例えば，もっとも容易なパターンである，ステーション１０２に向けたデータが実際に存在する場合をＤＴＩＭ間隔の変更トリガと想定すると，その効果は限定的となる。

【発明の概要】

【発明が解決しようとする課題】

【0021】

本願発明はかかる課題を解決するものである。すなわち，省電力ステーションを自身に接続している無線子機として擁するアクセスポイントであって，省電力ステーションの消費電力を低減しつつも遅延の少ない無線通信を行うことのできるアクセスポイントを提供する。

【課題を解決するための手段】

【0022】

本願発明にかかる第１の形態は，無線ステーションに対するデータ通信が存在する旨のビーコンを，所定の時間間隔にて，無線ステーションに向けて送信するビーコン送信手段と，所定の時間間隔を変更する変更手段と，変更手段による所定の時間間隔の変更を指示する，指示手段と，を備え，指示手段は，無線ステーションが自身に接続した時点において，所定の時間間隔を，無線ステーションが自身に接続する前の時間間隔（ｔ１）よりも短い時間間隔（ｔ２）に変更し，その後，所定時間経過後，所定の時間間隔を，当該所定時間経過前の時間間隔（ｔ２）よりも長い時間間隔（ｔ３）に変更する，旨の指示をする，無線アクセスポイントである。

【0023】

本願発明にかかる第２の形態は，無線ステーションに対するデータ通信が存在する旨のビーコンを，所定の時間間隔にて，無線ステーションに向けて送信するビーコン送信手段と，所定の時間間隔を変更する変更手段と，変更手段による所定の時間間隔の変更を指示する，指示手段と，を備え，指示手段は，自身に接続している無線ステーションから送信されたＡＲＰリクエストに対する応答（ＡＲＰレスポンス）を当該無線ステーションに応答後，所定の時間間隔を，当該応答前の時間間隔（ｔ４）よりも短い時間間隔（ｔ５）に変更し，その後，所定時間経過後，所定の時間間隔を，当該所定時間経過前の時間間隔（ｔ５）よりも長い時間間隔（ｔ６）に変更する，旨の指示をする，無線アクセスポイントである。

【0024】

さらに好ましくは，無線アクセスポイントは，さらに，ＡＲＰリクエストによってＭＡＣアドレスが解決される無線ステーションを特定する無線ステーション特定手段を備え，無線ステーション特定手段が，任意の通信端末から送信されたＡＲＰリクエストに基づきＭＡＣアドレスの解決が必要な無線ステーションを特定し，特定された当該無線ステーションにのみ，ＡＲＰリクエストを送信する。

【0025】

本願発明にかかる第３の形態は，無線ステーションに対するデータ通信が存在する旨のビーコンを，所定の時間間隔にて，無線ステーションに向けて送信するビーコン送信手段と，所定の時間間隔を変更する変更手段と，変更手段による所定の時間間隔の変更を指示する，指示手段と，を備え，指示手段は，自身に接続している無線ステーションへの無線フレームを所定の場所にバッファ後，所定の時間間隔を，当該バッファ前の時間間隔（ｔ７）よりも短い時間間隔（ｔ８）に変更し，その後，所定時間経過後，所定の時間間隔を，当該所定時間経過前の時間間隔（ｔ８）よりも長い時間間隔（ｔ９）に変更する，旨の指示をする，無線アクセスポイントである。

【0026】

本願発明にかかる第４の形態は，無線ステーションに対するデータ通信が存在する旨のビーコンを，所定の時間間隔にて，無線ステーションに向けて送信するビーコン送信手段と，所定の時間間隔を変更する変更手段と，変更手段による所定の時間間隔の変更を指示する，指示手段と，を備え，指示手段は，自身に接続している無線ステーションに対するＴＣＰセッションが確立されると，所定の時間間隔を，当該ＴＣＰセッション確立前の時間間隔（ｔ１０）よりも短い時間間隔（ｔ１１）に変更し，その後，ＴＣＰセッションが解放されると，ＴＣＰセッションが解放される前の時間間隔（ｔ１１）よりも長い時間間隔（ｔ１２）に変更する，旨の指示をする，無線アクセスポイントである。

【0027】

本願発明にかかる第５の形態は，通信端末に対するデータ通信が存在する旨の報知を，所定の時間間隔にて，通信端末に向けて送信する報知手段と，所定の時間間隔を変更する変更手段と，変更手段による所定の時間間隔の変更を指示する，指示手段と，を備え，指示手段は，所定の条件が充足されると，所定の時間間隔を，所定の条件が充足される前の時間間隔（ｔ１３）よりも短い時間間隔（ｔ１４）に変更し，その後，所定時間経過後，所定の時間間隔を，当該所定時間経過前の時間間隔（ｔ１４）よりも長い時間間隔（ｔ１５）に変更する，旨の指示をする，通信装置である。

【0028】

さらに好ましくは，所定の条件は，通信端末に対するデータ通信が発生する前であって，データ通信が発生すると予測されることである。

【0029】

上述の指示手段が指示する所定の時間間隔の変更は，１００ミリ秒などの絶対的な時間間隔の変更を意味することはもちろんのこと，ＤＴＩＭビーコン頻度（段落番号０００４参照のこと）について説明した様な，所定の絶対的な時間間隔を１単位とした，当該単位の数の変更も含むものである。

【発明の効果】

【0030】

本願発明にかかるアクセスポイントは，ステーションに対する通信データが実際に発生している場合だけでなく，通信データの発生が予測できる場合にもＤＴＩＭ間隔を変更する。さらに，ステーションからのＡＲＰリクエストに対しては，対応するステーションにのみこのリクエストを転送する。これにより，ステーションの消費電力を低減しつつも，迅速に通信を開始することができる。結果として，消費電力の低減および通信パフォーマンスを両立することができる。

【発明を実施するための形態】

【0031】

以下では図面を参照し本願発明に係る実施例を説明する。なお，以下ではＤＴＩＭビーコンの間隔変更の仕組みについて説明しているが，ＴＩＭビーコンでも同様である。
［実施例１］
［システム全体図］

【0032】

本実施例にかかるシステム全体図は，すでに説明した図１と同様であるため，説明を省略する。なお，本図において本願発明にかかる装置はアクセスポイント１０１である。
［ＤＴＩＭ間隔］

【0033】

本実施例にかかるアクセスポイント１０１は，所定の条件が満たされると，ＤＴＩＭ間隔を動的に変更する。たとえば図３のように変更する。通常はＤＴＩＭ間隔を３で運用しているアクセスポイント１０１であるが，所定条件が充足されることで，ＤＴＩＭ間隔を１に変更し，この状態を所定時間継続させたのちに，元のＤＴＩＭ間隔に戻す。

【0034】

このようにＤＴＩＭ間隔を短くすることで，省電力状態のステーション１０２に対し，ブロードキャストデータ等の存在を迅速に通知することができ，結果としてユニキャスト通信の迅速な開始にも寄与する。本願発明は，このＤＴＩＭ間隔を変更する契機となる条件がポイントとなるものである。
［ＤＴＩＭパターン］

【0035】

図４は本実施例にかかるＤＴＩＭビーコンのパターンである。なお，本実施例における平常時のＤＴＩＭ間隔は２としている。

【0036】

本実施例のポイントは，ＤＴＩＭビーコン１の直前にある，ステーション１０２からアクセスポイント１０１への接続４０１を行った後で，ＤＴＩＭ間隔を２から１に変更するところにある。この接続４０１とは，ＴＣＰ等の接続ではなく，物理層およびデータリンク層での接続を意味し，具体的には，アクセスポイント１０１とステーション１０２との間のアソシエーション処理のことである。

【0037】

アソシエーション直後においてＤＴＩＭ間隔を短くしている（ＤＴＩＭビーコン１〜６）理由は，ステーション１０２が通信を行うための具体的事由があるために接続が行われたと推測されるためである。このＤＴＩＭビーコン１〜６は，実際のブロードキャストデータ等が存在していないにもかかわらず，データが発生しているように擬制して通知されるものである。

【0038】

したがって，アソシエーション直後において所定時間のあいだ，ＤＴＩＭ間隔を短くすることで，ステーション１０２を迅速に非省電力状態とさせることができる。なお，実際には，ＤＴＩＭ間隔を短くすると同時に，上述の擬制したデータ発生を引き続き通知することで，ステーション１０２を所定時間継続して非省電力状態とさせている。

【0039】

データ発生を擬制する手段としては，フレーム制御フィールド中に含まれ，後続する送信待ちデータの存在の有無を示すＭｏｒｅＤａｔａ（モアデータ）ビットをTrue（データあり）にするといった手段がある。

【0040】

所定時間経過した後，平常時のＤＴＩＭ間隔に戻す（データ発生を擬制した通知も取り消す）ことにより，ステーション１０２は省電力状態と非省電力状態をListen Interval間隔にて繰り返す動作に戻る。

【0041】

以上説明したように，本実施例では，ステーション１０２とアクセスポイント１０１とのアソシエーションの存在を通信開始の前触れと判断することでＤＴＩＭビーコン間隔を短くする。
［実施例２］

【0042】

図５は本実施例にかかるＤＴＩＭビーコンのパターンである。なお，本実施例における平常時のＤＴＩＭ間隔は３としている。

【0043】

ビーコン１，４〜１３は，ＤＴＩＭビーコンである。ＡＲＰリクエスト（ブロードキャスト通信）は，通信端末１０３からステーション１０２に向けて送信されるものである。通信端末１０３は，ＡＲＰリクエスト５０１にて，ステーション１０２のＩＰアドレスを解決しようとするが，このタイミングでは，ステーション１０２が非省電力状態であるため，当該ＡＲＰリクエスト５０１はステーション１０２に到達しない。このため，アクセスポイント１０２は，当該ＡＲＰリクエスト５０１をいったん自身にバッファする。

【0044】

アクセスポイント１０２は，ＡＲＰリクエスト５０１を自身にバッファしたことをトリガとして，ＤＴＩＭビーコン間隔を変更し発信する（ＤＴＩＭビーコン４以降）。これを受信したステーション１０２は，省電力状態から非省電力状態に移行する。

【0045】

次いでアクセスポイント１０１は，バッファしておいたＡＲＰリクエストをステーション１０２に向けて送信する（ＡＲＰリクエスト５０２）。このタイミングにおいて，ステーション１０２は非省電力状態であるため，当該ＡＲＰリクエスト５０２を受信することができる。

【0046】

一方，ステーション１０２は，受信したＡＲＰリクエスト５０２に対する応答としてＡＲＰレスポンス５０３を通信端末１０３に向けて送信する。これにより，通信端末１０３とステーション１０２との間において，ＩＰ層より上位の通信が可能になる。

【0047】

なお，上位層の通信が可能になったとはいえ，実際にデータの送受信が始まるのがどのタイミングかを特定することは，この時点ではできない。しかし，実際のデータの送受信に対する遅延を少なくするため，継続してステーション１０２を非省電力状態にする必要がある。このため，本実施例においても実施例１と同じくＤＴＩＭビーコン等を用いてステーション１０２を継続して非省電力状態とさせる。具体的にはＤＴＩＭビーコン７〜１３がデータの発生が擬制されたビーコンとなる。

【0048】

図示したように本実施例では，２つの所定時間が存在し，その時間のあいだアクセスポイント１０１はＤＴＩＭ間隔を短くしている。

【0049】

１つは，通信端末１０３からのＡＲＰリクエスト５０１をバッファした段階である。ＡＲＰリクエストが存在するということは，その後，ＩＰ層以上での通信が行われる可能性が極めて高いため，ステーション１０２を常に非省電力状態とさせている。

【0050】

もう１つは，ステーション１０２からのＡＲＰレスポンス５０３がＡＲＰリクエスト発信元である通信端末１０３に応答された後の所定時間である。これも前者と同様，この後においてＩＰ層以上での通信が開始される可能性が極めて高いと推測されるためである。上述したように，この場合も，上位層における実際のデータ通信がいつ行われるかわからないため，ＤＴＩＭビーコンなどを用いてステーション１０２を継続して非省電力状態にしておく必要がある。

【0051】

以上説明したように，本実施例では，ＡＲＰリクエストおよびＡＲＰレスポンスの存在を通信開始の前触れとして判断することでＤＴＩＭビーコン間隔を短くする。

【0052】

なお，アクセスポイント１０１からのＡＲＰリクエスト５０２は，通常はブロードキャスト通信にて行われるものである。したがって，これをそのまま無線通信として送信すると，ＡＲＰリクエスト５０２の対象となるステーション１０２以外のステーションを非省電力状態にしてしまうという問題が発生する。

【0053】

このような問題を回避するための一つの手段として，アクセスポイント１０１は，事前にＲＡＲＰ（Reverse Address Resolution Protocol）などの手段によりステーションのＩＰアドレスを取得し，すべてのステーションのＩＰアドレスとＭＡＣアドレスの対応を予め把握しておく。これにより，ＡＲＰリクエスト５０２の対象となるステーション１０２を特定することができ，このステーションにのみ当該リクエストを送信することができるため，他のステーションの省電力状態を阻害することなく，ＡＲＰリクエスト５０１に対する応答が可能になる。結果として，無線システム全体としての省電力に貢献することができる。

【0054】

なお，ステーションのＩＰアドレスを取得し，ＡＲＰリクエスト５０２の対象となるステーションを特定する手段（無線ステーション特定手段）としては，同様のことが可能であれば，上述のＲＡＲＰに限らず，様々な手段が利用可能である。つまり，ＡＲＰリクエスト５０２に対して，これをブロードキャストにて転送することなく，アクセスポイント１０１が一意にステーションを特定できればよい。
［実施例３］

【0055】

図６は本実施例にかかるＤＴＩＭビーコンのパターンである。なお，本実施例における平常時のＤＴＩＭ間隔は３としている。

【0056】

ビーコン１，４〜８，１１は，ＤＴＩＭビーコンである。図からわかるとおり，本実施例の特徴は，ＴＣＰセッション継続期間においてＤＴＩＭビーコンの間隔を短くすることである。ＴＣＰセッションが継続している間は，常にＴＣＰデータの送受信が行われる可能性のある状態であり，その期間においてステーション１０２を非省電力状態にしておくことが望ましいためである。

【0057】

もちろん，上述した実施例と同じく，ＴＣＰセッションが存在するとはいえ，実際のデータ通信が伴わない場合もあるため，ＤＴＩＭビーコンなどを用いてステーション１０２を継続して非省電力状態にしておく必要がある。具体的にはＤＴＩＭビーコン４〜８である。
［その他の実施例］

【0058】

これまでの実施例では，ＤＴＩＭ間隔を常に１にするようにしてきたが，必ずしも１ではなく，平常時のＤＴＩＭ間隔よりも短いものであれば，どのような間隔でも効果がある。また，ＤＴＩＭ間隔を変更する契機となるトリガの種類に応じて，ＤＴＩＭ間隔を変更することも可能である。たとえば，実施例１で示したような，ステーション１０２とアクセスポイント１０１とのアソシエーションは，ＴＣＰセッションの継続期間よりも，データ通信の発生確率が低いと推測される場合には，ＤＴＩＭ間隔を１ではなく２にすることも可能である。

【0059】

さらに，短くしたＤＴＩＭ間隔を戻す際，必ずしも平常時のＤＴＩＭ間隔に戻す必要はなく，当該短くしたＤＴＩＭ間隔よりも長い間隔でさえあればよい。たとえば，平常時のＤＴＩＭ間隔が３で，これを１に変更した後，元の３ではなく２に戻すといった具合である。もちろん，平常時のＤＴＩＭ間隔よりも長いもの（たとえば４など）に戻すことも可能である。

【0060】

また，ＤＴＩＭ間隔を短くする代わりに，ビーコンの報知間隔そのものを短くすることも可能である。即ち，通常は１００ミリ秒間隔で報知しているビーコン間隔を５０ミリ秒にすることで，ＤＴＩＭ間隔を半分にするのと同じ効果が得られる。

【0061】

さらに，ＴＣＰセッション上で行われるアプリケーションの通信に踏み込んで，ＤＴＩＭ間隔を変更することも可能である。たとえば，図７に示すように，所定の記憶領域に，各アプリケーションのセッション情報（アプリケーションおよびポート番号）とレスポンスの重要度，およびＤＴＩＭ間隔を対応付けた情報をセットとして保持しておき，所定のセッションによる通信が発生している場合には，該当するＤＴＩＭ間隔に変更する。もちろん，レスポンス重要度が高い場合にはＤＴＩＭ間隔は短く設定され，反対に重要度が低い場合にはＤＴＩＭ間隔は長く設定される。これにより，アプリケーションにて実際に行われる通信のレスポンス重要度に応じてＤＴＩＭ間隔を変更することができる。

【0062】

なお，以上で説明した各実施例に共通するアクセスポイント１０１の機能ブロック図を図８に示す。ＤＴＩＭビーコン発信手段８０１は，ＤＴＩＭビーコンを発信する手段である。

【0063】

ＤＴＩＭ間隔変更手段８０２は，ＤＴＩＭビーコンが発信される間隔（周期）を動的に変更する手段であり，その値は後述するＤＴＩＭ間隔変更指示手段８０３により指定される。

【0064】

ＤＴＩＭ間隔変更指示手段８０３は，これまでの実施例で説明した状況に応じた値にＤＴＩＭ間隔に変更するようＤＴＩＭ間隔変更手段８０２に指示を出す。

【0065】

擬制データ報知指示手段８０４は，フレーム制御フィールド中に含まれ，後続する送信待ちデータの存在の有無を示すＭｏｒｅＤａｔａ（モアデータ）ビットをTrue（データあり）にするといったことをＤＴＩＭビーコン発信手段８０１に指示する手段である。
［まとめ］

【0066】

【図面の簡単な説明】

【0067】

【図1】システム全体図