JP2004080279A - Quality control method of video stream, its program, and recording medium - Google Patents

Quality control method of video stream, its program, and recording medium Download PDF

Info

Publication number
JP2004080279A
JP2004080279A JP2002236734A JP2002236734A JP2004080279A JP 2004080279 A JP2004080279 A JP 2004080279A JP 2002236734 A JP2002236734 A JP 2002236734A JP 2002236734 A JP2002236734 A JP 2002236734A JP 2004080279 A JP2004080279 A JP 2004080279A
Authority
JP
Japan
Prior art keywords
stream
node
video stream
control method
quality control
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
JP2002236734A
Other languages
Japanese (ja)
Other versions
JP3783947B2 (en
Inventor
Takehiko Kitamura
北村 健彦
Katsuhiko Okazaki
岡崎 勝彦
Hideki Kasahara
笠原 英樹
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.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone 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 Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2002236734A priority Critical patent/JP3783947B2/en
Publication of JP2004080279A publication Critical patent/JP2004080279A/en
Application granted granted Critical
Publication of JP3783947B2 publication Critical patent/JP3783947B2/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Abstract

<P>PROBLEM TO BE SOLVED: To achieve simple quality control of video streams considering burst characteristics. <P>SOLUTION: The video streams are measured in advance, stream characteristics (P, ρ, δ) (P: maximum traffic rate, ρ: long-time average rate, δ: amount of one-time burst data) are examined, and packet loss rate (ε) to be permitted is determined. Additionally, a link speed C in each node in a network, and buffer time T are examined. Then, a maximum value KO of K to be permitted when allowing K streams to flow to the same link is determined, and a multiplexing parameter A = C/K0 is defined and expressed by the two parameters α, β. Input side conditions and output side are expressed by α, β, respectively. By regarding, for example, stream speed and link speed in each node as ασ and βC, respectively, application can be made to a node independent distribution system such as RSVP-TE. <P>COPYRIGHT: (C)2004,JPO

Description

【0001】
【発明の属する技術分野】
本発明はIP網の品質制御技術に係わり、特に周期的なバーストを持つ映像ストリームトラフィックに対する品質制御として、統計多重効果をパラメータ化すること及びそのパラメータを利用してネットワークに品質制御機能を持たせる技術に関するものである。
【0002】
【従来の技術】
映像ストリームは、一般に、バーストが一定周期で発生して、1度のバーストで流れるデータ量が一定である性質を持つ。図17は、このような映像ストリームの一例を示したもので、ストリーム特性(トラフィック)は3つのパラメータP、ρ、σによって表現が可能である。ここで、ρは長時間平均レート、Pは瞬間最大レート、σは1度のバーストで流れるデータ量を表わしている。このようなストリームは、パケットロスが著しい品質劣化を起こす性質をもつが、リアルタイム性やマルチキャストを利用するアプリケーションで扱われるなど、再送制御による品質制御が困難で、ネットワーク側で品質制御を行う必要がある。
【0003】
まず、バースト性のあるトラフィックに対して品質制御を行う為の従来技術としては、ATM(Asynchronous Transfer mode:非同期転送モード)のトラフィック制御技術として既に標準的な手法が確立されている(文献:Paul Ferguson;Geoff Huston,“インターネットQoS”,オーム社,pp,123−154,2000)。それらに共通な性質は、以下のようなものである。
1.UPC(Usage Parameter Controller)によりトラヒックをネットワークの都合に合わせて加工する。UPCは、一般にすべてのネットワーク資源が使われたとき、過剰にトラヒックネットワークに入ることを禁止することにより輻輳を防ぐものである。
2.各フロー毎にVC(仮想チャネル)を割当ててVC単位に制御する。
3.QoS(Quality of Service)パラメータにより統計多重効果を推定して、品質制御を行う。通信品質に影響を及ぼすパラメータは、遅延時間や遅延のバラッキ、データ損失率、ピーク速度などである。
【0004】
また、IP網での品質保証技術としては、ルータ間で特定の通信チャネルの伝送帯域を管理するためのプロトコルであるRSVP(Resource Reservation Setup Protocol)を利用したRSVP−TEなどがあるが(文献:D.Awducheほか“RSVP−TE:Extension to RSVP for LSP Tunnels”,IETF Networking Group RFC 3209,2001)、以下のような特徴をもっている。
1.UPCの存在は必須ではない。
2.経路制御プロトコルで行われる為、一般には各ノードの自律分散によっ
て行われ、ATMに比べて経路計算処理負荷が小さい。
3.RSVP−TEのようにリソース予約モデルに基づくものが多く、パラ
メータは単純なものが主である。
【0005】
このように、ATMとIPの品質制御は異なる方向性をもっている。ほかには、VLAN単位のレートシェービングのような低位レイヤでの制御方法もあるが、これらはIPルーティングとは独立に動作した静的な制御である。
【0006】
【発明が解決しようとする課題】
上記ATMのトラフィック制御技術には、UPCの実装が必要であり、収容ノードに対する要求条件が厳しくなること、また、VCを各フローに割当てる為、フロー数が大きくなると経路計算負荷がIPのルーティング制御に比べて急速に増加するなどの課題があった。また、IPによる既存トラフィック制御技術では、リンク帯域や必要帯域といった単純なパラメータしか使えないため、バースト性を考慮しておらず、バースト性を考慮する場合には必要帯域として最大ピークレートを用いる必要があり、統計多重効果による効果を考慮してトラフィック制御が出来ない課題があった。
【0007】
これらの課題は、入力トラヒックとして一般のトラヒックを前提としているための問題である。先に述べたように映像ストリームの出力特性はある程度の規則性をもっており、かつ、そのパケットロス目標値は大変小さい。
【0008】
本発明の目的は、映像ストリームのこのような特性を利用して、UPCを用いることなく、既存のIPの経路制御プロトコルを用いて、バースト特性と統計多重効果の影響を考慮したトラフィック制御を可能とすることにある。
【0009】
【課題を解決するための手段】
本発明は、事前の統計解析によるパラメータ化とユーザーの視聴要求時にリアルタイムに判定処理を行う手続きの2つに大別される。リアルタイム手続きの際に必要となる受付判定部は、ネットワークにおける各ノード、あるいはネットワーク内に存在するQoSサーバに置かれる。
1. 事前の統計解析によるパラメータ化
(1)映像ストリームのモデル化を行う為、事前にサーバストリームを測定しておき、ストリーム特性(P,ρ,σ)を確定させておく。また、そのストリームのコーデック種別がどのくらいのパケットロスを許容するかを調べ、許容するパケットロス率(ε)を設定しておく。
(2)ノードjでの多重特性を見積もる為、ネットワーク内で品質制御対象となる全リンクLjに対してリンク速度(Cj)とバッファ時間(Tj)を調べておく。
(3)(1),(2)の結果を元に統計解析を行い、同一のリンクにK本の(P,ρ,σ)の等しいストリームを流す場合のパケットロス率(Ploss(K))を求め、Ploss(K)<εとなるKの最大値K0を求める。
(4)A≡C/K0と定義することにより、ストリーム側条件Si(Pi,ρi,σi,εi)とノード側条件Lj(Cj,Tj)が決定した場合の多重化パラメータAijを求める。
(5)AijをAij≒αi/βjとなるα,βのパラメータに分解する。
【0010】
モデル化で定義したS(P,ρ,σ)のストリーム多重特性については、既に定式化されている(文献:謝 宇計,“情報流通プラネットホームにおけるQos保証のためのトラヒック制御”,NII Journal No.3,pp.23 −2001)。同一のリンクにK本の(P,ρ,σ)の等しいストリームを流す場合のパケットロス率(Ploss(K))は以下のように上限値を起こせることが可能である。
log(Ploss(K))=−sup[s(Kμ−C)−Klog(Kρ/C)]:S≧0
但し、μは損失無し多重化のための実行帯域と呼ばれるもので、ノードで許される遅延の最大値がバッファ時間(T)であるとすると以下のようになる。
μ=max[ρ,Pσ/{(σ+T(P−ρ)}]
このときPloss(K)<εであるための条件としては、(1)または(2)の式で表される。
K>C/μ               (1)
Klog(Kρ/C)<log(ε)   (2)
ここで(2)式は、εが十分小さく、C/ρがあまり大きくない場合には自然数の解を持たない場合があり、解を持つ場合には(Kρ/C)が1に近い値をもつという傾向がある。
全てのリンクで(2)式が解を持つ場合には(2)式を用いてパラメータを決定し、そうでない場合は(1)を用いてパラメータを決定する。
(2)式を用いる場合にはリンク種別ごとの差が殆ど無いことになるので以下のように決定する。
A=K0ρ/C,α=A,β=1      (3)
(1)式を用いる場合には、1度のバーストの時間Tonを用いて以下のようにかける。
A=μ=Pσ/{σ+T(P−ρ)}=P・/{1+T/Ton}〜σ/T:但しT〉〉Tonのとき
ここで、σはストリームの性質であり、Tはノードの性質であるから、以下のように決定できる。
α=σ/ρ,β=T            (4)
【0011】
2. ユーザーの視聴要求時にリアルタイムに判定処理を行う手続き
(1)ネットワーク内に受付判定部を置き、ネットワーク内の各リンクLjに対して、リンクLjに現在流れているストリームの使用帯域(ΣAijρiあるいはΣαiρi)を記録しておく。
(2)ユーザー端末がストリームソースに対して新規視聴要求を行うと、ストリームソースは受付け判定部に対して受付判定要求を行う。
(3)受付判定要求を受け取ると、受付判定部は品質制御の対象となるリンクを確定し、新規に視聴要求を受けたストリームの必要帯域AIjρI或いはαIρIを調べて各リンクLjに対し判定式
{ΣAijρi+AIjρIΣ<Cj}あるいは{Σαiρi+αΣρΣ<βjCj}
の値の真/偽をストリームソースに返す。
(4)真が返された場合、ストリームソースはストリームの配信を行い、配信が終了すると終了通知を受付判定部に行う。偽が返された場合はストリームソースはストリームの配信を拒否する。
(5)受付判定部では、終了通知を受け取るとストリームの使用帯域から、そのストリームの使用帯域の値を引いた値に修正する。
【0012】
【発明の実施の形態】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
〈事前統計解析によるパラメータ〉
図1に、事前の統計解析によるパラメータ化の処理フローチャートを示す。これは、後述する各実施例に共通である。
まず、事前に映像ストリームのトラヒックを測定し、映像ストリームの特性を(P、ρ、σ)でモデル化するとともに、許容するパケットロス率(ε)を決定する(S1)。図17に示したように、Pはトラヒックの最大レート、ρは長時間平均レート、δは1度のバーストのデータ量を表わす。また、ノード特性(出力側)としてネットワーク(NW)の各ノードのリンク速度C、バッファ時間(T)を調査しておく(S2)。
【0013】
次に、ステップS1、S2の結果を元に統計解析を行い、同一のリンクにK本のストリーム性(P、ρ、σ)の等しいストリームを流す場合のパケットロス率(Ploss(K))を求め、Ploss(K)<εとなるKの最大値K0を決定する(S3)。そして、このK0により、多重化パラメータA=C/K0を定義する(S4)。
【0014】
Aには入出両方の条件が関わっているため、条件を入力側、出力側に分割し、A=α/βのように、2つのパラメータα、βで表現する。ここで、αは入力側条件、βは出力側条件を表わす。
【0015】
先に述べたように、パラメータのα、βの決定は、K>C/μで、Klog(Kρ/C)<(ε)が自然数の解をもつか判定し(S5)、次のように定める。すなわち、自然数の解をもつ場合には、先の(3)式から、α=K0ρ/C、β=1とする(S6)。また、自然数の解をもたない場合には、先の(4)式から、α=α=δ/P、β=Tとする(S7)。
【0016】
以下、本発明を適用した各実施例を示す。
〈実施例1〉
これは、ストリームのソースのソースとデストネーションが判明すると経路が特定できる閉域ネットワークにおいて、視聴要求時にソースとデストネーションのEnd−to−Endで通信品質が基準を満たせるかを判定可能とするものである。
【0017】
図2に本実施例のネットワーク構成例を示す。図2において、100はストリームソース、110はノード、120はユーザ端末、130はQoSサーバであり、該QoSサーバ130内に受付判定部135が存在する。受付判定部135は、全ノードのインターフェース(IF)のリンク速度、使用帯域等を管理している。
ユーザ端末120は、ストリームソース100に対してストリームの視聴要求を行う。ストリームソース100は、ユーザ端末120の視聴要求に応じてQ0Sサーバ130の受付判定部135に受付判定要求を行い、返答が真であれば、ストリームの配信を行う。各ノード110は、経路制御に基づいてパケットを転送する。なお、受付判定部135については後述する。
【0018】
〈実施例2〉
これは、トラヒックの多重による品質劣化の起こる階梯及びノードが予め定まっているネットワークにおいて、該当するノードのバッファ時間がストリームの1度のバースト時間より十分長い範囲の場合、バースト周期及び長時間平均レートが異なるストリームが混在しても、該当するノ士ドでのパケット率の上限値を算出し、End−to−Endで通信品質が基準を満たせるかを判定可能とするものである。
【0019】
図3に本実施例のネットワーク構成例を示す。これは、アクセス区間のみがボトルネットとなる以外、図2と基本的に同じである。Q0Sサーバ130内の受付判定部135は、対象ノードのIFのリンク速度、使用帯域等を管理する。
【0020】
図4に、実施例1、2におけるストリームソース100とQ0Sサーバ130の一構成例の機能ブロック図を示す。ストリームソース100はサーバ通信プロセス部101、ストリーム配信アプリケーション部102、トラヒック分類器103、パケットスケジューラ104などで構成される。サーバ通信プロセス部101は、ユーザ端末の視聴要求に応じてQ0Sサーバ130に受付判定要求を行い、その返答を受け取り、返答が真であれば、ストリーム配信アプリケーション部102やパケットスケジュール104にストリームの配信を指示し、配信が終了すると、Q0Sサーバ130に終了通知を行うものである。その他の機能は、基本的に従来と同様である。
【0021】
Q0Sサーバ130は通信プロセッサ131、経路計算部132、受付判定部135などで構成される。通信プロセッサ131はストリームソース100や各ノード110の通信制御を司り、経路計算部132はパケットの経路選択を司るものである、これらは、本発明に直接関係しないので、詳細は省略する。本発明は受付判定部135にかかわる。
【0022】
図5にQ0Sサーバ130内の受付判定部135の構成例を示す。本受付判定部135はインターフェース機能部1351、帯域計算・判定部1352、ストリームデータ管理DB1353、ノードデータ管理DB1354、帯域使用量管理DB1355、記録媒体1356などで構成される。図6に各管理DB1353、1354、1355での管理内容の具体例を示す。
【0023】
図7は本実施例1、2における判定処理フロー例を示したものである。以下、図7にもとづいて、実施例1、2の場合のユーザ視聴要求時のリアルタイム判定処理を説明する。
Q0Sサーバ130の受付判定部135では、ネットワーク内の全ノードの現在流れているストリームの使用帯域ΣAiρiを管理している(S11)。ユーザ端末130がストリームソース100に対して新規視聴要求を行うと、ストリームソース100はQ0Sサーバ130へ受付判定要求(帯域ρ)を行う(S12)。Q0Sサーバ130は、ストリームの経路を計算し(S13)、該経路上の全ノードiに対し、ΣAiρi+AIjρIを計算して、ΣAiρi+AIjρI<Cjを判定する(S14)。そして、判定が偽なら、ストリームソース100にNGを返す(S15)。一方、判定が真ならば、経路上のリンクに対し、使用帯域ΣAiρiにAIjρIを加算し、ストリームソース100にOKを返す(S16)。ストリームソース100は、Q0Sサーバ130からOKが返されると、ストリーム配信を行い(S17)、配信が終了すると、Q0Sサーバ130へ終了報告を行う(S18)。Q0Sサーバ130は、ストリームソース100から終了報告を受け取ると、該当経路上のリンクに対し、AIjρIを使用帯域から減算する(S19)。
【0024】
〈実施例3〉
これは、各ノードが自らのもつインターフェースに関してそのリンク速度と現状の使用帯域を把握し、新規のセッションに対して必要リソースの確保が可能な場合にセッションを確立する機能をもつネットワークにおいて、ノードに見做しリンク速度(βC)を設定し、必要帯域として見做し長時間平均レート(αρ)を用いることによって、End−to−Endで通信品質が基準を満たしたときのみにストリームの送信を可能とするものである。
【0025】
図8に本実施例のネットワーク構成例を示す。図8において、100はストリームソース、110はノード、120はユーザ端末であり、各ノード110内に受付判定部115が存在する。各受付判定部115は、自ノードのIFの使用帯域(Σαρ)、リンク速度(βC)を管理している。
【0026】
ユーザ端末120はストリームソース100に対してストリームの視聴要求を行う。ストリームソース100は、該ストリームソース100が収容されるノード110(以下、受付ノード)に受付判定要求を行う。受付ノード110は、RSVP−Pathメッセージで経路上の各ノードへ帯域のαIρIを要求し、各ノードの受付判定部115で判定を行い、判定が真ならRSVP−Resvメッセージを返し、受付ノード110が、ストリームソース100に返答する。ストリームソース100は、返答が真であれば、ストリームの配信を行う。
【0027】
図9に、本実施例におけるストリームソース100と各ノード110の構成例の機能ブロック図を示す。なお、ノード110の一つが受付ノードとなる。ストリームソース100はサーバ通信プロセス部101がRSVPプロセス部105に置き替った以外、先の図4と同様である。受付ノード110はRSVPプロセッサ111、ルーティングプロセッサ112、トラフィック分類部113、受付制御部114、受付判定部115、パケットスケジューラ116などで構成される。ここで、受付判定部115が本発明にかかわる。
【0028】
図10に、各ノード内の受付判定部115の構成例を示す。本受付判定部115はインターフェース機能部1151、帯域計算・判定部1152、リンク情報管理DB1153、帯域使用量管理DB1154、記憶媒体1155などで構成される。図11に各管理DB1153、1154での管理内容の具体例を示す。
【0029】
図12は本実施例3における判定処理フローチャート例を示したものである。以下、図12にもとづいて、実施例3の場合のユーザ視聴要求時のリアルタイム判定処理を説明する。
各ノード110の受付判定部115では、自ノードの使用帯域(Σαρ)、リンク速度(βC)を管理している(S21)。ユーザ端末130がストリーム100に対して新規視聴要求を行うと、ストリームソース100は、受付ノード110へRSVP−Pathメッセージで帯域(αIρI)を要求する(S22)。メッセージを受け取った受付ノード110は、ルーティングプロトコルにより出力IFを決定し(S23)、出力IFに対して、Σαρ+αIρIを計算し、Σαρ+αIρI<βjCjを判定する(S24)。ここで、判定が偽ならば、Pathメッセージ破棄をストリームソース100に返す(S25)。一方、判定が真ならば、ユーザ端末130が直下に収容されているか判定し(S26)、収容されていない場合は、出力IFから次のノードへRSVP−Pathメッセージで帯域(αIρI)要求を行う(S27)。以下、判定が真の場合、各ノードで同様の処理を行う。ユーザ端末130が直下に収容されている場合、該当ノード110は、RSVP Resvメッセージを一つ手前に返し、該当リンクに対し、使用帯域にαIρIを加算し、受付制御部に登録する(S28)。こうして、経路上の各ノード110で判定が真だった場合、受付ノード110がRSVP−Resvメッセージをストリームソース100に返答することになる。ストリームソース100は、RSVP−Resvメッセージを受け取ると、ストリームを配信し、配信中はRSVP−Confメッセージを、受付ノードを介し、経路上の各ノード110へ送信する(S29)。各ノード110では、RSVP−Confが来なくなったら、使用帯域からαIρIを減算し、受付制御部の登録から削除する(S30)。
【0030】
〈実施例4〉
これは、ネットワーク構成は先の実施例3と同様であるが、過去にストリームを流した事のあるストリームソースに対するストリームパラメータを記憶することにより、事前解析を自動化してオンデマンに行い、End−to−Endで通信品質が基準を満たしたときのみにストリームの送信を可能とするものである。ネットワーク構成は図8と同様であり、各ノード110に受付判定部115が存在する。
【0031】
図13に、本実施例におけるストリームソース100と各ノード110の構成例の機能ブロック図を示す。ストリームソース100の構成は先の図9と同様である。ノード100の構成も、トラフィック測定部117が加付された以外、先の図9と同様である。ただし、受付判定部115の内部構成が若干相違する。
【0032】
図14に受付判定部115の構成例を示す。本受付判定部115はインタフェース機能部115、帯域計算・判定部1152、ストリームデータ管理DB1156、リンク情報管理DB1153、帯域使用量管理DB1154、記憶媒体1155などで構成される。これは、基本的には、先の図5に類似している。図15に、各管理DB1156、1153、1154における管理内容の具体例を示す。ここで、ストリームデータ管理DB1156の内容は随時追加される。
【0033】
図16に本実施例4における判定処理フローチャート例を示す。先の図12との相違は、ストリームソースのIPアドレスからパラメータ(P,ρ,Toff)を検索する処理(S34)、ストリームを配信した際に、トラヒック測定部にて、そのストリーム(ソースとディストネーションの組)に対し、パラメータ(P,Toff,ρ)を測定する処理(S41)が追加されたことである。
【0034】
なお、各実施例で示した装置における各部の一部もしくは全部の処理機能をコンピュータのプログラムで構成し、そのプログラムをコンピュータを用いて実行して本発明を実現することができること、あるいは、図1、図7、図12、図16などで示した処理手順をコンピュータのプログラムで構成し、そのプログラムをコンピュータに実行させることができることは言うまでもない。また、コンピュータでその処理機能を実現するためのプログラム、あるいは、コンピュータにその処理手順を実行させるためのプログラムを、そのコンピュータが読み取り可能な記録媒体、例えば、FDや、MO、ROM、メモリカード、CD、DVD、リムーバブルディスクなどに記録して、保存したり、提供したりすることができるとともに、インターネット等のネットワークを通してそのプログラムを配布したりすることが可能である。
【0035】
【発明の効果】
本発明によれば、バースト性の強い映像ストリームに対してもリソース予約モデルを適用して品質制御を行うことが可能となる。またパラメータをα,βの2つに分離したことにより、ノード自律分散型の品質制御への適用も可能となる。トラフィック多重効果を考慮したことにによる収容率向上の例として、市販のストリームソースとレイヤ3スイッチのデータを基にK0及びAを起算した結果を図18に示す。また、その計算データを図19に示す。先の条件式(1)で計算した場合に比べて条件式(2)で計算した結果の方が非常に収容率が高くなっていることがわかる。
【図面の簡単な説明】
【図1】本発明による事前統計解析によるパラメータ決定の処理フロー例である。
【図2】本発明の実施例1のネットワーク構成例である。
【図3】本発明の実施例2のネットワーク構成例である。
【図4】実施例1,2におけるストリームソースとQ0Sサーバの一実施例の機能ブロック図である。
【図5】Q0Sサーバ内の受付判定部の機能ブロック図である。
【図6】受付判定部内の各管理DBの管理内容である。
【図7】実施例1、2における判定処理フローチャート例である。
【図8】本発明の実施例3のネットワーク構成例である。
【図9】実施例3におけるストリームソースと各ノードの一実施例の機能ブロック図である。
【図10】各ノード内の受付判定部の機能ブロック図である。
【図11】受付判定部内の各管理DBの管理内容である。
【図12】実施例3における判定処理フローチャート例である。
【図13】本発明の実施例4におけるストリームソースと各ノードの一実施例の機能ブロック図である。
【図14】各ノード内の受付判定部の機能ブロック図である。
【図15】受付判定部内の各管理DBの管理内容である。
【図16】実施例4における判定処理フローチャート例である。
【図17】本発明で対象とする映像ストリームのストリーム特性である。
【図18】本発明による統計多重効果例を示す。
【図19】図18の計算データ例を示す。
【符号の説明】
100  ストリームソース
110  ノード
115  受付判定部
120  ユーザ端末
130  Q0Sサーバ
135  受付判定部
[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a quality control technique of an IP network, and in particular, as a quality control for a video stream traffic having a periodic burst, parameterizing a statistical multiplexing effect and using the parameter to provide a quality control function to the network. It is about technology.
[0002]
[Prior art]
In general, a video stream has a property that bursts are generated at a constant cycle and the amount of data flowing in one burst is constant. FIG. 17 shows an example of such a video stream. Stream characteristics (traffic) can be expressed by three parameters P, ρ, and σ. Here, ρ represents the long-term average rate, P represents the instantaneous maximum rate, and σ represents the amount of data flowing in one burst. Such a stream has the property of causing significant quality degradation due to packet loss, but it is difficult to control the quality by retransmission control, such as being handled by applications that use real-time properties and multicasting, and it is necessary to perform quality control on the network side. is there.
[0003]
First, as a conventional technique for performing quality control on bursty traffic, a standard technique has already been established as an ATM (Asynchronous Transfer mode) traffic control technique (literature: Paul). Ferguson; Geoff Huston, "Internet QoS", Ohmsha, pp. 123-154, 2000). The properties common to them are as follows.
1. The traffic is processed by UPC (Usage Parameter Controller) according to the convenience of the network. UPC generally prevents congestion by prohibiting excessive traffic network entry when all network resources are used.
2. A VC (virtual channel) is allocated to each flow, and control is performed on a VC basis.
3. Quality control is performed by estimating a statistical multiplexing effect by using a QoS (Quality of Service) parameter. Parameters that affect communication quality include delay time, delay variation, data loss rate, and peak speed.
[0004]
Further, as a quality assurance technology in an IP network, there is RSVP-TE using RSVP (Resource Reservation Setup Protocol) which is a protocol for managing a transmission band of a specific communication channel between routers (Reference: D. Awduch et al., “RSVP-TE: Extension to RSVP for LSP Tunnels”, IETF Networking Group RFC 3209, 2001).
1. The presence of UPC is not mandatory.
2. Since the processing is performed by the path control protocol, the processing is generally performed by autonomous distribution of each node, and the path calculation processing load is smaller than that of the ATM.
3. Many are based on a resource reservation model like RSVP-TE, and the parameters are mainly simple.
[0005]
Thus, the quality control of ATM and IP has different directions. There are other control methods at a lower layer, such as rate shaving on a VLAN basis, but these are static controls that operate independently of IP routing.
[0006]
[Problems to be solved by the invention]
The ATM traffic control technology requires the implementation of UPC, which imposes strict requirements on accommodating nodes, and allocates VCs to each flow. Therefore, when the number of flows increases, the route calculation load reduces the IP routing control. There was a problem such as a rapid increase compared to. Further, in the existing traffic control technology based on IP, only simple parameters such as a link bandwidth and a required bandwidth can be used. Therefore, the burst property is not considered. When the burst property is considered, the maximum peak rate needs to be used as the required bandwidth. There is a problem that the traffic control cannot be performed in consideration of the effect of the statistical multiplexing effect.
[0007]
These problems are problems that assume general traffic as input traffic. As described above, the output characteristics of the video stream have some regularity, and the packet loss target value is very small.
[0008]
An object of the present invention is to use such characteristics of a video stream to enable traffic control in consideration of burst characteristics and the effects of statistical multiplexing effects using an existing IP routing protocol without using UPC. It is to be.
[0009]
[Means for Solving the Problems]
The present invention is roughly classified into two procedures: a parameterization based on a statistical analysis in advance, and a procedure for performing a judgment process in real time when a user requests viewing. The reception determination unit required for the real-time procedure is placed in each node in the network or the QoS server existing in the network.
1. Parameterization by Prior Statistical Analysis (1) In order to model a video stream, a server stream is measured in advance, and stream characteristics (P, ρ, σ) are determined. In addition, it checks how much packet loss the codec type of the stream allows, and sets an allowable packet loss rate (ε).
(2) In order to estimate the multiplexing characteristic at the node j, the link speed (Cj) and the buffer time (Tj) are checked for all the links Lj to be quality controlled in the network.
(3) Statistical analysis is performed based on the results of (1) and (2), and the packet loss rate (Ploss (K)) when K (P, ρ, σ) streams are sent through the same link Is obtained, and the maximum value K0 of K satisfying Ploss (K) <ε is obtained.
(4) By defining A≡C / K0, a multiplexing parameter Aij when the stream-side conditions Si (Pi, ρi, σi, εi) and the node-side conditions Lj (Cj, Tj) are determined is obtained.
(5) Aij is decomposed into α and β parameters such that Aij ≒ αi / βj.
[0010]
The stream multiplexing characteristic of S (P, ρ, σ) defined by modeling has already been formalized (Literature: Kei Ue, "Traffic Control for Guaranteeing QoS in Information Sharing Planet Home", NII Journal No. 3, pp. 23-2001). The packet loss rate (Ploss (K)) when K streams with the same (P, ρ, σ) flow through the same link can have an upper limit as follows.
log (Ploss (K)) = − sup [s (Kμ−C) −Klog (Kρ / C)]: S ≧ 0
Here, μ is called an execution band for lossless multiplexing, and assuming that the maximum value of the delay allowed at the node is the buffer time (T), the following is obtained.
μ = max [ρ, Pσ / {(σ + T (P-ρ)}]
At this time, the condition for Ploss (K) <ε is expressed by the equation (1) or (2).
K> C / μ (1)
Klog (Kρ / C) <log (ε) (2)
Here, equation (2) indicates that if ε is sufficiently small and C / ρ is not so large, there is a case where a natural number solution is not provided. Tend to have.
If equation (2) has a solution for all links, the parameters are determined using equation (2); otherwise, the parameters are determined using (1).
When equation (2) is used, there is almost no difference for each link type.
A = K0ρ / C, α = A, β = 1 (3)
When the equation (1) is used, the following operation is performed using the time Ton of one burst.
A = [mu] = P [sigma] / {[sigma] + T (P- [rho])} = P * / {1 + T / Ton} ~ [sigma] / T where T >>> where Ton is the property of the stream, and T is the node Because of the nature, it can be determined as follows.
α = σ / ρ, β = T (4)
[0011]
2. Procedure for performing determination processing in real time when a user requests viewing (1) A reception determination unit is placed in the network, and for each link Lj in the network, the used bandwidth (ス ト リ ー ム Aijρi or Σαipi) of the stream currently flowing on the link Lj Make a note of it.
(2) When the user terminal issues a new viewing request to the stream source, the stream source issues an acceptance determination request to the acceptance determination unit.
(3) Upon receiving the reception determination request, the reception determination unit determines the link to be subjected to quality control, checks the required bandwidth AIjρI or αIρI of the stream for which the new viewing request has been received, and determines the determination formula {for each link Lj. {Aijρi + AIjρI} <Cj} or {αipi + α {ρ} <βjCj}
Returns true / false of the value of to the stream source.
(4) If true is returned, the stream source distributes the stream, and when the distribution ends, notifies the reception determination unit of an end. If false is returned, the stream source refuses to deliver the stream.
(5) Upon receiving the end notification, the reception determining unit corrects the used bandwidth of the stream to a value obtained by subtracting the value of the used bandwidth of the stream.
[0012]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
<Parameters by prior statistical analysis>
FIG. 1 shows a processing flowchart of parameterization by prior statistical analysis. This is common to each embodiment described later.
First, the traffic of the video stream is measured in advance, the characteristics of the video stream are modeled by (P, ρ, σ), and the allowable packet loss rate (ε) is determined (S1). As shown in FIG. 17, P indicates the maximum traffic rate, ρ indicates the long-term average rate, and δ indicates the data amount of one burst. Further, the link speed C and the buffer time (T) of each node of the network (NW) are investigated as node characteristics (output side) (S2).
[0013]
Next, a statistical analysis is performed based on the results of steps S1 and S2, and the packet loss rate (Ploss (K)) when K streams with the same stream characteristics (P, ρ, σ) flow on the same link is calculated. Then, the maximum value K0 of K that satisfies Ploss (K) <ε is determined (S3). Then, the multiplexing parameter A = C / K0 is defined by the K0 (S4).
[0014]
Since both input and output conditions are involved in A, the condition is divided into an input side and an output side, and is expressed by two parameters α and β, such as A = α / β. Here, α represents an input condition and β represents an output condition.
[0015]
As described above, the parameters α and β are determined by determining whether Klog (Kρ / C) <(ε) has a natural number solution, where K> C / μ (S5). Determine. That is, when a solution having a natural number is provided, α = K0ρ / C and β = 1 are set based on the equation (3) (S6). If there is no natural number solution, α = α = δ / P and β = T from the above equation (S7).
[0016]
Hereinafter, each embodiment to which the present invention is applied will be described.
<Example 1>
In a closed network in which the source and destination of a stream can be identified when the source and destination of the stream are known, it is possible to determine whether or not the communication quality can meet the standard by the end-to-end of the source and destination at the time of a viewing request. is there.
[0017]
FIG. 2 shows a network configuration example of the present embodiment. In FIG. 2, 100 is a stream source, 110 is a node, 120 is a user terminal, 130 is a QoS server, and an acceptance determination unit 135 exists in the QoS server 130. The reception determination unit 135 manages the link speed, the used bandwidth, and the like of the interfaces (IFs) of all the nodes.
The user terminal 120 makes a stream viewing request to the stream source 100. The stream source 100 makes a reception determination request to the reception determination unit 135 of the QoS server 130 in response to the viewing request of the user terminal 120, and if the answer is true, distributes the stream. Each node 110 transfers a packet based on the route control. The reception determination unit 135 will be described later.
[0018]
<Example 2>
This is because when the buffer time of the corresponding node is sufficiently longer than the burst time of a single stream in a network where the steps and nodes where the quality degradation due to traffic multiplexing occurs are predetermined, the burst period and the long-term average rate Even if streams differing from each other, the upper limit value of the packet rate at the corresponding node is calculated, and it is possible to determine whether the communication quality can meet the criterion by End-to-End.
[0019]
FIG. 3 shows a network configuration example according to the present embodiment. This is basically the same as FIG. 2 except that only the access section is a bottle net. The reception determination unit 135 in the QoS server 130 manages the link speed, the used bandwidth, and the like of the IF of the target node.
[0020]
FIG. 4 shows a functional block diagram of a configuration example of the stream source 100 and the QoS server 130 in the first and second embodiments. The stream source 100 includes a server communication processing unit 101, a stream distribution application unit 102, a traffic classifier 103, a packet scheduler 104, and the like. The server communication processing unit 101 makes an acceptance determination request to the QOS server 130 in response to the viewing request of the user terminal, receives the response, and if the response is true, distributes the stream to the stream distribution application unit 102 and the packet schedule 104. When the distribution is completed, the QOS server 130 is notified of the completion. Other functions are basically the same as the conventional one.
[0021]
The QoS server 130 includes a communication processor 131, a route calculation unit 132, a reception determination unit 135, and the like. The communication processor 131 manages the communication control of the stream source 100 and each node 110, and the route calculation unit 132 controls the route selection of the packet. Since these are not directly related to the present invention, the details are omitted. The present invention relates to the reception determining unit 135.
[0022]
FIG. 5 shows a configuration example of the reception determining unit 135 in the QoS server 130. The reception determination unit 135 includes an interface function unit 1351, a bandwidth calculation / determination unit 1352, a stream data management DB 1353, a node data management DB 1354, a bandwidth usage management DB 1355, a recording medium 1356, and the like. FIG. 6 shows a specific example of the management contents in each of the management DBs 1353, 1354, and 1355.
[0023]
FIG. 7 shows an example of a determination processing flow in the first and second embodiments. Hereinafter, a real-time determination process at the time of a user viewing request in the first and second embodiments will be described with reference to FIG.
The acceptance determining unit 135 of the QoS server 130 manages the bandwidth ΣAipi of the stream currently flowing in all nodes in the network (S11). When the user terminal 130 issues a new viewing request to the stream source 100, the stream source 100 makes an acceptance determination request (bandwidth ρ) to the QoS server 130 (S12). The QoS server 130 calculates the path of the stream (S13), calculates ΣAipi + AIjρI for all nodes i on the path, and determines ΣAipi + AIjρI <Cj (S14). If the determination is false, NG is returned to the stream source 100 (S15). On the other hand, if the judgment is true, AIjρI is added to the used band ΣAipi for the link on the route, and OK is returned to the stream source 100 (S16). When the OK is returned from the QOS server 130, the stream source 100 performs stream distribution (S17), and when the distribution ends, reports an end to the QOS server 130 (S18). Upon receiving the end report from the stream source 100, the QoS server 130 subtracts AIjρI from the used band for the link on the corresponding path (S19).
[0024]
<Example 3>
This is because in a network that has the function of grasping the link speed and current bandwidth used by each node for its own interface and establishing a session when necessary resources can be secured for a new session, By setting the assumed link speed (βC) and using the assumed long-term average rate (αρ) as the required band, the stream transmission is performed only when the communication quality meets the criterion in End-to-End. It is possible.
[0025]
FIG. 8 shows a network configuration example of the present embodiment. In FIG. 8, reference numeral 100 denotes a stream source, 110 denotes a node, and 120 denotes a user terminal. Each reception determination unit 115 manages the IF band (Σαρ) and the link speed (βC) of the IF of the own node.
[0026]
The user terminal 120 issues a stream viewing request to the stream source 100. The stream source 100 makes a reception determination request to a node 110 (hereinafter, a reception node) in which the stream source 100 is accommodated. The receiving node 110 requests the αIρI of the band to each node on the route by an RSVP-Path message, makes a determination in the reception determining unit 115 of each node, and returns a RSVP-Resv message if the determination is true. , To the stream source 100. If the response is true, the stream source 100 distributes the stream.
[0027]
FIG. 9 shows a functional block diagram of a configuration example of the stream source 100 and each node 110 in the present embodiment. Note that one of the nodes 110 is a receiving node. The stream source 100 is the same as that of FIG. 4 except that the server communication processing unit 101 is replaced with the RSVP processing unit 105. The reception node 110 includes an RSVP processor 111, a routing processor 112, a traffic classification unit 113, a reception control unit 114, a reception determination unit 115, a packet scheduler 116, and the like. Here, the reception determination unit 115 is related to the present invention.
[0028]
FIG. 10 shows a configuration example of the reception determining unit 115 in each node. The reception determination unit 115 includes an interface function unit 1151, a bandwidth calculation / determination unit 1152, a link information management DB 1153, a bandwidth usage management DB 1154, a storage medium 1155, and the like. FIG. 11 shows a specific example of management contents in the management DBs 1153 and 1154.
[0029]
FIG. 12 shows an example of a determination processing flowchart in the third embodiment. Hereinafter, a real-time determination process at the time of a user viewing request in the third embodiment will be described with reference to FIG.
The reception determination unit 115 of each node 110 manages the band used (自 αρ) and the link speed (βC) of the own node (S21). When the user terminal 130 issues a new viewing request to the stream 100, the stream source 100 requests a band (αIρI) from the receiving node 110 by an RSVP-Path message (S22). The receiving node 110 that has received the message determines the output IF according to the routing protocol (S23), calculates Σαρ + αIρI for the output IF, and determines Σαρ + αIρI <βjCj (S24). Here, if the determination is false, return the Path message discard to the stream source 100 (S25). On the other hand, if the determination is true, it is determined whether the user terminal 130 is accommodated immediately below (S26). If not, the bandwidth (αIρI) is requested from the output IF to the next node by an RSVP-Path message. (S27). Hereinafter, when the determination is true, similar processing is performed in each node. When the user terminal 130 is accommodated immediately below, the corresponding node 110 returns the RSVP Resv message one immediately before, adds αIρI to the used band for the corresponding link, and registers it in the reception control unit (S28). Thus, when the determination is true at each node 110 on the route, the receiving node 110 replies an RSVP-Resv message to the stream source 100. Upon receiving the RSVP-Resv message, the stream source 100 distributes the stream, and transmits the RSVP-Conf message to each node 110 on the route via the receiving node during distribution (S29). In each node 110, when RSVP-Conf does not come, αIρI is subtracted from the used band and deleted from the registration of the reception control unit (S30).
[0030]
<Example 4>
The network configuration is the same as that of the third embodiment. However, by storing the stream parameters for the stream sources to which the stream has been streamed in the past, the pre-analysis is automated and performed on demand, and the end-to-end is performed. The stream transmission is enabled only when the communication quality satisfies the criterion in -End. The network configuration is the same as that of FIG. 8, and each node 110 has a reception determination unit 115.
[0031]
FIG. 13 shows a functional block diagram of a configuration example of the stream source 100 and each node 110 in the present embodiment. The configuration of the stream source 100 is the same as that of FIG. The configuration of the node 100 is the same as that of FIG. 9 except that the traffic measurement unit 117 is added. However, the internal configuration of the reception determination unit 115 is slightly different.
[0032]
FIG. 14 illustrates a configuration example of the reception determination unit 115. The reception determination unit 115 includes an interface function unit 115, a bandwidth calculation / determination unit 1152, a stream data management DB 1156, a link information management DB 1153, a bandwidth usage management DB 1154, a storage medium 1155, and the like. This is basically similar to FIG. 5 described above. FIG. 15 shows a specific example of management contents in each management DB 1156, 1153, 1154. Here, the contents of the stream data management DB 1156 are added as needed.
[0033]
FIG. 16 shows an example of a flowchart of the determination process in the fourth embodiment. The difference from FIG. 12 is that the process (S34) of searching for the parameters (P, ρ, Toff) from the IP address of the stream source, and when the stream is distributed, the traffic measurement unit detects the stream (source and destination). That is, a process (S41) for measuring the parameter (P, Toff, ρ) is added to the set of nations.
[0034]
It is to be noted that a part or all of the processing functions of each unit in the apparatus shown in each embodiment are configured by a computer program, and that the program can be executed by a computer to realize the present invention. Needless to say, the processing procedures shown in FIG. 7, FIG. 12, FIG. 16, and the like can be configured by a computer program, and the computer can execute the program. In addition, a program for realizing the processing function by the computer or a program for causing the computer to execute the processing procedure is stored in a computer-readable recording medium such as an FD, an MO, a ROM, a memory card, The program can be recorded on a CD, a DVD, a removable disk, or the like, stored and provided, and the program can be distributed through a network such as the Internet.
[0035]
【The invention's effect】
According to the present invention, it is possible to perform quality control by applying the resource reservation model to a video stream having a strong burst property. Also, by separating the parameters into two, α and β, it is also possible to apply to quality control of a node autonomous distributed type. As an example of the improvement of the accommodation ratio by considering the traffic multiplexing effect, FIG. 18 shows the result of calculating K0 and A based on the data of a commercially available stream source and the data of the layer 3 switch. FIG. 19 shows the calculated data. It can be seen that the accommodation ratio is much higher in the result calculated in conditional expression (2) than in the case calculated in conditional expression (1).
[Brief description of the drawings]
FIG. 1 is an example of a processing flow of parameter determination by prior statistical analysis according to the present invention.
FIG. 2 is an example of a network configuration according to a first embodiment of the present invention.
FIG. 3 is an example of a network configuration according to a second embodiment of the present invention.
FIG. 4 is a functional block diagram of a stream source and a QoS server according to the first and second embodiments.
FIG. 5 is a functional block diagram of a reception determining unit in the QoS server.
FIG. 6 shows management contents of each management DB in the reception determination unit.
FIG. 7 is a flowchart illustrating an example of a determination process according to the first and second embodiments.
FIG. 8 is an example of a network configuration according to a third embodiment of the present invention.
FIG. 9 is a functional block diagram of a stream source and each node according to a third embodiment;
FIG. 10 is a functional block diagram of a reception determining unit in each node.
FIG. 11 shows management contents of each management DB in the reception determination unit.
FIG. 12 is a flowchart illustrating an example of a determination process according to a third embodiment.
FIG. 13 is a functional block diagram of a stream source and each node according to a fourth embodiment of the present invention.
FIG. 14 is a functional block diagram of a reception determining unit in each node.
FIG. 15 shows management contents of each management DB in the reception determination unit.
FIG. 16 is a flowchart illustrating an example of a determination process according to a fourth embodiment.
FIG. 17 shows stream characteristics of a video stream targeted by the present invention.
FIG. 18 shows an example of a statistical multiplexing effect according to the present invention.
FIG. 19 shows an example of calculation data of FIG.
[Explanation of symbols]
100 stream source 110 node 115 reception determination unit 120 user terminal 130 QoS server 135 reception determination unit

Claims (7)

バーストの周期が一定でかつ1度のバーストのデータ量が一定している映像ストリームを出力するストリームソースをもつネットワークにおいて、1つのノードに複数のストリームを入力させ一つのリンクからトラフィックを多重して出力させる際に、ノードバッファにより吸収できずに発生するパケットロス率の上限値を算出し、通信品質が基準を満たしているかを判定して、映像ストリームの品質を制御する方法であって、
ストリームソースが複数の長時間平均レートを選択することが可能でかつ長時間レートが変化してもバーストの周期が一定で1度のバーストのデータ量が変化する性質をもち、各ノードのバッファ時間がストリームの1度のバースト時間より十分長い範囲において、長時間平均レートの違うストリームが混在しても、通信品質が基準を満たしているかを判定することを特徴とする映像ストリームの品質制御方法。
In a network having a stream source that outputs a video stream in which the burst period is constant and the data amount of a single burst is constant, a plurality of streams are input to one node and traffic is multiplexed from one link. When outputting, a method of calculating the upper limit of the packet loss rate that occurs without being absorbed by the node buffer, determines whether the communication quality satisfies the standard, and controls the quality of the video stream,
The stream source is capable of selecting a plurality of long-term average rates, and has a property that the burst period is constant and the data amount of one burst changes even if the long-term rate changes, and the buffer time of each node A video stream quality control method characterized by determining whether communication quality satisfies a standard even if streams having different long-term average rates are mixed in a range sufficiently longer than one burst time of the stream.
請求項1記載の映像ストリームの品質制御方法において、ストリームのソースとデストネーションが判明すると経路が特定できる閉域ネットワークにおいて、視聴要求時にソースとデストネーションのEnd−to−Endで通信品質が基準を満たせるかを判定することを特徴とする映像ストリームの品質制御方法。2. The video stream quality control method according to claim 1, wherein in a closed network in which a route can be specified when the source and destination of the stream are known, the communication quality can be satisfied by the end-to-end of the source and destination at the time of a viewing request. A video stream quality control method, characterized in that the method 請求項1記載の映像ストリームの品質制御方法において、各ノードが自らのもつインターフェイスに関してそのリンク速度と現状の使用帯域を把握し新規のセッションに対して必要リソースの確保が可能な場合にセッションを確立する機能をもつネットワークにおいて、ノードに見倣しリンク速度を設定し、必要帯域として見倣し長時間平均レートを用いることによって、End−to−Endで通信品質が基準を満たしたときのみにストリームの送信を可能とすることを特徴とする映像ストリームの品質制御方法。2. The video stream quality control method according to claim 1, wherein each node grasps the link speed and the current bandwidth used for its own interface and establishes a session when necessary resources can be secured for a new session. In a network having the function of performing the communication, a link speed is set by imitating a node, and a long-term average rate is imitated as a required bandwidth, so that a stream can be streamed only when communication quality satisfies an end-to-end standard. A quality control method of a video stream, which enables transmission of a video stream. 請求項1記載の映像ストリームの品質制御方法において、トラフィックの多重による品質劣化の起こる階梯及びノードが予め定まっているネットワークにおいて、該当するノードのバッファ時間がストリームの1度のバースト時間より十分長い範囲の場合、バースト周期及び長時間平均レートが異なるストリームが混在しても、該当するノードでのパケットロス率の上限値をを算出し、End−to−Endで通信品質が基準を満たせるかを判定可能とすることを特徴とする映像ストリームの品質制御方法。2. The video stream quality control method according to claim 1, wherein in a network in which a step and a node in which quality deterioration due to traffic multiplexing occurs are predetermined, a buffer time of the node is sufficiently longer than one burst time of the stream. In the case of, even if streams with different burst periods and long-term average rates coexist, the upper limit of the packet loss rate at the corresponding node is calculated, and it is determined whether the communication quality can meet the standard by End-to-End. A quality control method for a video stream, wherein the quality control method is enabled. 請求項3記載の映像ストリームの品質制御方法において、過去にストリームを流した事のあるストリームソースに対するストリームパラメータを記憶することにより、事前解析を自動化してオンデマンドに行い、End−to−Endで通信品質が基準を満たしたときのみにストリームの送信を可能とすることを特徴とする映像ストリームの品質制御方法。4. The video stream quality control method according to claim 3, wherein the pre-analysis is performed on demand by automating the pre-analysis by storing the stream parameters for the stream sources to which the stream has been streamed in the past. A video stream quality control method characterized in that a stream can be transmitted only when communication quality satisfies a standard. 請求項1乃至5記載の映像ストリームの品質制御方法をコンピュータで実行するためのプログラム。A program for causing a computer to execute the video stream quality control method according to claim 1. 請求項1乃至5記載の映像ストリームの品質制御方法をコンピュータで実行するためのプログラムを記録した記録媒体。A recording medium recording a program for executing the method of controlling the quality of a video stream according to claim 1 on a computer.
JP2002236734A 2002-08-14 2002-08-14 Video stream quality control method, program thereof and recording medium Expired - Lifetime JP3783947B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2002236734A JP3783947B2 (en) 2002-08-14 2002-08-14 Video stream quality control method, program thereof and recording medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2002236734A JP3783947B2 (en) 2002-08-14 2002-08-14 Video stream quality control method, program thereof and recording medium

Publications (2)

Publication Number Publication Date
JP2004080279A true JP2004080279A (en) 2004-03-11
JP3783947B2 JP3783947B2 (en) 2006-06-07

Family

ID=32020777

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002236734A Expired - Lifetime JP3783947B2 (en) 2002-08-14 2002-08-14 Video stream quality control method, program thereof and recording medium

Country Status (1)

Country Link
JP (1) JP3783947B2 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008546279A (en) * 2005-05-24 2008-12-18 マイクロソフト コーポレーション Strategies for scheduling bandwidth-consuming media events
JP2010087675A (en) * 2008-09-30 2010-04-15 Nec Corp Network system, control device, and method of controlling communication flow
JP2011024214A (en) * 2009-07-17 2011-02-03 Ntt Docomo Inc Service multiplexing method and apparatus

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008546279A (en) * 2005-05-24 2008-12-18 マイクロソフト コーポレーション Strategies for scheduling bandwidth-consuming media events
JP4690457B2 (en) * 2005-05-24 2011-06-01 マイクロソフト コーポレーション Strategies for scheduling bandwidth-consuming media events
JP2010087675A (en) * 2008-09-30 2010-04-15 Nec Corp Network system, control device, and method of controlling communication flow
JP2011024214A (en) * 2009-07-17 2011-02-03 Ntt Docomo Inc Service multiplexing method and apparatus

Also Published As

Publication number Publication date
JP3783947B2 (en) 2006-06-07

Similar Documents

Publication Publication Date Title
US7327681B2 (en) Admission control method in internet differentiated service network
Braun et al. End-to-end quality of service over heterogeneous networks
CN101378357A (en) Network system
WO2001006714A1 (en) Scheduling and admission control of packet data traffic
JP3783947B2 (en) Video stream quality control method, program thereof and recording medium
Lu Issues and technologies for supporting multimedia communications over the Internet
Nyambo et al. Quality of service in mobile ad hoc networks, carrying multimedia traffic
EP1698123B1 (en) Method for controlling forwarding quality in a data network
Más et al. Probe-based admission control for a differentiated-services internet
Pinto et al. Lightweight admission control and traffic management with SDN
Domżał et al. Efficient congestion control mechanism for flow‐aware networks
Gerla et al. Resource allocation and admission control styles in QoS DiffServ networks
Pagani et al. Distributed bandwidth broker for QoS multicast traffic
Cobb Scalable quality of service across multiple domains
JP2006121410A (en) Communication apparatus
Anjum et al. Bandwidth Allocation for Video Under Quality of Service Constraints
Antila et al. Adaptive scheduling for improved quality differentiation
Nanda Supporting QoS Guarantees Using Traffic Engineering and Policy Based Routing
Calarco et al. Implementation of Implicit QoS Control in a modular software router context
Villa et al. Improving Fairness in QoS and QoE domains for Adaptive Video Streaming
Császár et al. Resilient reduced-state resource reservation
KR100597591B1 (en) The Apparatus and Method For Multi-level Controlling Of Congestion
Georgoulas et al. On the location-awareness of bandwidth allocation and admission control for the support of real-time traffic in class-based IP networks
Eberspächer et al. QoS Architectures and Resource Management in the Intranet
Bai et al. Managing QoS requirements for video streaming: from intra‐node to inter‐node

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20040302

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20050427

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20050802

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20050929

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20060309

R151 Written notification of patent or utility model registration

Ref document number: 3783947

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

Year of fee payment: 3

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

Free format text: PAYMENT UNTIL: 20100324

Year of fee payment: 4

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

Free format text: PAYMENT UNTIL: 20110324

Year of fee payment: 5

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

Free format text: PAYMENT UNTIL: 20110324

Year of fee payment: 5

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

Free format text: PAYMENT UNTIL: 20120324

Year of fee payment: 6

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

Free format text: PAYMENT UNTIL: 20130324

Year of fee payment: 7

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

EXPY Cancellation because of completion of term