(57)【特許請求の範囲】
【請求項１】
マルチキャスト配信グループ（Ｇ）において配信されるデータストリームへの加入を要求する方法であって、前記マルチキャスト配信グループは、サーバ（１０１）と、第１のクライアント（２０１）と、第２のクライアント（２０２）とを含むソースを含み、前記ソースは、電子通信ネットワーク（３０１）を通して一緒に接続され、
前記マルチキャスト配信グループは、アドレスによって識別され、
第１のソースによって前記マルチキャスト配信グループの前記アドレスに送信されるストリームは、第２のソースが前記第１のソースによって送信されたデータストリームに以前に加入していた場合、前記第２のソースによって受信され、
前記第１のクライアントは前記サーバによって送信されたデータストリームに加入し、
前記方法は、前記第１のクライアントによって実施される、
前記サーバから発せられた、前記第２のクライアントによって前記マルチキャスト配信グループの前記アドレスに送信された前記ストリームに関連する少なくとも１つの品質パラメータを含む少なくとも１つの管理メッセージを受信するステップ（Ｅ７０１、Ｆ６）と、
前記受信した少なくとも１つの品質パラメータに依存する基準に応じて、前記第２のクライアントによって送信されたデータストリームへの加入を判断するステップ（Ｅ４０４、Ｆ８）と、
肯定的な判断の場合、前記第２のクライアントによって送信されたデータストリームへの加入を要求するメッセージを送信するステップ（Ｅ４０５、Ｆ９）とを含む、加入を要求する方法。
【請求項２】
前記判断するステップは、前記第２のクライアントによって前記マルチキャスト配信グループの前記アドレスに送信された前記ストリームを受信するために必要な平均ビットレート値を含む基準を考慮に入れ、前記少なくとも１つの品質パラメータに基づいてこの値を計算するステップ（Ｅ４０３、Ｆ７）が先行する、請求項１に記載の加入を要求する方法。
【請求項３】
前記判断するステップは、前記第２のクライアントによって前記マルチキャスト配信グループの前記アドレスに送信された前記ストリームを受信するために必要なキューサイズの値を含む基準を考慮に入れ、前記少なくとも１つの品質パラメータに基づいてこの値を計算するステップが先行する、請求項１に記載の加入を要求する方法。
【請求項４】
前記加入を要求するメッセージは、前記計算された値を含む、請求項２または３に記載の加入を要求する方法。
【請求項５】
マルチキャスト配信グループ（Ｇ）において配信されるデータストリームを管理する方法であって、前記マルチキャスト配信グループは、サーバ（１０１）と、第１のクライアント（２０１）と、少なくとも１つの第２のクライアント（２０２、２０ｘ）とを含むソースを含み、前記ソースは、電子通信ネットワーク（３０１）を通して一緒に接続され、
前記マルチキャスト配信グループは、アドレスによって識別され、
第１のソースによって前記マルチキャスト配信グループの前記アドレスに送信されるストリームは、第２のソースが前記第１のソースによって送信されたデータストリームに以前に加入していた場合、前記第２のソースによって受信され、
前記第１のクライアントは前記サーバによって送信されたデータストリームに加入し、
前記サーバは、前記少なくとも１つの第２のクライアントによって送信されたデータストリームに加入しており、前記第２のクライアントが前記マルチキャスト配信グループの前記アドレスに送信したストリームを受信し、そこから前記ストリームの品質に関連する少なくとも１つのパラメータを抽出することが可能であり、
前記方法は、前記サーバによって実施される、
前記抽出された少なくとも１つのパラメータに応じて、前記少なくとも１つの第２のクライアントの中から少なくとも１つのクライアントを選択するステップ（Ｅ５０３、Ｇ５）と、
前記少なくとも１つの選択されたクライアントに対応する前記少なくとも１つの抽出されたパラメータを含む少なくとも１つの管理メッセージを前記マルチキャスト配信グループの前記アドレスに送信するステップ（Ｅ７００、Ｇ７）とを含む、方法。
【請求項６】
マルチキャスト配信グループ（Ｇ）において配信されるデータストリームへの加入を要求するデバイスであって、前記マルチキャスト配信グループは、サーバ（１０１）と、第１のクライアント（２０１）と、第２のクライアント（２０２）とを含むソースを含み、前記ソースは、電子通信ネットワーク（３０１）を通して一緒に接続され、
前記マルチキャスト配信グループは、アドレスによって識別され、
第１のソースによって前記マルチキャスト配信グループの前記アドレスに送信されるストリームは、第２のソースが前記第１のソースによって送信されたデータストリームに以前に加入していた場合、前記第２のソースによって受信され、
前記第１のクライアントは前記サーバによって送信されたデータストリームに加入し、
前記デバイス（１００）は、
前記サーバから発せられた、前記第２のクライアントによって前記マルチキャスト配信グループの前記アドレスに送信された前記ストリームに関連する少なくとも１つの品質パラメータを含む少なくとも１つの管理メッセージを受信するモジュール（１４０）と、
前記受信した少なくとも１つの品質パラメータに依存する基準に応じて、前記第２のクライアントによって送信されたデータストリームへの加入を判断するモジュール（１５０）と、
肯定的な判断の場合、前記第２のクライアントによって送信されたデータストリームへの加入を要求するメッセージを送信するモジュール（１６０）とを備え、
前記第1のクライアントが前記デバイスを備える、デバイス。
【請求項７】
マルチキャスト配信グループ（Ｇ）において配信されるデータストリームを管理するデバイスであって、前記マルチキャスト配信グループは、サーバ（１０１）と、第１のクライアント（２０１）と、少なくとも１つの第２のクライアント（２０２、２０ｘ）とを含むソースを含み、前記ソースは、電子通信ネットワーク（３０１）を通して一緒に接続され、
前記マルチキャスト配信グループは、アドレスによって識別され、
第１のソースによって前記マルチキャスト配信グループの前記アドレスに送信されるストリームは、第２のソースが前記第１のソースによって送信されたデータストリームに以前に加入していた場合、前記第２のソースによって受信され、
前記第１のクライアントは前記サーバによって送信されたデータストリームに加入し、
前記サーバは、前記少なくとも１つの第２のクライアントによって送信されたデータストリームに加入しており、前記第２のクライアントが前記マルチキャスト配信グループの前記アドレスに送信したストリームを受信し、そこから前記ストリームの品質に関連する少なくとも１つのパラメータを抽出することが可能であり、
前記デバイス（２００）は、
前記抽出された少なくとも１つのパラメータに応じて、前記少なくとも１つの第２のクライアントの中から少なくとも１つのクライアントを選択するモジュール（２６０）と、
前記少なくとも１つの選択されたクライアントに対応する前記少なくとも１つの抽出されたパラメータを含む少なくとも１つの管理メッセージを前記マルチキャスト配信グループの前記アドレスに送信するモジュール（２７０）とを備え、
前記サーバが前記デバイスを備える、デバイス。
【請求項８】
マルチキャスト配信グループのクライアント設備機器であって、前記クライアント設備機器は、電子通信ネットワークに接続され、請求項６に記載のデータストリームへの加入を要求するデバイスを備える、クライアント設備機器。
【請求項９】
マルチキャスト配信グループのサーバ設備機器であって、前記サーバ設備機器は、電子通信ネットワークに接続され、請求項７に記載のデータストリームを管理するデバイスを備える、サーバ設備機器。
【請求項１０】
請求項９に記載のサーバ設備機器を備え、請求項８に記載のクライアント設備機器を少なくとも２つ備え、前記サーバ設備機器及び前記クライアント設備機器は、電子通信ネットワークを通して一緒に接続される、マルチキャスト配信グループ。
【請求項１１】
プロセッサによって実行されると、請求項１に記載のデータストリームへの加入を要求する方法のステップを実施する命令を含むことを特徴とする、コンピュータプログラム。
【請求項１２】
請求項１１に記載のプログラムが記録される、クライアント設備機器によって読み取り可能な記録媒体。
【請求項１３】
プロセッサによって実行されると、請求項５に記載のデータストリームを管理する方法のステップを実施する命令を含むことを特徴とするコンピュータプログラム。
【請求項１４】
請求項１３に記載のプログラムが記録される、サーバ設備機器によって読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の適用は、マルチキャストデータストリーム配信グループの分野にある。
【０００２】
より正確には、発明の適用は、双方向マルチキャスト配信グループと、マルチキャストクライアントから発せられたストリームへの加入とに関する。
【背景技術】
【０００３】
ＩＰ（インターネットプロトコル）ネットワークにおいてマルチキャストトランスポートを実施するサービスは当初、マルチキャストクライアントを宛先としたマルチキャストサーバから発せられたパケットの配信に制限されていた。したがって、インターネットを介してテレビを配信する場合、ネットワークフロントエンドサーバは、オペレータによって制御されるか、又はオペレータが契約を交わしたコンテンツプロバイダによって制御され、それにより、オペレータ又はコンテンツプロバイダがクライアントまでのサービスの品質を制御できるようにする。
【０００４】
現在、トランスポートのマルチキャストモードはもはや、サーバからマルチキャストクライアントへの下り方向で使用されるのみならず、各マルチキャストクライアントがトランスポートネットワークを介してマルチキャストＩＰパケットをマルチキャストグループに送信できるようにすることによって使用されている。
【０００５】
あるクライアントが高ビットレートのマルチキャストＩＰトラフィックを、他のクライアントが加入者であるマルチキャストグループのＩＰアドレスに送信する場合、ＩＰネットワークにアクセスする他のクライアントのインターフェースは、あるクライアントのマルチキャストＩＰトラフィックによって飽和する危険がある。
【０００６】
マルチキャストクライアントが受信するマルチキャストストリームの数を制限するために、マルチキャストクライアントは、マルチキャストグループのＩＰアドレスに加えて、例えば、標準ＩＥＴＦのＲＦＣ３３７６（インターネットエンジニアリングタスクフォース、リクエストフォーコメンツ）に定義されるＩＧＭＰｖ３プロトコル（インターネットグループ管理プロトコル）又は標準ＩＥＴＦ  ＲＦＣ３８１０に定義されるＭＬＤｖ２プロトコル（マルチキャストリスナ発見）を用いて、許可又は除外されるべき１つ又は複数のソースＩＰアドレスを指定することにより、マルチキャストストリームを受信するようにネットワークに求めることができる。
【０００７】
本文書において以下、マルチキャストクライアントが、別のクライアント又はサーバによって送信されるマルチキャストストリームに加入する場合、これは、この別のクライアント又はサーバのＩＰアドレスがマルチキャストストリーム受信要求において指定されていることを意味する。
【０００８】
（特許文献１）には、ＩＧＭＰｖ３又はＭＬＤｖ２要求のアドミッションを制御する方法が記載されており、保証された下りビットレートを認可された上りビットレートと比較することにより、クライアントに返送されるマルチキャストストリームの数を制限できるようにするが、この方法は、これらのビットレートがアドミッション制御エンティティにとって既知であると仮定する。
【０００９】
これらのビットレートは常に既知であるわけではない。このようなことは、例えば、マルチキャストストリームが、ＷｉＦｉアクセスポイントを通してネットワークにアクセスしているマルチキャストクライアントによって送信される場合に該当する。その場合、全てのＷｉＦｉ端末がＩＥＥＥ（米電気電子技術者協会）標準８０２．１１ｅを実施しているわけではないため、様々な上りＩＰマルチキャストストリームのビットレートを事前に知ることは不可能である。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】国際公開第２０１１／０６７４９５号
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明の目的の１つは、従来技術のこれらの欠点を解消することである。
【課題を解決するための手段】
【００１２】
本発明は、マルチキャスト配信グループにおいて配信されるデータストリームへの加入を要求する方法を用いて状況を改善し、上記グループは、サーバと、第１のクライアントと、第２のクライアントとを含むソースを含み、上記ソースは、電子通信ネットワークを通して一緒に接続され、マルチキャスト配信グループは、アドレスによって識別され、第１のソースによってマルチキャストグループのアドレスに送信されるストリームは、第２のソースが第１のソースに以前に加入していた場合、第２のソースによって受信され、第１のクライアントはサーバに加入し、方法は、第１のクライアントによって実施される、
・サーバから発せられた、第２のクライアントによってマルチキャストグループのアドレスに送信されたストリームに関連する少なくとも１つの品質パラメータを含む少なくとも１つの管理メッセージを受信するステップと、
・受信した少なくとも１つの品質パラメータに依存する基準に応じて、第２のクライアントへの加入を判断するステップと、
・肯定的な判断の場合、第２のクライアントへの加入を要求するメッセージを送信するステップと
を含む。
【００１３】
本発明により、双方向マルチキャストグループの第１のクライアントは、第２のクライアントに加入する前に、サーバから、第２のクライアントによって送信されたストリームの品質パラメータを取得する。したがって、サーバから得られた１つ又は複数の品質パラメータが、第２のクライアントへの第１のクライアントの加入を条件付ける基準が満たされていないこと、例えば、信号が高すぎるビットレート又は大きすぎるキュー内のメモリを要求すること等を示す場合、第１のクライアントは、第２のクライアントに加入しないと決定し得る。従来の技法によれば、あるクライアントは、別のクライアントに加入して、その別のクライアントによって送信されたマルチキャストストリームを受信する前に、その別のクライアントによって送信されたマルチキャストストリームの品質に関連する情報は利用可能ではなかった。
【００１４】
本発明の一態様によれば、判断するステップは、第２のクライアントによってマルチキャストグループのアドレスに送信されたストリームを受信するために必要な平均ビットレート値を含む基準を考慮に入れ、少なくとも１つの品質パラメータに基づいてこの値を計算するステップが先行する。
【００１５】
例えば、ＲＦＣ３５５０に従ってマルチキャストサーバによって送信されるＲＴＣＰ  ＳＲ（リアルタイム転送制御プロトコル、送信者要求）型の管理メッセージに含まれる品質パラメータは、受信パケット数、受信したＲＴＰパケット（リアルタイム転送プロトコル）の有用バイト数、及びＲＴＰセッションが開始されてから失われたＲＴＰパケット数である。
【００１６】
したがって、有利なことには、これらの品質パラメータを用いて、第１のクライアントが第２のクライアントによって送信されたストリームの平均ビットレートを計算することが可能であり、この平均ビットレートは、このストリームを受信するために必要な平均ビットレートと同一である。
【００１７】
本発明の一態様によれば、判断するステップは、第２のクライアントによってマルチキャストグループのアドレスに送信されたストリームを受信するために必要なキューサイズの値を含む基準を考慮に入れ、少なくとも１つの品質パラメータに基づいてこの値を計算するステップが先行する。
【００１８】
例えば、ＲＦＣ３６１１に従ってマルチキャストサーバにより送信されるＲＴＣＰ  ＸＲ（拡張リポート）型の管理メッセージに含まれる品質パラメータは、損失ＲＴＰパケットレート、到着が遅いか、又は早期到着に起因して考慮に入れられなかったＲＴＰパケットのレート、バースト中に失われたか、又は考慮に入れられなかったＲＴＰパケットのレート、２つのバースト間に失われたか、又は考慮に入れられなかったＲＴＰパケットのレートである。
【００１９】
したがって、有利なことに、これらの品質パラメータを用いて、第１のクライアントが、第２のクライアントによって送信されたストリームに関連付けられたキューサイズの値を計算することが可能である。
【００２０】
本発明の一態様によれば、加入要求メッセージは、計算された値を含む。
【００２１】
計算されたビットレートは、第１のクライアントが、第２のクライアントに加入する前に、ビットレートに関して既に受信したものへの追加のビットレートを表す。同様に、計算されたキューサイズは、第１のクライアントが、第２のクライアントに加入する前に、キューに関して既に受信したものへの追加のサイズを表す。
【００２２】
有利なことに、ストリームを受信するために計算された平均ビットレート及び／又は計算されたキューサイズを加入要求に含めることにより、第１のクライアントが、このビットレート又はこの追加のキューサイズが自由に使えるか否かを知らずに加入を決定した場合、要求を受信したネットワークの別のエンティティが、この追加のビットレートが実際に、第１のクライアントに向けた下り方向で利用可能であるかを検証することができる。
【００２３】
今述べたデータストリームへの加入を要求する方法の様々な態様は、互いから独立して又は互いと組み合わせて実施することができる。
【００２４】
本発明は、全ての実施形態において、今説明したデータストリームへの加入を要求する方法を実施することができる、データストリームへの加入を要求するデバイスに更に関する。
【００２５】
本発明は、マルチキャスト配信グループにおいて配信されるデータストリームを管理する方法にも関し、上記グループは、サーバと、第１のクライアントと、少なくとも１つの第２のクライアントとを含むソースを含み、上記ソースは、電子通信ネットワークを通して一緒に接続され、マルチキャスト配信グループは、アドレスによって識別され、第１のソースによってマルチキャストグループのアドレスに送信されるストリームは、第２のソースが第１のソースに以前に加入していた場合、第２のソースによって受信され、第１のクライアントはサーバに加入し、サーバは、上記少なくとも１つの第２のクライアントに加入しており、第２のクライアントがマルチキャストグループのアドレスに送信したストリームを受信し、そこから上記ストリームの品質に関連する少なくとも１つのパラメータを抽出することが可能であり、本方法は、サーバによって実施される、
・抽出された少なくとも１つのパラメータに応じて、少なくとも１つの第２のクライアントの中から少なくとも１つのクライアントを選択するステップと、
・少なくとも１つの選択されたクライアントに対応する少なくとも１つの抽出されたパラメータを含む少なくとも１つの管理メッセージをマルチキャストグループのアドレスに送信するステップと
を含む。
【００２６】
サーバは、マルチキャストグループの全てのストリームへの加入者であり、したがって、特に、第１及び第２の端末によってマルチキャストグループのアドレスに送信されるメッセージ、例えば、ペイロードデータと、送信者の識別子とを含むＲＴＰ型のメッセージを含め、マルチキャストグループの全ての端末によって送信される全てのストリームを受信する。
【００２７】
したがって、これにより、サーバは、端末から受信したペイロードデータの特定の品質パラメータを測定し、特定の品質パラメータを端末に関連付けることができる。
【００２８】
したがって、サーバは、マルチキャストグループのアドレスへのストリーム、すなわち、グループの全ての端末へのストリームにおいて、特定の数のパラメータを含む管理メッセージを送信することが可能になり、特定の数のパラメータは、これらの端末のそれぞれで、グループの１つ又は複数の他の端末のストリームへの加入の判断を助ける。
【００２９】
これらの管理メッセージは、例えば、ＲＴＣＰ  ＳＲ又はＸＲ型のメッセージであり、この型のメッセージは、送信ソースの識別子と、所与の時間間隔で受信したバイト又はパケットの数、損失パケット数、ジッタ等の特定の品質パラメータとを含み、これらのパラメータは、ソース、すなわちクライアントと、上り方向でのネットワークのノードとの間のリンクの品質を表す。
【００３０】
特定の端末は、不良な上りストリーム品質を有し、サーバ以外のマルチキャストグループのストリームへの加入を望む他の端末にとって不良な候補になる。
【００３１】
選択ステップにより、サーバは、上りストリームの品質が不良な端末に関連する情報項目を管理メッセージからなくすことができ、これは、それらの他の端末を良好な加入候補として見なすことから除外する。
【００３２】
したがって、有利なことに、本発明によれば、サーバによって送信されるＲＴＣＰ  ＳＲ／ＸＲメッセージの数は、ＲＴＰストリームを受信するとすぐにそのようなメッセージを自動的にディスパッチする従来技法よりも低減される。
【００３３】
さらに、品質不良なストリームに関連する管理メッセージは、端末がそれらを受信することが難しい場合のみ利用可能である。送信ステップにより、端末は、従来技法とは対照的に、利用可能な管理メッセージのみを受信する。
【００３４】
本発明は、全ての実施形態において、今説明したデータストリームを管理する方法を実施することができる、データストリームを管理するデバイスに更に関する。
【００３５】
本発明は、電子通信ネットワークに接続され、上述した等のデータストリームへの加入を要求するデバイスを備えるマルチキャスト配信グループのクライアント設備機器にも関する。このクライアント設備機器は、例えば、スマートフォン、デジタルタブレット、コンピュータ、又はセンサ等のユーザ端末であり得る。
【００３６】
本発明は、電子通信ネットワークに接続され、上述した等のデータストリームを管理するデバイスを備えるマルチキャスト配信グループのサーバ設備機器にも関する。このサーバ設備機器は、例えば、テレビジョンサーバ、ゲームサーバ、テレビ会議サーバ、又はセンサネットワークサーバであり得る。
【００３７】
本発明は、上述した等のサーバ設備機器と、少なくとも２つのクライアント設備機器とを備えるマルチキャスト配信グループに更に関し、設備機器は、電子通信ネットワークを通して一緒に接続される。
【００３８】
本発明は、プロセッサによって実行される場合、今説明したデータストリームへの加入を要求する方法のステップを実施する命令を含むコンピュータプログラムにも関する。
【００３９】
本発明は、今説明したプログラムが記録される、クライアント設備機器によって読み取り可能な記録媒体に更に関し、本記録媒体は、任意のプログラミング言語を使用することが可能であり、ソースコード、オブジェクトコード、部分的にコンパイルされた形態等のソースコードとオブジェクトコードとの間の中間コード、又は任意の他の所望の形態であることができる。
【００４０】
本発明は、プロセッサによって実行されると、今説明したデータストリームを管理する方法のステップを実施する命令を含むコンピュータプログラムにも関する。
【００４１】
最後に、本発明は、今説明したプログラムが記録される、サーバ設備機器によって読み取り可能な記録媒体に関し、本記録媒体は、任意のプログラミング言語を使用することが可能であり、ソースコード、オブジェクトコード、部分的にコンパイルされた形態等のソースコードとオブジェクトコードとの間の中間コード、又は任意の他の所望の形態であることができる。
【００４２】
本発明の他の利点及び特徴が、単純な例示的で非限定的な例として、且つ添付図面として与えられる本発明の特定の実施形態の以下の説明を読むことでより明確に明らかになろう。
【図面の簡単な説明】
【００４３】
【図１】本発明の態様による、サーバを含む幾つかのソースを備えるネットワーク内のマルチキャスト配信グループを概略的に提示する。
【図２】本発明の態様による、例示的な一連の出来事を一緒に提示するとともに、データストリームへの加入を要求する方法及びデータストリームを管理する方法のステップの実施を提示する。
【図３】本発明の態様による、データストリームへの加入を要求する方法のステップのクライアントによる例示的な実施を提示する。
【図４】本発明の態様による、データストリームを管理する方法のステップのサーバによる例示的な実施を提示する。
【図５】本発明の態様による、データストリームへの加入を要求するデバイスの例示的な構造を提示する。
【図６】本発明の態様による、データストリームを管理するデバイスの例示的な構造を提示する。
【発明を実施するための形態】
【００４４】
発明の少なくとも１つの実施形態の詳細な説明
続く説明において、ＩＥＴＦのマルチキャスト配信プロトコルに基づく本発明の幾つかの実施形態の例が提示されるが、本発明は、例えば、ＡＴＭ（非同期転送モード）若しくはＥｔｈｅｒｎｅｔ等の他のプロトコル又はＺｉｇＢｅｅ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、若しくはＷｉＦｉ等のセンサに適する転送プロトコルにも適用される。
【００４５】
図１は、本発明の態様による、サーバを含む幾つかのソースを備えるネットワーク内のマルチキャスト配信グループを概略的に提示する。
【００４６】
アドレスａＧを有するそのようなマルチキャスト配信グループＧにおいて、各ソースは、電子通信ネットワーク３０１、一般にＩＰ型のネットワークに接続され、パケットをネットワーク３０１のパケットのａＧに送信することができる。
【００４７】
ソースは、クライアント２０１〜２０ｘ等のクライアント又はサーバ１０１等のサーバのいずれかである。
【００４８】
最小限でも、各クライアント２０１〜２０ｘは、サーバ１０１によって送信される、アドレスａＧを有するマルチキャストストリームに加入している。したがって、全てのクライアントは、実線で示されるように、サーバによってａＧに送信される全てを受信する。クライアントは、別のクライアントによって送信される、アドレスａＧを有するマルチキャストストリームに明示的に加入していない限り、この別のクライアントによって送信されるものを受信しない。
【００４９】
サーバ側で、サーバは、クライアント２０１〜２０ｘのそれぞれによって送信される、アドレスａＧを有するマルチキャストストリームに加入する。したがって、サーバは、破線で示されるように、ａＧにクライアントによって送信される全てを受信し、それにより、サーバが、特に各ＲＴＰトラフィックを受信できるようにする。
【００５０】
マルチキャストグループにおいて、クライアントは、ＲＴＰトラフィックとも呼ばれるリアルタイムデータと、ＲＴＣＰメッセージとも呼ばれる制御メッセージとを送信する。ＲＴＰパケットは、例えば、１０ミリ秒毎に配信されるが、ＲＴＣＰ制御メッセージは、より低い頻度、例えば、１秒毎に配信される。
【００５１】
サーバがクライアントから受信したＲＴＰトラフィックにより、サーバは、このクライアントによって送信されたストリームに関連する情報項目を取得し、サーバによって受信されたこのクライアントのストリームの品質に関連するパラメータを含む、ＲＴＣＰ  ＳＲ又はＸＲ型のメッセージを送信することができる。
【００５２】
本発明によれば、サーバは、ＲＴＣＰ  ＳＲ又はＸＲメッセージを送信するクライアントを選択する。逆に、ＲＦＣ３５５０によって制約される従来の技法は、クライアントとサーバとを区別せず、サーバにそのようなメッセージをマルチキャストグループの全てのクライアントに強制的に送信させるか、又はそのようなメッセージをいずれのクライアントにも送信しない。有利なことに、本発明によるサーバは、例えば、品質パラメータが不十分な値を示すクライアントを選択しない。
【００５３】
本発明によれば、別のクライアントに加入したいクライアントは、サーバから受信されるＲＴＣＰ  ＳＲ又はＸＲメッセージを用いて、ストリームを受信するために必要な平均ビットレートを計算することができ、したがって、利用可能な下りビットレートに応じて、加入が可能か否かを判断することができる。
【００５４】
しかし、加入するために、このクライアントは、ストリームを受信したく、必要な平均ビットレートを計算したクライアントのＩＰアドレスを知らなければならない。ＲＴＣＰ  ＳＲ又はＸＲメッセージは、ＲＴＰメッセージのように、参照するストリームのいかなるソースＩＰアドレスも含まず、ＳＳＲＣ（同期ソース）識別子のみを含み、ＩＰネットワークとマルチキャストネットワークとの独立性を保証する。
【００５５】
しかし、サーバがクライアントから受信するＳＤＥＳ（ソース記述）ＲＴＣＰメッセージにより、ＩＰアドレスをクライアントのＳＳＲＣ識別子に関連付けることができる。実際に、ＳＤＥＳ  ＲＴＣＰ型のメッセージは、送信ソースのＳＳＲＣ識別子に加えて、このソースのＩＰｖ４又はＩＰｖ６アドレスをＡＳＣＩＩ形態で含む別の識別子を含む。
【００５６】
サーバは、様々なクライアントから受信したＳＤＥＳ  ＲＴＣＰメッセージをアドレスａＧに再送することができるか、又はそれらのメッセージを集約して、集約ＳＤＥＳ  ＲＴＣＰメッセージをアドレスａＧに送信することができる。クライアントが集約ＳＤＥＳ  ＲＴＣＰメッセージを受信する場合、これにより、他のクライアントのＩＰアドレスをＳＳＲＣ識別子に関連付けることができる。これは、少なくとも２つの理由により必要である。
１．第１の理由は、ＩＧＭＰｖ３又はＭＬＤｖ２要求を使用したクライアントへの加入要求が、このクライアントのＩＰアドレスを指定しなければならず、一方、ＲＦＣ３５５０によるＲＴＣＰ  ＳＲ又はＸＲメッセージが、ソースのＳＳＲＣ識別子のみを指定することである。
２．第２の理由は、ＳＳＲＣ識別子がマルチキャストグループにおいて一意でなければならず、サーバによって送信されたマルチキャストストリームのみに加入するクライアントが、既に使用されているＳＳＲＣ識別子を知らず、既に使用されている識別子が割り当てられる可能性が非常に高く、それにより、競合するクライアントへのマルチキャスト配信の品質が低下する可能性が高くなることである。
【００５７】
図２は、本発明の態様による、例示的な一連の出来事を一緒に提示するとともに、データストリームへの加入を要求する方法及びデータストリームを管理する方法のステップの実施を提示する。
【００５８】
説明を容易にするために、図ではクライアント数を２に低減し、サーバ以外の第２のソースへの加入を望んでいる第１のクライアント２０１及び単一の第２のクライアント２０２がある。以下の説明は、幾つかの第２のクライアント２０２、２０３、２０４等が、第１のクライアント２０１及びサーバ１０１を有するマルチキャストグループの部分を形成する場合にも当てはまる。
【００５９】
ステップＥ４００中、サーバ１０１は、ＩＧＭＰｖ３又はＭＬＤｖ２要求をネットワーク３０１に送信し、アドレスａＧをマルチキャストグループアドレスとして指定し、いかなるソースアドレスも除外しないことにより、マルチキャストアドレスａＧへのストリームセットに加入する。
【００６０】
ステップＥ５００中、サーバ１０１は、ソースアドレスＳを使用して、ＲＴＰトラフィックをマルチキャストアドレスａＧに送信開始する。クライアント２０１及び２０２のいずれも、アドレスＳによってマルチキャストアドレスａＧに送信されるストリームに個々に加入してない限り、このトラフィック又はアドレスＳによって送信されるいかなる他のトラフィックも受信しない。
【００６１】
ステップＥ４０１中、クライアント２０１は、ＩＧＭＰｖ３又はＭＬＤｖ２要求をネットワーク３０１に送信し、アドレスａＧをマルチキャストグループアドレスとして指定し、アドレスＳをソースアドレスとして指定することにより、アドレスＳによってマルチキャストアドレスａＧに送信されるストリームに加入する。クライアント２０１は、アドレスＳ、すなわちサーバによってマルチキャストグループに送信されたＲＴＰトラフィックを受信開始する。
【００６２】
ステップＥ６０１中、クライアント２０１は、クライアント２０１のアドレスＩＰ１と、クライアント２０１の識別子ＳＳＲＣ１とを含むＳＤＥＳ  ＲＴＣＰメッセージを送信する。
【００６３】
ステップＥ５０１中、クライアント２０１は、ソースアドレスＩＰ１を使用してＲＴＰトラフィックをマルチキャストアドレスａＧに送信する。
【００６４】
ステップＥ４０２中、クライアント２０２は、ＩＧＭＰｖ３又はＭＬＤｖ２要求をネットワーク３０１に送信し、アドレスａＧをマルチキャストグループアドレスとして指定し、アドレスＳをソースアドレスとして指定することにより、アドレスＳによってマルチキャストアドレスａＧに送信されたストリームに加入する。クライアント２０２は、アドレスＳ、すなわちサーバによってマルチキャストグループに送信されたＲＴＰトラフィックを受信開始する。
【００６５】
ステップＥ６０２中、クライアント２０２は、クライアント２０２のアドレスＩＰ２と、クライアント２０２の識別子ＳＳＲＣ２とを含むＳＤＥＳ  ＲＴＣＰメッセージを送信する。
【００６６】
ステップＥ５０２中、クライアント２０２は、ソースアドレスＩＰ２を使用してＲＴＰトラフィックをマルチキャストアドレスａＧに送信する。
【００６７】
ステップＥ５０３中、サーバ１０１は、マルチキャストアドレスａＧを宛先としたＲＴＰトラフィックを以前に受信しており、各ＲＴＰトラフィックで得られるパラメータに応じて、ソース２０１及び２０２の中から少なくとも１つのクライアントを選択する。ステップ５０３中、サーバ１０１は、ＲＴＰパケットのヘッダに含まれるシーケンス番号の連続性を検証することにより、ソースから発せられた受信ＲＴＰトラフィックがパケット損失を示すか否かを判断することができる。サーバ１０１は、例えば、パケット損失がない場合、ソースクライアントのみの選択を決定し得る。過度の到着間ジッタ等の他の選択基準を利用することもでき、到着間ジッタはＲＦＣ３５５０において定義されている。
【００６８】
説明を容易にするために、以下、クライアント２０２がこのステップＥ５０３中に選択されるクライアントの中にあると仮定する。
【００６９】
ステップＥ６００中、サーバ１０１は、ステップＥ５０３中に選択されるクライアントから発せられた、ステップＥ６０１及びＥ６０２に続けて受信されたＳＤＥＳ  ＲＴＣＰメッセージの抽出から構成される集約ＳＤＥＳ  ＲＴＣＰメッセージを生成し送信する。したがって、集約ＳＤＥＳ  ＲＴＣＰメッセージを受信しているクライアントは、その他のクライアントのＳＳＲＣに関連付けられたＩＰアドレスを認識し、ＳＳＲＣの生じ得る衝突を検出することができる。
【００７０】
ステップＥ６０３中、クライアント２０１は、集約ＳＤＥＳ  ＲＴＣＰメッセージを受信し、集約ＳＤＥＳ  ＲＴＣＰメッセージが含む対｛ＩＰアドレス，ＳＳＲＣ識別子｝を記憶する。特に、クライアント２０１はこれ以降、識別子ＳＳＲＣ２がアドレスＩＰ２に対応することを知る。
【００７１】
ステップＥ７００中、サーバ１０１は、ステップＥ５０３中に選択されたクライアントによって送信されたＲＴＰトラフィックに関連する品質パラメータを含むＲＴＣＰ  ＳＲメッセージを送信し、これらのクライアントは、メッセージ内のＳＳＲＣによってのみ識別される。ＲＴＰパケットのヘッダに含まれるシーケンス番号及び時間情報は、ＲＦＣ３５５０において定義されるように、この目的で使用される。
【００７２】
ステップＥ７０１中、クライアント２０１は、クライアント２０２によって送信されたＲＴＰトラフィックに関連する品質パラメータを含むＲＴＣＰ  ＳＲメッセージを受信する。ＲＴＣＰ  ＳＲメッセージは、識別子ＳＳＲＣ２を示すが、アドレスＩＰ２は示さない。標準ＩＥＴＦ  ＲＦＣ３５５０は、ＲＴＣＰ  ＳＲメッセージについて以下の情報項目を定義している。
・以下の情報項目が対応する、受信したＲＴＰストリームを送信するＲＴＰソースのＳＳＲＣ識別子、
・ＲＴＰソースから発せられた、ＲＴＰセッションが開始されてから受信されたＲＴＰパケットの有用バイトの数ＯＣ、
・ＲＴＰソースから発せられた、ＲＴＰセッションが開始されてから受信したＲＴＰパケットの数ＰＣ、
・ＲＴＰソースから発せられた、ＲＴＰセッションが開始されてから失われたＲＴＰパケットの数ＬＰＣ、
・ＲＦＣ３５５０によって定義されるアルゴリズムに従って計算された到着間ジッタ。
【００７３】
各ＲＴＣＰ  ＳＲメッセージは加えて、送信の瞬間に関連する時間情報項目ＮＴＰ（ネットワーク時間プロトコル）を含む。
【００７４】
ステップＥ４０３中、クライアント２０１は、ステップＥ７０１中に受信したメッセージに含まれる情報項目を用いて、クライアント２０２によって送信されたストリームに関連付けられた平均ビットレート値を計算する。
【００７５】
この有用平均ビットレート値は、クライアント（すなわち、本例ではクライアント２０１）によって受信され、ソースＳＳＲＣ（ｉ）（すなわち、本例ではクライアント２０２）に関連する情報項目ＯＣ（ｎ，ｉ）及びＬＰＣ（ｎ，ｉ）を含むＲＴＣＰ  ＳＲメッセージの送信の瞬間ＮＴＰ（ｎ）と、このクライアント（２０１）によって受信され、同じソースＳＳＲＣ（ｉ）に関連する情報項目ＯＣ（ｎ＋ｊ，ｉ）及びＬＰＣ（ｎ＋ｊ，ｉ）を含む任意の後続するＲＴＣＰ  ＳＲメッセージの送信の瞬間ＮＴＰ（ｎ＋ｊ）との間にある時間期間毎に計算することができる。
【００７６】
値ＬＰＣ（ｎ＋ｊ，ｉ）が値ＬＰＣ（ｎ，ｉ）に等しい場合、ソースＳＳＲＣ（ｉ）によって単位時間当たりに送信されるパケットの平均数ＭＰＲは、
ＭＰＲ＝［ＰＣ（ｎ＋ｊ，ｉ）−ＰＣ（ｎ，ｉ）］／［ＮＴＰ（ｎ＋ｊ）−ＮＴＰ（ｎ）］
に等しいものとして計算することができる。
【００７７】
なお、値ＬＰＣ（ｎ＋ｊ，ｉ）が値ＬＰＣ（ｎ，ｉ）に等しくない場合、これは、サーバが、この時間期間中にソースＳＳＲＣ（ｉ）から発せられたＲＴＰパケットの全セットをまだ受信しておらず、したがって、クライアント（２０１）が、このソースから発せられているマルチキャストストリームを受信するようにネットワークに求める場合、このソースから発せられているＲＴＰパケットの全セットを受信しない大きなリスクがあることを示す。実際に、ＩＰネットワークコアは一般に良好なサイズであるため、パケット損失の最も予想される原因は、例えば、ソースＳＳＲＣ（ｉ）と、ソースＳＳＲＣ（ｉ）が取り付けられるＷｉＦｉアクセスポイントとの間のＷｉＦｉセグメントであるか、又はこのＷｉＦｉアクセスポイントのネットワークへの接続リンクのいずれかである。
【００７８】
対応する平均ビットレートを評価するために、ＭＰＳ＝［ＯＣ（ｎ，ｉ）／ＰＣ（ｎ，ｉ）］に等しいものとして、ＲＴＰストリームを送るためにソースＳＳＲＣ（ｉ）によって使用されるＩＰパケットのペイロードの平均サイズＭＰＳを決定することが可能である。
【００７９】
ペイロードのこの平均サイズが整数であり、［ＯＣ（ｎ＋ｊ，ｉ）／ＰＣ（ｎ＋ｊ，ｉ）］＝［ＯＣ（ｎ，ｉ）／ＰＣ（ｎ，ｉ）］を変更しない場合、クライアントは、このソースにより単位時間当たりで送信されたパケットの平均数を、搬送するＩＰパケットのＩＰｖ４ヘッダ（２０バイト）又はＩＰｖ６ヘッダ（４０バイト）及びＵＤＰヘッダ（８バイト）のサイズＨＳによって増大するペイロードの平均サイズで乗算したものに等しいものとして、ソースＳＳＲＣ（ｉ）によって送信されたＲＴＰストリームに対応する平均ビットストリームを評価することが可能である。
【００８０】
例えば、式：
ＭＰＲ×ＭＰＳ＝｛［ＯＣ（ｎ＋ｊ，ｉ）−ＯＣ（ｎ，ｉ）］＋ＨＳ×［ＰＣ（ｎ＋ｊ，ｉ）−ＰＣ（ｎ，ｉ）］｝／［ＮＴＰ（ｎ＋ｊ）−ＮＴＰ（ｎ）］
に従って平均ビットレートを計算することが可能である。
【００８１】
ステップＥ４０４中、クライアント２０１は、クライアント２０２によってマルチキャストアドレスａＧに送信されたストリームへの加入を決定する又は決定しない。クライアント２０１は、ネットワークとネゴシエーションした帯域幅を認識する場合、下り帯域幅が、ステップＥ４０３中に計算された平均ビットレートに十分である場合のみ、加入を決定し得る。
【００８２】
ステップＥ４０５中、クライアント２０１は、ＩＧＭＰｖ３又はＭＬＤｖ２要求をネットワーク３０１に送信し、アドレスａＧをマルチキャストアドレスとして指定し、アドレスＩＰ２をソースアドレスとして指定することにより、クライアント２０２のアドレスＩＰ２によって送信されたマルチキャストアドレスａＧを宛先としたストリームに加入する。クライアント２０１は、ステップＥ６０３中に記憶された対の中から、クライアント２０２の識別子ＳＳＲＣ２に対応するＩＰアドレスを探すことにより、アドレスＩＰ２を取得する。
【００８３】
次に、クライアント２０１は、クライアント２０２によってマルチキャストグループに送信されたＲＴＰトラフィックを受信開始することができる。
【００８４】
クライアント２０１は、ネットワークとネゴシエーションした帯域幅を認識しない場合、ステップＥ４０３中に計算された平均ビットレートをＩＧＭＰｖ３又はＭＬＤｖ２要求に含め得、したがって、ネットワークは、アドミッション制御と呼ばれるものを実行することにより、判断することをできる。
【００８５】
代替の実施形態では、サーバは、ＲＴＣＰ  ＳＲメッセージの代替又は追加として、ＲＴＣＰ  ＸＲメッセージを送信する。
【００８６】
このモードでは、上記のステップＥ７００中、代替又は相補的に、サーバ１０１は、ステップＥ５０３中に選択されたクライアントによって送信されるＲＴＰトラフィックに関連する、ＲＴＣＰ  ＳＲ型のメッセージに含まれるものとは異なる品質パラメータを含むＲＴＣＰ  ＸＲメッセージを送信し、ステップＥ５０３中に選択されたクライアントは、メッセージ内のＳＳＲＣによってのみ識別される。
【００８７】
このモードでは、上記のステップＥ７０１中、クライアント２０１は、クライアント２０２によって送信されたＲＴＰストリームに関連する品質パラメータを含むＲＴＣＰ  ＸＲメッセージを受信する。ＲＴＣＰ  ＸＲメッセージは、識別子ＳＳＲＣ２を示すが、アドレスＩＰ２を示さない。標準ＩＥＴＦ  ＲＦＣ３６１１は、ＲＴＣＰ  ＸＲメッセージについて以下の情報項目を定義している。
・以下の情報項目が対応する、受信したＲＴＰストリームを送信したＲＴＰソースのＳＳＲＣ（同期ソース）識別子、
・ＲＴＰソースから発せられたＲＴＰストリームが受信開始されてからの損失パケットレート（損失レート）、
・ジッタ抑制バッファのドレイン又はオーバーフローを誘導する到着の遅れ又は早期到着に起因して考慮されなかった、ＲＴＰソースから発せられたＲＴＰストリームのパケットレート（破棄レート）、
・ＲＴＰソースから発せられたＲＴＰストリームについて、バースト中に失われたか、又は考慮されなかったパケットレート（バースト密度）、
・ＲＴＰソースから発せられたＲＴＰストリームについて、２つのバースト間に失われたか、又は考慮されなかったパケットのレート（ギャップ密度）、
・ＲＴＰソースから発せられたＲＴＰストリームについて、バーストの平均持続時間（バースト持続時間）、
・ＲＴＰソースから発せられたＲＴＰストリームについて、２つのバースト間の平均持続時間（ギャップ持続時間）。
【００８８】
やはりこのモードでは、上記のステップＥ４０３中、クライアント２０１は、ステップＥ７０１中に受信されるＲＴＣＰ  ＸＲメッセージに含まれる情報項目を用いて、クライアント２０２によって送信されたストリームを受信するために必要なキューサイズの値を計算する。
【００８９】
ＲＴＣＰ  ＸＲメッセージに含まれる情報項目により、クライアント２０１は、バーストの平均持続時間、２つのバースト間の平均持続時間、及び所与のＲＴＰソースによって送信されたＲＴＰストリームを受信するジッタ抑制バッファのドレイン又はオーバーフローに起因して失われたか、又は考慮されなかったパケットのレートを突き止めることができる。したがって、ジッタ抑制バッファのサイズが分かっていると仮定すると、クライアントは、所与のＲＴＰソースによって送信されるＲＴＰストリームを受信する容量を評価することができる。
【００９０】
ジッタ抑制バッファのサイズが、バーストの平均持続時間及び２つのバースト間の平均持続時間よりも大きく、且つジッタ抑制バッファのドレイン又はオーバーフローに起因して失われたか、又は考慮されなかったパケットのレートが低い、例えば１％である場合、ＲＴＰクライアントは、例えば、問題となっているＲＴＰソースによって送信されたＲＴＰストリームへの加入を決定し得る。
【００９１】
ＩＥＴＦがなお、ＲＴＣＰ  ＳＲ又はＸＲメッセージに相補的であり、別のクライアントによって送信されたストリームの受信を決定するためにクライアントによって有用であり得る他の情報項目を含む新しいメッセージを定義することができることに留意する。その場合、本メカニズムは同様に適用することが可能である。
【００９２】
図３は、本発明の態様による、データストリームへの加入を要求する方法のステップのクライアントによる例示的な実施を提示する。
【００９３】
ステップＦ１中、クライアント２０１は、ネットワーク３０１に、サーバ１０１のＩＰアドレスをソースとして指定しながら、アドレスａＧを有するマルチキャストグループへの加入要求を送信する。
【００９４】
ステップＦ２中、クライアント２０１は、クライアント２０１のアドレスＩＰ１と、割り振られた識別子ＳＳＲＣ１とを含むＳＤＥＳ  ＲＴＣＰメッセージを送信する。
【００９５】
ステップＦ３中、クライアント２０１は、ＲＴＰパケットの形態でアドレスａＧにリアルタイムデータを送信する。
【００９６】
ステップＦ４中、クライアント２０１は、アドレスａＧを有するマルチキャストグループの様々なソースに対応する対｛ＩＰアドレス，ＳＳＲＣ識別子｝を含む、サーバ１０１から発せられた集約ＳＤＥＳ  ＲＴＣＰメッセージを受信する。
【００９７】
ステップＦ５中、クライアント２０１は、受信した対をテーブルＴに記憶する。
【００９８】
ステップＦ６中、クライアント２０１は、アドレスａＧを有するマルチキャストグループのクライアントソースのＲＴＰトラフィックに関連する品質パラメータを含む、サーバ１０１から発せられたＲＴＣＰ  ＳＲ（及び／又はＸＲ）メッセージを受信する。
【００９９】
ステップＦ７中、クライアント２０１は、クライアント２０２によって送信されたストリームを受信するために必要な平気ビットレート値及び／又はキューサイズの値を計算する。
【０１００】
ステップＦ８中、クライアント２０１は、ネットワークとの接続で利用可能なビットレート及び／又はキューのサイズに応じて、クライアント２０２のストリームへの加入を決定する又は決定しない。
【０１０１】
ステップＦ９中、ステップＦ８に続けて肯定応答の場合、クライアント２０１は、テーブルＴを照会して、識別子ＳＳＲＣ２を知っているクライアント２０２に対応するＩＰアドレスを取得し、クライアント２０２のアドレスであるアドレスＩＰ２をソースとして指定しながら、アドレスａＧを有するマルチキャストグループへの加入要求を送信する。
【０１０２】
代替的には、判断ステップＦ８は省くことができ、ステップＦ９中、クライアント２０１は、ステップＦ７中に計算された１つ又は複数の値を加入要求に含め、ネットワークのエンティティに、加入要求が満たされ得るか、又は満たされなければならないかを判断させることができる。
【０１０３】
図４は、本発明の態様による、データストリームを管理する方法のステップのサーバによる例示的な実施を提示する。
【０１０４】
ステップＧ１中、サーバ１０１は、いかなるソースも除外せずに、マルチキャストグループのアドレスａＧを指定する加入要求をネットワーク３０１に送信することにより、アドレスａＧを有するマルチキャストグループに加入する。
【０１０５】
ステップＧ２中、サーバ１０１は、ＲＴＰパケットの形態でアドレスａＧにリアルタイムデータを送信する。
【０１０６】
ステップＧ３−１、Ｇ３−２、Ｇ３−ｘ（Ｇ３−１及びＧ３−２と同様であるため、図示せず）中、サーバ１０１は、クライアント２０１、２０２、２０ｘからそれぞれ発せられた、送信者クライアントのＩＰアドレスと、割り振られたＳＳＲＣ識別子とを含むＳＤＥＳ  ＲＴＣＰメッセージを受信する。
【０１０７】
ステップＧ４−１、Ｇ４−２、Ｇ４−ｘ（Ｇ４−１及びＧ４−２と同様であるため、図示せず）中、サーバ１０１は、クライアント２０１、２０２、２０ｘからそれぞれ発せられた、ＲＴＰパケットの形態のリアルタイムデータのストリームを受信する。
【０１０８】
ステップＧ５中、サーバ１０１は、クライアント２０１、２０２、及び２０ｘの中から、ステップＧ４−１、Ｇ４−２、Ｇ４−ｘ中に受信したＲＴＰストリームの品質に関連するパラメータが、ゼロの損失パケット数及び／又は特定の閾値未満の到着間ジッタ等の満足のいく値を示すものを選択する。
【０１０９】
ステップＧ６中、サーバ１０１は、ステップＧ５中に選択されたクライアントに関連する対｛ＩＰアドレス，ＳＳＲＣ識別子｝を含む集約ＳＤＥＳ  ＲＴＣＰメッセージを生成し、送信する。
【０１１０】
ステップＧ７中、サーバ１０１は、ステップＧ５中に選択されたクライアントソースのＲＴＰトラフィックに関連する品質パラメータを含むＲＴＣＰ  ＳＲ（及び／又はＸＲ）メッセージを送信し、ステップＧ５中に選択されたクライアントは、メッセージ内のＳＳＲＣのみによって識別される。
【０１１１】
図５と併せて、これより、本発明の態様による、データストリームへの加入を要求するデバイスの例示的な構造を提示する。
【０１１２】
データストリームへの加入を要求するデバイス１００は、様々な実施形態について今説明した、データストリームへの加入を要求する方法を実施する。
【０１１３】
そのようなデバイス１００は、スマートフォン、デジタルタブレット、コンピュータ、又はセンサ等のユーザ端末で実施することができる。
【０１１４】
例えば、デバイス１００は、マイクロプロセッサμＰが備えられ、コンピュータプログラム１１０によって駆動される処理ユニット１３０を備え、コンピュータプログラム１１０は、メモリ１２０に記憶され、本発明によるデータストリームへの加入を要求する方法を実施する。初期化されると、コンピュータプログラム１１０のコード命令は、例えば、ＲＡＭメモリにロードされ、それから、処理ユニット１３０のプロセッサによって実行される。
【０１１５】
そのようなデバイス１００は、
・マルチキャストグループのサーバから、マルチキャストグループのクライアント端末によりマルチキャストグループのアドレスに送信されたストリームに関連する少なくとも１つの品質パラメータを含む少なくとも１つの管理メッセージを受信することができる受信モジュール１４０と、
・受信した少なくとも１つの品質パラメータに依存する基準に応じて、クライアント端末のストリームへの加入を判断することができる判断モジュール１５０と、
・肯定判断の場合、クライアント端末のストリームへの加入を要求するメッセージを送信することができる送信モジュール１６０と
を備える。
【０１１６】
有利なことに、処理ユニット１３０は、
・少なくとも１つの品質パラメータに基づいて、クライアント端末によりマルチキャストグループのアドレスに送信されたストリームを受信するために必要な平均ビットレート値を計算することができる計算モジュール１７０と、
・少なくとも１つの品質パラメータに基づいて、クライアント端末によりマルチキャストグループのアドレスに送信されたストリームを受信するために必要なキューサイズの値を計算することができる計算モジュール１８０と
を備えることができる。
【０１１７】
図６と併せて、これより、本発明の態様によるデータストリームを管理するデバイスの例示的な構造を提示する。
【０１１８】
データストリームを管理するデバイス２００は、様々な実施形態を今説明したデータストリームを管理する方法を実施する。
【０１１９】
そのようなデバイス２００は、ＴＶサーバ、ゲームサーバ、テレビ会議サーバ、又はセンサネットワークサーバ等のマルチキャストサーバで実施することができる。
【０１２０】
例えば、デバイス２００は、マイクロプロセッサμＰが備えられ、コンピュータプログラム２１０によって駆動される処理ユニット２３０を備え、コンピュータプログラム２１０は、メモリ２２０に記憶され、本発明によるデータストリームを管理する方法を実施する。初期化されると、コンピュータプログラム２１０のコード命令は、例えば、ＲＡＭメモリにロードされ、それから、処理ユニット２３０のプロセッサによって実行される。
【０１２１】
そのようなデバイス２００は、
・少なくとも１つのクライアント端末からマルチキャストグループのアドレスに送信された少なくとも１つのストリームを受信することができる受信モジュール２４０と、
・上記ストリームの品質に関連する少なくとも１つのパラメータを抽出するのに適する抽出モジュール２５０と、
・抽出された少なくとも１つのパラメータに応じて、上記クライアント端末の中から少なくとも１つを選択することができる選択モジュール２６０と、
・選択された少なくとも１つのクライアントに対応する抽出された少なくとも１つのパラメータを含む少なくとも１つの管理メッセージをマルチキャストグループのアドレスに送信することができる送信モジュール２７０と
を備える。
【０１２２】
図５及び図６と併せて説明したモジュールは、ハードウェアモジュール又はソフトウェアモジュールであることができる。
【０１２３】
今提示した本発明の例示的な実施形態は、考えられる実施形態のうちの単なる少数である。今提示した本発明の例示的な実施形態は、本発明により、マルチキャスト配信グループのクライアントが、下り方向において十分な受信ビットレートを有することが保証される場合のみ、別のクライアントのストリームに加入することができ、中央サーバが、トランスポートネットワークによって保証され許可される上りビットレート及び下りビットレートを認識しない場合であってもそれを行う。
【符号の説明】
【０１２４】
１００  デバイス
１０１  サーバ
１１０  コンピュータプログラム
１２０  メモリ
１３０  処理ユニット
１４０  受信モジュール
１５０  判断モジュール
１６０  送信モジュール
１７０  計算モジュール
１８０  計算モジュール
２００  デバイス
２０１、２０２、２０３  クライアント
２１０  コンピュータプログラム
２２０  メモリ
２３０  処理ユニット
２４０  受信モジュール
２５０  抽出モジュール
２６０  選択モジュール
２７０  送信モジュール
３０１  ネットワーク
【図１】
0006523260.tif 000002
【図２】
0006523260.tif 000003
【図３】
0006523260.tif 000004
【図４】
0006523260.tif 000005
【図５】
0006523260.tif 000006
【図６】
0006523260.tif 000007