JP4029804B2 - ネットワーク装置、および送信出力レベル変更方法 - Google Patents

Description

本発明は、無線でデータ通信を行うネットワーク装置、および送信出力レベル変更方法に関する。

近年、無線ＬＡＮ(Local Area Network)方式が広く普及しつつある。
この種の無線ＬＡＮ方式の場合、限られた数の無線チャネルを複数のノードが共用するので、ノードの増加に伴って通信条件は厳しくなる。具体的には、第１に、キャリアセンスにおいて無線チャネルの空きを検出できないケースが増え、第２に、同時送信による混信が発生するケースが増えると考えられる。

より詳しく説明すると、ノード間で無線通信を開始する場合、送信側のノードは、データの送信を行う前に、使用したいチャネルの電波を受信し、他のノードからの電波が出ているかどうかをチェックする。この処理をキャリアセンスと呼ぶ。このキャリアセンスの結果、他のノードからの電波が出ていない場合には、その無線チャネルが空いていると判断して、送信対象となるデータの送信を開始するが、他のノードからの電波が出ている場合は、その無線チャネルが使われていると判断して、データ送信ができる状態になるまで待機することになる。同じ無線チャネルを使うノードが増えた場合、無線チャネルが使われている確率は高くなるので、データ送信ができる状態になるまで待機することになる確率も高くなり、スループットが低下するという問題を招く。

また、同じ無線チャネルを使うノードが増えた場合、上記のようなキャリアセンスを、２以上のノードがほぼ同時に実施する確率も高くなる。この場合、それらのノードすべてが、無線チャネルが空いていると判断するため、ほぼ同時にデータの送信を開始してしまい、混信が発生してしまう。このような混信が発生すると、直接的には、データエラーが発生するという問題を招く。また、このようなデータエラーを検出した場合に、データの再送処理を実施してエラーを回復する仕組みは実装されているが、そのような再送処理の発生に伴ってスループットが低下するという問題を招く。

こうした問題を緩和するための一手段としては、従来、受信感度を動的に変化させる技術が採用されている。すなわち、弱い電波しか到来しない場合には受信感度を高くする一方、強い電波が到来する場合には受信感度を低くし、これにより、強い電波と弱い電波とが同時に到来するような環境下では、強い電波だけを選択的に受信するという技術である。

この技術を採用すれば、キャリアセンスを行った際に、通信対象外のノードから弱い電波が出ていたとしても、通信対象となるノードからの電波が強ければ、自ノードの受信感度は低くなり、その結果、通信対象となるノードからの電波だけを選択的に受信する状態になる。したがって、通信対象外のノードからの弱い電波が原因で、その無線チャネルが使われていると判断してしまうことはなくなるので、データ送信ができる状態になるまで待機する確率も相応に低くなり、スループットの低下は発生しにくくなる。

また、上記のようなキャリアセンスを、２以上のノードがほぼ同時に実施し、同時にデータの送信を開始したとしても、通信対象となるノードの電波が強く、通信対象外のノードの電波が弱ければ、自ノードの受信感度は低くなり、その結果、通信対象となるノードからの電波だけを選択的に受信する状態になる。したがって、混信が発生してしまうことはなくなり、それに伴うデータエラーや、データの再送処理等に伴うスループットの低下などは、発生しにくくなる。

つまり、上記のように受信感度を動的に変化させる技術を採用していれば、強い電波を優先的に受信することができるので、弱い電波が存在することによる悪影響を排除できるのである。

ところで、上記のように受信感度を動的に変化させた場合、電波が強いほど優先的に受信されることになるので、自ノードと他ノードとの間における通信状態を良好にすることだけを考えるのであれば、それらの間の電波は強いほどよいことになる。しかし、むやみに強い電波を出すだけでは、他ノードと他ノードとの通信を妨げてしまうおそれがある。逆に、他ノードと他ノードとの通信を妨げないようにするだけであれば、自ノードと他ノードとの間の電波を弱くすればよいが、それでは、自ノードと他ノードとの間の通信が途切れるなどの障害が発生しやすくなるという問題がある。

このような問題に対し、例えば、下記特許文献１には、送信機側の送信出力に関する情報を送信機から受信機へ送信するとともに、受信機側が要求する送信機側における送信出力レベルを受信機から送信機へとフィードバックし、送信機側の送信出力レベルを過大にしたり過小にしたりすることなく、これら送信機および受信機が最適な状態で送受信を行うことができるようにする技術が記載されている。
特開平７−８７０９３号公報

しかしながら、上記特許文献１に記載の方式を採用する場合、送信機側および受信機側の双方において専用の電力制御用プロトコルをサポートしている必要があり、いずれか一方が上記電力制御用プロトコルをサポートしていても、他方が上記電力制御用プロトコルをサポートしていなければ、送信出力の適正化を図ることができなかった。

また、ノード間でやりとりされるデータの中には、比較的重要度の高いデータもあれば、比較的重要度の低いデータもあるが、従来は、これらを特に区別することなく同じ送信出力レベルで送信していた。あるいは、ノード間でやりとりされるデータの中には、比較的再送信しやすいデータ（何度でも送信できるデータやデータ量が少ないデータ）もあれば、比較的再送信しにくいデータ（１度しか送信できないデータやデータ量が多いデータ）もあるが、従来は、これらを特に区別することなく同じ送信出力レベルで送信していた。

そのため、あるノード間で比較的重要度の高いデータや比較的再送信しにくいデータの送受信を行いたい状況にあっても、その近くにあるノードが比較的重要度の低いデータや比較的再送信しやすいデータを送信していると、比較的重要度の高いデータや比較的再送信しにくいデータの送受信を妨害してしまい、データエラーを引き起こしたり、スループットの低下を招いたりするという問題があった。この場合、比較的重要度の低いデータや比較的再送信しやすいデータについては、データエラーが大きな問題とならないこともあるし、必要があれば再送信も容易である。しかし、比較的重要度の高いデータや比較的再送信しにくいデータについては、データエラーが大きな問題となることがあり、再送信による対処ができないこともあった。

本発明は、上記問題を解決するためになされたものであり、その目的は、送信機側において採用するだけでも通信環境を改善可能で、比較的重要度が高いデータや比較的再送信しにくいデータなどを優先的に送受信させやすいネットワーク装置を提供することにある。

以下、上記目的を達成するためになされた本発明の特徴について詳述する。
請求項１に記載のネットワーク装置は、無線にてデータを送信可能で、データ送信時の送信出力レベルを２通り以上に変更可能なデータ送信手段と、複数のデータ送信用プロトコルの中から選ばれる一つのプロトコルに従って、前記送信対象データを処理するデータ処理手段と、該データ処理手段によって処理された前記送信対象データを、該送信対象データに付加された前記送信出力レベルを示す出力レベル情報に基づいて前記送信出力レベルを変更した上で送信するように、前記データ送信手段を制御する送信制御手段とを備え、前記データ処理手段は、アプリケーション、ソケットインターフェース、およびプロトコルスタックの各階層をなすソフトウェア群から構成されるとともに、前記アプリケーションから前記ソケットインターフェース、前記プロトコルスタックを通して、前記送信制御手段である前記ドライバへとデータを伝送すると、該ドライバが前記データ送信手段を制御して、前記送信対象データを送信させるように構成されており、前記アプリケーションは、前記送信出力レベルを指定するとともに、前記ソケットインターフェースの階層へ前記送信対象データを伝送し、前記ソケットインターフェースの階層で、前記指定された送信出力レベルを示す前記出力レベル情報を前記送信対象データに対して付加することを特徴とする。
請求項２に記載のネットワーク装置は、請求項１に記載のネットワーク装置において、前記アプリケーションは、前記送信対象データを処理した前記一のプロトコルに基づいて、前記送信出力レベルを指定することを特徴とする。
請求項３に記載の送信出力レベル変更方法は、アプリケーション、ソケットインターフェース、プロトコルスタック、およびドライバの各階層をなすソフトウェア群を備えたネットワーク装置が、送信対象データに対して付加されたデータ送信時の送信出力レベルを示す出力レベル情報に基づき、無線にて該送信対象データを送信する際の送信出力レベルを変更する方法であって、前記アプリケーションが、前記送信出力レベルを指定するとともに、前記ソケットインターフェースの階層へ前記送信対象データを伝送し、前記ソケットインターフェースの階層で、前記指定された送信出力レベルを示す前記出力レベル情報を前記送信対象データに対して付加し、前記出力レベル情報が付加された送信対象データを、前記プロトコルスタックを通して、前記ドライバへと伝送し、前記ドライバは、前記送信対象データに付加された出力レベル情報に基づいて前記送信出力レベルを変更することを特徴とする。
請求項４に記載の送信出力レベル変更方法は、請求項３に記載の送信出力レベル変更方法において、前記アプリケーションは、前記送信対象データを処理したプロトコルに基づいて、前記送信出力レベルを指定することを特徴とする。
以上のような構成を採用した本発明においては、アプリケーションのレベルで送信出力レベルが指定されるので、アプリケーションよりも下位の層において送信出力レベルの判断をしなくてもよくなり、アプリケーションのレベルで指定された送信出力レベルに基づき、比較的重要度が高いデータを優先的に送受信することができるようになる。
次に、本発明に関連する参考技術の構成について説明する。
以下に説明するネットワーク装置は、
無線にてデータを送信可能で、データ送信時の送信出力レベルを２通り以上に変更可能なデータ送信手段と、
複数のデータ送信用プロトコルの中から選ばれる一つのプロトコルに従って、前記送信対象データを処理するデータ処理手段と、
該データ処理手段によって処理された前記送信対象データを、前記一つのプロトコルに対応づけられた送信出力レベルで送信するように、前記データ送信手段を制御する送信制御手段と
を備えたことを特徴とする。

このネットワーク装置においては、複数のデータ送信用プロトコルのそれぞれについて、各プロトコル毎に送信出力レベルが設定され、データ処理手段が、複数のデータ送信用プロトコルの中から選ばれる一つのプロトコルに従って送信対象データを処理した場合、送信制御手段が、前記一つのプロトコルに対応づけられた送信出力レベルで送信対象データを送信するように、データ送信手段を制御する。

より具体的な例を挙げれば、例えば、データ送信手段が、データ送信時の送信出力レベルを「高」、「低」の２通りに変更可能で、データ送信時に用いるプロトコルとして、比較的重要度の高いデータ（あるいは比較的再送信しにくいデータ）を送信する時に利用するプロトコルＡ、比較的重要度の低いデータ（あるいは比較的再送信しやすいデータ）を送信する時に利用するプロトコルＢがある場合、これらプロトコルＡ，Ｂに応じて、プロトコルＡ＝送信出力レベル「高」、プロトコルＢ＝送信出力レベル「低」といった具合に、あらかじめ各プロトコル毎に送信出力レベルが設定される。そして、データ処理手段が、プロトコルＡに従って送信対象データを処理した場合、送信制御手段は、プロトコルＡに対応づけられた送信出力レベル「高」で送信対象データを送信するように、データ送信手段を制御する。また、データ処理手段が、プロトコルＢに従って送信対象データを処理した場合、送信制御手段は、プロトコルＢに対応づけられた送信出力レベル「低」で送信対象データを送信するように、データ送信手段を制御する。

このようにすれば、あるノード間で比較的重要度の高いデータ（あるいは比較的再送信しにくいデータ）の送受信を行いたい状況にある場合、その近くにあるノードが比較的重要度の低いデータ（あるいは比較的再送信しやすいデータ）を送信しても、比較的重要度の高いデータ（あるいは比較的再送信しにくいデータ）の送受信を妨害してしまう可能性は低くなる。もちろん、比較的重要度の低いデータ（あるいは比較的再送信しやすいデータ）の送受信については、その近くにあるノードが比較的重要度の高いデータ（あるいは比較的再送信しにくいデータ）を送信することで、通信が妨害される可能性は相応に高くなるが、比較的重要度の低いデータ（あるいは比較的再送信しやすいデータ）については、データエラーが大きな問題とならないことも多く、必要があれば再送信も容易である。

したがって、このようなネットワーク装置であれば、比較的重要度が高いデータや比較的再送信しにくいデータなどを優先的に送受信させることができるようになる。また、上記特許文献１に記載の装置とは異なり、受信機側とのやり取りをして送信出力レベルを調節するものではないので、送信機側において採用するだけでも通信環境を改善することができ、既存の無線ネットワークシステムへの導入も容易である。

なお、このネットワーク装置において、データ送信時の送信出力レベルは、２通りに限らず、さらに多段階に変更可能であってもよく、この場合、より多くのプロトコルについて、きめ細かく送信出力レベルを対応づけることができる。

また、いくつかのデータ送信用プロトコルは、あらかじめ決められた特定の送信先ポート番号に宛ててデータ（パケット）を送信することになり、また、その送信先からの返信については、送信先であったポートが送信元となることから、特定の送信元ポート番号からデータ（パケット）を送信することになるので、前記送信制御手段は、前記送信対象データに付随する送信先または送信元ポート番号に基づいて、該送信先または送信元ポート番号を利用する前記一つのプロトコルに対応づけられた送信出力レベルで前記送信対象データを送信するように、前記データ送信手段を制御するように構成するとよい。

この場合、前記データ処理手段が、前記送信対象データに対して、送信先または送信元ポート番号を付加するポート番号付加手段を備えていてもよい。
また、特定のプロトコルに対応する送信先または送信元ポート番号が不変である場合もあれば、特定のプロトコルに対応する送信先ポート番号が、事前にノード間でのデータ通信を行うことにより、送信先となるノードから通知されることもあるが、後者の場合は、前記送信先ポート番号を送信先から動的に取得する送信先ポート番号取得手段を備えており、前記送信制御手段が、前記送信先ポート番号取得手段によって取得された前記送信先ポート番号を利用するプロトコルに対応づけられた送信出力レベルで前記送信対象データを送信するように、前記データ送信手段を制御するように構成されているとよい。

また、送信出力レベルを変更する対象となるプロトコルは、様々なものを考え得るが、いくつか具体例を挙げれば、例えば、前記送信制御手段が、ＴＣＰ／ＵＤＰのそれぞれに対応づけられた送信出力レベルで前記送信対象データを送信するように、前記データ送信手段を制御するように構成されているとよい。

より詳しく説明すると、ＴＣＰ（Transmission Control Protocol）は、データ送信時のエラーの有無をチェックしてエラーがあれば再送を行う等の対処を行うため、比較的重要度の高いデータを送信する際に用いられることが多い。一方、ＵＤＰ（User Datagram Protocol）は、データ送信時のエラーの有無をチェックしないため、いくらかエラーがあっても許容されるような、比較的重要度の低いデータを送信する際に用いられることが多い。したがって、この場合は、例えば、ＴＣＰ＝送信出力レベル「高」、ＵＤＰ＝送信出力レベル「低」といった具合に送信出力レベルが設定され、送信制御手段は、ＴＣＰ／ＵＤＰのそれぞれに対応づけられた送信出力レベルで送信対象データを送信するように、データ送信手段を制御する。

このようにすれば、あるノード間でＴＣＰを用いるデータ送信を行いたい状況にある場合、その近くにあるノードがＵＤＰを用いるデータ送信を行っても、ＴＣＰを用いるデータ送信を妨害してしまう可能性は低くなり、ＴＣＰ側で再送信等が発生しにくくなるので、ＴＣＰ側のデータ送信におけるスループットが改善される。もちろん、ＵＤＰ側においては、通信が妨害される可能性は相応に高くなるが、そもそもＵＤＰ側はある程度のデータエラーが許容されるので、データエラーが大きな問題とならないことが多い。したがって、これらのノードが参加するシステム全体で見れば、スループットが改善されることになる。

なお、上記の例は、ＴＣＰ側におけるスループットを高めたく、且つ、ＵＤＰ側における多少のデータエラーの発生が問題とならないケースを想定したものであるが、ＵＤＰ側における信頼性を高めたく、且つ、ＴＣＰ側におけるスループットの低下が許容されるシステムであれば、ＴＣＰ＝送信出力レベル「低」、ＵＤＰ＝送信出力レベル「高」と、送信出力レベルの設定を逆転させてもよい。つまり、より重要視すべきプロトコルは、個々の無線ネットワークシステム毎に変わり得るので、個々の無線ネットワークシステム毎に重要視すべきプロトコルを考慮して、どのプロトコルに対応づける送信出力レベルを高くするかを決めればよいのである。

また、上記ＴＣＰ／ＵＤＰ以外の事例としては、例えば、ＵＰｎＰ（商標）対応のネットワーク装置がノードとなるネットワークの場合、様々な機能を持つネットワーク装置がオンデマンドにネットワークとの接続／切断を行うため、ＳＳＤＰ（Simple Service Discover Protocol）と呼ばれるプロトコルを利用して、送信先となるネットワーク装置の発見を行い、ネットワーク装置の提供するサービスの情報や性能情報等をＸＭＬ（Extensible Markup Language）で記述したサービス／デバイスディスクリプタをＨＴＴＰ（Hyper Text Transfer Protocol）にて取得することで情報照会を行い、その後、発見したネットワーク装置へのデータ送信が行われることがある。この場合、送信先を発見・情報照会するために送信する第１のデータは、ネットワークに参加するノードを把握するためにある程度定期的に送信が繰り返されるため、たまたまデータエラーが発生したとしても次回の送信で対処がなされれば十分であることが多い。一方、送信先の発見後に当該送信先へ送信する第２のデータは、通常は、定期的に送信が繰り返されるデータではない。したがって、この場合は、前記送信制御手段が、送信先の機能を利用する前準備のために送信する第１のデータ、該前準備の後に当該送信先へ送信する第２のデータ、以上２つのデータそれぞれに対応づけられた送信出力レベルで前記送信対象データを送信するように、前記データ送信手段を制御するとよい。より具体的な例を挙げれば、例えば、前記送信制御手段が、前記前準備である送信先の発見または情報照会のために前記第１のデータ送信し、前記送信先の発見後または情報照会後に前記第２のデータを送信するように構成されているとよい。

さらに、複数の送信対象データを連続的に送信する際には、各送信対象データに対応する送信出力レベルがすべて同じになるとは限らない。この場合に、送信制御手段が各送信対象データ毎に逐一送信出力レベルを切り替えるべくデータ送信手段を制御すると、送信出力レベルの切り替えにある程度時間を要する装置においては、複数の送信対象データの送信間隔が長くなり、送信開始から送信完了までにかかる時間が増大するという問題を招く。そこで、この場合は、前記送信制御手段が、異なる送信出力レベルが対応づけられた複数組の送信対象データを送信する場合に、前記異なる送信出力レベルのうち、最も大きい送信出力レベルで前記複数組の送信対象データすべてを送信するように、前記データ送信手段を制御するとよい。

このような構成になっていれば、複数の送信対象データを連続的に送信する際に、各送信対象データに対応する送信出力レベルがすべて同じになっていなくても、それら異なる送信出力レベルのうち、最も大きい送信出力レベルで複数組の送信対象データすべてを送信するので、送信出力レベルの切り替えに時間を要することがなくなり、送信開始から送信完了までにかかる時間を短くすることができる。

さらに、データ処理手段と送信制御手段とを連動させるための一手段としては、前記データ処理手段が、前記一つのプロトコルに対応づけられた送信出力レベルを、前記送信制御手段に対して指令する出力レベル指令手段を備えており、前記送信制御手段は、前記データ処理手段によって処理された前記送信対象データを、前記出力レベル指令手段が指令した送信出力レベルで送信するように、前記データ送信手段を制御すると望ましい。

出力レベル指令手段からの指令を送信制御手段へ伝達する具体的な手法は任意であるが、例えば、前記出力レベル指令手段が、前記送信出力レベルを示す出力レベル情報を前記送信対象データに対して付加することにより、前記出力レベル情報によって示される送信出力レベルを、前記送信制御手段に対して指令する出力レベル情報付加手段を備えていれば、送信対象データに付加された出力レベル情報により、出力レベル指令手段からの指令が送信制御手段へと伝達される。

なお、データ処理手段は、例えば、アプリケーション、ソケットインターフェース、およびプロトコルスタックの各階層をなすソフトウェア群から構成されるとともに、前記アプリケーションから前記ソケットインターフェース、前記プロトコルスタックを通して、前記送信制御手段であるドライバへとデータを伝送すると、該ドライバが前記データ送信手段を制御して、該データ送信手段が前記送信対象データを送信するように構成されるが、上記のような出力レベル情報を利用する場合、前記ソケットインターフェースの階層で前記出力レベル情報を用意し、前記プロトコルスタックの階層で前記出力レベル情報を送信対象データに対して付加するとよい。

このように構成すれば、アプリケーションの階層をなすソフトウェア群については、この種の無線ネットワーク装置で利用される既存のソフトウェア群をそのまま利用することができ、プロトコルスタックの階層をなすソフトウェア群についても、ソケットとのインターフェースの部分のみに、出力レベル情報を送信対象のデータに対して付加する機能を追加するだけで、他の大部分の複雑なソフトウェア群に何ら手を加えることなく、この種の無線ネットワーク装置で利用される既存のソフトウェア群をそのまま利用することができる。後は、ソケットインターフェースおよびドライバに機能追加をするだけで、特徴的構成を実現することができる。

さらに、送信先または送信元ポート番号に対応するプロトコルに対応づけられた送信出力レベルを取得する手法も任意であるが、例えば、前記出力レベル指令手段が、前記送信先または送信元ポート番号に基づいて、送信先または送信元ポート番号と送信出力レベルとの対応関係を記憶する出力レベルテーブルから、前記送信出力レベルを取得し、該取得した送信出力レベルを、前記送信制御手段に対して指令するように構成するとよい。

このような出力レベルテーブルを利用する場合、特定のプロトコルに対応する送信先または送信元ポート番号が不変であれば、その送信先または送信元ポート番号に対応する送信出力レベルとしては、特定のレベルをあらかじめ記憶させておけばよい。特定のプロトコルに対応する送信先ポート番号が、事前にノード間でのデータ通信を行うことにより、送信先となるノードから通知される場合は、送信先ポート番号を送信先から動的に取得した後、その送信先ポート番号を利用するプロトコルに対応づけられた送信出力レベルを、出力レベルテーブルに書き込むようにすればよい。

加えて、無線にてデータを送信可能で、データ送信時の送信出力レベルを２通り以上に変更可能なデータ送信手段を備えたネットワーク装置に対し、複数のデータ送信用プロトコルの中から選ばれる一つのプロトコルに従って、前記送信対象データを処理するデータ処理手順と、該データ処理手順において処理された前記送信対象データを、前記一つのプロトコルに対応づけられた送信出力レベルで送信するように、前記データ送信手段を制御する送信制御手順とを備えたプログラムを導入すれば、先に説明した通りのネットワーク装置を構成することができるので、既に述べたとおりの作用、効果を奏するものとなる。

以上説明したように、本発明によれば、送信機側において採用するだけでも通信環境を改善可能で、比較的重要度が高いデータを優先的に送受信することも可能なネットワーク装置を提供することができる。
また、アプリケーションのレベルで送信出力レベルが指定されるので、アプリケーションよりも下位の層において送信出力レベルの判断をしなくてもよくなり、アプリケーションのレベルで指定された送信出力レベルに基づき、比較的重要度が高いデータを優先的に送受信することができるようになる。

次に、本発明の実施形態についていくつかの例を挙げて説明する。
［第１実施形態］
以下に本発明の実施形態として例示するネットワーク装置は、無線ＬＡＮ方式でネットワークを構成可能なＤＮＳサーバ、パーソナルコンピュータ（以下、ＰＣという）、およびプリンタである。なお、本実施形態において、無線ＬＡＮ方式は、ＩＥＥＥ８０２．１１系規格（IEEE802.11a,IEEE802.11b,IEEE802.11g等）の方式を想定しているが、規格そのものは他の無線ＬＡＮ規格であっても構わない。

図１は、ＤＮＳサーバ１、ＰＣ２、およびプリンタ３が備えるネットワーク関連のソフトウェア群、およびハードウェアを示す階層図である。
ＤＮＳサーバ１は、ネットワーク上のノードに付されたドメイン名を、ネットワーク上の論理アドレス（ＩＰアドレス）に変換する機能を提供するコンピュータである。

ＰＣ２は、周知の通り、アプリケーションに応じて様々な機能を提供可能な装置であるが、本実施形態においては、印刷機能を有するアプリケーションに従って印刷処理を実行することにより、プリンタ３に対して印刷データを出力する機能を提供する装置として説明する。

プリンタ３は、ネットワーク経由で送信されてくる印刷データに基づいて、紙状記録媒体に対して印刷を行う装置である。
これらＤＮＳサーバ１、ＰＣ２、およびプリンタ３は、いずれも無線ＬＡＮ方式でネットワークを構成するためのソフトウェア群およびハードウェアを備えており、これらのソフトウェア群およびハードウェアは、それぞれの機能から図１に示したような階層に分類される。これらの各階層に属するソフトウェアないしハードウェアは、通信相手の各階層と対になっており、各階層においてはそれぞれ同レベルのデータ処理が行われる。

より具体的には、アプリケーション１１，２１，３１ａ，３１ｂは、利用者や他のソフトウェアに対してデータ通信機能を提供するソフトウェアで、送信対象となる元データ（図２（ａ）参照）を用意して下位の層へと渡す。元データは、送信側と受信側とで同一プロトコルに従って処理され、そのプロトコルに応じたデータ処理が下位の層で実施されることになる。

ソケットインターフェース１２，２２，３２ａ，３２ｂは、論理的な通信の口であり、データの送受信を行なうための仮想的な経路の確立や解放を行なう。アプリケーション１１，２１，３１ａ，３１ｂの階層からは、ソケットインターフェース１２，２２，３２ａ，３２ｂの階層において、図１に点線で示したような、バーチャル通信チャネル間で通信を行っているように見えるが、実際にはさらに下位の層へデータが渡されることになる。また、後から詳述するが、ソケットインターフェース１２，２２，３２ａ，３２ｂの階層において、送信対象データの送信先ポート番号に基づいて、出力レベルテーブルから送信出力レベルを取得し、この送信出力レベルを示す出力レベルフラグ（本発明でいう出力レベル情報）を送信対象データに対して付加する処理が行われる（図２（ｂ）参照）。

プロトコルスタック１３，２３，３３は、ＴＣＰ（ＵＤＰ）／ＩＰ通信を行うための主要部で、相手側とのコネクションの管理、データパケットの生成、タイムアウト・再送処理などを行う。プロトコルスタック１３，２３，３３の階層では、渡されたデータに対して、ＭＡＣヘッダやＩＰヘッダが付加される（図２（ｃ）参照）。なお、プロトコルスタック１３，２３，３３では、ソケットインターフェース１２，２２，３２ａ，３２ｂから渡されたデータの内容については関知せず、渡されたデータを単なるバイト列として扱う。

ドライバ１４，２４，３４は、無線通信用のハードウェア１５，２５，３５の制御を行うソフトウェアで、プロトコルスタック１３，２３，３３から受け取ったデータを、実送信データと上記出力レベルフラグとに分割し、実送信データをハードウェア１５，２５，３５に渡すとともに、出力レベルフラグの示す送信出力レベルで送信が行われるように、ハードウェア１５，２５，３５の送信電力制御を行う。

ハードウェア１５，２５，３５は、実際の電波による物理的な送受信を行い、キャリアセンスなどの処理を行う。この無線通信用のハードウェア１５，２５，３５は、本実施形態においては、いずれもＰＣＭＣＩＡ（商標）規格の無線ＬＡＮカードとして構成されたもので、ＤＮＳサーバ１、ＰＣ２、およびプリンタ３のそれぞれが備えているカードスロットに装着されている。

図３は、ＰＣ２およびプリンタ３と、それぞれに装着された無線通信用のハードウェア２５，３５の内部構成を示すブロック図である。なお、図３においては図示を省略してあるが、ＤＮＳサーバ１の無線通信用のハードウェア１５も全く同様に構成されたものである。

図３に示す無線通信用のハードウェア２５，３５は、無線通信を行う際に利用する無線コントローラ４１およびアンテナ４２と、ＰＣ２側やプリンタ３側と接続するためのＰＣＭＣＩＡ（商標）Ｉ／Ｆ４３と、これらの制御を行うＣＰＵ４４と、ＣＰＵ４４を動作させるためのプログラムやデータを記憶するＲＯＭ４５、ＲＡＭ４６などから構成され、これらがシステムバス４７を介して接続されている。

無線コントローラ４１は、システムバス４７を経由してＣＰＵ４４から制御される。この無線コントローラ４１には、図４に示すように、システムバス４７と接続するためのバスインターフェース５１、データを送信するための送信器５２、送信データを一時的に保持する送信データバッファ５３、データを受信するための受信器５４、および受信データを一時的に保持する受信データバッファ５５などが設けられ、これらを制御回路５６が制御している。また、この無線コントローラ４１の送信器５２には送信出力切替機能が設けられており、さらに、無線コントローラ４１には、送信器５２の送信出力切替機能を用いて送信出力レベルを切り替えるためにＣＰＵ４４から電力指定信号が送られて来た際に、その指定を保持するためのラッチ５７と、指定されたデータ（パケット）の送信時に、指定された送信電力となるよう同期をとるための同期回路５８とが設けられている。

次に、上記無線ネットワーク上で送受信されるデータに関し、具体的なデータを例示しながら、そのデータの送信プロトコルと、その送信プロトコルを用いる通信の重要度について説明する。

ＤＮＳサーバ１は、自身が管理しているネットワーク上に存在するネットワーク装置について、そのドメイン名とＩＰアドレスの対応表を持っており、ネットワーク上の他のノードからの問い合わせに応えて、問い合わせ対象となったネットワーク装置のドメイン名やＩＰアドレスを示す情報を提供することができる。例えば、プリンタ３が、ＤＮＳサーバ１に対し、あるネットワーク装置のドメイン名とＩＰアドレスとの対応関係に関する問い合わせを行った場合、ＤＮＳサーバ１は、プリンタ３に対し、問い合わせ対象となったネットワーク装置のドメイン名とＩＰアドレスの対応関係に関する情報を送信する。これらの処理は、ＤＮＳサーバ１のアプリケーション１１とプリンタ３のアプリケーション３１ａとによって実行され、その際にＤＮＳプロトコルが利用される。

また、ＤＮＳサーバ１に対して問い合わせを行う上記他のネットワーク装置（例えば、プリンタ３）は、キャッシュと呼ばれる記憶領域を備えており、ＤＮＳサーバ１からドメイン名とＩＰアドレスとの対応関係に関する情報を受け取った後、その情報をキャッシュに格納する。そして、以後、上記他のネットワーク装置（例えば、プリンタ３）は、再び同じ情報が必要となった場合、自身のキャッシュから情報を得るようになる。このようなキャッシュを設けることで、上記他のネットワーク装置（例えば、プリンタ３）は、いちいちＤＮＳサーバ１から情報を取得するよりも、同じ情報をより迅速に取得できるようになり、また、ネットワークにかかる負荷を軽減することもできるのである。ただし、上記キャッシュの情報も、ある程度の時間が経過すると更新されるようになっている。例えば、情報毎に設定された有効期限が切れた場合、あるいは、日付が変わった場合など、上記他のネットワーク装置（例えば、プリンタ３）は、様々なタイミングでキャッシュの情報を更新しようとする。その際にも、上記同様、ＤＮＳプロトコルが利用される。

ところで、上記ＤＮＳプロトコルを用いるデータ通信で通信エラーが発生した場合、上記他のネットワーク装置（例えば、プリンタ３）は、単にＤＮＳサーバ１への問い合わせを中止して、キャッシュの情報更新を次の更新時期まで見送る。以降、次の更新時期（例えば、数時間後、１日後等）までは、キャッシュに格納されている更新前の情報をそのまま利用し続ける。このような処理を行うのは、一般に、ドメイン名とＩＰアドレスの対応関係は頻繁に変更されるものではないため、更新前の情報を利用し続けても実害がない場合が多く、むしろ、更新が成功するまで短期間に何度も（例えば、数秒〜数十秒間隔で）問い合わせを繰り返すような処理を行うと、ネットワークに対して余計な負荷をかけることになるからである。

このことは、換言すると、ＤＮＳサーバ１への問い合わせは、可能であれば当然成功させたいものの、何度かは失敗しても実用上は問題ない程度の通信であると言うこともでき、上記他のネットワーク装置（例えば、プリンタ３）にとって、上記ＤＮＳプロトコルを用いるデータ通信は、比較的重要度の低いデータ通信であると言える。

さて一方、ＰＣ２において、利用者が、印刷機能を有するアプリケーション２１を利用している際に所定の操作を行うと、ＰＣ２は、プリンタ３に対して印刷データを送信する。この時、ＰＣ２のアプリケーション２１はＬＰＲプロトコルを用いて印刷要求する一方、プリンタ３のアプリケーション３１ｂはＬＰＤプロトコルを用いて印刷要求の到来を待ち受け、これによりＰＣ２−プリンタ３間でのデータ通信が行われる。

上記ＬＰＲプロトコルを用いたデータ通信で通信エラーが発生した場合、ＰＣ２は、エラーとなったデータ（パケット）の再送処理を行う。この再送処理は、通信エラーが発生するたびに繰り返される。このような処理を行うのは、通信エラーを無視して印刷処理を継続すると文字化けやその他の印刷不良が発生するおそれがあり、また、単に印刷処理を中断すると中断前までの印刷が無駄になるなどの問題があるからである。

このことは、換言すると、ＰＣ２からプリンタ３への印刷データの送信は、エラー回復処理に伴うネットワークへの負荷やスループットの低下を勘案しても、エラーを無視することができない重要な通信である、すなわち、ＰＣ２およびプリンタ３にとって、上記ＬＰＲプロトコルを用いるデータ通信は、比較的重要度の高いデータ通信であると言える。

そこで、本実施形態において、上記ＤＮＳサーバ１、ＰＣ２、およびプリンタ３は、ＤＮＳプロトコルを用いてデータ通信を行う際には、送信電力レベルを「低」にして通信を行い、一方、ＬＰＲプロトコルを用いてデータ通信を行う際には、送信電力レベルを「高」にして通信を行い、これにより、プリンタ３への印刷データを、ＤＮＳサーバ１への問い合わせデータよりも優先的に送受信させることができるように構成してある。

以下、プロトコルによって送信電力レベルの高低を変えて通信を行うようにした通信処理について、上記ＬＰＲプロトコルを用いて印刷データを送信する場合を例に挙げながら、より詳細に説明する。

ＬＰＲプロトコルによる通信を行う場合、まず、プリンタ３側においては、図５に示すプリンタＬＰＤメイン処理が実行される。この処理は、プリンタ３の電源スイッチをＯＮにすると実行される処理である。この処理を開始すると、プリンタ３は、まず、プリンタ３各部の初期化処理を実行し（Ｓ１１）、ＬＰＤポートでソケットを生成し（Ｓ１２）、ＰＣ２からの接続を待つ状態になる（Ｓ１３）。この状態において、ＰＣ２から接続されると、プロトコルに従って印刷データを受信するとともに、当該印刷データに基づく印刷処理を行う（Ｓ１４）。

一方、ＰＣ２側においては、図６に示す印刷処理が実行される。この処理は、利用者が印刷機能を有するアプリケーション２１を利用している際に実行される処理である。この処理を開始すると、ＰＣ２は、まず、印刷出力のために必要なデータ（印刷データ）を準備する（Ｓ２１）。このデータは、例えば文字データや、その文字データに関連するフォント種別、サイズ、色、その他の属性を示すデータ、画像データ、各種制御データ等によって構成されるデータであり、利用者がアプリケーション２１（具体的にはワードプロセッサやグラフィックエディターなど）を利用して生成、あるいはハードディスク装置に記録済みのものを読み出す等、様々な方法で準備されることになる。

このような印刷データを準備したら、続いて、ＰＣ２は、プリンタ３のＬＰＤポートに対して接続するためのソケットをオープンする（Ｓ２２）。このＳ２２の処理は、より詳しくは、図７に示すような処理になる。

ソケットオープン処理を開始すると、ＰＣ２は、従来と同様のソケット処理を実行することにより（Ｓ３１）、データの送受信を行なうための仮想的な通信路の確立を行う。
続いて、印刷データの中からポート番号を取り出し（Ｓ３２）、このポート番号をキーにして出力レベルテーブルを検索する（Ｓ３３）。この出力レベルテーブルは、ポート番号と送信出力レベルとの対応関係を記録したテーブルで、ＰＣ２のメモリに記憶されている。メモリとしては、書き換え不能なＲＯＭを用いることができ、この場合は、出力レベルテーブルの内容は固定的なものとなる。また、メモリとして、書き換え可能なＲＯＭ（例えばフラッシュメモリ）や内蔵電池から供給される電力により記憶内容を保持するように構成された不揮発性ＲＡＭを用いてもよく、この場合は、出力レベルテーブルの内容は書き換え可能なものとなる。出力レベルテーブルの内容を書き換え可能な場合は、ＳＮＭＰ（Simple Network Management Protocol）などにより内容を更新できるようにしてもよい。

出力レベルテーブルの内容は、例えば、下記表１のような内容になっている。

ポート番号には、あらかじめ特定のプロトコルにおいて用いられることが決まっているものがあり、そのようなポート番号をWell-Knownポート番号と呼んでいる。例えば、表１に付記したように、ポート番号５３の場合、ＤＮＳプロトコルで用いられることが決まっており、ポート番号５１５の場合、ＬＰＲプロトコルで用いられることが決まっている。そこで、このＰＣ２においては、ポート番号５３であれば、送信出力レベルを「Ｌｏ」、ポート番号５１５であれば、送信出力レベルを「Ｈｉ」という具合に、ポート番号と送信出力レベルとの対応関係を出力レベルテーブルに記憶させている。

Ｓ３３の処理では、Ｓ３２の処理で取り出したポート番号（本処理の場合は５１５）をキーに上記表１を検索するので、送信出力レベル「Ｈｉ」を検出することになる。すなわち、ＬＰＲプロトコルを用いる場合、送信出力レベルは「Ｈｉ」とすることが決まるのである。ちなみに、ＤＮＳプロトコルを用いる場合であれば、データの中から取り出されるポート番号は５３となるので、このポート番号をキーに上記出力レベルテーブルを検索すると、送信出力レベル「Ｌｏ」を検出することになる。そして、出力レベルテーブルから送信出力レベルを検出したら、その出力レベルをメモリに記憶させ（Ｓ３４）、後の処理で利用できるようにする。

こうして、Ｓ３１〜Ｓ３４の処理を終えると、図６に示したＳ２２の処理を終えたことになり、引き続いて、ＰＣ２は、オープンしたソケットに対して印刷データを出力する（Ｓ２３）。このＳ２３の処理は、より詳しくは、図８に示すデータ書込み処理になる。

データ書込み処理を開始すると、ＰＣ２は、まず、データをパケットサイズに合わせて分割する（Ｓ４１）。そして、分割された個々のパケットに対し、上記Ｓ３４の処理でメモリに記憶させた送信出力レベルを示す出力レベルフラグを付加する（Ｓ４２）。この処理により、図２（ａ）に示したような元データが加工され、図２（ｂ）に示したような出力レベルフラグが付加されたデータとなる。

続いて、プロトコルスタック２３で必要な処理を行う（Ｓ４３）。プロトコルスタック２３は、ＴＣＰ／ＩＰ通信の主要部分であり、特にＴＣＰでの通信時には、ヘッダの付加、チェックサムの生成およびチェック、ハンドシェイク、タイムアウト処理、再送など、複雑な処理を行っているが、これらの処理自体はＴＣＰ／ＩＰプロトコルスタックが実行する処理として公知なので、ここでの詳細な説明は省略する。

そして、Ｓ４３の処理が施されたデータを下位層に渡すことにより（Ｓ４４）、そのデータ（パケット）が送信先へと送信される。以上、Ｓ４１〜Ｓ４４の処理は、印刷データすべてが処理されるまで繰り返し実行され（Ｓ４５：ＮＯ）、印刷データすべてが処理されると（Ｓ４５：ＹＥＳ）、本処理を終了する。

こうして、Ｓ４１〜Ｓ４５の処理を終えると、図６に示したＳ２３の処理を終えたことになり、ＰＣ２は、オープンしたソケットをクローズし（Ｓ２４）、本処理を終える。
さて、ＰＣ２が以上のような処理を実行することにより、ＰＣ２からプリンタ３へは印刷データを構成するパケットが送信されることになる。このとき、上記Ｓ１３の処理によって待機していたプリンタ３は、上記Ｓ１４の処理へと移行し、その処理の中で図９に示すデータ受信処理を実行する。

データ受信処理を開始すると、プリンタ３は、まず、パケットを受信する（Ｓ５１）。このパケットは、上記Ｓ４１〜Ｓ４５の処理により作成、送信されてくるものである。
続いて、パケットの中から宛先ポート番号を取り出し（Ｓ５２）、この宛先ポート番号をキーにして出力レベルテーブルの検索を行う（Ｓ５３）。すなわち、プリンタ３も、上記ＰＣ２と同様、ポート番号と送信出力レベルとの対応関係を記録した出力レベルテーブルをメモリに記憶しており、Ｓ５２の処理で取り出したポート番号をキーに出力レベルテーブルを検索する。その結果、本実施形態の場合、プリンタ３は、出力レベルテーブルから送信出力レベル「Ｈｉ」を検出することになる。

こうして、出力レベルテーブルから送信出力レベルを検出したら、プリンタ３は、Ａｃｋパケットを生成し（Ｓ５４）、そのＡｃｋパケットをＰＣ２側に送信する（Ｓ５５）。Ｓ５４の処理では、上記Ｓ４２の処理と同様、Ｓ５３の処理で検出した送信出力レベルを示す出力レベルフラグがパケットに付加される。すなわち、プリンタ３側から見れば、上記宛先ポート番号は送信元ポート番号となるのであり、送信元ポート番号に基づいて、この送信元ポート番号を利用するＬＰＲプロトコルに対応づけられた送信出力レベルを示す出力レベルフラグを、送信対象データであるパケットに対して付加するのである。そして、Ｓ５１の処理で受信したパケットに基づいて印刷を実施する（Ｓ５７）。以上、Ｓ５１〜Ｓ５７の処理は、印刷データすべてが処理されるまで繰り返し実行され（Ｓ５８：ＮＯ）、印刷データすべてが処理されると（Ｓ５８：ＹＥＳ）、本処理を終了する。

以上説明したように、ＰＣ２側においては、上記Ｓ４２の処理により、送信対象となるパケットに出力レベルフラグが付加され、プリンタ３側においては、上記Ｓ５４の処理により、送信対象となるパケットに出力レベルフラグが付加され、プロトコルスタック２３，３３での処理後は、図２（ｃ）に示すようなデータとなる。そして、このパケットがドライバ２４，３４に渡されることになる。

ところで、上記Ｓ４２、上記Ｓ５４の処理では、上述の通り、ＬＰＲプロトコルを用いたデータ通信を行うため、送信電力レベル「高」を示す出力レベルフラグが付加される。一方、プリンタ３からＤＮＳサーバ１に対しＤＮＳプロトコルを用いて問い合わせを行う場合も、送信対象となるパケットに出力レベルフラグが付加され、図２（ｃ）に示すようなデータとなるが、この場合は、ＤＮＳプロトコルを用いたデータ通信を行うため、送信電力レベル「低」を示す出力レベルフラグが付加される。

出力レベルフラグが付加されたパケットを渡されたドライバ１４，２４，３４は、それぞれ、図１０に示すようなドライバ送信処理を実行する。
この処理を開始すると、ドライバ１４，２４，３４は、パケットから出力レベルフラグを取り外し（Ｓ６１）、これにより、図２（ｄ）に示すような実送信データを作成する。

そして、出力レベルフラグが示す送信出力レベルに基づいて、ハードウェア１５，２５，３５に対して電力レベルの指定を行う（Ｓ６２）。この電力レベルの指定は、ＰＣＭＣＩＡ（商標）Ｉ／Ｆ４３を介して無線コントローラ４１へと伝達され、無線コントローラ４１では、バスインターフェース５１を介してラッチ５７に電力指定信号として伝達され、ラッチ５７に記憶される。

そして、実送信データをバッファ（送信データバッファ５３）に書き込み（Ｓ６３）、ハードウェア１５，２５，３５に対してバッファ内のデータについての送信要求を行う（Ｓ６４）。

その結果、ハードウェア１５，２５，３５は、周囲の通信状況を検出しながらデータの送信が可能かどうかを判断し、データの送信が可能になると、同期回路５８が送信器５２の出力を切り替えるためのセットアップタイムを反映させたタイミングで、送信器５２の出力レベルを切り替える。

出力レベルの切り替えは、ラッチ５７の記憶内容に応じて「高」、「低」いずれかとされる。具体例を挙げれば、例えば、ＬＰＲプロトコルによるデータ通信の場合は、送信器５２の出力レベルを「高」に切り替えることになるが、ＤＮＳプロトコルによるデータ通信であれば、送信器５２の出力レベルを「低」に切り替えることになる。

その後、セットアップタイムが経過すると、送信データバッファ５３内のデータが送信器５２に送り込まれ、実際にデータが送信される。同期回路５８は、データの送信終了のタイミングで、送信器５２の出力レベルを元に戻す。

以上の様子をタイミングチャートに表すと、図１１に示すような図になる。まず、上記Ｓ６２の処理により、ハードウェア１５，２５，３５に対する電力レベルの指定が行われると、電力指定信号として高電力を示すパルス信号がラッチ５７に対して出力される。続いて、上記Ｓ６３の処理により、実送信データが送信データバッファ５３に書き込まれる。

その後、ハードウェア１５，２５，３５は、受信キャリアレベルによって周囲の通信状況を検出し、キャリア断を検出したらデータの送信が可能であると判断し、同期回路５８が送信器５２の出力を切り替えるためのセットアップタイムを反映させたタイミングで、送信器５２の出力レベルを切り替える。

その後、セットアップタイムが経過すると、送信データバッファ５３内のデータが送信器５２に送り込まれ、実際にデータが送信され、自局送信中の状態になる。そして、データの送信終了後に、同期回路５８は、送信器５２の出力レベルを元に戻す。

なお、送信器５２の出力レベルを元に戻すタイミングで、次のパケットの送信出力レベルが既にわかっている場合もあり、その場合、送信出力レベルを変える必要がないこともあるので、そのような場合は、送信器５２の出力レベルを元に戻さず、維持したままにしてもよい。

このように、上記Ｓ６１〜Ｓ６４の処理を行うと、ハードウェア１５，２５，３５は、ＬＰＲプロトコルによるデータ通信の場合は、送信器５２の出力レベルを「高」に切り替えてデータの送信を実施し、一方、ＤＮＳプロトコルによるデータ通信の場合は、送信器５２の出力レベルを「低」に切り替えてデータの送信を実施するようになる。

そのため、ＰＣ２とプリンタ３との間で比較的重要度の高い印刷データの送受信を行いたい状況にある場合、その近くにあるＤＮＳサーバ１に対して、他の無線ネットワーク装置から比較的重要度の低いＤＮＳプロトコルによる問い合わせが実施されたとしても、印刷データの送受信を妨害してしまう可能性は低くなる。もちろん、ＤＮＳプロトコルによる問い合わせについては、ＰＣ２とプリンタ３との間で印刷データを送信していることが原因で、通信が妨害される可能性は相応に高くなるが、先にも説明した通り、ＤＮＳプロトコルによる問い合わせについては、時間が経ってからあらためて実施しても、実用上は大きな問題とならないことが多い。

したがって、このように通信プロトコルに応じて送信出力レベルを変更することができるＤＮＳサーバ１、ＰＣ２、およびプリンタ３であれば、比較的重要度が高い印刷データを優先的に送受信することができるようになる。

また、これらＤＮＳサーバ１、ＰＣ２、およびプリンタ３は、自身が用いる送信プロトコルに応じて送信出力レベルを切り替える装置であって、送信機側と受信機側とのやり取りを行って送信出力レベルを調節するものではないので、送信機側単独で上記構成を採用しても相応に通信環境を改善することができる。すなわち、例えば、ＰＣ２からプリンタ３へ印刷データを送信する場合、上記実施形態では、ＰＣ２からプリンタ３への送信パケットおよびプリンタ３からＰＣ２への送信パケットの双方について、送信出力レベルを「高」とする旨の説明をしたが、ＰＣ２からプリンタ３への送信パケットについてだけ、送信出力レベルを「高」とするような構成になった場合でも、相応の効果が期待できるのである。したがって、無線ネットワークへの導入時に、送信側と受信側とを必ずセットにしなければならないものに比べ、既存の無線ネットワークシステムへの導入も容易である。

なお、以上の説明においては、ＬＰＲプロトコルとＤＮＳプロトコルとを例示して、これらの違いに応じて送信出力レベルを変更する旨の説明をしたが、これら以外のプロトコルについてもそれぞれ重要度を定めて、送信出力レベルを切り替えれば、様々なプロトコルを用いた通信が行われる環境において、重要度が高いデータを優先的に送受信することができるようになる。

重要度を定める基準は、システム毎に変わり得るものであるが、一例としては、次のような基準を考えることができる。
例えば、上記ＬＰＲプロトコルを用いる通信は、利用者がＰＣ２において印刷を指示した際に一回限り実施される通信なので、同じ印刷データを後からプリンタ３が取得することは困難であるのに対し、ＤＮＳサーバ１への問い合わせによって得られる情報は、同じ情報を後から得ることも可能なので、前者の方が重要度は高いと言え、これを重要度の基準としてもよい。

また、送信対象となるデータ量が多いプロトコルで再送が多発すると、ネットワークに負荷がかかり、パフォーマンスが低下するのに対し、データ量が少ないプロトコルは、いくらか再送が発生したとしても、絶対的なデータ量が少ないのでネットワークに対する悪影響も少ない。送信対象となるデータ量が多いプロトコルとしては、ＨＴＴＰ、ＬＰＲ、ＰＯＰなどのデータ系のプロトコルを挙げることができ、送信対象となるデータ量が少ないプロトコルとしては、ＤＮＳ、ＳＮＭＰ、ＮＴＰなどの管理系のプロトコルを挙げることができるので、これを重要度の基準としてもよい。

［第２実施形態］
次に、上記第１実施形態とは、別の実施形態について説明する。ただし、本実施形態は、ソフトウェアによる具体的な処理内容が上記第１実施形態と異なるものの、その他の点（例えばハードウェア）については上記第１実施形態と共通する部分も多いので、上記第１実施形態と相違する点を中心に説明する。

上記第１実施形態では、ポート番号には、あらかじめ特定のプロトコルにおいて用いられることが決まっているものがある旨を説明したが、プロトコルによっては、ポート番号が動的に割り当てられることもある。例えば、ＵＰｎＰ（商標）のプリントサービスにおいては、動的に割り当てられるポート番号が利用される。

そこで、このような場合には、上記第１実施形態において説明した出力レベルテーブルを、書き換え可能なメモリ上に用意し、ポート番号が動的に割り当てられた後に、ポート番号と送信出力レベルとの対応関係を出力レベルテーブル内に追記することにより、以降の処理において、ポート番号と送信出力レベルとの対応関係を出力レベルテーブルから読み取り可能となるようにする。

以下、具体的な処理について、図１２のフローチャートに基づいて説明する。この処理は、ＰＣ２がプリンタ３に対して印刷出力する際にＰＣ２において実行される処理である。なお、ここでは、プリンタ３がＵＰｎＰ（商標）対応のネットワークプリンタであることを前提として説明を続ける。

この処理を開始すると、ＰＣ２は、サービスディスカバリ機能により、プリンタ３を探索し（Ｓ７１）、プリンタ３が提供するサービス（プリントサービス）についての情報を含むサービスディスクリプタおよびプリンタ３の装置情報を含むデバイスディスクリプタを取得する（Ｓ７２）。Ｓ７１の処理で送信されるパケットは、データ量が小さく送信先も特定されていないので、送信出力レベルは「低」にすることが望ましい。そして、印刷サービス（プリンタ３）に対してCreateJob()オペレーションを発行する（Ｓ７３）。これは、プリンタ３にプリントジョブを生成するものである。

プリンタ３側においてジョブが生成されてデータ受信の準備ができると、プリンタ３はＰＣ２（コントロールポイント）にレスポンス（応答）を返すので、ＰＣ２は、このレスポンスを受信する（Ｓ７４）。このレスポンスの中には、DataSink URLが含まれている。これは、印刷データの実体を送る先を指定するものであり、例えば、"http://10.134.43.60:54321/upnp/printbasic/datasink/job-5001"といった書式になっている。ここで、":54321"の部分がポート番号を表している。このポート番号は、サービス（プリンタ３）側が動的に割り当てるものであるので、コントロールポイント（ＰＣ２）側では、前もってこの番号を知ることはできない。

そこで、ＰＣ２は、DataSink URLからポート番号を取り出し（Ｓ７５）、出力レベルテーブル内にある送信出力レベルの設定値について、対応するポート番号を「高」に設定する（Ｓ７６）。これにより、動的に割り当てられたポート番号についても、ポート番号と送信出力レベルとの対応関係が出力レベルテーブル内に追記されることになる。

以後は、データ送信を行えば（Ｓ７７）、上記第１実施形態と同様の処理により、データ（パケット）に出力レベルフラグが付加された状態で、そのパケットがドライバに渡され、ドライバはパケットに付加された出力レベルフラグに応じて送信電力を制御することができるようになる。なお、データ送信を終えたら、出力レベルテーブルの対応するポート番号をクリアする（Ｓ７８）。これは、他の処理において上記ポート番号が使われる場合に、送信出力レベルを「高」にするとは限らないためである。

以上説明したように、上記Ｓ７１〜Ｓ７８の処理を実行するＰＣ２によれば、印刷データの送信先となるポート番号が動的に割り当てられる構成となっていても、比較的重要度が高い印刷データを優先的に送受信することができるようになる。

［第３実施形態］
次に、上記第１，第２実施形態とは、別の実施形態について説明する。ただし、本実施形態も、ソフトウェアによる具体的な処理内容が上記第１実施形態と異なるものの、その他の点（例えばハードウェア）については上記第１実施形態と共通する部分も多いので、上記第１実施形態と相違する点を中心に説明する。

上記第１実施形態においては言及しなかったが、ＰＣ２においては複数の処理が時分割制御によって実行されることがあり、その場合、異なるプロトコルを用いる通信があたかも同時進行しているかのように実施されることがある。

例えば、第１のアプリケーションによって、ＰＣ２からプリンタ３へＬＰＲプロトコルを用いて断続的にデータ送信が行われている場合に、第２のアプリケーションによって、ＰＣ２からＤＮＳサーバ１へＤＮＳプロトコルを用いてデータ送信が行われることがあり、さらに、第３のアプリケーションによって、ＰＣ２からプリンタ３とは別のプリンタ（図示略）へＬＰＲプロトコルを用いてデータ送信が行われることもある。

このような状況下では、ＬＰＲプロトコルを用いて送信されるデータ（パケット）とＤＮＳプロトコルを用いて送信されるデータ（パケット）とが混在する状態で、データの送出が行われることになる。

しかし、使用するハードウェアの制限により、各パケット毎に送信出力レベルの切替制御を行うことが困難な場合もある。
そこで、第３実施形態においては、図１３に示すように、送信出力レベル「高」のソケットが存在する間は、すべてのパケットについて送信出力レベル「高」で送信を行い、送信出力レベルを「低」には切り替えないように制御する方式を採用した。

すなわち、図１３に示すように、まず、ＬＰＲプロトコルを用いる通信が開始され、パケットが断続的に送信される場合に、引き続いて、ＤＮＳプロトコルを用いる通信が実行されても、その際の送信出力レベルは「高」を維持する。また、さらにＬＰＲプロトコルを用いる別の通信が開始された場合、先に開始したＬＰＲプロトコルを用いる通信が完了しても、後から開始したＬＰＲプロトコルを用いる通信が完了していなければ、その際の送信出力レベルは「高」を維持する。そして、後から開始したＬＰＲプロトコルを用いる通信が完了し、送信出力レベル「高」のソケットが存在しなくなったら、その時点で送信出力レベルを「低」に切り替える。

以上のような切替制御は、送信出力レベル「高」のソケットがオープンされるとインクリメントされ、送信出力レベル「高」のソケットがクローズされるとデクリメントされるカウンタを用い、このカウンタ値が０の場合は送信出力レベル「低」、カウンタ値が１以上の場合は送信出力レベル「高」とする制御を行うことにより実現される。

より具体的な例を挙げて実施方法を説明すれば、カウンタの初期値は０、送信出力レベルの初期値は「低」とし、出力レベルフラグとしては「変更無し」、「高」、「解除」の三値をとるようにする。

そして、重要度の高い通信で用いるソケットのオープン時に、送信出力レベル「高」の指定を行い、当該ソケットのクローズ時に、送信出力レベル「解除」の指定を行う。重要度の高い通信において送信される複数のパケットは、最初の送信パケットに対して送信出力レベル「高」を示す出力レベルフラグが付加され、最後の送信パケットに対して送信出力レベル「解除」を示す出力レベルフラグが付加され、これら以外の送信パケットに対しては送信出力レベル「変更無し」を示す出力レベルフラグが付加される。また、重要度の低い通信において送信される複数のパケットに対しては、すべて送信出力レベル「変更無し」を示す出力レベルフラグが付加される。

ドライバには、上記カウンタを設け、カウンタ値が０の場合は送信出力レベル「低」となるように、データ通信用のハードウェアに対する制御を行う。そして、送信出力レベル「高」を示す出力レベルフラグが付加されたパケットが到来する毎に上記カウンタをインクリメントし、カウンタ値が１以上になれば、送信出力レベル「高」となるように、データ通信用のハードウェアに対する制御を行う。一方、送信出力レベル「解除」を示す出力レベルフラグが付加されたパケットが到来する毎に上記カウンタをデクリメントし、カウンタ値が０になれば、送信出力レベル「低」となるように、データ通信用のハードウェアに対する制御を行う。

以上のような処理を実行すれば、使用するハードウェアの制限により、各パケット毎に送信出力レベルの切替制御を行うことが困難な場合であっても、重要度の高いデータが混在していれば送信出力レベルが「高」になるので、比較的重要度が高いデータを優先的に送受信することができるようになる。

［第４実施形態］
次に、上記第１〜第３実施形態とは、別の実施形態について説明する。ただし、本実施形態も、ソフトウェアによる具体的な処理内容が上記第１実施形態と異なるものの、その他の点（例えばハードウェア）については上記第１実施形態と共通する部分も多いので、上記第１実施形態と相違する点を中心に説明する。

一般に、ＴＣＰプロトコルを用いるデータ通信は、比較的高い信頼性が要求される通信であるのに対し、ＵＤＰプロトコルを用いるデータ通信は、ＴＣＰプロトコルを用いるデータ通信ほどの信頼性は要求されないことが多い。

したがって、ＴＣＰプロトコルを用いるデータ通信を行う場合は、送信出力レベルを「高」とし、ＵＤＰプロトコルを用いるデータ通信を行う場合は、送信出力レベルを「低」としてもよい。

ＴＣＰ／ＵＤＰの違いは、アプリケーションがソケットインターフェースの使用を開始するときに判別できるので、ソケットのオープン時にＴＣＰの場合は出力レベルフラグに送信出力レベル「高」を設定し、ＵＤＰの場合は出力レベルフラグに送信出力レベル「低」を設定する。

以上のような処理を実行すれば、ＴＣＰプロトコルを利用するデータ通信を、ＵＤＰプロトコルを利用するデータ通信よりも優先的に処理できるようになる。
なお、ＵＤＰを使っている場合でも、信頼性の点だけではなく、他の理由があってＵＤＰを用いている場合がある。例えば、リアルタイム性が要求される動画配信では、データロスのリスクより、再送による時間のずれを問題視するため、ＵＤＰを使用している。また、多数の受信者に対して同時に動画を配信する場合などは、ＴＣＰは使用できないのでＵＤＰを使用しているという事情もある。

このような場合に、ＵＤＰはＴＣＰと異なり、エラー検出や再送を行わないため、動画の品質を落とさないよう、元々のエラー発生率をより下げる必要がある。そのため、ＵＤＰプロトコルを用いるデータ通信を行う場合は、送信出力レベルを「高」とし、ＴＣＰプロトコルを用いるデータ通信を行う場合は、送信出力レベルを「低」としてもよい。つまり、ＴＣＰ／ＵＤＰのどちらを重要視するかは、利用者が重要視する内容に応じて変わりうるのである。

［第５実施形態］
次に、上記第１〜第４実施形態とは、別の実施形態について説明する。ただし、本実施形態も、ソフトウェアによる具体的な処理内容が上記第１実施形態と異なるものの、その他の点（例えばハードウェア）については上記第１実施形態と共通する部分も多いので、上記第１実施形態と相違する点を中心に説明する。

上記各実施形態においては、ソケットインターフェースよりも下位の層において、通信に用いるプロトコル毎に送信出力レベルを設定する旨の説明をしたが、アプリケーションが明示的に送信出力レベルを指定し、ソケットインターフェースよりも下位の層では、アプリケーションからの指定に基づいて、通信に用いるプロトコル毎に送信出力レベルを設定するようにしてもよい。

より具体的には、ソケットインターフェースには、オプション値を設定するための機能SETSOCKOPTが用意されており、様々な設定を行うことができるので、この機能を用いて、各アプリケーションが、自身の通信が信頼性を要求されるプロトコルである場合は、送信出力レベル「高」を指定し、そうでない場合は、送信出力レベル「低」を指定する。

例えば、上記第２実施形態で説明したＵＰｎＰ（商標）のプリントサービスの場合、DataSink URLに対するデータ送信であることは、アプリケーションのレベルで認識しているので、DataSink URLに対するデータ送信の場合は、アプリケーションが送信出力レベル「高」を指定するようにしてもよい。

また、同様に、DataSink URLに対するデータ送信がＨＴＴＰプロトコルを用いて行われることも、アプリケーションは認識しているので、ＨＴＴＰプロトコルを用いる場合には、使用するポート番号とは無関係にアプリケーションが送信出力レベル「高」を指定するようにしてもよい。

以上のような処理を行えば、アプリケーションのレベルで送信出力レベルが明示的に指定されるので、アプリケーションよりも下位の層において送信出力レベルの判断をしなくてもよくなり、しかも、先に説明した実施形態と同様、比較的重要度が高いデータを優先的に送受信することができるようになる。

［その他の実施形態］
以上、本発明の実施形態について説明したが、本発明は上記の具体的な実施形態に限定されず、この他にも種々の形態で実施することができる。

例えば、上記実施形態では、送信出力レベルを「高」／「低」いずれかに切り替える例を示したが、より多段階に切り替える構成としてもよい。例えば、送信器５２が送信出力レベルを１０段階に切り替え可能な場合、出力レベルフラグは１〜１０までの数値をとるフラグとし、この数値を様々なプロトコルに対応づけて出力レベルテーブルに記憶させ、送信器５２の制御に利用するように構成するとよい。

ＤＮＳサーバ、ＰＣ、およびプリンタが備えるネットワーク関連のソフトウェア群およびハードウェアの階層図である。 送信対象となるデータ（パケット）のデータ構造図である。 無線ＬＡＮカードのブロック図である。 無線コントローラのブロック図である。 プリンタＬＰＤメイン処理のフローチャートである。 印刷処理のフローチャートである。 ソケットオープン処理のフローチャートである。 データ書き込み処理のフローチャートである。 データ受信処理のフローチャートである。 ドライバ送信処理のフローチャートである。 データ送信状態を示すタイミングチャートである。 印刷処理のフローチャートである。 複数のプロトコルが時分割で処理される場合のデータ送信状態を示すタイミングチャートである。

符号の説明

１・・・ＤＮＳサーバ、２・・・パーソナルコンピュータ（ＰＣ）、３・・・プリンタ、１１，２１，３１ａ，３１ｂ・・・アプリケーション、１２，２２，３２ａ，３２ｂ・・・ソケットインターフェース、１３，２３，３３・・・プロトコルスタック、１４，２４，３４・・・ドライバ、１５，２５，３５・・・ハードウェア、４１・・・無線コントローラ、４２・・・アンテナ、４４・・・ＣＰＵ、４５・・・ＲＯＭ、４６・・・ＲＡＭ、４７・・・システムバス、５１・・・バスインターフェース、５２・・・送信器、５３・・・送信データバッファ、５４・・・受信器、５５・・・受信データバッファ、５６・・・制御回路、５７・・・ラッチ、５８・・・同期回路。

Claims (4)

1. 無線にてデータを送信可能で、データ送信時の送信出力レベルを２通り以上に変更可能なデータ送信手段と、
   複数のデータ送信用プロトコルの中から選ばれる一つのプロトコルに従って、前記送信対象データを処理するデータ処理手段と、
   該データ処理手段によって処理された前記送信対象データを、該送信対象データに付加された前記送信出力レベルを示す出力レベル情報に基づいて前記送信出力レベルを変更した上で送信するように、前記データ送信手段を制御する送信制御手段と
   を備え、
   前記データ処理手段は、アプリケーション、ソケットインターフェース、およびプロトコルスタックの各階層をなすソフトウェア群から構成されるとともに、前記アプリケーションから前記ソケットインターフェース、前記プロトコルスタックを通して、前記送信制御手段である前記ドライバへとデータを伝送すると、該ドライバが前記データ送信手段を制御して、前記送信対象データを送信させるように構成されており、
   前記アプリケーションは、前記送信出力レベルを指定するとともに、前記ソケットインターフェースの階層へ前記送信対象データを伝送し、
   前記ソケットインターフェースの階層で、前記指定された送信出力レベルを示す前記出力レベル情報を前記送信対象データに対して付加する
   ことを特徴とするネットワーク装置。
2. 前記アプリケーションは、前記送信対象データを処理した前記一のプロトコルに基づいて、前記送信出力レベルを指定することを特徴とする請求項１記載のネットワーク装置。
3. アプリケーション、ソケットインターフェース、プロトコルスタック、およびドライバの各階層をなすソフトウェア群を備えたネットワーク装置が、送信対象データに対して付加されたデータ送信時の送信出力レベルを示す出力レベル情報に基づき、無線にて該送信対象データを送信する際の送信出力レベルを変更する方法であって、
   前記アプリケーションが、前記送信出力レベルを指定するとともに、前記ソケットインターフェースの階層へ前記送信対象データを伝送し、
   前記ソケットインターフェースの階層で、前記指定された送信出力レベルを示す前記出力レベル情報を前記送信対象データに対して付加し、
   前記出力レベル情報が付加された送信対象データを、前記プロトコルスタックを通して、前記ドライバへと伝送し、
   前記ドライバは、前記送信対象データに付加された出力レベル情報に基づいて前記送信出力レベルを変更する
   ことを特徴とする送信出力レベル変更方法。
4. 前記アプリケーションは、前記送信対象データを処理したプロトコルに基づいて、前記送信出力レベルを指定することを特徴とする請求項３記載の送信出力レベル変更方法。

Images