(57)【要約】      （修正有）【課題】マルチキャストサービス又はブロードキャストサービスを受信している各移動端末からのフィードバックの送信を制御する、移動端末により実行される方法を提供する。【解決手段】方法は、ダウンリンクチャネルを介して、低信頼性トランスポートプロトコルを使用してマルチキャストサービス又はブロードキャストサービスを受信するステップと、移動端末がフィードバックを提供するか否かを決定するパラメータを受信するステップと、受信したパラメータに基づいて、マルチキャストサービス又はブロードキャストサービスに対するフィードバックを提供するか否かを決定するステップと、を含む。【選択図】なし【特許請求の範囲】
【請求項１】
マルチキャストサービス又はブロードキャストサービスを受信している各移動端末からのフィードバックの送信を制御する、移動端末により実行される方法であって、
ダウンリンクチャネルを介して、低信頼性トランスポートプロトコルを使用してマルチキャストサービス又はブロードキャストサービスを受信するステップと、
前記移動端末がフィードバックを提供するか否かを決定するパラメータを受信するステップと、
受信したパラメータに基づいて、マルチキャストサービス又はブロードキャストサービスに対するフィードバックを提供するか否かを決定するステップと、
を含む方法。
【請求項２】
前記決定ステップにおいてフィードバックを提供するという決定がなされる場合、フィードバックを提供するベアラを確立するステップと、
前記マルチキャストサービス又はブロードキャストサービスの受信統計値を示すフィードバックを前記確立ベアラを介して送信するステップと、
をさらに含む、請求項１記載の方法。
【請求項３】
マルチキャストサービス又はブロードキャストサービスを受信する移動端末であって、
ダウンリンクチャネルを介して、低信頼性トランスポートプロトコルを使用してマルチキャストサービス又はブロードキャストサービスを受信し、前記移動端末がフィードバックを提供するか否かを決定するパラメータをさらに受信するように適合される受信機と、
受信したパラメータに基づいて、マルチキャストサービス又はブロードキャストサービスに対するフィードバックを提供するか否かを決定するプロセッサと、
を具備する移動端末。
【請求項４】
前記プロセッサにおいてフィードバックを提供するという決定がなされる場合、フィードバックを提供するベアラを確立し、前記マルチキャストサービス又はブロードキャストサービスの受信統計値を示すフィードバックを前記確立ベアラを介して送信する送信機をさらに具備する、請求項３記載の移動端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、フィードバック制御エンティティにより送信又は転送されたマルチキャストサービス又はブロードキャストサービスを移動通信システムのエアインタフェースを介して受信している移動端末からのフィードバックの送信を制御する方法、及びこの方法を使用する移動端末に関する。
【背景技術】
【０００２】
リアルタイムトランスポートプロトコル（ＲＴＰ）（http://www.ietf.orgにて得られる非特許文献１を参照）は、オーディオ、ビデオ又はシミュレーションデータなどのリアルタイムデータの送信に適したエンドツーエンドのネットワーク伝送機能を提供する。ＲＴＰは、リソースの確保には対処しておらず、リアルタイムサービスのサービス品質を保証しない。
【０００３】
大規模なマルチキャストネットワークに拡張可能な方式でデータ配信を監視できるようにするために、また最小限の制御及び識別機能を実現するために、データ伝送は制御プロトコル（ＲＴＣＰ）によって増強されている。ＲＴＰ及びＲＴＣＰは、基本的なトランスポート層及びネットワーク層から独立に設計されている。
【０００４】
３Ｇネットワークにおけるストリーミングサービスのマルチキャスト又はブロードキャストのデータ伝送には、ＲＴＰが使用され得る。前述のとおり、リアルタイム制御プロトコル（ＲＴＣＰ）は、配信されたＲＴＰストリームに関する制御情報を監視し、伝送するための手段を提供する。
【０００５】
標準ＲＴＰ／ＲＴＣＰ
ＲＴＰ（及びそれと併用されるＲＴＣＰ）は、ユニキャスト及びマルチキャストの両方のデータ伝送向けに元来設計された（ＲＴＰ報告）。このため、フィードバック崩壊を防ぐための拡張可能なアルゴリズムとそれに対応したメカニズムが提案されてきた。本文書の以降の部分では、これをそれぞれ「標準的なＲＴＣＰアルゴリズム及びメカニズム」と言う。
【０００６】
ＲＴＣＰの標準的なアルゴリズム及びメカニズムは、各エンドシステムが双方向トランスポートチャネルを介してデータを送受信できるエニーソースマルチキャスト（ＡＳＭ：Any-Source Multicast）モデルを土台に想定して設計された。
【０００７】
従って、参加している各エンドシステムは、ＲＴＰデータを受信するほか、ＲＴＣＰセンダーレポート（ＳＲ）とすべての参加者のレシーバレポート（ＲＲ）とを受信する。すべてのＲＲの受信によって、各エンドシステムはセッションの参加者の数を独自に推定することができ、この値を使って、ＲＴＣＰの標準的なアルゴリズムによる報告時間間隔を計算することができる。さらに、これは、小グループ会議のような用途で役立ち得る、すべての参加者に関する情報を収集する手段を各エンドホストに提供する。
【０００８】
一方向マルチキャストチャネル向けのＲＴＣＰ  ＲＲ
非特許文献２（http//www.ietf.orgにて得られる）で記述されているようなソーススペシフィックマルチキャスト（ＳＳＭ：Source-Specific Multicast）は、http://www.3gpp.orgにて得られる非特許文献３に規定されるような３ＧＰＰ  ＭＢＭＳ構成との併用に特に適する。
【０００９】
ＳＳＭマルチキャストモデルは、ＡＳＭに比べて複雑度が少なく、加入ベースのアクセス制御を可能にする。ＳＳＭでは、各単一のエンドシステムが、一方向マルチキャストトランスポートチャネルを使ってデータの送信を行うことができる。このチャネルに加入した参加者だけがメッセージを受信することになる。
【００１０】
ＡＳＭの場合と異なり、ＲＴＣＰレシーバレポートは、このマルチキャストチャネルを通じて送信することはできない。しかし、各受信機がフィードバックを個別のユニキャストトランスポートチャネルを通じてセンダーに送信し、センダーがこれらのメッセージを、レシーバレポート及びセンダーレポートの帯域幅の指定値に従って、マルチキャストチャネルに反映することによって、ＳＳＭでのこの制約を克服することができる。
【００１１】
ＲＴＣＰのＳＤＰ帯域幅変更子
標準的なＲＴＣＰメカニズムは、全制御トラヒックの帯域幅の比率をＲＴＰセッション帯域幅の５％に定めている。単一のセンダーによる、用途のシナリオの目標では、センダーレポート（ＳＲ）に割り当てられたＲＴＰ帯域幅の比率Ｓは１．２５％であり、レシーバレポート（ＲＲ）のために各エンドシステムによって均等に共有される比率Ｒとしては３．７５％の値が割り当てられる。様々な帯域幅割当ての指定をサポートするために、非特許文献４（http://www.ietf.orgにて得られる）により、セッション記述プロトコル（ＳＤＰ）内でのＲＴＣＰ帯域幅変更子のシグナリングが提案されている。
【００１２】
特定のセッションに対するＳＤＰインスタンスは、二つの追加のパラメータ により拡張することができる。ここで、ｂ＝ＲＳ：＜帯域幅値＞及びｂ＝ＲＲ：＜帯域幅値＞はそれぞれ、全センダーレポート及び全レシーバレポートレートを指定する。ホストごと割当て及び報告時間間隔は、標準的なＲＴＣＰアルゴリズムに従って決定される。
【００１３】
マルチキャストフィードバックの制限
ＩＥＴＦ  ＲＭＴワーキンググループ内で検討されてきた既存の作業は、例えば高信頼性マルチキャスト送信での損失データパケットの否定応答といった冗長フィードバックを抑制するという問題を扱っている。これ以外のマルチキャストの用途は、特定のメトリックに基づく極値を有するエンドシステムのフィードバックを要求する。
【００１４】
これらの方式の目的は、マルチキャストセッション内で能力（帯域幅）が制限されている受信機を見つけることである。そして、このような受信機のフィードバックに対してセンダーは送信レートを調節する。両方の問題に対するエンドツーエンドのソリューションは、通常、フィードバックタイマ又はポーリングメカニズムの様々な変形を使用する。
【００１５】
マルチキャストに参加している受信機の状態情報を集めることについてのフィードバックの制限を扱っている既存の作業はほとんどない。受信機状態情報の収集に基づいたビデオストリーミング用途についての一つの重要なメカニズムが、非特許文献５に提示されている。この提案されたメカニズムの主たる目的は、報告された状態情報に応じてパケットの送信レートを調整することである。
【００１６】
従って、受信機が報告可能な状態のセットは、三つの異なる状態に制限されている。その結果、この手法は、以下の問題があるため、３ＧＰＰ  ＭＢＭＳセッションでの統計値のフィードバックの制限には適用できない。
【００１７】
参加しているエンドシステムの数は、ＲＴＣＰ  ＲＲにより各受信機で捕捉しなければならない。このことは、参加している各移動端末（ＭＴ、ＵＥ）にセンダーへのポイントツーポイントのフィードバックチャネルの確立を要求する。
【００１８】
センダーは、すべてのＲＲを反映又は集約して、この情報を一方向マルチキャストチャネルで転送しなければならない。セルラー及びモバイル環境に照らすと、上記ソリューションの欠点として、次のことが明白にあげられる。
【００１９】
●  フィードバックチャネル（ＭＴ／ＵＥ当り１つ）の確立及び維持のためのコスト
●  反映されたレポートにより生じるマルチキャストチャネルのオーバヘッド
●  状態情報を動的に維持更新しなければならないエンド装置の消費電力オーバヘッド
【００２０】
例えば、各ユーザが例えば個別の拡散コードを有する個別アップリンクチャネルを有することになる場合、ユニキャストフィードバックチャネルはセル内の相当な量のリソースを必要とし得る。この状況は、対応セルにおける呼の遮断（call blocking）やハンドオフの放棄（handoff dropping）の確率の増加を引き起こし得る。
【００２１】
受信機当り帯域幅（per-receiver bandwidth）ｂＲＲは、標準的なアルゴリズムを用いて次のとおりに計算される。
【００２２】
【数１】
2010063129.tif 000002
【００２３】
なお、Ｔｍｉｎは最小時間間隔（例えば、５ｓ）、ＰＲＴＣＰはＲＴＣＰパケットサイズ、ＢＲＲは全レシーバレポート帯域幅（ＲＴＰ帯域幅の３．７５％）、ｎは受信機数である。これにより得られた、グループサイズの関数としての受信機当り帯域幅ｂＲＲを図１に示す。
【００２４】
標準的なＲＴＣＰアルゴリズムにより計算された受信機当り帯域幅
グループダイナミクス（現行のセッション中に受信機はセッションに加わったり退去したりできる）により、実効的な受信機当り帯域幅は先験的に知られるものではなく、著しく変化することもある。現在のグループのサイズに適合するようにフィードバックチャネルを頻繁に再確立することを避けるために、レシーバフィードバックチャネルは、上限まで、すなわち、最悪のケースでは最大ＲＲ帯域幅までリソースを確保して確立されなければならないであろう。その結果、フィードバックチャネル用に確保されたリソースは、非常に非効率に使用され得る。
【００２５】
ＲＴＣＰ  ＲＲ時間間隔Ｔは、標準的なＲＴＰアルゴリズムによって次のとおりに計算される。
【００２６】
【数２】
2010063129.tif 000003
【００２７】
なお、Ｔｍｉｎは最小時間間隔、ｎは受信機数、ＰＲＴＣＰはＲＴＣＰパケットサイズ、ＢＲＲは全レシーバレポート帯域幅である。
【００２８】
図２は、ＲＲ時間間隔Ｔ（上記式により計算された）とＲＴＰセッションに参加している受信機数ｎとの関係を示す。時間間隔は、参加している受信機数とともに直線的に増加する。
【００２９】
この量的な影響を説明するために、６４ｋｂｐｓのデータレートでオーディオビジュアルコンテンツをストリーミングする下記の例を考える。平均ＲＴＣＰ  ＲＲパケットサイズが１２０バイト、ｎ＝１００とすれば、報告時間間隔はＴ１００＝４０ｓと計算される。これは、すなわち、ｎ＝９，０００とすれば、報告時間間隔はＴ９，０００＝３，６００ｓ＝１ｈに達する。
【００３０】
標準的なアルゴリズに従って、各受信機はそれぞれの報告パケットを均等な配分に従って間隔［０．５Ｔ、１．５Ｔ］内で確率論的にスケジューリングする。すなわち、上記の例では、最初の報告パケットは、それぞれ２０ｓ後及び０．５ｈ後に送信するように予定される。明らかに、この結果のＲＲ時間間隔Ｔは実用的には受け入れ難い。
【００３１】
前述のとおり、標準的なＲＴＣＰ手法は、どのエンドシステムでも単一の双方向チャネル上でデータを送受信できかつ損失の可能性の報告を行うようなＡＳＭモデルの特徴に対応するものである。しかし、３ＧＰＰ  ＭＢＭＳサービスでは、上記の間隔は容易にセッションの継続時間を超えることが予想され、報告は無駄になる。
【００３２】
さらに、留意すべき点は、ブロードキャストデータ配信についても、ブロードキャストサービスの受信機からフィードバックを提供すると考えられる（特に、受信コンテンツの品質が課金のために重要となり得るブロードキャストデータ配信にも、コンテンツベースの課金が使用され得るため）。あるサービスを受信することが重要である加入ベースの課金とは対照的である。
【００３３】
前述したＲＴＰ及びＭＢＭＳ特有の問題は、受信端末から送信元、例えば、マルチキャストサーバ又はブロードキャストサーバへのフィードバックの提供を可能にするプロトコルを使用してエアインタフェースを介して移動端末で受信するマルチキャスト又はブロードキャストに一般化して考えられ得る。
【００３４】
特許文献１において、無線ネットワークにおけるマルチユーザサービスの報告の方法が知られている。同文献での概念は、中間ネットワーク部において、エアインタフェースリソースのＲＮＣ知見に基づいて、集約型フィードバックレポートを生成することである。端末からのＲＴＣＰフィードバックは、マルチユーザサービスでは、すなわち、マルチユーザサービスのすべてのユーザで無効にされ得る。変形では、マルチユーザサービスのすべてのユーザは、イベント駆動型フィードバックを提供するようにＲＮＣによって設定され得る。各受信機からのこの情報は、ＲＮＣにおいて、集約型フィードバックを作成するために使用され得る。
【００３５】
特許文献１で提案された方法及びシステムは、マルチユーザサービスの送信元、すなわち、サーバへ送信される集約型フィードバックレポートを生成するために、移動通信システムの無線リソースに関するＲＮＣの知見を使用する。同文献に提案された方法は、複数層（例えばセッション層及び無線リソース制御）間での相互作用及びデータ交換、並びにＲＮＣでの無線リソース管理とデータ通信を行う中間ネットワーク部との間の独自の拡張を必要とする。そのため、エンドツーエンドの概念のマルチユーザサービス提供は犠牲になる。マルチキャストサービス又はブロードキャストサービスを提供するための構成が広範に定められなければならない場合、これらの拡張は実現不可能である。
【先行技術文献】
【特許文献】
【００３６】
【特許文献１】国際公開第２００４／０４０９２８Ａ１号パンフレット
【非特許文献】
【００３７】
【非特許文献１】Schulzrinne et al., "RTP: A Transport Protocol for Real-Time Applications", RFC 3550
【非特許文献２】S. Bhattacharyya, Ed. "An Overview of Source-Specific Multicast (SSM)", RFC 3569
【非特許文献３】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", RFC 3556
【非特許文献５】Bolet et al., "Scalable Feedback Control for Multicast Video Distribution in the Internet", Proceedings of ACM/SIGCOMM 1994, Vol.24, No.4, Oct.1994
【非特許文献６】Bronstein et al., “Taschenbuch der Mathematik”, 1999, chapter 16.2.3.1: “Binomialverteilung”
【非特許文献７】Friedman et al., “RTP Control Protocol Extended Reports (RTCP XR)”, RFC 3611
【非特許文献８】Palia et al., “FLUTE - File Delivery over Unidirectional Transport”, draft-ietf-rmt-flute-07.txt, June 2004
【発明の概要】
【００３８】
本発明の目的は、エンドツーエンド概念を維持しつつ、エアインタフェースを介して提供されるマルチキャストサービス又はブロードキャストサービスに対する設定可能で適応的なフィードバックを可能にすることである。別の目的としては、ＲＴＰプロトコルを使用して提供されるＭＢＭＳに対する設定可能で適応的なフィードバックを提供することが挙げられる。
【００３９】
上記目的は、独立請求項の主題によって解決される。本発明の有利な実施の形態は、従属請求項の主題である。
【００４０】
本発明の主たる思想の一つは、移動通信ネットワーク内のフィードバック制御エンティティからマルチキャストサービス又はブロードキャストサービスを受信している端末のサブセットのみに、送信元、すなわちフィードバック制御エンティティへのフィードバックを提供させることである。これにより、エンドツーエンド概念を維持することができ、かつ適用プロトコルの階層構造を壊さないことも可能になる。本発明の別の思想は、統計的ユーザサンプリングを使用することであり、このサンプリングに基づいてフィードバックを提供する端末のサブセットを決定する。
【００４１】
本発明の実施の形態によれば、フィードバック制御エンティティにより送信又は転送されたマルチキャストサービス又はブロードキャストサービスを移動通信システムのエアインタフェースを介して受信している移動端末からのフィードバックの送信を制御する方法が提供される。この方法によれば、移動端末は、一方向ダウンリンクチャネルを介して、低信頼性トランスポートプロトコル及びセッションプロトコルを使用してマルチキャストサービス又はブロードキャストサービスを受信することができる。ここで、上記セッションプロトコルはマルチキャストサービス又はブロードキャストサービスを受信している端末のフィードバック提供を設定する。さらに、移動端末は、パラメータを受信することができる。該パラメータに基づいて、端末は、フィードバック制御エンティティへのフィードバックを提供するか否かを決定することができる。
【００４２】
決定ステップにおいて、移動端末は、受信パラメータに基づいて、マルチキャストサービス又はブロードキャストに対するセッションプロトコル設定フィードバックをフィードバック制御エンティティへ提供するか否かを決定することができる。セッションプロトコル設定フィードバックを提供するという決定がなされる場合、セッションプロトコル設定フィードバック制御エンティティへのフィードバックを提供するためのベアラを確立することができる。
【００４３】
ベアラが確立されたとき、移動端末は、マルチキャストサービス又はブロードキャストサービスの受信統計値を示すセッションプロトコル設定フィードバックを確立ベアラを介してフィードバック制御エンティティへ送信することができる。
【００４４】
この実施の形態は、シグナリングされたパラメータのセット（又は単一のパラメータ）に基づき、移動端末がセッションプロトコル設定フィードバックを提供するか否かを決定できるという利点をもつ。前述のように、移動端末がセッションプロトコル設定フィードバックを提供すると決定する場合、セッションプロトコル設定フィードバックを提供するためのベアラが確立されるが、この場合、リソース、例えば、移動通信システムの無線アクセスネットワーク中のリソースが当該移動端末にのみ割り当てられるようにベアラが確立される。
【００４５】
本発明のさらに別の実施の形態では、移動端末で受信するパラメータは、移動端末がセッションプロトコル設定フィードバックを提供するか否かを決定する確率試験の確率値を示す。従って、セッションプロトコル設定フィードバックを提供するか否かの決定は、移動端末によって実行された確率試験の結果に基づくことができる。この試験を実行するために、受信した確率値が使用される。
【００４６】
マルチキャストサービス又はブロードキャストサービスを受信している移動端末にシグナリングされた確率メトリックの使用により、移動通信システムのフィードバック制御エンティティから受信されたデータ（パラメータ）のサイズが縮小可能である一方、確率メトリックを受信した各移動端末にセッションプロトコル設定フィードバックを提供するか否かの決定を自発的にさせることができる。フィードバックを提供するか否かを決定するための確率試験の使用についての詳細は後述する。
【００４７】
本発明の別の実施の形態によれば、上記確率試験はベルヌーイ試験である。これは、移動端末における計算の複雑度を減少するために試験の実行時の計算を簡易化する近似を使用できるという利点を有することができる。
【００４８】
本発明のさらに別の実施の形態では、上記パラメータは、マルチキャストサービス又はブロードキャストサービスを提供しているマルチキャストデータチャネル又はブロードキャストデータチャネルを介して受信される。この場合、データは、先に述べたように、低信頼性トランスポートプロトコル、例えば、ＵＤＰを使用して端末に配信され得る。
【００４９】
本発明の別の実施の形態による方法は、マルチキャストサービス又はブロードキャストサービスが受信機候補に告示される告示チャネルを介してパラメータを受信することを先見する。この実施の形態の変形では、告示チャネル上のデータ伝送に高信頼性通信プロトコルが使用される。
【００５０】
この実施の形態は、各端末がシグナリングされたパラメータを高信頼性で少なくとも一回受信することが望ましいと考える。パラメータが低信頼性通信プロトコルを用いて提供される場合、各受信端末が、セッションプロトコル設定フィードバックを提供するか否かを決定するために、必要なパラメータを有し得ることが保証されない場合がある。
【００５１】
本発明の別の実施の形態は、移動端末で受信されたパラメータはさらに、パラメータの有効期間が終わる時点を示すことを先見する。この実施の形態の変形では、パラメータによって示された時点に達している場合、移動端末は、セッションプロトコル設定フィードバックを提供するための確立ベアラを解除することができる。
【００５２】
これにより、セッションプロトコル設定フィードバックを各端末から提供すべきか否かを決定するために、移動端末が旧パラメータセットを使用することが保証され得る。例えば、フィードバック制御エンティティから受信されるパラメータが（例えば定期的に）更新され、かつ低信頼性トランスポートメカニズムを使用して提供されるような状況に、これを適用することができる。この場合、パラメータの有効期間を示す上記のメカニズムを先見することが実現可能であるようなパラメータセットの更新を各端末が正常に受信することが保証されない場合がある。
【００５３】
先にすでに示したように、本発明の別の実施の形態は、パラメータの再設定又は更新を容易にする。移動端末は、再設定パラメータを受信することができ、この再設定パラメータはフィードバック制御エンティティから以前に受信したパラメータを更新する。
【００５４】
この実施の形態の変形では、上記再設定パラメータは、以前に受信したパラメータの有効期間を更新するか否かを示す、すなわち当該パラメータがいわば「追加の」時間期間中に有効となるか否かを示すフラグを含み得る。この場合、移動端末は、このフラグに基づき、以前に受信したパラメータの有効期間を更新することができる。
【００５５】
さらに別の実施の形態では、セッションプロトコル設定フィードバックを提供するためのベアラを確立した移動端末のみが上記有効期間を更新するようにされる。
【００５６】
また、本発明のさらに別の実施の形態によれば、受信した再設定パラメータは、セッションプロトコル設定フィードバックの提供についての新たな決定が移動端末によってなされるべきか否かを示す（追加の）フラグを含み得る。従って、このフラグに応じて、移動端末はセッションプロトコル設定フィードバックの提供についての新たな決定をなすべきか否かを決定するように制御されることができる。
【００５７】
上記フラグがそうすべきことを示す場合、移動端末は受信した再設定パラメータに基づいて、マルチキャストサービス又はブロードキャストサービスに対するフィードバック制御エンティティへのセッションプロトコル設定フィードバックを提供するか否かを決定することができる。先に述べたように、セッションプロトコル設定フィードバックを提供するという決定がなされる場合、フィードバック制御エンティティへのセッションプロトコル設定フィードバックを提供するためのベアラを確立することができ、そして移動端末は、マルチキャストサービス又はブロードキャストサービスの受信統計値を示すセッションプロトコル設定フィードバックを確立ベアラを介してフィードバック制御エンティティへ送信することができる。
【００５８】
次に、フィードバック制御エンティティの動作に関係する、さらに他の実施の形態を以下に概説する。フィードバック制御エンティティは、単独のネットワークエンティティ（構成要素）として実現されてもよいし、あるいはサービス供給元、すなわち、マルチキャストサービス又はブロードキャストプロバイダと一体化した、移動通信ネットワークのネットワークエンティティとして実現されてもよいことに留意すべきである。本発明の多様な実施の形態のうちの一つは、フィードバック制御エンティティにより送信又は転送されたマルチキャストサービス又はブロードキャストサービスを移動通信システムのエアインタフェースを介して受信している複数の移動端末からのフィードバックの送信をフィードバック制御エンティティによって制御する方法を提供する。この方法によれば、フィードバック制御エンティティは、低信頼性トランスポートプロトコル及びセッションプロトコルを使用してマルチキャストサービス又はブロードキャストサービスを送信又は転送することができる。ここで、上記セッションプロトコルはマルチキャストサービス又はブロードキャストサービスを受信している端末のフィードバック提供を設定する。
【００５９】
さらに、フィードバック制御エンティティは、フィードバック制御エンティティへのセッションプロトコル設定フィードバックを提供するか否かを移動端末に決定させるパラメータを決定することができ、そしてマルチキャストサービス又はブロードキャストサービスを受信している複数の移動端末のうちの少なくともサブセットに上記パラメータを送信することができる。従って、フィードバック制御エンティティは、複数の移動端末のうち上記パラメータを受信したサブセットからフィードバックを受信することができる。
【００６０】
本発明の別の実施の形態では、フィードバック制御エンティティは、フィードバック制御エンティティによって保持され又は移動通信システムのネットワークエンティティから受信したマルチキャストサービス又はブロードキャストサービスの状態情報に基づいてパラメータを決定する。
【００６１】
本発明のさらに別の実施の形態では、フィードバック制御エンティティによって決定されたパラメータは、移動端末がセッションプロトコル設定フィードバックを提供するか否かを決定する確率試験のための確率値を示すことができる。従って、この実施の形態によれば、フィードバック制御エンティティは、移動端末により確率試験に使用されるべき確率メトリックを決定し、このメトリックを複数の移動端末のうちの少なくともサブセットにシグナリングすることができる。
【００６２】
先に述べたように、本発明の一実施の形態は、受信機候補にマルチキャストサービス又はブロードキャストサービスが告示される告示チャネルを介してパラメータを送信することを予見する。さらに、告示チャネル上のデータ伝送には高信頼性通信プロトコルを使用することができる。
【００６３】
さらに別の実施の形態によれば、フィードバック制御エンティティは、マルチキャストサービス又はブロードキャストサービスの参加者の数に基づき確率値を決定することができる。マルチキャストサービス又はブロードキャストサービスの参加者の数は、例えば、マルチキャストサービス又はブロードキャストサービスに関連した状態情報から得ることができる。
【００６４】
本発明の別の実施の形態では、マルチキャストサービス又はブロードキャストサービスに関連した状態情報は、フィードバック制御エンティティで保持されたＭＢＭＳ  ＵＥコンテキスト又はＭＢＭＳベアラコンテキスト内に含まれる。代替的に、上記状態情報は、ＭＢＭＳ  ＵＥコンテキスト又はＭＢＭＳベアラコンテキストを保持する移動通信ネットワークのネットワークエンティティからフィードバック制御エンティティによって受信され得る。
【００６５】
本発明のさらに別の実施の形態では、フィードバック制御エンティティは、マルチキャストサービス又はブロードキャストサービスのプロバイダからマルチキャストサービス又はブロードキャストサービスのデータを受信することができる。
【００６６】
この実施の形態の変形では、フィードバック制御エンティティは、移動端末から受信したセッションプロトコル設定フィードバックをマルチキャストサービス又はブロードキャストサービスのプロバイダへ転送することができる。
【００６７】
さらに別の変形では、マルチキャストサービスのデータは、トランスポートプロトコル及びセッションプロトコルを使用してフィードバック制御エンティティに伝送されることができる。フィードバック制御エンティティは、マルチキャストサービス又はブロードキャストサービスのデータを移動端末に送信又は転送する前に、トランスポートプロトコル及びセッションプロトコルの少なくとも一つをそれぞれ別のトランスポートプロトコル又はセッションプロトコルに変換することができる。
【００６８】
さらに、マルチキャストサービスに対するフィードバックは、トランスポートプロトコル及びセッションプロトコルを使用してフィードバック制御エンティティに伝送されることが可能である。この場合、フィードバック制御エンティティは、フィードバックをマルチキャストサービス又はブロードキャストサービスのプロバイダへ転送する前に、トランスポートプロトコル及びセッションプロトコルの少なくとも一つをそれぞれ別のトランスポートプロトコル又はセッションプロトコルにさらに変換することができる。
【００６９】
この実施の形態の別の変形では、フィードバック制御エンティティは、移動端末から受信したセッションプロトコル設定フィードバックの集約情報を生成し、受信したフィードバックの集約情報をフィードバック情報としてマルチキャストサービス又はブロードキャストサービスのプロバイダへ送信することができる。
【００７０】
本発明のさらに別の実施の形態は、ＲＴＰを使用したサービス提供を考える。この実施の形態では、マルチキャストサービス又はブロードキャストサービスはＲＴＰプロトコルを使用して提供され、フィードバックはＲＴＣＰプロトコルを使用して提供される。ここで、マルチキャストサービス又はブロードキャストサービスを提供しているセッションに使用可能な帯域幅の一部分が、ＲＴＣＰプロトコルメッセージに割り当てられる。
【００７１】
さらに、代替的には、セッションプロトコル設定フィードバックは、ＲＴＣＰプロトコルのレシーバレポートの形式で提供され得る。本発明の実施の形態によれば、前述の受信統計値は、ＲＴＣＰプロトコルによるレシーバレポート内でシグナリングされる情報に相当し得ることに留意すべきである。
【００７２】
本発明の別の実施の形態によれば、フィードバック制御エンティティにより送信されかつ移動端末により受信されたパラメータは、ＲＴＣＰプロトコルを使用したフィードバックを提供するための報告時間間隔と使用可能帯域幅とをさらに示すことができる。
【００７３】
フィードバック制御エンティティからシグナリングされるパラメータは、フィードバック制御エンティティから送信されるＲＴＣＰプロトコルのセンダーレポートメッセージ内に含まれ得る。
【００７４】
さらに別の実施の形態は、フィードバック制御エンティティにより送信又は転送されたマルチキャストサービス又はブロードキャストサービスを移動通信システムのエアインタフェースを介して受信する移動端末に関する。移動端末は、一方向ダウンリンクチャネルを介して、低信頼性トランスポートプロトコルを使用してマルチキャストサービス又はブロードキャストサービスを受信する受信機を含み得る。さらに、端末は、移動端末がフィードバック制御エンティティへのセッションプロトコル設定フィードバックを提供するか否かを決定するパラメータを受信することができる。また、受信したパラメータに基づいて、マルチキャストサービス又はブロードキャストサービスに対するフィードバック制御エンティティへのセッションプロトコル設定フィードバックを提供するか否かを決定し、セッションプロトコル設定フィードバックを提供するという決定がなされる場合に、フィードバック制御エンティティへのセッションプロトコル設定フィードバックを提供するベアラを確立するプロセッサと、マルチキャストサービス又はブロードキャストサービスの受信統計値を示すセッションプロトコル設定フィードバックを確立ベアラを介してフィードバック制御エンティティへ送信する送信機とを含み得る。
【００７５】
本発明の別の実施の形態では、移動端末は、先に述べたフィードバック制御方法の多様な実施の形態のうちの一つにおける移動端末により実行される各ステップを実行するように適合された手段をさらに含み得る。
【００７６】
本発明の別の実施の形態は、移動通信システムのエアインタフェースを介してフィードバック制御エンティティにより送信又は転送されたマルチキャストサービス又はブロードキャストサービスを受信している移動端末からのフィードバックの送信を制御するフィードバック制御エンティティを提供する。この実施の形態によれば、フィードバック制御エンティティは、一方向ダウンリンクチャネルを介して、低信頼性トランスポートプロトコル及びセッションプロトコルを使用してマルチキャストサービス又はブロードキャストサービスを送信又は転送する送信機を含み得る。ここで、上記セッションプロトコルはマルチキャストサービス又はブロードキャストサービスを受信している端末のフィードバック提供を設定する。さらに、フィードバック制御エンティティは、フィードバック制御エンティティへのセッションプロトコル設定フィードバックを提供するか否かを移動端末に決定させるパラメータを決定するプロセッサをさらに含むことができ、上記送信機は、マルチキャストサービス又はブロードキャストサービスを受信している複数の移動端末のうちの少なくともサブセットに上記パラメータを送信するように適合され、フィードバック制御エンティティは、複数の移動端末のうち上記パラメータを受信したサブセットからセッションプロトコル設定フィードバックを受信する受信機をさらに含むことができる。
【００７７】
本発明の別の実施の形態では、フィードバック制御エンティティは、先に述べたフィードバック制御方法の多様な実施の形態のうちの一つにおけるフィードバック制御エンティティにより実行される各ステップを実行するように適合された手段をさらに含み得る。
【００７８】
さらに、本発明の一実施の形態は、上記に定義されたフィードバック制御エンティティと、エアインタフェースを介してフィードバック制御エンティティからマルチキャストサービス又はブロードキャストサービスを受信する上記に定義された少なくとも一つの移動端末とを含んでなる移動通信システムに関する。
【００７９】
本発明のさらに別の実施の形態は、移動端末のプロセッサにより実行されるとき、フィードバック制御エンティティにより送信又は転送されたマルチキャストサービス又はブロードキャストサービスを移動通信システムのエアインタフェースを介して受信している移動端末からのフィードバックの送信を当該プロセッサに制御させる命令を記憶するためのコンピュータ読取り可能媒体に関し、一方向ダウンリンクチャネルを介して、低信頼性トランスポートプロトコル及びセッションプロトコルを使用してマルチキャストサービス又はブロードキャストサービスを移動端末で受信し、ここで上記セッションプロトコルはマルチキャストサービス又はブロードキャストサービスを受信している端末のフィードバック提供を設定し、移動端末がフィードバック制御エンティティへのセッションプロトコル設定フィードバックを提供するか否かを決定するパラメータを移動端末で受信し、受信したパラメータに基づいて、マルチキャストサービス又はブロードキャストに対するフィードバック制御エンティティへのセッションプロトコル設定フィードバックを提供するか否かを移動端末により決定し、セッションプロトコル設定フィードバックを提供するという決定がなされる場合、フィードバック制御エンティティへのセッションプロトコル設定フィードバックを提供するためのベアラを移動端末により確立し、マルチキャストサービス又はブロードキャストサービスの受信統計値を示すセッションプロトコル設定フィードバックを確立ベアラを介して移動端末からフィードバック制御エンティティへ送信することにより、フィードバックの送信を制御する。
【００８０】
別の実施の形態では、上記コンピュータ読取り可能媒体は、移動端末のプロセッサにより実行されるとき、先に述べたフィードバック制御方法の多様な実施の形態のうちの一つにおける移動端末により実行される各ステップを当該プロセッサに実行させる命令をさらに記憶することができる。
【００８１】
さらに、本発明の別の実施の形態は、フィードバック制御エンティティのプロセッサにより実行されるとき、フィードバック制御エンティティにより送信又は転送されたマルチキャストサービス又はブロードキャストサービスを移動通信システムのエアインタフェースを介して受信している移動端末からのフィードバックの送信を当該プロセッサに制御させる命令を記憶するためのコンピュータ読取り可能媒体を提供し、一方向ダウンリンクチャネル介して、低信頼性トランスポートプロトコル及びセッションプロトコルを使用して、フィードバック制御エンティティから少なくとも一つの移動端末へマルチキャストサービス又はブロードキャストサービスを転送し、ここで上記セッションプロトコルはマルチキャストサービス又はブロードキャストサービスを受信している端末のフィードバック提供を設定し、フィードバック制御エンティティへのセッションプロトコル設定フィードバックを提供するか否かを移動端末に決定させるパラメータをフィードバック制御エンティティにて決定し、上記パラメータをフィードバック制御エンティティからマルチキャストサービス又はブロードキャストサービスを受信している複数の移動端末のうちの少なくともサブセットに送信し、複数の移動端末のうち上記パラメータを受信したサブセットからフィードバックをフィードバック制御エンティティで受信することにより、フィードバックの送信を制御する。
【００８２】
さらに別の実施の形態では、上記コンピュータ読取り可能媒体は、フィードバック制御エンティティのプロセッサにより実行されるとき、先に述べたフィードバック制御方法の多様な実施の形態のうちの一つにおけるフィードバック制御エンティティにより実行される各ステップを当該プロセッサに実行させる命令をさらに記憶することができる。
【図面の簡単な説明】
【００８３】
【図１】ＲＴＰセッションに加入し受信を行う受信機数の関数としての受信機当りの報告帯域幅を示す。
【図２】ＲＴＰセッションに加入し受信を行う受信機数の関数としてのレシーバレポート（ＲＲ）時間間隔Ｔを示す。
【図３】ＲＴＣＰアプリケーション定義パケットを示す。
【図４】本発明の実施の形態による、ＲＴＣＰアプリケーション定義パケットで伝送されるアプリケーション定義パラメータのフォーマットを示す。
【図５】本発明の実施の形態による、拡張ＲＴＣＰレシーバレポートブロックのフォーマットを示す。
【図６】本発明の実施の形態による、図３のＲＴＣＰアプリケーション定義パケット又は図５に示した拡張ＲＴＣＰレシーバレポートブロック内でパラメータを伝送するためのフォーマットを示す。
【図７】本発明の実施の形態による、ユーザにマルチキャストサービス又はブロードキャストサービスを提供し、受信端末からのフィードバックを制御するシナリオを示す。
【図８】本発明の実施の形態による、ユーザにマルチキャストサービス又はブロードキャストサービスを提供し、受信端末からのフィードバックを制御するシナリオを示す。
【図９】本発明の実施の形態による、ユーザにマルチキャストサービス又はブロードキャストサービスを提供し、受信端末からのフィードバックを制御するシナリオを示す。
【図１０】本発明の実施の形態による、移動端末とフィードバック制御エンティティとをそれぞれ示す。
【図１１】本発明の実施の形態による、移動端末とフィードバック制御エンティティとをそれぞれ示す。
【発明を実施するための形態】
【００８４】
以下に、添付の図及び図面を参照して本発明をさらに詳細に説明する。図中の類似の又は同等の細部は、同一の参照番号を付けてある。
【００８５】
以下の段落では、本発明の多様な実施の形態を説明する。典型的な例を示すという目的でのみ、実施の形態の大部分は、ＵＭＴＳ通信システムに関連して概説される。また、以下の節で使用される専門用語は、主にＵＭＴＳの用語に関係する。しかし、使用された用語とＵＭＴＳ構成に関連した実施の形態の説明とは、本発明の原理及び思想を上記システムに限定することを意図したものではない。
【００８６】
また、前述の背景技術の節で述べた詳細な説明は、以下に説明する主にＵＭＴＳに特有の典型的な実施例をよりよく理解するためのものにすぎず、移動通信ネットワークにおける処理及び機能のここで述べた特定の実現に本発明を限定するものと理解すべきではない。
【００８７】
以下の節で概説される思想及び原理は、一方向ダウンリンク及びデータ配信用の低信頼性トランスポートプロトコルを使用して、エアインタフェースを介して移動端末で受信されるマルチキャストサービス又はブロードキャストサービスに適用できる。さらに、受信端末から送信元、例えば、フィードバック制御エンティティへのフィードバックの提供を可能にするプロトコルが使用される。上記のシナリオでは、サービスデータが受信されるチャネルを介してフィードバックを提供することは、このチャネルは一方向なのであり得ないことに留意する。
【００８８】
本発明の一実施の形態の主要な態様は、先に述べたように、フィードバック制御エンティティからマルチキャストサービス又はブロードキャストサービスを受信している端末のサブセットのみが、通信ネットワーク内でのサービスとフィードバック提供とを制御し得る移動通信ネットワーク中のフィードバック制御エンティティへのフィードバックを提供することを可能にすることである。本発明の実施の形態では、これは、例えばマルチキャストサービス又はブロードキャストサービスを受信している移動端末に、フィードバックを提供するか否かを例えば確率試験に基づいて決定させることにより、達成することができる。この試験に使用されるべきパラメータ、例えば確率値をシグナリングすることにより、フィードバック制御エンティティは、サービスを受信している統計的に所望の数の移動端末がフィードバックを提供するように、シグナリングされるパラメータの値を変えることでフィードバックを制御することができる。
【００８９】
この点について、マルチキャストサービス又はブロードキャストサービスの基礎はエンドツーエンド概念であること、つまりエンドポイント間で交換される情報はあらゆる中間ノードには見えないということに留意することは重要である。このことは、ある層内の伝達情報をカプセル化する階層構造に従った適用プロトコルによっても反映される。一つの層での情報は、初めは他の層には見えない。隣接する層間でのみ、明確に定義されたサービスとサービスアクセスポイントとを通じて情報を交換できる。マルチキャストサービス又はブロードキャストサービスの送信情報は、送信元、すなわちフィードバック制御エンティティと受信機とにだけ見えるので、中間に介在するノードは使用された送信プロトコルよりも下位層のプロトコルのみをサポートする。
【００９０】
マルチキャストサービス又はブロードキャストサービスを受信している端末のサブセットを、フィードバックを提供する端末として選択するという思想は、このエンドツーエンド概念を維持し、適用プロトコルの階層構造を壊さない。
【００９１】
対照的に、ＵＴＲＡＮ又はＣＮの中間ノードでフィードバックを生成するとすれば、これらの概念を壊してしまい、プロトコルを非互換的に変更しなければならず、中間ノードを本来不適当な機能を実行するように拡張しなければならない場合がある。マルチキャストサービス又はブロードキャストサービスを提供するための構成を広範に定めるとすれば、このような仮定はいずれも実現不可能である。
【００９２】
本発明の別の実施の形態は、ＭＢＭＳサービスに対する設定可能で適応的なフィードバックを提供するという思想に基づく。以下に、この実施の形態をより詳細に説明する。
【００９３】
ＭＢＭＳサービスは、通常、メディアをストリーミングするＲＴＰプロトコルを使用する。併用されるＲＴＣＰプロトコルは、ＲＴＰセッションフィードバックを収集するために、またセッションのゆるい制御を実施するために使用され得る。ＲＴＣＰフィードバックは、現行のＲＴＰマルチキャストセッションに関する統計値を収集するために使用され得る。基本的な低信頼性トランスポートプロトコルとしては、ＵＤＰが想定され得る。
【００９４】
標準的なＲＴＰアルゴリズム、すなわち、参加している移動端末（ＭＴ）の数を推定するためにＲＴＣＰ  ＲＲを使用する代わりに、本発明のこの実施の形態により提案された方式は、セッション内のＭＴ／ＵＥの正確な数を決定するためにＭＢＭＳシグナリング及び／又はＭＢＭＳ状態情報を使用する。この手法は、受信機ごとにフィードバックチャネルをもつ必要性、各参加者が他の参加者からのすべてのメッセージを受信することを回避し、マルチキャスト／ブロードキャスト及び計算オーバヘッドを取り除く。
【００９５】
一般に、ＭＢＭＳ仕様において、特定のＭＢＭＳベアラサービスを記述するＭＢＭＳベアラコンテキストと、特定のＭＢＭＳベアラサービスに関連したＵＥ特有の情報からなるＭＢＭＳ  ＵＥコンテキストとの二つの種類の状態情報があることに留意するべきである。両方のコンテキストは、ＲＡＮ、ＳＧＳＮ、ＧＧＳＮ及びＢＭ−ＳＣにおいて作成され得る。現時点では、ＧＧＳＮにおけるベアラコンテキストがサービスを受信しているＵＥの数を含む。
【００９６】
しかし、その他のＲＡＮ又はＣＮのノードがサービスの状態情報をコンテキスト内に格納することも、もちろん可能であり、これらのノードは、例えば、作成されたコンテキストの数を計数することにより（すなわち、各ＵＥはネットワークノード中に自分のＵＥコンテキストをもつ）、又はサービス参加者の総数を示すコンテキスト内のフィールドにより、サービス参加ＵＥの数を決定することができる。
【００９７】
サービス提供のためにＭＢＭＳ構成を採用する場合、例えば、参加者の数として、ＢＭ−ＳＣのＵＥコンテキスト数を計数することができ、又はＧＧＳＮはベアラコンテキストの各フィールド値をＢＭ−ＳＣにシグナリングし、参加者の総数を提供できる。
【００９８】
セッション統計値の収集のための統計的ユーザサンプリングの使用は、移動端末（ＭＴ）のサブセットにのみフィードバックを提供させるために使用され得る、すなわち、受信機のサブセットのみがフィードバック制御エンティティにレポートを送信するように設定される。これは、各参加者がＲＴＣＰフィードバックを送信し通常このフィードバックがすべての他の参加者に転送される標準的なＲＴＰマルチキャストとは対照的である。
【００９９】
本発明のこの実施の形態によれば、報告実行受信機（reporting receiver）のセットは、確率的方式で選択される。統計的ユーザサンプリングを行うために必要な一つのパラメータとしては、報告確率があり得る。使用／シグナリングされ得るさらに別のパラメータとしては、報告時間間隔と確保すべきフィードバック帯域幅とがあり得る。送信側のフィードバック制御エンティティ、例えばＢＭ−ＳＣは、異なるサービスが異なる報告ニーズをもつ可能性があるので、許容フィードバックの全体量に従ってこれらのパラメータを設定することができる。
【０１００】
こうした方式を採用することにより、フィードバックチャネル数を制御することができ、各フィードバックチャネルがより効率的に使用される。
【０１０１】
上記の方式の設定のためのパラメータは、マルチキャスト／ブロードキャストグループ参加者に伝送され得る。これは、マルチキャスト／ブロードキャストデータチャネル又は、例えば、告示チャネル（announcement channel）を使用することで実施することができる。
【０１０２】
この実施の形態の変形は、フィードバック制御エンティティ（例えば、ＢＭ−ＳＣ）に、報告実行受信機セットを再設定する可能性、および現行のセッション中に報告時間間隔をグループサイズに依存しない一定の値に設定（再設定）する可能性を与える。これは、報告時間間隔を適度な値に設定できるようにするという問題に対処することができる。
【０１０３】
再設定後に各端末が異なる報告間隔及び確率で動作することを回避するために、タイマ値をこれらのメッセージに含めることができる。こうすることにより、マルチキャストチャネル上のシグナリング及びオーバヘッドを最小に抑えることができ、各エンド装置上のパラメータの計算により生じる計算オーバヘッドも同様に最小にできる。
【０１０４】
標準的なＲＴＰ／ＲＴＣＰアルゴリズム及びメカニズムは、単一の及び複数のデータ送信元と受信機とを含む広範なクラスのアプリケーションをサポートするために一般的な設計に従う。
【０１０５】
３ＧＰＰ  ＭＢＭＳでの活動の目標は、ＲＴＰ／ＲＴＣＰの規定よりもさらに特化されており、単一のサーバから移動端末のセットへの一方向データ配信、すなわち、ストリーミング又はダウロードサービスに焦点を絞っている。
【０１０６】
従って、先に示唆されたように、本発明の一実施の形態は、ＲＴＰ及びＲＴＣＰを使用しながらも後者の環境を最適化することに関する。特に、この実施の形態の目標としては、上記の導入部分で説明したいくつかの問題を解決しつつ、ＲＴＰデータ配信に関する統計値のフィードバックをサポートすることが挙げられ得る。
【０１０７】
３ＧＰＰ  ＭＢＭＳ構成の一部は、ＭＢＭＳベアラコンテキストである。このベアラコンテキストの中で、３Ｇネットワーク内にリンクを確立するために必要な情報が集められる。ＭＢＭＳベアラコンテキストは、通常、ＭＢＭＳサービスデータが端末に提供されるまでに通る経路中の各ノード、すなわち、ＢＭ−ＳＣ、ＲＡＮ、ＧＧＳＮ及びＳＧＳＮに格納される。
【０１０８】
ホストされるＵＥの数も、ＧＧＳＮにおいてＭＢＭＳベアラコンテキスト中に格納される。従って、ＲＴＰセッションに参加しているユーザ数を判定するためのＲＴＣＰフィードバックに固有の遅延やオーバヘッドを回避しながら、ＭＢＭＳセッションに参加しているＵＥの正確な数に関する知見をＢＭ−ＳＣが得られるように、ＧＧＳＮはホストされるＵＥの数をＢＭ−ＳＣに提供することができる。このように、各参加者からフィードバックレポートを収集することによりＵＥの数を判定する代わりに、ベアラコンテキスト中の状態情報が使用され得る。
【０１０９】
セッション参加者の数が、参加ユーザからのフィードバックを使用せずに、ＭＢＭＳ状態情報に基づいて判定され得るので、参加者ごとにフィードバックチャネルを保持する必要はない。従って、移動通信システムのＲＡＮやコアネットワークにおける使用可能なリソースの大幅な節約を達成することができる。先に述べたように、本発明の実施の形態は、ＲＡＮ及び／又はＣＮ中のネットワークノードのうちの一つ以上に格納され得るサービス関連状態情報を、特定のサービスを受信している端末数を判定するために使用し得ることを先見する。必要に応じて、状態情報はネットワークノード間で交換され得る。
【０１１０】
先に示されたように、フィードバックの目的で割り当てられる必要なリソースを削減するために、受信機のサブセットであるＭ個の受信機のみを選択し、サーバへのフィードバックのためのＭ個のアップリンクチャネルを確立すればよい。ＭＢＭＳサーバは、全フィードバック帯域幅ＢＲＲの値と使用可能なフィードバックチャネル数Ｍを決定することができる。
【０１１１】
フィードバック制御エンティティは、レポートパケットの構成と平均サイズＰＲＴＣＰとを知り得るので、フィードバックメッセージ当りの報告間隔Ｔを次式により計算することができる。
【０１１２】
【数３】
2010063129.tif 000004
【０１１３】
本発明の実施の形態によれば、報告実行受信機セットＭの選択のために確率的手法を採用することができる。各受信機は、成功確率ｐを用いて、確率試験、例えばベルヌーイ試験を実行することができる。この値の計算のため、確率密度関数を以下のように特徴づけることができる。
【０１１４】
ｎ人のユーザが確率ｐでベルヌーイ試験を行うと仮定し、また各試験は他の試験に依存しないと仮定すると、２項分布が得られ、確率密度関数は次のように表現できる。
【０１１５】
【数４】
2010063129.tif 000005
【０１１６】
さらに、確率分布関数が次式により与えられる。
【０１１７】
【数５】
2010063129.tif 000006
【０１１８】
一定の条件下で、この２項分布はガウス分布を用いて近似できる。必要条件は次のとおりである。
【０１１９】
【数６】
2010063129.tif 000007
【０１２０】
ＭＢＭＳサービスを考えるとき、一般にマルチキャストサービスは多数のユーザに送信されると仮定できるので、この近似は簡易化のためにも使用できる。
【０１２１】
この簡易化を想定した場合、式はさらに扱いやすくなる。簡易化した２項分布の確率密度関数は、下記の平均及び分散をもつガウス分布となり得る。
【０１２２】
【数７】
2010063129.tif 000008
【０１２３】
マルチキャストセッションに現在参加している受信機の総数ｎは、前述のように、ＭＢＭＳベアラコンテキストにより判定され得る。このようにして、サーバは成功確率ｐを計算するためのすべての情報を格納し保持することができる。
【０１２４】
従って、上記の計算をフィードバック制御エンティティに行わせ、その後、すべての必要なパラメータ（時間間隔Ｔ、確率ｐ、受信機当り報告帯域幅、ＢＲＲ／Ｍ＝ｂＲＲ）をマルチキャスト／ブロードキャストチャネルを通じてグループに告示することが妥当である。
【０１２５】
上記確率分布関数から、ｐの値を得ることができる。ｐの値により、間隔（ＭＭｉｎ，ＭＭａｘ）内に入るべき報告実行受信機の総数Ｍが判定される。このとき、ｐの値は次式を満たす。
【０１２６】
【数８】
2010063129.tif 000009
【０１２７】
この式は、前述した近似又はその他の方法を使用して解くことができる。その他の方法については、本文書ではさらに詳しく記さない（例えば、非特許文献６を参照）。
【０１２８】
上記のｐの値をＵＥが受信すると直ちに、ＵＥはベルヌーイ試験を行う。試験の結果が肯定的である場合にのみ、受信機は提供された参加者当り報告帯域幅ｂＲＲをもつフィードバックチャネルを確立することができる。本文書で概説された原理を使用するシステムに応じて、ＵＥはベアラに必要な帯域幅を指定する機会を得ることができることに留意する。その後、ＵＥは指定された時間間隔Ｔの経過後にＲＴＣＰ  ＲＲを送信することができる。
【０１２９】
本発明の一実施の形態によれば、受信機の設定に使用される、すなわち、フィードバックを提供するか否かをＵＥに決定させるためのパラメータは、ＲＴＣＰセンダーレポートブロックを利用して受信機へ伝送され得る。この目的で、いくつかのオプションが使用可能である。
【０１３０】
第一の可能性は、図３に示すような、ＲＴＣＰ仕様に適合するアプリケーション定義パケット（ＡＰＰパケット）を使用することである。パケットタイプ値の登録を必要とせずに新しい用途や新しい特徴が開発されるため、一般にＡＰＰパケットは、試験用に利用される。
【０１３１】
図３に示した各フィールド、Ｖ、Ｐ、サブタイプ、ＰＴ、長さ及びＳＳＲＣは、ＲＦＣ  ３５００の６．７節で定義される。名称フィールドは、例えば「ＭＢＭＳ」に設定され得るが、４オクテット以下からなる名称が代用されてもよい。さらに、アプリケーション依存データが、上記のフィールドに付加され得る。
【０１３２】
図４に示した本発明の例示的な実施の形態では、ＡＰＰパケットのアプリケーション特有の部分は、少なくとも次のフィールドからなり得る。ミリ秒単位の（ＲＴＣＰ）報告時間間隔を示す時間間隔、確率試験用の成功確率の固定小数点表現による確率値、確率試験が成功したならばレポートチャネルに受信機が割り当てるべき帯域幅（例えば、秒当りビット数）を指定する報告帯域幅。
【０１３３】
確率値の固定小数点表現を用いると、最大確率ｐ＝１は、例えば、１６ビットの列（「１１１１１１１１１１１１１１１１１」）として符号化され得る。従って、ｐの分解能は１／（２１６−１））となる。
【０１３４】
本発明のさらに別の実施の形態は、図５に示した、新たに定義された拡張レシーバレポートブロック（ＸＲレポートブロック）を用いて必要なパラメータを送信することを先見する。非特許文献７（http://www.ietf.orgにて得られる）では、拡張機能をもつアドホックＲＴＣＰレポートブロックの枠組みを指定する。この実施の形態によれば、このようなブロックが、上記に指定したような報告情報（例えば、報告間隔、報告確率など）を伝達するために定義され得る。
【０１３５】
図５に示したＸＲレポートブロック中の各フィールド、Ｖ、Ｐ、予備、ＰＴ、長さ、ＳＳＲＣは、ＲＦＣ３６１１の２節に示されるように定義される。同様に、ＢＴ、ｒｓｖｄ（タイプ特有情報用）、及びブロック長のフィールドは、ＲＦＣ３６１１の３節に定義される。ＢＴ（ブロックタイプ）フィールドは、（８，２５５）の範囲内の未使用値をとる。０〜７の値はすでに使用されている。
【０１３６】
このオプションは、先に述べたＡＰＰレポートブロックを使用する場合のアプリケーション層での実現の代わりに、ＲＴＰプロトコルにロジックを直接実装する可能性を含むという利点がある。本発明のこの実施の形態により提案されたソリューションは、受信機が、ＲＦＣ３６１１により得られ又は本文書で定義された拡張報告の可能性を使用又は実現することができるというさらなる利点を有する。
【０１３７】
本発明のさらに別の実施の形態では、上記エンティティへフィードバックを提供するか否かを移動端末に決定させるパラメータを伝達するために、ＲＴＰヘッダにおける特定プロファイル拡張（profile specific extension）、アドホックレポートブロック、又はＲＴＣＰの特有プロファイル拡張などの方法を使用することが提案される。
【０１３８】
以下では、本発明のいくつかの実施の形態による、報告情報の伝送方法のいくつかの変形（部分的に異なるトランスポートプロトコルを使用する）を以下の節で概説する。
【０１３９】
その確率的性質のため、ＵＤＰなどの低信頼性トランスポートプロトコルでＲＴＰが実行される場合、先に述べた各実施の形態は、厳密に望ましい数のフィードバックチャネルの確立を保証しない場合がある。
【０１４０】
このことの一つの理由は、フィードバック制御エンティティからパラメータを受信する参加者の数が足りないために、目標とされた最小のレポート数に達しない場合があることである。前述のように、ダウンストリームでのパケットは、低信頼性トランスポートメカニズムを使用しているため、損失する可能性がある。
【０１４１】
別の理由は、試験の確率的性質のため、試験の結果、実際にフィードバックメッセージを送信するユーザの数が余りに少なくなるということが起こることである。これはまれなケースとなる（フィードバックを送信するユーザが余りに少なくなる確率が最小になるように、下記の式を解くことができるため）。
【０１４２】
【数９】
2010063129.tif 000010
【０１４３】
また、報告帯域幅の増加などの様々なほかの理由により、受信機の再設定を行わせるのが妥当となる場合がある。
【０１４４】
以下では、本発明のある実施の形態は、移動端末におけるフィードバックを提供するか否かの決定のためのパラメータの再設定が、どのように再設定されるかを概説する。上記の実施の形態（図４及び図５）によりシグナリングされた情報に加えて、再設定と何らかのタイマ情報とを示す二つのフラグが、移動端末にパラメータを伝達するパケットに含まれ得る。タイマは、例えば、異なる参加者が異なる設定値を使用することによりアップリンク帯域幅を使い果たすことを回避することができる。
【０１４５】
この実施の形態によるパケット構成を図６に示す。上記の図４及び図５に関して概説された実施の形態の場合と同様に、パケットは確率フィールドを含む。このフィールドが１４ビット長であり、ベルヌーイ試験のための成功確率の固定小数点表現を使用すると仮定すると、ｐの分解能は１／（２１４−１）となる。ｐ＝１の確率は、所定の１４ビットの列（例えば、「１１１１１１１１１１１１１１」）によって示され得る。
【０１４６】
確率フィールド、報告帯域幅フィールド及び時間間隔フィールドのほかに、パケット構成は再設定フラグ（Ｒ）、デルタフラグ（Ｄ）及び当パラメータが有効である時間間隔（例えば、ミリ秒単位）を示すタイマ値フィールド（例えば、３２ビット）を含むことができる。
【０１４７】
タイマが時間切れになり、受信機が新しい値を受信していない場合、受信機（移動端末）はこれらの値の使用をやめて、確立されたフィードバックチャネルを切断することができる。これは、各端末が異なる設定値で動作することを避けるために実現可能である（連続する報告設定値（パラメータ）が同じ参加者のセットにて受信されることはなかったので）。確立されたフィードバックチャネルをもつ受信機は、報告設定値を参照し、タイマ値をそれに応じて更新することができる。
【０１４８】
再設定フラグ（Ｒ）は、再設定を実行すべきか否かを受信機に知らせることができる。再設定フラグがセットされていなければ（例えば、Ｒ＝０）、当該メッセージはすでに確立されたフィードバックチャネルをもつ受信機のタイマ値を更新するために使用される。これは、現存の報告実行受信機を維持するために使用され、再設定は行われない。再設定フラグがセットされている場合（例えば、Ｒ＝１）、デルタフラグ（Ｄ）の状態に応じて、受信機は確率試験を実行しなければならない。
【０１４９】
デルタフラグ（Ｄ）は、再設定フラグがセットされている場合（例えば、Ｒ＝１）に再設定の範囲を定義することができる。デルタフラグがセットされていなければ（例えば、Ｄ＝０）、再設定はすべての受信機に適用する。この場合、すべての受信機は、指定された確率値に従って確率試験を実行することができる。これは、報告実行受信機を初期選択するために、又は確立された報告シナリオを完全に再設定するために、例えば、すべての報告実行受信機を停止するために使用することができる。
【０１５０】
デルタフラグがセットされていない場合（例えば、Ｄ＝０）、すでにフィードバックを実行する決定をしすでにフィードバックチャネルを確立した移動端末は、切断と再確立とを行わずに当該チャネルを保持することができる。ただしこれは、確立されたアップリンクが新しいメッセージで知らされたのと同じ帯域幅を提供するという前提でのみ当てはまり得る。もし帯域幅が変更されたとすれば、受信機は、古いチャネルを切断し、新しいフィードバックチャネル（ベアラ）を再確立する必要がある。
【０１５１】
デルタフラグがセットされている場合（例えば、Ｄ＝１）、再設定は、フィードバックチャネルをその時点で保持していない受信機にのみ適用することができる。このような受信機だけが、指定された確率値に従って確率試験を実行することができる。これは、報告実行受信機の好適な閾値Ｍｍｉｎが満たされず、追加の受信機がフィードバックチャネルを確立することが望まれる場合に有益である。
【０１５２】
以下の表は、異なる再設定オプションをまとめたものである。
【０１５３】
【表１】
2010063129.tif 000011
【０１５４】
上記の節の説明で明らかなように、低信頼性トランスポートメカニズムが報告パラメータを伝達するために使用される場合、パラメータが伝送中に損失する可能性がある。これは、パケットが低信頼性ＵＤＰプロトコルで転送される場合に特に言える。ＵＤＰは一般的に、ＲＴＰパケットにおいてストリーミングメディア（ＭＰＥＧ４のような）をユニキャスト／マルチキャストするのに使用される。対応するＲＴＣＰパケットもＵＤＰで伝送される。
【０１５５】
ＢＭ−ＳＣ（本実施の形態においてフィードバック制御エンティティとして動作する）は、より確実な方法でこの情報を送信することを決定してもよい。上記の各実施の形態では、ＢＭ−ＳＣが移動端末へ送信されるパラメータの送信元とみなされたことに留意する。しかし、マルチキャスト又はブロードキャストのサービス（セッション）のコンテンツを提供するフィードバック制御エンティティがサービスを受信している移動端末へこれらのパラメータを決定し伝播することも可能である。
【０１５６】
ＭＢＭＳの枠組みにおいて、この情報をより確実な方法で送信する方法がある。端末は、例えば、ＨＴＴＰサーバへのポイントツーポイント接続を使用して、ＭＢＭＳサービスのセッション記述情報（例えば、ＳＤＰ記述のような）を取得してもよいし、又はＭＢＭＳセッションに加わる前にこの情報を含むＳＭＳを受信してもよい。
【０１５７】
別の可能性は、ＦＬＵＴＥプロトコルの使用である（http://www.ietf.orgにて得られる非特許文献８を参照）。ＦＬＵＴＥプロトコルは、ＭＢＭＳ構成において高信頼性データ転送に使用され得る。フィードバックを提供するか否かを移動端末に決定させるためのパラメータをとりわけ含むサービス告示情報が、ＦＬＵＴＥと提供されたサービスを記述するセッション記述プロトコル（例えば、ＳＤＰ（Session Description Protocol））とを使用して送信され得る。
【０１５８】
従って、本発明の別の実施の形態によれば、上記のようなセッション記述の高信頼性送信が使用できる場合、報告情報（少なくとも報告確率、場合により必要であればさらに、報告間隔と報告帯域幅）は、当該記述に含まれ得る。
【０１５９】
次に、マルチキャストサービス又はブロードキャストサービスをユーザに提供するための、そして上記の多様な実施の形態に概説された本発明を採用することができる、いくつかの可能なシナリオを、図７、図８及び図９に関して例示目的で概説する。
【０１６０】
図７において、コンテンツサーバ７０１は、例えば、ＩＰベースネットワークでマルチキャストセッション又はブロードキャストセッションをフィードバック制御エンティティ、例えば、ＢＭ−ＳＣ７０４を介してユーザに提供する。サービスを受信するユーザのいくつかは、例示目的で以下に検討されるＵＭＴＳネットワーク７０２などの移動通信ネットワーク内に位置することができる。
【０１６１】
本発明の一実施の形態によれば、ＵＭＴＳネットワーク７０２内に設置されたＢＭ−ＳＣ７０４は、先に述べたように、サービス受信端末７１２、７１３からのフィードバックの提供を制御することができる。ＢＭ−ＳＣ７０４は、コンテンツサーバ７０１からサービスデータを受信し、例えば、ＣＮ（コアネットワーク）７０３のＧＧＳＮ（ＧＰＲＳゲートウェイサポートノード）７０５及びＳＧＳＮ（サービングＧＰＲＳサポートノード）７０６、少なくとも一つのＲＮＣ７０９並びに少なくとも一つのノードＢ（Node B）７１０、７１１を介して、ＭＢＭＳセッション内でコンテンツデータを端末７１２、７１３に送信することができる。ＢＭ−ＳＣ７０４は、ＵＭＴＳネットワーク７０２中の告示チャネルを介してサービス利用可能性を告示する役割を担い、サービスアドミッション、すなわち、ＵＥのサービスへの参加及び退去にかかわることに関与する。本発明の一実施の形態に関係して先に述べたように、サービス告示はフィードバック制御のためのパラメータを含むことができる。
【０１６２】
図８に移ると、コンテンツサーバ８０１が移動通信システム内に設置される本発明の例示的な実施の形態が図示される。図７に示したデータ提供のためのＩＰベースネットワークが必要でなくなることを除き、基本的に、図７を参照して概説した本発明の実施の形態について行った同じ考察がここでも当てはまる。
【０１６３】
図９には、コンテンツサーバ９０１がマルチキャストサービス又はブロードキャストサービスのデータの送信元である本発明の例示的実施の形態が図示される。本発明のこの実施の形態では、コンテンツサーバ９０１は、サービスに関連したデータストリームを直接ＧＧＳＮ７０５に供給している。この実施の形態によれば、ＧＧＳＮ７０５が、サービスを受信する下流の端末からのフィードバック提供を制御するネットワークエンティティとなり得る。この場合、ＭＢＭＳベアラコンテキストなどのサービス関連コンテキスト情報に格納された個々の情報に基づいて、ＧＧＳＮ７０５がサービス参加者の数を直接判定することができる。
【０１６４】
本発明のさらに別の実施の形態では、フィードバック制御エンティティ、例えばＢＭ−ＳＣは、図７及び図８に示されたマルチキャストサービス又はブロードキャストサービスプロバイダ（コンテンツプロバイダ７０１、８０１）からマルチキャストサービス又はブロードキャストサービスのデータを受信することができる。
【０１６５】
フィードバック制御エンティティは、マルチキャストサービス又はブロードキャストサービスのプロバイダにとって非透過的モードで動作することができる。このモードを図７を参照して以下に説明する。
【０１６６】
ここでは、ＢＭ−ＳＣ７０４（すなわち、図７に示した例示的な実施の形態におけるフィードバック制御エンティティ）は、コンテンツプロバイダ７０１（すなわち、図７に示した例示的な実施の形態におけるマルチキャストサービス又はブロードキャストサービスのプロバイダ）の視点からは、マルチキャストサービス又はブロードキャストサービスを受信するクライアントとして動作する。端末７１２、７１３の視点からは、マルチキャストサービス又はブロードキャストサービス、ＢＭ−ＳＣ７０４はサービスを提供するマルチキャストサーバ又はブロードキャストサーバとして動作する。
【０１６７】
従って、コンテンツサーバ７０１から移動端末７１２、７１３までのエンドツーエンドサービスセッションは存在しない場合がある。しかし、サービス供給は、一つは移動端末７１２、７１３とＢＭ−ＳＣ７０４との間、一つはＢＭ−ＳＣ７０４とコンテンツプロバイダ７０１との間の、二つのエンドツーエンドセッションに分割される。
【０１６８】
両方のセッションで、例えば、トランスポート層及びセッション層の異なるプロトコルを使用することもできる。例えば、ＢＭ−ＳＣ７０４と端末７１２、７１３との間のセッションはＲＴＰ／ＵＤＰ／ＩＰ（及びＲＴＣＰフィードバック）を使用し、一方、コンテンツプロバイダ７０１とＢＭ−ＳＣ７０４との間のセッションはこれと同じプロトコル又は異なるプロトコルを使用してもよい。従って、ＢＭ−ＳＣ７０４は、プロトコル変換メカニズムを提供するゲートウェイのように動作することができる。
【０１６９】
ここで、コンテンツプロバイダ７０１とＢＭ−ＳＣ７０４との間のセッションを考察すると、後者はコンテンツプロバイダ７０１にフィードバックを供給する。端末７１２、７１３から受信したフィードバックによって反映される受信統計値、例えば、異なるサービス受信端末７１２、７１３で達成されたＱｏＳ、個々の端末７１２、７１３へのパケット損失率などを反映するために、ＢＭ−ＳＣ７０４は、受信したフィードバックを分析し、移動通信システム内のサービスの受信統計値を反映するその集約値又は積算値を作成することができる。この集約値又は積算値は、フィードバックとしてコンテンツプロバイダ７０１へ何らかの形式で供給され得る。例えば、ＢＭ−ＳＣ７０４は、集約値又は積算値を反映した「標準的な」ＲＴＣＰレシーバレポートを生成してもよいし、又はフィードバック提供の特別な形式がコンテンツプロバイダ７０１とＢＭ−ＳＣ７０４との間で定義されてもよい。
【０１７０】
第二の可能性は、個々のＵＥ７１２、７１３からの受信フィードバックをＢＭ−ＳＣ７０４がコンテンツプロバイダ７０１へ転送することができる。この場合も、ＢＭ−ＳＣ７０４とコンテンツプロバイダ７０１との間には別個の接続／セッションがあり、そこでは別のプロトコルを使用してもよいのだから、ＢＭ−ＳＣ７０４はフィードバックデータの何らかの変換を行ってもよい。
【０１７１】
とにかく、ＢＭ−ＳＣ７０４からコンテンツプロバイダ７０１へのフィードバック提供は、例えば、受信サービスに対して達成されたＱｏＳに基づきユーザが課金される場合、特に実現可能である。
【０１７２】
本発明の別の実施の形態は、ハードウェア及びソフトウェアを使用した上記の多様な実施の形態の実現に関する。多様な前述の方法や前述の様々な論理ブロック、モジュール、回路は、例えば、汎用プロセッサとしてのコンピュータデバイス（プロセッサ）、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）又はその他のプログラム可能論理素子などを使用して実現可能又は実施可能であることが認識される。本発明の多様な実施の形態は、上記のデバイスの組合せによっても実施又は実現され得る。
【０１７３】
さらに、本発明の多様な実施の形態は、プロセッサで実行されるソフトウェアモジュールにより又はハードウェアにおいて直接実現可能である。また、ソフトウェアモジュールとハードウェア実現との組合せも可能である。ソフトウェアモジュールは、コンピュータで読取り可能などんな種類の記憶媒体（例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなど）に記憶されてもよい。
【０１７４】
これに関して、図１０及び図１１は、本発明の例示的な実施の形態による、移動端末とフィードバック制御エンティティとをそれぞれ示す。
【０１７５】
移動端末は、フィードバック制御エンティティから配信されたデータを表示するディスプレイ１００１、並びにマルチキャストセッション又はブロードキャストセッションの受信及びフィードバックの送信を可能にする少なくとも一つの通信インタフェース１００４をとりわけ含み得る。さらに、移動端末は、コンピュータ読取り可能記憶媒体１００３に記憶された命令を実行するためにとりわけ使用され得るプロセッサ１００２（コンピュータデバイス）を含み得る。さらに、プロセッサ１００２は、通信インタフェース１００４を介した通信の制御や、フィードバックを提供するか否かを決定するための確率試験の実行なども行うことができる。
【０１７６】
図１１に示したフィードバック制御エンティティは、プロセッサ１１０１、コンピュータ読取り可能記憶媒体１１０２及び少なくとも一つの通信インタフェース１１０４を含み得る。
【０１７７】
フィードバック制御エンティティは、ある場合には、マルチキャストサービス又はブロードキャストサービスを提供又は転送するＵＭＴＳネットワークのＢＭ−ＳＣである。フィードバック制御エンティティは、マルチキャストサービス又はブロードキャストサービスによりユーザへ提供されたサービスデータ（例えば、ストリーム）を格納又は一時保存するサービスデータベース１１０３をさらに含み得る。さらに、コンピュータ読取り可能記憶媒体１１０２は、プロセッサ１１０１で実行可能な命令やさらに他のデータを記憶することができる。
【０１７８】
例えば、コンピュータ読取り可能記憶媒体１１０２に記憶されるデータは、フィードバック制御エンティティがサービス参加者の数を判定する各サービスのコンテキスト情報を含み得る。コンピュータ読取り可能記憶媒体１１０２に記憶される命令は、さらに、上記の多様な実施の形態に概説したとおり、フィードバック制御エンティティがサービス参加者からのフィードバック提供を制御することを可能にすることができる。
【図１】
2010063129.tif 000012
【図２】
2010063129.tif 000013
【図３】
2010063129.tif 000014
【図４】
2010063129.tif 000015
【図５】
2010063129.tif 000016
【図６】
2010063129.tif 000017
【図７】
2010063129.tif 000018
【図８】
2010063129.tif 000019
【図９】
2010063129.tif 000020
【図１０】
2010063129.tif 000021
【図１１】
2010063129.tif 000022