JP2008160515A - 電子機器 - Google Patents

Abstract

【課題】スループットを向上させることが可能な電子機器を提供する。
【解決手段】携帯電話が、データを記憶すると共に、６４［ＫＢ］より大きいウィンドウサイズが設定される受信バッファ３０５と、受信バッファ３０５におけるウィンドウサイズの設定された部分の容量の残量が６４［ＫＢ］以下の場合は、この容量の残量を、通信の相手に通知する通知ウィンドウサイズとして設定し、受信バッファ３０５におけるウィンドウサイズの設定された部分の容量の残量が６４［ＫＢ］より大きい場合は、通信の相手に通知する通知ウィンドウサイズとして６４［ＫＢ］を設定するウィンドウサイズ制御部３０６とを備える。
【選択図】図３

Description

本発明は、電子機器に関する。

従来、通信においては様々なプロトコルが使用されている。例えば、Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（以下、ＴＣＰと記す。）を用いたデータの送受信システムが知られている。このＴＣＰのデータの送受信方法について、図６、図７及び図８を参照して説明する。図６及び図７は、ＴＣＰにおけるデータの送受信の概念図であり、図８は、ウィンドウサイズと、パケット往復時間と、スループットとの関係を示すグラフである。なお、図６及び図７に示される例では、サーバ６０１からパソコン（以下、単にＰＣとも記す。）６０２にデータを送信する場合を例に挙げている。また、図６及び図７では、サーバ６０１がデータの送信側の電子機器であり、ＰＣ６０２がデータの受信側の電子機器である。

図６に示されるように、ＴＣＰでは、送信したデータが受信側のＰＣ６０２に到達したとき、受信側のＰＣ６０２は送信側のサーバ６０１に対してデータの到達をＡＣＫパケット（以下、単にＡＣＫとも記す。）によって通知する。送信側のサーバ６０１は送信したデータに対するＡＣＫが受信できれば、ＰＣ６０２に送信データが到達したことが確認できる（図６の（１））。逆に、ＡＣＫが一定時間内に返ってこなければ、データが喪失した可能性があるため、同じデータを再送する（図６の（２））。

図６に示されるＡＣＫの送受信処理によって、ＴＣＰは、パケットが途中で喪失した場合であっても、データを相手に届けることができ、信頼性のある通信を可能にしている。

また、図７に示されるように、ＴＣＰではウィンドウサイズという概念を導入している。ウィンドウサイズとは、ＡＣＫを待たずに送受信できるデータ量の総量である（特許文献１、特許文献２参照）。図７に示される例では、データ［１］、データ［２］、データ［３］、データ［４］が１つのウィンドウサイズの範囲内のデータとして送信されている。

このウィンドウサイズによって、送信側のサーバ６０１は送信したパケットのＡＣＫを待たずに複数のパケットを送信することができる。このウィンドウサイズを用いた通信システムの仕組みは、受信側のＰＣ６０２が受信バッファを用意し、この受信バッファの残量を送信側のサーバ６０１に送信することで実現されている。

一般に、このウィンドウサイズを大きくすれば、データ通信時のスループットが向上することが知られている。これは、図８に示されるように、ＴＣＰのようなウィンドウ制御プロトコルにおけるスループットに関して成立するといわれている以下の関係式からも明らかである。なお、スループットとは、本明細書では、データの送受信の際の単位時間あたりのデータの転送量を意味する。また、図８において、６４Ｋ、３２Ｋ、１６Ｋとは、それぞれ、６４［ＫＢ］、３２［ＫＢ］、１６［ＫＢ］のことを意味する。

［スループット］≦［ウィンドウサイズ］÷［パケット往復時間］
このように、ウィンドウサイズを大きくするほどスループットが向上するが、そのサイズは最大６４［ＫＢ］（＝６５，５３５バイト）に制限される。これは、受信側の電子機器が送信側の電子機器に通知するＡＣＫ上のウィンドウサイズを設定するフィールドが１６ビットしかないことによるプロトコル上の制限である。すなわち、ＴＣＰでは、６４［ＫＢ］が、通信に使用するプロトコルにおいて通知可能な最大のウィンドウサイズとなる。
特開平８−３０５６４３号公報 特開２０００−２５３０９６号公報

上述のように、通信ではプロトコル毎に通知可能な最大のウィンドウサイズが設定されている。例えば、ＴＣＰでは、プロトコル上の制限から、受信側の電子機器が送信側の電子機器に通知するウィンドウサイズの上限は６４［ＫＢ］に制限されている。そのため、従来技術では、受信側の電子機器の内部ウィンドウサイズとして６４［ＫＢ］を設定している。内部ウィンドウサイズとは、電子機器が受信バッファに設定したウィンドウサイズのことである。

しかしながら、このような従来技術では、６４［ＫＢ］のウィンドウサイズが設定された受信バッファの一部が使用されている場合、送信側の電子機器に通知する通知ウィンドウサイズは、６４［ＫＢ］のうちデータの記憶が可能な内部ウィンドウサイズの部分のみとなり、６４［ＫＢ］よりも小さい値となる。そのため、従来技術では、受信側の電子機器から送信側の電子機器へと通知される通知ウィンドウサイズが６４［ＫＢ］以下となる場合が多くなり、通信システムのスループットが低下する場合があるという問題点を有している。

つまり、従来技術では、受信側の電子機器から送信側の電子機器へと通知される通知ウィンドウサイズが、通信に使用するプロトコルにおいて通知可能な最大のウィンドウサイズ以下となる場合が多くなり、通信システムのスループットが低下する場合があるという問題点を有している。

本発明は、上記事情に鑑みなされたもので、スループットを向上させることが可能な電子機器を提供することを目的とする。

本発明の電子機器は、データを記憶する、ウィンドウサイズが設定された記憶手段と、前記記憶手段における前記ウィンドウサイズが設定された部分の容量の残量が所定のしきい値より小さい場合は、該容量の残量を、通信の相手に通知する通知ウィンドウサイズとして設定し、前記容量の残量が所定のしきい値以上である場合は、通信の相手に通知する通知ウィンドウサイズとして通信に使用するプロトコルにおいて通知可能な最大のウィンドウサイズを設定するウィンドウサイズ制御手段とを備える。

また、本発明の電子機器は、前記ウィンドウサイズ制御手段は、前記通知ウィンドウサイズを前記最大のウィンドウサイズと設定した後、所定時間、通信の相手側からデータを受信しない場合は、前記所定のしきい値を増加させる。

このように、本発明は、通信に使用するプロトコルにおいて通知可能な最大のウィンドウサイズより大きいウィンドウサイズが設定された記憶手段におけるウィンドウサイズの設定された部分の容量の残量が通信に使用するプロトコルにおいて通知可能な最大のウィンドウサイズ以下の場合は、この容量の残量を、通信の相手に通知する通知ウィンドウサイズとして設定し、記憶手段におけるウィンドウサイズの設定された部分の容量の残量が通信に使用するプロトコルにおいて通知可能な最大のウィンドウサイズより大きい場合は、通信の相手に通知する通知ウィンドウサイズとして通信に使用するプロトコルにおいて通知可能な最大のウィンドウサイズを設定する。そのため、本発明は、ウィンドウサイズが設定された記憶手段の一部が使用されていても通知ウィンドウサイズとして通信に使用するプロトコルにおいて通知可能な最大のウィンドウサイズを通知することができる場合があり、スループットを向上させることができる。

以下、図面を参照して、本発明の電子機器の一実施形態について説明する。図１は、本発明の電子機器の一実施形態が適用される通信システムの概略図である。

図１に示されるように、図１に示される通信システムは、サーバ１０１と、本発明の電子機器の一実施形態となる携帯電話１０２と、ネットワーク１０３と、基地局１０４とを備える。図１に示される例では、サーバ１０１がデータの送信側であり、携帯電話１０２がデータの受信側である。なお、携帯電話１０２と基地局１０４との間は無線によりデータの送受信が行われる。また、ネットワーク１０３は、例えばインターネットなどである。このネットワーク１０３は、有線や無線やこれらの組み合わせのネットワークであって良い。

次に、図１に示されるサーバ１０１の内部構成について図２を参照して説明する。図２は、図１に示されるサーバ１０１の内部構成のブロック図である。

図２に示されるように、サーバ１０１は、データの送信処理を行う送信部２０１と、データの受信処理を行う受信部２０２と、送受信するデータなど各種のデータを記憶する記憶部２０３と、各部の機能を制御する制御部２０４とを備える。なお、図２に示される各部のうちの少なくとも１つが、ＣＰＵ（不図示）が記憶部２０３に記憶されたプログラムと協働することにより、その機能が実現されるとしても良い。

次に、図１に示される携帯電話１０２の内部構成について図３を参照して説明する。図３は、図１に示される携帯電話１０２の内部構成のブロック図である。

図３に示されるように、図１に示される携帯電話１０２は、データの送信処理を行う送信部３０１と、データの受信処理を行う受信部３０２と、送受信するデータなど各種のデータを記憶する記憶部３０３と、各部の機能を制御する制御部３０４とを備える。記憶部３０３は、送信側のサーバ１０１から送信されたデータを格納する受信バッファ３０５を備える。また、制御部３０４は、送信側のサーバ１０１に通知するウィンドウサイズを制御するウィンドウサイズ制御部３０６を備える。なお、図３に示される各部のうちの少なくとも１つが、ＣＰＵ（不図示）が記憶部３０３に記憶されたプログラムと協働することにより、その機能が実現されるとしても良い。

次に、図１に示される携帯電話１０２の動作について図４を参照して説明する。図４は、図１に示される携帯電話１０２の動作のフローチャートである。

図４に示されるように、携帯電話１０２の制御部は、送信側のサーバ１０１にウィンドウサイズを通知する場合、内部ウィンドウサイズが設定された受信バッファのうち、データの記憶が可能な領域として残っている容量（以下、残量ともいう。）を確認する（Ｓ４０１）。なお、受信バッファの内部ウィンドウサイズは、ユーザの初期設定により、６４［ＫＢ］より大きい値に設定されている。なお、本実施形態ではＴＣＰを用いるため、６４［ＫＢ］が通信に使用するプロトコルにおいて通知可能な最大のウィンドウサイズとなる。

次に、携帯電話１０２のウィンドウサイズ制御部は、内部ウィンドウサイズが設定された受信バッファの残量が６４［ＫＢ］より大きいか否かを判断する（Ｓ４０２）。そして、処理は、受信バッファの残量が６４［ＫＢ］より大きければ（ＹＥＳ）、Ｓ４０３に移行する。Ｓ４０３では、携帯電話１０２のウィンドウサイズ制御部は、サーバ１０１に通知する通知ウィンドウサイズを６４［ＫＢ］と設定し、サーバ１０１に通知する。

次に、携帯電話１０２の制御部は、通知ウィンドウサイズを６４［ＫＢ］に設定した後、所定時間内にサーバ１０１からデータを受信したか否かを確認する。携帯電話１０２のウィンドウサイズ制御部は、通知ウィンドウサイズを６４［ＫＢ］に設定した後、所定時間内にサーバ１０１からデータを受信しない場合には、次にサーバ１０１に通知するウィンドウサイズを６４［ＫＢ］から６０［ＫＢ］に再設定し、動作を終える（Ｓ４０４，Ｓ４０５）。

また、携帯電話１０２の制御部は、サーバ１０１からのデータの受信待機状態の際に、割込み処理要求を受信したか否かを判断する（Ｓ４０６）。そして、携帯電話１０２の制御部は、サーバ１０１からのデータの受信待機状態の際に、割り込み処理要求を受信していれば（ＹＥＳ）、Ｓ４０７において割り込み処理を行ってから動作を終了する。また、携帯電話１０２の制御部は、サーバ１０１からのデータの受信待機状態の際に、割り込み処理要求を受信しなければ（ＮＯ）、サーバ１０１からの受信待機状態を継続する。ここで、割り込み処理としては、例えばデータの受信処理や、データの送信処理や、ＴＣＰのクローズ処理などが挙げられるが、本発明はこのような場合に限定されるものではなく、その他適宜な割り込み処理をＳ４０６、Ｓ４０７における割り込み処理として用いることができる。

なお、本発明の電子機器では、再設定するウィンドウサイズとして６０［ＫＢ］に限定されるものではなく、６２［ＫＢ］や、５０［ＫＢ］などその他の適宜な値を選択することができる。また、再設定する回数も、１回に限定されるものではなく、再設定後、再び所定時間、データを受信しない場合は、さらに１回以上、ウィンドウサイズを小さく再設定するとしても良い。また、本発明の電子機器では、所定回数以上、ＡＣＫを送信した後は、受信バッファの残量が６４［ＫＢ］より大きい場合に通知するウィンドウサイズとして６４［ＫＢ］に戻すとしても良い。

他方、携帯電話１０２のウィンドウサイズ制御部は、Ｓ４０２の判断において、内部ウィンドウサイズの受信バッファの残量が６４［ＫＢ］より大きくなければ（ＮＯ）、受信バッファの残量を通知ウィンドウサイズに設定し、サーバ１０１に通知する（Ｓ４０８）。

上記本実施形態の携帯電話１０２の動作についてさらに説明する。図５に示されるように、本実施形態の携帯電話１０２は、予め内部ウィンドウサイズとして６４［ＫＢ］より大きい値が受信バッファに設定されている。図５に示される例では、受信バッファに設定された内部ウィンドウサイズとして１２８［ＫＢ］とされている。もちろん、本発明の電子機器の内部ウィンドウサイズの値としては１２８［ＫＢ］に限定されるものではなく、６４［ＫＢ］より大きい値であれば良い。図５は、本発明の電子機器の一実施形態における、内部ウィンドウサイズの構成を示す概略図である。

そして、本実施形態の携帯電話１０２は、１２８［ＫＢ］の内部ウィンドウサイズのうち、例えば１０［ＫＢ］が使用されていると、内部ウィンドウサイズの残量を１１８［ＫＢ］と認識する。そして、この１１８［ＫＢ］は６４［ＫＢ］以上であるため、携帯電話１０２は、サーバ１０１に通知する通知ウィンドウサイズを６４［ＫＢ］と設定する。

以上のように、本発明の電子機器の一実施形態の携帯電話１０２は、内部ウィンドウサイズの大きさを６４［ＫＢ］より大きく設定し、内部ウィンドウサイズが設定された受信バッファの残量が６４［ＫＢ］より大きければ送信側の携帯電話へと通知するウィンドウサイズを６４［ＫＢ］とし、内部ウィンドウサイズが設定された受信バッファの残量が６４［ＫＢ］以下の場合は送信側の携帯電話へと通知する通知ウィンドウサイズを受信バッファの残量の値に設定する。

そのため、本発明の電子機器の一実施形態の携帯電話１０２は、内部ウィンドウサイズが設定された受信バッファの一部が使用されている場合であっても、送信側の携帯電話に対して、最大の値である６４［ＫＢ］を通知ウィンドウサイズに設定して通知することができる場合が多くなるため、データの送受信のスループットを向上させることができる。

また、本発明の電子機器の一実施形態の携帯電話１０２は、送信側のサーバ１０１に６４［ＫＢ］のウィンドウサイズを通知した後、所定時間、送信側のサーバ１０１からデータの受信が確認できない場合は、送信側のサーバ１０１に通知する通知ウィンドウサイズを、例えば６０［ＫＢ］というように、６４［ＫＢ］から少なくする。そのため、本発明の電子機器の一実施形態の携帯電話１０２では、例えば通信システムに輻輳が発生している恐れがある場合というように、所定時間、送信側のサーバ１０１からデータの受信が確認できない場合、自律的に通知ウィンドウサイズを小さくするため、適切な輻輳制御を行うことができる。

さらに、本発明の電子機器の一実施形態の携帯電話１０２は、受信側の携帯電話１０２の内部のみで処理が行われるため、例えば送信側のサーバ１０１や、その他の通信機器の処理内容の変更を必要とせずに実現することができる。

ここで、上記実施形態において、ＴＣＰを用いて通信に使用するプロトコルにおいて通知可能な最大のウィンドウサイズとして６４［ＫＢ］を用いたが、本発明の電子機器はこのような場合に限定されるものではなく、ＴＣＰ以外のプロトコルを用い、通信に使用するプロトコルにおいて通知可能な最大のウィンドウサイズが他の値の場合であっても適用可能である。

本発明の電子機器の一実施形態が適用される通信システムの概略図である。 図１に示されるサーバ１０１の内部構成のブロック図である。 図１に示される携帯電話１０２の内部構成のブロック図である。 図１に示される携帯電話１０２の動作のフローチャートである。 本発明の電子機器の一実施形態における、内部ウィンドウサイズの構成を示す概略図である。 ＴＣＰにおけるデータの送受信の概念図である。 ＴＣＰにおけるデータの送受信の概念図である。 ウィンドウサイズと、パケット往復時間と、スループットとの関係を示すグラフである。

符号の説明

１０１ サーバ
１０２ 携帯電話
１０３ ネットワーク
１０４ 基地局
２０１ 送信部
２０２ 受信部
２０３ 記憶部
２０４ 制御部
３０１ 送信部
３０２ 受信部
３０３ 記憶部
３０４ 制御部
３０５ 受信バッファ（記憶手段）
３０６ ウィンドウサイズ制御部（ウィンドウサイズ制御手段）
６０１ サーバ
６０２ ＰＣ

Claims (2)

1. データを記憶すると共に、通信に使用するプロトコルにおいて通知可能な最大のウィンドウサイズより大きいウィンドウサイズが設定される記憶手段と、
   前記記憶手段における前記ウィンドウサイズの設定された部分の容量の残量が前記最大のウィンドウサイズ以下の場合は、該容量の残量を、通信の相手に通知する通知ウィンドウサイズとして設定し、
   前記記憶手段における前記ウィンドウサイズの設定された部分の容量の残量が前記最大のウィンドウサイズより大きい場合は、前記通信の相手に通知する通知ウィンドウサイズとして前記最大のウィンドウサイズを設定するウィンドウサイズ制御手段とを備える、電子機器。
2. 前記ウィンドウサイズ制御手段は、
   前記通知ウィンドウサイズを前記最大のウィンドウサイズと設定した後、所定時間、通信の相手側からデータを受信しない場合は、
   前記記憶手段における前記ウィンドウサイズの設定された部分の容量の残量が前記最大のウィンドウサイズより大きい場合に通信の相手に通知する通知ウィンドウサイズとして、前記最大のウィンドウサイズよりも少ない値を設定する請求項１記載の電子機器。

Images