JP4535075B2 - ネットワーク装置、およびネットワーク装置用のプログラム - Google Patents

ネットワーク装置、およびネットワーク装置用のプログラム Download PDF

Info

Publication number
JP4535075B2
JP4535075B2 JP2007061906A JP2007061906A JP4535075B2 JP 4535075 B2 JP4535075 B2 JP 4535075B2 JP 2007061906 A JP2007061906 A JP 2007061906A JP 2007061906 A JP2007061906 A JP 2007061906A JP 4535075 B2 JP4535075 B2 JP 4535075B2
Authority
JP
Japan
Prior art keywords
transmission
data
output level
port number
target data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007061906A
Other languages
English (en)
Other versions
JP2007174704A (ja
Inventor
典生 田川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Brother Industries Ltd
Original Assignee
Brother Industries Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Brother Industries Ltd filed Critical Brother Industries Ltd
Priority to JP2007061906A priority Critical patent/JP4535075B2/ja
Publication of JP2007174704A publication Critical patent/JP2007174704A/ja
Application granted granted Critical
Publication of JP4535075B2 publication Critical patent/JP4535075B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Landscapes

  • Small-Scale Networks (AREA)
  • Communication Control (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

本発明は、無線でデータ通信を行うネットワーク装置、およびそのネットワーク装置用のプログラムに関する。
近年、無線LAN(Local Area Network)方式が広く普及しつつある。
この種の無線LAN方式の場合、限られた数の無線チャネルを複数のノードが共用するので、ノードの増加に伴って通信条件は厳しくなる。具体的には、第1に、キャリアセン
スにおいて無線チャネルの空きを検出できないケースが増え、第2に、同時送信による混信が発生するケースが増えると考えられる。
より詳しく説明すると、ノード間で無線通信を開始する場合、送信側のノードは、データの送信を行う前に、使用したいチャネルの電波を受信し、他のノードからの電波が出ているかどうかをチェックする。この処理をキャリアセンスと呼ぶ。このキャリアセンスの結果、他のノードからの電波が出ていない場合には、その無線チャネルが空いていると判断して、送信対象となるデータの送信を開始するが、他のノードからの電波が出ている場合は、その無線チャネルが使われていると判断して、データ送信ができる状態になるまで待機することになる。同じ無線チャネルを使うノードが増えた場合、無線チャネルが使われている確率は高くなるので、データ送信ができる状態になるまで待機することになる確率も高くなり、スループットが低下するという問題を招く。
また、同じ無線チャネルを使うノードが増えた場合、上記のようなキャリアセンスを、2以上のノードがほぼ同時に実施する確率も高くなる。この場合、それらのノードすべてが、無線チャネルが空いていると判断するため、ほぼ同時にデータの送信を開始してしまい、混信が発生してしまう。このような混信が発生すると、直接的には、データエラーが発生するという問題を招く。また、このようなデータエラーを検出した場合に、データの再送処理を実施してエラーを回復する仕組みは実装されているが、そのような再送処理の発生に伴ってスループットが低下するという問題を招く。
こうした問題を緩和するための一手段としては、従来、受信感度を動的に変化させる技術が採用されている。すなわち、弱い電波しか到来しない場合には受信感度を高くする一方、強い電波が到来する場合には受信感度を低くし、これにより、強い電波と弱い電波とが同時に到来するような環境下では、強い電波だけを選択的に受信するという技術である。
この技術を採用すれば、キャリアセンスを行った際に、通信対象外のノードから弱い電波が出ていたとしても、通信対象となるノードからの電波が強ければ、自ノードの受信感度は低くなり、その結果、通信対象となるノードからの電波だけを選択的に受信する状態になる。したがって、通信対象外のノードからの弱い電波が原因で、その無線チャネルが使われていると判断してしまうことはなくなるので、データ送信ができる状態になるまで待機する確率も相応に低くなり、スループットの低下は発生しにくくなる。
また、上記のようなキャリアセンスを、2以上のノードがほぼ同時に実施し、同時にデータの送信を開始したとしても、通信対象となるノードの電波が強く、通信対象外のノードの電波が弱ければ、自ノードの受信感度は低くなり、その結果、通信対象となるノードからの電波だけを選択的に受信する状態になる。したがって、混信が発生してしまうことはなくなり、それに伴うデータエラーや、データの再送処理等に伴うスループットの低下などは、発生しにくくなる。
つまり、上記のように受信感度を動的に変化させる技術を採用していれば、強い電波を優先的に受信することができるので、弱い電波が存在することによる悪影響を排除できるのである。
ところで、上記のように受信感度を動的に変化させた場合、電波が強いほど優先的に受信されることになるので、自ノードと他ノードとの間における通信状態を良好にすることだけを考えるのであれば、それらの間の電波は強いほどよいことになる。しかし、むやみに強い電波を出すだけでは、他ノードと他ノードとの通信を妨げてしまうおそれがある。逆に、他ノードと他ノードとの通信を妨げないようにするだけであれば、自ノードと他ノ
ードとの間の電波を弱くすればよいが、それでは、自ノードと他ノードとの間の通信が途切れるなどの障害が発生しやすくなるという問題がある。
このような問題に対し、例えば、下記特許文献1には、送信機側の送信出力に関する情報を送信機から受信機へ送信するとともに、受信機側が要求する送信機側における送信出力レベルを受信機から送信機へとフィードバックし、送信機側の送信出力レベルを過大にしたり過小にしたりすることなく、これら送信機および受信機が最適な状態で送受信を行うことができるようにする技術が記載されている。
特開平7−87093号公報
しかしながら、上記特許文献1に記載の方式を採用する場合、送信機側および受信機側の双方において専用の電力制御用プロトコルをサポートしている必要があり、いずれか一方が上記電力制御用プロトコルをサポートしていても、他方が上記電力制御用プロトコルをサポートしていなければ、送信出力の適正化を図ることができなかった。
また、ノード間でやりとりされるデータの中には、比較的重要度の高いデータもあれば、比較的重要度の低いデータもあるが、従来は、これらを特に区別することなく同じ送信出力レベルで送信していた。あるいは、ノード間でやりとりされるデータの中には、比較的再送信しやすいデータ(何度でも送信できるデータやデータ量が少ないデータ)もあれば、比較的再送信しにくいデータ(1度しか送信できないデータやデータ量が多いデータ)もあるが、従来は、これらを特に区別することなく同じ送信出力レベルで送信していた。
そのため、あるノード間で比較的重要度の高いデータや比較的再送信しにくいデータの送受信を行いたい状況にあっても、その近くにあるノードが比較的重要度の低いデータや比較的再送信しやすいデータを送信していると、比較的重要度の高いデータや比較的再送信しにくいデータの送受信を妨害してしまい、データエラーを引き起こしたり、スループットの低下を招いたりするという問題があった。この場合、比較的重要度の低いデータや比較的再送信しやすいデータについては、データエラーが大きな問題とならないこともあるし、必要があれば再送信も容易である。しかし、比較的重要度の高いデータや比較的再送信しにくいデータについては、データエラーが大きな問題となることがあり、再送信による対処ができないこともあった。
本発明は、上記問題を解決するためになされたものであり、その目的は、送信機側において採用するだけでも通信環境を改善可能で、比較的重要度が高いデータや比較的再送信しにくいデータなどを優先的に送受信させやすいネットワーク装置を提供することにある。
以下、上記目的を達成するためになされた本発明の特徴について詳述する。
請求項1に記載のネットワーク装置は、無線にてデータを送信可能で、データ送信時の送信出力レベルを、第1の送信出力レベルまたは該第1の送信出力レベルよりも送信出力レベルの低い第2の送信出力レベルに変更してデータ送信可能なデータ送信手段と、複数のデータ送信用プロトコルの中から選ばれる一つのプロトコルに従って、前記送信対象データを処理するデータ処理手段と、前記データ処理手段によって処理された第1の送信対象データを受信可能な送信先のポート番号を該送信先から取得する送信先ポート番号取得手段と、前記送信先ポート番号取得手段により取得されたポート番号と前記第1の送信出力レベルとを対応付けて記憶する記憶手段とを備え、前記データ処理手段は、アプリケ
ーション、ソケットインターフェース、およびプロトコルスタックの各階層をなすソフトウェア群から構成されるとともに、前記アプリケーションから前記ソケットインターフェース、前記プロトコルスタックを通してドライバへとデータを伝送すると、該ドライバが前記データ送信手段を制御して、該データ送信手段が前記送信対象データを送信するように構成されており、前記アプリケーションは、前記記憶手段に記憶されたポート番号に対し、該ポート番号に対応付けて記憶された送信出力レベルに基づいて前記送信対象データを送信する際の送信出力レベルを指定するとともに、前記ソケットインターフェースの階層へ前記送信対象データを伝送し、前記ソケットインターフェースの階層で、前記指定された送信出力レベルを示す出力レベル情報を前記送信対象データに対して付加し、前記ドライバは、前記送信対象データに付加された出力レベル情報に基づいて送信出力レベルを変更し、データ送信手段が前記送信対象データを送信するように、前記データ送信手段を制御することを特徴とする
請求項2に記載のネットワーク装置は、前記データ送信手段により前記記憶手段に記憶された送信先のポート番号に対して前記第1の送信対象データを送信したことを条件に、該ポート番号を前記記憶手段から削除するポート番号削除手段とを備えたことを特徴とする。
これにより、他の処理において同じポート番号が使われる場合に、送信出力レベルを常に第1の送信出力レベルに固定してしまうことを防止できる。
請求項3に記載のネットワーク装置は、前記記憶手段には、前記送信先ポート番号取得手段により取得されたポート番号以外にも、前記送信対象データの送信先のポート番号と該ポート番号に対して前記送信対象データを送信する際の前記送信出力レベルとが対応付けて記憶されており、前記ドライバは、前記送信先ポート番号取得手段が送信先からポート番号を取得する際に送信する要求情報としての第2の送信対象データを、該第2の送信対象データの送信先のポート番号に対応付けて前記記憶手段に記憶された送信出力レベルで送信するように、前記データ送信手段を制御することを特徴とする。
これにより、ポート番号の取得という比較的再送信しやすいデータは送信出力レベルの低い第2の送信出力レベルで送信できるので、第1の送信出力レベルで送信を行う他のデータ送信を優先させることができる
請求項に記載のプログラムは、無線にてデータを送信可能で、データ送信時の送信出力レベルを、第1の送信出力レベルまたは該第1の送信出力レベルよりも送信出力レベルの低い第2の送信出力レベルに変更してデータ送信可能なデータ送信手段を備えたネットワーク装置において用いられるプログラムであって、複数のデータ送信用プロトコルの中から選ばれる一つのプロトコルに従って、前記送信対象データを処理するデータ処理手段と、前記データ処理手段によって処理された第1の送信対象データを受信可能な送信先のポート番号を該送信先から取得する送信先ポート番号取得手段と、前記送信先ポート番号取得手段により取得されたポート番号と前記第1の送信出力レベルとを対応付けて記憶手段に記憶させる記憶制御手段とを備え、前記データ処理手段は、アプリケーション、ソケットインターフェース、およびプロトコルスタックの各階層をなすソフトウェア群から構成されるとともに、前記アプリケーションから前記ソケットインターフェース、前記プロトコルスタックを通してドライバへとデータを伝送すると、該ドライバが前記データ送信手段を制御して、該データ送信手段が前記送信対象データを送信するように構成されており、前記アプリケーションは、前記記憶手段に記憶されたポート番号に対し、該ポート番号に対応付けて記憶された送信出力レベルに基づいて前記送信対象データを送信する際の送信出力レベルを指定するとともに、前記ソケットインターフェースの階層へ前記送信対象データを伝送し、前記ソケットインターフェースの階層で、前記指定された送信出力レベルを示す出力レベル情報を前記送信対象データに対して付加し、前記ドライバは、前記送信対象データに付加された出力レベル情報に基づいて送信出力レベルを変更し、データ送信手段が前記送信対象データを送信するように、前記データ送信手段を制御することを特徴とする。
以下に説明するネットワーク装置は、
無線にてデータを送信可能で、データ送信時の送信出力レベルを2通り以上に変更可能なデータ送信手段と、
複数のデータ送信用プロトコルの中から選ばれる一つのプロトコルに従って、前記送信対象データを処理するデータ処理手段と、
該データ処理手段によって処理された前記送信対象データを、前記一つのプロトコルに対応づけられた送信出力レベルで送信するように、前記データ送信手段を制御する送信制御装置と
を備えたことを特徴とする。
このネットワーク装置においては、複数のデータ送信用プロトコルのそれぞれについて、各プロトコル毎に送信出力レベルが設定され、データ処理手段が、複数のデータ送信用プロトコルの中から選ばれる一つのプロトコルに従って送信対象データを処理した場合、送信制御装置が、前記一つのプロトコルに対応づけられた送信出力レベルで送信対象データを送信するように、データ送信手段を制御する。
より具体的な例を挙げれば、例えば、データ送信手段が、データ送信時の送信出力レベルを「高」、「低」の2通りに変更可能で、データ送信時に用いるプロトコルとして、比較的重要度の高いデータ(あるいは比較的再送信しにくいデータ)を送信する時に利用するプロトコルA、比較的重要度の低いデータ(あるいは比較的再送信しやすいデータ)を送信する時に利用するプロトコルBがある場合、これらプロトコルA,Bに応じて、プロトコルA=送信出力レベル「高」、プロトコルB=送信出力レベル「低」といった具合に、あらかじめ各プロトコル毎に送信出力レベルが設定される。そして、データ処理手段が、プロトコルAに従って送信対象データを処理した場合、送信制御装置は、プロトコルAに対応づけられた送信出力レベル「高」で送信対象データを送信するように、データ送信手段を制御する。また、データ処理手段が、プロトコルBに従って送信対象データを処理した場合、送信制御装置は、プロトコルBに対応づけられた送信出力レベル「低」で送信対象データを送信するように、データ送信手段を制御する。
このようにすれば、あるノード間で比較的重要度の高いデータ(あるいは比較的再送信しにくいデータ)の送受信を行いたい状況にある場合、その近くにあるノードが比較的重要度の低いデータ(あるいは比較的再送信しやすいデータ)を送信しても、比較的重要度の高いデータ(あるいは比較的再送信しにくいデータ)の送受信を妨害してしまう可能性は低くなる。もちろん、比較的重要度の低いデータ(あるいは比較的再送信しやすいデータ)の送受信については、その近くにあるノードが比較的重要度の高いデータ(あるいは比較的再送信しにくいデータ)を送信することで、通信が妨害される可能性は相応に高くなるが、比較的重要度の低いデータ(あるいは比較的再送信しやすいデータ)については、データエラーが大きな問題とならないことも多く、必要があれば再送信も容易である。
したがって、このようなネットワーク装置であれば、比較的重要度が高いデータや比較的再送信しにくいデータなどを優先的に送受信させることができるようになる。また、上記特許文献1に記載の装置とは異なり、受信機側とのやり取りをして送信出力レベルを調節するものではないので、送信機側において採用するだけでも通信環境を改善することができ、既存の無線ネットワークシステムへの導入も容易である。
なお、このネットワーク装置において、データ送信時の送信出力レベルは、2通りに限らず、さらに多段階に変更可能であってもよく、この場合、より多くのプロトコルについて、きめ細かく送信出力レベルを対応づけることができる。
また、いくつかのデータ送信用プロトコルは、あらかじめ決められた特定の送信先ポート番号に宛ててデータ(パケット)を送信することになり、また、その送信先からの返信
については、送信先であったポートが送信元となることから、特定の送信元ポート番号からデータ(パケット)を送信することになるので、前記送信制御装置は、前記送信対象データに付随する送信先または送信元ポート番号に基づいて、該送信先または送信元ポート番号を利用する前記一つのプロトコルに対応づけられた送信出力レベルで前記送信対象データを送信するように、前記データ送信手段を制御するように構成するとよい。
この場合、前記データ処理手段が、前記送信対象データに対して、送信先または送信元ポート番号を付加するポート番号付加手段を備えていてもよい。
また、特定のプロトコルに対応する送信先または送信元ポート番号が不変である場合もあれば、特定のプロトコルに対応する送信先ポート番号が、事前にノード間でのデータ通信を行うことにより、送信先となるノードから通知されることもあるが、後者の場合は、前記送信先ポート番号を送信先から動的に取得する送信先ポート番号取得手段を備えており、前記送信制御装置が、前記送信先ポート番号取得手段によって取得された前記送信先ポート番号を利用するプロトコルに対応づけられた送信出力レベルで前記送信対象データを送信するように、前記データ送信手段を制御するように構成されているとよい。
また、送信出力レベルを変更する対象となるプロトコルは、様々なものを考え得るが、いくつか具体例を挙げれば、例えば、前記送信制御装置が、TCP/UDPのそれぞれに対応づけられた送信出力レベルで前記送信対象データを送信するように、前記データ送信手段を制御するように構成されているとよい。
より詳しく説明すると、TCP(Transmission Control Protocol)は、データ送信時のエラーの有無をチェックしてエラーがあれば再送を行う等の対処を行うため、比較的重要度の高いデータを送信する際に用いられることが多い。一方、UDP(User DatagramProtocol)は、データ送信時のエラーの有無をチェックしないため、いくらかエラーがあっても許容されるような、比較的重要度の低いデータを送信する際に用いられることが多い。したがって、この場合は、例えば、TCP=送信出力レベル「高」、UDP=送信出力レベル「低」といった具合に送信出力レベルが設定され、送信制御装置は、TCP/UDPのそれぞれに対応づけられた送信出力レベルで送信対象データを送信するように、データ送信手段を制御する。
このようにすれば、あるノード間でTCPを用いるデータ送信を行いたい状況にある場合、その近くにあるノードがUDPを用いるデータ送信を行っても、TCPを用いるデータ送信を妨害してしまう可能性は低くなり、TCP側で再送信等が発生しにくくなるので、TCP側のデータ送信におけるスループットが改善される。もちろん、UDP側においては、通信が妨害される可能性は相応に高くなるが、そもそもUDP側はある程度のデータエラーが許容されるので、データエラーが大きな問題とならないことが多い。したがって、これらのノードが参加するシステム全体で見れば、スループットが改善されることになる。
なお、上記の例は、TCP側におけるスループットを高めたく、且つ、UDP側における多少のデータエラーの発生が問題とならないケースを想定したものであるが、UDP側における信頼性を高めたく、且つ、TCP側におけるスループットの低下が許容されるシステムであれば、TCP=送信出力レベル「低」、UDP=送信出力レベル「高」と、送信出力レベルの設定を逆転させてもよい。つまり、より重要視すべきプロトコルは、個々の無線ネットワークシステム毎に変わり得るので、個々の無線ネットワークシステム毎に重要視すべきプロトコルを考慮して、どのプロトコルに対応づける送信出力レベルを高くするかを決めればよいのである。
また、上記TCP/UDP以外の事例としては、例えば、UPnP(商標)対応のネッ
トワーク装置がノードとなるネットワークの場合、様々な機能を持つネットワーク装置がオンデマンドにネットワークとの接続/切断を行うため、SSDP(Simple Service Discover Protocol)と呼ばれるプロトコルを利用して、送信先となるネットワーク装置の発見を行い、ネットワーク装置の提供するサービスの情報や性能情報等をXML(Extensible Markup Language)で記述したサービス/デバイスディスクリプタをHTTP(HyperText Transfer Protocol)にて取得することで情報照会を行い、その後、発見したネットワーク装置へのデータ送信が行われることがある。この場合、送信先を発見・情報照会するために送信する第1のデータは、ネットワークに参加するノードを把握するためにある程度定期的に送信が繰り返されるため、たまたまデータエラーが発生したとしても次回の送信で対処がなされれば十分であることが多い。一方、送信先の発見後に当該送信先へ送信する第2のデータは、通常は、定期的に送信が繰り返されるデータではない。したがって、この場合は、前記送信制御装置が、送信先の機能を利用する前準備のために送信する第1のデータ、該前準備の後に当該送信先へ送信する第2のデータ、以上2つのデータそれぞれに対応づけられた送信出力レベルで前記送信対象データを送信するように、前記データ送信手段を制御するとよい。より具体的な例を挙げれば、例えば、前記送信制御装置が、前記前準備である送信先の発見または情報照会のために前記第1のデータ送信し、前記送信先の発見後または情報照会後に前記第2のデータを送信するように構成されているとよい。
さらに、複数の送信対象データを連続的に送信する際には、各送信対象データに対応する送信出力レベルがすべて同じになるとは限らない。この場合に、送信制御装置が各送信対象データ毎に逐一送信出力レベルを切り替えるべくデータ送信手段を制御すると、送信出力レベルの切り替えにある程度時間を要する装置においては、複数の送信対象データの送信間隔が長くなり、送信開始から送信完了までにかかる時間が増大するという問題を招く。そこで、この場合は、前記送信制御装置が、異なる送信出力レベルが対応づけられた複数組の送信対象データを送信する場合に、前記異なる送信出力レベルのうち、最も大きい送信出力レベルで前記複数組の送信対象データすべてを送信するように、前記データ送信手段を制御するとよい。
このような構成になっていれば、複数の送信対象データを連続的に送信する際に、各送信対象データに対応する送信出力レベルがすべて同じになっていなくても、それら異なる送信出力レベルのうち、最も大きい送信出力レベルで複数組の送信対象データすべてを送信するので、送信出力レベルの切り替えに時間を要することがなくなり、送信開始から送信完了までにかかる時間を短くすることができる。
さらに、データ処理手段と送信制御装置とを連動させるための一手段としては、前記データ処理手段が、前記一つのプロトコルに対応づけられた送信出力レベルを、前記送信制御装置に対して指令する出力レベル指令手段を備えており、前記送信制御装置は、前記データ処理手段によって処理された前記送信対象データを、前記出力レベル指令手段が指令した送信出力レベルで送信するように、前記データ送信手段を制御すると望ましい。
出力レベル指令手段からの指令を送信制御装置へ伝達する具体的な手法は任意であるが、例えば、前記出力レベル指令手段が、前記送信出力レベルを示す出力レベル情報を前記送信対象データに対して付加することにより、前記出力レベル情報によって示される送信出力レベルを、前記送信制御装置に対して指令する出力レベル情報付加手段を備えていれば、送信対象データに付加された出力レベル情報により、出力レベル指令手段からの指令が送信制御装置へと伝達される。
なお、データ処理手段は、例えば、アプリケーション、ソケットインターフェース、お
よびプロトコルスタックの各階層をなすソフトウェア群から構成されるとともに、前記アプリケーションから前記ソケットインターフェース、前記プロトコルスタックを通して、前記送信制御装置であるドライバへとデータを伝送すると、該ドライバが前記データ送信手段を制御して、該データ送信手段が前記送信対象データを送信するように構成されるが、上記のような出力レベル情報を利用する場合、前記ソケットインターフェースの階層で前記出力レベル情報を用意し、前記プロトコルスタックの階層で前記出力レベル情報を送信対象データに対して付加するとよい。
このように構成すれば、アプリケーションの階層をなすソフトウェア群については、この種の無線ネットワーク装置で利用される既存のソフトウェア群をそのまま利用することができ、プロトコルスタックの階層をなすソフトウェア群についても、ソケットとのインターフェースの部分のみに、出力レベル情報を送信対象のデータに対して付加する機能を追加するだけで、他の大部分の複雑なソフトウェア群に何ら手を加えることなく、この種の無線ネットワーク装置で利用される既存のソフトウェア群をそのまま利用することができる。後は、ソケットインターフェースおよびドライバに機能追加をするだけで、特徴的構成を実現することができる。
さらに、送信先または送信元ポート番号に対応するプロトコルに対応づけられた送信出力レベルを取得する手法も任意であるが、例えば、前記出力レベル指令手段が、前記送信先または送信元ポート番号に基づいて、送信先または送信元ポート番号と送信出力レベルとの対応関係を記憶する出力レベルテーブルから、前記送信出力レベルを取得し、該取得した送信出力レベルを、前記送信制御装置に対して指令するように構成するとよい。
このような出力レベルテーブルを利用する場合、特定のプロトコルに対応する送信先または送信元ポート番号が不変であれば、その送信先または送信元ポート番号に対応する送信出力レベルとしては、特定のレベルをあらかじめ記憶させておけばよい。特定のプロトコルに対応する送信先ポート番号が、事前にノード間でのデータ通信を行うことにより、送信先となるノードから通知される場合は、送信先ポート番号を送信先から動的に取得した後、その送信先ポート番号を利用するプロトコルに対応づけられた送信出力レベルを、出力レベルテーブルに書き込むようにすればよい。
加えて、無線にてデータを送信可能で、データ送信時の送信出力レベルを2通り以上に変更可能なデータ送信手段を備えたネットワーク装置に対し、複数のデータ送信用プロトコルの中から選ばれる一つのプロトコルに従って、前記送信対象データを処理するデータ処理手順と、該データ処理手順において処理された前記送信対象データを、前記一つのプロトコルに対応づけられた送信出力レベルで送信するように、前記データ送信手段を制御する送信制御手順とを備えたプログラムを導入すれば、先に説明した通りのネットワーク装置を構成することができるので、既に述べたとおりの作用、効果を奏するものとなる。
以上説明したように、本発明によれば、送信機側において採用するだけでも通信環境を改善可能で、送信対象データの送信先となるポート番号が動的に割り当てられる構成となっていても、比較的重要度が高いデータを優先的に送受信することも可能なネットワーク装置を提供することができる。
次に、本発明の実施形態についていくつかの例を挙げて説明する。
[第1実施形態]
以下に本発明の実施形態として例示するネットワーク装置は、無線LAN方式でネットワークを構成可能なDNSサーバ、パーソナルコンピュータ(以下、PCという)、およ
びプリンタである。なお、本実施形態において、無線LAN方式は、IEEE802.11系規格(IEEE802.11a,IEEE802.11b,IEEE802.11g等)の方式を想定しているが、規格そのものは他の無線LAN規格であっても構わない。
図1は、DNSサーバ1、PC2、およびプリンタ3が備えるネットワーク関連のソフトウェア群、およびハードウェアを示す階層図である。
DNSサーバ1は、ネットワーク上のノードに付されたドメイン名を、ネットワーク上の論理アドレス(IPアドレス)に変換する機能を提供するコンピュータである。
PC2は、周知の通り、アプリケーションに応じて様々な機能を提供可能な装置であるが、本実施形態においては、印刷機能を有するアプリケーションに従って印刷処理を実行することにより、プリンタ3に対して印刷データを出力する機能を提供する装置として説明する。
プリンタ3は、ネットワーク経由で送信されてくる印刷データに基づいて、紙状記録媒体に対して印刷を行う装置である。
これらDNSサーバ1、PC2、およびプリンタ3は、いずれも無線LAN方式でネットワークを構成するためのソフトウェア群およびハードウェアを備えており、これらのソフトウェア群およびハードウェアは、それぞれの機能から図1に示したような階層に分類される。これらの各階層に属するソフトウェアないしハードウェアは、通信相手の各階層と対になっており、各階層においてはそれぞれ同レベルのデータ処理が行われる。
より具体的には、アプリケーション11,21,31a,31bは、利用者や他のソフトウェアに対してデータ通信機能を提供するソフトウェアで、送信対象となる元データ(図2(a)参照)を用意して下位の層へと渡す。元データは、送信側と受信側とで同一プロトコルに従って処理され、そのプロトコルに応じたデータ処理が下位の層で実施されることになる。
ソケットインターフェース12,22,32a,32bは、論理的な通信の口であり、データの送受信を行なうための仮想的な経路の確立や解放を行なう。アプリケーション11,21,31a,31bの階層からは、ソケットインターフェース12,22,32a,32bの階層において、図1に点線で示したような、バーチャル通信チャネル間で通信を行っているように見えるが、実際にはさらに下位の層へデータが渡されることになる。また、後から詳述するが、ソケットインターフェース12,22,32a,32bの階層において、送信対象データの送信先ポート番号に基づいて、出力レベルテーブルから送信出力レベルを取得し、この送信出力レベルを示す出力レベルフラグ(本発明でいう出力レベル情報)を送信対象データに対して付加する処理が行われる(図2(b)参照)。
プロトコルスタック13,23,33は、TCP(UDP)/IP通信を行うための主要部で、相手側とのコネクションの管理、データパケットの生成、タイムアウト・再送処理などを行う。プロトコルスタック13,23,33の階層では、渡されたデータに対して、MACヘッダやIPヘッダが付加される(図2(c)参照)。なお、プロトコルスタック13,23,33では、ソケットインターフェース12,22,32a,32bから渡されたデータの内容については関知せず、渡されたデータを単なるバイト列として扱う。
ドライバ14,24,34は、無線通信用のハードウェア15,25,35の制御を行うソフトウェアで、プロトコルスタック13,23,33から受け取ったデータを、実送信データと上記出力レベルフラグとに分割し、実送信データをハードウェア15,25,35に渡すとともに、出力レベルフラグの示す送信出力レベルで送信が行われるように、
ハードウェア15,25,35の送信電力制御を行う。
ハードウェア15,25,35は、実際の電波による物理的な送受信を行い、キャリアセンスなどの処理を行う。この無線通信用のハードウェア15,25,35は、本実施形態においては、いずれもPCMCIA(商標)規格の無線LANカードとして構成されたもので、DNSサーバ1、PC2、およびプリンタ3のそれぞれが備えているカードスロットに装着されている。
図3は、PC2およびプリンタ3と、それぞれに装着された無線通信用のハードウェア25,35の内部構成を示すブロック図である。なお、図3においては図示を省略してあるが、DNSサーバ1の無線通信用のハードウェア15も全く同様に構成されたものである。
図3に示す無線通信用のハードウェア25,35は、無線通信を行う際に利用する無線コントローラ41およびアンテナ42と、PC2側やプリンタ3側と接続するためのPCMCIA(商標)I/F43と、これらの制御を行うCPU44と、CPU44を動作させるためのプログラムやデータを記憶するROM45、RAM46などから構成され、これらがシステムバス47を介して接続されている。
無線コントローラ41は、システムバス47を経由してCPU44から制御される。この無線コントローラ41には、図4に示すように、システムバス47と接続するためのバスインターフェース51、データを送信するための送信器52、送信データを一時的に保持する送信データバッファ53、データを受信するための受信器54、および受信データを一時的に保持する受信データバッファ55などが設けられ、これらを制御回路56が制御している。また、この無線コントローラ41の送信器52には送信出力切替機能が設けられており、さらに、無線コントローラ41には、送信器52の送信出力切替機能を用いて送信出力レベルを切り替えるためにCPU44から電力指定信号が送られて来た際に、その指定を保持するためのラッチ57と、指定されたデータ(パケット)の送信時に、指定された送信電力となるよう同期をとるための同期回路58とが設けられている。
次に、上記無線ネットワーク上で送受信されるデータに関し、具体的なデータを例示しながら、そのデータの送信プロトコルと、その送信プロトコルを用いる通信の重要度について説明する。
DNSサーバ1は、自身が管理しているネットワーク上に存在するネットワーク装置について、そのドメイン名とIPアドレスの対応表を持っており、ネットワーク上の他のノードからの問い合わせに応えて、問い合わせ対象となったネットワーク装置のドメイン名やIPアドレスを示す情報を提供することができる。例えば、プリンタ3が、DNSサーバ1に対し、あるネットワーク装置のドメイン名とIPアドレスとの対応関係に関する問い合わせを行った場合、DNSサーバ1は、プリンタ3に対し、問い合わせ対象となったネットワーク装置のドメイン名とIPアドレスの対応関係に関する情報を送信する。これらの処理は、DNSサーバ1のアプリケーション11とプリンタ3のアプリケーション31aとによって実行され、その際にDNSプロトコルが利用される。
また、DNSサーバ1に対して問い合わせを行う上記他のネットワーク装置(例えば、プリンタ3)は、キャッシュと呼ばれる記憶領域を備えており、DNSサーバ1からドメイン名とIPアドレスとの対応関係に関する情報を受け取った後、その情報をキャッシュに格納する。そして、以後、上記他のネットワーク装置(例えば、プリンタ3)は、再び同じ情報が必要となった場合、自身のキャッシュから情報を得るようになる。このようなキャッシュを設けることで、上記他のネットワーク装置(例えば、プリンタ3)は、いち
いちDNSサーバ1から情報を取得するよりも、同じ情報をより迅速に取得できるようになり、また、ネットワークにかかる負荷を軽減することもできるのである。ただし、上記キャッシュの情報も、ある程度の時間が経過すると更新されるようになっている。例えば、情報毎に設定された有効期限が切れた場合、あるいは、日付が変わった場合など、上記他のネットワーク装置(例えば、プリンタ3)は、様々なタイミングでキャッシュの情報を更新しようとする。その際にも、上記同様、DNSプロトコルが利用される。
ところで、上記DNSプロトコルを用いるデータ通信で通信エラーが発生した場合、上記他のネットワーク装置(例えば、プリンタ3)は、単にDNSサーバ1への問い合わせを中止して、キャッシュの情報更新を次の更新時期まで見送る。以降、次の更新時期(例えば、数時間後、1日後等)までは、キャッシュに格納されている更新前の情報をそのまま利用し続ける。このような処理を行うのは、一般に、ドメイン名とIPアドレスの対応関係は頻繁に変更されるものではないため、更新前の情報を利用し続けても実害がない場合が多く、むしろ、更新が成功するまで短期間に何度も(例えば、数秒〜数十秒間隔で)問い合わせを繰り返すような処理を行うと、ネットワークに対して余計な負荷をかけることになるからである。
このことは、換言すると、DNSサーバ1への問い合わせは、可能であれば当然成功させたいものの、何度かは失敗しても実用上は問題ない程度の通信であると言うこともでき、上記他のネットワーク装置(例えば、プリンタ3)にとって、上記DNSプロトコルを用いるデータ通信は、比較的重要度の低いデータ通信であると言える。
さて一方、PC2において、利用者が、印刷機能を有するアプリケーション21を利用している際に所定の操作を行うと、PC2は、プリンタ3に対して印刷データを送信する。この時、PC2のアプリケーション21はLPRプロトコルを用いて印刷要求する一方、プリンタ3のアプリケーション31bはLPDプロトコルを用いて印刷要求の到来を待ち受け、これによりPC2−プリンタ3間でのデータ通信が行われる。
上記LPRプロトコルを用いたデータ通信で通信エラーが発生した場合、PC2は、エラーとなったデータ(パケット)の再送処理を行う。この再送処理は、通信エラーが発生するたびに繰り返される。このような処理を行うのは、通信エラーを無視して印刷処理を継続すると文字化けやその他の印刷不良が発生するおそれがあり、また、単に印刷処理を中断すると中断前までの印刷が無駄になるなどの問題があるからである。
このことは、換言すると、PC2からプリンタ3への印刷データの送信は、エラー回復処理に伴うネットワークへの負荷やスループットの低下を勘案しても、エラーを無視することができない重要な通信である、すなわち、PC2およびプリンタ3にとって、上記LPRプロトコルを用いるデータ通信は、比較的重要度の高いデータ通信であると言える。
そこで、本実施形態において、上記DNSサーバ1、PC2、およびプリンタ3は、DNSプロトコルを用いてデータ通信を行う際には、送信電力レベルを「低」にして通信を行い、一方、LPRプロトコルを用いてデータ通信を行う際には、送信電力レベルを「高」にして通信を行い、これにより、プリンタ3への印刷データを、DNSサーバ1への問い合わせデータよりも優先的に送受信させることができるように構成してある。
以下、プロトコルによって送信電力レベルの高低を変えて通信を行うようにした通信処理について、上記LPRプロトコルを用いて印刷データを送信する場合を例に挙げながら、より詳細に説明する。
LPRプロトコルによる通信を行う場合、まず、プリンタ3側においては、図5に示す
プリンタLPDメイン処理が実行される。この処理は、プリンタ3の電源スイッチをONにすると実行される処理である。この処理を開始すると、プリンタ3は、まず、プリンタ3各部の初期化処理を実行し(S11)、LPDポートでソケットを生成し(S12)、PC2からの接続を待つ状態になる(S13)。この状態において、PC2から接続されると、プロトコルに従って印刷データを受信するとともに、当該印刷データに基づく印刷処理を行う(S14)。
一方、PC2側においては、図6に示す印刷処理が実行される。この処理は、利用者が印刷機能を有するアプリケーション21を利用している際に実行される処理である。この処理を開始すると、PC2は、まず、印刷出力のために必要なデータ(印刷データ)を準備する(S21)。このデータは、例えば文字データや、その文字データに関連するフォント種別、サイズ、色、その他の属性を示すデータ、画像データ、各種制御データ等によって構成されるデータであり、利用者がアプリケーション21(具体的にはワードプロセッサやグラフィックエディターなど)を利用して生成、あるいはハードディスク装置に記録済みのものを読み出す等、様々な方法で準備されることになる。
このような印刷データを準備したら、続いて、PC2は、プリンタ3のLPDポートに対して接続するためのソケットをオープンする(S22)。このS22の処理は、より詳しくは、図7に示すような処理になる。
ソケットオープン処理を開始すると、PC2は、従来と同様のソケット処理を実行することにより(S31)、データの送受信を行なうための仮想的な通信路の確立を行う。
続いて、印刷データの中からポート番号を取り出し(S32)、このポート番号をキーにして出力レベルテーブルを検索する(S33)。この出力レベルテーブルは、ポート番号と送信出力レベルとの対応関係を記録したテーブルで、PC2のメモリに記憶されている。メモリとしては、書き換え不能なROMを用いることができ、この場合は、出力レベルテーブルの内容は固定的なものとなる。また、メモリとして、書き換え可能なROM(例えばフラッシュメモリ)や内蔵電池から供給される電力により記憶内容を保持するように構成された不揮発性RAMを用いてもよく、この場合は、出力レベルテーブルの内容は書き換え可能なものとなる。出力レベルテーブルの内容を書き換え可能な場合は、SNMP(Simple Network Management Protocol)などにより内容を更新できるようにしてもよい。
出力レベルテーブルの内容は、例えば、下記表1のような内容になっている。
ポート番号には、あらかじめ特定のプロトコルにおいて用いられることが決まっている
ものがあり、そのようなポート番号をWell−Knownポート番号と呼んでいる。例えば、表1に付記したように、ポート番号53の場合、DNSプロトコルで用いられることが決まっており、ポート番号515の場合、LPRプロトコルで用いられることが決まっている。そこで、このPC2においては、ポート番号53であれば、送信出力レベルを「Lo」、ポート番号515であれば、送信出力レベルを「Hi」という具合に、ポート番号と送信出力レベルとの対応関係を出力レベルテーブルに記憶させている。
S33の処理では、S32の処理で取り出したポート番号(本処理の場合は515)をキーに上記表1を検索するので、送信出力レベル「Hi」を検出することになる。すなわち、LPRプロトコルを用いる場合、送信出力レベルは「Hi」とすることが決まるのである。ちなみに、DNSプロトコルを用いる場合であれば、データの中から取り出されるポート番号は53となるので、このポート番号をキーに上記出力レベルテーブルを検索すると、送信出力レベル「Lo」を検出することになる。そして、出力レベルテーブルから送信出力レベルを検出したら、その出力レベルをメモリに記憶させ(S34)、後の処理で利用できるようにする。
こうして、S31〜S34の処理を終えると、図6に示したS22の処理を終えたことになり、引き続いて、PC2は、オープンしたソケットに対して印刷データを出力する(S23)。このS23の処理は、より詳しくは、図8に示すデータ書込み処理になる。
データ書込み処理を開始すると、PC2は、まず、データをパケットサイズに合わせて分割する(S41)。そして、分割された個々のパケットに対し、上記S34の処理でメモリに記憶させた送信出力レベルを示す出力レベルフラグを付加する(S42)。この処理により、図2(a)に示したような元データが加工され、図2(b)に示したような出力レベルフラグが付加されたデータとなる。
続いて、プロトコルスタック23で必要な処理を行う(S43)。プロトコルスタック23は、TCP/IP通信の主要部分であり、特にTCPでの通信時には、ヘッダの付加、チェックサムの生成およびチェック、ハンドシェイク、タイムアウト処理、再送など、複雑な処理を行っているが、これらの処理自体はTCP/IPプロトコルスタックが実行する処理として公知なので、ここでの詳細な説明は省略する。
そして、S43の処理が施されたデータを下位層に渡すことにより(S44)、そのデータ(パケット)が送信先へと送信される。以上、S41〜S44の処理は、印刷データすべてが処理されるまで繰り返し実行され(S45:NO)、印刷データすべてが処理されると(S45:YES)、本処理を終了する。
こうして、S41〜S45の処理を終えると、図6に示したS23の処理を終えたことになり、PC2は、オープンしたソケットをクローズし(S24)、本処理を終える。
さて、PC2が以上のような処理を実行することにより、PC2からプリンタ3へは印刷データを構成するパケットが送信されることになる。このとき、上記S13の処理によって待機していたプリンタ3は、上記S14の処理へと移行し、その処理の中で図9に示すデータ受信処理を実行する。
データ受信処理を開始すると、プリンタ3は、まず、パケットを受信する(S51)。このパケットは、上記S41〜S45の処理により作成、送信されてくるものである。
続いて、パケットの中から宛先ポート番号を取り出し(S52)、この宛先ポート番号をキーにして出力レベルテーブルの検索を行う(S53)。すなわち、プリンタ3も、上記PC2と同様、ポート番号と送信出力レベルとの対応関係を記録した出力レベルテーブルをメモリに記憶しており、S52の処理で取り出したポート番号をキーに出力レベルテ
ーブルを検索する。その結果、本実施形態の場合、プリンタ3は、出力レベルテーブルから送信出力レベル「Hi」を検出することになる。
こうして、出力レベルテーブルから送信出力レベルを検出したら、プリンタ3は、Ackパケットを生成し(S54)、そのAckパケットをPC2側に送信する(S55)。S54の処理では、上記S42の処理と同様、S53の処理で検出した送信出力レベルを示す出力レベルフラグがパケットに付加される。すなわち、プリンタ3側から見れば、上記宛先ポート番号は送信元ポート番号となるのであり、送信元ポート番号に基づいて、この送信元ポート番号を利用するLPRプロトコルに対応づけられた送信出力レベルを示す出力レベルフラグを、送信対象データであるパケットに対して付加するのである。そして、S51の処理で受信したパケットに基づいて印刷を実施する(S57)。以上、S51〜S57の処理は、印刷データすべてが処理されるまで繰り返し実行され(S58:NO)、印刷データすべてが処理されると(S58:YES)、本処理を終了する。
以上説明したように、PC2側においては、上記S42の処理により、送信対象となるパケットに出力レベルフラグが付加され、プリンタ3側においては、上記S54の処理により、送信対象となるパケットに出力レベルフラグが付加され、プロトコルスタック23,33での処理後は、図2(c)に示すようなデータとなる。そして、このパケットがドライバ24,34に渡されることになる。
ところで、上記S42、上記S54の処理では、上述の通り、LPRプロトコルを用いたデータ通信を行うため、送信電力レベル「高」を示す出力レベルフラグが付加される。一方、プリンタ3からDNSサーバ1に対しDNSプロトコルを用いて問い合わせを行う場合も、送信対象となるパケットに出力レベルフラグが付加され、図2(c)に示すようなデータとなるが、この場合は、DNSプロトコルを用いたデータ通信を行うため、送信電力レベル「低」を示す出力レベルフラグが付加される。
出力レベルフラグが付加されたパケットを渡されたドライバ14,24,34は、それぞれ、図10に示すようなドライバ送信処理を実行する。
この処理を開始すると、ドライバ14,24,34は、パケットから出力レベルフラグを取り外し(S61)、これにより、図2(d)に示すような実送信データを作成する。
そして、出力レベルフラグが示す送信出力レベルに基づいて、ハードウェア15,25,35に対して電力レベルの指定を行う(S62)。この電力レベルの指定は、PCMCIA(商標)I/F43を介して無線コントローラ41へと伝達され、無線コントローラ41では、バスインターフェース51を介してラッチ57に電力指定信号として伝達され、ラッチ57に記憶される。
そして、実送信データをバッファ(送信データバッファ53)に書き込み(S63)、ハードウェア15,25,35に対してバッファ内のデータについての送信要求を行う(S64)。
その結果、ハードウェア15,25,35は、周囲の通信状況を検出しながらデータの送信が可能かどうかを判断し、データの送信が可能になると、同期回路58が送信器52の出力を切り替えるためのセットアップタイムを反映させたタイミングで、送信器52の出力レベルを切り替える。
出力レベルの切り替えは、ラッチ57の記憶内容に応じて「高」、「低」いずれかとされる。具体例を挙げれば、例えば、LPRプロトコルによるデータ通信の場合は、送信器52の出力レベルを「高」に切り替えることになるが、DNSプロトコルによるデータ通
信であれば、送信器52の出力レベルを「低」に切り替えることになる。
その後、セットアップタイムが経過すると、送信データバッファ53内のデータが送信器52に送り込まれ、実際にデータが送信される。同期回路58は、データの送信終了のタイミングで、送信器52の出力レベルを元に戻す。
以上の様子をタイミングチャートに表すと、図11に示すような図になる。まず、上記S62の処理により、ハードウェア15,25,35に対する電力レベルの指定が行われると、電力指定信号として高電力を示すパルス信号がラッチ57に対して出力される。続いて、上記S63の処理により、実送信データが送信データバッファ53に書き込まれる。
その後、ハードウェア15,25,35は、受信キャリアレベルによって周囲の通信状況を検出し、キャリア断を検出したらデータの送信が可能であると判断し、同期回路58が送信器52の出力を切り替えるためのセットアップタイムを反映させたタイミングで、送信器52の出力レベルを切り替える。
その後、セットアップタイムが経過すると、送信データバッファ53内のデータが送信器52に送り込まれ、実際にデータが送信され、自局送信中の状態になる。そして、データの送信終了後に、同期回路58は、送信器52の出力レベルを元に戻す。
なお、送信器52の出力レベルを元に戻すタイミングで、次のパケットの送信出力レベルが既にわかっている場合もあり、その場合、送信出力レベルを変える必要がないこともあるので、そのような場合は、送信器52の出力レベルを元に戻さず、維持したままにしてもよい。
このように、上記S61〜S64の処理を行うと、ハードウェア15,25,35は、LPRプロトコルによるデータ通信の場合は、送信器52の出力レベルを「高」に切り替えてデータの送信を実施し、一方、DNSプロトコルによるデータ通信の場合は、送信器52の出力レベルを「低」に切り替えてデータの送信を実施するようになる。
そのため、PC2とプリンタ3との間で比較的重要度の高い印刷データの送受信を行いたい状況にある場合、その近くにあるDNSサーバ1に対して、他の無線ネットワーク装置から比較的重要度の低いDNSプロトコルによる問い合わせが実施されたとしても、印刷データの送受信を妨害してしまう可能性は低くなる。もちろん、DNSプロトコルによる問い合わせについては、PC2とプリンタ3との間で印刷データを送信していることが原因で、通信が妨害される可能性は相応に高くなるが、先にも説明した通り、DNSプロトコルによる問い合わせについては、時間が経ってからあらためて実施しても、実用上は大きな問題とならないことが多い。
したがって、このように通信プロトコルに応じて送信出力レベルを変更することができるDNSサーバ1、PC2、およびプリンタ3であれば、比較的重要度が高い印刷データを優先的に送受信することができるようになる。
また、これらDNSサーバ1、PC2、およびプリンタ3は、自身が用いる送信プロトコルに応じて送信出力レベルを切り替える装置であって、送信機側と受信機側とのやり取りを行って送信出力レベルを調節するものではないので、送信機側単独で上記構成を採用しても相応に通信環境を改善することができる。すなわち、例えば、PC2からプリンタ3へ印刷データを送信する場合、上記実施形態では、PC2からプリンタ3への送信パケットおよびプリンタ3からPC2への送信パケットの双方について、送信出力レベルを「
高」とする旨の説明をしたが、PC2からプリンタ3への送信パケットについてだけ、送信出力レベルを「高」とするような構成になった場合でも、相応の効果が期待できるのである。したがって、無線ネットワークへの導入時に、送信側と受信側とを必ずセットにしなければならないものに比べ、既存の無線ネットワークシステムへの導入も容易である。
なお、以上の説明においては、LPRプロトコルとDNSプロトコルとを例示して、これらの違いに応じて送信出力レベルを変更する旨の説明をしたが、これら以外のプロトコルについてもそれぞれ重要度を定めて、送信出力レベルを切り替えれば、様々なプロトコルを用いた通信が行われる環境において、重要度が高いデータを優先的に送受信することができるようになる。
重要度を定める基準は、システム毎に変わり得るものであるが、一例としては、次のような基準を考えることができる。
例えば、上記LPRプロトコルを用いる通信は、利用者がPC2において印刷を指示した際に一回限り実施される通信なので、同じ印刷データを後からプリンタ3が取得することは困難であるのに対し、DNSサーバ1への問い合わせによって得られる情報は、同じ情報を後から得ることも可能なので、前者の方が重要度は高いと言え、これを重要度の基準としてもよい。
また、送信対象となるデータ量が多いプロトコルで再送が多発すると、ネットワークに負荷がかかり、パフォーマンスが低下するのに対し、データ量が少ないプロトコルは、いくらか再送が発生したとしても、絶対的なデータ量が少ないのでネットワークに対する悪影響も少ない。送信対象となるデータ量が多いプロトコルとしては、HTTP、LPR、POPなどのデータ系のプロトコルを挙げることができ、送信対象となるデータ量が少ないプロトコルとしては、DNS、SNMP、NTPなどの管理系のプロトコルを挙げることができるので、これを重要度の基準としてもよい。
[第2実施形態]
次に、上記第1実施形態とは、別の実施形態について説明する。ただし、本実施形態は、ソフトウェアによる具体的な処理内容が上記第1実施形態と異なるものの、その他の点(例えばハードウェア)については上記第1実施形態と共通する部分も多いので、上記第1実施形態と相違する点を中心に説明する。
上記第1実施形態では、ポート番号には、あらかじめ特定のプロトコルにおいて用いられることが決まっているものがある旨を説明したが、プロトコルによっては、ポート番号が動的に割り当てられることもある。例えば、UPnP(商標)のプリントサービスにおいては、動的に割り当てられるポート番号が利用される。
そこで、このような場合には、上記第1実施形態において説明した出力レベルテーブルを、書き換え可能なメモリ上に用意し、ポート番号が動的に割り当てられた後に、ポート番号と送信出力レベルとの対応関係を出力レベルテーブル内に追記することにより、以降の処理において、ポート番号と送信出力レベルとの対応関係を出力レベルテーブルから読み取り可能となるようにする。
以下、具体的な処理について、図12のフローチャートに基づいて説明する。この処理は、PC2がプリンタ3に対して印刷出力する際にPC2において実行される処理である。なお、ここでは、プリンタ3がUPnP(商標)対応のネットワークプリンタであることを前提として説明を続ける。
この処理を開始すると、PC2は、サービスディスカバリ機能により、プリンタ3を探
索し(S71)、プリンタ3が提供するサービス(プリントサービス)についての情報を含むサービスディスクリプタおよびプリンタ3の装置情報を含むデバイスディスクリプタを取得する(S72)。S71の処理で送信されるパケットは、データ量が小さく送信先も特定されていないので、送信出力レベルは「低」にすることが望ましい。そして、印刷サービス(プリンタ3)に対してCreateJob()オペレーションを発行する(S73)。これは、プリンタ3にプリントジョブを生成するものである。
プリンタ3側においてジョブが生成されてデータ受信の準備ができると、プリンタ3はPC2(コントロールポイント)にレスポンス(応答)を返すので、PC2は、このレスポンスを受信する(S74)。このレスポンスの中には、DataSink URLが含まれている。これは、印刷データの実体を送る先を指定するものであり、例えば、” h
ttp://10.134.43.60:54321/upnp/printbasic/datasink/job−5001” といった書式になっている。ここで、” :54321” の部分がポート番号を表している。このポート番号は、サービス(プリンタ
3)側が動的に割り当てるものであるので、コントロールポイント(PC2)側では、前もってこの番号を知ることはできない。
そこで、PC2は、DataSink URLからポート番号を取り出し(S75)、出力レベルテーブル内にある送信出力レベルの設定値について、対応するポート番号を「高」に設定する(S76)。これにより、動的に割り当てられたポート番号についても、ポート番号と送信出力レベルとの対応関係が出力レベルテーブル内に追記されることになる。
以後は、データ送信を行えば(S77)、上記第1実施形態と同様の処理により、データ(パケット)に出力レベルフラグが付加された状態で、そのパケットがドライバに渡され、ドライバはパケットに付加された出力レベルフラグに応じて送信電力を制御することができるようになる。なお、データ送信を終えたら、出力レベルテーブルの対応するポート番号をクリアする(S78)。これは、他の処理において上記ポート番号が使われる場合に、送信出力レベルを「高」にするとは限らないためである。
以上説明したように、上記S71〜S78の処理を実行するPC2によれば、印刷データの送信先となるポート番号が動的に割り当てられる構成となっていても、比較的重要度が高い印刷データを優先的に送受信することができるようになる。
[第3実施形態]
次に、上記第1,第2実施形態とは、別の実施形態について説明する。ただし、本実施形態も、ソフトウェアによる具体的な処理内容が上記第1実施形態と異なるものの、その他の点(例えばハードウェア)については上記第1実施形態と共通する部分も多いので、上記第1実施形態と相違する点を中心に説明する。
上記第1実施形態においては言及しなかったが、PC2においては複数の処理が時分割制御によって実行されることがあり、その場合、異なるプロトコルを用いる通信があたかも同時進行しているかのように実施されることがある。
例えば、第1のアプリケーションによって、PC2からプリンタ3へLPRプロトコルを用いて断続的にデータ送信が行われている場合に、第2のアプリケーションによって、PC2からDNSサーバ1へDNSプロトコルを用いてデータ送信が行われることがあり、さらに、第3のアプリケーションによって、PC2からプリンタ3とは別のプリンタ(図示略)へLPRプロトコルを用いてデータ送信が行われることもある。
このような状況下では、LPRプロトコルを用いて送信されるデータ(パケット)とDNSプロトコルを用いて送信されるデータ(パケット)とが混在する状態で、データの送出が行われることになる。
しかし、使用するハードウェアの制限により、各パケット毎に送信出力レベルの切替制御を行うことが困難な場合もある。
そこで、第3実施形態においては、図13に示すように、送信出力レベル「高」のソケットが存在する間は、すべてのパケットについて送信出力レベル「高」で送信を行い、送信出力レベルを「低」には切り替えないように制御する方式を採用した。
すなわち、図13に示すように、まず、LPRプロトコルを用いる通信が開始され、パケットが断続的に送信される場合に、引き続いて、DNSプロトコルを用いる通信が実行されても、その際の送信出力レベルは「高」を維持する。また、さらにLPRプロトコルを用いる別の通信が開始された場合、先に開始したLPRプロトコルを用いる通信が完了しても、後から開始したLPRプロトコルを用いる通信が完了していなければ、その際の送信出力レベルは「高」を維持する。そして、後から開始したLPRプロトコルを用いる通信が完了し、送信出力レベル「高」のソケットが存在しなくなったら、その時点で送信出力レベルを「低」に切り替える。
以上のような切替制御は、送信出力レベル「高」のソケットがオープンされるとインクリメントされ、送信出力レベル「高」のソケットがクローズされるとデクリメントされるカウンタを用い、このカウンタ値が0の場合は送信出力レベル「低」、カウンタ値が1以上の場合は送信出力レベル「高」とする制御を行うことにより実現される。
より具体的な例を挙げて実施方法を説明すれば、カウンタの初期値は0、送信出力レベルの初期値は「低」とし、出力レベルフラグとしては「変更無し」、「高」、「解除」の三値をとるようにする。
そして、重要度の高い通信で用いるソケットのオープン時に、送信出力レベル「高」の指定を行い、当該ソケットのクローズ時に、送信出力レベル「解除」の指定を行う。重要度の高い通信において送信される複数のパケットは、最初の送信パケットに対して送信出力レベル「高」を示す出力レベルフラグが付加され、最後の送信パケットに対して送信出力レベル「解除」を示す出力レベルフラグが付加され、これら以外の送信パケットに対しては送信出力レベル「変更無し」を示す出力レベルフラグが付加される。また、重要度の低い通信において送信される複数のパケットに対しては、すべて送信出力レベル「変更無し」を示す出力レベルフラグが付加される。
ドライバには、上記カウンタを設け、カウンタ値が0の場合は送信出力レベル「低」となるように、データ通信用のハードウェアに対する制御を行う。そして、送信出力レベル「高」を示す出力レベルフラグが付加されたパケットが到来する毎に上記カウンタをインクリメントし、カウンタ値が1以上になれば、送信出力レベル「高」となるように、データ通信用のハードウェアに対する制御を行う。一方、送信出力レベル「解除」を示す出力レベルフラグが付加されたパケットが到来する毎に上記カウンタをデクリメントし、カウンタ値が0になれば、送信出力レベル「低」となるように、データ通信用のハードウェアに対する制御を行う。
以上のような処理を実行すれば、使用するハードウェアの制限により、各パケット毎に送信出力レベルの切替制御を行うことが困難な場合であっても、重要度の高いデータが混在していれば送信出力レベルが「高」になるので、比較的重要度が高いデータを優先的に送受信することができるようになる。
[第4実施形態]
次に、上記第1〜第3実施形態とは、別の実施形態について説明する。ただし、本実施形態も、ソフトウェアによる具体的な処理内容が上記第1実施形態と異なるものの、その他の点(例えばハードウェア)については上記第1実施形態と共通する部分も多いので、上記第1実施形態と相違する点を中心に説明する。
一般に、TCPプロトコルを用いるデータ通信は、比較的高い信頼性が要求される通信であるのに対し、UDPプロトコルを用いるデータ通信は、TCPプロトコルを用いるデータ通信ほどの信頼性は要求されないことが多い。
したがって、TCPプロトコルを用いるデータ通信を行う場合は、送信出力レベルを「高」とし、UDPプロトコルを用いるデータ通信を行う場合は、送信出力レベルを「低」としてもよい。
TCP/UDPの違いは、アプリケーションがソケットインターフェースの使用を開始するときに判別できるので、ソケットのオープン時にTCPの場合は出力レベルフラグに送信出力レベル「高」を設定し、UDPの場合は出力レベルフラグに送信出力レベル「低」を設定する。
以上のような処理を実行すれば、TCPプロトコルを利用するデータ通信を、UDPプロトコルを利用するデータ通信よりも優先的に処理できるようになる。
なお、UDPを使っている場合でも、信頼性の点だけではなく、他の理由があってUDPを用いている場合がある。例えば、リアルタイム性が要求される動画配信では、データロスのリスクより、再送による時間のずれを問題視するため、UDPを使用している。また、多数の受信者に対して同時に動画を配信する場合などは、TCPは使用できないのでUDPを使用しているという事情もある。
このような場合に、UDPはTCPと異なり、エラー検出や再送を行わないため、動画の品質を落とさないよう、元々のエラー発生率をより下げる必要がある。そのため、UDPプロトコルを用いるデータ通信を行う場合は、送信出力レベルを「高」とし、TCPプロトコルを用いるデータ通信を行う場合は、送信出力レベルを「低」としてもよい。つまり、TCP/UDPのどちらを重要視するかは、利用者が重要視する内容に応じて変わりうるのである。
[第5実施形態]
次に、上記第1〜第4実施形態とは、別の実施形態について説明する。ただし、本実施形態も、ソフトウェアによる具体的な処理内容が上記第1実施形態と異なるものの、その他の点(例えばハードウェア)については上記第1実施形態と共通する部分も多いので、上記第1実施形態と相違する点を中心に説明する。
上記各実施形態においては、ソケットインターフェースよりも下位の層において、通信に用いるプロトコル毎に送信出力レベルを設定する旨の説明をしたが、アプリケーションが明示的に送信出力レベルを指定し、ソケットインターフェースよりも下位の層では、アプリケーションからの指定に基づいて、通信に用いるプロトコル毎に送信出力レベルを設定するようにしてもよい。
より具体的には、ソケットインターフェースには、オプション値を設定するための機能SETSOCKOPTが用意されており、様々な設定を行うことができるので、この機能を用いて、各アプリケーションが、自身の通信が信頼性を要求されるプロトコルである場
合は、送信出力レベル「高」を指定し、そうでない場合は、送信出力レベル「低」を指定する。
例えば、上記第2実施形態で説明したUPnP(商標)のプリントサービスの場合、DataSink URLに対するデータ送信であることは、アプリケーションのレベルで認識しているので、DataSink URLに対するデータ送信の場合は、アプリケーションが送信出力レベル「高」を指定するようにしてもよい。
また、同様に、DataSink URLに対するデータ送信がHTTPプロトコルを用いて行われることも、アプリケーションは認識しているので、HTTPプロトコルを用いる場合には、使用するポート番号とは無関係にアプリケーションが送信出力レベル「高」を指定するようにしてもよい。
以上のような処理を行えば、アプリケーションのレベルで送信出力レベルが明示的に指定されるので、アプリケーションよりも下位の層において送信出力レベルの判断をしなくてもよくなり、しかも、先に説明した実施形態と同様、比較的重要度が高いデータを優先的に送受信することができるようになる。
[その他の実施形態]
以上、本発明の実施形態について説明したが、本発明は上記の具体的な実施形態に限定されず、この他にも種々の形態で実施することができる。
例えば、上記実施形態では、送信出力レベルを「高」/「低」いずれかに切り替える例を示したが、より多段階に切り替える構成としてもよい。例えば、送信器52が送信出力レベルを10段階に切り替え可能な場合、出力レベルフラグは1〜10までの数値をとるフラグとし、この数値を様々なプロトコルに対応づけて出力レベルテーブルに記憶させ、送信器52の制御に利用するように構成するとよい。
DNSサーバ、PC、およびプリンタが備えるネットワーク関連のソフトウェア群およびハードウェアの階層図である。 送信対象となるデータ(パケット)のデータ構造図である。 無線LANカードのブロック図である。 無線コントローラのブロック図である。 プリンタLPDメイン処理のフローチャートである。 印刷処理のフローチャートである。 ソケットオープン処理のフローチャートである。 データ書き込み処理のフローチャートである。 データ受信処理のフローチャートである。 ドライバ送信処理のフローチャートである。 データ送信状態を示すタイミングチャートである。 印刷処理のフローチャートである。 複数のプロトコルが時分割で処理される場合のデータ送信状態を示すタイミングチャートである。
1・・・DNSサーバ、2・・・パーソナルコンピュータ(PC)、3・・・プリンタ、11,21,31a,31b・・・アプリケーション、12,22,32a,32b・・・ソケットインターフェース、13,23,33・・・プロトコルスタック、14,24,34・・・ドライバ、15,25,35・・・ハードウェア、41・・・無線コント
ローラ、42・・・アンテナ、44・・・CPU、45・・・ROM、46・・・RAM、47・・・システムバス、51・・・バスインターフェース、52・・・送信器、53・・・送信データバッファ、54・・・受信器、55・・・受信データバッファ、56・・・制御回路、57・・・ラッチ、58・・・同期回路。

Claims (4)

  1. 無線にてデータを送信可能で、データ送信時の送信出力レベルを、第1の送信出力レベルまたは該第1の送信出力レベルよりも送信出力レベルの低い第2の送信出力レベルに変更してデータ送信可能なデータ送信手段と、
    複数のデータ送信用プロトコルの中から選ばれる一つのプロトコルに従って、前記送信対象データを処理するデータ処理手段と、
    前記データ処理手段によって処理された第1の送信対象データを受信可能な送信先のポート番号を該送信先から取得する送信先ポート番号取得手段と、
    前記送信先ポート番号取得手段により取得されたポート番号と前記第1の送信出力レベルとを対応付けて記憶する記憶手段と
    を備え
    前記データ処理手段は、アプリケーション、ソケットインターフェース、およびプロトコルスタックの各階層をなすソフトウェア群から構成されるとともに、前記アプリケーションから前記ソケットインターフェース、前記プロトコルスタックを通してドライバへとデータを伝送すると、該ドライバが前記データ送信手段を制御して、該データ送信手段が前記送信対象データを送信するように構成されており、
    前記アプリケーションは、前記記憶手段に記憶されたポート番号に対し、該ポート番号に対応付けて記憶された送信出力レベルに基づいて前記送信対象データを送信する際の送信出力レベルを指定するとともに、前記ソケットインターフェースの階層へ前記送信対象データを伝送し、
    前記ソケットインターフェースの階層で、前記指定された送信出力レベルを示す出力レベル情報を前記送信対象データに対して付加し、
    前記ドライバは、前記送信対象データに付加された出力レベル情報に基づいて送信出力レベルを変更し、データ送信手段が前記送信対象データを送信するように、前記データ送信手段を制御することを特徴とするネットワーク装置。
  2. 前記データ送信手段により前記記憶手段に記憶された送信先のポート番号に対して前記第1の送信対象データを送信したことを条件に、該ポート番号を前記記憶手段から削除するポート番号削除手段と
    を備えたことを特徴とする請求項1に記載のネットワーク装置。
  3. 前記記憶手段には、前記送信先ポート番号取得手段により取得されたポート番号以外にも、前記送信対象データの送信先のポート番号と該ポート番号に対して前記送信対象データを送信する際の前記送信出力レベルとが対応付けて記憶されており、
    前記ドライバは、前記送信先ポート番号取得手段が送信先からポート番号を取得する際に送信する要求情報としての第2の送信対象データを、該第2の送信対象データの送信先のポート番号に対応付けて前記記憶手段に記憶された送信出力レベルで送信するように、前記データ送信手段を制御する
    ことを特徴とする請求項1または請求項2に記載のネットワーク装置。
  4. 無線にてデータを送信可能で、データ送信時の送信出力レベルを、第1の送信出力レベルまたは該第1の送信出力レベルよりも送信出力レベルの低い第2の送信出力レベルに変更してデータ送信可能なデータ送信手段を備えたネットワーク装置において用いられるプログラムであって、
    複数のデータ送信用プロトコルの中から選ばれる一つのプロトコルに従って、前記送信対象データを処理するデータ処理手段と、
    前記データ処理手段によって処理された第1の送信対象データを受信可能な送信先のポート番号を該送信先から取得する送信先ポート番号取得手段と、
    前記送信先ポート番号取得手段により取得されたポート番号と前記第1の送信出力レベルとを対応付けて記憶手段に記憶させる記憶制御手段と、
    を備え、
    前記データ処理手段は、アプリケーション、ソケットインターフェース、およびプロトコルスタックの各階層をなすソフトウェア群から構成されるとともに、前記アプリケーションから前記ソケットインターフェース、前記プロトコルスタックを通してドライバへとデータを伝送すると、該ドライバが前記データ送信手段を制御して、該データ送信手段が前記送信対象データを送信するように構成されており、
    前記アプリケーションは、前記記憶手段に記憶されたポート番号に対し、該ポート番号に対応付けて記憶された送信出力レベルに基づいて前記送信対象データを送信する際の送信出力レベルを指定するとともに、前記ソケットインターフェースの階層へ前記送信対象データを伝送し、
    前記ソケットインターフェースの階層で、前記指定された送信出力レベルを示す出力レベル情報を前記送信対象データに対して付加し、
    前記ドライバは、前記送信対象データに付加された出力レベル情報に基づいて送信出力レベルを変更し、データ送信手段が前記送信対象データを送信するように、前記データ送信手段を制御することを特徴とするプログラム。
JP2007061906A 2007-03-12 2007-03-12 ネットワーク装置、およびネットワーク装置用のプログラム Expired - Fee Related JP4535075B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007061906A JP4535075B2 (ja) 2007-03-12 2007-03-12 ネットワーク装置、およびネットワーク装置用のプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007061906A JP4535075B2 (ja) 2007-03-12 2007-03-12 ネットワーク装置、およびネットワーク装置用のプログラム

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2003310584A Division JP4029804B2 (ja) 2003-09-02 2003-09-02 ネットワーク装置、および送信出力レベル変更方法

Publications (2)

Publication Number Publication Date
JP2007174704A JP2007174704A (ja) 2007-07-05
JP4535075B2 true JP4535075B2 (ja) 2010-09-01

Family

ID=38300561

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007061906A Expired - Fee Related JP4535075B2 (ja) 2007-03-12 2007-03-12 ネットワーク装置、およびネットワーク装置用のプログラム

Country Status (1)

Country Link
JP (1) JP4535075B2 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8429715B2 (en) * 2008-08-08 2013-04-23 Microsoft Corporation Secure resource name resolution using a cache
US7917616B2 (en) 2008-08-08 2011-03-29 Microsoft Corporation Secure resource name resolution
JP5350004B2 (ja) 2009-02-19 2013-11-27 キヤノン株式会社 通信装置、通信装置の制御方法及びプログラム
JP5423404B2 (ja) * 2010-01-08 2014-02-19 日本電気株式会社 オフロード処理装置、および、通信システム
JP6363871B2 (ja) * 2014-05-16 2018-07-25 キヤノン株式会社 通信装置、通信装置の制御方法およびプログラム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6361516A (ja) * 1986-09-01 1988-03-17 Victor Co Of Japan Ltd 無線通信装置
JP2000183935A (ja) * 1998-12-10 2000-06-30 Omron Corp ノード及びノード内のデータ処理方法
JP2002095065A (ja) * 2000-07-07 2002-03-29 Hitachi Ltd 無線基地局、無線端末及びコンテンツプロバイダ
JP2003125022A (ja) * 2001-10-18 2003-04-25 Sony Corp 通信処理装置、および通信処理方法、並びにコンピュータ・プログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6361516A (ja) * 1986-09-01 1988-03-17 Victor Co Of Japan Ltd 無線通信装置
JP2000183935A (ja) * 1998-12-10 2000-06-30 Omron Corp ノード及びノード内のデータ処理方法
JP2002095065A (ja) * 2000-07-07 2002-03-29 Hitachi Ltd 無線基地局、無線端末及びコンテンツプロバイダ
JP2003125022A (ja) * 2001-10-18 2003-04-25 Sony Corp 通信処理装置、および通信処理方法、並びにコンピュータ・プログラム

Also Published As

Publication number Publication date
JP2007174704A (ja) 2007-07-05

Similar Documents

Publication Publication Date Title
KR100636186B1 (ko) 양방향 터널 설정 방법 및 시스템
US7747779B2 (en) Information processing apparatus, information processing method, and medium storing therein program for executing the method
EP2297648B1 (en) Network controller based pass-through communication mechanism between local host and management controller
US7720097B2 (en) Communication apparatus, communication method, communication program and recording medium
US8934116B2 (en) Line concentrator and information processing system using the same, assigning transmitted data to all devices in the group of information processing devices
JP4535075B2 (ja) ネットワーク装置、およびネットワーク装置用のプログラム
US8478869B2 (en) Information processing device and program
US7532620B2 (en) Routing table synchronization method, network apparatus, and routing table synchronization program
JP4029804B2 (ja) ネットワーク装置、および送信出力レベル変更方法
JP2009296084A (ja) マルチパス通信システム
JP2004336716A (ja) アドホックネットワークにおけるパスmtu発見システム及び方法
US6947435B1 (en) Radio communication system and apparatus, communication method and program recording medium therefor
US8369245B2 (en) Communication apparatus having network interfaces and responding to device search, communication method, and storage medium
JP2010193276A (ja) 通信装置、通信装置の制御方法及びプログラム
CN109510912B (zh) 信息处理装置、其控制方法和存储介质
US8120806B2 (en) Communication port, and method for providing a communication port
CN116233279A (zh) 一种报文处理方法、设备及系统
JP2005094053A (ja) ネットワーク通信装置
US20230073061A1 (en) Mesh network update system and method thereof
KR101586761B1 (ko) 네트워크에서 네트워크 성분들을 관리하기 위한 방법과 네트워크 성분
JP2003289319A (ja) 制御装置、ネットワーク通信方法及び制御プログラム
CN113726874A (zh) 一种会话表的备份方法、主机设备及双机热备系统
CN108632898B (zh) 一种通信设备以及封包传送的方法
JP4368776B2 (ja) ネットワーク機器、ネットワーク機器の制御方法、プログラム及び記録媒体
JP5889122B2 (ja) 制御ノード及び通信制御方法

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070411

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070411

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100309

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100428

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20100428

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100525

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100607

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130625

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

Ref document number: 4535075

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees