JP2008160516A - 電子機器 - Google Patents

Abstract

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

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図４に示されるように、まず、携帯電話１０２のウィンドウサイズ制御部は、内部ウィンドウサイズの設定された受信バッファの残量がしきい値Ｗ［ＫＢ］以上であるか否かを判断する（Ｓ４０１）。そして、処理は、受信バッファの残量がＷ［ＫＢ］以上であれば（ＹＥＳ）、Ｓ４０２に移行し、受信バッファの残量がＷ［ＫＢ］よりも小さければ（ＮＯ）、Ｓ４０７に移行する。ここで、しきい値Ｗ［ＫＢ］は、携帯電話１０２に設定された内部ウィンドウサイズ内における受信バッファの容量の残量（以下、単に残量とも記す。）に対するしきい値のことをいう。このしきい値Ｗ［ＫＢ］は、初めユーザにより設定され、後述する処理に示されるように、携帯電話１０２の使用状況に応じてその値が更新されて携帯電話１０２内に格納される。

このしきい値Ｗ［ＫＢ］の値としては、本実施形態では、例えば５０を用いる。しかし、本発明の電子機器では５０に限定されるものではなく、４５や６０など他の適宜な値を用いることができる。なお、内部ウィンドウサイズ内における受信バッファの残量とは、内部ウィンドウサイズが設定された受信バッファの部分のうち、データの記憶が可能な領域として残っている容量をいう。

次に、携帯電話１０２のウィンドウサイズ制御部は、Ｓ４０２において、６４［ＫＢ］をウィンドウサイズに設定し、携帯電話１０２の送信部は、送信側のサーバ１０１にこの設定したウィンドウサイズを通知ウィンドウサイズとして通知する。なお、本実施形態ではＴＣＰを用いるため、６４［ＫＢ］が通信に使用するプロトコルにおいて通知可能な最大のウィンドウサイズとなる。

次に、制御部は、Ｓ４０３において、６４［ＫＢ］のウィンドウサイズを通知してからデータの不受信時間が所定時間以上であるか否かを判定する。

そして、処理は、データの不受信時間が所定時間以上となっている場合は（ＹＥＳ）、Ｓ４０４に移行する。また、処理は、データの不受信時間が所定時間より小さい場合は（ＮＯ）、Ｓ４０５に移行する。

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

次に、携帯電話１０２のウィンドウサイズ制御部は、Ｓ４０４において、しきい値ＷにＭＳＳ［ＫＢ］を追加して動作を終える。ここで、ＭＳＳとは、最大セグメント長（Ｍａｘｉｍｕｍ Ｓｅｇｍｅｎｔ Ｓｉｚｅ）のことであり、ＴＣＰデータ部分の最大長のことをいう。もちろん、本発明の電子機器においてＷに追加される値は、ＭＳＳに限定されるものではなく、本発明の趣旨を逸脱しない限り、５［ＫＢ］や１０［ＫＢ］などのその他の適宜な数値や、ＭＳＳの自然数倍などであっても良い。

他方、携帯電話１０２のウィンドウサイズ制御部は、Ｓ４０７において、受信バッファの残量を通知ウィンドウサイズとして設定し、携帯電話１０２の送信部は、送信側のサーバ１０１にこの通知ウィンドウサイズを通知して、動作を終える。

次に、本発明の電子機器の一実施形態である携帯電話１０２の動作について図５を参照してさらに詳細に説明する。図５は、図１に示される携帯電話１０２の内部ウィンドウサイズの概念図である。

図５に示される例では、受信バッファに、ウィンドウサイズとして６４［ＫＢ］が設定されている。そして、しきい値Ｗは５０［ＫＢ］が設定されている。また、６４［ＫＢ］のウィンドウサイズが設定された受信バッファ中、１０［ＫＢ］が使用済みである。したがって、６４［ＫＢ］のウィンドウサイズが設定された受信バッファ中、５４［ＫＢ］が残量となる。

そのため、図５に示される例では、ウィンドウサイズの設定された受信バッファの残量が５４［ＫＢ］≧Ｗ（＝５０［ＫＢ］）であるため、携帯電話１０２は、送信側のサーバ１０１に通知する通知ウィンドウサイズとして６４［ＫＢ］を設定する。ここで、図５に示される例では、受信バッファに設定されるウィンドウサイズとして６４［ＫＢ］としたが、本発明の電子機器では、受信バッファに設定されるウィンドウサイズとして６４［ＫＢ］に限定するものではなく、本発明の趣旨を逸脱しない限り、６４［ＫＢ］より小さい値や、６４［ＫＢ］より大きい値であって良い。

このように、本発明の電子機器の一実施形態である携帯電話１０２は、ウィンドウサイズが設定された受信バッファの残量を確認し、この残量が設定されたしきい値Ｗ［ＫＢ］以上であるか否かを判断する。

そして、本発明の電子機器の一実施形態である携帯電話１０２は、受信バッファの残量がしきい値Ｗ［ＫＢ］以上であれば、ウィンドウサイズを６４［ＫＢ］と設定してサーバ１０１に通知する。他方、本発明の電子機器の一実施形態である携帯電話１０２は、受信バッファの残量がしきい値Ｗ［ＫＢ］より小さければ、ウィンドウサイズを受信バッファの残量に設定してサーバ１０１に通知する。

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

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

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

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

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

符号の説明

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

Claims (2)

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

Images