無線通信端末
【課題】他の装置が使用するアプリケーションに関する情報を適切に受信しつつ消費電力を低減する。
【解決手段】移動可能な無線通信端末ＳTA１が、他の無線通信装置ＳTA２との間にＭＡＣ層レベルのアソシエーションを確立するＭＡＣ層制御部２０と、アソシエーションの確立前または確立過程において、他の無線通信装置ＳTA２が使用可能なアプリケーションに関する第１情報ＡIを示す情報要素ＩEを含んだＭＡＣフレームＦを他の無線通信装置ＳTA２から受信する受信部１０と、自機ＳTA１が使用可能なアプリケーションに関する第２情報５０１，５０２，５０３を記憶する記憶部５０と、第１情報ＡIと第２情報５０１，５０２，５０３とが一致した場合にはアソシエーションの確立を実行し、第１情報ＡIと第２情報５０１，５０２，５０３とが一致しない場合にはアソシエーションの確立を中止する判断部４０とを備える。
【解決手段】移動可能な無線通信端末ＳTA１が、他の無線通信装置ＳTA２との間にＭＡＣ層レベルのアソシエーションを確立するＭＡＣ層制御部２０と、アソシエーションの確立前または確立過程において、他の無線通信装置ＳTA２が使用可能なアプリケーションに関する第１情報ＡIを示す情報要素ＩEを含んだＭＡＣフレームＦを他の無線通信装置ＳTA２から受信する受信部１０と、自機ＳTA１が使用可能なアプリケーションに関する第２情報５０１，５０２，５０３を記憶する記憶部５０と、第１情報ＡIと第２情報５０１，５０２，５０３とが一致した場合にはアソシエーションの確立を実行し、第１情報ＡIと第２情報５０１，５０２，５０３とが一致しない場合にはアソシエーションの確立を中止する判断部４０とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信端末に関する。
【背景技術】
【０００２】
近年、スマートフォンに代表される多機能携帯電話が普及している。今後、多機能携帯電話の販売量はさらに大きく伸びるものと予測されている。一般的に、多機能携帯電話は近接無線通信用のインターフェース（無線LANまたはブルートゥース（登録商標）を利用した通信インターフェース）を有しており、多機能携帯電話の魅力の一因となっている。
【０００３】
携帯電話以外の携帯型機器においても、無線LANまたはブルートゥースを利用した通信が可能となりつつある。例えば、非特許文献１に開示されているように、任天堂株式会社のゲーム機器で実行可能なすれ違い通信（StreetPass Communication）では、互いに接近している移動可能なゲーム機器同士で通信が可能である。すなわち、基地局を介さずに端末間での直接的な通信が可能である。以下、端末間での直接的な通信を「端末間通信」と呼ぶ。すれ違い通信には、IEEE 802.11（非特許文献２）が使用される。
【０００４】
図１を参照して、従来技術における端末間通信の接続開始手順を説明する。無線通信端末は、無線通信可能な他の装置（無線通信端末、アクセスポイント又はその他の装置）を発見するためのスキャニングを実行する（ステップS101）。スキャニングにより他の装置を発見した無線通信端末は、他の装置との間で認証（authentication）およびアソシエーション確立を実行する（ステップS102）。アソシエーションの確立後、無線通信端末は、DHCP（Dynamic Host Configuration Protocol）により他の装置からIPアドレスを取得し（ステップS103）、他の装置との間にTCPコネクションを確立するためにSYNセグメントを送信する（ステップS104）。SYNセグメントを受信した他の装置は、無線通信端末にSYN/ACKセグメントを送信する。無線通信装置は、受信したSYN/ACKセグメントが示すポート番号に基づいて他の装置が使用するアプリケーションを特定し、特定されたアプリケーションと無線通信端末自身が使用するアプリケーションとが一致するか否かを判定する（ステップS105）。アプリケーションが一致した場合には（ステップS105：YES）、受信したSYN/ACKセグメントに対してACKセグメントを送信してTCPコネクションを確立し（ステップS106）、アプリケーション層での通信を開始する（ステップS107）。他方、アプリケーションが一致しなかった場合には（ステップS105：NO）、SYN/ACKセグメントに対してFINセグメント（またはRSTセグメント）を送信し、TCPコネクションを確立せずに接続を終了する（ステップS108）。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】andriasang.com、"Nintendo Brings New Services to 3DS"、[online]、[平成２３年３月１７日検索]、インターネット（ＵＲＬ：http://www.andriasang.com/e/blog/2010/09/30/3ds_services/）
【非特許文献２】IEEE Computer Society、"IEEE Std 802.11.TM-2007"、IEEE Standard for Information technology、Telecommunications and information exchange between systems、Local and metropolitan area networks、Specific requirements、Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications、２００７年６月１２日
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ＴＣＰコネクション確立試行の段階で他の装置が使用するアプリケーションを特定する従来の技術では、アプリケーションが一致しないためアプリケーション層での通信が不可能な場合であっても、他の装置との間でＭＡＣ層からトランスポート層までの接続処理が発生する。そのため、無線通信端末の消費電力が過大となる。以上の課題は、移動中にすれ違う他の多数の無線通信端末の各々に対して端末間通信を試行する無線通信端末において特に顕著となる。
【０００７】
本発明は、上記の課題に鑑みてなされたもので、他の装置が使用するアプリケーションに関する情報を適切に受信して消費電力を低減することが可能な無線通信端末を提供するものである。
【課題を解決するための手段】
【０００８】
本発明に係る無線通信端末は、移動可能であり、他の無線通信装置との間にＭＡＣ層レベルのアソシエーションを確立するＭＡＣ層制御部と、前記アソシエーションの確立前または確立過程において、前記他の無線通信装置が使用可能なアプリケーションに関する第１情報を示す情報要素を含んだＭＡＣフレームを前記他の無線通信装置から受信する受信部と、自機が使用可能なアプリケーションに関する第２情報を記憶する記憶部と、前記第１情報と前記第２情報とが一致した場合には前記アソシエーションの確立を実行し、前記第１情報と前記第２情報とが一致しない場合には前記アソシエーションの確立を中止する判断部とを備える。
本明細書において、「（第１情報と第２情報との）一致」とは、第１情報が示す内容と第２情報が示す内容とが完全に同一であることのみを意味するものではなく、例えば、第１情報と第２情報との少なくともいずれか一方が複数の内容を含む場合、第１情報に含まれる特定の内容と第２情報に含まれる特定の内容とが同一であること、すなわち第１情報と第２情報とが部分的に一致することをも包括する概念である。
【０００９】
以上の構成によれば、ＭＡＣ層レベルのアソシエーションの確立前または確立過程においてアプリケーションに関する情報の一致が判断されるため、一致判断のために認証、アソシエーション確立以降の接続処理が必要な構成と比較して、無線通信端末の処理負荷が低減される。したがって、無線通信端末の消費電力を低減することが可能である。また、アプリケーションに関する情報が不一致の場合にはアソシエーションの確立前または確立過程において通信が終了することから、他の無線通信装置にてアプリケーションが起動されることも抑制される。したがって、他の無線通信装置の消費電力もが低減され得る。
【００１０】
本発明の好適な態様において、前記ＭＡＣフレームは、通信相手の発見、通信相手の認証、または通信相手とのアソシエーションのために送信されるマネジメントフレームのいずれかである。
以上の構成によれば、アソシエーションの確立前または確立過程において用いられるマネジメントフレームがアプリケーションに関する情報（第１情報）を有するから、新たな型のフレームを設けることなく上述した一致の判断を実現することが可能となる。
【００１１】
本発明の好適な態様において、前記第１情報は、前記アプリケーションを特定する情報を含む。また、より好適な態様において、前記アプリケーションを特定する情報は、前記アプリケーションに対応づけられたポート番号またはＩＰアドレスである。
以上の構成によれば、アソシエーションの確立が完了しなくても、他の無線通信装置が使用可能なアプリケーションを特定することが可能となる。
【００１２】
本発明の好適な態様において、前記第１情報は、前記アプリケーションにて使用されるパラメータを特定する情報を含む。また、より好適な態様において、前記パラメータを特定する情報は、前記パラメータに対応づけられたポート番号またはＩＰアドレスである。
以上の構成によれば、アソシエーションの確立が完了しなくても、他の無線通信装置のアプリケーションにて使用されるパラメータを特定することが可能となる。
【００１３】
本発明の好適な態様において、前記パラメータを特定する情報は、前記他の無線通信装置のユーザが前記アプリケーションにて使用するユーザ識別子である。前記ユーザ識別子は、前記他の無線通信装置のユーザの電子署名に関する情報でもよい。
以上の構成によれば、アソシエーションの確立が完了しなくても、他の無線通信装置のユーザが希望する通信相手であるか否かを判断することができる。
【００１４】
本発明の好適な態様において、前記第１情報は、前記アプリケーションを使用する前記他の無線通信装置が、前記無線通信端末と無線通信を開始すべき時刻を含む。
以上の構成によれば、アソシエーションの確立が完了しなくても、他の無線通信装置が無線通信を開始すべき時刻を把握可能である。したがって、無線通信の再開がより円滑に行われる。
【００１５】
本発明の好適な態様において、前記第１情報は、前記アプリケーションを使用する前記他の無線通信装置が、前記無線通信端末との無線通信を実行する通信間隔を含む。
以上の構成によれば、アソシエーションの確立が完了しなくても、他の無線通信装置との通信間隔を把握可能である。したがって、間欠的な無線通信がより円滑に行われる。
【００１６】
本発明の好適な態様において、前記第１情報は、前記アプリケーションを使用する前記他の無線通信装置と前記無線通信端末との間で発生する通信データ量に関する情報を含む。
以上の構成によれば、アソシエーションの確立が完了しなくても、他の無線通信装置との間で発生する通信データ量を把握可能である。したがって、大容量データの送受信による消費電力の増大を避けることが可能である。
【図面の簡単な説明】
【００１７】
【図１】従来の端末間通信の接続開始手順を示すフローチャートである。
【図２】本発明の実施の形態に係る無線通信端末の構成を示すブロック図である。
【図３】端末間通信可能な２つの無線通信端末が接近している状態を示す概略図である。
【図４】本発明の端末間通信の接続開始手順を示すフローチャートである。
【図５】一般的なＭＡＣフレームのフォーマットを示す図である。
【図６】IEEE 802.11に規定されるＭＡＣヘッダの基本フォーマットを示す図である。
【図７】マネジメントフレームＦMのＭＡＣヘッダ部分のフォーマットを示す図である。
【図８】ビーコンフレームＦMBのフレームボディ部分のフォーマットを示す図である。
【図９】プローブレスポンスフレームＦMRのフレームボディ部分のフォーマットを示す図である。
【図１０】実施例１のアプリケーション特定の様子を示す図である。
【図１１】実施例１のアプリケーション特定の様子を示す図である。
【図１２】実施例２のパラメータ特定の様子を示す図である。
【図１３】実施例３のユーザ識別子の一致判定の様子を示す図である。
【発明を実施するための形態】
【００１８】
以下、添付の図面を参照しながら本発明に係る様々な実施の形態を説明する。
【００１９】
＜無線通信端末の構成＞
図２は、本発明の実施の形態に係る無線通信端末ＳTAの構成を示すブロック図である。無線通信端末ＳTAは、受信部１０と、通信制御部２０と、アプリケーション通信部３０と、判断部４０と、記憶部５０と、送信部６０とを備える。受信部１０は無線受信を行うための受信回路であり、送信部６０は無線送信を行うための送信回路である。受信部１０および送信部６０はIEEE 802.11bに準拠した無線インターフェースを含む。通信制御部２０、アプリケーション通信部３０、および判断部４０は、図示しないＣＰＵ（Central Processing Unit）がコンピュータプログラムを実行し、そのコンピュータプログラムに従って機能することによって実現される機能ブロックである。記憶部５０は、自機が使用可能なアプリケーションに関する情報を書換え可能に記憶する記憶媒体（例えばEEPROM（Electrically Erasable and Programmable ROM））である。
【００２０】
アプリケーション通信部３０は、端末間通信にて実行されるアプリケーション間通信を実行する機能を有する。すなわち、端末間通信を実行する際、アプリケーション通信部３０は端末間通信時に使用されるアプリケーションに従ってデータ信号を生成して通信制御部２０に供給する。通信制御部２０は、アプリケーション通信部３０から供給されたデータ信号をＴＣＰセグメント→ＩＰパケット→ＭＡＣフレームＦの順に変換して送信部６０に供給する。送信部６０はＭＡＣフレームＦを無線通信信号に変換して送信する。一方、受信部１０は他の無線通信端末ＳTAが送信した無線通信信号を受信してＭＡＣフレームＦに変換して通信制御部２０に供給する。通信制御部２０は、供給された無線通信信号をＭＡＣフレームＦ→ＩＰパケット→ＴＣＰセグメントの順に変換した後、ＴＣＰセグメントからデータ信号を生成してアプリケーション通信部３０に供給する。
【００２１】
また、通信制御部２０はＭＡＣ層制御部としても機能する。通信制御部２０は、自機（無線通信端末ＳTA１）に接近した他の無線通信端末ＳTA２との間でマネジメントフレームＦM（後述）を互いに送受信して、ＭＡＣ層レベルのアソシエーションを確立する機能を有する。すなわち、通信制御部２０は、ＭＡＣ層の機能を実行するＭＬＭＥ（MAC sublayer management entity）である。
【００２２】
＜アソシエーション確立要否判断の概略＞
図３は、端末間通信が可能な２つの無線通信端末ＳTA１，ＳTA２が接近している状態を示す。無線通信端末ＳTA１，ＳTA２の一方または両方が移動しており、無線通信端末ＳTA１の無線通信可能圏ＲA１に無線通信端末ＳTA２があり、無線通信端末ＳTA２の無線通信可能圏ＲA２に無線通信端末ＳTA１がある。すなわち、無線通信端末ＳTA１と無線通信端末ＳTA２とは相互に無線通信可能な位置に存在する。
【００２３】
図４を参照して、本発明の端末間通信の接続開始手順を説明する。無線通信端末ＳTA１は、無線通信可能な他の装置を発見するためのスキャニングを実行する（ステップS201）。スキャニングの具体的な方式としては、非特許文献２のSubclause 11.1.3に規定されるように、無線通信端末ＳTA１がプローブリクエストフレームＦMQを送信し、そのプローブリクエストフレームＦMQを受信した他の無線通信端末ＳTA２が返信するプローブレスポンスフレームＦMRを受信して端末の発見を行うActive Scanning方式と、他の無線通信端末ＳTAが随時に送信するビーコンフレームＦMBを受信して端末の発見を行うPassive Scanning方式とが存在するが、両方式とも端末間通信が可能な他の無線通信端末ＳTAが送信するマネジメントフレームＦMを受信してスキャニングを実行する点については共通である。以下では、ビーコンフレームＦMBを使用するPassive Scanning方式を例示して説明するが、本発明の構成としてActive Scanning方式も採用可能なことは当然に理解される。
【００２４】
無線通信端末ＳTA１の近傍には無線通信端末ＳTA２が存在するので、無線通信端末ＳTA２が送信するビーコンフレームＦMBが無線通信端末ＳTA１の受信部１０に受信される。スキャニングの過程で無線通信端末ＳTA２を発見した無線通信端末ＳTA１は、ビーコンフレームＦMBに含まれる無線通信端末ＳTA２が使用可能なアプリケーションに関する情報と、記憶部５０に記憶された無線通信端末ＳTA１が使用可能なアプリケーションに関する情報とが一致するか否かを判断する（詳細は後述される）。アプリケーションが一致すると判断すると（S202：YES）、通信制御部２０は無線通信端末ＳTA２との間で認証およびアソシエーション確立を実行する（ステップS204）。アソシエーションが確立されると、無線通信端末ＳTA１および無線通信端末ＳTA２によって非特許文献２のSubclause 5.2.1に記述されるＩＢＳＳ（Independent Basic Service Set）が形成される。アソシエーション確立後の手順（ステップS205，S206，S207）は、従来の接続開始手順のうちアプリケーション一致判断を除いたもの（ステップS103，S104，S106）と同様である。
【００２５】
他方、使用可能なアプリケーションが一致しないと判断すると（S202：NO）、通信制御部２０はスキャニングを中止する（ステップS203）。以上の構成によれば、ＭＡＣ層での接続中（アソシエーション確立前）にアプリケーション一致の判断がなされるため、アプリケーション一致の判断のために認証、アソシエーション確立、ＩＰアドレスの取得、およびＴＣＰコネクション確立試行が必要な構成と比較して、無線通信端末ＳTA１の処理負荷が低減される。したがって、無線通信端末ＳTA１の消費電力を低減することが可能である。また、アプリケーションが不一致の場合にはＭＡＣ層にて通信が終了することから、他の無線通信端末ＳTA２にてアプリケーションが起動されることも抑制される。したがって、スキャニングされた他の無線通信端末ＳTA２の消費電力もが低減され得る。
【００２６】
なお、以上の例示では、無線通信端末ＳTA１と無線通信端末ＳTA２とで使用可能なアプリケーションが一致するか否かに基づいてアソシエーション確立要否の判断を実行したが、アプリケーションにて使用されるパラメータが一致するか否かに基づいてアソシエーション確立要否の判断を実行してもよい。
【００２７】
＜ＭＡＣフレームの構成＞
無線通信端末ＳTA１と無線通信端末ＳTA２との間で（すなわち、ＩＢＳＳ内で）互いに送受信されるＭＡＣフレームＦのフォーマットについて以下に詳述する。図５は、一般的なＭＡＣフレームＦのフォーマットを示す図である。ＭＡＣフレームＦはＭＡＣ層のＰＤＵ（Protocol Data Unit）であり、ＭＡＣヘッダ部分とフレームボディ部分とＦＣＳ（Frame Check Sequence）部分とを含むビット列である。ＦＣＳ部分にはＭＡＣフレームＦの誤り制御信号が格納される。
【００２８】
ＭＡＣフレームＦのフレームボディ部分（ペイロード）には送信データが格納される。具体的には、ＭＡＣ層（第２層、Ｌ２）の上位層であるＩＰ層（第３層、Ｌ３）のＰＤＵであるＩＰパケットが格納される。ＩＰパケットはヘッダ部分とデータ部分（ペイロード）とを含み、ヘッダ部分は宛先ＩＰアドレスと送信元ＩＰアドレスとを含む。また、ＩＰパケットのデータ部分にはＩＰ層の上位層であるトランスポート層（第４層、Ｌ４）のＰＤＵであるＴＣＰセグメント（又はＵＤＰセグメント。以下同様）が格納される。ＴＣＰセグメントはヘッダ部分とデータ部分（ペイロード）とを含み、ヘッダ部分はプログラム（アプリケーション）を特定するポート番号（宛先ポート番号および送信元ポート番号）とを含む。ＴＣＰセグメントのデータ部分にはトランスポート層の上位層であるアプリケーション層のデータ、すなわち端末間通信で使用されるアプリケーションのデータが格納される。
【００２９】
ＭＡＣヘッダ部分には、ＭＡＣフレームＦの伝送制御に関与するパラメータが格納される。図６は、IEEE 802.11（非特許文献２のSubclause 7.1.2参照）に規定される無線LANのＭＡＣヘッダの基本フォーマットを示す図である。無線LANのＭＡＣヘッダは、フレーム制御、デュレーション／ＩＤ、アドレス１、アドレス２、アドレス３、シーケンス制御、アドレス４、およびＱｏＳ制御の各フィールドを備える。各アドレスフィールド（アドレス１〜アドレス４）には、用途に応じた任意のアドレス（例えば送信元ＭＡＣアドレス）が格納されるように規定される。
【００３０】
無線LANで用いられるＭＡＣフレームＦは、マネジメントフレームＦM（非特許文献２のSubclause 7.2.3参照）、制御フレーム（非特許文献２のSubclause 7.2.1参照）、およびデータフレーム（非特許文献２のSubclause 7.2.2参照）に大別される。このうち、マネジメントフレームＦMは以下のフレームを含む（非特許文献のSubclause 7.1.3.1.2参照）。
・通信相手の発見（スキャニング）に使用されるビーコンフレームＦMB、プローブリクエストフレームＦMQ、およびプローブレスポンスフレームＦMR
・通信相手の認証に使用される認証要求フレームおよび認証応答フレーム
・通信相手とのアソシエーション確立の際に使用されるアソシエーション要求フレームおよびアソシエーション応答フレーム
マネジメントフレームＦMは、ＭＡＣ層レベルでの通信制御において通信制御部２０にて生成され送信部６０から送信される。また、他の無線通信端末ＳTAが送信したマネジメントフレームＦMは、受信部１０で受信され通信制御部２０にて処理される。
【００３１】
図７は、マネジメントフレームＦMのＭＡＣヘッダ部分のフォーマットを示す図である（非特許文献２のSubclause 7.2.3参照）。マネジメントフレームＦMのＭＡＣヘッダ部分は、アドレス１として宛先ＭＡＣアドレスを、アドレス２として送信元ＭＡＣアドレスを、アドレス３としてＢＳＳ（Basic Service Set）ＩＤを含み、アドレス４フィールドおよびＱｏＳ制御フィールドを含まない。
【００３２】
マネジメントフレームＦMは、ＭＡＣ層の無線通信制御のためのパラメータを示す複数の情報要素ＩE（Information Element）をフレームボディ部分に含む。図８は、本発明にて新たに提案されるビーコンフレームＦMBのフレームボディ部分のフォーマットを示す図である。従来のビーコンフレームＦMBは、非特許文献２のSubclause 7.2.3.1に規定されるように複数の情報要素ＩE（Timestamp、QoS Capability、及びその他の要素）を含む。本発明に係るビーコンフレームＦMBは、新たな情報要素ＩEとしてアプリケーション関連情報ＡIをさらに含む。
【００３３】
また、図９は、本発明にて新たに提案されるプローブレスポンスフレームＦMRのフレームボディ部分のフォーマットを示す図である。従来のプローブレスポンスフレームのフォーマットは非特許文献２のSubclause 7.2.3.9に規定される。本発明のプローブレスポンスフレームＦMRは、新たな情報要素ＩEとしてアプリケーション関連情報ＡIを含む。
【００３４】
同様にして、他のマネジメントフレームＦMもフレームボディ部分に新たな情報要素ＩEとしてアプリケーション関連情報ＡIを含む。すなわち、本発明のマネジメントフレームＦMの各々は、既存の情報要素ＩEに加え、新たな情報要素ＩEであるアプリケーション関連情報ＡIを含む。なお、アプリケーション関連情報ＡIが配置される箇所はフレームボディ部分の任意の箇所であり、図８および図９に示された箇所に限定されるものでないことは当然に理解される。
【００３５】
＜アソシエーション確立の要否判断の実施例＞
アプリケーション関連情報ＡIは、無線通信端末ＳTA２が使用可能なアプリケーションに関する任意の情報である。以下、アプリケーション関連情報ＡIの具体的な内容を実施例とともに説明する。
【００３６】
＜実施例１ − ポート番号＞
図１０および図１１に、実施例１におけるアプリケーション特定の様子を示す。実施例１では、ＴＣＰセグメントのポート番号にてアプリケーションが特定される。
【００３７】
無線通信端末ＳTA１の記憶部５０には、無線通信端末ＳTA２が送信するＴＣＰセグメントに示される宛先ポート番号（無線通信端末ＳTA２が使用可能なアプリケーションに対応づけられている）と、無線通信端末ＳTA１が使用可能なアプリケーションとの対応関係を示すテーブル５０１が記憶されている。
【００３８】
一般的に、宛先ポート番号を含むＴＣＰセグメントは上位層に透過的に転送されるためＭＡＣ層の通信制御には関与しないが、本実施例では、無線通信端末ＳTA２が送信するＴＣＰセグメントに含まれる宛先ポート番号がビーコンフレームＦMB内の情報要素ＩEであるアプリケーション関連情報ＡIにも格納され、無線通信端末ＳTA１におけるＭＡＣ層の通信制御（アソシエーション確立を実行すべきか否かの判断）に利用される。具体的には以下の通りである。
【００３９】
無線通信端末ＳTA１がスキャニングを開始する（図４のステップＳ201）。無線通信端末ＳTA２が送信したビーコンフレームＦMBを受信部１０が受信して通信制御部２０に供給する。通信制御部２０は、受信したビーコンフレームＦMBからアプリケーション関連情報ＡIを抽出して判断部４０に供給する。判断部４０は、アプリケーション関連情報ＡIが示すＴＣＰセグメントの宛先ポート番号49153がテーブル５０１に記憶されているか否かを判断する（図１０、ステップＳ202）。テーブル５０１にはゲームＤを示す宛先ポート番号49153が記憶されている（すなわち、アプリケーション関連情報ＡIがテーブル５０１の情報と一致する）ので、判断部４０は、無線通信端末ＳTA２に対するアソシエーションの確立を実行すべきと判断し（ステップＳ202：YES）、通信制御部２０に認証およびアソシエーション確立を指示する（ステップＳ204）。無線通信端末ＳTA２とのアソシエーション確立後、無線通信端末ＳTA１は無線通信端末ＳTA２からＩＰアドレスを取得し、ＴＣＰコネクションを確立してアプリケーション層の通信（すなわち、無線通信端末ＳTA１および無線通信端末ＳTA２が使用可能なゲームＤに関する通信）を実行する（ステップＳ204〜Ｓ208）。
【００４０】
他方、図１１を参照して、ポート番号が一致しない場合を考える。通信制御部２０は、受信したビーコンフレームＦMBからアプリケーション関連情報ＡI（宛先ポート番号49155）を抽出して判断部４０に供給する。判断部４０は、アプリケーション関連情報ＡIが示すＴＣＰセグメントの宛先ポート番号49155がテーブル５０１に記憶されているか否かを判断する（ステップＳ202）。テーブル５０１には宛先ポート番号49155が記憶されていない（すなわち、アプリケーション関連情報ＡIがテーブル５０１の情報と一致しない）ので、判断部４０は、無線通信端末ＳTA２に対するアソシエーションの確立を中止すべきと判断し（ステップＳ202：NO）、通信制御部２０にスキャニングの中止を指示する（ステップＳ204）。
【００４１】
以上の実施例では、無線通信端末ＳTA２のＴＣＰセグメントに含まれる宛先ポート番号がアプリケーション関連情報ＡIにも格納されたが、無線通信端末ＳTA２が使用可能なアプリケーションと対応づけられた送信元ポート番号がアプリケーション関連情報ＡIに格納されてもよい。その場合、無線通信端末ＳTA１のテーブル５０１は、送信元ポート番号と無線通信端末ＳTA１が使用可能なアプリケーションの対応とを対応づけるものとなることは当然に理解される。
【００４２】
以上のようにして、無線通信端末ＳTA２のＴＣＰセグメントに含まれるポート番号がＭＡＣ層の通信制御に活用される。無線通信端末ＳTA１は、アソシエーションの確立前に無線通信端末ＳTA２にて使用可能なアプリケーションを特定することが可能であるから、アプリケーションが一致しない場合にはスキャニングを中止することで、後続するアソシエーションの確立、ＩＰアドレスの取得、およびＴＣＰコネクションの確立といった接続処理を実行しなくて済む。これらの接続処理は、接続確立を要求する側だけでなく接続確立が要求される側においても実行されるから、以上の構成によれば、無線通信端末ＳTA１および無線通信端末ＳTA２の消費電力が削減される。
【００４３】
＜実施例２ − ＩＰアドレス＞
図１２を参照して、アプリケーションにて使用されるパラメータを、ＩＰアドレスを用いて特定する様子を説明する。無線通信端末ＳTA１の記憶部５０には、無線通信端末ＳTA２が送信するＩＰパケットに含まれる宛先ＩＰアドレス（無線通信端末ＳTA２のアプリケーションにて使用されるパラメータに対応）と、無線通信端末ＳTA１のアプリケーションにて使用されるパラメータとの対応関係を示すテーブル５０２が記憶されている。本実施例においては、使用されるアプリケーションはロールプレイングゲームであり、ＩＰアドレスにて特定されるパラメータは無線通信端末ＳTAのユーザが操作するキャラクターの所在位置である場合が想定される。パラメータが一致する（すなわち、各ユーザが操作するキャラクターの所在位置が無線通信端末ＳTA１と無線通信端末ＳTA２とで一致する）場合にのみ端末間通信が実行され、アプリケーション内にて必要な情報が交換される（例えば、無線通信端末ＳTA１で実行されるゲーム内に無線通信端末ＳTA２のユーザに対応するキャラクターが登場する）ことが想定され得る。
【００４４】
一般的に、宛先ＩＰアドレスを含むＩＰパケットは上位層に透過的に転送されるためＭＡＣ層の通信制御には関与しないが、本実施例では、ＩＰパケットに含まれる宛先ＩＰアドレスがビーコンフレームＦMB内の情報要素ＩEであるアプリケーション関連情報ＡIに格納され、ＭＡＣ層の通信制御（アソシエーション確立を実行すべきか否かの判断）に利用される。一般的なクライアント−サーバ型の通信においては、ＩＰアドレスはＩＰ層（多数のノードを含む１つのＩＰアドレス空間）における一意な論理的位置を示すので自由に設定することは困難であるが、本発明の端末間通信のようなアドホック通信においては、１つのＩＰアドレス空間（例えば、１つのＩＢＳＳ）内には相互に無線通信を行う少数（例えば２台）の無線通信端末ＳTAが存在するに過ぎないので、ＩＰアドレスを比較的自由に設定することが可能である。そのため、本実施例では、アプリケーションで使用されるパラメータを特定する値としてＩＰアドレスを用いる。具体的には以下の通りである。
【００４５】
無線通信端末ＳTA１がスキャニングを開始する（ステップＳ201）。無線通信端末ＳTA２が送信したビーコンフレームＦMBを受信部１０が受信して通信制御部２０に供給する。通信制御部２０は、受信したビーコンフレームＦMBからアプリケーション関連情報ＡI(宛先ＩＰアドレス192.168.1.5)を抽出して判断部４０に供給する。判断部４０は、アプリケーション関連情報ＡIが示すＩＰパケットの宛先ＩＰアドレス192.168.1.5が、テーブル５０２に記憶されているか否かを判断する（図１２、ステップＳ202）。テーブル５０２には宛先ＩＰアドレス192.168.1.5が記憶されていない（すなわち、アプリケーション関連情報ＡIがテーブル５０２の情報と一致しない）ので、判断部４０は、無線通信端末ＳTA２に対するアソシエーションの確立を中止すべきと判断し（ステップＳ202：NO）、通信制御部２０にスキャニングの中止を指示する（ステップＳ204）。
【００４６】
以上の実施例では、無線通信端末ＳTA２のＩＰパケットに含まれる宛先ＩＰアドレスがアプリケーション関連情報ＡIに格納されたが、無線通信端末ＳTA２のアプリケーションにて使用されるパラメータと対応づけられた送信元ＩＰアドレスがアプリケーション関連情報ＡIに格納されてもよい。その場合、無線通信端末ＳTA１のテーブル５０２は、送信元ＩＰアドレスと無線通信端末ＳTA１のアプリケーションにて使用されるパラメータとを対応づけるものとなることは当然に理解される。
【００４７】
ＩＰアドレスが、無線通信端末ＳTA２が使用可能なアプリケーションと、そのアプリケーションにて使用されるパラメータとの双方を特定してもよい。例えば、宛先ＩＰアドレスの上位２４ビット（実施例２では192.168.1）がアプリケーションを特定し、宛先ＩＰアドレスの下位８ビットがパラメータを特定してもよい。また、実施例１と組み合わせて、ＴＣＰセグメントのポート番号がアプリケーションを特定し、ＩＰアドレスがパラメータを特定する構成も採用され得る。
【００４８】
以上のように、無線通信端末ＳTA２のＩＰパケットが含むＩＰアドレスが無線通信端末ＳTA１におけるＭＡＣ層の通信制御に利用される。ＩＰアドレスが一致しない場合にはスキャニングを中止するので、後続するアソシエーションの確立、ＩＰアドレスの取得、およびＴＣＰコネクションの確立といった接続処理の実行が省略される。したがって、無線通信端末ＳTA１および無線通信端末ＳTA２の消費電力が削減される。
【００４９】
＜実施例３ − ユーザ識別子＞
図１３を参照して、アプリケーション関連情報ＡIとしてマネジメントフレームＦM（ビーコンフレームＦMB）に格納されたユーザ識別子を用いて無線通信端末ＳTA１と無線通信端末ＳTA２とのアソシエーション確立要否を判断する様子を示す。
【００５０】
本実施例では、無線通信端末ＳTA１のユーザがゲームＤに関するＳＮＳ（Social Networking Service）に加入しており、そのＳＮＳ内のメンバーのうち特定のユーザのみとゲームＤに関する端末間通信を実行することを前提とする。無線通信端末ＳTA１の記憶部５０には、無線通信端末ＳTA２が送信するユーザ識別子と、無線通信端末ＳTA１のユーザが端末間通信を希望するユーザの名前との対応関係を示すテーブル５０３が記憶されている。テーブル５０３は、無線通信端末ＳTA１のユーザがＳＮＳのウェブサイトから事前にダウンロードしたデータによって構成されることが可能である。
【００５１】
アソシエーション確立要否の判断は以下のように実行される。無線通信端末ＳTA１がスキャニングを開始する（ステップＳ201）。無線通信端末ＳTA２が送信したビーコンフレームＦMBを、受信部１０が受信して通信制御部２０に供給する。通信制御部２０は、受信したビーコンフレームＦMBからアプリケーション関連情報ＡI(ユーザ識別子31045)を抽出して判断部４０に供給する。判断部４０は、ユーザ識別子31045がテーブル５０３に記憶されているか否かを判断する（図１３、ステップＳ202）。テーブル５０３にはユーザ識別子31045が記憶されていない（すなわち、アプリケーション関連情報ＡIがテーブル５０１の情報と一致しない）ので、判断部４０は、無線通信端末ＳTA２に対するアソシエーションの確立を中止すべきと判断し（ステップＳ202：NO）、通信制御部２０にスキャニングの中止を指示する（ステップＳ204）。
【００５２】
以上のように、無線通信端末ＳTA２のユーザ識別子がＭＡＣ層の通信制御に活用される。スキャニングにより発見された無線通信端末ＳTA２のユーザが端末間通信を希望するユーザではない場合にはスキャニングを中止するので、後続するアソシエーションの確立、ＩＰアドレスの取得、およびＴＣＰコネクションの確立といった接続処理の実行が省略される。したがって、無線通信端末ＳTA１および無線通信端末ＳTA２の消費電力が削減される。
【００５３】
＜変形例＞
以上の実施の形態は多様に変形される。具体的な変形の態様を以下に例示する。以下の例示から任意に選択された２以上の態様は相互に矛盾しない限り適宜に併合され得る。
【００５４】
（１）変形例１
以上の各形態においては、Passive Scanning方式でのビーコンフレームＦMBが含むアプリケーション関連情報ＡIに基づいてアプリケーション（又はパラメータ）の一致を判断したが、Active Scanning方式でのプローブリクエストフレームＦMQ又はプローブレスポンスフレームＦMRが含むアプリケーション関連情報ＡIに基づいてアプリケーション（又はパラメータ）の一致を判断してもよい。
【００５５】
（２）変形例２
以上の各形態においては、スキャニング中にアプリケーション（又はパラメータ）の一致を判断したが、認証中またはアソシエーションの確立過程においてアプリケーション（又はパラメータ）の一致を判断してもよい。認証中に一致を判断する場合には、マネジメントフレームＦMである認証要求フレームまたは認証応答フレームが含むアプリケーション関連情報ＡIを使用して一致の判断をすればよい。また、アソシエーションの確立過程において一致を判断する場合には、マネジメントフレームＦMであるアソシエーション要求フレームまたはアソシエーション応答フレームが含むアプリケーション関連情報ＡIを使用して一致の判断をすればよい。
【００５６】
（３）変形例３
以上の各形態においては、アプリケーションを特定する情報として、アプリケーションに関連づけられたポート番号およびＩＰアドレスを例示し、アプリケーションにて使用されるパラメータを特定する情報として、パラメータに関連づけられたＩＰアドレスおよびユーザ識別子を例示したが、任意の情報がアプリケーション又はパラメータを特定する情報として用いられ得る。例えば、アプリケーション又はパラメータと関連づけられた情報がＩＰヘッダ又はＴＣＰヘッダのオプションフィールドに格納され、その情報がアプリケーション関連情報ＡIとしてマネジメントフレームＦMのデータ部分に格納される構成が採用され得る。すなわち、アプリケーション関連情報ＡIに格納されるのは、そのアプリケーション関連情報ＡIを送信する無線通信端末ＳTAのアプリケーション又はアプリケーションにて使用されるパラメータを特定し得る任意の情報である。
【００５７】
（４）変形例４
マネジメントフレームＦMのアプリケーション関連情報ＡIに格納されるポート番号又はＩＰアドレスは、そのマネジメントフレームＦM内にカプセル化されたＴＣＰセグメントに含まれるポート番号又はそのマネジメントフレームＦM内にカプセル化されたＩＰパケットに含まれるＩＰアドレスに限定されない。例えば、スキャニングを実行する無線通信端末ＳTA１に送信すべきポート番号又はＩＰアドレスを無線通信端末ＳTA２の記憶部５０に予め記憶しておき、マネジメントフレームＦMのアプリケーション関連情報ＡIに格納してもよい。送信すべきポート番号又はＩＰアドレスとは、例えば無線通信端末ＳTA２がスリープ状態に移行した際に起動されていたアプリケーションを示すポート番号又はスリープ状態に移行した際のパラメータ（例えば、ゲーム内の所在位置）を示すＩＰアドレスである。
【００５８】
（５）変形例５
マネジメントフレームＦMのアプリケーション関連情報ＡIに格納されるユーザ識別子として、無線通信端末ＳTAのユーザの電子署名に関する情報を用いてもよい。例えば、無線通信端末ＳTAのユーザの公開鍵データの全部または一部をアプリケーション関連情報ＡIに格納してユーザ識別に用いてもよい。具体的には、端末間通信を実行した際に通信相手となったユーザの公開鍵データ（マネジメントフレームＦMに格納されている）を記憶部５０に記憶しておき、次回以降の端末間通信において、過去に端末間通信をしたことのあるユーザであるか否かを識別してもよい。
【００５９】
（６）変形例６
マネジメントフレームＦMのアプリケーション関連情報ＡIが、無線通信端末ＳTA２が無線通信端末ＳTA１と無線通信を開始すべき時刻を含んでもよい。例えば、無線通信端末ＳTA１と無線通信端末ＳTA２とで使用されるアプリケーションが一定期間（例えば５分）内での獲得点数を争うゲームＧである場合において、再度の無線通信を行って獲得点数情報を交換すべき時刻をアプリケーション関連情報ＡIが示してもよい。以上の場合、再度の無線通信を実施すべき時刻が既知となることにより円滑に無線通信を再開することが可能となる。なお、無線通信を開始すべき時刻とは、絶対時刻であってもよいし、マネジメントフレームＦMの受信時からの相対時刻であってもよい。
【００６０】
（７）変形例７
マネジメントフレームＦMのアプリケーション関連情報ＡIアプリケーション関連情報ＡIが、無線通信端末ＳTA１と無線通信端末ＳTA２とが無線通信すべき通信間隔の情報を含んでもよい。例えば、変形例６のゲームＧにおいて、ゲームの途中においても無線通信を定期的に実施して獲得点数を定期的（例えば１分おき）に交換する場合、無線通信を実施すべき間隔をアプリケーション関連情報ＡIが示してもよい。以上の場合、無線通信を実施すべき通信間隔が既知となることにより間欠的な無線通信が円滑に実行され得る。
【００６１】
（８）変形例８
マネジメントフレームＦMのアプリケーション関連情報ＡIが、無線通信端末ＳTA２と無線通信端末ＳTA１との間で発生する無線通信データ量に関する情報を含んでもよい。例えば、楽音情報等の大容量データを送受信することが必要なアプリケーションが無線通信端末ＳTA１と無線通信端末ＳTA２とに使用される場合において、他の無線通信端末ＳTA２と自機（無線通信端末ＳTA１）との間で発生する通信データ量をアプリケーション関連情報ＡIが示してもよい。以上の場合、通信データ量を事前に知ることができるので、大容量データの送受信による消費電力の増大を避けることが可能である。なお、通信データ量とは、そのアプリケーションを用いた一度の無線通信において発生する最大のデータ量でもよく、平均データ量でもよい。また、そのアプリケーションを用いた場合に発生する単位時間当たりのデータ量でもよい。
【００６２】
（９）変形例９
無線通信端末において、ＣＰＵが実行する各機能は、ＣＰＵの代わりに、ハードウェアで実行してもよいし、例えばＦＰＧＡ（Field Programmable Gate Array）、ＤＳＰ（Digital Signal Processor）等のプログラマブルロジックデバイスで実行してもよい。
【００６３】
（１０）変形例１０
前記の実施の形態は、IEEE 802.11に準拠しているが、本発明は、IEEE 802.15.1に準拠したブルートゥース（登録商標）による通信もカバーする。
【００６４】
（１１）変形例１１
前述の実施の形態は、無線通信端末ＳTA１と無線通信端末ＳTA２との直接的な端末間通信を行う構成であったが、無線通信端末ＳTA１と無線通信端末ＳTA２との間にアクセスポイントが介在する端末間通信についても適用可能である。
【００６５】
（１２）変形例１２
前述の実施の形態は、無線通信端末ＳTA１と無線通信端末ＳTA２との直接的な端末間通信を行う構成であったが、無線通信端末ＳTA１とアクセスポイントとの間の通信についても適用可能である。例えば、アクセスポイントが特定のアプリケーションとの無線通信のみを許可する場合に、アクセスポイントに許可されるアプリケーションを特定する情報（例えば、ポート番号）をマネジメントフレームＦMに格納してアクセスポイントから送信することにより、そのアプリケーションを有さない無線通信端末ＳTA１がそのアクセスポイントにアソシエーションを確立しようとすることを抑制できる。したがって、無線通信端末ＳTA１の消費電力が低減される。
【００６６】
前記の実施の形態および変形は、矛盾しない限り、組み合わせてもよい。
【符号の説明】
【００６７】
ＡI……アプリケーション関連情報、Ｆ……フレーム、ＦM……マネジメントフレーム、ＦMB……ビーコンフレーム、ＦMQ……プローブリクエストフレーム、ＦMR……プローブレスポンスフレーム、ＩE……情報要素、ＲA……無線通信可能圏、ＳTA１，ＳTA２……無線通信端末。１０……受信部、２０……通信制御部、３０……アプリケーション通信部、４０……判断部、５０……記憶部、６０……送信部。
【技術分野】
【０００１】
本発明は、無線通信端末に関する。
【背景技術】
【０００２】
近年、スマートフォンに代表される多機能携帯電話が普及している。今後、多機能携帯電話の販売量はさらに大きく伸びるものと予測されている。一般的に、多機能携帯電話は近接無線通信用のインターフェース（無線LANまたはブルートゥース（登録商標）を利用した通信インターフェース）を有しており、多機能携帯電話の魅力の一因となっている。
【０００３】
携帯電話以外の携帯型機器においても、無線LANまたはブルートゥースを利用した通信が可能となりつつある。例えば、非特許文献１に開示されているように、任天堂株式会社のゲーム機器で実行可能なすれ違い通信（StreetPass Communication）では、互いに接近している移動可能なゲーム機器同士で通信が可能である。すなわち、基地局を介さずに端末間での直接的な通信が可能である。以下、端末間での直接的な通信を「端末間通信」と呼ぶ。すれ違い通信には、IEEE 802.11（非特許文献２）が使用される。
【０００４】
図１を参照して、従来技術における端末間通信の接続開始手順を説明する。無線通信端末は、無線通信可能な他の装置（無線通信端末、アクセスポイント又はその他の装置）を発見するためのスキャニングを実行する（ステップS101）。スキャニングにより他の装置を発見した無線通信端末は、他の装置との間で認証（authentication）およびアソシエーション確立を実行する（ステップS102）。アソシエーションの確立後、無線通信端末は、DHCP（Dynamic Host Configuration Protocol）により他の装置からIPアドレスを取得し（ステップS103）、他の装置との間にTCPコネクションを確立するためにSYNセグメントを送信する（ステップS104）。SYNセグメントを受信した他の装置は、無線通信端末にSYN/ACKセグメントを送信する。無線通信装置は、受信したSYN/ACKセグメントが示すポート番号に基づいて他の装置が使用するアプリケーションを特定し、特定されたアプリケーションと無線通信端末自身が使用するアプリケーションとが一致するか否かを判定する（ステップS105）。アプリケーションが一致した場合には（ステップS105：YES）、受信したSYN/ACKセグメントに対してACKセグメントを送信してTCPコネクションを確立し（ステップS106）、アプリケーション層での通信を開始する（ステップS107）。他方、アプリケーションが一致しなかった場合には（ステップS105：NO）、SYN/ACKセグメントに対してFINセグメント（またはRSTセグメント）を送信し、TCPコネクションを確立せずに接続を終了する（ステップS108）。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】andriasang.com、"Nintendo Brings New Services to 3DS"、[online]、[平成２３年３月１７日検索]、インターネット（ＵＲＬ：http://www.andriasang.com/e/blog/2010/09/30/3ds_services/）
【非特許文献２】IEEE Computer Society、"IEEE Std 802.11.TM-2007"、IEEE Standard for Information technology、Telecommunications and information exchange between systems、Local and metropolitan area networks、Specific requirements、Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications、２００７年６月１２日
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ＴＣＰコネクション確立試行の段階で他の装置が使用するアプリケーションを特定する従来の技術では、アプリケーションが一致しないためアプリケーション層での通信が不可能な場合であっても、他の装置との間でＭＡＣ層からトランスポート層までの接続処理が発生する。そのため、無線通信端末の消費電力が過大となる。以上の課題は、移動中にすれ違う他の多数の無線通信端末の各々に対して端末間通信を試行する無線通信端末において特に顕著となる。
【０００７】
本発明は、上記の課題に鑑みてなされたもので、他の装置が使用するアプリケーションに関する情報を適切に受信して消費電力を低減することが可能な無線通信端末を提供するものである。
【課題を解決するための手段】
【０００８】
本発明に係る無線通信端末は、移動可能であり、他の無線通信装置との間にＭＡＣ層レベルのアソシエーションを確立するＭＡＣ層制御部と、前記アソシエーションの確立前または確立過程において、前記他の無線通信装置が使用可能なアプリケーションに関する第１情報を示す情報要素を含んだＭＡＣフレームを前記他の無線通信装置から受信する受信部と、自機が使用可能なアプリケーションに関する第２情報を記憶する記憶部と、前記第１情報と前記第２情報とが一致した場合には前記アソシエーションの確立を実行し、前記第１情報と前記第２情報とが一致しない場合には前記アソシエーションの確立を中止する判断部とを備える。
本明細書において、「（第１情報と第２情報との）一致」とは、第１情報が示す内容と第２情報が示す内容とが完全に同一であることのみを意味するものではなく、例えば、第１情報と第２情報との少なくともいずれか一方が複数の内容を含む場合、第１情報に含まれる特定の内容と第２情報に含まれる特定の内容とが同一であること、すなわち第１情報と第２情報とが部分的に一致することをも包括する概念である。
【０００９】
以上の構成によれば、ＭＡＣ層レベルのアソシエーションの確立前または確立過程においてアプリケーションに関する情報の一致が判断されるため、一致判断のために認証、アソシエーション確立以降の接続処理が必要な構成と比較して、無線通信端末の処理負荷が低減される。したがって、無線通信端末の消費電力を低減することが可能である。また、アプリケーションに関する情報が不一致の場合にはアソシエーションの確立前または確立過程において通信が終了することから、他の無線通信装置にてアプリケーションが起動されることも抑制される。したがって、他の無線通信装置の消費電力もが低減され得る。
【００１０】
本発明の好適な態様において、前記ＭＡＣフレームは、通信相手の発見、通信相手の認証、または通信相手とのアソシエーションのために送信されるマネジメントフレームのいずれかである。
以上の構成によれば、アソシエーションの確立前または確立過程において用いられるマネジメントフレームがアプリケーションに関する情報（第１情報）を有するから、新たな型のフレームを設けることなく上述した一致の判断を実現することが可能となる。
【００１１】
本発明の好適な態様において、前記第１情報は、前記アプリケーションを特定する情報を含む。また、より好適な態様において、前記アプリケーションを特定する情報は、前記アプリケーションに対応づけられたポート番号またはＩＰアドレスである。
以上の構成によれば、アソシエーションの確立が完了しなくても、他の無線通信装置が使用可能なアプリケーションを特定することが可能となる。
【００１２】
本発明の好適な態様において、前記第１情報は、前記アプリケーションにて使用されるパラメータを特定する情報を含む。また、より好適な態様において、前記パラメータを特定する情報は、前記パラメータに対応づけられたポート番号またはＩＰアドレスである。
以上の構成によれば、アソシエーションの確立が完了しなくても、他の無線通信装置のアプリケーションにて使用されるパラメータを特定することが可能となる。
【００１３】
本発明の好適な態様において、前記パラメータを特定する情報は、前記他の無線通信装置のユーザが前記アプリケーションにて使用するユーザ識別子である。前記ユーザ識別子は、前記他の無線通信装置のユーザの電子署名に関する情報でもよい。
以上の構成によれば、アソシエーションの確立が完了しなくても、他の無線通信装置のユーザが希望する通信相手であるか否かを判断することができる。
【００１４】
本発明の好適な態様において、前記第１情報は、前記アプリケーションを使用する前記他の無線通信装置が、前記無線通信端末と無線通信を開始すべき時刻を含む。
以上の構成によれば、アソシエーションの確立が完了しなくても、他の無線通信装置が無線通信を開始すべき時刻を把握可能である。したがって、無線通信の再開がより円滑に行われる。
【００１５】
本発明の好適な態様において、前記第１情報は、前記アプリケーションを使用する前記他の無線通信装置が、前記無線通信端末との無線通信を実行する通信間隔を含む。
以上の構成によれば、アソシエーションの確立が完了しなくても、他の無線通信装置との通信間隔を把握可能である。したがって、間欠的な無線通信がより円滑に行われる。
【００１６】
本発明の好適な態様において、前記第１情報は、前記アプリケーションを使用する前記他の無線通信装置と前記無線通信端末との間で発生する通信データ量に関する情報を含む。
以上の構成によれば、アソシエーションの確立が完了しなくても、他の無線通信装置との間で発生する通信データ量を把握可能である。したがって、大容量データの送受信による消費電力の増大を避けることが可能である。
【図面の簡単な説明】
【００１７】
【図１】従来の端末間通信の接続開始手順を示すフローチャートである。
【図２】本発明の実施の形態に係る無線通信端末の構成を示すブロック図である。
【図３】端末間通信可能な２つの無線通信端末が接近している状態を示す概略図である。
【図４】本発明の端末間通信の接続開始手順を示すフローチャートである。
【図５】一般的なＭＡＣフレームのフォーマットを示す図である。
【図６】IEEE 802.11に規定されるＭＡＣヘッダの基本フォーマットを示す図である。
【図７】マネジメントフレームＦMのＭＡＣヘッダ部分のフォーマットを示す図である。
【図８】ビーコンフレームＦMBのフレームボディ部分のフォーマットを示す図である。
【図９】プローブレスポンスフレームＦMRのフレームボディ部分のフォーマットを示す図である。
【図１０】実施例１のアプリケーション特定の様子を示す図である。
【図１１】実施例１のアプリケーション特定の様子を示す図である。
【図１２】実施例２のパラメータ特定の様子を示す図である。
【図１３】実施例３のユーザ識別子の一致判定の様子を示す図である。
【発明を実施するための形態】
【００１８】
以下、添付の図面を参照しながら本発明に係る様々な実施の形態を説明する。
【００１９】
＜無線通信端末の構成＞
図２は、本発明の実施の形態に係る無線通信端末ＳTAの構成を示すブロック図である。無線通信端末ＳTAは、受信部１０と、通信制御部２０と、アプリケーション通信部３０と、判断部４０と、記憶部５０と、送信部６０とを備える。受信部１０は無線受信を行うための受信回路であり、送信部６０は無線送信を行うための送信回路である。受信部１０および送信部６０はIEEE 802.11bに準拠した無線インターフェースを含む。通信制御部２０、アプリケーション通信部３０、および判断部４０は、図示しないＣＰＵ（Central Processing Unit）がコンピュータプログラムを実行し、そのコンピュータプログラムに従って機能することによって実現される機能ブロックである。記憶部５０は、自機が使用可能なアプリケーションに関する情報を書換え可能に記憶する記憶媒体（例えばEEPROM（Electrically Erasable and Programmable ROM））である。
【００２０】
アプリケーション通信部３０は、端末間通信にて実行されるアプリケーション間通信を実行する機能を有する。すなわち、端末間通信を実行する際、アプリケーション通信部３０は端末間通信時に使用されるアプリケーションに従ってデータ信号を生成して通信制御部２０に供給する。通信制御部２０は、アプリケーション通信部３０から供給されたデータ信号をＴＣＰセグメント→ＩＰパケット→ＭＡＣフレームＦの順に変換して送信部６０に供給する。送信部６０はＭＡＣフレームＦを無線通信信号に変換して送信する。一方、受信部１０は他の無線通信端末ＳTAが送信した無線通信信号を受信してＭＡＣフレームＦに変換して通信制御部２０に供給する。通信制御部２０は、供給された無線通信信号をＭＡＣフレームＦ→ＩＰパケット→ＴＣＰセグメントの順に変換した後、ＴＣＰセグメントからデータ信号を生成してアプリケーション通信部３０に供給する。
【００２１】
また、通信制御部２０はＭＡＣ層制御部としても機能する。通信制御部２０は、自機（無線通信端末ＳTA１）に接近した他の無線通信端末ＳTA２との間でマネジメントフレームＦM（後述）を互いに送受信して、ＭＡＣ層レベルのアソシエーションを確立する機能を有する。すなわち、通信制御部２０は、ＭＡＣ層の機能を実行するＭＬＭＥ（MAC sublayer management entity）である。
【００２２】
＜アソシエーション確立要否判断の概略＞
図３は、端末間通信が可能な２つの無線通信端末ＳTA１，ＳTA２が接近している状態を示す。無線通信端末ＳTA１，ＳTA２の一方または両方が移動しており、無線通信端末ＳTA１の無線通信可能圏ＲA１に無線通信端末ＳTA２があり、無線通信端末ＳTA２の無線通信可能圏ＲA２に無線通信端末ＳTA１がある。すなわち、無線通信端末ＳTA１と無線通信端末ＳTA２とは相互に無線通信可能な位置に存在する。
【００２３】
図４を参照して、本発明の端末間通信の接続開始手順を説明する。無線通信端末ＳTA１は、無線通信可能な他の装置を発見するためのスキャニングを実行する（ステップS201）。スキャニングの具体的な方式としては、非特許文献２のSubclause 11.1.3に規定されるように、無線通信端末ＳTA１がプローブリクエストフレームＦMQを送信し、そのプローブリクエストフレームＦMQを受信した他の無線通信端末ＳTA２が返信するプローブレスポンスフレームＦMRを受信して端末の発見を行うActive Scanning方式と、他の無線通信端末ＳTAが随時に送信するビーコンフレームＦMBを受信して端末の発見を行うPassive Scanning方式とが存在するが、両方式とも端末間通信が可能な他の無線通信端末ＳTAが送信するマネジメントフレームＦMを受信してスキャニングを実行する点については共通である。以下では、ビーコンフレームＦMBを使用するPassive Scanning方式を例示して説明するが、本発明の構成としてActive Scanning方式も採用可能なことは当然に理解される。
【００２４】
無線通信端末ＳTA１の近傍には無線通信端末ＳTA２が存在するので、無線通信端末ＳTA２が送信するビーコンフレームＦMBが無線通信端末ＳTA１の受信部１０に受信される。スキャニングの過程で無線通信端末ＳTA２を発見した無線通信端末ＳTA１は、ビーコンフレームＦMBに含まれる無線通信端末ＳTA２が使用可能なアプリケーションに関する情報と、記憶部５０に記憶された無線通信端末ＳTA１が使用可能なアプリケーションに関する情報とが一致するか否かを判断する（詳細は後述される）。アプリケーションが一致すると判断すると（S202：YES）、通信制御部２０は無線通信端末ＳTA２との間で認証およびアソシエーション確立を実行する（ステップS204）。アソシエーションが確立されると、無線通信端末ＳTA１および無線通信端末ＳTA２によって非特許文献２のSubclause 5.2.1に記述されるＩＢＳＳ（Independent Basic Service Set）が形成される。アソシエーション確立後の手順（ステップS205，S206，S207）は、従来の接続開始手順のうちアプリケーション一致判断を除いたもの（ステップS103，S104，S106）と同様である。
【００２５】
他方、使用可能なアプリケーションが一致しないと判断すると（S202：NO）、通信制御部２０はスキャニングを中止する（ステップS203）。以上の構成によれば、ＭＡＣ層での接続中（アソシエーション確立前）にアプリケーション一致の判断がなされるため、アプリケーション一致の判断のために認証、アソシエーション確立、ＩＰアドレスの取得、およびＴＣＰコネクション確立試行が必要な構成と比較して、無線通信端末ＳTA１の処理負荷が低減される。したがって、無線通信端末ＳTA１の消費電力を低減することが可能である。また、アプリケーションが不一致の場合にはＭＡＣ層にて通信が終了することから、他の無線通信端末ＳTA２にてアプリケーションが起動されることも抑制される。したがって、スキャニングされた他の無線通信端末ＳTA２の消費電力もが低減され得る。
【００２６】
なお、以上の例示では、無線通信端末ＳTA１と無線通信端末ＳTA２とで使用可能なアプリケーションが一致するか否かに基づいてアソシエーション確立要否の判断を実行したが、アプリケーションにて使用されるパラメータが一致するか否かに基づいてアソシエーション確立要否の判断を実行してもよい。
【００２７】
＜ＭＡＣフレームの構成＞
無線通信端末ＳTA１と無線通信端末ＳTA２との間で（すなわち、ＩＢＳＳ内で）互いに送受信されるＭＡＣフレームＦのフォーマットについて以下に詳述する。図５は、一般的なＭＡＣフレームＦのフォーマットを示す図である。ＭＡＣフレームＦはＭＡＣ層のＰＤＵ（Protocol Data Unit）であり、ＭＡＣヘッダ部分とフレームボディ部分とＦＣＳ（Frame Check Sequence）部分とを含むビット列である。ＦＣＳ部分にはＭＡＣフレームＦの誤り制御信号が格納される。
【００２８】
ＭＡＣフレームＦのフレームボディ部分（ペイロード）には送信データが格納される。具体的には、ＭＡＣ層（第２層、Ｌ２）の上位層であるＩＰ層（第３層、Ｌ３）のＰＤＵであるＩＰパケットが格納される。ＩＰパケットはヘッダ部分とデータ部分（ペイロード）とを含み、ヘッダ部分は宛先ＩＰアドレスと送信元ＩＰアドレスとを含む。また、ＩＰパケットのデータ部分にはＩＰ層の上位層であるトランスポート層（第４層、Ｌ４）のＰＤＵであるＴＣＰセグメント（又はＵＤＰセグメント。以下同様）が格納される。ＴＣＰセグメントはヘッダ部分とデータ部分（ペイロード）とを含み、ヘッダ部分はプログラム（アプリケーション）を特定するポート番号（宛先ポート番号および送信元ポート番号）とを含む。ＴＣＰセグメントのデータ部分にはトランスポート層の上位層であるアプリケーション層のデータ、すなわち端末間通信で使用されるアプリケーションのデータが格納される。
【００２９】
ＭＡＣヘッダ部分には、ＭＡＣフレームＦの伝送制御に関与するパラメータが格納される。図６は、IEEE 802.11（非特許文献２のSubclause 7.1.2参照）に規定される無線LANのＭＡＣヘッダの基本フォーマットを示す図である。無線LANのＭＡＣヘッダは、フレーム制御、デュレーション／ＩＤ、アドレス１、アドレス２、アドレス３、シーケンス制御、アドレス４、およびＱｏＳ制御の各フィールドを備える。各アドレスフィールド（アドレス１〜アドレス４）には、用途に応じた任意のアドレス（例えば送信元ＭＡＣアドレス）が格納されるように規定される。
【００３０】
無線LANで用いられるＭＡＣフレームＦは、マネジメントフレームＦM（非特許文献２のSubclause 7.2.3参照）、制御フレーム（非特許文献２のSubclause 7.2.1参照）、およびデータフレーム（非特許文献２のSubclause 7.2.2参照）に大別される。このうち、マネジメントフレームＦMは以下のフレームを含む（非特許文献のSubclause 7.1.3.1.2参照）。
・通信相手の発見（スキャニング）に使用されるビーコンフレームＦMB、プローブリクエストフレームＦMQ、およびプローブレスポンスフレームＦMR
・通信相手の認証に使用される認証要求フレームおよび認証応答フレーム
・通信相手とのアソシエーション確立の際に使用されるアソシエーション要求フレームおよびアソシエーション応答フレーム
マネジメントフレームＦMは、ＭＡＣ層レベルでの通信制御において通信制御部２０にて生成され送信部６０から送信される。また、他の無線通信端末ＳTAが送信したマネジメントフレームＦMは、受信部１０で受信され通信制御部２０にて処理される。
【００３１】
図７は、マネジメントフレームＦMのＭＡＣヘッダ部分のフォーマットを示す図である（非特許文献２のSubclause 7.2.3参照）。マネジメントフレームＦMのＭＡＣヘッダ部分は、アドレス１として宛先ＭＡＣアドレスを、アドレス２として送信元ＭＡＣアドレスを、アドレス３としてＢＳＳ（Basic Service Set）ＩＤを含み、アドレス４フィールドおよびＱｏＳ制御フィールドを含まない。
【００３２】
マネジメントフレームＦMは、ＭＡＣ層の無線通信制御のためのパラメータを示す複数の情報要素ＩE（Information Element）をフレームボディ部分に含む。図８は、本発明にて新たに提案されるビーコンフレームＦMBのフレームボディ部分のフォーマットを示す図である。従来のビーコンフレームＦMBは、非特許文献２のSubclause 7.2.3.1に規定されるように複数の情報要素ＩE（Timestamp、QoS Capability、及びその他の要素）を含む。本発明に係るビーコンフレームＦMBは、新たな情報要素ＩEとしてアプリケーション関連情報ＡIをさらに含む。
【００３３】
また、図９は、本発明にて新たに提案されるプローブレスポンスフレームＦMRのフレームボディ部分のフォーマットを示す図である。従来のプローブレスポンスフレームのフォーマットは非特許文献２のSubclause 7.2.3.9に規定される。本発明のプローブレスポンスフレームＦMRは、新たな情報要素ＩEとしてアプリケーション関連情報ＡIを含む。
【００３４】
同様にして、他のマネジメントフレームＦMもフレームボディ部分に新たな情報要素ＩEとしてアプリケーション関連情報ＡIを含む。すなわち、本発明のマネジメントフレームＦMの各々は、既存の情報要素ＩEに加え、新たな情報要素ＩEであるアプリケーション関連情報ＡIを含む。なお、アプリケーション関連情報ＡIが配置される箇所はフレームボディ部分の任意の箇所であり、図８および図９に示された箇所に限定されるものでないことは当然に理解される。
【００３５】
＜アソシエーション確立の要否判断の実施例＞
アプリケーション関連情報ＡIは、無線通信端末ＳTA２が使用可能なアプリケーションに関する任意の情報である。以下、アプリケーション関連情報ＡIの具体的な内容を実施例とともに説明する。
【００３６】
＜実施例１ − ポート番号＞
図１０および図１１に、実施例１におけるアプリケーション特定の様子を示す。実施例１では、ＴＣＰセグメントのポート番号にてアプリケーションが特定される。
【００３７】
無線通信端末ＳTA１の記憶部５０には、無線通信端末ＳTA２が送信するＴＣＰセグメントに示される宛先ポート番号（無線通信端末ＳTA２が使用可能なアプリケーションに対応づけられている）と、無線通信端末ＳTA１が使用可能なアプリケーションとの対応関係を示すテーブル５０１が記憶されている。
【００３８】
一般的に、宛先ポート番号を含むＴＣＰセグメントは上位層に透過的に転送されるためＭＡＣ層の通信制御には関与しないが、本実施例では、無線通信端末ＳTA２が送信するＴＣＰセグメントに含まれる宛先ポート番号がビーコンフレームＦMB内の情報要素ＩEであるアプリケーション関連情報ＡIにも格納され、無線通信端末ＳTA１におけるＭＡＣ層の通信制御（アソシエーション確立を実行すべきか否かの判断）に利用される。具体的には以下の通りである。
【００３９】
無線通信端末ＳTA１がスキャニングを開始する（図４のステップＳ201）。無線通信端末ＳTA２が送信したビーコンフレームＦMBを受信部１０が受信して通信制御部２０に供給する。通信制御部２０は、受信したビーコンフレームＦMBからアプリケーション関連情報ＡIを抽出して判断部４０に供給する。判断部４０は、アプリケーション関連情報ＡIが示すＴＣＰセグメントの宛先ポート番号49153がテーブル５０１に記憶されているか否かを判断する（図１０、ステップＳ202）。テーブル５０１にはゲームＤを示す宛先ポート番号49153が記憶されている（すなわち、アプリケーション関連情報ＡIがテーブル５０１の情報と一致する）ので、判断部４０は、無線通信端末ＳTA２に対するアソシエーションの確立を実行すべきと判断し（ステップＳ202：YES）、通信制御部２０に認証およびアソシエーション確立を指示する（ステップＳ204）。無線通信端末ＳTA２とのアソシエーション確立後、無線通信端末ＳTA１は無線通信端末ＳTA２からＩＰアドレスを取得し、ＴＣＰコネクションを確立してアプリケーション層の通信（すなわち、無線通信端末ＳTA１および無線通信端末ＳTA２が使用可能なゲームＤに関する通信）を実行する（ステップＳ204〜Ｓ208）。
【００４０】
他方、図１１を参照して、ポート番号が一致しない場合を考える。通信制御部２０は、受信したビーコンフレームＦMBからアプリケーション関連情報ＡI（宛先ポート番号49155）を抽出して判断部４０に供給する。判断部４０は、アプリケーション関連情報ＡIが示すＴＣＰセグメントの宛先ポート番号49155がテーブル５０１に記憶されているか否かを判断する（ステップＳ202）。テーブル５０１には宛先ポート番号49155が記憶されていない（すなわち、アプリケーション関連情報ＡIがテーブル５０１の情報と一致しない）ので、判断部４０は、無線通信端末ＳTA２に対するアソシエーションの確立を中止すべきと判断し（ステップＳ202：NO）、通信制御部２０にスキャニングの中止を指示する（ステップＳ204）。
【００４１】
以上の実施例では、無線通信端末ＳTA２のＴＣＰセグメントに含まれる宛先ポート番号がアプリケーション関連情報ＡIにも格納されたが、無線通信端末ＳTA２が使用可能なアプリケーションと対応づけられた送信元ポート番号がアプリケーション関連情報ＡIに格納されてもよい。その場合、無線通信端末ＳTA１のテーブル５０１は、送信元ポート番号と無線通信端末ＳTA１が使用可能なアプリケーションの対応とを対応づけるものとなることは当然に理解される。
【００４２】
以上のようにして、無線通信端末ＳTA２のＴＣＰセグメントに含まれるポート番号がＭＡＣ層の通信制御に活用される。無線通信端末ＳTA１は、アソシエーションの確立前に無線通信端末ＳTA２にて使用可能なアプリケーションを特定することが可能であるから、アプリケーションが一致しない場合にはスキャニングを中止することで、後続するアソシエーションの確立、ＩＰアドレスの取得、およびＴＣＰコネクションの確立といった接続処理を実行しなくて済む。これらの接続処理は、接続確立を要求する側だけでなく接続確立が要求される側においても実行されるから、以上の構成によれば、無線通信端末ＳTA１および無線通信端末ＳTA２の消費電力が削減される。
【００４３】
＜実施例２ − ＩＰアドレス＞
図１２を参照して、アプリケーションにて使用されるパラメータを、ＩＰアドレスを用いて特定する様子を説明する。無線通信端末ＳTA１の記憶部５０には、無線通信端末ＳTA２が送信するＩＰパケットに含まれる宛先ＩＰアドレス（無線通信端末ＳTA２のアプリケーションにて使用されるパラメータに対応）と、無線通信端末ＳTA１のアプリケーションにて使用されるパラメータとの対応関係を示すテーブル５０２が記憶されている。本実施例においては、使用されるアプリケーションはロールプレイングゲームであり、ＩＰアドレスにて特定されるパラメータは無線通信端末ＳTAのユーザが操作するキャラクターの所在位置である場合が想定される。パラメータが一致する（すなわち、各ユーザが操作するキャラクターの所在位置が無線通信端末ＳTA１と無線通信端末ＳTA２とで一致する）場合にのみ端末間通信が実行され、アプリケーション内にて必要な情報が交換される（例えば、無線通信端末ＳTA１で実行されるゲーム内に無線通信端末ＳTA２のユーザに対応するキャラクターが登場する）ことが想定され得る。
【００４４】
一般的に、宛先ＩＰアドレスを含むＩＰパケットは上位層に透過的に転送されるためＭＡＣ層の通信制御には関与しないが、本実施例では、ＩＰパケットに含まれる宛先ＩＰアドレスがビーコンフレームＦMB内の情報要素ＩEであるアプリケーション関連情報ＡIに格納され、ＭＡＣ層の通信制御（アソシエーション確立を実行すべきか否かの判断）に利用される。一般的なクライアント−サーバ型の通信においては、ＩＰアドレスはＩＰ層（多数のノードを含む１つのＩＰアドレス空間）における一意な論理的位置を示すので自由に設定することは困難であるが、本発明の端末間通信のようなアドホック通信においては、１つのＩＰアドレス空間（例えば、１つのＩＢＳＳ）内には相互に無線通信を行う少数（例えば２台）の無線通信端末ＳTAが存在するに過ぎないので、ＩＰアドレスを比較的自由に設定することが可能である。そのため、本実施例では、アプリケーションで使用されるパラメータを特定する値としてＩＰアドレスを用いる。具体的には以下の通りである。
【００４５】
無線通信端末ＳTA１がスキャニングを開始する（ステップＳ201）。無線通信端末ＳTA２が送信したビーコンフレームＦMBを受信部１０が受信して通信制御部２０に供給する。通信制御部２０は、受信したビーコンフレームＦMBからアプリケーション関連情報ＡI(宛先ＩＰアドレス192.168.1.5)を抽出して判断部４０に供給する。判断部４０は、アプリケーション関連情報ＡIが示すＩＰパケットの宛先ＩＰアドレス192.168.1.5が、テーブル５０２に記憶されているか否かを判断する（図１２、ステップＳ202）。テーブル５０２には宛先ＩＰアドレス192.168.1.5が記憶されていない（すなわち、アプリケーション関連情報ＡIがテーブル５０２の情報と一致しない）ので、判断部４０は、無線通信端末ＳTA２に対するアソシエーションの確立を中止すべきと判断し（ステップＳ202：NO）、通信制御部２０にスキャニングの中止を指示する（ステップＳ204）。
【００４６】
以上の実施例では、無線通信端末ＳTA２のＩＰパケットに含まれる宛先ＩＰアドレスがアプリケーション関連情報ＡIに格納されたが、無線通信端末ＳTA２のアプリケーションにて使用されるパラメータと対応づけられた送信元ＩＰアドレスがアプリケーション関連情報ＡIに格納されてもよい。その場合、無線通信端末ＳTA１のテーブル５０２は、送信元ＩＰアドレスと無線通信端末ＳTA１のアプリケーションにて使用されるパラメータとを対応づけるものとなることは当然に理解される。
【００４７】
ＩＰアドレスが、無線通信端末ＳTA２が使用可能なアプリケーションと、そのアプリケーションにて使用されるパラメータとの双方を特定してもよい。例えば、宛先ＩＰアドレスの上位２４ビット（実施例２では192.168.1）がアプリケーションを特定し、宛先ＩＰアドレスの下位８ビットがパラメータを特定してもよい。また、実施例１と組み合わせて、ＴＣＰセグメントのポート番号がアプリケーションを特定し、ＩＰアドレスがパラメータを特定する構成も採用され得る。
【００４８】
以上のように、無線通信端末ＳTA２のＩＰパケットが含むＩＰアドレスが無線通信端末ＳTA１におけるＭＡＣ層の通信制御に利用される。ＩＰアドレスが一致しない場合にはスキャニングを中止するので、後続するアソシエーションの確立、ＩＰアドレスの取得、およびＴＣＰコネクションの確立といった接続処理の実行が省略される。したがって、無線通信端末ＳTA１および無線通信端末ＳTA２の消費電力が削減される。
【００４９】
＜実施例３ − ユーザ識別子＞
図１３を参照して、アプリケーション関連情報ＡIとしてマネジメントフレームＦM（ビーコンフレームＦMB）に格納されたユーザ識別子を用いて無線通信端末ＳTA１と無線通信端末ＳTA２とのアソシエーション確立要否を判断する様子を示す。
【００５０】
本実施例では、無線通信端末ＳTA１のユーザがゲームＤに関するＳＮＳ（Social Networking Service）に加入しており、そのＳＮＳ内のメンバーのうち特定のユーザのみとゲームＤに関する端末間通信を実行することを前提とする。無線通信端末ＳTA１の記憶部５０には、無線通信端末ＳTA２が送信するユーザ識別子と、無線通信端末ＳTA１のユーザが端末間通信を希望するユーザの名前との対応関係を示すテーブル５０３が記憶されている。テーブル５０３は、無線通信端末ＳTA１のユーザがＳＮＳのウェブサイトから事前にダウンロードしたデータによって構成されることが可能である。
【００５１】
アソシエーション確立要否の判断は以下のように実行される。無線通信端末ＳTA１がスキャニングを開始する（ステップＳ201）。無線通信端末ＳTA２が送信したビーコンフレームＦMBを、受信部１０が受信して通信制御部２０に供給する。通信制御部２０は、受信したビーコンフレームＦMBからアプリケーション関連情報ＡI(ユーザ識別子31045)を抽出して判断部４０に供給する。判断部４０は、ユーザ識別子31045がテーブル５０３に記憶されているか否かを判断する（図１３、ステップＳ202）。テーブル５０３にはユーザ識別子31045が記憶されていない（すなわち、アプリケーション関連情報ＡIがテーブル５０１の情報と一致しない）ので、判断部４０は、無線通信端末ＳTA２に対するアソシエーションの確立を中止すべきと判断し（ステップＳ202：NO）、通信制御部２０にスキャニングの中止を指示する（ステップＳ204）。
【００５２】
以上のように、無線通信端末ＳTA２のユーザ識別子がＭＡＣ層の通信制御に活用される。スキャニングにより発見された無線通信端末ＳTA２のユーザが端末間通信を希望するユーザではない場合にはスキャニングを中止するので、後続するアソシエーションの確立、ＩＰアドレスの取得、およびＴＣＰコネクションの確立といった接続処理の実行が省略される。したがって、無線通信端末ＳTA１および無線通信端末ＳTA２の消費電力が削減される。
【００５３】
＜変形例＞
以上の実施の形態は多様に変形される。具体的な変形の態様を以下に例示する。以下の例示から任意に選択された２以上の態様は相互に矛盾しない限り適宜に併合され得る。
【００５４】
（１）変形例１
以上の各形態においては、Passive Scanning方式でのビーコンフレームＦMBが含むアプリケーション関連情報ＡIに基づいてアプリケーション（又はパラメータ）の一致を判断したが、Active Scanning方式でのプローブリクエストフレームＦMQ又はプローブレスポンスフレームＦMRが含むアプリケーション関連情報ＡIに基づいてアプリケーション（又はパラメータ）の一致を判断してもよい。
【００５５】
（２）変形例２
以上の各形態においては、スキャニング中にアプリケーション（又はパラメータ）の一致を判断したが、認証中またはアソシエーションの確立過程においてアプリケーション（又はパラメータ）の一致を判断してもよい。認証中に一致を判断する場合には、マネジメントフレームＦMである認証要求フレームまたは認証応答フレームが含むアプリケーション関連情報ＡIを使用して一致の判断をすればよい。また、アソシエーションの確立過程において一致を判断する場合には、マネジメントフレームＦMであるアソシエーション要求フレームまたはアソシエーション応答フレームが含むアプリケーション関連情報ＡIを使用して一致の判断をすればよい。
【００５６】
（３）変形例３
以上の各形態においては、アプリケーションを特定する情報として、アプリケーションに関連づけられたポート番号およびＩＰアドレスを例示し、アプリケーションにて使用されるパラメータを特定する情報として、パラメータに関連づけられたＩＰアドレスおよびユーザ識別子を例示したが、任意の情報がアプリケーション又はパラメータを特定する情報として用いられ得る。例えば、アプリケーション又はパラメータと関連づけられた情報がＩＰヘッダ又はＴＣＰヘッダのオプションフィールドに格納され、その情報がアプリケーション関連情報ＡIとしてマネジメントフレームＦMのデータ部分に格納される構成が採用され得る。すなわち、アプリケーション関連情報ＡIに格納されるのは、そのアプリケーション関連情報ＡIを送信する無線通信端末ＳTAのアプリケーション又はアプリケーションにて使用されるパラメータを特定し得る任意の情報である。
【００５７】
（４）変形例４
マネジメントフレームＦMのアプリケーション関連情報ＡIに格納されるポート番号又はＩＰアドレスは、そのマネジメントフレームＦM内にカプセル化されたＴＣＰセグメントに含まれるポート番号又はそのマネジメントフレームＦM内にカプセル化されたＩＰパケットに含まれるＩＰアドレスに限定されない。例えば、スキャニングを実行する無線通信端末ＳTA１に送信すべきポート番号又はＩＰアドレスを無線通信端末ＳTA２の記憶部５０に予め記憶しておき、マネジメントフレームＦMのアプリケーション関連情報ＡIに格納してもよい。送信すべきポート番号又はＩＰアドレスとは、例えば無線通信端末ＳTA２がスリープ状態に移行した際に起動されていたアプリケーションを示すポート番号又はスリープ状態に移行した際のパラメータ（例えば、ゲーム内の所在位置）を示すＩＰアドレスである。
【００５８】
（５）変形例５
マネジメントフレームＦMのアプリケーション関連情報ＡIに格納されるユーザ識別子として、無線通信端末ＳTAのユーザの電子署名に関する情報を用いてもよい。例えば、無線通信端末ＳTAのユーザの公開鍵データの全部または一部をアプリケーション関連情報ＡIに格納してユーザ識別に用いてもよい。具体的には、端末間通信を実行した際に通信相手となったユーザの公開鍵データ（マネジメントフレームＦMに格納されている）を記憶部５０に記憶しておき、次回以降の端末間通信において、過去に端末間通信をしたことのあるユーザであるか否かを識別してもよい。
【００５９】
（６）変形例６
マネジメントフレームＦMのアプリケーション関連情報ＡIが、無線通信端末ＳTA２が無線通信端末ＳTA１と無線通信を開始すべき時刻を含んでもよい。例えば、無線通信端末ＳTA１と無線通信端末ＳTA２とで使用されるアプリケーションが一定期間（例えば５分）内での獲得点数を争うゲームＧである場合において、再度の無線通信を行って獲得点数情報を交換すべき時刻をアプリケーション関連情報ＡIが示してもよい。以上の場合、再度の無線通信を実施すべき時刻が既知となることにより円滑に無線通信を再開することが可能となる。なお、無線通信を開始すべき時刻とは、絶対時刻であってもよいし、マネジメントフレームＦMの受信時からの相対時刻であってもよい。
【００６０】
（７）変形例７
マネジメントフレームＦMのアプリケーション関連情報ＡIアプリケーション関連情報ＡIが、無線通信端末ＳTA１と無線通信端末ＳTA２とが無線通信すべき通信間隔の情報を含んでもよい。例えば、変形例６のゲームＧにおいて、ゲームの途中においても無線通信を定期的に実施して獲得点数を定期的（例えば１分おき）に交換する場合、無線通信を実施すべき間隔をアプリケーション関連情報ＡIが示してもよい。以上の場合、無線通信を実施すべき通信間隔が既知となることにより間欠的な無線通信が円滑に実行され得る。
【００６１】
（８）変形例８
マネジメントフレームＦMのアプリケーション関連情報ＡIが、無線通信端末ＳTA２と無線通信端末ＳTA１との間で発生する無線通信データ量に関する情報を含んでもよい。例えば、楽音情報等の大容量データを送受信することが必要なアプリケーションが無線通信端末ＳTA１と無線通信端末ＳTA２とに使用される場合において、他の無線通信端末ＳTA２と自機（無線通信端末ＳTA１）との間で発生する通信データ量をアプリケーション関連情報ＡIが示してもよい。以上の場合、通信データ量を事前に知ることができるので、大容量データの送受信による消費電力の増大を避けることが可能である。なお、通信データ量とは、そのアプリケーションを用いた一度の無線通信において発生する最大のデータ量でもよく、平均データ量でもよい。また、そのアプリケーションを用いた場合に発生する単位時間当たりのデータ量でもよい。
【００６２】
（９）変形例９
無線通信端末において、ＣＰＵが実行する各機能は、ＣＰＵの代わりに、ハードウェアで実行してもよいし、例えばＦＰＧＡ（Field Programmable Gate Array）、ＤＳＰ（Digital Signal Processor）等のプログラマブルロジックデバイスで実行してもよい。
【００６３】
（１０）変形例１０
前記の実施の形態は、IEEE 802.11に準拠しているが、本発明は、IEEE 802.15.1に準拠したブルートゥース（登録商標）による通信もカバーする。
【００６４】
（１１）変形例１１
前述の実施の形態は、無線通信端末ＳTA１と無線通信端末ＳTA２との直接的な端末間通信を行う構成であったが、無線通信端末ＳTA１と無線通信端末ＳTA２との間にアクセスポイントが介在する端末間通信についても適用可能である。
【００６５】
（１２）変形例１２
前述の実施の形態は、無線通信端末ＳTA１と無線通信端末ＳTA２との直接的な端末間通信を行う構成であったが、無線通信端末ＳTA１とアクセスポイントとの間の通信についても適用可能である。例えば、アクセスポイントが特定のアプリケーションとの無線通信のみを許可する場合に、アクセスポイントに許可されるアプリケーションを特定する情報（例えば、ポート番号）をマネジメントフレームＦMに格納してアクセスポイントから送信することにより、そのアプリケーションを有さない無線通信端末ＳTA１がそのアクセスポイントにアソシエーションを確立しようとすることを抑制できる。したがって、無線通信端末ＳTA１の消費電力が低減される。
【００６６】
前記の実施の形態および変形は、矛盾しない限り、組み合わせてもよい。
【符号の説明】
【００６７】
ＡI……アプリケーション関連情報、Ｆ……フレーム、ＦM……マネジメントフレーム、ＦMB……ビーコンフレーム、ＦMQ……プローブリクエストフレーム、ＦMR……プローブレスポンスフレーム、ＩE……情報要素、ＲA……無線通信可能圏、ＳTA１，ＳTA２……無線通信端末。１０……受信部、２０……通信制御部、３０……アプリケーション通信部、４０……判断部、５０……記憶部、６０……送信部。
【特許請求の範囲】
【請求項１】
他の無線通信装置との間にＭＡＣ層レベルのアソシエーションを確立するＭＡＣ層制御部と、
前記アソシエーションの確立前または確立過程において、前記他の無線通信装置が使用可能なアプリケーションに関する第１情報を示す情報要素を含んだＭＡＣフレームを前記他の無線通信装置から受信する受信部と、
自機が使用可能なアプリケーションに関する第２情報を記憶する記憶部と、
前記第１情報と前記第２情報とが一致した場合には前記アソシエーションの確立を実行し、前記第１情報と前記第２情報とが一致しない場合には前記アソシエーションの確立を中止する判断部とを備える
移動可能な無線通信端末。
【請求項２】
前記ＭＡＣフレームは、通信相手の発見、通信相手の認証、または通信相手とのアソシエーションのために送信されるマネジメントフレームのいずれかである
請求項１に記載の無線通信端末。
【請求項３】
前記第１情報は、前記アプリケーションを特定する情報を含む
請求項１または２に記載の無線通信端末。
【請求項４】
前記アプリケーションを特定する情報は、前記アプリケーションに対応づけられたポート番号またはＩＰアドレスである
請求項３に記載の無線通信端末。
【請求項５】
前記第１情報は、前記アプリケーションにて使用されるパラメータを特定する情報を含む
請求項１から４のいずれか１項に記載の無線通信端末。
【請求項６】
前記パラメータを特定する情報は、前記パラメータに対応づけられたポート番号またはＩＰアドレスである
請求項５に記載の無線通信端末。
【請求項７】
前記パラメータを特定する情報は、前記他の無線通信装置のユーザが前記アプリケーションにて使用するユーザ識別子である
請求項５に記載の無線通信端末。
【請求項８】
前記第１情報は、前記アプリケーションを使用する前記他の無線通信装置が、前記無線通信端末と無線通信を開始すべき時刻を含む
請求項１から７のいずれか１項に記載の無線通信端末。
【請求項９】
前記第１情報は、前記アプリケーションを使用する前記他の無線通信装置が、前記無線通信端末との無線通信を実行する通信間隔を含む
請求項１から８のいずれか１項に記載の無線通信端末。
【請求項１０】
前記第１情報は、前記アプリケーションを使用する前記他の無線通信装置と前記無線通信端末との間で発生する通信データ量に関する情報を含む
請求項１から９のいずれか１項に記載の無線通信端末。
【請求項１】
他の無線通信装置との間にＭＡＣ層レベルのアソシエーションを確立するＭＡＣ層制御部と、
前記アソシエーションの確立前または確立過程において、前記他の無線通信装置が使用可能なアプリケーションに関する第１情報を示す情報要素を含んだＭＡＣフレームを前記他の無線通信装置から受信する受信部と、
自機が使用可能なアプリケーションに関する第２情報を記憶する記憶部と、
前記第１情報と前記第２情報とが一致した場合には前記アソシエーションの確立を実行し、前記第１情報と前記第２情報とが一致しない場合には前記アソシエーションの確立を中止する判断部とを備える
移動可能な無線通信端末。
【請求項２】
前記ＭＡＣフレームは、通信相手の発見、通信相手の認証、または通信相手とのアソシエーションのために送信されるマネジメントフレームのいずれかである
請求項１に記載の無線通信端末。
【請求項３】
前記第１情報は、前記アプリケーションを特定する情報を含む
請求項１または２に記載の無線通信端末。
【請求項４】
前記アプリケーションを特定する情報は、前記アプリケーションに対応づけられたポート番号またはＩＰアドレスである
請求項３に記載の無線通信端末。
【請求項５】
前記第１情報は、前記アプリケーションにて使用されるパラメータを特定する情報を含む
請求項１から４のいずれか１項に記載の無線通信端末。
【請求項６】
前記パラメータを特定する情報は、前記パラメータに対応づけられたポート番号またはＩＰアドレスである
請求項５に記載の無線通信端末。
【請求項７】
前記パラメータを特定する情報は、前記他の無線通信装置のユーザが前記アプリケーションにて使用するユーザ識別子である
請求項５に記載の無線通信端末。
【請求項８】
前記第１情報は、前記アプリケーションを使用する前記他の無線通信装置が、前記無線通信端末と無線通信を開始すべき時刻を含む
請求項１から７のいずれか１項に記載の無線通信端末。
【請求項９】
前記第１情報は、前記アプリケーションを使用する前記他の無線通信装置が、前記無線通信端末との無線通信を実行する通信間隔を含む
請求項１から８のいずれか１項に記載の無線通信端末。
【請求項１０】
前記第１情報は、前記アプリケーションを使用する前記他の無線通信装置と前記無線通信端末との間で発生する通信データ量に関する情報を含む
請求項１から９のいずれか１項に記載の無線通信端末。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１２−２２７６４８（Ｐ２０１２−２２７６４８Ａ）
【公開日】平成２４年１１月１５日（２０１２．１１．１５）
【国際特許分類】
【出願番号】特願２０１１−９２０５７（Ｐ２０１１−９２０５７）
【出願日】平成２３年４月１８日（２０１１．４．１８）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
【公開日】平成２４年１１月１５日（２０１２．１１．１５）
【国際特許分類】
【出願日】平成２３年４月１８日（２０１１．４．１８）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
[ Back to top ]