JP4628194B2

JP4628194B2 - 通信装置、所要時間測定方法及び通信制御方法

Info

Publication number: JP4628194B2
Application number: JP2005173797A
Authority: JP
Inventors: 健太郎齋藤; 健五十嵐
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2005-06-14
Filing date: 2005-06-14
Publication date: 2011-02-09
Anticipated expiration: 2025-06-14
Also published as: JP2006352337A

Description

本発明は、送信パケットの送信間隔を調整することにより輻輳制御を実行する通信システムで用いられる通信装置及び通信制御方法に関する。

現在インターネット等で用いられているＴＣＰでは、様々な輻輳制御方式が提案されている。これらの輻輳制御方式は、大きくパケットロスベースの輻輳制御方式とＲＴＴ（Round Trip Time）ベースの輻輳制御方式とに分類される。以下この分類に従って従来技術の説明を行う。

パケットロスベースの輻輳制御方式として、ＴＣＰ NewReno、ＴＣＰ Hack、High Speed ＴＣＰ等がある。これらの輻輳制御方式では、送信側の通信装置（以下、送信装置）は、送信パケットの損失が発生していない間はネットワークには輻輳が発生していないと見なしてデータ送信速度を徐々に増加させていく。一方で、送信装置は、送信パケットに損失が発生した場合には輻輳が発生したと見なしてデータ送信速度を大きく減少させる。送信パケットの損失の有無は、受信装置から返信されるＡｃｋパケットに含まれるSequence Numberから判定される。

ＲＴＴベースの輻輳制御方式として、ＴＣＰ Vegas、Fast ＴＣＰ等がある（例えば、非特許文献１乃至非特許文献３）。これらの輻輳制御方式では、送信装置は、送信パケットの損失の有無だけからではなく、送信装置と受信装置との間のＲＴＴの増減を用いて輻輳発生の有無を判断する。なお、ＲＴＴは、送信装置がデータを送出してからそのデータに対するＡｃｋパケットを受信するまでの時間である。ＲＴＴが増大し始めた場合には、ネットワークに輻輳が発生し始めたと見なし、送信装置はデータの送出速度を抑える。以下、ＲＴＴベースの輻輳制御方式としてTCP Vegasの概要を説明する。

ＴＣＰ Vegasでは、送信装置は、ネットワークが全く輻輳していない時のＲＴＴをＲＴＴｂａｓｅとして格納している。通常、送信装置は、ＲＴＴを常に測定しており、測定された中で最も小さなＲＴＴをＲＴＴｂａｓｅとして用いる。ネットワークが輻輳し始めると、ボトルネックルータにおいて送信パケットのキューイング遅延（以下ではＤと表す）が発生し、ＲＴＴが増大する。

ＲＴＴ＝ＲＴＴｂａｓｅ＋Ｄ …式１
送信装置は、ＲＴＴを算出する毎に、以下の式で定義されるＤｉｆｆを算出する。なお、ｃｗｎｄは、輻輳ウィンドウ（Congestion Window）を示している。

ここで、送信装置の送信パケットのデータ送信速度をＴとすると、ＴＣＰでは以下の式が成立する。

従って、上記式２は以下のように変形することができる。

上記式４より、Ｄｉｆｆは、ボトルネックルータのバッファにキューイングされているパケット量に等しいことが分かる。なぜなら、送信装置により送信パケットがデータ送信速度Ｔで常に送信されており、全ての送信パケットがＤ秒間バッファにキューイングされているため、平均のＤｉｆｆ＝Ｔ×Ｄの送信パケットの量が常にルータのバッファにキューイングされていると考えられるからである。

ＴＣＰ Vegasでは、送信装置はCongestion Avoidanceに入った後は、ＲＴＴを算出する毎に、このＤｉｆｆを算出し、以下の式によりｃｗｎｄを変更する。

(1)Ｄｉｆｆ＜α（αはデフォルトでは１）
ｃｗｎｄ_next＝ｃｗｎｄ＋１ …式５
(2)β＜Ｄｉｆｆ（βはデフォルトでは３）
ｃｗｎｄ_next＝ｃｗｎｄ−１ …式６
ＴＣＰ Vegasでは、送信装置は、ＲＴＴの変動情報（ＲＴＴ−ＲＴＴｂａｓｅ）を用いて上記式４を用いてＤｉｆｆを算出することにより輻輳制御を実行する。このため、送信装置から受信装置への送信パスにおいて送信パケットの輻輳が発生していなくても、受信装置から送信装置への返信パスにおいてＡｃｋパケットに遅延が発生する場合には、送信装置は、輻輳が発生していると見なし、送信パケットのデータ送信速度を減少させる。このため、片道伝送所要時間の増減のみを用いて輻輳制御を実行するEnhanced ＴＣＰ Vegas方式も提案されている。以下、Enhanced ＴＣＰ Vegasでの、ＲＴＤ（Relative Time Delay）を用いた片道伝送所要時間の増減の取得方法を示す。

先ず、送信装置が送信パケットを送信した時刻をｓとし、受信装置が送信パケットを受信した時刻をｔとすると、以下の式によりＲＴＤを表すことができる。

ＲＴＤ＝ｔ−ｓ …式７
一般に送信装置と受信装置との時計はδだけずれているため、実際の片道伝送所要時間は、ＲＴＤ＋δとなる。しかし、δは一定だと考えられるため、ＲＴＤの増減値は片道伝送所要時間の増減値に等しくなる。

従って、ＴＣＰ Vegasと同様にＲＴＤの最小値をＲＴＤｂａｓｅとして、片道伝送所要時間の変動情報（ＲＴＤ−ＲＴＤｂａｓｅ）を用いて以下の式を算出することにより輻輳制御を実行することができる。

Ｄｉｆｆ_ＲＴＤ＝Ｔ×（ＲＴＤ−ＲＴＤｂａｓｅ） …式８
Ｗ．リチャード・スティーヴンス、"詳解ＴＣＰ／ＩＰ Vol.1"、ピアソン・エデュエーション，2002 Charalampos (Babis) Samios, Mary K.Vernon,"Modeling the throughput of TCP Vegas"，ACM SIGMETRICS, 2003. Yi-Cheng Chan, Chia-Tai Chan, Yaw-Chung Chen,"An enhanced congestion avoidance mechanism for TCP Vegas"，Communications Letters, IEEE, 2003.

しかしながら、無線環境下（例えば、セルラー無線などの移動体端末を用いた無線環境下）では、ネットワークの輻輳以外の原因、具体的には無線通信網で発生した無線エラーにより送信パケットの損失が頻繁に発生するという問題が生じる。

この問題を軽減するためにＦＥＣ（Forward Error Collection）やＡＲＱ（Automatic Repeat Request）等の制御が実行されている。ところが、ＦＥＣでは送信パケットの構成が冗長であるため、伝送所要時間が大きくなり、特にＡＲＱでは送信パケットの再送が実行されるため、伝送所要時間が非常に大きく変動することとなる。

このため、特にＡＲＱではネットワークの輻輳が発生していないにも関わらず、伝送所要時間の大きな変動によりネットワークの輻輳が発生していると誤認することがあるため、必要以上にデータ伝送速度が減少するという問題が生じる。

以下では、セルラー無線の特徴の１つであるＡＲＱについて図７を参照しながら説明する（Inamura, H.; Takahashi, O.; Nakano, H,;Ishikawa, T.; Shigeno, H.,“Impact of layer two ARQ on TCP performance in W-CDMA networks”，Distributed Computing Systems, 2004.参照）。ＡＲＱは、受信側で送信パケットが受信されない場合に送信側に対して当該受信パケットの再送を要求するための制御である。

図７は、有線通信網３上に備えられた送信装置１から送信パケットが送信されて、当該送信パケットが基地局制御装置２を介して受信装置４によって受信される様子を示している。

図７に示すように、基地局制御装置２は、送信パケットを受信した場合には、当該送信パケットを複数のフレームに分割する。分割されたフレームのそれぞれは、該当するＲＬＣヘッダでカプセル化されて受信装置４によって受信される。ＲＬＣヘッダにはLink Layerで定義されるSequence Number（＃１乃至＃ｎ）が含まれている。

図７では、Sequence Number ＃３のフレームが無線エラーによって損失したケースを示す。受信装置４は、このSequence Numberに基づいて無線エラーによるフレームの損失を検出し、無線エラーによるフレーム（Sequence Number ＃３）の損失を検出した場合には、基地局制御装置２に対して該当するフレーム（Sequence Number ＃３）の再送要求を送信する。

基地局制御装置２は、受信装置４から再送要求を受信した場合には、該当するフレーム（Sequence Number ＃３）の再送を実行する一方で、受信装置４は、当該基地局制御装置２に対して再送要求を送信してから当該再送要求に対応するフレーム（Sequence Number ＃３）を受信するまでの間には続きのSequence Number ＃４以降のフレームを受信する。

受信装置４は、フレームに不足がない場合（Sequence Number ＃１〜＃２）には、受信したフレームをＴＣＰ Layerに受け渡す。受信装置４は、再送されたフレーム（Sequence Number ＃３）を受信するまでの間、それ以降（Sequence Number ＃４〜）のフレームをＴＣＰ Layerに受け渡さずにバッファに格納させる。

このため、ＡＲＱによる再送要求が実行されると、再送フレームだけでなく、その後に続くフレームもＴＣＰ Layerに受け渡されるまでに遅延が発生する。１つのフレームの最大再送要求回数は決まっており、最大再送要求回数に達したフレームは棄てられ最終的にはフレームロスとなる。

このようにＡＲＱを利用している無線環境下では、フレームが再送されることに伴ない、伝送所要時間が大きく変動するため、ＴＣＰ Vegas、Enhanced ＴＣＰ Vegas等の輻輳制御方式が用いられた場合には、送信装置は、フレームが再送されたことに伴なう伝送所要時間の変動を輻輳と誤認して、必要以上にデータ伝送速度を減少させることとなる。

また、従来からのＴＣＰ Hackでも必要以上にデータ伝送速度を減少させることがあり、この点についても以下説明する。

図８に示すように、従来からのＴＣＰ Hackでは、サーバ１が送信パケットを送信する場合には、サーバ１はＴＣＰ／ＩＰヘッダのチェックサムの算出結果を送信パケットに含めて送信する。無線通信網５上で送信パケットが送信されている際に、送信パケットを構成するいずれかのフレームの損失や、フレームのビットエラーによる破損等が発生すると、移動体端末４では、これらの各フレームに基づいて破損した送信パケットを再構成することとなる。

通常これらの送信パケットは、破損パケットとして破棄されるが、ＴＣＰ Hackでは、移動体端末４は、破損パケット中のＴＣＰ／ＩＰヘッダのチェックサムを算出する。移動体端末４は、破損パケットのＴＣＰ／ＩＰヘッダに破損がなければ、どのＴＣＰコネクションに無線エラーが発生したかを決定することができる。

そして、移動体端末４は、決定したＴＣＰコネクションを用いて、無線エラーによる送信パケットの破損が発生したことを示す破損発生情報をサーバ１に送信する。当該サーバ１は、当該破損発生情報を受信した場合には、上記ＴＣＰコネクションで無線エラーが発生しただけで、送信パケットの輻輳が発生していないと判定することができるため、移動体端末４に対して送信パケットを送信するためのＴＣＰコネクションにおいて送信パケットのデータ伝送速度を減少させるための輻輳制御を中止することができる。

しかしながら、従来からのＴＣＰ Hackでは、移動体端末４は、上述のように破損パケットのＴＣＰ／ＩＰヘッダに破損がない場合には、どのＴＣＰコネクションで無線エラーが発生したかを決定することができるが、破損パケットのＴＣＰ／ＩＰヘッダに破損がある場合には、どのＴＣＰコネクションに無線エラーが発生したかを決定することができない。このため、サーバ１は、ＴＣＰコネクションを介して上記破損発生情報を受信することができないため、輻輳による送信パケットの損失が発生したと誤認することとなり、送信パケットのデータ伝送速度を必要以上に減少させることとなる。

そこで、本発明は以上の点に鑑みて成されたものであり、必要以上に送信パケットのデータ伝送速度を減少させずに、適切な輻輳制御を実行することができる通信装置及び通信制御方法を提供することを目的とする。

上記課題を解決するために、本発明は、送信元によって送信される送信パケットの送信時刻と、該送信パケットを受信した受信時刻又は該送信パケットに対応する確認応答パケットを受信した受信時刻とを用いて算出される伝送所要時間を測定する通信装置であって、前記通信装置が受信した前記送信パケットを構成する複数フレームのうち、再送されたフレームである再送フレームが含まれている場合にのみ、前記フレームの再送が要求された時刻と前記再送フレームが受信された時刻とを用いて算出される再送所要時間を、前記伝送所要時間から除外する伝送所要時間除外部を備えることを特徴とする。

このような本発明の特徴によれば、受信された送信パケットを構成する複数フレームのうち、再送フレームが含まれている場合にのみ、フレームの再送が要求された時刻と再送フレームが受信された時刻とを用いて算出される再送所要時間を、伝送所要時間から除外することにより、フレームの再送が要求されても当該伝送所要時間が大きく変動しなくなる。このため、ＴＣＰ Vegas、Enhanced ＴＣＰ Vegas等の輻輳制御方式が用いられても、必要以上にデータ伝送速度を減少させないようにすることができ、送信パケットの輻輳制御を適切に実行することができる。

また、本発明は、無線通信網を介して接続されている通信システムで用いられる通信装置であって、前記通信装置が受信した送信パケットを構成するヘッダの一部が破損しているか否か検出する検出部と、前記通信装置が受信した前記送信パケットを構成する前記ヘッダの一部の破損が検出されたときは、破損している前記送信パケットである破損パケットの内容と、再送された再送パケットの内容とを比較し、該破損パケットのペイロード部と該再送パケットのペイロード部とが同一である場合には、該再送パケットを構成する前記ヘッダの一部に基づいて、前記破損パケットのコネクションを決定するコネクション決定部とを備えることを特徴とする。

上記発明においては、ヘッダの一部は、ＩＰアドレス及びポート番号を含んでもよい。

本発明の特徴によれば、必要以上に送信パケットのデータ伝送速度を減少させずに適切な輻輳制御を実行することができる。

［第１実施形態］
以下では図面を参照しながら、本実施形態について説明する。なお、上記「背景技術」及び上記「発明の開示」において既に説明した事項（例えば、「ＴＣＰ Vegas」、「Enhanced ＴＣＰ Vegas」など）についての詳細は省略する。

（通信システムの構成）
図１は、本実施形態における通信システムの構成を示す図である。図１に示すように、通信システムは、サーバ１０により送信された送信パケットの送信時刻と、移動体端末４０により受信された送信パケットの受信時刻とを用いて算出される伝送所要時間（上記式７参照）に基づいて、送信パケットの送信間隔を調整することにより輻輳制御を実行するものである。

通信システムは、サーバ１０と、基地局制御装置２０と、有線通信網３０とを備えている。

サーバ１０は、基地局制御装置２０を介して、移動体端末４０に向けて送信パケットを送信するものであり、サーバ１０と移動体端末４０との間においてＴＣＰを用いて送信パケットの送信間隔を調整する機能を備えている。

基地局制御装置２０は、有線通信網３０を介してサーバ１０から送信された送信パケットを受信し、無線通信網５０を介して移動体端末４０に向けて送信パケットを送信する。

（移動体端末の構成）
図２は、本実施形態における移動体端末４０の構成を示す図である。本実施形態におけるサーバ１０及び移動体端末４０は、上記「Enhanced ＴＣＰ Vegas」を用いて通信する機能を備えているものとして説明する。

移動体端末４０は、有線通信網３０及び無線通信網５０を介して、サーバ１０から送信された送信パケットを受信し、受信した送信パケットを構成する複数フレームのうち、再送されたフレームである再送フレームが含まれている場合にのみ、フレームの再送が要求された時刻と再送フレームが受信された時刻とを用いて算出される再送所要時間を、伝送所要時間（上記式７参照）から除外する伝送所要時間除外部を構成する。なお、サーバ１０又は移動体端末４０は、上記通信システムで用いられる通信装置を構成する。以下では、移動体端末４０の構成について詳細に説明する。

図２に示すように、移動体端末４０は、受信部４１と、再送要求情報格納部４２と、ＡＲＱ再送用フレームバッファ４３と、パケット再構成部４４と、送信部４５とを備えている。

受信部４１は、基地局制御装置２０を介して、サーバ１０から送信された送信パケットを受信する。この送信パケットには、サーバ１０から送信された送信パケットの送信時刻ｓが含まれている。

再送要求情報格納部４２は、受信部４１により受信された送信パケットを構成する複数フレームのうち再送フレームが含まれている場合には、その再送フレームのSequence Number（例えば、＃３）を再送要求情報として記録する。

ＡＲＱ再送用フレームバッファ４３は、受信部４１により受信された送信パケットを構成する複数フレームを格納するとともに、当該複数フレームのそれぞれが受信された受信時刻を記録する。但し、ＡＲＱ再送用フレームバッファは、当該複数フレームのうち再送フレームが含まれている場合には、当該再送フレームを格納するが、当該再送フレームの受信時刻を記録しない（図２に示す“ＮＧ”を参照）。なお、本実施形態では、送信パケットの送信時刻ｓは、いずれかのフレームに含まれており、ＡＲＱ再送用フレームバッファ４３に記録されるものとする。

また、ＡＲＱ再送用フレームバッファ４３は、受信部４１により受信された送信パケットを構成する複数フレームに損失がない場合、又はフレームの再送要求が所定回数以上されても該当する再送フレームが受信されない場合には、ＡＲＱ再送用フレームバッファ４３に格納した各フレーム及びそれぞれの受信時刻をパケット再構成部４４に出力するとともに、当該各フレーム及びそれぞれの受信時刻を削除する。

パケット再構成部４４は、ＡＲＱ再送用フレームバッファ４３から入力された各フレームのSequence Numberを参照し、そのSequence Numberの順番で各フレームを配置して送信パケットを再構成するとともに、再構成した送信パケットをアプリケーション層に出力する。このパケット再構成部４４は、ＡＲＱ再送用フレームバッファ４３に格納されているいずれかのフレームが損失（又は破損）している場合にも、Sequence Numberの順番で各フレームを配置して送信パケットを再構成する。

また、パケット再構成部４４は、ＡＲＱ再送用フレームバッファ４３から入力された各フレームのうち再送フレームが含まれていない場合には、最後に受信されたフレームの受信時刻を、再構成した送信パケットの受信時刻ｔとして決定する。

一方、パケット再構成部４４は、ＡＲＱ再送用フレームバッファ４３から入力された各フレームのうち再送フレームが含まれている場合、本実施形態ではフレームに対応する受信時刻が記録されていない場合には、再構成した送信パケットの受信時刻ｔを決定しない。

送信部４５は、ＡＲＱ再送用フレームバッファ４３に格納された各フレームのSequence Numberを参照し、抜けているSequence Number（例えば、＃３）を検出（フレームの損失を検出）した場合には、サーバ１０に対して当該Sequence Numberのフレームの再送要求を送信する。この場合には、受信部４１は、送信部４５により送信された再送要求に対応する再送パケットが送信された場合には、再送パケットのSequence Numberを再送要求情報格納部４２に記録するとともに、再送パケットの受信時刻を記録させずに、再送パケットをＡＲＱ再送用フレームバッファ４３に格納させる。

また、送信部４５は、パケット再構成部４４により送信パケットが再構成された場合には、送信パケットの送信時刻ｓ及び決定された送信パケットの受信時刻ｔを含むＡｃｋパケットをサーバ１０に向けて送信する。なお、送信部４５は、送信パケットの受信時刻ｔが決定されない場合には、当該送信パケットの送信時刻ｓを含むＡｃｋパケット（送信パケットの受信時刻ｔを含まず）をサーバ１０に向けて送信する。

（サーバ、基地局制御装置及び移動体端末の動作）
次に、通信システム及び移動体端末の動作について図面を参照しながら説明する。図３は、本実施形態におけるサーバ１０、基地局制御装置２０及び移動体端末４０の動作（通信制御方法）を示す図である。

図３に示すように、Ｓ１０１において、サーバ１０は、送信パケット（その送信パケットの送信時刻ｓを含む）を基地局制御装置２０に向けて送信する。

Ｓ１０３において、基地局制御装置２０は、サーバ１０から受信した送信パケットを複数フレームに分割する（フレーム＃１乃至フレーム＃Ｎ）。本実施形態におけるフレームのそれぞれには、ＲＬＣヘッダ及びSequence Numberが含まれるものとする。

Ｓ１０５において、基地局制御装置２０は、分割した各フレーム（フレーム＃１乃至フレーム＃Ｎ）を移動体端末４０に向けて送信する。

Ｓ１０７において、移動体端末４０は、基地局制御装置２０から受信した各フレームをＡＲＱ再送用フレームバッファ４３に格納させる。また、移動体端末４０は、再送要求情報格納部４２に格納されているSequence Numberのフレームの受信時刻を除いて、受信した各フレームのそれぞれに対応する受信時刻を記録する。

Ｓ１０９において、移動体端末４０は、再送要求情報格納部４２に格納されているSequence Numberを参照し、フレームの損失があるか否か、すなわち抜けているSequence Numberが存在するか否か判定する。

Ｓ１１１において、移動体端末４０は、この判定がＹＥＳである場合には、抜けているSequence Numberのフレームの再送要求を基地局制御装置２０に送信する。一方、移動体端末４０は、判定がＮＯである場合にはＳ１１５の処理に移る。

Ｓ１１３において、基地局制御装置２０は、移動体端末４０から再送要求を受信した場合には、当該再送要求に対応する再送フレームを当該移動体端末４０に送信する。この移動体端末４０は、基地局制御装置２０から再送フレームを受信した場合には、再送フレームのSequence Numberを再送要求情報格納部４２に格納させるとともに、再送フレームの受信時刻をＡＲＱ再送用フレームバッファ４３に記録させずに、再送フレームをＡＲＱ再送用フレームバッファ４３に格納させる。

Ｓ１１５において、移動体端末４０は、サーバ１０から送信された送信パケットを構成する全てのフレームを受信したか否か、又は再送要求を所定回数以上したか否か判定し、この判定がＹＥＳである場合にはＳ１１７の処理に移り、ＮＯである場合にはＳ１０９の処理に戻る。

Ｓ１１７において、移動体端末４０は、ＡＲＱ再送用フレームバッファ４３に格納されているSequence Numberを参照し、そのSequence Numberの順番で各フレームを配置して送信パケットを再構成する。

Ｓ１１９において、移動体端末４０は、再構成される送信パケットを構成する各フレームのうち再送フレームが含まれているか否か判別し、この判定がＮＯである場合には、Ｓ１２１において、最後に受信されたフレームの受信時刻を、再構成した送信パケットの受信時刻ｔとして決定する。

一方、移動体端末４０は、上記判定がＹＥＳである場合、すなわち再構成される送信パケットを構成する各フレームのうち再送フレームが含まれている場合（本実施形態ではフレームに対応する受信時刻が記録されていない場合）には、Ｓ１２３において、再構成した送信パケットの受信時刻ｔを決定しない。

Ｓ１２５において、移動体端末４０は、上記送信パケットの送信時刻ｓ及び受信時刻ｔを含むＡｃｋパケットをサーバ１０に向けて送信する。

Ｓ１２７において、移動体端末４０は、上記送信パケットの受信時刻ｔを含めずに、上記送信パケットの送信時刻ｓを含むＡｃｋパケットをサーバ１０に向けて送信する。

ここで、サーバ１０は、送信パケットの送信時刻ｓ及び受信時刻ｔを含むＡｃｋパケットを移動体端末４０から受信した場合には、上記式７によりＲＴＤ（伝送所要時間）を算出する。そして、サーバ１０は、算出したＲＴＤを用いて、上記式８によりＤｉｆｆ_ＲＴＤを算出し、その算出結果に応じて送信パケットの送信間隔を調整することにより輻輳制御を実行する。

一方、サーバ１０は、送信パケットの受信時刻ｔを含むＡｃｋパケットを移動体端末４０から受信せずに、送信パケットの送信時刻ｓを含むＡｃｋパケットを移動体端末４０から受信した場合には、上記式７によるＲＴＤ（伝送所要時間）、及び上記式８によるＤｉｆｆ_ＲＴＤを算出しない。これにより、移動体端末４０は、移動体端末４０によりフレームの再送が要求された時刻（ｔ１）と、移動体端末４０により再送フレームが受信された時刻（ｔ２）とを用いて算出される再送所要時間（ｔ１−ｔ２）を、上記式７によるＲＴＤ（伝送所要時間）から除外させることができる。

なお、サーバ１０は、送信パケットの受信時刻ｔがＡｃｋパケットに含まれていない場合には、上記式７によるＲＴＤ（伝送所要時間）、及び上記式８によるＤｉｆｆ_ＲＴＤを算出しないため、送信パケットの送信間隔を調整するための輻輳制御を中止する（実行しない）こととなる。

このような本実施形態の特徴によれば、受信された送信パケットを構成する複数フレームのうち、再送フレームが含まれている場合にのみ、フレームの再送が要求された時刻と再送フレームが受信された時刻とを用いて算出される再送所要時間を、伝送所要時間から除外することにより、フレームの再送が要求されても伝送所要時間が大きく変動しなくなるため、必要以上にデータ伝送速度を減少させないようにすることができ、送信パケットの輻輳制御を適切に実行することができる。

なお、本実施形態における移動体端末４０は、受信した送信パケットを構成する各フレームのうち、再送フレームが含まれていない場合には、最後に受信されたフレームの受信時刻を送信パケットの受信時刻ｓとして決定し、再送フレームが含まれている場合には、再送フレームを除く最後に受信されたフレームの受信時刻を送信パケットの受信時刻ｓとして決定してもよい。

これにより、送信パケットの送信時刻ｔと送信パケットの受信時刻ｓとにより算出される伝送所要時間（ＲＴＤ）には、フレームの再送が要求された時刻と再送フレームが受信された時刻とを用いて算出される再送所要時間が含まれないこととなる。このため、フレームの再送が要求されても伝送所要時間が大きく変動しなくなるため、必要以上にデータ伝送速度を減少させないようにすることができ、送信パケットの輻輳制御を適切に実行することができる。

［第２実施形態］
（移動体端末の構成）
本実施形態における移動体端末について図面を参照しながら説明する。本実施形態における通信システムは、第１実施形態とは異なり、上記「ＴＣＰ Hack」の機能を備えており、無線通信網５０（図１参照）における無線エラーによる送信パケットの損失と、輻輳による送信パケットの損失とのいずれかを区別するものである。

また、本実施形態における通信システムは、無線通信網５０における無線エラーにより送信パケットの破損が発生したことを示す破損発生情報を移動体端末４０Ａから受信した場合には、移動体端末４０Ａに対して送信パケットを送信するためのコネクション（ここではＴＣＰコネクション、以下も同様とする）上における輻輳制御を中止するものである。

図４は、上記通信システムで用いられる移動体端末４０Ａの構成を示す図である。本実施形態における移動体端末４０Ａは、受信した送信パケットを構成するＴＣＰ／ＩＰヘッダの一部の破損を検出したときは、その破損している送信パケットである破損パケットの内容と再送パケットの内容とを比較し、破損パケットのペイロード部と再送パケットのペイロード部とが同一である場合には、再送パケットを構成するＴＣＰ／ＩＰヘッダの一部に基づいて、破損パケットのＴＣＰコネクションを決定し、決定したＴＣＰコネクションを用いて上記破損発生情報を通信システムに送信するものである。以下では、移動体端末４０Ａを構成する各部について詳細に説明する。

図４に示すように、移動体端末４０Ａは、第１実施形態の構成に加えて、ＴＣＰコネクション管理部４６と、チェックサム検証部４７と、破損パケットバッファ４８とを備えている。なお、ＴＣＰコネクション管理部４６、チェックサム検証部４７及び破損パケットバッファ４８以外の構成については第１実施形態と同様であるため、詳細な説明は省略する。なお、チェックサム検証部４７は、検出部及びコネクション決定部を構成する。

ＴＣＰコネクション管理部４６は、通信中のＴＣＰコネクションを識別するために最小限必要な情報であるＴＣＰコネクション識別情報をＴＣＰコネクション毎に管理する。このＴＣＰコネクション識別情報には、送信元ＩＰアドレス、送信先ＩＰアドレス、送信元ポート番号（ＴＣＰポート番号又はＵＤＰポート番号）及び送信先ポート番号（ＴＣＰポート番号又はＵＤＰポート番号）が少なくとも含まれていればよい。ＴＣＰコネクション識別情報は、後述するように、サーバ１０側で送信パケットのチェックサムが算出される際に用いられる。

チェックサム検証部４７は、再構成された送信パケットに破損がない場合、すなわち送信パケットを構成する各フレームのSequence Numberに抜けがない場合には、送信部４５は、送信パケットに対応するＡｃｋパケットをサーバ１０に向けて送信する。一方、チェックサム検証部４７は、再構成された送信パケットに破損がある場合、すなわち送信パケットを構成する各フレームのSequence Numberに抜けがある場合には、破損している送信パケットである破損パケットを破損パケットバッファ４８に格納させる。なお、破損パケットがある場合には、当該破損パケットに対応するＡｃｋパケットが送信されないため、当該破損パケットに対応する再送パケットが送信されることとなる。

また、チェックサム検証部４７は、破損パケットがある場合には、当該破損パケットを構成するＴＣＰ／ＩＰヘッダの一部（ここではＴＣＰコネクション識別情報）が破損しているか否か検出する。

例えば、チェックサム検証部４７は、破損パケットの領域のうち、上記ＴＣＰコネクション識別情報に対応する領域のチェックサムを算出し、そのチェックサム算出結果と、再構成された送信パケットに含まれているチェックサム算出結果（サーバ１０で予め算出されたチェックサム算出結果）とを比較する。チェックサム検証部４７は、両チェックサム算出結果が同一である場合には、破損パケットのＴＣＰ／ＩＰヘッダの一部であるＴＣＰコネクション識別情報が破損していないと判定する。

この場合には、送信部４５は、破損パケットのＴＣＰコネクション識別情報を用いて破損パケットのＴＣＰコネクションを決定し、そのＴＣＰコネクションを用いてＡｃｋパケットと破損発生情報とをサーバ１０に向けて送信する。

一方、チェックサム検証部４７は、両チェックサム算出結果が同一でない場合には、破損パケットのＴＣＰ／ＩＰヘッダの一部であるＴＣＰコネクション識別情報が破損していると判定する。この場合には、チェックサム検証部４７は、破損パケットの内容と再送パケットの内容とを比較し、破損パケットのペイロード部と再送パケットのペイロード部とが同一である場合には、再送パケットを構成するＴＣＰ／ＩＰヘッダの一部であるＴＣＰコネクション識別情報に基づいて、破損パケットのＴＣＰコネクションを決定し、そのＴＣＰコネクションを用いてＡｃｋパケットと破損発生情報とを通信システムに送信する（後述する図６参照）。

（サーバ、基地局制御装置及び移動体端末の動作）
次に、サーバ、基地局制御装置及び移動体端末の動作について図面を参照しながら説明する。図５は、本実施形態におけるサーバ１０、基地局制御装置２０及び移動体端末４０Ａの動作（通信制御方法）を示す図である。

図５に示すように、Ｓ２０１において、移動体端末４０Ａは、通信中のＴＣＰコネクションのそれぞれに対応するＴＣＰコネクション識別情報を管理し、サーバ１０から送信された送信パケットに対応するＡｃｋパケットに、サーバ１０でチェックサムを実行する領域（ここではＴＣＰコネクション識別情報に対応する領域）を示すチェックサム実行領域情報を含めて、そのＡｃｋパケットをサーバ１０に向けて送信する。

Ｓ２０３において、サーバ１０は、移動体端末４０Ａから受信されたＡｃｋパケットに含まれているチェックサム実行領域情報に基づいて、送信パケットの領域のうち、当該チェックサム実行領域情報に対応する領域のチェックサムを算出し、そのチェックサム算出結果を含む送信パケットを基地局制御装置２０に送信する。

Ｓ２０７において、図３に示すＳ１０３乃至Ｓ１１５と同様の処理Ａが実行される。

Ｓ２０９において、移動体端末４０Ａは、再構成された送信パケットに破損があるか否か、本実施形態では再構成された送信パケットを構成する各フレームのSequence Numberに抜けがあるか否か判定する。また、移動体端末４０Ａは、この判定がＹＥＳである場合にはＳ２１５の処理に移り、ＮＯである場合にはＳ２１３の処理に移る。

Ｓ２１３において、移動体端末４０Ａは、再構成された送信パケットのＴＣＰコネクション識別情報（ここでは、送信元ＩＰアドレス、送信先ＩＰアドレス、送信元ポート番号及び送信先ポート番号）を用いて送信パケットのＴＣＰコネクションを決定し、そのＴＣＰコネクションを用いてＡｃｋパケットをサーバ１０に向けて送信する。

Ｓ２１５において、移動体端末４０Ａは、破損された送信パケットである破損パケットの領域のうち、ＴＣＰコネクション識別情報に対応する領域のチェックサムを算出する。

Ｓ２１７において、移動体端末４０Ａは、Ｓ２１５によるチェックサム算出結果と、破損パケットに含まれている予め算出されたチェックサム算出結果とを比較し、両チェックサム算出結果が同一であるか否か、すなわちＴＣＰコネクション識別情報に破損がないか否か判定する。

また、移動体端末４０Ａは、この判定がＹＥＳである場合、すなわちＴＣＰコネクション識別情報に破損がない場合（図６に示す破損パケット１を参照）にはＳ２１９の処理に移り、ＹＥＳである場合、すなわちＴＣＰコネクション識別情報に破損がある場合（図６に示す破損パケット２を参照）にはＳ２２３の処理に移る。

Ｓ２１９において、移動体端末４０Ａは、破損パケットのＴＣＰコネクション識別情報に破損がないため、当該ＴＣＰコネクション識別情報を用いて破損パケットのＴＣＰコネクションを決定し、そのＴＣＰコネクションを用いてＡｃｋパケットと破損発生情報とをサーバ１０に向けて送信する。

Ｓ２２１において、破損パケットのＴＣＰコネクション識別情報に破損がある場合には、移動体端末４０Ａは、Ａｃｋパケットをサーバ１０に向けて送信しないため、当該サーバ１０は、破損パケットに対応する再送パケットを移動体端末４０Ａに向けて送信する。

Ｓ２２３において、移動体端末４０Ａは、破損パケットのＴＣＰコネクション識別情報に破損がある場合には、破損パケットの内容と再送パケットの内容とを比較し、Ｓ２２５において、破損パケットのペイロード部と再送パケットのペイロード部とが同一である場合（図６参照）には、Ｓ２２７において、再送パケットを構成するＴＣＰ／ＩＰヘッダの一部であるＴＣＰコネクション識別情報に基づいて、破損パケットのＴＣＰコネクションを決定し、そのＴＣＰコネクションを用いてＡｃｋパケットと破損発生情報とをサーバ１０に向けて送信する。

なお、本実施形態における移動体端末４０Ａは、破損パケットのペイロード部と再送パケットのペイロード部とを１ビットづつ比較し、各ビットの一致する割合が所定割合以上である場合には、破損パケットのペイロード部と再送パケットのペイロード部とが同一であると判定する。

ここで、上記で既に説明したが、従来からのＴＣＰ Hackでは、サーバ１０が送信パケットを送信する場合には、サーバ１０はＴＣＰ／ＩＰヘッダのチェックサムの算出結果を送信パケットに含めて送信する。無線通信網５０上で送信パケットが送信されている際に、送信パケットを構成するいずれかのフレームの損失や、フレームのビットエラーによる破損等が発生すると、移動体端末４０では、これらの各フレームに基づいて破損した送信パケットを再構成することとなる（図１及び図８参照）。

通常これらの送信パケットは、破損パケットとして破棄されるが、ＴＣＰ Hackでは、移動体端末４０は、破損パケット中のＴＣＰ／ＩＰヘッダのチェックサムを算出する。移動体端末４０は、破損パケットのＴＣＰ／ＩＰヘッダに破損がなければ、どのＴＣＰコネクションに無線エラーが発生したかを決定することができる。

そして、移動体端末４０は、決定したＴＣＰコネクションを用いて、無線エラーによる送信パケットの破損が発生したことを示す破損発生情報をサーバ１０に送信する。当該サーバ１０は、当該破損発生情報を受信した場合には、上記ＴＣＰコネクションで無線エラーが発生しただけで、送信パケットの輻輳が発生していないと判定することができるため、移動体端末４０に対して送信パケットを送信するためのＴＣＰコネクションにおいて送信パケットのデータ伝送速度を減少させるための輻輳制御を中止することができる。

しかしながら、従来からのＴＣＰ Hackでは、移動体端末４０は、上述のように破損パケットのＴＣＰ／ＩＰヘッダに破損がない場合には、どのＴＣＰコネクションで無線エラーが発生したかを決定することができるが、破損パケットのＴＣＰ／ＩＰヘッダに破損がある場合には、どのＴＣＰコネクションに無線エラーが発生したかを決定することができない。このため、サーバ１０は、ＴＣＰコネクションを介して上記破損発生情報を受信することができないため、輻輳による送信パケットの損失が発生したと誤認することとなり、送信パケットのデータ伝送速度を必要以上に減少させることとなる。

本実施形態では、移動体端末４０Ａは、破損パケットのＴＣＰ／ＩＰヘッダの一部に破損がある場合には、破損パケットの内容と再送パケットの内容とを比較し、破損パケットのペイロード部と再送パケットのペイロード部とが同一である場合には、再送パケットを構成するＴＣＰ／ＩＰヘッダの一部に基づいて、破損パケットのＴＣＰコネクションを決定する。

これにより、サーバ１０は、決定されたＴＣＰコネクションを用いて上記破損発生情報を移動体端末４０Ａから受信することにより、輻輳による送信パケットの損失が発生したと誤認することなく、無線エラーによる送信パケットの損失が発生したと判定することができるため、決定されたＴＣＰコネクションで送信パケットのデータ伝送速度を減少させるための輻輳制御を中止することができ、決定されたＴＣＰコネクションで送信パケットのデータ伝送速度を必要以上に減少させないようにすることができる。

また、移動体端末４０Ａは、破損パケット及び再送パケットのＴＣＰコネクションを決定する場合には、破損パケット及び再送パケットのＴＣＰ／ＩＰヘッダの全体を用いておらず、破損パケット及び再送パケットのＴＣＰ／ＩＰヘッダの一部のみしか用いていないため、破損パケットのＴＣＰコネクションを決定する上での処理の高効率化を図ることができる。

［変更例］
なお、本発明は、第１実施形態及び第２実施形態に限定されずに、下記に示す変更を加えてもよい。具体的には、通信システムは、上記「Enhanced ＴＣＰ Vegas」を用いて通信する機能を備えるものとして説明したが、これに限定されずに、上記「ＴＣＰ Vegas」等を用いて通信する機能を備えてもよい。

すなわち、通信システムは、上記「Enhanced ＴＣＰ Vegas」を用いて通信する機能を備えることにより、サーバ１０により送信パケットが送信された送信時刻ｓと、移動体端末４０により送信パケットが受信された受信時刻ｔとを用いて算出される伝送所要時間（例えば、ＲＴＤ）に基づいて、送信パケットの送信間隔を調整することにより輻輳制御を実行しているが、これに限定される分けではない。

例えば、通信システムは、上記「ＴＣＰ Vegas」を用いて通信する機能を備えることにより、サーバ１０により送信パケットが送信された送信時刻ｓと、サーバ１０によりＡｃｋパケットが受信された受信時刻ｔとを用いて算出される伝送所要時間（例えば、ＲＴＴ）に基づいて、送信パケットの送信間隔を調整することにより輻輳制御を実行してもよい。

また、第１実施形態及び第２実施形態が組み合わされてもよい。例えば、図５に示す第２実施形態に対して図３に示す第１実施形態の一部が含まれる構成にしてもよい。すなわち、図５に示す第２実施形態のＳ２０７とＳ２０９との間に、図３に示す第１実施形態のＳ１１９乃至Ｓ１２３を挿入し、図５に示す第２実施形態のＳ２１３，Ｓ２１９及びＳ２２７において送信パケットの送信時刻ｓ及び送信パケットの受信時刻ｔ（再送フレームがある場合には送信パケットの受信時刻ｔはなし）を含むＡｃｋパケットをサーバ１０に向けて送信するという第１実施形態及び第２実施形態の組合せが挙げられる。

以上、本発明の一例を説明したが、具体例を例示したに過ぎず、特に本発明を限定するものではなく、各部の具体的構成等は、適宜設計変更可能である。また、各実施形態及び変更例の作用及び効果は、本発明から生じる最も好適な作用及び効果を列挙したに過ぎず、本発明による作用及び効果は、各実施形態及び変更例に記載されたものに限定されるものではない。

第１実施形態における通信システム及び移動体端末の構成を示す図である。第１実施形態における移動体端末の構成を示す図である。第１実施形態におけるサーバ、基地局制御装置及び移動体端末の動作を示す図である。第２実施形態における移動体端末の構成を示す図である。第２実施形態におけるサーバ、基地局制御装置及び移動体端末の動作を示す図である。第２実施形態における破損パケット及び再送パケットを示す図である。従来における送信装置、基地局制御装置及び受信装置の構成を示す図である。従来における送信装置、基地局制御装置及び受信装置の構成を示す図である。

符号の説明

１…送信装置、２…基地局制御装置、３…有線通信網、４…受信装置、１０…サーバ、２０…基地局制御装置、３０…有線通信網、４０…移動体端末、４１…受信部、４２…再送要求情報格納部、４３…ＡＲＱ再送用フレームバッファ、４４…パケット再構成部、４５…送信部、４６…ＴＣＰコネクション管理部、４７…チェックサム検証部、４８…破損パケットバッファ、５０…無線通信網

Claims

送信元によって送信される送信パケットの送信時刻と、該送信パケットを受信した受信時刻又は該送信パケットに対応する確認応答パケットを受信した受信時刻とを用いて算出される伝送所要時間を測定する通信装置であって、
前記通信装置が受信した前記送信パケットを構成する複数フレームに、再送されたフレームである再送フレームが含まれていない場合には、最後に受信されたフレームの受信時刻を送信パケットの受信時刻として決定し、再送フレームが含まれている場合には、再送フレームを除く最後に受信されたフレームの受信時刻を送信パケットの受信時刻として決定するパケット再構成部を備えることを特徴とする通信装置。
前記パケット再構成部は、再送フレームが含まれている場合にのみ、前記伝送所要時間の算出を中止することを特徴とする請求項１に記載の通信装置。
送信元によって送信される送信パケットの送信時刻と、該送信パケットを受信した受信時刻又は該送信パケットに対応する確認応答パケットを受信した受信時刻とを用いて算出される伝送所要時間に基づいて、前記送信パケットの送信間隔を調整することにより輻輳制御を実行する通信システムで用いられる通信装置であって、
前記通信装置が受信した前記送信パケットを構成する複数フレームに、再送されたフレームである再送フレームが含まれていない場合には、最後に受信されたフレームの受信時刻を送信パケットの受信時刻として決定し、再送フレームが含まれている場合には、再送フレームを除く最後に受信されたフレームの受信時刻を送信パケットの受信時刻として決定するパケット再構成部を備えることを特徴とする通信装置。
前記パケット再構成部は、再送フレームが含まれている場合にのみ、前記伝送所要時間の算出を中止することを特徴とする請求項３に記載の通信装置。
送信元によって送信される送信パケットの送信時刻と、該送信パケットを受信した受信時刻又は該送信パケットに対応する確認応答パケットを受信した受信時刻とを用いて算出される伝送所要時間を測定する所要時間測定方法であって、
前記通信装置が受信した前記送信パケットを構成する複数フレームに、再送されたフレームである再送フレームが含まれていない場合には、最後に受信されたフレームの受信時刻を送信パケットの受信時刻として決定し、再送フレームが含まれている場合には、再送フレームを除く最後に受信されたフレームの受信時刻を送信パケットの受信時刻として決定するステップを備えることを特徴とする所要時間測定方法。
前記決定するステップでは、再送フレームが含まれている場合にのみ、前記伝送所要時間の算出を中止することを特徴とする請求項５に記載の所要時間測定方法。
送信元によって送信される送信パケットの送信時刻と、該送信パケットを受信した受信時刻又は該送信パケットに対応する確認応答パケットを受信した受信時刻とを用いて算出される伝送所要時間に基づいて、前記送信パケットの送信間隔を調整することにより輻輳制御を実行する通信システムで用いられる通信制御方法であって、
前記通信装置が受信した前記送信パケットを構成する複数フレームに、再送されたフレームである再送フレームが含まれていない場合には、最後に受信されたフレームの受信時刻を送信パケットの受信時刻として決定し、再送フレームが含まれている場合には、再送フレームを除く最後に受信されたフレームの受信時刻を送信パケットの受信時刻として決定するステップを備えることを特徴とする通信制御方法。
前記決定するステップでは、再送フレームが含まれている場合にのみ、前記伝送所要時間の算出を中止することを特徴とする請求項７に記載の通信制御方法。