JP2009021941A - 情報通信端末、無線通信装置および無線通信ネットワーク - Google Patents

Abstract

【課題】送信されたデータについては、選択的に誤り訂正なしで受信する。
【解決手段】送信側端末ＳＴＡ１は、データと誤り訂正情報とを格納したフレームを受信側端末ＳＴＡ２に送信する。端末ＳＴＡ２は、このフレームを受信する毎に、予め設定された訂正可否を指すデータに基づき、データを誤り訂正情報を用いて誤り訂正を行うか否か検知する。誤り訂正を行なわないと検知したときは、誤り訂正を省略して、受信したフレーム中のデータをホストシステム１００２に出力する。
【選択図】図１６

Description

この発明は情報通信端末、無線通信装置および無線通信ネットワークに関し、特に、用途に応じた態様で通信を行なうことができる情報通信端末、無線通信装置および無線通信ネットワークに関する。

近年、複数の情報通信端末において、基地局（アクセス・ポイント）を使用しない無線通信が普及しつつある。なお、このような無線通信のできる端末のみで構成されるネットワークは、アドホックネットワーク（ad hoc network）と呼ばれる。

アドホック・ネットワークにおける通信が可能な端末に関する技術は、種々開示されており、たとえば、特許文献１には、フレームごとにＦＣＳ（Frame Check Sequence）という冗長コードを付与し、受信機は、それを照合することによってフレームごとのエラーチェックを行なっている。
特開平３−２６７８４４号公報

しかしながら、多少のデータ壊れがあっても、再生可能な非圧縮Ａ／Ｖデータ（Audio
／Visual data）などを、エラーチェックなしで相手側端末に送信したいという要求があ
る場合においても、従来のＬＡＮ（Local Area Network）経由では、ＦＣＳエラーチェック（ＦＣＳが指す冗長コードを照合することによってフレームごとのエラーチェックを行なうこと）がフレーム単位で常に行なわれているために、データ壊れが発生したエラーフレームは受信側では廃棄される。その結果、当該フレームに格納されたＡ／Ｖデータは受信されないので、受信側では、データの欠落が起こり、送信データがAudioデータであれ
ば、受信側では再生する音声が途切れるなどの不都合があった。

これを、図４６を参照して説明する。この図４６では、アドホックネットワークにおいてＦＣＳエラーチェックを行なう従来の通信シーケンスが模式的に示される。図においては、送信側端末はホストシステムと通信回路からなり、受信側端末も同様に通信回路とホストシステムからなる。さらに、各端末においてはホストシステムと通信回路が相互に通信する。

図を参照して、まず、送信側端末においてはホストシステムから入力された第１データ送信要求は、通信回路を介して第１フレームとしてネットワークに送信される。

受信側端末においては通信回路は第１フレームを受信すると、ＦＣＳチェックを行なう。その結果、エラーなし（ＯＫ）と判定した場合には、受信した第１データをホストシステムに出力するとともに、ＡＣＫのフレームを生成してネットワークに送信する。

続いて、送信側端末からは第２データを格納した第２フレームが受信側端末へ送信される。

受信側端末においては、通信回路はこの第２フレームを受信すると、第２フレームのデータについてＦＣＳエラーチェックがなされて、データ壊れがあると判定された場合には（ＮＧ）、受信側端末の通信回路により当該第２フレームは廃棄されてしまう。そのためん、受信側端末のホストシステム（再生装置）においては当該第２フレームに格納された
データを得ることはできず、当該データを再生することはできない。その結果、ホストシステムでは再生データの欠落（音の途切れ）が生じる。受信側端末の通信回路はデータを廃棄したので（正常受信できなかったので）ＡＣＫのフレームを生成しない。

その後、送信側端末では、受信側端末からＡＣＫが所定期間待機しても受信されないことに応じて、再度、第２フレームを送信する。受信側端末では、再送信された第２フレームを受信し、ＦＣＳエラーチェックを行なった結果、エラーなし（ＯＫ）と判定されると、第２フレームのデータは、通信回路からホストシステム側に与えられる。ホストシステムでは、受信したデータによる音が再生出力される。以降同様にして受信側端末の通信回路では、受信したフレームごとにＦＣＳエラーチェックが行なわれる。

図４６に従えば、受信側端末のホストシステムでは、第１データを受信（再生）してから、第２データを受信（再生）までの期間は、受信データを得ることができないので、音の欠落が生じ、ユーザはこの期間、再生音が途切れることにより、不快感を感じる。このような不快感の解消は、リアルタイム性（実時間応答）が要求されるようなデータの通信において要求される。

その一方で、受信側端末のホストシステムにおいては、この破壊されたデータ（第２データ）を修復（誤り訂正）機能を有することによって、エラーを訂正して正常なデータに復元する可能性がある。その場合には、出力（再生）音に関して欠落は生じず、ほぼ正常な音を再生することが可能となり、ユーザの視聴に支障を来たすのを回避できる。

したがって、本発明は係る実情に鑑み考え出されたものであり、受信したデータについては、選択的に誤り訂正なしで、受信側端末で受信することが可能な情報通信端末、無線通信装置、および無線通信ネットワークを提供することである。

この発明のある局面に従う情報通信端末は、外部から送信されたフレームを受信する受信部と、誤り訂正を行なう際は、受信部により受信したフレーム中のデータに対してフレーム中の訂正情報に従い誤り訂正した後にデータを出力し、誤り訂正を行なわない際は、受信部により受信したフレーム中のデータに対して誤り訂正を行わずにデータを出力する訂正処理手段と、訂正処理手段に対して誤り訂正を行なわせるか否かを決定する訂正検知手段とを備える。

この発明の他の局面に従うと、無線ネットワークを介して通信する情報通信端末は、他の情報通信端末から送信されたフレームを受信する受信部と、受信部により受信したフレーム中のデータを入力して処理する処理部と、を備える。

受信部は、他の情報通信端末からデータと誤り訂正のための訂正情報とを格納したフレームを受信するデータ受信手段と、データ受信手段が受信したフレーム中のデータを、当該フレーム中の訂正情報に従い誤り訂正した後に、当該データを処理部に出力する訂正処理手段と、データ受信手段がフレームを受信する毎に、予め設定された訂正可否データに基づき誤り訂正を行うか否か検知し、誤り訂正を行なわないと検知したときは、訂正処理手段による誤り訂正を省略して、データ受信手段が受信したフレーム中のデータを処理部に出力する訂正検知手段とを含む。

好ましくは、訂正検知手段は、データ受信手段がフレームを受信する毎に、訂正可否データに基づき誤り訂正を行うか否か検知し、誤り訂正を行なうと検知したときは、当該受信フレームのデータについて訂正処理手段による誤り訂正を行なわせる。

好ましくは、訂正可否データは設定変更可能である。
好ましくは、受信部は、さらに、他の情報通信端末から送信された誤り訂正可否の通知を受信する訂正可否受信手段を含み、訂正可否データは、訂正可否受信手段が予め受信した誤り訂正可否の通知を指す。

好ましくは、データは、非圧縮のオーディオデータまたはビジュアルデータを指す。
この発明の他の局面に従うと、無線ネットワークを介して通信し、且つ処理部を有した情報通信端末に搭載される無線通信装置は、他の情報通信端末から送信されたフレームを受信し、受信したフレーム中のデータを情報通信端末の処理部に出力するする受信部を備える。受信部は、他の情報通信端末からデータと誤り訂正のための訂正情報とを格納したフレームを受信するデータ受信手段と、データ受信手段が受信したフレーム中のデータを、当該フレーム中の訂正情報に従い誤り訂正した後に、当該データを処理部に出力する訂正処理手段と、データ受信手段がフレームを受信する毎に、予め設定された訂正可否データに基づき誤り訂正を行うか否か検知し、誤り訂正を行なわないと検知したときは、訂正処理手段による誤り訂正を省略して、データ受信手段が受信したフレーム中のデータを処理部に出力する訂正検知手段とを含む。

この発明のさらに他の局面に従う、第１の情報通信端末と、第１の情報通信端末によって送信されたデータを受信する第２の情報通信端末とを備える無線通信ネットワークは、以下の特徴を備える。

第１の情報通信端末は、データと誤り訂正のための訂正情報とを格納したフレームを送信するデータ送信手段を含み、第２の情報通信端末は、第１の情報通信端末のデータ送信手段から送信されたフレームを受信する受信部と、受信部により受信したフレーム中のデータを入力して処理する処理部と、を含み、受信部は、第１の情報通信端末のデータ送信手段により送信されたフレームを受信するデータ受信手段と、データ受信手段が受信したフレーム中のデータを、当該フレーム中の訂正情報に従い誤り訂正した後に、当該データを処理部に出力する訂正処理手段と、データ受信手段が前記フレームを受信する毎に、予め設定された訂正可否データに基づき誤り訂正を行うか否か検知し、誤り訂正を行なわないと検知したときは、訂正処理手段による誤り訂正を省略して、データ受信手段が受信したフレーム中のデータを処理部に出力する訂正検知手段とを有する。

好ましくは、ネットワークは、アドホック通信ネットワークである。

本発明によれば、データ受信手段がフレームを受信する毎に、当該フレーム中のデータを、訂正処理手段によって誤り訂正を施した後に、処理部に与えるか否かを、訂正可否データを予め設定しておくことによって、選択的に指定することができる。

したがって、無線通信ネットワークを介して通信されるフレーム中のデータについて、フレームを受信する毎に、選択的に誤り訂正なしで、当該フレーム中のデータを受信することが可能となる。

以下、本発明の無線通信ネットワークの実施の形態について図面を参照して説明する。
［第１の実施の形態］
図１は、本発明の無線通信ネットワークの第１の実施の形態であるアドホック・ネットワークの構成の一例を模式的に示す図である。

まず、図１（Ａ）を参照して、ネットワーク１０には、本発明の情報通信端末の一実施
の形態である端末１〜４が含まれる。ネットワーク１０は、複数の情報通信端末によって構成される、基地局を使用しない無線通信ネットワーク（アドホック・ネットワーク）である。

本実施の形態のネットワーク１０では、互いに異なるＩＢＳＳＩＤ（Independent Basic Service Set IDentification）が利用された、それぞれ独立した複数の無線セルが形成される。具体的には、あるＩＢＳＳＩＤ（図１では一例として「ＢＳＳ♯１」と記述されるものが記載されている）を利用して端末１と端末２の間で通信が行なわれるのと同時に、他のＩＢＳＳＩＤを利用して、端末３と端末４の間での通信が可能となる。図１（Ａ）では、「あるＩＢＳＳＩＤ」が利用されることによって形成される無線セルが無線セル１１として示され、また、「他のＩＢＳＳＩＤ」（図１では一例として「ＢＳＳ♯２」と記述されるものが記載されている）によって形成される無線セルが無線セル１２として示されている。

また、本実施の形態のネットワーク１０では、端末１は、「あるＩＢＳＳＩＤ」（または、別のＩＢＳＳＩＤ）を利用して端末３や端末４との間で通信が可能であり、端末２も、「他のＩＢＳＳＩＤ」（または、さらに別のＩＢＳＳＩＤ）を利用して端末３や端末４との間で通信が可能である。図１（Ｂ）では、「ＢＳＳ♯１」が利用されることによって端末１と端末３の間で形成される無線セルが無線セル１３として示され、また、「ＢＳＳ♯３」（図１ではさらの別のＩＢＳＳＩＤの一例）が利用されることによって端末２と端末４との間で形成される無線セルが無線セル１４として示されている。

図２は、図１の端末１のハードウェア構成を模式的に示す図である。
図２を参照して、端末１は、主にホストシステム１００と通信回路２００から構成される。ホストシステム１００は、当該ホストシステム１００の動作を全体的に制御するＣＰＵ（Central Processing Unit）を含む。また、ホストシステム１００では、種々のアプ
リケーションが実行される。各アプリケーションのプログラムは、ＨＤ（ハードディスク）１０２に格納されている。また、ホストシステム１００は、ＣＰＵ１０１のワークエリアとなるＲＡＭ（Random Access Memory）１０３、情報を表示するディスプレイ１０４、音声を出力するスピーカ１０５、キーやボタンなどの外部からの情報の入力に用いられる入力部１０６、および、通信回路２００との間で情報のやり取りを行なうインターフェイス１０７を含む。

通信回路２００は、ベースバンド／ＭＡＣ（Media Access Control）回路２５０、ＲＦ（Radio Frequency）回路２０５、バラン２０４、アンテナ２０３、ＥＥＰＲＯＭ（Electronically Erasable and Programmable Read Only Memory）２０６，２０７、電源回路２０１、および、クロック回路２０２を含む。

クロック回路２０２は、ベースバンド／ＭＡＣ回路２５０とＲＦ回路２０５にクロック信号を供給する。電源回路２０１は、ベースバンド／ＭＡＣ回路２５０とＲＦ回路２０５に対する電力の供給を制御する。

ＲＦ回路２０５は、アンテナ２０３を介してデータの送受信を行なう。アンテナ２０３とＲＦ回路２０５との間に、バラン２０４が設けられている。

ベースバンド／ＭＡＣ回路２５０は、ＣＰＵ２５１、インターフェイス２５２、外部バスコントローラ２５３、プログラムメモリ２５４、共有メモリ２５５、タイマ２５６、コントロールＭＡＣ部２５７、ＡＤＣ（analog-digital converter）２５８、および、ＤＡＣ（digital-analog converter）２５９を含む。

インターフェイス２５２は、ホストシステム１００に対するインターフェイスである。ＣＰＵ２５１は、ホストシステム１００から、データをネットワークに対して送信する指示を受けると、インターフェイス２５２に、ホストシステム１００内のメモリ（たとえば、ＲＡＭ１０３）に格納された当該データを取出させる。なお、ホストシステム１００は、送信を指示するデータを生成し、当該データを上記メモリに格納した後、当該データの送信指示を通信回路２００へ送信する。また、インターフェイス２５２によって取出されたデータは、ネットワークに対して送信するフレームの「ユーザ・データ・ボディ部」を構成するデータとして、プログラムメモリ２５４に一時的に格納される。

そして、ＣＰＵ２５１は、プログラムメモリ２５４に格納されたデータに対してＭＡＣヘッダとＦＣＳ（Frame Check Sequence）を含む種々のデータを付加することにより、ネットワークに対して送信するフレームを生成し、プログラムメモリ２５４に格納するとともに、共有メモリ２５５において当該フレームを生成した旨のフラグを立てる。ここで、ネットワークに送信されるフレームの一例であるBeaconフレームの構成を、図３を参照して説明する。

図３は、ＩＥＥＥ８０２．１１規格に準拠するフレームの構成を示す図である。
図３を参照して、フレーム３００は、ＭＡＣヘッダ部３１０と、フレーム・ボディ部３２０と、ＦＣＳ部３３０とを含む。

ＭＡＣヘッダ部３１０は、ＤＡ（Destination Address）３１１、ＳＡ（Source Address）３１２およびＩＢＳＳＩＤ３１３を含む。ＤＡ３１１は、フレーム３００の宛先アド
レスである。ＳＡ３１２は、フレーム３００の送信元アドレスである。ＤＡ３１１およびＳＡ３１２は、６バイトのＭＡＣアドレスである。これらのアドレスは、ＥＥＰＲＯＭ２０６に格納されている。また、ＩＢＳＳＩＤ３１３は、アドホック・ネットワークを識別するためのネットワーク識別情報である。本実施の形態では、端末１は、送信するデータ（ホストシステム１００においてアプリケーションから送信の要求がなされたデータ）の属性に応じて、データ送信の際に異なるＩＢＳＳＩＤを利用することができる。具体的には、ＭＡＣヘッダ部３１０を構成するＩＢＳＳＩＤ３１３の値が、送信されるデータの属性に応じて変更される。

フレーム・ボディ部３２０は、ビーコン・フレーム・ボディ部３２１と、ユーザ・データ・ボディ部３２２とを含む。ビーコン・フレーム・ボディ部３２１は、ＳＳＩＤ（Service Set Identifier）を含む。ＳＳＩＤ３２１１は、たとえば、ネットワークの名称を特定する情報とされ、３２バイト以内の文字列として設定される。ユーザ・データ・ボディ部３２２は、通信される実際のデータ（ホストシステム１００で実行されるアプリケーションから送信を要求されたデータ）を含む。ユーザ・データ・ボディ部３２２は、たとえば、１５００バイトのデータを含む。

なお、図３のフレーム３００は、Beaconフレームであるため、フレーム・ボディ部３２０にはビーコン・フレーム・ボディ部等のデータを含むが、フレーム３００が他の用途のフレームである場合には、フレーム・ボディ部３２０に含まれるデータは適宜変更される。

ＦＣＳ部３３０は、フレームの誤り検出に使用される情報（ＦＣＳ）を含む。
図２に戻って、プログラムメモリ２５４に格納された送信用のフレームは、コントロールＭＡＣ部２５７によって、ＤＡＣ２５９へ送られた後、アナログデータに変換されて、ＲＦ回路２０５、バラン２０４、アンテナ２０３を介して、ネットワークへと送信される。

通信回路２００において、ネットワークを介して送信されてきたデータが受信される際の動作について説明する。アンテナ２０３およびバラン２０４を介してＲＦ回路２０５に送られてきたフレームは、ＡＤＣ２５８においてデジタルデータに変換された後、コントロールＭＡＣ部２５７に送られる。コントロールＭＡＣ部２５７は、デジタル信号に変換されたフレームに対して、フレーム先頭検出、時間および周波数の同期処理を行なった後、誤り訂正復号を行なう。そして、コントロールＭＡＣ部２５７は、さらに、当該フレームのＤＡ３１１がＥＥＰＲＯＭ２０６に格納される当該通信回路２００のＭＡＣアドレスと一致するか否かを判断し、一致すると判断すると、フレームからＭＡＣヘッダ部３１０とＦＣＳ部３３０を取除いた後、プログラムメモリ２５４に、残ったデータ（フレーム・ボディ部３２０）を転送する。なお、一致しないと判断すると、コントロールＭＡＣ部２５７は、受信したフレームを破棄する。

また、コントロールＭＡＣ部２５７は、受信したフレーム・ボディ部３２０をプログラムメモリ２５４に格納したときに、共有メモリ２５５において、その旨を示すフラグをセットする。ＣＰＵ２５１は、当該フラグがセットされたことに応じて、プログラムメモリ２５４に格納されたフレーム・ボディ部３２０を、インターフェイス２５２を介して、ホストシステム１００へ送る。

図１の端末２〜４の構成は、図２を用いて説明した端末１の構成と同様とすることができるため、ここでは説明を繰返さない。

次に、本実施の形態のネットワーク１０で行なわれる通信のためにホストシステム１００および通信回路２００で実行される処理の内容について説明する。

図４は、端末１がネットワーク１０に対してデータを送信する際にホストシステム１００のＣＰＵ１０１が実行する処理のフローチャートであり、図５は、通信回路２００のＣＰＵ２５１が実行する処理のフローチャートである。

図４を参照して、ＣＰＵ１０１は、まずステップＳＡ１０で、入力部１０６に対してファイルを送信するための操作がなされたか否かを判断し、そのような操作がなされたと判断すると、ステップＳＡ２０へ処理を進める。

ステップＳＡ２０では、ＣＰＵ１０１は、当該ファイルの送信に利用するＩＢＳＳＩＤを決定して、ステップＳＡ３０へ処理を進める。なお、ステップＳＡ２０におけるＩＢＳＳＩＤの決定の際には、たとえば表１に示されるようなテーブルが利用される。当該テーブルは、たとえばＨＤ１０２に格納される。

表１では、ホストシステム１００から通信回路２００に対してデータの送信要求がなされた際に当該ホストシステム１００において利用されているアプリケーションと、当該データの送信の際に利用されるＩＢＳＳＩＤとが関連付けられて記憶されている。具体的には、「ＡＡ」で特定されるアプリケーションに対しては、「ＢＳＳ♯１」で特定されるＩ
ＢＳＳＩＤが関連付けられており、「ＢＢ」で特定されるアプリケーションに対しては「ＢＳＳ♯２」で特定されるＩＢＳＳＩＤが関連付けられ、そして、「ＣＣ」で特定されるアプリケーションに対しては「ＢＳＳ♯３」で特定されるＩＢＳＳＩＤが関連付けられている。

そして、ステップＳＡ２０では、ＣＰＵ１０１は、ステップＳＡ１０でファイルの送信を指示された際に実行されているアプリケーションに対応するＩＢＳＳＩＤを、ファイルの送信に利用するＩＢＳＳＩＤと決定する。

次に、ステップＳＡ３０では、ＣＰＵ１０１は、通信回路２００に対してBeaconフレームの送信を指示して、ステップＳＡ４０へ処理を進める。なお、ステップＳＡ３０では、ＣＰＵ１０１は、上記指示とともに、ステップＳＡ２０で決定したＩＢＳＳＩＤを特定する情報も通信回路２００へ送る。

ここで、図５を参照して、ホストシステム１００からBeaconフレームを送信する指示がなされると、通信回路２００では、ＣＰＵ２５１が、ステップＳＢ１０からステップＳＢ２０へ処理を進める。

ステップＳＢ２０では、ＣＰＵ２５１は、ステップＳＡ３０（図４参照）の処理により送信されてきたＩＢＳＳＩＤに基づいてBeaconフレームを生成して、ステップＳＢ３０へ処理を進める。具体的には、ステップＳＢ２０では、ＣＰＵ２５１は、図３を参照して説明したようなフレームにおいて、ＩＢＳＳＩＤ３１３としてホストシステム１００から送信されてきたＩＢＳＳＩＤを特定する情報を組込むことにより、Beaconフレームを生成する。

次に、ステップＳＢ３０で、ＣＰＵ２５１は、ステップＳＢ２０で生成したBeaconフレームをアンテナ２０３から送信して、ステップＳＢ４０へ処理を進める。

ステップＳＢ４０では、ＣＰＵ２５１は、ホストシステム１００からファイル送信の指示があるまで待機する。

図４に戻って、ステップＳＡ３０でBeaconフレームの送信を通信回路２００に対して指示した後、ＣＰＵ１０１は、ステップＳＡ４０で、ステップＳＡ１０で操作を受付けたファイルを当該ホストシステム１００内のメモリ（たとえば、ＲＡＭ１０３）に格納するとともに当該ファイルの送信を通信回路２００に指示する情報を送信して、処理を終了する。

図５を参照して、ホストシステム１００からファイルの送信の指示がなされると、ＣＰＵ２５１は、ステップＳＢ４０からステップＳＢ５０へ処理を進める。

ステップＳＢ５０では、ファイル送信用のフレームを生成して、ステップＳＢ６０へ処理を進める。なお、ステップＳＢ５０では、図３を参照して説明したフレームにおいて、ユーザ・データ・ボディ部３２２を構成するデータとして、ホストシステム１００のメモリから取出したファイルのデータを挿入することにより、ファイル送信用パケットを生成する。

ステップＳＢ６０では、ＣＰＵ２５１は、ステップＳＢ５０で生成したフレームを送信して、処理を終了する。

図６は、端末２〜４の中で、図４および図５を参照して説明したような態様で送信され
たフレームを受信する側の端末において通信回路２００のＣＰＵ２５１が実行する処理のフローチャートである。

図６を参照して、ＣＰＵ２５１は、ステップＳＣ１０でBeaconフレームを受信したか否かを判断し、受信したと判断するとステップＳＣ２０へ処理を進める。

ステップＳＣ２０では、ＣＰＵ２５１は、ステップＳＣ１０で受信したと判断したフレームに含まれるＩＢＳＳＩＤを、通信に利用するＩＢＳＳＩＤとして設定して、ステップＳＣ３０へ処理を進める。なお、ここで受信するBeaconフレームとは、ステップＳＡ３０（図４参照）で送信指示がなされ、ステップＳＢ３０（図５参照）で送信されたBeaconフレームである。また、ＩＢＳＳＩＤの設定とは、BeaconフレームからＩＢＳＳＩＤを特定するデータ（図３のＩＢＳＳＩＤ３１３）を抽出し、ＥＥＰＲＯＭ２０６に格納することを意味する。

ステップＳＣ３０では、ＣＰＵ２５１は、ステップＳＣ２０で設定したＩＢＳＳＩＤを含むパケットを受信したか否かを判断し、受信したと判断するとステップＳＣ４０へ処理を進める。

ステップＳＣ４０では、ＣＰＵ２５１は、ＳＣ３０で受信したと判断したパケットユーザ・データ・ボディ部３２２を構成するデータをプログラムメモリ２５４に格納するとともに当該データをホストシステム１００に対して送信して、処理を終了させる。

以上説明した本実施の形態では、ネットワーク１０を構成する複数の端末において、共通する複数のＩＢＳＳＩＤ（例として、ＢＳＳ♯１，ＢＳＳ♯２，ＢＳＳ♯３）が格納されている。そして、当該ネットワーク１０内の端末間でデータの送信が行なわれる際に、送信側の端末で送信するファイルが生成されたアプリケーションの種類に応じて、通信に利用するＩＢＳＳＩＤが特定される。

なお、ファイルの生成に利用されたアプリケーションは、送信されるファイルの属性の一例である。通信に利用するＩＢＳＳＩＤを決定する情報が、送信されるファイルの形式など、他の情報であってもよい。通信に利用されるＩＢＳＳＩＤを決定する際に利用されるデータの属性として、アプリケーションの種類の代わりにファイル形式が利用される場合には、表１の代わりに表２が、ステップＳＡ２０におけるＩＢＳＳＩＤの決定の際に利用される。

表２では、ファイル形式とＩＢＳＳＩＤとが関連付けられて記憶されている。なお、ファイル形式として示された「Ｘ」「Ｙ」「Ｚ」は、それぞれ、たとえばファイルの拡張子とすることができる。

また、表１に示したアプリケーション「ＡＡ」「ＢＢ」「ＣＣ」とは、それぞれ、ファイルなどのデータを高速で転送するためのアプリケーション、ＡＶ（Audio Visual）デー
タなどの大容量のデータをストリーム転送するためのアプリケーション、チャットなどの小容量のデータ転送のためのアプリケーションとすることができる。

また、以上説明した本実施の形態では、表１（または表２）に示されたテーブルはホストシステム１００側に格納され、ＩＢＳＳＩＤの決定は１００側で行なわれていた。なお、このようなＩＢＳＳＩＤの決定は、通信回路２００側で行なわれてもよい。この場合、表１または表２に示したテーブルは、たとえばＥＥＰＲＯＭ２０７に格納され、そして、ＣＰＵ２５１が、通信に利用するＩＢＳＳＩＤを決定する。端末１がこのように構成される場合のＣＰＵ１０１とＣＰＵ２５１のそれぞれの処理内容を図７と図８に示す。

図７を参照して、ＣＰＵ１０１は、入力部１０６からの操作を受付けると、ステップＳＡ３１へ処理を進める。

ステップＳＡ３１では、ＣＰＵ１０１は、通信回路２００に対してBeaconフレームの送信を指示して、ステップＳＡ４１に処理を進める。

なお、ステップＳＡ３１では、ＣＰＵ１０１は、ステップＳＡ１０でファイル送信の操作を受付けたときに、当該ファイル送信に利用されていたアプリケーションを特定する情報も、通信回路２００に対して送信する。

図８を参照して、ステップＳＡ３１でホストシステム１００からBeaconフレームの送信を指示されると、ＣＰＵ２５１は、ステップＳＢ１０からステップＳＢ１１に処理を進める。

ステップＳＢ１１では、ＣＰＵ２５１は、表１を参照することにより、ステップＳＡ３１でＣＰＵ１０１が送信してきたアプリケーションを特定する情報に基づいて、通信で利用するＩＢＳＳＩＤを決定して、ステップＳＢ２０へ処理を進める。

ステップＳＢ２０では、ＣＰＵ２５１は、図５を参照して説明したのと同様に、Beaconフレームを生成する。

図８のステップＳＢ３０の以降の処理は、図５のステップＳＢ３０以降の処理と同様であるため、重複した説明は繰返さない。

なお、以上説明した本実施の形態では、無線通信装置の一実施の形態として通信回路２００を示したが、無線通信装置の実施の形態は、これに限定されない。たとえば、通信回路２００を構成するハードウェアによって実現された機能の一部または全部は、ソフトウェアによって実現されても良い。

また、以上説明された本実施の形態の無線通信ネットワークでは、端末１（端末１〜４）において、ファイルを送信するための操作がなされると、ホストシステム１００または通信回路２００において、ファイルの属性に応じて、ＩＢＳＳＩＤが決定された。

このようなネットワークにおいて、さらに、端末１（端末１〜４）を、送信するファイルの属性に応じて割り込み送信を行なうか否かを決定するように構成することが考えられる。

このような場合、たとえば、ＨＤ１０２には、さらに、表３または表４に示されるような、ファイルの属性と割り込み送信に関する優先順位とを関連付ける情報が格納される。

表３には、ファイルの属性としてアプリケーションの種類が採用された場合の、割り込み送信に関する優先順位との関連性が示されている。また、表４には、ファイルの属性としてファイル形式が採用された場合の、割り込み送信に関する優先順位との関連性が示されている。

このような場合、ホストシステム１００のＣＰＵ１０１は、ステップＳＡ１０（図４参照）においてファイル送信のための操作がなされたと判断した場合、ステップＳＡ２０で、ファイル送信に利用するＩＢＳＳＩＤを決定するとともに、現在他の端末との間で通信動作が行なわれているか否かを判断する。そして、行なわれていると判断した場合、通信動作がどのようなファイルの属性によるものかを判断し、当該属性が、その時点で（直前のステップＳＡ１０において）送信の操作があったファイルの属性よりも表３または表４における優先順位が低いか否かを判断する。そして、低いと判断すると、ＣＰＵ１０１は、その時点で送信の操作がなされたファイルを、実行中の通信動作に対して、割り込み送信する。

つまり、たとえば、割り込み送信に関する優先順位が表３に示されるようにアプリケーションの種類に関連付けられて記憶されている場合、ＣＣまたはＡＡ（表１参照）のアプリケーションに対応したファイルについての通信動作が行なわれているときに、ＢＢ（表１参照）のアプリケーションに対応したファイルを送信する操作がなされると、ＣＰＵ１０１は、当該ＢＢのアプリケーションに対応したファイルを割り込み送信する。具体的には、再度ＩＢＳＳＩＤを決定し直し、当該ＩＢＳＳＩＤを利用したBeaconフレームを通信回路２００に送信させ、ＢＢのファイルを送信させ、当該ＢＢのファイル送信が終了した後、元のＩＢＳＳＩＤを利用した通信動作を再開させる。

また、割り込み送信に関する優先順位が表４に示されるようにファイルの種類に関連付けられて記憶されている場合、Ｚ（表２参照）という種類のファイルについての通信動作が行なわれているときに、ＸまたはＹという種類のファイルを送信する操作がなされると、ＣＰＵ１０１は、当該ＸまたはＹという種類のファイルを割り込み送信する。具体的には、割り込み送信の対象となるファイルの種類に応じてＩＢＳＳＩＤを決定し直し、当該ＩＢＳＳＩＤを利用したBeaconフレームを通信回路２００に送信させ、割り込み送信の対象となるファイルを送信させ、割り込み送信が終了した後、元のＩＢＳＳＩＤを利用した
通信動作を再開させる。

表３のＢＢや表４のＸのように、優先順位を１位とされたアプリケーションまたはファイルの種類については、その属性以外の属性に基づいた通信が行なわれている状態では、常に、割り込み送信が行なわれることになる。

なお、表３または表４に示したような優先順位は、端末１で実行または送信されるすべてのアプリケーションまたはファイルの種類について格納されていても良いし、一部についてのみ格納されていても良い。

また、優先順位は、予め端末１において設定されていても良いし、ユーザによる操作によって設定されても良い。

また、このような割り込み送信の処理は、通信回路２００のＣＰＵ２５１に実行させることもできる。この場合、表３または表４に示した情報は、ＥＥＰＲＯＭ２０７に格納される。

そして、ＣＰＵ２５１は、ステップＳＢ１０（図８参照）においてホストシステム１００からBeaconフレームを送信する指示がなされたと判断すると、ステップＳＢ１１で、ＣＰＵ１０１が送信してきたファイルの属性（アプリケーションを特定する情報またはファイルの種類）に基づいて、ＩＢＳＳＩＤを決定するとともに、現在他の端末との間で通信動作を行なっているか否かを判断する。そして、行なっていると判断した場合、通信動作がどのようなファイルの属性によるものかを判断し、当該属性が、その時点で（直前のステップＳＢ１０において）ＣＰＵ１０１から受信した情報で特定されるファイルの属性よりも表３または表４における優先順位が低いか否かを判断する。そして、低いと判断すると、ＣＰＵ２５１は、その時点で送信の操作がなされたファイルを、実行中の通信動作に対して、割り込み送信する。

［第２の実施の形態］
上記した第１の実施の形態では、通信に利用されるＩＢＳＳＩＤは、端末１〜４において、アプリケーション上で送信を指示されたファイルの属性に基づいて決定されていた。本実施の形態では、ＩＢＳＳＩＤは、各端末においてユーザから入力されるＳＳＩＤの内容に基づいて決定される。

図９は、本発明の無線通信ネットワークの第２の実施の形態において、端末間で接続が確立される際の情報のやり取りを説明するための図である。

図９を参照して、ネットワーク１０において端末１と端末２との間で接続が確立される場合、まず、１）として示されるように、ネットワーク１０内の各端末（端末１，２）においてＩＢＳＳＩＤが生成される。本実施の形態では、各端末が、入力部１０６を介して入力された情報（ＳＳＩＤ）に対して同じ演算を施す。これにより、各端末に対して同じＳＳＩＤが入力されれば、生成されるＩＢＳＳＩＤも同じものとなる。

そして、２）として示されるように、ネットワーク１０内のある端末（図９では端末１）が、生成したＩＢＳＳＩＤを含むBeaconフレームをブロードキャストする。これにより、当該Beaconフレームを送信した端末１と、当該Beaconフレームを受信した端末２との間で、接続が確立する。

本実施の形態のネットワーク１０を構成する複数の端末（端末１，２）は、それぞれ、図２を参照して説明したハードウェア構成を有するものとできるため、ここでは、これら
のハードウェア構成についての詳細な説明は繰返さない。

また、本実施の形態のネットワーク１０で送受信されるBeaconフレームの構成は、図３を参照して説明したものとすることができるため、詳細な説明は繰返さない。

次に、本実施の形態のネットワーク１０において、複数の端末間で接続が確立される際の、Beaconフレームを送信する端末において実行される処理について説明する。図１０は、そのような端末（便宜上、端末１とする）のホストシステム１００のＣＰＵ１０１が実行する処理のフローチャートであり、図１１は、当該端末１の通信回路２００のＣＰＵ２５１が実行する処理のフローチャートである。

図１０を参照して、ホストシステム１００では、ＣＰＵ１０１は、まずステップＳＤ１０において、ＳＳＩＤを特定する情報を入力する操作が入力部１０６に対してなされたか否かを判断する。そして、ＣＰＵ１０１は、そのような操作がなされたと判断すると、ステップＳＤ２０へ処理を進める。

ステップＳＤ２０では、ＣＰＵ１０１は、入力されたＳＳＩＤの値に基づいて、ＩＢＳＳＩＤを生成して、ステップＳＤ３０へ処理を進める。なお、ＣＰＵ１０１は、ステップＳＤ２０において、まず、入力部１０６に対して入力されたＳＳＩＤを特定する情報を受付け、当該情報をＲＡＭ１０３に一時的に格納する。そして、当該ＳＳＩＤを特定する情報に対して、ＣＰＵ１０１は、所定の演算を施す。所定の演算とは、たとえばハッシュ演算であり、ＣＰＵ１０１が当該演算を実行するのに必要とされるプログラムは、ＨＤ１０２に格納されている。そして、ＣＰＵ１０１は、当該演算の結果として得られた値をＲＡＭ１０３に格納して、ステップＳＤ３０へ処理を進める。

ステップＳＤ３０では、ＣＰＵ１０１は、インターフェイス１０７を介して、通信回路２００に、ＩＢＳＳＩＤを生成してＲＡＭ１０３に格納した旨を通知して、ステップＳＤ４０へ処理を進める。

図１１を参照して、通信回路２００のＣＰＵ２５１は、ステップＳＥ１０で、ホストシステム１００からＩＢＳＳＩＤが生成された旨の通知を受けるまで待機し、そして、当該通知を受けると、ステップＳＥ２０へ処理を進める。

ステップＳＥ２０では、ＣＰＵ２５１は、ホストシステム１００において生成されたＩＢＳＳＩＤを、ＲＡＭ１０３から読出し、ＥＥＰＲＯＭ２０６に格納させて、ステップＳＥ３０へ処理を進める。

そして、ＣＰＵ２５１は、ステップＳＥ３０において、ホストシステム１００からBeaconフレーム送信指示が来るまで待機する。

図１０に戻って、ステップＳＤ３０でＩＢＳＳＩＤを生成した旨の通知を行なった後、ＣＰＵ１０１は、ステップＳＤ４０で、入力部１０６等を介して、ネットワークへの接続を要求する情報が入力されたか否かを判断し、当該情報が入力されたと判断すると、ステップＳＤ５０へ処理を進める。

ステップＳＤ５０では、ＣＰＵ１０１は、通信回路２００に対して、Beaconフレームの送信を指示する情報を送信して、処理を終了させる。

図１１を参照して、ホストシステム１００からBeaconフレームの送信を指示する情報を受取ると、ＣＰＵ２５１は、ステップＳＥ３０からステップＳＥ４０へ処理を進める。

ステップＳＥ４０では、ＣＰＵ２５１は、Beaconフレームを生成して、ステップＳＥ５０へ処理を進める。なお、ステップＳＥ４０では、ステップＳＥ２０でＥＥＰＲＯＭ２０６に格納させたＩＢＳＳＩＤを、BeaconフレームのＩＢＳＳＩＤとしてセットする。

ステップＳＥ５０では、ＣＰＵ２５１は、ステップＳＥ４０で生成したBeaconフレームをアンテナ２０３を介してブロードキャスト送信する。

なお、本実施の形態では、ネットワーク１０を構成する各端末においてＳＳＩＤが入力されると、図１０を参照して説明したのと同様に、ＩＢＳＳＩＤが生成される。また、本実施の形態では各端末においてＳＳＩＤに対して同じ演算を行なうように構成されている。したがって、各端末に同じＳＳＩＤの値を入力すれば、ネットワーク１０を構成するすべての端末において、同じＩＢＳＳＩＤが生成されることになる。

また、ネットワーク１０における通信のセキュリティを向上させるため、ＩＢＳＳＩＤに対して施す演算の内容は、定期的に変更されてもよい。この場合、ネットワーク１０を構成するすべての端末において演算の内容は同時に変更されるべきである。

以上説明した本実施の形態では、各端末において、ホストシステム１００側で、ＳＳＩＤに演算を施すことによりＢＳＳＩＤが生成されていた。なお、各端末において、ＢＳＳＩＤは、通信回路２００側で生成されてもよい。ここで、通信回路２００側でＢＳＳＩＤが生成される場合の、ホストシステム１００のＣＰＵ１０１で実行される処理のフローチャートを図１２に示し、通信回路２００のＣＰＵ２５１で実行される処理を図１３に示す。

図１２を参照して、ＣＰＵ１０１は、ステップＳＤ１０で、入力部１０６等を介してＳＳＩＤを特定する情報が入力されたと判断すると、ステップＳＤ１１へ処理を進める。

ステップＳＤ１１では、ＣＰＵ１０１は、当該ＳＳＩＤをＲＡＭ１０３に格納するとともに、インターフェイス１０７を介して通信回路２００にＳＳＩＤが入力されたことを通知する情報を送信して、ステップＳＤ４０へ処理を進める。

図１３を参照して、ＣＰＵ２５１は、ステップＳＥ１１で、ホストシステム１００からＳＳＩＤの入力の通知を受けるまで待機し、当該通知を受けると、ステップＳＥ１１からステップＳＥ１２へ処理を進める。

ステップＳＥ１２では、ＣＰＵ２５１は、ＲＡＭ１０３に格納されたＳＳＩＤを読出し、そして、当該ＳＳＩＤに対して所定の演算を施すことによりＩＢＳＳＩＤを生成する。ここで、所定の演算とは、たとえばハッシュ演算であり、ＣＰＵ２５１が当該演算を実行するためのプログラムは、たとえばＥＥＰＲＯＭ２０７に格納されている。

次に、ＣＰＵ２５１は、ステップＳＥ２０で、ステップＳＥ１２で生成したＩＢＳＳＩＤの値を、通信に利用するＩＢＳＳＩＤとしてＥＥＰＲＯＭ２０６に格納させて、ステップＳＥ３０へ処理を進める。

ステップＳＥ３０では、ＣＰＵ２５１は、ホストシステム１００からBeaconフレームの送信を指示されるまで待機する。

図１２に戻って、ＣＰＵ１０１は、ステップＳＤ１１で通信回路２００に対してＳＳＩＤの入力を通知した後、ステップＳＤ４０で、入力部１０６等を介してネットワークへの
接続を要求する情報が入力されたか否かを判断する。そして、そのような情報が入力されたと判断すると、ステップＳＤ５０に処理を進める。

ステップＳＤ５０では、ＣＰＵ１０１は、通信回路２００に対してBeaconフレームの送信を指示する情報を送信して、処理を終了する。

図１３を参照して、ＣＰＵ２５１は、ホストシステム１００からBeaconフレームの送信を指示されると、ステップＳＥ３０からステップＳＥ４０へ処理を進める。

ステップＳＥ４０では、ＣＰＵ２５１は、ＥＥＰＲＯＭ２０６に格納させていたＩＢＳＳＩＤの値を利用してBeaconフレームを生成して、ステップＳＥ５０へ処理を進める。

ステップＳＥ５０では、ＣＰＵ２５１は、ステップＳＥ４０で生成したBeaconフレームを、アンテナ２０３を介してブロードキャスト送信して、処理を終了する。

［第３の実施の形態］
本実施の形態では、無線ＬＡＮ（Local Area Network）の規格の一つである、ＩＥＥＥ８０２．１１規格に基づいて通信が行なわれる場合を想定し、図１および図２に示したネットワーク１０において、受信側端末の通信回路２００によるＦＣＳが指す冗長コードに従うエラーチェックを省略するシステムが提供される。

本実施の形態では、ネットワーク１０においては同一無線セルを構成する端末ＳＴＡ１とＳＴＡ２とが無線通信する場合を想定する。図１４と図１５には、端末ＳＴＡ１とＳＴＡ２の構成が示される。図１４と図１５の構成は、図２に示した端末１の構成と同様である。ここでは、端末ＳＴＡ１とＳＴＡ２との構成を区別するために、図１４の端末ＳＴＡ１の各部の符号には図２の対応する部分の符号に４桁目の“１”を付与しており、図１５の端末ＳＴＡ２では、同様に符号に４桁目の“２”を付与して、両端末の各部を区別して示す。端末ＳＴＡ１は通信回路２００１とホストシステム１００１からなり、端末ＳＴＡ２は通信回路２００２とホストシステム１００２からなる。

図１６には、本実施の形態に係るＦＣＳが指す冗長コードに従うエラーチェックを行なわない方式（ここでは、Ｎｏ ＦＣＳ方式という）の通信シーケンスが模式的に示される。図１７と図１８には第３の実施の形態に係る通信処理のフローチャートが示される。図１９と図２０には第３の実施の形態に係るフレーム（Beaconフレーム）の構成が模式的に示される。図２１と図２２には第３の実施の形態に係るメモリの内容例が示される。

図１６のシーケンスを参照しながら、セッションを確立した端末ＳＴＡ１とＳＴＡ２により図１７と図１８のフローチャートに従い端末ＳＴＡ１側で、ファイルの送信要求が生じて、ファイルを端末ＳＴＡ２に送信する場合を説明する。

まず、送信側の端末ＳＴＡ１のホストシステム１００１のＣＰＵ１０１１は、ステップＳＦ１０において入力部１０６１から入力した指示または実行中のアプリケーション（アプリケーションプログラム）に従い、ファイル送信操作がなされたかを判別する。送信操作がなされたと判断すると、ステップＳＦ１３に処理を進める。

ステップＳＦ１３においては、ＣＰＵ１０１１は、入力部１０６１から入力した指示または実行中のアプリケーションに従い、Ｎｏ ＦＣＳ方式の要求が入力されているかを判断する。当該要求の入力ありと判断すると、次のステップＳＦ１６において、Ｎｏ ＦＣＳ通知のデータを生成し、当該データをＲＡＭ１０３１に格納した後、当該データの送信指示を通信回路２００１へ送信する。

通信回路２００１のＣＰＵ２５１１はステップＳＦ２７において、ホストシステム１００１からＮｏ ＦＣＳ方式の送信指示を入力するので、ステップＳＦ３０では、通信回路
２００１はＲＡＭ１０３１から読出したＮｏ ＦＣＳ通知を含むBeaconフレーム（図１９参照）を第１の実施の形態と同様にして生成して送信する。

受信側端末ＳＴＡ２の通信回路２００２においては、ステップＳＧ１０とＳＧ１３において、第１の実施の形態と同様にして図１９のBeaconフレーム３００が受信されて、コントロールＭＡＣ２５７２に与えられる。図１９のBeaconフレーム３００はユーザ・データボディ部３２２にＮｏ ＦＣＳ通知３４０を含む。

コントロールＭＡＣ部２５７２は、ステップＳＧ１５において、デジタル信号に変換されている図１９のBeaconフレーム３００を入力し、入力したBeaconフレーム３００について、フレーム先頭検出、時間および周波数の同期処理を行なった後、Ｎｏ ＦＣＳ通知３４０が含まれていることを検出するので、応じて、共有メモリ２５５２の所定領域２５５３にデータ２５５４を書込み設定する。

具体的には、図２１に示すように、所定領域２５５３のデータ２５５４は、通常はＦＣＳエラーチェック（誤り訂正復号）を行なうことを指示（エラーチェックイネーブル）するように設定されているが、Ｎｏ ＦＣＳ通知３４０を受信すると、コントロールＭＡＣ部２５７２によりＦＣＳエラーチェックを行なわないことを指示（エラーチェックディスイネーブル）するように設定（更新）される。

その後、ＣＰＵ２５５２は、ステップＳＧ１６において、データ２５５４を共有メモリ２５５２から読出しホストシステム１００２に通知する。

ホストシステム１００２のＣＰＵ１０１２は、ステップＳＧ３７とＳＧ４０において、通信回路２００２からデータ２５５４を受信すると、ステップＳＧ４３において、受信データを用いて図２２に示すＲＡＭ１０３１の所定領域１０３３のデータ１０３４を書換え（更新）する。

所定領域１０３３のデータ１０３４は、通常はＦＣＳエラーチェック（誤り訂正復号）を行なうことを指示（エラーチェックイネーブル）するように設定されているが、通信回路２００２からデータ２５５４を入力し更新された場合には、ＦＣＳエラーチェックを行なわないことを指示（エラーチェックディスイネーブル）するように設定（更新）される。

次に、送信が要求されているファイルの送信が開始される。ここでは、ファイルはリアルタイム処理が要求されるＡ／Ｖデータのファイルであると想定する。

端末ＳＴＡ１において予め送信ファイルのデータは所定サイズに分割されて、ステップＳＦ１９とＳＦ２３において、分割後の各データ（Ａ／Ｖデータ）は、全データを送信完了と判断されるまでファイル送信指示とともに通信回路２００１に順次に与えられる。

通信回路２００１は、ステップＳＦ３３、ＳＦ３６およびＳＦ３９において、ファイルの全データを端末ＳＴＡ２に送信完了するまで、ファイル送信指示を通信回路２００１から入力する毎に、ユーザ・データボディ部３２２を当該指示とともに入力したデータ３２２１により構成されるBeaconフレーム３００を生成し、ネットワーク１０に送信する。

通信回路２００１はホストシステム１００１からの通知によりファイル送信の終了を判
断すると、ステップＳＦ４３では、データ３４０が‘Ｎｏ ＦＣＳ解除通知’からなる図１９のBeaconフレーム３００を生成してネットワーク１０に送信する。

受信側の端末ＳＴＡ２では、通信回路２００２は、ステップＳＧ１９〜ＳＧ２６において、端末ＳＴＡ１から図２０のBeaconフレーム３００を、ファイルの送信が完了するまで繰返し受信する。図２０のBeaconフレーム３００はユーザ・データ・ボディ部３２２に送信するべきファイルデータを構成するＡ／Ｖデータ３２２１を含む。

このとき、Beaconフレーム３００を受信する毎にコントロールＭＡＣ部２５７２は、ステップＳＧ２０、ＳＧ２１、ＳＧ２２およびＳＧ２３において、共有メモリ２５５２のデータ２５５４に基づき次のように処理する。

まず、ステップＳＧ２０において共有メモリ２５５２のデータ２５５４を参照し、エラーチェックイネーブルを指していると判断すると（ステップＳＧ２０でＮＯ）、ステップＳＧ２１とＳＧ２２において、受信したデータ（Ａ／Ｖデータ３２２１）を、同時に受信したＦＣＳ部３３０の冗長コードを用いてＦＣＳエラーチェック（誤り訂正復号）し、その復号後のＡ／Ｖデータ３２２１をホストシステム１００２に送信する。一方、ステップＳＧ２０において共有メモリ２５５２のデータ２５５４はエラーチェックディスイネーブルを指していると判断すると（ステップＳＧ２０でＹＥＳ）、ＦＣＳエラーチェックを省略し、ステップＳＧ２３において受信したデータ（Ａ／Ｖデータ３２２１）とＦＣＳ部３３０の冗長コードとを、ホストシステム１００２に送信する。

ホストシステム１００２では、ＣＰＵ１０１２はステップＳＧ４６〜ＳＧ５３において、通信回路２００２から最終データを受信するまでは次の処理を繰返す。

つまり、通信回路２００２からデータを受信する毎に、ステップＳＧ４７においてＲＡＭ１０３２のデータ１０３４を参照して‘エラーチェックイネーブル’を指示するか否か判断する。‘エラーチェックイネーブル’を指示すると判断すると（ステップＳＧ４７でＹＥＳ）、ステップＳＧ４９において同時に受信しているＦＣＳ部３３０の冗長コードを用いて受信データ（Ａ／Ｖデータ３２２１）を誤り訂正復号し、ステップＳＧ５１において、復号されたＡ／Ｖデータ３２２１に従う音・画像をスピーカ１０５２またはディスプレイ１０４２を介し出力する。

一方、ＲＡＭ１０３２から読出したデータ１０３４は‘エラーチェックディスイネーブル’を指示すると判断すると（ステップＳＧ４７でＮＯ）、通信回路２００２から入力した受信データ（Ａ／Ｖデータ３２２１）をそのまま（誤り訂正なしに）復号し、ステップＳＧ５１において、復号されたＡ／Ｖデータ３２２１に従う音・画像をスピーカ１０５２またはディスプレイ１０４２を介し出力する。

受信データであるＡ／Ｖデータ３２２１に最終データである旨の情報が付されている場合には、当該付された情報に基づきステップＳＧ５３においてＣＰＵ１０１２は最終データ受信完了と判断し（ステップＳＧ５３でＹＥＳ）、処理はステップＳＧ５６以降に移る。

一方、通信回路２００２ではステップＳＧ２９において、コントロールＭＡＣ部２５７２はネットワーク１０を介して図１９のユーザ・データボディ部３２２を‘Ｎｏ ＦＣＳ通知’に代替して‘Ｎｏ ＦＣＳ解除通知’指示するデータ３４０で構成したBeaconフレーム３００を受信し、ステップＳＧ３２において、受信した当該通知をホストシステム１００２に送信する。その後、ステップＳＧ３３において、共有メモリ２５５２の所定領域２５５３のデータ２５５４を通常のデータに戻すように更新する。すなわちデータ２５５
４を‘エラーチェックイネーブル’を指示するように更新する。なお、データ２５５４が‘エラーチェックイネーブル’を指す場合には更新は行なわれない。

ホストシステム１００２では、ＣＰＵ１０１２はステップＳＧ５６において、通信回路２００２から‘Ｎｏ ＦＣＳ解除通知’を受信すると、ステップＳＧ５９において、ＲＡＭ１０３２の所定領域１０３３のデータ１０３４を通常のデータに戻すように更新する。すなわちデータ１０３４を‘エラーチェックイネーブル’を指示するように更新する。なお、データ１０３４が‘エラーチェックイネーブル’を指す場合には更新は行なわれない。

本実施の形態では図１８において、ステップＳＧ２０およびＳＧ４７において、受信フレーム毎にＮｏ ＦＣＳ設定の有無を判断するようにしているが、図１６に示すようにファイル送信開始から終了までの期間においては一旦設定されたＮｏ ＦＣＳ設定のデータの変更はない場合は、受信フレーム毎のＮｏ ＦＣＳ設定の有無判断を、ファイル受信開始時にのみに行なうようにしてもよい。

本実施の形態によれば、ＦＣＳに従う冗長コードを用いた誤り訂正復号を通信回路２００１（２００２）では行なわなわず、後段のホストシステム１００１（１００２）で実行するというＮｏ ＦＣＳ方式を用いることにより、エラーチェック処理を省略したフレーム通信が可能となる。これにより、ホストシステム１００１（１００２）で実行されるべきアプリケーションが要求するデータに応じて（リアルタイム性の通信が要求されるデータであるか否かなど）に応じてＮｏ ＦＣＳ方式を設定するか否かを入力部１０６１（１０６２）を操作して適宜変更することができる。これにより、たとえば非圧縮Ａ／Ｖデータを再生するアプリケーションプログラムを実行するホストシステム１００１（１００２）側でのデータ欠落のない精度の高いストリーミング再生が可能となる。

［第４の実施の形態］
本実施の形態では、無線ＬＡＮ（Local Area Network）の規格の一つである、ＩＥＥＥ８０２．１１規格に基づいて通信が行なわれる場合を想定し、無線ＬＡＮアドホック・ネットワークにおける端末の消費電力低減を実現するための通信方式として、間欠送受信アドホック・モードと称する方式が提示される。ここでは、同一無線セルを構成する２つの端末ＳＴＡ１とＳＴＡ２、およびＳＴＡ３を想定する。端末ＳＴＡ１とＳＴＡ２は図１４と図１５に示す構成を有するので構成の詳細説明は略す。端末ＳＴＡ３は図２に示すのと同様の構成を有する。

図２３は、本実施の形態に係る間欠送受信アドホック・モードのシーケンスを模式的に示す図である。ここで、間欠送受信アドホック・モードとは、通信回路２００が、電源回路２０１により電源ＯＮされて各部に電力が供給されてからＯＦＦされる（各部の供給電力が断たれる）までのデータの送受信が可能な期間において、間欠的に送受信動作を行なうようなモードを指す。したがって、電源ＯＮされてから電源ＯＦＦされるまでの間（これを、受信を待機する待機期間という）、通信回路２００は、スリープ期間（図２３の破線を示す）とウェイク期間（図２３の斜線の期間を示す）を交互に繰返し、ウェイク期間において送受信が可能となる。

ウェイク期間においては、クロック回路２０２により、通信回路２００の各部にクロックが供給される。各部はクロックが供給される期間は電源回路２０１からの供給電力を受けて動作するので、各部により電力が消費される状態にある。この状態においては、データの送受信が可能である。

ウェイク期間からスリープ期間に移行するとき、クロック回路２００はＣＰＵ２５１に
よりＯＦＦが指示される。クロック回路２００はＯＦＦが指示されると、タイマ２５５を除く各部にクロックの出力を停止する。これにより、通信回路２００のタイマ２５５を除く各部にはクロックが供給されなくなる。各部はクロックが供給停止される期間は、動作が不可能である（停止する）。これにより、スリープ期間では各部は動作を停止するのでデータ送受信が不可能であるが、タイマ２５５を除く各部での電力消費はないので省電力できる。

スリープ期間においては、タイマ２５６は計時動作を行ない、タイマ２５６は、一定のスリープ期間を計時すると、クロック回路２０２にＯＮの指示を与える。クロック回路２００はＯＮの指示を入力すると、応じて通信回路２００の各部にクロックの出力を再開する。これにより、各部は動作を再開し電力の消費が再開される。これによりスリープ期間からウェイク期間に移行する。

ウェイク期間においては、ＣＰＵ２５１は、タイマ２５６から入力する計時値に基づき、一定のウェイク期間が経過したことを検知すると、クロック回路２０２にＯＦＦの指示を与える。これにより、通信回路２００はウェイク期間からスリープ期間に移行する。

図２３を参照して、端末ＳＴＡ１とＳＴＡ２の両端末は、電源ＯＮされると、ウェイク期間に入り、Beaconフレーム３００を送信する。このBeaconフレーム３００は、端末ＳＴＡ１から送信されるものについては、図２４（Ａ）に示すフォーマット有し、端末ＳＴＡ２から送信されるものについては図２４（Ｂ）に示すフォーマットを有する。両方のBeaconフレーム３００のＤＡ３１１は、ブロードキャストに従う宛先を指している。

図２３において、端末ＳＴＡ１は、電源ＯＮされた後の４回目のウェイク期間において、３回目のウェイク期間に移行している端末ＳＴＡ２から送信された図２４（Ｂ）のBeaconフレーム３００を受信することができるので、受信したことに応じて、ＭＡＣヘッダ部３１０に確認応答のＮＵＬＬを有するBeaconフレーム３００（図２４（Ｃ）参照）を端末ＳＴＡ２に送信する。端末ＳＴＡ２は、ＮＵＬＬのBeaconフレーム３００を受信したことに応じて、ＭＡＣヘッダＢ３１０にＡＣＫ応答を有するBeaconフレーム３００（図２４（Ｄ）参照）を送信する。これにより、端末ＳＴＡ１とＳＴＡ２の間でセッションが確立（通信相手を確認し確認した通信相手と通信が可能な状態になること）して、端末ＳＴＡ１は、予めホストシステム１００１側から受信していたデータ送信要求に応じたデータのフレームを端末ＳＴＡ２に送信する。

図２５と図２６には、間欠送受信アドホック・モードを実装した場合において、端末ＳＴＡ１、ＳＴＡ２およびＳＴＡ３が待機時に周期的にスリープ期間に移行することによって待機電力（待機時の消費電力）を低減することが模式的に示される。図２５の状態（１）では、端末ＳＴＡ３はスリープ期間にあるがウェイク期間の端末ＳＴＡ１から送信されたBeaconフレーム３００は、ウェイク期間にある端末ＳＴＡ２により受信されて応答が返信されて、その後、端末ＳＴＡとＳＴＡ２の間でセッションが確立してデータ通信をする（図２６参照）。そして図２５の状態（２）に移行する。データ通信をする期間において、同じ無線セルに在る端末ＳＴＡ３は、ウェイク期間とスリープ期間を交互に繰返して電力消費量を低減するように動作する。

状態（２）では、端末ＳＴＡ１とＳＴＡ２の間でデータ通信をする期間において、同じ無線セルに在る端末ＳＴＡ３がウェイク期間にある。

データ通信が終了した後、図２５の状態（３）において、端末ＳＴＡ１から送信されたBeaconフレーム３００をウェイク期間にある端末ＳＴＡ３（端末ＳＴＡ２はスリープ期間にある）が受信し、図２６に示すように両者の間で応答が送受信されて、セッションが確
立し、状態（４）のデータ通信が行なわれる。このデータ通信期間では、同じ無線セルに在る端末ＳＴＡ２は、ウェイク期間とスリープ期間を交互に繰返して電力消費量を低減するように動作する。

図２７には、本実施の形態によるシステム状態の遷移モデルが示される。この遷移モデルにおいては、説明を簡単にするためにBeaconフレーム送出中のクロック停止状態に関しての記述が省略されている。図示されるように端末では、電源ＯＮされるとシステム設定がなされる。この設定では待機期間（ウェイク期間＋スリープ期間）とウェイク期間を指定するデータなどが設定される。その後、待機状態（ウェイク期間）に移行しネットワーク１０におけるBeaconフレームを監視する。設定された一定のウェイク期間内にBeaconフレームを受信できないときは（タイムアウト）、スリープ期間に移行する。一定のスリープ期間が終了すると（タイムアウト）、待機期間（ウェイク期間）に移行し、Beaconフレームを監視する。監視する中でBeaconフレームを受信すると（Beacon検出）セッション期間（データ送受信）に移行する。データ送受信が終了しセッション期間が終了すると、待機期間（ウェイク期間）に移行する。

図２７の状態遷移は共有メモリ（２５５１、２５５２）に予め設定された各種パラメータを参照することにより実現される。図２８には共有メモリ（２５５１、２５５２）に予め格納される各種パラメータが示される。パラメータとしては、待機期間データ２８０、ウェイク期間データ２８１、ＭＡＸ待機回数データ２８２、カウント待機回数データ２８３およびデフォルト待機期間データ２８４を含む。図２８のデータが格納される記憶領域は、電源回路２０１からの電力供給が断たれる場合でも、その記憶内容を保持できるような記憶領域である。

図２８の各種パラメータは、ホストシステム（１００１、１００２）の入力部（１０６１、１０６２）が操作されて外部から入力されて共有メモリ（２５５１、２５５２）に格納され、または、ホストシステム（１００１、１００２）で実行されるべきアプリケーションプログラムに従いＣＰＵ（１０１１、１０１２）により共有メモリ（２５５１、２５５２）に格納される。したがって共有メモリのデータは入力部（１０６１、１０６２）を操作することにより、または実行されるべきアプリケーションの種類などに従い可変に設定することができる。

ここでは、主に端末ＳＴＡ１とＳＴＡ２との間の間欠送受信アドホック・モードを想定するので、これらのパラメータは共有メモリ２５５１と２５５２に図２８のように格納されるとしたが、端末ＳＴＡ３においても同様に格納される。

図２９に示されるように、待機期間はウェイク期間とスリープ期間からなる。したがって、スリープ期間＝待機期間データ２８０−ウェイク期間データ２８１により算出することができる。

ＭＡＸ待機回数データ２８２は、待機期間データ２８０を更新（変更）するための閾値を示す。具体的にはＭＡＸ待機回数データ２８２が示す回数分連続して待機（ウェイク期間）を繰返してもBeaconフレームを受信（検出）できない場合に、待機期間データ２８０を変更（調整）する。カウント待機回数データ２８３が示す値は、Beaconフレームを受信したときから次のBeaconフレームを受信するまでの間に待機期間に移行した回数を指す１種のカウンタの機能を有する。カウント待機回数データ２８３の値は、Beaconフレームを受信する毎にリセットされる。たとえば０に更新される。

デフォルト待機期間データ２８４は、後述するように待機期間データ２８０が指す待機期間（ｍｓ）を更新するための算出において参照される。

図２９に示すように、待機期間におけるウェイク期間においてはBeaconフレームを受信することが可能な期間であるので、たとえば、Beaconフレームの受信可能確率（Beaconフレーム検出率）を高くすることに重きを置くならば、待機期間データ２８０が指す待機期間（ｍｓ）を短く設定しかつ待機期間におけるウェイク期間データ２８１が指すウェイク期間（ｍｓ）を長く設定する。一方、待機期間に消費電力を低減することに重きを置くならば、待機期間（ｍｓ）が長くなり、かつウェイク期間を短くするように待機期間データ２８０およびウェイク期間データ２８１を設定する。

図３０と図３１は、待機期間の可変設定（自動調整）について説明する図である。たとえば、図３０に示されるように、待機期間が固定とされる場合には、端末ＳＴＡ１のBeaconフレームの送信完了周期と、端末ＳＴＡ２におけるウェイク期間開始の周期とが同じとなる（一致する）ケースが生じる可能性がある。そのケースでは端末ＳＴＡ２はウェイク期間においてBeaconフレーム３００を受信できないので両者の間ではセッションが確立されることはなく、データ通信が行なわれることはない。

これに対して、図３１の待機期間の自動調整機能がある場合には、たとえば、カウント待機回数データ２８３の値が、矢印２８５で示す期間においてＭＡＸ待機回数データ２８２が指す値を超えた場合には、上述したように周期が同じになっている可能性があるので端末ＳＴＡ２の待機期間データ２８０が指す待機期間（ｍｓ）を変更（更新）する。これにより周期をずらすことができて、図３１の矢印２８６で示すタイミングにおいて、端末ＳＴＡ１のBeaconフレーム３００の発信期間と、端末ＳＴＡ２のウェイク期間とが一致し、端末ＳＴＡ２は、端末ＳＴＡ１側からのBeaconフレーム３００を受信することができて、両者の間で、データ通信をすることができる。

本実施の形態では、待機期間データ２８０が指す待機期間（ｍｓ）の更新は、（更新後待機期間＝デフォルト待機期間データ２８４が指すデフォルト待機期間＋ランダム係数）との計算式（１）に従いＣＰＵ（２５１１、２５１２）が新たな待機期間を算出し、算出された待機期間を共有メモリ（２５５１、２５５２）の待機期間データ２８０として格納（待機期間データ２８０を上書き）することにより行なわれる。

待機期間（ｍｓ）の算出に用いられるランダム係数は、端末１が所有している以下のパラメータから生成することができる。たとえばＭＡＣアドレス、エラー回数、クロック回路２０２が指すリアルタイムクロック（日付、時間）およびハードウェアタイマ２５６が指す時間データなどである。ここで、エラー回数とはＭＡＸ待機回数データ２８２に照らして待機期間（ｍｓ）の更新が行なわれた回数のトータル値を指す。

図３２と図３３のフローチャートを参照しながら、図２３のシーケンスに従う間欠送受信アドホック・モードについて説明する。図３２と図３３のフローチャートは、端末ＳＴＡ１と端末ＳＴＡ２の間で通信が行なわれることを想定したものである。なお、予め電源がＯＮされて共有メモリ２５５２（２５５２）には図２８に示すデータの格納が完了していると想定する。ここでは、カウント待機回数データ２８３は０に初期設定される。

図３２に従い端末ＳＴＡ１がBeaconフレーム３００を送信しながらネットワーク１０を介してBeaconフレーム３００の受信を待機する期間の動作について説明する。

まず、電源ＯＮして待機期間が開始されるとタイマ２５６１から入力する計時時間データに基づきＣＰＵ２５１１はステップＳＨ１０においてウェイク期間を計時開始する。待機時間が始まると、まずウェイク期間（ウェイクモード）に移行する。ステップＳＨ１３では、このウェイク期間の経過がタイマ２５６１の計時データに基づきＣＰＵ２５１１に
より計時（検知）される。このウェイク期間の処理は図３３において後述する。

ウェイク期間が経過したことが判断されると、スリープ期間に移行する。ステップＳＨ１６とＳＨ１９では、前述したようにクロック回路２０２１からのクロックの供給は停止して各部での電力消費はなされず送受信は不可能となる。また、タイマ２５６１によってスリープ期間の経過が計時される。

ステップＳＨ２２においてタイマ２５６１は計時値とスリープ期間の値とを比較して、比較結果が（計時値≧スリープ期間の値）を指すと検知すると（ステップＳＨ２２でＹＥＳ）、スリープ期間の終了、すなわち待機期間が終了したと判断し後述のステップＳＨ２５の処理に移行する。なお、スリープ期間の値は、ＣＰＵ２５１１により共有メモリ２５５１から読出した値を用いて（待機期間データ２８０−ウェイク期間データ２８１）に従い予め算出されて、タイマ２５６１に与えられていると想定する。

なお、比較結果が（計時値＜スリープ期間の値）を指すと判断される間は（ステップＳＨ２２でＮＯ）、待機期間が終了していないと検知されて、ステップＳＨ１６、ＳＨ１９およびＳＨ２２の処理が繰返される。

ステップＳＨ２５では、タイマ２５６１はクロック回路２０２１に対しＯＮの指示を与えるので、応じてクロック回路２０２１が再起動し各部にクロック信号が供給されて送受信可能な状態となる。このとき、クロック信号を入力再開するとＣＰＵ２５１１は、ステップＳＨ２８においてメモリ２５５１のカウント待機回数データ２８３を＋１アップする（更新する）。

その後、ＣＰＵ２５１１は、カウント待機回数データ２８３の値が、ＭＡＸ待機回数データ２８２が示す値以上を指示するか否かを両者を比較して判定する。具体的にはステップＳＨ３１において、当該比較結果が（カウント待機回数データ２８３≧ＭＡＸ待機回数データ２８２）を指すと判断されなければ（ステップＳＨ３１でＮＯ）、待機期間データ２８０の変更処理は行なわれず、一連の処理は終了し、次の待機期間のための処理に移行する。

一方、比較結果が（待機回数のデータ２８３≧ＭＡＸ待機回数のデータ２８２）を指すと判断されると（ステップＳＨ３１でＹＥＳ）、ステップＳＨ３３において待機期間の変更処理が上述の計算式（１）に従いＣＰＵ２５１１により算出されて、算出値を用いて共有メモリ２５５１の待機期間データ２８０が更新される。そして、ＣＰＵ２５１１は、ステップＳＨ３６において共有メモリ２５５１のカウント待機回数データ２８３をリセット（０）する。その後、一連の処理は終了し、次の待機期間のための処理に移行する。

図３３を参照して、図３２のステップＳＨ１３のウェイク期間処理について説明する。ウェイク期間においては、端末ＳＴＡ１のコントロールＭＡＣ部２５７１は、ステップＳＩ１０において、ブロードキャストのBeaconフレーム３００を送信し、その後、ステップＳＩ１３において何らかの信号を受信したかを判定する。

何らの信号も受信しないと判定されると（ステップＳＩ１３でＮＯ）その旨がコントロールＭＡＣ部２５７１からＣＰＵ２５１１に通知されて、ＣＰＵ２５１１は、ステップＳＩ４６において、タイマ２５６１から入力する計時データに基づき、ウェイク期間が終了したか否かを判断する。具体的には、入力計時データと共有メモリ２５５１から読出したウェイク期間データ２８１とを比較し、比較結果が（入力計時データ≧ウェイク期間データ２８１）を示すと判断すると、ウェイク期間を終了する（ステップＳＩ４６でＹＥＳ）。そして、図３２のステップＳＨ１６のスリープ期間に移行する。

比較結果が（入力計時データ＜ウェイク期間データ２８１）を示すと判定すると（ステップＳＩ４６でＮＯ）、ステップＳＩ１０の処理に戻り、Beaconフレーム３００の送信を行なう。

一方、ネッオワーク１０を介し端末ＳＴＡ１からのBeaconフレーム３００を受信したことを判断すると（ステップＳＩ１３でＹＥＳ、ＳＩ１６でＹＥＳ）、ステップＳＩ１９とＳＩ２３では、コントロールＭＡＣ部２５７１により前述したＮＵＬＬ応答のBeaconフレーム３００が生成されて、当該フレームが端末ＳＴＡ１に送信される。その後、ステップＳＩ３１に移行して、相手側の端末ＳＴＡ２からＡＣＫ応答のBeaconフレーム３００を受信するか否かを判定する。

コントロールＭＡＣ部２５７１はＮＵＬＬ応答のフレームを受信したと判定すると（ステップＳＩ２１でＹＥＳ）、コントロールＭＡＣ部２５７１は、ステップＳＩ２５とＳＩ２８においてＡＣＫ応答のBeaconフレーム３００を生成し送信する。その後、処理は後述のステップＳＩ４３に移行する。

コントロールＭＡＣ部２５７１によりＡＣＫ応答のBeaconフレーム３００を受信したと判定されると（ステップＳＩ３１でＹＥＳ）、そのとき、ホストシステム１００１からデータ送信要求を入力していれば（ＳＩ３３でＹＥＳ）、ステップＳＩ３７とＳＩ４０においてホストシステム１００１から与えられるデータに基づき、コントロールＭＡＣ部２５７は、データ送信用のフレームを生成する。生成されたデータのフレームは送信される。

一方、端末ＳＴＡ２からＡＣＫのBeaconフレーム３００を受信できないと判定すると（ステップＳＩ３１でＮＯ）、データフレームを受信したか否かを判定する（ステップＳＩ４３）。コントロールＭＡＣ部２５７１によりデータフレームを受信していないと判定されると（ステップＳＩ３３でＮＯ）、前述したステップＳＩ４６の処理に移行する。

データフレームを受信したと判定されると（ステップＳＩ４３でＹＥＳ）、ステップＳＩ４４において当該データフレームのデータはたとえばプログラムメモリ２５４１に一時的に格納されて、プログラムメモリ２５４１に格納された受信データは、その後ホストシステム１００１側に送信されて、ホストシステム１００１側で処理される。データフレームを受信したと判定されないと（ステップＳＩ４３でＮＯ）、処理はステップＳＩ４６に移行する。

ここでは端末ＳＴＡ１側の待機期間の処理について述べたが、端末ＳＴＡ２においても待機期間では同様な処理を適用して消費電力を低減することができる。

本実施の形態によれば、送受信待機期間中に周期的なスリープ期間（クロック停止期間）を設けて通信回路２００の各部で電力消費がされない状態にするので、無線ＬＡＮ機器である端末ＳＴＡ１、ＳＴＡ２、ＳＴＡ３の消費電力低減を実現することができる。

また、スリープ期間内は各部にクロック供給が停止されるため他の端末との通信が行なえないけれども、通信が行なえない期間が一定時間以上続いた場合、前述の計算式（１）を用いてスリープ期間またはスリープ周期を各端末内で自動的に変更することができるので、Beaconフレーム３００を受信できる確率に変更することができる。

［第５の実施の形態］
本実施の形態では、無線ＬＡＮ（Local Area Network）の規格の一つである、ＩＥＥＥ８０２．１１規格に基づいて通信が行なわれる場合を想定し、第１の実施の形態または第
２の実施の形態で示した無線ＬＡＮネットワーク１００において、各端末１の管理情報（ＩＢＳＳＩＤ３１３、ＳＳＩＤ３２１１など）のみならず、ユーザ定義のデータおよび送信すべきデータ（実体データ）を、規定された管理フレームによって送受信することによって、ネットワークの通信制御を行なう。これにより、ユーザ定義のデータや送信すべき実体データの送受信が管理フレームを用いて可能となり、別途のデータ通信用フレームを送受信するのに比べて通信効率を向上させることができる。

本実施の形態では管理フレームとして、アド・ホックネットワークで規定された管理フレームであり、端末１がネットワーク１０の状況監視（スキャンニング）をするために送受信するBeaconフレーム３００のフレーム・ボディ部３２０の未使用部分を使用して、ユーザ定義の情報を送信する。

本実施の形態では、端末１、ＳＴＡ１およびＳＴＡ２の構成は図２、図１４、図１５に示すものと同様であるので説明は略す。

本実施の形態では、端末１の通信モードに応じてフレームをフィルタリングするモードフィルタリング機能が提供される。端末１においては、受信するフレームを自己の通信モードと送信元端末の通信モードに応じてフィルタリングする。

ここで、本実施の形態で適用される通信方式（通信モード）について説明する。１つの通信方式は間欠送受信アドホック・モードであり、第４の実施の形態で示したモードである。

さらに１つの通信方式は、スキャンレスアドホック・モードである。スキャンレスアドホック・モードにおいては、ネットワーク１０のBeaconフレームの検出による状態監視（スキャニング）を行なわずに、ブロードキャストのみによりデータ通信を行なうことを可能にする。このような通信は、本出願人により、特願２００６−３２２０８７号で提案されたものであるから、詳細は略す。

また、さらに１つの通信方式は、標準アドホック・モードである。標準アドホック・モードにおいては、両端末間で周期的にスキャニングが行なわれ、送信要求が発生すればＵＤＰ（User Datagram Protocol）に従いブロードキャストによりデータを送信する方式である。

パケットフィルタリングを行なうための通信シーケンスの概略が図３４と図３５に示される。

図３４を参照して、端末ＳＴＡ１は、標準アドホック・モードに設定されている端末からのフレームのみを受信するとのフィルタ条件が設定されていたと想定する。そして、端末ＳＴＡ１と同一の無線セルにある端末ＳＴＡ２とＳＴＡ３はスキャンレスアドホック・モードと標準アドホック・モードとにそれぞれ設定されていると想定する。この場合、端末ＳＴＡ１はフィルタ条件に従い、スキャンレスアドホック・モードにある端末ＳＴＡ２のフレームは受信することはなく、端末ＳＴＡ３からのフレームは受信する。したがって、相手側端末の通信モードに従い、当該端末からのフレームを受信するか否か（フィルタするか否か）を判断し判断結果に基づく動作を実施することができる。これにより、所望しない通信モードである端末からのフレームを選択的に受信しないように設定することができる。本実施の形態では、フィルタ条件をホストシステム１００により可変に設定するようにして、所望しないデータを受信することに係るホストシステム１００側の負荷を削減することができる。

図３５の通信シーケンスにおいて、図３４の通信モードおよびフィルタ条件を想定する。端末ＳＴＡ１、ＳＴＡ２およびＳＴＡ３はそれぞれ電源がＯＮされると通信モードの設定が行なわれる。この場合、各端末には、フィルタ条件も設定されるが、ここでは説明を簡単にするために端末ＳＴＡ１のみにフィルタ条件が設定されたと想定する。

端末ＳＴＡ１は、フィルタ条件が、“標準アドホック・モードのフレームのみ受信”を指示するように設定されているので、端末ＳＴＡ３からのBeaconフレームはフィルタされて（受信されず）、その結果、受信完了フレームなしとなる。一方、端末ＳＴＡ２からのBeaconフレームは受信されて端末ＳＴＡ１では受信完了フレームありと判定され、当該フレームのデータはコントローラＭＡＣ部２５７１によりプログラムメモリ２５４１などに一時的に格納され、その後、ホストシステム１００１に与えられる。また、このとき、コントローラＭＡＣ部２５７１により応答フレームが端末ＳＴＡ２に返信される。

その後、端末ＳＴＡ２の通信モードが、標準アドホック・モードから間欠送受信アドホック・モードに切換えられると、端末ＳＴＡ１は端末ＳＴＡ２からのBeaconフレームもフィルタすることになる。

図３４には、本実施の形態に係る通信モードが示される。通信モードが標準アドホック・モードであるとき、フレームに格納される端末の通信モードを示す値は“ＳＴＡＮＤＡＲＤ”と設定され、間欠送受信アドホック・モードであれば、“ＩＮＴＭＴ”と設定され、スキャンレスアドホック・モードであれば、“ＳＣＮＬＳ”と設定される。なお、これらの通信モードは、本実施の形態の説明のために例示するものであって、これらに限定されるものではない。

図３６には、本実施の形態における通信モードのそれぞれについて、当該通信モードを識別するMode Infoの値（５Bytes）と意味（meaning）が表形式にて示される。これらの
対応付けを指すテーブルはＲＡＭ１０３に予め格納される。

図３７には、ホストシステム１００１のＲＡＭ１０３１に格納されるデータの一例が示される。ＲＡＭ１０３１には、テーブル４００１が格納されている。テーブル４００１のデータは、端末ＳＴＡ１の設定可能な現在の通信モードのそれぞれを指すデータ４０１１に対応して、フィルタ指定データ４０２１が格納される。ここでは、たとえば現在の通信モードが“ＳＴＡＮＤＡＲＤ”（図３６参照）であれば、フィルタ指定データ４０２１として、“ＳＴＡＮＤＡＲＤ”を指すMode Infoの値を格納した端末からのフレームのみを
受信し（ＯＦＦ：フィルタしない）、他の通信モードの端末からのフレームは受信しない（ＯＮ：フィルタする）ことが示される。他の通信モード“ＩＮＴＭＴ”および“ＳＣＮＬＳ”の場合においても同様にフィルタ指定データ４０２１により、送信元の端末の通信モードに従い当該端末からのフレームをフィルタするか否かを可変に設定することができる。

また、ＲＡＭ１０３１には、現在の通信モードを示すデータ４０３１と、モードフィルタリング機能を許可するか／禁止するかを示すデータ４０４１が格納される。

端末ＳＴＡ２においても、ＲＡＭ１０３２には上述した手順にて、図３７に示す内容のテーブル４００１に対応のテーブル４００２、データ４０３１に対応のデータ４０３２およびデータ４０４１に対応のデータ４０４２が格納される。

図３７に示すデータは、入力部１０６１（１０６２）を介した操作によりユーザが所望するように変更することができ、または、ホストシステム１００１（１００２）において実行されるべきアプリケーションに従いＣＰＵ１０１１（１０１２）により変更すること
もできる。

図３８には、端末ＳＴＡ１の通信回路２００１の共有メモリ２５５１に格納されるデータの一例が示される。図３８を参照して、共有メモリ２５５１には、ホストシステム１００１から受信したフィルタ条件データ２７１１と、フィルタ機能を許可するか／禁止するかを示すデータ２７２１が格納される。端末ＳＴＡ２の通信回路２００２の共有メモリ２５５２にも、図３８で説明したようなフィルタ条件データ２７１２およびデータ２７２２がホストシステム１００２から受信した内容に従い格納される。

共有メモリ２５５１（２５５２）のデータは、対応するホストシステム１００１（１００２）のＲＡＭ１０３１（１０３２）から読出されて与えられるデータをＣＰＵ２５１１（２５１２）が入力し、これを共有メモリ２５５１（２５５２）に書込むことにより、設定・更新される。

図３９〜図４２には、本実施の形態に係るフレームの構成例が示される。図３９を参照し、本実施の形態では、本来は通信のための管理情報を送信するためのBeaconフレームを利用して、ユーザが定義する情報である通信モード情報（Mode Infoの値）を送信する。
具体的には、Beaconフレーム３００のフレーム・ボディ部３２０の領域においてビーコン・フレーム・ボディ部３２１、拡張タグ３２５および拡張情報３２６を含むようにしている。拡張タグ３２５は、規格として常時格納されるフラグを指す。拡張情報３２６は、本実施の形態においては当該Beaconフレーム送信元の端末の現在の通信モードを指す通信モード情報（Mode Infoの値）３２７を含む。

図４０には、端末１が標準アドホック・モードであるときに送信するBeaconフレーム３００が示される。図４０を参照して、通信モード情報３２７は“ＳＴＡＮＤＡＲＤ”を指す。また、間欠送受信アドホック・モードであるときには図４１のBeaconフレーム３００のように通信モード情報３２７は“ＩＮＴＭＴ”を指す。また、スキャンレスアドホック・モードであるときには図４２のBeaconフレーム３００のように通信モード情報３２７は“ＳＣＮＬＳ”を指す。

図４０〜図４２のBeaconフレーム３００のＤＡデータ３１１はブロードキャストの宛先を指す。

図４３、図４４および図４５のフローチャートを参照して、図３５のシーケンスに従い端末ＳＴＡ１とＳＴＡ２の間で通信が行なわれる場合を説明する。ここでは、説明を簡単にするために端末ＳＴＡ３との通信は想定しない。なお、ＲＡＭ１０３１（１０３２）にはテーブル４００１（４００２）が予め格納されていると想定する。

図４３を参照し、端末ＳＴＡ１のホストシステム１００１では、ステップＳＫ１０において、たとえば入力部１０６１を介してユーザが通信モードの種類を入力する。入力される通信モードの種類は、ユーザが実行を所望するアプリケーションプログラムの種類に応じてＣＰＵ１０１１により検出される場合もある。入力された通信モードは、“ＳＴＡＲＤＡＲＤ”であり、ＲＡＭ１０３１にデータ４０３１として格納される。

次に、ステップＳＫ１３とＳＫ１７において、ユーザは入力部１０６１を介してフィルタ機能の許可／禁止の指示とフィルタ条件とを入力しＲＡＭ１０３１に格納する。ここでは、入力されたフィルタ機能の許可／禁止の指示は、データ４０４１としてＣＰＵ１０１１によりＲＡＭ１０３１に格納される。

ここで、フィルタ条件についてはユーザが入力部１０６１を操作して入力するとしたが
、次のようにしてもよい。つまり、ＣＰＵ１０１１は入力されて格納されたデータ４０３１に基づきテーブル４００１を検索して、データ４０３１が指示する通信モード４０１１に対応するフィルタ指定データ４０２１をフィルタ条件データとして読出して取得してもよい。

ステップＳＫ２０では、ＣＰＵ１０１１は、入力または取得されたフィルタ条件データおよびフィルタ許可／禁止のデータ４０４１を、通信回路２００１に送信する。

端末ＳＴＡ１の通信回路２００１においては、ＣＰＵ２５１１は、ステップＳＫ２３において、ホストシステム１００１側からの受信があるか否かを検出する。何らかの受信を検知すると（ステップＳＫ２３でＹＥＳ）、ステップＳＫ２６において、ホストシステム１００１からの受信内容（フィルタ条件データおよびフィルタ許可／禁止のデータ４０４１）を、共有メモリ２５５１にフィルタ条件データ２７１１およびデータ２７２１として格納する。

端末ＳＴＡ２側においては、電源ＯＮされた後、図４４に従う処理が行なわれる。まず、ステップＳＪ１０において、端末ＳＴＡ２のホストシステム１００２においては、ＣＰＵ１０１２は、入力部１０６２を介して、ユーザにより通信モードが入力される。または、ＣＰＵ１０１２により、実行されるべきアプリケーションプログラムの種類に従い、通信モードが判別される。このようにして入力、または判別された通信モードの種類はＲＡＭ１０３２にデータ４０３２として格納される。端末ＳＴＡ２においても、端末ＳＴＡ１と同様にフィルタ機能の許可／禁止を指すデータ４０４２およびフィルタ条件データの設定とＲＡＭ１０３２および共有メモリ２５２２への格納（フィルタ条件データ２７１２とデータ２７２２の格納）が行なわれる。

次に、ＣＰＵ１０１２は、ステップＳＪ１２において入力部１０６２を介してファイル送信のための操作がなされたか否かを判別する。ファイル送信操作があったと判別されると（ステップＳＪ１２でＹＥＳ）、ＣＰＵ１０１２は、ステップＳＪ１５、ＳＪ１７において、送信ファイルのデータと、Beaconフレーム送信指示と、ＲＡＭ１０３２から読出した現在の通信モードのデータ４０３２を、通信回路２００２に与える。ここでは送信されるべきファイルのデータは、図４０〜図４２のBeaconフレームの拡張情報３２６を構成するものであり、ファイルは１個のBeaconフレームにより送信完了するようなデータ量であると想定する。

通信回路２００２においては、ＣＰＵ２５１２は、ステップＳＪ２３において、ホストシステム１００２からステップＳＪ１７において送信されたデータ・指示を受信するか否かを判定している。

データ・指示を受信したと判定すると（ステップＳＪ２３でＹＥＳ）、ステップＳＪ２６、ＳＪ２９において、指示に基づきBeaconフレームがコントローラＭＡＣ部２５７２により生成されてネットワーク１０に送信される。

コントローラＭＡＣ部２５７２は、ビーコンフレーム送信指示が与えられると、入力したファイルのデータと通信モードのデータ４０３２とに基づき、図４０、図４１および図４２のうちのいずれかのBeaconフレーム３００を生成する。たとえば、データ４０３２が“ＳＴＡＮＤＡＲＤ”を指示すれば、図４０のBeaconフレーム３００が生成され、同様に“ＩＮＴＭＴ”を指示すれば図４１のBeaconフレーム３００が生成され、同様に“ＳＣＮＬＳ”を指示すれば図４２のBeaconフレーム３００が生成される。生成されるBeaconフレーム３００の拡張情報３２６はホストシステム１００２から受信した送信ファイルのデータを含む。

ここでは、端末ＳＴＡ１では、データ４０３１とデータ４０４１（２７２１）は、標準アドホック・モード（“ＳＴＡＮＤＡＲＤ”）および“フィルタ機能を許可”をそれぞれ指し、端末ＳＴＡ２では、データ４０３２とデータ４０４２（２７２２）は、標準アドホック・モード（“ＳＴＡＮＤＡＲＤ”）および“フィルタ機能を許可”にそれぞれ設定されていると想定する。

図４５を参照して、受信側の端末ＳＴＡ１の処理について説明する。端末ＳＴＡ１の通信回路２００１の共有メモリ２５５１においては、図３８に示すようなフィルタ条件のデータ２７１１が格納されていると想定する。

ステップＳＬ１０では、ネットワーク１０から何らかのフレームを受信するか否かを判定している。フレームを受信すると、受信したフレームは、コントロールＭＡＣ部２５７１により、そのフレーム・ボディ部３２０のみが取出されて、プログラムメモリ２５４１に一時的に格納される。

ＣＰＵ２５１１は、ステップＳＬ１２において、共有メモリ２５５１のデータ２７２１に基づきフィルタ機能を許可するか否かを判断する。ここではフィルタ機能を許可すると判断されて（ステップＳＬ１２でＹＥＳ）、処理はステップＳＬ１３に移行する。許可しない（禁止）と判断されると（ステップＳＬ１２でＮＯ）、全てのフレームを受信するので処理はステップＳＬ５３に移行する。ステップＳＬ５３の処理においては、受信したフレームのデータをプログラムメモリ２５４１から読出し、インターフェイス２５２１を介してホストシステム１００１へ送信するための動作がなされる。

ステップＳＬ１３では、ＣＰＵ２５１１は、プログラムメモリ２５４１に格納されたフレーム・ボディ部３２０の通信モード情報３２７と、共有メモリ２５５１のフィルタ条件データ２７２１を読出す。その後、読出した両方の情報を照合してフィルタ機能の処理を行う。

ステップＳＬ１６では、ＣＰＵ２５１１は、通信モード情報３２７が標準アドホック・モード（“ＳＴＡＮＤＡＲＤ”）を指示しているか否かを判定する。指示していると判定したならば（ステップＳＬ１６でＹＥＳ）、ステップＳＬ１９において、フィルタ指定データ２７１１に基づき、標準アドホック・モードの端末からのデータをフィルタするか否かを判定する。ここでは、図３８に示されるように、標準アドホック・モードのデータはフィルタしない（“ＯＦＦ”）と判定するので（ステップＳＬ１９でＮＯ）、当該データはプログラムメモリ２５４１において、その後に、ホストシステム１００１側へ送信されるまで格納される。

一方、標準アドホック・モードをフィルタすると判定した場合には（ステップＳＬ１９でＹＥＳ）、ステップＳＬ４３において、ＣＰＵ２５１１はプログラムメモリ２５４１に一時的に格納された受信データを削除して受信を終了する（受信完了フレームなし）。これにより、受信フレームのデータは廃棄される。

ステップＳＬ１６に戻り、標準アドホック・モードを指示していないと判定されると（ステップＳＬ１６でＮＯ）、ステップＳＬ２７、ＳＬ３０において、通信モード情報３２７は、間欠送受信アドホック・モード（“ＩＮＴＭＴ”）および“スキャンレスアドホック・モード（“ＳＣＮＬＳ”）のいずれを示すかが判定される。

いずれも示さないと判定されると（ステップＳＬ２７でＮＯ、ＳＬ３０でＮＯ）、ステップＳＬ３３において、ＣＰＵ２５１１は当該フレームのデータは適切でないと検出して
、プログラムメモリ２５４に一時的に格納されたフレーム・ボディデータを削除する。これにより、受信フレームのデータは廃棄される。

一方、通信モード情報３２７が“ＩＮＴＭＴ”を指示していると判定されると（ステップＳＬ２７でＹＥＳ）、ＣＰＵ２５１１は、ステップＳＬ３６において、フィルタ指定データ２７１１に基づき、間欠送受信アドホック・モードのデータをフィルタするか否かを判定する。ここでは、図３８のデータ２７１１に示されるように、間欠送受信アドホック・モード（“ＩＮＴＭＴ”）のデータはフィルタすることが指定されているので、フィルタすると判定されて（ステップＳＬ３６でＹＥＳ）、ステップＳＬ４３において、受信完了フレームのない状態で、受信終了する。一方、フィルタしないと判定されると（ステップＳＬ３６でＮＯ）、ステップＳＬ３９、ＳＬ５３において、プログラムメモリ２５４１に一時的に格納されているデータは、その後にホストシステム１００１側へ送信されるまで格納され続ける（受信完了フレームあり）。

ステップＳＬ３０において、通信モード情報３２７は“ＳＣＮＬＳ”を指示していると判定されると（ステップＳＬ３０でＹＥＳ）、ＣＰＵ２５１１は、ステップＳＬ４６において、データ２７１１に基づき、スキャンレスアドホック・モードのデータをフィルタするか否かを判定する。図３８の場合、スキャンレスアドホック・モードのデータはフィルタすると指定されているので、フィルタすると判定されて（ステップＳＬ４６でＹＥＳ）、前述したステップＳＬ４３以降の処理が行なわれる。一方、フィルタしないと判定されると（ステップＳＬ４６でＮＯ）、ステップＳＬ４９、ＳＬ５３において、プログラムメモリ２５４１に一時的に格納されているデータは、その後にホストシステム１００１側へ送信されるまで格納され続ける（受信完了フレームあり）。

以上のように本実施の形態によれば、無線ＬＡＮの管理用のフレームを用いて、ユーザ定義の端末の通信モードの送信と、当該通信モードの種類に従うフレームフィルタリングが可能となる。ここでは、ユーザ定義情報とした端末の通信モードを挙げたが、端末の他の種類の属性であってもよく、そのたの属性に従うフィルタリングであってもよい。

本実施の形態のフィルタリングによれば、管理フレーム（Beaconフレーム）を利用してユーザ定義情報を通信するので、ユーザ定義情報を送受信するための特別なフレームを用いる場合に比較して、ネットワーク１０を介して通信されるフレーム量を削減できて通信効率を向上させることができる。

また、ユーザ定義情報に従い所望される属性の端末からのBeaconフレーム３００のみを選択的に受信する機能を実現できる。これらの機能を備えることにより、ホストシステム１００を含む端末１で構成される無線ＬＡＮ機器の付加価値を高めることができる。

今回開示された各実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。また、各実施の形態に開示された技術は、可能な限り組み合わされて実現されることが意図される。

本発明の無線通信ネットワークの第１の実施の形態であるアドホック・ネットワークの構成の一例を模式的に示す図である。 図１の端末のハードウェア構成を模式的に示す図である。 図１のネットワークにおいて送受信されるフレーム（Beaconフレーム）の構成を模式的に示す図である。 図１のネットワークにおいてフレームを送信する際に図１の端末のホストシステム側で実行される処理のフローチャートである。 図１のネットワークにおいてフレームを送信する際に図１の端末の通信回路側で実行される処理のフローチャートである。 図１のネットワークにおいてフレームを受信する際に図１の端末の通信回路側で実行される処理のフローチャートである。 図４の処理の変形例のフローチャートである。 図５の処理の変形例のフローチャートである。 本発明の無線通信ネットワークの第２の実施の形態において、端末間で接続が確立される際の情報のやり取りを説明するための図である。 図９の無線通信ネットワークを構成する端末のホストシステムのＣＰＵが実行する処理のフローチャートである。 図９の無線通信ネットワークを構成する端末の通信回路のＣＰＵが実行する処理のフローチャートである。 図１０の処理の変形例のフローチャートである。 図１１の処理の変形例のフローチャートである。 第３の実施の形態に係る端末の構成図である。 第３の実施の形態に係る端末の構成図である。 第３の実施の形態に係るＮｏ ＦＣＳの通信シーケンスを模式的に示す図である。 第３の実施の形態に係る通信処理のフローチャートである。 第３の実施の形態に係る通信処理のフローチャートである。 第３の実施の形態に係る通信フレームの構成を模式的に示す図である。 第３の実施の形態に係る通信フレームの構成を模式的に示す図である。 第３の実施の形態に係る通信回路側のメモリの内容例を示す図である。 第３の実施の形態に係るホストシステム側のメモリの内容例を示す図である。 第４の実施の形態に係る間欠送受信アドホック・モードのシーケンスを模式的に示す図である。 （Ａ）〜（Ｄ）は、第４の実施の形態に係るフレームの一例を示す図である。 第４の実施の形態に係る間欠送受信アドホック・モードの通信手順を模式的に説明する図である。 第４の実施の形態に係る間欠送受信アドホック・モードの通信手順を模式的に説明する図である。 第４の実施の形態に係るシステム状態遷移モデルを示す図である。 第４の実施の形態に係る各種パラメータを説明する図である。 第４の実施の形態に係る間欠周期の設定機能を説明する図である。 第４の実施の形態に係る間欠周期の調整機能を説明する図である。 第４の実施の形態に係る間欠周期の調整機能を説明する図である。 第４の実施の形態に係る待機期間の処理フローチャートである。 第４の実施の形態に係るウェイク期間の処理フローチャートである。 第５の実施の形態に係る通信の概念を模式的に示す図である。 第５の実施の形態に係る通信シーケンスを模式的に示す図である。 第５の実施の形態に係る通信モード情報とその意味を説明する図である。 第５の実施の形態に係るホストシステム側の記憶内容の一例を示す図である。 第５の実施の形態に係る通信回路側の記憶内容の一例を示す図である。 第５の実施の形態に係るフレームの概略構成例を示す図である。 第５の実施の形態に係るフレームの一例を示す図である。 第５の実施の形態に係るフレームの他の例を示す図である。 第５の実施の形態に係るフレームのさらなる他の例を説明する図である。 第５の実施の形態に係る受信側端末の処理フローチャートである。 第５の実施の形態に係る送信側端末の処理フローチャートである。 第５の実施の形態に係るフレームフィルタリングの処理フローチャートである。 従来のＦＣＳエラーチェックを行なう通信シーケンスを模式的に示す図である。

符号の説明

１〜４ 端末、１０ ネットワーク、１１，１２ 無線セル、１００ ホストシステム、１０１，２５１ ＣＰＵ、１０２ ＨＤ、１０３ ＲＡＭ、１０４ ディスプレイ、１０５ スピーカ、１０６ 入力部、１０７，２５２ インターフェイス、２００ 通信回路、２０１ 電源回路、２０２ クロック回路、２０３ アンテナ、２０４ バラン、２０５ ＲＦ回路、２０６，２０７ ＥＥＰＲＯＭ、２５０ ベースバンド／ＭＡＣ回路、２５３ 外部バスコントローラ、２５４ プログラムメモリ、２５５ 共有メモリ、２５６ タイマ、２５７ コントロールＭＡＣ部、２５８ ＡＤＣ、２５９ ＤＡＣ、２８０
待機期間データ、２８１ ウェイク期間データ、２８２ ＭＡＸ待機回数データ、２８３ カウント待機回数データ、２８４ デフォルト待機期間データ、３００ フレーム、３４０ Ｎｏ ＦＣＳ通知のデータ、３２７ 通信モード情報、３２２１ Ａ／Ｖデータ、４００１（４００２） テーブル、４０３１（４０３２） 現在の通信モードのデータ、４０４１（４０４２）フィルタ許可／禁止のデータ。

Claims (12)

1. 外部から送信されたフレームを受信する受信部と、
   誤り訂正を行なう際は、前記受信部により受信した前記フレーム中のデータに対して前記フレーム中の訂正情報に従い誤り訂正した後に前記データを出力し、誤り訂正を行なわない際は、前記受信部により受信した前記フレーム中のデータに対して誤り訂正を行わずに前記データを出力する訂正処理手段と、
   前記訂正処理手段に対して誤り訂正を行なわせるか否かを決定する訂正検知手段とを備える、情報通信端末。
2. 前記訂正検知手段は、前記データ受信手段が前記フレームを受信する毎に、訂正可否データに基づき前記誤り訂正を行うか否かを検知し、前記誤り訂正を行なうと検知したときは、当該受信フレームのデータについて前記訂正処理手段による誤り訂正を行なわせる、請求項１に記載の情報通信端末。
3. 前記訂正可否データは、設定変更可能である、請求項１または２に記載の情報通信端末。
4. 前記受信部は、
   他の前記情報通信端末から送信された誤り訂正可否の通知を受信する訂正可否受信手段を含み、
   前記訂正可否データは、前記訂正可否受信手段が予め受信した前記誤り訂正可否の通知を指す、請求項１から３のいずれか１項に記載の情報通信端末。
5. 無線ネットワークを介して通信する情報通信端末であって、
   他の前記情報通信端末から送信されたフレームを受信する受信部と、
   前記受信部により受信した前記フレーム中のデータを入力して処理する処理部と、を備え、
   前記受信部は、
   他の前記情報通信端末から前記データと誤り訂正のための訂正情報とを格納したフレームを受信するデータ受信手段と、
   前記データ受信手段が受信した前記フレーム中の前記データを、当該フレーム中の前記訂正情報に従い誤り訂正した後に、当該データを前記処理部に出力する訂正処理手段と、
   前記データ受信手段が前記フレームを受信する毎に、予め設定された訂正可否データに基づき前記誤り訂正を行うか否か検知し、前記誤り訂正を行なわないと検知したときは、前記訂正処理手段による誤り訂正を省略して、前記データ受信手段が受信した前記フレーム中の前記データを前記処理部に出力する訂正検知手段とを含む、情報通信端末。
6. 前記訂正検知手段は、
   前記データ受信手段が前記フレームを受信する毎に、前記訂正可否データに基づき前記誤り訂正を行うか否か検知し、前記誤り訂正を行なうと検知したときは、当該受信フレームのデータについて前記訂正処理手段による誤り訂正を行なわせる、請求項５に記載の情報通信端末。
7. 前記訂正可否データは、設定変更可能である、請求項５または６に記載の情報通信端末。
8. 前記受信部は、さらに、
   前記他の情報通信端末から送信された誤り訂正可否の通知を受信する訂正可否受信手段を含み、
   前記訂正可否データは、前記訂正可否受信手段が予め受信した前記誤り訂正可否の通知を指す、請求項５から７のいずれか１項に記載の情報通信端末。
9. 前記データは、非圧縮のオーディオデータまたはビジュアルデータを指す、請求項５から８のいずれか１項に記載の情報通信端末。
10. 前記無線ネットワークは、アドホック通信ネットワークである、請求項５から９のいずれか１項に記載の情報通信端末。
11. 無線ネットワークを介して通信し、且つ処理部を有した情報通信端末に搭載される無線通信装置であって、
    他の前記情報通信端末から送信されたフレームを受信し、受信したフレーム中のデータを前記情報通信端末の前記処理部に出力するする受信部を備え、
    前記受信部は、
    他の前記情報通信端末から前記データと誤り訂正のための訂正情報とを格納したフレームを受信するデータ受信手段と、
    前記データ受信手段が受信した前記フレーム中の前記データを、当該フレーム中の前記訂正情報に従い誤り訂正した後に、当該データを前記処理部に出力する訂正処理手段と、
    前記データ受信手段が前記フレームを受信する毎に、予め設定された訂正可否データに基づき前記誤り訂正を行うか否か検知し、前記誤り訂正を行なわないと検知したときは、前記訂正処理手段による誤り訂正を省略して、前記データ受信手段が受信した前記フレーム中の前記データを前記処理部に出力する訂正検知手段とを含む、無線通信装置。
12. 第１の情報通信端末と、前記第１の情報通信端末によって送信されたデータを受信する第２の情報通信端末とを備える無線通信ネットワークであって、
    前記第１の情報通信端末は、
    データと誤り訂正のための訂正情報とを格納したフレームを送信するデータ送信手段を含み、
    前記第２の情報通信端末は、
    前記第１の情報通信端末の前記データ送信手段から送信されたフレームを受信する受信部と、
    前記受信部により受信した前記フレーム中のデータを入力して処理する処理部と、を含み、
    前記受信部は、
    前記第１の情報通信端末の前記データ送信手段により送信された前記フレームを受信するデータ受信手段と、
    前記データ受信手段が受信した前記フレーム中の前記データを、当該フレーム中の前記訂正情報に従い誤り訂正した後に、当該データを前記処理部に出力する訂正処理手段と、
    前記データ受信手段が前記フレームを受信する毎に、予め設定された訂正可否データに基づき前記誤り訂正を行うか否か検知し、前記誤り訂正を行なわないと検知したときは、前記訂正処理手段による誤り訂正を省略して、前記データ受信手段が受信した前記フレーム中の前記データを前記処理部に出力する訂正検知手段とを有する、無線通信ネットワーク。

Images