JP2009272794A - データ伝送システム、プログラム及び方法 - Google Patents

データ伝送システム、プログラム及び方法 Download PDF

Info

Publication number
JP2009272794A
JP2009272794A JP2008120216A JP2008120216A JP2009272794A JP 2009272794 A JP2009272794 A JP 2009272794A JP 2008120216 A JP2008120216 A JP 2008120216A JP 2008120216 A JP2008120216 A JP 2008120216A JP 2009272794 A JP2009272794 A JP 2009272794A
Authority
JP
Japan
Prior art keywords
packet
storage unit
data storage
unit
data
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.)
Granted
Application number
JP2008120216A
Other languages
English (en)
Other versions
JP5109787B2 (ja
Inventor
Noriyuki Ihara
範幸 井原
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.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
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 Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2008120216A priority Critical patent/JP5109787B2/ja
Priority to US12/335,781 priority patent/US8347189B2/en
Publication of JP2009272794A publication Critical patent/JP2009272794A/ja
Application granted granted Critical
Publication of JP5109787B2 publication Critical patent/JP5109787B2/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
    • 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
    • H04L1/1838Buffer management for semi-reliable protocols, e.g. for less sensitive applications such as streaming video
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0045Arrangements at the receiver end
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056Systems characterized by the type of code used
    • H04L1/0071Use of interleaving
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1415Saving, restoring, recovering or retrying at system level
    • G06F11/1443Transmit or communication errors
    • 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/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • 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
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】少ない演算量でネットワーク使用帯域の増加を抑えつつ、パケットロスの状況に応じてリアルタイム性の高いデータの伝送を可能にする。
【解決手段】本データ伝送システムは、デコーダにおける連続パケット抜け数の分布とパケット抜け間隔の分布とを含むパケット抜け状況データを格納するパケット抜け状況データ格納部と、連続パケット抜け数の分布に基づき、FECパケットを生成する単位であるFECブロックの、パケットインターリーブを実施する単位に含まれる数であるインターリーブ単位を決定するインターリーブ単位決定処理部と、パケット抜け間隔の分布に基づき、FECブロックに含まれるデータ・パケットの数を決定するFECブロック単位決定処理部と、決定されたインターリーブパターンに基づき、デコーダに対するパケットの伝送順番を特定するパケット通信処理部とを有する。
【選択図】図8

Description

本発明は、IPネットワークなどの品質保証のないネットワーク上でリアルタイム性を必要とする音声や映像などのデータ伝送技術に関する。
従来、リアルタイムIP画像伝送におけるエラー訂正技術としては、FEC(Forward Error Correction)が実装されていた。FECでは通常のデータ・パケットとエラー訂正用のFECパケットとをエンコーダからデコーダに送信しているため、1パケット抜けに対してはデコーダ側で該当パケットの復元が可能である。ただし、1FECでカバーしているデータ・パケット中の2パケット以上のパケット抜けに対してはARQ(Automatic Repeat reQuest)で再送要求をエンコーダ側に送信し、エンコーダ側から紛失したパケットを取得するようにしている。このように、2パケット以上のパケット抜けに対しては、必ずARQで再送要求を送信することになるので、エンコーダ−デコーダ間で、余分な再送パケットが発生し、ネットワークに負荷がかかったり、デコーダ側のバッファリング時間が短い場合、再送可能回数が少なくデータ復元に失敗するといった問題があった。
なお、映像ストリーミング配信サービス及び双方向映像通信サービスを含む複数のサービスが混在する場合に、個々のサービス間で悪影響を与え合うことなく、サービスの品質を向上させることができるようにするための技術が存在している。具体的には、利用者端末の映像ストリーミング品質測定部が映像ストリーミングに関する品質パラメータを取得し、双方向映像通信品質測定部が双方向映像通信に関する品質パラメータを取得し、FEC品質測定部がFEC符号器/復号器による誤り訂正に関する品質パラメータ、及びRTPカプセル化を施した通信に関する品質パラメータを取得する。品質管理サーバの受信レート判断部が、品質パラメータを受信し、利用者端末の受信レートを判断する。そして、エンコードレート制御部が、受信レート判断部からの指示に従い、利用者端末が保持するエンコードレートを制御する。但し、パケットのインターリーブ伝送については考慮されていない。
また、FECとARQの双方をサポートするデコーダ装置等のパケット受信装置側において、パケットロスト発生時の再送要求の送信タイミングを制御して、不要な再送要求の送信を抑制しつつ、最適な遅延時間で映像や音声の再生を可能とするための技術が存在している。具体的には、パケットの欠落が検出された場合に、パケット受信部で次に受信される冗長パケットに基づいて欠落パケットを復元するためのエラー訂正処理を行なうエラー訂正部と、パケット送信装置に対して欠落パケットの再送要求を送信しうる再送要求送信部と、パケットの欠落が検出された場合に、所定時間内にエラー訂正部により欠落パケットを復元できるか否かに応じて再送要求送信部によるパケット送信装置への再送要求の送信タイミングを制御する再送要求制御部とを有する。しかしながら、パケットのインターリーブ伝送については考慮されていない。
さらに、大きな帯域幅遅延積をもつワイヤレスネットワークにおいてスケーラブル且つリライアブルなマルチキャストをサポートする技術が存在している。この技術では、同数のデータパケットの損失を被る種々の受信機からの確認応答パケットに、同じタイムスロットが割り当てられる。この方法は、前方誤り訂正(FEC)による回復、事前防御、フィードバック抑制及び衝突検出のようなその他の損失回復技術と組み合わせることができる。帯域幅の使用方法が受信機の個数ではなく伝送されたパケットの個数だけに関係するので、スケーラビリティが実現されるとされる。しかしながら、パケットのインターリーブ伝送については考慮されていない。
さらに、伝送遅延のゆらぎが大きく、パケット損失が避けられないパケット通信ネットワークにリアルタイム連続ストリームを伝送するシステムにおいて、パケット損失の再生機能への影響が抑制できる技術、また、最大許容遅延時間を越えて到着したパケットの廃棄が連続して起こった時に対応できるバッファリング量制御が可能な技術が存在している。具体的には、データを受信・再生する受信端末とネットワーク等を介して通信可能であり、メディアデータを入力・蓄積するメディア入力手段と、メディア入力手段から入力・蓄積したデータを圧縮するメディアデータ圧縮手段と、メディアデータ圧縮手段で圧縮されたメディアデータをパケットにして送出するパケット送出手段と、パケット廃棄情報を受信する受信手段と、パケット廃棄情報によって、送信データのクロスインタリーブを行うか否かを決定する送信モード決定手段と、送信データに対してクロスインタリーブ処理を行うクロスインタリーブ手段とを備え、パケット送出手段から送出した、クロスインタリーブ処理を行っていない送信データのパケットの到着状態の一つであるパケット廃棄情報を受信端末から受けとり、クロスインタリーブを行うと決定した場合、クロスインタリーブ処理を行ったデータのパケットを送出する。しかしながら、パケットのインターリーブについて具体的な調整については考慮されておらず、バッファリング時間などの受信側のデータに基づきインターリーブ・パターンを調整することも考慮されていない。
特開2006−66973号公報 特開2005−159433号公報 特表2007−510363号公報 特開平11−177623号公報
このような従来技術では、少ない演算量でネットワーク使用帯域の増加を抑えつつ、パケットロス(パケット抜け)の状況に応じてリアルタイム性の高いデータを伝送することはできない。
従って、本発明の目的は、少ない演算量でネットワーク使用帯域の増加を抑えつつ、パケットロスの状況に応じてリアルタイム性の高いデータの伝送を可能にするための技術を提供することである。
データ伝送システムは、デコーダにおける連続パケット抜け数の分布とパケット抜け間隔の分布とを含むパケット抜け状況データを格納するパケット抜け状況データ格納部と、パケット抜け状況データ格納部に格納されている連続パケット抜け数の分布に基づき、FEC(Forward Error Correction)パケットを生成する単位であるFECブロックの、パケットインターリーブを実施する単位に含まれる数であるインターリーブ単位を決定し、インターリーブパターンデータ格納部に格納するインターリーブ単位決定処理部と、パケット抜け状況データ格納部に格納されているパケット抜け間隔の分布に基づき、FECブロックに含まれるデータ・パケットの数を決定し、インターリーブパターンデータ格納部に格納するFECブロック決定処理部と、インターリーブパターンデータ格納部に格納されているデータに基づき、デコーダに対するパケットの伝送順番を特定し、当該パケットの伝送順番に従ってデコーダに対してパケットのインターリーブ伝送を実施するパケット通信処理部とを有する。
少ない演算量でネットワーク使用帯域の増加を抑えつつ、パケットロスの状況に応じてリアルタイム性の高いデータの伝送が可能となる。
図1に本発明の一実施の形態におけるシステム構成図を示す。例えばインターネットなどの品質保証のないネットワーク1に、エンコーダ100と、1又は複数のデコーダ200とが接続されている。
エンコーダ100は、デコーダ200に伝送すべきパケットを格納するパケットバッファ116と、デコーダ200に伝送すべきパケットをネットワーク1を介して送信するための処理を実施するパケット通信処理部111と、例えばデコーダ200で収集されたパケット抜け状況データを取得する(場合によってはパケットの再送要求からパケット抜け状況データを生成する)パケット抜け状況データ取得部112と、パケット抜け状況データ取得部112によって取得されたパケット抜け状況データを格納するパケット抜け状況データ格納部117と、パケット抜け状況データ格納部117に格納されているデータを用いてFECパケットを生成する単位であるFECブロックの、パケットインターリーブを実施する単位に含まれる数であるインターリーブ単位を決定するインターリーブ単位決定処理部113と、パケット抜け状況データ格納部117に格納されているデータを用いてFECブロックに含まれるデータ・パケットの数であるFECブロック単位を決定するFECブロック単位決定処理部114と、デコーダ200におけるバッファリング時間及びリオーダリング時間と通信帯域制限条件とを格納する通信条件データ格納部118と、通信条件データ格納部118に格納されているデータを用いてインターリーブ単位決定処理部113及びFECブロック単位決定処理部114で決定されたインターリーブパターンを調整する処理を実施するインターリーブパターン調整部115と、インターリーブ単位決定処理部113、FECブロック単位決定処理部114及びインターリーブパターン調整部115によって決定されたインターリーブパターンのデータを格納するインターリーブパターンデータ格納部119とを有する。
なお、パケット通信処理部111は、パケットバッファ116に格納されているパケットを、インターリーブパターンデータ格納部119に格納されているインターリーブパターンに従ってその送信順番を特定してネットワーク1に送出する。また、パケット通信処理部111は、インターリーブパターンデータ格納部119に格納されているインターリーブパターンに従って通常のパケットからFECパケットを生成するFEC符号化処理部1111を有する。FEC符号化処理及びFECブロック単位復元処理については、本実施の形態の主旨ではないので、これ以上述べない。
また、デコーダ200は、エンコーダ100からパケットを受信する際の処理を実施するパケット通信処理部211と、パケット通信処理部211により受信されたパケットのデータを格納するパケットバッファ213と、パケット抜け状況データを格納するパケット抜け状況データ格納部214と、バッファリング時間やリオーダリング時間などの通信条件データを格納する通信条件データ格納部215とを有する。
パケット通信処理部211は、通信条件データ格納部215に格納されている通信条件データをエンコーダ100に送信する。また、パケット通信処理部211は、通常のデータ・パケットの抜けが生じた場合にFECパケットを用いてパケット抜けが生じたパケットの復元処理を行うFEC復元処理部2111と、エンコーダ100からのパケットの受信状況からパケット抜け状況データを生成するパケット抜け状況データ生成部2112とを有する。
次に、図2乃至図16を用いて、図1に示したデータ伝送システムの処理内容を説明する。まず、データ伝送を必要とするデコーダ200のパケット通信処理部211は、通信条件データ格納部215に格納されている通信条件データ(バッファリング時間及びリオーダリング時間を含む)を含む受信要求をエンコーダ100にネットワーク1を介して送信する(ステップS1)。
エンコーダ100のパケット通信処理部111は、デコーダ200から、バッファリング時間及びリオーダリング時間を含む受信要求を受信し、デコーダ200のIDと共にバッファリング時間及びリオーダリング時間を、通信条件データ格納部118に格納する(ステップS3)。そして、パケット通信処理部111は、受信要求に対する受信確認ACKをデコーダ200に送信する(ステップS5)。デコーダ200のパケット通信処理部211は、エンコーダ100から受信確認ACKを受信する(ステップS7)。
また、エンコーダ100のパケット通信処理部111は、送信時刻Aを取得して当該送信時刻Aを含むRTCP SRパケットをデコーダ200に送信する(ステップS9)。デコーダ200のパケット通信処理部211は、エンコーダ100から送信時刻Aを含むRTCP SRパケットを受信し、送信時刻Aをメインメモリなどの記憶装置に格納すると共に、受信時刻Bを取得する(ステップS11)。ここで、5秒間計測して、5秒タイムアウトでの時刻Cを取得する(ステップS13)。そして、DLSR(=C−B)及びLSR(=A)を含むRTCP RRパケットを生成して、エンコーダ100に送信する(ステップS15)。
エンコーダ100のパケット通信処理部111は、デコーダ200から、DLSR及びLSRを含むRTCP RRパケットを受信し、DLSR及びLSRをメインメモリなどの記憶装置に格納すると共に、受信時刻Dを取得する(ステップS17)。そして、RTT=D−DLSR−LSRを算出して、当該RTTを含むRTCP APPパケットを生成して、デコーダ200に送信する(ステップS19)。
デコーダ200のパケット通信処理部211は、RTTを含むRTCP APPパケットを受信し(ステップS21)、RTTを例えば通信条件データ格納部215に格納する。この後の処理は端子A及びBを介して図3の処理に移行する。
図3の処理の説明に移行して、エンコーダ100のパケット通信処理部111は、伝送すべきパケットをはじめは通常の順番で送信する(ステップS23)。この際、FEC符号化処理部1111を動作させてもよいし、動作させなくとも良い。デコーダ200のパケット通信処理部211は、エンコーダ100から、パケットを受信し、パケットバッファ213に格納する(ステップS24)。パケットに含まれるデータを再生する再生処理部(図示せず)は、パケットバッファ213からデータを読み出して再生する。
このように、順次エンコーダ100からデコーダ200にパケットが送信されて、デコーダ200のパケット通信処理部211に含まれるパケット抜け状況データ生成部2112は、パケットの抜け状況に応じて、連続パケット抜け数及びパケット抜け間隔のデータを含むパケット抜け状況データを生成して、パケット抜け状況データ格納部214に蓄積してゆく(ステップS25)。
このステップS23乃至S25では、図4に示すような処理を行う。エンコーダ100のパケット通信処理部111は、例えばN番目のRTPパケットをデコーダに送信し、さらにN+1番目のRTPパケット、N+2番目のRTPパケットを送信する。N番目のRTPパケットは、デコーダ200のパケット通信処理部211により受信できたが、N+1番目のRTPパケットがネットワーク1でロスした場合、デコーダ200のパケット通信処理部211は、N+2番目のRTPパケットを受信した時点で、受信時刻Fを取得し、再生のための処理を開始する時刻G(=F+バッファリング時間)を算出する。この時刻Gは、N+1番目のRTPパケットを受信できなければあきらめる時刻でもある。
また、N+1番目のRTPパケットのロスを検出したことになるので、パケット抜け状況データ生成部2112は、これより前のパケット抜けとの間隔を特定し、パケット抜け状況データ格納部214に格納する。さらに連続パケット抜け数のカウントを開始する。同様に次のパケット抜けとの間隔のカウントも開始する。但し、本例では既にN+2番目のRTPパケットを受信しているので、連続パケット抜け数は「なし」となる。
パケット抜け状況データに含まれる連続パケット抜け数及びパケット抜け間隔については、図5に示すようにカウントされる。図5においてDxは、RTPパケットを表し、FxはFECパケットを表すものとする。図5の例では、D1、D2、D3、F1、D4、D5、D6、F2、D7、D8、D9、F3...という順番でパケットが送信され、D2及びD3と、D5及びD6でパケット抜けを検出したものとする。この場合、D2及びD3でのパケット抜けは、連続パケット抜け数が「2」と認識される。同様に、D5及びD6でのパケット抜けは、連続パケット抜け数が「2」と認識される。そして、これらのパケット抜けの間隔は、F1及びD4があるので、「2」と認識される。
このような連続パケット抜け数及びパケット抜け間隔とを計算して、パケット抜け状況データ格納部214に格納すると、パケット抜け状況データ格納部214には例えば図6に示すようなデータが格納される。図6の例では、測定時間(開始時間から終了時間)毎に、総パケット抜け数と、連続パケット抜け数の分布(2連続抜け回数、3連続抜け回数、...)と、パケット抜け間隔の分布(2パケット回数、3パケット回数、....)とが登録されるようになっている。すなわちパケット抜け状況データ生成部2112は、図6のテーブルにおける該当回数をインクリメントする。
そして、デコーダ200のパケット通信処理部211は、N+2番目のRTPパケットの受信時刻Fからリオーダリング時間計測し、リオーダリング時間経過までにN+1番目のRTPパケットを受信せず、FECパケットで復元できなければ、N+1番目のRTPパケットの再送を要求するRTCP APPパケットをエンコーダ100に送信する。さらに、RTTの計測を開始する。また、再送要求回数をカウントする。
エンコーダ100のパケット通信処理部111は、N+1番目のRTPパケットの再送を要求するRTCP APPパケットを、デコーダ200から受信すると、N+1番目のRTPパケットを再送する。ここでも、N+1番目のパケットはネットワーク1でロスしたものとする。そして、再送要求回数上限値に達しておらず且つ時間H(H=G−現時刻)がRTT以上ある場合は、N+1番目のパケットの再送を要求するRTCP APPパケットをエンコーダ100に送信する。
エンコーダ100のパケット通信処理部111は、N+1番目のRTPパケットの再送を要求するRTCP APPパケットを、デコーダ200から受信すると、N+1番目のRTPパケットを再送する。このような処理を繰り返す。そして、パケット抜け状況データ生成部2112は、連続パケット抜け数の分布及びパケット抜け間隔の分布を含むパケット抜け状況データをパケット抜け状況データ格納部214に蓄積してゆく。
なお、上で述べたように、FECパケット及び同一FECブロックの残余のパケットを用いることによって、FEC復元処理部2111によってロスしたパケットを復元できれば、再送を要求するRTCP APPパケットを送る必要はなくなる。
そして、デコーダ200のパケット通信処理部211は、所定時間毎にパケット抜け状況データをエンコーダ100に送信する(図3:ステップS27)。エンコーダ100のパケット抜け状況データ取得部112は、デコーダ200からパケット抜け状況データを受信すると、パケット抜け状況データ格納部117に蓄積してゆく(ステップS29)。図6に示すようなデータが、パケット抜け状況データ格納部117にも蓄積されてゆく。
この後、エンコーダ100では、図7乃至図13に示すような処理を実施する。ステップS29と同様に、デコーダ200から受信したパケット抜け状況データは、パケット抜け状況データ格納部117に蓄積される(ステップS51)。そして、エンコーダ100のパケット抜け状況データ取得部112は、パケット抜け状況データが一定時間分蓄積されたか、定期的に判断する(ステップS53)。まだ、デコーダ200についてのパケット抜け状況データが一定時間分蓄積されていない場合には、ステップS51に戻る。
一方、デコーダ200についてのパケット抜け状況データが一定時間分蓄積されている場合には、パケット抜け状況データ取得部112は、インターリーブ単位決定処理部113やFECブロック単位決定処理部114に対して処理開始を指示する。インターリーブ単位決定処理部113は、パケット抜け状況データ格納部117に格納されている、当該デコーダ200についての連続パケット抜け数の最頻値に従って、インターリーブ単位を選択し、インターリーブパターンデータ格納部119に格納する(ステップS55)。具体的には、連続パケット抜け数の最頻値が「3」である場合には、インターリーブ単位を「3」に設定する。すなわち、FECパケットを生成する元となるデータ・パケットを含むFECブロック3つをインターリーブするものと仮に決定する。インターリーブしなければ、1つのFECブロックで複数のパケット抜けが発生するが、このようにインターリーブすれば、可能な限り1FECブロックに1つのエラーになるようにすることができる。
さらに、FECブロック単位決定処理部114は、パケット抜け間隔の最頻値に従って、FECブロック単位を選択し、インターリーブパターンデータ格納部119に格納する(ステップS57)。具体的には、パケット抜け間隔の最頻値が「4」である場合には、1FECブロックのデータ・パケット数を「3」とするように仮に決定する。FECパケットの出現間隔とパケット抜け間隔の最頻値を併せておけば、復元できる可能性が高くなるからである。
上で述べた例のように、インターリーブ単位が「3」で、FECブロック単位が「3」であれば、図8に示すようなインターリーブパターンとなる。すなわち、通常であれば、データパケットD1乃至D3からFECパケットF1が構成されて、FECブロック1はこれらのパケットを含む。また、データパケットD4乃至D6からFECパケットF2が構成され、FECブロック2は、これらのパケットを含む。データパケットD7乃至D9からFECパケットF3が構成されて、FECブロック3はこれらのパケットを含む。
このようなパケット構成の場合、FECブロック1から1番目のパケットD1を取り出し、FECブロック2から2番目のパケットD5を取り出し、FECブロック3から3番目のパケットD9を取り出し、FECブロック1からFECパケットF1を取り出し、FECブロック2から1番目のパケットD4を取り出し、FECブロック3から2番目のパケットD8を取り出し、FECブロック1から3番目のパケットD3を取り出し、FECブロック2からFECパケットF2を取り出し、FECブロック3から1番目のパケットD7を取り出し、FECブロック1から2番目のパケットD2を取り出し、FECブロック2から3番目のパケットD6を取り出し、FECブロック3のFECパケットF3を取り出すようにする。
インターリーブパターン例の詳細を図9乃至図12に示す。図9は、インターリーブ単位が「2」であり、FECブロック単位が「1」である場合のインターリーブパターンを示す。図9の例では、1行目に、通常パケットの並びを表し、2行目に、FECブロック番号(「ブロック番号−ブロック内番号」で表す)を表し、3行目に、インターリーブ後のパケットの並びを表し、4行目にインターリーブ後のFECブロック番号を表し、Normal/Interleaveの別を表している。Normalは、通常パケットの並びと同じ並びであることを表し、Interleaveは、通常パケットの並びと異なる並びであることを表す。
このようなインターリーブパターンの場合、1パケットに1FECパケットが必要となるので、必要な伝送帯域は2倍になる。また、矢印で示すように、通常パケットの並びからすると、最大1パケット分遅延する。すなわち、最大パケット遅延時間は、1パケット受信する時間となる。
図10は、インターリーブ単位が「2」であり、FECブロック単位が「2」である場合のインターリーブパターンを示す。図10のテーブルは、図9のテーブル構成と同様である。このようなインターリーブパターンの場合、2パケットに1FECパケットが必要となるので、必要な伝送帯域は1.5倍となる。また、矢印で示すように、通常パケットの並びからすると、最大3パケット分遅延する。すなわち、最大パケット遅延時間は、3パケット受信する時間となる。
図11は、インターリーブ単位が「3」であり、FECブロック単位が「2」である場合のインターリーブパターンを示す。図11のテーブルは、図9のテーブル構成と同様である。このようなインターリーブパターンの場合、2パケットに1FECパケットが必要となるので、必要な伝送帯域は1.5倍となる。また、矢印で示すように、通常パケットの並びからすると、最大5パケット分遅延する。すなわち、最大パケット遅延時間は、5パケット受信する時間となる。このように、インターリーブ単位が増加すると、最大パケット遅延時間も長くなる。
図12は、インターリーブ単位が「3」であり、FECブロック単位が「3」である場合のインターリーブパターンを示す。図12のテーブルは、図9のテーブル構成と同様である。このようなインターリーブパターンの場合、3パケットに1FECパケットが必要となるので、必要な伝送帯域は1.33倍となる。また、矢印で示すように、通常パケットの並びからすると、最大8パケット分遅延する。すなわち、最大パケット遅延時間は、8パケット受信する時間となる。このように、FECブロック単位が増加すると、最大パケット遅延時間も長くなる。
最大パケット遅延時間についてのデータ(例えば遅延パケット数)及び必要伝送帯域についてのデータについては、インターリーブパターン毎に、例えば通信条件データ格納部118に格納しておき、それを参照して特定する。
図7の説明に戻って、次に、インターリーブパターン調整部115は、上で選択されたインターリーブパターンから特定される最大パケット遅延時間と、通信条件データ格納部118に格納されている、デコーダ200についてのバッファリング時間とを比較し、バッファリング時間より最大パケット遅延時間が長い場合には、FECブロック単位をバッファリング時間より最大パケット遅延時間が短くなるように減少させ、減少後のFECブロック単位をインターリーブパターンデータ格納部119に格納する(ステップS59)。
デコーダ200では、パケット抜けを検出した場合、バッファリング時間内であればARQの再送要求を行うが、バッファリング時間を超えた場合には、そのパケットはロスしたものとして再生処理(デコード)を行う。このため、エンコーダ100は、バッファリング時間を超える最大パケット遅延時間が生じるようなインターリーブを行えない。例えば、384Kbpsで1パケット1000バイトの場合、48パケット/秒であり、パケット間隔時間20.83msであり、8パケット遅延の場合の遅延時間は20.83ms×8=166.66msとなる。従って、バッファリング時間が166ms以下の場合、最大8パケット遅延するようなインターリーブパターンを選択することはできない。上で述べた例では、図12で示したようなインターリーブ単位が「3」でFECブロック単位が「3」というインターリーブパターンを選択することはできない。従って、FECブロック単位を下げ、インターリーブ単位が「3」でFECブロック単位が「2」というインターリーブパターンを選択する。
処理は、端子Cを介して図13の処理に移行する。インターリーブパターン調整部115は、上で選択されたインターリーブパターンから特定される必要帯域と、通信条件データ格納部118に格納されている、デコーダ200に対するデータ伝送における通信帯域制限条件とを比較し、必要帯域が通信帯域制限条件を満たしていない場合には、インターリーブパターンにおけるインターリーブ単位を下げ且つバッファリング時間を満たすようにFECブロック単位を決定し、インターリーブパターンデータ格納部119に格納する(ステップS61)。
例えば、インターリーブ単位が「3」でFECブロック単位が「2」というインターリーブパターンであると、必要帯域は1.5倍となる。ここで通信帯域制限条件が1.5倍未満であると、上記のようなインターリーブパターンを選択することはできない。従って、ステップS61では、次善の策として、インターリーブ単位を「2」に下げる。ここで、8パケット遅延未満で、必要帯域が1.5倍未満であるFECブロック単位を選択する。FECブロック単位が「2」であれば必ず必要帯域は1.5倍となるので、FECブロック単位を「3」以上に増加させる必要がある。さらに、8パケット遅延未満である必要があり、インターリーブ単位「2」でFECブロック単位「3」で最大5パケット遅延となるのでこのインターリーブパターンが選択される。
さらに、インターリーブパターン調整部115は、上で選択されたインターリーブパターンから特定される最大パケット遅延時間と、通信条件データ格納部118に格納されている、デコーダ200におけるリオーダリング時間とを比較して、可能であれば、最大パケット遅延時間がリオーダリング時間内になるようにFECブロック単位を変更して、インターリーブパターンデータ格納部119に格納する(ステップS63)。
上で述べたように、デコーダ200側でパケット抜けの存在を検出すると、リオーダリング時間経過後に再送要求をエンコーダ100側に送信するようになっている。従って、リオーダリング時間内のインターリーブであれば、デコーダ200は再送要求をエンコーダ100に送信することはない。再送要求の分だけネットワーク1の帯域を消費するので、可能であれば最大パケット遅延時間がリオーダリング時間であることが好ましい。但し、コマ落ちを生ずるバッファリング時間とは異なり、再生品質上の問題はないので、「可能な限り」リオーダリング時間内に最大パケット遅延時間を抑えるものとする。なお、上で述べた例では、これ以上FECブロック単位を下げると通信帯域制限条件を満たせなくなるので、ここではステップS63をスキップする。
このようなインターリーブパターンの決定処理を行った後に、パケット通信処理部111は、デコーダ200側でパケット抜け状況データを正しく生成できるように、インターリーブパターンデータ格納部119に格納されているインターリーブパターンを表すデータをデコーダ200に送信する(ステップS65)。その後、インターリーブパターンデータ格納部119に格納されているインターリーブパターンに従って、インターリーブを伴うパケット送信を実施し始める(ステップS66)。
デコーダ200のパケット通信処理部211は、インターリーブパターンを表すデータを受信すると、例えばメインメモリなどの記憶装置に格納すると共に、このデータに基づき、パケット抜けを検出する。すなわち、インターリーブ単位が「2」でFECブロック単位が「3」である場合には、D1、D5、D9、F1、D4、D8、D3、F2といった順番でパケットが送られてくるので、例えばD9及びF1を受信できない場合には、3番目及び4番目のパケットが連続して抜けたと判断する。そして、パケット抜け状況データ生成部2112は、検出したパケット抜け状況をパケット抜け状況データ格納部214に反映する。
そして、処理終了となるまで(例えばエンコーダ100からデコーダ200へのデータ伝送が終了するまで)、端子Dを介してステップS55からステップS66までを繰り返す(ステップS67)。
このような処理を実施すれば、上で述べたようにパケット抜け状況に応じて、ロス・パケットを可能な限りデコーダ200側で復元できるような態様でエンコーダ100からパケットを送信できるようになる。
例えば、図14(a)に示すように、通常の並びでパケットを送信しており、D4、D5及びD6でロスが生じた場合、それらについてはFECパケットF2だけでは復元できない。図14(b)のようにインターリーブを行ってパケットを送信していれば、同じ位置でロスが生じても、D4、D8及びD3といったバラバラのFECブロックのパケットが1つロスしたことになるので、FEC復元処理部2111によって該当する残余のパケットでロスしたパケットを再送要求を行うことなく復元することができる。
なお、デコーダ200側におけるパケット抜け状況データの蓄積の際には、連続パケット抜け数のカウント最大値及びパケット抜け間隔のカウント最大値を設定しておき、それを超える場合にはカウントしないような設定をしておく。すなわち、インターリーブ可能なFECブロック数に制限がある場合には、当該FECブロック数(例えば5)及びFECブロック単位+1(例えば4+1=5)の積(例えば25)を超えるような連続パケット抜けについてはカウントしない。さらに、デコーダ200側で対応可能なFECブロックの最大サイズを超えるようなパケット抜け間隔についてはカウントしない。
上で述べた例では、デコーダ200側にパケット抜け状況データ生成部2112を設けて、連続パケット抜け数の分布データ及びパケット抜け間隔の分布データを生成し、エンコーダ100側に送信していたが、必ずしもこのようなデータをデコーダ200側で生成する必要はない。パケットの送信順序についてはエンコーダ100で分かっているので、ARQの再送要求を受信して、再送要求の対象であるパケットが特定できれば、エンコーダ100側でもパケット抜け状況データを生成することができる。
すなわち図3のステップS27及びS29の代わりに、デコーダ200のパケット通信処理部211は、パケット抜けを検出すると、通常のとおり特定のパケットの再送を要求するRTCP APPパケットをエンコーダ100に送信する(図15:ステップS31)。エンコーダ100のパケット通信処理部111は、デコーダ200から、特定のパケットの再送を要求するRTCP APPパケットを受信し(ステップS33)、特定のパケットを指定してパケット抜け状況データ取得部112に出力する。パケット抜け状況データ取得部112は、インターリーブパターンデータ格納部119に格納されているインターリーブパターン又はインターリーブしていない場合にはその旨のデータに従って、パケット抜け状況を特定してパケット抜け状況データを生成し、パケット抜け状況データ格納部117に蓄積する(ステップS35)。
例えば、図16(a)に示すような順番でパケットを送信していて(すなわちインターリーブ無しでFECブロック単位「3」)、図16(b)に示すように、D2及びD3と、D5及びD6とについて再送要求を受信した場合、例えばパケット抜け状況データ取得部112は、ロスしたパケットと送信順番と照らし合わせれば、連続パケット抜け数「2」が2回、パケット抜け間隔「2」が1回ということを特定し、パケット抜け状況データ格納部117に蓄積する。
このようにすれば、デコーダ200側の構成をあまり変更せずに、パケット抜け状況データをエンコーダ100側に蓄積することができ、それに応じて適切なパケットインターリーブを実施できる。よって、ネットワーク使用帯域の増加を抑えつつリアルタイム性の高いデータ伝送を適切に実施することができる。
以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、図1に示した機能ブロックは一例であって、プログラムモジュール構成と一致しない場合もある。図1に示した機能ブロックは、プロセッサとプログラムの組み合わせで構成される場合もあれば、専用の半導体チップを構成するようにしても良い。
上で述べた実施の形態をまとめると以下のとおりになる。すなわち、データ伝送システムは、デコーダにおける連続パケット抜け数の分布とパケット抜け間隔の分布とを含むパケット抜け状況データを格納するパケット抜け状況データ格納部と、パケット抜け状況データ格納部に格納されている連続パケット抜け数の分布に基づき、FEC(Forward Error Correction)パケットを生成する単位であるFECブロックの、パケットインターリーブを実施する単位に含まれる数であるインターリーブ単位を決定し、インターリーブパターンデータ格納部に格納するインターリーブ単位決定処理部と、パケット抜け状況データ格納部に格納されているパケット抜け間隔の分布に基づき、FECブロックに含まれるデータ・パケットの数を決定し、インターリーブパターンデータ格納部に格納するFECブロック決定処理部と、インターリーブパターンデータ格納部に格納されているデータに基づき、デコーダに対するパケットの伝送順番を特定し、当該パケットの伝送順番に従ってデコーダに対してパケットのインターリーブ伝送を実施するパケット通信処理部とを有する。
このように連続パケット抜け数の分布(例えば特徴的な統計量(例えば最頻数や平均値)に応じてインターリーブ単位を決定すると共にパケット抜け間隔の分布(例えば特徴的な統計量(最頻値や平均値など))に応じてFECブロックに含まれるデータ・パケットの数を決定することによって、少ない演算量でネットワーク使用帯域の増加を抑えつつ、パケットロスの状況に応じた適切なデータ伝送が可能となる。
また、本データ伝送システムにおいて、デコーダにおけるバッファリング時間を含む通信条件データを格納する通信条件データ格納部と、通信条件データ格納部に格納されているバッファリング時間と、インターリーブパターンデータ格納部に格納されているデータから特定される最大パケット遅延時間とを比較して、最大パケット遅延時間がバッファリング時間を超える場合には、インターリーブパターンデータ格納部に格納されているFECブロックに含まれるデータ・パケットの数を、最大パケット遅延時間がバッファリング時間を超えないように減少させて、インターリーブパターンデータ格納部に格納する調整部とをさらに有するようにしてもよい。このようにすれば、コマ落ち再生を防止しつつ、パケットの再送要求の送出頻度を下げることができ、ネットワーク使用帯域の増加を抑えることができる。
また、上で述べた通信条件データが、通信帯域制限条件を含むようにしてもよい。その場合、上で述べた調整部が、通信条件データ格納部に格納されている通信帯域制限条件と、インターリーブパターンデータ格納部に格納されているデータから特定される必要帯域とを比較して、必要帯域が通信帯域制限条件を満たさない場合、インターリーブパターンデータ格納部に格納されているインターリーブ単位を減少させ、バッファリング時間の条件及び通信条件制限条件を満たすようにFECブロックに含まれるデータ・パケットの数(例えば最大数)を特定し、インターリーブパターンデータ格納部に格納するものである。このようにすれば、ネットワーク使用帯域を通信帯域制限条件に合わせることができるようになる。
さらに、上で述べた通信条件データが、リオーダリング時間を含むようにしてもよい。その場合、上で述べた調整部が、通信条件データ格納部に格納されているリオーダリング時間と、インターリーブパターンデータ格納部に格納されているデータから特定される最大パケット遅延時間とを比較して、最大パケット遅延時間がリオーダリング時間を超えている場合には、通信帯域制限条件を満たすようにFECブロックに含まれるデータ・パケットの数を特定し、インターリーブパターンデータ格納部に格納するようにする。このようにすれば、パケットの再送要求の送信頻度を下げることができるようになる。但し、バッファリング時間内に不足パケットを取得できなければ、コマ落ち再生が発生するが、リオーダリング時間の要求を満たさなくとも、コマ落ち再生は発生しないので、必ずしも本処理を実施しなくとも良い。
さらに、本データ伝送システムにおいて、デコーダからパケット抜け状況データを受信し、パケット抜け状況データ格納部に格納する手段をさらに有するようにしてもよい。デコーダ側に、パケット抜け状況データの生成部を用意できる場合には、エンコーダ側の構成は簡単になる。なお、パケットインターリーブを実施した後には、当該インターリーブパターンのデータをデコーダ側に通知して、パケット抜け状況データを正しく生成できるようにする必要がある。
また、本データ伝送システムにおいて、デコーダから特定パケットの再送要求を受信し、当該特定パケットの送信順番からパケット抜け状況データを生成し、パケット抜け状況データ格納部に格納する手段をさらに有するようにしてもよい。このようにすれば、デコーダ側の変更を少なくすることができる。
なお、上で述べた処理をエンコーダに実行させるためのプログラムを作成することができ、このプログラムは、例えばフレキシブルディスク、CD−ROM、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介してデジタル信号として配信される場合もある。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。
また、処理フローについては直線的に示した部分についても、処理結果が変わらなければ並列的に実施しても良いし、また処理順番を入れ替えても良い。
(付記1)
デコーダにおける連続パケット抜け数の分布とパケット抜け間隔の分布とを含むパケット抜け状況データを格納するパケット抜け状況データ格納部と、
前記パケット抜け状況データ格納部に格納されている前記連続パケット抜け数の分布に基づき、FEC(Forward Error Correction)パケットを生成する単位であるFECブロックの、パケットインターリーブを実施する単位に含まれる数であるインターリーブ単位を決定し、インターリーブパターンデータ格納部に格納するインターリーブ単位決定処理部と、
前記パケット抜け状況データ格納部に格納されている前記パケット抜け間隔の分布に基づき、前記FECブロックに含まれるデータ・パケットの数を決定し、前記インターリーブパターンデータ格納部に格納するFECブロック決定処理部と、
前記インターリーブパターンデータ格納部に格納されているデータに基づき、前記デコーダに対するパケットの伝送順番を特定し、当該パケットの伝送順番に従って前記デコーダに対してパケットのインターリーブ伝送を実施するパケット通信処理部と、
を有するデータ伝送システム。
(付記2)
前記デコーダにおけるバッファリング時間を含む通信条件データを格納する通信条件データ格納部と、
前記通信条件データ格納部に格納されている前記バッファリング時間と、前記インターリーブパターンデータ格納部に格納されているデータから特定される最大パケット遅延時間とを比較して、前記最大パケット遅延時間が前記バッファリング時間を超える場合には、前記インターリーブパターンデータ格納部に格納されている前記FECブロックに含まれるデータ・パケットの数を、前記最大パケット遅延時間が前記バッファリング時間を超えないように減少させて、前記インターリーブパターンデータ格納部に格納する調整部と、
をさらに有する付記1記載のデータ伝送システム。
(付記3)
前記通信条件データが、通信帯域制限条件を含み、
前記調整部が、
前記通信条件データ格納部に格納されている前記通信帯域制限条件と、前記インターリーブパターンデータ格納部に格納されているデータから特定される必要帯域とを比較して、前記必要帯域が前記通信帯域制限条件を満たさない場合、前記インターリーブパターンデータ格納部に格納されている前記インターリーブ単位を減少させ、前記バッファリング時間の条件及び前記通信条件制限条件を満たすように前記FECブロックに含まれるデータ・パケットの数を特定し、前記インターリーブパターンデータ格納部に格納する
付記2記載のデータ伝送システム。
(付記4)
前記通信条件データが、リオーダリング時間を含み、
前記調整部が、
前記通信条件データ格納部に格納されている前記リオーダリング時間と、前記インターリーブパターンデータ格納部に格納されているデータから特定される最大パケット遅延時間とを比較して、前記最大パケット遅延時間が前記リオーダリング時間を超えてる場合には、前記通信帯域制限条件を満たすように前記FECブロックに含まれるデータ・パケットの数を特定し、前記インターリーブパターンデータ格納部に格納する
付記3記載のデータ伝送システム。
(付記5)
前記デコーダから前記パケット抜け状況データを受信し、前記パケット抜け状況データ格納部に格納する手段
をさらに有する付記1記載のデータ伝送システム。
(付記6)
前記デコーダから特定パケットの再送要求を受信し、当該特定パケットの送信順番からパケット抜け状況データを生成し、前記パケット抜け状況データ格納部に格納する手段
をさらに有する付記1記載のデータ伝送システム。
(付記7)
デコーダにおける連続パケット抜け数の分布とパケット抜け間隔の分布とを含むパケット抜け状況データをパケット抜け状況データ格納部に格納するステップと、
前記パケット抜け状況データ格納部に格納されている前記連続パケット抜け数の分布に基づき、FEC(Forward Error Correction)パケットを生成する単位であるFECブロックの、パケットインターリーブを実施する単位に含まれる数であるインターリーブ単位を決定し、インターリーブパターンデータ格納部に格納するインターリーブ単位決定処理ステップと、
前記パケット抜け状況データ格納部に格納されている前記パケット抜け間隔の分布に基づき、前記FECブロックに含まれるデータ・パケットの数を決定し、前記インターリーブパターンデータ格納部に格納するFECブロック決定処理ステップと、
前記インターリーブパターンデータ格納部に格納されているデータに基づき、前記デコーダに対するパケットの伝送順番を特定し、当該パケットの伝送順番に従って前記デコーダに対するパケットのインターリーブ伝送を実施するパケット通信処理ステップと、
を、エンコーダに実行させるためのデータ伝送プログラム。
(付記8)
デコーダにおける連続パケット抜け数の分布とパケット抜け間隔の分布とを含むパケット抜け状況データをパケット抜け状況データ格納部に格納するステップと、
前記パケット抜け状況データ格納部に格納されている前記連続パケット抜け数の分布に基づき、FEC(Forward Error Correction)パケットを生成する単位であるFECブロックの、パケットインターリーブを実施する単位に含まれる数であるインターリーブ単位を決定し、インターリーブパターンデータ格納部に格納するインターリーブ単位決定処理ステップと、
前記パケット抜け状況データ格納部に格納されている前記パケット抜け間隔の分布に基づき、前記FECブロックに含まれるデータ・パケットの数を決定し、前記インターリーブパターンデータ格納部に格納するFECブロック決定処理ステップと、
前記インターリーブパターンデータ格納部に格納されているデータに基づき、前記デコーダに対するパケットの伝送順番を特定し、当該パケットの伝送順番に従って前記デコーダに対するパケットのインターリーブ伝送を実施するパケット通信処理ステップと、
を含み、エンコーダに実行されるデータ伝送方法。
本発明の実施の形態に係るシステム概要図である。 本発明の実施の形態に係る処理フローを示す図である。 本発明の実施の形態に係る処理フローを示す図である。 本発明の実施の形態に係る処理フローを示すシーケンス図である。 連続パケット抜け数及びパケット抜け間隔のカウント例を示す図である。 パケット抜け状況データの例を示す図である。 本発明の実施の形態に係る処理フローを示す図である。 インターリーブパターンを説明するための図である。 インターリーブ単位が「2」であり、FECブロック単位が「1」である場合のインターリーブパターンを示す図である。 インターリーブ単位が「2」であり、FECブロック単位が「2」である場合のインターリーブパターンを示す図である。 インターリーブ単位が「3」であり、FECブロック単位が「2」である場合のインターリーブパターンを示す図である。 インターリーブ単位が「3」であり、FECブロック単位が「3」である場合のインターリーブパターンを示す図である。 本発明の実施の形態に係る処理フローを示す図である。 本発明の実施の形態に係る効果を説明するための図である。 本発明の別の実施の形態の処理フローの一部を示すための図である。 エンコーダにおけるパケット抜け状況データの生成について説明するための図である。
符号の説明
100 エンコーダ
111 パケット通信処理部 112 パケット抜け状況データ取得部
113 インターリーブ単位決定処理部 114 FECブロック単位決定処理部
115 インターリーブパターン調整部 116 パケットバッファ
117 パケット抜け状況データ格納部 118 通信条件データ格納部
119 インターリーブパターンデータ格納部
1111 FEC符号化処理部
200 デコーダ
211 パケット通信処理部 213 パケットバッファ
214 パケット抜け状況データ格納部
215 通信条件データ格納部
2111 FEC復元処理部
2112 パケット抜け状況データ生成部

Claims (7)

  1. デコーダにおける連続パケット抜け数の分布とパケット抜け間隔の分布とを含むパケット抜け状況データを格納するパケット抜け状況データ格納部と、
    前記パケット抜け状況データ格納部に格納されている前記連続パケット抜け数の分布に基づき、FEC(Forward Error Correction)パケットを生成する単位であるFECブロックの、パケットインターリーブを実施する単位に含まれる数であるインターリーブ単位を決定し、インターリーブパターンデータ格納部に格納するインターリーブ単位決定処理部と、
    前記パケット抜け状況データ格納部に格納されている前記パケット抜け間隔の分布に基づき、前記FECブロックに含まれるデータ・パケットの数を決定し、前記インターリーブパターンデータ格納部に格納するFECブロック決定処理部と、
    前記インターリーブパターンデータ格納部に格納されているデータに基づき、前記デコーダに対するパケットの伝送順番を特定し、当該パケットの伝送順番に従って前記デコーダに対してパケットのインターリーブ伝送を実施するパケット通信処理部と、
    を有するデータ伝送システム。
  2. 前記デコーダにおけるバッファリング時間を含む通信条件データを格納する通信条件データ格納部と、
    前記通信条件データ格納部に格納されている前記バッファリング時間と、前記インターリーブパターンデータ格納部に格納されているデータから特定される最大パケット遅延時間とを比較して、前記最大パケット遅延時間が前記バッファリング時間を超える場合には、前記インターリーブパターンデータ格納部に格納されている前記FECブロックに含まれるデータ・パケットの数を、前記最大パケット遅延時間が前記バッファリング時間を超えないように減少させて、前記インターリーブパターンデータ格納部に格納する調整部と、
    をさらに有する請求項1記載のデータ伝送システム。
  3. 前記通信条件データが、通信帯域制限条件を含み、
    前記調整部が、
    前記通信条件データ格納部に格納されている前記通信帯域制限条件と、前記インターリーブパターンデータ格納部に格納されているデータから特定される必要帯域とを比較して、前記必要帯域が前記通信帯域制限条件を満たさない場合、前記インターリーブパターンデータ格納部に格納されている前記インターリーブ単位を減少させ、前記バッファリング時間の条件及び前記通信条件制限条件を満たすように前記FECブロックに含まれるデータ・パケットの数を特定し、前記インターリーブパターンデータ格納部に格納する
    請求項2記載のデータ伝送システム。
  4. 前記通信条件データが、リオーダリング時間を含み、
    前記調整部が、
    前記通信条件データ格納部に格納されている前記リオーダリング時間と、前記インターリーブパターンデータ格納部に格納されているデータから特定される最大パケット遅延時間とを比較して、前記最大パケット遅延時間が前記リオーダリング時間を超えている場合には、前記通信帯域制限条件を満たすように前記FECブロックに含まれるデータ・パケットの数を特定し、前記インターリーブパターンデータ格納部に格納する
    請求項3記載のデータ伝送システム。
  5. 前記デコーダから特定パケットの再送要求を受信し、当該特定パケットの送信順番からパケット抜け状況データを生成し、前記パケット抜け状況データ格納部に格納する手段
    をさらに有する請求項1記載のデータ伝送システム。
  6. デコーダにおける連続パケット抜け数の分布とパケット抜け間隔の分布とを含むパケット抜け状況データをパケット抜け状況データ格納部に格納するステップと、
    前記パケット抜け状況データ格納部に格納されている前記連続パケット抜け数の分布に基づき、FEC(Forward Error Correction)パケットを生成する単位であるFECブロックの、パケットインターリーブを実施する単位に含まれる数であるインターリーブ単位を決定し、インターリーブパターンデータ格納部に格納するインターリーブ単位決定処理ステップと、
    前記パケット抜け状況データ格納部に格納されている前記パケット抜け間隔の分布に基づき、前記FECブロックに含まれるデータ・パケットの数を決定し、前記インターリーブパターンデータ格納部に格納するFECブロック決定処理ステップと、
    前記インターリーブパターンデータ格納部に格納されているデータに基づき、前記デコーダに対するパケットの伝送順番を特定し、当該パケットの伝送順番に従って前記デコーダに対するパケットのインターリーブ伝送を実施するパケット通信処理ステップと、
    を、エンコーダに実行させるためのデータ伝送プログラム。
  7. デコーダにおける連続パケット抜け数の分布とパケット抜け間隔の分布とを含むパケット抜け状況データをパケット抜け状況データ格納部に格納するステップと、
    前記パケット抜け状況データ格納部に格納されている前記連続パケット抜け数の分布に基づき、FEC(Forward Error Correction)パケットを生成する単位であるFECブロックの、パケットインターリーブを実施する単位に含まれる数であるインターリーブ単位を決定し、インターリーブパターンデータ格納部に格納するインターリーブ単位決定処理ステップと、
    前記パケット抜け状況データ格納部に格納されている前記パケット抜け間隔の分布に基づき、前記FECブロックに含まれるデータ・パケットの数を決定し、前記インターリーブパターンデータ格納部に格納するFECブロック決定処理ステップと、
    前記インターリーブパターンデータ格納部に格納されているデータに基づき、前記デコーダに対するパケットの伝送順番を特定し、当該パケットの伝送順番に従って前記デコーダに対するパケットのインターリーブ伝送を実施するパケット通信処理ステップと、
    を含み、エンコーダに実行されるデータ伝送方法。
JP2008120216A 2008-05-02 2008-05-02 データ伝送システム、プログラム及び方法 Expired - Fee Related JP5109787B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2008120216A JP5109787B2 (ja) 2008-05-02 2008-05-02 データ伝送システム、プログラム及び方法
US12/335,781 US8347189B2 (en) 2008-05-02 2008-12-16 Data transmission system, program and method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008120216A JP5109787B2 (ja) 2008-05-02 2008-05-02 データ伝送システム、プログラム及び方法

Publications (2)

Publication Number Publication Date
JP2009272794A true JP2009272794A (ja) 2009-11-19
JP5109787B2 JP5109787B2 (ja) 2012-12-26

Family

ID=41257933

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008120216A Expired - Fee Related JP5109787B2 (ja) 2008-05-02 2008-05-02 データ伝送システム、プログラム及び方法

Country Status (2)

Country Link
US (1) US8347189B2 (ja)
JP (1) JP5109787B2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015115728A (ja) * 2013-12-11 2015-06-22 日本電信電話株式会社 データ送信装置、前方誤り訂正方法、及びプログラム

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5109787B2 (ja) * 2008-05-02 2012-12-26 富士通株式会社 データ伝送システム、プログラム及び方法
US9026610B2 (en) * 2009-02-12 2015-05-05 France Telecom Method of collecting real time data
CN101902315B (zh) * 2009-06-01 2013-04-17 华为技术有限公司 基于前向纠错的重传方法、设备和通信系统
JP5506362B2 (ja) * 2009-12-15 2014-05-28 キヤノン株式会社 送信装置、送信方法
JP5533322B2 (ja) * 2010-06-18 2014-06-25 富士通株式会社 データ転送装置、データ転送方法及びデータ転送プログラム
US9705654B2 (en) * 2011-11-08 2017-07-11 Apple Inc. Methods and apparatus for an extensible and scalable control channel for wireless networks
CN103888215B (zh) * 2012-12-21 2017-11-28 华为技术有限公司 数据传输方法、装置及通信系统
GB2521883B (en) * 2014-05-02 2016-03-30 Imagination Tech Ltd Media controller
EP3244623A1 (en) 2016-05-13 2017-11-15 Thomson Licensing Method and apparatus for bandwidth optimization using staggercast
CN106160953B (zh) * 2016-07-06 2019-04-16 四川大学 一种基于学习型能效模型的传输方法
US10567102B2 (en) * 2017-02-06 2020-02-18 Valens Semiconductor Ltd. Efficient double parity forward error correction on a communication network

Citations (5)

* 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 デジタルデータ通信方法およびデジタルデータ通信制御システム
JP2004215224A (ja) * 2002-12-20 2004-07-29 Nippon Telegr & Teleph Corp <Ntt> 符号誤り訂正方法、符号誤り訂正システム、プログラム及びそのプログラムを記録した記録媒体
JP2006086941A (ja) * 2004-09-17 2006-03-30 Matsushita Electric Ind Co Ltd 送信方法と送信装置及び受信方法と受信装置
JP2007074152A (ja) * 2005-09-05 2007-03-22 Nippon Telegr & Teleph Corp <Ntt> 品質測定方法及び装置及び符号誤り訂正方法及びシステム及びプログラム
JP2007324876A (ja) * 2006-05-31 2007-12-13 Ntt Communications Kk データ送信装置、データ受信装置、データ送信方法、データ受信方法、及びプログラム

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB8616616D0 (en) * 1986-07-08 1986-08-13 Philips Nv Transmission system
JP2945007B2 (ja) * 1987-09-29 1999-09-06 ソニー株式会社 データ伝送方法
US5457701A (en) * 1994-01-06 1995-10-10 Scientific-Atlanta, Inc. Method for indicating packet errors in a packet-based multi-hop communications system
JP3761635B2 (ja) * 1996-07-12 2006-03-29 株式会社ダックス メモリボード、メモリアクセス方法及びメモリアクセス装置
JP3734946B2 (ja) 1997-12-15 2006-01-11 松下電器産業株式会社 データ送出装置、データ受信装置及びデータ伝送装置
US6490705B1 (en) * 1998-10-22 2002-12-03 Lucent Technologies Inc. Method and apparatus for receiving MPEG video over the internet
US6292918B1 (en) * 1998-11-05 2001-09-18 Qualcomm Incorporated Efficient iterative decoding
US6378101B1 (en) * 1999-01-27 2002-04-23 Agere Systems Guardian Corp. Multiple program decoding for digital audio broadcasting and other applications
AU751376B2 (en) * 1999-07-08 2002-08-15 Samsung Electronics Co., Ltd. Apparatus and method for controlling a demultiplexer and a multiplexer used for rate matching in a mobile communication system
AU2002319335B2 (en) * 2002-08-13 2008-12-04 Nokia Corporation Symbol interleaving
JP4558739B2 (ja) 2003-10-28 2010-10-06 株式会社エヌ・ティ・ティ・ドコモ マルチキャストサービスを提供する方法
JP4328602B2 (ja) * 2003-11-20 2009-09-09 富士通株式会社 パケットエラー訂正装置及び方法
US7542435B2 (en) * 2004-05-12 2009-06-02 Nokia Corporation Buffer level signaling for rate adaptation in multimedia streaming
JP4283186B2 (ja) 2004-08-24 2009-06-24 日本電信電話株式会社 双方向映像通信品質制御システム、利用者端末、品質管理サーバ及びプログラム
KR101131323B1 (ko) * 2004-11-30 2012-04-04 삼성전자주식회사 이동통신 시스템에서 채널 인터리빙 장치 및 방법
US7739580B1 (en) * 2005-02-17 2010-06-15 Kencast, Inc. System, method and apparatus for reducing blockage losses on information distribution networks
WO2008001580A1 (fr) * 2006-06-29 2008-01-03 Nec Corporation Dispositif de communication et procédé
KR101435830B1 (ko) * 2007-06-20 2014-08-29 엘지전자 주식회사 인터리빙 수행 방법
KR101133907B1 (ko) * 2007-07-06 2012-04-12 주식회사 코아로직 디인터리브 장치와 방법 및 인터리빙 인덱스 산출장치 및방법과 그 기록매체
JP2009033622A (ja) * 2007-07-30 2009-02-12 Kyocera Corp Ofdm送信装置及びofdm受信装置並びにインターリーブ方法
JP2009033623A (ja) * 2007-07-30 2009-02-12 Kyocera Corp Ofdm送信装置及びofdm受信装置並びにインターリーブ方法
US8145975B2 (en) * 2008-02-28 2012-03-27 Ip Video Communications Corporation Universal packet loss recovery system for delivery of real-time streaming multimedia content over packet-switched networks
JP5109787B2 (ja) * 2008-05-02 2012-12-26 富士通株式会社 データ伝送システム、プログラム及び方法
US8345617B2 (en) * 2009-08-24 2013-01-01 Qualcomm Incorporated Sending an uplink order to active set base stations

Patent Citations (5)

* 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 デジタルデータ通信方法およびデジタルデータ通信制御システム
JP2004215224A (ja) * 2002-12-20 2004-07-29 Nippon Telegr & Teleph Corp <Ntt> 符号誤り訂正方法、符号誤り訂正システム、プログラム及びそのプログラムを記録した記録媒体
JP2006086941A (ja) * 2004-09-17 2006-03-30 Matsushita Electric Ind Co Ltd 送信方法と送信装置及び受信方法と受信装置
JP2007074152A (ja) * 2005-09-05 2007-03-22 Nippon Telegr & Teleph Corp <Ntt> 品質測定方法及び装置及び符号誤り訂正方法及びシステム及びプログラム
JP2007324876A (ja) * 2006-05-31 2007-12-13 Ntt Communications Kk データ送信装置、データ受信装置、データ送信方法、データ受信方法、及びプログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015115728A (ja) * 2013-12-11 2015-06-22 日本電信電話株式会社 データ送信装置、前方誤り訂正方法、及びプログラム

Also Published As

Publication number Publication date
US20090276678A1 (en) 2009-11-05
JP5109787B2 (ja) 2012-12-26
US8347189B2 (en) 2013-01-01

Similar Documents

Publication Publication Date Title
JP5109787B2 (ja) データ伝送システム、プログラム及び方法
JP4116470B2 (ja) メディア・ストリーミング配信システム
KR101242663B1 (ko) 패킷 송신 장치, 통신 시스템 및 컴퓨터 판독가능한 기록매체
US7320099B2 (en) Method and apparatus for generating error correction data, and a computer-readable recording medium recording an error correction data generating program thereon
KR100634946B1 (ko) 패킷 에러 정정 장치 및 방법
US7430219B2 (en) Method for transporting media, transmitter and receiver therefor
US9565482B1 (en) Adaptive profile switching system and method for media streaming over IP networks
US8566662B2 (en) Transmission apparatus, receiving apparatus, and method
US9781488B2 (en) Controlled adaptive rate switching system and method for media streaming over IP networks
JP2005198191A (ja) 伝送装置、伝送制御プログラム、及び伝送方法
JP3730974B2 (ja) メディア伝送方法及びその送信装置
JP2010119133A (ja) パケット送信装置、通信システム及びプログラム
WO2005122455A1 (ja) 双方向通信方法と装置、システムならびにプログラム
KR100851918B1 (ko) 네트워크 적응형 데이터 전송 방법, 이를 위한 데이터 전송시스템, 데이터 송신 장치, 및 데이터 수신 장치
JP2005033556A (ja) データ送信装置、データ送信方法、データ受信装置、データ受信方法
JP4445012B2 (ja) パケットの配信帯域制御方法、配信装置及び映像配信システム
JP5170106B2 (ja) 中継装置
KR100916312B1 (ko) 적응적 가중 오류 정정 부호화 및 다중 표현열 부호화를사용한 비디오 전송 장치 및 그 방법
JP2004120148A (ja) マルチメディアコンテンツ送信装置およびマルチメディアコンテンツ受信装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110118

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120830

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

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

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

Free format text: PAYMENT UNTIL: 20151019

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5109787

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees