(57)【要約】  本技術は、より柔軟に、広い帯域幅を利用した放送サービスを提供することができるようにする受信装置、送信装置、及び、データ処理方法に関する。受信装置が、物理層よりも上位の上位層で伝送される伝送情報に、放送サービスのストリームが所定の周波数帯域をまたいで配信されていることを示す配信構成情報を含むストリームであって、配信構成情報に応じた配信構成からなるストリームを処理することで、より広い帯域幅を利用した放送サービスを提供することができるようになる。本技術は、例えば、家庭内LANやケーブルオペレータのヘッドエンド、モバイル網の基地局等のネットワークに接続されるFWプロキシ装置に適用することができる。
2018066355.tif 000002
【特許請求の範囲】
【請求項１】
放送サービスのストリームを受信する受信部と、
前記ストリームを処理する処理部と
を備え、
前記ストリームは、物理層よりも上位の上位層で伝送される伝送情報に、放送サービスのストリームが所定の周波数帯域をまたいで配信されていることを示す配信構成情報を含み、
前記処理部は、前記配信構成情報に応じた配信構成からなる前記ストリームを処理する
受信装置。
【請求項２】
前記処理部は、
放送サービスのストリームを受信して、ネットワークに接続されたクライアント装置に送信するプロキシであって、スレーブプロキシに対するマスタプロキシとして機能し、
各プロキシに対して、前記配信構成情報に応じた放送サービスの担当範囲を決定する
請求項１に記載の受信装置。
【請求項３】
前記処理部は、前記配信構成情報に基づいて、常に同時稼働が保証されているプロキシに対して、放送サービスの担当範囲として、所定の周波数帯域をまたいで配信される放送サービスを割り当てる
請求項２に記載の受信装置。
【請求項４】
前記伝送情報は、上位層の制御情報であり、
前記処理部は、各プロキシに対して、前記上位層の制御情報に含まれる前記配信構成情報に応じた放送サービスの担当範囲を決定する
請求項２に記載の受信装置。
【請求項５】
前記上位層の制御情報は、セッション間の優先度を示す優先度情報をさらに含み、
前記処理部は、各プロキシに対して、前記上位層の制御情報に含まれる前記配信構成情報と前記優先度情報に応じた放送サービスの担当範囲を決定する
請求項４に記載の受信装置。
【請求項６】
前記配信構成情報が示す配信構成として、所定の周波数帯域をまたいで配信される放送サービスを配信する際に最低限必要なストリームを伝送する第１のセッションと、当該放送サービスを配信する際に付加的なストリームを伝送する第２のセッションとを含み、
前記優先度情報は、前記第１のセッションの優先度を、前記第２のセッションの優先度よりも高くなるようにする
請求項５に記載の受信装置。
【請求項７】
前記処理部は、前記上位層の制御情報の配信構成を示す情報が更新される度に、各プロキシに対して、前記配信構成情報に応じた放送サービスの担当範囲を決定する
請求項４に記載の受信装置。
【請求項８】
前記伝送情報は、前記伝送情報に対応する放送サービスのストリームが配信されるよりも、所定の期間だけ先に配信される
請求項２に記載の受信装置。
【請求項９】
前記伝送情報は、電子番組表に関する情報である
請求項８に記載の受信装置。
【請求項１０】
前記処理部は、前記伝送情報に基づいて、所定の周波数帯域をまたいで配信される放送サービスの配信を通知する
請求項８に記載の受信装置。
【請求項１１】
前記スレーブプロキシが稼働する他の受信装置は、前記ネットワーク上に１又は複数設置されており、
前記処理部は、
各プロキシと、放送サービスの担当範囲とを対応付けたデータベースを生成し、
前記クライアント装置から、放送サービスのリクエストを受けた場合、前記データベースを参照して、当該放送サービスを担当するプロキシに対し、当該放送サービスのリクエストがリダイレクションされるようにする
請求項２に記載の受信装置。
【請求項１２】
前記上位層の制御情報は、放送サービスごとに配信される制御情報であり、
前記配信構成情報は、ファイル転送用のプロトコルの制御情報に含まれる
請求項４に記載の受信装置。
【請求項１３】
前記所定の周波数帯域は、RFチャネルごとに割り当てられる帯域幅である
請求項１に記載の受信装置。
【請求項１４】
受信装置のデータ処理方法において、
前記受信装置が、
物理層よりも上位の上位層で伝送される伝送情報に、放送サービスのストリームが所定の周波数帯域をまたいで配信されていることを示す配信構成情報を含むストリームであって、前記配信構成情報に応じた配信構成からなる前記ストリームを処理するステップを含む
データ処理方法。
【請求項１５】
物理層よりも上位の上位層で伝送される伝送情報であって、放送サービスのストリームが所定の周波数帯域をまたいで配信されていることを示す配信構成情報を含む前記伝送情報を生成する生成部と、
前記伝送情報を含むストリームを送信する送信部と
を備える送信装置。
【請求項１６】
前記伝送情報は、前記上位層の制御情報である
請求項１５に記載の送信装置。
【請求項１７】
前記上位層の制御情報は、セッション間の優先度を示す優先度情報をさらに含む
請求項１６に記載の送信装置。
【請求項１８】
前記上位層の制御情報は、放送サービスごとに配信される制御情報であり、
前記配信構成情報は、ファイル転送用のプロトコルの制御情報に含まれる
請求項１６に記載の送信装置。
【請求項１９】
前記伝送情報は、電子番組表に関する情報である
請求項１５に記載の送信装置。
【請求項２０】
送信装置のデータ処理方法において、
前記送信装置が、
物理層よりも上位の上位層で伝送される伝送情報であって、放送サービスのストリームが所定の周波数帯域をまたいで配信されていることを示す配信構成情報を含む前記伝送情報を生成し、
前記伝送情報を含むストリームを送信する
ステップを含むデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、受信装置、送信装置、及び、データ処理方法に関し、特に、より柔軟に、広い帯域幅を利用した放送サービスを提供することができるようにした受信装置、送信装置、及び、データ処理方法に関する。
【背景技術】
【０００２】
地上デジタル放送では、RFチャネルのバンド幅として、例えば、6MHzなどの帯域幅が割り当てられる（例えば、非特許文献１参照）。【０００３】
また、画像符号化方式の１つとして、スケーラブル符号化（階層符号化）が知られている（例えば、特許文献１参照）。ここで、スケーラブル符号化（SVC：Scalable Video Coding）とは、基本品質と高品質で用いられるストリームを伝送するベースレイヤと、高品質でのみ用いられるストリームを伝送するエンハンスレイヤとを階層的に符号化する技術をいう。
【先行技術文献】
【特許文献】
【０００４】
【非特許文献１】ATSC Candidate Standard: Physical Layer Protocol(A/322)
【特許文献１】特開2016-076957号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、例えば、地上デジタル放送で、スケーラブル符号化を利用した放送サービスなどの広帯域サービスを実現しようとする場合に、当該放送サービスのストリームが、１つのRFチャネルのバンド幅の帯域内に収まらないことが想定される。【０００６】
しかしながら、このような広い帯域幅を必要とするストリームの放送サービスを提供するための技術方式は確立されておらず、より柔軟に、広い帯域幅を利用した放送サービスを提供できるようにするための提案が要請されていた。【０００７】
本技術はこのような状況に鑑みてなされたものであり、より柔軟に、広い帯域幅を利用した放送サービスを提供することができるようにするものである。
【課題を解決するための手段】
【０００８】
本技術の第１の側面の受信装置は、放送サービスのストリームを受信する受信部と、前記ストリームを処理する処理部とを備え、前記ストリームは、物理層よりも上位の上位層で伝送される伝送情報に、放送サービスのストリームが所定の周波数帯域をまたいで配信されていることを示す配信構成情報を含み、前記処理部は、前記配信構成情報に応じた配信構成からなる前記ストリームを処理する受信装置である。【０００９】
本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面のデータ処理方法は、上述した本技術の第１の側面の受信装置に対応するデータ処理方法である。【００１０】
本技術の第１の側面の受信装置、及び、データ処理方法においては、放送サービスのストリームが受信され、前記ストリームが処理される。また、前記ストリームは、物理層よりも上位の上位層で伝送される伝送情報に、放送サービスのストリームが所定の周波数帯域をまたいで配信されていることを示す配信構成情報を含み、前記配信構成情報に応じた配信構成からなる前記ストリームが処理される。【００１１】
本技術の第２の側面の送信装置は、物理層よりも上位の上位層で伝送される伝送情報であって、放送サービスのストリームが所定の周波数帯域をまたいで配信されていることを示す配信構成情報を含む前記伝送情報を生成する生成部と、前記伝送情報を含むストリームを送信する送信部とを備える送信装置である。【００１２】
本技術の第２の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面のデータ処理方法は、上述した本技術の第２の側面の送信装置に対応するデータ処理方法である。【００１３】
本技術の第２の側面の送信装置、及び、データ処理方法においては、物理層よりも上位の上位層で伝送される伝送情報であって、放送サービスのストリームが所定の周波数帯域をまたいで配信されていることを示す配信構成情報を含む前記伝送情報が生成され、前記伝送情報を含むストリームが送信される。
【発明の効果】
【００１４】
本技術の第１の側面、及び、第２の側面によれば、より柔軟に、広い帯域幅を利用した放送サービスを提供することができる。【００１５】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００１６】
【図１】本技術を適用した伝送システムの一実施の形態の構成を示す図である。
【図２】マスタ・プロキシ装置の構成例を示す図である。
【図３】スレーブ・プロキシ装置の構成例を示す図である。
【図４】クライアント装置の構成例を示す図である。
【図５】放送サーバの構成例を示す図である。
【図６】本技術のIP伝送方式のプロトコルスタックの例を示す図である。
【図７】単一の放送サービスが、複数のブロードキャストストリームにまたがって配信される場合の構成例を示す図である。
【図８】サービス１のS-TSIDメタデータの例を示す図である。
【図９】サービス２のS-TSIDメタデータの例を示す図である。
【図１０】S-TSIDメタデータのフォーマットの例を示す図である。
【図１１】時間帯T1-T2における配信の構成を示す図である。
【図１２】サービス１のS-TSIDメタデータの例を示す図である。
【図１３】サービス２のS-TSIDメタデータの例を示す図である。
【図１４】サービス３のS-TSIDメタデータの例を示す図である。
【図１５】時間帯T2-T3における配信の構成を示す図である。
【図１６】各放送サービスで共通のS-TSIDメタデータの例を示す図である。
【図１７】ROUTEセッション間の優先度を定義した場合における配信の構成を示す図である。
【図１８】サービス２のS-TSIDメタデータの例を示す図である。
【図１９】S-TSIDメタデータのフォーマットの例を示す図である。
【図２０】チューナと放送サービスとのマッピング管理の流れを説明するフローチャートである。
【図２１】図１１の配信の構成におけるSLTメタデータとS-TSIDメタデータの例を示す図である。
【図２２】図１１の配信の構成におけるSLTメタデータとS-TSIDメタデータの例を示す図である。
【図２３】図１１の配信の構成におけるSLTメタデータとS-TSIDメタデータの例を示す図である。
【図２４】図１５の配信の構成におけるSLTメタデータとS-TSIDメタデータの例を示す図である。
【図２５】図１５の配信の構成におけるSLTメタデータとS-TSIDメタデータの例を示す図である。
【図２６】図１５の配信の構成におけるSLTメタデータとS-TSIDメタデータの例を示す図である。
【図２７】SLTメタデータ又はS-TSIDメタデータの更新が検知された場合におけるサービス担当範囲の割り当て処理の流れを説明するフローチャートである。
【図２８】図１１の配信の構成におけるマッピングの例を示す図である。
【図２９】図１５の配信の構成におけるマッピングの例を示す図である。
【図３０】図１５の配信の構成におけるマッピングの例を示す図である。
【図３１】図３０の配信の構成におけるSLTメタデータとS-TSIDメタデータの例を示す図である。
【図３２】セグメントリクエストのリダイレクションの処理の流れを説明するフローチャートである。
【図３３】送信側の処理の流れを説明するフローチャートである。
【図３４】第１の配信構成の場合のESGサービスの構成例を示す図である。
【図３５】第１の配信構成の場合のXMLフラグメントの関係を示す図である。
【図３６】第１の配信構成の場合のXMLインスタンスの例を示す図である。
【図３７】第２の配信構成の場合のESGサービスの構成例を示す図である。
【図３８】第２の配信構成の場合のXMLフラグメントの関係を示す図である。
【図３９】第２の配信構成の場合のESGサービスの画面の表示例を示す図である。
【図４０】第３の配信構成の場合でのブロードキャストストリーム１の構成例を示す図である。
【図４１】第３の配信構成の場合のXMLフラグメントの関係を示す図である。
【図４２】第３の配信構成の場合でのブロードキャストストリーム２の構成例を示す図である。
【図４３】第３の配信構成の場合のXMLフラグメントの関係を示す図である。
【図４４】第３の配信構成の場合のESGサービスの画面の表示例を示す図である。
【図４５】ESGのスケジュールフラグメントの構成例を示す図である。
【図４６】ESGのスケジュールフラグメントのスキーマの例を示す図である。
【図４７】ESGのスケジュールフラグメントのXMLインスタンスの例を示す図である。
【図４８】第３の配信構成の場合のXMLインスタンスの例を示す図である。
【図４９】第３の配信構成の場合のESGサービスの画面の表示例を示す図である。
【図５０】伝送システムの他の構成例を示す図である。
【図５１】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００１７】
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
【００１８】
１．システムの構成
２．本技術の概要
３．ユースケース
４．ROUTEセッション間の優先度
５．チューナと放送サービスとのマッピング管理
６．ESGによるエンドユーザへの通知
７．変形例
８．コンピュータの構成
【００１９】
＜１．システムの構成＞
【００２０】
（伝送システムの構成例）
図１は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
【００２１】
図１において、伝送システム１は、FWプロキシ装置１０−１乃至１０−Ｎ（Ｎ：１以上の整数）、クライアント装置２０−１乃至２０−Ｍ（Ｍ：１以上の整数）、及び放送サーバ４０を含んで構成される。
【００２２】
伝送システム１において、FWプロキシ装置１０−１乃至１０−Ｎと、クライアント装置２０−１乃至２０−Ｍとは、エンドユーザ宅２に構築された家庭内LAN(Local Area Network)等のネットワーク３０を介して、相互に接続され、通信を行うことが可能である。
【００２３】
FWプロキシ装置１０−１は、ネットワーク３０に接続されたデバイスと、放送サーバ４０や送信所５０などからなる放送伝送路６０との間に設置され、フォワードプロキシ（Forward Proxy）としての機能（ゲートウェイ機能）を有している。FWプロキシ装置１０−１は、フォワードプロキシ機能を提供するための専用のサーバや、テレビ受像機やセットトップボックス（STB：Set Top Box）、ネットワークストレージ、ゲーム機などから構成される。
【００２４】
FWプロキシ装置１０−１は、送信所５０を介して、放送サーバ４０から送信されてくる放送波を受信し、放送波から得られるコンテンツのストリームを、ネットワーク３０に接続されたクライアント装置２０−１乃至２０−Ｍのいずれかに送信（転送）する。
【００２５】
FWプロキシ装置１０−２乃至１０−Ｎは、FWプロキシ装置１０−１と同様に、専用のサーバやテレビ受像機などから構成され、フォワードプロキシとしての機能を有している。FWプロキシ装置１０−２乃至１０−Ｎは、放送サーバ４０からの放送波から得られるコンテンツのストリームを、ネットワーク３０に接続されたクライアント装置２０−１乃至２０−Ｍのいずれかに送信（転送）する。
【００２６】
ここで、詳細は後述するが、ネットワーク３０に接続されるFWプロキシ装置１０−１乃至１０−Ｎにおいては、いずれかのFWプロキシ装置１０が、マスタプロキシとして機能し、それ以外のFWプロキシ装置１０が、スレーブプロキシとして機能するマスタ・スレーブ関係を有している。そして、FWプロキシ装置１０−１乃至１０−Ｎが、マスタ・スレーブ関係を有することで、マスタプロキシが稼働するFWプロキシ装置１０によって、各FWプロキシ装置１０に対し、放送サービスの担当範囲が割り当てられる。
【００２７】
なお、FWプロキシ装置１０−１乃至１０−Ｎを、特に区別する必要がない場合、単に、FWプロキシ装置１０と称するものとする。
【００２８】
また、以下の説明では、マスタプロキシとしての機能を有するFWプロキシ装置１０を、マスタ・プロキシ装置１０Ｍと称する一方で、スレーブプロキシとしての機能を有するFWプロキシ装置１０を、スレーブ・プロキシ装置１０Ｓと称して区別する。
【００２９】
なお、マスタ・プロキシ装置１０Ｍの詳細な構成は、図２を参照して後述する。また、スレーブ・プロキシ装置１０Ｓの詳細な構成は、図３を参照して後述する。さらに、以下の説明では、マスタ・プロキシ装置１０Ｍとスレーブ・プロキシ装置１０Ｓを、特に区別する必要がない場合には、FWプロキシ装置１０と称するものとする。つまり、FWプロキシ装置１０は、マスタ・プロキシ装置１０Ｍ又はスレーブ・プロキシ装置１０Ｓのいずれかとなる。
【００３０】
クライアント装置２０−１は、ネットワーク３０を介してFWプロキシ装置１０−１乃至１０−Ｎのいずれから送信（転送）されてくるコンテンツのストリームを受信して再生する受信機である。すなわち、クライアント装置２０−１は、エンドユーザの操作などに応じて、FWプロキシ装置１０−１乃至１０−Ｎのいずれかを介して、放送経由で配信されるコンテンツを再生（又は記録）することができる。
【００３１】
クライアント装置２０−１は、テレビ受像機やセットトップボックス、パーソナルコンピュータ、ゲーム機などの固定受信機、あるいは、スマートフォンや携帯電話機、タブレット型コンピュータなどのモバイル受信機として構成される。さらに、クライアント装置２０−１は、ヘッドマウントディスプレイ（HMD：Head Mounted Display）などのウェアラブルコンピュータであってもよい。
【００３２】
クライアント装置２０−２乃至２０−Ｍは、クライアント装置２０−１と同様に、家庭内で使用される固定受信機又はモバイル受信機などから構成され、FWプロキシ装置１０−１乃至１０−Ｎのいずれかを介して、放送経由で配信されるコンテンツのストリームを受信して再生（又は記録）する。
【００３３】
なお、以下の説明では、クライアント装置２０−１乃至２０−Ｍを、特に区別する必要がない場合、単に、クライアント装置２０と称するものとする。また、クライアント装置２０の詳細な構成は、図４を参照して後述する。
【００３４】
放送サーバ４０は、例えば、放送局などの放送事業者により提供されるサーバであって、送信所５０に設置される送出設備と、専用線などの所定の回線を介して接続される。なお、放送サーバ４０の詳細な構成は、図５を参照して後述する。
【００３５】
放送サーバ４０は、番組やCM等のコンテンツのファイル（データ）や制御情報（シグナリング）を処理し、その結果得られる伝送データを、専用線を介して送信所５０内の送出設備に送信する。そして、送信所５０内の送出設備は、放送サーバ４０からの伝送データに対し、必要な処理（変調処理等）を施すことで、その結果得られる放送波が、放送伝送路６０を介して、エンドユーザ宅２内のFWプロキシ装置１０により受信される。
【００３６】
なお、図１の伝送システムでは、FWプロキシ装置１０とクライアント装置２０が、エンドユーザ宅２内に配置される場合を説明したが、FWプロキシ装置１０は、エンドユーザ宅２内に限らず、例えば、ケーブルオペレータのヘッドエンドや、モバイル網の基地局などに設置されるようにして、より広範囲は領域をカバーできるようにしてもよい。
【００３７】
すなわち、例えば、FWプロキシ装置１０が、ケーブルオペレータのヘッドエンドに設置される場合、クライアント装置２０は、同一のエンドユーザ宅内ではなく、ケーブルテレビのサービスを契約している各エンドユーザ宅内に設置されることになる。また、例えば、FWプロキシ装置１０が、モバイル網の基地局に設置される場合、クライアント装置２０は、モバイルサービスを契約しているエンドユーザが、屋内又は屋外で所持しているデバイス（モバイル受信機）となる。
【００３８】
また、FWプロキシ装置１０やクライアント装置２０は、自動車等の車両に搭載される車載機器であってもよい。さらに、図１の伝送システム１において、ネットワーク３０に接続されるデバイスやサーバの間で行われる通信は、無線通信及び有線通信は勿論、無線通信と有線通信とが混在した通信、すなわち、ある区間では無線通信が行われ、他の区間では有線通信が行われるようなものであってもよい。
【００３９】
（マスタ・プロキシ装置の構成）
図２は、図１のFWプロキシ装置１０のうち、マスタ・プロキシ装置１０Ｍの構成例を示す図である。
【００４０】
図２において、マスタ・プロキシ装置１０Ｍは、処理部１００、チューナ１０１、通信I/F１０２、及び記憶部１０３から構成される。
【００４１】
処理部１００は、例えば、CPU(Central Processing Unit)やマイクロプロセッサ等から構成される。処理部１００は、各種の演算処理や、各部の動作制御などの処理を行う。
【００４２】
チューナ１０１は、アンテナを介して受信された放送波に対し、必要な処理（復調処理等）を施し、その結果得られる多重化ストリームを、処理部１００に供給する。処理部１００は、チューナ１０１から供給される多重化ストリームを処理し、その結果得られるコンテンツのストリームを、通信I/F１０２に供給する。なお、図２においては、１つのチューナ１０１のみが設けられる構成を示しているが、複数のチューナが設けられるようにしてもよい。
【００４３】
通信I/F１０２は、例えば、通信インターフェース回路等から構成される。通信I/F１０２は、ネットワーク３０に接続されたクライアント装置２０から送信されてくるデータを受信し、処理部１００に供給する。また、通信I/F１０２は、処理部１００から供給されるコンテンツのストリームを、ネットワーク３０を介して、クライアント装置２０に送信する。
【００４４】
記憶部１０３は、例えば、半導体メモリやハードディスクドライブ（HDD：Hard Disk Drive）等から構成される。記憶部１０３は、処理部１００からの制御に従い、各種のデータを記憶する。
【００４５】
処理部１００は、マスタプロキシ１１１、UPnP/SSDPサーバ１１２、及びSLS処理系１１３を含む。
【００４６】
マスタプロキシ１１１は、マスタ・プロキシ装置１０Ｍで稼働するサービスであって、スレーブ・プロキシ装置１０Ｓで稼働するスレーブプロキシに対するマスタプロキシとして機能する。
【００４７】
マスタプロキシ１１１は、自身（マスタプロキシ）やスレーブプロキシに対し、放送サービスの担当範囲を割り当てる処理を行う。マスタプロキシ１１１は、自身が割り当てた放送サービスの担当範囲に従い、担当範囲の放送サービスに関する処理を行う。
【００４８】
また、マスタプロキシ１１１は、クライアント装置２０からのリクエストを、対象の放送サービスを担当するスレーブプロキシに通知する。なお、マスタプロキシ１１１により行われる処理の詳細は、図２７及び図３２などを参照して後述する。
【００４９】
UPnP/SSDPサーバ１１２は、マスタ・プロキシ装置１０Ｍで稼働するサービスである。
【００５０】
UPnP/SSDPサーバ１１２は、マスタプロキシ１１１と、ネットワーク３０に接続されるスレーブ・プロキシ装置１０Ｓで稼働するスレーブプロキシとの間のマスタ・スレーブ関係を確立するための処理を行う。また、UPnP/SSDPサーバ１１２は、マスタプロキシ１１１と、ネットワーク３０に接続されるクライアント装置２０との接続を確立するための処理を行う。
【００５１】
SLS処理系１１３は、放送経由で取得される制御情報であるSLS(Service Layer Signaling)に関する処理を行う。SLS処理系１１３によりSLSが処理されることで、多重化ストリームから、所望のコンテンツのストリーム（担当範囲の放送サービスで配信されるコンテンツのストリーム）が得られる。なお、SLSの詳細は、図６を参照して後述する。
【００５２】
マスタ・プロキシ装置１０Ｍは、以上のように構成される。
【００５３】
（スレーブ・プロキシ装置の構成）
図３は、図１のFWプロキシ装置１０のうち、スレーブ・プロキシ装置１０Ｓの構成例を示す図である。
【００５４】
図３において、スレーブ・プロキシ装置１０Ｓは、処理部１５０、チューナ１５１、通信I/F１５２、及び記憶部１５３から構成される。なお、チューナ１５１乃至記憶部１５３は、図２のチューナ１０１乃至記憶部１０３と同様に構成されるため、ここではその説明は省略する。ただし、複数のチューナが設けられるようにしてもよい。
【００５５】
処理部１５０は、例えば、CPUやマイクロプロセッサ等から構成される。処理部１５０は、各種の演算処理や、各部の動作制御などの処理を行う。
【００５６】
処理部１５０は、スレーブプロキシ１６１及びSLS処理系１６２を含む。
【００５７】
スレーブプロキシ１６１は、スレーブ・プロキシ装置１０Ｓで稼働するサービスであって、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１に対するスレーブプロキシとして機能する。
【００５８】
スレーブプロキシ１６１は、マスタプロキシ１１１により割り当てられた放送サービスの担当範囲に従い、担当範囲の放送サービスに関する処理を行う。なお、スレーブプロキシ１６１により行われる処理の詳細は、図２７及び図３２などを参照して後述する。
【００５９】
SLS処理系１６２は、放送経由で取得される制御情報であるSLSに関する処理を行う。SLS処理系１６２によりSLSが処理されることで、多重化ストリームから、所望のコンテンツのストリーム（担当範囲の放送サービスで配信されるコンテンツのストリーム）が得られる。なお、SLSの詳細は、図６を参照して後述する。
【００６０】
スレーブ・プロキシ装置１０Ｓは、以上のように構成される。
【００６１】
（クライアント装置の構成）
図４は、図１のクライアント装置２０の構成例を示す図である。
【００６２】
図４において、クライアント装置２０は、処理部２００、通信I/F２０１、表示部２０２、及びスピーカ２０３から構成される。
【００６３】
処理部２００は、例えば、CPUやマイクロプロセッサ等から構成される。処理部２００は、各種の演算処理や、各部の動作制御などの処理を行う。
【００６４】
通信I/F２０１は、例えば、通信インターフェース回路等から構成される。
【００６５】
通信I/F２０１は、処理部２００からの制御に従い、ネットワーク３０に接続されたマスタ・プロキシ装置１０Ｍに対し、所望の放送サービスで配信されるコンテンツを要求する。また、通信I/F２０１は、ネットワーク３０を介して、マスタ・プロキシ装置１０Ｍ又はスレーブ・プロキシ装置１０Ｓから送信（転送）されてくるコンテンツのストリームを受信し、処理部２００に供給する。
【００６６】
処理部２００は、通信I/F２０１から供給されるコンテンツのストリームを処理し、その結果得られるデータのうち、ビデオデータを、表示部２０２に供給し、オーディオデータを、スピーカ２０３に供給する。
【００６７】
表示部２０２は、例えば、LCD(Liquid Crystal Display)やOELD(Organic Electroluminescence Display)等のディスプレイから構成される。表示部２０２は、処理部２００から供給されるビデオデータに対応する映像を表示する。スピーカ２０３は、処理部２００から供給されるオーディオデータに対応する音声を出力する。
【００６８】
なお、表示部２０２が、タッチパネルの機能を有している場合には、当該タッチパネルに対するエンドユーザの操作に応じた操作信号が処理部２００に供給され、処理部２００は、当該操作信号に応じた処理を行う。また、図４には図示していないが、物理的なボタン等の入力部を設けて、当該入力部に対するエンドユーザの操作に応じた操作信号が、処理部２００に供給されるようにしてもよい。
【００６９】
処理部２００は、アプリケーション２１１及びブラウザ２１２を含む。アプリケーション２１１及びブラウザ２１２により、レンダラ機能が提供される。
【００７０】
アプリケーション２１１は、ネットワーク３０に接続されるクライアント装置２０が、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１との接続を確立するための処理を行う。なお、アプリケーション２１１で行われる処理の詳細は、図３２を参照して後述する。
【００７１】
ブラウザ２１２は、通信I/F２０１から供給されるコンテンツのストリームであって、マスタ・プロキシ装置１０Ｍ又はスレーブ・プロキシ装置１０Ｓにより放送経由で受信されたデータを処理し、コンテンツを再生する。
【００７２】
なお、ブラウザ２１２は、DASHプレーヤとしての機能を有するが、その詳細は、図６を参照して後述する。また、ブラウザ２１２で行われる処理の詳細は、図３２を参照して後述する。
【００７３】
クライアント装置２０は、以上のように構成される。
【００７４】
（放送サーバの構成例）
図５は、図１の放送サーバ４０の構成例を示す図である。
【００７５】
図５において、放送サーバ４０は、コンポーネント処理部４０１、制御情報生成部４０２、ESG生成部４０３、マルチプレクサ４０４、データ処理部４０５、及び送信部４０６から構成される。
【００７６】
コンポーネント処理部４０１は、番組等のコンテンツを構成するコンポーネントのデータを処理し、その結果得られるコンポーネントのストリームを、マルチプレクサ４０４に供給する。
【００７７】
ここで、コンポーネントのデータは、例えば、ビデオやオーディオ、字幕等のデータであり、これらのデータに対し、所定の符号化方式（例えば、スケーラブル符号化（階層符号化）等）に準拠した符号化処理などの処理が行われる。
【００７８】
制御情報生成部４０２は、コンテンツの選局や再生等の上位層の処理で用いられる制御情報（上位層の制御情報）を生成し、マルチプレクサ４０４に供給する。なお、この上位層の制御情報には、LLS(Low Level Signaling)やSLS(Service Layer Signaling)等のシグナリングが含まれるが、その詳細は、図６を参照して後述する。また、本明細書において、上位層とは、物理層よりも上位の階層を意味する。
【００７９】
ESG生成部４０３は、ESG(Electronic Service Guide)情報を生成し、マルチプレクサ４０４に供給する。なお、ESGサービスは、携帯電話の規格策定を行う組織であるOMA（Open Mobile Alliance）によって規定されている電子サービスガイド（電子番組表）であり、その詳細は、図６や図４５などを参照して後述する。
【００８０】
マルチプレクサ４０４は、コンポーネント処理部４０１から供給されるコンポーネントのストリームと、制御情報生成部４０２から供給される上位層の制御情報のストリームと、ESG生成部４０３から供給されるESG情報のストリームとを多重化し、その結果得られる多重化ストリームを、データ処理部４０５に供給する。なお、ここでは、アプリケーションや時刻情報などの他のストリームが多重化されるようにしてもよい。
【００８１】
データ処理部４０５は、マルチプレクサ４０４から供給される多重化ストリームを処理して、所定の形式のパケット（フレーム）を生成し、伝送データとして、送信部４０６に供給する。
【００８２】
送信部４０６は、データ処理部４０５から供給される伝送データを、専用線を介して送信所５０内の送出設備に送信する。
【００８３】
放送サーバ４０は、以上のように構成される。
【００８４】
（本技術のプロトコルスタック）
図６は、本技術のIP伝送方式のプロトコルスタックの例を示す図である。
【００８５】
デジタル放送の伝送方式として、現状では、MPEG2-TS(Transport Stream)方式が広く普及しているが、今後は、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式が普及することが想定されている。
【００８６】
例えば、次世代地上波放送規格の１つであるATSC(Advanced Television Systems Committee)3.0においても、IP伝送方式を採用して、より高度なサービスを提供できるようにすることが期待されている。本技術においても、ATSC3.0等と同様に、IP伝送方式を採用することができる。
【００８７】
図６において、最も下位の階層は、物理層（Physical Layer）とされる。ATSC3.0等のIP伝送方式のデジタル放送では、一方向の放送を利用した伝送に限らず、一部のデータを、双方向の通信を利用して伝送する場合があるが、放送（Broadcast）を利用する場合、その物理層は、サービス（チャネル）のために割り当てられた放送波の周波数帯域等が対応することになる。
【００８８】
物理層（Physical Layer）の上位の階層は、データリンク層（Data Link Layer）とされる。また、データリンク層の上位の階層は、IP(Internet Protocol)層とUDP(User Datagram Protocol)層とされる。IP層とUDP層は、通信の階層モデルにおけるネットワーク層とトランスポート層に相当する層であり、IPアドレスとポート番号により、IPパケットとUDPパケットが特定される。
【００８９】
ここで、ATSC3.0では、制御情報（シグナリング）として、LLS(Low Level Signaling)とSLS(Service Layer Signaling)を用いることが想定されている。LLSは、SLSよりも下位の層で伝送される制御情報である。SLSは、サービス単位の制御情報である。すなわち、ATSC3.0では、トランスポート層の制御情報が、LLSとSLSの２階層で伝送される。
【００９０】
LLSには、SLT(Service List Table)等のメタデータが含まれる。SLTメタデータは、放送サービス（チャネル）の選局に必要な情報など、放送ネットワークにおけるストリームや放送サービスの構成を示す基本情報を含む。このSLTメタデータは、UDPパケットを含むIPパケットであるUDP/IPパケットに含めて伝送される。ただし、SLTメタデータを格納したUDP/IPパケットは、特別なIPアドレスとポート番号で伝送されることになる。
【００９１】
IP層とUDP層に隣接する上位の階層は、ROUTE(Real-time Object Delivery over Unidirectional Transport)とされる。ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。
【００９２】
このROUTEセッションにより、放送サービスごとに、SLSのファイル（Signaling）や、NRT(Non Real Time)コンテンツのファイル（NRT）、DASHセグメントファイル（DASH）などが伝送される。
【００９３】
ここで、SLSは、サービスレベルの制御情報であり、対象の放送サービスに属するコンポーネントの探索と選択に必要な情報や属性などを提供するものである。SLSは、USBD(User Service Bundle Description)，S-TSID(Service-based Transport Session Instance Description)，MPD(Media Presentation Description)等のメタデータを含む。
【００９４】
USBDメタデータは、他のメタデータの取得先などの情報を含む。
【００９５】
S-TSIDメタデータは、LSID(LCT Session Instance Description)をATSC3.0向けに拡張したものであって、ROUTEプロトコルの制御情報である。また、S-TSIDメタデータは、ROUTEセッションで伝送されるEFDT(Extended FDT)を特定することができる。EFDTは、FLUTEで導入されていたFDT(File Delivery Table)を拡張したものであって、転送用の制御情報である。
【００９６】
MPDメタデータは、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)に準拠したストリーミング配信を行うために用いられる、ビデオやオーディオのファイルの制御情報である。
【００９７】
ここで、MPEG-DASHは、OTT-V(Over The Top Video)に従ったストリーミング配信規格であって、HTTP(Hypertext Transfer Protocol)をベースとしたストリーミングプロトコルを用いたアダプティブストリーミング配信に関する規格である。
【００９８】
このMPEG-DASHの規格では、ビデオやオーディオのファイルの制御情報であるメタデータを記述するためのマニフェストファイルと、動画のコンテンツを伝送するためのファイルフォーマットが規定されている。ここでは、前者のマニフェストファイルが、MPD(Media Presentation Description)と称され、後者のファイルフォーマットは、セグメントフォーマットとも称される。
【００９９】
また、トランスポート・プロトコルとして、ROUTEを用いる場合には、ストリーミングのファイルフォーマットとして、MP4ファイルフォーマットを用いることができる。MP4ファイルフォーマットは、ISO/IEC 14496-12で規定されているISO BMFF(ISO Base Media File Format)の派生フォーマットである。
【０１００】
ROUTEセッションで伝送されるセグメントは、イニシャライゼイションセグメント（IS：Initialization Segment）と、メディアセグメント（MS：Media Segment）から構成される。イニシャライゼイションセグメントは、データ圧縮方式等の初期化情報を含んでいる。また、メディアセグメントは、ビデオやオーディオ、字幕のストリームのデータを格納している。すなわち、このメディアセグメントが、DASHセグメント（DASHセグメントファイル）に相当するものである。
【０１０１】
このように、番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータは、ISO BMFFの規格に準じたDASHセグメント単位で、ROUTEセッションにより伝送されることになる。
【０１０２】
なお、NRTコンテンツは、受信機のストレージに一旦蓄積された後で再生が行われるコンテンツである。また、例えば、アプリケーションや電子サービスガイド（ESG：Electronic Service Guide）のファイルなど、NRTコンテンツ以外のファイルを、ROUTEセッションで伝送することもできる。
【０１０３】
また、LLSとしてのSLTメタデータや、SLSとしてのUSBD，S-TSID，MPD等のメタデータは、例えば、XML(Extensible Markup Language)等のマークアップ言語により記述されたテキスト形式のデータとすることができる。
【０１０４】
一方で、双方向の通信（Broadband）を利用する場合、その物理層（Physical Layer）の上位の階層は、データリンク層（Data Link Layer）とされる。また、データリンク層の上位の階層は、ネットワーク層に相当するIP層とされる。IP層に隣接する上位階層は、トランスポート層に相当するTCP(Transmission Control Protocol)層とされ、さらに、TCP層に隣接する上位階層は、アプリケーション層に相当するHTTP層とされる。
【０１０５】
すなわち、これらの階層によって、インターネット等の通信回線で稼働するTCP/IPなどのプロトコルが実装される。
【０１０６】
HTTP層に隣接する上位階層のうち、一部の階層は、制御情報（Signaling）と、NRTコンテンツ（NRT）とされる。この制御情報としては、上述したROUTEセッションで伝送される制御情報など、すべての制御情報が含まれる。また、NRTコンテンツは、通信経由で取得されるコンテンツであって、例えば、アプリケーションが含まれる。
【０１０７】
HTTP層に隣接する上位階層のうち、上述した階層以外の他の階層は、DASHセグメント（DASH）とされる。すなわち、双方向の通信系のストリーミング配信では、VOD(Video On Demand)番組等のコンテンツを構成するサービスコンポーネント（ビデオやオーディオ、字幕等）のストリームデータが、ISO BMFFの規格に準じたDASHセグメント単位で伝送されることになる。
【０１０８】
以上のように、本技術のIP伝送方式のプロトコルスタックにおいては、一方向の放送系の階層と、双方向の通信系の階層の一部が共通のプロトコルとなって、一方向の放送と双方向の通信で、コンテンツを構成するサービスコンポーネントのストリームデータを、ISO BMFFの規格に準じたDASHセグメント単位で伝送することができる。
【０１０９】
そのため、一方向の放送系のストリーミング配信と、双方向の通信系のストリーミング配信の双方を行う場合において、上位の階層のプロトコルが共通化されているため、各装置での実装の負担や処理の負担を軽減することができる。
【０１１０】
なお、図１の伝送システム１では、送信側に、放送系の放送サーバ４０が設けられ、一方向の放送系のストリーミング配信のみに対応した構成を示したが、図６のプロトコルスタックに示したように、本技術は、双方向の通信系のストリーミング配信にも対応することができる。このような双方向の通信系のストリーミング配信に対応した構成については、図５０を参照して後述するものとする。
【０１１１】
＜２．本技術の概要＞
【０１１２】
ところで、ATSC3.0等の放送方式では、RFチャネルのバンド幅（Broadcast Stream）として、6MHzなどの帯域幅が割り当てられるが、広い帯域幅のストリーミングサービスやファイル配信サービス（例えば、スケーラブル符号化を利用した放送サービス）など、この帯域内に収まらない広帯域サービスを、動的にスケジュールして提供する運用が想定される。
【０１１３】
そのため、広帯域サービスを提供するための提案が要請されているが、現状では、そのような要請に応えるための技術方式は確立されていない。
【０１１４】
そこで、本技術では、単一の放送サービス（広帯域サービス）が、複数のブロードキャストストリームにまたがって配信されることを示す情報（以下、配信構成情報という）を、SLSの１つであるS-TSIDメタデータ、又はESG情報などの上位層で伝送される情報（以下、伝送情報という）に含めるようにすることで、より柔軟に、広帯域サービスを提供できるようにする。
【０１１５】
例えば、図１の伝送システム１において、複数のFWプロキシ装置１０が設置される環境で、マスタ・プロキシ装置１０Ｍによって、各FWプロキシ装置１０に対する放送サービスの担当範囲（以下、サービス担当範囲という）を割り当てる際に、S-TSIDメタデータ等の伝送情報に含まれる配信構成情報が参照されるようにする。
【０１１６】
これにより、複数のブロードキャストストリームにまたがって配信される放送サービスについてのサービス担当範囲を、FWプロキシ装置１０に対して、適切に割り当てることができるため、その結果として、より柔軟に、スケーラブル符号化を利用した放送サービスなどの広帯域サービスを提供することが可能となる。
【０１１７】
換言すれば、図１の伝送システム１において、動的にスケジュールされる広帯域サービスを、複数のFWプロキシ装置１０で終端して、ネットワーク３０上のクライアント装置２０に提供する場合に必要となる、FWプロキシ装置１０の間の役割分担プロトコルを実装することが可能となる。
【０１１８】
なお、図１の伝送システム１において、マスタ・プロキシ装置１０Ｍは、クライアント装置２０から、DASHセグメントのリクエストを受けた場合、当該リクエストの放送サービスを担当するFWプロキシ装置１０にリダイレクションを行う。そして、リダイレクションを受けたFWプロキシ装置１０は、割り当てられた放送サービスの範囲内で、放送経由で配信されるコンテンツのストリームを受信し、ネットワーク３０を介してクライアント装置２０に送信することになる。
【０１１９】
（配信構成の例）
図７は、単一の放送サービスが、複数のブロードキャストストリームにまたがって配信される場合の構成例を示す図である。
【０１２０】
ブロードキャストストリームを識別するブロードキャストストリームID（bsid：BroadcastStreamID）として、bsid = bsid-1を持つブロードキャストストリーム１（BroadcastStream-1）は、２つのROUTEセッション（RouteSession-1-1，RouteSession-1-2）から構成される。また、bsid = bsid-2を持つブロードキャストストリーム２（BroadcastStream-2）は、１つのROUTEセッション（RouteSession-2-1）から構成される。
【０１２１】
ここで、ROUTEセッション１−１（RouteSession-1-1）は、１つの独立した放送サービスであるサービス１（Service-1）を転送するのに対して、ROUTEセッション１−２（RouteSession-1-2）とROUTEセッション２−１（RouteSession-2-1）は、２つのROUTEセッションで１つの独立した放送サービスであるサービス２（Service-2）を転送する。
【０１２２】
ただし、放送サービスを識別するサービスID（ServiceId）として、サービス１は、ServiceId = svc-1を持ち、サービス２は、ServiceId = svc-2を持っている。
【０１２３】
ROUTEセッション１−１は、SLSを運ぶLCTセッション（LctSession-1-1-0-SLS（tsi = 0））と、オーディオやビデオのストリームを運ぶLCTセッション（LctSession-1-1-1-AV（tsi = tsi-av-1-1））から構成される。
【０１２４】
ROUTEセッション１−２は、SLSを運ぶLCTセッション（LctSession-1-2-0-SLS（tsi = 0））と、オーディオやビデオのストリームを運ぶLCTセッション（LctSession-1-2-1-AV（tsi = tsi-av-2-1））から構成される。
【０１２５】
ROUTEセッション２−１は、SLSを運ぶLCTセッション（LctSession-2-1-0-SLS（tsi=0））と、オーディオやビデオのストリームを運ぶLCTセッション（LctSession-2-1-1-AV（tsi = tsi-av-2-2））からなる。
【０１２６】
なお、ブロードキャストストリーム１のROUTEセッション１−２と、ブロードキャストストリーム２のROUTEセッション２−１では、LCTセッションで伝送されるサービス２のSLSとして、同一のSLS-svc-2が運ばれる。一方で、ブロードキャストストリーム１のROUTEセッション１−１では、LCTセッションで伝送されるサービス１のSLSとして、SLS-svc-2とは異なるSLS-svc-1が運ばれる。
【０１２７】
ここで、図７に示した配信構成のうち、SLSとしてのS-TSIDメタデータを例示すると、図８及び図９に示すようになる。
【０１２８】
図８は、サービス１についてのSLS（SLS-svc-1）のS-TSIDメタデータの例を示す図である。
【０１２９】
図８において、XML形式のS-TSIDメタデータには、ルート要素としてのS-TSID要素のserviceId属性として、serviceId = svc-1 が記述される。また、S-TSID要素の配下のRS要素のdIpAddr属性として、dIpAddr = dIpAddr-svc-1，さらにRS要素の配下のLS要素のtsi属性として、tsi = tsi-av-1-1 が記述される。
【０１３０】
図９は、サービス２についてのSLS（SLS-svc-2）のS-TSIDメタデータの例を示す図である。
【０１３１】
図９において、XML形式のS-TSIDメタデータには、図８と同様に、S-TSID要素とその配下のRS要素とLS要素が記述されているが、RS要素に、bsid属性が追加されている。すなわち、上段のRS要素には、bsid属性として、bsid = bsid-1 が記述され、下段のRS要素には、bsid属性として、bsid = bsid-2 が記述されている。
【０１３２】
これらのRS要素のbsid属性の値により、単一の放送サービス（サービス２）が、２つのROUTEセッションで構成され、一方のROUTEセッションが、bsid = bsid-1を持つブロードキャストストリーム１で転送され、他方のROUTEセッションが、bsid = bsid-2を持つブロードキャストストリーム２で転送されることを表している。
【０１３３】
なお、上述したように、図７に示した配信構成の例では、ブロードキャストストリーム１と、ブロードキャストストリーム２のいずれにおいても、同一のシグナリングフラグメントであるSLS-svc-2（図９）が運ばれることになる。また、サービス１とサービス２の両方が、１つの放送事業者の放送サーバ４０から提供される場合もあれば、それらの放送サービスごとに、異なる放送事業者の放送サーバ４０から提供される場合もある。
【０１３４】
（S-TSIDの構造）
図１０は、XML形式のS-TSIDメタデータのフォーマットの例を示す図である。
【０１３５】
図１０において、ルート要素のS-TSID要素には、serviceId属性を配置することができる。serviceId属性には、サービスIDが指定される。
【０１３６】
また、S-TSID要素には、１又は複数のROUTEセッションに関する情報を表すためのRS要素が配置される。RS要素は、sIpAddr属性、dIpAddr属性、dport属性、bsid属性、及びLS要素を配置することができる。
【０１３７】
sIpAddr属性には、ROUTEセッションの送信元IPアドレス（source IP address）が指定される。dIpAddr属性には、ROUTEセッションの送信先IPアドレス（destination IP address）が指定される。dport属性には、ROUTEセッションのポート番号が指定される。
【０１３８】
bsid属性には、ブロードキャストストリームID（bsid）を指定することができる。このブロードキャストストリームIDとしては、親要素となるRS要素に対応したROUTEセッションであって、広帯域サービス（複数のブロードキャストストリームをまたいで配信される放送サービス）を構成するROUTEセッションを転送するブロードキャストストリームのブロードキャストストリームIDが指定される。
【０１３９】
LS要素には、LCTチャネルに関する情報が記述される。なお、LS要素は、LCTチャネルごとに、１又は複数配置することができる。LS要素は、tsi属性、bw属性、startTime属性、endTime属性、SrcFlow要素、及びRepairFlow要素を配置することができる。
【０１４０】
tsi属性には、TSIの値が指定される。bw属性には、最大バンド幅が指定される。startTime属性とendTime属性には、開始時刻と終了時刻が指定される。
【０１４１】
SrcFlow要素には、Source Flowに関する情報が指定される。RepairFlow要素には、Repair Flowに関する情報が指定される。
【０１４２】
なお、図１０において、「Use」の項目であるが、"0..1"が指定された場合には、その要素又は属性を指定するかどうかは任意である。また、「Use」の項目として、"1..N"が指定された場合には、その要素又は属性は、１以上指定され、"1"が指定された場合にはその要素又は属性は必ず１つだけ指定される。
【０１４３】
また、「Data Type」の項目であるが、"unsignedShort"や"unsignedInt"が指定された場合、その要素又は属性の値が、整数型であることを示し、"string"が指定された場合には、その要素又は属性の値が、文字列型であることを示している。また、「Data Type」の項目として、"dateTime"が指定された場合には、その要素又は属性が、特定の日時を表すことを示している。
【０１４４】
なお、図１０に示したS-TSIDメタデータのフォーマットは一例であって、例えば、XML形式の以外の他のテキスト形式を採用することもできる。また、S-TSIDメタデータは、テキスト形式に限らず、バイナリ形式であってもよい。
【０１４５】
以上のように、本技術では、伝送情報であるS-TSIDメタデータに、配信構成情報として、RS要素のbsid属性に、広帯域サービス（複数のブロードキャストストリームをまたいで配信される放送サービス）を構成するROUTEセッションを転送するブロードキャストストリームのブロードキャストストリームID（bsid）を指定できるようにすることで、より柔軟に、広帯域サービスを提供することが可能となる。
【０１４６】
＜３．ユースケース＞
【０１４７】
次に、時間帯ごとに放送サービスと、その放送サービスを構成するROUTEセッションとの関係が変化する場合のユースケースについて説明する。このユースケースでは、ある時間軸で、時刻T1，T2，T3が順に経過する場合に、時間帯T1-T2と、時間帯T2-T3における配信の構成を説明する。
【０１４８】
（時間帯T1-T2の配信構成）
図１１は、時間帯T1-T2における配信の構成を示す図である。
【０１４９】
図１１においては、ブロードキャストストリーム１（bsid-1）のROUTEセッション１−１（dIpAddr-svc-1）で、サービス１（svc-1）を転送する。このROUTEセッション１−１のLCTセッションでは、サービス１のSLS（SLS-svc-1）と、サービス１のオーディオやビデオ（AV）のストリームが伝送される。
【０１５０】
また、図１１において、ブロードキャストストリーム１（bsid-1）のROUTEセッション１−２（dIpAddr-svc-2）と、ブロードキャストストリーム２（bsid-2）のROUTEセッション２−１（dIpAddr-svc-2）とで、サービス２（svc-2）を転送する。すなわち、時間帯T1-T2における配信の構成において、サービス２は、２つのブロードキャストストリーム（bsid-1，bsid-2）をまたいで配信される。
【０１５１】
ROUTEセッション１−２のLCTセッションでは、サービス２のSLS（SLS-svc-2）と、サービス２のオーディオやビデオ（AV）のストリームが伝送される。一方で、ROUTEセッション２−１のLCTセッションでは、サービス２のSLS（SLS-svc-2）と、サービス２のオーディオやビデオ（AV）のストリームが伝送される。
【０１５２】
また、図１１において、ブロードキャストストリーム３（bsid-3）のROUTEセッション３−１（dIpAddr-svc-3）で、サービス３（svc-3）を転送する。ROUTEセッション３−１のLCTセッションでは、サービス３のSLS（SLS-svc-3）と、サービス３のオーディオやビデオ（AV）のストリームが伝送される。
【０１５３】
ここで、図１２乃至図１４には、図１１に示した配信の構成における各放送サービスのSLSに含まれるS-TSIDメタデータの例が示されている。
【０１５４】
図１２は、サービス１のSLS（SLS-svc-1）のS-TSIDメタデータの例を示す図である。図１２のS-TSIDメタデータにおいては、サービス１（svc-1）が、１つのROUTEセッション（dIpAddr-svc-1）で構成されることを表している。
【０１５５】
図１３は、サービス２のSLS（SLS-svc-2）のS-TSIDメタデータの例を示す図である。図１３のS-TSIDメタデータにおいては、サービス２（svc-2）が、２つのROUTEセッション（dIpAddr-svc-2）で構成され、一方のROUTEセッションが、bsid = bsid-1を持つブロードキャストストリーム１で転送され、他方のROUTEセッションが、bsid = bsid-2を持つブロードキャストストリーム２で転送されることを表している。
【０１５６】
図１４は、サービス３のSLS（SLS-svc-3）のS-TSIDメタデータの例を示す図である。図１４のS-TSIDメタデータにおいては、サービス３（svc-3）が、１つのROUTEセッションで構成されることを表している。
【０１５７】
このように、時間帯T1-T2における配信の構成では、３つのブロードキャストストリーム（bsid-1，bsid-2，bsid-3）のうち、ブロードキャストストリーム１（bsid-1）とブロードキャストストリーム２（bsid-2）のROUTEセッション（dIpAddr-svc-2）で、サービス２（svc-2）が転送され、当該サービス２（svc-2）は、２つのブロードキャストストリーム（bsid-1，bsid-2）をまたいで配信されている。また、このサービス２（svc-2）が、２つのブロードキャストストリーム（bsid-1，bsid-2）をまたいだ配信の構成となっていることは、サービス２のSLS（SLS-svc-2）のS-TSIDメタデータにより通知することができる。
【０１５８】
（時間帯T2-T3の配信構成）
図１５は、時間帯T2-T3における配信の構成を示す図である。
【０１５９】
図１５においては、ブロードキャストストリーム１（bsid-1）のROUTEセッション１−１（dIpAddr-svc-1）と、ブロードキャストストリーム２（bsid-2）のROUTEセッション２−１（dIpAddr-svc-1）と、ブロードキャストストリーム３（bsid-3）のROUTEセッション３−１（dIpAddr-svc-1）とで、サービス１（svc-1）を転送する。すなわち、時間帯T2-T3における配信の構成において、サービス１は、３つのブロードキャストストリーム（bsid-1，bsid-2，bsid-3）をまたいで配信される。
【０１６０】
ROUTEセッション１−１のLCTセッションでは、サービス１のSLS（SLS-svc-1）と、サービス１のオーディオやビデオ（AV）のストリームが伝送される。同様に、ROUTEセッション２−１とROUTEセッション３−１のLCTセッションでは、サービス１のSLS（SLS-svc-1）と、サービス１のオーディオやビデオ（AV）のストリームが伝送される。
【０１６１】
ここで、図１６には、図１５に示した配信の構成におけるサービス１のSLSに含まれるS-TSIDメタデータの例が示されている。すなわち、図１５の配信の構成では、３つのブロードキャストストリーム（bsid-1，bsid-2，bsid-3）をまたいで、サービス１（svc-1）が配信されるので、SLS（SLS-svc-1）のS-TSIDメタデータは、３つのブロードキャストストリームで共通とされる。
【０１６２】
図１６のS-TSIDメタデータにおいては、サービス１（svc-1）が、３つのROUTEセッション（dIpAddr-svc-1）で構成され、１つ目のROUTEセッション１−１（dIpAddr-svc-1）が、bsid = bsid-1を持つブロードキャストストリーム１で転送されることを表している。
【０１６３】
同様にまた、２つ目のROUTEセッション２−１（dIpAddr-svc-1）が、bsid = bsid-2を持つブロードキャストストリーム２で転送され、３つ目のROUTEセッション３−１（dIpAddr-svc-1）が、bsid = bsid-3を持つブロードキャストストリーム３で転送されることを表している。
【０１６４】
このように、時間帯T2-T3における配信の構成では、３つのブロードキャストストリーム（bsid-1，bsid-2，bsid-3）の各ROUTEセッション（dIpAddr-svc-1）で、サービス１（svc-1）が転送され、当該サービス１（svc-1）は、３つのブロードキャストストリームをまたいで配信されている。また、このサービス１（svc-1）が、３つのブロードキャストストリームをまたいだ配信の構成になっていることは、サービス１のSLS（SLS-svc-1）のS-TSIDメタデータにより通知することができる。
【０１６５】
以上のように、時間帯T1-T2と時間帯T2-T3の配信の構成として、時間帯T1-T2においては、２つのブロードキャストストリーム（bsid-1，bsid-2）のROUTEセッションで、サービス２（svc-2）が転送されるが、その後、時間帯T2-T3になると、３つのブロードキャストストリーム（bsid-1，bsid-2，bsid-3）のROUTEセッションで、サービス１（svc-1）が転送されることになり、時間帯ごとに、配信の構成が変化している。このような時間帯ごとに変化する配信の構成は、SLSのS-TSIDメタデータの内容を更新することで、通知することができる。
【０１６６】
＜４．ROUTEセッション間の優先度＞
【０１６７】
次に、ブロードキャストストリームのROUTEセッション間に、優先度（重要度）を定義する場合におけるS-TSIDメタデータの拡張方法について説明する。
【０１６８】
ここで、ROUTEセッション間に、優先度を定義する運用を行うケースとしては、例えば、スケーラブル符号化（階層符号化）が適用された広帯域サービスなどが想定される。ここで、詳細は後述するが、スケーラブル符号化（SVC）とは、基本品質と高品質で用いられるストリーム（最低限必要なストリーム）を伝送するベースレイヤと、高品質でのみ用いられるストリーム（付加的なストリーム）を伝送するエンハンスレイヤとを階層的に符号化する技術である。
【０１６９】
（優先度を定義した場合の配信構成）
図１７は、ROUTEセッション間の優先度を定義した場合における配信の構成を示す図である。
【０１７０】
図１７においては、ブロードキャストストリーム１（bsid-1）のROUTEセッション１−１（dIpAddr-svc-1）で、サービス１（svc-1）を転送する。このROUTEセッション１−１のLCTセッションでは、サービス１のSLS（SLS-svc-1）と、サービス１のオーディオやビデオ（AV）のストリームが伝送される。
【０１７１】
また、図１７において、ブロードキャストストリーム１（bsid-1）のROUTEセッション１−２（dIpAddr-svc-2）と、ブロードキャストストリーム２（bsid-2）のROUTEセッション２−１（dIpAddr-svc-2）とで、サービス２（svc-2）を転送する。すなわち、図１７の配信構成において、サービス２は、２つのブロードキャストストリーム（bsid-1，bsid-2）をまたいで配信される。
【０１７２】
ROUTEセッション１−２のLCTセッションでは、サービス２のSLS（SLS-svc-2）と、サービス２のオーディオやビデオ（AV）のストリームが伝送される。一方で、ROUTEセッション２−１のLCTセッションでは、サービス２のSLS（SLS-svc-2）と、サービス２のオーディオやビデオ（AV）のストリームが伝送される。
【０１７３】
ここで、図１７の配信構成に、スケーラブル符号化を適用して、例えば、ブロードキャストストリーム２（bsid-2）のROUTEセッション２−１（dIpAddr-svc-2）では、ベースレイヤのストリームを転送し、ブロードキャストストリーム１（bsid-1）のROUTEセッション１−２（dIpAddr-svc-2）では、エンハンスレイヤのストリームを転送する配信構成とした場合を想定する。
【０１７４】
ベースレイヤのストリームは、例えば、通常のフレームレート60fpsで、HD(High Definition)画質のストリームとすることができる。一方で、エンハンスレイヤのストリームは、例えば、ベースレイヤのストリームに基づき、その倍のフレームレート120fpsで、4K（UHD：Ultra High Definition）画質のストリームとして表示可能にするストリームとすることができる。
【０１７５】
そして、受信側のFWプロキシ装置１０は、例えば、チューナが１つで、一度に１つのブロードキャストストリームしか処理できない環境など、ブロードキャストストリーム２（bsid-2）のみしか受信できない環境の場合には、ベースレイヤのストリームのみを処理して、ネットワーク３０に接続されたクライアント装置２０に対し、HD画質（基本品質）の映像を表示させる。
【０１７６】
一方で、受信側のFWプロキシ装置１０は、ブロードキャストストリーム２（bsid-2）と同時に、ブロードキャストストリーム１（bsid-1）も受信可能な環境の場合には、ベースレイヤのストリームとともに、エンハンスレイヤのストリームも処理して、ネットワーク３０に接続されたクライアント装置２０に対し、4K画質（高品質）の映像を表示させる。これにより、クライアント装置２０では、エンハンスレイヤに対応可能な環境では、ベースレイヤのみの環境よりも、より高画質な映像を表示させることができる。
【０１７７】
ここで、図１８には、図１７に示した配信の構成におけるサービス２のSLSに含まれるS-TSIDメタデータの例が示されている。すなわち、図１７の配信の構成では、２つのブロードキャストストリーム（bsid-1，bsid-2）をまたいで、サービス２（svc-2）が配信されるので、SLS（SLS-svc-2）のS-TSIDメタデータは、ROUTEセッション１−２とROUTEセッション２−１で共通とされる。
【０１７８】
図１８のS-TSIDメタデータにおいては、サービス２（svc-2）が、２つのROUTEセッション（dIpAddr-svc-2）で構成され、１つ目のROUTEセッション１−２（dIpAddr-svc-2）が、bsid = bsid-1を持つブロードキャストストリーム１で転送され、２つ目のROUTEセッション２−１（dIpAddr-svc-2）が、bsid = bsid-2を持つブロードキャストストリーム２で転送されることを表している。
【０１７９】
また、図１８のS-TSIDメタデータにおいて、S-TSID要素の配下の各RS要素には、priority属性が追加されている。このpriority属性により、ベースレイヤとエンハンスレイヤとの違いで生じるROUTEセッション間の優先度（重要度）を指定することができる。
【０１８０】
例えば、図１８のS-TSIDメタデータでは、ROUTEセッション１−２に対し、RS要素のpriority属性として、priority = low（優先度：低）が指定される一方で、ROUTEセッション２−１に対し、RS要素のpriority属性として、priority = high（優先度：高）が指定されている。
【０１８１】
これにより、図１７の配信の構成において、ブロードキャストストリーム１（bsid-1）のROUTEセッション１−２よりも、ブロードキャストストリーム２（bsid-2）のROUTEセッション２−１のほうが、より優先度（重要度）の高いROUTEセッションであるとすることができる。
【０１８２】
すなわち、図１７の配信の構成においては、スケーラブル符号化を適用した広帯域サービスであるサービス２を提供するにあたって、ブロードキャストストリーム２（bsid-2）のROUTEセッション２−１は、最低限必要なストリームやNRTファイルが転送されるROUTEセッションであると言える。一方で、ブロードキャストストリーム１（bsid-1）のROUTEセッション１−２は、あればより良い品質のサービスが提供できる（付加的な）ストリームが転送されるROUTEセッションであると言える。
【０１８３】
なお、S-TSIDメタデータのS-TSID要素の配下のRS要素に、priority属性が配置されていない場合、複数のブロードキャストストリームをまたいで配信される放送サービスを提示するためには、複数のブロードキャストストリームにまたがるすべてのROUTEセッションが必須になると解釈することになる。
【０１８４】
（優先度に対応したS-TSIDの構造）
図１９は、ROUTEセッション間の優先度に対応したXML形式のS-TSIDメタデータのフォーマットの例を示す図である。
【０１８５】
図１９のS-TSIDメタデータのフォーマットは、図１０に示したS-TSIDメタデータのフォーマットと比べて、S-TSID要素の配下のRS要素に、sIpAddr属性、dIpAddr属性、dport属性、bsid属性、及びLS要素に加えて、priority属性を配置可能な点が異なっている。
【０１８６】
priority属性には、ROUTEセッション間の優先度（重要度）が指定される。このpriority属性の値としては、例えば、highとlowや、1〜5の重要度を示す整数値などを用いることができる。
【０１８７】
なお、図１９に示したS-TSIDメタデータのフォーマットは一例であって、例えば、XML形式の以外の他のテキスト形式を採用することもできる。また、S-TSIDメタデータは、テキスト形式に限らず、バイナリ形式であってもよい。
【０１８８】
以上のように、例えば、スケーラブル符号化が適用された広帯域サービスを提供する場合に、ブロードキャストストリームのROUTEセッション間に、優先度（重要度）を定義することで、ベースレイヤとエンハンスレイヤとの違いで生じるROUTEセッション間の優先度（重要度）を指定することができる。
【０１８９】
なお、上述した説明では、セッション間の優先度を示す優先度情報として、S-TSIDメタデータのS-TSID要素の配下のRS要素に、priority属性を配置することで優先度が指定される場合を説明したが、このpriority属性の値で、明示的に優先度を指定しない場合でも、例えば、S-TSIDメタデータにおけるROUTEセッションの配置順を優先度順に配置するという規則を、運用規則とすることで、優先度が指定されるようにしてもよい。
【０１９０】
すなわち、このような運用規則を採用する場合には、例えば、上述した図１８のS-TSIDメタデータにおいて、より優先度の高いROUTEセッション２−１のRS要素が、より優先度の低いROUTEセッション１−２のRS要素よりも先に配置されるようにする。なお、この場合において、S-TSIDメタデータのS-TSID要素の配下のRS要素に、priority属性を配置する必要はない。
【０１９１】
＜５．チューナと放送サービスとのマッピング管理＞
【０１９２】
ところで、上述したような、同時に複数のブロードキャストストリームにまたがって配信される放送サービスがある場合には、１つのデバイス上に実装された複数のチューナにより同時に受信する場合もあれば、１つのチューナのみ実装した複数のデバイスにより同時に受信する場合もある。
【０１９３】
複数のデバイスにまたがる場合には、それらのチューナ制御系同士が、最新のSLS（S-TSIDメタデータ）に基づき、同時に受信処理が必要な放送サービスを適宜選択制御する必要がある。
【０１９４】
例えば、上述したユースケースでは、図１１に示した時間帯T1-T2の配信構成では、サービス２が、２つのブロードキャストストリーム（bsid-1，bsid-2）にまたがって配信されるため、ブロードキャストストリーム１（bsid-1）とブロードキャストストリーム２（bsid-1）とを同時に受信する必要がある。
【０１９５】
一方で、図１５に示した時間帯T2-T3の配信構成では、サービス１が、３つのブロードキャストストリーム（bsid-1，bsid-2，bsid-3）にまたがって配信されるため、それらのブロードキャストストリーム（bsid-1，bsid-2，bsid-3）を同時に受信する必要がある。
【０１９６】
本技術では、これらのチューナと、各チューナが受信すべき放送サービスの割り当ての制御としてのマッピング管理を、UPnP(Universal Plug and Play)やSSDP(Simple Service Discovery Protocol)等を利用したFWプロキシ装置１０の間のメッセージングを利用することで実現する。
【０１９７】
なお、UPnPは、デバイスを接続するだけで、対象のネットワークに参加することを可能にするプロトコルである。また、SSDPは、UPnPで用いられるプロコトルの１つで、ネットワーク上のデバイスの探索や応答を行うためのものである。
【０１９８】
すなわち、ネットワーク３０に接続された複数のFWプロキシ装置１０の間で、マスタ・スレーブ関係を持たせて、マスタ・プロキシ装置１０Ｍが、各FWプロキシ装置１０に対し、クライアント装置２０からのセグメント要求を、適切にリダイレクションできるようにする。
【０１９９】
このFWプロキシ装置１０の間のマスタ・スレーブ関係は、FWプロキシ装置１０がネットワーク３０に追加される度に、手動で設定してもよいし、あるいはFWプロキシ装置１０同士が、例えば各自の能力属性（処理能力やストレージ能力等）等に応じたネゴシエーションを行うことで決定してもよい。
【０２００】
マスタとなったFWプロキシ装置１０（マスタ・プロキシ装置１０Ｍ）は、例えば、UPnPのSSDP等でサービス担当範囲を調整するAPI(Application Programming Interface)を公開し、そのAPIを通じて、スレーブとなったFWプロキシ装置１０（スレーブ・プロキシ装置１０Ｓ）に、サービス担当範囲を割り当てる。なお、ここでは、各FWプロキシ装置１０にサービス担当範囲を割り当てるためのデータベース（以下、プロキシ−サービス担当範囲データベースという）が生成され、FWプロキシ装置１０ごとに、サービス担当範囲が割り当てられる。
【０２０１】
マスタ・プロキシ装置１０Ｍは、クライアント装置２０からのセグメント要求又はアプリケーション取得のリクエストを受け付けた場合、プロキシ−サービス担当範囲データベースを参照して、対象のFWプロキシ装置１０に、適切にリダイレクションを行う。そして、リダイレクションを受けた各FWプロキシ装置１０は、割り当てられたサービス担当範囲内で、ブロードキャストストリームを取得する。
【０２０２】
ただし、マスタ・プロキシ装置１０Ｍにおいて、プロキシ−サービス担当範囲データベースを構成する際に、最新のSLTメタデータ又はS-TSIDメタデータをパースして、ある放送サービスが、複数のROUTEセッションからなり、それらのROUTEセッションが異なるブロードキャストストリームから提供されることが検知された場合には、次のように、プロキシ−サービス担当範囲データベースを構成する。
【０２０３】
すなわち、マスタ・プロキシ装置１０Ｍでは、広帯域サービス等の放送サービスが、同時に複数のブロードキャストストリームにまたがって配信される場合に、同時に受信しなければならない複数のブロードキャストストリームが、異なるFWプロキシ装置１０（チューナ）にばらけるように、プロキシ−サービス担当範囲データベースが構成される。つまり、各FWプロキシ装置１０では、１つのブロードキャストストリームのみしか受けられないチューナが実装されているものと仮定して、それらのチューナで、ブロードキャストストリームの同時並行受信処理が可能なように、プロキシ−サービス担当範囲データベースが構成される。
【０２０４】
以上の処理の流れをまとめると、図２０のフローチャートのように表すことができる。
【０２０５】
すなわち、まず、マスタ・プロキシ装置１０Ｍ又はスレーブ・プロキシ装置１０Ｓは、SLTメタデータ又はS-TSIDメタデータの更新により通知される、異なるブロードキャストストリームにまたがる放送サービスの出現（又は構成の更新）を検知する（Ｓ１）。
【０２０６】
次に、マスタ・プロキシ装置１０Ｍは、マスタ・プロキシ装置１０Ｍとスレーブ・プロキシ装置１０Ｓの受け持ちサービス担当範囲を決定する（Ｓ２）。ここでは、同時に受信しなければならない複数のブロードキャストストリームが、異なるFWプロキシ装置１０にばらけるように、プロキシ−サービス担当範囲データベースが生成される。
【０２０７】
次に、マスタ・プロキシ装置１０Ｍは、クライアント装置２０からのリクエストを受け付けた場合、プロキシ−サービス担当範囲データベースを参照して、対象のFWプロキシ装置１０に対し、リダイレクションを行う（Ｓ３）。これにより、リダイレクションを受けた各FWプロキシ装置１０では、割り当てられたサービス担当範囲内で、ブロードキャストストリームを取得して、ネットワーク３０を介してクライアント装置２０に送信することになる。
【０２０８】
なお、マスタ・プロキシ装置１０Ｍでは、異なるブロードキャストストリームにまたがる放送サービスが出現する度に、同一のネットワーク３０内で稼働する同一のマスタ・プロキシ装置１０Ｍを共有するスレーブ・プロキシ装置１０Ｓ群のそれぞれが担当するサービス担当範囲の再設定が行われ、プロキシ−サービス担当範囲データベースが更新される。これにより、同一の放送サービスが配信される複数のブロードキャストストリームが同時に処理できるように、それぞれのFWプロキシ装置１０の受け持ち範囲が割り当てられる。
【０２０９】
ここで、SLTメタデータ又はS-TSIDメタデータの更新が発生し、複数のブロードキャストストリームにまたがる放送サービスが出現する場合におけるFWプロキシ装置１０のサービス担当範囲の変更処理について説明する。なお、配信構成の更新が発生するSLTメタデータ又はS-TSIDメタデータは、共有される放送サービスが配信されるブロードキャストストリームに限られるため、この配信構成の変更を検知したFWプロキシ装置１０が、プロキシ−サービス担当範囲データベースの更新のトリガをかけることになる。
【０２１０】
以下の例では、２つのスレーブ・プロキシ装置１０Ｓ（１０Ｓ−１，１０Ｓ−２）では、既にサービス担当範囲が割り当てられており、スレーブ・プロキシ装置１０Ｓ−２において、受信中のブロードキャストストリームから得られるSLTメタデータ又はS-TSIDメタデータの更新が検知されるものとする。なお、一般に、この配信構成の更新の検知は、複数のスレーブ・プロキシ装置１０Ｓで同時に起こるものであるが、ここでは、説明の都合上、スレーブ・プロキシ装置１０Ｓ−２でのみ、配信構成の更新が検知されるものとする。
【０２１１】
また、以下の例でも、上述したユースケースと同様に、ある時間軸で、時刻T1，T2，T3が順に経過する場合に、時間帯T1-T2と、時間帯T2-T3における配信の構成を例にして説明する。すなわち、時間帯T1-T2では、図１１に示した配信の構成となり、時間帯T2-T3では、図１５に示した配信の構成となる。
【０２１２】
（時間帯T1-T2におけるBS-1の構成）
図２１は、時間帯T1-T2において、図１１に示した配信の構成でのブロードキャストストリーム１（bsid-1）に流れるSLTメタデータとS-TSIDメタデータの例を示す図である。
【０２１３】
図２１において、ブロードキャストストリーム１（bsid-1）のSLTメタデータは、bsid属性として、bsid = bsid-1が指定され、サービスループ内には、２つの放送サービスが配置される。
【０２１４】
SLTメタデータにおいて、２つの放送サービスのうち、一方の放送サービスが、サービスIDとして、serviceId = svc-1が指定されるサービス１であり、BroadcastSvcSignaling要素のslsDestinationIpAddress属性として、dIpAddr-svc-1であるサービス１のSLS（SLS-svc-1）の送信先IPアドレスが指定される。
【０２１５】
このサービス１のSLS（SLS-svc-1）として伝送されるS-TSIDメタデータは、サービス１（svc-1）が、１つのROUTEセッション（dIpAddr-svc-1）で構成されることを表している。
【０２１６】
また、SLTメタデータにおいて、２つの放送サービスのうち、他方の放送サービスが、サービスIDとして、serviceId = svc-2が指定されるサービス２であり、BroadcastSvcSignaling要素のslsDestinationIpAddress属性として、dIpAddr-svc-2であるサービス２のSLS（SLS-svc-2）の送信先IPアドレスが指定される。
【０２１７】
このサービス２のSLS（SLS-svc-2）として伝送されるS-TSIDメタデータは、サービス２（svc-2）が、２つのROUTEセッション（dIpAddr-svc-2）で構成され、一方のROUTEセッションが、bsid = bsid-1を持つブロードキャストストリーム１で転送され、他方のROUTEセッションが、bsid = bsid-2を持つブロードキャストストリーム２で転送されることを表している。
【０２１８】
（時間帯T1-T2におけるBS-2の構成）
図２２は、時間帯T1-T2において、図１１に示した配信の構成でのブロードキャストストリーム２（bsid-2）に流れるSLTメタデータとS-TSIDメタデータの例を示す図である。
【０２１９】
図２２において、ブロードキャストストリーム２（bsid-2）のSLTメタデータは、bsid属性として、bsid = bsid-2が指定され、サービスループ内には、単一の放送サービスが配置される。この放送サービスは、サービスIDとして、serviceId = svc-2が指定されるサービス２であり、dIpAddr-svc-2であるサービス２のSLS（SLS-svc-2）の送信先IPアドレスが指定される。
【０２２０】
このサービス２のSLS（SLS-svc-2）として伝送されるS-TSIDメタデータは、サービス２（svc-2）が、２つのROUTEセッション（dIpAddr-svc-2）で構成され、一方のROUTEセッションが、bsid = bsid-1を持つブロードキャストストリーム１で転送され、他方のROUTEセッションが、bsid = bsid-2を持つブロードキャストストリーム２で転送されることを表している。
【０２２１】
なお、図２１と図２２のサービス２のSLS（SLS-svc-2）の内容は、共通の内容とされる。
【０２２２】
（時間帯T1-T2におけるBS-3の構成）
図２３は、時間帯T1-T2において、図１１に示した配信の構成でのブロードキャストストリーム３（bsid-3）に流れるSLTメタデータとS-TSIDメタデータの例を示す図である。
【０２２３】
図２３において、ブロードキャストストリーム３（bsid-3）のSLTメタデータは、bsid属性として、bsid = bsid-3が指定され、サービスループ内には、単一の放送サービスが配置される。この放送サービスは、サービスIDとして、serviceId = svc-3が指定されるサービス３であり、dIpAddr-svc-3であるサービス３のSLS（SLS-svc-3）の送信先IPアドレスが指定される。
【０２２４】
このサービス３のSLS（SLS-svc-3）として伝送されるS-TSIDメタデータは、サービス３（svc-3）が、１つのROUTEセッションで構成されることを表している。
【０２２５】
以上、図２１乃至図２３を参照して、図１１に示した時間帯T1-T2における配信の構成での各ブロードキャストストリーム（bsid-1，bsid-2，bsid-3）に流れるSLTメタデータとS-TSIDメタデータの内容を例示した。次に、図２４乃至図２６を参照して、図１５に示した時間帯T2-T3における配信の構成での各ブロードキャストストリーム（bsid-1，bsid-2，bsid-3）に流れるSLTメタデータとS-TSIDメタデータの内容を例示する。
【０２２６】
（時間帯T2-T3におけるBS-1の構成）
図２４は、時間帯T2-T3において、図１５に示した配信の構成でのブロードキャストストリーム１（bsid-1）に流れるSLTメタデータとS-TSIDメタデータの例を示す図である。
【０２２７】
図２４において、ブロードキャストストリーム１（bsid-1）のSLTメタデータは、bsid属性として、bsid = bsid-1が指定され、サービスループ内には、単一の放送サービスが配置される。この放送サービスは、サービスIDとして、serviceId = svc-1が指定されるサービス１であり、BroadcastSvcSignaling要素のslsDestinationIpAddress属性として、dIpAddr-svc-1であるサービス１のSLS（SLS-svc-1）の送信先IPアドレスが指定される。
【０２２８】
このサービス１のSLS（SLS-svc-1）として伝送されるS-TSIDメタデータは、サービス１（svc-1）が、３つのROUTEセッション（dIpAddr-svc-1）で構成されることを表している。
【０２２９】
すなわち、図２４のS-TSIDメタデータにおいては、１つ目のROUTEセッション１−１（dIpAddr-svc-1）が、bsid = bsid-1を持つブロードキャストストリーム１で転送されることを表している。同様にまた、２つ目のROUTEセッション２−１（dIpAddr-svc-1）が、bsid = bsid-2を持つブロードキャストストリーム２で転送され、３つ目のROUTEセッション３−１（dIpAddr-svc-1）が、bsid = bsid-3を持つブロードキャストストリーム３で転送されることを表している。
【０２３０】
（時間帯T2-T3におけるBS-2の構成）
図２５は、時間帯T2-T3において、図１５に示した配信の構成でのブロードキャストストリーム２（bsid-2）に流れるSLTメタデータとS-TSIDメタデータの例を示す図である。
【０２３１】
図２５において、ブロードキャストストリーム２（bsid-2）のSLTメタデータは、bsid属性として、bsid = bsid-2が指定され、サービスループ内には、単一の放送サービスが配置される。この放送サービスは、サービスIDとして、serviceId = svc-1が指定されるサービス１であり、dIpAddr-svc-1であるサービス１のSLS（SLS-svc-1）の送信先IPアドレスが指定される。
【０２３２】
このサービス１のSLS（SLS-svc-1）として伝送されるS-TSIDメタデータは、サービス１（svc-1）が、３つのROUTEセッション（dIpAddr-svc-1）で構成されることを表している。図２５のサービス１のSLS（SLS-svc-1）の内容は、図２４のサービス１のSLS（SLS-svc-1）の内容と共通の内容とされ、サービス１を構成する３つのROUTEセッションが、複数のブロードキャストストリーム（bsid-1，bsid-2，bsid-3）で構成されることを表している。
【０２３３】
（時間帯T2-T3におけるBS-3の構成）
図２６は、時間帯T2-T3において、図１５に示した配信の構成でのブロードキャストストリーム３（bsid-3）に流れるSLTメタデータとS-TSIDメタデータの例を示す図である。
【０２３４】
図２６において、SLTメタデータは、bsid属性として、bsid = bsid-3が指定され、サービスループ内には、単一の放送サービスが配置される。この放送サービスは、サービスIDとして、serviceId = svc-1が指定されるサービス１であり、dIpAddr-svc-1であるサービス１のSLS（SLS-svc-1）の送信先IPアドレスが指定される。
【０２３５】
このサービス１のSLS（SLS-svc-1）として伝送されるS-TSIDメタデータは、サービス１（svc-1）が、３つのROUTEセッションで構成されることを表している。図２６のサービス１のSLS（SLS-svc-1）の内容は、図２４及び図２５のサービス１のSLS（SLS-svc-1）の内容と共通の内容とされ、サービス１を構成する３つのROUTEセッションが、複数のブロードキャストストリーム（bsid-1，bsid-2，bsid-3）で構成されることを表している。
【０２３６】
以上のように、図１１に示した時間帯T1-T2における配信の構成と、図１５に示した時間帯T2-T3における配信の構成とでは、時間帯ごとに配信の構成が変化しているが、それに伴い、SLTメタデータとS-TSIDメタデータが更新され、その内容が変化している。具体的には、時間帯T1-T2と時間帯T2-T3とで、配信の構成が変化すると、SLTメタデータとS-TSIDメタデータの内容は、図２１乃至図２３に示した内容から、図２４乃至図２６に示した内容に更新されることになる。
【０２３７】
そして、例えば、ネットワーク３０に接続されたFWプロキシ装置１０のうち、スレーブ・プロキシ装置１０Ｓ−２が、このSLTメタデータ又はS-TSIDメタデータの更新を検知したことを、マスタ・プロキシ装置１０Ｍに通知することで、マスタ・プロキシ装置１０Ｍでは、その通知をトリガとして、プロキシ−サービス担当範囲データベースを更新することになる。
【０２３８】
（SLT又はS-TSIDの更新時のサービス担当範囲の割り当て処理）
次に、図２７のフローチャートを参照して、SLTメタデータ又はS-TSIDメタデータの更新が検知された場合におけるサービス担当範囲の割り当て処理の流れを説明する。
【０２３９】
ただし、図２７の説明では、マスタ・プロキシ装置１０Ｍと、スレーブ・プロキシ装置１０Ｓ−１，１０Ｓ−２との間で、マスタ・スレーブ関係が成立しているものとする。
【０２４０】
また、以下の説明では、スレーブプロキシ１６１として、スレーブ・プロキシ装置１０Ｓ−１で稼働するものを、スレーブプロキシ１６１−１（図中では「スレーブプロキシ１」と略記する）と称する一方で、スレーブ・プロキシ装置１０Ｓ−２で稼働するものを、スレーブプロキシ１６１−２（図中では「スレーブプロキシ２」と略記する）と称して、区別するものとする。
【０２４１】
また、図２７において、ステップＳ１０１乃至Ｓ１０６の処理は、マスタ・プロキシ装置１０Ｍにより実行される。一方で、ステップＳ１１１乃至Ｓ１１４の処理は、スレーブ・プロキシ装置１０Ｓ−１により実行され、ステップＳ１２１乃至Ｓ１２６の処理は、スレーブ・プロキシ装置１０Ｓ−２により実行される。
【０２４２】
スレーブ・プロキシ装置１０Ｓ−２において、SLTメタデータ又はS-TSIDメタデータの更新が検知されると（Ｓ１２１）、ステップＳ１２２において、スレーブプロキシ１６１−２は、マスタプロキシ１１１の存在を確認するために、通信I/F１５２を介して、ネットワーク３０に接続されたデバイスに対し、存在確認用のメッセージを、マルチキャストで送信する。
【０２４３】
なお、上述したように、マスタ・プロキシ装置１０Ｍとスレーブ・プロキシ装置１０Ｓ−２との間では、マスタ・スレーブ関係が成立しているため、スレーブ・プロキシ装置１０Ｓ−２では、マスタ・プロキシ装置１０Ｍは既知であるが、あえて知らないように振る舞うことで、スレーブ・プロキシ装置１０Ｓ−２がネットワーク３０に新規で追加される場合と、同一の処理シーケンスとすることができる。
【０２４４】
ステップＳ１０１，Ｓ１０２において、マスタプロキシ１１１は、マルチキャストで送信されてくるメッセージに応じて、設定管理APIを生成し、ネットワーク３０を介して、スレーブ・プロキシ装置１０Ｓ−１とスレーブ・プロキシ装置１０Ｓ−２に通知（再通知）する。
【０２４５】
ステップＳ１２３において、スレーブプロキシ１６１−２は、マスタ・プロキシ装置１０Ｍからの通知に応じて、チューナ１５１を制御して、放送サービスのスキャンを行う。ここでは、例えば、チューナ１５１により初期スキャン処理が行われることで、LLSとして伝送されるSLTメタデータ等から、スレーブ・プロキシ装置１０Ｓ−２により受信可能な放送サービスを示すサービススキャン結果が得られる。
【０２４６】
このとき、スレーブプロキシ１６１−１が稼働するスレーブ・プロキシ装置１０Ｓ−１では、マスタ・プロキシ装置１０Ｍからの通知に応じて、放送サービスの再スキャンが行われ、サービススキャン結果が得られる（Ｓ１１１）。また、マスタプロキシ１１１が稼働するマスタ・プロキシ装置１０Ｍにおいても、放送サービスの再スキャンが行われ、サービススキャン結果が得られる（Ｓ１０３）。
【０２４７】
ただし、スレーブ・プロキシ装置１０Ｓ−２がサービススキャンを行うタイミングで、マスタ・プロキシ装置１０Ｍとスレーブ・プロキシ装置１０Ｓ−１によるサービススキャンを行うかどうかは、任意である。
【０２４８】
スレーブプロキシ１６１−２は、放送サービスのスキャン（Ｓ１２３）が終了したとき、マスタプロキシ１１１に対し、当該サービススキャン結果の通知と、サービス担当範囲の要求を行う（Ｓ１２４，Ｓ１２５）。
【０２４９】
同様に、スレーブプロキシ１６１−１は、放送サービスのスキャン（Ｓ１１１）が終了したとき、マスタプロキシ１１１に対し、当該サービススキャン結果の通知と、サービス担当範囲の要求を行う（Ｓ１１２，Ｓ１１３）。
【０２５０】
スレーブ・プロキシ装置１０Ｓ−１，１０Ｓ−２により送信される、サービススキャン結果とサービス担当範囲リクエストは、マスタ・プロキシ装置１０Ｍにより受信される。
【０２５１】
ステップＳ１０４において、マスタプロキシ１１１は、サービススキャン結果に基づいて、サービス担当範囲を決定する。
【０２５２】
ここでは、サービススキャン結果として、マスタ・プロキシ装置１０Ｍ自身のサービススキャン結果、既存のスレーブ・プロキシ装置１０Ｓ−１のサービススキャン結果、及び新規のスレーブ・プロキシ装置１０Ｓ−２のサービススキャン結果が得られる。そして、マスタプロキシ１１１では、これらのサービススキャン結果を用いて、配信構成情報や優先度情報に従い、各FWプロキシ装置１０のサービス担当範囲を決定する。
【０２５３】
ただし、配信構成情報は、例えば、最新のSLTメタデータやS-TSIDメタデータのパース結果から得られる、単一の放送サービス（広帯域サービス等）が、複数のブロードキャストストリームにまたがって配信されることを示す情報である。また、優先度情報は、例えば、最新のS-TSIDメタデータのパース結果から得られるROUTEセッション間の優先度を示す情報である。
【０２５４】
ここでは、例えば、広帯域サービス等の放送サービスが、複数のブロードキャストストリームにまたがって配信される場合において、同時に受信する必要がある複数のブロードキャストストリームが、異なるFWプロキシ装置１０（チューナ）にばらけるように、各FWプロキシ装置１０（マスタプロキシ１１１やスレーブプロキシ１６１−１，１６１−２）と、サービス担当範囲とを対応付けたプロキシ−サービス担当範囲データベースが生成され、記憶部１０３に記憶される。
【０２５５】
なお、マスタ・プロキシ装置１０Ｍでは、プロキシ−サービス担当範囲データベースを生成する際に、S-TSIDメタデータ等から得られる配信構成情報や優先度情報のほか、あらかじめ定められた各種のポリシ（規則）を加味して、FWプロキシ装置１０に対し、サービス担当範囲が割り当てられるようにしてもよい。
【０２５６】
このようなポリシとしては、例えば、複数のFWプロキシ装置１０に対し、対象のエリア内で受信可能な全放送サービスを機械的に割り当てたり、あるいは、エンドユーザの視聴履歴を考慮に入れて、アクセス頻度の高い放送サービス群が優先的に負荷分散されるように割り当てたりすることができる。さらには、放送サービス（チャネル）のザッピングの高速化を図るために、同時に受信可能な放送サービス群をまとめるなど、様々な規則を選択することができる。
【０２５７】
ステップＳ１０５において、マスタプロキシ１１１は、スレーブプロキシ１６１−１とスレーブプロキシ１６１−２に対し、ステップＳ１０４の処理で得られるサービス担当範囲を通知する。
【０２５８】
スレーブプロキシ１６１−２が稼働するスレーブ・プロキシ装置１０Ｓ−２では、マスタ・プロキシ装置１０Ｍからのサービス担当範囲情報に基づいて、チューナ１５１を制御して、自身の担当範囲の放送サービスのチューニングの準備が行われる（Ｓ１２６）。
【０２５９】
同様に、スレーブプロキシ１６１−２が稼働するスレーブ・プロキシ装置１０Ｓ−１においても、マスタ・プロキシ装置１０Ｍからのサービス担当範囲情報に応じた自身の担当範囲の放送サービスのチューニングの準備が行われる（Ｓ１１４）。さらに、マスタ・プロキシ装置１０Ｍにおいても、自身の担当範囲の放送サービスのチューニングの準備が行われる（Ｓ１０６）。
【０２６０】
このようにして、ネットワーク３０に接続された各FWプロキシ装置１０では、自身の担当範囲の放送サービスのチューニングの準備が完了して、クライアント装置２０からのDASHセグメントのリクエストに対し、ネットワーク３０内の適切なFWプロキシ装置１０が対応することになる。
【０２６１】
ここで、図２８乃至図３１には、サービス担当範囲の割り当てのより具体的な例を示している。
【０２６２】
なお、以下の例でも、上述したユースケースと同様に、ある時間軸で、時刻T1，T2，T3が順に経過する場合に、時間帯T1-T2と、時間帯T2-T3における配信の構成を例にして説明する。すなわち、時間帯T1-T2では、図１１に示した配信の構成となり、時間帯T2-T3では、図１５に示した配信の構成となる。
【０２６３】
（時間帯T1-T2におけるサービス担当範囲の割り当て）
図２８は、時間帯T1-T2において、図１１に示した配信の構成でのブロードキャストストリーム（bsid-1，bsid-2，bsid-3）とFWプロキシ装置１０とのマッピングの例を示す図である。
【０２６４】
図２８には、図１１に示した配信の構成のサービススキャン結果を示しているので、ネットワーク３０に接続されたFWプロキシ装置１０で受信可能な放送サービスとして、ブロードキャストストリーム１（bsid-1）のサービス１（svc-1）及びサービス2.1（svc-2）と、ブロードキャストストリーム２（bsid-2）のサービス2.2（svc-2）と、ブロードキャストストリーム３（bsid-3）のサービス３（svc-3）がスキャンされている。
【０２６５】
なお、サービス2.1とサービス2.2は、複数のブロードキャストストリーム（bsid-1，bsid-2）をまたいで配信される同一のサービス２（svc-2）である。
【０２６６】
マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１は、これらのサービススキャン結果に基づいて、マスタプロキシ１１１とスレーブプロキシ１６１が受け持つ放送サービスの担当範囲を決定する。
【０２６７】
ここで、図２８の例では、スキャンされた放送サービスのうち、サービス１とサービス2.1が、マスタプロキシ１１１のサービス担当範囲に割り当てられ、サービス2.2が、スレーブプロキシ１６１−１のサービス担当範囲に割り当てられ、サービス３が、スレーブプロキシ１６１−２のサービス担当範囲に割り当てられている。
【０２６８】
すなわち、図２８の例では、サービス２（svc-2）が、ブロードキャストストリーム１（bsid-1）とブロードキャストストリーム２（bsid-2）をまたいで配信され、かつ、マスタ・プロキシ装置１０Ｍとスレーブ・プロキシ装置１０Ｓ−１との同時稼働が常に保証されている。そのため、サービス２（svc-2）のうち、サービス2.1が、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１に割り当てられ、サービス2.2が、スレーブ・プロキシ装置１０Ｓ−１で稼働するスレーブプロキシ１６１−１に割り当てられる。
【０２６９】
また、スレーブ・プロキシ装置１０Ｓ−２は、例えば、電源が落とされる可能性がある等、常に同時稼働が保証されていないFWプロキシ装置１０であるため、単独の放送サービスとして提供されるサービス３は、スレーブ・プロキシ装置１０Ｓ−２で稼働するスレーブプロキシ１６１−２に割り当てられる。
【０２７０】
（時間帯T2-T3におけるサービス担当範囲の割り当て）
図２９は、時間帯T2-T3において、図１５に示した配信の構成でのブロードキャストストリーム（bsid-1，bsid-2，bsid-3）とFWプロキシ装置１０とのマッピングの例を示す図である。
【０２７１】
図２９には、図１５に示した配信の構成のサービススキャン結果を示しているので、ネットワーク３０に接続されたFWプロキシ装置１０で受信可能な放送サービスとして、ブロードキャストストリーム１（bsid-1）のサービス1.1（svc-1）と、ブロードキャストストリーム２（bsid-2）のサービス1.2（svc-1）と、ブロードキャストストリーム３（bsid-3）のサービス1.3（svc-1）がスキャンされている。
【０２７２】
なお、サービス1.1と、サービス1.2と、サービス1.3は、複数のブロードキャストストリーム（bsid-1，bsid-2，bsid-3）をまたいで配信される同一のサービス１（svc-1）である。
【０２７３】
マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１は、これらのサービススキャン結果に基づいて、マスタプロキシ１１１とスレーブプロキシ１６１が受け持つ放送サービスの担当範囲を決定する。
【０２７４】
ここで、図２９の例では、スキャンされた放送サービスのうち、サービス1.1が、マスタプロキシ１１１のサービス担当範囲に割り当てられ、サービス1.2が、スレーブプロキシ１６１−１のサービス担当範囲に割り当てられ、サービス1.3が、スレーブプロキシ１６１−２のサービス担当範囲に割り当てられている。
【０２７５】
すなわち、図２９の例では、サービス１（svc-1）が、３つのブロードキャストストリーム（bsid-1，bsid-2，bsid-3）をまたいで配信され、かつ、マスタ・プロキシ装置１０Ｍと、スレーブ・プロキシ装置１０Ｓ−１，１０Ｓ−２との同時稼働が常に保証されている。
【０２７６】
そのため、サービス１（svc-1）のうち、サービス1.1が、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１に割り当てられ、サービス1.2が、スレーブ・プロキシ装置１０Ｓ−１で稼働するスレーブプロキシ１６１−１に割り当てられ、サービス1.3が、スレーブ・プロキシ装置１０Ｓ−２で稼働するスレーブプロキシ１６１−２に割り当てられる。
【０２７７】
（プロキシ数の制限と優先度指定がある場合の時間帯T2-T3におけるサービス担当範囲の割り当て）
図３０は、同時受信可能なFWプロキシ装置１０の数に制限があり、かつ、ROUTEセッション間に異なる優先度指定がある場合に、時間帯T2-T3において、図１５に示した配信の構成でのブロードキャストストリーム（bsid-1，bsid-2，bsid-3）とFWプロキシ装置１０とのマッピングの例を示す図である。
【０２７８】
図３０には、図１５に示した配信の構成のサービススキャン結果を示しているので、ネットワーク３０に接続されたFWプロキシ装置１０で受信可能な放送サービスとして、図２９と同様に、ブロードキャストストリーム１（bsid-1）のサービス1.1（svc-1）と、ブロードキャストストリーム２（bsid-2）のサービス1.2（svc-1）と、ブロードキャストストリーム３（bsid-3）のサービス1.3（svc-1）がスキャンされている。
【０２７９】
なお、サービス1.1と、サービス1.2と、サービス1.3は、複数のブロードキャストストリーム（bsid-1，bsid-2，bsid-3）をまたいで配信される同一のサービス１（svc-1）であって、例えば、サービス1.1は、ベースレイヤのストリームを転送するROUTEセッションを含み、サービス1.2とサービス1.3は、エンハンスレイヤのストリームを転送するROUTEセッションを含んでいる。
【０２８０】
マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１は、これらのサービススキャン結果に基づいて、マスタプロキシ１１１とスレーブプロキシ１６１が受け持つ放送サービスの担当範囲を決定する。
【０２８１】
ここで、図３０の例では、ネットワーク３０に、マスタ・プロキシ装置１０Ｍとスレーブ・プロキシ装置１０Ｓ−１のみが接続され、同時受信可能なFWプロキシ装置１０の数に制限があるため、ROUTEセッション間の優先度に応じて、マスタプロキシ１１１とスレーブプロキシ１６１が受け持つ放送サービスの担当範囲が決定される。
【０２８２】
すなわち、図３０の例では、サービス１（svc-1）が、３つのブロードキャストストリーム（bsid-1，bsid-2，bsid-3）をまたいで配信されているが、１つのマスタ・プロキシ装置１０Ｍと、１つのスレーブ・プロキシ装置１０Ｓ−１の構成であるため、すべてのブロードキャストストリームを受信することができない。
【０２８３】
一方で、マスタ・プロキシ装置１０Ｍとスレーブ・プロキシ装置１０Ｓ−１は、同時稼働が常に保証されている。また、このとき、図３１に示すように、S-TSIDメタデータにおいて、ブロードキャストストリーム１（bsid-1）とブロードキャストストリーム３（bsid-3）のROUTEセッションには、priority = highである優先度が指定される一方で、ブロードキャストストリーム２（bsid-2）のROUTEセッションには、priority = lowである優先度が指定されている。
【０２８４】
この場合において、マスタプロキシ１１１は、ブロードキャストストリーム１，３と比べて、ブロードキャストストリーム２（bsid-2）のROUTEセッションの優先度が低いため、FWプロキシ装置１０が２つという構成では、ブロードキャストストリーム１，３（のサービス1.1とサービス1.3）を優先的に、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１と、スレーブ・プロキシ装置１０Ｓ−１で稼働するスレーブプロキシ１６１に割り当てる。つまり、ROUTEセッション間の優先度が相対的に低いブロードキャストストリーム２に対しては、同時受信処理を行うスレーブプロキシ１６１が割り当てられない。
【０２８５】
なお、マスタプロキシ１１１は、ネットワーク３０に接続されたクライアント装置２０からサービス1.2のセグメントリクエストを受けた場合、常に、サービス1.2の受信処理を保証することはできないため、例えば、当該セグメントを、通信経由で取得することになる。この通信経由での配信に対応した構成は、図５０に示している。また、通信経由での配信を受信するのは、マスタプロキシ１１１が稼働するマスタ・プロキシ装置１０Ｍに限らず、例えば、スレーブ・プロキシ装置１０Ｓやクライアント装置２０自身が受信してもよい。
【０２８６】
以上、SLTメタデータ又はS-TSIDメタデータの更新が検知された場合におけるサービス担当範囲の割り当て処理の流れを説明した。
【０２８７】
（セグメントリクエストのリダイレクションの処理）
次に、図３２のフローチャートを参照して、セグメントリクエストのリダイレクションの処理の流れを説明する。
【０２８８】
図３２の説明では、マスタ・プロキシ装置１０Ｍと、１つのスレーブ・プロキシ装置１０Ｓが存在するネットワーク３０に対し、クライアント装置２０が接続し、当該クライアント装置２０により、放送経由で配信されるコンテンツの再生が指示される場合を説明する。
【０２８９】
すなわち、図３２のセグメントリクエストのリダイレクションの処理は、図２７を参照して説明したサービス担当範囲の割り当て処理の後に行われる処理である。ただし、説明の簡略化のため、図３２の説明では、スレーブ・プロキシ装置１０Ｓが１つだけ接続されている場合を説明する。
【０２９０】
また、図３２において、ステップＳ１４１乃至Ｓ１４５の処理は、クライアント装置２０により実行される。一方で、ステップＳ１４２，Ｓ１５１乃至Ｓ１５２の処理は、マスタ・プロキシ装置１０Ｍにより実行され、ステップＳ１６１乃至Ｓ１６４の処理は、スレーブ・プロキシ装置１０Ｓにより実行される。
【０２９１】
図３２においては、クライアント装置２０が、ネットワーク３０に接続されると（Ｓ１４１）、当該クライアント装置２０と、マスタ・プロキシ装置１０Ｍとの間で、マスタプロキシ設定処理が行われる（Ｓ１４２）。このマスタプロキシ設定処理では、クライアント装置２０と、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１との間の接続が確立される。
【０２９２】
なお、クライアント装置２０が、マスタ・プロキシ装置１０Ｍで稼働するマスタプロキシ１１１を発見・接続する方法としては、例えば、DHCP(Dynamic Host Configuration Protocol)サーバを用いる方法や、WPAD(Web Proxy Auto Discovery)を用いる方法など、いくつかの方法が想定されるが、それらの方法のいずれかを用いて接続が確立されることになる。
【０２９３】
ステップＳ１４３において、アプリケーション２１１は、マスタプロキシ１１１に対し、サービス−MPDテーブルを要求する。
【０２９４】
ステップＳ１４３の処理で、クライアント装置２０により送信されるサービス−MPDテーブルのリクエストは、ネットワーク３０を介して、マスタ・プロキシ装置１０Ｍにより受信される。
【０２９５】
ステップＳ１５１において、マスタプロキシ１１１は、クライアント装置２０から受信したテーブルのリクエストに応じて、サービス−MPDテーブルを生成し、レスポンスとして、ネットワーク３０を介してクライアント装置２０に返答する。
【０２９６】
ここで、サービス−MPDテーブルは、放送サービスとMPDメタデータとを対応付けたテーブルである。サービス−MPDテーブルは、SLSから生成される。なお、ここでは、説明の簡略化のため、サービス−MPDテーブルがマスタプロキシ１１１により生成されるとして説明するが、サービス−MPDテーブルは、SLS処理系１１３により生成されるようにしてもよい。
【０２９７】
ステップＳ１５１の処理で、マスタ・プロキシ装置１０Ｍにより送信されるサービス−MPDテーブルは、ネットワーク３０を介して、クライアント装置２０により受信される。
【０２９８】
ステップＳ１４４において、アプリケーション２１１は、マスタ・プロキシ装置１０Ｍから受信したサービス−MPDテーブルを参照して、所望の放送サービスに対応したMPDメタデータに基づいて、マスタプロキシ１１１に対し、DASHセグメントを要求する。
【０２９９】
ステップＳ１４４の処理で、クライアント装置２０により送信されるDASHセグメントのリクエストは、ネットワーク３０を介して、マスタ・プロキシ装置１０Ｍにより受信される。
【０３００】
ステップＳ１５２において、マスタプロキシ１１１は、クライアント装置２０から受信したDASHセグメントのリクエストに対するスレーブプロキシ１６１への割り振りを、プロキシ−サービス担当範囲データベースを参照して判断し、その判断結果に応じたリダイレクションを行う。
【０３０１】
これにより、マスタプロキシ１１１によって、クライアント装置２０（のアプリケーション２１１）からのDASHセグメントのリクエストが、適切なスレーブプロキシ１６１に対し、リダイレクションされることになる。
【０３０２】
なお、ここでは、説明を簡略化するために、リダイレクションされるDASHセグメントのリクエストが、マスタプロキシ１１１からスレーブプロキシ１６１に対して直接通知されるとして説明しているが、実際には、図３２の点線で示しているように、マスタプロキシ１１１からクライアント装置２０を経由して、いわば間接的に、スレーブプロキシ１６１に通知される。
【０３０３】
ステップＳ１５２の処理で、マスタ・プロキシ装置１０ＭによりリダイレクションされたDASHセグメントのリクエストは、適切であると判断されたスレーブプロキシ１６１が稼働しているスレーブ・プロキシ装置１０Ｓにより受信される。
【０３０４】
ステップＳ１６２において、スレーブプロキシ１６１は、事前サービスチューニングを行っているかどうかを判定する。なお、スレーブ・プロキシ装置１０Ｓにおいては、リソースに余裕がある場合には、担当範囲の放送サービスについて、事前にサービスチューニングを行うことができる（Ｓ１６１）。
【０３０５】
ここでは、ステップＳ１６１の処理で、リソースに余裕がなく、事前サービスチューニングを行っていない場合には、ステップＳ１６２の判定処理で、「NO」と判定され、処理は、ステップＳ１６３に進められる。
【０３０６】
ステップＳ１６３において、スレーブプロキシ１６１は、マスタ・プロキシ装置１０Ｍから受信したDASHセグメントのリクエストに基づいて、チューナ１５１を制御して、放送サービスのチューニングを行う。これにより、DASHセグメントのリクエストに応じたDASHセグメントファイルが、放送サーバ４０から放送経由で取得される。
【０３０７】
一方、上述のステップＳ１６１の処理で、リソースに余裕があって、事前サービスチューニングが行われていた場合には、放送サーバ４０から放送経由で得られる、担当範囲の放送サービスのストリームは展開済みであるので、ステップＳ１６３の処理はスキップされる。この場合、展開済みのストリームから、DASHセグメントのリクエストに応じたDASHセグメントファイルが取得される。
【０３０８】
DASHセグメントファイルが取得されると、処理は、ステップＳ１６４に進められる。ステップＳ１６４において、スレーブプロキシ１６１は、放送サーバ４０から受信したDASHセグメントファイルを、通信I/F１０２を介して、ネットワーク３０に接続されたクライアント装置２０に返答する。
【０３０９】
ステップＳ１６４の処理で、スレーブ・プロキシ装置１０Ｓにより送信（転送）されるDASHセグメントファイルは、ネットワーク３０を介して、クライアント装置２０により受信される。
【０３１０】
クライアント装置２０では、ブラウザ２１２によって、スレーブ・プロキシ装置１０Ｓから受信したDASHセグメントファイルが再生される（Ｓ１４５）。これにより、クライアント装置２０においては、放送経由で配信された番組等のコンテンツが再生されることになる。
【０３１１】
以上、セグメントリクエストのリダイレクションの処理の流れを説明した。
【０３１２】
（送信側の処理）
次に、図３３のフローチャートを参照して、送信側の処理の流れを説明する。
【０３１３】
ステップＳ２０１において、コンポーネント処理部４０１は、番組等のコンテンツを構成するコンポーネントのデータを処理する。ここでは、例えば、ビデオやオーディオ、字幕等のデータに対し、スケーラブル符号化等の符号化処理などが行われる。
【０３１４】
ステップＳ２０２において、制御情報生成部４０２は、上位層の制御情報を生成する。ここでは、上位層の制御情報として、LLSやSLSなどが生成される。例えば、放送サービスが複数のブロードキャストストリームをまたいで配信される場合には、配信構成情報や優先度情報などの情報が、SLSのS-TSIDメタデータに含められる。
【０３１５】
ステップＳ２０３において、ESG生成部４０３は、ESG情報を生成する。ここでは、例えば、放送サービスが複数のブロードキャストストリームをまたいで配信される場合には、配信構成情報が、ESG情報のスケジュールフラグメントに含められる。なお、ESG情報の詳細は、図３４乃至４９を参照して後述する。
【０３１６】
ステップＳ２０４において、マルチプレクサ４０４は、ステップＳ２０１の処理で得られるコンポーネントのストリームと、ステップＳ２０２の処理で得られる上位層の制御情報のストリームと、ステップＳ２０３の処理で得られるESG情報のストリームとを多重化する。また、ステップＳ２０４において、データ処理部４０５は、多重化の結果得られる多重化ストリームを処理して、所定の形式からなる伝送データを生成する。
【０３１７】
ステップＳ２０５において、送信部４０６は、ステップＳ２０４の処理で得られる伝送データを、専用線を介して、送信所５０の送出設備に送信する。そして、送信所５０内の送出設備は、放送サーバ４０からの伝送データに対し、必要な処理（変調処理等）を施すことで、その結果得られる放送信号が送信される。
【０３１８】
以上、送信側の処理の流れを説明した。
【０３１９】
＜６．ESGによるエンドユーザへの通知＞
【０３２０】
ところで、複数のブロードキャストストリームにまたがる単一の放送サービスの存在は、SLSにより通知される（シグナルされる）が、SLSは、当該サービスが開始される直前に配信されるため、例えば、数分前、数時間前、あるいは数時間前に、受信側で、このような放送サービスの存在を知ることができない。この事前周知のために、ESG(Electronic Service Guide)がある。
【０３２１】
例えば、ATSC3.0におけるESGは、１つのサービスとして提供されることになっており、当該ESGサービスを取得するためには、SLTメタデータのサービスエントリの中で、サービスカテゴリが、ESGサービスとなるものを探すことにより取得する。なお、SLTメタデータの詳細は、下記の非特許文献２の「Table 6.2 SLT XML Format」に記述されている。
【０３２２】
非特許文献２：ATSC Candidate Standard:Signaling, Delivery, Synchronization,and Error Protection (A/331)
【０３２３】
（１）第１の配信構成の場合のESGサービスの構成
【０３２４】
まず、第１の配信構成の場合のESGサービスの構成例について説明する。この第１の配信構成では、独立した２つの放送サービス（Service-1，Service-2）のROUTEセッション（RouteSession-1-1，RouteSession-1-2）が、ブロードキャストストリーム１（bsid-1）で転送される構成となる。
【０３２５】
（第１の配信構成のESGサービスの構成例）
図３４は、第１の配信構成の場合のESGサービスの構成例を示す図である。
【０３２６】
ブロードキャストストリームIDとして、bsid = bsid-1を持つブロードキャストストリーム１は、３つのROUTEセッション（RouteSession-1-1，RouteSession-1-2，RouteSession-1-esg）からなる。２つの放送サービス（Service-1，Service-2）は、ROUTEセッション１−１（dIpAddr-svc-1）とROUTEセッション１−２（dIpAddr-svc-2）でそれぞれ運ばれ、それぞれの放送サービス（svc-1，svc-2）は、時間方向に、複数の番組（Content）からなる。
【０３２７】
図３４においては、図中の左側から右側に向かう方向を時間の方向としたとき、サービス１（svc-1）では、時刻t1から時刻t2の間は、コンテンツ１−１（cnt-1-1）が配信され、時刻t2以降は、コンテンツ１−２（cnt-1-2）が配信される。また、サービス２（svc-2）では、時刻t1から時刻t2の間は、コンテンツ２−１（cnt-2-1）が配信され、時刻t2以降は、コンテンツ２−２（cnt-2-2）が配信される。
【０３２８】
これらの各放送サービスの番組編成は、それらの放送サービスと同一のブロードキャストストリーム１（bsid-1）のROUTEセッション１−esg（dIpAddr-svc-esg-1）で転送されるESGサービス（svc-esg-1）により、受信側に通知される。このESGサービスでは、複数のESG XMLフラグメントファイルが、いわばカルーセル（Carousel）による伝送のように転送される。
【０３２９】
ここで、ESGサービスの各XMLフラグメントは、サービス（Service）、コンテンツ（Content）、及びスケジュール（Schedule）等の記述する対象の内容に応じたデータ構造を有している。ESGサービスのROUTEセッション１−esg（dIpAddr-svc-esg-1）のLCTセッションには、サービス、コンテンツ、及びスケジュールのXMLフラグメントが、ESG情報として、当該サービス（番組）が配信される数日から数週間前に配信される。
【０３３０】
ここでは、次のXMLフラグメントがESG情報に含まれる。すなわち、第１の配信構成の場合、サービス１（Service-1）、サービス２（Service-2）、コンテンツ１−１（Content-1-1）、コンテンツ１−２（Content-1-2）、コンテンツ２−１（Content-2-1）、コンテンツ２−２（Content-2-2）、スケジュール１−１（Schedule-1-1）、スケジュール１−２（Schedule-1-2）、スケジュール２−１（Schedule-2-1）、及びスケジュール２−２（Schedule-2-2）のXMLフラグメントが、ESG情報として配信される。
【０３３１】
（XMLフラグメントの関係）
図３５は、第１の配信構成の場合のサービス、コンテンツ、及びスケジュールのXMLフラグメントの関係を示す図である。
【０３３２】
図３５の上段に示すように、ServiceFragment-1.xmlには、サービス名等のService-1の属性が記述される。
【０３３３】
ContentFragment-1-1.xmlには、番組名等のContent-1-1の属性が記述される。また、ContentFragment-1-2.xmlには、番組名等のContent-1-2の属性が記述される。なお、Content-1-1とContent-1-2のXMLフラグメントは、Service-1のXMLフラグメントに関連付けられる。
【０３３４】
ScheduleFragment-1-1.xmlには、Content-1-1の開始時刻t1等のSchedule-1-1のスケジュール属性が記述される。また、ScheduleFragment-1-2.xmlには、Content-1-2の開始時刻t2等のSchedule-1-2のスケジュール属性が記述される。
【０３３５】
なお、Schedule-1-1とSchedule-1-2のXMLフラグメントは、Service-1のXMLフラグメントに関連付けられる。また、Schedule-1-1のXMLフラグメントは、Content-1-1のXMLフラグメントに関連付けられ、Schedule-1-2のXMLフラグメントは、Content-1-2のXMLフラグメントに関連付けられる。
【０３３６】
ここで、図３６には、ServiceFragment-1，ContentFragment-1-1/-1-2，ScheduleFragment-1-1/-1-2のXMLインスタンスの例を示している。
【０３３７】
ServiceFragment-1.xmlには、Service要素のName要素により、サービス名として、Service-1が指定されている。
【０３３８】
ContentFragment-1-1.xmlには、Content要素のName要素により、番組名として、Content-1-1が指定される。また、ContentFragment-1-2.xmlには、Content要素のName要素により、番組名として、Content-1-2が指定される。
【０３３９】
また、ContentFragment-1-1.xmlと、ContentFragment-1-2.xmlでは、ServiceReference要素のidRef属性の値が、ServiceFragment-1.xmlのService要素のid属性の値と関連付けられている。
【０３４０】
ScheduleFragment-1-1.xmlには、PresentationWindow要素のstartTime属性とendTime属性により、Content-1-1の開始時刻と終了時刻が指定される。この例では、startTime属性により、Content-1-1の開始時刻t1として、'2016-02-17T12:00:00+00:00' が指定され、endTime属性により、Content-1-1の終了時刻t2として、'2016-02-17T12:30:00+00:00' が指定される。
【０３４１】
ScheduleFragment-1-2.xmlには、PresentationWindow要素のstartTime属性とendTime属性により、Content-1-2の開始時刻と終了時刻が指定される。この例では、startTime属性により、Content-1-2の開始時刻t2として、'2016-02-17T12:30:00+00:00' が指定され、endTime属性により、Content-1-2の終了時刻として、'2016-02-17T12:45:00+00:00' が指定される。
【０３４２】
また、ScheduleFragment-1-1.xmlと、ScheduleFragment-1-2.xmlでは、ServiceReference要素のidRef属性の値が、ServiceFragment-1.xmlのService要素のid属性の値と関連付けられている。さらに、ScheduleFragment-1-1.xmlでは、ContentReference要素のidRef属性の値が、ContentFragment-1-1.xmlのContent要素のid属性の値と関連付けられている。また、ScheduleFragment-1-2.xmlでは、ContentReference要素のidRef属性の値が、ContentFragment-1-2.xmlのContent要素のid属性の値と関連付けられている。
【０３４３】
図３５の説明に戻り、図３５の下段に示すように、ServiceFragment-2.xmlには、サービス名等のService-2の属性が記述される。
【０３４４】
ContentFragment-2-1.xmlには、番組名等のContent-2-1の属性が記述される。また、ContentFragment-2-2.xmlには、番組名等のContent-2-2の属性が記述される。なお、Content-2-1とContent-2-2のXMLフラグメントは、Service-2のXMLフラグメントに関連付けられる。
【０３４５】
ScheduleFragment-2-1.xmlには、Content-2-1の開始時刻t1等のSchedule-2-1のスケジュール属性が記述される。また、ScheduleFragment-2-2.xmlには、Content-2-2の開始時刻t2等のSchedule-2-2のスケジュール属性が記述される。
【０３４６】
なお、Schedule-2-1とSchedule-2-2のXMLフラグメントは、Service-2のXMLフラグメントに関連付けられる。また、Schedule-2-1のXMLフラグメントは、Content-2-1のXMLフラグメントに関連付けられ、Schedule-2-2のXMLフラグメントは、Content-2-2のXMLフラグメントに関連付けられる。
【０３４７】
以上、第１の配信構成の場合のESGサービスの構成について説明した。
【０３４８】
（２）第２の配信構成の場合のESGサービスの構成
【０３４９】
次に、第２の配信構成の場合のESGサービスの構成例について説明する。この第２の配信構成では、上述した第１の配信構成に並行して、ブロードキャストストリーム２（bsid-2）の中で、１つの放送サービス（Service-3）が転送される構成となる。
【０３５０】
（第２の配信構成のESGサービスの構成例）
図３７は、第２の配信構成の場合のESGサービスの構成例を示す図である。
【０３５１】
ブロードキャストストリームIDとして、bsid = bsid-2を持つブロードキャストストリーム２は、２つのROUTEセッション（RouteSession-2-1，RouteSession-2-esg）からなる。単一の放送サービス（Service-3）は、ROUTEセッション２−１（dIpAddr-svc-3）で運ばれ、そのサービス３（svc-3）は、時間の方向に、複数の番組（Content）からなる。
【０３５２】
図３７においては、図中の左側から右側に向かう方向を時間の方向としたとき、サービス３（svc-3）では、時刻t1から時刻t2の間は、コンテンツ３−１（cnt-3-1）が配信され、時刻t2以降は、コンテンツ３−２（cnt-3-2）が配信される。このサービス３（svc-3）の番組編成は、上述したサービス１，２（svc-1，2）と同様に、サービス３と同一のブロードキャストストリーム２（bsid-2）のROUTEセッション２−esg（dIpAddr-svc-esg-2）で転送されるESGサービス（svc-esg-2）により、受信側に通知される。
【０３５３】
ESGサービスのROUTEセッション２−esg（dIpAddr-svc-esg-2）のLCTセッションには、サービス、コンテンツ、及びスケジュールのXMLフラグメントが、ESG情報として、当該サービス（番組）が配信される数日から数週間前に配信される。
【０３５４】
ここでは、次のXMLフラグメントがESG情報に含まれる。すなわち、第２の配信構成の場合、サービス３（Service-3）、コンテンツ３−１（Content-3-1）、コンテンツ３−２（Content-3-2）、スケジュール３−１（Schedule-3-1）、及びスケジュール３−２（Schedule-3-2）のXMLフラグメントが、ESG情報として配信される。
【０３５５】
（XMLフラグメントの関係）
図３８は、第２の配信構成の場合のサービス、コンテンツ、及びスケジュールのXMLフラグメントの関係を示す図である。
【０３５６】
ServiceFragment-3.xmlには、サービス名等のService-3の属性が記述される。
【０３５７】
ContentFragment-3-1.xmlには、番組名等のContent-3-1の属性が記述される。また、ContentFragment-3-2.xmlには、番組名等のContent-3-2の属性が記述される。なお、Content-3-1とContent-3-2のXMLフラグメントは、Service-3のXMLフラグメントに関連付けられる。
【０３５８】
ScheduleFragment-3-1.xmlには、Content-3-1の開始時刻t1等のSchedule-3-1のスケジュール属性が記述される。また、ScheduleFragment-3-2.xmlには、Content-3-2の開始時刻t2等のSchedule-3-2のスケジュール属性が記述される。
【０３５９】
なお、Schedule-3-1とSchedule-3-2のXMLフラグメントは、Service-3のXMLフラグメントに関連付けられる。また、Schedule-3-1のXMLフラグメントは、Content-3-1のXMLフラグメントに関連付けられ、Schedule-3-2のXMLフラグメントは、Content-3-2のXMLフラグメントに関連付けられる。
【０３６０】
（ESGサービスの画面例）
図３９は、第２の配信構成の場合のESGサービスの画面の表示例を示す図である。
【０３６１】
図３９のESGサービスの画面は、例えば、ブロードキャストストリーム１，２（bsid-1，bsid-2）を受信可能なFWプロキシ装置１０と同一のネットワーク３０に接続されたクライアント装置２０で表示される画面の表示例である。
【０３６２】
すなわち、第２の配信構成では、第１の配信構成と同様に、ブロードキャストストリーム１（bsid-1）で、サービス１，２（svc-1，svc-2）が配信され、さらに、ブロードキャストストリーム２（bsid-2）で、サービス３（svc-3）が配信される。したがって、受信側では、２つのブロードキャストストリーム（bsid-1，bsid-2）を受信可能であれば、３つの放送サービス（svc-1，svc-2，svc-3）の番組編成に関する情報が、時系列で表示されることになる。
【０３６３】
図３９においては、サービス１（svc-1）、サービス２（svc-2）、サービス３（svc-3）のサービス名に対応して、時間帯ごとに、各放送サービスで配信される番組が表示される。
【０３６４】
サービス１では、時間帯t1-t2に、コンテンツ１−１（cnt-1-1）が配信され、時間帯t2以降に、コンテンツ１−２（cnt-1-2）が配信される。また、サービス２では、時間帯t1-t2に、コンテンツ２−１（cnt-2-1）が配信され、時間帯t2以降に、コンテンツ２−２（cnt-2-2）が配信される。また、サービス３では、時間帯t1-t2に、コンテンツ３−１（cnt-3-1）が配信され、時間帯t2以降に、コンテンツ３−２（cnt-3-2）が配信される。
【０３６５】
なお、図３９に示したESGサービスの画面の表示例は、一例であり、他の表示形態で表示されるようにしてもよい。例えば、コンテンツごとに、コンテンツ名を表示するだけでなく、サービスタイプや概要などの様々な属性を表示させることができる。
【０３６６】
以上、第２の配信構成の場合のESGサービスの構成について説明した。
【０３６７】
（３）第３の配信構成の場合のESGサービスの構成
【０３６８】
次に、第３の配信構成の場合のESGサービスの構成例について説明する。この第３の配信構成では、上述した第２の配信構成で、時刻t2から開始されるブロードキャストストリーム１（bsid-1）のサービス２（svc-2）のコンテンツ２−２（cnt-2-2）を配信するにあたって、ブロードキャストストリーム２（bsid-2）のサービス３（svc-3）のコンテンツ３−２（cnt-3-2）に割り当てられていた帯域を同時に利用して配信する構成となる。そして、このブロードキャストストリーム２（bsid-2）では、サービス２（svc-2）のコンテンツ２−２（cnt-2-2）として、付加的なストリームのみが配信されるものとする。
【０３６９】
（第３の配信構成の場合のBS-1の構成例）
図４０は、第３の配信構成の場合でのブロードキャストストリーム１（bsid-1）の構成例を示す図である。
【０３７０】
図４０において、ブロードキャストストリーム１（bsid-1）は、３つのROUTEセッション（RouteSession-1-1，RouteSession-1-2，RouteSession-1-esg）で、サービス１（svc-1）と、サービス２（svc-2）と、ESGサービス（svc-esg-1）を配信している。
【０３７１】
図４０においては、時間の方向を、図中の左側から右側に向かう方向としたとき、サービス１（svc-1）では、コンテンツ１−１（cnt-1-1）と、コンテンツ１−２（cnt-1-2）が順次配信される。また、サービス２（svc-2）では、コンテンツ２−１（cnt-2-1）と、コンテンツ２−２（cnt-2-2）が順次配信される。さらにまた、ESGサービス（svc-esg-1）では、サービス１，２についてのサービス（Service）、コンテンツ（Content）、及びスケジュール（Schedule）のXMLフラグメントが、当該サービス（番組）が配信される数日から数週間前に配信される。
【０３７２】
（XMLフラグメントの関係）
図４１は、第３の配信構成の場合のサービス、コンテンツ、及びスケジュールのXMLフラグメントの関係を示す図である。
【０３７３】
図４１の上段に示すように、サービス１（svc-1）についてのServiceFragment-1と、ContentFragment-1-1，ContentFragment-1-2，ScheduleFragment-1-1，ScheduleFragment-1-2とは、関連付けられ、サービス１の番組編成を構成している。
【０３７４】
一方で、図４１の下段に示すように、サービス２（svc-2）についてのServiceFragment-2と、ContentFragment-2-1，ContentFragment-2-2，ScheduleFragment-2-1，ScheduleFragment-2-2とは、関連付けられ、サービス２の番組編成を構成している。
【０３７５】
（第３の配信構成の場合のBS-2の構成例）
図４２は、第３の配信構成の場合でのブロードキャストストリーム２（bsid-2）の構成例を示す図である。
【０３７６】
図４２において、ブロードキャストストリーム２（bsid-2）は、２つのROUTEセッション（RouteSession-2-1，RouteSession-2-esg）で、サービス３（svc-3）又はサービス２（svc-2）と、ESGサービス（svc-esg-2）を配信している。
【０３７７】
図４２においては、時間の方向を、図中の左側から右側に向かう方向としたとき、サービス３（svc-3）又はサービス２（svc-2）では、コンテンツ３−１（cnt-3-1）と、コンテンツ２−２（cnt-2-2）が順次配信される。また、ESGサービス（svc-esg-2）では、サービス３又はサービス２についてのサービス（Service）、コンテンツ（Content）、及びスケジュール（Schedule）のXMLフラグメントが、当該サービス（番組）が配信される数日から数週間前に配信される。
【０３７８】
（XMLフラグメントの関係）
図４３は、第３の配信構成の場合のサービス、コンテンツ、及びスケジュールのXMLフラグメントの関係を示す図である。
【０３７９】
図４３の上段に示すように、サービス２（svc-2）についてのServiceFragment-2と、ContentFragment-2-2，ScheduleFragment-2-2とは、関連付けられ、時刻t2を経過した後に配信されるサービス２の番組編成を構成している。
【０３８０】
一方で、図４３の下段に示すように、サービス３（svc-3）についてのServiceFragment-3と、ContentFragment-3-1，ScheduleFragment-3-1とは、関連付けられ、時刻t2を経過する前に配信されるサービス３の番組編成を構成している。
【０３８１】
（ESGサービスの画面例）
図４４は、第３の配信構成の場合のESGサービスの画面の表示例を示す図である。
【０３８２】
図４４のESGサービスの画面は、例えば、ブロードキャストストリーム１，２（bsid-1，bsid-2）を受信可能なFWプロキシ装置１０と同一のネットワーク３０に接続されたクライアント装置２０で表示される画面の表示例である。
【０３８３】
すなわち、第３の配信構成では、ブロードキャストストリーム１（bsid-1）で、サービス１，２（svc-1，svc-2）が配信され、ブロードキャストストリーム２（bsid-2）で、サービス３（svc-3）又はサービス２（svc-2）が配信される。したがって、受信側では、２つのブロードキャストストリーム（bsid-1，bsid-2）を受信可能であれば、３つの放送サービス（svc-1，svc-2，svc-3）の番組編成に関する情報が、時系列で表示されることになる。
【０３８４】
図４４においては、図３９の画面例と同様に、サービス１（svc-1）、サービス２（svc-2）、サービス３（svc-3）のサービス名に対応して、時間帯ごとに、各サービスで配信される番組が表示される。
【０３８５】
サービス１では、時間帯t1-t2に、コンテンツ１−１（cnt-1-1）が配信され、時間帯t2以降に、コンテンツ１−２（cnt-1-2）が配信される。サービス２では、時間帯t1-t2に、コンテンツ２−１（cnt-2-1）が配信され、時間帯t2以降に、コンテンツ２−２（cnt-2-2）が配信される。
【０３８６】
サービス３では、時間帯t1-t2に、コンテンツ３−１（cnt-3-1）が配信されるが、時間帯t2以降には、コンテンツの配信は行われない。すなわち、第３の配信構成では、ブロードキャストストリーム２（bsid-2）のサービス３（svc-3）のコンテンツ３−２（cnt-3-2）に割り当てられていた帯域を利用して、サービス２（svc-2）のコンテンツ２−２（cnt-2-2）の付加的なストリームを配信するため、時間帯t2以降においては、サービス３の配信は停止して、サービス１とサービス２のみが配信されることなる。
【０３８７】
ここでは、例えば、第３の配信構成で、サービス２（svc-2）のコンテンツ２−２（cnt-2-2）に対し、スケーラブル符号化を適用して、ブロードキャストストリーム１（bsid-1）のROUTEセッション（RouteSession-1-1）では、ベースレイヤのストリームを転送し、ブロードキャストストリーム２（bsid-2）のROUTEセッション（RouteSession-2-1）では、エンハンスレイヤのストリームを転送することができる。これにより、スケーラブル符号化を利用した放送サービスなどような広帯域サービスであっても、動的にスケジュールして配信することが可能となる。
【０３８８】
（ESG情報の拡張）
ここで、受信側のFWプロキシ装置１０で、複数のチューナを用意できる場合に、上述のサービス２（svc-2）のコンテンツ２−２（cnt-2-2）が配信される前に、複数のチューナを稼働させておいて、コンテンツ２−２（cnt-2-2）が配信されると、FWプロキシ装置１０では、直ちに、ブロードキャストストリーム１，２（bsid-1，bsid-2）を同時に受信して、パケットを取りこぼすことなく、コンテンツ２−２（cnt-2-2）を再生したい（録画したい）という提案が要請される可能性がある。
【０３８９】
しかしながら、現状の技術では、複数のブロードキャストストリームにまたがる番組である旨を通知するための方式はなく、そのような技術方式の確立が求められる。例えば、現行のESGの仕様では、そのような通知を行うことができないため（下記の非特許文献３参照）、本技術では、現行のESGを拡張して、複数のブロードキャストストリームにまたがる番組である旨を通知できるようにして、FWプロキシ装置１０で事前稼働準備が可能なようにする。
【０３９０】
非特許文献３：ATSC Candidate Standard: Service Announcement (A/332)
【０３９１】
すなわち、本技術では、上述したSLS（のS-TSIDメタデータ）のみならず、ESG情報によっても、複数のブロードキャストストリームにまたがる放送サービスの存在を通知できるようにして、FWプロキシ装置１０において、複数のチューナを視聴予約番組の放送時刻に稼働予約できるようにする。
【０３９２】
例えば、ブロードキャストストリームを同時に２つしか受信できない環境において、ブロードキャストストリーム１，２（bsid-1，bsid-2）にまたがって配信されるサービス２（svc-2）のコンテンツ２−２（cnt-2-2）を視聴予約（録画予約）している場合に、それに並行して、同時刻に配信される別の放送サービスのコンテンツも視聴予約（録画予約）しようとしたとき、次のような問題が生じる。すなわち、前者の放送サービスの受信のためには、２つのチューナが同時に必要になるため、前者の放送サービスと後者の放送サービスのどちらを優先するかの優先度付けを促す必要が生じる。
【０３９３】
そこで、本技術では、複数のブロードキャストストリームにまたがる放送サービス（番組）である旨を通知できるようにするため、ESGのスケジュールフラグメント（ScheduleFragment）に、当該スケジュールフラグメントが記述する対象のサービスや、コンテンツが配信されるブロードキャストストリームのブロードキャストストリームID（bsid）を参照する要素（配信構成情報）を配置できるようにする。
【０３９４】
（ESG情報の構成）
上述したように、ESG(Electronic Service Guide)は、OMA(Open Mobile Alliance)によりその仕様が策定されており、本技術のESG情報も、OMA-ESGに準拠した構成からなる。
【０３９５】
ESGは、それぞれの目的を有するフラグメントで構成され、使用する用途に応じて、アドミニストラティブ（Administrative）、プロビジョニング（Provisioning）、コア（Core）、及び、アクセス（Access）からなる４つのグループに分けられる。
【０３９６】
コアは、サービスそれ自体に関する情報を提供するグループである。コアのグループは、サービス（Service）、スケジュール（Schedule）、及び、コンデンツ（Content）から構成される。サービスは、チャンネル・サービスの内容、及び、関連する制御情報を含むメタデータを提供する。スケジュールは、コンテンツの配信スケジュール、及び、関連する制御情報を含むメタデータを提供する。コンデンツは、サービスを構成するコンデンツの内容、及び、関連する制御情報を含むメタデータを提供する。
【０３９７】
図４５には、ESGのスケジュールフラグメント（ScheduleFragment）の構成例を示している。また、図４６には、ESGのスケジュールフラグメントのスキーマの例を示している。
【０３９８】
図４６に示すように、本技術のESG情報では、ESGのスケジュール（Schedule）を拡張して、PrivateExt要素に、bsidReference要素を追加する。このbsidReference要素には、放送サービスが、複数のブロードキャストストリームをまたいで配信される場合に、対象のブロードキャストストリームのブロードキャストストリームIDを指定することができる。
【０３９９】
図４７は、ESGのスケジュールフラグメントのXMLインスタンスの例を示す図である。図４７においては、スケジュール（Schedule）のPrivateExt要素のbsidReference要素に、"xxxx"と"yyyy"の２つのブロードキャストストリームID（bsid）が記述されており、これらのブロードキャストストリームID（bsid）を、サービス（Service）やコンデンツ（Content）のフラグメントが参照することができる。
【０４００】
より具体的には、上述した第３の配信構成の場合に、サービス２（svc-2）に関連するESGのフラグメントを図示すると、図４８に示すようになる。すなわち、図４８は、ServiceFragment-2，ContentFragment-2-1/-2-2，ScheduleFragment-2-1/-2-2のXMLインスタンスの例を示している。
【０４０１】
ServiceFragment-2.xmlには、Service要素のName要素により、サービス名として、Service-2が指定されている。
【０４０２】
ContentFragment-2-1.xmlには、Content要素のName要素により、番組名として、Content-2-1が指定される。また、ContentFragment-2-2.xmlには、Content要素のName要素により、番組名として、Content-2-2が指定される。
【０４０３】
また、ContentFragment-2-1.xmlと、ContentFragment-2-2.xmlでは、ServiceReference要素のidRef属性の値が、ServiceFragment-2.xmlのService要素のid属性の値と関連付けられている。
【０４０４】
ScheduleFragment-2-1.xmlには、PresentationWindow要素のstartTime属性とendTime属性により、Content-2-1の開始時刻と終了時刻が指定される。この例では、startTime属性により、Content-2-1の開始時刻t1として、'2016-02-17T12:00:00+00:00' が指定され、endTime属性により、Content-2-1の終了時刻t2として、'2016-02-17T12:30:00+00:00' が指定される。
【０４０５】
ScheduleFragment-2-2.xmlには、PresentationWindow要素のstartTime属性とendTime属性により、Content-2-2の開始時刻と終了時刻が指定される。この例では、startTime属性により、Content-2-2の開始時刻t2として、'2016-02-17T12:30:00+00:00' が指定され、endTime属性により、Content-2-2の終了時刻として、'2016-02-17T12:45:00+00:00' が指定される。
【０４０６】
ここで、ScheduleFragment-2-2.xmlには、PrivateExt要素のbsidReference要素として、"BroadcastStream-1"と、"BroadcastStream-2"であるブロードキャストストリームID（bsid）が指定されている。これにより、サービス２（svc-2）のコンテンツ２−２（cnt-2-2）が、ブロードキャストストリーム１（bsid-1）とブロードキャストストリーム２（bsid-2）にまたがって配信されることを意味することになる。
【０４０７】
また、ScheduleFragment-2-1.xmlと、ScheduleFragment-2-2.xmlでは、ServiceReference要素のidRef属性の値が、ServiceFragment-2.xmlのService要素のid属性の値と関連付けられている。さらに、ScheduleFragment-2-1.xmlでは、ContentReference要素のidRef属性の値が、ContentFragment-2-1.xmlのContent要素のid属性の値と関連付けられている。また、ScheduleFragment-2-2.xmlでは、ContentReference要素のidRef属性の値が、ContentFragment-2-2.xmlのContent要素のid属性の値と関連付けられている。
【０４０８】
（ESGサービスの画面例）
図４９は、第３の配信構成の場合のESGサービスの画面の表示例を示す図である。
【０４０９】
図４９のESGサービスの画面では、図４４のESGサービスの画面と比べて、時刻t2以降の時間帯に配信されるサービス２（svc-2）のコンテンツ２−２（cnt-2-2）が、ブロードキャストストリーム１，２（bsid-1，bsid-2）にまたがって配信されるため、スケジュールフラグメント（ScheduleFragment-2-2）のbsidReference要素の値を利用して、例えば、「チューナ２台必須」などの注意を促すメッセージを表示している点が異なっている。
【０４１０】
このような表示を行うことで、エンドユーザに対し、コンテンツ２−２（cnt-2-2）の視聴には、同時に稼働可能な複数のチューナが必要であることを事前に通知することができる。これにより、例えば、同時に稼働可能なチューナ数に制限がある環境において、エンドユーザが、複数のチューナが前提となる番組の視聴予約を試みた場合などに、本技術のESG情報を利用して、エンドユーザに対する優先度付けを促すことが可能となる。
【０４１１】
＜７．変形例＞
【０４１２】
（通信経由の配信）
上述した図１の伝送システム１においては、コンテンツのストリームが、放送伝送路６０を介して放送経由で配信される場合を説明したが、コンテンツのストリームは、インターネット等の通信伝送路を介して通信経由で配信されるようにしてもよい。
【０４１３】
図５０には、伝送システムの他の構成例を示している。図５０の伝送システム６においては、図１の伝送システム１と比べて、送信側に、放送系の放送サーバ４０に加えて、通信系の通信サーバ７０が設けられている点が異なっている。
【０４１４】
FWプロキシ装置１０は、放送伝送路６０を介して送信される放送波を受信する受信機能とともに、インターネット８０に接続可能な通信機能（通信I/F（不図示））も有している。これにより、FWプロキシ装置１０は、インターネット８０を介して、通信サーバ７０と相互に接続され、通信を行うことが可能である。
【０４１５】
FWプロキシ装置１０は、ネットワーク３０に接続されたクライアント装置２０からのリクエストを、インターネット８０に接続された通信サーバ７０に送信する。また、FWプロキシ装置１０は、インターネット８０を介して、通信サーバ７０から送信されてくるコンテンツのストリームを受信し、ネットワーク３０に接続されたクライアント装置２０に送信（転送）する。
【０４１６】
ここで、上述したように、ネットワーク３０に接続されるFWプロキシ装置１０−１乃至１０−Ｎにおいては、いずれかのFWプロキシ装置１０が、マスタプロキシとして機能し、それ以外のFWプロキシ装置１０が、スレーブプロキシとして機能するマスタ・スレーブ関係を有している。そして、FWプロキシ装置１０−１乃至１０−Ｎが、マスタ・スレーブ関係を有することで、マスタプロキシ１１１が稼働するマスタ・プロキシ装置１０Ｍによって、各FWプロキシ装置１０に対し、放送サービスの担当範囲が割り当てられるのは、先に述べた通りである。
【０４１７】
これにより、ネットワーク３０に接続されたクライアント装置２０は、エンドユーザの操作などに応じて、FWプロキシ装置１０（マスタ・プロキシ装置１０Ｍ、又はスレーブ・プロキシ装置１０Ｓ）を介して、放送経由又は通信経由で配信されるコンテンツを再生することができる。
【０４１８】
通信サーバ７０は、例えば、放送局などの放送事業者やその他の事業者により提供されるサーバであって、インターネット８０に接続される。
【０４１９】
通信サーバ７０は、FWプロキシ装置１０からのリクエストに応じて、番組やCM等のコンテンツのファイルや制御情報を処理し、その結果得られるデータを、インターネット８０を介して送信（ストリーミング配信）する。
【０４２０】
なお、放送サーバ４０や通信サーバ７０は、番組等のコンテンツだけでなく、例えば、アプリケーションなどを配信するようにしてもよい。すなわち、伝送システム６においては、アプリケーションが放送経由又は通信経由で配信され、FWプロキシ装置１０を介して、クライアント装置２０により受信される。
【０４２１】
また、伝送システム１（図１）と、伝送システム６（図５０）においては、FWプロキシ装置１０により、少なくとも、放送経由で配信されるコンテンツのストリームが処理される構成を示したが、送信側に、通信系の通信サーバ７０のみを設け、FWプロキシ装置１０では、通信経由で配信されるコンテンツのストリームのみが処理されるようにしてもよい。この場合、クライアント装置２０は、通信経由で配信されるコンテンツのみを再生することになる。
【０４２２】
なお、上述した説明では、ネットワーク３０に接続されたFWプロキシ装置１０のうち、１つのFWプロキシ装置１０が、マスタ・プロキシ装置１０Ｍとして機能するとして説明したが、複数のFWプロキシ装置１０が、マスタ・プロキシ装置１０Ｍとして機能するようにしてもよい。また、マスタ・プロキシ装置１０Ｍやスレーブ・プロキシ装置１０Ｓは、図２や図３に示した構成では、コンテンツの再生機能は有していないが、クライアント装置２０と同様に、放送経由又は通信経由で配信されるコンテンツを再生したり、あるいは録画したりすることができる。
【０４２３】
（他の放送規格への適用）
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC（特に、ATSC3.0）を説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。また、上述した説明では、IP伝送方式が採用されるATSC3.0を例にして説明したが、IP伝送方式に限らず、例えば、MPEG2-TS(Transport Stream)方式等の他の方式に適用するようにしてもよい。
【０４２４】
また、デジタル放送の規格としては、地上波放送のほか、放送衛星（BS：Broadcasting Satellite)や通信衛星（CS：Communications Satellite）等を利用した衛星放送や、ケーブルテレビ（CATV：Common Antenna TeleVision）等の有線放送などの規格に適用することができる。
【０４２５】
（その他の変形例）
上述した制御情報（シグナリング）などの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、対象の制御情報やパケットなどの実質的な内容が異なるものではない。例えば、USBD(User Service Bundle Description)は、USD(User Service Description)と称される場合がある。また、例えば、NRT(Non Real Time)は、LCC(Locally Cached Content)などと称される場合がある。
【０４２６】
また、DASHプレーヤは、例えば、HTML5(HyperText Markup Language 5)などのマークアップ言語やJavaScript（登録商標）等のスクリプト言語で開発されたアプリケーションのほか、例えば、Java（登録商標）などのプログラミング言語で開発されたアプリケーションとすることができる。また、このアプリケーションは、ブラウザにより実行されるアプリケーションに限らず、いわゆるネイティブアプリケーションとして、オペレーティングシステム（OS：Operating System）環境などで実行されるようにしてもよい。
【０４２７】
なお、アプリケーションは、何らかの情報を明示的に表示するだけでなく、非表示で（バックグラウンドで）動作されるようにしてもよい（エンドユーザに認識されずに起動するようにしてもよい）。また、コンテンツは、動画や音楽のほか、例えば、電子書籍やゲーム、広告など、あらゆるコンテンツを含めることができる。
【０４２８】
＜８．コンピュータの構成＞
【０４２９】
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図５１は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
【０４３０】
コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。
【０４３１】
入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体１０１１を駆動する。
【０４３２】
以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。
【０４３３】
コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
【０４３４】
コンピュータ１０００では、プログラムは、リムーバブル記録媒体１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。その他、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。
【０４３５】
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
【０４３６】
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０４３７】
また、本技術は、以下のような構成をとることができる。
【０４３８】
（１）
放送サービスのストリームを受信する受信部と、
前記ストリームを処理する処理部と
を備え、
前記ストリームは、物理層よりも上位の上位層で伝送される伝送情報に、放送サービスのストリームが所定の周波数帯域をまたいで配信されていることを示す配信構成情報を含み、
前記処理部は、前記配信構成情報に応じた配信構成からなる前記ストリームを処理する
受信装置。
（２）
前記処理部は、
放送サービスのストリームを受信して、ネットワークに接続されたクライアント装置に送信するプロキシであって、スレーブプロキシに対するマスタプロキシとして機能し、
各プロキシに対して、前記配信構成情報に応じた放送サービスの担当範囲を決定する
（１）に記載の受信装置。
（３）
前記処理部は、前記配信構成情報に基づいて、常に同時稼働が保証されているプロキシに対して、放送サービスの担当範囲として、所定の周波数帯域をまたいで配信される放送サービスを割り当てる
（２）に記載の受信装置。
（４）
前記伝送情報は、上位層の制御情報であり、
前記処理部は、各プロキシに対して、前記上位層の制御情報に含まれる前記配信構成情報に応じた放送サービスの担当範囲を決定する
（２）又は（３）に記載の受信装置。
（５）
前記上位層の制御情報は、セッション間の優先度を示す優先度情報をさらに含み、
前記処理部は、各プロキシに対して、前記上位層の制御情報に含まれる前記配信構成情報と前記優先度情報に応じた放送サービスの担当範囲を決定する
（４）に記載の受信装置。
（６）
前記配信構成情報が示す配信構成として、所定の周波数帯域をまたいで配信される放送サービスを配信する際に最低限必要なストリームを伝送する第１のセッションと、当該放送サービスを配信する際に付加的なストリームを伝送する第２のセッションとを含み、
前記優先度情報は、前記第１のセッションの優先度を、前記第２のセッションの優先度よりも高くなるようにする
（５）に記載の受信装置。
（７）
前記処理部は、前記上位層の制御情報の配信構成を示す情報が更新される度に、各プロキシに対して、前記配信構成情報に応じた放送サービスの担当範囲を決定する
（４）乃至（６）のいずれかに記載の受信装置。
（８）
前記伝送情報は、前記伝送情報に対応する放送サービスのストリームが配信されるよりも、所定の期間だけ先に配信される
（２）に記載の受信装置。
（９）
前記伝送情報は、電子番組表に関する情報である
（８）に記載の受信装置。
（１０）
前記処理部は、前記伝送情報に基づいて、所定の周波数帯域をまたいで配信される放送サービスの配信を通知する
（８）又は（９）に記載の受信装置。
（１１）
前記スレーブプロキシが稼働する他の受信装置は、前記ネットワーク上に１又は複数設置されており、
前記処理部は、
各プロキシと、放送サービスの担当範囲とを対応付けたデータベースを生成し、
前記クライアント装置から、放送サービスのリクエストを受けた場合、前記データベースを参照して、当該放送サービスを担当するプロキシに対し、当該放送サービスのリクエストがリダイレクションされるようにする
（２）又は（３）に記載の受信装置。
（１２）
前記上位層の制御情報は、放送サービスごとに配信される制御情報であり、
前記配信構成情報は、ファイル転送用のプロトコルの制御情報に含まれる
（４）乃至（７）のいずれかに記載の受信装置。
（１３）
前記所定の周波数帯域は、RFチャネルごとに割り当てられる帯域幅である
（１）乃至（１２）のいずれかに記載の受信装置。
（１４）
受信装置のデータ処理方法において、
前記受信装置が、
物理層よりも上位の上位層で伝送される伝送情報に、放送サービスのストリームが所定の周波数帯域をまたいで配信されていることを示す配信構成情報を含むストリームであって、前記配信構成情報に応じた配信構成からなる前記ストリームを処理するステップを含む
データ処理方法。
（１５）
物理層よりも上位の上位層で伝送される伝送情報であって、放送サービスのストリームが所定の周波数帯域をまたいで配信されていることを示す配信構成情報を含む前記伝送情報を生成する生成部と、
前記伝送情報を含むストリームを送信する送信部と
を備える送信装置。
（１６）
前記伝送情報は、前記上位層の制御情報である
（１５）に記載の送信装置。
（１７）
前記上位層の制御情報は、セッション間の優先度を示す優先度情報をさらに含む
（１６）に記載の送信装置。
（１８）
前記上位層の制御情報は、放送サービスごとに配信される制御情報であり、
前記配信構成情報は、ファイル転送用のプロトコルの制御情報に含まれる
（１６）又は（１７）に記載の送信装置。
（１９）
前記伝送情報は、電子番組表に関する情報である
（１５）に記載の送信装置。
（２０）
送信装置のデータ処理方法において、
前記送信装置が、
物理層よりも上位の上位層で伝送される伝送情報であって、放送サービスのストリームが所定の周波数帯域をまたいで配信されていることを示す配信構成情報を含む前記伝送情報を生成し、
前記伝送情報を含むストリームを送信する
ステップを含むデータ処理方法。
【符号の説明】
【０４３９】
１，６  伝送システム，  １０−１乃至１０−Ｍ，１０  FWプロキシ装置，１０Ｍ  マスタ・プロキシ装置，１０Ｓ  スレーブ・プロキシ装置，  ２０−１乃至２０−Ｍ，２０  クライアント装置，  ３０  ネットワーク，  ４０  放送サーバ，  ５０  送信所，  ６０  放送伝送路，  ７０  通信サーバ，  ８０  インターネット，  １００  処理部，  １０１  チューナ，  １０２  通信I/F，  １０３  記憶部，  １１１  マスタプロキシ，  １１２  UPnP/SSDPサーバ，  １１３  SLS処理系，  １５０  処理部，  １５１  チューナ，  １５２  通信I/F，  １５３  記憶部，  １６１  スレーブプロキシ，  １６２  SLS処理系，  ２００  処理部，  ２０１  通信I/F，  ２０２  表示部，  ２０３  スピーカ，  ２１１  アプリケーション，  ２１２  ブラウザ，  ４０１  コンポーネント処理部，  ４０２  制御情報生成部，  ４０３  ESG生成部，  ４０４  マルチプレクサ，  ４０５  データ処理部，  ４０６  送信部，  １０００  コンピュータ，  １００１  CPU
【図１】
2018066355.tif 000003
【図２】
2018066355.tif 000004
【図３】
2018066355.tif 000005
【図４】
2018066355.tif 000006
【図５】
2018066355.tif 000007
【図６】
2018066355.tif 000008
【図７】
2018066355.tif 000009
【図８】
2018066355.tif 000010
【図９】
2018066355.tif 000011
【図１０】
2018066355.tif 000012
【図１１】
2018066355.tif 000013
【図１２】
2018066355.tif 000014
【図１３】
2018066355.tif 000015
【図１４】
2018066355.tif 000016
【図１５】
2018066355.tif 000017
【図１６】
2018066355.tif 000018
【図１７】
2018066355.tif 000019
【図１８】
2018066355.tif 000020
【図１９】
2018066355.tif 000021
【図２０】
2018066355.tif 000022
【図２１】
2018066355.tif 000023
【図２２】
2018066355.tif 000024
【図２３】
2018066355.tif 000025
【図２４】
2018066355.tif 000026
【図２５】
2018066355.tif 000027
【図２６】
2018066355.tif 000028
【図２７】
2018066355.tif 000029
【図２８】
2018066355.tif 000030
【図２９】
2018066355.tif 000031
【図３０】
2018066355.tif 000032
【図３１】
2018066355.tif 000033
【図３２】
2018066355.tif 000034
【図３３】
2018066355.tif 000035
【図３４】
2018066355.tif 000036
【図３５】
2018066355.tif 000037
【図３６】
2018066355.tif 000038
【図３７】
2018066355.tif 000039
【図３８】
2018066355.tif 000040
【図３９】
2018066355.tif 000041
【図４０】
2018066355.tif 000042
【図４１】
2018066355.tif 000043
【図４２】
2018066355.tif 000044
【図４３】
2018066355.tif 000045
【図４４】
2018066355.tif 000046
【図４５】
2018066355.tif 000047
【図４６】
2018066355.tif 000048
【図４７】
2018066355.tif 000049
【図４８】
2018066355.tif 000050
【図４９】
2018066355.tif 000051
【図５０】
2018066355.tif 000052
【図５１】
2018066355.tif 000053
【国際調査報告】
2018066355.tif 000054
2018066355.tif 000055