(57)【要約】  通信システムにおけるＮ個以上のデータストリームを送信する方法を提供する。上記方法は、データストリームをデータペイロードに分け、データペイロードにＮ個のデータストリームを区別するためのＩＤ情報を含むヘッダを付加してソースパケットを生成するステップと、ソースパケットで構成されたＦＥＣソースパケットフローを決定するステップと、ソースパケットブロックを区別するステップと、ソースパケットブロックからソースシンボルブロックを生成するステップと、生成されたソースシンボルブロックにＦＥＣ符号を適用してリペアシンボルブロックを生成するステップと、リペアフローを識別するためのリペアフローＩＤを決定するステップと、リペアシンボルにリペアフローＩＤ及びＦＥＣリペアペイロードＩＤを含むヘッダを付加してＦＥＣリペアパケットを生成するステップと、ソースパケット及びＦＥＣリペアパケットを送信するステップとを有する。
2016535507.tif 000002
【特許請求の範囲】
【請求項１】
通信システムにおけるデータストリームのためのパケットを送信する方法であって、
前記それぞれのデータストリームを所定のサイズのデータペイロードに分け、前記それぞれのデータストリームから分けられたそれぞれのデータペイロードにＮ（前記Ｎは、１以上の整数）個以上のそれぞれのデータストリームを区別するためのＩＤ情報（パケットＩＤ）を含むヘッダを付加することにより、前記Ｎ個のデータストリームのためのソースパケットフローを構成するソースパケットを生成するステップと、
前記ソースパケットフローでＮ個のデータストリームのうちでＮ−Ｍ（ここで、Ｍは、整数であり、１≦Ｍ＜Ｎ）個のデータストリームから生成されたソースパケットで構成されたＦＥＣソースパケットフローを決定するステップと、
前記決定されたＦＥＣソースパケットフローで所定数のソースパケットで構成された少なくとも１つのソースパケットブロックを区別するステップと、
前記区別された少なくとも１つのソースパケットブロックからソースシンボルブロックを生成するステップと、
前記生成されたソースシンボルブロックにＦＥＣ符号を適用することにより少なくとも１つ以上のリペアシンボルで構成されたリペアシンボルブロックを生成するステップと、
前記ＦＥＣソースパケットフローからＦＥＣ符号を適用することにより生成されたリペアシンボルで構成されたリペアフローを識別するためのリペアフローＩＤを決定するステップと、
前記リペアフローのそれぞれのリペアシンボルに前記リペアフローＩＤ及びＦＥＣリペアペイロードＩＤを含むヘッダを付加することによりＦＥＣリペアパケットを生成するステップと、
前記ソースパケット及びＦＥＣリペアパケットを送信するステップと
を有することを特徴とするパケット送信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムにおけるパケット送受信方法及び装置に関する。
【背景技術】
【０００２】
通信システムにおける様々なコンテンツの増加及び高解像度（High Definition：ＨＤ）コンテンツ及び超高解像度（Ultra High Definition：ＵＨＤ）コンテンツのような高容量コンテンツの増加の結果として、ネットワークトラフィックと関連したデータ輻輳（data Congestion）は、さらに悪化している。結果的に、送信器（Sender）（例えば、ホストＡ）により送信されたコンテンツは、受信器（Receiver）（例えば、ホストＢ）に正常に配信されず、コンテンツの一部は、経路上で損失される状況が発生する場合がある。
【０００３】
一般的に、データは、パケット単位で送信される。このように、コンテンツ損失は、パケット単位で発生する場合がある。このパケットは、送信しようとするデータの１つのブロック（ペイロード）とアドレス情報（例えば、発信地アドレス及び宛先アドレス）と管理情報（例えば、ヘッダ）とから構成される。したがって、受信器は、ネットワーク上でデータの損失によりパケットを受信することができないので、損失されたパケット内のデータ及び管理情報がわからない。したがって、オーディオの品質劣化、ビデオの画質劣化、画面クラック、字幕欠落、ファイル損失などのような様々な形態でユーザの不便さをもたらす。
【０００４】
このような理由で、ネットワーク上で発生し得るデータ損失を復旧するための方法でアプリケーションレイヤーフォワードエラー訂正（Application Layer Forward Error Correction：ＡＬ−ＦＥＣ）が必要であり、このために、ＦＥＣパケットを構成し送受信する方法が要求される。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の目的は、少なくとも上述した問題点及び／又は不都合に取り組み、少なくとも以下の利便性を提供することにある。すなわち、本発明の目的は、パケット基盤通信方式をサポートする通信システムにおいて１つ以上のエラー訂正符号を使用して生成されたリペアパケットをデータパケットとともに送信することによりネットワークの信頼度を向上させるＡＬ−ＦＥＣ運用のためのパケットを構成して送受信する方法及び装置を提供することにある。
【０００６】
本発明の他の目的は、ＦＥＣ符号化の後にデータパケット（ソースパケット）の修正なしにパケット保護方法及び装置とペイロード保護方法及び装置とを提供することにある。
【０００７】
本発明のまた他の目的は、ＦＥＣ符号化の後にデータパケット（ソースパケット）に個別のＳＳ＿ＩＤ（Source Symbol ID）を付加するパケット保護（又はペイロード保護）と並行して使用する場合にこのためのシグナリング方法を提供することにある。
【課題を解決するための手段】
【０００８】
上記のような目的を達成するために、本発明の一態様によれば、通信システムにおいて、Ｎ（１以上の整数）個以上のデータストリームのためのパケットを送信する方法が提案される。上記方法は、それぞれのデータストリームを所定のサイズのデータペイロードに分け、上記それぞれのデータストリームから分けられたそれぞれのデータペイロードに上記Ｎ個のそれぞれのデータストリームを区別するためのＩＤ情報（パケットＩＤ）を含むヘッダを付加することにより、上記Ｎ個のデータストリームのためのソースパケットフローを構成するソースパケットを生成するステップと、上記ソースパケットフローでＮ個のデータストリームのうちでＮ−Ｍ（ここで、Ｍは、整数であり、１≦Ｍ＜Ｎ）個のデータストリームから生成されたソースパケットで構成されたＦＥＣソースパケットフローを決定するステップと、上記決定されたＦＥＣソースパケットフローで所定数のソースパケットで構成された少なくとも１つのソースパケットブロックを区別するステップと、上記区別された少なくとも１つのソースパケットブロックからソースシンボルブロックを生成するステップと、上記生成されたソースシンボルブロックにＦＥＣ符号を適用することにより少なくとも１つ以上のリペアシンボルで構成されたリペアシンボルブロックを生成するステップと、上記ＦＥＣソースパケットフローからＦＥＣ符号を適用することにより生成されたリペアシンボルで構成されるリペアフローを識別するためのリペアフローＩＤを決定するステップと、上記リペアフローのそれぞれのリペアシンボルに上記リペアフローＩＤ及びＦＥＣリペアペイロードＩＤを含むヘッダを付加することによりＦＥＣリペアパケットを生成するステップと、上記ソースパケット及びＦＥＣリペアパケットを送信するステップとを含む。
【０００９】
ここで、上記ソースパケットのためのヘッダは、上記各データストリームのためのＩＤ情報（パケットＩＤ）に基づくパケットシーケンス番号（Packet Sequence Number）を含み、ＦＥＣリペアパケットのヘッダは、上記リペアフローＩＤに基づくパケットシーケンス番号を有する。上記ＦＥＣリペアペイロードＩＤは、上記リペアフローＩＤを有するＦＥＣリペアパケットが保護しているソースパケットブロックに含まれているデータストリームの個数情報（Ｏ個、Ｏは、Ｎ−Ｍ以下）、上記ソースパケットブロック内のそれぞれのデータストリーム（パケットＩＤによる区別）の上記ソースパケットブロック内の１番目のソースパケットのパケットシーケンス番号リスト（Ｏ個のパケットシーケンス番号）、上記ソースパケットブロック内に含まれている各データストリームのためのソースパケットの個数情報、上記ソースパケットブロック内に含まれているデータストリームのパケットＩＤリスト、適用されたＦＥＣのコードポイント、適用されたＳＳＢＧ＿ｍｏｄｅ（ソースシンボルブロック生成モード）、適用されたＦＥＣコーディング構造、上記ソースパケットブロックのパケット個数情報、リペアパケットブロック内で上記ＦＥＣリペアパケットが何番目であるかを示す情報、上記ＦＥＣリペアパケットを含むＦＥＣリペアパケットブロックの個数情報のうちの少なくとも１つを含む。上記ＦＥＣリペアパケットが上記ソースパケットブロック内に含まれているデータストリームのＩＤ情報であるパケットＩＤリスト、適用されたＦＥＣコーディング構造、適用されたＦＥＣコードポイント、適用されたＳＳＢＧ＿ｍｏｄｅの全体又は一部は、ＡＬ−ＦＥＣメッセージに含まれて個別のパケットに送信される。ＦＥＣソースパケットフローに含まれているデータストリームのＩＤ情報であるパケットＩＤリストがＡＬ−ＦＥＣメッセージを通して送信される場合に、ＡＬ−ＦＥＣは、上記パケットＩＤリストに対応するデータストリームを保護するリペアフローＩＤに関するマッピング情報を提供する。
【００１０】
本発明の他の態様によれば、通信システムにおいて、Ｎ（１以上の整数）個以上のデータストリームのためのパケットを送信する装置が提案される。上記装置は、上記それぞれのデータストリームを所定のサイズのデータペイロードに分け、上記それぞれのデータストリームから分けられたそれぞれのデータペイロードに上記Ｎ個のそれぞれのデータストリームを区別するためのＩＤ情報（パケットＩＤ）を含むヘッダを付加することにより、上記Ｎ個のデータストリームのためのソースパケットフローを構成するソースパケットを生成し、上記ソースパケットフローでＮ個のデータストリームのうちのＮ−Ｍ（ここで、Ｍは、整数であり、１≦Ｍ＜Ｎ）個のデータストリームから生成されたソースパケットで構成されたＦＥＣソースパケットフローを決定し、上記決定されたＦＥＣソースパケットフローで所定数のソースパケットで構成された少なくとも１つのソースパケットブロックを区別し、上記区別された少なくとも１つのソースパケットブロックからソースシンボルブロックを生成し、上記生成されたソースシンボルブロックにＦＥＣ符号を適用することにより、少なくとも１つ以上のリペアシンボルで構成されたリペアシンボルブロックを生成し、上記ＦＥＣソースパケットフローからＦＥＣ符号を適用することにより、生成されたリペアシンボルで構成されるリペアフローを識別するためのリペアフローＩＤを決定し、上記リペアフローのそれぞれのリペアシンボルに上記リペアフローＩＤ及びＦＥＣリペアペイロードＩＤを含むヘッダを付加することによりＦＥＣリペアパケットを生成する制御部と、上記ソースパケット及びＦＥＣリペアパケットを送信する送信部とを含む。
【００１１】
ここで、上記ソースパケットのためのヘッダは、上記各データストリームのためのＩＤ情報（パケットＩＤ）に基づくパケットシーケンス番号を含み、ＦＥＣリペアパケットのヘッダは、上記リペアフローＩＤに基づくパケットシーケンス番号を有する。上記ＦＥＣリペアペイロードＩＤは、上記リペアフローＩＤを有するＦＥＣリペアパケットが保護しているソースパケットブロックに含まれているデータストリームの個数情報（Ｏ個は、Ｎ−Ｍ以下）、上記ソースパケットブロック内のそれぞれのデータストリーム（パケットＩＤによる区別）の上記ソースパケットブロック内の１番目のソースパケットのパケットシーケンス番号リスト（Ｏ個のパケットシーケンス番号）、上記ソースパケットブロック内に含まれている各データストリームのためのソースパケットの個数情報、上記ソースパケットブロック内に含まれているデータストリームのパケットＩＤリスト、適用されたＦＥＣのコードポイント、適用されたＳＳＢＧ＿ｍｏｄｅ（ソースシンボルブロック生成モード）、適用されたＦＥＣコーディング構造、上記ソースパケットブロックのパケット個数情報、リペアパケットブロック内で上記ＦＥＣリペアパケットが何番目であるかを示す情報、上記ＦＥＣリペアパケットを含むＦＥＣリペアパケットブロックの個数情報の中の少なくとも１つを含む。上記ＦＥＣリペアパケットが上記ソースパケットブロック内に含まれているデータストリームのＩＤ情報であるパケットＩＤリスト、適用されたＦＥＣコーディング構造、適用されたＦＥＣコードポイント、適用されたＳＳＢＧ＿ｍｏｄｅの全体又は一部は、ＡＬ−ＦＥＣメッセージに含まれて個別のパケットに送信される。ＦＥＣソースパケットフローに含まれているデータストリームのＩＤ情報であるパケットＩＤリストがＡＬ−ＦＥＣメッセージを通して送信される場合に、ＡＬ−ＦＥＣは、上記パケットＩＤリストに対応するデータストリームを保護するリペアフローＩＤに関するマッピング情報を提供する。
【００１２】
本発明のまた他の態様によれば、通信システムにおけるパケットを受信する方法が提案される。上記方法は、送信器から受信されたパケットからソースパケットであるかＦＥＣリペアパケットであるかを区別するステップと、上記ＦＥＣリペアパケットからリペアシンボルを取得するステップとを含み、上記ＦＥＣリペアパケットのＦＥＣリペアペイロードＩＤから上記ＦＥＣリペアパケットが保護しているソースパケットブロックに含まれるソースパケットを区別するステップと、上記区別されたソースパケット及び上記リペアシンボルからエンコーディングシンボルブロック（Encoding Symbol Block）（又は、ＦＥＣブロック）を構成するステップと、上記構成されたエンコーディングシンボルブロックにＦＥＣ復号を通して損失されたソースシンボルを復元することにより送信の間に損失されたソースパケットをソースシンボルから取得するステップとを含む。
【００１３】
本発明の実施形態のさらに他の態様によれば、通信システムにおけるパケットを受信する装置が提案される。上記装置は、送信器から受信されたパケットからソースパケットであるか又はＦＥＣリペアパケットであるかを区別し、上記ＦＥＣリペアパケットからリペアシンボルを取得するステップを含み、上記ＦＥＣリペアパケットのＦＥＣリペアペイロードＩＤから上記ＦＥＣリペアパケットが保護しているソースパケットブロックに含まれるソースパケットを区別し、上記区別されたソースパケットと上記リペアシンボルで構成されたエンコーディングシンボルブロックを構成し、上記構成されたエンコーディングシンボルブロックにＦＥＣ復号を通して損失されたソースシンボルを復元することにより送信の間に損失されたソースパケットをソースシンボルから取得する制御部を含む。
【００１４】
本発明の実施形態のさらなる他の態様によれば、通信システムにおけるパケットを受信する方法が提案される。送信器からＡＬ−ＦＥＣメッセージを含むパケットを受信してＡＬ−ＦＥＣメッセージを取得するステップと、上記ＡＬ−ＦＥＣメッセージからＦＥＣソースパケットフローに含まれるデータストリームのためのＩＤ情報であるパケットＩＤリストとこれを保護するリペアフローＩＤに関するマッピング情報を取得するステップと、送信器から受信されたパケットからソースパケットであるかＦＥＣリペアパケットであるかを区別するステップと、上記ＦＥＣリペアパケットからリペアシンボルを取得するステップとを含み、上記ＦＥＣリペアパケットのＦＥＣリペアペイロードＩＤから上記ＦＥＣリペアパケットが保護しているソースパケットブロックに含まれるソースパケットを区別し、上記区別されたソースパケットと上記リペアシンボルからエンコーディングシンボルブロックを構成するステップと、上記構成されたエンコーディングシンボルブロックにＦＥＣ復号を実行することによりソースシンボルを復旧するステップと、上記復旧されたソースシンボルから送信される間に損失されたソースパケットブロックのソースパケットを取得するステップとを含む。
【００１５】
本発明の実施形態のさらに他の１つの態様によれば、通信システムにおけるパケットを受信する装置が提案される。上記装置は、送信器からＡＬ−ＦＥＣメッセージを含むパケットを受信してＡＬ−ＦＥＣメッセージを取得し、上記ＡＬ−ＦＥＣメッセージからＦＥＣソースパケットフローに含まれるデータストリームのためのＩＤ情報であるパケットＩＤリストとこれを保護するリペアフローＩＤに関するマッピング情報を取得し、送信器から受信されたパケットからソースパケットであるかＦＥＣリペアパケットであるかを区別し、上記ＦＥＣリペアパケットからリペアシンボルを取得するステップを含み、上記ＦＥＣリペアパケットのＦＥＣリペアペイロードＩＤから上記ＦＥＣリペアパケットが保護しているソースパケットブロックに含まれるソースパケットを区別し、上記区別されたソースパケットと上記リペアシンボルからエンコーディングシンボルブロックを構成し、上記構成されたエンコーディングシンボルブロックにＦＥＣ復号を実行してソースシンボルを復旧し、上記復旧されたソースシンボルから送信の間に損失されたソースパケットブロックのソースパケットを取得する制御部を含む。
【００１６】
本発明の実施形態のさらにまた他の態様によれば、通信システムにおいて、Ｎ（１以上の整数）個以上のデータストリームのためのパケットを送信する方法が提案される。上記それぞれのデータストリームを所定のサイズのデータペイロードに分けて上記データペイロードで構成されたソースペイロードフローを構成するステップと、上記Ｎ個のデータストリームのうちでＮ−Ｍ（ここで、Ｍは、整数であり、１≦Ｍ＜Ｎ）個のデータストリームから生成されたデータペイロードで構成されたＦＥＣソースペイロードフローを決定するステップと、上記決定されたＦＥＣソースペイロードフローで所定数のソースペイロードで構成された少なくとも１つのソースペイロードブロックを区別するステップと、上記区別された少なくとも１つのソースペイロードブロックからソースシンボルブロックを生成するステップと、上記生成されたソースシンボルブロックにＦＥＣ符号を適用することにより少なくとも１つ以上のリペアシンボルで構成されたリペアシンボルブロックを生成するステップと、上記ＦＥＣソースペイロードフローからＦＥＣ符号を適用することにより生成されたリペアシンボルで構成されるリペアフローを識別するためのリペアフローＩＤを決定するステップと、上記ソースペイロードフローのそれぞれのデータペイロードにデータストリームを識別するためのパケットＩＤ情報を含むヘッダを付加することによりソースパケットを生成するステップと、上記リペアフローのそれぞれのリペアシンボルに上記リペアフローＩＤ及びＦＥＣリペアペイロードＩＤを含むヘッダを付加することによりＦＥＣリペアパケットを生成するステップと、上記ソースパケット及びＦＥＣリペアパケットを送信するステップとを含む。
【００１７】
ここで、上記ソースパケットのためのヘッダは、上記各データストリームのためのＩＤ情報（パケットＩＤ）に基づくパケットシーケンス番号を含み、ＦＥＣリペアパケットのヘッダは、上記リペアフローＩＤに基づくパケットシーケンス番号を有する。上記ＦＥＣリペアペイロードＩＤは、上記リペアフローＩＤを有するＦＥＣリペアパケットが保護するソースペイロードブロックに含まれているデータストリームの個数情報（Ｏ個、Ｏは、Ｎ−Ｍ以下）、上記ソースペイロードブロック内のそれぞれのデータストリーム（パケットＩＤによる区別）の上記ソースペイロードブロック内の１番目のデータペイロードを送信するソースパケットのパケットシーケンス番号リスト（Ｏ個のパケットシーケンス番号）、上記ソースペイロードブロックに含まれている各データストリームのためのデータペイロードの個数情報、上記ソースペイロードブロックに含まれているデータストリームのパケットＩＤリスト、適用されたＦＥＣのコードポイント、適用されたＳＳＢＧ＿ｍｏｄｅ、適用されたＦＥＣコーディング構造、上記ソースペイロードブロックのペイロード個数情報、リペアシンボルブロック内で上記リペアシンボルが何番目であるかを示す情報、上記リペアシンボルを含むリペアシンボルブロックの個数情報のうちの少なくとも１つを含む。上記ＦＥＣリペアパケットが上記ソースペイロードブロック内に含まれているデータストリームのＩＤ情報であるパケットＩＤリスト、適用されたＦＥＣコーディング構造、適用されたＦＥＣコードポイント、適用されたＳＳＢＧ＿ｍｏｄｅのうちの全体又は一部は、ＡＬ−ＦＥＣメッセージに含まれ、個別のパケットとして送信される。ＦＥＣソースペイロードフローに含まれているデータストリームのＩＤ情報であるパケットＩＤリストがＡＬ−ＦＥＣメッセージで送信される場合に、ＡＬ−ＦＥＣは、パケットＩＤリストに対応するデータストリームを保護するリペアフローＩＤに関するマッピング情報を提供する。
【００１８】
本発明の実施形態のさらなる他の態様によれば、通信システムにおいて、Ｎ（１以上の整数）個以上のデータストリームのためのパケットを送信する装置が提案される。上記装置は、上記それぞれのデータストリームを所定のサイズのデータペイロードに分けて上記データペイロードで構成されたソースペイロードフローを構成し、上記Ｎ個のデータストリームのうちで、Ｎ−Ｍ（ここで、Ｍは、整数であり、１≦Ｍ＜Ｎ）個のデータストリームから生成されたデータペイロードで構成されたＦＥＣソースペイロードフローを決定し、上記決定されたＦＥＣソースペイロードフローで所定数のソースペイロードで構成された少なくとも１つのソースペイロードブロックを区別し、上記区別された少なくとも１つのソースペイロードブロックからソースシンボルブロックを生成し、上記生成されたソースシンボルブロックにＦＥＣ符号を適用して少なくとも１つ以上のリペアシンボルで構成されたリペアシンボルブロックを生成し、上記ＦＥＣソースペイロードフローからＦＥＣ符号を適用することにより生成されたリペアシンボルで構成されるリペアフローを識別するためのリペアフローＩＤを決定し、上記ソースペイロードフローのそれぞれのデータペイロードにデータストリームを識別するためのパケットＩＤ情報を含むヘッダを付加してソースパケットを生成し、上記リペアフローのそれぞれのリペアシンボルに上記リペアフローＩＤ及びＦＥＣリペアペイロードＩＤを含むヘッダを付加してＦＥＣリペアパケットを生成する制御部と上記ソースパケット及びＦＥＣリペアパケットを送信する送信部とを含む。
【００１９】
ここで、上記ソースパケットのためのヘッダは、上記各データストリームのためのＩＤ情報（パケットＩＤ）に基づくパケットシーケンス番号を含み、ＦＥＣリペアパケットのヘッダは、上記リペアフローＩＤに基づくパケットシーケンス番号を有する。上記ＦＥＣリペアペイロードＩＤは、上記リペアフローＩＤを有するＦＥＣリペアパケットが保護するソースペイロードブロックに含まれているデータストリームの個数情報（Ｏ個、Ｏは、Ｎ−Ｍ以下）、上記ソースペイロードブロック内のそれぞれのデータストリーム（パケットＩＤによる区別）の上記ソースペイロードブロック内の１番目のデータペイロードを送信するソースパケットのパケットシーケンス番号リスト（Ｏ個のパケットシーケンス番号）、上記ソースペイロードブロックに含まれている各データストリームのためのデータペイロードの個数情報、上記ソースペイロードブロックに含まれているデータストリームのパケットＩＤリスト、適用されたＦＥＣコードポイント、適用されたＳＳＢＧ＿ｍｏｄｅ、適用されたＦＥＣコーディング構造、上記ソースペイロードブロックのペイロード個数情報、リペアシンボルブロック内で上記リペアシンボルが何番目であるかを示す情報、上記リペアシンボルを含むリペアシンボルブロックの個数情報のうちの少なくとも１つを含む。上記ＦＥＣリペアパケットが上記ソースペイロードブロックに含まれているデータストリームのＩＤ情報であるパケットＩＤリスト、適用されたＦＥＣコーディング構造、適用されたＦＥＣコードポイント、適用されたＳＳＢＧ＿ｍｏｄｅのうちの全体又は一部は、ＡＬ−ＦＥＣメッセージに含まれ、個別のパケットとして送信される。ＦＥＣソースペイロードフローに含まれているデータストリームのＩＤ情報であるパケットＩＤリストがＡＬ−ＦＥＣメッセージを通して送信される場合に、ＡＬ−ＦＥＣは、上記パケットＩＤリストに対応するデータストリームを保護するリペアフローＩＤに関するマッピング情報を提供する。
【００２０】
本発明の実施形態のさらにまた他の態様によれば、通信システムにおけるパケットを受信する方法が提案される。上記方法は、送信器から受信されたパケットがソースパケットであるか又はＦＥＣリペアパケットであるかを区別するステップと、上記ソースパケットからデータペイロードを取得し、上記ＦＥＣリペアパケットからリペアシンボルを取得するステップとを含み、上記ＦＥＣリペアパケットのＦＥＣリペアペイロードＩＤから上記ＦＥＣリペアパケットが保護しているソースペイロードブロックに含まれるデータペイロード及び上記リペアシンボルからエンコーディングシンボルブロックを構成するステップと、上記エンコーディングシンボルブロックにＦＥＣ復号を適用してソースシンボルを復旧するステップと、上記復旧されたソースシンボルから送信の間に損失されたソースパケットのソースペイロードを取得するステップとを含む。
【００２１】
本発明の実施形態のさらなる他の態様によれば、通信システムにおけるパケットを受信する装置が提案される。上記装置は、送信器から受信されたパケットがソースパケットであるか又はＦＥＣリペアパケットであるかを区別し、上記ソースパケットからデータペイロードを取得し、上記ＦＥＣリペアパケットからリペアシンボルを取得し、上記ＦＥＣリペアパケットのＦＥＣリペアペイロードＩＤから上記ＦＥＣリペアパケットが保護しているソースペイロードブロックに含まれるデータペイロード及び上記リペアシンボルからエンコーディングシンボルブロックを構成し、上記エンコーディングシンボルブロックにＦＥＣ復号を適用してソースシンボルを復旧し、上記復旧されたソースシンボルから送信の間に損失されたソースパケットのソースペイロードを取得する制御部を含む。
【００２２】
本発明の実施形態のさらなる他の態様によれば、通信システムにおけるパケットを受信する方法が提案される。上記方法は、送信器からＡＬ−ＦＥＣメッセージを含むパケットを受信してＡＬ−ＦＥＣメッセージを取得するステップと、上記ＡＬ−ＦＥＣメッセージからＦＥＣソースパケットフローに含まれるデータストリームのためのＩＤ情報であるパケットＩＤリスト及びこれを保護するリペアフローＩＤに関するマッピング情報を取得するステップと、送信器から受信されたパケットがソースパケットであるか又はＦＥＣリペアパケットであるかを区別するステップと、上記ソースパケットからデータペイロードを取得し、上記ＦＥＣリペアパケットからリペアシンボルを取得するステップと、を含み、上記ＦＥＣリペアパケットのＦＥＣリペアペイロードＩＤから上記ＦＥＣリペアパケットが保護しているソースペイロードブロックに含まれるソースペイロードと上記リペアシンボルからエンコーディングシンボルブロックを構成するステップと、上記構成されたエンコーディングシンボルブロックにＦＥＣ復号を適用してソースシンボルを復元するステップと、上記復元されたソースシンボルから送信の間に損失されたソースパケットのソースペイロードを取得するステップとを含む。
【００２３】
本発明の実施形態のさらにその他の態様によれば、通信システムにおけるパケットを受信する装置が提案される。上記装置は、送信器からＡＬ−ＦＥＣメッセージを含むパケットを受信してＡＬ−ＦＥＣメッセージを取得し、上記ＡＬ−ＦＥＣメッセージからＦＥＣソースパケットフローに含まれるデータストリームのためのＩＤ情報であるパケットＩＤリストとこれを保護するリペアフローＩＤに関するマッピング情報を取得し、送信器から受信されたパケットがソースパケットであるか又はＦＥＣリペアパケットであるかを区別し、上記ソースパケットからデータペイロードを取得し、上記ＦＥＣリペアパケットからリペアシンボルを取得し、上記ＦＥＣリペアパケットのＦＥＣリペアペイロードＩＤから上記ＦＥＣリペアパケットが保護しているソースペイロードブロックに含まれるソースペイロードと上記リペアシンボルからエンコーディングシンボルブロックを構成し、上記構成されたエンコーディングシンボルブロックにＦＥＣ復号を適用することによりソースシンボルを復元し、上記復元されたソースシンボルから送信の間に損失されたソースパケットのソースペイロードを取得する制御部を含む。
【００２４】
上記ソースパケット又はＦＥＣリペアパケットのヘッダは、ソースパケットであるかＦＥＣリペアパケットであるかを区別する情報を有する。特に、ソースシンボルブロック内のソースシンボルの順序を通知するための個別のソースシンボルＩＤ（ＳＳ＿ＩＤ）を上記ソースパケットに付加するパケット送信方法及び本発明のパケット送信方法がともに使用される場合に、本発明の実施形態によるソースパケット又はＦＥＣリペアパケットのヘッダは、パケットがソースパケット＋ＳＳ＿ＩＤであるか、ソースパケットそれ自体であるか、本発明の実施形態とは異なるＦＥＣリペアパケットであるか、本発明の実施形態によるＦＥＣリペアパケットであるかを区別する情報を有する。
【００２５】
下記の表１は、ＭＰＥＧメディアトランスポート（ＭＭＴ）パケットヘッダのＦＥＣタイプの実施形態を示す。
【００２６】
【表１】
2016535507.tif 000003
また、このパケット区別情報は、ＡＬ−ＦＥＣメッセージを通して本発明の実施形態とは異なるＦＥＣ適用を行ってパケットを送信するか又は本発明の実施形態によるＦＥＣを適用してパケットを送信するかを示すペイロードＩＤ＿モードフラグを有し、受信器に対してＡＬ−ＦＥＣメッセージを通して送信される。
【００２７】
ペイロードＩＤ＿モードフラグ＝１の場合に、本発明の実施形態によるＦＥＣを適用したパケット送信方法を示す。すなわち、ソースパケットに個別のＳＳ＿ＩＤを使用することなしにソースパケット内の情報がＳＳ＿ＩＤに置き換えられ、本発明の実施形態によるＦＥＣリペアパケットフォーマット（特に、ＦＥＣリペアペイロードＩＤ）に従う。
【００２８】
ペイロードＩＤ＿モードフラグ＝０の場合に、本発明の実施形態とは異なるＦＥＣ適用を行ったパケット送信方法を示す。すなわち、個別のＳＳ＿ＩＤをソースパケットに付加し、一般的なＦＥＣリペアパケットフォーマット（特に、ＦＥＣリペアペイロードＩＤ）に従う。
【図面の簡単な説明】
【００２９】
【図１Ａ】ネットワークトポロジー及びデータフローを示す図である。
【図１Ｂ】ネットワークトポロジー及びデータフローを示す図である。
【図２】本発明の実施形態によるＭＭＴシステムの構成を示す図である。
【図３】本発明の実施形態によるＭＭＴパッケージの構造を示す図である。
【図４】本発明の実施形態によるＭＭＴパッケージに含まれた設定情報の構成を示す図である。
【図５Ａ】本発明の一実施形態によるソースパケット、ソースシンボル、及びＦＥＣリペアパケットのフォーマットを示すブロック図である。
【図５Ｂ】本発明の一実施形態によるソースペイロード、ソースシンボル、ＦＥＣリペアパケットのフォーマットを示すブロック図である。
【図５Ｃ】本発明の一実施形態によるソースペイロード、ソースシンボル、ＦＥＣリペアパケットのフォーマットを示すブロック図である。
【図６Ａ】本発明の一実施形態によるＭＭＴパケットヘッダ及びＦＥＣリペアペイロードＩＤのフォーマットを示す図である。
【図６Ｂ】本発明の一実施形態によるソースパケットのためのＭＭＴパケットヘッダ、ＦＥＣリペアパケットのためのＭＭＴパケットヘッダ、及びそれに従うＦＥＣリペアペイロードＩＤのフォーマットを示す図である。
【図６Ｃ】本発明の一実施形態によるＦＥＣコンポジション情報を有するＦＥＣリペアペイロードＩＤのフォーマットを示す図である。
【図６Ｄ】本発明の一実施形態によるＡＬ−ＦＥＣメッセージのためのＭＭＴパケット、ＦＥＣコンポジション情報を有するＡＬ−ＦＥＣメッセージのフォーマットを示す図である。
【図７Ａ】本発明の一実施形態によるソースパケットフローを生成する方法を示す図である。
【図７Ｂ】本発明の一実施形態によるソースパケットフローから２個のＦＥＣソースパケットフローを生成し、それぞれのＦＥＣソースパケットフローに対して１つのリペアフローを生成する方法及びＭＭＴパケットヘッダ、ＦＥＣリペアペイロードＩＤの例を示す図である。
【図８Ａ】本発明の実施形態によるパケット保護のための送信装置の構成を示すブロック図である。
【図８Ｂ】本発明の実施形態によるペイロード保護のための送信装置の構成を示すブロック図である。
【図９Ａ】本発明の実施形態によるパケット保護のための受信装置の構成を示すブロック図である。
【図９Ｂ】本発明の実施形態によるペイロード保護のための受信装置の構成を示すブロック図である。
【図１０】本発明の実施形態によるソースシンボルブロックを構成する例を示す図である。
【発明を実施するための形態】
【００３０】
以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。
【００３１】
また、本発明を説明するにあたって、関連した公知機能或いは構成に対する具体的な説明が本発明の要旨を不必要に不明瞭にすると判断された場合、その詳細な説明は省略する。また、後述する用語は、本発明の機能を考慮して定義されたものであって、ユーザ、運用者の意図、又は慣例によって変わってもよい。したがって、上記用語は、本明細書の全体内容に基づいて定義されなければならない。
【００３２】
まず、本発明で使用される用語を整理すると、次の表２のようである。
【００３３】
【表２】
2016535507.tif 000004
2016535507.tif 000005
以下では、パリティ及びリペアは、同一の意味で混用して使用する。
【００３４】
図１Ａ及び図１Ｂは、ネットワークトポロジー及びデータフローを示す図である。
【００３５】
図１Ａを参照すると、ネットワークトポロジーは、送信器として動作するホストＡ  １０２及び受信器として動作するホストＢ１０８を含み、ホストＡ１０２及びホストＢ１０８は、１つ以上のルータ１０４及び１０６を通して接続される。ホストＡ１０２及びホストＢ１０８は、イーサネット（登録商標）１１８及び１２２を通してルータ１０４及び１０６と接続され、ルータ１０４及び１０６は、光ファイバー、衛星通信（satellite communication）、又は使用可能な他の手段１２０を通して相互に接続される。ホストＡ１０２とホストＢ１０８間のデータフローは、リンクレイヤー１１６、インターネットレイヤー１１４、トランスポートレイヤー１１２、及びアプリケーションレイヤー１１０を通してなされる。
【００３６】
図１Ｂを参照すると、アプリケーションレイヤー１３０は、 ＡＬ−ＦＥＣを通して送信しようとするデータ１３０を生成する。データ１３０は、オーディオ／ビデオ（Audio/Video：ＡＶ）コーデックステージにより圧縮されたデータをリアルタイムプロトコル（Real Time Protocol：ＲＴＰ）を使用して分割したＲＴＰパケットデータ又はＭＭＴに従うＭＭＴパケットデータとできる。一例として、データ１３０は、トランスポートレイヤー１１２によりユーザデータグラムプロトコル（User Datagram Protocol：以下、'ＵＤＰ'と称する）ヘッダが挿入されたＵＤＰパケット１３２に変換される。インターネットレイヤー１１４は、インターネットプロトコル（Internet Protocol：以下、'ＩＰ'と称する）ヘッダをＵＤＰパケット１３２に付加することによりＩＰパケット１３４を生成し、リンクレイヤー１１６は、フレームヘッダ１３６及び必要に応じてフレームフッタ（frame footer）をＩＰパケット１３４に付加することにより送信しようとするフレーム１１６を構成する。
【００３７】
図２は、本発明の実施形態によるＭＭＴシステムの構成を示す図である。
【００３８】
図２の左側は、ＭＭＴシステムの構成を示す図であり、図２の右側は、配信機能レイヤーの細部構造を示す図である。
【００３９】
メディアコーディングレイヤー２０５は、オーディオ又は／及びビデオデータを圧縮してカプセル化機能レイヤー（Encapsulation Function Layer：以下、'Ｅ．レイヤー'と称する）２１０に送信する。
【００４０】
カプセル化機能レイヤー２１０は、圧縮されたオーディオ／ビデオデータをファイルフォーマットと類似した形態でパッケージ化することにより配信機能レイヤー（Delivery Function Layer）２２０に送信する。
【００４１】
配信機能レイヤー（Delivery Function Layer：以下、'Ｄ．レイヤー'と称する）２２０は、カプセル化機能レイヤー２１０の出力をＭＭＴペイロードフォーマットに変換し、ＭＭＴトランスポートパケットヘッダを付加することによりＭＭＴトランスポートパケット形態でトランスポートプロトコルレイヤー２３０に配信する。あるいは、配信機能レイヤー２２０は、カプセル化機能レイヤー２１０の出力を既存のＲＴＰプロトコルを使用してＲＴＰパケット形態でトランスポートプロトコルレイヤー２３０に配信する。その後に、トランスポートプロトコルレイヤー２３０は、ユーザデータグラムプロトコル（User Datagram Protocol：以下、'ＵＤＰ'と称する）及びトランスポート制御プロトコル（Transport Control Protocol：以下、'ＴＣＰ'と称する）のうちのいずれか１つのトランスポートプロトコルに変換した後にＩＰレイヤー２４０に送信する。最終的に、ＩＰレイヤー２４０は、トランスポートプロトコルレイヤー２３０の出力をＩＰパケットに変換してＩＰプロトコルを使用して送信する。
【００４２】
本発明の実施形態によると、ＭＭＴＰパケットを保護するか、ＭＭＴペイロードを保護するか、またはペイロードデータを保護することが可能である。
【００４３】
制御機能レイヤー（Control Function Layer：以下、'Ｃ．レイヤー'と称する）２００は、プレゼンテーションセッション（Presentation Session）及び配信セッション（Delivery Session）を管理する。
【００４４】
図３は、本発明の一実施形態によるＭＭＴパッケージの構造を示す図である。
【００４５】
図３を参照すると、ＭＭＴパッケージ３１０は、ネットワークの配信機能レイヤー（Ｄ．レイヤー）３３０−１及び３３０−２を通してクライアント３５０と送受信され、ＭＭＴアセット３０３−１乃至３０３−３と、コンポジション情報（composition information）３０１と、トランスポート特性（Transport characteristic）３０５−１及び３０５−２とを含む。
【００４６】
また、ＭＭＴパッケージ３１０は、コンフィギュレーション情報を活用するための機能（functionality）及び動作（operation）を有する。コンフィギュレーション情報は、ＭＭＴアセット３０３−１乃至３０３−３のリストと、コンポジション情報３０１と、トランスポート特性３０５−１及び３０５−２とを含む。
【００４７】
ディスクリプション情報（description information）は、ＭＭＴパッケージ３１０とＭＭＴアセット３０３−１乃至３０３−３とを説明する。コンポジション情報３０１は、ＭＭＴアセット３０３−１乃至３０３−３の消費を助ける。トランスポート特性情報３０５−１及び３０５−２は、ＭＭＴアセット３０３−１乃至３０３−３の送信のためのヒントを提供する。
【００４８】
ＭＭＴパッケージ３１０は、ＭＭＴアセット別にトランスポート特性を記述する。トランスポート特性３０５−１及び３０５−２は、エラー復元力（Error Resiliency）情報を含み、１つのＭＭＴアセットのための単純なトランスポート特性（Simple Transport Characteristic）情報は、損失されるか又は損失されないことがある。また、トランスポート特性３０５−１及び３０５−２は、各ＭＭＴアセットのＱｏＳ（Quality of Service：損失許容程度、遅延許容程度）を含む。
【００４９】
図４は、ＭＭＴパッケージに含まれたコンフィギュレーション情報及びその下位情報を示す図である。
【００５０】
図４を参照すると、コンフィグレーション情報は、パッケージ識別情報３１２、パッケージの構成要素であるアセットリスト情報３１４、コンポジション情報３１６、トランスポート特性３１８、及びコンテンツとともに追加の情報を含み、このような構成要素がパッケージ内にどのように含まれるかどこに含まれるかを示す構造的な情報を提供する。
【００５１】
図５Ａは、本発明の一実施形態によるソースパケット、ソースシンボル、及びＦＥＣリペアパケットのフォーマットを示すブロック図である。
【００５２】
ソースパケット（＝ＭＭＴＰパケット）は、ＭＭＴパケットヘッダ、ＭＭＴペイロードヘッダ、及びペイロード（データ）で構成される。ソースシンボルは、ソースパケットに可能なパディングを付加して生成され、ＡＬ−ＦＥＣメッセージで与えられるか又は予め定められたリペアシンボルのサイズとの差だけパディングデータ（すべて００ｈ）が付加される。ＦＥＣリペアパケットは、ＭＭＴパケットヘッダ、ＦＥＣリペアペイロードＩＤ、ＦＥＣ符号化によりソースシンボルブロックから生成されるリペアシンボルで構成される。
【００５３】
図５Ｂは、本発明の一実施形態によるソースペイロード、ソースシンボル、及びＦＥＣリペアパケットのフォーマットを示すブロック図である。
【００５４】
ソースペイロード（＝ＭＭＴペイロード）は、ＭＭＴペイロードヘッダ及びペイロード（データ）で構成される。ソースシンボルは、可能なパディングをソースペイロードに付加して生成され、ＡＬ−ＦＥＣメッセージで与えられるか又は予め定められたリペアシンボルのサイズとの差だけパディングデータ（すべて００ｈ）が付加される。ＦＥＣリペアパケットは、ＭＭＴパケットヘッダ、ＦＥＣリペアペイロードＩＤ、ＦＥＣ符号化によりソースシンボルブロックから生成されるリペアシンボルで構成される。
【００５５】
図５Ｃは、本発明の一実施形態によるソースペイロード、ソースシンボル、ＦＥＣリペアパケットのフォーマットを示すブロック図である。
【００５６】
ソースペイロード（＝ＭＭＴペイロード）は、ＭＭＴペイロードヘッダとペイロード（データ）とから構成される。ソースシンボルは、可能なパディングをソースペイロードに付加して生成され、ＡＬ−ＦＥＣメッセージで与えられるか又は予め定められたリペアシンボルのサイズとの差だけパディングデータ（すべて００ｈ）が付加される。ＦＥＣリペアパケットは、ＭＭＴパケットヘッダ、ＦＥＣリペアペイロードＩＤ、ＦＥＣ符号化によりソースシンボルブロックから生成されるリペアシンボルで構成される。
【００５７】
図６Ａは、本発明の一実施形態によるＭＭＴパケットヘッダ及びＦＥＣリペアペイロードＩＤのフォーマットを示す図である。
【００５８】
ソースパケット及びＦＥＣリペアパケットのためのＭＭＴパケットヘッダは、パケット＿ＩＤフィールド及びパケットシーケンス番号フィールドを有する。
【００５９】
−  パケット＿ＩＤは、対応するＭＭＴＰパケットが送信しているペイロードを含むデータストリームを識別する情報が設定される。対応するＭＭＴＰパケットが任意のアセットのデータを送信する場合に、シグナリングメッセージのメッセージパッケージテーブル（ＭＰＴ）を通してアセットＩＤとマッピングされるパケット＿ＩＤがこのフィールドに設定され、対応するＭＭＴＰパケットがリペアフローのリペアシンボルを送信する場合に、ＡＬ−ＦＥＣメッセージを通してリペアフローＩＤとマッピングされるパケット＿ＩＤがこのフィールドに設定される。
【００６０】
−  パケットシーケンス番号は、同一のパケット＿ＩＤ値を有するパケットのシーケンス番号を示す。アセットを送信する場合に、対応するアセットのデータを送信するパケットの送信順序に基づいて任意の番号から始めて１ずつ増加するシーケンス番号を示す。
【００６１】
ＦＥＣリペアペイロードＩＤは、ＳＳ＿Ｓｔａｒｔ＿Ｓｅｑ＿Ｎｒ［１］〜ＳＳ＿Ｓｔａｒｔ＿Ｓｅｑ＿Ｎｒ［ｎ］、Ｌ［１］／ＳＳＢ＿Ｌｅｎｇｔｈ［１］〜Ｌ［ｎ］／ＳＳＢ＿Ｌｅｎｇｔｈ［ｎ］、ＲＳ＿ＩＤを含み、ブロックコード基盤ＦＥＣコード（例えば、ＬＤＰＣ、ＲＳ）のためには、ＲＳＢ＿Ｌｅｎｇｔｈを追加で含むことができる（ラプター又はラプターＱのようなレートレスＦＥＣコードがＲＳＢ＿Ｌｅｎｇｔｈを使用する場合に、リペアシンボルブロックの損失されたリペアシンボルの個数をＲＳＢ＿Ｌｅｎｇｔｈから測定することができる）。
【００６２】
−  ＳＳ＿Ｓｔａｒｔ＿Ｓｅｑ＿Ｎｒ［ｉ］は、ＦＥＣリペアパケットが保護するソースパケットブロックに含まれるデータストリームのうちでｉ番目のデータストリームのソースパケットブロック内の１番目のソースパケットがパケットシーケンス番号で設定される（ｉ＝１，２，．．．，パケット＿ＩＤ数）。データストリームの順序は、ＡＬ−ＦＥＣメッセージで提供される、ＦＥＣリペアパケットに設定されたパケット＿ＩＤにマッピングされる、ソースパケットフローのためのパケット＿ＩＤがリストされた順序と同一である。
【００６３】
−  Ｌ［ｉ］は、２ビットが割り当てられてＳＳＢ＿Ｌｅｎｇｔｈフィールドのサイズを調節する値である。
【００６４】
−  ＳＳＢ＿Ｌｅｎｇｔｈ［ｉ］（＝"６＋８＊Ｌ［ｉ］"ビット）がＦＥＣリペアパケットが保護するソースパケットブロックに含まれるデートストリームでｉ番目のデータストリームのためのソースシンボルの個数を示す（ｉ＝１，２，．．．，パケット＿ＩＤ数）。
【００６５】
−  ＲＳ＿ＩＤは、ＦＥＣリペアパケットのリペアシンボルがリペアシンボルブロック内の位置を示し、０から始まり１ずつ増加する。
【００６６】
−  ＲＳＢ＿Ｌｅｎｇｔｈは、ＦＥＣリペアパケットを含むリペアパケットブロック内のリペアシンボルの個数を示す。
【００６７】
データストリームの順序は、ＡＬ−ＦＥＣメッセージで提供される、ＦＥＣリペアパケットに設定されたパケット＿ＩＤにマッピングされる、ソースパケットフローのためのパケット＿ＩＤがリストされた順序と同一である。
【００６８】
図６Ｂは、本発明の一実施形態によるソースパケットのためのＭＭＴパケットヘッダ、ＦＥＣリペアパケットのためのＭＭＴパケットヘッダ、及びそれに従うＦＥＣリペアペイロードＩＤのフォーマットを示す図である。ＦＥＣリペアパケットのためのＭＭＴパケットヘッダのパケットシーケンス番号がＦＥＣペイロードＩＤのＲＳ＿ＩＤに変わったことを除いては、図６Ａの説明と同一である。
【００６９】
図６Ｃは、本発明の一実施形態によるＦＥＣコンフィギュレーション情報 を有するＦＥＣリペアペイロードＩＤを示す図である。ＦＥＣコンフィギュレーション情報は、パケット＿ＩＤ数、パケット＿ＩＤのリスト、ＳＳＢＧ＿ＭＯＤＥ、ＦＥＣコードポイント、ＦＥＣコーディング構造、リペアシンボルのサイズがあり、図示していないが、ＦＥＣソース又はリペアパケットブロックのデュレーション（例えば、１番目のソースパケットと最後のソースパケットとが送信される時間差又はパケットの個数）に関する時間情報を追加で含む。
【００７０】
−  パケット＿ＩＤ数：ＦＥＣリペアパケットが保護するソースパケットブロックに含まれているデータストリームの個数
−  パケット＿ＩＤのリスト：ＦＥＣリペアパケットが保護するソースパケットブロックに含まれているデータストリームを識別するパケット＿ＩＤのリスト
−  ＳＳＢＧ＿ＭＯＤＥ：ソースシンボル生成モードを示す。ＳＳＢＧ＿ＭＯＤＥ０又はＳＳＢＧ＿ＭＯＤＥ１
−  ＦＥＣコーディング構造：ＦＥＣリペアパケットが保護するソースパケットブロックに適用されたコーディング構造を示す。１ステージ、２ステージ、ＬＡ−ＦＥＣを区別する。
【００７１】
−  ＦＥＣコードポイント：ＦＥＣリペアパケットを生成するのに使用したＦＥＣ符号を示す。
【００７２】
−  リペアシンボルのサイズ：ＦＥＣリペアパケットを含むリペアシンボルブロックのリペアシンボルのサイズを示す。
【００７３】
ＦＥＣリペアペイロードＩＤに関する他の情報は、図６Ｂの説明と同一である。
【００７４】
図６Ｄは、本発明の一実施形態によるＦＥＣコンフィギュレーション情報を含むＡＬ−ＦＥＣメッセージを示す図であり、ＦＥＣコンフィギュレーション情報は、図６Ｃの説明と同一である。ＡＬ−ＦＥＣメッセージは、メッセージＩＤ、長さフィールド、ＦＥＣフロー数、及び各ＦＥＣフローに関するＦＥＣコンフィギュレーション情報を含む。
【００７５】
図７Ａは、本発明の一実施形態によるソースパケットフローを生成する方法を示す図である。
【００７６】
３個のアセットＡ、Ｂ、Ｃ（例えば、オーディオデータ、ビデオデータ、ｔｘｔ、ファイルのような非同期データ又は同期データ）がある時に、それぞれのアセットは、所定のサイズのデータに分離された後に、ＭＭＴペイロードヘッダ、ＭＭＴパケットヘッダを付加することによりＭＭＴパケットフロー（ソースパケットフロー）を構成する。アセットＡ、Ｂ、Ｃの各々は、５個のデータペイロードに分離され、これらの各々にパケット＿ＩＤ及びパケットシーケンス番号を含むヘッダを付加する。アセットＡのパケットを識別するパケット＿ＩＤ＝０、アセットＢは、パケット＿ＩＤ＝１、アセットＣは、パケット＿ＩＤ＝２が割り当てられ、それぞれのパケット＿ＩＤに基づくパケットシーケンス番号が１ずつ増加するように割り当てられている。このヘッダの一例としてＭＭＴパケットヘッダを挙げることができる。
【００７７】
図７Ｂは、本発明の一実施形態によるＦＥＣソースパケットフロー及びそれに従うリペアフローを生成する方法を示す図である。
【００７８】
図７Ａで生成されたソースパケットフローからのＦＥＣソースパケットフロー１は、アセットＡ及びＢから生成されたソースパケットで構成することにより、ＦＥＣソースパケットブロック１（又はソースシンボルブロック）を生成し、ＦＥＣソースパケットフロー２は、アセットＢ及びアセットＣから生成されたソースパケットで構成し、図示するように、ＦＥＣソースパケットブロック２（又はソースシンボルブロック）を生成することによりそれぞれＦＥＣ符号化を行う。このようにすることにより、ＦＥＣソースパケットブロックは、図１０に記述されたＳＳＢＧ＿ＭＯＤＥの１つの方法によりソースシンボルブロックに転換され、ここにＦＥＣエンコーディングを実行することによりリペアシンボルを送信するＦＥＣリペアパケットを生成する。ＦＥＣリペアパケットのＭＭＴペイロードヘッダ及びＦＥＣリペアペイロードＩＤ情報は、図６Ａ及び図６Ｂに基づく実施形態に示されている。図示していないが、ソースパケットブロックからソースシンボルブロックを生成する時に、ソースパケットブロック内のソースパケットの位置は、送信順序により決定されると仮定すると、それぞれのソースパケットに対応するソースシンボルの位置は、ソースシンボルブロック内で相互に異なる。リペアパケットのＦＥＣリペアペイロードＩＤにて特定されたパケット＿ＩＤの順序に基づいて、ソースシンボルをソースシンボルブロック内に配置することを要する。すなわち、ソースパケットブロックがアセットＡ及びＢで構成される場合に、ソースパケットブロック内では、アセットＡ及びアセットＢのためのソースパケットが相互に混在していても、ソースシンボルブロック内では、アセットＡのためのソースシンボルをまず配置し、次にアセットＢのためのソースシンボルを配置するか、又は、その反対に配置する必要がある。その結果、ＦＥＣリペアパケットのＦＥＣリペアペイロードＩＤに、ソースパケットブロック（又はソースシンボルブロック）に含まれるパケットＩＤの個数と、その配置順序に対応したアセットにマッピングされたパケット＿ＩＤとがリストされる。あるいは、図７Ｂに示すようなソースパケットフローで構成しようとするＦＥＣソースパケットフローを構成し、それぞれのソースパケットブロック（又はソースシンボルブロック）を構成する時に、アセットＡのためのパケットをソースパケットブロック（又はソースシンボルブロック）内にまず配置し、次にアセットＢのためのパケットを配置し、パケット＿ＩＤの個数と、配置順序に基づくパケット＿ＩＤとがリストされる。実際に、ソースパケットフローは、送信順序に基づくソースパケットのストリームである。従って、それぞれのソースパケットブロックのためのソースパケットのうち、最初に送信されるソースパケットのパケット＿ＩＤに対応するソースパケットをソースパケットブロック（又はソースシンボルブロック）内に最初に配置し、次に、それに続くパケット＿ＩＤに対応するソースパケットを配置することが好ましい。
【００７９】
図８Ａ及び図８Ｂは、パケット保護及びペイロード保護の観点からの送信器の動作を示す図である。まず、データストリームは、セグメンテーション、ペイロード化（Payloadization）、パケット化（Packetization）を通して送信器によりパケットストリームとして送信される。例えば、ＭＭＴをデータストリーム＝アセットに配置することができる。セグメンテーションは、データを所定のサイズに分ける。ペイロード化は、ヘッダをデータに付加する。例えば、ＭＭＴペイロードに対応するヘッダには、受信器で受信されたパケットからデータを再構成できる情報が記憶される。パケット化は、ＭＭＴパケットヘッダをＭＭＴペイロードに付加する。ＭＭＴパケットヘッダは、パケット＿ＩＤ及びパケットシーケンス番号を有しているので、ＦＥＣに活用される。
【００８０】
パケット保護がなされる場合に、ＦＥＣ保護を行おうとするＭＭＴパケットは、ＦＥＣ制御器の制御を受けてソースシンボルブロック生成器に入力される。ソースシンボルブロック生成器は、ＭＭＴパケット（ソースパケット）からソースシンボルブロックを生成（図１０の例を参照）し、ＦＥＣエンコーダは、ソースシンボルブロックの入力を受けてリペアシンボルを生成し、それぞれのリペアシンボルは、ＭＭＴパケットヘッダ及びＦＥＣリペアペイロードＩＤを付加することによりＦＥＣリペアパケットに送信される。ここで、ＭＭＴパケットヘッダ及びＦＥＣリペアペイロードＩＤは、その方法に従って本発明の図６Ａ、図６Ｂ、図６Ｃのようなフィールドで構成される。
【００８１】
ペイロード保護は、ＭＭＴペイロード又はペイロードデータの代わりにソースシンボルブロックが入力されること以外は、上記と同様である。
【００８２】
ペイロード化の実行後、すなわち、ＭＭＴペイロードヘッダを付加後、ＭＭＴパケットヘッダが付加され、ＡＬ−ＦＥＣメッセージが、データとは異なるパケットとして送信される。
【００８３】
図９Ａ及び図９Ｂは、パケット保護及びペイロード保護の観点からの受信器の動作を示す図である。まず、パケットを受信する場合に、ソースパケットであるか又はＦＥＣリペアパケットであるかを区別する。様々なタイプのソースパケット（例えば、個別のＳＳ＿ＩＤを有するＭＭＴパケット（既存の発明）とそうでないＭＭＴパケット（本発明）とが共存する場合に）、及び様々なタイプのＦＥＣリペアパケット（例えば、既存の発明によるＦＥＣリペアパケット及び本発明によるＦＥＣリペアパケットが共存する場合）が共存する場合に、これを区別する情報がＭＭＴパケットヘッダにあり、受信器は、これに基づいてそれぞれのパケットを区別する。逆パケット化（例えば、ＭＭＴ逆パケット化又はパース）、逆ペイロード化（ＭＭＴペイロード逆ペイロード化又はパース）、逆セグメンテーションを通してデータストリームが再構成される。パケット保護が適用された場合の受信器の動作は、ＡＬ−ＦＥＣメッセージからＦＥＣデコーディングに必要なＦＥＣ構成に関する基本的な情報を把握する。受信されたパケットがリペアパケットである場合に、受信器は、リペアパケットのリペアシンボルとＭＭＴパケットヘッダにあるパケット＿ＩＤとＦＥＣリペアペイロードＩＤにリストされているパケット＿ＩＤ数、パケット＿ＩＤのリスト、ＳＳ＿Ｓｔａｒｔ＿Ｓｅｑ＿Ｎｒｓ、ＳＳＢ＿Ｌｅｎｇｔｈ［］のリストとは異なる情報から対応するリペアパケットが保護しているソースパケットを認識し、対応するソースパケット（ＭＭＴパケット）をエンコーディングシンボル生成器に入力する。エンコーディングシンボル生成器は、ソースパケットから与えられたＳＳＢＧモードに従ってソースシンボルに転換し、リペアシンボルとともにエンコーディングシンボルブロックを構成する。ＦＥＣデコーダは、リペアシンボルを用いて損失されたソースシンボルを復元し、ソースパケットを取得して逆パケット化ブロックに送信する。
【００８４】
ペイロード保護は、パケットの場合とは反対にペイロードを修復する点を除いて、ＭＭＴパケットヘッダの情報の活用又はＦＥＣリペアパケットのＦＥＣリペアペイロードＩＤ情報の活用面では、パケット保護と同一である。
【００８５】
図１０は、本発明の実施形態によるエンコーディングシンボルブロック生成器５２０でソースシンボルブロックの構成に対する第１の実施形態（ＳＳＢＧ＿ＭＯＤＥ１）を示す図である。
【００８６】
図１０は、本発明の実施形態によるソースパケットブロック（又はソースシンボルブロック）を構成する例を示す図である。３つのパケット＿ＩＤで構成されるパケットのフローからパケット＿ＩＤ＝０又は１を有する２個のパケット＿ＩＤに対応するパケットを選別してＦＥＣソースパケットフロー（＝１ソースパケットブロック）を構成し、パケットＩＤ＝０を有するパケットをまず配置し、次にパケット＿ＩＤ＝１を有するパケットを配置することによりソースシンボルブロックを生成する。ソースパケットがソースシンボルに転換される時に、ソースパケットの長さが相互に異なる場合には、パディングが必要であり（ＳＳＢＧ＿ＭＯＤＥ１）、すべて同一の長さである場合には、パディングが必要ない（ＳＳＢＧ＿ＭＯＤＥ０）。
【００８７】
上述したように、本発明によると、ユーザにより良質のサービスを提供できる。本発明の実施形態によると、受信装置がＦＥＣパケット内のストリーム区別情報又はソースパケットとは異なる個別の制御情報からそれぞれのデータストリームを区別し、それぞれのデータストリームのＦＥＣ保護を行うために生成されたリペアストリームを把握し、ＦＥＣ復号化を円満に実行することができるだけでなく、生成されたソースパケットフローに含まれる所定数のデータストリームに対してリペアフローをソースパケットに影響を与えず生成することができる。
【００８８】
以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び趣旨を逸脱することなく様々な変更が可能であるということは、当業者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。
【図１Ａ】
2016535507.tif 000006
【図１Ｂ】
2016535507.tif 000007
【図２】
2016535507.tif 000008
【図３】
2016535507.tif 000009
【図４】
2016535507.tif 000010
【図５Ａ】
2016535507.tif 000011
【図５Ｂ】
2016535507.tif 000012
【図５Ｃ】
2016535507.tif 000013
【図６Ａ】
2016535507.tif 000014
【図６Ｂ】
2016535507.tif 000015
【図６Ｃ】
2016535507.tif 000016
【図６Ｄ】
2016535507.tif 000017
【図７Ａ】
2016535507.tif 000018
【図７Ｂ】
2016535507.tif 000019
【図８Ａ】
2016535507.tif 000020
【図８Ｂ】
2016535507.tif 000021
【図９Ａ】
2016535507.tif 000022
【図９Ｂ】
2016535507.tif 000023
【図１０】
2016535507.tif 000024
【手続補正書】
【提出日】平成28年5月10日(2016.5.10)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
放送システムにおけるＦＥＣリペアパケットを生成する方法であって、  
ソースシンボルブロック生成モードに基づいて、複数のパケットを含むソースパケットブロックにパディングデータを挿入することで、前記ソースパケットブロックをソースシンボルブロックに変換するステップと、
ＦＥＣコードを用いて前記ソースシンボルブロックをコーディングすることでＦＥＣリペアパケットを生成するステップと、を含み、
前記ＦＥＣリペアパケットは、パケットヘッダとリペアＦＥＣペイロードＩＤを含み、
前記パケットヘッダは、前記コーディングのために使用されるＦＥＣスキームのタイプを表すＦＥＣタイプと、パケットＩＤとパケットシーケンス番号に対する情報を含むことを特徴とする方法。
【請求項２】
前記ＦＥＣタイプが所定値を示すと、前記リペアＦＥＣペイロードＩＤは、前記ＦＥＣリペアパケットにより保護される前記ソースシンボルブロックで最下位パケットを表すシーケンス番号と、前記ＦＥＣリペアパケットにより保護される前記ソースシンボルブロックに含まれたパケットの個数に関する情報を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記ソースパケットブロックのために適用されるコーディング構造を表す情報を含むＦＥＣ構成情報を送信するステップをさらに含むことを特徴とする請求項１に記載の方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００３６
【補正方法】変更
【補正の内容】
【００３６】
図１Ｂを参照すると、アプリケーションレイヤー１３０は、 ＡＬ−ＦＥＣを通して送信しようとするデータ１３０を生成する。データ１３０は、オーディオ／ビデオ（Audio/Video：ＡＶ）コーデックステージにより圧縮されたデータをリアルタイムプロトコル（Real Time Protocol：ＲＴＰ）を使用して分割したＲＴＰパケットデータ又はＭＭＴに従うＭＭＴパケットデータとできる。一例として、データ１３０は、トランスポートレイヤー１１２によりユーザデータグラムプロトコル（User Datagram Protocol：以下、'ＵＤＰ'と称する）ヘッダが挿入されたＵＤＰパケット１３２に変換される。インターネットレイヤー１１４は、インターネットプロトコル（Internet Protocol：以下、'ＩＰ'と称する）ヘッダをＵＤＰパケット１３２に付加することによりＩＰパケット１３４を生成し、リンクレイヤー１１６は、フレームヘッダ１３６及び必要に応じてフレームフッタ（frame footer）１３８をＩＰパケット１３４に付加することにより送信しようとするフレームを構成する。
【国際調査報告】
2016535507.tif 000025
2016535507.tif 000026
2016535507.tif 000027
2016535507.tif 000028