【国等の委託研究の成果に係る記載事項】(出願人による申告)平成27年度、総務省、「平成27年度 電波資源拡大のための研究開発」における「超高精細度衛星・地上放送の周波数有効利用技術の研究開発」に係わる委託研究、産業技術力強化法第19条の適用を受ける特許出願
【文献】
Youngkwon Lim et al.,New MPEG Transport Standard for Next Generation Hybrid Broadcasting System With IP,IEEE Transactions on Broadcasting (Volume:60, Issue:2, June 2014),2014年 4月15日,pp.160-169,URL,https://ieeexplore.ieee.org/document/6798732
【文献】
青木 秀一 他,スーパーハイビジョンの放送に向けたメディアトランスポート技術MMT ,映像情報メディア学会技術報告 Vol.37 No.54 ,日本,(一社)映像情報メディア学会 ,2013年11月28日,第37巻,pp.161-166
(58)【調査した分野】(Int.Cl.,DB名)
【発明の概要】
【発明が解決しようとする課題】
【0007】
AL−FECでは、一連の複数のソースパケットとリペアパケットの集合をFECブロックと呼ぶ。また、1つのFECブロックに含まれる複数のソースパケットを基に、複数のリペアパケットが生成される。AL−FECでは、複数のリペアパケットの集合を、その生成元の複数のソースパケットの集合と関連付ける必要がある。これは、複数のパケットの一部がロスした場合に、同一のFECブロックに含まれるソースパケットおよびリペアパケットを基に、誤り訂正の復号処理を行う必要があるためである。
【0008】
非特許文献1に記載されている技術では、MMTにAL−FECを適用するためのフレームワークとして、あるパケットが属するFECブロックを特定するための2つの方法が規定されている。
【0009】
第1の方法は、ソースシンボルブロック生成モード(Source Symbol Block Generation Mode)が0の場合におけるものである。この場合、ssbg_mode=0と表される。SSBGは「Source Symbol Block Generation Mode」の略である。ssbg_mode=0の場合、リペアパケットを生成して送信するにあたり、対応するソースパケットに変更が加えられないことが特徴である。そして、この場合、リペアパケットの生成に用いた複数のソースパケットの先頭のパケットシーケンス番号を、リペアパケットのペイロード内に格納する。この場合、受信側では、受信したソースパケットそのものからはFECブロックを特定することができない。これは、ソースパケット内にFECブロックを示す情報が含まれないためである。しかし、受信側では、受信したリペアパケット内に格納されている、上記の先頭のパケットシーケンス番号を参照することにより、FECブロックを特定することができる。
【0010】
FECブロックを特定するための第2の方法は、ソースシンボルブロック生成モードが1の場合におけるものである。この場合、ssbg_mode=1と表される。ssbg_mode=1の場合、ssbg_mode=0の場合と同様に、リペアパケットのペイロード内には、リペアパケットの生成に用いた複数のソースパケットの先頭のパケットシーケンス番号を格納する。そして、ssbg_mode=1の場合、さらに、ソースパケット内の最後の部分にも、FECブロックの先頭のパケットシーケンス番号を格納する。したがって、ssbg_mode=1の場合には、ソースパケットだけからでも、リペアパケットからでも、そのパケットが属するFECブロックを特定することができる。つまり、ssbg_mode=1の場合には、受信側で、FECブロックの再構成を容易に行うことができる。
【0011】
このような従来技術は、次の問題を持っている。即ち、ssbg_mode=0の場合には、ソースパケットだけからFECブロックを特定することができない。リペアパケットからFECブロックを特定することは可能であるが、ソースパケットおよびリペアパケット両方のFECブロックを再構成することが困難であり、そのための装置規模(例えば、メモリ量等)が増大してしまう。一方、ssbg_mode=1の場合には、ソースパケットまたはリペアパケットからFECブロックを特定することが容易であるものの、次のような問題を生じる。即ち、ソースパケットの最後部にパケットシーケンス番号が付加されているため、AL−FECに対応しないMMT受信装置は、そのようなパケットを不正なMMTPパケットと認識してしまう。つまり、AL−FECに対応しないMMT受信装置は、正しく受信処理をすることができない。
【0012】
まとめると、従来技術におけるAL−FECフレームワークは、以下のとおりとなる。
(1)ssbg_mode=0では、AL−FECに対応しないMMT受信装置でもソースパケットを処理できる一方、FECブロックの特定が容易ではない。
(2)ssbg_mode=1では、AL−FECに対応しないMMT受信装置ではソースパケットを処理できなくなるが、AL−FECに対応する受信装置はFECブロックを容易に特定できる。
【0013】
例えばテレビ放送あるいは通信回線経由でのコンテンツ配信では、今後、AL−FECを用いた放送信号の伝送と、AL−FECを用いない放送信号の伝送とが共存する状況が生じる。また、AL−FECに対応する受信装置とAL−FECに対応しない受信装置とが共存する状況が生じる。したがって、AL−FECに対応しない受信装置でもAL−FECを用いたパケットを正しく処理することができるとともに、AL−FECに対応する受信装置がFECブロックを容易に特定できるようにすることが求められる。
【0014】
本発明は、上記の課題認識に基づいて行われたものである。本発明は、誤り訂正方式(例えば、AL−FEC)に対応しない受信装置でもその誤り訂正方式を用いたパケットを正しく処理することができ、且つ、その誤り訂正方式に対応する受信装置がパケットの属する誤り訂正ブロック(例えば、FECブロック)を容易に特定できるようにする送信装置、受信装置、プログラム、およびチップを提供する。
【課題を解決するための手段】
【0015】
[1]上記の課題を解決するため、本発明の一態様による送信装置は、供給されるソースデータをソースパケットに格納し、前記ソースデータを基に、誤り訂正ブロックごとに誤り訂正符号化処理を行って生成されるリペアデータをリペアパケットに格納し、前記誤り訂正ブロックを特定するためのブロック特定情報を当該誤り訂正ブロックに属する前記ソースパケットの各々の選択的設定領域内に格納して、前記ソースパケットおよび前記リペアパケットを生成するパケット化部と、前記パケット化部によって生成された前記ソースパケットおよび前記リペアパケットを送信する送信部と、を具備し、前記選択的設定領域内の前記ブロック特定情報の領域は、誤り訂正に対応しない受信装置側においては読み飛ばされる領域である、ことを特徴とする。
【0016】
[2]また、本発明の一態様による送信装置は、供給されるソースデータをソースパケットに格納し、前記ソースデータを基に、FECブロックごとにAL−FEC方式による誤り訂正符号化処理を行って生成されるリペアデータをリペアパケットに格納し、前記FECブロックを特定するためのブロック特定情報を当該FECブロックに属する前記ソースパケットの各々のヘッダー拡張領域内に格納して、MMTPによる前記ソースパケットおよび前記リペアパケットを生成するパケット化部と、前記パケット化部によって生成された前記ソースパケットおよび前記リペアパケットをMMTPで送信する送信部と、を具備することを特徴とする。
【0017】
[3]また、本発明の一態様は、上記の送信装置において、前記パケット化部は、前記ブロック特定情報を当該FECブロックに属する前記リペアパケットのペイロード領域内に格納する、ことを特徴とする。
【0018】
[4]また、本発明の一態様は、上記の送信装置において、前記ブロック特定情報は、前記FECブロックに含まれる先頭のソースパケットのパケットシーケンス番号である、ことを特徴とする。
【0019】
[5]また、本発明の一態様による受信装置は、送信側から送信されるソースパケットおよびリペアパケットを受信する受信部と、前記ソースパケットの選択的設定領域内に格納されたブロック特定情報と前記リペアパケットに格納されたブロック特定情報とに基づいて、前記ソースパケットおよび前記リペアパケットが属する誤り訂正ブロックを特定し、特定された前記誤り訂正ブロックごとに前記ソースパケットおよび前記リペアパケットに基づく誤り訂正処理を行うことによって、元のソースデータを復元する復元部と、を具備することを特徴とする。
【0020】
[6]また、本発明の一態様による受信装置は、AL−FEC方式で冗長符号化されたソースデータおよびリペアデータをそれぞれ含んで送信側からMMTPで送信されるソースパケットおよびリペアパケットを受信する受信部と、前記ソースパケットのヘッダー拡張領域に格納されたブロック特定情報と前記リペアパケットに格納されたブロック特定情報とに基づいて、前記ソースパケットおよび前記リペアパケットが属するFECブロックを特定し、特定された前記FECブロックごとに前記ソースパケットおよび前記リペアパケットに基づいてAL−FEC方式の誤り訂正処理を行うことによって、元のソースデータを復元する復元部と、を具備することを特徴とする。
【0021】
[7]また、本発明の一態様は、上記の受信装置において、前記ブロック特定情報は、前記FECブロックに含まれる先頭のソースパケットのパケットシーケンス番号である、
ことを特徴とする。
【0022】
[8]また、本発明の一態様は、パケットを送信する送信部を備えたコンピューターを、上記のいずれかの送信装置、として機能させるためのプログラムである。
【0023】
[9]また、本発明の一態様は、パケットを受信する受信部を備えたコンピューターを、上記のいずれかの受信装置、として機能させるためのプログラムである。
【0024】
[10]また、本発明の一態様によるチップは、供給されるソースデータをソースパケットに格納し、前記ソースデータを基に、誤り訂正ブロックごとに誤り訂正符号化処理を行って生成されるリペアデータをリペアパケットに格納し、前記誤り訂正ブロックを特定するためのブロック特定情報を当該誤り訂正ブロックに属する前記ソースパケットの各々の選択的設定領域内に格納して、前記ソースパケットおよび前記リペアパケットを生成するパケット化部、を具備し、前記選択的設定領域内の前記ブロック特定情報の領域は、誤り訂正に対応しない受信装置側においては読み飛ばされる領域である、ことを特徴とする。
【0025】
[11]また、本発明の一態様によるチップは、供給されるソースパケットの選択的設定領域内に格納されたブロック特定情報と前記リペアパケットに格納されたブロック特定情報とに基づいて、前記ソースパケットおよび供給されるリペアパケットが属する誤り訂正ブロックを特定し、特定された前記誤り訂正ブロックごとに前記ソースパケットおよび前記リペアパケットに基づく誤り訂正処理を行うことによって、元のソースデータを復元する復元部、を具備することを特徴とする。
【発明の効果】
【0026】
本発明によれば、誤り訂正処理に対応しない受信装置(例えば従来技術による既存の受信装置)との間の互換性を維持しながら、誤り訂正処理により伝送品質を向上させ、さらに受信装置側で容易に誤り訂正ブロックを特定することが可能となる。
なお、誤り訂正ブロックの一例は、AL−FECにおけるFECブロックである。
【発明を実施するための形態】
【0028】
次に、図面を参照しながら、本発明の実施形態について説明する。
【0029】
[第1実施形態]
図1は、本実施形態による送信装置の概略機能構成を示すブロック図である。図示するように、送信装置1は、映像アセット供給部12と、音声アセット供給部14と、字幕アセット供給部16と、多重化部21と、パケット化部25と、送信部27とを含んで構成される。
【0030】
送信装置1は、また誤り訂正を可能とするためにデータを冗長化するとともに、そのデータをパケット化して外部に送信する。より具体的な例としては、送信装置1は、映像や音声等を含むコンテンツのデータを、冗長化するとともに、そのデータをパケット化して外部に送信する。より具体的な例としては、送信装置1は、MMT(MPEG Media Transport)の方式により、コンテンツデータを送信する。送信装置1は、テレビの放送信号(無線または有線)や、通信回線(インターネットプロトコルによる通信)などの手段を用いて、パケットを送信する。以下、送信装置1内の各部の機能について説明する。
【0031】
映像アセット供給部12は、映像のデータを供給する。映像アセット供給部12が供給する映像は、適宜、所定の符号化方法により符号化されたものである。
音声アセット供給部14は、音声のデータを供給する。音声アセット供給部14が供給する音声は、適宜、所定の符号化方法により符号化されたものである。
字幕アセット供給部16は、字幕のデータを供給する。字幕アセット供給部16が供給する字幕データは、例えば、TTML(タイムドテキストマークアップ言語)など、所定の書式を用いて記述されたデータである。
なお、映像と音声と字幕以外のデータを供給する供給部がさらに存在していてもよい。
【0032】
多重化部21は、映像アセット供給部12から供給される映像のデータと、音声アセット供給部14から供給される音声のデータと、字幕アセット供給部16から供給される字幕のデータとを多重化する。また、多重化部21が、映像と音声と字幕以外のデータの供給を受け、このデータを共に多重化してもよい。多重化部21は、多重化したデータを1本のまとまった論理的単位として出力する。テレビ放送の場合、この論理的単位は「サービス」である。
【0033】
パケット化部25は、多重化部21から出力されたデータを基に、送信するためのパケットを生成する。多重化部21から供給されるデータを、ソースデータと呼ぶ。パケット化部25は、多重化部21から出力されたデータをソースパケットとして生成するとともに、AL−FEC(アプリケーション層前方誤り訂正,Application Layer Forward Error Correction)による誤り訂正符号化の手段を用いて、リペアパケットをも生成する。
つまり、パケット化部25は、供給されるソースデータをソースパケットに格納し、ソースデータを基に、誤り訂正ブロックごとに誤り訂正符号化処理を行って生成されるリペアデータをリペアパケットに格納し、誤り訂正ブロックを特定するためのブロック特定情報を当該誤り訂正ブロックに属するソースパケットの各々の選択的設定領域内に格納して、ソースパケットおよびリペアパケットを生成する。なお、選択的設定領域内のブロック特定情報の領域は、誤り訂正に対応しない受信装置側においては読み飛ばされる領域である。
より具体的には、パケット化部25は、供給されるソースデータをソースパケットに格納し、ソースデータを基に、FECブロックごとにAL−FEC方式による誤り訂正符号化処理を行って生成されるリペアデータをリペアパケットに格納し、FECブロックを特定するためのブロック特定情報を当該FECブロックに属するソースパケットの各々のヘッダー拡張領域内に格納して、MMTPによるソースパケットおよびリペアパケットを生成する。なお、「MMTP」は、MPEG Media Transport Protocol(MPEGメディアトランスポートプロトコル)の略である。なお、パケット化部25は、ブロック特定情報をそのFECブロックに属するリペアパケットのペイロード領域内にも格納する。
また、本実施形態では、ブロック特定情報として、そのFECブロックに含まれる先頭のソースパケットのパケットシーケンス番号を用いる。
つまり、FECブロックが、誤り訂正ブロックにあたる。また、誤り訂正符号化処理は、AL−FEC方式により行われる。また、MMTPによるソースパケットのヘッダー拡張領域が、選択的設定領域にあたる。
なお、パケット化部25は、内部に、冗長化部31と、冗長化ブロック特定情報設定部33とを含んでいる。
【0034】
パケット化部25内の冗長化部31は、AL−FECにより、リペアパケットのシンボル列を生成する。冗長化部31は、多重化部21から出力されるデータを所定の単位で分割し、FECブロックに区切る。冗長化部31による冗長化の処理は、このFECブロックを単位として行われる。つまり、1つのFECブロックは、複数のソースパケットの集合と、それら複数のソースパケットの集合に対応する複数のリペアパケットの集合とから成る。なお、AL−FEC自体は既存の技術であり、冗長化部31はこれを利用する。
【0035】
パケット化部25内の冗長化ブロック特定情報設定部33は、各々のソースパケット内に、そのソースパケットが属するFECブロックを特定するための情報を設定する。また、冗長化ブロック特定情報設定部33は、各々のリペアパケット内に、そのリペアパケットが属するFECブロックを特定するための情報を設定する。これにより、各々のソースパケットおよび各々のリペアパケットは、FECブロックを特定する情報を内部に格納する。これにより、これらのパケットを受信する受信装置の側では、単一のパケットの内部に含まれる情報だけから、そのパケットが属するFECブロックを特定できるようになる。FECブロックを特定するための情報として、本実施形態では、そのFECブロックに属する先頭のソースパケットが有するパケットシーケンス番号を用いる。パケットシーケンス番号とは、MMT伝送の規約において定められるシーケンス番号であり、32ビットの符号なし整数で表現されるものである。32ビットの符号なし整数は、42億9496万7296通りの値を表すことができ、通常の映像コンテンツ等の伝送におけるシーケンス番号としては十分な数の表現が可能である。なお、ソースパケットの構成と、ソースパケット内にFECブロックを特定する情報を格納する方法については、後で別の図面を参照しながら詳述する。また、リペアパケットの構成と、リペアパケット内にFECブロックを特定する情報を格納する方法についても、後で別の図面を参照しながら詳述する。
【0036】
上述したように、パケット化部25は、FECブロックごとに、複数のソースパケットと複数のリペアパケットとを生成して出力する。そして、これら各パケットは、そのパケットがどのFECブロックに属するかを示す情報を内部に有している。
【0037】
送信部27は、パケット化部25から出力されたパケットを、順次、送信する。より具体的には、送信部27は、パケット化部25によって生成されたソースパケットおよびリペアパケットをMMTPで送信する。例えば、送信部27は、パケットをテレビの放送信号として送信する。また例えば、送信部27は、パケットをインターネット等の通信回線を介して送信する。このとき、送信部27は、適宜、定められた方式により変調を行う。
【0038】
図2は、本実施形態による受信装置の概略機能構成を示すブロック図である。図示するように、受信装置2は、受信部41と、復元部43と、分離部47と、映像アセット処理部52と、音声アセット処理部54と、字幕アセット処理部56と、提示部60とを含んで構成される。
【0039】
受信装置2は、前述の送信装置1から送信されるパケットを受信し、受信したデータを処理する。受信装置2は、例えば、テレビ受像機である。また、受信装置2は、例えば、パーソナルコンピューターや、タブレット装置や、スマートフォン(スマホ)装置として実現される情報機器である。また、受信装置2は、これら以外の情報処理機器として実現されてもよい。以下、受信装置2内の各部の機能について説明する。
【0040】
受信部41は、外部からの信号を受信する。具体的には、受信部41は、送信側から送信されるソースパケットおよびリペアパケットを受信する。さらに具体的には、受信部41は、AL−FEC方式で冗長符号化されたソースデータおよびリペアデータをそれぞれ含んで送信側からMMTPで送信されるソースパケットおよびリペアパケットを受信する。信号は、放送信号や、通信回線を介して伝送される信号である。具体的には、受信部41は、送信装置1から送信された信号を受信する。そして、受信部41は、受信した信号を復調し、その結果として得られるパケット(受信パケット)を復元部43に供給する。
【0041】
復元部43は、受信部41から渡されるパケットを基に、データを復元する。これらのパケットには、前述のソースパケットとリペアパケットとが含まれている。
具体的には、復元部43は、ソースパケットの選択的設定領域内に格納されたブロック特定情報とリペアパケットに格納されたブロック特定情報とに基づいて、ソースパケットおよびリペアパケットが属する誤り訂正ブロックを特定する。そして、復元部43は、特定された誤り訂正ブロックごとにソースパケットおよびリペアパケットに基づく誤り訂正処理を行うことによって、元のソースデータを復元する。
さらに具体的には、復元部43は、ソースパケットのヘッダー拡張領域に格納されたブロック特定情報とリペアパケットに格納されたブロック特定情報とに基づいて、ソースパケットおよびリペアパケットが属するFECブロックを特定する。そして、復元部43は、特定されたFECブロックごとにソースパケットおよびリペアパケットに基づいてAL−FEC方式の誤り訂正処理を行うことによって、元のソースデータを復元する。
つまり、復元部43は、1つのFECブロックに属するパケットの集合(複数のソースパケットと複数のリペアケット)を基に、誤り訂正処理を行う。なお、伝送路上でパケットが消失している可能性があるが、この誤り(消失)の度合いがそれほど大きくない場合には、上記の誤り訂正処理によって消失したパケットを補って、正しいデータを復元することができる。そして、復元部43は、誤り訂正後のデータを、分離部47に供給する。つまり、復元部43は、受信部41が受信したパケットを基に、元のデータを復元する。
送信装置1の説明においても述べたように、本実施形態でのブロック特定情報は、FECブロックに含まれる先頭のソースパケットのパケットシーケンス番号である。
なお、復元部43は、内部に、冗長化ブロック特定情報検出部71と、誤り訂正部73とを含んでいる。
【0042】
冗長化ブロック特定情報検出部71は、受信部41が受信したパケットの各々が、どのFECブロックに属するものであるかを特定する情報を検出する。冗長化ブロック特定情報検出部71は、ソースパケットあるいはリペアパケットのいずれの場合についても、1つのパケットの内部の情報だけから、そのパケットが属するFECブロックを特定できる。具体的には、ソースパケットを受信した場合、冗長化ブロック特定情報検出部71は、そのソースパケットが属するFECブロックの先頭のソースパケットが有するパケットシーケンス番号を検出し、そのパケットシーケンス番号によりFECブロックを特定する。また、リペアパケットを受信した場合、冗長化ブロック特定情報検出部71は、そのリペアパケットが属するFECブロックの先頭のソースパケットが有するパケットシーケンス番号を検出し、そのパケットシーケンス番号によりFECブロックを特定する。このように、冗長化ブロック特定情報検出部71は、容易に、各パケットが属するFECブロックを特定することができる。
【0043】
誤り訂正部73は、FECブロックごとに分類されたパケットの集合(複数のソースパケットと複数のリペアパケット)により、誤り訂正処理を行う。上記の冗長化ブロック特定情報検出部71が各パケットの属するFECブロックを特定済であるため、誤り訂正部73は、ブロックごとにまとめられたパケットに基づいて容易に誤り訂正処理を行うことができる。なお、あるFECブロック内の一部のパケット(ソースパケットまたはリペアパケット)が消失していた(受信されなかった)場合でも、その程度が所定の範囲内であれば、誤り訂正部73が誤り訂正(消失パケットの復元)を行って、正しいデータが得られる。
【0044】
以上のように、復元部43は、受信したパケットを容易にFECブロックごとにまとめて、誤り訂正処理を行い、送信装置1側でパケット化される前のデータを復元することができる。
なお、受信装置2が、元々送信側において誤り訂正符号化されていない(つまり、AL−FECが用いられていない)パケットを受信した場合には、復元部43は、FECブロックを特定するための処理や、誤り訂正処理を行わない。つまりこの場合、復元部43は、パケットからペイロードを取り出して元のデータを復元する、即ちデパケタイズ処理(depacketization)のみを行う。なお、受信したパケットがAL−FECによる処理を施されていたものであるか否かは、パケットの制御情報を参照することにより判別可能である。
【0045】
分離部47は、復元部43からデータを受け取り、多重化されているそのデータを分離する。そして、分離部47は、分離された各アセットのデータを、それぞれの処理部に渡す。具体的には、分離部47は、復元部43からのデータから抽出した映像アセットのデータを、映像アセット処理部52に渡す。また、分離部47は、復元部43からのデータから抽出した音声アセットのデータを、音声アセット処理部54に渡す。また、分離部47は、復元部43からのデータから抽出した字幕アセットのデータを、字幕アセット処理部56に渡す。さらに、復元部43からのデータにその他のアセットが含まれている場合には、そのアセットを抽出し、そのアセットのための処理部に渡す。
【0046】
映像アセット処理部52は、分離部47から渡された映像アセットのデータをデコードし、映像として出力する。なお、この映像は、提示時刻(プレゼンテーションタイム)情報を伴うものである。
音声アセット処理部54は、分離部47から渡された音声アセットのデータをデコードし、音声として出力する。なお、この音声は、提示時刻情報を伴うものである。
字幕アセット処理部56は、分離部47から渡された字幕アセットのデータを処理する。具体的には、字幕データが格納されたTTML文書ファイルを解析し、ファイル内で指定されたタイミングにしたがって字幕テキストを出力する。なお、出力される字幕データは、提示時刻情報を伴うものである。
その他のアセットがある場合には、それらも適宜同様に処理され、出力される。
【0047】
提示部60は、映像アセット処理部52から渡される映像と、音声アセット処理部54から渡される音声と、字幕アセット処理部56から渡される字幕テキストを、指定されたタイミングで同期させて提示する。提示部60は、渡された映像や字幕を、それぞれのプレーン上に表示する。提示部60は、複数のプレーンを重ねて成る映像(画像)を、例えば液晶ディスプレイ装置等で表示できるように出力する。また、提示部60は、音声を、スピーカー等から出力する。その他のアセットに基づくコンテンツについても、提示部60は、適切な方法で提示する。
【0048】
次に、送信装置1から受信装置2に向けて送信されるMMTPパケットの構成について説明する。なお、
図3および
図4を参照しながらソースパケットについて説明する。また、
図5および
図6を参照しながらリペアパケットについて説明する。
【0049】
図3は、本実施形態において、1つのFECブロックに含まれる一連のソースパケットの構成の特徴的部分を図示する概略図である。
図示する例では、このFECブロックは100個のソースパケットを含む。これらのパケットの各々には、パケットシーケンス番号が付与されている。図中で、例えば「S=201」と表記しているのは、このパケットのパケットシーケンス番号が201であることを示している。このFECに含まれる100個のソースパケットのパケットシーケンス番号は、201で始まり、300で終わる。なお、パケットシーケンス番号が203から299までのソースパケットについては、図示を省略している。
【0050】
各ソースパケットのヘッダー部分は、拡張フラグ(extension flag)とパケットシーケンス番号(packet sequence number)の格納領域を含んでいる。また、図示を省略しているが、ソースパケットのヘッダーは、このパケットがソースパケットであることを表す情報(FEC_type=1)を含んでいる。また、ソースパケットのヘッダーは、他のデータ項目をも格納するが、ここでは図示と説明を省略する。
拡張フラグは、MMTPパケットのヘッダー拡張が行われるか否かを示すフラグ情報である。拡張フラグが1のとき、パケットのヘッダー拡張が行われる、即ち、そのパケットはヘッダー拡張領域(header extension byte)を有する。拡張フラグが0のとき、パケットのヘッダー拡張は行われない。本実施形態では、拡張フラグを1として、ヘッダー拡張を行う。
パケットシーケンス番号は、MMTPパケットの順序を示す番号である。パケットシーケンス番号は、任意の値からスタートすることのできる、シーケンス番号である。図示する例では、各パケットに、パケットシーケンス番号として、201、202、・・・、300という値が格納されている。なお、例えば十進数表現での201は、16進数表現では0x00C9である。
【0051】
前述の通り、本実施形態はパケット拡張を行っているため、図示するソースパケットの各々は、ヘッダー拡張領域を持っている。そして、ソースパケットのヘッダー拡張領域内に、先頭番号を格納する4バイトの領域が設けられている。この先頭番号の領域には、当該FECブロックにおける最初の(先頭の)ソースパケットのパケットシーケンス番号を格納するようにする。図示する一連のソースパケット(S=201からS=300まで)は、前述の通り、1つのFECブロックに属している。したがって、このFECブロックの先頭のソースパケットのパケットシーケンス番号は201である。よって、ここに図示している各パケットのヘッダー拡張領域内の先頭番号には、201という値が設定されている。
【0052】
そして、各ソースパケットのMMTPペイロードの領域には、多重化部21から出力されたデータであって、パケットごとに分割されたデータが、格納されている。
【0053】
なお、AL−FECに対応していない受信装置がこのような先頭番号を含んでいるソースパケットを受信した場合には、その受信装置は、ヘッダー拡張領域に含まれているマルチ拡張ヘッダーのうち、識別できないマルチ拡張ヘッダータイプのデータを読み飛ばして、処理を行う。したがって、AL−FECに対応していない受信装置は、リペアパケットを用いた誤り訂正処理を行わないものの、本実施形態によるソースパケットの処理を適切に行うことができる。ここで、AL−FECに対応していない受信装置とは、例えば、従来技術による、既存の受信装置である。
ソースパケットのヘッダー拡張領域内にブロック特定情報(そのFECブロックの先頭のソースパケットのパケットシーケンス番号)を格納したことにより、上記の効果が得られる。このように、従来技術による既存の受信装置が識別できないタイプについてはデータを読み飛ばす領域を、選択的設定領域と呼ぶ。MMTPパケットのヘッダー拡張領域は、選択的設定領域の一つである。
【0054】
図4は、ソースパケットにおけるヘッダー拡張領域のデータ構成の詳細を示す図である。同図は、ブロック構造を有する形式言語でデータ構造を示し、また、各データ項目のビット数およびデータ表記を併せて示している。なお、データ表記において、bslbfは、「bit string, left bit first」の略であり、「ビット列、最左側ビットが最初」を意味する。また、uimsbfは、「unsigned integer, most significant bit first」の略であり、「符号なし整数、最上位ビットが最初」を意味する。また、データ構造の記述の各行に、便宜上、行番号を付して示している。
【0055】
同図における1行目のHeader_extension_byteが、前図にも示したヘッダー拡張領域にあたる。1行目の左中括弧(カーリーブレース)から10行目の右中括弧までの範囲が、ヘッダー拡張領域である。
2行目のfor文は、繰り返しを表す。iは、繰り返しのための指標である。具体的には、i=0からi=N−1までのN回、2行目の左中括弧から9行目の右中括弧までの範囲が繰り返される。
【0056】
3行目のhdr_ext_end_flag(マルチタイプヘッダー拡張終了フラグ)は、直後のマルチタイプヘッダーがヘッダー拡張の最後であるか否かを示すフラグである。マルチタイプヘッダー拡張終了フラグのビット数は1であり、データ表記はbslbfである。マルチタイプヘッダー拡張終了フラグが1のとき、直後のマルチタイプヘッダーがヘッダー拡張の最後である。また、マルチタイプヘッダー拡張終了フラグが0のとき、それ以外である(即ち、最後ではない)。
【0057】
4行目のhdr_ext_type(マルチ拡張ヘッダータイプ)は、マルチタイプヘッダー拡張の拡張種別を示す。マルチ拡張ヘッダータイプのビット数は15であり、データ表記はuimsbfである。本実施形態では、FECブロックの先頭のソースパケットのパケットシーケンス番号を格納するための拡張種別の値を、適宜、定義する。一例として、マルチ拡張ヘッダータイプが0x0004(16進数表現)であるとき、そのヘッダー拡張において、FECブロックの先頭のソースパケットのパケットシーケンス番号を格納することとする。なお、「ARIB標準規格STD−B60 1.4版」(2015年9月30日改定)では、多くの値が「将来予約」として残されているため、これらの値の中から選ばれた値を、この先頭番号の格納用に用いればよい。
【0058】
5行目のhdr_ext_length(マルチ拡張ヘッダー長)は、このフィールドの直後の一つの拡張ヘッダー領域の大きさ(直後のhdr_ext_byteの大きさ)をバイト単位で示す。マルチ拡張ヘッダー長のビット数は16であり、データ表記はuimsbfである。ソースパケットの先頭のパケットシーケンス番号を格納するためには、4バイト必要であるため、そのためのマルチ拡張ヘッダー長の値としては、0x0004(16進数表現)を格納する。
【0059】
6行目から8行目までのループで、上記のマルチ拡張ヘッダー長の値に応じた回数だけ、hdr_ext_byte(マルチ拡張ヘッダー領域)が繰り返される。当該FECブロックの先頭のソースパケットのパケットシーケンス番号を格納するためには、4バイト(32ビット)分の領域が確保される。この4バイトの領域に、先頭のソースパケットのパケットシーケンス番号を格納するようにする。前図に示した例では、先頭のソースパケットのパケットシーケンス番号として0x00C9(十進数表現では、201)が格納される。
【0060】
図5は、本実施形態において、1つのFECブロックに含まれる一連のリペアパケットの構成の特徴的部分を図示する概略図である。
図示する例では、このFECブロックは20個のリペアパケットを含む。これらのパケットの各々には、パケットシーケンス番号が付与されている。このFECに含まれる20個のリペアパケットのパケットシーケンス番号は、301で始まり、320で終わる。なお、パケットシーケンス番号が303から319までのリペアパケットについては、図示を省略している。
【0061】
各リペアパケットのヘッダー部分は、ペイロードタイプ(payload type)の領域を含んでいる。ペイロードタイプは、6ビットの、符号なし整数で表現される。ペイロードタイプが3(16進数表記で、0x03)のとき、その値は、そのパケットがAL−FECのリペアシンボルを含むことを表す。図示するように、各リペアパケットは、ペイロードタイプ=3という情報を保持している。
また、各リペアパケットのヘッダー部分がパケットシーケンス番号の領域を含んでいることは、ソースパケットについて説明したのと同様である。図示するリペアパケットは、パケットシーケンス番号の値として、301、302、・・・、320をそれぞれ保持している。
また、リペアパケットのヘッダーは、他のデータ項目をも格納するが、ここでは図示と説明を省略する。
【0062】
また、各リペアパケットは、MMTPペイロードの領域を有している。MMTPペイロードの詳細な構成については、後で別の図面を参照しながら説明する。各リペアパケットのMMTPペイロードは、FECブロックを特定するための情報を格納する領域を有している。リペアパケット内のこの情報により、当該リペアパケットがどのFECブロックに属するものであるかを示すことができる。前述の通り、本実施形態で、FECブロックを特定するための情報とは、そのFECブロックにおける先頭のソースパケットのパケットシーケンス番号である。つまり、各リペアパケットのMMTPペイロードは、ソースパケットの先頭番号を格納するための領域を有している。ここで、ソースパケットの先頭番号とは、このリペアパケットが属するFECブロックにおける、先頭のソースパケットのパケットシーケンス番号のことである。
図3で示した例では、FECブロックにおける先頭のソースパケットのパケットシーケンス番号は201である。よって、本図に示すリペアパケットは、その内部において、ソースの先頭番号として201という値を格納する。
【0063】
そして、各リペアパケットの、MMTPペイロードの領域内において、より後方にはリペアシンボル列を格納するための領域が存在する。
【0064】
図6は、MMTPのリペアパケット内のペイロードのデータ構成を示す図である。同図も、
図4と同様に、ブロック構造を有する形式言語でデータ構造を示し、また、各データ項目のビット数およびデータ表記を併せて示している。また、データ構造を記述している各行に、便宜上、行番号を付して示している。
【0065】
図示するデータ構造の、1行目から21行目までがMMTPパケット内のペイロードの構成を表す記述である。また、2行目の条件節(if文)は、「type==0x03」という条件を含んでいる。この条件が真であるとき、即ちパケットのタイプの値が0x03(16進数表現)であるとき、このパケットはリペアパケットである。なお、当該条件節の条件が真であるとき、2行目の左中括弧から20行目の右中括弧までのブロックの定義が有効である。
3行目から7行目までについては、説明を省略する。
【0066】
8行目から10行目までの記述によって定義される領域が、FECブロックを特定する情報を格納するための領域である。即ち、8行目から10行目までの記述によって定義される領域が、当該リペアパケットが属するFECブロックの、先頭のソースパケットのパケットシーケンス番号を格納するための領域である。この領域のビット数は、8+8*SSMである。なおここで「*」は乗算演算子である。また、SSMは、データ構造の5行目で定義されている長さ情報である。つまり、名称ss_start_seq_nr[]で定義される領域に、当該リペアパケットが属するFECブロックの、先頭のソースパケットのパケットシーケンス番号が書き込まれる。
【0067】
11行目から19行目までについては、説明を省略する。
【0068】
図7は、上述した方法により送信装置から受信装置に伝送される一連のパケットを示す概略図である。同図には、2つのFECブロックが含まれている。便宜上、各FECブロックを#1および#2として示している。なお、一連のデータ伝送におけるFECブロックの個数は、いくつでもよい。各FECブロックは、複数のソースパケットと複数のリペアパケットを含む。FECブロックは、誤り訂正符号のひとまとまりの単位である。
【0069】
#1のFECブロックには、100個のソースパケットと20個のリペアパケットとが含まれている。このうち、100個のソースパケットのパケットシーケンス番号は、201から300までである。また、20個のソースパケットのパケットシーケンス番号は、301から320までである。
#2のFECブロックには、100個のソースパケットと20個のリペアパケットとが含まれている。このうち、100個のソースパケットのパケットシーケンス番号は、321から420までである。また、20個のソースパケットのパケットシーケンス番号は、421から440までである。
なお、パケットのサイズは、可変である。また、1つのFECブロックに含まれるソースパケットの個数は100に限定されない。また、1つのFECブロックに含まれるリペアパケットの個数は20に限定されない。
【0070】
このようにソースパケット及びリペアパケットの両方に、ソースパケット先頭のパケットシーケンス番号を格納することで、受信装置は、送信装置側と同じFECブロックを構成することが容易に行え、ロスしたパケットを復元することができる。
【0071】
[第2実施形態]
次に、第2実施形態について説明する。なお、前実施形態と共通の事項については説明を省略する場合がある。ここでは、本実施形態に特有の事項を中心に説明する。
図8は、本実施形態による送信装置の概略機能構成を示すブロック図である。図示するように、送信装置3は、データ供給部101と、パケット化部125と、送信部127とを含んで構成される。
【0072】
データ供給部101は、送信するためのデータを供給する。データ供給部101が供給するデータは、誤り訂正符号化処理におけるソースデータである。
【0073】
パケット化部125は、第1実施形態におけるパケット化部25と同様の機能を有する。ただし、パケット化部125が処理の対象とするデータは、映像コンテンツ等のデータに限らず、一般的なデータである。また、パケット化部125が生成するパケットは、MMTPのパケットに限らず、他のプロトコルのためのパケットであってもよい。ただし、パケット化部125が、ソースパケットとリペアパケットを生成する点は、第1実施形態におけるパケット化部25と同様である。なお、パケット化部125は、冗長化部131と冗長化ブロック特定情報設定部133とを含んで構成される。
【0074】
冗長化部131は、データ供給部101から供給されるソースデータを基に、誤り訂正符号化の処理を行い、リペアデータを生成する。なお、本実施形態においても、冗長化部131は、誤り訂正ブロックごとのまとまりで、誤り訂正符号化を行う。つまり、ある誤り訂正ブロックに含まれるソースデータに対応するリペアデータは、同じ誤り訂正ブロック内のみに存在する。ここで、誤り訂正符号化の処理は、AL−FEC方式に限られず、他の方式によるものであってもよい。ソースデータは、ソースパケットに格納される。リペアデータはリペアパケットに格納される。伝送路上でこれらのパケットのうちの一部が消失した場合でも、その消失の程度に応じては、受信側で受信できたソースパケットとリペアパケットに基づいて、元のデータを復元可能である。
【0075】
冗長化ブロック特定情報設定部133は、少なくともソースパケットに、そのソースパケットが属する誤り訂正ブロックを特定するための情報を格納する。また、冗長化ブロック特定情報設定部133が、リペアパケットにも、そのリペアパケットが属する誤り訂正ブロックを特定するための情報を格納してもよい。ここで、誤り訂正ブロックを特定するための情報を、便宜上、ブロック特定情報と呼ぶ。ブロック特定情報としては、例えば、その誤り訂正ブロックを代表するソースパケットの識別情報(例えば、パケットシーケンス番号など)や、誤り訂正ブロックごとに付与される識別情報(例えば、パケットシーケンス番号とは独立に付与される、誤り訂正ブロックのシーケンス番号など)を用いる。ここで、誤り訂正ブロックを代表するソースパケットとは、例えばそのブロック内の先頭のソースパケットや、そのブロック内の2番目のソースパケットや、その他、適宜予め定めておいたソースパケットである。
【0076】
なお、パケット化部125は、ブロック特定情報を、ソースパケット内の選択的設定領域の中に格納する。ここで、選択的設定領域とは、受信装置側で適宜読み飛ばされることのできる領域である。例えば、本実施形態による送信装置3が送信するソースパケットが誤り訂正符号化に対応していない受信装置によって受信される場合、その受信装置は、選択設定領域内の情報であって自受信装置に不要なデータを読み飛ばす。したがって、誤り訂正符号化に対応していない受信装置が本実施形態によるソースパケットを受信した場合にも、エラーとはならず、正常に処理を行える。
また、さらに、パケット化部125は、ブロック特定情報を、リペアパケット内の選択的設定領域の中に格納するようにしてもよい。リペアパケット内の選択的設定領域の技術的意義も、上述したソースパケット内の選択的設定領域のそれと同様である。
【0077】
送信部127は、第1実施形態における送信部27と同様に、生成されたソースパケットおよびリペアパケットを送信する。ただし、本実施形態では、通信プロトコルは、MMTPには限定されない。また、送信部127は、無線信号あるいは有線信号のいずれを用いて送信してもよい。
【0078】
図9は、本実施形態による受信装置の概略機能構成を示すブロック図である。図示するように、受信装置4は、受信部141と、復元部143と、データ処理部180とを含んで構成される。受信装置4は、前述の送信装置3から送信されるパケットを受信し、受信したデータを処理する。受信装置4は、第1実施形態における受信装置2と同様に、例えば、テレビ受像機、パーソナルコンピューター、タブレット装置、スマートフォン(スマホ)装置などといった機器として実現される。
【0079】
受信部141は、送信装置3から送信されるソースパケットおよびリペアパケットを受信する。なお、受信部141が受信しようとするパケットの一部は、伝送路上で消失する場合もある。受信部141は、消失したパケットの有無にかかわらず、受信したソースパケットおよびリペアパケットのすべてを復元部143に渡す。
【0080】
復元部143は、第1実施形態における復元部43と同様に、渡されたソースパケットおよびリペアパケットから、送信側で供給された元のデータ(ソースデータ)を復元する。そのため、復元部143は、渡されたパケットから、ソースデータおよびリペアデータを取り出し、そのシーケンスを再構成する。また、復元部143は、誤り訂正処理により、ソースデータを復元する。この誤り訂正処理により、伝送路上でデータの一部が消失していた場合にも、その誤り訂正符号の能力の範囲内で、消失データの訂正を行える。なお、前述の通り、送信装置3側では、誤り訂正ブロックごとに誤り訂正符号化の処理が行われている。したがって、復元部143は、渡されたソースパケットに格納されているブロック特定情報を検出してから、上記の誤り訂正処理を行う。また、復元部143は、渡されたリペアパケットに格納されているブロック特定情報を検出してから、上記の誤り訂正処理を行う。各パケットにブロック特定情報が格納されているため、復元部143は、そのパケットがどの誤り訂正ブロックに属するものであるかを、容易に特定することができる。
【0081】
なお、復元部143は、冗長化ブロック特定情報検出部171と、誤り訂正部173とを含んで構成され、これら各部の機能を利用して上述した処理を行う。
冗長化ブロック特定情報検出部171は、第1実施形態における冗長化ブロック特定情報検出部71と同様の機能を有する。ただし、処理対象のパケットはMMTPのパケットには限定されない。
誤り訂正部173は、第1実施形態における誤り訂正部173と同様の機能を有する。ただし、処理対象のパケットはMMTPのパケットには限定されない。また、誤り訂正符号化の方式は、AL−FECには限定されない。
【0082】
データ処理部180は、復元部143によって復元されたデータを用いて、処理を行う。なお、データ処理部180による処理の内容は、適用分野に応じて様々である。
【0083】
次に、本実施形態におけるパケットのデータ構成について説明する。
図10は、本実施形態において送信装置が受信装置に送るソースパケットのデータ構成を示す概略図である。図示するように、ソースパケットのペイロード領域にソースデータが格納されている。また、ソースパケットは、選択的設定領域を有している。そして、選択的設定領域内の所定の場所にブロック特定情報が格納される。送信装置3は、同図に示すソースパケットを送信する。受信装置4は、このソースパケットを受信すると、選択的設定領域内のブロック特定情報を検出する。受信装置4は、ソースパケット内のブロック特定情報を参照することにより、このソースパケットがどの誤り訂正ブロックに属するかを特定することができる。つまり、受信装置4は、そのソースパケットの外の情報に依ることなく、そのソースパケットがどの誤り訂正ブロックに属するかを特定することができる。
【0084】
なお、本実施形態による誤り訂正方式に対応していない受信装置(例えば、従来技術による既存の受信装置)は、同図に示すソースパケットを受信しても、ブロック特定情報を認識しない。つまり、その受信装置は、ブロック特定情報を読み飛ばして、ソースデータの処理を正しく行うことができる。これは、ブロック特定情報が選択的設定領域内に格納されているためである。
【0085】
図11は、本実施形態において送信装置が受信装置に送るリペアパケットのデータ構成を示す概略図である。図示するように、リペアパケットのペイロード領域にリペアデータが格納されている。また、リペアパケットは、選択的設定領域を有している。そして、選択的設定領域内の所定の場所にブロック特定情報が格納される。送信装置3は同図に示すリペアパケットを送信し、受信装置4はそのリペアパケットを受信する。受信装置4は、リペアパケット内のブロック特定情報を参照することにより、そのリペアパケットがどの誤り訂正ブロックに属するものであるかを特定できる。
なお、選択的設定領域内にブロック特定情報を格納する代わりに、リペアパケット内の選択的設定領域以外の任意の場所にブロック特定情報を格納するようにしてもよい。一例として、リペアパケットにおけるペイロードの領域内にブロック特定情報を格納するようにしてもよい。
【0086】
以上、
図10と
図11とを参照しながら説明したように、ソースパケットとリペアパケットがともに、パケット内に誤り訂正ブロックを特定するためのブロック特定情報を有している。したがって、これらのパケットを受信する受信装置4の側では、各ソースパケットおよび各リペアパケットがどの誤り訂正ブロックに属するかを容易に認識することができる。したがって、受信装置4は、簡単に(例えば、少ない処理量で、あるいは少ない一時記憶用のメモリ量で)、受信したパケットの誤り訂正処理を行うことができる。また、ソースパケットのブロック特定情報は、ソースブロックにおける選択的設定領域内に格納されているため、本実施形態による誤り訂正方式に対応していない受信装置も、ブロック特定情報を読み飛ばして、正しい処理を行うことができる。つまり、本実施形態による伝送方法は、既存の受信装置にも互換性がある。もちろん、リペアパケットにおいても、ブロック特定情報を選択的設定領域内に格納してもよい。
【0087】
ここで説明した第2実施形態は、既に述べた第1実施形態をより一般化した実施形態である。逆に言うと、第1実施形態は、第2実施形態の特殊例である。具体的には、第1実施形態では、用いるプロトコルをMMTPに限定していた。また、第1実施形態では、誤り訂正の方式をAL−FECに限定していた。第2実施形態にはこれらの限定はない。第2実施形態は任意のプロトコルに適用可能である。また、第2実施形態は、ソースデータをソースパケットで送信し、リペアデータ(ソースデータを基に生成される冗長符号のデータ)をソースパケット以外で送信する任意の誤り訂正方式に適用可能である。
【0088】
なお、上述した各実施形態における、送信装置内の少なくともパケット化部(25,125)を含む機能を、半導体集積回路のチップとして実装しても良い。また同様に、受信装置内の少なくとも復元部(43,143)を含む機能を、半導体集積回路のチップとして実装しても良い。チップは、微細加工技術を用いて、多数の素子を有する電子回路を実現したものである。また、チップは、パッケージ化され、電力供給や信号入出力のためのリード線が設けられている。また、半導体集積回路のチップを実現する手法の一つとして、FPGA(フィールド・プログラマブル・ゲート・アレイ,Field Programmable Gate Array)を用いて、上述した機能を設定するようにしても良い。
【0089】
なお、上述した実施形態における送信装置および受信装置の少なくとも一部の機能をコンピューターで実現するようにしても良い。その場合、これらの機能を実現するためのプログラムをコンピューター読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピューターシステムに読み込ませ、実行することによって実現しても良い。なお、ここでいう「コンピューターシステム」とは、OSや周辺機器等のハードウェアを含むものとする。また、「コンピューター読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD−ROM等の可搬媒体、コンピューターシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピューター読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバーやクライアントとなるコンピューターシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【0090】
以上、複数の実施形態を説明したが、本発明はさらに次のような変形例でも実施することが可能である。
第1実施形態および第2実施形態では、ソースパケットとリペアパケットで、共通のパケットシーケンス番号が付与されていた。具体的には、例えば
図7において、第1のFECブロックにおける最後のソースパケットのパケットシーケンス番号が300であり、それに続く、その第1のFECブロックにおける先頭のリペアパケットのパケットシーケンス番号が301であった。また、第1のFECブロックにおける最後のリペアパケットのパケットシーケンス番号が320であり、次の、第2のFECブロックにおける先頭のソースパケットのパケットシーケンス番号が321であった。変形例では、ソースパケットにはソースパケット内で閉じたパケットシーケンス番号を付与し、リペアパケットにはリペアパケット内で閉じたパケットシーケンス番号を付与する。この場合、送信装置内には、ソースパケットにパケットシーケンス番号を付与するためのカウンターと、リペアパケットにパケットシーケンス番号を付与するためのカウンターとがそれぞれ設けられる。前者のカウンターはソースパケットを生成する都度インクリメントされ、後者のカウンターはリペアパケットを生成する都度インクリメントされる。
【0091】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。