JP4649091B2 - 通信端末、サーバ装置、中継装置、放送通信システム、放送通信方法及びプログラム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、映像（ビデオ）情報、音声（オーディオ）情報等の放送メディアを放送するための放送通信システム、放送通信方法、及び、これらに用いて好適な通信端末、サーバ装置、中継装置及びプログラムに関する。
【０００２】
【従来の技術】
近年、デジタル衛星放送通信システムの普及が進んでいる。デジタル衛星放送通信システムでは、大容量の通信帯域を利用して多チャンネル化がなされており、スポーツ、映画、音楽、ニュース等の専門チャネルが多数用意されている。これらの専門チャンネルでは、それぞれの専門の企画、内容に応じた番組コンテンツが放送されている。そして、上記デジタル衛星放送通信システムを利用して、かかる番組コンテンツの再生を可能とする放送メディアの放送が行われている。
【０００３】
このような映像情報、音声情報等の放送メディアを放送する放送通信方式として、特開２０００-３５８０６２号公報には、ＭＰＥＧ-２システム規格のデータ送信フォーマットを用いて放送メディア等の各種データを送信する「デジタルデータ送受信システム及びその方法」が開示されている。
【０００４】
また、放送メディア等の各種データを繰り返し伝送する放送通信方式として、特開２００１-５３６９６号公報には、ＩＳＯ/ＩＥＣ１３８１８-６で規定された「ＤＳＭ-ＣＣ（Ｄｉｇｉｔａｌ Ｓｔｏｒａｇｅ Ｍｅｄｉａ Ｃｏｍｍａｎｄ ａｎｄ Ｃｏｎｔｒｏｌ）データカルーセル方式」を用いて放送メディア等の各種データを放送する方式、すなわち、放送メディア等の各種データがＩＳＯ/ＩＥＣ１３８１８-１で規定されたセクション形式に準拠した形式で繰り返し伝送される「デジタル放送におけるセクション送出装置及びセクション送出方法」が開示されている。
【０００５】
一方、インターネットにおける放送通信方式としては、放送通知情報として「ＳＡＰ（Ｓｅｓｓｉｏｎ Ａｎｎｏｕｎｃｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）メッセージ」を用いて「放送メディアを再生するために必要な情報（発信元のＩＰアドレス情報や送信先のＩＰアドレス情報等）」を通知して、音声情報や映像情報等の放送メディアの放送を行う放送通信方式が考えられている。
【０００６】
ＳＡＰメッセージは、予め決められた「ＩＰアドレス」及び「ポート番号」にて伝送される。また、ＳＡＰメッセージは、ＳＡＰメッセージ内に含まれる「当該ＳＡＰメッセージの発信元のＩＰアドレス情報（ｏｒｉｇｉｎａｔｉｎｇ ｓｏｕｒｃｅ）」及び「当該発信元によって送信されるＳＡＰメッセージを一意に特定するメッセージＩＤ（ｍｓｇ ｉｄ ｈａｓｈ）」によって、一意に識別される。
【０００７】
インターネットにおけるＳＡＰメッセージを用いた放送通信方式では、ＳＡＰメッセージ内の「ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）情報」内の「ｃフィールド」に、放送メディアが送信されている「マルチキャストアドレス（送信先のＩＰアドレス情報）」を指定するのが一般的である。受信者は、当該「ｃフィールド」により放送メディアが送信されている「マルチキャストアドレス（送信先のＩＰアドレス情報）」を知り、当該放送メディアを視聴することが可能となる。
【０００８】
図４５に、従来の放送通信システムにおいて、２つの放送メディアを送信する例を示す。
【０００９】
具体的には、図４５は、１つのチャネル上で、２つの「ＳＡＰメッセージ（ＳＡＰ１，ＳＡＰ２）」と、各ＳＡＰメッセージに対応する「ＲＴＰ（Ｒｅａｌ-ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ：ＲＦＣ１８８９）パケット（ＲＴＰ１-ａ及びＲＴＰ１-ｂ，ＲＴＰ２-ａ及びＲＴＰ-ｂ）」とを送信する例である。
【００１０】
図４６は、ＳＡＰメッセージ内での「ＳＤＰ情報」の記述例である。図４６では、「ｃ＝ＩＮ ＩＰ４ ２２４．２．１７．１２/１２７」の部分で、放送メディアの「マルチキャストアドレス（送信先のＩＰアドレス情報）」が示されている。したがって、このＳＡＰメッセージを受信した受信端末は、かかるマルチキャストアドレスにより放送メディアが放送されることが判断できる。
【００１１】
また、パケット型通信方式では、音声情報及び映像情報を含むパケットは、ＲＴＰパケットとして伝送される。ＲＴＰパケットには、ヘッダとして「ＲＴＰ／ＵＤＰ／ＩＰヘッダ」が付加されることになり、そのオーバーヘッドが非常に大きい。
【００１２】
ＲＴＰ／ＵＤＰ／ＩＰヘッダのオーバーヘッドを低減（圧縮）する方法としては、ＩＥＴＦのＲＦＣ２５０８で規定される「ＣＲＴＰ」やＲＦＣ３０９５で規定される「ＲＯＨＣ」が知られている。
【００１３】
いずれのヘッダ圧縮方法も、最初に、ヘッダ圧縮状態を初期化する「ヘッダ圧縮リフレッシュパケット」を送信した後、ヘッダの圧縮された「ヘッダ圧縮パケット」を送信する。「ＣＲＴＰ」では、「ＦＵＬＬ＿ＨＥＡＤＥＲ」が、ヘッダ圧縮リフレッシュパケットに当たり、「ＲＯＨＣ」では、「ＩＲヘッダ」が、ヘッダ圧縮リフレッシュパケットに当たる。
【００１４】
【特許文献１】
特開２０００-３５８０６２号公報
【００１５】
【特許文献２】
特開２００１-５３６９６号公報
【００１６】
【発明が解決しようとする課題】
一般的に、大容量の通信帯域を有するデジタル衛星放送通信システムやインターネットにおける放送通信システムにおいては、放送メディアの繰り返し送信におけるオーバーヘッドにも寛容である。
【００１７】
しかしながら、比較的小容量（低ビットレート）の通信帯域しか利用できない移動通信端末等を受信端末とする放送通信システムにおいては、上述のオーバーヘッドにより、音声情報や映像情報等の伝送容量の圧迫がより顕著に表れるという問題点があった。
【００１８】
また、上述のオーバーヘッドを抑えるために、上記で説明したヘッダ圧縮方法を単純にパケット型放送通信システムに適用した場合、放送メディアの放送の途中から視聴を始めた受信端末では、ヘッダ圧縮パケットを受信しても、ヘッダ圧縮状態が分からないため、当該パケットを復元することができないという問題点があった。
【００１９】
また、従来のインターネットにおけるＳＡＰメッセージを用いた放送通信方式では、放送メディアの送信に用いられる「物理チャネル」が１つしかないため、ＳＡＰメッセージ内の「ＳＤＰ情報」の「ｃフィールド」に記述されたＩＰアドレスの指定で、放送メディアを視聴することができるが、移動通信端末を用いた放送通信方式では、複数の無線チャネル（物理チャネル）を用いて複数の放送メディアを放送することが考えられるため、上述のＩＰアドレスの指定だけでは、どの無線チャネルに放送メディアが流れているかを特定することができないという問題点があった。
【００２０】
すなわち、移動通信端末を用いた放送通信方式では、放送メディアの放送に用いる「物理チャネル」と「論理アドレス（ＩＰアドレス）」とを、どのように対応付けるかという課題が生じる。
【００２１】
さらに、受信端末からの指示によってマルチメディア情報を受信して再生する通信方式と違って、放送通信方式におけるマルチメディア情報（放送メディア）の受信及び再生では、放送メディア提供者（発信元）は、受信者がどのタイミングで受信を始めるか知ることができず、受信者に放送メディアを確実に再生させることができない場合があるという問題点があった。
【００２２】
本発明は、かかる問題点に鑑みてなされたもので、放送メディアの放送に伴うオーバーヘッドを抑えつつ、放送メディアを素早く再生することを可能とすることを目的とする。
【００２３】
また、本発明は、放送通知情報（ＳＡＰメッセージ又はＨ.２４５メッセージ）を送信した直後に送信する放送メディアを、ヘッダ圧縮リフレッシュパケットによって送信することによって、放送メディアの放送の途中から視聴を始めた受信端末であっても、直ちに放送メディアを再生することを可能とすることを目的とする。
【００２４】
このことにより、放送通知情報を受信し、放送メディアの放送の途中から視聴を始めた受信端末であっても、ヘッダ圧縮リフレッシュパケットによって送信された放送メディアを受信した後、ヘッダ圧縮パケットによって送信された放送メディアを再生することが可能となり、すばやい再生と伝送のオーバーヘッドの削減を実現することが可能となる。
【００２５】
また、本発明は、放送メディアの放送に用いる「物理チャネル」と「論理アドレス（ＩＰアドレス）」とを対応付け、受信端末に通知することを目的とする。
【００２６】
さらに、本発明は、放送メディア提供者が意図する再生方法を、受信端末に指示することを可能とし、受信端末が当該指示に従って放送メディアを再生することを目的とする。
【００２７】
【課題を解決するための手段】
本発明の第１の特徴は、受信した放送メディアを再生する通信端末であって、前記放送メディアの再生に先立って、該放送メディアの再生方法を示す再生情報を取得し、少なくとも一つの前記放送メディアを指定する放送通知情報を受信した場合、前記再生情報に基づいて、指定された該放送メディアを再生することを要旨とする。
【００２８】
かかる発明によれば、通信端末が、再生情報に基づいて放送メディアを再生するため、放送メディアの提供者が意図する再生方法に従って、任意の放送メディアを素早く再生することが可能となる。また、事前に取得した再生情報（予め保持しているもの等）を用いることによって、無線チャネルを介して全ての再生情報を受信する前に放送メディアを再生することが可能となる。
【００２９】
本発明の第１の特徴において、前記放送メディアの再生に先立って、前記再生情報に関連付けられた参照情報を取得し、前記参照情報を用いて前記再生情報を取得することが好ましい。
【００３０】
また、本発明の第１の特徴において、前記再生情報が、前記放送メディアの再生の際に用いられるレイアウト情報を含むことが好ましい。
【００３１】
かかる発明によれば、通信端末の表示部において、放送メディアを表示するレイアウトを自由に変更することが可能となる。
【００３２】
また、本発明の第１の特徴において、前記再生情報が、前記放送メディアの再生の際に用いられるタイミング情報を含むことが好ましい。
【００３３】
かかる発明によれば、通信端末において、放送メディアの再生についての時間同期制御、例えば、映像情報とテキスト情報の同期処理等を行うことが可能となる。
【００３４】
また、本発明の第１の特徴において、前記放送メディアの再生に先立って、必ず行うべき必須処理を示す必須処理情報を受信した場合に、前記必須処理を行った後で該放送メディアを再生することが好ましい。
【００３５】
かかる発明によれば、放送メディアの提供者の意図を、通信端末における放送メディアの再生により詳細に反映させることが可能となる。
【００３６】
また、本発明の第１の特徴において、前記必須処理情報が、放送通知情報に含まれていることが好ましい。
【００３７】
かかる発明によれば、配信データが欠落する環境においても、通信端末において、放送メディア再生のための再生情報を処理する前に必須処理情報を取得することができ、放送メディア提供者の意図を反映することが可能となる。
【００３８】
また、本発明の第１の特徴において、前記必須処理情報が、前記放送メディアの再生と同時に行うべき処理内容を示すものであり、前記通信端末が、前記放送メディアの再生と同時に前記必須処理を行うことが好ましい。
【００３９】
また、本発明の第１の特徴において、無線チャネルを介して受信した前記放送メディアを再生する場合であって、前記放送通知情報に、前記放送メディアが送信される物理チャネル識別情報と論理チャネル識別情報との対応情報とが含まれている場合に、該対応情報に基づいて、該放送メディアを再生することが好ましい。
【００４０】
かかる発明によれば、通信端末において、放送メディアの放送に用いる「物理チャネル」と「論理アドレス（ＩＰアドレス）」とを対応付けることが可能となる。
【００４１】
また、本発明の第１の特徴において、前記論理チャネル識別情報は、ＩＰアドレスであることが好ましい。また、本発明の第１の特徴において、前記物理チャネル識別情報が、ＣＤＭＡ通信方式のチャネライゼーションコードであることが好ましい。また、本発明の第１の特徴において、前記物理チャネル識別情報は、周波数値であることが好ましい。
【００４２】
また、本発明の第１の特徴において、前記放送通知情報が、前記放送メディアを識別する放送メディア識別情報を含み、前記再生情報として、前記放送メディア識別情報を用いることが好ましい。
【００４３】
本発明の第２の特徴は、放送メディアを通信端末に配信するサーバ装置であって、少なくとも一つの放送メディアを指定する放送通知情報を送信し、前記通信端末による前記放送メディアの再生に先立って、該放送通知情報によって指定された前記放送メディアの再生方法を示す再生情報を送信することを要旨とする。
【００４４】
本発明の第２の特徴において、前記通信端末による前記放送メディアの再生に先立って、前記再生情報に関連付けられた参照情報を送信することが好ましい。
【００４５】
かかる発明によれば、サーバ装置が、再生情報の代わりに参照情報を送信するため、サーバ装置が、再生情報を送信することなく、放送メディアの提供者が意図する再生方法を通信端末に送信することが可能となると共に、サーバ装置から通信端末に送信するデータ量を削減することも可能となる。
【００４６】
本発明の第２の特徴において、放送通知情報を周期的に繰り返し送信し、前記放送通知情報を送信した直後に、カルーセルデータによって、前記再生情報を送信することが好ましい。
【００４７】
かかる場合、放送通知情報（ＳＡＰメッセージ）及びカルーセルデータにより繰り返し送信される再生情報（ＳＭＩＬ）によって、放送メディアの放送の途中から視聴を始めた通信端末であっても、放送メディアを再生することが可能となる。
【００４８】
また、本発明の第２の特徴において、前記放送通知情報が、前記カルーセルデータによって前記再生情報を送信することを示すことが好ましい。
【００４９】
かかる発明によれば、カルーセルデータによって送信される再生情報（ＳＭＩＬ）を変更することによって、放送通知情報（ＳＡＰメッセージ）を変更することなく、放送メディアの送信を継続することが可能となる。
【００５０】
また、本発明の第２の特徴において、前記再生情報が、前記放送メディアの再生の際に用いられるレイアウト情報を含むことが好ましい。
【００５１】
また、本発明の第２の特徴において、前記再生情報が、前記放送メディア再生の際に用いられるタイミング情報を含むことが好ましい。
【００５２】
また、本発明の第２の特徴において、前記通信端末による前記放送メディアの再生に先立って、該通信端末が必ず行うべき必須処理を示す必須処理情報を送信することが好ましい。
【００５３】
また、本発明の第２の特徴において、前記必須処理情報が、前記放送通知情報に含まれることが好ましい。
【００５４】
また、本発明の第２の特徴において、前記必須処理情報が、前記通信端末によって前記放送メディアの再生と同時に行われるべき処理内容を示すものであることが好ましい。
【００５５】
また、本発明の第２の特徴において、無線チャネルを介して放送メディアを通信端末に配信する場合に、前記放送通知情報によって、前記放送メディアが送信される物理チャネル識別情報と論理チャネル識別情報との対応情報を送信することが好ましい。
【００５６】
また、本発明の第２の特徴において、前記論理チャネル識別情報が、ＩＰアドレスであることが好ましい。また、本発明の第２の特徴において、前記物理チャネル識別情報が、ＣＤＭＡ通信方式のチャネライゼーションコードであることが好ましい。また、本発明の第２の特徴において、前記物理チャネル識別情報が、周波数値であることが好ましい。
【００５７】
また、本発明の第２の特徴において、前記放送通知情報の送信後、最初に、他の放送メディアを参照することなく再生可能な形式で、前記放送メディアを前記通信端末に送信することが好ましい。
【００５８】
また、本発明の第２の特徴において、前記放送通知情報の送信後、最初に、予測符号化を行うことなく再生可能な形式で（ヘッダ圧縮リフレッシュパケットやＩピクチャフレーム等によって）、前記放送メディアを前記通信端末に送信することが好ましい。
【００５９】
かかる発明によれば、通信端末は、放送通知情報の送信後に最初に送信された放送メディアを受信した場合、他の放送メディア（ヘッダ圧縮リフレッシュパケットやＩピクチャフレーム等によって送信される放送メディア）の受信を待つまでもなく、直ちに当該放送メディアを再生することが可能となる。
【００６０】
また、本発明の第２の特徴において、前記放送通知情報の送信後に最初に送信する放送メディアとその旨を示す識別情報とを関連付けて送信することが好ましい。
【００６１】
また、本発明の第２の特徴において、前記放送メディアを識別する放送メディア識別情報を含む前記放送通知情報を送信し、前記メディア識別情報と前記再生情報とを関連付けて送信するように機能させることが好ましい。
【００６２】
本発明の第３の特徴は、サーバ装置から送信された放送メディアを通信端末に中継する中継装置であって、前記サーバ装置によって放送通知情報が送信された後に最初に送信された少なくとも１つの放送メディアを、他の放送メディアを参照することなく再生可能な形式で前記通信端末に中継することを要旨とする。
【００６３】
かかる発明によれば、中継装置が、放送通知情報（ＳＡＰメッセージやＨ.２４５メッセージ）の後に最初に受信した放送メディア以外の放送メディアを、ヘッダ圧縮パケット又はＩピクチャフレーム等として通信端末に中継するため、オーバーヘッドを削減することが可能となる。
【００６４】
また、かかる発明によれば、中継装置が、放送通知情報（ＳＡＰメッセージやＨ.２４５メッセージ）の後に最初に受信した放送メディア以外の放送メディアを、ヘッダ圧縮パケット又はＩピクチャフレーム等として通信端末に中継するため、放送メディアの放送の途中から視聴を始めた通信端末であっても、素早く放送メディアを再生することを可能となる。
【００６５】
また、本発明の第４の特徴は、サーバ装置から送信された放送メディアを通信端末に中継する中継装置であって、前記サーバ装置から受信した前記放送メディアに、該放送メディアが放送通知情報の送信後に最初に送信するものである旨を示す識別情報が関連付けられている場合に、他の放送メディアを参照することなく再生可能な形式で、該放送メディアを前記通信端末に中継することを要旨とする。
【００６６】
かかる発明によれば、放送通知情報の送信後に最初に送信するものである旨を示す識別情報に関連付けられた放送メディアについては、他の放送メディアを参照することなく再生可能な形式で（例えば、ヘッダ圧縮リフレッシュパケット）として中継するため、放送メディアの放送の途中から視聴を始めた通信端末であっても、素早く放送メディアを再生することが可能となる。
【００６７】
また、本発明の第５の特徴は、サーバ装置から送信された放送メディアを通信端末に中継する中継装置であって、前記サーバ装置から受信した前記放送メディアに、該放送メディアが放送通知情報の送信後に最初に送信するものである旨を示す識別情報が関連付けられている場合に、該放送メディアを、予測符号化を行うことなく再生可能な形式で、該放送メディアを前記通信端末に中継することを要旨とする。
【００６８】
かかる発明によれば、放送通知情報の送信後に最初に送信するものである旨を示す識別情報に関連付けられた放送メディアについては、予測符号化を行うことなく再生可能な形式で、（例えば、Ｉピクチャフレーム等）として中継するため、放送メディアの放送の途中から視聴を始めた通信端末であっても、素早く放送メディアを再生することが可能となる。
【００６９】
本発明の第６の特徴は、サーバ装置から通信端末に放送メディアを送信する放送通信システムであって、前記サーバ装置が、少なくとも一つの放送メディアを指定する放送通知情報を送信し、前記通信端末による放送メディアの再生に先立って、前記放送通知情報によって指定された前記放送メディアの再生方法を示す再生情報を送信し、前記通信端末が、前記放送通知情報を受信した場合に、前記再生情報に基づいて、該放送通知情報によって指定された前記放送メディアを再生することを要旨とする。
【００７０】
本発明の第７の特徴は、中継装置がサーバ装置からの放送メディアを通信端末に中継する放送通信システムであって、前記中継装置が、前記サーバ装置によって放送通知情報が送信された後に最初に送信された少なくとも１つの放送メディアを、他の放送メディアを参照することなく再生可能な形式で前記通信端末に中継することを要旨とする。
【００７１】
本発明の第８の特徴は、中継装置がサーバ装置からの放送メディアを通信端末に中継する放送通信システムであって、前記サーバ装置が、放送通知情報の送信後に最初に送信するものであるか否かを示す識別情報を前記放送メディアに関連付けて送信し、前記中継装置が、前記識別情報に関連付けられた前記放送メディアを受信した場合に、他の放送メディアを参照することなく再生可能な形式で、該放送メディアを前記通信端末に中継することを要旨とする。
【００７２】
本発明の第９の特徴は、中継装置がサーバ装置からの放送メディアを通信端末に中継する放送通信システムであって、前記サーバ装置が、放送通知情報の送信後に最初に送信するものであるか否かを示す識別情報を前記放送メディアに関連付けて送信し、前記中継装置が、前記識別情報に関連付けられた前記放送メディアを受信した場合に、予測符号化を行うことなく再生可能な形式で、該放送メディアを前記通信端末に中継することを要旨とする。
【００７３】
本発明の第１０の特徴は、サーバ装置から通信端末に放送メディアを送信する放送通信方法であって、前記サーバ装置において、前記サーバ装置において、少なくとも一つの放送メディアを指定する放送通知情報を送信し、前記通信端末による放送メディアの再生に先立って、前記放送通知情報によって指定された前記放送メディアの再生方法を示す再生情報を送信し、前記通信端末において、前記放送通知情報を受信した場合に、前記再生情報に基づいて、該放送通知情報によって指定された前記放送メディアを再生することを要旨とする。
【００７４】
本発明の第１１の特徴は、中継装置がサーバ装置からの放送メディアを通信端末に中継する放送通信方法であって、前記中継装置において、前記サーバ装置によって放送通知情報が送信された後に最初に送信された少なくとも１つの放送メディアを、他の放送メディアを参照することなく再生可能な形式で該放送メディアを前記通信端末に中継することを要旨とする。
【００７５】
本発明の第１２の特徴は、中継装置がサーバ装置からの放送メディアを通信端末に中継する放送通信方法であって、前記サーバ装置において、放送通知情報の送信後に最初に送信するものであるか否かを示す識別情報を前記放送メディアに関連付けて送信し、前記中継装置において、前記識別情報に関連付けられた前記放送メディアを受信した場合に、他の放送メディアを参照することなく再生可能な形式で該放送メディアを前記通信端末に中継することを要旨とする。
【００７６】
本発明の第１３の特徴は、中継装置がサーバ装置からの放送メディアを通信端末に中継する放送通信方法であって、前記サーバ装置において、放送通知情報の送信後に最初に送信するものであるか否かを示す識別情報を前記放送メディアに関連付けて送信し、前記中継装置において、前記識別情報に関連付けられた前記放送メディアを受信した場合に、予測符号化を行うことなく再生可能な形式で該放送メディアを前記通信端末に中継することを要旨とする。
【００７７】
本発明の第１４の特徴は、受信した放送メディアを再生する通信端末を、前記放送メディアの再生に先立って、該放送メディアの再生方法を示す再生情報を取得し、少なくとも一つの前記放送メディアを指定する放送通知情報を受信した場合、前記再生情報に基づいて、指定された該放送メディアを再生するように機能させるためのプログラムであることを要旨とする。
【００７８】
本発明の第１５の特徴は、放送メディアを通信端末に配信するサーバ装置を、少なくとも一つの放送メディアを指定する放送通知情報を送信し、前記通信端末による前記放送メディアの再生に先立って、該放送通知情報によって指定された前記放送メディアの再生方法を示す再生情報を送信するように機能させるプログラムであることを要旨とする。
【００７９】
【発明の実施の形態】
以下、本発明の実施形態について、図１乃至図４４を参照しながら、詳細に説明する。図１は、本発明の実施形態における放送通信システムの概略構成図である。
【００８０】
図１に示すように、本実施形態に係る放送通信システム１は、放送メディアを配信（送信）するコンテンツ送信サーバ１０と、配信（送信）された放送メディアを受信して再生する受信端末２０と、無線制御装置４０及び基地局５０から構成される中継装置３０とを具備する。
【００８１】
本実施形態では、放送メディアとは、例えば、ＲＴＰパケットやＩピクチャフレームやＰピクチャフレーム等を用いたストリーミング形式で送信される音声情報（ＡＭＲ）や映像情報（ＭＰＥＧ-４）等を指すものとする。
【００８２】
以下、受信端末２０として移動通信端末を用いる場合について説明するが、本発明は、移動通信端末以外の端末を用いた場合にも適用可能である。
【００８３】
コンテンツ送信サーバ１０は、インターネット２と中継装置３０と無線チャネルとを介して、放送メディアをストリーミング形式で受信端末２０に配信するサーバ装置である。受信端末２０は、無線チャネルを介して受信した放送メディアを再生する移動通信端末である。中継装置３０は、必要に応じて、伝送路の物理条件に合わせたプロトコル/フォーマット変換を行うものである。
【００８４】
（第１の実施形態）
本発明の第１の実施形態について図１から図１１を用いて説明する。本実施形態では、インターネットプロトコルである「ＲＴＰ/ＵＤＰ/ＩＰ」パケット（放送メディアパケット）の形式で、音声情報や映像情報等を含む放送メディアを伝送する放送通信システム１について説明する。
【００８５】
本実施形態では、受信端末２０は、音声情報や映像情報等の放送メディアの再生に先立って、該放送メディアの再生方法を示す再生情報を取得し、放送通知情報（ＳＡＰメッセージ）を受信した場合に、前記再生情報に基づいて放送メディアを再生する。ここで、放送通知情報（ＳＡＰメッセージ）は、少なくとも一つの放送メディアを指定するものである。
【００８６】
コンテンツ送信サーバ１０は、受信端末２０による放送メディアの再生に先立って、放送通知情報（ＳＡＰメッセージ）によって指定されている放送メディアの再生方法を示す再生情報を送信する。
【００８７】
コンテンツ送信サーバ１０は、放送通知情報（ＳＡＰメッセージ）によって指定される放送メディア（ＡＭＲを含むＲＴＰパケットやＭＰＥＧ４を含むＲＴＰパケット）を送信する前に、放送メディアの再生方法を示す再生情報を送信する。
【００８８】
例えば、コンテンツ送信サーバ１０は、放送通知情報（ＳＡＰメッセージ）を周期的に繰り返し送信して、放送通知情報（ＳＡＰメッセージ）を送信した直後に、カルーセルデータによって再生情報を送信することができる。ここで、カルーセルデータとは、同じデータを繰り返し送信する方式（データカルーセル方式）によって伝送されるデータのことをいう。
【００８９】
ここで、再生情報は、ＳＡＰメッセージの「ｐａｙｌｏａｄ（ペイロード）」内に記述されている「ＳＤＰ情報（図４参照）」や、データカルーセル方式によって送信される「ＳＭＩＬ（Ｓｙｎｃｈｒｏｎｉｚｅｄ ＭｕｌｔｉｍｅｄｉａＩｎｔｅｇｒａｔｉｏｎ Ｌａｎｇｕａｇｅ）（図８参照）」等に含まれている。
【００９０】
また、再生情報は、放送メディアの再生の際に用いられる「レイアウト情報」や、放送メディアの再生の際に用いられる「タイミング情報」を含むことができる。
【００９１】
図２は、本実施形態における放送通信システム１におけるコンテンツ送信サーバ１０と受信端末２０との間のシーケンス図である。
【００９２】
図２に示すように、ステップ２０１において、コンテンツ送信サーバ１０が、放送通知情報である「ＳＡＰメッセージ」を、受信端末２０に送信する。ＳＡＰメッセージの内容については、後述の図３及び図４において詳細に説明する。ここで、ＳＡＰメッセージが通知される「ＩＰアドレス」及び「ポート番号」は、受信端末２０に既知のものとする。
【００９３】
ステップ２０２において、コンテンツ送信サーバ１０が、「ＳＭＩＬ」を含むカルーセルデータを受信端末２０に送信する。また、ステップ２０３において、コンテンツ送信サーバ１０が、ＨＴＭＬ形式のテキスト情報やアンカー情報を含むカルーセルデータを受信端末２０に送信する。
【００９４】
例えば、ＪＰＥＧ等の静止画像情報やＸＭＬ形式の構造化データは、ＵＤＰ上でデータを繰り返し送るデータカルーセル方式にて伝送される（図３５参照）。データカルーセル方式については、後述の図５乃至図７の説明において詳細に説明する。
【００９５】
ステップ２０４乃至２０７において、コンテンツ送信サーバ１０が、音声情報（ＡＭＲ）や映像情報（ＭＰＥＧ-４）を含むＲＴＰパケット（放送メディアパケット）を受信端末２０に送信する。
【００９６】
ここで、ＳＡＰメッセージ及びカルーセルデータは、ＵＤＰ/ＩＰパケットによって伝送され、音声情報及び映像情報は、ＵＤＰ/ＩＰ上のＲＴＰパケットによって伝送される（図３５参照）。
【００９７】
そして、コンテンツ送信サーバ１０は、ＳＡＰメッセージを、所定間隔をもって周期的に繰り返し伝送する。受信端末２０は、ＳＡＰメッセージを受信することにより、放送メディアの再生を開始するので、ＳＡＰメッセージは、できうる限り短い周期にて伝送することが望ましい。
【００９８】
次に、図３及び図４を用いて、ＳＡＰメッセージについて説明する。図３は、ＳＡＰメッセージのフォーマットを示すものである。
【００９９】
図３において、「Ｖ」は、バージョン情報を示す。「Ａ」は、アドレスタイプを示し、Ａ＝０の時、ＩＰｖ４であり、Ａ＝１の時、ＩＰｖ６である。「Ｒ」は、「Ｒｅｓｅｒｖｅｄ」である。
【０１００】
「Ｔ」は、メッセージタイプを示し、Ｔ＝０の時、放送開始を示す放送通知情報であることを意味し、Ｔ＝１の時、放送終了を示す放送通知情報であることを意味する。
【０１０１】
「Ｅ」は、「Ｅｎｃｒｙｐｔｉｏｎ ｂｉｔ」である。「Ｃ」は、「Ｃｏｍｐｒｅｓｓｉｏｎ ｂｉｔ」である。「ａｕｔｈ ｌｅｎ」は、「ｏｐｔｉｏｎａｌ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｄａｔａ」のサイズを示す。
【０１０２】
「ｍｓｇ ｉｄ ｈａｓｈ」は、「ｏｒｉｇｉｎａｔｉｎｇ ｓｏｕｒｃｅ」に記述されたＩＰアドレスで示される発信元（コンテンツ送信サーバ１０等）によって送信されるＳＡＰメッセージを一意に特定するメッセージＩＤである。
【０１０３】
「ｏｒｉｇｉｎａｔｉｎｇ ｓｏｕｒｃｅ」は、ＳＡＰメッセージの発信元のＩＰアドレスである。
【０１０４】
ここで、「ｍｓｇ ｉｄ ｈａｓｈ」と「ｏｒｉｇｉｎａｔｉｎｇ ｓｏｕｒｃｅ」との組み合わせによって、ＳＡＰメッセージを一意に特定することができる。
【０１０５】
「ｏｐｔｉｏｎａｌ ｐａｙｌｏａｄ ｔｙｐｅ」は、「ｐａｙｌｏａｄ」のデータタイプを示す。「ｐａｙｌｏａｄ」については、図４において詳細に説明する。
【０１０６】
図４は、本実施形態におけるＳＡＰメッセージ内の「ｐａｙｌｏａｄ」に記述された「ＳＤＰ情報」の例を示す。
【０１０７】
「ｖ＝０」は、「ｐａｙｌｏａｄ」のバージョンを示すものであり、「ｐａｙｌｏａｄ」を記述するルールを規定するための情報を示している。
【０１０８】
「ｏ＝」は、発信元情報であり、発信元のＩＰアドレス情報（１２６．１６．６４．４）を含む。「ｓ＝」は、放送メディアのセッション名である。「ｃ＝」は、放送メディアを送信しているマルチキャストアドレス（送信先のＩＰアドレス情報）である。「ｔ＝」は、放送メディアの有効期間を示すものである。
【０１０９】
「ｍ＝」は、当該ＳＡＰメッセージによって指定されている放送メディアを示す情報であり、図４に示すＳＡＰメッセージは、放送メディアとして、１つの音声情報と１つの映像情報と１つのカルーセルデータを指定している。
【０１１０】
すなわち、第１の放送メディアを指定する「ｍ＝ａｕｄｉｏ ３４５６ ＲＴＰ/ＡＶＰ ０」という記述は、音声情報を「３４５６」で特定されるポート番号にて、ＲＴＰパケットによって伝送することを示している。
【０１１１】
また、第２の放送メディアを指定する「ｍ＝ｖｉｄｅｏ ２２３２ ＲＴＰ/ＡＶＰ ９８」という記述は、映像情報を「２２３２」で特定されるポート番号にて、ＲＴＰパケットによって伝送することを示している。
【０１１２】
また、「ｍ＝ａｐｐｌｉｃａｔｉｏｎ ３２４１６ ｕｄｐ ｄｃ」という記述は、繰り返し送信するカルーセルデータを、ＵＤＰパケットを用いて伝送することを示している。
【０１１３】
次に、図５乃至図７を用いて、データカルーセル方式にて伝送されるカルーセルデータについて説明を行う。図５は、本実施形態において用いられるデータカルーセル方式を用いたデータ伝送方式の概要を示している。
【０１１４】
カルーセルデータは、「ＤＩＩ（Ｄｏｗｎｌｏａｄ ＩｎｆｏｒｍａｔｉｏｎＩｎｄｉｃａｔｉｏｎ）」を含むカルーセルデータパケットと、１つ以上の「ＤＤＢ（Ｄｏｗｎｌｏａｄ Ｄａｔａ Ｂｌｏｃｋ）」を含むカルーセルデータパケットとによって構成される。
【０１１５】
「ＤＩＩ」は、後続のカルーセルデータパケット（ＤＤＢ）についての情報を含み、「ＤＤＢ」は、実データ（ブロック単位に分割されたモジュール）を含む。「ＤＩＩ」については、後述の図６の説明にて詳細に説明する。
【０１１６】
図５は、「ＤＤＢ」が、ブロック単位に分割された３つのモジュール（「ＳＭＩＬ」と「テキスト情報（テロップ）」と「アンカー情報（ＵＲＬ）」）をそれぞれ含む場合の例を示している。それぞれのモジュール（ファイル）の内容については、後述の図８乃至図１０を参照して詳細に説明する。
【０１１７】
図５に示すように、各モジュールは、それぞれブロック単位に分割される。さらに、ブロック単位に分割されたモジュールに、それぞれ「データカルーセルヘッダ」が付加されて、「カルーセルデータ」を構成する「カルーセルデータパケット」となる。
【０１１８】
図６は、本実施形態のデータカルーセル方式で送信される「ＤＩＩ」の内容について示している。図６に示すように、「ＤＩＩ」は、「データカルーセルヘッダ」と「メッセージ本体データ」と誤り検出のための「ＣＲＣ」とから構成される。
【０１１９】
「データカルーセルヘッダ」は、「メッセージ種別」と、「データカルーセル識別子」と、「セクション番号」と、「最終セクション番号」と、「コンテンツ識別子」と、「有効時間情報」と、「メッセージ本体サイズ」とで構成される。
【０１２０】
「メッセージ種別」は、当該カルーセルデータパケットが、「ＤＩＩ」を含むものか「ＤＤＢ」を含むものかについて示す情報である。
【０１２１】
「データカルーセル識別子」は、当該カルーセルデータを一意に特定する識別情報である。「セクション番号」は、当該カルーセルデータを構成する「カルーセルデータパケット」を一意に特定する識別情報である。
【０１２２】
「最終セクション番号」は、当該カルーセルデータ内のカルーセルデータパケットの数を表す情報である。「コンテンツ識別子」は、当該カルーセルデータパケットの内容（コンテンツ）が更新されるとインクリメントされるバージョン情報である。
【０１２３】
「有効時間情報」は、当該カルーセルデータを構成するカルーセルデータパケットが有効である時間情報を表し、有効時間の開始及び終了を特定する情報によって構成される。本実施形態では、「有効時間情報」として「ＮＴＰタイム」を用いている。なお、有効時間を示す必要の無いときには、明示的に「有効時間情報」を設定しなくても良い。
【０１２４】
「メッセージ本体データ」は、「モジュール数」と、当該モジュール数で示される数分の「モジュール情報１〜Ｎ」とで構成される。
【０１２５】
「モジュール数」とは、意味的にまとまった単位であるモジュールの数を表すものである。図５に示すように、本実施形態に係るモジュールは、「ＳＭＩＬ」や「テキスト情報（テロップ）」や「アンカー情報（ＵＲＬ）」等の１つのファイルに対応するものである。
【０１２６】
「モジュール情報」は、「モジュールＩＤ」と、「モジュールサイズ」と、「モジュールバージョン」と、「モジュールのコンテンツタイプ情報」とで構成される。
【０１２７】
「モジュールＩＤ」は、当該カルーセルデータ内で、モジュールを一意に特定する識別情報である。「モジュールサイズ」は、モジュールのデータサイズである。「モジュールバージョン」は、モジュールの更新情報である。「モジュールのコンテンツタイプ情報」は、モジュールが含むコンテンツタイプ（例えば、平文形式のテキスト情報やＨＴＭＬ形式のテキスト情報等）を示すものである。
【０１２８】
図７は、本実施形態でのデータカルーセル方式で送信される「ＤＤＢ」の内容を示している。図７に示すように、「ＤＤＢ」は、「データカルーセルヘッダ」と「メッセージ本体データ」と誤り検出に使用される「ＣＲＣ」とから構成される。
【０１２９】
「データカルーセルヘッダ」は、図６において説明した「ＤＩＩ」における「データカルーセルヘッダ」と同様に、「メッセージ種別」と、「データカルーセル識別子」と、「セクション番号」と、「最終セクション番号」と、「コンテンツ識別子」と、「有効時間情報」と、「メッセージ本体サイズ」とで構成される。
【０１３０】
「メッセージ本体データ」は、「モジュールＩＤ」と、「モジュールサイズ」と、「ブロック番号」と、「最終ブロック番号」と、「ブロックサイズ」と、「ブロックデータ」とから構成される。
【０１３１】
「モジュールＩＤ」は、当該カルーセルデータ内で、モジュールを一意に特定する識別情報である。「モジュールサイズ」は、モジュールのデータサイズである。「ブロック番号」は、当該モジュールが分割されたブロックを一意に識別する識別子である。「最終ブロック番号」は、当該モジュールが分割されたブロック数を示す。「ブロックサイズ」は、後続のブロックのデータサイズを示す。「ブロックデータ」は、ブロック単位に分割されたモジュールのデータである。
【０１３２】
次に、本実施形態において、データカルーセル方式にて伝送される各モジュール（ファイル）について説明する。
【０１３３】
図８は、本実施形態において、データカルーセル方式にて伝送される「ＳＭＩＬ」の記述例を示す。「ＳＭＩＬ」は、複数の放送メディア間で時間同期処理を行うために用いられる「タイミング情報」や通信端末の表示部における放送メディアの表示を変更するための「レイアウト情報」等の再生情報を含む。「ＳＭＩＬ」は、データカルーセル方式にて伝送されるファイル（モジュール）として位置付けられる。
【０１３４】
図８に示す「ＳＭＩＬ」は、１つの音声情報と１つの映像情報と２つのテキスト情報とが、同期して同時に再生されることを示す。
【０１３５】
「＜ａｕｄｉｏ ｓｒｃ＝“：＜ｐｏｒｔ-ａ０１＞/”/＞」という記述により、ＳＡＰメッセージに示される音声情報用のポートを参照すべき旨が示されている。
【０１３６】
「＜ｖｉｄｅｏ ｓｒｃ＝“：＜ｐｏｒｔ-ｖ０１＞/”ｒｅｇｉｏｎ＝”ａ”/＞」という記述により、ＳＡＰメッセージに示される映像情報用のポートを参照すべき旨が示されている。
【０１３７】
「＜ｔｅｘｔ ｓｒｃ＝“〜/ｍｏｄｕｌｅ０１”ｒｅｇｉｏｎ＝”ｂ”/＞」という記述により、「ＳＭＩＬ」が伝送されるカルーセルデータに含まれる「ｍｏｄｕｌｅ０１」で示されるテキスト情報を参照すべき旨が示されている。
【０１３８】
「＜ｔｅｘｔ ｓｒｃ＝“〜/ｍｏｄｕｌｅ０２“ｒｅｇｉｏｎ＝”ｃ”/＞」という記述により、「ＳＭＩＬ」が伝送されるカルーセルデータに含まれる「ｍｏｄｕｌｅ０２」で示されるテキスト情報を参照すべき旨が示されている。
【０１３９】
また、「＜ｌａｙｏｕｔ＞〜＜/ｌａｙｏｕｔ＞」という記述には、音声情報や映像情報やテキスト情報を、受信端末２０の表示部に表示するレイアウト（表示領域）を指定する「レイアウト情報」が示されている。
【０１４０】
図９は、図８の「ＳＭＩＬ」における「＜ｔｅｘｔ ｓｒｃ＝“〜/ｍｏｄｕｌｅ０１“ｒｅｇｉｏｎ＝”ｂ”/＞」という記述によって参照されるテキスト情報（テロップ）の記述例である。
【０１４１】
図１０は、図８の「ＳＭＩＬ」における「＜ｔｅｘｔ ｓｒｃ＝“〜/ｍｏｄｕｌｅ０２“ｒｅｇｉｏｎ＝”ｃ”/＞」という記述によって参照されるアンカー情報（ＵＲＬ）の記述例である。
【０１４２】
なお、データカルーセル方式は、同一のデータを繰り返し伝送するものであり、各放送メディア間の同期に係るタイミング情報、レイアウト情報、字幕やアップリンクと連携したアンカー情報（ＵＲＬ）、静止画像情報、テキスト情報（テロップ・静止文字）、動画像情報、音声情報等を、繰り返し伝送されるデータとしてファイル化して伝送することが可能である。
【０１４３】
次に、ＳＡＰメッセージを受信する受信端末２０の動作を説明する。具体的には、受信端末２０において、ＳＡＰメッセージを受信した後、受信した放送メディアを再生するまでの動作を説明する。
【０１４４】
第１に、ＳＡＰメッセージを受信した受信端末２０は、ＳＡＰメッセージ（放送通知情報）の受信をきっかけとして放送メディア（ＲＴＰパケット）の受信を開始する。
【０１４５】
第２に、受信端末２０は、ＳＡＰメッセージを参照することにより、音声情報や映像情報やカルーセルデータ等の放送メディアが送信されている「ＩＰアドレス」や、各放送メディアを再生するために必要な「ポート番号」や「ＲＴＰペイロードタイプ」等の再生情報を取得する。
【０１４６】
例えば、図４に示すＳＡＰメッセージを受信した受信端末２０は、「ｃ＝ＩＮＩＰ４ ２２４．２．１７.１２/１２７」という記述により、各放送メディアが送信されている「ＩＰアドレス（マルチキャストアドレス）」を取得する。
【０１４７】
また、受信端末２０は、第１の放送メディアを指定する「ｍ＝ａｕｄｉｏ ３４５６ ＲＴＰ/ＡＶＰ ０」という記述により、音声情報が、ポート番号「３４５６」によってＲＴＰパケットを用いて送信されると解析する。
【０１４８】
また、受信端末２０は、第２の放送メディアを指定する「ｍ＝ｖｉｄｅｏ ２２３２ ＲＴＰ/ＡＶＰ ９８」という記述により、映像情報が、ポート番号「２２３２」によってＲＴＰパケットを用いて送信されると解析する。
【０１４９】
さらに、受信端末２０は、「ｍ＝ａｐｐｌｉｃａｔｉｏｎ ３２４１６ ｕｄｐ ｄｃ」という記述より、ポート番号「３２４１６」によって、ＵＤＰパケット上で、カルーセルデータが送信されると解析する。
【０１５０】
第３に、上述の放送メディアについての解析を行った受信端末２０は、各放送メディアの受信処理の準備を行い、放送メディアが放送されるのを待つ。
【０１５１】
第４に、本実施形態では、ＳＡＰメッセージに引き続き、時間同期情報（タイミング情報）である「ＲＴＣＰ（ＲＴＰ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ）メッセージ」が送信される。
【０１５２】
第５に、ＲＴＣＰメッセージを受信した受信端末２０は、ＲＴＣＰメッセージに含まれる「ＮＴＰタイムスタンプ」と「ＲＴＰタイムスタンプ」との対応情報（ＮＴＰ-ＲＴＰ関連情報）により、各放送メディア間の時間同期情報（タイミング情報）を得る。これにより、音声情報と映像情報の放送メディア間の時間同期情報（タイミング情報）が得られる。
【０１５３】
第６に、複数のブロック単位に分割されたカルーセルデータが送信され、受信端末２０が、当該カルーセルデータを受信すると、当該カルーセルデータの解析を行う。受信端末２０は、複数のブロック単位に分割された全てのカルーセルデータの受信を行う。なお、本実施形態では、カルーセルデータは、音声情報及び映像情報の放送の合間に放送される。
【０１５４】
第７に、受信端末２０は、ＲＴＰパケットにて伝送される音声情報及び映像情報を受信したならば、ＮＴＰタイムスタンプで用いられている時間軸（ＮＴＰタイム）を基準にして、各放送メディア間の同期を取りつつ、ストリーミング形式で再生処理を行う。
【０１５５】
なお、受信端末２０において、カルーセルデータにて放送されるレイアウト情報を受信する前に、すばやく映像情報の再生を行いたい場合は、一旦、あらかじめ決められたレイアウト情報により再生を開始した後、レイアウト情報を受信し、解析の結果により、レイアウトが確定すれば再レイアウトを行えばよい。
【０１５６】
なお、コンテンツ送信サーバ１０は、音声情報及び映像情報の放送の合間にカルーセルデータを放送してもよいし、ＳＡＰメッセージ送信後、音声情報及び映像情報の放送に先立ち、カルーセルデータを放送してもよい。後者の場合、放送メディアを受信する受信端末２０が、音声情報及び映像情報の放送メディアの受信に先立ち、放送メディアの再生に関する制御情報を処理することが可能となる。
【０１５７】
また、音声情報及び映像情報に先立って受信端末２０が受信するカルーセルデータは、カルーセルデータ全体でなくとも良く、放送メディア再生において重要な情報を放送メディア再生に先立ち放送しても良い。ここで、重要な情報とは、映像情報の再生におけるレイアウト情報等である。
【０１５８】
次に、定期的に繰り返し送信されるＳＡＰメッセージを繰り返し受信する受信端末２０での動作を説明する。
【０１５９】
第１に、受信端末２０は、ＳＡＰメッセージに含まれる「ｍｓｇ ｉｄ ｈａｓｈ（メッセージＩＤ）」及び「ｏｒｉｇｉｎａｔｉｎｇ ｓｏｕｒｃｅ」を確認することにより、ＳＡＰメッセージが更新されているか否かを判断する。
【０１６０】
ここで、放送メディアに関して変更があった場合には、ＳＡＰメッセージに含まれる「メッセージＩＤ」が更新される。「メッセージＩＤ」は、同一の「ｏｒｉｇｉｎａｔｉｎｇ ｓｏｕｒｃｅ」から送信されるＳＡＰメッセージを一意に識別する情報である。
【０１６１】
第２に、ＳＡＰメッセージの更新が示されていたならば、ＳＡＰメッセージに含まれる「ｐａｙｌｏａｄ」の確認を行う。
【０１６２】
例えば、音声情報や映像情報を伝送する「ポート番号」や「コーディックタイプ」が変更されたりした場合には、ＳＡＰメッセージに含まれる「メッセージＩＤ」が変更される。
【０１６３】
なお、図２には示していないが、本実施形態では、ＲＴＣＰメッセージを用いて、ＮＴＰタイムとＲＴＰタイムとを関連付ける時間同期情報（タイミング情報）を送っている。
【０１６４】
ここで、受信端末２０において、データカルーセル方式にて送られたデータ（ＨＴＭＬ等）と、ＲＴＰパケットにて送られた映像情報及び音声情報を時間的に関連付ける方法を示す。
【０１６５】
受信端末２０は、各ＲＴＰパケットに対応するＲＴＣＰメッセージより、ＮＴＰタイムとＲＴＰタイムとを関連付けるＮＴＰ-ＲＴＰ関連情報を取得する。
【０１６６】
データカルーセル方式より、カルーセルデータが有効である時間を示す「有効時間情報（ＮＴＰタイムスタンプ）」を取得する。かかる「ＮＴＰタイムスタンプ」には、有効となる時間を示す「開始ＮＴＰタイムスタンプ」及び無効となる時間を示す「終了ＮＴＰタイムスタンプ」とが含まれる。
【０１６７】
第３に、音声情報及び映像情報のＲＴＰパケットを受け取った受信端末２０は、ＲＴＰパケットに含まれるＲＴＰタイムスタンプより、ＮＴＰ-ＲＴＰ関連情報に基づいて、ＮＴＰタイムスタンプで用いられている時間軸（ＮＴＰタイム）と同期させて、該ＲＴＰパケットに含まれる音声情報又は映像情報を再生処理する。
【０１６８】
また、受信端末２０は、音声情報及び映像情報の再生処理において、データカルーセル方式にて受信したカルーセルデータ（テキスト情報等）が有効となる「有効時間情報（ＮＴＰタイムスタンプ）」に応じて当該カルーセルデータを表示する等のデータ処理を行う。
【０１６９】
なお、「終了ＮＴＰタイムスタンプ」は、カルーセルデータが無効となる時間を示す時間情報ではなく、カルーセルデータの有効期間を表す期間情報であっても良い。
【０１７０】
図１１は、本実施形態における受信端末２０での表示イメージ図である。図１１に示すように、映像情報と音声情報の再生処理に合わせて、テキスト情報（テロップや静止文字）やアンカー情報（ＵＲＬ）が同期して表示されている。
【０１７１】
なお、本実施形態では、インターネットとの親和性を考慮して、ＲＴＣＰメッセージにて、ＮＴＰタイムとＲＴＰタイムとを関連付ける「ＮＴＰ-ＲＴＰ関連情報」を通知しているが、ＲＴＣＰメッセージを用いずに、ＳＡＰメッセージ内に「ＮＴＰ-ＲＴＰ関連情報」を含めて通知する等、受信端末２０にて各放送メディア間の同期処理等の時間に関する処理が可能となるのであれば、他の方法を用いても良い。
【０１７２】
例えば、ＳＡＰメッセージに各放送メディア間の時間同期情報（タイミング情報）を含めても良いし、当該時間同期情報（タイミング情報）を「ＳＭＩＬ」に含めても良い。
【０１７３】
（第２の実施形態）
本発明の第２の実施形態では、受信端末２０が、放送メディアの再生に先立って、必ず行うべき必須処理を示す必須処理情報を含む「ＳＡＰメッセージ」を受信する場合の実施例を示す。
【０１７４】
ここで、図４に示す「ｐａｙｌｏａｄ」を有するＳＡＰメッセージの替わりに、図１２に示す「ｐａｙｌｏａｄ」を有するＳＡＰメッセージを受信した場合の受信端末２０の動作を説明する。
【０１７５】
図１２に示す「ｐａｙｌｏａｄ」を有するＳＡＰメッセージには、必須処理情報を示す「ｒｅｑｕｉｒｅ＝ｍｉｄ：３；“ｍｏｄｕｌｅ００”＝“ｈｔｔｐ：//ｄｏｃｏｍｏ.ｎｅ.ｊｐ/ｌａｙｏｕｔ０１.ｓｍｉｌ”」という記述が含まれている。
【０１７６】
この必須処理情報により示される必須処理は、放送メディア識別情報「ｍｉｄ：３」で識別される放送メディアについての処理を行うことが示されており、特に、当該放送メディアについて「ｍｏｄｕｌｅ００」を処理することが示されている。ここで、「ｍｉｄ：３」で識別される放送メディアは、カルーセルデータであり、「ｍｏｄｕｌｅ００」は、「ＳＭＩＬ」である。
【０１７７】
図１３は、必須処理情報を含むＳＡＰメッセージを処理する受信端末２０の構成を示す。
【０１７８】
図１３に示すように、受信端末２０は、放送メディアを受信する受信処理部２１と、必須処理情報処理部２２と、再生処理部２３と、出力部２４とによって構成される。
【０１７９】
ここで、再生処理部２３は、放送メディア同期再生制御部２３ａと、音声情報再生処理部２３ｂと、映像情報再生処理部２３ｃと、テキスト・静止画像情報再生処理部２３ｄとによって構成される。また、出力部２４は、再生された情報を出力するスピーカ２４ａやディスプレイ２４ｂによって構成される。
【０１８０】
必須処理情報処理部２２は、受信処理部２１が受信した放送通知情報（ＳＡＰメッセージ）に必須処理情報が含まれるか否かを判定し、必須処理情報が含まれる場合には、放送メディア同期再生制御部２３ａにおける各放送メディアの再生処理に先立ち、必須処理を行うことを指示する。
【０１８１】
次に、図１４を用いて、図１２に示す必須処理情報を含むＳＡＰメッセージを受信する場合の受信端末２０での処理フローを説明する。
【０１８２】
図１４に示すように、ステップ１４０１において、受信処理部２１が、ＳＡＰメッセージを受信して、放送メディアが放送されるＩＰアドレス情報（マルチキャストアドレス）や時間同期情報（タイミング情報）や各放送メディアの再生情報を取得する。
【０１８３】
ステップ１４０２において、必須処理情報処理部２２が、ＳＡＰメッセージに必須処理情報が含まれているか否かの判定を行う。必須処理情報が含まれている場合、必須処理情報処理部２２が、必須処理情報の解析を行い、解析内容を放送メディア同期再生処理部２３ａに通知して、本フローは、ステップ１４０３に進む。一方、必須処理情報が含まれていない場合、本フローは、ステップ１４０５に進む。
【０１８４】
ステップ１４０３において、放送メディア同期再生処理部２３ａが、通知された必須処理情報に示された必須処理を実行する。そして、放送メディア同期再生処理部２３ａが、各放送メディアを順次受信した時に、必須処理情報及び各放送メディアの再生情報を参照しながら、各再生処理部２３ｂ乃至２３ｄに再生の指示を行う。放送メディア同期再生処理部２３ａは、必須処理情報及び各放送メディアの再生情報を保持しておく。
【０１８５】
ステップ１４０４及び１４０５において、再生指示を受けた再生処理部２３ｂ乃至２３ｄは、放送メディアの再生処理を行う。
【０１８６】
本実施形態における必須処理情報は、ＳＭＩＬの処理を行うことを示すものであり、音声情報や映像情報の各放送メディアの再生しようとする場合に、ＳＭＩＬの処理を既に行っていれば該放送メディアの再生を行い、そうでなければ該放送メディアの再生を開始しない。
【０１８７】
なお、本実施形態では、必須処理が示されるファイル（必須処理情報）を一意に特定するＩＤとして、ＵＲＬ情報である「ｈｔｔｐ：//ｄｏｃｏｍｏ.ｎｅ.ｊｐ/ｌａｙｏｕｔ０１.ｓｍｉｌ」を用いている。このように、ＳＡＰメッセージに必須処理情報を一意に特定するＩＤを含めることにより、必須処理情報が示されているファイル（例えば「ＳＭＩＬ」等）の受信を完了せずとも必須処理を特定することが可能となり、再生をすばやく始めることが可能となる。
【０１８８】
また、上述のＩＤとして、ＵＲＬ情報を用いることにより、事前に必須処理情報を保持していなくとも、ネットワークで接続される他の装置にアクセスすることにより、必須処理情報を取得することが可能となる。ＵＲＬ情報を用いることにより、必須処理情報に限らない任意の処理に対する必要な情報を放送により取得することに限らず、ネットワークで接続される他の装置から必要に応じて取得することを可能とするものである。
【０１８９】
（第３の実施形態）
本発明に係る第３の実施形態では、受信端末２０が、放送メディアの再生に先立って、再生情報としてのレイアウト情報を含むＳＡＰメッセージを受信する場合の実施例を示す。
【０１９０】
図１５は、レイアウト情報を含むＳＡＰメッセージ内の「ＳＤＰ情報」における「ｐａｙｌｏａｄ」の記述例である。
【０１９１】
図１５に示すように、「ｌａｙｏｕｔ＝“ｈｔｔｐ：//ｄｏｃｏｍｏ.ｎｅ.ｊｐ/ｌａｙｏｕｔ０１.ｓｍｉｌ”；ｃｉｄ＝ｄｏｃｏｍｏ０１２３」という記述により、放送メディアの再生の際に用いられるレイアウト情報が一意に特定される。
【０１９２】
図１６は、本実施形態における受信端末２０の構成図である。
【０１９３】
図１６に示すように、受信端末２０は、放送メディアを受信する受信処理部２１と、レイアウト情報判定処理部２５と、再生処理部２３と、出力部２４とによって構成される。
【０１９４】
ここで、再生処理部２３は、放送メディア同期再生制御部２３ａと音声情報再生処理部２３ｂと映像情報再生処理部２３ｃとテキスト・静止画像情報再生処理部２３ｄとによって構成される。また、出力部２４は、再生情報を出力するスピーカ２４ａやディスプレイ２４ｂによって構成される。
【０１９５】
レイアウト情報判定処理部２５は、受信処理部２１が受信した放送通知情報（ＳＡＰメッセージ）にレイアウト情報が含まれるか否かを判定し、レイアウト情報が含まれる場合には、放送メディア同期再生制御部２３ａにその旨を通知する。
【０１９６】
ここで、図１７に示すフローチャートを用いて、図１５で示すレイアウト情報を含むＳＡＰメッセージを受信した時の受信端末２０の動作を説明する。
【０１９７】
図１７に示すように、ステップ１７０１において、ＳＡＰメッセージを受信した受信端末２０の受信処理部２１は、ＳＡＰメッセージであることの判断及び当該ＳＡＰメッセージの解析を行う。ここで、受信処理部２１は、ＳＡＰメッセージより、以降受信する放送メディアのアドレス情報や再生情報を取得する。
【０１９８】
ステップ１７０２において、レイアウト情報判定処理部２５は、受信したＳＡＰメッセージに、放送メディアに係るレイアウト情報のＩＤが含まれているか否かの判定を行う。
【０１９９】
レイアウト情報のＩＤが含まれている場合、ステップ１７０３において、レイアウト情報判定処理部２５は、該ＩＤによって示されるレイアウト情報を既に受信端末２０にて保持しているか否かの判定を行う。
【０２００】
すでに、当該レイアウト情報を保持しているのであれば、ステップ１７０４において、レイアウト情報判定処理部２５は、保持するレイアウト情報を放送メディア同期再生制御部２３ａに通知する。そして、放送メディア同期再生制御部２３ａは、通知されたレイアウト情報に基づきレイアウト処理を行う。
【０２０１】
ステップ１７０５において、各再生処理部２３ｂ乃至２３ｄが、ディスプレイに表示を行う各放送メディアを受信した場合には、既に処理済みのレイアウト情報に基づき再生表示が行われる。
【０２０２】
なお、上述のＩＤによって示されるレイアウト情報を受信端末２０にて保持していない場合、ステップ１７０６において、受信端末２０は、当該レイアウト情報を、後続の放送される情報より取得するか、もしくはネットワークを介して他の装置から取得することが考えられる。
【０２０３】
レイアウト情報のＩＤとして、ＵＲＬ情報を用いることにより、Ｗｅｂで一般的に用いられているＨＴＴＰを用いて容易にデータ取得することが可能である。
【０２０４】
（第４の実施形態）
本発明の第４の実施形態では、図１８及び図１９を用いて、複数の放送メディア間で関連して行われる必須処理を指定する例を示す。
【０２０５】
図１８は、データカルーセル方式にて伝送される「ＳＭＩＬ」を示すものであり、「ｒｅｑｕｉｒｅ＝“ｉｄ：ｖ１”」という記述によって、第２のテキスト情報を表示すると同時に、「ｉｄ＝“ｖ１”」で識別される映像情報を再生表示することを必須処理とすることが示される。
【０２０６】
図１９は、本実施形態での受信端末２０の構成図である。
【０２０７】
受信端末２０は、放送メディアを受信する受信処理部２１と、再生処理部２３と、出力部２４とによって構成される。
【０２０８】
ここで、再生処理部２３は、放送メディア同期再生制御部２３ａと音声情報再生処理部２３ｂと映像情報再生処理部２３ｃとテキスト・静止画像情報再生処理部２３ｄと必要条件判定処理部２３ｅとによって構成される。また、出力部２４は、再生情報を出力するスピーカ２４ａやディスプレイ２４ｂで構成される
必要条件判定処理部２３ｅは、放送メディア同期再生制御部２３ａが、受信処理部２１により受信された「ＳＭＩＬ」に基づいて、各放送メディアの同期再生処理を行う場合に、ある特定の放送メディアの再生と同時に行うべき内容（必須処理）を判定する。本実施形態では、第２のテキスト情報を再生する場合には、同時に必須処理として映像情報の再生が要求されることを判定する。
【０２０９】
すなわち、本実施形態では、図１８に示す「ＳＭＩＬ」の「ｒｅｑｕｉｒｅ＝“ｉｄ：ｖ１”」という記述が、受信端末２０が放送メディアの再生と同時に行うべき処理内容（すなわち、必須処理情報）に該当する。
【０２１０】
（第５の実施の形態）
本実施の形態では、図１、図２０乃至図２２を用いて、ＳＡＰメッセージの伝送と同期して、予測符号化を行わない映像情報パケットである「Ｉピクチャフレーム」を伝送する例を示す。
【０２１１】
図２０は、コンテンツ送信サーバ１０が、受信端末２０に映像情報を放送する動作を示すシーケンス図である。
【０２１２】
図２０に示すように、コンテンツ送信サーバ１０は、放送メディアと当該放送メディアの再生方法を示す再生情報等を有するＳＡＰメッセージとを、受信端末２０に対して繰り返し送信する。受信端末２０は、ＳＡＰメッセージを受信することにより、音声情報や映像情報等の各放送メディアの再生情報を取得することができる。
【０２１３】
映像情報の符号化方法として、前のフレーム画像又は隣接するフレーム画像（他の放送メディア）を参照することにより現在のフレーム画像を再生可能な方法として「予測符号化」が知られている。例えば、「Ｐピクチャフレーム」が、「予測符号化」を用いて符号化されたフレーム画像である。
【０２１４】
一方、「Ｉピクチャフレーム」が、「予測符号化」を行うことなく現在のフレーム画像のみで再生可能な映像情報フレームである。すなわち、「Ｉピクチャフレーム」は、他の放送メディアを参照することなく再生可能なものである。
【０２１５】
つまり、映像情報フレームを復号化するためには、当該映像情報フレームの他の映像情報フレームに対する依存関係を知る必要があり、放送メディアの受信開始直後に受信した放送メディアを必ずしも正しく復号化できるとは限らない。
【０２１６】
例えば、ＭＰＥＧを想定した場合、Ｉピクチャフレームは、当該Ｉピクチャフレームだけで復号化することができるものの、Ｐピクチャフレームは、一つ前の映像情報フレームからの差分情報であるため、当該Ｐピクチャフレームを復号化するには、一つ前の映像情報フレームが正しく復号化されている必要がある。
【０２１７】
したがって、ＳＡＰメッセージを受信した直後にＰピクチャフレームで構成される放送メディアを受信しても、映像情報フレームを直ちに復号化することができず、次にＩピクチャフレームが送信されるまで、受信端末２０は、放送メディアの再生を待たなければならない。
【０２１８】
このような待ち時間を低減するためには、コンテンツ送信サーバ１０は、ＳＡＰメッセージを送信した後、次に送信する映像情報をＩピクチャフレームで構成される放送メディアとする。
【０２１９】
ＳＡＰメッセージを送信した直後の放送メディアを「Ｉピクチャフレーム」で構成する実施例として、コンテンツ送信サーバ１０において、リアルタイムに映像情報を符号化する場合と、予め用意された映像情報に合わせてＳＡＰメッセージを送信する場合の実施例を示す。
【０２２０】
まず、図２１のフローチャートを用いて、コンテンツ送信サーバ１０が、リアルタイムに映像情報を符号化する場合の例を示す。図２１は、コンテンツ送信サーバが、リアルタイムに映像情報フレームの符号化を行う場合の制御例を示す。
【０２２１】
図２１に示すように、ステップ２１０１において、コンテンツ送信サーバ１０は、ＳＡＰメッセージの送信タイミングになると、ＳＡＰメッセージを生成する。
【０２２２】
ステップ２１０２において、コンテンツ送信サーバ１０は、映像情報フレームのフローを「リフレッシュ状態（Ｒｅｆｒｅｓｈ＝１）」にセットする。ステップ２０１３において、コンテンツ送信サーバ１０は、ＳＡＰメッセージを受信端末２０に送信する。
【０２２３】
一方、ステップ２１１１において、コンテンツ送信サーバ１０は、送信すべき映像情報フレームを取得する。ステップ２１１２において、コンテンツ送信サーバ１０は、取得した映像情報フレームが「リフレッシュ状態（Ｒｅｆｒｅｓｈ＝１）」であるか否かを判定する。
【０２２４】
コンテンツ送信サーバ１０は、取得した映像情報フレームが「リフレッシュ状態（Ｒｅｆｒｅｓｈ＝１）」である場合、ステップ２１１３において、当該映像情報フレームを「Ｉピクチャフレーム」に符号化して、映像情報フローを「非リフレッシュ状態（Ｒｅｆｒｅｓｈ＝０）」にセットする。
【０２２５】
一方、コンテンツ送信サーバ１０は、当該映像情報フレームが「非リフレッシュ状態（Ｒｅｆｒｅｓｈ＝０）」である場合、当該映像情報フレームをＰピクチャフレームもしくはＢピクチャフレームに符号化する。
【０２２６】
なお、本実施形態では、ＳＡＰメッセージを用いた例を示したが、本発明は、この場合に限定されず、後述する回線交換放送通信方式において、ＳＡＰメッセージの代わりに、Ｈ．２４５メッセージを用いる場合にも適用することができる。この場合、Ｈ．２４５メッセージを契機として映像情報フレームをＩピクチャフレームに符号化することになる。すなわち、この場合も、放送通知情報（Ｈ．２４５メッセージ）と同期して映像情報フレームをＩピクチャフレームに符号化する。この例、すなわち、コンテンツ送信サーバ１０が、Ｈ．２４５メッセージを送信した後に、Ｉピクチャフレームを送信するシーケンスを、後述の図３４に示す。
【０２２７】
次に、図２２のフローチャートを用いて、予め用意された映像情報（放送メディア）に合わせて、ＳＡＰメッセージを送信する場合の実施例を示す。図２２は、予め映像情報（放送メディア）が符号化されている場合のコンテンツ送信サーバ１０での処理フローを示す。
【０２２８】
図２２に示すように、ステップ２２０１において、コンテンツ送信サーバ１０は、コンテンツファイルから次に送信しようとする映像情報フレームを検索する。ステップ２２０２において、コンテンツ送信サーバ１０は、検索した次に送信しようとする映像情報フレームが、Ｉピクチャフレームか、それ以外かを判別する。
【０２２９】
当該映像情報フレームがＩピクチャフレームでなければ、ステップ２２０３において、コンテンツ送信サーバ１０は、当該映像情報フレームをそのまま送信する。
【０２３０】
一方、当該映像情報フレームがＩピクチャフレームの場合には、ステップ２２０４において、コンテンツ送信サーバ１０は、当該映像情報フレームの送信前にＳＡＰメッセージを生成する。コンテンツ送信サーバ１０は、ステップ２２０５において、ＳＡＰメッセージ送信後、ステップ２２０３において、Ｉピクチャフレームの映像情報フレームを送信する。
【０２３１】
このような制御により、ＳＡＰメッセージの送信頻度を必要最低限に抑えることができるとともに、受信端末２０は、ＳＡＰメッセージ受信後、直ちに映像情報フレームの復号化を開始することができ無駄がない。
【０２３２】
なお、本実施形態では、ＳＡＰメッセージでの例を示したが、本発明は、この例に限定されず、回線交換放送通信方式の場合には、ＳＡＰメッセージの代わりに、Ｈ．２４５メッセージを用いてもよい。この場合、Ｈ．２４５メッセージが、Ｉピクチャフレームの送信直前に生成され送信されることになる。
【０２３３】
なお、本実施形態では、コンテンツ送信サーバ１０において、ＳＡＰメッセージと映像情報フレームのＩピクチャフレームとを同期させる方法を示したが、中継装置３０にてこれらを同期させる処理を行っても良い。
【０２３４】
（第６の実施形態）
本発明の第６の実施形態では、パケット型放送通信方式において、「ＲＴＰ/ＵＤＰ/ＩＰ」パケットのヘッダ圧縮を行う例を、図１、図２３乃至図２６を用いて説明する。図２３は、コンテンツ送信サーバ１０が、繰り返し送信されるＳＡＰメッセージとヘッダ圧縮パケットとを、中継装置３０を介して受信端末２０に送信する動作を示すシーケンス図である。
【０２３５】
本実施形態におけるパケット型放送通信方式において、音声情報及び映像情報等の放送メディアは、ＲＴＰパケットとして伝送される。ＲＴＰパケットには、ヘッダとして「ＲＴＰ/ＵＤＰ/ＩＰヘッダ」が付加されることになり、そのオーバーヘッドが非常に大きい。
【０２３６】
本実施形態においては、図２３に示すように、コンテンツ送信サーバ１０と中継装置３０の間では、ＲＴＰ/ＵＤＰ/ＩＰヘッダについて圧縮することなしに伝送している。
【０２３７】
中継装置３０は、コンテンツ送信サーバ１０から受信したＲＴＰパケットが、ＳＡＰメッセージを中継した直後のＲＴＰパケット（図２３におけるステップ２３０１及び２３０２で送信されるＲＴＰパケット）の場合、ヘッダ圧縮リフレッシュパケットとして当該ＲＴＰパケットを受信端末２０に送信する。一方、中継装置３０は、コンテンツ送信サーバ１０から受信したＲＴＰパケットが、その他のＲＴＰパケットである場合、ヘッダ圧縮パケットとして当該ＲＴＰパケットを送信する。
【０２３８】
すなわち、図２３において、中継装置３０は、放送通知情報（ＳＡＰメッセージ）を、コンテンツ送信サーバ１０から受信した後に最初に受信した少なくとも１つの放送メディア（ステップ２３０１及び２３０２で送信されるＲＴＰパケット）を、他の放送メディアを参照することなく再生可能な形式で（ヘッダ圧縮リフレッシュパケットとして）、受信端末２０に中継する。
【０２３９】
このことにより、パケット型放送通信方式において、中継装置３０と受信端末２０との間にヘッダ圧縮処理を適用した場合、放送メディアの放送の途中から視聴を開始した受信端末２０は、ＳＡＰメッセージを受信した直後に伝送されるＲＴＰパケットがヘッダ圧縮パケットであるため、ヘッダ圧縮状態を把握することができず、当該ＲＴＰパケットを復元することができないという問題点を解消することができる。
【０２４０】
なお、ここでは、ＲＴＰパケット（ＲＴＰ/ＵＤＰ/ＩＰヘッダ）についてヘッダ圧縮する場合を説明したが、ＵＤＰパケット（ＵＤＰ／ＩＰヘッダ）やＩＰパケット（ＩＰヘッダ）についてヘッダ圧縮を行っても良い。
【０２４１】
次に、図２４を用いて、図２３に示す中継装置３０におけるヘッダ圧縮処理の具体例を示す。図２４は、中継装置３０におけるヘッダ圧縮処理を示すフローチャートである。
【０２４２】
図２４に示すように、中継装置３０が、ステップ２４０１において、コンテンツ送信サーバ１０からパケットを受信し、ステップ２４０２において、次に送信するパケットがＳＡＰメッセージかどうかを検査する。
【０２４３】
中継装置３０は、当該パケットがＳＡＰメッセージの場合には、ステップ２４０３において、全てのＲＴＰパケットのフローｎを「リフレッシュ状態（Ｒｅｆｒｅｓｈ＿ｎ＝１）」にセットし、ステップ２４０４において、ＳＡＰメッセージをそのままの状態で受信端末２０送信する。
【０２４４】
一方、中継装置３０は、当該パケットがＳＡＰメッセージでない場合には、ステップ２４０５において、当該パケットがＲＴＰパケットか否かを検査する。中継装置３０は、当該パケットがＲＴＰパケットでなければ、ステップ２４０６において、そのままの状態で当該パケットを受信端末２０に送信する。
【０２４５】
一方、中継装置３０は、当該パケットがＲＴＰパケットである場合には、ステップ２４０７において、当該ＲＴＰパケットの「ＩＰアドレス」、「ポート番号」及び「ＲＴＰのＳＳＲＣ識別子」から、当該ＲＴＰパケットがどのフローに当たるのか判断する。本実施形態では、当該ＲＴＰパケットが「フローｉ」と判定されたとする。
【０２４６】
ステップ２４０８において、中継装置３０は、フローｉが「リフレッシュ状態（Ｒｅｆｒｅｓｈ＿ｉ＝１）」であるかどうかを検査する。フローｉが「リフレッシュ状態（Ｒｅｆｒｅｓｈ＿ｉ＝１）」であれば、中継装置３０は、ステップ２４０９において、当該ＲＴＰパケットをヘッダ圧縮リフレッシュパケットに変換するとともに、フローｉを「非リフレッシュ状態（Ｒｅｆｒｅｓｈ＿ｉ＝０）」にセットする。そして、ステップ２４１０において、中継装置３０は、当該ヘッダ圧縮リフレッシュパケットを受信端末２０に送信する。
【０２４７】
一方、フローｉが「非リフレッシュ状態（Ｒｅｆｒｅｓｈ＿ｉ＝０）」であれば、中継装置３０は、ステップ２４１１において、当該ＲＴＰパケットをヘッダ圧縮パケットに変換して、ステップ２４１２において、受信端末２０に送信する。
【０２４８】
なお、本実施形態では、ＲＴＰパケット（ＲＴＰ/ＵＤＰ/ＩＰヘッダ）についてヘッダ圧縮を行う場合を説明したが、本発明は、この場合に限定されるものではなく、ＵＤＰパケット（ＵＤＰ/ＩＰヘッダ）やＩＰパケット（ＩＰヘッダ）についてヘッダ圧縮を行う場合にも適用される。
【０２４９】
次に、図２５及び図２６を用いて、コンテンツ送信サーバ１０と中継装置３０とが連携したヘッダ圧縮方法を説明する。
【０２５０】
図２５は、コンテンツ送信サーバ１０でのヘッダ圧縮に関する情報を付加する動作を示すフローチャートである。
【０２５１】
図２５に示すように、コンテンツ送信サーバ１０は、ステップ２５０１において、ＳＡＰメッセージを生成し、ステップ２５０２において、全てのパケットのフローｎを「リフレッシュ状態（Ｒｅｆｒｅｓｈ＿ｎ＝１）」にセットし、ステップ２５０３において、当該ＳＡＰメッセージを中継装置３０に送信する。
【０２５２】
また、コンテンツ送信サーバ１０は、ステップ２５１１において、フローｉのＲＴＰパケットを生成し、ステップ２５１２において、当該フローｉが「リフレッシュ状態（Ｒｅｆｒｅｓｈ＿ｎ＝１）」であるか否かについて判定する。
【０２５３】
コンテンツ送信サーバ１０は、当該フローｉが「リフレッシュ状態（Ｒｅｆｒｅｓｈ＿ｉ＝１）」である場合、ステップ２５１３において、当該ＲＴＰパケットのＩＰヘッダ内の「ＴＯＳ（Ｔｙｐｅ ｏｆ Ｓｅｒｖｉｃｅ）フィールド」を「０ｘＦＦ」に変更するとともに、当該フローｉを「非リフレッシュ状態（Ｒｅｆｒｅｓｈ＿ｉ＝０）」に設定し、ステップ２５１４において、「ＴＯＳフィールド」が「０ｘＦＦ」に設定されたＲＴＰパケットを中継装置３０に送信する。
【０２５４】
一方、コンテンツ送信サーバ１０は、当該フローｉが「非リフレッシュ状態（Ｒｅｆｒｅｓｈ＿ｉ＝０）」である場合、「ＴＯＳフィールド」はそのままで、ステップ２５１４において、当該ＲＴＰパケットを中継装置３０に送信する。
【０２５５】
図２６は、無線制御装置４０及び基地局５０からなる中継装置３０における、図２５において説明したコンテンツ送信サーバ１０から受信したパケット処理に関する動作を示すフローチャートである。
【０２５６】
図２６に示すように、中継装置３０は、ステップ２６０１において、コンテンツ送信サーバ１０からＲＴＰパケットを受信し、ステップ２６０２において、当該ＲＴＰパケットの「ＴＯＳフィールド」が「０ｘＦＦ」であるか否かについて検査する。
【０２５７】
中継装置３０は、当該ＲＴＰパケットの「ＴＯＳフィールド」が「０ｘＦＦ」である場合、ステップ２６０３において、当該ＲＴＰパケットをヘッダ圧縮リフレッシュパケットに変換して、ステップ２６０４において、受信端末２０に送信する。
【０２５８】
一方、中継装置３０は、当該ＲＴＰパケットの「ＴＯＳフィールド」が「０ｘＦＦ」でない場合、ステップ２６０５において、当該ＲＴＰパケットをヘッダ圧縮パケットに変換して、ステップ２６０６において、受信端末２０に送信する。
【０２５９】
すなわち、図２５及び図２６において、コンテンツ送信サーバ１０は、放送通知情報（ＳＡＰメッセージ）の送信後に最初に送信する放送メディア（ＲＴＰパケットとその旨を示す識別情報（ヘッダ圧縮に関する情報）とを関連付けて送信する（すなわち、ＲＴＰパケットの「ＴＯＳフィールド」を「０ｘＦＦ」に設定して送信する）。
【０２６０】
また、中継装置３０は、放送通知情報（ＳＡＰメッセージ）の送信後に最初に送信するものである旨を示す識別情報に関連付けられた放送メディア（「ＴＯＳフィールド」が「０ｘＦＦ」に設定されたＲＴＰパケット）を受信した場合に、放送メディア（ＲＴＰパケット）を、他の放送メディアを参照することなく再生可能な形式で（ヘッダ圧縮リフレッシュパケットとして）、受信端末２０に中継する。
【０２６１】
この結果、ＳＡＰメッセージの直後のＲＴＰパケットがヘッダ圧縮リフレッシュパケットとして送信され、受信端末２０は当該ＲＴＰパケットを正しく復元することが可能となる。
【０２６２】
なお、本実施形態では、ＲＴＰパケット（ＲＴＰ/ＵＤＰ/ＩＰヘッダ）についてヘッダ圧縮する場合を説明したが、本発明は、これに限定されるものではなく、ＵＤＰパケット（ＵＤＰ/ＩＰヘッダ）やＩＰパケット（ＩＰヘッダ）についてヘッダ圧縮を行う場合に適用することもできる。
【０２６３】
なお、コンテンツ送信サーバ１０で変更するフィールド（すなわち、中継装置３０で検査するフィールド）は、「ＴＯＳフィールド」以外に、ＩＰヘッダ内の「ＩＤフィールド」やＲＴＰヘッダ内の「ＲＴＰマーカービット」などでもよい。すなわち、コンテンツ送信サーバ１０及び中継装置３０の間で取り決めた共通認識される情報であれば良い。また、「ＴＯＳフィールド」において変更される値は「０ｘＦＦ」以外でもよい。
【０２６４】
なお、「ＴＯＳフィールド」の優先度を利用する方法としては、優先度によりデータカルーセル方式にて伝送するデータの繰り返し送出回数を制御し、優先度の高いデータカルーセル方式のデータは、他のデータよりも送出回数を多くするということが可能である。このことにより、重要なデータをより確実に受信端末２０に通知することが可能となる。
【０２６５】
（第７の実施形態）
本発明の第７の実施形態では、コンテンツ送信サーバ１０が、複数の無線チャネルを介して放送メディアをストリーミング配信する場合の例を、図２７乃至図２９を参照して説明する。
【０２６６】
図２７の例では、コンテンツ送信サーバ１０が、ＳＡＰメッセージ用チャネルを介してＳＡＰメッセージ（ＳＡＰ１、ＳＡＰ２）を伝送し、番組１用チャネルを介して第１の放送メディア（ＲＴＰ１-ａ、ＲＴＰ１-ｂ）を伝送し、番組２用チャネルを介して第２の放送メディア（ＲＴＰ２-ａ、ＲＴＰ２-ｂ）を伝送している。すなわち、図２７の例では、コンテンツ送信サーバ１０は、番組毎に異なる無線チャネルを使用している。
【０２６７】
この場合、コンテンツ送信サーバ１０は、ＳＡＰメッセージにおいて放送メディア（番組）のＩＰアドレス（論理チャネル識別情報）だけ指定したのでは不十分であり、どの無線チャネルにどの放送メディアが流れているかについても特定する必要がある。そこで、コンテンツ送信サーバ１０は、ＳＡＰメッセージ内のＳＤＰ情報の中で、無線チャネルを特定する情報（物理チャネル識別情報）を通知する。
【０２６８】
例えば、コンテンツ送信サーバ１０は、図２８に示すように、ＳＤＰの「ｃフィールド」の中で「ｃ＝Ｃｈａｎｎｅｌ ＡＢＣＤＥ」というように無線チャネルを特定する情報を通知する。無線チャネルを特定する情報としては、ＣＤＭＡ通信方式のチャネライゼーションコードや周波数値等が考えられる。
【０２６９】
受信端末２０は、この無線チャネルを特定する情報に基づいて、放送メディアの流れている無線チャネルを特定し、当該放送メディアを視聴することが可能となる。
【０２７０】
すなわち、本実施形態では、放送通知情報（ＳＡＰメッセージ）内のＳＤＰ情報に、放送メディアが送信される物理チャネル識別情報（ＣＤＭＡ通信方式のチャネライゼーションコードや周波数値等の無線チャネルを特定する情報）と論理チャネル識別情報（放送メディアのＩＰアドレス）との対応情報とが含まれている。
【０２７１】
なお、本実施形態では、各放送メディアに係るＳＡＰメッセージ（ＳＡＰ１，ＳＡＰ２）をＳＡＰメッセージ用チャネルを介して放送する例を示したが、図２９に示すように、各無線チャネルに対応するＳＡＰメッセージ（ＳＡＰ１，ＳＡＰ２）は、各番組用チャネルを介して放送し、共通チャネル（ＳＡＰメッセージ用チャネル）には、各放送メディアのＩＰアドレス（マルチキャストアドレス）と無線チャネルを特定する情報とを関連付ける情報（ＳＡＰ０）を放送するようにしても良い。
【０２７２】
（第８の実施形態）
本発明の第８の実施形態では、Ｈ.２２３多重化フレーム方式を用いて放送メディアを放送する実施例を、図５乃至図９、図３０乃至図３３を用いて示す。以後、Ｈ.２２３多重化フレーム方式を回線放送通信方式と呼ぶ。図３０は、回線放送通信方式での放送通信シーケンス概略図である。ここで、コンテンツ送信サーバ１０は、Ｈ.２２３多重化フレームのレベルと、受信端末２０の受信能力及び多重分離能力と、受信端末２０が「Ｓｌａｖｅ端末」であることを知っているものとする。
【０２７３】
図３０に示すように、ステップ３００１において、受信端末２０は、放送通知情報である「Ｈ.２４５メッセージ」を受信することにより、「放送メディアの論理チャネル情報（論理チャネルパラメータ）」及び「Ｈ.２２３多重化テーブル」を検出する。
【０２７４】
その後、中継装置３０は、音声情報、映像情報及びカルーセルデータを、Ｈ.２４５メッセージで記述されたＨ.２２３多重化フレームに従って伝送する。
【０２７５】
図３１は、回線放送通信方式におけるＨ.２２３多重化フレームの送信例である。図３１に示すように、Ｈ．２４５メッセージは、論理チャネルパラメータ３１０１及びＨ.２２３多重化テーブル３１０２を含んでいる。
【０２７６】
本実施形態において、論理チャネルパラメータ３１０１は、第１の論理チャネル（ＬＣＮ１）でカルーセルデータが伝送され、第２の論理チャネル（ＬＣＮ２）で音声情報（ＡＭＲ）が伝送され、第３の論理チャネル（ＬＣＮ３）で映像情報（ＭＰＥＧ-４）が伝送され、第４の論理チャネル（ＬＣＮ４）でメディア同期情報が伝送されることを示している。
【０２７７】
図３１に示すＨ.２２３多重化テーブル３１０２の記述｛ＬＣＮ０，ＡＬＬ｝によれば、Ｈ.２２３多重化フレーム０（Ｅｎｔｒｙ０）は、全て論理チャネルＬＣＮ０によって構成されている。
【０２７８】
図３１に示すＨ.２２３多重化テーブル３１０２の記述｛ＬＣＮ４，１ｂｙｔ｝｛ＬＣＮ１，ＡＬＬ｝によれば、Ｈ.２２３多重化フレーム１（Ｅｎｔｒｙ１）は、１バイトが第４の論理チャネルＬＣＮ４によって構成されており、残りが第１の論理チャネルＬＣＮ１によって構成されている。
【０２７９】
図３１に示すＨ.２２３多重化テーブル３１０２の記述｛ＬＣＮ４，１ｂｙｔ｝｛ＬＣＮ２，３１ｂｙｔｅ｝｛ＬＣＮ１、ＡＬＬ｝によれば、Ｈ.２２３多重化フレーム２（Ｅｎｔｒｙ２）は、１バイトが第４の論理チャネルＬＣＮ４によって構成されており、３１バイトが第２の論理チャネルＬＣＮ２によって構成されており、残りが第１の論理チャネルＬＣＮ１によって構成されている。
【０２８０】
以下、Ｈ.２２３多重化フレーム３（Ｅｎｔｒｙ３）等の構成についても同様に理解できる。
【０２８１】
図３１に示すＨ.２２３多重化フレームの例では、最初に、Ｈ.２４５メッセージ（ＭＣ＝０）が伝送され、その後、メディア同期情報（ＬＣＮ４）及びカルーセルデータ（ＬＣＮ１）が多重化されたＨ.２２３多重化フレーム１（Ｅｎｔｒｙ１）が伝送されることを示している。
【０２８２】
図３２は、受信端末２０において、上述のＨ.２２３多重化フレームによって伝送されるカルーセルデータと、音声情報及び映像情報とを同期処理する動作を示すフローチャートである。
【０２８３】
図３２に示すように、ステップ３２０１において、受信端末２０は、Ｈ.２２３多重化フレームによって受信したカルーセルデータと、当該Ｈ.２２３多重化フレームに含まれるメディア同期情報（ｓｙｎｃ１）とを関連付けて記憶する。
【０２８４】
受信端末２０は、ステップ３２０２において、Ｈ.２２３多重化フレームによって音声情報若しくは映像情報を受信し、ステップ３２０３において、当該Ｈ.２２３多重化フレームに含まれるメディア同期情報（ｓｙｎｃ２）を検出する。
【０２８５】
受信端末２０は、ステップ３２０４において、カルーセルデータを受信した時に記憶していたメディア同期情報（ｓｙｎｃ１）と当該メディア同期情報（ｓｙｎｃ２）が一致するか否かについて判定する。
【０２８６】
受信端末２０は、「ｓｙｎｃ１」と「ｓｙｎｃ２」とが一致する場合、ステップ３２０５において、「ｓｙｎｃ１」に関連付けられたカルーセルデータを、有効であると判断し、音声情報若しくは映像情報の再生と同期して処理される。
【０２８７】
受信端末２０は、「ｓｙｎｃ１」と「ｓｙｎｃ２」とが一致しない場合、ステップ３２０６において、「ｓｙｎｃ１」に関連付けられたカルーセルデータを無効と判断する。
【０２８８】
ここで、カルーセルデータは、図５乃至図７で示したカルーセルデータの仕様と同じものである。また、カルーセルデータ内のテキスト情報やアンカー情報等については、それぞれ図９及び図１０で示したものと同様とする。
【０２８９】
図３３は、本実施形態における「ＳＭＩＬ」の記述例である。本実施形態に係る「ＳＭＩＬ」は、１つの音声情報と、１つの映像情報と、２つのテキスト情報と、レイアウト情報と、時間同期情報（タイミング情報）とを示している。
【０２９０】
ここで、「ＬＣＮ２」は、第２の論理チャネルＬＣＮ２を表し、図３１で説明したように、音声情報である。「ＬＣＮ３」は、第３の論理チャネルＬＣＮ３を表し、図３１で説明したように、映像情報である。「〜/ｍｏｄｕｌｅ０１」は、第１の論理チャネル（ＬＣＮ１）内で特定されるモジュール（モジュール０１）を示している。ここで、モジュール０１は、テキスト情報（テロップ）である。「〜/ｍｏｄｕｌｅ０２」は、第１の論理チャネル（ＬＣＮ１）内で特定されるモジュール（モジュール０２）を示している。ここで、モジュール０２は、アンカー情報（ＵＲＬ）である。
【０２９１】
なお、図３３に示される「ＳＭＩＬ」は、第１の論理チャネル（ＬＣＮ１）内の特定モジュール（モジュール００）である。第１の論理チャネル（ＬＣＮ１）は、図３１で説明したように、カルーセルデータである。
【０２９２】
本実施形態によれば、伝送されるＨ.２２３多重化フレームに抜けが生じた場合、データカルーセル方式にて伝送されるデータ（カルーセルデータ）と、音声情報及び映像情報との意図しない同期再生処理が行われることが無くなる。
【０２９３】
本実施形態において、上述のように、コンテンツ送信サーバ１０は、放送通知情報であるＨ.２４５メッセージを周期的に繰り返し送信し、カルーセルデータをＨ.２４５メッセージの送信後に繰り返し送信する。
【０２９４】
また、コンテンツ送信サーバ１０は、Ｈ.２４５メッセージの論理チャネルパラメータ及びＨ.２２３多重化テーブルや、カルーセルデータである「ＳＭＩＬ」によって、放送メディアの再生方法を示す再生情報を送信する。
【０２９５】
（第９の実施形態）
本発明の第９の実施形態では、放送通知情報としてＨ.２４５メッセージを送出した後の映像情報メッセージをＩピクチャフレームとする例を示す。本実施形態は、上述の第５の実施形態で示した「ＳＡＰメッセージ」を「Ｈ．２４５メッセージ」に変更して、回線放送通信方式に適用したものである。
【０２９６】
図３４は、コンテンツ送信サーバ１０が、データ（Ｈ.２４５メッセージ及び映像情報）を放送する動作を示すシーケンス図である。
【０２９７】
回線放送通信方式において、コンテンツ送信サーバ１０は、Ｈ．２４５メッセージを繰り返し送信する。受信端末２０は、Ｈ．２４５メッセージを受信することにより初めて音声情報や映像情報等の放送メディアを受信できるようになる。
【０２９８】
ここで、放送メディアが映像情報の場合、受信端末２０は、映像情報フレームを復号化する際、映像情報フレーム間の依存関係を必要とするため、放送メディアを受信開始直後に、必ずしも正しく映像情報フレームを復号化できるとは限らない。
【０２９９】
例えば、ＭＰＥＧ符号化を想定した場合、Ｉピクチャフレームは、それだけで復号化することができるものの、Ｐピクチャフレームは、一つ前の映像情報フレームからの差分情報であるため、一つ前の映像情報フレームが正しく復号化されている必要がある。したがって、受信端末２０は、Ｈ.２４５メッセージを受信した直後にＰピクチャフレームで構成される放送メディアを受信しても、当該映像情報を直ちに復号化することができず、次にＩピクチャフレームが送信されるまで待たなければならない。
【０３００】
このような待ち時間を低減するために、コンテンツ送信サーバ１０は、Ｈ.２４５メッセージを送信した後、次に送信する映像情報パケットを、必ずＩピクチャフレームで構成される映像情報とする。
【０３０１】
リアルタイム符号化の場合、コンテンツ送信サーバ１０は、Ｈ.２４５メッセージの送信を検出したときに、その直後に符号化する映像情報フレームをＩピクチャフレームに変換する。
【０３０２】
一方、予め映像情報が生成されている場合、コンテンツ送信サーバ１０は、映像情報の符号化におけるＩピクチャフレームの出現周期を、Ｈ.２４５メッセージの繰り返し周期と等しくして符号化する。この結果、受信端末２０は、Ｈ.２４５メッセージを受信した直後の映像情報としてＩピクチャフレームを受信し、復号化することが可能となるため、映像情報が表示されるまでの待ち時間を短縮することができる。
【０３０３】
（第１０の実施形態）
本発明の第１０の実施形態では、図１、図８、図３３、図３５乃至図３８を参照して、コンテンツ送信サーバ１０から受信端末２０へ放送メディアを送信する場合に、放送メディアを中継する中継装置３０において、伝送プロトコル変換を行う例を示す。
【０３０４】
具体的には、中継装置３０は、コンテンツ送信サーバ１０からＩＰパケットによって送信された放送メディアを、Ｈ.２２３多重化フレーム方式に基づく回線放送通信用プロトコルで送信可能な放送メディアへ変換し、受信端末２０へ送信する例を示す。
【０３０５】
図３５は、本実施形態におけるコンテンツ送信サーバ１０と中継装置３０との間におけるＩＰパケット型放送通信方式のプロトコルスタックを示す構成図である。
【０３０６】
音声情報（Ｓｐｅｅｃｈ ｃｏｄｉｎｇ、Ａｕｄｉｏ ｃｏｄｉｎｇ）３５０２、３５０３及び映像情報（Ｖｉｄｅｏ ｃｏｄｉｎｇ）３５０１の放送メディアは、ストリーミング形式の「ＲＴＰ（３５１０）/ＵＤＰ（３５１１）/ＩＰ（３５１２）パケット」によって伝送される。
【０３０７】
カルーセルデータ３５０４は、「ＵＤＰ（３５１１）/ＩＰ（３５１２）パケット」によって伝送される。カルーセルデータ３５０４によって伝送されるデータは、静止画像情報（Ｉｍａｇｅ ｃｏｄｉｎｇ）３５０５やテキスト情報（Ｔｅｘｔ ｄｅｓｃｒｉｐｔｉｏｎ）３５０６やレイアウト情報及び時間同期情報（Ｌａｙｏｕｔ ＆ Ｓｙｎｃ ｄｅｓｃｒｉｐｔｉｏｎ）３５０８が含まれる。放送通知情報（Ｓｅｓｓｉｏｎ Ａｎｎｏｕｎｃｅｍｅｎｔ）３５０９を通知するＳＡＰメッセージ３５０７は、「ＵＤＰ（３５１１）/ＩＰ（３５１２）パケット」によって伝送される。
【０３０８】
図３６は、本実施形態における中継装置３０と受信端末２０との間における回線放送通信方式のプロトコルスタックを示す構成図である。
【０３０９】
各放送メディアは、Ｈ.２２３多重化フレーム３６１４により伝送される。音声情報３６０２、３６０３及び映像情報３６０１は、Ｈ.２２３多重化フレーム上のＡＬ２（３６１１）により伝送される。
【０３１０】
カルーセルデータ（３６０４）は、Ｈ.２２３多重化フレーム上のＡＬ１（３６１２）により伝送される。カルーセルデータ３６０４によって伝送されるデータは、静止画像情報（Ｉｍａｇｅ ｃｏｄｉｎｇ）３６０６やテキスト情報（Ｔｅｘｔ ｄｅｓｃｒｉｐｔｉｏｎ）３６０５やレイアウト情報及び時間同期情報（Ｌａｙｏｕｔ ＆ Ｓｙｎｃ ｄｅｓｃｒｉｐｔｉｏｎ）３６０９が含まれる。放送メディアや伝送方式に関する放送通知情報（Ｓｅｓｓｉｏｎ Ａｎｎｏｕｎｃｅｍｅｎｔ）３６０７は、ＡＬ２（３６１３）上のＨ.２４５メッセージ３６０８により伝送される。なお、Ｈ.２４５メッセージは、論理チャネル０（ＬＣＮ＝０）に含まれる。
【０３１１】
図３７を参照して、本実施形態における中継装置３０が、パケット型放送通信方式から回線放送通信方式へのプロトコル変換を行う動作仕様を説明する。
【０３１２】
図３７に示すように、中継装置３０は、ステップ３７０１において、コンテンツ送信サーバ１からパケットを受信し、ステップ３７０２において、受信したパケットがＳＡＰメッセージであるか否かについて判定する。
【０３１３】
中継装置３０は、受信したパケットがＳＡＰメッセージである場合、ステップ３７０３において、ＳＡＰメッセージ内の放送に関する記述（ＳＤＰ情報）に基づいて、論理チャネルパラメータ及び多重化テーブルを作成し、ステップ３７０４において、Ｈ.２４５メッセージを生成して、受信端末２０に送信する。
【０３１４】
また、中継装置３０は、受信したパケットがＳＡＰメッセージでない場合、ステップ３７０５において、受信したパケットがＲＴＣＰメッセージであるか否かについて判定する。
【０３１５】
中継装置３０は、受信したパケットがＲＴＣＰメッセージである場合、ステップ３７０６において、当該ＲＴＣＰメッセージに含まれるＮＴＰタイムスタンプとＲＴＰタイムスタンプとを関係付ける情報を取得して記憶する。
【０３１６】
また、中継装置３０は、受信したパケットがＲＴＣＰメッセージでない場合、ステップ３７０７において、受信したパケットがカルーセルデータであるか否かについて判定する。
【０３１７】
中継装置３０は、受信したパケットがカルーセルデータである場合、ステップ３７０８において、Ｈ.２２３多重化フレームにおけるＡＬ１（図３６の３６１２）により当該カルーセルデータを受信端末２０に送信する。
【０３１８】
さらに、中継装置３０は、受信したパケットがカルーセルデータでない場合、ステップ３７０９において、受信したパケットがＲＴＰパケットであると判断し、ステップ３７１０において、ＲＴＣＰメッセージ受信時に関連付けられたＲＴＰタイムスタンプとＮＴＰタイムスタンプとの対応関係に基づいて、ＲＴＰパケットにて受信した各放送メディアにＮＴＰタイムスタンプをマッピングする。
【０３１９】
ステップ３７１１において、中継装置３０は、ＮＴＰタイムスタンプとそのＮＴＰタイムスタンプに対応する音声情報又は映像情報を、Ｈ.２２３多重化フレームの同一フレーム内にて送信する。
【０３２０】
図３８は、第１の実施形態にて示した放送メディアを中継装置３０が受信した場合に生成される論理チャネルパラメータとＨ.２２３多重化テーブルとＨ.２２３多重化フレームの一例を示すものである。
【０３２１】
図４に示すＳＡＰメッセージを受信した中継装置３０は、伝送される各放送メディアに係る情報を取得し、論理チャネルパラメータ及びＨ.２２３多重化テーブルを作成し、受信端末２０にＨ．２４５メッセージを送信する。中継装置３０は、カルーセルデータを受信した場合、Ｈ.２２３多重化フレーム１（ＭＣ＝１）にて当該カルーセルデータを受信端末２０へ送信する。
【０３２２】
なお、本実施形態において、図５乃至図８に示すカルーセルデータの構成に変更点はない。ただし、「ＳＭＩＬ」が変更された場合のデータサイズの変更などは起こりうる。
【０３２３】
また、本実施形態では、図８に示す「ＳＭＩＬ」が、図３３に示す「ＳＭＩＬ」に変換されている。すなわち、音声情報に対応するＲＴＰメッセージを受信するための「ポート番号：３４５６」が「論理チャネル：ＬＣＮ２」に変更され、映像情報に対応するＲＴＰメッセージを受信するための「ポート番号：２２３２」が「論理チャネル：ＬＣＮ３」に変更される。
【０３２４】
その後、音声情報及び映像情報を含むＲＴＰパケットを受信した中継装置３０は、ＮＴＰタイムスタンプを基準として、Ｈ.２２３多重化フレーム２（ＭＣ＝２）によって当該ＲＴＰパケットを受信端末２０へ送信する。ここで、メディア同期情報は、ＮＴＰタイムスタンプとしている。
【０３２５】
なお、カルーセルデータ方式で送信されるデータを中継装置３０は、無線区間の電波状況や重み付け係数等によって、当該データの繰り返し送信回数を変更することができる。
【０３２６】
また、中継装置３０は、Ｈ.２４５メッセージの繰り返し周期を短くするために、受信した１つのＳＡＰメッセージに対して複数のＨ.２４５メッセージを生成し、受信端末２０に繰り返し送信することも可能である。逆に、受信したＳＡＰメッセージに変更点がなければ、送信すべきＨ.２４５メッセージを間引くことも可能である。
【０３２７】
（第１１の実施形態）
本発明の第１１の実施形態は、図１、図３９及び図４０を参照して説明する。本実施形態では、中継装置３０が、コンテンツ送信サーバ１０からＩＰパケットにて送信されたデータを、回線交換型プロトコルで送信可能なデータに変換して受信端末２０へ放送する場合に、複数の放送メディアに対応する複数のＳＡＰメッセージを伝送する。
【０３２８】
本実施形態を実現する第１の方法は、中継装置３０が、ＳＡＰメッセージを無線チャネル（物理チャネル）にそれぞれ割り当てることによって、複数の無線チャネルによって複数の放送メディアを放送するものである。第１の方法は、複数の物理チャネルが存在する場合に採用可能な方法である。
【０３２９】
本実施形態を実現する第２の方法は、１つの無線チャネル（物理チャネル）によって複数の放送メディアを放送するものである。
【０３３０】
図３９は、第１０の実施形態で示した放送メディアの放送が行われている場合に、別の放送メディアの放送を同時に行う場合の中継装置の動作を示すフローチャート図である。ここで、図３８に示す放送メディアの放送は、既に行われているものとする。
【０３３１】
図３９に示すように、ステップ３８０１において、中継装置３０は、コンテンツ送信サーバ１０より、現在放送されている第１の放送メディアに係る第１のＳＡＰメッセージとは別であると識別できる第２のＳＡＰメッセージを受け取る。
【０３３２】
中継装置３０は、ステップ３８０２において、第２のＳＡＰメッセージの内容を取得して、既に記憶している第１のＳＡＰメッセージの内容とあわせて記憶し、論理チャネルパラメータの更新と、Ｈ.２２３多重化テーブルの更新を行う。
【０３３３】
ステップ３８０３において、中継装置３０は、新たなＨ.２４５メッセージを生成し、受信端末２０に送信する。
【０３３４】
図４０に、更新されたＨ．２４５メッセージの論理チャネルパラメータと、Ｈ.２２３多重化テーブルと、受信端末２０に伝送されるＨ.２２３多重化フレームとを示す。
【０３３５】
論理チャネルパラメータは、図３８で示される第１の放送メディアに関する情報（ＬＣＮ１乃至ＬＣＮ４参照）に第２の放送メディアに関する情報（ＬＣＮ５乃至ＬＣＮ８参照）が追加されている。また、Ｈ.２２３多重化テーブルについても、第１の放送メディアに関する情報に第２の放送メディアに関する情報が追加されている。
【０３３６】
なお、図３８及び図４０では、ＭＣ＝１，ＭＣ＝２，ＭＣ＝３，ＭＣ＝４の順でＨ.２２３多重化フレームを送信する例を示しているが、この順番で送信しなければならないことはない。また、コンテンツ送信サーバ１０は、複数存在しても良い。
【０３３７】
（第１２の実施形態）
本発明の第１２の実施形態について、図４１乃至４３を参照して説明する。本実施形態に係る放送通信システムは、放送通知情報（ＳＡＰメッセージ）に含まれる「メディア識別情報（ｍｉｄ）」を用いて放送メディアの同期再生を可能とするものである。
【０３３８】
図４１は、ＳＡＰメッセージ内の「ｐａｙｌｏａｄ」内容の一例である。ここで、放送メディア（音声情報や映像情報や「ＳＭＩＬ」や静止画像情報やテキスト情報）のそれぞれに対して、メディア識別情報（ｍｉｄ）が指定されている。
【０３３９】
図４１の例では、音声情報（ｍ＝ａｕｄｉｏ）は、「ａ＝ｍｉｄ：１」という記述によって指定されており、映像情報（ｍ＝ｖｉｄｅｏ）は、「ａ＝ｍｉｄ：２」という記述によって指定されている。
【０３４０】
また、「ＳＭＩＬ」は、「ａ＝ｍｉｄ：３」によって指定される放送メディアとして伝送される。ここで、「ａ＝ｒｔｐｍａｐ：１００ Ｘ-ｄｃ/８０００」という記述は、コーデックタイプが「Ｘ-ｄｃ」で、カルーセルデータであることを示し、クロック周波数が「８０００」であることを示す。また、「ａ＝ｆｍｔｐ」の行によって、「ｃｏｎｔｅｎｔ-ｔｙｐｅ」がＭＩＭＥ形式で「ＳＭＩＬ」であることが示されている。
【０３４１】
同様に、「ａ＝ｍｉｄ：４」によって指定される放送メディアとして静止画像情報（ＪＰＥＧ）が伝送され、「ａ＝ｍｉｄ：５」によって指定される放送メディアとしてテキスト情報（ＨＴＭＬ）が伝送されることが示されている。
【０３４２】
図４２は、本実施形態に係る放送通信システムで使用される「ＳＭＩＬ」の一例を示すものである。ここで、「ａｕｄｉｏ ｓｒｃ＝“ｍｉｄ＝１”」という記述によって、当該「ＳＭＩＬ」は、ＳＡＰメッセージ内の「ｍｉｄ：１」によって指定される放送メディア（図４１の例では、音声情報）とリンクする。
【０３４３】
同様に、当該「ＳＭＩＬ」は、映像情報（ｍｉｄ：２）や静止画像情報（ｍｉｄ：４）やテキスト情報（ｍｉｄ：５）にそれぞれリンクする。
【０３４４】
以上のように、本実施形態では、「ＳＭＩＬ」において、放送メディアの参照は、ＳＡＰメッセージ内のメディア識別情報「ｍｉｄ」によって行われている。この結果、放送メディアの再生情報を、ＳＡＰメッセージから取得することが可能となる。
【０３４５】
図４３は、「ｍｉｄ：５」によって指定されるテキスト情報（ＨＴＭＬ）内に含まれるリンク情報の一例を示すものである。ここで、「＜ａ ｈｒｅｆ＝”ｂｃ-ｌｉｎｋ：// <<ＵＳＥＲ＿ＮＡＭＥ>>；<<ＳＥＳＳＩＯＮ＿ＩＤ>>/”＞」という記述は、放送通知情報（ＳＡＰメッセージ）内の「ｏフィールド」で示される「ユーザ名（図４１の例では“ＤｏＣｏＭｏ”）」と「セッションＩＤ」とに対応する放送通知情報（ＳＡＰメッセージ）を指定している。
【０３４６】
ユーザが、上述のユーザ名とセッションＩＤとを指定した場合、当該ユーザの受信端末１０が、当該ユーザ名とセッションＩＤとによって指定されるＳＡＰメッセージに対応する放送メディアを再生する。
【０３４７】
図４３に示す「＜ａ ｈｒｅｆ＝”ｂｃ-ｌｉｎｋ：// <<ＵＳＥＲ＿ＮＡＭＥ>>；<<ＳＥＳＳＩＯＮ＿ＩＤ>>/”＞」という記述によって、図４１に示すＳＡＰメッセージが一意に特定され、当該ＳＡＰメッセージに対応する放送メディアが指定される。
【０３４８】
本実施形態に係る放送通信システムによれば、放送通知情報（ＳＡＰメッセージ）を指定することが可能となり、他の放送メディアの放送への切り替えを行うこと（他の放送メディアによる番組コンテンツにジャンプすること）が可能となる。
【０３４９】
（その他）
また、本明細書に記載された全ての実施形態において、コンテンツ送信サーバ１０と中継装置３０は、別の構成として説明したが、中継装置３０がコンテンツ送信サーバ１０の機能を併せ持っても良い。
【０３５０】
また、コンピュータ４１０１に、本明細書に記載されたコンテンツ送信サーバ１０、受信端末２０、中継装置３０の機能を実行させるためのプログラムを、コンピュータ読み取り可能な記録媒体に記録することができる。このコンピュータ読み取り可能な記録媒体は、図４４に示すように、例えば、フロッピィーディスク４１０２、コンパクトディスク４１０３、ＩＣチップ４１０４、カセットテープ４１０５等が挙げられる。また、上述のコンピュータ４１０１には、デスクトップ型ＰＣの他、ノート型ＰＣや携帯情報端末等も含まれる。
【０３５１】
【発明の効果】
本発明によれば、受信端末２０が、放送メディアの再生方法を示す再生情報（ＳＡＰメッセージ内のＳＤＰ情報やデータカルーセル方式で送信されるＳＭＩＬの記述）に基づいて放送メディア（音声情報や映像情報等）を再生するため、放送メディアの提供者が意図する再生方法に従って、任意の放送メディアを素早く再生することが可能となる。
【０３５２】
また、本発明によれば、再生情報としてレイアウト情報を送信することによって、放送メディアの提供者は、受信端末２０のディスプレイにおける放送メディアの表示を自由に変更することが可能となる。
【０３５３】
また、本発明によれば、放送メディアの提供者は、放送メディアの再生についてのタイミング制御、例えば、映像情報とテキスト情報との時間同期処理等を行うことが可能となる。
【０３５４】
また、事前に取得した再生情報（予め保持しているもの等）を用いることによって、受信端末２０は、再生情報（ＳＭＩＬ）を、全て無線チャネルを介して受信する前に放送メディアを再生することが可能となる。
【０３５５】
また、本発明によれば、受信端末２０において、放送メディアの放送に用いる物理チャネル（無線チャネル）と、論理アドレスであるＩＰアドレスとを対応付けることが可能となる。
【０３５６】
また、本発明によれば、コンテンツ送信サーバ１０が、再生情報の代わりに参照情報を送信するため、放送メディアの提供者が意図する再生方法を受信端末２０に送信することが可能となると共に、送信するデータ量を削減することも可能となる。
【０３５７】
また、本発明によれば、繰り返し送信される放送通知情報（ＳＡＰメッセージ又はＨ.２４５メッセージ）と再生情報（又は参照情報）によって、放送メディアの放送の途中から視聴を始めた受信端末２０であっても、放送メディアを素早く再生することが可能となる。
【０３５８】
また、本発明によれば、カルーセルデータ内の情報が変わろうともＳＡＰメッセージ（又はＨ.２４５メッセージ）は変わることがなく、放送メディアの送信を継続することが可能となる。
【０３５９】
また、本発明によれば、受信端末２０は、放送通知情報（ＳＡＰメッセージ又はＨ.２４５メッセージ）の直後に受信した第１の放送メディア（ＲＴＰパケットや映像情報フレーム）について、他の放送メディア（映像情報フレーム）を参照することなく再生可能であるため、第１の放送メディアの受信後、他の放送メディアの受信を待つまでもなく、直ちに第１の放送メディアを再生することが可能となる。
【０３６０】
また、本発明によれば、基本的に、ヘッダ圧縮処理を行った放送メディア（再生するために他の放送メディアを参照することが必要な放送メディア）を受信端末２０に中継するため、オーバーヘッドを削減することが可能となる。
【０３６１】
また、本発明によれば、放送通知情報（ＳＡＰメッセージ又はＨ.２４５メッセージ）を受信した後に最初に受信した少なくとも１つの放送メディアを、他の放送メディアを参照することなく再生可能な放送メディア（ヘッダ圧縮リフレッシュパケット）とするため、放送メディアの放送の途中から視聴を始めた受信端末２０であっても、当該放送メディアを素早く再生することを可能となる。
【０３６２】
また、本発明によれば、中継装置３０は、放送通知情報（ＳＡＰメッセージ又はＨ.２４５メッセージ）の送信後に最初に送信するものである旨を示す識別情報に関連付けられた（「ＴＯＣフィールド」が「０ｘＦＦ」と設定された）放送メディアを、他の放送メディアを参照することなく再生可能な放送メディア（ヘッダ圧縮リフレッシュパケット）とするため、放送メディアの放送の途中から視聴を始めた受信端末２０であっても、放送メディアを再生することを可能となる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る放送通信システムの概略構成図である。
【図２】本発明の一実施形態に係る放送通信方式のシーケンス図である。
【図３】本発明の一実施形態に係る放送通信システムで用いられるＳＡＰメッセージを示す図である。
【図４】本発明の一実施形態に係る放送通信システムで用いられるＳＡＰメッセージ内のＳＤＰ情報を示す図である。
【図５】本発明の一実施形態に係る放送通信システムで用いられるデータカルーセル方式を用いたデータ伝送方式を説明するための図である。
【図６】本発明の一実施形態に係る放送通信システムで用いられるカルーセルデータパケット（ＤＩＩ）を示す図である。
【図７】本発明の一実施形態に係る放送通信システムで用いられるカルーセルデータパケット（ＤＤＢ）を示す図である。
【図８】本発明の一実施形態に係る放送通信システムで用いられるＳＭＩＬを示す図である。
【図９】本発明の一実施形態に係る放送通信システムで用いられるテキスト情報の記述例を示す図である。
【図１０】本発明の一実施形態に係る放送通信システムで用いられるアンカー情報の記述例を示す図である。
【図１１】本発明の一実施形態に係る通信端末における放送メディアの表示イメージを示す図である。
【図１２】本発明の一実施形態に係る放送通信システムで用いられるＳＡＰメッセージ内のＳＤＰを示す図である。
【図１３】本発明の一実施形態に係る移動通信端末の機能ブロック図である。
【図１４】本発明の一実施形態に係る移動通信端末の動作を示すフローチャート図である。
【図１５】本発明の一実施形態に係る放送通信システムで用いられるＳＡＰメッセージ内のＳＤＰを示す図である。
【図１６】本発明の一実施形態に係る通信端末の機能ブロック図である。
【図１７】本発明の一実施形態に係る通信端末の動作を示すフローチャート図である。
【図１８】本発明の一実施形態に係る放送通信システムで用いられるＳＭＩＬを示す図である。
【図１９】本発明の一実施形態に係る通信端末の機能ブロック図である。
【図２０】本発明の一実施形態に係る放送通信方式のシーケンス図である。
【図２１】本発明の一実施形態に係るサーバ装置の動作を示すフローチャート図である。
【図２２】本発明の一実施形態に係るサーバ装置の動作を示すフローチャート図である。
【図２３】本発明の一実施形態に係る放送通信方式のシーケンス図である。
【図２４】本発明の一実施形態に係る中継装置の動作を示すフローチャート図である。
【図２５】本発明の一実施形態に係るサーバ装置の動作を示すフローチャート図である。
【図２６】本発明の一実施形態に係る中継装置の動作を示すフローチャート図である。
【図２７】本発明の一実施形態に係る放送通信システムにおいて、複数の放送メディアを伝送する様子を示す図である。
【図２８】本発明の一実施形態に係る放送通信システムで用いられるＳＡＰメッセージ内のＳＤＰを示す図である。
【図２９】本発明の一実施形態に係る放送通信システムにおいて、複数の放送メディアを伝送する様子を示す図である。
【図３０】本発明の一実施形態に係る放送通信方式のシーケンス図である。
【図３１】本発明の一実施形態に係る放送通信システムで用いられるＨ.２２３多重化フレームの構成を示す図である。
【図３２】本発明の一実施形態に係る通信端末の動作を示すフローチャート図である。
【図３３】本発明の一実施形態に係る放送通信システムで用いられるＳＭＩＬを示す図である。
【図３４】本発明の一実施形態に係る放送通信方式のシーケンス図である。
【図３５】本発明の一実施形態に係る放送通信方式で用いられるプロトコルスタックを示す図である。
【図３６】本発明の一実施形態に係る放送通信方式で用いられるプロトコルスタックを示す図である。
【図３７】本発明の一実施形態に係る中継装置の動作を示すフローチャート図である。
【図３８】本発明の一実施形態に係る放送通信システムで用いられるＨ.２２３多重化フレームの構成を示す図である。
【図３９】本発明の一実施形態に係る中継装置の動作を示すフローチャート図である。
【図４０】本発明の一実施形態に係る放送通信システムで用いられるＨ.２２３多重化フレームの構成を示す図である。
【図４１】本発明の一実施形態に係る放送通信システムで用いられるＳＡＰメッセージ内のＳＤＰを示す図である。
【図４２】本発明の一実施形態に係る放送通信システムで用いられるＳＭＩＬを示す図である。
【図４３】本発明の一実施形態に係る放送通信システムで用いられるテキスト情報（ＨＴＭＬ）の記述例を示す図である。
【図４４】本発明の一実施形態に係るサーバ装置、中継装置、移動通信端末の機能を実行するためのプログラムを記録するコンピュータ読み取り可能な記録媒体を示す図である。
【図４５】従来技術に係る放送通信システムにおいて、複数の放送メディアを伝送する様子を示す図である。
【図４６】従来技術に係る放送通信システムで用いられるＳＡＰメッセージ内のＳＤＰを示す図である。
【符号の説明】
１…放送通信システム
２…インターネット
１０…コンテンツ送信サーバ
２０…受信端末
２１…受信処理部
２２…必須処理情報処理部
２３…再生処理部
２３ａ…放送メディア同期再生処理部
２３ｂ…音声情報再生処理部
２３ｃ…映像情報再生処理部
２３ｄ…テキスト・静止画像情報再生処理部
２３ｅ…必要条件判定処理部
２４…出力部
２４ａ…スピーカ
２４ｂ…ディスプレイ
２５…レイアウト情報判定処理部
３０…中継装置
４０…無線制御装置
５０…基地局

Claims (13)

1. サーバ装置から中継装置を介してパケット形式で受信した放送メディアを再生する通信端末であって、
   少なくとも一つの放送メディアを指定する放送通知情報を前記サーバ装置から前記中継装置を介して受信する受信部と、
   前記放送通知情報を受信した場合に、前記放送通知情報によって指定された前記放送メディアを再生する再生部とを備え、
   前記受信部は、前記放送通知情報の直後の所定パケットを、他のパケットを参照せずに再生可能な形式のヘッダ圧縮リフレッシュパケットとして受信し、前記放送通知情報の直後の所定パケット以外のパケットを他のパケットの参照によって再生可能な形式のヘッダ圧縮パケットとして受信し、
   前記再生部は、前記ヘッダ圧縮リフレッシュパケットを他のパケットを参照せずに再生し、前記ヘッダ圧縮パケットを他のパケットの参照によって再生し、
   前記ヘッダ圧縮リフレッシュパケット及び前記ヘッダ圧縮パケットは、前記中継装置がパケットのヘッダを圧縮する工程で生成されることを特徴とする通信端末。
2. 前記放送メディアは、無線チャネルを介して送信されており、
   前記放送通知情報は、前記放送メディアが送信される物理チャネル識別情報と論理チャネル識別情報との対応情報を含むことを特徴とする請求項１に記載の通信端末。
3. 通信端末に対して中継装置を介して放送メディアをパケット形式で送信するサーバ装置であって、
   少なくとも一つの放送メディアを指定する放送通知情報を前記中継装置を介して前記通信端末に送信する送信部を備え、
   前記送信部は、前記放送通知情報の直後の所定パケットを他のパケットを参照せずに再生可能な形式のヘッダ圧縮リフレッシュパケットとして送信すべきことを示す情報を前記中継装置に送信し、前記放送通知情報の直後の所定パケット以外のパケットを他のパケットの参照によって再生可能な形式のヘッダ圧縮パケットとして送信すべきことを示す情報を前記中継装置に送信し、
   前記ヘッダ圧縮リフレッシュパケット及び前記ヘッダ圧縮パケットは、前記中継装置がパケットのヘッダを圧縮する工程で生成されることを特徴とするサーバ装置。
4. 前記放送メディアは、無線チャネルを介して送信されており、
   前記放送通知情報は、前記放送メディアが送信される物理チャネル識別情報と論理チャネル識別情報との対応情報を含むことを特徴とする請求項３に記載のサーバ装置。
5. 前記送信部は、前記放送通知情報の直後の所定パケットと前記放送通知情報の直後の所定パケットであることを示す識別情報とを関連付けて送信することを特徴とする請求項３に記載のサーバ装置。
6. サーバ装置から中継装置を介して通信端末に放送メディアをパケット形式で送信する放送通信システムであって、
   前記サーバ装置は、少なくとも一つの放送メディアを指定する放送通知情報を前記中継装置を介して前記通信端末に送信し、
   前記通信端末は、前記放送通知情報を受信した場合に、前記放送通知情報によって指定された前記放送メディアを再生し、
   前記通信端末は、前記放送通知情報の直後の所定パケットを他のパケットを参照せずに再生可能な形式のヘッダ圧縮リフレッシュパケットとして受信し、前記放送通知情報の直後の所定パケット以外のパケットを他のパケットの参照によって再生可能な形式のヘッダ圧縮パケットとして受信し、
   前記通信端末は、前記ヘッダ圧縮リフレッシュパケットを他のパケットを参照せずに再生し、前記ヘッダ圧縮パケットを他のパケットの参照によって再生し、
   前記ヘッダ圧縮リフレッシュパケット及び前記ヘッダ圧縮パケットは、前記中継装置がパケットのヘッダを圧縮する工程で生成されることを特徴とする放送通信システム。
7. 前記放送メディアは、無線チャネルを介して送信されており、
   前記放送通知情報は、前記放送メディアが送信される物理チャネル識別情報と論理チャネル識別情報との対応情報を含むことを特徴とする請求項６に記載の放送通信システム。
8. サーバ装置から中継装置を介して通信端末に放送メディアをパケット形式で送信する放送通信方法であって、
   前記サーバ装置が、少なくとも一つの放送メディアを指定する放送通知情報を前記中継装置を介して前記通信端末に送信し、
   前記通信端末が、前記放送通知情報を受信した場合に、前記放送通知情報によって指定された前記放送メディアを再生し、
   前記通信端末が、前記放送通知情報の直後の所定パケットを他のパケットを参照せずに再生可能な形式のヘッダ圧縮リフレッシュパケットとして受信し、前記放送通知情報の直後の所定パケット以外のパケットを他のパケットの参照によって再生可能な形式のヘッダ圧縮パケットとして受信し、
   前記通信端末が、前記ヘッダ圧縮リフレッシュパケットを他のパケットを参照せずに再生し、前記ヘッダ圧縮パケットを他のパケットの参照によって再生し、
   前記ヘッダ圧縮リフレッシュパケット及び前記ヘッダ圧縮パケットは、前記中継装置がパケットのヘッダを圧縮する工程で生成されることを特徴とする放送通信方法。
9. 前記放送メディアは、無線チャネルを介して送信されており、
   前記放送通知情報は、前記放送メディアが送信される物理チャネル識別情報と論理チャネル識別情報との対応情報を含むことを特徴とする請求項８に記載の放送通信方法。
10. サーバ装置から中継装置を介してパケット形式で受信した放送メディアを再生する通信端末に用いられるプログラムであって、コンピュータに、
    少なくとも一つの放送メディアを指定する放送通知情報を前記サーバ装置から前記中継装置を介して受信するステップＡと、
    前記放送通知情報の直後の所定パケットを他のパケットを参照せずに再生可能な形式のヘッダ圧縮リフレッシュパケットとして受信するステップＢと、
    前記放送通知情報の直後の所定パケット以外のパケットを他のパケットの参照によって再生可能な形式のヘッダ圧縮パケットとして受信するステップＣと、
    前記放送通知情報を受信した場合に、前記放送通知情報によって指定された前記放送メディアを再生するステップＤとを実行させ、
    前記ステップＤでは、前記ヘッダ圧縮リフレッシュパケットを他のパケットを参照せずに再生し、前記ヘッダ圧縮パケットを他のパケットの参照によって再生し、
    前記ヘッダ圧縮リフレッシュパケット及び前記ヘッダ圧縮パケットは、前記中継装置がパケットのヘッダを圧縮する工程で生成されることを特徴とするプログラム。
11. 前記放送メディアは、無線チャネルを介して送信されており、
    前記放送通知情報は、前記放送メディアが送信される物理チャネル識別情報と論理チャネル識別情報との対応情報を含むことを特徴とする請求項１０に記載のプログラム。
12. 通信端末に対して中継装置を介して放送メディアをパケット形式で送信するサーバ装置に用いられるプログラムであって、コンピュータに、
    少なくとも一つの放送メディアを指定する放送通知情報を前記中継装置を介して前記通信端末に送信するステップＡと、
    前記放送通知情報の直後の所定パケットを他のパケットを参照せずに再生可能な形式のヘッダ圧縮リフレッシュパケットとして送信すべきことを示す情報を前記中継装置に送信するステップＢと、
    前記放送通知情報の直後の所定パケット以外のパケットを他のパケットの参照によって再生可能な形式のヘッダ圧縮パケットとして送信すべきことを示す情報を前記中継装置に送信するステップＣとを実行させ、
    前記ヘッダ圧縮リフレッシュパケット及び前記ヘッダ圧縮パケットは、前記中継装置がパケットのヘッダを圧縮する工程で生成されることを特徴とするプログラム。
13. 前記放送通知情報の直後の所定パケットと前記放送通知情報の直後の所定パケットであることを示す識別情報とを関連付けて送信するステップＧをコンピュータに実行させることを特徴とする請求項１２に記載のプログラム。

Images