JP5094593B2 - 送信装置、受信装置、及び方法、プログラム - Google Patents

送信装置、受信装置、及び方法、プログラム Download PDF

Info

Publication number
JP5094593B2
JP5094593B2 JP2008169329A JP2008169329A JP5094593B2 JP 5094593 B2 JP5094593 B2 JP 5094593B2 JP 2008169329 A JP2008169329 A JP 2008169329A JP 2008169329 A JP2008169329 A JP 2008169329A JP 5094593 B2 JP5094593 B2 JP 5094593B2
Authority
JP
Japan
Prior art keywords
packet
packets
group
error
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.)
Active
Application number
JP2008169329A
Other languages
English (en)
Other versions
JP2010011212A (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.)
Canon Inc
Original Assignee
Canon Inc
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 Canon Inc filed Critical Canon Inc
Priority to JP2008169329A priority Critical patent/JP5094593B2/ja
Priority to US12/492,075 priority patent/US8566662B2/en
Priority to CN2009101506927A priority patent/CN101616185B/zh
Publication of JP2010011212A publication Critical patent/JP2010011212A/ja
Application granted granted Critical
Publication of JP5094593B2 publication Critical patent/JP5094593B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0009Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the channel coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • H04L1/1835Buffer management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/11Identifying congestion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416Real-time traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/25Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • 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
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0002Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission rate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0078Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H04L1/0079Formats for control data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • 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/40Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Description

本発明は、有線あるいは無線のネットワークにおける通信技術に関する。
近年、通信システムの発達により、比較的大きなデータ通信帯域が必要となるデータ、例えば、動画像データをインターネットなどの通信回線を介して送受信することが一般に行なわれている。
このようなデータの送信において、特にリアルタイム性を要する動画像データを送信する場合において、通信エラーの補償がないプロトコルが用いられることがある。通信エラーの補償がないプロトコルとは、例えば、RTP(A Transport Protocol for Real−Time Applications)である。
このような通信エラーの補償がないプロトコルで音声や動画像データを送信する際には、以下のようなQoS(Quality of Service)の技術によって、通信エラーの回避、修正を図ることが一般に行われる。即ち、ネットワークの状況に合わせた適応的な送信レートの制御(レート制御)、通信エラーが発生したパケットの再送制御、FEC(Forward Error Correction:前方誤り訂正)による、通信エラーが発生したパケットの修正などである。
ここで、パケット棄却率とRTT(Round Trip Time)の変動率などに応じてQoSを制御する方法が知られている(例えば特許文献1)。特許文献1では、パケットロス率が閾値よりも高く、さらにRTTが、予め記憶された最小往復遅延時間に対して高い場合、データの転送レートを下げている。
また、パケット棄却率とRTTをレート制御に用いる手法の例として、例えば、非特許文献1がある。
非特許文献1のTFRC(TCP Friendly Rate Control)では、図10に示す方程式により、ネットワークの使用可能帯域を算出している。
図10の方程式において、Ttcpは算出するネットワーク使用可能帯域、MTU(Maximum Transfer Unit)は送出パケットの最大サイズである。また、Toは、TCPの受信確認(Ack)が返ってくるまでの最大待ち時間となるタイムアウト時間、pは、1RTT内のパケット棄却率を示している。すなわち、この方程式により、パケット棄却率とRTTに応じて使用可能帯域を算出し、通信レートの制御を行っている。
特開2001−160824号公報 M.Handley et al.,"TCP Friendly Rate Control (TFRC):Protocol Specification"RFC 3448,January.2003
しかしながら、従来の方法では、通信エラーが発生する原因によっては、適切なQoSの制御ができない恐れがあった。
即ち、例えば、通信エラーが発生する原因は、輻輳だけでなく、例えば、ノイズ(外乱)が原因である場合もある。また、RTTの変動も、例えば、受信装置による負荷の変動やネットワーク上のルートの変更など、輻輳以外の原因で発生することがある。
さらに、複数の通信ノードを経由してデータの送信を行う場合、例えば、通信エラーを発生させている通信ノードと、遅延を発生させている通信ノードが異なる場合もある。
つまり、RTTやパケット棄却率からでは、ネットワーク上で発生する通信エラーの原因を特定することができない場合があった。そして、例えば、RTTやパケット棄却率に応じて転送レートを下げても、通信エラーの原因がノイズである場合などは、パケット棄却率を下げることができないことがあった。また、例えば、例えば、RTTやパケット棄却率に応じてFECパケットを増加させても、通信エラーの原因が輻輳である場合などは、却って通信量が増えてしまい、パケット棄却率を下げることができないことがあった。
つまり、通信相手から取得したRTTやパケット棄却率に応じて、QoSの制御を行っても、その制御が必ずしも適切なQoSの制御であるとは限らなかった。
本発明は上記の問題に鑑みてなされたものであり、その目的は、ネットワーク上で発生している通信エラーの原因を特定できるようにすることである。
また、本発明の目的は、通信エラーが発生する原因に応じて、適切なQoSの制御を行えるようにすることである。
本発明の課題を解決するために、例えば本発明の送信装置は以下の手段を備える。すなわち、複数のパケットを、順次、通信相手に送信する送信装置であって、あるグループのパケットを送信してから次のグループのパケットを送信するまでの間に待機期間を設ける送信制御手段と、通信相手から、パケットの受信状況を示す受信情報を受信する受信手段と、パケットを送信するグループ内における、エラーが発生したパケットの位置を、受信情報から特定し、当該エラーが発生したパケットの位置に基づいて、グループ内におけるパケット数、及び、通信相手が受信したパケットのエラー修正に利用できるように当該通信相手に送信するデータのデータ数のうち、少なくともいずれかを設定する設定手段とを有する。
また、本発明の送信装置は、複数のパケットを、順次、通信相手にネットワークを介して送信する送信装置であって、あるグループのパケットを送信してから次のグループのパケットを送信するまでの間に待機期間を設ける送信制御手段と、通信相手から、パケットの受信状況を示す受信情報を受信する受信手段と、パケットを送信するグループ内における、エラーが発生したパケットの位置を、受信情報から特定し、当該エラーが発生したパケットの位置が、連続して送信する複数のグループ内の対応する位置であるか否かに応じて、ネットワークの状態を判断する判断手段とを有する。
また、本発明の受信装置は、複数のグループに分けられて送信され、かつ、グループ間に送信待機時間を設けて送信される複数のパケットを受信する受信装置であって、受信されたパケットに含まれる、当該パケットのグループ内の位置を識別可能な識別情報を取得する取得手段と、取得された識別情報により、送信装置から送信されたパケットのうちネットワーク上でエラーとなったパケットの、グループ内における位置を特定し、当該特定されたグループ内における位置が、連続して送信する複数のグループ内の対応する位置であるか否かに基づいて、ネットワークの状態を判断する判断手段と、判断されたネットワークの状態を前記送信装置へ通知する通知手段とを有する。
また、本発明の送信方法は、複数のパケットを、順次、通信相手に送信する送信装置が行う送信方法であって、あるグループのパケットを送信してから次のグループのパケットを送信するまでの間に待機期間を設ける送信制御工程と、通信相手から、パケットの受信状況を示す受信情報を受信する受信工程と、パケットを送信するグループ内における、エラーが発生したパケットの位置を、受信情報から特定し、当該エラーが発生したパケットの位置に基づいて、グループ内におけるパケット数、及び、通信相手が受信したパケットのエラー修正に利用できるように当該通信相手に送信するデータのデータ数のうち、少なくともいずれかを設定する設定工程とを有する。
また、本発明の送信方法は、複数のパケットを、順次、通信相手にネットワークを介して送信する送信装置が行う送信方法であって、あるグループのパケットを送信してから次のグループのパケットを送信するまでの間に待機期間を設ける送信制御工程と、通信相手から、パケットの受信状況を示す受信情報を受信する受信工程と、パケットを送信するグループ内における、エラーが発生したパケットの位置を、受信情報から特定し、当該エラーが発生したパケットの位置が、連続して送信する複数のグループ内の対応する位置であるか否かに応じて、ネットワークの状態を判断する判断工程とを有する。
また、本発明の処理方法は、複数のグループに分けられて送信され、かつ、グループ間に送信待機時間を設けて送信される複数のパケットを受信する受信装置が行う処理方法であって、受信されたパケットに含まれる、当該パケットのグループ内の位置を識別可能な識別情報を取得する取得工程と、取得された識別情報により、送信装置から送信されたパケットのうちネットワーク上でエラーとなったパケットの、グループ内における位置を特定し、当該特定されたグループ内における位置が、連続して送信する複数のグループ内の対応する位置であるか否かに基づいて、ネットワークの状態を判断する判断工程と、判断されたネッワークの状態を送信装置へ通知する通知工程とを有する。
本発明によれば、ネットワーク上で発生している通信エラーの原因を特定できる。
また、本発明によれば、通信エラーが発生する原因に応じて、適切なQoSの制御を行うことができる。
<実施形態1>
図1は、本発明の実施に好適な送信装置の基本構成を示すブロック図である。この送信装置100は、パーソナルコンピュータ、ワークステーション、ノートブックPC、パームトップPC、コンピュータを内蔵した各種家電製品、ゲーム機、携帯電話、デジタルビデオカメラ、デジタルカメラなどのうち、複数のパケットを、順次、通信相手(受信装置)に送信することができる装置、もしくは、これらの組合せにより実現可能である。
図1に示すように、送信装置100は、符号化部101、パケット生成部102、誤り訂正符号化部103、送信バッファ104、送信制御部105、送信位置情報記憶部106、送受信部107、再送制御部108、エラーパターン解析部109、QoS制御部110、レート制御部111から構成されている。
符号化部101は、動画像や音声データを、レート制御部111から指示された符号化レートに基づいて、例えばMPEG(Moving Picture Experts Group)−4方式により符号化することでデータ量を圧縮する。動画像データの圧縮方法としては、MPEG−4に限らずMPEG−2やH.264(MPEG−4 AVC)などの符号化方式を用いても良い。
パケット生成部102では、例えばRTPプロトコルを用いて通信する場合、符号化部101により符号化されたデータを、通信に適したサイズに分割し、更に通信するために必要なヘッダを付加してRTPのデータパケットを生成する。
誤り訂正符号化部103では、後述するQoS制御部110から指示される冗長度に従って、パケット生成部102にて生成されたデータパケットから、誤り訂正用のパケット(以下、FECパケットと呼ぶ)を生成する。つまり、FECパケットは、通信相手(受信装置)が、受信したパケットのエラー修正に利用できるように通信相手に送信するデータであり、冗長度は、データパケット数に対するFECパケット数を示すものである。
パケット生成部102で生成されたデータパケット、および、誤り訂正符号化部103で生成されたFECパケットは、送信バッファ104に一時保管される。
送信バッファ104に一時保管されたデータパケットおよびFECパケットは、送信制御部105によって決定された送信順序および送信時刻に応じて、送受信部107から、伝送路112へ送信される。
ここで、伝送路112は各種ネットワークに代表される伝送路であり、本実施形態においては、パケット化した動画像および音声データ、誤り訂正用データ等を送信するネットワークである。
送信制御部105は、QoS制御部110からの指示によってパケットの送信順序、及び送信時刻を決定し、更に、送信パケットの情報を、送信位置情報記憶部106に記憶させる。このパケットの情報については、後述する。また、送信制御部105は、後述する再送制御部108からの再送指示に基づいて、再送するパケットの送信順序、及び送信時刻を決定する。また、本実施形態の送信制御部105は、図5のパケット送信の様子507に示すように、複数のパケットを連続して送信させる。また、送信制御部105は、連続して送信されるパケット群(グループ)の間に間隔をあける。
即ち、送信制御部105は、あるグループのパケットを送信してから次のグループのパケットを送信するまでの間に待機期間を設ける。
送受信部107は、送信バッファ104に記憶されるパケットの送信、及び伝送路112からのパケットを受信する機能を備えている。受信されるパケットには、例えば、受信装置におけるパケットの受信状況を送信装置100に通知するためのパケット(受信情報パケット)がある。
即ち、送受信部107は、通信相手(受信装置)から、パケットの受信状況を示す受信情報(受信情報パケット)を受信する。
送受信部107は、受信情報パケットを受信すると、受信情報をエラーパターン解析部109に通知する。
また、送受信部107が受信するパケットには、例えば、通信経路で棄却されたパケット及びビットエラーとなったパケット(棄却パケット)の再送要求をするためのパケット(再送要求パケット)がある。送受信部107は、再送要求パケットを受信すると、その内容を再送制御部108に通知する。
再送制御部108は、送受信部107から受け取った再送要求に関する情報に応じて、送信制御部105に対してパケットの再送を指示する。
エラーパターン解析部109は、送受信部107から通知される受信情報と、送信位置情報記憶部106に記憶されているパケットの送信位置情報とから、連続送信されたパケット群(グループ)内における棄却パケットの位置を特定する。そして、エラーパターン解析部109は、特定された棄却パケットの位置に応じて、通信エラーのパターンを解析する。なお、受信情報には、棄却パケットの識別情報(シーケンスナンバー)が含まれている。
即ち、エラーパターン解析部109は、パケットを送信するグループ内における、エラーが発生したパケット(棄却パケット)の位置を、受信情報から特定する。
そして、エラーパターン解析部109は、エラーパターンの解析結果を、QoS制御部110に通知する。エラーパターンの解析処理の詳細については、後述する。
QoS制御部110では、エラーパターンの解析結果に応じて、誤り訂正符号化部103に対する冗長度の設定、送信制御部105に対するグループ内のパケット数や各グループの送信間隔の設定、レート制御部111に対する符号化レートの設定などを行なう。QoS制御部110は、各グループで送信するデータパケットの数を、符号化レートとしてレート制御部111に対して設定する。
即ち、QoS制御部110は、エラーが発生したパケットの位置に基づいて、以下のような設定を行う。すなわち、QoS制御部110は、グループ内におけるパケット数、及び、通信相手(受信装置)が受信したパケットのエラー修正に利用できるように通信相手に送信するデータのデータ数のうち、少なくともいずれかを設定する。
ところで、本実施形態の送受信部107から送信するRTPパケットのヘッダ(RTPヘッダ)には、パケット毎に連番で増加する番号が付加される。
図11は、RFC1889で定義されたRTPヘッダのフォーマットである。同図において、『Sequence number』(シーケンスナンバー)1102が前述のパケット毎に連番で増加する番号の例である。このシーケンスナンバー1102は、16ビットの幅を持ち、受信装置は受信したパケットのシーケンスナンバーに抜けが無いか監視することで、通信経路でのパケットの棄却の有無を知ることができる。
次に、エラーパターン解析部109におけるエラーパターンの解析処理の内容について説明する。まず、エラーパターン解析部109が送受信部107から通知される、受信情報について具体的に説明する。
図4に示す受信情報は、受信装置から送信装置100へ通知される受信情報パケットに含まれ、さらに、送受信部107からエラーパターン解析部109に通知される情報の例である。
図4のパケット棄却率401は、送信したパケットのうち、通信経路で棄却されたパケット及びビットエラーとなったパケット(棄却パケット)の割合を示し、RTT402は、送信装置100と受信装置との間でパケットが往復するのにかかった時間を示す。なお、RTT402として、例えば、送信装置100から送信されたパケットが受信装置に到着するまでにかかった時間、及び、受信情報パケットの送信時刻の情報が含まれる情報であっても良い。この場合、受信情報パケットを受信した送信装置100が、上記2つの情報、及び、受信情報パケットの受信時刻により、送信装置100と受信装置との間でパケットが往復するのにかかった時間を算出することができる。
また、棄却パケットのシーケンスナンバー403は、通信経路で棄却されたパケット及びビットエラーとなったパケット(棄却パケット)のシーケンスナンバーである。このシーケンスナンバー403は、図11を用いて説明したRTPヘッダに含まれるシーケンスナンバー1102に対応するナンバーである。つまり、エラーパターン解析部109は、棄却パケットのシーケンスナンバー403を参照することにより、通信経路で棄却されたパケット、及びビットエラーとなったパケットを特定することができる。また、受信データレート404は、受信装置で正常に受信できたパケットのビットレートを示す。
本実施形態のエラーパターン解析部109は、通信エラーのパターンを解析するために、図4に示す情報のうち、特に棄却パケットのシーケンスナンバー403を使用する。
次に、送信位置情報記憶部106に記憶された、パケットの送信位置情報の例について、図5を用いて説明する。
図5において、パケット送信の様子507は、パケット化された、動画の各フレームデータが、フレーム毎に連続送信される様子を示している。本形態では、送信パケットをフレームごとにグループ化して送信する。尚、本実施形態では、連続送信されるパケット群(グループ)は、フレーム毎としているが、これに限らず、スライス毎、複数フレーム毎など、任意の単位で連続送信するようにしても良い。また、あるグループにおいて最後に送信されるパケットから、次に送信されるグループにおいて最初に送信されるパケットまでの送信間隔は、グループ内におけるパケットの送信間隔よりも長い。
先頭シーケンスナンバー501は、パケット送信の様子507において、連続送信したパケット505の先頭に位置する先頭パケット504のRTPヘッダに記録されたシーケンスナンバーを示す。つまり、先頭シーケンスナンバー501は、グループ内において最初に送信されるパケットのシーケンスナンバーを示している。連続送信パケット数502は、連続送信したパケット505のパケット数を示す。つまり、連続送信パケット数502は、グループ内のパケット数を示している。
フレーム識別フラグ503は、パケット化されたフレームの符号化方式の違いを示すフレーム種別506を識別可能なフラグを示す。フレーム種別506には、例えば、Iフレーム(Intra frame)、Pフレーム(Predictive frame)、Bフレーム(Bidirectionally predictive frame)などがある。本実施形態のエラーパターン解析部109は、通信エラーのパターンを解析するために、図5に示す情報のうち、特に先頭シーケンスナンバー501と、連続送信パケット数502を使用する。
つまり、本実施形態におけるエラーパターン解析部109は、通信エラーのパターンを解析するために、以下の情報を参照する。すなわち、受信情報パケットから取得される棄却パケットのシーケンスナンバー403と、送信位置情報記憶部106に記憶されている先頭シーケンスナンバー501と、連続送信パケット数502である。送信位置情報記憶部106には、各グループ(各フレーム)の、先頭のパケットのシーケンスナンバー番号403、送信パケット数502が記憶されている。
ところで、インターネットなどの通信回線を介してデータ通信を行う場合にパケットが棄却する原因は様々だが、代表的な原因の1つにネットワーク帯域の輻輳がある。
このネットワーク帯域の輻輳によって、ネットワークを構成するハブやルータなどの通信機器において、比較的短い一定時間内に通過しようとするパケットの数が多くなると、パケットを処理するバッファが足りなくなり、その結果、パケットの棄却が発生する。
次に、エラーパターン解析部109による、通信エラーのパターン解析処理の内容について、図2及び図3を用いて説明する。
図2及び図3において、□は受信装置にて正常に受信したパケット、■は通信経路で棄却、或いはビットエラーとなったパケット(棄却パケット)を示している。エラーパターン解析部109は、正常に受信したパケットや、棄却パケットの時間軸上の送信位置を、棄却パケットのシーケンスナンバー403と、先頭シーケンスナンバー501と、連続送信パケット数502から特定することができる。つまり,エラーパターン解析部109は、棄却パケットの、グループ内における位置を特定することができる。尚、本実施形態において、グループとは、上述のように、連続送信されるパケット群を示すものである。
エラーパターン解析部109は、例えば、ある棄却パケットの、グループ内における位置を特定する場合、受信情報に含まれる棄却パケットのシーケンスナンバー403を参照する。そして、棄却パケットのシーケンスナンバー403に対応するシーケンスナンバーのパケットが含まれるグループを検索する。上述の通り、送信位置情報記憶部106には、これまでに送信されたパケットの先頭シーケンスナンバー501、連続送信パケット数502が記憶されている。このようにして、エラーパターン解析部109は、位置を特定したい棄却パケットが送信されたグループを特定することができる。そして、エラーパターン解析部109は、特定されたグループの先頭シーケンスナンバーと、棄却パケットのシーケンスナンバー403との差と、連続送信パケット数502とに基づいて、棄却パケットのグループ内における位置を特定することができる。ただし、エラーパターン解析部109による棄却パケットのグループ内における位置の特定方法は、これに限らない。
図2は、棄却パケットのグループ内における位置を示した図である。図2は、例えば動画のデータをパケット化したものをフレーム毎に連続送信した場合の例を示している。上述のように、各グループにおいて送信するパケットの数は、例えばフレームの種別によって異なる。
同図において、輻輳パターン1(201)は、連続して送信された各グループにおいて、最後のパケットを含む1つ以上の連続したパケットが棄却されるパターンを示している。
エラーパターン解析部109は、このエラーパターンが、所定の時間内に(または所定数のグループにおいて)所定の回数以上発生した場合に、輻輳(パターン1)によるパケット棄却が発生したと判断する。また、エラーパターン解析部109は、このエラーパターンが、連続する所定数以上の複数のグループにおいて発生した場合、輻輳(パターン1)によるパケット棄却が発生したと判断する。
即ち、エラーパターン解析部109は、連続して送信する複数のグループのそれぞれで、最後に送信するパケットがエラーになった場合、輻輳(パターン1)が発生していると判断する。
次に輻輳パターン2(202)は、各グループのパケットを、先頭から一定数正常に受信した後、一定数のパケットが棄却されるパターンを示している。このパターン2(202)において、正常受信或いは棄却されるパケットの一定数とは、ある程度のばらつきを含むものである。また、受信パケットと棄却パケットの数の相関は問わない。
エラーパターン解析部109は、このエラーパターンが、所定の時間内に(または所定数のグループにおいて)所定の回数以上発生した場合に、輻輳(パターン2)によるパケット棄却が発生したと判断する。また、エラーパターン解析部109は、このエラーパターンが、連続する所定数以上の複数のグループにおいて発生した場合、輻輳(パターン2)によるパケット棄却が発生したと判断する。即ち、エラーパターン解析部109は、連続して送信する複数のグループのそれぞれで、最初に送信するパケットから所定パケット数あとに送信されるパケットがエラーになった場合、輻輳(パターン2)が発生していると判断する。
次に輻輳パターン3(203)は、グループ内のパケットが全て棄却されるパターンを示している。エラーパターン解析部109は、このエラーパターンが、所定の時間内に(または所定数のグループにおいて)所定の回数以上発生した場合に、輻輳(パターン3)によるパケット棄却が発生したと判断する。また、エラーパターン解析部109は、このエラーパターンが、連続する所定数以上の複数のグループにおいて発生した場合、輻輳(パターン3)によるパケット棄却が発生したと判断する。尚、本実施形態の輻輳パターン3は、グループ内のパケットがすべて棄却される場合を示したが、グループ内のパケットのうち、所定割合以上のパケットが棄却された場合に、輻輳パターン3であるとエラーパターン解析部109が判断するようにしても良い。即ち、エラーパターン解析部109は、連続して送信する複数のグループのそれぞれで、グループ内のパケットのうち所定割合以上のパケットがエラーになった場合、輻輳(パターン3)が発生していると判断する。
以上のように、本実施形態のエラーパターン解析部109は、輻輳パターン1〜輻輳パターン3のようなパケット棄却が発生している場合、輻輳によるパケット棄却が発生していると判断する。
即ち、エラーパターン解析部109は、連続して送信する複数のグループ内の対応する位置でエラーが発生する場合、輻輳が発生していると判断する。
尚、本実施形態において、エラーパターン解析部109が輻輳を検知するパケットのエラーパターンは3つあるが、その中で、輻輳パターン1(201)は、比較的軽い輻輳状態の時に発生するエラーパターンである。一方、輻輳パターン2(202)及び輻輳パターン3(203)は比較的重い輻輳状態の時に発生するエラーパターンである。
尚、輻輳パターンの種類に応じて、それぞれ異なる基準でその輻輳パターンの発生を判断するようにしても良い。即ち、例えば、輻輳パターン1は、一般に、輻輳パターン2と比較して軽い輻輳状態であるため、複数の連続するグループのすべてにおいて、必ずしもパケット棄却が起きるとは限らない。つまり、輻輳パターン1の場合は、連続する複数のグループのうち、いくつかのグループでは、エラーが発生しない可能性がある。一方、輻輳パターン2は、一般に、輻輳パターン1と比較して重い輻輳状態であり、パケット棄却が発生する位置に多少のばらつきはあるとしても、複数の連続するグループにおいてパケット棄却が発生する可能性が高い。従って、例えば、輻輳パターン1の判断は、最後のパケットを含む1つ以上の連続したパケットが棄却されるパターンが所定の時間内に(または所定数のグループにおいて)所定の回数以上発生したか否かによって行う。一方、輻輳パターン2の判断は、各グループのパケットを、先頭から一定数正常に受信した後、一定数のパケットが棄却されるパターンが連続する所定回数以上発生したか否かによって行う。このように、輻輳パターンの種類に応じて、それぞれの輻輳パターンが発生していると判断する基準を設定するようにしても良い。
また、さらに、輻輳パターン1の発生を判断するために参照するグループの数と輻輳パターン2の発生を判断するために参照するグループの数を、輻輳パターンの種類や、その輻輳パターンが発生していると判断する基準に応じて設定するようにしても良い。例えば、輻輳パターン1が発生していると判断する基準が、所定の時間内に(または所定数のグループにおいて)所定の回数以上発生したか否かによって行う場合、比較的多くのグループを参照する。一方、輻輳パターン2が発生していると判断する基準が、連続するすべてのグループで所定の条件を満たすパケット棄却が発生しているとする場合、輻輳パターン1と比較して少ないグループを参照して判断するようにしても良い。このようにすれば、より効率良くエラーパターンの解析を行うことができる。
また、上述のように、本実施形態では、グループ内のパケット数はフレームの種別によって変化する。つまり、例えば、Iフレームのグループは、グループ内のパケット数が多く、BフレームやPフレームのグループ内のパケット数は、比較的少ない。従って、Iフレームのグループでは、グループの後ろのほうでパケット棄却が発生するが、Bフレームのグループは、連続送信されるパケット数が少ないため、そのようなパケット棄却が発生しない可能性がある。そこで、エラーパターン解析部109は、例えば、Iフレームのグループのみで棄却パケットの位置を特定し、その結果に応じて、パケット棄却のパターンを判断するようにしても良い。つまり、エラーパターン解析部109は、例えば、所定数のIフレームのグループのうち、上記のようなエラーパターン(輻輳パターン1〜輻輳パターン3)が所定の回数以上発生した場合に、輻輳によるパケット棄却が発生したと判断しても良い。また、エラーパターン解析部109は、このエラーパターンが、連続する所定数以上のIフレームのグループにおいて発生した場合、輻輳によるパケット棄却が発生したと判断しても良い。
即ち、エラーパターン解析部109は、グループ内のパケット数がグループによって異なる場合、グループ内のパケット数が所定数以上の複数のグループ内の対応する位置でエラーが発生する場合に、輻輳が発生していると判断しても良い。
このようにすれば、グループによってパケット数が異なる場合であっても、より高い精度で輻輳の検知を行うことができる。
また、本実施形態のエラーパターン解析部109は、棄却パケットのグループ内における位置を特定し、エラーパターンを判断している。このとき、エラーパターン解析部109は、グループ内における位置を特定するために、棄却パケットのシーケンスナンバー、送信位置情報記憶部106に記憶されている先頭シーケンスナンバー501、連続送信パケット数502を参照している。
しかし、エラーパターン解析部109は、棄却パケットのグループ内の位置の代わりに、グループの先頭のパケットから棄却パケットまでのパケット数を特定するようにしても良い。すなわち、エラーパターン解析部109は、グループの先頭のパケットから棄却パケットまでのパケット数を、棄却パケットのシーケンスナンバーと、送信位置情報記憶部106に記憶されている先頭シーケンスナンバー501から特定することができる。そして、エラーパターン解析部109は、特定したパケット数が、連続して送信する複数のグループにおいて対応する場合、輻輳によるパケット棄却が発生していると判断する。また、エラーパターン解析部109は、輻輳によるパケット棄却が発生していると判断した場合、特定したパケット数が小さいほど、重い輻輳が発生していると判断するようにしても良い。これは、輻輳による棄却パケットがグループの前方にあるほど、連続送信されたパケットのうち、例えばルータなどの中継装置で正常に中継することができたパケットが少ないと判断できるからである。このようにすれば、より少ない情報で、エラーパターンを判断することができる。
次に図3を参照しながら、輻輳以外のエラーパターン解析について説明する。
図3は、図2と同様に、棄却されたパケットのグループ内における位置を示した図であり、例えば、動画のデータをパケット化したものをフレーム毎に連続送信した場合の例を示している。
図3において、ランダムパターン301は、連続して送信された各グループ内のパケットが、特に規則性も無く、例えば、1パケット単位でパケット棄却が発生しているパターンを示している。つまり、ランダムパターン301は、連続して送信する複数のグループのそれぞれでエラーとなったパケットの位置が他のグループでエラーとなったパケットの位置と対応しない。また、ランダムパターン301は、エラーが発生するパケットが所定数以上連続していない。
エラーパターン解析部109は、このエラーパターンが、所定の時間内に(または所定数のグループにおいて)所定の回数以上発生した場合に、ランダムパターン301によるパケット棄却が発生したと判断する。また、エラーパターン解析部109は、このエラーパターンが、連続する所定数以上の複数のグループにおいて発生した場合、ランダムパターン301によるパケット棄却が発生したと判断する。
一方、バーストパターン302は、連続して送信された各グループ内のパケットが、前述の輻輳を示すエラーパターンとは異なるパターンで、複数のパケットが連続して棄却されるパターンを示している。
つまり、バーストパターン302は、連続して送信する複数のグループのそれぞれでエラーとなったパケットの位置が他のグループでエラーとなったパケットの位置と対応しない。また、バーストパターン302は、エラーが発生するパケットが所定数以上連続している。
エラーパターン解析部109は、このエラーパターンが、所定の時間内に(または所定数のグループにおいて)所定の回数以上発生した場合に、バーストパターン302によるエラーが発生したと判断する。また、エラーパターン解析部109は、このエラーパターンが、連続する所定数以上の複数のグループにおいて発生した場合、バーストパターン302によるエラーが発生したと判断する。
この様に、エラーパターン解析部109は、輻輳を示すエラーパターン以外は、ランダムパターン301かバーストパターン302のいずれかに分類する。つまり、本実施形態のエラーパターン解析部109は、連続して送信する複数のグループのそれぞれでエラーとなったパケットの位置が他のグループでエラーとなったパケットの位置と対応しない場合、輻輳以外の要因でパケット棄却が発生していると判断する。
尚、エラーパターン解析部109は、ランダムパターン301であるかバーストパターン302であるかの分類をするために、エラーが発生したパケットがいくつ連続しているかを判断するが、その閾値は任意に設定すれば良い。また、エラーパターン解析部109は、複数のグループにおいて、連続してエラーが発生したパケット数の平均値や最大値などによってエラーパターンを分類しても良い。
また、本実施形態のエラーパターン解析部109は、受信情報として、パケット棄却率の通知も受けている。しかし、エラーパターン解析部109において、送信したパケット数と棄却されたパケット数からパケット棄却率を算出しても良い。
また、本実施形態のエラーパターン解析部109は、エラーパターンを解析した区間で複数のエラーパターンを検出した場合、エラーパターン毎にパケット棄却率を算出する。即ち、本実施形態のエラーパターン解析部109は、輻輳パターン、ランダムパターン、バーストパターンのそれぞれについて、パケット棄却率を算出する。
例えば、エラーパターン解析部109によって解析した区間において送信したパケット数が100パケットであったとする。そして、エラーパターン解析部109は、その解析区間において、輻輳パターンによって8パケットのパケット棄却が発生し、ランダムパターン301によって2パケットのパケット棄却が発生したと判断したとする。この場合、エラーパターン解析部109は、輻輳パターンによるパケット棄却率が8%、ランダムパターンによるパケット棄却率が2%であるというように、エラーパターンごとのパケット棄却率を算出する。
尚、エラーパターン解析部109は、上述のように、連続して送信される複数のグループにおいて、棄却パケットの位置が対応する場合、そのパケットは輻輳パターンによって棄却されたパケットであると判断する。また、エラーパターン解析部109は、連続して送信される複数のグループにおいて、棄却パケットの位置が対応しない場合、そのパケットは、ランダムパターン、或いは、バーストパターンによって棄却されたパケットであると判断する。さらに、エラーパターン解析部109は、棄却パケットがランダムパターンかバーストパターンのどちらによって棄却されたかを、棄却パケットがいくつ連続しているかによって判断する。
次に、エラーパターン解析部109から、エラーパターン解析結果の通知を受けたQoS制御部110における各QoS手段の制御方法について図8を参照しながら説明する。
図8は、本実施形態の送信装置100によるデータ送信処理のフローチャートである。
まず、送信装置100の送受信部107は、受信装置に対し、伝送路112を介してパケットを送信する(S801)。
続いて送受信部107は、受信装置から、受信情報パケット、即ち、図4で示した受信情報を受信する(S802)。
即ち、送受信部107は、S802(受信手順)において、通信相手(受信装置)から、パケットの受信状況を示す受信情報(受信情報パケット)を受信する。
送受信部107は、受信情報パケットの受信に応じて、受信情報をエラーパターン解析部109に通知する。ここで送受信部107からエラーパターン解析部109に通知される受信情報には、棄却パケットのシーケンスナンバーが含まれる。受信情報を通知されたエラーパターン解析部109は、通信エラーの有無について判断する(S803)。
エラーパターン解析部109は、S803で、エラーが発生していないと判断した場合(No)は、そのことをQoS制御部110に通知する。そして、エラーが発生していないことを通知されたQoS制御部110は、現在の符号化レートと予め目標として設定された目標レートを比較する(S804)。符号化レートとは、単位時間当たりに送信されるデータパケット(例えば映像データのパケット)の送信レートを示す。QoS制御部110は、現在の符号化レートが目標レートに達していないと判断した場合は、符号化レートを所定の割合増加させる(S805)。S804で現在の符号化レートが目標レートに達していないと判断される場合の例として、1つのグループで1つのフレームのデータが送れずに、複数のグループに分けて送信している場合がある。このような場合、QoS制御部110は、S805で、1つのグループで送信するデータパケットの数を増やす。これにより、例えば、1フレーム分のデータを5つのグループに分けて送信されていた場合、1フレーム分のデータが3つのグループで送信されるようになる。なお、グループ内のパケット数を変化させても、グループの間隔は保持する。ここで、グループの間隔とは、あるグループAの最後のパケットの送信から、グループAの次に送信するグループBの先頭のパケットを送信するまでの間隔である。一方、QoS制御部110が、S804で、既に現在の符号化レートが目標レートに達していると判断した場合は、符号化レートを変更せずにS801に戻る。
エラーパターン解析部109は、S803において、通信エラーが発生していたと判断した場合(Yes)、受信情報を読み出し(S806)、メモリに記憶させる(S807)。エラーパターン解析部109がメモリに記憶させる情報には、棄却パケットのシーケンスナンバー、パケット棄却率が含まれる。パケット棄却率は、図4で説明したように、送信したパケットのうち、通信経路で棄却されたパケット及びビットエラーとなったパケット(棄却パケット)の割合を示している。
そして、エラーパターン解析部109は、エラーパターンの解析を行なう(S808)。尚、上述のように、エラーパターン解析部109は、棄却パケットのシーケンスナンバー403、先頭シーケンスナンバー501、及び連続送信パケット数502によってグループ内における棄却パケットの位置を特定する。ここで、棄却パケットのシーケンスナンバー403は、送受信部107から通知され、先頭シーケンスナンバー501、及び連続送信パケット数502は、送信位置情報記憶部106に記憶されている。そして、エラーパターン解析部109は、図2、図3を用いて説明したように、特定された棄却パケットの位置に基づいて、エラーパターンの解析を行う。即ち、エラーパターン解析部109は、S808において、パケットを送信するグループ内における、エラーが発生したパケットの位置を、受信情報から特定する。ここで、エラーパターン解析部109は、S808において、エラーパターンを、前述の通り輻輳パターン(P1)かランダムパターン(P2)かバーストパターン(P3)のいずれかに分類する。また、エラーパターン解析部109は、複数のエラーパターンを検出した場合、エラーパターンごとのパケット棄却率を算出する。また、エラーパターン解析部109は、S808において、エラーパターンの解析結果をQoS制御部110に通知する。
エラーパターンの解析結果の通知を受けたQoS制御部110は、当該エラーパターンに輻輳パターン(P1)を含むか否か判定する(S809)。この輻輳パターン(P1)には、図2で説明した輻輳パターン1(201)、輻輳パターン2(202)、輻輳パターン3(203)が含まれる。QoS制御部110は、輻輳パターン(P1)を含むと判定した場合(Yes)、輻輳状態を回避するため、グループ内のパケット数を設定する(S810)。
具体的には、QoS制御部110は、例えば、輻輳パターン(P1)が含まれると判定した場合、連続送信するパケット群のパケット数を減少させる。つまり、QoS制御部110は、例えば、複数の連続送信するパケット群(グループ)において、先頭から5つめのパケットが棄却パケットとなる場合、グループ内のパケット数の最大値を4に設定する。つまり、QoS制御部110は、1つのフレームのパケット数が、設定されたグループ内のパケット数の最大値を超える場合、各グループのパケット数が最大値を超えないように、当該フレームのデータを複数のグループに分けて送信させる。ただし、グループ内のパケット数の設定方法については、これに限らない。
ここで、QoS制御部110がS810で設定するグループ内のパケット数は、データパケット(例えば映像データのパケット)のパケット数(符号化レート)に、FECパケットのパケット数(FECレート)を加えたパケット数のことを示している。
尚、本実施形態のエラーパターン解析部109は、連続して送信する複数のグループにおいて、棄却パケットの位置が対応する場合、輻輳が原因でパケットの棄却が発生していると判断する。
即ち、QoS制御部110は、連続して送信する複数のグループ内の対応する位置でエラーが発生する場合、グループ内におけるパケット数を減少させる。
また、グループをグループAとグループBに分割すると、グループAの最後に送信されるパケットから、次のグループBの先頭で送信されるパケットまでの間隔が広がることになる。本実施形態のQoS制御部110は、グループ内のパケット数を減少させたあと、各グループの間隔が、グループ内のパケット数を減少させる前のグループの間隔と同じ間隔となるように、各グループの間隔の設定を行う。また、本形態のQoS制御部110は、グループ内のパケット数を増加させた場合、パケット数を設定する前の各グループの間隔を保持する。
S810でパケットのグループ内のパケット数を設定したQoS制御部110は、FECで回復すべきエラーであるランダムパターン(P2)及びバーストパターン(P3)によるパケット棄却率から、FECの冗長度を設定する(S811)。尚、本形態のQoS制御部110は、S811において、エラーの原因がランダムパターン(P2)であるかバーストパターン(P3)であるかに応じて、FECの種類を設定する。すなわち、ランダムパターン(P2)では、棄却パケットが所定数以上連続しない。そこで、QoS制御部110は、ランダムパターン(P2)によるパケット棄却に対しては、グループ内のデータパケットを送信順序が連続する複数のサブグループに分け、それぞれのサブグループに対してFECパケットを生成させる。一方、バーストパターン(P3)は、棄却パケットが連続する。そこで、QoS制御部110は、バーストパターンによるパケット棄却に対しては、グループ内のデータパケットを送信順序が連続しない複数のサブグループに分け、それぞれのサブグループに対してFECパケットを生成させる。QoS制御部110は、例えば、1つのグループで9つのデータパケットを送信する場合であって、9つのデータパケットに対して3つのFECパケットを付加する場合、エラーの原因に応じて、次にようにFECを設定する。すなわち、ランダムパターンに対しては、送信順序が1〜3番目のデータパケット、4〜6番目のデータパケット、7〜9番目のデータパケットのサブグループに分ける。そして、それぞれのサブグループ内のデータパケットが1つ、棄却パケットとなっても回復できるようにFECパケットを生成させる。一方、バーストパターンに対しては、送信順序が1、4、7番目のデータパケット、2、5、8番目のデータパケット、3、6、9番目のデータパケットのサブグループに分ける。そして、それぞれのサブグループ内のデータパケットが1つ、棄却パケットとなっても回復できるようにFECパケットを生成させる。このようにすることで、エラーの原因に応じたFECによるQoS制御を実現することができる。
そして、QoS制御部110は、設定したFECの冗長度を誤り訂正符号化部103に通知する。尚、上述のように、FECパケットは、通信相手(受信装置)が、受信したパケットのエラー修正に利用できるように通信相手に送信するデータであり、冗長度は、データパケット数に対するFECパケット数を示すものである。
このように、本実施形態のQoS制御部110は、S809で、輻輳パターン(P1)が含まれると判断されると、それに応じてグループ内のパケット数を設定する。そして、QoS制御部110は、S810で、ランダムパターン(P2)及びバーストパターン(P3)によるパケット棄却率から、FECの冗長度を設定する。
QoS制御部110は、S810で設定したグループ内のパケット数から、S811で設定したFECの冗長度に応じたFECパケット数を差し引くことで、データパケット数(符号化レート)を設定し(S812)、設定した符号化レートをレート制御部111に通知する。上述のように、符号化レートとは、データパケット(例えば映像データのパケット)の送信レートである。
一方、S809で輻輳パターン(P1)が含まれていないと判断された場合(No)、QoS制御部110は、パケット棄却率が増加傾向にあるか否か判断する(S813)。パケット棄却率は、図4を用いて説明したように、送信したパケットのうち、通信経路で棄却されたパケット及びビットエラーとなったパケット(棄却パケット)の割合を示している。また、パケット棄却率は、S807でエラーパターン解析部109が、送受信部から通知された受信情報に応じて、メモリに記憶させている。
QoS制御部110は、S813において、パケット棄却率が増加傾向ではないと判断した場合(No)、現在の符号化レートが目標レートに達していないか判断する(S814)。QoS制御部110は、現在の符号化レートが目標レートに達していないと判断した場合(Yes)、符号化レートを所定の割合増加させ、増加させた符号化レートをレート制御部111に通知する(S815)。尚、符号化レートは、単位時間当たりに送信されるデータパケット(例えば映像データのパケット)の送信レートを示している。S814で現在の符号化レートが目標レートに達していないと判断される場合の例として、1つのグループで1つのフレームのデータが送れずに、複数のグループに分けて送信している場合がある。つまり、S809で輻輳が発生していると判断された場合、QoS制御部110は、S812で、輻輳によるパケット棄却が起こらないように、符号化レートを決定している。これにより、1つのフレームのデータを複数のグループに分けて送信することになると、各グループの間には間隔があいているため、符号化レートが下がり、目標レートを下回ってしまう場合がある。
これに対し、S815では、輻輳によるパケット棄却が発生しておらず、輻輳以外が原因のパケット棄却率も増加していないので、QoS制御部110は、データパケットの送信レートが目標レートを下回らないように、或いは、目標レートに近づくように増加させる。これにより、例えば、1フレーム分のデータを5つのグループに分けて送信されていた場合、1フレーム分のデータが3つのグループで送信されるようになる。なお、グループ内のパケット数を変化させても、グループの間隔は保持する。ここで、グループの間隔とは、あるグループAの最後のパケットの送信から、グループAの次に送信するグループBの先頭のパケットを送信するまでの間隔である。このようにして、QoS制御部110は、単位時間あたりに送信するデータパケットの数を増加させる。
つまり、QoS制御部110は、S814において、現在の符号化レートが目標レートに達していないと判断した場合、連続送信するパケット群(グループ)におけるパケット数を増加させる。
そして、QoS制御部110は、S811と同様に、ランダムパターン(P2)及びバーストパターン(P3)によるパケット棄却率に応じて、FEC冗長度を設定し、設定したFEC冗長度を誤り訂正符号化部103に通知する(S816)。
一方、QoS制御部110が、S814において、現在の符号化レートが目標レートに達していると判断した場合(No)、S816に進む。S816では、上述のように、QoS制御部110が、ランダムパターン(P2)及びバーストパターン(P3)によるパケット棄却率に応じて、FEC冗長度を設定し、設定したFEC冗長度を誤り訂正符号化部103に通知する。つまり、S816では、QoS制御部110が、輻輳以外のエラーパターンによるパケット棄却率に応じて、FEC冗長度を設定する。尚、FECパケットは、通信相手(受信装置)が、受信したパケットのエラー修正に利用できるように通信相手に送信するデータであり、冗長度は、データパケット数に対するFECパケット数を示すものである。
また、QoS制御部110は、S813において、パケット棄却率が増加傾向にあると判断した場合(Yes)、S816と同様にFEC冗長度を設定し、設定したFEC冗長度を誤り訂正符号化部103に通知する(S817)。
即ち、QoS制御部110は、S810〜S817(設定手順)で、エラーが発生したパケットの位置に基づいて、以下のような設定を行う。すなわち、QoS制御部110は、グループ内におけるパケット数、及び、通信相手(受信装置)が受信したパケットのエラー修正に利用できるように通信相手に送信するデータのデータ数のうち、少なくともいずれかを設定する。
また、QoS制御部110は、連続して送信する複数のグループ内の対応する位置と対応しない位置でエラーが発生した場合、グループ内におけるパケット数を減少させ、FEC冗長度を増加させる。尚、FEC冗長度は、データパケット数に対する、通信相手が受信したパケットのエラー修正に利用できるように当該通信相手に送信するデータ(FECデータ)数である。
S818において、QoS制御部110は、解析したエラーパターンにバーストパターン(P3)が含まれているか否かを判断する。
QoS制御部110が、エラーパターンにバーストパターン(P3)が含まれていると判断した場合(Yes)、バーストエラー率が増加傾向にあるか判断(S819)する。ここで、バーストエラー率とは、上述のエラーパターン解析部109によって算出されたエラーパターン毎のパケット棄却率のうち、バーストパターン(P3)によるパケット棄却率のことを示す。QoS制御部110は、バーストエラー率が増加傾向にあると判断した場合(Yes)、バースト耐性を向上させ(S820)、増加傾向でないと判断した場合はバースト耐性を低下させる(S821)。つまり、QoS制御部110は、例えば、これまでに算出されたバーストエラー率よりも、今回算出されたバーストエラー率のほうが高い場合、バースト耐性を向上させる。また、QoS制御部110は、例えば、これまでに算出されたバーストエラー率よりも、今回算出されたバーストエラー率のほうが低い場合、バースト耐性を低下させる。
ここで、QoS制御部110がバースト耐性を向上する具体的な方法として、例えば、送信するパケットの順序を例えばランダムに入れ替える方法がある。即ち、QoS制御部110は、S820において、連続してエラーになるパケットが所定数よりも多い場合、パケットの再生順序に対する送信順序が一定とならないように制御する。
ただし、バースト耐性を向上する方法として、異なるフレームのデータパケットからFECパケットを生成する方法などを用いても良い。QoS制御部110は、このような方法により、バースト耐性を向上させることができる。ただし、バースト耐性の向上と引き替えにリアルタイム性を損なう場合があるので、バーストエラーが減少傾向にある場合は、バースト耐性を下げ、リアルタイム性を向上させることが望ましい。従って、S818においてエラーパターンにバーストパターン(P3)が含まれていない場合は、バースト耐性を基本状態である初期レベルに戻し(S822)、リアルタイム性を向上させる。つまり、QoS制御部110は、S822でバースト耐性を減少させる場合は、送信するパケットの順序を入れ替えないようにしたり、同一のフレームのデータパケットからFECパケットを生成するようにする。このようにすることにより、バーストパターンが発生していない場合に、バースト耐性を下げ、リアルタイム性を向上させることができる。
以上のように、本実施形態の送信装置は、通信エラーのパケット棄却率をエラーパターン毎に分類する。そして、輻輳が原因のエラーに対してはグループ内のパケット数を制御することで回避し、輻輳以外が原因のエラーに関してはFECによって受信装置側でパケットの復元を行わせる。また、輻輳以外が原因のエラーのうち、特に、バーストエラーによるパケット棄却率が変化した場合は、それに応じてバースト耐性を変更する。このようにすることで、通信エラーの原因に応じたQoS制御を行うことが可能となる。
ところで、S802において受信装置から受け取る受信情報パケットには、例えば、RTCP(RTP Control Protocol)というプロトコルが使用される。そして、特に本実施形態における受信情報のようなデータを、RTCPでは、レシーバーレポートという。
このレシーバーレポートは、一般に比較的短い時間間隔で送信されるものであり、それに含まれる情報は、比較的短い期間の情報となる。従って、1つのレシーバーレポートの情報のみから随時制御を行なうと、その都度、グループ内のパケット数やFEC冗長度が大きくばらついてしまう。このように、グループ内のパケット数が短い間隔でばらつくと、短い時間間隔におけるパケットの送信レートが大きくばらつくことになる。
そこで、グループ内のパケット数やFEC冗長度を設定する際に、S807でメモリに保持された過去の情報を用いて統計処理を行なうことで、ばらつきを抑えることが望ましい。統計処理を行うために用いる過去の情報として、例えば、エラーパターン毎のパケット棄却率がある。つまり、QoS制御部110は、図8で説明したように、輻輳によるパケット棄却率に応じて、例えばS810でグループ内のパケット数を設定し、ランダムパターンやバーストパターンによるパケット棄却率に応じて、FEC冗長度を設定する。ここで、レシーバーレポートの受信ごとに、例えば輻輳によるパケット棄却率を算出し、グループ内のパケット数を変更してしまうと、各グループのパケット数が大きくばらついてしまう場合がある。そこで、QoS制御部110は、過去に算出された、輻輳によるパケット棄却率を用いて、各グループのパケット数のばらつきを抑える。
QoS制御部110が各グループのパケット数のばらつきを抑えるために過去のパケット棄却率を用いる具体的な方法として、例えば、以下のような方法がある。すなわち、レシーバーレポートの受信に応じて算出した輻輳によるパケット棄却率と、所定数ぶんだけ過去に受信されたレシーバーレポートに応じて算出された輻輳によるパケット棄却率との平均値をとる。また、或いは、単純な平均値ではなく、予め設定された重み付けに従って過去に算出された輻輳によるパケット棄却率を重み付けして、パケットの棄却率の平均値をとるようにしても良い。また、或いは、レシーバーレポートの受信に応じて算出した輻輳によるパケット棄却率と、前回算出した輻輳によるパケット棄却率の差が、所定の値よりも小さい場合は、輻輳によるパケット棄却率が変化していないと判断するようにしても良い。
また、統計処理を行うために用いる過去の情報の別の例として、例えば、過去のグループ内のパケット数や、FEC冗長度、符号化レートがある。つまり、QoS制御部110は、過去に用いられた、グループ内のパケット数、FEC冗長度、符号化レートによって、各グループのパケット数のばらつきを抑える。QoS制御部110が各グループのパケット数のばらつきを抑えるために過去のグループ内のパケット数を用いる具体的な方法として、例えば、以下のような方法がある。すなわち、レシーバーレポートの受信に応じて算出したグループ内のパケット数と、所定数ぶんだけ過去に受信されたレシーバーレポートに応じて算出されたグループ内のパケット数との平均値をとる。また、或いは、単純な平均値ではなく、予め設定された重み付けに従って過去に算出されたグループ内のパケット数を重み付けして、グループ内のパケット数の平均値をとるようにしても良い。また、或いは、レシーバーレポートの受信に応じて算出したグループ内のパケット数と、前回算出したグループ内のパケット数の差が、所定の値よりも小さい場合は、グループ内のパケット数を変化させないようにしても良い。
このようにして、本実施形態のQoS制御部110は、過去の情報を用いて、各グループのパケット数や、FEC冗長度のばらつきを抑える。また、このようにすることで、短い時間間隔におけるパケットの送信レートのばらつきを低減する。
しかし一方で、統計処理における過去の情報の重み付けを重くすると、例えばネットワーク上で、急激な帯域の変動があった場合などにおけるエラー回避やレート回復のレスポンスが悪化してしまう恐れがある。
そこで、本実施形態のQoS制御部110は、比較的軽い輻輳状態である場合は、過去の情報の重み付けを重くすることで、各グループのパケット数やFEC冗長度がばらついてしまうことを抑える。一方、QoS制御部110は、比較的重い輻輳状態である場合は、過去の情報の重み付けを軽くする(もしくは参照しない)ことによって急激な帯域の変動などにおけるエラー回避やレート回復のレスポンスを向上させるようにする。
尚、図2を用いて説明したように、本実施形態のエラーパターン解析部109が検知する輻輳パターン(P1)は3つあり、この輻輳パターンによって輻輳の程度を分類することができる。すなわち、輻輳パターン1(201)は、他の輻輳パターンよりも比較的軽い輻輳状態のときに発生する輻輳パターンであり、輻輳パターン2(202)、輻輳パターン3(203)は、比較的重い輻輳状態のときに発生する輻輳パターンであると分類できる。
また、エラーパターン解析部109は、上述のように、輻輳状態の重さを、エラーとなるパケットの位置によって判断することもできる。つまり、エラーパターン解析部109は、連続して送信する複数のグループで棄却パケットの位置が対応する場合、その棄却パケットの位置が、グループの前方にあるほど、重い輻輳状態であると判断しても良い。
ただし、輻輳状態の重さを判断する方法は、この方法に限らず、例えば、輻輳による棄却パケットの数などによって判断することも可能である。
このように、検知した輻輳のパターンに応じて、グループ内のパケット数やFEC冗長度設定の計算方法を動的に変更することで、輻輳の程度に応じたグループ内のパケット数やFEC冗長度の設定を行うことができる。
QoS制御部110が、検知された輻輳パターンに応じて、グループ内のパケット数、FEC冗長度を設定する際に参照する過去の情報の重み付けを制御する処理について、図9のフローチャートを用いて説明する。尚、図9のS901の処理は、図8を用いて説明した、S810の処理時に実行される。
エラーパターン解析部109からエラーパターンの解析結果を通知されたQoS制御部110は、輻輳パターン2(202)、または輻輳パターン3(203)がエラーパターンに含まれているか否かを判断する(S901)。ここで、輻輳パターン2(202)、輻輳パターン3(203)は、上述のように、図2で説明した輻輳パターンのうち、比較的重い輻輳状態のときに発生する輻輳パターンである。
QoS制御部110は、これらの輻輳パターンが含まれていると判断した場合(Yes)、過去の情報の重み付けを軽くするか、或いは無視する(S902)。このようにすることで、急激な帯域の変動などにおけるエラー回避やレート回復のレスポンスを向上させる。
一方、QoS制御部110は、S901において、輻輳パターン2(202)または輻輳パターン3(203)を含まないと判断した場合(No)、過去の情報に所定の重み付けをする。そして、QoS制御部110は、所定の重み付けをされた過去の情報と、現在の情報とに応じて、グループ内のパケット数や符号化レート、FEC冗長度などを算出する(S903)。上述のように、過去の情報は、例えば、これまでに送信したグループ(第1のグループ)の受信状況を示す受信情報パケット(レシーバーレポート)に応じて算出されたエラーパターン毎のパケット棄却率である。また、過去の情報の他の例は、例えば、これまでに用いられたグループ内のパケット数や、符号化レート、FEC冗長度などである。
また、現在の情報とは、例えば、前記これまでに送信したグループよりも後に送信したグループ(第2のグループ)の受信状況を示す受信情報パケット(レシーバーレポート)によって算出されたエラーパターン毎のパケット棄却率である。また、現在の情報のほかの例は、例えば、前記これまでに送信したグループよりも後に送信したグループの受信状況を示すレシーバーレポートの受信に応じて算出されたグループ内のパケット数や、符号化レート、FEC冗長度などである。
即ち、送受信部107は、第1の複数のグループの受信状況を示す第1の受信情報と、当該第1の複数のグループよりも後に送信した第2の複数のグループの受信状況を示す第2の受信情報を受信している。そして、QoS制御部110は、S903で、第1の受信情報、及び第2の受信情報に基づいて、第2の複数のグループよりも後に送信する第3の複数のグループ内におけるパケット数を設定する。ここで、本実施形態における受信情報は、受信情報パケット(レシーバーレポート)である。
また、S902において、QoS制御部110は、輻輳パターン2又は輻輳パターン3を含むと判断した場合、過去の情報の重み付けを軽くするか、或いは無視する。尚、上述の通り、輻輳パターン2、輻輳パターン3は、比較的重い輻輳である場合に発生する輻輳パターンである。また、これらの輻輳パターンは、グループで最初にエラーとなったパケットの位置が、グループ内において前方にある場合に検知されるパターンである。即ち、QoS制御部110は、第2の複数のグループでエラーとなるパケットの位置のうちの最も前の位置が第1の位置より前の第2の位置である場合、第2の複数のグループでエラーとなるパケットの位置のうちの最も前の位置が第2の位置である場合より、第1の受信情報の重み付けが軽くなるように重み付けを設定する。そして、QoS制御部110は、重み付けを設定した第1の受信情報及び第2の受信情報に基づいて、第3の複数のグループ内におけるパケット数を決定する。このように、検知した輻輳のパターンに応じて、グループ内のパケット数やFEC冗長度設定の計算方法を動的に変更することで、輻輳の程度に応じたグループ内のパケット数やFEC冗長度の設定を行うことができる。
以上のように、本発明の送信装置100は、連続して送信するパケットにおける棄却されたパケットの位置から、通信エラーの原因の推定し、さらに、原因別にパケット棄却率を算出する。そして、送信装置100は、通信エラーの原因に基づいて、適切なQoSの技術を選択・制御する。このようにすることで、通信エラーが発生する原因に応じたQoSの制御を行うことができる。
尚、本実施形態のエラーパターン解析部109は、データパケット及びFECパケットの通信エラー状況から通信エラーの状況を解析する方法について説明した。しかし、ネットワークの品質を確認するためのダミーパケットを送信し、そのダミーパケットの通信エラー状況から、エラーパターン解析部109が通信エラーの状況を解析しても良い。このようにすれば、データパケットが棄却されることを低減できる。
<実施形態2>
次に本発明による第2の実施形態について、実施形態1との差異を中心に説明する。本実施形態は、受信装置にエラーパターン解析機能を有する場合の実施例である。
図6は、本発明の実施に好適な受信装置の基本構成を示すブロック図である。この受信装置600は、パーソナルコンピュータ、ワークステーション、ノートブックPC、パームトップPC、コンピュータを内蔵した各種家電製品、ゲーム機、携帯電話、デジタルビデオカメラ、デジタルカメラなどのうち、複数のグループに分けられて送信され、かつ、グループ間に送信待機時間を設けて送信される複数のパケットを受信することができる装置、もしくは、これらの組合せにより実現可能である。
図6に示すように、受信装置600は、送受信部601、受信バッファ602、パケット棄却検出部603、エラーパターン解析部604、パケット復元部605、再送要求部606から構成されている。
一方、図7は、本実施形態の受信装置600に対し、データを送信する送信装置700のブロック図を示しており、送信装置700はRTPプロトコルを用いてパケットを通信するものとする。この送信装置700は、パーソナルコンピュータ、ワークステーション、ノートブックPC、パームトップPC、コンピュータを内蔵した各種家電製品、ゲーム機、携帯電話、デジタルビデオカメラ、デジタルカメラなどのうち、複数のパケットを、順次、通信相手(受信装置)に送信することができる装置、もしくは、これらの組合せにより実現可能である。
受信装置600の送受信部601は、各種ネットワークに代表される伝送路である伝送路112を介してパケットの送受信を行う機能を備えている。送受信部601は、受信したパケットを受信バッファ602に保持させる。また、送受信部601は、例えば、受信装置600におけるパケットの受信情報を送信装置700に通知するための、受信情報パケットや、通信経路で棄却されたパケットの再送要求をするための再送要求パケットを送信装置700に対して送信する。
パケット棄却検出部603は、受信バッファ602に保持されるRTPパケットのヘッダ部分にあるシーケンスナンバーを随時監視し、シーケンスナンバーに抜けが無いか確認することで、通信経路でのパケットの棄却を検知する。
そして、パケット棄却検出部603は、パケットの棄却を検知すると、検知された棄却パケットのシーケンスナンバーをエラーパターン解析部604に通知する。また、パケット棄却検出部603は、グループ内における棄却パケットの位置を特定するための情報を、エラーパターン解析部604に通知する。棄却パケットの位置を特定するための情報の詳細については、後述する。
パケット棄却検出部603から通知を受けたエラーパターン解析部604は、図2及び図3で示したエラーパターンの解析と、エラーパターン毎のパケット棄却率を算出する。
ここで、エラーパターン解析部604は、図2及び図3に示す解析を行なうために、連続して送信されるパケット群(グループ)の区切りを識別する必要がある。つまり、エラーパターン解析部604は、グループ内における棄却パケットの位置を特定するために、グループの区切りを識別する。本実施形態の送信装置700は、送信するグループの間に間隔をあけているため、その間隔を保ったまま受信された場合は、受信装置600は、受信したパケットの間隔を目安に、グループの区切りを識別することができる。
しかし、ネットワークの状況によっては、ジッタなどの影響により、グループの区切りが識別できなくなる恐れがある。そこで、本実施形態では、RTPヘッダの拡張領域を利用することで、グループの区切りを識別できるようにする。
図11に示すRTPヘッダのフォーマットにおいて、『X』1101は1ビットのフラグであり、このフラグが設定されている場合、RTPの固定ヘッダに続いて、拡張領域が続くことを示している。
図12はRTPヘッダの拡張領域のフォーマットを示しており、『length』1201は拡張領域のサイズ、『header extension』1202は拡張領域のデータを格納する領域である。
図13に、『header extension』1202の内容を示す。図13の『First sequence number』1301には、連続送信したパケット群(グループ)の先頭のパケットのシーケンスナンバーを記録する。また、『Last sequence number』1302には、連続送信したパケット群(グループ)の最後のパケットのシーケンスナンバーを記録する。
すなわち、本実施形態の送信装置700は、図11の『X』1101のフラグを設定して拡張領域を有効とする。さらに、送信装置700は、図13に示すように、グループ内の先頭のパケットのシーケンスナンバーと、グループ内の最後のパケットのシーケンスナンバーを記録する。また、送信装置700は、同じグループの複数のパケット全てに上記の先頭、及び最後のシーケンスナンバーの情報を付加する。
そして、エラーパターン解析部604は、付加されたシーケンスナンバーの情報を参照することで、連続送信したパケット群の先頭及び最後のパケットの識別、すなわちグループの区切りの識別が可能になる。
つまり、パケット棄却検出部603は、正常に受信されたパケットのシーケンスナンバーを取得することで、棄却パケットのシーケンスナンバーを取得する。また、パケット棄却検出部603は、正常に受信されたパケットの拡張領域に記録されているグループ内の先頭のパケットのシーケンスナンバーと、最後のパケットのシーケンスナンバーを取得する。
即ち、パケット棄却検出部603は、受信されたパケットに含まれる、当該パケットのグループ内の位置を識別可能な識別情報を取得する。
そして、パケット棄却検出部603は、取得した棄却パケットのシーケンスナンバー、グループ内の先頭パケットのシーケンスナンバー、最後のパケットのシーケンスナンバーをエラーパターン解析部604に通知する。エラーパターン解析部604は、パケット棄却検出部603から通知されたこれらの情報により、棄却パケットのグループ内の位置を特定する。
即ち、エラーパターン解析部604は、パケット棄却検出部603により取得された識別情報により、送信装置から送信されたパケットのうちネットワーク上でエラーとなったパケット(棄却パケット)の、グループ内における位置を特定する。尚、本実施形態において、識別情報は、正常に受信されたパケットのシーケンスナンバー、正常に受信されたRTPパケットのヘッダの拡張領域に記録されるグループ内の先頭のシーケンスナンバー、及び最後のシーケンスナンバーである。
このようにすることで、エラーパターン解析部604は、例えば、通信経路中でのパケットの棄却や、ジッタによるパケット送信間隔の乱れがあっても、連続送信したパケット群の区切りの識別することが可能になる。そして、エラーパターン解析部604は、エラーパターンの解析を正しく行なうことが可能になる。尚、エラーパターン解析部604は、実施形態1と同様に、エラーパターンの解析処理を行う。例えば、エラーパターン解析部604は、連続して送信する複数のグループの対応する位置でパケット棄却が発生している場合、輻輳によるパケット棄却が発生していると判断する。
即ち、エラーパターン解析部604は、ネットワーク上でエラーとなったパケット(棄却パケット)の、グループ内における位置が、連続して送信する複数のグループ内の対応する位置であるか否かに基づいて、前記ネットワークの状態を判断する。
エラーパターン解析部604は、エラーパターンの解析結果を、受信情報パケット(RTCPのレシーバーレポート)として送受信部601、伝送路112を介して送信装置700に通知する。即ち、送受信部601は、エラーパターン解析部604で判断されたネットワークの状態を送信装置700へ通知する。
パケット復元部605では、パケット棄却検出部603から通知された棄却パケットのシーケンスナンバーに基づいて、FECによる棄却パケットの復元を行なう。また、パケット復元部605は、FECを用いても復元できなかったパケットの識別情報、例えば、シーケンスナンバーを再送要求部606に通知する。
再送要求部606は、パケット復元部605から通知された、復元できなかったパケットの識別情報を含めた再送要求パケットを送受信部601、伝送路112を介して送信装置700に通知する。
図7に示す送信装置700の構成は、実施形態1で説明した図1の送信装置100から、送信位置情報記憶部106とエラーパターン解析部109を除いたものとなっている。そして、この除かれたブロックの機能のうち、エラーパターン解析部109に対応するブロックが受信装置600のエラーパターン解析部604に追加されている。また、実施形態1のエラーパターン解析部109は、棄却パケットのシーケンスナンバーと、送信位置情報記憶部106に記憶された先頭シーケンスナンバー、及び連続送信パケット数により、棄却パケットのグループ内における位置を特定している。それに対し、本実施形態のエラーパターン解析部604は、棄却パケットのシーケンスナンバーと、RTPヘッダの拡張領域に記憶されたグループの先頭パケットのシーケンスナンバー、及びグループの最後のパケットのシーケンスナンバーにより、棄却パケットのグループ内における位置を特定する。従って、エラーパターン解析部604は、実施形態1のエラーパターン解析部109と同様に、エラーパターンの解析処理を行うことができる。
従って、本実施形態の送信装置700においても、受信装置600からエラーパターン解析結果を受け取ることで、図8に示す制御フローのように、パケット棄却が発生する原因に応じたQoSの制御を行うことができる。
<本発明に係る他の実施形態>
本発明の目的は、次の形態によっても達成される。即ち、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ(またはCPUまたはMPU)が記録媒体に格納されたプログラムコードを読み出し実行する形態である。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD−ROM、CD−R、磁気テープ、不揮発性のメモリカード、ROM、DVDなどを用いることができる。
また、本発明は、コンピュータが読み出したプログラムコードを実行することにより、前述した実施例の機能が実現される形態には限られない。すなわち、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているOperating System(OS)などが実際の処理の一部または全部を行い、その処理によって前述した実施例の機能が実現される場合も含まれる。
さらに、本発明には、以下の形態も含まれる。すなわち、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される形態である。
送信装置100の基本構成を示すブロック図である 輻輳によるエラーパターンを示した図である 輻輳以外のエラーパターンを示した図である 受信装置から送信装置100へ通知される受信情報の例である 送信位置情報記憶部106に保管された送信位置情報500の例である 受信装置600の基本構成を示すブロック図である 受信装置600にデータを送信する送信装置700のブロック図である 送信装置100における一連の制御フローである グループ内のパケット数や冗長度設定等の計算方法を動的に変更する制御フローである ネットワークの使用可能帯域を算出するTCPのスループット方程式である RFC1889で定義されたRTPヘッダのフォーマットである RTPヘッダの拡張領域のフォーマットである RTPヘッダの拡張領域利用の例である
符号の説明
100 送信装置
105 送信制御部
106 送信位置情報記憶部
107 送受信部
109 エラーパターン解析部
110 QoS制御部
600 受信装置
601 送受信部
603 パケット棄却検出部
604 エラーパターン解析部

Claims (19)

  1. 複数のパケットを、順次、通信相手に送信する送信装置であって、
    あるグループのパケットを送信してから次のグループのパケットを送信するまでの間に待機期間を設ける送信制御手段と、
    前記通信相手から、パケットの受信状況を示す受信情報を受信する受信手段と、
    パケットを送信するグループ内における、エラーが発生したパケットの位置を、前記受信情報から特定し、当該エラーが発生したパケットの位置に基づいて、グループ内のパケット数、及び、前記通信相手が受信したパケットのエラー修正に利用できるように当該通信相手に送信する修正用データのデータ数のうち、少なくともいずれかを設定する設定手段と
    を有することを特徴とする送信装置。
  2. 前記設定手段は、連続して送信する複数のグループのそれぞれにおいて、対応する位置でエラーが発生する場合、グループ内のパケット数を減少させることを特徴とする請求項1記載の送信装置。
  3. 前記設定手段は、連続して送信する複数のグループのそれぞれで、最後に送信するパケットがエラーになった場合、グループ内のパケット数を減少させることを特徴とする請求項1記載の送信装置。
  4. 前記設定手段は、連続して送信する複数のグループのそれぞれで、最初に送信するパケットから所定パケット数あとに送信されるパケットがエラーになった場合、グループ内のパケット数を減少させることを特徴とする請求項1記載の送信装置。
  5. 前記設定手段は、連続して送信する複数のグループのそれぞれで、グループ内のパケットのうち所定割合以上のパケットがエラーになった場合、グループ内のパケット数を減少させることを特徴とする請求項1記載の送信装置。
  6. 前記通信相手に送信するデータには、映像データを含み、
    前記設定手段は、連続して送信する複数のグループのそれぞれで最初にエラーとなったパケットの位置が他のグループの最初にエラーとなったパケットの位置と対応しない場合、前記通信相手に送信する映像データのデータ数に対する修正用データのデータ数を増加させることを特徴とする請求項1記載の送信装置。
  7. 連続してエラーになるパケットが所定数よりも多い場合、パケットの再生順序に対する送信順序が一定とならないように制御する制御手段
    を有することを特徴とする請求項1乃至6のうち、いずれか1項記載の送信装置。
  8. 前記受信手段は、第1の複数のグループの受信状況を示す第1の受信情報と、当該第1の複数のグループよりも後に送信した第2の複数のグループの受信状況を示す第2の受信情報を受信し、
    前記設定手段は、前記第1の受信情報、及び前記第2の受信情報に基づいて、前記第2の複数のグループよりも後に送信する第3の複数のグループ内におけるパケット数を設定する
    ことを特徴とする請求項1記載の送信装置。
  9. 前記設定手段は、前記第2の複数のグループでエラーとなるパケットの位置のうちの最も前の位置が所定の位置より前である場合、前記第2の複数のグループでエラーとなるパケットの位置のうちの最も前の位置が前記所定の位置である場合より、前記第1の受信情報の重み付けが軽くなるように重み付けを設定し、当該重みを設定した第1の受信情報及び第2の受信情報に基づいて、前記第3の複数のグループ内のパケット数を決定する
    ことを特徴とする請求項8記載の送信装置。
  10. 連続して送信する複数のグループ内の対応する位置と対応しない位置でエラーが発生した場合、
    前記設定手段は、グループ内のパケット数を減少させ、前記通信相手が受信したパケットのエラー修正に利用できるように当該通信相手に送信する修正用データのデータ数を増加させる
    ことを特徴とする請求項1記載の送信装置。
  11. 前記グループ内のパケット数が、グループによって異なる場合、
    前記設定手段は、前記グループ内のパケット数が所定数以上の複数のグループ内の対応する位置でエラーが発生する場合、パケット数が前記所定数以上のグループ内のパケット数を減少させる
    ことを特徴とする請求項1記載の送信装置。
  12. 複数のパケットを、順次、通信相手に送信する送信装置が行う送信方法であって、
    あるグループのパケットを送信してから次のグループのパケットを送信するまでの間に待機期間を設ける送信制御工程と、
    前記通信相手から、パケットの受信状況を示す受信情報を受信する受信工程と、
    パケットを送信するグループ内における、エラーが発生したパケットの位置を、前記受信情報から特定し、当該エラーが発生したパケットの位置に基づいて、グループ内のパケット数、及び、前記通信相手が受信したパケットのエラー修正に利用できるように当該通信相手に送信する修正用データのデータ数のうち、少なくともいずれかを設定する設定工程と、
    を有することを特徴とする送信方法。
  13. 複数のパケットを、順次、通信相手に送信するコンピュータに、
    あるグループのパケットを送信してから次のグループのパケットを送信するまでの間に
    待機期間を設ける送信制御手順と、
    前記通信相手から、パケットの受信状況を示す受信情報を受信する受信手順と、
    パケットを送信するグループ内における、エラーが発生したパケットの位置を、前記受信情報から特定し、当該エラーが発生したパケットの位置に基づいて、グループ内のパケット数、及び、前記通信相手が受信したパケットのエラー修正に利用できるように当該通信相手に送信する修正用データのデータ数のうち、少なくともいずれかを設定する設定手順と、
    を実行させることを特徴とするプログラム。
  14. 複数のパケットを、順次、通信相手にネットワークを介して送信する送信装置であって、
    あるグループのパケットを送信してから次のグループのパケットを送信するまでの間に待機期間を設ける送信制御手段と、
    前記通信相手から、パケットの受信状況を示す受信情報を受信する受信手段と、
    パケットを送信するグループ内における、エラーが発生したパケットの位置を、前記受信情報から特定し、当該エラーが発生したパケットの位置が、連続して送信する複数のグループ内の対応する位置であるか否かに応じて、前記ネットワークの状態を判断する判断手段と
    を有することを特徴とする送信装置。
  15. 複数のグループに分けられて送信され、かつ、グループ間に送信待機時間を設けて送信される複数のパケットを送信装置から受信する受信装置であって、
    前記受信されたパケットに含まれる、当該パケットのグループ内の位置を識別可能な識別情報を取得する取得手段と、
    前記取得された識別情報により、前記送信装置から送信されたパケットのうちネットワーク上でエラーとなったパケットの、グループ内における位置を特定し、当該特定されたグループ内における位置が、連続して送信される複数のグループ内の対応する位置であるか否かに基づいて、前記ネットワークの状態を判断する判断手段と、
    前記判断されたネットワークの状態を前記送信装置へ通知する通知手段と
    を有することを特徴とする受信装置。
  16. 複数のパケットを、順次、通信相手にネットワークを介して送信する送信装置が行う送信方法であって、
    あるグループのパケットを送信してから次のグループのパケットを送信するまでの間に待機期間を設ける送信制御工程と、
    前記通信相手から、パケットの受信状況を示す受信情報を受信する受信工程と、
    パケットを送信するグループ内における、エラーが発生したパケットの位置を、前記受信情報から特定し、当該エラーが発生したパケットの位置が、連続して送信する複数のグループ内の対応する位置であるか否かに応じて、前記ネットワークの状態を判断する判断工程と
    を有することを特徴とする送信方法。
  17. 複数のパケットを、順次、通信相手にネットワークを介して送信するコンピュータに、
    あるグループのパケットを送信してから次のグループのパケットを送信するまでの間に待機期間を設ける送信制御手順と、
    前記通信相手から、パケットの受信状況を示す受信情報を受信する受信手順と、
    パケットを送信するグループ内における、エラーが発生したパケットの位置を、前記受信情報から特定し、当該エラーが発生したパケットの位置が、連続して送信する複数のグループ内の対応する位置であるか否かに応じて、前記ネットワークの状態を判断する判断手順と
    を実行させることを特徴とするプログラム。
  18. 複数のグループに分けられて送信され、かつ、グループ間に送信待機時間を設けて送信される複数のパケットを送信装置から受信する受信装置が行う処理方法であって、
    前記受信されたパケットに含まれる、当該パケットのグループ内の位置を識別可能な識別情報を取得する取得工程と、
    前記取得された識別情報により、前記送信装置から送信されたパケットのうちネットワーク上でエラーとなったパケットの、グループ内における位置を特定し、当該特定されたグループ内における位置が、連続して送信される複数のグループ内の対応する位置であるか否かに基づいて、前記ネットワークの状態を判断する判断工程と、
    前記判断されたネットワークの状態を前記送信装置へ通知する通知工程と
    を有することを特徴とする処理方法。
  19. 複数のグループに分けられて送信され、かつ、グループ間に送信待機時間を設けて送信される複数のパケットを送信装置から受信するコンピュータに、
    前記受信されたパケットに含まれる、当該パケットのグループ内の位置を識別可能な識別情報を取得する取得手順と、
    前記取得された識別情報により、前記送信装置から送信されたパケットのうちネットワーク上でエラーとなったパケットの、グループ内における位置を特定し、当該特定されたグループ内における位置が、連続して送信される複数のグループ内の対応する位置であるか否かに基づいて、前記ネットワークの状態を判断する判断手順と、
    前記判断されたネットワークの状態を前記送信装置へ通知する通知手順と
    を実行させることを特徴とするプログラム。
JP2008169329A 2008-06-27 2008-06-27 送信装置、受信装置、及び方法、プログラム Active JP5094593B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2008169329A JP5094593B2 (ja) 2008-06-27 2008-06-27 送信装置、受信装置、及び方法、プログラム
US12/492,075 US8566662B2 (en) 2008-06-27 2009-06-25 Transmission apparatus, receiving apparatus, and method
CN2009101506927A CN101616185B (zh) 2008-06-27 2009-06-29 发送设备、接收设备和方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008169329A JP5094593B2 (ja) 2008-06-27 2008-06-27 送信装置、受信装置、及び方法、プログラム

Publications (2)

Publication Number Publication Date
JP2010011212A JP2010011212A (ja) 2010-01-14
JP5094593B2 true JP5094593B2 (ja) 2012-12-12

Family

ID=41449083

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008169329A Active JP5094593B2 (ja) 2008-06-27 2008-06-27 送信装置、受信装置、及び方法、プログラム

Country Status (3)

Country Link
US (1) US8566662B2 (ja)
JP (1) JP5094593B2 (ja)
CN (1) CN101616185B (ja)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101902315B (zh) * 2009-06-01 2013-04-17 华为技术有限公司 基于前向纠错的重传方法、设备和通信系统
CN102511150B (zh) * 2009-09-24 2015-12-09 日本电气株式会社 通信数据传输设备、通信数据传输系统、通信数据传输方法以及通信数据传输程序
US8274882B2 (en) * 2009-12-08 2012-09-25 At&T Intellectual Property I, Lp Bulk data transport in a network
JP5427707B2 (ja) * 2010-06-21 2014-02-26 日本電信電話株式会社 データ伝送システム及び方法
US8769516B2 (en) * 2010-08-19 2014-07-01 International Business Machines Corporation Systems and methods for automated support for repairing input model errors
CN102404182B (zh) * 2010-09-07 2014-12-31 中国移动通信集团公司 传输控制方法及装置
WO2011124184A2 (zh) 2011-05-16 2011-10-13 华为技术有限公司 丢包处理方法、目的网络节点设备及移动传输网络系统
US9338580B2 (en) * 2011-10-21 2016-05-10 Qualcomm Incorporated Method and apparatus for packet loss rate-based codec adaptation
CN102938738B (zh) * 2012-11-12 2015-06-17 上海斐讯数据通信技术有限公司 一种机架式设备卡间通信拥塞预防装置及方法
US20140164641A1 (en) * 2012-12-11 2014-06-12 The Hong Kong University Of Science And Technology Congestion control for data center traffic
US8948020B2 (en) * 2012-12-11 2015-02-03 International Business Machines Corporation Detecting and isolating dropped or out-of-order packets in communication networks
CN103108186A (zh) * 2013-02-21 2013-05-15 中国对外翻译出版有限公司 实现视频高清传播的方法
JP6323282B2 (ja) * 2014-09-29 2018-05-16 沖電気工業株式会社 回線終端装置
EP3104563B1 (en) 2015-06-10 2019-10-16 Nokia Solutions and Networks GmbH & Co. KG Sdn security
US9654815B2 (en) * 2015-09-18 2017-05-16 Arris Enterprises, Inc. Advertising detection in adaptive bitrate streaming
US10268541B2 (en) 2016-08-15 2019-04-23 Samsung Electronics Co., Ltd. DRAM assist error correction mechanism for DDR SDRAM interface
US10492084B2 (en) * 2016-10-10 2019-11-26 Microsoft Technology Licensing, Llc Collaborative communications
CN114070459B (zh) * 2020-08-04 2023-11-07 成都鼎桥通信技术有限公司 数据传输方法、装置、终端设备和存储介质
CN114584257B (zh) * 2022-01-26 2024-02-13 百果园技术(新加坡)有限公司 一种基于前向纠错编码的冗余分配方法及装置

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08130530A (ja) * 1994-11-01 1996-05-21 Hitachi Ltd デジタルデータ通信方法およびデジタルデータ通信制御システム
JP2003324496A (ja) * 1998-11-30 2003-11-14 Matsushita Electric Ind Co Ltd データ伝送方法,及びパケットデータ構造
JP4101993B2 (ja) * 1999-12-03 2008-06-18 三菱電機株式会社 有線無線混在網データ配信装置及び有線無線混在網データ配信方法
JP4061643B2 (ja) * 2002-12-11 2008-03-19 ソニー株式会社 情報処理システム、情報処理装置および方法、記録媒体、並びにプログラム
WO2005046125A1 (en) * 2003-10-28 2005-05-19 Docomo Communications Laboratories Usa, Inc. Method for supporting scalable and reliable multicast in tdma/tdd systems using feedback suppression techniques
JP4349114B2 (ja) 2003-12-10 2009-10-21 ソニー株式会社 送信装置および方法、受信装置および方法、記録媒体、並びにプログラム
JP4417733B2 (ja) 2004-01-15 2010-02-17 ソニー・エリクソン・モバイルコミュニケーションズ株式会社 伝送方法及び装置
CA2596927A1 (en) * 2005-02-04 2006-08-10 Apparent Networks, Inc. Method and apparatus for evaluation of service quality of a real time application operating over a packet-based network
JP2006262288A (ja) * 2005-03-18 2006-09-28 Nec Corp 映像データの配信サーバおよび映像データ配信方法
FR2906428A1 (fr) * 2006-09-26 2008-03-28 Canon Kk Procede, dispositif et application logicielle pour la transmission de paquets de donnees dands un systeme de communication.
CN101043296A (zh) 2007-04-28 2007-09-26 华为技术有限公司 请求重传数据的方法、数据重传方法和数据传输系统
EP2019522B1 (en) * 2007-07-23 2018-08-15 Polycom, Inc. Apparatus and method for lost packet recovery with congestion avoidance
US9312989B2 (en) * 2008-07-07 2016-04-12 Cisco Technology, Inc. Importance-based FEC-aware error-repair scheduling

Also Published As

Publication number Publication date
CN101616185A (zh) 2009-12-30
CN101616185B (zh) 2013-03-27
US20090327844A1 (en) 2009-12-31
JP2010011212A (ja) 2010-01-14
US8566662B2 (en) 2013-10-22

Similar Documents

Publication Publication Date Title
JP5094593B2 (ja) 送信装置、受信装置、及び方法、プログラム
JP4697525B2 (ja) 送受信システム、送信装置および送信方法、受信装置および受信方法、並びにプログラム
US9781488B2 (en) Controlled adaptive rate switching system and method for media streaming over IP networks
EP2255535B1 (en) Device and method for adaptation of target rate of video signals
EP1235392A1 (en) Data transmitting/receiving method, transmitting device, receiving device, transmitting/receiving system, and program
JP5109787B2 (ja) データ伝送システム、プログラム及び方法
US20120039391A1 (en) System and method for transmission of data signals over a wireless network
JP5084362B2 (ja) データ送信装置、及びデータ送受信システム
JP4930588B2 (ja) 中継装置、及び中継方法
KR20090118936A (ko) 미디어 서버로의 피드백 제공 방법
KR20130047642A (ko) 통신 시스템에서 데이터 송수신 장치 및 방법
JP4320024B2 (ja) 誤り訂正パケットを用いた伝送率制御方法およびそれを用いた通信装置
JP2012504352A (ja) 再送回数を動的に適合させる方法及び装置
Singh et al. Rate adaptation for conversational 3G video
JP2017069849A (ja) 映像制御装置、映像配信システムおよび映像制御方法
JP2010028378A (ja) 通信装置及び通信方法
Le et al. Reliable user datagram protocol for airborne network
Kim et al. A transmission control SCTP for real-time multimedia streaming
Kim et al. UDP-based extremely low latency streaming
TWI801835B (zh) 往返估算
JP2006109325A (ja) 通信システム、通信装置、およびプログラム
JP4909590B2 (ja) メディア信号の受信装置、送信装置及び送受信システム
JP5375416B2 (ja) ストリーム配信装置、ストリーム配信システム、ストリーム配信方法およびストリーム配信プログラム
JP2013118560A (ja) 送信装置、受信装置、送信方法、受信方法
JP2009044651A (ja) コンテンツ配信方法、コンテンツ配信システム、無線端末及びコンテンツ配信サーバ

Legal Events

Date Code Title Description
RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20100201

RD01 Notification of change of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7421

Effective date: 20100630

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110609

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120409

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120605

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120802

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

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

R151 Written notification of patent or utility model registration

Ref document number: 5094593

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

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

Free format text: PAYMENT UNTIL: 20150928

Year of fee payment: 3