(57)【特許請求の範囲】
【請求項１】
パケット伝送を行う通信網に接続され、少なくとも第１及び第２の通信セッションを行う端末装置であって、
第１の通信セッションは、当該端末装置以外の第２端末装置が送信したパケットを受信するセッションであり、
第２の通信セッションは、当該端末装置以外の第３の端末装置が送信した主たるパケットの受信時に確認応答パケットを第３の端末装置に送信するセッションであり、
該端末装置は、前記第１の通信セッションが行われていないときには、第２の通信セッションにおける主たるパケットの受信時に直ちに確認応答パケットを送信し、第１の通信セッションが行われているときには、第２の通信セッションにおける主たるパケットの受信後、予め決められた時間または予め定めた計算方法により求めた時間が経過した後確認応答パケットを送信することを特徴とする端末装置。
【請求項２】
パケット伝送を行う通信網に接続され、少なくとも第１及び第２の通信セッションを行う端末装置であって、
第１の通信セッションは、当該端末装置以外の第２の端末装置が送信したパケットを受信するセッションであり、
第２の通信セッションは、当該端末装置以外の第３の端末装置が送信した主たるパケットの受信時に確認応答パケットを第３の端末装置に送信するセッションであり、
前記確認応答パケットは、前記第３の端末装置が直ちに送信可能なデータの容量に関する情報を含み、
当該端末装置は、第１の通信セッションが行われていないときには第２の通信セッションにおける確認応答パケットの送信可能な容量として実際の送信可能容量を用い、第１の通信セッションが行われているときには第２の通信セッションにおける確認応答パケットにおける送信可能容量として、実際の送信可能容量の代わりに、予め決められた容量あるいは予め定められた計算方法により求めた容量を用いることを特徴とする端末装置。
【請求項３】
パケット伝送を行う通信網に接続され、少なくとも第１及び第２の通信セッションを行う端末装置であって、
第１の通信セッションは、当該端末装置以外の第２の端末装置が送信したパケットを受信するセッションであり、
第２の通信セッションは、当該端末装置が当該端末装置以外の第３の端末装置に主たるパケットを送信し、第３の端末装置は当該主たるパケットを受信した際に確認応答パケットを当該端末装置に送信するセッションであり、
当該端末装置は、第１の通信セッションが行われていないときには第２の通信セッションにおける確認応答パケットの受信時に直ちに引き続く主たるパケットを第３の端末装置に送信し、第１の通信セッションが行われているときには第２の通信セッションにおける確認応答パケットの受信後、予め決められた時間または予め定めた計算方法により求めた時間が経過した後引き続く主たるパケットを送信することを特徴とする端末装置。
【請求項４】
パケット伝送を行う通信網に接続され、少なくとも第１及び第２の通信セッションを行う端末装置であって、
第１の通信セッションは、当該端末装置以外の第２の端末装置が送信したパケットを受信するセッションであり、
第２の通信セッションは、当該端末装置が当該端末装置以外の第３の端末装置に主たるパケットを送信し、第３の端末装置は当該主たるパケットを受信した際確認応答パケットを当該端末装置に送信するセッションであり、
前記確認応答パケットは該端末装置が直ちに送信可能なデータの容量に関する情報を含み、
該端末装置は、第１の通信セッションが行われていないときには第２の通信セッションにおける確認応答パケットの送信可能な容量として実際の送信可能容量を用い、第１の通信セッションが行われているときには、第２の通信セッションにおける確認応答パケットにおける送信可能容量の代わりに、実際の送信可能容量から予め決められた容量あるいは予め定められた計算方法により求めた容量を用いることを特徴とする端末装置。
【請求項５】
パケット伝送を行う通信網に接続され、少なくとも第１及び第２の通信セッションを行う端末装置であって、
第１の通信セッションは、当該端末装置以外の第２の端末装置に対しパケットを送信するセッションであり、
第２の通信セッションは、当該端末装置以外の第３の端末装置が送信した主たるパケットの受信時に確認応答パケットを第３の端末装置に送信するセッションであり、
当該端末装置は、第１の通信セッションが行われていないときには第１の通信セッションにおける主たるパケットの受信時に直ちに確認応答パケットを送信し、第１の通信セッションが行われているときには第２の通信セッションにおける主たるパケットの受信後、予め決められた時間または予め定めた計算方法により求めた時間が経過した後確認応答パケットを送信することを特徴とする端末装置。
【請求項６】
パケット伝送を行う通信網に接続され、少なくとも第１及び第２の通信セッションを行う端末装置であって、
第１の通信セッションは、当該端末装置以外の第２の端末装置に対しパケットを送信するセッションであり、
第２の通信セッションは、当該端末装置以外の第３の端末装置が送信した主たるパケットの受信時に確認応答パケットを第３の端末装置に送信するセッションであり、
前記確認応答パケットは第３の端末装置が直ちに送信可能なデータの容量に関する情報を含み、
当該端末装置は、第１の通信セッションが行われていないときには第２の通信セッションにおける確認応答パケットの送信可能な容量として実際の送信可能容量を用い、第１の通信セッションが行われているときには第２の通信セッションにおける確認応答パケットにおける送信可能容量として、実際の送信可能容量の代わりに、予め決められた容量あるいは予め定められた計算方法により求めた容量を用いることを特徴とする端末装置。
【請求項７】
パケット伝送を行う通信網に接続され、少なくとも第１及び第２の通信セッションを行う端末装置であって、
第１の通信セッションは、当該端末装置以外の第２の端末装置に対しパケットを送信するセッションであり、
第２の通信セッションは、当該端末装置が当該端末装置以外の第３の端末装置に主たるパケットを送信し、第３の端末装置は受信時に確認応答パケットを当該端末装置に送信するセッションであり、
当該端末装置は、第１の通信セッションが行われていないときには第２の通信セッションにおけ確認応答パケットの受信時に直ちに引き続く主たるパケットを送信し、第１の通信セッションが行われているときには第２の通信セッションにおける確認応答パケットの受信後、予め決められた時間または予め定めた計算方法により求めた時間が経過した後引き続く主たるパケットを送信することを特徴とする端末装置。
【請求項８】
パケット伝送を行う通信網に接続され、少なくとも第１及び第２の通信セッションを行う端末装置であって、
第１の通信セッションは、当該端末装置以外の第２の端末装置に対しパケットを送信するセッションであり、
第２の通信セッションは、当該端末装置が当該端末装置以外の第３の端末装置に主たるパケットを送信し、第３の端末装置は受信時に確認応答パケットを当該端末装置に送信するセッションであり、
前記確認応答パケットは該端末装置が直ちに送信可能なデータの容量に関する情報を含み、
当該端末装置は、第１の通信セッションが行われていないときには第２の通信セッションにおける確認応答パケットの送信可能な容量として実際の送信可能容量を用い、第１の通信セッションが行われているときには、第２の通信セッションにおける確認応答パケットにおける送信可能容量の代わりに、実際の送信可能容量から予め決められた容量あるいは予め定められた計算方法により求めた容量を用いることを特徴とする端末装置。
【請求項９】
請求項１、３、５又は７に記載の端末装置において、パケット通信網はインターネットプロトコルで通信を行うものとし、前記第１の通信セッションはＵＤＰで通信を行い、第２の通信セッションはＴＣＰで通信を行い、確認応答パケットはＴＣＰのＡＣＫとしたことを特徴とする端末装置。
【請求項１０】
請求項２、４、６又は８に記載の端末装置において、パケット通信網はインターネットプロトコルで通信を行うものとし、前記第１の通信セッションはＵＤＰで通信を行い、第２の通信セッションはＴＣＰで通信を行い、確認応答パケットはＴＣＰのＡＣＫとし、送信可能容量はＷｉｎｄｏｗとしたことを特徴とする端末装置。
【請求項１１】
請求項９に記載の端末装置において、前記第１の通信セッションは帯域ＢUDP を必要とし、通信網の帯域をＢとし、前記第２の通信セッションで用いられるＷｉｎｄｏｗサイズをＷとし、当該端末装置と第３の端末装置との間の往復遅延時間をＴRTT とし、０から１までの間で予め定められる品質パラメータをＰとした場合に、前記主たるパケットを受信してから確認応答パケットを送信するまでの時間又は前記確認応答パケットを受信してから引き続く主たるパケットを送信するまでの時間ＴW を、式
ＴW ＝Ｗ／（ＰＢ−ＢUDP ）−ＴRTT
で決定されることを特徴とする端末装置。
【請求項１２】
請求項１０に記載の端末装置において、前記第１の通信セッションは帯域ＢUDP を必要とし、通信網の帯域をＢとし、当該端末装置と第３の端末装置との間の往復遅延時間をＴRTT とし、０から１までの間で予め定められる品質パラメータをＰとした場合に、前記第２の通信セッションにおけるＷｉｎｄｏｗサイズＷが、式
Ｗ＝ＴRTT （ＰＢ−ＢUDP ）
で決定されることを特徴とする端末装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はインターネットプロトコルを用いた通信網における通信品質の向上に関するものであり、一台の端末装置でリアルタイム性を必要とする通信セッションと送受信の確実性を重視する通信セッションが共存する場合を想定している。
【０００２】
【従来の技術】
インターネットに接続された端末装置において音声通信とＷＷＷを行う場合を例に従来技術を説明する。音声通信は一般にＵＤＰ（User Datagram Protocol）が用いられており、特許請求の範囲における第１の通信セッションに相当する。ＷＷＷはＴＣＰが用いており、別の端末装置から送信されてきたパケットを受信した際に確認応答パケットを送信する第２の通信セッションに相当する。
【０００３】
ＴＣＰでは、データを受信した際に受信側の端末装置がＡＣＫパケットを送信側の端末装置に送信する。送信側はＡＣＫにより送信したデータが確実に受信側に到達したことを知ると同時に次に送るべきデータを送信する。この繰り返しにより確実にデータの送受信が行える。この方式では、データ送信からＡＣＫの受信までの時間が伝送路の遅延などにより増大するとデータの伝送速度が低下する。この問題を避けるためＴＣＰのヘッダにはＷｉｎｄｏｗの値が示されている。このＷｉｎｄｏｗサイズはパケットを送信した端末装置がパケットを送信した時点で受信可能なデータの容量を示している。
【０００４】
この動作の概要を図１に、また図１で示されたパケットの概要を図４に示す表１として示す。この動作の例では送信側から受信側へのヘッダを除いたパケット長を１０００バイトとする。受信側の装置はデータを含むパケット１の受信によりパケット２を送信する。パケット２は送信側にパケット１が受信されたことを知らせるとともにＷｉｎｄｏｗとして４０００を指定することで現在４０００バイトのデータが受信可能であることを示す。送信側の装置がパケット２によりパケット１に引き続くデータを送信する。Ｗｉｎｄｏｗサイズは４０００バイトなので４０００バイト送信するが、一つのパケットで送信できるデータ量は伝送路における最大パケット長（ＭＴＵ）により制限を受けるのでいくつかのパケットに分割して送信することもある。この例ではＭＴＵとして１０００バイトを想定する。パケット２のＷｉｎｄｏｗにより４個のパケットを引き続くデータとして送信できる。このようにして送信されたデータを含むパケットがパケット３〜６である。受信側はパケット１の受信時と同様に受信したことを知らせるパケット７を送信側に送信する。送信側及び受信側の装置の処理時間を無視するとパケット２〜６までの一連のプロセスは伝送路における往復遅延時間ＴRTT 内で行われる。従って、一般にＷｉｎｄｏｗサイズをＷとすると、ＴＣＰによるデータの転送速度Ｖは
Ｖ＝Ｗ／ＴRTT
で示される。
【０００５】
往復遅延時間ＴRTT には様々な要素が含まれる。ここではデータパケットの伝送に要する時間τdata、ＡＣＫパケットの伝送に要する時間τACK 、送信側及び受信側それぞれで固定的に発生する遅延時間τc とすると、図１に示した往復遅延時間ＴRTT は以下のように表現される。
0003759465.tif 000002
ここで、Ｌdataはデータパケットのパケット長、ＬACK はＡＣＫパケットのパケット長、Ｂd は送信側から受信側への帯域、Ｂｕは受信側から送信側への帯域、Ｎは１個のＡＣＫに対応したデータパケットの数である。ここで、一般のネットワークにおいて見られるようにＮが大きく、データパケットがＡＣＫパケットに対し大きく、スイッチやルータによる遅延が小さい極限を適用すると、この一連のプロセスによるデータの転送速度Ｖは送信側から受信側への帯域Ｂd に近づく。このことは、一般にＴＣＰは伝送路において使用可能な帯域の大半を消費することを意味する。
【０００６】
次にＵＤＰによる音声通信を考える。音声通信では端末装置で音声信号を符号化し、これを予め決められた条件でパケット化し伝送路に送出する。受信側ではこのパケット受信し、順次復号化することでもとの音声信号を得る。このとき、伝送路においてジッタ、パケットロスが発生すると受信側では本来順序良く受信されるべき音声パケットを正しく受信する事が出来ず、その結果、円滑な復号化が行えず、音声の品質が著しく劣化することとなる。このような品質の劣化は伝送路の物理的品質、ルータなどの中継装置の性能の劣化などでも発生するが、一般には伝送路あるいは中継装置におけるパケットの輻輳によってもたらされることが多い。
【０００７】
上述したように、通常ＴＣＰは伝送路の帯域の大半を消費するため、音声通信をパケットレベルで多重した場合、音声品質の劣化をもたらすパケットの輻輳を発生させると考えられる。実際にはＴＣＰとＵＤＰが競合した場合、往復遅延時間ＴRTT が増大するためＴＣＰによる伝送路の帯域の占有は軽減されると考えられるが、それがＵＤＰによる音声通信の品質を確保するに足るものであるかどうかは音声通信の通信条件により一般に保証されている訳ではない。
【０００８】
パケット通信網で音声通信などストリーム的なサービスを取り扱うためには遅延、パケットロスを低減することが必要である。これを実現するために例えばインターネットではＲＳＶＰ、Ｄｉｆｆｓｅｒｖなど様々なＱｏＳ技術（サービス品質技術）が試みられている。これらＱｏＳ技術は主にルータに作用するものであり、一般にネットワークを大幅に改修しないと十分な効果を引き出すことが難しい。また、ネットワークの末端部分においてはこれらのＱｏＳ技術の適用は末端のルータ、アクセス回線におけるモデムなどの改修が必要で低コストで実施することが困難である。
【０００９】
【発明が解決しようとする課題】
上述したように、パケット通信網上において音声通信などリアルタイム通信とその他の通信を共存させることはリアルタイム通信の品質に影響を与える。ＱｏＳ技術により解決する方法もあるが、従来のＱｏＳ技術を適用するためにはルータ、モデムなど通信機器を改修する必要があった。ルータやモデムの改修は費用がかかり、利用者に負担となる。本発明はこのような課題を解決するためになされたものである。
【００１０】
【課題を解決するための手段】
本発明では、上記課題の解決に際し、ネットワーク側ではなく、端末装置において解決する。すなわち、端末装置においてデータの送受信に際し確認応答を行うセッションとリアルタイム性を重視する通信セッションが共存する場合、確認応答の仕組みを改良することにより実現するものである。尚、本明細書において、「端末装置」とは、通信網を介してデータのやりとりを行う装置を意味し、パーソルコンピュータ、携帯電話機、メールサーバ、ファイルサーバ、ウェッブサーバ等の各種端末装置を含むものとする。
【００１１】
請求項１の発明は、リアルタイムでデータを受信する第１の通信セッションと確認応答により確実にデータを受信する第２の通信セッションが共存する端末装置において、第２の通信セッションの確認応答を遅らせる事で第１の通信セッションの品質を確保するものである。
【００１２】
請求項２の発明は、リアルタイムでデータを受信する第１の通信セッションと確認応答により確実にデータを受信する第２の通信セッションが共存する端末装置において、第２の通信セッションの確認応答における送信可能なデータ量を調整する事で第１の通信セッションの品質を確保するものである。
【００１３】
請求項３の発明は、リアルタイムでデータを受信する第１の通信セッションと確認応答により確実にデータを送信する第２の通信セッションが共存する端末装置において、第２の通信セッションの確認応答後引き続くデータの送信を遅らせる事で第１の通信セッションの品質を確保するものである。
【００１４】
請求項４の発明は、リアルタイムでデータを受信する第１の通信セッションと確認応答により確実にデータを送信する第２の通信セッションが共存する端末装置において、第２の通信セッションの確認応答後引き続くデータの送信可能なデータ量を調整する事で第１の通信セッションの品質を確保するものである。
【００１５】
請求項５の発明は、リアルタイムでデータを送信する第１の通信セッションと確認応答により確実にデータを受信する第２の通信セッションが共存する端末装置において、第２の通信セッションの確認応答を遅らせる事で第１の通信セッションの品質を確保するものである。
【００１６】
請求項６の発明は、リアルタイムでデータを送信する第１の通信セッションと確認応答により確実にデータを受信する第２の通信セッションが共存する端末装置において、第２の通信セッションの確認応答における送信可能なデータ量を調整する事で第１の通信セッションの品質を確保するものである。
【００１７】
請求項７の発明は、リアルタイムでデータを送信する第１の通信セッションと確認応答により確実にデータを送信する第２の通信セッションが共存する端末装置において、第２の通信セッションの確認応答後引き続くデータの送信を遅らせる事で第１の通信セッションの品質を確保するものである。
【００１８】
請求項８の発明は、リアルタイムでデータを送信する第１の通信セッションと確認応答により確実にデータを送信する第２の通信セッションが共存する端末装置において、第２の通信セッションの確認応答後引き続くデータの送信可能なデータ量を調整する事で第１の通信セッションの品質を確保するものである。
【００１９】
請求項９の発明は、インターネットプロトコルを用い、リアルタイムでデータを送受信する第１の通信セッションはＵＤＰを用い、確認応答により確実にデータを送受信する第２の通信セッションではＴＣＰを用い、第２の通信セッションにおけるＡＣＫパケットの送信タイミングあるいはＡＣＫに引き続くパケットの送信タイミングを調整することで第１の通信セッションの品質を確保するものである。
【００２０】
請求項１０の発明は、インターネットプロトコルを用い、リアルタイムでデータを送受信する第１の通信セッションはＵＤＰを用い、確認応答により確実にデータを送受信する第２の通信セションではＴＣＰを用い、送信可能容量としてＷｉｎｄｏｗを用いることで第１の通信セッションの品質を確保するものである。
【００２１】
請求項１１の発明は、第１の通信セッションで必要とする帯域をＢUDP とし、通信網の帯域をＢとし、第２の通信セッションで用いられるＷｉｎｄｏｗサイズをＷとし、当該端末装置と第３の端末装置との間の往復遅延時間をＴRTT とし、０から１までの間で予め定められる品質パラメータをＰとした場合、主たるパケットを受信してから確認応答パケットを送信するまでの時間又は確認応答パケットを受信してから引き続く主たるパケットを送信するまでの時間Ｔｗを、
ＴW ＝Ｗ／（ＰＢ−ＢUDP ）−ＴRTT
で決定することで第一の通信セッションの品質を確保するものである。
【００２２】
請求項１２の発明は、第１の通信セッションで必要とする帯域を帯域ＢUDP 、通信網の帯域をＢとし、当該端末装置と第３の端末装置との問の往復遅延時間をＴRTT とし、０から１までの間で予め定められる品質パラメータをＰとした場合に、第２の通信セッションにおけるＷｉｎｄｏｗサイズＷを、
Ｗ＝ＴRTT （ＰＢ−ＢUDP ）
で決定することで第２の通信セションの品質を確保するものである。
【００２３】
【発明の実施の形態】
図２に本発明の第１の実施例の構成を示す。第１の端末装置１は、回線終端装置３及び回線端局装置４により中継網５に接続されている。サーバ装置６及び端末装置２はそれぞれ中継網５に接続されている。端末装置１、端末装置２及びサーバ装置６はそれぞれＴＣＰ／ＩＰにより通信を行っている。本実施例では中継網は十分な帯域を持ち、回線終端装置３と回線端局装置４との間の帯域がボトルネックになっており、その帯域をＢとする。端末装置１はＷＷＷ及び音声通信を行うものであり、サーバ装置６からＴＣＰによりＷＷＷのコンテンツを受信し、第２の端末装置２との間で音声通信を行っている。音声通信で必要とする帯域をＢUDP とし、ＴＣＰのＷｉn ｄｏｗサイズは４０００とする。これら２つの通信サービスは同時に行われる事もあるし、どちらか一方だけ行われることもある。
【００２４】
第１の端末装置は、ＷＷＷ又は音声通信のどちらか一方しか行わないときには通常のＴＣＰとＵＤＰによりそれぞれのサービスが行われる。両方のサービスが同時に行われるとき、第１の端末装置１では、ＴＣＰではデータパケット受信に対するＡＣＫパケットの送信は直ちには行わず待機時間Ｔｗを待って行われる。このときのＴＣＰの動作を図３に示す。このとき、ＴＣＰにより占有される実効的な帯域Ｖeff は
0003759465.tif 000003
で示される。このことは、待機時間Ｔｗを適切に設定することでＴＣＰにより占有される帯域を制御できることを示している。ここで、ＴＣＰにより音声通信が影響を受ける程度は音声通信で用いられる符号化方式、パケットの送信レート、バッファの容量により異なり、ＴＣＰで占有される帯域と音声通信で用いられる帯域の合計を伝送路の帯域を等しくするだけでは音声通信の品質が確保できないこともある。このため、音声通信の品質を確保するためには
Ｂ≧ＢUDP ＋Ｖeff
であることが必要である。このため、０から１の間で決められる品質パラメータＰを導入し、音声通信の品質を確保するためにＴＣＰに許容されるい帯域を
ＰＢ＝ＢUDP ＋Ｖeff
で決定する。この式を変形することで待機時間ＴW として
ＴW ＝Ｗ／（ＰＢ−ＢUDP ）−ＴRTT
が得られる。実際に待機時間Ｔｗを決定する場合にはＷｉｎｄｏｗサイズＷは端末装置１がサーバ装置に送信する値から、往復遅延時間ＴRTT はＴＣＰのコネクション確立時の遅延時間あるいはｐｉｎｇなどによる測定から、音声通信で用いる帯域ＢUDP は音声通信のアプリケーションから、伝送路の帯域Ｂは装置に接続された伝送路のリンク速度あるいはユーザによる入力から、品質パラメータＰはユーザによる入力あるいは音声通信のアプリケーションからそれぞれ得られる。
【００２５】
次に、第２の実施例としてＷｉｎｄｏｗサイズを変更する方法を説明する。第２の実施例でも第１の実施例と同様に図２に示した構成で実施する。第１の実施例と同様に品質パラメータＰを導入し、
Ｗ＝ＴRTT （ＰＢ−ＢUDP ）
で端末装置１からサーバ装置へ送信するパケットのＴＣＰヘッダに用いられるＷｈｄｏｗサイズを決定することでＴＣＰが占有する帯域を抑制することができ、音声通信の品質を確保する事が出来る。
【００２６】
【発明の効果】
本発明はパケット通信網における通信でＴＣＰなどデータ送信の確実性を確保するため確認応答パケットを利用する通信セッションとＵＤＰによる音声通信のようにリアルタイムでデータを送受信する必要のある通信セッションが共存する場合に、端末装置側において後者の通信セッションが前者の通信セッションによって受ける影響を軽減する方法を提供する。本発明は通信網の改良を前提としないので安価かつ迅速に実施可能である。また、本発明をＴＣＰ／ＩＰ上で実施する場合、応答時間により制御する方法とＷｉｎｄｏｗサイズにより制御する方法があるが、前者はＡＣＫパケットの送信の効率性を損なうことなく実施可能であり、後者はＵＤＰの通信セッションのジツタヘの影響を軽減できる効果がある。
【図面の簡単な説明】
【図１】  ＴＣＰによるデータ通信の概要を示す線図である。
【図２】  本発明による通信システムの一例を示す線図である。
【図３】  待機時間を設けてＡＣＫパケットを送信する例を示す線図である。
【図４】  ＴＣＰによるデータ通信で用いられるパケットの一例を示す線図である。
【符号の説明】
１  端末装置１
２  端末装置２
３  回線終端装置
４  回線端局装置
５  中継網
６  サーバ装置
【図１】
0003759465.tif 000004
【図２】
0003759465.tif 000005
【図３】
0003759465.tif 000006
【図４】
0003759465.tif 000007