(57)【要約】  本発明は、送信セッション内において１台の送信機（９０２）から複数台の受信機（９０１）へ共有データを送信するための方法と、コンピュータプログラムと、コンピュータプログラム製品と、システムと、送信機と、受信機と、セッション記述プロトコルとに関し、前記送信セッション内における前記共有データの前記送信に関係する少なくとも１つのセッションパラメータを通信プロトコルを介して前記複数台の受信機（９０１）へ通信すること（８０２）と、前記送信セッション内において前記送信機（９０２）から前記複数台の受信機（９０１）へ前記共有データを送信することとが含まれる。本発明は、特に、有線接続ネットワークおよび／または無線ネットワークにおける放送／マルチキャスト共有データの送信に関し、該送信時に、片方向トランスポートプロトコルを介するファイル転送（ＦＬＵＴＥ）が利用される。公開用として図１を示す。
2007531368.tif 000002
【特許請求の範囲】
【請求項１】
送信セッション内において１台の送信機から複数台の受信機へ共有データを送信する方法であって、前記送信セッション内における前記共有データの前記送信に関係する少なくとも１つのセッションパラメータを通信プロトコルを介して前記複数台の受信機へ通信することと、前記送信セッション内において前記送信機から前記複数台の受信機へ前記共有データを送信することと、を備える方法。
【請求項２】
前記送信セッションの確立前に、または、前記送信セッションの確立中に前記少なくとも１つのセッションパラメータを前記複数台の受信機へ通信する請求項１に記載の方法。
【請求項３】
前記通信プロトコルがセッション記述プロトコル（ＳＤＰ）である請求項１に記載の方法。
【請求項４】
インターネットプロトコル（ＩＰ）ベースのネットワークを介して少なくとも部分的に前記送信機から前記複数台の受信機へ前記共有データを送信する請求項１に記載の方法。
【請求項５】
放送時に、または、マルチキャスト処理時に前記送信機から前記複数台の受信機へ前記共有データを送信する請求項１に記載の方法。
【請求項６】
前記共有データがストリーミングデータまたは非ストリーミングデータである請求項１に記載の方法。
【請求項７】
前記共有データがリアルタイムデータまたは非リアルタイムデータである請求項１に記載の方法。
【請求項８】
無線ネットワークを介して少なくとも部分的に前記送信機から前記複数台の受信機へ前記共有データを送信する請求項１に記載の方法。
【請求項９】
前記無線ネットワークが、第３世代パートナプロジェクト（３ＧＰＰ）によって規定されているようなマルチメディア放送／マルチキャストサービス（ＭＢＭＳ）を少なくとも部分的に実行する移動通信ネットワークである請求項８に記載の方法。
【請求項１０】
前記通信プロトコルが、前記送信セッション内における前記共有データの前記送信用として用いられる少なくともＦＥＣ符号化方式を指定する順方向エラー修正（ＦＥＣ）属性を含む請求項１に記載の方法。
【請求項１１】
前記ＦＥＣ属性がＦＥＣ符号化識別子をさらに指定する請求項１０に記載の方法。
【請求項１２】
前記通信プロトコルが、ＦＥＣ復号化情報をダウンロードすることができるダウンロード元のロケーションを指定するＦＥＣマシン属性を含む請求項１に記載の方法。
【請求項１３】
前記複数台の受信機のうちの少なくとも１台の受信機によって前記ロケーションから前記ＦＥＣ復号化情報をエラーのない方法でダウンロードする必要がある請求項１２に記載の方法。
【請求項１４】
前記複数台の受信機のうちの少なくとも１台の受信機が、前記ＦＥＣ復号化情報をダウンロードするために、ハイパーテキスト・トランスポートプロトコル（ＨＴＴＰ）ベースの、または、トランスポート制御プロトコル（ＴＣＰ）ベースのポイント間接続を利用する請求項１２に記載の方法。
【請求項１５】
前記複数台の受信機のうちの少なくとも１台の受信機が、時間分散機能を用いて、前記ロケーションからの前記ＦＥＣ復号化情報のダウンロード開始時刻を決定する請求項１２に記載の方法。
【請求項１６】
前記通信プロトコルが、前記送信セッション時における前記送信機から前記複数台の受信機への前記共有データの送信中、前記複数台の受信機に課せられたバッファ処理要件を指定する順方向エラー修正バッファ属性を含む請求項１に記載の方法。
【請求項１７】
前記バッファ処理要件がバッファ遅延、バッファ処理用メモリサイズ、あるいは上記双方である請求項１６に記載の方法。
【請求項１８】
前記通信プロトコルが、前記送信セッション内における前記共有データの前記送信用として利用される輻輳状態制御方式を指定する輻輳状態制御属性を含む請求項１に記載の方法。
【請求項１９】
前記複数台の受信機のうちの少なくとも１台の受信機において前記共有データが正しく受信されなかった場合、リペアセッション内でリペアサーバから前記少なくとも１台の受信機へ少なくとも前記共有データの一部を送信する請求項１に記載の方法。
【請求項２０】
前記複数台の受信機のうちの前記少なくとも１台の受信機が時間分散機能を用いて、前記リペアセッションの開始時刻を決定する請求項１９に記載の方法。
【請求項２１】
前記リペアセッションがポイント間リペアセッションまたはポイント・ツウ・マルチポイントリペアセッションである請求項１９に記載の方法。
【請求項２２】
前記通信プロトコルが、前記リペアサーバのＵＲＩを指定するリペアユニフォームリソース識別子（ＵＲＩ）属性を含む請求項１に記載の方法。
【請求項２３】
前記通信プロトコルがエラーしきい値を指定するリペアしきい値属性を含み、さらに、前記エラーしきい値が、前記送信セッションで前記送信機から前記複数台の受信機によって受信されるような前記共有データの受信品質に関係する請求項１９に記載の方法。
【請求項２４】
前記複数台の受信機のうちの少なくとも１台の受信機によって前記リペアセッションの中へ入るステップが、前記送信セッション内において前記送信機から前記受信機によって受信されるような前記共有データの受信品質と、前記エラーしきい値と間の関係に依存する請求項２３に記載の方法。
【請求項２５】
エラー単位と、エラー値と、測定ウィンドウの単位と、測定ウィンドウ値という点から前記エラーしきい値を定量化する請求項２３に記載の方法。
【請求項２６】
エラー値という点から前記エラーしきい値を定量化する請求項２３に記載の方法。
【請求項２７】
前記送信セッション用として複数のエラーしきい値を利用し、さらに、前記エラーしきい値に明示的にまたは暗黙のうちにラベルを施す請求項２３に記載の方法。
【請求項２８】
前記通信プロトコルが、バックオフモードを指定するバックオフモード属性を含み、さらに、前記送信セッション内において前記送信機から前記共有データを正しく受信しなかった受信機が前記リペアセッションを求める要求を開始できる時点に関する情報を前記バックオフモードが提供する請求項１９に記載の方法。
【請求項２９】
前記通信プロトコルがバックオフモードを指定するバックオフモード属性を含み、前記送信セッション内において前記送信機から前記共有データを正しく受信しなかった受信機が前記リペアセッションを求める要求を開始できる時点に関する情報を前記バックオフモードが提供し、前記送信セッション用として複数のバックオフモードを利用し、さらに、前記エラーしきい値のうちの少なくとも１つの前記エラーしきい値を前記バックオフモードのうちの少なくとも１つのバックオフモードとそれぞれリンクさせる請求項２７に記載の方法。
【請求項３０】
前記送信セッション中に受信機が受信するような前記共有データの受信品質と、前記エラーしきい値によって要求されるような受信品質との間の関係に依存して、前記バックオフモードを前記受信機に割り当てる請求項２９に記載の方法。
【請求項３１】
バックオフ単位と、バックオフ値と、バックオフウィンドウとによって前記情報を表わす請求項２８に記載の方法。
【請求項３２】
絶対タイミングが用いられているか、相対タイミングが用いられているかを示す変数と、時間値とによって前記情報を表わす請求項２８に記載の方法。
【請求項３３】
前記情報がエラーしきい値と３つの値Ｘ、Ｙ、Ｚとを含み、さらに、前記複数台の受信機のうちの少なくとも１台の受信機において、前記送信セッション内において前記送信機から前記少なくとも１台の受信機によって受信されるような前記共有データの受信品質が、前記エラーしきい値が決定する受信品質よりも良好な品質である場合、継続時間Ｘのタイムインタバルの範囲内で前記リペアセッションを求める前記要求をランダムに開始し、前記送信セッションの終了時に前記インタバルが開始し、そうでない場合には、Ｙと、Ｙ＋Ｚとの間の時間の範囲内で前記リペアセッションを求める前記要求をランダムに開始し、前記送信セッションの終了からＹをカウントする請求項２８に記載の方法。
【請求項３４】
前記通信プロトコルを用いて前記複数台の受信機の数を前記複数台の受信機へ通信することができる請求項１に記載の方法。
【請求項３５】
前記通信プロトコルがリペアタイプパラメータ属性を含み、該リペアタイプパラメータ属性によって、前記リペアセッションをポイント間セッションとするか、ポイント・ツウ・マルチポイントセッションとするか、あるいは、上記双方のセッションとすることができるかどうかが指定される請求項１９に記載の方法。
【請求項３６】
前記通信プロトコルが、前記リペアセッションのタイプを指定するリペアトークン属性を含むか、前記送信セッション内において前記複数台の受信機のうちの少なくとも１台の受信機において正しく受信されない前記共有データのどの部分が、前記リペアセッション内で前記リペアサーバから前記少なくとも１台の受信機へ送信されるかに関する情報を含むか、あるいは、上記双方を含む請求項１９に記載の方法。
【請求項３７】
前記通信プロトコルがコンテンツ記述属性を含み、前記共有データのコンテンツに関する記述が格納されているＵＲＩを前記送信機が前記複数台の受信機に示す方法が該コンテンツ記述属性によって指定される請求項１に記載の方法。
【請求項３８】
前記送信機から前記複数台の受信機への前記共有データの前記送信が、片方向トランスポートプロトコルを介するファイル転送（ＦＬＵＴＥ）によって少なくとも部分的に制御される請求項１に記載の方法。
【請求項３９】
前記送信セッション内において前記共有データを前記複数台の受信機へ送信するために前記送信機が使用するチャネル数を指定するＦＬＵＴＥチャネル属性が前記通信プロトコルの中に含まれる請求項３８に記載の方法。
【請求項４０】
前記通信プロトコルが、前記送信セッション内においてＴＳＩの値を指定するＦＬＵＴＥ送信セッションＩＤ  ＴＳＩ属性を含む請求項３８に記載の方法。
【請求項４１】
前記通信プロトコルが、前記送信セッション内において使用メディアを指定するメディア記述を含む請求項３８に記載の方法。
【請求項４２】
前記通信プロトコルが、前記送信セッション内において使用チャネルのアドレスを指定する接続データを含む請求項３８に記載の方法。
【請求項４３】
請求項１の前記方法のステップをプロセッサに実行させるように作動可能なコンピュータプログラム。
【請求項４４】
請求項１の前記方法ステップをプロセッサに実行させるように作動可能な命令を含むコンピュータプログラムを備えるコンピュータプログラム製品。
【請求項４５】
データを送信するシステムであって、該システムが、少なくとも１台の送信機と、複数台の受信機とを備え、前記少なくとも１台の送信機と、前記複数台の受信機とが、前記送信セッション内における前記共有データの前記送信に関係する少なくとも１つのセッションパラメータを、前記少なくとも１台の送信機から前記複数台の受信機へ通信プロトコルを介して通信するように構成された手段を備え、さらに、前記少なくとも１台の送信機と、前記複数台の受信機とが、前記送信セッション内において前記送信機から前記複数台の受信機へ前記共有データを送信するように構成された手段を備えるシステム。
【請求項４６】
送信セッション内において複数台の受信機へ共有データを送信する送信機であって、該送信機が、
前記送信セッション内における前記共有データの前記送信に関係する少なくとも１つのセッションパラメータを通信プロトコルを介して前記複数台の受信機へ通信するように構成された手段と、
前記送信セッション内において前記複数台の受信機へ前記共有データを送信するように構成された手段とを備える送信機。
【請求項４７】
送信セッション内において１台の送信機から複数台の受信機へ送信される共有データを受信する受信機であって、該受信機が、
前記送信セッション内における前記共有データの前記送信に関係する少なくとも１つのセッションパラメータであって、通信プロトコルを介して前記複数台の受信機へ通信される少なくとも１つのセッションパラメータを受信するように構成された手段と、
前記送信セッション内において前記送信機から前記複数台の受信機へ送信される前記共有データを受信するように構成された手段と、を備える受信機。
【請求項４８】
送信セッション内における送信機から複数台の受信機への共有データの送信に関係する少なくとも１つのセッションパラメータの定義を含む通信プロトコル。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送信セッション内において１台の送信機から複数台の受信機へ共有データを送信するための、方法と、コンピュータプログラムと、コンピュータプログラム製品と、システムと、送信機と、受信機と、プロトコルとに関する。
【背景技術】
【０００２】
放送／マルチキャストサービスとは、１台の送信機から複数台の受信機へ共通の（同じ）情報を送信する柔軟でかつ効率のよいメカニズムの提供を意図するサービスである。
【０００３】
無線通信システムのコンテキストでは、第３世代パートナプロジェクト（３ＧＰＰ）によって標準化されているような一般移動通信システム（ＵＭＴＳ）におけるマルチメディア放送／マルチキャストサービス（ＭＢＭＳ）が利用されている。
【０００４】
３ＧＰＰのＭＢＭＳは、放送サービスは、単複の放送エリアにおける単一ソースエンティティ（送信機）からすべてのユーザ（受信機）へのマルチメディアデータ（テキスト、オーディオ、映像、ビデオなど）の片方向ポイント・ツウ・マルチポイント送信について記述している。放送（一斉同報）モードは、無線／ネットワークリソースの効率的利用を意図するものであり、例えば、データは共通の無線チャネルを介して送信される。データはネットワークによって定義されているように放送エリアへ送信される。
【０００５】
ユーザが受信する放送サービスは１以上の連続する放送セッションを含むようにすることも可能である。例えば、放送サービスは、現在進行中の単一セッション（メディアストリームなど）から成る場合もあれば、延長期間にわたって間欠的に生じるいくつかのセッション（メッセージなど）を含む場合もある。
【０００６】
放送モードを利用するサービスの１例として、広告やネットワークへの歓迎メッセージを挙げることができる。ネットワークと接続しているすべてのユーザがこれらのメッセージの受信を必ずしも望んでいるわけではないので、その場合、ユーザは、自分のユーザ装置（ＵＥ）でこれらの放送サービスの受信のオン／オフを行うことができるようになっている。
【０００７】
放送モードは、この放送モードでＭＢＭＳをアクティブにしたり、ＭＢＭＳへ加入したりする特定の要件が存在しないという点でマルチキャストモードとは異なるものである。
【０００８】
３ＧＰＰのＭＢＭＳのマルチキャストモードは、マルチキャストエリアにおいて単一ソースポイントからマルチキャストグループヘ、マルチメディアデータ（テキスト、オーディオ、映像、ビデオなど）の片方向ポイント・ツウ・マルチポイント送信を可能にするものである。マルチキャストモードは無線／ネットワークリソースの効率的利用を意図するものであり、例えば、データは共通の無線チャネルを介して送信される。データは、ネットワークによって定義されているようにマルチキャストエリアへ送信される。マルチキャストモードでは、ネットワークが、マルチキャストグループのメンバーを含むマルチキャストエリア内のセルに対して選択的送信を行うことが可能となる。
【０００９】
ＵＥが受信したマルチキャストサービスは１以上の連続するマルチキャストセッションを含むものであってもよい。マルチキャストサービスは、例えば、（マルチメディアストリームなどの）現在進行中の単一セッションから構成される場合が考えられる。あるいは延長された期間にわたっていくつかの間欠的に生じる（メッセージなどの）マルチキャストセッションを含むものであってもよい。マルチキャストモードを利用するサービスの１例として、サッカーの結果通知サービスを挙げることも可能である。このサービスを受けるためには予約申し込みが必要となる。
【００１０】
放送モードとは異なり、マルチキャストモードは、一般にマルチキャスト予約申し込みグループに対する予約申し込みを必要とし、次いで、ユーザは対応するマルチキャストグループに加入することになる。公衆地上移動通信ネットワーク（ＰＬＭＮ）通信事業者や、ユーザや、あるいはこれらの代りにサードパーティ（会社など）がこの予約申し込みとグループへの加入とを行ってもよい。
【００１１】
インターネット技術特別調査委員会（ＩＥＴＦ）（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／）からインターネットドラフトとして入手可能な、片方向トランスポートプロトコルを介するファイル転送（ＦＬＵＴＥ）は、ＩＰ（インターネットプロトコル）ベースのネットワークを介するファイルの片方向転送用プロトコルを表わし、このプロトコルはマルチキャストネットワークに特に適している。その場合共有データが１つのＩＰベースのエンティティから複数のＩＰベースのホストへ送信される。ＦＬＵＴＥ仕様は非同期層符号化（ＡＬＣ）プロトコルで構成され、ベースをなす上記プロトコルは大規模に調整可能なマルチキャスト転送向けに設計されたものである。ＦＬＵＴＥは、数秒またはそれ以上の秒の転送セッションを用いる、多数のＩＰベースのホストへの大小のファイル転送に対して適用可能である。例えば、ＦＬＵＴＥは、多くのＩＰベースのホストへの大きなソフトウェア更新の転送に同時に利用することも可能である。ＦＬＵＴＥは、サブタイトル用の時系列テキストのような、連続し、しかもセグメント化したデータ用として利用することも可能である。
【００１２】
しかし、３ＧＰＰのＭＢＭＳに対して利用可能なＦＬＵＴＥプロトコルの（ＩＰベースのホストへ提供される）サービスを試みて、複数のパラメータが、放送／マルチキャストセッションの確立に必要となるＩＰベースのネットワークに当初配置された放送／マルチキャストコンテンツへのアクセスを無線通信システム内の移動受信機に対して行うことを意図するとき、問題が生じることになり、その場合、ＩＰベースのネットワークに配置されるソースエンティティからの共通のコンテンツは、一部はＩＰベースのネットワークを介して、さらに、一部は、少なくとも部分的に無線ネットワークの制御下にあるＦＬＵＴＥプロトコルを介して、前記移動受信機へ送信されることになり、該共通のコンテンツは移動受信機には利用できなくなる。例えば、順方向エラー修正（ＦＥＣ）と、放送／マルチキャストセッション中にコンテンツに障害が生じた場合のデータリペア機能と、輻輳状態制御処理と、マルチチャネルの利用と、ＦＬＵＴＥプロトコルによって使用されるコンテンツ記述とに関する情報を移動受信機へ提供することは現在不可能である。この結果、放送／マルチキャスト送信パスの両端でこれらの機能性が実行できなくなるという事実が生じることになる。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
無線通信システムにおける移動受信機へのＩＰ発信型共通コンテンツの特定のコンテキスト放送／マルチキャスト送信時に遭遇する上記問題から始まり、特に、前記複数台の受信機への送信セッション内における送信機から複数台の受信機への共有データの送信に関連するパラメータの通信を可能にする方法と、コンピュータプログラムと、コンピュータプログラム製品と、システムと、送信機と、受信機と、プロトコルとを提供することが本発明の一般的目的である。
【００１４】
送信セッション内において１台の送信機から複数台の受信機へ共有データを送信する方法であって、前記送信セッション内における前記共有データの前記送信に関係する少なくとも１つのセッションパラメータを通信プロトコルを介して前記複数台の受信機へ通信することと、前記送信セッション内において前記送信機から前記複数台の受信機へ前記共有データを送信することと、を備える方法が提案される。
【００１５】
前記共有データは、例えば、テキスト、オーディオ、画像並びにビデオなどの電子書式で表わすことができるすべての種類の情報を含むようにすることも可能である。前記共有データは、前記送信機から前記複数台の受信機へ同期し、かつ、連続的に送信されるストリーミングデータや非ストリーミングデータであってもよい。前記データは共有データである。すなわち同じデータが、ポイント・ツウ・マルチポイント方式で前記複数台の受信機の個々の受信機へ送信される。前記共有データの前記送信は、有線接続で、または、無線ネットワークで、あるいは、有線接続と無線ネットワークとを組み合わせた形で行うことも可能である。したがって、送信機は例えばインターネットサーバであってもよく、受信機はＩＰベースのホストであってもよい。同様に、前記受信機は無線ネットワークで作動する移動受信機であってもよい。前記受信機は同じタイプの受信機であってもよいし、異なるタイプの受信機であってもよい。前記共有データの前記送信は、制限された継続時間の送信となる場合もある送信セッション内において行われる。
【００１６】
前記少なくとも１つのセッションパラメータは前記送信セッション内における前記共有データの前記送信に関係する。前記少なくとも１つのセッションパラメータは、例えば、エラー保護、チャネル符号化、変調および／または前記共有データの前記送信用として用いられるインタリービングについて記述することも可能である。前記少なくとも１つのセッションパラメータは、受信機、共有データのコンテンツ、輻輳状態制御処理、エラー回復、あるいは共有データの正確な送受信に関係する他の任意のトピックに課せられる遅延上のあるいはメモリ上の制約に関連する情報を含むようにすることも同様に可能である。例えば、前記共有データが１乃至いくつかの受信機で正しく受信されなかった場合、したがって、リペアセッション内で少なくとも一部を再送する必要がある場合、前記共有データの前記送信に後続して求められる場合があるリペアセッションに関する情報は、前記少なくとも１つのセッションパラメータの中に含まれる場合がある。
【００１７】
前記少なくとも１つのセッションパラメータは通信プロトコルを介して前記複数台の受信機へ通信される。前記通信プロトコルは、例えば、セッション記述プロトコル（ＳＤＰ）、ファイル転送プロトコル（ＦＴＰ）、ハイパーテキスト・トランスポートプロトコル（ＨＴＴＰ）、ショートメッセージサービス（ＳＭＳ）、一般パケット無線サービス（ＧＰＲＳ）あるいは同様のプロトコルであってもよい。例えば、異なるピア内の通信プロトコルエンティティ間で交換されるプロトコルデータの単位で、前記少なくとも１つのセッションパラメータを通信するようにしてもよい。その場合、一方のピアは送信機であってもよく、他方のピアは前記複数台の受信機のうちの少なくとも１台の受信機であってもよい。前記通信プロトコルは、特に、前記少なくとも１つのセッションパラメータの通信用として指定したり、定義したりすることも可能である。
【００１８】
したがって、前記セッションパラメータを前記複数台の受信機へ通信するための前記通信プロトコルの利用によって、前記送信セッションに関する情報の前記受信機への提供が可能となる。該情報は、前記送信セッションの適切な機能にとって非常に重要なものとなるかもしれない。
【００１９】
本発明の方法によれば、前記送信セッションの確立前に、または、前記送信セッションの確立中に前記少なくとも１つのセッションパラメータを前記複数台の受信機へ通信することが望ましい。この場合、前記送信セッション内における前記共有データの前記後続する送信に関係する前記少なくとも１つのセッションパラメータがこれらの受信機に与えられる。これは、前記複数台の受信機における前記共有データの適切な受信が可能となるように十分早めに行われる。
【００２０】
本発明の方法によれば、前記通信プロトコルがセッション記述プロトコルＳＤＰであることが望ましい。
【００２１】
前記ＳＤＰは、セッション通知と、セッション勧誘と、別の形式のマルチメディアセッションの開始とを目的として、マルチメディアセッションについての記述を意図するものであってもよい。
【００２２】
前記ＳＤＰは、マルチメディア遠隔会議、ボイス・オーバーＩＰ電話、ストリーミングビデオ、あるいは他のリアルタイムセッションを開始する際に、メディアの詳細情報、トランスポートアドレス並びに他のセッション記述メタデータについて記述するための標準的表現を与えるものであってもよい。実際のマルチメディアセッションが行われる前に、前記ＳＤＰがマルチメディアセッションの参加者へ与える前記セッション記述メタデータの送信を行うことも可能である。前記ＳＤＰは、情報をトランスポートする実際の方法に依存しないものであってもよい。前記ＳＤＰは、トランスポートプロトコルが組み込まれていない純粋にセッション記述用のフォーマットであってもよく、適切なプロトコルとして異なるトランスポートプロトコルを使用してもよい。該トランスポートプロトコルには、例えば、セッション通知プロトコル（ＳＡＰ）、セッション開始プロトコル（ＳＩＰ）、リアルタイムストリーミングプロトコル（ＲＴＳＰ）、あるいはハイパーテキスト・トランスポートプロトコル（ＨＴＴＰ）が含まれる。前記ＳＤＰは、広範囲のネットワーク環境とアプリケーションとで利用できるように、汎用的プロトコルにすることを意図するものであってもよい。前記ＳＤＰは、例えば、前記送信機（またはコンテントサーバや同様のサーバのような別の例）内のＳＤＰプロトコルエンティティ、並びに、前記複数台の受信機内のＳＤＰプロトコルエンティティによって作動するようにしてもよい。前記ＳＤＰは、例えば、インターネット技術特別調査委員会（ＩＥＴＦ）によって定義されたＳＤＰであってもよい。
【００２３】
前記少なくとも１つのセッションパラメータは前記ＳＤＰを介して前記複数台の受信機へ通信される。このセッションパラメータは、例えば、前記ＳＤＰによって定義される複数の属性フィールドによって達成することも可能であり、その場合個々の属性フィールドは、１以上のセッションパラメータ情報を組み入れる能力を備えたものであってもよい。
【００２４】
本発明の方法によれば、ＩＰベースのネットワークを介して少なくとも部分的に前記送信機から前記複数台の受信機へ前記共有データを送信することが望ましい。例えば、前記送信機はインターネットサーバやインターネット内の同様の例であってもよく、さらに、前記受信機は無線通信システムの移動受信機であってもよい。該無線通信システムのコアネットワークはインターネットと接続され、したがって、前記送信機と接続されることになる。
【００２５】
本発明の方法によれば、放送時に、または、マルチキャスト処理時に前記送信機から前記複数台の受信機へ前記共有データを送信することが望ましい。いずれの場合にも、ポイント・ツウ・マルチポイント処理が行われる。
【００２６】
本発明の方法によれば、前記共有データはストリーミングデータまたは非ストリーミングデータであることが望ましい。ストリーミングデータは、例えば、ストリーミングビデオやオーディオの形で、前記送信機から前記複数台の受信機へ連続的に、かつ、同期して送信されるデータとして特徴づけられるものであってもよい。
【００２７】
本発明の方法によれば、前記共有データはリアルタイムデータまたは非リアルタイムデータであることが望ましい。
【００２８】
本発明の方法によれば、無線ネットワークを介して少なくとも部分的に前記送信機から前記複数台の受信機へ前記共有データを送信することが望ましい。例えば、前記受信機はＩＰベースのネットワークに存在する送信機と接続された無線通信ネットワーク内の移動受信機であってもよい。前記無線ネットワークは、例えば、一般移動通信システム（ＵＭＴＳ）の標準規格に準拠する移動無線通信ネットワークあるいはＩＥＥＥ８０２．１１またはＨｉｐｅｒＬＡＮ／２のような無線ローカルエリアネットワーク（Ｗ−ＬＡＮ）または衛星ベースのネットワークであってもよい。
【００２９】
本発明の方法によれば、前記無線ネットワークは、第３世代パートナプロジェクト（３ＧＰＰ）によって規定されているようなマルチメディア放送／マルチキャストサービス（ＭＢＭＳ）を少なくとも部分的に実行する移動通信ネットワークであることが望ましい。
【００３０】
本発明の方法によれば、前記通信プロトコルは、前記送信セッション内における前記共有データの前記送信用として用いられる少なくともＦＥＣ符号化方式を指定する順方向エラー修正（ＦＥＣ）属性を含むことが望ましい。
【００３１】
前記通信プロトコルの中に含まれる前記属性は、前記通信プロトコルを拡張する主要手段としてもよく、さらに、該属性を定義して“セッションレベル”属性あるいは“メディアレベル”属性、あるいは上記双方の属性として利用するようにしてもよい。前記属性はメディアストリームに関する情報を追加することも可能である。前記属性は、個々のメディアに対してというよりはむしろ全体として前記送信セッションに当てはまる追加情報をさらに送信するようにすることも可能である。属性は、プロパティ属性か、値属性かのいずれかにすることも可能である。
【００３２】
前記ＦＥＣ属性が指定する前記ＦＥＣ符号化方式は、例えば自動再送要求（ＡＲＱ）方式であってもよい。
【００３３】
本発明の方法によれば、前記ＦＥＣ属性がＦＥＣ符号化識別子をさらに指定することが望ましい。前記ＦＥＣ符号化識別子は、ＦＥＣ復号化行列またはＦＥＣバイトコードに関する情報を含むものであってもよい。
【００３４】
本発明の方法によれば、前記通信プロトコルには、ＦＥＣ復号化情報をダウンロードすることができるダウンロード元のロケーションを指定するＦＥＣマシン属性が含まれることが望ましい。
【００３５】
本発明の方法によれば、前記複数台の受信機のうちの少なくとも１台の受信機によって、ＦＥＣ復号化行列あるいはＦＥＣバイトコードのような前記ＦＥＣ復号化情報をエラーのない方法で前記ロケーションからダウンロードする必要があることが望ましい。
【００３６】
本発明の方法によれば、前記複数台の受信機のうちの少なくとも１台の受信機が、前記ＦＥＣ復号化情報をダウンロードするために、ハイパーテキスト・トランスポートプロトコル（ＨＴＴＰ）ベースの、または、トランスポート制御プロトコル（ＴＣＰ）ベースのポイント間接続を利用することが望ましい。
【００３７】
本発明の方法によれば、前記複数台の受信機のうちの少なくとも１台の受信機が、時間分散機能を用いて、前記ロケーションからの前記ＦＥＣ復号化情報のダウンロードを開始する時刻を決定したり、リペアセッションの開始時刻を決定したりすることが望ましい。この時間分散機能は、前記ロケーションからの前記ＦＥＣ情報のダウンロードを同時に試みる可能性がある受信機の数を減らしたり、あるいは、例えば、ランダムに選択される開始時刻を前記ダウンロード用として規定したりすることによってリペアセッションを実行したりすることも可能である。
【００３８】
本発明の方法によれば、前記通信プロトコルは、前記送信セッション時における前記送信機から前記複数台の受信機への前記共有データの送信中、前記複数台の受信機に課せられるバッファ処理要件を指定するＦＥＣバッファ属性を含むことが望ましい。
【００３９】
本発明の方法によれば、前記バッファ処理要件はバッファ遅延および／またはバッファ処理用メモリサイズであることが望ましい。
【００４０】
本発明の方法によれば、前記通信プロトコルは、前記送信セッション内における前記共有データの前記送信用として用いられる輻輳状態制御方式を指定する輻輳状態制御属性を含むことが望ましい。
【００４１】
本発明の方法によれば、前記複数台の受信機のうちの少なくとも１台の受信機において前記共有データが正しく受信されなかった場合、リペアセッション内でリペアサーバから前記少なくとも１台の受信機へ少なくとも前記共有データの一部を送信することが望ましい。
【００４２】
本発明の方法によれば、前記複数台の受信機のうちの前記少なくとも１台の受信機が、時間分散機能を用いて前記リペアセッションの開始時刻を決定することが望ましい。
【００４３】
本発明の方法によれば、前記リペアセッションがポイント間リペアセッションまたはポイント・ツウ・マルチポイントリペアセッションであることが望ましい。
【００４４】
本発明の方法によれば、前記通信プロトコルが、前記リペアサーバのＵＲＩを指定するリペアユニフォームリソース識別子（ＵＲＩ）属性を含むことが望ましい。
【００４５】
本発明の方法によれば、前記通信プロトコルがエラーしきい値を指定するリペアしきい値属性を含み、さらに、前記エラーしきい値が、前記送信セッションで前記送信機から前記複数台の受信機によって受信されるような前記共有データの受信品質に関係することが望ましい。前記エラーしきい値は、例えば、パケット当たりの、または、時間当たりのビットエラーの最大許容数を定量化することも可能である。
【００４６】
本発明の方法によれば、前記複数台の受信機のうちの少なくとも１台の受信機によって前記リペアセッションの中へ入るステップが、前記送信セッション内において前記送信機から前記受信機によって受信されるような前記共有データの受信品質と、前記エラーしきい値と間の関係に依存することが望ましい。例えば、前記受信機が、３００秒のウィンドウの中で１０バイトのエラーと共に、前記送信セッション中に前記共有データを受け取った場合、かつ、リペアセッションを開始するために、３００秒のウィンドウにおいて１バイトのエラーのみが許容されることが前記エラーしきい値によって言明されている場合、前記受信機は前記リペアセッションに入ることを控えるようにすることも可能である。
【００４７】
本発明の方法によれば、エラー単位と、エラー値と、測定ウィンドウの単位と、測定ウィンドウ値という点から前記エラーしきい値の定量化を行うことが望ましい。前記エラー単位は、例えばバイト、ビット、パケットあるいは割合であってもよく、前記エラー値は実数値であってもよく、前記ウィンドウ単位は、例えば秒、パケット、ビットあるいはバイトであってもよく、前記ウィンドウ値は実数値であってもよい。このようにして定量化されたエラーしきい値の例は、したがって、３００秒のウィンドウでのエラーを含む１０バイトや同様の組み合わせであってもよい。
【００４８】
本発明の方法によれば、エラー値という点から前記エラーしきい値を定量化することが望ましい。例えば、０．０１などの実数のエラー値によって前記エラーしきい値を指定することも可能である。このとき、エラー単位、測定ウィンドウの単位および測定ウィンドウ値は例えば予め定義したものであってもよい。
【００４９】
本発明の方法によれば、前記送信セッション用として複数のエラーしきい値を利用し、さらに、前記エラーしきい値に対して明示的にあるいは暗黙のうちにラベリングを施すことが望ましい。前記エラーしきい値は、例えば整数を用いて明示的ラベリングを施し、第１、第２などのエラーしきい値を識別できるようにしてもよい。同様に、例えば、エラーしきい値をその値に従ってソートするように規定することによって前記エラーしきい値に固有のラベリングを施し、次いで、最低または最高のエラーしきい値から始めて昇順の（或いは降順の）ソートでラベリングを施すようにしてもよい。例えば、リペアセッションを求める要求が開始できるようになるまで受信機がどのくらいの時間待機する必要があるかについて記述できるような異なるバックオフモードがサポートされているとき、そして、個々のエラーしきい値がそれぞれのバックオフモードに対応しているとき、特に、エラーしきい値のラベリングは利点を有するものとなる。この時、受信エラーの大きさに応じて、受信機がリペアセッションの中へ入る動作を制御して、例えば、大きな受信エラーを有する受信機が最初にあるいは最後に前記リペアセッションの中に入るようにすることが可能となる。
【００５０】
本発明の方法によれば、前記通信プロトコルがバックオフモード属性を含み、前記送信セッション内において前記送信機から前記共有データを正しく受信しなかった受信機が前記リペアセッションを求める要求を開始できる時点に関する情報を該バックオフモード属性が提供することが望ましい。
【００５１】
本発明によれば、前記通信プロトコルがバックオフモードを指定するバックオフモード属性を含み、前記送信セッション内において前記送信機から前記共有データを正しく受信しなかった受信機が前記リペアセッションを求める要求を開始できる時点に関する情報を前記バックオフモードが提供し、前記送信セッション用として複数のバックオフモードを利用し、さらに、前記エラーしきい値のうちの少なくとも１つのエラーしきい値を前記バックオフモードのうちの少なくとも１つのバックオフモードとそれぞれリンクさせることが望ましい。次いで、例えば個々のエラーしきい値をそれぞれのバックオフモードとリンクさせるようにすることも可能である。例えば、上記エラーしきい値と上記バックオフモードの双方のラベリングにより上記リンクを行って、対応するラベルがリンクを表わしていることが解るようにすることも可能である。
【００５２】
本発明によれば、前記送信セッション中に受信機が受信するような前記共有データの受信品質と、前記エラーしきい値によって要求されるような受信品質との間の関係に依存して、前記バックオフモードを前記受信機に割り当てることが望ましい。前記共有データの受信中に前記送信セッション内においての受信機によって経験されるエラー比率、および、前記エラーしきい値と前記バックオフモード間での上記リンク付けに基づいて、バックオフモードを前記受信機に割り当てることが可能となる。このようにして、例えば、（第１のエラーしきい値以上の）高いエラー比率を有する受信機は第１のバックオフモードに割り当てられ、第１のエラーしきい値未満で、かつ、第２のエラーしきい値以上の低いエラー比率を有する受信機が第２のバックオフモードに割り当てられる。次いで、第２のバックオフモードの受信機がこのようにしてサービス品質（ＱｏＳ）の制御を処理する前に、または、サービス品質（ＱｏＳ）の制御を処理した後で第１のバックオフモードの受信機は送信許可を与えるようにすることも可能である。
【００５３】
本発明の方法によれば、バックオフ単位と、バックオフ値と、バックオフウィンドウとによって前記情報を表わすことが望ましい。前記バックオフ単位は、例えば、相対時間（秒）、絶対ネットワークタイムプロトコル（ＮＴＰ）時間、バイト、ビットまたはパケットであってもよい。前記バックオフ値は例えば実数値であってもよい。前記バックオフウィンドウは、例えば、前記バックオフ単位によって指定されたものと同じ単位になる場合もある単位を持つ実数値であってもよい。前記情報は絶対時間ベースまたは相対時間ベースと関係するものであってもよい。一例として、前記バックオフ単位が秒の場合、前記バックオフ値は６０秒になり、前記バックオフウィンドウは１２０となる。これによって、受信機は、送信セッションの終了から６０と１８０（＝６０＋１２０）秒との間でリペアセッションを求める要求を開始してもよいことを示すことが可能となる。この場合、例えば、均一な配分に基づいて６０秒と１２０秒との間の前記インタバルから前記開始時刻をランダムに選択することが可能となる。
【００５４】
本発明の方法によれば、絶対タイミングを使用しているか、相対タイミングを使用しているかを示す変数と、時間値とによって前記情報を表わすことが望ましい。例えば、絶対タイミングが使用されていることが前記変数によって示されている場合、前記時間値は、リペアセッションを求める要求の開始が可能な絶対ＮＴＰ時間を指定するものであってもよい。（あるいは、該絶対ＮＴＰ時間周辺でまたは絶対ＮＴＰ時間を起点として開始時刻をランダムに選択することも可能である）。上記とは別に、相対タイミングが使用されていることを前記変数が示す場合、例えば、送信セッションの終了から始まり、前記時間値が示すような継続時間後に終了するインタバルで前記要求をランダムに開始することも可能である旨を前記時間値によって指定することができる。前記時間値は、リペアの利用が可能な最長時間、リペア処理が可能となるまでの時間として定義することも可能であり、次いで、該時間値をＮＴＰ時間で好適に表現して、いわゆるレージィ・リペア（ｌａｚｙ  ｒｅｐａｉｒ）を作動可能にすることも可能である。
【００５５】
本発明の方法によれば、前記情報がエラーしきい値と３つの値Ｘ、Ｙ、Ｚとを含み、さらに、前記複数台の受信機のうちの少なくとも１台の受信機において、前記送信セッション内において前記送信機から前記少なくとも１台の受信機によって受信されるような前記共有データの受信品質が、前記エラーしきい値が決定する受信品質よりも良好な品質である場合、継続時間Ｘのタイムインタバルの範囲内で前記リペアセッションを求める前記要求をランダムに開始し、前記送信セッションの終了時に前記インタバルが開始し、そうでない場合には、Ｙと、Ｙ＋Ｚとの間の時間の範囲内で前記リペアセッションを求める前記要求をランダムに開始し、前記送信セッションの終了からＹをカウントすることが望ましい。
【００５６】
本発明の方法によれば、前記通信プロトコルを用いて前記複数台の受信機数を前記複数台の受信機へ通信できることが望ましい。前記リペアセッション用バックオフタイムを検出する際に、前記受信機は受信機数に関する情報を好適に利用することも可能である。
【００５７】
本発明の方法によれば、前記通信プロトコルがリペアタイプパラメータ属性を含み、該リペアタイプパラメータ属性によって、前記リペアセッションをポイント間セッションとするか、ポイント・ツウ・マルチポイントセッションとするか、あるいは、上記双方のセッションとすることができるかどうかが指定されることが望ましい。
【００５８】
本発明の方法によれば、前記通信プロトコルが、前記リペアセッションのタイプを指定するリペアトークン属性を含むか、前記送信セッション内において前記複数台の受信機のうちの少なくとも１台の受信機において正しく受信されない前記共有データのどの部分が、前記リペアセッション内で前記リペアサーバから前記少なくとも１台の受信機へ送信されるかに関する情報を含むか、あるいは、上記双方を含むことが望ましい。前記部分に関する前記情報は、例えば、ファイル識別子、ソースブロック数（ＳＢＮ）および／または前記共有データの符号化用シンボルＩＤ（ＥＳＩ）またはこれらの値に基づく対あるいは範囲を指定するものであってもよい。
【００５９】
本発明の方法によれば、前記通信プロトコルがコンテンツ記述属性を含み、前記共有データのコンテンツに関する記述が格納されているＵＲＩを前記送信機が前記複数台の受信機に示す方法が該コンテンツ記述属性によって指定されることが望ましい。前記ＵＲＩは、例えば、ファイル転送テーブル（ＦＤＴ）ＸＭＬスキーマのような拡張型マークアップ言語（ＸＭＬ）方式や、インターネットメディア・ガイド（ＩＭＧ）データモデルへのエントリポイント、あるいは別のエントリ・ポイントスキーマやモデルであってもよい。
【００６０】
本発明の方法によれば、前記送信機から前記複数台の受信機への前記共有データの前記送信が、片方向トランスポートプロトコルを介するファイル転送（ＦＬＵＴＥ）によって少なくとも部分的に制御されることが望ましい。前記ＦＬＵＴＥは、インターネットを介してファイルの片方向転送を行うためのプロトコルを表わすことも可能である。該片方向転送用プロトコルはマルチキャストネットワークに特に適したものとなる可能性がある。前記ＦＬＵＴＥプロトコルは、非同期層符号化（ＡＬＣ）をベースとするものであってもよい。
【００６１】
本発明の方法によれば、前記送信セッション内において前記複数台の受信機へ前記共有データを送信するために送信機が使用するチャネル数を指定するＦＬＵＴＥチャネル属性が前記通信プロトコルの中に含まれることが望ましい。
【００６２】
本発明の方法によれば、前記通信プロトコルが、前記送信セッション内においてＴＳＩの値を指定するＦＬＵＴＥ送信セッションＩＤ  ＴＳＩ属性を含むことが望ましい。
【００６３】
本発明の方法によれば、前記通信プロトコルは、前記送信セッション内において使用メディアを指定するメディア記述を含むことが望ましい。このメディア記述は“ｍライン”と呼ばれる場合もある。例えば、前記メディアは、オーディオ、ビデオ、アプリケーション、データ並びに制御処理であってもよい。前記メディア記述は、例えば、ユーザデータグラムプロトコル（ＵＤＰ）を介してＦＬＵＴＥを利用するチャネルでのビデオデータのトランスポートについて記述するものであってもよい。
【００６４】
本発明の方法によれば、前記通信プロトコルが、前記送信セッション内において使用チャネルのアドレスを指定する接続データを含むことが望ましい。この接続データは“ｃライン”と呼ばれる場合もある。前記接続データは、ネットワークタイプ、アドレスタイプ並びに接続アドレスを含むことも可能である。したがって、この接続データは例えばＩＰｖ６アドレスを示すことも可能となる。
【００６５】
上記方法ステップをプロセッサに実行させるように作動可能なコンピュータプログラムがさらに提案される。例えば、前記送信機、受信機あるいは上記双方の中に前記プロセッサを組み込むようにしてもよい。
【００６６】
上記方法ステップをプロセッサに実行させるように作動可能な命令を含むコンピュータプログラムを備えるコンピュータプログラム製品がさらに提案される。
【００６７】
データを送信するシステムであって、該システムが、少なくとも１台の送信機と、複数台の受信機とを備え、前記少なくとも１台の送信機と、前記複数台の受信機とが、前記送信セッション内における前記共有データの前記送信に関係する少なくとも１つのセッションパラメータを、前記少なくとも１台の送信機から前記複数台の受信機へセッション記述プロトコル通信プロトコルを介して通信するように構成された手段を備え、さらに、前記少なくとも１台の送信機と、前記複数台の受信機とが、前記送信セッション内において前記送信機から前記複数台の受信機へ前記共有データを送信するように構成された手段を備えるシステムが提案される。
【００６８】
さらにまた、送信セッション内において複数台の受信機へ共有データを送信する送信機であって、該送信機が、前記送信セッション内における前記共有データの前記送信に関係する少なくとも１つのセッションパラメータを、セッション記述プロトコル通信プロトコルを介して前記複数台の受信機へ通信するように構成された手段と、前記送信セッション内において前記複数台の受信機へ前記共有データを送信するように構成された手段とを備える送信機が提案される。
【００６９】
さらにまた、送信セッション内において１台の送信機から複数台の受信機へ送信される共有データを受信する受信機であって、該受信機が、前記送信セッション内における前記共有データの前記送信に関係する少なくとも１つのセッションパラメータであって、セッション記述プロトコル通信プロトコルを介して前記複数台の受信機へ通信される少なくとも１つのセッションパラメータを受信するように構成された手段と、前記送信セッション内において前記送信機から前記複数台の受信機へ送信される前記共有データを受信するように構成された手段とを備える受信機が提案される。
【００７０】
さらにまた、送信セッション内における送信機から複数台の受信機への共有データの送信に関係する少なくとも１つのセッションパラメータの定義を含むセッション記述プロトコルが提案される。
【００７１】
本発明のこれらの局面およびその他の局面は、本明細書で後述する実施形態から明らかにされ、該実施形態を参照しながら解明される。
【発明を実施するための最良の形態】
【００７２】
本発明は、ポイント・ツウ・マルチポイント接続を経由して送信機から共有データを受信する複数台の受信機へセッションパラメータを通信するための通信プロトコルの利用を提案するものである。本発明の範囲を限定するものではない以下の説明では、通信プロトコルに関連するような例として、上記目的のためにセッション記述プロトコルＳＤＰを利用することにする。この目的のために、前記ＳＤＰには、前記セッションパラメータの通信処理のために定義される属性と、メディア記述と、接続データとが含まれる。以下では、インターネット・エンジニアリング・タスクフォース（ＩＥＴＦ）が定義しているような片方向トランスポートプロトコルを介するファイル転送（ＦＬＵＴＥ）により制御されるセッションに対して第３世代パートナプロジェクト（３ＧＰＰ）マルチメディア放送／マルチキャストサービスを提供するシステムに関連する例として、これらのＳＤＰコンポーネントの定義を示すことにする。上記システムに対する本発明の適用および以下のコンポーネント定義は、決して、この特定のアプリケーションに本発明の範囲を限定することを意図するものではないことに留意されたい。コンポーネントは、拡張バッカス・ナウア記法（ＡＢＮＦ）シンタックス記述フォーマットに基づいて定義される。
【００７３】
１．ＦＥＣパラメータ
順方向エラー修正（ＦＥＣ）属性は、使用するＦＥＣ符号化方式について記述するものである。ＦＥＣ属性はＦＥＣ符号化識別子（および使用するＦＥＣ符号化方式との関連付け）についても記述する。例えば、ＩＥＴＦ  ＦＬＵＴＥプロトコルのドラフトでは、ＦＬＵＴＥプロトコル用のＦＥＣ符号化ＩＤが与えられる。ＦＥＣ符号化方式と関連づけられたマルチ符号化用識別子が存在する場合もある。
【００７４】
本発明に基づくＦＥＣ属性に関連するシンタックスの例を下記に示す：
ａ＝ＦＥＣ−Ｉｎｆｏ：“｛”ｖａｌｕｅ＊（“，”ｖａｌｕｅ）“｝”  ＣＲＬＦ
但し、
ｖａｌｕｅ＝ｖａｌｕｅ−ｓｉｎｇｌｅ／ｖａｌｕｅ−ｃｏｕｐｌｅ
ｖａｌｕｅ−ｓｉｎｇｌｅ＝％ｄ０−１２７
ｖａｌｕｅ−ｃｏｕｐｌｅ＝“｛”％ｄｌ２８−２５５“，”％ｄ０−２５５“）”
【００７５】
上式で、ｖａｌｕｅは使用するＦＥＣ符号化方式を表わす数値である。ｖａｌｕｅ−ｓｉｎｇｌｅはＦＥＣ符号化方式（本例では０と１２７との間の値を有する）を表わす。ｖａｌｕｅ−ｃｏｕｐｌｅは（ＦＥＣ符号化方式とＦＥＣ符号化用ＩＤ）の対（本例ではＦＥＣ符号化方式用として１２８と２５５との間の値、および、符号化用ＩＤ用として０と２５５との間の値をそれぞれ有する）を表わす。
【００７６】
ＦＥＣ属性はセッションレベル専用属性であることが望ましい場合もある（但し、このＦＥＣ属性をメディアレベル属性として利用することを除外するものではない）。
【００７７】
示されたｖａｌｕｅ−ｓｉｎｇｌｅとｖａｌｕｅ−ｃｏｕｐｌｅの例を上記好ましいシンタックスとすることも可能である。しかし、ｖａｌｕｅ−ｓｉｎｇｌｅ＝％ｄ０−２５５またはｖａｌｕｅ−ｃｏｕｐｌｅ＝“｛”％ｄ０−２５５“，”％ｄ０−２５５“）”のような別のオプションも本発明の範囲に属するものである。
【００７８】
このような属性がＳＤＰ記述子の間に存在しない場合、これは、ＦＥＣが記述子によって使用されていないことを示している可能性がある（例えば、ＩＥＴＦ  ＦＬＵＴＥプロトコルのドラフトに記載されているように、Ｃｏｍｐａｃｔ  ＮＯＣＯＤＥ  ＦＥＣが使用されている）。これは記述子ａ＝ＦＥＣ−Ｉｎｆｏ：｛０｝の使用に相当する。
【００７９】
本発明に基づくＦＥＣ属性の利用例として下記がある：
ａ＝ＦＥＣ−Ｉｎｆｏ：｛０，６４，１２７，（１２８，３），（１２８，４），（１２９，３）｝
【００８０】
上記例ではマルチＦＥＣ  ＩＤが用いられていることが送信機によって示されている。数字０，６４、１２７等々はこれらのＦＥＣ  ＩＤを示す。送信機は、これらのＦＥＣ  ＩＤをＦＬＵＴＥセッションの特定のチャネルに対応づける必要はない。
【００８１】
本発明に基づくＦＥＣ属性の別の利用例として下記がある：
ａ＝ＦＥＣ−ｉｎｆｏ：｛０｝
【００８２】
受信機に対応する上記例では、送信機がＣｏｍｐａｃｔ  ｎｏ  ｃｏｄｅ  ＦＥＣを利用していることが示されている。上記パラメータのみを用いてＦＥＣ  ＩＤ０〜１２７（これらは全部指定される）を示すようにすることも可能である。しかし、２つのパラメータを用いてＦＥＣ  ＩＤ０〜１２７を使用することも可能である旨を明示するように送信機を選択することも可能である。例えば、ａ＝ＦＥＣ−Ｉｎｆｏ：｛（０，０）｝は、ＦＥＣ  ＩＤ０とＦＥＣインスタンス０について記述するものである（但し、インスタンス情報はＦＥＣ  ＩＤ０〜１２７用のベストモードでは冗長な情報となる）。
【００８３】
有効なＦＥＣ符号化用ＩＤ０〜１２７の唯一の単一（ＦＥＣ符号化用ＩＤ）パラメータの制限はＡＬＣバージョン１によって指定される。しかし、ＦＥＣ符号化用ＩＤ０〜１２７に対応する多くの受信機用の第２パラメータ（ＦＥＣインスタンスＩＤ）の利用もまた本発明に基づいて予見が可能であり、それによって信号送信が可能な全指定されたＦＥＣ方式の数のさらなる拡張を図ることが可能となる。
【００８４】
２．ＦＥＣマシンパラメータ
一般的なＦＥＣマシン（すなわち、セッションの開始前にＦＥＣ方式またはＦＥＣ復号化行列の受信機へのダウンロードが可能なシステム）を使用する場合、送信機は、受信機からダウンロードすべきＦＥＣ復号化行列の正確なロケーションまたはＦＥＣバイトコードを信号で送信して、マルチキャスト／放送チャネルで送信するデータの復号化を図るようにしなければならない。
【００８５】
上記データのダウンロードは、好適にはＨＴＴＰ／ＴＣＰポイント間接続を介してエラーのない方法で好適に行われる（但しこれらのみに限定されるわけではない）。バイトコードまたはＦＥＣ行列が受信機へ転送されない場合、受信機がマルチキャスト／放送セッション内で共有データを正しく受信することが困難となる場合がある。
【００８６】
本発明によれば、送信機はＳＤＰセッションの通知中に、したがってセッションが開始する前にＦＥＣファイルのロケーションを信号で送信することも可能である。受信機がセッションの開始前にエラーのないＦＥＣファイルをフェッチして、システムがデータの復号化を準備するようにすると好都合となる場合もある。ＦＥＣファイルのダウンロードを求める多くの受信機の要求に起因して生じるネットワークの過負荷を避けるために、受信機はランダムに選択される開始時刻を用いてこのポイント間ダウンロードを開始することも可能である。例えば、タイム０（前記ＳＤＰを介してセッション記述が受信された時点）と、同じセッション記述の中に含まれる（第１）ｔパラメータ値でセッション開始時刻として示される時点との間で、受信機によって上記時刻の計算を行うことも可能である。
【００８７】
本発明に基づくＦＥＣマシン属性に関連するシンタックスの例を下記に示す：
ａ＝ＦＥＣ−ｍａｃｈｉｎｅ：ＦＩＬＥ−ＩＤ
但し、
ＦＩＬＥ−ＩＤ＝＜”＞ｔｅｘｔｓｔｒｉｎｇ＜”＞
ｔｅｘｔｓｔｒｉｎｇ＝１＊（（０ｘ０１．．０ｘ０９）／０ｘ０ｂ／０ｘ０ｃ／０ｘ０ｅ．．０ｘ２１）
／（０ｘ０２３．．０ｘｆｆ））
；ＮＵＬ，ＣＲ，ＬＦ，‘”’以外の任意のバイト
【００８８】
上記ＦＥＣマシン属性はセッションレベル専用属性とすることが望ましい場合もある。しかし、メディアレベル属性として上記ＦＥＣマシン属性を利用することは除外されていない。
【００８９】
マルチＦＥＣマシン属性定義（すなわちａ＝ＦＥＣ−ｍａｃｈｉｎｅ  ｌｉｎｅｓ）が設けられている場合がある。このケースでは、時間領域においてだけでなく、マルチＦＥＣマシンロケーションに基づいても受信機をランダムに選択することが可能となる。
【００９０】
本発明に基づくＦＥＣマシン属性の利用例を下記に示す：
ａ＝ＦＥＣ−ｍａｃｈｉｎｅ：“ｈｔｔｐ：／／ｗｗｗ．ｆｅｃ．ｃｏｍ／ｍａｔｒｉｘ．ｆｅｃ”
本例では受信機は上記アドレスからＦＥＣ行列ファイルをフェッチする。
【００９１】
３．ＦＥＣバッファ処理用パラメータ
ＦＥＣバッファ処理属性は、マルチキャスト／放送データストリームの受信時に、受信機に対してＦＥＣ符号化方式により課される要件または制約について記述するものである。これらの制約は、例えば、第１パラメータの点から追加遅延（すなわち、ミリ秒の時間で表現される待ち時間）および／または第２のパラメータメモリ要件（すなわち、ＦＥＣ復号化を行うために受信機側で必要となるバイト数）とすることも可能である。
【００９２】
上記第１のパラメータは、（マルチキャストメディア・ストリーミングセッションのような）リアルタイムのセッションに対して適用可能であることが望ましい。この第１のパラメータを用いてリアルタイムの休止のないＦＥＣ符号化メディアデータの復号化並びに受信機側での再生を保証することが可能となる。
【００９３】
第２のパラメータは、リアルタイムのセッションに対して適用可能であることが望ましいが、（ファイルダウンロードセッションなどの）非リアルタイムのセッションに対しても適用可能であることが望ましい。受信機は上記第２のパラメータを用いて、セッション要件に対してその端末装置機能を判別し、十分なメモリ量を割り当てて、効率のよいＦＥＣデータの復号化を可能にすることも可能である。
【００９４】
双方のパラメータはセッションレベルの専用属性にすることが望ましい場合がある。しかし、メディアレベル属性としての上記双方のパラメータの利用が除外されるわけではない。
【００９５】
双方のパラメータがＦＥＣバッファ処理属性の中に存在することが要求されない場合もある。また、使用するＦＥＣ符号化方式を示すことによって、以前のＦＥＣ属性に対する参照符号を作成してもよい。
【００９６】
本発明に基づくＦＥＣバッファ処理属性に関連するシンタックスの例を下記に示す：
ａ＝ＦＥＣ−Ｂｕｆ：“｛”（ｓｃｈｅｍｅ−ｖａｌｕｅ）“，”０＊１（ｄｅｌａｙ−ｖａｌｕｅ）”，”０＊１（ｍｅｍｏｒｙ−ｖａｌｕｅ）“｝”ＣＲＬＦ
但し、
ｓｃｈｅｍｅ−ｖａｌｕｅ＝％ｄ
ｄｅｌａｙ−ｖａｌｕｅ＝％ｄ
ｍｅｍｏｒｙ−ｖａｌｕｅ＝％ｄ
【００９７】
本発明に基づくＦＥＣバッファ処理属性の利用例を後編で示すことにする。
【００９８】
例１：
ａ＝ＦＥＣ−Ｂｕｆ：｛１２７，５００，１００００００｝
本例では、送信機は、ＦＥＣ方式１２７が５００ｍｓの遅延を生成し、１００００００バイトのメモリを要求することを受信機に対して命じる。
【００９９】
例２：
ａ＝ＦＥＣ−Ｂｕｆ：｛１２７，５００，  ｝
本例では、メモリ要件パラメータが欠落している。
【０１００】
例３：
ａ＝ＦＥＣ−Ｂｕｆ：｛１２７，  ，１００００００｝
本例では、遅延パラメータが欠落している。
【０１０１】
４．輻輳状態制御用パラメータ
輻輳状態制御属性は、使用する輻輳状態制御方式について記述するものである。
【０１０２】
本発明に基づく輻輳状態制御属性に関連するシンタックスの例を下記に示す：
ａ＝Ｃｏｎｇｅｓｔｉｏｎ−Ｃｏｎｔｒｏｌ−ＩＤ：ｖａｌｕｅ  ＣＲＬＦ
但し、
ｖａｌｕｅ＝％ｄ／＜”＞ｔｅｘｔｓｔｒｉｎｇ＜”＞
ｔｅｘｔｓｔｒｉｎｇ＝１＊（（０ｘ０１．．０ｘ０９）／０ｘ０ｂ／０ｘ０ｃ／
（０ｘ０ｅ．．０ｘ２１）
／（０ｘ０２３．．０ｘｆｆ））
；ＮＵＬ，ＣＲ，ＬＦ，‘”’以外の任意のバイト
【０１０３】
上式で、ｖａｌｕｅは、使用する輻輳状態制御方式を表わす数値または英数字値であってもよい。このｖａｌｕｅはセッションレベルの専用属性とすることも可能である。
【０１０４】
５．リペアパラメータ
これらのリペアパラメータはセッションレベルの専用属性とすることが望ましい場合がある。しかし、メディアレベル属性としての上記リペアパラメータの利用が除外されるわけではない。以下の説明では、リペアパラメータに関係する４つの属性を例示として定義することにする。
【０１０５】
５．１  リペアサーバのＵＲＩ
リペアサーバ属性のＵＲＩはポイント間リペアセッションまたはポイント・ツウ・マルチポイントリペアセッションを確立するために受信機が使用すべきリペアサーバのアドレスについて記述するものである。
【０１０６】
本発明に基づくリペアＵＲＩ属性に関連するシンタックスの例を下記に示す：
ａ＝ｒｅｐａｉｒ−ＵＲＩ：“ｕｒｉ＝”＜“＞ＵＲＩ＜”＞ＣＲＬＦ
但し、
ＵＲＩ＝コメント募集（ＲＦＣ）ドキュメント２３９６に定義されているもの
【０１０７】
上式で、ＵＲＩは、リペアセッションを確立するために受信機が利用可能なリペアサーバに対応する有効なＵＲＩである。
【０１０８】
セッションレベルで“ａ＝ｒｅｐａｉｒ−ＵＲＩ”属性のいくつかのインスタンスが存在することも可能である。クライアントは以下の基準に基づいて適切なサーバを選択することも可能である：
−サーバのＩＰ領域（ネットワークトポロジ様の最も近いリペアサーバなど）、または
−ランダム選択
【０１０９】
本発明に基づくリペアＵＲＩ属性の利用例として下記がある：
ａ＝ｒｅｐａｉｒ−ＵＲＩ：ｕｒｉ＝“ｗｗｗ．ｒｅｐａｉｒｓｅｒｖｅｒ．ｃｏｍ”
【０１１０】
上記例では、送信機は、セッション全体が正しく受信されなかった場合にポイント間リペアセッションを確立できるようにするために受信機が利用すべきリペアサーバを示す。
【０１１１】
５．２  エラー率リペアしきい値
エラー率リペアしきい値に関係するＳＤＰ属性の定義には以下に説明するように２つの局面が含まれる。
【０１１２】
５．２．１  第１の局面：４つの値の利用
エラー率リペアしきい値属性は、その値を越えると受信機がリペア要求を要求すべきでないしきい値について記述することも可能である。
【０１１３】
リペアしきい値シンタックスに関連するシンタックスの例を下記に示す：
ａ＝ｒｅｐａｉｒ−ｔｈｒｅｓｈｏｌｄ：“（”ｖａｌｕｅ１“，”ｖａｌｕｅ２“，”ｖａｌｕｅ３“，”ｖａｌｕｅ４“）”
但し、
ｖａｌｕｅ１＝％ｄ
ｖａｌｕｅ２＝％ｄ／ｆｌｏａｔ−ｖａｌｕｅ
ｖａｌｕｅ３＝％ｄ
ｖａｌｕｅ４＝％ｄ／ｆｌｏａｔ−ｖａｌｕｅ
ｆｌｏａｔ−ｖａｌｕｅ＝１＊ＤＩＧＩＴ［“．”１＊ＤＩＧＩＴ］
【０１１４】
上式で、ｖａｌｕｅ１はエラー率しきい値用として使用するエラー単位である。この目的のために利用できる値の例は以下になる：
ｖａｌｕｅ１＝０；バイト（毎秒）
ｖａｌｕｅ１＝１；ビット（毎秒）
ｖａｌｕｅ１＝２；パケット（毎秒）
ｖａｌｕｅ１＝３；（紛失バイトまたは紛失パケットなどの）割合（毎秒）
【０１１５】
上記エラー単位の別の値も可能である。例えば、同じエラー単位が“毎秒”表示なしで定義される場合もある：
ｖａｌｕｅ１＝０；バイト
ｖａｌｕｅ１＝１；ビット
ｖａｌｕｅ１＝２；パケット
ｖａｌｕｅ１＝３；（紛失バイトまたは紛失パケットなどの）割合
【０１１６】
ｖａｌｕｅ２はエラー値である。例えば、１０分、２００万バイトあるいは３０パケットなどの値を上記エラー値用として利用することができる。このパラメータはユーザによって定義されることが望ましい。
【０１１７】
ｖａｌｕｅ３は測定ウィンドウの単位である。この目的のために利用することが可能な値の１例として下記がある：
ｖａｌｕｅ３＝０；測定ウィンドウの単位は秒である。
ｖａｌｕｅ３＝１；測定ウィンドウの単位はパケットである。
ｖａｌｕｅ３＝２；測定ウィンドウの単位はビットである。
ｖａｌｕｅ３＝３；測定ウィンドウの単位はバイトである。
【０１１８】
ｖａｌｕｅ４は測定ウィンドウ値の量である。このパラメータは測定ウィンドウ値について記述するものである。例えば、ｖａｌｕｅ３＝０かつｖａｌｕｅ４＝４の場合、これは４秒の測定ウィンドウを示すことになる。
【０１１９】
したがって、“毎秒”表示を用いる場合、ｖａｌｕｅ１＝０、ｖａｌｕｅ２＝１０、ｖａｌｕｅ３＝０、ｖａｌｕｅ４＝３００であれば、これは、しきい値が３００秒のウィンドウで毎秒１０バイトのエラー値であることを意味することになる。このしきい値を上回るエラー値が認められた場合、必要に応じて反応するように受信機を義務づけるようにすることも可能である。
【０１２０】
また、“毎秒”表示を用いない場合も、ｖａｌｕｅ１＝０、ｖａｌｕｅ２＝１０、ｖａｌｕｅ３＝０、ｖａｌｕｅ４＝３００であれば、これは、しきい値が３００秒のウィンドウで１０バイトのエラー値であることを意味することになる。このしきい値を上回るエラー値が認められた場合、必要に応じて反応するように受信機を義務づけるようにすることも可能である。
【０１２１】
マルチエラーしきい値を用いる好適な処理では、最も困難なエラーしきい値基準（すなわち、最小のエラー率しきい値）から、最も困難でないエラーしきい値基準（すなわち最大のエラー率しきい値）に従って増分する順序（０，１，２，．．ｎ）でこれらのしきい値に暗黙のうちにラベルを施すようにしてもよい。このようにして、（毎秒０．０００００１ビットのしきい値未満などの）最大エラー比率未満のエラー比率を伴う受信経験をエラー比率０として特定し、（毎秒０．０００００１よりも大きく０．０１ビット未満などの）次の最も困難な基準を伴う受信経験をエラー比率１として特定する等々を行い、最後に、（すべてのしきい値を上回る）最も困難でない受信基準が“エラー比率ｎ”を得ることになる。上記ラベリングに従って、指定しきい値の数がｎ＋１となり、これを不変量とすることも可能であることに留意されたい。このバーチャルラベリングの重要性は、採用できる可能性のある異なるバックオフモードにエラーしきい値を対応づけることである。
【０１２２】
いずれの当業者にとっても、ｖａｌｕｅ１、ｖａｌｕｅ２、ｖａｌｕｅ３、ｖａｌｕｅ４のいくつかの列挙が可能であり、この列挙が本発明の範囲内に属することは明らかである。例えば、ｖａｌｕｅ３＝０（測定ウィンドウの単位がパケットの中にある）；ｖａｌｕｅ３＝１（測定ウィンドウの単位は秒である）は上記の例に対する別の列挙である。
【０１２３】
４つの組からなるいくつかの値を設けてもよいことに注意することが重要である。１例として、ａ＝ｒｅｐａｉｒ−ｔｈｒｅｓｈｏｌｄ：“（Ａ，Ｂ，Ｃ，Ｄ）（Ｗ，Ｘ，Ｙ，Ｚ）”がある。別例として、ａ＝ｒｅｐａｉｒ−ｔｈｒｅｓｈｏｌｄ：“（Ｗ，Ｘ，Ｙ，Ｚ）”が後続するａ＝ｒｅｐａｉｒ−ｔｈｒｅｓｈｏｌｄ：“（Ａ，Ｂ，Ｃ，Ｄ）”がある。これによって、ホストはマルチしきい値を理解することが可能となる。マルチしきい値を用いる推奨実施形態では、以下さらに詳細に説明するように、しきい値はバックオフモードとリンクすることも可能である。上記を行うシンプルで、エレガントな方法として、上記４組の値の順序が受信機の振舞いのモードを決定する場合が考えられる。したがって、（上回る）第１の指定しきい値（しきい値１）が第１の指定バックオフモード（バックオフ１）に対応することになる等々。
【０１２４】
本発明に基づくこのリペアしきい値属性の利用に関連する一例は下記となる：
ａ＝ｒｅｐａｉｒ−ｔｈｒｅｓｈｏｌｄ：（０，１０，０，３００）
【０１２５】
本例では、リペアしきい値が３００秒のウィンドウに対して毎秒１０バイトとなることが送信機によって受信機に示される。
【０１２６】
５．２．２  第２の局面：１つの値の利用
４つの値を有するシンタックスの例は、さらにシンプルなケースに関連するエラーしきい値属性の適用性を限定するものではないことを指摘することは重要なことである。例えば、以下に例示的に描かれているように単一の値の利用も可能となる場合がある：
ａ＝ｒｅｐａｉｒ−ｔｈｒｅｓｈｏｌｄ：ｖａｌｕｅ
但し、
ｖａｌｕｅ＝％ｄ／ｆｌｏａｔ−ｖａｌｕｅ
ｆｌｏａｔ−ｖａｌｕｅ＝１＊ＤＩＧＩＴ［“．”１＊ＤＩＧＩＴ］
【０１２７】
第２の局面は第１の局面の特殊化を表わすという点で、第１の局面（４つの値、上記節２．１を参照のこと）と、第２の局面（１つの値、本節２．２を参照のこと）との間に対応付けが存在することを強調することは重要である。実際には、本発明の第１および第２の態様の双方に従って、シンプルなエラー比率（５％のような）を表現することが可能である。
【０１２８】
本発明に基づく上記リペアしきい値属性の利用例は下記となる：
ａ＝ｒｅｐａｉｒ−ｔｈｒｅｓｈｏｌｄ：５
本例では、エラー比率がパケットロス率の単位で測定されたものであることが明らかであれば、リペアしきい値が５％のパケットロス率であることが送信機により受信機に示される。
【０１２９】
５．３  バックオフモード
パラメータの数に依存する、バックオフモード属性に対する３つの可能な定義について以下のセクション（５．３．１、５．３．２、５．３．３）で説明する。
【０１３０】
５．３．１  第１のバックオフモード属性
バックオフモード属性（同等の名称として、抑制除外モード、応答タイミングモード、時間分散機能あるいはタイムスプレッド機能と呼ぶ場合もある）は、リペア処理を求める要求の開始時点またはこの開始時刻の計算方法を送信機が受信機に教える方法について記述するものである。このバックオフモード属性は、単一値（時間単位）のシグナリングを含むものであってもよく、上記受信機を介してリペア要求開始時刻またはリペア開始時刻（さらに複雑なセットのしきい値やマルチキャストの送信時に関与する受信機の数など）の受信機による計算を可能にすることが考えられる１セットの値をランダムに選択するようにしてもよい。
【０１３１】
エラー率しきい値に対して定義された方式と類似の方式を１セットのモードと共に利用することも可能である。本発明に基づくバックオフモード属性に関連するシンタックスの例を下記に示す：
ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：“（“ｖａｌｕｅ１”、“ｖａｌｕｅ２”、“ｖａｌｕｅ３”）”
但し、
ｖａｌｕｅ１＝％ｄ／ｆｌｏａｔ−ｖａｌｕｅ
ｆｌｏａｔ−ｖａｌｕｅ＝１＊ＤＩＧＩＴ［“．”１＊ＤＩＧＩＴ］
ｖａｌｕｅ２＝％ｄ
ｖａｌｕｅ３＝％ｄ
【０１３２】
上式で、ｖａｌｕｅ１は測定単位である。ｖａｌｕｅ１用として使用可能な値の１例を下記に示す：
ｖａｌｕｅ１＝０；単位は秒で表される相対時間である。
ｖａｌｕｅ１＝１；単位は絶対ＮＴＰ時間である。
ｖａｌｕｅ１＝２；単位はバイトである。
ｖａｌｕｅ１＝３；単位はビットである。あるいは、
ｖａｌｕｅ１＝４；単位はパケットである。
【０１３３】
ｖａｌｕｅ２は測定値である。例えば、１０秒、２０バイト、３０パケットとなる。この値はオフセット値を表わすものであってもよいし、負の値であってもよい。時間測定用として、上記値は絶対値または相対値のいずれかであってもよいことに留意されたい。セッション長が有限長で、かつ、相対的に短い時間のものである場合、相対的に短い時間のベストモードはセッションの終了を基準として相対的なモードにすることも可能である。決して終了しないセッション（ＭＢＭＳではない）の場合、（トランスポートヘッダフラグにより信号送信される送信オブジェクトの終了のような）別のエンティティの終了を利用するようにしてもよい。
【０１３４】
ｖａｌｕｅ３はウィンドウを表わす。このウィンドウ用の単位はｖａｌｕｅ２用の単位と同じにしてもよい。すなわちｖａｌｕｅ１によって定義されている単位と同じであってもよい。
【０１３５】
本発明の別の実施形態では、３未満のパラメータも可能である場合がある。例えば、２個だけのパラメータの存在によって、この存在が相対時間に対するデフォルトであることを示すことができる。同様に、１個のみのパラメータはゼロオフセットを含む相対時間を示すことも可能である。
【０１３６】
例えば、ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：（０，６０，１２０）は、上記モードを利用する装置が、好適には、通知済みのセッション（または別の関連するエンティティ）の終了から６０秒と１８０（＝６０＋１２０）秒との間の均一な配分を伴うランダムな選択によって、（リペア要求などの）メッセージ送信時刻の計算を行うことを示すことになる。
【０１３７】
好適な処理では、記述インスタンスでの表示順序に従って、増分する順序（０，１，２，．．．ｍ）で暗黙のうちにバックオフモードにラベリングを施すようにしてもよい。この結果（ＳＤＰファイルの開始などから得られる）第１の記述モードはモード０として特定され、次の記述モードはモード０として特定される等々が行われ、最後のモードはラベル“モードｍ”について記述することになる。このバーチャルラベリングの重要性として、（上記に定義されているような）エラー率しきい値からの上記ラベリングの対応付けが挙げられる。この対応付けによって、受信機はどのモードを採用すべきかにについて命令を受けることが可能となる。この結果、エラー比率１を経験した場合、受信機はバックオフモード１を採用することが可能となる。好適な設計によって、モード（ｍ＋１）の数が指定のエラー率しきい値の数と等しくなるように保証することも可能となる。しかし、不必要なエラー状態を避けるために、ｎ＞ｍ場合、すべてのエラー比率ｍ並びにｍよりも大きいエラー比率に対してモードｍを使用するようにしてもよく、さらに、ｎ＜ｍの場合、ｎ＋１からｍまでのバックオフモードを許可なく無視してもよい。エラー比率基準に依存するマルチモードの目的は、迅速なリペアタイプのサービスと、低速のリペアタイプのサービスとを認めることであることに留意されたい。これらのタイプのサービスによって、リペアスケジューリングで要求が一番厳しくないリペア要件の優先順位をユーザに許可することにより、マルチキャスト／放送グループ全体にわたってユーザの知覚ＱｏＳを最大化することが可能となる。したがって、このケースの場合、モード０が最もタイムリーな早めのリペアを与え、モードｍが最もタイムリでないリペアを与えるように保証することは理にかなうものとなる場合がある。しかし、上記は必須のものではないため別の方式も許されている。
【０１３８】
例えば、ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：（０，０，６０）、ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：（０，６０，１２０）は、第１のモードを使用している装置が、セッションの終了から０秒と６０秒との間のある時点でそのメッセージを送信し、第２のモードを使用している装置が、セッションの終了から６０秒と１２０秒との間のある時点でそのメッセージを送信するようになっていることを示すことになる。この例は、非オーバーラップメッセージウィンドウズを示すものである。但し、（異なるモードの両端にわたって）オーバラップするウィンドウズも本発明の範囲に属することになる。
【０１３９】
別の処理として、個々のバックオフモード行に４番目の値を追加する処理がある。この４番目の値は、上記のようなエラー比率に対する対応付けが可能な整数として、あるいは、エラーしきい値行へ導入すべき同様のラベルや、やはり使用すべき個々の対応付け用記述子を必要とする別の或るラベルとして、いずれかのモードラベルを施すことができる値である。
【０１４０】
本発明に基づくこのバックオフモード属性の利用例として、リペアしきい値属性の利用と組み合わされた下記の例がある：
ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：（０，０，３０）
ａ＝ｒｅｐａｉｒ−ｔｈｒｅｓｈｏｌｄ：（１，１０，０，１００）
ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：（０，３０，６０）
ａ＝ｒｅｐａｉｒ−ｔｈｒｅｓｈｏｌｄ：（１，２０，０，１００）
ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：（０，６０，２４０）
【０１４１】
本例では、エラー比率が（１００秒のスライドする時間ウィンドウを介して）毎秒１０ビット未満である場合、受信機は転送セッションの終了と３０秒との間でリペア要求の開始時刻をランダムに選択することが望ましい。転送セッションの終了後、エラー比率が毎秒１０ビット以上で、かつ、毎秒２０ビット未満であれば、受信機は３０秒間待機し、次いで、３０秒の待ち時間の終了とさらに６０秒（すなわちセッション終了後の３０秒と９０秒との間）との間でリペア要求をランダムに選択することが望ましい。エラー比率が毎秒２０ビット以上であれば、受信機は転送セッションの終了後６０秒間待機し、次いで、６０秒の待ち時間の終了とさらに２４０秒（すなわちセッションの終了後６０秒と３００秒の間）との間でリペア要求をランダムに選択することが望ましい。
【０１４２】
上記例の受信機による解釈は上記別の順序の解釈と同一であることに留意されたい：
ａ＝ｒｅｐａｉｒ−ｔｈｒｅｓｈｏｌｄ：（１，１０，０，１００）
ａ＝ｒｅｐａｉｒ−ｔｈｒｅｓｈｏｌｄ：（１，２０，０，１００）
ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：（０，０，３０）
ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：（０，３０，６０）
ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：（０，６０，２４０）
【０１４３】
５．３．２  第２のバックオフモード属性
本発明に基づく別のバックオフ処理は以下の規則に従うものであってもよい：
エラー比率がしきい値エラー比率未満の場合、“最初の転送セッションの終了を起点として時間Ｘにわたって一律にＮＡＣＫをランダムに選択する”。
エラー比率がしきい値エラー比率以上の場合、
“最初のセッションの終了後或る一定の時間Ｙまで待機し、次いで、時間ＺにわたってＮＡＣＫをランダムに選択しなければならない”。
【０１４４】
上記の場合、受信否定応答メッセージ（ＮＡＣＫ）は、例えばリペアセッションを求める要求の開始に対応することも可能である。
【０１４５】
この別のバックオフ処理はいくつかのＳＤＰパラメータについての記述を必要とする。本例では、上記パラメータはエラー比率Ｘ、Ｙ、Ｚであり、その場合これらのエラー比率は上記に定義されているようにエラー率しきい値と同じ単位で表現され、Ｘ、Ｙ、Ｚは（秒などの）時間単位で表現される。本発明に基づくこのようなバックオフモード属性に関連するシンタックスの例を下記に示す：
ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：“（”ｖａｌｕｅ１“，”ｖａｌｕｅ２“，”ｖａｌｕｅ３“，”ｖａｌｕｅ４“）”
但し、
ｖａｌｕｅ１＝％ｄ／ｆｌｏａｔ−ｖａｌｕｅ
ｆｌｏａｔ−ｖａｌｕｅ＝１＊ＤＩＧＩＴ［“．”１＊ＤＩＧＩＴ］
ｖａｌｕｅ２＝％ｄ
ｖａｌｕｅ３＝％ｄ
ｖａｌｕｅ４＝％ｄ
【０１４６】
上式で、ｖａｌｕｅ１は、エラー率リペアしきい値で上記に定義されているようなエラー比率である。ｖａｌｕｅ２は、転送セッションの終了以来、エラー比率がｖａｌｕｅ１未満である場合のバックオフタイムである。ｖａｌｕｅ３はエラー比率がｖａｌｕｅ１によって示されるしきい値を上回る場合の待ち時間である。ｖａｌｕｅ４はエラー比率がｖａｌｕｅ１より大の場合のバックオフタイムである。ｖａｌｕｅ４は、転送セッションの終了後ｖａｌｕｅ３からの相対変位値あるいは転送セッションの終了に対応する変位値となる場合がある（後者の場合ｖａｌｕｅ４＞ｖａｌｕｅ２）。
【０１４７】
バックオフモード属性を含む複数のａ行によって、複数の条件からなるアレイが定義され、該ａ行の実行も可能となる。
【０１４８】
上記バックオフモード属性の利用例を以下に示す：
例１：
ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：（５，１０，２０，３０）
【０１４９】
本例では、エラー比率が５％未満の場合、受信機は、転送セッションの終了と１０秒との間でリペア要求開始時刻をランダムに選択することが望ましい。エラー比率が５％よりも大きくなった場合、受信機は、転送セッションの終了後２０秒間待機し、次いで、２０秒の待ち時間の終了と３０秒との間でリペア要求をランダムに選択することが望ましい。
【０１５０】
例２：
ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：（５，１０，２０，３０）
ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：（１０，２０，３０，６０）
本例には同じ属性を含む複数の行が含まれる。５％エラー比率に関連する例２で定義される規則に加えて、１０％エラー比率のケースを処理する第２の規則が設けられ、この第２の規則は前回の例の場合と同様の意味論を有する。
【０１５１】
５．３．３  第３のバックオフモード属性
重要なこととして、上記シンタックスの例がバックオフモード属性の適用性をシンプルなケースに限定しているものではないことを指摘しておく。例えば、下記に例として示されているように単一値の利用も可能である：
ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：“（”［“＋”］ｖａｌｕｅ“）”
但し、
ｖａｌｕｅ＝％ｄ
【０１５２】
上式で、“＋”が用いられている場合、ＳＤＰの受信からの相対時間が考慮される。このケースでは、送信機は、セッションの終了と（秒で表現される）ｖａｌｕｅとの間のランダムな時点にリペアセッションを開始するように受信機に命じることも可能である。“＋”が使用されていない場合、絶対ＮＴＰ時間単位が用いられる。
【０１５３】
（リペア処理が可能となる時間までの）リペア利用可能最長時間としてｖａｌｕｅを定義することも可能であり、ＮＴＰ時間でこのリペア利用可能最長時間を表現することも可能である。このケースではレージィ・リペアを作動可能にすることが考えられる。
【０１５４】
さらに、送信機は、マルチキャストセッションに参加している受信機の数をＳＤＰを経由して信号送信することも可能である。この数は、リペアセッションの開始バックオフタイムを計算する関数への入力時に（上記のランダムな時間と共に）示すことができる数値である。
【０１５５】
上記バックオフモード属性の利用例を以下に示す：
例１：
ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：（＋５００）
本例では、送信機は、セッションの終了と５００秒との間のランダムな時刻にリペアセッションの開始を受信機に命じることになる。
【０１５６】
例２：
ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：（＋５００）
ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ−ｕｓｅｒｓ：５０００
本例では、送信機は、マルチキャストセッションに参加している５０００人のユーザが存在していることを考慮してバックオフタイムの計算を行うように受信機に命じることになる。
【０１５７】
５．４  リペアタイプパラメータおよびリペアトークンパラメータ
このパラメータは、双方のリペアタイプ（すなわちポイント・ツウ・マルチポイントリペアとポイント間リペアとの双方）並びにリペアトークンについて記述するものである。第１のリペアタイプは、どのようなタイプのリペアが可能であるかについて記述するために利用される。第２のリペアタイプは、ある特定のオブジェクト（ファイルなど）をリペアする方法（すなわちリペアタイプ）と、オブジェクトのどの部分をリペアするか（ポイント・ツウ・マルチポイントリペアが用いられる場合）について記述するものである。マルチリペアトークン属性リストが存在する場合もある。この属性はセッションレベルまたはメディアレベルのものであってもよい。
【０１５８】
本発明に基づくリペアタイプ属性に関連するシンタックスの例を下記のように示す：
ａ＝ｒｅｐａｉｒ−ｔｙｐｅ−ｐａｒａｍ：ｒｅｐａｉｒ−ｔｙｐｅ
但し、
ｒｅｐａｉｒ−ｔｙｐｅ＝“ｐｔｐ”／“ｐｔｍ”／“ｂｏｔｈ”
さらに、本発明に基づくリペアトークン属性に関連するシンタックスの例を下記のように示す：
ａ＝ｒｅｐａｉｒ−ｔｏｋｅｎ：“｛”ｒｅｐａｉｒ−ｔｙｐｅ＊｛“，”ｅｎｔｉｔｙ）｝”
但し、
ｒｅｐａｉｒ−ｔｙｐｅ＝“ｐｔｐ”／“ｐｔｍ”／“ｂｏｔｈ”
ｅｎｔｉｔｙ＝（“（”Ｆｉｌｅ−ＩＤ［＊（“，｛”ＳＢＮ＊（“，”ＥＳＩ）“｝”）／
（＊（“，（ｆｉｒｓｔ_ｂｙｔｅ_ｐｏｓｉｔｉｏｎ＝”
ｆｉｒｓｔ_ｂｙｔｅ_ｐｏｓｉｔｉｏｎ“，ｎｕｍｂｅｒ−_ｏｆ_ｂｙｔｅｓ＝”ｎｕｍｂｅｒ_ｏｆ_ｂｙｔｅｓ）“）”）］“）”）
ＦＩＬＥ−ＩＤ＝＜“＞ｔｅｘｔｓｔｒｉｎｇ＜”＞
ＳＢＮ＝（％ｄ）／（“（“％ｄ＊（“，”％ｄ）“）”）／（“（“％ｄ“−”％ｄ−“）”）
ＥＳＩ＝（％ｄ）／（“（“％ｄ＊（“，”％ｄ）“）”）／（“（“％ｄ“−”％ｄ“）”）
ｆｉｒｓｔ_ｂｙｔｅ_ｐｏｓｉｔｉｏｎ＝％ｄ
ｎｕｍｂｅｒ_ｏｆ_ｂｙｔｅｓ＝％ｄ
ｔｅｘｔｓｔｒｉｎｇ＝１＊（（０ｘ０１．．０ｘ０９）／０ｘ０ｂ／０ｘ０ｃ／（０ｘ０ｅ．．０ｘ２１）
／（０ｘ０２３．．０ｘｆｆ））
；ＮＵＬ，ＣＲ，ＬＦ，‘”’以外の任意のバイト
【０１５９】
上式で、ＳＢＮはソースブロック番号であり、ＥＳＩは符号化シンボルＩＤである。ＥＳＩとＳＢＮとは対を成すものであってもよく、さらに、ＥＳＩとＳＢＮとは範囲または範囲のリストであってもよい。しかし、ＥＳＩはこの記述子の中に単独で存在することはできない。
【０１６０】
リペアトークンは（ファイルなどの）個々のオブジェクト毎に送信することも可能である。一般に、ファイルＩＤのテキスト文字列はＵＲＩまたはＵＲＩの一部であると予想されることに留意されたい。
【０１６１】
リペアタイプ属性の利用例を下記に示す：
ａ＝ｒｅｐａｉｒ−ｔｙｐｅ−ｐａｒａｍ：ｐｔｍ
本例では、受信機は、ポイント・ツウ・マルチポイントを介してリペアを実行するように命じられる。リペアトークン属性の利用例は以下のようになる：
例１：
ａ＝ｒｅｐａｉｒ−ｔｏｋｅｎ：｛ｐｔｍ，（“ｈｔｔｐ：／／ｗｗｗ．ｆｉｌｅ．ｃｏｍ／ｆｉｌｅ３．３ｇｐ”，（１０，２０），（１２，１３４））｝
本例では、リペアは、指示されたファイルに対してポイント・ツウ・マルチポイントを介して実行される。リペアの対象となるブロックは、ＳＢＮ１０とＥＳＩ２０、並びに、ＳＢＮ１２とＥＳＩ１３４を持つブロックである。
【０１６２】
例２：
ａ＝ｒｅｐａｉｒ−ｔｏｋｅｎ：｛ｐｔｍ，（“ｈｔｔｐ：／／ｗｗｗ．ｆｉｌｅ．ｃｏｍ／ｆｉｌｅ３．３ｇｐ”，（１０−１４），（１６，３４））｝
本例では、リペアは、指示されたファイルに対してポイント・ツウ・マルチポイントを介して実行される。リペアの対象となるブロックは、ＳＢＮ１０〜１４およびＳＢＮ１６のＥＳＩ３４用ブロックである。
【０１６３】
例３：
ａ＝ｒｅｐａｉｒ−ｔｏｋｅｎ：｛ｐｔｍ，（“ｈｔｔｐ：／／ｗｗｗ．ｆｉｌｅ．ｃｏｍ／ｆｉｌｅ３．３ｇｐｐ”，“ｆｉｒｓｔ_ｂｙｔｅ_ｐｏｓｉｔｉｏｎ＝１０，ｎｕｍｂｅｒ_ｏｆ_ｂｙｔｅｓ＝１５０”）｝
【０１６４】
本例では、リペアは、指示されたファイルに対してポイント・ツウ・マルチポイントを介して実行される。リペアの対象となるバイト数は、１０バイトから始まる１５０バイトである。
【０１６５】
６．マルチチャネル
マルチチャネルに関係するＳＤＰ属性の定義には、以下に説明するように３つの局面が含まれる。
【０１６６】
６．１  第１の局面
マルチチャネル属性は、送信機が使用するチャネルの送信数について記述する。マルチチャネル属性は、ＳＤＰのｍラインに対してチャネル数のチェックに利用することも可能である。
【０１６７】
本発明に基づくシンタックスの例を下記に示す：
ａ＝ｆｌｕｔｅ−ｃｈ：ｖａｌｕｅ  ＣＲＬＦ
但し、
ｖａｌｕｅ＝％ｄ
【０１６８】
上式で、ｖａｌｕｅは、ＦＬＵＴＥセッション時にデータを送信を行うために送信機が使用するチャネルの数である。このパラメータは、送信機がデータを送信するためにＦＬＵＴＥセッション時にマルチチャネルを利用することを受信機に指示することも可能である。このパラメータは、送信機が使用するチャネルの数を指示することも可能である。受信機は、この記述子が指定する値を利用して、宛先について記述するすべてのｍラインを受信したことをチェックすることも可能である。例えば、上記パラメータの値が２であれば、ｍラインによって指定された２チャネルが存在することが望ましい。
【０１６９】
６．２  第２の局面
さらに、本発明に基づくＴＳＩ属性は、セッション用の送信セッションＩＤ（ＴＳＩ）の値について記述する。上記ＴＳＩ属性に関連するシンタックスの例を下記に示す：
ａ＝ｆｌｕｔｅ−ｔｓｉ：  ｖａｌｕｅ  ＣＲＬＦ
但し、
ｖａｌｕｅ＝％ｄ
【０１７０】
６．３  第３の局面
本発明では、或る一定のチャネルに在るＦＬＵＴＥセッションの存在の導入を示すために、（行の形で表わされる）新規のメディア記述子（ｍライン）および接続データ（ｃライン）も用いられる。これは、次例に図示のようなＳＤＰ記述でｍラインを用いることによって行われる：
ｍ＝ｄａｔａ  １２３４５  ＦＬＵＴＥ／ＵＤＰ  ０
Ｃ＝ＩＮ  ＩＰ６  ＦＦｌＥ：０３ＡＤ：：７Ｆ２Ｅ：１７２Ａ：１Ｅ２４／１
【０１７１】
上記ＳＤＰメディア記述子（ｍライン）および接続データ（ｃライン）では、ｍラインは使用メディアを示し、ｃラインは対応するチャネルを示す。したがって、上記例では、ＵＤＰを介してＦＬＵＴＥを利用するチャネルでメディアのトランスポートが行われることがｍラインによって示されていることになる。さらに、ｃラインは、このケースではＩＰｖ６アドレスであるチャネルのアドレスを示す。
【０１７２】
上述の３つの局面に基づくマルチチャネルに関連する属性の利用例を下記に示す：
ｖ＝０
ｏ＝ｕｓｅｒ１２３  ２８９０８４４５２６  ２８９０８４２８０７  ＩＮ  ＩＰ６
２２０１：０５６Ｄ：：１１２Ｅ：１４４Ａ：１Ｅ２４
Ｓ＝Ｆｉｌｅ  ｄｅｌｉｖｅｒｙ  ｓｅｓｓｉｏｎ  ｅｘａｍｐｌｅ
ｉ＝Ｍｏｒｅ  ｉｎｆｏｒｍａｔｉｏｎ
ｔ＝２８７３３９７４９６  ２８７３４０４６９６
ａ＝ｓｏｕｒｃｅ−ｆｉｌｔｅｒ：  ｉｎｃｌ  ＩＮ  ＩＰ６  ＊
２００１：２１０：１：２：２４０：９６ＦＦ：ＦＥ２５：８ＥＣ９
ａ＝ｆｌｕｔｅ−ｔｓｉ：  ３
ａ＝ｆｌｕｔｅ−ｃｈ：  ２
ｍ＝ｄａｔａ  １２３４５  ＦＬＵＴＥ／ＵＤＰ  ０
ｃ＝ＩＮ  ＩＰ６  ＦＦｌＥ：０３ＡＤ：：７Ｆ２Ｅ：１７２Ａ：１Ｅ２４／１
ｍ＝ｄａｔａ  １２３４６  ＦＬＵＴＥ／ＵＤＰ  ０
ｃ＝ＩＮ  ＩＰ６  ＦＦｌＥ：０３ＡＤ：：７Ｆ２Ｅ：１７２Ａ：１Ｅ３０／１
【０１７３】
上記例では、送信機は、２チャネル（ａ＝ｆｌｕｔｅ−ｃｈ：２）でＦＬＵＴＥセッション時にデータの送信を行うことを示す。次いで、送信機はチャネルを指定する。これらのチャネルは、行ｃ＝ＩＮ  ＩＰ６  ＦＦｌＥ：０３ＡＤ：：７Ｆ２Ｅ：１７２Ａ：１Ｅ３０／１の形で指示される。これは、２つのチャネル（おそらく別のケースでは連続するチャネルの中にさらに多くのチャネル）があることを受信機に示すものである。行ａ＝ｆｌｕｔｅ−ｔｓｉ：３の中に定義されている属性ＴＳＩはセッション用のＴＳＩ（送信セッションＩＤ）について記述する。行ａ＝ｓｏｕｒｃｅ−ｆｉｌｔｅｒ：  ｉｎｃｌ  ＩＮ  ＩＰ６  ＊  ２００１：２１０：１：２：２４０：９６ＦＦ：ＦＥ２５：８ＥＣ９の中に定義される属性はソースフィルタについて記述するものである。本例では、送信機は、受信機がセッションの中へ所定のＩＰアドレス｛２００１：２１０：１：２：２４０：９６ＦＦ：ＦＥ２５：８ＥＣ９）を含むことが望ましいことを示す。上記一対（ソースＩＰアドレスとＴＳＩ）によって、セッションは一体に一意に特定される。別の可能性を利用することも可能ではあるが、このケースでは、上記記述子の中でｉｎｃｌ属性および＊属性のみを使用してもよいことに留意されたい。行ｍ＝ｄａｔａ１２３４５ＦＬＵＴＥ／ＵＤＰ０は、チャネル用として使用するメディアを示す新規の追加行である。本例では記載の２つのチャネルに対して２つの‘ｍ’行が存在する。
【０１７４】
上記記載のＦＬＵＴＥセッションの外にリペアセッションを必要とするような状況で使用すべきパラメータを受信機へ信号で送信するために、送信機はセッションリペア用のセクション７で定義するＳＤＰ属性を利用する。これらのパラメータによって、受信機は正しいリペアサーバの配置が可能となり、送信機は所定のリペアしきい値のセットが可能となり、送信機はリペアタイプおよびこれとは別のパラメータの定義を行うことが可能となる。
【０１７５】
７．コンテンツ記述ポインタ
コンテンツ記述子ポインタ属性によって、コンテンツ記述の格納されているＵＲＩを送信機が受信機に示す方法が記述される。
【０１７６】
本発明に基づくコンテンツ記述子ポインタ属性に関連するシンタックスの例は下記のようになる：
ａ＝ｃｏｎｔｅｎｔ−ｄｅｓｃ：“ｕｒｉ＝”＜“＞ＵＲＩ＜”＞ＣＲＬＦ
但し、
ＵＲＩ＝コメント募集（ＲＦＣ）ドキュメント２３９６に定義されているもの
【０１７７】
上式で、ＵＲＩはコンテンツ記述用として有効なＵＲＩである。ＵＲＩは、ファイル記述テーブル（ＦＤＴ）ＸＭＬスキーマのような拡張マークアップ言語（ＸＭＬ）スキーマや、インターネットメディア・ガイド（ＩＭＧ）データモデルへのエントリポイント、あるいは、スキーマやデータモデルへの別の上記のようなエントリ・ポイントであってもよい。当業者は上記方法を利用して別の代替方法を発見することが可能となる。
【０１７８】
図１は本発明に準拠する方法の可能な実施形態を示すフローチャートを描く図である。第１のステップ８０１では、送信機と受信機との間に物理的接続または論理的接続が確立される。次いで、第２のステップ８０２では、例えば、送信セッション時に適用されるＦＥＣ符号化方式に関する情報や受信機サイト側におけるバッファ処理要件に関連する情報のようなセッションパラメータが、例えばＳＤＰなどの通信プロトコルを介して送信機から受信機へ通信される。このケースでは、本発明の上記説明で例として定義されているようにＳＤＰ属性を介して前記セッションパラメータを通信するようにしてもよい。これらのセッションパラメータを受信機側で受信し、処理した後、ステップ８０３で、送信機から前記受信機への、共有データのポイント・ツウ・マルチポイント送信が実行される。この処理は前記セッションパラメータによって少なくとも部分的に定義されている。
【０１７９】
図２は、本発明に準拠するシステムの可能な実施形態を概略的に描く図である。システムは送信機９０２、ネットワーク９０３および受信機９０１−１、９０１−２、９０１−３を具備する。前記送信機９０３は例えばＭＢＭＳサーバであってもよい。前記送信機９０３から、例えば、ポイント・ツウ・マルチポイントセッション内のＩＰベースの放送／マルチキャストネットワークであってもよい前記ネットワーク９０３を経由してデータは前記受信機９０１−１、９０１−２、９０１−３へ送信される。ポイント・ツウ・マルチポイントセッションより前に、セッションパラメータは、例えばＳＤＰなどであってもよい前記通信プロトコルを介して前記送信機９０３から前記受信機９０１−１、９０１−２、９０１−３へ通信される。
【０１８０】
如上の例から、少なくとも以下の局面に関して、本発明が特筆すべき利点を提供するものであることを容易に理解されたい。
【０１８１】
本発明は、ＦＬＵＴＥセッションの外に、受信機側でセッションの受信に必要なパラメータを受信機へ送信を行う方法を提供する。
【０１８２】
本発明はまた、受信機がセッション中にすべての必要なデータを受信していない状況で、ポイント間リペアセッションの確立に必要な受信機へパラメータを送信する方法も提供するものである。再度、これらのパラメータはセッション外の送信を行うために本来必要となる。これらのパラメータを受信機へ送信するためにＳＤＰを利用することによって、理想的方法が提供され、同方法が達成されることになる。
【０１８３】
さらに、本発明によって、差動受信回復要求に従って、特に異なるエラーしきい値をそれぞれのバックオフモードとリンクすることによって、シンプルでかつ強力に調整可能なマルチ・バックオフ・アルゴリズム採用が可能となる。
【０１８４】
以上、実施例並びに推奨実施形態によって本発明を説明した。当業者には自明である代替方法および変更例が存在し、これらは添付の請求項の精神の範囲から逸脱することなく実施可能であることに留意されたい。特に、本発明は、ＩＰネットワークを介するすべてのタイプの放送／マルチキャストシステムに対して適用可能であり、移動通信ネットワークあるいは３ＧＰＰのＭＢＭＳシステムに限定されるものではない。さらに、本発明は、決してＦＬＵＴＥセッションに限定されるものではなく、別のタイプのセッションにも同様に適用可能である。
【図面の簡単な説明】
【０１８５】
【図１】本発明に準拠する方法の可能な実施形態のフローチャート。
【図２】本発明に準拠するシステムの可能な実施形態の概略図。
【図１】
2007531368.tif 000003
【図２】
2007531368.tif 000004
【手続補正書】
【提出日】平成19年1月10日(2007.1.10)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】請求項４５
【補正方法】変更
【補正の内容】
【請求項４５】
データを送信するシステムであって、該システムが、少なくとも１台の送信機と、複数台の受信機とを備え、前記少なくとも１台の送信機と、前記複数台の受信機とが、送信セッション内における共有データの前記送信に関係する少なくとも１つのセッションパラメータを、前記少なくとも１台の送信機から前記複数台の受信機へ通信プロトコルを介して通信するように構成された手段を備え、さらに、前記少なくとも１台の送信機と、前記複数台の受信機とが、前記送信セッション内において前記送信機から前記複数台の受信機へ前記共有データを送信するように構成された手段を備えるシステム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０１２２
【補正方法】変更
【補正の内容】
【０１２２】
いずれの当業者にとっても、ｖａｌｕｅ１、ｖａｌｕｅ２、ｖａｌｕｅ３、ｖａｌｕｅ４のいくつかの列挙が可能であり、この列挙が本発明の範囲内に属することは明らかである。例えば、ｖａｌｕｅ３＝０（測定ウィンドウの単位は秒である）；ｖａｌｕｅ３＝１（測定ウィンドウの単位はパケットである）は上記の例に対する別の列挙である。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０１３７
【補正方法】変更
【補正の内容】
【０１３７】
好適な処理では、記述インスタンスでの表示順序に従って、増分する順序（０，１，２，．．．ｍ）で暗黙のうちにバックオフモードにラベリングを施すようにしてもよい。この結果（ＳＤＰファイルの開始などから得られる）第１の記述モードはモード０として特定され、次の記述モードはモード１として特定される等々が行われ、最後のモードはラベル“モードｍ”について記述することになる。このバーチャルラベリングの重要性として、（上記に定義されているような）エラー率しきい値からの上記ラベリングの対応付けが挙げられる。この対応付けによって、受信機はどのモードを採用すべきかにについて命令を受けることが可能となる。この結果、エラー比率１を経験した場合、受信機はバックオフモード１を採用することが可能となる。好適な設計によって、モード（ｍ＋１）の数が指定のエラー率しきい値の数と等しくなるように保証することも可能となる。しかし、不必要なエラー状態を避けるために、ｎ＞ｍ場合、すべてのエラー比率ｍ並びにｍよりも大きいエラー比率に対してモードｍを使用するようにしてもよく、さらに、ｎ＜ｍの場合、ｎ＋１からｍまでのバックオフモードを許可なく無視してもよい。エラー比率基準に依存するマルチモードの目的は、迅速なリペアタイプのサービスと、低速のリペアタイプのサービスとを認めることであることに留意されたい。これらのタイプのサービスによって、リペアスケジューリングで要求が一番厳しくないリペア要件の優先順位をユーザに許可することにより、マルチキャスト／放送グループ全体にわたってユーザの知覚ＱｏＳを最大化することが可能となる。したがって、このケースの場合、モード０が最もタイムリーな早めのリペアを与え、モードｍが最もタイムリでないリペアを与えるように保証することは理にかなうものとなる場合がある。しかし、上記は必須のものではないため別の方式も許されている。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０１５０
【補正方法】変更
【補正の内容】
【０１５０】
例２：
ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：（５，１０，２０，３０）
ａ＝ｂａｃｋｏｆｆ−ｍｏｄｅ：（１０，２０，３０，６０）
本例には同じ属性を含む複数の行が含まれる。５％エラー比率に関連する例１で定義される規則に加えて、１０％エラー比率のケースを処理する第２の規則が設けられ、この第２の規則は前回の例の場合と同様の意味論を有する。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】０１７９
【補正方法】変更
【補正の内容】
【０１７９】
図２は、本発明に準拠するシステムの可能な実施形態を概略的に描く図である。システムは送信機９０２、ネットワーク９０３および受信機９０１−１、９０１−２、９０１−３を具備する。前記送信機９０２は例えばＭＢＭＳサーバであってもよい。前記送信機９０２から、例えば、ポイント・ツウ・マルチポイントセッション内のＩＰベースの放送／マルチキャストネットワークであってもよい前記ネットワーク９０３を経由してデータは前記受信機９０１−１、９０１−２、９０１−３へ送信される。ポイント・ツウ・マルチポイントセッションより前に、セッションパラメータは、例えばＳＤＰなどであってもよい前記通信プロトコルを介して前記送信機９０３から前記受信機９０１−１、９０１−２、９０１−３へ通信される。
【国際調査報告】
2007531368.tif 000005
2007531368.tif 000006
2007531368.tif 000007