JP4014223B2 - 受信機及び改善されたフォーマットでデータを提供する方法 - Google Patents
受信機及び改善されたフォーマットでデータを提供する方法 Download PDFInfo
- Publication number
- JP4014223B2 JP4014223B2 JP51410097A JP51410097A JP4014223B2 JP 4014223 B2 JP4014223 B2 JP 4014223B2 JP 51410097 A JP51410097 A JP 51410097A JP 51410097 A JP51410097 A JP 51410097A JP 4014223 B2 JP4014223 B2 JP 4014223B2
- Authority
- JP
- Japan
- Prior art keywords
- sequence
- data
- digital
- frame
- receiver
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H40/00—Arrangements specially adapted for receiving broadcast information
- H04H40/18—Arrangements characterised by circuits or components specially adapted for receiving
- H04H40/27—Arrangements characterised by circuits or components specially adapted for receiving specially adapted for broadcast systems covered by groups H04H20/53 - H04H20/95
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04H—BROADCAST COMMUNICATION
- H04H2201/00—Aspects of broadcast communication
- H04H2201/10—Aspects of broadcast communication characterised by the type of broadcast system
- H04H2201/20—Aspects of broadcast communication characterised by the type of broadcast system digital audio broadcasting [DAB]
Description
【技術分野】
【０００１】
本発明は、ディジタル送信信号を受信する受信機であって、前記ディジタル送信信号は、チャネル符号化されたディジタルデータシーケンスを有し、前記ディジタルデータシーケンスは、種々のデータタイプの複数のシーケンスを有し、前記種々のデータタイプの複数のシーケンスのうちの少なくとも一つのシーケンスは、前記種々のデータタイプの複数のシーケンスのうちの少なくとも一つの他のシーケンスと共に前記ディジタルデータシーケンス内に、前記少なくとも一つのシーケンスを取り出すには、前記少なくとも一つの他のシーケンスを取り出す必要があるように埋め込まれていて、
− 受信した前記ディジタル送信信号をチャネルデコードし前記ディジタルデータシーケンスを形成する手段と、
− 前記ディジタルデータシーケンス内に埋め込まれている前記種々のデータタイプの複数のシーケンスのうちの前記少なくとも一つのシーケンスを取り出す手段と、
− 前記受信されチャネルデコードされたディジタル送信信号から前記ディジタルデータシーケンスの少なくとも一部を当該受信機の出力に供給する手段とを有する受信機に関する。
【０００２】
本発明はさらに、ディジタルデータシーケンスの少なくとも一部を供給する方法であって、前記ディジタルデータシーケンスは、種々のデータタイプの複数のシーケンスを有し、前記種々のデータタイプの複数のシーケンスのうちの少なくとも一つのシーケンスは、前記種々のデータタイプの複数のシーケンスのうちの少なくとも一つの他のシーケンスと共に前記ディジタルデータシーケンス内に埋め込まれている方法に関する。
【背景技術】
【０００３】
冒頭による受信機は、１９９５年２月オランダのフィリップス・コンシューマ・エレクトロニクス社出版のパンフレット「ＤＡＢ４５２ディジタル・オーディオ放送試験受信機(DAB452 Digital Audio Broadcasting test receiver)”から既知である。この既知の受信機においては、受信したディジタルオーディオ放送信号が、ディジタルデータシーケンスに、周波数変換され、高速フーリエ変換装置により復調され、インターリーブ解除され、デコードされる。このデータシーケンスは、例えばオーディオフレームを有する主サービスチャネルデータ、高速情報チャネルデータ等の種々のデータタイプの複数のシーケンスを有するものである。主サービスチャネル内のオーディオフレームは、オーディオデータ及びプログラムに関連付けられたデータ（ＰＡＤ）を有する。オーディオフレーム内のオーディオデータの最大量は、該フレーム内のＰＡＤの量に依存する。すなわち、ＰＡＤは、オーディオデータと共に前記ディジタルデータシーケンス内に埋め込まれている。前記既知のＤＡＢ受信機は、これら目的のために、オーディオデコード手段を有する。このオーディオデコード手段は、前記オーディオフレームからオーディオデータを取り出すだけではなく、これらオーディオフレームからＰＡＤも取り出す。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、改善された受信機及びディジタルデータシーケンスを供給する改善された方法を提供することにある。
【課題を解決するための手段】
【０００５】
本発明による受信機は、前記供給手段が、前記埋め込まれている少なくとも一つの他のシーケンスと別個とされた前記取り出された少なくとも一つのシーケンスを前記ディジタルデータシーケンスの前記少なくとも一部に付加するように構成されることを特徴とする。本発明は、前記ディジタルデータシーケンスを受信する周辺装置が、埋め込まれたデータを取り出すためのデコード手段を常に有してはいないことの認識に基づいている。すなわち、これら周辺装置は、このようなデータを得るための余分な分析及び取り出し手段を持つ必要がある。固定されたフォーマットのデータストリームに前記少なくとも一つのシーケンスを２回付加することにより、周辺装置は、前記ディジタルデータシーケンスから前記少なくとも一つのシーケンスをより容易に識別し取り出すことができ、これにより、該周辺装置の複雑さを減少させることができる。例えば、ＤＡＢ受信機においては、オーディオフレームをデコードするためのデコード手段が与えられる。これらオーディオデコード手段においては、ＰＡＤも同様にデコードされる。このように取り出されたＰＡＤはＤＡＢ受信機内で既に利用可能であるため、これは、前記供給手段にＰＡＤを供給するために有利に使用することができる。
【０００６】
本発明のある実施例は、前記供給手段は、前記少なくとも一つのシーケンス内のデータタイプを識別してデータタイプ識別子を生成し、該データタイプ識別子を前記取り出された少なくとも一つのシーケンスに付加するように動作することを特徴とする。この手段により、前記ディジタルデータシーケンス内の前記少なくとも一つのシーケンスが容易に認識できる。これは、データが、パケット自体で情報を含み、ヘッダを有する、これらパケットに構築されるようなディジタルデータシーケンスにおいて特に有利である。
【０００７】
本発明のある実施例は、前記供給手段は、前記少なくとも一つのシーケンスの長さを識別して長さインジケータを生成し、該長さインジケータを前記取り出された少なくとも一つのシーケンスに付加するように動作することを特徴とする。この手段により、前記少なくとも一つのシーケンスがどの様な長さであるかを周辺装置が知ることができる。これは、前記少なくとも一つのシーケンスが可変の長さを持つ可能性がある場合特に有利であり、データがパケットに構築される場合非常に役立つ。
【０００８】
本発明のある実施例は、前記ディジタル送信信号が、ディジタルオーディオ放送信号であり、前記少なくとも一つのシーケンスが、プログラムに関連付けられたデータであることを特徴とする。本発明によるこれら手段は、前記少なくとも一つのシーケンスがプログラムに関連付けられたデータであるような、ＤＡＢ受信機における適用に関して特に有利である。
【０００９】
本発明のある実施例は、前記ディジタルデータシーケンスの少なくとも一部が、ＩＥＣ９５８フォーマットにより構築されることを特徴とする。これは、ＤＡＢデータシーケンスが非常に特殊なフォーマットを持つが、ＩＥＣ９５８インタフェースはより共通的に使用されるため、周辺装置と共により標準化されたインタフェースを実現する。
【００１０】
本発明のある実施例は、前記供給手段が、前記少なくとも一つのシーケンスを前記ＩＥＣ９５８フォーマットでユーザデータチャネルに付加するように構成されることを特徴とする。ＩＥＣ９５８インタフェース内のユーザデータチャネルは、複数の目的に対して利用可能である。ＰＡＤを搬送するためのユーザデータチャネルを選択することにより、取り出されたＰＡＤが、ＩＥＣ９５８フォーマットの通常のフレーム構造に付加される必要がなく、すなわち、オリジナルのデータに関してデータ容量をセーブする。
【００１１】
本発明の上述の目的及び特徴は、以下の図を参照して、以下の好ましい実施例の記載からより明白になるであろう。
【発明を実施するための最良の形態】
【００１２】
図中、同じ要素には同じ参照番号がつけてある。
【００１３】
第１図は、本発明によるディジタル信号を受信する受信機の一実施例の図である。受信アンテナ２は、当該受信機の第１の入力に接続されている。この受信機の入力は、フロント・エンド・ユニット４に接続されている。フロント・エンド・ユニット４の出力は、ＦＦＴプロセッサ６の入力に接続されている。ＦＦＴプロセッサ６の出力は、チャネル・デコーダ８の入力に接続されている。
【００１４】
ディジタル信号を受信するための受信機は、ディジタル・オーディオ放送システム（ＤＡＢ）で使用することができる。複数のキャリアを有し、これらキャリア上でディジタル信号は変調されているようなＯＦＤＭ信号が、前記受信機により受信され、フロント・エンド・ユニット４で増幅され、周波数変調される。次いで、フロント・エンド・ユニット４の出力信号は、ＦＦＴプロセッサ６に送られ、前記ディジタル信号を得るために復調される。ＦＦＴプロセッサ６の出力において、コード化され、インタリーブされた信号が得られる。ＦＦＴプロセッサ６はまた、フロント・エンド・ユニット４の同期を行うために、信号プロセッサ１４に情報を送る。この信号プロセッサはまた、受信した送信の電界強度及び該送信の識別、送信識別情報すなわちＴＩＩに関する、ＦＦＴプロセッサ６からの情報を取り出すこともできる。このＴＩＩは、各ＤＡＢフレームの開始時のヌル記号に存する。ＦＦＴプロセッサ６の出力における信号は、再構築されたディジタル信号を得るために、デコーダ８によりインタリーブ解除され、デコードされる。例えば、フィリップスのＳＡＡ２５００のようなオーディオ・デコーダが、オーディオ・フレームを有する前述のディジタル信号をデコードするために、デコーダ８の出力に結合されている。第１の出力において、オーディオ・デコーダ１０は、オーディオ・フレームに埋め込まれているプログラムに関連付けられたデータ３６、すなわち、ＰＡＤを供給する。このＰＡＤは、制御ユニット１２に送られ、さらに処理される。第２の出力において、オーディオ・デコーダ１０はオーディオ・データ３２を供給する。制御ユニット１２はさらに、受信機の同調及びデコーダ８でのデコード処理を制御する。制御ユニット１２は、ユーザから情報を受信し、情報をユーザに供給するデータ３４を用いるインターフェースを備えている。
【００１５】
第２図は、ＤＡＢ送信フレームのである。ＤＡＢフレームは３つのフィールドを含む。すなわち、同期チャネルＳＣ、高速情報チャネルＦＩＣ及び主サービス・チャネルＭＳＣである。ＦＩＣは、多数の高速情報ブロックＦＩＢを含む。ＦＩＢの数は、ＤＡＢ送信モードに依存する。モードＩの場合には、ＤＡＢフレームは、１２個のＦＩＢを含み、モードＩＩの場合には、３個のＦＩＢ、モードＩＩＩの場合には、４個のＦＩＢを含む。主サービスチャネルは、多数の共通インターリーブフレームＣＩＦを有する。この数も、ＤＡＢ送信モードに依存する。モードＩの場合には、ＤＡＢフレームは、４個のＣＩＦを、モードＩＩの場合には、１個のＣＩＦを、モードＩＩＩの場合には、１個のＣＩＦを含む。モードＩの場合には、第１の３個のＦＩＢが、第１のＣＩＦに割り当てられ、第２の３個のＦＩＢが、第２のＣＩＦ等に割り当てられる。主サービス・チャネルは、それぞれがサブチャネル識別番号ＳｕｂＣｈＩｄを持つ、多数のサブチャネルに分割される時間的にインタリーブされたデータ・チャネルであり、各サブチャネルは、オーディオ及びデータ等の一つ以上のサービス要素を搬送することができる。ＭＳＣは、６４ビットの複数の容量ユニットにさらに分割され、サブチャネルは、これら容量ユニットの一つ以上を占有することができる。サブチャネルの組織及びこれらサブチャネルの容量ユニットにおける位置は、他のアイテムと一緒にＦＩＣにより送信される。ＤＡＢ送信フレーム、該フレームの構造及び内容の詳細な説明については、１９９５年にソフィア・アンチポリス所在のヨーロッパ遠隔通信規格協会が発行した「無線放送システム；移動、携帯及び定置受信機に対するディジタル・オーディオ放送（ＤＡＢ）」ＥＴＳ３００ ４０１を参照されたい。
【００１６】
第１図の受信機においては、現在使用されているデコーダ８は、ＤＡＢシーケンス全部をデコードすることができず、ＤＡＢデータの選択された部分しかデコードできない。例えば、ユーザは、制御ユニット１２に、例えば、「無線３」のようなあるプログラムからのオーディオ・データを、オーディオ・デコーダ１０に供給するように命令する。次いで、制御ユニット１２は、ＦＩＣを分析し、「無線３」のプログラムが、主サービス・チャネルのどのサブチャネル上に存在するのかを決定する。次いで、制御ユニット１２は、どの容量ユニットが上記サブチャネルに割り当てられているか、例えば、ＣＵ６、７及び８を決定する。次いで、制御ユニット１２は、デコーダ８に、デコードし、ＣＵ６、７及び８からデコードしたデータを出力し、デコードしたデータがあることを知らせるために、第１のウィンドウ信号を活性化するように命令する。オーディオ・デコーダ１０は、上記データ及びウィンドウ信号を受信し、該出力に含まれるオーディオ・データを供給する。すなわち、デコーダ８は、限られたデータ量しか供給できない。将来のデコーダ８は、ＤＡＢ信号から完全なデコードされたデータをＤＡＢ信号から供給することができるであろう。
【００１７】
本発明によれば、第１図の受信機はさらに、
− 第１のシーケンスのデータを受信するためデコーダ８の出力に結合される第１の入力（前述のように、このシーケンスは、デコーダ８に依存して、完全なＤＡＢデータ・シーケンスか少なくとも該ＤＡＢデータ・シーケンスの一部の何れかを有する）
− 第２のタイプのフレームで構築された第２のシーケンスのデータ３６を供給するための出力（第１のタイプのフレームのフレーム長は、第２のタイプのフレームのフレーム長とは異なる。第２のシーケンスは、少なくとも２つの別個のシーケンスを有する。これら別個のシーケンス各々は、異なるデータ・タイプのために予約され、第２のタイプのフレーム内に配置されている。ここで、第２タイプの各フレームは、第２のシーケンス内のこれら別個のシーケンスを識別するためのフレーム・タイプ識別子を含む。）
を持つ変換手段１６を有している。
【００１８】
本発明の他の態様によれば、変換手段１６は、ＤＡＢ信号のヌル記号に含まれているＴＩＩを受信するため、信号プロセッサ１４の第２の出力に結合されている第２の入力を持っている。この信号プロセッサ１４はまた、ヌル記号のＦＦＴから測定した相対的な電界強度を供給し、必要ならば、選択されたキャリヤ・ペアの同相及び直角位相成分の値も供給する。次いで、変換手段１６は、信号プロセッサ１４により供給されるＴＩＩ及び他のデータを、第２のシーケンスに挿入することができる。その方法については、第２のシーケンス内のフレームの内容について扱う際にさらに詳細に説明する。
【００１９】
前述の態様とは別個のものとさえ見られるかもしれない、本発明の他の態様によれば、変換手段１６が、ＰＡＤを供給するオーディオ・デコーダ１０の第２の出力に結合されている第３の入力を持つことである。次いで、このＰＡＤも、前記シーケンス中に挿入される。この挿入は、ＴＩＩ及び関連データの挿入方法と同様に行うことができ、ＰＡＤに対して個別のデータ・タイプ識別子を供給し、個別のパケット内にＰＡＤを挿入する。これについてはこれ以上詳細に説明しない。後で詳細に説明する好適な実施例においては、第２のタイプのフレームが、ＩＥＣ９５８フォーマットによるフレームである場合、ＰＡＤはユーザ・データ・チャネルの第２のシーケンス内に挿入される。
【００２０】
変換手段１６は、供給手段とも呼ばれる。何故なら、変換手段は、実際に外部、例えば、周辺装置等に第２のシーケンスのデータを供給するからである。
【００２１】
第３Ａ図は、本発明の一実施例による第２のシーケンスのフレームの図である。本発明においては、第１のシーケンスのデータは、該第１のシーケンスのフレーム長とは異なるフレーム長を有する第２のシーケンスのデータに変換される。一実施例においては、第２のシーケンスのフレーム長は、２４ビットの長さに選択され、そのうち最初の２０ビットは、すなわち、ｂ０．．ｂ１９ビットは、データ（ＤＴ）用に予約され、ｂ２０．．ｂ２３ビットは、フレーム・タイプ識別子（ＦＴＩ）用に予約されている。このように選択することにより、第２のシーケンスのフレームをＩＥＣ９５８規格によるサブフレームに組み込むことができる。この規格の詳細については、１９８９年に、スイスの国際電子技術委員会、中央部局が発行した国際規格ＩＥＣ９５８の「ディジタル・オーディオ・インターフェース」の文献を参照されたい。
【００２２】
第３Ｂ図は、ＩＥＣ９５８サブフレームの図である。ＩＥＣ９５８は、４ビットのプリアンブルＰＲ、補助データＡＸＤ用の４ビット・フィールド、オーディオ・データＡＤ用の２０ビット・フィールド及び４つの１ビット・フィールド、すなわち、妥当性フラグ・ビットＶ、ユーザ・データ・チャネル・ビットＵ、チャネル状態ビットＣ、及びパリティ・ビットＰを含む。チャネル状態ビットＣは、１ビットのチャネル状態語を含み、チャネルを通して送られるデータの情報を与える。ユーザ・データ・チャネル・ビットＵは、１ビットのユーザ・データ・チャネルを含む。第２のシーケンスのフレームが、ＩＥＣ９５８サブフレームに組み込まれている場合には、該フレームはビット位置ａ４．．ａ２７に収容される。この場合、妥当性フラグ・ビットＶは、オーディオ・デコーダにより誤ってデコードされないように、「１」に設定されるべきである。チャネル状態語においては、状態が「非オーディオ」（バイト０のビットを１）に設定され、「コピーライト」主張（バイト０のビット２＝「０」）されるべきである。バイト０のビット３、４及び５は、「０００」に設定され、バイト０のビット６及び７は、モード０（＝「００」）に設定されるべきである。ディジタル・オーディオの放送受信用のカテゴリコード「００１」が、使用されるべきである（バイト１のビット０、１、２＝「００１」）。発生状態ビットは、「オリジナル」（バイト１のビット７＝「０」）に設定されるべきである。バイト２においては、ソース番号及びチャネル番号が、「無指定」（バイト２＝「００００００００」）に設定されるべきである。サンプリング周波数は、４８ｋＨｚ（バイト３のビット０、１、２、３＝「０１００」）であるべきである。±１０００ｐｐｍのクロック精度が、「レベルＩＩ」（バイト３のビット４、５＝「００」）であるべきである。すなわち、チャネル状態語の最初の４つのバイトを次のように、すなわち、バイト０を「０１００００００」、バイト１を「００１００１００」、バイト２を「００００００００」、バイト３を「０１００００００」に設定することが推奨される。バイト１のビット３、４、５、６は、「００１０」に設定される。これは、入力「ＤＡＢ」がカテゴリ「放送受信」に規定されるべきであることを提示している。
【００２３】
表１は、フレーム・タイプ識別子のビットｂ２０．．ｂ２３の値の例である。
【表１】
【００２４】
フレーム・タイプ識別子の値、「０００１」、「ＸＸ１０］、「０１００」及び「０１１１」は、パケットでのデータ転送を示す。値「０００１」及び「０１１１」は、パケットの始まりを通知し、この値「０１１１」はさらに、パケット内のデータ・タイプも識別している。値「ＸＸ１０］は、パケットの継続を通知し、値「０１００」は、パケットの終わりを示す。パケットでのデータ転送の利点は、使用されるオーバーヘッドが少なくて済むということである。何故なら、例えば、データ・タイプ及びパケットの長さを通知するヘッダ・フレーム（及びあれば付随(trailer)フレーム）しかオーバーヘッドとして使用されないからである。この高容量データ転送は、完全なＤＡＢデータをデコードすることができる将来のチャネル・デコーダ８と組合わせる場合に役立つ。
【００２５】
値「ＸＸ１０］のフレーム・タイプ識別子は、ビットｂ２０及びｂ２１の値は無視してよいということを意味する。これは、ビットｂ０．．ｂ１９により供給された２０個のデータ・ビットでは不十分で、１つ以上のデータ・ビットが継続しているフレーム内に必要とされる場合に特に役立つ。この場合、ビットｂ２０及びｂ２１が、データ・ビットに追加され、それにより２２ビットのデータ・フィールドが実現される。ビットｂ２０及びｂ２１は、パケット内のデータ・タイプに依存して、データ・ビットとしては使用されない場合、これらビットは、好適には「００」に設定されるべきである。例えば、ＭＳＣデータの場合、ビットｂ２０及びｂ２１は、データ・フィールドに追加される。一方、ＦＩＣまたはＴＩＩデータの場合、ビットｂ２０及びｂ２１は、フレーム・タイプ識別子の一部である。
【００２６】
値「１１１１」のフレーム・タイプ識別子は、データ及び該データのデータ・タイプ識別子を含むフレームを通知する。各フレームがこのような識別子を含んでいるので、各フレームを相互に独立して処理することができる。これは、今全てのフレームがデータ・タイプ識別子を含む必要があるので多量のオーバーヘッドを犠牲にするが、受信側におけるフレーム処理を非常に容易にする。
【００２７】
値「００００」のフレーム・タイプ識別子は、ｂ０．．ｂ１９の全ての位置に置いて通常論理値「０」しか持たない、パディング・フレームを通知する。このフレーム・タイプは、転送できる状態のデータがない場合に使用され、データが存在しない場合、第２のシーケンスにおける継続的なフレームの流れを確実にする。
【００２８】
値「０１０１」のフレーム・タイプ識別子は、第１のシーケンスにおけるフレームの開始、すなわち、例えば、論理ＤＡＢフレームの開始を知らせる。このフレームは、残りのビット位置ｂ０．．ｂ１９上にいくつかの情報を含ませることができる。さらに、ビットｂ０．．ｂ３は、同期フレームコンテンツインジケータＳＦＣＩ用に予約され、例えば「０００１」の値を持つような場合、コンテンツフィールドＣＦ、すなわち、残りのビット、ｂ４．．ｂ１９は、過去のＤＡＢフレームのＦＩＣの再符号化により検出された訂正エラーの数を含むことを指示する。他のビットｂ０．．ｂ３の値は予約されている。
【００２９】
（「ＸＸ１０］及び「０１００」に関連付けられる、値「０１１１」のＴＩＩフレーム・タイプ識別子、及び値「１１１１」のフレーム・タイプ識別子を用いる）低容量データ転送の場合、フレーム・タイプ識別子の値が「１１１１」であるフレームは、例えば、ＩＥＣ９５８フォーマットのチャネルＡを通じて送信され、あるならば、次いで、ＴＩＩフレームが、ＩＥＣ９５８フォーマットのチャネルＢを通じて送信される。低容量データ伝送は、限られたデータ量しか搬送される必要がないので、現在用いられているチャネル・デコーダ８と組合わせた場合特に有用である。
【００３０】
このように、変換手段１６は、ＴＩＩデータ及び関連付けられるデータを、高容量データ転送に対してパケット内に収容するか、低容量データ転送に対してパケット内に収容する。ＭＳＣデータ及びＦＩＣデータ等の他のデータに対しても同様である。上記の説明は単に例示としてのものに過ぎず、本発明を制限するものでないことは明らかであろう。
【００３１】
表１に示すように、低容量データ転送に対するフレーム・タイプ識別子がある。これらのフレーム・タイプ識別子は、（パケットの残りを指示するため関連付けられる値「ＸＸ１０」及び「０１００」と共に）「１１１１」及び「０１１１」の値を有する。
【００３２】
「１１１１」の値のフレーム・タイプ識別子を持つフレームは、好適には、第３Ａ図のフレーム内のビット位置ｂ８．．ｂ１５に位置する８ビットのデータＤＴを有する。データ・タイプ識別子ＤＴＩは、表２に示すように、データの出所を示すため及びフレームのビットｂ０．．ｂ５内の６ビット・フィールドＩＤＦが使用されていることを示すために、ビットｂ６及びｂ７の位置で該フレームに追加される。
【表２】
【００３３】
サブチャネル識別子ＳｕｂＣｈＩｄは、すでに説明したように、ＭＳＣ内のサブチャネルを識別するための識別子である。第１図のチャネル・デコーダ８は、ＤＡＢデータ・シーケンスと共にウィンドウ信号を供給することができる。このようなウィンドウ信号は、あるデータ・タイプに属するデータがＤＡＢデータ・シーケンス内に存在する間活性化される。例えば、制御ユニットは、特定のサブチャネルがＭＳＣの容量ユニット６、７及び８内に存する限り、ＦＩＣから得られる。ここで、制御ユニットは、チャネル・デコーダ８に、容量ユニット６、７及び８からのデコードされたデータがチャネル・デコーダ８の出力に存在する間、ウィンドウ信号１を活性化するように指示する。ここで、ウィンドウ信号１は、当該出力に容量ユニット６、７及び８からデコードされたデータが存在することを通知し、前記制御ユニットはこのデータが特定のサブチャネル番号に関連付けられていることが分かる。フレーム・フォーマットにおいて、フレーム内のビット位置ｂ１６．．ｂ１９に、４ビットのウィンドウ信号識別子を設けることにより、前記チャネル・デコーダからの１６個の異なるウィンドウ信号を識別することができる。ウィンドウ信号は、データがＭＳＣからのものである場合には、フレームのビット位置ｂ０．．ｂ５における識別フィールド内にサブチャネル識別子を挿入することにより、サブチャネルとリンクさせることができる。他の場合には、識別フィールドは予約されている。ウィンドウ信号の１つを、パディングに対して使用し、獲得できるデータがないことを示しても良い。
【００３４】
値が「０１１１」のフレーム・タイプ識別子は、低容量データ転送に対するＴＩＩ情報パケットのヘッダを示し、すなわち、データタイプ識別子としても機能する。「ＸＸ１０」及び「０１００」の値のフレームタイプを持つフレームが、データを搬送する。（値が「０１１１」である）ヘッダ・フレーム内には、ビット位置ｂ１１．．ｂ１５の５ビットワードが、受信される送信数（ＮＲＴ）を指示するために予約されている。ＮＲＴは、１−２４の範囲内とすることができる。他の値は予約されている。（ＮＲＴ−１）個の継続フレーム及び一個の付随フレームがあり、これらフレームは以下のように満たされる。これらのフレーム各々は、ビット位置ｂ８．．ｂ１２に５ビットのサブ識別子を、ビット位置ｂ１３．．ｂ１９に７ビットの主識別子を含み、主識別子及びサブ識別子は、１９９５年にソフィア・アンチポリス所在のヨーロッパ遠隔通信規格協会発行の「移動、携帯、定置受信機に対するディジタル・オーディオ放送（ＤＡＢ）」、ＥＴＳ３００ ４０１の「無線放送システム」の文献の８．１．９項に記載されている。さらに、微弱の信号を指示する「００１」から非常に強い信号を示す「１１１」までの範囲の相対的な電界強度を指示するために、３ビット（ｂ５．．ｂ７）が予約されている。値「０００」は、「信号が送られていない」ことを示す。残りのビット、ｂ０．．ｂ４は予約されている。すでに説明したように、最後のデータ・フレームは、値「０１００」のフレーム・タイプ識別子を有するが、特定の付随フレームは必要ないので、前記継続フレームと同じ種類のデータを含む。
【００３５】
低容量データ転送の場合には、ＴＩＩフレームを、フレーム・タイプ１１１１のデータ・フレームと変更することができる。パディング・フレームは自由に挿入することができる。
【００３６】
低容量データ伝送の場合には、ＴＩＩフレームをフレームタイプ「１１１１」のデータ・フレームと交互に使用できる。パディング・フレームは自由に挿入することができる。
【００３７】
値が「０００１」であるフレームタイプ識別子は、高容量データ伝送用のパケットのヘッダ・フレームを識別する。表３に示すように、この目的のために、ヘッダ・フレーム内のビット、ｂ１８およびｂ１９は、データタイプ識別子を形成し、パケット内に含まれるデータタイプを示すために予約される。
【表３】
【００３８】
値が「ＸＸ１０］のフレームタイプ識別子は、継続フレーム、すなわち、パケットの一部であるフレームを示し、値が「０１００」のフレームタイプ識別子は、パケットの終わりを示す付随フレームと見なすことができる。
【００３９】
ＭＳＣデータが送信されている場合には（ｂ１８＝０ ｂ１９＝１）、ヘッダ・フレームは、ビット、ｂ０．．ｂ１１に、ＲＤＩフレームの数Ｍ、すなわち、パケットの長さを、そしてビット、ｂ１２．．ｂ１７にサブチャネル識別子を設けることができる。継続フレームは、全てのデータを搬送する。パケット内の終わりから二番目のフレームは、データを含むことができ、データ・ビットの総数であるパディング・ビットは、パケット内の使用可能なビットの総数に対応してなくてもよい。付随フレームは、１６ビットのフィールドを含み、このフィールドは再復号化の際に検出された訂正エラーの数を特定する。例外としては、コード「１１１１ １１１１ １１１１ １１１１」は、この情報が送信されないものであることを示すべきである。ＭＳＣデータを送信中の場合には、「ＸＸ１０］の値を有するフレームタイプ識別子は、望ましくは最後の２ビット「１０」に短縮することが好ましい。表１を見れば、継続フレームであることを認識するには、これら最後の２ビット（ｂ２０およびｂ２１）で十分であることが明らかであろう。この結果、余分の２ビット（ｂ２０およびｂ２１）がデータ用に使用されることになり、データ・フィールドが２０ビットから２４ビットに拡張する。この２ビットを必要としない他の場合には、これらデータは「００」にセットされる。
【００４０】
ＦＩＣデータが送信されている場合には（ｂ１８＝０ ｂ１９＝１）、ヘッダ・フレームは、例えば、ビットｂ１４およびｂ１５は、ＤＡＢ送信モードを示す二つのビットを有する。表４は、ビットｂ１４およびビットｂ１５の値と、関連するＤＡＢ送信モードを示す。
【表４】
【００４１】
ＦＩＣヘッダ・フレームにおいて、ＦＩＢ数用に４ビット（例えば、ビットｂ１０．．ｂ１３）が予約されている。ＤＡＢ送信モードＩＩおよびＩＩＩの場合には、ＦＩＢ数フィールドは、ＦＩＢを指定する、符号を持たない二進数にコード化される。表５にＦＩＢ数のコード化を示す。
【表５】
【００４２】
フレームタイプ識別子の値が「０１００」である付随フレームは、ＦＩＣパケットの場合には下記のものを含む。３桁のビット（例えば、ビットｂ１６．．ｂ１８のような）は、エラー表示タイプ（ＥＩＴ）用に予約され、１６桁のビット（例えば、ビット、ｂ０．．ｂ１５のような）は、エラー・チェック・フィールド（ＥＣＦ）を指定する。表６は、ＥＩＴに対するコードおよびＥＣＦ内の関連する内容を示す。
【表６】
【００４３】
ＤＡＢ送信モードＩの場合には、一つの送信フレーム内に含まれている１２のＦＩＢを９６ｍｓ毎に一回で、または２４ｍｓの間隔を置いて３のＦＩＢずつ４回に分けて送信することができる。
【００４４】
ＴＩＩデータを送信している場合には（ｂ１８＝１ ｂ１９＝０）、ヘッダ・フレームは、この例示の場合には、さらに３ビット、すなわち、ｂ８．．ｂ１０を含むＴＩＩフォーマット識別子を有する。「０１０」の数を有するＴＩＩフォーマット識別子は、基本フォーマットを示し、値「００１」は拡張フォーマットを示す。低容量フォーマットの場合と同じように（フレームタイプ識別子値＝「０１１１」）、ビット、ｂ１１．．ｂ１５はＮＲＴを含む。
【００４５】
基本フォーマットの場合（ヘッダ中のｂ８．．ｂ１０は「０１０」に等しい）、ＴＩＩパケットの残りの部分は、低容量フォーマット内と同じである。
【００４６】
拡張フォーマットの場合（ヘッダ中のｂ８．．ｂ１０は「００１」に等しい）、第一のＮＲＴ継続フレームの内容は、基本フォーマットの内容と同じであるが、ビットｂ１．．ｂ４は下記のように使用される。ビットｂ１は、ヌル記号インジケータであり、新しいヌル記号からのデータが最初に送信されるときに変化する。拡張フォーマットの場合には、選択したキャリヤ・ペアのヌル記号のサンプルに対して、第１図のプロセッサ６内で行われた離散フーリエ変換の復号結果が供給される。この目的のために、ビットｂ２．．ｂ４は、主識別子および副識別子によって識別された送信機に関する情報が送られるキャリヤ・ペア（ＮＣＰ）の数を示す。上記のＮＲＴフレームの数の後にある継続フレームにおいては、２の補数としてコード化された１６ビットが、ＮＲＴフレームの数内で識別された各送信機に対して、ＮＣＰによって指定されたキャリヤ・ペアの各数に対するヌル記号のいくつかのサンプルに関するＦＦＴの結果の実数および虚数部分を含む。
【００４７】
ＭＳＣサブチャネルからのデータ、任意のフォーマットのＦＩＣおよびＴＩＩの送信の時間的順序は自由である。パディング・フレームは、任意の場所に挿入することができる。しかし、通常、一つの論理的ＤＡＢフレームに関連するすべてのデータは、同期フレームの二つの連続送信により指定された間隔中に送信しなければならない。必要ならば、ＴＩＩデータはいくつかのパケットに分割して送信することができる。各キャリヤ・ペアのＴＩＩ情報は、好適には評価されたヌル記号一つにつき一度だけ送信することが好ましく、またそうしなければならない。しかし、この情報は、いくつかの論理フレームに分割することができる。新しいデータ・セットの開始は、ヌル記号インジケータの新しい値により表示される。
【００４８】
第一のシーケンスの場合には、ＦＩＣにすでに内蔵されている一つのＴＩＩデータ以外のＴＩＩデータは含まれていない。ＤＡＢ信号は、また各ＤＡＢフレームの開始時に、ヌル記号内にＴＩＩデータを含む。本発明では、このＴＩＩデータが、受信した送信機の相対的電界強度と共にＦＦＴプロセッサ６から取り出され、第二のシーケンス内に挿入される。
【００４９】
第一のシーケンスの場合には、ビット・ストリーム上のオーディオ情報と一緒に、ＰＡＤデータが埋め込まれる。このＰＡＤデータを取り出すには、最初にオーディオ・フレームを取り出し、その後でそこからＰＡＤデータを取り出す必要がある。これは厄介な動作であり、余分なハードウェアを必要とする。大部分のＤＡＢ受信機は、オーディオ復号化手段を有し、この復号化手段はまたオーディオ・フレームからＰＡＤデータも取り出す。本発明では、これが、別個とされたシーケンスとして第二のシーケンス内にこのＰＡＤを挿入することによって有利に使用され得る。このため、第二のシーケンスを受信する周辺装置は、第二のシーケンスからＰＡＤデータを非常に容易に取り出すことができる。何故なら、オーディオ復号化手段を必要としないからである。
【００５０】
第４図は、本発明の受信機内で使用する、ＰＡＤメッセージの構造の一例である。この場合、ＰＡＤは取り出され、第二のシーケンス内に挿入される。ＰＡＤメッセージは下記の構成を含む。すなわち、
− メッセージが、後で説明する構造を持つことを知らせるためのヘッダ（ＨＤＲ）、
− ＰＡＤメッセージ内で、後に続くバイト数を指定するバイト長インジケータ（ＬＩ）、
− ＥＴＳ３００ ４０１で規定されているＦ−ＰＡＤを運ぶ２バイトのフィールド（Ｆ−ＰＡＤ）、
− 必要ならば、ＥＴＳ３００ ４０１に指定されているＸ−ＰＡＤフィールドからの多数のバイトを運ぶもう一つのフィールド（Ｘ−ＰＡＤ）。これらバイトもまた論理的な順序に配列されている。
【００５１】
ヘッダもバイト長インジケータも、好適には１バイト・フィールドであることが好ましい。この場合、ヘッダはメッセージの構造を識別するための１６進法の値「ＡＤ」を含む。Ｘ−ＰＡＤフィールドは任意のものである。その存在および長さは、バイト長インジケータＬＩから入手することができる。ＤＡＢ受信機は、実際にＸ−ＰＡＤデータ内に含まれているものよりも多くのバイトをＸ−ＰＡＤ内に供給できることに注意されたい。この場合、ＤＡＢ受信機は、それらがオーディオ・データを含む場合、ＰＡＤを含む場合を区別しないで、オーディオ・フレームの終わりの部分からバイトを搬送する。
【００５２】
望ましい実施例においては、ＩＥＣ９５８インターフェースのユーザ・データ・チャネルを通して、ＰＡＤメッセージを送信することができる。このことは、第一のビットが、常に「１」にセットされているスタート・フラグ（ＳＦ）であり、それぞれがその後に７つの情報ビットが続く、８つのビットを含む情報ユニット（ＩＵ）により送信されることを意味している。ユーザ・データ・メッセージは、三つのＩＵのヘッダおよび多数のデータＩＵを有する。
【００５３】
第５Ａ図は、ユーザ・データ・メッセージの第一ヘッダＩＵの図である。第一のＩＵは、メッセージのタイプを識別するための識別子（ＴＭＩ）を有する第一の５ビットフィールドを有する。望ましくは、このフィールドは二進法の値「１００１０」を有する。上記フィールドは、さらに、最終フラグビット（ＬＦ）を有する。このフラグは、当該メッセージが或るＰＡＤメッセージと共に搬送する一連のユーザ・データ・メッセージの最後がメッセージである場合、「１」にセットされる。他の場合、ＬＦを「０」にセットしなければならない。最後に、上記フィールドは、第一フラグ・ビット（ＦＦ）を有する。このビットは、当該メッセージが或るＰＡＤメッセージと共に搬送する一連のユーザ・データ・メッセージの最初がメッセージである場合、「１」にセットしなければならない。他の場合、ＦＦを「０」にセットしなければならない。
【００５４】
第５Ｂ図は、ユーザ・データ・メッセージの第二のヘッダＩＵの図である。このヘッダ内の第２のＩＵは、７ビットのメッセージ長インジケータ（ＬＩ）を有する。第３のヘッダＩＵは、この長さの値内に含まれていることに留意されたい。
【００５５】
第５Ｃ図は、ユーザ・データ・メッセージの第３のＩＵの図である。このヘッダ内の第３のＩＵは、望ましくはＩＥＣ９５８フォーマットのチャネル状態の元の分類コード（バイト１のビット、ｂ０．．ｂ６）を複製する７ビットのフィールド（ＯＣＣ）を含む。
【００５６】
第５Ｄ図は、ユーザ・データ・メッセージのデータＩＵの図である。ＩＵがデータ、すなわち、ＰＡＤメッセージの一部を含んでいる場合には、残りの７のビットをユーザ・データ・フィールド（ＵＤＦ）内のデータのために使用することができる。望ましい実施例の場合、ＩＵの第２のビット（７ビットのユーザ・データ・フィールドの第１のビット）を、後続の６のユーザ・データ・ビット内でエラーを検出したかどうかを知らせるためのエラー・フラグ（ＥＦ）用に予約できる。即ち、ユーザ・データＩＵは、望ましくは、ユーザ・データ・フィールド（ＵＤＦ）により、６ビットのユーザ・データを搬送でき、エラー・フラグがなくてすむ場合には、７ビットを送ることができる。メッセージ内の最後のＵＤＦは、６ビット（または７ビット）以下のビットが使用されている場合には、多数のパディング・ビットを設けることができる。
【００５７】
ユーザ・データ・メッセージ内のＩＵは、最大８のパディング・ビットを持ち、論理的値が「０」であるパディング・ビットにより分離することができる。あるビットの値が「１」である場合は、論理値「０」を有する後続の９の連続ビットが、新しいユーザ・データ・メッセージに最初の部分であると認識される。異なるユーザ・データ・メッセージに属するＩＵの間のパディングは、その長さが少なくとも９ビットである限りは、最大の長さに制限はない。一つのユーザ・データ・メッセージに収容できないＰＡＤメッセージは、いくつかのユーザ・データ・メッセージに分割することができる。ＰＡＤメッセージは、バイト単位で分割する必要はない。ユーザ・データ・メッセージのヘッダは、ＰＡＤメッセージを作成すると共に、メッセージがＤＡＢ−ＰＡＤを含んでいることを示し、また、ユーザ・データ・メッセージの長さや、メッセージがスタート部分であるのか継続メッセージであるのか、一連のメッセージの終了部分であるのかということを示す。
【００５８】
ＩＥＣ９５８ユーザ・データ・チャネル内へＰＡＤメッセージを追加挿入する上述の例は、次のような理由で特に優れている。その理由は、ユーザ・データ・チャネル内の他のデータのコード化および復号化とは別に、コード化および復号化を行うことができる電子回路が容易に入手できることである。このことは、特にＰＡＤのみのアクセスが必要な上記周辺装置の場合には、コード化／復号化が簡単になるので非常に有利である。
【００５９】
上述の実施例は、単に本発明を説明するためのものに過ぎない。埋設データはＤＡＢデータ内のＰＡＤに限定されない。さらに、本発明の範囲から逸脱しないで、ＰＡＤをＩＥＣ９５８に適合しない他のビット・ストリームおよび他の構造内に挿入することができる。
【図面の簡単な説明】
【００６０】
【図１】本発明によるディジタル記号を受信するための受信機の一実施例の図である。
【図２】ＤＡＢ送信フレームの図である。
【図３Ａ】本発明の一実施例による第２のシーケンスのフレームの図である。
【図３Ｂ】ＩＥＣ９５８サブフレームの図である。
【図４】本発明による受信機において使用するためのＰＡＤメッセージの構造の一例の図である。
【図５Ａ】ユーザ・データ・メッセージの第１のヘッダＩＵの図である。
【図５Ｂ】ユーザ・データ・メッセージの第２のヘッダＩＵの図である。
【図５Ｃ】ユーザ・データ・メッセージの第３のヘッダＩＵの図である。
【図５Ｄ】ユーザ・データ・メッセージのデータＩＵの図である。
【０００１】
本発明は、ディジタル送信信号を受信する受信機であって、前記ディジタル送信信号は、チャネル符号化されたディジタルデータシーケンスを有し、前記ディジタルデータシーケンスは、種々のデータタイプの複数のシーケンスを有し、前記種々のデータタイプの複数のシーケンスのうちの少なくとも一つのシーケンスは、前記種々のデータタイプの複数のシーケンスのうちの少なくとも一つの他のシーケンスと共に前記ディジタルデータシーケンス内に、前記少なくとも一つのシーケンスを取り出すには、前記少なくとも一つの他のシーケンスを取り出す必要があるように埋め込まれていて、
− 受信した前記ディジタル送信信号をチャネルデコードし前記ディジタルデータシーケンスを形成する手段と、
− 前記ディジタルデータシーケンス内に埋め込まれている前記種々のデータタイプの複数のシーケンスのうちの前記少なくとも一つのシーケンスを取り出す手段と、
− 前記受信されチャネルデコードされたディジタル送信信号から前記ディジタルデータシーケンスの少なくとも一部を当該受信機の出力に供給する手段とを有する受信機に関する。
【０００２】
本発明はさらに、ディジタルデータシーケンスの少なくとも一部を供給する方法であって、前記ディジタルデータシーケンスは、種々のデータタイプの複数のシーケンスを有し、前記種々のデータタイプの複数のシーケンスのうちの少なくとも一つのシーケンスは、前記種々のデータタイプの複数のシーケンスのうちの少なくとも一つの他のシーケンスと共に前記ディジタルデータシーケンス内に埋め込まれている方法に関する。
【背景技術】
【０００３】
冒頭による受信機は、１９９５年２月オランダのフィリップス・コンシューマ・エレクトロニクス社出版のパンフレット「ＤＡＢ４５２ディジタル・オーディオ放送試験受信機(DAB452 Digital Audio Broadcasting test receiver)”から既知である。この既知の受信機においては、受信したディジタルオーディオ放送信号が、ディジタルデータシーケンスに、周波数変換され、高速フーリエ変換装置により復調され、インターリーブ解除され、デコードされる。このデータシーケンスは、例えばオーディオフレームを有する主サービスチャネルデータ、高速情報チャネルデータ等の種々のデータタイプの複数のシーケンスを有するものである。主サービスチャネル内のオーディオフレームは、オーディオデータ及びプログラムに関連付けられたデータ（ＰＡＤ）を有する。オーディオフレーム内のオーディオデータの最大量は、該フレーム内のＰＡＤの量に依存する。すなわち、ＰＡＤは、オーディオデータと共に前記ディジタルデータシーケンス内に埋め込まれている。前記既知のＤＡＢ受信機は、これら目的のために、オーディオデコード手段を有する。このオーディオデコード手段は、前記オーディオフレームからオーディオデータを取り出すだけではなく、これらオーディオフレームからＰＡＤも取り出す。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、改善された受信機及びディジタルデータシーケンスを供給する改善された方法を提供することにある。
【課題を解決するための手段】
【０００５】
本発明による受信機は、前記供給手段が、前記埋め込まれている少なくとも一つの他のシーケンスと別個とされた前記取り出された少なくとも一つのシーケンスを前記ディジタルデータシーケンスの前記少なくとも一部に付加するように構成されることを特徴とする。本発明は、前記ディジタルデータシーケンスを受信する周辺装置が、埋め込まれたデータを取り出すためのデコード手段を常に有してはいないことの認識に基づいている。すなわち、これら周辺装置は、このようなデータを得るための余分な分析及び取り出し手段を持つ必要がある。固定されたフォーマットのデータストリームに前記少なくとも一つのシーケンスを２回付加することにより、周辺装置は、前記ディジタルデータシーケンスから前記少なくとも一つのシーケンスをより容易に識別し取り出すことができ、これにより、該周辺装置の複雑さを減少させることができる。例えば、ＤＡＢ受信機においては、オーディオフレームをデコードするためのデコード手段が与えられる。これらオーディオデコード手段においては、ＰＡＤも同様にデコードされる。このように取り出されたＰＡＤはＤＡＢ受信機内で既に利用可能であるため、これは、前記供給手段にＰＡＤを供給するために有利に使用することができる。
【０００６】
本発明のある実施例は、前記供給手段は、前記少なくとも一つのシーケンス内のデータタイプを識別してデータタイプ識別子を生成し、該データタイプ識別子を前記取り出された少なくとも一つのシーケンスに付加するように動作することを特徴とする。この手段により、前記ディジタルデータシーケンス内の前記少なくとも一つのシーケンスが容易に認識できる。これは、データが、パケット自体で情報を含み、ヘッダを有する、これらパケットに構築されるようなディジタルデータシーケンスにおいて特に有利である。
【０００７】
本発明のある実施例は、前記供給手段は、前記少なくとも一つのシーケンスの長さを識別して長さインジケータを生成し、該長さインジケータを前記取り出された少なくとも一つのシーケンスに付加するように動作することを特徴とする。この手段により、前記少なくとも一つのシーケンスがどの様な長さであるかを周辺装置が知ることができる。これは、前記少なくとも一つのシーケンスが可変の長さを持つ可能性がある場合特に有利であり、データがパケットに構築される場合非常に役立つ。
【０００８】
本発明のある実施例は、前記ディジタル送信信号が、ディジタルオーディオ放送信号であり、前記少なくとも一つのシーケンスが、プログラムに関連付けられたデータであることを特徴とする。本発明によるこれら手段は、前記少なくとも一つのシーケンスがプログラムに関連付けられたデータであるような、ＤＡＢ受信機における適用に関して特に有利である。
【０００９】
本発明のある実施例は、前記ディジタルデータシーケンスの少なくとも一部が、ＩＥＣ９５８フォーマットにより構築されることを特徴とする。これは、ＤＡＢデータシーケンスが非常に特殊なフォーマットを持つが、ＩＥＣ９５８インタフェースはより共通的に使用されるため、周辺装置と共により標準化されたインタフェースを実現する。
【００１０】
本発明のある実施例は、前記供給手段が、前記少なくとも一つのシーケンスを前記ＩＥＣ９５８フォーマットでユーザデータチャネルに付加するように構成されることを特徴とする。ＩＥＣ９５８インタフェース内のユーザデータチャネルは、複数の目的に対して利用可能である。ＰＡＤを搬送するためのユーザデータチャネルを選択することにより、取り出されたＰＡＤが、ＩＥＣ９５８フォーマットの通常のフレーム構造に付加される必要がなく、すなわち、オリジナルのデータに関してデータ容量をセーブする。
【００１１】
本発明の上述の目的及び特徴は、以下の図を参照して、以下の好ましい実施例の記載からより明白になるであろう。
【発明を実施するための最良の形態】
【００１２】
図中、同じ要素には同じ参照番号がつけてある。
【００１３】
第１図は、本発明によるディジタル信号を受信する受信機の一実施例の図である。受信アンテナ２は、当該受信機の第１の入力に接続されている。この受信機の入力は、フロント・エンド・ユニット４に接続されている。フロント・エンド・ユニット４の出力は、ＦＦＴプロセッサ６の入力に接続されている。ＦＦＴプロセッサ６の出力は、チャネル・デコーダ８の入力に接続されている。
【００１４】
ディジタル信号を受信するための受信機は、ディジタル・オーディオ放送システム（ＤＡＢ）で使用することができる。複数のキャリアを有し、これらキャリア上でディジタル信号は変調されているようなＯＦＤＭ信号が、前記受信機により受信され、フロント・エンド・ユニット４で増幅され、周波数変調される。次いで、フロント・エンド・ユニット４の出力信号は、ＦＦＴプロセッサ６に送られ、前記ディジタル信号を得るために復調される。ＦＦＴプロセッサ６の出力において、コード化され、インタリーブされた信号が得られる。ＦＦＴプロセッサ６はまた、フロント・エンド・ユニット４の同期を行うために、信号プロセッサ１４に情報を送る。この信号プロセッサはまた、受信した送信の電界強度及び該送信の識別、送信識別情報すなわちＴＩＩに関する、ＦＦＴプロセッサ６からの情報を取り出すこともできる。このＴＩＩは、各ＤＡＢフレームの開始時のヌル記号に存する。ＦＦＴプロセッサ６の出力における信号は、再構築されたディジタル信号を得るために、デコーダ８によりインタリーブ解除され、デコードされる。例えば、フィリップスのＳＡＡ２５００のようなオーディオ・デコーダが、オーディオ・フレームを有する前述のディジタル信号をデコードするために、デコーダ８の出力に結合されている。第１の出力において、オーディオ・デコーダ１０は、オーディオ・フレームに埋め込まれているプログラムに関連付けられたデータ３６、すなわち、ＰＡＤを供給する。このＰＡＤは、制御ユニット１２に送られ、さらに処理される。第２の出力において、オーディオ・デコーダ１０はオーディオ・データ３２を供給する。制御ユニット１２はさらに、受信機の同調及びデコーダ８でのデコード処理を制御する。制御ユニット１２は、ユーザから情報を受信し、情報をユーザに供給するデータ３４を用いるインターフェースを備えている。
【００１５】
第２図は、ＤＡＢ送信フレームのである。ＤＡＢフレームは３つのフィールドを含む。すなわち、同期チャネルＳＣ、高速情報チャネルＦＩＣ及び主サービス・チャネルＭＳＣである。ＦＩＣは、多数の高速情報ブロックＦＩＢを含む。ＦＩＢの数は、ＤＡＢ送信モードに依存する。モードＩの場合には、ＤＡＢフレームは、１２個のＦＩＢを含み、モードＩＩの場合には、３個のＦＩＢ、モードＩＩＩの場合には、４個のＦＩＢを含む。主サービスチャネルは、多数の共通インターリーブフレームＣＩＦを有する。この数も、ＤＡＢ送信モードに依存する。モードＩの場合には、ＤＡＢフレームは、４個のＣＩＦを、モードＩＩの場合には、１個のＣＩＦを、モードＩＩＩの場合には、１個のＣＩＦを含む。モードＩの場合には、第１の３個のＦＩＢが、第１のＣＩＦに割り当てられ、第２の３個のＦＩＢが、第２のＣＩＦ等に割り当てられる。主サービス・チャネルは、それぞれがサブチャネル識別番号ＳｕｂＣｈＩｄを持つ、多数のサブチャネルに分割される時間的にインタリーブされたデータ・チャネルであり、各サブチャネルは、オーディオ及びデータ等の一つ以上のサービス要素を搬送することができる。ＭＳＣは、６４ビットの複数の容量ユニットにさらに分割され、サブチャネルは、これら容量ユニットの一つ以上を占有することができる。サブチャネルの組織及びこれらサブチャネルの容量ユニットにおける位置は、他のアイテムと一緒にＦＩＣにより送信される。ＤＡＢ送信フレーム、該フレームの構造及び内容の詳細な説明については、１９９５年にソフィア・アンチポリス所在のヨーロッパ遠隔通信規格協会が発行した「無線放送システム；移動、携帯及び定置受信機に対するディジタル・オーディオ放送（ＤＡＢ）」ＥＴＳ３００ ４０１を参照されたい。
【００１６】
第１図の受信機においては、現在使用されているデコーダ８は、ＤＡＢシーケンス全部をデコードすることができず、ＤＡＢデータの選択された部分しかデコードできない。例えば、ユーザは、制御ユニット１２に、例えば、「無線３」のようなあるプログラムからのオーディオ・データを、オーディオ・デコーダ１０に供給するように命令する。次いで、制御ユニット１２は、ＦＩＣを分析し、「無線３」のプログラムが、主サービス・チャネルのどのサブチャネル上に存在するのかを決定する。次いで、制御ユニット１２は、どの容量ユニットが上記サブチャネルに割り当てられているか、例えば、ＣＵ６、７及び８を決定する。次いで、制御ユニット１２は、デコーダ８に、デコードし、ＣＵ６、７及び８からデコードしたデータを出力し、デコードしたデータがあることを知らせるために、第１のウィンドウ信号を活性化するように命令する。オーディオ・デコーダ１０は、上記データ及びウィンドウ信号を受信し、該出力に含まれるオーディオ・データを供給する。すなわち、デコーダ８は、限られたデータ量しか供給できない。将来のデコーダ８は、ＤＡＢ信号から完全なデコードされたデータをＤＡＢ信号から供給することができるであろう。
【００１７】
本発明によれば、第１図の受信機はさらに、
− 第１のシーケンスのデータを受信するためデコーダ８の出力に結合される第１の入力（前述のように、このシーケンスは、デコーダ８に依存して、完全なＤＡＢデータ・シーケンスか少なくとも該ＤＡＢデータ・シーケンスの一部の何れかを有する）
− 第２のタイプのフレームで構築された第２のシーケンスのデータ３６を供給するための出力（第１のタイプのフレームのフレーム長は、第２のタイプのフレームのフレーム長とは異なる。第２のシーケンスは、少なくとも２つの別個のシーケンスを有する。これら別個のシーケンス各々は、異なるデータ・タイプのために予約され、第２のタイプのフレーム内に配置されている。ここで、第２タイプの各フレームは、第２のシーケンス内のこれら別個のシーケンスを識別するためのフレーム・タイプ識別子を含む。）
を持つ変換手段１６を有している。
【００１８】
本発明の他の態様によれば、変換手段１６は、ＤＡＢ信号のヌル記号に含まれているＴＩＩを受信するため、信号プロセッサ１４の第２の出力に結合されている第２の入力を持っている。この信号プロセッサ１４はまた、ヌル記号のＦＦＴから測定した相対的な電界強度を供給し、必要ならば、選択されたキャリヤ・ペアの同相及び直角位相成分の値も供給する。次いで、変換手段１６は、信号プロセッサ１４により供給されるＴＩＩ及び他のデータを、第２のシーケンスに挿入することができる。その方法については、第２のシーケンス内のフレームの内容について扱う際にさらに詳細に説明する。
【００１９】
前述の態様とは別個のものとさえ見られるかもしれない、本発明の他の態様によれば、変換手段１６が、ＰＡＤを供給するオーディオ・デコーダ１０の第２の出力に結合されている第３の入力を持つことである。次いで、このＰＡＤも、前記シーケンス中に挿入される。この挿入は、ＴＩＩ及び関連データの挿入方法と同様に行うことができ、ＰＡＤに対して個別のデータ・タイプ識別子を供給し、個別のパケット内にＰＡＤを挿入する。これについてはこれ以上詳細に説明しない。後で詳細に説明する好適な実施例においては、第２のタイプのフレームが、ＩＥＣ９５８フォーマットによるフレームである場合、ＰＡＤはユーザ・データ・チャネルの第２のシーケンス内に挿入される。
【００２０】
変換手段１６は、供給手段とも呼ばれる。何故なら、変換手段は、実際に外部、例えば、周辺装置等に第２のシーケンスのデータを供給するからである。
【００２１】
第３Ａ図は、本発明の一実施例による第２のシーケンスのフレームの図である。本発明においては、第１のシーケンスのデータは、該第１のシーケンスのフレーム長とは異なるフレーム長を有する第２のシーケンスのデータに変換される。一実施例においては、第２のシーケンスのフレーム長は、２４ビットの長さに選択され、そのうち最初の２０ビットは、すなわち、ｂ０．．ｂ１９ビットは、データ（ＤＴ）用に予約され、ｂ２０．．ｂ２３ビットは、フレーム・タイプ識別子（ＦＴＩ）用に予約されている。このように選択することにより、第２のシーケンスのフレームをＩＥＣ９５８規格によるサブフレームに組み込むことができる。この規格の詳細については、１９８９年に、スイスの国際電子技術委員会、中央部局が発行した国際規格ＩＥＣ９５８の「ディジタル・オーディオ・インターフェース」の文献を参照されたい。
【００２２】
第３Ｂ図は、ＩＥＣ９５８サブフレームの図である。ＩＥＣ９５８は、４ビットのプリアンブルＰＲ、補助データＡＸＤ用の４ビット・フィールド、オーディオ・データＡＤ用の２０ビット・フィールド及び４つの１ビット・フィールド、すなわち、妥当性フラグ・ビットＶ、ユーザ・データ・チャネル・ビットＵ、チャネル状態ビットＣ、及びパリティ・ビットＰを含む。チャネル状態ビットＣは、１ビットのチャネル状態語を含み、チャネルを通して送られるデータの情報を与える。ユーザ・データ・チャネル・ビットＵは、１ビットのユーザ・データ・チャネルを含む。第２のシーケンスのフレームが、ＩＥＣ９５８サブフレームに組み込まれている場合には、該フレームはビット位置ａ４．．ａ２７に収容される。この場合、妥当性フラグ・ビットＶは、オーディオ・デコーダにより誤ってデコードされないように、「１」に設定されるべきである。チャネル状態語においては、状態が「非オーディオ」（バイト０のビットを１）に設定され、「コピーライト」主張（バイト０のビット２＝「０」）されるべきである。バイト０のビット３、４及び５は、「０００」に設定され、バイト０のビット６及び７は、モード０（＝「００」）に設定されるべきである。ディジタル・オーディオの放送受信用のカテゴリコード「００１」が、使用されるべきである（バイト１のビット０、１、２＝「００１」）。発生状態ビットは、「オリジナル」（バイト１のビット７＝「０」）に設定されるべきである。バイト２においては、ソース番号及びチャネル番号が、「無指定」（バイト２＝「００００００００」）に設定されるべきである。サンプリング周波数は、４８ｋＨｚ（バイト３のビット０、１、２、３＝「０１００」）であるべきである。±１０００ｐｐｍのクロック精度が、「レベルＩＩ」（バイト３のビット４、５＝「００」）であるべきである。すなわち、チャネル状態語の最初の４つのバイトを次のように、すなわち、バイト０を「０１００００００」、バイト１を「００１００１００」、バイト２を「００００００００」、バイト３を「０１００００００」に設定することが推奨される。バイト１のビット３、４、５、６は、「００１０」に設定される。これは、入力「ＤＡＢ」がカテゴリ「放送受信」に規定されるべきであることを提示している。
【００２３】
表１は、フレーム・タイプ識別子のビットｂ２０．．ｂ２３の値の例である。
【表１】
フレーム・タイプ識別子の値、「０００１」、「ＸＸ１０］、「０１００」及び「０１１１」は、パケットでのデータ転送を示す。値「０００１」及び「０１１１」は、パケットの始まりを通知し、この値「０１１１」はさらに、パケット内のデータ・タイプも識別している。値「ＸＸ１０］は、パケットの継続を通知し、値「０１００」は、パケットの終わりを示す。パケットでのデータ転送の利点は、使用されるオーバーヘッドが少なくて済むということである。何故なら、例えば、データ・タイプ及びパケットの長さを通知するヘッダ・フレーム（及びあれば付随(trailer)フレーム）しかオーバーヘッドとして使用されないからである。この高容量データ転送は、完全なＤＡＢデータをデコードすることができる将来のチャネル・デコーダ８と組合わせる場合に役立つ。
【００２５】
値「ＸＸ１０］のフレーム・タイプ識別子は、ビットｂ２０及びｂ２１の値は無視してよいということを意味する。これは、ビットｂ０．．ｂ１９により供給された２０個のデータ・ビットでは不十分で、１つ以上のデータ・ビットが継続しているフレーム内に必要とされる場合に特に役立つ。この場合、ビットｂ２０及びｂ２１が、データ・ビットに追加され、それにより２２ビットのデータ・フィールドが実現される。ビットｂ２０及びｂ２１は、パケット内のデータ・タイプに依存して、データ・ビットとしては使用されない場合、これらビットは、好適には「００」に設定されるべきである。例えば、ＭＳＣデータの場合、ビットｂ２０及びｂ２１は、データ・フィールドに追加される。一方、ＦＩＣまたはＴＩＩデータの場合、ビットｂ２０及びｂ２１は、フレーム・タイプ識別子の一部である。
【００２６】
値「１１１１」のフレーム・タイプ識別子は、データ及び該データのデータ・タイプ識別子を含むフレームを通知する。各フレームがこのような識別子を含んでいるので、各フレームを相互に独立して処理することができる。これは、今全てのフレームがデータ・タイプ識別子を含む必要があるので多量のオーバーヘッドを犠牲にするが、受信側におけるフレーム処理を非常に容易にする。
【００２７】
値「００００」のフレーム・タイプ識別子は、ｂ０．．ｂ１９の全ての位置に置いて通常論理値「０」しか持たない、パディング・フレームを通知する。このフレーム・タイプは、転送できる状態のデータがない場合に使用され、データが存在しない場合、第２のシーケンスにおける継続的なフレームの流れを確実にする。
【００２８】
値「０１０１」のフレーム・タイプ識別子は、第１のシーケンスにおけるフレームの開始、すなわち、例えば、論理ＤＡＢフレームの開始を知らせる。このフレームは、残りのビット位置ｂ０．．ｂ１９上にいくつかの情報を含ませることができる。さらに、ビットｂ０．．ｂ３は、同期フレームコンテンツインジケータＳＦＣＩ用に予約され、例えば「０００１」の値を持つような場合、コンテンツフィールドＣＦ、すなわち、残りのビット、ｂ４．．ｂ１９は、過去のＤＡＢフレームのＦＩＣの再符号化により検出された訂正エラーの数を含むことを指示する。他のビットｂ０．．ｂ３の値は予約されている。
【００２９】
（「ＸＸ１０］及び「０１００」に関連付けられる、値「０１１１」のＴＩＩフレーム・タイプ識別子、及び値「１１１１」のフレーム・タイプ識別子を用いる）低容量データ転送の場合、フレーム・タイプ識別子の値が「１１１１」であるフレームは、例えば、ＩＥＣ９５８フォーマットのチャネルＡを通じて送信され、あるならば、次いで、ＴＩＩフレームが、ＩＥＣ９５８フォーマットのチャネルＢを通じて送信される。低容量データ伝送は、限られたデータ量しか搬送される必要がないので、現在用いられているチャネル・デコーダ８と組合わせた場合特に有用である。
【００３０】
このように、変換手段１６は、ＴＩＩデータ及び関連付けられるデータを、高容量データ転送に対してパケット内に収容するか、低容量データ転送に対してパケット内に収容する。ＭＳＣデータ及びＦＩＣデータ等の他のデータに対しても同様である。上記の説明は単に例示としてのものに過ぎず、本発明を制限するものでないことは明らかであろう。
【００３１】
表１に示すように、低容量データ転送に対するフレーム・タイプ識別子がある。これらのフレーム・タイプ識別子は、（パケットの残りを指示するため関連付けられる値「ＸＸ１０」及び「０１００」と共に）「１１１１」及び「０１１１」の値を有する。
【００３２】
「１１１１」の値のフレーム・タイプ識別子を持つフレームは、好適には、第３Ａ図のフレーム内のビット位置ｂ８．．ｂ１５に位置する８ビットのデータＤＴを有する。データ・タイプ識別子ＤＴＩは、表２に示すように、データの出所を示すため及びフレームのビットｂ０．．ｂ５内の６ビット・フィールドＩＤＦが使用されていることを示すために、ビットｂ６及びｂ７の位置で該フレームに追加される。
【表２】
サブチャネル識別子ＳｕｂＣｈＩｄは、すでに説明したように、ＭＳＣ内のサブチャネルを識別するための識別子である。第１図のチャネル・デコーダ８は、ＤＡＢデータ・シーケンスと共にウィンドウ信号を供給することができる。このようなウィンドウ信号は、あるデータ・タイプに属するデータがＤＡＢデータ・シーケンス内に存在する間活性化される。例えば、制御ユニットは、特定のサブチャネルがＭＳＣの容量ユニット６、７及び８内に存する限り、ＦＩＣから得られる。ここで、制御ユニットは、チャネル・デコーダ８に、容量ユニット６、７及び８からのデコードされたデータがチャネル・デコーダ８の出力に存在する間、ウィンドウ信号１を活性化するように指示する。ここで、ウィンドウ信号１は、当該出力に容量ユニット６、７及び８からデコードされたデータが存在することを通知し、前記制御ユニットはこのデータが特定のサブチャネル番号に関連付けられていることが分かる。フレーム・フォーマットにおいて、フレーム内のビット位置ｂ１６．．ｂ１９に、４ビットのウィンドウ信号識別子を設けることにより、前記チャネル・デコーダからの１６個の異なるウィンドウ信号を識別することができる。ウィンドウ信号は、データがＭＳＣからのものである場合には、フレームのビット位置ｂ０．．ｂ５における識別フィールド内にサブチャネル識別子を挿入することにより、サブチャネルとリンクさせることができる。他の場合には、識別フィールドは予約されている。ウィンドウ信号の１つを、パディングに対して使用し、獲得できるデータがないことを示しても良い。
【００３４】
値が「０１１１」のフレーム・タイプ識別子は、低容量データ転送に対するＴＩＩ情報パケットのヘッダを示し、すなわち、データタイプ識別子としても機能する。「ＸＸ１０」及び「０１００」の値のフレームタイプを持つフレームが、データを搬送する。（値が「０１１１」である）ヘッダ・フレーム内には、ビット位置ｂ１１．．ｂ１５の５ビットワードが、受信される送信数（ＮＲＴ）を指示するために予約されている。ＮＲＴは、１−２４の範囲内とすることができる。他の値は予約されている。（ＮＲＴ−１）個の継続フレーム及び一個の付随フレームがあり、これらフレームは以下のように満たされる。これらのフレーム各々は、ビット位置ｂ８．．ｂ１２に５ビットのサブ識別子を、ビット位置ｂ１３．．ｂ１９に７ビットの主識別子を含み、主識別子及びサブ識別子は、１９９５年にソフィア・アンチポリス所在のヨーロッパ遠隔通信規格協会発行の「移動、携帯、定置受信機に対するディジタル・オーディオ放送（ＤＡＢ）」、ＥＴＳ３００ ４０１の「無線放送システム」の文献の８．１．９項に記載されている。さらに、微弱の信号を指示する「００１」から非常に強い信号を示す「１１１」までの範囲の相対的な電界強度を指示するために、３ビット（ｂ５．．ｂ７）が予約されている。値「０００」は、「信号が送られていない」ことを示す。残りのビット、ｂ０．．ｂ４は予約されている。すでに説明したように、最後のデータ・フレームは、値「０１００」のフレーム・タイプ識別子を有するが、特定の付随フレームは必要ないので、前記継続フレームと同じ種類のデータを含む。
【００３５】
低容量データ転送の場合には、ＴＩＩフレームを、フレーム・タイプ１１１１のデータ・フレームと変更することができる。パディング・フレームは自由に挿入することができる。
【００３６】
低容量データ伝送の場合には、ＴＩＩフレームをフレームタイプ「１１１１」のデータ・フレームと交互に使用できる。パディング・フレームは自由に挿入することができる。
【００３７】
値が「０００１」であるフレームタイプ識別子は、高容量データ伝送用のパケットのヘッダ・フレームを識別する。表３に示すように、この目的のために、ヘッダ・フレーム内のビット、ｂ１８およびｂ１９は、データタイプ識別子を形成し、パケット内に含まれるデータタイプを示すために予約される。
【表３】
値が「ＸＸ１０］のフレームタイプ識別子は、継続フレーム、すなわち、パケットの一部であるフレームを示し、値が「０１００」のフレームタイプ識別子は、パケットの終わりを示す付随フレームと見なすことができる。
【００３９】
ＭＳＣデータが送信されている場合には（ｂ１８＝０ ｂ１９＝１）、ヘッダ・フレームは、ビット、ｂ０．．ｂ１１に、ＲＤＩフレームの数Ｍ、すなわち、パケットの長さを、そしてビット、ｂ１２．．ｂ１７にサブチャネル識別子を設けることができる。継続フレームは、全てのデータを搬送する。パケット内の終わりから二番目のフレームは、データを含むことができ、データ・ビットの総数であるパディング・ビットは、パケット内の使用可能なビットの総数に対応してなくてもよい。付随フレームは、１６ビットのフィールドを含み、このフィールドは再復号化の際に検出された訂正エラーの数を特定する。例外としては、コード「１１１１ １１１１ １１１１ １１１１」は、この情報が送信されないものであることを示すべきである。ＭＳＣデータを送信中の場合には、「ＸＸ１０］の値を有するフレームタイプ識別子は、望ましくは最後の２ビット「１０」に短縮することが好ましい。表１を見れば、継続フレームであることを認識するには、これら最後の２ビット（ｂ２０およびｂ２１）で十分であることが明らかであろう。この結果、余分の２ビット（ｂ２０およびｂ２１）がデータ用に使用されることになり、データ・フィールドが２０ビットから２４ビットに拡張する。この２ビットを必要としない他の場合には、これらデータは「００」にセットされる。
【００４０】
ＦＩＣデータが送信されている場合には（ｂ１８＝０ ｂ１９＝１）、ヘッダ・フレームは、例えば、ビットｂ１４およびｂ１５は、ＤＡＢ送信モードを示す二つのビットを有する。表４は、ビットｂ１４およびビットｂ１５の値と、関連するＤＡＢ送信モードを示す。
【表４】
ＦＩＣヘッダ・フレームにおいて、ＦＩＢ数用に４ビット（例えば、ビットｂ１０．．ｂ１３）が予約されている。ＤＡＢ送信モードＩＩおよびＩＩＩの場合には、ＦＩＢ数フィールドは、ＦＩＢを指定する、符号を持たない二進数にコード化される。表５にＦＩＢ数のコード化を示す。
【表５】
フレームタイプ識別子の値が「０１００」である付随フレームは、ＦＩＣパケットの場合には下記のものを含む。３桁のビット（例えば、ビットｂ１６．．ｂ１８のような）は、エラー表示タイプ（ＥＩＴ）用に予約され、１６桁のビット（例えば、ビット、ｂ０．．ｂ１５のような）は、エラー・チェック・フィールド（ＥＣＦ）を指定する。表６は、ＥＩＴに対するコードおよびＥＣＦ内の関連する内容を示す。
【表６】
ＤＡＢ送信モードＩの場合には、一つの送信フレーム内に含まれている１２のＦＩＢを９６ｍｓ毎に一回で、または２４ｍｓの間隔を置いて３のＦＩＢずつ４回に分けて送信することができる。
【００４４】
ＴＩＩデータを送信している場合には（ｂ１８＝１ ｂ１９＝０）、ヘッダ・フレームは、この例示の場合には、さらに３ビット、すなわち、ｂ８．．ｂ１０を含むＴＩＩフォーマット識別子を有する。「０１０」の数を有するＴＩＩフォーマット識別子は、基本フォーマットを示し、値「００１」は拡張フォーマットを示す。低容量フォーマットの場合と同じように（フレームタイプ識別子値＝「０１１１」）、ビット、ｂ１１．．ｂ１５はＮＲＴを含む。
【００４５】
基本フォーマットの場合（ヘッダ中のｂ８．．ｂ１０は「０１０」に等しい）、ＴＩＩパケットの残りの部分は、低容量フォーマット内と同じである。
【００４６】
拡張フォーマットの場合（ヘッダ中のｂ８．．ｂ１０は「００１」に等しい）、第一のＮＲＴ継続フレームの内容は、基本フォーマットの内容と同じであるが、ビットｂ１．．ｂ４は下記のように使用される。ビットｂ１は、ヌル記号インジケータであり、新しいヌル記号からのデータが最初に送信されるときに変化する。拡張フォーマットの場合には、選択したキャリヤ・ペアのヌル記号のサンプルに対して、第１図のプロセッサ６内で行われた離散フーリエ変換の復号結果が供給される。この目的のために、ビットｂ２．．ｂ４は、主識別子および副識別子によって識別された送信機に関する情報が送られるキャリヤ・ペア（ＮＣＰ）の数を示す。上記のＮＲＴフレームの数の後にある継続フレームにおいては、２の補数としてコード化された１６ビットが、ＮＲＴフレームの数内で識別された各送信機に対して、ＮＣＰによって指定されたキャリヤ・ペアの各数に対するヌル記号のいくつかのサンプルに関するＦＦＴの結果の実数および虚数部分を含む。
【００４７】
ＭＳＣサブチャネルからのデータ、任意のフォーマットのＦＩＣおよびＴＩＩの送信の時間的順序は自由である。パディング・フレームは、任意の場所に挿入することができる。しかし、通常、一つの論理的ＤＡＢフレームに関連するすべてのデータは、同期フレームの二つの連続送信により指定された間隔中に送信しなければならない。必要ならば、ＴＩＩデータはいくつかのパケットに分割して送信することができる。各キャリヤ・ペアのＴＩＩ情報は、好適には評価されたヌル記号一つにつき一度だけ送信することが好ましく、またそうしなければならない。しかし、この情報は、いくつかの論理フレームに分割することができる。新しいデータ・セットの開始は、ヌル記号インジケータの新しい値により表示される。
【００４８】
第一のシーケンスの場合には、ＦＩＣにすでに内蔵されている一つのＴＩＩデータ以外のＴＩＩデータは含まれていない。ＤＡＢ信号は、また各ＤＡＢフレームの開始時に、ヌル記号内にＴＩＩデータを含む。本発明では、このＴＩＩデータが、受信した送信機の相対的電界強度と共にＦＦＴプロセッサ６から取り出され、第二のシーケンス内に挿入される。
【００４９】
第一のシーケンスの場合には、ビット・ストリーム上のオーディオ情報と一緒に、ＰＡＤデータが埋め込まれる。このＰＡＤデータを取り出すには、最初にオーディオ・フレームを取り出し、その後でそこからＰＡＤデータを取り出す必要がある。これは厄介な動作であり、余分なハードウェアを必要とする。大部分のＤＡＢ受信機は、オーディオ復号化手段を有し、この復号化手段はまたオーディオ・フレームからＰＡＤデータも取り出す。本発明では、これが、別個とされたシーケンスとして第二のシーケンス内にこのＰＡＤを挿入することによって有利に使用され得る。このため、第二のシーケンスを受信する周辺装置は、第二のシーケンスからＰＡＤデータを非常に容易に取り出すことができる。何故なら、オーディオ復号化手段を必要としないからである。
【００５０】
第４図は、本発明の受信機内で使用する、ＰＡＤメッセージの構造の一例である。この場合、ＰＡＤは取り出され、第二のシーケンス内に挿入される。ＰＡＤメッセージは下記の構成を含む。すなわち、
− メッセージが、後で説明する構造を持つことを知らせるためのヘッダ（ＨＤＲ）、
− ＰＡＤメッセージ内で、後に続くバイト数を指定するバイト長インジケータ（ＬＩ）、
− ＥＴＳ３００ ４０１で規定されているＦ−ＰＡＤを運ぶ２バイトのフィールド（Ｆ−ＰＡＤ）、
− 必要ならば、ＥＴＳ３００ ４０１に指定されているＸ−ＰＡＤフィールドからの多数のバイトを運ぶもう一つのフィールド（Ｘ−ＰＡＤ）。これらバイトもまた論理的な順序に配列されている。
【００５１】
ヘッダもバイト長インジケータも、好適には１バイト・フィールドであることが好ましい。この場合、ヘッダはメッセージの構造を識別するための１６進法の値「ＡＤ」を含む。Ｘ−ＰＡＤフィールドは任意のものである。その存在および長さは、バイト長インジケータＬＩから入手することができる。ＤＡＢ受信機は、実際にＸ−ＰＡＤデータ内に含まれているものよりも多くのバイトをＸ−ＰＡＤ内に供給できることに注意されたい。この場合、ＤＡＢ受信機は、それらがオーディオ・データを含む場合、ＰＡＤを含む場合を区別しないで、オーディオ・フレームの終わりの部分からバイトを搬送する。
【００５２】
望ましい実施例においては、ＩＥＣ９５８インターフェースのユーザ・データ・チャネルを通して、ＰＡＤメッセージを送信することができる。このことは、第一のビットが、常に「１」にセットされているスタート・フラグ（ＳＦ）であり、それぞれがその後に７つの情報ビットが続く、８つのビットを含む情報ユニット（ＩＵ）により送信されることを意味している。ユーザ・データ・メッセージは、三つのＩＵのヘッダおよび多数のデータＩＵを有する。
【００５３】
第５Ａ図は、ユーザ・データ・メッセージの第一ヘッダＩＵの図である。第一のＩＵは、メッセージのタイプを識別するための識別子（ＴＭＩ）を有する第一の５ビットフィールドを有する。望ましくは、このフィールドは二進法の値「１００１０」を有する。上記フィールドは、さらに、最終フラグビット（ＬＦ）を有する。このフラグは、当該メッセージが或るＰＡＤメッセージと共に搬送する一連のユーザ・データ・メッセージの最後がメッセージである場合、「１」にセットされる。他の場合、ＬＦを「０」にセットしなければならない。最後に、上記フィールドは、第一フラグ・ビット（ＦＦ）を有する。このビットは、当該メッセージが或るＰＡＤメッセージと共に搬送する一連のユーザ・データ・メッセージの最初がメッセージである場合、「１」にセットしなければならない。他の場合、ＦＦを「０」にセットしなければならない。
【００５４】
第５Ｂ図は、ユーザ・データ・メッセージの第二のヘッダＩＵの図である。このヘッダ内の第２のＩＵは、７ビットのメッセージ長インジケータ（ＬＩ）を有する。第３のヘッダＩＵは、この長さの値内に含まれていることに留意されたい。
【００５５】
第５Ｃ図は、ユーザ・データ・メッセージの第３のＩＵの図である。このヘッダ内の第３のＩＵは、望ましくはＩＥＣ９５８フォーマットのチャネル状態の元の分類コード（バイト１のビット、ｂ０．．ｂ６）を複製する７ビットのフィールド（ＯＣＣ）を含む。
【００５６】
第５Ｄ図は、ユーザ・データ・メッセージのデータＩＵの図である。ＩＵがデータ、すなわち、ＰＡＤメッセージの一部を含んでいる場合には、残りの７のビットをユーザ・データ・フィールド（ＵＤＦ）内のデータのために使用することができる。望ましい実施例の場合、ＩＵの第２のビット（７ビットのユーザ・データ・フィールドの第１のビット）を、後続の６のユーザ・データ・ビット内でエラーを検出したかどうかを知らせるためのエラー・フラグ（ＥＦ）用に予約できる。即ち、ユーザ・データＩＵは、望ましくは、ユーザ・データ・フィールド（ＵＤＦ）により、６ビットのユーザ・データを搬送でき、エラー・フラグがなくてすむ場合には、７ビットを送ることができる。メッセージ内の最後のＵＤＦは、６ビット（または７ビット）以下のビットが使用されている場合には、多数のパディング・ビットを設けることができる。
【００５７】
ユーザ・データ・メッセージ内のＩＵは、最大８のパディング・ビットを持ち、論理的値が「０」であるパディング・ビットにより分離することができる。あるビットの値が「１」である場合は、論理値「０」を有する後続の９の連続ビットが、新しいユーザ・データ・メッセージに最初の部分であると認識される。異なるユーザ・データ・メッセージに属するＩＵの間のパディングは、その長さが少なくとも９ビットである限りは、最大の長さに制限はない。一つのユーザ・データ・メッセージに収容できないＰＡＤメッセージは、いくつかのユーザ・データ・メッセージに分割することができる。ＰＡＤメッセージは、バイト単位で分割する必要はない。ユーザ・データ・メッセージのヘッダは、ＰＡＤメッセージを作成すると共に、メッセージがＤＡＢ−ＰＡＤを含んでいることを示し、また、ユーザ・データ・メッセージの長さや、メッセージがスタート部分であるのか継続メッセージであるのか、一連のメッセージの終了部分であるのかということを示す。
【００５８】
ＩＥＣ９５８ユーザ・データ・チャネル内へＰＡＤメッセージを追加挿入する上述の例は、次のような理由で特に優れている。その理由は、ユーザ・データ・チャネル内の他のデータのコード化および復号化とは別に、コード化および復号化を行うことができる電子回路が容易に入手できることである。このことは、特にＰＡＤのみのアクセスが必要な上記周辺装置の場合には、コード化／復号化が簡単になるので非常に有利である。
【００５９】
上述の実施例は、単に本発明を説明するためのものに過ぎない。埋設データはＤＡＢデータ内のＰＡＤに限定されない。さらに、本発明の範囲から逸脱しないで、ＰＡＤをＩＥＣ９５８に適合しない他のビット・ストリームおよび他の構造内に挿入することができる。
【図面の簡単な説明】
【００６０】
【図１】本発明によるディジタル記号を受信するための受信機の一実施例の図である。
【図２】ＤＡＢ送信フレームの図である。
【図３Ａ】本発明の一実施例による第２のシーケンスのフレームの図である。
【図３Ｂ】ＩＥＣ９５８サブフレームの図である。
【図４】本発明による受信機において使用するためのＰＡＤメッセージの構造の一例の図である。
【図５Ａ】ユーザ・データ・メッセージの第１のヘッダＩＵの図である。
【図５Ｂ】ユーザ・データ・メッセージの第２のヘッダＩＵの図である。
【図５Ｃ】ユーザ・データ・メッセージの第３のヘッダＩＵの図である。
【図５Ｄ】ユーザ・データ・メッセージのデータＩＵの図である。
Claims (12)
- ディジタル送信信号を受信する受信機であって、
前記ディジタル送信信号は、チャネル符号化されたディジタルデータシーケンスを有し、
前記ディジタルデータシーケンスは、種々のデータタイプの複数のシーケンスを有し、
前記種々のデータタイプの複数のシーケンスのうちの少なくとも一つのシーケンスは、前記種々のデータタイプの複数のシーケンスのうちの少なくとも一つの他のシーケンスと共に前記ディジタルデータシーケンス内に、前記少なくとも一つのシーケンスを取り出すには、前記少なくとも一つの他のシーケンスを取り出す必要があるように埋め込まれていて、
− 受信した前記ディジタル送信信号をチャネルデコードし前記ディジタルデータシーケンスを形成する手段と、
− 前記ディジタルデータシーケンス内に埋め込まれている前記種々のデータタイプの複数のシーケンスのうちの前記少なくとも一つのシーケンスを取り出す手段と、
− 前記受信されチャネルデコードされたディジタル送信信号から前記ディジタルデータシーケンスの少なくとも一部を当該受信機の出力に供給する手段とを有する受信機において、
前記供給手段は、前記埋め込まれている少なくとも一つの他のシーケンスと別個とされた前記取り出された少なくとも一つのシーケンスを前記ディジタルデータシーケンスの前記少なくとも一部に付加するように構成されることを特徴とする受信機。 - 請求項１に記載の受信機において、
前記供給手段は、前記少なくとも一つのシーケンス内のデータタイプを識別してデータタイプ識別子を生成し、該データタイプ識別子を前記取り出された少なくとも一つのシーケンスに付加するように動作することを特徴とする受信機。 - 請求項１または２に記載の受信機において、
前記供給手段は、前記少なくとも一つのシーケンスの長さを識別して長さインジケータを生成し、該長さインジケータを前記取り出された少なくとも一つのシーケンスに付加するように動作することを特徴とする受信機。 - 請求項１、２または３に記載の受信機において、
前記ディジタル送信信号はディジタルオーディオ放送信号であり、
前記少なくとも一つのシーケンスは、プログラムに関連付けられたデータであることを特徴とする受信機。 - 請求項１、２、３または４に記載の受信機において、
前記ディジタルデータシーケンスの少なくとも一部は、ＩＥＣ９５８フォーマットにより構築されることを特徴とする受信機。 - 請求項５に記載の受信機において、
前記供給手段は、前記少なくとも一つのシーケンスを前記ＩＥＣ９５８フォーマットでユーザデータチャネルに付加するように構成されることを特徴とする受信機。 - 請求項１に記載の受信機の出力にディジタルデータシーケンスの少なくとも一部を供給する方法であって、前記ディジタルデータシーケンスは、種々のデータタイプの複数のシーケンスを有し、前記種々のデータタイプの複数のシーケンスのうちの少なくとも一つのシーケンスは、前記種々のデータタイプの複数のシーケンスのうちの少なくとも一つの他のシーケンスと共に前記ディジタルデータシーケンス内に、前記少なくとも一つのシーケンスを取り出すには、前記少なくとも一つの他のシーケンスを取り出す必要があるように埋め込まれている方法において、
− チャネル符号化されたディジタルデータシーケンスを有するディジタル送信信号を受信する工程と、
− 受信した前記ディジタル送信信号をチャネルデコードし前記ディジタルデータシーケンスを形成する工程と、
− 前記ディジタルデータシーケンス内に埋め込まれている前記種々のデータタイプの複数のシーケンスのうちの前記少なくとも一つのシーケンスを取り出す工程と、
− 前記埋め込まれている少なくとも一つの他のシーケンスと別個とされた前記取り出された少なくとも一つのシーケンスを前記ディジタルデータシーケンスの前記少なくとも一部に挿入する工程とを有することを特徴とする方法。 - 請求項７に記載の方法において、
前記少なくとも一つのシーケンス内のデータタイプを識別してデータタイプ識別子を生成し、該データタイプ識別子を前記取り出された少なくとも一つのシーケンスに付加する工程を有することを特徴とする方法。 - 請求項７または８に記載の方法において、
前記少なくとも一つのシーケンスの長さを識別して長さインジケータを生成し、該長さインジケータを前記取り出された少なくとも一つのシーケンスに付加する工程を有することを特徴とする方法。 - 請求項７、８または９に記載の方法において、
前記ディジタル送信信号はディジタルオーディオ放送信号であり、
前記少なくとも一つのシーケンスは、プログラムに関連付けられたデータであることを特徴とする方法。 - 請求項７、８、９または１０に記載の方法において、
前記ディジタルデータシーケンスの少なくとも一部は、ＩＥＣ９５８フォーマットにより構築されることを特徴とする方法。 - 請求項１１に記載の方法において、
前記取り出された少なくとも一つのシーケンスが、前記ＩＥＣ９５８フォーマットのユーザデータチャネルに挿入されることを特徴とする方法。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP95202670 | 1995-10-04 | ||
| NL95202670.6 | 1995-10-04 | ||
| PCT/IB1996/000991 WO1997013338A1 (en) | 1995-10-04 | 1996-09-25 | Receiver and method for providing data in an improved format |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007150591A Division JP2008035490A (ja) | 1995-10-04 | 2007-06-06 | 受信機及び改善されたフォーマットでデータを提供する方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11502389A JPH11502389A (ja) | 1999-02-23 |
| JP4014223B2 true JP4014223B2 (ja) | 2007-11-28 |
Family
ID=8220683
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP51410097A Expired - Fee Related JP4014223B2 (ja) | 1995-10-04 | 1996-09-25 | 受信機及び改善されたフォーマットでデータを提供する方法 |
| JP2007150591A Pending JP2008035490A (ja) | 1995-10-04 | 2007-06-06 | 受信機及び改善されたフォーマットでデータを提供する方法 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007150591A Pending JP2008035490A (ja) | 1995-10-04 | 2007-06-06 | 受信機及び改善されたフォーマットでデータを提供する方法 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US5796785A (ja) |
| EP (1) | EP0843920B1 (ja) |
| JP (2) | JP4014223B2 (ja) |
| WO (1) | WO1997013338A1 (ja) |
Families Citing this family (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6424725B1 (en) | 1996-05-16 | 2002-07-23 | Digimarc Corporation | Determining transformations of media signals with embedded code signals |
| US6122403A (en) | 1995-07-27 | 2000-09-19 | Digimarc Corporation | Computer system linked by using information in data objects |
| US6408082B1 (en) | 1996-04-25 | 2002-06-18 | Digimarc Corporation | Watermark detection using a fourier mellin transform |
| FI100629B (fi) * | 1996-05-09 | 1998-01-15 | Nokia Oy Ab | Linkkiobjektin käyttö digitaalisessa yleisradiojärjestelmässä |
| SE9703630L (sv) * | 1997-03-03 | 1998-09-04 | Telia Ab | Förbättringar av, eller med avseende på, synkronisering |
| US7284187B1 (en) * | 1997-05-30 | 2007-10-16 | Aol Llc, A Delaware Limited Liability Company | Encapsulated document and format system |
| EP0902563B1 (en) * | 1997-09-09 | 2006-01-25 | Sony Deutschland GmbH | Detection method for the transmitter identification information signal in the null symbol of a DAB stream |
| US6148422A (en) * | 1997-10-07 | 2000-11-14 | Nortel Networks Limited | Telecommunication network utilizing an error control protocol |
| US5945932A (en) * | 1997-10-30 | 1999-08-31 | Audiotrack Corporation | Technique for embedding a code in an audio signal and for detecting the embedded code |
| JP2000224062A (ja) * | 1999-02-01 | 2000-08-11 | Sony Corp | デジタル音声放送の受信機 |
| US6871180B1 (en) | 1999-05-25 | 2005-03-22 | Arbitron Inc. | Decoding of information in audio signals |
| EP1087585B1 (en) * | 1999-09-17 | 2013-08-21 | Alcatel-Lucent | Identification of a terrestrial repeater using inactive subcarriers of a multicarrier signal |
| US6434408B1 (en) * | 2000-09-29 | 2002-08-13 | Datex-Ohmeda, Inc. | Pulse oximetry method and system with improved motion correction |
| US7161239B2 (en) | 2000-12-22 | 2007-01-09 | Broadcom Corporation | Ball grid array package enhanced with a thermal and electrical connector |
| PT1978747E (pt) * | 2001-11-29 | 2014-07-24 | Panasonic Ip Corp America | Método de remoção de distorção de codificação |
| US6934570B2 (en) * | 2002-01-08 | 2005-08-23 | Masimo Corporation | Physiological sensor combination |
| US6993285B2 (en) * | 2002-04-11 | 2006-01-31 | International Business Machines Corporation | Audio buffer processing |
| US6801965B2 (en) | 2002-04-11 | 2004-10-05 | International Business Machines Corporation | Audio buffer station allocation |
| US20030195978A1 (en) * | 2002-04-11 | 2003-10-16 | International Business Machines Corporation | Audio buffer selective data processing |
| US9711153B2 (en) | 2002-09-27 | 2017-07-18 | The Nielsen Company (Us), Llc | Activating functions in processing devices using encoded audio and detecting audio signatures |
| US7222071B2 (en) | 2002-09-27 | 2007-05-22 | Arbitron Inc. | Audio data receipt/exposure measurement with code monitoring and signature extraction |
| US8959016B2 (en) | 2002-09-27 | 2015-02-17 | The Nielsen Company (Us), Llc | Activating functions in processing devices using start codes embedded in audio |
| EP1740006B1 (en) * | 2005-06-27 | 2008-01-09 | Samsung Electronics Co., Ltd. | Dynamic channel allocation method in an OFDMA mobile communication system |
| KR101405965B1 (ko) * | 2007-06-25 | 2014-06-12 | 엘지전자 주식회사 | 디지털 방송 시스템 및 데이터 처리 방법 |
| US8713593B2 (en) | 2010-03-01 | 2014-04-29 | Zazum, Inc. | Detection system and method for mobile device application |
| WO2011109083A2 (en) * | 2010-03-01 | 2011-09-09 | Zazum, Inc. | Mobile device application |
| US8576817B2 (en) | 2010-04-08 | 2013-11-05 | Spectrum Bridge, Inc. | System and method for managing radio access to spectrum and to a spectrum management system |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS6261438A (ja) * | 1985-09-12 | 1987-03-18 | Fujitsu Ltd | サ−ビスチヤンネル信号変換回路 |
| JPS63196134A (ja) * | 1987-02-09 | 1988-08-15 | Fujitsu Ltd | デジタルネツトワ−クの分割秘匿方式 |
| JPH03104333A (ja) * | 1989-09-18 | 1991-05-01 | Nec Corp | 符号化復号化装置 |
| DE4118424A1 (de) * | 1991-06-05 | 1992-12-10 | Thomson Brandt Gmbh | Verfahren zur verarbeitung und wiedergabe empfangener digital codierter audio-daten und rundfunkempfaenger zum empfang von digital codierter ton-rundfunkdaten (dar) |
| US5584051A (en) | 1991-11-01 | 1996-12-10 | Thomson Consumer Electronics Sales Gmbh | Radio broadcast transmission system and receiver for incompatible signal formats, and method therefor |
| JPH05300118A (ja) * | 1992-03-04 | 1993-11-12 | Nec Corp | 監視信号の分離多重システム |
| EP0596440B1 (en) * | 1992-11-02 | 1997-07-16 | Matsushita Electric Industrial Co., Ltd. | Station selecting apparatus for digital modulation signal use |
| DE4319769C1 (de) * | 1993-06-15 | 1994-07-14 | Grundig Emv | Verfahren und Anordnung zur Einstellung der lokalen Oszillatoren eines Empfängers in einem Mehrkanalübertragungssystem |
| US5457815A (en) * | 1994-01-13 | 1995-10-10 | Morewitz, Ii; Herbert | RBDS scan, identify and select receiving method and system |
| DE19503540A1 (de) * | 1995-02-03 | 1996-09-05 | Bosch Gmbh Robert | Verfahren zum Empfang und zur Ausgabe eines Rundfunkprogrammes mit zugefügten digitalen Informationen und Rundfunkempfängern dazu |
-
1996
- 1996-09-25 JP JP51410097A patent/JP4014223B2/ja not_active Expired - Fee Related
- 1996-09-25 EP EP96929497.4A patent/EP0843920B1/en not_active Expired - Lifetime
- 1996-09-25 WO PCT/IB1996/000991 patent/WO1997013338A1/en active Application Filing
- 1996-10-01 US US08/724,389 patent/US5796785A/en not_active Expired - Lifetime
-
2007
- 2007-06-06 JP JP2007150591A patent/JP2008035490A/ja active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| EP0843920B1 (en) | 2013-12-11 |
| JPH11502389A (ja) | 1999-02-23 |
| EP0843920A1 (en) | 1998-05-27 |
| WO1997013338A1 (en) | 1997-04-10 |
| JP2008035490A (ja) | 2008-02-14 |
| US5796785A (en) | 1998-08-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4014223B2 (ja) | 受信機及び改善されたフォーマットでデータを提供する方法 | |
| JP4014224B2 (ja) | ディジタルオーディオ放送のデータシーケンスのフォーマットを変換するためのディジタルオーディオ放送受信機、装置および方法 | |
| EP1628420A2 (en) | Mobile broadcast receiver for decoding broadcast services selected by the user | |
| CN107431545B (zh) | 用于hd无线电接收器的模拟与数字音频混合的方法和装置 | |
| KR100698273B1 (ko) | 멀티미디어 방송 시스템 및 멀티미디어 방송 채널 관리방법 | |
| US20050262419A1 (en) | Superframe error coding in digital audio broadcasting systems | |
| EP1566905A1 (en) | Enhanced error protection for packet-based service delivery in digital broadcasting systems | |
| KR20070055970A (ko) | 디지털 방송 시스템에서 서로 다른 버전의 전자 서비스가이드를 송수신하는 방법 및 장치 | |
| JPH04502693A (ja) | 無線データ・システム | |
| KR101119250B1 (ko) | 디지털 방송 시스템에서 슬립 모드시 긴급 서비스 송수신을위한 방법 및 이를 위한 송수신기 | |
| TW200408207A (en) | Digital Audio Broadcasting receiver | |
| KR101013646B1 (ko) | 아날로그 라디오 전송 시스템 내의, 대체 ｒ 디지털 송신주파수와 관련한 부가 데이터 전송 방법 및 장치 | |
| WO1997028620A1 (en) | Coding of file segments on a digital radio channel | |
| KR20070062755A (ko) | 한시적으로 ｃａ 디지털 방송을 제공하는 방법 | |
| KR101181776B1 (ko) | 재난 정보 송수신 방법 및 재난 정보 수신 장치 | |
| JP2011176547A (ja) | デジタルオーディオ放送受信装置及びデジタルオーディオ放送受信方法 | |
| KR100831357B1 (ko) | 디지털 멀티미디어 방송의 송신방법 및 수신방법 | |
| EP0833468B1 (en) | Receiver for receiving mulliplexed broadcast programmes, comprising audio data and supplementary broadcast data | |
| JP3830074B2 (ja) | ディジタル放送受信装置及びそのラベル表示方法 | |
| JP3290083B2 (ja) | 放送受信機 | |
| JP2001352264A (ja) | ディジタル放送受信装置及びその割り込み受信制御方法 | |
| KR100930729B1 (ko) | 방송 시스템에서의 신호 송신 방법 및 신호 수신 방법 | |
| CN101375601A (zh) | 发射和接收数字广播信号的方法和接收系统 | |
| JPH10303763A (ja) | ディジタル放送用ラジオ受信機 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060606 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20060905 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20061023 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061206 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070206 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070606 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070802 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070814 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070911 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100921 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110921 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110921 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120921 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120921 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130921 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |