JP4645281B2 - 情報処理装置および方法、プログラム、並びに記録媒体 - Google Patents

情報処理装置および方法、プログラム、並びに記録媒体 Download PDF

Info

Publication number
JP4645281B2
JP4645281B2 JP2005120550A JP2005120550A JP4645281B2 JP 4645281 B2 JP4645281 B2 JP 4645281B2 JP 2005120550 A JP2005120550 A JP 2005120550A JP 2005120550 A JP2005120550 A JP 2005120550A JP 4645281 B2 JP4645281 B2 JP 4645281B2
Authority
JP
Japan
Prior art keywords
packet
time
information processing
processing apparatus
transmission
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
JP2005120550A
Other languages
English (en)
Other versions
JP2006303750A (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.)
Sony Corp
Original Assignee
Sony Corp
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 Sony Corp filed Critical Sony Corp
Priority to JP2005120550A priority Critical patent/JP4645281B2/ja
Priority to US11/400,286 priority patent/US8441943B2/en
Priority to CN2006100762335A priority patent/CN1855935B/zh
Publication of JP2006303750A publication Critical patent/JP2006303750A/ja
Application granted granted Critical
Publication of JP4645281B2 publication Critical patent/JP4645281B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852Delays
    • H04L43/0864Round trip delays
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/28Timers or timing mechanisms used in protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Maintenance And Management Of Digital Transmission (AREA)

Description

本発明は、情報処理装置および方法、プログラム、並びに記録媒体に関し、特に、データ通信における送受信端末間の伝送往復遅延を正確に計算することができるようにする情報処理装置および方法、プログラム、並びに記録媒体に関する。
従来、パケット通信を利用して、送信端末から受信端末に、例えば、動画データの実時間ストリーミングを行う情報処理システムがある。また、近年のネットワーク帯域の増大(ネットワークの高速化)に伴い、UDP(User Datagram Protocol)を利用したインターネットストリーミングが行なわれるようになってきた。UDPは、TCPと異なりレート制御の仕組みが無いため、RFC3448で規定されるTFRC(TCP Friendly Rate Control)などのレート制御の仕組みを利用して、インターネット内でTCPと共存可能な通信方法となることが期待されている。
TCPでは、予め設定されたタイムアウト時間と、パケットの送受信に伴って測定される送受信端末間の伝送往復遅延(RTT:Round Trip Time)に基づいて、パケットロスの判定を行っている。例えば、設定したタイムアウト時間内に受信端末からの確認応答パケットが到着しなければ、パケットが廃棄されたと判定し、送信レートを制御するなどして輻輳回避を行う。すなわち、インターネットを利用して動画データのストリーミングなどを行う場合、UDPにおいても、TCPと同様にレート制御を行うためにRTTを計算することが期待されている。
図1は、従来のRTTの計測の方法を説明する図である。同図においては、送信端末1からネットワーク3を経由して送信されるデータパケットが、受信端末2により受信され、受信端末2が受信したデータパケットに対応する確認応答パケットが、受信端末2からネットワーク3を経由して送信端末1に送信され、送信端末1により受信される。
送信端末1は、自身が実装するソフトウェアまたはハードウェアにおけるアプリケーション層において、データパケットにタイムスタンプを付与してから、アプリケーション層の下位層であるトランスポート層乃至データリンク層(TCP/IP、MAC(Media Access Control)など)の処理を経てデータパケットを送信する。そして、受信端末2から送信され、送信端末1により受信された確認応答パケットも、送信時とは逆にトランスポート層乃至データリンク層(TCP/IP、MAC(Media Access Control)など)の処理を経てアプリケーション層に取得され、RTTが計算される。
送信端末1のアプリケーション層においてデータパケットにタイムスタンプが付与された時刻を時刻Ttsとする。受信端末2においてデータパケットを受信した時刻、確認応答パケットを送信した時刻をそれぞれTrr、Trxとする。また、送信端末1において、確認応答パケットがアプリケーション層で取得される時刻をTcとし、各時刻を時系列に表すと図2に示されるようになる。同図において、縦軸は時間軸であり、図中上から下に向かって時間が経過していくものとする。
したがって、送信端末1において、RTTは次式のようにして計算される。
RTT = Tc−Tts
また、受信端末2がデータパケットを受信してから、確認応答パケットを送信するまでにどの程度の時間を費やしたかを、確認応答パケットに記述して送り返すようにすれば、次式のようにRTTをさらに正確に計算することができる。
RTT = (Tc−Tts)−(Trx−Trr)
このようにして計算されるRTTは、上述した送信レートの制御など、通信処理における様々な制御にもちいられている。また、RTTに基づいて、ARQ(Automatic Repeat Request)、FEC(Forward Error Collection)などのエラー訂正に関する処理を動的に変更する技術も提案されている(例えば、特許文献1参照。)
特開2003−179580号公報
しかしながら、従来のRTTの計算方法は、送信端末1のアプリケーション層において、データパケットにタイムスタンプが付与された時刻またはアプリケーション層において確認応答パケットが取得された時刻が、パケットの送信時刻または受信時刻とされRTTが計算されているが、正確には、アプリケーション層の下位層であるトランスポート層乃至データリンク層(TCP/IP、MACなど)の処理を経てネットワーク3にデータパケットが送出された時刻がパケットの送信時刻であり、送信端末1の物理層においてネットワーク3から確認応答パケットが取り出された時刻がパケットの受信時刻である。すなわち、従来のRTTの計算方法は、送信端末1内部の処理による伝送遅延が考慮されていなかった。
これに対して、近年のブロードバンドネットワークの普及に伴ってRTTの計算方法を見直す必要に迫られている。すなわち、従来、インターネットなど、例えば個人が利用する安価なネットワークの帯域(伝送速度)は、数十Kbps〜数百Kbpsが主流であり、ネットワーク3の伝送遅延と比して、端末内の処理に要する時間は無視できる程小さい(短い)ものであったが、近年では、1Gbpsに近い帯域の利用が充分安価に可能となっており、従来と比してネットワーク上で利用できる帯域は飛躍的に拡大した。一方で、送信装置1内でのデータの伝送速度(処理速度)は、従来と比して飛躍的に向上しているとはいい難い。
また、例えば、送信端末1のアプリケーションに含まれる画像データの圧縮符号化など処理負荷の高いプログラムが稼動している場合、RTTの計算処理が遅延してしまい、正確かつ適時にRTTを算出することができない。
従って、ネットワーク3上をパケットが通過するのに要する時間と比して、アプリケーション層乃至データリンク層の処理を経てパケットがネットワーク3に対して送信または受信されるのに要する時間は無視できる程小さい(短い)とは言えず、今後は、送信装置1内部における伝送遅延も考慮してRTTを計算する必要がある。
本発明はこのような状況に鑑みてなされたものであり、データ通信における送受信端末間の伝送往復遅延を正確に計算することができるようにするものである。
本発明の情報処理装置は、アプリケーション層のプログラムにより画像処理を実行するとともに、ネットワークを介して接続される他の情報処理装置と通信を行い、ネットワークインタフェースカードと、ネットワークインタフェースカードを制御するデバイスドライバ有する情報処理装置であって、アプリケーション層に設けられ、他情報処理装置とのデータの送受信の実行、または伝送往復遅延の計算の実行を制御する実行制御手段と、デバイスドライバの一部として設けられ、伝送往復遅延の計算において他の情報処理装置からの応答を得るために他の情報処理装置に送信される第1のパケットを生成するパケット生成手段と、MAC層のネットワークインタフェースカードの一部として設けられ、生成された第1のパケットを、ネットワークに送出するときの時刻を、第1のパケットの送信時刻として送信時刻を含む第1のタイムスタンプを生成する第1のタイムスタンプ生成手段と、MAC層のネットワークインタフェースカードの一部として設けられ、第1のパケットに対する応答として他の情報処理装置から送信されるパケットであって、第2のパケットをネットワークから取得するときの時刻を、第2のパケットの受信時刻として受信時刻を含む第2のタイムスタンプを生成する第2のタイムスタンプ生成手段と、デバイスドライバの一部として設けられ、第1および第2のタイムスタンプを取得する取得手段と、デバイスドライバの一部として設けられ、取得手段により取得された第1および第2のタイムスタンプに基づいて、自分と他の情報処理装置との間の伝送往復遅延を算出する算出手段と、デバイスドライバの一部として設けられ、算出された伝送往復遅延のデータを、他の情報処理装置とのデータの送受信の実行に関するデータの授受を行うインタフェースとは異なるインタフェースを介してアプリケーション層に通知する通知手段とを備えることを特徴とする。
前記第1のパケットの宛先アドレスおよびパケットの種類に関する情報を含むフロー情報を記憶するフロー情報記憶手段をさらに備えるようにすることができる。
前記ネットワークから取得されるパケットの送信元アドレスおよびパケットの種類に関する情報と、フロー情報記憶手段に記憶されるフロー情報とを比較して、ネットワークから取得されるパケットが第2のパケットであるか否かを判定する判定手段をさらに備えるようにすることができる。
本発明の情報処理方法は、アプリケーション層のプログラムにより画像処理を実行するとともに、ネットワークを介して接続される他の情報処理装置と通信を行い、ネットワークインタフェースカードと、ネットワークインタフェースカードを制御するデバイスドライバ有する情報処理装置の情報処理方法であって、アプリケーション層に設けられた実行制御手段が、他の情報処理装置とのデータの送受信の実行、または伝送往復遅延の計算の実行を制御し、デバイスドライバの一部として設けられたパケット生成手段が、伝送往復遅延の計算において他の情報処理装置からの応答を得るために他の情報処理装置に送信される第1のパケットを生成し、MAC層のネットワークインタフェースカードの一部として設けられた第1のタイムスタンプ生成手段が、生成された第1のパケットを、ネットワークに送出するときの時刻を、第1のパケットの送信時刻として送信時刻を含む第1のタイムスタンプを生成し、MAC層のネットワークインタフェースカードの一部として設けられた第2のタイムスタンプ生成手段が、第1のパケットに対する応答として他の情報処理装置から送信されるパケットであって、第2のパケットをネットワークから取得するときの時刻を、第2のパケットの受信時刻として受信時刻を含む第2のタイムスタンプを生成し、デバイスドライバの一部として設けられた取得手段が、第1および第2のタイムスタンプを取得し、デバイスドライバの一部として設けられた算出手段が、取得手段により取得された第1および第2のタイムスタンプに基づいて、自分と他の情報処理装置との間の伝送往復遅延を算出し、デバイスドライバの一部として設けられた通知手段が、算出された伝送往復遅延のデータを、他の情報処理装置とのデータの送受信の実行に関するデータの授受を行うインタフェースとは異なるインタフェースを介してアプリケーション層に通知するステップを含むことを特徴とする。
本発明のプログラムは、コンピュータを、アプリケーション層のプログラムにより画像処理を実行するとともに、ネットワークを介して接続される他の情報処理装置と通信を行い、ネットワークインタフェースカードと、ネットワークインタフェースカードを制御するデバイスドライバ有する情報処理装置であって、アプリケーション層に設けられ、他の情報処理装置とのデータの送受信の実行、または伝送往復遅延の計算の実行を制御する実行制御手段と、デバイスドライバの一部として設けられ、伝送往復遅延の計算において他の情報処理装置からの応答を得るために他の情報処理装置に送信される第1のパケットを生成するパケット生成手段と、MAC層のネットワークインタフェースカードの一部として設けられ、生成された第1のパケットを、ネットワークに送出するときの時刻を、第1のパケットの送信時刻として送信時刻を含む第1のタイムスタンプを生成する第1のタイムスタンプ生成手段と、MAC層のネットワークインタフェースカードの一部として設けられ、第1のパケットに対する応答として他の情報処理装置から送信されるパケットであって、第2のパケットをネットワークから取得するときの時刻を、第2のパケットの受信時刻として受信時刻を含む第2のタイムスタンプを生成する第2のタイムスタンプ生成手段と、デバイスドライバの一部として設けられ、第1および第2のタイムスタンプを取得する取得手段と、デバイスドライバの一部として設けられ、取得手段により取得された第1および第2のタイムスタンプに基づいて、自分と他の情報処理装置との間の伝送往復遅延を算出する算出手段と、デバイスドライバの一部として設けられ、算出された伝送往復遅延のデータを、他の情報処理装置とのデータの送受信の実行に関するデータの授受を行うインタフェースとは異なるインタフェースを介してアプリケーション層に通知する通知手段とを備える情報処理装置として機能させる。
本発明の情報処理装置および方法、並びにプログラムにおいては、アプリケーション層に設けられた実行制御手段により、他の情報処理装置とのデータの送受信の実行、または伝送往復遅延の計算の実行が制御され、デバイスドライバの一部として設けられたパケット生成手段により、伝送往復遅延の計算において他の情報処理装置からの応答を得るために他の情報処理装置に送信される第1のパケットが生成され、MAC層のネットワークインタフェースカードの一部として設けられた第1のタイムスタンプ生成手段により、生成された第1のパケットを、ネットワークに送出するときの時刻を、第1のパケットの送信時刻として送信時刻を含む第1のタイムスタンプが生成され、MAC層のネットワークインタフェースカードの一部として設けられた第2のタイムスタンプ生成手段により、第1のパケットに対する応答として他の情報処理装置から送信されるパケットであって、第2のパケットをネットワークから取得するときの時刻を、第2のパケットの受信時刻として受信時刻を含む第2のタイムスタンプが生成され、デバイスドライバの一部として設けられた取得手段により、第1および第2のタイムスタンプが取得され、デバイスドライバの一部として設けられた算出手段により、第1および第2のタイムスタンプに基づいて、自分と他の情報処理装置との間の伝送往復遅延が算出され、デバイスドライバの一部として設けられた通知手段により、伝送往復遅延のデータが、他の情報処理装置とのデータの送受信の実行に関するデータの授受を行うインタフェースとは異なるインタフェースを介してアプリケーション層に通知される。
本発明によれば、データ通信における送受信端末間の伝送往復遅延を正確に計算することができる。
以下、図面を参照して、本発明の実施の形態について説明する。
図3は、本発明を適用した通信システムの一実施形態に係る構成例を示す図である。
図3において、通信システム100は、送信装置101、受信装置102、およびインターネットなどのネットワーク103により構成され、送信装置101と受信装置102がネットワーク10を介してデータを送受信するシステムである。例えば、送信装置101は、動画像などのデータをパケット化して、データパケットとして受信装置102にストリーミング送信し、受信装置102がデータパケットを受信して動画像を再生する。また、受信装置102は、送信装置101が送信したデータパケットに対応する確認応答パケットを、送信装置101に送信する。
なお、確認応答パケットには、受信装置102がデータパケットを受信した時刻および受信装置102が確認応答パケットを送信した時刻などRTTの計算に必要となる情報が記述されており、ここでは、受信装置102から送信装置101に送信されるパケットのうち、送信装置101から送信されて受信したデータパケットに対して受信装置102が応答として返信するパケットを確認応答パケットと称する。
送信装置101は、受信装置102から送信された確認応答パケットを受信して、送信装置101と受信装置102との間の伝送往復遅延(RTT:Round Trip Time)を計算する。そして、送信装置101は、RTTと、RTTに基づいて設定されるタイムアウト時間に基づいて、パケットロスの判定を行ない、設定したタイムアウト時間内に受信装置102からの確認応答パケットが到着しなければ、パケットが廃棄されたと判定し、送信レートを変更するなどして輻輳回避の処理を行う。
ここで、送信装置101から送信されるパケットのパケットサイズをs、RTTをR、ロス率(0〜 1.0)をp、タイムアウト時間をt RTO、確認応答パケットの送信の割合(何個のパケット毎に確認応答を返すか)をbとすると、送信レートXは、例えば式(1)の通り計算できる。
Figure 0004645281
このうち、パケットサイズsと確認応答パケットの送信の割合b(通常1または2)は定数、t RTOは通常4×RTTなので、ネットワーク中のパケットロス率とRTTによって送信レートが決定することが分かる。
送信装置101は、例えば、このようにして計算される送信レートXに基づいて、自身の送信レートを制御するなどして輻輳回避の処理を行う。
図4は、上述したRTTの計算にあたって送信装置101と受信装置102との間で行われる処理と時間の経過を説明する図である。同図においては、縦軸が時間軸であり、送信装置101と受信装置102において行われる処理が、その処理が行われる時刻とともに示されており、図中上から下に向かって時間が経過していくものとする。
送信装置101は、時刻Ttsにおいて、RTTを計算するためにデータパケットの送信を要求し、時刻Txxにおいて、そのデータパケットがネットワーク103に送出される。
受信装置102は、時刻Trrにおいて、ネットワーク103を経て送信されてきたデータパケットを受信し、時刻Trxにおいて、受信したデータパケットに対応する確認応答パケットをネットワーク103に送出する。
その後、送信装置101は、時刻Trxにおいて、ネットワーク103を経て送信されてきた確認応答パケットを、ネットワークから取り出して(取得して)受信し、時刻Tcにおいて、受信した確認応答パケットに基づいてRTTの計算を開始する。
従来の狭帯域ネットワークを利用する場合、通信システム100において、ネットワーク103で発生する遅延と比して、送信装置101内の処理に要する時間は無視できる程小さい(短い)ものであった。
しかし、近年のブロードバンドネットワークの普及に伴って、ネットワーク103の帯域は充分広くなっており(高速化されており)、RTTを正確に計算するためには、送信装置101内の処理に要する時間は無視できないものとなってきている。
そこで、本発明では、送信装置101内の処理に要する時間を考慮してRTTを計算する。すなわち、従来は、送信装置101内の処理に要する時間を考慮せず時刻Ttsにおいてデータパケットが送信されたものとして近似され、時刻Tcにおいて確認応答パケットが受信されたものとして近似されてRTTが計算されていたが、本発明では、時刻Ttxにおいてデータパケットが送信され、時刻Txrにおいて確認応答パケットが受信されたものとしてRTTを計算する。このようにすることで、送信装置101内の処理に要する時間を考慮した、より正確なRTTの計算が可能となる。
図5は、送信装置101の内部構成例を示すブロック図である。同図において、CPU(Central Processing Unit)151は、ROM(Read Only Memory)152に記憶されているプログラム、または記憶部158からRAM(Random Access Memory)153にロードされたプログラムに従って各種の処理を実行する。RAM153にはまた、CPU151が各種の処理を実行する上において必要なデータなども適宜記憶される。
CPU151、ROM152、およびRAM153は、バス154を介して相互に接続されている。このバス154にはまた、入出力インタフェース155も接続されている。
入出力インタフェース155には、キーボード、マウスなどよりなる入力部156、CRT(Cathode Ray Tube)、LCD(Liquid Crystal display)などよりなるディスプレイ、並びにスピーカなどよりなる出力部157、ハードディスクなどより構成される記憶部158、モデム、LANカードなどのネットワークインタフェースカードなどより構成される通信部159が接続されている。通信部159は、インターネットを含むネットワークを介しての通信処理を行う。
入出力インタフェース155にはまた、必要に応じてドライブ160が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア161が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部158にインストールされる。
図6は、図5のCPU151により実行されるソフトウェアの機能的構成例を示すブロック図である。
同図において、CPU151により実行されるソフトウェアがアプリケーション201、デバイスドライバ202、およびMAC(Media Access Control)の3つの階層により構成されている。
アプリケーション201は、例えば、受信装置102に対して行われるデータの送受信などを制御する一連のアプリケーションプログラムなどが含まれる階層を表すプログラム群であり、必要に応じてRTTの計算と、RTTの計算に必要な処理の実行を制御する。アプリケーション201は、OSI参照モデルにおいては、ネットワーク層を含むネットワーク層より上位の各層に対応することになる。
デバイスドライバ202は、例えば、送信装置101の通信部159に対応するネットワークインタフェースカードなどの通信デバイスを制御するプログラムが含まれる階層を表すプログラム群であり、アプリケーション201からの指令に基づいて、パケットの送信若しくは受信、または後述するタイムスタンプの提供などの処理を実行する。なお、デバイスドライバ202は、OSI参照モデルにおいては、データリンク層に対応することになる。
MAC203は、デバイスドライバ202により制御される通信デバイスの機能ブロックが含まれる階層を表しており、実際には、ネットワークインタフェースカードなどのハードウェアとして設けられるようにしてもよい。MAC203は、デバイスドライバ202の制御に基づいて、ネットワーク103にパケットを送出(送信)し、またネットワーク103からパケットを取り出す(受信する)とともに、送信または受信するパケットの送信時刻または受信時刻を表すタイムスタンプを付与(生成)する。なお、MAC203は、OSI参照モデルにおいては、データリンク層(ただし一部は物理層)に対応することになる。
アプリケーション201は、デバイスドライバ202に設けられ、図中円で示された3つのインタフェースであるインタフェースA乃至Cを用いて、デバイスドライバ202とのデータの送受信を行う。
アプリケーション201には、例えば受信装置102とのTCP/IP通信またはUDPの通信を行うためのパケットの生成、送達確認、データ量の制御などを行う一連のプログラムなどで構成されるTCPI/IPのプロトコルスタックが含まれている。例えば、送信装置101から送信されるデータであって、受信装置102との間で送受信される動画像のデータなどは、TCPI/IPのプロトコルスタックによる処理を経てネットワーク103に対して送信または受信される。なお、TCPI/IPのプロトコルスタックを構成する一連のプログラムは、例えば、一般に流通するOS(Operating System)などに組み込まれており、実際にはUDPの通信に関する処理も行うが、ここでは、TCPI/IPのプロトコルスタックと称する。
インタフェースAまたはBは、ネットワーク103に対してパケットを送信または受信するための処理に必要なデータの送受信に用いられるインタフェースであり、例えば、アプリケーション201に含まれるTCPI/IPのプロトコルスタックなどに対応するように構成されている。すなわち、インタフェースAまたはBは、例えば、一般に流通しているネットワークインタフェースカードのドライバソフトなどのインタフェースと同様に構成される。
インタフェースCは、アプリケーション201の指令に基づいて、タイムスタンプを提供する処理に必要なデータの送受信に用いられるインタフェースであり、TCPI/IPのプロトコルスタックなどの処理を経て行われるネットワーク103に対してのパケットの送信または受信の処理には用いられない。したがって、デバイスドライバ202およびMAC203を送信装置101に実装するにあたって、アプリケーション201に含まれるTCP/IPのプロトコルスタックなどを変更する必要はない。
RTTの計算を行う場合、アプリケーション201は、インタフェースAを介してパケット送信部221にパケットの送信の指令を出力し(図4の時刻Tts)、パケット送信部221は、MACパケット送信部241を制御して、MACアドレスを付与してデータパケットを生成し、ネットワーク103に送出させる。このとき、送出されるデータパケットが、タイムスタンプ付与部244を経由し、タイムスタンプ付与部244において計時部245の出力値に基づく現在時刻が取得されて、送信時刻(図4の時刻Txx)を表すタイムスタンプが生成され、タイムスタンプ通知部242に出力される。なお、計時部245が、送信装置101に内蔵されるタイマなどに基づいて現在時刻を計時するようにしてもよいし、ネットワーク103を介して取得される他の装置からの情報に基づいて現在時刻を計時するようにしてもよい。
タイムスタンプ通知部242は、タイムスタンプ保持部222にデータパケットの送信時刻を表すタイムスタンプを通知し、タイムスタンプ保持部222がそれを保持(記憶)する。
また、受信装置102から送信された確認応答パケットが、ネットワーク103からタイムスタンプ付与部244を経由して取り出され、MACパケット受信部243、およびパケット223により受信される。このとき、タイムスタンプ付与部244において計時部245の出力値に基づく現在時刻が取得されて、受信時刻(図4の時刻Txr)を表すタイムスタンプが生成され、タイムスタンプ通知部242に出力される。
タイムスタンプ通知部242は、タイムスタンプ保持部222に確認応答パケットの受信時刻を表すタイムスタンプを通知し、タイムスタンプ保持部222がそれを保持(記憶)する。
パケット受信部223が、インタフェースBを介してアプリケーション201に確認応答パケットを供給するとともに確認応答パケットの受信を通知すると、アプリケーション201は、インタフェースCを介してタイムスタンプ保持部222にタイムスタンプの取得要求を出力し、タイムスタンプ保持部222からデータパケットの送信時刻を表すタイムスタンプと、確認応答パケットの受信時刻を表すタイムスタンプとを取得して、例えば式(2)によりRTTを計算する。
RTT = (Txr−Txx)−(Trx−Trr) ・・・(2)
次に、図7と図8のフローチャートを参照して、送信装置101の図6を参照して上述した各部によるRTT計算処理について説明する。この処理は、例えば、所定の間隔で定期的に実行されるようにしてもよいし、ユーザによる指令などに基づいて実行されるようにしてもよい。
ステップS101において、アプリケーション201は、パケット送信部221にRTTを計算するためのデータパケットの送信を指令する(図4の時刻Tts)。これによりパケット送信部221は、MACパケット送信部241を制御して、MACアドレスを付与してデータパケットを生成し、タイムスタンプ付与部244に出力する。
ステップS102において、タイムスタンプ付与部244は、計時部245の出力値に基づいて現在時刻を取得して、タイムスタンプを付与する。このとき、データパケットの送信時刻(図4の時刻Txx)を表すタイムスタンプが生成され、タイムスタンプ通知部242に出力される。
ステップS103において、タイムスタンプ付与部244は、データパケットをネットワーク103に送出する。ここで、ネットワーク103に送出されたデータパケットは、受信装置102により受信され(図4の時刻Trr)、また、受信装置102は、受信したデータパケットに対応する確認応答パケットをネットワーク103を介して送信装置101に送信する(図4の時刻Trx)。
ステップS104において、タイムスタンプ通知部242は、ステップS102の処理により付与されたタイムスタンプを、タイムスタンプ保持部222に通知(出力)する。
ステップS105において、タイムスタンプ保持部222は、ステップS104の処理により通知されたタイムスタンプを保持(記憶)する。これにより、タイムスタンプ保持部222にデータパケットの送信時刻(図4の時刻Txx)を表すタイムスタンプが記憶される。
図8のステップS106において、タイムスタンプ付与部244は、ステップS103の処理で送出されたデータパケットに対応して受信装置102により送信された確認応答パケットをネットワーク103から取り出す(受信する)。これにより、確認応答パケットは、MACパケット受信部243、およびパケット223により受信される。
ステップS107において、タイムスタンプ付与部244は、計時部245の出力値に基づいて現在時刻を取得し、タイムスタンプを付与する。このとき、確認応答パケットの受信時刻(図4の時刻Txr)を表すタイムスタンプが生成され、タイムスタンプ通知部242に出力される。
ステップS108において、タイムスタンプ通知部242は、ステップS107の処理により付与されたタイムスタンプを、タイムスタンプ保持部222に通知(出力)する。
ステップS109において、タイムスタンプ保持部222は、ステップS108の処理により通知されたタイムスタンプを保持(記憶)する。これにより、タイムスタンプ保持部222に確認応答パケットの受信時刻(図4の時刻Txr)を表すタイムスタンプが記憶される。
ステップS110において、パケット受信部223は、アプリケーション201に確認応答パケットを供給し、確認応答パケットの受信を通知する。
ステップS111において、アプリケーション201は、タイムスタンプ保持部222に記憶されているデータパケットの送信時刻(図4の時刻Txx)を表すタイムスタンプと、確認応答パケットの受信時刻(図4の時刻Txr)を表すタイムスタンプとを取得する。
ステップS112において、アプリケーション112は、ステップS111の処理により取得されたタイムスタンプと、確認応答パケットの記述内容に基づいて、例えば、式(2)によりRTTを計算する(図4の時刻Tc)。
このようにして、RTTが計算される。このようにすることで、送信装置101の内部での処理に要する時間である図4の時刻Ttsと時刻Txxの差分、および時刻Txrと時刻Tcの差分が含まれないようにして正確にRTTを計算することができる。
また、アプリケーション201とデバイスドライバ202との間で、パケットの送信または受信の処理に必要なデータの送受信に用いられるインタフェース(インタフェースAまたはB)と、タイムスタンプの提供の処理に必要なデータの送受信に用いられるインタフェース(インタフェースC)とがそれぞれ設けられるようにしたので、ユーザは、例えば、従来の送信装置101にMAC203(ネットワークインタフェースカード)およびそれに対応するデバイスドライバ202を組み込むだけで、正確なRTTの計算ができるように対処することができる。
ところで、以上においては、アプリケーション201でRTTを計算する例について説明したが、デバイスドライバ202でRTTを計算させるようにすることも可能である。
図9は、デバイスドライバ202でRTTを計算させるようにした場合の、図5のCPU151により実行されるソフトウェアの機能的構成例を示すブロック図である。同図は、図6に対応するブロック図であり、図6と対応する部分には同一の符号が付されている。
図9においては、デバイスドライバ202の構成が図6の場合と異なっている。すなわち、図9のブロック図においては、コマンド制御部224乃至RTT計測部228が新たに設けられている。
コマンド制御部224は、インタフェースCを介してアプリケーション201からのRTT計算(計測)の指令を受け付け、パケット生成部225を制御して、RTTの計算に必要となるデータパケットを生成させる。
パケット生成部225は、生成したパケットをMACパケット送信部241に出力して、タイムスタンプ付与部244を経てネットワーク103に送出させるとともに、生成したパケットのフロー情報をフロー情報保持部226に出力する。ここで、フロー情報は、RTTの計算に必要となるデータパケットを特定するための情報であり、例えば、データパケットの宛先アドレス(いまの場合、受信端末102のアドレス)、およびデータパケットの種類(例えば、ICMP(Internet Control Message Protocol)Echo Request)などの情報とされる。
また、送出されるデータパケットのタイムスタンプ(データパケットの送信時刻:図4の時刻Txx)がタイムスタンプ通知部242からRTT計測部228に通知される。
一方、ネットワーク103から受信される受信装置102から送信されたパケットは、タイムスタンプ付与部244を経てMACパケット受信部243からフロー特定部227に供給される。フロー特定部227は、MACパケット受信部243から供給されるパケットの送信元アドレス(受信端末102のアドレスか否か)、およびパケットの種類(ICMP Echo Replyであるか否か)などの情報をチェックし、フロー情報保持部226に登録されているフロー情報と比較する。
そして比較結果に基づいて、フロー特定部227は、MACパケット受信部243から供給されたパケットが、RTTの計算のために送信されたデータパケットに対応する確認応答パケットか否かを判定し、当該パケットがRTTの計算のために送信されたデータパケットに対応する確認応答パケットであると判定された場合、タイムスタンプ保持部222から当該パケットのタイムスタンプ(確認応答パケットの受信時刻:図4の時刻Txr)を取得して、RTT計測部228に、当該パケットとともに出力する。
RTT計測部228は、データパケットの送信時刻を表すタイムスタンプと、確認応答パケットの受信時刻を表すタイムスタンプとを取得して、例えば式(2)によりRTTを計算し、計算結果をコマンド制御部224に出力する。
コマンド制御部224は、RTTの計算の完了の通知と、計算結果とをアプリケーション201にインタフェースCを介して出力する。
図9の例の場合、RTTの計算に関する処理以外の通信に伴うデータの送受信が、アプリケーション201とデバイスドライバ202との間で、インタフェースAまたはBを介して行われることになる。
次に図10のフローチャートを参照して、図9のブロック図に対応するRTT計算処理の例について説明する。
ステップS151において、デバイスドライバ202は、アプリケーション201よりRTTの計測が指令されたか否かを判定し、指令されたと判定されるまで待機する。インタフェースCを介してアプリケーション201からのRTT計測の指令があった場合(図4のTts)、処理は、ステップS152に進む。
ステップS152において、デバイスドライバ202は、図11を参照して後述するパケット送信処理を実行する。これによりRTTを計算するためのデータパケットが受信装置102に対して送信される。
ステップS152の処理の後、ステップS153において、デバイスドライバ202は、図12を参照して後述するパケット受信処理を実行する。これにより、ステップS152の処理により送信されたデータパケットに対応して、受信装置102が送信した確認応答パケットが受信される。
ステップS153の処理の後、ステップS154において、デバイスドライバ202は、図13を参照して後述するRTT算出処理を実行する。これによりステップS152の処理で送信されたデータパケットの送信時刻と、ステップS153の処理により受信された確認応答パケットの受信時刻に基づくRTTが計算され、計算結果がアプリケーション201に出力される。
次に、図11のフローチャートを参照して、図10のステップS152のパケット送信処理の詳細について説明する。
ステップS201において、コマンド制御部224は、パケット生成部225にRTTを計算するためのデータパケットの生成を指令する。
ステップS202において、パケット生成部225は、RTTを計算するためのデータパケットを生成する。いまの場合、宛先が受信装置102のアドレスであるICMP Echo Requestのパケットが生成される。また、生成されたデータパケットは、MACパケット送信部241で、MACアドレスが付与されて、タイムスタンプ付与部244に出力される。
ステップS203において、フロー情報保持部226は、フロー情報を登録(記憶)する。これにより、データパケットのフロー情報として、パケットの宛先アドレス、パケットの種類などの情報が記憶される。
ステップS204において、タイムスタンプ付与部244は、計時部245の出力値に基づいて現在時刻を取得して、タイムスタンプを付与する。このとき、データパケットの送信時刻(図4の時刻Txx)を表すタイムスタンプが生成され、タイムスタンプ通知部242に出力される。
ステップS205において、タイムスタンプ付与部244は、データパケットをネットワーク103に送出する。ここで、ネットワーク103に送出されたデータパケットは、受信装置102により受信され(図4の時刻Trr)、また、受信装置102は、受信したデータパケットに対応する確認応答パケットを、ネットワーク103を介して送信装置101に送信する(図4の時刻Trx)。
ステップS206において、タイムスタンプ通知部242は、ステップS204の処理により付与されたタイムスタンプを、タイムスタンプ保持部222に通知(出力)する。
ステップS207において、タイムスタンプ保持部222は、ステップS206の処理により通知されたタイムスタンプを保持(記憶)する。これにより、タイムスタンプ保持部222にデータパケットの送信時刻(図4の時刻Txx)を表すタイムスタンプが記憶される。
このようにしてデータパケットが送信される。
次に、図12のフローチャートを参照して、図10のステップS153のパケット受信処理の詳細について説明する。
ステップS221において、タイムスタンプ付与部244は、受信装置102により送信されたパケットをネットワーク103から取り出す(受信する)。これにより、当該パケットは、MACパケット受信部243を経て、フロー特定部227に出力される。
ステップS222において、タイムスタンプ付与部244は、計時部245の出力値に基づいて現在時刻を取得し、タイムスタンプを付与する。このとき、ステップS221の処理で受信されたパケットの受信時刻(図4の時刻Txrの候補となる時刻)を表すタイムスタンプが生成され、タイムスタンプ通知部242に出力される。
ステップS223において、タイムスタンプ通知部242は、ステップS222の処理により付与されたタイムスタンプを、タイムスタンプ保持部222に通知(出力)する。
ステップS224において、タイムスタンプ保持部222は、ステップS223の処理により通知されたタイムスタンプを保持(記憶)する。この時点では、まだフロー情報の判定が行われていないので、当該タイムスタンプは、確認応答パケットの受信時刻を表すタイムスタンプの候補としてタイムスタンプ保持部222に記憶される。
ステップS225において、フロー特定部227は、ステップS221の処理で受信されたパケットは、フロー情報が登録されているパケットか否かを判定する。このとき、フロー特定部227は、MACパケット受信部243から供給されるパケットの、例えば送信元アドレス、およびパケットの種類をチェックし、フロー情報保持部226に登録されているフロー情報と比較する。当該パケットの送信元アドレスが受信端末102のアドレスであり、かつ当該パケットの種類がICMP Echo Replyである場合、当該パケットは、フロー情報が登録されているパケットであると判定され、処理は、ステップS227に進む。
ステップS227において、フロー特定部227は、ステップS221の処理で受信したパケットを、RTTの計算のために送信されたデータパケットに対応する確認応答パケットとして、タイムスタンプ保持部222から当該パケットのタイムスタンプ(確認応答パケットの受信時刻:図4の時刻Txr)を取得し、そのタイムスタンプとともにRTT計測部228に出力し、確認応答パケットの受信を通知する。
一方、ステップS225において、当該パケットは、フロー情報が登録されているパケットではないと判定された場合、処理は、ステップS226に進み、タイムスタンプ保持部222は、当該パケットのタイムスタンプを廃棄する。また、この場合、当該パケット(ステップS221の処理で受信したパケット)は、RTTの計算のために送信されたデータパケットに対応する確認応答パケットではないので、パケット受信部223に出力され、インタフェースBを介してアプリケーション201にパケットのデータが供給されることになる。
このようにして確認応答パケットが受信される。
次に、図13のフローチャートを参照して、図10のステップS154のRTT算出処理の詳細について説明する。
ステップS251において、RTT計測部228は、データパケットの送信時刻(図4の時刻Txx)を表すタイムスタンプと、確認応答パケットの受信時刻(図4の時刻Txr)を表すタイムスタンプとを取得する。
ステップS252において、RTT計測部228は、ステップS251の処理で取得したタイムスタンプと、確認応答パケットの記述内容に基づいて、例えば式(2)によりRTTを計算する。
ステップS253において、RTT計測部228は、ステップS252の処理によるRTTの計算結果をコマンド制御部224に出力する。
ステップS254において、コマンド制御部224は、ステップS253の処理により出力されたRTTの計算結果を、アプリケーション201に供給し、RTTの計算が完了したことを表す情報をアプリケーション201に出力する。
このようにしてRTTが算出される。このようにすることで、送信装置101の内部での処理に要する時間である図4の時刻Ttsと時刻Txxの差分、および時刻Txrと時刻Tcの差分が含まれないようにして正確にRTTを計算することができる。
また、アプリケーション201とデバイスドライバ203との間で、RTTの計算に関する処理以外の通信に伴うデータの送受信に用いられるインタフェース(インタフェースAまたはB)と、RTTの計算に関する処理以外の通信に伴うデータの送受信に用いられるインタフェース(インタフェースC)とがそれぞれ設けられるようにしたので、ユーザは、従来の送信装置101にMAC203(ネットワークインタフェースカード)およびそれに対応するデバイスドライバ202を組み込むだけで、正確なRTTの計算ができるように対処することができる。
さらに、RTTの計算は、デバイスドライバ202により行われ、アプリケーション201は、デバイスドライバ202に対してRTTの計算の指令、および計算されたRTTの供給を受ける処理を行うだけでよいので、CPU、メモリなど送信装置101のリソースを有効に利用することができる。また、例えば、アプリケーション201に含まれる画像データの圧縮符号化などを行うプログラムにより、CPU、メモリなど送信装置101のリソースが多分に使用され、送信装置101の処理負荷が高い状態であっても、RTTの計算処理が遅延してしまうことはなく、その結果、より正確かつ適時にRTTを算出することが可能となる。
なお、以上においては、送信装置101によりRTTの計算が行われる例について説明したが、受信装置102も送信装置101と同様の構成とし、受信装置102によりRTTの計算が行われるようにすることも勿論可能である。また、このようにして計算されるRTTは、上述した送信レートの制御や、ARQ(Automatic Repeat Request)、FEC(Forward Error Collection)などのエラー訂正に関する処理を動的に変更する際の指標(参考値)として用いることができる。
ところで、本発明は、RTTの計算に限られるものではなく、上述したデータパケットの送信時刻(図4の時刻Txx)を表すタイムスタンプと、確認応答パケットの受信時刻(図4の時刻Txr)を表すタイムスタンプを用いることでより正確な伝送制御を行うことが可能となる。例えば、本発明をネットワークの輻輳を予測してデータ伝送のレート制御を行う通信システムに適用することも可能である。
図14は、別のデータ通信システムにおける、データ送信装置331およびデータ受信装置332の構成を示すブロック図である。
データ送信装置331およびデータ受信装置332は、リアルタイム・データ転送プロトコルであるRTP(Real-time Transport Protocol)にしたがって、データの授受を行う。RTPは、例えば、映像と音声データを利用して遠隔会議を行うアプリケーションなどで利用されることを想定し、映像や音声データをリアルタイムに適した形で転送することを目的に設計されている。RTPにおいては、データが時間単位でパケットに分割されて送信される。また、RTPは、パケットロス対策や伝送時間保証などは行われていないUDP(User Datagram Protocol)タイプのプロトコルで、通常は、RTCP(RTP Control Protocol)による通信状態レポートとセットで用いられる。
また、ネットワーク333は、例えば、組織内で運営されているLAN(Local Area Network)であってもよいし、いわゆるインターネットのような不特定多数のネットワークが結合した、大規模なネットワークであってもよいし、または、所定の送信装置と受信装置を接続する専用回線であっても良い。
データ送信装置331のデータ生成部341は、例えば、音声、画像、映像、テキストデータ、または、これらの混合したデータを生成し、データ送信部342に供給する。このとき生成されるデータ量は、送信レート制御部345によって制御される。
データ送信部342は、データ生成部341から供給されたデータをRTPパケットとして送信する場合、例えば、5秒間などの所定の時間ごとに、RTCPのSR(Sender Report)パケットを付加して、ネットワーク333を介して、データ受信装置332に送信する。SRパケットとは、データ送信側の送受信統計のためのレポートであり、データ伝送の状況を示す情報が記載されている。
SRパケットには、NTP(Network Time Protocol)タイムスタンプ、および、RTPタイムスタンプが含まれている。
データ受信部343は、データ受信装置332から送信される、RTCPにおけるRR(Receiver Report)パケットを受信する。RRパケットは、データ受信側からの受信統計のためのレポートである。
レート制御命令受信部344は、ネットワーク333を介して、データ受信装置332から、レート制御命令を受信し、送信レート制御部345に供給する。
送信レート制御部345は、レート制御命令受信部344から供給されたレート制御命令を基に、送信レート制御信号を生成し、データ生成部341に供給する。
データ受信装置332のデータ受信部351は、ネットワーク333を介して、データ送信装置331から、SRパケットおよびRTPパケットを受信し、RTPパケットの、例えば、映像、音声、テキストなどのデータを、データ処理部352に供給するとともに、RTPパケットの受信時刻、タイムスタンプ、パケットサイズ、シーケンス番号など、輻輳の予測に必要な情報を、輻輳予測部353に供給する。
データ処理部352は、データ受信部351から供給されたデータに対する処理を実行する。具体的には、データ処理部352は、供給されたデータに対して、例えば、復号処理、デスクランブル処理、表示処理、または、音声再生処理などを実行する。
データ送信部354は、データ送信装置331から送信されたRTPパケットに対して、RRパケットを生成し、ネットワーク333を介して、データ送信装置331に送信する。
輻輳予測部353は、データ受信部351から供給された情報を基に、データ伝送路の輻輳を予測し、その結果を基に、必要に応じて、データ受信レート(すなわち、データ受信装置332が受信するデータのデータ伝送レート)を設定して、レート制御命令を生成し、レート制御命令送信部355に供給する。
レート制御命令送信部355は、輻輳予測部353から供給されたレート制御命令を、RTCPのAPP(Application defined RTCP packet)として、ネットワーク333を介して、データ送信装置331に送信する。APPとは、アプリケーション拡張用のパケットである。
このようにレート制御が行われる通信システムにおいて、データ送信装置331またはデータ受信装置332に、例えば、上述したMAC(ネットワークインタフェースカード)203と、それに対応するデバイスドライバ202を実装し、データ送信装置331またはデータ受信装置332の内部の処理による伝送遅延を考慮して、RTPパケットのタイムスタンプを正確に取得できるようにすれば、より正確に輻輳を予測して適正なレート制御を行うことが可能となる。
あるいはまた、本発明を利用して、ネットワークの帯域の測定の精度を高めることも可能である。
例えば、サーバからクライアントに、インターネットを通じてリアルタイムに動画像データなどのストリーミングを行う場合、サーバからクライアント(ユーザ)までのネットワーク間において、最低の転送レートに合わせて転送しないと、ネットワークの容量を超えて転送することになり、パケットロスが生じてしまう。ここで、サーバからクライアントまでのネットワーク間における最低のリンクスピードをもつリンクを、ネットワークのボトルネックリンクと呼ぶ。
すなわち、サーバは、ストリーミングを行うにあたり、ボトルネックリンクのスピードを推定する必要があり、このボトルネックリンクのスピードの推定方法として、例えば、パケットペア(Packet Pair)と呼ばれる手法がある。
このパケットペア手法は、ボトルネックリンクの帯域予測方式の1つであり、例えば、図15に示されるように、送信側(サーバ)から受信側(クライアント)に対して、等しいパケットサイズの2つのパケット1,2を、送信間隔を空けずに、いわゆるバックツーバック(back-to-back)で転送し、ネットワークの伝送遅延により、ボトルネックリンクの帯域を測定するものである。
同図において、縦軸は時刻を示している。すなわち、時刻T1sは、パケット1の転送が終了するサーバ側の時刻を表し、時刻T1は、パケット1の受信を完了するクライアント側の時刻を表している。同様に、時刻T2sは、パケット2の転送が終了するサーバ側の時刻を表し、時刻T2は、パケット2の受信を完了するクライアント側の時刻を表している。
サーバから、一方が他方の直後に続くようなペアのパケット1,2を、ノード1,2を介してクライアントに転送すると、ノード1とノード2の間でパケットが時間軸方向に伸ばされる。このノード1とノード2の間がボトルネックリンクである。
クライアントは、1つ目のパケット1の到着時刻T1と2つ目のパケット2の到着時刻T2を測定することで、次式に従い、ボトルネックリンクの帯域Bを算出することができる。ここで、Sは、パケット1およびパケット2のサイズ(大きさ)を表している。
帯域B=S/(T2−T1)
このように帯域測定が行われる通信システムにおいて、クライアントに、例えば、上述したMAC(ネットワークインタフェースカード)203と、それに対応するデバイスドライバ202を実装して、クライアントの内部の処理による伝送遅延を考慮して、パケット1およびパケット2のタイムスタンプ(到着時刻)を正確に取得できるようにすれば、より正確な帯域測定を行うようにすることが可能となる。
以上においては、動画像のデータが送受信される例について説明したが、送受信されるデータは動画像のデータに限られるものではない。また、ネットワーク103は、インターネットなどの有線設備を伴うネットワークに限られるものではなく、例えば、Bluetoothなどの無線通信技術により実現されるネットワークであってもよい。
なお、上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、インターネットなどのネットワークや、リムーバブルメディア(例えば、図5のリムーバブルメディア161)などからなる記録媒体からインストールされる。
なお、この記録媒体は、装置本体とは別に、ユーザにプログラムを配信するために配布される、プログラムが記録されている磁気ディスク(フロッピディスク(登録商標)を含む)、光ディスク(CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む)、光磁気ディスク(MD(Mini-Disk)(登録商標)を含む)、もしくは半導体メモリなどよりなるリムーバブルメディア161により構成されるものだけでなく、装置本体に予め組み込まれた状態でユーザに配信される、プログラムが記録されているROMや、記憶部に含まれるハードディスクなどで構成されるものも含む。
本明細書において上述した一連の処理を実行するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
従来のRTTの計算方法の例を説明する図である。 図1の送信端末と受信端末において行われる処理の時刻を時系列に表した図である。 本発明を適用した通信システムの一実施形態に係る構成例を示す図である。 図1の送信装置と受信装置において行われる処理の時刻を時系列に表した図である。 図3の送信装置の内部構成例を示すブロック図である。 図5のCPUで実行されるソフトウェアの機能的構成例を示すブロック図である。 RTT計算処理を説明するフローチャートである。 RTT計算処理を説明するフローチャートである。 図5のCPUで実行されるソフトウェアの別の機能的構成例を示すブロック図である。 RTT計算処理の別の例を説明するフローチャートである。 パケット送信処理の例を説明するフローチャートである。 パケット受信処理の例を説明するフローチャートである。 RTT算出処理の例を説明するフローチャートである。 ネットワークの輻輳を予測して伝送レートの制御を行う通信システムの例を示すブロック図である。 パケットペア手法を説明するための図である。
符号の説明
100 通信システム, 101 送信装置, 102 受信装置, 103 ネットワーク, 151 CPU, 159 通信部, 161 リムーバブルメディア, 201 アプリケーション, 202 デバイスドライバ, 203 MAC, 221 パケット送信部, 222 タイムスタンプ保持部, 223 パケット受信部, 224 コマンド制御部, 225 パケット生成部, 226 フロー情報登録部, 227 フロー特定部, 228 RTT計測部, 242 タイムスタンプ通知部, 244 タイムスタンプ付与部

Claims (6)

  1. アプリケーション層のプログラムにより画像処理を実行するとともに、ネットワークを介して接続される他の情報処理装置と通信を行い、ネットワークインタフェースカードと、前記ネットワークインタフェースカードを制御するデバイスドライバ有する情報処理装置であって、
    アプリケーション層に設けられ、前記他の情報処理装置とのデータの送受信の実行、または伝送往復遅延の計算の実行を制御する実行制御手段と、
    前記デバイスドライバの一部として設けられ、前記伝送往復遅延の計算において前記他の情報処理装置からの応答を得るために前記他の情報処理装置に送信される第1のパケットを生成するパケット生成手段と、
    MAC層の前記ネットワークインタフェースカードの一部として設けられ、前記生成された前記第1のパケットを、前記ネットワークに送出するときの時刻を、前記第1のパケットの送信時刻として前記送信時刻を含む第1のタイムスタンプを生成する第1のタイムスタンプ生成手段と、
    MAC層の前記ネットワークインタフェースカードの一部として設けられ、前記第1のパケットに対する応答として前記他の情報処理装置から送信されるパケットであって、第2のパケットを前記ネットワークから取得するときの時刻を、前記第2のパケットの受信時刻として前記受信時刻を含む第2のタイムスタンプを生成する第2のタイムスタンプ生成手段と、
    前記デバイスドライバの一部として設けられ、前記第1および第2のタイムスタンプを取得する取得手段と、
    前記デバイスドライバの一部として設けられ、前記取得手段により取得された前記第1および第2のタイムスタンプに基づいて、自分と前記他の情報処理装置との間の伝送往復遅延を算出する算出手段と、
    前記デバイスドライバの一部として設けられ、前記算出された伝送往復遅延のデータを、前記他の情報処理装置とのデータの送受信の実行に関するデータの授受を行うインタフェースとは異なるインタフェースを介して前記アプリケーション層に通知する通知手段と
    を備えることを特徴とする情報処理装置。
  2. 前記第1のパケットの宛先アドレスおよびパケットの種類に関する情報を含むフロー情報を記憶するフロー情報記憶手段をさらに備える
    ことを特徴とする請求項1に記載の情報処理装置。
  3. 前記ネットワークから取得されるパケットの送信元アドレスおよびパケットの種類に関する情報と、前記フロー情報記憶手段に記憶されるフロー情報とを比較して、前記ネットワークから取得されるパケットが前記第2のパケットであるか否かを判定する判定手段をさらに備える
    ことを特徴とする請求項2に記載の情報処理装置。
  4. アプリケーション層のプログラムにより画像処理を実行するとともに、ネットワークを介して接続される他の情報処理装置と通信を行い、ネットワークインタフェースカードと、前記ネットワークインタフェースカードを制御するデバイスドライバ有する情報処理装置の情報処理方法であって、
    アプリケーション層に設けられた実行制御手段が、前記他の情報処理装置とのデータの送受信の実行、または伝送往復遅延の計算の実行を制御し、
    前記デバイスドライバの一部として設けられたパケット生成手段が、前記伝送往復遅延の計算において前記他の情報処理装置からの応答を得るために前記他の情報処理装置に送信される第1のパケットを生成し、
    MAC層の前記ネットワークインタフェースカードの一部として設けられた第1のタイムスタンプ生成手段が、前記生成された前記第1のパケットを、前記ネットワークに送出するときの時刻を、前記第1のパケットの送信時刻として前記送信時刻を含む第1のタイムスタンプを生成し、
    MAC層の前記ネットワークインタフェースカードの一部として設けられた第2のタイムスタンプ生成手段が、前記第1のパケットに対する応答として前記他の情報処理装置から送信されるパケットであって、第2のパケットを前記ネットワークから取得するときの時刻を、前記第2のパケットの受信時刻として前記受信時刻を含む第2のタイムスタンプを生成し、
    前記デバイスドライバの一部として設けられた取得手段が、前記第1および第2のタイムスタンプを取得し、
    前記デバイスドライバの一部として設けられた算出手段が、前記取得手段により取得された前記第1および第2のタイムスタンプに基づいて、自分と前記他の情報処理装置との間の伝送往復遅延を算出し、
    前記デバイスドライバの一部として設けられた通知手段が、前記算出された伝送往復遅延のデータを、前記他の情報処理装置とのデータの送受信の実行に関するデータの授受を行うインタフェースとは異なるインタフェースを介して前記アプリケーション層に通知するステップ
    を含むことを特徴とする情報処理方法。
  5. コンピュータを、
    アプリケーション層のプログラムにより画像処理を実行するとともに、ネットワークを介して接続される他の情報処理装置と通信を行い、ネットワークインタフェースカードと、前記ネットワークインタフェースカードを制御するデバイスドライバ有する情報処理装置であって、
    アプリケーション層に設けられ、前記他の情報処理装置とのデータの送受信の実行、または伝送往復遅延の計算の実行を制御する実行制御手段と、
    前記デバイスドライバの一部として設けられ、前記伝送往復遅延の計算において前記他の情報処理装置からの応答を得るために前記他の情報処理装置に送信される第1のパケットを生成するパケット生成手段と、
    MAC層の前記ネットワークインタフェースカードの一部として設けられ、前記生成された前記第1のパケットを、前記ネットワークに送出するときの時刻を、前記第1のパケットの送信時刻として前記送信時刻を含む第1のタイムスタンプを生成する第1のタイムスタンプ生成手段と、
    MAC層の前記ネットワークインタフェースカードの一部として設けられ、前記第1のパケットに対する応答として前記他の情報処理装置から送信されるパケットであって、第2のパケットを前記ネットワークから取得するときの時刻を、前記第2のパケットの受信時刻として前記受信時刻を含む第2のタイムスタンプを生成する第2のタイムスタンプ生成手段と、
    前記デバイスドライバの一部として設けられ、前記第1および第2のタイムスタンプを取得する取得手段と、
    前記デバイスドライバの一部として設けられ、前記取得手段により取得された前記第1および第2のタイムスタンプに基づいて、自分と前記他の情報処理装置との間の伝送往復遅延を算出する算出手段と、
    前記デバイスドライバの一部として設けられ、前記算出された伝送往復遅延のデータを、前記他の情報処理装置とのデータの送受信の実行に関するデータの授受を行うインタフェースとは異なるインタフェースを介して前記アプリケーション層に通知する通知手段とを備える情報処理装置として機能させる
    プログラム。
  6. 請求項5に記載のプログラムが記録されている記録媒体。
JP2005120550A 2005-04-19 2005-04-19 情報処理装置および方法、プログラム、並びに記録媒体 Expired - Fee Related JP4645281B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2005120550A JP4645281B2 (ja) 2005-04-19 2005-04-19 情報処理装置および方法、プログラム、並びに記録媒体
US11/400,286 US8441943B2 (en) 2005-04-19 2006-04-10 Information processing apparatus and method, program, and recording medium
CN2006100762335A CN1855935B (zh) 2005-04-19 2006-04-19 信息处理装置和方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005120550A JP4645281B2 (ja) 2005-04-19 2005-04-19 情報処理装置および方法、プログラム、並びに記録媒体

Publications (2)

Publication Number Publication Date
JP2006303750A JP2006303750A (ja) 2006-11-02
JP4645281B2 true JP4645281B2 (ja) 2011-03-09

Family

ID=37108362

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005120550A Expired - Fee Related JP4645281B2 (ja) 2005-04-19 2005-04-19 情報処理装置および方法、プログラム、並びに記録媒体

Country Status (3)

Country Link
US (1) US8441943B2 (ja)
JP (1) JP4645281B2 (ja)
CN (1) CN1855935B (ja)

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4645281B2 (ja) * 2005-04-19 2011-03-09 ソニー株式会社 情報処理装置および方法、プログラム、並びに記録媒体
JP2007012021A (ja) * 2005-06-01 2007-01-18 Sony Corp 情報処理装置および情報処理方法、並びにプログラム
JP2006338353A (ja) * 2005-06-02 2006-12-14 Sony Corp 情報処理装置および情報処理方法、並びにプログラム
US8340101B2 (en) 2006-09-25 2012-12-25 Futurewei Technologies, Inc. Multiplexed data stream payload format
US7675945B2 (en) * 2006-09-25 2010-03-09 Futurewei Technologies, Inc. Multi-component compatible data architecture
US8660152B2 (en) * 2006-09-25 2014-02-25 Futurewei Technologies, Inc. Multi-frame network clock synchronization
US8295310B2 (en) 2006-09-25 2012-10-23 Futurewei Technologies, Inc. Inter-packet gap network clock synchronization
US7986700B2 (en) 2006-09-25 2011-07-26 Futurewei Technologies, Inc. Multiplexed data stream circuit architecture
US7813271B2 (en) * 2006-09-25 2010-10-12 Futurewei Technologies, Inc. Aggregated link traffic protection
US8494009B2 (en) * 2006-09-25 2013-07-23 Futurewei Technologies, Inc. Network clock synchronization timestamp
US8976796B2 (en) 2006-09-25 2015-03-10 Futurewei Technologies, Inc. Bandwidth reuse in multiplexed data stream
US7961751B2 (en) * 2006-09-25 2011-06-14 Futurewei Technologies, Inc. Multiplexed data stream timeslot map
US8588209B2 (en) 2006-09-25 2013-11-19 Futurewei Technologies, Inc. Multi-network compatible data architecture
US7809027B2 (en) * 2006-09-25 2010-10-05 Futurewei Technologies, Inc. Network clock synchronization floating window and window delineation
JP2008192128A (ja) * 2007-01-11 2008-08-21 Sony Corp 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
US8645668B2 (en) 2007-01-11 2014-02-04 Sony Corporation Information processing apparatus, information processing method and computer program
JP2008172699A (ja) * 2007-01-15 2008-07-24 Fujitsu Ltd パケット処理方法、パケット処理システム、およびコンピュータプログラム
CN101578794B (zh) * 2007-01-26 2012-12-12 华为技术有限公司 数据通信装置及网络组件
CN101277179B (zh) * 2007-03-29 2012-08-08 华为技术有限公司 发送、接收通知消息的方法、装置及系统
KR101571145B1 (ko) * 2007-10-23 2015-11-23 톰슨 라이센싱 무선 근거리 네트워크들에서의 신뢰 가능한 멀티캐스트를 위해 병합된 자동 반복 요청으로 적응 순방향 에러 정정을 하기 위한 방법 및 장치
JP4826575B2 (ja) * 2007-11-16 2011-11-30 沖電気工業株式会社 遅延時間測定方法、パケット中継装置、遅延時間測定装置、及びプログラム
US8194756B2 (en) * 2008-05-28 2012-06-05 Broadcom Corporation Using program clock references to assist in transport of video stream to wireless device
JP5590825B2 (ja) * 2008-06-30 2014-09-17 キヤノン株式会社 通信装置及びラウンドトリップ時間を求める方法
JP2010211388A (ja) * 2009-03-09 2010-09-24 Canon Inc 検索装置及び検索方法
US20120057481A1 (en) * 2010-09-07 2012-03-08 Electronics And Telecommunications Research Institute System and method for measuring round trip time based on wireless local area network
US9531630B2 (en) * 2012-02-20 2016-12-27 Telefonaktiebolaget Lm Ericsson (Publ) Capacity estimates using burst-trailer trains
US8837316B2 (en) * 2012-06-14 2014-09-16 Qualcomm Incorporated RTT based ranging system and method
US9191908B2 (en) * 2013-03-05 2015-11-17 Qualcomm Incorporated Reducing impact of clock drift in wireless devices
JP6335430B2 (ja) 2013-03-21 2018-05-30 キヤノン株式会社 通信装置、通信装置の制御方法、プログラム
US20160013892A1 (en) * 2013-03-25 2016-01-14 Hidetoshi Suzuki Communication apparatus, reception apparatus, and transmission apparatus
CN104426641B (zh) * 2013-09-11 2019-01-11 松下知识产权经营株式会社 通信控制装置及通信控制方法
CN104469901B (zh) * 2013-09-17 2018-09-07 华为终端(东莞)有限公司 数据处理的方法及装置
US9614891B1 (en) * 2013-09-23 2017-04-04 Amazon Technologies, Inc. Assembling communications based on captured packets
CN104571986B (zh) * 2013-10-22 2018-07-06 精工爱普生株式会社 显示系统、显示装置以及显示方法
US20160301599A1 (en) * 2013-11-19 2016-10-13 Telefonaktiebolaget L M Ericsson (Publ) Method and first network node for managing a first ip path used by a connection
CN104767650A (zh) * 2014-01-03 2015-07-08 中国移动通信集团广东有限公司 一种消息网络延迟测算方法及装置
CN104320809A (zh) * 2014-11-05 2015-01-28 四川九洲电器集团有限责任公司 基于rtt的无线多跳网络拥塞控制方法及系统
WO2017193308A1 (zh) 2016-05-11 2017-11-16 广东欧珀移动通信有限公司 通信方法和通信设备
EP3479527B1 (en) * 2016-07-01 2022-09-07 Telefonaktiebolaget LM Ericsson (PUBL) Round trip time skew control methods and arrangements
WO2019021402A1 (ja) * 2017-07-26 2019-01-31 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 通信装置、通信方法および通信システム
WO2019093167A1 (ja) * 2017-11-10 2019-05-16 日本電気株式会社 制御装置、制御方法、及びプログラムが格納された非一時的なコンピュータ可読媒体
JP7119399B2 (ja) * 2018-02-06 2022-08-17 株式会社デンソー 半導体装置
US11290471B2 (en) * 2019-08-27 2022-03-29 Hewlett Packard Enterprise Development Lp Cross-attestation of electronic devices
CN111277785B (zh) * 2019-12-31 2021-04-20 杭州当虹科技股份有限公司 一种端到端延时测量方法
EP3907943B1 (en) * 2020-05-05 2022-04-27 Axis AB Round-trip estimation
CN113422704A (zh) * 2021-02-05 2021-09-21 阿里巴巴集团控股有限公司 数据测量方法、装置、电子设备及计算机存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0779250A (ja) * 1993-09-07 1995-03-20 Fujitsu Ltd パケット通信の遅延制御システム
JP2002141933A (ja) * 2000-11-02 2002-05-17 Yokogawa Electric Corp ネットワーク品質評価装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU3188800A (en) * 1999-03-15 2000-10-04 Vocaltec Communications Ltd. Flow control method and apparatus
JP3323483B2 (ja) * 2000-09-12 2002-09-09 松下電器産業株式会社 パケット送信装置およびパケット伝送方法
US7327676B2 (en) * 2001-10-11 2008-02-05 Nippon Telegraph And Telephone Corporation Data transmission control method, program therefor and data transmission unit using the same
JP3757857B2 (ja) 2001-12-12 2006-03-22 ソニー株式会社 データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム
JP3769752B2 (ja) * 2002-12-24 2006-04-26 ソニー株式会社 情報処理装置および情報処理方法、データ通信システム、並びに、プログラム
JP4645281B2 (ja) * 2005-04-19 2011-03-09 ソニー株式会社 情報処理装置および方法、プログラム、並びに記録媒体

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0779250A (ja) * 1993-09-07 1995-03-20 Fujitsu Ltd パケット通信の遅延制御システム
JP2002141933A (ja) * 2000-11-02 2002-05-17 Yokogawa Electric Corp ネットワーク品質評価装置

Also Published As

Publication number Publication date
JP2006303750A (ja) 2006-11-02
CN1855935B (zh) 2011-12-07
CN1855935A (zh) 2006-11-01
US8441943B2 (en) 2013-05-14
US20060233116A1 (en) 2006-10-19

Similar Documents

Publication Publication Date Title
JP4645281B2 (ja) 情報処理装置および方法、プログラム、並びに記録媒体
US11843535B2 (en) Key performance indicators (KPI) for tracking and correcting problems for a network-under-test
JP4491257B2 (ja) 終端間測定に基づくネットワークへのデータストリームの許容の制御
US7817568B2 (en) Method for measuring characteristics of path between nodes by using active testing packets based on priority
JP4348124B2 (ja) QoSを推定する方法および通信装置
JP2004254258A (ja) 情報処理装置および情報処理方法、データ通信システム、並びに、プログラム
KR20040111669A (ko) 프로토콜, 정보 처리 시스템 및 방법, 정보 처리 장치 및방법, 기록 매체, 및 프로그램
JP2015500609A (ja) ネットワーク内の送信特性を監視するための方法および装置
JP2008278207A (ja) 可用帯域幅推定システム、ストリームデータ配信システム、方法、及び、プログラム
JP2009194540A (ja) 品質計測システム、送信装置、受信装置、品質計測方法及びプログラム
WO2018161303A1 (zh) 无线质量支持视频体验的检测方法及装置
US9184928B2 (en) Communications terminal, communications method, and program and integrated circuit for controlling a reproduction delay time in distributing a stream
JP5625940B2 (ja) 監視プログラム、監視装置、及び監視方法
US20050102391A1 (en) Method and apparatus providing an asymmetric ping procedure
JP2004135065A (ja) 送信端末、受信端末及びデータ伝送システム
US20210218686A1 (en) Methods and apparatus to facilitate data transmission
JP2009105662A (ja) マルチホップ通信システム、マルチホップ通信方法、端末装置および中継装置
US7643503B2 (en) System and method for dynamically determining retransmit buffer time
JP2004312725A (ja) サービスの品質を決定する方法および装置
JP5029763B2 (ja) ネットワーク障害時情報収集装置、方法、及びプログラム
KR101627796B1 (ko) 네트워크 기반 av 시스템에서 디바이스 상태 정보 전송 방법
Rico et al. Performance analysis of the multi-connection tactile internet protocol over 5G
WO2022006725A1 (zh) 一种通信方法及装置
CN114285791B (zh) 数据传输方法、装置、计算机设备及存储介质
JP4766703B2 (ja) エッジノードおよび帯域制御方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080220

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100212

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100304

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100506

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100708

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101005

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20101015

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: 20101109

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: 20101122

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

Free format text: PAYMENT UNTIL: 20131217

Year of fee payment: 3

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

Free format text: PAYMENT UNTIL: 20131217

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees