(57)【要約】本発明は、移動体通信システムのエアインタフェースを介してマルチキャストサービスまたはブロードキャストサービスを受信する複数の移動端末のフィードバックの送信を、フィードバック制御エンティティによって制御する方法と、この方法を用いる移動端末と、フィードバック制御エンティティとに関する。更に、フィードバック制御エンティティと、マルチキャストサービスまたはブロードキャストサービスを受信する移動端末とを備える通信システムが提供される。エンドツーエンドセッションのコンセプトを維持しながらエアインタフェースを介して供給されるマルチキャストサービスまたはブロードキャストサービスに対する構成可能で適応的なフィードバックを可能にするために、本発明は、フィードバック制御エンティティが、フィードバック制御エンティティに対してフィードバックを供給するマルチキャストサービスまたはブロードキャストサービスを受信する、移動体通信システムの移動端末のサブセットを決定選択することを提案する。本発明の一実施の形態では、端末は、シグナリングを用いてフィードバック制御エンティティによってフィードバック供給を開始または停止することを指示される。
2008512014.tif 000002
【特許請求の範囲】
【請求項１】
移動体通信システムのエアインタフェースを介してマルチキャストサービスまたはブロードキャストサービスを受信する複数の移動端末のフィードバックの送信を、フィードバック制御エンティティによって制御する方法であって、前記フィードバック制御エンティティによって実行される、
一方向ダウンリンクチャネルを介して、少なくとも１つの移動端末に、低信頼転送プロトコルと、前記マルチキャストサービスまたはブロードキャストサービスを受信する端末のフィードバック供給を構成するセッションプロトコルとを用いて、前記マルチキャストサービスまたはブロードキャストサービスのデータを送信または転送するステップと、
前記複数の移動端末の中から、前記フィードバック制御エンティティに対して、前記セッションプロトコルにより構成されるフィードバックの供給について前記マルチキャストサービスまたはブロードキャストサービスを受信する複数の移動端末を決定するステップと、
決定した前記複数の移動端末を識別するフィードバック制御データを決定するステップと、
少なくとも決定した前記複数の移動端末に、前記フィードバック制御データを送信するステップと、
決定した前記複数の移動端末のうちの少なくとも１つの移動端末から、前記セッションプロトコルにより構成されるフィードバックを受信するステップと、
を有する方法。
【請求項２】
送信する前記フィードバック制御データは、決定した前記複数の移動端末を識別する少なくとも１つの端末識別子、または決定した前記複数の移動端末を識別する端末識別子の範囲を示す、請求項１記載の方法。
【請求項３】
送信する前記フィードバック制御データ情報は、少なくとも１つの端末識別子または端末識別子の範囲が前記フィードバック制御データによって示されるか否かを示す領域を更に備える、請求項１または請求項２記載の方法。
【請求項４】
前記フィードバック制御データは、前記フィードバック制御エンティティによって維持され、または前記移動体通信システムのネットワークエンティティから受信される前記マルチキャストサービスおよびブロードキャストサービスの状態情報に基づいて決定される、請求項１乃至請求項３のいずれかに記載の方法。
【請求項５】
前記フィードバック制御データは、前記マルチキャストサービスまたはブロードキャストサービスを提供するマルチキャストデータチャネルまたはブロードキャストデータチャネルを介して送信される、請求項１乃至請求項４のいずれかに記載の方法。
【請求項６】
前記フィードバック制御データは、潜在的な受信器に前記マルチキャストサービスまたはブロードキャストサービスをアナウンスするためのアナウンスメントチャネルを介して送信される、請求項１乃至請求項４のいずれかに記載の方法。
【請求項７】
信頼性の高い通信プロトコルが前記アナウンスメントチャネル上でのデータ転送に使用される、請求項６記載の方法。
【請求項８】
前記セッションプロトコルにより構成されるフィードバックを供給する移動端末の数は、前記マルチキャストサービスまたはブロードキャストサービスの参加者数、および前記セッションプロトコルにより構成されるフィードバックを供給するセッションの利用可能な帯域幅の一部に基づいて決定される、請求項１乃至請求項７のいずれかに記載の方法。
【請求項９】
前記フィードバック制御エンティティによって維持または受信される前記状態情報から、前記マルチキャストサービスまたはブロードキャストサービスの参加者数を取得するステップを更に供える、請求項８記載の方法。
【請求項１０】
前記マルチキャストサービスまたはブロードキャストサービスの前記状態情報は、前記フィードバック制御エンティティで保持されるＭＢＭＳ  ＵＥコンテキストまたはＭＢＭＳベアラコンテキスト内に含まれる、請求項９記載の方法。
【請求項１１】
ＭＢＭＳ  ＵＥコンテキストまたはＭＢＭＳベアラコンテキストを保持する前記移動体通信ネットワークのネットワークエンティティから、前記マルチキャストサービスまたはブロードキャストサービスの前記状態情報を受信するステップを更に備える、請求項１０記載の方法。
【請求項１２】
マルチキャストサービスプロバイダまたはブロードキャストサービスプロバイダから、前記マルチキャストサービスまたはブロードキャストサービスのデータを受信するステップを更に備える、請求項１乃至請求項１１のいずれかに記載の方法。
【請求項１３】
前記フィードバックエンティティで受信した前記セッションプロトコルにより構成されるフィードバックを、前記マルチキャストサービスプロバイダまたはブロードキャストサービスプロバイダに送るステップを更に備える、請求項１２記載の方法。
【請求項１４】
前記マルチキャストサービスのデータは、転送プロトコルおよびセッションプロトコルを用いて前記フィードバック制御エンティティに転送され、
前記移動端末に前記マルチキャストサービスまたはブロードキャストサービスのデータを送信または転送する前に、転送プロトコルまたはセッションプロトコルのうちの少なくとも１つを、別の転送プロトコルまたはセッションプロトコルに変更するステップを更に備える、請求項１２または請求項１３記載の方法。
【請求項１５】
前記マルチキャストサービスに対するフィードバックは、転送プロトコルおよびセッションプロトコルを用いて前記フィードバック制御エンティティに転送され、
前記マルチキャストサービスプロバイダまたはブロードキャストサービスプロバイダに前記フィードバックを転送する前に、転送プロトコルまたはセッションプロトコルの少なくとも１つを、別の転送プロトコルまたはセッションプロトコルに変更するステップを更に備える、請求項１３または請求項１４記載の方法。
【請求項１６】
前記フィードバック制御エンティティで受信した前記セッションプロトコルにより構成されるフィードバックの集約体を形成するステップと、
前記セッションプロトコルにより構成されるフィードバックの集約体を、前記マルチキャストサービスプロバイダまたはブロードキャストサービスプロバイダに送信するステップとを更に備える、請求項１２記載の方法。
【請求項１７】
少なくとも決定した前記複数の移動端末に前記フィードバック制御データを送信する際にタイマを開始するステップを更に備える、請求項１乃至請求項１６のいずれかに記載の方法。
【請求項１８】
セッションにより構成されるフィードバックが、前記タイマが切れる前に前記複数の移動端末から受信されたか否かを判断するステップと、
前記セッションにより構成されるフィードバックが、前記タイマが切れる前に前記複数の移動端末の少なくとも１つから受信されていないと前記フィードバック制御エンティティが判断した場合に、セッションプロトコルにより構成されるフィードバックを供給するように前記少なくとも１つの端末に指示するフィードバック制御データを、前記少なくとも１つの端末に送信するステップとを備える請求項１７記載の方法。
【請求項１９】
前記サービスは、マルチキャストサービスであり、
前記マルチキャストサービスまたはブロードキャストサービスを受信する移動端末に、端末識別子を割り当てるステップと、
各端末識別子を対応する移動端末に送信するステップとを更に備える、請求項２乃至請求項１８のいずれかに記載の方法。
【請求項２０】
各端末識別子を、前記マルチキャストサービスまたはブロードキャストサービスの状態情報に記憶するステップを更に備える、請求項１９記載の方法。
【請求項２１】
前記状態情報に基づいてフィードバック制御データを決定するステップを更に備える、請求項２０記載の方法。
【請求項２２】
移動体通信システムのフィードバック制御エンティティによって送信または転送される、前記移動体通信システムのエアインタフェースを介してマルチキャストサービスまたはブロードキャストサービスを受信する複数の移動端末のフィードバックの送信を制御する方法であって、前記移動端末によって実行される、
一方向ダウンリンクチャネルを介して、低信頼転送プロトコルと、前記マルチキャストサービスまたはブロードキャストサービスを受信する端末のフィードバック供給を構成するセッションプロトコルとを用いて、前記マルチキャストサービスまたはブロードキャストサービスを受信するステップと、
前記移動端末が、セッションプロトコルにより構成されるフィードバックを前記フィードバック制御エンティティに対して供給するように指示されたか否かを示すフィードバック制御データを受信するステップと、
前記フィードバック制御データが、セッションプロトコルにより構成されるフィードバックを供給するように指示する場合に、前記フィードバック制御エンティティにフィードバックを供給するためのベアラを確立するステップと、
確立した前記ベアラを介して、前記マルチキャストサービスまたはブロードキャストサービスの受信統計を示す、セッションプロトコルにより構成されるフィードバックを、前記フィードバック制御エンティティに送信するステップと、
を備える方法。
【請求項２３】
受信する前記フィードバック制御データは、フィードバックを供給するように指示される、前記マルチキャストサービスまたはブロードキャストサービスを受信する移動端末の少なくとも１つの端末識別子、またはフィードバックを供給するように指示される、前記マルチキャストサービスまたはブロードキャストサービスを受信する移動端末を識別する端末識別子の範囲を示す、請求項２２記載の方法。
【請求項２４】
受信する前記フィードバック制御データは、前記少なくとも１つの端末識別子または端末識別子の範囲が前記フィードバック制御データによって示されるか否かを示す領域を更に備える、請求項２３記載の方法。
【請求項２５】
前記フィードバック制御データは、前記マルチキャストサービスまたはブロードキャストサービスを提供するマルチキャストデータチャネルまたはブロードキャストデータチャネルを介して受信される、請求項２２乃至請求項２４のいずれかに記載の方法。
【請求項２６】
前記フィードバック制御データは、潜在的な受信器に対して前記マルチキャストサービスまたはブロードキャストサービスをアナウンスするためのアナウンスメントチャネルを介して受信される、請求項２２乃至請求項２４のいずれかに記載の方法。
【請求項２７】
信頼性の高い通信プロトコルが前記アナウンスメントチャネル上でのデータ転送に使用される、請求項２６記載の方法。
【請求項２８】
前記フィードバック制御エンティティから、セッションプロトコルにより構成されるフィードバックを供給しているどの移動端末がフィードバック供給を停止するかを示す再構成データを受信するステップを更に備える、請求項２２乃至請求項２６のいずれかに記載の方法。
【請求項２９】
前記移動端末がフィードバック供給を停止するように指示されると、確立した前記ベアラを壊すステップを更に備える、請求項２８記載の方法。
【請求項３０】
前記サービスは、マルチキャストサービスであり、
端末識別子を受信するステップを更に備える、請求項１乃至請求項２９のいずれかに記載の方法。
【請求項３１】
前記端末識別子は、前記マルチキャストサービスのサービス参加手順において受信される、請求項３０記載の方法。
【請求項３２】
受信した前記フィードバック制御データが端末識別子を示すか否かを判断するステップと、
示す場合に、セッションプロトコルにより構成されるフィードバックを供給するステップとを更に備える、請求項３０または請求項３１記載の方法。
【請求項３３】
前記フィードバック制御データ、および前記マルチキャストサービスまたはブロードキャストサービスは、ＦＬＵＴＥプロトコルに従ってダウンロードセッション内で供給される、請求項１乃至請求項３２のいずれかに記載の方法。
【請求項３４】
前記マルチキャストサービスまたはブロードキャストサービスは、ＲＴＰプロトコルを用いて供給され、フィードバックは、ＲＴＣＰプロトコルを用いて供給され、前記マルチキャストサービスまたはブロードキャストサービスを供給するセッションに対する利用可能な帯域幅の一部は、前記ＲＴＣＰプロトコルメッセージに割り当てられる、請求項１乃至請求項３２のいずれかに記載の方法。
【請求項３５】
前記セッションプロトコルにより構成されるフィードバックは、前記ＲＴＣＰプロトコルの受信器レポートの形態で供給される、請求項３４記載の方法。
【請求項３６】
前記フィードバック制御データは更に、前記ＲＴＣＰプロトコルを用いてセッションプロトコルにより構成されるフィードバックを供給するための、レポート時間間隔および利用可能な帯域幅を示す、請求項３４または請求項３５記載の方法。
【請求項３７】
前記フィードバック制御データは、前記フィードバック制御エンティティによって送信されるＲＴＣＰプロトコルの送信側レポートメッセージ内に含まれる、請求項１乃至請求項３２または請求項３４乃至請求項３６のいずれかに記載の方法。
【請求項３８】
移動端末のＩＭＳＩが端末識別子として使用される、請求項１乃至請求項１８、請求項２２乃至請求項２９または請求項３３乃至請求項３７のいずれかに記載の方法。
【請求項３９】
前記少なくとも１つのＩＭＳＩが備えるフィードバック制御データは、暗号化された形態で供給される、請求項３８記載の方法。
【請求項４０】
移動体通信システムのエアインタフェースを介して、フィードバック制御エンティティによって送信または転送されるマルチキャストサービスまたはブロードキャストサービスを受信する、複数の移動端末のフィードバックの送信を制御するフィードバック制御エンティティであって、
一方向ダウンリンクチャネルを介して、少なくとも１つの移動端末に対する低信頼転送プロトコルと、前記マルチキャストサービスまたはブロードキャストサービスを受信する端末のフィードバック供給を構成するセッションプロトコルとを用いて、前記マルチキャストサービスまたはブロードキャストサービスのデータを送信または転送する送信器と、
前記複数の移動端末の中から、前記フィードバック制御エンティティに対してプロトコルにより構成されるフィードバックを供給するための前記マルチキャストサービスまたはブロードキャストサービスを受信する複数の移動端末を決定し、決定した前記複数の移動端末を識別するフィードバック制御データを決定するプロセッサと、
決定した前記複数の移動端末のうちの少なくとも１つの移動端末から、セッションプロトコルにより構成されるフィードバックを受信する受信器とを備え、
前記送信器は、決定した前記複数の移動端末のうちの少なくとも１つの移動端末に前記フィードバック制御データを送信するように適合されている、フィードバック制御エンティティ。
【請求項４１】
請求項１乃至請求項２１または請求項３３乃至請求項３９のいずれかに記載の方法のステップを実行するように適応された手段を更に備える、請求項４０記載のフィードバック制御エンティティ。
【請求項４２】
フィードバック制御エンティティによって送信または転送されるマルチキャストサービスまたはブロードキャストサービスを、移動体通信システムのエアインタフェースを介して受信する移動端末であって、
一方向ダウンリンクチャネルを介して、低信頼転送プロトコルと、前記マルチキャストサービスまたはブロードキャストサービスを受信する端末のフィードバック供給を構成するセッションプロトコルとを用いて、前記マルチキャストサービスまたはブロードキャストサービスを受信すると共に、セッションプロトコルにより構成されるフィードバックを前記フィードバック制御エンティティに供給するように前記移動端末が指示されたか否かを示すフィードバック制御データを受信するように適合された受信器と、
前記フィードバック制御データがセッションプロトコルにより構成されるフィードバックを供給することを指示する場合に、前記フィードバック制御エンティティにフィードバックを供給するためのベアラを確立するプロセッサと、
確立した前記ベアラを介して、前記フィードバック制御エンティティに、前記マルチキャストサービスまたはブロードキャストサービスの受信統計を示す、セッションプロトコルにより構成されるフィードバックを送信する送信器と、
を備える移動端末。
【請求項４３】
請求項２２乃至請求項３９のいずれかに記載の方法のステップを実行するように適応された手段を更に備える、請求項４２記載の移動端末。
【請求項４４】
請求項４０または請求項４１記載のフィードバック制御エンティティと、
一方向ダウンリンクチャネルおよび低信頼転送プロトコルを用いてエアインタフェースを介してフィードバック制御エンティティからマルチキャストサービスまたはブロードキャストサービスを受信する、請求項４２または請求項４３記載の少なくとも１つの移動端末と、
を備える移動体通信システム。
【請求項４５】
フィードバック制御エンティティのプロセッサによって実行されると、
一方向ダウンリンクチャネルを介して、少なくとも１つの移動端末に対する低信頼転送プロトコルと、マルチキャストサービスまたはブロードキャストサービスを受信する端末のフィードバック供給を構成するセッションプロトコルとを用いて、前記マルチキャストサービスまたはブロードキャストサービスのデータを送信または転送し、
前記複数の移動端末の中から、前記フィードバック制御エンティティに対してプロトコルにより構成されるフィードバックを供給するための前記マルチキャストサービスまたはブロードキャストサービスを受信する複数の移動端末を決定し、決定した前記複数の移動端末を識別するフィードバック制御データを決定し、
決定した前記複数の移動端末のうちの少なくとも１つの移動端末から、セッションプロトコルにより構成されるフィードバックを受信することにより、
前記フィードバック制御エンティティによって送信または転送される前記マルチキャストサービスまたはブロードキャストサービスを、移動体通信システムのエアインタフェースを介して受信する移動端末のフィードバックの送信を、前記プロセッサに制御させる命令を記憶するコンピュータ読み取り可能媒体。
【請求項４６】
前記フィードバック制御エンティティのプロセッサによって実行されると、請求項１乃至請求項２１または請求項３３乃至請求項３９のいずれかに記載の方法のステップを前記プロセッサに実行させる命令を更に記憶する、請求項４５記載のコンピュータ読み取り可能媒体。
【請求項４７】
移動端末のプロセッサによって実行されると、
一方向ダウンリンクチャネルを介して、低信頼転送プロトコルと、マルチキャストサービスまたはブロードキャストサービスを受信する端末のフィードバック供給を構成するセッションプロトコルとを用いて、前記マルチキャストサービスまたはブロードキャストサービスを受信し、
セッションプロトコルにより構成されるフィードバックを前記フィードバック制御エンティティに供給するように前記移動端末が指示されたか否かを示すフィードバック制御データを受信し、
前記フィードバック制御データがセッションプロトコルにより構成されるフィードバックを供給することを指示する場合に、前記フィードバック制御エンティティにフィードバックを供給するためのベアラを確立し、
確立した前記ベアラを介して、前記フィードバック制御エンティティに、前記マルチキャストサービスまたはブロードキャストサービスの受信統計を示す、セッションプロトコルにより構成されるフィードバックを送信することにより、
前記フィードバック制御エンティティによって送信または転送される前記マルチキャストサービスまたはブロードキャストサービスを、移動体通信システムのエアインタフェースを介して受信する移動端末のフィードバックの送信を、前記プロセッサに制御させる命令を記憶するコンピュータ読み取り可能媒体。
【請求項４８】
前記移動端末のプロセッサによって実行されると、請求項２２乃至請求項３９のいずれかに記載の方法のステップを前記プロセッサに実行させる命令を更に記憶する、請求項４７記載のコンピュータ読み取り可能媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動体通信システムのエアインタフェースを介して、フィードバック制御エンティティによって送信または転送されるマルチキャストサービスまたはブロードキャストサービスを受信する移動端末のフィードバックの送信を制御する方法に関する。また、この方法を使用するフィードバック制御エンティティが提供される。更に、フィードバック制御エンティティと、マルチキャストサービスまたはブロードキャストサービスを受信する移動端末とを備える通信システムが提供される。
【背景技術】
【０００２】
リアルタイム転送プロトコル（ＲＴＰ）（http://www.ietf.orgで入手可能な非特許文献１参照）は、エンドツーエンドネットワーク転送機能を提供し、この機能は、マルチキャストネットワークサービスまたはユニキャストネットワークサービスにおいて、音声、映像、またはシミュレーションデータ等のリアルタイムデータを送信するためのアプリケーションに好適である。ＲＴＰは、リソース予約をせず、リアルタイムサービスのサービス品質を保証しない。
【０００３】
データ転送は、大規模マルチキャストネットワークに拡張可能にデータ配送をモニタリングし、最小限の制御および識別機能を提供するように、制御プロトコル（ＲＴＣＰ）によって拡張される。ＲＴＰおよびＲＴＣＰは、下位の（ｕｎｄｅｒｌｙｉｎｇ）転送レイヤおよびネットワークレイヤとは独立して設計される。
【０００４】
３Ｇネットワークにおけるストリーミングサービスのマルチキャストデータ転送またはブロードキャストデータ転送には、ＲＴＰを使用することができる。上述の通り、リアルタイム制御プロトコル（ＲＴＣＰ）は、配送ＲＴＰストリームにおける制御情報をモニタリングし、転送する手段を提供する。
【０００５】
一方向転送におけるＩＥＴＦ規格のプロトコルファイル配送（ＦＬＵＴＥ）（http://www.ietf.orgで入手可能な非特許文献２参照）は、マルチキャストネットワークに特に適した、インターネット上でのファイルの一方向配送のための手段を提供する。この規格は、非同期階層符号化で構築され、ベースプロトコルは、大規模に拡張可能なマルチキャスト配送用に設計されている。
【０００６】
３ＧネットワークＦＬＵＴＥは、ダウンロードサービスのマルチキャストデータ転送またはブロードキャストデータ転送に使用することもできる。
【０００７】
標準的なＦＬＵＴＥ
ＦＬＵＴＥは、数秒以上の配送セッションを用いて多数のホストに大小のファイルを配送するのに適用することができる。大規模な拡張性は、ＦＬＵＴＥの主な設計目的である。ＩＰマルチキャストは本質的に大規模に拡張可能であるが、提供するその最大のサービスは、セッション管理機能、輻輳制御または信頼性を提供しない。ＦＬＵＴＥは、ＩＰマルチキャストのどの本質的な拡張可能性も犠牲にすることなく、ＡＬＣおよびＩＰマルチキャストを用いてこの全てを提供する。ＦＬＵＴＥは、好適な輻輳制御構築ブロックを備えるインターネット使用と、無線ブロードキャストラジオシステム上の配送のような供給／制御システムとの双方に適用可能である。ＦＬＵＴＥは、マルチキャスト配送またはユニキャスト配送に使用され得るが、その主な適用法は、一方向性マルチキャストファイル配送である。ＦＬＵＴＥは、送信側と受信側の間の接続を必要とするが、受信側から送信側への接続は必要としない。
【０００８】
結果として、ＦＬＵＴＥはＲＴＰ／ＲＴＣＰの場合のように、送信側へフィードバックを送信するどの固有の手段も提供しない。
【０００９】
標準的なＲＴＰ／ＲＴＣＰ
ＲＴＰ（およびその関連プロトコルＲＴＣＰ）はもともと、ユニキャストデータ転送とマルチキャストデータ転送（ＲＴＰレポート）の双方のために設計されている。そのため、フィードバック崩壊を防止する拡張可能なアルゴリズム、および対応するメカニズムが提案される。本明細書の以下では、この後者を、「標準ＲＴＣＰアルゴリズムおよびメカニズム」として称する。
【００１０】
ＲＴＣＰ標準的アルゴリズムおよびメカニズムは、基礎となるエニーソースマルチキャスト（ＡＳＭ）モデルを想定して設計され、全ての終端システムが、双方向転送チャネル上でデータを送受信することができる。
【００１１】
結果として、参加している終端システムのそれぞれは、ＲＴＰデータ、全ての参加者のＲＴＣＰ送信レポート（ＳＲ）および受信レポート（ＲＲ）を受信する。全てのＲＲの受信により、終端システムのそれぞれは、あるセッションの参加者数を独立して推定し、この値を用いてＲＴＣＰ標準的アルゴリズムに従うレポート時間間隔を計算する。更に、全ての参加者に関する情報を終端ホストが集めるための手段が提供され、これは少人数のグループ会議等の用途で有用となり得る。
【００１２】
一方向マルチキャストチャネルに対するＲＴＣＰ  ＲＲ
非特許文献３（ＲＦＣ３５６９参照、http//www.ietf.orgで入手可能）に記載されるソース指定マルチキャスト（ＳＳＭ）モデルは、http://www.3gpp.orgで入手可能な非特許文献４において特定される３ＧＰＰ  ＭＢＭＳアーキテクチャと関連して使用するのに特に適している。
【００１３】
ＳＳＭマルチキャストモデルは、ＡＳＭよりも複雑でなく、登録ベースのアクセス制御を可能にする。ＳＳＭでは、単一の終端システムのそれぞれが、一方向マルチキャスト転送チャネルを使用してデータを送信することができる。そのチャネルに登録をした参加者だけがメッセージを受信する。
【００１４】
ＡＳＭとは違って、ＲＴＣＰ受信レポートは、このマルチキャストチャネル上を送信され得ない。しかし、ＳＳＭに対するこの制限は、指定された受信器レポート帯域幅および送信器レポート帯域幅の値に応じて、各受信側が送信側に個々のユニキャスト転送チャネル上でフィードバックを送り、送信側がマルチキャストチャネル上でこれらのメッセージを反映することで克服される。
【００１５】
ＲＴＣＰに対するＳＤＰ帯域幅変更子
標準ＲＴＣＰのメカニズムは、全体的な制御トラフィック帯域幅をＲＴＰセッション帯域幅の５％に減らす。単一の送信側を含むターゲットアプリケーションシナリオについて、送信レポート（ＳＲ）に割り当てられるＲＴＰ帯域幅の部分Ｓは１．２５％であり、受信レポート（ＲＲ）について終端システムによって同様に共有される部分Ｒは３．７５％の値が割り当てられる。異なる配分での割り当てをサポートするために、セッション記述プロトコル（ＳＤＰ）内のＲＴＣＰ帯域幅変更子のシグナリングが、非特許文献５（ＲＦＣ３５５６参照、http://www.ietf.orgで入手可能）において提案されている。
【００１６】
特定のセッションに対するＳＤＰインスタンスは、２つの追加的なパラメータを用いて拡張され、ｂ＝ＲＳ：＜帯域幅−値＞は全体的な送信レポート速度を示し、ｂ＝ＲＲ＜帯域幅−値＞は全体的な受信レポート速度を示す。１ホスト当たりの配分およびレポートの時間間隔は、標準的なＲＴＣＰアルゴリズムに従って決定される。
【００１７】
マルチキャストフィードバック規制
ＩＥＴＦ  ＲＭＴワーキンググループ内で考えられている既存の作業の大部分は、冗長的なフィードバック、例えば信頼性の高いマルチキャスト送信に対して失われたデータパケットの否定応答を抑制する問題に取り組んでいる。他のマルチキャストアプリケーションは、特定の測定基準に応じた極値を有する終端システムのフィードバックを必要とする。
【００１８】
このスキームの目的は、マルチキャストセッションにおいて能力（帯域幅）が制限されている受信器を見つけることで、送信側が受信側のフィードバックについて伝送速度を調節することである。双方の問題に対するエンドツーエンド解決策は、通常、フィードバックタイマまたはポーリング機構の各種変形例を用いる。
【００１９】
殆どどの既存の作業も、マルチキャストに参加している受信側の状態情報を収集することに対するフィードバック規制に取り組まない。受信側の状態情報を収集することに基づく映像ストリーミングアプリケーションに対する１つの顕著な機構が、非特許文献６に記載されている。提案された機構の主な目的は、レポートされた状態情報に従ってパケットの送信速度を調節することにある。
【００２０】
したがって、受信側がレポートすることができる状態の組は、３つの異なる状態に制限されている。結果として、このアプローチは、以下の問題により、３ＧＰＰ  ＭＢＭＳセッションにおける統計のフィードバックを規制することに適用可能でない。
【００２１】
参加する終端システムの数は、ＲＴＣＰ  ＲＲを用いて各受信器によって発見されなくてはならない。このためには、参加する移動端末（ＭＴ、ＵＥ）それぞれが、送信器との一対一方向フィードバックチャネルを確立しなければならない。
【００２２】
送信側は、全てのＲＲを反映または集約し、一方向マルチキャストチャネル上でこの情報を送らなくてはならない。セルラ環境およびモバイル環境のコンテキストにおける本解決策の欠点は、明らかである。
【００２３】
・フィードバックチャネルの確立および維持にかかるコスト（ＭＴ／ＵＥ当たり１つ）
・反映されたレポートによって生成されるマルチキャストチャネルのオーバーヘッド
・状態情報を動的に維持し更新しなくてはならない終端装置の電力消費オーバーヘッド
【００２４】
ユニキャストフィードバックチャネルは、例えば全てのユーザが個々の拡散コード等を有する個別アップリンクチャネルを必要とする際、セル内で著しい量のリソースを必要とする場合がある。この状況は、対応するセルにおけるコールブロッキングおよびハンドオフドロッピングの確率を増加させる。
【００２５】
受信器毎の帯域幅ｂＲＲは、標準アルゴリズムを用いて以下のように計算される。
【数１】
2008512014.tif 000003
ここで、Ｔｍｉｎは最小時間間隔（例えば、５秒）、ＰＲＴＣＰはＲＴＣＰパケットサイズ、ＢＲＲは全体的な受信レポート帯域幅（ＲＴＰ帯域幅の３．７５％）、ｎは受信器の数である。グループサイズの関数として結果的に得られる受信器毎の帯域幅ｂＲＲは、図１に示される。
【００２６】
標準ＲＴＣＰアルゴリズムを用いて計算される受信器毎の帯域幅
進行中のセッション中に受信器が加わるか抜けることができるグループダイナミクスにより、有効的な受信器毎の帯域幅は、前もっては知られておらず、著しく変化する。現在のグループサイズに適応するようにフィードバックチャネルを頻繁に再確立するのを回避するために、受信側フィードバックチャネルは、リソースを上限、即ち最悪の場合、最大ＲＲ帯域幅として確立されなくてはならない。そのため、フィードバックチャネルに対して予約されたリソースは、極めて非効率的に使用され得る。
【００２７】
ＲＴＣＰ  ＲＲ時間間隔Ｔは、標準ＲＴＰアルゴリズムによって、以下のように計算される。
【数２】
2008512014.tif 000004
このとき、
【数３】
2008512014.tif 000005
ここで、Ｔｍｉｎは最小時間間隔、ｎは受信器の数、ＰＲＴＣＰはＲＴＣＰパケットサイズ、ＢＲＲは全体的な受信レポート帯域幅である。
【００２８】
図２は、ＲＲ時間間隔Ｔ（上記式に従って計算される）対ＲＴＰセッションに参加する受信器の数ｎを示す。時間間隔は、参加受信器の数と共に線形に増加する。
【００２９】
量的な効果を例示するためには、６４ｋｂｐｓのデータ速度で音声−映像コンテンツをストリーミングする実施例が考えられる。１２０バイトの平均ＲＴＣＰ  ＲＲパケットサイズ、およびｎ＝１００では、レポート時間間隔は、Ｔ１００＝４０秒と計算される。即ち、ｎ＝９０００の場合には、Ｔ９０００＝３６００秒＝１時間となる。
【００３０】
標準アルゴリズムに続いて、受信側は、均一分布に続く時間間隔［０．５Ｔ、１．５Ｔ］内で確率的にレポートパケットをスケジューリングする。つまり、上述の実施例では、最初のレポートパケットは、２０秒および０．５時間後にそれぞれ送られると予想される。この結果となるＲＲ時間間隔Ｔは、明らかに実用的な目的に関して許容できない。
【００３１】
上述の通り、標準的なＲＴＣＰの手法は、ＡＳＭモデルの特徴に取り組み、全ての終端システムが単一の双方向チャネル上でデータを送受信し、消失レポートの可能性も与える。しかし、３ＧＰＰ  ＭＢＭＳサービスでは、間隔はセッションの持続時間を容易に超えてしまうので、レポーティングすることが無意味となる。
【００３２】
更に、特にコンテンツベースの課金がブロードキャストデータ配送にも使用されるので、ブロードキャストデータの配送についてもブロードキャストサービスの受信側からフィードバックを供給することが考えられ、受信したコンテンツの品質は課金にとって重大であることに留意されたい。登録ベースの課金では、あるサービスが受信されたという事実だけが重要となる。
【００３３】
上述のＭＢＭＳ特有の問題は、例えばマルチキャストサーバまたはブロードキャストサーバのような送信源への受信端末からのフィードバックの供給を可能にするプロトコルを用いてエアインタフェースを介して移動端末で受信されるマルチキャストサービスまたはブロードキャストサービスによって一般化される。
【００３４】
特許文献１では、無線ネットワークにおいてマルチユーザサービスをレポーティングする方法が記載されている。この文献のコンセプトは、中間ネットワーク部においてエアインタフェースリソースのＲＮＣ知識に基づいて集合フィードバックレポートを生成することである。端末からのＲＴＣＰフィードバックは、マルチユーザサービス、即ちマルチユーザサービスの全ての受信器に対して無効となることもある。変形例では、マルチユーザサービスの全ての受信者が、事象駆動（ｅｖｅｎｔ  ｄｒｉｖｅｎ）フィードバックを供給するようにＲＮＣによって構成されてもよい。この受信側からの情報は、集合フィードバックを作成するようにＲＮＣで使用されてもよい。
【００３５】
特許文献１において提案される方法およびシステムは、マルチユーザサービスのソース、つまりサーバに送信される集合フィードバックレポートを生成するように、移動体通信システムの無線リソースにおけるＲＮＣの知識を用いる。それにより、例えば、データを通信するためにＲＮＣにおける無線リソース管理と中間ネットワーク部との間のセッションレイヤ、無線リソース制御、および所有者拡張として、エンドツーエンドコンセプトのマルチユーザサービスの供給は、この文献で提案される方法が異なるレイヤ間で相互作用およびデータ交換を必要とするため犠牲にされる。これらの拡張は、マルチキャストサービスまたはブロードキャストサービスを供給するアーキテクチャが幅広くなくてはならない場合には実現可能でない。
【特許文献１】国際公開第２００４／０４０９２８Ａ１号パンフレット
【非特許文献１】Schulzrinneet al., "RTP: A Transport Protocol for Real-Time Applications", RFC 3550
【非特許文献２】Paila et al., "FLUTE-File Delivery over Unidirectional Transport", draft-ietf-rmt-flute-07.txt, June 2004
【非特許文献３】S. Bhattacharyya, Ed. “An Overview of Source-Specific Multicast (SSM)”
【非特許文献４】3GPP TR 23.846: "Multimedia Broadcast/Multicast (MBMS); Architecture and functional description (Release 6)", V6.1.0, December 2003
【非特許文献５】Casner, “Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth”
【非特許文献６】Bolet et al., "Scalable Feedback Control for Multicast Video Distribution in the Internet" (Proceedings of ACM/SIGCOMM 1994, Vol. 24, No. 4, Oct. 1994)
【非特許文献７】RFC 3500, section 6.7
【非特許文献８】"RTP Control Protocol Extended Reports (RTCP XR)", Friedman et al.
【非特許文献９】RFC 3611, section 2
【非特許文献１０】section 3 of RFC3611
【発明の開示】
【００３６】
本発明の目的は、エンドツーエンドセッションのコンセプトを維持しながらエアインタフェースを介して提供されるマルチキャストサービスまたはブロードキャストサービスに対する構造化可能且つ適応可能なフィードバックを可能にすることである。更に、別の目的は、ＲＴＰプロトコルを用いて提供されるＭＢＭＳストリーミングサービスまたは、ＦＬＵＴＥプロトコルを用いて提供されるＭＢＭＳダウンロードサービスに対する構造化可能且つ適応可能なフィードバックを提供することである。
【００３７】
この目的は、独立項の技術的内容により達成される。本発明の有利な実施の形態は、従属項の技術的内容である。
【００３８】
本発明の主な態様の１つは、マルチキャストサービスまたはブロードキャストサービスに対してレポーティング受信器の組を決定的に選択する解決策を提供することにある。これは、例えばＭＢＭＳアーキテクチャにおけるＢＭ−ＳＣ等のフィードバック制御エンティティから所望のレポートを行う受信器を明示的にアドレス指定することで実現される。
【００３９】
本発明の実施の形態によると、移動体通信システムのエアインタフェースを介してマルチキャストサービスまたはブロードキャストサービスを受信する複数の移動端末のフィードバックの送信を制御する方法が提供される。フィードバック制御エンティティは、一方向ダウンリンクチャネルを介して、少なくとも１つの移動端末に、マルチキャストサービスまたはブロードキャストサービスのデータを送信または転送する。データ転送には、低信頼転送プロトコルおよびセッションプロトコルが利用され、セッションプロトコルは、マルチキャストサービスまたはブロードキャストサービスを受信する端末のフィードバック供給を構成する。フィードバック制御エンティティは更に、複数の移動端末の中から、フィードバック制御エンティティに対して、セッションプロトコルにより構成されるフィードバックの供給についてマルチキャストサービスまたはブロードキャストサービスを受信する複数の移動端末を決定し、決定した複数の移動端末を識別するフィードバック制御データを決定する。フィードバック制御エンティティは、少なくとも決定した複数の移動端末に、フィードバック制御データを送信し、決定した複数の移動端末のうちの少なくとも１つの移動端末から、セッションプロトコルにより構成されるフィードバックを受信する。
【００４０】
本実施の形態の変形例では、送信するフィードバック制御データは、決定した複数の移動端末を識別する少なくとも１つの端末識別子、または決定した複数の移動端末を識別する端末識別子の範囲を示す。
【００４１】
更に、別の変形例では、送信するフィードバック制御データ情報は、少なくとも１つの端末識別子または端末識別子の範囲がフィードバック制御データによって示されるか否かを示す領域を更に備える。
【００４２】
本発明の別の実施の形態では、フィードバック制御エンティティは、フィードバック制御エンティティによって維持され、または移動体通信システムのネットワークエンティティから受信されるマルチキャストサービスおよびブロードキャストサービスの状態情報に基づいてフィードバック制御データを決定してもよい。
【００４３】
本発明の更なる実施の形態では、フィードバック制御エンティティは、マルチキャストサービスまたはブロードキャストサービスを提供するマルチキャストデータチャネルまたはブロードキャストデータチャネルを介してフィードバック制御データを送信してもよい。したがって、本実施の形態によると、低信頼転送メカニズムが、移動端末にフィードバック制御データを送るために使用される。
【００４４】
代替的な本発明の別の実施の形態では、各移動端末がシグナリングされたフィードバック制御データを少なくとも一旦高い信頼性で受信することを確実にするために、フィードバック制御データは、マルチキャストサービスまたはブロードキャストサービスを潜在的な受信器に対してアナウンスするためのアナウンスメントチャネルを介してフィードバック制御エンティティによって送信される。これにより、本実施の形態の変形例では、信頼性の高い通信プロトコルが、アナウンスメントチャネル上での転送に使用される。
【００４５】
本発明の更なる実施の形態では、セッションプロトコルにより構成されるフィードバックを供給する移動端末の数は、マルチキャストサービスまたはブロードキャストサービスの参加者数等に基づいて決定される。更に、セッションプロトコルにより構成されるフィードバックを供給するセッションの利用可能な帯域幅の一部を考慮してもよい。
【００４６】
本実施の形態の変形例では、マルチキャストサービスまたはブロードキャストサービスの参加者数は、フィードバック制御エンティティによって維持または受信される状態情報から得られる。例えば、ＭＢＭＳアーキテクチャを考えると、マルチキャストサービスまたはブロードキャストサービスの状態情報は、フィードバック制御エンティティで保持されるＭＢＭＳ  ＵＥコンテキストまたはＭＢＭＳベアラコンテキスト内に含まれる。
【００４７】
以下により詳細に概要を説明すると、状態情報から、サービスの参加者数がフィードバック制御エンティティに直接的に利用可能でない可能性がある。この場合、マルチキャストサービスまたはブロードキャストサービスの状態情報は、ＭＢＭＳ  ＵＥコンテキストまたはＭＢＭＳベアラコンテキストを保持する移動体通信ネットワークのネットワークエンティティから受信されてもよい。
【００４８】
例えば、ＭＢＭＳアーキテクチャを考えると、ＧＧＳＮは、フィードバック制御エンティティとして機能するＢＭ−ＳＣに対して、マルチキャストサービスまたはブロードキャストサービスを受けている端末のうち、どの端末および／または幾つの端末がフィードバックを提供すべきかを決定する際に必要な情報をシグナリングする。
【００４９】
本発明の更なる実施の形態では、フィードバック制御エンティティは、マルチキャストサービスプロバイダまたはブロードキャストサービスプロバイダから、マルチキャストサービスまたはブロードキャストサービスのデータを受信してもよい。
【００５０】
本実施の形態の変形例では、フィードバック制御エンティティは、移動端末から受信したセッションプロトコルにより構成されるフィードバックを、マルチキャストサービスプロバイダまたはブロードキャストサービスプロバイダに転送してもよい。
【００５１】
更なる変形例では、マルチキャストサービスのデータは、転送プロトコルおよびセッションプロトコルを用いてフィードバック制御エンティティに転送されてもよい。フィードバック制御エンティティは、移動端末にマルチキャストサービスまたはブロードキャストサービスのデータを送信または転送する前に、転送プロトコルまたはセッションプロトコルのうちの少なくとも１つを、別の転送プロトコルまたはセッションプロトコルに変更してもよい。
【００５２】
更に、マルチキャストサービスに対するフィードバックは、転送プロトコルおよびセッションプロトコルを用いてフィードバック制御エンティティに転送されることも可能である。この場合、フィードバック制御エンティティは、マルチキャストサービスプロバイダまたはブロードキャストサービスプロバイダにフィードバックを転送する前に、転送プロトコルまたはセッションプロトコルの少なくとも１つを、別の転送プロトコルまたはセッションプロトコルに変更してもよい。
【００５３】
本実施の形態の別の変形例では、フィードバック制御エンティティは、移動端末から受信したセッションプロトコルにより構成されるフィードバックの集約体を形成し、フィードバック情報として受信したフィードバックの集約体を、マルチキャストサービスプロバイダまたはブロードキャストサービスプロバイダに送信してもよい。
【００５４】
本発明の別の実施の形態は、指示された移動端末がセッションプロトコルにより構成されるフィードバックを供給することを確実にするために使用される制御メカニズムを提供する。この目的のために、少なくとも複数の移動端末にフィードバック制御データを送信する際に、フィードバック制御エンティティでタイマが開始される。
【００５５】
更に、フィードバック制御エンティティは、セッションにより構成されるフィードバックが、タイマが切れる前に複数の移動端末から受信されたか否かを判断してもよい。フィードバック制御エンティティは、セッションにより構成されるフィードバックが、タイマが切れる前に複数の移動端末（フィードバックを供給すべき移動端末）の少なくとも１つから受信されていないと判断した場合、セッションプロトコルにより構成されるフィードバックを供給するように少なくとも１つの端末に指示するフィードバック制御データを、少なくとも１つの端末に送信する。
【００５６】
上記から明らかであるように、移動端末は、端末識別子によって識別されてもよい。端末識別子は、移動端末に割り当てられる一意（ｕｎｉｑｕｅ）識別子および／または一時（ｔｅｍｐｏｒａｒｙ）識別子でもよい。ここでいう「一意」とは、端末識別子が、フィードバック制御エンティティが制御するサービスエリア内で固有でなくてはならないことを意味する。したがって、端末識別子は、世界的に固有の識別子であってもよいし、なくてもよい。本発明の別の実施の形態によると、フィードバック制御エンティティは、マルチキャストサービスまたはブロードキャストサービスを受信する移動端末に端末識別子を割り当て、各端末識別子を対応する移動端末に送信する。
【００５７】
更に、フィードバック制御エンティティは、各端末識別子を、マルチキャストサービスまたはブロードキャストサービスの状態情報に記憶してもよい。フィードバック制御データは、この状態情報に基づいて決定されてもよい。つまり、セッションプロトコルにより構成されるフィードバックを供給するように指示される移動端末の端末識別子は、状態情報から抽出されてもよい。
【００５８】
本発明の更なる実施の形態は、移動体通信システムのフィードバック制御エンティティによって送信または転送される、移動体通信システムのエアインタフェースを介してマルチキャストサービスまたはブロードキャストサービスを受信する複数の移動端末のフィードバックの送信を制御する方法に関する。移動端末は、一方向ダウンリンクチャネルを介してマルチキャストサービスまたはブロードキャストサービスを受信してもよい。これにより、低信頼転送プロトコルおよびセッションプロトコルが使用され、セッションプロトコルは、マルチキャストサービスまたはブロードキャストサービスを受信する端末のフィードバック供給を構成する。
【００５９】
移動端末は、セッションプロトコルにより構成されるフィードバックをフィードバック制御エンティティに対して供給するように移動端末が指示されたか否かを示すフィードバック制御データを更に受信し、セッションプロトコルにより構成されるフィードバックを供給するようにフィードバック制御データが指示する場合には、フィードバック制御エンティティにフィードバックを供給するためのベアラを確立する。次に、確立したベアラを介して、マルチキャストサービスまたはブロードキャストサービスの受信統計を示す、セッションプロトコルにより構成されるフィードバックが、移動端末からフィードバック制御エンティティに送信される。
【００６０】
移動端末は、セッションプロトコルにより構成されるフィードバックを供給するようにフィードバック制御エンティティから指示されているか否かを、フィードバック制御データに基づいて判断してもよい。本実施の形態では、セッションプロトコルにより構成されるフィードバックを供給するためのベアラが、移動端末がセッションプロトコルにより構成されるフィードバックを供給すると判断した場合に確立され、この場合、移動体通信システムの無線アクセスネットワーク等におけるリソースが移動端末にだけ割り当てられるといった利点を有する。
【００６１】
受信するフィードバック制御データは、フィードバックを供給するように指示される、マルチキャストサービスまたはブロードキャストサービスを受信する移動端末の少なくとも１つの端末識別子、またはフィードバックを供給するよう指示される、マルチキャストサービスまたはブロードキャストサービスを受信する移動端末を識別する端末識別子の範囲を示してもよい。
【００６２】
先に述べたように、フィードバック制御データは、マルチキャストサービスまたはブロードキャストサービスを供給するマルチキャストデータチャネルもしくはブロードキャストデータチャネルを介して、またはマルチキャストサービスもしくはブロードキャストサービスを潜在的な受信器に対してアナウンスするためのアナウンスメントチャネルを介して受信されてもよい。
【００６３】
マルチキャストデータチャネルまたはブロードキャストデータチャネルを介してデータを受信する場合、データは、例えばＵＤＰのような低信頼転送プロトコルを用いて端末に伝送されてもよい。
【００６４】
各端末は、信頼性のある方法で少なくとも１回シグナリングされたフィードバック制御データを受信することが望ましい。フィードバック制御データが信頼性のない通信プロトコルを用いて供給される場合、各受信端末は、存在するセッションプロトコルにより構成されるフィードバックを供給すべきか否かを判断するために必要なパラメータを確実に有するとは限らない。したがって、本発明の更なる実施の形態では、アナウンスメントチャネルを介してデータを受信する際、信頼性の高い通信プロトコルがアナウンスメントチャネル上でのデータ転送に使用される。
【００６５】
本発明の別の実施の形態では、フィードバック制御エンティティが、個々の移動端末のフィードバック送信を開始および停止することが望ましい。先に述べたように、フィードバック制御データは、フィードバック供給を開始するように端末に指示するために使用されてもよい。更に、フィードバック制御エンティティによって送信される再構成データが、フィードバック供給を停止するように個々の移動端末に指示するために使用されてもよい。したがって、移動端末は、セッションプロトコルにより構成されるフィードバックを供給しているどの移動端末がフィードバック供給を停止すべきかを示す再構成データを受信する。
【００６６】
移動端末は、フィードバック供給を停止するように指示されると、確立したベアラを壊す。これは、利用されたエアインタフェースリソースを解放するために可能である。
【００６７】
先に述べたように、フィードバック制御エンティティは、マルチキャストサービスまたはブロードキャストサービスを受信する移動端末に対して端末識別子を割り当てる。本発明の実施の形態では、サービスは、マルチキャストサービスであり、移動端末は、フィードバック制御エンティティから端末識別子を受信する。例えば、端末識別子は、マルチキャストサービスのサービスに参加する手順、例えばマルチキャストサービスセッションに参加する手順において移動端末によって受信される。
【００６８】
本発明の更なる実施の形態では、セッションプロトコルにより構成されるフィードバックを供給するようにフィードバック制御データが指示するか否かを判断するために、移動端末は、受信したフィードバック制御データが端末識別子を示すか否かを判断し、示す場合にはセッションプロトコルにより構成されるフィードバックを供給する。
【００６９】
本発明の別の実施の形態では、フィードバック制御データ、およびマルチキャストサービスデータまたはブロードキャストサービスデータとは、ＦＬＵＴＥプロトコルに従ってダウンロードセッション内で供給される。本実施の形態は、例えばダウンロードされたマルチキャストサービスまたはブロードキャストサービスを供給する場合に適している。
【００７０】
更に、本発明の実施の形態は、マルチキャストサービスまたはブロードキャストサービスがＲＴＰプロトコルを用いて供給され、フィードバックがＲＴＣＰプロトコルを用いて供給され、マルチキャストサービスまたはブロードキャストサービスを供給するセッションに対する利用可能な帯域幅の一部がＲＴＣＰプロトコルメッセージに割り当てられている。本実施の形態の変形例では、セッションプロトコルにより構成されるフィードバックは、ＲＴＣＰプロトコルの受信器レポートの形態で供給される。本発明の本実施の形態は、ストリーミングサービスを提供する場合に特に適している。
【００７１】
本発明の別の実施の形態によると、フィードバック制御データは更に、ＲＴＣＰプロトコルを用いてセッションプロトコルにより構成されるフィードバックを供給するための、レポート時間間隔および利用可能な帯域幅を示す。これにより、セッションプロトコルにより構成されるフィードバックを供給するためのフィードバック制御データが、フィードバック制御エンティティによって再構成される。
【００７２】
別の実施の形態では、フィードバック制御データは、フィードバック制御エンティティによって送信されるＲＴＣＰプロトコルの送信側レポートメッセージ内に含まれる。
【００７３】
別の実施の形態では、移動端末のＩＭＳＩが端末識別子として使用される。これにより、本発明の上記実施の形態で説明したように可能な追加の端末識別子を定める代わりに、フィードバック制御エンティティは、例えばマルチキャストサービスまたはブロードキャストサービスの状態情報内で既に利用可能な識別子を使用してもよい。
【００７４】
サービス参加者のプライバシを確保するために、フィードバック制御データは、暗号化された形態の情報を備える。例えば、データによって示されるＩＭＳＩは暗号化された形式のデータによって示される。
【００７５】
更に、本発明の別の実施の形態によると、移動体通信システムのエアインタフェースを介して、フィードバック制御エンティティによって送信または転送されるマルチキャストサービスまたはブロードキャストサービスを受信する、複数の移動端末のフィードバックの送信を制御するフィードバック制御エンティティが提供される。フィードバック制御エンティティは、一方向ダウンリンクチャネルを介して、マルチキャストサービスまたはブロードキャストサービスのデータを送信または転送する送信器を備える。これにより、少なくとも１つの移動端末に対する低信頼転送プロトコルと、マルチキャストサービスまたはブロードキャストサービスを受信する端末のフィードバック供給を構成するセッションプロトコルとが使用される。
【００７６】
フィードバック制御エンティティは更に、複数の移動端末の中から、フィードバック制御エンティティに対してセッションプロトコルにより構成されるフィードバックを供給するためのマルチキャストサービスまたはブロードキャストサービスを受信する複数の移動端末を決定し、決定した複数の移動端末を識別するフィードバック制御データを決定するプロセッサを備える。送信器は、決定した複数の移動端末のうちの少なくとも１つの移動端末にフィードバック制御データを送信するように適合されている。
【００７７】
更に、フィードバック制御エンティティは、決定した複数の移動端末のうちの少なくとも１つの移動端末からセッションプロトコルにより構成されるフィードバックを受信する受信器を備える。
【００７８】
本発明の別の実施の形態では、フィードバック制御エンティティは、上記フィードバック制御方法の各種実施の形態の１つにおけるフィードバック制御エンティティによって実行されるステップを実行するように適合された手段を更に備える。
【００７９】
本発明の別の実施の形態は、フィードバック制御エンティティによって送信または転送されるマルチキャストサービスまたはブロードキャストサービスを、移動体通信システムのエアインタフェースを介して受信する移動端末を提供する。移動端末は、一方向ダウンリンクチャネルを介して、マルチキャストサービスまたはブロードキャストサービスを受信する受信器を備えてもよい。更に、低信頼転送プロトコルと、マルチキャストサービスまたはブロードキャストサービスを受信する端末のフィードバック供給を構成するセッションプロトコルとが使用されてもよい。
【００８０】
受信器は、移動端末がフィードバック制御エンティティにセッションプロトコルにより構成されるフィードバックを供給するように指示されたか否かを示すフィードバック制御データを受信するように適合され、移動端末は、フィードバック制御データがセッションプロトコルにより構成されるフィードバックを供給することを指示する場合に、フィードバック制御エンティティにフィードバックを供給するためのベアラを確立するプロセッサを更に備える。
【００８１】
更に、移動端末は、確立したベアラを介して、フィードバック制御エンティティに、マルチキャストサービスまたはブロードキャストサービスの受信統計を示す、セッションプロトコルにより構成されるフィードバックを送信する送信器を更に備える。
【００８２】
本発明の別の実施の形態では、移動端末は、上記フィードバック制御方法の各種実施の形態の１つにおける移動端末によって実行されるステップを実行するように適合された手段を更に備える。
【００８３】
更に、本発明の一実施の形態は、上記フィードバック制御エンティティと、エアインタフェースを介してフィードバック制御エンティティからマルチキャストサービスまたはブロードキャストサービスを受信する上記少なくとも１つの移動端末とを備える移動体通信システムに関する。
【００８４】
本発明の更なる実施の形態は、フィードバック制御エンティティのプロセッサによって実行されると、一方向ダウンリンクチャネルを介して、少なくとも１つの移動端末に対する低信頼転送プロトコルと、マルチキャストサービスまたはブロードキャストサービスを受信する端末のフィードバック供給を構成するセッションプロトコルとを使用して、マルチキャストサービスまたはブロードキャストサービスのデータを送信または転送し、複数の移動端末の中から、フィードバック制御エンティティに対してプロトコルにより構成されるフィードバックを供給するためのマルチキャストサービスまたはブロードキャストサービスを受信する複数の移動端末を決定し、決定した複数の移動端末を識別するフィードバック制御データを決定し、決定した複数の移動端末のうちの少なくとも１つの移動端末から、セッションプロトコルにより構成されるフィードバックを受信することにより、フィードバック制御エンティティによって送信または転送されるマルチキャストサービスまたはブロードキャストサービスを、移動体通信システムのエアインタフェースを介して受信する移動端末のフィードバックの送信を、プロセッサに制御させる命令を記憶するコンピュータ読み取り可能媒体を提供する。
【００８５】
更なる実施の形態では、コンピュータ読み取り可能媒体は、フィードバック制御エンティティのプロセッサによって実行されると、プロセッサに上記したフィードバック制御方法の各種実施の形態の１つにおいてフィードバック制御エンティティによって実行されるステップを実行させる命令を記憶する。
【００８６】
更に、本発明の別の実施の形態は、移動端末のプロセッサによって実行されると、一方向ダウンリンクチャネルを介して、低信頼転送プロトコルと、マルチキャストサービスまたはブロードキャストサービス受信する端末のフィードバック供給を構成するセッションプロトコルとを使用して、マルチキャストサービスまたはブロードキャストサービスを受信し、セッションプロトコルにより構成されるフィードバックをフィードバック制御エンティティに供給するように移動端末が指示されたか否かを示すフィードバック制御データを受信し、フィードバック制御データがセッションプロトコルにより構成されるフィードバックを供給することを指示する場合に、フィードバック制御エンティティにフィードバックを供給するためのベアラを確立し、確立したベアラを介して、フィードバック制御エンティティに、マルチキャストサービスまたはブロードキャストサービスの受信統計を示す、セッションプロトコルにより構成されるフィードバックを送信することにより、フィードバック制御エンティティによって送信または転送されるマルチキャストサービスまたはブロードキャストサービスを移動体通信システムのエアインタフェースを介して受信する移動端末のフィードバックの送信を、プロセッサに制御させる命令を記憶するコンピュータ読み取り可能媒体を提供する。
【００８７】
別の実施の形態では、コンピュータ読み取り可能媒体は、移動端末によって実行されるとプロセッサに上記したフィードバック制御方法の各種実施の形態の１つにおいて移動端末によって実行されるステップを実行させる命令を更に記憶する。
【発明を実施するための最良の形態】
【００８８】
以下では、本発明を添付の図面を参照してより詳細に説明する。図中における同様のまたは対応する構成要素には同様の参照番号が付与される。
【００８９】
以下の段落は、本発明の様々な実施の形態を説明する。例示のみを目的として、多くの実施の形態は、ＵＭＴＳ通信システムに関連して概要が説明され、後続する項目で使用される用語は、ＵＭＴＳ用語に主に関連する。しかし、ＵＭＴＳアーキテクチャについて使用される用語および実施の形態の説明は、本発明の原理および思想をこのようなシステムに限定するものとして理解されないことは明らかであろう。
【００９０】
上述の背景技術の分野の項目に示した詳細な説明は、以下に説明する主にＵＭＴＳ特有の例示的な実施の形態をより理解するためのものに過ぎず、説明する移動体通信ネットワークにおける処理および機能の特定の実装に本発明を限定するものとして理解されてはならない。
【００９１】
後続する項目で概要を説明する思想および原理は、一方向ダウンリンクを用いるエアインタフェースとデータ配送のための低信頼転送プロトコルを介して移動端末で受信されるマルチキャストサービスまたはブロードキャストサービスにも適応可能である。更に、受信端末から、送信元、例えばフィードバック制御エンティティへのフィードバックの供給を可能にするプロトコルが使用される。上述のシナリオでは、フィードバックが一方向であるため、フィードバックは、サービスデータが受信されるチャネルを介して供給されないことに留意されたい。
【００９２】
本発明の重要な態様の１つは、受信したマルチキャストサービスまたはブロードキャストサービスに対するフィードバックを供給すべき移動端末の決定的選択にある。これは、例えば、フィードバック制御エンティティから所望のレポート受信器を明確にアドレス指定することで実現される。
【００９３】
これに関連して、エンドツーエンドコンセプトがマルチキャストサービスまたはブロードキャストサービスの基礎となっていること、つまりエンドポイント間で交換される情報があらゆる中間ノードに対して透過的であることが重要である。これは、特定のレイヤ内で伝送される情報をカプセル化する階層化アーキテクチャに従って利用されるプロトコルによって反映される。あるレイヤでの情報は最初、他のレイヤからは不可視である。隣接するレイヤだけが明確なサービスとサービスアクセスポイント上で情報を交換することができる。マルチキャストサービスまたはブロードキャストサービスの送信された情報が送信元および受信元、即ちフィードバック制御エンティティおよび受信器にだけ可視であるため、中間ノードは、使用される送信プロトコルより下位のレイヤのプロトコルだけをサポートする。
【００９４】
マルチキャストサービスまたはブロードキャストサービスを受信する端末のサブセットを決定的に選択してフィードバックを供給するといった考えは、エンドツーエンドコンセプトを維持し、利用するプロトコルの階層化アーキテクチャを壊さない。
【００９５】
反対に、ＵＴＲＡＮまたはＣＮの中間ノードにおいてフィードバックを生成すると、これらのコンセプトを壊し、互換性のないようにプロトコルを変更し、中間ノードを拡張して不適切な機能を実行することを必要とする。これらいずれか一方の前提は、マルチキャストサービスまたはブロードキャストサービスを供給するアーキテクチャが幅広く定められている場合には実現可能でない。
【００９６】
本発明の別の実施の形態は、フィードバックを供給するＵＥの決定的な選択を用いて、ＭＢＭＳサービスに対する構成可能且つ適応可能なフィードバック解決策を提供するといった考えに基づく。以下に本実施の形態をより詳細に説明する。
【００９７】
ＭＢＭＳストリーミングサービスは、典型的には、ストリーミングメディアを配送するためのＲＴＰプロトコルを用いる。ＲＴＰセッションフィードバックを収集し、セッションのルース制御を提供するために、対になる（ｃｏｍｐａｎｉｏｎ）ＲＴＣＰプロトコルを用いてもよい。ＲＴＣＰフィードバックは、進行中のＲＴＰマルチキャストセッションに関する統計を収集するために使用されてもよい。基礎となる、低信頼転送プロトコルとしてＵＤＰが想定される。更に、ＲＴＰセッションのセットアップ中、フィードバックを供給するためのパラメータが、サービスに参加しているＵＥに供給されることが重要である。サービスに参加しているＵＥは、示されるパラメータに応じてフィードバック供給を構成する。
【００９８】
参加している移動端末（ＭＴ）の数を推定するためにＲＴＣＰ  ＲＲを用いる標準ＲＴＰアルゴリズムの代わりに、本発明の本実施の形態で提案されるスキームは、ＭＢＭＳシグナリングおよび／またはＭＢＭＳ状態情報を用いて、セッション中におけるＭＴ／ＵＥの正確な数を判断する。この手法によれば、全ての参加者が残りの参加者から全てのメッセージを受信し、マルチキャスト／ブロードキャストおよび消費オーバーヘッドを排除するので、受信器毎にフィードバックチャネルを設ける必要性を回避することができる。
【００９９】
ＭＢＭＳダウンロードサービスを考えると、受信器にデータを送信するためにＦＬＵＴＥプロトコルが使用されてもよい。データ配送には、低信頼転送プロトコルを使用することが想定でき、例えば、ＵＤＰを典型的に使用することができる。このようなＦＬＵＴＥセッションのコンテンツは、ＦＬＵＴＥセッション内に所謂ＦＤＴインスタンスで送信されるファイル配達テーブル（ＦＤＴ）に記述される。ＦＤＴインスタンスは、セッション中にいつでも送信され、繰り返される。ＦＬＵＴＥセッション中、フィードバックを提供するためのパラメータは、示されるフィードバック制御データに応じてフィードバック供給を構成するＵＥに、ＦＤＴインスタンスにおいて供給できることが重要である。
【０１００】
一般的に、ＭＢＭＳ規格では、特定のＭＢＭＳベアラサービスを記述するＭＢＭＳベアラコンテキストと、特定のＭＢＭＳベアラサービスに関するＵＥ特有の情報を有するＭＢＭＳ  ＵＥコンテキストとの２種類の状態情報が存在することに留意されたい。これら双方のコンテキストは、ＲＡＮ、ＳＧＳＮ、ＧＧＳＮ、ＢＭ−ＳＣで作成され得る。ＵＥコンテキストは、サービスを受信するＵＥのそれぞれに対して作成される。現在では、ＧＧＳＮ中のベアラコンテキストは、サービスを受信するＵＥの数を含む。
【０１０１】
しかし、他のＲＡＮまたはＣＮノードがコンテキスト内でサービスの状態情報を記憶することも当然のことながら可能である。これによれば、作成されるコンテキストの数を数えることによって（即ち、各ＵＥはネットワークノードに独自のＵＥコンテキストを有する）、またはサービス参加者の合計を示すコンテキスト内の領域よって、サービスに参加するＵＥの数が決定される。
【０１０２】
サービス供給に対して、即ち参加者の数に対してＭＢＭＳアーキテクチャを用いる場合、ＢＭ−ＳＣのＵＥコンテキストを数えることができ、あるいはＧＧＳＮが、ベアラコンテキストのそれぞれの領域値をシグナリングする参加者の合計を、ＢＭ−ＳＣ（本実施の形態ではフィードバック制御エンティティとして動作する）に提供することができる。
【０１０３】
アドレス指定されるＵＥがシグナリングを受信した場合、ＵＥは、フィードバックチャネルをセットアップし、ＢＭ−ＳＣにレポートを送る。レポートの種類および範囲は、特定のＭＢＭＳユーザサービス、例えばダウンロードサービスまたはストリーミングサービスに依存し、何らかのプロファイル情報によって決定される、特定のシグナリングに依存する。これは、本発明の範囲外であるため、本願では具体的に説明しない。
【０１０４】
概要を上述したとおり、例えば、コンテキストで保持されるマルチキャストサービスまたはブロードキャストサービスに関する状態情報は、ＭＢＭＳユーザサービスにおける参加受信器の個々の識別子を決定するために使用してもよい。特に、ＢＭ−ＳＣでも作成されるＭＢＭＳ  ＵＥコンテキストは、サービスに参加している個々の端末を識別するために使用される特定のユーザを識別する国際移動電話加入者識別番号（ＩＭＳＩ）を含む。
【０１０５】
ＩＭＳＩは、移動国コード（ＭＣＣ）と、移動ネットワークコード（ＭＮＣ）と、移動端末識別番号（ＭＳＩＮ）とからなる。ＭＣＣは、国を一意に識別する三桁の数字であり、ＭＮＣは、特定の国からのネットワークを一意に識別するために用いられる二桁または三桁の数字である。ＭＳＩＮは、ネットワークからの移動体または登録を一意に識別し、最大で十桁よりなる。合計すると、ＩＭＳＩは１５桁（０−９）を超えることはないので、５０ビットの整数値により表される。シグナリングメッセージで使用される識別子の実際の長さは、選択される表示と、識別子の符号化に依存する。例えば、ＩＭＳＩは、結果として２４０ビットを用いるユニコード符号化を用いる文字列として表すことができる。
【０１０６】
サービスに参加している端末の識別子と、サービスの参加者の合計数を知っているとして、ＢＭ−ＳＣは、フィードバックをレポートするＵＥとして構成される受信器の明確なサブセットを選択してもよい。このサブセットは、手動で構成されてもよく、あるいはサービスに参加するＵＥの特定の割合が常にレポート受信器として構成される何らかの自動選択処理に基づいてもよい。これらのＵＥに対応するメッセージを送信することにより、ＢＭ−ＳＣは、セッションプロトコル、例えばＲＴＰ／ＲＴＣＰによってセットアップとしてフィードバック供給の開始（または停止）を指示してもよい。メッセージは、フィードバック供給を開始（または停止）するように指示される１つ以上の個々のＵＥをとりわけ識別するフィードバック制御データを有してもよい。
【０１０７】
本発明の更なる実施の形態では、構成可能なＵＥの動作が２種類ある。第１は、フィードバックを送るようにＵＥを構成することであり、第２は、フィードバックを供給するＵＥにフィードバックを送るのを停止させることである。
【０１０８】
ＵＥの動作は、例えば、動作フラグ（Ｏ）を用いて制御される。フィードバック制御データにおける動作フラグが設定（例えば、Ｏ＝１）されると、それぞれのＵＥは、フィードバック供給を開始する。これは、ＵＥがフィードバックベアラを確立してフィードバックを送ることを示している。フラグが設定されていない場合（例えば、Ｏ＝０）、ＵＥはフィードバックのレポートを停止して、確立したフィードバックベアラが壊される。
【０１０９】
図３は、単一の受信器を構成するためのフィードバック制御データを備える例示的なメッセージ形式を示す。このメッセージは、要求される動作モードを示すフラグと、フィードバック制御エンティティにフィードバックを供給するように指示される受信器を識別するＩＭＳＩとを含む。更に、メッセージ形式（予約領域）中の数ビットは、将来的なシグナリング選択のために予約されてもよい。
【０１１０】
ＭＢＭＳ転送ベアラの信頼性がないので、フィードバック制御エンティティによって送信される構成メッセージは失われる可能性がある。本発明の更なる実施の形態によると、フィードバック制御エンティティは、構成されるべき各受信器に対して内部タイマＴを設定することでこのような状況に対処する。Ｔの値は、それぞれのＵＥがフィードバックベアラをセットアップ（または壊す）に十分な時間を有するように選択することができる。
【０１１１】
受信器がタイムスパンＴ内でシグナリングされた指示に従わない場合、フィードバック制御エンティティは、最後の構成メッセージが失われたと推測する。この場合、フィードバック制御エンティティは、構成メッセージを再び（再）送信する。
【０１１２】
フィードバック制御エンティティは、ＵＥがＭＢＭＳユーザサービスを出る、またはフィードバック制御エンティティのサービスエリアを出ることにより、もはや届くことができないといった状況に対処しなくてもよい。これらの場合は、ＭＢＭＳアーキテクチャ内で扱われ、特定のユーザのＭＢＭＳ  ＵＥコンテキストの排除につながる。したがって、１つ以上のＵＥにフィードバックを供給するように指示する構成メッセージが失われると、フィードバック制御エンティティは、ＵＥに対するＭＢＭＳ  ＵＥコンテキストがまだ有効であり、再びシグナリングを送るか繰り返すことを確認する。
【０１１３】
本発明の別の実施の形態では、ＭＢＭＳの範囲が多数のユーザに対してデータを分配することを考える。フィードバックを供給するようにユーザの小さいサブセットだけを選択することでも大多数のＵＥを構成しなくてはならない。したがって、効率的なシグナリングを可能にし、これに伴うオーバーヘッドをできる限り小さくすることが望ましい。更に、同じ受信器の動作（レポートするまたはレポートしない）は、大部分のＵＥによって要求される可能性も高い。
【０１１４】
ＵＥがデフォルトでフィードバックを供給しないように構成される場合には、フィードバックを供給するようにフィードバック制御エンティティによって選択されたＵＥに対してフィードバックを供給するように指示する必要があることに留意されたい。デフォルトで端末でのフィードバック供給が可能な場合には、フィードバック制御エンティティは、サービス内の幾つかのＵＥに対して、フィードバックを供給しないようにシグナリングする必要が生ずる場合もある。
【０１１５】
したがって、個々のメッセージによって個々の端末をアドレス指定する代わりに、要求された動作モードに応じて受信器をグループ化することが有利である。グループシグナリングに対する様々な例示的な選択を以下に説明する。
【０１１６】
本発明の一実施の形態によると、要求された動作モードによる全てのＩＭＳＩがグループ化され、それにより、個々のＩＭＳＩそれぞれに対して要求された動作モードを特定する必要性が排除される。
【０１１７】
図４は、グループシグナリングの変形例による可能なフィードバック制御データの形式を示す。フィードバック制御データ形式は、動作フラグＯと、続いて現在のグループに属しているＩＭＳＩの数を示すカウント領域（ｃｏｕｎｔ）とからなる。この領域に続いて、フィードバックのレポートを開始／停止すべきＵＥの個々のＩＭＳＩが列挙される。
【０１１８】
当然のことながら、追加的なカウント領域には数ビット必要である。したがって、このメッセージ形式を用いることは、グループ化されたＩＭＳＩの数がカウント領域に必要なスペースを超える場合に特に適している。
【０１１９】
本発明の別の実施の形態は、構成メッセージにおける端末識別子の範囲をシグナリングすることを予想する。一定の範囲の端末識別子（即ち、ＩＭＳＩ）と関連付けられる全てのＵＥが、フィードバック供給を開始／停止することを指示される。
【０１２０】
本実施の形態におけるフィードバック制御エンティティであるＢＭ−ＳＣは、個々のＵＥの全ての端末識別子（例えば、ＩＭＳＩ）を認識している。したがって、ＢＭ−ＳＣは、正確な既知の数のＵＥを備える２つのＩＭＳＩ（間隔の始まりと終わり）を特定することで間隔を決定することができる。端末識別子の範囲を含むメッセージを受信すると、構成メッセージを受信する全てのＵＥが、それぞれの個々の端末識別子がその範囲内にあるか否かを確認する。範囲内にある場合、ＵＥは、要求された動作、即ちフィードバックベアラを確立もしくは壊し、またはフィードバック供給を開始もしくは停止する。
【０１２１】
図５は、本実施の形態によるフィードバック制御データの形式を示す。最適な場合では、フィードバック制御エンティティによって動作モードを指示される必要のある全ての所望のＵＥは、２つのＩＭＳＩを特定することによりアドレス指定される。
【０１２２】
本発明の更なる実施の形態によると、特定の受信器のグループを定める別の可能性として受信器にシグナリングされるＩＭＳＩパターンを特定することが挙げられる。このパターンは、部分的に限定されたＩＭＳＩ、例えば最初の十桁だけによって表され、残りの数字を未知数としてもよい。
【０１２３】
ＢＭ−ＳＣが受信器の全ての個々のＩＭＳＩを認識しているので、正確に受信器の所望のサブセットが含まれるようなパターンを計算することが可能である。このようなシグナリングメッセージを受信した際、受信器は、ＩＭＳＩパターンの特定された部分がそれらの個々のＩＭＳＩと適合するか否かを確認する。適合する場合、要求された動作が実行される、即ちフィードバックベアラが確立され、または壊される。図６では、この選択によるメッセージが示される。全ての所望の受信器は、単一のＩＭＳＩパターンを特定することでアドレス指定されてもよく、それにより、上述の範囲のシグナリング選択よりもオーバーヘッドを軽減することができる。
【０１２４】
上述したシグナリング選択およびそのフィードバック制御データの形式は、利点と欠点を有する。図４に示すグループシグナリング選択に関しては、個々の受信器がアドレス指定されなくてはならない場合に柔軟であるといった利点がある。このスキームの欠点としては、特に、構成されるグループが大きい場合であっても、個々のＩＭＳＩ全てが常に特定されなくてはならない点である。反対に、図５および図６にそれぞれ示す範囲シグナリング選択およびパターンシグナリング選択では、状況が反対になる。構成されるグループが大きい場合には極めて効率的であるが、アドレス指定されるべき全てのＵＥに到達するために幾つかのメッセージを送らなくてはならない場合には非効率的である。
【０１２５】
本発明の別の実施の形態は、追加的なモード領域（Ｍ）を導入することにより上述の２つのシグナリング選択を組み合わせることに関する。この領域により、グループシグナリング、範囲シグナリング、パターンシグナリングの選択のいずれかが使用される。この組み合わせを通じて、個々の選択の欠点が克服され、利点だけを得ることができる。
【０１２６】
図７は、本スキームによる例示的なフィードバック制御データの形式を示す。グループシグナリング選択が使用されているとモード領域が示す場合（例えば、Ｍ＝００）、ｃｎｔ／ｒｅｓ領域は、一緒にグループ化されたＩＭＳＩの数と、後続して余ったＩＭＳＩの数を示す。範囲シグナリング選択が使用されているとモード領域が示す場合（例えば、Ｍ＝１０）、ＩＭＳＩ  ＡおよびＩＭＳＩ  Ｂは、ＩＭＳＩ間隔を特定し、ｃｎｔ／ｒｅｓ領域は無視される。最後に、パターンシグナリング選択が使用されているとモード領域が示す場合（例えば、Ｍ＝１１）、ＩＭＳＩパターンは余りに続き、ｃｎｔ／ｒｅｓ領域は無視される。
【０１２７】
状況に応じて適切なモードが選択される。アドレス指定されるべき個々の受信器が存在する場合、グループモードを選択することで利点を最も得ることができる。構成されるグループが大きい場合には、範囲モードまたはパターンモードが最適な選択となる。後者のモードのどちらが最適であるかは、ＢＭ−ＳＣによって適切な範囲またはパターンを計算することがどれだけ簡単であるかに依存し、それにより所望の受信器が正確にグループ化される。
【０１２８】
本発明の更に別の実施の形態は、ＵＥへのフィードバック制御データの転送に関する。ＭＢＭＳユーザサービスに対して使用される配送方法に依存して受信器にフィードバック制御データを送信するために、異なるプロトコル、つまり異なるメッセージ形式が利用される。したがって、先に説明したフィードバック制御データの形式は、使用される転送プロトコルおよびシグナリングプロトコルにマッピングされなくてはならず、それにより、既存のメッセージ形式への拡張あるいは新しいメッセージの規定といった、スキームへのある程度の適合が必要となる。
【０１２９】
本発明の一実施の形態によると、受信器の構成に使用されるフィードバック制御データ、即ちＵＥにフィードバックを供給させ、または供給させないといった指示は、ＲＴＣＰ送信側レポートブロックを利用する受信器に転送される。この目的のために、幾つかの選択が利用可能である。
【０１３０】
第１の可能性は、図８に示すようなＲＴＣＰ規格に従うアプリケーションで定義されるパケット（ＡＰＰパケット）を用いることである。一般的に、ＡＰＰパケットは、新しいアプリケーションとしての実験的な使用を意図したものであり、パケットタイプ値の登録を必要とすることなく新しい特徴が発展される。
【０１３１】
図８では、非特許文献７において、Ｖ、Ｐ、サブタイプ（ｓｕｂｔｙｐｅ）、ＰＴ、長さ（ｌｅｎｇｔｈ）、ＳＳＲＣの領域が定義されている。名前領域は、例えば「ＭＢＭＳ」に設定されてもよいが、最大で４オクテットよりなるあらゆる他の名前が代わりに使用されてもよい。更に、アプリケーション依存データが前述の領域に添付されてもよい。
【０１３２】
これらのアプリケーション依存データは、図３、４、５、６、７を参照して概要を説明した異なる形式に応じたフィードバック制御データでもよい。
【０１３３】
本発明の更なる実施の形態は、新しく定められた拡張された受信器レポートブロック（ＸＲレポートブロック）を用いて必要なパラメータを送信することを想定する。図９は、図７によって形式化されたフィードバック制御データを備える本発明の例示的な実施の形態によるＸＲレポートブロックを示す。非特許文献８（http://www.ietf.orgで入手可能なＲＦＣ  ３６１１参照）では、拡張された能力でアドホック（ａｄ−ｈｏｃ）ＲＴＣＰレポートブロックを規定するフレームワークを特定する。本実施の形態によると、このようなブロックは、上述したとおり、レポート情報（例えば、レポートの間隔等）を伝送するように規定されてもよい。
【０１３４】
図９に示すＸＲレポートブロックでは、非特許文献９において、Ｖ、Ｐ、予約（ｒｅｓｅｒｖｅｄ）、ＰＴ、長さ、ＳＳＲＣの領域が定義されている。同様に、非特許文献１０において、ＢＴ、予約（タイプ特定情報に対する）、ブロック長さの領域が定義されている。領域ＢＴ（ブロックタイプ）は、範囲（８，２５５）において未使用の値をとる。値０−７は、既に使用されている。これらの領域に続いてフィードバック制御データが添付されてもよい。
【０１３５】
上述したように、この選択は、ＡＰＰレポートブロックを使用する際、アプリケーションレイヤの代わりにＲＴＰプロトコルにおいて論理を直接的に実行する可能性を含むといった利点を有する。本発明の本実施の形態によって提案される解決策は、ＲＦＣ３６１１あるいは本願で定義するように利用可能な拡張されたレポートを使用し、または提供することができるといった更なる利点を有する。
【０１３６】
本発明の更なる実施の形態では、ＲＴＰヘッダにおけるプロファイル特定拡張子、アドホックレポートブロック、またはＲＴＣＰに対するプロファイル特定拡張子等の方法を、移動端末がフィードバックを供給するか否かを決定することを可能にするためのパラメータを伝送するために使用することが提案される。
【０１３７】
別の実施の形態では、フィードバック制御データおよびサービスデータの転送のために、ＦＬＵＴＥプロトコルが使用されてもよい。ＦＬＵＴＥプロトコルは、ＭＢＭＳアーキテクチャに対して特定されるダウンロードサービスにおけるデータ伝送に対して使用することができる。マルチメディアコンテンツを含む任意のファイルがＦＬＵＴＥを用いて送信され、後で取り出すために端末で記憶される。
【０１３８】
ＦＬＵＴＥの基本要素は、ファイル配送セッション（ＦＬＵＴＥセッション）の完全なコンテンツを記述するために使用されるファイル配達テーブル（ＦＤＴ）である。このようなセッションは、全ての受信器に配送されるべき多数のファイルからなる。各ファイルは、ＦＤＴにおける別個のエントリとして表され、ＦＬＵＴＥセッションにおけるファイルの送信に対して要求されたパラメータを記述する。ＦＤＴ自体は、ＦＤＴインスタンスとしてＦＬＵＴＥセッション（帯域内）で配送されるので、送信されたファイルと同様にして扱われる。ＦＤＴインスタンスは、パラメータがＦＤＴ  ＸＭＬスキーマに従うＸＭＬ構造である。
【０１３９】
ＲＴＰ／ＲＴＣＰプロトコルと比べて、サーバが前もって完全なセッションをコンパイルするので、ＦＬＵＴＥセッションにおいて送信されるコンテンツまたは情報を動的に変更または適合する特有の方法はない。ＦＬＵＴＥセッションの唯一の動的要素はＦＤＴインスタンスであり、このＦＤＴインスタンスは、送信することができ、特にセッション内でいつでも繰り返すことができる。
【０１４０】
本発明の更なる実施の形態によると、これらのＦＤＴインスタンスは、必要なシグナリングパラメータを伝送するために適切に拡張されてもよい。例えば、以下のＸＭＬスキーマによってＦＤＴインスタンスの定義を拡張することができる。
【０１４１】
<!-- Global type definition -->
<xs:complexType name="RIDsType">
<xs:sequence>
<xs:element name="IMSI" type="xs:string"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributename="Operation"
type="xs:boolean"
use="required"/>
<xs:attributename="Mode"
type="xs:string"
use="required"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
<!-- Element added to the FDT-Instance element definition -->
<xs:element name="RIDs" type="RIDsType" minOccurs="0"
maxOccurs="unbounded"/>
【０１４２】
以下に、拡張されたＦＤＴインスタンスの例を示す。
【０１４３】
<?xml version="1.0" encoding="UTF-8"?>
<FDT-Instance    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:fl=http://www.example.com/flute
xsi:schemaLocation=http://www.example.com/flute-fdt.xsd
Expires="2890842807">
<File ... />
<RIDs Operation=”true” Mode=”group”>
<IMSI>1234567890</IMSI>
<IMSI>5555555555</IMSI>
</RIDs>
</FDT-Instance>
【０１４４】
これは、ＩＭＳＩ「１２３４５６７８９０」および「５５５５５５５５５５」によって識別されるＵＥに対して、フィードバックベアラをセットアップしてレポートを送るようにシグナリングするために使用される。ＩＭＳＩは、本発明の異なる実施の形態において例示目的のみ使用されることに留意されたい。上記例の＜Ｆｉｌｅ＞要素は、通常、ＦＬＵＴＥセッションにおいてファイルを送信するために必要な情報を有する。
【０１４５】
本発明の別の実施の形態は、例えばアナウンスメントチャネルを介してフィードバック制御データを高い信頼性でシグナリングすることに関する。本実施の形態では、フィードバック制御データは、ＳＤＰ属性を用いたセッション記述に含まれる。その典型的な構文定義は、以下のようである。
【０１４６】
attribute        =   "a=RIDs" parameter-list
parameter-list  =   operation-param";" mode-param ";" imsi-param
operation-param =   "operation=" (0 / 1)
mode-param       =   "mode=" ("group" / "range" / "pattern")
imsi-param       =   "imsi=" imsi *("," imsi)
imsi              =   1*15DIGIT
【０１４７】
この場合、シグナリングメッセージの信頼性の高い転送が想定されるので、フィードバック制御エンティティは、選択された受信器のそれぞれに対してタイマＴをスケジューリングすることはできないことに留意されたい。以下では、このような属性の実施例がＩＭＳＩグループをシグナリングすることについて示される。
【０１４８】
a=RIDs operation=1 mode=group imsi=1234567890, 5555555555
【０１４９】
上述のＦＬＵＴＥ  ＦＤＴインスタンスの実施例と同様に、この属性は、それらのＩＭＳＩによって識別されるＵＥに対して、フィードバックベアラをセットアップしてレポートを送るようにシグナリングするために使用される。
【０１５０】
上述のセクションから分かるように、フィードバック制御データを伝送するために低信頼転送メカニズムが使用される場合、転送中にフィードバック制御データが失われる可能性がある。これは、特に、ＲＴＰパケットまたはＦＬＵＴＥパケットが低信頼ＵＤＰプロトコル上で伝送される場合に生ずる。ＵＤＰは、信頼性のないデータグラムサービスを提供する転送プロトコルである。それは、典型的には、ＲＴＰパケットでストリーミングメディア（ＭＰＥＧ４等）をユニキャスト／マルチキャストするために使用される。対応するＲＴＣＰパケットもまた、ＵＤＰ上で転送される。
【０１５１】
ＢＭ−ＳＣ（本実施の形態ではフィードバック制御エンティティとして機能する）もまた、より信頼性のある方法でこの情報を送ると判断してもよい。上述の実施の形態では、ＢＭ−ＳＣは移動端末に送信されるフィードバック制御データのソースとして考えられていることに留意されたい。しかし、マルチキャストサービスまたはブロードキャストサービス（セッション）のコンテンツを提供するフィードバック制御エンティティが判断し、サービスを受信する移動端末にこれらのデータを伝播してもよい。
【０１５２】
ＭＢＭＳフレームワークでは、より信頼性のある方法でフィードバック制御データを送信する方法がある。端末は、例えばＨＴＴＰサーバに対する一対一接続を用いてＭＢＭＳサービスのセッション記述情報（例えば、ＳＤＰ記述）を取り出し、またはＭＢＭＳセッションに加わる前にこの情報を備えるＳＭＳを受信してもよい。
【０１５３】
図３から図９で概要を説明した例示的な実施の形態では、ＩＭＳＩは、フィードバックを供給するように構成されるべき受信器を識別するために使用される。ＩＭＳＩは、世界的に一意の識別子であり、ユーザの個人情報を含むので、可能であれば公にされない。ＭＢＭＳサービスの全ての受信器にシグナリングメッセージが送信され、他の受信器によるＩＭＳＩの傍受を容易にし得るので、確実にプライバシとセキュリティについての論争を生む。特に、シグナリングがセッションプロトコルレベルにあり、アプリケーションレイヤに近いので、より低いレイヤプロトコルから情報を抽出するよりも傍受が簡単になる。
【０１５４】
特に、個々のＩＭＳＩが列挙されるグループシグナリング選択は、顕著なセキュリティの問題を引き起こす。範囲およびパターンシグナリング選択に関して、潜在的な危険性が低くなる。パターンシグナリング選択は、完全に限定されたＩＭＳＩを用いない。範囲シグナリング選択では、現在存在しないＩＭＳＩだけが範囲を定めるために使用される。
【０１５５】
代替的な解決策では、別の識別子、例えば一時識別子が、ＩＭＳＩ識別子の代わりに使用されてもよい。更なる実施の形態では、ＩＭＳＩの代わりに、シグナリングメッセージにおいて一時識別子を用いることが提案される。この識別子は、それが使用されるＭＢＭＳサービスのコンテキストにおいて少なくとも一意でなくてはならない。
【０１５６】
例えば、３ＧＰＰではＵＥに対して特定される複数の一時識別子がある。既に定義されている候補の１つとして、パケット−一時移動電話加入者識別番号（Ｐ−ＩＭＳＩ）を使用することができる。この識別子は、ＳＧＳＮのルーティングエリア（ＲＡ）内では一意である。しかし、フィードバックがＳＧＳＮによって制御されない場合、ユーザの移動性によりＳＧＳＮが変化し得るので、Ｐ−ＴＭＳＩの使用は実現可能な解決策とならない。
【０１５７】
したがって、本発明の別の実施の形態によると、ＭＢＭＳサービスにおける参加ユーザのそれぞれに対して、フィードバック制御エンティティとして機能するＢＭ−ＳＣにおいて新しい一時識別子が作成される。この識別子は、ＭＢＭＳサービスに加入した際に端末に割り当てられ、ＭＢＭＳ  ＵＥコンテキストに記憶される。ＭＢＭＳサービスからユーザが離脱すると、一時識別子が、ＢＭ−ＳＣにおけるＭＢＭＳ  ＵＥコンテキストと共に削除される。
【０１５８】
本発明の更なる実施の形態による別の可能な解決策は、プレーンテキストでＩＭＳＩを特定する代わりに、暗号化されたＩＭＳＩを使用することである。ＵＥがこのようなシグナリングメッセージを受信すると、ＵＥは含まれる識別子の復号化を試みる。個々のＵＥだけが、自身の暗号化された識別子を確実に復号化することができるようになる。
【０１５９】
ＩＭＳＩを暗号化および復号化するために使用される鍵は、各ＵＥに対して１つである。ＭＢＭＳサービスの多数の傍受により、個々の暗号鍵の割り当てと分配が可能である。したがって、使用される暗号スキームは、ＵＥの個々のＩＭＳＩ、つまりＩＭＳＩ自身とのシグナリングメッセージにおけるＩＭＳＩの暗号化および復号化に基づかなくてはならない。
【０１６０】
暗号化されたＩＭＳＩに対する他の代替例は、ハッシュ関数スキームの使用である。この代替例では、ＢＭ−ＳＣがＩＭＳＩのハッシュ値だけを送るので、各ＵＥに対して暗号鍵を使用する必要がない。ＵＥがこのような要求を受信すると、ＵＥはそのＩＭＳＩからハッシュ値を計算する。ＢＭ−ＳＣから送られるハッシュ値がＵＥで計算される値と一致すると、ＵＥはフィードバックを送る。ハッシュ関数は一方向関数なので、ＵＥは別のＵＥのＩＭＳＩから学習することはできない。本代替例のように、ＩＭＳＩ自体はエアインタフェース上で送られず、説明したセキュリティ脅威が低下する。
【０１６１】
次に、ユーザにマルチキャストサービスまたはブロードキャストサービスを提供し、上述の各実施の形態で概要を説明した本発明を用いる幾つかの可能なシナリオが、図１０、１１、１２を参照して例示目的で説明される。
【０１６２】
図１０では、コンテンツサーバ１００１は、フィードバック制御エンティティ、例えばＢＭ−ＳＣ１００４を介して、マルチキャストセッションまたはブロードキャストセッションを、ＩＰベースのネットワーク上でユーザに提供する。サービスデータを受信する複数のユーザは、ＵＭＴＳネットワーク１００２のような移動体通信ネットワークに位置し、以下ではこの場合を例示目的で説明する。
【０１６３】
本発明の一実施の形態によると、ＵＭＴＳネットワーク１００２内に位置するＢＭ−ＳＣ１００４は上述の通り、サービス受信端末１０１２、１０１３のフィードバックの供給を制御する。ＢＭ−ＳＣ１００４は、コンテンツサーバ１００１からサービスデータを受信し、受信したサービスデータを、ＭＢＭＳセッション内で、例えば、ＣＮ（コアネットワーク）１００３のＧＧＳＮ（ＧＰＲＳゲートウェイサポートノード）１００５およびＳＧＳＮ（サービングＧＰＲＳサポートノード）１００６、少なくとも１つのＲＮＣ１００９、ならびに少なくとも１つのノードＢ１０１０、１０１１を介して、端末１０１２、１０１３に送信する。ＢＭ−ＳＣ１００４は、ＵＭＴＳネットワーク１０１２におけるアナウンスメントチャネルを介してサービスの利用可能性をアナウンスし、ＵＥのサービスへの参加および離脱といったサービスの許可に関連している。本発明の一実施の形態を参照して先に説明したように、サービスのアナウンスは、フィードバック制御に対するフィードバック制御データを含む。
【０１６４】
図１１を参照すると、コンテンツサーバ１１０１が移動体通信システム内に位置する、本発明の例示的な実施の形態が示されている。図１０に示したデータ供給のためのＩＰベースのネットワークの使用が必要でない点を除いて、図１１は、本質的には、図１０を参照して説明した本発明の実施の形態と同一である。
【０１６５】
図１２では、コンテンツサーバ１２０１がマルチキャストサービスまたはブロードキャストサービスのデータのソースである本発明の例示的な実施の形態が示される。本発明の実施の形態では、コンテンツサーバ１２０１は、ＧＧＳＮ１２０５に直接的にサービス関連データストリームを供給する。本実施の形態によると、ＧＧＳＮ１２０５は、サービスを受信する下流側端末のフィードバック供給を制御するネットワークエンティティとすることができる。ＧＧＳＮ１２０５は、ＭＢＭＳベアラコンテキストのようなサービス関連コンテキスト情報に記憶されるそれぞれの情報に基づいて、サービス参加者数を直接的に決定する。
【０１６６】
本発明の更なる実施の形態では、図１０および図１１に示すように、フィードバック制御エンティティ、例えばＢＭ−ＳＣは、マルチキャストサービスプロバイダまたはブロードキャストサービスプロバイダ（コンテンツプロバイダ１００１、１１０１）から、マルチキャストサービスまたはブロードキャストサービスのデータを受信してもよい。
【０１６７】
フィードバック制御エンティティは、マルチキャストサービスプロバイダまたはブロードキャストサービスプロバイダに対して、非透過的なモードで動作してもよい。このモードについて、図１０を参照して以下に説明する。
【０１６８】
この場合、ＢＭ−ＳＣ１００４（即ち、図１０に示す例示的な実施の形態におけるフィードバック制御エンティティ）は、コンテンツプロバイダ１００１（即ち、図１０に示す例示的な実施の形態におけるマルチキャストサービスプロバイダまたはブロードキャストサービスプロバイダ）の観点からマルチキャストサービスまたはブロードキャストサービスを受信するクライアントとして機能する。端末１０１２、１０１３の観点からすると、ＢＭ−ＳＣ１００４は、サービスを提供するマルチキャストサーバまたはブロードキャストサーバとして機能する。
【０１６９】
したがって、コンテンツサーバ１００１から移動端末１０１２、１０１３に対してエンドツーエンドサービスのセッションはないが、サービス供給は２つのエンドツーエンドセッションに分けられる。これら２つのエンドツーエンドセッションの１つは、端末１０１２、１０１３とＢＭ−ＳＣ１００４の間であり、もう１つは、ＢＭ−ＳＣ１００４とコンテンツプロバイダ１００１の間である。
【０１７０】
これら双方のセッションに対して、転送レイヤ、セッションレイヤ等の異なるプロトコルが使用される。例えば、ＢＭ−ＳＣ１００４と端末１０１２、１０１３との間のセッションは、ＲＴＰ／ＵＤＰ／ＩＰ（およびＲＴＣＰフィードバック）を使用し、コンテンツプロバイダ１００１とＢＭ−ＳＣ１００４との間のセッションは、同じプロトコルか異なるプロトコルを使用する。これにより、ＢＭ−ＳＣ１００４は、プロトコル変換メカニズムを提供するゲートウェイのように動作することができる。
【０１７１】
今、コンテンツサーバ１００１とＢＭ−ＳＣ１００４との間のセッションを考えると、ＢＭ−ＳＣ１００４は、コンテンツプロバイダ１００１にフィードバックを供給する。異なるサービス受信端末１０１２、１０１３に対して実現されるＱｏＳ等の受信の統計、およびパケット損失レートを個々の端末１０１２、１０１３等に反映するためには、ＢＭ−ＳＣ１００４は、受信したフィードバックを解析し、移動体通信システム内のサービスの受信の統計を反映している集合値または累積値を作成する。この集合値または累積値は、任意の形態でコンテンツプロバイダ１００１にフィードバックとして供給されてもよい。例えば、ＢＭ−ＳＣ１００４は、集合値または累積値を反映する「標準的な」ＲＴＣＰ受信レポートを生成してもよいし、特別な形態のフィードバック供給が、コンテンツプロバイダ１００１とＢＭ−ＳＣ１００４との間で定められてもよい。
【０１７２】
第２の可能性は、ＢＭ−ＳＣ１００４が、個々のＵＥ１０１２、１０１３の受信したフィードバックをコンテンツプロバイダ１００１に送ることである。この場合でも、ＢＭ−ＳＣ１００４は、フィードバックデータに対して何らかの変換を実行する。これは、更に別のプロトコルが使用され得る、ＢＭ−ＳＣ１００４とコンテンツプロバイダ１００１との間における別個の接続／セッションが存在するからである。
【０１７３】
いずれの場合でも、ＢＭ−ＳＣ１００４からコンテンツプロバイダ１００１へのフィードバック供給は、例えば、達成されたＱｏＳに基づいて受信したサービスに対してユーザが課金される場合に特に実現可能となる。
【０１７４】
更に、本発明の実施の形態では、ＩＭＳＩ以外の識別子が、マルチキャストサービスまたはブロードキャストサービスを受信する個々のＵＥを識別するために使用される。本実施の形態によると、フィードバック制御エンティティは、マルチキャストサービスまたはブロードキャストサービスに興味を示す各ＵＥに対して、ＵＥがサービスを受信する限り有効となる一意の端末識別子を割り当てる。マルチキャストサービスを考えた場合、参加する手順におけるメッセージが、端末識別子を対応するＵＥに伝送するために使用されてもよい。
【０１７５】
更に、フィードバック制御エンティティは、状態情報（例えば、サービスコンテキスト）に端末識別子を記憶してもよい。これにより、フィードバック制御エンティティにフィードバックを供給するように指示される移動端末を決定する際、フィードバック制御エンティティは、フィードバック制御データにおいて対応する端末を識別するために割り当てられた端末識別子を使用してもよい。
【０１７６】
本発明の別の実施の形態は、ハードウェアおよびソフトウェアを用いて上述した各種実施の形態を実行することに関する。上述した各種論理ブロック、モジュール、回路が、演算装置（プロセッサ）、例えば汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブル論理装置等を用いて、実装または実行されてもよいことは認識されるであろう。本発明の各種実施の形態は、これらの装置の組み合わせによって実行あるいは具現化されてもよい。
【０１７７】
更に、本発明の各種実施の形態は、プロセッサによって、またはハードウェアで直接的に実行されるソフトウェアモジュールを用いて実行されてもよい。ソフトウェアモジュールとハードウェア実装の組み合わせも可能である。ソフトウェアモジュールは、例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ等の、あらゆる種類のコンピュータ読み取り可能な記憶媒体に記憶される。
【０１７８】
これに関して、図１３および図１４は、本発明の例示的な実施の形態による移動端末およびフィードバック制御エンティティをそれぞれ示している。
【０１７９】
移動端末はとりわけ、フィードバック制御エンティティから配送されるデータを表示する表示部１３０１と、マルチキャストセッションまたはブロードキャストセッションの受信およびフィードバックの送信を可能にする少なくとも１つの通信インタフェース１３０４とを備える。更に、移動端末は、コンピュータ読み取り可能な記憶媒体１３０３に記憶される命令を実行するためにとりわけ使用されるプロセッサ１３０２（演算装置）を備える。プロセッサ１３０２は、通信インタフェース１３０４を介して通信を制御し、移動端末に、受信したメッセージを解読または作成することを可能にする。
【０１８０】
図１４に示すフィードバック制御エンティティは、プロセッサ１４０１と、コンピュータ読み取り可能な記憶媒体１４０２と、少なくとも１つの通信インタフェース１４０４とを備える。
【０１８１】
フィードバック制御エンティティは、マルチキャストサービスまたはブロードキャストサービスを提供または転送するＵＭＴＳネットワークのＢＭ−ＳＣでもよい。フィードバック制御エンティティは、ユーザへのマルチキャストサービスまたはブロードキャストサービスによって供給されるサービスデータ（例えば、ストリーム）を記憶またはバッファリングするサービスデータベース１４０３を備える。更に、コンピュータ読み取り可能媒体１４０２は、プロセッサ１４０１によって実行可能な命令および更なるデータを記憶してもよい。
【０１８２】
例えば、コンピュータ読み取り可能媒体１４０２に記憶されるデータは、各サービスのコンテキスト情報を含むことができ、このコンテキスト情報は、フィードバック制御エンティティがサービス参加者数を決定する際の基となる。コンピュータ読み取り可能媒体１４０２に記憶される命令は、更に、上述の各種実施の形態で説明したように、フィードバック制御エンティティに、サービス参加者からのフィードバック供給を制御することを可能にさせる。
【図面の簡単な説明】
【０１８３】
【図１】ＲＴＰセッションに加入した受信器の数ｎの関数としての１受信器当たりのレポート帯域幅を示す図
【図２】ＲＴＰセッションに加入した受信器の数ｎの関数としての受信器レポート（ＲＲ）時間間隔Ｔを示す図
【図３】本発明の様々な実施の形態によるフィードバック制御データの形式を示す図
【図４】本発明の様々な実施の形態によるフィードバック制御データの形式を示す図
【図５】本発明の様々な実施の形態によるフィードバック制御データの形式を示す図
【図６】本発明の様々な実施の形態によるフィードバック制御データの形式を示す図
【図７】本発明の様々な実施の形態によるフィードバック制御データの形式を示す図
【図８】本発明の実施の形態によるＲＴＣＰアプリケーション定義パケットで転送されるアプリケーション定義パラメータの形式を示す図
【図９】本発明の実施の形態による拡張されたＲＴＣＰ受信器レポートブロックの形式を示す図
【図１０】本発明の様々な実施の形態によるユーザへのマルチキャストサービスおよびブロードキャストサービスの供給ならびに受信端末のフィードバックの制御に対するシナリオを示す図
【図１１】本発明の様々な実施の形態によるユーザへのマルチキャストサービスおよびブロードキャストサービスの供給ならびに受信端末のフィードバックの制御に対するシナリオを示す図
【図１２】本発明の様々な実施の形態によるユーザへのマルチキャストサービスおよびブロードキャストサービスの供給ならびに受信端末のフィードバックの制御に対するシナリオを示す図
【図１３】本発明の様々な実施の形態による移動端末を示す図
【図１４】本発明の様々な実施の形態によるフィードバック制御エンティティを示す図
【図１】
2008512014.tif 000006
【図２】
2008512014.tif 000007
【図３】
2008512014.tif 000008
【図４】
2008512014.tif 000009
【図５】
2008512014.tif 000010
【図６】
2008512014.tif 000011
【図７】
2008512014.tif 000012
【図８】
2008512014.tif 000013
【図９】
2008512014.tif 000014
【図１０】
2008512014.tif 000015
【図１１】
2008512014.tif 000016
【図１２】
2008512014.tif 000017
【図１３】
2008512014.tif 000018
【図１４】
2008512014.tif 000019
【国際調査報告】
2008512014.tif 000020
2008512014.tif 000021
2008512014.tif 000022