JP5434570B2 - ストリーム配信装置 - Google Patents

ストリーム配信装置 Download PDF

Info

Publication number
JP5434570B2
JP5434570B2 JP2009291138A JP2009291138A JP5434570B2 JP 5434570 B2 JP5434570 B2 JP 5434570B2 JP 2009291138 A JP2009291138 A JP 2009291138A JP 2009291138 A JP2009291138 A JP 2009291138A JP 5434570 B2 JP5434570 B2 JP 5434570B2
Authority
JP
Japan
Prior art keywords
transmission rate
rate
packet
content
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
JP2009291138A
Other languages
English (en)
Other versions
JP2011135207A (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.)
NEC Corp
Original Assignee
NEC 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 NEC Corp filed Critical NEC Corp
Priority to JP2009291138A priority Critical patent/JP5434570B2/ja
Publication of JP2011135207A publication Critical patent/JP2011135207A/ja
Application granted granted Critical
Publication of JP5434570B2 publication Critical patent/JP5434570B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、ストリーム配信装置等に関し、特に品質非保証ネットワークで、ネットワーク帯域を可能な限り使用し、乱れや途切れのないストリーミングを実現するストリーム配信装置等に関する。
特許文献1に記載されているストリーム配信システムの送信端末は、コンテンツパケットとともに、ロスしたコンテンツパケットを再構成するための冗長パケットを、受信端末へ送信する。受信端末は、コンテンツパケットがロスした場合に、冗長パケットからコンテンツパケットを再構成して再生する。また、受信端末は、パケットロス率を送信端末へフィードバックする機能を持つ。送信端末は、受信端末からのフィードバック情報をもとに、ネットワークが輻輳状態であると判定したらビットレートを低減させる。また、送信する冗長パケット量を増加させることにより送信ビットレートを上昇させ、受信端末からのフィードバック情報をもとにネットワークが高いデータレートをサポートするか否かを判定する。
特許文献2には、受信した試験ストリームと同じ構成(パケットサイズ、ビットレート)の試験ストリームを送信ノード側に返送する受信ノードが、記載されている。
特許文献3には、伝送遅延時間差の増加傾向及び減少傾向から試験伝送率を求める技術が、記載されている。
特許文献4には、画像データのバッファ量の近似直線の傾きを演算し、送信レートを制御する技術が、記載されている。
特許文献5には、ストリームの送信時にビットレートを段階的に増加させる技術が、記載されている。
特開2009−027720号公報 特開2008−278207号公報(段落0045〜0047、図1) 特開2006−074773号公報(段落0019〜0021、図1、図2) 特開2005−005823号公報(段落0054〜0060、図10、図12) 特開平11−243360号公報(段落0084、図1)
Jain and Dovrolis:a measurement tool for end-to-end available bandwidth、In Proceedings of Passive and Active Measurements Workshop、pp.14-25、2002.
しかしながら、特許文献1の技術を使用するには、受信端末から送信端末へ、パケットロス率などのコンテンツの受信状態をフィードバックする必要がある。そのため、送信端末がコンテンツ受信状態のフィードバックを得られない場合には、特許文献1の技術を使用できない。例えば、特許文献1には、RTCP RR(RTP(Realtime Transport Protocol) Control Protocol Receiver Report)によるパケットロス率のフィードバック方法が記載されている。しかし、RTCPをサポートしないSTB(SetTop Box)や、RTCPの不使用を明示したIPTV(Internet Protocol TeleVision)プロトコルの環境では、特許文献1のフィードバック制御を実現できない。
また、特許文献2の技術では、ストリーム配信で受信ノードが「受信した試験ストリームと同じ構成(パケットサイズ、ビットレート)の試験ストリームを送信ノード側に返送する」ために、「受信したコンテンツパケットをそのまま送信ノードへ返送する」というコンテンツ受信状態のフィードバック機能が受信ノードに必要になる。そのため、そのような機能を有しない一般的な受信ノードに対しては、特許文献2の技術を使用できない。
このように、特許文献1、2の技術では、パケットロス率などのコンテンツ受信状態のフィードバックが受信端末から得られない場合には、ネットワークの輻輳状態を知ることができず、その結果、ネットワーク帯域を可能な限り使用し、乱れや途切れのないストリーミングを実現することができなかった。この課題を解決するための技術は、特許文献3〜5のどこにも開示も示唆もされていない。
そこで、本発明の目的は、パケットロス率などのコンテンツ受信状態のフィードバックが受信端末から得られない場合にも、ネットワーク状態を知ることができ、その結果、ネットワーク帯域を可能な限り使用し、乱れや途切れのないストリーミングを実現することにある。
本発明に係るストリーム配信装置は、
ネットワークを介して受信端末へストリームを送信するストリーム配信装置において、
プローブパケットを定期的に前記受信端末へ送信する送信部と、
前記プローブパケットを受信したことを示す応答パケットを前記受信端末から受信する受信部と、
前記送信部が前記プローブパケットを送信してから前記受信部が前記応答パケットを受信するまでに要した往復遅延時間を計算し、前記往復遅延時間が増加傾向に有れば前記ストリームの送信レートが可用帯域を上回っていると判定し、前記往復遅延時間が増加傾向に無ければ前記送信レートが前記可用帯域以下であると判定する制御部と、
を備えたことを特徴とする。
本発明に係るストリーム配信方法は、
ネットワークを介して受信端末へストリームを送信するストリーム配信方法において、
プローブパケットを定期的に前記受信端末へ送信する送信部と、前記プローブパケットを受信したことを示す応答パケットを前記受信端末から受信する受信部とを用意し、
前記送信部が前記プローブパケットを送信してから前記受信部が前記応答パケットを受信するまでに要した往復遅延時間を計算し、前記往復遅延時間が増加傾向に有れば前記ストリームの送信レートが可用帯域を上回っていると判定し、前記往復遅延時間が増加傾向に無ければ前記送信レートが前記可用帯域以下であると判定する、
ことを特徴とする。
本発明に係るストリーム配信プログラムは、
ネットワークを介して受信端末へストリームを送信するストリーム配信装置に用いられるストリーム配信プログラムにおいて、
前記ストリーム配信装置が、プローブパケットを定期的に前記受信端末へ送信する送信部と、前記プローブパケットを受信したことを示す応答パケットを前記受信端末から受信する受信部と、コンピュータとを備える場合に、
前記送信部が前記プローブパケットを送信してから前記受信部が前記応答パケットを受信するまでに要した往復遅延時間を計算する手段、及び、前記往復遅延時間が増加傾向に有れば前記ストリームの送信レートが可用帯域を上回っていると判定し、前記往復遅延時間が増加傾向に無ければ前記送信レートが前記可用帯域以下であると判定する手段として、
前記コンピュータを機能させるためのものである。
本発明によれば、プローブパケットを送信してから応答パケットを受信するまでに要した往復遅延時間を計算し、往復遅延時間の増加傾向の有無に応じて送信レートが可用帯域を上回っているか否かを判定するようにしたので、パケットロス率などのコンテンツ受信状態のフィードバックが受信端末から得られない場合でも、ネットワーク状態を知ることができる。
実施形態1の送信端末を示すブロック図である。 図1の制御部の一例を示すブロック図である。 図3[1]は送信レートが可用帯域を上回っている場合のパケットの挙動を表すタイミングチャートであり、図3[2]は送信レートが可用帯域以下である場合のパケットの挙動を表すタイミングチャートである。 コンテンツレートと送信レートとの関係を示すグラフである。 実施形態1の送信端末における全体の動作を示すフローチャートである。 実施形態1におけるコンテンツレート及び送信レートの決定方法を示すフローチャートである。 実施形態2におけるコンテンツレート及び送信レートの決定方法を示すフローチャートである。 実施形態3におけるコンテンツレート及び送信レートの決定方法を示すフローチャートである。 実施例1における送信時刻と送信パケット数との関係を示す図表であり、図9[1]は配信開始時であり、図9[2]は送信レート上昇時に1回に送信するパケット数を増やした場合であり、図9[3]はパケットの送信間隔を短くした場合である。 実施例2における送信レートの変化を示す図表である。 図11[1]は実施例3における往復遅延時間と送信レートの増加率との関係を示す図表であり、図11[2]は実施例3における近似直線の傾きと送信レートの低下率との関係を示す図表である。
次に、発明を実施するための形態について図面を参照して詳細に説明する。図1は、本発明の実施形態1の送信端末を示すブロック図である。図2は、図1の制御部の一例を示すブロック図である。以下、これらの図面に基づき説明する。
本実施形態1における送信端末10、パケット送信部15及びプローブパケット受信部16は、それぞれ特許請求の範囲における「ストリーム配信装置」、「送信部」及び「受信部」に相当する。送信端末10は、ネットワーク21を介して受信端末20へストリームを送信するストリーム配信装置であり、プローブパケットを定期的に受信端末20へ送信するパケット送信部15と、プローブパケットを受信したことを示す応答パケットを受信端末20から受信するプローブパケット受信部16と、制御部17と、を備えたことを特徴とする。制御部17は、パケット送信部15がプローブパケットを送信してからプローブパケット受信部16が応答パケットを受信するまでに要した往復遅延時間を計算し、この往復遅延時間が増加傾向に有ればストリームの送信レートが可用帯域を上回っていると判定し、往復遅延時間が増加傾向に無ければ送信レートが前記可用帯域以下であると判定する。プローブパケットは、例えばエコー要求パケットである。
送信端末10によれば、プローブパケットを送信してから応答パケットを受信するまでに要した往復遅延時間を定期的に計測し、往復遅延時間の増加傾向の有無に応じて送信レートが可用帯域を上回っているか否かを判定するようにしたので、パケットロス率などのコンテンツ受信状態のフィードバックが受信端末20から得られない場合でも、ネットワーク21の状態を知ることができる。
また、送信端末10は、次のように構成してもよい。
制御部17は、送信レートが可用帯域を上回っていると判定した場合に送信レートを低下させ、送信レートが可用帯域以下であると判定した場合に送信レートを上昇させる。この場合は、ネットワーク帯域を可能な限り使用し、乱れや途切れのないストリーミングを実現することができる。
ここで、本明細書における送信レートの定義を、図4を参照して説明しておく。図4は、コンテンツレートと送信レートとの関係を示すグラフである。図4において、横軸は送信開始からの時間を表し、縦軸は累積送信データ量を表す。
通常の送信方法では、図中の破線のように、累積送信データ量は経過時間に比例する。このとき、A[bps]のコンテンツを配信開始からt秒経過したときの累積送信データ量は、A×t[ビット]になる。一方で、送信レートをB[bps](B≧A)とした場合、送信開始からの(A/B)×t秒間でA×t[ビット]のコンテンツの送信を完了し、その後の(1−(A/B))×t秒間は送信しないという送り方も可能である(図中の実線)。本明細書では、このときのBを送信レートと定義する。
また、制御部17は、次のように構成してもよい。送信レートが可用帯域を上回っていると判定した場合に、(1)ストリームの対象となるコンテンツのレートであるコンテンツレートよりも送信レートが高ければ、コンテンツレートまで前記送信レートを低下させ、(2)コンテンツレートと送信レートとが同一であれば、コンテンツレートを低下させるとともに低下後のコンテンツレートまで送信レートを低下させる。送信レートが可用帯域以下であると判定した場合に、(3)コンテンツレートよりも送信レートが高ければ、コンテンツレートを上昇させるとともに上昇後のコンテンツレートに送信レートを合わせ、(4)コンテンツレートと送信レートとが同一であれば、送信レートを上昇させる。
本実施形態1のストリーム配信方法は、送信端末10の動作を方法の発明として捉えたものである。すなわち、本実施形態1のストリーム配信方法は、ネットワーク21を介して受信端末20へストリームを送信するストリーム配信方法において、プローブパケットを定期的に受信端末20へ送信するパケット送信部15と、プローブパケットを受信したことを示す応答パケットを受信端末20から受信するプローブパケット受信部16とを用意し、パケット送信部15がプローブパケットを送信してからプローブパケット受信部16が応答パケットを受信するまでに要した往復遅延時間を計算し、この往復遅延時間が増加傾向に有ればストリームの送信レートが可用帯域を上回っていると判定し、往復遅延時間が増加傾向に無ければ送信レートが可用帯域以下であると判定する、ことを特徴とする。
本実施形態1のストリーム配信プログラムは、制御部17としてコンピュータ30(図2)を機能させるためのものである。本実施形態1のストリーム配信プログラムは、ネットワーク21を介して受信端末20へストリームを送信する送信端末10に用いられる。送信端末10は、プローブパケットを定期的に受信端末20へ送信するパケット送信部15と、プローブパケットを受信したことを示す応答パケットを受信端末20から受信するプローブパケット受信部16と、コンピュータ30とを備える。このとき、本実施形態1のストリーム配信プログラムは、パケット送信部15が前記プローブパケットを送信してからプローブパケット受信部16が応答パケットを受信するまでに要した往復遅延時間を計算する手段、及び、この往復遅延時間が増加傾向に有ればストリームの送信レートが可用帯域を上回っていると判定し、往復遅延時間が増加傾向に無ければ送信レートが可用帯域以下であると判定する手段として(すなわち制御部17として)、コンピュータ30を機能させるためものである。
図2に示すように、コンピュータ30は、CPU31、ROM32、RAM33、バス34、入出力インタフェース35等を有し、パケット送信部15、プローブパケット受信部16等に接続される。CPU31は、ROM32又はRAM33に記憶された本実施形態1のストリーム配信プログラムを、読み込み、解釈し、実行する。なお、後述するコンテンツパケット生成部13などの機能も、コンピュータ30に実現するようなストリーム配信プログラムにしてもよい。
本実施形態1のストリーム配信方法及びプログラムは、送信端末10と同様の作用及び効果を奏するとともに、送信端末10の構成に準じて多様な構成を採り得る。
以下、送信端末10について、更に詳しく説明する。
図1を参照すると、本実施形態1のストリーム配信システムは、コンテンツを配信する送信端末10と、コンテンツを受信して再生する受信端末20とから構成される。送信端末10と受信端末20とは、ネットワーク21を介して接続されている。受信端末20は複数存在してもよい。本実施形態1の送信端末10には、前述したパケット送信部15、プローブパケット受信部16及び制御部17の他に、コンテンツ記憶部12、コンテンツパケット生成部13等を備える。制御部17は、配信制御部11及びプローブパケット生成部14を有する。
送信端末10は、配信制御部11、コンテンツ記憶部12、コンテンツパケット生成部13、プローブパケット生成部14、パケット送信部15、プローブパケット受信部16等からなる。配信制御部11は、プローブパケット受信部16から各プローブパケットに対する応答パケットの受信時刻を受け取り、配信するコンテンツレート及び送信レートを決定してコンテンツパケット生成部13及びプローブパケット生成部14へコンテンツパケット及びプローブパケットの生成を指示する。コンテンツ記憶部12は、複数のビットレートで配信可能な形態で、コンテンツを記憶している。コンテンツパケット生成部13は、コンテンツ記憶部12からコンテンツデータを取り出してコンテンツパケットを生成し、生成したコンテンツパケットをパケット送信部15へ転送する。プローブパケット生成部14は、プローブパケットであるエコー要求パケットを生成し、これをパケット送信部15へ転送する。パケット送信部15は、コンテンツパケット生成部13及びプローブパケット生成部14で生成した各パケットをネットワーク21へ送出する、プローブパケット受信部16は、送信したプローブパケットに対する応答パケットを受信し、受信時刻を配信制御部11へ通知する
ここで、本実施形態1のストリーム配信システムの動作原理を説明する。
IPネットワークには、次の性質がある。送信端末10からの送信レートが送信端末10と受信端末20との間の可用帯域を上回っていると、後に送信するパケットほど遅延時間が増加する。逆に、送信レートが可用帯域以下であるならば、後に送信するパケットでも遅延時間は増加しない。
図3[1]は送信レートが可用帯域を上回っている場合のパケットの挙動を表すタイミングチャートであり、図3[2]は送信レートが可用帯域以下である場合のパケットの挙動を表すタイミングチャートである。言い換えると、図3[1]は可用帯域よりも高いビットレートでパケットを送信したときのパケットの遅延を示し、図3[2]は可用帯域以下のビットレートでパケットを送信したときのパケットの遅延を示す。以下、これらの図面に基づき説明する。
図3において、縦方向が時間経過を表し、矢印はパケットを表し、矢印の密度が高いほどレートが高いことを意味する。可用帯域を上回るレートで送信したパケットは、可用帯域最小のリンク直前のルータに到着後、送信可能になるまでこのルータのキューに保存され、送信可能になると出力される。
図3[1]に示すように、送信レートが可用帯域を上回っていると、後方のパケットになるほど、キューに保存される時間が増加するため、遅延時間(送信端末10で送信してから受信端末20に到着するまでの時間)が大きくなる。
一方、図3[2]に示すように、送信レートが可用帯域以下である場合、送信端末10から送信したパケットは、可用帯域最小リンク直前のルータのキューに保存されることなく、即座に送信される。そのため、送信順によらず、各パケットの遅延時間は一定になる。
すなわち、あるレートで送信したときの遅延時間に、増加傾向があれば送信レートが可用帯域を超えており、増加傾向がなければ送信レートが可用帯域以下である、と判定できる。この原理はIPネットワークだけでなく、パケット交換ネットワーク全般で利用できるため、本発明の対象はIPネットワークに限らない。本実施形態1の送信端末10は、受信端末20へ送信したプローブパケットの往復遅延時間に増加傾向があるか否かによって、送信レートと可用帯域との大小関係を判定し、その判定結果に基づいてコンテンツレート及び送信レートを制御する。
送信レートをコンテンツレートと異なる値にすることで、現在配信しているコンテンツレートよりも高いレートと可用帯域との大小を比較できるため、コンテンツレートを上昇させられるか否かの判定が可能になる。
次に、図5のフローチャートを参照して、本実施形態1の送信端末10における全体の動作について詳細に説明する。以下、図1及び図5に基づき説明する。
配信開始時、配信制御部11は、初期コンテンツレート及び送信レート並びにプローブパケットの送信間隔をそれぞれ決定し(ステップS11)、コンテンツパケットの生成をコンテンツパケット生成部13へ、プローブパケットの生成をプローブパケット生成部14へそれぞれ指示する。初期コンテンツレート及び送信レートは、あらかじめ設定しておいた値にする方法、過去の情報をもとに決定する方法、配信可能な最低のビットレートのコンテンツを配信する方法など、いかなる方法で決定してもよい。
続いて、コンテンツパケット生成部13は、配信制御部11から指示されたレートのコンテンツデータをコンテンツ記憶部12から取り出してコンテンツパケットを生成し、そのコンテンツパケットを指定された送信レートでパケット送信部15へ転送する(ステップS12)。同時に、プローブパケット生成部14は、配信制御部11から指示された間隔でプローブパケットを生成し、これをパケット送信部15へ転送する(ステップS12)。
続いて、パケット送信部15は、コンテンツパケット生成部13で生成したコンテンツパケットと、プローブパケット生成部14で生成したプローブパケットとを、ネットワーク21へ送出する(ステップS13)。
最後に、配信制御部11は、コンテンツレートと送信レートを決定する(ステップS14)。その後、送信端末10の動作はステップS12へ戻る。
ここで、ステップ14におけるコンテンツレート及び送信レートの決定方法を、図6のフローチャートを参照して、詳細に説明する。以下、図1及び図6に基づき説明する。
配信制御部11は、プローブパケット受信部16から各プローブパケットの受信時刻を受け取り(ステップS1401)、配信制御部11が記憶している送信時刻に基づき往復遅延時間を計算する(ステップS1402)。この送信時刻は、例えば、パケット送信部15がプローブパケットをネットワーク21へ送出した時刻、すなわち配信制御部11がプローブパケット生成部14へプローブパケットの生成を指示した送信時刻である。したがって、往復遅延時間は、(往復遅延時間)=(受信時刻)−(送信時刻)の式で得られる。
続いて、配信制御部11は、規定数のプローブパケットを受信したら、往復遅延時間の増加傾向の有無を判定する(ステップS1403)。往復遅延時間の増加傾向の有無を判定する方法の一例として、横軸をプローブパケットの送信時刻とし、縦軸を往復遅延時間としたグラフにおいて、各送信時刻における往復遅延時間をプロットし、これらの点の近似直線を最小二乗法で求め、その傾きが規定値以上ならば増加傾向あり、規定値未満ならば増加傾向なし、と判定する方法がある。また、可用帯域推定法であるPathload(非特許文献1参照)の判定方法を使用してもよい。Pathloadでは、既定数のプローブパケットの遅延時間から、PCT(Pairwise Comparison Test)とPDT(Pairwise Difference Test)という値を計算し、これらの値をもとに増加傾向の有無を判定している。また、受信端末20へエコー要求を送信してから規定時間が経ってもエコー応答が返ってこない場合にパケットロスと判定し、プローブパケットのパケットロス率が規定値以上ならば、送信レートが可用帯域を上回っていると判定してもよい。
これ以降の処理は、送信レートとコンテンツレートとが同一か否か(ステップS1404)と、往復遅延時間に増加傾向があるか否か(ステップS1405,S1406)との、次の四通りの組み合わせによって異なる。
(1).送信レートとコンテンツレートとが同一であり、往復遅延時間に増加傾向がない場合(ステップS1404がYes、ステップS1405がNo)。この場合は、コンテンツレートの上昇可否を判定するため、コンテンツレートは変更せずに送信レートを現在のコンテンツレートよりも1段階上のコンテンツレートと同一にする(ステップS1407)。
(2).送信レートとコンテンツレートとが同一であり、往復遅延時間に増加傾向がある場合(ステップS1404がYes、ステップS1405がYes)。この場合は、現在のコンテンツレートが可用帯域を上回っていると判定して、コンテンツレートを1段階下げ、送信レートを低下後のコンテンツレートと同一にする(ステップS1408)。
(3).送信レートとコンテンツレートとが異なり(すなわち送信レートを1段階上のコンテンツレートとしている)、往復遅延時間に増加傾向がある場合(ステップS1404がNo、ステップS1406がYes)。この場合は、1段階上のコンテンツレートでは配信不可と判定して、送信レートを現在配信中のコンテンツレートと同一する(ステップS1409)。
(4).送信レートとコンテンツレートとが異なり(すなわち送信レートを1段階上のコンテンツレートとしている)、往復遅延時間に増加傾向がない場合(ステップS1404がNo、ステップS1406がNo)。この場合は、1段階上のコンテンツレートで配信可能と判定して、コンテンツレートを1段階上昇させる(ステップS1410)。図6では、送信レートとコンテンツレートとが同一か否か(ステップS1404)の判定を先に、往復遅延時間に増加傾向があるか否か(ステップS1405,S1406)の判定を後にしているが、前述の四通りの組み合わせが得られればよいので、これらの順従は逆でもよい。
ステップS1407とステップS1410とにおいて、往復遅延時間に増加傾向がない場合にすぐに上昇させるのではなく、何回か連続して増加傾向がない場合に上昇させるようにしてもよい。また、ステップS1407において、送信レートを1段階上のコンテンツレートよりも高くして、1段階上のコンテンツレートよりも高いレートと可用帯域を比較してもよい。
これらの処理を行うことで、可用帯域に余裕がある場合にのみコンテンツレートを上昇させることができ、コンテンツレート上昇後に可用帯域不足による受信端末での再生の停止や乱れを防止できる。
次に、本実施形態1の効果を説明する。本実施形態1によれば、受信端末がコンテンツ受信機能の他にエコー要求に対して応答する機能を備えていれば、受信端末がコンテンツ受信状態のフィードバック機能を持たなくても、ネットワーク帯域を可能な限り使用し、乱れや途切れのないストリーミングを実現できる。インターネットで使用されているIP(Internet Protocol)をサポートするほぼすべての受信端末はICMP(Internet Control Message Protocol) Echo機能を実装しているため、インターネットでのストリーム配信では、ほとんどすべての場合に本発明を利用できる。
図7は、実施形態2におけるコンテンツレート及び送信レートの決定方法を示すフローチャートである。本実施形態2は、配信制御部11におけるコンテンツレート及び送信レートの決定方法(図5のステップS14)が実施形態1と異なる。以下、本実施形態2における図5のステップS14の詳細な動作を、図1及び図7を参照して詳細に説明する。
図5のステップS1401からステップS1403までの動作は、実施形態1と同一である。これ以降の処理は、往復遅延時間の増加傾向の有無によって異なる(ステップS1411)。
往復遅延時間に増加傾向がある場合(ステップS1411がYes)には、送信レートとコンテンツレートとが同一か否かを判定する(ステップS1412)。送信レートがコンテンツレートと異なる(ステップS1412がNo)場合(すなわち送信レートがコンテンツレートよりも大きい場合)には、現在の送信レートが可用帯域を超えていると判定して送信レートをコンテンツレートと同一に変更する(ステップS1414)。送信レートとコンテンツレートとが等しい(ステップS1412がYes)場合には、現在のコンテンツレートは可用帯域を上回っていると判定して、コンテンツレートを1段階低下させ、送信レートを低下後のコンテンツレートと同一にする(ステップS1415)。
一方、往復遅延時間に増加傾向がない(ステップS1411がNo)場合には、送信レートを上昇させる(ステップS1413)。ステップS1413における送信レートの上昇量は、例えば10%上昇させるなどあらかじめ決めておく。送信レートの上昇量は、現在の送信レートからの一定割合とする以外に、500kbpsなどの絶対量にしてもよい。また、送信レートが1Mbps以上ならば500kbps、1Mbps未満ならば100kbpsなどと、送信レートに応じて変動させてもよい。
続いて、上昇後の送信レートと1段階上のコンテンツレートとを比較し(ステップS1416)、送信レートが1段階上のコンテンツレートを上回っていたら、1段階上のコンテンツレートで配信可能と判断して、コンテンツレートを1段階上昇させる(ステップS1417)。このとき、送信レートが1段階上のコンテンツレートを上回ったらすぐにコンテンツレートを上昇させるのではなく、送信レートが1段階上のコンテンツレートを一定割合(例えば10%)上回ったらコンテンツレートを上昇させるとしてもよい。
これらの処理を行うことで、実施形態1と同様に可用帯域に余裕がある場合にのみコンテンツレートを上昇させることができ、コンテンツレート上昇後に可用帯域不足による受信端末での再生の停止や乱れを防止できる。
次に、本実施形態2の効果を説明する。本実施形態2では、送信レートを徐々に上昇させていくため、パケットロスが発生しにくくなる。送信レートが可用帯域を大幅に超えると、ネットワーク機器のキューを溢れさせてコンテンツパケットのロスとなるので、受信端末20での再生に途切れや乱れが生じる可能性がある。そこで、送信レートを徐々に増加させることにより、送信レートが可用帯域を大幅に超える可能性が低くなるので、パケットロスが発生しにくくなる。
本実施形態2のその他の構成、作用及び効果は、実施形態1と同様である。
図8は、実施形態3におけるコンテンツレート及び送信レートの決定方法を示すフローチャートである。本実施形態3も、配信制御部11におけるコンテンツレート及び送信レートの決定方法(図5のステップS14)が実施形態1、2と異なる。以下、本実施形態3における図5のステップS14の詳細な動作を、図1及び図8を参照して詳細に説明する。
ステップS1401からステップS1411までの動作は、実施形態2と同一である。本実施形態3では、往復遅延時間に増加傾向がないと判定した(ステップS1411がNo)場合、往復遅延時間の挙動から送信レートの上昇量を決定する(ステップS1423)。
送信レートが可用帯域以下の場合でも、送信レートが可用帯域よりも大幅に小さいときと、送信レートが可用帯域に近いときとでは、往復遅延時間のばらつき傾向が異なる。例えば、送信レートが可用帯域よりも大幅に小さいときには往復遅延時間の分散が小さくなり、送信レートが可用帯域に近いといには往復遅延時間の分散が大きくなる。本実施形態3では、プローブパケットの往復遅延時間の分散が小さい場合には送信レートの上昇量を大きくし、その分散が大きい場合には送信レートの上昇量を小さくする。
また、往復遅延時間に増加傾向がある(ステップS1411がYes)場合には、増加傾向から送信レートの低下量を決定する(ステップS1422)。
送信レートが可用帯域を大幅に上回っている場合には、実施形態1で述べた近似直線の傾きが大きくなり、プローブパケットのロスも発生しやすくなる。一方、送信レートが可用帯域を超える量が少なければ、近似直線の傾きが小さくなり、プローブパケットのロスも発生しにくくなる。本実施形態3では、プローブパケットの往復遅延時間を直線に近似した場合の傾きの大きさや、プローブパケットのロス率に応じて、送信レートの低下量を決定する。
最後に、ステップS1422及びステップS1423で決定した送信レートをもとに、ステップS1424でコンテンツレートを決定する。コンテンツレートは、配信可能なコンテンツレートの中で、送信レート以下かつ最大のものを選択することで、決定できる。
換言すると、本実施形態3における制御部17は、送信レートを上昇させる際に、往復遅延時間のばらつき具合の大小に応じて送信レートの上昇率を変化させ、送信レートを低下させる際に、送信レートが可用帯域を上回っている量に応じて送信レートの低下率を変化させる。
次に、本実施形態3の効果を説明する。本実施形態3では、送信レートと可用帯域との大小関係だけでなく、送信レートと可用帯域とにどれだけ差があるかという情報をもとに送信レートの変動量を決定するため、可用帯域変動への追従性が向上する。
本実施形態3のその他の構成、作用及び効果は、実施形態1、2と同様である。
次に、実施形態1〜3をそれぞれ更に具体化した実施例1〜3について説明する。図9は、実施例1における送信時刻と送信パケット数との関係を示す図表であり、図9[1]は配信開始時であり、図9[2]は1回に送信するパケット数を増やした場合であり、図9[3]はパケットの送信間隔を短くした場合である。以下、図1及び図9に基づき説明する。
実施例1は、実施形態1を更に具体化した一例である。本実施例1において、送信端末10と受信端末20とは、ネットワーク21としてのインターネットを経由して接続されている。送信端末10から受信端末20へのコンテンツ配信はRTP(Realtime Transport Protocol)によって行われ、トランスポートプロトコルにはUDP(User Datagram Protocol)を使用する。また、プローブパケットにはICMP Echoを使用する。送信端末10から受信端末20へはICMP Echo Requestを送信し、受信端末20はICMP Echoを受信すると送信端末10へはICMP Echo Replyを返答する。ICMP Echo機能は、IPをサポートするほとんどすべての端末に実装されているため、本発明はほとんどすべての受信端末で使用できる。ICMP Echo以外にも、UDP Echoなどを使用してもよい。
送信端末10はサーバ装置である。配信制御部11、コンテンツパケット生成部13及びプローブパケット生成部14は、サーバ装置のCPU31(図2)で実行するプログラムによって実現されている。コンテンツ記憶部12は、サーバ装置に内蔵される磁気ディスク装置であり、各映像コンテンツを複数のビットレートでエンコードして記憶しておく。コンテンツは、映像以外に音声などでもよい。本実施例1では、各映像コンテンツを2Mbps、4Mbps、6Mbpsでエンコードしたものを記憶しているとする。パケット送信部15及びプローブパケット受信部16は、サーバ装置のネットワーク・インタフェース・カードである。受信端末20は、IPTV用のセット・トップ・ボックス、携帯電話端末、PDA(Personal Digital Assistant)、PC(Personal Computer)などの、映像や音声などのメディアを受信して再生する端末であり、ICMP Echo機能を実装している。
配信開始時、送信端末10は、初期のコンテンツレート及び配信レートを決定する。ここでは、コンテンツ記憶部12で記憶しているものうち、最低品質のものを選択するとし、コンテンツレート及び送信レートともに2Mbpsとする。1RTPパケットあたりのデータサイズを1000バイトとしたとき、1秒間に送信するRTPパケット数は、250個(=2000000[bps]/8[b/B]/1000[B/パケット])となる。パケットの送信間隔を10ミリ秒とすると、1回に送信するRTPパケット数は2.5個(2個と3個を交互に送信)となる(図9[1])。
このとき、コンテンツパケットの直前・直後・中間にICMP Echo Requestを送信する。
ICMP Echo Requestは、なるべくネットワーク21の負荷にならないように、可能な限り小さいサイズにすることが望ましい。また、ICMP EchoヘッダのIDフィールド及びシーケンス番号フィールドを送信パケット毎に変更することにより、受信端末20からのエコー応答受信時には、どのエコー要求に対する応答パケットであるかを識別可能にする。
ここでは、コンテンツレート及び送信レートともに2Mbpsとした場合、往復遅延時間に増加傾向がなかったとする。送信レートとコンテンツレートとが等しく、往復遅延時間に増加傾向がない場合、1段階上のコンテンツレートで配信できるか否かを判定するため、コンテンツレートを変更せずに、送信レートを1段階上のコンテンツレートに変更する(図6のステップS1407)。本実施例1では、送信レートを4Mbpsへ上昇させる。
送信レートを上昇させる方法として、パケットの送信間隔を変更せずに1回の送信パケット数を増加させる方法と、1回の送信パケット数を変更せずにパケットの送信間隔を変更する方法との二通りが考えられる。
前者の送信パケット数を増加させる方法について、0.1秒分(2Mbpsコンテンツの場合には25個)のパケットの送信レートを変更する例で考える。1回の送信パケット数を増加させる方法では、図9[2]に示すように、10ミリ秒間隔で5個(=2.5×(4Mbps/2Mbps))ずつのコンテンツパケットを送信する。そして、コンテンツパケットとともに送信したプローブパケットの増加傾向の有無に基づき、可用帯域が4Mbps以上あるか否かを判定する。その結果に基づき、コンテンツレートを4Mbpsへ上昇させるか否かを判定する。
一方、後者のパケットの送信間隔を変更する方法では、図9[3]に示すように、5ミリ秒間隔で2.5個(実際には2個と3個を交互に)のコンテンツパケットを送信する。そして、プローブパケットの往復遅延時間の増加傾向の有無に基づき、可用帯域が4Mbps以上あるか否かを判定する。判定の結果、増加傾向がなければコンテンツレートを4Mbpsへ上昇させ、増加傾向があれば送信レートを2Mbpsへ低下させる。
一般的なストリーム配信では、コンテンツのビットレートが上昇した場合、コンテンツの送信間隔は変更せずに1回に送信するパケット数を変化させる。そのため、前者の方法を用いると、コンテンツレート上昇後と同じ送信パターンで、送信レートと可用帯域との比較が可能になる。一方、後者の方法の場合、1回の送信あたりに1個のプローブパケットを送信した場合に、より多くのプローブパケットを送信するため、多くのサンプルから送信レートと可用帯域とを比較することが可能である。
図10は、実施例2における送信レートの変化を示す図表である。以下、図10に基づき説明する。
実施例2は、実施形態2を更に具体化した一例である。コンテンツレート及び送信レートがともに2Mbpsのときに往復遅延時間に増加傾向がない場合、実施例1では送信レートを4Mbpsに増加させるのに対し、本実施例2では送信レートを徐々に増加させていく。送信レートを10%ずつ増加させた場合の一例を図10に示す。往復遅延時間に増加傾向がない場合には、送信レートを2.2Mbps、2.42Mbps、・・・と増加させていき、この処理を9回実行すると送信レートが4Mbpsを超えるため、コンテンツレートを4Mbpsに変更する。
実施例2における他の構成、作用及び効果は、実施例1と同様である。
図11[1]は実施例3における往復遅延時間と送信レートの増加率との関係を示す図表であり、図11[2]は実施例3における近似直線の傾きと送信レートの低下率との関係を示す図表である。以下、図8及び図11に基づき説明する。
実施例3は、実施形態3を更に具体化した一例である。実施形態3では、往復遅延時間に増加傾向がない場合の送信レートの増加率を往復遅延時間の分散に応じて決定し、往復遅延時間に増加傾向がある場合の送信レートの低下率を近似直線の傾きに応じて決定する。
送信レートの増加率は、図11[1]に示したように決定する。図11[1]は、往復遅延時間の分散があるしきい値a以下ならば送信レートを20%増加させ、aより大きくb以下ならば10%増加させ、b以上ならば5%増加させることを表す。図11[2]は、往復遅延時間に増加傾向があるか否かを判定する際に求めた近似直線の傾きに応じて
送信レートの低下率を変化させている。
配信開始時、コンテンツレート及び送信レートがともに2Mbpsであるとする。このとき図8のステップS1411で往復遅延時間に増加傾向がないと判定すると、送信レートの上昇量の決定ステップ(図8のステップS1423)に移る。ステップS1423では、往復遅延時間の分散をもとに送信レートの上昇量を決定する。往復遅延時間の分散vがa未満の場合、送信レートを20%上昇させた2.4Mbpsとする。次に得られた往復遅延時間の分散vがb≧v>aの場合には、送信レートを更に10%上昇させた2.64Mbpsとする。
続いて、送信レートが2.64Mbpsの場合に、プローブパケットの往復遅延時間に増加傾向が表れたとする。往復遅延時間に増加傾向が表れると、近似直線の傾きwをもとに送信レートの変動量を決定する(図8のステップS1422)。このとき、w≦dであれば、送信レートを10%低下させて2.38Mbpsとする。
実施例3における他の構成、作用及び効果は、実施例1、2と同様である。
以上、上記各実施形態及び各実施例を参照して本発明を説明したが、本発明は上記各実施形態及び各実施例に限定されるものではない。本発明の構成や詳細については、当業者が理解し得るさまざまな変更を加えることができる。また、本発明には、上記各実施形態及び各実施例の構成の一部又は全部を相互に適宜組み合わせたものも含まれる。
本発明は、例えば、インターネット上での映像配信サービスに使用する配信サーバや、テレビ会議システムなどに適用できる。
最後に、本発明の構成として特許請求の範囲に記載し得る例を、以下に付記として記載する。
(付記1)ネットワークを介して受信端末へストリームを送信するストリーム配信装置であって、
前記ストリーム配信装置の配信制御部は、
定期的に送信したプローブパケットの往復遅延時間の増加傾向の有無を判定し、
前記増加傾向がある場合には前記ストリームの送信レートが可用帯域を上回っていると判定し、前記増加傾向がない場合には前記送信レートが可用帯域以下であると判定する、
ことを特徴とするストリーム配信装置。
(付記2)付記1に記載のストリーム配信装置であって、
前記送信レートをコンテンツレートよりも高く設定し、
前記プローブパケットの往復遅延時間の増加傾向の有無を判定することにより、前記コンテンツレートよりも高いレートと可用帯域との比較を行う、
ことを特徴とするストリーム配信装置。
(付記3)付記2に記載のストリーム配信装置であって、
コンテンツパケットの各送信時刻における送信パケット数を増加させることにより、前記送信レートを上昇させる、
ことを特徴とするストリーム配信装置。
(付記4)付記2に記載のストリーム配信装置であって、
コンテンツパケットの送信間隔を短縮することにより、前記送信レートを上昇させる、
ことを特徴とするストリーム配信装置。
(付記5)付記3又は4に記載のストリーム配信装置であって、
前記コンテンツパケットの送信時にプローブパケットを送信する、
ことを特徴とするストリーム配信装置。
(付記6)付記1乃至5のいずれか一つに記載のストリーム配信装置であって、
前記プローブパケットがエコー要求パケットである、
ことを特徴とするストリーム配信装置。
(付記7)付記1乃至6のいずれか一つに記載のストリーム配信装置であって、
前記送信レートが可用帯域を上回っていると判定した場合に前記送信レートを低下させる、
ことを特徴とするストリーム配信装置。
(付記8)付記1乃至7に記載のストリーム配信装置であって、
前記送信レートが可用帯域以下と判定した場合に前記送信レートを上昇させる、
ことを特徴とするストリーム配信装置。
(付記9)付記7に記載のストリーム配信装置であって、
前記送信レートが可用帯域を上回っていると判定した場合に、
前記送信レートがコンテンツレートよりも高ければ、前記送信レートを前記コンテンツレートと同一のレートへ低下させ、
前記送信レートと前記コンテンツレートとが同一であるならば、前記コンテンツレートを現在配信しているものから1段階低下させ、前記送信レートを低下後の前記コンテンツレートと同一にする、
ことを特徴とするストリーム配信装置。
(付記10)付記7に記載のストリーム配信装置であって、
前記送信レートが前記可用帯域を上回っていると判定した場合に、前記送信レートが前記可用帯域を上回っている量に応じて前記送信レートの低下率を変化させる、
ことを特徴とするストリーム配信装置。
(付記11)付記8に記載のストリーム配信装置であって、
前記送信レートが前記可用帯域以下であると判定した場合に、
前記送信レートとコンテンツレートが同一であるならば、前記送信レートを現在配信しているものから1段階上の前記コンテンツレートと同一にし、
前記送信レートが現在配信しているものから1段階上の前記コンテンツレートと同一であるならば、前記コンテンツレートを1段階上昇させる、
ことを特徴とするストリーム配信装置。
(付記12)付記8に記載のストリーム配信装置であって、
前記送信レートが前記可用帯域以下であると判定した場合に、前記送信レートを既定量上昇させる、
ことを特徴とするストリーム配信装置。
(付記13)付記8に記載のストリーム配信装置であって、
前記送信レートが前記可用帯域以下であると判定した場合に、前記プローブパケットの前記往復遅延時間のばらつき具合の大小に応じて前記送信レートの上昇率を変化させる、
ことを特徴とするストリーム配信装置。
(付記14)付記1乃至13のいずれか一つに記載のストリーム配信装置を有する、
ことを特徴とするストリーム配信システム。
10 送信端末(ストリーム配信装置)
11 配信制御部
12 コンテンツ記憶部
13 コンテンツパケット生成部
14 プローブパケット生成部
15 パケット送信部(送信部)
16 プローブパケット受信部(受信部)
17 制御部
20 受信端末
21 ネットワーク(インターネット)
30 コンピュータ
31 CPU
32 ROM
33 RAM
34 バス
35 入出力インタフェース

Claims (5)

  1. ネットワークを介して受信端末へストリームを送信するストリーム配信装置において、
    プローブパケットを定期的に前記受信端末へ送信する送信部と、
    前記プローブパケットを受信したことを示す応答パケットを前記受信端末から受信する受信部と、
    前記送信部が前記プローブパケットを送信してから前記受信部が前記応答パケットを受信するまでに要した往復遅延時間を計算し、前記往復遅延時間が増加傾向に有れば前記ストリームの送信レートが可用帯域を上回っていると判定し、前記往復遅延時間が増加傾向に無ければ前記送信レートが前記可用帯域以下であると判定する制御部と、
    を備え
    前記制御部は、
    前記送信レートが前記可用帯域を上回っていると判定した場合に、
    前記ストリームの対象となるコンテンツのレートであるコンテンツレートよりも前記送信レートが高ければ、前記コンテンツレートまで前記送信レートを低下させ、
    前記コンテンツレートと前記送信レートとが同一であれば、前記コンテンツレートを低下させるとともに低下後の前記コンテンツレートまで前記送信レートを低下させる、
    ことを特徴とするストリーム配信装置。
  2. 請求項記載のストリーム配信装置において、
    前記制御部は、前記送信レートを低下させる際に、前記送信レートが前記可用帯域を上回っている量に応じて前記送信レートの低下率を変化させる、
    ことを特徴とするストリーム配信装置。
  3. ネットワークを介して受信端末へストリームを送信するストリーム配信装置において、
    プローブパケットを定期的に前記受信端末へ送信する送信部と、
    前記プローブパケットを受信したことを示す応答パケットを前記受信端末から受信する受信部と、
    前記送信部が前記プローブパケットを送信してから前記受信部が前記応答パケットを受信するまでに要した往復遅延時間を計算し、前記往復遅延時間が増加傾向に有れば前記ストリームの送信レートが可用帯域を上回っていると判定し、前記往復遅延時間が増加傾向に無ければ前記送信レートが前記可用帯域以下であると判定する制御部と、
    を備え、
    前記制御部は、
    前記送信レートが前記可用帯域以下であると判定した場合に、
    前記ストリームの対象となるコンテンツのレートであるコンテンツレートよりも前記送信レートが高ければ、前記コンテンツレートを上昇させるとともに上昇後の前記コンテンツレートに前記送信レートを合わせ、
    前記コンテンツレートと前記送信レートとが同一であれば、前記送信レートを上昇させる、
    ことを特徴とするストリーム配信装置。
  4. 請求項記載のストリーム配信装置において、
    前記制御部は、前記送信レートを上昇させる際に、前記往復遅延時間のばらつき具合の大小に応じて前記送信レートの上昇率を変化させる、
    ことを特徴とするストリーム配信装置。
  5. 請求項1乃至のいずれか一項記載のストリーム配信装置において、
    前記プローブパケットがエコー要求パケットである、
    ことを特徴とするストリーム配信装置。
JP2009291138A 2009-12-22 2009-12-22 ストリーム配信装置 Active JP5434570B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2009291138A JP5434570B2 (ja) 2009-12-22 2009-12-22 ストリーム配信装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009291138A JP5434570B2 (ja) 2009-12-22 2009-12-22 ストリーム配信装置

Publications (2)

Publication Number Publication Date
JP2011135207A JP2011135207A (ja) 2011-07-07
JP5434570B2 true JP5434570B2 (ja) 2014-03-05

Family

ID=44347497

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009291138A Active JP5434570B2 (ja) 2009-12-22 2009-12-22 ストリーム配信装置

Country Status (1)

Country Link
JP (1) JP5434570B2 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014050546A1 (ja) * 2012-09-27 2014-04-03 日本電気株式会社 音声情報伝送方法及びパケット通信システム
KR101640851B1 (ko) * 2012-09-27 2016-07-19 닛본 덴끼 가부시끼가이샤 화상 정보 전송 방법 및 패킷 통신 시스템
JP5732498B2 (ja) * 2013-09-04 2015-06-10 株式会社京三製作所 鉄道用通信システム、車上装置、地上装置及び通信制御方法
JP6173141B2 (ja) * 2013-09-13 2017-08-02 セコム株式会社 無線通信システム及び無線送信機
US9781734B2 (en) 2013-12-26 2017-10-03 Nec Corporation Communication apparatus, communication method, and recording medium
JP2016005220A (ja) * 2014-06-19 2016-01-12 株式会社Jvcケンウッド 送信装置、送信方法、プログラム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1023064A (ja) * 1996-07-01 1998-01-23 Nippon Telegr & Teleph Corp <Ntt> 自律分散型トラヒックフロー制御法
JP2003174489A (ja) * 2001-12-05 2003-06-20 Ntt Docomo Inc ストリーミング配信装置、ストリーミング配信方法

Also Published As

Publication number Publication date
JP2011135207A (ja) 2011-07-07

Similar Documents

Publication Publication Date Title
EP1309151A2 (en) System and method of network adaptive real-time multimedia streaming
JP5434570B2 (ja) ストリーム配信装置
EP3175584B1 (en) Reducing delay in video telephony
US6992981B2 (en) Communication system and method capable of avoiding congestion in moving image data transmission
US10785448B2 (en) Robust handling of sudden changes of bandwidth in selective forwarding unit conferences
US20020194361A1 (en) Data transmitting/receiving method, transmitting device, receiving device, transmiting/receiving system, and program
KR101399509B1 (ko) 시-변화 전송 미디어를 통한 데이터 스트리밍
US9014048B2 (en) Dynamic bandwidth re-allocation
JP2010011212A (ja) 送信装置、受信装置、及び方法、プログラム
JP5807710B2 (ja) コンテンツ配信システム、コンテンツ配信方法及びプログラム
US8873590B2 (en) Apparatus and method for correcting jitter
US20160241410A1 (en) Method for subscribing to streams from multicast clients
CN109495326B (zh) 网络带宽分配方法和***
US20140344392A1 (en) Content delivery system, cache server, and content delivery method
US20110299399A1 (en) Method and apparatus for congestion control
JP5748471B2 (ja) 配信装置、配信方法、プログラム
GB2527365A (en) A telecommunication end-point device data transmission controller
JP2009246630A (ja) ホームゲートウェイ装置およびホームゲートウェイ装置の通信品質制御方法
KR101017352B1 (ko) 무선 인터넷 환경에서의 스트리밍 콘텐츠 전송 방법
WO2014083962A1 (ja) 通信システム
CN109922307A (zh) 一种多媒体数据传输方法及摄像机
KR101107325B1 (ko) 실시간 멀티미디어 서비스에 대한 네트워크 구간별 품질측정 방법 및 시스템
WO2014087764A1 (ja) 端末および通信システム
WO2014087765A1 (ja) 端末および通信システム
Dhamodaran et al. Adaptive Queue Management Scheme for Flexible Dual TCP/UDP Streaming Protocol

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20121112

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130712

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130723

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130918

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20131125

R150 Certificate of patent or registration of utility model

Ref document number: 5434570

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150