送信端末および送信方法
【課題】ＣＰＵ負荷が高くなるのを抑制しつつ、一箇所のスループットの低下が他の送信先に影響しない状態を実現する。
【解決手段】映像ストリームをＴＣＰ等の輻輳制御機構を持つトランスポートプロトコルを利用して、複数の送信先に送信する多地点配信システム等に適用できる。送信端末は、スループットが十分な受信端末Ａ，Ｃに対しては同一スレッド（第１のスレッド）で送信し、スループットが低下している受信端末Ｂに対しては別スレッド（第２のスレッド）で送信する。このような送信方法をとることで、受信端末Ｂ宛てのスループットの低下が受信端末Ａ，Ｃへの送信に影響を与えることがなくなる。また、受信端末Ａ，Ｂ，Ｃに対してそれぞれ別のスレッドで送信するものではなく、スレッド数の増加、従ってＣＰＵ負荷が増加することを抑制できる。
【解決手段】映像ストリームをＴＣＰ等の輻輳制御機構を持つトランスポートプロトコルを利用して、複数の送信先に送信する多地点配信システム等に適用できる。送信端末は、スループットが十分な受信端末Ａ，Ｃに対しては同一スレッド（第１のスレッド）で送信し、スループットが低下している受信端末Ｂに対しては別スレッド（第２のスレッド）で送信する。このような送信方法をとることで、受信端末Ｂ宛てのスループットの低下が受信端末Ａ，Ｃへの送信に影響を与えることがなくなる。また、受信端末Ａ，Ｂ，Ｃに対してそれぞれ別のスレッドで送信するものではなく、スレッド数の増加、従ってＣＰＵ負荷が増加することを抑制できる。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、送信端末および送信方法に関し、特に、映像ストリーム等の同一データをＴＣＰ（TransmissionControl Protocol）等の輻輳制御機構を持つトランスポートプロトコルを利用して複数の送信先に送信する送信端末および送信方法に関する。
【背景技術】
【０００２】
送信端末が、映像ストリーム等の同一データをＴＣＰ等のトランスポートプロトコルを利用して複数の送信先に送信するシステムが考えられる。全ての送信先に対して、同一スレッドでデータを送信する場合、送信処理がブロッキングされる送信先が一箇所でもあると、他の全ての送信先に対する送信処理もブロッキング解除まで待機させられる、その結果、スループットが十分なものも含めて、全ての送信先に対する通信が遅延し、データが欠損する場合もある。
【０００３】
また、全ての送信先に対して、それぞれにスレッドを生成してデータを送信する場合、送信処理は全て並行に行われるので、ある送信先の送信処理がブロッキングされても、他の送信先には影響しない。しかし、生成されるスレッド数が増大するので、ＣＰＵ負荷が高くなる。
【０００４】
また、送信処理を非ブロッキングに設定する場合、送信処理が遅延する場合、ブロッキングされずに即座にエラーとなる．この場合、処理は遅延しないが、スループットが十分な送信先もエラーを起こし、実用に耐えない。
【０００５】
例えば、特許文献１には、受信端末の演算能力やネットワークの帯域に応じて映像の質を変化させる等、送るデータを適正化する技術が記載されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１０−２１２９４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上述したように、送信端末が、映像ストリーム等の同一データをＴＣＰ等のトランスポートプロトコルを利用して複数の送信先に送信する場合、一箇所のスループットの低下が他の送信先にも影響する、あるいは、ＣＰＵ負荷が高くなる、などの不都合ある。
【０００８】
本技術の目的は、ＣＰＵ負荷が高くなるのを抑制しつつ、一箇所のスループットの低下が他の送信先に影響しない状態を実現することにある。
【課題を解決するための手段】
【０００９】
本技術の概念は、
同一データを、輻輳制御機構を持つトランスポートプロトコルを利用して複数の送信先に送信するデータ送信部を備え、
上記データ送信部は、
スループットが十分な送信先に対しては第１のスレッドでまとめて送信し、上記スループットが低下して送信処理が一定時間以上ブロッキングされる送信先に対しては、上記第１のスレッドとは異なる第２のスレッドで送信する状態に移す
送信端末にある。
【００１０】
本技術において、データ送信部により、同一データが、複数の送信先に送信される。この場合、トランスポートプロトコルとして、輻輳制御機構を持つトランスポートプロトコル、例えば、ＴＣＰ（Transmission Control Protocol）、ＳＴＣＰ（StreamControl Transmission Protocol）、ＤＣＣＰ（Datagram CongestionControl Protocol）等である。また、この場合、データは、映像ストリームの他、ファイル等のその他のデータ等も考えられる。ここで、輻輳制御機構とは、ネットワークの状況に応じて転送速度を制御する機構である。ＴＣＰ等のトランスポートプロトコルを利用することで、他の通信を阻害しないように、利用帯域が調整されるが、その代わり必要なスループットを確保できなくなる場合がある。
【００１１】
データ送信部では、スループットが十分な送信先に対しては、第１のスレッドでまとめて送信されるが、スループットが低下して送信処理が一定時間以上ブロッキングされる送信先に対しては、第１のスレッドとは異なる第２のスレッドで送信される。ここで、スループットが低下して送信処理が一定時間以上ブロッキングされる送信先が複数ある場合、各送信先の送信が別個のスレッドで行われるか、あるいは、全ての送信先の送信が共通の１つのスレッドで行われる。
【００１２】
このように、本技術においては、スループットが十分な送信先に対しては、第１のスレッドでまとめて送信し、スループットが低下して送信処理が一定時間以上ブロッキングされる送信先に対しては第２のスレッドで送信するものである。そのため、一箇所のスループットの低下が他の送信先に影響しない状態を実現可能となる。また、本技術は、スループットが低下して送信処理が一定時間以上ブロッキングされる送信先のみを第２のスレッドで送信する状態に移すものである。そのため、ＣＰＵ負荷が高くなるのを抑制可能となる。
【００１３】
本技術において、例えば、データ送信部は、第２のスレッドで送信される送信先のスループットが十分な状態に回復するとき、この送信先に対しては、第１のスレッドで送信する状態に戻す、ようにされてもよい。このようにスループットが十分な状態に回復した送信先に対して第１のスレッドで送信する状態に戻すことで、増加したスレッド数を元に戻すことが可能となり、ＣＰＵ負荷の軽減が可能となる。
【００１４】
この場合、例えば、データ送信部は、第２のスレッドで送信される送信先の送信処理が一定時間以上ブロッキングされないことが所定回数連続するとき、この送信先に対しては、第１のスレッドで送信する状態に戻す、ようにされる。そして、この場合、例えば、データ送信部は、第２のスレッドで送信される送信先の送信処理が一定時間以上ブロッキングされないときカウントアップするカウンタを有し、この送信処理が一定時間以上ブロッキングされるときこのカウンタをリセットし、このカウンタのカウント値に基づいて第２のスレッドで送信される送信先の送信処理が一定時間以上ブロックされないことが所定回数連続するか否かを判断する、ようにされる。
【００１５】
また、本技術において、例えば、データ送信部は、第２のスレッドで送信される送信先のスループットが所定時間回復しないとき、この送信先を切断する、ようにされてもよい。このようにスループットが所定時間回復しない送信先を切断することで、ＣＰＵ負荷の軽減が可能となる。この場合、例えば、データ送信部は、第２のスレッドで送信される送信先の送信処理が一定時間以上ブロッキングされないときカウントアップするカウンタを有し、この送信処理が一定時間以上ブロッキングされるときカウンタをリセットし、所定時間におけるリセット回数に基づいてスループットが所定時間回復しないか否かを判断する、ようにされる。
【発明の効果】
【００１６】
本技術によれば、ＣＰＵ負荷が高くなるのを抑制しつつ、一箇所のスループットの低下が他の送信先に影響しない状態を実現できる。
【図面の簡単な説明】
【００１７】
【図１】本技術の実施の形態としての多地点配信システムの構成例を示すブロック図である。
【図２】多地点配信システムを構成する送信端末の構成例を示すブロック図である。
【図３】同一スレッドで受信端末Ａ，Ｂ，Ｃに送信する送信方法の一例を説明するための図である。
【図４】同一スレッドで複数の受信端末Ａ，Ｂ，Ｃに送信する送信方法の一例であって、受信端末Ｂ宛てのスループットのみ低下している場合の例を説明するための図である。
【図５】別々のスレッドで受信端末Ａ，Ｂ，Ｃに送信する送信方法の一例であって、受信端末Ｂ宛てのスループットのみ低下している場合の例を説明するための図である。
【図６】本技術における送信方法を説明するための図である。
【図７】元スレッド（第１のスレッド）の送信処理フローを示すフローチャートである。
【図８】別スレッド（第２のスレッド）の送信処理フローを示すフローチャートである。
【発明を実施するための形態】
【００１８】
以下、発明を実施するための形態（以下、「実施の形態」とする）について説明する。なお、説明を以下の順序で行う。
１．実施の形態
２．変形例
【００１９】
＜１．実施の形態＞
［多地点配信システム］
図１は、実施の形態としての多地点配信システム１０の構成例を示している。この多地点配信システム１０は、送信端末１００と複数の受信端末２００がＩＰネットワーク３００を介して接続された構成とされている。ここで、受信端末２００は送信先を構成している。送信端末１００には、ビデオカメラ装置等の映像／音声入力装置４００から映像音声入力（映像データ、音声データ）が供給される。送信端末１００では、映像音声入力に対して符号化処理等が行われて、映像データおよび音声データを含む映像ストリームが生成される。そして、送信端末１００では、この映像ストリームが、ＴＣＰ（Transmission Control Protocol）を利用して、データブロック毎に、送信先としての複数の受信端末２００に順次送信される。
【００２０】
ここで、送信端末１００は、スループットが十分な受信端末２００に対しては、第１のスレッドでまとめて送信する。また、送信端末１００は、スループットが低下して送信処理が一定時間以上ブロッキングされる受信端末２００に対しては、第１のスレッドとは異なる第２のスレッドで送信する状態に移す。また、送信端末１００は、第２のスレッドで送信される受信端末２００のスループットが十分な状態に回復するとき、この受信機２００に対しては、第１のスレッドで送信する状態に戻す。さらに、送信端末１００は、第２のスレッドで送信される受信端末２００のスループットが所定時間回復しないとき、この受信端末２００を切断する。
【００２１】
［送信端末の構成］
図２は、送信端末１００の構成例を示している。この送信端末１００は、デバイスとして、エンコーダ１０１を有する。このエンコーダ１０１は、映像／音声入力装置４００（図１参照）からの映像音声入力（（映像データ、音声データ）に対して符号化処理等を行って映像ストリームを生成する。
【００２２】
また、送信端末１００は、アプリケーションとして、アプリケーションバッファ１０２と、送信処理部１０３を有する。アプリケーションバッファ１０２は、エンコーダ１０１で生成される送信ストリームを一時的に蓄積する。送信処理部１０３は、アプリケーションバッファ１０２に蓄積された送信ストリームを、データブロック毎に、複数の受信端末２００に送信する。ここで、アプリケーションは、データ送信部を構成している。
【００２３】
また、送信端末１００は、カーネルとして、ソケットバッファ１０４を有する。このソケットバッファ１０４は、送信処理部１０３が各受信端末２００に送信するデータブロックを一時的に蓄積する。このソケットバッファ１０４は、アプリケーション層とＴＣＰ層との間でデータの受け渡しをするために用いられるバッファである。このソケットバッファ１０４は、ソケット毎に確保されている。
【００２４】
［送信端末における送信方法］
ここで、送信端末１００における送信方法を説明する。ＴＣＰを利用したデータ送信においては、ソケットバッファ１０４に空きができるまで送信処理がブロッキングされる。ライブ配信している場合は、送信処理がブロッキングされている間も、エンコーダ１０１で新たなデータが生成され続ける。そのため、エンコーダ１０１で生成されたデータは、一旦アプリケーションバッファ１０２に蓄積され、その後に送信処理部１０３により順次送信される。
【００２５】
最初に、種々の送信方法を説明する。図３は、同一スレッドで、複数の受信端末２００、ここでは受信端末Ａ，Ｂ，Ｃに送信する例を示している。映像音声入力はエンコーダ１０１に供給され、このエンコーダ１０１ではエンコード処理（符号化処理）を行って、映像ストリームを構成するエンコードされたデータをアプリケーションバッファ１０２に入れる。送信処理部１０３は、アプリケーションバッファ１０２からデータを取り出し、受信端末Ａ，Ｂ，Ｃに順次データを送信する。
【００２６】
この場合、送信処理部１０３は、データブロック毎に、受信端末Ａ，Ｂ，Ｃに順次データを送信することを繰り返す。この場合、受信端末Ａ，Ｂ，Ｃ宛てのスループットはそれぞれ十分なので、問題は発生していない。例えば、受信端末Ａ，Ｂ，Ｃの全てに１０Ｍｂｐsの映像ストリームを送っていて、受信端末Ａ，Ｂ，Ｃ宛てのスループットが全て１０Ｍｂｐｓでネットワーク性能が出ているのであれば、図３に示すような送信方法であっても、問題なく送信することができる。
【００２７】
図４は、図３の例と同様に同一スレッドで受信端末Ａ，Ｂ，Ｃに送信するが、受信端末Ｂ宛てのスループットのみ低下している場合の例である。例えば、受信端末Ａ，Ｃ宛てのスループットが１０Ｍｂｐｓでネットワーク性能が出ているが、受信端末Ｂ宛てのスループットが、ネットワーク状態の不良などによって、１０Ｍｂｐｓより小さくなっている場合である。送信処理部１０３は、データブロック毎に、受信端末Ａ，Ｂ，Ｃに順次データを送信することを繰り返すため、アプリケーションバッファ１０２に未送信データが滞留し、受信端末Ｂ宛てのスループットの低下により、受信端末Ａ，Ｃへの送信にも送信遅延が波及する。
【００２８】
図５は、受信端末Ａ，Ｂ，Ｃに対して別々のスレッドで送信し、受信端末Ｂ宛てのスループットのみ低下している場合の例である。この場合、スレッド毎に送信処理部１０３とアプリケーションバッファ１０２が用意され、並行して処理される。そのため、受信端末Ｂ宛てのスループットの低下が、受信端末Ａ，Ｃへの送信に影響していない。ただし、この例では、スレッド数が増加するので、ＣＰＵ負荷が高くなる。
【００２９】
図６は、この実施の形態における送信方法の一例を示している。この場合、スループットが十分な受信端末Ａ，Ｃに対しては同一スレッド（第１のスレッド）で送信され、スループットが低下している受信端末Ｂに対しては別スレッド（第２のスレッド）で送信される。このような送信方法とすることで、受信端末Ｂ宛てのスループットの低下が受信端末Ａ，Ｃへの送信に影響を与えることがなくなる。しかも、この場合、受信端末Ａ，Ｂ，Ｃに対してそれぞれ別のスレッドで送信するものではなく、図５の送信方法に比べて、スレッド数の増加、従ってＣＰＵ負荷が増加することを抑制できる。
【００３０】
［スレッドの移動処理］
次に、スレッドの移動処理について説明する。この実施の形態における送信方法では、どの受信端末（送信先）を別スレッドで処理するかは、動的に制御される。具体的には、元スレッド（第１のスレッド）は、送信処理にかかった時間を監視し、一定時間以上かかっていれば、スループットが低下していると判断して、別スレッド（第２のスレッド）に移す。また、別スレッドに移した場合、スループットが回復すれば元のスレッドに処理を戻すが、一定時間以上スループットが回復しなければ回復不能と見做して切断する。
【００３１】
図７のフローチャートは、元スレッド（第１のスレッド）の送信処理フローを示している。元スレッドは、この送信処理フローによる処理を、データブロック毎に繰り返す。元スレッドは、複数の受信機２００への送信処理を行うが、送信処理にタイムアウト時間を設け、それを超えた受信機２００への送信は別スレッド（第２のスレッド）に移す。
【００３２】
すなわち、元スレッドは、ステップＳＴ１において、処理を開始し、その後にステップＳＴ２の処理に移る。元スレッドは、このステップＳＴ２において、未送信先を検索する。そして、元スレッドは、ステップＳＴ３において、未送信先があるか否かを判定する。未送信先がないとき、元スレッドは、ステップＳＴ７において、処理を終了する。一方、未送信先があるとき、元スレッドは、ステップＳＴ４において、その送信先に対する送信処理を行う。そして、元スレッドは、ステップＳＴ５において、送信処理時間がタイムアウト時間（例えば、０．２〜０．３秒）を超えたか否かを判定する。
【００３３】
送信処理時間がタイムアウト時間を超えていないとき、元スレッドは、直ちにステップＳＴ２の処理に戻る。一方、送信処理時間がタイムアウト時間を超えたとき、元スレッドは、ステップＳＴ６において、その送信先に対する送信処理を別スレッドに移し、その後に、ステップＳＴ２の処理に戻る。すなわち、スループットが低下して送信処理が一定時間以上ブロッキングされる送信先に対しては、別スレッドで送信する状態に移す。
【００３４】
図８のフローチャートは、別スレッド（第２のスレッド）の送信処理フローを示している。別スレッドは、この送信処理フローによる処理を、データブロック毎に繰り返す。別スレッドは、送信処理を行い、タイムアウトせずに処理が成功した場合は、送信成功数を１だけ増やす。別スレッドは、送信成功数が一定回数を超えたら、元のスレッドに処理を戻して終了する。別スレッドは、タイムアウトした場合、送信成功数をリセットし、過去所定時間のリセット回数が一定回数（閾値）を超えた場合、回復不能と見做して切断する。
【００３５】
すなわち、別スレッドは、ステップＳＴ２１において、処理を開始し、その後に、ステップＳＴ２２の処理に移る。別スレッドは、このステップＳＴ２２において、送信処理を行う。そして、別スレッドは、ステップＳＴ２３おいて、送信処理時間がタイムアウト時間（例えば、０．２〜０．３秒）を超えたか否かを判定する。送信処理時間がタイムアウト時間を超えていないとき、別スレッドは、ステップＳＴ２４において、送信成功数を１だけ増加する。この場合、送信成功数をカウントするＣＰＵ内のカウンタをインクリメントする。
【００３６】
次に、別スレッドは、ステップＳＴ２５において、送信成功数が閾値以上であるか否かを、カウンタのカウント値により判定する。この閾値は、例えば、数秒分程度に相当する値とされる。送信成功数が閾値以上でないとき、別スレッドは、直ちに、ステップＳＴ２７において、処理を終了する。一方、送信成功数が閾値以上であるとき、別スレッドは、ステップＳＴ２６において、当該送信先に対しては元スレッド（第１のスレッド）に処理を戻し、その後に、ステップＳＴ２７において、処理を終了する。すなわち、別スレッドは、この別スレッドで送信される送信先のスループットが十分な状態に回復するとき、この送信先に対しては元スレッドで送信する状態に戻す。
【００３７】
また、ステップＳＴ２３で送信処理時間がタイムアウト時間を超えているとき、別スレッドは、ステップＳＴ２８において、送信成功数をリセットする。この場合、送信成功数をカウントするカウンタをリセットする。そして、別スレッドは、ステップＳＴ２９において、例えば、過去所定時間、例えば過去３０秒間のリセット回数が閾値以上であるか否かを判定する。リセット回数が閾値以上でないとき、別スレッドは、直ちに、ステップＳＴ２７において、処理を終了する。
【００３８】
一方、リセット回数が閾値以上であるとき、別スレッドは、ステップＳＴ３０において、当該送信先を切断し、その後に、ステップＳＴ２７において、処理を終了する。すなわち、別スレッドは、この別スレッドで送信される送信先のスループットが所定時間以上回復しないとき、この送信先を切断する。
【００３９】
図１に示す多地点配信システム１０において、送信端末１００では、スループットが十分な受信機２００に対しては、第１のスレッドでまとめて送信される。また、この送信端末１００では、スループットが低下して送信処理が一定時間以上ブロッキングされる受信機２００に対しては、第２のスレッドで送信される。そのため、一箇所のスループットの低下が他の受信機２００に影響しない状態を実現できる。また、送信端末１００では、スループットが低下して送信処理が一定時間以上ブロッキングされる受信機２００のみを第２のスレッドで送信する状態に移すものである。そのため、ＣＰＵ負荷が高くなるのを抑制できる。これにより、データ配信以外の処理が影響を受けなくなる。
【００４０】
また、図１に示す多地点配信システム１０において、送信端末１００では、第２のスレッドで送信される受信機２００のスループットが十分な状態に回復するとき、この受信機２００に対しては第１のスレッドで送信する状態に戻される。これにより、スレッド数を例えば２から１に減じることができ、ＣＰＵ負荷の軽減が可能となる。
【００４１】
また、図１に示す多地点配信システム１０において、送信端末１００では、第２のスレッドで送信される受信機２００のスループットが所定時間回復しないとき、この受信機２００が切断される。これにより、ＣＰＵ負荷の軽減が可能となる。
【００４２】
＜２．変形例＞
なお、上述実施の形態において、この送信端末１００では、スループットが低下して送信処理が一定時間以上ブロッキングされる受信機２００に対しては第２のスレッド（別スレッド）で送信される。ここで、このような受信機２００が複数存在する場合も考えられる。その場合、各受信機２００の送信が別個のスレッドで行われるようにしてもよいし、あるいは、全ての受信機２００の送信が共通の１つのスレッドで行われるようにしてもよい。なお、各受信機２００の送信が別個のスレッドで行われる場合には、第２のスレッドが複数となり、ＣＰＵ負荷が増加する。
【００４３】
また、上述実施の形態において、送信端末１００は、ＴＣＰを利用して、送信を行っている。しかし、利用可能なトランスポートプロトコルは、ＴＣＰに限定されない。例えば、ＴＣＰと同様に輻輳制御機構を持つ、ＳＴＣＰ（Stream Control Transmission Protocol）、あるいはＤＣＣＰ（Datagram Congestion Control Protocol）等であってもよい。また、上述実施の形態において、送信端末１００は、複数の受信端末２００に、映像データおよび音声データが含まれる映像ストリームを送信するものであるが、ファイルなどのその他のデータを送信する場合にも、本技術を同様に適用できる。
【産業上の利用可能性】
【００４４】
本技術は、例えば、映像ストリームをＴＣＰ等の輻輳制御機構を持つトランスポートプロトコルを利用して複数の送信先に送信する多地点配信システム等に適用できる。
【符号の説明】
【００４５】
１０・・・多地点配信システム
１００・・・送信端末
１０１・・・エンコーダ
１０２・・・アプリケーションバッファ
１０３・・・送信処理部
１０４・・・ソケットバッファ
２００・・・受信端末
３００・・・ＩＰネットワーク
４００・・・映像／音声入力装置
【技術分野】
【０００１】
本技術は、送信端末および送信方法に関し、特に、映像ストリーム等の同一データをＴＣＰ（TransmissionControl Protocol）等の輻輳制御機構を持つトランスポートプロトコルを利用して複数の送信先に送信する送信端末および送信方法に関する。
【背景技術】
【０００２】
送信端末が、映像ストリーム等の同一データをＴＣＰ等のトランスポートプロトコルを利用して複数の送信先に送信するシステムが考えられる。全ての送信先に対して、同一スレッドでデータを送信する場合、送信処理がブロッキングされる送信先が一箇所でもあると、他の全ての送信先に対する送信処理もブロッキング解除まで待機させられる、その結果、スループットが十分なものも含めて、全ての送信先に対する通信が遅延し、データが欠損する場合もある。
【０００３】
また、全ての送信先に対して、それぞれにスレッドを生成してデータを送信する場合、送信処理は全て並行に行われるので、ある送信先の送信処理がブロッキングされても、他の送信先には影響しない。しかし、生成されるスレッド数が増大するので、ＣＰＵ負荷が高くなる。
【０００４】
また、送信処理を非ブロッキングに設定する場合、送信処理が遅延する場合、ブロッキングされずに即座にエラーとなる．この場合、処理は遅延しないが、スループットが十分な送信先もエラーを起こし、実用に耐えない。
【０００５】
例えば、特許文献１には、受信端末の演算能力やネットワークの帯域に応じて映像の質を変化させる等、送るデータを適正化する技術が記載されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１０−２１２９４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上述したように、送信端末が、映像ストリーム等の同一データをＴＣＰ等のトランスポートプロトコルを利用して複数の送信先に送信する場合、一箇所のスループットの低下が他の送信先にも影響する、あるいは、ＣＰＵ負荷が高くなる、などの不都合ある。
【０００８】
本技術の目的は、ＣＰＵ負荷が高くなるのを抑制しつつ、一箇所のスループットの低下が他の送信先に影響しない状態を実現することにある。
【課題を解決するための手段】
【０００９】
本技術の概念は、
同一データを、輻輳制御機構を持つトランスポートプロトコルを利用して複数の送信先に送信するデータ送信部を備え、
上記データ送信部は、
スループットが十分な送信先に対しては第１のスレッドでまとめて送信し、上記スループットが低下して送信処理が一定時間以上ブロッキングされる送信先に対しては、上記第１のスレッドとは異なる第２のスレッドで送信する状態に移す
送信端末にある。
【００１０】
本技術において、データ送信部により、同一データが、複数の送信先に送信される。この場合、トランスポートプロトコルとして、輻輳制御機構を持つトランスポートプロトコル、例えば、ＴＣＰ（Transmission Control Protocol）、ＳＴＣＰ（StreamControl Transmission Protocol）、ＤＣＣＰ（Datagram CongestionControl Protocol）等である。また、この場合、データは、映像ストリームの他、ファイル等のその他のデータ等も考えられる。ここで、輻輳制御機構とは、ネットワークの状況に応じて転送速度を制御する機構である。ＴＣＰ等のトランスポートプロトコルを利用することで、他の通信を阻害しないように、利用帯域が調整されるが、その代わり必要なスループットを確保できなくなる場合がある。
【００１１】
データ送信部では、スループットが十分な送信先に対しては、第１のスレッドでまとめて送信されるが、スループットが低下して送信処理が一定時間以上ブロッキングされる送信先に対しては、第１のスレッドとは異なる第２のスレッドで送信される。ここで、スループットが低下して送信処理が一定時間以上ブロッキングされる送信先が複数ある場合、各送信先の送信が別個のスレッドで行われるか、あるいは、全ての送信先の送信が共通の１つのスレッドで行われる。
【００１２】
このように、本技術においては、スループットが十分な送信先に対しては、第１のスレッドでまとめて送信し、スループットが低下して送信処理が一定時間以上ブロッキングされる送信先に対しては第２のスレッドで送信するものである。そのため、一箇所のスループットの低下が他の送信先に影響しない状態を実現可能となる。また、本技術は、スループットが低下して送信処理が一定時間以上ブロッキングされる送信先のみを第２のスレッドで送信する状態に移すものである。そのため、ＣＰＵ負荷が高くなるのを抑制可能となる。
【００１３】
本技術において、例えば、データ送信部は、第２のスレッドで送信される送信先のスループットが十分な状態に回復するとき、この送信先に対しては、第１のスレッドで送信する状態に戻す、ようにされてもよい。このようにスループットが十分な状態に回復した送信先に対して第１のスレッドで送信する状態に戻すことで、増加したスレッド数を元に戻すことが可能となり、ＣＰＵ負荷の軽減が可能となる。
【００１４】
この場合、例えば、データ送信部は、第２のスレッドで送信される送信先の送信処理が一定時間以上ブロッキングされないことが所定回数連続するとき、この送信先に対しては、第１のスレッドで送信する状態に戻す、ようにされる。そして、この場合、例えば、データ送信部は、第２のスレッドで送信される送信先の送信処理が一定時間以上ブロッキングされないときカウントアップするカウンタを有し、この送信処理が一定時間以上ブロッキングされるときこのカウンタをリセットし、このカウンタのカウント値に基づいて第２のスレッドで送信される送信先の送信処理が一定時間以上ブロックされないことが所定回数連続するか否かを判断する、ようにされる。
【００１５】
また、本技術において、例えば、データ送信部は、第２のスレッドで送信される送信先のスループットが所定時間回復しないとき、この送信先を切断する、ようにされてもよい。このようにスループットが所定時間回復しない送信先を切断することで、ＣＰＵ負荷の軽減が可能となる。この場合、例えば、データ送信部は、第２のスレッドで送信される送信先の送信処理が一定時間以上ブロッキングされないときカウントアップするカウンタを有し、この送信処理が一定時間以上ブロッキングされるときカウンタをリセットし、所定時間におけるリセット回数に基づいてスループットが所定時間回復しないか否かを判断する、ようにされる。
【発明の効果】
【００１６】
本技術によれば、ＣＰＵ負荷が高くなるのを抑制しつつ、一箇所のスループットの低下が他の送信先に影響しない状態を実現できる。
【図面の簡単な説明】
【００１７】
【図１】本技術の実施の形態としての多地点配信システムの構成例を示すブロック図である。
【図２】多地点配信システムを構成する送信端末の構成例を示すブロック図である。
【図３】同一スレッドで受信端末Ａ，Ｂ，Ｃに送信する送信方法の一例を説明するための図である。
【図４】同一スレッドで複数の受信端末Ａ，Ｂ，Ｃに送信する送信方法の一例であって、受信端末Ｂ宛てのスループットのみ低下している場合の例を説明するための図である。
【図５】別々のスレッドで受信端末Ａ，Ｂ，Ｃに送信する送信方法の一例であって、受信端末Ｂ宛てのスループットのみ低下している場合の例を説明するための図である。
【図６】本技術における送信方法を説明するための図である。
【図７】元スレッド（第１のスレッド）の送信処理フローを示すフローチャートである。
【図８】別スレッド（第２のスレッド）の送信処理フローを示すフローチャートである。
【発明を実施するための形態】
【００１８】
以下、発明を実施するための形態（以下、「実施の形態」とする）について説明する。なお、説明を以下の順序で行う。
１．実施の形態
２．変形例
【００１９】
＜１．実施の形態＞
［多地点配信システム］
図１は、実施の形態としての多地点配信システム１０の構成例を示している。この多地点配信システム１０は、送信端末１００と複数の受信端末２００がＩＰネットワーク３００を介して接続された構成とされている。ここで、受信端末２００は送信先を構成している。送信端末１００には、ビデオカメラ装置等の映像／音声入力装置４００から映像音声入力（映像データ、音声データ）が供給される。送信端末１００では、映像音声入力に対して符号化処理等が行われて、映像データおよび音声データを含む映像ストリームが生成される。そして、送信端末１００では、この映像ストリームが、ＴＣＰ（Transmission Control Protocol）を利用して、データブロック毎に、送信先としての複数の受信端末２００に順次送信される。
【００２０】
ここで、送信端末１００は、スループットが十分な受信端末２００に対しては、第１のスレッドでまとめて送信する。また、送信端末１００は、スループットが低下して送信処理が一定時間以上ブロッキングされる受信端末２００に対しては、第１のスレッドとは異なる第２のスレッドで送信する状態に移す。また、送信端末１００は、第２のスレッドで送信される受信端末２００のスループットが十分な状態に回復するとき、この受信機２００に対しては、第１のスレッドで送信する状態に戻す。さらに、送信端末１００は、第２のスレッドで送信される受信端末２００のスループットが所定時間回復しないとき、この受信端末２００を切断する。
【００２１】
［送信端末の構成］
図２は、送信端末１００の構成例を示している。この送信端末１００は、デバイスとして、エンコーダ１０１を有する。このエンコーダ１０１は、映像／音声入力装置４００（図１参照）からの映像音声入力（（映像データ、音声データ）に対して符号化処理等を行って映像ストリームを生成する。
【００２２】
また、送信端末１００は、アプリケーションとして、アプリケーションバッファ１０２と、送信処理部１０３を有する。アプリケーションバッファ１０２は、エンコーダ１０１で生成される送信ストリームを一時的に蓄積する。送信処理部１０３は、アプリケーションバッファ１０２に蓄積された送信ストリームを、データブロック毎に、複数の受信端末２００に送信する。ここで、アプリケーションは、データ送信部を構成している。
【００２３】
また、送信端末１００は、カーネルとして、ソケットバッファ１０４を有する。このソケットバッファ１０４は、送信処理部１０３が各受信端末２００に送信するデータブロックを一時的に蓄積する。このソケットバッファ１０４は、アプリケーション層とＴＣＰ層との間でデータの受け渡しをするために用いられるバッファである。このソケットバッファ１０４は、ソケット毎に確保されている。
【００２４】
［送信端末における送信方法］
ここで、送信端末１００における送信方法を説明する。ＴＣＰを利用したデータ送信においては、ソケットバッファ１０４に空きができるまで送信処理がブロッキングされる。ライブ配信している場合は、送信処理がブロッキングされている間も、エンコーダ１０１で新たなデータが生成され続ける。そのため、エンコーダ１０１で生成されたデータは、一旦アプリケーションバッファ１０２に蓄積され、その後に送信処理部１０３により順次送信される。
【００２５】
最初に、種々の送信方法を説明する。図３は、同一スレッドで、複数の受信端末２００、ここでは受信端末Ａ，Ｂ，Ｃに送信する例を示している。映像音声入力はエンコーダ１０１に供給され、このエンコーダ１０１ではエンコード処理（符号化処理）を行って、映像ストリームを構成するエンコードされたデータをアプリケーションバッファ１０２に入れる。送信処理部１０３は、アプリケーションバッファ１０２からデータを取り出し、受信端末Ａ，Ｂ，Ｃに順次データを送信する。
【００２６】
この場合、送信処理部１０３は、データブロック毎に、受信端末Ａ，Ｂ，Ｃに順次データを送信することを繰り返す。この場合、受信端末Ａ，Ｂ，Ｃ宛てのスループットはそれぞれ十分なので、問題は発生していない。例えば、受信端末Ａ，Ｂ，Ｃの全てに１０Ｍｂｐsの映像ストリームを送っていて、受信端末Ａ，Ｂ，Ｃ宛てのスループットが全て１０Ｍｂｐｓでネットワーク性能が出ているのであれば、図３に示すような送信方法であっても、問題なく送信することができる。
【００２７】
図４は、図３の例と同様に同一スレッドで受信端末Ａ，Ｂ，Ｃに送信するが、受信端末Ｂ宛てのスループットのみ低下している場合の例である。例えば、受信端末Ａ，Ｃ宛てのスループットが１０Ｍｂｐｓでネットワーク性能が出ているが、受信端末Ｂ宛てのスループットが、ネットワーク状態の不良などによって、１０Ｍｂｐｓより小さくなっている場合である。送信処理部１０３は、データブロック毎に、受信端末Ａ，Ｂ，Ｃに順次データを送信することを繰り返すため、アプリケーションバッファ１０２に未送信データが滞留し、受信端末Ｂ宛てのスループットの低下により、受信端末Ａ，Ｃへの送信にも送信遅延が波及する。
【００２８】
図５は、受信端末Ａ，Ｂ，Ｃに対して別々のスレッドで送信し、受信端末Ｂ宛てのスループットのみ低下している場合の例である。この場合、スレッド毎に送信処理部１０３とアプリケーションバッファ１０２が用意され、並行して処理される。そのため、受信端末Ｂ宛てのスループットの低下が、受信端末Ａ，Ｃへの送信に影響していない。ただし、この例では、スレッド数が増加するので、ＣＰＵ負荷が高くなる。
【００２９】
図６は、この実施の形態における送信方法の一例を示している。この場合、スループットが十分な受信端末Ａ，Ｃに対しては同一スレッド（第１のスレッド）で送信され、スループットが低下している受信端末Ｂに対しては別スレッド（第２のスレッド）で送信される。このような送信方法とすることで、受信端末Ｂ宛てのスループットの低下が受信端末Ａ，Ｃへの送信に影響を与えることがなくなる。しかも、この場合、受信端末Ａ，Ｂ，Ｃに対してそれぞれ別のスレッドで送信するものではなく、図５の送信方法に比べて、スレッド数の増加、従ってＣＰＵ負荷が増加することを抑制できる。
【００３０】
［スレッドの移動処理］
次に、スレッドの移動処理について説明する。この実施の形態における送信方法では、どの受信端末（送信先）を別スレッドで処理するかは、動的に制御される。具体的には、元スレッド（第１のスレッド）は、送信処理にかかった時間を監視し、一定時間以上かかっていれば、スループットが低下していると判断して、別スレッド（第２のスレッド）に移す。また、別スレッドに移した場合、スループットが回復すれば元のスレッドに処理を戻すが、一定時間以上スループットが回復しなければ回復不能と見做して切断する。
【００３１】
図７のフローチャートは、元スレッド（第１のスレッド）の送信処理フローを示している。元スレッドは、この送信処理フローによる処理を、データブロック毎に繰り返す。元スレッドは、複数の受信機２００への送信処理を行うが、送信処理にタイムアウト時間を設け、それを超えた受信機２００への送信は別スレッド（第２のスレッド）に移す。
【００３２】
すなわち、元スレッドは、ステップＳＴ１において、処理を開始し、その後にステップＳＴ２の処理に移る。元スレッドは、このステップＳＴ２において、未送信先を検索する。そして、元スレッドは、ステップＳＴ３において、未送信先があるか否かを判定する。未送信先がないとき、元スレッドは、ステップＳＴ７において、処理を終了する。一方、未送信先があるとき、元スレッドは、ステップＳＴ４において、その送信先に対する送信処理を行う。そして、元スレッドは、ステップＳＴ５において、送信処理時間がタイムアウト時間（例えば、０．２〜０．３秒）を超えたか否かを判定する。
【００３３】
送信処理時間がタイムアウト時間を超えていないとき、元スレッドは、直ちにステップＳＴ２の処理に戻る。一方、送信処理時間がタイムアウト時間を超えたとき、元スレッドは、ステップＳＴ６において、その送信先に対する送信処理を別スレッドに移し、その後に、ステップＳＴ２の処理に戻る。すなわち、スループットが低下して送信処理が一定時間以上ブロッキングされる送信先に対しては、別スレッドで送信する状態に移す。
【００３４】
図８のフローチャートは、別スレッド（第２のスレッド）の送信処理フローを示している。別スレッドは、この送信処理フローによる処理を、データブロック毎に繰り返す。別スレッドは、送信処理を行い、タイムアウトせずに処理が成功した場合は、送信成功数を１だけ増やす。別スレッドは、送信成功数が一定回数を超えたら、元のスレッドに処理を戻して終了する。別スレッドは、タイムアウトした場合、送信成功数をリセットし、過去所定時間のリセット回数が一定回数（閾値）を超えた場合、回復不能と見做して切断する。
【００３５】
すなわち、別スレッドは、ステップＳＴ２１において、処理を開始し、その後に、ステップＳＴ２２の処理に移る。別スレッドは、このステップＳＴ２２において、送信処理を行う。そして、別スレッドは、ステップＳＴ２３おいて、送信処理時間がタイムアウト時間（例えば、０．２〜０．３秒）を超えたか否かを判定する。送信処理時間がタイムアウト時間を超えていないとき、別スレッドは、ステップＳＴ２４において、送信成功数を１だけ増加する。この場合、送信成功数をカウントするＣＰＵ内のカウンタをインクリメントする。
【００３６】
次に、別スレッドは、ステップＳＴ２５において、送信成功数が閾値以上であるか否かを、カウンタのカウント値により判定する。この閾値は、例えば、数秒分程度に相当する値とされる。送信成功数が閾値以上でないとき、別スレッドは、直ちに、ステップＳＴ２７において、処理を終了する。一方、送信成功数が閾値以上であるとき、別スレッドは、ステップＳＴ２６において、当該送信先に対しては元スレッド（第１のスレッド）に処理を戻し、その後に、ステップＳＴ２７において、処理を終了する。すなわち、別スレッドは、この別スレッドで送信される送信先のスループットが十分な状態に回復するとき、この送信先に対しては元スレッドで送信する状態に戻す。
【００３７】
また、ステップＳＴ２３で送信処理時間がタイムアウト時間を超えているとき、別スレッドは、ステップＳＴ２８において、送信成功数をリセットする。この場合、送信成功数をカウントするカウンタをリセットする。そして、別スレッドは、ステップＳＴ２９において、例えば、過去所定時間、例えば過去３０秒間のリセット回数が閾値以上であるか否かを判定する。リセット回数が閾値以上でないとき、別スレッドは、直ちに、ステップＳＴ２７において、処理を終了する。
【００３８】
一方、リセット回数が閾値以上であるとき、別スレッドは、ステップＳＴ３０において、当該送信先を切断し、その後に、ステップＳＴ２７において、処理を終了する。すなわち、別スレッドは、この別スレッドで送信される送信先のスループットが所定時間以上回復しないとき、この送信先を切断する。
【００３９】
図１に示す多地点配信システム１０において、送信端末１００では、スループットが十分な受信機２００に対しては、第１のスレッドでまとめて送信される。また、この送信端末１００では、スループットが低下して送信処理が一定時間以上ブロッキングされる受信機２００に対しては、第２のスレッドで送信される。そのため、一箇所のスループットの低下が他の受信機２００に影響しない状態を実現できる。また、送信端末１００では、スループットが低下して送信処理が一定時間以上ブロッキングされる受信機２００のみを第２のスレッドで送信する状態に移すものである。そのため、ＣＰＵ負荷が高くなるのを抑制できる。これにより、データ配信以外の処理が影響を受けなくなる。
【００４０】
また、図１に示す多地点配信システム１０において、送信端末１００では、第２のスレッドで送信される受信機２００のスループットが十分な状態に回復するとき、この受信機２００に対しては第１のスレッドで送信する状態に戻される。これにより、スレッド数を例えば２から１に減じることができ、ＣＰＵ負荷の軽減が可能となる。
【００４１】
また、図１に示す多地点配信システム１０において、送信端末１００では、第２のスレッドで送信される受信機２００のスループットが所定時間回復しないとき、この受信機２００が切断される。これにより、ＣＰＵ負荷の軽減が可能となる。
【００４２】
＜２．変形例＞
なお、上述実施の形態において、この送信端末１００では、スループットが低下して送信処理が一定時間以上ブロッキングされる受信機２００に対しては第２のスレッド（別スレッド）で送信される。ここで、このような受信機２００が複数存在する場合も考えられる。その場合、各受信機２００の送信が別個のスレッドで行われるようにしてもよいし、あるいは、全ての受信機２００の送信が共通の１つのスレッドで行われるようにしてもよい。なお、各受信機２００の送信が別個のスレッドで行われる場合には、第２のスレッドが複数となり、ＣＰＵ負荷が増加する。
【００４３】
また、上述実施の形態において、送信端末１００は、ＴＣＰを利用して、送信を行っている。しかし、利用可能なトランスポートプロトコルは、ＴＣＰに限定されない。例えば、ＴＣＰと同様に輻輳制御機構を持つ、ＳＴＣＰ（Stream Control Transmission Protocol）、あるいはＤＣＣＰ（Datagram Congestion Control Protocol）等であってもよい。また、上述実施の形態において、送信端末１００は、複数の受信端末２００に、映像データおよび音声データが含まれる映像ストリームを送信するものであるが、ファイルなどのその他のデータを送信する場合にも、本技術を同様に適用できる。
【産業上の利用可能性】
【００４４】
本技術は、例えば、映像ストリームをＴＣＰ等の輻輳制御機構を持つトランスポートプロトコルを利用して複数の送信先に送信する多地点配信システム等に適用できる。
【符号の説明】
【００４５】
１０・・・多地点配信システム
１００・・・送信端末
１０１・・・エンコーダ
１０２・・・アプリケーションバッファ
１０３・・・送信処理部
１０４・・・ソケットバッファ
２００・・・受信端末
３００・・・ＩＰネットワーク
４００・・・映像／音声入力装置
【特許請求の範囲】
【請求項１】
同一データを、輻輳制御機構を持つトランスポートプロトコルを利用して複数の送信先に送信するデータ送信部を備え、
上記データ送信部は、
スループットが十分な送信先に対しては第１のスレッドでまとめて送信し、上記スループットが低下して送信処理が一定時間以上ブロッキングされる送信先に対しては、上記第１のスレッドとは異なる第２のスレッドで送信する状態に移す
送信端末。
【請求項２】
上記データ送信部は、
上記第２のスレッドで送信される送信先の上記スループットが十分な状態に回復するとき、該送信先に対しては、上記第１のスレッドで送信する状態に戻す
請求項１に記載の送信端末。
【請求項３】
上記データ送信部は、
上記第２のスレッドで送信される送信先の送信処理が上記一定時間以上ブロッキングされないことが所定回数連続するとき、該送信先に対しては、上記第１のスレッドで送信する状態に戻す
請求項２に記載の送信端末。
【請求項４】
上記データ送信部は、
上記第２のスレッドで送信される送信先の送信処理が上記一定時間以上ブロッキングされないときカウントアップするカウンタを有し、該送信処理が上記一定時間以上ブロッキングされるとき該カウンタをリセットし、該カウンタのカウント値に基づいて上記第２のスレッドで送信される送信先の送信処理が上記一定時間以上ブロッキングされないことが所定回数連続するか否かを判断する
請求項３に記載の送信端末。
【請求項５】
上記データ送信部は、
上記第２のスレッドで送信される送信先の上記スループットが所定時間回復しないとき、該送信先を切断する
請求項２に記載の送信端末。
【請求項６】
上記データ送信部は、
上記第２のスレッドで送信される送信先の送信処理が上記一定時間以上ブロッキングされないときカウントアップするカウンタを有し、該送信処理が上記一定時間以上ブロッキングされるとき該カウンタをリセットし、上記所定時間におけるリセット回数に基づいて上記スループットが所定時間回復しないか否かを判断する
請求項５に記載の送信端末。
【請求項７】
上記データは、映像ストリームである
請求項１に記載の送信端末。
【請求項８】
上記輻輳制御機構を持つトランスポートプロトコルは、ＴＣＰである
請求項１に記載の送信端末。
【請求項９】
同一データを、輻輳制御機構を持つトランスポートプロトコルを利用して複数の送信先に送信する際に、
スループットが十分な送信先に対しては第１のスレッドでまとめて送信し、
上記スループットが低下して送信処理が一定時間以上ブロッキングされる送信先に対しては、上記第１のスレッドとは異なる第２のスレッドで送信する状態に移す
送信方法。
【請求項１】
同一データを、輻輳制御機構を持つトランスポートプロトコルを利用して複数の送信先に送信するデータ送信部を備え、
上記データ送信部は、
スループットが十分な送信先に対しては第１のスレッドでまとめて送信し、上記スループットが低下して送信処理が一定時間以上ブロッキングされる送信先に対しては、上記第１のスレッドとは異なる第２のスレッドで送信する状態に移す
送信端末。
【請求項２】
上記データ送信部は、
上記第２のスレッドで送信される送信先の上記スループットが十分な状態に回復するとき、該送信先に対しては、上記第１のスレッドで送信する状態に戻す
請求項１に記載の送信端末。
【請求項３】
上記データ送信部は、
上記第２のスレッドで送信される送信先の送信処理が上記一定時間以上ブロッキングされないことが所定回数連続するとき、該送信先に対しては、上記第１のスレッドで送信する状態に戻す
請求項２に記載の送信端末。
【請求項４】
上記データ送信部は、
上記第２のスレッドで送信される送信先の送信処理が上記一定時間以上ブロッキングされないときカウントアップするカウンタを有し、該送信処理が上記一定時間以上ブロッキングされるとき該カウンタをリセットし、該カウンタのカウント値に基づいて上記第２のスレッドで送信される送信先の送信処理が上記一定時間以上ブロッキングされないことが所定回数連続するか否かを判断する
請求項３に記載の送信端末。
【請求項５】
上記データ送信部は、
上記第２のスレッドで送信される送信先の上記スループットが所定時間回復しないとき、該送信先を切断する
請求項２に記載の送信端末。
【請求項６】
上記データ送信部は、
上記第２のスレッドで送信される送信先の送信処理が上記一定時間以上ブロッキングされないときカウントアップするカウンタを有し、該送信処理が上記一定時間以上ブロッキングされるとき該カウンタをリセットし、上記所定時間におけるリセット回数に基づいて上記スループットが所定時間回復しないか否かを判断する
請求項５に記載の送信端末。
【請求項７】
上記データは、映像ストリームである
請求項１に記載の送信端末。
【請求項８】
上記輻輳制御機構を持つトランスポートプロトコルは、ＴＣＰである
請求項１に記載の送信端末。
【請求項９】
同一データを、輻輳制御機構を持つトランスポートプロトコルを利用して複数の送信先に送信する際に、
スループットが十分な送信先に対しては第１のスレッドでまとめて送信し、
上記スループットが低下して送信処理が一定時間以上ブロッキングされる送信先に対しては、上記第１のスレッドとは異なる第２のスレッドで送信する状態に移す
送信方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１２−１６９９５９（Ｐ２０１２−１６９９５９Ａ）
【公開日】平成２４年９月６日（２０１２．９．６）
【国際特許分類】
【出願番号】特願２０１１−３０５１０（Ｐ２０１１−３０５１０）
【出願日】平成２３年２月１６日（２０１１．２．１６）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
【公開日】平成２４年９月６日（２０１２．９．６）
【国際特許分類】
【出願日】平成２３年２月１６日（２０１１．２．１６）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
[ Back to top ]