(57)【要約】【課題】ユニキャスト及びマルチキャストが使える通信環境で、送信装置及びネットワークのリソースを効率的に利用することを目的とする。【解決手段】通信方式にユニキャスト又はマルチキャストを使って受信装置にデータを送信する送信装置１００であって、受信装置までのネットワークの状況に基づいて、受信装置がマルチキャストでの受信ができる状態であるか否かを判断する判断手段と、判断手段での判断に応じて通信方式を決定する決定手段と、を備える。【選択図】図２
2016178540.tif 000002
【特許請求の範囲】
【請求項１】
通信方式にユニキャスト又はマルチキャストを使って受信装置にデータを送信する送信装置であって、
前記受信装置までのネットワークの状況に基づいて、前記受信装置がマルチキャストでの受信ができる状態であるか否かを判断する判断手段と、
前記判断手段での判断に応じて通信方式を決定する決定手段と、を備えることを特徴とする送信装置。
【請求項２】
前記受信装置までのホップ数を計測するホップ数計測手段をさらに備え、
前記判断手段は、前記ホップ数計測手段で計測したホップ数とマルチキャストのＴＴＬの初期値との比較により、前記受信装置がマルチキャストでの受信ができる状態であるか否かを判断することを特徴とする請求項１に記載の送信装置。
【請求項３】
前記決定手段は、前記受信装置から要求されるデータのマルチキャストによる送信の状況、及び、前記判断手段の判断に応じて、通信方式を決定することを特徴とする請求項１又は２に記載の送信装置。
【請求項４】
前記決定手段は、前記受信装置から要求されるデータのユニキャストによる配信数が閾値に達しているか否か、及び、前記判断手段の判断に応じて、通信方式を決定することを特徴とする請求項１又は２に記載の送信装置。
【請求項５】
前記決定手段は、前記受信装置から要求されるデータの一定時間当たりの送信量が閾値に達しているか否か、及び、前記判断手段の判断に応じて、通信方式を決定することを特徴とする請求項１又は２に記載の送信装置。
【請求項６】
前記決定手段は、前記判断手段で前記受信装置がマルチキャストでの受信ができる状態であると判断された場合に、マルチキャスト及びユニキャストのどちらでもデータを送信できるとの決定をすることを特徴とする請求項１又は２に記載の送信装置。
【請求項７】
前記決定手段で決定した通信方式を前記受信装置に通知する通知手段をさらに備えることを特徴とする請求項１乃至６のいずれか１項に記載の送信装置。
【請求項８】
前記受信装置から通信方式を受信する受信手段を備え、
前記通知手段で通知した通信方式と、前記受信手段で受信した通信方式とが合致した場合、合致した通信方式でデータを送信することを特徴とする請求項７に記載の送信装置。
【請求項９】
前記決定手段は、前記受信装置から複数のデータの送信を要求された場合に、データごとに通信方式を決定することを特徴とする請求項１乃至８のいずれか１項に記載の送信装置。
【請求項１０】
通信方式にユニキャスト又はマルチキャストを使って受信装置にデータを送信する送信装置の制御方法であって、
前記受信装置までのネットワークの状況に基づいて、前記受信装置がマルチキャストでの受信ができる状態であるか否かを判断する判断ステップと、
前記判断ステップでの判断に応じて通信方式を決定する決定ステップと、を備えることを特徴とする送信装置の制御方法。
【請求項１１】
前記受信装置までのホップ数を計測する計測ステップをさらに備え、
前記判断ステップでは、前記計測ステップで計測したホップ数とマルチキャストのＴＴＬの初期値との比較により、前記受信装置がマルチキャストでの受信ができる状態であるか否かを判断することを特徴とする請求項１０に記載の送信装置の制御方法。
【請求項１２】
前記決定ステップでは、前記受信装置から要求されるデータのマルチキャストによる送信の状況、及び、前記判断ステップの判断に応じて、通信方式を決定することを特徴とする請求項１０又は１１に記載の送信装置の制御方法。
【請求項１３】
通信方式にユニキャスト又はマルチキャストを使って受信装置にデータを送信する送信装置を制御するためのプログラムであって、
前記受信装置までのネットワークの状況に基づいて、前記受信装置がマルチキャストでの受信ができる状態であるか否かを判断する判断手段と、
前記判断手段での判断に応じて通信方式を決定する決定手段と、してコンピュータを機能させるためのプログラム。
【請求項１４】
前記受信装置までのホップ数を計測するホップ数計測手段として、さらにコンピュータに機能させ、
前記判断手段は、前記ホップ数計測手段で計測したホップ数とマルチキャストのＴＴＬの初期値との比較により、前記受信装置がマルチキャストでの受信ができる状態であるか否かを判断することを特徴とする請求項１３に記載のプログラム。
【請求項１５】
前記決定手段は、前記受信装置から要求されるデータのマルチキャストによる送信の状況、及び、前記判断手段の判断に応じて、通信方式を決定することを特徴とする請求項１３又は１４に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データの送受信技術に関するもので、より詳細には、送信装置やネットワークのリソースの効率的な利用方法に関する。
【背景技術】
【０００２】
近年、動画像や音声等のマルチメディアデータをＩＰネットワークによってストリーミング配信し、視聴する技術が実用化されている。特に、ライブ映像等のリアルタイム性を必要とするマルチメディアデータを配信する際には、ＲＴＰ(A Transport Protocol for Real-Time Applications)と呼ばれる通信プロトコルが一般に使用されている。ＲＴＰは、主に音声や動画像等をリアルタイムでデータ転送するためのプロトコルであり、ＩＥＴＦによりＲＦＣ３５５０として定義されている。
【０００３】
ＲＴＰは、非コネクション型のプロトコルであるＵＤＰ(User Datagram Protocol)の上位プロトコルである。ＲＴＰには、一般的にユニキャストやマルチキャストと呼ばれる通信方式が用いられる。ユニキャストとは、一対一の通信をするための技術である。ユニキャストで複数の受信装置にパケットを送信する場合は、送信装置側でパケットを複製して、それぞれの受信装置に送信する必要がある。一方マルチキャストとは、一つのパケットを特定の多数を対象に送信するための技術である。マルチキャストのパケットは通信経路中の適切な中継装置によって複製され、各受信装置に送信される。
このことから、マルチキャストを受信可能な複数の受信装置が、同じマルチメディアデータを送信装置に要求する場合、送信装置は、ユニキャストではなくマルチキャストを利用することで、パケットを複製して送信する必要が無くなる。これにより、パケットの送信に伴う送信装置の処理負荷を軽減できる。
【０００４】
ところで、ＲＴＰを用いて動画像や音声のデータをパケット化して送受信する場合、一般にネットワークに流れるＲＴＰパケットの事をストリームデータ、或いはメディアストリーム等と呼ぶ。このＲＴＰを用いたメディアストリームの開始や終了等、いわゆる通信セッションの制御を行う為のプロトコルとして、一般にＲＴＳＰ（Real Time Streaming Protocol）がよく知られている。ＲＴＳＰはＩＥＴＦによりＲＦＣ２３２６として定義されている。ＲＴＳＰでは、通信方式をユニキャスト又はマルチキャストのどちらにするかは、クライアントとなる受信装置がサーバとなる送信装置にＳＥＴＵＰメソッドを送ることで決定される。特許文献１は、ＲＴＳＰを用いてユニキャスト通信、及び、マルチキャスト通信を行うことについて開示する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１１−１８２２１２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、ＳＥＴＵＰメソッドで通信方式を決定すると、ネットワークの使用効率が低下したり、送信装置の処理負荷が高くなったりする場合がある。例えば、多数の受信装置が送信装置からマルチキャストでデータを受信できるにもかかわらず、それぞれの受信装置はユニキャストで同じデータを受信する場合である。この場合、送信装置はマルチキャストでデータを送信し、それぞれの受信装置はマルチキャストでデータを受信すれば、送信装置が配信するストリームデータは１本でよい為、送信装置のデータ配信に関わるリソースの消費が少なくて済む。更に、ネットワークに流れるストリームデータが少なくなることで、通信帯域の節約に繋がる可能性がある。
【０００７】
また、経由するルーターの数等のネットワークの距離の問題で、マルチキャストでデータ受信できない場所に位置する受信装置が、マルチキャストでデータを要求する場合が考えられる。この場合、マルチキャストでデータを要求しても、受信装置はマルチキャストのデータを受信できない。
【０００８】
本発明は上述した問題を解決するためになされたものであり、ユニキャスト及びマルチキャストが使える通信環境で、送信装置及びネットワークのリソースを効率的に利用することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の送信装置は、通信方式にユニキャスト又はマルチキャストを使って受信装置にデータを送信する送信装置であって、前記受信装置までのネットワークの状況に基づいて、前記受信装置がマルチキャストでの受信ができる状態であるか否かを判断する判断手段と、前記判断手段での判断に応じて通信方式を決定する決定手段と、を備える。
【発明の効果】
【００１０】
本発明によれば、受信装置がマルチキャストでの受信ができる状態であるか否かに応じて通信方式が決定される。このため、ユニキャスト及びマルチキャストが使える通信環境で、送信装置及びネットワークのリソースを効率的に利用できる。
【図面の簡単な説明】
【００１１】
【図１】第１実施形態の送信装置のブロック図である。
【図２】第１実施形態の送信装置が通信方式を決定する処理の例を示すフローチャートである。
【図３】第１実施形態のＳＤＰ生成部が生成するセッション情報の例を示す図である。
【図４】第１実施形態の送信装置がセッション情報通知後にＳＥＴＵＰメソッドを受信した時の処理の例を示すフローチャートである。
【図５】第２実施形態における第１の例の送信装置が通信方式を決定する処理の例を示すフローチャートである。
【図６】第２実施形態のＳＤＰ生成部が生成するセッション情報の例を示す図である。
【図７】第２実施形態における第２の例の送信装置が通信方式を決定する処理の例を示すフローチャートである。
【図８】第２実施形態における第３の例の送信装置が通信方式を決定する処理の例を示すフローチャートである。
【図９】第３実施形態の送信装置が、ＤＥＳＣＲＩＢＥメソッドを受信してから、メディアを配信するまでの処理の例を示すフローチャートである。
【図１０】第３実施形態のＳＤＰ生成部が生成するセッション情報の例を示す図である。
【発明を実施するための形態】
【００１２】
以下、添付図面を参照して、本発明の好適な実施形態について説明する。
＜第１実施形態＞
本実施形態の送信装置１００の構成について、図１のブロック図を参照して説明する。送信装置１００は、データパケット生成部１０１、パケット送信バッファ部１０２、ＳＤＰ生成部１０３、配信制御部１０４、ホップ数計測部１０５及びパケット送受信部１０６を備える。
【００１３】
データパケット生成部１０１は、例えばＲＴＰプロトコルを用いて通信する場合、外部から入力された動画像や音声の符号化されたデータを、通信に適したサイズに分割し、更に通信するために必要なヘッダを付加してＲＴＰのデータパケットを生成する。
パケット送信バッファ部１０２は、生成されたデータパケットを一時保管するためのバッファである。パケット送信バッファ部１０２に一時保管されたデータパケットは、パケット送受信部１０６において、伝送路１０７に送信される。
ＳＤＰ生成部１０３は、配信制御部１０４からの指示に従ってＳＤＰ（Session Description Protocol）に準じたセッション情報を生成する。ＳＤＰは、メディアストリームの初期化パラメータを記述するための形式を定めたものであり、ＩＥＴＦによりＲＦＣ４５６６として定義されている。
【００１４】
配信制御部１０４は、データパケットの通信方式を決定する機能や配信制御を行う機能を備え、本実施形態では、メディアストリームの配信を要求する受信装置に対し、ユニキャストで送信するかマルチキャストで送信するかを決定する。
ホップ数計測部１０５は、ＲＴＳＰでメディアストリームの配信を要求してきた受信装置までのホップ数を計測する。ここでホップ数とは、ＩＰパケットが通過するルーターの台数のことであり、例えばtraceroute（tracert）等のコマンドにより計測することができる。なお、ホップ数は、ネットワークにおける２つの装置間の距離を表すといえる。
パケット送受信部１０６は、伝送路１０７へのパケットの送信及び伝送路１０７からのパケットの受信をする。例えばホップ数計測部１０５が行うホップ数計測の際には、計測用のパケットの送受信もパケット送受信部１０６で行われる。
伝送路１０７は各種ネットワークに代表される伝送路であり、本実施形態においては、パケット化した符号化データ等を送信するネットワークである。
【００１５】
次に、本実施形態の受信装置の構成を説明する。受信装置は、パケット送受信部、出力部及び制御部を備える。受信装置のパケット送受信部は、伝送路１０７へのパケットの送信及び伝送路１０７からのパケットの受信ができ、送信装置１００との通信等に使われる。受信装置の出力部は、送信装置１００から受信した動画像や音声等のデータを出力する。受信装置の出力部は、例えば、動画像を表示するディスプレイや音声を出力するスピーカーを備える。受信装置の制御部は、受信装置全体を制御する。受信装置の制御部は、例えば、送信装置１００に送るパケットを生成して、受信装置のパケット送受信部に送信を指示する。また、受信装置の制御部は、受信装置のパケット送受信部から受信したパケットが送信装置１００から送られた動画像や音声等のデータのとき、受信装置の出力部にこの受信データの出力を指示する。
【００１６】
なお、本実施形態の送信装置１００及び受信装置はそれぞれ単一のコンピュータ装置で実現してもよいし、必要に応じて複数のコンピュータ装置に各機能を分散して実現してもよい。複数のコンピュータ装置で実現する場合は、互いに通信可能なようにLocal Area Network（ＬＡＮ）等で接続される。
【００１７】
次に、本実施形態の送信装置１００による配信制御の詳細について、図２を参照して説明する。図２は、本実施形態の送信装置１００が通信方式を決定する処理の例を示すフローチャートである。図２は、送信装置１００がＲＴＳＰのＤＥＳＣＲＩＢＥメソッドを受信してから、そのレスポンスとしてＳＤＰを用いて記述されたセッション情報を通知するまでの処理を示す。なお、ＤＥＳＣＲＩＢＥメソッドによって、受信装置は、受信装置が送信装置に要求するデータ（メディア）に関するセッション情報を要求する。
【００１８】
まず、送信装置１００の配信制御部１０４は、ＲＴＳＰのＤＥＳＣＲＩＢＥメソッドを受信装置から受信する（ステップＳ２０１）。次に、配信制御部１０４は、受信装置までのネットワークの状況に基づいて、受信装置がマルチキャストでの受信ができる状態であるか否かを判断する。本実施形態では、次に説明するステップＳ２０２及びＳ２０３の処理の結果により受信装置がマルチキャストでの受信ができる状態であるか否かを判断する。
パケット送受信部１０６は、配信制御部１０４の指示により、ホップ数計測部１０５に対し、ＤＥＳＣＲＩＢＥメソッドを送信してきた受信装置までのホップ数の計測を指示する。ホップ数計測部１０５は、配信制御部１０４からの指示を受け、ホップ数の計測を行い（ステップＳ２０２）、計測結果を配信制御部１０４へ通知する。
【００１９】
配信制御部１０４は、ホップ数の計測結果とマルチキャストのＴＴＬの初期値との比較を行う（ステップＳ２０３）。ここで、ＴＴＬ（Time To Live）とは、パケットの有効期間を表す値であり、２５５までの整数値で表され、パケットがルーター等を１回経由するたびに値が１減少する。ＴＴＬが０になったパケットはその時点で廃棄されるため、マルチキャストを行う際には、ＴＴＬの初期値は適切な値に設定される。ＴＴＬは、パケットがルーター等を１回経由するたびに値が１減少するものであり、ホップ数と同様に、ネットワークにおける２つの装置間の距離を表すといえる。
【００２０】
配信制御部１０４は、受信装置までのホップ数がマルチキャストのＴＴＬの初期値より大きいと判定したとき（ステップＳ２０３のＹｅｓ）、受信装置はマルチキャストでメディアを受信できない状態である、と判断する。そして、配信制御部１０４は通信方式にユニキャストを使って受信装置にメディアを配信することに決定する。ＳＤＰ生成部１０３は、配信制御部１０４の指示により、ＳＤＰを用いて記述されたユニキャスト用のセッション情報を生成する（ステップＳ２０４）。
一方、配信制御部１０４は、受信装置までのホップ数がマルチキャストのＴＴＬの初期値より大きくないと判定したとき（ステップＳ２０３のＮｏ）、受信装置はマルチキャストでメディアを受信できる状態である、と判断する。そして、配信制御部１０４は通信方式にマルチキャストを使って受信装置にメディアを配信することに決定する。ＳＤＰ生成部１０３は、配信制御部１０４の指示により、ＳＤＰを用いて記述されたマルチキャスト用のセッション情報を生成する（ステップＳ２０５）。
次に、配信制御部１０４は、ステップＳ２０４又はステップＳ２０５で生成されたセッション情報を、ＤＥＳＣＲＩＢＥメソッドのレスポンスとして、パケット送受信部１０６を介して、受信装置に通知する（ステップＳ２０６）。
こうして図２に示される処理が終了する。
【００２１】
次に、ステップＳ２０４及びＳ２０５で生成されるセッション情報の例について、図３を参照して説明する。図３は、ＳＤＰを用いて記述されたユニキャスト用及びマルチキャスト用のセッション情報の例である。
図３のＳＤＰ３０１は、ＳＤＰを用いて記述されたユニキャスト用のセッション情報であり、ＳＤＰ３０２は、ＳＤＰを用いて記述されたマルチキャスト用のセッション情報である。ＳＤＰ３０１及びＳＤＰ３０２は、いずれも、メディアとしてＪＰＥＧの動画データが１つある場合の例である。マルチキャスト用のＳＤＰ３０２は、ＴＴＬの初期値が４となっている。図２のステップＳ２０３では、このＴＴＬの初期値とホップ数とを比較する。なお、ＳＤＰ３０１及びＳＤＰ３０２には、セッション情報に１つのメディアのみ記述されているが、動画と音声等、複数のメディアが記述されてもよい。
【００２２】
次に、ＤＥＳＣＲＩＢＥメソッドのレスポンス通知後の送信装置１００の処理について、図４を参照して説明する。ＤＥＳＣＲＩＢＥメソッドのレスポンスとしてセッション情報を受信した受信装置は、ＳＥＴＵＰメソッドを送信装置１００に通知する。図４は、本実施形態の送信装置１００がセッション情報通知後にＳＥＴＵＰメソッド受信したときの処理の例を示すフローチャートである。図４は、ＲＴＳＰのＳＥＴＵＰメソッドを受信してから、その要求に応じてメディアを配信するまでの処理を示す。
【００２３】
送信装置１００の配信制御部１０４は、ＲＴＳＰのＳＥＴＵＰメソッドを受信すると（ステップＳ４０１）、ＤＥＳＣＲＩＢＥメソッドのレスポンスで通知したセッション情報がマルチキャスト用か否か判断する（ステップＳ４０２）。
ステップＳ４０２においてマルチキャスト用であると判断した場合（ステップＳ４０２のＹｅｓ）、配信制御部１０４は、受信装置からのＳＥＴＵＰメソッドにおいて、通信方式にマルチキャストが要求されているか否かを判断する（ステップＳ４０３）。
続いてＳＥＴＵＰメソッドでマルチキャストが要求されている場合（ステップＳ４０３のＹｅｓ）、送信装置１００は、次のようにマルチキャストでメディアを配信する。まず、送信装置１００のパケット送受信部１０６は、配信制御部１０４からの指示により、受信装置からのＳＥＴＵＰメソッドのレスポンスとして、成功の旨を送信する。こうしてメディアの配信の準備が完了する。次に、受信装置は送信装置１００にＰＬＡＹメソッドを送信する。次に、送信装置１００のパケット送受信部１０６は、ＰＬＡＹメソッドを受信し、配信制御部１０４からの指示により、成功の旨のレスポンスを送信する。そして、送信装置１００のパケット送受信部１０６は、配信制御部１０４からの指示により、ＲＴＰによるマルチキャストでのメディアの配信を開始する（ステップＳ４０５）。
一方、ステップＳ４０３において、ＳＥＴＵＰメソッドでユニキャストが要求されている場合（ステップＳ４０３のＮｏ）、配信制御部１０４は、当該メディアの配信を中止する（ステップＳ４０６）。
【００２４】
ステップＳ４０２においてユニキャスト用であると判断した場合（ステップＳ４０２のＮｏ）、配信制御部１０４は、受信装置からのＳＥＴＵＰメソッドにおいて、通信方式にユニキャストが要求されているか否かを判断する（ステップＳ４０４）。
続いてＳＥＴＵＰメソッドの要求もユニキャストだった場合（ステップＳ４０４のＹｅｓ）、送信装置１００は、ユニキャストでメディアを配信する（ステップＳ４０７）。ステップＳ４０７でのユニキャストでのメディアの配信は、マルチキャストとユニキャストとの違いを除き、ステップＳ４０５と同様の手順で行われる。
一方、ステップＳ４０４においてＳＥＴＵＰメソッドの要求がマルチキャストの場合（ステップＳ４０４のＮｏ）、当該メディアの配信は中止する（ステップＳ４０６）。
つまり、ＤＥＳＣＲＩＢＥメソッドのレスポンスで通知したセッション情報に記載の通信方式と、ＳＥＴＵＰメソッドで要求された通信方式とが合致した場合のみ、合致した通信方式によるメディアの配信を開始する。
【００２５】
以上のように、受信装置がマルチキャストでメディアを受信できるか否かによって、受信装置からの配信要求をマルチキャストに集約することで、生成するストリームの数やネットワークの使用帯域を少なくすることができる。したがって、ユニキャスト及びマルチキャストが使える通信環境で、送信装置１００及び伝送路１０７のリソースを効率的に利用できる。
【００２６】
＜第２実施形態＞
次に、本発明の第２実施形態について、第１実施形態との差異を中心に説明する。上述の第１実施形態では、受信装置までのホップ数とマルチキャストのＴＴＬの初期値との比較によって、メディアの配信方式をユニキャストにするかマルチキャストにするか決定した。これに対して、本実施形態では、更にその他の要因を組み合わせることで通信方式を決定する。この例を以下に説明する。
【００２７】
はじめに図５を参照して本実施形態の第１の例を説明する。本例の通信方式の決定には、受信装置から要求されたメディアが既にマルチキャスト配信されているか否かの判断が含まれる。図５は、本例の送信装置１００が通信方式を決定する処理の例を示すフローチャートである。
【００２８】
送信装置１００のパケット送受信部１０６は、ＲＴＳＰのＤＥＳＣＲＩＢＥメソッドを受信する（ステップＳ５０１）。次に、送信装置１００の配信制御部１０４は、ＤＥＳＣＲＩＢＥメソッドによって受信装置から要求されたメディアが、既にマルチキャストで配信されているか否かを判断する（ステップＳ５０２）。
ステップＳ５０２において、要求されたメディアが既にマルチキャストで配信されている場合（ステップＳ５０２のＹｅｓ）、配信制御部１０４は、受信装置がマルチキャストの受信が可能か否か判断する（ステップＳ５０３）。ステップＳ５０３の判断は、図２に示されるステップＳ２０２及びステップＳ２０３と同様に行う。すなわち、ホップ数計測部１０５が送信装置１００から受信装置までのホップ数を計測する。そして、配信制御部１０４は、計測されたホップ数とマルチキャストのＴＴＬの初期値とを比較して、受信装置がマルチキャストの受信が可能か否か判断する。
【００２９】
次に、ステップＳ５０３の判断がＹｅｓの場合、配信制御部１０４は、既に配信しているマルチキャストのデータストリームを受信装置に受信させることによって、受信装置から要求されたメディアを配信することに決定する。そして、ＳＤＰ生成部１０３は、配信制御部１０４の指示により、ＳＤＰを用いて記述されたマルチキャスト用のセッション情報を生成する（ステップＳ５０４）。
一方、ステップＳ５０２の判断がＮｏの場合、及びステップＳ５０３の判断がＮｏの場合、配信制御部１０４は、通信方式にユニキャストを使って受信装置にメディアを配信することに決定する。そして、ＳＤＰ生成部１０３は、配信制御部１０４の指示により、ＳＤＰを用いて記述されたユニキャスト用のセッション情報を生成する（ステップＳ５０５）。
次に、配信制御部１０４は、ステップＳ５０４又はステップＳ５０５で生成されたセッション情報を、ＤＥＳＣＲＩＢＥメソッドのレスポンスとして、パケット送受信部１０６を介して、受信装置に通知する（ステップＳ５０６）。
こうして図５に示される処理が終了する。
なお、ステップＳ５０６以降は、第１実施形態の図４に示される処理と同様の処理によって、マルチキャスト又はユニキャストでメディアが配信されたり、配信が中止されたりする。マルチキャストで配信するとき、送信装置１００は、既にマルチキャストで配信しているメディアのデータストリームを受信装置が受信するようにする。
【００３０】
ところで、ＤＥＳＣＲＩＢＥメソッドによって受信装置から要求されたメディアが複数の場合、配信制御部１０４は、図５のステップＳ５０２の判断をメディア毎に行い、メディア毎に通信方式を決定してもよい。例えば、受信装置が動画と音声という２つのメディアを要求した場合、配信制御部１０４はそれぞれのメディアについて通信方式を決定する。そして、ＳＤＰ生成部１０３はこの決定が反映されたセッション情報を生成する。
図６は、受信装置から動画と音声という２つのメディアが要求され、それぞれのメディアについて異なる通信方式が用いられる決定がされたときにＳＤＰ生成部１０３が生成するセッション情報の例である。
図６のＳＤＰ６０１は、動画のメディアであるＪＰＥＧのデータがマルチキャストであり、音声のメディアであるＧ．７１１のデータがユニキャストである場合の、ＳＤＰを用いて記述されたセッション情報の例である。ＳＤＰ６０１の一部であるＳＤＰ６０２がＪＰＥＧのデータについての記述であり、ＳＤＰ６０３がＧ．７１１のデータについての記述である。
図６のＳＤＰ６０４は、ＪＰＥＧのデータがユニキャストであり、Ｇ．７１１のデータがマルチキャストである場合の、ＳＤＰを用いて記述されたセッション情報の例である。ＳＤＰ６０４の一部であるＳＤＰ６０５がＪＰＥＧのデータについての記述であり、ＳＤＰ６０６がＧ．７１１のデータについての記述である。
なお、受信装置から要求されたメディアが複数の場合におけるメディア毎の通信方式の決定は、本例以外の実施形態で行ってもよい。
【００３１】
次に、図７を参照して本実施形態の第２の例を説明する。本例の通信方式の決定には、受信装置から要求されたメディアのユニキャストでの配信数が、閾値に達しているか否かの判断が含まれる。図７は、本例の送信装置１００が通信方式を決定する処理の例を示すフローチャートである。
送信装置１００のパケット送受信部１０６は、ＲＴＳＰのＤＥＳＣＲＩＢＥメソッドを受信する（ステップＳ７０１）。
送信装置１００の配信制御部１０４は、ＤＥＳＣＲＩＢＥメソッドによって受信装置から要求されたメディアのユニキャストでの配信数が、閾値に達しているか否かを判断する（ステップＳ７０２）。
【００３２】
ステップＳ７０２において、要求されたメディアのユニキャスト配信数が既に閾値に達している場合（ステップＳ７０２のＹｅｓ）、配信制御部１０４は、受信装置がマルチキャストの受信が可能か否か判断する（ステップＳ７０３）。ステップＳ７０３の判断は、図２に示されるステップＳ２０２及びステップＳ２０３と同様に行う。すなわち、ホップ数計測部１０５が送信装置１００から受信装置までのホップ数を計測する。そして、配信制御部１０４は、計測されたホップ数とマルチキャストのＴＴＬの初期値とを比較して、受信装置がマルチキャストの受信が可能か否か判断する。
【００３３】
次に、ステップＳ７０３の判断がＹｅｓの場合、配信制御部１０４は、通信方式にマルチキャストを使って受信装置にメディアを配信することに決定する。そして、ＳＤＰ生成部１０３は、配信制御部１０４の指示により、ＳＤＰを用いて記述されたマルチキャスト用のセッション情報を生成する（ステップＳ７０４）。  一方、ステップＳ７０２の判断がＮｏの場合、及びステップＳ７０３の判断がＮｏの場合、配信制御部１０４は、要求されたメディアをユニキャストで配信することに決定する。そして、ＳＤＰ生成部１０３は、配信制御部１０４の指示により、ＳＤＰを用いて記述されたユニキャスト用のセッション情報を生成する（ステップＳ７０５）。
次に、配信制御部１０４は、ステップＳ７０４又はステップＳ７０５で生成されたセッション情報を、ＤＥＳＣＲＩＢＥメソッドのレスポンスとして、パケット送受信部１０６を介して、受信装置に通知する（ステップＳ７０６）。
こうして図７に示される処理が終了する。
なお、ステップＳ７０６以降は、第１実施形態の図４に示される処理と同様の処理によって、マルチキャスト又はユニキャストでメディアが配信されたり、配信が中止されたりする。
【００３４】
次に、図８を参照して本実施形態の第３の例を説明する。本例の通信方式の決定には、受信装置から要求されたメディアの配信ビットレートが、閾値に達しているか否かの判断が含まれる。図８は、本例の送信装置１００が通信方式を決定する処理の例を示すフローチャートである。
【００３５】
送信装置１００のパケット送受信部１０６は、ＲＴＳＰのＤＥＳＣＲＩＢＥメソッドを受信する（ステップＳ８０１）。送信装置１００の配信制御部１０４は、ＤＥＳＣＲＩＢＥメソッドによって受信装置から要求されたメディアの配信ビットレートが、閾値に達しているか否かを判断する（ステップＳ８０２）。配信ビットレートは、一定時間当たりのデータの送信量である。
【００３６】
ステップＳ８０２において、要求されたメディアの配信ビットレートが閾値に達している場合（ステップＳ８０２のＹｅｓ）、配信制御部１０４は、受信装置がマルチキャストの受信が可能か否か判断する（ステップＳ８０３）。ステップＳ８０３の判断は、図２に示されるステップＳ２０２及びステップＳ２０３と同様に行う。すなわち、ホップ数計測部１０５が送信装置１００から受信装置までのホップ数を計測する。そして、配信制御部１０４は、計測されたホップ数とマルチキャストのＴＴＬの初期値とを比較して、受信装置がマルチキャストの受信が可能か否か判断する。
【００３７】
ステップＳ８０３の判断がＹｅｓの場合、配信制御部１０４は、通信方式にマルチキャストを使って受信装置にメディアを配信することに決定する。そして、ＳＤＰ生成部１０３は、配信制御部１０４の指示により、ＳＤＰを用いて記述されたマルチキャスト用のセッション情報を生成する（ステップＳ８０４）。
一方、ステップＳ８０２の判断がＮｏの場合、及びステップＳ８０３の判断がＮｏの場合、配信制御部１０４は、要求されたメディアをユニキャストで配信することに決定する。そして、ＳＤＰ生成部１０３は、配信制御部１０４の指示により、ＳＤＰを用いて記述されたユニキャスト用のセッション情報を生成する（ステップＳ８０５）。
次に、配信制御部１０４は、ステップＳ８０４又はステップＳ８０５で生成されたセッション情報を、ＤＥＳＣＲＩＢＥメソッドのレスポンスとして、パケット送受信部１０６を介して、受信装置に通知する（ステップＳ８０６）。
こうして図８に示される処理が終了する。
なお、ステップＳ８０６以降は、第１実施形態の図４に示される処理と同様の処理によって、マルチキャスト又はユニキャストでメディアが配信されたり、配信が中止されたりする。
【００３８】
図７のステップＳ７０２及び図８のステップＳ８０２では、閾値を使って通信方式をユニキャストにするか否かが判断される。しかし、閾値に段階を設ける等して、所定の閾値に達している場合は、要求されたメディアの配信を中止することに決定してもよい。
この例として、上述した第２の例の変形例を説明する。第２の例の変形例では、閾値として、第１閾値と、第１閾値より大きい第２閾値とを設ける。そして、図７のステップＳ７０２の代わりに次の処理を行う。
送信装置１００の配信制御部１０４は、受信装置から要求されたメディアのユニキャストでの配信数が第１閾値に達していない場合、ステップＳ７０５へ処理を進める。そして、配信制御部１０４は、通信方式にユニキャストを使って受信装置にメディアを配信することに決定する。
配信制御部１０４は、受信装置から要求されたメディアのユニキャストでの配信数が第１閾値に達しているが第２閾値に達していない場合、ステップＳ７０３へ処理を進める。
配信制御部１０４は、受信装置から要求されたメディアのユニキャストでの配信数が第２閾値に達している場合、配信制御部１０４は、メディアの配信を中止することに決定する。
【００３９】
一般に、送信装置１００のハードウェア能力が低い場合や、ネットワークのリソースが少ない場合、送信装置１００が配信するメディアストリームの本数やビットレートを抑えたい場合が考えられる。本実施形態で説明した３つの例は、いずれもマルチキャストに集約可能な場合はマルチキャストに集約することで、送信装置１００、及びネットワークのリソースを有効に使用するために効果がある。
【００４０】
＜第３実施形態＞
次に、本発明の第３実施形態について、第１実施形態及び第２実施形態との差異を中心に説明する。上述の第１実施形態及び第２実施形態では、送信装置１００がＲＴＳＰのＤＥＳＣＲＩＢＥメソッドを受信した段階で、送信装置１００は受信装置がマルチキャストを受信可能か否かによって通信方式を決定することを基本としていた。これに対し、本実施形態では、送信装置１００はユニキャストとマルチキャストの両方の情報を記述したセッション情報を受信装置に通知して、受信装置が通信方式を選択する点が異なる。
図９は、本実施形態の処理の例を示すもので、送信装置１００がＤＥＳＣＲＩＢＥメソッドを受信してから、メディアを配信するまでの処理の例を示すフローチャートである。
【００４１】
送信装置１００のパケット送受信部１０６は、受信装置からＤＥＳＣＲＩＢＥメソッドを受信する（ステップＳ９０１）。次に、送信装置１００の配信制御部１０４は、受信装置までのホップ数をホップ数計測部１０５に計測させ（ステップＳ９０２）、マルチキャストのＴＴＬの初期値と比較する（ステップＳ９０３）。
配信制御部１０４は、受信装置までのホップ数がマルチキャストのＴＴＬの初期値より大きいと判定したとき（ステップＳ９０３のＹｅｓ）、受信装置はマルチキャストでメディアを受信できない状態である、と判断する。そして、配信制御部１０４は、通信方式にユニキャストを使って受信装置にメディアを配信することに決定する。ＳＤＰ生成部１０３は、配信制御部１０４の指示により、ＳＤＰを用いて記述されたユニキャスト用のセッション情報を生成する（ステップＳ９０４）。ステップＳ９０４で生成されるセッション情報にはユニキャストの情報のみが記述される。
一方、配信制御部１０４は、受信装置までのホップ数がマルチキャストのＴＴＬの初期値より大きくないと判断したとき（ステップＳ９０３のＮｏ）、受信装置はマルチキャストでメディアを受信できる状態と判断する。そして、配信制御部１０４は、受信装置にメディアを配信するときの通信方式には、マルチキャスト及びユニキャストのどちらでも使えるとの決定をする。ＳＤＰ生成部１０３は、配信制御部１０４の指示により、ユニキャスト及びマルチキャストの情報がＳＤＰを用いて併記されたセッション情報を生成する（ステップＳ９０５）。
【００４２】
次に、配信制御部１０４は、ステップＳ９０４又はステップＳ９０５で生成されたセッション情報を、ＤＥＳＣＲＩＢＥメソッドのレスポンスとして、パケット送受信部１０６を介して、受信装置に通知する（ステップＳ９０６）。
次に、パケット送受信部１０６は、受信装置に通知したセッション情報の応答として、受信装置からＳＥＴＵＰメソッドを受信する（ステップＳ９０７）。
次に、配信制御部１０４は、ＳＥＴＵＰメソッドでマルチキャストが指定されているか否かを判断する（ステップＳ９０８）。
ＳＥＴＵＰメソッドでユニキャストが指定されている場合（ステップＳ９０８のＮｏ）、パケット送受信部１０６は、配信制御部１０４からの指示により、ユニキャストでメディアを配信する（ステップＳ９１１）。なお、ユニキャストでのメディアの配信は、図４のステップＳ４０７と同様の手順で行われる。
一方、ＳＥＴＵＰメソッドでマルチキャストが指定されている場合（ステップＳ９０８のＹｅｓ）、配信制御部１０４は、通知したセッション情報にマルチキャストの情報が含まれるか否か判断する（ステップＳ９０９）。
マルチキャスト情報が含まれる場合（ステップＳ９０９のＹｅｓ）、パケット送受信部１０６は、配信制御部１０４からの指示により、マルチキャストでメディアを配信する（ステップＳ９１０）。なお、マルチキャストでのメディアの配信は、図４のステップＳ４０５と同様の手順で行われる。
マルチキャスト情報が含まれない場合（ステップＳ９０９のＮｏ）、配信制御部１０４は受信装置への配信を中止する（ステップＳ９１２）。
【００４３】
ここで、図９のステップＳ９０５でＳＤＰ生成部１０３が生成するセッション情報の例について、図１０を参照して説明する。図１０は、同一のメディアについてユニキャスト及びマルチキャストの通信方式が併記され、ＳＤＰを用いて記述されたセッション情報の例を示す図である。なお、図１０は、メディアがＪＰＥＧの動画データである場合の例である。
図１０に示すセッション情報の一部であるＳＤＰ１００１は、ＪＰＥＧのデータをユニキャストで送信する場合の情報である。ＳＤＰ１００２はＪＰＥＧのデータをマルチキャストで送信する場合の情報である。ＳＤＰ１００３は、ＳＤＰ１００１及びＳＤＰ１００２の情報が選択可能なことを示すもので、ＩＥＴＦによりＲＦＣ５８８８で定義されているＳＤＰのグループ化の記述方法で記述されている。
【００４４】
本実施形態は、マルチキャストを受信可能な受信装置が、ネットワークの状況等に合わせて、所望のメディアをユニキャストで受信するかマルチキャストで受信するかを選択可能にする。
【００４５】
＜その他の実施形態＞
上述の実施形態において、送信装置１００の配信制御部１０４は、ホップ数計測部１０５が計測したホップ数を、送信装置１００のメモリ等の記憶手段に保存してもよい。そして、配信制御部１０４は、送信装置１００の記憶手段に保存されているホップ数があるとき、この保存されているホップ数を使う、という処理にしてもよい。これにより、ホップ数を計測する頻度を下げることができ、ネットワークのリソースを効率的に利用できる。
なお、送信装置１００の記憶手段には、送信装置１００から受信装置までのホップ数を予め保存しておいてもよい。
【００４６】
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００４７】
以上、本発明を実施形態と共に説明したが、上記実施形態は本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
【符号の説明】
【００４８】
１００  送信装置
１０１  データパケット生成部
１０２  パケット送信バッファ部
１０３  ＳＤＰ生成部
１０４  配信制御部
１０５  ホップ数計測部
１０６  パケット送受信部
１０７  伝送路
【図１】
2016178540.tif 000003
【図２】
2016178540.tif 000004
【図３】
2016178540.tif 000005
【図４】
2016178540.tif 000006
【図５】
2016178540.tif 000007
【図６】
2016178540.tif 000008
【図７】
2016178540.tif 000009
【図８】
2016178540.tif 000010
【図９】
2016178540.tif 000011
【図１０】
2016178540.tif 000012