JP6442507B2 - ネットワークのデバイスにより実行される進行中のトラフィックセッションの中でネットワークの利用可能な帯域幅を割り当てる方法、対応するデバイス - Google Patents

Description

本開示は、一般に、例えば、これだけに限らないが、適応型ストリーミングクライアントを含むネットワークにおける帯域幅割当てに関する。

このセクションは、以下で述べられる、かつ／または特許請求される本開示の様々な特徴に関連し得る技術の様々な特徴を読者に紹介するように意図されている。この論議は、本開示の様々な特徴を理解しやすくするための背景情報を読者に提供するのに役立つと考えられる。したがって、これらの記述はこの観点で読まれるべきであり、従来技術を取り込むことではないことを理解されたい。

ＨＴＴＰ適応型技術は、様々な投資者により推進され、インターネットにおけるオーバーザトップ（over the top）オーディオビジュアル配信を可能にしている。このような技術は、クライアントデバイスが、ビデオを、いわゆるチャンクと呼ばれる、小さな連続するセグメント（数秒の長さ）の形態で受信できるようにする。各セグメントは、ＨＴＴＰプロトコルを介して要求され、様々な変形形態（いわゆる表現）で存在することができ、クライアントデバイスが、ネットワークおよびデバイス制約に適合する適切なビットレートをいつでも選択できるようにする。

すでに使用されているＨＴＴＰ適応型ストリーミング（ＨＡＳ）プロトコルの中で、最も有名なものは、ＡｐｐｌｅからのＨＴＴＰライブストリーミング（ＨＬＳ）、Ｍｉｃｒｏｓｏｆｔからのシルバーライトスムースストリーミング（ＳＳＳ）、ＡｄｏｂｅからのＨＴＴＰ動的ストリーミング（ＨＤＳ）、およびＳＡ４グループ内の３ＧＰＰにより始められ、ＭＰＥＧにより発展された動的適応型ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）である。これらのＨＴＴＰ適応型ストリーミングの既存技法は、マニフェストファイルのフォーマットを変え、マニフェストは、コンテンツオプション（ビットレート、画像のディメンジョン、フレームレート・・・）を記述するためのメタデータを提供し、コンテンツの利用可能な表現を、セグメントで、サポートされるコーデックで、およびコンテンツ保護技術で編成することを提供する。

特に、クライアントデバイスがオーディオ／ビデオコンテンツを再生することを望む場合、それはまず、この特定のコンテンツをどのようにして取得できるかを記述するそのようなマニフェストを得る必要がある。これは、ＵＲＬから何らかの「ファイル」を得ることにより、ＨＴＴＰを介して行われる。このマニフェストファイルは、コンテンツの（ビットレートおよび他の特性による）利用可能な表現を一覧にし、また各表現に対して、ＵＲＬは、各時間スライスに対するコンテンツのチャンクをロード可能にする。ビデオオンデマンド（ＶｏＤ）の場合、Ａ／Ｖコンテンツ全体の記述が提供されるが、ライブコンテンツ（例えば、ＴＶコンテンツ）の場合、その記述は、短い時間期間をカバーするだけであり、時間が経過したとき、周期的に再ロードして新しい項目を見出す必要がある。

その機能、およびネットワーク化環境からそれが有する知識に応じて、クライアントデバイスは、（例えば、そのビットレートに基づき）１つの表現を選択し、かつコンテンツの第１のチャンク（複数可）をロードする。それは、ネットワーク障害に対処できるようにいくつかのチャンクをバッファする。次いで、Ａ／Ｖコンテンツは、各受信されたチャンクから順次再生される。同時に、クライアントデバイスは、受信レートを測定し、より高いビットレート、またはより低いビットレートを選択することを判断することができる。このような場合、それは、別の表現に次のチャンク（複数可）を要求するだけである。あらゆるＨＴＴＰストリーミング技法は、クライアントデバイスが、所与のビットレートを有するチャンクから、別のビットレートを有する次のチャンクへと切換えながら、連続的な再生（playout）を確実に行うことを可能にする。このように、ネットワーク上で競合するトラフィックが、Ａ／Ｖコンテンツを受信するレートで変動をもたらすとき、クライアントデバイスは、バッファ充足量を安全なレベルに維持できるビットレートを有するチャンクを選択することにより対応し、かつ適合させることができる。実際に、クライアントデバイスは、レンダリングが、データの遅延した受信を経験することのないレベルに留まりながら、エンドユーザに良好な閲覧品質を提供する、最大限可能なビットレートに達するように試みる。

これらのＨＡＳ技法は、前から存在する技術と比較したとき、適度に良好に動作することを示しているが、最近の研究は、いくつかの特有の困難な状況（すなわち、障害時における別のＨＡＳクライアントまたは別のＴＣＰフローとの競合）下で、ＨＡＳ実装形態は、重大な不安定問題を生ずる可能性があると指摘している。

特に、帯域幅を求めて競合する２つのＨＡＳクライアントを有することは、予測できない結果を生じ、最終的にユーザエクスペリエンスを危険にさらすことが観察された。加えてＨＡＳデバイスは、帯域幅が評価されず、過小評価される可能性のあるＯＦＦ期間を生ずるその周期的なダウンロードプロファイルのため、貪欲な（greedy）ＴＣＰフロー（例えば、バルクトラフィックなど）と競合する場合、それらの帯域幅の正当な割り当てを取り戻す能力がないことを示している。また特にこれらのＯＦＦ期間中に、他のＴＣＰフローは、帯域幅を取り込む機会を得ることができる。

本開示は、これだけに限らないが、少なくとも、他のストリームが存在するすべての適応型ストリーミング実装形態の特性である不安定および帯域幅共用問題を改善するように試みるものである。

本発明は、ネットワークのデバイスにより実行される進行中のトラフィックセッションの中で、ネットワークの利用可能な帯域幅を割り当てるための方法に関し、その方法は、所与のデバイスで、
− 少なくとも１つのトラフィックセッションを実行する上記ネットワークのデバイスから状態メッセージを収集するステップと、
− 状態メッセージから取得されたデバイスおよびトラフィックセッションのパラメータに従ってランク付けされた各トラフィックセッションに、上記ネットワークの利用可能な帯域幅、上記ランク付けされたトラフィックセッションのランク、および上記ランク付けされたトラフィックセッションのタイプに応じて、割り振られる帯域幅を決定するステップと、
− 所与のデバイスのトラフィックセッションに割り振られる上記決定された帯域幅がゼロを超える場合、上記トラフィックセッションに対して上記所与のデバイスにより上記割り振られた帯域幅を使用するステップと、
を含むことは注目に値する。

本開示により、ネットワークのデバイスは、それらのそれぞれに対して最適な帯域幅を協調して決定することができ、したがって、最良の可能な集合的ユーザエクスペリエンスを有効に達成することができる。状態メッセージにより、デバイスは、その各特性および必要条件を交換し、かつ知らせる。この情報に基づき、各デバイスが、近似することによる無駄な帯域幅を回避し、それが真に受けるに足る帯域幅を受け取ることのできるように、最適な帯域幅の再分割を計算することができる。

本開示に準拠する例として、状態メッセージは、以下の要素の少なくともいくつかを含むことができる：
− セッション開始時間；
− セッション終了時間；
− セッションを実行するデバイスのタイプ；
− ディスプレイのサイズ；
− デバイスのディスプレイ解像度；
− ユーザの数；
− セッションのタイプ；
− 固定されたストリーミングセッションに必要なビットレート；
− 適応型ストリーミングセッションに利用可能なビットレートのリスト；
− 適応型ストリーミングセッションに望ましい最大のビットレート；
− バルクトラフィックセッションに望ましい最大のビットレート；
− 適応型ストリーミングセッションに対するチャンク持続期間；
− デバイスの優先順位。

１つの状態メッセージは、１つの進行中のトラフィックセッションと関係付けられることが好ましい。

加えて、本開示によると、状態メッセージは、イベントが生じたとき、そのネットワークのすべてのデバイスにその所与のデバイスにより送られる。

特に上記イベントは、少なくとも以下のイベントを含むグループに属することができる：
− 所与のデバイスによるトラフィックセッションの開始；
− 所与のデバイスによるトラフィックセッションの停止；
− 所与のデバイスにより実行される進行中のトラフィックセッションのいずれかの特性の変更。

本開示のさらなる特徴によると、ランク付け中に、上記トラフィックセッションのそれぞれに対するランクは、有利には、上記トラフィックセッションを実行する上記デバイスの優先順位、上記デバイスのタイプ、および上記トラフィックセッションのタイプに基づいて決定され得る。

加えて所与のランク内で、対応するトラフィックセッションは、それらの開始時間に応じて順序付けできることが好ましい。

さらに上記ネットワークの上記利用可能な帯域幅は、上記ネットワークのゲートウェイにより提供されることができる。

さらに、本開示の実施形態では、上記ランク付けされたトラフィックセッションに割り振られる帯域幅の決定は、
− まだ未処理の最も高くランク付けされたトラフィックセッションを選択するステップと、
− 上記選択されたトラフィックセッションが、固定レートのストリーミングセッションであるか否かを調べるステップと、
− 上記ネットワークの現在利用可能な帯域幅と、上記固定レートのストリーミングセッションに関連付けられた必要なビットレートとの間の差が、少なくともゼロに等しいとき、上記選択されたトラフィックセッションに帯域幅を割り振るステップと、
を含む。

上記の実施形態の別の特徴では、上記ランク付けされたトラフィックセッションに割り振られる帯域幅の決定は、上記選択されたトラフィックセッションが適応型ストリーミングセッションである場合、
− まだ未処理の、上記選択されたトラフィックセッションと同じランクを有するトラフィックセッションの数により分割された、上記現在利用可能な帯域幅に多くても等しいビットレートを選択するステップと、
− 上記選択されたビットレートと、上記選択されたトラフィックセッションに関連付けられた最大の望ましいビットレートとの間の最小のビットレートを決定するステップと、
− 上記最小のビットレートを、上記選択されたトラフィックセッションに割り振るステップと、
をさらに含むことができる。

上記実施形態のさらなる特徴では、上記ランク付けされたトラフィックセッションに割り振られる帯域幅の決定は、上記割り振られた帯域幅により、現在利用可能な帯域幅を減少させるステップをさらに含むことができる。

さらに本開示はまた、上記ネットワークのデバイスの進行中のトラフィックセッションの中で上記ネットワークの利用可能な帯域幅を割り当てるための方法を実装するように構成されたネットワークのデバイスに関する。

本開示によると、上記デバイスは、
− 少なくとも１つのトラフィックセッションを実行するネットワークのデバイスから状態メッセージを収集するように適合された通信モジュールと、
− 状態メッセージから取得されたデバイスおよびトラフィックセッションのパラメータに従って上記進行中のトラフィックセッションをランク付けするように構成されたランク付けモジュールと、
− 上記利用可能な帯域幅、上記ランク付けされたトラフィックセッションのランク、および上記ランク付けされたトラフィックセッションのタイプに応じて、各ランク付けされたトラフィックセッションに割り振られる帯域幅を決定するように構成された計算器と、
− 上記デバイスのトラフィックセッションに割り振られる上記決定された帯域幅が、ゼロとは異なるか否かを調べることのできる比較器と、
を備える。

上記通信モジュールは、状態メッセージを上記ネットワークのすべてのデバイスに送るようにさらに構成することができる。

さらに上記ランク付けモジュールは、上記トラフィックセッションを実行するデバイスの優先順位、上記デバイスのタイプ、および上記トラフィックセッションのタイプに基づいて、上記トラフィックセッションのそれぞれに対してランクを決定できるので有利である。

本開示は、上記で述べられた方法を実装するためのプログラムコード命令を含む、通信ネットワークからダウンロード可能な、かつ／またはコンピュータにより読取り可能な、かつ／またはプロセッサにより実行可能な媒体に記録されたコンピュータプログラム製品にさらに関する。

加えて本開示はまた、その上に記録され、かつプロセッサにより実行することができ、前に述べられた方法を実装するためのプログラムコード命令を含むコンピュータプログラム製品を含む非一時的なコンピュータ可読媒体に関する。

開示される実施形態と範囲が対応するいくつかの特徴が以下に記載される。これらの特徴は、本開示が使用するはずのいくつかの形態の短い要約を読者に提供するために提示されるに過ぎないこと、およびこれらの特徴は、本開示の範囲を限定するようには意図されていないことを理解されたい。実際に、本開示は、以下で記載されていない可能性のある様々な特徴を包含することができる。

本開示は、添付図を参照して、決して限定するものではない以下の実施形態および実行例により、よく理解され、かつ例示されよう。
本開示が実現され得るクライアント−サーバネットワークアーキテクチャの概略図である。 本開示に従って利用可能な帯域幅を割り当てるための方法を実現する図１のネットワークアーキテクチャのクライアントデバイスの例のブロック図である。 実施形態に従って利用可能な帯域幅を割り当てるための方法の主なステップを示す流れ図である。 図３の方法の帯域幅決定ステップを規定する流れ図である。

図２では、示されたブロックは、単なる機能的なエンティティであり、それは、必ずしも物理的に分離したエンティティに対応するものではない。つまり、それらは、ソフトウェア、ハードウェアの形態で開発される、または１または複数のプロセッサを備える１つまたはいくつかの集積回路で実現され得る。

可能な場合、同じ参照番号は、図全体を通して同じまたは同様の部分を指すために使用される。

本開示の図および記述は、本開示を明確に理解するのに適した要素を示すために簡略化されているが、明確化のために、典型的なディジタルマルチメディアコンテンツ配信方法およびシステムで見られる多くの他の要素を除外していることを理解されたい。しかし、このような要素は当技術分野でよく知られているため、このような要素の詳細な論議は、本明細書では行われない。

図１で示すように、本開示がここで実現され得るクライアント−サーバネットワークアーキテクチャは、例えば、３つのクライアントデバイスＣ１、Ｃ２、およびＣ３、住宅用ゲートウェイＧＷ、ならびにいくつかのサーバＳ１およびＳ２（図１では２つだけが示されている）を備える。明らかに、追加のクライアントが、アーキテクチャ内に存在することができる。

デバイスＣ１、Ｃ２、およびＣ３は、（家庭内ネットワーク、または企業内ネットワークのような）ローカルネットワークＮ１に接続される。ローカルネットワークＮ１は、ゲートウェイＧＷによりブロードバンドネットワークＮ２（インターネットなど）に接続される。

各デバイスＣ１からＣ３は、ブロードバンドネットワークＮ２を介して、遠隔サーバＳ１、Ｓ２の１または複数のものと接続することにより、１または複数のトラフィックセッション（固定レートのストリーミングセッション、適応型ストリーミングセッション（例えば、ＨＡＳ）、バルクトラフィックセッションなど）を確立するように適合される。

この目的のために、図２で示されるように、各デバイスＣ１からＣ３は、以下のものを備える：
− ローカルネットワークＮ１への接続（例えば、Ｗｉ−Ｆｉ、イーサネット（登録商標）などの有線および／または無線のもの）のＬＡＮ（ローカルエリアネットワーク）インターフェース１；
− 通信モジュール２、以下のものを含む：
・パブリッシュ／サブスクライブパラダイム（例えば、図には示されていないデータ配信サービス（ＤＤＳ）、Ｊａｖａメッセージサービス（ＪＭＳ）、Ｑｅｏなど）を実現する管理通信バスに関連する管理インターフェース２Ａ、デバイスは、それによりローカルネットワークＮ１の他のすべてのデバイスＣ１からＣ３、およびゲートウェイＧＷに状態メッセージを送り、かつ収集することができる。状態メッセージは、永続的なメッセージであることが好ましく、したがって、それは、（送る時点で、デバイスがネットワークＮ１に接続されていない場合であっても）ネットワークの任意のデバイスによって収集され得る。特に、状態メッセージは、例えば、デバイスの管理インターフェース２Ａ上で動作するバックグラウンドサービスにより収集され得る、または管理インターフェース２Ａにより取得される（例えば、周期的に、または必要な場合に）長寿命の状態メッセージとして管理通信バスにより記憶され得る；
・アプリケーションインターフェース２Ｂ、それにより、所与のセッションと関連付けられる制御およびデータメッセージがデバイスにより送られ、受信される。

通信モジュール２は、サーバＳ１、Ｓ２と通信するためのプロトコルスタックを含む。特に、通信モジュール２は、当技術分野でよく知られているＴＣＰ／ＩＰスタックを含む。当然ではあるが、それは、デバイスＣ１からＣ３をサーバＳ１、Ｓ２と通信できるようにする任意の他のタイプのネットワークおよび／または通信手段とすることもできる；
− 単一のブロックの形態で表されたメモリ３、ただし、それは、全く同時に、ランダムアクセスメモリ、読出し専用メモリ、および再プログラム可能な永続性のあるメモリ（例えば、「フラッシュ」タイプのもの）を含むことができる；
− デバイスのメモリ３に記憶されたアプリケーションおよびプログラムを実行するための１または複数のプロセッサ（複数可）４；
− 様々なモジュールと、一般的なクライアントデバイス機能を実施するための当業者によく知られたすべての手段とを接続するための内部バスＢ。

加えて、それらのタイプに応じて、デバイスＣ１からＣ３はまた、適応型ストリーミングモジュール（それは、ネットワークの制約、およびそれ自体の制約によく適合するビットレートでチャンクを絶えず選択する）、マルチメディアコンテンツを復号し、かつレンダリングするように適合されたビデオプレーヤ、サーバから受信されたチャンクを、ビデオプレーヤへそれらを送信する前にバッファするように構成されたバッファなど（そのモジュールは、図２で示されていない）を備えることもできる。

実施形態では、デバイスＣ１からＣ３は、可搬型のメディアデバイス、移動電話、タブレット、ラップトップ、ＨＤＴＶなどとすることができる。当然であるが、デバイスＣ１からＣ３は、完全なビデオプレーヤを含まず、メディアコンテンツを多重分離する、かつ復号するためのものなどいくつかの部分要素だけを含むことができ、外部の手段を利用して、復号されたコンテンツをエンドユーザに表示することもできる。

実施形態によると、ネットワークＮ１のデバイスＣ１からＣ３により送られた、または収集されたトラフィックセッションの各状態メッセージは、以下の要素の少なくともいくつかを含むことができる：
− セッション開始時間；
− セッション終了時間；
− セッションを実行するデバイスのタイプ；
− ディスプレイのサイズ；
− デバイスのディスプレイ解像度；
− ユーザの数；
− セッションのタイプ；
− 固定されたストリーミングセッションのために必要なビットレート；
− 適応型ストリーミングセッションに対して利用可能なビットレートのリスト；
− 適応型ストリーミングセッションに対して望ましい最大ビットレート；
− バルクトラフィックセッションに対して望ましい最大ビットレート；
− 適応型ストリーミングセッションに対するチャンク持続期間；
− デバイスの優先順位。

特に状態メッセージは、いくつかのフィールド（例えば、７フィールド）を含むことができ、各フィールドは、以下で示すように、上記で述べた要素の１または複数のものを収集する：

フィールド１は、トラフィックセッションの開始時間を含み、終了時間は、最初は０（ゼロ）に設定される。セッションの終了を示すために、フィールドの終了時間は、非ゼロの値に設定される。

フィールド２、３、および４は、それぞれ、状態メッセージを送るデバイスのタイプ、デバイスのディスプレイのサイズ、およびディスプレイの解像度に関する。

フィールド５は、それが簡単なシンタックスに従うと仮定すると、送出デバイスの能力に応じて、様々な方法で使用することができる。利用可能な場合、それは、現在デバイスを見ているユーザを一覧にする（例えば、Ｊｏｈｎ、Ｗｅｎｄｙ、Ｌｉｓａなど）、そうでなければユーザの数（０・・・ｎ）だけが使用される（０は、特定のデバイスの前に誰もいないことを示す）。加えて異常値（例えば、−１など）を使用して、送出デバイスが、閲覧しているユーザの存在を決定できないことを示すために使用され得る。

フィールド６は、その適合能力を推測するために使用され得るトラフィックのタイプを指定する。実施形態では、トラフィックの以下のタイプ、すなわち、固定レートストリーミング、適応型ストリーミング、バルクトラフィックが考えられる。固定レートストリーミングが考えられる場合、必要なビットレートも状態メッセージに存在する。適応型ストリーミングセッションの場合、マニフェストで見出される利用可能なビットレートが、最大の望ましいビットレートと同様に示される。デバイスは、最大の利用可能なビットレートよりも低いビットレートを希望する様々な理由（低いエンドツーエンドの帯域幅、別のウィンドウにより隠されるビデオ、全画面ではないビデオ（ピクチャイングラフィックス）など）を有する可能性があることに留意する必要がある。同様にバルクトラフィックの場合（例えば、非ストリーミングデータのダウンロードなど）、望ましいレートを含むことができ、帯域幅の使用を制限できるようにする。

フィールド７は、デバイスの優先順位を示すために使用される。それは、一般に０（ゼロ）のままであるが、例えば、特定のデバイスに、他のデバイスを超える特別な利点を与える一時的な変化を示すために使用することができる。

加えてゲートウェイＧＷがまた、例えば、以下の情報を含む状態メッセージを生成するように構成される：
− ブロードバンドネットワークＮ２の利用可能な帯域幅［ｋｂｐｓ］（いわゆるアクセス帯域幅）；
− ローカルネットワークＮ１の利用可能な帯域幅［ｋｂｐｓ］；
− デバイス記述、トラフィックのタイプ、ビットレートなどのサービスのリスト。

フィールド３は、ユーザに、適切なアクション（帯域幅を多く消費するデバイスをオフする、または手動でストリームを再度優先順位付けするなど）をとることができるように、現在実行しているサービスについて知らせるために使用することができる。そのために、デバイス記述フィールドは、デバイス記述を含めることにより構築され、ユーザが原因を突き止めるのを容易にする。さらにこのリストは、状態メッセージにより通知されていない、ゲートウェイＧＷにより見えるストリーム（例えば、レガシーデバイスおよびアプリケーションにより生成されたストリームなど）についてデバイスに知らせるために使用され得る。

デバイス状態メッセージと同様にこれも永続性のあるメッセージであるゲートウェイ状態メッセージが、ゲートウェイＧＷにより、周期的に、または１つのパラメータ（例えば、ローカル帯域幅、アクセス帯域幅）が変化するたびに送られる。したがって、ローカルネットワークＮ１のデバイスは、受動的に、ローカルおよびアクセス帯域幅へアクセスすることができる。

本開示の実施形態によると、また図３で示されるように、デバイスＣ１からＣ３は、デバイスＣ１からＣ３により実行される進行中のトラフィックセッションの中で、ネットワークＮ１の利用可能な帯域幅を割り当てる方法を実現するように構成される。

特に、ネットワークＮ１の所与のデバイス（例えば、デバイスＣ１）で実現されたとき、方法Ｍは、以下のステップを含む：
− 通信モジュール２により、状態メッセージをネットワークＮ１のすべての他のデバイスＣ２、Ｃ３とゲートウェイＧＷとに送信するステップ（ステップＳ１）。状態メッセージは、デバイスＣ１により実行される特定のトラフィックセッションと関連付けられ（セッションごとに１つの状態メッセージ）、かつ有利には、新しいトラフィックセッションがデバイスＣ１により開始されるたびに、デバイスＣ１の進行中のトラフィックセッションが終了するたびに、またはその進行中のトラフィックセッション（複数可）の特性のいずれかが変更された場合に送られる。例として、適応型ストリーミングセッションの特定の場合を考えると、デバイスＣ１が、利用可能な表現の間での切換えを続けている場合、状態メッセージは、チャンクが要求されるたびに再度送られることになり、したがって、すべての他のデバイスが通知され、その変化に反応することができる。実施形態の変形形態では、状態メッセージはまた、所与のイベント時に同報通信されるのではなく、デバイスにより周期的に送ることができる；
− 少なくとも１つの進行中のトラフィックセッションを実行するネットワークＮ１のデバイスＣ２、Ｃ３から、かつゲートウェイＧＷからの状態メッセージを通信モジュール２により収集するステップ（ステップＳ２）。収集された状態メッセージは、デバイスＣ１のメモリ３に記憶することができる。ステップＳ１およびＳ２は、互いに独立して（Ｓ２の前にＳ１、Ｓ１の前にＳ２、またはＳ１およびＳ２を同時に）実施することができる；
− デバイスＣ１のランク付けモジュール５により、対応するデバイスのパラメータ、およびセッションのパラメータに従って進行中のセッションのランク付けをするステップ（ステップＳ３）。パラメータの値は、収集された状態メッセージから取得される。ステップＳ３が行われている間、ランク付けリストが、ランク付けモジュール５により構築され、例えば、メモリ３に記憶される；
− （ゲートウェイ状態メッセージから得られる）ローカルネットワークＮ１の全体の利用可能な帯域幅、ランク付けモジュール５により決定されたセッションのランク、およびランク付けされたセッションのタイプに応じて、デバイスＣ１の帯域幅計算器６により、各ランク付けされたセッションに割り振られる帯域幅を決定するステップ（ステップＳ４）。変形形態または補完形態において、他の機能が、各進行中のセッションに割り振られる帯域幅を決定するために使用される、または追加され得る；
− デバイスＣ１の比較器７により、所与のデバイスＣ１のセッションに割り振られる決定された帯域幅が、ゼロを超えているか否かを調べるステップ（ステップＳ５）；
− 所与のデバイスＣ１のセッションに割り振られる決定された帯域幅が、ゼロを超えている場合、そのセッションに対して、所与のデバイスＣ１により自己割振りによる帯域幅を用いるステップ（ステップＳ６）；
− 所与のデバイスＣ１のセッションに割り振られる決定された帯域幅が、ゼロに等しい場合（ステップＳ７）、所与のデバイスＣ１により送られた状態メッセージに他のセッションが反応するために時間が必要かどうかを検証するステップ（例えば、競合する進行中のＨＡＳセッションは、やがて生ずるチャンクの持続期間に対して一定の帯域幅を利用できるものと想定して、所与のデバイスＣ１のセッションのランクが、そのＨＡＳセッションのものより高い場合であっても、チャンクダウンロードの終了まで、待つことが好ましい）；
− 他のセッションが、所与のデバイスＣ１により送られた状態メッセージに反応するためには時間が必要である場合（ステップＳ８）、他の進行中のセッション（複数可）がその送られた状態メッセージを考慮に入れるのを待つステップ（例えば、適応型ストリーミングセッションの場合、現在のチャンクのダウンロード終了後、および適応型ストリーミングセッションを実行する関連するデバイスによる新しい状態メッセージの放出後）、次いでステップＳ１へ戻る；
− 他のセッションが、所与のデバイスＣ１により送られた状態メッセージに反応するのに時間が必要でない場合（ステップＳ９）、デバイスＣ１のユーザに失敗を示すステップ。

デバイスＣ１のセッションがまだ終了していない場合（ステップＳ１０）、方法Ｍは、ステップＳ１へと戻り、次のステップを繰り返す。

方法Ｍは、以下の場合に実施することができる：
− （方法Ｍを実現する）所与のデバイスＣ１により実行されるセッションが固定レートセッション、またはバルクトラフィックセッションである場合に、ネットワークＮ１のデバイスから新しい状態メッセージを受信したとき；
− 以下の対応する期間で周期的に：
・所与のデバイスＣ１により実行されるセッションが、固定レートセッションまたはバルクトラフィックセッションである場合、任意に決定される（例えば、１０秒）；または
・所与のデバイスＣ１により実行される適応型ストリーミングセッションの場合、チャンクの持続期間に等しい。

実施形態によれば、ランク付けモジュール５により実現されるランク付けステップＳ３は、以下のサブステップを含む：
− 収集された状態メッセージから処理するために、ネットワークＮ１のすべての進行中のセッションのプロセスリストを確立するステップ（Ｓ３１）；
− そのトラフィックセッションを実行するデバイスの優先順位、デバイスのタイプ、およびトラフィックセッションのタイプに基づいて、（例えば、プロセスリストの最初のセッションで、またはランダムに選択されたそのリストのセッションで開始することにより）プロセスリストの各セッションのランクを決定するステップ（Ｓ３２）。例示的なものであって、限定する例ではないが、セッションのランクは、以下の式から決定される：ランク＝ＭＡＸ−ＰＷ×優先順位−ＤＰ（デバイスタイプ）−ＦＰ（セッションタイプ）−ＡＰ（セッションタイプ）
式中：
・ＭＡＸは定数であり、例えば、１０に等しく、１０個の異なるランクを可能にする（なお、ランク０は最高ランクである）；
・優先順位は、ランク付けされるセッションを実行するデバイスと関連付けられた優先順位である；
・ＰＷは、優先順位を重み付けする定数であり、例えば、５に等しく、２つの異なる優先順位を可能にする（高い優先順位は１、低い優先順位は０）、したがって、高い優先順位（１）を有するデバイスは、より高いランク０から５に割り当てられ、また低い優先順位（０）を有するデバイスは、より低いランク６から１０に割り当てられることになる；
・ＤＰは、デバイスタイプの優先度に対応する定数であり、例えば、デバイスタイプがＨＤＴＶである場合、３に等しく、その他の場合はゼロに等しい。言い換えると、ＤＰの値（３または０）は、デバイスのタイプに依存する；
・ＦＰは、固定レートのストリーミングセッションの優先度に対応する定数であり、例えば、トラフィックセッションが固定レートセッションである場合、２に等しく、その他の場合は０に等しい。言い換えると、ＦＰの値（２または０）は、トラフィックセッションのタイプに依存する；
・ＡＰは、適応型ストリーミングセッションの優先度に対応する定数であり、例えば、トラフィックセッションが適応型ストリーミングセッションである場合、１に等しく、その他の場合は０に等しい。言い換えると、ＡＰの値は、トラフィックセッションのタイプに依存する。

このような式により、高い優先順位を有するセッションは、第１のランクに割り当てられ、また低い優先順位を有するセッションは、最後のランクに配置される。等しい優先順位では、ＨＤＴＶタイプを有するデバイスは、例えば、タブレット、またはスマートフォンとは対照的に優遇されることになる。加えて固定レートセッションは、適応型ストリーミングセッションの前に扱われることが好ましく、それはバルクトラフィックの前に扱われることが好ましい。

− 各ランクのセッションを、それらの開始時間の昇順で順序付けるステップ（ステップＳ３３）、したがって、前に開始されたセッションは、同じランクに割り当てられた新しく開始されたセッションと比較して、優先して扱われる。明らかに、（終了時間フィールドにより）その終了が示されたセッションは、プロセスリストから破棄される。

ランク付けステップＳ３の結果、ランク付けリストが導かれる。２つのレベル構造を有するこのランク付けリストは、ランクのリストからなる。各ランクでは、セッションは、それらの開始時間に応じて順序付けられる。したがって、第１のランクにあるセッションは、（帯域幅割振りの点で）最初にサービスされ、その後に次のランクのセッションがサービスされて、以下同様に行われる。特に同じランクのセッションが適応型ストリーミングセッションである場合、次のランクを考慮する前に、残りの帯域幅を均等にこのランクのセッションに割り当てることが可能である。

実施形態によると、また図４で示すように、デバイスＣ１の帯域幅計算器６により実現される帯域幅決定ステップＳ４は、以下のサブステップを含む：
− まだ未処理のランク付けリストのうちの最高にランク付けされたトラフィックセッションを選択するステップ（ステップＳ４０１）；
− 選択されたトラフィックセッションが、固定レートのストリーミングセッション、適応型ストリーミングセッション、またはバルクトラフィックセッションか否かを調べるステップ（ステップＳ４０２）；
− 選択されたセッションが、固定レートのストリーミングセッションである場合、（ゲートウェイ状態メッセージから得られる）ネットワークＮ１の現在利用可能な帯域幅と、（対応する状態メッセージで示す）固定レートのストリーミングセッションに関連付けられた必要なビットレートの間の差が、少なくともゼロに等しいかどうかを決定するステップ（ステップＳ４０３）；
− 選択されたセッションが適応型ストリーミングセッションである場合：
・まだ処理されておらず、（ステップＳ４０１で）選択されたセッションと同じランクを有するトラフィックセッションの数により分割された現在利用可能な帯域幅に多くても等しいビットレートを（対応するマニフェストから取得された利用可能なビットレートの中で）選択するステップ（ステップＳ４０４）。マニフェストの利用可能なビットレートの中のビットレートがいずれも、同じランクを有するまだ未処理のトラフィックセッションの数により分割された現在利用可能な帯域幅よりも低くない場合、選択されたビットレートはゼロに等しい；
・選択されたビットレート（ステップＳ４０４）と、（関連付けられた状態メッセージから取得された）選択されたセッションに関連付けられた最大の望ましいビットレートとの間の最小のビットレートを決定するステップ（ステップＳ４０５）；
− 選択されたセッションがバルクトラフィックセッションである場合：
・まだ未処理であり、選択されたセッション（ステップＳ４０１で）と同じランクを有するトラフィックセッションの数により分割された現在の利用可能な帯域幅に等しいビットレートを計算するステップ（ステップＳ４０６）；
・関連する状態メッセージから、最大の望ましいビットレートが、選択されたバルクトラフィックセッションと関連付けられているか否かを調べるステップ（ステップＳ４０７）；
・最大の望ましいビットレートが、選択されたバルクトラフィックセッションと関連付けられる場合、計算されたビットレート（ステップＳ４０６）と、選択されたセッションと関連付けられた最大の望ましいビットレートとの間の最小のビットレートを決定するステップ（ステップＳ４０８）；
− 帯域幅を選択されたセッションに割り振るステップ（ステップＳ４０９）。割り振られた帯域幅は、以下のものに等しい：
・選択されたセッションが固定レートのストリーミングセッションである場合、必要なビットレート；
・選択されたセッションが適応型ストリーミングセッションである場合、決定された最小のビットレート（ステップ４０５のもの）；
・選択されたセッションがバルクトラフィックセッションである場合、（ステップ４０６の）計算されたビットレート、または（ステップ４０８の）決定された最小のビットレート；
− ステップ４０９で割り振られた帯域幅により現在の帯域幅を減少させるステップ（ステップ４１０）。

ステップＳ４０１からＳ４１０は、ランク付けリストのすべてのセッションが処理されるまで繰り返されることが好ましい。

次に、実施形態では、実際の帯域幅割振りは、進行中の適応型ストリーミングセッションに関するチャンク持続期間を考慮に入れる。実際に、進行中のセッションは、やがて生ずるチャンク持続期間に対して一定の帯域幅が使用できるものと想定しているので、これらの条件をチャンクの終了前に変更することは望ましくない。したがって、セッションが開始すると、進行中のセッションが、新しく開始されるセッション情報を受け取って、それ自体に割り振られた帯域幅を減らすことによりその存在を考慮するまで、より高いランクのセッションは延期されることになる。この遅延は、各進行中のセッションに特有のものであり、（本明細書の後で述べるように）高ランクセッションに対して帯域幅を段階的に戻すことになる。固定レートおよびバルクセッションの場合、ネットワークＮ１の他のデバイスにより送られた状態メッセージの処理は、期間が任意に（例えば、１０秒に）固定される差を伴い、同様に周期的に行われ、固定レートまたはバルクセッションを実行するデバイスが、新しいセッションを開始するデバイスにより送られた新しい状態メッセージをいつ考慮するかを決定する。

帯域幅がデバイスのセッションに割り振られると、後者は、それを完全に使用する権利を有するが、なお、知られたＨＡＳ実装形態が行うように、帯域幅測定に基づいてその実際の使用を調整することができる。

その帯域幅の使用を再調整するための時間を必要とする競合するセッションの存在に起因して、帯域幅が割り振られなかった場合、デバイスＣ１は、受信した情報に基づいて、待つ必要のある時間量を決定することができる。帯域幅割振りの失敗が、低い優先順位のデバイスの存在によるものではない場合（進行しているより高い優先順位のセッションが存在するためである可能性が最も高い）、新たに開始するセッションは取り消され、ユーザに失敗したことを示す。

方法Ｍは、反復的なものであり、したがって、最初の反復で延期された開始セッションは、第２の反復では、進行中のセッションにより解放された帯域幅のその割当てを共有することができる。同様に、進行中のセッションは、新しいセッションを記述するメッセージを受信すると、その帯域幅の使用量を絶えず調整することができる。セッションが、ゼロに等しい帯域幅に割り振られたときは常に、それは停止する。

本開示の実施形態によれば、ネットワークの各デバイスは、当て推量および近似を行う必要がなく、例えば、どのビットレートをそれが受信できるか、それはいつ再生を開始し、停止するかなどを正確に知らせるので、帯域幅使用に対するはるかに細かい制御を達成することができる。デバイスは、それらの能力および各優先順位に関する豊富な情報を交換するので、ユーザエクスペリエンスを実際に反映する帯域幅割当てが達成され得る。それは帯域幅競合問題を、決定論的に解決し、デバイスの優先順位を保存し、かつ浪費される帯域幅を回避することができる。

次の３つの例では、状態メッセージが周期的に送られると（明確化のため）想定されており、期間は、固定レートおよびバルクトラフィックセッションに対しては任意の期間であり、また適応型ストリーミングセッションに対しては、チャンクの持続期間に等しい。

実施形態の第１の説明に役立つ例では、ＡＤＳＬゲートウェイＧＷにより報告されるように、アクセスネットワークは８Ｍｂｐｓの帯域幅を有するものと想定される。自分のＨＤＴＶでビデオオンデマンド（ＶｏＤ）を見ることを望むユーザは、方法Ｍを実現するＨＡＳアプリケーションを開始する。他のストリームが現在ネットワークを使用していないことに気が付くと、ＨＡＳアプリケーションは、直ちに現在のネットワーク帯域幅に関して許容される最高のビットレートに集中する。

第２の説明に役立つ例では、これもアクセスネットワークが８Ｍｂｐｓの帯域幅を有することが想定される。ネットワーク帯域幅の一部は、すでにＨＡＳストリームを消費するタブレットおよびスマートフォンにより使用されている。簡単にするために、ＨＡＳストリームは、それらの対応するマニフェストに一覧にされている同一のビットレート（すなわち、２００、４００、６００、１２００、１８００、２５００、４５００、６５００、および８５００Ｋｂｐｓ）を有するものと想定される。以下のことに留意されたい：
− ｔ１：タブレット上で動作している第１のＨＡＳクライアントが、それが消費しているＨＡＳストリームの特性を最後に報告した時間であり、持続期間ｄ１のチャンクを有する；
− ｔ２：スマートフォン上で動作している第２のＨＡＳクライアント２が、そのストリームの特性を最後に報告した時間であり、持続期間ｄ２のチャンクを有する。

ネットワーク帯域幅の可用性により、第１および第２のＨＡＳクライアントは、それぞれ、４．５Ｍｂｐｓおよび２．５Ｍｂｐｓで比較的高品質のストリームを楽しんでいる。

時間ｔ３に、ＨＤＴＶ上で動作している第３のＨＡＳクライアントが起動される。それは、望ましいＨＡＳストリームのパラメータを取得し、その望ましいビットレートとして、アクセスネットワークの能力よりも低い最高のビットレートを選択し、かつネットワーク上のセッションを記述する状態メッセージを送る。ＨＤＴＶは、タブレットおよびスマートフォンに対して優先権を有する。そうではあるが、好ましくは、第３のＨＡＳクライアントは、受信されたメッセージを考慮するために、第１および第２のＨＡＳクライアントに対して、何らかの時間を残すべきである。第１のＨＡＳクライアントはｔ１にその最後の状態メッセージを送っており、また第３のＨＡＳクライアントは、ｔ３（ｔ３＜ｔ１＋ｄ１であると仮定する）にその状態メッセージを送っているので、第１と第３のクライアントは共に、互いの存在に気付き、それに従って、ｔ１＋ｄ１に、それらの帯域幅使用量を調整することができる。第１のＨＡＳクライアントの場合、これは、割り振られる帯域幅が計算される次のループの反復時に生ずる。同様に、ｔ３＜ｔ２＋ｄ２であると仮定すると、第２のＨＡＳクライアント２は、ｔ２＋ｄ２に、その帯域幅使用量を調整することになる。第３のＨＡＳクライアントの場合、帯域幅が、第１および第２のＨＡＳクライアントにより解放されることになるので、いつ方法Ｍを実行できるかを決定するために、時間ｍａｘ（ｔ１＋ｄ１、ｔ２＋ｄ２）が使用される。この計算は、すべてのデバイス上で全く同様に行われて、アクセスリンク能力よりも低い最高の利用可能なビットレートとして選択された最大の帯域幅が（第３のＨＡＳクライアントを動作させる）高ランクのデバイスに与えられ、残りは、第１および第２のＨＡＳクライアントの中で割り当てられる。異なるセッションに対して利用可能なビットレートのセットが与えられると、６．５Ｍｂｐｓが第３のＨＡＳクライアントに割り振られるが、第１および第２のＨＡＳクライアントは、６００ｋｂｐｓを割り振られる。

第３の例では、それは、２つのタブレットに対する無線ホットスポットとして働くスマートフォン付近に編成された無線ネットワークであると考えられる。ネットワーク帯域幅は、ゲートウェイ状態メッセージを用いて現在のアクセス帯域幅を示すスマートフォンにより通知されたような８Ｍｂｐｓのものであると考えられる。タブレットの１つで動作する第１のクライアントは、５Ｍｂｐｓで固定レートストリームの再生を開始し、ストリーム特性を通知し、かつメッセージを待ち受ける。その後に、他のタブレット上で動作する第２のクライアントが、ＨＡＳストリームの再生を開始する。固定レートストリームを消費する第１のクライアントは、第２のクライアントと比較して第１にランク付けされる。したがって、第１のクライアントは、そのストリームの再生を続けるが、第２のクライアントは、残りの帯域幅を使用して、ＨＡＳストリームから適切なレートを選択する。上記の例と同じ利用可能なビットレートを考えると、第２のクライアントは、２５００ｋｂｐｓストリームを選択することになる。しばらくしてから、外部の事象に起因して、スマートフォンにより使用される無線ネットワークの速度が４Ｍｂｐｓに低下する。スマートフォンは、現在のネットワーク能力を示す、新しい、更新されたゲートウェイ状態メッセージを送ることにより、ネットワーク内のデバイスに知らせる。このゲートウェイ状態メッセージに応じて、第１のクライアントは、利用可能な帯域幅は、それが消費している固定レートストリームの再生を進めるには低すぎると決定し、セッションの終了を示す状態メッセージを送り、終了時間フィールドを非ゼロの値に設定する。ｔ２が、チャンク持続期間ｄ２を有する、第１のクライアントによりセッション終了メッセージを送る前に、第２のＨＡＳクライアントが最後に方法Ｍを実行した時間であると考えると、アクセス帯域幅の４Ｍｂｐｓが使用可能になっているので、ｔ２＋ｄ２に、第２のクライアントは、２５００ｋｂｐｓストリームへと切り換わる。

図の流れ図および／またはブロック図は、本開示の様々な実施形態によるシステム、方法、およびコンピュータプログラム製品の可能な実装形態の構成、動作、および機能を示している。これに関して、流れ図またはブロック図における各ブロックは、モジュール、セグメント、またはコードの一部を表すことができ、それは、指定された論理機能（複数可）を実現するための１または複数の実行可能命令を含む。いくつかの代替的実装形態では、ブロックで記された機能は、図に記された順序を変えて行われ得ることにも留意されたい。例えば、連続して示された２つのブロックは、実際には、実質的に同時に実行することができ、またはブロックは、時には逆の順序で実行することができ、またはブロックは、含まれている機能に応じて代替の順序で実行することもできる。ブロック図および／または流れ図で示す各ブロック、およびブロック図および／または流れ図で示すブロックの組合せは、指定された機能もしくは動作を実施する専用のハードウェアベースのシステムで、または専用のハードウェアとコンピュータ命令の組合せにより実現できることにも留意されたい。明示的に述べられていないが、本実施形態は、任意の組合せで、または下位の組合せで使用することができる。

当業者であれば理解されるように、本原理の特徴は、システム、方法、またはコンピュータ可読媒体として具現化することができる。したがって、本原理の特徴は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐するソフトウェア、マイクロコード、以下同様のものなどを含む）、または本明細書で概して「回路」、「モジュール」、または「システム」とすべて呼ぶことのできるソフトウェアおよびハードウェア特徴を組み合わせた実施形態の形態をとることができる。さらに本原理の特徴は、コンピュータ可読記憶媒体の形態をとることができる。１または複数のコンピュータ可読記憶媒体（複数可）の任意の組合せを利用することができる。

コンピュータ可読記憶媒体は、１または複数のコンピュータ可読記憶媒体（複数可）で具現化され、かつコンピュータにより実行可能なコンピュータ可読プログラムコードをその上で具現化されたコンピュータ可読のプログラム製品の形態をとることができる。本明細書で使用される場合、コンピュータ可読記憶媒体は、情報をそれに記憶する固有の能力、ならびに情報をそこから取得する固有の能力が与えられた非一時的な記憶媒体と考えられる。コンピュータ可読記憶媒体は、例えば、これだけに限らないが、電子的、磁気的、光学的、電磁気的、赤外線、もしくは半導体のシステム、装置、もしくはデバイス、または前述のものの任意の適切な組合せとすることができる。以下のものは、本原理が適用できるコンピュータ可読記憶媒体のより具体的な例を提供するが、当業者であれば容易に理解されるように、単に説明に役立つものであって、網羅的な一覧ではないことを理解されたい：すなわち、可搬型のコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、消去可能プログラム可能な読出し専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）、可搬型コンパクトディスク読出し専用メモリ（ＣＤ−ＲＯＭ）、光学的な記憶デバイス、磁気的な記憶デバイス、または前述のものの任意の適切な組合せである。
［付記１］
ネットワーク（Ｎ１）のデバイス（Ｃ１、Ｃ２、Ｃ３）により実行される進行中のトラ フィックセッションの中で、前記ネットワーク（Ｎ１）の利用可能な帯域幅を割り当てる ための方法であって、所与のデバイス（Ｃ１、Ｃ２、Ｃ３）で、
− 少なくとも１つのトラフィックセッションを実行する前記ネットワークのデバイス （Ｃ１、Ｃ２、Ｃ３）から状態メッセージを収集するステップ（Ｓ２）と、
− 状態メッセージから取得されたデバイスおよびトラフィックセッションのパラメー タに従ってランク付けされた（Ｓ３）各トラフィックセッションに、前記ネットワークの 利用可能な帯域幅、前記ランク付けされたトラフィックセッションのランク、および前記 ランク付けされたトラフィックセッションのタイプに応じて、割り振られる帯域幅を決定 するステップと、
− 前記所与のデバイス（Ｃ１、Ｃ２、Ｃ３）のトラフィックセッションに割り振られ る前記決定された帯域幅がゼロを超える場合、前記トラフィックセッションに対して前記 所与のデバイスにより前記割り振られた帯域幅を使用するステップと、
を含む、前記方法。
［付記２］
１つの状態メッセージは、１つの進行中のトラフィックセッションに関連付けられる、 付記１に記載の方法。
［付記３］
状態メッセージは、イベントが生じたとき、前記所与のデバイス（Ｃ１、Ｃ２、Ｃ３） によって前記ネットワーク（Ｎ１）の全ての前記デバイス（Ｃ１、Ｃ２、Ｃ３）に送られ る、付記１又は２に記載の方法。
［付記４］
前記イベントは、少なくとも、
−前記所与のデバイス（Ｃ１、Ｃ２、Ｃ３）によるトラフィックセッションの開始、
−前記所与のデバイスによるトラフィックセッションの終了、
−前記所与のデバイスにより実行される進行中のトラフィックセッションのいずれかの 特性の変更、
のイベントを含むグループに属する、付記３に記載の方法。
［付記５］
ランク付け（Ｓ３）中に、前記トラフィックセッションのそれぞれに対するランクは、 前記トラフィックセッションを実行する前記デバイスの優先順位、前記デバイスのタイプ 、および前記トラフィックセッションのタイプに基づいて決定される、付記１から４のい ずれかに記載の方法。
［付記６］
所与のランク内で、対応するトラフィックセッションは、それらの開始時間に応じて順 序付けされる、付記１から５のいずれかに記載の方法。
［付記７］
前記ネットワークの前記利用可能な帯域幅は、前記ネットワーク（Ｎ１）のゲートウェ イ（ＧＷ）により提供される、付記１から６のいずれかに記載の方法。
［付記８］
前記ランク付けされたトラフィックセッションに割り振られる帯域幅の前記決定（Ｓ４ ）は、
−まだ未処理の最も高くランク付けされたトラフィックセッションを選択するステップ （Ｓ４０１）と、
−前記選択されたトラフィックセッションが、固定レートのストリーミングセッション であるか否かを調べるステップ（Ｓ４０２）と、
−前記ネットワーク（Ｎ１）の現在利用可能な帯域幅と、前記固定レートのストリーミ ングセッションに関連付けられた必要なビットレートとの間の差が、少なくともゼロに等 しいとき、前記選択されたトラフィックセッションに帯域幅を割り振るステップ（Ｓ４０ ９）と、
を含む、付記１から７のいずれかに記載の方法。
［付記９］
前記ランク付けされたトラフィックセッションに割り振られる帯域幅の前記決定（Ｓ４ ）は、前記選択されたトラフィックセッションが適応型ストリーミングセッションである 場合、
−まだ未処理の、前記選択されたトラフィックセッションと同じランクを有するトラフ ィックセッションの数により分割された、前記現在利用可能な帯域幅に多くても等しいビ ットレートを選択するステップ（Ｓ４０４）と、
−前記選択されたビットレートと、前記選択されたトラフィックセッションに関連付け られた最大の望ましいビットレートとの間の最小のビットレートを決定するステップ（Ｓ ４０５）と、
−前記最小のビットレートを、前記選択されたトラフィックセッションに割り振るステ ップ（Ｓ４０３）と、
をさらに含む、付記８に記載の方法。
［付記１０］
前記ランク付けされたトラフィックセッションに割り振られる帯域幅の前記決定（Ｓ４ ）は、前記割り振られた帯域幅により現在利用可能な帯域幅を減少させる、付記８又は９ に記載の方法。
［付記１１］
付記１から１０のいずれかに記載した、前記ネットワーク（Ｎ１）のデバイス（Ｃ１、 Ｃ２、Ｃ３）の進行中のトラフィックセッションの中で前記ネットワーク（Ｎ１）の利用 可能な帯域幅を割り当てるための方法を実装するように構成されたネットワークのデバイ スであって、
−少なくとも１つのトラフィックセッションを実行する前記ネットワークのデバイス（ Ｃ１、Ｃ２、Ｃ３）から状態メッセージを収集するように適合された通信モジュール（２ ）と、
−状態メッセージから取得されたデバイスおよびトラフィックセッションのパラメータ に従って前記進行中のトラフィックセッションをランク付けするように構成されたランク 付けモジュール（５）と、
−前記利用可能な帯域幅、前記ランク付けされたトラフィックセッションのランク、お よび前記ランク付けされたトラフィックセッションのタイプに応じて、各ランク付けされ たトラフィックセッションに割り振られる帯域幅を決定するように構成された計算器（６ ）と、
−前記デバイスのトラフィックセッションに割り振られる前記決定された帯域幅が、ゼ ロとは異なるか否かを調べることのできる比較器（７）と、
を備えた、前記デバイス。
［付記１２］
前記通信モジュール（２）は、前記ネットワークの全ての前記デバイス（Ｃ１、Ｃ２、 Ｃ３）に状態メッセージを送信するようにさらに構成された、付記１１に記載のデバイス 。
［付記１３］
前記ランク付けモジュール（５）は、前記トラフィックセッションを実行する前記デバ イスの優先順位、前記デバイスのタイプ、および前記トラフィックセッションのタイプに 基づき、前記トラフィックセッションのそれぞれに対してランクを決定する、付記１１又 は１２に記載のデバイス。
［付記１４］
付記１から９のいずれかに記載の方法を実装するためのプログラムコード命令を含む、 通信ネットワークからダウンロード可能な、かつ／またはコンピュータにより読取り可能 な、かつ／またはプロセッサにより実行可能な媒体に記録されたコンピュータプログラム 製品。
［付記１５］
その上に記録され、かつプロセッサにより実行することができ、付記１から９のいずれ かに記載の方法を実装するためのプログラムコード命令を含む、コンピュータプログラム 製品を含む非一時的なコンピュータ可読媒体。

Claims (15)

1. ネットワークの複数のデバイスにより実行される進行中のトラフィックセッションの中で、前記ネットワークにおける利用可能な帯域幅を割り当てる方法であって、前記複数の デバイスのうちの所与のデバイスで、
   少なくとも１つのトラフィックセッションを実行する前記ネットワークの複数のデバイスのうちの他のデバイスから状態メッセージを収集することと、
   状態メッセージから取得されたデバイスおよびトラフィックセッションのパラメータに従ってランク付けされた各トラフィックセッションに、前記ネットワークにおける利用可能な帯域幅、前記ランク付けされたトラフィックセッションのランク、および前記ランク付けされたトラフィックセッションのタイプに応じて、割り振られる帯域幅を決定するこ とと、
   前記所与のデバイスのトラフィックセッションに割り振られる前記決定された帯域幅がゼロを超える場合、前記トラフィックセッションに対して前記所与のデバイスにより前記割り振られた帯域幅を使用することと、
   を含む、前記方法。
2. １つの状態メッセージは、１つの進行中のトラフィックセッションに関連付けられる、請求項１に記載の方法。
3. 状態メッセージは、イベントが生じたとき、前記所与のデバイスによって前記ネットワークの他の全てのデバイスに送られる、請求項１又は２に記載の方法。
4. 前記イベントは、少なくとも、
   前記所与のデバイスによるトラフィックセッションの開始、
   前記所与のデバイスによるトラフィックセッションの終了、
   前記所与のデバイスにより実行される進行中のトラフィックセッションのいずれかの特性の変更、
   のイベントを含むグループに属する、請求項３に記載の方法。
5. ランク付け中に、前記トラフィックセッションのそれぞれに対するランクは、前記トラフィックセッションを実行する前記デバイスの優先順位、前記デバイスのタイプ、および前記トラフィックセッションのタイプに基づいて決定される、請求項１から４のいずれかに記載の方法。
6. 同じランクに割り当てられたトラフィックセッションは、それらの開始時間に応じて順序付けされる、請求項１から５のいずれかに記載の方法。
7. 前記ネットワークにおける前記利用可能な帯域幅は、前記ネットワークのゲートウェイ により提供される、請求項１から６のいずれかに記載の方法。
8. 前記ランク付けされたトラフィックセッションに割り振られる帯域幅の前記決定は、
   前記ランク付けされたトラフィックセッションの中から、まだ処理されていない最も高くランク付けされたトラフィックセッションを選択することと、
   前記選択されたトラフィックセッションが、固定レートのストリーミングセッションであるか否かを調べることと、
   前記ネットワークの現在利用可能な帯域幅と、前記固定レートのストリーミングセッションに関連付けられた必要なビットレートとの間の差が、少なくともゼロに等しいとき、前記選択されたトラフィックセッションに帯域幅を割り振ることと、
   を含む、請求項１から７のいずれかに記載の方法。
9. 前記ランク付けされたトラフィックセッションに割り振られる帯域幅の前記決定は、前記選択されたトラフィックセッションが適応型ストリーミングセッションである場合、
   前記選択されたトラフィックセッションに関連付けられた利用可能なビットレートの中 からビットレートを選択することであって、前記ビットレートは、まだ処理されていない、前記選択されたトラフィックセッションと同じランクを有するトラフィックセッションの数により分割された前記現在利用可能な帯域幅に多くても等しい、前記選択することと、
   前記選択されたビットレートと、前記選択されたトラフィックセッションに関連付けられた最大の望ましいビットレートとの間の最小のビットレートを決定することと、
   前記最小のビットレートを、前記選択されたトラフィックセッションに割り振ることと、
   をさらに含む、請求項８に記載の方法。
10. 前記ランク付けされたトラフィックセッションに割り振られる帯域幅の前記決定は、前記割り振られた帯域幅により現在利用可能な帯域幅を減少させる、請求項８又は９に記載の方法。
11. ネットワークに属するように構成され、複数のデバイスの進行中のトラフィックセッションの中で前記ネットワークにおける利用可能な帯域幅を割り当てるための方法を実装するように構成されたネットワークのデバイスであって、
    少なくとも１つのトラフィックセッションを実行する、前記ネットワークの複数のデバイスのうちの他のデバイスから状態メッセージを収集するように適合された通信モジュー ルと、
    状態メッセージから取得されたデバイスおよびトラフィックセッションのパラメータに従って前記進行中のトラフィックセッションをランク付けするように構成されたランク付けモジュールと、
    前記利用可能な帯域幅、前記ランク付けされたトラフィックセッションのランク、および前記ランク付けされたトラフィックセッションのタイプに応じて、各ランク付けされたトラフィックセッションに割り振られる帯域幅を決定するように構成された計算器と、
    前記デバイスのトラフィックセッションに割り振られる前記決定された帯域幅が、ゼロとは異なるか否かを調べることのできる比較器と、
    を備えた、前記デバイス。
12. 前記通信モジュールは、前記ネットワークの他の全てのデバイスに状態メッセージを送信するようにさらに構成された、請求項１１に記載のデバイス。
13. 前記ランク付けモジュールは、前記トラフィックセッションを実行する前記デバイスの優先順位、前記デバイスのタイプ、および前記トラフィックセッションのタイプに基づき、前記トラフィックセッションのそれぞれに対してランクを決定する、請求項１１又は１２に記載のデバイス。
14. 請求項１から９のいずれか１項に記載の方法をコンピュータに実行させるコンピュータプログラム。
15. 請求項１から９のいずれか１項に記載の方法をコンピュータに実行させるコンピュータプログラムを記憶する記憶媒体。