JP4388031B2 - デジタルマルチメディア放送チャネルの管理方法、デジタルマルチメディア放送システム及びデジタルマルチメディア放送を受信可能な端末機 - Google Patents

Description

本発明は、デジタルマルチメディア放送チャネルの管理方法、デジタルマルチメディア放送システム及びデジタルマルチメディア放送を受信可能な端末機に関し、特に、いわゆるリコンフィグレーション、すなわち、放送チャネル（アンサンブル）内のサービス変更が発生したときの処理に関する。

近年、ＣＤ、ＤＶＤなどの優れた音質のデジタルオーディオ機器が急速に普及したことに伴って、高音質なデジタル放送に対する聴取者の要求も日々に増加している。このような環境の下、ヨーロッパ、カナダ、米国などでは、既存のＦＭ放送における音質の限界を克服するために、デジタルオーディオ放送（Ｄｉｇｉｔａｌ Ａｕｄｉｏ Ｂｒｏａｄｃａｓｔｉｎｇ：ＤＡＢ）が実現されている。このＤＡＢ（システム）では、既存のＡＭ放送またはＦＭ放送とは全く異なる技術を用いており、高音質で移動中も優れた受信性能を有するばかりでなく、映像や文字などのデジタルデータも高速で送信できるという特徴を有している。このような特徴を有することもあって、最近は、ＤＡＢを単にオーディオ放送と称するよりは、映像を含む様々なデジタルマルチメディアサービスを提供できる点が強調されて、デジタルマルチメディア放送と称する場合も多い。

ＤＡＢシステムにおいては、各放送チャネルに対応する放送波（周波数）がアンサンブル（ｅｎｓｅｍｂｌｅ）と呼ばれ、各アンサンブル（放送チャネル）には、複数のサービス（番組等）が含まれている（多重化されている）。また、各サービスには、複数（例えば、最大１１〜１２個）のサブチャネルや高速情報データチャネル（Ｆａｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｄａｔａ Ｃｈａｎｎｅｌ：ＦＩＤＣ）などのサービスコンポーネントも含まれている。

このようなアンサンブル内のサービス構成（以下、「アンサンブル構成」という）に関する情報を多重化構成情報（Ｍｕｌｔｉｐｌｅｓ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ：ＭＣＩ）といい、このＭＣＩは、主要サービスチャネル（Ｍａｉｎ Ｓｅｒｖｉｃｅ Ｃｈａｎｎｅｌ：ＭＳＣ）のサービス種類、位置、形態などの情報として受信装置（端末機）に繰り返しに受信されるようになっており、この受信されたＭＣＩはＭＳＣを解析するのに用いられる。
ところで、アンサンブル構成を変更することをリコンフィグレーション（ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）という。このリコンフィグレーションが発生した場合でも、その所定時間前（例えば、少なくとも６秒（２５０ＣＩＦ）前）に新しいＭＣＩを受信装置に送信しておくことで、受信装置は予め新しいアンサンブル構成を知ってそれに対応することができる。

リコンフィグレーションが発生すると、アンサンブル内のサービス数やサービスコンポーネントの構造が変化するか、あるいは、サブチャネルの構成が変化する。例えば、図４に示すように、アンサンブル（放送チャネル）内のサービス数（番組数）が３から４に増加したり、図５に示すように、サービス数が３から２に減少したりする。また、サービス数は３に維持されるものの、それらのうちのあるサービスに属するサブチャネルの一部がなくなったり、既存のサービスに新しいサブチャネルが追加されたりすることもある。
しかしながら、このようなリコンフィグレーションの発生がユーザに知らされないと、ユーザは、アンサンブル構成が変更されたことを認識することができない。そのため、例えば、リコンフィグレーションによって新たなサービスが追加され、あるいは、それまであったサービスがなくなったりした場合であっても、ユーザはそのことを知り得ず、アンサンブル構成が変更された後に、ユーザが自ら該アンサンブルのサービス構成を確認することによって事後的に知るしかなかった。

従来は、視聴しているアンサンブルのサービス構成（放送チャネルのアンサンブル構成）が変更されたときにのみ、リコンフィグレーションを通じて約６秒間新しいＭＣＩ（すなわち、アンサンブル内のサービス情報）を得ることができた。しかしながら、この方法では、リコンフィグレーションが発生したときに視聴していないと、換言すると、視聴していない放送チャネルのアンサンブル構成の変更には対応することができなかった。
このような問題に対処するため、放送が受信されていないとき（視聴していないとき）にアンサンブルのサービス検索（チャネル検索）を行うことが考えられる。これにより、ＤＡＢデータフレームのＦＩＣ（Ｆｉｒｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ）のデコーディングが可能となり、視聴していない放送チャネルのリコンフィグレーション発生後のアンサンブル構成情報（放送番組情報）を得ることができる。
しかし、このようにしてしまうと、一時的に受信信号が微弱となったり、遮られたりした場合、例えば、陰影地域でさえも動作するようになり、現在の情報までも消してしまうという問題がある。

また、周期的にＦＩＣデコーディングを行う方法も提案されたが、この方法も、陰影地域等で動作することになり、同様の問題があった。

本発明は、上記のような問題を解決するためになされたものであり、その目的は、特に視聴していない放送チャネル（アンサンブル）においてサービス構成（番組構成等）に変更があった場合であっても、この変更に適切に対応することのできるデジタルマルチメディア放送チャネルの管理方法、デジタルマルチメディア放送システム及びデジタルマルチメディア放送を受信可能な端末機を提供することにある。

上記目的を達成するため、本発明に係るデジタルマルチメディア放送チャネルの管理方法は、デジタルマルチメディア放送センターから送出され、ＦＩＧタイプ０のエクステンション０（ＦＩＧ０／０）における「Ｃｈａｎｇｅ ｆｌａｇ」フィールドの値が「０」であるときの「Ｏｃｃｕｒｒｅｎｃｅ ｃｈａｎｇｅ」フィールドにアンサンブルのリコンフィグレーションのバージョン情報が含まれた放送用データフレームを受信する過程と、受信した前記放送用データフレームから前記アンサンブルのリコンフィグレーションのバージョン情報を抽出する過程と、抽出したリコンフィグレーションのバージョン情報と、メモリ内に記録されているリコンフィグレーションのバージョン情報とを比較する過程と、前記比較の結果、両バージョン情報が異なる場合に、前記アンサンブルのサービス検索を行う共に、前記抽出したリコンフィグレーションのバージョン情報を前記メモリに記録する過程と、を含んで構成されることを特徴とする。

ここで、前記放送用データフレームにおいて、前記アンサンブルのリコンフィグレーションのバージョン情報は、例えば、前記アンサンブルでリコンフィグレーション（ｒｅｃｏｎｆｉｇｒａｔｉｏｎ）が発生するたびに変化する８ビットの値であり、前記「Ｏｃｃｕｒｒｅｎｃｅ ｃｈａｎｇｅ」フィールドに記録されるのが好ましい。

また、前記８ビットの値は、前記リコンフィグレーションが発生するたびに１ずつカウントアップされるのが好ましく、例えば、モジュロ演算を用いて「０」から「２５５」まで１ずつ増加される。

また、本発明に係るデジタルマルチメディア放送システムは、アンサンブルのリコンフィグレーションのバージョン情報を、放送用データフレームのＦＩＧタイプ０のエクステンション０（ＦＩＧ０／０）における「Ｃｈａｎｇｅ ｆｌａｇ」フィールドの値が「０」であるときの「Ｏｃｃｕｒｒｅｎｃｅ ｃｈａｎｇｅ」フィールドに含ませて送出するデジタルマルチメディア放送センターと、前記放送用データフレームを受信し、該放送用データフレームから前記アンサンブルのリコンフィグレーションのバージョン情報を抽出し、抽出したリコンフィグレーションのバージョン情報と、メモリ内に記録されているリコンフィグレーションのバージョン情報とを比較し、両バージョン情報が異なる場合に、前記アンサンブルのサービス検索を行うと共に、前記抽出したリコンフィグレーションのバージョン情報を前記メモリに記録する端末機と、を含んで構成されることを特徴とする。

ここで、前記デジタルマルチメディア放送センターは、リコンフィグレーションが発生するたびに前記リコンフィグレーションのバージョン情報を変化させ、その変化させたバージョン情報を前記「Ｏｃｃｕｒｒｅｎｃｅ ｃｈａｎｇｅ」フィールドに記録して送出する。

また、本発明に係るデジタルマルチメディア放送を受信可能な端末機は、アンサンブルのリコンフィグレーションのバージョン情報を記録するメモリと、受信した放送用データフレームのＦＩＧタイプ０のエクステンション０（ＦＩＧ０／０）における「Ｃｈａｎｇｅ ｆｌａｇ」フィールドの値が「０」であるときの「Ｏｃｕｕｒｒｅｎｃｅ ｃｈａｎｇｅ」フィールドに含まれたリコンフィグレーションのバージョン情報が、前記メモリ内に記録されているリコンフィグレーションのバージョン情報と異なる場合に、前記アンサンブルのサービス検索を行うための制御信号を出力すると共に、前記「Ｏｃｃｕｒｒｅｎｃｅ ｃｈａｎｇｅ」フィールドに含まれたリコンフィグレーションのバージョン情報を前記メモリに記録させる制御部と、を含んで構成されることを特徴とする。

ここで、前記放送用データフレームにおいて、前記アンサンブルのリコンフィグレーションのバージョン情報は、リコンフィグレーションが発生するたびに変化する８ビットの値であり、その変化した状態で前記「Ｏｃｃｕｒｒｅｎｃｅ ｃｈａｎｇｅ」フィールドに記録されたものであるのが好ましい。

また、前記８ビットの値は、リコンフィグレーションが発生するたびに１ずつカウントアップされるのが好ましく、例えば、モジュロ演算を用いて「０」から「２５５」まで１ずつ増加される。

本発明の他の目的、特徴及び利点については、図面に基づいた各実施形態の詳細な説明によって明らかになるだろう。

本発明に係るデジタルマルチメディア放送チャネルの管理方法、デジタルマルチメディア放送システム及びデジタルマルチメディア放送を受信可能な端末機によると、放送用データフレームのＦＩＧ０／０における「Ｃｈａｎｇｅ ｆｌａｇ」フィールドの値が「０」であるときの「Ｏｃｃｕｒｒｅｎｃｅ ｃｈａｎｇｅ」フィールドを利用してアンサンブルのリコンフィグレーションのバージョン情報を伝送する。
ここで、放送用データフレームに含まれるバージョン情報（アンサンブルのリコンフィグレーションのバージョン情報）が、記憶している対応バージョン情報と異なる場合に、該アンサンブル（内）のサービス検索を行うようにすることで、サービス構成情報の新たな形成（すなわち、サービスの再構築）を最小限に行うようにしつつ、例えば、視聴していない間にリコンフィグレーションの発生によって追加されたサービスがある場合でも、視聴するときには、該追加されたサービスについても速やかにこれを利用することができるという効果がある。

以下、本発明に係るデジタルマルチメディア放送システム及びデジタルマルチメディア放送チャネルの管理方法の好適な実施形態について、添付の図面に基づいて詳細に説明する。なお、添付図面に基づいて説明される本発明の構成及び作用は、本発明の一実施形態として説明されるものであり、これによって本発明の技術的思想、その核心構成及び作用が制限されることはない。

本実施形態において、アンサンブル（放送チャネル）に関する情報は、ＦＩＧ（Ｆｉｒｓｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｇｒｏｕｐ）のタイプ０フィールドのエクステンション（Ｅｘｔｅｎｓｉｏｎ）０にコーディングされる。
図１は、Ｅｕｒｅｋａ１４７規格で定義される伝送フレームのＦＩＧタイプ０の拡張（エクステンション）０の構造図である。以下、ＦＩＧタイプ０フィールドのエクステンション０、すなわち、ＦＩＧ０／０（ｔｙｐｅ ０ ｆｉｅｌｄ ｆｏｒ ｅｘｔｅｎｓｉｏｎ ０）にコーディングされたアンサンブル情報の各フィールドを説明する。

（１）ＥＩｄ（Ｅｎｓｅｍｂｌｅ Ｉｄｅｎｔｉｆｉｅｒ）フィールド
１６ビットのコードで構成されるフィールドであり、４ビットのカントリーＩＤ及び１２ビットのアンサンブルリファレンスからなる。

（２）変更フラグ（ｃｈａｎｇｅ ｆｌａｇ）フィールド
２ビットのフラグフィールドであり、サブチャネル及びサービスの少なくとも一方の構成が変更される場合に、その事実を知らせるものである。その種類は以下の表に示すとおりである。

（３）Ａｌフラグフィールド
１ビットのフラグフィールドであり、アンサンブルと共に、アクセス可能のアラームメッセージ（accessible alarming message）を表示するための信号として用いられる。ここで、この値が「０」のときは、アクセス不可能なアラームメッセージ（inaccessible alarming message）を表示し、この値が「１」のときは、アクセス可能なアラームメッセージを表示する。

（４）ＣＩＦ（Ｃｈａｎｎｅｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｆｌａｇ）カウントフィールド
このＣＩＦカウントフィールドの上位の値（５ビット）は、モジュロ−２０カウンター（０ ｔｏ １９）からなり、下位の値（８ビット）は、モジュロ−２５０カウンター（０ ｔｏ ２４９）からなる。

（５）変更発生（Ｏｃｃｕｒｒｅｎｃｅ ｃｈａｎｇｅ）フィールド
リコンフィグレーション発生後の新しいアンサンブル構成に適用される８ビットのフィールドであり、ＣＩＦカウントフィールドの下位の値を示す。

前記変更フラグフィールド（図１の「Ａ」）の値が「０（００）」である場合、すなわち、リコンフィグレーションが発生していないときには、変更発生フィールド（図１の「Ｂ」）は使用されない。したがって、この変更発生フィールド（Ｂ）は、何度も伝送されるにもかかわらず、全く使用されない場合も多い。このため、本発明では、かかる変更発生フィールドを利用する。以下、具体的に説明する。
まず、放送センター（放送局）は、リコンフィグレーションが発生するたびに、８ビットのバージョン値を、モジュラー−２５６を用いて、０から２５５まで１ずつ増加させる（つまり、バージョン値をカウントアップする）。かかる８ビットのバージョン値がリコンフィグレーションのバージョン情報であり、言い換えれば、アンサンブル構成のバージョン情報でもある。リコンフィグレーションは、アンサンブル構成、すなわち、放送チャネルの番組構成等を変更したときに、放送局側によってそのことを知らせるための手段でもある。放送局は、リコンフィグレーションが発生したとき、すなわち、変更フラグフィールド（Ａ）の値が「０（００）」でないときには、変更発生フィールド（Ｂ）に、ＣＩＦ（Ｃｈａｎｎｅｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｆｌａｇ）カウントの下位のフィールド値（８ビット）をコピーして６秒のタイマーとして用いる。
これにより、上述したように、受信装置は、視聴している放送チャネルのアンサンブル構成が変更されたときには、変更フラグフィールド（Ａ）の値によって、そのことを知ることができるとともに、該リコンフィグレーションを通じて６秒間新しい（変更後）ＭＣＩを得ることができる。

また、放送局側は、変更フラグフィールド（Ａ）の値が「０」のときの変更発生フィールド（Ｂ）を利用して上記バージョン値を伝送する。すなわち、上述したように、変更フラグフィールド（Ａ）の値が「０」であるときは、変更発生フィールド（Ｂ）は使用されない。そこで、この使用されない変更発生フィールド（Ｂ）に、リコンフィグレーションのバージョン値（アンサンブル構成のバージョン情報）を記録して伝送する。これにより、放送局は、受信装置に該放送チャネルにおけるリコンフィグレーションの最新のバージョン値（アンサンブル構成の最新バージョン）を知らせることができる。
一方、受信装置としての端末機は、放送チャネルの切り換え時に周波数（アンサンブル）の変更があると、受信した変更後の放送用データフレームのＦＩＧ０／０における変更フラグ（Ａ）の値を確認し、変更フラグ（Ａ）の値が「０」である場合には、変更発生フィールド（Ｂ）に記録されているリコンフィグレーションのバージョン値（アンサンブル構成のバージョン）と、メモリ内にすでに記録している対応バージョン値（記録している同じ放送チャネルのアンサンブル構成のバージョン）とを比較する。
そして、それらが同じ値である場合には、サービスアップデート（すなわち、変更後のアンサンブルのサービス検索）を行わないが、それらの値が異なる場合には、変更後のアンサンブルのサービス検索を行ってサービス構成を新しくする。すなわち、視聴する放送チャネルの切り換え等によって新たなアンサンブルが選択されるたびに、リコンフィグレーションのバージョンフィールド（すなわち、変更フラグ（Ａ）の値が「０」のときの変更発生フィールド（Ｂ））をチェックして該アンサンブルのアンサンブル構成のバージョンを確認し、該アンサンブルのサービス検索を行うか否か、さらに言えば、該アンサンブル内のサービス構成情報である多重化構成情報を形成するか否かを決定する。
この結果、端末機は、選択した放送チャネル（アンサンブル、周波数）のデータフレームの変更発生フィールドに記録されているバージョン値が、メモリ内に記録されている該放送チャネルのバージョン値と異なる場合には、該放送チャネルを視聴していないときにリコンフィグレーションが発生した（すなわち、アンサンブル構成が変更されている）と判断し、アンサンブルのサービス検索を実行して、新たなアンサンブル構成（サービス構成）に対応できるように、端末機側における該放送チャネルのサービス構成を再構築する。

図２は、本発明の実施形態に係るデジタルマルチメディア放送チャネルの管理方法を示すフローチャートである。
まず、デジタルマルチメディア放送センターでは、放送用データフレームのＦＩＧ０／０の変更フラグフィールドの値が「０」であると、リコンフィグレーションの発生に伴ってカウントアップされるリコンフィグレーションのバージョン情報（受信したアンサンブルのアンサンブル構成のバージョン情報に相当する）を変更発生フィールドに８ビット値で含ませて送出する。
受信装置（端末機）は、上記放送用データフレームを受信し（Ｓ１１）、この放送用データフレームのＦＩＧ０／０に含まれたリコンフィグレーションのバージョン情報を抽出する（Ｓ１２）。

ＦＩＧ０／０の変更フラグフィールドの値が「０」である場合には、すでに記録されている（保存されている）対応バージョン情報（すなわち、同一放送チャネルのリコンフィグレーションのバージョン情報）をメモリから読み出し、Ｓ１２で抽出したバージョン情報がこの読み出したバージョン情報と一致するか否かを判断する（Ｓ１３）。

両バージョン情報が一致していれば（バージョン値が同じであれば）、該放送チャネルを前回視聴してから今回視聴するまでの間にリコンフィグレーションが発生していない（つまり、アンサンブル構成が変更されていない）と判断し、サービスアップデートを行わない。一方、両バージョン情報が一致しなければ（バージョン値が異なれば）、該放送チャネルを前回視聴してから今回視聴するまでの間にリコンフィグレーションが発生していると判断し、新たなアンサンブル構成に対応すべく、アンサンブルのサービス検索（チャネル検索）を行い（Ｓ１４）、新しいアンサンブル構成に関する情報（アンサンブル内の新たなサービス構成情報）を形成してメモリに記録（保存）する（Ｓ１５）。なお、このとき、新たなリコンフィグレーションのバージョン情報（アンサンブル構成のバージョン情報）も同時に記録する。

デジタルマルチメディア放送システムは、大きく送信側と受信側とに分けられる。送信側としては、放送データフレームを伝送するデジタルマルチメディア放送センター（放送局）が該当し、受信側としては、衛星デジタル放送または地上デジタル放送（ＴＶ放送、ラジオ放送、または、デジタルマルチメディアデータ）を受信する端末機（すなわち、デジタルマルチメディア放送を受信可能な端末機）が該当する。
本発明を適用したデジタルマルチメディア放送システムにおいて、デジタルマルチメディア放送センターは、放送用データフレームのＦＩＧ０／０における変更フラグフィールドの値が「０」であるときには、リコンフィグレーション（アンサンブル構成）のバージョン情報を変更発生フィールドに８ビット値で含ませて送出する。デジタルマルチメディア放送を受信可能な端末機は、受信した放送用データフレームの変更フラグフィールド及び変更発生フィールドを確認し、該放送用データフレーム（具体的には、変更発生フィールド）に含まれるリコンフィグレーション（アンサンブル構成）のバージョン情報と内部メモリに記憶（保存）されている対応バージョン情報とを比較し、アンサンブルのサービス検索を行うか否かを決定する。アンサンブルのサービス検索を行うことによって、端末機は、該アンサンブル（放送チャネル）における現在のサービス構成情報（例えば、番組構成情報）を形成することができ、ユーザがこれを利用して提供されるサービスを速やかに利用することができるようになる。

図３は、本発明の実施形態に係るデジタルマルチメディア放送システムを受信可能な端末機の構成を概略的に示した図である。図３に示すように、端末機は、受信した放送チャネル（アンサンブル）のリコンフィグレーション（アンサンブル構成）のバージョン情報を記録（保存）するメモリ３０と、放送チャネルの切り換え時に周波数の変更（アンサンブルの変更）があると、受信した新たな放送チャネル（アンサンブル）のデータフレームに含まれるリコンフィグレーションのバージョン情報と、メモリ３０に記録（保存）されている対応バージョン情報（該放送チャネルに係るリコンフィグレーションのバージョン情報）とを比較し、その比較の結果、両バージョン情報が一致しないと、変更後の放送チャネル（アンサンブル）のサービス検索（チャネル検索）を行うための制御信号をデジタル放送（ＤＭＢ）受信部１０に出力する制御部２０と、を含んで構成される。

リコンフィグレーションのバージョン情報は、受信した放送データフレームのＦＩＦ０／０における変更発生フィールドに８ビット値として含まれる。放送センターは、アンサンブル内のサービス構成（すなわち、放送チャネルのサービス（番組）構成）に変更が発生するたびに、すなわち、リコンフィグレーションが発生するたびに、モジュロ演算を用いて「０」から「２５５」まで１ずつ増加させた値をリコンフィグレーション（アンサンブル構成）のバージョン情報（値）として含ませて伝送する。

端末機において、制御部２０は、視聴する放送チャネルを変更するためにアンサンブルを切り換える（新たなアンサンブルを選択する）たびに、受信した放送用データフレームのＦＩＧ０／０における変更発生フィールド（リコンフィグレーションのバージョンフィールド）をチェックし、メモリ３０に記録（保存）されている対応バージョン情報（値）と比較する。両バージョン情報が異なると、該アンサンブルのサービス検索を実行してサービス構成を再構築する。そして、制御部２０は、新しいアンサンブルのサービス検索結果であるサービス再構築結果（例えば、新たな番組構成情報等）及びリコンフィグレーションのバージョン情報（アンサンブル構成のバージョン情報）をメモリ３０に記録（保存）する。

以上説明した内容を通して、本発明の技術思想から逸脱しない範囲で多様な変更及び修正が可能であることは、当業者にとって明らかである。したがって、本発明の技術的範囲は、明細書の詳細な説明に記載された内容に限定されるものではなく、特許請求の範囲によって定められるべきである。

ヨーロッパ標準方式で定義された伝送フレームのタイプ０のエクステンション０（ＦＩＧ０／０）の構造を例示した図である。 本発明の実施形態に係るデジタルマルチメディア放送チャネルの管理方法を示すフローチャートである。 本発明の実施形態に係るデジタルマルチメディア放送を受信可能な端末機の構成を概略的に示した図である。 リコンフィグレーションが発生した場合のアンサンブル構成（サービス構成）の例を示した図である。 同じくリコンフィグレーションが発生した場合のアンサンブル構成（サービス構成）の例を示した図である。

符号の説明

１０ デジタルマルチメディア（ＤＭＢ）受信部
２０ 制御部
３０ メモリ

Claims (9)

1. デジタルマルチメディア放送センターから送出され、ＦＩＧタイプ０のエクステンション０（ＦＩＧ０／０）における「Ｃｈａｎｇｅ ｆｌａｇ」フィールドの値が「０」であるときの「Ｏｃｃｕｒｒｅｎｃｅ ｃｈａｎｇｅ」フィールドにアンサンブルのリコンフィグレーションのバージョン情報が含まれた放送用データフレームを受信する過程と、
   受信した前記放送用データフレームから前記アンサンブルのリコンフィグレーションのバージョン情報を抽出する過程と、
   抽出したリコンフィグレーションのバージョン情報と、メモリ内に記録されているリコンフィグレーションのバージョン情報とを比較する過程と、
   前記比較の結果、両バージョン情報が異なる場合に、前記アンサンブルのサービス検索を行う共に、前記抽出したリコンフィグレーションのバージョン情報を前記メモリに記録する過程と、
   を含んで構成されることを特徴とするデジタルマルチメディア放送チャネルの管理方法。
2. 前記放送用データフレームにおいて、前記アンサンブルのリコンフィグレーションのバージョン情報は、前記「Ｏｃｃｕｒｒｅｎｃｅ ｃｈａｎｇｅ」フィールドに、８ビットの値として含まれることを特徴とする請求項１に記載のデジタルマルチメディア放送チャネルの管理方法。
3. 前記８ビットの値は、リコンフィグレーションが発生するたびに０から２５５まで１ずつカウントアップされることを特徴とする請求項２に記載のデジタルマルチメディア放送チャネルの管理方法。
4. アンサンブルのリコンフィグレーションのバージョン情報を、放送用データフレームのＦＩＧタイプ０のエクステンション０（ＦＩＧ０／０）における「Ｃｈａｎｇｅ ｆｌａｇ」フィールドの値が「０」であるときの「Ｏｃｃｕｒｒｅｎｃｅ ｃｈａｎｇｅ」フィールドに含ませて送出するデジタルマルチメディア放送センターと、
   前記放送用データフレームを受信し、受信した放送用データフレームから前記アンサンブルのリコンフィグレーションのバージョン情報を抽出し、抽出したリコンフィグレーションのバージョン情報と、メモリ内に記録されているリコンフィグレーションのバージョン情報とを比較し、両バージョン情報が異なる場合に、前記アンサンブルのサービス検索を行うと共に、前記抽出したリコンフィグレーションのバージョン情報を前記メモリに記録する端末機と、
   を含んで構成されることを特徴とするデジタルマルチメディア放送システム。
5. 前記デジタルマルチメディア放送センターは、リコンフィグレーションが発生するたびに前記リコンフィグレーションのバージョン情報を変化させ、その変化させたバージョン情報を前記「Ｏｃｃｕｒｒｅｎｃｅ ｃｈａｎｇｅ」フィールドに記録して送出することを特徴とする請求項４に記載のデジタルマルチメディア放送システム。
6. 前記デジタルマルチメディア放送センターは、リコンフィグレーションが発生するたびに８ビットの値とした前記リコンフィグレーションのバージョン情報を０から２５５まで１ずつカウントアップすることを特徴とする請求項５に記載のデジタルマルチメディア放送システム。
7. デジタルマルチメディア放送を受信可能な端末機であって、
   アンサンブルのリコンフィグレーションのバージョン情報を記録するメモリと、
   受信した放送用データフレームのＦＩＧタイプ０のエクステンション０（ＦＩＧ０／０）における「Ｃｈａｎｇｅ ｆｌａｇ」フィールドの値が「０」であるときの「Ｏｃｕｕｒｒｅｎｃｅ ｃｈａｎｇｅ」フィールドに含まれたリコンフィグレーションのバージョン情報が、前記メモリ内に記録されているリコンフィグレーションのバージョン情報と異なる場合に、前記アンサンブルのサービス検索を行うための制御信号を出力すると共に、前記「Ｏｃｃｕｒｒｅｎｃｅ ｃｈａｎｇｅ」フィールドに含まれたリコンフィグレーションのバージョン情報を前記メモリに記録させる制御部と、
   を含んで構成されることを特徴とする端末機。
8. 前記放送用データフレームにおいて、前記アンサンブルのリコンフィグレーションのバージョン情報は、リコンフィグレーションが発生するたびに変化する８ビットの値であり、その変化した状態で前記「Ｏｃｃｕｒｒｅｎｃｅ ｃｈａｎｇｅ」フィールドに記録されたものであることを特徴とする請求項７に記載の端末機。
9. 前記８ビットの値は、リコンフィグレーションが発生するたびに０から２５５まで１ずつカウントアップされるものであることを特徴とする請求項８に記載の端末機。
   

Images